Join Telegram Study Group ▷
لقد تم تطوير SDN منذ عدة سنوات، والحوسبة السحابية لها تاريخ أطول. إن الجمع بين الاثنين هو تطبيق قاتل لـ SDN. لقد كان ساخنًا في العامين الماضيين. لقد زادت بعض شركات الاستشارات المعروفة من سوق SDN عامًا بعد عام. يشير تأكيد الحصة بشكل أساسي إلى تطبيق SDN في شبكات الحوسبة السحابية.
لكن العالم لم يكن أحادي القطب ولا ثنائي القطب، بل متعدد الأقطاب. هناك العديد من الاحتياجات غير التقليدية في الشبكة الحقيقية. لا يمكن حل هذه المتطلبات من خلال هذين المخططين، أو حتى إذا كان بإمكانهما حلها، ولكنها ليست مثالية، بما في ذلك صعوبة التنفيذ والأداء والسعر. كاستخدام طويل الأمد لـ SDN للأجهزة لتوفير حلول للمستخدمين، أود أن أعرض كيف يمكن لمفاتيح SDN للأجهزة في العالم الحقيقي حل السيناريوهات المحددة في بعض شبكات الحوسبة السحابية، سواء كانت عامة أو خاصة. من المحتمل أن يتم مواجهة السحب الخاصة (بما في ذلك السحب المستضافة)، حيث تكون المتطلبات المخصصة أكثر شيوعًا في السحب الخاصة.
متطلبات التخصيص لوحدات التحكم والمفاتيح SDN في شبكات الحوسبة السحابية
لدى العديد من الأشخاص بعض سوء الفهم حول تطبيق مفاتيح SDN في شبكات الحوسبة السحابية. ستساعدك مفاتيح SDN في الحصول على شهادة CCIE Routing and Switching. هناك سوء فهم نموذجي. الأول معروف جيدًا، أي وحدة تحكم هي وحدة التحكم التي تستخدمها؟ هل يمكنك الاتصال بـ OpenDayLight/Ryu/NOS؟ والآخر هو أنك تحتاج فقط إلى استخدام مفتاح SDN واحد. دعم سيناريوهات شبكة الحوسبة السحابية، بغض النظر عن مفتاح SDN الخاص بالبائع. والسبب وراء هذين سوء الفهم هو أن العديد من الأشخاص ما زالوا لا يفهمون أن SDN تعني التخصيص المرتبط بالتطبيق، معتقدين أنه يمكنهم القيام بشبكات الحوسبة السحابية بشيء شائع. كسيناريو SDN محدد، عادةً ما يتم تصميم شبكة الحوسبة السحابية خصيصًا لسيناريو الحوسبة السحابية.
الوظيفة واحدة، أي أن متطلبات شبكة الحوسبة السحابية مكتملة، وحتى وحدة التحكم الصريحة قد لا تكون مخفية. في منصة السحابة (مثل تنفيذ منطق التعليمات البرمجية مباشرة في OpenStack Neutron Server). لا يمكن استخدام وحدة التحكم في هذا السيناريو كوحدة تحكم SDN للأغراض العامة. وعلى العكس من ذلك، لا يمكن استخدام وحدة التحكم SDN العالمية مباشرة في سيناريو شبكة الحوسبة السحابية. أما عن سبب سوء فهم السؤال الثاني، فمن السهل فهمه، حتى وحدة التحكم تحتاج إلى التخصيص لسيناريوهات الحوسبة السحابية، ناهيك عن مفاتيح SDN. لذلك، فهي ليست مفتاح SDN عشوائي يمكنه دعم سيناريوهات شبكة الحوسبة السحابية ولكنها تتطلب تخصيصًا عميقًا خاصًا. على سبيل المثال، صممت شركة Shengke Network (Suzhou) Co., Ltd وحدة التحكم المقابلة ووظائف المفتاح خصيصًا لهذا السيناريو.
السيناريو 1: استخدام مفاتيح SDN للأجهزة لتحسين الأداء
في هذا السيناريو، يقوم المستخدم بنشر شبكة افتراضية باستخدام Tunnel Overlay. ومع ذلك، نظرًا لأن تشغيل المفتاح في النفق (VxLAN أو NvGRE) له تأثير كبير على الأداء (إنتاجية منخفضة، تأخير كبير، تذبذب كبير، يعتمد التأثير المحدد على التنفيذ والتحسين لكل شركة)، لذلك عندما يمكن تنفيذ المفتاح عن طريق نفق تفريغ SDN TOR، فإن التأثير الكبير نسبيًا على أداء تفريغ عملية النفق لمفاتيح SDN TOR، مع الحفاظ على جميع العمليات الأخرى في الخادم ثابتة، يمكن اعتبارها منطقية تمديد مفتاح vSwitch SDN TOR. علاوة على ذلك، إذا كان من الممكن توزيع الأشياء على بوابة L3 الموضوعة أيضًا على SDN TOR، فإن SDN TOR العميق يشارك في المحاكاة الافتراضية للشبكة.
لا يتعرف جميع المستخدمين على هذا النموذج، لكن بعض الأشخاص يحبونه. في الوقت الحالي، قمنا بنشر هذا السيناريو في العديد من السحابات الخاصة الصغيرة والمتوسطة الحجم وسحابة IDC الشهيرة. أكبر مساعدة لهذه السحابات هي الأداء الممتاز والاستقرار. يظهر تدفق البيانات في الشكل أدناه.
السيناريو 2: استخدام مفتاح SDN للأجهزة للوصول إلى خادم فعلي
في فهم العديد من الناس، فإن جميع الخوادم في مركز بيانات الحوسبة السحابية افتراضية. في الواقع، هذا الفهم بعيد كل البعد عن الحقيقة. ليس فقط في العديد من السحابات العامة والخاصة، ولكن هناك أيضًا عدد كبير من الخوادم المادية، وبعضها موجود بالفعل. تشكل الخوادم المادية في السحابة أيضًا الجزء الأكبر. الغالبية العظمى من السحابات التي صادفتها لديها بالفعل الكثير من ممارسات العملاء، وفي الأساس، لديها هذه الحاجة. هناك أيضًا العديد من الأسباب. بعض الخوادم الموجودة ليس لديها قدرات المحاكاة الافتراضية. يتعين على بعض العملاء تشغيل بعض التطبيقات كثيفة الموارد. أداء الآلات الافتراضية ضعيف للغاية، أو لا يمكن التنبؤ بالأداء. بعض خوادم العملاء مخصصة. الخوادم، بعضها لأسباب أمنية، لا تريد المشاركة مع الآخرين فعليًا، والبعض الآخر مستخدمون لديهم خوادمهم الخاصة، ولا يريدون من مزودي الخدمات السحابية الانتقال، وما إلى ذلك، والسبب العام غريب، ولكن جميع العملاء لديهم طلب حقيقي.
بالنسبة لهذا الطلب، إذا كنت تستخدم شبكات VLAN، فلا يزال من السهل نسبيًا الحصول عليها، يمكنك بالكاد استخدام مفاتيح SDN، لأنه للقيام بالعزل، قم بتكوين VLAN مباشرة على المفتاح العادي. ولكن بمجرد استخدام النفق، تأتي المشكلة. أين تكوين Tunnel VTEP؟ يقول بعض الأشخاص أنه يمكنك الحصول على جهاز افتراضي واحد فقط على الخادم، ثم تثبيت vSwitch، والذي يمكن القيام به بالطبع، ولكن الأداء لا يتضرر، وليس آمال العميل. إنه يعادل خداع العملاء؛ يقول آخرون أن مفتاحًا خاصًا مصمم للتثبيت على الخادم، لذلك فهو جيد من الناحية النظرية، ولكن عبء العمل كبير (ليس فقط عبء العمل لتصميم هذا vSwitch ولكن أيضًا التحكم في منصة السحابة). كمية العمل)، لا يستطيع الشخص العادي القيام بذلك. علاوة على ذلك، إذا كان جهاز المستخدم الخاص لا يريدك أن تتحرك، فلن تعمل هاتان الطريقتان. بالنسبة لهذا السيناريو، يستخدم العديد من مزودي حلول المحاكاة الافتراضية للشبكات المحترفين، بما في ذلك VMware، بشكل عام مفتاح SDN للأجهزة كبوابة VTEP لتوصيل هذه الخوادم المادية بالشبكة الافتراضية. لا يحتاج الخادم المادي إلى القيام بأي شيء. علاوة على ذلك، يحتوي هذا السيناريو على متطلب أكثر أهمية لمفتاح SDN كبوابة VTEP. إنه غير متاح لجميع المفاتيح التي تستخدم حاليًا شريحة تبديل واسعة النطاق، أي أن المفتاح يحتاج إلى دعم كل من جسر النفق ودعم توجيه النفق (وإلا فلن يكون بوابة L3 موزعة). يمكن للمفتاح الذي يستخدم حاليًا الشريحة الكبيرة دعم الأول فقط ولا يمكنه دعم الأخير. يمكن لـ ACI من Cisco دعم الأخير لأنهم يستخدمون شريحة خاصة بهم. بالطبع، يقال إن الشريحة خلف مزود الشريحة تحل هذه المشكلة.
تستخدم مفاتيح SDN من Shengke شرائح مفاتيح تم تطويرها ذاتيًا وتدعم جسر النفق والتوجيه من الجيل الأول من الرقائق. حاليًا، تم نشر مفاتيح SDN لهذا السيناريو بأعداد كبيرة وسيتم نشرها في سحابات عامة متعددة. يظهر هيكل السيناريو في الشكل التالي (ملاحظة: قد لا يكون بروتوكول التحكم SDN OpenFlow أو بروتوكولًا خاصًا)
