PowerStore: wbudowany węzeł ESXi nie może prezentować żadnych punktów końcowych protokołu w pamięci masowej 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

Kiedy parametr MTU (Maximum Transmission Unit) skonfigurowany na przełącznikach Ethernet nie jest równy lub większy niż parametr MTU skonfigurowany w sieci zarządzania PowerStore, może to spowodować przejściowe problemy z zarządzaniem.
W tym konkretnym przykładzie połączenie PowerStore X VASA nie powiodło się tylko z jednym z wbudowanych hostów ESXi (host zainstalowany na węźle B)
 

 

SLN322011_pl__1icon Kiedy ramki Jumbo Frame (zazwyczaj rozmiar MTU to 9000 bajtów) są włączone, muszą być ustawione kompleksowo na stałe. Nieprawidłowo skonfigurowane ramki Jumbo Frame mogą skutkować awarią połączenia lub zmniejszoną wydajnością we/wy.

  
 

Spis treści

  1. Problem
  2. Rozwiązanie
 

1. Problem

Te błędy połączenia można zaobserwować w pliku /var/log/vvold.log na hoście ESXi:
  
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
 

 
Poniżej znajduje się inny przykład z dziennika z innego systemu. Poniższy wpis dziennika to awaria certyfikatu, która jest zupełnie odmiennym problemem. Jednak w powyższym przykładzie jest to błąd połączenia, chociaż duże części dziennika są identyczne.

  
Te błędy certyfikatów zaobserwowane w pliku /var/log/vvold.log na innym hoście ESXi dla innego problemu:

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_pl__1icon Upewnij się, że błąd w pliku vvold.log to err=Connection timed out a nieerr=SSL Exception. Jeśli błąd dotyczy wyjątku SSL, należy postępować zgodnie z artykułem KB 67744 firmy VMware.

  
 

SLN322011_pl__1icon Podczas testowania łączności z ramkami Jumbo Frame odejmij nagłówek ICMP 8 bajtów i minimalny rozmiar nagłówka IP 20 bajtów. 9000 - 28 = 8972. Zostaną automatycznie dodane te 2 nagłówki, zwiększając rozmiar ramki.

  
 

Sprawdzanie połączenia z hosta ESXi nie powiodło się w przypadku niektórych ścieżek. W poniższym przykładzie wykonywany jest test łączności z jednego wbudowanego hosta ESXi na węźle B do drugiego osadzonego hosta na węźle 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_pl__1icon Te testy ping zostały wykonywane z sesji SSH na hostach ESXi, patrz artykuł KB 1003728 firmy VMware, aby uzyskać więcej informacji na temat polecenia vmkping.

  
 

Jeśli jednak test zostanie ponowiony przy użyciu standardowego rozmiaru obciążenia, polecenia ping powiodą się (zmiana -s 8972 na -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_pl__1icon Wygląda na to, że nie można wykonać polecenia ping przez kanał portu VLTi. To, czy polecenia ping zakończą się pomyślnie w powyższych przykładach, zależy od wybranego interfejsu źródłowego, ponieważ każdy z interfejsów źródłowych jest podłączony do innego przełącznika.

  
 

2. Rozwiązanie

 

SLN322011_pl__1icon Na przełączniku Dell Networking OS10 lub OS9 jednostka MTU ze wszystkich interfejsów podłączonych do PowerStore powinna mieć wartość 9216. Wystąpi błąd konfiguracji.

  
 

SLN322011_pl__1icon Istnieje problem w wersjach OS10 wcześniejszych niż 10.5.0 (sierpień 2019 r.), w których kanał portu interfejsu VLTi 1000 nie przekazuje ramek o jednostce MTU większej niż 1500 bez fragmentacji. Oczekuje się, że domyślnie VLTi powinien przekazywać ramki o MTU do 9216.

  
 

Aby sprawdzić, czy z wiersza poleceń przełącznika OS10 można przekazać określoną jednostkę MTU, użyj polecenia w formacieping -M do -s 8972 aaa.bbb.ccc.ddd -c 3. Na przykład:
  
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#

 

  • Lampka -s Przełącznik służy do określenia rozmiaru obciążenia dla ramki
  • W powyższym wysłanie ramki z obciążeniem 8972, które odpowiada jednostce MTU 9000, kończy się niepowodzeniem.
  • Następnie wysyłane jest obciążenie 2472 odpowiadające 2500 MTU, co także kończy się niepowodzeniem
  • Wreszcie obciążenie 1472 odpowiadające 1500 MTU kończy się powodzeniem
  • W tym przypadku potwierdzono, że ścieżka sieciowa nie może przyjąć ramki większej niż 1500 MTU
  • W tym konkretnym przykładzie wystąpił problem z kanałem portu VLTi 1000 między 2 x S4148U-ON ze względu na wcześniej opisaną wadę OS10.
 

 

SLN322011_pl__1icon Po usunięciu niezgodności MTU i przeprowadzeniu skanowania pamięci masowej na hoście ESXi wszystkie punkty końcowe protokołu są wyświetlane zgodnie z oczekiwaniami.

 



 

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.