‏KVM مقابل OpenVZ مقابل LXC: ما الذي يسمح لك به نوع المحاكاة الافتراضية في خادمك الافتراضي فعليًا

خطتا خادم افتراضي على الصفحة نفسها. أربعة vCPU، و8 غيغابايت من الذاكرة، و160 غيغابايت من التخزين، وسعر شبه متطابق. إحداهما تقول KVM والأخرى تقول OpenVZ. ولا تشرح أي من الصفحتين ما الذي تغيّره هذه الكلمة.

إنها تغيّر ما يُسمح لك بتشغيله. أنواع المحاكاة الافتراضية للخوادم ليست مجرد حاشية عن الأداء. فهي تحدد ما إذا كنت تتحكم في النواة، وما إذا كان Windows ممكنًا، وما إذا كان Docker يعمل دون تدخل من المزوّد. المقارنة بين KVM وOpenVZ وLXC هي مسألة قدرات قبل أن تكون مسألة سرعة.

يغطي هذا الدليل التسميات الثلاث الأكثر صلة بقرار الشراء هذا. توجد أيضًا Xen وVMware وHyper-V وغيرها من منصات المحاكاة الافتراضية، لكنها خارج نطاق هذه المقارنة الثلاثية.

الخلاصة السريعة

• KVM يمنح كل خادم افتراضي نواة ضيف خاصة به. يعمل Docker بشكل طبيعي، وWindows ممكن تقنيًا، ويمكنك عادةً تحميل وحدات النواة أو إقلاع نواة مخصصة. لكن KVM وحده لا يضمن معالجًا أو ذاكرة مخصصة؛ فالتزامات الموارد تظل مرهونة بالمزوّد وبالخطة.
• OpenVZ عادةً ما تكون خطط الخوادم الافتراضية حاويات Linux تتشارك نواة المضيف. لا يمكن تشغيل Docker على OpenVZ 7 إلا إذا استخدم المزوّد نواة وإعداد قوالب متوافقين. لا يمكنك استبدال نواة المضيف، والذاكرة التي تتجاوز الذاكرة العشوائية تُدار عبر VSwap الخاضع لتحكم المزوّد بدلاً من ملف التبديل العادي على القرص الذي يديره الضيف.
• LXC يتشارك هو الآخر نواة المضيف، لكنه مبني على خصائص الاحتواء في نواة Linux الرئيسية. يمكن تشغيل Docker عندما يفعّل المضيف الخصائص المطلوبة، مع أن Proxmox يوصي بتضمين الحاويات داخل جهاز افتراضي QEMU لأحمال العمل التي تتطلب أقصى عزل وترحيلًا حيًا.
• عادةً ما يكون تغيير حجم الحاويات أثناء التشغيل أسهل. ويستطيع KVM أيضًا دعم الإضافة الساخنة للمعالج والذاكرة، لذا فإن القول إن "KVM يتطلب إعادة تشغيل دائمًا" ليس قاعدة شراء موثوقة. اسأل المزوّد عما تدعمه منصته فعليًا.
• بالنسبة إلى موقع ثابت أو حزمة LAMP صغيرة لا تحتاج أبدًا إلى Docker أو Windows أو تخصيص على مستوى النواة، قد يكون الفارق العملي ضئيلًا. ومع ذلك، قد يظل العزل ودورة الحياة وسياسة الموارد مختلفة.

الفارق الوحيد الذي يتسبب في كل الفوارق الأخرى

يمنح KVM كل خادم افتراضي على المضيف نواة ضيف خاصة به. أما حاويات OpenVZ وLXC فتستخدم النواة التي أقلعها المضيف.

‏KVM هو حل محاكاة افتراضية كاملة لعتاد x86 ‏مع امتدادات المحاكاة الافتراضية. وقد دُمج في نواة Linux الرئيسية اعتبارًا من الإصدار 2.6.20. يرى كل ضيف عتادًا افتراضيًا ويقلع نظام تشغيله ونواته الخاصة.

