PROPOSITION TECHNIQUE

10
Cette section appelée « proposition technique » comprend :

 Un Document de présentation approfondie de la solution NUTANIX

 Le dimensionnement de la plateforme NUTANIX proposée
 L’Architecture matérielle proposée
 Les Fiches Techniques
 DOCUMENT DE PRESENTATION
APPROFONDIE DE LA SOLUTION NUTANIX

12
Nutanix Xtreme
Computing Platform
Table des matières
1. Qui est Nutanix ? ...................................................................................................... 4
1.1 En Bref......................................................................................................................... 4
1.2 Une position de leader reconnue .................................................................................. 4
1.3 Une équipe dirigeante expérimentée ........................................................................... 5
1.4 Proposition de valeur ................................................................................................... 6
1.5 Evolution des architectures .......................................................................................... 7
2. Le défi de l’hyperconvergence ................................................................................... 9
2.1 Le constat .................................................................................................................... 9
1.2 L’approche Web-Scale ...................................................................................................... 10
3. L’architecture du cluster Nutanix ............................................................................. 11
3.1 Principes fondamentaux ............................................................................................ 11
3.2 Une infrastructure distribuée ..................................................................................... 11
3.3 La virtualisation ......................................................................................................... 12
3.4 L’utilisation des disques SSD....................................................................................... 16
3.5 Des fonctions de management distribuées ................................................................. 17
3.5.1 PRISM : Architecture ....................................................................................................... 17
3.5.2 API et interfaces .............................................................................................................. 19
3.6 Intégration avec OpenStack........................................................................................ 20
3.7 Une gestion du stockage distribuée ............................................................................ 23
3.7.1 La convergence................................................................................................................ 24
3.7.2 Software Defined ............................................................................................................ 25
3.7.3 Composants du cluster Nutanix ...................................................................................... 25
3.7.4 Services Acropolis............................................................................................................ 27
3.7.5 Système de fichier distribué ............................................................................................ 27
3.7.6 Structure des données .................................................................................................... 28
3.7.7 Chemin de l’I/O et système de cache.............................................................................. 28
3.7.8 Data Protection ............................................................................................................... 30
3.7.9 Availibility Domain .......................................................................................................... 31
3.7.10 Résilience de l’accès à la donnée : Autopath.............................................................. 31
3.7.11 Erasure Coding ............................................................................................................ 33
3.7.12 Compression ............................................................................................................... 35
3.7.13 Déduplication .............................................................................................................. 38
3.7.14 Equilibrage de l’utilisation des espaces disques ......................................................... 40
3.7.15 Volume Group ............................................................................................................. 41
3.7.16 Nutanix Guest Tools .................................................................................................... 42
3.7.17 Snapshots et Clones .................................................................................................... 44
3.7.18 Réplication et Distater Recovery ................................................................................ 45
3.7.19 Metro Availibility ........................................................................................................ 49
3.7.20 Localité de la donnée .................................................................................................. 51
3.8 Acropolis Hypervisor : une offre de virtualisation par Nutanix ..................................... 51
3.8.1 KVM Architecture ............................................................................................................ 53
3.8.2 Configuration Maximums ................................................................................................ 54
3.8.3 Réseaux virtuels dans AHV .............................................................................................. 54
3.8.4 iSCSI multi-pathing .......................................................................................................... 55
3.8.5 Gestion des adresses IP ................................................................................................... 56
3.8.6 VM High Availibility (HA) ................................................................................................. 57
 1. Qui est Nutanix ?

1.1 En Bref

Nutanix est une société fondée en 2009 à San Jose en Californie. Les premiers produits ont
été commercialises en 2011. En un peu plus de trois ans, plus de 10 000 nœuds ont été
commercialisés à travers le monde. Nutanix dispose aujourd’hui de plus de 1750 clients de
toutes tailles à travers plus de 70 pays.
En France Nutanix a dépassé la barre des 100 clients depuis le début de son activité en 2013
et parmi eux on retrouve :
 Société Générale
 Total
 Mairie de Paris
 Axa
 118 218
 Accor
 Kering
 Mondial Assistance
 Claranet
 Almerys
 Axa
 Technip
 Ministere de la defense
 Bollore
 Thales
 Cdiscount
 L’Oreal
 CFAO
 Diademys
 EBP
 Egis
 Malakoff Mederic
 BNP Paribas
 …

1.2 Une position de leader reconnue

En aout 2015, le Gartner a publié son rapport sur le marche des systèmes intégrés plaçant
Nutanix en tant que leader des solutions convergés et hyperconvergés. Le rapport est
disponible ici.

Le Gartner salue la capacité de Nutanix à innover et simplifier la gestion des infrastructures

de virtualisation, sa capacité a délivrer des projets de grandes envergures (55 000 postes VDI
sur 600 nœuds avec Dell pour le FBI) ou encore son approche de la virtualisation avec sa
solution Acropolis Hypervisor.
1.3 Une équipe dirigeante expérimentée
 1.4 Proposition de valeur

L’objectif de Nutanix est de proposer un nouveau modèle d’architecture élastique conçu

nativement pour évoluer sans limite et s’adapter au monde de l’entreprise et aux évolutions
de croissance. Pour ce faire, Nutanix reprend les principes d’architectures développe
notamment chez Google et Facebook pour les rendre accessibles au plus grand nombre. La
brique de départ est un système de fichier distribué développé au départ chez Google avec le
Google File System (GFS).

Ce type d’architecture repose sur des serveurs x86 classiques. Ces machines sont agrégées et
pilotées par un logiciel distribué capable de fournir une suite de services en terme de gestion
de la donnée, gestion des pannes, réplication, supervision etc…
Nutanix propose donc une plateforme de virtualisation agnostique en terme d’hyperviseur
(support natif de VMware vSphere, Microsoft Hyper-V et Acropolis Hypervisor (KVM)), dont
le stockage sous jacent s’appuie sur du stockage local (SSD et HDD) le tout agrégé par un
logiciel utilisant des techniques issues du monde du Big Data.

Toutes les fonctionnalités proposées par Nutanix sont exploitables au niveau de la machine
virtuelle simplifiant considérablement la gestion des plateformes de virtualisation.

La solution Nutanix est commercialisée sous forme de nœud (Appliance) regroupant :

 Serveur x86 (mono ou bi processeur, 64 à 768GB RAM, interfaces réseaux 1G et 10G)
 Du stockage local (1 à 4 SSD et 2 à 20 disques SATA)
 Contrôleur de stockage sous forme de machine virtuelle présente sur chaque nœud
(CVM=Controler VM)

L’objectif de ce type d’architecture est de faire croitre de manière linéaire les capacités et
performances de la plateforme de virtualisation au fur et à que l’on rajoute des nœuds dans
le cluster.
 1.5 Evolution des architectures

Bien avant l’ère virtualisation, la plupart des applications étaient installées directement sur
des serveurs physiques exploitant dans un premier du stockage puis du stockage centralise
de type SAN.

Avec l’arrivée de la virtualisation le modèle d’architecture n’a pas changé, et on a consolidé

davantage de serveur virtuel sur des serveurs physiques. Cette consolidation massive n’a pas
remis en question l’architecture SAN.
Les puissances de calcul ont considérablement augmenté, le nombre d’hôte de virtualisation
également mais les contrôleurs de stockage des baies SAN ne se sont pas pour autant
multiplié.
Il est relativement simple d’étendre le stockage du système SAN pour adresser partiellement
les besoins en performance et en volumétrie. L’ajout des nouveaux hôtes de virtualisation est
une opération courante également. En revanche, il est beaucoup plus compliqué, rare et
couteux d’augmenter la capacité de traitement des contrôleurs SAN.
A chaque ajout d’un hôte de virtualisation, on augmente la puissance de traitement au niveau
compute (CPU et RAM), mais on divise un peu plus à chaque fois la puissance de traitement
des contrôleurs SAN.

Pour tenter de pallier à cette limite des contrôleurs SAN et avec la démocratisation du
stockage de type flash, les baies SAN se sont vu embarquer de plus en plus de SSD pour
essayer d’améliorer les performances globales du stockage. Cependant cette mesure ne
permet toujours pas d’augmenter la capacité de traitement des contrôleurs de stockage.

L’approche de Nutanix est à l’opposé de celui apporter par le stockage de type SAN. Chaque
ajout de nœud apporte une puissance de calcul supplémentaire. Maintenant comme chaque
nœud porte également un contrôleur de stockage sous forme de machine virtuelle, non
seulement la volumétrie disponible à chaque ajout de nœud mais surtout on rajoute de la
puissance de traitement pour pouvoir gérer les nouvelles demandes d’accès en lecture et en
écriture. Cette approche dite Web-Scale ou Scale Out, couplée à la banalisation du stockage
flash permet de concevoir des infrastructures modulaires avec des puissances de traitement
élevée.
 2. Le défi de l’hyperconvergence

2.1 Le constat

Les entreprises, pour la plus grande majorité, bâtissent leurs plateformes de virtualisation sur
la base d’un modèle traditionnel de serveurs connectés à une baie de stockage à travers un
réseau, modèle qui se prête mal aux évolutions des environnements virtuels. Il est très
fréquent de constater des problèmes de dégradation des performances avec l’accroissement
du nombre de VM hébergées par ce type d’architecture. C’est la première raison pour laquelle
les grands acteurs du Cloud n’utilisent pas ce modèle serveurs-réseau-stockage pour servir
les machines virtuelles qu’ils hébergent. La seconde raison est que dans un modèle
traditionnel, le stockage en réseau est devenu la source principale de coût et de complexité
au sein des infrastructures virtuelles.

