Testen der virtuellen IP-Adresse eines SafeKit Mirror-Cluster in Ihrem Netzwerk

Diese Anleitung beschreibt, wie Sie überprüfen, ob die virtuelle IP-Adresse (VIP) eines SafeKit Mirror-Cluster (mirror) in Ihrem Netzwerk korrekt funktioniert: Die virtuelle IP (VIP) wird vom primären Server gehalten und nach einem Failover auf den neuen primären Server umgeleitet.

1. Grundprinzipien

Voraussetzung: Beide Knoten des Mirror-Cluster müssen sich im selben Layer-2-IP-Subnetz befinden: einem LAN oder einem VLAN, das zwischen entfernten Standorten erweitert wird.

• Die virtuelle IP (VIP) ist nur auf dem primären Server aktiv (Zustände PRIM oder ALONE): Sie wird als Alias der physischen IP-Adresse auf der Netzwerkkarte dieser Adresse festgelegt, wenn das Modul als primäres Modul auf dem Knoten startet (Konfiguration where="one_side_alias").
• Die MAC-Adresse des primären Servers ist daher diejenige, die in den ARP-Tabellen (Router, Gateway, Clients im selben Subnetz) der virtuellen IP-Adresse (VIP) zugeordnet ist. Der gesamte Datenverkehr an die virtuelle IP-Adresse (VIP) wird an den primären Server gesendet.
• Während eines Failovers (Stopp oder Ausfall des Primärsystems) wird die virtuelle IP (VIP) vom ehemaligen Primärsystem entfernt und als Alias auf dem neuen Primärsystem festgelegt. Zwei Mechanismen ermöglichen es dem Netzwerk dann, die virtuelle IP (VIP) mit der MAC-Adresse des neuen Primärsystems zu verknüpfen:
  • die vom Betriebssystem gesendeten Netzwerknachrichten, wenn die virtuelle IP-Adresse (VIP) als Alias auf der Netzwerkkarte hinzugefügt wird;
  • die GARPs (Gratuitous ARP), die von SafeKit gesendet werden, wenn das Attribut arpreroute="on" im Abschnitt <vip> konfiguriert ist.

Was Sie daher testen müssen:

1. Die virtuelle IP-Adresse (VIP) wird vom primären Server gehalten und ist von den Clients aus erreichbar;
2. Die mit der virtuellen IP-Adresse (VIP) verknüpfte MAC-Adresse wird an den neuen Primärserver im Netzwerk (Router, Gateway, Virtualisierung) umgeleitet, wenn sich der Primärserver ändert.

2. Voraussetzung: Konfiguration der virtuellen IP (VIP)

1. Konfigurieren Sie in der userconfig.xml des mirror die virtuelle IP (VIP) im Abschnitt <vip>. Das Attribut arpreroute="on" bewirkt, dass der neue Primärserver nach einem Failover GARPs sendet:

   <vip>
     <interface_list>
       <interface arpreroute="on">
         <real_interface>
           <virtual_addr addr="<VIP>" where="one_side_alias"/>
         </real_interface>
       </interface>
     </interface_list>
   </vip>
   

2. Wenden Sie die Konfiguration auf beiden Knoten an.

3. Starten Sie das Modul: Ein Knoten muss PRIM (Ready) und der andere SECOND (Ready) sein.

3. Test 1 – Virtuelle IP-Adresse (VIP), die vom primären Server gehalten wird

Schritte

1. Führen Sie auf dem primären Server ipconfig (Windows) oder ip addr show (Linux) aus. → Erwartetes Ergebnis: Die virtuelle IP-Adresse (VIP) wird als Alias auf der Netzwerkkarte der physischen IP-Adresse angezeigt.
2. Führen Sie auf dem sekundären Server denselben Befehl aus. → Erwartetes Ergebnis: Die virtuelle IP-Adresse (VIP) wird nicht angezeigt.
3. ping von einem Client-Arbeitsplatz außerhalb des Clusters sowohl die physischen IP-Adressen als auch die virtuelle IP-Adresse (VIP) an. → Erwartetes Ergebnis: Alle drei ping Befehle antworten (sofern sie nicht von Firewalls gefiltert werden).
4. Überprüfen Sie den Zugriff über die virtuelle IP (VIP) mit SafeKit-Mosaik: Verbinden Sie sich von einem Browser auf dem externen Client mit http://<VIP>:9010/safekit/mosaic.html (oder verwenden Sie Port 9453, wenn der SafeKit-Webserver und die Konsole auf HTTPS umgestellt wurden), geben Sie dann den Namen des Spiegelmoduls mirror und führen Sie den Test aus. → Erwartetes Ergebnis: Alle Zellen des Mosaik Displays zeigen den Namen des primären Servers in einer einzigen Farbe an: Alle TCP-Verbindungen zur virtuellen IP (VIP) werden vom primären Server bedient.

4. Test 2 – Manuelle Fehlerübernahme (Stoppen des Primärsystems)

Dieser Test prüft, ob die virtuelle IP-Adresse (VIP) dem primären Server bei einem Failover folgt, das durch das Stoppen des Moduls auf dem primären Server ausgelöst wird.

Schritte

