La résilience des données décrit le nombre et les types de pannes qu'un cluster peut

supporter; déterminé par des fonctionnalités telles que le facteur de redondance et la

détection des blocs ou des racks.
Après avoir terminé ce module, vous serez en mesure de:
 Décrivez l'impact des pannes de composants au sein du cluster Nutanix sur les
opérations des VM invitées.
 Expliquez la procédure de récupération pour une panne donnée.
 Décrivez le facteur de réplication et son impact.
 Décrivez la détection des blocs et des racks.
Indisponibilité CVM
L'indisponibilité des composants est une partie inévitable de tout cycle de vie de centre
de données. L'architecture Nutanix a été conçue pour résoudre les pannes en utilisant
diverses formes de redondance matérielle et logicielle.
  

Un cluster peut tolérer les défaillances uniques d' une variété de composants tout en

exécutant les machines virtuelles invité et répondre aux commandes via la console
de gestion généralement tous sans une pénalité de performance.

Indisponibilité CVM
 
Un nœud Nutanix est un hôte physique avec un contrôleur VM (CVM). L'un ou l'autre des
composants peut échouer sans affecter le reste du cluster.
Le cluster Nutanix surveille l'état des CVM dans le cluster. Si un processus Stargate ne
répond pas deux fois ou plus dans une période de 30 secondes, un autre CVM redirige les E /
S de l'hyperviseur sur l'hôte associé vers un autre CVM. Les opérations de lecture et d'écriture
se produisent sur le réseau 10 GbE jusqu'à ce que le Stargate défaillant revienne en ligne.
Pour éviter une commutation constante entre les Stargates, le chemin des données n'est pas
restauré tant que le Stargate d'origine n'a pas été stable pendant 30 secondes

Que remarqueront les utilisateurs?

Au cours du processus de commutation, l'hôte dont le CVM a échoué peut signaler que le
stockage partagé n'est pas disponible. La VM IO invitée peut s'arrêter jusqu'à ce que le
chemin de stockage soit restauré. Bien que la copie principale des données de la machine
virtuelle invitée ne soit pas disponible car elle est stockée sur des disques mappés sur le CVM
en échec, les répliques de ces données sont toujours accessibles.
Dès que la redirection a lieu, les VM reprennent les E / S en lecture et en écriture. Les
performances peuvent légèrement diminuer car les E / S se déplacent sur le réseau plutôt que
sur un bus interne. Étant donné que tout le trafic passe par le réseau 10 GbE, la plupart des
charges de travail ne diminuent pas d'une manière perceptible par les utilisateurs.
Que se passe-t-il si un autre échoue?
Une deuxième défaillance CVM a le même impact sur les machines virtuelles de l'autre hôte,
ce qui signifie que deux hôtes enverront des demandes d'E / S sur le réseau. Le risque
supplémentaire pour les données des VM invitées est plus important. Avec deux CVM
indisponibles, il existe désormais deux ensembles de disques physiques
inaccessibles. Dans un cluster avec un facteur de réplication 2, il est désormais possible que
certaines extensions de données de VM soient complètement manquantes, au moins jusqu'à ce
que l'un des CVM défaillants reprenne l'opération
 
Impact sur les VM
 Événement HA: Aucun
 Échec des opérations d'E / S: aucune
 Latence: potentiellement plus élevée compte tenu des opérations d'E / S
sur le réseau
En cas d'échec du CVM, l'opération d'E / S est transmise à un autre CVM du cluster.
ESXi et Hyper-V gèrent cela via un processus appelé autopathing CVM, qui exploite un
programme Python appelé HA.py (comme «happy»). HA.py modifie la table de routage sur
l'hôte pour transférer le trafic qui va à l'adresse CVM interne (192.168.5.2) vers l'adresse IP
externe d'un autre CVM. Cela permet à la banque de données de rester en ligne - seul le CVM
responsable des opérations d'E / S est distant. Une fois que le CVM local est rétabli et est
stable, la route est supprimée et le CVM local prend en charge toutes les nouvelles opérations
d'E / S.
AHV exploite le multipathing iSCSI, où le chemin principal est le CVM local et les deux
autres chemins sont distants. En cas d'échec du chemin principal, l'un des autres chemins
devient actif. Similaire à l'autopathie avec ESXi et Hyper-V, lorsque le CVM local revient en
ligne, il prend le relais en tant que chemin principal.
Dans le cas où le nœud reste inactif pendant une période prolongée (par exemple, 30 minutes),
le CVM est supprimé de l'anneau de métadonnées. Il est réintégré dans l'anneau après avoir
été en place et stable pendant un certain temps.
 
