Zurück

Hochverfügbarkeits-(HA)-Funktionen

Die Hochverfügbarkeitsfunktion ist eine Funktion, die eine virtuelle Maschine automatisch auf einem anderen normal funktionierenden Host „neu startet“ (sogenannter Failover), wenn ein physischer Host ausfällt. Daher ist es notwendig, im Voraus im Gast-Betriebssystem der virtuellen Maschine Vorkehrungen zu treffen, damit das System automatisch wiederhergestellt werden kann.

Was sind die Voraussetzungen für die Nutzung von HA?

Um HA mit der HRPC KVM-Version zu nutzen, müssen die folgenden Bedingungen erfüllt sein:

  1. Ein virtuelles Rechenzentrum, das aus drei oder mehr identisch konfigurierten Knoten besteht.
  2. Muss vom Typ HCI oder 3-Tier sein, da gemeinsam genutzter Speicher (Ceph, ESF mit ES) erforderlich ist.
  3. Es muss ausreichend freie Kapazität (insbesondere Arbeitsspeicher) auf der Hardware vorhanden sein. Es ist wichtig, dass insgesamt mindestens der Arbeitsspeicher eines Knotens frei bleibt.
    *Beispielsweise sollten bei einem virtuellen Rechenzentrum aus drei Knoten insgesamt nur der Arbeitsspeicher von zwei Knoten verwendet werden.
  4. Stellen Sie sicher, dass Sicherungen der virtuellen Maschinen erstellt werden.
    Wir empfehlen dringend, einen Vertrag mit Backup Storage oder Ähnlichem abzuschließen und regelmäßige Sicherungen Ihrer virtuellen Maschinen einzurichten.

Wie aktiviere ich die HA-Funktion?

Wenn Sie die HA-Funktion aktivieren möchten, wählen Sie zunächst das Rechenzentrum im linken Bereich aus, öffnen Sie HA im mittleren Bereich und klicken Sie auf Gruppe.

Klicken Sie im rechten Bereich auf die Schaltfläche „Erstellen“, erstellen Sie eine HA-Gruppen-ID und markieren Sie die mit HA verbundenen Hosts. Beim Erstellen von virtuellen Maschinen auf Hosts, die mit HA verbunden sind, müssen Sie mindestens den Arbeitsspeicher eines physischen Hosts als Reserve vorbereiten. Wenn Sie mit insgesamt vier HRPCs mit jeweils 768 GB Arbeitsspeicher an HA teilnehmen, benötigen die verbleibenden drei Maschinen 768 GB freien Arbeitsspeicher, damit die anderen Geräte weiterhin betrieben werden können, selbst wenn ein HRPC einen physischen Ausfall erleidet. Wenn Sie die HA-Gruppe nicht markieren, wird sie als HA-Ziel ignoriert, selbst wenn sie sich im selben Rechenzentrum befindet.

Wenn ein Host absichtlich aus der HA-Gruppe entfernt wird und die HA-Gruppeneinstellung „eingeschränkt“ aktiviert ist, können virtuelle Maschinen, die zu dieser HA-Gruppe gehören, auf dem entfernten Host nicht gestartet werden.

Wenn „nofailback“ aktiviert ist, werden die virtuellen Maschinen bei der Rückkehr eines ausgefallenen physischen Knotens nach einem Neustart nicht wiederhergestellt, sondern laufen weiterhin am Zielort. Wenn „nofailback“ nicht aktiviert ist, werden sie durch Live-Migration zum ursprünglichen Knoten zurückgeführt, was eine strikte Verwaltung der Platzierung von Knoten-Hosts und virtuellen Maschinen ermöglicht. Wenn der physische Knoten jedoch instabil wird und wiederholt neu gestartet wird, wird HA erneut aktiviert und die virtuellen Maschinen werden wiederholt neu gestartet. Aus diesem Grund empfehlen wir, „nofailback“ zu aktivieren.

Auch wenn die Live-Migration eine Funktion ist, die selten fehlschlägt, gibt es eine kurze interne Unterbrechung, die bei Echtzeit-Software Probleme verursachen kann.

Wie aktiviere ich HA für eine virtuelle Maschine?

Proxmox HA wird nicht angewendet, es sei denn, die virtuelle Maschine steht unter HA-Verwaltung.

Um eine virtuelle Maschine unter HA-Verwaltung zu stellen, wählen Sie die virtuelle Maschine aus und wählen Sie „HA verwalten“ aus dem Pulldown-Menü „Mehr▼“ oben rechts. Wählen Sie die ID der oben konfigurierten HA-Gruppe aus der Gruppe aus, setzen Sie den gewünschten Status auf „gestartet“ und klicken Sie dann auf die Schaltfläche „Hinzufügen“.

Diese virtuelle Maschine steht nun unter HA-Kontrolle.

