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

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

ولكن دعونا ننظر إلى الأمر من زاوية مختلفة.

تستخدم العديد من الخدمات نفس الشبكة لفترة طويلة. في حالة مشغل الاتصالات، هذا هو 2G، 3G، LTE، النطاق العريض وB2B، على سبيل المثال. في حالة DC: الاتصال لعملاء مختلفين، والإنترنت، وتخزين الكتل، وتخزين الكائنات.

وجميع الخدمات تتطلب العزلة عن بعضها البعض. هكذا ظهرت شبكات التراكب.

وجميع الخدمات لا تريد الانتظار حتى يقوم شخص ما بتكوينها يدويًا. هكذا ظهر المنسقون وSDN.

لقد تم منذ فترة طويلة اتباع النهج الأول للأتمتة المنهجية للشبكة، أو بالأحرى جزء منها، وتنفيذه في العديد من الأماكن: VMWare، OpenStack، Google Compute Cloud، AWS، Facebook.

وهذا ما سنتعامل معه اليوم.

محتوى

• أسباب
• مفردات اللغة
• الأساس الذي تقوم عليه - الشبكة المادية
• تراكب - الشبكة الافتراضية
  • تراكب مع ToR
  • تراكب من المضيف
  • استخدام نسيج التنغستن كمثال
    • التواصل داخل جهاز مادي واحد
    • التواصل بين الأجهزة الافتراضية الموجودة على أجهزة فعلية مختلفة
    • الخروج إلى العالم الخارجي

• الأسئلة الشائعة
• اختتام
• وصلات مفيدة

أسباب

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

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

من أجل عدم انتظار قيام المسوقين الشبكيين بإدخال شبكات VLAN وعدم تسجيل أي خدمات على كل عقدة شبكة، توصل الأشخاص إلى فكرة استخدام التراكبات - شبكات التراكب - والتي يوجد منها مجموعة كبيرة ومتنوعة: GRE، IPinIP، MPLS، MPLS L2/L3VPN، VXLAN، GENEVE، MPLSoverUDP، MPLSoverGRE، إلخ.

تكمن جاذبيتهم في شيئين بسيطين:

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

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

ستصف السلسلة بأكملها مركز بيانات يتكون من صفوف من الحوامل المتماثلة التي تم تركيب نفس معدات الخادم فيها.

يقوم هذا الجهاز بتشغيل الأجهزة الافتراضية/الحاويات/بدون خادم التي تنفذ الخدمات.

مفردات اللغة

في حلقة الخادم سأقوم بتسمية برنامج ينفذ جانب الخادم للاتصال بين العميل والخادم.

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

الآلة المادية - كمبيوتر x86 مثبت على الرف. المصطلح الأكثر استخداما مضيف. وهذا ما سنسميه "سيارة"أو مضيف.

برنامج Hypervisor - تطبيق يعمل على جهاز فعلي يحاكي الموارد المادية التي تعمل عليها الأجهزة الافتراضية. في بعض الأحيان في الأدب والإنترنت، يتم استخدام كلمة "hypervisor" كمرادف لكلمة "host".

آلة افتراضية - نظام تشغيل يعمل على جهاز فعلي أعلى برنامج Hypervisor. بالنسبة لنا في هذه الدورة، لا يهم حقًا ما إذا كان في الواقع جهازًا افتراضيًا أو مجرد حاوية. دعنا نسميها "VM«

مستأجر هو مفهوم واسع سأحدده في هذه المقالة كخدمة منفصلة أو عميل منفصل.

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

ToR - مفتاح أعلى الحامل - مفتاح مثبت على حامل تتصل به جميع الأجهزة المادية.

بالإضافة إلى طوبولوجيا ToR، يمارس العديد من مقدمي الخدمة نهاية الصف (EoR) أو وسط الصف (على الرغم من أن الأخير نادر للغاية ولم أر اختصار MoR).

