vSAN prend en charge les déploiements de cluster étendus qui couvrent deux emplacements.
Dans vSAN 6.5 et version antérieure, le trafic vSAN entre les sites de données est multidiffusion pour les métadonnées et monodiffusion pour les E/S.
Dans vSAN 6.6 et version ultérieure, l'intégralité du trafic est en monodiffusion. Dans toutes les versions de vSAN, le trafic témoin entre un site de données et l'hôte témoin est en monodiffusion.
Couche 2 partout
Vous pouvez configurer un cluster étendu vSAN dans un réseau de couche 2, mais cette configuration n'est pas recommandée.
Envisagez une conception dans laquelle le cluster étendu vSAN est configuré dans une conception de couche 2 de grande taille. Les machines virtuelles sont déployées sur le site de données 1 et le site 2. Le site 3 contient l'hôte témoin.
Pour illustrer la couche 2 partout aussi simplement que possible, nous utilisons des commutateurs (et non des routeurs) dans les topologies.
Les réseaux de couche 2 ne peuvent pas avoir de boucles (chemins multiples). Par conséquent, les fonctionnalités telles que le protocole STP (Spanning Tree Protocol) sont nécessaires pour bloquer l'une des connexions entre le site 1 et le site 2. Considérons à présent une situation dans laquelle le lien entre le site 2 et le site 3 est rompu (le lien entre le site 1 et le site 2). Le trafic réseau est désormais basculé du site 1 vers le site 2 via l'hôte témoin sur le site 3. Étant donné que VMware prend en charge une bande passante beaucoup plus faible et une latence plus élevée pour l'hôte témoin, vous observez une diminution importante des performances si le trafic du réseau de données passe par un site témoin doté de spécifications inférieures.
Dans les cas où le basculement du trafic entre des sites de données via le site témoin n'a pas d'incidence sur la latence des applications et que la bande passante est acceptable, une configuration L2 étendue entre les sites est possible. Dans la plupart des cas, une telle configuration n'est pas faisable et accroît la complexité des exigences de mise en réseau.
Avec vSAN 6.5 ou version antérieure, qui utilise le trafic multidiffusion, vous devez configurer l'écoute IGMP sur les commutateurs. Cette opération n'est pas nécessaire dans vSAN 6.6 et version ultérieure. PIM n'est pas nécessaire, car il n'y a aucun routage du trafic multidiffusion.
Configurations de cluster étendu prises en charge
vSAN prend en charge les configurations de cluster étendu.
La configuration suivante empêche l'acheminement du trafic du site 1 vers le site 2 via l'hôte témoin, en cas de défaillance sur l'un des réseaux des sites de données. Cette configuration permet d'éviter une dégradation des performances. Pour vous assurer que le trafic de données n'est pas commuté via l'hôte témoin, utilisez la topologie réseau suivante.
Entre le site 1 et le site 2, implémentez une configuration étendue de couche 2 commutée ou une configuration de couche 3 routée. Les deux configurations sont prises en charge.
Entre le site 1 et l'hôte témoin, implémentez une configuration de couche 3 routée.
Entre le site 2 et l'hôte témoin, implémentez une configuration de couche 3 routée.
Ces configurations (L2+L3 et L3 partout) sont décrites avec une attention portée au trafic multidiffusion dans vSAN 6.5 et version antérieure, et le trafic monodiffusion uniquement, qui est disponible dans vSAN 6.6. Le trafic multidiffusion introduit des étapes de configuration supplémentaires pour l'écoute IGMP, et PIM pour le routage du trafic multidiffusion.
Nous examinerons un réseau étendu de couche 2 entre les sites de données et un réseau routé de couche 3 vers le site témoin. Pour démontrer une combinaison de couche 2 et de couche 3 aussi simplement que possible, utilisez une combinaison de commutateurs et de routeurs dans les topologies.
Couche 2 étendue entre les sites de données, couche 3 vers l'hôte témoin
vSAN prend en charge les configurations étendues de couche 2 entre les sites de données.
Dans ce cas, le seul trafic acheminé est le trafic témoin. Dans vSAN 6.5 et version antérieure, qui utilise la multidiffusion, utilisez l'écoute IGMP pour le trafic multidiffusion sur le vSAN L2 étendu entre les sites de données. Cependant, dans la mesure où le trafic témoin est en monodiffusion, il n'est pas nécessaire d'implémenter PIM sur les segments de couche 3.
Dans vSAN 6.6, qui utilise la monodiffusion, il n'est pas nécessaire d'envisager l'écoute IGMP ou PIM.
Couche 3 partout
Dans cette configuration de cluster étendu vSAN, le trafic de données est acheminé entre les sites de données et l'hôte témoin.
Pour implémenter la couche 3 partout aussi simplement que possible, utilisez des routeurs ou des commutateurs de routage dans les topologies.
Par exemple, envisagez un environnement avec vSAN 6.5 ou version antérieure, qui utilise le trafic multidiffusion. Dans ce cas, configurez l'écoute IGMP sur les commutateurs du site de données pour gérer le volume de trafic multidiffusion sur le réseau. Cela n'est pas nécessaire sur l'hôte témoin, car le trafic témoin est en monodiffusion. Le trafic multidiffusion est acheminé entre les sites de données, c'est pourquoi vous devez configurez PIM pour autoriser le routage du trafic multidiffusion.
Dans vSAN 6.6 et versions ultérieures, ni l'écoute IGMP ni PIM ne sont nécessaires, car la totalité du trafic acheminé est monodiffusion.
Séparation du trafic témoin sur les clusters étendus vSAN
vSAN prend en charge la séparation du trafic témoin sur les clusters étendus.
Dans vSAN 6.5 et versions ultérieures, vous pouvez séparer le trafic témoin du trafic vSAN dans les configurations à deux nœuds. Cela signifie que les deux hôtes vSAN peuvent être connectés directement sans commutateur 10 Go.
Cette séparation du trafic témoin est uniquement prise en charge sur les déploiements à deux nœuds dans vSAN 6.6. La séparation du trafic témoin sur des clusters étendus vSAN est prise en charge dans vSAN 6.7 et versions ultérieures.
Utilisation d'un cluster étendu pour permettre la détection des racks
Avec les clusters étendus, vSAN garantit la détection des racks sur un site unique.
Si vous disposez de deux racks d'hôtes vSAN, vous pouvez continuer à exécuter votre cluster vSAN après une défaillance de rack complète. Dans ce cas, la disponibilité des charges de travail de la VM est fournie par le rack restant et un hôte témoin distant.
Dans cet exemple, si le rack 1 fait défaut, le rack 2 et l'hôte témoin garantissent la disponibilité de la VM. Cette configuration est un environnement antérieur àvSAN 6.6 et requiert que la multidiffusion soit configurée sur le réseau. L'hôte témoin doit se trouver sur le réseau vSAN. Le trafic témoin est monodiffusion. Dans vSAN 6.6 et version ultérieure, l'intégralité du trafic est en monodiffusion.
Cette topologie est également prise en charge sur L3. Placez les ports VMkernel pour vSAN sur différents sous-réseaux ou VLAN, et utilisez un sous-réseau ou un VLAN distinct pour chaque rack.
Cette topologie prend en charge les déploiements avec deux racks pour assurer la détection des racks (domaines de pannes) avec un cluster étendu vSAN. Cette solution utilise un hôte témoin externe au cluster.
