mercredi 14 mars 2018

vCenter HA


Principe

Cette fonctionnalité permet de protéger l’appliance vCenter. Vous l’avez compris cette fonctionnalité n’est pas disponible pour vCenter installé sur un OS Windows. On sent donc la volonté de VMware de continuer à améliorer et pousser la version appliance de vCenter au détriment de la version Windows.

Il s’agit donc de créer une VM vCenter de reprise afin de limiter le temps d’indisponibilité du service vCenter. Cela peut être vraiment intéressant sur vous disposez de serveurs ESXi sans stockage partagé ou si vous avez 2 clusters HA distincts. Vous pouvez alors placer les VMs principales et secondaire sur des cluster (ou site) différents.

La VM de reprise est maintenue à jour grâce à une réplication depuis le vCenter principal.

De plus, cette fonctionnalité fait appel à une VM dite « Témoin » permettant d’automatiser la détection de panne et donc la bascule depuis la VM vCenter principale vers la VM de secours.




On comprend grâce au schéma ci-dessus qu’on utilise un réseau de réplication privé en plus du réseau de management public. Chaque nœud (VM Active / VM Passive / VM témoin) dispose d’une adresse IP dans ce réseau de réplication. Parcontre, seule la VM Active dispose de l’adresse IP publique de management du vCenter.


Prérequis

Pour mettre en place la fonctionnalité vCenter HA, vous aurez besoin :
·       D'une licence vCenter standard
·       De vCenter 6.5 minimum
·       De serveurs ESXi 5.5 minimum
·       D'au moins 3 serveurs ESXi afin que les 3 noeuds (Actif/passif/témoin) ne soient pas sur le même ESXi
·       D’un VLAN dédié pour le réseau de réplication avec 3 adresses IP (1 pour chaque noeud: Actif/Passif/témoin)
·       Ce VLAN doit être propagé sur tous les ESXi, mais il n'a pas besoin d'être routé vers d'autres VLANs.
·       Ce VLAN de réplication doit avoir une latence inférieure à 10ms entre les noeuds actif/passif/témoin
·       Créer un portgroup ou dvPortgroup pour ce VLAN.
·       Disposer d'un compte « administrateur » sur la plateforme VMware



Mise en place 

Se connecter au vCenter actif avec un compte administrateur, puis sélectionner le vCenter (la racine de l’arborescence) et aller dans configuration. Ensuite cliquer sur "vCenter HA" puis le bouton "Configurer" en haut à droite:

Choisir la configuration de base afin que le wizard s’occupe de tout (ajout d’une carte réseau sur l’appliance vCenter / clonage pour les noeuds passif et témoin / configuration de la réplication). La configuration avancée pourra servir dans des cas spécifiques comme par exemple lorsque le PSC est externe au vCenter :

Indiquer l'adresse IP de réplication (réseau privé) du nœud actif:

Indiquer les adresses IP de réplication (réseau privé) des nœuds passif et témoin:

Faire le "mapping" en plaçant les nœuds sur les bons éléments:


Valider pour lancer la déploiement:

Une fois l’installation terminée, vous pouvez voir que les 3 nœuds sont opérationnels :

Test de bascule

Lorsqu'un nœud tombe ou qu'on initie une bascule volontairement, le nœud passif récupère l’adresse IP publique puis lance tous les services vCenter. L’interface Web affiche alors le message « Failover in progress » :

Puis après quelques minutes, la console se recharge automatiquement :)

Afin de tester le bon fonctionnement, vous pouvez par exemple éteindre la VM principale. Le nœud passif deviendra alors actif. Lorsque la VM principale revient à la vie, le rôle reste hébergé sur la VM secondaire. Vous pouvez alors initier un basculement manuel si vous souhaitez que la VM principal héberge le rôle à nouveau.

Pour plus d'informations sur la fonctionnalité VMware vCenter HA, je vous laisse consulter la documentation officielle: https://docs.vmware.com/fr/VMware-vSphere/6.5/vsphere-esxi-vcenter-server-65-availability-guide.pdf




vendredi 15 décembre 2017

[Zerto] Déclencher un FailOver 3/3 [Rollback ou Commit après un failover]

Rollback après failover Pas besoin de conserver les modifications apportées aux VMs du site de DR


Choisir cette option signifie que vous allez revenir à l'état initial des VMs.
Sur l'onglet “Dashboard“ vous pouvez voir une tâche attendant une action de votre part

Sélectionner la flêche rouge “Rollback”

Cela va automatiquement stopper les VMs du site de DR, les retirer de l'inventaire du vCenter cible,
et les redémarrer sur le site de production.

Rollback après failover Besoin de conserver les modifications apportées aux VMs du site de DR

Choisir cette option signifie que vous allez conserver les VMs dans leur état actuel sur
le site de DR.
Sur l'onglet “Dashboard“ vous pouvez voir une tâche attendant une action de votre part



Sélectionnez l'option “Commit”.


=> Attention : Dès lors que vous aurez cliqué sur "Commit", il vous sera IMPOSSIBLE de revenir
en arrière !!

