Le trafic monodiffusion fait référence à une transmission point à point d'un point du réseau à un autre. vSAN 6.6 et versions ultérieures utilisent la monodiffusion pour simplifier la conception et le déploiement du réseau.
Tous les hôtes ESXi utilisent le trafic monodiffusion et vCenter Server devient la source de l'appartenance au cluster. Les nœuds vSAN sont automatiquement mis à jour avec la dernière liste d'appartenance d'hôte fournie par vCenter. vSAN communique à l'aide de la monodiffusion pour les mises à jour de CMMDS.
Les versions de vSAN antérieures à 6.6 s'appuient sur la monodiffusion pour activer les signaux de pulsation et échanger des métadonnées entre les hôtes au sein du cluster. Si certains hôtes de votre cluster vSAN exécutent des versions antérieures du logiciel, un réseau multidiffusion est toujours nécessaire. Le basculement vers le réseau monodiffusion à partir de la multidiffusion garantit des performances et une prise en charge réseau améliorées. Pour de plus amples informations sur la multidiffusion, reportez-vous à la section Utilisation de la multidiffusion dans un réseau vSAN.
Comportement du groupe de disques antérieur à la version 5
La disponibilité d'un groupe de disques version 5 unique dans un groupe de disques vSAN version 6.6 déclenche le cluster pour qu'il communique de façon permanente en mode monodiffusion.
- Tous les hôtes du cluster exécutent vSAN 6.5 ou version antérieure.
- Tous les groupes de disques utilisent la version sur disque 3 ou antérieure.
- Un hôte non-vSAN 6.6, tel que vSAN 6.2 ou vSAN 6.5 est ajouté au cluster.
Par exemple, si un hôte exécutant vSAN 6.5 ou version antérieure est ajouté à un cluster vSAN 6.6 existant, le cluster revient en mode multidiffusion et inclut l'hôte 6.5 comme un nœud valide. Pour éviter ce comportement, utilisez la dernière version pour les hôtes ESXi et le format sur disque. Pour vous assurer que le cluster vSAN continue de communiquer en mode monodiffusion et ne revient pas à la multidiffusion, mettez à niveau les groupes de disques sur les hôtes vSAN 6.6 vers la version sur disque 5.0.
Comportement du groupe de disques version 5
La présence d'un groupe de disques version 5 unique dans un cluster vSAN version 6.6 déclenche le cluster pour communiquer de façon permanente en mode monodiffusion.
Dans un environnement où un cluster vSAN 6.6 utilise déjà une version sur disque 5 et un nœud vSAN 6.5 est ajouté au cluster, les événements suivants se produisent :
- Le nœud vSAN 6.5 forme sa propre partition réseau.
- Le nœud vSAN 6.5 continue de communiquer en mode multidiffusion, mais il ne peut pas communiquer avec les nœuds vSAN 6.6 lorsqu'ils utilisent le mode monodiffusion.
Un avertissement de résumé de cluster apparaît sur le format sur disque, indiquant qu'un nœud appartient à une version antérieure. Vous pouvez mettre le nœud à niveau vers la dernière version. Il n'est pas possible de mettre à niveau les versions de format de disque lorsqu'un cluster est en mode mixte.
Prise en charge de DHCP sur le réseau monodiffusion
Un déploiement vCenter Server sur un cluster vSAN 6.6 peut utiliser des adresses IP de protocole DHCP (DHCP) sans réservation.
Vous pouvez utiliser DHCP avec des réservations, car les adresses IP affectées sont liées aux adresses MAC des ports VMkernel.
Prise en charge d'IPv6 sur le réseau monodiffusion
vSAN 6.6 prend en charge IPv6 avec les communications monodiffusion.
Avec IPv6, l'adresse de liaison locale est automatiquement configurée sur toute interface utilisant le préfixe de liaison locale. Par défaut, vSAN n'ajoute pas l'adresse de liaison locale d'un nœud à d'autres nœuds de cluster voisins. vSAN 6.6 ne prend donc pas en charge les adresses locales de liaison IPv6 pour les communications monodiffusion.
Interroger la monodiffusion avec ESXCLI
Vous pouvez exécuter des commandes ESXCLI pour déterminer la configuration monodiffusion.
Afficher les modes de communication
À l'aide de la commande esxcli vsan cluster get, vous pouvez afficher le mode de CMMDS (monodiffusion ou multidiffusion) du nœud de cluster vSAN.
Procédure
- ♦ Exécutez la commande
esxcli vsan cluster get.
Résultats
Cluster Information
Enabled: true
Current Local Time: 2020-04-09T18:19:52Z
Local Node UUID: 5e8e3dc3-43ab-5452-795b-a03d6f88f022
Local Node Type: NORMAL
Local Node State: AGENT
Local Node Health State: HEALTHY
Sub-Cluster Master UUID: 5e8e3d3f-3015-9075-49b6-a03d6f88d426
Sub-Cluster Backup UUID: 5e8e3daf-e5e0-ddb6-a523-a03d6f88dd4a
Sub-Cluster UUID: 5282f9f3-d892-3748-de48-e2408dc34f72
Sub-Cluster Membership Entry Revision: 11
Sub_cluster Member Count: 5
Sub-Cluster Member UUIDs: 5e8e3d3f-3015-9075-49b6-a03d6f88d426, 5e8e3daf-e5e0-ddb6-a523-a03d6f88dd4a,
5e8e3d73-6d1c-0b81-1305-a03d6f888d22, 5e8e3d33-5825-ee5c-013c-a03d6f88ea4c, 5e8e3dc3-43ab-5452-795b-a03d6f88f022
Sub-Cluster Member HostNames: testbed-1.vmware.com, testbed2.vmware.com,
testbed3.vmware.com, testbed4.vmware.com, testbed5.vmware.com
Sub-Cluster Membership UUID: 0f438e5e-d400-1bb2-f4d1-a03d6f88d426
Mode monodiffusion activé : true
Maintenance Mode State: OFF
Config Generation: ed845022-5c08-48d0-aa1d-6b62c0022222 7 2020-04-08T22:44:14.889
Vérifier les hôtes du cluster vSAN
Utilisez la commande esxcli vsan cluster unicastagent list pour vérifier si les hôtes du cluster vSAN fonctionnent en mode monodiffusion.
Procédure
- ♦ Exécutez la commande
esxcli vsan cluster unicastagent list.
Résultats
NodeUuid IsWitness Supports Unicast IP Address Port Iface Name Cert Thumbprint SubClusterUuid ------------------------------------ --------- ---------------- ---------- ----- ---------- 5e8e3d73-6d1c-0b81-1305-a03d6f888d22 0 true 10.198.95.10 12321 43:80:B7:A1:3F:D1:64:07:8C:58:01:2B:CE:A2:F5:DE:D6:B1:41:AB 5e8e3daf-e5e0-ddb6-a523-a03d6f88dd4a 0 true 10.198.94.240 12321 FE:39:D7:A5:EF:80:D6:41:CD:13:70:BD:88:2D:38:6C:A0:1D:36:69 5e8e3d3f-3015-9075-49b6-a03d6f88d426 0 true 10.198.94.244 12321 72:A3:80:36:F7:5D:8F:CE:B0:26:02:96:00:23:7D:8E:C5:8C:0B:E1 5e8e3d33-5825-ee5c-013c-a03d6f88ea4c 0 true 10.198.95.11 12321 5A:55:74:E8:5F:40:2F:2B:09:B5:42:29:FF:1C:95:41:AB:28:E0:57
La sortie inclut l'UUID du nœud vSAN, l'adresse IPv4, l'adresse IPv6, le port UDP avec lequel le nœud vSAN communique et indique si le nœud est un hôte de données (0) ou un hôte témoin (1). Vous pouvez utiliser ce résultat pour identifier les nœuds de cluster vSAN qui fonctionnent en mode monodiffusion et afficher les autres hôtes du cluster. vCenter Server conserve la liste de sortie.
Afficher les informations sur le réseau vSAN
Utilisez la commande esxcli vsan network list pour afficher les informations de réseau vSAN, telles que l'interface VMkernel utilisée par vSAN pour la communication, le port monodiffusion (12321) et le type de trafic (vSAN ou témoin) associées à l'interface vSAN.
Procédure
- ♦ Exécutez la commande
esxcli vsan network list.
Résultats
Interface
VmkNic Name: vmk1
IP Protocol: IP
Interface UUID: e290be58-15fe-61e5-1043-246e962c24d0
Agent Group Multicast Address: 224.2.3.4
Agent Group IPv6 Multicast Address: ff19::2:3:4
Agent Group Multicast Port: 23451
Master Group Multicast Address: 224.1.2.3
Master Group IPv6 Multicast Address: ff19::1:2:3
Master Group Multicast Port: 12345
Host Unicast Channel Bound Port: 12321
Multicast TTL: 5
Traffic Type: vsan
Ce résultat affiche également les informations de multidiffusion.
Trafic intra-cluster
En mode monodiffusion, le nœud principal traite tous les nœuds du cluster, car il envoie le même message à tous les nœuds vSAN d'un cluster.
Par exemple, si N correspond au nombre de nœuds vSAN, le nœud principal envoie les messages N fois. Cela entraîne une légère augmentation du trafic de CMMDS vSAN. Vous ne remarquerez peut-être pas cette légère augmentation du trafic lors d'un fonctionnement normal en régime continu.
Trafic intra-cluster dans un seul rack
Si tous les nœuds d'un cluster vSAN sont connectés au même commutateur de haut de rack (TOR), l'augmentation totale du trafic se fait uniquement entre le nœud principal et le commutateur.
Si un cluster vSAN s'étend sur plusieurs commutateurs TOR, le trafic entre les commutateurs augmente. Si un cluster s'étend sur de nombreux racks, plusieurs TOR forment des domaines de pannes (FD) pour la détection des racks. Le nœud principal envoie N messages aux racks ou aux domaines de pannes, N correspondant au nombre d'hôtes dans chaque domaine de pannes.
Trafic intra-cluster dans un cluster étendu vSAN
Dans un cluster étendu vSAN, le nœud principal se trouve sur le site préféré.
Dans un domaine de pannes, les données CMMDS doivent être communiquées depuis le site secondaire vers le site préféré. Pour calculer le trafic dans un cluster étendu vSAN, vous devez multiplier le nombre de nœuds d'un site secondaire par la taille du nœud CMMDS (en Mo) par le nombre de nœuds du site secondaire.
Trafic dans un cluster étendu vSAN = nombre de nœuds dans le site secondaire * taille du nœud CMMDS (en Mo) * nombre de nœuds dans le site secondaire.
Avec le trafic monodiffusion, il n'y a aucune modification des conditions de trafic du site témoin.
