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 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 .

Pour ceux qui n’ont pas pu faire le déplacement ou suivre l’événement à distance, voici mon résumé de ce .NEXT qui célébrait les 10 ans de Nutanix.

Lire la suite de

Alors que les upgrades AHV sont habituellement beaucoup plus calmes que les upgrades ESXi sur la plateforme Nutanix, je me retrouve ce matin avec une mise à jour figée vers 5.5.2. Les détails de tâches indiquent que l’opération est en cours, mais elle traîne vraiment depuis un long moment.

Le détail de la tâche en cours correspond à la mise en maintenance de l’hôte afin de déplacer les VMs qu’il héberge pour le redémarrer sans impact :

En vérifiant l’état des hôtes sur le cluster, je m’aperçois qu’il y a bien un nœud en maintenance (schedulable à False), mais ce n’est pas celui dont la mise à jour est en cours. Je le sort de maintenance, puis je rajoute celui qui est censé y être.

acli
host.list
host.exit_maintenance_mode fqdn.server
host.list #verifier l'etat de l'hôte
host.enter_maintenance_mode fqdn.server

Après cette opération, les VMs ont été déplacés automatiquement à chaud et le nœud AHV est passé en maintenance, ce qui a débloqué le reste du processus de patching.

Voici le script que j’utilise en ce moment pour les mises en maintenance des hôtes AHV des clusters Nutanix avec un menu à choix multiples :

Disconnect-NTNXCluster *

#Choisir le cluster 
$ClusterNut = Read-Host "Entrer the Ip or DNS name of your Nutanix Cluster to manage"

Connect-NTNXCluster $ClusterNut -AcceptInvalidSSLCerts -ForcedConnection
$Clusterlist = $null


for () {

# récupère la liste des noms d'hôtes du cluster
$Clusterlist = Get-NTNXHost

    #défini integer à 0
    $i=0

    $ClusterName = (Get-NTNXCluster).name

    Write-Host "Vous avez selectionné le cluster $($(Get-NTNXCluster).name)
    "

    # Créer un menu : Pour chaque hôte du cluster ajouter 1 à i et afficher le nom d'hôte associé
    write-host "0 : Sortir du script"
    foreach ($ht in $Clusterlist) {
        $i++
        Write-Host "$i : $($ht.Name) : état  $($ht.hypervisorState) : Hyperviseur $($ht.hypervisorAddress) : IPMI $($ht.ipmiAddress) " 
        }

    do {
    $Menu = Read-Host "Choisir le numéro d'hôte"
    #juste affichage : tant que le chiffre indiqué n'est pas un nombre d'un hôte possible on boucle ici
    if (0..$Clusterlist.Count -notcontains $Menu) {Write-Host "Merci d'indiquer le numéro correspond au noeud à mettre en maintenance" -ForegroundColor Red}
    }

    #tant que le chiffre indiqué n'est pas un nombre d'un hôte possible on boucle ici
    while (0..$Clusterlist.Count -notcontains $Menu)

    #Conserve le nom de l'hôte dans la variable ChoiceMenu le -1 sert car le count debute à 0.
    if ($menu -eq 0) {
                        #Déco
                        Disconnect-NTNXCluster *
                        exit
                      } 
    $ChoiceMenu = ($Clusterlist).name[$menu-1]
    write-host "Vous avez choisi le $ChoiceMenu"

    Write-Host -ForegroundColor Green "Choisir l'option 1 pour Mettre en Maintenance et l'option 2 pour remettre en ligne" 
    $Menu1 = Read-Host 

    if ($Menu1 -eq 1) {
        $uuid = (Get-NTNXHost | where {$_.name -like $ChoiceMenu}).uuid
        
        write-host "La tache de mise en maintenance de l'hôte $ChoiceMenu est en cours"
        Start-NTNXMaintenanceMode -Hostid $uuid -EvacuationOption LIVE_MIGRATE
        sleep 3 
        
    }

    if ($Menu1 -eq 2) {
    write-host "La tache remise en prod de l'hôte $ChoiceMenu est en cours"
    Stop-NTNXMaintenanceMode -Hostid $uuid
    sleep 3
    }
    
}