Anche se avviene raramente, Amazon può decidere di cancellare deliberatamente le vostre istanze al verificarsi di determinati eventi. Anzi, questa è la normale procedura che Amazon adotta con le istanze "spot" in caso di sovraccarico della struttura. Il problema è che normalmente i dischi scompaiono sempre insieme alle macchine quando queste si disattivano.

Amazon consiglia l'utilizzo di una architettura software elastica e ridondante. Purtroppo questa soluzione non è sempre possibile o conveniente. In questo articolo è descritto:

  • cose da fare "prima" che le istanze vengano terminate.
  • come rendere persistenti alla terminazione i volumi in AMI EBS.
  • come ricostruire una AMI da volumi EBS che ripristina l'istanza terminata

Questo articolo è valido solo per istanze costruite su AMI basate su EBS.

Usate AMI basate sulla tecnologia EBS

Le macchine virtuali in Amazon EC2 (AMI) possono usare due tecnologie di storage, una basata su EBS (Elastic Block Storage) e l'altra basata su S3. Utilizzate sempre AMI EBS-Backed, infatti ricordate che le AMI S3-Backed usano solo dischi effimeri che vengono sempre cancellati al momento dello spegnimento (o del crash) della macchina.

Una AMI basata su EBS può invece essere ricostruita partendo dal disco che contiene il root file system.

Installate ed imparate ad usare le API di EC2 da command line

Sulla documentazione ufficiale è descritto tutto abbastanza bene per un ambiente unix. Se non sapete come fare in ambiente windows fate anche una visita qui. Può essere opportuno costruirsi una macchina virtuale che contiene già tutto l'ambiente per utilizzare le API di AWS, e magari qualche script. In questo modo, anche se non avete a disposizione il vostro PC potete comunque gestire il vostro data center virtuale, anche da un buon cellulare ( serve: ssh o rdp, keypair o Administrator passwd e accesso  AWS console)

Rendete il disco di root persistente alla terminazione dell'istanza

Le istanze di AMI EBS-Backed montano volumi persistenti ( vedi la sezione device mapping sul manuale utente ). Sfortunatamente, per default, AMAZON cancella i volumi EBS alla teminzione della AMI. Possiamo però ovviare a questa seccatura modificando il comportamento di default tramite le API di EC2. Purtroppo la procedura descritta nel manuale di Amazon è incompleta perchè non tiene conto delle istanze lanciate su datacenter di regioni diverse. Ecco cosa dovete fare:

Guardate le informazioni relative ad una istanza e segnatevi negli appunti queste informazioni:

  • l'ID dell'istanza, l'informazione è nel titolo del primo tab della description dell'immagine: inizia con una "i" (es. i-6fabe338 ). Non confondetela con l'AMI ID.
  • l'ID della zona in cui l'istanza sta girando (es.Zone:eu-west-1a) non considerate l'ultimo carattere, ovvero considerate ad esempio solo eu-west-1
  • Il root device, es. /dev/sda1, si trova analizzando il campo Block Device (es: /dev/sda1=vol-d8c905c1:attached:2010-09-29T12:43:17.000Z:true )
  • L'ID del volume cui la root è montata, anche questa informazione è nel campo Block Device (/dev/sda1=vol-d8c905c1:attached:2010-09-29T12:43:17.000Z:true)

Notate il "true" alla fine del Block Device (/dev/sda1=vol-d8c905c1:attached:2010-09-29T12:43:17.000Z:true):  questo flag significa: "attiva la cancellazione del device alla terminazione dell'istanza". Il nostro obiettivo è di modificarlo in "false".

Usando le API di amazon, lanciate ora comando

ec2-modify-instance-attribute istanceID -b "rootdevice=VolumeID:false" --region regionid

Nel caso dei dati presi ad esempio:

ec2-modify-instance-attribute i-6fabe238 -b "/dev/sda1=vol-d8c905c1:false" --region eu-west-1

Non dimenticate di racchiudere la specifica del blocco tra apici (in particolare sotto windows)

Il comando ec2-modify-instance-attribute potrebbe ritornare degli errori che però fortunatamente spesso non pregiudicano il buon esito del comando. Ad ogni buon conto ricaricate le proprietà dell'istanza su management console e verificate da che il campo Block Device sia variato: al posto di true ci deve essere scritto false.