الشبكة الأساسية أو أن الشبكة الأساسية أو الطبقة الأساسية هي البنية التحتية الفعلية للشبكة: المحولات وأجهزة التوجيه والكابلات.

شبكة تراكب أو تراكب الشبكة أو التراكب - شبكة افتراضية من الأنفاق تعمل فوق الشبكة الفعلية.

نسيج L3 أو نسيج IP - اختراع مذهل للبشرية يسمح لك بتجنب تكرار STP وتعلم TRILL لإجراء المقابلات. مفهوم تكون فيه الشبكة بأكملها حتى مستوى الوصول هي L3 حصريًا، بدون شبكات VLAN، وبالتالي، مجالات بث ممتدة ضخمة. سننظر في مصدر كلمة "مصنع" في الجزء التالي.

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

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

فنف - وظيفة الشبكة الافتراضية. جهاز افتراضي محدد: جهاز التوجيه، والمحول، وجدار الحماية، وNAT، وIPS/IDS، وما إلى ذلك.

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

يمكن تقسيم معظم الشبكات اليوم بشكل واضح إلى قسمين:

بطانة - شبكة فعلية ذات تكوين مستقر.
غطاء - التجريد على الأساس الذي يقوم عليه عزل المستأجرين.

وينطبق هذا على حالة DC (التي سنقوم بتحليلها في هذه المقالة) وعلى مزود خدمة الإنترنت (الذي لن نحلله، لأنه تم بالفعل SDSM). مع شبكات المؤسسات، بطبيعة الحال، فإن الوضع مختلف إلى حد ما.

الصورة مع التركيز على الشبكة:

بطانة

الأساس الذي تقوم عليه هو شبكة فعلية: مفاتيح الأجهزة والكابلات. تعرف الأجهزة الموجودة تحت الأرض كيفية الوصول إلى الآلات المادية.

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

لكن شركة مثل Google يمكنها تطوير مفاتيحها الخاصة والتخلي عن البروتوكولات المقبولة عمومًا. لكن LAN_DC ليس Google.

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

• IPv4+OSPF
• IPv6+داعش+BGP+L3VPN
• L2+تريل
• إل 2 + ستب

تم تكوين الشبكة الأساسية بالطريقة الكلاسيكية: CLI/GUI/NETCONF.

يدويًا، البرامج النصية، والمرافق الخاصة.

سيتم تخصيص المقالة التالية في السلسلة للأساس الذي تقوم عليه بمزيد من التفاصيل.

غطاء

Overlay عبارة عن شبكة افتراضية من الأنفاق ممتدة فوق Underlay، وهي تسمح للأجهزة الافتراضية لعميل واحد بالتواصل مع بعضها البعض، مع توفير العزلة عن العملاء الآخرين.

يتم تغليف بيانات العميل في بعض رؤوس الأنفاق لنقلها عبر الشبكة العامة.

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

يمكن أن يكون التراكب، على سبيل المثال، كما ذكرت أعلاه:

• نفق جي آر إي
• VXLAN
• EVPN
• L3VPN
• جنيف

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

نعم، هذا هو SDN في أنقى صوره.

هناك طريقتان مختلفتان بشكل أساسي لتنظيم شبكة التراكب:

1. تراكب مع ToR
2. تراكب من المضيف

تراكب مع ToR

يمكن أن يبدأ التراكب عند مفتاح الوصول (ToR) الموجود على الحامل، كما يحدث، على سبيل المثال، في حالة نسيج VXLAN.

هذه آلية تم اختبارها عبر الزمن على شبكات مزودي خدمة الإنترنت ويدعمها جميع بائعي معدات الشبكة.

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

وهنا سأحيل القارئ إلى مقال حول VxLAN على حبري صديقنا القديم @bormoglotx.
في هذا العروض التقديمية مع ENOG تم وصف طرق بناء شبكة DC باستخدام نسيج EVPN VXLAN بالتفصيل.

