vSAN permite examinar e solucionar os diferentes tipos de problemas que surgem de uma rede vSAN configurada incorretamente.
As operações do vSAN dependem da configuração, da confiabilidade e do desempenho da rede. Muitas solicitações de suporte resultam de uma configuração de rede incorreta ou do não desempenho da rede conforme o esperado.
Use o serviço de integridade vSAN para resolver problemas de rede. As verificações de integridade da rede podem direcionar você para um artigo apropriado da Base de Dados de Conhecimento, dependendo dos resultados da verificação de integridade. O artigo da Base de Conhecimento fornece instruções para solucionar o problema de rede.
Verificações de integridade da rede
O serviço de integridade inclui uma categoria para verificações de integridade de rede.
Cada verificação de integridade tem um link Perguntar VMware. Se uma verificação de integridade falhar, clique em Perguntar VMware e leia o artigo da Base de conhecimento VMware associado para obter mais detalhes e orientações sobre como resolver o problema em questão.
- vSAN: Verificação de conectividade básica (unicast). Essa verificação verifica se existe conectividade IP entre todos os hosts ESXi no cluster vSAN, executando ping em cada host ESXi na rede vSAN de cada outro host ESXi.
- vMotion: verificação de conectividade básica (unicast). Essa verificação verifica se existe conectividade IP entre todos os hosts ESXi no cluster vSAN que têm o vMotion configurado. Cada host ESXi na rede do vMotion efetua ping em todos os outros hosts ESXi.
- Todos os hosts têm um vSAN vmknic configurado. Essa verificação garante que cada host ESXi no cluster vSAN tenha uma NIC VMkernel configurada para o tráfego vSAN.
- Todos os hosts têm configurações de multicast correspondentes. Essa verificação garante que cada host tenha um endereço de multicast configurado corretamente.
- Todos os hosts têm sub-redes correspondentes (All hosts have matching subnets). Essa verificação testa se todos os hosts ESXi em um cluster vSAN foram configurados para que todas as vSAN NICs VMkernel estejam na mesma sub-rede IP.
- Hosts desconectados do VC (Hosts disconnected from VC). Essa verificação verifica se o vCenter Server tem uma conexão ativa com todos os hosts ESXi no cluster vSAN.
- Hosts com problemas de conectividade (Hosts with connectivity issues). Essa verificação se refere a situações em que vCenter Server lista o host como conectado, mas as chamadas de API de vCenter para o host estão falhando. Ele pode destacar problemas de conectividade entre um host e o vCenter Server.
- Latência de rede (Network latency). Essa verificação realiza uma verificação de latência de rede de vSAN hosts. Se o limite exceder 100 ms, um aviso será exibido. Se o limite de latência exceder 200 ms e o erro for gerado.
- vMotion: verificações de MTU (ping com tamanho de pacote grande). Essa verificação complementa a verificação básica de conectividade de ping do vMotion. O tamanho máximo da Unidade de Transmissão foi aumentado para melhorar o desempenho da rede. As MTUs configuradas incorretamente podem não aparecer como um problema de configuração de rede, mas podem causar problemas de desempenho.
- vSAN partição de cluster. Essa verificação de integridade examina o cluster para ver quantas partições existem. Ele exibirá um erro se houver mais de uma única partição no cluster vSAN.
- Avaliação de multidifusão com base em outras verificações (Multicast assessment based on other checks). Essa verificação de integridade agrega dados de todas as verificações de integridade da rede. Se essa verificação falhar, isso indica que o multicast provavelmente é a causa raiz de uma partição de rede.
Comandos para verificar a rede
Quando a rede vSAN tiver sido configurada, use esses comandos para verificar seu estado. Você pode verificar qual Adaptador VMkernel (vmknic) é usado para vSAN e quais atributos ele contém.
Use os comandos ESXCLI e RVC para verificar se a rede está totalmente funcional e para solucionar quaisquer problemas de rede com vSAN.
Você pode verificar se o vmknic usado para a rede vSAN está configurado de maneira uniforme e correta em todos os hosts, verificar se o multicast está funcionando e verificar se os hosts que participam do cluster vSAN podem se comunicar com êxito entre si.
lista de redes esxcli vsan
Esse comando permite que você identifique a interface do VMkernel usada pela rede vSAN.
A saída abaixo mostra que a rede vSAN está usando vmk2. Esse comando continua a funcionar mesmo se vSAN tiver sido desativado e os hosts não participarem mais de vSAN.
Também é importante verificar o Multicast do grupo de agentes e o Multicast do grupo mestre.
[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
Isso fornece informações úteis, como qual interface VMkernel está sendo usada para o tráfego vSAN. Nesse caso, é vmk1. No entanto, também são mostrados os endereços multicast. Essas informações podem ser exibidas mesmo quando o cluster está sendo executado no modo unicast. Há o endereço e a porta de multicast do grupo. A porta 23451 é usada para a pulsação, enviada a cada segundo pelo primário, e fica visível em todos os outros hosts do cluster. A porta 12345 é usada para as atualizações do CMMDS entre o primário e o de backup.
lista de interfaces de IP de rede esxcli
Esse comando permite que você verifique itens como vSwitch ou switch distribuído.
Use esse comando para verificar a qual vSwitch ou switch distribuído ele está conectado e o tamanho da MTU, o que pode ser útil se os quadros jumbo tiverem sido configurados no ambiente. Nesse caso, o MTU está no padrão 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
O tamanho máximo da unidade de transmissão é mostrado como 9.000, portanto, essa porta VMkernel é configurada para quadros jumbo, que exigem um MTU de cerca de 9.000. VMware não faz nenhuma recomendação sobre o uso de quadros jumbo. No entanto, os quadros jumbo são suportados para uso com vSAN.
esxcli network ip interface ipv4 get –i vmk2
Esse comando exibe informações como endereço IP e máscara de rede da interface vSAN VMkernal.
Com essas informações, um administrador agora pode começar a usar outros comandos disponíveis na linha de comando para verificar se a rede vSAN está funcionando corretamente.
[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
O comando vmkping verifica se todos os outros hosts ESXi na rede estão respondendo às suas solicitações 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
Embora não verifique a funcionalidade de multicast, ele pode ajudar a identificar um host ESXi não autorizado que tenha problemas de rede. Você também pode examinar os tempos de resposta para ver se há alguma latência anormal na rede vSAN.
Se os jumbo-frames estiverem configurados, esse comando não relatará nenhum problema se o tamanho da MTU do jumbo-frame estiver incorreto. Por padrão, esse comando usa um tamanho de MTU de 1500. Se houver a necessidade de verificar se os quadros jumbo estão funcionando com êxito de ponta a ponta, use vmkping com uma opção de tamanho de pacote (-s) maior da seguinte maneira:
~ # 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 ~ #
Considere adicionar -d ao comando vmkping para testar se os pacotes podem ser enviados sem fragmentação.
lista de vizinhos de ip de rede esxcli
Esse comando ajuda a verificar se todos os hosts vSAN estão no mesmo segmento de rede.
Nessa configuração, temos um cluster de quatro hosts, e esse comando retorna as entradas ARP (Protocolo de Resolução de Endereço) dos outros três hosts, incluindo seus endereços IP e seu vmknic (vSAN está configurado para usar vmk1 em todos os hosts no este 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:~]
ping de diagnóstico de rede esxcli
Esse comando verifica se há duplicatas na rede e os tempos de ida e volta.
Para obter ainda mais detalhes sobre a conectividade de rede vSAN entre os vários hosts, o ESXCLI fornece um poderoso comando de diagnóstico de rede. Aqui está um exemplo de uma dessas saídas, em que a interface do VMkernel está em vmk1 e o IP de rede vSAN remoto de outro host na rede é 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
Esse comando do RVC exibe informações da porta de uplink.
Se houver switches que não sejam da Cisco com o Link Layer Discovery Protocol (LLDP) ativado no ambiente, haverá um comando RVC para exibir informações de porta do switch de uplink <-> switch <-> switch. Para obter mais informações sobre o RVC, consulte o RVC Command Guide.
Isso ajuda a determinar quais hosts estão conectados a quais switches quando o cluster vSAN está abrangendo vários switches. Ele pode ajudar a isolar um problema para um switch específico quando apenas um subconjunto dos hosts no cluster é afetado.
> 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 |+---------------+---------------------------+
Isso só está disponível com switches que oferecem suporte a LLDP. Para configurá-lo, faça login no switch e execute o seguinte:
switch# config t Switch(Config)# feature lldp
Para verificar se o LLDP está ativado:
switch(config)#do show running-config lldp
O LLDP opera no modo de envio e recebimento, por padrão. Verifique as configurações das propriedades do vDS se as informações do comutador físico não estiverem sendo descobertas. Por padrão, o vDS é criado com o protocolo de descoberta definido como CDP, Cisco Discovery Protocol. Para resolver isso, defina o protocolo de descoberta como LLDP e defina a operação como ambos (both) no vDS.
Verificando as comunicações multicast
As configurações de multicast podem causar problemas para a implantação vSAN inicial.
Uma das maneiras mais simples de verificar se o multicast está funcionando corretamente em seu ambiente vSAN é usando o comando tcpdump-uw. Esse comando está disponível na linha de comando dos hosts ESXi.
Esse comando tcpdump-uw mostra se o primário está enviando corretamente pacotes multicast (porta e informações de IP) e se todos os outros hosts no cluster estão recebendo-os.
No primário, esse comando mostra os pacotes que estão sendo enviados para o endereço de multicast. Em todos os outros hosts, os mesmos pacotes são visíveis (do primário ao endereço de multicast). Se eles não estiverem visíveis, o multicast não está funcionando corretamente. Execute o comando tcpdump-uw mostrado aqui em qualquer host no cluster, e as pulsações do primário ficarão visíveis. Nesse caso, o primário está no endereço IP 172.32.0.2. O -v para detalhamento é 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
Embora essa saída possa parecer um pouco confusa, basta dizer que a saída mostrada aqui indica que os quatro hosts no cluster estão recebendo uma pulsação do primário. Esse comando tcpdump-uw deve ser executado em cada host para verificar se todos estão recebendo a pulsação. Isso verifica se o primário está enviando as pulsações e todos os outros hosts do cluster estão recebendo-as, o que indica que o multicast está funcionando.
Se alguns dos hosts vSAN não puderem capturar as pulsações de um segundo do primário, o administrador de rede precisará verificar a configuração de multicast de seus comutadores.
Para evitar o irritante ip truncado – 146 bytes ausentes!, use a opção –s0 para o mesmo comando para interromper o truncamento de pacotes:
[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
O comando tcpdump está relacionado à associação IGMP (Internet Group Management Protocol). Os hosts (e dispositivos de rede) usam o IGMP para estabelecer a associação ao grupo de multicast.
Cada host ESXi no cluster vSAN envia relatórios regulares de associação IGMP (Join).
O comando tcpdump mostra relatórios de membro IGMP de um 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)
A saída mostra que os relatórios IGMP v3 estão ocorrendo, indicando que o host ESXi está atualizando regularmente sua associação. Se um administrador de rede tiver alguma dúvida se os hosts vSAN ESXi estão fazendo o IGMP corretamente ou não, a execução desse comando em cada host ESXi no cluster e a exibição desse rastreamento poderão ser usadas para verificar.
Se você tiver comunicações multicast, use o IGMP v3.
Na verdade, o seguinte comando pode ser usado para examinar o tráfego multicast e IGMP ao mesmo tempo:
[root@esxi-hp-02:~] tcpdump-uw -i vmk2 multicast or igmp -v -s0
Um problema comum é que o cluster vSAN está configurado em vários comutadores físicos e, embora o multicast tenha sido habilitado em um comutador, ele não foi habilitado nos comutadores. Nesse caso, o cluster se forma com dois hosts ESXi em uma partição e outro host ESXi (conectado ao outro comutador) não pode ingressar nesse cluster. Em vez disso, ele forma seu próprio cluster vSAN em outra partição. O comando vsan.lldpnetmap visto anteriormente pode ajudá-lo a determinar a configuração da rede e quais hosts estão conectados a qual switch.
Enquanto um cluster vSAN se forma, há indicadores que mostram que o multicast pode ser um problema.
Suponha que a lista de verificação para sub-rede, VLAN, MTU tenha sido seguida e que cada host no cluster possa vmkping todos os outros hosts no cluster.
Se houver um problema de multicast quando o cluster for criado, um sintoma comum é que cada host ESXi forma seu próprio cluster vSAN, sendo ele próprio o principal. Se cada host tiver uma ID de partição de rede exclusiva, esse sintoma sugerirá que não há multicast entre nenhum dos hosts.
No entanto, se houver uma situação em que um subconjunto dos hosts ESXi forma um cluster e outro subconjunto forma outro cluster, e cada um tem partições exclusivas com seus próprios hosts primário, de backup e talvez até mesmo de agente, o multicast é habilitado no comutador , mas não entre switches. vSAN mostra os hosts no primeiro comutador físico formando sua própria partição de cluster e os hosts no segundo comutador físico formando sua própria partição de cluster, cada um com seu próprio primário. Se você puder verificar a quais comutadores os hosts no cluster se conectam e os hosts em um cluster estão conectados ao mesmo comutador, provavelmente esse é o problema.
Verificando o desempenho da rede vSAN
Verifique se há largura de banda suficiente entre seus hosts ESXi. Essa ferramenta pode ajudá-lo a testar se sua rede vSAN está funcionando de maneira ideal.
Para verificar o desempenho da rede vSAN, você pode usar a ferramenta iperf para medir a largura de banda e a latência máximas do TCP. Ele está localizado em /usr/lib/vmware/vsan/bin/iperf.copy. Execute-o com -–help para ver as várias opções. Use essa ferramenta para verificar a largura de banda e a latência da rede entre os hosts ESXi que participam de um cluster vSAN.
VMware KB 2001003 pode ajudar na configuração e no teste.
Isso é mais útil quando um cluster vSAN está sendo comissionado. A execução de testes do iperf na rede vSAN quando o cluster já está em produção pode afetar o desempenho das máquinas virtuais em execução no cluster.
Verificando os limites de rede do vSAN
O comando vsan.check.limits verifica se nenhum dos limites vSAN está sendo violado.
> 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>>
Do ponto de vista da rede, são as associações RDT (Assocs) e a contagem de soquetes que são importantes. Há 45.000 associações por host no vSAN 6.0 e posterior. Uma associação RDT é usada para rastrear o estado da rede peer-to-peer em vSAN. vSAN é dimensionado para que nunca fique sem associações RDT. vSAN também limita quantos soquetes TCP ele tem permissão para usar, e vSAN é dimensionado para que nunca fique sem sua alocação de soquetes TCP. Há um limite de 10.000 soquetes por host.
Um vSAN cliente (client) representa o acesso do objeto no cluster vSAN. O cliente normalmente representa uma máquina virtual em execução em um host. O cliente e o objeto podem não estar no mesmo host. Não há limite definido, mas essa métrica é mostrada para ajudar a entender como os clientes se equilibram entre os hosts.
Há apenas um vSAN proprietário (owner) para um determinado objeto vSAN, normalmente co-localizado com o cliente vSAN que está acessando esse objeto. Os proprietários de vSAN coordenam todo o acesso ao objeto vSAN e implementam funcionalidades, como espelhamento e distribuição. Não há limite definido, mas essa métrica é mostrada novamente para ajudar a entender como os proprietários se equilibram entre os hosts.
