Les clusters étendus vSAN étendent le cluster vSAN d'un site de données unique à deux sites pour améliorer le niveau de disponibilité et l'équilibrage de charge entre sites. Les clusters étendus vSAN sont généralement déployés dans des environnements dans lesquels la distance entre les centres de données est limitée, par exemple les environnements métropolitains ou campus.

Vous pouvez utiliser les clusters étendus vSAN pour gérer la maintenance planifiée et éviter les scénarios catastrophes, car la maintenance ou la perte d'un site n'affecte pas le fonctionnement global du cluster. Dans une configuration de cluster étendu vSAN, les deux sites de données sont des sites actifs. Si l'un ou l'autre tombe en panne, vSAN utilise le stockage sur l'autre site. vSphere HA redémarre toute machine virtuelle devant être redémarrée sur le site actif restant.

Vous devez désigner un site comme site préféré. L'autre site devient un site secondaire ou non préféré. En cas de perte de la connexion réseau entre les deux sites actifs, vSAN continue l'opération avec le site préféré. Le site désigné comme préféré est généralement celui qui reste opérationnel, sauf s'il est en cours de resynchronisation ou présente un autre problème. Le site qui donne lieu à une disponibilité maximale des données est celui qui reste en opération.

Un cluster étendu vSAN peut tolérer une panne de liaison sans perte de disponibilité de données. Une panne de liaison est une perte de connexion réseau entre les deux sites ou entre un site et l'hôte témoin. Pendant la panne d'un site ou une perte de connexion réseau, vSAN passe automatiquement aux sites entièrement fonctionnels.

Les clusters étendus vSAN vSAN 7.0 Update 3 et versions ultérieures peuvent tolérer une panne d'hôte témoin lorsqu'un site n'est pas disponible. Configurez la règle de stratégie de stockage Tolérance aux pannes du site sur Mise en miroir du site - Cluster étendu. Si un site est inactif en raison d'une maintenance ou d'une panne et qu'un échec de l'hôte témoin se produit, les objets deviennent non conformes, mais restent accessibles.

Pour plus d'informations sur l'utilisation de clusters étendus vSAN, reportez-vous au Guide de clusters étendus vSAN.

Hôte témoin

Chaque cluster étendu vSAN se compose de deux sites de données et d'un hôte témoin. L'hôte témoin réside sur un troisième site et contient les composants témoins d'objets de machine virtuelle. L'hôte témoin ne stocke pas les données client, uniquement les métadonnées, telles que la taille et l'UUID de l'objet et des composants vSAN.

L'hôte témoin sert d'arbitre lorsqu'une décision doit être prise concernant la disponibilité de composants de banque de données lorsque la connexion réseau entre les deux sites est perdue. Dans ce cas, le témoin forme généralement un cluster vSAN avec le site préféré. Mais si le site préféré devient isolé du site secondaire, l'hôte témoin forme un cluster en utilisant le site secondaire. Lorsque le site préféré est de nouveau en ligne, les données sont resynchronisées pour garantir que les deux sites disposent des dernières copies de toutes les données.

Si l'hôte témoin tombe en panne, tous les objets correspondants deviennent non conformes mais sont entièrement accessibles.

L'hôte témoin a les caractéristiques suivantes :

  • L'hôte témoin peut utiliser des liaisons à faible bande passante/latence élevée.
  • L'hôte témoin ne peut pas exécuter de machines virtuelles.
  • Un seul hôte témoin ne peut prendre en charge qu'un seul cluster étendu vSAN. Les clusters vSAN à deux nœuds peuvent partager un seul hôte témoin.
  • L'hôte témoin doit disposer d'un adaptateur VMkernel sur lequel le trafic vSAN est activé, avec des connexions à tous les hôtes du cluster. L'hôte témoin utilise un adaptateur VMkernel pour la gestion et un adaptateur VMkernel pour le trafic de données vSAN. L'hôte témoin ne peut avoir qu'un seul adaptateur VMkernel dédié à vSAN.
  • L'hôte témoin doit être un hôte autonome dédié au cluster étendu vSAN. Il ne peut pas être ajouté à un cluster ou déplacé en inventaire par le biais de vCenter Server.

