تقسيم MikroTik CRS812 400G إلى DGX Spark: رابط 200G يتوقف عند 106 جيجابت في الثانية وNCCL يتراجع إلى Socket
نُعِدّ أربع عقد DGX Spark للتدريب الموزّع وربطناها بـ MikroTik CRS812-8DS-2DQ-2DDQ. كانت الخطة منفذ QSFP-DD واحد بسرعة 400G على المحول يغذي عقدتين بسرعة 200G لكل منهما، بحيث يغطي كابلا تقسيم (breakout) الكلاستر بأكمله.
- MikroTik CRS812-8DS-2DQ-2DDQ، منافذ QSFP-DD تُستخدم في وضع التقسيم (breakout)
- NADDOD Q2Q56-400G-CU2، DAC سلبي من QSFP-DD 400G إلى 2xQSFP56 200G
- عقد DGX Spark ببطاقة ConnectX-7 مدمجة
- التحقق باستخدام iperf3 وnccl-tests all_reduce_perf
يبلغ كلا الطرفين عن رابط 200GbE نظيف، لكن الإنتاجية تستقر عند أكثر بقليل من نصف ذلك:
# iperf3 -c <peer> -P 8
[SUM] 0.00-10.00 sec ... 106 Gbits/sec
single stream: ~30 Gbits/sec
# ip -br link
enp1s0f1np1 UP
enP2p1s0f1np1 UPNCCL يبدو أسوأ من ذلك: يبلغ all_reduce_perf عن نقل Socket ونحو 2 جيجابايت في الثانية من عرض نطاق الناقل (bus bandwidth) عبر العقد الأربع، إذًا من الواضح أن RDMA لا يُستخدم إطلاقًا.
ما تحققنا منه بالفعل:
- أعدنا تركيب واستبدلنا كابل التقسيم بين منافذ المحول، نفس الأرقام تمامًا
- رفعنا عدد التدفقات، الإجمالي يبقى مثبتًا قرب 106 جيجابت في الثانية
- أكدنا أن المحول يبلغ عن المنفذ عند 200G، وليس 100G
الجزء الذي أعود إليه دائمًا هو أن منفذ QSFP56 فيزيائي واحد يظهر كواجهتين منطقيتين على العقدة. هل يقدّم التقسيم فقط نصف الحارات (lanes) لكل عقدة، أم أن منفذ 200G على هذا العتاد من المفترض أن يبدو هكذا؟
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 7
هذا بالضبط ما هو، وكابل التقسيم بريء. على هذه المنصة يُوصَّل منفذ ConnectX-7 عبر PCIe x4 ويظهر كنصفين منطقيين، كل منهما يحمل نحو 100 جيجابت في الثانية. لا تظهر سرعة 200G الكاملة إلا عندما يُحمَّل النصفان في نفس الوقت، لذا تشغيل iperf3 بعنوان واحد يتوقف بالكاد بعد 100 جيجابت في الثانية هو النتيجة المتوقعة وليس عطلًا.
ما نجح هنا:
مع حمل كلا النصفين لحركة البيانات يجب أن تصل قريبًا من معدل الخط على الزوج، وسيبلغ nccl-tests all_reduce_perf عن فئة مختلفة تمامًا من عرض نطاق الناقل بمجرد أن يتوقف عن المرور عبر المقابس (sockets).
قبل أن تتهم الكابل، كيف بالضبط تُشغِّل تلك الواجهتين؟ لصقت enp1s0f1np1 وenP2p1s0f1np1 كلتيهما UP، لكن هل يضرب iperf3 كلتيهما، أم فقط أيًا منهما يحمل عنوانًا؟
يستحق النشر أيضًا: MTU على العقد وعلى منافذ CRS812، لأن 1500 يؤذي بشدة عند هذا المعدل، ومحتويات /etc/nccl.conf. عندما يختار NCCL نقل Socket فذلك في الغالب لأن شيئًا في ذلك الملف أخبره ألا يلمس مسار IB، وليس لأن النسيج (fabric) معطل.
أسئلة عادلة. فقط enp1s0f1np1 لديها عنوان، ونصف enP2p1s0f1np1 نشط لكن غير مُعدّ، وكل تشغيل لـ iperf3 حتى الآن ذهب إلى ذلك العنوان الواحد. MTU هو 1500 على العقد ولم ألمس MTU من الطبقة الثانية (L2) على جانب المحول أيضًا. ونعم، ها هو:
كان ذلك موجودًا بالفعل في الصورة (image) ولم أشكك فيه أبدًا. فهل يمكن أن يكون 106 جيجابت في الثانية مجرد نصف واحد من المنفذ بالإضافة إلى بعض المساحة الإضافية؟
حزمة تقنية مختلفة، نفس شكل المفاجأة. جانبي كان ConnectX-6 (MT28908) تحت RHEL 8.4، MLNX_OFED 5.7، الفيرموير 20.32.2004، MFT 4.21؛ الطرف البعيد Switch-IB 2 SB7800، وبينهما مقسّم LinkX MCP7H50-H002R26 يأخذ 200G وينزل إلى 2x100G. عمل المنفذ كـ
ولا mlxlink -d mlx5_0 -p 1 --speeds edr ولا --speeds hdr غيّرا شيئًا. اتضح أنه سقف في السيليكون وليس خطأ إعداد: عتاد EDR يشكّل روابط فقط بعرض 1x أو 4x، ومقسّم من هذا النوع يعتمد على تجميع 2x، الذي وصل مع HDR. إذًا إما كابل 4x EDR عادي في ذلك المحول، أو الانتقال إلى HDR إذا كان التقسيم ضروريًا.
العبرة للتقسيمات (breakouts) بشكل عام: اعرف نوع تجميع الحارات (lane grouping) الذي يمكن لكل طرف تشكيله فعليًا قبل أن تقيس أي شيء.
شيء واحد من الوصفة أعلاه يستحق التوضيح، لأنه المكان الذي يفقد فيه الناس المكاسب مرة أخرى: يجب أن يتطابق MTU على المحول أيضًا. ضبط 9000 على المضيفات بينما لا تزال المنافذ تمرر إطارات بحجم 1500 بايت يشتري لك إسقاطات بدلاً من إنتاجية. اضبط MTU من الطبقة الثانية على منافذ CRS812 وتحقق باستخدام بينغ (ping) بحمولة كبيرة قبل إعادة تشغيل أي اختبار.
نقطة IPv6 هي نفس القصة. مع عنونة كلا النصفين وترك IPv6 مفعّلاً تحصل على إدخالات GID إضافية لكل منفذ، والفهرس الذي طُلب من اختبارك استخدامه ليس بالضرورة ما تعتقده. إيقاف IPv6 على واجهات CX7 يبقي ذلك الجدول صغيرًا وقابلًا للتنبؤ عبر إعادة التشغيل، وهو أمر أكثر أهمية مما يبدو عندما تقارن التشغيلات.
يستحق تذكّره أن منفذ تقسيم يبقى معطلاً هو حيوان مختلف تمامًا عن حالتك. على جهاز Arista DCS-7060CX-32S مستعمل (EOS 4.16.8FX-7060X) أظهرت واجهاتي الفرعية الأربع عدم وجود أخطاء إطلاقًا ولم تعمل ببساطة أبدًا. كان الصندوق مضبوطًا على transceiver qsfp default-mode 4x10G بينما قدّم الطرف البعيد 25G، وبقي Et17/1 في حالة errdisabled حتى ضُبط المعدل يدويًا:
في نفس الجلسة رُفض كابل Mellanox كوحدة إرسال واستقبال غير معتمدة واضطر لاستبداله بكابل DAC متوافق مع Arista من نوع 100GBASE-CR4 QSFP28. في الطرف الآخر من الطيف، لم يحصل زميل أبدًا على تقسيم QDD-4X100G-2P5M ليعمل على QFX5220-32CD يعمل بـ Junos 23.2R1-S1.8-EVO نحو محول Mellanox، مع ملف تعريف منفذ تحقق منه Port Checker وكل نوع FEC جُرِّب. حالتك على الأقل تتفاوض وتمرر حركة البيانات.
تأكّد، ولم يكن المنفذ معطلاً أبدًا. عنونت enP2p1s0f1np1 كواجهة خاصة بها، ضبطت MTU 9000 على العقد وعلى منافذ المحول، أوقفت IPv6 على كلتا واجهتي CX7 وحذفت NCCL_IB_DISABLE=1 من /etc/nccl.conf.
جلستا iperf3 متوازيتان، واحدة لكل نصف، تعطيان الآن إجماليًا 196-198 جيجابت في الثانية. يبلغ all_reduce_perf عبر العقد الأربع عن 23.76 جيجابايت في الثانية من عرض نطاق الناقل وNCCL على مسار RDMA، لا نقل Socket في السجل بعد الآن. كان NADDOD Q2Q56-400G-CU2 يقوم بعمله طوال الوقت.