Configurer une règle de haute disponibilité pour les VM

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