Le modèle de stockage en réseau fonctionne bien pour des serveurs physiques qui servent
des applications relativement statiques. La virtualisation et, plus récemment, le Cloud
Computing ont rendu les Datacenters extrêmement dynamiques : les machines virtuelles sont
créées à la demande, se déplacent sur différents serveurs et dépendent complètement des
ressources partagées. Ces caractéristiques rendent complexe la gestion des machines
virtuelles et de l’infrastructure physique sous-jacente.

Conséquence directe de la facilité de création des VM : les volumes de données augmentent

très rapidement au sein des Datacenter. Dans les entreprises, de nouvelles initiatives comme
la virtualisation des postes de travail accentuent encore cette tendance. Le surcroît d’activité
lié à la gestion des infrastructures de virtualisation n’est plus absorbable par beaucoup
d’entreprises. Celles-ci externalisent de plus en plus leurs machines virtuelles chez des
sociétés de services, qui se retrouvent à gérer un nombre encore plus important de machines
virtuelles, et à implanter des Datacenter de plus en plus capacitifs pour répondre à la
demande.
Le nombre croissant de machines virtuelles exerce une pression de plus en plus forte sur les
architectures traditionnelles qui connectent les moyens de calcul aux espaces de stockage via
un réseau multicouche. Les performances, temps d’administration et budget
d’investissement se dégradent continuellement.

La solution idéale serait donc une architecture basée sur des briques très simples à installer
et à remplacer, dont la performance augmente à l’infini en fonction des besoins, et qui réduise
drastiquement les dépenses en matériels, logiciels, espace occupé et consommation
électrique.

L’émergence des disques SSD (solid-state) est une autre tendance qui agrandit le fossé entre
les serveurs et les systèmes de stockage. L’usage de disques SSD qui sont entre 100 fois et
1000 fois plus rapides que les disques traditionnels vont accroitre les goulots d’étranglement
et la complexité du réseau stockage si les machines virtuelles doivent y accéder à travers un
réseau. De nombreux acteurs du stockage SAN/NAS ajoutent désormais les disques SSD à
leurs solutions, pour un budget conséquent.

Ce type de solution nécessite également des investissements supplémentaires sur le réseau,

afin de délivrer la bande passante nécessaire à l’exploitation de ce tiers de stockage pourtant
déjà onéreux. Sur cet aspect, la solution idéale permettra aux machines virtuelles d’accéder
directement à ces SSD en local pour une performance maximale, tout en supportant les
fonctionnalités primordiales de déplacement de VM et de haute disponibilité.

1.2 L’approche Web-Scale

Google et d’autres entreprises majeures de l’ère du Cloud comme Amazon, Yahoo et

Microsoft (Azure) ont pris conscience qu’une approche basée sur du stockage en réseau ne
pourrait pas fonctionner pour leurs Datacenter. Ils ont donc développé des solutions
logicielles (notamment le Google File System) pouvant fédérer un très grand nombre de
serveurs de commodité incluant du stockage local dans un cluster unique.

Cette approche a permis à Google de construire une infrastructure convergée de calcul et de

stockage utilisant des serveurs contenant du stockage local comme brique de base. Le File
System de Google exploite un cluster de serveurs et crée un espace de stockage unique qui
peut être accédé par toutes les applications qui s’exécutent sur un des serveurs du cluster. La
particularité de ce type d’architecture est que le système cherche constamment à rapprocher
géographiquement l’exécution de l’application et les données utilisées, ainsi une majorité des
échanges s’effectuent localement dans le serveur afin d’éviter l’utilisation du réseau. Le
niveau de performance est donc optimal grâce à l’élimination des problèmes de latence et de
congestion.

Cette architecture permet également d’obtenir un très haut niveau de disponibilité pour les
applications en masquant complètement les pannes matérielles au niveau des disques et des
serveurs. Le File System Google a permis à Google de construire des Datacenter évolutifs à
l’extrême tout réduisant les coûts de moitié et en levant les limites de performance
constatées sur des architectures serveurs-réseau-SAN/NAS.
Pour les besoins des entreprises, Nutanix a adopté une approche « scale out » similaire pour
développer une infrastructure de calcul et de stockage prévue dès sa genèse pour
l’hébergement de machines virtuelles en entreprise.

A l’origine de Nutanix, on retrouve l’équipe d’architectes et développeurs à l’origine du

Google File System, les architectes de l’infrastructure Big Data de Facebook ainsi que d’autres
talents issus des domaines du Cloud, de la virtualisation, de l’optimisation des performances
sur les systèmes de stockage. Par exemple certains concepteurs de la base de données NoSQL
Cassandra ont rejoint les équipes Nutanix.

3. L’architecture du cluster Nutanix

3.1 Principes fondamentaux

La solution Nutanix Complete Cluster a été développée à partir d’une feuille blanche pour
résoudre les problématiques liées au stockage pour les machines virtuelles en construisant
un système qui tire parti des dernières avancées en terme d’architecture système, et de
technologies matérielles et logicielles.

3.2 Une infrastructure distribuée

L’architecture Nutanix est similaire à celle de Google car c’est une infrastructure distribuée,
ou « scale out » au niveau des moyens de calcul et de stockage qui élimine le besoin en
système de stockage en réseau. Nutanix puise dans les meilleurs pratiques et fonctionnalités
de l’environnement Google pour délivrer une solution optimisée pour la virtualisation en
entreprise.

A l’inverse du Google File System qui est une solution customisée pour les applications
internes de Google (recherche, Gmail, etc..), Nutanix fournit une solution qui sert toutes les
applications à partir du moment où elles sont virtualisées. En plus de ses facultés à distribuer
l’infrastructure, la solution dispose de fonctionnalités embarquées identiques ou meilleures
que celles fournies dans les solutions de stockage classiques du marché, comme par exemple
(liste non exhaustive) :
 Relocalisation de la donnée
 Tiering et Caching
  Redondance de la donnée via Replication Facteur 2 ou 3
 Snapshot et clones
 Replication asynchrone et synchrone
 Deduplication inline et post process
 Compression inline et post process
 Erasure Coding
 Thin provisionning
 Authentification double facteur
 …

3.3 La virtualisation

La solution Nutanix a été pensée pour les machines virtuelles et supporte nativement toutes
les fonctions des hyperviseurs, au même titre que les solutions de stockage centralisées. Ceci
inclut entre autre la migration en ligne de machines virtuelles et la fonction de haute
disponibilité (HA). De plus, comme l’architecture Nutanix est consciente de l’environnement
virtuel, elle résorbe les limitations des solutions traditionnelles qui sont optimisées pour
fonctionner avec des serveurs physiques. La plateforme Nutanix a la particularite d’etre
agnostic en terme d’hyperviseur et supporte :
 VMware vSphere ESXi
 Microsoft Hyper-V 2012 R2
 Acropolis Hypervisor (KVM)

Par exemple, alors que l’unité de gestion est la machine virtuelle du côté système, du côté
stockage l’unité est traditionnellement la LUN. Quand une LUN est partagée par de
nombreuses VM, il devient de plus en plus difficile d’effectuer des opérations sur le stockage,
telles que la sauvegarde, la reprise après incident, les snapshot par machine virtuelle. Cela
devient également très compliqué d’identifier les causes des dégradations de performance
au sein d’un environnement fortement mutualisé à cause de la séparation entre serveurs et
stockage. L’architecture Nutanix annule complètement ces contraintes et permet à gérer le
stockage avec la VM pour unité de gestion.

Le protocole NFS a pendant très longtemps été assimilé à une solution de stockage médiocre
et pas vraiment adapté pour les applications de type « Mission Critical ». Sans réfléchir aux
conséquences, un grand nombre de projet ont été réalisés avec des systèmes de stockage en
mode bloc en FC ou iSCSI soit disant pour des questions de performances.

Aujourd’hui la plupart des solutions dites convergées ou hyper-convergées adoptent

massivement le protocole NFS comme moyen d’accès au système de stockage. C’est le cas de
Nutanix qui par défaut présente son stockage à VMware vSphere ESXi en NFS en s‘appuyant
sur des interfaces 1Gb ou 10Gb. Par conséquent on peut se demander pour une solution qui
prône le «Scale Out » quelles ont été les motivations pour ce choix d’architecture ?

Tout d’abord on oppose généralement le protocole NFS aux protocoles FC/iSCSI. Le premier
permet un accès en mode fichier au stockage alors que les deux autres en mode bloc. Très
souvent, le mode de transport de la donnée entre l’hyperviseur et le stockage est synonyme
de performance.

La mise en œuvre d’un réseau FC nécessite des compétences spécifiques pour la mise en place
du zoning. Ce type de déploiement s’accompagne très souvent d’un surcoût de licence afin
de pouvoir bénéficier de tous les ports d’un switch FC, sans compter qu’il faut une
connectique spécifique (fibre, module FC pour les switch et carte HBA coté hyperviseur). Il
faut faire l’acquisition de toute la chaine de transport FC.

