PowerStore: встроенный узел ESXi не может представить конечные точки протокола в 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

Если максимальный передаваемый блок данных (MTU), настроенный на коммутаторах Ethernet, не равен или превышает размер MTU, настроенного в сети управления PowerStore, это может привести к периодическим проблемам управления.
В данном конкретном примере сбой подключения PowerStore X VASA происходит только для одного из встроенных хостов ESXi (хост, установленный на узле B)
 

 

SLN322011_ru__1icon Если включены пакеты крупных кадров (обычно размер MTU составляет 9000 байт), их необходимо задать последовательно и в подходящем формате. Неправильная настройка пакетов крупных кадров может привести к сбоям соединения или снижению производительности ввода-вывода.

  
 

Содержание

  1. Проблема
  2. Решение
 

1. Проблема

Эти ошибки подключения обнаружены в файле /var/Log/vvold.log на затронутом хосте 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
 

 
Это другой пример из журнала, приведенного ниже, из другой системы. Следующий журнал — это ошибка сертификата, которая является совершенно другой проблемой. Однако в приведенном выше примере это ошибка подключения, хотя большие части журнала идентичны.

  
Вот ошибки сертификатов, обнаруженные в /var/Log/vvold.log на другом хосте ESXi, для другой проблемы:

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_ru__1icon Убедитесь, что ошибка в vvold.log выглядит так: err=Connection timed out а не так:err=SSL Exception. Если ошибка является исключением SSL, следуйте инструкциям в статье VMware KB 67744.

  
 

SLN322011_ru__1icon При тестировании соединения с крупными файлами необходимо вычесть размер заголовка ICMP (8 байт) и минимальный размер заголовка IP (20 байт). 9000 - 28 = 8972. Эти 2 заголовка будут добавлены автоматически, увеличивая размер кадра.

  
 

Проверка подключения с хоста ESXi не выполняется для некоторых путей. В примере ниже показано тестирование подключения одного встроенного хоста ESXi на узле B к другому встроенному хосту на узле 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_ru__1icon Эти проверки с командой ping были запущены из сеанса ssh на хостах ESXi. Дополнительные сведения о vmkping см. в статье VMware KB 1003728.

  
 

Однако при повторном тестировании со стандартным размером полезной нагрузки запросы с командой pig успешно выполняются (если заменить -s 8972 на -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_ru__1icon Похоже, что не удается отправить запрос ping через агрегированный канал VLTi. Успех или сбой ping-запросов в приведенных выше примерах зависит от выбранного исходного интерфейса, поскольку каждый исходный интерфейс подключен к отдельному коммутатору.

  
 

2. Решение

 

SLN322011_ru__1icon На коммутаторе Dell Networking OS10 или OS9 MTU всех интерфейсов, подключенных к PowerStore, должно быть установлено в значение 9216. Неправильная конфигурация приведет к этой проблеме.

  
 

SLN322011_ru__1icon В версиях OS10 до 10.5.0 (август 2019 г.) существует проблема, при которой агрегированный канал VLTi 1000 не передает кадры с MTU больше 1500 без фрагментации. Предполагается, что по умолчанию VLTi должен передавать кадры с MTU до 9216.

  
 

Чтобы проверить через интерфейс командной строки коммутатора OS10, можно ли передать определенный MTU, команда будет выглядеть так:ping -M do -s 8972 aaa.bbb.ccc.ddd -c 3. Пример:
  
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#

 

  • Документ с кратким описанием решения -s этот параметр используется для определения размера полезной нагрузки для кадра.
  • В приведенном выше выводе происходит сбой при отправке кадра с полезной нагрузкой 8972, которая соответствует MTU 9000.
  • После этого отправляется полезная нагрузка 2472, соответствующая 2500 MTU, и также происходит сбой.
  • Наконец, отправка полезной нагрузки 1472, соответствующей 1500 MTU, выполняется успешно.
  • В этом случае было подтверждено, что сетевой путь не может принять кадр, превышающий 1500 MTU.
  • В данном конкретном примере проблема заключалась в агрегированном канале VLTi 1000 между 2 x S4148U-ON из-за ранее описанного дефекта OS10.
 

 

SLN322011_ru__1icon После устранения несоответствия MTU и повторного сканирования ресурса хранения на хосте ESXi все конечные точки протокола отображаются должным образом.

 



 

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.