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.

VMware part du principe que les VMs sont fréquemment déplacées par des mécanismes de rééquilibrage comme DRS et que la pénalité provoquée par la traversée du lien inter-sites peut engendrer des latences en lecture. Par ailleurs, VMware recommande la mise en place de groupes d’affinités DRS afin d’éviter que les VM exécutées sur des hôtes ESXi du Site A (FD1) et dont les caches sont alimentés migrent sur des hôtes du site B (FD2) dont les caches ne sont pas alimentés. La Read Locality ainsi que les règles d’affinités DRS en mode Streched sont là pour pallier aux nombreuses reconstructions des caches.

Note : Nous aborderons le Witness Site et son utilité dans un autre article dédié à la particularité du Streched Cluster.

Lecture d’un bloc de donnée en cache en mode Streched Cluster:

La VM s’exécute sur l’hôte ESXi A du Prefered-Site.

La politique Number Of Failures To Tolerate est configurée 1

Les hôtes ESXi sont intégrés dans des Fault Domain FD1, FD2 et FD3

FD1 = Prefered Site, FD2 = Secondary Site et FD3 = Witness Site.

Les hôtes ESXi A, B, C, D dans FD1, les hôtes ESXi E, F, G, H dans FD2 et l’hôte témoin ESXi W dans FD3

ESXi A est propriétaire de l’objet VMDK1.

ESXi E est propriétaire de l’objet réplica VMDK1′.

1. La VM effectue la lecture d’un bloc de données dans son VMDK1.
2. vSan utilise la Read Locality et vérifie la présence en cache du bloc demandé sur l’un des hôtes ESXi du cluster dans le Prefered-site possédant l’objet VMDK1.
3. Le bloc est trouvé dans le cache de l’hôte A. L’opération de lecture ne traverse pas le réseau et s’effectue localement sur l’un des disk group de l’hôte ESXi A par l’intermédiaire de sa carte contrôleur interne.
4. vSan effectue la lecture sur le disque de cache SSD du Disk Group 2 de l’hôte ESXi A
5. L’information est remontée à la VM

Lecture d’un bloc de données non en cache en mode Streched Cluster:

La VM s’exécute sur l’hôte ESXi A du Prefered-Site.

La politique Number Of Failures To Tolerate est configurée 1

Les hôtes ESXi sont intégrés dans des Fault Domain FD1, FD2 et FD3

FD1 = Prefered Site, FD2 = Secondary Site et FD3 = Witness Site.

Les hôtes ESXi A, B, C, D dans FD1, les hôtes ESXi E, F, G, H dans FD2 et l’hôte témoin ESXi W dans FD3

ESXi A est propriétaire de l’objet VMDK1.

ESXi E est propriétaire de l’objet réplica VMDK1′.

1. La VM effectue la lecture d’un bloc de données dans son VMDK1.
2. vSan utilise la Read Locality et vérifie la présence en cache du bloc demandé sur l’un des hôtes ESXi du cluster dans le Prefered-site possédant l’objet VMDK1.
3. Le bloc de données demandé n’est pas trouvé en cache. vSan effectue ses lectures sur les disques capacitifs. Dans notre cas l’hôte A.
4. Le bloc de données non présent en cache sur l’hôte A, vSan va effectuer la lecture sur les disques capacitifs du disk group 2 de l’hôte A via sa la carte contrôleur interne sans traverser le réseau.
5. Le bloc de données va être placé dans le disque de cache SSD du Disk Group2 de l’hôte ESXi A.
6. L’information est remontée à la VM

Lecture d’un bloc de données en cache après vMotion de la VM en mode Streched Cluster:

La VM est déplacée par un vMotion de l’hôte ESXi A vers ESXi C

La VM s’exécute sur l’hôte ESXi C du Prefered-Site.

La politique Number Of Failures To Tolerate est configurée 1

Les hôtes ESXi sont intégrés dans des Fault Domain FD1, FD2 et FD3

FD1 = Prefered Site, FD2 = Secondary Site et FD3 = Witness Site.

Les hôtes ESXi A, B, C, D dans FD1, les hôtes ESXi E, F, G, H dans FD2 et l’hôte témoin ESXi W dans FD3

ESXi A est propriétaire de l’objet VMDK1.

ESXi E est propriétaire de l’objet réplica VMDK1′.

1. La VM effectue la lecture d’un bloc de données dans son VMDK1.
2. vSan utilise la Read Locality et vérifie la présence en cache du bloc demandé sur l’un des hôtes ESXi du cluster dans le Prefered-site possédant l’objet VMDK1.
3. Le bloc est trouvé dans le cache de l’hôte A. L’opération de lecture traverse le réseau et s’effectue sur l’un des disk group de l’hôte ESXi A par l’intermédiaire de sa carte contrôleur interne.
4. vSan effectue la lecture sur le disque de cache SSD du Disk Group 2 de l’hôte ESXi A
5. L’information est remontée à la VM

Lecture d’un bloc de données non en cache après vMotion de la VM en mode Streched Cluster:

La VM est déplacée par un vMotion de l’hôte ESXi A vers ESXi C

