النظرية العامة وعلم الآثار الافتراضية x86

مقدمة

فريق المؤلفين

أرسلت بواسطة أنتون Zhbankov ( AntonVirtual ، cloudarchitect.cc )
مؤلفون مشاركون : غريغوري بريالوكين ، يفغيني بارفينوف

المفاهيم الافتراضية العامة

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

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

المحاكاة الافتراضية - إخفاء تنفيذ معين وراء طريقة موحدة عالمية للوصول إلى الموارد / البيانات.

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

POZOR!

Uwaga! Achtung! Pozor!

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

أنواع المحاكاة الافتراضية

دعونا نعود من المفاهيم المجردة تماما إلى أكثر دراية لأجهزة الكمبيوتر لدينا الحبيب.

تخزين الظاهري

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

FS -> LBA -> CHS

خذ أبسط الحالات لنظام التخزين على قرص مغناطيسي ثابت واحد. التنسيق المعتاد للعمل مع البيانات هو الملفات الموجودة على محرك الأقراص المنطقي. يمكن فتح الملف وقراءته وإغلاقه. لكن هذا الكائن كملف ببساطة غير موجود فعليًا - لا يوجد سوى طريقة للوصول إلى كتل بيانات معينة باستخدام طريقة عنونة النموذج "drive: \ folder1 \ folder2 \ file". أي نلتقي الطبقة الأولى من الافتراضية - من ذاكري ومفهومة للبشر ، نحن نترجم كل شيء إلى عناوين مفهومة من النظام. في جداول البيانات الأولية ، يبحث برنامج تشغيل نظام الملفات عن نوع كتل البيانات الموجودة ، ونحصل على العنوان في نظام عنونة الكتلة المنطقية (LBA). في نظام LBA ، يكون للكتل حجم ثابت وتتبع بعضها البعض خطيًا ، أي بطريقة ما ، قد يكون الأمر متعلقًا بتخزين البيانات على شريط مغناطيسي ، لكن القرص الثابت مختلف تمامًا! وهنا نذهب إلى الطبقة الثانية من المحاكاة الافتراضية - ترجمة LBA الموجهة إلى CHS (الاسطوانة / الرأس / القطاع).



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

RAID

الطبقة التالية من المحاكاة الافتراضية ، والتي لا يعتبرها الكثير من الناس عن طريق الخطأ ، هي RAID (مجموعة زائدة من الأقراص الرخيصة / المستقلة).

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

RAID هو القرص الظاهري.

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

عرض الافتراضية

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

الخوادم الطرفية و VDI وحتى RDP فقط عبر VPN إلى الخادم هي كل المحاكاة الافتراضية للجلسة. باستخدام واجهة قياسية (الشاشة ولوحة المفاتيح والماوس) ، نعمل إما مع جهاز حقيقي ، أو مع تصميم غير مفهوم من سطح مكتب افتراضي على استنساخ مرتبط مع تطبيق حاويات ، حيث ننقل البيانات من خلال مخزن مؤقت إلى تطبيق مع تسليم دفق. أم لا ، من سيحددها ، إلى جانب الشخص الذي صممها؟

مقدمة إلى x86 الافتراضية

التاريخ ونظرة عامة على المعالجات

تنفيذ البرنامج

في الدرس الأول في دورة برمجة خاصة ، أخبر فلاديمير دينيسوفيتش ليليوخ الطلاب (الراحة من أجله) الطلاب: الكمبيوتر ، على الرغم من اسمه ، لا يمكن الاعتماد عليه ، يمكن أن يدعي أنه قادر على الاعتماد. ولكن إذا كان هناك شيء يشبه البطة ، يمشي مثل البطة والدج مثل البطة ، فمن الناحية العملية ، يكون البطة.

دعونا نحاول أن نتذكر هذا للاستخدام العملي أكثر.

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

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

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

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

تعدد المهام

ما الذي يجب فعله في المواقف إذا كان من الضروري تنفيذ العديد من البرامج (تدفقات التعليمات البرمجية مع بنيات البيانات والذاكرة الخاصة بهم) في نفس الوقت؟ من الواضح ، إذا كان هناك تدفقات رمز أكثر من الأجهزة القادرة على تنفيذها ، فهذه مشكلة.

يظهر تعدد المهام الزائفة عند تنفيذ المهمة عند التبديل مباشرة إليها.

في المستقبل ، تظهر تعاونية (تعدد المهام غير الاستباقية) - المهمة التنفيذية نفسها تدرك أنها لم تعد بحاجة إلى موارد المعالج وتمنح التحكم لشخص آخر. لكن كل هذا لا يكفي.

وهنا مرة أخرى الانقطاعات + القدرة على التظاهر تأتي لإنقاذنا. لا يهم المستخدم حقًا أن يتم تنفيذه بدقة متزامنة ، يكفي أن يبدو الأمر كذلك.
لذلك ، يتم تعليق المعالج ببساطة لمقاطعة المؤقت ، والذي يبدأ في التحكم في دفق الرمز الذي يجب تنفيذه بعد ذلك. إذا تم تشغيل المؤقت في كثير من الأحيان (قل 15ms) ، عندها يبدو كل شيء للمستخدم عملية موازية. وهكذا هناك ازدحام حديث متعدد المهام.

الوضع الحقيقي

يمكن وصف وضع المعالج الحقيقي في هذه المقالة بكل بساطة - كل الذاكرة متاحة للجميع. يمكن لأي تطبيق ، بما في ذلك البرامج الضارة (البرامج الضارة ، والبرامج الضارة) الوصول إلى أي مكان ، للقراءة والكتابة.

هذا هو الوضع الأولي لتشغيل عائلة المعالجات Intel x86.

الوضع المحمي

في عام 1982 ، ظهر ابتكار في معالج Intel 80286 (المشار إليه فيما يلي باسم 286) - وهو أسلوب تشغيل محمي ، جلب معه الابتكارات في تنظيم العمل مع الذاكرة (على سبيل المثال ، تخصيص أنواع شرائح الذاكرة - الكود ، البيانات ، المكدس). ولكن الشيء الأكثر أهمية الذي جلبه المعالج 286 إلى عالم x86 هو مفهوم حلقات الحماية ، التي لا نزال نستخدمها.

ظهر مفهوم حلقات الحماية في الأصل في Multics OS لنظام GE645 الرئيسي (1967) مع تنفيذ برنامج جزئي ، وأجهزة كاملة بالفعل في عام 1970 في نظام هانيويل 6180.



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

