Quant on travail avec VMWare on a parfois tendance a oublier les bases... Voila une piqûre de rappel plus que nécéssaire sur comment on stock des données sur un disque dur... et comment VMWare "émule" cela...

La machine Physique

Quand une application sur une machine physique veut écrire quelque chose sur un disque local, l'OS de la machine émet une requête d'écriture, cette requête va être traiter par le contrôleur de disques auquel est attaché le disque visé. Le HBA ou Contrôleur de Disque se charge de la gestion des disques (RAID, redondance, etc...)

La machine Virtuelle (VM)

Il en va de même pour une VM à la différence que les ordres traités par "contrôleur de disque" de la VM, vont être interceptés et redirigés vers le fichier VMDK qui "contient" les données du disque virtuel. Le serveur host VMWare va résoudre le chemin vers le datastore visé, et ce quelque soit la nature profonde du stockage. Sur un host avec stockage local, il s'agit d'initier un dialogue avec le HBA qui contrôle le disque dur en question et d'émettre une commande d'écriture d'un bloc donné à un endroit donné sur le disque.

Augmentation des Volumes et des disques

Quand le nombre de disques de stockage augmentent, et que nous débordons la capacité maximale du contrôleur SCSI, nous passons d'une version "direct attached" à une "mise en réseau" des disques, évidement le SCSI n'est pas capable directement de débordé son nombre de disque maximum, il faut passer par un appareil qui fera la jonction entre un grand nombre de disques physiques (plusieurs dizaines) et les serveurs qui ne peuvent voir qu'un faible nombre de disques (moins de 20).

Les SANs

C'est l'idée de base des SAN qui offraient un grand nombre de disques montés et présentés comme un seul (ou quelques) disque(s) aux serveurs ESX.

 

Cette suite d'événements parait évidente et simple, surtout avec des technologies éprouvées comme le FibreChannel (FC), mais n'oublions pas que VMWare écrit au final dans un fichier VMDK sur un filesystem VMFS, et que dans le cas d'un système de stockage distant a technique est la même que pour un disque local, sauf que les contrôleurs HBA doivent initier un dialogue avec un appareil distant, et que ce dialogue peut passer via divers appareils (switches fabric, controlleurs de SAN, etc) et dans ce cas déjà, beaucoup de problèmes externes peuvent se présenter.

Les NASs

Si au lieu d'utiliser un protocole "bloc", comme le FiberChannel, on doit écrire sur un NAS en iSCSI ou en NFS, les NAS n'écrivent pas directement sur des volumes, mais écrivent dans des fichiers locaux, au travers de l'OS du NAS:

 

Ce système de fichiers NAS contient outre les données des fichiers également des métadonnées. Dans de nombreux cas, il est très important pour la stabilité du système que les métadonnées soient mise à jour de manière prudente et réfléchie, car si elle n'est pas, et il y a un réel risque de perte de données, en cas d'accident ou de panne de courant, qui pourrait rendre le système de fichiers instable, inutilisable, et même irrécupérable.

La Synchronisation

Quelque soit le type de stocakge (local, DirectAttached, NAS, SAN) il est important pour VMWare de s'assurer que toutes écritures a été faite correctement et réellement, donc en bon élèves, un ESX attendra la confirmation d'écriture avant de passer (réellement) à autre chose.

Le signal de synchronisation fournit a l'ESX l'assurance que les données qu'il a écrit sont écrites sur un disque et non "en transit". Ce type de signal dans un protocole "hardware" comme le FibreChannel ou le SCSI est assez facile a obtenir (puisque le contrôleur (ou le SAN) est responsable directement de la gestion des disques), mais plus délicats dans le cas d'un NAS du fait de la couche "software" qui ne sais pas toujours si les disques ont un "cache" d'écriture ou non.

ESX et les blocs de données

Un host VMWare considère toutes demandes d'écritures disques venant d'une VM comme "importantes" et prendra donc TOUTES les garanties pour l'écriture de celles-ci. Ce qui signifie qu'il attendra la réponse du système de stockage. Sur un SAN (ou tout autre système "bloc") cette réponse sera souvent immédiate (ou presque) mais sur un NAS, qui pour augmenter les performances, utilise souvent des caches et écrit sur les disques de manière asynchrone, cela peut prendre du temps.

Alors voilà le problème, ESX représente le disque dur de votre machine virtuelle dans un fichier VMDK. Cependant, il n'a vraiment aucune idée de ce que VM tente d'écrire sur le disque, et donc considère que toute écriture est précieuse. En d'autres termes, VMware écrit tout avec une demande de confirmation de synchronisation. Cela peut entraîner des ralentissements importants.

Sur un serveur avec stockage local, la solution typique à ce problème est d'utiliser un contrôleur RAID équipé de write back cache et d'une batterie de secours.

La même chose se produit sur des périphériques réseaux, VMware exige que toutes écritures soit faite sur un stockage stable,

Maintenant, il est important de comprendre que VMware veut être prudent avec vos données. Disons que votre VM met à jour certaines métadonnées du système de fichiers, par exemple, la table de blocs libres, car un certains nombres de fichiers ont été crées sur la VM.

• La VM écrit une mise à jour qui indique quels blocs ont été utilisés.

• ESXi envoie cette mise à jour vers le système de stockage NAS / SAN. Supposons que l’écriture est différée (pour des raisons de performances) et qu’à ce moment précis, une panne de courant (non secourue) survient.

Après redémarrage, le NAS montrera ces blocs comme libre et vide, la VM pourra écrire sur ces block (et donc remplacer le contenu des fichiers crées juste avant le crash).

Donc, la solution de VMware est de s'assurer que les écritures sont signalées comme synchronisé et de confier le problème du sous-système de stockage.

Sync or not Sync ?

Si dans les périphériques "blocs" (comme le SCSI ou le FiberChannel) la question ne se pose pas, elle se pose largement pour les périphériques "réseaux" et les protocoles IP.

En général, dans un protocole réseaux, vous avez le choix d’activé la synchronisation ou non, c'est souvent une question de cout/performances/risques qui vous permettra de décider.

• NFS, par défaut, activera la synchronisation en écriture à la demande des ESX. C'est pourquoi il est lent. Vous pouvez améliorer les performances avec un cache Front en SSD.

• iSCSI, par défaut, n’a pas synchronisation. En tant que tel, il apparaît souvent comme beaucoup plus rapide, et donc un bien meilleur choix que NFS, cependant, attention là aussi aux pertes de données. On peut activer la synchronisation sur les données iSCSI, mais dès lors les performances seront en baise.