Proxmox‏ LXC أم آلة افتراضية لاستضافة Docker مع تمرير USB أو وحدة معالجة الرسومات: أيهما أسهل في التشغيل؟

اختر حاوية Proxmox LXC لمضيف Docker عندما يمكن كشف عُقد أجهزة Linux بأمان، ويمتلك المضيف برامج تشغيل GPU أو USB المطلوبة، ويكون انخفاض الاستهلاك أو مشاركة GPU أمرًا مهمًا. واختر جهازًا افتراضيًا عندما يجب أن يمتلك الضيف حزمة برامج التشغيل، أو ينبغي عزل جهاز PCI عبر IOMMU، أو يجب أن يظل Docker ووصوله إلى العتاد مستقلَّين عن مضيف Proxmox. غالبًا ما تناسب الأجهزة التسلسلية عبر USB كلا المسارين؛ أما تمرير GPU الحصري فعادةً ما يفضّل جهازًا افتراضيًا.

حدّد معنى «التمرير» قبل مقارنة LXC بجهاز افتراضي

لا يمرّر LXC وKVM العتاد إلى أحمال العمل بالطريقة نفسها. تشارك حاوية LXC نواة Proxmox، لذا تحصل عادةً على إذن للوصول إلى عُقد الأجهزة التي أنشأها المضيف، مثل `/dev/dri` أو `/dev/ttyUSB0` أو `/dev/bus/usb`. ويظل المضيف يكتشف العتاد ويحمّل برنامج تشغيل النواة.

يشغّل الجهاز الافتراضي نواته الخاصة. ويمكن لـ Proxmox محاكاة جهاز USB، أو إرفاق جهاز USB أو منفذ USB محدد، أو تعيين جهاز PCI عبر VFIO وIOMMU. ثم يحمّل الضيف برنامج التشغيل الخاص به ويتعامل مع العتاد المعيّن كما لو كان جهازًا مثبتًا مباشرةً.

يقدّم دليل إعداد Proxmox NAS الحالي من ZimaSpace كلا النوعين من أنظمة الضيف. وتضيّق هذه المقالة نطاق القرار إلى مضيف Docker تحتاج حاوياته إلى وحدات USB، أو محوّلات تسلسلية، أو وحدات GPU للوسائط، أو مسرّعات حوسبة.

تفضّل أجهزة USB حاويات LXC عندما تتصرف مثل عُقد أجهزة Linux مستقرة

يمكن أن تعمل محولات USB التسلسلية، ومنسقات Zigbee، وواجهات UPS، ومسرّعات Coral USB، والأجهزة المماثلة جيدًا في LXC عندما يتيح Proxmox عقدة الجهاز ويعيّن الملكية الصحيحة. وتتلقى حاوية Docker داخل LXC ذلك الجهاز من بيئة مضيف Linux الخاصة بها.

يوضح شرح عملي لـ الوصول إلى USB داخل Proxmox LXC النمط الأساسي: لا يكفي تركيب الجهاز ما لم يُسمح للحاوية أيضًا بالوصول إليه.

استخدم مسارات ثابتة مثل `/dev/serial/by-id` عندما يدعمها التطبيق. فقد تتغير أرقام الناقل وتعيينات `/dev/ttyUSB0` بعد إعادة التشغيل أو إعادة الاتصال. ويصبح مسار LXC هشًا عندما يتطلب كل تحديث للمضيف إصلاح cgroup أو UID أو GID أو مسار الجهاز يدويًا.

يكون الجهاز الافتراضي أنظف عندما يجب أن تكون ملكية USB مستقلة بالكامل

يمكن للجهاز الافتراضي تلقي جهاز USB باستخدام معرّف المورّد والمنتج أو عبر منفذ فعلي، ثم تحميل تعريف الجهاز داخل نظام التشغيل الخاص به. ويفيد ذلك عندما يحتاج الجهاز إلى حزمة مورّد، أو إصدار مختلف من النواة، أو حزمة تطبيقات ينبغي ألا تعتمد على مكتبات مضيف Proxmox.

كما يوفر الجهاز الافتراضي حدًا أوضح للتشخيص. فإذا فقد الضيف جهاز USB، يمكن للمسؤول فحص إرفاقه ببرنامج مراقبة الأجهزة الافتراضية، ثم فحص تعريف الضيف بشكل منفصل. أما في LXC، فيشارك تعريف المضيف، وعقدة الجهاز، والأذونات، وتعيين الحاوية، وبيئة تشغيل Docker، والتطبيق جميعًا في سلسلة واحدة.

