OCe14000 LoM, kablo çıkarılmışken link up raporluyor, bu yüzden ESXi teaming hiç failover yapmıyor
Küçük bir vSphere cluster'ı, host başına bir çift top-of-rack switch'e giden iki 10G uplink. ToR bir firmware güncellemesi için reboot edildikten sonra bir hosttaki VM'lerin bir kısmı sessizleşti ve vMotion iki uplinkte de başarısız oldu - yine de ESXi hiçbir şeyi down işaretlemedi, adaptör LED'leri de boyunca yanık kaldı.
- Fujitsu Primergy RX2540 M1
- Emulex OneConnect OCe14000 LAN-on-motherboard adaptörü (VID 10df DID 0720 SVID 1734 SSID 120e)
- ESXi 6.0 U3
- ToR'a giden SFP+ optikler, vSwitch'te düz active/standby teaming
Beni bunun switch olmadığına ikna eden şey: fiberi adaptörden tamamen çıkardım ve hâlâ canlı görünüyor.
esxcli network nic get -n vmnic2 (cable physically removed)
Link Status: Up
Firmware Version: 11.2.1194.36
esxcli software vib list | grep elxnet
elxnet 10.2.309.6vŞimdiye kadar denediklerim:
- optiği ve fiberi yeniden oturttum, patch lead'i değiştirdim
- uplink'i diğer ToR switch'ine taşıdım, onun portu beklendiği gibi düşüyor
- host'taki management agent'ları restart ettim
Host uplink'in canlı olduğuna inandığı için teaming policy'nin hiçbir şeyi taşımak için sebebi yok ve VM'ler ölü bir porta pinlenmiş kalıyor. Bu, OneConnect'te bilinen bir driver-firmware sorunu mu, yoksa LoM donanımına mı bakmalıyım?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 6
Bu kombinasyon senin hatan, ESXi 6.0 için desteklenen bir eşleşme olarak listelenmiyor. Adaptör yarı canlı bir hâlde kalıyor: trafiği taşımayı durduruyor ama portu bağlı olarak duyurmaya devam ediyor, bu yüzden teaming policy harekete geçmek için ihtiyaç duyduğu down event'ini hiç almıyor. Bu yüzden sana bu, dürüst bir NIC arızası yerine iki uplinkte de vMotion'ın öldüğü kısmi bir izolasyon olarak ulaştı - düzgünce ölen bir kart, yalan söyleyen birinden çok daha kolay atlatılır.
Driver'ı 11.2.1149.0'a çıkar. Bu, VMware compatibility list'inde firmware 11.2.1194.36'ya karşı yeterlilik kazanmış elxnet seviyesi, yani kartı geri almak yerine driver'ı firmware'e uysun diye ileri taşıyorsun. Sonrasında zaten elindeki iki komutla doğrula:
vib satırı yeni versiyonu göstermeli, host geri geldiğinde Link Status de kabloyu tekrar takip etmeli. Cluster'a güvenmeden önce, o uplinkte bir VM çalışırken fiberi çekerek test et.
Alışkanlık olarak akılda kalması gereken: OneConnect'te driver ve firmware bir çift olarak hareket eder, yani bir maintenance bundle'ın ikisinden birini kendi başına sürüklemesine izin vermek yerine ikisini birlikte planla. O iki satırı karşılaştırmak tek bir komut alıyor, optikleri çekmeye ya da switch'i suçlamaya başlamadan çok önce yapılması gereken de bu.
Paylaştığın iki satır ilginç kısım: elxnet 10.2.309.6v'nin altında çalışan firmware 11.2.1194.36. O firmware bir noktada, driver'dan ayrı olarak bir server maintenance bundle'ıyla mı geldi?
O eşleşmeyi "en yenisi mutlaka iyidir"e karşı değil, ESXi 6.0 için compatibility list'ine karşı kontrol et. OneConnect, driver ve firmware'in bir çift olarak yeterlilik kazandığı ailelerden biri, uyuşmayan bir çift de mutlaka gürültülü başarısız olmaz - yarı çalışır, bu da çok daha kötüdür.
Adaptörün ikinci portunun da kablosu çıkınca aynı şekilde davranıp davranmadığını söylemekte de fayda var.
Evet, firmware bir server maintenance bundle'ıyla geldi; driver host kurulduğundan beri dokunulmamış.
İki LoM portu da aynı şekilde davranıyor: kablo çıkınca esxcli network nic get hâlâ Link Status: Up raporluyor, LED'ler yanık kalıyor, vSwitch de uplink'i active listesinde tutuyor. Switch tarafı temiz ve fişi çektiğim an onun portu düşüyor.
Yani bu hostta uyumsuz olan tek şey, firmware 11.2.1194.36'ya karşı elxnet versiyonu.
Farklı bir aile, aynı ders. Uzun süredir dokunulmadan çalışan bir çift Emulex LPe31000/LPe32000 FC portu, bir Proxmox kernel'i 5.15.64'e ve sonra 5.15.74'e geçince hiç LUN görmemeye başladı. Kablolama ve optikler hiç dokunulmadı, log da şunu söylüyordu:
Bu host tarafında bir lpfc regresyonu, optik bir arıza değil; 5.15.60'tan sonraki kernel'lerde ortaya çıktı. Boot kernel'ini geri sabitlemek, production'da tutan workaround'du:
Opt-in 5.19 kernel'i de 5.15 branch'inden ayrılmayı sorun etmeyenler için işe yaradı. Düzeltmenin 5.15.77'de gelmesi bekleniyordu, ama o build'i kendim hiç çalıştırmadım, yani bunu duyum olarak al. Nokta şu: eskiden çalışan bir link, hostta bir şey değiştikten hemen sonra ölürse, transceiver'lara yaklaşmadan önce host change log'unu oku.
Bunun ayna görüntüsünü ekliyorum, çünkü aynı refleksi eğitiyor. Göstergeler software'dir, software da her iki yönde de yanılır.
EX3400 ve EX2300'de bir Junos defekti var, PR1428703, link gerçekten up olup trafik geçirirken SFP+ ve SFP port LED'leri karanlık kalıyor. İnsanlar buna çoğunlukla DAC ile 15.1X53'ten 18.1 ve 19.x train'lerine geçerken rastladı. CLI panelle anlaşmıyor:
fiziksel olan sönükken LED'i Green olarak raporluyor. Bazı build'ler fixed olarak bildirildi, başkalarında karanlık LED'ler raporlanmaya devam etti, yani bunu temiz bir şekilde kapandı diye adlandırmam.
Seninki linksiz yanıyor, o ise linkli karanlık. Her hâlükârda, karşı uca ve sayaçlara güven, göstergeye asla.
Driver şimdi iki hostta da 11.2.1149.0'da. Kablo çekilince LED'ler sönüyor, esxcli linki down raporluyor, standby uplink de her zaman yapması gerektiği gibi devralıyor - vMotion, test olarak her uplinkte ayrı ayrı sorunsuz çalıştı.
Driver-firmware çifti, sıradaki bundle'ın onları sessizce yine ayırmaması için server maintenance checklist'imize giriyor.