Ce document explique comment configurer la règle de haute disponibilité pour les machines virtuelles (VM) qui s'exécutent à l'aide de l'environnement d'exécution des VM Anthos.
Lorsque vous activez l'environnement d'exécution des VM Anthos, le cluster crée un objet VMHighAvailabilityPolicy nommé default
. Cet objet spécifie la stratégie de récupération par défaut en cas de défaillance d'un nœud de cluster qui exécute une VM. Les stratégies de récupération par défaut possibles sont les suivantes :
- Reprogrammer : reprogrammez la VM sur un autre nœud de cluster.
- Ignorer : ne faites rien.
Au départ, la stratégie de récupération par défaut est définie sur Reschedule
.
Une stratégie de reprise par défaut de Reschedule
est appropriée dans le cas suivant :
Votre cluster comporte au moins deux nœuds de calcul.
Vos disques de VM sont provisionnés à l'aide d'une classe de stockage basée sur des fichiers réseau. Autrement dit, la classe de stockage est basée sur un système de fichiers réseau qui coordonne les verrous de fichiers POSIX sur différents clients. Network File System (NFS) est un exemple de classe de stockage basée sur un système de fichiers.
Si vos VM utilisent un stockage local ou un système de stockage de blocs, nous vous recommandons de définir la stratégie de récupération par défaut sur Ignore
. Nous formulons cette recommandation pour les raisons suivantes :
Si vos VM utilisent le stockage local et qu'un nœud échoue, il n'existe aucun moyen de récupérer les données stockées et de les déplacer vers un nouveau nœud.
Si vos VM utilisent un système de stockage basé sur les blocs, l'espace de stockage risque de ne pas disposer de garanties de dissociation suffisantes. Cela peut entraîner un accès simultané au disque et une corruption des données pendant la planification de la VM.
Inspecter l'objet VMHighAvailabilityPolicy
Vérifiez qu'il existe un objet VMHighAvailabilityPolicy :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get VMHighAvailabilityPolicy --namespace vm-system
Remplacez USER_CLUSTER_KUBECONFIG par le chemin d'accès du fichier kubeconfig de votre cluster d'utilisateur.
Le résultat indique qu'il existe un objet VMHighAvailabilityPolicy nommé default
. Dans le résultat, vous pouvez également voir la valeur actuelle de defaultRecoveryStrategy
. Par exemple, le résultat suivant indique que la valeur actuelle de defaultRecoveryStrategy
est Reschedule
:
vm-system default 5m55s Reschedule 15s 1m30s
Obtenez une vue détaillée de l'objet VMHighAvailabilityPolicy :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get VMHighAvailabilityPolicy \ --namespace vm-system --output yaml
Exemple de résultat :
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
Modifier la stratégie de récupération par défaut
Dans certains cas, nous vous recommandons de modifier la stratégie de récupération par défaut. Par exemple, si vos VM utilisent un stockage local ou un système de fichiers qui n'est pas basé sur des fichiers réseau, nous vous recommandons de remplacer la valeur defaultRecoveryStrategy
par Ignore
.
Pour modifier la valeur de defaultRecoveryStrategy
, ouvrez l'objet VMHighAvailabilityPolicy pour le modifier :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG edit VMHighAvailabilityPolicy \ default --namespace vm-system
Dans votre éditeur de texte, remplacez la valeur de defaultRecoveryStrategy
par la valeur de votre choix : Reschedule
ou Ignore
. Fermez l'éditeur de texte.
Ignorer la stratégie de récupération par défaut pour une VM
La stratégie de récupération par défaut s'applique à toutes les VM exécutées dans le cluster. Toutefois, vous devrez peut-être remplacer la stratégie de récupération par défaut pour des VM individuelles.
Par exemple, supposons que la plupart de vos VM soient provisionnées avec une classe de stockage basée sur des fichiers réseau, mais que quelques VM disposent d'une classe de stockage basée sur des blocs. Pour chaque VM qui utilise le stockage basé sur des blocs, nous vous recommandons de remplacer la stratégie de récupération par défaut en définissant la stratégie de récupération de chaque VM sur Ignore
.
Pour remplacer la stratégie de récupération par défaut d'une VM, ajoutez une annotation vm.cluster.gke.io/vm-ha-recovery-strategy
à la fois à l'objet VirtualMachineInstance (VMI) et à l'objet GVM.
Par exemple, ces commandes définissent la stratégie de récupération sur Ignore
pour une VM nommée my-vm
:
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
Si vous souhaitez supprimer les annotations ultérieurement, insérez un trait d'union à la fin du nom de l'annotation. Exemple :
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-
Configuration avancée
Outre la configuration de la stratégie de récupération par défaut, vous pouvez configurer les éléments suivants :
Intervalle de pulsations des nœuds : délai entre les pulsations envoyées par chaque nœud de cluster
Délai de grâce pour la surveillance des nœuds : durée maximale pendant laquelle un nœud peut envoyer une pulsation avant d'être considéré comme non opérationnel
Dans la plupart des cas, les valeurs par défaut pour l'intervalle de pulsation et le délai de grâce sont appropriées. Toutefois, vous pouvez choisir de modifier ces valeurs si vous souhaitez ajuster le compromis entre vitesse de récupération et surcharge. Un intervalle de pulsation plus court réduit le temps de récupération, mais augmente également la surcharge. Dans un cluster volumineux, vous pouvez allonger l'intervalle de pulsation, car les pulsations fréquentes provenant de nombreux nœuds peuvent créer une charge inacceptable sur le serveur d'API Kubernetes.
Réduisez l'intervalle de pulsation au-delà du délai de grâce pour éviter les cas où une pulsation peut causer un défaut de nœud.
Exécutez kubectl edit
pour ouvrir l'objet VMHighAvailabilityPolicy afin de le modifier. Définissez nodeHeartbeatInterval
et nodeMonitorGracePeriod
sur les valeurs de votre choix.
spec: defaultRecoveryStrategy: Reschedule nodeHeartbeatInterval: 15s nodeMonitorGracePeriod: 1m30s