L'hôte témoin peut être un hôte physique ou un hôte ESXi exécuté à l'intérieur d'une machine virtuelle. L'hôte témoin de machine virtuelle ne fournit pas d'autres types de fonctionnalités, telles que le stockage ou l'exécution de machines virtuelles. Plusieurs hôtes témoins peuvent s'exécuter sous forme de machines virtuelles sur un serveur physique unique. Pour la correction et la configuration de base de mise en réseau et de surveillance, l'hôte témoin de machine virtuelle fonctionne de la même manière qu'un hôte ESXi type. Vous pouvez le gérer avec vCenter Server, le corriger et le mettre à jour à l'aide de esxcli ou vSphere Lifecycle Manager, et le surveiller avec des outils standard en interaction avec les hôtes ESXi.

Vous pouvez utiliser un dispositif virtuel témoin comme hôte témoin dans un cluster étendu vSAN. Le dispositif virtuel témoin est un hôte ESXi dans une machine virtuelle, conditionné comme un OVF ou un OVA. Le dispositif est disponible dans différentes options, en fonction de la taille du déploiement. Vous pouvez utiliser un dispositif virtuel témoin comme hôte témoin dans un cluster étendu vSAN. Le dispositif virtuel témoin est un hôte ESXi dans une machine virtuelle, conditionné comme un OVF ou un OVA. Différents dispositifs et différentes options sont disponibles en fonction de l'architecture vSAN et de la taille du déploiement.

Clusters étendus vSAN et domaines de pannes

Les clusters étendus vSAN utilisent des domaines de pannes pour permettre la redondance et la protection contre les pannes entre les sites. Chaque site dans un cluster étendu vSAN réside dans un domaine de pannes distinct.

Un cluster étendu vSAN nécessite trois domaines de pannes : le site préféré, le site secondaire et un hôte témoin. Chaque domaine de pannes représente un site distinct. Lorsque l'hôte témoin échoue ou passe en mode de maintenance, vSAN considère cela comme une panne du site.

Dans vSAN 6.6 et versions ultérieures, vous pouvez fournir un niveau supplémentaire de protection locale contre les pannes pour les objets de machine virtuelle dans des clusters étendus vSAN. Lorsque vous configurez un cluster étendu vSAN, les règles de stratégie suivantes sont disponibles pour les objets du cluster :
  • Tolérance aux pannes du site. Pour les clusters étendus vSAN, cette règle définit la méthode de tolérance aux pannes. Sélectionnez Mise en miroir de site - cluster étendu.
  • Pannes tolérées (FTT). Pour les clusters étendus vSAN, FTT définit le nombre de pannes de l'hôte supplémentaire qu'un objet de machine virtuelle peut tolérer.
  • Aucun. Vous pouvez définir cette règle de localité des données sur Aucun, Préféré ou Secondaire. Cette règle vous permet de limiter les objets de machine virtuelle à un site sélectionné dans le cluster étendu vSAN.

Dans un cluster étendu vSAN disposant d'une protection locale contre les pannes, même lorsqu'un site n'est pas disponible, le cluster peut effectuer des réparations sur des composants manquants ou endommagés dans le site disponible.

vSAN 7.0 et versions ultérieures continuent à envoyer les E/S si un ou plusieurs disques sur un site atteignent 96 % de capacité ou 5 Go de capacité libre (selon la valeur la plus faible), tandis que les disques de l'autre site disposent d'un espace libre. Les composants sur le site concerné sont marqués comme absents et vSAN continuent d'envoyer des E/S vers les copies d'objets sains sur l'autre site. Lorsque les disques sur le site concerné atteignent 94 % de capacité ou 10 Go (selon la valeur la plus faible), les composants absents deviennent disponibles. vSAN resynchronise les composants disponibles et tous les objets deviennent conformes à la stratégie.

Considérations relatives à la conception de clusters étendus vSAN

