Fonctionnalités de haute disponibilité (HA)

La fonction de haute disponibilité est une fonction qui “redémarre” automatiquement (appelée basculement) une machine virtuelle sur un autre hôte fonctionnant normalement lorsqu’un hôte physique tombe en panne. Par conséquent, il est nécessaire de prendre des dispositions préalables dans le système d’exploitation invité de la machine virtuelle pour que le système puisse être restauré automatiquement.

Quelles sont les conditions pour utiliser la HA ?

Pour utiliser la HA avec la version HRPC KVM, les conditions suivantes doivent être remplies :

1. Un centre de données virtuel composé de trois nœuds ou plus configurés de manière identique.
2. Doit être de type HCI ou de type 3-tier, car un stockage partagé (Ceph, ESF avec ES) est requis.
3. Il doit y avoir une capacité de réserve suffisante (en particulier la mémoire) sur l’équipement. Il est important qu’au moins la mémoire d’un nœud soit libre au total.
   *Par exemple, dans le cas d’un centre de données virtuel composé de trois nœuds, seule la mémoire de deux nœuds doit être utilisée au total.
4. Assurez-vous que des sauvegardes des machines virtuelles sont effectuées.
   Nous recommandons vivement de souscrire un contrat avec le stockage de sauvegarde ou similaire et de configurer des sauvegardes régulières de vos machines virtuelles.

Comment activer la fonction HA ?

Si vous souhaitez activer la fonction HA, commencez par sélectionner le centre de données dans le panneau de gauche, ouvrez HA dans le panneau central, et cliquez sur Groupe.

Cliquez sur le bouton Créer dans le panneau de droite, créez un identifiant de groupe HA, et cochez les hôtes liés à la HA. Lors de la création de machines virtuelles sur des hôtes liés à la HA, vous devez prévoir au moins la mémoire de réserve équivalente à celle d’un hôte physique. Si vous participez à la HA avec un total de quatre HRPC équipés de 768 Go de mémoire, les trois autres machines devront avoir 768 Go de mémoire libre pour que les autres appareils puissent continuer à fonctionner même en cas de panne physique d’un HRPC. Si vous ne cochez pas le groupe HA, il sera ignoré en tant que cible HA, même s’il se trouve dans le même centre de données.

Si un hôte est délibérément retiré du groupe HA et que le paramètre du groupe HA “restreint” est coché, les machines virtuelles appartenant à ce groupe HA ne pourront pas être démarrées sur l’hôte retiré.

Si l’option nofailback est cochée, lorsqu’un nœud physique défaillant redémarre et revient, les machines virtuelles ne seront pas restaurées mais continueront à fonctionner sur la destination. Si nofailback n’est pas coché, elles seront renvoyées au nœud d’origine par migration à chaud, permettant une gestion stricte du placement des hôtes de nœuds et des machines virtuelles. Cependant, si le nœud physique devient instable et est redémarré à plusieurs reprises, la HA sera activée à nouveau et les machines virtuelles seront redémarrées à plusieurs reprises. Pour cette raison, nous recommandons de cocher nofailback.

De plus, bien que la migration à chaud soit une fonctionnalité qui échoue rarement, il y a une interruption interne momentanée qui peut causer des problèmes dans les logiciels en temps réel.

Comment activer la HA pour une machine virtuelle ?

La HA de Proxmox ne sera pas applicable à moins que la machine virtuelle ne soit sous gestion HA.

Pour placer une machine virtuelle sous gestion HA, sélectionnez la machine virtuelle et choisissez “Gérer HA” dans le menu déroulant “Plus▼” en haut à droite. Sélectionnez l’identifiant du groupe HA que vous avez configuré ci-dessus dans le groupe, définissez l’état souhaité sur démarré, puis cliquez sur le bouton Ajouter.

Cette machine virtuelle est maintenant sous contrôle HA.

La portée de l’opération HA varie selon l’hyperviseur. Dans VMware, lorsque la HA est activée dans un centre de données virtuel, elle affecte toutes les machines virtuelles du centre de données virtuel, tandis que dans XenOrchestra, elle n’affecte que les machines virtuelles du pool où la HA est activée et qui ont le paramètre “redémarrer”.

