اعتبارات الشبكة لعمليات توزيع Azure VMware Solution ثنائية المنطقة

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

سيناريو المنطقة المزدوجة

تركز هذه المقالة على سيناريو نموذجي ثنائي المنطقة، موضح في الشكل 1 التالي:

  • يوجد مركز Azure وشبكة محورية في كل منطقة.
  • تم نشر تكوين مرن في مواجهة الكوارث ل ExpressRoute (دائرتان في موقعين مختلفين للتناظر، مع توصيل كل دائرة بالشبكات الظاهرية المركزية في كلتا المنطقتين). تظل الإرشادات المقدمة في الأقسام التالية كما هي في حالة تكوين اتصال VPN الاحتياطي .
  • تم نشر سحابة خاصة ل Azure VMware Solution في كل منطقة.

رسم تخطيطي للشكل 1، والذي يعرض سيناريو المنطقة المزدوجة الذي تغطيه هذه المقالة.

ملاحظة

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

أنماط الاتصال ثنائية المنطقة

تصف الأقسام التالية تكوين شبكة Azure VMware Solution الضروري لتمكين أنماط الاتصال التالية في سيناريو المنطقة المزدوجة المرجعي:

اتصال Azure VMware Solution عبر المناطق

عند وجود سحابات خاصة متعددة من Azure VMware Solution، غالبا ما يكون اتصال الطبقة 3 بينها مطلبا لمهام مثل دعم النسخ المتماثل للبيانات.

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

يعتمد الاتصال المباشر بين السحب الخاصة على اتصالات ExpressRoute Global Reach بين دوائر Azure VMware Solution المدارة، كما هو موضح في الخط الأخضر في الرسم التخطيطي التالي. لمزيد من المعلومات، راجع البرنامج التعليمي: البيئات المحلية النظيرة إلى Azure VMware Solution. توضح المقالة إجراء توصيل دائرة مدارة من Azure VMware Solution مع دائرة يديرها العميل. ينطبق نفس الإجراء على توصيل دائرتين مدارتين من Azure VMware Solution.

رسم تخطيطي للشكل 2، والذي يظهر السحب الخاصة في مناطق مختلفة متصلة عبر اتصال Global Reach بين دوائر ExpressRoute المدارة.

الاتصال المختلط

الخيار الموصى به لتوصيل السحب الخاصة ل Azure VMware Solution بالمواقع المحلية هو ExpressRoute Global Reach. يمكن إنشاء اتصالات Global Reach بين دوائر ExpressRoute المدارة من قبل العميل ودائرات ExpressRoute المدارة من Azure VMware Solution. اتصالات Global Reach ليست عابرة، وبالتالي فإن شبكة كاملة (كل دائرة مدارة من Azure VMware Solution متصلة بكل دائرة يديرها العميل) ضرورية للمرونة في مواجهة الكوارث، كما هو موضح في الشكل 3 التالي (ممثل بخطوط برتقالية).

رسم تخطيطي للشكل 3، والذي يظهر اتصالات Global Reach التي تربط دوائر ExpressRoute المدارة من قبل العميل ودائرات VMware Solution ExpressRoute.

اتصال الشبكة الظاهرية في Azure

يمكن توصيل شبكة Azure الظاهرية بالسحب الخاصة ل Azure VMware Solution من خلال الاتصالات بين بوابات ExpressRoute والدوائر المدارة من Azure VMware Solution. هذا الاتصال هو بالضبط نفس الطريقة التي يمكن بها توصيل شبكة Azure الظاهرية بالمواقع المحلية عبر دوائر ExpressRoute المدارة من قبل العميل. راجع الاتصال بالسحابة الخاصة يدويا للحصول على إرشادات التكوين.

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

رسم تخطيطي للشكل 4، والذي يوضح أن موارد Azure الأصلية في كل منطقة لديها اتصال L3 مباشر بالسحب الخاصة ل Azure VMware Solution.

الاتصال بالإنترنت

عند نشر السحب الخاصة ل Azure VMware Solution في مناطق متعددة، نوصي بالخيارات الأصلية للاتصال بالإنترنت (ترجمة عنوان الشبكة المصدر المدارة (SNAT) أو عناوين IP العامة وصولا إلى NSX-T). يمكن تكوين أي خيار من خلال مدخل Microsoft Azure (أو عبر قوالب PowerShell أو CLI أو ARM/Bicep) في وقت التوزيع، كما هو موضح في الشكل 5 التالي.

رسم تخطيطي للشكل 5، والذي يعرض الخيارات الأصلية ل Azure VMware Solution للاتصال بالإنترنت في مدخل Microsoft Azure.

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

  • يجب استخدام SNAT المدار في سيناريوهات ذات متطلبات أساسية وصادرة فقط (كميات منخفضة من الاتصالات الصادرة ولا حاجة للتحكم الدقيق في تجمع SNAT).
  • يجب تفضيل عناوين IP العامة وصولا إلى حافة NSX-T في السيناريوهات ذات كميات كبيرة من الاتصالات الصادرة أو عندما تحتاج إلى تحكم دقيق في عناوين IP NAT. على سبيل المثال، أي الأجهزة الظاهرية ل Azure VMware Solution تستخدم SNAT خلف عناوين IP. تدعم عناوين IP العامة وصولا إلى حافة NSX-T أيضا الاتصال الوارد عبر DNAT. لا تتناول هذه المقالة الاتصال بالإنترنت الوارد.

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

تعطل الإنترنت الأصلي في Azure

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

يمكن جذب نسبة استخدام الشبكة المرتبطة بالإنترنت المنبعثة من الأجهزة الظاهرية ل Azure VMware Solution إلى Azure VNet عن طريق إنشاء مسار افتراضي والإعلان عنه، عبر بروتوكول بوابة الحدود (BGP)، إلى دائرة ExpressRoute المدارة في السحابة الخاصة. يمكن تكوين خيار الاتصال بالإنترنت هذا من خلال مدخل Microsoft Azure (أو عبر قوالب PowerShell أو CLI أو ARM/Bicep) في وقت التوزيع، كما هو موضح في الشكل 6 التالي. لمزيد من المعلومات، راجع تعطيل الوصول إلى الإنترنت أو تمكين مسار افتراضي.

رسم تخطيطي للشكل 6، يوضح تكوين Azure VMware Solution لتمكين الاتصال بالإنترنت عبر حواف الإنترنت في شبكة Azure الظاهرية.

يمكن أن تنشأ NVAs حافة الإنترنت المسار الافتراضي إذا كانت تدعم BGP. إذا لم يكن الأمر كما هو، يجب توزيع NVAs أخرى قادرة على BGP. لمزيد من المعلومات حول كيفية تنفيذ الاتصال الصادر بالإنترنت ل Azure VMware Solution في منطقة واحدة، راجع تنفيذ اتصال الإنترنت ل Azure VMware Solution باستخدام Azure NVAs. في سيناريو المنطقة المزدوجة الذي تمت مناقشته في هذه المقالة، يجب تطبيق نفس التكوين على كلتا المنطقتين.

الاعتبار الرئيسي في سيناريوهات المنطقة المزدوجة هو أن المسار الافتراضي الذي نشأ في كل منطقة يجب نشره عبر ExpressRoute فقط إلى السحابة الخاصة ل Azure VMware Solution في نفس المنطقة. يسمح هذا النشر لأحمال عمل Azure VMware Solution بالوصول إلى الإنترنت من خلال تجزئة محلية (داخل المنطقة). ومع ذلك، إذا كنت تستخدم المخطط الموضح في الشكل 4، فإن كل سحابة خاصة ل Azure VMware Solution تتلقى أيضا مسارا افتراضيا متساوي التكلفة من المنطقة البعيدة عبر اتصالات ExpressRoute عبر المناطق. تمثل الخطوط المتقطعة الحمراء هذا الانتشار الافتراضي غير المرغوب فيه للمسار عبر المناطق في الشكل 7.

رسم تخطيطي للشكل 7، والذي يظهر أنه يجب إزالة الاتصالات عبر المناطق بين بوابات ExpressRoute ودائرات ExpressRoute المدارة بواسطة VMware Solution.

تؤدي إزالة اتصالات ExpressRoute عبر المناطق في Azure VMware Solution إلى تحقيق الهدف المتمثل في إدخال مسار افتراضي لإعادة توجيه الاتصالات المرتبطة بالإنترنت إلى حافة إنترنت Azure في المنطقة المحلية في كل سحابة خاصة.

تجدر الإشارة إلى أنه إذا تمت إزالة اتصالات ExpressRoute عبر المناطق (خطوط متقطعة حمراء في الشكل 7)، فلا يزال الانتشار عبر المناطق للمسار الافتراضي يحدث عبر Global Reach. ومع ذلك، فإن المسارات التي يتم نشرها عبر Global Reach لها مسار AS أطول من المسارات الأصلية محليا ويتم تجاهلها بواسطة عملية تحديد مسار BGP.

يوفر الانتشار عبر المناطق عبر Global Reach لمسار افتراضي أقل تفضيلا مرونة ضد أخطاء حافة الإنترنت المحلية. إذا كانت حافة الإنترنت في المنطقة غير متصلة بالإنترنت، فإنها تتوقف عن إنشاء المسار الافتراضي. في هذا الحدث، يتم تثبيت المسار الافتراضي الأقل تفضيلا الذي تم تعلمه من المنطقة البعيدة في السحابة الخاصة ل Azure VMware Solution، بحيث يتم توجيه نسبة استخدام الشبكة المرتبطة بالإنترنت عبر التقسيم الفرعي للمنطقة البعيدة.

يظهر المخطط الموصى به لعمليات النشر ثنائية المنطقة مع فواصل الإنترنت في Azure VNets في الشكل 8 التالي.

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

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

رسم تخطيطي للشكل 9، والذي يظهر سماعات BGP التي تنهي دوائر ExpressRoute التي يديرها العميل تقوم بتصفية المسارات الافتراضية ل Azure NVAs.

الخطوات التالية