OCe14000 LoM يبلغ عن الرابط كنشط مع إزالة الكابل، لذا التجميع (teaming) في ESXi لا يتحول أبدًا
كلاستر vSphere صغير، رابطان صاعدان بسرعة 10G لكل مضيف إلى زوج من محولات top-of-rack. بعد إعادة تشغيل ToR لتحديث الفيرموير، صمت جزء من الأجهزة الافتراضية على أحد المضيفين وفشل vMotion على كلا الرابطين الصاعدين - ومع ذلك لم يُبلغ ESXi أبدًا عن انقطاع أي شيء وبقيت مصابيح البطاقة مضاءة طوال الوقت.
- Fujitsu Primergy RX2540 M1
- بطاقة Emulex OneConnect OCe14000 LAN-on-motherboard (VID 10df DID 0720 SVID 1734 SSID 120e)
- ESXi 6.0 U3
- بصريات SFP+ إلى ToR، تجميع (teaming) بسيط active/standby على vSwitch
ما أقنعني أن هذا ليس المحول: سحبت الألياف من البطاقة تمامًا ولا تزال تبدو حية.
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ما جُرِّب بالفعل:
- أعدت تركيب الوحدة البصرية والألياف، استبدلت كابل الوصل
- نقلت الرابط الصاعد إلى محول ToR الآخر، الذي ينقطع منفذه كما هو متوقع
- أعدت تشغيل عوامل الإدارة على المضيف
بما أن المضيف يعتقد أن الرابط الصاعد حي، فسياسة التجميع لا سبب لديها لنقل أي شيء وتبقى الأجهزة الافتراضية مثبتة على منفذ ميت. هل هذه مشكلة معروفة بين التعريف والفيرموير على OneConnect، أم يجب أن أنظر إلى عتاد LoM؟
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
هذه التركيبة هي خطأك، وهي غير مدرجة كزوج مدعوم لـ ESXi 6.0. تنتهي البطاقة نصف حية: تتوقف عن تمرير حركة البيانات لكن تستمر بالإعلان عن المنفذ كمتصل، لذا لا تحصل سياسة التجميع أبدًا على حدث الانقطاع الذي تحتاجه للتصرف. لهذا وصل إليك الأمر كعزل جزئي مع موت vMotion على كلا الرابطين الصاعدين بدلاً من فشل صريح للبطاقة - بطاقة تموت بشكل صحيح أسهل بكثير للنجاة منها من واحدة تكذب.
ارفع التعريف إلى 11.2.1149.0. هذا هو مستوى elxnet المعتمد مقابل الفيرموير 11.2.1194.36 في قائمة توافق VMware، إذًا أنت تنقل التعريف ليطابق الفيرموير بدلاً من إرجاع البطاقة للخلف. تحقق بعد ذلك بالأمرين اللذين لديك بالفعل:
يجب أن يظهر سطر vib الإصدار الجديد، ويجب أن يتبع Link Status الكابل مرة أخرى بمجرد عودة المضيف. اختبر ذلك بسحب الألياف مع تشغيل جهاز افتراضي على ذلك الرابط الصاعد قبل أن تثق بالكلاستر عليه.
العادة التي تستحق الاحتفاظ بها: على OneConnect ينتقل التعريف والفيرموير كزوج، لذا جدول الاثنين معًا بدلاً من ترك حزمة صيانة تدفع أحدهما للأمام بمفرده. مقارنة هذين السطرين تأخذ أمرًا واحدًا، وتنتمي إلى ما قبل بدء سحب البصريات أو اتهام المحول بوقت طويل.
السطران اللذان نشرتهما هما الجزء المثير: الفيرموير 11.2.1194.36 يعمل تحت elxnet 10.2.309.6v. هل وصل ذلك الفيرموير مع حزمة صيانة خادم في مرحلة ما، بشكل منفصل عن التعريف؟
تحقق من ذلك الزوج مقابل قائمة التوافق لـ ESXi 6.0، وليس مقابل "الأحدث يجب أن يكون جيدًا". OneConnect إحدى العائلات التي يُعتمد فيها التعريف والفيرموير كزوج، والزوج غير المتطابق لا يفشل بالضرورة بصوت عالٍ - إنه يعمل نصفيًا، وهذا أسوأ بكثير.
يستحق الذكر أيضًا ما إذا كان المنفذ الثاني للبطاقة يتصرف بنفس الطريقة عند سحب كابله.
نعم، وصل الفيرموير مع حزمة صيانة خادم؛ لم يُلمس التعريف منذ بناء المضيف.
يتصرف كلا منفذي LoM بنفس الطريقة تمامًا: الكابل خارج، وesxcli network nic get لا يزال يبلغ عن Link Status: Up، والمصابيح تبقى مضاءة، وvSwitch يبقي الرابط الصاعد في القائمة النشطة. جانب المحول نظيف ومنفذه ينقطع لحظة فصلي له.
إذًا الشيء الوحيد غير المتطابق على هذا المضيف هو إصدار elxnet مقابل الفيرموير 11.2.1194.36.
عائلة مختلفة، نفس الدرس. زوج من منافذ Emulex LPe31000/LPe32000 Fibre Channel كان يعمل دون تغيير لفترة طويلة توقف عن رؤية أي LUNs بعد انتقال نواة Proxmox إلى 5.15.64 ثم لاحقًا 5.15.74. الكابلات والبصريات لم تُلمس أبدًا، وقال السجل:
هذا تراجع في lpfc من جانب المضيف، وليس عطلًا بصريًا؛ ظهر في النواة بعد 5.15.60. تثبيت نواة الإقلاع للخلف كان الحل البديل الذي صمد في الإنتاج:
كذلك عملت نواة 5.19 الاختيارية لمن لم يمانع مغادرة فرع 5.15. كان من المفترض أن يصل الإصلاح في 5.15.77، لكنني لم أتح لي الوقت لتشغيل ذلك الإصدار بنفسي، فخذها كسماع من الآخرين. النقطة تبقى قائمة: عندما يموت رابط كان يعمل مباشرة بعد تغيير شيء على المضيف، اقرأ سجل تغييرات المضيف قبل أن تقترب من الوحدات البصرية.
أضيف الصورة المعاكسة لهذا، لأنها تُدرِّب نفس رد الفعل. المؤشرات برمجية، والبرمجية تخطئ في كلا الاتجاهين.
على EX3400 وEX2300 يوجد عيب في Junos، PR1428703، حيث تبقى مصابيح منافذ SFP+ وSFP مطفأة بينما الرابط يعمل فعلاً وتمر عبره حركة بيانات. واجه الناس هذا عند الانتقال من 15.1X53 إلى فروع 18.1 و19.x، غالبًا مع DAC. واجهة سطر الأوامر تختلف مع اللوحة:
تبلغ عن المصباح كأخضر بينما المصباح الفعلي مطفأ. أُبلغ عن إصلاح بعض الإصدارات بينما استمر الإبلاغ عن مصابيح مطفأة في إصدارات أخرى، فلن أصفها كمغلقة بشكل نظيف.
حالتك مضاءة بلا رابط، تلك مطفأة مع رابط. في كلتا الحالتين، ثق بالطرف البعيد والعدادات، أبدًا بالمؤشر.
التعريف عند 11.2.1149.0 على كلا المضيفين الآن. عند سحب الكابل، تنطفئ المصابيح، ويبلغ esxcli عن انقطاع الرابط، ويتولى الرابط الصاعد الاحتياطي الأمر كما كان يجب دائمًا - عمل vMotion بشكل نظيف عبر كل رابط صاعد منفصلًا كاختبار.
زوج التعريف والفيرموير أصبح جزءًا من قائمة تدقيق صيانة الخادم لدينا حتى لا تفصلهما الحزمة القادمة بهدوء مرة أخرى.