Come ricreare un'AMI funzionante dallo snapshot di recupero dopo un'interruzione dell'8 agosto?

11

Dopo l' interruzione di Amazon dell'8 agosto , tutte le AMI (basate su EBS) hanno smesso di funzionare per molti utenti . Ciò è dovuto alla corruzione di alcuni settori nelle istantanee su cui si basano le AMI.

Tuttavia, Amazon ha creato snapshot di ripristino in cui i problemi del disco devono essere risolti. Quelli sono chiamati sulla falsariga di "Istantanea di recupero per vol-xxxxxxxx".

Ho creato una nuova AMI dall'istantanea di recupero che ha funzionato bene, ma le istanze avviate da questa nuova AMI non funzionano: il loro stato è "In esecuzione", ma non riesco a collegarmi alla macchina né accedere a nessuno dei servizi Web che dovrebbero essere in esecuzione lì. Si riduce a questo (dal registro di sistema, accessibile tramite la console di gestione AWS):

EXT3-fs: sda1: couldn't mount because of unsupported optional features (240).

EXT2-fs: sda1: couldn't mount because of unsupported optional features (244).

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)

Ho montato un volume creato da quella snapshot di recupero in un altro server su AWS e tutto sembra abbastanza normale. Ad esempio, fsck dice:

$ sudo fsck -a /dev/xvdg
fsck from util-linux-ng 2.17.2
uec-rootfs: clean, 53781/524288 files, 546065/2097152 blocks

In una delle discussioni del forum AWS, ho trovato questo consiglio da qualcuno con problemi simili:

Una soluzione sarà quella di creare un volume dall'istantanea e collegarlo a un'istanza in esecuzione, utilizzare fsck --force per forzare il controllo del filesystem e una volta cancellato, è possibile creare un'istantanea e usarla per l'AMI.

Ma non so come forzare fsck su Ubuntu (11.04):

$ sudo fsck --force /dev/xvdg
fsck from util-linux-ng 2.17.2
fsck.ext3: invalid option -- 'o'

Qualcuno sa come forzare il controllo del file system sul volume su Ubuntu? Altre idee su come avviare istanze di lavoro basate sull'istantanea di recupero?

In questo momento sembra che potrebbe essere più veloce ricominciare da un'AMI Ubuntu pulita e reimpostare tutti i nostri servizi. :-( Ma ovviamente preferirei non farlo se c'è un modo per far funzionare l'istantanea di recupero.

— Jonik
fonte

14

Ho riscontrato lo stesso problema durante il tentativo di duplicare una macchina.

Il problema si è rivelato essere il kernel. Sia durante la creazione dell'AMI che l'istanza ho selezionato l'impostazione predefinita per l'immagine del kernel.

Per risolvere il problema, ho ricreato l'AMI usando la stessa immagine del kernel dell'istanza originale.

— DCYorke
fonte

Per chiarire, l'immagine del kernel di default manca del supporto ext4, ma il kernel che è stato usato per compilare l'AMI dovrebbe sempre essere usato comunque.

— DCYorke,

Se rimane solo l'istantanea, sarà molto difficile ripristinarla. Puoi suggerire un metodo per eseguire il backup di questo tipo di metadati (anche quali gruppi di sicurezza e dati utente vengono utilizzati) con lo snapshot o da qualche altra parte?

— Martijn Heemels,

2

Potresti provare il seguente comando (nota l'opzione -f invece di --force): sudo fsck -f /dev/xvdg

Spero che questo ti aiuti. Fred

— fred
fonte

fsck -fanzi fa qualcosa di più (non so esattamente cosa; man fscknon dice nulla al riguardo), quindi +1. Ma in ogni caso questo non risolve l'intero problema; Ho creato uno snapshot e quindi un AMI dal volume fscked, ne ho lanciato un'istanza e ancora ottengo lo stesso errore "Kernel panic ... Unable to mount root" nel registro di sistema.

— Jonik,

0

Non volevo perdere altro tempo a combattere con strani problemi specifici di AWS, quindi ho creato una nuova istanza pulita da una delle AMI Ubuntu ufficiali (nel mio caso ami-359ea941che è un'immagine a 32 bit supportata da EBS di Ubuntu 11.04 nella eu-west-1) e ho ricreato lì la mia configurazione del server.

Il fatto di poter montare un volume creato dall'istantanea di ripristino nella nuova istanza ha reso la reinstallazione molto più veloce. Ad esempio, ho fatto qualcosa di simile cp -a /mnt/recovery/usr/local /usrper ripristinare un sacco di roba sotto /usr/local.

Quindi nel mio caso i backup di ripristino erano tutt'altro che inutili in quanto potevo accedere ai dati su di essi. Ma ovviamente sarebbe stato più bello creare un AMI dall'istantanea e continuare a utilizzare (istanze da) che come l'intero incidente non è mai accaduto. (Sentiti libero di aggiungere una risposta se sai come raggiungerlo!)

— Jonik
fonte