اعتبارات تصميم شبكة Azure VMware Solution
يوفر Azure VMware Solution بيئة سحابية خاصة ل VMware يمكن للمستخدمين والتطبيقات الوصول إليها من البيئات أو الموارد المحلية والمستندة إلى Azure. توفر خدمات الشبكات مثل Azure ExpressRoute واتصالات الشبكة الظاهرية الخاصة (VPN) الاتصال.
هناك العديد من اعتبارات الشبكات لمراجعتها قبل إعداد بيئة Azure VMware Solution. توفر هذه المقالة حلولا لحالات الاستخدام التي قد تواجهها عند استخدام Azure VMware Solution لتكوين شبكاتك.
توافق Azure VMware Solution مع AS-Path Prepend
يحتوي Azure VMware Solution على اعتبارات تتعلق باستخدام AS-Path Prepend لتكوينات ExpressRoute المكررة. إذا كنت تقوم بتشغيل مسارين أو أكثر من مسارات ExpressRoute بين الموقع المحلي وAzure، ففكر في الإرشادات التالية للتأثير على نسبة استخدام الشبكة من Azure VMware Solution نحو موقعك المحلي عبر ExpressRoute GlobalReach.
نظرا للتوجيه غير المتماثل، يمكن أن تحدث مشكلات الاتصال عندما لا يراقب Azure VMware Solution AS-Path Prepend وبالتالي يستخدم التوجيه متعدد المسارات (ECMP) بتكلفة متساوية لإرسال نسبة استخدام الشبكة نحو بيئتك عبر كل من دوائر ExpressRoute. يمكن أن يسبب هذا السلوك مشاكل مع أجهزة فحص جدار الحماية ذات الحالة الموضوعة خلف دوائر ExpressRoute الموجودة.
المتطلبات الأساسية
بالنسبة إلى AS-Path Prepend، ضع في اعتبارك المتطلبات الأساسية التالية:
- النقطة الرئيسية هي أنه يجب عليك إلحاق أرقام ASN العامة للتأثير على كيفية توجيه Azure VMware Solution لنسبة استخدام الشبكة مرة أخرى إلى أماكن العمل. إذا قمت بالدفع المسبق باستخدام Private ASN، فسيتجاهل Azure VMware Solution prepend، وسيحدث سلوك ECMP المذكور سابقا. حتى إذا كنت تشغل Private BGP ASN محليا، فلا يزال من الممكن تكوين أجهزتك المحلية لاستخدام ASN عام عند التوجيهات المسبقة الصادرة، لضمان التوافق مع Azure VMware Solution.
- تصميم مسار نسبة استخدام الشبكة ل ASNs الخاصة بعد ASN العامة ليتم تكريمها من قبل Azure VMware Solution. لا تقوم دائرة Azure VMware Solution ExpressRoute بتعرية أي ASNs خاصة موجودة في المسار بعد معالجة ASN العامة.
- يتم توصيل كل من الدائرتين أو جميعهما ب Azure VMware Solution من خلال Azure ExpressRoute Global Reach.
- يتم الإعلان عن نفس netblocks من دائرتين أو أكثر.
- ترغب في استخدام AS-Path Prepend لفرض حل Azure VMware لتفضيل دائرة واحدة على الأخرى.
- استخدم أرقام ASN العامة المكونة من 2 بايت أو 4 بايت.
إدارة الأجهزة الظاهرية والمسارات الافتراضية من أماكن العمل
هام
لن تحترم الأجهزة الظاهرية لإدارة حلول Azure VMware مسارا افتراضيا من أماكن العمل للوجهات RFC1918.
إذا كنت تقوم بالرجوع إلى الشبكات المحلية باستخدام مسار افتراضي معلن عنه فقط نحو Azure، فلن تتبع نسبة استخدام الشبكة من vCenter Server وNSX Manager VMs التي يتم استخدامها نحو الوجهات المحلية ذات عناوين IP الخاصة هذا المسار.
للوصول إلى خادم vCenter ومدير NSX من أماكن العمل، قم بتوفير مسارات محددة للسماح لنسبة استخدام الشبكة بالحصول على مسار إرجاع إلى تلك الشبكات. على سبيل المثال، الإعلان عن ملخصات RFC1918 (10.0.0.0/8 و172.16.0.0/12 و192.168.0.0/16).
المسار الافتراضي إلى Azure VMware Solution لفحص حركة مرور الإنترنت
تتطلب بعض عمليات النشر فحص جميع حركة الخروج من Azure VMware Solution نحو الإنترنت. على الرغم من أنه من الممكن إنشاء الأجهزة الظاهرية للشبكة (NVAs) في Azure VMware Solution، إلا أن هناك حالات استخدام توجد فيها هذه الأجهزة بالفعل في Azure ويمكن تطبيقها لفحص حركة مرور الإنترنت من Azure VMware Solution. في هذه الحالة، يمكن حقن مسار افتراضي من NVA في Azure لجذب نسبة استخدام الشبكة من Azure VMware Solution وفحص حركة المرور قبل خروجها إلى الإنترنت العام.
يصف الرسم التخطيطي التالي طوبولوجيا محورية أساسية متصلة بسحابة Azure VMware Solution وشبكة محلية من خلال ExpressRoute. يوضح الرسم التخطيطي كيفية إنشاء NVA في Azure للمسار الافتراضي (0.0.0.0/0). ينشر Azure Route Server المسار إلى Azure VMware Solution من خلال ExpressRoute.
هام
سيتم نشر المسار الافتراضي الذي تعلن عنه NVA إلى الشبكة المحلية. تحتاج إلى إضافة مسارات معرفة من قبل المستخدم (UDRs) للتأكد من أن نسبة استخدام الشبكة من Azure VMware Solution تمر عبر NVA.
عادة ما يحدث الاتصال بين Azure VMware Solution والشبكة المحلية عبر ExpressRoute Global Reach، كما هو موضح في البيئات المحلية النظيرة إلى Azure VMware Solution.
الاتصال بين Azure VMware Solution وشبكة محلية
هناك سيناريوهان رئيسيان للاتصال بين Azure VMware Solution وشبكة محلية عبر NVA تابعة لجهة خارجية:
- لدى المؤسسات متطلبات لإرسال نسبة استخدام الشبكة بين Azure VMware Solution والشبكة المحلية من خلال NVA (عادة جدار حماية).
- لا يتوفر ExpressRoute Global Reach في منطقة معينة لربط دوائر ExpressRoute ل Azure VMware Solution والشبكة المحلية.
هناك طبولوجيا اثنين يمكنك تطبيقهما لتلبية جميع المتطلبات لهذه السيناريوهات: الشبكة الظاهرية للشبكة الفائقة والعبور المحوري.
هام
الخيار المفضل لتوصيل Azure VMware Solution والبيئات المحلية هو اتصال ExpressRoute Global Reach مباشر. تضيف الأنماط الموضحة في هذه المقالة تعقيدا إلى البيئة.
مخطط تصميم الشبكة الفائقة
إذا تم إنهاء كل من دوائر ExpressRoute (إلى Azure VMware Solution وإلى أماكن العمل) في نفس بوابة ExpressRoute، يمكنك افتراض أن البوابة ستوجه الحزم عبرها. ومع ذلك، فإن بوابة ExpressRoute ليست مصممة للقيام بذلك. تحتاج إلى تثبيت حركة المرور إلى NVA التي يمكن أن توجه حركة المرور.
هناك متطلبان لحركة مرور شبكة تثبيت الشعر إلى NVA:
يجب أن تعلن NVA عن شبكة فائقة ل Azure VMware Solution والبادئات المحلية.
يمكنك استخدام شبكة فائقة تتضمن كلا من Azure VMware Solution والبادئات المحلية. أو يمكنك استخدام بادئات فردية ل Azure VMware Solution ومحلي (دائما أقل تحديدا من البادئات الفعلية المعلن عنها عبر ExpressRoute). ضع في اعتبارك أن جميع بادئات الشبكة الفائقة المعلن عنها ل Route Server يتم نشرها إلى كل من Azure VMware Solution والأماكن المحلية.
تتسبب UDRs في الشبكة الفرعية للبوابة، والتي تتطابق تماما مع البادئات المعلن عنها من Azure VMware Solution ومحليها، في نسبة استخدام الشبكة من الشبكة الفرعية للبوابة إلى NVA.
ينتج عن هذا المخطط حمل إدارة عال للشبكات الكبيرة التي تتغير بمرور الوقت. ضع في اعتبارك هذه القيود:
- في أي وقت يتم إنشاء مقطع حمل العمل في Azure VMware Solution، قد تحتاج UDRs إلى إضافة لضمان نقل البيانات من Azure VMware Solution عبر NVA.
- إذا كانت بيئتك المحلية تحتوي على عدد كبير من المسارات التي تتغير، فقد تحتاج إلى تحديث تكوين Border Gateway Protocol (BGP) وUDR في الشبكة الفائقة.
- نظرا لأن بوابة ExpressRoute واحدة تعالج حركة مرور الشبكة في كلا الاتجاهين، فقد يكون الأداء محدودا.
- هناك حد لشبكة Azure الظاهرية يبلغ 400 UDRs.
يوضح الرسم التخطيطي التالي كيف يحتاج NVA إلى الإعلان عن البادئات الأكثر عمومية (أقل تحديدا) والتي تتضمن الشبكات من محلية وAzure VMware Solution. كن حذرا مع هذا النهج. يمكن أن تجذب NVA نسبة استخدام الشبكة التي لا ينبغي أن تجذبها، لأنها تعلن عن نطاقات أوسع (على سبيل المثال، الشبكة بأكملها 10.0.0.0/8 ).
مخطط الشبكة الظاهرية ل Transit spoke
إشعار
إذا لم يكن من الممكن الإعلان عن بادئات أقل تحديدا بسبب الحدود الموضحة سابقا، يمكنك تنفيذ تصميم بديل يستخدم شبكتين ظاهريتين منفصلتين.
في هذا المخطط، بدلا من نشر المسارات الأقل تحديدا لجذب حركة المرور إلى بوابة ExpressRoute، يمكن لاثنين من NVAs مختلفين في شبكات ظاهرية منفصلة تبادل المسارات بين بعضهما البعض. يمكن للشبكات الظاهرية نشر هذه المسارات إلى دوائر ExpressRoute الخاصة بها عبر BGP وAzure Route Server. كل NVA لديه تحكم كامل في البادئات التي يتم نشرها إلى كل دائرة ExpressRoute.
يوضح الرسم التخطيطي التالي كيفية الإعلان عن مسار واحد 0.0.0.0/0 إلى Azure VMware Solution. كما يوضح كيفية نشر بادئات Azure VMware Solution الفردية إلى الشبكة المحلية.
هام
مطلوب بروتوكول تغليف مثل VXLAN أو IPsec بين NVAs. التغليف مطلوب لأن محول شبكة NVA (NIC) سيتعلم المسارات من Azure Route Server مع NVA كوثبة تالية وإنشاء حلقة توجيه.
هناك بديل لاستخدام التراكب. تطبيق NICs الثانوية في NVA التي لا تتعلم المسارات من Azure Route Server. ثم قم بتكوين UDRs بحيث يمكن ل Azure توجيه نسبة استخدام الشبكة إلى البيئة البعيدة عبر تلك NIC. يمكنك العثور على مزيد من التفاصيل في تخطيط الشبكة على مستوى المؤسسة والاتصال لـ Azure VMware Solution.
يتطلب هذا المخطط إعدادا أوليا معقدا. ثم يعمل المخطط كما هو متوقع مع الحد الأدنى من الحمل الإداري. تتضمن تعقيدات الإعداد ما يلي:
- هناك تكلفة إضافية لإضافة شبكة ظاهرية أخرى للنقل تتضمن Azure Route Server وبوابة ExpressRoute وNVA آخر. قد تحتاج NVAs أيضا إلى استخدام أحجام الأجهزة الظاهرية الكبيرة لتلبية متطلبات معدل النقل.
- مطلوب نفق IPsec أو VXLAN بين NVAs اثنين، ما يعني أن NVAs موجودة أيضا في مسار البيانات. اعتمادا على نوع NVA الذي تستخدمه، يمكن أن يؤدي إلى تكوين مخصص ومعقد على NVAs هذه.
الخطوات التالية
بعد التعرف على اعتبارات تصميم الشبكة ل Azure VMware Solution، ضع في اعتبارك استكشاف المقالات التالية: