بطاقة Solarflare SFN7122F تحت TrueNAS: البطاقة تُكتشف لكن وحدات SFP+ متعددة الأنماط العاملة تبقى مطفأة
أبني جهاز تخزين منزلي واقتنيت بطاقة Solarflare SFN7122F ثنائية المنفذ بسرعة 10GbE (شريحة SFC9120) لأنها كانت رخيصة. البطاقة نفسها تبدو سليمة، والنظام يراها وكلا المنفذين يظهران، لكن لا واحدة من وحدات SFP+ متعددة الأنماط التي أملكها ترفع رابطاً فيها.
- Solarflare SFN7122F، ثنائية المنفذ، وحدة تحكم SFC9120
- TrueNAS SCALE على جهاز التخزين، وكانت CORE الخطة الأصلية
- وحدات SFP+ متعددة الأنماط بسرعة 10G ترتبط دون مشاكل في بطاقة أخرى
- كابل تصحيح (patch cord) متعدد الأنماط قصير، نفس الكابل المستخدم في الاختبار الناجح
eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP>
eth3: <NO-CARRIER,BROADCAST,MULTICAST,UP>ما جربته:
- كلا المنفذين، كلتا الوحدتين، جميع التوليفات الأربع، لا شيء يرتبط أبداً
- نقلت نفس الوحدتين ونفس كابل التصحيح إلى البطاقة الأخرى، فارتبط الرابط فوراً
- بدّلت كابلات التصحيح احتياطاً لاحتمال اتساخ سطح الوصلة
إذن الألياف والوحدات ليست هي المشكلة. هل ترفض هذه البطاقة البصريات غير المُشفّرة لها، أم أن هناك خللاً في جانب التعريف، وهل ستتصرف CORE بشكل مختلف عن SCALE هنا؟ وإن كانت المسألة تشفيراً، فما الوحدات التي يشغّلها الناس فعلياً في SFN7122F؟
Comments 3
جانب التعريف (driver) ليس مشكلتك. تعريف sfxge على FreeBSD يغطّي عائلة مهايئات Solarflare SFC9000 بسرعة 10GbE، لذا SFC9120 يعمل بشكل جيد على CORE، وأنت بالفعل ترى أن SCALE تكتشف العتاد. ما تواجهه هو فحص الوحدة البصرية الخاص بالبطاقة نفسها: تقبل الوحدات المُشفّرة لـ Solarflare وتتجاهل البقية بصمت، وهذا بالضبط ما تراه - بطاقة سليمة بمنافذ لا ترتفع أبداً.
قطع يشغّلها الناس فعلاً في هذه البطاقات: FTLX8571D3BCL-SL و SFM10G-SR. كما توفّر FS وحدات مُشفّرة مسبقاً لـ Solarflare إذا ذكرت الهدف عند الطلب، وهذا عادة أسهل من البحث عن مخزون مُشفّر أصلي.
قبل أن تنفق أي شيء، فكّر في المدة المتبقية لعمر هذه البطاقة. انتقلت Solarflare إلى Xilinx وتوقف العمل على التعريف، لذا لن يأتي شيء جديد لها. لجهاز تريد نسيانه، سأضع Chelsio أولاً على هذه المنصة و Intel ثانياً. وللمعلومية، أحد التقارير طويلة الأمد هنا كان عن عامين من الخدمة دون مشاكل من بطاقة SFN6122F القريبة الصلة، والتي وُصفت بأنها أكثر تسامحاً مع البصريات العشوائية من بطاقة Intel X520 المجاورة لها - لكن تلك بطاقة أقدم ولا يغيّر ذلك سلوك التشفير في بطاقتك.
طلبت زوجاً من SFM10G-SR مُشفّرة للبطاقة وارتفع كلا المنفذين من أول إدخال، فنظرية التشفير صحيحة. لكن النتيجة عندي جزئية فقط: الوحدات القديمة متعددة الأنماط ما زالت ميتة تماماً في هذه البطاقة وتعمل فقط في البطاقة الأخرى، لذا أحتفظ الآن بمجموعتين من البصريات موسومتين ومنفصلتين.
ستبقى البطاقة حالياً لأنها تؤدي مهمتها، لكن أخذت ملاحظة Chelsio بعين الاعتبار للمرة القادمة - أفضّل ألا أشتري بصريات مُشفّرة خصيصاً في كل مرة أضيف فيها منفذاً.
يستحق إضافة فحص واحد إلى الإجراء العام، لأن "بصريات غير مدعومة" تعني أشياء مختلفة جداً حسب الجهاز. على جهاز Instant On 1930 24G كانت إجابة المورّد نفسه أن الوحدة غير المدعومة (SX أو LH وما شابه) تُعلَّم فقط - وميض في مصباح المنفذ بالإضافة إلى رسالة في سجل النظام (syslog) - ولا يُعطَّل المنفذ إطلاقاً، لذا رابط يبقى معطّلاً هناك يشير إلى المسار الفيزيائي وليس إلى قفل. انتهت تلك الحالة بمدّ ألياف جديد ووحدة SFP+ من طرف ثالث بسرعة 10G أحادية النمط من نوع LR فارتفع الرابط.
نفس الفخ يظهر بالاتجاه المعاكس مع بطاقات HBA: بطاقة Brocade 825 تظهر مرتين في lspci، وإدخال البصريات لا ينتج عنه شيء في dmesg، ما يفسّره الناس على أنه عطل. التعريفات تسجّل حالة الرابط وليس إدخال الوحدة، لذا الصمت هناك ليس تشخيصاً أيضاً.
في حالتك، أجريت بالفعل الاختبار الوحيد الذي يحسم الأمر، نفس الوحدة ونفس الكابل يرتبطان في بطاقة أخرى، لذا قفل التشفير هو الاستنتاج الصحيح. فقط لا تدع أحداً يقنعك بهذا الاستنتاج على جهاز حيث كل ما في الأمر مصباح ورسالة سجل.