Utiliser les bonnes pratiques de création et d’organisation des LUNs et volumes VMFS

Dans la série des bonnes pratiques de modélisation de votre infrastructure de stockage, le sizing de vos LUNs et volumes VMFS ne sera pas un élément bloquant de vos déploiements mais plutôt une tranquillité d’esprit quant à l’optimisation des moyens mis en œuvre pour rendre une installation plus facile et cohérente à administrer à long terme.

Déterminer les spécificités d’environnement

Pour cela, nous allons partir de préalables à déterminer selon vos besoins :

• Nombre total de VMs
• Taille moyenne (maximale) des VMs (en Go/To)
• Taille totale de la baie de stockage (en To)
• Pourcentage d’espace disque estimé réservé aux snapshots et au swap

Garder en tête les pratiques habituellement constatées

Chaque configuration révèle ses vérités et l’expérience que vous obtenez au fur et à mesure de vos déploiements peut radicalement vous faire changer de méthode. Néanmoins, il reste certaines recommandations jusqu’alors bien utiles :

• On dépasse rarement 30 machines virtuelles par LUN pour garder une file d’attente disque raisonnable. Idéalement, on restera dans la dizaine.
• On tente le plus possible de distinguer et de rapprocher en groupes les machines virtuelles de taille similaire : 0 à 100Go, 100 à 500Go etc…
• On arrondit toujours la taille totale estimée à une valeur supérieure d’au moins 20Go
• On utilise toujours des DataStores plutôt que des Raw Device Mapping (RDM), sauf si l’on désire présenter des volumes de plus de 800Go.
• VMFS3 supporte des volumes allant jusqu’à 64To donc vous n’avez pas à vous inquiéter d’un quelconque bridage technique.

Simuler une taille de volume

Comme il n’existe pas de taille idéale par définition, nous allons partir de valeurs de test pour effectuer notre exemple de modélisation :

• Nombre total de VMs : 112
• Taille moyenne (maximale) des VMs : 50Go pour 102 machines (soit une taille totale de 5,1To) et 3 VMs à 1To (soit une taille totale de 3To)
• Taille totale de la baie de stockage : 10To
• Pourcentage d’espace disque estimé réservé aux snapshots et au swap : 20

La formule mathématique qui en découle est donc très simple :

Nombre total de VMs x Taille moyenne (maximale) des VMs + 20% = Taille du volume

Comme dans notre configuration test nous nous retrouvons avec de nombreuses machines virtuelles – qui plus est hétérogènes – et que nous désirons suivre les bonnes pratiques et recommandations, nous allons créer les volumes en conséquence. Attention, ce n’est pas compliqué mais il faut être attentif avec la succession du raisonnement logique :

• 102 VMs x 50Go + 20% =  6120Go > comme on préfère travailler avec des datastores et qu’ils ne doivent pas dépasser 800Go, on divise donc 6120 par 800, ce qui donne 8 datastores de 800Go (6,4To au total) .
• 3 VMs x 1To + 20% = 3,6To > comme nos disques dépassent 800Go par machine, on crée un RDM pour chacune, ce qui donne 3 RDM de 1,5To (4,5To au total) au lieu de 1,2To normalement car avec des machines de cette taille, on surévalue par précaution le sizing en prévoyant des snapshots gourmands qui traîneraient et grossiraient bien plus vite qu’avec de petites machines virtuelles…

J’insiste sur le fait que ce n’est pas un calcul très complexe mais tout de même fin et très emprunt d’une dose de vécu qui vous fera adapter intelligemment chaque paramètre pour satisfaire au mieux votre déploiement. Rappelez-vous enfin que la concaténation de LUNs existe (MetaLUN) et que vous n’avez aucune raison de vous en priver. De même, si vous passez d’un environnnement Virtual Infrastructure à vSphere, aucun problème étant donné que le VMFS de vSphere, en version 3.33, est totalement compatible avec la version 3.31 de Virtual Infrastructure.

Rester lucide sur son travail

Voilà, votre modélisation est désormais argumentée et sérieuse. Cependant, n’avez-vous rien remarqué de bloquant ? 6,4To + 4,5To font 10,9To. Or, votre baie ne fait que 10To ! Pourtant vous ne pouvez pas avoir plus d’espace disque. Vous êtes donc confronté à une réalité tout à fait opérationnelle : il va falloir faire “comme vous pouvez”, en prenant soin de respecter au mieux les bonnes pratiques tout en faisant avec les contraintes techniques du client. C’est là que vont entrer en jeu votre imagination et votre expertise, sachant que travailler avec une baie aussi pleine n’est pas serein, ne serait-ce que vis-à-vis du blocage immédiat que vous allez rencontrer concernant la création de nouvelles VMs ou l’extension à prévoir des VMDK déjà en production.

Bon courage !

Comprendre les bonnes pratiques de partitionnement des hôtes sous VMware ESX 3.5 et vSphere

Le partitionnement de vos hôtes ESX semble anecdotique de prime abord, d’autant plus que l’installation graphique par défaut de VMware ESX ou de vSphere vous permet d’automatiser cette opération. Néanmoins, ce qui différenciera le simple technicien de l’expert commencera par l’affinage du partitionnement des hôtes de manière à assurer la pérennité du filesystem Red Hat.

