I filesystem di root Xen DomU diventano di sola lettura in caso di failover IP virtuale iSCSI

I miei server Xen sono openSUSE 11.1 con open-iscsi per il nostro cluster SAN iSCSI. I moduli SAN si trovano in un gruppo di failover IP dietro un IP virtuale a cui si connettono gli iniziatori.

Nel caso in cui il server SAN primario non funzioni, il secondario assume il ruolo di servire come destinazione. Tutto questo è gestito dal software SAN / iQ LeftHand e funziona bene nella maggior parte delle situazioni.

Il problema che ho è che occasionalmente alcuni dei miei DomU Xen avranno il loro filesystem di root andare in sola lettura dopo un failover IP. Non è coerente e si verifica in un sottoinsieme diverso ogni volta che si verifica un failover. Stanno tutti eseguendo la stessa immagine del software openSUSE 11.1.

I filesystem di root per ogni DomU sono montati da open-iscsi in Dom0 e quindi Xen utilizza il driver di dispositivo a blocchi standard per esporlo a DomU.

Il sintomo esatto è che come root come in esecuzione touch /testrestituisce l'errore "filesystem di sola lettura". Tuttavia, l'output di lo mountmostra come montato in lettura-scrittura. Naturalmente, anche tutti gli altri I / O sulla domU non funzionano in questo momento, quindi la macchina si arresta. Il semplice riavvio xmda Dom0 senza nemmeno ricollegare la sessione iSCSI fa funzionare di nuovo tutto.

Sul lato Dom0 i messaggi syslog durante il failover sono simili ai seguenti:

kernel: connection1:0: iscsi: detected conn error (1011)
iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
iscsid: connection1:0 is operational after recovery (1 attempts) 

Sto facendo fatica a capire a quale livello eseguire il debug di questo problema, è qualcosa nel kernel DomU? o a livello di Dom0 o Xen? Penso che ci sia probabilmente qualche parametro da qualche parte che ha bisogno di modifiche per aumentare una sorta di timeout, ma non sono sicuro dove cercare.

Non penso davvero che sia un problema con open-iscsi semplicemente perché il dispositivo a blocchi collegato è ancora leggibile e scrivibile da Dom0.

Alla fine ho risolto questo usando i seguenti consigli e impostazioni dalla documentazione di open-iscsi:

8.2 iSCSI settings for iSCSI root
---------------------------------

When accessing the root parition directly through a iSCSI disk, the
iSCSI timers should be set so that iSCSI layer has several chances to try to
re-establish a session and so that commands are not quickly requeued to
the SCSI layer. Basically you want the opposite of when using dm-multipath.

For this setup, you can turn off iSCSI pings by setting:

node.conn[0].timeo.noop_out_interval = 0
node.conn[0].timeo.noop_out_timeout = 0

And you can turn the replacement_timer to a very long value:

node.session.timeo.replacement_timeout = 86400

Dopo aver impostato la connessione a ciascun LUN come descritto sopra, il failover funziona come un incantesimo, anche se occorrono diversi minuti.

Sembra un problema con l'iniziatore iSCSI in esecuzione su dom0. L'iniziatore non dovrebbe inviare errori SCSI nello stack così rapidamente. Probabilmente vorrai impostare ConnFailTimeout in iscsi.conf, questa è l'impostazione che determina quanto tempo prima considera un errore di connessione un errore e invia quell'errore nello stack SCSI.

Analizzerei anche quanto tempo impiega effettivamente il failover, potrebbe richiedere più tempo del previsto. In tal caso, forse il failover VIP sta impiegando troppo tempo a causa di problemi relativi all'ARP.

Ci sono messaggi in dom0 che indicano errori di lettura / scrittura o errori scsi al momento del failover? In tal caso, sembra che questo errore di scrittura venga trasmesso a domU. DomU non "sa" che si tratta di un dispositivo iSCSI, quindi si comporta come se il disco sottostante fosse andato via e rimontasse il filesystem in sola lettura (vedi manpage mount (1) - errors=continue / errors=remount-ro / errors=panic)

Dal punto di vista di dom0, non verrà modificato in sola lettura: questo comportamento di sola lettura è un semantico del filesystem, non un semantico del dispositivo a blocchi.

Dici che in questo momento "tutti gli altri I / O falliscono" - intendi domU o dom0?

Di solito quando si configura una soluzione iSCSI HA utilizzo il multipath anziché l'acquisizione IP virtuale: consente una maggiore visibilità sull'host e non si ha una scomparsa improvvisa di una sessione iSCSI che deve essere riavviata: è sempre lì, ce ne sono solo due . È un'opzione in questo ambiente?

Uhm ... Parte del problema è anche che non stai eseguendo / come RO. Le migliori pratiche in termini di sicurezza indicano che dovresti avere "/" montato ro e che tutti i filesystem che necessitano di rw devono essere montati separatamente, (cioè, / var e / tmp). Se ci sono directory in / etc che devono essere scritte, dovrebbero essere spostate in / var / etc / path e collegate simbolicamente a / etc.

"/" deve essere montato RW solo in modalità utente singolo.

L'impostazione in questo modo potrebbe impedire il segfault nella situazione sopra quando combinato con gli altri suggerimenti.