قد يعني الجمع بين منفذي Ethernet أمرين مختلفين تمامًا. أراد المستخدم الأصلي استخدام LACP/تجميع الوصلات عبر واجهتي 2.5GbE حتى يحصل جهاز NAS على نطاق ترددي إجمالي أكبر وتكرار احتياطي. بينما ناقش موضوع آخر في المجتمع جسر Linux يعيد توجيه حركة المرور بين الواجهات. هذان تصميمان غير متكافئين.
لم ينتج عن النقاش الأصلي خلال 2025-2026 إعداد LACP موثّقًا ومستمرًا على ZimaOS. أفاد المستخدمون بعدم وجود عناصر تحكم للتجميع في واجهة الويب، وقال صاحب المنشور الأصلي إنه حاول تكييف إعداد بأسلوب NetworkManager، لكن إعادة تشغيل NetworkManager والنظام بالكامل لم تجعل التجميع يعمل.
الجسر ليس مثل LACP
يربط جسر Linux مقاطع الشبكة في الطبقة الثانية، ويمكن أن يجعل المضيف يتصرف إلى حد ما مثل المحوّل. لكنه لا يجمع منفذي الرفع تلقائيًا في اتصال منطقي واحد بسرعة 5Gbps.
ينشئ LACP/802.3ad واجهة منطقية مُجمّعة، ويتطلب عادةً إعدادًا متوافقًا على كل من جهاز NAS والمحوّل المُدار.
أراد المستخدم الأصلي استخدام منفذي 2.5GbE كتجميع واحد
كان النظام يضم بطاقة شبكة مدمجة بسرعة 1GbE، بالإضافة إلى واجهتي 2.5GbE على بطاقة توسعة. أراد المستخدم تجميع الواجهتين بدلًا من استخدامهما كعنوانين منفصلين فحسب.
كما أدرك البديل أيضًا: تثبيت بطاقة شبكة واحدة بسرعة 10GbE واستخدام محوّل متوافق.
لم يجد المستخدم الأصلي عنصر تحكم لـ LACP في واجهة ZimaOS
أفاد الرد الأول بأن تجميع الوصلات غير متاح من واجهة الويب. واستمر مستخدمون لاحقون في طلب دعم أصلي للتجميع حتى يوليو 2026.
تعرض وثائق الشبكات العامة الحالية لـ ZimaOS المنافذ الفعلية كلٌّ على حدة، مع حالة الوصلة والسرعة وإعدادات DHCP/عنوان IP اليدوي والبوابة وDNS. ولا توثّق آلية لإنشاء LACP أو التجميع.
استخدم نموذج واجهات الشبكة الحالي في ZimaOS باعتباره الأساس المدعوم.
لم يُؤكَّد نجاح التجميع اليدوي بأسلوب NetworkManager
اكتشف صاحب المنشور الأصلي أن ZimaOS لا يستخدم بنية Debian التقليدية /etc/network، وعثر بدلًا من ذلك على إعدادات مرتبطة بـ NetworkManager. فنسخ ملفات الاتصال وعدّلها لإنشاء تجميع، لكنه أفاد بأن إعادة تشغيل NetworkManager أو إعادة تشغيل النظام بالكامل لم تحقق النتيجة المطلوبة.
هذا دليل سلبي من المصدر، ولا ينبغي تحويله إلى دليل إرشادي عملي لسطر الأوامر.
لا يكفي إعداد LACP على المحوّل وحده
لا يمكن للمحوّل المُدار تجميع المنافذ إلا عندما يشارك الخادم أيضًا في إعداد LACP/التجميع نفسه. وقد يؤدي توصيل واجهتي ZimaOS عاديتين بمجموعة LACP واحدة من دون تجميع على جانب المضيف إلى عدم استقرار تعلّم عناوين MAC أو فقدان الاتصال.
لا يحوّل رابطا 2.5GbE إلى عملية نسخ واحدة بسرعة 5Gbps
حتى في الأنظمة التي يعمل فيها LACP، تُوزّع حركة المرور عادةً باستخدام تجزئة التدفقات. وتبقى تدفقات SMB/TCP المفردة عادةً على أحد رابطَي التجميع، بينما يمكن توزيع عدة عملاء أو جلسات على روابط مختلفة.
لذلك يكون تجميع الوصلات مفيدًا أساسًا لزيادة النطاق الترددي الإجمالي لعدة عملاء وللتبديل الاحتياطي، وليس وسيلة مضمونة لمضاعفة سرعة النقل في تدفق واحد لمحطة عمل واحدة.
غالبًا ما تكون بطاقة شبكة واحدة أسرع أبسط
إذا كان الهدف الفعلي هو أن ينقل عميل واحد البيانات بسرعة تتجاوز 2.5Gbps، فقد يكون مسار واحد بسرعة 10GbE أسهل في الفهم والإدارة من LACP، لأنه لا يعتمد على تجزئة التدفقات أو إعداد مجموعة LAG على محوّل مُدار.
ومع ذلك، يجب أن يكون مجمّع التخزين والعميل سريعَين بما يكفي لتغذية هذا الرابط.
ظلّ الموضوع طلبًا لإضافة ميزة
لم يعلن أي رد من موظفي IceWhale في موضوع المصدر عن دعم أصلي لـ LACP، وكان أحد المشاركين في يوليو 2026 لا يزال يطلب عناصر تحكم للتجميع في واجهات الإدارة الرسمية.
إلى أن تنشر ZimaOS آلية تجميع مدعومة، تجنّب إجراء تغييرات مستمرة على شبكة المضيف في جهاز NAS بعيد أو بلا شاشة، ما لم يتوفر لديك وصول إلى وحدة تحكم محلية ومسار للتراجع.
الأسئلة الشائعة حول تجميع الوصلات
هل جسر الشبكة هو نفسه LACP؟
لا. يعيد الجسر توجيه حركة المرور في الطبقة الثانية، بينما يجمع LACP الروابط في واجهة منطقية واحدة بالتعاون مع المحوّل.
هل أكد موضوع المصدر وجود تجميع مستمر وفعّال على ZimaOS؟
لا. لم تنجح محاولة صاحب المنشور الأصلي اليدوية باستخدام NetworkManager.
هل ستجعل وصلتا LACP بسرعة 2.5GbE عملية نسخ SMB واحدة تعمل بسرعة 5Gbps؟
عادةً لا. يكون LACP مفيدًا أكثر للتدفقات المتزامنة المتعددة وللتكرار الاحتياطي.
