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