Relation entre le redémarrage de maintenance des nœuds (hôtes) dans un groupe HA et les machines virtuelles

Lorsqu’un nœud faisant partie d’un groupe HA est redémarré pour maintenance (et non en raison d’une panne inattendue), le comportement des machines virtuelles sera différent selon qu’elles sont sous gestion HA ou non.

Machines virtuelles sous gestion HA	Migration à chaud vers une autre machine
Machines virtuelles non gérées par HA	Elle s’arrête automatiquement et reste arrêtée après le redémarrage

colonne

Limites de la fonction HA

Les fonctions HA ont des limites, et des problèmes peuvent survenir lors de l’utilisation de la HA.

1. Redémarrage inattendu d’une machine virtuelle
2. Corruption des données de la machine virtuelle

En résumé, la HA est la capacité à démarrer une machine virtuelle depuis un autre nœud lorsqu’un nœud tombe en panne, mais c’est ainsi que cela fonctionne d’un point de vue global, et la logique logicielle réelle doit être implémentée de manière complètement différente.

Tout d’abord, il n’est pas possible de définir strictement ce qui constitue une “panne” dans un nœud spécifique parmi les trois nœuds (c’est-à-dire le nœud A, le nœud B et le nœud C). La HA est réalisée en faisant travailler chaque nœud en coordination avec les autres.

Lorsque le nœud A perd la communication avec le nœud B, il n’est pas clair si une panne s’est produite dans le nœud B, ou si la communication a simplement été perdue entre le nœud A et le nœud B. Si le nœud A peut communiquer avec le nœud C de son point de vue, il est conceivable qu’une panne ait pu se produire dans le nœud B.

Cependant, si les données des machines virtuelles hébergées sur le nœud B sont constamment mises à jour sur le stockage partagé, le nœud B peut être complètement isolé.

Dans l’exemple ci-dessus, si les nœuds A et C communiquent, il y a une forte probabilité que le nœud B ait échoué. Par conséquent, les nœuds A et C tenteront de démarrer eux-mêmes les machines virtuelles hébergées sur le nœud B.

Cependant, le nœud B n’a peut-être pas échoué, mais peut simplement être isolé. Si un nœud détermine qu’il est isolé, il arrêtera immédiatement les machines virtuelles qu’il héberge pour se préparer à ce que les nœuds A et C puissent démarrer, ce qui provoque le redémarrage inattendu mentionné ci-dessus.

Alors, que se passe-t-il si le nœud B ne s’arrête pas ?

Si la même machine virtuelle fonctionne à deux endroits, le nœud B et un autre nœud, le disque virtuel de la machine virtuelle sera corrompu en un instant, ce qui conduira à la destruction des données de la machine virtuelle mentionnée ci-dessus.

Donc, votre choix est soit de redémarrer, soit de détruire vos données.

La HA nécessite une coordination entre chaque nœud pour déterminer s’il est en panne, s’il a simplement perdu la communication, ou s’il est lent.

Si les deux pannes ci-dessus sont mutuellement exclusives, ce que vous voulez éviter est la corruption des données, donc arrêtez immédiatement.

Cette décision est prise à intervalles réguliers, et Proxmox le fait toutes les 2 minutes. S’il n’y a pas de réponse pendant 2 minutes, il est déterminé que “l’hôte a échoué”. Par conséquent, au minimum, l’arrêt sera de 2 minutes + le temps nécessaire pour démarrer la machine virtuelle (en réalité, cela prendra plus de temps).

Cependant, si la vitesse du nœud ralentit, que la mémoire est échangée, que la récupération de mémoire par le pilote de ballonage provoque un ralentissement temporaire, ou que l’écriture sur le stockage ralentit, les deux minutes peuvent passer rapidement Ott rapidement et l’arrêt peut ne pas être possible à temps. Parce que ce qui doit être protégé est les données, le système utilise automatiquement un WatchDog Timer ou similaire, et les clouds privés fonctionnent sur du matériel équipé d’un dispositif qui peut redémarrer automatiquement le noyau même si le noyau de l’hôte cesse de répondre.