L'altro giorno, durante una discussione con alcuni utenti, mi è apparso chiaro che non capivano in quali condizioni un sistema Stratus avrebbe effettuato una chiamata home un adattatore di rete. Questo malinteso ha causato la perdita della connessione di rete da parte del sistema. Se loro non lo capivano, sono sicuro che ci sono anche altri che non lo capiscono, quindi questo blog cercherà di spiegare quando un sistema effettua una chiamata home un adattatore di rete.
La risposta semplice è che il sistema chiamerà home rileva che l'adattatore di rete non funziona. La zona grigia è cosa significa non funziona. Se la scheda si guasta o viene danneggiata dal sistema, viene eseguita una serie di test diagnostici e, se la scheda supera i test, viene rimessa in servizio. Se si guasta troppe volte in un intervallo di tempo troppo breve, la scheda supererà la soglia MTBF (Mean Time Between Failure, tempo medio tra i guasti) e rimarrà fuori servizio. In tal caso, il sistema chiamerà home della scheda. Se i test diagnostici vengono eseguiti e falliscono, la scheda rimane fuori servizio e il sistema chiamerà home.
Se i messaggi di test sdlmux, che vengono trasmessi tra i partner della scheda di rete attiva e di riserva, non vengono ricevuti dalla scheda partner, il sistema interromperà il funzionamento della scheda di riserva, la testerà e la rimetterà in servizio. Se il problema che ha bloccato i messaggi di test non viene risolto, questo schema si ripeterà fino a quando la scheda non supererà la soglia MTBF e il sistema chiamerà home. Si noti che il problema potrebbe non essere la scheda, ma la rete.
Se un collegamento si interrompe, in modo tale che un adattatore non sia più connesso alla rete, il sistema eseguirà il failover degli adattatori di rete secondo necessità e non farà nient'altro. Non chiamerà home. Il motivo è che ci sono troppe ragioni, quasi tutte esterne all'adattatore, per cui il collegamento può interrompersi. Ventidue anni fa, nella versione 8.0 di VOS, l'implementazione originale Stratus chiamava home si perdeva un collegamento. Ciò ha portato all'apertura di molte segnalazioni, che hanno solo infastidito le persone quando le abbiamo richiamate, poiché sapevano di aver riavviato uno switch o rimosso un cavo. All'epoca si decise che la perdita di un collegamento non sarebbe stata considerata un guasto. Si noti che i messaggi di test sdlmux menzionati nel paragrafo precedente non vengono inviati a meno che entrambi gli adattatori non abbiano un collegamento a una rete.
Cosa è successo agli utenti citati nel paragrafo iniziale? Circa un mese fa hanno perso il collegamento a un adattatore. Non se ne sono accorti perché il sistema non presentava problemi di connettività. Poi, qualche giorno fa, hanno perso anche l'altro collegamento e a quel punto sono rimasti fuori dalla rete. Questo scenario dimostra perché è importante monitorare gli adattatori sul proprio sistema per verificare che siano collegati alla rete. Un monitoraggio periodico avrebbe identificato il problema con il collegamento del primo adattatore in tempo per correggerlo prima che si verificasse il problema con il collegamento del secondo adattatore.
Il comando macro monitor_sdlmux_adapter_status (figura 1) monitorerà periodicamente tutti gli adattatori associati sdlmuxed. Invierà un messaggio alla 25ª riga agli utenti selezionati e aggiungerà una voce nel syserr_log. Una voce nel syserr_log viene creata quando il collegamento viene perso per la prima volta, ma la macro monitor_sdlmux_adapter_status ne aggiungerà una ogni volta che esegue il controllo, rendendola più visibile (figura 2). La macro deve essere eseguita come processo avviato con -privileged impostato su yes, poiché chiama analyze_system per ottenere l'elenco dei dispositivi sdlmux.
La macro verifica anche se uno degli adattatori è "DOWN" e lo segnala allo stesso modo in cui segnala un collegamento interrotto. Il sistema avrebbe dovuto chiamare home è stato facile aggiungere il controllo e ho pensato che una notifica in più non potesse nuocere.
La riga 25 e i messaggi syserr_log rimandano al file check_adapters nella home di chiunque stia eseguendo la macro monitor_sdlmux_adapter_status. Tale file è costituito dall'output del comando dlmux_admin sdlmux_status eseguito su ogni partnership sdlmux presente nel sistema (figura 3). Sarà necessario esaminare tale file per identificare gli adattatori specifici che presentano un problema.
La macro esamina solo gli adattatori che sono stati associati a sdlmux. I problemi relativi agli adattatori che non sono stati associati sono immediatamente evidenti, quindi non è necessario alcun monitoraggio aggiuntivo. Si noti che Stratus che tutti gli adattatori di rete siano associati a sdlmux.
& monitor_sdlmux_adapter_status begins here |
Figura 1 – La macro di comando monitor_sdlmux_adapter_status
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 – Output del file check_adapters che mostra che #enetA.m16.10-5-0 ha perso il collegamento