VFRC – Flash Read Cache

Petit ajout au lab 1 concernant la partie performance.

Lorsque j’ai commencé à faire le lab 1, j’avais dans l’idée de tester le VFRC (Vmware Fast Read Cache) pour le comparer aux performances que j’avais sur les datastores et les disques. Une fois le lab fini, et prêt à installer VFRC, j’ai lu la doc….
Et là, c’est le drame, je me suis rendu compte qu’il fallait un vCenter et que le VFRC se gérait via le client web.
J’ai donc mis cette idée en attente. Avec l’avancement du lab 2, je dispose maintenant d’un cluster VMware et d’un vCenter. Je reprend donc le test du VFRC.

Avant de commencer, une petite explication rapide, le Vmware Fast Read Cache permet d’utiliser des équipements de type flash (disque SSD…) pour ajouter du cache en LECTURE au niveau des disques des VMs.

L’idée est plutôt sympa et permet de rationaliser l’utilisation du SSD. A noter qu’on peut également se servir des disques SSD pour stocker le swap des ESX. Personnellement, je ne pense pas que ce soit une bonne solution, si les ESX se mettent à swapper, c’est que la ram est saturée à plus de 90%, je pense qu’il vaut mieux revoir le sizing de l’infra, plutôt que de masquer le manque de ressources ram par du cache SSD…

Donc c’est parti, on regarde rapidement la doc

Performance of vSphere Flash Read Cache in VMware vSphere 5.5
https://www.vmware.com/files/pdf/techpaper/vfrc-perf-vsphere55.pdf

On lance le client web et on configure VFRC.
On vérifie sur l’ESX que le disque SSD est bien présent

Ensuite au niveau de la VM, on vérifie également que la partie Virtual Flash est bien configurée. Il faut éventuellement sélectionner le disque SSD.

Enfin, on paramètre la quantité de cache au niveau du disque / VMDK
Pour nostre premier test, on va mettre 100% de la capacité du disque en flash..

On relance toujours le même test
SANS VFRC     /     AVEC VFRC 100% de la capacité

On constate effectivement une nette amélioration sur la lecture, on retrouve les valeurs du test sur un datastore SSD.

On va essayé d’optimiser un peu le fonctionnement. Déjà, mettre 100% de la capacité du datastore, c »est un peu ridicule, le fichier généré par l’application de test est de 2Go, donc on va essayé de prendre plutôt en compte la taille du fichier que celle du datastore.

Dans la doc, il y a des indications pour calculer la bonne taille, le paramétrage des blocs…
Pour notre lab, on va prendre 50 % de la taille du fichier et 4k pour les blocs.
il faut rentrer dans les paramètres avancés.

On constate une baisse des performances. Cela est normal dans notre cas. En effet, si on prend comme exemple une base de donnée, il va y avoir un % de blocs « actifs » mais pas toute la base, il faudra alors estimer cette taille pour définir au mieux celle du cache, surement entre 10 et 20%.

Ici, on fait un test de performance du disque, l’intégralité du fichier de 2Go est sollicitée.
La taille de notre cache est trop petite. Par contre par rapport aux performances du disque SATA, on est bien au dessus, surtout pour le 4k

On a fait un rapide tour du VFRC et on a effectivement mis en évidence son apport au niveau des performances. Il faut par contre bien avoir à l’esprit que ce gain n’est valable que pour de la LECTURE et nécessite un peu d’investigation pour déterminer la taille du cache ainsi que celle des blocs. De plus, dans un cluster VMware, si on veut pouvoir bouger des VMs entre les ESX, il faudra avoir la même conf sur tous les hôtes…