VMware : vCenter HA pour une disponibilité maximale de vos plateformes    

Le serveur vCenter est un composant très critique de notre environnement de virtualisation, la console d’administration principale et beaucoup d’autres produits sont relais au vCenter Server API en ce qui concerne leur propre fonctionnalité.

Depuis la version 6.5 de vSphere, VMware a intégré une nouvelle fonctionnalité pour la mise en place d’une architecture hautement disponible du vCenter

Avec une architecture active passive basée sur 3 nodes, vCenter Server High Availability nous permet d’avoir un RPO=0 et un RTO de quelques minutes (10 minutes dans notre infrastructure).

Les 3 nodes peuvent être installés sur des serveurs ESXi 5.5 et d’au moins 3 afin qu’elles ne soient pas sur le même serveur. Idéalement aussi trois datastores pour une disponibilité maximale.

Active Node : Le serveur vCenter protégés est appelé l’active node

Passive Node : Le serveur vCenter crée par le clonage de l’active node avec les mêmes ressources (CPU, RAM et HDD)

Witeness Node : le serveur vCenter qui forme le cluster quorum. En termes de configuration il n’a pas les mêmes ressources que l’active et joue le rôle d’un split-brain dans un environnement de HA.

Il existe deux façons pour mettre en place l’architecture :

• Mode Basic : pour la configuration automatique à condition que la VM VCSA doit être dans l’inventaire du vCenter.
• Mode Advanced : pour une configuration manuelle, les nœuds seront clonés et configurés manuellement.

Dans les deux cas l’installation est très simple. Il suffit de suivre les opérations basiques de clonage et le vCenter va faire le travail. Soyez sûr tout de même que l’SSH est active sur les 3 nodes, le serveur NTP est bien configuré et que l’active et le passive nodes sont dans le même vCenter SSO.

En cas de soucis, vous pouvez regarder dans les logs /var/log/vmware/vcha.

Après l’installation, un seul node réussi a créé le lock sur le cluster et assume le rôle active et le node passif assume le rôle et surveille le lock du cluster.

Les 4 services utilisés pour former le cluster sont :

1. vMon Watchdog : c’est un service exécuté dans l’actif et le passif node qui a la responsabilité du contrôle des autres services ( start stop)
2. Postgres Service : c’est un processus responsable de la réplication de la base de données entre le master Postgres dans l’active node et le slave Postgres dans le passive node (Toute transaction sur le master est également répliquée sur le slave).
3. FDM Agent : c’est un agent utilisé pour la gestion du cluster (Fault Domain Manager) qui se trouve sur les 3 nodes entant que master sur le node active et slave sur les nodes passive et Witeness.
4. vCenter HA Service : c’est le composant principal pour la configuration de vCenter HA. Il permet la réplication du fichier de configuration en utilisation Linux Rsync.

La réplication de la base de données et le fichier de configuration est assurée par le réseau vCenter HA configuré entre les trois nodes. L’un des prérequis c’est qu’il doit avoir une latence inférieure à 10ms.

vPostgres native réplication est utilisé pour la réplication entre les deux databases Master et Slave, l’utilitaire Linux Rsync est utilisé pour synchroniser les fichiers entre les deux nodes et pour bien identifier les changements l’architecture utilise iNotify qui permet de positionner un watch descriptor sur les fichiers, qui lui enverra des notifications au système en cas des changements afin de déclencher la réplication

/etc/vmware/service-state pour les petits fichiers tels que le fichier de configuration

/storage/service-state pour les fichiers volumineux tels que les patches dans update manager, les images ESXi, et l’auto deploy cache.

Si la réplication tombe en erreur la liste des fichiers non répliqués sont stockés dans /storage/vcha/ et l’automatic failover entre les deux nodes est désactivé jusqu’à la réplication de tous les fichiers.

La configuration du vCenter HA peut être dans l’une des trois modes :

Le statut de VCSA HA peut être dans l’une de trois cas :

Si le node active est déclaré inactive, il y aura le basculement sur le node passive et ce selon l’ordre ci-dessous :

• Étape 1 : le lock cluster sera relâché
• Étape 2 : le node passive est averti qui le lock cluster est libéré
• Étape 3 : le node passive active l’adresse IP publique du cluster sur vNIC0
• Étape 4 : la base des données slave est convertie en master
• Étape 5 : le service vMon démarre les services dans le passif node
• Étape 6 : le node passive est maintenant active
• Étape 7 : une alerte déclenchée pour un cluster en situation dégradée

Durant le temps de basculement vSphere web client sera inaccessible

Pour mettre à jour un vCenter configuré en HA, vous devez placer la configuration en mode maintenance afin de mettre en pause la réplication et appliquer le patch sur les trois nodes mais attention il y a un ordre à respecter :

• Étape 0 : identifier les nodes
• Étape 1 : mettre le cluster en mode maintenance
• Étape 2 : appliquer les mises à jour sur le node passive
• Étape 3 : lancer un basculement manuel entre les deux nodes
• Étape 4 : appliquer les mises à jour sur le node active
• Étape 5 : appliquer les mises à jour sur le node Witeness
• Étape 6 : quitter le mode maintenance

Dans l’ensemble, le processus prendra moins de 20 minutes par nodes pour effectuer la mise à niveau complète, mais le plus important que le vCenter restera toujours disponible.

N’hésitez pas aussi de consulter les deux KBs VMware ci-dessous :

https://kb.vmware.com/s/article/2148003

https://kb.vmware.com/s/article/2151548