لكن المقابل هو سلوك إعادة الاتصال. فقد تُعاد تهيئة بعض أجهزة USB أو تتغير هويتها أو تختفي أثناء إعادة تشغيل الضيف. اختبر فصل الجهاز، وإعادة تشغيل المضيف، وإعادة تشغيل الضيف، واستعادة التطبيق بدل افتراض أن نجاح الإرفاق الأول يثبت استقرار التشغيل.

-15% OFF

ZimaBoard 2 - خادم منزلي صغير لأفكارك الكبيرة

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

عادةً ما يُفضَّل LXC للوصول المشترك إلى وحدة معالجة الرسومات

بالنسبة إلى أجهزة التصيير من Intel أو AMD وأحمال العمل المدعومة على NVIDIA، يمكن لـ LXC إتاحة عُقد أجهزة وحدة معالجة الرسومات التي يستضيفها المضيف لعدة خدمات Linux. وتظل وحدة معالجة الرسومات مُدارة بواسطة تعريف مضيف Proxmox، ما يتيح لعدة حاويات استخدام تسريع الأجهزة لتحويل الترميز أو تنفيذ العمليات الحسابية من دون إسناد جهاز PCI بالكامل إلى ضيف واحد.

يوضح المثال الأخير من XDA كيفية تمكّن ‏LXC من مشاركة وحدة معالجة الرسومات التي يديرها المضيف بدل تخصيصها عبر تمريرها إلى جهاز افتراضي. ويمكن أن يلائم نموذج التشغيل نفسه Jellyfin أو Plex أو Frigate أو خدمات Docker متعددة عندما تتوافق متطلبات التعريفات والأذونات.

تؤدي المشاركة إلى ترابط الإصدارات. إذ يجب أن يظل برنامج تشغيل النواة في المضيف، والمكتبات في مساحة المستخدم داخل LXC، وتكامل بيئة تشغيل Docker، وحزم التطبيقات متوافقة. لذلك قد يؤثر تحديث نواة Proxmox أو برنامج التشغيل في كل حاوية تستخدم وحدة معالجة الرسومات في الوقت نفسه.

يميل تمرير وحدة معالجة الرسومات حصريًا إلى تفضيل الآلة الافتراضية عادةً

تُعد الآلة الافتراضية الخيار الأقوى عندما يحتاج أحد أعباء العمل إلى ملكية مباشرة لوحدة معالجة رسومات منفصلة، أو برنامج تشغيل خاص بالضيف، أو دعم Windows، أو عزل CUDA، أو حزمة نواة لا ينبغي تثبيتها على Proxmox. ويفصل إسناد VFIO الجهاز عن المضيف ويقدّمه إلى الضيف.

صُمّم نموذج PCI في Proxmox حول إسناد جهاز PCI فعلي إلى ضيف KVM. وتوضح مناقشة Docker على Level1Techs النتيجة العملية: تستهلك الآلة الافتراضية عادةً وحدة معالجة الرسومات التي تم تمريرها إليها حصريًا، في حين يمكن لـ LXC مشاركة الوصول إلى أجهزة المضيف بين الخدمات.

قد ينقلب هذا الاختيار عندما تدعم وحدة معالجة الرسومات الأجهزة المُدارة أو SR-IOV، لكن وحدات معالجة الرسومات الاستهلاكية ومنصات الخوادم المنزلية لا توفر مسار مشاركة موحدًا. تحقّق من مجموعات IOMMU، وسلوك إعادة الضبط، والبرامج الثابتة، وتهيئة العرض، وما إذا كان المضيف يحتاج إلى وحدة معالجة الرسومات تلك قبل تصميم الحل على أساس التمرير الحصري.

يضيف Docker داخل LXC طبقة إدارة متداخلة

يوفّر LXC عزلًا على مستوى نظام التشغيل، ويضيف Docker بيئة تشغيل حاويات أخرى بداخله. قد يكون ذلك فعالًا، لكنه يضيف مساحات أسماء متداخلة، وcgroups، وبرامج تشغيل للتخزين، وإمكانات، وسلوكًا مختلفًا لعمليات الربط. وتتطلب بعض ميزات Docker تفعيل خيارات التداخل أو منح أذونات إضافية في حاوية Proxmox.

