SDLMUX erneut betrachtet

Die SDLMUX-Software kombiniert zwei Netzwerkadapter zu einer IP-Schnittstelle und bietet eine Ausfallsicherung für den Fall, dass die Verbindung des aktiven Adapters unterbrochen wird oder der Adapter ausfällt. Nach der Einrichtung ist praktisch keine Verwaltung mehr erforderlich, aber es gibt einige Dinge, die Sie beachten sollten.

Erstens bietet SDLMUX keine Lastverteilung; der gesamte Datenverkehr wird über den aktiven Adapter gesendet und empfangen.

Zweitens hat der aktive Adapter auf der ftServer eine MAC-Adresse in der Form 00:00:A8:4v:wx:yz. Die 00:00:A8 ist die von der IEEE zugewiesene Stratus eindeutige Kennung (OUI) Stratus . Das „v“ ist ein Index, der auf der Reihenfolge basiert, in der die SDLMUX-Geräte initialisiert wurden, beginnend bei 0. Der Wert „wx:yz“ basiert auf der Seriennummer des Systems. Die Standby-Adresse unterscheidet sich von der aktiven Adresse nur im oberen Nibble des vierten Bytes, anstelle einer 4 ist es eine 6. Auch der Unterschied zwischen den MAC-Adressen von zwei aktiven (oder Standby-)Adaptern auf demselben Modul besteht nur im unteren Nibble des vierten Bytes. Der einfachste Weg, eine Liste aller MAC-Adressen zu erhalten, ist die analyze_system-Anfrage „dump_sdlmux“ mit der Übereinstimmung „MAC“, siehe Abbildung 1.

Die MAC-Adressen allein sind nicht sehr hilfreich. Durch Abgleichen mit „MAC“ oder „#“ erhalten Sie die MAC-Adressen und die Namen der SDLMUX- und Netzwerkadaptergeräte. Beachten Sie, dass diese Liste keine Netzwerkadapter enthält, die nicht Teil einer SDLMUX-Partnerschaft sind.

Drittens senden SDLMUX-Netzwerkadapter Ethernet-802.2-LLC-Frames an ihre Partner, um sicherzustellen, dass der Netzwerkpfad ordnungsgemäß funktioniert. Fünf Sätze dieser Testframes werden in Intervallen von drei Sekunden gesendet, gefolgt von einem Intervall von 33 Sekunden. Trace 1 zeigt drei Zyklen dieses Musters. Trace 1 zeigt auch den tatsächlichen Frame vom aktiven Adapter (Frame 1) und vom Standby-Adapter (Frame 2). Ich habe den Frame nach der 33-Sekunden-Pause hervorgehoben, um die Zyklen besser lesbar zu machen. Es handelt sich hierbei nicht um Ethernet-Typ-II-Frames oder IP-Pakete, und die mit den Netzwerkadaptern verbundenen Switches sowie alle Switches entlang des Pfads zwischen den beiden Adaptern müssen so konfiguriert sein, dass sie diese 802.2 LLC-Frames nicht blockieren.

Beachten Sie, dass Sie packet_monitor nicht verwenden können, um diese Testframes anzuzeigen. Die Frames werden unterhalb des Punktes gesendet, an dem packet_monitor in den Stack eingreift, und SDLMUX entfernt die Frames aus dem Stack, bevor packet_monitor sie lesen kann.

Viertens: Wenn jeder Adapter mit einem anderen Switch verbunden ist und die Verbindung zwischen diesen Switches ausfällt oder die Testframes aus einem anderen Grund nicht durchkommen, sehen Sie im syserr_log etwas, das wie Abbildung 3 aussieht. Ab den Versionen 16.2.1ak und 17.0.0ah löst SDLMUX bei einem Testframe-Fehler eine ARP-Anfrage an den letzten Host aus, der erfolgreich über die verdächtige Schnittstelle ARP-vermittelt wurde. Wenn es eine Antwort erhält, weiß es, dass der aktive Adapter funktioniert, und setzt den Standby-Adapter zurück, um zu versuchen, ihn zum Laufen zu bringen. Wenn ein Netzwerkproblem die Testframes blockiert, hilft das Zurücksetzen des Adapters nicht und der Adapter geht schließlich in den MTBF-Modus über, siehe Zeitstempel 08:08:10 in Abbildung 3. Der Befehl dlmux_admin meldet den defekten Adapter als DOWN (Abbildung 4), und eine Ablaufverfolgung zeigt keine Testframes an, da zu diesem Zeitpunkt nichts zu testen ist. Wenn keine ARP-Antwort empfangen wird oder das Problem bei einer Version auftritt, die keine ARP-Anfrage sendet, führt SDLMUX ein Failover der Adapter durch und unterbricht den neuen Standby-Adapter. Wenn während des nächsten Zyklus die Testframes erneut fehlschlagen und keine ARP-Antwort empfangen wird, werden das Failover und die Unterbrechung erneut durchgeführt. Schließlich wird ein Adapter MTBF erreichen.

Um den Adapter wieder in Betrieb zu nehmen, müssen Sie ihn mit dem Befehl board_admin erneut hinzufügen. Wenn Sie dies tun, ohne das zugrunde liegende Problem zu beheben, wird der Adapter natürlich erneut ausfallen.

Fünftens: Da der aktive Adapter immer dieselbe MAC-Adresse hat, bewirkt ein Failover, dass die MAC-Adresse von einem Switch-Port zu einem anderen verschoben wird. Alle Sicherheitseinstellungen an den Switch-Ports müssen diese Änderung zulassen. Außerdem können Switch-Ports so konfiguriert werden, dass sie mit anderen Switch-Ports kommunizieren und verschiedene Einstellungen aushandeln. Diese können ausgelöst werden, wenn der Switch eine Änderung in der Topologie feststellt, z. B. eine neue MAC-Adresse oder die Wiederherstellung einer Verbindung. Bis diese Einstellungen ausgehandelt sind, darf ein Switch keine regulären Frames weiterleiten. Die mit den SDLMUX-Adaptern verbundenen Switch-Ports sollten so konfiguriert werden, dass sie diese Verhandlungen nicht durchführen. Darüber hinaus sollten die mit den SDLMUX-Adaptern verbundenen Switch-Ports so konfiguriert werden, dass sie das Spanning-Tree-Protokoll nicht ausführen oder die Lern- und Abhörschritte überspringen (dies wird von Cisco als „Portfast“ bezeichnet). Während der Lern- und Abhörschritte leitet der Switch keine regulären Datenframes weiter. In extremen Fällen kann die durch diese Einstellungen verursachte Verzögerung so lang sein, dass SDLMUX ein weiteres Failover auslöst.

Schließlich muss der Verbindungsstatus der Adapter überwacht werden, um sicherzustellen, dass beide Verbindungen aktiv sind. Der Ausfall einer Verbindung führt nicht dazu, dass das System einen Anruf home tätigt home da es fehlertolerant ist, kommt es zu keinem Verlust der Systemkonnektivität. Ich habe dies in einem früheren Blogbeitrag behandelt, siehe Überwachen des Netzwerkadapterstatus.