VMWARE vSphere - 6.5 User’s Manual [fr]
Disponibilité vSphere
Mise à jour 1
VMware vSphere 6.5
VMware ESXi 6.5
vCenter Server 6.5
Disponibilité vSphere
Vous trouverez la documentation technique la plus récente sur le site Web de VMware à l'adresse :
hps://docs.vmware.com/fr/
Le site Web de VMware propose également les dernières mises à jour des produits.
N’hésitez pas à nous transmettre tous vos commentaires concernant cette documentation à l’adresse suivante :
docfeedback@vmware.com
Copyright © 2009–2017 VMware, Inc. Tous droits réservés. Copyright et informations sur les marques.
VMware, Inc.
3401 Hillview Ave.
Palo Alto, CA 94304
www.vmware.com
2 VMware, Inc.
VMware, Inc.
100-101 Quartier Boieldieu
92042 Paris La Défense
France
www.vmware.com/fr
Table des matières
À propos de Disponibilité de vSphere 5
Continuité d'activité et minimisation des interruptions de service 7
1
Réduire les interruptions de service prévues 7
Prévenir les interruptions de service imprévues 8
vSphere HA assure une reprise d'activité rapide suite à une interruption 8
vSphere Fault Tolerance assure la continuité de la disponibilité 9
Protection de vCenter Server Appliance avec vCenter High Availability 10
Protection de vCenter Server avec VMware Service Lifecycle Manager 11
Créer et utiliser des clusters vSphere HA 13
2
Fonctionnement de vSphere HA 13
Contrôle d'admission vSphere HA 22
Interopérabilité de vSphere HA 28
Création d'un cluster vSphere HA 31
Conguration des paramètres de disponibilité vSphere 34
Recommandations pour les clusters VMware vSphere® High Availability 43
Assurer Fault Tolerance des machines virtuelles 47
3
Fonctionnement de Fault Tolerance 47
Cas d'utilisation de Fault Tolerance 48
Conguration requise, limites et licence de Fault Tolerance 49
Interopérabilité de Fault Tolerance 49
Préparer votre cluster et vos hôtes à Fault Tolerance 52
Utilisation de la tolérance aux pannes 54
Pratiques d'excellence pour Fault Tolerance 59
Fault Tolerance héritée 61
VMware, Inc.
vCenter High Availability 65
4
Planier le déploiement de vCenter HA 66
Congurer le réseau 71
Congurer vCenter HA avec l'option Basique 72
Congurer vCenter HA avec l'option Avancé 73
Gérer la conguration vCenter HA 76
Corriger votre environnement vCenter HA 83
Application de correctifs à un environnement vCenter High Availability 88
Utilisation de Microsoft Clustering Service pour vCenter Server sur un cluster
5
Windows haute disponibilité 89
Avantages et limitations de l'utilisation de MSCS 89
Mere à niveau vCenter Server dans un environnement MSCS 90
3
Disponibilité vSphere
Congurer MSCS pour la haute disponibilité 91
Index 95
4 VMware, Inc.
À propos de Disponibilité de vSphere
Disponibilité vSphere présente les solutions permeant d'assurer la continuité d'activité, et explique
notamment comment mere en place vSphere® High Availability (HA) et vSphere Fault Tolerance.
Public cible
Ces informations sont destinées à tous ceux qui veulent assurer la continuité d'activité à l'aide des solutions
vSphere HA et Fault Tolerance. Les informations fournies dans ce livre sont destinées aux administrateurs
du système Windows ou Linux expérimentés qui connaissent le fonctionnement de la technologie des
machines virtuelles et des centres de données.
Les instructions relatives aux tâches présentées dans ce guide se basent sur vSphere Web Client. Vous
pouvez également exécuter la plupart des tâches de ce guide en utilisant la nouvelle version de
vSphere Client. La terminologie, la topologie et le workow de la nouvelle interface utilisateur de
vSphere Clientcorrespondent dèlement aux aspects et éléments de l'interface utilisateur de
vSphere Web Client. Vous pouvez appliquer les instructions de vSphere Web Client à la nouvelle version de
vSphere Client sauf mention du contraire.
R Les fonctionnalités de vSphere Web Client n'ont pas toutes été mises en œuvre pour
vSphere Client dans la version vSphere 6.5. Pour obtenir une liste actualisée des fonctionnalités non prises
en charge, consultez le Guide des mises à jour des fonctionnalités de vSphere Client sur
hp://www.vmware.com/info?id=1413.
VMware, Inc.
5
Disponibilité vSphere
6 VMware, Inc.
Continuité d'activité et minimisation
des interruptions de service 1
Qu'elles soient prévues ou non, les interruptions de service engendrent des coûts considérables. Cependant,
les solutions assurant des niveaux élevés de disponibilité sont généralement chères et diciles à
implémenter et à gérer.
Les logiciels de VMware assurent facilement et à moindre coût un niveau élevé de disponibilité pour les
applications importantes. Avec vSphere, vous pouvez augmenter le niveau de disponibilité de base assuré
pour toutes les applications et fournir des niveaux élevés de disponibilité plus facilement et à moindre frais.
Avec vSphere, vous pouvez :
Assurer une haute disponibilité indépendamment du matériel, du système d'exploitation et des
n
applications.
Réduire les interruptions de service prévues pour les opérations de maintenance courantes.
n
Assurer la restauration automatique en cas de dysfonctionnement.
n
vSphere permet de réduire les interruptions de service prévues, d'éviter des interruptions de service
imprévues et de récupérer rapidement suite à des interruptions.
Ce chapitre aborde les rubriques suivantes :
« Réduire les interruptions de service prévues », page 7
n
« Prévenir les interruptions de service imprévues », page 8
n
« vSphere HA assure une reprise d'activité rapide suite à une interruption », page 8
n
« vSphere Fault Tolerance assure la continuité de la disponibilité », page 9
n
« Protection de vCenter Server Appliance avec vCenter High Availability », page 10
n
« Protection de vCenter Server avec VMware Service Lifecycle Manager », page 11
n
Réduire les interruptions de service prévues
Les interruptions de service prévues représentent généralement plus de 80 % des interruptions de service
d'un centre de données. La maintenance matérielle, la migration des serveurs et les mises à niveau des
microprogramme imposent une interruption du service des serveurs physiques. Pour réduire les
répercussions de ces interruptions de service, les entreprises doivent reporter la maintenance à des plages
horaires peu pratiques et diciles à planier.
vSphere permet aux entreprises de réduire considérablement les interruptions de service prévues. Comme
les charges de travail d'un environnement vSphere peuvent être déplacées dynamiquement sur diérents
serveurs physiques sans interruptions de service, la maintenance des serveurs peut être eectuée sans exiger
une interruption des applications et du service. Avec vSphere, les entreprises peuvent :
éliminer les interruptions de service pour les opérations de maintenance ordinaires.
n
VMware, Inc.
7
Disponibilité vSphere
éliminer les plages de maintenance prévues.
n
exécuter la maintenance à tout moment sans perturber les utilisateurs et les services.
n
vSphere vMotion® et la fonctionnalité Storage vMotion de vSphere permeent aux entreprises de réduire les
interruptions de service prévues car les charges de travail d'un environnement VMware peuvent être
déplacées dynamiquement sur d'autres serveurs physiques ou sur d'autres stockages sous-jacents sans
interruption de service. Les administrateurs peuvent eectuer plus rapidement des opérations de
maintenance entièrement transparentes, sans devoir planier des plages de maintenance peu pratiques.
Prévenir les interruptions de service imprévues
Alors qu'un hôte ESXi ore une plate-forme stable pour exécuter des applications, les entreprises doivent
aussi se protéger contre les interruptions de service imprévues provoquées par des pannes matérielles ou
logicielles. vSphere renforce considérablement les capacités des infrastructures des centres de données, ce
qui contribue à éviter les interruptions de service imprévues.
Ces capacités vSphere font partie d'une infrastructure virtuelle et sont transparentes pour le système
d'exploitation et les applications exécutées sur les machines virtuelles. Ces fonctions peuvent être
congurées et utilisées par toutes les machines virtuelles sur un système physique, ce qui réduit le coût et la
complexité de la prévision d'une disponibilité supérieure. Des fonctions clés de disponibilité sont intégrées à
vSphere :
Stockage partagé. Élimine des points de panne isolés en stockant les chiers des machines virtuelles
n
dans des espaces de stockage partagés, comme Fibre Channel ou iSCSI SAN, ou encore NAS. Il est
possible de faire appel aux fonctions de réplication et de mise en miroir SAN pour conserver les copies
mises à niveau des disques virtuels dans des sites de reprise.
Association d'interfaces réseau. Assure la tolérance aux défaillances des adaptateurs réseau
n
individuelles.
chemins multiples du stockage. Assure la tolérance aux défaillances des emplacements de stockage.
n
En outre, les fonctions vSphere HA et Fault Tolerance peuvent réduire ou éliminer les interruptions de
service imprévues en assurant respectivement la reprise rapide de l'activité suite à une interruption et la
continuité de la disponibilité.
vSphere HA assure une reprise d'activité rapide suite à une interruption
vSphere HA a recours à plusieurs hôtes ESXi congurés en cluster pour assurer une reprise d'activité rapide
suite à une interruption et une haute disponibilité à moindres coûts pour les applications exécutées sur des
machines virtuelles.
vSphere HA protège la disponibilité des applications de la manière suivante :
Il protège contre une défaillance du serveur en redémarrant les machines virtuelles sur d'autres hôtes
n
au sein du cluster.
Il protège contre les défaillances des applications en surveillant en permanence une machine virtuelle et
n
en la réinitialisant en cas de détection d'une défaillance.
Il protège contre les erreurs d'accessibilité de la banque de données en redémarrant les machines
n
virtuelles aectées sur d'autres hôtes ayant toujours accès à leurs banques de données.
Il protège les machines virtuelles contre l'isolation réseau en les redémarrant si leurs hôtes se retrouvent
n
isolés sur le réseau de gestion ou vSAN. Cee protection est assurée même si le réseau s'est retrouvé
partitionné.
8 VMware, Inc.
Chapitre 1 Continuité d'activité et minimisation des interruptions de service
Contrairement aux autres solutions de mise en cluster, vSphere HA fournit l'infrastructure nécessaire à la
protection de toutes les charges de travail :
Il n'est pas nécessaire d'installer des logiciels spéciaux dans l'application ou sur la machine virtuelle.
n
Toutes les charges de travail sont protégées par vSphere HA. Une fois que vSphere HA est conguré,
aucune action n'est requise pour protéger de nouvelles machines virtuelles. Elles sont protégées
automatiquement.
Vous pouvez associer vSphere HA à vSphere Distributed Resource Scheduler (DRS) pour assurer la
n
protection contre les pannes, et pour répartir la charge entre tous les hôtes d'un cluster.
vSphere HA présente plusieurs avantages face aux solutions de basculement habituelles :
Configuration minimale
Coûts et configuration
matérielle réduits
Disponibilité accrue des
applications
Intégration DRS et
vMotion
Quand un cluster vSphere HA a été conguré, toutes les machines virtuelles
du cluster sont incluses dans le basculement sans conguration
supplémentaire.
La machine virtuelle fait oce de conteneur portable pour les applications et
elle peut être déplacée parmi les hôtes. Les administrateurs évitent ainsi de
reproduire les congurations sur plusieurs machines. Lorsque vous utilisez
vSphere HA, vous devez disposer de susamment de ressources pour le
basculement des hôtes que vous souhaitez protéger avec vSphere HA.
Toutefois, le système vCenter Server® gère automatiquement les ressources
et congure les clusters.
Une application exécutée au sein d'une machine virtuelle a accès à une
disponibilité accrue. Comme la machine virtuelle peut récupérer d'une
défaillance matérielle, toutes les applications qui démarrent au moment de
l'initialisation ont une disponibilité accrue sans accroître la charge de calcul,
même si l'application n'est pas en cluster. En surveillant et en répondant aux
signaux de pulsation de VMware Tools et en redémarrant les machines
virtuelles qui ne répondent plus, elle assure également une protection contre
les défaillances du système d'exploitation client.
En cas de défaillance d'un hôte et du redémarrage des machines virtuelles
sur d'autres hôtes, DRS peut fournir des recommandations de migration ou
faire migrer les machines virtuelle en équilibrant les ressources allouées. Si
l'hôte source et/ou l'hôte de destination d'une migration sont défaillants,
vSphere HA peut faciliter la récupération suite à la défaillance.
vSphere Fault Tolerance assure la continuité de la disponibilité
vSphere HA assure un niveau de protection de base pour vos machines virtuelles en les redémarrant en cas
de défaillance de l'hôte. vSphere Fault Tolerance assure un niveau de disponibilité supérieur en permeant
aux utilisateurs de protéger les machines virtuelles contre une défaillance de l'hôte sans perte de données,
de transactions ou de connexions.
Fault Tolerance assure la continuité de la disponibilité en vériant que les états des machines virtuelles
principales et secondaires demeurent identiques tout au long de l'exécution des instructions de la machine
virtuelle.
Si l'hôte faisant fonctionner la machine virtuelle principale ou l'hôte faisant fonctionner la machine virtuelle
secondaire est défaillant, un basculement immédiat et transparent se produit. L'hôte ESXi en état de marche
devient la machine virtuelle principale sans qu'il y ait perte des connexions réseau ou des transactions en
cours. Le basculement transparent évite toute perte de données et assure le maintien des connexions réseau.
En cas de basculement transparent, une nouvelle machine virtuelle est réaectée et la redondance est
rétablie. Le processus est entièrement transparent et automatisé et se produit même en cas d'indisponibilité
du vCenter Server.
VMware, Inc. 9
Disponibilité vSphere
Protection de vCenter Server Appliance avec vCenter High Availability
vCenter High Availability (vCenter HA) protège non seulement contre les défaillances matérielles et de
l'hôte mais également contre les défaillances de l'application vCenter Server. Grâce au basculement
automatisé entre actif et passif, vCenter HA prend en charge la haute disponibilité avec un temps d'arrêt
minimal.
Options de déploiement de vCenter HA
vCenter HA protège votre dispositif vCenter Server Appliance. Cependant, Platform Services Controller
fournit l'authentication, la gestion des certicat et les licences pour vCenter Server Appliance. Par
conséquent, vous devez garantir la haute disponibilité de Platform Services Controller. Vous avez plusieurs
options.
Déployez un nœud actif avec une instance intégrée de Platform Services Controller. Dans le cadre du
n
processus de clonage, Platform Services Controller est cloné, ainsi que tous ses services. Dans le cadre
de la synchronisation entre le nœud actif et le nœud passif, , Platform Services Controller est mis à jour
sur le nœud passif.
Lorsque le basculement se produit du mode actif au mode passif, les instances de
Platform Services Controller sur le nœud passif sont disponibles, ainsi que l'environnement complet.
Déployez au moins deux Platform Services Controller instances et placez-les derrière un équilibrage de
n
charge.
Lorsque le basculement se produit du nœud actif au nœud passif, le nœud passif continue de pointer
vers l'équilibrage de charge. Lorsque l'une des instances de Platform Services Controller n'est plus
disponible, l'équilibrage de charge dirige les requêtes vers la seconde instance de
Platform Services Controller.
Reportez-vous à « Options de déploiement de vCenter HA », page 68.
Options de configuration de vCenter HA
Vous congurez vCenter HA à partir de vSphere Web Client. L'assistant de conguration ore les options
suivantes.
Option Description
De base L'option De base clone le nœud actif en nœud passif et en nœud témoin, et congure le nœud pour vous.
Si votre environnement répond aux exigences suivantes, vous pouvez utiliser cee option.
Soit l'instance de vCenter Server Appliance, qui deviendra le nœud actif, gère son propre hôte ESXi et sa
n
propre machine virtuelle. Cee conguration de vCenter Server est parfois appelée gestion automatique.
Ou le dispositif vCenter Server Appliance est géré par une autre instance de vCenter Server
n
(vCenter Server de gestion) et les deux instances de vCenter Server se trouvent dans le même domaine
vCenter Single Sign-On. Cela implique que toutes deux utilisent un dispositif Platform Services Controller
externe et qu'elles exécutent toutes deux vSphere 6.5.
Reportez-vous à « Congurer vCenter HA avec l'option Basique », page 72.
Avancé L'option Avancé ore davantage de exibilité. Vous pouvez utiliser cee option tant que votre environnement
satisfait les congurations matérielles et logicielles requises.
Si vous sélectionnez cee option, vous devez cloner le nœud actif sur le nœud passif et sur le nœud témoin.
Vous devez également eectuer une conguration de mise en réseau.
Reportez-vous à « Congurer vCenter HA avec l'option Avancé », page 73.
10 VMware, Inc.
Chapitre 1 Continuité d'activité et minimisation des interruptions de service
Protection de vCenter Server avec VMware Service Lifecycle Manager
La disponibilité de vCenter Server est fournie par VMware Service Lifecycle Manager.
Si le service vCenter échoue, VMware Service Lifecycle Manager le redémarre. VMware Service Lifecycle
Manager surveille la santé des services et exécute une action corrective précongurée en cas de détection de
panne. Le service ne redémarre pas en cas de plusieurs tentatives de correction de panne.
VMware, Inc. 11
Disponibilité vSphere
12 VMware, Inc.
Créer et utiliser des clusters vSphere
HA 2
Les clusters vSphere HA permeent à un ensemble d'hôtes ESXi de travailler conjointement, de façon à
fournir aux machines virtuelles, en tant que groupe, un niveau de disponibilité supérieur à celui d'un seul
hôte ESXi. Si vous envisagez de créer et d'utiliser un nouveau cluster vSphere HA, les options choisies
aectent la manière dont ce cluster réagit aux pannes des hôtes ou des machines virtuelles.
Avant de créer un cluster vSphere HA, vous devez savoir comment vSphere HA identie les pannes et
l'isolation de l'hôte et comment il réagit à ces situations. Vous devez aussi connaître le mode de
fonctionnement du contrôle d'admission de façon à être capable de choisir les règles qui répondent à vos
besoins de basculement. Après avoir créé un cluster, vous pouvez en personnaliser le comportement avec
des options avancées et en optimiser les performances en suivant les recommandations.
R Un message d'erreur peut apparaître lorsque vous essayez d'utiliser vSphere HA. Pour plus
d'informations sur les messages d'erreur relatifs à vSphere HA, reportez-vous à l'article de la base de
connaissances VMware sur hp://kb.vmware.com/kb/1033634.
Ce chapitre aborde les rubriques suivantes :
« Fonctionnement de vSphere HA », page 13
n
« Contrôle d'admission vSphere HA », page 22
n
« Interopérabilité de vSphere HA », page 28
n
« Création d'un cluster vSphere HA », page 31
n
« Conguration des paramètres de disponibilité vSphere », page 34
n
« Recommandations pour les clusters VMware vSphere® High Availability », page 43
n
Fonctionnement de vSphere HA
vSphere HA assure la disponibilité élevée des machines virtuelles en les rassemblant avec leurs hôtes
respectifs dans un cluster. Les hôtes du cluster sont surveillés et, en cas de défaillance, les machines
virtuelles d'un hôte défectueux sont redémarrées sur d'autres hôtes.
Lorsque vous créez un cluster vSphere HA , un seul hôte est automatiquement sélectionné en tant qu'hôte
maître. L'hôte maître communique avec vCenter Server et surveille l' état de protection de toutes les
machines virtuelles et des hôtes esclaves. Diérents types de défaillances d'hôtes sont possibles, et l'hôte
principal doit les détecter et les traiter de façon adaptée. L'hôte principal doit faire la diérence entre un
hôte défaillant et un hôte se trouvant dans une partition de réseau ou réseau isolé. L'hôte principal utilise le
signal de pulsation de banques de données pour déterminer le type de panne.
Clusters vSphere HA (hp://link.brightcove.com/services/player/bcpid2296383276001?
bctid=ref:vSphereHAClusters)
VMware, Inc. 13
Disponibilité vSphere
Hôtes principaux et subordonnés
Lorsque vous ajoutez un hôte à un cluster vSphere HA, un agent est transféré vers l'hôte et conguré pour
communiquer avec les autres agents du cluster. Chaque hôte du cluster fonctionne en tant qu'hôte principal
ou hôte subordonné.
Lorsque vSphere HA est activé pour un cluster, tous les hôtes actifs (ceux qui ne sont pas en mode veille ou
en mode maintenance, ou qui ne sont pas déconnectés) participent au choix de l'hôte principal du cluster.
L'hôte contenant le plus grand nombre de banques de données a l'avantage pour être choisi.
Habituellement, il n'existe qu'un hôte principal par cluster, tous les autres sont des hôtes subordonnés. Si
l'hôte principal est défaillant, fermé, mis en mode standby ou éliminé du cluster, un nouvel hôte principal
doit être choisi.
L'hôte principal d'un cluster a plusieurs responsabilités :
Surveiller l'état des hôtes subordonnés. Si un hôte subordonné est défaillant ou devient inaccessible,
n
l'hôte principal identie les machines virtuelles qui doivent être redémarrées.
Surveiller l'état d'alimentation de toutes les machines virtuelles protégées. Si une machine virtuelle est
n
défaillante, l'hôte principal s'assure qu'elle est redémarrée. Grâce à un moteur de placement local, l'hôte
principal détermine également l'endroit où le redémarrage a lieu.
Gérer les listes d'hôtes et de machines virtuelles protégées du cluster.
n
Servir d'interface de gestion vCenter Server du cluster et rendre compte de l'état de santé du cluster.
n
Les hôtes subordonnés apportent une contribution essentielle au cluster en exécutant des machines
virtuelles localement, en surveillant leur état d'exécution et en communiquant les mises à jour d'état à l'hôte
principal. Un hôte principal peut également exécuter et surveiller des machines virtuelles. Les hôtes
principaux et les hôtes subordonnés meent en œuvre les fonctions de surveillance de machine virtuelle et
d'application.
Une des fonctions exercées par l'hôte maître est la coordination des redémarrages de machines virtuelles
protégées. Une VM est protégée par un hôte maître après que vCenter Server observe que l'état
d'alimentation de la VM est passé de hors tension à sous tension en réponse à une action de l'utilisateur.
L'hôte maître conserve la liste des machines virtuelles protégées dans les banques de données du cluster. Un
hôte maître nouvellement élu utilise ces informations pour déterminer quelles machines virtuelles doivent
être protégées.
R Si vous déconnectez un hôte d'un cluster, les machines virtuelles enregistrées sur cet hôte ne
sont pas protégées par vSphere HA.
Types de pannes d'hôte
L'hôte principal d'un cluster VMware vSphere® High Availability est responsable de la détection des pannes
des hôtes subordonnés. Selon le type de panne détecté, les machines virtuelles exécutées sur les hôtes
peuvent nécessiter un basculement.
Dans un cluster vSphere HA, trois types de pannes d'hôtes sont détectés :
Panne : un hôte cesse de fonctionner.
n
Isolation : un hôte se retrouve isolé sur le réseau.
n
Partition : un hôte perd sa connectivité réseau avec l'hôte principal.
n
14 VMware, Inc.
Chapitre 2 Créer et utiliser des clusters vSphere HA
L'hôte principal surveille la réactivité des hôtes subordonnés du cluster. Cee communication s'eectue par
l'échange, toutes les secondes, de signaux de pulsation réseau. Lorsqu'un hôte principal cesse de recevoir
des signaux de pulsation d'un hôte subordonné, il vérie la réactivité de l'hôte avant de le déclarer
défaillant. Le contrôle de réactivité eectué par l'hôte principal permet de déterminer si l'hôte subordonné
échange des signaux de pulsation avec une des banques de données. Reportez-vous à « Signal de pulsation
de banque de données », page 20. Par ailleurs, l'hôte principal vérie si l'hôte répond aux pings ICMP
envoyés à ses adresses IP de gestion.
Si un hôte principal ne peut pas communiquer directement avec l'agent sur un hôte subordonné, celui-ci ne
répond pas aux commandes ping ICMP. Si l'agent n'émet pas de pulsations, il est considéré comme
défaillant. Les machines virtuelles des hôtes sont redémarrées sur d'autres hôtes. Si cet hôte subordonné
échange des signaux de pulsation avec une banque de données, l'hôte principal suppose que l'hôte
subordonné se trouve dans une partition du réseau ou est isolé du réseau. L'hôte principal continue donc à
surveiller l'hôte et ses machines virtuelles. Reportez-vous à « Partitions de réseau », page 20.
L'isolation du réseau de l'hôte survient lorsqu'un hôte, toujours en cours d'exécution, ne parvient plus à
observer le trac provenant des agents vSphere HA sur le réseau de gestion. Si un hôte cesse d'observer ce
trac, il tente d'envoyer un ping aux adresses d'isolation du cluster. Si cee commande ping échoue
également, l'hôte déclare qu'il est isolé du réseau.
L'hôte principal surveille les machines virtuelles qui s'exécutent sur un hôte isolé. Si l'hôte principal
remarque que les machines virtuelles se meent hors tension et qu'il en est responsable, il les redémarre.
R Si vous vous assurez que l'infrastructure réseau est susamment redondante et qu'au moins un
chemin d'accès au réseau est toujours disponible, l'isolation du réseau de l'hôte est moins susceptible de se
produire.
Pannes de Proactive HA
Une panne de Proactive HA se produit lorsqu'un composant hôte est défaillant, ce qui entraîne une perte de
redondance ou une panne non grave. Cependant, le comportement de fonctionnement des machines
virtuelles qui résident sur l'hôte n'est pas aecté. Par exemple, si une alimentation électrique sur l'hôte
tombe en panne, mais que les autres alimentations sont disponibles, il s'agit d'une panne de Proactive HA.
En cas de panne de Proactive HA, vous pouvez automatiser la mesure corrective prise dans la section
Disponibilité vSphere de vSphere Web Client. Les machines virtuelles sur l'hôte concerné peuvent être
évacuées vers d'autres hôtes et l'hôte est mis en mode de quarantaine ou de maintenance.
R Pour que la surveillance des pannes de Proactive HA fonctionne, votre cluster doit utiliser
vSphere DRS.
Déterminer les réponses aux problèmes de l'hôte
Si un hôte échoue et que ses machines virtuelles doivent être redémarrées, vous pouvez contrôler l'ordre
dans lequel cela se fait avec le paramètre de priorité de redémarrage des machines virtuelles. De même,
vous pouvez congurer la réponse de vSphere HA lorsque des hôtes perdent la connectivité au réseau de
gestion à d'autres hôtes en utilisant les paramètres de réponse d'isolation. D'autres facteurs sont également
pris en compte lorsque vSphere HA redémarre une machine virtuelle après un échec.
Les paramètres suivants s'appliquent à toutes les machines virtuelles du cluster en cas d'échec ou d'isolation
d'un hôte. Vous pouvez congurer des exceptions pour des machines virtuelles spéciques. Reportez-vous à
« Personnaliser une machine virtuelle secondaire », page 42.
VMware, Inc. 15
Disponibilité vSphere
Réponse d'isolation de l'hôte
La réponse d'isolation d'hôte détermine les événements survenant lorsqu'un hôte d'un cluster vSphere HA
perd ses connexions au réseau de gestion, mais continue à s'exécuter. Vous pouvez utiliser la réponse
d'isolation an que vSphere HA mee hors tension les machines virtuelles en cours d'exécution sur un hôte
isolé et les redémarre sur un hôte non isolé. Les réponses d'isolation d'hôte exigent que l'état de surveillance
de l'hôte soit activé. Si l'état de surveillance de l'hôte est désactivé, les réponses d'isolation d'hôte sont
également suspendues. Un hôte détermine qu'il est isolé lorsqu'il est incapable de communiquer avec les
agents en cours d'exécution sur les autres hôtes et d'envoyer un ping à ses adresses d'isolation. L'hôte
exécute ensuite sa réponse d'isolation. Les réponses sont Mere hors tension et redémarrer les VM ou
Arrêter et redémarrer les machines virtuelles. Vous pouvez personnaliser cee propriété pour des machines
virtuelles individuelles.
R Si le paramètre de priorité de redémarrage d'une machine virtuelle est déni sur Désactivée,
aucune réponse d'isolation d'hôte n'est fournie.
Pour utiliser le paramètre Arrêter et redémarrer les machines virtuelles, vous devez installer VMware Tools
dans le système d'exploitation invité de la machine virtuelle. L'arrêt de la machine virtuelle ore l'avantage
de préserver son état. L'arrêt est préférable à la mise hors tension de la machine virtuelle qui ne prend pas
en compte pas les dernières modications apportées aux disques ni ne valide les transactions. Le
basculement des machines virtuelles qui sont en train de s'arrêter est plus long car la fermeture doit aussi
être eectuée. Les machines virtuelles qui n'ont pas été arrêtées au bout de 300 secondes ou du délai déni
par l'option avancée das.isolationshutdowntimeout sont mises hors tension.
Lorsque vous avez créé un cluster vSphere HA, vous pouvez changer les paramètres par défaut du cluster
relatifs à la priorité de redémarrage et à la réponse d'isolation de machines virtuelles spéciques. Ces
remplacements sont utiles pour les machines virtuelles qui sont utilisées pour des tâches spéciales. Par
exemple, les machines virtuelles qui fournissent des services d'infrastructure, comme DNS ou DHCP,
doivent éventuellement être mises sous tension avant d'autres machines virtuelles du cluster.
Une condition de split-brain peut se produire sur une machine virtuelle lorsqu'un hôte se retrouve isolé ou
partitionné depuis un hôte principal qui ne peut pas communiquer avec lui à l'aide des banques de données
des signaux de pulsation. Dans une telle situation, l'hôte principal n'est pas en mesure de déterminer si
l'hôte est actif et le déclare inactif. L'hôte principal fait ensuite une tentative pour redémarrer les machines
virtuelles qui s'exécutent sur l'hôte isolé ou partitionné. Cee tentative réussit si les machines virtuelles
continuent de s'exécuter sur l'hôte isolé ou partitionné et celui-ci perd l'accès aux banques de données des
machines virtuelles quand il s'est retrouvé isolé ou partitionné. Il existe alors une condition de split-brain,
car la machine virtuelle se retrouve avec deux instances. Toutefois, seule une de ces instances est en mesure
de lire ou d'écrire sur les disques virtuels de la machine virtuelle. VM Component Protection peut vous
aider à empêcher cee condition de split-brain. Lorsque vous activez VMCP avec le paramètre intensif, il
contrôle l'accessibilité de la banque de données sur les machines virtuelles sous tension et arrête celles qui
perdent l'accès à leurs banques de données.
Pour résoudre ce problème, ESXi génère une question sur la machine virtuelle qui a perdu les verrouillages
disque pour le moment où l'hôte quie son état d'isolation et est dans l'impossibilité obtenir de nouveau les
verrouillages disque. vSphere HA répond automatiquement à cee question ce qui permet à l'instance de la
machine virtuelle qui a perdu les verrouillages disque de se mere hors tension, laissant uniquement
l'instance qui dispose des verrouillages disque.
16 VMware, Inc.
Chapitre 2 Créer et utiliser des clusters vSphere HA
Dépendances des machines virtuelles
Vous pouvez créer des dépendances entre les groupes de machines virtuelles. Pour cela, vous devez d'abord
créer les groupes de VM dans vSphere Web Client en accédant à l'onglet du cluster et en
sélectionnant Groupes de VM/Hôte. Une fois les groupes créés, vous pouvez créer des règles de
redémarrage des dépendances entre les groupes en accédant à l'onglet Règles de VM/Hôte et en
sélectionnant dans le menu déroulant Machines virtuelles vers machines virtuelles. Ces règles peuvent
spécier que certains groupes de VM ne peuvent pas être redémarrés tant que d'autres groupes spéciés
n'ont pas été démarrés en premier.
Facteurs pris en charge pour le redémarrage de la machine virtuelle
Après un échec, l'hôte principal du cluster fait une tentative de redémarrage des machines virtuelles
concernées en identiant un hôte susceptible de les mere sous tension. Lors de la sélection de cet hôte,
l'hôte principal tient compte d'un certain nombre de facteurs.
Accessibilité des
fichiers
Machine virtuelle et
compatibilité de l'hôte
Réservations de
ressources
Limites d'hôtes
Contraintes de la
fonctionnalité
Avant de pouvoir redémarrer une machine virtuelle, ses chiers doivent être
accessibles depuis l'un des hôtes actif du cluster avec lequel l'hôte principal
peut communiquer via le réseau.
S'il existe des hôtes accessibles, la machine virtuelle doit être compatible avec
au moins l'un d'entre eux. La compatibilité dénie pour une machine
virtuelle comprend l'eet de l'une des règles d'anité machine
virtuelle/hôte. Par exemple, si une règle permet à une machine virtuelle de
s'exécuter sur deux hôtes, elle est prise en compte pour le placement sur ces
deux hôtes.
Parmi les hôtes sur lesquels la machine virtuelle peut s'exécuter, au moins un
doit disposer d'une capacité non réservée susante pour satisfaire aux
besoins de la mémoire de temps système de la machine virtuelle et aux
réservations de ressources. Quatre types de réservations sont prises en
compte : CPU, mémoire, vNIC et lecteur Flash virtuel. De plus, un nombre
de ports réseau susant doit être disponible pour mere sous tension la
machine virtuelle.
En plus des réservations de ressources, une machine virtuelle ne peut être
placée sur un hôte que si cela ne lui fait pas dépasser le nombre maximal de
machines virtuelles autorisées ou de vCPU utilisés.
Si l'option avancée qui a été dénie nécessite que vSphere HA fasse respecter
les règles d'anité machine virtuelle/machine virtuelle, vSphere HA
n'enfreint pas cee règle. De plus, vSphere HA n'enfreint pas les limites
congurée pour chaque hôte pour les machines virtuelles Fault Tolerance.
Si aucun hôte ne répond aux considérations précédentes, l'hôte principal émet un événement indiquant qu'il
ne dispose pas des ressources susantes pour que vSphere HA démarre la machine virtuelle et ressaiera
une fois les conditions du cluster améliorées. Par exemple, si la machine virtuelle n'est pas accessible, l'hôte
principal réessaie après une modication de l'accessibilité des chiers.
VMware, Inc. 17
Disponibilité vSphere
Surveillance des VM et applications
Surveillance de VM redémarre les machines virtuelles si leurs signaux de pulsation de VMware Tools n'ont
pas été reçus pendant un certain temps. De même, la Surveillance d'application peut redémarrer une
machine virtuelle si les signaux de pulsation d'une application exécutée ne sont pas reçus. Il est possible
d'activer ces fonctions et de congurer la sensibilité de la surveillance de l'absence de réaction par vSphere
HA.
Lorsque vous activez la Surveillance de VM, le service Surveillance de VM (à l'aide de VMware Tools) vérie
si chaque machine virtuelle du cluster fonctionne en vériant la régularité des signaux de pulsations et
l'activité des E/S à partir du processus VMware Tools exécuté sur le client. Si aucun signal de pulsation ou
activité des E/S n'est reçu, cela est probablement dû à une défaillance du système d'exploitation invité ou au
fait que les VMware Tools n'ont pas eu le temps de terminer certaines tâches. Dans ce cas, le service
Surveillance de VM détermine que la machine virtuelle est défectueuse et la machine virtuelle redémarre
pour restaurer le service.
Il arrive qu'occasionnellement, les machines virtuelles ou les applications qui continuent à fonctionner
correctement, cessent d'émere des signaux de pulsation. Pour éviter les réinitialisations inutiles, le service
Surveillance de VM surveille aussi l'activité des E/S d'une machine virtuelle. Si aucun signal de pulsation
n'est reçu pendant la période de défaillance, la fréquence des statistiques des E/S (aribut déni au niveau
du cluster) est vériée. La fréquence des statistiques des E/S détermine si un disque ou une activité réseau
s'est produite sur la machine virtuelle au cours des deux minutes (120 secondes) précédentes. Si ce n'est pas
le cas, la machine virtuelle est réinitialisée. Cee valeur par défaut (120 secondes) peut être modiée à l'aide
de l'option avancée das.iostatsinterval.
Pour activer la surveillance d'application, il faut d'abord obtenir le SDK approprié (ou utiliser une
application qui prend en charge la surveillance de l'application VMware) et l'utiliser pour congurer des
signaux de pulsation personnalisés pour les applications à surveiller. Après avoir fait cela, la surveillance
d'application fonctionne de la même manière que la Surveillance de VM. Si les signaux de pulsation d'une
application ne sont pas reçus pendant un certain temps, sa machine virtuelle est redémarrée.
Vous pouvez congurer le niveau de sensibilité de la surveillance. Une sensibilité de surveillance élevée
permet de conclure plus rapidement à un dysfonctionnement. Même si cela est peu probable, une sensibilité
de surveillance élevée peut entraîner l'identication erronée de dysfonctionnements alors que la machine
virtuelle ou l'application en question fonctionne toujours mais les signaux de pulsation ne sont pas reçus du
fait de certains facteurs tels que des contraintes de ressources. Une sensibilité de surveillance basse se
traduit par des interruptions de service prolongées entre les défaillances avérées et le redémarrage des
machines virtuelles. Sélectionnez l'option qui ore un compromis intéressant par rapport à vos besoins.
Vous pouvez aussi indiquer des valeurs personnalisées à la fois pour la sensibilité de la surveillance et les
intervalles de statistiques d'E/S en cochant la case Personnalisé.
Tableau 2‑1. Paramètres de surveillance des machines virtuelles
Paramètre Intervalle d'échec Période de réinitialisation
Haut 30 1 heure
Moyen 60 24 heures
Faible 120 7 jours
Lorsque des dysfonctionnements sont détectés, vSphere HA réinitialise les machines virtuelles. La
réinitialisation contribue à garantir que les services restent disponibles. Pour éviter de réinitialiser
constamment des machines virtuelles en cas d'erreurs non transitoires, les machines virtuelles sont
réinitialisées par défaut trois fois seulement au cours d'une période congurable. Après trois réinitialisations
18 VMware, Inc.
Chapitre 2 Créer et utiliser des clusters vSphere HA
des machines virtuelles, vSphere HA n'eectue aucune tentative supplémentaire pour redémarrer les
machines virtuelles en cas de nouvel échec et ce jusqu'à ce que la période dénie ne soit écoulée. Vous
pouvez congurer le nombre de réinitialisations à l'aide du paramètre personnalisé Nbre maximum de
réinitialisations par machine virtuelle.
R Les statistiques de réinitialisation sont eacées lorsque la machine virtuelle est mise hors
tension puis sous tension, ou quand elle est migrée à un autre hôte en utilisant vMotion. Cela provoque le
redémarrage du système d'exploitation d'hôte, mais de façon diérente à un «redémarrage» dans lequel
l'état d'alimentation de la VM est changé.
VM Component Protection
Si VM Component Protection (VMCP) est activé, vSphere HA peut détecter les erreurs d'accessibilité à la
banque de données et fournir une récupération automatisée pour les machines virtuelles concernées.
VMCP ore une protection contre les erreurs d'accessibilité à la banque de données qui aectent une
machine virtuelle s'exécutant sur un hôte dans un cluster vSphere HA. En cas d'erreur d'accessibilité à une
banque de données, l'hôte aecté ne peut plus accéder au chemin de stockage d'une banque de données
spécique. Vous pouvez déterminer la réaction de vSphere HA face à cee erreur, depuis la création
d'alarmes d'événement jusqu'au redémarrage de la machine virtuelle sur d'autres hôtes.
R Pour utiliser la fonctionnalité VM Component Protection, la version de vos hôtes ESXi doit être
6.0 ou une version ultérieure.
Types d'erreurs
Il existe deux types d'erreurs d'accessibilité à une banque de données :
PDL
APD
PDL (perte de périphérique permanente) est une perte d'accessibilité
irrécupérable qui se produit lorsqu'un périphérique de stockage signale que
la banque de données n'est plus accessible à l'hôte. Cee condition ne peut
pas être rétablie sans mere hors tension les machines virtuelles.
APD (Tous chemins hors service) représente une perte d'accessibilité
temporaire ou inconnue, ou tout autre retard non identié dans le traitement
des E/S. Ce type d'erreur d'accessibilité est récupérable.
Configuration de VMCP
La fonctionnalité VM Component Protection est congurée dans vSphere Web Client. Accédez à l'onglet
et cliquez sur Disponibilité vSphere, puis cliquez sur . Sous Pannes et réponses, vous
pouvez sélectionnez l'option Banque de données avec PDL ou Banque de données avec APD. Les niveaux
de protection du stockage que vous pouvez sélectionner et les actions de correction de la machine virtuelle
disponibles varient selon le type d'erreur d'accessibilité à la base de données.
Erreurs PDL
Erreurs APD
Sous Banque de données avec PDL, vous pouvez sélectionner l'option
Émission d'événements ou hors tension et redémarrer les VM.
La réponse aux événements APD est plus complexe et, en fonction de la
conguration, est dénie avec une plus grande précision. Vous pouvez
sélectionner l'option Émission d'événements, hors tension et
redémarrer les VM : stratégie de redémarrage modérée ou hors
tension et redémarrer les VM : stratégie de redémarrage agressive.
R Si les paramètres Surveillance VM ou Priorité redémarrage VM sont désactivés, VMCP ne peut
pas redémarrer la machine virtuelle. Toutefois, la santé du stockage peut toujours être surveillée et les
événements être émis.
VMware, Inc. 19
Disponibilité vSphere
Partitions de réseau
En cas de défaillance du réseau de gestion d'un cluster vSphere HA, un sous-ensemble d'hôtes du cluster
risque d'être incapable de communiquer avec les autres hôtes sur le réseau de gestion. De multiples
partitions peuvent se produire dans un cluster.
Un cluster partitionné entraîne une diminution de la protection des machines virtuelles et une altération des
fonctions de gestion du cluster. Réparez le cluster partitionné dès que possible.
Protection de VM. vCenter Server permet de mere sous tension une VM, mais celle-ci n'est protégée
n
que si elle s'exécute sur la même partition que l'hôte principal qui en est responsable. L'hôte principal
doit communiquer avec vCenter Server. Un hôte principal est responsable d'une machine virtuelle s'il a
bloqué exclusivement un chier déni par le système sur la banque de données contenant le chier de
conguration de la machine virtuelle.
Gestion de cluster. vCenter Server peut communiquer avec l'hôte principal, mais uniquement un sous-
n
ensemble d'hôtes secondaires. Par conséquent, il se peut que les modications de conguration relatives
à vSphere HA ne prennent pas eet tant que le problème de partition n'est pas résolu. Suite à cee
défaillance, une des partitions pourrait s'exécuter selon l'ancienne conguration, tandis qu'une autre
utiliserait les nouveaux paramètres.
Signal de pulsation de banque de données
Lorsque l'hôte principal d'un cluster VMware vSphere® High Availability ne peut pas communiquer avec
un hôte subordonné sur le réseau de gestion, l'hôte principal utilise le signal de pulsation de banque de
données pour déterminer si l'hôte subordonné est défaillant, s'il se trouve dans une partition de réseau ou
est isolé du réseau. Si l'hôte subordonné a arrêté le signal de pulsation de banque de données, il est
considéré comme défaillant et ses machines virtuelles sont redémarrées ailleurs.
VMware vCenter Server® sélectionne un ensemble de banques de données préférées pour le signal de
pulsation. Cee sélection a pour but d'optimiser le nombre d'hôtes ayant accès à une banque de données de
signaux de pulsation et de minimiser le risque que les banques de données soient sauvegardées par le même
LUN ou le même serveur NFS.
Vous pouvez utiliser l'option avancée das.heartbeatdsperhost pour modier le nombre de banques de
données de signaux de pulsation sélectionné par vCenter Server pour chaque hôte. La valeur par défaut est
deux et la valeur maximale est cinq.
vSphere HA crée un répertoire à la racine de chaque banque de données qui sert à la fois au signal de
pulsation de banques de données et à maintenir l'ensemble des machines virtuelles protégées. Le nom de ce
répertoire est .vSphere-HA. Vous ne devez ni supprimer ni modier les chiers stockés dans ce répertoire car
cela peut avoir des répercussions sur les opérations. Plusieurs clusters peuvent utiliser une banque de
données. Des sous-répertoires sont donc créés dans ce répertoire pour chaque cluster. Ces répertoires et
chiers font partie de la racine, et seule celle-ci peut les lire et les modier. L'espace disque utilisé par
vSphere HA dépend de plusieurs facteurs, notamment la version de VMFS et le nombre d'hôtes qui utilisent
la banque de données pour le signal de pulsation. Avec vmfs3, l'utilisation maximale est 2 Go et l'utilisation
type est 3 Mo. Avec vmfs5, l'utilisation maximale et classique est 3 Mo. L'utilisation des banques de données
par vSphere HA n'entraîne qu'un dépassement de mémoire négligeable et n'a aucun impact sur les
performances des autres opérations des banques de données.
20 VMware, Inc.
Chapitre 2 Créer et utiliser des clusters vSphere HA
vSphere HA limite le nombre de machines virtuelles qui peuvent avoir des chiers de conguration sur une
banque de données unique. Consultez Congurations Maximales pour connaître les limites mises à jour. Si
vous placez plus que ce nombre de machines virtuelles sur une banque de données et que vous les meez
sous tension, vSphere HA ne protège les machines virtuelles que jusqu'à cee limite.
R Une banque de données de vSAN ne peut pas être utilisée pour le signal de pulsation de
banque de données. Par conséquent, si aucun autre stockage partagé n'est accessible à tous les hôtes du
cluster, il se peut qu'aucune banque de données de signaux de pulsation ne soit utilisée. Toutefois, si vous
disposez d'un stockage accessible par un autre chemin réseau indépendant de vSAN, vous pouvez l'utiliser
pour congurer une banque de données de signaux de pulsation.
Sécurité vSphere HA
Plusieurs fonctions de sécurité permeent d'améliorer vSphere HA.
Sélectionner les ports
de pare-feu ouverts
Fichiers de
configuration protégés
par les autorisations du
système de fichiers
Journalisation détaillée
vSphere HA utilise les ports 8182 TCP et UDP pour la communication
d'agent à agent. Les ports de pare-feu s'ouvrent et se ferment
automatiquement pour assurer qu'ils sont ouverts uniquement lorsque cela
est nécessaire.
vSphere HA stocke les informations de conguration sur le système de
stockage local ou sur le ramdisk s'il n'existe aucune banque de données
locale. Ces chiers sont protégés par les autorisations du système de chiers
et sont accessibles uniquement par l'utilisateur racine. Les hôtes sans
stockage local sont pris en charge uniquement si ils sont gérés par Auto
Deploy.
L'emplacement des chiers journaux choisi par vSphere HA dépend de la
version de l'hôte.
Pour les hôtes ESXi 5.x, vSphere HA écrit sur syslog uniquement par
n
défaut. Les journaux sont donc placés à l'endroit indiqué dans la
conguration de syslog. Les noms des chiers journaux de vSphere HA
sont précédés de fdm, fault domain manager (gestionnaire de domaine
de pannes), qui est un service de vSphere HA.
Pour les hôtes existants 4.x ESXi, vSphere HA écrit
n
dans /var/log/vmware/fdm sur le disque local, ainsi que syslog si il est
conguré.
Pour les hôtes hérités ESX 4.x, vSphere HA écrit
n
sur /var/log/vmware/fdm.
Connexions vSphere
HA sécurisées
vSphere HA se connecte aux agents vSphere HA à l'aide d'un compte
d'utilisateur, vpxuser, créé par vCenter Server. Ce compte est le même que
celui utilisé par vCenter Server pour la gestion de l'hôte. vCenter Server crée
un mot de passe aléatoire pour ce compte et le change régulièrement. La
fréquence de renouvellement du mot de passe est dénie par le paramètre
VirtualCenter.VimPasswordExpirationInDays de vCenter Server. Les
utilisateurs ayant des privilèges d'administration sur le dossier racine de
l'hôte peut se connecter à l'agent.
VMware, Inc. 21
Disponibilité vSphere
Communication
sécurisée
Toutes les communications entre vCenter Server et l'agent vSphere HA sont
sécurisées par SSL. La communication d'agent à agent utilise également le
protocole SSL sauf pour les messages d'élection, qui utilisent UDP. Les
messages d'élection sont vériés via SSL de sorte qu'un agent non autorisé
puisse empêcher uniquement l'hôte sur lequel l'agent s'exécute d'être choisi
comme hôte principal. Dans ce cas, un problème de conguration du cluster
est émis an que l'utilisateur soit informé du problème.
Vérification du certificat
SSL de l'hôte requise
vSphere HA exige que chaque hôte dispose d'un certicat SSL vérié.
Chaque hôte génère un certicat auto-signé lors de son premier démarrage.
Ce certicat peut être généré une nouvelle fois ou remplacé par un certicat
émis par une autorité. Si le certicat est remplacé, vSphere HA doit être
reconguré sur l'hôte. Si un hôte se déconnecte de vCenter Server après la
mise à jour de son certicat et si l'agent de l'hôte ESXi ou ESX est redémarré,
vSphere HA est automatiquement reconguré au moment où l'hôte est
reconnecté à vCenter Server. Si la déconnexion n'est pas due au fait que la
vérication du certicat SSL de l'hôte de vCenter Server est désactivée à ce
moment-là, vériez le nouveau certicat et recongurez vSphere HA sur
l'hôte.
Contrôle d'admission vSphere HA
vSphere HA utilise le contrôle d'admission pour s'assurer que des ressources susantes sont réservées à la
récupération des machine virtuelles en cas de défaillance d'un hôte.
Le contrôle d'admission impose des contraintes sur l'utilisation des ressources. Les actions qui risquent
d'enfreindre ces contraintes ne sont pas autorisées. Les actions qui peuvent ne pas être autorisées incluent
les exemples suivants :
Mise sous tension d'une machine virtuelle
n
Migration d'une machine virtuelle
n
Augmentation de la réserve de CPU ou de mémoire d'une machine virtuelle
n
La base du contrôle d'admission vSphere HA est le nombre de défaillances d'hôte que le cluster est autorisé
à tolérer et qui continue à garantir le basculement. La capacité de basculement des hôtes peut être dénie de
trois manières diérentes :
Pourcentage de ressources du cluster
n
Stratégie d'emplacement
n
Hôtes de basculement dédiés
n
R Le contrôle d'admission vSphere HA peut être désactivé. Cependant, sans ce contrôle, il est
impossible de garantir que le nombre de machines virtuelles aendu puisse être redémarré après une
défaillance. Ne désactivez pas le contrôle d'admission de façon permanente.
Quelle que soit l'option de contrôle d'admission choisie, un seuil de réduction des ressources de VM existe
également. Ce paramètre permet de spécier le pourcentage de dégradation des ressources pouvant être
toléré, mais il n'est pas disponible si vSphere DRS n'est pas activé.
Le calcul de la réduction des ressources est vérié pour le CPU et la mémoire. Il prend en compte la
mémoire réservée d'une machine virtuelle et la surcharge de la mémoire pour décider de l'autoriser ou non
à être mise sous tension, migrée ou à modier sa réservation. La mémoire réelle utilisée par la machine
virtuelle n'est pas prise en compte dans le calcul, car la réservation de mémoire ne correspond pas toujours à
l'utilisation réelle de la mémoire de la machine virtuelle. Si l'utilisation réelle est supérieure à la mémoire
réservée, la capacité de basculement disponible est insusante, ce qui entraîne la dégradation des
performances lors du basculement.
22 VMware, Inc.
Chapitre 2 Créer et utiliser des clusters vSphere HA
Dénir un seuil de réduction des performances vous permet de spécier l'occurrence d'un problème de
conguration. Par exemple :
La valeur par défaut est 100 %, qui ne produit pas d'avertissements.
n
Si vous réduisez le seuil à 0 %, un avertissement est généré dès que l'utilisation du cluster est supérieure
n
à la capacité disponible.
Si vous réduisez le seuil à 20 %, la réduction des performances pouvant être tolérée est calculée de la
n
manière suivante : performance reduction = current utilization * 20%. Lorsque l'utilisation actuelle
moins la réduction des performances dépasse la capacité disponible, une notication concernant la
conguration est émise.
Contrôle d'admission Pourcentage de ressources de cluster
Il est possible de congurer vSphere HA pour eectuer le contrôle d'admission en réservant un pourcentage
spécique de ressources de CPU et de mémoire du cluster à la récupération en cas de pannes d'hôtes.
Avec ce type de contrôle d'admission, vSphere HA vérie qu'un pourcentage spécié de ressources
cumulées de CPU et de mémoire est réservé au basculement.
Lorsque l'option de pourcentage de ressources de cluster est congurée, vSphere HA met en œuvre le
contrôle d'admission de la manière suivante :
1 Calcule les besoins totaux en ressources pour toutes les machines virtuelles sous tension dans le cluster.
2 Calcule les ressources totales de l'hôte disponibles pour les machines virtuelles.
3 Calcule la Capacité CPU de basculement actuelle et la Capacité mémoire de basculement actuelle du
cluster.
4 Détermine si la Capacité de basculement de CPU actuelle ou la Capacité de basculement mémoire
actuelle sont inférieures ou non à la Capacité de basculement congurée correspondante (spéciée par
l'utilisateur).
Si c'est le cas, le contrôle d'admission n'autorise pas l'opération.
vSphere HA utilise les réserves eectives des machines virtuelles. Si une machine virtuelle n'a pas de
réserves, c'est-à-dire que la valeur de réserve est nulle, les valeurs utilisées par défaut sont 0 Mo de mémoire
et 32 MHz de CPU.
R L'option de pourcentage de ressources de cluster du contrôle d'admission vérie également
qu'il existe au moins deux hôtes compatibles vSphere HA dans le cluster (à l'exception des hôtes qui passent
en mode maintenance). S'il n'y a qu'un hôte compatible vSphere HA, aucune opération n'est autorisée,
même si le pourcentage de ressources disponibles est susant. Cee vérication supplémentaire s'explique
par le fait que vSphere HA ne peut pas eectuer de basculement s'il n'y a qu'un seul hôte dans le cluster.
Calcul de la Capacité de basculement actuelle
Les ressources totales requises par les machines virtuelles sous tension incluent deux composants, CPU et
mémoire. vSphere HA calcule ces valeurs.
Le besoin en composant CPU est obtenu en additionnant le CPU réservé par les machines virtuelles
n
sous tension. Si aucun CPU n'a été réservé pour une machine virtuelle, une valeur de 32 MHz est
dénie par défaut (cee valeur peut être modiée par l'option avancée das.vmcpuminmhz).
La taille du composant de mémoire est obtenue en additionnant la mémoire réservée (plus la capacité
n
supplémentaire de mémoire) de chaque machine virtuelle sous tension.
VMware, Inc. 23
besoins totaux en ressources
7 Ghz, 6 Go
ressources totales de l'hôte
24 GHz, 21 Go
2 Ghz
1 Go
2 Ghz
1 Go
1 Ghz
2 Go
1 Ghz
1 Go
1 Ghz
1 Go
VM1
9 Ghz
9 Go
H1
9 Ghz
6 Go
H2
6 Ghz
6 Go
H3
VM2 VM3 VM4 VM5
Disponibilité vSphere
Les ressources totales des hôtes disponibles pour les machines virtuelles sont calculées en additionnant les
ressources de CPU et de mémoire des hôtes. Ces valeurs sont celles contenues dans le pool de ressources
racine de l'hôte, et non dans les ressources physiques totales de l'hôte. Les ressources utilisées à des ns de
virtualisation ne sont pas incluses. Seuls les hôtes qui sont connectés, qui ne sont pas en mode maintenance
et qui ne présentent pas d'erreurs vSphere HA sont pris en compte.
La Capacité CPU de basculement actuelle est calculée en soustrayant les besoins totaux en ressources CPU
des ressources CPU totales des hôtes et en divisant le résultat par les ressources CPU totales des hôtes. La
Capacité mémoire de basculement actuelle est calculée de la même manière.
Exemple : Contrôle d'admission en utilisant un pourcentage de ressources de
cluster
Nous allons illustrer par un exemple le mode de calcul de la Capacité de basculement actuelle et son
utilisation avec cee règle de contrôle d'admission. Prenons les hypothèses suivantes pour un cluster :
Le cluster est composé de trois hôtes, ayant chacun des quantités diérentes de CPU et de ressources
n
mémoire disponibles. Le premier hôte (H1) a 9 Ghz de ressources CPU et 9 Go de mémoire disponibles.
Le second (H2) a 9 Ghz de CPU et 6 Go de mémoire disponibles et le troisième (H3) a 6 Ghz de CPU et
6 Go de mémoire disponibles.
Il y a cinq machines virtuelles sous tension dans le cluster avec des besoins en CPU et en mémoire
n
diérents. VM1 a besoin de 2 Ghz de ressources CPU et 1 Go de mémoire, tandis que VM2 a besoin de
2 Ghz et 1 Go, VM3 a besoin de 1 Ghz et de 2 Go, VM4 a besoin de 1 Ghz et 1 Go, VM5 a besoin de
1 Ghz et 1 Go.
La capacité de basculement congurée pour le processeur et la mémoire est pour tous deux de 25 %.
n
Figure 2‑1. Exemple de contrôle d'admission utilisant les règles de Pourcentage de ressources de cluster
réservées
Les besoins totaux en ressources des machines virtuelles sous tension sont de 7 Ghz et 6 Go. Les ressources
totales de l'hôte disponibles pour les machines virtuelles sont de 24 Ghz et 21 Go. Partant de là, la Capacité
CPU de basculement actuelle s'élève à 70% ((24 Ghz - 7 Ghz)/24 Ghz). De même, la Capacité mémoire de
basculement actuelle s'élève à 71% ((21 Go - -6 Go)/21 Go).
Comme la Capacité de basculement congurée pour le cluster est de 25 %, 45 % des ressources CPU totales
du cluster et 46 % des ressources mémoire totales du cluster sont toujours disponibles pour les machines
virtuelles supplémentaires.
24 VMware, Inc.
Chapitre 2 Créer et utiliser des clusters vSphere HA
Contrôle d'admission Stratégie d'emplacement
Lorsque l'option de stratégie d'emplacement est congurée, vSphere HA s'assure que même si un nombre
d'hôtes spécié est défaillant, les ressources demeurent en quantité susante sur le cluster pour permere le
basculement de toutes les machines virtuelles depuis ces hôtes.
Avec la stratégie d'emplacement, vSphere HA eectue le contrôle d'admission de la manière suivante :
1 Calcule la taille d'emplacement.
Un emplacement est une représentation logique de la mémoire et des ressources CPU. Par défaut, il est
dimensionné pour satisfaire aux exigences de chaque machine virtuelle sous tension dans le cluster.
2 Détermine le nombre d'emplacements pouvant se trouver sur chaque hôte du cluster.
3 Détermine la Capacité de basculement actuelle du cluster.
Il s'agit du nombre d'hôtes défectueux permeant de conserver un nombre susant d'emplacements
pour satisfaire toutes les machines virtuelles sous tension.
4 Détermine si la Capacité de basculement actuelle est inférieure ou non à la Capacité de basculement
congurée (précisée par l'utilisateur).
Si c'est le cas, le contrôle d'admission n'autorise pas l'opération.
R Vous pouvez dénir une taille d'emplacement spécique pour les CPU et la mémoire dans la
section de contrôle d'admission des paramètres vSphere HA dans vSphere Web Client
Calcul de la taille d'emplacement
Taille d'emplacement et contrôle d'admission de vSphere HA
(hp://link.brightcove.com/services/player/bcpid2296383276001?
bctid=ref:video_vsphere_slot_admission_control)
La taille d'un emplacement est déterminée par deux composants, le CPU et la mémoire.
vSphere HA calcule la taille de CPU à partir du CPU réservé par chaque machine virtuelle sous tension,
n
en sélectionnant la valeur la plus élevée. Si aucun CPU n'a été réservé pour une machine virtuelle, une
valeur de 32 MHz est dénie par défaut. Cee valeur peut être modiée par l'option avancée
das.vmcpuminmhz.)
vSphere HA calcule la taille de la mémoire à partir de la mémoire réservée (plus la capacité
n
supplémentaire de mémoire) de chaque machine virtuelle sous tension, en sélectionnant la valeur la
plus élevée. Il n'y a pas de valeur par défaut pour la mémoire réservée.
Si le cluster contient des machines virtuelles ayant des valeurs de réservation bien plus élevées que d'autres,
celles-ci inueront sur le calcul de la taille d'emplacement. Pour éviter cela, vous pouvez préciser une limite
supérieure pour le CPU ou le composant de mémoire de la taille d'emplacement en utilisant respectivement
les options avancées das.slotcpuinmhz ou das.slotmeminmb. Reportez-vous à « Options avancées de
vSphere HA », page 40.
Vous pouvez également déterminer le risque de fragmentation des ressources dans le cluster en regardant le
nombre de machines virtuelles qui nécessitent plusieurs emplacements. Ceci peut être calculé dans la
section de contrôle d'admission des paramètres vSphere HA dans vSphere Web Client. Les machines
virtuelles peuvent nécessiter plusieurs emplacements si vous avez spécié une taille xe ou maximale
d'emplacements dans les options avancées.
VMware, Inc. 25
Disponibilité vSphere
Utiliser les emplacements pour déterminer la capacité de basculement actuelle
Une fois la taille d'emplacement calculée, vSphere HA détermine les ressources de CPU et de mémoire
disponibles sur chaque hôte pour les machines virtuelles. Ces valeurs sont celles contenues dans le pool de
ressources racine de l'hôte, et non dans les ressources physiques totales de l'hôte. Vous trouverez les
données sur les ressources d'un hôte utilisé par vSphere HA dans l'onglet Résumé de l'hôte, sur
vSphere Web Client. Si tous les hôtes de votre cluster sont identiques, vous pouvez obtenir ces données en
divisant les chires relatifs au cluster dans son ensemble par le nombre d'hôtes. Les ressources utilisées à
des ns de virtualisation ne sont pas incluses. Seuls les hôtes qui sont connectés, qui ne sont pas en mode
maintenance et qui ne présentent pas d'erreurs vSphere HA sont pris en compte.
Le nombre maximum d'emplacements pouvant être pris en charge par chaque hôte est alors déterminé. À
cee n, la quantité de ressources CPU de l'hôte est divisée par le composant de CPU de la taille
d'emplacement et le résultat est arrondi. Le même calcul est fait pour la quantité de ressources de mémoire
de l'hôte. Ces deux valeurs sont comparées et la plus basse équivaut au nombre d'emplacements pouvant
être pris en charge par l'hôte.
La Capacité de basculement actuelle est calculée en déterminant le nombre d'hôtes (en commençant par le
plus gros) pouvant être défectueux tout en conservant un nombre susant d'emplacements pour satisfaire
toutes les machines virtuelles sous tension.
Exemple : Contrôle d'admission en utilisant la stratégie d'emplacement
Nous allons illustrer par un exemple le mode de calcul de la taille d'emplacement et son utilisation avec
cee stratégie de contrôle d'admission. Prenons les hypothèses suivantes pour un cluster :
Le cluster est composé de trois hôtes, ayant chacun des quantités diérentes de CPU et de ressources
n
mémoire disponibles. Le premier hôte (H1) a 9 Ghz de ressources CPU et 9 Go de mémoire disponibles.
Le second (H2) a 9 Ghz de CPU et 6 Go de mémoire disponibles et le troisième (H3) a 6 Ghz de CPU et
6 Go de mémoire disponibles.
Il y a cinq machines virtuelles sous tension dans le cluster avec des besoins en CPU et en mémoire
n
diérents. VM1 a besoin de 2 Ghz de ressources CPU et 1 Go de mémoire, tandis que VM2 a besoin de
2 Ghz et 1 Go, VM3 a besoin de 1 Ghz et de 2 Go, VM4 a besoin de 1 Ghz et 1 Go, VM5 a besoin de
1 Ghz et 1 Go.
Les défaillances d'hôte tolérées par le cluster sont dénies sur la valeur 1.
n
26 VMware, Inc.
6 slots restent
si H1 est défectueux
taille du slot
2 Ghz, 2 Go
2 Ghz
1 Go
2 Ghz
1 Go
1 Ghz
2 Go
1 Ghz
1 Go
1 Ghz
1 Go
VM1
9 Ghz
9 Go
4 slots
H1
9 Ghz
6 Go
3 slots
H2
6 Ghz
6 Go
3 slots
H3
VM2 VM3 VM4 VM5
Chapitre 2 Créer et utiliser des clusters vSphere HA
Figure 2‑2. Exemple de contrôle d'admission avec la stratégie Défaillances d'hôte tolérées par le cluster
1 La taille d'emplacement est calculée en comparant à la fois les exigences de CPU et de mémoire des
machines virtuelles et en sélectionnant la plus élevée.
Le besoin en CPU le plus élevé (partagé par VM1 et VM2) est de 2 GHz, tandis que le besoin en
mémoire le plus élevé (VM3) est de 2 Go. Partant de là, la taille d'emplacement se compose d'un CPU de
2 GHz et d'une mémoire de 2 Go.
2 Le nombre maximum d'emplacements pouvant être pris en charge par chaque hôte est déterminé.
H1 peut prendre en charge quatre emplacements. H2 peut prendre en charge trois emplacements (le
plus bas de 9 GHz/2 GHz et 6 Go/2 Go) et H3 peut aussi en prendre en charge trois.
3 La Capacité de basculement actuelle est calculée.
Le plus gros hôte est H1 et s'il est défectueux, le cluster contient toujours six slots, ce qui est susant
pour les cinq machines virtuelles sous tension. Si H1 et H2 sont défectueux, il ne reste que trois
emplacements, ce qui est insusant. Par conséquent, la Capacité de basculement actuelle est de 1.
Le cluster a un slot disponible (les six slots de H2 et H3 moins les cinq slots utilisés).
Contrôle d'admission sur des hôtes de basculement dédiés
Il est possible de congurer vSphere HA an de désigner des hôtes spéciques comme hôtes de
basculement.
Avec le contrôle d'admission sur des hôtes de basculement dédiés, en cas de panne d'un hôte, vSphere HA
tente de redémarrer ses machines virtuelles sur un des hôtes de basculement prédénis. Si le redémarrage
des machines virtuelles est impossible, notamment lorsque les hôtes de basculement sont eux-mêmes en
panne ou que leurs ressources sont insusantes, vSphere HA tente de redémarrer ces machines virtuelles
sur d'autres hôtes du cluster.
Pour que des capacités restent disponibles sur un hôte de basculement, vous ne pouvez pas mere sous
tension des machines virtuelles ni utiliser vMotion pour faire migrer des machines virtuelles vers un hôte de
basculement. De plus, DRS n'utilise pas d'hôte de basculement pour la répartition de la charge.
R Si vous utilisez le contrôle d'admission sur des hôtes de basculement dédiés et désignez
plusieurs hôtes de basculement, DRS ne cherche pas à faire respecter les règles d'anité VM-VM pour les
machines virtuelles qui s'exécutent sur des hôtes de basculement.
VMware, Inc. 27
Disponibilité vSphere
Interopérabilité de vSphere HA
vSphere HA peut interagir avec de nombreuses autres fonctionnalités, comme DRS et vSAN.
Avant de congurer vSphere HA, vous devez connaître les limitations de son interopérabilité avec ces autres
fonctionnalités ou produits.
Utilisation de vSphere HA avec vSAN
Vous pouvez utiliser vSAN comme stockage partagé pour un cluster vSphere HA. Lorsqu'il est activé, vSAN
regroupe les disques de stockage locaux spéciés qui sont disponibles sur les hôtes dans une banque de
données unique partagée par tous les hôtes.
Avant d'utiliser vSphere HA avec vSAN, vous devez connaître les exigences et les limitations liées à
l'interopérabilité de ces deux fonctionnalités.
Pour plus d'informations sur vSAN, reportez-vous à la section Administration de VMware vSAN.
R Vous pouvez utiliser vSphere HA avec des clusters étendus vSAN.
Conditions requises pour les hôtes ESXI
Pour utiliser vSAN avec un cluster vSphere HA, les conditions suivantes doivent être remplies :
Tous les hôtes ESXi du cluster doivent être de la version 5.5 ou ultérieure.
n
Le cluster doit avoir au moins trois hôtes ESXi.
n
Différences de mise en réseau
vSAN dispose de son propre réseau. Lorsque vSAN et vSphere HA sont activés sur le même cluster, le trac
entre agents HA circule sur ce réseau de stockage plutôt que sur le réseau de gestion. vSphere HA utilise le
réseau de gestion uniquement si vSAN est désactivé. Si vSphere HA est conguré sur un hôte,
vCenter Server choisit le réseau approprié.
R Vous ne pouvez activer vSAN que si vSphere HA est désactivé.
Si vous modiez la conguration de vSAN, les agents vSphere HA ne choisissent pas automatiquement les
nouveaux paramètres réseau. Pour modier le réseau vSAN, vous devez eectuer la procédure suivante
dans vSphere Web Client :
1 Désactivez la surveillance de l'hôte pour le cluster vSphere HA.
2 Modiez le réseau vSAN.
3 Cliquez avec le bouton droit sur chacun des hôtes du cluster et sélectionnez pour vSphere
HA.
4 Réactivez la surveillance de l'hôte pour le cluster vSphere HA.
Tableau 2-2 montre les diérences dans la mise en réseau vSphere HA, que vSAN soit utilisé ou non.
28 VMware, Inc.
Chapitre 2 Créer et utiliser des clusters vSphere HA
Tableau 2‑2. Différences de mise en réseau de vSphere HA
vSAN activé vSAN désactivé
Réseau utilisé par vSphere HA Réseau de stockage vSAN Réseau de gestion
Banques de données de signaux de
pulsation
Hôte déclaré comme isolé Adresses d'isolation ne répondant pas
Toutes les banques de données
montées sur plusieurs hôtes, sauf les
banques de données vSAN
aux commandes ping et réseau de
stockage vSAN inaccessible
Toutes les banques de données
montées sur plusieurs hôtes
Adresses d'isolation ne répondant pas
aux commandes ping et réseau de
gestion inaccessible.
Paramètres de réservation de capacité
Lorsque vous réservez de la capacité pour votre cluster vSphere HA en utilisant une stratégie de contrôle
d'admission, ce paramètre doit être cohérent avec le paramètre de vSAN correspondant qui permet
d'assurer l'accessibilité des données en cas de panne. Plus précisément, la valeur du paramètre dénissant le
nombre de pannes toléré dans l'ensemble des règles de vSAN ne doit pas être inférieure à la capacité
réservée par le paramètre de contrôle d'admission de vSphere HA.
Par exemple, si l'ensemble de règles de vSAN n'autorise que deux pannes, la stratégie du contrôle
d'admission de vSphere HA doit réserver une capacité équivalente à seulement une ou deux pannes d'hôte.
Si vous utilisez la stratégie du pourcentage de ressources de cluster réservées sur un cluster disposant de
huit hôtes, vous ne devez pas réserver plus de 25 % des ressources du cluster. Si vous utilisez la stratégie des
pannes d'hôtes tolérées par le cluster sur ce même cluster, la valeur du paramètre ne doit pas dépasser deux
hôtes. Si vSphere HA réserve moins de capacité, l'activité de basculement peut s'avérer imprévisible. La
réservation d'une capacité trop grande impose une contrainte excessive à l'activation des machines virtuelles
et aux migrations vSphere vMotion entre clusters.
Utilisation conjointe de vSphere HA et DRS
L'utilisation de vSphere HA avec Distributed Resource Scheduler (DRS) allie le basculement automatique à
l'équilibrage de la charge. Cee association peut aboutir à un cluster mieux équilibré une fois que vSphere
HA a déplacé les machines virtuelles sur d'autres hôtes.
Quand vSphere HA exécute le basculement et redémarre les machines virtuelles sur des hôtes diérents, sa
première priorité est la disponibilité immédiate de toutes les machines virtuelles. Après le redémarrage des
VM, les hôtes sur lesquels elles sont mises sous tension peuvent se retrouver surchargés, tandis que la
charge d'autres hôtes est, en comparaison, plus légère. vSphere HA utilise le CPU et la réservation de
mémoire de la VM pour déterminer si un hôte dispose de susamment de capacité disponible pour prendre
en charge la VM.
Dans un cluster utilisant DRS et vSphere HA avec le contrôle d'admission activé, les machines virtuelles ne
sont pas nécessairement évacuées des hôtes passant en mode maintenance. Ce comportement intervient par
suite des ressources réservées pour le redémarrage des machines virtuelles en cas de panne. Il faut migrer
manuellement les machines virtuelles en dehors des hôtes avec vMotion.
Dans certains cas, vSphere HA ne parvient pas à basculer les machines virtuelles en raison de contraintes de
ressources. Ceci peut se produire pour plusieurs raisons.
Le contrôle d'admission HA est désactivé et Gestion de l'alimentation distribuée (DPM) est activé. Cela
n
peut aboutir à la consolidation par DPM des machines virtuelles sur un nombre inférieur d'hôtes et à la
mise en veille des hôtes vides, ce qui ne laisse pas susamment de réserve de capacité active pour
eectuer un basculement.
Les règles (requises) d'anité de machine virtuelle/hôte peuvent limiter les hôtes sur lesquels certaines
n
machines virtuelles peuvent être placées.
Il peut y avoir susamment de ressources cumulées mais celles-ci sont fragmentées sur plusieurs hôtes
n
de sorte qu'elles ne peuvent pas être utilisées par les machines virtuelles pour le basculement.
VMware, Inc. 29
Disponibilité vSphere
Dans ces cas-là, vSphere HA peut utiliser DRS pour essayer d'ajuster le cluster (par exemple, en sortant les
hôtes du mode veille ou en migrant les machines virtuelles pour défragmenter les ressources du cluster) de
sorte que HA puisse exécuter les basculements.
Si DPM est en mode manuel, vous devrez éventuellement conrmer les recommandations de mise sous
tension des hôtes. De même, si DPM est en mode manuel, vous devrez éventuellement conrmer les
recommandations de migration.
Si vous utilisez les règles d'anité entre VM et hôte requises, sachez que ces règles doivent obligatoirement
être respectées. vSphere HA n'eectue pas de basculement si cela risque d'enfreindre une règle.
Pour plus d'informations sur DRS, consultez la documentation Gestion des ressources vSphere.
Règles d'affinités de vSphere HA et DRS
Si vous créez une règle d'anité DRS pour votre cluster, vous pouvez indiquer de quelle manière vSphere
HA doit appliquer cee règle en cas de basculement d'une machine virtuelle.
Les deux types de règles pour lesquelles vous pouvez le comportement de vSphere HA en cas de
basculement sont les suivants :
Les règles d'anti-anité de machine virtuelle contraignent les machines virtuelles spéciées à rester
n
séparées pendant les opérations de basculement.
Les règles d'anité machine virtuelle/hôte placent les machines virtuelles spéciées sur un hôte
n
particulier ou un membre d'un groupe d'hôtes déni pendant les opérations de basculement.
Lorsque vous modiez une règle d'anité DRS, cochez la ou les cases appliquant le comportement de
basculement souhaité pour vSphere HA.
HA doit respecter les règles VM pendant le basculement : si les machines virtuelles
n
avec cee règle doivent être placées ensemble, le basculement est abandonné.
HA devrait respecter les règles VM pendant le basculement : vSphere HA tente de
n
placer les machines virtuelles soumises à cee règle sur les hôtes spéciés le cas échéant.
R vSphere HA peut redémarrer une machine virtuelle dans un cluster sur lequel DRS est
désactivé, en remplaçant un mappage de règles d'anité machine virtuelle/hôte si l'échec de l'hôte a lieu
rapidement (par défaut en moins de 5 minutes) après avoir déni la règle.
Autres problèmes d'interopérabilité de vSphere HA
Pour utiliser vSphere HA, vous devez connaître les problèmes d'interopérabilité supplémentaires suivants.
VM Component Protection
VM Component Protection (VMCP) connaît les problèmes et limitations de l'interopérabilité suivants :
VMCP ne prend pas en charge vSphere Fault Tolerance. Si VMCP est activé pour cluster utilisant Fault
n
Tolerance, les machines virtuelles FT aectées recevront automatiquement des remplacements qui
désactivent VMCP.
VMCP ne détecte pas ni ne réagit aux problèmes d'accessibilité des chiers situés sur des banques de
n
données vSAN. Si les chiers de conguration et VMDK d'une machine virtuelle sont situés
uniquement sur des banques de données vSAN, ils ne sont pas protégés par VMCP.
VMCP ne détecte pas ni ne réagit aux problèmes d'accessibilité des chiers situés sur des banques de
n
données Virtual Volumes. Si les chiers de conguration et VMDK d'une machine virtuelle sont situés
uniquement sur des banques de données Virtual Volumes, ils ne sont pas protégés par VMCP.
VMCP ne protège pas contre le mappage de périphérique brut (Raw Device Mapping, RDM)
n
inaccessible.
30 VMware, Inc.
Loading...