Je ne vais pas faire durer plus longtemps le suspense, la réplication synchrone est arrivée sur AHV ! Cette release est le grand pas en avant que beaucoup de clients attendaient pour tout ce qui concerne la reprise sur sinistre (Disaster Recover – DR).

À nous le RPO 0, la simplicité de configuration d’une seule stratégie qui protégerait toutes nos VMs Mission Critical ! Contrairement au métro cluster sur ESXi qui fonctionne par datastore, ici la granularité est à la VM. On peut la mettre en pause, la stopper et l’appliquer au travers de catégories.

Concernant les contraintes et prérequis un petit schéma vaut mieux que mille mots :

En premier lieu, il faut un Prism Central (PC) sur chaque site. Pour cette première version, seule la bascule non planifiée (unplanned failover) est supportée. La bascule planifiée viendra par la suite pour démontrer aux divers auditeurs que vous avez testé votre scénario de bascule. Si vous lancez quand même la bascule aujourd’hui pour tester, cela généra un split brain. Il est conseillé d’éteindre les VMs avant 😉

Dans la même veine, pas d’option pour un témoin (witness), mais c’est prévu. Le failback fonctionne de la même façon (unplanned failover, éteindre les VMs, récupérer depuis le dernier point de récupération ou plus loin dans le temps comme sur Metro).

Pour les environnements qui ne nécessitent pas un RPO 0, il y a le Near-Sync d’une à quatorze minutes. Near-Sync était déjà disponible au niveau des Protections Domains historiques. Il est ici question de l’implémentation dans Leap, le moteur de bascule utilisé pour XI Leap. Pas de changement concernant les anciens prérequis du Near-sync. Enfin, la protection ne concerne que 100 VMs pour le moment, et cela devrait rapidement doubler.

AOS 5.17 apporte aussi le support d’un seul Prism Central pour Leap, s’il est utilisé pour les réplications asynchrones donc tout ce qui est au-delà de l’heure. Pas de Cross-Hypervisor DR non plus, la source et la destination doivent avoir le même hyperviseur, enfin le PC et le Prism Element (PE) doivent être en 5.17 tous les deux et disposer du mappage réseau dans le plan de récupération.

Single PC support for Leap

Enfin pour Metro ESXi uniquement, le support du near-sync, alors là vous vous dites que j’ai bugué, moi aussi je suis resté bloqué un moment pour comprendre. En plus du Metro entre votre Site A et B, vous cumulez le NearSync avec un site C, et si vous avez un site D (Flush Flash uniquement) vous pouvez ajouter une réplication Async de 3 minutes au niveau du conteneur. Le tout pilotable avec Site Recovery Manager (SRM) de VMware, en plus de Prism Element ! Ce scénario ne devrait intéresser qu’un petit nombre de clients haut de gamme avec des besoins vraiment spécifiques.

Demandé par de nombreux clients qui ont à cœur la séparation de leur flux réseaux pour des questions de sécurité principalement, et qui avaient sûrement déjà isolé leur flux Volumes (iSCSI) depuis la 5.11, voici la segmentation réseau pour la Réplication. Nous aurons la possibilité de créer un nouveau réseau pour la réplication externe. Supporté par ESXi et AHV, ce n’est pas compatible Leap, mais uniquement sur les Protections Domains. Attention, cela concerne plutôt les nouvelles installations. Sinon vous devrez supprimer le site distant et le refaire après avoir créé la nouvelle VIP pour ce trafic.

CVM Network Isolation

À la façon d’un VMware SRM, nous pouvons maintenant faire du mappage d’adresse IP statique dans Leap, ainsi que lancer un script pendant la séquence de démarrage de la VM :

C’est fini pour les nouveautés spécifiques au DR, la suite ici dans la partie 2 .

Nous n’arrivions pas à faire de remédiation d’un hôte ESXi, il fallait forcément le passer en maintenance « manuellement » avant, ce qui est fort peu pratique quand il y a plusieurs dizaines d’ESXi à mettre à jour.

La remédiation échouait avec les messages « Another Task is already in progress / Une autre tâche est déjà en cours. » et « The task failed because another task is currently in prgress. Either your task, the task that is in progress, or both tasks require exclusive execution. / La tâche a échoué car une autre tâche est actuellement en cours d’exécution. Votre tâche, la tâche qui est en cours d’exécution ou les deux tâches nécessitent une exécution exclusive ».

Dans les logs, on constate effectivement deux taches lancées en même temps par 2 composants :

La tache en erreur de com.vmware.vcIntegrity correspond à VMware Update Manager, com.vmware.vcHms correspond à vSphere Replication, mais pourquoi lancent-ils une tache en même temps ?

message du /var/log/esxupdate.log :
2020-01-15T14:08:31Z esxupdate: 4185081: esxupdate: ERROR: wmware.esximage.Errors.VibDownloadError: ('https://IP:8043/vib/vmware-hbr-agent.vib', None, '(\'https://IP:8043/vib/vmware-hbr-agent.vib\', \'/tmp/vibtransaction/tmp.vib\', \'[Errno 14] curl#56 - "Content-Length: in 200 response"\')')^@

