¶ Importance
Les Resource Pools vous permettent de déléguer le contrôle des ressources d’un hôte ou d’un cluster.
Les vSphere Cluster Services (vCLS) garantissent que si le vCenter devient indisponible, les services de cluster restent disponibles afin de maintenir les ressources et l’intégrité des workloads exécutés dans les clusters.
¶ Leçons du module
- Resource Pools
- vSphere Cluster Services (vCLS)
Voici la traduction fidèle de cette page, avec tes consignes appliquées :
- Titres et sous-titres traduits en français
- Termes techniques et VMware conservés en anglais
- Resource Pool non traduit
¶ Leçon 1 : Resource Pools
¶ Objectifs d’apprentissage
- Créer un Resource Pool
- Définir les attributs d’un Resource Pool
- Décrire les réservations extensibles
- Décrire les parts évolutives
¶ Réservations, limites et parts
Au-delà du CPU et de la mémoire configurés pour une VM, vous pouvez appliquer des paramètres d’allocation de ressources à une VM afin de contrôler la quantité de ressources accordées.
- Une reservation spécifie l’allocation minimale garantie pour une VM.
- Une limit spécifie une limite supérieure pour le CPU ou la mémoire pouvant être allouée à une VM.
- Une share est une valeur qui définit la priorité relative ou l’importance de l’accès d’une VM à une ressource donnée.
Si les ressources de l’hôte sont sur-engagées et que les charges de travail des VM sont élevées, une contention des ressources peut se produire.
Pour gérer efficacement les ressources, vSphere fournit des mécanismes permettant d’autoriser un accès moindre, supérieur ou égal à une ressource définie.
vSphere empêche également une VM de consommer de grandes quantités de ressources.
vSphere accorde une quantité garantie de ressources à une VM dont les performances ne sont pas suffisantes ou qui nécessite une certaine quantité de ressources pour fonctionner correctement.
Lorsque la mémoire de l’hôte ou le CPU commencent à être en contention, la cible d’allocation d’une VM se situe entre la reservation spécifiée et la limit définie, selon les shares de la VM et la charge du système.
vSphere utilise un algorithme d’allocation basé sur les shares pour garantir une utilisation efficace des ressources pour toutes les VMs et pour assurer la priorité d’allocation des ressources aux VMs qui en ont le plus besoin.
¶ Allocation de ressources : RAM
Reservations
- La mémoire réservée à une VM est garantie pour ne jamais utiliser le swap ou le balloon.
- Si un hôte ESXi ne dispose pas de suffisamment de RAM non réservée pour prendre en charge une VM avec une reservation, la VM ne démarre pas.
- Les reservations sont mesurées en MB, GB ou TB.
- La valeur par défaut est 0 MB.
Limits
- Les VMs ne consomment jamais plus de mémoire physique que celle spécifiée par l’unité d’allocation mémoire.
- Les VMs peuvent utiliser le mécanisme de swap (.vswp) si le guest OS tente de consommer plus de mémoire que la limit définie.
¶ Allocation de ressources : CPU
Reservations
- Le CPU réservé pour une VM est garanti pour être immédiatement planifié sur les cœurs physiques. La VM n’est jamais placée dans un état d’attente du CPU (CPU ready state).
- Si un hôte ESXi ne dispose pas de suffisamment de CPU non réservé pour prendre en charge une VM avec une reservation, la VM ne démarre pas.
- Les reservations sont mesurées en MHz ou GHz.
- La valeur par défaut est 0 MHz.
Limits
- Les VMs ne consomment jamais plus de CPU physique que ce qui est spécifié par l’unité d’allocation CPU.
- Les threads CPU sont placés en état d’attente (ready state) si le guest OS tente d’exécuter des threads plus rapidement que ce que la limit autorise.
¶ À propos des Resource Pools
Un resource pool est une abstraction logique des ressources CPU et mémoire gérées de manière hiérarchique.
- Standalone hosts each have their own root resource pool : Les hôtes autonomes possèdent chacun leur propre root resource pool
- Root Resource Pool : Root Resource Pool
- In a vSphere DRS cluster, the cluster is the root resource pool : Dans un cluster vSphere DRS, le cluster est le root resource pool
- Sibling Resource Pools : Resource Pools frères
- Parent Resource Pool : Resource Pool parent
- Child Resource Pool : Resource Pool enfant
Un resource pool est une abstraction logique utilisée pour gérer les ressources.
Les resource pools peuvent être regroupés en hiérarchies et utilisés pour partitionner de manière hiérarchique les ressources CPU et mémoire disponibles.
Dans l’exemple présenté sur la diapositive, RP-HR est le parent resource pool de RP-Testing-UI.
RP-Finance et RP-HR sont des siblings (frères).
Avec un resource pool, vous pouvez diviser et allouer des ressources aux machines virtuelles (VMs) et à d’autres resource pools.
Vous pouvez contrôler les ressources CPU et mémoire agrégées de la ressource de calcul.
La ressource de calcul peut être soit un hôte autonome, soit un cluster vSphere DRS.
Les resource pools servent également à déléguer des privilèges à d’autres utilisateurs et groupes.
Le resource pool le plus haut dans la hiérarchie est appelé root resource pool.
Chaque hôte autonome et chaque cluster vSphere DRS possèdent un root resource pool (invisible) qui regroupe les ressources de cet hôte ou cluster.
Le root resource pool n’apparaît pas, car ses ressources sont celles de l’hôte (ou du cluster), et ces deux entités sont toujours identiques.
¶ Raisons d’utiliser les Resource Pools
Avec les resource pools, vous pouvez déléguer le contrôle des ressources d’un hôte autonome ou d’un cluster vSphere DRS.
L’utilisation des resource pools peut offrir les avantages suivants :
-
Organisation hiérarchique flexible : Ajoutez, supprimez ou réorganisez des resource pools ou modifiez les allocations de ressources selon les besoins.
-
Isolement entre les pools et partage au sein des pools : Les administrateurs de niveau supérieur peuvent mettre à disposition un ensemble de ressources à un administrateur de département.
-
Contrôle d’accès et délégation : La création et la gestion des machines virtuelles (VMs) s’effectuent dans les limites des ressources auxquelles le resource pool a droit. La délégation se fait généralement par le biais des paramètres d’autorisation.
-
Séparation des ressources matérielles : Si vous utilisez VMware vSphere® Distributed Resource Scheduler™ (DRS), les ressources de tous les hôtes sont toujours attribuées au cluster.
-
Gestion d’ensembles de VMs exécutant un service multiniveau : Regroupez les VMs d’un service multiniveau dans un même resource pool.
¶ Attributs d’un Resource Pool
Vous pouvez créer un child resource pool à partir de n’importe quel hôte ESXi, resource pool, ou vSphere DRS cluster :
-
Shares : Low, Normal, High, Custom
-
Reservation : En MHz, GHz, MB ou GB
-
Type de réservation :
- Expandable (case cochée) : Les VMs et les sous-pools peuvent puiser dans les ressources du parent de ce pool.
- Expandable (case décochée) : Les VMs et les sous-pools ne peuvent puiser que dans les ressources de ce pool, même si le parent dispose de ressources libres.
-
Limit :
- En MHz, GHz, MB ou GB
- Accès illimité par défaut, jusqu’à la quantité maximale de ressources accessibles
Comme les VMs, les resource pools possèdent des valeurs de reservation, limit et shares pour les ressources CPU et mémoire :
- High Shares reçoit 8000 CPU
- Normal Shares reçoit 4000 CPU
- Low Shares reçoit 2000 CPU
(basé sur 16 GB de RAM et 4 vCPUs)
Les resource pools disposent également d’un paramètre qui permet d’étendre les reservations.
Avec cet attribut de reservation expandable, un resource pool qui ne peut pas satisfaire une demande de réservation peut rechercher dans sa hiérarchie une capacité non réservée afin de répondre à cette demande.
¶ Exemple de Resource Pool
Les attributs de ressources sont définis sur un resource pool.
¶ Exemple de Resource Pool : CPU Shares
Le Resource Pool Finance possède deux fois plus de CPU Shares que le Resource Pool Engineering.
Le Resource Pool Finance a donc droit à deux fois plus de ressources CPU que le Resource Pool Engineering.
Les resource pools peuvent être organisés hiérarchiquement.
Le root resource pool est le resource pool le plus haut dans la hiérarchie.
Il inclut la somme de tous les CPU (en MHz) et de toute la mémoire RAM (en Mo) disponibles dans l’environnement de calcul (hôte autonome ou cluster).
À l’exception du root resource pool, chaque resource pool a un parent resource pool.
Un resource pool parent peut contenir des resource pools enfants ou uniquement des machines virtuelles (VMs) actives dans ce pool.
Un resource pool enfant est utilisé pour allouer des ressources provenant du resource pool parent pour les consommateurs du pool enfant.
Le contrôle administratif peut également être délégué à des individus ou à des organisations.
Un resource pool enfant ne peut pas dépasser la capacité du resource pool parent.
En créant un resource pool enfant, vous réservez des ressources du pool parent, que les VMs du pool enfant soient allumées ou non.
Les shares indiquent la priorité ou l’importance relative d’un resource pool ou d’une VM.
Si un resource pool possède deux fois plus de shares qu’un autre, il est autorisé à consommer deux fois plus de cette ressource. La même logique s’applique aux VMs.
¶ Exemple de Resource Pool : Contention CPU
Le VMkernel a planifié toutes les machines virtuelles (VMs) sur le même processeur physique (CPU).
Ces VMs sont donc en concurrence directe les unes avec les autres.
L’exemple présenté dans cette diapositive utilise des approximations pour expliquer comment le nombre de shares influence la quantité de CPU attribuée à une VM.
L’hôte nommé Srv01 ne dispose que d’un seul processeur (CPU).
Le processeur n’est pas nommé Srv01 — ce nom correspond à celui de l’hôte ESXi.
Le Resource Pool Engineering reçoit environ 33 % du CPU total, qu’il répartit ensuite entre les VMs Eng-Test et Eng-Prod.
De même, le Resource Pool Finance reçoit environ 67 % du CPU total et divise cette part entre les VMs Fin-Test et Fin-Prod.
Les paramètres de ressources d’une VM sont limités par les ressources disponibles dans le Resource Pool auquel elle appartient.
La VM Eng-Test obtient environ 33 % de l’allocation CPU du Resource Pool Engineering (1,000 / (1,000 + 2,000) = 33 %).
Ce qui correspond à environ 11 % du CPU physique (33 % de 33 % ≈ 11 %).
Chaque VM obtient ainsi un pourcentage du CPU physique proportionnel à la part qui lui est attribuée dans son Resource Pool.
¶ À propos des réservations extensibles (Expandable Reservations)
-
Les réservations étendues ne sont pas libérées tant que la machine virtuelle (VM) à l’origine de cette extension n’est pas arrêtée ou que sa réservation n’est pas réduite.
-
L’emprunt de ressources se fait de manière récursive à partir des ancêtres du Resource Pool actuel :
- L’option Expandable Reservation doit être activée.
- Cette option offre plus de flexibilité, mais moins de protection.
REMARQUE : Une réservation extensible mal configurée ou mal dimensionnée peut consommer toute la capacité non réservée.
Dans cet exemple, eCommerce Apps est un Resource Pool enfant extensible.
La réservation d’un Resource Pool enfant ne peut pas dépasser celle de son parent.
La recherche de ressources non utilisées remonte la hiérarchie du Root Resource Pool, ou jusqu’au premier Resource Pool dont le type de réservation extensible n’est pas activé.
Utilisez les réservations extensibles avec précaution.
Un seul Resource Pool enfant peut consommer toutes les ressources disponibles de son parent, ne laissant rien de disponible pour d’autres Resource Pools enfants.
Ce problème peut survenir si des VMs sont déplacées de manière incorrecte pour démarrer en fonction des réservations de ressources.
Vous pouvez désactiver le type de réservation extensible (Expandable Reservation Type) lorsque vous configurez une quantité fixe de ressources pour un groupe.
Par exemple, un administrateur IT dont les clients sont différentes organisations au sein d’une entreprise ayant payé pour une quantité fixe de CPU et de mémoire pourrait choisir de désactiver le type de réservation extensible.
¶ Exemples de réservation extensible
¶ Premier exemple
Les resource pools eCommerce réservent 2 200 MHz sur les 3 000 MHz que le Retail Pool a réservés.
Vous mettez sous tension des VMs dans le eCommerce Web Pool.
Avec l’option Expandable Reservation désactivée sur le eCommerce Web Pool, la VM3 ne peut pas démarrer avec une réservation de 500 MHz.
Les solutions possibles sont :
- Réduire la réservation de la VM.
- Activer Expandable comme type de réservation (Reservation Type).
- Augmenter la réservation du eCommerce Web Pool.
¶ Deuxième exemple
Le type de réservation extensible (Expandable Reservation Type) est activé sur le eCommerce Web Pool.
Le système prend en compte les ressources disponibles dans le child resource pool et dans son parent resource pool direct.
La réservation de la VM est déduite de la réservation du eCommerce Web Pool.
La réservation du eCommerce Web Pool est elle-même déduite de la réservation du Retail Pool.
¶ Onglet Résumé du Resource Pool
L’onglet Summary du resource pool affiche les informations qui s’appliquent à l’hôte ESXi et à ses ressources.
Cet onglet fournit des informations importantes :
- Le panneau Resource Settings affiche les paramètres de partage du CPU et de la mémoire.
- Le panneau Resource Consumers affiche le nombre de VMs, le nombre de VMs sous tension (powered-on) et les child resource pools présents dans le resource pool sélectionné.
- Le panneau Tags affiche les tags attribués aux objets qui résident dans le resource pool.
¶ Détails de la Réservation des Ressources
Dans le vSphere Client, vous pouvez consulter les informations relatives au CPU, à la mémoire et aux ressources de stockage d’un resource pool.
Pour les ressources CPU et mémoire du resource pool, les informations suivantes sont fournies :
- La quantité de CPU et de mémoire réservée qui est configurée
- Le type de réservation utilisé (expandable ou fixe)
- La quantité de réservation utilisée par les VMs et les child pools
- La quantité de CPU et de mémoire disponible pour être réservée
¶ Partages de Resource Pool
Un resource pool est une abstraction logique de ressources CPU et mémoire gérées de manière hiérarchique.
Les partages (shares) définissent la priorité du resource pool par rapport aux autres resource pools.
Les resource pools peuvent être organisés de manière hiérarchique.
Le root resource pool (pool racine) est le resource pool le plus haut dans la hiérarchie.
Le root resource pool comprend la somme de tous les CPU (en mégahertz) et la somme de toute la mémoire installée (en mégaoctets) disponible dans l’environnement de calcul (hôte autonome ou cluster).
Un child resource pool (pool enfant) est utilisé pour allouer des ressources à partir du parent resource pool (pool parent) aux consommateurs du pool enfant. Un child resource pool ne peut pas dépasser la capacité de son parent resource pool. En créant un child pool, vous réservez des ressources à partir du parent pool.
Dans l’exemple, le root resource pool est Cluster-A.
Cluster-A possède deux child resource pools : le Engineering pool et le Finance pool.
Les shares spécifient la priorité ou l’importance relative d’un resource pool.
Dans l’exemple, vous souhaitez que les VMs du Finance pool aient deux fois plus de temps processeur que celles du Engineering pool.
Vous pouvez configurer le Finance pool avec deux fois plus de CPU shares que le Engineering pool.
Vous pouvez également définir des shares par VM et distribuer l’allocation des ressources à l’intérieur d’un resource pool.
Les VM shares sont relatives uniquement à d’autres VMs allumées au sein du même resource pool.
Dans l’exemple, toutes les VMs ont un nombre égal de shares.
Cependant, les VMs du Finance pool ont droit à environ 67 % du temps processeur du cluster.
Chaque VM du Finance pool obtient donc environ 33 % des ressources CPU totales du cluster, soit deux fois plus que les VMs du Engineering pool.
¶ Partages dilués
Lorsque vous mettez sous tension davantage de machines virtuelles (VM) dans un resource pool, vous pouvez diluer l’allocation de ressources attribuée à chaque VM de ce pool.
Lorsque vous mettez sous tension des VMs supplémentaires dans un pool de ressources, l’allocation de ressources par VM est recalculée en fonction de la valeur configurée pour les shares.
Dans l’exemple, deux VM supplémentaires sont mises sous tension dans le Finance pool. Toutes les VM du cluster ont un nombre égal de shares. Par conséquent, les ressources sont réparties entre les quatre VMs.
Comme les VMs du Finance pool ont droit à environ 67 % du temps processeur du cluster, chaque VM du Finance pool reçoit environ 17 % des ressources CPU totales du cluster.
La valeur des shares au sein du Finance pool est donc diluée et n’est plus deux fois supérieure à celle des VM du Engineering pool.
¶ À propos des Scalable Shares
Introduit dans vSphere 7, vous pouvez activer les scalable shares afin d’augmenter ou de diminuer dynamiquement les shares des "pools de ressources frères" et de maintenir le ratio d’allocation des ressources.
Lorsque vous activez les scalable shares sur un pool de ressources, tous les child resource pools conservent le ratio de shares initialement configuré dans le parent pool.
Dans l’exemple, vous activez les scalable shares sur Cluster-A pour ajuster dynamiquement l’allocation des ressources des child resource pools.
Toutes les VM ont un nombre égal de shares, de sorte que la configuration des shares des child resource pools s’ajuste pour donner à chaque VM du Finance pool deux fois plus de ressources qu’aux VM du Engineering pool.
La configuration des shares des child resource pools s’ajuste donc à 80 % pour le Finance pool et à 20 % pour le Engineering pool.
Chaque VM du Finance pool obtient 20 % du temps processeur du Cluster-A, et les VM du Engineering pool obtiennent 10 %.
La fonctionnalité des scalable shares rend les child resource pools évolutifs :
- DRS augmente et diminue dynamiquement les shares des resource pools pour maintenir un ratio d’allocation des ressources.
- L’algorithme des scalable shares maintient le ratio d’allocation des ressources en additionnant les shares de toutes les entités du resource pool et en les multipliant par la valeur initiale des shares définie par l’utilisateur.
- Les scalable shares rendent le child resource pool évolutif, mais ne rendent pas le parent resource pool évolutif.
¶ Activation des Scalable Shares
Vous pouvez activer les scalable shares au niveau du cluster ou du resource pool.
L’allocation des ressources des child resource pools devient alors évolutive.
¶ Lab 5 : Gestion des Resource Pools
Créez et utilisez des resource pools :
- Reconfigurer les machines virtuelles (VMs)
- Créer une contention CPU
- Créer des resource pools
- Vérifier le bon fonctionnement des resource pools
- Vérification des connaissances
Retrouvez le lien du Lab en cliquant ici : Lab 5 : Accéder à l'environnement de lab
¶ Revue des objectifs d’apprentissage
- Créer un resource pool
- Définir les attributs d’un resource pool
- Décrire les réservations extensibles (expandable reservations)
- Décrire les scalable shares
¶ Leçon 2 : vSphere Cluster Service (vCLS)
¶ Objectifs d’apprentissage
- Décrire les machines virtuelles vCLS
- Identifier les flux de travail vCLS
- Décrire la fonction du vCLS
- Reconnaître les opérations pouvant perturber le bon fonctionnement des machines virtuelles vCLS
¶ À propos de vCLS
Le vCLS déploie des machines virtuelles vCLS (vCLS VMs) sur chaque cluster vSphere.
Les vCLS VMs sont déployées dans un cluster lors de sa création et après l’ajout d’hôtes au cluster. Dans une future version, les vCLS VMs fourniront les services vCLS (vSphere HA et vSphere DRS) aux charges de travail, même si vCenter est hors ligne.
Les vCLS VMs sont également déployées sur les clusters vSphere existants après la mise à jour de vCenter vers la version 7.0 Update 1.
Le vSphere Distributed Resource Scheduler (vSphere DRS) ne peut pas fonctionner si les vCLS VMs ne sont pas présentes dans le cluster vSphere.
Les vCLS VMs s’exécutent dans chaque cluster, même si les services de cluster tels que vSphere DRS ou vSphere HA ne sont pas activés sur le cluster.
Le nombre de vCLS VMs dépend du nombre d’hôtes ESXi présents dans un cluster.
| Nombre d’hôtes dans un cluster | Nombre de vCLS VMs |
|---|---|
| 1 | 1 |
| 2 | 2 |
| 3 ou plus | 3 |
Le cluster vSphere affiche un message d’alerte si les vCLS VMs saines (fonctionnelles) ne sont pas disponibles dans le cluster.
¶ Composants vCLS
Le vCLS introduit vCLS Manager et vCLS Resource Manager.
Chaque composant vCLS remplit une fonction unique :
- ESX Agent Manager (EAM) :
— Déploie les vCLS VMs sur les hôtes ESXi dans le cluster vSphere.
— Reçoit les informations de placement des machines virtuelles depuis le vCLS Resource Manager. - vCLS Manager :
— Nouveau module exécuté dans le service wcpsvc
— Gère et surveille une agence vSphere ESX Agent Manager pour chaque ensemble de vCLS VMs
— Conserve les informations de l’agence EAM dans la base de données vCenter
— Personnalise chaque vCLS VM lors du déploiement
— Effectue la rotation des mots de passe pour les vCLS VMs
— Fonctionne selon un modèle d’état souhaité - vCLS Resource Manager :
— Nouveau module exécuté dans le service vmware-vpxd
— Gère le placement initial et le placement de basculement des vCLS VMs - vCLS OVF :
— Modèle OVF de machine virtuelle pour les vCLS VMs
— Stocké dans le répertoire :/storage/lifecycle/vmware-hdcs/dans vCenter
— Les correctifs et mises à jour de vCenter peuvent contenir des versions mises à jour de l’OVF.
EAM déploie les nouvelles vCLS VMs mises à jour dans le cluster, puis supprime les anciennes vCLS VMs obsolètes.
¶ À propos des vCLS VMs
Les vCLS VMs sont présentes dans chaque cluster vSphere.
Les vCLS VMs possèdent les caractéristiques suivantes :
- Gérées par vCenter
- Ne possèdent pas de carte réseau (NIC) ni d’adresse IP assignée
- Déployées sur un datastore partagé lorsque cela est possible
- Configurées avec 1 vCPU, 128 Mo de mémoire et un disque de 2 Go en thin provisioning
- Exécutent une installation minimale de Photon OS
Une vCLS VM est déployée à partir d’un OVF avec un profil minimal installé de Photon OS.
vCLS Manager gère les ressources, l’état d’alimentation et la disponibilité de ces VMs.
Les vCLS VMs sont nécessaires pour maintenir la santé et la disponibilité de vSphere HA et DRS.
Toute incidence sur l’alimentation ou les ressources de ces VMs peut altérer la santé du vCLS et entraîner l’arrêt du fonctionnement de vSphere DRS dans le cluster.
La modification des vCLS VMs n’est pas prise en charge.
Les vCLS VMs sont visibles dans l’onglet VMs de l’hôte ou du cluster, dans l’onglet VM and Templates, ou lors d’une connexion directe à un hôte ESXi via VMware Host Client.
Lorsque aucun datastore partagé n’est disponible, les vCLS VMs sont déployées sur des datastores locaux.
Avec vSphere 7 Update 3, les vCLS agent VMs actuellement exécutées sur un stockage local ou sur un datastore non présent dans la liste autorisée des vCLS sont migrées, à l’aide de Storage vMotion, vers un datastore autorisé configuré par l’utilisateur.
Les vCLS VMs sont automatiquement rallumées par vCenter si elles ont été arrêtées manuellement.
Dans le vSphere Client, les vCLS VMs ne sont pas visibles dans l’arborescence d’inventaire de la vue Hosts and Clusters.
Vous pouvez consulter ces machines virtuelles depuis l’onglet VMs dans la vue Hosts and Clusters.
Vous pouvez également afficher les vCLS VMs à partir de la vue VMs and Templates.
Introduit dans vSphere 7 Update 3, les vCLS VMs possèdent désormais un nom unique basé sur leur UUID.
¶ À propos de l’agence EAM
Le cycle de vie des vCLS agent VMs est géré par le vSphere ESX Agent Manager (EAM).
Dans le vSphere Client, sélectionnez Administration > vCenter Server Extensions > vSphere ESX Agent Manager (EAM) pour afficher les agences ESX.
L’agence vCLS est ajoutée automatiquement et ne nécessite aucune configuration.
¶ Workflow de création d’un cluster vCLS
Le vCLS Manager déploie des vCLS VMs lorsqu’un nouveau cluster vSphere est créé.
- Un administrateur vSphere crée un cluster vSphere.
- Le vCLS Manager crée une agence vSphere ESX Agent Manager (EAM) associée au cluster vSphere.
- L’administrateur vSphere ajoute un hôte ESXi au cluster.
- EAM déploie une vCLS VM sur l’hôte ESXi.
Des vCLS VMs supplémentaires sont déployées à mesure que d’autres hôtes ESXi sont ajoutés au cluster vSphere.
Un maximum de trois vCLS VMs sont déployées et maintenues dans un seul cluster vSphere.
¶ Workflow de mise à niveau des vCLS d’un cluster
Le vCLS met automatiquement à jour les vCLS VMs lorsque de nouvelles mises à jour du modèle vCLS OVF deviennent disponibles.
Lorsqu’une nouvelle mise à jour du modèle vCLS OVF devient disponible :
-
Un administrateur vSphere met à jour ou applique un correctif à vCenter.
La mise à jour inclut une nouvelle version du modèle vCLS OVF. -
Le vCLS Manager détecte la nouvelle version du modèle vCLS OVF et met à jour l’agence EAM.
-
EAM lance la mise à niveau des vCLS VMs :
a. Une nouvelle vCLS VM est déployée et mise sous tension.
b. L’ancienne vCLS VM est arrêtée et supprimée.
Ce processus se répète jusqu’à ce que toutes les vCLS VMs soient remplacées par de nouvelles versions.
¶ Déplacement des hôtes ESXi entre clusters
Le vCLS garantit automatiquement l’état souhaité de chaque agence EAM dans un cluster vSphere.
Par exemple :
-
Un administrateur vSphere déplace un hôte d’un cluster vSphere vers un autre cluster vSphere.
-
Si des vCLS VMs se trouvent sur l’hôte, elles sont supprimées lorsque l’hôte est ajouté au cluster vSphere de destination.
-
L’agence EAM pour le cluster vSphere source et le cluster de destination est mise à jour.
-
De nouvelles vCLS VMs sont déployées sur l’hôte lorsqu’il est ajouté au cluster vSphere de destination, si nécessaire, pour satisfaire les exigences de l’agence EAM.
Si un hôte ESXi, exécutant des vCLS VMs, est déplacé d’un environnement vCenter 7.0 Update 1 vers un environnement vCenter 7.0 ou antérieur, les vCLS VMs doivent être arrêtées et supprimées manuellement.
¶ Fonctions de vCLS
Le vCLS garantit que les services de cluster tels que vSphere DRS et vSphere HA sont tous disponibles afin de maintenir les ressources et la santé des charges de travail exécutées dans les clusters, indépendamment de la disponibilité de l’instance vCenter.
Introduit dans vSphere 7.0 Update 3, il est désormais possible de configurer :
- Datastores préférés pour les vCLS VMs
- Anti-affinité pour les vCLS VMs avec certaines autres machines virtuelles
¶ Maintenir la santé de vCLS
Les machines virtuelles vCLS (vCLS VMs) sont toujours sous tension, car vSphere DRS dépend de leur disponibilité.
Seuls les administrateurs peuvent effectuer certaines opérations sélectives sur les vCLS VMs.
Pour éviter toute défaillance des services de cluster, il est recommandé d’éviter toute configuration ou opération sur les vCLS VMs.
Les vCLS VMs sont protégées contre la suppression accidentelle.
Les opérations suivantes peuvent perturber le bon fonctionnement des machines virtuelles vCLS (vCLS VMs) :
- Changer l’état d’alimentation des vCLS VMs
- Reconfigurer les ressources des vCLS VMs
- Supprimer les vCLS VMs du disque
- Chiffrer une VM
- Déplacer une vCLS VM vers un autre dossier
- Renommer les dossiers vCLS
- Activer la stratégie de contrôle d’admission HA sur les vCLS VMs
- Déplacer les vCLS VMs vers un resource pool
- Restaurer les vCLS VMs à partir d’un snapshot
- Modifier le BIOS
- Supprimer les vCLS VMs de l’inventaire
- Configurer la mémoire persistante (PMem)
- Cloner les vCLS VMs
- Renommer les vCLS VMs
- Activer des règles ou exceptions DRS sur les vCLS VMs
- Activer des exceptions HA sur les vCLS VMs
¶ Mode de repli (Retreat Mode)
Il n’existe aucun moyen de désactiver vCLS dans un cluster vSphere tout en maintenant le fonctionnement de vSphere DRS sur ce cluster.
Cependant, si nécessaire, il est possible de désactiver vCLS sur un cluster en activant le mode de repli (Retreat Mode).
Par exemple, lorsqu’un datastore est placé en mode maintenance, si ce datastore héberge des vCLS VMs, vous devez déplacer manuellement les vCLS VMs vers un autre emplacement à l’aide de vMotion, ou placer le cluster en mode de repli.
Impacts sur votre cluster vSphere :
- vSphere DRS ne fonctionnera pas sur ce cluster si DRS est activé.
- vSphere HA n’effectuera pas un placement optimal en cas de défaillance d’un hôte, car HA dépend de DRS pour les recommandations de placement.
¶ Activer le mode de repli (Retreat Mode)
Pour placer un cluster en mode de repli (Retreat Mode) :
- Accédez au cluster sur lequel vCLS doit être désactivé.
- Copiez l’ID du domaine du cluster depuis l’URL du navigateur. Il doit ressembler à :
domain-c<numéro> - Allez dans l’onglet Configure du vCenter.
- Sous Advanced Settings, cliquez sur le bouton Edit Settings.
- Ajoutez une nouvelle entrée :
config.vcls.clusters.domain-c<numéro>.enabled
(Utilisez l’ID du domaine copié à l’étape 2.) - Définissez la valeur sur False.
- Cliquez sur Save.
¶ Dépannage des fichiers journaux (Log Files)
Les fichiers journaux liés aux tâches vCLS se trouvent à différents emplacements sur le vCenter.
| Composant | Emplacement |
|---|---|
| ESX Agent Manager | |
eam.log |
/var/log/vmware/eam/ |
| vCLS Manager | |
wcpsvc.log |
/var/log/vmware/wcp/ |
Le mot de passe root pour les machines virtuelles vSphere Cluster Service (vCLS VMs) peut être extrait en exécutant le script suivant à partir d’une session SSH root sur vCenter : /usr/lib/vmware-wcp/decrypt_clustervm_pw.py. L’interface de la console VM est utilisée pour accéder aux vCLS VMs.
Pour garantir la santé des services de cluster, évitez d’accéder directement aux vCLS VMs. Ce document est destiné à fournir des informations de diagnostic explicites sur les vCLS VMs.
¶ Lab 6 : Activation du mode de repli (vCLS Retreat Mode)
Activez le mode de repli vCLS sur un cluster vSphere :
- Vérifiez l’ID du domaine du cluster
- Activez le mode de repli vCLS et surveillez les vCLS VMs
- Rétablissez les modifications
Retrouvez le lien du Lab en cliquant ici : Lab 6 : Accéder à l'environnement de lab
¶ Revue des objectifs d’apprentissage
- Décrire les machines virtuelles vCLS VMs
- Identifier les workflows vCLS
- Décrire la fonction du vCLS
- Reconnaître les opérations susceptibles de perturber le bon fonctionnement des vCLS VMs
¶ Points clés
- Un pool de ressources est une abstraction logique de ressources CPU et mémoire gérées de manière hiérarchique.
- Les machines virtuelles vSphere Cluster Service (vCLS VMs) sont déployées dans un cluster lors de sa création, ainsi qu’après l’ajout d’hôtes au cluster.
Chapitre précédent : 2 - Opérations de machines virtuelles - Chapitre suivant : 4 - Opérations réseau