مقدمة عن جزء الشبكة من البنية التحتية السحابية

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

سنتحدث اليوم عن العالم الداخلي للبنية التحتية السحابية ، على وجه الخصوص ، سنقوم بتحليل أساسيات جزء الشبكة.

ما هي السحابة؟ نفس الافتراضية - عرض الملف الشخصي؟

أكثر من سؤال منطقي. لا - هذه ليست افتراضية ، على الرغم من أنها لم تكن لتستطيع الاستغناء عنها. ضع في اعتبارك تعريفين:

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

الافتراضية - هذه هي القدرة على تقسيم كيان مادي واحد (على سبيل المثال ، خادم) إلى عدة كيانات افتراضية ، وبالتالي زيادة استخدام الموارد (على سبيل المثال ، تم تحميل 3 خوادم بنسبة 25-30 بالمائة ، وبعد المحاكاة الافتراضية يتم تحميل خادم واحد بنسبة 1-80 في المائة). بطبيعة الحال ، تستهلك المحاكاة الافتراضية بعض الموارد - تحتاج إلى إطعام برنامج Hypervisor ، ومع ذلك ، كما أظهرت الممارسة ، فإن اللعبة تستحق كل هذا العناء. المثال المثالي للمحاكاة الافتراضية هو برنامج VMWare ، وهو ممتاز في إعداد الأجهزة الافتراضية ، أو على سبيل المثال KVM ، وهو ما أفضله ، ولكن هذه بالفعل مسألة ذوق.

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

المحاكاة الافتراضية هي إحدى اللبنات الأساسية التي تُبنى عليها السحابة.

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

لكنني أفهم أنه من التعريف الوارد أعلاه ، ليس من الواضح تمامًا ما يمكن أن يُطلق عليه في الواقع سحابة.

لذلك ، يسرد المستند من NIST (المعهد الوطني للمعايير والتكنولوجيا) 5 خصائص رئيسية يجب أن تتمتع بها البنية التحتية السحابية:

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

توافر الخدمة على نطاق واسع. يجب توفير الوصول إلى الموارد من خلال آليات قياسية لتكون قادرة على استخدام كل من أجهزة الكمبيوتر القياسية والعملاء الرقيقين والأجهزة المحمولة.

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

التكيف السريع مع الظروف المختلفة. يجب أن تكون الخدمات مرنة - توفير الموارد بسرعة ، وإعادة تخصيصها ، وإضافة الموارد أو تقليلها بناءً على طلب العميل ، ويجب أن يشعر العميل بأن موارد السحابة لا حصر لها. لسهولة الفهم ، على سبيل المثال ، لا ترى تحذيرًا بأن جزءًا من مساحة القرص الخاص بك قد اختفى في Apple iCloud بسبب حقيقة أن محرك الأقراص الثابتة على الخادم قد تعطل ، والأقراص معطلة. بالإضافة إلى ذلك ، من جانبك ، فإن إمكانيات هذه الخدمة غير محدودة تقريبًا - تحتاج إلى 2 تيرابايت - لا توجد مشكلة ، لقد دفعت واستلمت. وبالمثل ، يمكنك إعطاء مثال على Google.Drive أو Yandex.Disk.

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

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

لماذا نحتاج سحابة؟

ومع ذلك ، أي تقنية جديدة أو موجودة ، يتم إنشاء أي بروتوكول جديد لشيء ما (حسنًا ، باستثناء RIP-ng ، بالطبع). لا يحتاج أي شخص إلى بروتوكول من أجل بروتوكول (حسنًا ، باستثناء RIP-ng ، بالطبع). من المنطقي أن يتم إنشاء السحابة لتقديم نوع من الخدمة للمستخدم / العميل. نحن جميعًا على دراية ببعض الخدمات السحابية على الأقل ، مثل Dropbox أو Google.Docs ، وأعتقد أن معظمهم يستخدمهم بنجاح - على سبيل المثال ، تمت كتابة هذه المقالة باستخدام خدمة Google.Docs السحابية. لكن الخدمات السحابية المعروفة لنا ليست سوى جزء من إمكانيات السحابة - بتعبير أدق ، إنها خدمة من نوع SaaS فقط. يمكننا تقديم خدمة سحابية بثلاث طرق: في شكل SaaS أو PaaS أو IaaS. تعتمد الخدمة التي تحتاجها على رغباتك وقدراتك.

دعنا نفكر في كل منها بالترتيب:

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

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

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

ما هو OpenStack؟

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

كومة مفتوحة هو نظام تشغيل سحابي يسمح لك بالتحكم في مجموعات كبيرة من موارد الحوسبة وتخزين البيانات وموارد الشبكة ، والتي يتم توفيرها وإدارتها من خلال API باستخدام آليات المصادقة القياسية.

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

في وقت كتابة هذه السطور ، تبدو بنية OpenStack كما يلي:

الصورة مأخوذة من openstack.org

يؤدي كل مكون من مكونات OpenStack وظيفة محددة. تسمح لك هذه البنية الموزعة بتضمين مجموعة المكونات الوظيفية التي تحتاجها في الحل. ومع ذلك ، فإن بعض المكونات عبارة عن مكونات جذرية وستؤدي إزالتها إلى عدم قابلية تشغيل الحل بشكل كامل أو جزئي. يشار إلى هذه المكونات عادة باسم:

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

يمكن الاطلاع على قائمة كاملة بجميع المشاريع والغرض منها هنا.

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

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

دعونا نجري الخوارزمية لإنشاء جهاز افتراضي وربطه بالشبكة والتخزين المستمر في Openstack.

1. عندما تنشئ طلبًا لإنشاء سيارة ، سواء كان طلبًا عبر Horizon (Dashboard) أو طلبًا عبر CLI ، فإن أول شيء يحدث هو تفويض طلبك على Keystone - هل يمكنك إنشاء سيارة ، أو لديها حق لاستخدام هذه الشبكة ، هل مشروع حصتك ، وما إلى ذلك.
2. يصادق Keystone على طلبك وينشئ رمز المصادقة في رسالة الاستجابة ، والذي سيتم استخدامه لاحقًا. بعد تلقي رد من Keystone ، يتم إرسال الطلب إلى Nova (nova api).
3. يتحقق Nova-api من صحة طلبك عن طريق الاتصال بـ Keystone باستخدام رمز المصادقة الذي تم إنشاؤه مسبقًا
4. تقوم Keystone بإجراء المصادقة وتوفر معلومات حول الأذونات والقيود بناءً على رمز المصادقة هذا.
5. تقوم Nova-api بإنشاء إدخال VM جديد في قاعدة بيانات nova وترسل طلبًا لإنشاء آلة إلى nova-Scheduler.
6. يحدد Nova-Scheduler المضيف (كمبيوتر العقدة) الذي سيتم نشر الجهاز الظاهري عليه بناءً على المعلمات والأوزان والمناطق المحددة. تتم كتابة سجل بهذا ومعرف الجهاز الظاهري في قاعدة بيانات nova.
7. بعد ذلك ، يستدعي nova-Scheduler nova-compute مع طلب نشر النسخة. تستدعي Nova-compute nova-connectoror للحصول على معلومات حول معلمات الآلة (nova-Conductor هو عنصر nova يعمل كخادم وكيل بين قاعدة بيانات nova و nova-compute ، مما يحد من عدد الطلبات إلى قاعدة بيانات nova من أجل تجنب المشاكل مع تقليل حمل اتساق قاعدة البيانات).
8. يسترد Nova-Conductor المعلومات المطلوبة من قاعدة بيانات nova ويمررها إلى nova-compute.
9. بعد ذلك ، يمكنك إلقاء نظرة سريعة على مكالمات nova-compute للحصول على معرف الصورة. يتحقق Glace من صحة الطلب في Keystone ويعيد المعلومات المطلوبة.
10. تستدعي Nova-compute النيوترون للحصول على معلومات حول معلمات الشبكة. على غرار النظرة الخاطفة ، يتحقق النيوترون من صحة الطلب في Keystone ، ثم ينشئ إدخالًا في قاعدة البيانات (معرف المنفذ ، وما إلى ذلك) ، وينشئ طلبًا لإنشاء منفذ ، ويعيد المعلومات المطلوبة لحساب nova.
11. استدعاءات Nova-compute مع طلب تخصيص وحدة تخزين للجهاز الظاهري. على غرار النظرة ، يتحقق cider من صحة الطلب في Keystone ، وينشئ طلبًا لإنشاء مجلد ، ويعيد المعلومات المطلوبة.
12. تستدعي Nova-compute libvirt مع طلب نشر آلة افتراضية بالمعلمات المحددة.

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

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

توفر Neutron ، كونها خدمة شبكة ، واجهة برمجة تطبيقات لإدارة جزء الشبكة من البنية التحتية السحابية. توفر الخدمة صحة جزء الشبكة وإدارته من Openstack من خلال توفير طبقة تجريد تسمى Network-as-a-Service (NaaS). أي أن الشبكة هي نفس الوحدة الافتراضية القابلة للقياس ، مثل النوى الافتراضية لوحدة المعالجة المركزية أو مقدار ذاكرة الوصول العشوائي.

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

لذلك لدينا جهازان ظاهريان لعميل RED وجهازان ظاهريان للعميل الأخضر. لنفترض أن هذه الأجهزة موجودة على اثنين من برامج Hypervisor بهذه الطريقة:

في الوقت الحالي ، هذه مجرد محاكاة افتراضية لـ 4 خوادم ولا شيء أكثر من ذلك ، نظرًا لأن كل ما فعلناه حتى الآن هو 4 خوادم افتراضية ، ووضعها على خادمين فعليين. ومع ذلك فهم غير متصلين بالشبكة.