Indisponibilité du nœud
Curator et Stargate répondent à deux problèmes résultant de la défaillance de l'hôte:

 Lorsque la VM invitée commence à lire sur le réseau, Stargate commence la

migration de ces extensions vers le nouvel hôte. Cela améliore les
performances de la machine virtuelle invitée.
 Curator répond à la panne de l'hôte et du CVM en demandant à Stargate de
créer de nouvelles répliques des données vDisk manquantes.

Que remarqueront les utilisateurs?

Les utilisateurs qui accèdent à des machines virtuelles protégées HA remarqueront que leur
machine virtuelle n'est pas disponible lors du redémarrage sur le nouvel hôte. Sans HA, la
VM doit être redémarrée manuellement.
Et si un autre hôte échoue?
En fonction de la charge de travail du cluster, une deuxième panne d'hôte peut laisser les
hôtes restants avec une puissance de traitement insuffisante pour redémarrer les machines
virtuelles à partir du deuxième hôte. Même dans les clusters peu chargés, le plus gros
problème est le risque supplémentaire pour les données des VM invitées. Par exemple, si un
deuxième hôte / CVM échoue avant que le cluster ne guérisse et que ses disques physiques ne
soient inaccessibles, certaines données de machine virtuelle ne seront pas disponibles.
N'oubliez pas qu'avec le facteur de réplication 2 (RF2, défini au niveau du conteneur de
stockage), il existe deux copies de toutes les données. Si deux nœuds se déconnectent
simultanément, il est possible de perdre les données primaires et répliquées. Si cela n'est pas
acceptable, implémentez le facteur de réplication 3 au niveau du conteneur de stockage ou le
facteur de redondance RF3 qui s'applique au cluster complet.
Dans cette démonstration, vous observerez comment un cluster Nutanix répond et gère les
machines virtuelles invitées lorsqu'un hôte tombe en panne.
 

Indisponibilité du disque
Les lecteurs d'un nœud Nutanix stockent quatre types principaux de données: 
 Données persistantes (niveau chaud et niveau froid)
 Métadonnées de stockage
 Oplog
 Fichiers de démarrage CVM
 
 
 
Les données persistantes de niveau froid sont stockées sur les lecteurs de disque dur
(HDD) du nœud. Les métadonnées de stockage, le journal d'opération, les données
persistantes de niveau chaud et les fichiers de démarrage CVM sont conservés dans le
lecteur à état solide de connexion AT série (SATA-SSD) dans la baie de lecteur
un. Les disques SSD dans un système à double SSD sont utilisés pour les métadonnées
de stockage, le journal d'opération, les données persistantes de niveau chaud en
fonction du facteur de réplication du système. Les fichiers de démarrage CVM et du
système d'exploitation sont stockés sur les deux premiers périphériques SSD dans une
configuration RAID-1 (mise en miroir). Dans les nœuds 100% Flash, les données de
tous types sont stockées dans les SSD SATA.
Sur les plates-formes matérielles qui contiennent des disques SSD (PCIe-SSD) express
d'interconnexion de composants périphériques, le SATA-SSD contient uniquement les fichiers de
démarrage CVM. Les métadonnées de stockage, le journal d'opérations et les données persistantes
de niveau chaud résident sur le PCIe-SSD.
Indisponibilité du disque de démarrage (DOM)
 
 
Lorsqu'un DOM de démarrage (DOM SATA pour matériel NX) échoue, le nœud continuera à
fonctionner normalement tant que l'hyperviseur ou le CVM ne redémarrera pas. Après une
panne du DOM, l'hyperviseur ou CVM sur ce nœud ne pourra plus démarrer car leurs fichiers
de démarrage résident sur le DOM.
 