Plusieurs KB VMware font référence à ce type de message d’erreurs, pas exactement pour le même problème, alors je prends contact avec le GSS VMware.

Ils m’indiquent que les deux seuls problèmes connus avec ce message sont référencés dans les KB vSphere replication 8.2. ESXi unable to download hbr-agent.vib « VibDownloadError » (75321) et ESXi hosts report vib errors after installing VMware vSphere Replication 5.6.x or later (2110304)

En premier lieu, nous vérifions la présence des vibs sur les ESXi

localcli software vib list | egrep -i "vr2c|hbr"
localcli software vib get | egrep -i "vr2c|hbr"

Les vibs sont bien installées, le workaround consiste à désactiver l’option d’installation automatique des vibs de vSphere Replication afin de ne plus entrer en conflit avec Update Manager, ce qui aura comme conséquence de devoir installer ces vibs « manuellement » sur les nouveaux ESXi.

Sur les appliances vSphere Replication le ssh n’est pas activé par défaut, ce que je m’empresse de faire à l’aide du script /usr/bin/enable-sshd.sh disponible en console cf: Unable to Establish an SSH Connection to the vSphere Replication Appliance

Je vérifie ensuite le paramètre hms-auto-install sur l’appliance en SSH

/opt/vmware/hms/bin/hms-configtool -cmd list | grep -i hms-auto-install-hbragent

Le retour est bien :

hms-auto-install-hbragent-vib = true

Je modifie la valeur :

/opt/vmware/hms/bin/hms-configtool -cmd reconfig -property hms-auto-install-hbragent-vib=false

Puis, je relance le service :

service hms restart

Après ces opérations, je lance une remédiation sur un des ESXi et l’opération de patching se passe correctement.

Je ne suis pas pleinement satisfait, car même si le patching se déroule normalement, des opérations supplémentaires sont à prévoir à l’installation de nouveau nœud, mais je vous indique une partie de la réponse du support à ce sujet : « There is no projected fix for this issue presently. Engineering are only providing us with the VR vib ‘auto-install’ disable option.
New hosts added to the cluster require a manual vib install or you can include the vib in a VUM baseline. »

J’essaye donc d’appliquer cette dernière recommandation et de créer une nouvelle baseline avec les vibs en suivant la KB75321.

Après récupération des vibs comme dans la procédure, j’essaye d’importer celle-ci dans Update Manager, mais j’ai un message d’erreur :

Il s’avère que le fichier fourni ne permet pas l’importation dans VMware Update Manager, il sert uniquement à l’installation sur l’ESXi. Le support est au courant et m’a confirmé qu’il n’y aurait pas d’autre workaround pour ce problème et m’a même conseillé de soumettre une feature request… Ce n’est pas une feature que d’avoir les deux produits qui fonctionnent « normalement » dans son infrastructure…

Si comme moi, vous avez un environnement Nutanix CE Nested avec peu de puissance, il n’est pas forcement évident d’héberger une VM Prism Central sur celui-ci, j’ai tenté l’opération à plusieurs reprises et j’ai systématiquement eu un kernel panic sur la VM.

J’ai donc installé le dernier Prism Central sur une autre infrastructure et je souhaite maintenant y connecter la Community Edition. Pour information cette configuration n’est vraiment pas idéale car de nombreuses options de Prism Central ne seront pas disponibles s’il n’est pas hébergé sur le cluster Nutanix.

Normalement il suffit simplement de cliquer sur Register or create new

Comme dit précédemment le Prism Central est déjà installé, je cherche simplement à m’y connecter.

Un résumé de l’impact de l’intégration du Prism Element à Prism central apparaît.

Je rentre les informations de connexion, puis je valide la connexion.

Malheureusement l’opération ne s’exécute pas entièrement.

L’opération échoue dès la vérification des prérequis avec le message d’erreur : The AOS version 2019.11.22 of this cluster is not compatible with the Prism Central version 5.11.2.1

The AOS version 2019.11.22 of this cluster is not compatible with the Prism Central version 5.11.2.1

Pour éviter cette erreur, il faut modifier le fichier json de compatibilité sur la VM Prism Central.

Le fichier se trouve à l'emplacement : 
~/prism/webapps/PrismGateway/WEB-INF/classes/prism_central_compatibility.json

J'en fait une copie par sécurité :
cp ~/prism/webapps/PrismGateway/WEB-INF/classes/prism_central_compatibility.json ~/prism/webapps/PrismGateway/WEB-INF/classes/prism_central_compatibility.json.bck

 puis je modifie comme suit :

{"minimum":"5.5","maximum":"2019.11.22","exceptions":{"versions":["5.6","5.8"]}}

Une fois le fichier modifié et sauvegardé, je retente l’opération qui cette fois est un succès.

Le Prism Element de la Comunity Edition est maintenant connecté à la dernière version en date de Prism Central !

Post-install

