Hochverfügbarkeitsrichtlinie für VMs konfigurieren

In diesem Dokument erfahren Sie, wie Sie die Hochverfügbarkeitsrichtlinie für virtuelle Maschinen (VMs) konfigurieren, die mit Anthos VM Runtime ausgeführt werden.

Wenn Sie die Anthos-VM-Laufzeit aktivieren, erstellt der Cluster ein VMHighAvailabilityPolicy-Objekt namens default. Dieses Objekt gibt die Standardwiederherstellungsstrategie für den Fall an, dass ein Clusterknoten, auf dem eine VM ausgeführt wird, fehlschlägt. Mögliche Standard-Wiederherstellungsstrategien sind:

  • Termin verschieben: Verschieben Sie die VM auf einen anderen Clusterknoten.
  • Ignorieren: Nichts unternehmen.

Anfangs ist die standardmäßige Wiederherstellungsstrategie auf Reschedule festgelegt.

In den folgenden Situationen ist eine Standard-Wiederherstellungsstrategie von Reschedule geeignet:

  • Ihr Cluster hat mindestens zwei Worker-Knoten.

  • Ihre VM-Laufwerke werden mithilfe einer netzwerkbasierten 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 netzwerkbasierte Speicherklasse.

Wenn Ihre VMs lokalen Speicher oder ein blockbasiertes Speichersystem verwenden, sollten Sie die Standardwiederherstellungsstrategie auf Ignore festlegen. Wir empfehlen diese Empfehlung aus folgenden Gründen:

  • 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, ist der Speicher möglicherweise nicht ausreichend geschützt. Dies kann zu gleichzeitigem Laufwerkszugriff und Datenbeschädigung 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 mit dem Namen 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 VMHighAvailabilityPolicy-Objekts 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

Standard-Wiederherstellungsstrategie ändern

In bestimmten Situationen empfehlen wir, die Standardstrategie zur Wiederherstellung zu ändern. Wenn Ihre VMs beispielsweise lokalen Speicher oder ein Dateisystem ohne Netzwerkdatei verwenden, sollten Sie den Wert von defaultRecoveryStrategy in Ignore ändern.

Zum Ändern des Werts von defaultRecoveryStrategy öffnen Sie das VMHighAvailabilityPolicy-Objekt 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.

Standard-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 Standard-Wiederherstellungsstrategie für einzelne VMs überschreiben.

Angenommen, die meisten Ihrer VMs werden mit einer netzwerkbasierten Speicherklasse bereitgestellt, einige VMs jedoch mit einer blockbasierten Speicherklasse. Für jede VM mit blockbasiertem Speicher empfehlen wir, die standardmäßige Wiederherstellungsstrategie zu überschreiben, indem Sie die Wiederherstellungsstrategie für die einzelne VM auf Ignore setzen.

Wenn Sie die Standardwiederherstellungsstrategie für eine VM überschreiben möchten, fügen Sie dem Objekt der VirtualMachineInstance (VMI) und dem GVM-Objekt die Annotation vm.cluster.gke.io/vm-ha-recovery-strategy hinzu.

Mit diesen Befehlen wird beispielsweise die Wiederherstellungsstrategie für eine VM mit dem Namen my-vm auf Ignore festgelegt:

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, verwenden Sie am Ende des Annotationsnamens 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

Neben der Konfiguration der Standard-Wiederherstellungsstrategie können Sie auch Folgendes konfigurieren:

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

  • Kulanzzeitraum für die Knotenüberwachung: Die maximale Zeit, die ein Knoten keinen Herzschlag senden kann, bevor er als fehlerhaft gilt.

In den meisten Fällen sind die Standardwerte für das Heartbeat-Intervall und den Kulanzzeitraum angemessen. Sie können diese Werte jedoch anpassen, wenn Sie den Kompromiss zwischen Geschwindigkeit der Wiederherstellung und Aufwand erhöhen 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 Herzschlagintervall verlängern, da häufige Herzschläge von vielen Knoten eine inakzeptable Belastung des Kubernetes API-Servers verursachen könnten.

Halten Sie das Herzfrequenzintervall unter dem Kulanzzeitraum, 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 nodeHeartbeatInterval und nodeMonitorGracePeriod auf Werte Ihrer Wahl fest.

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