وللانغماس الكامل في الواقع، يمكنك قراءة كتاب تسيسكا نسيج حديث ومفتوح وقابل للتطوير: VXLAN EVPN.

ألاحظ أن VXLAN ما هي إلا طريقة تغليف وأن إنهاء الأنفاق لا يمكن أن يحدث على ToR، بل على المضيف، كما يحدث في حالة OpenStack، على سبيل المثال.

ومع ذلك، فإن نسيج VXLAN، حيث يبدأ التراكب عند ToR، هو أحد تصميمات شبكة التراكب المعمول بها.

تراكب من المضيف

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

سيتطلب هذا بالطبع تشغيل تطبيق خاص على المضيفين، لكن الأمر يستحق ذلك.

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

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

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

من الأسهل إلقاء نظرة على الأمثلة. وكموضوع اختبار، سنأخذ منصة OpenSource SDN OpenContrail، المعروفة الآن باسم نسيج التنغستن.

في نهاية المقال سأقدم بعض الأفكار حول التشابه مع OpenFlow وOpenvSwitch.

استخدام نسيج التنغستن كمثال

كل آلة مادية لديها vRouter - جهاز توجيه افتراضي يعرف الشبكات المتصلة به والعملاء الذين ينتمون إليهم - وهو في الأساس جهاز توجيه PE. لكل عميل، فإنه يحتفظ بجدول توجيه معزول (اقرأ VRF). ويقوم vRouter بالفعل بإجراء نفق التراكب.

المزيد عن vRouter موجود في نهاية المقالة.

يتم توصيل كل جهاز افتراضي موجود على برنامج Hypervisor بجهاز vRouter الخاص بهذا الجهاز عبر واجهة اضغط.

TAP - نقطة الوصول الطرفية - واجهة افتراضية في نواة Linux تسمح بالتفاعل مع الشبكة.

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

حتى تتمكن أجهزة vRouters من التواصل مع بعضها البعض، وبناءً على ذلك، تقوم الأجهزة الافتراضية الموجودة خلفها بتبادل معلومات التوجيه عبر تحكم SDN.

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

الآن دعونا نلقي نظرة على أمثلة الاتصالات - وسيكون هناك وضوح.

التواصل داخل جهاز مادي واحد

يريد VM0 إرسال حزمة إلى VM2. لنفترض الآن أن هذا جهاز افتراضي واحد لعميل واحد.

طائرة البيانات

1. يمتلك VM-0 مسارًا افتراضيًا إلى واجهة eth0 الخاصة به. يتم إرسال الحزمة هناك.
   يتم توصيل هذه الواجهة eth0 فعليًا بجهاز التوجيه الظاهري vRouter من خلال واجهة TAP Tap0.
2. يقوم vRouter بتحليل الواجهة التي وصلت إليها الحزمة، أي العميل (VRF) الذي تنتمي إليه، ويتحقق من عنوان المستلم من خلال جدول التوجيه الخاص بهذا العميل.
3. بعد اكتشاف أن المستلم على نفس الجهاز موجود على منفذ مختلف، يقوم vRouter ببساطة بإرسال الحزمة إليه دون أي رؤوس إضافية - في هذه الحالة، يحتوي vRouter بالفعل على سجل ARP.

في هذه الحالة، لا تدخل الحزمة إلى الشبكة الفعلية - بل يتم توجيهها داخل جهاز vRouter.

طائرة مراقبة

عندما يبدأ تشغيل الجهاز الظاهري، يخبره برنامج Hypervisor بما يلي:

• عنوان IP الخاص بها.
• المسار الافتراضي هو من خلال عنوان IP الخاص بـ vRouter على هذه الشبكة.

يقدم برنامج Hypervisor تقاريره إلى vRouter من خلال واجهة برمجة تطبيقات خاصة:

• ما تحتاجه لإنشاء واجهة افتراضية.
• ما نوع الشبكة الافتراضية التي يحتاج (VM) إلى إنشائها؟
• أي VRF (VN) سيتم ربطه به.
• إدخال ARP ثابت لجهاز VM هذا - أي واجهة تقع خلف عنوان IP الخاص به وعنوان MAC المرتبط به.

