Menu
InformatiWeb Pro
  • Index
  • Admin système
  • Virtualisation

Connexion

Inscription Mot de passe perdu ?
US
  • Windows Server
    • WMS 2012
    • WS2012 R2
    • WS2016
  • Citrix
    • Citrix NetScaler Gateway
    • Citrix XenApp / XenDesktop
    • Citrix XenServer
  • VMware
    • VMware ESXi
    • VMware vSphere
    • VMware Workstation
  • Microsoft
    • Hyper-V
  • RAID
    • Adaptec SmartRAID
  • UPS
    • APC Back-UPS Pro
  • InformatiWeb Pro
  • Virtualisation
  • VMware
  • Activer vSphere DRS sur un cluster pour automatiser la gestion des ressources dans une infrastructure VMware vSphere 6.7

Activer vSphere DRS sur un cluster pour automatiser la gestion des ressources dans une infrastructure VMware vSphere 6.7

  • VMware
  • VMware vCenter Server (VCSA), VMware vSphere
  • 26 février 2025 à 15:22
  • InformatiWeb
  • 2/2
Page précédente

6. Règles d'affinité et anti-affinité DRS

6.1. Règles d'affinité DRS préférentielles

Grâce à DRS, vous pouvez définir des règles d'affinité et d'anti-affinité en tant que préférence ou en tant que nécessité.

Dans ce 1er exemple, vous indiquez à DRS que vous préférez que les machines virtuelles du groupe A s'exécutent sur le groupe d'hôte "Blade Chassis A".
Pour les machines virtuelles du groupe B, celles-ci devront s'exécuter sur le groupe d'hôte "Blade Chassis B".

Ce qui signifie qu'en cas de panne des hôtes du groupe d'hôtes "Blade Chassis A", les machines virtuelles pourront être redémarrées sur un autre groupe d'hôtes pour assurer la disponibilité des services hébergés par ces machines virtuelles.

6.2. Règles d'affinité DRS exigées

Dans ce 2ème exemple, vous indiquez à DRS que les machines virtuelles du groupe A doivent s'exécuter uniquement sur le groupe d'hôtes "ISV-Licensed".
Dans le cas où les hôtes du groupe "ISV-Licensed" tombent en panne, les machines virtuelles du groupe A ne pourront pas être redémarrées sur d'autres groupes d'hôtes.
Les services hébergés sur les machines virtuelles de ce groupe A ne seront donc plus disponibles.

Ce type de règle (nécessité) est donc utilisé principalement pour éviter des problèmes de licences.
En effet, certains fabricants sont intransigeants dans le respect des licences. Dans le cas où la VM est migrée vers un autre groupe d'hôtes, les conditions de la licence de la solution que vous utilisez dans une de vos VMs risquent de ne plus être respectées.

6.3. Ajouter un groupe de VMs

Comme expliqué précédemment, les règles sont appliquées grâce à des groupes de VMs et des groupes d'hôtes.
Pour commencer, sélectionnez votre cluster et allez dans : Configurer -> Configuration -> Groupes de VM/Hôte.
Ensuite, cliquez sur : Ajouter.

Dans la fenêtre "Créer un groupe de VM/hôtes" qui s'affiche, indiquez un nom pour ce groupe de VMs et sélectionnez "Groupe de VM" comme type.
Ensuite, cliquez sur : Ajouter.

Sélectionnez les machines virtuelles que vous souhaitez ajouter dans ce groupe et cliquez sur OK.
Dans notre cas, nos machines virtuelles sous Windows 10.

Cliquez sur OK.

Le groupe de VMs ajouté apparait dans la liste "Groupes de VM/Hôte".

6.4. Ajouter un groupe d'hôtes

Maintenant, cliquez à nouveau sur : Ajouter.

Dans la fenêtre "Créer un groupe de VM/hôtes" qui s'affiche, indiquez un nom pour ce groupe d'hôtes et, cette fois-ci, sélectionnez "Groupe d'hôtes" comme type.
Ensuite, cliquez sur : Ajouter.