Cependant, lorsque l’on doit partir de zéro ou tout remettre en question, il parait quasiment
obligatoire de passer par du 10Gb Ethernet. Pourquoi ? Parce que dans ce cas on continue de
gérer des plans d’adressage et des adresses ip, plus besoin d’acquérir des compétences
spécifiques pour gérer son stockage, plus de besoin d’acheter des licences supplémentaires
pour pouvoir utiliser tous les ports de son switch 10Gb et enfin plus besoin de carte
spécifique.

Aujourd’hui, en fonction des modèles et des constructeurs, les serveurs sont livrées avec des
ports 10Gb directement intégrés sur les cartes mères. Dans la plupart des environnements on
peut parfaitement construire les réseaux virtuels coté vSphere (management, vMotion, LAN
VM, NFS) en s’appuyant sur ces deux interfaces 10Gb. Enfin un avantage non négligeable
concernant les couts d’OPEX, moins d’interfaces signifie moins de câble à l’intérieur des racks,
donc moins d’équipements à installer et à gérer.

Grâce au 10Gb on simplifie fortement l’infrastructure tout en conservant le niveau de

performance nécessaire pour accéder au stockage. Ensuite, il reste à sélectionner les bonnes
technologies de disques et les bons algorithmes pour gérer les accès au stockage.

Le système de fichier NFS ne souffre pas des contraintes imposées les systèmes en mode bloc.
Il offre une souplesse de gestion et une scalabilité que ne permet pas d’avoir le mode bloc. A
chaque fois que l’hyperviseur envoie des instructions aux datastores pour agir sur les
machines virtuelles cela se traduit par des jeux de commandes SCSI envoyées aux contrôleurs
de la baie de stockage.

Pour rappel, VMware préconise d’affecter une LUN par datastore. Plus le nombre de machine
virtuelle par datastore est important, plus le nombre de commande SCSI à traiter par la LUN
est important. On parle alors de réservations SCSI. Ces réservations augmentent à chaque fois
que des fichiers (principalement lorsque l’on agit sur les disques virtuels des VMs) sont créés,
supprimés, modifiés. On rencontre ce type d’action typiquement lors du démarrage des
machines virtuelles (en particulier quand il s’agit de lots de VM sur une plateforme VDI, Cloud,
ou sur de grande plateforme de virtualisation), quand un logiciel de backup fait des snapshot
ou encore lorsque l’on déploie des VMs à partir d’un template.

Toutes ces actions impliquent la mise à jour des metadata de la LUN. A ce stade, l’hyperviseur
verrouille la LUN pour réaliser toutes ces modifications. Même si ce « lock » est très court,
sur des environnements hébergeant un grand nombre de machines virtuelles, on va voir
apparaitre un phénomène de latence au niveau du système de stockage.

A partir de vSphere 4 .1 et de sa version Enterprise +, VMware propose un ensemble d’APIs

appelées VAAI (vStorage APIs for Array Integration) permettant de décharger l’hyperviseur
d’un certain nombre d’actions liées au stockage. Ces actions sont alors entièrement exécutées
par le SAN. Parmi les primitives VAAI, on peut en citer une en particulier appelée ATS (Atomic
Test and Set). Cette primitive permet de verrouiller uniquement les fichiers de la VM devant
être mise à jour au lieu de verrouiller la totalité de la LUN comme indiqué précédemment.
Cette gestion du « lock » est déchargée au niveau du SAN au lieu d’être gérée par
l’hyperviseur. Grace à cette primitive et à la possibilité de créer des datastore de 64Tb à partir
de vSphere 5.x, on pourrait penser que les problèmes de performance lié à la mise à jour des
métadonnées d’une LUN sont réglés et pourquoi pas déployer plusieurs centaines de VMs par
datastore et donc par LUN ?

Une question revient fréquemment, combien de VMs peut-on placer par datastore ? Comme
toujours en IT, la réponse est « ça dépend ». Sur un stockage en mode bloc, la consolidation
des VMs par datastore implique rapidement des problèmes de performances. Par ailleurs, la
criticité des VMs est un élément important à prendre en compte car il en découle les
indicateurs de RPO/RTO. Les caractéristiques des contrôleurs (cache, algorithme d’écriture et
de gestion des données) sont également des paramètres déterminant.

Dans un stockage en mode bloc, on a généralement un rapport de 1 :1 entre les LUNs

présentes sur le SAN et les datastores coté vSphere. Chaque LUN dispose d’un identifiant
unique coté vSphere. En cas défaillance du SAN il est possible qu’une LUN perde son
identifiant unique. Afin de ne pas perdre les données, il faut procéder à une séance de
troubleshooting et régénérer la signature de la LUN à partir d’un ESXi. Cette opération peut
s’avérer délicate pour des administrateurs n’étant pas habituer à ce type d’opération. Le NFS
simplifie cette gestion des datastores puisqu’il n’existe pas ce pas principe de signature pour
les points de montage. Il s’agit là d’un avantage non négligeable notamment lors des
opérations de DR.

Maintenant ramenons toutes ces problématiques à l’architecture Nutanix. Tout d’abord

Nutanix présente son stockage aux hyperviseurs en NFS. Par défaut NFS gère le « lock » au
niveau du fichier et non au niveau de la LUN ou du point de montage pour être plus précis.
De plus, les datastores en mode bloc sont généralement limités à une file d’attente (« Queue
Depth ») de 64. Cela signifie que toutes les machines virtuelles stockées sur un même
datastore se partage la même file d’attente pouvant provoquer ainsi un goulet
d’étranglement en direction du stockage.

La file d’attente est utilisée pour les interactions avec le système de stockage. Elle gère le
nombre de commandes pouvant être envoyées simultanément aux contrôleurs de la baie de
stockage. Si l’on configure la file d’attente à 1, chaque commande doit être acquittée par le
contrôleur de stockage avec que la commande suivante puisse être exécutée. Par défaut, la
file d’attente est configurée à 64. Cela signifie que 64 commandes sont envoyées
simultanément aux contrôleurs du système de stockage. Une fois que ces commandes sont
acquittées par les contrôleurs les commandes suivantes peuvent être envoyées.

NFS dispose d’une file d’attente presque illimitée et ne souffre pas du phénomène des
réservations SCSI. Du coup, il possible d’obtenir des taux de consolidation de VMs par
datastore beaucoup plus élevés que sur un stockage en mode bloc. Par exemple, dans le cas
d’un environnement VDI avec Horizon View, VMware recommande de ne pas dépasser 140
VMs sur un datastore en mode bloc (VMFS) avec VAAI alors que cette limite est donnée par
VMware à 250VMs par datastore sur un stockage NFS. En production, on préfèrera réduire le
nombre de VMs par datastore en mode bloc (VMFS), notamment à cause des phénomènes
de « boot storm ».

Autre point sur lequel le stockage NFS joue à égalité avec le VMFS, il s’agit de la disponibilité
des primitives VAAI.

 Full File Clone : décharge les opérations de clone à froid et de déploiement d’une
machine virtuelle à partir d’un template au NAS. Cette primitive fonctionne
uniquement lorsque la VM de départ est éteinte. La fonction de Storage vMotion n’est
pas supportée sur un datastore en NFS, le déplacement de la VM est toujours à la
charge du datamover du VMKernel.
 Fast File Clone : Ici il s’agit du cas où la création de Linked Clone est déchargée au niveau
du NAS. Cette fonctionnalité est totalement supportée à partir d’Horizon Suite 5.3. A
partir de vSphere 5.1 et vCloud 5.1, cette fonctionnalité est utilisée lorsque l’on déploie
une vApp en mode Fast Provisionning en s’appuyant sur la technologie des Linked
Clone.
 Reserve Space : Historiquement lorsqu’on déployait une VM sur un datastore en NFS,
le VMDK était automatiquement au format Thin Provisionning. Il était impossible de
 pré allouer l’espace de stockage. Avec la primitive « Reserve Space » il est possible de
créer des VMDK au format Thick Provisonning. Lorsque l’on crée une VM sur NAS VAAI
NAS compatible, une commande Flat est envoyée au NAS pour garantir la disponibilité
de l’espace de stockage pour le VMDK. Cette commande revient à créer un VMDK en
Thick Provisonning Lazyzeroedthick sur un datastore VMFS, où les blocs seront mis à
zéro lors de la première écriture.
 Extended Stats : Cette primitive permet d’envoyer des requêtes au NAS pour connaitre
l’espace de stockage utilisé par les VMDK à l’instant T. Comme par défaut les VMDK
sont déployés en Thin Provisionning, cette commande permet de contrôler la sur
allocation de l’espace de stockage.

En résumé, les raisons pour lesquelles Nutanix a retenu le système NFS pour son stockage
distribué sont les suivantes :

 Réseau haute densité et parfaitement scalable au travers des interfaces 10G sur du
matériel de commodité, pas besoin de faire l’acquisition de matériel spécifique (HBA,
switch FC, licence etc…)
 Stockage NFS ne souffrant pas du phénomène de réservation SCSI
 Support des primitives VAAI NAS pour accélérer le déploiement des VMs
 Taux de consolidation des VMs par datastore beaucoup plus élevé que sur du VMFS
impliquant une simplification de la gestion du stockage
 Une Queue Depth quasiment illimitée
 Pas de problèmes de resignature des LUNs sur un stockage NFS

3.4 L’utilisation des disques SSD