مرة أخرى، تم تبسيط إجراء التفاعل الفعلي من أجل فهم المفهوم.

وبالتالي، يرى vRouter جميع الأجهزة الافتراضية لعميل واحد على جهاز معين كشبكات متصلة بشكل مباشر ويمكنه التوجيه بينها بنفسه.

لكن VM0 وVM1 ينتميان إلى عملاء مختلفين، وبالتالي، يوجدان في جداول vRouter مختلفة.

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

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

التواصل بين الأجهزة الافتراضية الموجودة على أجهزة فعلية مختلفة

طائرة البيانات

1. البداية هي نفسها تمامًا: يرسل VM-0 حزمة بالوجهة VM-7 (172.17.3.2) بشكل افتراضي.
2. يستقبلها vRouter ويرى هذه المرة أن الوجهة موجودة على جهاز مختلف ويمكن الوصول إليها من خلال Tunnel0.
3. أولاً، يتم تعليق علامة MPLS التي تحدد الواجهة البعيدة، بحيث يمكن لـ vRouter على الجانب الخلفي تحديد مكان وضع هذه الحزمة دون عمليات بحث إضافية.

   

4. Tunnel0 لديه المصدر 10.0.0.2، الوجهة: 10.0.1.2.
   يضيف vRouter رؤوس GRE (أو UDP) وعنوان IP جديد إلى الحزمة الأصلية.
5. يحتوي جدول توجيه vRouter على مسار افتراضي عبر عنوان ToR1 10.0.0.1. هذا هو المكان الذي يرسله.

   
   

6. يعرف ToR1، باعتباره عضوًا في شبكة Underlay (على سبيل المثال، عبر OSPF) كيفية الوصول إلى 10.0.1.2 ويرسل الحزمة على طول المسار. لاحظ أن ECMP ممكّن هنا. هناك خطوتان تالتان في الرسم التوضيحي، وسيتم فرز سلاسل الرسائل المختلفة فيهما حسب التجزئة. في حالة وجود مصنع حقيقي، سيكون هناك على الأرجح 4 تجارب تالية.

   وفي الوقت نفسه، لا يحتاج إلى معرفة ما هو موجود تحت رأس IP الخارجي. وهذا يعني، في الواقع، أنه ضمن IP يمكن أن يكون هناك شطيرة من IPv6 عبر MPLS عبر Ethernet عبر MPLS عبر GRE عبر اليونانية.

7. وفقًا لذلك، على الجانب المتلقي، يقوم vRouter بإزالة GRE، وباستخدام علامة MPLS، يفهم الواجهة التي يجب إرسال هذه الحزمة إليها، ويزيلها ويرسلها في شكلها الأصلي إلى المستلم.

طائرة مراقبة

عند تشغيل السيارة يحدث نفس الشيء كما هو موضح أعلاه.

و بالإضافة إلى ما يلي:

• لكل عميل، يخصص vRouter علامة MPLS. هذا هو ملصق خدمة L3VPN، والذي سيتم من خلاله فصل العملاء داخل نفس الجهاز الفعلي.
  

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

• ينشئ vRouter اتصالاً بوحدة تحكم SDN باستخدام بروتوكول BGP (أو ما شابه ذلك - في حالة TF، هذا هو XMPP 0_o).
• من خلال هذه الجلسة، يقوم vRouter بالإبلاغ عن المسارات إلى الشبكات المتصلة إلى وحدة تحكم SDN:
  • عنوان الشبكة
  • طريقة التغليف (MPLSoGRE، MPLSoUDP، VXLAN)
  • علامة العميل MPLS
  • عنوان IP الخاص بك كالمتجر التالي

• تستقبل وحدة تحكم SDN مثل هذه المسارات من جميع أجهزة vRouters المتصلة وتعكسها للآخرين. أي أنه يعمل بمثابة عاكس للطريق.