Pour cet exemple, nous sélectionnerons qu'un hôte, car nous n'avons que 2 pour ce tutoriel.
Une fois l'hôte ou les hôtes souhaités sélectionnés, cliquez sur OK.

Cliquez sur OK.

Le groupe d'hôtes ajouté apparait.

6.5. Ajouter une règle de VM/hôte

Dans la section "Règles de VM/hôte", cliquez sur : Ajouter.

Dans la fenêtre "Créer une règle de VM/hôte" qui s'affiche, indiquez un nom pour cette règle et cochez la case "Activer la règle".
Pour le type de règle, vous aurez le choix entre :

  • Garder les machines virtuelles ensemble : permet de toujours exécuter les machines virtuelles ajoutées à la liste sur le même hôte.
    Exemple : exécuter des machines virtuelles qui communiquent beaucoup entre-elles via le réseau sur le même hôte pour privilégier le réseau interne.
    Ce qui est plus performant et ce qui évite de saturer la bande passante du réseau physique.
  • Séparer les machines virtuelles : permet de toujours exécuter les machines virtuelles ajoutées à la liste sur des hôtes différents.
    Exemple : exécuter des machines virtuelles dont les données sont répliquées entre-elles pour qu'une VM soit toujours disponible sur un hôte fonctionnel, alors que l'autre VM était peut-être sur un hôte qui est tombé en panne.
  • Machines virtuelles aux hôtes : permet d'indiquer si les machines virtuelles d'un groupe de VM spécifique s'exécutent toujours ou de préférence s'exécuter sur un groupe d'hôtes spécifique.
  • Machines virtuelles à machines virtuelles : permet d'indiquer une condition de redémarrage de dépendance de cluster.
    Autrement dit, les machines virtuelles du 1er groupe de VM sélectionné devront être redémarrées avant que les machines virtuelles du 2ème groupe de VMs ne soient redémarrées.

Dans notre cas, nous allons créer une règle de type "Machines virtuelles aux hôtes".

Sources :

  • Utilisation de règles d'affinité DRS - VMware Docs
  • Créer une règle d'affinité machine virtuelle/hôte - VMware Docs
  • VMware vSphere Metro Storage Cluster Recommended Practices

