On a maintenant un stockage partagé sur notre cluster, cela est très intéressant car il va permettre de faire bouger les VMs qu’il héberge d’un ESX à l’autre.
cette fonction se nomme le vMotion. Elle permet de transférer la ram et le contexte CPU d’une VM entre 2 ESX. Les 2 serveurs ayant accès au stockage de la VM, cela se fait rapidement et à chaud.
Avant de commencer, on va créer une nouvelle VM sur ce stockage.
Pour changer on va installer une VM Linux avec LUBUNTU (version light d’Ubuntu)
On sélectionne un ESX puis clic droit / Nouvelle machine virtuelle
On choisit forcément de la mettre sur le datastore partagé
Une fois que la paramétrage est fini, on dépose l’ISO pour l’install sur le datstore local de l’ESX.
On modifie le cdrom pour utiliser l’image et il ne faut pas oublier de cocher la case pour le connecter au démarrage.
Si vous ne l’avez pas encore fait, il faut installer la console distante VMRC
L’install de l’OS se finie, la VM redémarre et tada!!!! un ecran noir 
Bon on arrête la VM, on modifie les paramètre de la carte vidéo pour les passer sur Détection automatique
On redémarre et c’est bon !!
On passe à la conf du réseau et on ajoute une entrée dans le DNS
C’est un bon début !!!
Notre VM est presque prête
On va en profiter opur installer les VMware tools sous linux.
Depuis la console vCenter, dans le résumé de la VM, il y a une alarme qui indique qu’ils ne sont pas installé avec un lien pour le faire, on clique dessus.
cela va connecter un cdrom avec le programme d’installation
On monte le cdrom
On copie l’archive dans un répertoire temporaire, on lance l’extraction puis l’install
On garde tous les paramètres par défaut
Mise en place du réseau de vMotion
Avant de déplacer des VMs, il faut créer un réseau spécifique de type VMkernel qui aura comme rôle de gérer le trafic de vMotion.
On va modifier la conf réseau du premier ESX, on sélectionne le vSwitch0
On clique sur le premier bouton (ajouter la mise en réseau…)
C’est un réseau pour l’ESX, il aura une IP, c’est un réseau VMkernel.
Il sera associé au switch virtuel 0
On le nomme vMotion et on coche la case pour indiquer qu’il va gérer le trafic vMotion
Remarque: depuis le début, j’utilise un masque réseau en 255.255.255 pour isoler les différents réseau (Management, réseau de VM, iSCSI, vMotion…) c’est la solution simple pour faire les choses au minimum un peu propres sur le lab.
En environnement de production, l’utilisation de VLAN est fortement recommandée, il y aura de la conf réseau à faire sur les ESX, pour taguer les différents flux et sur les switchs réseau en passant les interfaces en mode trunk pour faire transiter tous les vlans.
On paramètre une IP (voir la partie Architecture du lab pour les détails)
Notre nouveau réseau est en place, il faut faire exactement la même chose (à part l’@IP) sur l’autre ESX
Paramétrage du cluster
Avant de passer au test, il faut activer 2 fonctions sur le cluster HA et DRS
HA Hight Availability: va permettre de faire du vMotion
DRS Distributed Ressources Scheduler: on verra plus tard 😀
On sélectionne le cluster puis Paramètres et on active les 2.
On laisse les options par défaut
Après quelques instants, HA est installé et on se récupère pleins de Warnings sur les ESX.
HA Error: The number of heartbeat datastores for host is 1, which is less than required: 2 (2004739)
Pour surveiller l’état du cluster, les ESX, en plus du LAN , utilisent les banques de stockage comme signal de pulsation, il en faut par défaut 2, si vous n’en avez qu’une, on peut forcer le paramétrage
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2004739
Network redundancy message when configuring VMware High Availability in vCenter Server (1004700)
Dan mon lab, je n’ai qu’une seule carte qui transporte le management de l’ESX, pour des raisons de sécurité, il en faudrait normalement 2, on peut également forcer le fait de n’en avoir qu’une seule
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1004700
C’est bon, plus de warning !!
On peut voir les 2 variables que j’ai ajoutée dans le cluster au niveau des paramètres avancés.
Déplacement de la VM
On peut enfin sélectionner la VM SRV-LUBUNTU qui se trouve sur le serveur SRV-ESX2 puis clis droit et Migrer
On souhaite la passer sur SRV-ESX1
(attention de bien déconnecter le cdrom sur la VM)
On vérifie que la VM est sur SRV-ESX2, on prépare un ping et ….
Comme dirait ma petite princesse:
Prêt, feu, go , partez !!!! 😀
La tâche se lance
On perd un ping à cause du rafraichissement de la table ARP du switch…
Comme toujours, c’est la faute des mecs du réseau….
C’est fini, cela aura pris env 1 minute, la VM a perdu juste un ping, elle est maintenant sur SRV-ESX1.
Cette fonctionnalité est vraiment super pratique, elle permet d’équilibrer la charge entre les ESX en déplaçant facilement les VMs.
En cas de maintenance ou d’upgrade d’un ESX, on peut déplacer les VMs sur les autres sans fenêtre d’arrêt…
Cela implique de bien faire le sizing et le design du cluster avant de mettre en place une infra. Il faut toujours prévoir des ressources CPU et RAM suffisantes sur les ESX pour pouvoir déplacer les VMs en cas d’arrêt d’un ESX.
—————————————————–
Le vMotion est OK, on va maintenant voir ce qu’il se passe
en cas de perte brutale d’un ESX, c’est l’autre avantage du HA
Test du HA
—————————————————–
vhlab - Virtu@l home lab 