Partez du fait que de nos jours, les disques embarqués dans les serveurs sont très volumineux alors qu’une installation standard d’un hôte ESX ne consommera la plupart du temps guère plus de 20Go.
Pourquoi donc s’embarrasser à créer de petites partitions alors que la majorité de l’espace disque – qui plus est si le stockage des VMs est centralisé – sera inutilisé ? Tout simplement parce-qu’il vaut mieux comprendre et argumenter ses choix plutôt que de se baser sur l’opulence et la facilité. De plus, si l’espace est relativement bien optimisé, il permettra un stockage VMFS de VMs de test ou de sauvegardes à bas coût.

Pré-requis à un partitionnement affiné

• Pour toutes les partitions de 1Go et supérieur, utilisez des multiples de 1024Mo (exemple : 5 x 1024 = 5120)
• Pensez à garder 5Go non attribués (plus ou moins…) au cas où vous devriez d’urgence rajouter un point de montage à votre filesystem
• Faites tout particulièrement attention à créer des points de montage cohérents avec votre utilisation d’ESX, notamment pour éviter que votre filesystem se remplisse

Par exemple, voici une installation fonctionnelle sous VMware ESX 3.5 Update 4 dont le point de montage /var/log peut pourtant poser problème si jamais des fichiers temporaires étaient générés en masse ou si un sous-dossier tel que /var/core venait à générer des core dumps du Service Console. Le filesystem pollué par ces fichiers se remplirait alors dangereusement et pourrait finir par crasher une fois plein.

[root@esx root]# df -vh
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2             4.0G  1.4G  2.5G  35% /
/dev/sda1             198M   28M  161M  15% /boot
none                  250M     0  250M   0% /dev/shm
/dev/sda10            2.0G  368M  1.6G  19% /opt
/dev/sda9             2.0G  134M  1.8G   7% /tmp
/dev/sda7             2.0G  353M  1.6G  19% /var/log
/dev/sda8             2.0G   33M  1.9G   2% /var/updates
/dev/sda6             9.8G  153M  9.2G   2% /vmimages
/vmfs                 123G     0  123G   0% /vmfs

Synthèse de partitionnement affinée

[table id=9 /]

Voici dans le détail ce partitionnement mis en œuvre sous VMware ESX 3.5 Update 4 :

[root@esx root]# df -vh
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2             5.0G  1.2G  3.6G  25% /
/dev/sda1             200M   58M  200M   29% /boot
/dev/sda8             2.0G   33M  1.9G   2% /home
/dev/sda9             2.0G   33M  1.9G   2% /opt
none                  132M     0  132M   0% /dev/shm
/dev/sda7             5.0G   33M  4.7G   1% /tmp
/dev/sda6             5.0G  199M  4.5G   5% /var
/dev/sda5             123G     0  123G   0% /vmfs

Même chose, mais cette fois sous VMware vSphere 4 :

[root@esx root]# df -vh
Filesystem            Size  Used Avail Use% Mounted on
/dev/sdc1             5.0G  1.6G  3.2G  33% /
/dev/sdb1             1.1G   74M  952M   8% /boot
/dev/sdc6             2.0G   36M  1.9G   2% /home
/dev/sdc7             2.0G   68M  1.9G   4% /opt
/dev/sdc8             5.0G  139M  4.6G   3% /tmp
/dev/sdc5             5.0G  189M  4.5G   4% /var
/dev/sdc9             123G     0  123G   0% /vmfs

Avec l’arrivée de vSphere, la création de partitions s’est considérablement simplifiée. Ainsi, vous n’avez plus à choisir si une partition doit être primaire ou logique ni à renseigner d’informations additionnelles. De même, vous n’aurez plus à créer de filesystem vmkcore (on le créait à 100mo jusqu’à ESX 3.5) ni de partition /boot qui enfle au passage à 1,1Go contre environ 200mo auparavant. Cela est apparemment prévu pour accueillir de futures mises à jour.

Vous aurez peut-être également noté que sous vSphere, le Service Console devient un simple .vmdk (donc une machine virtuelle) stocké dans /vmfs/volumes. C’est une autre variante de vSphere qui demande pour cela de créer un volume vmfs lors de l’installation et de lui donner un nom. Ici on l’a appelé vmfs-local0-esx, ce qui est matérialisé par le lien symbolique de l’UUID que j’ai colorié en vert.

Note : si la création d’un point de montage /vmfs était optionnelle sous VMware ESX 3.x, elle devient de fait obligatoire depuis vSphere.

[root@esx volumes]$ ll
total 1024
drwxr-xr-t 1 root root 1120 Dec  3 16:45 4b17dd13-59b3c11f-1716-002219655b17
lrwxr-xr-x 1 root root   35 Dec  3 17:23 vmfs-local0-esx -> 4b17dd13-59b3c11f-1716
-002219655b17
[root@esx volumes]$ cd vmfs-local0-esx/
[root@esx vmfs-local0-esx]$ ll
total 64
drwxr-xr-x 1 root root 840 Dec  3 16:59 esxconsole-4b17db68-666b-401c
-ccaf-002219655b15
[root@esx vmfs-local0-esx]$ cd esxconsole-4b17db68-666b-401c-ccaf-002219655b15/
[root@esx esxconsole-4b17db68-666b-401c-ccaf-002219655b15]$ ll
total 135356608
drwxr-xr-x 1 root root          280 Dec  3 16:59 core-dumps
-rw------- 1 root root 138604969984 Dec  3 17:23 esxconsole-flat.vmdk
-rw------- 1 root root          478 Dec  3 16:45 esxconsole.vmdk
drwxr-xr-x 1 root root          980 Dec  3 16:59 logs