CVM

  • Ajout vlan tag : change_cvm_vlan 50
  • enlever vlan tag : change_cvm_vlan 0
  • change rf d’un container : ncli container edit rf=3 name=container_name
  • check du br0 : allssh manage_ovs show_uplinks
  • 10G uniquement dans le br0 : allssh manage_ovs --interfaces 10g update_uplinks
  • ncli cluster set-timezone timezone=Europe/Paris
  • cluster -s 192.168.0.110,192.168.0. 111,192.168.0.112 create
  • /etc/sysconfig/network-scripts/ifcfg-eth0

AHV

  • Changer le vlan d’AHV: ovs-vsctl set port br0 tag=50
  • retirer le vlan: ovs-vsctl set port br0 tag=0
  • chemin des fichiers conf réseaux : /etc/sysconfig/network-scripts/ifcfg-br0 puis Sudo systemctl restart network.service
  • Renommage AHV : /etc/sysconfig/network et /etc/hostname puis reboot du noeud
  • acli vm.list power_state=on
  • acli vm.shutdown
  • acli vm.off
  • Changement de vlan pour VM : acli vm.nic_get VMNAME -> acli vm.nic_update VMNAME MACADDRESS network=NETWORKDESTINATION
  • éteindre AFS : afs > infra.stop * puis infra.start *
  • changement d’interface active : ovs-appctl bond/set-active-passive br0-up eth3
  • Fallback vers active-backup : ovs-vsctl set port br0-up other_config:lacp-fallback- ab=true
  • En fonction du switch OVS LACP timer : ovs-vsctl set port br0-up other_config:lacp-time=fast
  • ncli cluster set-timezone timezone=Europe/Paris
  • ovs-vsctl show
  • ethtool eth0
  • ifup eth0 – ifdown eth0

ESX

  • Création portgroup : esxcli network vswitch standard portgroup add --portgroup-name=VM_VLAN_50 --vswitch-name=vSwitch0
  • Changement vlan portgroup : esxcfg-vswitch -p « VM_VLAN_50 » -v 50 vSwitch0
  • Assigner VM : Get-VM toto| Get-NetworkAdapter | Set-NetworkAdapter -StartConnected $true -NetworkName « $DRNetWorkLabel » -Confirm:$false -RunAsync

Prism Central

  • Application Deployement Error -> cluster --cluster_function_list="multicluster" -s [ip_address_PrismCentralVM] create
  • Reset Admin password : ncli user reset-password user-name="admin" password="Enter_New_Password" (c’est étrange mais parfois un peu long a prendre en compte)
  • add DNS parfois manuel obligatoire ncli cluster add-to-name-servers servers="192.168.0.50"
  • allssh sudo faillock --user admin --reset
  • ncli cluster set-timezone timezone=Europe/Paris

Diagnostique

CVM

  • passer une commande sur toutes les CVM : allssh
  • passer une commande sur tous les hôtes depuis une cvm : hostssh
  • verifier le vlan des cvm : hostssh « ovs-vsctl show | grep vnet[0-1] -A2 »
  • cluster status | grep -v UP
  • ncli -v
  • nodetool -h 0 ring
  • ncli cluster get-domain-fault-tolerance-status type=node
  • allssh df -h
  • Verif latence entre les CVMs : tailf ~nutanix/data/logs/sysstats/ping_cvm_hosts.INFO
  • connexion à l’hôte depuis la CVM : ssh [email protected]
  • hostssh ipmitool lan print | grep « ==\|IP Address\|MAC Address »
  • conf matériel : ncc hardware_info show_hardware_info

AHV

  • Change Buffer RX size AHV : si ethtool -S eth0 | grep -i error donne des rx_missed_errors ethtool -g eth0, voir le max possible puis ethtool -G eth0 rx 4096 ce n’est plus la recommandation du support
  • pb de disque : df -h voir cd data/logs tail hades.out voir cat hades.out | grep -C enfin restart hades pour voir le nouveau disque
  • verif latence entre les hotes : tailf ~nutanix/data/logs/sysstats/ping_hosts.INFO
  • connexion à la CVM depuis l’hôte ssh [email protected]
  • virsh list – virsh start
  • conf dhcp iDrac : ipmitool lan set 1 ipsrc dhcp
  • reset impi : ipmitool mc reset cold

LCM

  • url par defaut : http://download.nutanix.com/lcm/2.0

Mais le VMUG qu’est-ce que c’est ? Derrière ces initiales se cache le VMware User Group, autrement dit, le groupe des utilisateurs VMware. Historiquement, les membres se retrouvaient sur un forum où chacun était libre de poser ses questions. C’est vrai que les forums ne sont plus trop tendances et que VMware a bien centralisé les choses avec VMware Technology Network (VMTN) en intégrant un forum énorme, très bien référencé par Google, qui permet généralement de s’en sortir lorsqu’on rencontre un problème.

Pas besoin d’être un expert ! Le VMUG est ouvert à tous. L’important c’est de partager autour des technologies et de l’écosystème VMware.

Lire la suite de