NDFS, le système de fichiers distribué de Nutanix

Il existe 4 gammes de produits chez Nutanix, la gamme NX-1000, NX-3000, NX-6000, et NX-7000 (voir les spécifications sur le site de l'éditeur). Les solutions se présentent sous la forme suivante :

• Un boitier au format 2U qu’on appelle « bloc »
• Un bloc contient de un à quatre serveurs qu’on appelle « nœud ».
• Chaque nœud dispose de :
  • Deux processeurs Intel
  • De 32Go à 512Go de RAM
  • D’un stockage local qui implémente :
    • 1 à 2 disques SSD
    • 4 à 6 disques SATA

    
    .

.

Dans un bloc, tous les hyperviseurs, installés en usine par Nutanix, disposent d’une machine virtuelle appelée « Nutanix Controller VM  (CVM)». Le rôle du CVM est de gérer les accès au stockage pour chaque hyperviseur, avec un accès direct en mode « Passthrough ».

Côté VMware, le stockage, présenté au travers du protocole NFS par chaque serveur du bloc, apparait comme une seule et unique banque de données qui regroupe l’ensemble des disques du bloc (le Storage Pool)

Le principe de gestion du stockage Nutanix repose sur un système de fichiers distribué qu’on appelle NDFS (« Nutanix Distributed File System »). Ce système de fichiers est dérivé de celui utilisé chez Google, Facebook et Amazon.

NDFS, le système de fichiers distribué de Nutanix

Les avantages du système de fichiers distribué et l’intelligence embarquée dans le CVM vont faire toute la différence face aux infrastructures classiques.

Comme mentionné plus haut, tous les nœuds du bloc Nutanix comprennent des disques SSD et SATA et disposent d’une machine virtuelle CVM qui gère les demandes de lecture/écriture au niveau stockage.

.

.

Gestion des accès en lecture/écriture

Le contrôleur VM (CVM) d’un hyperviseur gère l’accès au stockage de toutes les machines virtuelles qui sont exécutées sur ce même hyperviseur. Sur le schéma ci-dessous, pour comprendre l’explication, la VM Guest sur l’hyperviseur est symbolisée par les trois losanges, rouge, orange, violet côté stockage. Comme je l’ai expliqué dans le billet « La gestion du stockage chez Nutanix », pour garantir une tolérance de panne, Nutanix utilise un système de fichiers distribué (NDFS) entre tous les nœuds d’un cluster en utilisant un facteur de réplication x2 (RF). Cela signifie que chaque bloc de données d’une machine virtuelle est copié sur le stockage local de l’hyperviseur qui l’héberge et sur le stockage local d’un autre nœud du cluster.

.

.

L’hyperviseur lit et écrit les blocs de données d’une machine virtuelle à partir de sa Datastore, comme s’il était connecté à un SAN « traditionnel ». Dans ce contexte architectural, on obtient une amélioration des performances pour l’accès au stockage car les données transitent sur un bus interne au lieu de passer par un réseau de stockage externe.

Schéma de traitement des accès au stockage

.

.

Explication (pour des explications plus précises, lire ce billet)

Quand une machine virtuelle fait la demande pour une requête en écriture, elle l'envoie au Contrôleur VM (CVM). Pour optimiser les temps d’accès au stockage, le bloc de données de la requête est déjà stocké dans un cache SSD du nœud local (OpLog) afin d'acquitter au plus vite la demande. Pour garantir une cohérance des données en cas de crash du noeud ou du CVM, le cache est rapidement répliqué sur des autres serveurs du cluster au travers des interfaces 1G/10G.

Pour un accès en lecture, le bloc de données est stocké en cache dans la RAM et dans le stockage SSD du nœud. Cette technologie apporte des accès très rapides avec une latence peu élevée. A partir du moment où la donnée est moins sollicitée, elle est transférée dans l’Extent Store, zone correspondante à une partie du stockage SSD et SATA.

L’intérêt de ce mécanisme permet :

• De s’affranchir des contraintes de performance liées aux disques SATA car les accès en lecture/écriture ne se font qu’aux travers de la RAM et du stockage SSD.  
• De bénéficier des grosses volumétries des disques SATA

Quand une machine virtuelle fait une demande pour une requête en lecture, le CVM analyse déjà son cache local SSD pour voir si le bloc de données demandé s’y trouve. S’il n’est pas présent, il analyse ses disques locaux SATA et copie le bloc de données vers son cache local SSD. S’il n’est pas présent dans son stockage local SATA, le CVM va lire directement le bloc de données dans le stockage local d’un autre nœud du cluster qui dispose de ce bloc. La lecture du bloc se fait alors au travers du réseau 1G/10G et elle est transférés sur le nœud qui émet la demande de manière à pouvoir accéder au bloc en local lors des prochaines demandes.

Gestion du déplacement à chaud des VMs

Les mécanismes de déplacement à chaud de machine virtuelles (vMotion de vSphere ou Live Migration d’Hyper-V) sont supportés par Nutanix. Grace au CVM de chaque nœud du cluster, tous les hyperviseurs sont capables de voir toutes les banques de données.

Lorsqu’une machine virtuelle est migrée sur un autre hyperviseur, toutes les nouvelles requêtes en lecture sont faites en local sur l’hyperviseur qui héberge la VM pour voir si le bloc de données y est présent (exemple, le losange violet dans le schéma ci-dessous). Si ce n’est pas le cas, le CVM va lire directement le bloc de données dans le stockage local d’un autre nœud du cluster qui dispose de ce bloc (exemple, les losanges rouge et orange dans le schéma ci-dessous). La lecture du bloc se fait alors au travers du réseau 1G/10G et elle est transférés sur le nœud qui émet la demande de manière à pouvoir accéder au bloc en local lors des prochaines demandes.

.

.

Gestion de la haute disponibilité (HA)

En cas de perte d’un hyperviseur (nœud), les deux problématiques suivantes sont à gérer :

1. Le redémarrage de la machine virtuelle sur un autre nœud
2. L’accès aux blocs de données de la machine virtuelle redémarrée

Le redémarrage automatique de la machine virtuelle est géré par la fonctionnalité HA de l’éditeur. Lorsqu’un hyperviseur est indisponible, le mécanisme HA redémarre automatiquement les machines virtuelles présentes sur d’autres hyperviseurs du cluster.

Si le nœud sur lequel la machine virtuelle est redémarrée ne contient pas les blocs de données correspondant à cette machine virtuelle, le CVM va lire directement le bloc de données dans le stockage local d’un autre nœud du cluster qui dispose de ce bloc. La lecture du bloc se fait alors au travers du réseau 1G/10G et elle est transférés sur le nœud qui émet la demande de manière à pouvoir accéder au bloc en local lors des prochaines demandes.

Pour garantir une tolérance de panne, le CVM va ensuite écrire les blocs de la machine virtuelle sur le stockage local d’un autre serveur du cluster afin de conserver un facteur de réplication x2 (RF) et maintenir le niveau de protection des données.

.

.

Gestion de la défaillance de la CVM

Si l’on perd un CVM du cluster, l’accès au stockage local du nœud qui héberge le CVM n’est plus disponible.

Comme le disfonctionnement est directement lié à la couche Nutanix et qu’il faut garantir l’ordre de marche des machines virtuelles hébergées sur ce nœud, Nutanix fait intervenir la fonction appelée autopathing.

Grâce au système de fichiers distribué NDFS qui gère la tolérance de panne du stockage en copiant un même bloc de données sur les stockages locaux de deux ou trois nœuds d’un même cluster (RF2 ou RF3 dans la version 4.0 du NOS), la fonction d’autopathing va déterminer le meilleur chemin pour qu'un des CVM encore en ligne accède aux blocs de données des machines virtuelles en cours d’exécution sur l’hyperviseur qui n’a plus de CVM, de manière à ce qu'elles ne soient pas impactées et continues à fonctionner.

.

.

Merci à Alexandre Arrive-Cornec pour son article consultable sur ce lien