سيناريوهات تطبيق مفاتيح SDN في شبكات الحوسبة السحابية (2)

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

يجب أن نذكر بشكل خاص أنه يمكن تنفيذ هذه السيناريوهات باستخدام Cisco ACI لأن فكرة ACI في الأساس هي استخدام SDN للأجهزة لدعم المحاكاة الافتراضية للشبكة. إذا كنت تتقن معرفة مفاتيح SDN جيدًا، فمن المحتمل جدًا أن تجتاز اختبار CCIE Routing and Switching Lab . ومع ذلك، نظرًا لأن العديد من المستخدمين لا يريدون استخدام Cisco ACI لأسباب مختلفة (مثل السعر المرتفع للغاية، أو احتكار البائع، أو اتجاه التوطين، وما إلى ذلك)، فإنهم يحتاجون إلى حل آخر (لا أقول إن ACI ليس جيدًا، بل على العكس من ذلك، من وجهة نظر فنية بحتة) أنا شخصيًا أقدر ACI).

السيناريو 1: استخدام مفتاح SDN للأجهزة للوصول إلى جدار حماية الأجهزة

تُستخدم جدران الحماية المادية في شبكات الحوسبة السحابية، وهو أمر شائع. وبشكل خاص، تتوفر سحابات خاصة بالشركات، وحتى سحابات عامة. وقد أوضح العديد من المستخدمين أنني استخدمت جدار الحماية المادي الخاص بي بشكل جيد للغاية. يجب أن تسمح لي بالانتقال إلى السحابة، ويجب أن أستخدم جدار الحماية المادي الخاص بي. وقد ظهرت تلك المشكلة. في الشبكة التقليدية، تريد بيانات المستخدم المرور عبر جدار الحماية. الأمر بسيط للغاية. قم بتوصيل جدار الحماية بمخرج الشبكة أو قم بتكوين قائمة التحكم في الوصول لتوجيه التدفق. ومع ذلك، في شبكة الحوسبة السحابية، من الممكن أن يخدم جدار الحماية عددًا معينًا من المستخدمين أو مجموعة من التطبيقات فقط. حتى جدار الحماية هذا تم بناؤه بواسطة المستخدم. لا يمكنك توصيله فعليًا بمنفذ الشبكة. يجب توجيه حركة المرور إلى جدار حماية على خزانة، ولكن هذه المرة ليس من المناسب استخدام قائمة التحكم في الوصول التقليدية لأن VM يتم إنشاؤها ديناميكيًا وقد تتغير السياسة ديناميكيًا. تحتاج إلى تكوين قائمة التحكم في الوصول ديناميكيًا على المحول. ما هو الأنسب للاستخدام؟ ليس هناك شك في أن مفاتيح SDN والاستراتيجية الديناميكية التي يجب اتباعها هي قوة SDN، وجوهر ACI من Cisco هو استراتيجية ديناميكية يجب اتباعها.

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

يقول بعض الأشخاص إن جدران الحماية ستظل محدودة بـ 4K VLAN. في الواقع، نظرًا لأن النفق تم تحويله إلى VLAN، يمكن أن تكون VLAN هنا فريدة لكل منفذ، ولا يلزم أن تكون فريدة عالميًا. بالطبع، يتطلب هذا أيضًا أن يدعم المحول. يمكن لمحول SDN الخاص بـ Sheng دعم هذا الطلب بشكل جيد.

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

يقال أن هناك العديد من المشرفين، في الواقع، لا يزال معظمهم عبارة عن شبكة هجينة من VMware والمشرفين الآخرين. لأن KVM أو Xen، أو منصات سحابية مفتوحة المصدر أو منصات سحابية خاصة محايدة تابعة لجهات خارجية يمكنها دعمها بشكل جيد، ويمكن لمنصة السحابة التحكم الكامل في هذه المشرفين. لكن VMware هو مشرف مغلق المصدر، ولا توجد طريقة للتحكم فيه كما يحلو لك. استخدم العديد من العملاء منتجات VMware القديمة. الآن VPC رائجة، سواء كانت عصرية أو متطلبة حقًا، يريدون جميعًا دعم VPC، وخاصة VPC المستندة إلى Tunnel Overlay. يقول بعض الناس أنه من السهل القيام بذلك، VMware ليس لديها NSX خصيصًا للقيام بذلك؟ على الرغم من أنها توفر برامج تشغيل لـ OpenStack، فإن NSX باهظة الثمن، ولا يستطيع العميل العادي تحملها أو يشعر بعدم الاقتصاد. يريد هؤلاء العملاء تقديم بعض KVM وXEN مفتوح المصدر، لكنهم لا يريدون التخلص من VMware السابقة، ولكنهم يريدون أيضًا أن تشكل هذه المشرفات معًا شبكة VPC. إذن ماذا يجب أن نفعل؟

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

السيناريو 3: نشر Vlan عند الطلب باستخدام مفتاح SDN للأجهزة

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

الحل البسيط للغاية لهذه المشكلة هو تقديم مفتاح SDN لتكوين VLAN بشكل ديناميكي حسب الحاجة.

لتلخيص

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