vSan – Stratégie de résilience – part 3

La résilience des objets dans un cluster Standard ou Streched Cluster vSan est assurée par la politique FTT <NumberOfFailuresToTolerate> appliqué aux objets et par la définition de FD <Fault Domain>. Pour assurer cette résilience, un cluster vSan requière un minimum de 3 hôtes mais 4 hôtes minimum sont conseillés afin d’assurer la protection des données lors d’une panne pendant la maintenance d’un hôte.

FTT <NumberOfFailuresToTolerate>, est une politique de tolérance de panne appliquée aux objets VMs ou individuellement aux disques virtuels des VMs. Cette politique définit le nombre de pannes d’hôte qu’un objet de VM peut tolérer. Pour N échecs tolérés, chaque donnée écrite est stockée sur le stockage de N+1 hôtes. Cela permet de s’assurer qu’une réplique de l’objet est créée sur les disques d’un autre hôte du cluster vSan. La mise en place de cette politique multiplie par N (2, 3 ou 4) l’espace consommé sur le cluster vSan. En streched cluster, cette politique est limitée à 1.

  • Exemple d’un cluster vSan standard composé de 4 hôtes :

Policy en FTT=1 sur les objets.

2 objets sont créés dans le cluster (VMDK0 et VMDK1)
1 réplica de l’objet sur un hôte A (VMDK0)
1 réplica de l’objet sur un hôte B (VMDK0’)
1 objet témoin joue le rôle de quorum sur un hôte C (WITNESS0)
1 réplica de l’objet sur un hôte A (VMDK1)
1 réplica de l’objet sur un hôte B (VMDK1’)
1 objet témoin joue le rôle de quorum sur un hôte D (WITNESS1)

ftt vsan

Un Streched Cluster vSan, permet de pallier non seulement à la perte d’un hôte mais aussi à la perte d’un site complet. La mise en place de FD <Fault Domain> est obligatoire. Cette fonctionnalité, va définir des domaines de panne par rack ou par site en plaçant les données sur 2 fault domain différents. En streched cluster cette politique est limitée à 3.

  • Exemple d’un cluster vSan en Streched Cluster composé de 8 hôtes + 1 hôte witness :

Policy en FTT=1 sur les objets et 3 FD.

2 objets sont créés dans le Streched Cluster vSan

1 réplica de l’objet sur un hôte A (VMDK0)
1 réplica de l’objet sur un hôte E (VMDK0’)
1 objet témoin joue le rôle de quorum sur un hôte W (WITNESS0)
1 réplica de l’objet sur un hôte D (VMDK1)
1 réplica de l’objet sur un hôte F (VMDK1’)
1 objet témoin joue le rôle de quorum sur un hôte W (WITNESS1)

streched cluster vsan

La politique SW <NumberOfDiskStripesPerObject> est le nombre minimal de disques capacitifs sur lesquels chaque réplica d’un objet de machine virtuelle est agrégé. Une valeur supérieure à 1 peut dans certains cas d’améliorer la performance des VMs. En effet, cette politique force le découpage des objets et réplicas d’objet inférieur à 255GB en plusieurs composants (stripes). Un objet de VM pourra ainsi profiter dans le meilleur des cas de plusieurs disques de cache et/ou capacitif différents pour effectuer ses lectures et écritures. L’algorithme de vSan ne garantit pas le placement des composants sur des disk groups d’hôtes différents. Il est à noter qu’en mode streched cluster les réplicas des composants d’objet créés par la politique de FTT sur le site n’exécutant pas la VM ne sont pas exploités en lecture car l’algorithme de vSan utilise la « Read Data Locality ».

  • Exemple d’un cluster vSan en Streched Cluster composé de 8 hôtes + 1 hôte witness :

Policy en FTT=1, SW=2 sur les objets et FD=3.

2 objets sont créés dans le Streched Cluster vSan et chaque objet découpé en 2 composants (stripes)
1 stripe du réplica de l’objet sur un hôte A (VMDK0)
1 stripe du réplica de l’objet sur un hôte B (VMDK0)
1 stripe du réplica de l’objet sur un hôte E (VMDK0’)
1 stripe du réplica de l’objet sur un hôte G (VMDK0’)
1 objet témoin joue le rôle de quorum sur un hôte W (WITNESS0)
1 stripe du réplica de l’objet sur un hôte D (VMDK1)
1 stripe du réplica de l’objet sur un hôte D (VMDK1)
1 stripe du réplica de l’objet sur un hôte F (VMDK1’)
1 stripe du réplica de l’objet sur un hôte G (VMDK1’)
1 objet témoin joue le rôle de quorum sur un hôte W (WITNESS1)

fault domain

En cas de non-conformité du cluster avec les stratégies de stockage définies, soit par manque de capacité, soit par une panne et/ou maintenance, le provisionnement d’une VM ne sera autorisé qu’en mode <force provisionning>. Cette option nécessite la confirmation de l’utilisateur et autorise vSan à outrepasser les règles de FTT et SW appliquées. Il faut bien prendre en considération que vSan ne tente pas d’appliquer des règles d’exigences réduites en cas de <force provisionning>, mais provisionne la VM sans réplica en FTT=0 (RAID 0) et SW=1. Dès que des ressources sont à nouveau disponibles (ajout d’un hôte ou de nouveaux disques), vSan consomme les nouvelles ressources pour satisfaire les stratégies de FTT et SW.

twitterlinkedin
Tagués avec : , , , , , , , ,
Un commentaire sur “vSan – Stratégie de résilience – part 3
  1. adam dit :

    Merci très instructif

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*