في أول تطبيق كامل لـ Honeywell 6180 ، تم تنفيذ 8 حلقات حماية ، لكن Intel قررت تبسيط الدائرة إلى 4 ، والتي من الناحية العملية ، بدأ مصنعو OS يستخدمون اثنين فقط من الصفر والثالث.

32BIT و

في عام 1985 ، تم إصدار معالج آخر مهم للغاية من الناحية المعمارية في خط x86 - 80386 (يشار إليه فيما يلي 386) ، والذي قام بتطبيق عنونة الذاكرة 32 بت واستخدم إرشادات 32 بت. وبالطبع ، الذاكرة الافتراضية. كما ذكرنا من قبل ، فإن المحاكاة الافتراضية هي إخفاء للتنفيذ الفعلي من خلال توفير موارد "افتراضية" مصطنعة. في هذه الحالة ، نحن نتحدث عن معالجة الذاكرة. لدى قطاع الذاكرة عنونة خاصة به ، والتي لا علاقة لها بالموقع الفعلي لخلايا الذاكرة.
تبين أن المعالج كان في حالة طلب كبير حيث تم إنتاجه قبل عام 2007.
الهندسة المعمارية من حيث إنتل تسمى IA32.

64BIT

بطبيعة الحال ، حتى دون وجود المحاكاة الافتراضية في منتصف العقد الأول من القرن العشرين ، كانت الصناعة تعمل بالفعل في حدود 32 بت. كانت هناك حلول جزئية في شكل PAE (ملحق العنوان الفعلي) ، لكنها معقدة وتباطأت الكود. كان الانتقال إلى 64 بت نتيجة مفروغ منها.

قدمت AMD نسختها من البنية ، والتي تسمى AMD64. في Intel ، كانوا يأملون في الحصول على منصة IA64 (Intel Architecture 64) ، والتي نعرفها أيضًا باسم Itanium. ومع ذلك ، واجه السوق هذه البنية دون الكثير من الحماس ، ونتيجة لذلك ، اضطرت شركة Intel إلى تنفيذ دعمها الخاص لتعليمات AMD64 ، والتي كانت تسمى أولاً EM64T ، ثم Intel 64 فقط.

في النهاية ، نعرف جميعًا هذه البنية مثل AMD64 أو x86-64 أو x86_64 أو x64 أحيانًا.

نظرًا لأن الاستخدام الرئيسي للخوادم في ذلك الوقت كان من المفترض أن يكون فعليًا ، دون استخدام المحاكاة الافتراضية ، فقد حدث شيء فني مضحك مع أول معالجات 64 بت في المحاكاة الافتراضية. غالبًا ما كانت برامج Hypervisor المتداخلة تستخدم كملقمات مختبرية ؛ ولا يمكن لأي شخص تحمل تكاليف عدة خوادم فعلية. وفي النهاية اتضح أن تحميل VM في برنامج Hypervisor المضمن يمكن أن يعمل فقط في وضع 32bit.

في معالجات x86-64 الأولى ، قام المطورون ، مع الحفاظ على التوافق التام مع وضع التشغيل 32 بت ، بإخراج جزء كبير من الوظيفة في وضع 64 بت. في هذه الحالة ، كانت المشكلة تبسيط تجزئة الذاكرة إلى حد كبير. تمت إزالة القدرة على ضمان حرمة قطعة صغيرة من الذاكرة في VM حيث يعمل معالج استثناء برنامج Hypervisor. وفقا لذلك ، كان نظام التشغيل الضيف قادرا على تعديله.
بعد ذلك ، أعادت AMD إمكانية الحد من الشرائح ، وانتظرت Intel ببساطة لإدخال المحاكاة الافتراضية للأجهزة.

UMA

بدأت أنظمة X86 متعددة المعالجات العمل مع وضع UMA (الوصول إلى الذاكرة الموحدة) ، حيث المسافة من أي معالج (التأخير في الوصول إلى خلية ذاكرة) إلى أي شريط ذاكرة هو نفسه. في معالجات Intel ، تم الحفاظ على مخطط العمل هذا حتى بعد ظهور معالجات متعددة النواة حتى الجيل 54xx (Harpertown). بدءًا من الجيل 55xx (Nehalem) ، تحولت المعالجات إلى بنية NUMA.

من وجهة نظر منطق التنفيذ ، هذا هو ظهور مؤشرات ترابط الأجهزة الإضافية ، والتي يمكنك من خلالها تعيين تدفقات التعليمات البرمجية للتنفيذ بالتوازي.

NUMA

NUMA (الوصول غير الموحد للذاكرة) - بنية مع وصول غير متساو إلى الذاكرة. ضمن هذه البنية ، كل معالج له ذاكرته المحلية الخاصة ، والتي يتم الوصول إليها مباشرة مع الكمون المنخفض. يتم الوصول إلى ذاكرة المعالجات الأخرى بشكل غير مباشر مع تأخير أعلى ، مما يؤدي إلى انخفاض الأداء.

بالنسبة لمعالجات Intel Xeon Scalable v2 لعام 2019 ، لا تزال البنية الداخلية UMA داخل المقبس ، وتتحول إلى NUMA لمآخذ التوصيل الأخرى (وإن لم تكن في الحقيقة ، فهي تتظاهر فقط). تمتلك معالجات Opteron من AMD بنية NUMA حتى أثناء أقدم UMA Xeon ، ثم أصبحت NUMA داخل المقبس حتى الجيل الأخير من روما ، حيث عادوا إلى NUMA = socket.

آلة افتراضية

Virtual Machine (VM ، من الجهاز الظاهري باللغة الإنجليزية) - برنامج و / أو نظام أجهزة يحاكي أجهزة بعض الأنظمة الأساسية (الهدف هو النظام الأساسي الهدف أو الضيف) وينفذ برامج النظام الأساسي الهدف على النظام الأساسي المضيف (المضيف هو النظام الأساسي المضيف أو النظام الأساسي المضيف) أو إضفاء طابع افتراضي على بعض الأنظمة الأساسية وإنشاء بيئات عليها تعزل البرامج وحتى أنظمة التشغيل عن بعضها البعض. ويكيبيديا.
في هذه المقالة ، سوف نقول "الجهاز الظاهري" ، بمعنى "الأجهزة الافتراضية للنظام" ، مما يسمح بمحاكاة جميع الموارد والأجهزة بشكل كامل في شكل تصميمات البرامج.
هناك نوعان رئيسيان من البرامج لإنشاء أجهزة افتراضية - كاملة وممتازة. المحاكاة الافتراضية غير المكتملة.

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

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

