vSAN permite examinar y solucionar distintos tipos de problemas que surgen de una red de vSAN mal configurada.
Las operaciones de vSAN dependen de la configuración, la fiabilidad y el rendimiento de la red. Muchas solicitudes de soporte técnico provienen de una configuración de red incorrecta o de que la red no funciona según lo esperado.
Use el servicio de estado de vSAN para resolver problemas de red. Las comprobaciones del estado de la red pueden dirigirle a un artículo de la base de conocimientos adecuado, según los resultados de la comprobación de estado. El artículo de la base de conocimientos le proporcionará instrucciones para solucionar el problema de red.
Comprobaciones de estado de red
El servicio de estado incluye una categoría para las comprobaciones de estado de redes.
Cada comprobación de estado tiene un enlace AskVMware. Si se produce un error en una comprobación de estado, haga clic en AskVMware y lea el artículo de la base de conocimientos de VMware asociado para obtener más información y las instrucciones para solucionar el problema.
- vSAN: Comprobación básica de conectividad (unidifusión). Esta comprobación verifica que existe conectividad IP entre todos los hosts ESXi del clúster de vSAN haciendo ping a cada host ESXi de la red de vSAN desde cada host ESXi.
- vMotion: Comprobación básica de conectividad (unidifusión). Esta comprobación verifica que existe conectividad IP entre todos los hosts ESXi del clúster de vSAN que tengan vMotion configurado. Cada host ESXi de la red de vMotion hace ping a los demás hosts ESXi.
- Todos los hosts tienen una vmknic de vSAN configurada. Esta comprobación garantiza que cada host ESXi del clúster de vSAN tenga una NIC de VMkernel configurada para el tráfico de vSAN.
- Todos los hosts tienen configuración de multidifusión coincidente. Esta comprobación garantiza que cada host tenga una dirección de multidifusión configurada correctamente.
- Todos los hosts tienen subredes coincidentes. Esta comprobación verifica que todos los hosts ESXi de un clúster de vSAN se hayan configurado para que todas las NIC VMkernel de vSAN estén en la misma subred IP.
- Hosts desconectados de VC. Esta comprobación verifica que vCenter Server tiene una conexión activa con todos los hosts ESXi en el clúster de vSAN.
- Hosts con problemas de conectividad. Esta comprobación hace referencia a situaciones en las que las listas de vCenter Server muestran el host como conectado, pero las llamadas de la API desde vCenter al host están fallando. Puede resaltar los problemas de conectividad entre un host y vCenter Server.
- Latencia de red. Esta comprobación verifica la latencia de red de los hosts vSAN. Si el umbral supera los 5 ms, se mostrará una advertencia.
- vMotion: prueba de MTU (ping con tamaño de paquete grande). Esta comprobación complementa la comprobación de conectividad de ping de vMotion básica. El tamaño máximo de la unidad de transmisión aumenta para mejorar el rendimiento de la red. Es posible que las MTU configuradas de forma incorrecta no aparezcan como un problema de configuración de red, pero pueden causar problemas de rendimiento.
- Partición de clúster de vSAN. Esta comprobación de estado examina el clúster para ver cuántas particiones existen. Muestra un error si hay más de una partición en el clúster de vSAN.
- Evaluación de multidifusión basada en otras comprobaciones. Esta comprobación de estado agrega datos de todas las comprobaciones de estado de la red. Si se produce un error en esta comprobación, indica que es probable que la multidifusión sea la causa principal de una partición de red.
Comandos para comprobar la red
Cuando se haya configurado la red vSAN, utilice estos comandos para comprobar su estado. Puede comprobar qué adaptador de VMkernel (vmknic) se utiliza para vSAN y qué atributos contiene.
Utilice los comandos ESXCLI y RVC para comprobar que la red funciona perfectamente y solucionar cualquier problema de red con vSAN.
Puede comprobar que los vmknic utilizados para la red de vSAN estén configurados de manera uniforme en todos los hosts, comprobar que la multidifusión sea funcional y que los hosts que participan en el clúster de vSAN pueden comunicarse correctamente entre sí.
esxcli vsan network list
Este comando permite identificar la interfaz de VMkernel que utiliza la red de vSAN.
El siguiente resultado muestra que la red vSAN está utilizando vmk2. Este comando sigue funcionando aunque vSAN se haya desactivado y los hosts ya no participen en vSAN.
Es importante comprobar también la multidifusión del grupo de agentes y la multidifusión del grupo maestro.
[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
Esto proporciona información útil, como la interfaz de VMkernel que se utiliza para el tráfico de vSAN. En este caso, es vmk1. Sin embargo, también se muestran las direcciones de multidifusión. Es posible que esta información se muestre incluso cuando el clúster se ejecuta en modo de unidifusión. Existe el puerto y la dirección de multidifusión del grupo. El puerto 23451 se utiliza para el latido, enviado cada segundo por el principal, y es visible en los demás hosts del clúster. El puerto 12345 se utiliza para las actualizaciones de CMMDS entre el principal y la copia de seguridad.
esxcli network ip interface list
Este comando permite verificar elementos como vSwitch o conmutadores distribuidos.
Utilice este comando para comprobar a qué vSwitch o conmutador distribuido está asociado y el tamaño de MTU, que puede resultar útil si se han configurado tramas gigantes en el entorno. En este caso, MTU tiene el valor predeterminado de 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
El tamaño de la unidad de transmisión máxima se muestra como 9000, por lo que este puerto de VMkernel se configura para las tramas gigantes, que requieren una MTU de aproximadamente 9000. VMware no realiza ninguna recomendación sobre el uso de tramas gigantes. Sin embargo, se admite el uso de tramas gigantes con vSAN.
esxcli network ip interface ipv4 get –i vmk2
Este comando muestra información como la dirección IP y la máscara de red de la interfaz de VMkernel de vSAN.
Con esta información, un administrador ahora puede empezar a utilizar otros comandos disponibles en la línea de comandos para comprobar que la red vSAN funciona correctamente.
[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
El comando vmkping comprueba si los demás hosts ESXi de la red responden a sus solicitudes de 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
Aunque no se verifica la funcionalidad de multidifusión, puede ayudar a identificar un host ESXi malintencionado que tenga problemas de red. También puede examinar los tiempos de respuesta para ver si hay latencia anormal en la red de vSAN.
Si se configuran tramas gigantes, este comando no encontrará ningún problema si el tamaño de la MTU de las tramas gigantes es incorrecto. De forma predeterminada, este comando utiliza un tamaño de MTU de 1500. Si es necesario comprobar si las tramas gigantes funcionan correctamente de extremo a extremo, use vmkping con una opción de tamaño de paquete (-s) mayor, como se indica a continuación:
~ # 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 ~ #
Puede agregar -d al comando vmkping para probar si los paquetes se pueden enviar sin fragmentación.
esxcli network ip neighbor list
Este comando ayuda a comprobar si todos los hosts vSAN se encuentran en el mismo segmento de red.
En esta configuración, tenemos un clúster con cuatro hosts y este comando devuelve las entradas ARP (Protocolo de resolución de direcciones) de los otros tres hosts, incluidas sus direcciones IP y sus vmknic (vSAN está configurado para usar vmk1 en todos los hosts de este clúster).
[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
Este comando comprueba los duplicados en la red y los tiempos de ida y vuelta.
Para obtener más información sobre la conectividad de redes vSAN entre los distintos hosts, ESXCLI ofrece un comando de diagnóstico de red eficaz. A continuación se muestra un ejemplo de un resultado, en el que la interfaz de VMkernel se encuentra en vmk1 y la IP de red de vSAN remota de otro host de la red es 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
Este comando de RVC muestra la información del puerto de vínculo superior.
Si hay conmutadores que no son de Cisco con el protocolo de detección de nivel de vínculo (LLDP) habilitado en el entorno, existe un comando de RVC para mostrar la siguiente información: vínculo superior <-> conmutador <-> puerto del conmutador. Para obtener más información sobre RVC, consulte la guía de comandos de RVC.
Esto le ayudará a determinar qué hosts están conectados a qué conmutadores cuando el clúster de vSAN abarca varios conmutadores. Puede ayudar a aislar un problema en un determinado conmutador cuando solo se ve afectado un subconjunto de los hosts del clúster.
> 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 |+---------------+---------------------------+
Esto solo está disponible con los conmutadores que admiten LLDP. Para configurarlo, inicie sesión en el conmutador y ejecute lo siguiente:
switch# config t Switch(Config)# feature lldp
Para verificar que LLDP está habilitado:
switch(config)#do show running-config lldp
LLDP funciona en modo de envío y recepción de forma predeterminada. Compruebe la configuración de las propiedades del vDS si no se detecta la información del conmutador físico. De forma predeterminada, el vDS se crea con el protocolo de detección configurado en CDP (Cisco Discovery Protocol). Para solucionar este error, establezca el protocolo de detección en LLDP y establezca la operación en Ambos en el vDS.
Comprobar las comunicaciones de multidifusión
Las configuraciones de multidifusión pueden causar problemas en la implementación inicial de vSAN.
Una de las formas más sencillas de comprobar si la multidifusión funciona correctamente en el entorno de vSAN es mediante el comando tcpdump-uw. Este comando está disponible en la línea de comandos de los hosts ESXi.
El comando tcpdump-uw muestra si el principal está enviando correctamente paquetes de multidifusión (información de puerto e IP) y si los demás hosts del clúster los reciben.
En el nodo principal, este comando muestra los paquetes que se envían a la dirección de multidifusión. En los demás hosts, los mismos paquetes son visibles (desde el principal a la dirección de multidifusión). Si no están visibles, la multidifusión no funciona correctamente. Ejecute el comando tcpdump-uw que se muestra aquí en cualquier host del clúster y los latidos del principal estarán visibles. En este caso, el nodo principal se encuentra en la dirección IP 172.32.0.2. El uso de -v para nivel de detalle es opcional.
[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
Aunque esta solución puede parecer un poco confusa, basta con decir que el resultado que se muestra aquí indica que los cuatro hosts del clúster están recibiendo un latido del principal. Se debe ejecutar el comando tcpdump-uw en cada host para comprobar que todos están recibiendo el latido. Esto comprueba que el principal está enviando los latidos y que los demás hosts del clúster los están recibiendo, lo que indica que la multidifusión funciona.
Si algunos de los hosts de vSAN no reciben los latidos de un segundo del principal, el administrador de red debe comprobar la configuración de multidifusión de sus conmutadores.
Para evitar el molesto mensaje truncated-ip – 146 bytes missing!, utilice la opción -s0 en el mismo comando para detener el truncado de paquetes:
[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
El comando tcpdump está relacionado con la pertenencia a IGMP (protocolo de administración de grupos de Internet). Los hosts (y los dispositivos de red) utilizan IGMP para establecer la pertenencia al grupo de multidifusión.
Cada host ESXi en el clúster de vSAN envía informes de pertenencia IGMP normales (Unirse).
El comando tcpdump muestra los informes de miembros de IGMP de un host:
[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)
El resultado muestra que los informes de IGMP v3 se están realizando, lo que indica que el host ESXi está actualizando su pertenencia de forma regular. Si un administrador de red tiene dudas sobre si los hosts ESXi de vSAN están realizando IGMP de forma correcta, ejecute este comando en cada host ESXi del clúster y use este seguimiento para comprobarlo.
Si tiene comunicaciones de multidifusión, use IGMP 3.
De hecho, el siguiente comando se puede utilizar para ver el tráfico de multidifusión e IGMP al mismo tiempo:
[root@esxi-hp-02:~] tcpdump-uw -i vmk2 multicast or igmp -v -s0
Un problema común es que el clúster de vSAN está configurado en varios conmutadores físicos y, mientras que la multidifusión se habilitó en un conmutador, no se habilitó en todos los conmutadores. En este caso, el clúster se crea con dos hosts ESXi en una partición y otro host ESXi (conectado al otro conmutador) no puede unirse a este clúster. En su lugar, crea su propio clúster de vSAN en otra partición. El comando vsan.lldpnetmap que vimos antes le ayudará a determinar la configuración de red y los hosts asociados a ese conmutador.
Mientras se crea un clúster de vSAN, hay indicadores que muestran que la multidifusión pueden ser un problema.
Supongamos que siguió la lista de comprobación de subred, VLAN y MTU, y cada host del clúster puede hacer vmkping en todos los hosts del clúster.
Si se produce un problema de multidifusión cuando se crea el clúster, un síntoma común es que cada host ESXi crea su propio clúster vSAN, con él mismo como principal. Si cada host tiene un identificador de partición de red único, este síntoma sugiere que no hay multidifusión entre cualquiera de los hosts.
Sin embargo, si un subconjunto de los hosts ESXi crea un clúster y otro subconjunto crea otro clúster, y cada uno tiene particiones únicas con su propio principal, su propia copia de seguridad e incluso sus propios hosts de agente, la multidifusión se habilita en el conmutador, pero no entre conexiones. vSAN muestra los hosts en el primer conmutador físico creando su propia partición del clúster, y los hosts del segundo conmutador físico creando también su propia partición del clúster, cada uno con su propio principal. Si puede verificar a qué conmutadores se conectan los hosts del clúster y si los hosts de un clúster están conectados al mismo conmutador, es probable que este sea el problema.
Comprobar el rendimiento de las redes de vSAN
Asegúrese de que haya suficiente ancho de banda entre los hosts ESXi. Esta herramienta puede ayudarle a probar si la red de vSAN funciona de forma óptima.
Para comprobar el rendimiento de la red de vSAN, puede usar la herramienta iperf para medir la latencia y el ancho de banda de TCP máximos. Se encuentra en /usr/lib/vmware/vsan/bin/iperf.copy. Ejecútela con -–help para ver las distintas opciones. Use esta herramienta para comprobar el ancho de banda y la latencia de la red entre los hosts ESXi que participan en un clúster de vSAN.
El artículo 2001003 de la base de conocimientos de VMware incluye información sobre la configuración y las pruebas.
Esto resulta especialmente útil cuando se realiza una puesta en servicio de un clúster de vSAN. La ejecución de las pruebas iperf en la red de vSAN cuando el clúster ya está en producción puede afectar al rendimiento de las máquinas virtuales que se ejecutan en el clúster.
Comprobar los límites de red de vSAN
El comando vsan.check.limits permite comprobar que no se esté infringiendo ninguno de los umbrales de vSAN.
> 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>>
Desde el punto de vista de la red, lo importante son las asociaciones de RDT y el número de sockets. Hay 45.000 asociaciones por host en vSAN 6.0 y versiones posteriores. Se utiliza una asociación de RDT para supervisar el estado de la red de igual a igual en vSAN. El tamaño de vSAN se ajusta para que nunca se ejecute fuera de las asociaciones de RDT. vSAN también limita cuántos sockets TCP pueden usarse y se ajusta su tamaño para que nunca se agote su asignación de sockets TCP. Hay un límite de 10.000 sockets por host.
Un cliente vSAN representa el acceso del objeto en el clúster de vSAN. El cliente suele representar una máquina virtual que se ejecuta en un host. Es posible que el cliente y el objeto no estén en el mismo host. No hay ningún límite definido, pero esta métrica se muestra para ayudar a comprender el modo en que los clientes equilibran los hosts.
Solo hay un propietario de vSAN para cada objeto de vSAN, que normalmente se encuentra en la misma ubicación que el cliente de vSAN que accede a este objeto. Los propietarios de vSAN coordinan todo el acceso al objeto de vSAN e implementan funciones, como la creación de reflejos y la fragmentación. No hay ningún límite definido, pero esta métrica se muestra una vez más para ayudar a comprender el modo en que los propietarios equilibran los hosts.
