vSphere 6.5 – vCenter Server High Availability
vCenter Appliance a non seulement rattrapé la richesse fonctionnelle du vCenter sous Windows, mais il dispose maintenant de fonctionnalités qui lui sont uniques. C’est le cas de vCenter High Availibility qui n’est disponible qu’avec les appliances.
Activer vCenter HA permet de protéger le vCenter en cas de perte de host par exemple, ou de limiter les indisponibilités durant les mises à jour.
Cet article est particulièrement long et la page lourde à charger en raison des copies d’écran, mais j’ai préféré le laisser en un seul bloc.
Principe
Le vCenter est cloné en deux autres nodes : un noeud passif et un noeud témoin (witness).
Une seconde carte réseau est ajoutée aux trois nodes pour qu’ils communiquent via un lien privé (en bleu), permettant la synchronisation sur les deux autres nodes de toutes modifications sur le noeud actif. La communication entre le noeud actif et l’extérieur (ESXi, management, …) restant sur la première carte réseau (en orange).
En cas d’indisponibilité du noeud actif, le noeud passif reprend automatiquement son rôle ainsi que son nom et son IP afin de permettre la continuité.
Lorsque le noeud manquant redeviendra disponible, il prendra automatiquement la fonction de noeud passif.
Le témoin n’est là que pour assurer l’arbitrage pour faire la différence entre une isolation réseau et une indisponibilité d’un noeud (même principe que pour un cluster de hosts ou de vSan).
3 hosts sont normalement nécessaires, les 3 nodes devant évidemment être séparés les uns des autres. Bien que la fonction apparaisse avec vCenter Appliance 6.5, les hosts eux-même peuvent etre en 5.5, 6.0 ou 6.5.
SSH doit être activé sur le vCenter
Un scope IP séparé de celui réseau de management doivent être configurés pour la communication entre les nodes.
Deux modes d’installation sont proposés :
- Basique : géré par un assistant, et nécessitant peu d’informations (adresses IP). L’ajout de la carte réseau, le clonage, la configuration IP et les règles d’anti-affinité sont gérés par l’assistant.
Convient lorsque le host hébergeant le vCenter est géré par celui-ci, ou par un vCenter du même domaine SSO. - Avancé : un peu plus complexe à mettre en oeuvre. Il faut cloner soi-même les VMs, configurer les IPs, créer les éventuelles règles.
Convient lorsque le vCenter ne connait pas le host qui l’héberge, ou lorsqu’on veut répartir les nodes entre plusieurs infras.
Initialement je pensais aussi que le mode avancé était le seul moyen d’activer vCenter HA lorsqu’il n’y a qu’un ESXi (dans le cas d’un home lab par exemple), car l’assistant met un message d’erreur. Mais je suis tombé sur cet article de William Lam sur virtuallyGhetto qui indique comment contourner le problème : How to enable vCenter Server High Availability (VCHA) in vSphere 6.5 w/single ESXi host?. Je n’ai pas testé, je le livre pour info…
Configuration basique
Cliquer sur Configure.
Choisir la configuration basique.
Indiquer l’adresse IP à utiliser sur le vCenter pour la communication avec les autres nodes. Ce doit être un scope IP différent de l’IP principale, mais le même port group peut être utilisé.
Indiquer les adresses IP des deux autres noeuds.
La configuration à déployer est affichée.
Il est possible de modifier des éléments pour les 2 nouveaux noeuds en cliquant sur le lien Edit à droite de chacun d’eux.
Si on choisit de customiser un nouveau node, un nouvel assistant s’ouvre.
Choisir le folder devant accueillir la VM.
Choisir le Host.
Choisir le datastore.
Choisir le ou les port groups. Seul le noeud passif aura 2 cartes, l’une sur le réseau de management pour prendre le relai du node actif et l’autre sur le réseau HA. Le noeud witness n’aura que le réseau HA.
Valider les informations.
La nouvelle configuration à déployer est affichée.
Une fois la configuration validée, un dernier écran de confirmation est affiché…
… puis les noeuds additionnels sont déployés…
… et la réplication est lancée.
Une fois la réplication terminée, HA est actif.
Configuration avancée
Il faut commencer par ajouter une carte réseau sur le vCenter.
Se connecter sur l’interface de management de l’appliance : https://<venter_fqdn_ou_ip>:5480
Dans la partie Networking, on voit bien la seconde carte, encore inutilisée. Cliquer sur Edit.
Donner l’adresse IP et le masque réseau à utiliser. Il doit s’agir d’un scope IP différent du réseau de management. A noter : dans cette interface le masque est à donner sous forme de préfixe (24 correspondant à 255.255.255.0).
Une fois validé on voit que la seconde carte réseau est active.
Revenir sur le vCenter à la page de configuration de vCenter HA, et cliquer sur Configure.
Choisir la configuration Advanced.
Donner les IPs et masque réseau pour les cartes HA des deux autres noeuds.
Ne pas cliquer sur Finish, il faut d’abord cloner le vCenter.
Soit laisser la fenêtre de configuration et ouvrir une autre session sur le vCenter, soit la réduire via la double flèche en haut à droite pour qu’elle passe en attente dans la colonne Work in prgress.
Lancer un premier clonage du vCenter.
Indiquer le nom de la VM et son emplacement.
Choisir le host. Même si on peut faire ensuite des règles d’anti-affinité, autant prendre directement un host différent de celui du vCenter.
Choisir le host et le mode de stockage. Même remarque que pour le host.
Cocher « Customize the operating system » et « Power on virtual machine after creation ».
Les règles de customisation peuvent avoir été créées à l’avance. Elles sont stockées dans « Policies and Profiles ». Mais autant les créer à la volée.
Cliquer sur l’ajout d’une spécification.
Donner un nom. C’est justement celui qui apparaîtra dans Policies and Profiles.
Indiquer le hostname (et pas le FQDN) du vCenter ainsi que son domaine.
Indiquer le même fuseau horaire que le vCenter actuel. Si nécessaire, il peut être retrouvé dans la section Time de l’interface de management de l’appliance.
Editer les propriétés de la première carte réseau.
Indiquer l’IP, le masque et la gateway du vCenter. C’est bien la même IP que le vCenter actuel.
Editer ensuite les propriétés de la seconde carte réseau.
Indiquer l’IP et le masque du réseau HA. Cette fois, c’est l’IP propre à ce node qui doit être indiquée.
Passer à la suite.
Renseigner les serveurs DNS ainsi que le suffixe de recherche DNS.
Vérifier et valider pour créer la spécification.
Sélectionner la spécification nouvellement créée et cliquer sur Next.
Valider les informations pour lancer le clonage.
Répéter alors l’opération de clonage pour le troisième node.
Au moment des spécifications, il est possible d’éditer celle existante au lieu de tout recréer, cela génèrera un clone de la spécification, et il n’y aura qu’à changer l’IP de la second carte pour obtenir la spécification du dernier noeud.
Une fois les 2 clones créés, revenir sur l’assistant de configuration de vCenter HA.
Les deux clones ont été créés à l’identique, qu’il s’agisse du noeud passif ou du noeud témoin. C’est l’IP secondaire configurée qui permettra à l’assistant d’identifier quel clone a quelle fonction.
Valider les informations et cliquer sur Finish.
vCenter HA est configuré.
Test de vCenter HA
Dans la situation initiale, on voit bien que c’est le vCenter initial, la VM SAVC06 qui a l’IP de management du vCenter 192.168.3.6.
J’ai désactivé la fonction HA du cluster (le HA classique, pas celui du vCenter) pour éviter que la VM vCenter soit redémarrée automatiquement, puis j’ai coupé le host qui l’hébergeait.
Immédiatement un rafraîchissement de la page de vSphere Web Client a montré que le vCenter n’était plus joignable.
Après un peu plus d’une minute, un rafraîchissement a montré cette page.
Après encore un moment, la page a été remplacée par celle-ci (comme lors du démarrage d’un vCenter, lorsqu’il affiche qu’il est prêt mais que le vSphere Client server n’est pas encore démarré.
Un peu plus de 9 minutes après la coupure, il est de nouveau possible de se connecter au vCenter.
On voit bien que la VM initiale est Disconnected, et dans vCenter HA elle est marquée down et passive, alors que la VM initialement Passive est devenue Active.
Après redémarrage du host et de la VM, vCenter HA la détecte bien online et indique qu’il y a un problème de réplication.
Après quelques minutes, les noeuds sont synchronisés est tout est marqué OK.
La VM initiale est toujours Passive, et c’est le noeud initialement Passif qui reste bien Actif.
On voit d’ailleurs que c’est bien lui qui porte désormais l’IP de management du vCenter.
D’accord j’ai fait mon test sur un lab avec des hosts virtuels hébergeant eux-même des VMs, donc la réactivité est moindre qu’avec une infra de production comprenant de vrais serveurs physiques. Le vCenter sera peut-être disponible en quelques minutes au lieu d’une dizaine.
Mais je trouve qu’on est plutôt dans la continuation d’activité que dans la vraie haute disponibilité.
N’empêche, vCenter HA reste une fonctionnalité intéressante.
En cas de perte du datastore hébergeant le vCenter par exemple, cas où le HA classique ne peut pas grand chose, le vCenter HA sera bien plus réactif qu’une action manuelle pour récupérer le vCenter.
A noter que la durée est à peu près la même en cas de bascule manuelle, pour une maintenance par exemple.