البرامج الافتراضية

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

لكن تم تحديد كل شيء بكل بساطة: نظرًا لأن برنامج الضيف OS هو عبارة عن مجموعة من صفحات الذاكرة مع وصول مباشر كامل ، ولأن المعالج الظاهري هو مجرد قائمة انتظار من الأوامر ، لماذا لا تعيد كتابتها؟ فورًا ، يطرد برنامج hypervisor من قائمة انتظار الإرشادات للتنفيذ على المعالج الظاهري جميع الإرشادات التي تتطلب امتيازات الحلقة الصفرية ، واستبدالها بامتيازات أقل امتيازًا. ولكن يتم تقديم نتيجة هذه التعليمات بنفس الطريقة تمامًا كما لو كان نظام التشغيل الضيف في حلقة الصفر. وبالتالي ، يمكنك محاكاة أي شيء على الإطلاق ، حتى الغياب الكامل لنظام التشغيل الضيف.
تم تنفيذ هذا النهج من قبل فريق التطوير في عام 1999 في منتج VMware Workstation ، ثم في عام 2001 في برامج مراقبة خادم GSX (النوع الثاني ، مثل محطة العمل) و ESX (النوع الأول).

الظاهرية الافتراضية

Paravirtualization هو مفهوم بسيط للغاية ، والذي يفترض أن نظام التشغيل الضيف يعرف أنه في جهاز افتراضي ، ويعرف كيفية الوصول إلى نظام التشغيل المضيف لبعض وظائف النظام. — , .
x86 2003 Linux Xen.

, . , VMware ESXi SCSI PVSCSI, , . ( VMware Tools), Linux (open-vm-tools).

, .

— Intel VT-x AMD-V , , . .

2 (hosted)

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

: VMware Workstation / Fusion, Oracle VM VirtualBox, Parallels Desktop, VMware Server (ex-GSX), Microsoft Virtual Server 2005

1 (bare-metal)

, . , , -. -, . . x86 VMware ESX, 1+. “” VMware ESXi — ESX, RHEL.

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



العيب هنا هو برامج تشغيل الأجهزة: لضمان "ركاكة" النظام الأساسي والقضاء على المضاعفات غير الضرورية من إصدار إلى إصدار ، يتم تدوير برامج تشغيل الأجهزة ، مما يجعل البنية الأساسية المادية تعتمد على قائمة توافق الأجهزة (HCL).

النوع 1+ (Hybrid Hypervisor)

( 1+, 1a, 1.5) , (parent partition Microsoft Hyper-V) (domain dom0 Xen). , , . -.

, . : , ESXi, , HCL. , .

1+ :



تشمل برامج Hypervisors من هذا النوع: برامج VMware ESX المتوفاة ، و Microsoft Hyper-V ، و Hypervisor على Xen (تطبيقات Citrix XenServer و Xen في توزيعات Linux المختلفة). تذكر أن Citrix XenServer عبارة عن نظام تشغيل يستند إلى RHEL مبتوراً قليلاً ، وأن إصداره ووظائفه كانا يعتمدان بشكل مباشر على الإصدار الحالي من Red-Hat Enterprise Linux. في حالة تطبيقات Xen الأخرى ، لا يختلف الموقف كثيرًا: إنه نفس Linux kernel في وضع Xen Hypervisor ونظام التشغيل الأساسي في مجال dom0. هذا يؤدي إلى استنتاج لا لبس فيه أن برامج Hypervisor المستندة إلى Xen هي من النوع المختلط وليست برامج Hypervisor من النوع الأول.

التقنيات الرئيسية للمنصات الصناعية

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

جيش تحرير السودان

هذه مجموعة من التقنيات التي تؤثر بشكل أساسي على أداء اتفاقيات مستوى الخدمة للوصول (RPO / RTO).

HA

High Availability - تقنية لضمان توفر عالي لـ VMs في كتلة بواسطة hypervisor. في حالة وفاة المضيف ، تتم إعادة تشغيل VM تلقائيًا على المضيفين الباقين على قيد الحياة. تأثير: تقليل RTO قبل انقضاء مهلة HA + إعادة تشغيل OS / الخدمات.

FT

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

TCO

هذه مجموعة من التقنيات التي تؤثر بشكل أساسي على التكلفة الإجمالية للملكية.

vMotion

vMotion هي تقنية للترحيل المباشر لنقطة تنفيذ VM من مضيف كامل الوظائف إلى آخر. في الوقت نفسه ، تكون نقطة التبديل في نقطة التنفيذ أقل من مهلات اتصال الشبكة ، مما يسمح لنا بالنظر في الترحيل بشكل مباشر ، أي دون انقطاع في عمل الخدمات الإنتاجية. التأثير: تقليل نسبة الخطأ إلى العرض (RTO) إلى الصفر بسبب الانقطاعات المخططة لصيانة الخادم ، وبالتالي التخلص الجزئي من الانقطاعات نفسها.

تخزين vMotion

التخزين vMotion هي تقنية للانتقال المباشر لنقطة تخزين VM من وحدة تخزين كاملة الوظائف إلى أخرى. في الوقت نفسه ، لا يتوقف العمل مع نظام القرص ، مما يسمح بترحيل الترحيل. التأثير: تقليل نسبة الخطأ إلى العرض (RTO) إلى الصفر بسبب الانقطاعات المخططة لصيانة التخزين ، وبالتالي التخلص الجزئي من الانقطاعات نفسها.

DPM

إدارة الطاقة الموزعة - تقنية للتحكم في مستوى حمل المضيف وتشغيل / إيقاف تشغيل المضيفين مع تغير الحمل على الكتلة. يتطلب DRS لتشغيلها. التأثير: التخفيض الكلي في استهلاك الطاقة.

وزعت vSwitch

vSwitch الموزعة هي تقنية للإدارة المركزية لإعدادات شبكة مفاتيح تبديل المضيف الظاهري. التأثير: تقليل حجم وتعقيد العمل على إعادة تشكيل النظام الفرعي للشبكة ، وتقليل مخاطر الأخطاء.

EVC

التوافق المحسّن vMotion هو تقنية تسمح بإخفاء تعليمات المعالج المتوفرة لـ VMs في الوضع التلقائي. يتم استخدامه لمحاذاة عمل VMs في كتلة غير متساوية مع أقدم عائلة المعالج ، مما يوفر القدرة على ترحيل VMs إلى أي مضيف. التأثير: التوفير في تعقيد البنية التحتية مع زيادة السعة / تطوير المجموعات جزئيًا.