نفس الشيء يحدث في الاتجاه المعاكس.

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

تهتم وحدة التحكم المركزية بكل تعقيدات الحفاظ على التكوين ومراقبة جداول التحويل/التوجيه على جهاز vRouter.

بشكل تقريبي، تتواصل وحدة التحكم مع جميع أجهزة vRouters عبر BGP (أو بروتوكول مشابه) وتقوم ببساطة بنقل معلومات التوجيه. على سبيل المثال، يحتوي BGP بالفعل على Address-Family لنقل طريقة التغليف MPLS-في-GRE أو MPLS-في-UDP.

في الوقت نفسه، لا يتغير تكوين شبكة Underlay بأي شكل من الأشكال، والتي، بالمناسبة، أكثر صعوبة في الأتمتة، وأسهل للكسر بحركة محرجة.

الخروج إلى العالم الخارجي

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

يتم ممارسة نهجين:

1. تم تثبيت جهاز توجيه.
2. تم إطلاق جهاز ينفذ وظائف جهاز التوجيه (نعم، بعد SDN، واجهنا أيضًا VNF). دعنا نسميها بوابة افتراضية.

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

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

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

وبالقدم الأخرى، تنظر البوابة إلى الشبكة الأساسية وتعرف كيفية الوصول إلى الإنترنت.

طائرة البيانات

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

1. يرسل VM-0، الذي تم ضبطه افتراضيًا على نفس vRouter، حزمة ذات وجهة في العالم الخارجي (185.147.83.177) إلى واجهة eth0.
2. يتلقى vRouter هذه الحزمة ويبحث عن عنوان الوجهة في جدول التوجيه - ويبحث عن المسار الافتراضي عبر بوابة VNGW1 عبر النفق 1.
   ويرى أيضًا أن هذا هو نفق GRE مع SIP 10.0.0.2 وDIP 10.0.255.2، ويحتاج أيضًا إلى إرفاق علامة MPLS لهذا العميل أولاً، وهو ما يتوقعه VNGW1.
3. يقوم vRouter بتعبئة الحزمة الأولية مع MPLS وGRE ورؤوس IP الجديدة ويرسلها إلى ToR1 10.0.0.1 افتراضيًا.
4. تقوم الشبكة الأساسية بتسليم الحزمة إلى البوابة VNGW1.
5. تقوم بوابة VNGW1 بإزالة رؤوس أنفاق GRE وMPLS، وترى عنوان الوجهة، وترجع إلى جدول التوجيه الخاص بها، وتفهم أنه موجه إلى الإنترنت - أي من خلال العرض الكامل أو الافتراضي. إذا لزم الأمر، ينفذ ترجمة NAT.
6. من الممكن أن تكون هناك شبكة IP عادية من VNGW إلى الحدود، وهو أمر غير مرجح.
   قد تكون هناك شبكة MPLS كلاسيكية (IGP+LDP/RSVP TE)، وقد يكون هناك نسيج خلفي مع BGP LU أو نفق GRE من VNGW إلى الحدود عبر شبكة IP.
   مهما كان الأمر، يقوم VNGW1 بإجراء التغليفات اللازمة ويرسل الحزمة الأولية نحو الحدود.

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

1. تقوم الحدود بإسقاط الحزمة إلى VNGW1
2. يخلع ملابسه وينظر إلى عنوان المستلم ويرى أنه يمكن الوصول إليه عبر نفق Tunnel1 (MPLSoGRE أو MPLSoUDP).
3. وبناءً على ذلك، فإنه يرفق ملصق MPLS ورأس GRE/UDP وعنوان IP جديد ويرسله إلى ToR3 10.0.255.1.
   عنوان وجهة النفق هو عنوان IP الخاص بجهاز vRouter الذي يقع خلفه الجهاز الظاهري المستهدف - 10.0.0.2.
