Mettre en place des règles d’affinité dans un cluster DRS sous VMware vSphere

Les règles d’affinité permettent de définir que certaines machines virtuelles doivent être placées sur le même hôte ESX (affinity) ou au contraire sur des hôtes distincts (anti-affinity).

En général, on présume que les règles d’affinité s’établissent pour améliorer les performances et que les règles d’anti-affinité privilégient au contraire la haute disponibilité. En effet, on n’agira pas de la même manière selon que l’on doit sécuriser un cluster Exchange ou donner le maximum de proximité – et donc de performances – à une base de données et son serveur applicatif.

Pour définir une règle sur un cluster DRS, il suffit de cliquer droit sur le cluster et sélectionner Edit Settings…

La fenêtre qui apparaît propose ensuite de régler les paramètres du cluster, que ce soit au niveau de VMware HA ou de VMware DRS. Ici, on s’astreindra à sélectionner le menu Rules et à cliquer sur le bouton Add… pour ajouter une nouvelle règle.

Après avoir donné un nom à la nouvelle règle, il suffit juste de sélectionner des machines virtuelles du cluster (toujours via un bouton Add…) et de sélectionner le type de règle qui nous intéresse :

• Separate Virtual Machines : impose aux machines virtuelles sélectionnées de s’exécuter sur des hôtes distincts
• Keep Virtual Machines Together : impose aux machines virtuelles sélectionnées de rester sur le même hôte ESX

Sachez également qu’une règle d’anti-affinité n’autorise que deux machines virtuelles à la fois. C’est dommage mais c’est ainsi pour le moment…

Une fois vos modifications effectuées, vous les retrouverez dans le menu Rule. En décochant la case, vous pourrez à tout moment désactiver cette règle sans la détruire.

Le bouton Details vous permettra d’obtenir un résumé de votre règle et déterminer si d’autres règles rentrent en conflit avec votre nouvelle règle.

Le vCenter indiquera enfin par une tâche récente que la reconfiguration du cluster a bien été prise en compte.

Bien que les règles d’affinité soient très facilement compréhensibles, n’oubliez jamais que le niveau d’automation de votre cluster DRS agira également sur vos réglages. Si vous optez pour une automation Manual ou Partially automated, votre cluster ne prendra pas de décision à votre place. En ce sens, il ne pourra qu’établir des recommandations suivant vos règles.

Par exemple, si vous sélectionnez trois machines qui doivent rester ensemble et qu’une de ces trois machines se trouve sur un autre hôte ESX, vous devrez manuellement appliquer la recommandation.

Dans l’onglet DRS de votre cluster, vous aurez peut-être remarqué qu’il existe trois vues : Recommandations, Faults et History. La première vous permet de visualiser et de valider les recommandations le cas échéant. La deuxième vous permet de rapidement déterminer les problèmes sur vos règles. Le vue History permet quant à elle de retracer l’évolution des opérations.

Changez votre niveau d’automation à Fully automated si vous voulez que vos règles s’exécutent immédiatement, et ce sans intervention supplémentaire.

En outre, utiliser le cmdlet Powershell Get-DrsRule, vous permettra également connaître à tout moment le détail des règles existantes (activées ou pas) qui s’appliquent sur un cluster donné (notez l’astérisque qui sert de wildcard…).

[vSphere PowerCLI] C:> Get-DrsRule -Name "*" -Cluster "Cluster Prod"

