Richtlinie für Hochverfügbarkeit für VMs konfigurieren

In diesem Dokument erfahren Sie, wie Sie die Hochverfügbarkeitsrichtlinie für virtuelle Maschinen (VMs) konfigurieren, die über die VM-Laufzeit auf GDC ausgeführt werden.

Wenn Sie die VM-Laufzeit auf GDC aktivieren, erstellt der Cluster ein VMHighAvailabilityPolicy-Objekt mit dem Namen default. Dieses Objekt gibt die standardmäßige Wiederherstellungsstrategie für den Fall an, dass ein Clusterknoten, auf dem eine VM ausgeführt wird, fehlschlägt. Mögliche standardmäßige Wiederherstellungsstrategien sind:

  • Neu planen: Planen Sie die VM auf einem anderen Clusterknoten neu.
  • Ignorieren: Sie brauchen nichts zu tun.

Die standardmäßige Wiederherstellungsstrategie ist anfangs auf Reschedule festgelegt.

In den folgenden Situationen eignet sich die standardmäßige Wiederherstellungsstrategie Reschedule:

  • Der Cluster hat mindestens zwei Worker-Knoten.

  • Ihre VM-Laufwerke werden mit einer netzwerkdateibasierten Speicherklasse bereitgestellt. Das heißt, die Speicherklasse basiert auf einem Netzwerkdateisystem, das POSIX-Dateisperren für verschiedene Clients koordiniert. Network File System (NFS) ist ein Beispiel für eine netzwerkdateibasierte Speicherklasse.

Wenn Ihre VMs lokalen Speicher oder ein blockbasiertes Speichersystem verwenden, empfehlen wir, die standardmäßige Wiederherstellungsstrategie auf Ignore festzulegen. Wir geben diese Empfehlung aus den folgenden Gründen ab:

  • Wenn Ihre VMs lokalen Speicher verwenden und ein Knoten ausfällt, gibt es keine Möglichkeit, die gespeicherten Daten wiederherzustellen und auf einen neuen Knoten zu verschieben.

  • Wenn Ihre VMs ein blockbasiertes Speichersystem verwenden, hat der Speicher möglicherweise keine ausreichende Trennungsgarantie. Dies kann zu gleichzeitigem Laufwerkzugriff und Datenbeschädigungen während der VM-Planung führen.

VMHighAvailabilityPolicy-Objekt prüfen

Prüfen Sie, ob ein VMHighAvailabilityPolicy-Objekt vorhanden ist:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get VMHighAvailabilityPolicy --namespace vm-system

Ersetzen Sie USER_CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei des Nutzerclusters.

Die Ausgabe zeigt, dass es ein VMHighAvailabilityPolicy-Objekt namens default gibt. In der Ausgabe sehen Sie auch den aktuellen Wert von defaultRecoveryStrategy. Die folgende Ausgabe zeigt beispielsweise, dass der aktuelle Wert von defaultRecoveryStrategy Reschedule ist:

vm-system   default   5m55s   Reschedule   15s   1m30s

Rufen Sie eine detaillierte Ansicht des Objekts „VMHighAvailabilityPolicy“ ab:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get VMHighAvailabilityPolicy \
    --namespace vm-system --output yaml

Beispielausgabe:

apiVersion: vm.cluster.gke.io/v1alpha1
kind: VMHighAvailabilityPolicy
metadata:
  ...
  labels:
    app.kubernetes.io/component: kubevirt
    app.kubernetes.io/managed-by: virt-operator
    kubevirt.io: virt-api
  name: default
  namespace: vm-system
  ..
spec:
  defaultRecoveryStrategy: Reschedule
  nodeHeartbeatInterval: 15s
  nodeMonitorGracePeriod: 1m30s

Standardmäßige Wiederherstellungsstrategie ändern

In bestimmten Situationen empfehlen wir, die Standardwiederherstellungsstrategie zu ändern. Wenn Ihre VMs beispielsweise lokalen Speicher oder ein Dateisystem verwenden, das nicht auf Netzwerkdateien basiert, empfehlen wir, den Wert von defaultRecoveryStrategy in Ignore zu ändern.