1. Stoppen Sie das Modul auf dem primären Knoten (Knoten 1) über die SafeKit-Konsole (oder über die Befehlszeile mit safekit stop -m <module>). → Erwartetes Ergebnis: Knoten 1 wechselt in den STOP (NotReady) und Knoten 2 wechselt in ALONE (Ready). Im Protokoll des neuen Primärknotens erscheint die Meldung Virtual IP <VIP> set.
2. Führen Sie auf der neuen primären Schnittstelle ipconfig oder ip addr show aus. → Erwartetes Ergebnis: Die virtuelle IP (VIP) wird nun als Alias auf diesem Knoten und nicht mehr auf dem ehemaligen primären Knoten angezeigt.
3. Wiederholen Sie von der Client-Workstation aus die drei ping-Befehle und führen Sie Mosaik erneut auf der virtuellen IP-Adresse (VIP) aus. → Erwartetes Ergebnis: Alles reagiert, und alle Zellen des Mosaik zeigen nun den Namen des neuen Primärfarbtons in einer einzigen Farbe an.
4. Starten Sie das Modul auf Knoten 1 neu: Es wird erneut synchronisiert und wechselt in den SECOND (Ready), während Knoten 2 in den PRIM (Ready) wechselt.

5. Test 3 – Überprüfung der MAC-Umleitung mit arp -a

Notieren Sie die MAC-Adresse, die der virtuellen IP-Adresse (VIP) zugeordnet ist, vor dem Failover und prüfen Sie anschließend, ob sie sich geändert hat.

Dieser Test ist nur möglich, wenn sich die Client-Workstation im selben IP-Subnetz wie der Cluster befindet.

Wenn sich ein Router zwischen dem Client und dem Cluster befindet, enthält die ARP-Tabelle des Clients nicht die virtuelle IP (VIP), sondern die Adresse des Gateways, das zum Erreichen des Cluster-Netzwerks verwendet wird. In diesem Fall überprüfen Sie die ARP-Tabelle des Routers oder Gateways mit dem Netzwerkteam.

Schritte

1. Das Modul ist PRIM (Ready) auf Knoten 1 und SECOND (Ready) auf Knoten 2.
2. ping auf der Client-Workstation sowohl die physischen IP-Adressen als auch die virtuelle IP-Adresse (VIP) an und führen Sie dann arp -a aus. → Erwartetes Ergebnis: Die virtuelle IP-Adresse (VIP) ist mit derselben MAC-Adresse wie die physische IP-Adresse des primären Geräts verknüpft.
3. stop das Modul auf dem primären Knoten (Knoten 1).
4. ping die virtuelle IP-Adresse (VIP) erneut an und führen Sie dann erneut arp -a aus. → Erwartetes Ergebnis: Die virtuelle IP-Adresse (VIP) ist jetzt mit derselben MAC-Adresse wie die physische IP-Adresse des neuen Primärsystems verknüpft.

ping die virtuelle IP-Adresse (VIP) erneut an, bevor Sie die ARP-Tabelle lesen: Der Eintrag kann als veraltet markiert sein und wird erst nach einem ping aktualisiert.

Beispiel der erwarteten ARP-Tabelle vor und nach dem Stoppen des Primärsystems:

6. Test 4 – End-to-End-Prüfung mit Wireshark (Windows) oder tcpdump (Linux)

Sie können eine TCP-Verbindung zur virtuellen IP (VIP) verfolgen, indem Sie Pakete auf dem Client und auf beiden Knoten erfassen: mit Wireshark auf Windows-Rechnern und mit tcpdump auf Linux-Rechnern.

Sie müssen die MAC-Header (Ethernet) der Pakete betrachten: Die Ziel-IP-Adresse bleibt die virtuelle IP (VIP), und es ist die Ziel-MAC-Adresse, die anzeigt, welcher Knoten den Datenverkehr empfängt.

Was Sie beachten sollten:

Wenn sich die Client-Workstation in einem anderen Subnetz als der Cluster befindet, ist die auf den Knoten angezeigte „Client-MAC“ die MAC-Adresse des Gateways (Routers), das die beiden Subnetze verbindet, und nicht die der Client-Workstation.

7. Von welchen Arbeitsplätzen aus testen?

Das Verhalten hängt vom Netzwerkpfad zwischen dem Client und dem Cluster ab. Führen Sie die Tests 1 und 2 von jedem für Ihre Architektur relevanten Client-Typ aus:

8. Zusammenfassung der erwarteten Ergebnisse

9. Fehlerbehebung

• Die virtuelle IP (VIP) reagiert nach dem Failover nicht mehr: MAC-Umleitungsnachrichten werden von einem Gerät auf dem Pfad (Router, Gateway, virtueller Switch) nicht berücksichtigt, das weiterhin Datenverkehr an die MAC-Adresse des ehemaligen Primärsystems sendet. Überprüfen Sie die Behandlung von MAC-Umleitungsnachrichten mit Ihrem Netzwerkteam.
• Senden von GARPs: Das Attribut arpreroute="on" des Abschnitts <vip> (mit arpinterval und arpelapse) sendet nach dem Failover regelmäßig GARPs an die virtuelle IP (VIP). Siehe Benutzerhandbuch, Abschnitt 13.6.4 „ <vip>-Syntax “.
• Diagnose der Auflösung von virtuellen IP-Adressen (VIP) ↔ MAC-Adressen: Siehe Benutzerhandbuch, Abschnitt 7.24 „ Fehlerbehebung bei der Auflösung von virtuellen IP-Adressen (VIP) ↔ MAC-Adressen “ und Abschnitt 7.16 „ Problem mit der virtuellen IP-Adresse nach Failover “.

Für weitere Informationen:

• Wie funktioniert eine virtuelle IP-Adresse in einem Hochverfügbarkeits-Cluster?
• Informationen zum Lastenausgleich mit einer virtuellen IP-Adresse finden Sie unter Testen der virtuellen IP-Adresse für den Lastenausgleich in einem SafeKit Farm-Cluster.