Laissez “Reverse Protection” coché



Cela va automatiquement supprimer de l'inventaire du vCenter de production les VMs, et les VMs
du site de DR seront considérées comme définitivement actives.
En ayant laissé coché "Reverse protection", la protection inverse des Vms du VPG
se fait automatiquement.

Si toutes fois vous décochez la case, vous devrez éditer le VPG pour terminer la configuration
en indiquant vers quel datastore vous souhaitez les protéger.



[Zerto] Déclencher un FailOver 2/3 [Utilisation des checkpoints]

Revenir à un état précédent d'un VPG en utilisant les checkpoints.


Sur l'onglet "Dashboard" vous pouvez voir une tâche attendant une action de votre part :
Commit ou Rollback


Selectionnez la flêche rouge “Rollback”

Cel va automatiquement (et instantanément) stoper les VMs sur le site de DR, et les supprimer de
l'inventaire du vCenter. Cela va également redémarrer les VMs sur le site de Production.
Il vous faut de nouveau arrêter la/les VMs que vous voulez faire démarrer sur le site de DR.

Donc, de nouveau, allez sur l'onglet VPGs ...


... et sélectionnez le VPG à basculer...


...Selectionnez “LIVE”...


… and et cliquez sur la flêche rouge “FAILOVER”


Vérifiez que votre VPG est bien selectionné et cliquez sur “NEXT”


Cliquez alors sur la colonne“Checkpoint” ….
…. et sélectionnez checkpoint à une date antérieure à celle précédemment utilisée
Par défaut, lors d'une bascule, Zerto sélectionne le dernier checkpoint pris.


Cliquez sur “Next” puis sur “ START FAILOVER”


Les VMs du VPG démarrent de nouveau sur le site de DR.
Si de nouveau, l'état des VMs ne vous convient pas, recommencez l'opération en sélectionnant
un autre checkpoint.


Si au contraire, vous validez l'état des VMs démarrées sur le site de DR, vous devez décider si
vous voulez conserver les modifications apportées aux VMs sur le site de DR ou pas.

Rollback ou commit après FailOver


[Zerto] Déclencher un FailOver 1/3 [Bascule sans auto-commit]

Déclencher un "faux" Live Failover 1/3

Le but de déclencher un "faux" Live Failover, est de valider la protection des applications entre les
2 sites (production et DR site)
-> Dans notre cas, nous n'avons pas de réseau dédié au test : ils doivent donc se faire sur le réseau
de production


Suivez les instructions suivantes afin de tester votre failover , sans impacter la production sur le site principal.

Vous devez d'abord stopper les VMs du site principal.

Vous pouvez les stop par l'OS ou par le client vSphere:

:
WARNING :Il est essentiel de vérifier dans le client vSphere que la/les VMs sont bien arrêtées !!


Loguez vous sur les ZVM du site de DR, pour se mettre en situation cible.


Utilisez votre login / password et cliquez sur “LOGIN”




Allez sur l'onglet VPGs ...


... select the VPG you need to Failover ...


...Selectionnez “LIVE”...


… et cliquez sur la flêche rouge “FAILOVER”


Vérifiez que votre VPG est selectionné et cliquez sor “NEXT”


Il faut maintenant vérifier les éléments suivants:
  • Commit Policy :DOIT être à “NONE”
  • VM Shutdown : DOIT être à “No”. Rappellez vous que les VMs ont déjà été stopées précédemment




Cliquez maintenant “Next” puis sur “ START FAILOVER”


La bascule commence.
Notez que la VM arretée sur le vcenter source reste inventoriée et n'est pas supprimée:


Cette même VM est alors inventoriée et démarrée sur le vCenter du site de DR :


=> C'est pour éviter tout problème qu'il faut absolument vérifier que la VM du site source est bien
arrêtée

Vous pouvez maintenant tester l'application sur le site de DR. Si vous n'êtes pas satisfait de l'état
des VMs (une des VMs ne boote pas, n'est pas stable ou de façon plus générale, n'est pas dans
un état qui vous convient), vous pouvez utiliser les checkpoints : ce sont des points de consistance
de chaque VM stockés sur le site de DR.

jeudi 16 février 2017

vExpert 2017


C'est avec beaucoup de fierté que j'apprends avoir été élu vExpert pour la 2e année consécutive. C'est un immense plaisir de faire parti de ce programme :) Merci à VMware pour votre soutien.

Je tiens également à féliciter mon co-blogger et ami Guillaume qui lui aussi a été élu vExpert 2017 !
J'en profite aussi, pour tous vous remercier de suivre notre blog.

Vous trouverez la liste complète des vExperts 2017 ici



jeudi 26 janvier 2017

[Formation] Comment bien se former sur VMware

Je discute avec beaucoup d'administrateurs Système\Virtu qui gèrent souvent un petit parc (entre 3 à 10 ESXi) et ils aimeraient bien se former à VMware, mais à leur rythme et quand ils ont du temps…

Voici plusieurs moyens de se former à VMware:

vendredi 13 janvier 2017