جودة الخدمة

هذه مجموعة من التقنيات التي تؤثر بشكل أساسي على أداء SLA من حيث جودة الخدمة.

vNUMA

vNUMA هي تقنية تتيح لنظام التشغيل الضيف التواصل مع طوبولوجيا NUMA الظاهري لـ VM للآلات الواسعة (عقدة vCPU أو vRAM> NUMA). التأثير: عدم وجود عقوبة على أداء برنامج التطبيق الذي يدعم NUMA.

تجمع الموارد

— . : , .

Limit / Reserve

/ , / .

DRS

Dynamic Resource Scheduler — . vMotion.

Storage IO Control

Storage IO control — , “ ”, , . — / .

Network IO Control

Network IO Control — , “ ”, .

Storage Integration (VAAI etc)

:

• / , .
• تكامل مستوى البروتوكول - VAAI ، ODX. تتيح لك هذه التقنيات إلغاء تحميل النظام الفرعي للقرص ، ونقل جزء من الحمل القياسي إلى التخلص من التخزين الذكي. على سبيل المثال ، تشتمل هذه الفئة على عمليات مثل كتل التصفير ، واستنساخ VMs ، إلخ. لهذا السبب ، يتم تفريغ القناة إلى نظام التخزين بشكل كبير ، ويقوم نظام التخزين نفسه بإجراء عمليات القرص بطريقة أكثر مثالية.

أمن

Microsegmentation

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

بلا وكيل AV

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

فرط الأنظمة المتقاربة

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

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

هندسة معمارية

مع الحفاظ على التقارب كمبدأ معماري ، نحصل على مزيج من نقطة التخزين ونقطة التنفيذ لـ VM في نظام واحد.

وبمعنى آخر ، تتضمن البنية المتقاربة استخدام نفس خدمات الأجهزة لتنفيذ كل من أجهزة VM وتخزينها على الأقراص المحلية. حسنًا ، بما أنه يجب أن يكون هناك تسامح مع الخطأ - في بنية متقاربة توجد طبقة من SDS الموزعة.

نحصل على:

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

, , . , .

— .
. , SDS. disaggregated HCI ( ). , , NetApp , . NetApp HCI ( 2019) — hybrid cloud infrastructure.

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

• 1. وحدة النواة. تعمل SDS كمتماسك في قلب برنامج hypervisor ، على سبيل المثال vSAN + ESXi
• 1.5 وحدة القسم الرئيسي. تعمل SDS كخدمة كجزء من القسم الأصل في برنامج hypervisor ، على سبيل المثال S2D + Hyper-V
• 2. الجهاز الظاهري. يتم تطبيق SDS كجهاز ظاهري مخصص على كل مضيف. Nutanix ، Cisco Hyperflex ، HPE Simplivity.

من الواضح ، بالإضافة إلى المشكلات التي تمت مناقشتها مع تأثير التضمين في الأداء ، هناك مشكلة مهمة جدًا تتمثل في عزل ودعم برامج مراقبة الجهات الخارجية. في الحالة 1 ، من الواضح أن هذا يمكن أن يكون نظامًا واحدًا فقط من مزود برنامج Hypervisor ، بينما يمكن أن يعمل 2 في أي برنامج مراقبة.

حاويات

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

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

VM حاوية

إيجابيات وسلبيات كلا النهجين بسيطة للغاية ومباشرة.

توفر المحاكاة الافتراضية الكاملة (VM) استقلالًا تامًا لمستوى الحديد ، بما في ذلك أنظمة التشغيل والشبكات وشبكات التخزين المستقلة تمامًا. من ناحية أخرى ، يتطلب كل تطبيق ، نظرًا لأننا نلتزم بالخادم 1 application = 1 server ، نظام التشغيل الخاص به ، وقرصه وشبكة الاتصال الخاصة به. أي هناك نفقات متعددة للموارد.

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

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

حاويات 0.1

الاستجذار

النموذج الأولي للحاويات في عام 1979 كان chroot.

"Chroot هي عملية تغيير الدليل الجذر على أنظمة التشغيل المشابهة لـ Unix. لا يمكن لأي برنامج تم إطلاقه باستخدام دليل جذر معدل إلا الوصول إلى الملفات الموجودة في هذا الدليل. "

أي في الواقع ، تكون العزلة على مستوى نظام الملفات فقط ، وإلا فهي مجرد عملية عادية في نظام التشغيل.

السجن فري

وكان السجن الأكثر تقدماً بشكل ملحوظ هو السجن من مرض BSD المجاني ، والذي ظهر عام 1999. سمح لك Jail بإنشاء مثيلات OS افتراضية كاملة مع مجموعاتها الخاصة من التطبيقات وملفات التكوين على أساس FreeBSD. بالتأكيد هناك من يقول - وماذا يفعل السجن في الحاويات ، لأن هذا هو الافتراض الافتراضي! وسوف تكون على حق جزئيا.

ومع ذلك ، قبل افتراضية كاملة (ومتغير في شكل parav افتراضية) السجن تفتقر إلى القدرة على تشغيل نواة إصدار مختلف في الضيف VM والتكتل مع هجرة VM إلى نظام مضيف آخر.

سولاريس المناطق

Solaris Zones هي تقنية للمحاكاة الافتراضية لنظام التشغيل (المحاكاة الافتراضية للحاويات) ، تم تقديمها في عام 2004 في Sun Solaris. المبدأ الأساسي هو انخفاض الحمل الافتراضي.

لم يكتسب شعبية كبيرة ، تم ترحيله إلى OpenSolaris والتوزيعات بناءً عليه ، وهو متاح في عام 2019.

حاويات 1.0

في عصر الحاويات 1.0 ، ظهر اتجاهان رئيسيان للحاويات - وهما منتجات تجارية لموفري الاستضافة ، وتطبيقات الحاويات.

Virtuozzo / OpenVZ

قدمت SWSoft الروسية في عام 2001 نسختها الأولى من Virtuozzo للحاوية الافتراضية ، والتي تهدف إلى سوق مقدمي الاستضافة. نظرًا للتصميم والجمهور المستهدف التجاري المحدد ، فقد أصبح المنتج ناجحًا للغاية واكتسب شعبية. من الناحية التكنولوجية ، في عام 2002 ، تم عرض التشغيل المتزامن لـ 2500 حاوية على خادم 8 معالجات.