Le CVM redémarre si un lecteur de démarrage échoue ou si vous supprimez un lecteur de démarrage sans
marquer le lecteur pour la suppression et les données n'ont pas réussi à migrer.
 

Panne du lecteur de métadonnées

Cassandra utilise jusqu'à 4 disques SSD pour stocker la base de données offrant un accès en
lecture et en écriture aux métadonnées du cluster.
En fonction du RF du cluster (2 ou 3), 3 ou 5 copies de chaque élément de métadonnées sont
stockées sur les CVM du cluster.
Lorsqu'un lecteur de métadonnées tombe en panne, le processus Cassandra local ne pourra
plus accéder à sa part de la base de données et commencera un cycle persistant de
redémarrages jusqu'à ce que ses données soient disponibles. Si Cassandra ne peut pas
redémarrer, le processus Stargate sur ce CVM plantera également. L'échec des deux processus
entraîne une redirection d'E / S automatique.
Pendant le processus de commutation, l'hôte avec le SSD défectueux peut signaler que le
stockage partagé n'est pas disponible. La VM IO invitée sur cet hôte s'arrêtera jusqu'à ce que
le chemin de stockage soit restauré.
Une fois la redirection effectuée, les machines virtuelles peuvent reprendre les E / S en lecture
et en écriture. Les performances peuvent diminuer légèrement, car les E / S se déplacent sur le
réseau plutôt que sur le réseau interne. Étant donné que tout le trafic passe par le réseau 10
GbE, la plupart des charges de travail ne diminueront pas d'une manière perceptible par les
utilisateurs.
Plusieurs pannes de disque dans un seul domaine sélectionné (nœud, bloc ou rack) sont
également tolérées.
 
La machine virtuelle du contrôleur redémarre si un lecteur de métadonnées tombe en panne ou si vous
supprimez un lecteur de métadonnées sans marquer le lecteur pour suppression et que les données n'ont pas
réussi à migrer .

Si Cassandra reste dans un état d'échec pendant plus de trente minutes, les nœuds Cassandra
survivants détachent le nœud défaillant de la base de données Cassandra afin que les
métadonnées non disponibles puissent être répliquées sur les nœuds de cluster restants. Le
processus de restauration de la base de données prend environ 30 à 40 minutes.
Si le processus Cassandra redémarre et reste en cours d'exécution pendant cinq minutes, la
procédure de détachement du nœud est annulée. Si le processus reprend et est stable une fois
la procédure de guérison terminée, le nœud sera automatiquement ajouté à l'anneau. Un nœud
peut être ajouté manuellement à la base de données à l'aide de la commande nCLI:
 
ncli > host enable-metadata-store id = cvm_id
  
Panne du lecteur de données
Chaque nœud ajoute ses périphériques de stockage locaux au pool de stockage du cluster. Les
données de niveau froid sont stockées sur des disques durs, tandis que les données de niveau
chaud sont stockées sur des disques SSD pour des performances plus rapides. Les données
sont répliquées à travers le cluster, de sorte qu'une panne de lecteur de données unique
n'entraîne pas de perte de données. Les nœuds contenant uniquement des disques SSD ont
uniquement un niveau chaud.
Lorsqu'un lecteur de données (HDD / SSD) tombe en panne, le cluster reçoit une alerte de
l'hôte et commence immédiatement à créer une deuxième réplique de toutes les données de
machine virtuelle invitée stockées sur le lecteur.
 

Que se passe-t-il si un autre disque tombe en panne?

Dans un cluster avec un facteur de réplication 2, la perte d'un deuxième lecteur dans un
domaine différent (nœud, bloc ou rack) avant que le cluster ne guérisse peut entraîner une
perte de données VM pour les deux réplicas. Bien qu'une panne d'un seul disque n'ait pas le
même impact qu'une panne d'hôte, il est important de remplacer le disque défectueux dès que
possible.
 
