Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

4.14. Funzione Withdraw di GFS2

La funzione withdraw di GFS2 è una funzione per l'integrità dei dati dei file system GFS2 in un cluster. Se il modulo del kernel GFS2 rileva una inconsistenza nel file system GFS2 dopo una operazione I/O, il file system non sarà disponibile al cluster. L'operazione I/O viene arrestata ed il sistema attende la fine di eventuali errori, impedendo il verificarsi di ulteriori danni. Se si verifica questo comportamento sarà possibile arrestare manualmente qualsiasi altro servizio o applicazione, e successivamente riavviare e rimontare il file system GFS2 per eseguire nuovamente i journal. Se il problema persiste sarà possibile smontare il file system da tutti i nodi nel cluster ed eseguire un ripristino con il comando fsck.gfs2. La funzione withdraw di GFS è meno severa di un kernel panic, il quale potrebbe causare l'esecuzione del fencing di un nodo da parte di un altro nodo.
Se il sistema è stato configurato con lo script d'avvio gfs2 abilitato ed il file system GFS2 è stato incluso nel file /etc/fstab, il file system GFS2 verrà rimontato al momento del reboot. Se si verifica il ritiro del file system GFS2 a causa di una presunta corruzione del file system, è consigliato eseguire il comando fsck.gfs2 prima di rimontare il file system stesso. In questo caso per non rimontare il file system al momento dell'avvio eseguire la seguente procedura:
  1. Disabilitare momentaneamente lo script d'avvio sul nodo interessato con il seguente comando:
    # chkconfig gfs2 off
  2. Riavviare il nodo interessato avviando il software del cluster. Il file system GFS2 non verrà montato.
  3. Smontare il file system da ogni nodo nel cluster.
  4. Eseguire fsck.gfs2 sul file system solo da un nodo in modo da assicurarsi che il file system non sia corrotto.
  5. Abilitare nuovamente lo script d'avvio sul nodo interessato eseguendo il seguente comando:
    # chkconfig gfs2 on
  6. Rimontare il file system GFS2 da tutti i nodi nel cluster.
Un esempio di inconsistenza in grado di causare il ritiro di un GFS2 è un conteggio dei blocchi incorretto. Quando il kernel del GFS rimuove un file da un file system esso rimuove sistematicamente tutti i blocchi relativi ai metadati ed ai dati associati con quel file. Una volta terminato verrà controllato il conteggio dei blocchi. Se il conteggio è diverso da uno (ciò significa che tutto ciò che è rimasto è il solo inode del disco), ciò indicherà una inconsistenza del file system poichè il conteggio non corrisponde all'elenco di blocchi trovati.
È possibile sovrascrivere la funzione withdraw del GFS2 montando il file system specificando l'opzione -o errors=panic. Se la suddetta opzione è stata specificata, qualsiasi errore che normalmente è in grado di causare il ritiro del sistema causerà un processo di panic del sistema stesso. Tale operazione arresterà le comunicazioni con il cluster del nodo, causando così l'isolamento del nodo stesso.
Internamente la funzione withdraw di GFS2 richiede un invio di un messaggio da parte del kernel al demone gfs_controld che richiede la revoca. Il demone gfs_controld esegue il programma dmsetup per posizionare il target di errore del device mapper sotto il file system impedendone l'accesso al dispositivo a blocchi. Successivamente verrà indicato al kernel che questa operazione è stata completata. Questo è il motivo per il quale il requisito per il supporto del GFS2 è quello di usare sempre un dispositivo CLVM sotto il GFS2, in caso contrario non sarà possibile inserire alcun target per il device mapper.
Lo scopo di un target d'errore per il device mapper è quello di assicurare che tutte le operazioni future di I/O possano risultare in un errore I/O il quale permetterà al file system un processo di smontaggio corretto. Ne risulta che, quando si verifica un processo di revoca, sarà normale visualizzare un certo numero di errori I/O del device mapper presenti nei log del sistema.
Occasionalmente la revoca può fallire se il programma dmsetup non è in grado di inserire un target d'errore come richiesto. Ciò si può verificare se è presente memoria insufficiente al momento della revoca e quindi sarà impossibile recuperare alcuna memoria a causa del problema che ha innescato la revoca stessa.
Una revoca non indica sempre la presenza di un errore in GFS2. Talvolta la funzione withdraw può essere innescata dagli errori I/O del dispositivo per il dispositivo a blocchi sottostante. A tal proposito è fortemente consigliato controllare i log del sistema.