PowerStore: Innbygd ESXi-node kan ikke presentere noen protokollendepunkter 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

Hvis den maksimale overføringsenheten (MTU) som er konfigurert på Ethernet-svitsjer ikke er lik eller større enn MTU-en som er konfigurert på PowerStore-administrasjonsnettverket, kan det føre til periodiske administrasjonsproblemer.
I dette spesifikke eksemplet mislykkes PowerStore X VASA-tilkoblingen for bare én av de innebygde ESXi-vertene (verten som er installert på node B)
 

 

SLN322011_no__1icon Når jumborammer (vanligvis MTU-størrelse på 9000 byte) er aktivert, må de angis konsekvent fra ende til ende. Feilkonfigurerte jumborammer kan resultere i tilkoblingsfeil eller redusert I/U-ytelse.

  
 

Innholdsfortegnelse

  1. Problem
  2. Løsning
 

1. Problem

Disse tilkoblingsfeilene er observert i /var/log/vvold.log på den berørte ESXi-verten:
  
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 annet eksempel fra loggen nedenfor fra et annet system. Følgende logg er en sertifikatfeil, noe som er helt annet problem. I eksemplet ovenfor er det en tilkoblingsfeil selv om store deler av loggen er identisk.

  
Disse sertifikatfeilene er observert i /var/log/vvold.log på en annen ESXi-vert for et annet 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_no__1icon Kontroller at feilen i vvold.log er err=Connection timed out og ikkeerr=SSL Exception. Hvis feilen er SSL Exception, må du følge VMware KB 67744 i stedet.

  
 

SLN322011_no__1icon Når du tester tilkoblingsmulighet med jumborammer, må du trekke fra ICMP-toppteksten med 8 byte og den minste IP-topptekststørrelsen på 20 byte. 9000 - 28 = 8972. Disse to topptekstene blir lagt til automatisk, noe som øker rammestørrelsen.

  
 

Kontroll av tilkoblingsmulighet fra ESXi-verten mislykkes for enkelte baner. I eksempelet nedenfor testes tilkoblingsmulighet fra én innebygd ESXi-vert på node B til den andre innebygde verten 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_no__1icon Disse ping-testene ble kjørt fra en ssh-økt til ESXi-vertene. Se VMware KB 1003728 for mer informasjon om vmkping.

  
 

Når du tester på nytt med en standard nyttelaststørrelse, lykkes ping-kommandoene (endrer -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_no__1icon Dette ser ut som om vi ikke kan pinge på tvers av VLTi-portkanalen. Hvorvidt pingkommandoene lykkes eller ikke i eksemplene ovenfor, avhenger av det valgte kildegrensesnittet ettersom hvert kildegrensesnitt er koblet til hver sin svitsj.

  
 

2. Løsning

 

SLN322011_no__1icon MTU for alle grensesnitt som er koblet til PowerStore på en Dell Networking OS10- eller OS9-svitsj, bør være angitt til 9216. Feilkonfigurasjon vil føre til dette problemet.

  
 

SLN322011_no__1icon Det er et problem med OS10-versjoner før 10.5.0 (august 2019), der portkanal 1000 for VLTi-grensesnittet ikke godkjenner rammer med en MTU som er større enn 1500, uten fragmentering. Det forventes at VLTi skal godkjenne rammer på opptil 9216 MTU.

  
 

Hvis vil skal kontrollere om vi kan godkjenne en spesifikk MTU fra kommandolinjegrensesnittet til en OS10-bryter, skal kommandoen ha følgende formatping -M do -s 8972 aaa.bbb.ccc.ddd -c 3. Eksempel:
  
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#

 

  • Informasjonen i -s svitsjen brukes til nyttelaststørrelsen for rammen
  • I utdataene ovenfor mislykkes sendingen av en ramme med nyttelast på 8972, som tilsvarer en MTU på 9000.
  • Etter dette vil sending av en nyttelast på 2472, som tilsvarer en 2500 MTU, og mislykkes
  • Til slutt lykkes en nyttelast på 1472, som tilsvarer 1500 MTU
  • I dette tilfellet ble det bekreftet at nettverksbanen ikke kunne godkjenne en ramme som er større enn 1500 MTU
  • I dette spesifikke eksemplet var problemet VLTi-portkanal 1000 mellom 2 x S4148U-ON på grunn av OS10-feilen som ble beskrevet tidligere.
 

 

SLN322011_no__1icon Når vi har rettet opp manglende MTU-samsvar og skannet lagringen på ESXi-verten på nytt, kan vi se alle protokollendepunktene 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.