Comparaison et explication de VMware vSphere HA et DRS
Un hyperviseur VMware vous permet d’exécuter des machines virtuelles sur un seul serveur. Vous pouvez exécuter plusieurs machines virtuelles sur un hôte VMware ESXi autonome et réaliser un déploiement de plusieurs hôtes pour exécuter davantage de machines virtuelles. Si vous disposez de plusieurs hôtes VMware ESXi connectés via le réseau, vous pouvez migrer des machines virtuelles d’un hôte à un autre.
Parfois, l’utilisation de plusieurs hôtes connectés via le réseau pour exécuter des VMs ne suffit pas à répondre aux besoins de l’entreprise. Par exemple, en cas de défaillance d’un hôte, toutes les VMs résidant sur cet hôte cesseront également de fonctionner. De plus, les Workloads des VMs sur les hôtes VMware ESXi peuvent être déséquilibrés, et la migration manuelle des VMs d’un hôte à l’autre est une opération courante. Pour remédier à ces problèmes, VMware propose des fonctionnalités de clustering telles que VMware High Availability (HA) et Distributed Resource Scheduler (DRS). L’utilisation du clustering VMware vSphere vous permet de réduire les temps d’arrêt des VMs et d’utiliser les ressources matérielles de manière rationnelle. Cet article de blog traite des fonctionnalités VMware HA et DRS , ainsi que des cas d’utilisation de chaque fonctionnalité de clustering.
Qu’est-ce qu’un cluster vSphere ?
Un cluster vSphere est un ensemble d’hôtes ESXi connectés qui partagent des ressources matérielles telles que le processeur, la mémoire et le stockage. Les clusters VMware vSphere sont gérés de manière centralisée dans vCenter. Les ressources d’un cluster sont regroupées dans un pool de ressources ; ainsi, lorsque vous ajoutez un hôte à un groupe, les ressources de cet hôte sont intégrées à celles de l’ensemble du cluster. Les hôtes ESXi membres du cluster sont également appelés nœuds de cluster. Il existe deux types de clusters vSphere : vSphere High Availability et Distributed Resource Scheduler (VMware HA et DRS).
Conditions à remplir pour les clusters VMware
Pour déployer VMware HA et DRS, certaines conditions doivent être remplies :
- Il faut utiliser au moins deux ESXi hôtes présentant une configuration identique (processeurs de la même famille, version ESXi et niveau de correctif, etc.). Par exemple, vous pouvez utiliser deux serveurs équipés de processeurs Intel de la même famille (ou
AMD) et sur lesquels {12} est installé. Il est recommandé d’utiliser au moins trois hôtes pour une protection et des performances optimales. - Des connexions réseau haut débit pour le réseau de gestion, le réseau de stockage et le réseau vMotion. Des connexions réseau redondantes sont requises.
- Un magasin de données partagé accessible à tous les hôtes ESXi au sein d’un cluster. Un réseau de stockage (SAN), un périphérique de stockage en réseau (NAS) et VMware vSAN peuvent être utilisés comme magasin de données partagé. Les protocoles NFS et iSCSI sont pris en charge pour accéder aux données d’un magasin de données partagé. Les fichiers des machines virtuelles doivent être stockés sur un magasin de données partagé.
VMware vCenter Servercompatible avec la version d’ESXi installée sur les hôtes.
Contrairement à un Hyper-V Failover Cluster, aucun quorum n’est requis et vous n’avez pas besoin d’utiliser des noms de réseau complexes.
Qu’est-ce que VMware HA dans vSphere ?
VMware vSphere High Availability (HA) est une fonctionnalité de clustering conçue pour redémarrer automatiquement une machine virtuelle (VM) en cas de panne. VMware vSphere High Availability permet aux entreprises de garantir une haute disponibilité pour les VMs et les applications s’exécutant sur celles-ci au sein d’un cluster vSphere (indépendamment des applications en cours d’exécution). VMware HA offre une protection contre la panne d’un hôte ESXi : la machine virtuelle en panne est redémarrée sur un hôte en bon état. Vous pouvez ainsi réduire considérablement les temps d’arrêt.
Les conditions à remplir pour vSphere HA
Les conditions à remplir pour vSphere HA doivent être prises en compte en plus des conditions générales relatives aux clusters vSphere. Pour configurer VMware vSphere High Availability, vous devez disposer des éléments suivants :
- A
VMware vSphere Standardlicence - Au moins 4 Go de RAM sur chaque hôte
- Une passerelle accessible par ping
Comment fonctionne vSphere HA ?
VMware vSphere High Availability vérifie les hôtes ESXi afin de détecter une défaillance d’hôte. Si une défaillance d’hôte est détectée (les VMs exécutées sur cet hôte sont également en panne), les VMs défaillantes sont alors migrées vers des hôtes ESXi en bon état au sein du cluster. Après la migration, les VMs sont enregistrées sur les nouveaux hôtes, puis démarrées. Les fichiers de la machine virtuelle (VMX, VMDK et autres) se trouvent sur la même ressource, à savoir un magasin de données partagé, après la migration. Les fichiers de la machine virtuelle ne sont pas migrés. Seuls les composants processeur, mémoire et réseau utilisés par les VMs en panne sont fournis par le nouvel hôte ESXi après la migration.
Le temps d’indisponibilité est égal au temps nécessaire pour redémarrer une VM sur un autre hôte. Cependant, gardez à l’esprit qu’il faut également compter le temps nécessaire au démarrage du système d’exploitation et au chargement des applications requises sur une VM. VMware HA est une solution qui fonctionne au niveau de la couche VM et peut également être utilisée si les applications ne disposent pas de fonctionnalités natives de haute disponibilité. VMware vSphere High Availability ne dépend pas du système d’exploitation invité installé sur la VM.
Le fonctionnement d’un cluster vSphere HA est illustré dans le schéma ci-dessous. Cet exemple présente un cluster composé de trois hôtes VMware ESXi. Les VMs s’exécutent sur tous les hôtes. Les connexions entre les VMs et leurs fichiers sont représentées par des lignes pointillées.
1. Fonctionnement normal d’un cluster. Toutes les VMs s’exécutent sur leurs hôtes d’origine.
2. L’hôte ESXi 1 tombe en panne. Les VMs résidant sur l’hôte ESXi 1 (VM1 et VM2) sont en état de défaillance (ces VMs sont éteintes). Un cluster vSphere HA lance le redémarrage des VMs sur d’autres hôtes ESXi en bon état.
3. Les VMs ont été migrées et redémarrées sur des hôtes en bon état de fonctionnement. VM1 a été migrée vers l’hôte ESXi 2, et VM2 a été migrée vers l’hôte ESXi 3. Les fichiers des VMs se trouvent au même emplacement sur le stockage partagé connecté à tous les hôtes ESXi du cluster vSphere.
HA maître et subordonnés
Après que vSphere High Availability est activé dans le cluster, un hôte ESXi est sélectionné comme HA maître. Les autres hôtes ESXi sont des subordonnés (hôtes esclaves subordonnés). Un maître surveille l’état des subordonnés afin de détecter à temps toute défaillance d’hôte et de lancer le redémarrage des VMs défaillantes. L’hôte maître surveille également l’état du Stromstatus des VMs sur les nœuds du cluster. Si une défaillance de VM est détectée, le maître lance un redémarrage de la VM (l’hôte optimal est sélectionné par le maître avant le redémarrage de la VM défaillante). Le maître HA envoie à vCenter des informations sur l’état du cluster HA . VMware vCenter gère le cluster par l’interface fournie par l’hôte maître HA .
Le maître peut exécuter des VMs au même titre que les autres hôtes du cluster. En cas de défaillance d’un hôte maître, un autre hôte maître est sélectionné. L’hôte connecté au plus grand nombre de magasins de données bénéficie d’un avantage lors de l’élection de l’hôte ESXi principal. Les hôtes qui ne sont pas en cours de maintenance participent à l’élection de l’hôte principal.
Les hôtes subordonnés peuvent exécuter des machines virtuelles, surveiller leur état et transmettre des informations actualisées sur cet état à l’hôte maître HA .
Fault Domain Manager (FDM) est le nom de l’agent utilisé pour surveiller la disponibilité des serveurs physiques. L’agent FDM fonctionne sur chaque hôte ESXi au sein d’un cluster HA .
Types de défaillances des hôtes
Il existe trois types de défaillances des hôtes ESXi :
Défaillance. Un hôte ESXi a cessé de fonctionner pour une raison quelconque.
Isolation. Un hôte ESXi et les VMs qu’il héberge continuent de fonctionner, mais l’hôte est isolé des autres hôtes du cluster en raison de problèmes réseau.
Partition. La connectivité réseau avec l’hôte principal est perdue.
Comment les défaillances sont-elles détectées ?
Des signaux de présence sont échangés pour détecter les défaillances dans un cluster vSphere HA . L’hôte principal surveille l’état des hôtes secondaires en recevant des signaux de présence de leur part chaque seconde. L’hôte principal envoie des pings ICMP à l’hôte secondaire et attend les réponses. Si l’hôte principal ne parvient pas à communiquer directement avec l’agent de l’hôte secondaire, ce dernier peut être en bon état de fonctionnement ou en panne, mais inaccessible via le réseau.
Si l’hôte principal ne reçoit pas de signaux de présence, il vérifie alors l’hôte suspect par l’intermédiaire de Datastore Heartbeating. En fonctionnement normal, chaque hôte au sein d’un HA cluster échange des signaux de présence avec le magasin de données partagé. L’hôte ESXi principal vérifie si les signaux de présence du magasin de données ont bien été échangés avec l’hôte suspect, en plus d’envoyer des pings à cet hôte. S’il n’y a pas d’échange de signaux de présence du magasin de données avec l’hôte suspect et que cet hôte n’envoie pas de requêtes ICMP , alors l’hôte est désigné comme hôte défaillant.
Remarque : Un répertoire spécial .vSphere-HA est créé à la racine d’un magasin de données partagé pour la gestion des signaux de présence et l’identification d’une liste de VMs protégées. Notez que les magasins de données vSAN ne peuvent pas être utilisés pour la gestion des signaux de présence du magasin de données. Si l’hôte principal ne parvient pas à se connecter à l’agent de l’hôte secondaire, mais que ce dernier échange des signaux de vérification d’activité avec le magasin de données partagé, l’hôte principal marque alors l’hôte suspect comme étant isolé du réseau. Si l’hôte principal détermine que l’hôte secondaire fonctionne dans un segment de réseau isolé, il continue à surveiller les VMs présentes sur cet hôte isolé. Si les VMs de l’hôte isolé sont éteintes, l’hôte principal lance le redémarrage de ces VMs sur un autre hôte ESXi. Vous pouvez configurer la réponse du cluster vSphere HA lorsqu’un hôte ESXi se retrouve isolé du réseau.
Surveillance des VMs individuelles. VMware vSphere High Availability dispose d’un mécanisme permettant de surveiller les VMs individuelles et de détecter si une VM particulière a subi une défaillance. {45} Les services installés sur un système d’exploitation invité (OS) sont utilisés pour déterminer l’état de la machine virtuelle. VMware Tools envoient des signaux de présence du système d’exploitation invité à l’hôte ESXi.
Les signaux de présence et les activités d’entrée/sortie (I/O) générés par VMware Tools sont surveillés par le service de surveillance des machines virtuelles. Si l’hôte ESXi principal du cluster HA détecte que VMware Tools sur la machine virtuelle protégée ne répondent pas et qu’il n’y a aucune activité I/O , l’hôte lance un redémarrage de la machine virtuelle. La surveillance de l’activité des machines virtuelles I/O permet à un cluster HA d’éviter des redémarrages inutiles de machines virtuelles si VMware Tools n’envoient pas de signaux de présence pour une raison quelconque alors que la machine virtuelle est en cours d’exécution. Vous pouvez définir la sensibilité de la surveillance afin de configurer le délai après lequel une machine virtuelle doit être redémarrée si les signaux de présence du système d’exploitation invité générés par VMware Tools ne sont pas reçus par l’hôte ESXi. VMware vSphere HA redémarre la machine virtuelle sur le même hôte VMware ESXi en cas de défaillance d’une seule machine virtuelle. Les signaux de présence
VMware Tools sont envoyés à hostd au niveau de l’hyperviseur (ESXi), et non par la pile réseau. L’hôte VMware ESXi transmet ensuite les informations reçues à vCenter. Les signaux de présence VMware Tools peuvent être reçus par un hôte VMware ESXi si une machine virtuelle est déconnectée du réseau, et même si aucune carte réseau virtuelle n’est connectée à la machine virtuelle.
Surveillance des machines virtuelles et des applications. Vous pouvez utiliser SDK d’un fournisseur tiers pour surveiller si une application spécifique installée sur une machine virtuelle a subi une défaillance. L’autre option consiste à utiliser une application prenant déjà en charge la surveillance des applications VMware. Les signaux de pulsation d’application sont utilisés pour la surveillance des applications sur les machines virtuelles VMware s’exécutant dans un cluster VMware vSphere HA .
Paramètres clés pour la configuration du cluster HA
Avant de commencer à configurer un cluster HA, vous devez définir certains paramètres clés. La réponse d’isolation est un paramètre qui définit le comportement d’un hôte ESXi lorsqu’il ne reçoit pas de signaux de pulsation. Les options disponibles sont Leave powered on, Power off (par défaut) et Shutdown.
Reservation est un paramètre calculé en fonction des caractéristiques maximales de la machine virtuelle la plus gourmande en ressources au sein d’un cluster. Ce paramètre sert à estimer la capacité de basculement. Un cluster HA crée des créneaux de réservation par la valeur du paramètre « Reservation ».
Capacité de basculement. Ce paramètre est mesuré en nombre entier et définit le nombre maximal de serveurs pouvant tomber en panne au sein du cluster sans impact négatif sur les Workloads (le cluster et toutes les VMs peuvent continuer à fonctionner après la défaillance de ce nombre d’hôtes ESXi).
Nombre de pannes d’hôtes autorisées. Ce paramètre est défini par un administrateur système afin de déterminer le nombre d’hôtes pouvant tomber en panne sans interrompre le fonctionnement du cluster. La capacité de basculement est prise en compte lors de la définition de la valeur de ce paramètre.
Admission Control est le paramètre utilisé pour garantir que des ressources suffisantes sont réservées à la récupération des VMs après la panne d’un hôte ESXi. Ce paramètre est défini par un administrateur et détermine le comportement des VMs s’il n’y a pas suffisamment d’emplacements libres pour démarrer des VMs après des pannes d’hôtes ESXi. Admission Control définit la capacité de basculement, c’est-à-dire le pourcentage de dégradation des ressources pouvant être toléré dans un cluster vSphere HA après un basculement.
Restart Priority est défini par un administrateur pour déterminer l’ordre de démarrage des VMs après le basculement d’un nœud du cluster. Les administrateurs peuvent configurer vSphere HA pour démarrer en premier lieu les machines virtuelles critiques, puis les autres VMs.
Capacité de basculement et défaillance d’hôte
Examinons deux cas, chacun comportant trois hôtes ESXi mais avec des valeurs de capacité de basculement différentes. Dans le premier cas, le cluster HA peut continuer à fonctionner après la défaillance d’un hôte ESXi (voir la partie gauche de l’image ci-dessous). Dans le deuxième cas, le HA cluster peut tolérer la défaillance de deux hôtes ESXi (voir la partie droite de l’image).
1. Chaque hôte ESXi dispose de 4 emplacements. Le cluster compte 6 VMs. Si un hôte ESXi tombe en panne (le troisième hôte, par exemple), les trois VMs (VM4, VM5 et VM6) peuvent alors migrer vers les deux autres hôtes ESXi. Dans mon exemple, ces trois VMs migrent vers le deuxième hôte ESXi. Si un autre hôte ESXi tombe en panne, il n’y aura plus d’emplacements libres pour migrer et exécuter d’autres VMs.
2. Chaque hôte ESXi dispose de 4 emplacements. 4 VMs sont en cours d’exécution dans le cluster VMware vSphere HA . Dans ce cas, il y a suffisamment d’emplacements pour faire fonctionner toutes les VMs au sein du cluster si deux hôtes ESXi tombent en panne.
Pour calculer Failover Capacity, procédez comme suit : du nombre total de nœuds du cluster, soustrayez le rapport entre le nombre de VMs du cluster et le nombre d’emplacements sur un nœud. Si le résultat est un nombre non entier (un nombre qui n’est pas un nombre entier), arrondissez-le à l’entier inférieur le plus proche. Calculons Failover Capacity pour les deux exemples.
Exemple 1 :
3–6/4=1,5
Arrondissez 1,5 à 1. Toutes les VMs d’un HA cluster peuvent survivre si 1 hôte ESXi tombe en panne.
Exemple 2 :
3–4/4=2
Il n’est pas nécessaire d’arrondir à l’entier inférieur, car 2 est un nombre entier. Toutes les VMs peuvent continuer à fonctionner si 2 hôtes ESXi tombent en panne.
Contrôle d’admission
Comme mentionné ci-dessus, le contrôle d’admission est le paramètre nécessaire pour garantir qu’il y ait suffisamment de ressources pour faire fonctionner les VMs après la défaillance d’un hôte dans le cluster. Vous pouvez également définir le Admission Control State paramètre pour plus de commodité. Admission Control State est calculé comme le rapport entre Failover Capacity et Nombre de défaillances d’hôtes autorisées (NHF).
Si Failover Capacity est supérieur à NHF, alors le HA cluster est correctement configuré. Sinon, vous devez définir Admission Control manuellement. Deux options sont disponibles :
1. Ne pas démarrer les VMs si elles enfreignent les contraintes de disponibilité (ne pas démarrer les VMs s’il n’y a pas suffisamment de ressources matérielles).
2. Autoriser le démarrage des VMs même si elles enfreignent les contraintes de disponibilité (démarrer les VMs malgré le manque de ressources matérielles).
Choisissez l’option qui correspond le mieux à votre vSphere High Availability cas d’utilisation du cluster. Si votre objectif est la fiabilité du HA cluster, sélectionnez la première option (Do not power on VMs). Si votre priorité est de garantir le fonctionnement de toutes les VMs, sélectionnez alors la deuxième option (Allow VMs to be started). Sachez que dans ce second cas, le comportement du cluster peut s’avérer imprévisible. Dans le pire des cas, le cluster HA peut devenir inutilisable.
Remplacements au niveau des VMs
Les remplacements au niveau des VMs (ou HA dans le cas d’un cluster HA ) constituent l’option qui vous permet de désactiver HA pour une VM spécifique s’exécutant dans le cluster HA . Vous pouvez configurer votre cluster VMware vSphere HA à un niveau plus granulaire grâce à cette option au niveau du cluster.
Tolérance aux pannes
VMware propose une fonctionnalité pour les clusters VMware vSphere HA qui vous permet d’atteindre un temps d’indisponibilité nul en cas de défaillance d’un hôte VMware ESXi. Cette fonctionnalité s’appelle Fault Tolerance. Alors que la configuration standard de vSphere High Availability nécessite un redémarrage de la machine virtuelle en cas de panne, Fault Tolerance permet aux VMs de continuer à fonctionner si l’hôte ESXi principal sur lequel elles sont enregistrées tombe en panne. Fault Tolerance peut être utilisé pour les VMs stratégiques exécutant des applications critiques.
La mise en place d’une continuité d’activité de très haut niveau, garantissant une indisponibilité nulle, implique une surcharge, car il existe deux instances en cours d’exécution d’une machine virtuelle protégée par Fault Tolerance. La deuxième machine virtuelle « fantôme » s’exécute sur le deuxième hôte ESXi, et toutes les modifications apportées à la machine virtuelle d’origine (processeur, RAM, état du réseau) sont répliquées de l’hôte ESXi initial vers l’hôte ESXi secondaire. La machine virtuelle protégée est appelée « machine virtuelle principale » et la machine virtuelle dupliquée est appelée « machine virtuelle secondaire ». Les machines virtuelles primaire et secondaire doivent résider sur des hôtes ESXi différents afin de garantir une protection contre la défaillance d’un hôte ESXi.
Les deux machines virtuelles (primaire et secondaire) s’exécutent simultanément et consomment des ressources processeur, RAM et réseau sur les deux hôtes ESXi (ainsi, une machine virtuelle protégée par la fonctionnalité Fault Tolerance consomme deux fois plus de ressources au sein du cluster vSphere HA ). Ces machines virtuelles sont synchronisées en continu et en temps réel. Les utilisateurs ne peuvent travailler qu’avec la machine virtuelle principale (originale) ; la machine virtuelle secondaire (fantomatique) leur est invisible.
Si le premier hôte ESXi tombe en panne (l’hôte sur lequel réside la machine virtuelle principale), les Workloads sont alors migrés vers la machine virtuelle secondaire (c’est-à-dire le clone de la machine virtuelle ou la machine virtuelle fantomatique) s’exécutant sur le deuxième hôte ESXi. La machine virtuelle secondaire devient active et accessible en un instant. Les utilisateurs peuvent constater une légère latence réseau au moment du basculement transparent. Il n’y a ni interruption de service ni perte de données pendant le basculement. Une fois le basculement effectué avec succès, une nouvelle machine virtuelle « fantôme » est créée sur l’hôte ESXi de secours en bon état afin d’assurer la redondance et de poursuivre la protection de la machine virtuelle contre une défaillance de l’hôte ESXi.
Fault Tolerance évite les scénarios de « split-brain » (lorsque deux copies actives d’une machine virtuelle protégée s’exécutent simultanément) grâce au mécanisme de verrouillage des fichiers sur le stockage partagé pour la coordination du basculement. Cependant, Fault Tolerance ne protège pas contre les défaillances logicielles au sein d’une machine virtuelle (telles que la défaillance du système d’exploitation invité ou celle d’applications particulières). Si une machine virtuelle principale tombe en panne, la machine virtuelle secondaire tombe également en panne. Conditions à remplir pour Fault Tolerance
- Un cluster vSphere
HAcomprenant au moins deux hôtes ESXi. vMotionetFT logging.- Un processeur compatible prenant en charge la virtualisation assistée par matériel
MMU.
Il est recommandé d’utiliser un réseau dédié Fault Tolerance au sein du cluster vSphere HA .
Une licence pour les Fault Tolerance
- hôtes VMware ESXi est requise pour utiliser
Fault Tolerance. - vSphere
StandardetEnterpriseoffrent une prise en charge jusqu’à 2 vCPU pour une seule machine virtuelle. - vSphere
Enterprise Plusvous permet d’utiliser jusqu’à 8 vCPU par machine virtuelle.
Fault Tolerance limitations
L’utilisation de VMware Fault Tolerance dans VMware vSphere comporte certaines limitations. Fonctionnalités de VMware vSphere incompatibles avec FT:
- instantanés de machine virtuelle. Une machine virtuelle protégée ne doit pas comporter d’instantanés.
- Clones liés
- VMware {118} Magasins de données
Périphériques non pris en charge :
Raw device mappingpériphériques- CD-ROM physiques et autres périphériques d’un serveur connectés à une machine virtuelle en tant que périphériques virtuels
- Périphériques audio et périphériques USB
- Disques virtuels VMDK dont la taille dépasse 2 To
- Périphériques vidéo avec graphiques 3D
- Ports parallèles et série
Hot-plugpériphériquesNIC (network interface controller)pass-throughStorage vMotion(doivent être temporairement désactivés pour migrer les fichiers de la machine virtuelle vers un autre stockage)
Qu’est-ce que le DRS dans VMware vSphere ?
Distributed Resource Scheduler (DRS) est une fonctionnalité de clustering de VMware vSphere qui permet d’équilibrer la charge des VMs s’exécutant dans le cluster. DRS vérifie la charge des VMs et celle des serveurs ESXi au sein d’un cluster vSphere. Si DRS détecte qu’un hôte ou une VM est surchargé(e), DRS migre la VM vers un hôte VMware ESXi disposant de ressources matérielles libres suffisantes pour garantir la qualité de service (QoS). DRS Vous pouvez sélectionner l’hôte VMware ESXi optimal pour une machine virtuelle lorsque vous créez une nouvelle machine virtuelle dans le cluster.
VMware DRS vous permet d’exécuter des VMs dans un cluster équilibré et d’éviter les surcharges ainsi que les situations où les ressources matérielles sont insuffisantes pour permettre le fonctionnement normal des VMs et des applications qui y sont exécutées (dans ce cas, il doit y avoir suffisamment de ressources dans l’ensemble du cluster).
DRS Conditions à remplir
Les conditions à remplir pour DRS, en plus des exigences générales pour un cluster VMware vSphere, comprennent :
- Licence vSphere
Enterpriseou vSphereEnterprise Plus - Un processeur doté de la technologie
Enhanced vMotion Compatibilitypour la migration à chaud des VMs avecvMotion - Un
vMotionRéseaux
dédié. Un VMware vMotion configuré est nécessaire pour faire fonctionner un cluster DRS , contrairement à un cluster HA , où vMotion n’est requis que si l’on utilise Fault Tolerance. De plus, la licence vSphere requise pour VMware vSphere DRS est plus coûteuse que celle nécessaire pour utiliser vSphere High Availability.
. Le rôle de vMotion
: migrer des VMs d’un hôte VMware ESXi à un autre à l’aide de vMotion, comme nous l’avons mentionné lors de l’explication du fonctionnement de Fault Tolerance . Avec VMware vMotion, la migration des VMs (processeur, mémoire, état du réseau) s’effectue sans interrompre les VMs en cours d’exécution (il n’y a pas de temps d’arrêt). VMware vMotion est la fonctionnalité clé pour le bon fonctionnement de DRS.
Examinons les principales étapes du fonctionnement de vMotion :
1. vMotion crée une machine virtuelle « fantôme » sur l’hôte VMware ESXi de destination. L’hôte VMware ESXi de destination pré-alloue suffisamment de ressources pour la VM à migrer. La VM est placée dans un état intermédiaire et sa configuration ne peut pas être modifiée pendant la migration.
2. Le processus de pré-copie. Chaque page de mémoire de la VM est copiée de la source vers la destination par un réseau vMotion .
3. Un nouveau passage de copie des pages de mémoire de la source vers la destination est effectué, car les pages de mémoire sont modifiées pendant le fonctionnement de la VM. Il s’agit d’un processus itératif qui se poursuit jusqu’à ce qu’il ne reste plus aucune page de mémoire modifiée. Les pages mémoire modifiées sont appelées « pages sales ». La migration d’une machine virtuelle via « vMotion » prend plus de temps si des opérations gourmandes en mémoire sont effectuées sur cette machine virtuelle, car un plus grand nombre de pages mémoire sont alors modifiées.
4. La machine virtuelle est arrêtée sur l’hôte ESXi source et redémarrée sur l’hôte de destination. À ce moment-là, une latence réseau négligeable peut être constatée au sein de la machine virtuelle migrée pendant environ une seconde.
Principe de fonctionnement de DRS dans VMware
VMware DRS vérifie les Workloads du point de vue du processeur et de la mémoire vive pour déterminer l’équilibre du cluster VMware vSphere chaque minute, ce qui correspond à l’intervalle par défaut. VMware DRS vérifie toutes les ressources du pool de ressources du cluster, y compris celles consommées par les VMs et celles de chaque hôte VMware ESXi au sein du cluster pouvant être mises à disposition pour l’exécution des machines virtuelles. Les vérifications des ressources sont effectuées conformément aux politiques configurées.
Les besoins des VMs sont également pris en compte (les ressources matérielles dont les VMs ont besoin pour fonctionner au moment de la vérification). La formule suivante est utilisée pour calculer les besoins en mémoire des VMs : Besoin en mémoire de la VM = Fonction(Mémoire active utilisée, Mémoire transférée, Mémoire partagée) + 25 % (mémoire consommée en mode inactif)
La demande CPU d’une VM est calculée en fonction du nombre de ressources processeur actuellement consommées par celle-ci. Les valeurs maximales et moyennes de CPU de la VM, collectées lors de la dernière vérification, aident le DRS à déterminer la tendance d’utilisation des ressources pour une VM donnée. Si vSphere DRS détecte un déséquilibre dans le cluster et que certains hôtes ESXi sont surchargés, alors le DRS lance la migration à chaud des VMs s’exécutant sur l’hôte surchargé vers un hôte disposant de ressources libres.
Voyons comment vSphere DRS fonctionne dans VMware à l’aide d’un exemple illustré par des schémas. Dans le schéma ci-dessous, vous pouvez voir un cluster DRS composé de 3 hôtes VMware ESXi. Tous les hôtes sont connectés à un stockage partagé, où se trouvent les fichiers des machines virtuelles. Le premier hôte est très sollicité, le deuxième hôte dispose de ressources processeurs et mémoire disponibles, et le troisième hôte est fortement sollicité. Certaines VMs sur les premier (VM1) et troisième (VM4, VM5) hôtes ESXi consomment la quasi-totalité des ressources processeurs et mémoire allouées. Dans ce cas, les performances de ces VMs peuvent se dégrader.
VMware DRS détermine que la solution rationnelle consiste à migrer la VM2, fortement sollicitée, de l’hôte VMware ESXi 1 surchargé vers l’hôte VMware ESXi 2, qui dispose de ressources libres suffisantes, et à migrer la VM4 de l’hôte VMware ESXi 3 vers l’hôte VMware ESXi 2. Si le DRS est configuré pour fonctionner en mode automatique, les VMs en cours d’exécution sont alors migrées via vMotion (cette action est illustrée par des flèches vertes dans l’image ci-dessous). Les fichiers des machines virtuelles, notamment les disques virtuels (VMDK), les fichiers de configuration (VMX) et les autres fichiers, se trouvent au même emplacement sur le stockage partagé pendant et après la migration des machines virtuelles (les liens entre les machines virtuelles et leurs fichiers sont illustrés par des lignes pointillées sur l’image).
Une fois les VM sélectionnées migrées, le cluster DRS est rééquilibré. Chaque hôte ESXi du cluster dispose de ressources libres pour exécuter efficacement les VM et garantir des performances élevées.
La situation peut évoluer en raison d’une répartition inégale des Workloads des machines virtuelles, et le cluster peut à nouveau se déséquilibrer. Dans ce cas, DRS vérifiera les ressources consommées et les ressources disponibles au sein du cluster afin de relancer la migration des machines virtuelles.
Paramètres clés pour la configuration de VMware vSphere DRS
VMware vSphere DRS est une fonctionnalité de clustering hautement personnalisable qui vous permet d’utiliser le DRS avec une plus grande efficacité dans différentes situations. Examinons les principaux paramètres qui influencent le comportement de DRS au sein d’un cluster vSphere.
VMware DRS niveaux d’automatisation
Lorsque DRS détecte un déséquilibre au sein d’un cluster vSphere, DRS fournit des recommandations concernant le placement et la migration des machines virtuelles via vMotion. Ces recommandations peuvent être mises en œuvre à l’aide de l’un des trois niveaux d’automatisation suivants :
Fully automated. Le placement initial des machines virtuelles et vMotion les recommandations sont appliquées automatiquement par DRS (aucune intervention de l’utilisateur n’est requise).
Partially automated. Seules les recommandations relatives au placement initial des nouvelles VMs sont appliquées automatiquement. Les autres recommandations peuvent être lancées et appliquées manuellement, ou ignorées.
Manual. DRS fournit des recommandations pour le placement initial et la migration des VMs, mais l’intervention de l’utilisateur est nécessaire pour les appliquer. Vous pouvez également ignorer les recommandations fournies par DRS.
DRS niveaux d’agressivité (seuils de migration)
DRS niveaux d’agressivité ou seuils de migration permettent de contrôler le niveau maximal de déséquilibre acceptable pour un DRS cluster. Il existe cinq valeurs de seuil, allant de 1 (la plus prudente) à 5 (la plus agressive).
Le paramètre « agressif » déclenche la migration des machines virtuelles même si le gain lié à leur placement est minime. Le paramètre « prudent » ne déclenche pas la migration des machines virtuelles, même si celle-ci permet d’obtenir des gains significatifs. Le niveau 3, qui correspond au niveau d’agressivité intermédiaire, est sélectionné par défaut et constitue le paramètre recommandé.
Règles d’affinité dans VMware DRS
Les règles d’affinité et d’anti-affinité sont utiles lorsque vous devez placer des VMs spécifiques sur des hôtes VMware ESXi spécifiques. Par exemple, vous pouvez avoir besoin d’exécuter certaines VMs ensemble sur un même hôte VMware ESXi au sein d’un cluster, ou inversement (vous avez besoin que deux VMs ou plus soient placées uniquement sur des hôtes VMware ESXi différents, et les VMs ne doivent pas être placées sur un même hôte). Voici quelques cas d’utilisation :
- Des VMs de contrôleur de domaine (un contrôleur de domaine principal et un contrôleur de domaine supplémentaire) sur des hôtes différents afin d’éviter la défaillance des deux VMs en cas de défaillance d’un hôte. Dans ce cas, ces VMs ne doivent pas s’exécuter ensemble sur un seul hôte ESXi.
- Des VMs exécutant des logiciels sous licence qui peuvent fonctionner sur le matériel approprié mais ne peuvent pas fonctionner sur d’autres ordinateurs physiques en raison de restrictions de licence (par exemple, la base de données Oracle).
Les règles d’affinité se divisent en :
- Règles d’affinité machine virtuelle-machine virtuelle (pour des machines virtuelles individuelles)
- Règles d’affinité machine virtuelle-hôte (relation entre des groupes d’hôtes et des groupes de machines virtuelles)
Les règles d’affinité machine virtuelle-hôte peuvent être préférentielles (les machines virtuelles doivent…) et obligatoires (la machine virtuelle doit…). Les règles obligatoires continuent d’être appliquées même si l’option « DRS » est désactivée, ce qui vous empêche de migrer manuellement les VMs concernées à l’aide de vMotion. Ce principe permet d’éviter toute violation de la règle appliquée aux VMs s’exécutant sur des hôtes ESXi en cas d’indisponibilité temporaire ou de défaillance de vCenter.
Il existe quatre options pour les règles d’affinité « DRS » :
« Keep virtual machines together ». Les VM sélectionnées doivent s’exécuter ensemble sur un seul hôte ESXi (si une migration de VM est nécessaire, toutes ces VM doivent être migrées ensemble). Cette règle peut être utilisée lorsque vous souhaitez localiser le trafic réseau entre les VM sélectionnées (pour éviter une surcharge du réseau entre les hôtes ESXi si les VM génèrent un trafic réseau important). Un autre cas d’utilisation consiste à exécuter une application complexe qui utilise des composants (dépendants les uns des autres) installés sur plusieurs VM ou à exécuter un vApp. Il peut s’agir, par exemple, d’un serveur de base de données et d’un serveur d’applications.
Machines virtuelles distinctes. La sélection des VM ne doit pas entraîner l’exécution sur un seul hôte ESXi. Cette option est utilisée à des fins de haute disponibilité.
Machines virtuelles par hôtes. Les VM ajoutées à un groupe de VM doivent s’exécuter sur l’hôte ESXi ou le groupe d’hôtes spécifié. Vous devez configurer DRS des groupes (groupes de machines virtuelles/d’hôtes). Un DRS groupe contient plusieurs machines virtuelles ou hôtes VMware ESXi.
Machines virtuelles vers machines virtuelles. Cette règle peut être sélectionnée pour lier des machines virtuelles à d’autres machines virtuelles lorsque vous souhaitez mettre sous tension un groupe de machines virtuelles, puis un autre groupe de machines virtuelles (dépendant). Cette option est utilisée lorsque VMware HA et DRS sont configurés conjointement dans le cluster.
En cas de conflit entre deux règles, c’est la règle la plus ancienne qui prévaut.
Remplacement de machine virtuelle pour VMware DRS
À l’instar de l’utilisation du remplacement de machine virtuelle dans un cluster vSphere HA , les remplacements de machine virtuelle sont utilisés pour des configurations plus granulaires de DRS dans VMware vSphere et vous permettent de remplacer les paramètres globaux définis au niveau du cluster DRS et de définir des paramètres spécifiques pour une machine virtuelle individuelle. Les autres VMs du cluster ne sont pas affectées lorsque le remplacement de machine virtuelle est appliqué à une machine virtuelle spécifique.
Predictive DRS
Le principe fondamental de Predictive DRS consiste à collecter des informations sur le placement des VMs, puis, sur la base des informations précédemment recueillies, à prédire quand et où une utilisation élevée des ressources aura lieu. À l’aide de ces informations, Predictive DRS peut déplacer des VMs d’un hôte à l’autre afin d’optimiser l’équilibrage de charge avant qu’un serveur ESXi ne soit surchargé et que les VMs ne manquent de ressources. Cette fonctionnalité peut s’avérer utile lorsque la demande des VMs d’un cluster varie en fonction du temps. Predictive DRS est désactivé par défaut. VMware vRealize Operations Manager est nécessaire pour utiliser Power DRS.
Distributed Power Manager
Distributed Power Manager (DPM) est une fonctionnalité permettant de migrer des VMs lorsqu’il y a suffisamment de ressources libres dans un cluster pour arrêter un hôte ESXi (le mettre en mode veille) et exécuter les VMs sur les hôtes ESXi restants du cluster (ces derniers devant disposer de ressources suffisantes pour exécuter les VMs concernées).
Lorsque davantage de ressources sont nécessaires dans un cluster pour faire fonctionner des VMs, DPM déclenche le réveil d’un serveur qui avait été arrêté afin qu’il fonctionne en mode normal. L’un des protocoles de gestion de l’alimentation pris en charge est utilisé pour mettre un hôte sous tension via le réseau. Ces protocoles sont Intelligent Platform Management Interface (IPMI), Hewlett-Packard Integrated Lights-Out (iLO)ou Wake-On-LAN (WOL). Ensuite, DRS migre certaines VMs vers ce serveur afin de répartir les Workloads et d’équilibrer le cluster. Par défaut, Distributed Power Management est désactivé. Les recommandations de DPM peuvent être appliquées automatiquement ou manuellement.
Storage DRS
Alors que DRS migre les VMs en fonction des ressources de calcul (processeurs et RAM), Storage DRS migre les fichiers des VMs d’un magasin de données à un autre en fonction de l’utilisation du magasin de données, par exemple l’espace disque disponible. Les règles d’affinité et d’anti-affinité vous permettent de configurer si Storage DRS doit stocker les fichiers de disque virtuel d’une VMs ensemble sur le même magasin de données. Par exemple, vous pouvez configurer la règle d’anti-affinité pour stocker les fichiers VMDK d’une machine virtuelle effectuant des opérations I/O intensives sur différents magasins de données. Cela permet d’éviter une dégradation des performances de la machine virtuelle et du magasin de données d’origine de celle-ci (I/O les Workloads des disques seront répartis sur plusieurs magasins de données lorsque vous utilisez la règle d’anti-affinité).
Storage DRS est utile lorsque vous utilisez des VMs avec des disques à allocation dynamique en cas de surprovisionnement. Storage DRS Cela permet d’éviter les situations où la taille des disques « thin » augmente, entraînant un manque d’espace libre sur un magasin de données. Le manque d’espace libre provoque la défaillance des VMs stockant des disques virtuels sur ce magasin de données. Les fichiers de disque des VMs peuvent être migrés d’un magasin de données vers un autre à l’aide de Storage vMotion alors que la VM est en cours d’exécution.
Surveillance de l’utilisation du processeur et de la mémoire
VMware offre la possibilité de surveiller l’utilisation des ressources dans l’interface Web de VMware vSphere Client. Vous pouvez surveiller l’utilisation du processeur au sein du cluster en accédant à Settings > Monitor > vSphere DRS > CPU Utilization. Il existe également d’autres options pour surveiller la mémoire et l’espace de stockage de chaque hôte VMware ESXi. La surveillance VMware est prise en charge dans NAKIVO Backup & Replication 10.5. Pour en savoir plus sur la surveillance de l’infrastructure, consultez l’article de blog.
Utilisation conjointe de VMware HA et DRS
VMware HA et DRS ne sont pas des technologies concurrentes. Ces deux technologies se complètent, et vous pouvez utiliser à la fois VMware DRS et HA dans un cluster VMware vSphere afin d’assurer la haute disponibilité des VMs et d’équilibrer les Workloads si celles-ci sont redémarrées par HA sur d’autres hôtes VMware ESXi. Il est recommandé d’utiliser ces deux technologies dans les clusters VMware vSphere fonctionnant en environnement de production pour bénéficier d’un basculement automatique et d’un équilibrage de charge.
Lorsqu’un hôte VMware ESXi tombe en panne, Basculement de machine virtuelle est déclenché par HA, et les VMs sont redémarrées sur d’autres hôtes. Dans cette situation, la priorité absolue est de rendre les VMs disponibles. Cependant, après la migration des VMs, certains hôtes VMware ESXi peuvent être surchargés, ce qui aurait un impact négatif sur les VMs s’exécutant sur ces hôtes. VMware DRS vérifie l’utilisation des ressources sur chaque hôte au sein d’un cluster et fournit des recommandations pour un placement optimal des VMs après un basculement. Vous avez ainsi toujours la garantie que les VMs disposent de ressources suffisantes après le basculement pour exécuter leurs Workloads avec des performances adéquates. En activant à la fois VMware DRS et HA , vous pouvez bénéficier d’un cluster plus efficace.
Conclusion
VMware fournit les puissantes fonctionnalités des clusters dans vSphere pour répondre aux besoins des clients vSphere les plus exigeants. Nous avons abordé les fonctionnalités VMware DRS et HA et expliqué le principe de fonctionnement ainsi que les principaux paramètres de chacune de ces fonctionnalités de clustering. Les fonctionnalités VMware DRS et HA se complètent mutuellement et améliorent le résultat final de l’utilisation d’un cluster.
Même si vous utilisez les fonctionnalités VMware DRS et HA, n’oubliez pas de sauvergarder vos VMs VMware dans VMware vSphere. Téléchargez NAKIVO Backup & Replication Free Edition pour VMware-Backup dans votre environnement.