Tenez compte de ces directives lors de l'utilisation d'un cluster étendu vSAN.

  • Configurez les paramètres DRS pour le cluster étendu vSAN.
    • DRS doit être activé sur le cluster. Si vous placez DRS dans un mode partiellement automatisé, vous pouvez contrôler quelles machines virtuelles migrer vers chaque site. vSAN 7.0 Update 2 permet d'utiliser DRS en mode automatique, et de récupérer normalement suite à des partitions réseau.
    • Créez deux groupes d'hôtes, un premier pour le site préféré, un autre pour le site secondaire.
    • Créez deux groupes de machines virtuelles, un premier pour contenir les machines virtuelles du site préféré, un autre pour contenir les machines virtuelles du site secondaire.
    • Créez deux règles d'affinité VM-hôte qui mappent des groupes VM vers hôtes, et spécifie quelles machines virtuelles et quels hôtes résident dans le site préféré et dans le site secondaire.
    • Configurez les règles d'affinité VM-hôte pour effectuer le placement initial des machines virtuelles dans le cluster.
  • Configurez les paramètres HA pour le cluster étendu vSAN.
    • Les paramètres des règles HA doivent respecter les règles d'affinité VM-hôte pendant le basculement.
    • Désactivez les signaux de pulsation de banque de données HA.
    • Utilisez HA avec la surveillance des pannes d'hôte, le contrôle d'admission et définissez FTT sur le nombre d'hôtes de chaque site.
  • Les clusters étendus vSAN nécessitent un format sur disque 2.0 ou version ultérieure. Si nécessaire, mettez à niveau le format sur disque avant de configurer un cluster étendu vSAN. Reportez-vous à la section « Mettre à niveau le format de disque vSAN » dans Administration de VMware vSAN.
  • Configurez l'option FTT sur 1 pour les clusters étendus vSAN.
  • Les clusters étendus vSAN prennent en charge l'activation des VM SMP-FT (Symmetric Multiprocessing Fault Tolerance) lorsque l'option Tolérance aux sinistres de sites est définie sur Aucune avec Préféré ou Secondaire. vSAN ne prend pas en charge les VM SMP-FT sur un cluster étendu vSAN avec l'option Tolérance aux sinistres de sites définie sur au moins 1. Les clusters à deux hôtes vSAN prennent en charge l'activation de SMP-FT avec FTT défini sur 1 uniquement lorsque les deux nœuds de données se trouvent sur le même site.
  • Lorsqu'un hôte est déconnecté ou ne répond pas, vous ne pouvez pas ajouter ou supprimer l'hôte témoin. Cette limitation garantit que vSAN collecte suffisamment d'informations de tous les hôtes avant de lancer des opérations de reconfiguration.
  • L'utilisation d'esxcli pour ajouter ou supprimer des hôtes n'est pas prise en charge pour les clusters étendus vSAN.
  • Ne créez pas de snapshots de l'hôte témoin ou de sauvegardes de l'hôte témoin. Si l'hôte témoin échoue, changez l'hôte témoin.

Recommandations pour l'utilisation de clusters étendus vSAN

Lors de l'utilisation de clusters étendus vSAN, suivez ces recommandations pour obtenir de bonnes performances.

  • Si l'un des sites (domaines de pannes) dans le cluster étendu vSAN est inaccessible, de nouvelles VM peuvent toujours être provisionnées dans le sous-cluster contenant le site opérationnel. Ces nouvelles machines virtuelles sont implicitement provisionnées de force et ne sont pas conformes tant que le site partitionné n'a pas rejoint le cluster. Ce provisionnement implicite de force est effectué uniquement lorsque deux des trois sites sont disponibles. Un site ici se réfère à un site de données ou à l'hôte témoin.
  • Si l'intégralité d'un site devient hors ligne en raison d'une panne de courant ou d'une perte de connexion réseau, redémarrez le site immédiatement sans trop tarder. Plutôt que de redémarrer les hôtes vSAN un par un, remettez tous les hôtes en ligne environ en même temps, idéalement dans une période de 10 minutes. En suivant ce processus, vous évitez de resynchroniser une grande quantité de données entre les sites.
  • Si un hôte est non disponible de façon permanente, retirez l'hôte du cluster avant d'effectuer toute tâche de reconfiguration.
  • Si vous souhaitez cloner un hôte témoin de VM pour prendre en charge plusieurs clusters étendus vSAN, ne configurez pas la VM comme un hôte témoin avant de la cloner. Déployez d'abord la machine virtuelle à partir d'OVF, puis clonez la machine virtuelle et configurez chaque clone comme un hôte témoin pour un cluster différent. Vous pouvez également déployer autant de machines virtuelles que nécessaire à partir de l'OVF, et configurer chacune comme un hôte témoin pour un cluster différent.