La VM s’exécute sur l’hôte ESXi C du Prefered-Site.

La politique Number Of Failures To Tolerate est configurée 1

Les hôtes ESXi sont intégrés dans des Fault Domain FD1, FD2 et FD3

FD1 = Prefered Site, FD2 = Secondary Site et FD3 = Witness Site.

Les hôtes ESXi A, B, C, D dans FD1, les hôtes ESXi E, F, G, H dans FD2 et l’hôte témoin ESXi W dans FD3

ESXi A est propriétaire de l’objet VMDK1.

ESXi E est propriétaire de l’objet réplica VMDK1′.

1. La VM effectue la lecture d’un bloc de données dans son VMDK1.
2. vSan utilise la Read Locality et vérifie la présence en cache du bloc demandé sur l’un des hôtes ESXi du cluster dans le Prefered-site possédant l’objet VMDK1.
3. Le bloc de données demandé n’est pas trouvé en cache. vSan effectue ses lectures sur les disques capacitifs de l’hôte A.
4. Le bloc de données non présent en cache sur l’hôte A, la lecture traverse le réseau vSan pour effectuer la lecture sur les disques capacitifs du disk group 2 de l’hôte A par l’intermédiaire de sa carte contrôleur interne.
5. Le bloc de données va être placé dans le disque de cache SSD du Disk Group2 de l’hôte ESXi A.
6. L’information est remontée à la VM

Ecriture d’un bloc de données en mode Streched Cluster:

La VM s’exécute sur l’hôte ESXi A du Prefered-Site.

La politique Number Of Failures To Tolerate est configurée 1

Les hôtes ESXi sont intégrés dans des Fault Domain FD1, FD2 et FD3

FD1 = Prefered Site, FD2 = Secondary Site et FD3 = Witness Site.

Les hôtes ESXi A, B, C, D dans FD1, les hôtes ESXi E, F, G, H dans FD2 et l’hôte témoin ESXi W dans FD3

ESXi A est propriétaire de l’objet VMDK1.

ESXi E est propriétaire de l’objet réplica VMDK1′.

1. La VM effectue l’écriture d’un bloc de données dans son VMDK1.
2. Le DOM Owner de l’objet VMDK1 (l’hôte ESXi A) va cloner l’opération d’écriture demandée par la VM et l’envoyée en parallèle à l’hôte qui détient l’objet et les réplicas d’objets.
3. Une écriture est envoyée localement vers le disque de cache du disk group 2 de l’hôte ESXi A via sa carte contrôleur interne et l’autre vers le disque de cache du disk group 2 de l’hôte ESXi E via le réseau (lien inter-sites).
4. Une fois le bloc de données écrit dans chaque cache SSD, vSan prépare les acquittements (ACK) à envoyer à l’hôte DOM Owner de l’objet VMDK1 (dans notre cas ESXi A).
5. Les deux acquittements (ACK) sont reçus par le DOM Owner de l’objet VMDK1 est l’opération d’écriture est validée. Le bloc pourra résider en cache ou être déchargé sur les disques capacitifs en fonction de la fréquence de lecture du bloc par la VM.

En Streched Cluster, l’objet Witness ne détient que les métadonnées. A chaque écriture sur un objet, le Witness est mis à jour.

Ecriture d’un bloc de données après vMotion de la VM en mode Streched Cluster:

La VM est déplacée par un vMotion de l’hôte ESXi A vers ESXi C

La VM s’exécute sur l’hôte ESXi C du Prefered-Site.

La politique Number Of Failures To Tolerate est configurée 1

Les hôtes ESXi sont intégrés dans des Fault Domain FD1, FD2 et FD3

FD1 = Prefered Site, FD2 = Secondary Site et FD3 = Witness Site.

Les hôtes ESXi A, B, C, D dans FD1, les hôtes ESXi E, F, G, H dans FD2 et l’hôte témoin ESXi W dans FD3

ESXi A est propriétaire de l’objet VMDK1.

ESXi E est propriétaire de l’objet réplica VMDK1′.

1. La VM effectue l’écriture d’un bloc de données dans son VMDK1.
2. Le DOM Owner de l’objet VMDK1 (l’hôte ESXi A) va cloner l’opération d’écriture demandée par la VM et l’envoyée en parallèle à l’hôte qui détient l’objet et les réplicas d’objets.
3. Une écriture est envoyée via le réseau local vSan au disque de cache du disk group 2 de l’hôte ESXi A et l’autre au disque de cache du disk group 2 de l’hôte ESXi E via le lien inter-sites.
4. Une fois le bloc de données écrit dans chaque cache SSD, vSan prépare les acquittements (ACK) à envoyer à l’hôte DOM Owner de l’objet VMDK1 (dans notre cas ESXi A).
5. Les deux acquittements (ACK) sont reçus par le DOM Owner de l’objet VMDK1 est l’opération d’écriture est validée. Le bloc pourra résider en cache ou être déchargé sur les disques capacitifs en fonction de la fréquence de lecture du bloc par la VM.

En Streched Cluster, l’objet Witness ne détient que les métadonnées. A chaque écriture sur un objet, le Witness est mis à jour.