L’architecture Nutanix a été développée pour tirer le meilleur parti des disques solid-state
drives les plus performants du marché. Il est important de noter que les systèmes de stockage
traditionnels ont été pensés pour exploiter des disques mécaniques et l’exploitation de
disques SSD de manière efficace s’avère très compliquée pour eux, car le mode d’accès aux
données est complètement différent avec les disques SSD. Les disques durs doivent gérer des
rotations et optimiser la latence des recherches, les disques SSD n’ont pas ces limitations
physiques. Cette différence entre les deux médias induit un paramétrage différent pour tirer
le maximum de performance des disques SSD.

On ne peut pas simplement utiliser un logiciel prévu pour des systèmes à disques durs et
espérer qu’il fonctionnera efficacement avec des disques solid-state. La solution Nutanix
fédère les disques SSD du cluster pour stocker les données accédées fréquemment. Par
exemple, les métadonnées et les données « chaudes » du stockage primaire, sont stockées
au sein de ce cache distribué pour la haute performance et persistant pour un recouvrement
rapide des données.
Pour maximiser le gain en performance des SSD, la solution Nutanix :
 Réserve les disques SSD pour les fonctions gourmandes en I/O
 Inclus des technologies d’optimisation d’espace utilisé pour permettre à une grande
capacité d’espace virtuel d’être stocké sur une petite quantité d’espace physique
 Migre automatiquement les données « froides » ou rarement utilisées vers des
disques durs capacitifs, et permet aux administrateurs systèmes de by passer les SSD
pour les machines virtuelles dont la criticité est faible.

3.5 Des fonctions de management distribuées

L’architecture du cluster Nutanix repose sur deux composants :

 Contrôl Plane : PRISM

 Data Plane : Acropolis
o Distributed Storage Fabric
o App Mobility Fabric

3.5.1 PRISM : Architecture

Prism est une interface d’administration distribuée permettant aux administrateurs de gérer
et superviser des objets (stockage, machine virtuelle) et services (ajout/suppression de
nœuds, réplication synchrone/asynchrone) sur une plateforme Nutanix. Ces fonctionnalités
sont reparties dans deux catégories :

 Interfaces
o HTML5, REST API, CLI, Powershell Cmdlets etc…
 Management
o Définition des règles de gestion, de compliance, supervision, outil analytique
Prism se divise en deux composants :

 Prism Central (PC)

o PC est un console d’administration permettant de fédérer l’administration de
plusieurs cluster Nutanix. Dans le cas d’une infrastructure Nutanix avec
plusieurs clusters, que ce soit sur un seul site ou sur des sites distants, Prism
Central fournit une vision unifiee de l’ensemble de ces clusters.
L’administrateur s’authentifie une seule fois dans Prism Central et peut ensuite
naviguer sur l’ensemble des clusters quelque soit l’hyperviseur installé
(vSphere, Hyper-V, Acropolis Hyperviseur).
 Prism Element (PE)
o PE est le console d’administration pour un cluster Nutanix. Chaque cluster
Nutanix dispose de sa console d’administration Prism Element.

Prism est un service présent dans chacune des CVM. L’un des services Prism est élu comme
leader au sein du cluster et il est responsable de traiter les requêtes http. Comme la plupart
des autres composants du logiciel Nutanix, il y a toujours une organisation de type
maitre/esclave. Si le Prism leader est défaillant, un nouveau leader est élu au sein du cluster.
Quand une CVM qui n’est porte pas le Prism leader reçoit une requête http, elle est
automatiquement redirigée vers le leader.
Prisme coute sur les ports 80 et 9440, si une requête arrive sur le port 80, alors elle est
automatiquement renvoyée en https sur le port 9440.
 3.5.2 API et interfaces

Nutanix propose des API et des interfaces en lignes de commande pour offrir des capacités
d’automatisation et d’industrialisation de la plateforme. Par défaut toutes les opérations
réalisées dans Prism Element sont accessibles via les REST API.
Ces REST API présentes sur chaque cluster Nutanix permettent de s’intégrer avec des outils
tels que :
 Saltstack
 Puppet
 vRealize Automation
 System Center Orchestrator
 Ansible
De plus au niveau des CVMs, plusieurs environnement CLI (ACLI : Acropolis CLI | NCLI : Nutanix
CLI) sont également disponibles pour accéder à des fonctions avancées ou à des fins
d’automatisations. Ces interfaces sont disponibles via une connexion SSH sur l’une des CVMs
du cluster.
Nutanix met également à disposition des cmdlets Powershell pour piloter les fonctionnalités
du cluster.

3.6 Intégration avec OpenStack

OpenStack est un plateforme open source permettant de construire et de gérer des cloud
prive/public. OpenStack repose sur deux composants, un front-end exposant des tableaux
bords et des APIs, un backend qui se compose de services d’infrastructures (compute,
stockage etc…).

L’intégration entre Nutanix et OpenStack utilise plusieurs éléments :

 OpenStack Controller (OSC)

Cette machine virtuelle a en charge la GUI Openstack ainsi que les API et les services. Elle gère
tous les appels aux APIs Openstack.

 Acropolis OpenStack Driver

Ces drivers fournis par Nutanix reçoit tous les appels RPCs provenant de l’OpenStack
Controller et les convertit en appels aux API d’Acropolis.

 Acropolis OpenStack Services VM (OVM)

Cette VM est fournit par Nutanix et porte les Acropolis OpenStack Driver.

L’utilisateur d’Openstack consomme ces services comme il a l’habitude de le faire en utilisant

l’interface graphique, SDK, CLI ou les APIs. L’OpenStack Controller (OSC) communique avec
l’Acropolis OpenStack Services VM (OVM). L’OVM se charge de convertir les requêtes
provenant de l’OSC en requete API REST pour consommer les ressources exposées (compute
et stockage) par le cluster Nutanix. Toutes les distributions d’OpenStack sont supportées a
partir de la version « Kilo » du contrôleur OpenStack.
Voici un mapping de rôles supportes par les différents composants :

La suite OpenStack propose une suite de services. Dans l’integration Nutanix/OpenStack

certains services sont portes par OpenStack et d’autres par Nutanix. Le tableau suivant
reprend les différents composant d’une infrastructure OpenStack et montre la distribution
des roles.
Le schéma suivant décrit la communication entre les éléments OpenStack et l’infrastructure
Nutanix :
 3.7 Une gestion du stockage distribuée

Acropolis est une solution distribuée de gestion de la donnée, également appelée « data
plane ».

Ce data plane s’articule autour de trois éléments :

 Distributed Storage Fabric (DSF)

o Le DSF est le composant a la base de la technologie Nutanix. Au démarrage de
la solution Nutanix, ce composant s’appelait aussi Nutanix Distibuted
FileSystem (NDFS). Les fonctionnalités de ce système de fichier distribue ayant
fortement évoluée au cours des dernières années, son a été modifie pour
refléter ses capacités actuelles.
 App Mobility Fabric
o L’AMF est un framework de fonctionnalités permettant de déplacer des
machines virtuelles entre differents hyperviseurs (par exemple de vSphere
vers Acropolis Hypervisor (KVM)) ou encore de migrer une machine virtuelle
d’un site de production vers le cloud (Amazon ou Azure) directement a partir
de la console d’administration Prism.
 Hypervisor
o Nutanix a développé sa propre offre de virtualisation, appelée Acropolis
Hypervisor, en s’appuyant sur CentOS KVM et une suite de logiciel open source
gravitant autour de KVM. Nutanix supporte egalement les principaux acteurs
du marche de la virtualisation VMware vSphere et Microsoft Hyper-V.
 3.7.1 La convergence

Nutanix commercialise sa solution au travers d’appliance regroupant puissance de compute,

stockage local (mix de SSD et de disques SATA), et une machine virtuelle appelée CVM qui
porte le logiciel Nutanix.

D’un point de materiel, ces appliances sont particulièrement denses car elles permettent de
regrouper de 1 à 4 nœuds dans un chassis de 2U.
 Serveur x86 (mono ou bi processeur)
 64 à 768GB RAM par nœud
 1 interface IPMI 1G | 2 ou 4 interfaces 1G | 2 ou 4 interfaces 10G SFP+/Base-T par
nœud
 3.7.2 Software Defined

La convergence est un processus qui commence avant tout par le logiciel. La convergence
matérielle n’est qu’une conséquence de la convergence logicielle. Au sein d’une plateforme
Nutanix touts les fonctionnalités sont opérées à 100% par le logiciel. Il n’y a aucun composant
matériel spécifique à l’intérieur des nœuds.

Ce principe d’architecture, dit Web-Scale, est ce que les géants du web Google, Facebook,
Amazon ont initié il y a déjà plusieurs années, une plateforme hardware simple reposant sur
du matériel x86 standard, le tout fédéré par un logiciel disposant des capacités pour agréger
les ressources, fournir des services de supervision, réplication, localisation de la donnée, auto
réparation du cluster en cas de panne matérielle etc…

3.7.3 Composants du cluster Nutanix

La caractéristique du logiciel Nutanix est qu’il est entièrement composé de brique

technologique issues du monde du Big Data et notamment de la suite Hadoop.
 Base de donnees NoSQL Cassandra
 MapReduce
 Curator
 Zookeeper
 Algorhtime de Paxos pour garantir la coherence des donnees
 …
  Cassandra

Cassandra stocke et gère toutes les métadonnées du cluster et utilise une version modifiée
d’Apache Cassandra. L’algorithme de Paxos est utilisé pour garantir la consistance des
données au sein du système de fichier distribue. Ce service s’exécute dans chacune des CVMs.
L’interface d’accès à Cassandra s’appelle Medusa.

 Zookeeper