Indisponibilité de la liaison réseau
 

 
Les adaptateurs réseau physiques de chaque hôte sont regroupés sur le réseau
externe. L'indisponibilité d'une liaison réseau est tolérée sans impact pour les utilisateurs si
plusieurs ports sont connectés au réseau.
La plate-forme Nutanix n'utilise aucun fond de panier pour la communication entre nœuds. Il
s'appuie sur un réseau 10 GbE standard.
Toutes les E / S de stockage des VM s'exécutant sur un nœud Nutanix sont gérées par
l'hyperviseur sur un réseau privé dédié. La demande d' E / S est gérée par l'hyperviseur, qui
transmet ensuite la demande à l'adresse IP privée sur la CVM locale. Le CVM effectue
ensuite la réplication à distance avec d'autres nœuds Nutanix en utilisant son adresse IP
externe sur le réseau public 10 GbE.
Dans la plupart des cas, les demandes de lecture sont traitées par le nœud local et ne sont pas
acheminées vers le réseau 10 GbE. Cela signifie que le seul trafic acheminé vers le réseau
public 10 GbE est le trafic de réplication de données et les E / S du réseau VM. Les tâches à
l'échelle du cluster, l'équilibrage de disque par exemple, génèrent des E / S sur le réseau 10
GbE.
Que remarqueront les utilisateurs?
Chaque nœud Nutanix est configuré en usine pour utiliser un port 10 GbE comme chemin
principal pour vSwitch0. Les autres ports 10 GbE sont configurés en mode veille. Les
performances de la VM invitée ne diminuent pas dans cette configuration. Si un port 10 GbE
n'est pas configuré comme chemin de basculement, le trafic bascule vers un port 1 GbE. Ce
basculement réduit le débit du trafic de stockage et diminue les performances d'écriture des
machines virtuelles invitées sur l'hôte avec la liaison défaillante. D'autres hôtes peuvent
également subir une légère diminution, mais uniquement sur les écritures dans des étendues
stockées sur l'hôte avec l'échec de la liaison. Les meilleures pratiques de mise en réseau
Nutanix recommandent de supprimer les ports 1 GbE de la configuration réseau de chaque
hôte.
 
Que se passe-t-il si un autre échoue?
Si les deux liaisons 10 GbE sont interrompues, l'hôte basculera vers un port 1 GbE s'il est
configuré en tant qu'interface de veille. Ce basculement réduit le débit du trafic de stockage et
diminue les performances d'écriture des machines virtuelles invitées sur l'hôte avec la liaison
défaillante. D'autres hôtes peuvent également subir une légère diminution, mais uniquement
sur les écritures dans des étendues stockées sur l'hôte avec l'échec de la liaison.
 
Facteur de redondance 3
Par défaut, les clusters Nutanix ont un RF de 2, ce qui tolère la défaillance d'un seul
nœud ou lecteur. Plus le cluster est grand, plus il est probable qu'il subisse des échecs
simultanés. Plusieurs échecs peuvent entraîner l'indisponibilité du cluster jusqu'à ce
que les échecs soient réparés.
Le facteur de redondance 3 (RF3) est une option configurable qui permet à un cluster
Nutanix de résister à la défaillance de deux nœuds ou disques dans différents blocs.
 
 
 
Si un cluster est défini sur RF2, il peut être converti en RF3 si suffisamment de nœuds sont
présents. L'augmentation du niveau RF du cluster consomme 66% du stockage du cluster contre
50% pour RF2.

Fonctionnalités RF3
 Au moins une copie de toutes les données de la VM invitée plus le
journal d'opération est disponible si deux nœuds échouent.
 Les données de machine virtuelle sous-répliquées sont copiées sur
d'autres nœuds.
 Le cluster conserve cinq copies de métadonnées et cinq copies de
données de configuration.
o Si deux nœuds échouent, au moins trois copies sont disponibles.

Exigences RF3
 Un cluster doit avoir au moins cinq nœuds pour que RF3 soit activé.
 Pour que les machines virtuelles invitées tolèrent la défaillance
