Pour garantir des résultats Fault Tolerance optimaux, vous devez respectez certaines meilleures pratiques.

Les recommandations suivantes concernant la configuration de l'hôte et de la mise en réseau peut améliorer la stabilité et les performances de votre cluster.

Configuration d'hôte

Les hôtes exécutant les machines virtuelles principales et secondaires doivent fonctionner à des fréquences de processeur assez proches sinon la machine virtuelle secondaire risque de redémarrer plus souvent. Les fonctions de gestion de l'alimentation de la plate-forme qui ne sont pas réglées selon la charge de travail (modes de limitation de puissance et de basse fréquence pour économiser de l'énergie, par exemple) peuvent entraîner de fortes variations des fréquences du processeur. Si des machines virtuelles secondaires sont redémarrées régulièrement, désactivez tous les modes de gestion de l'alimentation sur les hôtes exécutant des machines virtuelles tolérantes aux pannes ou veillez à ce que tous les hôtes soient exécutés avec les mêmes modes de gestion de l'alimentation.

Configuration de la mise en réseau des hôtes

Les directives suivantes vous permettent de configurer la mise en réseau des hôtes pour la prise en charge de Fault Tolerance avec différentes combinaisons de types de trafic (par exemple, NFS) et plusieurs adaptateurs réseau physiques.

  • Répartissez chaque association d'adaptateurs réseau sur deux commutateurs physiques assurant la continuité des domaines L2 pour chaque VLAN entre les deux commutateurs physiques.
  • Utilisez des règles d'association déterministe pour vous assurer que des types de trafic particuliers présentent une affinité avec une carte réseau particulière (active/veille) ou un ensemble d'adaptateurs réseau (par exemple, ID port virtuel d'origine).
  • Quand des règles active/veille sont utilisées, associez les types de trafic pour réduire les répercussions dans le cas de basculement où les deux types de trafic partagent un vmnic.
  • Quand des règles active/veille sont utilisées, configurez tous les adaptateurs actifs pour un type de trafic particulier (par exemple, journalisation de la tolérance aux pannes) sur le même commutateur physique. Cela réduit le nombre de bonds réseau et diminue les possibilités de surabonner le commutateur à des liaisons de commutateurs.
Note : Le trafic de la journalisation de la tolérance aux pannes entre les machines virtuelles primaires et secondaires est chiffré et contient un réseau client et des données E/S de stockage, ainsi que le contenu de la mémoire du système d'exploitation client. Ce trafic peut inclure des données sensibles telles que des mots de passe en texte brut. Pour éviter que ces données ne soient divulguées, assurez-vous que ce réseau est sécurisé, notamment pour éviter les « attaques de l'intercepteur ». Par exemple, vous pourriez utiliser un réseau privé pour le trafic de la journalisation de la tolérance aux pannes.

Clusters homogènes

vSphere Fault Tolerance peut fonctionner dans des clusters contenant des hôtes non uniformes, mais il est préférable que les clusters aient des nœuds compatibles. Au moment de la construction du cluster, tous les hôtes doivent être configurés comme suit :

  • Accès commun aux banques de données utilisées par les machines virtuelles.
  • La même configuration réseau de machines virtuelles.
  • Les mêmes paramètres de BIOS (gestion de l'alimentation et hyperthreading) pour tous les hôtes.

Exécutez Vérifier la conformité pour identifier les incompatibilités et les corriger.

Performances

Pour accroître la bande passante disponible pour le trafic de journalisation entre les machines virtuelles principales et secondaires, utilisez une carte réseau de 10 Gbit et activez l'utilisation des Trames jumbo.

Vous pouvez sélectionner plusieurs cartes réseau pour le réseau de journalisation FT. En sélectionnant plusieurs cartes réseau, vous pouvez tirer parti de la bande passante de plusieurs cartes réseau, même si toutes les cartes réseau ne sont pas dédiées à l'exécution de FT.

Stocker les images ISO sur des stockages partagés pour un accès permanent

Les images ISO auxquelles accèdent les machines virtuelles dont Fault Tolerance est activée doivent être conservées sur des stockages partagés accessibles aux deux instances de la machine virtuelle tolérante aux pannes. Si vous utilisez cette configuration, le CD-ROM présent dans la machine virtuelle continue de fonctionner correctement, même en cas de basculement.

Éviter les partitions de réseau

Une partition de réseau survient quand un cluster vSphere HA connaît une défaillance du réseau de gestion qui isole certains hôtes de vCenter Server et les isole les uns des autres. Reportez-vous à la section Partitions de réseau. En cas de partition, la protection de Fault Tolerance peut être réduite.

Dans un cluster vSphere HA partitionné utilisant Fault Tolerance, la machine virtuelle principale (ou sa machine virtuelle secondaire) peut se retrouver dans une partition gérée par un hôte principal qui n'est pas responsable de cette machine virtuelle. Si un basculement est nécessaire, une machine virtuelle secondaire est redémarrée uniquement si la machine virtuelle principale se trouve dans une partition gérée par un hôte principal qui en est responsable.

Pour réduire les risques de panne de votre réseau de gestion entraînant une partition du réseau, suivez les recommandations figurant dans Meilleures pratiques pour la mise en réseau.

Utilisation des banques de données vSAN

vSphere Fault Tolerance peut utiliser des banques de données vSAN, mais vous devez observer les restrictions suivantes :

  • Un mélange de vSAN et d'autres types de banques de données n'est pas pris en charge pour les machines virtuelles principales et les machines virtuelles secondaires.
  • Les metro-clusters vSAN ne sont pas pris en charge avec FT.

Pour augmenter les performances et la fiabilité lors de l'utilisation de FT avec vSAN, les conditions suivantes sont également recommandées.

  • vSAN et FT doivent utiliser des réseaux distincts.
  • Maintenez les machines virtuelles principales et secondaires dans des domaines de pannes vSAN distincts.