Cet article ne concerne que le stockage en environnement SAN et plus particulièrement de type Fiber Channel.

Types de stockages disponibles 

Le système de virtualisation VMware ESX permet l’utilisation de plusieurs types de stockage en environnement SAN basé sur le protocole Fiber Channel :

• Virtual Machine File System

C’est un système de fichiers spécifique permettant de stocker des fichiers pour les machines virtuelles. VMFS est optimisé afin de pouvoir gérer l’exécution de plusieurs machines virtuelles en une seule charge de travail. Il fournit aussi une gestion distribuée des verrouillages de fichiers afin de permettre à plusieurs hôtes VMware ESX de partager des LUNs sur un SAN. Un volume VMFS peut être étendu sur 32 extensions de stockage d’un même type. Il est possible d’étendre un volume VMFS lorsque des machines virtuelles sont en cours d’exécution sur ce même volume. Dans une configuration simple, les disques des machines virtuelles sont stockés sous forme de fichiers VMDK dans un datastore VMFS.

• Raw Device Mapping

Un RDM est un fichier spécial dans un volume VMFS qui intervient comme un proxy pour un “RAW device” (portion de disque ne contenant pas de système de fichier). Les RDMs fournissent certains des avantages des disques virtuels stockés dans un volume VMFS tout en conservant certains avantages de l’accès direct au disque physique. De manière générale, l’utilisation de RDM est recommandée quand une machine virtuelle doit interagir directement avec un disque physique sur le SAN.

Dans quels cas utiliser des RDMs ?

L’utilisation d’un RDM est généralement requis lors de l’utilisation de Microsoft Cluster Server (MSCS) ou d’outils tiers de gestion du SAN. Ces outils permettent d’accéder à des fonctionnalités de snapshot, mirroir ou réplication.

Les RDMs sont aussi utiles dans le cas de construction d’infrastructure physique ou virtuelle en standby, c’est à dire que le volume peut être présenté à un système physique et un système virtuel. On peut donc aussi envisager d’utiliser un RDM pour garder la possibilité de redémarrer sur une machine physique en cas de défaillance au niveau VMware ou dans le cas d’un cluster MSCS physique / virtuel ou dont les noeuds sont hébergés sur des serveurs VMware ESX différents.

Dans le cadre de l’utilisation de VMFS, il n’est pas possible de monitorer l’accès au SAN d’une machine virtuelle, mais seulement l’accès des hôtes VMware ESX avec les outils de monitoring traditionnels fournis avec votre SAN. Il faut utiliser le client VMware Infrastructure. Une bonne alternative est d’utiliser un RDM.

Les performances entre VMFS et RDM sont quasiment similaires. Ce n’est donc pas un critère de choix.

Etendre un VMDK ou un volume VMFS est aussi plus contraignant. Pour étendre la taille d’un disque d’une machine virtuelle avec un RDM, il suffit d’étendre la LUN concernée, puis d’étendre le volume dans le système d’exploitation. Pour un volume VMFS, il faut augmenter la taille du volume VMFS en ajoutant une LUN supplémentaire, puis il devient possible d’étendre le fichier VMDK concerné (cette opération est toujours réalisée à froid, machine virtuelle à l’arrêt), pour enfin étendre le volume dans le système d’exploitation concerné.

Attention : Il est necessaire de démonter le RDM puis de le remonter lors d’une utilisation en mode virtuel, machine virtuelle arrêtée. En mode physique, l’operation peut être réalisée en toute transparence, à chaud.

RDM en mode virtuel ou en mode physique ?

Les RDMs peuvent être utilisée dans deux modes : virtuel ou physique. La principale différence est l’impossibilité d’utiliser les fonctionnalités de snapshot au niveau VMware en mode physique. Par conséquent, les fonctionnalités de VMware Consolidated Backup (VCB) ne sont pas non plus disponibles (le fonctionnement de VCB est basé sur les snapshots).

