J’ai fait le tour de tout ce qui concernait le DR dans la part I. Ici, je vais maintenant détailler les autres “petites nouveautés”.

Plus de détail sera apporté à la vue “Data Resiliency Status”. Je trouve que c’est pratique de retrouver l’information ici, rapidement, plutôt que d’aller chercher en ligne de commande. En image voici concrètement ce que cela donne pour un nœud en panne sur un cluster de 3 :

À savoir, le statut sera toujours noté “Computing” pendant un upgrade. J’avais déjà proposé une amélioration à ce sujet, pour mettre en sourdine les évènements liés à l’opération ce qui nous laisserait les logs plus lisibles, mais c’est en attente.

Ensuite, il y a un nouveau mécanisme d’optimisation concernant les snapshots, appelé Merge vBlock Metadata. Il permettra de limiter la perte d’IOPS avec les snapshots cumulatifs lorsque les metadatas ne proviennent pas du cache, ce qui arrive avec un changement de working set ou le reboot de stargate.

Dans le détail, lorsque nous avons une chaîne de snapshot, la donnée lue doit parfois traverser 6 entrées de vblock dans Cassandra contre 2 seulement avec les Merge vBlock. Concrètement, les gains sont de 30% sur de la lecture aléatoire au dixième snapshots et plus encore sur la relance d’un stargate.

Par contre, cette fonctionnalité est volontairement limitée aux clusters qui disposent de nœud d’une capacité de stockage entre 60 et 70TB. Cette limitation baissera avec le temps. Autre limitation, mais qui ne changera pas, Merged vblock est automatiquement désactivé s’il y a la de-duplication activée sur le conteneur. Bonne nouvelle cette technologie n’est pas soumise à un licensing particulier et tous les hyperviseurs pourront en bénéficier.

La fonctionnalité Rack Awareness est également disponible sur Hyper-V, donc tous les hyperviseurs sont maintenant supportés.

En 5.17, Nutanix Volumes supporte officiellement Windows Server 2019, idéal pour les serveurs bare metal et le Windows Failover Cluster.

Enfin la simplification du clustering avec Volumes qui supporte les réservations persistantes SCSI-3, qui évitera d’aller dans la VM pour réaliser la connexion iSCSI.

L’Erasure Coding est maintenant pleinement opérationnel avec Autonomous Extent Store (AES). Pour rappel AES introduit en 5.11 permet l’amélioration des performances en conservant une partie des metadatas sur le nœud qui exécute le worload. Nutanix Bible parle de METAdata locality, je trouve ça très explicite.

Pour terminer, le licensing pour Object est maintenant géré depuis Prism Central. Mercury sera la nouvelle passerelle API développé en C++ pour diverses optimisations et Prism Central pourra supporter jusqu’à 300 clusters (avec un noeud chacun) et 25 000 VMs. Uniquement pour les nouveaux déploiements de Prism Central, il y aura la possibilité d’améliorer les performances en répartissant la charge sur plusieurs vDisks.

N’hésitez pas à donner votre avis en commentaire, mais je trouve cette mise à jour impressionnante. Elle apporte une réponse à ce que pas mal de clients demandent depuis quelque temps. Même si tout n’est pas encore implémenté, les briques sont là et les prochaines versions viendront améliorer tout ça !

Je ne l’avais pas anticipé, mais lors de la suppression d’une VM VDI Côté Xendesktop, le nettoyage du Protection Domain côté Nutanix n’est pas automatique si bien qu’hier j’ai eu un petit warning “Unable to locate VM with name ‘VM_Name and internal ID ‘60069aa8-29d5-2c52-6827-945372df5a5a’ in protection domain ‘ProtectionDomain_Name’.

Capture

Voici le script que j’utilise pour faire le nettoyage :

#Chargement des Addins
Add-PSSnapin Citrix*
Add-PSSnapin Nutanix*

#Renseigner votre broker Xendesktop
$XenBroker = Read-Host "Broker_name"

#Renseigner vos IP CVM Nutanix
$NutanixCluster1 = Read-Host "IP_VCM_Cluster1"
$NutanixCluster2 = Read-Host "IP_VCM_Cluster2"

#Connexion aux clusters Nutanix
Connect-NTNXCluster -Server:$NutanixCluster1 -UserName:admin -AcceptInvalidSSLCerts
Connect-NTNXCluster -Server:$NutanixCluster2 -UserName:admin -AcceptInvalidSSLCerts

#Recupération des VDI Xen
$VDIs=Get-ProvVM -AdminAddress $XenBroker

#Création de la liste des VDI Xen
$XEN_VMs = $VDIs.VMName

#Récuperation de la liste de Protection Domain Nutanix
$NUT_VMs = Get-NTNXPRotectionDomain

#Création de la liste des VM Nutanix
$NUT_VMS = $NUT_VMS.vms.vmName