Zookeeper stocke toutes les configurations du cluster y compris les informations sur les hôtes
de virtualisation, IPs, l’état des composants etc…Il s’appuie sur Apache Zookeeper. Ce service
s’exécute sur trois nœuds dans le cluster avec un fonctionnement un maitre et deux esclaves.
Le leader reçoit toutes les requêtes puis les transmets aux autres instances de Zookeeper. Si
le leader est indisponible, un mécanisme de réélection est lancé pour déterminer un nouveau
leader. L’interface d’accès à Zookeeper s’appelle Zeus.

 Stargate

Stargate est responsable de toutes les opérations de lecture et ecriture de la donnée sur le
stockage local de chacun des nœuds du cluster. C’est l’interface entre le système Nutanix et
l’hyperviseur. En fonction de l’hyperviseur(vSphere/Hyper-V/AHV) le stockage est exposé
avec un protocole diffèrent (NFS/SMBv3/iSCSI).
Stargate étant présent sur chacun des nœuds, la donnée est toujours lue et écrite à partir du
SSD localement ce qui offre un niveau de performance élevé.

 Curator
Curator est responsable de la gestion et de la distribution des taches à travers le cluster
incluant l’équilibrage de la consommation de l’espace disque, le nettoyage des données.
Curator fonctionne toujours sur un principe maitre/escalve. Curaor réalise deux types de
scan : complet toutes les 6 heures et partiel toutes les 6 heures.

 Prism

Prism est l’interface graphique développée en HTML5 permettant d’administrer simplement

le cluster Nutanix. Elle expose également des API REST à des fins d’intégration,
automatisation, orchestration.
 3.7.4 Services Acropolis

Dans le cas d’un déploiement d’Acropolis Hypervisor (KVM), les services Acropolis sont
présents dans chacune des CVMs. Acropolis Hypervisor offre une solution de virtualisation à
moindre cout au travers de KVM et son écosystème. Grace à cette offre de Nutanix, il est
possible de créer, administrer des machines virtuelles et des réseaux virtuels directement au
travers de la console d’administration sans aucune connaissance de l’hyperviseur KVM ou des
outils open source qui gravitent autour ou encore de CentOS.

3.7.5 Système de fichier distribué

Ensemble les nœuds Nutanix forment un système distribué appelé Acropolis Distributed
Storage Fabric (DSF). DSF apparaît aux hyperviseurs (vSphere/Hyper-V/AHV) comme un
système de stockage partagé. Cependant toutes les opérations de lecture et écriture de la
donnée sont réalisée en local via le Controler VM (CVM).
 3.7.6 Structure des données

La structure des données repose sur trois éléments dans un cluster Nutanix :

 Storage Pool
Le storage pool est un groupe de disque physique. Par défaut dans un storage pool on
regroupe tous les disques SSD et HDD de tous les nœuds du cluster.

 Container

Par dessus ce storage pool, on crée des containers qui permettront à l’administrateur de la
plateforme de virtualisation de pourvoir stocker ses machines virtuelles. Le container est un
objet coté Nutanix qui se matérialise par un datastore en NFS sur une plateforme de
virtualisation vSphere ou encore un partage SMBv3 sur un cluster Hyper-V. Il y a une relation
de 1 :1 entre un container Nutanix et un datastore pour les machines virtuelles.

 vDisk

Un vDisk est un fichier de plus de 512KB (par exemple un disque virtuel virtuel vmdk ou vhd)
stocké dans un container.

3.7.7 Chemin de l’I/O et système de cache

Le stockage local d’un nœud Nutanix est composé de disques SSD et de disques mécaniques
HDD SATA.
Les disques SSD sont là pour apporter la performance et les disques SATA sont là pour
adresser les besoins en volumétrie.
Le schéma suivant décrit les différents chemins des I/O en fonction de leur nature
  Oplog

L’Oplog est une zone de cache en écriture pour toutes les écritures de type random. Via un
algorithme de tiering les données sont ensuite, si c’est nécessaire, descendu au niveau de
l’Extent Store.
L’oplog est répliqué de manière synchrone vers d’autre nœuds Nutanix avant d’envoyer
l’acquittement de l’écriture. Etant donné qu’il n’y a aucun système de Raid appliqué sur les
disques physiques de chaque nœud, il est indispensable de trouver une solution pour
sécuriser la donnée. C’est la raison pour laquelle, par défaut la donnée est écrite en local et
répliquée de manière synchrone vers un autre nœud. De cette façon la donnée existe toujours
deux fois au sein du cluster Nutanix.
Pour les écritures séquentielles, l’Oplog est n’est pas utilisé et les opérations se faites
directement au niveau de l’Extent Store.

 Unified Cache

Si la donnée reste présente dans l’Oplog, toutes les requêtes en lecture sont ensuite servies
par le Unified Cache (Cache en lecture). Cette zone de cache en lecture repose sur le SSD et
sur de la mémoire. La CVM utilise une partie de la mémoire qui lui est allouée pour en faire
une zone de cache en lecture.
  Extent Store

L’Extent Store est la zone d’écriture persistante et s’appuie sur le SSD et le HDD. Les données
arrivant sur l’Extent Store sont issues soit de l’Oplog, soit ce sont des écritures séquentielles
qui par nature de vont pas dans l’Oplog.

3.7.8 Data Protection

Le cluster Nutanix s’appuie sur un facteur de résilience, également appelé facteur de

réplication (Replication Factor (RF)) couple à un mécanisme de checksum pour assurer la
disponibilité de la donnée dans le cas de la perte d ‘un nœud. Au niveau du stockage physique
présent à l’avant des blocks (châssis de 2U) aucune notion de RAID n’est appliquée sur les
disques SATA et encore moins sur les disques SSD. Pour garantir la redondance de la donnée
Nutanix utilise un facteur de réplication qui par défaut est de 2 et peut monter jusqu’à 3.

Que ce soit dans le cas des écriture random ou séquentielles, le SSD est là pour fournir la
performance du stockage et absorbe toutes les écritures. Lorsqu’une écriture est faite sur
l’Oplog d’un nœud, elle est automatiquement répliquée sur un autre nœud, dans le cas du
RF2, ou sur deux nœuds supplémentaires dans le cas du RF3 dans le cluster. L’acquittement
de l’écriture n’est renvoyé que lorsque la deuxième copie, ou la troisième copie dans le cas
du RF3, a été écrite. Un checksum est calculé systématiquement lorsque cette deuxième ou
troisième écriture est faite afin de garantir la consistance des données sur l’ensemble du
cluster. Ce checksum fait entre autre partie des metadata et est stocké dans la base de
données Cassandra.

Dans le cas de la perte d’un disque ou d’un nœud, le cluster reconstruit automatiquement le
RF2 ou RF3 à de la copie restante de manière à toujours protégé en cas de défaillance du
cluster. Le système de fichiers distribué, par la suite redistribue la donnée à travers tout le
cluster pour équilibrer l’occupation des espaces disques.
Par défaut, lors de l’installation initiale d’un cluster, c’est un facteur de réplication 2 qui est
sélectionné. Dans certains cas, lorsque l’on souhaite un niveau de résilience accru, il est
possible d’utiliser un facteur de réplication de 3.

Jusqu’à AOS 4.6, le seul moyen de passer en cours de route de RF2 à RF3 était de détruire le
cluster puis d’en créer un nouveau en déclarant des le début le RF3. Cette opération était
quasiment impossible car cela signifiait de migrer les machines virtuelles vers une
infrastructure temporaire le temps de la reconstruction du cluster. A partir d’Acropolis OS
4.6, la migration de RF2 vers RF3 se fait de manière transparente et il n’est plus nécessaire de
détruire le cluster Nutanix. Sous réserve d’avoir le nombre de nœud minimum et la
volumétrie utile nécessaire, il est possible a tout moment de passer du RF2 au RF3.

3.7.9 Availibility Domain

La fonction « Availibility domain » permet de répliquer les données à travers plusieurs blocks
et donc plusieurs châssis. Cette construction permet d’améliorer la disponibilité de la
plateforme et de supporter la perte d’un rack physique complet à l’intérieur du Datacenter.
Le DSF a conscient de la localisation des block (Chassis de 2U) ainsi que des blocs de donnée
et est capable de distribuer la donnée à travers plusieurs blocks.

3.7.10 Résilience de l’accès à la donnée : Autopath

Contrairement aux architectures traditionnelles où l’on part du principe que le matériel est
fiable, Nutanix adopte une approche différente issue des méthodologies appliquées
notamment par Google et Facebook. Dans cette nouvelle approche, on part du principe que
le matériel peut éventuellement est indisponible.
Partant de ce principe, le système est conçu nativement pour gérer les pannes et de manière
non disruptive.

Cette approche ne signifie pas les composants ne sont pas soigneusement sélectionnés, il
s’agit simplement d’un changement de vision de l’infrastructure. Les équipes de R&D de
Nutanix ont des process de qualifications des composants très rigoureux. Pour information,
les composants des nœuds sont principalement fournis par Intel (processeur, SSD, carte
réseau).

Le système distribué de Nutanix est conçu pour savoir gérer une défaillance au niveau
composant matériel, service et CVM. Une défaillance peut arriver sur trois niveaux :
 Disque
 CVM
 Nœud