4. تقوم الشبكة الأساسية بتسليم الحزمة إلى vRouter المطلوب.
5. يقرأ vRouter الهدف GRE/UDP، ويحدد الواجهة باستخدام علامة MPLS ويرسل حزمة IP العارية إلى واجهة TAP المرتبطة بـ eth0 الخاص بالجهاز الظاهري.

طائرة مراقبة

ينشئ VNGW1 منطقة BGP مع وحدة تحكم SDN، والتي يتلقى منها جميع معلومات التوجيه حول العملاء: أي عنوان IP (vRouter) يقع خلف أي عميل، وأي علامة MPLS يتم التعرف عليه من خلالها.

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

في VNGW، عادةً ما يحدث تجميع المسار أو ترجمة NAT.

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

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

وبمساعدة الإنشاء المتسلسل لـ VRFs والإعلان الصحيح عن المسارات، يمكنك إجبار حركة المرور على التكرار بالطريقة التي تريدها، وهو ما يسمى تسلسل الخدمة.

وهذا يعني أن وحدة تحكم SDN تعمل هنا أيضًا كعاكس للطريق بين VNGWs وvRouters وأجهزة الشبكة الأخرى.

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

الأسئلة الشائعة

لماذا تستمر في الإدلاء بملاحظة GRE/UDP؟

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

ولكن إذا أخذناها، فإن TF نفسه، في حين لا يزال OpenContrail، يدعم كلا التغليفين: MPLS في GRE وMPLS في UDP.

يعد UDP جيدًا لأنه من السهل جدًا في منفذ المصدر تشفير وظيفة التجزئة من IP+Proto+Port الأصلي في رأسه، مما سيسمح لك بإجراء الموازنة.

في حالة GRE، للأسف، لا يوجد سوى رؤوس IP وGRE خارجية، وهي نفسها بالنسبة لجميع حركة المرور المغلفة ولا يوجد حديث عن التوازن - قلة من الناس يمكنهم النظر بعمق داخل الحزمة.

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

في الإنصاف، تجدر الإشارة إلى أن TF يدعم بشكل كامل اتصال L2 باستخدام VXLAN.

لقد وعدت برسم أوجه التشابه مع OpenFlow.
إنهم حقا يطلبون ذلك. يقوم vSwitch في نفس OpenStack بأشياء مشابهة جدًا، باستخدام VXLAN، والذي، بالمناسبة، يحتوي أيضًا على رأس UDP.

في مستوى البيانات، يعملون بنفس الطريقة تقريبًا، ويختلف مستوى التحكم بشكل كبير. يستخدم Tungsten Fabric XMPP لتوصيل معلومات التوجيه إلى vRouter، بينما يقوم OpenStack بتشغيل Openflow.

هل يمكن أن تخبرني المزيد عن vRouter؟
وهو مقسم إلى قسمين: vRouter Agent وvRouter Forwarder.

يعمل الأول في مساحة المستخدم لنظام التشغيل المضيف ويتواصل مع وحدة تحكم SDN، ويتبادل المعلومات حول المسارات وVRFs وقوائم ACL.

والثاني ينفذ Data Plane - عادةً في Kernel Space، ولكن يمكن أيضًا تشغيله على SmartNICs - بطاقات الشبكة المزودة بوحدة المعالجة المركزية وشريحة تبديل منفصلة قابلة للبرمجة، مما يسمح لك بإزالة الحمل من وحدة المعالجة المركزية للجهاز المضيف، وجعل الشبكة أسرع وأكثر قابل للتنبؤ.

السيناريو الآخر المحتمل هو أن vRouter هو تطبيق DPDK في مساحة المستخدم.

يرسل vRouter Agent الإعدادات إلى vRouter Forwarder.

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

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

وبالتالي، لا توجد مراسلات مباشرة بين الشبكة الافتراضية والمستأجر.

اختتام

