vSAN vous permet d'examiner et de résoudre les différents types de problèmes qui découlent d'un réseau vSAN incorrectement configuré.
Les opérations de vSAN dépendent de la configuration, de la fiabilité et des performances du réseau. De nombreuses demandes de support proviennent d'une configuration de réseau incorrecte ou du fait que le réseau ne fonctionne pas comme prévu.
Utilisez le service de santé vSAN pour résoudre les problèmes liés au réseau. Les contrôles de santé du réseau peuvent vous orienter vers un article approprié de la base de connaissances, en fonction des résultats du contrôle de santé. L'article de la base de connaissances contient des instructions pour résoudre le problème de réseau.
Contrôles de santé du réseau
Le service de santé inclut une catégorie pour les contrôles de santé de mise en réseau.
À chaque contrôle de santé est associé un lien AskVMware. En cas d'échec d'un contrôle de santé, cliquez sur AskVMware et lisez l'article de la base de connaissances VMware associé pour obtenir de plus amples détails et des conseils sur la procédure de résolution du problème.
- vSAN : vérification de la connectivité (monodiffusion) de base. Ce contrôle permet de vérifier que la connectivité IP existe entre tous les hôtes ESXi du cluster vSAN, en exécutant une commande Ping sur chaque hôte ESXi du réseau vSAN à partir de chaque autre hôte ESXi.
- vMotion : vérification de la connectivité (monodiffusion) de base. Ce contrôle permet de vérifier qu'une connectivité IP existe entre tous les hôtes ESXi du cluster vSAN sur lesquels vMotion est configuré. Chaque hôte ESXi sur le réseau vMotion envoie une commande Ping à tous les autres hôtes ESXi.
- Une vmknic vSAN est configurée pour tous les hôtes. Ce contrôle permet de vous assurer que chaque hôte ESXi du cluster vSAN dispose d'une carte réseau VMkernel configurée pour le trafic vSAN.
- Tous les hôtes ont des paramètres multidiffusion correspondants. Ce contrôle permet de vous assurer qu'une adresse multidiffusion est correctement configurée pour chaque hôte.
- Tous les hôtes ont des sous-réseaux correspondants. Ce contrôle permet de vérifier que tous les hôtes ESXi d'un cluster vSAN ont été configurés de manière à ce que toutes les cartes réseau VMkernel vSAN se trouvent sur le même sous-réseau IP.
- Hôtes déconnectés de VC. Ce contrôle permet de vérifier que le vCenter Server dispose d'une connexion active sur tous les hôtes ESXi du cluster vSAN.
- Hôtes présentant des problèmes de connectivité. Ce contrôle fait référence aux cas où vCenter Server indique que l'hôte est connecté, mais où les appels API de vCenter sur l'hôte échouent. Il peut mettre en évidence les problèmes de connectivité entre un hôte et le vCenter Server.
- Latence du réseau. Ce contrôle procède à une vérification de la latence du réseau des hôtes vSAN. Si le seuil est supérieur à 100 ms, un avertissement s'affiche. Si le seuil de latence est supérieur à 200 ms, une erreur est générée.
- vMotion : contrôles de MTU (test Ping avec des paquets de grande taille). Ce contrôle complète la vérification de la connectivité Ping de base de vMotion. La taille maximale de l'unité de transmission est augmentée pour améliorer les performances du réseau. Les MTU configurés de manière incorrecte peuvent ne pas apparaître comme un problème de configuration du réseau, mais peuvent provoquer des problèmes de performances.
- Partition du cluster vSAN. Ce contrôle de santé examine le cluster pour identifier le nombre de partitions existantes. Il affiche une erreur si le cluster vSAN contient plusieurs partitions.
- Évaluation de la multidiffusion basée sur d'autres contrôles. Ce contrôle de santé regroupe les données de tous les contrôles de santé du réseau. Si ce contrôle échoue, cela indique que la multidiffusion est probablement la cause principale d'une partition réseau.
Commandes de vérification du réseau
Lorsque le réseau vSAN a été configuré, utilisez ces commandes pour vérifier son état. Vous pouvez vérifier l'adaptateur VMkernel (vmknic) utilisé pour vSAN et les attributs qu'il contient.
Utilisez les commandes ESXCLI et RVC pour vérifier que le réseau est entièrement fonctionnel et pour résoudre tous les problèmes de réseau liés à vSAN.
Vous pouvez vérifier que le vmknic utilisé pour le réseau vSAN est correctement configuré sur tous les hôtes, que la multidiffusion est fonctionnelle et que les hôtes participant au cluster vSAN peuvent communiquer correctement entre eux.
esxcli vsan network list
Cette commande vous permet d'identifier l'interface VMkernel utilisée par le réseau vSAN.
Le résultat ci-dessous indique que le réseau vSAN utilise vmk2. Cette commande continue de fonctionner, même si vSAN a été désactivé sur le cluster et que les hôtes ne participent plus à vSAN.
Il convient également de contrôler la multidiffusion du groupe d'agents et la multidiffusion du groupe de maîtres.
[root@esxi-dell-m:~] esxcli vsan network list Interface VmkNic Name: vmk1 IP Protocol: IP Interface UUID: 32efc758-9ca0-57b9-c7e3-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
Cela fournit des informations utiles, telles que l'interface VMkernel utilisée pour le trafic vSAN. Dans ce cas, il s'agit de vmk1. Toutefois, les adresses multidiffusion sont également affichées. Cette information peut s'afficher même lorsque le cluster est en cours d'exécution en mode monodiffusion. L'adresse et le port multidiffusion du groupe sont présents. Le port 23451 est utilisé pour le signal de pulsation, envoyé toutes les secondes par l'hôte principal, et est visible sur tous les autres hôtes du cluster. Le port 12345 est utilisé pour les mises à jour de CMMDS entre les hôtes principal et de sauvegarde.
esxcli network ip interface list
Cette commande vous permet de vérifier des éléments tels que vSwitch ou le commutateur distribué.
Utilisez cette commande pour vérifier le vSwitch ou le commutateur distribué auquel il est associé, ainsi que la taille du MTU, qui peut être utile si les trames Jumbo ont été configurées dans l'environnement. Dans ce cas, le MTU a la valeur par défaut 1500.
[root@esxi-dell-m:~] esxcli network ip interface list vmk0 Name: vmk0 <<truncated>> vmk1 Name: vmk1 MAC Address: 00:50:56:69:96:f0 Enabled: true Portset: DvsPortset-0 Portgroup: N/A Netstack Instance: defaultTcpipStack VDS Name: vDS VDS UUID: 50 1e 5b ad e3 b4 af 25-18 f3 1c 4c fa 98 3d bb VDS Port: 16 VDS Connection: 1123658315 Opaque Network ID: N/A Opaque Network Type: N/A External ID: N/A MTU: 9000 TSO MSS: 65535 Port ID: 50331814
La taille maximale de l'unité de transmission indiquée est de 9000. Ce port VMkernel est donc configuré pour les trames Jumbo, qui nécessitent un MTU d'environ 9000. VMware ne fournit aucune recommandation concernant l'utilisation des trames Jumbo. Cependant, les trames Jumbo peuvent être utilisées avec vSAN.
esxcli network ip interface ipv4 get –i vmk2
Cette commande affiche des informations telles que l'adresse IP et le masque de réseau de l'interface VMkernel vSAN.
Avec ces informations, un administrateur peut à présent commencer à utiliser d'autres commandes disponibles sur la ligne de commande pour vérifier que le réseau vSAN fonctionne correctement.
[root@esxi-dell-m:~] esxcli network ip interface ipv4 get -i vmk1 Name IPv4 Address IPv4 Netmask IPv4 Broadcast Address Type Gateway DHCP DNS ---- ------------ ------------- -------------- ------------ ------- -------- vmk1 172.40.0.9 255.255.255.0 172.40.0.255 STATIC 0.0.0.0 false
vmkping
La commande vmkping vérifie si tous les autres hôtes ESXi du réseau répondent à vos demandes Ping.
~ # vmkping -I vmk2 172.32.0.3 -s 1472 -d PING 172.32.0.3 (172.32.0.3): 56 data bytes 64 bytes from 172.32.0.3: icmp_seq=0 ttl=64 time=0.186 ms 64 bytes from 172.32.0.3: icmp_seq=1 ttl=64 time=2.690 ms 64 bytes from 172.32.0.3: icmp_seq=2 ttl=64 time=0.139 ms --- 172.32.0.3 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.139/1.005/2.690 ms
Même s'il ne vérifie pas la fonctionnalité de multidiffusion, il peut faciliter l'identification d'un hôte ESXi non autorisé qui présente des problèmes de réseau. Vous pouvez également examiner les délais de réponse pour vérifier l'existence d'une latence anormale sur le réseau vSAN.
Si les trames Jumbo sont configurées, cette commande ne signale aucun problème si la taille du MTU de trame Jumbo est incorrecte. Par défaut, cette commande utilise une taille de MTU de 1500. S'il est nécessaire de vérifier que les trames Jumbo fonctionnent correctement de bout en bout, utilisez vmkping avec une option de taille de paquet supérieure (-s) comme suit :
~ # vmkping -I vmk2 172.32.0.3 -s 8972 -d PING 172.32.0.3 (172.32.0.3): 8972 data bytes 9008 bytes from 172.32.0.3: icmp_seq=0 ttl=64 time=0.554 ms 9008 bytes from 172.32.0.3: icmp_seq=1 ttl=64 time=0.638 ms 9008 bytes from 172.32.0.3: icmp_seq=2 ttl=64 time=0.533 ms --- 172.32.0.3 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.533/0.575/0.638 ms ~ #
Pensez à ajouter-d à la commande vmkping pour déterminer si des paquets peuvent être envoyés sans fragmentation.
esxcli network ip neighbor list
Cette commande permet de vérifier si tous les hôtes vSAN se trouvent sur le même segment de réseau.
Dans cette configuration, nous disposons d'un cluster à quatre hôtes, et cette commande renvoie les entrées ARP (Address Resolution Protocol) des trois autres hôtes, notamment leurs adresses IP et leur vmknic (vSAN est configuré pour utiliser vmk1 sur tous les hôtes de ce cluster).
[root@esxi-dell-m:~] esxcli network ip neighbor list -i vmk1 Neighbor Mac Address Vmknic Expiry State Type ----------- ----------------- ------ ------- ----- ------- 172.40.0.12 00:50:56:61:ce:22 vmk1 164 sec Unknown 172.40.0.10 00:50:56:67:1d:b2 vmk1 338 sec Unknown 172.40.0.11 00:50:56:6c:fe:c5 vmk1 162 sec Unknown [root@esxi-dell-m:~]
esxcli network diag ping
Cette commande vérifie les doublons sur le réseau et les temps aller-retour.
Pour obtenir de plus amples détails sur la connectivité réseau vSAN entre les différents hôtes, ESXCLI propose une commande de diagnostic de réseau puissante. Vous trouverez ci-dessous un exemple de ce type de résultat, où l'interface VMkernel se trouve sur vmk1 et où l'adresse IP du réseau vSAN distant d'un autre hôte sur le réseau est 172.40.0.10
[root@esxi-dell-m:~] esxcli network diag ping -I vmk1 -H 172.40.0.10
Trace:
Received Bytes: 64
Host: 172.40.0.10
ICMP Seq: 0
TTL: 64
Round-trip Time: 1864 us
Dup: false
Detail:
Received Bytes: 64
Host: 172.40.0.10
ICMP Seq: 1
TTL: 64
Round-trip Time: 1834 us
Dup: false
Detail:
Received Bytes: 64
Host: 172.40.0.10
ICMP Seq: 2
TTL: 64
Round-trip Time: 1824 us
Dup: false
Detail:
Summary:
Host Addr: 172.40.0.10
Transmitted: 3
Recieved: 3
Duplicated: 0
Packet Lost: 0
Round-trip Min: 1824 us
Round-trip Avg: 1840 us
Round-trip Max: 1864 us
[root@esxi-dell-m:~]
vsan.lldpnetmap
Cette commande RVC affiche des informations sur le port de liaison montante.
S'il existe des commutateurs non Cisco avec LLDP (Link Layer Discovery Protocol) activé dans l'environnement, il existe une commande RVC pour afficher des informations sur la liaison montante <-> le commutateur <-> le port de commutateur. Pour plus d'informations sur RVC, reportez-vous au Guide de commandes RVC.
Cela vous permet de déterminer les hôtes et les commutateurs auxquels ils sont reliés lorsque le cluster vSAN s'étend sur plusieurs commutateurs. Il peut faciliter l'isolement d'un problème sur un commutateur spécifique lorsque seul un sous-ensemble des hôtes du cluster est concerné.
> vsan.lldpnetmap 02013-08-15 19:34:18 -0700: This operation will take 30-60 seconds ...+---------------+---------------------------+| Host | LLDP info |+---------------+---------------------------+| 10.143.188.54 | w2r13-vsan-x650-2: vmnic7 || | w2r13-vsan-x650-1: vmnic5 |+---------------+---------------------------+
Cette fonction est uniquement disponible avec les commutateurs prenant en charge LLDP. Pour le configurer, connectez-vous au commutateur et exécutez ce qui suit :
switch# config t Switch(Config)# feature lldp
Pour vérifier que LLDP est activé :
switch(config)#do show running-config lldp
LLDP fonctionne en mode d'envoi et de réception, par défaut. Vérifiez les paramètres des propriétés du vDS si les informations sur le commutateur physique ne sont pas détectées. Par défaut, le vDS est créé avec le protocole de détection défini sur CDP, le protocole de détection Cisco. Pour résoudre ce problème, définissez le protocole de détection sur LLDP et définissez l'opération pour les deux sur le vDS.
Vérification des communications multidiffusion
Les configurations multidiffusion peuvent entraîner des problèmes de déploiement initial de vSAN.
L'une des méthodes les plus simples pour vérifier si la multidiffusion fonctionne correctement dans votre environnement vSAN consiste à utiliser la commande tcpdump-uw. Cette commande est disponible à partir de la ligne de commande des hôtes ESXi.
Cette commande tcpdump-uw indique si l'hôte principal envoie correctement les paquets multidiffusion (port et informations IP) et si tous les autres hôtes du cluster les reçoivent.
Sur l'hôte principal, cette commande affiche les paquets envoyés à l'adresse multidiffusion. Sur tous les autres hôtes, les mêmes paquets sont visibles (de l'hôte principal à l'adresse multidiffusion). S'ils ne sont pas visibles, la multidiffusion ne fonctionne pas correctement. Exécutez la commande tcpdump-uw indiquée ici sur n'importe quel hôte du cluster, et les signaux de pulsation de l'hôte principal sont visibles. Dans ce cas, l'hôte principal se trouve à l'adresse IP 172.32.0.2. Le -v désignant le niveau de détails est facultatif.
[root@esxi-hp-02:~] tcpdump-uw -i vmk2 multicast -v tcpdump-uw: listening on vmk2, link-type EN10MB (Ethernet), capture size 96 bytes 11:04:21.800575 IP truncated-ip - 146 bytes missing! (tos 0x0, ttl 5, id 34917, offset 0, flags [none], proto UDP (17), length 228) 172.32.0.4.44824 > 224.1.2.3.12345: UDP, length 200 11:04:22.252369 IP truncated-ip - 234 bytes missing! (tos 0x0, ttl 5, id 15011, offset 0, flags [none], proto UDP (17), length 316) 172.32.0.2.38170 > 224.2.3.4.23451: UDP, length 288 11:04:22.262099 IP truncated-ip - 146 bytes missing! (tos 0x0, ttl 5, id 3359, offset 0, flags [none], proto UDP (17), length 228) 172.32.0.3.41220 > 224.2.3.4.23451: UDP, length 200 11:04:22.324496 IP truncated-ip - 146 bytes missing! (tos 0x0, ttl 5, id 20914, offset 0, flags [none], proto UDP (17), length 228) 172.32.0.5.60460 > 224.1.2.3.12345: UDP, length 200 11:04:22.800782 IP truncated-ip - 146 bytes missing! (tos 0x0, ttl 5, id 35010, offset 0, flags [none], proto UDP (17), length 228) 172.32.0.4.44824 > 224.1.2.3.12345: UDP, length 200 11:04:23.252390 IP truncated-ip - 234 bytes missing! (tos 0x0, ttl 5, id 15083, offset 0, flags [none], proto UDP (17), length 316) 172.32.0.2.38170 > 224.2.3.4.23451: UDP, length 288 11:04:23.262141 IP truncated-ip - 146 bytes missing! (tos 0x0, ttl 5, id 3442, offset 0, flags [none], proto UDP (17), length 228) 172.32.0.3.41220 > 224.2.3.4.23451: UDP, length 200
Même si ce résultat peut sembler un peu confus, il va sans dire que le résultat affiché ici indique que les quatre hôtes du cluster obtiennent un signal de pulsation de l'hôte principal. Cette commande tcpdump-UW doit être exécutée sur chaque hôte pour vérifier qu'ils reçoivent tous le signal de pulsation. Cela permet de vérifier que l'hôte principal envoie les signaux de pulsation et que tous les autres hôtes du cluster les reçoivent, indiquant ainsi que la multidiffusion fonctionne.
Si certains des hôtes vSAN ne parviennent pas à détecter les signaux de pulsation d'une seconde de l'hôte principal, l'administrateur réseau doit vérifier la configuration multidiffusion de leurs commutateurs.
Pour éviter l'affichage du message ennuyeux IP tronqué – 146 octets manquants !, utilisez l'option –s0 sur la même commande pour interrompre la troncature de paquets :
[root@esxi-hp-02:~] tcpdump-uw -i vmk2 multicast -v -s0
tcpdump-uw: listening on vmk2, link-type EN10MB (Ethernet), capture size 65535 bytes
11:18:29.823622 IP (tos 0x0, ttl 5, id 56621, offset 0, flags [none], proto UDP (17), length 228)
172.32.0.4.44824 > 224.1.2.3.12345: UDP, length 200
11:18:30.251078 IP (tos 0x0, ttl 5, id 52095, offset 0, flags [none], proto UDP (17), length 228)
172.32.0.3.41220 > 224.2.3.4.23451: UDP, length 200
11:18:30.267177 IP (tos 0x0, ttl 5, id 8228, offset 0, flags [none], proto UDP (17), length 316)
172.32.0.2.38170 > 224.2.3.4.23451: UDP, length 288
11:18:30.336480 IP (tos 0x0, ttl 5, id 28606, offset 0, flags [none], proto UDP (17), length 228)
172.32.0.5.60460 > 224.1.2.3.12345: UDP, length 200
11:18:30.823669 IP (tos 0x0, ttl 5, id 56679, offset 0, flags [none], proto UDP (17), length 228)
172.32.0.4.44824 > 224.1.2.3.12345: UDP, length 200
La commande tcpdump est associée à l'appartenance IGMP (Internet Group Management Protocol). Les hôtes (et les périphériques réseau) utilisent IGMP pour établir l'appartenance au groupe multidiffusion.
Chaque hôte ESXi du cluster vSAN envoie des rapports d'adhésion IGMP réguliers (jonction).
La commande tcpdump affiche les rapports de membres IGMP d'un hôte :
[root@esxi-dell-m:~] tcpdump-uw -i vmk1 igmp tcpdump-uw: verbose output suppressed, use -v or -vv for full protocol decode listening on vmk1, link-type EN10MB (Ethernet), capture size 262144 bytes 15:49:23.134458 IP 172.40.0.9 > igmp.mcast.net: igmp v3 report, 1 group record(s) 15:50:22.994461 IP 172.40.0.9 > igmp.mcast.net: igmp v3 report, 1 group record(s)
La sortie montre que les rapports IGMP v3 sont établis, ce qui indique que l'hôte ESXi met régulièrement à jour son appartenance. Si un administrateur réseau a des doutes sur l'exécution correcte d'IGMP par les hôtes vSAN ESXi, l'exécution de cette commande sur chaque hôte ESXi du cluster et l'affichage de cette trace peuvent être utilisés pour la vérification.
Si vous disposez de communications multidiffusion, utilisez IGMP v3.
En effet, la commande suivante peut être utilisée pour examiner simultanément le trafic multidiffusion et IGMP :
[root@esxi-hp-02:~] tcpdump-uw -i vmk2 multicast or igmp -v -s0
Il arrive fréquemment que le cluster vSAN soit configuré sur plusieurs commutateurs physiques, mais alors que la multidiffusion a été activée sur un commutateur en particulier, elle n'a pas été activée sur tous les commutateurs. Dans ce cas, les formulaires de cluster avec deux hôtes ESXi dans une partition et un autre hôte ESXi (connecté à l'autre commutateur) ne peuvent pas joindre ce cluster. En lieu et place, il forme son propre cluster vSAN dans une autre partition. La commande vsan.lldpnetmap présentée précédemment peut vous aider à déterminer la configuration du réseau, ainsi que les hôtes et les commutateurs auxquels ils sont attachés.
Pendant qu'un cluster vSAN se forme, des indicateurs montrent que la multidiffusion peut poser problème.
Supposons que la liste de contrôle du sous-réseau, du VLAN et de la MTU a été suivie et que chaque hôte du cluster peut exécuter la commande vmkping sur chaque hôte du cluster.
En cas de problème de multidiffusion lors de la création du cluster, un symptôme commun est que chaque hôte ESXi forme son propre cluster vSAN, lui-même constituant l'hôte principal. Si chaque hôte possède un ID de partition réseau unique, ce symptôme suggère qu'il n'existe aucune multidiffusion entre les hôtes.
Cependant, si dans un cas particulier, un sous-ensemble des hôtes ESXi forme un cluster, qu'un autre sous-ensemble forme un autre cluster et que chacun d'entre eux possède des partitions uniques avec leur propre l'hôte principal, une sauvegarde, voire des hôtes d'agent, la multidiffusion est alors activée sur le commutateur, mais pas dans l'ensemble des commutateurs. vSAN affiche les hôtes sur le premier commutateur physique formant leur propre partition de cluster et les hôtes sur le second commutateur physique formant leur propre partition de cluster, chacun avec son propre l'hôte principal. Si vous pouvez vérifier les commutateurs auxquels les hôtes du cluster se connectent et que les hôtes d'un cluster sont connectés au même commutateur, le problème se situe probablement à ce niveau.
Vérification des performances du réseau vSAN
Assurez-vous que la bande passante est suffisante entre vos hôtes ESXi. Cet outil peut vous aider à vérifier si votre réseau vSAN fonctionne de manière optimale.
Pour vérifier les performances du réseau vSAN, vous pouvez utiliser l'outil iperf pour mesurer la bande passante et la latence TCP maximales. Ce dernier se trouve dans /usr/lib/vmware/vsan/bin/iperf.copy. L'exécuter avec -–help pour afficher les différentes options. Utilisez cet outil pour vérifier la bande passante et la latence réseau entre les hôtes ESXi participant à un cluster vSAN.
L'article 2001003 de la base de connaissances VMware peut vous assister dans les tâches de configuration et de test.
Cela est très utile lorsqu'un cluster vSAN est mis en service. L'exécution des tests de iperf sur le réseau vSAN lorsque le cluster est déjà en production peut nuire aux performances des machines virtuelles exécutées sur le cluster.
Vérification des limites du réseau vSAN
La commande vsan.check.limits vérifie qu'aucun des seuils vSAN n'est dépassé.
> ls 0 / 1 vcsa-04.rainpole.com/ > cd 1 /vcsa-04.rainpole.com> ls 0 Datacenter (datacenter) /vcsa-04.rainpole.com> cd 0 /vcsa-04.rainpole.com/Datacenter> ls 0 storage/ 1 computers [host]/ 2 networks [network]/ 3 datastores [datastore]/ 4 vms [vm]/ /vcsa-04.rainpole.com/Datacenter> cd 1 /vcsa-04.rainpole.com/Datacenter/computers> ls 0 Cluster (cluster): cpu 155 GHz, memory 400 GB 1 esxi-dell-e.rainpole.com (standalone): cpu 38 GHz, memory 123 GB 2 esxi-dell-f.rainpole.com (standalone): cpu 38 GHz, memory 123 GB 3 esxi-dell-g.rainpole.com (standalone): cpu 38 GHz, memory 123 GB 4 esxi-dell-h.rainpole.com (standalone): cpu 38 GHz, memory 123 GB /vcsa-04.rainpole.com/Datacenter/computers> vsan.check_limits 0 2017-03-14 16:09:32 +0000: Querying limit stats from all hosts ... 2017-03-14 16:09:34 +0000: Fetching vSAN disk info from esxi-dell-m.rainpole.com (may take a moment) ... 2017-03-14 16:09:34 +0000: Fetching vSAN disk info from esxi-dell-n.rainpole.com (may take a moment) ... 2017-03-14 16:09:34 +0000: Fetching vSAN disk info from esxi-dell-o.rainpole.com (may take a moment) ... 2017-03-14 16:09:34 +0000: Fetching vSAN disk info from esxi-dell-p.rainpole.com (may take a moment) ... 2017-03-14 16:09:39 +0000: Done fetching vSAN disk infos +--------------------------+--------------------+-----------------------------------------------------------------+ | Host | RDT | Disks | +--------------------------+--------------------+-----------------------------------------------------------------+ | esxi-dell-m.rainpole.com | Assocs: 1309/45000 | Components: 485/9000 | | | Sockets: 89/10000 | naa.500a075113019b33: 0% Components: 0/0 | | | Clients: 136 | naa.500a075113019b37: 40% Components: 81/47661 | | | Owners: 138 | t10.ATA_____Micron_P420m2DMTFDGAR1T4MAX_____ 0% Components: 0/0 | | | | naa.500a075113019b41: 37% Components: 80/47661 | | | | naa.500a07511301a1eb: 38% Components: 81/47661 | | | | naa.500a075113019b39: 39% Components: 79/47661 | | | | naa.500a07511301a1ec: 41% Components: 79/47661 | <<truncated>>
Du point de vue du réseau, le nombre d'associations RDT (assoc.) et de sockets constituent les aspects les plus importants. Il existe 45 000 associations par hôte dans vSAN 6.0 et version ultérieure. Une association RDT est utilisée pour suivre l'état du réseau poste à poste dans vSAN. vSAN est dimensionné de sorte qu'il n'est jamais à court d'associations RDT. vSAN limite également le nombre de sockets TCP qu'il est autorisé à utiliser et vSAN est dimensionné de sorte que son allocation de sockets TCP n'arrive jamais à échéance. Il existe une limite de 10 000 sockets par hôte.
Un client vSAN représente l'accès de l'objet dans le cluster vSAN. Le client représente généralement une machine virtuelle s'exécutant sur un hôte. Le client et l'objet ne se trouvent pas sur le même hôte. Il n'existe pas de limite définie, mais cette mesure s'affiche pour vous aider à comprendre comment les clients s'équilibrent entre les hôtes.
Il n'y a qu'un seul propriétaire vSAN pour un objet vSAN spécifique, généralement colocalisé avec le client vSAN accédant à cet objet. Les propriétaires de vSAN coordonnent tous les accès à l'objet vSAN et mettent en œuvre des fonctionnalités comme la mise en miroir et la répartition. Il n'existe pas de limite définie, mais cette mesure est à nouveau affichée afin de mieux comprendre comment les propriétaires s'équilibrent entre les hôtes.
