في
مقال سابق ، تم النظر في الخيارات التي يمكن استبدال الأنظمة الحالية بها كجزء من تنفيذ أمر استبدال الاستيراد. سوف تركز مقالات أخرى على اختيار منتجات معينة لتحل محل نشرها حاليا. لنبدأ من نقطة البداية - أنظمة المحاكاة الافتراضية.
1. دقيق الاختيار
فماذا يمكنك الاختيار من بينها؟ يوجد في
سجل وزارة الاتصالات خيار :
- نظام المحاكاة الافتراضية للخادم " R-Virtualization " (libvirt ، KVM ، QEMU)
- حزمة البرامج " Brest Virtualization Tools " (libvirt، KVM، QEMU)
- نظام إدارة ومراقبة لبيئة Sharx Stream الافتراضية (حل سحابة غير مناسب للقطاع العام في 95٪ من الحالات (الخصوصية ، إلخ.)
- برنامج HOST للمحاكاة الافتراضية للخوادم وأجهزة الكمبيوتر المكتبية والتطبيقات (KVM x86)
- نظام الإدارة الآمنة للبيئة الافتراضية " Z | virt " (ويعرف أيضًا باسم vVirt + KVM)
- نظام إدارة بيئة المحاكاة الافتراضية لـ ROSA (المعروف أيضًا باسم oVirt + KVM)
- QP VMM Hypervisor (مشابه جدًا لـ Oracle Virtual Box ليكون أي شيء آخر)
يمكنك أيضًا مراعاة برامج Hypervisor التي تشكل جزءًا من تسليم نظام التشغيل أو الموجودة في المستودع الخاص بهم. على سبيل المثال ، نفس Astra Linux لديه دعم KVM. ونظرًا لأنه يتم تضمينه في مستودعات نظام التشغيل ، فيمكن اعتباره "مشروعًا" للتثبيت والاستخدام. نوقشت حقيقة أن "ما يمكن استخدامه في إطار استبدال الواردات وما هو ليس" في
المقال السابق ، لذلك لن أتناول هذه المسألة.
في الحقيقة ، إليك قائمة بأدوات Astra Linux الافتراضيةصلة- فيرتثلبوإكس
- Virt-manager (KVM) النسر الحالي
- libvirt على KVM
ليس لدى روزا لينكس مثل هذه القائمة ، ولكن في الويكي يمكنك العثور على الحزم التالية:صلة- ROSA الافتراضية على مدى vVirt على KVM
- QEMU على KVM
- oVirt 3.5 على KVM
تم العثور على بديل Linux في المستودع:صلة- QEMU على KVM
- libvirt على KVM
- فيرتثلبوإكس
حساب وجدت ما يلي:صلة- QEMU على KVM
- libvirt على KVM
- فيرتثلبوإكس
1.2. هناك واحد ولكن
بعد الفحص الدقيق ، نستنتج أنه سيتعين علينا التعامل مع عدد قليل فقط من برامج Hypervisor المعروفة ، وهي:
- KVM
- فيرتثلبوإكس
- كيمو
- bhyve
QEMU هو برنامج مفتوح المصدر مجاني لمضاهاة الأجهزة من مختلف المنصات التي يمكن أن تعمل دون استخدام KVM ، ولكن استخدام المحاكاة الافتراضية للأجهزة يسرع أنظمة الضيف بشكل كبير ، لذلك فإن استخدام KVM في QEMU (-enable-kvm) هو الخيار المفضل. (ج) وهذا هو ، QEMU هو برنامج Hypervisor من النوع 2 ، وهو أمر غير مقبول في بيئة المنتج. يمكن استخدامه مع KVM ، ولكن في هذه الحالة ، سيتم استخدام QEMU كأداة لإدارة KVM.
bhyve - hypervisions من النوع الثاني. تم وضع علامة عليه.
يعد استخدام
VirtualBox الأصلي في التجارة
انتهاكًا للترخيص : "بدءًا من الإصدار 4 ، الذي تم إصداره في ديسمبر 2010 ، يتم توزيع الجزء الأكبر من المنتج مجانًا بموجب ترخيص GPL v2. يتم توزيع الحزمة الإضافية المثبتة فوقه ، والتي تدعم أجهزة USB 2.0 و 3.0 ، بروتوكول سطح المكتب البعيد (RDP) ، وتشفير محرك الأقراص ، والتمهيد من NVMe و PXE ، بموجب ترخيص PUEL خاص ("للاستخدام الشخصي والتعريف") ، والذي بموجبه النظام "مجاني للاستخدام الشخصي أو لأغراض تعليمية أو للتقييم قبل اتخاذ قرار بشراء نسخة تجارية." (ج) Plus VirtualBox هو أيضًا برنامج hypervisor من النوع 2 ، لذلك يختفي أيضًا.
المجموع: في شكله النقي لدينا فقط
KVM .
2. الباقي: KVM أو KVM؟

إذا كنت لا تزال بحاجة إلى التبديل إلى برنامج Hypervisor "محلي" ، فبصراحة ، لديك خيار صغير. سيكون
KVM في غلاف واحد أو آخر ، مع العديد من التعديلات ، لكنه سيظل KVM. للأفضل أو للأسوأ - السؤال مختلف ، على أي حال ، لا يوجد بديل.
إذا كانت الشروط غير صارمة ، إذن ، كما هو مذكور في
المقال السابق: "نحن بحاجة إلى رفع المؤشرات إلى الحدود المحددة. في الواقع ، هذا يعني أنه يجب علينا استبدال أنظمة التشغيل الحالية بمنتجات من سجل وزارة الاتصالات والاتصالات ورفع عدد أنظمة التشغيل التي تم استبدالها إلى 80 ٪ ... لذلك ، يمكننا أن نترك المجموعة بأمان على Hyper-V ، حيث أننا بالفعل لدينا ونحبها. .. "(ج) لذلك نحن أمام خيار:
Microsoft Hyper-V أو
KVM . قد تكون
KVM مزودة بعناصر تحكم "مثبتة" بها ، لكنها ستظل كما هي
KVM .
تمت مقارنة هذه المنتجات أكثر من
مرة ، وليس
مرتين ، وليس
ثلاث مرات ... حسنًا ، أنت تفهم ...
حول نشر وتكوين
KVM ، تمت كتابته أيضًا أكثر من
مرة ، وليس
مرتين ، وليس
ثلاث مرات ، وليس
أربع مرات ... باختصار ، قاموا
بإعداده .
الشيء نفسه ينطبق على
Microsoft Hyper-V ..لا أرى أي سبب لتكرار ووصف هذه الأنظمة ، والمقارنة ، إلخ. يمكنك بالطبع استخلاص النقاط الرئيسية من المقالات ، لكن هذا سيكون عدم احترام للمؤلفين ، على ما أعتقد. من عليه أن يختار - سيقرأ هذا ليس فقط ، ولكن أيضًا جبل من المعلومات لاتخاذ قرار.
الفرق الوحيد الذي أريد التركيز عليه هو تجميع الفشل. إذا كانت Microsoft مدمجة في نظام التشغيل ووظائف برنامج hypervisor ، فعندئذٍ في حالة KVM ، سيتعين عليك استخدام برنامج تابع لجهة خارجية ، والذي يجب تضمينه في مستودعات نظام التشغيل. نفس المجموعة من Corosync + Pacemaker ، على سبيل المثال. (تحتوي جميع أنظمة التشغيل المحلية تقريبًا على هذه المجموعة ... ربما يكون لدى الجميع ، لكنني لم أتحقق من ذلك بنسبة 100٪.) يوجد أيضًا الكثير من الأدلة لتكوين المجموعات.
3. الخاتمة
حسنًا ، كالعادة ، لم تهتم Kulibins لدينا ، لقد أخذوا ما حدث ، ثملوا قليلاً من تلقاء أنفسهم ، وقدموا "منتجًا" ، والذي وفقًا للوثائق محلي ، لكن في الواقع - OpenSource. هل يعقل إنفاق الأموال من الميزانية لأنظمة الافتراضية "منفصلة" (قراءة غير المدرجة في نظام التشغيل)؟ لا أعتقد ذلك. نظرًا لأنك ستظل تتلقى نفس KVM ، فسوف يتعين عليك دفع ثمنها فقط.
وبالتالي ، فإن اختيار بديل برنامج Hypervisor يكمن في نظام تشغيل الخادم الذي تنوي شراءه وتشغيله من أجل Enterprise. أو ، كما في حالتي ، ستظل على ما لديك بالفعل (Hyper-V \ ESXi \ enter_necessary).
أيضا حول هذا الموضوع يمكنك أن تقرأ:المقالة السابقة حول تخطيط استبدال الواردات.
ومزيد من:مقال عن أنظمة التشغيل "المحلية".
مقال عن الأنظمة والخدمات.
وحول
QP OS بالإضافة إلى ذلك.