في عام 2005 ، ظهرت نسخة مفتوحة من حاويات Virtuozzo لنظام Linux تسمى OpenVZ. وأصبحت تقريبًا المعيار الذهبي لاستضافة VPS.

ال إكس سي

LinuX Containers (LXC) هي محاكاة افتراضية أخرى معروفة للحاويات تعتمد على مساحات الأسماء ومجموعات cgroups ، والتي ظهرت في عام 2008. إنها تكمن وراء عمال الإرساء الشائعين حاليًا ، إلخ.

حاويات 1.1 (التطبيق الظاهري)

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

التطبيق-V

Microsoft Application Virtualization (App-V) ، المعروفة سابقًا باسم Softricity SoftGrid - تقنية حاويات لتطبيقات معينة (الحاوية هي العكس) في صندوق حماية معزول ، ثم Microsoft. في عام 2006 ، استحوذت شركة Microsoft على Softricity بدء التشغيل ، والتي حولت الحاوية بالفعل.

ThinApp

VMware ThinApp (المعروف سابقًا باسم Thinstall) هو أحد منتجات حاويات التطبيقات من Jilt التي حصلت عليها VMware في عام 2008. تقدر VMware أن 90-95 ٪ من جميع التطبيقات المعبأة في العالم تستخدم هذه التكنولوجيا.

حاويات 2.0

يرتبط تاريخ ظهور الحاويات 2.0 ارتباطًا كبيرًا بالتغيير في عملية تطوير البرامج. أرغبت رغبة الشركة في الحد من مثل هذه المعلمة المهمة مثل Time-to-market للمطورين على إعادة النظر في أساليب إنشاء منتجات البرمجيات. يتم استبدال منهجية تطوير الشلال (دورات الإطلاق الطويلة ، يتم تحديث التطبيق بالكامل) بواسطة Agile (دورات إطلاق قصيرة وقصيرة المدة ، يتم تحديث مكونات التطبيق بشكل مستقل) ويفرض على المطورين فصل التطبيقات المتجانسة إلى مكونات. في حين أن مكونات التطبيقات المتجانسة لا تزال كبيرة جدًا ولا يوجد الكثير منها يمكن وضعها في أجهزة افتراضية ، ولكن عندما يتكون أحد التطبيقات من عشرات أو مئات المكونات ، فإن الأجهزة الافتراضية لم تعد مناسبة جدًا. بالإضافة إلى ذلك ، تنشأ مشكلة إصدارات البرامج المساعدة والمكتبات والتبعيات أيضًا ، غالبًا ما يكون هناك موقف عندما تتطلب المكونات المختلفة إصدارات مختلفة أو متغيرات البيئة التي تم تكوينها بشكل مختلف. هذه المكونات يجب أن توزع على أجهزة افتراضية مختلفة ، لأن يكاد يكون من المستحيل تشغيل إصدارات متعددة من البرنامج في نفس نظام التشغيل في وقت واحد. يبدأ عدد VM في النمو مثل انهيار جليدي. هنا ، تظهر الحاويات على المسرح ، مما يسمح في إطار نظام التشغيل الضيف بإنشاء عدة بيئات معزولة لتشغيل مكونات التطبيق. تتيح لك حاويات التطبيقات الاستمرار في تجزئة تطبيق مترابط إلى مكونات أصغر حجمًا والانتقال إلى نموذج مهمة واحدة = مكون واحد - حاوية ، وهذا ما يسمى نهج الخدمة المجهرية ، وكل مكون من هذه المكونات عبارة عن خدمة microservice.

حاوية تحت غطاء محرك السيارة

إذا نظرت إلى الحاوية بنظرة خاطفة من مسؤول النظام ، فهذه مجرد عمليات Linux لها منافذ خاصة بها ، إلخ. ما الذي يجعل من الممكن عزل العمليات الجارية في الحاويات عن بعضها البعض واستهلاك موارد نظام التشغيل الضيف معًا؟ يوجد آليتان عاديتان موجودتان في نواة أي توزيع Linux حديث. الأول ، Linux Namespaces ، والذي يضمن أن ترى كل عملية تمثيل نظام التشغيل الخاص بها (نظام الملفات ، واجهات الشبكة ، واسم المضيف ، وما إلى ذلك) والثانية ، Linux Control Groups (cgroups) ، التي تقصر العملية على استهلاك موارد نظام التشغيل الضيف (CPU ، ذاكرة عرض النطاق الترددي للشبكة ، وما إلى ذلك).

مساحات أسماء Linux

افتراضيًا ، يحتوي كل نظام Linux على مساحة اسم واحدة. جميع موارد النظام ، مثل أنظمة الملفات ، ومعرفات العملية (معرفات العملية) ، ومعرفات المستخدم (معرفات المستخدم) ، واجهات الشبكة تنتمي إلى مساحة الاسم هذه. ولكن لا أحد يمنعنا من إنشاء مساحات أسماء إضافية وإعادة توزيع موارد النظام بينهما.

عند بدء عملية جديدة ، تبدأ في مساحة اسم أو معيار نظام أو واحدة من تلك التي تم إنشاؤها. وستشاهد هذه العملية فقط الموارد المتاحة في مساحة الاسم المستخدمة لتشغيلها.

ولكن ليس كل شيء بهذه البساطة ، فكل عملية لا تنتمي إلى مساحة اسم واحدة ، ولكن إلى مساحة اسم واحدة في كل فئة من الفئات:

• جبل (mnt)
• معرف العملية (معرف المنتج)
• الشبكة (صافي)
• التواصل بين العمليات (ipc)
• UTS
• معرف المستخدم (المستخدم)

يعزل كل نوع من مساحة الاسم مجموعة موارد مقابلة. على سبيل المثال ، تحدد مساحة UTS اسم المضيف واسم المجال المرئي للعمليات. وبالتالي ، يمكن أن تفترض عمليتان داخل نظام التشغيل الضيف أنهما تعملان على خوادم مختلفة.

تحدد مساحة اسم الشبكة رؤية واجهات الشبكة ، وستشاهد العملية بداخلها فقط الواجهات التي تنتمي إلى مساحة الاسم هذه.

مجموعات التحكم في Linux (cgroups)

مجموعات التحكم في Linux (cgroups) هي آلية نظام kernel (Kernel) لأنظمة Linux التي تحد من استهلاك موارد النظام من خلال العمليات. لن تتمكن كل عملية أو مجموعة من العمليات من الحصول على مزيد من الموارد (وحدة المعالجة المركزية والذاكرة وعرض النطاق الترددي للشبكة ، وما إلى ذلك) مما تخصص ، ولن تتمكن من الحصول على الموارد "الأخرى" - موارد العمليات المجاورة.

عامل ميناء

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

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

أنشأ Docker نظامًا بيئيًا لإنشاء وتخزين ونقل وإطلاق الحاويات. هناك ثلاثة مكونات رئيسية لعالم Docker:

• الصور - صورة ، هذا هو الكيان الذي يحتوي على التطبيق الخاص بك ، والبيئة الضرورية والبيانات الوصفية الأخرى اللازمة لتشغيل الحاوية ؛
• سجلات - مستودع ، مكان تخزين لصور عامل الميناء. هناك مجموعة متنوعة من المستودعات ، بدءًا من الموقع الرسمي - hub.docker.com وتنتهي مع المستودعات الخاصة المنتشرة في البنية التحتية للشركة ؛
• حاويات - حاوية ، حاوية Linux تم إنشاؤها من صورة Docker. كما ذكر أعلاه ، هذه عملية Linux تعمل على نظام Linux مع تثبيت Docker ، بمعزل عن العمليات الأخرى ونظام التشغيل نفسه.

النظر في دورة حياة الحاوية. في البداية ، يقوم المطور بإنشاء صورة Docker مع تطبيقه (أمر docker build) ، تمامًا من نقطة الصفر أو استخدام الصور التي تم إنشاؤها بالفعل كأساس (تذكر حول الطبقات). علاوة على ذلك ، يمكن للمطور إطلاق هذه الصورة مباشرة على الجهاز الخاص به أو يمكن نقلها إلى جهاز آخر - الخادم. من أجل قابلية النقل ، غالبًا ما يتم استخدام مستودعات التخزين (أمر docker push) - يتم تحميل الصورة في المستودع. بعد ذلك ، يمكن تنزيل الصورة إلى أي جهاز أو خادم آخر (سحب عامل ميناء). أخيرًا ، قم بإنشاء حاوية عمل (تشغيل عامل ميناء) من هذه الصورة.

Kubernetes

كما قلنا من قبل ، فإن مفهوم الخدمات الميكروية يعني تقسيم تطبيق متجانسة إلى العديد من الخدمات الصغيرة ، وعادة ما تؤدي وظيفة واحدة. حسنًا ، عند وجود العشرات من هذه الخدمات ، لا يزال من الممكن إدارتها يدويًا من خلال Docker على سبيل المثال. ولكن ماذا تفعل عندما يكون هناك المئات والآلاف من هذه الخدمات؟ بالإضافة إلى البيئة الصناعية ، فأنت بحاجة إلى بيئة اختبار وبيئات إضافية للإصدارات المختلفة من المنتج ، أي اضرب ب 2 أو 3 أو أكثر. واجهت Google أيضًا نفس المشكلات ، فقد كان مهندسوها من أوائل من استخدم الحاويات على نطاق صناعي. لذا وُلد Kubernetes (K8s) ، وتم إنشاؤه تحت اسم Borg في جدران منتج Google ، وتم إعطاؤه لاحقًا لعامة الناس وتمت إعادة تسميته.

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

نظرًا لأن هذه المقالة مخصصة أساسًا لمهندسي المحاكاة الافتراضية ، لفهم عام لمبادئ التشغيل والمكونات الرئيسية لـ K8s ، نوصيك بقراءة المقال الذي يرسم التوازي بين K8s و VMware vSphere: https://medium.com/medium.com/pryalukhin/kubernetes-introduction-for-vmware- المستخدمين 232cc2f69c58

X86 تاريخ المحاكاة الصناعية

في إم وير

ظهرت VMware في عام 1998 ، بدءًا من تطوير نوع ثانٍ من برنامج hypervisor ، والذي أصبح فيما بعد يعرف باسم VMware Workstation.

دخلت الشركة سوق الخوادم في عام 2001 من خلال اثنين من المشرفين - GSX (Ground Storm X ، النوع الثاني) و ESX (Flex Sky X ، النوع الأول). بمرور الوقت ، أصبحت احتمالات النوع الثاني في تطبيقات الخوادم واضحة ، أي لا. وتحولت GSX المدفوعة أولاً إلى خادم VMware مجاني ، ثم توقفت بالكامل ودُفنت.

في عام 2003 ، ظهر نظام الإدارة المركزية لـ Virtual Center وتكنولوجيا vSMP والترحيل المباشر للأجهزة الافتراضية.

في عام 2004 ، تم الحصول على VMware بواسطة شركة EMC ، عملاق التخزين ، لكنها تركت عملياتها مستقلة.

في عام 2008 ، أصبح VMware المعيار الفعلي للصناعة ، وحفز النمو السريع للعروض التنافسية - Citrix ، Microsoft ، وما إلى ذلك. أصبح من الواضح الحاجة إلى الحصول على نسخة مجانية من برنامج hypervisor ، وهو أمر مستحيل - كقسم رئيسي في ESX ، تم استخدام RHEL تجاري بالكامل. حصل مشروع استبدال RHEL بشيء أسهل ومجاني على تنفيذه في عام 2008 بنظام busbox. والنتيجة هي ESXi ، المعروفة للجميع اليوم.

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

Connectix

تأسست Connectix في عام 1988 ، وعملت على مجموعة متنوعة من أدوات النظام المساعدة حتى استغرق الأمر بالمحاكاة الافتراضية. في عام 1997 ، تم إنشاء أول منتج VirtualPC لماكنتوش Apple ، مما يسمح بتشغيل Windows في جهاز ظاهري. ظهر الإصدار الأول من VirtualPC لـ Windows في عام 2001.

في عام 2003 ، اشترت Microsoft VirtualPC ، ومن خلال الاتفاق مع Connectix ، تحول المطورون إلى Microsoft. بعد ذلك ، أغلقت Connectix.

تم تطوير تنسيق VHD (القرص الثابت الافتراضي) بواسطة Connectix for VirtualPC ، وكتذكير ، تحتوي الأقراص الافتراضية لأجهزة Hyper-V على "conectix" في توقيعها.
الكمبيوتر الشخصي VIrtual ، كما تعتقد ، هو برنامج مراقبة سطح مكتب كلاسيكي من النوع الثاني.

مايكروسوفت

بدأت رحلة Microsoft إلى المحاكاة الافتراضية الصناعية بشراء Connectix وإعادة تسمية Connectix Virtual PC في Microsoft Virtual PC 2004. تم تطوير Virtual PC لفترة من الوقت تحت اسم Windows Virtual PC في Windows 7. في Windows 8 والإصدارات الأحدث ، تم استبدال Virtual PC بـ نسخة سطح المكتب من Hyper-V.

استنادًا إلى Virtual PC ، تم إنشاء برنامج مراقبة خادم Virtual Server ، والذي كان موجودًا حتى بداية عام 2008. نظرًا للخسارة التكنولوجية الواضحة قبل برنامج VMware ESX ، فقد تقرر الحد من تطوير النوع الثاني من برنامج Hypervisor لصالح النوع الأول من برنامج Hypervisor الذي أصبح Hyper-V. هناك رأي غير رسمي في الصناعة مفاده أن Hyper-V يشبه بشكل مدهش Xen في الهندسة المعمارية. تقريبا نفس. الصافية في جافا.

"بالطبع ، قد تعتقد أن مايكروسوفت سرقت فكرة جافا." لكن هذا غير صحيح ، ألهمتها مايكروسوفت! - (من خطاب ألقاه ممثل مايكروسوفت في عرض خادم ويندوز 2003)

منذ اللحظات الغريبة ، تجدر الإشارة إلى أن استخدام منتجات المحاكاة الافتراضية الاحتكارية في Microsoft خلال السنوات الصفرية كان داخل Microsoft أمرًا معتدلًا اختياريًا. توجد لقطات شاشة لـ Technet من مقالات حول الظاهرية ، حيث يوجد شعار أدوات VMware بوضوح في الدرج. أيضًا ، أجرى مارك روسينوفيتش في منصة 2009 في موسكو مظاهرة مع محطة عمل VMware.

في محاولة للدخول إلى أسواق جديدة ، أنشأت Microsoft سحابة عامة خاصة بها ، وهي Azure ، باستخدام خادم Nano Server المعدل للغاية مع دعم Hyper-V و S2D و SDN كمنصة. تجدر الإشارة إلى أنه في البداية ، كانت أزور في بعض النقاط متخلفة عن الأنظمة الداخلية. على سبيل المثال ، ظهر دعم الأجهزة الظاهرية من الجيل الثاني (مع دعم Secure Boot ، والتمهيد من أقسام GPT ، والتمهيد PXE ، وما إلى ذلك) في Azure فقط في عام 2018. أثناء وجوده في موقع العمل ، تُعرف أجهزة VM من الجيل الثاني منذ Windows Server 2012R2. ينطبق الأمر نفسه على حلول portal: حتى عام 2017 ، استخدم كل من Azure و Windows Azure Pack (حل سحابة Multi-Tenancy مع دعم SDN و Shielded VM ، والذي حل محل System Center App Controller في 2013) نفس تصميم البوابة. بعد أن أعلنت Microsoft عن دورة تدريبية حول السحب العامة ، تقدمت Azure إلى الأمام لتطوير وتنفيذ المعرفة المختلفة. في حوالي عام 2016 ، يمكنك مشاهدة صورة منطقية تمامًا: الآن تأتي جميع الابتكارات في Windows Server من Azure ، ولكن ليس في الاتجاه المعاكس. تشير حقيقة نسخ أجزاء من الوثائق من Azure إلى فرضية "كما هي" (انظر الوثائق الخاصة بـ Azure SDN و Network Controller) إلى هذا ، والذي يشير من ناحية إلى الحلول القائمة على الحلول المنطقية ، ومن ناحية أخرى ، يشير إلى علاقة الحلول من حيث الكيانات والهندسة المعمارية. الذي نسخ من ومن كيف هو حقا - سؤال قابل للنقاش.

في مارس 2018 ، أعلن Satya Nadela (الرئيس التنفيذي لشركة Microsoft) رسميًا أن السحابة العامة أصبحت أولوية الشركة. الذي ، من الواضح ، يرمز إلى الطي والتلاشي التدريجي لخط الخادم للمنتجات المحلية (ومع ذلك ، لوحظ الركود مرة أخرى في عام 2016 ، ولكن تم تأكيده مع الإصدار التجريبي الأول من Windows Server وخطوط الإنتاج المحلية الأخرى) ، باستثناء Azure Edge - الحد الأدنى المطلوب للخادم البنية التحتية في مكتب العميل للخدمات التي لا يمكن نقلها إلى السحابة.

الحديد الظاهري

منذ تأسيسها عام 2003 ، قدمت Virtual Iron إصدارًا تجاريًا من Xen وكانت واحدة من أوائل الشركات التي قدمت الدعم الكامل للمحاكاة الافتراضية للأجهزة.
في عام 2009 ، تم تولي أوراكل لتطوير خطها الخاص من أوراكل VM وتوسيعه على x86. قبل ذلك ، تم تقديم Oracle VM فقط على نظام SPARC.

Innotek

في أوائل عام 2007 ، أصدرت Innotek GmbH برنامج Hypervisor لأجهزة الكمبيوتر المكتبية من النوع الثاني ، VirtualBox ، وهو مجاني للاستخدام غير التجاري. في نفس العام ، تم إصدار نسخة مفتوحة المصدر.

في عام 2008 ، استحوذت عليها شركة Sun ، والتي بدورها حصلت عليها شركة أوراكل. حافظت Oracle على الاستخدام المجاني للمنتج لأغراض غير تجارية.
يدعم VirtualBox ثلاثة تنسيقات للأقراص الافتراضية - VDI (أصلي) ، VMDK (VMware) ، VHD (Microsoft). كما المضيف OS ، ويندوز ، ماك ، لينكس ، سولاريس و OpenSolaris معتمدة. ومن المعروف أن شوكة VirtualBox ل FreeBSD.

IBM

يُعد الكمبيوتر الرئيسي هو الكمبيوتر الرئيسي لمركز البيانات الذي يحتوي على كمية كبيرة من الذاكرة الداخلية والخارجية (كمرجع: في الستينيات ، تم اعتبار 1 ميغابايت من الذاكرة كبيرة بشكل غير واقعي). في الواقع ، كان الحاسوب المركزي مركزًا للحوسبة: احتلت أجهزة الكمبيوتر الأولى غرفًا كاملة الجهاز ، وكانت تتكون من رفوف ضخمة. في هذه الأيام يطلق عليه مراكز البيانات. ولكن في مراكز البيانات الموجودة في نفس غرفة الآلة ، يمكن أن يكون الآلاف من أجهزة الكمبيوتر ، وفي فجر تكنولوجيا الحوسبة ، شغل كمبيوتر واحد غرفة بأكملها. باع كل رف جهاز كمبيوتر واحد (!) (رفوف منفصلة بها ذاكرة ، ورفوف منفصلة مزودة بأجهزة تخزين ، وأجهزة طرفية منفصلة). كان جوهر هذه الآلة الضخمة هو حامل مع معالج - كان يطلق عليه الرئيسي ، أو المركزية.بعد الانتقال إلى الدوائر المتكاملة للترانزستور ، انخفض حجم هذه المعجزة من الفكر العلمي والهندسي إلى حد كبير ، وبدأ فهم الإطار الرئيسي لشركة IBM ونظائرها على أنه الإطار الرئيسي.

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

IBM IBM System/360-67. CP/CMS , , . CP (Control Program) – , « » (VM). CMS ( – Cambridge Monitor System, Conversational Monitor System) . , CMS z/VM. , 90- ( , ) Time-Sharing. , – , . , , .

CP/CMS VM/370 System/370 2 1972 . – VM, VM IBM. , ( ) – VM/370. : () System/370 VM/370 ( ! – ). .

80- « ». VM , . , VM. (Logical Partition Access Resources LPAR), . , - VM, LPAR VM . - , . , VM , 80-:

VM/SP – System z
VM/SP HPO (High Performance Option) – VM/SP System z
VM/XA (extended architecture) – VM S/370.

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

Linux Xen

Xen (zen prenounced zen) هو برنامج hypervisor تم تطويره في مختبر الكمبيوتر بجامعة كامبريدج تحت إشراف Ian Pratt وتم توزيعه تحت رخصة GPL. ظهرت النسخة العامة الأولى في عام 2003. بعد ذلك ، واصل إيان العمل على برنامج Hypervisor في نسخته التجارية ، حيث أسس الشركة XenSource.
في عام 2013 ، خضع Xen لسيطرة Linux Foundation.

XenSource

بعد أن كانت موجودة لعدة سنوات في السوق مع منتجات XenServer و XenEnterprise ، في نهاية عام 2007 تم شراؤها بواسطة Citrix.

سيتريكس XenServer

XenSource 500 , Citrix . , , XenServer , . VMware ESX XenServer 2009 . XenCenter .
Citrix Microsoft , , .

, Citrix XenApp XenDesktop Xen.

Amazon

Amazon IaaS EC2 (Elastic Compute) 2006 . EC2 Xen, Amazon , , .

2017 EC2 KVM . , EC2 KVM .

Linux QEMU / KVM

QEMU (Quick EMUlator) — , GPL v2. x86 ARM, MIPS, RISC-V, PowerPC, SPARC, SPARC64. QEMU , . QEMU x86 , KVM (Kernel-based Virtual Machine) Qumranet.

KVM — QEMU KVM, qcow2 (QEMU copy-on-write 2) KVM.
, QEMU , QEMU / KVM .

Qumranet

شركة إسرائيلية ، مطور سابق وراعي رئيسي لبرنامج KVM hypervisor وبروتوكول SPICE. تأسست في عام 2005 ، اكتسبت شهرة بعد دمج KVM في نواة لينكس. 4 سبتمبر 2008 ، حصلت عليها ريد هات.

قبعة حمراء

GNU/Linux, 2010 Red Hat Xen. , , . , KVM. Red Hat Enterprise Virtualization 2.2 (RHEV) 2010 VDI Citrix VMware Qumranet, . , Live Migration, 2 ( RHEL). , , Red Hat Xen .

28 2018 IBM Red Hat.

OpenStack

OpenStack - VMware x86. 2010 Rackspace Hosting ( ) NASA ( Nebula). , 2012 VMware OpenStack, -.

Canonical (Ubuntu Linux), Debian, SUSE, Red Hat, HP, Oracle.

. 2012 NASA , AWS. 2016 HPE Helion OpenStack.

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

هناك مجموعة واسعة من الآراء المتعلقة بمشروع OpenStack ، من العبادة المتحمسة إلى الشكوك الخطيرة والنقد الشديد. النقد ليس بدون سبب - تم تسجيل عدد كبير من المشاكل وفقدان البيانات عند استخدام OpenStack. وهذا ، مع ذلك ، لا يمنع المعجبين من إنكار كل شيء والإشارة إلى الانحناء في تنفيذ الأنظمة وتشغيلها.

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

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

Nutanix AHV

Nutanix VMware vSphere. - , - VMware , . KVM, AHV (Acropolis HyperVisor).

المتوازيات

7 Virtuozzo KVM.

Proxmox

Proxmox VE (بيئة افتراضية) هو مشروع مفتوح المصدر لشركة Proxmox Server Solutions GmbH النمساوية مقرها في دبيان لينكس. كان الإصدار الأول في عام 2008.
يدعم المنتج المحاكاة الافتراضية للحاوية LXC (OpenVZ سابقًا) ، والمحاكاة الافتراضية الكاملة مع برنامج مراقبة KVM.

يوازي / Virtuozzo / Rosplatform

1999 SWsoft . 2003 - Plesk.

2004 SWsoft Parallels Parallels Workstation ( Windows).
Parallels Parallels Desktop Mac ( MacOS).

, . Virtuozzo OpenVZ, . Parallels Parallels Bare Metal Server ( Parallels Hypervisor Cloud Server, Virtuozzo), Cloud Storage. .

في عام 2015 ، على أساس منتجات المحاكاة الافتراضية للخوادم ، تم إنشاء مشروع النظام الأساسي لـ Rosplatform - من الناحية الفنية (حذف الجوانب القانونية والتنظيمية) نفس Virtuozzo ، فقط مع خلفيات معدلة وفي سجل البرنامج الروسي. استنادًا إلى برنامج النظام الأساسي Rosplatform ومعدات Depo ، تنشئ IBS عرضًا عالي الحزم لحزمة Scala-R.

قبل الإصدار 7 ، كان Virtuozzo يستخدم برنامج Hypervisor لتصميمه الخاص ؛ وفي الإصدار 7 ، تم الانتقال إلى KVM. وفقًا لذلك ، تعتمد Rosplatform أيضًا على KVM.
بعد العديد من عمليات الدمج والاستحواذ والعلامات التجارية ، تم تشكيل الصورة التالية بحلول عام 2019.

Parallels Desktop هي شركة تابعة لـ Parallels وتباع إلى Corel. ذهبت جميع الأتمتة إلى أودين وبيعها إلى IngramMicro. ظلت المحاكاة الافتراضية للخادم تحت العلامة التجارية لمنصة Virtuozzo / Rosplatform.