Dans ce cas, vous devrez sélectionner :

  • Groupe de VM : le groupe de VMs souhaité.
  • Affinité :
    • Doit s'exécuter sur des hôtes en groupe : les VMs du groupe de VM souhaité devront toujours s'exécuter sur le groupe d'hôte souhaité.
    • Devrait s'exécuter sur des hôtes en groupe : les VMs du groupe de VM souhaité s'exécuteront de préférence sur le groupe d'hôte souhaité, mais celles-ci pourront être migrées vers un autre groupe d'hôtes si besoin (en cas de panne des hôtes du groupe d'hôte source, par exemple).
    • Ne doit pas s'exécuter sur des hôtes en groupe : les VMs du groupe de VM souhaité ne s'exécuteront jamais sur le groupe d'hôte souhaité.
    • Ne devrait pas s'exécuter sur des hôtes en groupe : les VMs du groupe de VM souhaité s'exécuteront de préférence sur d'autres hôtes que le groupe d'hôte souhaité, mais celles-ci pourraient s'exécuter sur le groupe d'hôte sélectionné si cela est nécessaire.
  • Groupe d'hôtes : le groupe d'hôtes souhaité.

Dans notre cas, nous souhaitons que nos machines virtuelles sous Windows 10 s'exécutent de préférence sur notre hôte "esxi1" qui fait partie de notre groupe d'hôtes "ESXi 1 host".

La règle de VM/hôte ajoutée apparait
Si vous la sélectionnez, vous pourrez voir les machines virtuelles et les hôtes concernés par cette règle, ainsi qu'une description indiquant ce que cette règle implique.

Important : si DRS détecte des conflits entre différentes règles de VM/hôte, vous verrez le nombre dans la colonne "Conflits" augmenter.
Par contre, sachez aussi que les règles ne s'appliquent que lorsque les machines virtuelles sont sous tension (démarrées).
Autrement dit, un conflit se produit entre 2 règles de VM/hôte, mais que les machines virtuelles concernées par ces règles sont éteintes, le conflit ne sera pas détecté.
Le conflit n'apparaitra que lorsque les machines virtuelles concernées seront sous tensions.

6.6. Séparer des machines virtuelles sur différents hôtes (exemple)

Maintenant que vous savez à quoi correspondent les différentes options et comment mettre en place vos propres règles DRS, voici un petit exemple.

Dans un précédent tutoriel, nous avions déployé la solution StarWind Virtual SAN sous VMware vSphere.
Ce qui impliquait de déployer 2 machines virtuelles StarWindVSA vSphere. Une machine virtuelle par hôte.

En effet, il s'agit de serveurs de stockage accessibles en iSCSI, dont les données sont répliquées d'une machine virtuelle à l'autre.
Autrement dit, le stockage partagé StarWind Virtual SAN accessible via le protocole iSCSI est disponible via n'importe laquelle de ces 2 machines virtuelles.

Dans ce cas-ci, vous comprendrez aisément qu'il est impératif de signaler à DRS de toujours séparer ces machines virtuelles sur différents hôtes de votre cluster.
Ainsi, si un hôte tombe, l'autre machine virtuelle "StarWind VSA vSphere" est toujours fonctionnelle et le stockage partagé reste disponible comme si de rien n'était.
Ce qui ne serait pas le cas si les 2 machines virtuelles StarWind VSA vSphere se retrouvaient sur le même hôte par accident. (Une migration d'une VM StarWind serait au moins nécessaire pour qu'une machine virtuelle StarWindVSA vSphere soit de nouveau fonctionnelle.)

Pour que le stockage StarWind Virtual SAN soit toujours disponible, même en cas de panne d'un de nos hôtes, nous sélectionnons notre cluster VMware vSphere et nous allons dans : Configurer -> Configuration -> Règles de VM/hôte.
Ensuite, nous cliquons sur : Ajouter.

Dans la fenêtre "Créer une règle de VM/hôte" qui s'affiche, nous spécifions :

  • Nom : StarWind VSA VMs.
  • Activer la règle : nous cochons la case pour activer cette règle.
  • Type : Séparer les machines virtuelles.
  • Membres : nous cliquons sur "Ajouter" et nous ajoutons nos machines virtuelles "StarWindVSA vSphere X".

Comme vous pouvez le voir, VMware vous indique que les machines virtuelles répertoriées doivent s'exécuter sur des hôtes différents.

Nous cliquons sur OK.

La nouvelle règle créée apparait.

Partager ce tutoriel

Partager
Tweet

A voir également

  • VMware ESXi 6.7 - Fonctionnement de la gestion de la mémoire (RAM)

    VMware 7/4/2023

    VMware ESXi 6.7 - Fonctionnement de la gestion de la mémoire (RAM)

  • VMware vSphere 6.7 - Ajouter une source d'identité Active Directory

    VMware 31/7/2024

    VMware vSphere 6.7 - Ajouter une source d'identité Active Directory

  • VMware vSphere 6.7 - Créer une pile TCP/IP personnalisée (pour NFS)

    VMware 20/9/2024

    VMware vSphere 6.7 - Créer une pile TCP/IP personnalisée (pour NFS)

  • VMware vSphere 6.7 - Migrer VMs via vMotion (renommer fichiers VMs)

    VMware 15/11/2024

    VMware vSphere 6.7 - Migrer VMs via vMotion (renommer fichiers VMs)

Commentaires

Pas de commentaire

Donnez-nous votre avis

Contenu épinglé

  • Logiciels (Admin système)
  • Logiciels Linux
  • Nos programmes
  • Conditions générales
  • Donnez votre avis

Contact

  • Livre d'or
  • Support technique
  • Contact

® InformatiWeb-Pro.net - InformatiWeb.net 2008-2022 - © Lionel Eppe - Tous droits réservés.

Toute reproduction totale ou partielle de ce site est interdite et constituerait une contrefaçon sanctionnée par les articles L.335-2 et suivants du Code de la propriété intellectuelle.