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.

Lire la suite ›

Nous avons vu dans les articles précédents comment vSan gère les lectures et écritures dans un mode standard. Ici, nous aborderons les particularités de vSan en mode Streched Cluster.

Contrairement au mode vSan classique, en mode Streched Cluster, vSan utilise un algorithme lui permettant d’effectuer ses lectures sur le site qui exécute la VM et cela dans les deux versions (Hybrid / All Flash). En streched cluster, chaque site représente un domaine de panne (FD = Fault Domain) et les hôtes ESXi de chaque site doivent être ajoutés dans un Fault Domain. La définition des Fault Domain permet à chaque objet provisionné d’avoir son réplica dans un Fault Domain différent et donc un site différent. Cet algorithme permet d’éviter la répartition des lectures en Round Robin sur les deux sites comme en vSan non Streched. En Streched, vSan utilise volontairement de la Read Locality afin d’éviter les latences pouvant être engendrées par le lien inter-sites. En cas de migration de VM par vMotion entre les hôtes ESXi du cluster d’un même site, le cache n’est pas reconstruit sur l’hôte qui exécute la VM (même principe que vSan non streched). Par contre, en cas de migration d’une VM sur un hôte du cluster du site distant, le cache est reconstruit sur les SSD des hôtes du 2^nd Fault Domain et la Read Locality s’applique à nouveau.

Lire la suite ›

La gestion des écritures dans vSan en version Hybrid et All Flash.

Comme nous l’avons vu dans l’article précèdent, en version Hybrid, vSan possède 1 disque SSD dédié par disk group. vSan utilise 30% de ce disque comme cache en écriture.

En version All Flash, vSan utilise 100% de la capacité d’un disque SSD ‘Write intensive’ dédié par disk group comme cache en écriture avant le destaging sur les disques capacitifs (SSD).

En version Hybrid, les 30% du disque de cache SSD dans un disk group est principalement utilisé comme buffer en écriture afin d’accélérer le traitement des I/O. En effet, cela permet un acquittement (Ack) bien plus rapide des opérations et évite ainsi les latences d’écriture.

En version All Flash, le disque de cache SSD par disk group est principalement utilisé pour prolonger la durée de vie des disques capacitifs SSD. Les disques utilisés pour le cache supportent des écritures intensives et ont une durée de vie bien plus longue exprimée en TBW (Terabytes Written) par VMware ou en DWDP (Drive Writes Per Day) par les constructeurs.

En vSan 6 (Hybrid ou All Flash), la taille maximale des disques de cache utilisés dans les disk group est de 600GB.

Lire la suite ›