Clever Geek Handbook

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





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



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



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



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



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



الافتراضية- هذه هي القدرة على تقسيم كيان مادي واحد (على سبيل المثال ، خادم) إلى عدة كيانات افتراضية ، وبالتالي زيادة استخدام الموارد (على سبيل المثال ، كان لديك 3 خوادم محملة بنسبة 25-30 في المائة ، بعد المحاكاة الافتراضية تحصل على خادم واحد تم تحميله بنسبة 80-90 بالمائة). بطبيعة الحال ، تستهلك المحاكاة الافتراضية بعض الموارد - تحتاج إلى إطعام برنامج 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. تعتمد الخدمة التي تحتاجها على رغباتك وقدراتك.



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



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



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



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



ما هو OpenStack؟



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



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



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



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



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



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



  • Dashboard - واجهة المستخدم الرسومية المستندة إلى الويب لإدارة خدمات OpenStack
  • Keystone هي خدمة هوية مركزية توفر وظائف المصادقة والتفويض للخدمات الأخرى ، بالإضافة إلى إدارة بيانات اعتماد المستخدم وأدواره.
  • Neutron — , OpenStack ( VM )
  • Cinder —
  • Nova —
  • Glance —
  • Swift —
  • Ceilometer — ,
  • Heat —


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



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



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



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



  1. عندما تنشئ طلبًا لإنشاء جهاز ، سواء كان طلبًا من خلال Horizon (Dashboard) أو طلبًا من خلال CLI ، فإن أول شيء يحدث هو طلب تفويض Keystone - هل يمكنك إنشاء جهاز ، أو لديك الحق في استخدام هذه الشبكة ، هل لديك ما يكفي مشروع الحصص ، إلخ.
  2. يصادق Keystone على طلبك وينشئ رمز المصادقة في رسالة الاستجابة ، والذي سيتم استخدامه لاحقًا. بعد تلقي رد من Keystone ، يتم إرسال الطلب إلى Nova (nova api).
  3. Nova-api , Keystone, auth-
  4. Keystone auth- .
  5. Nova-api nova-database VM nova-scheduler.
  6. Nova-scheduler ( ), VM , . VM nova-database.
  7. nova-scheduler nova-compute . Nova-compute nova-conductor (nova-conductor nova, nova-database nova-compute, nova-database ).
  8. Nova-conductor nova-database nova-compute.
  9. nova-compute glance ID . Glace Keystone .
  10. Nova-compute neutron . glance, neutron Keystone, database ( ), nova-compute.
  11. Nova-compute cinder volume. glance, cider Keystone, volume .
  12. Nova-compute libvirt .


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



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



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



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



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







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



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



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







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







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



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



يبدو أنه ليس شيئًا معقدًا - فنحن نصمم واجهة جسر على عقدة التحكم ، ونوجه حركة المرور إليها ومن هناك نوجهها إلى حيث نحتاج إليها. لكن المشكلة تكمن في أن عميل RED يريد استخدام الشبكة 10.0.0.0/24 وعميل GREEN يريد استخدام الشبكة 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. في هذه الحالة ، على الرغم من أن جميع العملاء سيستخدمون نفس الشبكة ، يتم الاحتفاظ بالعزلة الداخلية تمامًا. وهذا يعني أننا نحتاج إلى إنشاء dNAT و sNAT على عقدة التحكم.استخدم شبكة واحدة مع تخصيص عناوين عائمة أو شبكات خارجية ، أو كليهما في وقت واحد - نظرًا لحقيقة أنك تريد السحب إلى السحابة. لن نضيف عناوين عائمة إلى الرسم التخطيطي ، لكننا سنترك الشبكات الخارجية التي تمت إضافتها مسبقًا - لكل عميل شبكته الخارجية الخاصة (في الرسم التخطيطي ، تم تحديدهما كـ vlan 100 و 200 على الواجهة الخارجية).



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



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







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



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



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



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





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



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



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



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



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



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



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


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



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



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







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



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



  • خدمة REST
  • المكون الإضافي النيوتروني (الأساسي / الخدمة)


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



المكونات الإضافية هي مكونات / وحدات برمجية إضافية يتم استدعاؤها عند طلبات 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 أوامر إلى وحدة التحكم من خلال المكون الإضافي الجذر ، وهو يفعل بالفعل ما قيل له.



لنقم بتحديث ذاكرتنا افتح 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) — , user space, kernel —
  • Database server — , , OVS, . OVSDB SDN .


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



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

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

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



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



لنبدأ بنشر تثبيت 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 ( ) (Storage management Storage) , , QoS , . .
ملاحظة: نظرًا لأننا سنقوم بتشغيل أجهزة افتراضية في بيئة افتراضية تعتمد على الأجهزة الافتراضية ، فنحن بحاجة أولاً إلى تمكين المحاكاة الافتراضية المتداخلة.



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