للحصول على سحابة ، نحتاج إلى إضافة عدة مكونات. أولاً ، نقوم بإضفاء الطابع الافتراضي على جزء الشبكة - نحتاج إلى توصيل هذه الأجهزة الأربعة في أزواج ، ويريد العملاء اتصال L4 بالضبط. يمكنك استخدام مفتاح الدورة وإعداد جذع في اتجاهه وحل كل شيء باستخدام جسر لينكس ، أو لمستخدمي openvswitch الأكثر تقدمًا (سنعود إليه لاحقًا). ولكن يمكن أن يكون هناك الكثير من الشبكات ، ودفع L2 باستمرار من خلال مفتاح ليس هو أفضل فكرة - لذلك أقسام مختلفة ، ومكتب خدمة ، وشهور من انتظار اكتمال التطبيق ، وأسابيع من استكشاف الأخطاء وإصلاحها - في العالم الحديث ، هذا النهج لم يعد يعمل. وكلما أسرعت الشركة في فهم ذلك ، كان من الأسهل المضي قدمًا. لذلك ، بين برامج Hypervisor ، سنختار شبكة L2 ستتواصل من خلالها أجهزتنا الافتراضية ، وعلى رأس شبكة L3 هذه ، سنقوم ببناء شبكات تراكب افتراضية L3 (تراكب) حيث سيتم تشغيل حركة مرور أجهزتنا الافتراضية. يمكن أن يكون التغليف GRE أو Geneve أو VxLAN. في الوقت الحالي ، دعنا نركز على الأخير ، على الرغم من أن هذا ليس مهمًا بشكل خاص.

نحتاج إلى تحديد موقع VTEP في مكان ما (آمل أن يكون الجميع على دراية بمصطلحات VxLAN). نظرًا لأن شبكة L3 تغادر خوادمنا على الفور ، فلا شيء يمنعنا من وضع VTEP على الخوادم نفسها ، ويمكن لـ OVS (OpenvSwitch) القيام بذلك تمامًا. نتيجة لذلك ، حصلنا على الهيكل التالي:

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

الآن يمكننا إنتاج أجهزتنا وشبكاتنا الافتراضية لهم دون أي مشاكل.

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

يبدو أنه ليس شيئًا معقدًا - فنحن نصمم واجهة جسر على عقدة التحكم ، ونوجه حركة المرور إليها ومن هناك نوجهها إلى حيث نحتاج إليها. لكن المشكلة تكمن في أن عميل RED يريد استخدام الشبكة 10.0.0.0/24 والعميل الأخضر يريد استخدام الشبكة 10.0.0.0/24. أي أننا نبدأ تقاطع مساحات العنوان. بالإضافة إلى ذلك ، لا يريد العملاء أن يتمكن العملاء الآخرون من التوجيه إلى شبكاتهم الداخلية ، وهذا أمر منطقي. لفصل الشبكات وحركة مرور هؤلاء العملاء ، سنخصص مساحة اسم منفصلة لكل منهم. Namespace هو في الواقع نسخة من مكدس شبكة Linux ، أي أن العملاء في مساحة الاسم RED معزولون تمامًا عن العملاء من مساحة الاسم GREEN (حسنًا ، إما أن التوجيه بين شبكات العملاء هذه مسموح به من خلال مساحة الاسم الافتراضية أو بالفعل على معدات نقل أعلى).

أي نحصل على المخطط التالي:

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

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

نتيجة لذلك ، حصلنا على المخطط التالي:

السؤال المعقول هو لماذا لا نصنع بوابات على عقد الحوسبة نفسها؟ هذه ليست مشكلة كبيرة ، علاوة على ذلك ، عند تشغيل جهاز التوجيه الموزع (DVR) ، سيعمل على هذا النحو. في هذا السيناريو ، نعتبر الخيار الأبسط مع بوابة مركزية ، والتي يتم استخدامها افتراضيًا في Openstack. بالنسبة للوظائف عالية التحميل ، سيستخدمون كلاً من جهاز التوجيه الموزع وتقنيات التسريع مثل SR-IOV و Passsthrough ، ولكن كما يقولون ، هذه قصة مختلفة تمامًا. أولاً ، لنتعامل مع الجزء الأساسي ، ثم ندخل في التفاصيل.

في الواقع ، مخططنا يعمل بالفعل ، ولكن هناك بعض الفروق الدقيقة:

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

لنبدأ بحماية السيارة. للقيام بذلك ، يمكنك استخدام iptables المبتذلة ، لماذا لا.

أي أن الطوبولوجيا أصبحت الآن أكثر تعقيدًا:

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

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

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

وهنا يأتي دور NAT في عملية الإنقاذ - سنعمل ببساطة على تمكين العملاء من الوصول إلى العالم الخارجي من خلال مساحة الاسم الافتراضية باستخدام ترجمة NAT. حسنًا ، هذه مشكلة صغيرة. يعد هذا أمرًا جيدًا إذا كان خادم العميل يعمل كعميل وليس كخادم - أي أنه يبدأ الاتصالات ولا يقبلها. لكن بالنسبة لنا سيكون العكس. في هذه الحالة ، نحتاج إلى إنشاء وجهة NAT بحيث عند تلقي حركة المرور ، تدرك عقدة التحكم أن حركة المرور هذه مخصصة للجهاز الظاهري A للعميل A ، مما يعني أننا بحاجة إلى إجراء ترجمة NAT من عنوان خارجي ، على سبيل المثال 100.1.1.1. 10.0.0.1 إلى عنوان داخلي 100. في هذه الحالة ، على الرغم من أن جميع العملاء سيستخدمون نفس الشبكة ، يتم الاحتفاظ بالعزلة الداخلية تمامًا. وهذا يعني أننا نحتاج إلى عمل dNAT و sNAT على عقدة التحكم. استخدم شبكة واحدة مع تخصيص عناوين عائمة أو شبكات خارجية ، أو كليهما في وقت واحد - يتم تحديد ذلك من خلال حقيقة أنك تريد تضييقها في السحابة. لن نضع أيضًا عناوين عائمة في الرسم التخطيطي ، لكننا سنترك الشبكات الخارجية المضافة مسبقًا - لكل عميل شبكته الخارجية الخاصة (في الرسم التخطيطي ، يشار إليها كـ vlan 200 و XNUMX على الواجهة الخارجية).

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

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

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

المشكلة التالية هي أقراص الآلة الافتراضية. في الوقت الحالي ، يتم تخزينها على برامج Hypervisor نفسها ، وفي حالة حدوث مشكلات مع برنامج Hypervisor ، نفقد جميع البيانات - ولن يساعد وجود غارة هنا إذا لم نفقد القرص ، ولكن الخادم بأكمله. للقيام بذلك ، نحتاج إلى إنشاء خدمة تعمل كواجهة أمامية لأي تخزين. ما نوع التخزين الذي سيكون ليس مهمًا بشكل خاص بالنسبة لنا ، ولكن يجب أن يحمي بياناتنا من فشل كل من القرص والعقدة ، وربما الخزانة بأكملها. هناك العديد من الخيارات هنا - بالطبع ، هناك شبكات SAN مع Fibre Channel ، ولكن لنكن صادقين - FC هي بالفعل من بقايا الماضي - تناظرية لـ E1 في النقل - نعم ، أوافق ، لا تزال تستخدم ، ولكن فقط حيث يكون من المستحيل بدونها. لذلك ، لن أنشر شبكة FC طواعية في عام 2020 ، مع العلم أن هناك بدائل أخرى أكثر إثارة للاهتمام. على الرغم من أنه بالنسبة لكل واحد منهم وربما هناك أولئك الذين يعتقدون أن FC بكل قيودها هو كل ما نحتاجه - لن أجادل ، فكل شخص لديه آرائه الخاصة. ومع ذلك ، فإن الحل الأكثر إثارة للاهتمام في رأيي هو استخدام SDS ، مثل Ceph.

يسمح لك Ceph ببناء حل تخزين متاح للغاية مع مجموعة من خيارات التكرار الممكنة ، من أكواد التكافؤ (على غرار RAID 5 أو 6) إلى النسخ المتماثل الكامل للبيانات على أقراص مختلفة ، مع مراعاة موقع الأقراص في الخوادم والخوادم في الخزانات ، إلخ.

أنت بحاجة إلى 3 عقد أخرى لبناء Ceph. سيتم أيضًا إجراء التفاعل مع التخزين عبر الشبكة باستخدام خدمات تخزين الكتلة والعناصر والملفات. دعنا نضيف مساحة تخزين إلى المخطط:

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

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

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

العمارة النيوترونية

في OpenStack ، يكون Neutron مسؤولاً عن توصيل منافذ الجهاز الظاهري بشبكة L2 مشتركة ، مما يوفر توجيه حركة المرور بين الأجهزة الافتراضية الموجودة في شبكات L2 المختلفة ، بالإضافة إلى التوجيه الخارجي ، وتوفير خدمات مثل NAT ، و Floating IP ، و DHCP ، وما إلى ذلك.

يمكن وصف التشغيل عالي المستوى لخدمة الشبكة (الجزء الأساسي) على النحو التالي.

عند بدء تشغيل الجهاز الظاهري ، فإن خدمة الشبكة:

1. يقوم بإنشاء منفذ لهذا الجهاز الظاهري (أو المنافذ) ويخطر خدمة DHCP بذلك ؛
2. يتم إنشاء جهاز شبكة افتراضية جديد (عبر libvirt) ؛
3. يتصل الجهاز الظاهري بالمنفذ (المنافذ) التي تم إنشاؤها في الخطوة 1 ؛

من الغريب أن نيوترون مبني على آليات قياسية مألوفة لكل من سبق له الغوص في لينكس - وهذه هي مساحات الأسماء ، و iptables ، وجسور لينكس ، و openvswitch ، و conntrack ، وما إلى ذلك.

يجب توضيح أن النيوترون ليس وحدة تحكم SDN.

يتكون النيوترون من عدة مكونات مترابطة:

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

خادم النيوترون هو في الواقع تطبيق مكتوب بلغة بيثون ، ويتكون من جزأين:

• خدمة REST
• البرنامج المساعد النيوتروني (الأساسية / الخدمة)

تم تصميم خدمة REST لتلقي استدعاءات API من المكونات الأخرى (على سبيل المثال ، طلب تقديم بعض المعلومات ، إلخ.)

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

يمكن الاطلاع على قائمة المكونات الإضافية المتاحة حاليًا على سبيل المثال هنا

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

مكدس مفتوح-نيوترون- ml2 هو البرنامج الإضافي القياسي لجذر Openstack. يحتوي هذا المكون الإضافي على بنية معيارية (على عكس سابقتها) وتكوين خدمة الشبكة من خلال برامج التشغيل المتصلة بها. سننظر في المكون الإضافي نفسه بعد قليل ، لأنه في الواقع يمنح المرونة التي يتمتع بها OpenStack في جزء الشبكة. يمكن استبدال المكون الإضافي الجذر (على سبيل المثال ، تقوم شركة Contrail Networking بهذا الاستبدال).