Dans le cas d’une défaillance d’un disque les impacts sur les VMs sont les suivants :
 HA event : No
 Failed I/Os : No
 Latency : No impact

Dans le cas de la perte d’un disque, Curator (MapReduce Framework) déclenche un scan
immédiatement. Il va scanner les les metadata de Cassandra pour trouver la donnée
précédemment stockée sur le disque défaillant et le disque ou nœud portant la deuxième
copie de cette donnée (le réplica).
Lorsque cette donne est trouvée, elle va être re-repliquée et distribuée afin de retomber dans
une situation de RF2.
Etant donne le principe de distribution de la donnée dans un cluster Nutanix, pour ce type
d’opération ces sont tous les nœuds / CVM / disques qui participent à cette tache limitant
ainsi le temps et l’impact sur les performances durant cette période de reconstruction.
Par conséquent, plus il y a de nœuds dans un cluster Nutanix, plus le niveau de résilience
augmente, plus le temps de reconstruction de la donne sera court et l’impact sur la
performance globale faible.

Dans le cas de la perte d’une CVM (power off de la VM, indisponibilité d’un service), le
système est conçu pour gérer cette situation de manière transparente. Si la CVM local n’est
plus opérationnelle pour traiter les accès au stockage local, les accès en lectures et écritures
sont rediriges vers un autre nœud du cluster.
Ce mécanisme est valable pour tous les hyperviseurs supportes par Nutanix, mais
techniquement va fonctionner différemment.
Nutanix s’appuie sur ce même mécanisme pour opérer la mise du système globale.

Dans le cas de la perte d’une CVM, les impacts sur les VMs sont les suivants :

 HA event : No
 Failed I/Os : No
 Latency : Potentially higher given I/Os over the network
Dans le cas VMware vSphere et Microsoft Hyper-V le mécanisme de redirection des accès au
stockage vers une autre CVM est appelé Autopath. Cette fonction utilise un script HA.py pour
modifier la route réseau utilisée par défaut en local pour accéder au stockage en changeant
la passerelle de cette route et en spécifiant l’IP publique d’une autre CVM.
La datastore en NFS dans le cas de vSphere ou le partage SMBv3 dans le cas d’Hyper-V reste
intact les Ios sont simplement servis par une autre CVM.

Dans le cas de Acropolis Hypervisor, Nutanix s’appuie sur de l’iSCSI pour présenter le stockage
au VMs. Dans le cas de la perte d’une CVM se sont les mécanismes de multipath inhérents à
l’iSCSI qui sont utilisés.

Lorsque la CVM locale est à nouveau opérationnelle et stable, l’accès au stockage est à
nouveau réalisé en local.

Dernier scenario envisageable, il s’agit de la perte complet d’un nœud Nutanix. Dans ce cas,
on perd à la fois le stockage local mais aussi toute la partie compute (CPU et mémoire) avec
l’hyperviseur. En fonction des fonctionnalités de l’hyperviseur déployé, les machines
virtuelles vont redémarrer sur les autres hyperviseurs présents dans le cluster. La donnée
étant distribuée par défaut les machines virtuelles vont pouvoir repartir.

Le mécanisme de reconstruction de la donnée est identique à celui utilise dans le cas de la

perte d’un disque.

3.7.11 Erasure Coding

Nutanix exploite un principe de facteur de réplication pour assurer la protection et la

disponibilité des données au sein de son cluster. Cependant, cette approche a un coup sur la
volumétrie disponible dans un cluster car les données sont écrites deux ou trois fois.
Afin de conserver la protection et la disponibilité de la donnée tout en améliorant la quantité
de volumétrie utile, Nutanix a intégré une fonction d’Erasure Coding.

Similaire au concept de RAID où une parité est calculée, l’erasure coding regroupe les blocs
de données au travers de plusieurs block physique (châssis 2U) et calcule une parité. Dans le
cas de la perte d’un nœud ou d’un disque, on s’appuie sur la parité pour calculer la donnée
manquante.

Le calcul de parité est fait en tache de fond (post-process) et s’appuie sur Curator et son
Framework MapReduce pour distribuer la tache de calcul. Ce mécanisme étant exécuté en
tache de fond, il ne vient pas dégrader le processus d’écriture de la donnée.

Un environnement normal avec facteur de réplication ressemble au schéma suivant :

Dans cette exemple, il y a un mix de RF2 et RF3. Lorsque Curator opère un scan complet, il va
identifier toutes les données éligibles à l’erasure coding. Les données éligibles à l’erasure
coding sont les données non modifiées depuis plus d’une heure.

Une fois le processus d’erasure coding, et le calcul de parité terminé, on peut observer la
réduction de la consommation de l’espace de stockage :
L’Erasure Coding peut parfaitement être activée conjointement avec les mécanismes de
compression et/ou déduplication proposés par le DSF.

3.7.12 Compression

Le DSF de Nutanix propose par défaut deux mode de compression : Inline et Post-process. Le
mode compression Inline va compresser les accès séquentiels ou les blocs de données de
grande taille, en mémoire avant de réaliser l’écriture sur disque. Dans le cas de la compression
post-process, les données sont d’abord écrites, puis à intervalle régulier, lors d’un scan de
Curator, elles seront compressées si cela est possible en fonction de la structure des données.
Lorsque la compression inline est activé mais que les IOs sont de type random, les données
sont d’abord écrites dans l’Oplog, puis rassemblées, et ensuite compressées en mémoire
avant d’être écrites dans l’Exten Store.

Nutanix exploite la librairie Google Snappy pour fournir ce mécanisme de compression. Cette
librairie permet de bons taux de compression avec une consommation réduite de puissance
de calcul et des taux de décompression très rapides.
Par défaut, Nutanix recommande d’activer la compression inline. Ce mécanisme ne concerne
que les blocs de grande taille et les écritures séquentielles et n’a aucun impact sur les
écritures random.
La compression Inline s’associe parfaitement bien avec l’Erasure Coding afin d’améliorer du
mieux possible la volumétrie disponible du cluster.

Pour la compression post-process, toutes les nouvelles écritures suivent le chemin d’accès
normal au stockage. Après le délai de compression, configuré dans PRISM, les données
froides (présentes sur les disques HDD) sont éligibles à la compression. La compression post-
process est orchestrée par Curator et son framework MapReduce. La tache de compression
est alors distribuée sur tous les nœuds du cluster.
Pour les accès en lecture, la donnée est d’abord décompressée en mémoire. Pour la donnée
fréquemment appelée, elle reste décompressée sur les HDD et éventuellement remontée en
SSD sur la fonction de tiering le décide.
 3.7.13 Déduplication

Au même titre que la compression, Nutanix propose un système de déduplication Inline (SSD
et mémoire) et post process (HDD). Dans le cas de la déduplication, pour chaque bloc de
donnée écrit sur le cluster un identifiant / hash (« Fingerprint ») est calculé en utilisant
l’algorithme SHA-1.
Ce Hash est uniquement calculé pour les données entrant sur le cluster Nutanix et est ensuite
stocké de manière persistante dans la base de donnée Cassandra.

Contrairement aux approches traditionnelles qui utilisent un scan complet en tache de fond
pour relire toutes les données et identifier celle devant être dédupliquée, Nutanix réalise
cette tache d’identification lors de l’arrivée des données sur le cluster.
Pour la déduplication post process, seules les données ayant le même hash sont supprimées.
Comme toujours cette tache de déduplication post process est distribuée sur l’ensemble des
nœuds du cluster.

Nutanix s’appuie sur les instructions des CPU Intel pour réaliser le calcul du Hash avec SHA-1.
Dans le cas où le calcul du fingerprint n’a pas pu être fait à l’arrivée de la donnée (par exemple
à cause d’une taille d’IO trop petite), il sera fait en tache de fond plus tard.

Le mode opératoire de la déduplication inline est particulier dans le cas du cluster Nutanix.
Chaque bloc de donnée disposant d’un hash, lorsque les données remontent dans le cache
en lecture (Unified Cache), si le système trouve des blocs identiques, les copies en trop sont
alors supprimées.
De cette manière, la déduplication permet de maximiser l’utilisation du cache en lecture et
d’y placer davantage d’information.
La déduplication inline est calculée pour le moment sur les 24 premiers Go du disque virtuel
afin de limiter la quantité des metadata. Sur cet espace on retrouve généralement le système
d’exploitation. Dans le cas de machines virtuelles déployées à partir d’une image de
référence, les blocs relatifs au système d’exploitation sont souvent les mêmes ce qui permet
d’obtenir de bons taux de déduplication.
Le schéma suivant illustre le principe de déduplication inline, également déduplication inline
dans le cache :
 3.7.14 Equilibrage de l’utilisation des espaces disques

Le DSF est une plateforme très dynamique et capable de recevoir des nœuds de
configurations différentes à l’intérieur d’un même cluster. Typiquement dans le cas où on l’a
des nœuds avec des disques SATA de 1TB et d’autres de 6TB, le système doit être capable
d’harmoniser l’utilisation des espaces disques sur l’ensemble du cluster.

Cette fonctionnalité est appelée « Disk Balancing » dans la terminologie Nutanix. Dans le cas
d’un cluster Nutanix construit avec des nœuds de la série 3000 et 6000, il y a une très forte
probabilité que l’occupation des espaces disques ne soit pas la même sur tous les nœuds.