Der Umfang des HA-Betriebs variiert je nach Hypervisor. In VMware wirkt sich die Aktivierung von HA in einem virtuellen Rechenzentrum auf alle virtuellen Maschinen im virtuellen Rechenzentrum aus, während in XenOrchestra nur die virtuellen Maschinen im Pool betroffen sind, bei denen HA aktiviert ist und „Neustart“ eingestellt ist.

Beziehung zwischen Wartungsneustart von Knoten (Hosts) in einer HA-Gruppe und virtuellen Maschinen

Wenn ein Knoten, der Teil einer HA-Gruppe ist, für Wartungsarbeiten neu gestartet wird (nicht aufgrund eines unerwarteten Fehlers), hängt das Verhalten der virtuellen Maschinen davon ab, ob sie unter HA-Verwaltung stehen oder nicht.

Virtuelle Maschinen unter HA-VerwaltungLive-Migration auf eine andere Maschine
Virtuelle Maschinen, die nicht von HA verwaltet werdenSie schalten sich automatisch ab und bleiben nach dem Neustart ausgeschaltet

Spalte

Einschränkungen der HA-Funktion

HA-Funktionen haben Einschränkungen, und es können Probleme auftreten, wenn HA verwendet wird.

  1. Unerwarteter Neustart einer virtuellen Maschine
  2. Datenbeschädigung der virtuellen Maschine

Einfach ausgedrückt, ist HA die Fähigkeit, eine virtuelle Maschine von einem anderen Knoten zu starten, wenn ein Knoten ausfällt, aber so funktioniert es aus einer übergeordneten Perspektive, und die tatsächliche Softwarelogik muss völlig anders implementiert werden.

Zunächst ist es nicht möglich, genau zu definieren, was einen „Ausfall“ eines bestimmten Knotens unter allen drei Knoten (d. h. Knoten A, Knoten B und Knoten C) ausmacht. HA wird erreicht, indem jeder Knoten in Koordination mit den anderen arbeitet.

Wenn Knoten A die Kommunikation mit Knoten B verliert, ist nicht klar, ob ein Ausfall bei Knoten B aufgetreten ist oder ob lediglich die Kommunikation zwischen Knoten A und Knoten B verloren gegangen ist. Wenn Knoten A aus seiner Perspektive mit Knoten C kommunizieren kann, ist es denkbar, dass ein Ausfall bei Knoten B aufgetreten ist.

Wenn jedoch die Daten der virtuellen Maschinen, die auf Knoten B gehostet werden, ständig auf dem gemeinsamen Speicher aktualisiert werden, kann Knoten B vollständig isoliert sein.

Im obigen Beispiel ist, wenn Knoten A und C kommunizieren, die Wahrscheinlichkeit hoch, dass Knoten B ausgefallen ist. Daher werden Knoten A und C versuchen, die auf Knoten B gehosteten virtuellen Maschinen selbst zu starten.

Knoten B ist jedoch möglicherweise nicht ausgefallen, sondern nur isoliert. Wenn ein Knoten feststellt, dass er isoliert ist, wird er die von ihm gehosteten VMs sofort herunterfahren, um sich darauf vorzubereiten, dass Knoten A und C möglicherweise starten, was den oben erwähnten unerwarteten Neustart verursacht.

Was passiert also, wenn Knoten B nicht herunterfährt?

Wenn dieselbe virtuelle Maschine an zwei Orten läuft, Knoten B und ein anderer Knoten, wird der virtuelle Datenträger der virtuellen Maschine in einem Augenblick beschädigt, was zur Zerstörung der Daten der virtuellen Maschine führt, wie oben erwähnt.

Ihre Wahl ist also entweder ein Neustart oder die Zerstörung Ihrer Daten.

HA muss zwischen den Knoten koordinieren, um festzustellen, ob ein Knoten ausgefallen ist, die Kommunikation verloren hat oder langsam ist.

Wenn die oben genannten zwei Fehler sich gegenseitig ausschließen, möchten Sie Datenbeschädigung vermeiden, also sofort herunterfahren.

Diese Entscheidung wird in Intervallen getroffen, und Proxmox tut dies alle 2 Minuten. Wenn innerhalb von 2 Minuten keine Antwort erfolgt, wird festgelegt, dass „der Host ausgefallen ist“. Daher beträgt die Ausfallzeit mindestens 2 Minuten + die Zeit, die für das Starten der virtuellen Maschine benötigt wird (in Wirklichkeit wird es länger dauern).

Wenn jedoch die Knotengeschwindigkeit nachlässt, der Arbeitsspeicher ausgelagert wird, die Speicherwiederherstellung durch den Ballooning-Treiber eine vorübergehende Verlangsamung verursacht oder das Schreiben auf den Speicher langsamer wird, können die zwei Minuten schnell vergehen, und ein Herunterfahren ist möglicherweise nicht rechtzeitig möglich. Da die Daten geschützt werden müssen, verwendet das System automatisch einen WatchDog-Timer oder Ähnliches, und private Clouds laufen auf Hardware, die mit einem Gerät ausgestattet ist, das den Kernel automatisch neu starten kann, selbst wenn der Host-Kernel nicht mehr reagiert.