Wenn Sie den Wert von defaultRecoveryStrategy ändern möchten, öffnen Sie das Objekt „VMHighAvailabilityPolicy“ zur Bearbeitung:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG edit VMHighAvailabilityPolicy \
    default --namespace vm-system

Ändern Sie im Texteditor den Wert von defaultRecoveryStrategy in einen Wert Ihrer Wahl: Reschedule oder Ignore. Schließen Sie den Texteditor.

Standardmäßige Wiederherstellungsstrategie für eine VM überschreiben

Die standardmäßige Wiederherstellungsstrategie gilt für alle VMs, die im Cluster ausgeführt werden. Möglicherweise müssen Sie jedoch die Standardwiederherstellungsstrategie für einzelne VMs überschreiben.

Angenommen, die meisten Ihrer VMs werden mit einer netzwerkdateibasierten Speicherklasse bereitgestellt, einige aber auch mit einer blockbasierten Speicherklasse. Für jede VM, die blockbasierten Speicher verwendet, empfehlen wir, dass Sie die Standardwiederherstellungsstrategie überschreiben, indem Sie die Wiederherstellungsstrategie für die einzelne VM auf Ignore setzen.

Zum Überschreiben der Standardwiederherstellungsstrategie für eine VM fügen Sie dem VirtualMachineInstance-Objekt (VMI) und dem GVM-Objekt eine vm.cluster.gke.io/vm-ha-recovery-strategy-Annotation hinzu.

Die folgenden Befehle setzen beispielsweise die Wiederherstellungsstrategie für eine VM mit dem Namen my-vm auf Ignore:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  annotate vmi my-vm \
  vm.cluster.gke.io/vm-ha-recovery-strategy=Ignore --overwrite

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  annotate gvm my-vm \
  vm.cluster.gke.io/vm-ha-recovery-strategy=Ignore --overwrite

Wenn Sie die Annotationen später entfernen möchten, setzen Sie am Ende des Annotationsnamen einen Bindestrich. Beispiel:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  annotate vmi my-vm \
  vm.cluster.gke.io/vm-ha-recovery-strategy-

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  annotate gvm my-vm \
  vm.cluster.gke.io/vm-ha-recovery-strategy-

Erweiterte Konfiguration

Zusätzlich zur Konfiguration der standardmäßigen Wiederherstellungsstrategie können Sie Folgendes konfigurieren:

  • Knotenherzschlagintervall: Die Zeit zwischen den von jedem Clusterknoten gesendeten Herzschlägen

  • Kulanzzeitraum für Knotenüberwachung: Die maximale Zeitspanne, in der ein Knoten keinen Herzschlag senden kann, bevor er als fehlerhaft eingestuft wird.

In den meisten Fällen sind die Standardwerte für das Herzschlagintervall und den Kulanzzeitraum angemessen. Sie können diese Werte jedoch anpassen, wenn Sie einen Kompromiss zwischen Wiederherstellungsgeschwindigkeit und Aufwand erzielen möchten. Ein kürzeres Herzschlagintervall verkürzt die Wiederherstellungszeit, erhöht aber auch den Aufwand. In einem großen Cluster können Sie das Heartbeat-Intervall verlängern, da häufige Heartbeats von vielen Knoten eine inakzeptable Last auf dem Kubernetes API-Server verursachen können.

Das Herzschlagintervall sollte kleiner als der Kulanzzeitraum sein, um Fälle zu vermeiden, in denen ein einzelner verpasster Herzschlag dazu führt, dass ein Knoten als fehlerhaft eingestuft wird.

Führen Sie kubectl edit aus, um das VMHighAvailabilityPolicy-Objekt zur Bearbeitung zu öffnen. Legen Sie für nodeHeartbeatInterval und nodeMonitorGracePeriod Werte Ihrer Wahl fest.

spec:
  defaultRecoveryStrategy: Reschedule
  nodeHeartbeatInterval: 15s
  nodeMonitorGracePeriod: 1m30s