تعمل أنواع الحاويات بطريقة مختلفة. فـ LXC هو واجهة في فضاء المستخدم لخصائص الاحتواء في نواة Linux، بما في ذلك مساحات الأسماء وcgroups وcapabilities وseccomp وملفات تعريف الأمان. ويهدف إلى توفير بيئة قريبة من تثبيت Linux العادي دون إقلاع نواة منفصلة.

تتبع حاوية OpenVZ النموذج العام نفسه القائم على نواة مشتركة، رغم أن OpenVZ يستخدم منصته ومكدس النواة الخاص به. يستطيع OpenVZ 7 إدارة الحاويات وأجهزة KVM الافتراضية معًا، لكن حين تُوسم خطة خادم افتراضي تجارية بـ "OpenVZ"، فالمنتج المُباع عادةً هو النوع الحاوي.

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

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

اقرأ

KVM مقابل OpenVZ 2022: من هو نجم المحاكاة الافتراضية؟

ما الذي يتيح لك كل نوع تشغيله

المحاور التي تحسم قرار الشراء هي التحكم في النواة، ودعم نظام تشغيل الضيف، والتوافق مع Docker، وسلوك الذاكرة، وتغيير الحجم، وسياسة الموارد.

أيها ينبغي أن تختار؟ ‏KVM هو الجواب الأوضح عندما تحتاج إلى Windows أو نواة مخصصة أو وحدات يحمّلها الضيف أو مضيف Docker يمكن التنبؤ بسلوكه. وقد يكون OpenVZ وLXC بيئتَي Linux فعّالتين، لكنهما يتركان القرارات على مستوى النواة بيد المزوّد.

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

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

لماذا يُعد Docker السؤال الذي يحسم معظم قرارات الشراء

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

‏Docker على OpenVZ

دعم Docker على OpenVZ قرار تزويد يُتخذ فوق مستواك. مقال دعم من SolusVM يذكر أن Docker يمكن أن يعمل داخل OpenVZ 7 اعتبارًا من إصدار نواة محدد من سلسلة 3.10، لكنه يشير أيضًا إلى أن Docker لا يعمل مع القوالب القديمة القياسية المُنشأة مسبقًا. فعلى الحاوية استخدام قالب EZ أو قالب مخصص مناسب. ويستثني المقال نفسه ضيوف CentOS 8.

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

عندما يكون إعداد المضيف غير متوافق، فإن تغيير خيارات Docker داخل الخادم الافتراضي لن يحل المشكلة الجذرية. تحتاج إلى أن يغيّر المزوّد إعداد الحاوية أو ينقلك إلى نوع محاكاة افتراضية مختلف.

‏Docker على LXC

يمكن تشغيل Docker داخل LXC عندما يتيح المضيف الخصائص المطلوبة. وفي Proxmox يشمل ذلك عادةً تداخل الحاويات و keyctl للحاويات غير المميزة.

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

إذا كنت تتحكم بمضيف LXC، فبإمكانك تقييم هذه المفاضلة واختبار الترقيات وفق جدولك الخاص. أما إذا كنت تستأجر خادمًا افتراضيًا بـ LXC، فالمزوّد هو من يتحكم بالنواة وملف تعريف الأمان وخيارات الخصائص المتقدمة. تأكد من الإعداد المدعوم بدلًا من افتراض أن صلاحية الجذر داخل الحاوية كافية.

‏Docker على KVM

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

امتلاك نواة الضيف يعني أيضًا صيانتها. فعلى خادم افتراضي غير مُدار، تبقى التحديثات وقواعد الجدار الناري وأمان Docker والنسخ الاحتياطية من مسؤوليتك.