#Comparaison des deux precedentes listes, conservation des machines présentent côté nutanix, absentent côté Vdi Xendesktop
$VMs2Delete = Compare-Object -ReferenceObject $NUT_VMs -DifferenceObject $XEN_VMs | Where { $_.SideIndicator -eq "<=" }

#Pour chaque VM de cette liste à supprimer, recuperation du Protection Domaine associé et suppression de la VM de celui-ci
foreach ($VM in $VMs2Delete) {
$ProtectionDomain = Get-NTNXProtectionDomain | Where {$_.vms.vmname -like $VM.InputObject}
Remove-NTNXProtectionDomainVM -name $ProtectionDomain.name -input $VM.InputObject
}

#Déco et fin du script
Disconnect-NTNXCluster *

Il y aura un peu de rouge à l’exécution étant donné que le script essayera de supprimer la VM sur les 2 Sites donc pas d’inquiétude.

Pour cet article, je partirai du principe que vous avez les bases pour monter une infra nutanix et xendesktop, le point ici concerne spécifiquement la réplication asynchrone de VDI Xendesktop provisionné par MCS pour des machines persistantes évidemment.

La réplication en mode synchrone ne posera aucun problème, car elle fonctionne au niveau du datastore et ne sera donc pas traitée dans l’article.

Oui, il est possible d’avoir une réplication asynchrone de VM VDI généré par Machine Creation Service de Xendesktop entre deux clusters Nutanix sur du VMware ,et je vais vous expliquer comment !

Voici les bases de notre archi, 2 datacenters ayant chacun leur vCenter (5.5), un cluster de 3 nœuds Nutanix (4.5.2) et un broker Xendesktop (7.7).

Avec MCS, un basedisk est créé dans un répertoire portant le nom du catalogue Xendesktop, ce sont ces fichiers en plus de la VDI qu’il faut répliquer.

La documentation nutanix “Prism Web Console Guide” traite de ce point mais de façon incomplète :

nuta-xen-doc

En effet, il est clairement indiqué que les “linked clones” et leurs disques de bases doivent être hébergés dans le même groupe de consistance et le même domaine de protection.

nuta-linked

Il faut donc absolument spécifier le même groupe de consistance que celui de la VM à basculer.

/!\ attention, je simplifie volontairement ici avec une seule machine en partant du principe que vous avez conservez les options par défaut pendant la configuration du domaine de protection.

nuta-update-pd

Avec la commande ci-dessous on liste les groupes de protections, les noms des groupes de consistance ainsi que les fichiers ajoutés manuellement à la synchronisation:

ncli> pd ls

 

Puis on complète la ligne de commande dans la documentation :

ncli> protection-domain protect \ files=/container1/view-gold-image/replica-ABC.vmdk name=vmware1-pd  cg-name=vmware1-cg

 

En rapport avec les captures d’écrans cela donne:

ncli> protection-domain protect files=/nom_du_container/chemin_vers_basedisk/date_du_snapshot_xendesktop.vmdk name=test_VM cg-name=test_VM
ncli> protection-domain protect files=/nom_du_container/chemin_vers_basedisk/date_du_snapshot_xendesktop-flat.vmdk name=test_VM cg-name=test_VM

 

L’argument “cg-name” vous évite à la réplication le message d’erreur suivant : “Snapshot of Protection Domain PD_name failed as some files in consistence group CG_name are common with another consistence group” :

nuta_alert

Une fois la réplication opérationnelle avec toutes les dépendances, deuxième problématique, le  “parentFileNameHint” ce point mérite d’être mis en avant, car il est très simple à éviter.

Après un migrate Nutanix, notre VM était bien basculée sur le site distant mais impossible de la démarrer.

“An unexpected error was received from the ESX host while powering on VM VM_name.
Reason: Reason
Cannot open the disk disk_name or one of the snapshot disks it depends on.”

nuta_poweron

Comme pour un “linked clone”, la machine ne trouvait pas le chemin vers son disque de base, cette valeur étant renseignée dans le paramètre “parentFileNameHint” du vmdk de la machine.

Ce chemin n’était pas correct, car dans notre cas l’ID du volume VMFS était celui du site source. Oui, vous avez bien lu, l’ID et non l’UUID, car les montages NFS n’en ont pas et sont simplement hashés. J’ai obtenu cette information sur ce site : NFS datastore does not have a UUID.

Il faut donc impérativement avoir les mêmes noms de conteneurs nutanix, étrangement ce conseil entre en parfaite opposition avec l’un des points de la documentation pour une config mono vCenter :

nuta_vc

Une fois les “remotes sites” nutanix reconfigurés plus de problèmes, les machines s’éteignent, se réenregistrent sur le vCenter du site distant et sont fonctionnelles.

Je viendrai enrichir ce billet dès que possible, en attendant n’hésitez pas à poser vos questions en commentaire si vous avez des difficultés avec cette configuration.