#acl hayd@cbs.mpg.de:read,write,delete,revert,admin Known:read,write All:read = Proxmox High-Availablility = <> Um ein [[https://pve.proxmox.com/wiki/High_Availability|High-Availability-Cluster (HA-Cluster)]] zu bilden werden mindestens drei Knoten (Quorum) in einem [[https://wiki.init.mpg.de/IT4Science/ProxmoxCluster|Cluster]] benötigt. Wie bei einem Cluster ohne HA-Fähigkeit findet hier die Kommunikation über [[https://corosync.github.io/corosync/|Corosync]] statt. == Vorraussetzung == * [[https://wiki.init.mpg.de/IT4Science/ProxmoxCluster|Cluster]] aus mindestens drei Knoten * Shared Storage als ausfallsicherer gemeinsamer Speicher für die Gastsysteme * Hardwareredundanz * Watchdogs (Hardware oder Software) == Einrichten übers Web-Interface == * Datacenter -> HA -> Groups -> Create * einzigartige Gruppen-ID vergeben (einzigartig, da sie das Unterscheidungsmerkmal der bei mehreren Gruppen ist), Auswahl der Knoten mit Prioritäten (Bei Ausfall werden die Knoten mit der höchsten Priorität ausgewählt und unter mehreren Knoten mit gleicher Priorität fällt die Wahl auf den Knoten mit weniger Workload.) * optionale Checkboxen: * restricted: Gast läuft nur auf Knoten bestimmter Gruppen und befindet sich im stopped state falls keiner der in der Gruppe befindlichen Knoten online ist * nofailback: Gast wird normalerweise auf den Knoten mit höherer Priorität migriert falls dieser auftaucht - nofailback verhindert dies * comment: Beschreibung der Gruppe * Datacenter -> HA -> Resources -> Add * Group: Auswahl einer vorher definierten HA-Gruppe * Request State: bevorzugter Status der VM (bei "startet" wird das Gastsystem gestartet, falls dieses offline sein sollte) * Max. Restart: Anzahl der Neustartversuche des Service auf aktuellen Knoten * Max. Relocate: Anzahl der Versuche den Service auf einem anderen Knoten zu starten (nachdem max. restart abgearbeitet ist) Als Gruppe wird hier die Gruppierung von einzelnen Knoten zu einer HA-Gruppe verstanden, nicht zu verwechseln mit den Benutzergruppen, welchen man gewisse Rechte zuweisen kann. == Einrichten über das CLI == * Gruppe erstellen (einzigartige ID): {{{$ ha-manager groupadd GRUPPENNAME -nodes "KNOTEN:PRIORITÄT"}}} * Gastsystem zum HA-Cluster hinzufügen: {{{$ ha-manager add vm:501 --state started --max_relocate 2 --max_restart 2 --group GRUPPE --comment KOMMENTAR}}} * Container zum HA-Cluster hinzufügen: {{{$ ha-manager add ct:501}}} == Ablauf bei Ausfall eines Knotens == * Timer zählt intern herunter (Watchdog/Fencing) * Knoten mit höchster Priorität wird ausgewählt * bei gleicher Priorität wiegt Workload * Gastsystem wird auf anderem Knoten gestartet * System wird gebootet und somit geht die aktuelle Arbeit verloren, falls diese nicht gespeichert wurde == Fencing == Als Fencing bezeichnet man die Methode, bei der ein Knoten aus einem Cluster ausgegrenzt wird, um gleichzeitigen Schreibzugriff auf Daten zu verhindern. Dies könnte andernfalls zu inkonsistenten Daten führen. Die Ausgrenzung des Knotens kann durch verschiedene Wege erfolgen: * Externe Schalter, welche die Stromzufuhr kappen. (STONITH) * Isolierung des Knotens durch Deaktivieren des Netzwerkverkehrs am Switch. * Watchdog-Timer Bis einschließlich PVE 5.4 ist Fencing nur über Watchdog-Timer möglich. == Software Fencing == * per Standard aktiviert * Vorteile: * günstig, da keine zusätzliche Hardware nötig * sicher, da zusätzliche Hardware ein Ausfallrisiko hat * HA-Manager setzt Watchdog-Timer regelmäßig zurück * kein Zurücksetzen des Timers aufgrund von Hardware- oder Softwareproblemen -> Neustart des Knotens Das Testen des Fencingmechanismus mit einem Cluster, bestehend aus drei Knoten und einem separaten Clusternetzwerk (zwei NICs) sind folgende Ergebnisse erzielt worden: * Netzwerkbrücke des Knotens abgeschaltet, nach außen nicht mehr erreichbar, sichtbar im Clusternetzwerk: * Fencing ist nicht aktiviert worden, da der Knoten weiterhin über das Clusternetzwerk von den anderen Knoten erreicht werden konnte. Problematisch, da die Gast-Systeme auf dem Knoten von außen nicht mehr erreichbar waren. * beide Netzwerkinterfaces deaktiviert, nach außen nicht mehr sichtbar, nicht sichtbar im Cluster * Fencing aktiv -> automatischer Reboot * Clusternetzwerkinterface abgeschaltet, nach außen sichtbar, nicht sichtbar im Clusternetzwerk * Fencing aktiv -> automatischer Reboot == Hardware Fencing == Proxmox unterstützt Fencing aktuell (PVE 5.4) nur über Watchdogs. Auf aktuellen Servermotherboards ist entsprechende Hardware verbaut, muss aber aktiviert werden. * Aktivieren des HW-Watchdogs in {{{/etc/default/pve-ha-manager}}} * z.B. {{{$ select watchdog module}}} (default is softdog) * WATCHDOG_MODULE=iTCO_wdt* iTCO Watchdog * in fast allen INTEL Motherboards enthalten * IPMI Watchdog: * {{{/etc/modprobe.d/ipmi_watchdog.conf}}} -> {{{options ipmi_watchdog action=power_cycle panic_wdt_timeout=10}}} * Reboot oder {{{ipmi_watchdog module}}} neu laden * Dell IDrac: * "Automated System Recovery Agent" in der IDrac-Konfiguration deaktivieren * ggf. Watchdogmanagement von Openmanage deaktivieren * {{{/opt/dell/srvadmin/sbin/dcecfg command=removepopalias aliasname=dcifru}}} -> Reboot * Watchdog-Timer bei 10s! -> {{{$ idracadm getsysinfo -w}}} oder {{{$ ipmitool mc watchdog get}}} * HP ILO: * reported crashs * Deaktivieren von Automatic Server Rocovery * bei installierten HP Management Tools -> {{{hp-asrd daemon}}} deaktivieren == Ausfall eines Knotens UND Ausfall des Shared-Storage == * wie [[https://wiki.init.mpg.de/IT4Science/ProxmoxHighAvailablility#Ablauf_bei_Ausfall_eines_Knotens|Ablauf bei Ausfall eines Knotens]] * Gastsystem kann nicht gestartet werden * "Error: storage 'xyz' is disabled" * bei Reaktivieren des Knotens und Shared Storage bleibt das Gastsystem im State "error" * befindet sich ein Gastsystem im State "error" wird dieses nicht mehr durch den HA-Cluster verwaltet * Ursache des error State beseitigen * {{{$ ha-manager set vm:100 --state disabled}}} und Knoten hinzufügen * oder über GUI das Gastsystem entfernen und neu hinzufügen