L’avantage du mode physique est de pouvoir utiliser des logiciels ou systèmes d’exploitation qui requièrent des accès directs au stockage comme un agent de management SAN qui flush les écritures disques en cache dans une machine virtuelle puis envoie des commandes au SAN directement afin de réaliser un snapshot directement par la baie et garantir son intégrité.

Ce mode est aussi utile lorsqu’une application est basée sur le target SCSI ou encore pour mettre en place un cluster avec un noeud virtuel et un noeud physique.

Les volumes VMFS

Pour commencer, il faut créer son volume correctement, c’est-à-dire, avec le client VMware Infrastructure ou le client VMware Infrastructure Web. Il ne faut pas utiliser le programme d’installation pour créer des volumes VMFS car celui-ci risque de créer une structure qui ne soit pas alignée et donc moins performante.

Durant le processus de configuration, il faut choisir la taille des blocs. Il convient de choisir la taille des blocs en fonctions du volume maximal qu’occupera un fichier stocké sur ce volume. Pour une taille de bloc de 1 Mo, la taille d’un fichier sur le volume VMFS sera de 256 Go, pour 2 Mo, la taille passe à 512 Go, pour 4 Mo, 1 To, pour 8 Mo, 2 To.

Concernant la taille des volumes VMFS, VMware suggère de ne pas dépasser 10 à 15 machines virtuelles par volume, ce qui correspond généralement à des volumes de 200 à 500 Go. En effet, chaque réservation SCSI sur une LUN bloque les accès en écriture aux VMDKs qui y sont stockés. Une réservation SCSI est produite à chaque opération sur les fichiers stockés sur le volume (création de fichier, extension d’un VMDK, etc.). Les réservations SCSI sont de courte durée mais pénalise la performance globale des machines virtuelles qui y sont stockées.

Plusieurs petites LUNs ou une grande LUN unique ?

VMware ESX Server ne permet l’utilisation que d’un seul volume par LUN. Cependant, il est possible d’utiliser un seul volume VMFS réparti sur plusieurs LUNs.

Il est plus intéressant d’utiliser moins de LUNs de plus grandes tailles :

• Pour d’avantage de flexibilité pour créer des machines virtuelles, c’est-à-dire, ne pas avoir à modifier la configuration du SAN
• Plus de souplesse pour redimensionner les disques, utiliser les snapshots, etc.
  Moins de LUNs à gérer

Il est plus judicieux d’utiliser plus de LUNs de plus petites tailles :

• Si les applications sont multiples et requiert des niveaux de RAID différents
• Pour disposer de plus de flexibilité de configuration car la stratégie de multipathing et les priorités d’accès aux disques (disk share) sont gérés par LUN

Il est bien entendu qu’un volume VMFS réparti sur plusieurs LUNs n’améliore pas la performance d’accès aux disques des machines virtuelles.

Tout le monde convient qu’il faut éviter l’utilisation des extensions. C’est une configuration qui comporte des risques de corruption en cas d’absence d’une des LUNs (petite erreur de zoning temporaire par exemple) et réduit la capacité de gestion du stockage car il est impossible de réallouer une extension sans détruire le volume dans son intégralité.

Autres paramètres à prendre en compte

La mise en oeuvre d’un cluster Microsoft requiert l’utilisation d’une LUN par ressource disque cluster.

Si plusieurs machines virtuelles partagent un volume VMFS commun, il peut être difficile d’optimiser l’accès au stockage. VMware recommande de répartir les machines virtuelles entre les serveurs, les processeurs et le stockage.

Pour optimiser l’infrastructure il est judicieux de présenter plusieurs LUNs et de définir un chemin préféré différent à chaque LUNs. Ceci permet de répartir la charge sur les différentes interfaces Fiber Channel d’un hôte VMware ESX et éventuellement sur les différents contrôleurs d’une baie de disques.

Dernier point à prendre en compte, qui n’a rien à voir avec VMware, la capacité de votre baie de stockage d’étendre des LUNs à partir d’un espace de stockage libre qui n’est pas toujours contigu avec la LUN à étendre. Certaines baies de disques “entrée de gamme” ne le supportent pas.