Nutanix – Perte d'une CVM

Nutanix – Perte d'une CVM

10 septembre 2015 0 Par Michael PERES

Que se passe-t-il en cas de perte d’une CVM.

La CVM est une Appliance virtuelle embarquant un certain nombre de processus, et qui fonctionne sur chaque serveur hôte ESXi. Elles communiquent entre elles à travers un switch de façon à contrôler qu’elles sont toutes disponibles et opérationnelles.
Lorsqu’une CVM ne répond plus, c’est un second chemin qui se met en place, appelé « autopath ». Ce chemin est aussi utilisé par le cluster Nutanix, qui sélectionne automatiquement le chemin optimal entre un hyperviseur hôte et une VM.

Lorsque les données locales sont disponibles, le chemin optimal est toujours celui qui transite par la CVM local pour les périphériques de stockage locaux. Cependant, dans certaines situations, les données d’une VM ne sont pas disponibles sur un stockage local, comme quand un VM a été récemment migré vers un autre hôte. Dans ce genre de cas, la CVM redirige la demande de lecture à travers le réseau de stockage sur un autre hôte du cluster.

L’ESXi quand à lui, envoie les accès au stockage à un processus nommé Stargate.
Cependant, il est possible aussi que le processus Stargate ne soit pas « joignable ». Si cela se produit, et que le processus ne répond pas deux fois ou plus dans un intervalle de 30s, la CVM est considérée comme hors service ou éteinte.
Pour éviter une interruption de la commutation avec la CVM, le chemin de données ne sera pas rétabli jusqu'à ce que la CVM d'origine ait été stable pendant au moins 30 secondes.

Ce procédé est possible du fait que l’ensemble utilise un système de fichier distribué et utilise des interfaces en 10G pour la redirection des différentes requêtes.

CVM1

Ce schéma nous montre que chaque hyperviseur et sa propre CVM communiquent sur un réseau privé à travers un vSwitch sur le réseau 192.168.5.X.
Le système NDFS est monté sur chaque hôte ESXi via l’adresse serveur NFS: 192.168.5.2.
La CVM utilise une adresse IP interne afin de répliquer les données d’un nœud à l’autre et communiquer entre elles.
Les échanges (IOs disque) sont gérés localement à travers le vswitch privé et local reliant l’hyperviseur et la CVM.
Lorsque la CVM n’est plus accessible, l’adresse locale (192.168.5.2) interne à la CVM, ne l’est plus non plus. C’est à ce moment-là que le système NDFS détecte la panne. Les CVMs situées sur les autres hyperviseurs ne reçoivent plus les « heartbeats » de la CVM en panne et l’excluent automatiquement du cluster en redirigeant les IOs vers une autre CVM accessible du cluster à travers le réseau 10GbE.
La performance peut légèrement diminuer, parce que les IOs transitent à travers le réseau, plutôt que dans le vSwitch interne. Cependant, vu que tout le trafic passe à travers le réseau 10 GbE, la majeure partie des différentes charges de travail ne sera pas impactée.
Cette légère diminution de performances ne devrait donc pas être perceptible par les utilisateurs.

Ce procédé consiste à rediriger l’adresse 192.168.5.2 vers une autre CVM et non plus en interne. La communication s’effectue directement depuis l’une des CVM accessible vers l’ESXi.

CVM2

Perte d’une CVM supplémentaire :

La perte d’une CVM supplémentaire aura le même impact sur les machines virtuelles sur un autre hyperviseur.
Le fait que deux hyperviseurs envoyant des requêtes IO à travers le réseau, augmente le risque de perte de données, puisque l’ensemble fonctionnera avec deux ensembles de disques physiques inaccessibles.
Le cluster permet de répliquer deux fois chaque donnée. L’ensemble se trouve donc fragilisé en cas de nouvelle perte de CVM, et ce, jusqu'à ce que l'une des CVM hors service soit de nouveau opérationnelle.