La fonctionnalité VMware Fault Tolerance (FT) assure une disponibilité continue des machines virtuelles en maintenant une instance secondaire active. Elle protège contre les défaillances d’hôte sans aucune interruption de service. Cette fonction utilise un mécanisme synchrone d’enregistrement et de lecture pour refléter l’exécution de la machine virtuelle. Sa configuration exige une attention particulière en ce qui concerne le processeur, le réseau et le stockage. Ce guide progresse des notions de base aux détails les plus avancés, couvrant les prérequis, le fonctionnement, la configuration, les tests, la surveillance ainsi que les compromis par rapport à la haute disponibilité (HA).
Qu’est-ce que VMware Fault Tolerance ?
VMware Fault Tolerance garantit une disponibilité continue en exécutant une machine virtuelle secondaire en parallèle exacte avec la machine virtuelle principale. Elle capture les événements non déterministes sur la machine virtuelle principale et les applique à la machine virtuelle secondaire avant leur exécution. Cette dernière reste passive concernant les entrées/sorties externes, mais active lors de la relecture. En cas de défaillance de l’hôte principal, la machine virtuelle secondaire prend immédiatement le relais. Fault Tolerance utilise la technologie vLockstep pour répliquer au niveau des instructions les états du processeur et de la mémoire. Cela garantit une perte de données nulle zéro perte de données et un service ininterrompu.
Comment la tolérance aux pannes VMware fonctionne-t-elle ?
La tolérance aux pannes (FT) repose sur une réplication synchrone de l’état au niveau des instructions. Elle enregistre les registres du processeur, les mises à jour mémoire et les entrées non déterministes telles que les interruptions et les paquets réseau sur la machine principale. Ces enregistrements sont transmis via un réseau dédié de journalisation FT vers la machine secondaire. Cette dernière rejoue les instructions pas à pas, mais bloque toute entrée/sortie externe jusqu’à la basculée. Seule la machine principale émet des écritures sur le stockage ou des envois réseau. Cela évite le « split-brain » en garantissant qu’une seule source d’entrées/sorties est active. La FT utilise des verrous atomiques (par exemple, les réservations persistantes SCSI-3) sur le stockage partagé afin de coordonner la basculée, ce qui garantit qu’après une panne, une seule copie s’exécute en tant que machine principale.
FT utilise un adaptateur de journalisation VMkernel FT. La machine principale capture les événements et les transmet à la machine secondaire avant l’exécution des instructions. La machine secondaire les rejoue dans le même ordre. Les entrées/sorties réseau et de stockage s’achèvent sur la machine principale ; la machine secondaire attend. Si l’hôte principal tombe en panne (coupure d’alimentation, erreur fatale du système PSOD, isolement du réseau de gestion dépassant le délai d’attente ou arrêt brutal du processus vmx), le signal de cœur cesse. La machine secondaire prend immédiatement le relais en tant que machine principale, en se basant sur son état rejoué. Une nouvelle machine secondaire est automatiquement créée sur un autre hôte. FT évite les lacunes de données grâce à des verrous atomiques sur le stockage et à une synchronisation d’état synchrone.
⚫ Synchronisation stricte et événements non déterministes
vLockstep capture les événements susceptibles de modifier les chemins d’exécution : les interruptions, la finalisation des opérations d’entrée/sortie (I/O) et les instructions basées sur le temps (par exemple, RDTSC). Ces événements sont enregistrés sur le système principal, puis transmis via la journalisation FT. Ils sont ensuite injectés dans l’exécution du système secondaire avant l’exécution de ces instructions. Cela garantit que les deux machines virtuelles reçoivent des entrées identiques. Le fait d’enregistrer uniquement les entrées non déterministes permet de maintenir un volume réduit des données journalisées, comparé aux sauvegardes complètes de l’état. Le système secondaire rejoue l’état du processeur et de la mémoire de façon synchronisée, mais attend les opérations d’entrée/sortie externes jusqu’à la reprise de contrôle.
⚫ Réplication synchrone de l’état
La technologie FT reproduit les registres du processeur et l’état mémoire au niveau de chaque instruction. Il ne s’agit pas d’une réplication au niveau des blocs. Cela garantit que l’état interne de la machine secondaire correspond exactement à celui de la machine principale à chaque point d’exécution d’une instruction. Le réseau de journalisation FT doit acheminer les enregistrements avec une latence minimale. Tout retard peut provoquer un blocage des machines virtuelles si les tampons se remplissent. Par conséquent, une bande passante dédiée et des chemins à faible latence sont essentiels. Le trafic de journalisation FT peut atteindre plusieurs centaines de mégabits par seconde pour les machines virtuelles fortement sollicitées par le processeur.
⚫ Gestion des entrées/sorties et prévention des scénarios de « split-brain »
Seule la machine virtuelle principale effectue les E/S externes : écritures sur le disque, envoi de paquets réseau. La machine virtuelle secondaire reste passive concernant les E/S jusqu’à la bascule. Cela évite d’avoir deux sources actives d’E/S. Le stockage partagé utilise un verrouillage atomique des fichiers, souvent via des réservations persistantes SCSI-3, afin d’empêcher les deux machines virtuelles d’accéder aux disques en tant que principales après une défaillance. Lors de la bascule, la machine virtuelle secondaire obtient la réservation et poursuit l’exécution. Si la machine virtuelle principale d’origine revient en ligne, elle crée une nouvelle machine virtuelle secondaire au lieu de reprendre son rôle de principale.
⚫ Déclencheurs de basculement
Le basculement FT se déclenche lorsque l’hôte principal devient injoignable ou tombe en panne. Les causes possibles incluent une coupure d’alimentation de l’hôte, un PSOD (Purple Screen of Death), un arrêt brutal du processus vmx (par exemple, via la commande esxcli) ou une isolation du réseau de gestion dépassant le délai de tolérance défini pour le basculement automatique (HA). FT surveille le signal de présence (heartbeat) via le canal de journalisation FT. Lorsque ce signal cesse, l’hôte secondaire prend immédiatement le relais en tant qu’hôte principal. vCenter enregistre cet événement dans ses journaux. Un nouvel hôte secondaire est automatiquement déployé sur un hôte compatible.
Comment configurer et utiliser la tolérance aux pannes dans VMware ?
Cette section vous guide à travers les conditions préalables, l’activation de la tolérance aux pannes (FT), les tests de basculement et la maintenance. Elle suppose que vous connaissez déjà les concepts vSphere tels que l’EVC, le DRS et le HA.
Conditions préalables et configuration
Assurez la compatibilité des processeurs en activant EVC avant la mise en œuvre de FT. Veillez à ce que les hôtes partagent une version de base d’EVC couvrant les instructions processeur utilisées par les machines virtuelles. Si vous devez ultérieurement augmenter le niveau d’EVC, désactivez d’abord FT sur les machines virtuelles concernées. Utilisez des processeurs prenant en charge la virtualisation matérielle (Intel EPT ou AMD RVI), tels que les processeurs Intel Sandy Bridge ou versions ultérieures, ainsi que les processeurs AMD Bulldozer ou versions ultérieures.
Configurez le réseau pour une faible latence. Utilisez un réseau dédié pour la journalisation FT, de préférence 10 GbE ou supérieur. VMware recommande un temps de round-trip (RTT) inférieur à 10 ms, idéalement inférieur à 1 ms, afin d’éviter les retards de lecture et les interruptions. Utilisez des cartes réseau physiques distinctes ou des VLAN pour isoler le trafic FT. Activez les trames géantes (MTU 9000) de bout en bout si pris en charge. Réservez une bande passante dédiée afin d’éviter la saturation du canal de journalisation.
Assurez-vous que le stockage partagé répond aux exigences de latence. La latence continue des E/S de stockage doit rester inférieure à environ 15 ms pour que la synchronisation FT puisse suivre le rythme. Utilisez Fibre Channel, iSCSI ou vSAN avec des performances stables. Évitez les pics pouvant retarder l’acquittement des E/S sur le serveur principal. Une faible latence de stockage réduit le risque de divergence. Surveillez les métriques de latence des banques de données afin de détecter les problèmes.
Configurez séparément le réseau vMotion. Ce réseau gère le placement initial de la machine virtuelle secondaire ainsi que les migrations effectuées pendant les opérations de maintenance. Assurez-vous que les chemins vMotion disposent d’une bande passante suffisante et d’une faible latence. La journalisation FT ne remplace pas le trafic vMotion ; les deux types de trafic nécessitent des réseaux fiables. Utilisez DRS pour placer la machine virtuelle secondaire sur un hôte adapté. Les pools de ressources ne doivent pas priver les machines virtuelles FT de ressources. Évitez les limites ou les réservations concurrentes susceptibles de restreindre la lecture différée ou la journalisation. Réservez des ressources processeur et mémoire sur les hôtes destinées aux charges de travail FT.
Configurez les adaptateurs VMkernel : un pour la gestion, un pour vMotion et un dédié à la journalisation FT. Affectez l’adaptateur VMkernel de journalisation FT à une carte réseau physique présentant une contention minimale. Vérifiez que les chemins réseau entre les hôtes comportent un nombre minimal de sauts. Configurez les paramètres de haute disponibilité (HA) afin de gérer avec précaution les partitions réseau ; évitez d’isoler les hôtes exécutant des machines virtuelles FT.
1. Activation de la tolérance aux pannes sur une machine virtuelle
Avant d’activer la tolérance aux pannes (FT), vérifiez que les ressources sont suffisantes à la fois sur l’hôte principal et sur l’hôte secondaire potentiel. Vérifiez le processeur, la mémoire vive (RAM) et la bande passante réseau. Dans le client vSphere, cliquez avec le bouton droit sur la machine virtuelle, puis sélectionnez Turn On Fault Tolerance. Le système crée un modèle de machine virtuelle secondaire correspondant aux paramètres du processeur, de la mémoire et du disque. La journalisation FT débute entre les deux machines virtuelles. Surveillez l’indicateur d’état : celui-ci doit afficher Protected. Si ce n’est pas le cas, vérifiez la connectivité réseau, le mode EVC ou les contraintes de ressources. La FT peut désactiver DRS pour cette machine virtuelle ; prévoyez-en les conséquences.
Assurez-vous que le système d’exploitation invité et les versions du matériel virtuel sont pris en charge. Supprimez les périphériques non pris en charge : évitez les instantanés, n’utilisez pas de SCSI/Net paravirtuel, pas de NPIV, ni de passage direct RDMA. Consultez le Guide de compatibilité VMware. Vérifiez que votre licence prend bien en charge la fonctionnalité FT (Fault Tolerance) pour le nombre souhaité de vCPU. Limites courantes : vSphere 8 Enterprise Plus peut autoriser jusqu’à 2 vCPU ; consultez la documentation actuelle pour connaître les valeurs exactes.
2. Test de la tolérance aux pannes
Effectuez des tests de tolérance aux pannes afin de renforcer votre confiance dans le système. Utilisez des méthodes sûres allant au-delà d’une simple mise hors tension de l’hôte. Par exemple : arrêtez le processus vmx sur l’hôte principal à l’aide de la commande esxcli system process kill -t force -p <vmx-pid> ; simulez une partition réseau pour isoler l’hôte ; ou interrompez un processus critique à l’intérieur de la machine virtuelle afin de tester la continuité de l’application. Vérifiez que l’hôte secondaire poursuit son fonctionnement sans interruption de service.
Vérifiez le basculement via PowerCLI : exécutez la commande Get-VM | Select Name, FaultToleranceState. Recherchez les changements d’état indiquant la reprise de contrôle. Examinez les événements vCenter pour identifier les entrées relatives au basculement de la tolérance aux pannes (FT). Utilisez la journalisation des applications afin de confirmer la persistance des sessions et la continuité du service. Une fois le basculement effectué, vérifiez que vSphere crée une nouvelle machine virtuelle secondaire : assurez-vous que l’état Protected est bien affiché. Le test ne peut être considéré comme terminé que lorsque la nouvelle machine virtuelle secondaire a achevé sa synchronisation.
Vérifiez les connexions réseau : veillez à ce que les sessions TCP restent intactes, si possible. Certaines applications peuvent nécessiter un basculement prenant en compte les sessions. Examinez les contrôles d’intégrité propres à chaque application. Documentez les résultats des tests. Utilisez des plages de maintenance planifiées si les tests sont effectués en production.
3. Surveillance et maintenance
Surveillez en continu l’état de santé du basculement par redondance (FT). Vérifiez le volume de trafic des journaux FT (en Mo/s), la latence et les pertes de paquets sur les ports VMkernel FT. Utilisez les graphiques de performances vSphere ou PowerCLI (Get-VM | Get-FaultToleranceVM) pour afficher les états de signal de vie (heartbeat) et de rattrapage (catchup). Prêtez attention aux blocages répétés (stuns) ou aux débordements de mémoire tampon, qui indiquent des problèmes réseau.
Définissez des alarmes pour les événements liés à la fonctionnalité FT. Recevez une alerte en cas de désactivation de FT ou de déclenchements répétés du basculement. Examinez les modifications de compatibilité des hôtes : lors de l’ajout d’hôtes ou de la mise à jour de leur micrologiciel, assurez-vous qu’ils répondent aux exigences relatives au mode EVC et au matériel pour FT.
Lors de la mise à jour des hôtes, suivez cette procédure : placez l’hôte protégé par FT en mode maintenance. DRS déplace les autres machines virtuelles. La machine virtuelle secondaire FT est migrée via vMotion vers un autre hôte compatible avant l’entrée en mode maintenance. Mettez à jour et redémarrez l’hôte. Quittez le mode maintenance. vSphere peut automatiquement ramener la machine virtuelle secondaire ou en créer une nouvelle. Cette procédure suppose que DRS et HA sont activés. Vérifiez que la synchronisation reprend.
Conservez des niveaux de micrologiciel et de pilotes cohérents sur tous les hôtes. Alignez les versions du microcode processeur afin d’éviter les dérives EVC. Gardez uniformes la multipath stockage et les chemins réseau. Testez les modifications dans un environnement de laboratoire, si possible. Documentez toutes les configurations FT.
VMware Tolérance aux pannes par rapport à la haute disponibilité
La tolérance aux pannes (FT) et la haute disponibilité (HA) visent toutes deux à réduire les temps d’indisponibilité, mais diffèrent quant au temps de reprise (RTO), à la surcharge système et à la complexité. Les deux garantissent un objectif de point de récupération (RPO) égal à zéro pour l’état des machines virtuelles au moment de la panne : la FT réplique continuellement l’état, tandis que la HA permet de redémarrer rapidement les machines virtuelles, bien qu’un certain état présent dans la mémoire vive puisse être perdu — toutefois, une perte de données peut survenir si les données n’ont pas été écrites sur le disque avant le plantage. La différence fondamentale réside dans le RTO : la FT offre un RTO quasi nul (quelques millisecondes), car la machine virtuelle secondaire prend immédiatement le relais ; en revanche, la HA nécessite un redémarrage complet de la machine virtuelle, entraînant plusieurs minutes d’indisponibilité.
La technologie FT entraîne une surcharge plus importante : elle exécute une machine virtuelle secondaire en mode relecture, consommant autant de cycles processeur que la machine virtuelle principale. Elle double ainsi effectivement les réservations de ressources processeur. Le trafic de journalisation FT peut atteindre plusieurs centaines de mégabits par seconde pour les machines virtuelles gourmandes en CPU et en mémoire. La latence réseau doit rester faible. Les entrées/sorties de stockage ne s’exécutent que sur la machine virtuelle principale, mais la journalisation ajoute une surcharge. FT convient donc mieux aux petites machines virtuelles (1 à 2 vCPUs) ou aux charges de travail extrêmement critiques. HA utilise moins de ressources : elle redémarre les machines virtuelles sur un autre hôte, ce qui provoque un court redémarrage. Utilisez HA pour les machines virtuelles plus volumineuses ou moins critiques, lorsque des temps d’indisponibilité de quelques minutes sont acceptables.
Prenez en compte la complexité : la fonctionnalité FT impose des exigences strictes et une surveillance attentive. La haute disponibilité (HA) nécessite un stockage partagé et la configuration d’un cluster HA, mais est plus simple à mettre en œuvre. Planifiez le recours à FT uniquement lorsque l’absence totale d’interruption de service est obligatoire et que le coût en ressources est justifié. Posez-vous la question suivante : votre application peut-elle supporter un redémarrage bref ? Si oui, la haute disponibilité (HA) peut suffire. Si non, FT pourrait justifier son surcoût.
Sauvegarde des machines virtuelles VMware avec Vinchin
La tolérance aux pannes protège contre les défaillances des hôtes. Toutefois, les sauvegardes préservent les données contre la corruption, les erreurs humaines ou les catastrophes sur site. Vinchin propose une solution de sauvegarde de machines virtuelles de niveau entreprise, spécifiquement conçue pour les environnements VMware. Elle s’intègre parfaitement à vSphere et garantit que vos machines virtuelles restent restaurables au-delà de la protection offerte par la tolérance aux pannes.
Vinchin Backup & Recovery est une solution professionnelle de sauvegarde de machines virtuelles, conçue pour les entreprises, prenant en charge VMware ainsi que plus de 15 autres plates-formes, telles que Hyper-V, Proxmox, oVirt, OLVM, RHV, XCP-ng, XenServer et OpenStack, ZStack, entre autres. Elle propose un ensemble complet de fonctionnalités.
Vinchin propose une sauvegarde incrémentale permanente pour gagner du temps et économiser de l’espace de stockage. Il utilise la dé-duplication des données et la compression afin de réduire la taille des sauvegardes. La migration V2V permet de déplacer des machines virtuelles entre hôtes ou plates-formes. Il prend en charge la technologie CBT (Changed Block Tracking) afin de ne capturer que les blocs modifiés. Il offre une restauration instantanée pour une récupération rapide des machines virtuelles. En outre, il intègre le chiffrement des données, la transmission multithread, la vérification des sauvegardes, la restauration fine, l’archivage dans le cloud ou sur bande, des politiques de limitation de bande passante ainsi que la stratégie de rétention GFS (Grandfather-Father-Son). Ce ne sont là que quelques-unes des nombreuses fonctionnalités offertes par Vinchin.
La console web est intuitive. Pour sauvegarder une machine virtuelle, suivez ces quatre étapes :
1. Sélectionnez la machine virtuelle VMware à sauvegarder.
2. Choisissez le stockage de sauvegarde.
3. Configurez les stratégies de sauvegarde.
4. Envoyer la tâche.
Ce flux simple permet aux administrateurs de protéger efficacement leurs charges de travail VMware. La clientèle mondiale de Vinchin et ses excellentes évaluations témoignent de la confiance accordée à ses performances. Profitez d’un essai gratuit complet de 60 jours pour tester toutes les fonctionnalités dans votre environnement. Téléchargez l’installateur et déployez-le facilement afin de sécuriser vos machines virtuelles dès aujourd’hui.
Foire aux questions sur la tolérance aux pannes VMware
Q1 : Quelles sont les limites de la tolérance aux pannes VMware ?
A1 : Le nombre de vCPU par machine virtuelle FT dépend de la version et de la licence de vSphere ; par exemple, vSphere 7 autorise jusqu’à 8 vCPU, tandis que vSphere 8 limite souvent à 2 vCPU sur la licence Enterprise Plus. La fonctionnalité FT interdit les instantanés (snapshots), le Storage vMotion, les périphériques paravirtualisés, le NPIV et le passage direct du RDMA.
Q2 : Comment ajouter le réseau de journalisation FT ?
A2 : Dans le client vSphere, sélectionnez l’hôte > Configurer > Réseau > VMkernel adapters, cliquez sur Add Networking, choisissez Fault Tolerance Logging, attribuez un port, liez-le à une carte réseau physique dédiée (10 GbE ou supérieure) et activez les trames géantes si le chemin prend en charge une MTU de 9 000.
Q3 : Comment assurer la maintenance sans perturber le FT ?
A3 : Utilisez DRS : migrez les machines virtuelles non protégées par FT vers un autre hôte, autorisez la machine virtuelle secondaire FT à effectuer une migration vMotion vers un autre hôte, appliquez le correctif à l’hôte, quittez le mode Maintenance, vérifiez la synchronisation de la nouvelle machine virtuelle secondaire ; assurez-vous que DRS et HA sont activés pour l’automatisation.
Q4 : Comment FT affecte-t-il les performances des machines virtuelles ?
A4 : FT ajoute une surcharge due à la journalisation du trafic et à la lecture secondaire ; attendez-vous à une pénalité de 5 à 20 % sur le système principal, selon la charge de travail et la latence ; effectuez des tests sous charge pour vérifier l’impact avant le déploiement en production.
Conclusion
La fonctionnalité VMware Fault Tolerance assure une protection sans interruption de service en exécutant une machine virtuelle secondaire passive synchronisée exactement avec la machine virtuelle principale. Elle exige une configuration rigoureuse : compatibilité des processeurs via EVC, réseaux dédiés à faible latence et faible latence de stockage. Des tests et une surveillance régulière garantissent sa fiabilité, tandis que le choix entre Fault Tolerance et High Availability dépend des exigences en matière de temps de reprise (RTO) et du coût des ressources.
L’association de la fonctionnalité FT (Fault Tolerance) avec les sauvegardes Vinchin couvre à la fois les pannes d’hôte et les risques au niveau des données. Les fonctionnalités avancées de Vinchin, telles que la sauvegarde incrémentale permanente et la déduplication, renforcent la résilience du système. Testez régulièrement la fonctionnalité FT, planifiez vos sauvegardes et analysez les indicateurs de performance afin de maintenir un environnement VMware robuste. Faites confiance à Vinchin pour une protection complète de vos machines virtuelles.
