PowerStore: o nó do ESXi incorporado não consegue apresentar nenhum endpoint de protocolo no PowerStore X
This article applies to
This article does not apply to
This article is not tied to any specific product.
Not all product versions are identified in this article.
Symptoms
Quando a MTU (Maximum Transmission Unit, Unidade Máxima de Transmissão) configurada em switches Ethernet não for igual ou maior que a MTU configurada na rede de gerenciamento do PowerStore, isso poderá causar problemas intermitentes de gerenciamento.
Nesse exemplo específico, a conectividade VASA do PowerStore X falha somente para um dos hosts do ESXi incorporados (host que está instalado no nó B)
Quando os jumbo frames (geralmente, o tamanho da MTU é de 9000 bytes) forem ativados, eles deverão ser definidos consistentemente de ponta a ponta. Jumbo frames configurados incorretamente podem resultar em falhas de conexão ou redução de desempenho de E/S.
Verifique se o erro em vvold.log é err=Connection timed out e nãoerr=SSL Exception. Se o erro for SSL Exception, siga o artigo KB 67744 da VMware.
Ao testar a conectividade com jumbo frames, subtraia o cabeçalho ICMP de 8 bytes e o tamanho mínimo do cabeçalho IP de 20 bytes. 9000 - 28 = 8972. Esses dois cabeçalhos serão adicionados automaticamente, o que aumentará o tamanho do quadro.
Esses testes de ping foram executados em uma sessão ssh para os hosts do ESXi. Consulte o artigo KB 1003728 da VMware para obter mais informações sobre o vmkping.
Parece que não é possível fazer ping no port-channel do VLTi. Obter sucesso ou não nos pings dos exemplos acima depende da interface de origem escolhida, pois cada uma delas está conectada a um switch diferente.
Em um switch Dell Networking OS10 ou OS9, a MTU de todas as interfaces conectadas ao PowerStore deve ser definida como 9216. A configuração incorreta resultará nesse problema.
Há um problema nas versões do OS10 anteriores à versão 10.5.0 (agosto de 2019), em que o port-channel 1000 da interface do VLTi não passa quadros com uma MTU maior que 1500 sem realizar a fragmentação. Espera-se que, por padrão, o VLTi passe quadros com MTU de até 9216.
Depois de corrigir a disparidade de MTU e verificar novamente o armazenamento no host do ESXi, podemos ver todos os endpoints de protocolo, conforme esperado.
Nesse exemplo específico, a conectividade VASA do PowerStore X falha somente para um dos hosts do ESXi incorporados (host que está instalado no nó B)
Quando os jumbo frames (geralmente, o tamanho da MTU é de 9000 bytes) forem ativados, eles deverão ser definidos consistentemente de ponta a ponta. Jumbo frames configurados incorretamente podem resultar em falhas de conexão ou redução de desempenho de E/S.
Sumário
1. Problema
Esses erros de conectividade são observados em /var/log/vvold.log no host do ESXi afetado:2020-06-24T09:33:08.114Z info vvold[2104948] [Originator@6876 sub=Default] VasaSession::Initialize url is empty 2020-06-24T09:33:08.114Z warning vvold[2104948] [Originator@6876 sub=Default] VasaSession::DoSetContext: Empty VP URL for VP (PowerStore)! 2020-06-24T09:33:08.114Z info vvold[2104948] [Originator@6876 sub=Default] Initialize: Failed to establish connection https://xx.xx.xx.xx:8443/version.xml 2020-06-24T09:33:08.114Z error vvold[2104948] [Originator@6876 sub=Default] Initialize: Unable to init session to VP PowerStore state: 0 2020-06-24T09:33:08.117Z info vvold[2104947] [Originator@6876 sub=Default] VasaSession::GetEndPoint: with url https://xx.xx.xx.xx:8443/version.xml 2020-06-24T09:34:28.895Z warning vvold[2104947] [Originator@6876 sub=Default] VasaSession::GetEndPoint: failed to get endpoint, err=Connection timed out, using default 2020-06-24T09:34:28.896Z info vvold[2104947] [Originator@6876 sub=Default] VasaSession::Initialize url is empty
Este é um exemplo diferente do log abaixo de um sistema diferente. O log a seguir é uma falha de certificado que é um problema totalmente diferente. No entanto, no exemplo acima, há um erro de conectividade mesmo que grande parte do log seja idêntica.
Esses são os erros de certificado observados em /var/log/vvold.log em um host do ESXi diferente para um problema diferente:
2019-12-26T16:57:03.396Z info vvold[2139844] [Originator@6876 sub=Default] VasaSession::GetEndPoint: with url https://xxxxxxxx.com:8443/version.xml 2019-12-26T16:57:03.401Z warning vvold[2139844] [Originator@6876 sub=Default] VasaSession::GetEndPoint: failed to get endpoint, err=SSL Exception: Verification parameters: --> PeerThumbprint: 0B:01:C4:F2:16:E0:10:C9:63:B5:F2:92:D3:36:B5:65:5C:59:DB:17 --> ExpectedThumbprint: --> ExpectedPeerName: xxxxxxxx.com --> The remote host certificate has these problems: --> --> * Host name does not match the subject name(s) in certificate., using default 2019-12-26T16:57:03.401Z info vvold[2139844] [Originator@6876 sub=Default] VasaSession::Initialize url is empty 2019-12-26T16:57:03.401Z warning vvold[2139844] [Originator@6876 sub=Default] VasaSession::DoSetContext: Empty VP URL for VP (xxxxxxxxx)! 2019-12-26T16:57:03.401Z info vvold[2139844] [Originator@6876 sub=Default] Initialize: Failed to establish connection https://xxxxxxxx.com:8443/version.xml 2019-12-26T16:57:03.401Z error vvold[2139844] [Originator@6876 sub=Default] Initialize: Unable to init session to VP xxxxxxxxx state: 0
Verifique se o erro em vvold.log é err=Connection timed out e nãoerr=SSL Exception. Se o erro for SSL Exception, siga o artigo KB 67744 da VMware.
Ao testar a conectividade com jumbo frames, subtraia o cabeçalho ICMP de 8 bytes e o tamanho mínimo do cabeçalho IP de 20 bytes. 9000 - 28 = 8972. Esses dois cabeçalhos serão adicionados automaticamente, o que aumentará o tamanho do quadro.
[root@Powerstore1000X-host-2:~] vmkping -I vmk1 1.2.3.4 -s 8972 -c 2 PING 1.2.3.4 (1.2.3.4): 8972 data bytes 8980 bytes from 1.2.3.4: icmp_seq=0 ttl=64 time=0.327 ms 8980 bytes from 1.2.3.4: icmp_seq=1 ttl=64 time=0.376 ms --- 1.2.3.4 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 0.327/0.352/0.376 ms [root@Powerstore1000X-host-2:~] vmkping -I vmk1 1.2.3.5 -s 8972 -c 2 PING 1.2.3.5 (1.2.3.5): 8972 data bytes --- 1.2.3.5 ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss[root@Powerstore1000X-host-2:~] [root@Powerstore1000X-host-2:~] vmkping -I vmk2 1.2.3.5 -s 8972 -c 2 PING 1.2.3.5 (1.2.3.5): 8972 data bytes 8980 bytes from 1.2.3.5: icmp_seq=0 ttl=64 time=0.303 ms 8980 bytes from 1.2.3.5: icmp_seq=1 ttl=64 time=0.411 ms --- 1.2.3.5 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 0.303/0.357/0.411 ms [root@Powerstore1000X-host-2:~] vmkping -I vmk2 1.2.3.4 -s 8972 -c 2 PING 1.2.3.4 (1.2.3.4): 8972 data bytes --- 1.2.3.4 ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss[root@Powerstore1000X-host-2:~]
Esses testes de ping foram executados em uma sessão ssh para os hosts do ESXi. Consulte o artigo KB 1003728 da VMware para obter mais informações sobre o vmkping.
[root@Powerstore1000X-host-2:~] vmkping -I vmk1 1.2.3.4 -s 8972 -c 2 PING 1.2.3.4 (1.2.3.4): 8972 data bytes 8980 bytes from 1.2.3.4: icmp_seq=0 ttl=64 time=0.327 ms 8980 bytes from 1.2.3.4: icmp_seq=1 ttl=64 time=0.376 ms --- 1.2.3.4 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 0.327/0.352/0.376 ms [root@Powerstore1000X-host-2:~] vmkping -I vmk1 1.2.3.5 -s 8972 -c 2 PING 1.2.3.5 (1.2.3.5): 8972 data bytes --- 1.2.3.5 ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss[root@Powerstore1000X-host-2:~] [root@Powerstore1000X-host-2:~] vmkping -I vmk2 1.2.3.5 -s 8972 -c 2 PING 1.2.3.5 (1.2.3.5): 8972 data bytes 8980 bytes from 1.2.3.5: icmp_seq=0 ttl=64 time=0.303 ms 8980 bytes from 1.2.3.5: icmp_seq=1 ttl=64 time=0.411 ms --- 1.2.3.5 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 0.303/0.357/0.411 ms [root@Powerstore1000X-host-2:~] vmkping -I vmk2 1.2.3.4 -s 8972 -c 2 PING 1.2.3.4 (1.2.3.4): 8972 data bytes --- 1.2.3.4 ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss[root@Powerstore1000X-host-2:~]
Parece que não é possível fazer ping no port-channel do VLTi. Obter sucesso ou não nos pings dos exemplos acima depende da interface de origem escolhida, pois cada uma delas está conectada a um switch diferente.
2. Solução
Em um switch Dell Networking OS10 ou OS9, a MTU de todas as interfaces conectadas ao PowerStore deve ser definida como 9216. A configuração incorreta resultará nesse problema.
Há um problema nas versões do OS10 anteriores à versão 10.5.0 (agosto de 2019), em que o port-channel 1000 da interface do VLTi não passa quadros com uma MTU maior que 1500 sem realizar a fragmentação. Espera-se que, por padrão, o VLTi passe quadros com MTU de até 9216.
SWITCH# ping -M do -s 8972 1.2.3.6 -c 3 PING 1.2.3.6 (1.2.3.6) 8972(9000) bytes of data. ping: local error: Message too long, mtu=1500 ping: local error: Message too long, mtu=1500 ping: local error: Message too long, mtu=1500 --- 1.2.3.6 ping statistics --- 3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2042ms SWITCH# ping -M do -s 2472 1.2.3.6 -c 3 PING 1.2.3.6 (1.2.3.6) 2472(2500) bytes of data. ping: local error: Message too long, mtu=1500 ping: local error: Message too long, mtu=1500 ping: local error: Message too long, mtu=1500 --- 1.2.3.6 ping statistics --- 3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2039ms SWITCH# ping -M do -s 1472 1.2.3.6 -c 3 PING 1.2.3.6 (1.2.3.6) 1472(1500) bytes of data. 1480 bytes from 1.2.3.6: icmp_seq=1 ttl=64 time=1.05 ms 1480 bytes from 1.2.3.6: icmp_seq=2 ttl=64 time=0.966 ms 1480 bytes from 1.2.3.6: icmp_seq=3 ttl=64 time=1.00 ms --- 1.2.3.6 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2001ms rtt min/avg/max/mdev = 0.966/1.008/1.059/0.046 ms SWITCH#
- O switch -s é usado para definir o tamanho do payload para o quadro
- No resultado acima, ocorre falha ao enviar um quadro com um payload de 8972, que corresponde a uma MTU de 9000.
- Depois disso, um payload de 2472, correspondendo a uma MTU de 2500, é enviado e apresenta falha
- Por fim, um payload de 1472, correspondendo a uma MTU de 1500, é bem-sucedido
- Nesse caso, foi confirmado que o caminho de rede não pôde aceitar um quadro maior que uma MTU de 1500
- Nesse exemplo específico, o problema era o port-channel 1000 do VLTi entre 2 x S4148U-ON devido à falha do OS10 descrita anteriormente.
Depois de corrigir a disparidade de MTU e verificar novamente o armazenamento no host do ESXi, podemos ver todos os endpoints de protocolo, conforme esperado.
Affected Products
PowerStoreArticle Properties
Article Number: 000125860
Article Type: Solution
Last Modified: 19 Apr 2021
Version: 5
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.