Die Hochverfügbarkeitsfunktion (HA) in vSphere bedient sich der Isolationsadresse als eine Art „Witness“ bzw. „Zeugen“. Sollte ein Mitglied eines HA-Clusters nicht mehr mit einem anderen kommunizieren können, dient die Isolationsadresse dazu zu ermitteln, ob das Problem am betroffenen Mitglied selbst liegt oder am nicht erreichbaren Host.
Standardmäßig wird die Isolationsadresse mit dem konfigurierten Standardgateway vorbelegt. Wenn jedoch die Isolationsadresse angepasst werden soll, sind einige Einträge in den erweiterten Optionen des HA-Clusters erforderlich.
Um die Isolationsadresse zu ändern, müssen die folgenden Einträge über die Schaltfläche „Hinzufügen“ ergänzt werden:
Durch den Eintrag „das.usedefaultisolationaddress“ wird der HA-Cluster angewiesen, nicht länger die Standardisolationsadresse abzufragen.
Allerdings sollte nun mindestens eine Alternativ-Adresse angegeben werden. Diese Adresse sollte von einem physischen Server stammen, der kontinuierlich erreichbar ist. Ein virtueller Server, der auf einem der Hosts im HA-Cluster gehostet wird, ist in diesem Fall nicht sinnvoll.
Sobald die Einträge im HA-Cluster hinzugefügt wurden, müssen die Konfigurationen auf jedem Host übernommen werden. Hierfür wählt man über das Aktionen-Menü den Punkt „Für vSphere HA neu konfigurieren“ aus.
Dadurch werden die Änderungen auf alle beteiligten Hosts angewendet, was entscheidend ist, um sicherzustellen, dass das HA-Cluster einwandfrei funktioniert und die Hochverfügbarkeit der virtuellen Maschinen gewährleistet ist. Diese sorgfältige Vorgehensweise ist von wesentlicher Bedeutung für die Stabilität und Leistungsfähigkeit des Clusters und somit für die Geschäftskontinuität.
Nachdem wir den Aufbau eines Hochverfügbarkeitsclusters mit zwei UTM 220 von Sophos / Astaro begonnen hatten, stießen wir auf einige Probleme, die es wert sind, hier ausführlicher dokumentiert zu werden.
Zunächst wurde der Cluster gemäß den folgenden Schritten eingerichtet:
„Trying zeroconf. Zeroconf failed, Permission denied.“
Kurz darauf fuhr die UTM unerwartet herunter.
Im HA-Live-Protokoll der UTM wurde der folgende Eintrag generiert:
„Autojoin of 198.xxx.xxx.xxx denied“.
Bei einer gründlichen Überprüfung der Konfiguration in der UTM stellte sich heraus, dass unter „Hochverfügbarkeit -> Konfiguration -> Erweitert“ kein Haken bei „Automatische Konfiguration neuer Geräte aktivieren“ gesetzt war.
Um das Problem zu beheben, wurde dieser Haken gesetzt, und die neue UTM wurde erneut eingeschaltet. Dieses Mal begann sie erfolgreich mit der Synchronisierung und schloss diesen Vorgang ohne Probleme ab.
In der Statusanzeige waren nun zwei UTMs im Status „Active“ sichtbar, wobei eine als Master und die andere als Slave fungierte.
Um die Konfiguration weiter zu verfeinern und die Stabilität des Clusters zu verbessern, wurden zusätzliche Maßnahmen ergriffen:
Diese zusätzlichen Konfigurationsschritte wurden unternommen, um eine zuverlässige und robuste Hochverfügbarkeitslösung für das Netzwerk zu gewährleisten. Nach deren Implementierung waren die UTMs erfolgreich in Betrieb und sorgten für eine kontinuierliche Verfügbarkeit der Netzwerkdienste.