تقدّم الآلة الافتراضية إلى Docker مضيف Linux تقليديًا. ويصبح تفسير وثائق Docker ووحدات النواة وسلوك جدار الحماية وبرامج تشغيل التخزين أسهل، لأن نظام الضيف يتولى إعدادات نواته. لكن التكلفة تشمل نظام تشغيل كاملًا للضيف، وذاكرة محجوزة، وإدارة قرص افتراضي، وطبقة أخرى من التحديثات.

لا تختَر LXC لمجرد توفير بضع مئات من الميغابايتات إذا كان الإعداد المطلوب يفرض حاوية ذات صلاحيات كاملة، وأذونات واسعة للأجهزة، وتعديلات غير موثقة على المضيف. يفقد الخيار خفيف الوزن قيمته عندما يعتمد كل تحديث على تذكّر الاستثناءات التي كانت الآلة الافتراضية ستحتويها داخل نظام الضيف.

يمكن للعزل والأمان أن يقلبا الفائز في الأداء

تشترك LXC في نواة المضيف، لذا قد تكشف حاوية ذات امتيازات تم إعدادها بشكل خاطئ أو تعيين جهاز واسع النطاق عن جزء أكبر من عقدة Proxmox مما هو مقصود. ويساعد استخدام LXC غير ذات الامتيازات، وتقييد أذونات الأجهزة، وعمليات التركيب للقراءة فقط، والحد الأدنى من الإمكانات على تحسين العزل، لكن البنية تظل أكثر ترابطًا من VM كاملة.

توفر VM نواة منفصلة ويمكنها عزل حزم GPU الاحتكارية، وشبكات Docker، ووحدات الجدار الناري، والبرامج التجريبية عن قاعدة Proxmox. وتكون هذه العزلة قيّمة عندما يستضيف Docker صورًا من جهات خارجية، أو خدمات عامة، أو حزم ذكاء اصطناعي محلية، أو تجارب متكررة لبرامج التشغيل.

لا تكون VM آمنة تلقائيًا. إذ لا يزال تمرير PCI، وعمليات تركيب وحدات التخزين المشتركة، وبيانات اعتماد الإدارة، والشبكات الموصولة بجسر، تفتح مسارات للهجوم والفشل. اخترها عندما يبسّط حد النواة وبرنامج التشغيل المستقل فعلًا نموذج التهديد والصيانة.

تفضّل النسخ الاحتياطية والترحيل نوعين مختلفين من البساطة

تتميز نسخ LXC الاحتياطية بصغر حجمها وسرعتها لأن الضيف لا يحتوي على حزمة أجهزة افتراضية كاملة. لكن استعادة الوصول إلى الأجهزة على عقدة Proxmox أخرى تتطلب تطابق عقد الأجهزة والمجموعات وبرامج التشغيل والأذونات. ويمكن نقل نظام ملفات الحاوية، لكن لا يمكن نقل متطلبات الجهاز الفعلي بالطريقة نفسها.

تتضمن نسخة VM الاحتياطية نظام تشغيل الضيف وإعدادات برنامج التشغيل، ما يجعل استعادة التطبيق أكثر اكتفاءً ذاتيًا. ومع ذلك، لا تزال مرفقات USB وعناوين PCI بحاجة إلى إعادة تعيين على الوجهة، وقد يمنع تمرير GPU الترحيل المباشر لأن الجهاز الفعلي مرتبط بعقدة واحدة.

يغطي سير عمل النسخ الاحتياطي في ZimaSpace حماية الضيف. في هذه المقارنة، لا تكتمل الاستعادة إلا عند بدء Docker وتمكّن التطبيق المعتمد على USB أو GPU من رؤية الجهاز البديل.

استخدم اختبارًا لاستعادة الجهاز قبل اختيار نوع الضيف

1. أدرج كل جهاز USB وPCI تحتاج إليه تطبيقات Docker.
2. حدّد ما إذا كان ينبغي مشاركة كل جهاز مع المضيف أو تخصيصه لضيف واحد.
3. اختبر برنامج تشغيل المضيف، وعقدة الجهاز، وتعيين UID/GID، وأذونات Docker لـ LXC.
4. اختبر تجميع IOMMU، وتثبيت برنامج تشغيل الضيف، وسلوك إعادة الضبط لجهاز افتراضي.
5. أعد تشغيل مضيف Proxmox وتأكد من عودة إرفاق الجهاز تلقائيًا.
6. استعد الضيف من النسخة الاحتياطية وأعد إنشاء تعيين الأجهزة بالاستناد إلى الوثائق.
7. كرّر الاختبار على عقدة أخرى متوافقة إذا كانت الهجرة أو استبدال الأجهزة مهمًا.