simultanée de deux nœuds ou disques dans des blocs différents, les données
doivent être stockées sur des conteneurs de stockage avec RF3.
  Le CVM doit être configuré avec suffisamment de mémoire pour
prendre en charge RF3.

Bloquer le placement des données tolérantes aux pannes

  
 
Stargate est responsable du placement des données entre les blocs, et Curator fait des
demandes de placement de données à Stargate pour maintenir la tolérance aux pannes
de bloc.
Les clusters nouveaux et existants peuvent atteindre un état de tolérance aux pannes de
bloc. Les nouveaux clusters peuvent être tolérants aux pannes de bloc immédiatement
après leur création si la configuration le prend en charge. Les clusters existants qui
n'étaient pas auparavant tolérants aux pannes de bloc peuvent être rendus tolérants en
reconfigurant le cluster de manière à prendre en charge la tolérance aux pannes de
bloc.
De nouvelles données dans un cluster à tolérance de panne de bloc sont placées pour
maintenir la tolérance de panne de bloc. Les données existantes qui n'étaient pas dans
un état de tolérance de panne de bloc sont déplacées et analysées par Curator vers un
état de tolérance de panne de bloc.
Selon le volume de données à déplacer, Curator peut nécessiter plusieurs analyses sur
une période de plusieurs heures pour répartir les données entre les blocs.
 
ock le placement des données tolérantes aux pannes est effectué au mieux mais n'est
pas garanti. Des conditions telles qu'une utilisation élevée du disque entre les blocs
peuvent empêcher le cluster de placer des données de copie redondantes de VM invitée
sur d'autres blocs.
Des copies redondantes des données de la VM invitée sont écrites sur les nœuds dans
des blocs autres que le bloc qui contient le nœud sur lequel la VM s'exécute. Le cluster
conserve deux copies de chaque écriture stockées dans l'oplog.
Le composant Nutanix Medusa utilise Cassandra pour stocker les
métadonnées. Cassandra utilise une structure en forme d'anneau où les données sont
copiées vers des pairs au sein de l'anneau pour assurer la cohérence et la disponibilité
des données. Le cluster conserve au moins trois copies redondantes des métadonnées,
dont au moins la moitié doit être disponible pour garantir la cohérence.
Avec la tolérance aux pannes de bloc, les pairs Cassandra sont répartis entre les blocs
pour garantir qu'il n'y a pas deux pairs sur le même bloc. En cas d'échec d'un bloc, au
moins deux copies des métadonnées sont présentes dans le cluster.
 
Tolérance aux pannes du rack
 
 La tolérance aux pannes du rack est la capacité de fournir un domaine de disponibilité
au niveau du rack. Avec la tolérance aux pannes du rack, des copies redondantes des
données sont effectuées et placées sur les nœuds qui ne sont pas dans le même rack.
Une défaillance du rack peut se produire dans les situations suivantes:
 Tous les blocs d'alimentation échouent dans un rack
 Le commutateur TOR (Top-of-Rack) échoue
 Partition réseau; où l'un des racks devient inaccessible depuis les autres racks
Lorsque la tolérance aux pannes de rack est activée et que les machines virtuelles
invitées peuvent continuer à fonctionner en cas de défaillance d'un rack (RF2) ou de
deux racks (RF3). Les copies redondantes des données et métadonnées de la VM
invitée existent sur d'autres racks lorsqu'un rack tombe en panne.

Nombre Nombre Nombre

Domaine Facteur de Résilience des
minimum de minimum de minimum de
d'erreur réplication données
nœuds blocs racks
1 nœud ou 1 bloc
2 3 3 3* ou 1 rack ou 1
disque
Grille
2 nœuds ou 2
3 5 5 5* blocs ou 2 racks
ou 2 disques

 
 
