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.

Les disques utilisés pour le cache sont principalement des disques de type SLC (Single Level Cell). Les disques SLC propose des performances en lecture et écriture bien plus élevé que les disques de type MLC et TLC. De même le cout d’un disque SLC est bien plus chère et ont une durée de vie de l’ordre de 10x supérieure à un disque MLC.

Ci-dessous un tableau comparatif des types de SSD :

vSan utilise un algorithme lui permettant de cloner ses écritures en fonction de la politique FTT appliquée à l’objet et cela dans les deux modes (Hybrid / All Flash). Cet algorithme permet au propriétaire de l’objet (DomOwner) de cloner les opérations d’écritures. L’écriture d’un bloc de données est effectuée sur les disques de cache des disk group hébergeant l’objet ou le(s) réplica(s) d’objet(s), en passant par plusieurs cartes contrôleurs RAID mais aussi plusieurs cartes réseaux (SFP+ ou BASE-T).

Nous verrons qu’en cas de migration d’une VM entre les hôtes ESXi du cluster vSan, le cache n’est pas reconstruit sur l’hôte qui exécute la VM. 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é de réécriture ou déplacement du cache en local est plus élevé que celle engendrée par le réseau 10Gbps.

Ecriture d’un bloc de données (version Hybrid):

La VM s’exécute sur l’hôte ESXi A.

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

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

ESXi B 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 via la carte contrôleur HBA interne de l’hôte ESXi A et l’autre vers le disque de cache du disk group 1 de l’hôte ESXi B via le réseau.
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.
6. 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.

Ecriture d’un bloc de données après vMotion de la VM (version Hybrid):

La VM s’exécute sur l’hôte ESXi C.

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

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

ESXi B 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 vers le disque de cache du disk group 2 de l’hôte ESXi A et l’autre vers le disque de cache du disk group 1 de l’hôte ESXi B. Les 2 écritures sont faites via le réseau.
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 C).
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.
6. 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.