الفكرة الرئيسية: لا يجعل Docker استخدام OpenVZ أو LXC مستحيلًا، لكنه يجعل إعداد المزوّد جزءًا من موثوقية تطبيقك. وبالنسبة إلى مضيف Docker إنتاجي مستأجَر، يزيل KVM هذا الاعتماد الإضافي.

هل تعني "4 vCPU" أربع أنوية معالجة مخصصة

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

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

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

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

الفكرة الرئيسية: الرقم نفسه على صفحة الخطة يمثل وعدًا مختلفًا باختلاف النوع. فعلى KVM هو تخصيص، وعلى OpenVZ هو سقف تتشاركه مع غيرك.

أين لا يزال OpenVZ منطقيًا، وإلى أين يتجه

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

تتطلب دورة الحياة انتباهًا أكبر مما كانت عليه قبل عقد. يستند OpenVZ 7 إلى فرع نواة RHEL 7، الإصدار 3.10. ورقم الإصدار وحده لا يثبت أن نواة مؤسسية ما زالت مصانة تفتقر إلى إصلاحات أمنية، لأن المورّدين ينقلون الترقيعات إلى الإصدارات الأقدم. لكنه يعني أن عليك التحقق من التوافق مع البرمجيات التي تتوقع واجهات نواة أحدث.

The open-source OpenVZ project and the commercial Virtuozzo product are on separate tracks, and the commercial one has published dates. Virtuozzo Hybrid Server 7 reached end of maintenance in July 2024 and is listed for end of life in December 2027 in the سياسة دورة الحياة الرسمية.

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

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

الاختيار بحسب حجم العمل

ابدأ من المتطلب لا من التقنية.

اختر KVM عندما يحتاج حجم العمل إلى نواة خاصة به

‏KVM هو الخيار المباشر عندما تحتاج إلى أي مما يلي:

• ‏Windows كنظام تشغيل ضيف
• نواة مخصصة
• وحدات نواة يحمّلها الضيف
• ‏Docker إنتاجي دون الاعتماد على حاوية داخل حاوية
• المحاكاة الافتراضية المتداخلة، عندما يتيحها المزوّد
• ملف تبديل وضبط للنواة يتحكم بهما الضيف

‏Windows هو العامل الحاسم لأن حاويات OpenVZ وLXC كلتيهما تستخدمان نواة مضيف Linux. أما الاختيار بين Linux وWindows للتطبيق نفسه فهو مسألة منفصلة تتعلق بتوافق البرمجيات والإدارة والترخيص. راجع مقارنة الخوادم الافتراضية بين Linux وWindows لاتخاذ ذلك القرار.

اختر LXC عندما تريد حاوية نظام Linux فعّالة

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

بالنسبة إلى خادم افتراضي مستأجَر بـ LXC، تحقق من دعم Docker والأجهزة المطلوبة ووضع الأمان وسلوك النسخ الاحتياطي وإمكانية تفعيل الخصائص المتقدمة.

فكّر في OpenVZ لحِمل عمل Linux بسيط ومُتحقَّق منه

قد يظل OpenVZ مقبولًا لموقع بسيط أو حزمة LAMP صغيرة أو خدمة DNS أو حِمل Linux تقليدي مماثل، وذلك عندما:

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

لا تختره لمجرد أن مقارنة قديمة تقول إن OpenVZ أرخص دائمًا. قارن الخطة الحالية والدعم وسياسة الموارد وخيارات الترحيل.

إذا استقرّت إجابتك على KVM، فذلك بفعل القيد لا بفعل التفضيل. إن KVM VPS من Cloudzy يقلع خلال 60 ثانية على AMD EPYC مع NVMe خالص، وتحصل كل نسخة على نواة ضيف خاصة بها. تُحمَّل وحدات النواة، وتُقلع الأنوية المخصصة، ويُدعم ضيوف Linux وWindows على السواء. ‏Docker متاح في سوق التطبيقات إن كنت تفضّل ألا تثبّته بنفسك.

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

systemd-detect-virt