PowerStore: Integrovanému uzlu ESXi se v zařízení PowerStore X nedaří prezentovat žádné koncové body protokolu

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

Pokud jednotka MTU (Maximum Transmission Unit) nakonfigurovaná na přepínačích sítě Ethernet není rovna nebo větší než jednotka MTU nakonfigurovaná v síti správy zařízení PowerStore, může docházet k občasným problémům se správou.
V tomto konkrétním příkladu selže připojení zařízení PowerStore X VASA k jednomu z integrovaných hostitelů ESXi (hostitel nainstalovaný na uzlu B).
 

 

SLN322011_cs__1icon Pokud jsou povoleny rámce typu jumbo (obvykle jednotky MTU o velikosti 9 000 bajtů), musí být nastaveny konzistentně. Nesprávně nakonfigurované rámce typu jumbo mohou způsobit selhání připojení nebo snížení výkonu IO.

  
 

Obsah

  1. Problém
  2. Řešení
 

1. Problém

Tyto chyby připojení jsou patrné v protokolu /var/log/vvold.log v dotčeném hostiteli 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
 

 
Toto je jiný příklad z níže uvedeného protokolu z jiného systému. Následující protokol je způsoben závadou certifikátu, což je zcela jiný problém. Ve výše uvedeném příkladu se však jedná o chybu připojení, i když jsou velké části protokolu identické.

  
Chyby certifikátu pozorované v protokolu /var/log/vvold.log na jiném hostiteli ESXi, které představují jiný problém:

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_cs__1icon Zkontrolujte, zda je v protokolu vvold.log přítomna chyba err=Connection timed out, a nikolierr=SSL Exception. Pokud se jedná o chybu SSL Exception, postupujte podle článku databáze znalostí 67744 VMware.

  
 

SLN322011_cs__1icon Při testování připojení s rámci typu jumbo odečtěte velikost 8 bajtů hlavičky ICMP a minimální velikost velikost 20 bajtů hlavičky IP adresy. 9000 − 28 = 8972. Tyto 2 hlavičky se přidají automaticky a zvýší velikost rámce.

  
 

Kontrola připojení z hostitele ESXi se u některých cest nezdaří. V níže uvedeném příkladu otestujte připojení mezi jedním integrovaným hostitelem ESXi v uzlu B a druhým integrovaným hostitelem v uzlu 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_cs__1icon Tyto testy ping byly spuštěny z relace ssh na hostitele ESXi. Další informace o příkazu vmkping najdete v článku databáze znalostí 1003728 systému VMware.

  
 

Při opětovném testování se standardní velikostí datové části jsou však příkazy ping provedeny úspěšně (změna -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_cs__1icon Zdá se, že nemůžeme provést příkaz ping napříč kanálem portu VLTi. Zda provedení příkazů ping ve výše uvedených příkladech uspěje nebo ne, závisí na zvoleném zdrojovém rozhraní, protože každé zdrojové rozhraní je připojeno k jinému přepínači.

  
 

2. Řešení

 

SLN322011_cs__1icon U přepínače Dell Networking OS10 nebo OS9 by měla být jednotka MTU všech rozhraní připojených k zařízení PowerStore nastavena na 9216. Tento problém způsobuje nesprávná konfigurace.

  
 

SLN322011_cs__1icon Ve verzích přepínače OS10 starších než 10.5.0 (ze srpna 2019) došlo k problému, při kterém kanál portu 1000 rozhraní VLTi nepředá bez fragmentace rámce s jednotkou MTU větší než 1 500. Očekává se, že ve výchozím nastavení rozhraní VLTi předá rámce až do velikosti 9216 MTU.

  
 

Pokud chcete ověřit hodnotu z příkazového řádku přepínače OS10 a můžete předat určitou jednotku MTU, je formát příkazuping -M do -s 8972 aaa.bbb.ccc.ddd -c 3. Například:
  
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#

 

  • Přepínač -s se používá k definování velikosti datové části pro rámec.
  • Ve výše uvedeném výstupu se odeslání rámce s datovou částí 8972, která by odpovídala 9000 MTU, nezdaří.
  • Poté se datová část 2472 odpovídající 2500 MTU odešle, což také selže.
  • Nakonec je datová část 1472 odpovídající 1500 MTU úspěšná.
  • V tomto případě bylo potvrzeno, že síťová cesta nemůže přijmout rámec větší než 1500 MTU.
  • V tomto konkrétním příkladu nastal problém s kanálem portu 1000 rozhraní VLTi mezi 2 x S4148U-ON kvůli dříve popsané závadě přepínače OS10.
 

 

SLN322011_cs__1icon Po opravě neshody jednotek MTU a opětovném skenování úložiště v hostiteli ESXi se podle očekávání zobrazí veškeré koncové body protokolu.

 



 

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.