Conception du réseau des clusters étendus vSAN

Tous les trois sites dans un cluster étendu vSAN communiquent sur le réseau de gestion et sur le réseau vSAN. Les VM des deux sites de données communiquent sur un réseau de machine virtuelle commun.

Un cluster étendu vSAN doit respecter certaines exigences basiques de mise en réseau.
  • Le réseau de gestion exige la connectivité entre les trois sites, via un réseau étendu de couche 2 ou un réseau de couche 3.
  • Le réseau vSAN exige la connectivité entre les trois sites. Il doit disposer d'une connectivité et d'un routage indépendants entre les sites de données et l'hôte témoin. vSAN prend en charge les couches 2 et 3 entre les deux sites de données et la couche 3 entre les sites de données et l'hôte témoin.
  • Le réseau de machine virtuelle exige la connectivité entre les sites de données, mais pas l'hôte témoin. Utilisez un réseau étendu de couche 2 ou un réseau de couche 3 entre les sites de données. En cas de défaillance, les VM n'ont pas besoin d'une nouvelle adresse IP pour fonctionner sur le site distant.
  • Le réseau vMotion exige la connectivité entre les sites de données, mais pas l'hôte témoin. Utilisez un réseau étendu de couche 2 ou un réseau de couche 3 entre les sites de données.
Note : vSAN sur RDMA n'est pas pris en charge sur les clusters étendus vSAN ou les clusters vSAN à deux nœuds.

Utilisation d'itinéraires statiques sur des hôtes ESXi

Si vous utilisez une passerelle par défaut unique sur les hôtes ESXi, chaque hôte ESXi contient une pile TCP/IP par défaut qui comprend une passerelle par défaut unique. L'itinéraire par défaut est généralement associé à la pile TCP/IP du réseau de gestion.

Le réseau de gestion et le réseau vSAN peuvent être isolés l'un de l'autre. Par exemple, le réseau de gestion peut utiliser vmk0 sur la carte NIC physique 0, pendant que le réseau vSAN utilise vmk2 sur la carte NIC physique 1 (adaptateurs réseau séparés pour deux piles TCP/IP distinctes). Cette configuration suppose que le réseau vSAN ne possède pas de passerelle par défaut.

Dans vSAN 7.0 et les versions ultérieures, vous pouvez remplacer la passerelle par défaut pour l'adaptateur VMkernel vSAN sur chaque hôte et configurer une adresse de passerelle pour le réseau vSAN.

Vous pouvez également utiliser des routes statiques pour communiquer entre les réseaux. Considérons un réseau vSAN étendu entre deux site de données sur un domaine de diffusion de couche 2 (par exemple, 172.10.0.0) et l'hôte témoin sur un autre domaine de diffusion (par exemple, 172.30.0.0). Si les adaptateurs VMkernel sur un site de données tentent de se connecter au réseau vSAN sur l'hôte témoin, la connexion échoue, car la passerelle par défaut sur l'hôte ESXi est associée au réseau de gestion. Il n'existe aucune route du réseau de gestion vers le réseau vSAN.

Définissez une nouvelle entrée de routage pour indiquer le chemin d'accès à suivre afin d'atteindre un réseau donné. Pour un réseau vSAN sur un cluster étendu vSAN, vous pouvez ajouter des routes statiques afin d'assurer une communication appropriée entre tous les hôtes.

Par exemple, vous pouvez ajouter un itinéraire statique aux hôtes de chaque site de données, afin que les requêtes pour atteindre le réseau témoin 172.30.0.0 soient acheminées via l'interface 172.10.0.0. Ajoutez également un itinéraire statique à l'hôte témoin, afin que les requêtes pour atteindre le réseau 172.10.0.0 pour les sites de données soient acheminées via l'interface 172.30.0.0.

Note : Si vous utilisez des itinéraires statiques, vous devez ajouter manuellement les itinéraires statiques pour tout nouvel hôte ESXi ajouté à chaque site avant que ces hôtes puissent communiquer dans le cluster. Si vous remplacez l'hôte témoin, vous devez mettre à jour la configuration des itinéraires statiques.

Utilisez la commande esxcli network ip route pour ajouter des itinéraires statiques.