PowerStore: Yerleşik ESXi düğümü, PowerStore X'te herhangi bir protokol uç noktası sunamıyor

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

Ethernet anahtarlarında yapılandırılan Maksimum İletim Birimi (MTU), PowerStore yönetim ağında yapılandırılan MTU'ya eşit veya bu MTU'dan daha büyük olmadığında zaman zaman yönetim sorunları oluşabilir.
Bu örnekte, PowerStore X VASA bağlantısı yalnızca yerleşik ESXi ana bilgisayarlarından birinde (Düğüm B'ye takılmış ana bilgisayar) başarısız olmaktadır
 

 

SLN322011_tr__1icon Jumbo çerçeveler (tipik olarak 9000 baytlık MTU boyutu) etkinleştirildiğinde bunların tutarlı bir şekilde uçtan uca ayarlanması gerekir. Yanlış yapılandırılmış jumbo çerçeveler, bağlantı hatalarına veya düşük GÇ performansına neden olabilir.

  
 

İçindekiler

  1. Sorun
  2. Çözüm
 

1. Sorun

Bu bağlantı hataları, etkilenen ESXi ana bilgisayarındaki /var/log/vvold.log günlüğünde gözlemlenir:
 
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
 

 
Bu, farklı bir sisteme ait aşağıdaki günlükten alınan başka bir örnektir. Aşağıdaki günlükte, tamamen farklı bir sorun olan sertifika hatası gösterilmektedir. Bununla birlikte yukarıdaki örnekte, günlüğün büyük bölümü tamamen aynı olsa da bir bağlantı hatası gösterilmektedir.

  
Bu sertifika hataları, farklı bir soruna sahip farklı bir ESXi ana bilgisayarının /var/log/vvold.log günlüğünde gözlemlenmiştir:

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_tr__1icon vvold.log günlüğündeki hatanın err=SSL Exception değil,err=Connection timed out şeklinde olduğundan emin olun. Hata SSL Exception (SSL İstisnası) ise VMware KB 67744 makalesindeki adımları izleyin.

  
 

SLN322011_tr__1icon Jumbo çerçevelerde bağlantıyı test ederken 8 baytlık ICMP başlığı ve 20 baytlık minimum IP başlığı boyutunu çıkarın. 9000 - 28 = 8972. Bu 2 başlık otomatik olarak eklenerek çerçeve boyutu artırılır.

  
 

ESXi ana bilgisayarından bağlantı durumu kontrol edildiğinde bazı yolların bağlantısı başarısız olur. Aşağıdaki örnekte, düğüm B'deki bir yerleşik ESXi ana bilgisayardan düğüm A'daki diğer yerleşik ana bilgisayara olan bağlantı test edilmektedir: 
 
[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_tr__1icon Bu ping testleri, bir SSH oturumundan ESXi ana bilgisayarlarına yönelik olarak gerçekleştirilmiştir; vmkping hakkında daha fazla bilgi için VMware KB 1003728 makalesine bakın.

  
 

Ancak standart yük boyutuyla tekrar test edildiğinde ping'ler başarılı olur (-s 8972'yi -s 1472 olarak değiştirerek):
 
[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_tr__1icon Bu, VLTi bağlantı noktası kanalı üzerinden ping işlemi yapamadığımız anlamına geliyor. Her bir kaynak arayüzü farklı bir anahtara bağlı olduğundan yukarıdaki örneklerdeki ping'lerin başarılı olup olmayacağı, seçilen kaynak arayüzüne bağlıdır.

  
 


2. Çözüm

 

SLN322011_tr__1icon Bir Dell Networking OS10 veya OS9 anahtarında, PowerStore'a bağlı tüm arayüzlerin MTU değerinin 9216 olarak ayarlanması gerekir. Bu soruna yanlış yapılandırma neden olmaktadır.

  
 

SLN322011_tr__1icon 10.5.0'dan (Ağustos 2019) önceki OS10 sürümlerinde, VLTi arayüzü Bağlantı Noktası kanalı 1000'in, 1500'den büyük bir MTU'ya sahip çerçeveleri parçalara ayırmadan geçememesi şeklinde bir sorun mevcuttur. VLTi'nin varsayılan olarak 9216 MTU'ya kadar olan çerçeveleri geçmesi beklenir.

  
 

Bir OS10 anahtarının CLI'sini kullanarak belirli bir MTU'nun geçilip geçilemeyeceğini doğrulamaya yönelik komut aşağıdaki biçimdedir:ping -M do -s 8972 aaa.bbb.ccc.ddd -c 3. Örneğin:
 
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 anahtarı, çerçevenin yük boyutunu tanımlamak için kullanılır
  • Yukarıdaki çıktıda, 9000 MTU'ya karşılık gelen 8972 değerinde yüke sahip bir çerçevenin gönderimi başarısız olur.
  • Daha sonra, 2500 MTU'ya karşılık gelen 2472 değerinde bir yük gönderilir ve bu da başarısız olur
  • Son olarak, 1500 MTU'ya karşılık gelen 1472 değerinde bir yük başarılı şekilde gönderilir
  • Bu durumda, ağ yolunun 1500 MTU'dan daha büyük bir çerçeveyi kabul edemediği doğrulanmıştır
  • Bu örnek özelinde sorun, daha önce açıklanan OS10 hatasına bağlı olarak 2 tane S4148U-ON anahtarı arasındaki VLTi bağlantı noktası kanalı 1000'den kaynaklanmaktadır.
 

 

SLN322011_tr__1icon MTU uyuşmazlığını düzelttikten ve ESXi ana bilgisayarındaki depolamayı yeniden taradıktan sonra tüm protokol uç noktalarını beklendiği şekilde görebiliriz.

 



 

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.