خدمة RPC (خادم rabbitmq) - خدمة توفر إدارة قائمة الانتظار والتفاعل مع خدمات OpenStack الأخرى ، فضلاً عن التفاعل بين وكلاء خدمة الشبكة.

وكلاء الشبكة - الوكلاء الموجودون في كل عقدة ، والتي يتم من خلالها تكوين خدمات الشبكة.

الوكلاء من عدة أنواع.

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

العامل التالي الذي لا يقل أهمية هو وكيل L3. بشكل افتراضي ، يعمل هذا الوكيل حصريًا على عقدة الشبكة (غالبًا ما يتم دمج عقدة الشبكة مع عقدة تحكم) ويوفر التوجيه بين شبكات المستأجرين (سواء بين شبكاتها وشبكات المستأجرين الآخرين ، وهو متاح للعالم الخارجي ، مما يوفر NAT وكذلك خدمة DHCP). ومع ذلك ، عند استخدام DVR (جهاز توجيه موزع) ، تظهر أيضًا الحاجة إلى مكون إضافي L3 على عقد الحوسبة.

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

قاعدة البيانات - قاعدة بيانات للمعرفات الخاصة بالشبكات ، والشبكات الفرعية ، والمنافذ ، والتجمعات ، وما إلى ذلك.

في الواقع ، يقبل Neutron طلبات API من إنشاء أي كيانات شبكة ، ويصادق على الطلب ، ومن خلال RPC (إذا كان يشير إلى نوع من المكونات الإضافية أو الوكيل) أو REST API (إذا كان يتصل في SDN) ينقل إلى الوكلاء (عبر الإضافات) التعليمات اللازمة لتنظيم الخدمة المطلوبة.

الآن دعنا ننتقل إلى التثبيت التجريبي (كيف يتم نشره وما يحتويه ، سنرى لاحقًا في الجزء العملي) ونرى أين يوجد المكون:

(overcloud) [stack@undercloud ~]$ openstack network agent list  
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID                                   | Agent Type         | Host                                | Availability Zone | Alive | State | Binary                    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent           | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-l3-agent          |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent         | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-dhcp-agent        |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent     | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-metadata-agent    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$ 

في الواقع ، هذا هو الهيكل الكامل للنيوترون. الآن من الجدير قضاء بعض الوقت في البرنامج المساعد ML2.

طبقة معيارية 2

كما هو مذكور أعلاه ، يعد المكون الإضافي مكونًا إضافيًا قياسيًا لجذر OpenStack وله بنية معيارية.

كان لسابق البرنامج المساعد ML2 بنية متجانسة ، والتي لم تسمح ، على سبيل المثال ، باستخدام مزيج من عدة تقنيات في تثبيت واحد. على سبيل المثال ، لا يمكنك استخدام كل من openvswitch و linuxbridge في نفس الوقت - إما الأول أو الثاني. لهذا السبب ، تم إنشاء ملحق ML2 بهيكلته.

يحتوي ML2 على مكونين - نوعان من برامج التشغيل: محركات النوع وبرامج تشغيل الآلية.

اكتب السائقين تحديد التقنيات التي سيتم استخدامها لتنظيم اتصال الشبكة ، مثل VxLAN و VLAN و GRE. في هذه الحالة ، يسمح لك برنامج التشغيل باستخدام تقنيات مختلفة. التكنولوجيا القياسية هي تغليف VxLAN لشبكات التراكب وشبكات vlan الخارجية.

برامج تشغيل النوع هي الأنواع التالية من الشبكات:

شقة - شبكة بدون علامات
VLAN - الشبكة الموسومة
محلّي - نوع خاص من الشبكات للتركيبات الشاملة (مثل هذه التركيبات مطلوبة إما للمطورين أو للتدريب)
GRE - شبكة تراكب باستخدام أنفاق GRE
شبكة VxLAN - تراكب الشبكة باستخدام أنفاق VxLAN

محركات الآلية تحديد الوسائل التي توفر تنظيم التقنيات المحددة في برنامج تشغيل النوع - على سبيل المثال ، openvswitch ، sr-iov ، opendaylight ، OVN ، إلخ.

اعتمادًا على تنفيذ برنامج التشغيل هذا ، سيتم استخدام إما الوكلاء الذين يتحكم فيهم Neutron ، أو سيتم استخدام الاتصالات بوحدة تحكم SDN خارجية ، والتي تهتم بجميع مشكلات تنظيم شبكات L2 والتوجيه وما إلى ذلك.

على سبيل المثال ، إذا استخدمنا ML2 مع OVS ، فسيتم تثبيت وكيل L2 على كل عقدة حوسبة تدير OVS. ومع ذلك ، إذا استخدمنا ، على سبيل المثال ، OVN أو OpenDayLight ، فإن تحكم OVS يخضع لولايتها القضائية - يعطي Neutron أوامر لوحدة التحكم من خلال المكون الإضافي الجذر ، وهو يقوم بالفعل بما قيل له.

لنقم بتحديث ذاكرة Open vSwitch

في الوقت الحالي ، أحد المكونات الرئيسية لـ OpenStack هو Open vSwitch.
عند تثبيت OpenStack بدون أي مورد إضافي SDN مثل Juniper Contrail أو Nokia Nuage ، فإن OVS هو مكون الشبكة الرئيسي للشبكة السحابية ويسمح لك ، جنبًا إلى جنب مع iptables و conntrack ومساحات الأسماء ، بتنظيم شبكة تراكب كاملة متعددة الإيجارات. وبطبيعة الحال ، يمكن استبدال هذا المكون ، على سبيل المثال ، عند استخدام حلول SDN مملوكة لجهة خارجية (البائع).

OVS هو مفتاح برمجي مفتوح المصدر مصمم للاستخدام في البيئات الافتراضية كموجه حركة مرور افتراضي.

في الوقت الحالي ، تتمتع OVS بوظيفة جيدة للغاية ، والتي تشمل تقنيات مثل QoS و LACP و VLAN و VxLAN و GENEVE و OpenFlow و DPDK وما إلى ذلك.

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

هناك ثلاثة مكونات OVS مهمة يجب أن تكون على دراية بها:

• وحدة Kernel - عنصر موجود في مساحة النواة يعالج حركة المرور بناءً على القواعد الواردة من عنصر التحكم ؛
• vSwitch daemon (ovs-vswitchd) هي عملية تعمل في مساحة المستخدم ، وهي مسؤولة عن برمجة وحدة kernel - أي أنها تمثل منطق المحول مباشرة
• خادم قاعدة البيانات هي قاعدة بيانات محلية موجودة على كل مضيف يقوم بتشغيل OVS والذي يخزن التكوين. من خلال هذه الوحدة ، يمكن لوحدات تحكم SDN الاتصال باستخدام بروتوكول OVSDB.

كل هذا مصحوب بمجموعة من أدوات التشخيص والإدارة ، مثل ovs-vsctl ، و ovs-appctl ، و ovs-ofctl ، إلخ.

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

ملاحظة: بالنسبة إلى السحابة التي تم نشرها لوظائف الاتصالات ، من الممكن إخراج حركة المرور من العقد الحاسوبية التي تتجاوز OVS مباشرة إلى تبديل المعدات. لهذا الغرض ، يتم استخدام آليات SR-IOV و العبور.

كيف يعمل على تخطيط حقيقي؟

حسنًا ، دعنا الآن ننتقل إلى الجزء العملي ونرى كيف يعمل كل شيء في الممارسة.

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

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

لذا ، لنبدأ بالترتيب. أولا ، نظرية صغيرة. سنقوم بتثبيت Openstack باستخدام TripleO (Openstack on Openstack). يتمثل جوهر TripleO في أننا نقوم بتثبيت Openstack all-in-one (أي على عقدة واحدة) ، يسمى undercloud ، ثم نستخدم إمكانيات Openstack المنشور لتثبيت Openstack ، المصمم للاستغلال ، والذي يسمى overcloud. سيستخدم Undercloud قدرته على إدارة الخوادم المادية (المعدن المجرد) - المشروع الأيوني - لتوفير أجهزة Hypervisor التي ستعمل كعقد للحوسبة والتحكم والتخزين. أي أننا لا نستخدم أي أدوات تابعة لجهات خارجية لنشر Openstack - فنحن ننشر Openstack باستخدام Openstack. بعد التثبيت ، سيصبح الأمر أكثر وضوحًا ، لذلك لن نتوقف عند هذا الحد ونمضي قدمًا.

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

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

يمكنك التحقق مما إذا تم تمكين الظاهرية المتداخلة أم لا مثل هذا:

[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested
N
[root@hp-gen9 bormoglotx]# 

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

نحتاج إلى تجميع المخطط التالي من الأجهزة الافتراضية:

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

[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1        
<network>
  <name>ovs-network-1</name>
  <uuid>7a2e7de7-fc16-4e00-b1ed-4d190133af67</uuid>
  <forward mode='bridge'/>
  <bridge name='ovs-br1'/>
  <virtualport type='openvswitch'/>
  <portgroup name='trunk-1'>
    <vlan trunk='yes'>
      <tag id='100'/>
      <tag id='101'/>
      <tag id='102'/>
    </vlan>
  </portgroup>
  <portgroup name='access-100'>
    <vlan>
      <tag id='100'/>
    </vlan>
  </portgroup>
  <portgroup name='access-101'>
    <vlan>
      <tag id='101'/>
    </vlan>
  </portgroup>
</network>

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

virsh net-define ovs-network-1.xml 
virsh net-start ovs-network-1 
virsh net-autostart ovs-network-1 

نقوم الآن بتحرير تكوين منافذ برنامج Hypervisor:

[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens1f0   
TYPE=Ethernet
NAME=ens1f0
DEVICE=ens1f0
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=ovs-br1
ONBOOT=yes
OVS_OPTIONS="trunk=100,101,102"
[root@hp-gen9 ~]
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ovs-br1 
DEVICE=ovs-br1
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.255.200
PREFIX=24
[root@hp-gen9 ~]# 

ملاحظة: في هذا السيناريو ، لن يمكن الوصول إلى العنوان الموجود على منفذ ovs-br1 ، لأنه لا يحتوي على علامة vlan. لإصلاح ذلك ، تحتاج إلى إصدار الأمر sudo ovs-vsctl set port ovs-br1 tag = 100. ومع ذلك ، بعد إعادة التشغيل ، ستختفي هذه العلامة (إذا كان أي شخص يعرف كيفية إبقائها في مكانها ، فسأكون ممتنًا للغاية). لكن هذا ليس مهمًا جدًا ، لأننا سنحتاج إلى هذا العنوان فقط أثناء التثبيت ولن تكون هناك حاجة إليه عند نشر Openstack بالكامل.

بعد ذلك ، قم بإنشاء آلة undercloud:

virt-install  -n undercloud --description "undercloud"  --os-type=Linux  --os-variant=centos7.0  --ram=8192  --vcpus=8  --disk path=/var/lib/libvirt/images/undercloud.qcow2,bus=virtio,size=40,format=qcow2 --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=access-101 --graphics none  --location /var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso --extra-args console=ttyS0

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

بعد التثبيت الناجح ، يجب أن يكون لديك جهاز افتراضي يمكنك تثبيته تحت السحاب

[root@hp-gen9 bormoglotx]# virsh list
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 62    undercloud                     running

أولاً نقوم بتثبيت الأدوات اللازمة أثناء عملية التثبيت:

sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool

تركيب Undercloud

نقوم بإنشاء مستخدم مكدس ، وتعيين كلمة مرور ، وإضافتها إلى sudoer ومنحه القدرة على تنفيذ أوامر الجذر من خلال sudo دون الحاجة إلى إدخال كلمة مرور:

useradd stack
passwd stack

echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stack

الآن نحدد الاسم الكامل لـ undercloud في ملف المضيفين:

vi /etc/hosts

127.0.0.1   undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

بعد ذلك ، أضف المستودعات وقم بتثبيت البرنامج الذي نحتاجه:

sudo yum install -y https://trunk.rdoproject.org/centos7/current/python2-tripleo-repos-0.0.1-0.20200409224957.8bac392.el7.noarch.rpm
sudo -E tripleo-repos -b queens current
sudo -E tripleo-repos -b queens current ceph
sudo yum install -y python-tripleoclient
sudo yum install -y ceph-ansible

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

بعد ذلك ، انسخ ملف التكوين undercloud إلى الدليل الرئيسي لمستخدم المكدس:

cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.conf

نحتاج الآن إلى إصلاح هذا الملف ، وتعديله حسب التثبيت الخاص بنا.

أضف الأسطر التالية إلى بداية الملف:

vi undercloud.conf
[DEFAULT]
undercloud_hostname = undercloud.openstack.rnd
local_ip = 192.168.255.1/24
network_gateway = 192.168.255.1
undercloud_public_host = 192.168.255.2
undercloud_admin_host = 192.168.255.3
undercloud_nameservers = 192.168.255.253
generate_service_certificate = false
local_interface = eth0
local_mtu = 1450
network_cidr = 192.168.255.0/24
masquerade = true
masquerade_network = 192.168.255.0/24
dhcp_start = 192.168.255.11
dhcp_end = 192.168.255.50
inspection_iprange = 192.168.255.51,192.168.255.100
scheduler_max_attempts = 10

لذلك ، دعنا ننتقل إلى الإعدادات:

undercloud_hostname - الاسم الكامل لخادم undercloud ، يجب أن يتطابق مع الإدخال على خادم DNS

local_ip - العنوان المحلي undercloud تجاه توفير الشبكة

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

undercloud_public_host - عنوان API خارجي ، يتم تعيين أي عنوان مجاني من شبكة التزويد

undercloud_admin_host عنوان API الداخلي ، يتم تعيين أي عنوان مجاني من شبكة التزويد

undercloud_nameservers - خادم DNS

توليد_شهادة_خدمة - هذا الخط مهم جدًا في المثال الحالي ، لأنه إذا لم تقم بتعيينه على خطأ ، فستتلقى خطأ في التثبيت ، ويتم وصف المشكلة في متتبع أخطاء Red Hat

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

local_mtu - MTU. نظرًا لأن لدينا معمل اختبار ولدي MTU 1500 على منافذ OVS للمحول ، فمن الضروري ضبطه على 1450 حتى تمر الحزم المغلفة في VxLAN

Network_cidr - شبكة التزويد

حفلة تنكرية - استخدام NAT للوصول إلى الشبكة الخارجية

masquerade_network - شبكة ستكون نات شيا

dhcp_start - عنوان البداية لتجمع العناوين الذي سيتم من خلاله تخصيص العناوين للعقد أثناء النشر فوق السحاب

dhcp_end - عنوان نهاية تجمع العناوين الذي سيتم من خلاله تخصيص العناوين للعقد أثناء النشر فوق السحاب

نطاق_التفتيش - مجموعة من العناوين المطلوبة للاستبطان (يجب ألا تتداخل مع المجموعة أعلاه)

جدولة_الحد الأقصى_المحاولات - الحد الأقصى لعدد محاولات التثبيت فوق السحاب (يجب أن يكون أكبر من عدد العقد أو مساويًا له)

بعد وصف الملف ، يمكنك إصدار أمر للنشر تحت السحاب:

openstack undercloud install

تستغرق العملية من 10 إلى 30 دقيقة حسب نوع المكواة. في النهاية ، يجب أن ترى الإخراج مثل هذا:

vi undercloud.conf
2020-08-13 23:13:12,668 INFO: 
#############################################################################
Undercloud install complete.

The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.

There is also a stackrc file at /home/stack/stackrc.

These files are needed to interact with the OpenStack services, and should be
secured.

#############################################################################

يوضح هذا الإخراج أنك قمت بتثبيت undercloud بنجاح ويمكنك الآن التحقق من حالة undercloud والانتقال إلى التثبيت overcloud.

إذا نظرت إلى إخراج ifconfig ، فسترى ظهور واجهة جسر جديدة

[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.1  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe2c:89e  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:2c:08:9e  txqueuelen 1000  (Ethernet)
        RX packets 14  bytes 1095 (1.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 20  bytes 1292 (1.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

من خلال هذه الواجهة ، سيتم الآن تنفيذ العمل لنشر السحاب فوق السحابي.

من الإخراج أدناه ، يمكنك أن ترى أن لدينا جميع الخدمات على نفس العقدة:

(undercloud) [stack@undercloud ~]$ openstack host list
+--------------------------+-----------+----------+
| Host Name                | Service   | Zone     |
+--------------------------+-----------+----------+
| undercloud.openstack.rnd | conductor | internal |
| undercloud.openstack.rnd | scheduler | internal |
| undercloud.openstack.rnd | compute   | nova     |
+--------------------------+-----------+----------+

فيما يلي تكوين جزء شبكة undercloud:

(undercloud) [stack@undercloud ~]$ python -m json.tool /etc/os-net-config/config.json 
{
    "network_config": [
        {
            "addresses": [
                {
                    "ip_netmask": "192.168.255.1/24"
                }
            ],
            "members": [
                {
                    "dns_servers": [
                        "192.168.255.253"
                    ],
                    "mtu": 1450,
                    "name": "eth0",
                    "primary": "true",
                    "type": "interface"
                }
            ],
            "mtu": 1450,
            "name": "br-ctlplane",
            "ovs_extra": [
                "br-set-external-id br-ctlplane bridge-id br-ctlplane"
            ],
            "routes": [],
            "type": "ovs_bridge"
        }
    ]
}
(undercloud) [stack@undercloud ~]$

التثبيت فوق السحاب

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

انتقل إلى المجلد الذي يحتوي على أقراص أجهزتنا الافتراضية وأنشئ أقراصًا بالحجم المطلوب:

cd /var/lib/libvirt/images/
qemu-img create -f qcow2 -o preallocation=metadata control-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-2.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata storage-1.qcow2 160G
qemu-img create -f qcow2 -o preallocation=metadata storage-2.qcow2 160G

نظرًا لأننا نتصرف كجذر ، فنحن بحاجة إلى تغيير مالك هذه الأقراص حتى لا نواجه مشكلة في الحقوق:

[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 root root  61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 root root  61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 root root  61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:07 undercloud.qcow2
[root@hp-gen9 images]# 
[root@hp-gen9 images]# 
[root@hp-gen9 images]# chown qemu:qemu /var/lib/libvirt/images/*qcow2
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:08 undercloud.qcow2
[root@hp-gen9 images]# 

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

رائع ، نحتاج الآن إلى تحديد كل هذه الآلات:

virt-install --name control-1 --ram 32768 --vcpus 8 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/control-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=trunk-1 --dry-run --print-xml > /tmp/control-1.xml  

virt-install --name storage-1 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-1.xml  

virt-install --name storage-2 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-2.xml  

virt-install --name compute-1 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-1.xml  

virt-install --name compute-2 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-2.xml 

في النهاية توجد أوامر -print-xml> /tmp/storage-1.xml ، والتي تُنشئ ملف xml مع وصف كل جهاز في المجلد / tmp / ، إذا لم تقم بإضافته ، فلن تكون قادرًا على ذلك لتحديد الأجهزة الافتراضية.

نحتاج الآن إلى تحديد كل هذه الآلات في virsh:

virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml

[root@hp-gen9 ~]# virsh list --all
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 -     compute-1                      shut off
 -     compute-2                      shut off
 -     control-1                      shut off
 -     storage-1                      shut off
 -     storage-2                      shut off

[root@hp-gen9 ~]#

الآن فارق بسيط - يستخدم tripleO IPMI من أجل إدارة الخوادم أثناء التثبيت والاستبطان.

الاستبطان هو عملية فحص الأجهزة من أجل الحصول على المعلمات اللازمة لتوفير المزيد من العقد. يتم إجراء الاستبطان بمساعدة خدمة Ironic ، وهي خدمة مصممة للعمل مع الخوادم المعدنية.

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

تثبيت vbmc:

yum install yum install python2-virtualbmc

إذا لم يتمكن نظام التشغيل لديك من العثور على الحزمة ، فقم بإضافة المستودع:

yum install -y https://www.rdoproject.org/repos/rdo-release.rpm

لنقم الآن بإعداد الأداة المساعدة. كل شيء هنا عادي للعار. الآن من المنطقي عدم وجود خوادم في قائمة vbmc

[root@hp-gen9 ~]# vbmc list

[root@hp-gen9 ~]# 

لكي تظهر ، يجب التصريح عنها يدويًا بهذه الطريقة:

[root@hp-gen9 ~]# vbmc add control-1 --port 7001 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-1 --port 7002 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-2 --port 7003 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-1 --port 7004 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-2 --port 7005 --username admin --password admin
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+--------+---------+------+
| Domain name | Status | Address | Port |
+-------------+--------+---------+------+
| compute-1   | down   | ::      | 7004 |
| compute-2   | down   | ::      | 7005 |
| control-1   | down   | ::      | 7001 |
| storage-1   | down   | ::      | 7002 |
| storage-2   | down   | ::      | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#

أعتقد أن بناء جملة الأمر واضح دون تفسير. ومع ذلك ، في الوقت الحالي ، جميع جلساتنا في حالة DOWN. لكي ينتقلوا إلى حالة UP ، تحتاج إلى تمكينهم:

[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Started vBMC instance for domain control-1
[root@hp-gen9 ~]# vbmc start storage-1 
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-2
[root@hp-gen9 ~]# 
[root@hp-gen9 ~]# 
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status  | Address | Port |
+-------------+---------+---------+------+
| compute-1   | running | ::      | 7004 |
| compute-2   | running | ::      | 7005 |
| control-1   | running | ::      | 7001 |
| storage-1   | running | ::      | 7002 |
| storage-2   | running | ::      | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#

واللمسة الأخيرة - تحتاج إلى إصلاح قواعد جدار الحماية (حسنًا ، أو إيقاف تشغيله تمامًا):

firewall-cmd --zone=public --add-port=7001/udp --permanent
firewall-cmd --zone=public --add-port=7002/udp --permanent
firewall-cmd --zone=public --add-port=7003/udp --permanent
firewall-cmd --zone=public --add-port=7004/udp --permanent
firewall-cmd --zone=public --add-port=7005/udp --permanent
firewall-cmd --reload

الآن دعنا نذهب إلى undercloud ونتحقق من أن كل شيء يعمل. عنوان الجهاز المضيف هو 192.168.255.200 ، أضفنا حزمة ipmitool الضرورية إلى السحاب أثناء التحضير للنشر:

[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status          
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$ 

[root@hp-gen9 ~]# virsh list 
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 65    control-1                      running

كما ترى ، لقد أطلقنا بنجاح عقدة التحكم عبر vbmc. الآن قم بإيقاف تشغيله والمضي قدمًا:

[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassis Power Control: Down/Off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ 

[root@hp-gen9 ~]# virsh list --all
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 -     compute-1                      shut off
 -     compute-2                      shut off
 -     control-1                      shut off
 -     storage-1                      shut off
 -     storage-2                      shut off

[root@hp-gen9 ~]#

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

[root@hp-gen9 ~]# virsh domiflist --domain control-1 
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:20:a2:2f
-          network    ovs-network-1 virtio      52:54:00:3f:87:9f

[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:98:e9:d6

[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:6a:ea:be

[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:79:0b:cb

[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:a7:fe:27

ملاحظة: هناك نوعان من الواجهات على عقدة التحكم ، ولكن في هذه الحالة لا يهم ، في هذا التثبيت واحدة كافية بالنسبة لنا.

الآن نقوم بإعداد ملف json. نحتاج إلى تحديد عنوان الخشخاش للمنفذ الذي سيتم من خلاله تنفيذ التزويد ، ومعلمات العقد ، ومنحهم أسماء وبيان كيفية الوصول إلى ipmi:

{
    "nodes":[
        {
            "mac":[
                "52:54:00:20:a2:2f"
            ],
            "cpu":"8",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"control-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7001"
        },
        {
            "mac":[
                "52:54:00:79:0b:cb"
            ],
            "cpu":"4",
            "memory":"16384",
            "disk":"160",
            "arch":"x86_64",
            "name":"storage-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7002"
        },
        {
            "mac":[
                "52:54:00:a7:fe:27"
            ],
            "cpu":"4",
            "memory":"16384",
            "disk":"160",
            "arch":"x86_64",
            "name":"storage-2",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7003"
        },
        {
            "mac":[
                "52:54:00:98:e9:d6"
            ],
            "cpu":"12",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"compute-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7004"
        },
        {
            "mac":[
                "52:54:00:6a:ea:be"
            ],
            "cpu":"12",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"compute-2",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7005"
        }
    ]
}

الآن نحن بحاجة إلى تجهيز الصور للسخرية. للقيام بذلك ، قم بتنزيلها عبر wget وقم بالتثبيت:

(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/overcloud-full.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/ironic-python-agent.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ ls -lh
total 1.9G
-rw-r--r--. 1 stack stack 447M Aug 14 10:26 ironic-python-agent.tar
-rw-r--r--. 1 stack stack 1.5G Aug 14 10:26 overcloud-full.tar
-rw-------. 1 stack stack  916 Aug 13 23:10 stackrc
-rw-r--r--. 1 stack stack  15K Aug 13 22:50 undercloud.conf
-rw-------. 1 stack stack 2.0K Aug 13 22:50 undercloud-passwords.conf
(undercloud) [stack@undercloud ~]$ mkdir images/
(undercloud) [stack@undercloud ~]$ tar -xpvf ironic-python-agent.tar -C ~/images/
ironic-python-agent.initramfs
ironic-python-agent.kernel
(undercloud) [stack@undercloud ~]$ tar -xpvf overcloud-full.tar -C ~/images/                       
overcloud-full.qcow2
overcloud-full.initrd
overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$ 
(undercloud) [stack@undercloud ~]$ ls -lh images/
total 1.9G
-rw-rw-r--. 1 stack stack 441M Aug 12 17:24 ironic-python-agent.initramfs
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:24 ironic-python-agent.kernel
-rw-r--r--. 1 stack stack  53M Aug 12 17:14 overcloud-full.initrd
-rw-r--r--. 1 stack stack 1.4G Aug 12 17:18 overcloud-full.qcow2
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:14 overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$

تحميل الصور إلى undercloud:

(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
|                  ID                  |          Name          | Disk Format |   Size  | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz |     aki     | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
|                  ID                  |          Name         | Disk Format |   Size   | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd |     ari     | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
|                  ID                  |      Name      | Disk Format |    Size    | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full |    qcow2    | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
|                  ID                  |       Name       | Disk Format |   Size  | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel |     aki     | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
|                  ID                  |        Name       | Disk Format |    Size   | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk |     ari     | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$

تحقق من تحميل جميع الصور

(undercloud) [stack@undercloud ~]$  openstack image list
+--------------------------------------+------------------------+--------+
| ID                                   | Name                   | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel       | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk      | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full         | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd  | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$

لمسة أخرى - تحتاج إلى إضافة خادم DNS:

(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID                                   | Name            | Network                              | Subnet           |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field             | Value                                                     |
+-------------------+-----------------------------------------------------------+
| allocation_pools  | 192.168.255.11-192.168.255.50                             |
| cidr              | 192.168.255.0/24                                          |
| created_at        | 2020-08-13T20:10:37Z                                      |
| description       |                                                           |
| dns_nameservers   |                                                           |
| enable_dhcp       | True                                                      |
| gateway_ip        | 192.168.255.1                                             |
| host_routes       | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id                | f45dea46-4066-42aa-a3c4-6f84b8120cab                      |
| ip_version        | 4                                                         |
| ipv6_address_mode | None                                                      |
| ipv6_ra_mode      | None                                                      |
| name              | ctlplane-subnet                                           |
| network_id        | 6ca013dc-41c2-42d8-9d69-542afad53392                      |
| prefix_length     | None                                                      |
| project_id        | a844ccfcdb2745b198dde3e1b28c40a3                          |
| revision_number   | 0                                                         |
| segment_id        | None                                                      |
| service_types     |                                                           |
| subnetpool_id     | None                                                      |
| tags              |                                                           |
| updated_at        | 2020-08-13T20:10:37Z                                      |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$ 
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253                                    
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$

الآن يمكننا أن نأمر بالاستبطان:

(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json 
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.


5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$

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

(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID                                 | Name      | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None          | power off   | available          | False       |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None          | power off   | available          | False       |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None          | power off   | available          | False       |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None          | power off   | available          | False       |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None          | power off   | available          | False       |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ 

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

بعد ذلك ، نحتاج إلى تحديد العقدة التي ستؤدي الوظيفة - أي تحديد ملف التعريف الذي ستنشر العقدة به:

(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID                            | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available       | None            |                   |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available       | None            |                   |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available       | None            |                   |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available       | None            |                   |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available       | None            |                   |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID                                   | Name          |  RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 |   40 |         0 |     1 | True      |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal     | 4096 |   40 |         0 |     1 | True      |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control       | 4096 |   40 |         0 |     1 | True      |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 |   40 |         0 |     1 | True      |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute       | 4096 |   40 |         0 |     1 | True      |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage  | 4096 |   40 |         0 |     1 | True      |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$

حدد ملف تعريف لكل عقدة:

openstack baremetal node set --property capabilities='profile:control,boot_option:local' b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' b89a72a3-6bb7-429a-93bc-48393d225838
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 766ab623-464c-423d-a529-d9afb69d1167

نتحقق من أننا فعلنا كل شيء بشكل صحيح:

(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID                            | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available       | control         |                   |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available       | ceph-storage    |                   |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available       | ceph-storage    |                   |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available       | compute         |                   |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available       | compute         |                   |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$

إذا كان كل شيء صحيحًا ، فإننا نعطي الأمر للنشر فوق السحاب:

openstack overcloud deploy --templates --control-scale 1 --compute-scale 2  --ceph-storage-scale 2 --control-flavor control --compute-flavor compute  --ceph-storage-flavor ceph-storage --libvirt-type qemu

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

ملاحظة: مطلوب متغير qemu من نوع --libvirt في هذه الحالة لأننا سنستخدم المحاكاة الافتراضية المتداخلة. خلاف ذلك ، لن تقوم بتشغيل الأجهزة الافتراضية.

الآن لديك حوالي ساعة ، أو ربما أكثر (حسب إمكانيات المكواة) ولا يسعك إلا أن تأمل أنه بعد هذا الوقت سترى هذا النقش:

2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE  Stack CREATE completed successfully

 Stack overcloud CREATE_COMPLETE 

Host 192.168.255.21 not found in /home/stack/.ssh/known_hosts
Started Mistral Workflow tripleo.deployment.v1.get_horizon_url. Execution ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$

الآن لديك نسخة كاملة تقريبًا من المكدس المفتوح ، حيث يمكنك الدراسة والتجربة وما إلى ذلك.

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

(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID                                   | Name                    | Status | Networks                | Image          | Flavor       |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0  | ACTIVE | ctlplane=192.168.255.15 | overcloud-full | control      |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.168.255.26 | overcloud-full | compute      |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | ACTIVE | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.255.19 | overcloud-full | compute      |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | ACTIVE | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$ 

(undercloud) [stack@undercloud ~]$ source overcloudrc 
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID                               | Name    |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin   |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ openstack network agent list  
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID                                   | Agent Type         | Host                                | Availability Zone | Alive | State | Binary                    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent           | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-l3-agent          |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent         | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-dhcp-agent        |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent     | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-metadata-agent    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$

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

(undercloud) [stack@undercloud ~]$ ssh [email protected]         
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254

حسنًا ، الآن يمكنك الذهاب إلى الأفق. جميع المعلومات - العناوين وتسجيل الدخول وكلمة المرور - موجودة في الملف / home / stack / overcloudrc. يبدو المخطط النهائي كما يلي:

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

كيف تتدفق حركة المرور بين الأجهزة الافتراضية؟

في هذه المقالة ، سننظر في ثلاثة خيارات لتمرير حركة المرور

• جهازان على جهاز مراقبة واحد في شبكة L2 واحدة
• جهازان على برامج Hypervisor مختلفة في نفس شبكة L2
• جهازان على شبكات مختلفة (تجذير عبر الشبكة)

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

للاختبار ، دعنا نجمع المخطط التالي:

لقد أنشأنا 4 أجهزة افتراضية - 3 في نفس شبكة L2 - net-1 ، وواحدة أخرى في شبكة net-1

(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c             
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID                                   | Name | Tenant ID                        | Status | Task State | Power State | Networks        |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-2=10.0.2.8  |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ 

دعونا نرى ما هي برامج Hypervisor الموجودة على الأجهزة التي تم إنشاؤها:

(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-1                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-0.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000001                                        |

(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-2                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-1.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000002                                        |

(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-3                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-0.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000003                                        |

(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-4                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-1.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000004                                        |

(overcloud) [stack@undercloud ~]$
توجد الأجهزة vm-1 و vm-3 في الحوسبة 0 ، والآلات vm-2 و vm-4 موجودة في حساب العقدة -1.

بالإضافة إلى ذلك ، تم إنشاء جهاز توجيه افتراضي لتمكين التوجيه بين الشبكات المحددة:

(overcloud) [stack@undercloud ~]$ openstack router list  --project 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| ID                                   | Name     | Status | State | Distributed | HA    | Project                          |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | router-1 | ACTIVE | UP    | False       | False | 5e18ce8ec9594e00b155485f19895e6c |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
(overcloud) [stack@undercloud ~]$ 

يحتوي جهاز التوجيه على منفذين افتراضيين يعملان كبوابات للشبكات:

(overcloud) [stack@undercloud ~]$ openstack router show 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | grep interface
| interfaces_info         | [{"subnet_id": "2529ad1a-6b97-49cd-8515-cbdcbe5e3daa", "ip_address": "10.0.1.254", "port_id": "0c52b15f-8fcc-4801-bf52-7dacc72a5201"}, {"subnet_id": "335552dd-b35b-456b-9df0-5aac36a3ca13", "ip_address": "10.0.2.254", "port_id": "92fa49b5-5406-499f-ab8d-ddf28cc1a76c"}] |
(overcloud) [stack@undercloud ~]$ 

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

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:3 missed:3
  br-ex:
    br-ex 65534/1: (internal)
    phy-br-ex 1/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/2: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
  br-tun:
    br-tun 65534/3: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$

يوجد حاليًا ثلاثة جسور ovs على العقدة - br-int ، br-tun ، br-ex. بينهما ، كما نرى ، هناك مجموعة من الواجهات. لتسهيل الإدراك ، دعنا نضع كل هذه الواجهات على الرسم التخطيطي ونرى ما سيحدث.

من العناوين التي يتم رفع أنفاق VxLAN إليها ، يمكن ملاحظة أن أحد النفق مرفوع على حساب 1 (192.168.255.26) ، والنفق الثاني ينظر إلى control-1 (192.168.255.15). لكن الشيء الأكثر إثارة للاهتمام هو أن br-ex لا يحتوي على واجهات فعلية ، وإذا نظرت إلى التدفقات التي تم تكوينها ، يمكنك أن ترى أن هذا الجسر يمكنه فقط إسقاط حركة المرور في الوقت الحالي.

[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.19  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe6a:eabe  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:6a:ea:be  txqueuelen 1000  (Ethernet)
        RX packets 2909669  bytes 4608201000 (4.2 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1821057  bytes 349198520 (333.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-novacompute-0 ~]$ 

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

[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-appctl fdb/show br-ex
 port  VLAN  MAC                Age
[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-ofctl dump-flows br-ex
 cookie=0x9169eae8f7fe5bb2, duration=216686.864s, table=0, n_packets=303, n_bytes=26035, priority=2,in_port="phy-br-ex" actions=drop
 cookie=0x9169eae8f7fe5bb2, duration=216686.887s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL
[heat-admin@overcloud-novacompute-0 ~]$ 

وفقًا للقاعدة الأولى ، يجب التخلص من كل ما يأتي من منفذ phy-br-ex.
في الواقع ، لا يوجد مكان آخر لتوصيل حركة المرور إلى هذا الجسر حتى الآن ، باستثناء من هذه الواجهة (تقاطع مع br-int) ، واستنادًا إلى القطرات ، وصلت حركة مرور BUM بالفعل إلى الجسر.

أي أن حركة المرور من هذه العقدة لا يمكن أن تغادر إلا عبر نفق VxLAN ولا شيء غير ذلك. ومع ذلك ، إذا قمت بتشغيل DVR ، فسيتغير الوضع ، لكننا سنتعامل مع هذا مرة أخرى. عند استخدام عزل الشبكة ، على سبيل المثال ، باستخدام vlans ، لن يكون لديك واجهة L3 واحدة في 0th vlan ، ولكن عدة واجهات. ومع ذلك ، ستخرج حركة مرور VxLAN من العقدة بنفس الطريقة تمامًا ، ولكن يتم تغليفها أيضًا في بعض شبكات محلية ظاهرية مخصصة.

اكتشفنا عقدة الحساب ، انتقل إلى عقدة التحكم.

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
  br-ex:
    br-ex 65534/1: (internal)
    eth0 1/2: (system)
    phy-br-ex 2/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/3: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
  br-tun:
    br-tun 65534/4: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff13 3/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.19)
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$

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

[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.15  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe20:a22f  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:20:a2:2f  txqueuelen 1000  (Ethernet)
        RX packets 803859  bytes 1732616116 (1.6 GiB)
        RX errors 0  dropped 63  overruns 0  frame 0
        TX packets 808475  bytes 121652156 (116.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
 port  VLAN  MAC                Age
    3   100  28:c0:da:00:4d:d3   35
    1     0  28:c0:da:00:4d:d3   35
    1     0  52:54:00:98:e9:d6    0
LOCAL     0  52:54:00:20:a2:2f    0
    1     0  52:54:00:2c:08:9e    0
    3   100  52:54:00:20:a2:2f    0
    1     0  52:54:00:6a:ea:be    0
[heat-admin@overcloud-controller-0 ~]$ 

يرتبط هذا المنفذ بجسر br-ex وبما أنه لا يحتوي على أي علامات vlan ، فإن هذا المنفذ عبارة عن منفذ trunk يُسمح فيه بجميع شبكات vlans ، والآن تخرج حركة المرور بدون علامة ، كما هو موضح بواسطة vlan-id 0 in الإخراج أعلاه.

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

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

اكتشفنا ما لدينا على العقد في حالة عدم وجود أي خدمات. لنقم الآن بتشغيل 4 أجهزة افتراضية ونرى كيف يتغير المخطط الموصوف أعلاه - يجب أن يكون لدينا منافذ وأجهزة توجيه افتراضية وما إلى ذلك.

حتى الآن تبدو شبكتنا كما يلي:

لدينا جهازان ظاهريان على كل عقدة كمبيوتر. باستخدام compute-0 كمثال ، دعنا نرى كيف يتم تضمين كل شيء.

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list 
 Id    Name                           State
----------------------------------------------------
 1     instance-00000001              running
 3     instance-00000003              running

[heat-admin@overcloud-novacompute-0 ~]$ 

يحتوي الجهاز على واجهة افتراضية واحدة فقط - Tap95d96a75-a0:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 

تبدو هذه الواجهة في جسر لينكس:

[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.0242904c92a8       no
qbr5bd37136-47          8000.5e4e05841423       no              qvb5bd37136-47
                                                        tap5bd37136-47
qbr95d96a75-a0          8000.de076cb850f6       no              qvb95d96a75-a0
                                                        tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ 

كما ترى من الإخراج ، لا يوجد سوى واجهتين في الجسر - tap95d96a75-a0 و qvb95d96a75-a0.

هنا يجدر بنا أن نتحدث قليلاً عن أنواع أجهزة الشبكة الافتراضية في OpenStack:
vtap هي واجهة افتراضية متصلة بمثيل (VM)
qbr - لينكس بريدج
زوج qvb و qvo - vEth متصلان بجسر Linux و Open vSwitch bridge
br-int ، br-tun ، br-vlan - جسور vSwitch المفتوحة
patch-، int-br-، phy-br- - فتح واجهات تصحيح vSwitch التي تربط الجسور
qg ، qr ، ha ، fg ، sg - فتح منافذ vSwitch التي تستخدمها الأجهزة الافتراضية للاتصال بـ OVS

كما تفهم ، إذا كان لدينا منفذ qvb95d96a75-a0 في الجسر ، وهو زوج vEth ، فهناك مكان ما يوجد نظيره ، والذي يجب أن يسمى منطقيًا qvo95d96a75-a0. نحن ننظر إلى المنافذ الموجودة على OVS.

[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:526 missed:91
  br-ex:
    br-ex 65534/1: (internal)
    phy-br-ex 1/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/2: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
    qvo5bd37136-47 6/6: (system)
    qvo95d96a75-a0 3/5: (system)
  br-tun:
    br-tun 65534/3: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ 

كما يمكننا أن نرى المنفذ في br-int. يعمل Br-int كمفتاح ينهي منافذ الجهاز الظاهري. بالإضافة إلى qvo95d96a75-a0 ، يكون منفذ qvo5bd37136-47 مرئيًا في الإخراج. هذا منفذ للجهاز الظاهري الثاني. نتيجة لذلك ، يبدو مخططنا الآن كما يلي:

السؤال الذي يجب أن يثير اهتمام القارئ المنتبه على الفور هو ما هو جسر لينكس بين منفذ الجهاز الظاهري ومنفذ OVS؟ الحقيقة هي أن مجموعات الأمان تُستخدم لحماية الجهاز ، وهي ليست أكثر من iptables. لا تعمل OVS مع iptables ، لذلك تم اختراع مثل هذا "العكاز". ومع ذلك ، فقد أصبح عفا عليه الزمن - تم استبداله بكون تراك في الإصدارات الجديدة.

هذا هو ، في النهاية ، المخطط يبدو كما يلي:

جهازان على جهاز مراقبة واحد في شبكة L2 واحدة

نظرًا لأن هذين الجهازين الظاهريين موجودان في نفس شبكة L2 وعلى نفس برنامج Hypervisor ، فسيكون من المنطقي أن تنتقل حركة المرور بينهما محليًا عبر br-int ، نظرًا لأن كلا الجهازين سيكونان في نفس شبكة VLAN:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000003
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap5bd37136-47 bridge     qbr5bd37136-47 virtio      fa:16:3e:83:ad:a4

[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int 
 port  VLAN  MAC                Age
    6     1  fa:16:3e:83:ad:a4    0
    3     1  fa:16:3e:44:98:20    0
[heat-admin@overcloud-novacompute-0 ~]$ 

جهازان على برامج Hypervisor مختلفة في نفس شبكة L2

لنرى الآن كيف ستنتقل حركة المرور بين جهازين في نفس شبكة L2 ، ولكنهما موجودان على أجهزة Hypervisor مختلفة. لنكون صادقين ، لن يتغير شيء كثيرًا ، فقط حركة المرور بين برامج Hypervisor ستمر عبر نفق vxlan. لنلقي نظرة على مثال.

عناوين الأجهزة الافتراضية التي سنراقب من خلالها حركة المرور:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 

[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tape7e23f1b-07 bridge     qbre7e23f1b-07 virtio      fa:16:3e:72:ad:53

[heat-admin@overcloud-novacompute-1 ~]$ 

ننظر إلى جدول إعادة التوجيه في br-int على compute-0:

[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
    2     1  fa:16:3e:72:ad:53    1
[heat-admin@overcloud-novacompute-0 ~]

يجب أن تذهب حركة المرور إلى المنفذ 2 - انظر إلى المنفذ:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:7e:7f:28:1f:bd:54
 2(patch-tun): addr:0a:bd:07:69:58:d9
 3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
 6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
 LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$

هذا هو patch-tun - أي الواجهة في br-tun. دعونا نرى ما سيحدث مع الحزمة على br-tun:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:72:ad:53
 cookie=0x8759a56536b67a8e, duration=1387.959s, table=20, n_packets=1460, n_bytes=138880, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:72:ad:53 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-novacompute-0 ~]$ 

يتم تعبئة الحزمة في VxLAN وإرسالها إلى المنفذ 2. ننظر إلى أين يؤدي المنفذ 2:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-tun | grep addr   
 1(patch-int): addr:b2:d1:f8:21:96:66
 2(vxlan-c0a8ff1a): addr:be:64:1f:75:78:a7
 3(vxlan-c0a8ff0f): addr:76:6f:b9:3c:3f:1c
 LOCAL(br-tun): addr:a2:5b:6d:4f:94:47
[heat-admin@overcloud-novacompute-0 ~]$

هذا هو نفق vxlan على الحوسبة 1:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$

نذهب إلى compute-1 ونرى ما سيحدث بعد ذلك مع الحزمة:

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:44:98:20
    2     1  fa:16:3e:44:98:20    1
[heat-admin@overcloud-novacompute-1 ~]$ 

يوجد الخشخاش في جدول إعادة التوجيه br-int في compute-1 ، وكما ترى من الإخراج أعلاه ، يمكن رؤيته من خلال المنفذ 2 ، وهو المنافذ باتجاه br-tun:

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr   
 1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
 2(patch-tun): addr:46:cc:40:bd:20:da
 3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
 4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
 LOCAL(br-int): addr:e2:27:b2:ed:14:46

حسنًا ، ثم ننظر إلى أن هناك وجهة الخشخاش في br-int في compute-1:

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:72:ad:53
    3     1  fa:16:3e:72:ad:53    0
[heat-admin@overcloud-novacompute-1 ~]$ 

أي أن الحزمة المستلمة ستنتقل إلى المنفذ 3 ، والذي يوجد خلفه بالفعل مثيل الجهاز الظاهري 00000003.

يكمن جمال نشر Openstack للدراسة على بنية تحتية افتراضية في أنه يمكننا بسهولة رصد حركة المرور بين برامج Hypervisor ومعرفة ما سيحدث لها. هذا ما سنفعله الآن ، قم بتشغيل tcpdump على منفذ vnet نحو الحوسبة 0:

[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes

*****************omitted*******************

04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
	
*****************omitted*******************

يوضح السطر الأول أن الحزمة من العنوان 10.0.1.85 تنتقل إلى العنوان 10.0.1.88 (حركة مرور ICMP) ، ويتم تغليفها في حزمة VxLAN مع vni 22 وتنتقل الحزمة من المضيف 192.168.255.19 (الحوسبة -0) إلى المضيف 192.168.255.26 (حساب 1). يمكننا التحقق من تطابق VNI مع المحدد في ovs.

دعنا نعود إلى إجراءات السطر هذه = تحميل: 0-> NXM_OF_VLAN_TCI [] ، حمل: 0x16-> NXM_NX_TUN_ID [] ، الإخراج: 2. 0x16 هو vni في نظام الأرقام الست عشري. لنحول هذا الرقم إلى النظام العاشر:

16 = 6*16^0+1*16^1 = 6+16 = 22

هذا هو ، vni صحيح.

يُظهر السطر الثاني حركة المرور العكسية ، حسنًا ، ليس من المنطقي شرح ذلك هناك ، وبالتالي فإن كل شيء واضح.

جهازان على شبكات مختلفة (التوجيه بين الشبكات)

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

أولاً ، دعنا نرى أن التوجيه يعمل:

$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 ms

نظرًا لأنه في هذه الحالة يجب أن تذهب الحزمة إلى البوابة ويتم توجيهها إلى هناك ، نحتاج إلى معرفة عنوان الخشخاش للبوابة ، والتي سننظر فيها إلى جدول ARP في المثال:

$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether]  on eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether]  on eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether]  on eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether]  on eth0

لنرى الآن أين يجب إرسال حركة المرور مع الوجهة (10.0.1.254) fa: 16: 3e: c4: 64: 70:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
    2     1  fa:16:3e:c4:64:70    0
[heat-admin@overcloud-novacompute-0 ~]$ 

ننظر إلى أين يؤدي المنفذ 2:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:7e:7f:28:1f:bd:54
 2(patch-tun): addr:0a:bd:07:69:58:d9
 3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
 6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
 LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$ 

كل شيء منطقي ، تذهب حركة المرور إلى br-tun. دعونا نرى أي نفق vxlan سيتم لفه:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:c4:64:70
 cookie=0x8759a56536b67a8e, duration=3514.566s, table=20, n_packets=3368, n_bytes=317072, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:c4:64:70 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3
[heat-admin@overcloud-novacompute-0 ~]$ 

المنفذ الثالث هو نفق vxlan:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
 1(patch-int): addr:a2:69:00:c5:fa:ba
 2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
 3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
 LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ 

الذي ينظر إلى عقدة التحكم:

[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 

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

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

لذلك ، من الواضح ، يجب أن يكون عنوان البوابة الخشخاش في جدول إعادة توجيه br-int على عقدة التحكم. دعنا نتحقق من وجودها وأين تبدو:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:c4:64:70
    5     1  fa:16:3e:c4:64:70    1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$  sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:2e:58:b6:db:d5:de
 2(patch-tun): addr:06:41:90:f0:9e:56
 3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
 4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
 5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
 6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
 LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ 

يكون جهاز Mac مرئيًا من المنفذ qr-0c52b15f-8f. بالعودة إلى قائمة المنافذ الافتراضية في Openstack ، يتم استخدام نوع المنفذ هذا لتوصيل العديد من الأجهزة الافتراضية بـ OVS. لكي نكون أكثر دقة ، فإن qr هو المنفذ نحو جهاز التوجيه الظاهري ، والذي يتم تمثيله كمساحة اسم.

دعونا نرى ما هي مساحة الاسم على الخادم:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ 

هناك ثلاث نسخ. لكن بناءً على الأسماء ، يمكنك تخمين الغرض من كل منها. سنعود إلى المثيلات ذات المعرف 0 و 1 لاحقًا ، والآن نحن مهتمون بمساحة الاسم qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ip route
10.0.1.0/24 dev qr-0c52b15f-8f proto kernel scope link src 10.0.1.254 
10.0.2.0/24 dev qr-92fa49b5-54 proto kernel scope link src 10.0.2.254 
[heat-admin@overcloud-controller-0 ~]$ 

في مساحة الاسم هذه ، هناك نوعان داخليان أنشأناهما سابقًا. تمت إضافة كلا المنفذين الظاهريين إلى br-int. دعنا نتحقق من عنوان منفذ MAC qr-0c52b15f-8f ، نظرًا لأن حركة المرور ، بناءً على عنوان MAC الوجهة ، انتقلت إلى هذه الواجهة.

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.0.1.254  netmask 255.255.255.0  broadcast 10.0.1.255
        inet6 fe80::f816:3eff:fec4:6470  prefixlen 64  scopeid 0x20<link>
        ether fa:16:3e:c4:64:70  txqueuelen 1000  (Ethernet)
        RX packets 5356  bytes 427305 (417.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5195  bytes 490603 (479.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-controller-0 ~]$ 

وهذا يعني ، في هذه الحالة ، أن كل شيء يعمل وفقًا لقوانين التوجيه القياسي. نظرًا لأن حركة المرور مخصصة للمضيف 10.0.2.8 ، يجب أن تخرج من خلال الواجهة الثانية qr-92fa49b5-54 وتنتقل عبر نفق vxlan إلى عقدة الحساب:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe arp
Address                  HWtype  HWaddress           Flags Mask            Iface
10.0.1.88                ether   fa:16:3e:72:ad:53   C                     qr-0c52b15f-8f
10.0.1.90                ether   fa:16:3e:83:ad:a4   C                     qr-0c52b15f-8f
10.0.2.8                 ether   fa:16:3e:6c:ad:9c   C                     qr-92fa49b5-54
10.0.2.42                ether   fa:16:3e:f5:0b:29   C                     qr-92fa49b5-54
10.0.1.85                ether   fa:16:3e:44:98:20   C                     qr-0c52b15f-8f
[heat-admin@overcloud-controller-0 ~]$ 

كل شيء منطقي ، ولا مفاجآت. ننظر من حيث يظهر عنوان الخشخاش للمضيف 10.0.2.8 في br-int:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
    2     2  fa:16:3e:6c:ad:9c    1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:2e:58:b6:db:d5:de
 2(patch-tun): addr:06:41:90:f0:9e:56
 3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
 4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
 5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
 6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
 LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ 

كما هو متوقع ، تنتقل حركة المرور إلى br-tun ، فلنرى النفق الذي ستنتقل إليه حركة المرور بعد ذلك:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:6c:ad:9c
 cookie=0x2ab04bf27114410e, duration=5346.829s, table=20, n_packets=5248, n_bytes=498512, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0002/0x0fff,dl_dst=fa:16:3e:6c:ad:9c actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
 1(patch-int): addr:a2:69:00:c5:fa:ba
 2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
 3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
 LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 

تذهب حركة المرور إلى النفق لحساب -1. حسنًا ، في compute-1 ، كل شيء بسيط - بدءًا من br-tun تصل الحزمة إلى br-int ومن هناك إلى واجهة الجهاز الظاهري:

[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
    4     2  fa:16:3e:6c:ad:9c    1
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr                  
 1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
 2(patch-tun): addr:46:cc:40:bd:20:da
 3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
 4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
 LOCAL(br-int): addr:e2:27:b2:ed:14:46
[heat-admin@overcloud-novacompute-1 ~]$ 

دعنا نتحقق من أن هذه هي بالفعل الواجهة الصحيحة:

[heat-admin@overcloud-novacompute-1 ~]$ brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.02429c001e1c       no
qbr3210e8ec-c0          8000.ea27f45358be       no              qvb3210e8ec-c0
                                                        tap3210e8ec-c0
qbre7e23f1b-07          8000.b26ac0eded8a       no              qvbe7e23f1b-07
                                                        tape7e23f1b-07
[heat-admin@overcloud-novacompute-1 ~]$ 
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000004
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap3210e8ec-c0 bridge     qbr3210e8ec-c0 virtio      fa:16:3e:6c:ad:9c

[heat-admin@overcloud-novacompute-1 ~]$

في الواقع ، لقد قطعنا طريقنا بالكامل. أعتقد أنك لاحظت أن حركة المرور مرت عبر أنفاق vxlan مختلفة وخرجت باستخدام VNIs مختلفة. دعونا نرى ما هي VNIs ، وبعد ذلك سنجمع تفريغًا على منفذ التحكم في العقدة ونتأكد من أن حركة المرور تسير تمامًا كما هو موضح أعلاه.
لذا فإن النفق المراد حساب 0 له الإجراءات التالية = تحميل: 0-> NXM_OF_VLAN_TCI [] ، تحميل: 0x16-> NXM_NX_TUN_ID [] ، الإخراج: 3. دعنا نترجم 0x16 إلى نظام الأرقام العشري:

0x16 = 6*16^0+1*16^1 = 6+16 = 22

يحتوي النفق المراد حسابه -1 على VNI التالي: الإجراءات = التحميل: 0-> NXM_OF_VLAN_TCI [] ، التحميل: 0x63-> NXM_NX_TUN_ID [] ، الإخراج: 2. دعنا نترجم 0x63 إلى نظام الأرقام العشري:

0x63 = 3*16^0+6*16^1 = 3+96 = 99

حسنًا ، لنرى الآن التفريغ:

[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4 
tcpdump: listening on vnet4, link-type EN10MB (Ethernet), capture size 262144 bytes

*****************omitted*******************

04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.19.41591 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.15.38983 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.26.42588 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.15.38983 > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
	
*****************omitted*******************

الحزمة الأولى هي حزمة vxlan من المضيف 192.168.255.19 (compute-0) لاستضافة 192.168.255.15 (control-1) مع vni 22 ، حيث يتم تعبئة حزمة ICMP من المضيف 10.0.1.85 إلى المضيف 10.0.2.8. كما حسبنا أعلاه ، تطابق vni ما رأيناه في الإخراج.

الحزمة الثانية هي حزمة vxlan من المضيف 192.168.255.15 (control-1) لاستضافة 192.168.255.26 (compute-1) مع vni 99 ، حيث يتم تعبئة حزمة ICMP من المضيف 10.0.1.85 إلى المضيف 10.0.2.8. كما حسبنا أعلاه ، تطابق vni ما رأيناه في الإخراج.

الحزمتان التاليتان هما عودة حركة المرور من 10.0.2.8 وليس 10.0.1.85.

أي ، في النهاية ، حصلنا على مخطط عقدة التحكم التالي:

يبدو أن هذا كل شيء؟ لقد نسينا مجالين:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ 

عندما تحدثنا عن بنية النظام الأساسي السحابي ، سيكون من الجيد أن تتلقى الأجهزة العناوين تلقائيًا من خادم DHCP. هذا هو خادما DHCP لشبكتنا 10.0.1.0/24 و 10.0.2.0/24.

دعونا نتحقق من أن الأمر كذلك. يوجد عنوان واحد فقط في مساحة الاسم هذه - 10.0.1.1 - عنوان خادم DHCP نفسه ، وهو مضمن أيضًا في br-int:

[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 1  bytes 28 (28.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1  bytes 28 (28.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.0.1.1  netmask 255.255.255.0  broadcast 10.0.1.255
        inet6 fe80::f816:3eff:fee6:2c5c  prefixlen 64  scopeid 0x20<link>
        ether fa:16:3e:e6:2c:5c  txqueuelen 1000  (Ethernet)
        RX packets 129  bytes 9372 (9.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 49  bytes 6154 (6.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

دعونا نرى ما إذا كانت العمليات تحتوي على qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 باسمها على عقدة التحكم:

[heat-admin@overcloud-controller-0 ~]$ ps -aux | egrep qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 
root      640420  0.0  0.0   4220   348 ?        Ss   11:31   0:00 dumb-init --single-child -- ip netns exec qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 /usr/sbin/dnsmasq -k --no-hosts --no-resolv --pid-file=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/host --addn-hosts=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/opts --dhcp-leasefile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases --dhcp-match=set:ipxe,175 --local-service --bind-dynamic --dhcp-range=set:subnet-335552dd-b35b-456b-9df0-5aac36a3ca13,10.0.2.0,static,255.255.255.0,86400s --dhcp-option-force=option:mtu,1450 --dhcp-lease-max=256 --conf-file= --domain=openstacklocal
heat-ad+  951620  0.0  0.0 112944   980 pts/0    S+   18:50   0:00 grep -E --color=auto qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
[heat-admin@overcloud-controller-0 ~]$ 

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

[heat-admin@overcloud-controller-0 ~]$ cat /var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases
1597492111 fa:16:3e:6c:ad:9c 10.0.2.8 host-10-0-2-8 01:fa:16:3e:6c:ad:9c
1597491115 fa:16:3e:76:c2:11 10.0.2.1 host-10-0-2-1 *
[heat-admin@overcloud-controller-0 ~]$

نتيجة لذلك ، نحصل على مجموعة الخدمات التالية على عقدة التحكم:

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

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

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

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

أنا لا أقوم بحملة من أجل المنتج الأول أو المنتج الثاني - أنت تختار ما تحتاجه. ولكن إذا كان لدي مثل هذا الاختيار ، فسأختار كلا الحلين - VMWare لسحابة تكنولوجيا المعلومات (الأحمال الخفيفة ، الإدارة المريحة) ، OpenStack من بعض البائعين (توفر Nokia و Juniper حلولًا جيدة جدًا للتسليم) - لسحابة Telecom. لن أستخدم Openstack لتكنولوجيا المعلومات البحتة - إنه مثل إطلاق النار على العصافير من مدفع ، لكنني لا أرى أي موانع لاستخدامه ، باستثناء التكرار. ومع ذلك ، فإن استخدام برنامج VMWare في الاتصالات - مثل سحب الأنقاض في سيارة Ford Raptor - أمر رائع من الخارج ، ولكن يتعين على السائق القيام بـ 10 رحلات بدلاً من واحدة.

في رأيي ، أكبر عيب في برنامج VMWare هو قربه التام - لن تقدم لك الشركة أي معلومات حول كيفية عملها ، على سبيل المثال ، vSAN أو ما هو موجود في برنامج Hypervisor الأساسي - إنه ببساطة غير مربح له - أي ، لن تصبح خبيرًا في برنامج VMWare أبدًا - بدون دعم البائع ، ستكون محكومًا عليك (في كثير من الأحيان أقابل خبراء VMWare الذين حيرتهم الأسئلة المبتذلة). بالنسبة لي ، تشتري VMWare سيارة مع غطاء محرك السيارة مغلق - نعم ، قد يكون لديك متخصصون يمكنهم تغيير حزام التوقيت ، ولكن الشخص الذي باعك هذا الحل فقط هو الذي سيكون قادرًا على فتح غطاء المحرك. أنا شخصياً لا أحب القرارات التي لا أستطيع أن أتوافق معها. ستقول أنك قد لا تضطر إلى الذهاب تحت غطاء المحرك. نعم ، هذا ممكن ، لكنني سأنظر إليك عندما تحتاج إلى جمع وظيفة كبيرة في السحابة من 20 إلى 30 جهازًا افتراضيًا ، و 40-50 شبكة ، نصفها يريد الخروج ، والنصف الآخر يطلب ريال سعودي -IOV تسريع وإلا فستحتاج إلى أكثر من بضع عشرات من هذه الآلات - وإلا فلن يكون الأداء كافيًا.

هناك وجهات نظر أخرى ، لذا فالأمر متروك لك لتقرر ما تختار ، والأهم من ذلك أنك ستكون مسؤولاً عن اختيارك. هذا مجرد رأيي - شخص شاهد ولمس 4 منتجات على الأقل - Nokia و Juniper و Red Hat و VMWare. لذلك لدي شيء للمقارنة.

المصدر: www.habr.com