[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-definition: 




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 بالكامل.
بعد ذلك ، نقوم بإنشاء سيارة تحت السحاب: 




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 - العنوان المحلي تحت السحاب نحو إثبات شبكة



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



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



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



undercloud_nameservers - الخادم DNS



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



أخطاء Red Hat local_interface في توفير الشبكة. ستتم إعادة تكوين هذه الواجهة أثناء نشر undercloud ، لذلك تحتاج إلى وجود



واجهتين على السحاب السفلي - واحدة للوصول إليها ، والثانية لتوفير local_mtu - MTU. نظرًا لأن لدينا معمل اختبار و MTU لدي 1500 منفذ OVS Svicha ، فمن الضروري وضع القيمة في 1450 ، والتي كان من الممكن تغليفها في حزم VxLAN



network_cidr -



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



masquerade_network الخارجية - شبكة من شأنها ترجمة NAT -صيا



dhcp_start - عنوان بدءا من حوض السباحة العنوان الذي سيتم تعيين عناوين العقد خلال جعله مظلما نشر



dhcp_end - العنوان النهائي للتجمع العنوان الذي سيتم تعيين عناوين العقد خلال جعله مظلما نشر



inspection_iprange - تجمع العناوين اللازمة لالاستبطان (يجب أن لا تتقاطع مع التجمع المذكورة أعلاه )



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



بعد وصف الملف ، يمكنك إعطاء الأمر للنشر undercloud: 




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


سيتم الآن تنفيذ نشر Overercloud من خلال هذه الواجهة.



من الإخراج أدناه يمكن ملاحظة أن لدينا جميع الخدمات على عقدة واحدة: 



(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 نفسها بتثبيت نظام التشغيل والبرامج الضرورية على جهاز overcloud - أي أننا لا نحتاج إلى نشر الجهاز بالكامل ، ولكن فقط إنشاء قرص (أو أقراص) له وتحديد معلماته - أي في الواقع ، نحصل على خادم مكشوف بدون تثبيت نظام تشغيل عليه ...



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




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 من أجل إدارة الخوادم أثناء التثبيت والاستبطان.



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



ولكن هنا تكمن المشكلة - إذا كانت خوادم الحديد 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


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

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


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




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 heat-admin@192.168.255.15         
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-2 



(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 ~]$


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



(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 في الإخراج أعلاه.







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



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



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



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







لدينا جهازان ظاهريان على كل كمبيوتر. دعونا نرى كيف يتم تضمين كل شيء في الحوسبة 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 - جسر Linux

qvb و qvo - زوج vEth متصل بجسر Linux و Open vSwitch bridge

br-int ، br-tun ، br-vlan - فتح vSwitch bridges

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 ، لذلك تم اختراع هذا "العكاز". ومع ذلك ، فإنه يعيش أكثر من نفسه - يتم استبداله بـ conntrack في الإصدارات الجديدة.



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







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



نظرًا لأن هذين الجهازين الظاهريين في نفس شبكة L2 وعلى نفس المشرف ، فإن حركة المرور بينهما ستنتقل منطقيًا عبر 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 ~]$


يوجد جهاز Mac في جدول إعادة التوجيه 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


حسنًا ، ثم ننظر إلى أن هناك وجهة mac في 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


نظرًا لأنه في هذه الحالة يجب أن تذهب الحزمة إلى البوابة ويتم توجيهها هناك ، نحتاج إلى معرفة عنوان MAC الخاص بالبوابة ، والذي سننظر فيه إلى جدول 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. دعنا نتحقق من العنوان الجماعي للمنفذ qr-0c52b15f-8f ، نظرًا لأن حركة المرور ، استنادًا إلى عنوان الخشخاش الوجهة ، انتقلت بالضبط إلى هذه الواجهة. 



[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. حسنًا ، كل شيء في الحوسبة 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 مختلفة. دعونا نرى ما هو نوع VNI ، ثم نجمع تفريغًا على منفذ التحكم في العقدة ونتأكد من أن حركة المرور تسير تمامًا كما هو موضح أعلاه.

لذلك ، النفق المطلوب حساب 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 أجهزة وشبكتين داخليتين وجهاز توجيه افتراضي واحد ... ليس لدينا شبكات خارجية هنا الآن ، أكوام من المشاريع المختلفة ، لكل منها شبكاتها الخاصة (متداخلة ) ، وقمنا بإيقاف تشغيل جهاز التوجيه الموزع ، وفي النهاية كانت هناك عقدة تحكم واحدة فقط في طاولة الاختبار (للتسامح مع الخطأ ، يجب أن يكون هناك نصاب من ثلاث عقد). من المنطقي أن يكون كل شيء "قليلاً" في التجارة أكثر تعقيدًا ، ولكن في هذا المثال البسيط ، نفهم كيف يجب أن يعمل هذا - إذا كان لديك 3 أو 300 مساحة اسم ، بالطبع ، فمن المهم ، ولكن من وجهة نظر تشغيل الهيكل بأكمله ، فلن يتغير شيء كثيرًا ... لكن في الوقت الحالي لا تلتصق بنوع من SDN البائع. لكن هذه قصة مختلفة تمامًا.



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



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



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



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



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



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


More articles:


All Articles