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 !

A la suite de mon précédent article « Nutanix Async DR  with Citrix Xendesktop MCS VDI« , le point a été remonté chez Nutanix et la prochaine mise à jour de la documentation devrait éclaircir les choses la dessus.

J’avais des réplications fonctionnelles, mais une autre limitation du design été en train de me poser problème.

En version 4.5 d’après la doc Nutanix « System Maximums », nous ne pouvons avoir plus de 50 VMs par Protection Domain, consistency group, ou SRA.

Nous avons donc décidé d’automatiser la création des « Protection Domains » de sortent que tous les soirs chaque nouvelle VM soit protégée et répliquée.

Je ne vais pas poster ici le script, car il est vraiment spécifique à notre environnement, mais je vais lister les commandes Nutanix utilisées.

J’ai vraiment eu beaucoup de mal à trouver des exemples et de la documentation pour certaines :

# Création d'un ProtectionDomain
Add-NTNXProtectionDomain -PDName "My_PD"
#Ajout d'une VM à ce Protection Domain
Add-NTNXProtectionDomainVM -PDName "My_PD" -names "My_VM"

Évidemment Attention si vous êtes dans un scenario VDI Xendesktop MCS comme moi, cette commande ne fonctionne que pour synchroniser une machine, les suivantes ne seraient pas dans le bon « Consistency Group »

#Ajout d'une VM à ce Protection Domain avec le meme nom de "Consistency group" 
Add-NTNXProtectionDomainVM -PDName "My_PD" -names "My_VM" -ConsistencyGroupName "My_PD"
#Création d'une tache planifiée associée au précédent Protection Domain
# qui tournera tous les jours à 00:01
Add-NTNXProtectionDomainCronSchedule -Name "My_PD" -Type "DAILY" -EveryNth "1" -UserStartTimeInUsecs "1463522460000000"
#Configuration de la "retention policy"
Set-NTNXProtectionDomainRetentionPolicy -pdname "My_PD" -Id ($(Get-NTNXProtectionDomainCronSchedule -Name "My_PD").Id) -LocalmaxSnapshots 2 -RemoteMaxSnapshots "My_Remote_Site=1"

Je configure donc un snapshot local et un snapshot sur le site de réplication.
Pour la configuration du « RemoteMaxSnapshots » il faut impérativement indiquer le RemoteSite (vous pourriez en avoir plusieurs) coller avec « = » et le nombre de snapshots. 1f616

 

Pour faire le grand nettoyage dans vos configurations de réplication:

#Supprimer tous les snapshots
$snaps=Get-NTNXProtectionDomainSnapshot
foreach ($snap in $snaps){
Remove-NTNXProtectionDomainSnapshot -ProtectionDomainName $Snap.ProtectionDomainName -SnapshotId $Snap.SnapshotId }
#Supprimer toutes les taches planifiées
$PDs = Get-NTNXProtectionDomain
foreach ($PD in $PDs) {
Clear-NTNXCronSchedule -PDname:$PD.name
}
#Sortir toutes les VMs de tous les ProtectionDomains
$VMs = Get-NTNXVM
foreach ($VM in $VMs){
Remove-NTNXProtectionDomainVM -name $VM.protectionDomainName -input $VM.vmName
}

 

Une fois vide les ProtectionDomains devraient être supprimable également:

#Destructions des ProtectionDomains
$PDs = Get-NTNXProtectionDomain
foreach ($PD in $PDs) {
Mark-NTNXProtectionDomainForRemoval -name $PD.name
}

 

 

Concernant l’automatisation, nous avons choisi de reprendre le nom du disque de base Xendesktop dans le nom du « Protection Domain », ainsi que pour le « Consistency Group ».

Cette méthode nous permet de surveiller la limite des 50 machines et nous n’avons qu’un upgrade de l’image de base à réaliser pour faire le découpage.

Vivement l’augmentation de cette limite, car elle est encore administrable dans un petit environnement de quelques centaines de VDI, mais cela deviendrait difficilement compréhensible avec plusieurs milliers.

Si vous avez un autre mode de découpage, ou si vous gérez différemment vos réplications, n’hésitez pas à laisser un message dans les commentaires.