Tout ce que vous devez savoir sur vSphere et le stockage de données (2ème partie)
VMware ESX a peut-être été une aubaine pour les administrateurs système, mais il n’a guère simplifié le travail des professionnels du stockage. vSphere corrige bon nombre des défauts de son prédécesseur en la matière. Seconde partie d'une série de trois articles
Lorsque VMware a lancé vSphere 4.0 en mai 2009, la nouvelle plateforme de virtualisation de l’éditeur a apporté plus de 100 nouvelles fonctionnalités et améliorations, dont un grand nombre concernait le stockage de données. Dans un premier article daté du 19 janvier 2010, nous étions revenus sur les principales en matière de Thin Provisionning, de support d'iSCSI, de support de FCoE et des JUmbo Frames, d'extension à chaud de VMDK et d'accroissement de volumes VMFS. Nous poursuivons aujourd'hui ce tour d'horizon en trois parties des améliorations de la gestion du stockage apportées par vSphere :
Architecture de stockage modulaire
VMware a doté vSphere d'une nouvelle architecture de stockage modulaire qui permet aux fournisseurs tiers d'interfacer le logiciel avec les capacités de leurs systèmes de stockage. L'architecture dite "Pluggable Storage Architecture" (PSA) permet par exemple aux fournisseurs de créer des plug-ins pour contrôler certaines fonctions de gestion des entrées/sorties telles que le multipathing.
vSphere intègre par défaut la possibilité de définir de façon fixe ou par un mécanisme de round-robin les chemins à utiliser, lorsqu'il existe plusieurs chemins pour accéder à un périphérique de stockage en réseau. Les constructeurs peuvent désormais enrichir ces fonctions de base en développant leurs propres plug-ins. Ils peuvent ainsi optimiser l'équilibrage de charge entre chemins ou effectuer des choix de chemins plus intelligents (ce qu'offre par exemple EMC avec l'intégration de son plug-in de multipath, PowerPath, à vSphere). Il est à noter que la PSA met à profit les nouvelles capacités offertes par les API vStorage.
Des adaptateurs SCSI paravirtualisés
La paravirtualisation est une technologie disponible pour certains systèmes d'exploitation (et notammetn Linux) qui s'appuie sur la mise en oeuvre d'un pilote spécial pour communiquer directement avec l'hyperviseur. Sans paravirtualisation, l'OS invité n'a pas conscience de fonctionner au dessus d'une couche de virtualisation et ses appels à la couche de stockage se font au travers d'une couche d'émulation.
L'usage de la paravirtualisation permet de réduire sensiblement l'utilisation du CPU et assure de bien meilleurs débits puisque l'émulation de périphérique n'est plus nécessaire. Son impact est particulièrement sensible pour les applications gourmandes en entrées/sorties. Les adaptateurs paravirtualisés peuvent être utilisés pour contrôler les partitions autres que la partition principale. On les active en modifiant les paramètres de la machine virtuelle (en activant la fonctionnalité paravirtualisation).
VMDirectPath pour les périphériques de stockage
VMDirectPath permet à une machine virtuelle d'acceder directement aux ressources physiques d'un adaptateur hôte (carte HBA, SAS ou Ethernet) comme s'il lui était rattaché directement. Ce faisant, on contourne la couche de virtualisation ce qui permet d'obtenir des niveaux de débits et d'utilisation CPU proches de ceux d'une machine physique. L'inconvénient est qu'il faut dédier un adaptateur à une machine virtuelle et, qu'une fois dédié, il ne pourra être utilisé par une autre machine virtuelle sur l'hôte.
VMDirectPath est uniquement disponible pour un nombre restreint d'adaptateurs réseau et de stockage, et uniquement à titre expériental pour les adaptateurs de stockage. L'usage de VMDirectPath doit être envisagé pour les machines virtuelles qui ont des besoins élevés en matière d'entrées/sorties, typiquement celles hébergeant un serveur de base de données. L'inconvénient le plus important de la technologie à ce jour est qu'il est impossible de combiner l'usage de VMDirectPath avec de fonctions telles que VMotion et VMware Distributed Resource Scheduler (DRS).
Storage VMotion amélioré
Alors que VMotion déplace une machine virtuelle en cours d'exécution d'un hôte à un autre, sans affecter son fonctionnement, Storage VMotion (SVMotion) permet de déplacer le stockage associé à une machine virtuelle sans impact sur la bonne marche de cette VM. SVMotion a d'abord été introduit dans la version 3.5 d'ESX Server, mais n'était disponible qu'en mode ligne de commande. Dans vSphere, il est intégré dans le client vSphere, ce qui permet un usage simplifié. En outre, SVMotion supporte désormais la conversion entre volume fins et volume "épais" pendant le déplacement (et vice-versa).
SVMotion peut aussi être utilisé pour re-optimiser un disque "thin-provisionné" après un effacement de données sur ce disque. En règle générale, Storage VMotion est utilisé pour déplacer les volumes associés à une VM sur un autre périphérique de stockage, mais il est aussi possible d'utiliser la technologie pour effectuer une conversion de disque (fin à épais ou l'inverse) sans changer de dispositif physique de stockage. SVMotion est notamment précieux lors d'opérations de maintenance planifiées, puisqu'il permet le déplacement des fichiers de machines virtuelles sans perturber l'exploitation.
Des modifications opérées sous le capot de vSphere rendent le processus de migration bien plus efficace que dans ESX Server 3.5. Au lieu d'effectuer une copie instantanée (snapshot) lors de la copie du disque à son nouvel emplacement, et d'effectuer un "commit" à la fin de l'opération de bascule, SVMotion utilise désormais une nouvelle fonction de suivi des blocs modifiés qui journalise les modifications apportées à des blocs de données pendant le processus de mouvement puis rejoue ce journal sur le périphérique de destination pendant la dernière phase du processus.
A suivre dans la dernière partie : La nouvelle API vStorage et les nouvelles vue et alarmes orientées stockage de vCenter.
A lire aussi sur Searchstorage.fr :
Tout ce que vous devez savoir sur vSphere et le stockage de données (1ère partie)