Part 2
Partition
On parle de partition d’un cluster lorsque plusieurs groupes
d’hôtes se forment, suite à un incident réseau par exemple.
Le groupe d’hôte ne comportant pas d’hôte Maître va en élire
un afin d’assurer son autonomie, en terme de redémarrage des VMs, en cas de
perte d’un hôte. Lorsque l’incident réseau est résolu, un des deux hôtes Maître
abdique au profit du second.
Configuration de HA
Le contrôle d’admission
L’ « admission control » est le mécanisme
utilisé par le serveur vCenter pour s’assurer d’avoir suffisamment de
ressources disponibles pour faire redémarrer tout ou partie des VMs en cas de
sinistre.
Un hôte du cluster mis en Mode Maintenance ou retiré du
cluster modifie les ressources disponibles pour le Fail over.
Il est ainsi possible d’adopter deux positions :
-
Je veux être certain de faire redémarrer TOUTES
mes VMs en cas de sinistre : le système nous empêchera de démarrer des VMs
supplémentaires lorsqu’il jugera ne plus être en mesure d’assurer le Fail over
complet de l’Infrastructure.
-
J’accepte DE NE PAS faire redémarrer
toutes mes VMs en cas de sinistre : je pourrai continuer à démarrer mes VMs
« sans limite », mais en cas de sinistre sur un des hôtes du cluster,
je suis certain de ne pas avoir suffisamment de ressources pour assurer un Fail
over complet. Il faudra alors définir une politique de « restart
priority »
VMware met à notre disposition trois politiques de contrôle
d’admission pour déterminer la quantité de ressources nécessaires au Fail
over:
-
« Host failures cluster tolerates » :
Nombre d’hôtes que j’accepte de perdre tout en étant certain de conserver ma
capacité de Fail over. Cette méthode se base sur le calcul de la taille de slot
utilisé par chaque VM. La taille du slot est composée de la quantité de CPU et
de RAM configurée (réservations comprises) la plus grosse VMs des hôtes du
cluster.
Le système divise la quantité de ressources disponible sur
chaque hôte par la taille du slot pour déterminer le nombre de VM qu’il est
possible de faire fonctionner sur chaque hôte. Ainsi, le système considère qu’il
faut être capable de supporter la perte du plus gros des hôtes ESXi et d’en absorber
la charge. Lorsque tous les slots disponibles sont utilisés, un message nous
indique qu’il n’y a plus de ressources disponibles.
-
« Percentage of cluster resources reserved
as failover spare capacity» : un pourcentage de ressources CPU et/ou RAM
est conservé pour le Fail over (pas de calcul de taille de slot)
-
« Specify a failover host » : un
ou plusieurs hôtes sont conservés pour le Fail over. Des VMs ne tournent dessus
qu’en cas de Fail over : ce sont des hôtes de Spare(pas de calcul de
taille de slot)
Comparaison des avantages et limites des
différents types de contrôle d’admission
Admission control
|
Avantages
|
Limites
|
Host failures cluster tolerates
|
- Ajustement
automatique du nombre de slots disponibles lors de l’ajout (ou du retrait)
d’un hôte dans le cluster HA
- Fail
over assuré par le calcul des slots : méthode la plus contraignante pour
l’infrastructure
|
- Le
calcul des slots est très (trop) conservatif et inflexible lorsque des
réservations de CPU et RAM ont été positionnés sur les VMs
- Un
cluster composé d’hôtes non homogènes entraine un gaspillage de ressources
important
|
Percentage
of cluster resources reserved as failover spare capacity
|
- Méthode
plus souple dans le cas de réservations de ressources
- Ajustement
automatique des ressources conservées pour le Fail over lors de l’ajout de
RAM et de CPU dans les hôtes du cluster
- Possibilité
de spécifier des % de CPU et de RAM différents pour le Fail over (70% pour
l’un et 80% pour l’autre par exemple)
|
- Ajustement
manuel des % de ressources dédiés au Fail over à faire lors de l’ajout d’un
hôte dans le cluster HA
- Le
nombre de d’hôtes dont on a calculé la perte de doit pas évoluer sans refaire
les calculs
- Un
cluster composé d’hôtes non homogènes peut être un problème en cas de % trop
bas (un hôte pourrait se retrouver à n’être quasiment pas utilisé)
|
Specify a failover host
|
-
What you see is what you get.
- Possibilité
de spécifier plusieurs hôtes de Fail over
|
-
What you see is what you get.
- L’hôte
dédié au Fail over n’est JAMAIS utilisé en fonctionnement nominal
|
Restart priority
Le « restart priority » est la configuration que
l’on peut apporter au redémarrage des VMs en cas de perte d’un hôte.
Si le Contrôle d’admission n’a pas été activé , il faudra positionner une priorité
de redémarrage des VMs, en fonction de leur environnement par exemple, afin de
faire démarrer en premier les VMs qui nous semblent les plus importantes.
Ainsi, on peut imaginer que les VMs de production et d’intégration seront redémarrées avant les VMs de développement,
qui elles-mêmes seront démarrées avant les VMs de prototype.
Il faut cependant garder à l’esprit que la capacité à
démarrer les VMs est contrainte par les ressources encore disponibles dans le
cluster en cas de Fail over : configurer un « restart priority »
sur les VMs d’un cluster garantie que certaines VMs seront redémarrées avant
d’autres, mais rien ne garantit qu’elles seront toutes redémarrées.
Les trois niveaux de « restart priority »
sont :
·
High
·
Medium (valeur par défaut)
·
Low
ð
Configurer toutes les VMs en high aura le même
impact que toute les configurer en low.
Types d’incidents et conséquences sur les VMs
Perte du serveur vCenter
La perte du serveur vCenter n’a aucune incidence sur le
fonctionnement des autres VMs des clusters.
S’il devait y avoir un incident sur l’hôte qui héberge le
vCenter et que toutes les VMs hébergées dessus tombent, les agents FDM sont
autonomes et sont capables de faire redémarrer l’ensemble de ces VMs (dans la
limite des ressources disponibles).
0 commentaires :
Enregistrer un commentaire