قِس سلوك التطبيق بدلًا من قياس النفقات العامة للضيف فقط. فعادةً ما تكون استقرارية التسريع العتادي لترميز الوسائط، وإعادة اتصال USB، وتحديثات برامج التشغيل، وصيانة المضيف، ووقت الاسترداد أهم من فرق صغير في وحدة المعالجة المركزية بين LXC وKVM.

أي نوع من ضيوف Proxmox يلائم استضافة Docker؟

اختر LXC عندما

اختر LXC عندما تكون جميع أعباء العمل معتمدة على Linux، ويستطيع المضيف تولي برامج التشغيل، وتكشف أجهزة USB عن عقد ثابتة، وينبغي مشاركة وحدة معالجة الرسومات بين عدة خدمات. أبقِ الحاوية غير ذات امتيازات حيثما أمكن، ووثّق كل تعيين للأجهزة والمجموعات.

اختر آلة افتراضية عندما

اختر آلة افتراضية عندما تحتاج استضافة Docker إلى ملكية حصرية لوحدة معالجة الرسومات PCI، أو إلى برامج تشغيل مملوكة أو تجريبية، أو إلى عزل أقوى على مستوى النواة، أو إلى قابلية نقل أسهل لحزمة البرامج الكاملة. خصص ذاكرة وصول عشوائي ومساحة تخزين كافيتين للضيف، واختبر إعادة ضبط الجهاز بعد إعادة التشغيل.

قسّم أعباء العمل عندما

شغّل خدمات الوسائط الخفيفة وخدمات USB في LXC، بينما ضع حوسبة GPU الحصرية، أو الأدوات المعتمدة على Windows، أو حزم Docker غير الموثوقة في آلة افتراضية. يمكن لمنصة متوافقة مع Proxmox دعم الخيارين، لكن ينبغي أن يكون لكل جهاز فعلي نموذج ملكية موثق واحد.

الأسئلة الشائعة

هل يمكن تشغيل Docker بشكل موثوق داخل LXC غير ذي امتيازات؟

نعم، بالنسبة إلى العديد من أعباء العمل، لكن قد تتطلب الاستضافة المتداخلة وبرامج تشغيل التخزين ونقاط الربط والشبكات والوصول إلى الأجهزة إعدادًا إضافيًا. اختبر ميزات Docker المطلوبة تحديدًا، وتجنب التحول إلى حاوية ذات امتيازات لمجرد تجاوز مشكلة أذونات غير مفسرة.

هل يمكن استخدام وحدة معالجة رسومات واحدة بواسطة كل من LXC وآلة افتراضية؟

ليس من خلال تمرير الجهاز بالكامل عبر VFIO بالطريقة العادية في الوقت نفسه. قد يشارك LXC جهاز عرض تديره المضيف، بينما تحتاج الآلة الافتراضية عادةً إلى فصل الجهاز عن المضيف. ويمكن أن يغير دعم SR-IOV أو الأجهزة المُدارة هذا الأمر على أجهزة محددة.

أي خيار أفضل لمنسق Zigbee عبر USB؟

يمكن أن ينجح كلا الخيارين. يتميز LXC بالكفاءة عندما يكون مسار serial-by-ID ثابتًا والأذونات موثوقة. وتكون الآلة الافتراضية أنظف عندما ينبغي أن تظل حزمة برامج المنسق أو برنامج التشغيل مستقلة عن مضيف Proxmox.

الحكم النهائي

استخدم LXC لاستضافة Docker عندما يمكن مشاركة موارد USB ووحدة معالجة الرسومات عبر حزمة برامج تشغيل Linux على مضيف Proxmox ويكون انخفاض النفقات العامة مهمًا. استخدم آلةً افتراضية عندما ينبغي أن تكون الأجهزة مملوكة للضيف، أو عندما يلزم عزل برامج التشغيل، أو عندما يجب أن تحافظ عملية الاسترداد على نظام تشغيل مستقل ومتكامل. اختر بناءً على ملكية الجهاز وسلوك الاستعادة، لا على افتراض أن الحاويات أبسط دائمًا.