PowerStore : le nœud ESXi intégré ne peut pas présenter de points de terminaison de protocole sur 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
Lorsque l’unité de transmission maximale (MTU) configurée sur les commutateurs Ethernet n’est pas supérieure ou égale à la valeur de MTU configurée sur le réseau de gestion PowerStore, vous pouvez rencontrer des problèmes de gestion par intermittence.
Dans cet exemple spécifique, la perte de connectivité PowerStore X VASA est observée uniquement pour l’un des hôtes ESXi intégrés (c’est-à-dire l’hôte installé sur le nœud B).
Lorsque les trames Jumbo (généralement avec une taille de MTU de 9 000 octets) sont activées, elles doivent être définies de bout en bout de manière cohérente. Des trames Jumbo mal configurées peuvent entraîner des échecs de connexion ou un ralentissement des performances d’E/S.
Vérifiez que le fichier vvold.log indique l’erreur suivante : err=Connection timed out et nonerr=SSL Exception. Si l’erreur est « SSL Exception », suivez plutôt l’article 67744 de la base de connaissances VMware.
Lors du test de connectivité avec des trames Jumbo, soustrayez l’en-tête ICMP de 8 octets et la taille d’en-tête IP minimale de 20 octets. 9 000 - 28 = 8 972. Ces 2 en-têtes seront ajoutés automatiquement afin d’augmenter la taille des trames.
Ces tests ping ont été exécutés à partir d’une session SSH sur les hôtes ESXi ; pour plus d’informations sur vmkping, reportez-vous à l’article 1003728 de la base de connaissances VMware.
Il apparaît qu’il n’est pas possible d’envoyer une commande ping à travers le canal de ports VLTi. La réussite ou l’échec des commandes ping dans les exemples ci-dessus dépendent de l’interface source choisie, car chaque interface source est connectée à un commutateur différent.
Sur un commutateur Dell Networking OS10 ou OS9, la MTU de toutes les interfaces qui sont connectées à PowerStore doit être définie sur 9 216. Ce problème est donc lié à une erreur de configuration.
Un problème a été identifié au niveau des commutateurs OS10 à des versions antérieures à 10.5.0 (août 2019), où le canal de ports d’interface VLTi 1000 ne transmet pas les trames avec une MTU supérieure à 1 500 sans fragmentation. Par défaut, le canal VLTi doit transmettre les trames jusqu’à une MTU de 9 216.
Après avoir corrigé le problème de correspondance des MTU et après une nouvelle analyse du stockage sur l’hôte ESXi, tous les points de terminaison du protocole sont visibles comme prévu.
Dans cet exemple spécifique, la perte de connectivité PowerStore X VASA est observée uniquement pour l’un des hôtes ESXi intégrés (c’est-à-dire l’hôte installé sur le nœud B).
Lorsque les trames Jumbo (généralement avec une taille de MTU de 9 000 octets) sont activées, elles doivent être définies de bout en bout de manière cohérente. Des trames Jumbo mal configurées peuvent entraîner des échecs de connexion ou un ralentissement des performances d’E/S.
Sommaire
1. Problème
Ces erreurs de connectivité sont indiquées dans le journal /var/log/vvold.log sur l’hôte ESXi concerné :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
Il s’agit ici d’un autre exemple de log extrait d’un autre système. Le log suivant indique un échec au niveau du certificat, lequel est dû à un problème totalement différent. Toutefois, dans l’exemple ci-dessus, il s’agit d’une erreur de connectivité, même si certaines parties du log sont identiques.
Ces erreurs de certificat indiquées dans /var/log/vvold.log sur un autre hôte ESXi concernent un problème différent :
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
Vérifiez que le fichier vvold.log indique l’erreur suivante : err=Connection timed out et nonerr=SSL Exception. Si l’erreur est « SSL Exception », suivez plutôt l’article 67744 de la base de connaissances VMware.
Lors du test de connectivité avec des trames Jumbo, soustrayez l’en-tête ICMP de 8 octets et la taille d’en-tête IP minimale de 20 octets. 9 000 - 28 = 8 972. Ces 2 en-têtes seront ajoutés automatiquement afin d’augmenter la taille des trames.
[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:~]
Ces tests ping ont été exécutés à partir d’une session SSH sur les hôtes ESXi ; pour plus d’informations sur vmkping, reportez-vous à l’article 1003728 de la base de connaissances 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:~]
Il apparaît qu’il n’est pas possible d’envoyer une commande ping à travers le canal de ports VLTi. La réussite ou l’échec des commandes ping dans les exemples ci-dessus dépendent de l’interface source choisie, car chaque interface source est connectée à un commutateur différent.
2. Solution
Sur un commutateur Dell Networking OS10 ou OS9, la MTU de toutes les interfaces qui sont connectées à PowerStore doit être définie sur 9 216. Ce problème est donc lié à une erreur de configuration.
Un problème a été identifié au niveau des commutateurs OS10 à des versions antérieures à 10.5.0 (août 2019), où le canal de ports d’interface VLTi 1000 ne transmet pas les trames avec une MTU supérieure à 1 500 sans fragmentation. Par défaut, le canal VLTi doit transmettre les trames jusqu’à une MTU de 9 216.
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#
- Le commutateur -s est utilisé pour définir la taille de charge utile pour la trame
- Dans la sortie ci-dessus, on peut voir qu’il n’est pas possible d’envoyer une trame contenant une charge utile de 8 972, qui correspond à une MTU de 9 000.
- Après quoi, l’envoi d’une charge utile de 2 472 (correspondant à une MTU de 2 500) échoue également.
- En revanche, l’opération aboutit avec une charge utile de 1 472 correspondant à une MTU de 1 500.
- Dans ce cas, cela confirme que le chemin d’accès au réseau ne peut pas accepter de trame avec une MTU supérieure à 1 500.
- Dans cet exemple spécifique, le problème se situe au niveau du canal de ports VLTi entre 2 commutateurs S4148U-ON, en raison du défaut lié à OS10 décrit précédemment.
Après avoir corrigé le problème de correspondance des MTU et après une nouvelle analyse du stockage sur l’hôte ESXi, tous les points de terminaison du protocole sont visibles comme prévu.
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.