PowerStore: il nodo ESXi incorporato non è in grado di presentare endpoint di protocollo in 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
Se la MTU (Maximum Transmission Unit) configurata sugli switch Ethernet non è uguale o maggiore della MTU configurata sulla rete di gestione PowerStore, può determinare problemi di gestione intermittenti.
In questo esempio specifico, la connettività VASA di PowerStore X ha esito negativo solo per uno degli host ESXi incorporati (host installati sul nodo B)
Quando i frame jumbo (in genere con dimensioni MTU di 9000 byte) sono abilitati, devono essere impostati in modo coerente a livello end-to-end. I frame jumbo non configurati correttamente potrebbero causare errori di connessione o ridurre le prestazioni di IO.
Verificare che l'errore in vvold.log sia err=Connection timed out e nonerr=SSL Exception. Se l'errore è SSL Exception, seguire l'articolo della KB 67744 di VMware.
Quando si esegue un test di connettività con frame jumbo, sottrarre l'intestazione ICMP di 8 byte e la dimensione minima dell'intestazione IP di 20 byte. 9000 - 28 = 8972. Queste 2 intestazioni verranno aggiunte automaticamente aumentando le dimensioni dei frame.
Questi test di ping sono stati eseguiti da una sessione ssh agli host ESXi. Per ulteriori informazioni su vmkping, vedere l'articolo della KB 1003728 di VMware.
Sembra che non sia possibile eseguire il ping sul port-channel dell'interfaccia VLTi. Il fatto che i test di ping riescano o meno negli esempi riportati in precedenza dipende dall'interfaccia di origine scelta, in quanto ogni interfaccia di origine è connessa a uno switch diverso.
Su uno switch Dell Networking OS10 o OS9, la MTU di tutte le interfacce connesse a PowerStore deve essere impostata su 9216. Una configurazione errata genererà questo problema.
Nelle versioni precedenti a 10.5.0 di OS10 (agosto 2019) sussiste un problema in cui il port-channel 1000 dell'interfaccia VLTi non passa i frame con una MTU maggiore di 1500 senza frammentazione. Per impostazione predefinita, l'interfaccia VLTi deve passare i frame con MTU fino a 9216.
Dopo aver corretto la mancata corrispondenza di MTU e rianalizzato lo storage sull'host ESXi, tutti gli endpoint del protocollo verranno visualizzati come previsto.
In questo esempio specifico, la connettività VASA di PowerStore X ha esito negativo solo per uno degli host ESXi incorporati (host installati sul nodo B)
Quando i frame jumbo (in genere con dimensioni MTU di 9000 byte) sono abilitati, devono essere impostati in modo coerente a livello end-to-end. I frame jumbo non configurati correttamente potrebbero causare errori di connessione o ridurre le prestazioni di IO.
Sommario
1. Problema
Questi errori di connettività vengono osservati in /var/log/vvold.log nell'host ESXi interessato: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
Si tratta di un esempio diverso rispetto al log riportato di seguito di un altro sistema. Il seguente registro indica un errore di certificato, un problema completamente diverso. Tuttavia, nell'esempio precedente si tratta di un errore di connettività anche se gran parte del registro è identica in entrambi i casi.
Questi sono errori di certificato osservati in/var/log/vvold.log su un host ESXi diverso per un problema diverso:
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
Verificare che l'errore in vvold.log sia err=Connection timed out e nonerr=SSL Exception. Se l'errore è SSL Exception, seguire l'articolo della KB 67744 di VMware.
Quando si esegue un test di connettività con frame jumbo, sottrarre l'intestazione ICMP di 8 byte e la dimensione minima dell'intestazione IP di 20 byte. 9000 - 28 = 8972. Queste 2 intestazioni verranno aggiunte automaticamente aumentando le dimensioni dei frame.
[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:~]
Questi test di ping sono stati eseguiti da una sessione ssh agli host ESXi. Per ulteriori informazioni su vmkping, vedere l'articolo della KB 1003728 di VMware.
[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:~]
Sembra che non sia possibile eseguire il ping sul port-channel dell'interfaccia VLTi. Il fatto che i test di ping riescano o meno negli esempi riportati in precedenza dipende dall'interfaccia di origine scelta, in quanto ogni interfaccia di origine è connessa a uno switch diverso.
2. Soluzione
Su uno switch Dell Networking OS10 o OS9, la MTU di tutte le interfacce connesse a PowerStore deve essere impostata su 9216. Una configurazione errata genererà questo problema.
Nelle versioni precedenti a 10.5.0 di OS10 (agosto 2019) sussiste un problema in cui il port-channel 1000 dell'interfaccia VLTi non passa i frame con una MTU maggiore di 1500 senza frammentazione. Per impostazione predefinita, l'interfaccia VLTi deve passare i frame con MTU fino a 9216.
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#
- L'opzione -s consente di definire le dimensioni di payload per il frame
- Nell'output precedente, l'invio di un frame con un payload di 8972 che corrisponde a una MTU di 9000 non riesce.
- Successivamente viene inviato un payload di 2472 che corrisponde a una MTU di 2500, anch'esso con esito negativo
- Infine, un payload di 1472 che corrisponde a una MTU di 1500 ha esito positivo
- In questo caso, è stato confermato che il percorso di rete non ha potuto accettare un frame con MTU maggiore di 1500
- In questo esempio specifico, il problema è dovuto al port-channel 1000 dell'interfaccia VLTi tra 2 S4148U-ON a causa del difetto OS10 descritto in precedenza.
Dopo aver corretto la mancata corrispondenza di MTU e rianalizzato lo storage sull'host ESXi, tutti gli endpoint del protocollo verranno visualizzati come previsto.
Affected Products
PowerStoreArticle 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.