Tag Archives for " HA-Cluster "

VMware ESXi – Isolationsadresse des vSphere HA Cluster ändern

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.

Ändern kann man die Isolationsadresse in den Erweiterten Optionen des HA-Clusters.

Ü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.

In den erweiterten Optionen des HA-Clusters werden die alternativen Isolations-Adressen eingetragen.

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.

Die neue Konfiguration muss noch auf den Hosts aktiviert werden.

Sophos / Astaro UTM 220 – Zeroconf failed, Permission Denied beim Aufbau eines HA-Clusters

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:

  1. Eine funktionierende UTM (aktuelles Backup vorhanden).
  2. Die zweite neue UTM wurde vorerst nur über den HA Port mit der Ersten verbunden (im Standard ETH3).
  3. Die neue UTM wurde eingeschaltet.

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.