C.3. Comportamenti comuni del cluster: Generale

Perdita di connettività nei confronti di un interruttore o impossibilità di isolare un membro

Cause comuni: Interruttori seriali per il controllo del membro scollegati. Interruttori di rete scollegati da una rete.

Comportamenti previsti: I membri controllati da un interruttore non potranno essere disabilitati o riavviati. In questo caso, se il membro è sospeso, i servizi non verranno trasferiti su di un altro membro controllato della stesso interruttore.

Verifica: Eseguire clustat per verificare che i servizi siano ancora riportati come running sul membro, anche se essi vengono riportati inactive in accordo alla membership.

Scioglimento del quorum del cluster

Cause comuni: La maggior parte dei membri del cluster (per esempio, 3 su 5), vanno off line

In caso di prova: In un cluster a 3 membri, arrestare il software del cluster su due membri.

Comportamenti previsti: Tutti i membri che non hanno interruttori di controllo esegueno un riavvio immediato. Tutti i servizi si arrestano immediatamente e il loro stato non viene aggiornato sui media condivisi (quando si esegue clustat, i lock dello stato del servizio, possono indicare che il servizio stesso sia ancora in esecuzione). I manager del servizio eseguono un abbandono. I bloccaggi del cluster vengono perduti e diventano non disponibili.

Verifica: Eseguire clustat su uno dei membri attivi restanti.

Il membro perde lo stato di partecipante nel quorum del cluster, ma non è sospeso

Cause comuni: Perdita totale di connettività con gli altri membri.

In caso di prova: Scollegare tutti i cavi di rete da un membro del cluster.

Comportamento previsto: Se il membro non ha alcun interruttore di controllo, eseguirà un riavvio immediato. Alternativamente, cercherà di arrestare i servizi il più velocemente possibile. Se esiste un quorum, l'insieme di membri compresi nel quorum del cluster, isolerà il membro.

arresto di clumembd

In caso di prova: killall -KILL clumembd

Comportamento previsto: Riavvio del sistema.

sospensione di clumembd, watchdog in uso

In caso di prova: killall -STOP clumembd

Comportamento previsto: Si può verificare il riavvio del sistema se clumembd è sospeso per un periodo maggiore di (failover_time - 1) secondi. Azionato esternamente dal timer watchdog.

sospensione di clumembd, nessun watchdog in uso

In caso di prova: killall -STOP clumembd

Comportamento previsto: Si può verificare il riavvio del sistema se clumembd è sospeso per un periodo maggiore di (failover_time) secondi. Azionato internamente da clumembd.

interruzione di cluquorumd

In caso di prova: killall -KILL cluquorumd

Comportamento previsto: Riavvio del sistema.

interruzione di clusvcmgrd

In caso di prova: killall -KILL clusvcmgrd

Comportamento previsto: cluquorumd rigenera clusvcmgrd, il quale esegue la fase di arresto per tutti i servizi. I servizi che sono stati arrestati vengono riavviati.

Verifica: Consultare i log del sistema per la verifica di un messaggio di avviso proveniente da cluquorumd.

interruzione di clulockd

In caso di prova: killall -KILL clulockd

Comportamente previsto: cluquorumd rigenera clulockd. I lock potrebbero essere non disponibili (evitando il passaggio del servizio), per un breve periodo di tempo.

Verifica: Consultare i log del sistema per la verifica di un messaggio di avviso proveniente da cluquorumd.

Riavvio del sistema non previsto senza un arresto corretto dei servizi del cluster

Cause comuni: Qualsiasi scenario capace di causare un riavvio del sistema.

In caso di prova: reboot -fn; premendo il pulsante reset.

Comportamento previsto: Se un interruttore controlla il membro in questione che stà per eseguire l'avvio, il sistema verrà isolato (generalmente, si verificherà una procedura power-cycle) se esiste il quorum del cluster.

Perdita del quorum durante uno spegnimento corretto

In caso di prova: Arrestare i servizi del cluster (service clumanager stop) su tutti i membri.

Comportamento previsto: Qualsiasi servizio restante verrà arrestato in modo non corretto.

Verifica: Consultare le registrazioni del sistema in cerca di messaggi d'avviso.

Operazione di isolamento STONITH positiva

Comportamento previsto: I servizi presenti sul membro isolato, vengono avviati, se possibile, in un'altra posizione.

Verifica: Verificare che i servizi sono stati, di fatto, avviati dopo aver isolato il membro. Questa operazione richiede pochi secondi.

Operazione di isolamento del membro del cluster negativa

Cause comuni: L'interruttore ritorna una condizione d'errore, oppure non è raggiungibile.

In caso di prova: Scollegare l'interruttore che controlla un membro, ed eseguire reboot -fn sul membro stesso.

Comportamento previsto: I servizi del membro non isolato, non vengono avviati, in alcun luogo, nel cluster. Se il membro recupera le sue funzioni, i servizi presenti sul cluster verranno riavviati. Poichè non vì è alcun modo per controllare lo stato del membro, si presume che esso sia ancora in esecuzione anche se gli heartbeat sono stati fermati. In questo modo, tutti i servizi dovrebbero essere riportati come se fossero in esecuzione sul membro sospeso.

Verifica: Eseguire clustat, in modo da verificare che i servizi vengono riportati come se fossero in esecuzione sul membro, anche se lo stesso membro viene riportato come non attivo dalla membership. Verranno registrati così alcuni messaggi che indicano lo stato PANIC del membro.

Errore nella lettura da una delle pertizioni condivise

In caso di prova: Eseguire dd per registrare gli zero sulla partizione condivisa

	    
dd if=/dev/zero of=/dev/raw/raw1 bs=512 count=1
shutil -p /cluster/header

Comportamento previsto: L'event viene registrato. Vengono copiati i dati dalla partizione condivisa migliore su quella che riporta gli errori

Verifica: Una seconda lettura degli stessi dati non dovrebbe riportare alcun messaggio d'errore.

Errore durante la lettura da entrambe le partizioni condivise

Cause comuni: Il media condiviso potrebbe essere non raggiungibile oppure si è verificata una corruzione dei dati su entrambe le partizioni.

In caso di prova: Disinserire SCSI o il cavo Fibre Channel da un membro.

Comportamento previsto: L'event viene registrato. L'azione configurata deve risolverela pardita d'accesso sulla memoria condivisa (reboot/halt/stop/ignore). L'azione di default è quella del riavvio