* Codage d'effacement avec prise en compte du rack - Le codage d'effacement est pris en charge sur un
cluster compatible rack. Vous pouvez activer le codage d'effacement sur les nouveaux conteneurs dans les
clusters prenant en charge les racks à condition que certains minimums soient respectés, comme indiqué
dans le tableau ci-dessus. 
Le tableau indique le niveau de résilience des données (échec simultané) fourni pour les
combinaisons suivantes de facteur de réplication, nombre minimum de nœuds, nombre
minimum de blocs et nombre minimum de racks.
 
La tolérance aux pannes de rack est uniquement prise en charge pour AHV et ESXi.

Haute disponibilité VM
Dans les clusters gérés Acropolis, vous pouvez activer la haute disponibilité (HA) pour
le cluster afin de garantir que les machines virtuelles peuvent être migrées et
redémarrées sur un autre hôte en cas de panne.
  

HA peut garantir que des ressources de cluster suffisantes sont disponibles pour
prendre en charge la migration des machines virtuelles en cas de défaillance du nœud.
Acropolis Master suit la santé des nœuds en surveillant les connexions sur tous les
nœuds du cluster. Lorsqu'un nœud devient indisponible, Acropolis Master redémarre
toutes les machines virtuelles qui s'exécutaient sur ce nœud sur un autre nœud du
même cluster.
L'Acropolis Master détecte les pannes dues à l'isolation du réseau VM, qui est signalée
par une incapacité à répondre aux pulsations.
 
Options de configuration HA
Il existe trois options de configuration HA du cluster AHV. Cliquez sur chaque onglet pour en
savoir plus.
 
Segments réservés
Sur chaque nœud, une partie de la mémoire est réservée dans le cluster pour le basculement
des machines virtuelles à partir d'un nœud défaillant. Le service Acropolis du cluster calcule
la mémoire à réserver dans le cluster en fonction de la configuration de la mémoire de la
machine virtuelle. AHV marque tous les nœuds comme programmables et les ressources
disponibles pour exécuter des machines virtuelles.
 
Meilleur effort
Non recommandé. Aucune réservation de nœud ou de mémoire sur le nœud n'est effectuée
dans le cluster et en cas de panne, les machines virtuelles sont déplacées vers d'autres nœuds
en fonction des ressources et de la mémoire disponibles sur le nœud. Ce n'est pas une
méthode préférée. S'il n'y a pas de ressources disponibles sur le cluster ou le nœud, certaines
des machines virtuelles peuvent ne pas être sous tension.
 
Hôte réservé
Uniquement disponible via aCLI et non recommandé. Un nœud complet est réservé à la haute
disponibilité de la machine virtuelle en cas de défaillance d'un nœud dans le cluster et ne
permet pas aux machines virtuelles d'être exécutées et mises sous tension ou migrées vers le
nœud pendant le fonctionnement normal du cluster. Ce mode ne fonctionne que si tous les
nœuds du cluster ont la même quantité de mémoire.
 
Mode flash
Le mode Flash pour les VM et les groupes de volumes (VG) est une fonctionnalité qui permet à un
administrateur de définir la préférence de niveau de stockage pour une VM ou VG qui peut exécuter
des applications critiques sensibles à la latence.
Par exemple, un cluster exécutant des applications critiques (telles que la base de données
SQL) avec un ensemble de travail volumineux aux côtés d'autres charges de travail peut être
trop volumineux pour s'adapter au niveau SSD et pourrait potentiellement migrer vers le
niveau HDD. Pour les charges de travail extrêmement sensibles à la latence, la migration vers
le niveau HDD peut sérieusement affecter les performances de lecture et d'écriture de la
charge de travail.
Le mode Flash est disponible pour toutes les machines virtuelles et VG exécutant AHV, ESXi
et Hyper-V. Vous devez gérer les hôtes ESXi à l'aide de vCenter Server. Hyper-V prend en
charge le mode Flash pour les VG. Vous activez la fonctionnalité sur un niveau par VM ou
par VG, et tous les disques virtuels correspondant à la VM ou VG activée sont également
activés pour le mode Flash. Vous pouvez désactiver un disque virtuel individuel lorsque vous
activez la VM ou VG à laquelle il correspond pour le mode Flash.
Vous pouvez configurer le mode Flash pour les machines virtuelles nouvelles ou existantes,
les VG et leurs disques virtuels associés. Lorsque vous ajoutez un nouveau disque virtuel à
une VM ou VG activée en mode Flash, vous épinglez également ce disque virtuel au SSD.
L'activation du mode Flash sur une VM ou VG ne migre pas automatiquement ses données du
niveau froid vers le niveau chaud. Le mécanisme de gestion du cycle de vie des informations
(ILM) gère la migration des données à chaud. Cependant, une fois que le mode Flash est
activé pour une machine virtuelle dans un système hybride, les données des données
d'application critiques pour l'entreprise et sensibles à la latence ne migrent pas du SSD vers le
disque dur.
Le mode Flash offre des performances 100% Flash pour des charges de travail spécifiques sur
votre infrastructure hybride existante sans que vous ayez à acheter un système 100% Flash.
  
 
 
