vSphere vMotion et Storage vMotion

Dans les centres de données, les interruptions planifiées constituent une part significative des indisponibilités de service. Elles sont généralement liées à des opérations essentielles comme les mises à jour ou la maintenance matérielle, contraignant les entreprises à redémarrer les serveurs physiques ou à migrer les machines virtuelles durant des fenêtres de maintenance restreintes.

Avec vSphere vMotion, VMware a apporté une solution efficace pour atténuer les effets des interruptions planifiées. La technologie vMotion offre la possibilité de migrer des machines virtuelles en cours d’exécution (à chaud), d’un hôte physique à un autre ou d’un stockage à un autre (Storage vMotion), sans interruption de service ni perte de connectivité, et permet d’effectuer des opérations de maintenance sur les hôtes physiques sans perturber la production, tout en garantissant la disponibilité de l’infrastructure.

Avec vMotion et Storage vMotion, il devient possible d’intervenir à tout moment sur l’infrastructure physique sans affecter les services, et il n’est plus nécessaire de planifier des fenêtres de maintenance spécifiques, ce qui offre une grande flexibilité opérationnelle.

La migration...

VMware HA

Lorsque des services critiques sont hébergés sur des VM, leur disponibilité doit être assurée. vSphere permet cela à travers l’utilisation d’un cluster vSphere HA.

vSphere High Availability (HA) est une fonctionnalité de VMware qui permet de redémarrer automatiquement les machines virtuelles sur un autre hôte du cluster en cas de défaillance d’un hôte physique. Elle garantit une continuité de service sans intervention manuelle.

Les étapes principales du processus vSphere HA sont les suivantes :

détection de panne ;
évaluation des ressources suffisantes pour redémarrer les VM ;
redémarrage des VM.

vSphere HA

1. Fonctionnement de vSphere HA

Lorsque vSphere HA est activé sur un cluster, un agent est installé sur chaque ESXi et un hôte principal est élu (généralement celui avec le plus de datastores) pour surveiller en continu les autres hôtes et les machines virtuelles afin de détecter les pannes. Les hôtes secondaires assurent la surveillance des machines virtuelles qu’ils hébergent (avec VMware Tools) et transmettent les informations à l’hôte principal.

En cas d’indisponibilité de l’hôte principal, un nouveau est automatiquement élu pour garantir la continuité du cluster.

L’hôte principal de vSphere HA surveille en permanence la réactivité des hôtes secondaires du cluster à l’aide de signaux de pulsation réseau échangés chaque seconde. Si un hôte secondaire cesse d’envoyer ces pulsations, le principal vérifie sa connectivité via des pings ICMP et l’accès aux banques de données. Si aucune réponse n’est reçue et que l’agent HA ne transmet plus de pulsations, l’hôte est considéré comme défaillant et ses machines virtuelles sont redémarrées sur un autre hôte disponible.

Cependant, si l’hôte secondaire continue à échanger des pulsations avec une banque de données, il est considéré, soit comme isolé (lorsqu’il ne détecte plus le trafic HA sur le réseau de gestion et ne parvient pas à joindre les adresses...

VMware Fault Tolerance FT

Fault Tolerance est une technologie de haute disponibilité avancée dans vSphere qui permet à une machine virtuelle de continuer à fonctionner sans interruption, même en cas de panne d’un hôte ESXi. Contrairement à vSphere HA, qui redémarre les VM sur un autre hôte après une panne, FT assure une continuité immédiate grâce à une réplication en temps réel.

Fault Tolerance crée une VM secondaire sur un autre hôte ESXi. Cette VM secondaire est synchronisée en continu avec la VM principale, si l’hôte de la VM principale tombe en panne, la VM secondaire prend le relais instantanément, sans perte de données ni redémarrage.

Les prérequis pour utiliser FT sont les suivants :

Une licence pour FT.
Un cluster vSphere HA avec au moins deux hôtes ESXi avec stockage partagé.
Journalisation de Fault Tolerance et réseau vMotion configuré.
Les hôtes doivent utiliser des processeurs pris en charge.

L’utilisation de Fault Tolerance dans vSphere impose certaines restrictions. Plusieurs fonctionnalités de VMware vSphere sont incompatibles avec les machines virtuelles protégées par FT comme les snapshots de VM, le Storage vMotion ou les volumes virtuels (vVols).

Pour configurer un adaptateur VMkernel dédié à...

VMware DRS

Distributed Resource Scheduler (DRS) est une fonctionnalité clé de VMware vSphere qui permet d’équilibrer automatiquement la charge des machines virtuelles entre les hôtes ESXi d’un cluster. Son objectif principal est d’optimiser l’utilisation des ressources et d’éviter les conflits de performance.

Placement initial intelligent : lors du démarrage d’une VM, DRS sélectionne l’hôte le plus adapté en fonction des ressources disponibles.
Rééquilibrage dynamique : pendant l’exécution, DRS surveille en continu les niveaux d’utilisation et ajuste la répartition des VM pour maintenir un équilibre optimal.
Migration proactive : en cas de surcharge d’un hôte, DRS peut migrer les VM vers des hôtes moins sollicités à l’aide de vMotion, sans interruption de service.

DRS peut être configuré selon différents niveaux d’automatisation :

Mode	Comportement
Manuel	DRS propose des recommandations, mais aucune action n’est prise automatiquement.
Partiellement automatisé	DRS place les VM au démarrage, mais les migrations ultérieures nécessitent une validation manuelle.
Entièrement automatisé	DRS prend en charge le placement initial et les migrations sans intervention humaine.

DRS exige des prérequis essentiels pour fonctionner correctement dans un environnement VMware vSphere :

le vMotion activé et configuré ;
accès partagé aux datastores ;
une licence valide pour DRS ;
Enhanced vMotion Compatibility (EVC) activé si nécessaire.

1. Enhanced vMotion Compatibility

Lors de la création d’un cluster DRS, vous pouvez activer la compatibilité Enhanced vMotion (EVC) afin de garantir la migration à chaud des machines virtuelles entre des hôtes ESXi dotés de processeurs différents.

EVC crée une référence CPU commune que tous les hôtes du cluster doivent respecter. Cela permet à chaque hôte de présenter les mêmes fonctionnalités CPU aux machines virtuelles, même si leurs processeurs physiques sont différents.

EVC ne fonctionne qu’avec des processeurs d’une même famille, il est interdit de mélanger...