L'altro giorno, durante una discussione con alcuni utenti, mi è apparso chiaro che non capivano a quali condizioni un sistema VSeries Stratus chiamerebbe home per quanto riguarda una scheda di rete. Questo malinteso ha fatto sì che il sistema perdesse la connessione di rete. Se non hanno capito, sono sicuro che ce ne sono altri che non lo capiscono, e quindi questo blog cercherà di spiegare quando un sistema chiamerà home riguardo ad una scheda di rete.
La risposta semplice è che il sistema chiamerà home quando rileverà che la scheda di rete è guasta. L'area grigia è ciò che significa "fallito". Se l'adattatore si rompe o è rotto dal sistema viene eseguito un set di diagnostica, e se l'adattatore passa viene rimesso in servizio. Se si rompe troppe volte in un intervallo di tempo troppo breve, l'adattatore supera la soglia MTBF (Mean Time Between Failure) e rimane fuori servizio. Se ciò accade, il sistema chiamerà home per quanto riguarda l'adattatore. Se la diagnostica funziona e si guasta, l'adattatore rimane fuori servizio e il sistema chiama home.
Se i messaggi di test sdlmux, che vengono passati tra i partner della scheda di rete attiva e quelli della scheda di rete di standby, non vengono ricevuti dall'adattatore partner, il sistema rompe la scheda di standby, la prova e la rimette in servizio. Se qualsiasi cosa abbia bloccato i messaggi di test non viene risolta, questo schema si ripeterà fino a quando la scheda non supera la soglia MTBF e il sistema chiamerà home. Si noti qui che il problema potrebbe non essere l'adattatore, ma la rete.
Se un collegamento si interrompe, in modo che un adattatore non sia più collegato alla rete, il sistema si bloccherà sugli adattatori di rete in caso di necessità e non farà nient'altro. Non chiamerà home. Il motivo è che ci sono troppe ragioni, quasi tutte esterne all'adattatore, perché il link cada. Ventidue anni fa nella versione 8.0 di VOS l'implementazione originale di Ethernet Stratus ha chiamato home quando un link è andato perso. Il risultato è stato l'apertura di molti problemi, che hanno solo dato fastidio alle persone quando le abbiamo richiamate, poiché sapevano di aver riavviato uno switch o rimosso un cavo. Si decise allora che un link perso non sarebbe stato considerato un fallimento. Si noti che i messaggi di test sdlmux di cui al paragrafo precedente non vengono inviati a meno che entrambi gli adattatori non abbiano un collegamento ad una rete.
Cosa è successo agli utenti citati nel paragrafo di apertura? Circa un mese fa hanno perso il link ad un adattatore. Non ne erano consapevoli perché il sistema non aveva problemi di connettività. Poi qualche giorno fa hanno perso l'altro collegamento e a quel punto erano fuori dalla rete. Questo scenario dimostra perché è importante monitorare gli adattatori del sistema per confermare che sono collegati alla rete. Un monitoraggio periodico avrebbe identificato il problema con il primo collegamento dell'adattatore in tempo per correggerlo prima che si verificasse il problema con il secondo collegamento dell'adattatore.
Il comando macro monitor_sdlmux_adapter_status (figura 1) monitorerà periodicamente tutti gli adattatori partner sdlmuxed. Invierà un messaggio a 25 righe agli utenti selezionati e aggiungerà una voce nel syserr_log. Una voce nel syserr_log viene effettuata quando il link viene perso per la prima volta, ma la macro monitor_sdlmux_adapter_status ne aggiungerà una ogni volta che controlla rendendola più visibile (figura 2). La macro dovrebbe essere eseguita come un processo avviato con -privilegiato impostato a yes poiché chiama analyze_system per ottenere la lista dei dispositivi sdlmux.
La macro controlla anche se uno degli adattatori è "DOWN" e lo segnala nello stesso modo in cui segnala un link abbandonato. Il sistema avrebbe dovuto chiamare home ma è stato facile aggiungere il controllo e ho pensato che la notifica extra non può far male.
La 25a riga e i messaggi syserr_log rimandano al file check_adapter nel file home dir di chi sta eseguendo la macro monitor_sdlmux_adapter_status. Tale file è costituito dall'output del comando dlmux_admin sdlmux_status eseguito contro ogni partnership sdlmux sul sistema (figura 3). Sarà necessario rivedere quel file per identificare l'adattatore o gli adattatori specifici con un problema.
La macro guarda solo agli adattatori che sono stati accoppiati con sdlmux. I problemi con gli adattatori che non sono stati accoppiati sono immediatamente evidenti, quindi non è necessario un monitoraggio supplementare. Si noti che Stratus raccomanda che tutti gli adattatori di rete siano associati a sdlmux.
& monitor_sdlmux_adapter_status begins here |
Figura 1 - il comando monitor_sdlmux_adapter_status macro
d >system>syserr_log.10-05-24 -match check_adapters%phx_vos#m16_mas>system>syserr_log.10-05-24 10-05-25 08:27:29 mst. . . . . . . . . |
Figura 2 - messaggi syserr_log
d check_adapters%phx_vos#m16_mas>SysAdmin>Noah_Davids>check_adapters 10-05-24 19:57:43 mst**************************************************--------------- 10-05-24.19:56:47 ----------------****************************************************************************************************Group Name: #sdlmuxA.m16.10-5-0.11-5-0Device Name: %phx_vos#enetA.m16.11-5-0Adapter State: ACTIVE UPPartner: %phx_vos#enetA.m16.10-5-0Partner State: UP (network connection lost)**************************************************Group Name: #sdlmuxA.m16.10-5-1.11-5-1Device Name: %phx_vos#enetA.m16.10-5-1Adapter State: ACTIVE UPPartner: %phx_vos#enetA.m16.11-5-1Partner State: UP**************************************************Group Name: #sdlmux.m16.11-2Device Name: %phx_vos#enet.m16.11.11-2Adapter State: ACTIVE UPPartner: %phx_vos#enet.m16.10.11-2Partner State: UP**************************************************Group Name: #sdlmux.m16.11-3Device Name: %phx_vos#enet.m16.10.11-3Adapter State: ACTIVE UPPartner: %phx_vos#enet.m16.11.11-3Partner State: UPready 19:57:43 |
Figura 3 - uscita del file check_adapter che mostra #enetA.m16.10-5-0 ha perso il link
