PowerStore: En integreret ESXi-node kan ikke vise nogen protokolslutpunkter på 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.
Check out other resources

Symptoms

Når maksimum transmissionsenheden (MTU), der er konfigureret på Ethernet-switcher, ikke er lig med eller større end den MTU, der er konfigureret på PowerStore-administrationsnetværket, kan det medføre uregelmæssige administrationsproblemer.
I dette specifikke eksempel mislykkes PowerStore X VASA-tilslutningen kun for en af de integrerede ESXi-værter (vært, der er installeret på node B)
 

 

SLN322011_da__1icon Når jumborammer (typisk MTU-størrelse på 9000 byte) er aktiveret, skal de indstilles konsekvent fra start til slut. Fejlkonfigurerede jumborammer kan medføre forbindelsesfejl eller mindsket IO-ydeevne.

  
 

Indholdsfortegnelse

  1. Problem
  2. Løsning
 

1. Problem

Disse forbindelsesfejl observeres i /var/log/vvold.log på den berørte ESXi-vært:
  
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
 

 
Dette er et andet eksempel fra logfilen nedenfor fra et andet system. Følgende log er en certifikatfejl, hvilket er et helt andet problem. I ovenstående eksempel er det en forbindelsesfejl, selvom store dele af logfilen er identiske.

  
Disse certifikatfejl observeres i /var/log/vvold.log på anden ESXi-vært for et andet problem:

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
 

  

SLN322011_da__1icon Sørg for, at fejlen i vvold.log er err=Connection timed out og ikkeerr=SSL Exception. Hvis fejlen er SSL Exception, skal du følge VMware KB 67744 i stedet.

  
 

SLN322011_da__1icon Når du tester tilslutninger med jumborammer, skal du trækker 8 byte fra ICMP-headeren og 20 byte fra minimumsstørrelsen på IP-headeren. 9000 - 28 = 8972. Disse to headere tilføjes automatisk med en forøgelse af rammestørrelsen.

  
 

Kontrol af forbindelsen fra ESXi-værten mislykkes for visse stier. I eksemplet nedenfor testes tilslutning fra en integreret ESXi-vært på node B til den anden integrerede vært på node A: 
  
[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:~]

 

  
SLN322011_da__1icon Disse ping-tests blev kørt fra en ssh-session til ESXi-værterne, se VMware KB 1003728 for at få flere oplysninger om vmkping.

  
 

Men ved ny test med en standardmæssig datastørrelse lykkedes pingsignalerne igen (ændring -s 8972 til -s 1472):
  
[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:~]

 

SLN322011_da__1icon Det ser ud til, at vi ikke kan ping på tværs af VLTi port-kanalen. Om pingsignaler lykkes eller ej, afhænger af den kildegrænseflade, der er valgt, da hver enkelt kildegrænseflade er tilsluttet en anden switch.

  
 

2. Løsning

 

SLN322011_da__1icon På en Dell Networking OS10 eller OS9-switch, skal MTU for alle grænseflader, der er forbundet til PowerStore, indstilles til 9216. Fejlkonfiguration vil resultere i dette problem.

  
 

SLN322011_da__1icon Der er et problem i OS10-versioner før 10.5.0 (august 2019), hvor VLTi interface Port-kanal 1000 ikke overfører rammer med en MTU større end 1500 uden fragmentering. Det forventes, at VLTi'en som standard skal overføre rammer op til 9216 MTU.

  
 

For at verificere fra CLI'en til en OS10-switch, om vi kan overføre en bestemt MTU, skal kommandoformatet væreping -M do -s 8972 aaa.bbb.ccc.ddd -c 3. F.eks.:
  
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#

 

  • Ikonet -s switchen bruges til at definere datastørrelsen for rammen
  • I ovenstående output vil det mislykkes at sende en ramme med en datamængde på 8972, som ville svare til en MTU på 9000.
  • Efter dette sendes der en datamængde på 2472 svarende til en 2500 MTU, som også mislykkes.
  • Endelig lykkes en datamængde på 1472 svarende til 1500 MTU
  • I dette tilfælde blev det bekræftet, at netværksstien ikke kunne acceptere en ramme, der er større end 1500 MTU
  • I dette specifikke eksempel var problemet VLTi port-kanal 1000 mellem 2 x S4148U-ON på grund af den tidligere beskrevne OS10-fejl.
 

 

SLN322011_da__1icon Efter rettelse af MTU-uoverensstemmelsen og genscanning af lageret på ESXi-værten, kan vi se alle protokolslutpunkter som forventet.

 



 

Affected Products

PowerStore
Article 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.