الفرق بين Hypervisor من النوع الأول والنوع الثاني

Hypervisor هو البرنامج الذي يُنشئ الأجهزة الافتراضية (VMs) ويُشغّلها. يتيح لحاسوب فعلي واحد تشغيل عدة أنظمة تشغيل في الوقت نفسه، كل نظام معزول داخل جهازه الافتراضي الخاص، بينما تتشارك جميعها العتاد نفسه. من دون Hypervisor، يفترض نظام التشغيل أنه يمتلك الجهاز بأكمله — عناوين الذاكرة الخاصة به، وأنوية المعالج، والأقراص. مهمة Hypervisor هي اعتراض هذه الافتراضات وترجمتها بأمان إلى موارد فعلية مشتركة.

يقسّم Hypervisor موارد العتاد — وقت المعالج والذاكرة والتخزين والوصول إلى الشبكة — بين الأجهزة الافتراضية، ويحافظ على عزل كل نظام تشغيل ضيف عن غيره، بحيث لا ينتقل عطل أو خطأ في الإعداد أو حادثة أمنية داخل جهاز افتراضي واحد إلى الأجهزة المجاورة. تساعد في ذلك ميزات المحاكاة الافتراضية المدعومة بالعتاد والمدمجة في المعالجات الحديثة، مثل Intel VT-x وAMD-V، التي تتيح للمعالج نفسه فرض الحدود بين الأجهزة الضيفة.

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

يُثبَّت Hypervisor من النوع الأول مباشرةً على الخادم الفعلي، من دون نظام تشغيل عام تحته. فهو يتحكم بالعتاد نفسه — جدولة المعالج، وإدارة الذاكرة، وتعريفات الأجهزة — ويجدول الأجهزة الافتراضية على ذلك العتاد كمهمته الأساسية والوحيدة. لهذا السبب يُطلق على Hypervisor من النوع الأول أيضًا اسم Hypervisor العتاد المباشر (Bare Metal).

ولأن Hypervisor من النوع الأول لا يتشارك الجهاز مع نظام تشغيل سطح مكتب وتطبيقاته وخدماته الخلفية ودورات تحديثه، فبإمكانه تخصيص كامل موارد الخادم تقريبًا لتشغيل الأجهزة الافتراضية. كما أنه مصمم من الأساس لأنماط التشغيل التي تحتاجها مراكز البيانات فعليًا: الإقلاع بشكل موثوق من دون لوحة مفاتيح أو شاشة متصلة، والإدارة عن بُعد عبر الشبكة، والانضمام إلى عنقود من الخوادم الأخرى، وتوفير واجهة برمجة تطبيقات (API) تتيح لأدوات التزويد والمراقبة والأتمتة التواصل معه مباشرة.

يُعد Hypervisor من النوع الأول الخيار المعياري لمحاكاة خوادم المؤسسات لهذه الأسباب بالذات. فهو مصمم للعمل المستمر وغير المراقَب على مدى أشهر أو سنوات، ولتجميع خوادم فعلية عديدة في مجمّع منطقي واحد من السعة، وللتوافر العالي (High Availability) بحيث يمكن إعادة تشغيل الأجهزة الافتراضية على خادم آخر عند تعطّل أحد الخوادم، وللترحيل الحي (Live Migration) الذي يتيح نقل جهاز افتراضي قيد التشغيل بين الخوادم من دون إيقافه. ونادرًا ما يتفاعل مسؤولو النظام مع Hypervisor من النوع الأول عبر شاشة محلية مباشرة — بل يديرونه من خلال لوحة تحكم مركزية، أو سطر أوامر، أو واجهة برمجية، غالبًا عبر عشرات أو مئات الخوادم في آنٍ واحد.

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

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

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

يعكس الجدول التالي التصاميم النمطية الشائعة؛ وتختلف المنتجات الفعلية عن ذلك أحيانًا وقد تُذيب الحدود الموصوفة هنا.

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

"العتاد المباشر" (Bare Metal) يعني ببساطة أن Hypervisor هو أول طبقة برمجية على العتاد — فلا يوجد نظام تشغيل عام عليه التفاوض معه. ولأنه لا ينافس نظام تشغيل سطح مكتب على دورات المعالج أو الذاكرة أو إدخال وإخراج القرص، يمكنه تخصيص الجهاز بالكامل لتشغيل الأجهزة الافتراضية، وتقليل سطح الهجوم البرمجي المكشوف على المضيف، وإدارته وتحديثه كبنية تحتية لا كحاسوب شخصي.

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

يُدمَج KVM (الجهاز الافتراضي المستند إلى النواة) داخل نواة لينكس نفسها، بدل تثبيته كمنتج منفصل فوقها. عند تفعيله، تتصرف نواة لينكس التي تعمل مباشرةً على الخادم كـ Hypervisor، وتستخدم الأجهزة الافتراضية امتدادات المحاكاة الافتراضية في المعالج لتشغيل تعليمات النظام الضيف بأداء قريب من الأداء الأصلي. من هذا المنظور، يتصرف KVM كـ Hypervisor من النوع الأول على العتاد المباشر، ويُستخدم بهذه الطريقة في مراكز بيانات المؤسسات وبيئات السحابة حول العالم، بما في ذلك عدد من أكبر مزودي السحابة العامة.

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

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

يُعد Hypervisor محوريًا لمحاكاة الخوادم، لكن كلمة "المحاكاة الافتراضية" تشمل عدة مفاهيم متمايزة يسهل الخلط بينها في الحديث اليومي، رغم أن التقنيات والأدوات الكامنة وراءها مختلفة تمامًا:

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

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

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

أساس HV هو أساس محاكاة الخوادم لدى فيرشوا، مبني على KVM وQEMU وlibvirt، ويُنشر مباشرةً على عتاد الخادم كمنصة من طراز النوع الأول على العتاد المباشر. وحول هذا الأساس، تضيف منصة فيرشوا إدارة مركزية عبر لجام لإدارة السحابة، وأدوات ترحيل عبر جسر للمؤسسات المنتقلة من VMware أو منصة أخرى، وقدرات نسخ احتياطي وتعافٍ من الكوارث عبر حماية، وأتمتة عبر مهاد للفرق التي تريد تزويد البنية التحتية وإدارتها ككود بدل الإعداد اليدوي.

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