PowerStore: Inbäddad ESXi-nod kan inte visa några protokollslutpunkter 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.

Symptoms

När den maximala överföringsenheten (MTU) som konfigurerats på ethernetswitchar inte är lika med eller större än den MTU som konfigurerats i PowerStore-hanteringsnätverket kan det orsaka återkommande hanteringsproblem.
I det här specifika exemplet misslyckas PowerStore X VASA-anslutningen endast för en av de inbäddade ESXi-värdarna (värden som är installerad på nod B)
 

 

SLN322011_sv__1icon När jumboramar (vanligtvis en MTU-storlek på 9 000 byte) är aktiverade måste de konsekvent ställas in från ände till ände. Felkonfigurerade jumboramar kan resultera i anslutningsfel eller försämrade IO-prestanda.

  
 

Innehållsförteckning

  1. Problem
  2. Lösning
 

1. Problem

Dessa anslutningsfel observeras i /var/log/vvold.log på den berörda ESXi-värden:
 
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
 

 
Det här är ett annat exempel från loggen nedan från ett annat system. Följande logg är ett certifikatfel som är ett helt annat problem. I exemplet ovan är det dock ett anslutningsfel även om stora delar av loggen är identiska.

  
Dessa certifikatfel observeras i /var/log/vvold.log på en annan ESXi-värd för ett annat 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_sv__1icon Kontrollera att felet i vvold.log är err=Connection timed out och inteerr=SSL Exception. Om felet är SSL Exception följer du istället VMware KB 67744.

  
 

SLN322011_sv__1icon När du testar anslutningen med jumboramar subtraherar du ICMP-huvudet på 8 byte och den minsta IP-huvudstorleken på 20 byte. 9 000 – 28 = 8 972. Dessa två huvuden läggs till automatiskt och ökar ramstorleken.

  
 

Kontrollen av anslutningen från ESXi-värden misslyckas för vissa sökvägar. I exemplet nedan testas anslutningen från en inbäddad ESXi-värd på nod B till den andra inbyggda värden på nod 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_sv__1icon Pingtesterna kördes från en ssh-session till ESXi-värdarna, se VMware KB 1003728 för mer information om vmkping.

  
 

Vid testning igen med en standardstorlek på nyttolasten fungerar pingarna (vid ändring av -s 8 972 till -s 1 472):
 
[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_sv__1icon Det verkar som att det inte går att pinga över VLTi-portkanalen. Om pingarna fungerar eller inte i exemplen ovan beror på vilket källgränssnitt som väljs, eftersom varje källgränssnitt är anslutet till olika switchar.

  
 


2. Lösning

 

SLN322011_sv__1icon På en Dell Networking OS10- eller OS9-switch ska MTU för alla gränssnitt som är anslutna till PowerStore ställas in på 9 216. Felaktig konfiguration leder till det här problemet.

  
 

SLN322011_sv__1icon Det finns ett problem i OS10-versioner före 10.5.0 (augusti 2019) där VLTi-gränssnittets portkanal 1 000 inte skickar ramar med en MTU som är större än 1 500 utan fragmentering. Som standard förväntas att VLTi ska skicka ramar upp till 9 216 MTU.

  
 

För att kunna verifiera från CLI på en OS10-switch, och om vi kan skicka en viss MTU, är formatet på kommandotping -M do -s 8972 aaa.bbb.ccc.ddd -c 3. Exempel:
 
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#

 

  • Informationen -s -parametern används för att definiera nyttolaststorleken för ramen
  • I ovanstående utskrift skickas en ram med en nyttolast på 8 972, vilket motsvarar en MTU på 9 000 som misslyckas.
  • Efter detta skickas en nyttolast på 2 472, motsvarande 2 500 MTU som också misslyckas
  • Slutligen skickas en nyttolast på 1 472 som motsvarar 1 500 MTU som lyckas
  • I det här fallet bekräftades att nätverkssökvägen inte kunde ta emot en ram som är större än 1 500 MTU
  • I det här specifika exemplet var problemet VLTi-portkanalen 1 000 mellan 2 x S4148U-ON på grund av OS10-defekten som beskrevs tidigare.
 

 

SLN322011_sv__1icon Efter att ha korrigerat MTU-felmatchningen och skannat om lagringen på ESXi-värden kan vi se alla protokollslutpunkter som förväntat.

 



 

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.