Per maggiori dettagli consultate questo ottimo articolo o la procedura di Amazon . Se state creando una vostra AMI è anche possibile registrare la AMI specificando esplicitamente di non voler cancellare i volumi montati alla terminazione della istanza. Purtroppo la documentazione di Amazon tende a dare per scontato particolari i essenziali visti nel precedente passaggio  (ovvero gli apicetti e il parametro --region)

Salvate le informazioni delle istanze necessarie al loro ripristino

Per ogni istanza prendete nota delle informazioni che sono necessare alla sua ricostruzione.

Potete annotare le informazioni direttamente sulla snapshot da cui è costruita l'istanza utilizzando i tag di Amazon o i vostri appunti.

Per ogni volume utilizzato dalla ami, annotate le seguenti informazioni:

  • DNS nome a dominio eventualmente assegnato alla macchina (es. www.mysite.it)
  • Mount point del volume (es. / )
  • Dev device a cui il volume è attaccato (es sda1)
  • Kernel Id e Ram disk Id  eventualmente utilizzati dalla AMI
  • Boot: è un volume bootable? Ovvero il volume è montato come root file system.

Sulle Ami Io tengo anche traccia dello stato con due valori:

  • running : la ami è (o dovrebbe essere) connessa ad una istanza attiva. In questo caso il volume costruito a partire dalla snapshot associata alla ami contiene i dati aggiornati.
  • ready: la ami è pronta per essere lanciata. 
  • backup: la ami rappresenta un backup di una macchina virtuale in un deterimnato istante 

Definite una politica di backup basata su snapshot

Sia da console che da API, è possibile fare delle snapshot a caldo dei volumi EBS montati dalla AMI. 

Ogni snapshot costa in termini di spazio utilizzato. Amazon utilizza la tecnologia di data deduplication per cui si paga solo per i bit modificati rispetto alla snapshot precedente. Di fatto una snapshot costa molto poco e si fa in pochi secondi.

Ciò detto non vale certo la pena di fare un backup ogni 10 minuti. Può essere invece utile partizionare su più volumi EBS i dati in funzione della necessità di backup più o meno frequente. 

Ricordatevi che lo spazio occupato si paga ogni mese... inutile tenere troppe snapshot, potete tranquillamente cancellare quelle che non vi servono più: da una qualsiasi snapshot è infatti possibile ricostruire l'intero volume aggiornato all'istante in cui è avvenuta la snapshot indipendentemente dall'esistenza di snapshop precedenti.

In ogni caso, se si vuole implementare una strategia d backup tradizionale, potete considerare le snapshot come efficentissimi e robusti backup incrementali. Anche il restore dei dati è davvero facile (vedi doc EBS per dettagli).

In caso di terminazione della macchina virtuale:

  1. Fate subito una snapshot preventiva dei volumi EBS che contiengono il root fle system e i dati (per mettersi al riparo da errori fatti durante il recovery del disco). 
  2. Verificate l'integrità dei filesystem contenuto nei volumi EBS. Sfruttiamo ancola la cloud creando un AMI ad hoc in cui installiamo gli strumenti per la verifica e il ripristino dei dischi e su cui montiamo i dischi da verificare. Verificate e rimuovete  nel root file system eventuali dipendenze da filesystem remoti e/o effimeri (meglio evitarli).Il più delle volte troverete un disco in buone condizioni e potete passare all'ultimo punto. In caso diverso potete tentare di correggere eventuali errori su filesystem con fsck e/o altri tool. Se in questa fase fate pasticci vi tornerà preziosa la snapshot fatta al punto 1. Se dopo averle tentate tutte il disco risulta inutilizzabile, partite da una delle snapshot fatte durante il processo di backup.
  3. Se avete fatto qualche modifica ai dischi, fatene un'altra snapshot 
  4. Create una nuova AMI partendo dalle snapshot volumi riparati. 

Caso 1: AMI basata su Linux

Se la vostra AMI utilizza una tecnologia di paravirtualizzazione (ovvero è una macchina basata su kernel linux), usate questa procedura per attivare una istanza partendo da una snapshot del vostro root disk.

Per questa attività, ancora una volta, avremo bisogno delle API da linea di comando:

