Die HA-Funktion nutzt in vSphere die Isolationsadresse als eine Art „Witness“. Das bedeutet, wenn ein Mitglied eines HA Clusters nicht mehr mit einem anderen Mitglied des HA Clusters kommunizieren kann, kann dieses mit der Isolationsadresse feststellen, ob das Problem an ihm selbst oder an dem nicht erreichten Host liegt.
Im Standard wird die Isolationsadresse mit dem konfigurierten Standardgateway vorbelegt.
Will man die Isolationsadresse ändern, muss man in den erweiterten Optionen des HA Clusters ein paar Einträge hinzufügen.
Über die Schaltfläche Hinzufügen fügt man nun die folgenden Einträge hinzu:
das.isolationaddress1 IP-Adresse
das.isolationaddress2 IP-Adresse
das.usedefaultisolationaddress false
Mit dem Eintrag „das.usedefaultisolationaddress“ bringt man den HA-Cluster dazu nicht mehr die Standardisolationsadresse abzufragen.
Nun sollte aber mindestens eine Alternativ-Adresse angegeben werden. Die Adresse sollte aber auch von einem physischen Server sein, der ständig erreichbar ist. Ein virtueller Server, der auf einem der Host in dem HA-Cluster gehostet wird, macht in dem Fall keinen Sinn.
Sind die Einträge im HA-Cluster hinzugefügt, muss die Konfiguration auf jedem Host übernommen werden. Über das Aktionen-Menü wählt man dazu den Punkt „Für vSphere HA neu konfigurieren“ aus.
Wir sind beim Aufbau eines HA-Clusters mit zwei UTM 220 von Sophos / Astaro auf nachfolgende Probleme gestoßen, die ich hier dokumentieren möchte.
Der Cluster wurde wie folgt aufgebaut:
Nun haben wir folgende Meldung auf dem Display der neuen UTM erhalten:
Trying zeroconf
Zeroconf failed, Permission denied
Anschließend ist die UTM von allein heruntergefahren.
Im HA-Live-Protokoll der UTM wurde folgender Eintrag generiert:
Autojoin of 198.xxx.xxx.xxx denied
Bei einer Überprüfung der Konfiguration in der UTM stellte sich heraus, dass unter „Hochverfügbarkeit -> Konfiguration -> Erweitert“ bei „Automatische Konfiguration neuer Geräte aktivieren“ kein Haken gesetzt war.
Nachdem der Haken gesetzt und die neue UTM erneut eingeschaltet wurde, hat sie mit der Synchronisierung begonnen und diese auch erfolgreich abgeschlossen.
Unter Status sind nun zwei UTMs im Status Active sichtbar. Eine als Master und die andere als Slave.
Abschließend haben wir unter „Konfiguration -> Hochverfügbarkeitsstatus“ den Betriebsmodus auf „Hot-Standby (aktiv-passiv)“ geändert und unter „Erweitert“ den Haken bei „Knoten während eines Up2Date zurückhalten“ gesetzt sowie bei „Bevorzugter Master“ einen festen Knoten hinterlegt, damit die UTM nicht wahllos umschaltet.