OCe14000 LoM cable निकालने पर भी link up बताता है, इसलिए ESXi teaming कभी failover नहीं करता
Small vSphere cluster है, हर host से दो 10G uplinks एक जोड़ी top-of-rack switches में जाते हैं। firmware update के लिए ToR reboot होने के बाद, एक host की कुछ VMs चुप हो गईं और vMotion दोनों uplinks पर fail हुआ - फिर भी ESXi ने कभी कुछ down नहीं बताया और adapter की LEDs पूरे समय जलती रहीं।
- Fujitsu Primergy RX2540 M1
- Emulex OneConnect OCe14000 LAN-on-motherboard adapter (VID 10df DID 0720 SVID 1734 SSID 120e)
- ESXi 6.0 U3
- ToR में SFP+ optics, vSwitch पर plain active/standby teaming
जिस चीज़ ने मुझे यकीन दिलाया कि यह switch की गलती नहीं है: मैंने adapter से fibre पूरी तरह निकाल दी और यह अब भी जिंदा दिख रहा है।
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पहले ही try कर चुका हूँ:
- optic और fibre reseat की, patch lead बदली
- uplink दूसरे ToR switch पर shift की, जिसका port expected तरीके से down हो जाता है
- host पर management agents restart किए
चूँकि host को लगता है कि uplink जिंदा है, teaming policy के पास कुछ भी move करने की कोई वजह नहीं बचती और VMs एक dead port पर टिकी रह जाती हैं। क्या यह OneConnect पर driver-बनाम-firmware की कोई known problem है, या मुझे LoM hardware देखना चाहिए?
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
यह combination आपकी अपनी गलती है, और ESXi 6.0 के लिए यह supported pairing में listed नहीं है। Adapter आधा-जिंदा हो जाता है: traffic move करना बंद कर देता है पर port को connected बताना जारी रखता है, तो teaming policy को कभी वह down event मिलता ही नहीं जो action लेने के लिए चाहिए। इसीलिए यह आपके पास honest NIC failure की तरह नहीं, बल्कि दोनों uplinks पर मरे हुए vMotion के साथ partial isolation के तौर पर पहुँचा - जो card ठीक से मरता है उससे बचना उस card से कहीं आसान है जो झूठ बोलता है।
Driver को 11.2.1149.0 तक ले जाएँ। VMware compatibility list में firmware 11.2.1194.36 के साथ यही elxnet level qualified है, तो आप card को वापस rollback करने की बजाय driver को firmware से मिलाने के लिए आगे बढ़ा रहे हैं। बाद में उन्हीं दो commands से verify करें जो आपके पास पहले से हैं:
vib वाली line नया version दिखानी चाहिए, और host वापस up होने के बाद Link Status फिर से cable को follow करना चाहिए। Cluster को इस पर भरोसा देने से पहले उस uplink पर एक VM चलाकर fibre खींचकर test कर लें।
एक आदत अपनाने लायक है: OneConnect पर driver और firmware जोड़ी में चलते हैं, तो इन दोनों को साथ schedule करें, किसी maintenance bundle को इनमें से एक को अकेला आगे खींचने मत दें। इन दो lines को compare करना बस एक command का काम है, और यह optics निकालने या switch को दोष देने से बहुत पहले करने वाली चीज़ है।
आपने जो दो lines post कीं वही दिलचस्प हिस्सा हैं: elxnet 10.2.309.6v के नीचे firmware 11.2.1194.36 चल रहा है। क्या वह firmware कभी driver से अलग, किसी server maintenance bundle के साथ आया था?
उस pairing को ESXi 6.0 की compatibility list के हिसाब से check करें, "newest हमेशा ठीक होगा" के हिसाब से नहीं। OneConnect उन families में से एक है जहाँ driver और firmware जोड़ी के तौर पर qualified होते हैं, और mismatched जोड़ी ज़रूरी नहीं कि ज़ोर से fail करे - यह आधा काम करती है, जो कहीं ज्यादा बुरा है।
यह भी बताने लायक है कि adapter का दूसरा port cable निकालने पर वैसा ही व्यवहार करता है या नहीं।
हाँ, firmware एक server maintenance bundle के साथ गया था; host बनने के बाद से driver को छुआ तक नहीं गया।
दोनों LoM ports बिलकुल एक जैसा व्यवहार करते हैं: cable बाहर, esxcli network nic get अब भी Link Status: Up report करता है, LEDs जली रहती हैं, और vSwitch uplink को active list में रखता है। Switch साइड बिलकुल clean है और मेरे unplug करते ही उसका port drop हो जाता है।
तो इस host पर सिर्फ elxnet version ही firmware 11.2.1194.36 के मुकाबले out of step है।
अलग family, सीख वही। Emulex LPe31000/LPe32000 वाले FC ports की एक जोड़ी, जो लंबे समय से बिना छेड़े चल रही थी, Proxmox kernel के 5.15.64 और बाद में 5.15.74 पर जाने के बाद कोई भी LUN देखना बंद कर बैठी। Cabling और optics को छुआ तक नहीं गया, और log में लिखा था:
यह host साइड पर lpfc की regression है, optical खराबी नहीं; यह 5.15.60 के बाद वाले kernels में दिखी। Boot kernel को पीछे pin करना वह workaround था जो production में टिका रहा:
opt-in 5.19 kernel भी उन लोगों के लिए काम कर गया जिन्हें 5.15 branch छोड़ने से दिक्कत नहीं थी। Fix का 5.15.77 में आना तय था, पर मैंने खुद वह build चलाकर कभी देखा नहीं, तो इसे सुनी-सुनाई बात ही मानें। बात वही है: जब कोई पहले से चलता link host पर कुछ बदलने के ठीक बाद मर जाए, transceivers के पास जाने से पहले host का change log पढ़ लें।
इसकी mirror image जोड़ रहा हूँ, क्योंकि यह वही reflex train करती है। Indicators software हैं, और software दोनों दिशाओं में गलती करता है।
EX3400 और EX2300 पर एक Junos defect है, PR1428703, जिसमें SFP+ और SFP port की LEDs बंद रहती हैं जबकि link genuinely up है और traffic pass हो रहा है। लोगों को यह 15.1X53 से 18.1 और 19.x trains पर जाते वक्त मिली, ज्यादातर DAC के साथ। CLI panel से असहमत रहता है:
LED को Green report करता है जबकि physical वाली बंद है। कुछ builds में इसे fixed बताया गया और कुछ दूसरों में dark LEDs की report आती रही, तो मैं इसे साफ तौर पर बंद हुआ नहीं कहूँगा।
आपकी वाली बिना link के जली है, वह वाली link होते हुए बंद है। दोनों ही मामलों में, far end और counters पर भरोसा करें, indicator पर कभी नहीं।
अब दोनों hosts पर driver 11.2.1149.0 पर है। Cable खींचने पर LEDs बुझ जाती हैं, esxcli link को down report करता है, और standby uplink उसी तरह take over करता है जैसा उसे हमेशा से करना चाहिए था - test के तौर पर vMotion हर uplink पर अलग-अलग साफ-साफ चला।
Driver-और-firmware की जोड़ी अब हमारी server maintenance checklist में जा रही है ताकि अगला bundle इन्हें चुपचाप फिर से अलग न कर दे।