PowerStore: Eingebetteter ESXi-Node kann keine Protokoll-Endpunkte auf PowerStore X anzeigen

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

Wenn die Maximum Transmission Unit (MTU), die auf Ethernet-Switches konfiguriert wurde, nicht gleich oder größer als die im PowerStore-Managementnetzwerk konfigurierte MTU ist, kann dies zu gelegentlichen Managementproblemen führen.
In diesem speziellen Beispiel schlägt die Verbindung von PowerStore X VASA nur für einen der eingebetteten ESXi-Hosts fehl (Host, der auf Node B installiert ist).
 

 

SLN322011_de__1icon Wenn Jumbo Frames (in der Regel mit einer MTU-Größe von 9000 Byte) aktiviert sind, müssen sie konsistent für alle Endpunkte festgelegt werden. Falsch konfigurierte Jumbo Frames können zu Verbindungsfehlern oder einer niedrigeren E/A-Performance führen.

  
 

Inhaltsverzeichnis

  1. Problem
  2. Lösung
 

1. Problem

Diese Verbindungsfehler werden im /var/log/vvold.log auf dem betroffenen ESXi-Host angezeigt:
  
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
 

 
Dies ist ein anderes Beispiel als die nachfolgende Protokolldatei eines anderen Systems. Das folgende Protokoll ist ein Zertifikatsfehler, was ein komplett anderes Problem darstellt. Im obigen Beispiel handelt es sich jedoch um einen Verbindungsfehler, obwohl große Teile des Protokolls identisch sind.

  
Diese Zertifikatsfehler werden im /var/log/vvold.log auf einem anderen ESXi-Host für ein anderes Problem angezeigt:

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_de__1icon Stellen Sie sicher, dass der Fehler in vvold.log lautet err=Connection timed out und nichterr=SSL Exception. Wenn der Fehler SSL Exception lautet, befolgen Sie stattdessen VMware KB 67744.

  
 

SLN322011_de__1icon Beim Testen der Konnektivität mit Jumbo Frames subtrahieren Sie den ICMP-Header mit 8 Byte und die IP-Header-Mindestgröße von 20 Byte. 9000 - 28 = 8972. Diese zwei Header werden automatisch hinzugefügt und erhöhen die Frame-Größe.

  
 

Die Überprüfung der Konnektivität vom ESXi-Host schlägt für einige Pfade fehl. Im folgenden Beispiel wird die Verbindung von einem eingebetteten ESXi-Host auf Node B zu dem anderen eingebetteten Host auf Node A getestet: 
  
[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_de__1icon Diese Ping-Tests wurden von einer SSH-Sitzung an die ESXi-Hosts durchgeführt. Weitere Informationen zu vmkping finden Sie unter VMware KB 1003728.

  
 

Bei einem erneuten Test mit einer standardmäßigen Payload-Größe sind die Pings jedoch erfolgreich (Änderung von -s 8972 auf -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_de__1icon Es sieht so aus, als könnte kein Ping über den VLTi-Anschlusskanal durchgeführt werden. Ob die Pings in den obigen Beispielen erfolgreich sind oder nicht, hängt von der ausgewählten Quellschnittstelle ab, da jede Quellschnittstelle mit einem anderen Switch verbunden ist.

  
 

2. Lösung

 

SLN322011_de__1icon Auf einem Dell Networking OS10- oder OS9-Switch sollte die MTU aller Schnittstellen, die mit PowerStore verbunden sind, auf 9216 festgelegt werden. Eine Fehlkonfiguration führt zu diesem Problem.

  
 

SLN322011_de__1icon In OS10-Versionen vor 10.5.0 (August 2019) tritt ein Problem auf, bei dem der Anschlusskanal 1000 der VLTi-Schnittstelle keine Frames mit einer MTU größer als 1500 ohne Fragmentierung überträgt. Standardmäßig sollte die VLTi-Schnittstelle Frames mit einer MTU bis zu 9216 übertragen.

  
 

Um über die CLI eines OS10-Switches zu überprüfen, ob eine bestimmte MTU übertragen werden kann, lautet das Format des Befehlsping -M do -s 8972 aaa.bbb.ccc.ddd -c 3. Zum Beispiel:
  
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#

 

  • Die -s Switch wird zum Definieren der Payload-Größe für den Frame verwendet.
  • In der obigen Ausgabe schlägt das Senden eines Frames mit einer Payload von 8972, die einer MTU von 9000 entspricht, fehl.
  • Danach wird eine Payload von 2472, entsprechend einer MTU von 2500, gesendet, die auch fehlschlägt.
  • Schließlich ist eine Payload von 1472, entsprechend einer MTU von 1500, erfolgreich.
  • In diesem Fall wurde bestätigt, dass der Netzwerkpfad keinen Frame annehmen konnte, der größer als eine MTU von 1500 ist.
  • In diesem speziellen Beispiel war das Problem der VLTi-Anschlusskanal 1000 zwischen 2 x S4148U-ON aufgrund des zuvor beschriebenen OS10-Fehlers.
 

 

SLN322011_de__1icon Nachdem die MTU angepasst und der Storage auf dem ESXi-Host erneut gescannt wurde, werden alle Protokoll-Endpunkte wie erwartet angezeigt.

 



 

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.