Dans cet article, nous aborderons plusieurs cas de panne vSan en configuration FTT1 mais le principe reste le même en FTT2/FTT3, si ce n’est que nous aurons plus de réplica d’objet et que cela nécessitera un nombre d’hôte minimum afin de garantir la résilience des objets. Cela nous permettra de démontrer l’avantage du FTT2/FTT3 😉

vSan connaît deux types d’évènement lors d’une panne :

• Absent : vSan considère que la donnée (objet) est perdue de façon permanente et qu’elle ne reviendra pas. Il n’y donc aucune raison d’attendre et une récupération immédiate des données (objets) est initiée par vSan. Il n’est pas possible de configurer ce timer.
• Degraded : vSan considère que la donnée est temporairement indisponible. Il considère que l’évènement responsable de cette indisponibilité requière le déclenchement d’un timer de 60 minutes avant de lancer des opérations de récupération des données (objets). Ce timer est configurable dans les paramètres avancés des hôtes « ClomRepairDelay ».

Ne pas oublier qu’en mode vSan (non streched), les lectures sont effectuées en round-robin sur les objets sources et réplicas du cluster par blocs de 1Mo.

Cas de panne d’un hôte sur le cluster n’exécutant pas de VM:

La VM s’exécute sur l’hôte A du cluster. La VM possède 2 objets VMDK0 et VMDK1. Les deux objets sont configurés avec un SW=2 qui divise chaque objet en deux composants d’objet. Les composants d’objet sont repartis sur des disques différents.

Si l’un des hôtes du cluster tombe en panne (exemple hôte G), la VM n’est pas impactée car un réplica des objets (VMDK0 et VMDK1) reste disponible sur le stockage des autres hôtes. Nous avons donc plus de 50% des composants ou votes de composant disponibles (1). La perte d’un composant d’objet équivaut à la perte de l’objet complet (RAID 0).

Lors de la panne d’un hôte, VSAN Health Check affichera une erreur de type « absent » due à l’absence de l’hôte et initiera une minuterie de 60 minutes.

• Si les objets hébergés sur le stockage de l’hôte en panne reviennent en ligne dans les 60 minutes, vSan resynchronise les objets sources depuis les objets réplica.
  
• Si les objets ne reviennent pas en ligne dans les 60 minutes, vSan créé de nouveaux réplicas d’objets sur le cluster, puis supprime les anciens après avoir terminé sa création.
  

  (vSan ne supprimera les composants VMDK0′ et VMDK1′ qu’après la reconstruction complète des réplicas manquants)
  

• Si les objets reviennent en ligne peu après les 60 minutes et que vSan est en cours de création des nouveaux réplicas d’objet, vSan évalue s’il est préférable de synchroniser les objets existants (non à jour) ou poursuivre la création des nouveaux objets puis supprimer les anciens.
  

(1) : En version 5.5, vSan se base sur un % de composant présent ou chaque composant équivaut à un vote et se charge d’ajouter des composants witness pour égaliser les votes. A partir de la version 6.0, chaque composant possède un vote et vSan se charge d’augmenter le poids des votes pour certains composants afin d’égaliser les votes. (Nous étudierons cette notion de % de vote et de % de composant disponible dans un futur article)

Cas de panne d’un hôte exécutant la VM :

La VM s’exécute sur un des hôtes du cluster (exemple : ESXi A). Si cet hôte tombe en panne, le mécanisme de vSphere HA redémarre la VM sur un autre hôte du cluster (exemple : ESXi B).

Si les objets de la VM ne sont pas sur le stockage de l’hôte impacté, lors du redémarrage sur un autre hôte ESXi du cluster, la VM verra toujours 100% de ses objets et effectuera ses lectures sur le stockage des autres hôtes hébergeant les objets et les réplicas d’objets.

Si des objets de la VM sont hébergés sur le stockage de l’hôte impacté, la VM ne voit plus 100% des composants ou votes de son objet (VMDK0) mais au moins 50% (VMDK0′). La VM est démarrée sur un autre hôte ESXi du cluster (ESXi B) et effectue ses lectures sur le stockage des hôtes hébergeant les réplicas d’objets restant (ESXi E et G). (À noter que la perte d’un composant d’objet revient à perdre complètement l’objet).

Lors de la panne d’un hôte, VSAN Health Check affichera une erreur de type « absent » due à l’absence de l’hôte et initiera une minuterie de 60 minutes.

• Si les objets hébergés sur le stockage de l’hôte en panne reviennent en ligne dans les 60 minutes, vSan resynchronise les objets sources depuis les objets réplica.
  
• Si les objets ne reviennent pas en ligne dans les 60 minutes, vSan créé de nouveaux réplicas d’objets sur le cluster, puis supprime les anciens après avoir terminé sa création.
  

  (vSan ne supprimera le composant VMDK0 qu’après la reconstruction complète de celui-ci)
  

• Si les objets reviennent en ligne peu après les 60 minutes et que vSan est en cours de création des nouveaux réplicas d’objet, vSan évalue s’il est préférable de synchroniser les objets existants (non à jour) ou poursuivre la création des nouveaux objets puis supprimer les anciens.
  

Pendant la panne, certains objets n’étant plus présents, vSan Health Check affiche une erreur de type « absent ». Une fois l’hôte rétabli, vSan Health Check vérifie qu’il n’y a plus d’absence d’objets de VM et que tous sont de nouveau actifs.

Pendant la panne de l’hôte et avant la fin de la reconstruction des objets (60min + temps de reconstruction), les objets réplica du cluster sont en FTT0 et donc non protégé !

Je vous vois venir en criant au secours ! (Et oui, Au même titre qu’un RAID 1 qui perd un disque et qui n’est pas remplacé). Il va falloir prendre l’habitude de résoudre les pannes rapidement ;-p

