Situazione orribile: file system montati contemporaneamente da più istanze di SO indipendenti

Come posso uscire da questa situazione in sicurezza?

I dettagli sono i seguenti:

Un server xen ha dispositivi a blocchi allocati alle macchine virtuali. Ma questi dispositivi sono stati montati anche all'interno di Xen.

Infatti 44 di questi dispositivi a blocchi sono stati montati in questo modo. A peggiorare le cose, ogni dispositivo fisico è visto su 4 percorsi e ognuno di essi è montato su un mountpoint separato. In altre parole, i dispositivi sono effettivamente montati 5 volte ciascuno.

Il SO guest VM vede il percorso tramite uno pseudo dispositivo PowerPath (allocato come dispositivo phy: block alla domU)

Alcuni dei dispositivi sono formattati come ext2 e reiserfs.

Non c'è bisogno di spiegarmi i rischi di corruzione del file system qui coinvolti.

Temo che anche solo smontare i file system possa causare la corruzione e ritengo che a questo punto trarre energia dall'host sia l'opzione più sicura .

Si noti che le applicazioni, i database Oracle per la maggior parte, in tutte le macchine virtuali sono ancora in esecuzione e in uso.

Ho scoperto questo quando ho studiato un elevato utilizzo della CPU su dom0. Esiste un processo "find" non verificabile, con cwd -> / media / disk-12 che è montato da / dev / sdf1, che appartiene a / dev / emcpowerr

Prima che qualcuno lo chieda, l'unica volta che ho visto i processi non possono essere uccisi e continuare a usare CPU e RAM (a differenza di un processo defunto / zombi), è quando ci sono I / O commessi in sospeso, ad es. Sincronizzazione restituita ma non fisicamente ancora su disco . Più comunemente ciò si verifica sull'I / O su nastro.

Suggerimenti !?

PS Mi sarei aspettato che i dispositivi fossero "riservati" una volta montati, per evitare questo tipo di cose? O non è possibile su Linux?

EDIT: in primo luogo sono convinto che KDE all'interno dell'hypervisor) sia il colpevole. Sembra che KDE stia montando i dispositivi possibili durante la registrazione per creare icone del desktop. La stessa cosa però non sta accadendo su altri server Xen, ma tutti gli altri server eseguono una versione molto più vecchia di SLES e KDE ... V4 sembra essere quello offensivo, con 3.4 che si comporta meglio).

Inoltre, due VM non critiche sono state bloccate. Dopo averli chiusi, non si riavvierebbero a causa della corruzione del file system. La VM principale / di produzione è ancora in esecuzione e il database su di essa funziona ancora, ma chiaramente questa è una bomba a orologeria. Il cliente sta tentando di ricostruire l'ambiente su un'altra macchina virtuale su un altro server ma è bloccato su problemi di configurazione di alcuni componenti, quindi stiamo aspettando ...

In ogni caso, sento che nessuna delle risposte è stata finora più di "la migliore pratica è sempre chiusa con garbo" E spero di ottenere qualcosa di più concreto ... In ogni caso, sento che questa situazione può giustificare un po 'più di attenzione pensiero. La chiusura causerà la sincronizzazione degli IO in sospeso, in particolare gli aggiornamenti dei metadati del file system dall'hypervisor, e la corruzione del file system potenzialmente maggiore?

— Johan
fonte

E in questo momento qualsiasi backup eseguito prima della "chiusura" potrebbe semplicemente eseguire il backup dei dati danneggiati, anche se in questa situazione è più probabile che i metadati del file system siano danneggiati, piuttosto che il contenuto del file.

— Johan

Temo che perderai almeno alcuni dei dati in ogni caso. La disattivazione fisica dell'host o la chiusura forzata delle macchine virtuali potrebbero avere le conseguenze indesiderate del disordine di tutto (vale a dire anche di quei file system montati una sola volta). Probabilmente proverei a terminare tutto nel modo più pulito possibile per ridurre al minimo le perdite. E ovviamente assicurandomi che non accada di nuovo.

— peterph

Per quanto riguarda la sua prevenzione, IIUC potresti provare a impostare le autorizzazioni sul dispositivo in dom0 una volta che è stato aperto dal guest, ma poiché le autorizzazioni fs (sui file del dispositivo) possono essere incrociate da root (a meno che tu non abbia un kernel patchato) potrebbe non ho bisogno di aiuto.

— peterph

Per quanto riguarda il tuo post script: se i dispositivi sono visibili attraverso più percorsi, probabilmente il kernel non sa nemmeno che sono tutti lo stesso dispositivo, quindi come potrebbe "riservarlo"? Per quanto riguarda l'esportazione di un dispositivo da dom0 a domU multiple, ti consente di farlo perché potresti effettivamente volerlo fare apposta (ad esempio con un filesystem che lo supporta o montato in sola lettura ovunque).

— Celada,

