Neulich wurde mir bei einer Diskussion mit einigen Anwendern klar, dass sie nicht verstanden haben, unter welchen Bedingungen ein Stratus VSeries System home bezüglich eines Netzwerkadapters aufrufen würde. Dieses Mißverständnis führte dazu, daß das System seine Netzwerkverbindung verlor. Wenn sie es nicht verstanden haben, bin ich mir sicher, dass es auch andere gibt, die es nicht verstanden haben, und so wird dieser Blog versuchen zu erklären, wann ein System home bezüglich eines Netzwerkadapters aufruft.
Die einfache Antwort ist, dass das System home aufruft, wenn es feststellt, dass der Netzwerkadapter ausgefallen ist. Die Grauzone ist, was "ausgefallen" bedeutet. Wenn der Adapter kaputt geht oder vom System kaputt gemacht wird, wird eine Reihe von Diagnosen durchgeführt, und wenn der Adapter besteht, wird er wieder in Betrieb genommen. Wenn der Adapter zu oft in einem zu kurzen Zeitintervall kaputt geht, überschreitet er den MTBF-Schwellenwert (Mean Time Between Failure) und wird außer Betrieb gesetzt. In diesem Fall ruft das System home bezüglich des Adapters auf. Wenn die Diagnose läuft und fehlschlägt, bleibt der Adapter außer Betrieb und das System ruft home auf.
Wenn die sdlmux-Testnachrichten, die zwischen den aktiven und den Standby-Netzwerkadapterpartnern ausgetauscht werden, vom Partneradapter nicht empfangen werden können, unterbricht das System die Standby-Karte, testet sie und nimmt sie wieder in Betrieb. Wenn das Problem, das die Testnachrichten blockiert hat, nicht behoben wird, wiederholt sich dieses Muster, bis die Karte die MTBF-Schwelle überschreitet und das System home aufruft. Beachten Sie hier, dass das Problem möglicherweise nicht der Adapter, sondern das Netzwerk ist.
Wenn eine Verbindung unterbrochen wird, so dass ein Adapter nicht mehr mit dem Netzwerk verbunden ist, übernimmt das System die Netzwerkadapter nach Bedarf und unternimmt nichts weiter. Es wird nicht home aufrufen. Der Grund dafür ist, dass es zu viele Gründe für einen Verbindungsabbruch gibt, die fast alle außerhalb des Adapters liegen. Vor zweiundzwanzig Jahren, in der VOS-Version 8.0, rief die ursprüngliche Stratus Ethernet-Implementierung home auf, wenn eine Verbindung unterbrochen wurde. Dies führte dazu, dass viele Probleme geöffnet wurden, was die Leute nur verärgerte, wenn wir sie zurückriefen, da sie wussten, dass sie einen Switch neu gestartet oder ein Kabel entfernt hatten. Damals wurde beschlossen, dass ein verlorener Link nicht als Fehler gewertet werden sollte. Beachten Sie, dass die im vorigen Absatz erwähnten sdlmux-Testmeldungen nur dann gesendet werden, wenn beide Adapter eine Verbindung zu einem Netzwerk haben.
Was geschah mit den im ersten Absatz erwähnten Benutzern? Vor etwa einem Monat verloren sie die Verbindung zu einem Adapter. Sie waren sich dessen nicht bewusst, da das System keine Verbindungsprobleme hatte. Vor ein paar Tagen verloren sie dann die andere Verbindung, und zu diesem Zeitpunkt waren sie nicht mehr im Netz. Dieses Szenario zeigt, warum es wichtig ist, die Adapter in Ihrem System zu überwachen, um sicherzustellen, dass sie mit dem Netzwerk verbunden sind. Eine regelmäßige Überwachung hätte das Problem mit der Verbindung des ersten Adapters rechtzeitig erkannt, um es zu beheben, bevor das Problem mit der Verbindung des zweiten Adapters auftrat.
Das Befehlsmakro monitor_sdlmux_adapter_status (Abbildung 1) überwacht in regelmäßigen Abständen alle mit sdlmux verbundenen Partneradapter. Es sendet eine 25-zeilige Nachricht an ausgewählte Benutzer und fügt einen Eintrag in das syserr_log hinzu. Ein syserr_log-Eintrag wird erstellt, wenn die Verbindung zum ersten Mal unterbrochen wird, aber das Makro monitor_sdlmux_adapter_status fügt bei jeder Überprüfung einen Eintrag hinzu, was die Wahrscheinlichkeit erhöht, dass es gesehen wird (Abbildung 2). Das Makro sollte als gestarteter Prozess mit der Einstellung -privileged auf yes ausgeführt werden, da es analyze_system aufruft, um die Liste der sdlmux-Geräte zu erhalten.
Das Makro prüft auch, ob einer der Adapter "DOWN" ist, und meldet dies auf die gleiche Weise wie eine unterbrochene Verbindung. Das System hätte home aufrufen sollen, aber es war einfach, die Prüfung hinzuzufügen, und ich dachte mir, dass die zusätzliche Benachrichtigung nicht schaden kann.
Die 25. Zeile und die syserr_log-Meldungen verweisen auf die Datei check_adapters im Verzeichnis home desjenigen, der das Makro monitor_sdlmux_adapter_status ausführt. Diese Datei besteht aus der Ausgabe des Befehls dlmux_admin sdlmux_status, der für jede sdlmux-Partnerschaft im System ausgeführt wird (Abbildung 3). Sie müssen sich diese Datei ansehen, um den oder die spezifischen Adapter mit einem Problem zu identifizieren.
Das Makro betrachtet nur Adapter, die mit sdlmux gepaart wurden. Probleme mit Adaptern, die nicht mit sdlmux verbunden sind, sind sofort erkennbar, so dass keine zusätzliche Überwachung erforderlich ist. Beachten Sie, dass Stratus empfiehlt, dass alle Netzwerkadapter mit sdlmux verbunden werden.
& monitor_sdlmux_adapter_status begins here |
Abbildung 1 - das Befehlsmakro 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. . . . . . . . . |
Abbildung 2 - syserr_log-Meldungen
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 |
Abbildung 3 - Ausgabe der Datei check_adapters zeigt, dass #enetA.m16.10-5-0 die Verbindung verloren hat