La gestion du stockage chez Nutanix

Chaque nœud d’un bloc Nutanix dispose de 6 emplacements disques. Les configurations matérielles différes selon les modèles de bloc, entre autres :

• La répartition entre les disques SSD et les disques SATA (voir les spécificités techniques sur le site de l’éditeur)
• La capacité des disques :
  • Disques SSD : 400Go ou 800Go
  • Disques SATA : 1To ou 4To

Les Appliances Nutanix ne sont pas équipées de contrôleur RAID, ce qui implique zéro configuration côté disques physiques. La sécurité est assurée par les mécanismes de gestion du système de fichiers distribué qui utilise un système de réplication facteur (RF) x2 ( x3 dans la version 4.0 )

• RF2 : Quand un bloc de données d’une VM  est écrit dans le cache en écriture du nœud1 (qui l’héberge la VM), il est :
  • Répliqué dans le cache en écriture du nœud2 (du même cluster) puis sauvegardé sur le stockage local du nœud2.
  • Sauvegardé sur le stockage local du noeud1
• RF3 : Quand un bloc de données d’une VM  est écrit dans le cache du nœud1 (qui l’héberge la VM), il est :
  • Répliqué dans les caches en écriture des nœud2 et nœud3 (du même cluster) puis sauvegardé sur les stockages locaux des nœud2 et nœud3.
  • Sauvegardé sur le stockage local du noeud1

  
  .

Protection de la donnée, présentée par Steven POITRAS.

Structure de données

Le système de fichiers distribué Nutanix est composé des structures suivantes:

1. Le Storage Pool
2. Le Container
3. Le vDisk

.

.

1 - Le « Storage Pool »

Un Storage Pool est un groupe de disques physiques SSD et(ou) SATA, un peu comparable à un RAID Groupe d’une baie de stockage sur un réseau SAN. Le disque d’un Storage Pool est dédié à son Storage Pool (évident, mais mieux vaut le préciser) ce qui implique un cloisonnement physique entre les VMs de chaque Storage Pool.

Dans ses Best Practices, pour garantir des performances optimums côté IOPS et latence, Nutanix recommande de n’implémenter qu’un Storage Pool par cluster. Par son architecture de stockage scale-Out, Nutanix garantie une efficacité linéaire car elle permet de rajouter des nœuds dans le cluster sans dégrader les performances. En effet, les ressources supplémentaires d’un nouveau nœud (calcul, mémoire et stockage) rajoutées dans le cluster seront gérées par le contrôleur VM (que l’on nomme CVM) de ce nouveau nœud. L’augmentation de la volumétrie de stockage, qui se fait sans interruption de service, n’a donc quasi aucun impact sur la production ni sur les performances du cluster.

2 - Le « Container »

Le container est constitué d’un ensemble de disques physiques du Storage Pool qui hébergent les disques (vDisk) des VMs qui lui seront rattachées. On pourrait faire une certaine association de cette gestion au découpage de volumes dans une LUN. Lors de la création du container, le stockage, qui est présenté par défaut en mode « Thin-Provisioning, peut être monté sous la forme d’un point de montage NFS aux hyperviseurs du cluster. C’est à partir du container que l’on gère les fonctionnalités de compression et de déduplication.

3 - Le « vDisk »

Le vDisk correspond au disque dur d’une machine virtuelle. Avec une connexion du stockage aux hyperviseurs en iSCSI, il est possible de créer deux types de vDisk :

• RDM : Le vDisk est directement présenté à la VM
• VMFS : Dans un deuxième temps, on formate le vDisk avec le système de fichier VMFS de VMware pour fournir un accès en mode bloc aux VMs.

Le Contrôleur VM (CVM)

.

.

Un CVM est une machine virtuelle sous NOS (Nutanix OS), préconfigurée par Nutanix, et implémentée sur chaque nœud du cluster. C’est le cœur du produit, sur lequel repose toute l’intelligence pour la gestion du stockage local, qu’il accède en Passthrough. Il respecte une convention de nommage qui reprend le numéro du bloc ainsi que l’emplacement de chaque nœud dans le bloc (position A, B, C, D).

Par défaut, toutes les CVM du cluster ont la même configuration :

• 8 vCPU
• 16Go RAM
• Deux cartes réseaux

Selon la configuration des containers (activation de la déduplication ou de la compression), le CVM peut utiliser jusqu’à 24Go RAM. Il faut donc être très vigilant lorsque l’on étudie le Design d'une infrastructure Nutanix. Il ne faut donc pas hésiter à mettre les nœuds du cluster à 256Gà, voir 512Go (si le modèle le permet).

Concernant la partie réseau, une des cartes est connectée sur le port group VM Network du vSwitch0 afin de permettre à tous les CVM de communiquer entre eux.

.

.

C’est au travers de ce VLAN que la fonction appelée autopathing intervient quand un CVM du cluster est hors service, car un nœud sans CVM ne peut plus accéder à son stockage local. Comme le système de fichiers distribué NDFS 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 en V4), 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
Pour plus de détails sur les mécamismes techniques de Nutanix, lisez la Bible Nutanix de Steven Poitras.