@Celada Ci ho pensato molto, ma ci sono modi di "bloccare" i dispositivi: PowerPath dovrebbe (nel caso di Solaris) riservare tutti i percorsi principali di un dispositivo (al momento dell'inizializzazione). Inoltre, i comandi di "riserva" SCSI sono gestiti dal dispositivo di destinazione, quindi una volta che un obiettivo è riservato, dovrebbe rifiutare di consentire una riserva su uno dei percorsi per quel dispositivo. Almeno questa è la mia comprensione limitata.

— Johan

Risposte:

Se i dischi vengono scritti da un singolo punto di montaggio, non viene fatto alcun danno. Esegui un arresto pulito, (esegui il backup dallo stato sospeso se vuoi) correggi i montaggi. Non eseguire altro che le app nude necessarie su Dom0. Se, OTOH, le partizioni vengono scritte da più percorsi, questo è MALE e peggiora di secondo in secondo luogo. Inserire la presa.

— Forma di vita aliena
fonte

Non ho una ragione concreta, ma il mio istinto mi dice che il seguente potrebbe essere l'approccio migliore:

Chiudi le applicazioni.
Copia tutti i dati dalla VM tramite la rete in una posizione di backup.
Disinstallare i file system dall'interno della VM.
Arrestare la VM. (C'è solo una VM in esecuzione su questo host ora).
Assicurarsi che nessun domU sia impostato per l'avvio automatico.
Estrarre l'alimentazione dall'host per impedire all'hypervisor di eseguire azioni di "chiusura", sincronizzazione di I / O in sospeso, ecc.
Avviare la VM, sperando che l'hypervisor stesso sia sopravvissuto al power-yank.
Se fallisce, ricostruire l'ambiente. (I dischi di avvio delle macchine virtuali sono basati su file, ma i punti di montaggio dei dati risiedono su un disco esterno allocato come dispositivi a blocchi)
Controllare se l'hypervisor sta montando file system appartenenti alle domU. Disinstalla questi prima di avviare qualsiasi domU)
Disattiva il montaggio automatico di KDE.
Avviare la VM e forzare un controllo completo di FS.

Alternativa a 11: avviare la VM e montare i file system senza un fsck completo.

Il ragionamento è che non voglio che l'hypervisor Xen abbia più possibilità di quella assolutamente necessaria per causare la corruzione sui file system domU.

— Johan
fonte

Non sono un esperto di Xen e non ho ancora avuto esperienza con esso. Ma il mio approccio se fossi al tuo posto sarebbe: in primo luogo so che potrei perdere i dati (forse anche tutti); secondo, proverei a creare snapshot e quindi a sospendere le VM, ripristinandole in un ambiente diverso e sicuro.
Non voglio darti false speranze, ma penso che sarai fortunato se riuscirai a recuperare qualcosa.

Attenzione : seguire questi consigli potrebbe farti perdere tutti i dati. Sta a te vedere se vale il rischio o meno.

Con un sacco di fortuna, le tue applicazioni funzionano ancora perché i dati che stanno utilizzando sono tutti nella memoria volatile. Dovresti provare a sfruttare questa situazione (prova a valutare se ciò potrebbe accadere in base alle app) ed esportare i dati in tempo reale in una condivisione di rete se le applicazioni offrono tale funzionalità. Se sul disco sono presenti dati, questa funzione di esportazione potrebbe essere "bloccata" in modo simile findall'istruzione o all'arresto anomalo (e all'arresto anomalo dell'applicazione o del sistema operativo) a causa dei dati del disco modificati / danneggiati.

Quindi potresti provare a fare un'istantanea dal vivo, le istruzioni nel seguente articolo: Creazione di istantanee in Xen . Vorrei fare l'istantanea byte per byte, anche se potrebbe rimanere bloccata proprio come il tuo findcomando ... Tuttavia, non darei così tanta speranza.

Prima di eseguire il comando precedente, è necessario leggere questo documento da Citrix che aiuta a comprendere le istantanee in Xen (PDF) .

Ti auguro buona fortuna.

— Huygens
fonte

Grazie. Il cliente ha un'esportazione del database. Penso che abbiano appena usato FTP per toglierlo dalla VM, ma è possibile montare una condivisione di rete ed esportare direttamente su quella.

— Johan

Ho avuto l'idea di sospendere la VM e quindi di trasferirne una copia completa su un altro host e quindi provare a a) Riprenderlo dalla modalità di sospensione oppure b) Avviarlo, seguito da un riavvio e da fsck. L'idea è che poiché ho ancora la VM sospesa sull'host originale, potrei essere in grado di riprenderla se la copia non funziona sull'altro host.

— Johan

Inoltre, il problema con FWIW nel tornare a un backup è che si teme che tutti i backup eseguiti negli ultimi due mesi siano corrotti.

— Johan

@Johan questo è più che probabilmente vero, la maggior parte se non tutti i backup (poiché si è verificato il problema) sono probabilmente danneggiati. Lo stesso potrebbe valere per l'esportazione del database. Buona fortuna di nuovo, ne avrai bisogno!

— Huygens,