La fonction de « Disk Balancing » s’appuie sur Curator pour observer l’utilisation de l’espace
disque de tous les disques du cluster et si nécessaire améliorer la répartition des données.
 3.7.15 Volume Group

Le Volume Group est une fonctionnalité présente depuis quelques temps. Le principe est de
prendre une portion du stockage distribué exposé par le cluster et de connecter ce stockage
directement à l’intérieur d’une machine virtuelle au travers du Guest initiator iSCSI. Jusqu’à
maintenant toutes les actions nécessaires à la configuration du VG se faisaient en CLI. Avec
cette version 4.6, la configuration des VG se fait dans la vue Storage de la même manière que
pour provisionner des containers (datastores). De plus, les VG intègre aussi les mécanismes
de réplication asynchrone pour fournir des services de DR.
Les VG vont simplifier la mise en œuvre des applications telles que MS Exchange, Ms Failover
Clustering, Oracle RAC pour ne citer que celles là.
Le VG peut également s’avérer très utile lorsqu’il s’agit de construire un cluster MS
nécessitant un disque de quorum. Dernier use case, le cas des bases de données Oracle, tout
le monde connait aujourd’hui la contrainte du licensing Oracle lorsque l’on est en
environnement virtuel. Pour régler définitivement la question, il est supporter d’exposer ce
VG à l’extérieur du cluster Nutanix à destination d’un ou plusieurs serveurs Oracle physiques.
Dans ce cas de figure, il n’existe plus de problématique de licensing Oracle, mais le stockage
qui supporte les DB Oracle provient du cluster Nutanix et fournit toute la puissance
induite par le DSF et la supervision allant avec.

La configuration des Volume Group est disponible ici. Bien sur, il est toujours possible
d’automatiser ces étapes en passant par le shell Acropolis CLI.

En prime, les Volume Groups peuvent être répliqués de la même manière que les machines
virtuelles en s’appuyant sur les domaines de protection. Peu importe que l’infrastructure
Exchange exploite le DAG ou pas, peu importe que les cluster MS soient geo localisés ou pas,
le cluster Nutanix apporte des réponses pour adresser les besoins en PRA en toute
circonstance.

3.7.16 Nutanix Guest Tools

Les Nutanix Guest Tools (NGT) font leur apparition à partir de al version 4.6 d’AOS. On peut
faire le parallèle avec les VMware Tools pour se raccrocher à quelque chose de familier. Les
NGT deviennent un composant incontournable de l’architecture Nutanix. C’est le
dénominateur commun pour accéder aux fonctions de : Cross Hypervisor Migration, Convert
Cluster, File Level Restore.

Les NGT apportent les composants suivants :

 Guest agent service
 Self service Restore (SSR) aka File Level Restore (FLR) CLI
 VM Mobility Driver (VirtIO Drivers for AHV)
 VSS Agent and Hardware provider for Windows VM
 App Consistent snapshot support for Linux VMs (via script to quiesce)

L’architecture des NGT repose sur deux éléments :

 Guest Tools Service
o Il s’agit de la gateway entre Acropolis et les services Nutanix et l’agent NGT
présent dans les VMs. Les Guest Tools Service sont présents dans toutes les
 CVM avec un Master NGT s’exécutant sur le nœud étant Prism Leader (celui
qui porte la VIP du cluster)
 Guest Agent
Il s’agit de l’agent et des services associes déployés dans les machines virtuelles suite à
l’installation des NGT.

La partie Guest Tools Service (présente dans les CVMs) est divisée en deux composants :
 NGT Master :
o Le Master traite les requêtes provenant du proxy NGT et des différentes
interfaces d’Acropolis. Il existe un seul NGT au sein du cluster. Celui ci est élu
de manière dynamique et écoute sur le port 2073.
 NGT Proxy
o Ce proxy s’exécute sur chacune des CVMs et redirige les requêtes vers le NGT
master. La CVM étant Prism Leader et NGT Master va traiter toutes les
requêtes provenant des NGt Guest Agent. Le NGT proxy écoute sur le port
2074.
Le Guest Agent présent dans toutes les VMs regroupe les fonctionnalités suivantes :

Le Guest Agent communique avec le Guest Tools Service via la VIP du cluster en SSL. Le
module Guest Tools Service présent dans les CVM, joue le rôle d’autorité de certification et
est responsable de générer un couple de certificat pour le Guest Agent et le Guest Tools
Service lors de chaque installation des NGT. Le certificat est intégré directement dans le
fichier ISO qui est crée pour l’installation des NGT dans les machines virtuelles.

L’installation des NGT peut se faire directement dans la console d’administration PRISM ou
encore via REST API, ncli ou Powershell.

3.7.17 Snapshots et Clones

Le DSF propose nativement des fonctions de snapshot et de clones pouvant s’appuyer sur les
APIs VAAI, ODX, NCLI, REST et PRISM. Les snapshot et les clones utilisent l’algorithme du
redirect-on-write.
Contrairement à un environnement traditionnel, les snapshot et les clones sont des fonctions
pouvant être exploitées au niveau d’une machine virtuelle.
Les snapshot sont opérés directement au niveau du DSF et sont utilisés soit pour restaurer
une machine virtuelle dans sa totalité soit pour les besoins des mécanismes de réplication
asynchrone et synchrone.
 3.7.18 Réplication et Distater Recovery

Nutanix fournit par défaut des fonctionnalités de réplication et de gestion du plan de reprise
d’activité en s’appuyant sur ces capacités de snapshot et de clones. Cerebro est le nom du
composant en charge des mécanismes de réplication.
Cerebro s’exécute sur tous les nœuds Nutanix et travaille en mode maitre/esclave. Dans le
cas où le maitre Cerebro est indisponible, un système de réélection se lance et détermine un
nouveau maitre Cerebro dans la gestion de la réplication.

Concernant les topologies de réplication la technologie Nutanix offre tous les modes de
réplication :
La mise en œuvre de la réplication entre deux clusters Nutanix est très simple et s’opère en
mois de cinq minutes. Le système de réplication Nutanix repose sur deux éléments :

 Remote Site

Comme son nom l’indique, un site distant est un site hébergeant un cluster Nutanix et
pouvant recevoir une réplication provenant d’un autre cluster Nutanix.

 Protection Domain (PD)

Un domaine de protection correspond à un groupe de machines virtuelles ou à un container

(équivalent d’un datastore dans un environnement VMware vSphere) sur lequel une prise de
snapshot a été planifiée. Il est recommandé de créer un domaine de protection par niveau de
SLA souhaité (RTO/RPO).

 Consistency Group (CG)

Par défaut, sur un domaine de protection, lorsque la prise de snapshot va être faite, les
machines virtuelles sont traitées les uns après les autres. Dans certains cas, il peut être
nécessaire de prendre le snapshot de manière simultanée sur un ensemble de machine
virtuelle constituant une même application métier (base de données, application, serveur
Web).
A l’intérieur du domaine de protection, Nutanix propose la création d’un groupe de
consistance. Ce dernier est représente par un groupe de machines virtuelles sur lesquelles le
snapshot sera pris de manière simultanée.

 Retention Policy

La police de rétention correspond au nombre de snapshot que l’administrateur souhaite

conserver sur le site local et sur le site distant. Plus le nombre de snapshot conservé est
important pour le RPO peut être élevé.

Durant une séquence de réplication, le maitre Cerebro est en charge d’identifier les données
devant être répliquées, puis délègue la tache de réplication au Cerebro Slave en charge de
cette donnée.
Le système de réplication s’appuie sur des snapshot dans le cas de la réplication asynchrone.
Par défaut ces snapshot sont compresses à la source pour limiter la quantité de données
devant transiter sur les liens inter site.
De plus il est possible de limiter la bande passante utilisée par le système de réplication afin
de préserver de la ressource pour les autres services (Impressions, ToIP etc..) devant utiliser
les mêmes liens.
Dans le cas de la mise en place de réplication asynchrone avec VMware vSphere, chaque
cluster Nutanix sur chaque site héberge son propre vCenter. Lors des opérations de bascule
d’un site vers un autre, Nutanix se charge d’enregistrer les machines virtuelles dans
l’inventaire du vCenter de destination.
Pour des besoins spécifiques d’orchestration de redémarrage des machine virtuelles, Nutanix
fournit un SRA pour permettre le pilotage de la réplication du stockage avec Site Recovery
Manager de VMware.

 Global Déduplication

Le DSF a la capacité de mettre en place de la déduplication au niveau d’un cluster Nutanix