هذا وصف سطحي للغاية لتشغيل الشبكة الافتراضية مع تراكب من المضيف ووحدة تحكم SDN. ولكن بغض النظر عن منصة المحاكاة الافتراضية التي تختارها اليوم، فإنها ستعمل بطريقة مماثلة، سواء كانت VMWare أو ACI أو OpenStack أو CloudStack أو Tungsten Fabric أو Juniper Contrail. وسوف تختلف في أنواع التغليفات والرؤوس، وبروتوكولات توصيل المعلومات إلى أجهزة الشبكة النهائية، ولكن مبدأ شبكة التراكب القابلة للتكوين بواسطة البرنامج والتي تعمل فوق شبكة أساسية ثابتة وبسيطة نسبيًا سيظل كما هو.
يمكننا القول أن SDN المستندة إلى شبكة متراكبة قد فازت اليوم بمجال إنشاء سحابة خاصة. ومع ذلك، هذا لا يعني أن Openflow ليس له مكان في العالم الحديث - فهو يستخدم في OpenStacke وفي نفس VMWare NSX، وبقدر ما أعرف، تستخدمه Google لإعداد الشبكة تحت الأرض.

لقد قمت أدناه بتوفير روابط لمواد أكثر تفصيلاً إذا كنت ترغب في دراسة المشكلة بشكل أعمق.

وماذا عن الأساس الذي تقوم عليه لدينا؟

ولكن بشكل عام، لا شيء. ولم يتغير الطريق كله. كل ما عليه فعله في حالة وجود تراكب من المضيف هو تحديث المسارات وARPs حيث تظهر وتختفي vRouter/VNGW وتحمل الحزم بينهما.

دعونا نقوم بصياغة قائمة المتطلبات لشبكة Underlay.

1. تكون قادرًا على استخدام نوع ما من بروتوكول التوجيه، في حالتنا - BGP.
2. احصل على نطاق ترددي واسع، ويفضل أن يكون بدون اشتراك زائد، حتى لا يتم فقدان الحزم بسبب التحميل الزائد.
3. يعد دعم ECMP جزءًا لا يتجزأ من النسيج.
4. تكون قادرًا على توفير جودة الخدمة (QoS)، بما في ذلك الأشياء الصعبة مثل ECN.
5. يعد دعم NETCONF أساسًا للمستقبل.

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

من الواضح أنني أقيدنا جميعًا بشدة باستخدام كمثال شبكة DC المبنية في مصنع Cloz مع توجيه IP خالص وتراكب من المضيف.

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

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

وصلات مفيدة

• هندسة نسيج التنغستن.
• حول:سحابة. 6 ساعات حول Yandex.Cloud، والذي يغطي أيضًا الشبكة الافتراضية على TF.
• ما هو فتح vSwitch؟
• مقدمة إلى VxLAN.
• RFC 7348. شبكة المنطقة المحلية الافتراضية القابلة للتوسيع (VXLAN): إطار عمل لتراكب شبكات الطبقة الثانية الافتراضية عبر شبكات الطبقة الثالثة.
  
• نهج التوسع في نسيج VXLAN EVPN. إنه يتحدث عن شبكة DC بأكملها، بما في ذلك Underlay وOverlay وأساليب التوجيه المتعدد والإدارة.

شكرًا

• رومان جورجا - مضيف سابق لبودكاست Linkmeup والآن خبير في مجال المنصات السحابية. للتعليقات والتعديلات. حسنًا، نحن ننتظر مقالته الأكثر تعمقًا حول المحاكاة الافتراضية في المستقبل القريب.
• الكسندر شاليموف - زميلي وخبير في مجال تطوير الشبكات الافتراضية. للتعليقات والتعديلات.
• فالنتين سينيتسين - زميلي وخبير في مجال قماش التنجستين. للتعليقات والتعديلات.
• أرتيوم تشيرنوباي - رابط المصور. بالنسبة لـ KDPV.
• الكسندر ليمونوف. من أجل ميمي "التلقائي".

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