Ce document explique comment configurer la règle de haute disponibilité pour les machines virtuelles (VM) exécutées à l'aide de leur environnement d'exécution sur Google Distributed Cloud.
Lorsque vous activez l'environnement d'exécution des VM sur Google Distributed Cloud, le cluster crée un objet VMHighAvailabilityPolicy nommé default. Cet objet spécifie la stratégie de reprise 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 par 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 un stockage local et qu'un nœud tombe en panne, 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 par blocs, le stockage peut ne pas présenter de garanties de dissociation suffisantes. Cela peut entraîner un accès simultané au disque et une corruption des données lors de 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 montre qu'il existe un objet VMHighAvailabilityPolicy nommé default. Dans la sortie, 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 un fichier réseau, nous vous recommandons de remplacer la valeur de 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 d'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 les fichiers réseau, mais que quelques VM le soient avec une classe de stockage par blocs. Pour chaque VM qui utilise le stockage basé sur les blocs, nous vous recommandons d'ignorer la stratégie de récupération par défaut en définissant la stratégie de récupération sur Ignore pour chaque VM.
Pour ignorer 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 aux objets VirtualMachineInstance (VMI) et 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 par la suite, ajoutez un trait d'union à la fin de leur nom. 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 de l'intervalle de pulsation et du 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 de grande taille, vous pouvez choisir d'allonger l'intervalle des pulsations, car des pulsations fréquentes provenant de plusieurs nœuds peuvent créer une charge inacceptable sur le serveur d'API Kubernetes.
Maintenez l'intervalle de pulsation à un niveau inférieur au délai de grâce pour éviter les cas où un seul battement de cœur manqué entraîne le jugement d'un nœud non opérationnel.
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