notamment via un calcul de fingerprint. Ce même concept est utilisé pour la réplication inter
site.
Avant de répliquer les données, le DSF vérifie sur le site distant sur le fingerprint existe ou
pas. Si le pointeur existe dans Cassandra sur le site distant, la donnée n’est pas répliquée et il
y a simplement une mise à jour des metadata. Pour les données non présentes à la
destination, elles sont compressées puis envoyées.
A partir d’Acropolis OS 4.6, Nutanix propose d’une manière simple et élégante la migration
de machines virtuelles entre ESXi et AHV. Le principe est le suivant, à partir d’un cluster
Nutanix tournant sous ESXi, il est désormais possible de migrer simplement tout ou une partie
des VMs vers un cluster Nutanix AHV. La réciproque est également vraie, la migration se fait
de ESXi vers AHV mais aussi de AHV vers ESXi.
La problématique adressée ici est la suivante. Pour exploiter plusieurs hyperviseurs au sein
d’une même infrastructure, cela demande d’étendre l’éventail de compétences des équipes
techniques. En fonction du gap technique à combler, la courbe d’apprentissage peut être plus
ou moins longue. De plus sur un plan purement technique, il est souvent nécessaire de
conjuguer plusieurs outils pour la mise en place du processus de migration entre deux
plateformes.
L’accumulation de solutions techniques ainsi que la montée en compétence des équipes
d’administration conduisent souvent les clients à faire machine arrière et à rester sur une
seule plateforme de virtualisation au détriment de l’équation économique.
Avec cette solution de Cross Hypervisor DR, Nutanix s’appuie sur son savoir faire en
environnement VMware et Acropolis Hypervisor pour offrir un pont entre ces deux
plateformes. Pour faire la jonction entre ces deux mondes rien de plus simple, Nutanix
s’appuie un mécanisme maîtrisée depuis bien longtemps, à savoir son système de réplication
asynchrone et les domaines de protection disponible au travers de la console
d’administration Prism Element.
L’opération est réalisable dans les deux sens, les machines virtuelles peuvent migrer de ESXi
vers AHV et inversement avec seulement quelques clics…

Voici la liste des Guest OS supportés :

 Windows 7 et 8
 Windows Server 2008 R2 à Windows Server 2012 R2
 CentOs 6,5 +
 RHEL 6.5 +
 Ubuntu 14.04 +
 SLES11 SP4 et SLES12
 Oracle Linux 6.5 +
L’élément indispensable pour que les bascules s’opèrent sans accroc est la présence des
Nutanix Guest Tools dans les machines virtuelles. L’installation des NGT apporte notamment
un composant appelé “VM Mobility Driver”. Ces drivers permettent notamment pour
l’environnement Windows de bénéficier des drivers optimisés pour le contrôleur de stockage
et la carte réseau du Guest OS Winodws. Ce sont en réalité les VirtIO nécessaire pour que le
Guest Os Windows puisse fonctionner dans de bonnes conditions sur AHV.

En résumé, chaque machine virtuelle doit disposer des VMware Tools et des Nutanix Guest
Tools pour un fonctionnement optimum sur chaque hyperviseur. Une fois ce travail de
préparation accompli, il reste plus qu’à configurer un domaine de protection pour protéger
un groupe de machines virtuelles.
Avec cette fonction de migration entre hyperviseur Nutanix introduit un nouveau composant
dans son architecture appelé Morphos. Morphos est en charge de la conversion des VM entre
ESXi et AHV. Il travaille en collaboration avec le module Cerebro, en charge de gérer la
réplication entre les clusters Nutanix. Une démonstration est disponible ici.

3.7.19 Metro Availibility

La fonction de Metro Availibility fait référence à la fonction de réplication synchrone chez

Nutanix. Dans ce mode de réplication l’infrastructure est construite en mode stretched
cluster.
Cette fonction ne s’applique pour le moment qu’aux plateformes Nutanix/VMware vSphere.
Un mécanisme très proche existe pour Hyper-V. Acropolis Hypervisor propose pour l’instant
que de la réplication asynchrone.

La construction du Metro Availibility (MA) est assez simple. Au niveau Nutanix deux clusters
distincts et au niveau VMware les ESXi des deux sites sont regroupes dans un seul et unique
objet cluster au niveau de l’inventaire du vCenter. Cette fonctionnalité permet d’étendre un
cluster VMware qu’entre deux sites.
Le principe de réplication synchrone apporte un RPO=0. Le cluster ESXi étendu sur deux sites
utilise la fonction de HA du cluster VMware pour redémarrer les machines virtuelles en case
de perte d’un site.

Lorsque la VM 1 réalise une écriture sur le site 1, cette écriture est également faite de manière
synchrone sur le site 2. L’acquittement est renvoyé si et seulement si la donnée est écrite sur
le site 2. C’est la raison pour laquelle Nutanix recommande un latence inferieure à 5ms RTT
sur el lien inter site. Plus la latence sera élevée et plus l’acquittement mettra du temps à
parvenir au site 1. De plus il est important de noter que seules les écritures sont répliquées.
Toutes les opérations en lecture se font en local sur chaque site pour respecter le principe de
localité de la donnée décrite dans la prochaine section.
 3.7.20 Localité de la donnée

Comme évoqué dans la section chemin IO et système de cache, chaque CVM traite les
opérations en lecture/écriture sur le stockage local qu’elle gère. Lorsqu’une VM se déplace
d’un nœud à un autre, l’accès au stockage vers être géré par la CVM à la destination.
Pour les opérations en écritures, il n’y a pas de changement, ces opérations vont se faire en
local c’est là le comportement par défaut du cluster Nutanix.

Quand cette machine virtuelle va se mettre à lire des données présentes sur le nœud qu’elle
vient de quitter, les requêtes vont être transmises de la nouvelle CVM vers l’ancienne. Si cette
donnée continue d’être appelée par la machine virtuelle qui vient de se déplacer, le DSF va
en tache de fond relocaliser la donnée au plus proche de la machine virtuelle. Ce bloc de
donnée va donc être migre vers le stockage local de la CVM qui porte cette machine virtuelle.

3.8 Acropolis Hypervisor : une offre de virtualisation par Nutanix

Acropolis Hypervisor est une offre de virtualisation conçue par Nutanix autour de solution
Open Source existante. Son nom de code AHV, est une plateforme de virtualisation reposant
sur l’hyperviseur KVM et un ensemble d’outil open source.

La proposition de valeur de Nutanix autour de cette plateforme est de simplifier toutes les
taches d’administration classique d’une plateforme de virtualisation (gestion du stockage,
administration des machines virtuelles et des réseaux virtuels) tout en se focalisant sur les
fonctions principales pour réduire le cout des infrastructures e virtualisation. AHV est inclut
de base dans les licences Nutanix et il n’est donc pas nécessaire de faire l’acquisition de
licence supplémentaire pour obtenir une couche de virtualisation.
La solution Acropolis Hypervisor repose sur CentOS KVM est offre des fonctionnalités
standard que l’on peut attendre d’une solution de virtualisation de type Enterprise :
 HA
 vMotion
 DRS like
 Snapshot
 Clone
 EVC
 …

Pour donner de la crédibilité à cette offre conçue par Nutanix, AHV est aujourd’hui certifiée
chez Microsoft est fait parti du programme SVVP.
Par ailleurs AHV est également certifié chez Citrix pour héberger les solutions suivantes :
 XenApp et XenDesktop 7.6 et suivante
 ShareFile Enterprise
 NetScaler 10.x
 CloudBridge 7.4 et suivante

3.8.1 KVM Architecture

AHV repose sur plusieurs briques techniques gravitant autour de KVM.

 KVM-kmod
o Kernel KVM
 Libvirtd
o API permettant de simplifier la gestion de KVM et QEMU. La communication
entre Acropolis, KVM et QEMU est faite via la librairie Libvirt
 Qemu-kvm
o Module permettant de virtualiser les instructions CPU et d’isoler les VM entre
elles et avec le host
 3.8.2 Configuration Maximums

 Nombre maximum de nœud dans un cluster : N/A (identique à celui du cluster

Nutanix)
 Nombre maximum de vCPU par VM : Limité au nombre de cœur physique par nœud
 RAM Maximum par VM : 2TB
 Nombre maximum de VM par nœud : Limité à la mémoire disponible sur le nœud
 Nombre maximum de VM par cluster : Limité à la mémoire disponible dans le cluster

3.8.3 Réseaux virtuels dans AHV

AHV s’appuie sur Open vSwitch pour fournir des réseaux virtuels aux machines virtuelles. LA
configuration des reseaux virtuels se fait au travers de la console d’administration PRISM ou
via le shell ACLI (Acropolis CLI).
 3.8.4 iSCSI multi-pathing

Sur chaque host KVM, on retrouve un demon iSCSI qui vérifie la disponibilité du module
Stargate (composant responsable des opérations en lecture/écriture sur le stockage dans le
DSF).
QEMU est configuré avec un redirecteur iSCSI vers le portail iSCSI de la CVM.

Dans le cas ou le module Stargate actif n’est plus disponible, le redirecteur iSCSI de QEMU
identifie comme indisponible la CVM locale. Lorsque le redirecteur iSCSI de QEMU va chercher
à s’authentifier à nouveau sur le portail iSCSI, il sera redirigé vers une autre CVM du cluster.
Lorsque la CVM locale est à nouveau disponible et stable, le chemin d’accès au stockage est
à nouveau opéré en local.

3.8.5 Gestion des adresses IP

AHV propose dans la gestion des réseaux virtuels un module de gestion des adresses IP
(IPAM). Cet IPAM déploie un serveur DHCP par réseau virtuel et permet d’attribuer une IP
provenant d’un pool défini lors de la création du réseau virtuel, à chaque machine virtuelle
affectée et démarrée dans ce réseau virtuel.
Cette configuration des réseaux virtuels est par défaut distribuée. Lorsque l’on crée un réseau
virtuel dans PRISM (équivalent d’un port group dans le monde VMware vSphere), ce réseau
virtuel est automatiquement crée sur tous les nœuds du cluster.

3.8.6 VM High Availibility (HA)

AHV offre par défaut une fonctionnalité de HA qui permet de redémarrer automatiquement
les machines virtuelles en cas de perte d’un hosts dans le cluster. Cette fonction est similaire
à la fonction de HA sur un cluster vSphere.