Name            Enabled KeepTogether VMIDs
----            ------- ------------ -----
Serveur web     True    True         {VirtualMachine-vm-789, VirtualMachine-vm-...

Utiliser le Thin Provisionning sous VMware vSphere 4

Une des avancées majeures de vSphere 4 concerne le support du Thin Provisionning qui permet d’économiser de l’espace disque sur un SAN en donnant la possibilité à l’administrateur de spécifier à des disques virtuels de ne consommer que la place réellement utile et de grandir au besoin, plutôt que d’allouer tout l’espace par défaut. Si la technologie est connue, son comportement sous vSphere mérite d’être mieux appréhendé.

Lorsque l’on déploie une machine, l’assistant Disk Format nous propose désormais l’option Thin provisioned format. Vous remarquerez au passage que seuls les systèmes de fichiers VMFS-3 supportent cette fonctionnalité.

Dans le montage ci-dessous, on a déployé le même template deux fois de suite. La première fois on a choisi Same format as source qui crée dans notre cas un disque Thick par défaut. La deuxième fois, on a choisi Thin provisioned format. On peut dès lors observer les différences d’allocation d’espace disque. La machine dont le disque utilise le Thin Provisionning ne consomme effectivement que 5,90 Go sur les 16 potentiels.

Lorsque l’on navigue dans le Datastore correspondant et qu’on ouvre le conteneur de la VM, on obtient la preuve que le Thin Provisionning est bien pris en compte.

Si maintenant on veut tester la fonctionnalité, il suffit de remplir l’espace disque vide en copiant des fichiers et constater l’agrandissement du disque VMDK en temps réel dans le Datastore.

Dans l’inventaire de la VM, un rafraîchissement de la vue du stockage indiquera la nouvelle allocation.

A partir de ces observations, vous devrez avoir compris le principe. Sachez toutefois que faire de la place sur un disque en Thin provisioned format ne provoquera pas une réduction du disque .vmdk pour autant. L’opération ne fonctionne en effet que dans un sens…

Le cas des snapshots

Etude de cas très importante que la création de snapshots en mode Thin Provisionning. Du moment où vous en aurez créé un, le provisionnement du disque augmentera automatiquement pour refléter les changements.

De retour dans le conteneur de la VM, vous découvrirez alors les fichiers habituels .vmsn et le nouveau .vmdk dans lequel les écritures s’effectueront jusqu’à la consolidation du snapshot. Lors de sa suppression, le provisionnement reviendra à son état initial.

Thin Provisionning rime avec planification

Si l’utilisation de cette technique est séduisante et permet de maximiser l’utilisation d’un SAN, n’oubliez jamais qu’elle peut vous amener à gérer des situations douloureuses, par exemple dans le cas où la taille totale de l’espace provisionné dépasserait l’espace disque total de votre Datastore à cause – pourquoi pas – de snapshots non maîtrisés.

La capture écran ci-dessous reflète l’utilisation la plus sécurisée de l’espace, dans le sens où la valeur Provisioned Space ne dépasse pas la valeur Capacity. C’est en revanche un constat extrêmement fréquent que de relever des valeurs de provisionning bien supérieures à la capacité totale physiquement disponible.

Pour éviter de vous faire surprendre par un volume plein, une seule solution invariable : monitorez plutôt deux fois qu’une le remplissage des disques, que ce soit par le biais d’alarmes dans le vCenter ou par un outil tiers !

Auditer les performances des machines virtuelles sous VMware vSphere 4 (deuxième partie)

Avant toute chose, je vous invite à lire la première partie de cet article si vous n’en avez pas encore pris connaissance.

Maintenant que vous avez saisi l’importance du triptyque d’analyse de performance (système d’exploitation, VM, hôte), il ne vous reste plus qu’à le vérifier par vous-même. Pour cela, les graphs de performance intégrés au vCenter sont particulièrement utiles. Lorsque vous sélectionnez une machine virtuelle, vous aurez probablement remarqué l’onglet Performance qui permet d’obtenir à la fois une vue synthétisée de l’état actuel de la VM (Overview) et une vue plus précise et personnalisable (Advanced) qui était d’ailleurs la seule disponible avant la sortie de VMware vSphere 4.

La vue Advanced permet de personnaliser les compteurs que l’on veut surveiller et de remonter dans le temps selon les réglages pré-enregistrés dans le moteur de SGBD du vCenter. Dans les exemples ci-dessous, on a choisi d’afficher les valeurs CPU Usage et CPU Ready. Pour cela, il suffit de cliquer sur le lien Chart Options… et de choisir les valeurs qui nous intéressent.

Etude de cas

Si la valeur CPU Usage est connue et maitrisée,  CPU Ready est quant à elle fort intéressante dans le sens où elle reflète l’intervalle pendant lequel la VM est prête pour exécuter des instructions mais ne le peut pas car elle n’arrive pas à obtenir de ressources processeur suffisantes de l’hôte. En d’autres termes, le CPU Ready correspond au temps passé (en millisecondes) avant d’obtenir un contexte d’exécution mémoire disponible. On ne peut donc à nouveau pas interpréter de lenteurs à coup sûr sans croiser les relevés de performance…

1er cas : la VM est moyennement utilisée mais l’hôte ne répond pas de façon optimale

• Moyenne CPU Usage : 37%
• Moyenne CPU Ready : 16ms

2ème cas : la VM charge beaucoup et l’hôte ne répond pas de façon optimale

• Moyenne CPU Usage : 86%
• Moyenne CPU Ready : 24ms

3ème cas : la VM est peu utilisée et l’hôte répond quasi de façon optimale

• Moyenne CPU Usage : 1%
• Moyenne CPU Ready : 3ms

Note : la valeur CPU Ready n’a de sens qu’analysée sur du long terme. En effet, votre hôte peut charger ponctuellement, des VMs peuvent nécessiter beaucoup de ressources en même temps et au moment même où vous mesurez les performances, etc…

La valeur de référence de CPU Ready étant 0ms, vous pouvez tenir pour acquis que plus vos mesures sont près de 0, plus votre infrastructure virtualisée répond bien.

Il existe bien d’autres moyens de déterminer des lenteurs dans un système d’exploitation, dans une VM ou un hôte ESX. Le tout étant de bien comprendre le mécanisme de virtualisation. A présent vous n’aurez qu’à appliquer le même principe de réflexion pour la RAM, le réseau ou les I/O disque.

Pour aller plus loin, je vous invite à lire les documents de référence VMware suivants qui prolongent cet article :

• CPU Ready
• HyperThreading