5 comments on “La gestion du stockage chez Nutanix

  1. Pingback: La gestion du stockage chez Nutanix – Nware

  2. Hello,

    Petite question :

    Etant donnée que le VMkernel discute avec la CVM sur un vswitch isolé (sans uplink), si la CVM tombe, comment ESXI (VMkernel) à accès au stockage des autres noeuds et ainsi continuer à faire tourner les VMS ?

    Plus de multipathing ? c’est bizzar ça !
    En gros je perd la CVM je perd le noeud complet ! ce n’est pas ce qu j’ai entendu de nutanix.

    Merci bcp pour les éclaircissements 😉

  3. Salut Komatek et Bienvenue sur v-desktop.fr!

    Concrètement, la CVM embarque un certain nombre de processus. Je ferai un post pour présenter cette architecture des que je peux. Comme tu l’as mentionné l’ESXi communique avec la CVM au travers d’un vswitch. Côté CVM, l’ESXi envoie les accès au stockage à un processus appelé Stargate.
    Dans le cas de la perte d’une CVM, c’est le mécanisme d’autopath qui rentre en jeu. Les CVM controllent entre elles qu’elles sont toutes disponibles et opérationnelles.
    Si le processus Stargate ne répond pas deux fois ou plus dans un intervalle de 30s, la CVM est considéré comme down.
    A ce moment c’est une autre CVM qui prend le relai et redirige les demandes d’accès au stockage sur un autre nœud. Ne pas oublier que l’on est dans un système de fichier distribué. Cette redirection des requêtes passe par les interfaces 10G.
    Une fois la CVM defectueuse remise en etat, donc le processus Stargate à nouveau up, la CVM qui a pris le relai avec l’Autopath, attend 30s pour voir si le service Stargate est stable, et ensuite rend la main à la CVM d’origine pour que tous les accès stockage se fassent à nouveau en local.

    • Merci pour l’acceuil 😉

      En revanche, dans le cas de l’autopath et qu’une autre CVM prend le relais, comment l’esxi (celui ayant la CVM down) communique depuis son VMkernel (pour l’accès NFS) vers la CVM d’un autre ESXi (puisque le VMkernel est sur un vswitch sans UPlink) ?

      Soit je comprends pas, soit il manque un truc 😉

      Merci.

  4. Oui il te manque un niveau d’explicarion :
    Pour bien comprendre l’autopath:
    – sur chaque noeud, l’hyperviseur et sa propre CVM communiquent sur un réseau privé (vSwitchNutanix) en 192.168.5.0. Le NDFS est monté sur chaque hôte ESXi via l’adresse serveur NFS: 192.168.5.2 (tu peux le constater sur les datastores NFS) 
    – l’adresse IP externe de la CVM (celle que l’on configure à la création du cluster) sert, elle, à répliquer les données d’un noeud à l’autre et pour la communication entre les CVMs (les heartbeats entre autres)

    >> dans un état normal du cluster, les IOs sont gérées localement par le switch privé entre l’hyperviseur et la CVM

    >> en cas de panne de la CVM (power down, mise à jour de l’OS, perte du SSD de boot, etc…), l’adresse locale 192.168.5.2, interne à la CVM, n’est plus accessible. NDFS va détecter la panne (les autres CVMs ratent des heartbeats avec la CVM down et l’excluent du cluster) et va rediriger les IO vers une autre CVM du cluster à travers le réseau 10GbE. C’est fait de façon transparente et ça consiste à rediriger l’adresse 192.168.5.2 vers une autre CVM et non plus en interne (on attaque directement l’ESX depuis une des CVMs restantes pour reconfigurer les vSwitch). C’est ça, l’autopath.
    C’est donc pour ça qu’il ne faut pas segmenter les réseaux entre les CVM et les ESX, sinon l’autopath ne peut plus fonctionner: on ne peut plus rediriger le traffic entre un ESX et une CVM à travers le réseau 10GbE.
    C’est aussi pour ça qu’il ne faut pas modifier les mots de passe des ESX et des CVMs n’importe comment: la CVM doit connaitre le mot de passe de l’ESX pour pouvoir faire des modifs de la config réseau dessus.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *