لفترة طويلة ، استخدمت شركة Maxnet Systems الإصدار المجاني من VMware - ESXi ، بدءًا من الإصدار 5.0 ، كمشرف. النسخة المدفوعة من vSphere خائفة من نموذج الترخيص ، في حين أن الإصدار المجاني كان له عدد من العيوب التي لم تكن متوفرة في النسخة المدفوعة ، ولكن يمكنك تحملها. ولكن عندما رفضت واجهة الويب الجديدة في الإصدارات الجديدة من ESXi العمل مع الواجهة القديمة ، وتوقف رصد صفائف RAID لإظهار علامات على الحياة ، قررت الشركة البحث عن حل أكثر عالمية وانفتاحًا. الشركة لديها بالفعل تجربة جيدة وانطباع جيد عن LXC - Linux Containers. لذلك ، أصبح من الواضح أن برنامج hypervisor للأحلام سوف يكون مختلطًا ويجمع بين KVM و LXD للأحمال المختلفة - استمرار تطوري لـ LXC. تبحث عن معلومات عن KVM ، واجهت الشركة مفاهيم خاطئة ، وأشعل النار والممارسات الضارة ، ولكن الاختبارات والوقت وضع كل شيء في مكانه.
حول كيفية التعامل مع الانتقال من ESXi إلى KVM وعدم قيادة عجلة على أشعل النار ، سوف يخبر
Lev Nikolaev (
maniaque ) - مدير ومطور الأنظمة المحملة للغاية ، ومدرب تكنولوجيا المعلومات. دعونا نتحدث عن الشبكة ، والمستودعات ، والحاويات ، KVM ، LXD ، LXC ، التوفير ، والأجهزة الظاهرية المريحة.
فاتحة
سنقوم على الفور بتحديد الأفكار الرئيسية ، ومن ثم سنحللها بمزيد من التفاصيل.
الشبكة. في حين أن سرعات واجهاتك لا تتجاوز 1 جيجابت / ثانية ، فإن الجسر يكفي لك. بمجرد رغبتك في الضغط أكثر - سيحدك.
التخزين. إنشاء شبكة تخزين مشتركة. حتى إذا لم تكن مستعدًا لاستخدام 10 جيجابت / ثانية داخل الشبكة ، فستوفر لك حتى 1 جيجابت / ثانية سعة تخزين تبلغ 125 ميجابايت / ثانية. بالنسبة لعدد من الأحمال ، سيكون هذا كافيًا بهامش ، وستكون هجرة الأجهزة الظاهرية أمرًا أساسيًا.
حاوية أو KVM؟ إيجابيات ، سلبيات ، المزالق. ما هي أنواع الأحمال التي يتم وضعها بشكل أفضل في الحاوية وما هي الأحمال الأفضل تركها في KVM؟
LXD أو LXC . هو LXD LXC؟ أو نسخة أخرى؟ أو وظيفة إضافية؟ ما هذا كله؟ دعونا نبدد الخرافات ونفهم الاختلافات بين LXD و LXC.
توفير مريحة . ما هو أكثر ملاءمة: التقاط نفس الصورة أو تثبيت النظام من نقطة الصفر في كل مرة؟ كيف نفعل ذلك بسرعة وبدقة في كل مرة؟
آلة افتراضية مريحة. سيكون هناك قصص مخيفة حول محمل الإقلاع ، الأقسام ، LVM.
متفرقات . العديد من الأسئلة الصغيرة: كيف تسحب بسرعة الجهاز الظاهري من ESXi إلى KVM ، وكيف تهاجر بشكل جيد ، وكيفية محاكاة الأقراص بشكل صحيح؟
سبب النقل
من أين حصلنا على فكرة مجنونة بالانتقال من ESXi إلى KVM / LXD؟ ESXi تحظى بشعبية كبيرة بين الشركات الصغيرة والمتوسطة. هذا هو برنامج مراقبة جيد ورخيص. ولكن هناك فروق دقيقة.
لقد بدأنا بالإصدار 5.0 - مريح ، كل شيء يعمل! الإصدار التالي 5.5 هو نفسه.
منذ الإصدار 6.0 أصبح الأمر أصعب. على ESXi ، لم تصبح واجهة الويب مجانية على الفور ، إلا من الإصدار 6.5 ، قبل أن تكون هناك حاجة إلى أداة مساعدة لنظام Windows. وضعنا هذا. الذي يدير OS X يشتري Parallels ويثبت هذه الأداة. هذا ألم معروف.
رصد تومض بشكل دوري. كان من الضروري إعادة تشغيل خدمات الإدارة في وحدة تحكم الخادم - ثم ظهر CIM Heartbeat مرة أخرى. لقد تحملنا ، لأنه لم يسقط دائمًا.
ESXi 6.5 الإصدار - القمامة ، النفايات والفظائع. المشرف فظيعة. وهنا السبب.
- الزاوي يقع خارج مع استثناء عند مدخل واجهة الويب. بمجرد إدخال اسم المستخدم وكلمة المرور الخاصة بك - على الفور استثناء!
- لا تعمل القدرة على مراقبة حالة صفيف RAID عن بُعد لأنها ملائمة لنا. كانت مريحة ، ولكن في الإصدار 6.5 ، كل شيء سيء.
- دعم ضعيف لبطاقات الشبكة الحديثة من Intel . بطاقات الشبكة من Intel و ESXi تسبب الألم. هناك خيط مؤلم في منتدى دعم ESXi حول هذا الموضوع. VMware و Intel ليسوا أصدقاء ولن تتحسن العلاقات في المستقبل القريب. الشيء المحزن هو أنه حتى عملاء الحلول المدفوعة يواجهون مشكلات.
- لا الهجرة داخل ESXi . ما لم يُعتبر الترحيل إجراءً مؤقتًا ، انسخ وبدء الإجراء. نوقف السيارة مؤقتًا وننسخها بسرعة ونبدأ تشغيلها في مكان آخر. ولكن من المستحيل تسميتها الهجرة - لا يزال هناك واحدة بسيطة.
بعد النظر في كل هذا ، حصلنا على فكرة مجنونة بالتحرك مع ESXi 6.5.
قائمة الأمنيات
بادئ ذي بدء ، كتبنا قائمة أمنيات لمستقبل مثالي سنذهب إليه.
إدارة من SSH ، والويب وأكثر اختياري. تعد واجهة الويب رائعة ، ولكن في رحلة عمل من iPhone ، انتقل إلى واجهة ويب ESXi وفعل شيء هناك غير مريح وصعب. لذلك ، فإن الطريقة الوحيدة لإدارة كل شيء هي SSH ، ولن يكون هناك شيء آخر.
ويندوز الافتراضية. في بعض الأحيان يطلب العملاء أشياء غريبة ، ومهمتنا هي مساعدتهم.
دائما برامج تشغيل جديدة والقدرة على تكوين بطاقة الشبكة . رغبة كافية ، ولكن غير محققة تحت ESXi النقي.
الهجرة الحية ، وليس التجميع . نحن نريد القدرة على سحب الآلات من برنامج Hypervisor إلى آخر دون الشعور بأي تأخير أو توقف أو إزعاج.
قائمة الأمنيات جاهزة ، ثم بدأ البحث الصعب.
دقيق الاختيار
يدور السوق حول KVM أو LXC مع الصلصات المختلفة. في بعض الأحيان يبدو أن Kubernetes في مكان ما أعلاه ، حيث كل شيء على ما يرام ، والشمس والجنة ، وعلى المستوى أدناه هناك Morlocks - KVM ، Xen أو شيء من هذا القبيل ...
على سبيل المثال ، Proxmox VE هو Debian ، والذي تم سحبه بواسطة kernel من Ubuntu. يبدو غريبًا ، لكن هل يصل به إلى الإنتاج؟
جيراننا في الطابق السفلي هم Alt Linux. توصلوا إلى حل جميل: وضعوا Proxmox VE كحزمة. لقد وضعوا الحزمة في أمر واحد. هذا مناسب ، لكننا لا نضع Alt Linux في الإنتاج ، لذلك لم يناسبنا.
خذ KVM
في النهاية ، اخترنا KVM. لم يأخذوها ، Xen ، على سبيل المثال ، بسبب المجتمع - KVM لديها أكثر من ذلك بكثير. يبدو أننا سنجد دائمًا الإجابة على سؤالنا. اكتشفنا لاحقًا أن حجم المجتمع لا يؤثر على جودته.
في البداية ، حسبنا أننا سوف نأخذ آلة Bare Metal ، ونضيف Ubuntu التي نعمل معها ، ونلف KVM / LXD من أعلى. اعتمدنا على القدرة على تشغيل الحاويات. Ubuntu هو نظام مشهور ولا توجد مفاجآت من حيث حل مشكلات التمهيد / الاسترداد بالنسبة لنا. نحن نعرف من أين نركل إذا لم يبدأ برنامج Hypervisor. كل شيء واضح ومريح بالنسبة لنا.
دورة تحطم KVM
إذا كنت من عالم ESXi ، فستجد الكثير من الأشياء المثيرة للاهتمام. تعلم ثلاث كلمات: QEMU ، KVM ، و libvirt.
تقوم QEMU بترجمة رغبات نظام التشغيل الافتراضي إلى تحديات العملية المنتظمة. يعمل بشكل رائع في كل مكان تقريبًا ، ولكن ببطء. QEMU بحد ذاته منتج مستقل يعمل على حفنة من الأجهزة الأخرى.
علاوة على ذلك ، تأتي مجموعة من
QEMU-KVM . هذه هي وحدة Linux kernel لنظام QEMU. يعد إضفاء الطابع الافتراضي على جميع الإرشادات مكلفًا ، لذلك لدينا وحدة KVM للنواة التي
تترجم بعض الإرشادات فقط . ونتيجة لذلك ، يكون هذا أسرع بكثير ، لأنه تتم معالجة بضعة بالمائة فقط من الإرشادات الواردة من المجموعة العامة. هذا هو كل تكاليف الافتراضية.
إذا كان لديك QEMU للتو ، فإن بدء تشغيل الجهاز الظاهري دون الربط يبدو كالتالي:
$ qemu < >
في المعلمات التي تصفها الشبكة ، حظر الأجهزة. كل شيء رائع ، ولكن غير مريح. لذلك هناك libvirt.
الهدف من libvirt هو أن تكون أداة واحدة لجميع برامج Hypervisor . يمكن أن تعمل مع أي شيء: مع KVM ، مع LXD. يبدو أنه يبقى فقط لتعلم بناء جملة libvirt ، لكنه في الواقع يعمل بشكل أسوأ من الناحية النظرية.
هذه الكلمات الثلاث هي كل ما هو مطلوب لرفع أول آلة افتراضية في KVM. ولكن مرة أخرى ، هناك فروق دقيقة ...
Libvirt لديه التكوين حيث يتم تخزين الأجهزة الافتراضية وغيرها من الإعدادات. إنه يخزن التكوين في ملفات xml - أنيقة وعصرية ومباشرة من التسعينيات. إذا رغبت في ذلك ، يمكن تحريرها باليد ، ولكن لماذا ، إذا كانت هناك أوامر مريحة. مريحة أيضا هو أن التغييرات على ملفات XML هي إصدارات رائعة. نحن نستخدم
etckeeper - إصدار الدليل الخ من الممكن بالفعل استخدام etckeeper وقد حان الوقت.
دورة تحطم LXC
هناك العديد من المفاهيم الخاطئة حول LXC و LXD.
LXC هي قدرة النواة الحديثة على استخدام مساحات الأسماء - للتظاهر بأنها ليست في جوهرها على الإطلاق.
يمكنك إنشاء مساحات الأسماء هذه بقدر ما تريد لكل حاوية. من الناحية الرسمية ، جوهر واحد ، لكنه يتصرف مثل العديد من النوى متطابقة. تتيح لك LXC تشغيل الحاويات ، ولكنها توفر فقط الأدوات الأساسية.
أطلقت شركة Canonical ، التي تقف وراء أوبونتو وتحرك الحاويات بقوة إلى الأمام ،
LXD ، وهو نظير لل libvirt . هذا الربط يجعل من السهل تشغيل الحاويات ، لكن بداخلها لا يزال LXC.
LXD هو hypervisor حاوية يستند LXC.
المؤسسة يسود في LXD. يخزن LXD التكوين في قاعدة البيانات الخاصة به - في الدليل
/var/lib/lxd . هناك ، يؤدي LXD التكوين الخاص به إلى التكوين في SQlite. إن نسخها غير منطقي ، لكن يمكنك كتابة الأوامر التي استخدمتها لإنشاء تكوين الحاوية.
لا يوجد تفريغ على هذا النحو ، لكن معظم التغييرات تتم آليا بواسطة الفرق. هذا هو التماثلية لملف Docker ، فقط مع التحكم اليدوي.
إنتاج
ما واجهناه عندما أبحرنا جميعًا في العملية.
شبكة
كم القمامة الجهنمية والضجة على شبكة الإنترنت حول الشبكة في KVM! 90 ٪ من المواد يقولون استخدام الجسر.
التوقف عن استخدام الجسر!
ما هو الخطأ معه؟ في الآونة الأخيرة ، لدي شعور بأن الجنون يحدث مع الحاويات: ضع Docker أعلى Docker بحيث يمكنك تشغيل Docker في Docker أثناء مشاهدة Docker. معظمهم لا يفهمون ما يفعله الجسر.
يضع جهاز التحكم في الشبكة في
وضع مختلط ويستقبل كل حركة المرور لأنه لا يعرف أي منها وأي منها لا. نتيجةً لذلك ، تمر كل حركة مرور الجسور بمجموعة Linux رائعة وسريعة على الشبكة ، وهناك الكثير من النسخ. في النهاية ، كل شيء بطيء وسيء. لذلك ، لا تستخدم الجسر في الإنتاج.
SR-قسائم الصرف الداخلية
SR-IOV هي القدرة على التمثيل الافتراضي داخل بطاقة الشبكة . بطاقة الشبكة نفسها قادرة على تخصيص جزء من نفسها للأجهزة الافتراضية ، الأمر الذي يتطلب بعض دعم الأجهزة. هذا هو ما سيمنع الهجرة. يعد ترحيل جهاز افتراضي حيث مفقود SR-IOV مؤلمًا.
يجب استخدام SR-IOV حيثما كان مدعومًا من قِبل جميع برامج Hypervisor كجزء من الترحيل. إذا لم يكن كذلك ، ثم macvtap هو لك.
macvtap
هذا هو لأولئك الذين لا تدعم بطاقة الشبكة SR-IOV. هذه هي النسخة الخفيفة من الجسر: يتم تعليق عناوين MAC المختلفة على بطاقة شبكة واحدة ،
ويتم استخدام تصفية البث الأحادي : لا تقبل بطاقة الشبكة كل شيء ، ولكن وفقًا لقائمة عناوين MAC.
يمكن العثور على مزيد من التفاصيل الدموية في حديث Toshiaki Makita الرائع
وتقنيات التبديل الافتراضي و Linux Bridge . إنه مليء بالألم والمعاناة.
90 ٪ من المواد حول كيفية بناء شبكة في KVM عديمة الفائدة.
إذا قال أحدهم أن الجسر رائع ، فلا تتحدث مع هذا الشخص بعد الآن.
مع macvtap ،
توفر وحدة المعالجة المركزية حوالي 30 ٪ بسبب عدد أقل من النسخ. لكن الوضع مختلط له الفروق الدقيقة الخاصة به. لا يمكنك الاتصال بواجهة شبكة جهاز الضيف من برنامج hypervisor نفسه - من المضيف. تقرير توشياكي تفاصيل هذا. ولكن باختصار - لن ينجح.
من المشرف جدا نادرا ما تذهب على SSH. يعد تشغيل وحدة التحكم هناك أكثر ملاءمة ، على سبيل المثال ، وحدة تحكم Win. من الممكن "مراقبة" حركة المرور على الواجهة - لا يمكنك الاتصال عبر TCP ، لكن حركة المرور على برنامج hypervisor مرئية.
إذا كانت سرعاتك أعلى من 1 جيجابت - اختر macvtap.
عند سرعات واجهة تصل إلى أو حوالي 1 جيجابت في الثانية ، يمكن استخدام الجسر أيضًا. ولكن إذا كان لديك بطاقة شبكة بسرعة 10 جيجا بايت وتريد التخلص منها بطريقة أو بأخرى ، فسيظل هناك macvtap فقط. لا توجد خيارات أخرى. باستثناء SR-IOV.
سيستم دي-networkd
هذه طريقة رائعة لتخزين تكوين الشبكة على برنامج Hypervisor نفسه . في حالتنا ، هذا هو Ubuntu ، لكن بالنسبة للأنظمة الأخرى ، يعمل systemd.
اعتدنا أن يكون لدينا ملف
/etc/network/interfaces احتفظنا به جميعًا. ملف واحد غير مريح للتحرير في كل مرة - يسمح لك systemd-networkd بتقسيم التكوين إلى مجموعة من الملفات الصغيرة. هذا مناسب لأنه يعمل مع أي نظام تعيين: تم إرساله إلى Git وترى متى حدث التغيير وماذا حدث.
هناك عيب اكتشفه مسئولو الشبكات لدينا. عندما تحتاج إلى إضافة شبكة محلية ظاهرية جديدة في برنامج Hypervisor ، أذهب وأهيئ. ثم أقول: "إعادة تشغيل systemctl systemd-networkd". في هذه اللحظة ، كل شيء على ما يرام معي ، ولكن إذا تم رفع جلسات BGP من هذا الجهاز ، فإنها تنهار. المسوقين الشبكيين لدينا لا يوافقون على هذا.
بالنسبة لبرنامج Hypervisor ، لا يحدث شيء سيء. Systemd-networkd غير مناسب لحدود الحدود والخوادم ذات BGP المرتفعة ، وللمراقبين الفائقين - ممتاز.
Systemd-networkd أبعد ما يكون عن النهائي ولن يتم إكماله أبدًا. ولكن هذا أكثر ملاءمة من تحرير ملف ضخم واحد. بديل لـ systemd-networkd في Ubuntu 18.04 هو Netplan. هذه طريقة "رائعة" لتكوين الشبكة والخطوة على أشعل النار.
جهاز الشبكة
بعد تثبيت KVM و LXD على برنامج hypervisor ، فإن أول شيء ستراه هو جسرين. قدم واحد KVM لنفسه ، والثاني - LXD.
تحاول LXD و KVM نشر شبكتها.
إذا كنت لا تزال بحاجة إلى جسر - لآلات الاختبار أو اللعب ، فقم بقتل الجسر الذي يتم تشغيله افتراضيًا وإنشاء جسر خاص بك - الجسر الذي تريده. KVM أو LXD تفعل ذلك بشكل رهيب - تنزلق dnsmasq ، ويبدأ الرعب.
مستودع
لا يهم التطبيقات التي تريدها - استخدم التخزين المشترك.
على سبيل المثال ، iSCSI للأجهزة الافتراضية. لن تتخلص من "نقطة الفشل" ، ولكن يمكنك
دمج التخزين في نقطة واحدة . هذا يفتح فرصا جديدة مثيرة للاهتمام.
للقيام بذلك ، يجب أن يكون لديك واجهات 10 جيجابت / ثانية على الأقل داخل مركز البيانات. ولكن حتى لو كان لديك فقط 1 جيجابت / ثانية - لا تقلق. هذا هو حوالي 125 ميغا بايت / ثانية - جيد للغاية لبرامج Hypervisor التي لا تتطلب تحميل القرص عالية.
يمكن KVM ترحيل وسحب التخزين. ولكن ، على سبيل المثال ، في وضع عبء العمل ، يعد نقل جهاز ظاهري إلى زوجين تيرابايت بمثابة ألم. بالنسبة للترحيل باستخدام وحدة تخزين مشتركة ، فإن ذاكرة الوصول العشوائي (RAM) فقط كافية ، وهو أمر أساسي. هذا
يقلل من وقت الهجرة .
في النهاية ، LXD أو KVM؟
في البداية ، افترضنا أنه بالنسبة لجميع الأجهزة الافتراضية التي تتطابق فيها النواة مع النظام المضيف ، سنتخذ LXD. وحيث نحتاج إلى أخذ نواة أخرى - خذ KVM.
في الواقع ، لم تقلع الخطط. لفهم السبب ، ألقِ نظرة فاحصة على LXD.
LXD
زائد الرئيسي هو حفظ الذاكرة على جوهر. النواة هي نفسها وعندما نطلق حاويات جديدة ، النواة هي نفسها. على هذا ، انتهت إيجابيات وبدأت سلبيات.
يجب أن يتم تثبيت جهاز كتلة مع rootfs. الأمر أصعب مما يبدو.
لا يوجد حقا هجرة . هو ، ويستند على criu صك قاتمة رائعة ، والتي رآنا مواطنينا. أنا فخور بهم ، ولكن في الحالات البسيطة لا يعمل criu.
وكيل zabbix يتصرف بغرابة في وعاء . إذا قمت بتشغيله داخل الحاوية ، فسترى سلسلة من البيانات من النظام المضيف ، وليس من الحاوية. حتى الآن لا يمكن فعل شيء.
عند النظر في قائمة العمليات على برنامج Hypervisor ، يستحيل فهم الحاوية التي تنمو منها عملية معينة بسرعة . يستغرق وقتًا ما لمعرفة مساحة الاسم الموجودة وماذا وأين. إذا قفز الحمل في مكان ما أكثر من المعتاد ، ثم بسرعة لا أفهم. هذه هي المشكلة الرئيسية - القيد في قدرات الاستجابة. يتم إجراء تحقيق صغير لكل حالة.
تعمل ميزة الإضافة الوحيدة من LXD على توفير الذاكرة الأساسية وتقليل الحمل.
لكن Kernel Shared Memory في KVM يحفظ الذاكرة بالفعل.
حتى الآن لا أرى أي سبب لإدخال إنتاج جدي و LXD. على الرغم من الجهود التي بذلتها Canonical في هذا المجال ، فإن إنتاج LXD يجلب مشاكل أكثر من الحلول. في المستقبل القريب لن يتغير الوضع.
ولكن ، لا يمكن القول أن LXD هو الشر. إنه جيد ، لكن في حالات محدودة ، سأناقشها بعد قليل.
Criu
Criu هو أداة قاتمة.
قم بإنشاء حاوية فارغة ، سيصل مع عميل DHCP ويخبرها: "Suspend!" احصل على الخطأ لأن هناك عميل DHCP: "رعب ، رعب! انه يفتح المقبس مع علامة "الخام" - يا له من كابوس! " أسوأ في أي مكان.
انطباعات الحاويات: لا هجرة ، Criu يعمل مرة أخرى.
يعجبني التوصية الصادرة عن فريق LXD بشأن ما يجب فعله مع Criu بحيث لا توجد مشاكل:
-
خذ نسخة أعذب من المستودع!وهل يمكنني وضعه بطريقة ما من العبوة حتى لا يتم الدخول إلى المستودع؟
النتائج
LXD رائع إذا كنت تريد إنشاء بنية أساسية CI / CD. نحن نأخذ LVM - Logical Volume Manager ونقوم بعمل لقطة منه وبدء الحاوية عليه. كل شيء يعمل بشكل رائع! في الثانية ، يتم إنشاء حاوية نظيفة جديدة ، والتي تم تكوينها لاختبار الشيف المتداول - نستخدمه بفعالية.
LXD ضعيف للإنتاج الجاد . لا يمكننا معرفة ما يجب القيام به مع LXD في الإنتاج إذا كان لا يعمل بشكل جيد.
اختيار KVM و KVM فقط!الهجرة
سأقول هذا لفترة وجيزة. بالنسبة لنا ، تحولت الهجرة إلى عالم جديد رائع نحبه. كل شيء بسيط هناك - هناك فريق للهجرة وخياران مهمان:
virsh migrate <vm> qemu+ssh://<hypervisor>/system --undefinesource -persistent
إذا كتبت "ترحيل KVM" في Google وفتحت المادة الأولى ، فسترى أمرًا للهجرة ، ولكن بدون المفتاحين الأخيرين. لن ترى إشارة إلى أنها مهمة: "فقط قم بتنفيذ هذا الأمر!" قم بتشغيل الأمر - وهو يهاجر حقًا ، لكن فقط كيف؟
خيارات الترحيل المهمة.
undefinesource - إزالة الجهاز الظاهري من برنامج hypervisor الذي نقوم بالترحيل منه. إذا قمت بإعادة التشغيل بعد عملية الترحيل هذه ، فسيقوم برنامج Hypervisor الذي تركته بإعادة تشغيل هذا الجهاز. سوف تفاجأ ، لكن هذا طبيعي.
بدون المعلمة الثانية - المستمرة - لا يعتبر برنامج hypervisor الذي قمت بنقله على الإطلاق عملية ترحيل دائمة. بعد إعادة التشغيل ، لن يتذكر برنامج hypervisor أي شيء.
- virsh dominfo <vm> | grep persistent
بدون هذه المعلمة ، يكون الجهاز الظاهري هو دوائر على الماء. إذا تم تحديد المعلمة الأولى دون الثانية ، ثم تخمين ما سيحدث.
هناك العديد من هذه اللحظات مع KVM.
- الشبكة: يخبركون دائمًا عن الجسر - إنه كابوس! تقرأ وتفكر - كيف ذلك؟!
- الهجرة: لن يقولوا أي شيء واضح ، حتى تضرب رأسك على هذا الجدار.
من أين تبدأ؟
للبدء في وقت متأخر - أنا أتحدث عن شيء آخر.
التزويد: كيفية نشره
إذا كنت راضيًا عن خيارات التثبيت القياسية ، فإن آلية الضبط المسبق تكون رائعة.
تحت ESXi ، استخدمنا التطبيق الفعلي. هذه طريقة منتظمة لنشر جهاز افتراضي. من المريح أنك تقوم بإنشاء ملف مسبق تصف فيه صورة Debian / Ubuntu. قم ببدء تشغيل جهاز جديد بتزويده بمجموعة توزيع ISO وملف مسبق. ثم السيارة لفات نفسها. يمكنك الاتصال به عبر SSH ، قم بتوصيله إلى رئيس الطهاة ، ملفات تعريف الارتباط - هذا كل شيء ، اندفع إلى المنتج!
ولكن إذا كان لديك ما يكفي من التطبيق ، لدي أخبار سيئة. هذا يعني أنك لم تصل إلى المرحلة عندما تريد القيام بشيء آخر. لقد انتهينا وأدركنا أن التطبيق الفعلي لا يكفي. لقد توصلنا إلى بعض "الصورة الذهبية" ، التي نقوم باستنساخها ثم تشغيل الأجهزة الافتراضية.
وكيفية ترتيب الجهاز الظاهري؟
لماذا وصلنا إلى هذه الصورة ، ولماذا الإمداد مهم؟ لأنه لا يزال هناك فهم ضعيف في المجتمع بوجود اختلافات كبيرة بين جهاز افتراضي وجهاز عادي.
لا يحتاج الجهاز الظاهري إلى عملية تمهيد معقدة ومحمل إقلاع ذكي . من الأسهل بكثير توصيل أقراص الجهاز الظاهري بجهاز يحتوي على مجموعة كاملة من الأدوات عن وضع الاسترداد الذي يحاول الخروج في مكان ما.
يحتاج الجهاز الظاهري إلى بساطة الجهاز . لماذا أحتاج إلى أقسام على قرص افتراضي؟ لماذا يأخذ الناس قرصًا افتراضيًا ويضعون أقسامًا ، وليس LVM؟
يحتاج الجهاز الظاهري إلى أقصى درجة من القابلية للتوسعة . عادة الأجهزة الافتراضية تنمو. هذه عملية "رائعة" - زيادة القسم في MBR. قمت بحذفها ، في تلك اللحظة تمسح العرق من جبينك وتظن: "لا تكتب الآن ، فقط لا تكتب!" - وإعادة مع المعايير الجديدة.
LVM @ ليلو
نتيجة لذلك ، وصلنا إلى LVM @ lilo. هذا هو أداة تحميل التشغيل التي تتيح لك التكوين من ملف واحد. إذا قمت بتحرير GRUB config ، فأنت تقوم بتحرير ملف خاص يتحكم في محرك القوالب ويقوم بإنشاء ملف boot.cfg الوحشي ، ثم باستخدام Lilo - ملف واحد ، ولا شيء أكثر من ذلك.
LVM Partitionless يجعل النظام مثاليًا وسهلاً. المشكلة هي أن GRUB لا يمكن أن يعيش بدون MBR أو GPT وأنه يتجمد. نقول له: "GRUB يستقر هنا" ، لكنه لا يستطيع ذلك ، لأنه لا توجد أقسام.
يسمح لك LVM بتوسيع وعمل نسخ احتياطية بسرعة. الحوار القياسي:
- الرجال ، كيف يمكنك إجراء النسخ الاحتياطي الظاهري؟- ... نأخذ جهاز كتلة ونسخ.- هل حاولت إعادة النشر؟- حسنا ، لا ، كل شيء يعمل بالنسبة لنا!يمكنك لعق جهاز كتلة في جهاز ظاهري في أي وقت ، ولكن إذا كان هناك نظام ملفات ، فإن أي سجل فيه يتطلب ثلاث حركات - هذا الإجراء ليس ذريًا.
إذا كنت تقوم بعمل لقطة للجهاز الظاهري من الداخل ، فيمكنه التحدث إلى نظام الملفات بحيث يصل إلى حالة الاتساق الصحيحة. لكن هذا ليس مناسبًا لكل شيء.
كيفية بناء الحاوية؟
لبدء وإنشاء حاوية ، هناك أدوات منتظمة من القوالب. تقدم LXD قالب Ubuntu 16.04 أو 18.04. ولكن إذا كنت مقاتلًا متقدمًا ولا تريد قالبًا عاديًا ، ولكن لديك rootfs المخصصة ، والتي يمكنك تخصيصها لنفسك ، فإن السؤال الذي يطرح نفسه هو: كيف تنشئ حاوية من البداية في LXD؟
حاوية من الصفر
إعداد rootfs . سيساعد Debootstrap في ذلك: نوضح الحزم المطلوبة ، والتي ليست ضرورية ، وتثبيتها.
اشرح لـ LXD أننا نريد إنشاء حاوية من جذر محدد . لكن أولاً ، قم بإنشاء حاوية فارغة باستخدام أمر قصير:
curl --unix-socket /var/lib/lxd/unix.socket -X POST -d '{"name": "my-container", "source": {"type": "none"}}' lxd/1.0/containers
ويمكن حتى أن يكون آليا.
سيقول قارئ مدروس - أين توجد حاوية الجذر الخاصة بي؟ أين هو مبين في أي مكان؟ لكنني لم أقل ذلك!
نقوم بتركيب جذور الحاوية حيث ستعيش. ثم نشير إلى أن حاوية rootfs ستعيش هنا:
lxc config set my-container raw.lxc "lxc.rootfs=/containers/my-container/rootfs"
مرة أخرى هذا هو الآلي.
حاوية الحياة
لا تحتوي الحاوية على نواة خاصة بها ، لذا فإن التحميل أسهل
: systemd و init وطار!
إذا كنت لا تستخدم أدوات منتظمة للعمل مع LVM ، ثم في معظم الحالات ، لبدء الحاوية ، ستحتاج إلى تحميل rootfs الحاوية في برنامج hypervisor.
أجد في بعض الأحيان مقالات تقديم المشورة autofs. لا تفعل ذلك. يحتوي Systemd على وحدات آلية تعمل تلقائيًا ، لكن عمليات autofs لا تعمل. لذلك ، يمكن وينبغي أن تستخدم وحدات automd systemd ، ولكن autofs لا يستحق كل هذا العناء.
النتائج
نحن نحب KVM مع الهجرة . مع LXD ، ليس هذا هو الطريق بعد ، على الرغم من اختبار وبناء البنية التحتية التي نستخدمها حيث لا يوجد حمل الإنتاج.
نحن نحب أداء KVM . من المألوف أن ننظر إلى الأعلى ، ونرى هناك عملية مرتبطة بهذا الجهاز الظاهري ، وفهم من وماذا نفعل. هذا أفضل من استخدام مجموعة من الأدوات المساعدة غريبة مع حاويات لمعرفة أي نوع من تقرع تحت الماء هناك.
نحن سعداء بالهجرة. هذا يرجع إلى حد كبير إلى التخزين المشترك. إذا هاجرنا بسحب الأقراص ، فلن نكون سعداء للغاية.
إذا كنت ، مثل ليو ، على استعداد للحديث عن التغلب على صعوبات التشغيل أو التكامل أو الدعم ، فقد حان الوقت الآن لإرسال تقرير إلى مؤتمر DevOpsConf الخريف. ونحن في لجنة البرنامج سوف نساعد في إعداد نفس العرض الملهم والمفيد لهذا.
لا ننتظر الموعد النهائي لنداء تقديم الأوراق وقد قبلنا بالفعل عدة تقارير لبرنامج المؤتمر. اشترك في النشرة الإخبارية وقناة التلغراف وسوف تكون على اطلاع دائم بالأعمال التحضيرية لـ DevOpsConf 2019 ولا تفوت المقالات ومقاطع الفيديو الجديدة.