Non plus sérieusement, dans ce cas, il faut plutôt envisager du FTT2 ou FTT3 J

Cas d’isolation réseau d’un hôte du cluster :

Lors d’une isolation réseau d’un hôte du cluster. (Exemple : panne des cartes réseaux, problème de câble réseau, erreur de configuration sur switch, etc …)

L’hôte en question n’est plus en mesure d’établir de communication avec les hôtes du cluster.

• vSphere HA va détecter qu’il n’y a plus d’échange heartbeat venant de l’hôte en panne.
• L’hôte avec le rôle master HA, va essayer de joindre l’hôte en panne sans succès.
• vSphere HA, va déclarer l’hôte comme indisponible.
• En vSan les agents HA « FDM » dialoguent sur le réseau vSan et l’adresse d’isolation doit être configurée sur le réseau vSan (exemple : gateway vsan). Cela permet d’avoir une vue unique permettant de déclencher l’isolation et non un split brain.
• Les VMs vont redémarrées sur les autres hôtes en fonction de la policy d’isolation configurée.

Le résultat va être le même qu’en cas de panne d’un hôte exécutant la VM (voir cas précédent)

Pendant l’isolation d’un hôte, VSAN Health Check affichera une erreur de type « absent » due à l’absence de l’hôte et initiera une minuterie de 60 minutes.

• Si les objets hébergés sur le stockage de l’hôte isolé reviennent en ligne dans les 60 minutes, vSan resynchronise les objets source depuis les objets réplica.
  
• Si les objets ne reviennent pas en ligne dans les 60 minutes, vSan créé de nouveaux réplicas d’objets sur le cluster, puis supprime les anciens après avoir terminé sa création.
  

  (vSan ne supprimera le composant VMDK0 qu’après la reconstruction complète de celui-ci)
  

• Si les objets reviennent en ligne peu après les 60 minutes et que vSan est en cours de création des nouveaux réplicas d’objet, vSan évalue s’il est préférable de synchroniser les objets existants (non à jour) ou poursuivre la création des nouveaux objets puis supprimer les anciens.
  

Pendant l’isolation réseau, certains objets n’étant plus présents, vSan Health Check affiche une erreur de type « absent ». Une fois l’hôte rétabli, vSan Health Check vérifie qu’il n’y a plus d’absence d’objets de VM et que tous sont de nouveau actifs.

Pendant l’isolation de l’hôte et avant la fin de la reconstruction des objets (60min + temps de reconstruction), les objets réplica du cluster sont en FTT0 et donc non protégé.

Dans ce cas, il faut taper sur l’équipe réseau qui a encore appliqué une conf de vlan sur le mauvais port du switch :-p. Non ! Comme pour la perte d’un hôte, il faut envisager du FTT2 ou FTT3 J

Panne d’un disque capacitif sur un hôte du cluster :

Lors d’une panne de disque, vSan place les composants impactés en mode « degraded » et reconstruit immédiatement une copie des composants en vérifiant qu’il y a bien les ressources stockage nécessaires. Si le disque en panne comporte des composants d’objet de VM, il n’y a pas de migration de VM sur un autre hôte, les lectures sont effectuées sur les composants présents sur le stockage des autres hôtes jusqu’à la reconstruction des données.

Attention, en configuration All-Flash, si vous activez la déduplication & compression la perte d’un disque capacitif revient à perdre le « disk group » complet.

Je vous vois revenir en criant au secours ! (Encore une fois, au même titre qu’un RAID 1 qui perd un disque et qui n’est pas remplacé). Quoi ! Cette fois vous voulez laisser un disque en spare sur chaque Disk Group ? 😉

Non plus sérieusement, dans ce cas, il faut plutôt envisager du FTT2 ou FTT3 J

Panne d’un disque flash sur un hôte du site:

Lors d’une panne de disque de cache SSD, vSan place les composants du disk group complet en mode « degraded » et reconstruit immédiatement les objets depuis les réplicas en vérifiant qu’il y a bien les ressources nécessaires. Si le disk group en panne comporte des composants d’objet de VM, il n’y a pas de migration de VM sur un autre hôte, les lectures sont effectuées sur les composants présents sur le stockage des autres hôtes jusqu’à la reconstruction des données. Les performances en lecture pendant la reconstruction de l’objet peuvent être dégradées car certaines données présentes dans le cache du disk group en panne ne sont plus visibles et nécessitent de remonter en cache sur les autres hôtes. Une fois les composants ou objets reconstruit, les VM pourront de nouveau s’appuyer sur le cache de l’hôte impacté.

Cas d’un split-brain dans le cluster vSan:

Nous aborderons ce sujet dans un prochain article ou nous expliquerons les différents mécanismes mis en œuvre par vSan en Streched Cluster et non Streched.

Que se passe-t-il lorsqu’une panne engendre une non-conformité du cluster avec la politique de résilience appliquée FTT/SW ?

En cas de non-conformité du cluster avec la politique de résilience de panne configurée, soit par manque de ressources, soit suite à une panne et/ou une maintenance, le provisionnement d’une nouvelle VM ne sera autorisé qu’en mode « force provisionning ». Cette option autorise vSan à outrepasser les règles de FTT et SW configurées. Il faut bien prendre en considération que vSan ne tentera pas d’appliquer des règles d’exigences réduites en cas de « force provisionning », mais provisionnera la VM sans réplica en FTT=0 (RAID 0) et SW=1. Dès que les ressources seront de nouveau disponibles (ajout d’un hôte, ajout de nouveaux disques, réparation d’un hôte ou d’un disk group), vSan consommera les nouvelles ressources pour satisfaire sa politique de FTT.