Par défaut, vous pouvez utiliser 25% du niveau SSD de l'ensemble du cluster comme mode
Flash pour les VM ou VG.
Si la quantité de données de VM épinglées sur SSD dépasse 25% de la capacité SSD du
cluster, le système peut migrer les données des vDisks épinglés vers le disque dur, en fonction
de l'utilisation du niveau chaud. Prism alerte lorsque ce seuil est dépassé. Lorsque cela se
produit, vous devez évaluer l'utilisation du niveau actif du cluster. Réduisez la quantité de
données épinglées au SSD ou ajoutez une capacité supplémentaire de niveau chaud au cluster.
Si cette fonctionnalité est activée pour une machine virtuelle, tous les disques virtuels qui sont
attachés à la machine virtuelle sont automatiquement épinglés au niveau SSD. En outre, tous
les disques virtuels ajoutés à cette machine virtuelle après la configuration du mode Flash sont
automatiquement épinglés. Cependant, la configuration d'une VM peut être modifiée pour
supprimer le mode Flash de tous les disques virtuels. «L'épinglage de VM» est une
fonctionnalité disponible pour les machines virtuelles et les groupes de volumes.
 
Avant d'utiliser le mode Flash, utilisez au maximum les fonctionnalités d'optimisation de la capacité telles que la
déduplication, la compression et le codage d'effacement (EC-X).
 

Considérations relatives au mode Flash VM

 
Le mode VM Flash est recommandé uniquement pour les applications hautes performances sensibles à la
latence. VM mode Flash réduit la capacité du FSN à gérer les charges de travail d' une manière
dynamique. Utilisez-le en dernier recours uniquement.
 

Utiliser le mode VM Flash pour les applications sensibles à

la latence
 Utilisez le mode VM Flash pour les charges de travail qui s'exécutent
selon une planification qui lance la migration des données vers le niveau
froid entre les travaux. 
 Activez le disque virtuel entier si possible.
 Lorsque vous utilisez le mode VM Flash pour placer une partie du
disque virtuel dans le niveau chaud, les données que vous souhaitez
 conserver peuvent migrer vers le niveau froid. Cela se produit lorsque
d'autres données non critiques sont écrites sur le disque virtuel et utilisent
l'espace de niveau actif.
 Activer pour les charges de travail lourdes en lecture.

Configuration du mode Flash

Vérification des paramètres du mode Flash à l'aide de Prism:
 

 
 
Le mode Flash est configuré lorsque vous mettez à jour la configuration de la VM. En
plus de modifier la configuration, vous pouvez attacher un groupe de volumes à la VM
et activer le mode flash sur la VM. Si vous attachez un groupe de volumes à une
machine virtuelle qui fait partie d'un domaine de protection, la machine virtuelle n'est
pas protégée automatiquement. Ajoutez manuellement la machine virtuelle au même
groupe de cohérence.
Pour activer le mode flash sur la VM, cochez la case Activer le mode Flash .  
Une fois que vous avez activé cette fonctionnalité sur la machine virtuelle, l'état est
mis à jour dans la vue de la table de la machine virtuelle. Pour afficher l'état des
disques virtuels individuels (disques qui sont flashés sur le SSD), accédez à
l' onglet Disques virtuels dans la vue de table VM .    
Vous pouvez désactiver la fonction de mode flash pour des disques virtuels
individuels. Pour mettre à jour le mode flash pour des disques virtuels individuels,
cliquez sur l'icône de mise à jour du disque dans le volet Disques et décochez la case
Activer le mode Flash .    
 
