In diesem Dokument erfahren Sie, wie Sie die Hochverfügbarkeitsrichtlinie für virtuelle Maschinen (VMs) konfigurieren, die mithilfe der VM-Laufzeit in Google Distributed Cloud ausgeführt werden.
Wenn Sie die VM-Laufzeit in Google Distributed Cloud 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 Standardstrategien zur Wiederherstellung sind:
- Verschieben: Verschieben Sie die VM auf einem anderen Clusterknoten.
- Ignorieren: Sie tun nichts.
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 mithilfe einer netzwerkbasierten Speicherklasse bereitgestellt. Das heißt, die Speicherklasse basiert auf einem Netzwerkdateisystem, das POSIX-Dateisperren über verschiedene Clients koordiniert. Network File System (NFS) ist ein Beispiel für eine auf Netzwerkdateien basierende Speicherklasse.
Wenn Ihre VMs lokalen Speicher oder ein blockbasiertes Speichersystem verwenden, empfehlen wir, die Standardstrategie für die Wiederherstellung auf Ignore festzulegen. 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, sind für den Speicher möglicherweise keine ausreichenden Trennungsgarantien gegeben. Dies kann zu gleichzeitigem Laufwerkszugriff und Datenbeschädigungen bei 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 ein VMHighAvailabilityPolicy-Objekt mit dem Namen default vorhanden ist. 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
Standardstrategie zur Wiederherstellung ä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 VMHighAvailabilityPolicy-Objekt zum Bearbeiten:
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 VMs werden mit einer auf Netzwerkdatei basierenden Speicherklasse bereitgestellt, einige aber auch mit einer blockbasierten Speicherklasse. Für jede VM, die blockbasierten Speicher verwendet, empfehlen wir, die Standardwiederherstellungsstrategie zu überschreiben. Dazu legen Sie die Wiederherstellungsstrategie für die einzelne VM auf Ignore fest.
Wenn Sie die Standardwiederherstellungsstrategie für eine VM überschreiben möchten, fügen Sie dem VMI-Objekt (VirtualMachineInstance) und dem GVM-Objekt die Annotation vm.cluster.gke.io/vm-ha-recovery-strategy 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 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
Zusätzlich zur Konfiguration der standardmäßigen Wiederherstellungsstrategie können Sie Folgendes konfigurieren:
Knoten-Heartbeat-Intervall: Die Zeit zwischen den von jedem Clusterknoten gesendeten Herzschlägen.
Kulanzzeitraum für Knotenüberwachung: Die maximale Zeitspanne, in der ein Knoten keinen Heartbeat sendet, bevor er als fehlerhaft eingestuft wird.
In den meisten Fällen sind die Standardwerte für Heartbeat-Intervall und Kulanzzeitraum angemessen. Sie können diese Werte jedoch anpassen, um einen Kompromiss zwischen Wiederherstellungsgeschwindigkeit und Aufwand zu finden. Ein kürzeres Herzschlagintervall verkürzt die Erholungszeit, 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 zu einer inakzeptablen Last auf dem Kubernetes API-Server führen 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 betrachtet wird.
Führen Sie kubectl edit aus, um das VMHighAvailabilityPolicy-Objekt zum Bearbeiten zu öffnen. Legen Sie für nodeHeartbeatInterval und nodeMonitorGracePeriod Werte Ihrer Wahl fest.
spec: defaultRecoveryStrategy: Reschedule nodeHeartbeatInterval: 15s nodeMonitorGracePeriod: 1m30s