En fonction de la puissance des équipements dont nous disposons et des ressources nécessaires à nos systèmes, nous aurons un ratio moyen de machines virtuelles par serveur.
Prenons par exemple la maintenance programmée d'un serveur dans le Centre de calcul. Il y a quelques années, si cela ne faisait pas partie d'un cluster, le système contenu dans l'équipement serait mis hors ligne, par conséquent les utilisateurs seraient également affectés et/ou le personnel impliqué dans la maintenance devait travailler dans des fenêtres de temps réduites (pour ne pas dire inconfortable).
Dans le cas d'un environnement virtualisé, les machines virtuelles peuvent simplement être « déplacées ou migrées » vers un autre membre d'un cluster et l'équipement peut être arrêté pour fonctionner dessus. Problème résolu.
Commençons par voir les situations où le manque de service n'est pas programmé.
Surveillance des machines virtuelles et des applications
Chaque fois que nous créons une machine virtuelle, il est recommandé d'installer un recueil d'applications et de pilotes qui optimisent le comportement du matériel virtuel dans son intégralité (disponible pour Windows, Mac OS, Linux et autres OS). Ces outils, appelés VMTools, incluent entre autres la possibilité pour l'hôte de surveiller la machine virtuelle (via des heartbeats, comme dans les clusters). S'il ne répond pas dans un certain délai, il redémarre votre système d'exploitation.
Un cas similaire se produit avec la surveillance des applications, mais vous devez d'abord obtenir le SDK approprié (ou utiliser une application qui prend en charge la surveillance des applications VMware).
Mais… que se passe-t-il si le défaut est matériel ?
Le cluster mentionné ci-dessus est la première couche de la solution.
Stockage partagéOù tous les membres du cluster ont accès aux machines virtuelles.
Équipe de réseauFace à la défaillance d'une carte, les autres continuent de gérer le trafic.
Chemins multiples (multipathing)Pour le stockage, ils permettront non seulement d'optimiser l'accès mais aussi de redonner de l'argent.
D'une manière générale, ces trois technologies atténuent le temps où nos informations sont inaccessibles. Désormais, en fonction des licences dont nous disposons, nous pouvons également disposer de deux fonctionnalités très intéressantes : la haute disponibilité (HA) et la tolérance aux pannes (FT).
Dans les deux cas, nous avons besoin d'un cluster avec stockage partagé. Sans avoir besoin d'installer de logiciel supplémentaire, la haute disponibilité peut être activée et configurée de telle sorte que si un serveur ou une machine virtuelle tombe en panne dans le cluster, il démarre automatiquement sur un autre membre du cluster. Il convient de préciser que la haute disponibilité n'est pas destinée aux machines virtuelles critiques (machines virtuelles). Ainsi le temps estimé sans service sera : "Démarrage du système d'exploitation + Démarrage des services".
Nombre de pannes d'hôte prises en charge par le cluster
Nous avons un nombre X de machines virtuelles réparties sur Y serveurs dans un cluster.
Combien d'hôtes peuvent tomber en panne sans affecter la disponibilité et les performances de notre environnement virtuel ?
La haute disponibilité peut être configurée pour prendre en charge un nombre spécifique de pannes de serveur, garantissant qu'il reste suffisamment de ressources pour la récupération.
La HA découpe les ressources disponibles d'un cluster en tenant compte du CPU et de la RAM configurés et consommés par nos machines virtuelles de manière très conservatrice. Il prend la plus grande réservation de CPU configurée de toutes les machines virtuelles sur chaque hôte du cluster, puis la plus grande réservation de mémoire et son excès. S'il n'y a pas de réservation configurée, il faudra un minimum de 32 Mhz par VM pour le CPU et 0 Mo de RAM + son excédent.
Avec ces chiffres, il suppose que chaque machine virtuelle utilisée consommera ce processeur et cette mémoire, puis il génère une valeur appelée taille de l'emplacement. Avec cette valeur, il est déterminé combien de slots sont disponibles/utilisés par chaque hôte.
Le problème se pose lorsque, par exemple, nous avons une seule machine avec une grande réserve CPU et mémoire. En prenant des réservations configurées, il est très probable que le reste de nos machines virtuelles n'ait pas vraiment besoin de ces ressources, d'où moins de slots pour notre cluster.
Pourcentage de ressources de cluster comme capacité d'échec
Contrairement à l'option précédente, celle-ci fonctionne très bien lorsque vous avez des machines virtuelles avec des configurations CPU et mémoire très variables.
Il est possible de configurer séparément les valeurs en pourcentage du processeur et de la mémoire, ce qui est encore plus flexible et permet ainsi d'économiser des ressources. Il s'agit généralement de la méthode préférée pour configurer la haute disponibilité.
Hôtes pour le basculement
Il s'agit de la configuration de cluster de secours typique. Cette option est principalement donnée car certaines organisations maintiennent des politiques qui indiquent qu'il doit y avoir des serveurs en veille en cas de sinistre. Étant donné que VMware gère bien la tolérance aux pannes, ce serait peut-être l'option lorsque les ressources sont abondantes… mais certainement pas la meilleure.
vMouvement : Migrations en direct
La migration en direct vous permet de déplacer des machines virtuelles opérationnelles d'un serveur physique à un autre tout en conservant votre connexion réseau et votre identité. La mémoire active (processus en cours d'exécution) est transférée sur le réseau à grande vitesse. L'ensemble du processus prend moins de 5 secondes sur un réseau gigabit.
Il est possible de déplacer la VM, les fichiers qu'elle utilise, ou les deux, et la procédure peut être effectuée avec la machine allumée ou éteinte. Dans ce dernier cas, nous l'appelons "migration à froid" et si la machine est en cours d'exécution, nous l'appelons vMotion.
Utilisations et avantages de vMotion
- Réorganisation des VM, optimisant ainsi les ressources. Supprimez-les des serveurs sujets aux pannes ou saturés.
- Optimisation automatique des ressources disponibles (Je travaille en collaboration avec Dynamic Resource Scheduler ou DRS).
- Faire maintenance de l'infrastructure sous-jacente pas besoin de planification de maintenance ou d'interruption d'activité.
Chaque composant de l'intégrité de la machine virtuelle est géré différemment lors de la migration. La configuration générale est la plus simple, elle ne bouge pas mais est recréée sur le poste cible.
Étant donné que le disque ne peut pas être recréé en si peu de temps, il est nécessaire d'avoir un stockage partagé. L'état actuel de la mémoire est progressivement copié sur l'hôte de destination. A la fin de la copie, les différences existantes survenues lors de la migration sont comparées, l'état de la VM source est figé et le système d'exploitation est activé sur la VM de destination .
Parce que dans certains cas, l'option de redémarrage de la machine n'est pas idéale, pour les missions critiques, nous avons la Tolérance aux pannes. Ce qui est souhaité dans ces cas ne cesse de fonctionner à aucun moment, même si son hôte tombe en panne. La seule façon pour que cela soit possible est que la VM s'exécute à deux endroits en même temps. Il est configuré au niveau de la machine virtuelle et générera une copie exacte de la VM, en la gardant 100% répliquée à tout moment sur un autre serveur, donc en cas de panne matérielle, son jumeau continuera simplement à fonctionner sans aucune perte d'informations. Intéressant, non ?
S'il ne s'agissait que de ressources, nous activerions FT dans toutes les machines virtuelles de notre centre de données, mais dans les versions précédentes de vSphere, nous avons rencontré certaines limitations, la plus importante : il n'était pas possible d'activer FT dans les machines qui utilisaient plusieurs processeur. Heureusement, dans la dernière version du produit, il prend en charge jusqu'à 4 processeurs virtuels simultanément par machine protégée, cependant une licence devra être prise en compte :
Le nombre de vCPU pris en charge par une machine virtuelle compatible FT est limité par le niveau de licence acheté pour vSphere.
La tolérance aux pannes est prise en charge comme suit :
- vSphere Standard et Entreprise. Autorise jusqu'à 2 vCPU.
- vSphere Entreprise Plus. Autorise jusqu'à 4 vCPU.
Ce n'est pas la seule exigence du système.
StockageLes machines virtuelles doivent avoir un stockage partagé. Il n'est pas possible d'utiliser le RDM physique (Raw Devide Mapping).
RapporterIl est nécessaire d'avoir au moins deux cartes virtuelles (vmnics), une pour vMotion et l'autre (10 gbps) pour FT Logging. C'est une nouvelle exigence de la version 6 (auparavant, des plaques de 1 gbps étaient nécessaires)
ProcesseurLes processeurs et les systèmes d'exploitation doivent être compatibles avec FT (et entre eux).
Limites
- Il n'est pas possible de prendre des instantanés des machines virtuelles protégées par FT et elles doivent être supprimées avant d'activer cette fonction.
- Disques virtuels (VMDK) supérieurs à 2 To.
- Il existe une liste de périphériques et de fonctionnalités spécifiques dans la documentation VMware.
Et il y a aussi une limitation sur le nombre de VM par serveur : un maximum de 4 machines protégées par hôte ou 8 vCPU protégés (selon la limite qui vient en premier). Ces maximums incluent la machine principale et secondaire (et les vCPU)
Différences entre FT hérité (précédent) et actuel
IPv6
Legacy FT = Non pris en charge par les cartes réseau configurées pour la journalisation FT FT = Pris en charge
API VStorage - Sauvegarde avec protection des données
FT hérité = non pris en charge FT = pris en charge
Disque virtuel
Legacy FT = EZT (Eager Zeroed Thick) FT = Tous les types, y compris épais et minces
Redondance Vmdk (disque virtuel)
Legacy FT = Single copy FT = Les machines principale et secondaire conservent des copies indépendantes, ce qui leur permet d'être stockées dans différentes banques de données et d'augmenter la redondance
Bande passante de la plaque réseau
Legacy FT = carte réseau 1 Go dédiée recommandée FT = carte réseau 10 Go dédiée recommandée
Compatibilité CPU et hôte
Legacy FT = Nécessite le même modèle de processeur et la même famille. Versions presque identiques de vSphere FT = les CPU doivent être compatibles avec vSphere vMotion ou EVC. La version de VSphere doit être compatible avec vSphere vMotion
Activer / Désactiver FT avec la machine en marche
FT hérité = pas toujours pris en charge FT = pris en charge
N'oubliez pas que FT protège contre les défaillances matérielles du serveur, et non contre les défaillances des systèmes d'exploitation ou des applications.
Chien de garde de vCenter Server il s'agit d'une fonctionnalité intégrée de la version 6.x. Il vérifie périodiquement l'état des services qui composent vCenter, il redémarrera les processus d'administration ou la VM si nécessaire.
