Ce document explique comment configurer la règle de haute disponibilité pour les machines virtuelles (VM) exécutées à l'aide de l'environnement d'exécution des VM sur GDC.
Lorsque vous activez l'environnement d'exécution des VM sur GDC, 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.
Par défaut, 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 les 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 le 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 basé sur des blocs, le stockage peut ne pas présenter suffisamment de garanties de dissociation. Cela peut entraîner un accès simultané au disque et la corruption des données lors de la planification des 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 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 les fichiers 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.
Remplacer 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 les 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 soient provisionnées avec une classe de stockage basée sur les blocs. Pour chaque VM qui utilise le stockage de 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 de la VM individuelle 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
à 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, utilisez 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 de grande taille, vous pouvez choisir d'allonger l'intervalle des pulsations, car des pulsations fréquentes provenant de nombreux nœuds peuvent créer une charge inacceptable sur le serveur d'API Kubernetes.
Maintenez l'intervalle de pulsation inférieur au délai de grâce pour éviter les cas où une seule pulsation manquée rend un nœud considéré comme 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