Politiques d'affinité pour AHV
 
 
Vous pouvez spécifier des politiques de planification pour les machines virtuelles sur un
cluster AHV. En définissant ces stratégies, vous pouvez contrôler le placement des machines
virtuelles sur les hôtes au sein d'un cluster.

Vous pouvez définir deux types de stratégies d'affinité:

 Stratégie d'anti-affinité VM-VM
 Stratégie d'affinité VM-hôte

Stratégie anti-affinité de VM
Cette stratégie empêche les machines virtuelles de s'exécuter sur le même nœud. La stratégie
force les machines virtuelles à s'exécuter sur des nœuds distincts afin que la disponibilité des
applications ne soit pas affectée par une défaillance de nœud. Cette politique ne limite pas la
fonction de planification dynamique d'Acropolis (ADS) à prendre les mesures nécessaires en
cas de contraintes de ressources.
 
Actuellement, vous ne pouvez définir la stratégie anti-affinité VM-VM qu'en utilisant aCLI. Pour plus
d'informations, consultez Configuration de la stratégie d'anti-affinité VM-VM . 
 
La stratégie Anti-Affinity est appliquée lors du placement initial des VM (lorsqu'une VM est sous tension). La
stratégie anti-affinité peut être annulée en migrant manuellement une machine virtuelle vers le même hôte que sa
machine virtuelle opposée, lorsqu'un hôte est mis en mode de maintenance ou pendant un événement HA. ADS
tentera de résoudre toutes les violations d'anti-affinité lorsqu'elles seront détectées.
 
La stratégie d'affinité VM-VM n'est pas prise en charge.
 
Politique d'affinité VM-hôte
La stratégie d'affinité VM-hôte contrôle le placement des VM. Utilisez cette stratégie pour
spécifier qu'une machine virtuelle sélectionnée ne peut s'exécuter que sur les membres de la
liste d'hôtes d'affinité. Cette stratégie vérifie et applique où une machine virtuelle peut être
hébergée lorsque vous mettez sous tension ou migrez la machine virtuelle.
 
Si vous choisissez d'appliquer une politique d'affinité VM-hôte, cela limite Acropolis HA et Acropolis Dynamic
Scheduling (ADS) de telle sorte qu'une machine virtuelle ne peut pas être mise sous tension ou migrée vers un
hôte qui n'est pas conforme aux exigences de la politique d'affinité car cette politique est obligatoirement
appliquée.
 
La stratégie d'anti-affinité de l'hôte VM n'est pas prise en charge.
 
Sélectionnez au moins deux hôtes lors de la création d' une liste d'affinité d'hôte pour vous protéger contre les
temps d'arrêt en cas de défaillance d'un nœud. Cette configuration est toujours appliquée; Les VM ne seront pas
déplacées des hôtes spécifiés ici, même dans le cas d'un événement HA.
 
Regardez la vidéo suivante pour en savoir plus sur les règles d'affinité
Nutanix: https://youtu.be/ rfHR93RFuuU . 
Limitations des règles d'affinité
 Même si un hôte est supprimé d'un cluster, l'UUID de l'hôte n'est pas
supprimé de la liste d'affinité d'hôte pour une machine virtuelle. Vérifiez et
mettez à jour les règles d'affinité d'hôte chaque fois qu'un nœud est
supprimé d' un cluster.
 L'affinité VM-hôte ne peut pas être configurée sur un cluster dont la
haute disponibilité est configurée à l'aide de la méthode d'hôte réservé.
 Vous ne pouvez pas supprimer l'affinité VM-hôte pour une VM sous
tension de Prism. Vous pouvez utiliser la commande vm.affinity_unset
vm_list aCLI pour effectuer cette opération.