Creazione di un'immagine AMI EC2 da un'istanza in esecuzione anziché da un'istantanea del volume


22

Voglio eseguire il backup di un'istanza EC2 basata su Linux mentre è in esecuzione senza tempi di inattività, quindi avviare una nuova istanza. (L'istanza esegue un server Web e un database Postgres.)

Ho scoperto che ci sono due modi per farlo, ma sono confuso su quale sia la differenza nel risultato tra di loro.

Opzione n. 1: crea un AMI direttamente da un'istanza in esecuzione:

  1. Crea una nuova AMI direttamente dall'istanza originale in esecuzione.
  2. Avviare una nuova istanza dall'AMI

Opzione n. 2: creare manualmente un AMI da un'istantanea:

  1. Scatta un'istantanea dal volume associato all'istanza originale in esecuzione
  2. Crea AMI dall'istantanea, inserendo manualmente dettagli come architettura e ID kernel
  3. Avvia una nuova istanza dall'immagine creata manualmente

Ora ciò che confonde è che quando si crea un AMI direttamente da un'istanza, EC2 riavvierebbe l'istanza per impostazione predefinita. C'è una casella di controllo "Nessun riavvio" con la seguente descrizione comando:

Se abilitato, Amazon EC2 non arresta l'istanza prima di creare l'immagine. Quando viene utilizzata questa opzione, l' integrità del file system sull'immagine creata non può essere garantita.

C'è davvero una differenza nel risultato di queste opzioni in due modi? Per me è come se stessi facendo manualmente le stesse cose che la procedura guidata automatizzata farebbe comunque. Genera snapshot, seleziona gli ID del kernel e le architetture.

Perché uno ha un testo di avviso e l'altro no? L'istantanea di un'istanza in esecuzione è considerata relativamente sicura e se la creazione di AMI esegue un'istantanea in background, è più pericolosa che eseguire tutto manualmente?

Risposte:


13

Fanno esattamente lo stesso se si seleziona l' no rebootopzione quando si crea l'AMI direttamente da EC2. Questo crea fondamentalmente un'istantanea che può essere potenzialmente in uno stato incoerente. Ad esempio, si rischia di avere uno stato incoerente se si eseguono molte scritture su disco durante la creazione dell'istantanea.

Se si desidera creare uno snapshot in uno stato "coerente", è necessario prima arrestare l'istanza, quindi eseguire uno snapshot e riavviare l'istanza. Questo è il motivo per cui l'opzione di creazione AMI da EC2 è piuttosto utile perché non è necessario arrestarsi e riavviare. Amazon se ne occupa e anche l'indirizzo IP non cambia nella tua istanza. (Se interrompi / riavvii l'istanza, il tuo indirizzo IP in realtà cambia)

Non sono davvero sicuro del perché Amazon non abbia un avviso se si prende un'istantanea direttamente dal volume ma dal punto di vista del volume non importa davvero se il volume viene utilizzato da un'istanza in esecuzione o non in esecuzione ( importa solo se è collegato o bloccato senza alcun effetto sulla creazione di istantanee)


Sono d'accordo che dovresti creare le AMI poiché non vuoi chiudere l'istanza. Puoi cercare soluzioni che lo fanno immediatamente per risparmiare tempo. Personalmente uso totalcloud.io per automatizzare le mie azioni su AWS.
Veer Abheek Singh Manhas,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.