Brocade 200e بين Proxmox وFreeNAS: خطأ Buffer I/O وisp0: Receive Error بينما كل المنافذ online
أدير بيئة افتراضية صغيرة: عقدتا Proxmox 6 وهدف (target) على FreeNAS 11.2. طالما كانت بطاقات HBA متصلة بالهدف مباشرة، عمل كل شيء لأشهر دون خطأ واحد. وضعت بينهما محول Brocade 200e مستعملًا حتى لا أمدّ أسلاكًا متقاطعة، وبدأت المشاكل.
- عقدتا Proxmox 6، بطاقات HBA من نوع QLogic QLE2462 وQLE2432
- هدف FreeNAS 11.2
- محول Brocade 200e، Fabric OS 6.1.0a
- وحدات SFP وكابلات وصل LC من مخزون قديم، بلا علامات تعريف
على العقد في السجل:
Buffer I/O error on dev dm-5ويتبعها إعادة ضبط مستمرة للجهاز. على جانب الهدف - انتهاء مهلة الفيرموير على الأوامر (CTIO7)، وتقريبًا كل دقيقة:
isp0: Receive Errorبعد ذلك ينفصل الهدف فورًا عن كلا المُبادِرَين (initiators)، ولا يُصلح ذلك إلا بإعادة تشغيل العقدة.
ما فعلته بالفعل:
- أعدت الاتصال المباشر - لا أخطاء إطلاقًا، أي أن HBA والأقراص والهدف نفسه ليست السبب
switchshowيُظهر كل المنافذ الثلاثة online، تقسيم مناطق (zoning) بسيط، منطقة واحدة- أعدت توصيل كابلات الوصل، أعدت تشغيل المحول
أين يجب أن أنظر على المحول نفسه؟ online في switchshow يخدعني بوضوح، لكن كيف أتحقق من ذلك لا أعرف بعد.
Show original (Русский)
Also available in: Русский
العربية
Deutsch
English
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Türkçe
Tiếng Việt
简体中文
Comments 4
أنت وجدت الجواب بنفسك: تزايد crc_err وenc_out هو تلف للإطارات على الخط، وهذا ينتقل عبر الطبقات إلى مهلات الفريموير وإعادة تعيين الجهاز وإلى
isp0: Receive Error. لا النواة على العقد ولا الهدف (target) مذنبان هنا، فهما فقط ينقلان بصدق ما وصلهما.ما جمعته حتى الآن يُقرأ كالتالي:
sfpshowعلى نفس المنفذين بأسلاك متساوية الطول - هذه مقارنة بين رابطين متماثلين ببعضهما، وليست مقارنة بمعيار من الخيال. المنفذ الثالث النظيف يعمل عندك كمرجعبقي القليل. شغّل
fabriclog -s- هناك ترى كيف تتذبذب المنافذ حتى لو كان switchshow في تلك اللحظة يعرضها online. وغيّر في المنافذ المشتبه بها وحدة SFP مع كابل التوصيل LC معًا، وليس كل واحد على حدة. عندي قصة مشابهة انتهت بالضبط هكذا: استبدال الوحدات والكابلات في منفذين مشكلتين، وبعدها بقي porterrshow صفرًا خلال يوم كامل تحت الحمل، ولم تعد الفابريك تنهار.المنطق بسيط: في التوصيل المباشر يوجد على المسار موصلان، وعبر المفتاح - أربعة، بالإضافة إلى وحدتين إضافيتين. وحدة SFP على حافة القدرة أو كابل متّسخ كان بالكاد يكفي للتوصيل المباشر، لن يكفي لهذا المسار الأطول. إذن online في switchshow ليس تشخيصًا، بل مجرد واقع تسجيل الدخول (login) إلى المنفذ.
switchshow يقول شيئًا واحدًا بالضبط: رأى المنفذ ضوءًا وسجّل دخوله إلى النسيج. لا يعرف شيئًا عن جودة الإشارة، لذا الثقة به في هذا الموقف بلا معنى.
نفّذ
portstatsclearعلى كل المنافذ الثلاثة، شغّل حملًا ثم انظر إلىporterrshow- المهم هو crc_err وenc_out، هل تنمو وعلى أي منافذ بالضبط. وأيضًاsfpshowلكل منفذ: قدرة الاستقبال والجهد، من المفيد مقارنتهما بين المنافذ. وأظهر ما يعطيهsysctl dev.isp.0على جانب FreeNAS في لحظة انفصال الهدف.نظّفت العدادات، شغّلت حملًا، نظرت. الصورة هكذا: على منفذين ينمو crc_err وenc_out على دفعات، بالضبط في اللحظات التي يظهر فيها Buffer I/O error على العقد، وعلى المنفذ الثالث صفر.
sfpshowعلى نفس المنفذين يُظهر استقبالًا أقل بشكل ملحوظ من المنفذ المجاور، بأسلاك متساوية الطول.sysctl dev.isp.0أثناء الانفصال يُظهر أن HBA يعيد التهيئة، أي أنه يتفاعل مع الانقطاع، وليس هو من يُسبِّبه. يبدو أن هذا فيزياء، وليس Proxmox ولا الهدف.فخ مشابه يحدث أيضًا خارج FC، لذا يستحق النظر في العدادات على أي حال. كانت هناك تركيبة من Intel X520-2 بوحدات 10Gtek SR بطول موجة 850 نانومتر وBrocade FastIron CX 648S-PoE بوحدة FCX-2XG ووحدات XFP من Brocade، خمسة أمتار من الألياف بينهما.
الخادم كان يرفع 10GbE بصدق ويرسل، لكن لا استقبال إطلاقًا، والمنفذ على المحول كان عالقًا Up بسرعة None. نظرنا إلى
show media، تحققنا من طول الموجة والمدى من كلا الجانبين، أوقفنا تفاوض النطاق (trunk) على المنفذ - لم ينته أي من ذلك بشيء، لا يمكن تثبيت السرعة على XFP. نفس الألياف على منافذ SFP+ عملت بهدوء عند سرعة الجيجابت. العبرة نفسها تمامًا التي لديك: Up على المنفذ لا يعني أن الإطارات تصل.