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 de VM sur GDC.
Lorsque vous activez l'environnement d'exécution de 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 exécutant 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.
Les disques de vos VM sont provisionnés à l'aide d'une classe de stockage basée sur un système de fichiers. 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 basé sur des 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 basé sur des blocs, il est possible que le stockage ne dispose pas de garanties de détachement suffisantes. Cela pourrait entraîner un accès simultané au disque et une 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 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.
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 des VM individuelles.
Par exemple, supposons que la plupart de vos VM soient provisionnées avec une classe de stockage basée sur un système de fichiers, mais que quelques VM soient provisionnées avec une classe de stockage basée sur des blocs. Pour chaque VM qui utilise un 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 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, 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 grand cluster, vous pouvez choisir d'allonger l'intervalle de pulsation, car des pulsations fréquentes de nombreux nœuds pourraient 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 qu'un seul battement de cœur manqué ne conduise à considérer un nœud 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