ec2-register -n "mio_ID_nome" -d "Descrizione AMI" --root-device-name "/dev/sda1" \
-b "/dev/sda1=snap-1234abcd::false" --ramdisk "ari-12345678" \
--kernel "aki-abcd1234" --region eu-west-1

I parametri in rosso sono quelli che dovete modificare: avrete bisogno i dati annotati come descritto nel precedenti capitoli:

  • snap-1234abcd:  l'ID della vostra snapshot;
  • /dev/sda1/:device che che contiene il file system di root;
  • snap-1234abcd: l'id della snapshot del root filesystem predisposta ai punti precedenti. N.B. abbiamo già impostato il volume rendendolo persistente (flag "delete on termination"=false)
  • se la vostra AMI necessita al boot di altri dischi, usate altri blocchi della forma -b "device=snapshot"
  • ari-12345678:  ID del RAM Disk (se c'e', in caso contrario omettete il parametro --ramdisk)
  • aki-abcdef12 il Kernel ID (se c'e', in caso contrario omettete il parametro --kernel)
  • mio_ID_nome:  un identificativo a piacere, corto e senza spazi
  • Descrizione AMI: una descrizione della vostra AMI (es www.example.com@20110101)
  • eu-west1: specifica il nome della region in cui volete aver disponibile la nuova AMI. Deve essere la stessa usata per i volumi e le snapshot.

Se tutto ha funzionato vi troverete, nella finestra della management console - sezione AMI, una nuova AMI con le caratteristiche volute. Lanciandola riattiverte ripristinerete l'operatività della vostra macchina virtuale. 

Per ulteriori approfondimento guardate anche la documentazione ufficiale.

Caso2: ripristino di una istanza windows

Non è possibile registrare una ami bootable basata su windows. Questo metodo sembra però funzionare:

  1. Lanciate un'altra istanza partendo dal più recente backup o dall'ami originale. Create una istanza normale (i.e. non spot) nella stessa zona in cui esiste il volume contenete il root disk dell'istanza crashata.
  2. Fermate (stop) l'istanza
  3. Smontate (detach) il volume di sistema dalla istanza stoppata e buttatelo
  4. Attaccate all'istanza stoppata il root volume della vecchia istanza, eventualmente ricostruitene uno partendo dalla più recente snapshot.Usate come mount point /dev/sda1
  5. Fate il re-start dell'istanza stoppata.

N.B. l'opzione "stop" non è presente sulle istanze lanciate come "spot". Se avete bisogno di ripristinare una istanza stop, eseguite i passi sopra indicati utilizzando una istanza normale. Quando l'istanza funziona utilizzatela come matrice per create una nuova ami; richiedete l'attivazione di una istanza spot sulla ami creata e, quando siete sicuri che tutto va bene, potete terminare l'istanza normale e cancellare il suo volume.

Ricordatevi infine di riassegnare l'IP address all'istanza ripristinata e di montare eventuali volumi aggiuntivi.

 

Non fatevi prendere dal panico!

(Douglas Adams, in Guida galattica per gli autostoppisti)

Sovente, quando  la nuova AMI non riesce a fare partire l'istanza, il problema risiede risiede nei file system montati a livello al boot (in unix /etc/fstab), in particolare i dischi effimeri. Montando il disco di boot da un'alta istanza potete editare il file /etc/fstab evitando dipendenze che a runtime potrebbero non essere valide, una volta che la macchina virtuale è running ripristinerete anche i file system aggiuntivi.

Normalmente, se non ci si fa prendere dal panico, si riesce a ripristinare il tutto esattamente come prima del crash in pochi minuti.

L'unico modo per non impanicarsi è provare e riprovare la procedura di ripristino quando non serve. Il bello della cloud è proprio che fare una simulazione di crash, anche su sistemi importanti, non richiede alcun costo di infrastruttura aggiuntivo.

Sintesi

Le tre azioni da fare "prima":

  1. usare AMI basate su EBS
  2. annotare le caratteristiche delle istanze funzionanti
  3. rendere persistenti i volumi alla terminazione delle istanze

le quattro azioni da imparare a fare  velocemente in caso di crash:

  1. fare snapshot dei volumi utilizzati dalla istanza crash
  2. verificare integrità file systems
  3. creare nuova AMI partendo dalle snapshot
  4. lanciare una istanza basata sulla  nuova ami