Share via

إرشادات VMware HCX Mobility Optimized Networking (MON)

  • مقالة

إشعار

يتم دعم VMware HCX Mobility Optimized Networking رسميا من قبل VMware وAzure VMware Solution من HCX الإصدار 4.1.0.

هام

قبل تمكين HCX MON، يرجى قراءة القيود أدناه والتكوينات غير المدعومة:

تكوينات المصدر غير المدعومة ل HCX NE

القيود المفروضة على أي توزيع HCX بما في ذلك MON

VMware HCX Mobility Optimized Networking (MON) غير مدعوم باستخدام بوابة جهة خارجية. يمكن استخدامه فقط مع بوابة T1 المتصلة مباشرة ببوابة T0 بدون جهاز ظاهري للشبكة (NVA). قد تتمكن من إنشاء وظيفة التكوين هذه، لكننا لا ندعمها.

HCX Mobility Optimized Networking (MON) هي ميزة اختيارية لتمكينها عند استخدام ملحقات شبكة HCX (NE). يوفر MON التوجيه الأمثل لنسبة استخدام الشبكة في ظل سيناريوهات معينة لمنع انتقال الشبكة بين الموارد المحلية والمستندة إلى السحابة على الشبكات الموسعة.

نظرا لأن MON هي قدرة مؤسسة لميزة NE، تأكد من تمكين VMware HCX Enterprise من خلال مدخل Microsoft Azure.

طوال دورة الترحيل، تعمل MON على تحسين تنقل التطبيق من أجل:

  • تحسين الجهاز الظاهري (VM) لاتصال VM L2 عند استخدام الشبكات الممتدة

  • تحسين وتجنب تدفقات نسبة استخدام الشبكة غير المتماثلة بين حلول Azure VMware وAzure المحلية

في هذه المقالة، تعرف على حالات الاستخدام الخاصة ب Azure VMware Solution ل MON.

تحسين تدفقات نسبة استخدام الشبكة عبر الشرائح القياسية والممتدة على جانب السحابة الخاصة

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

إشعار

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

Diagram showing the optimization for VM to VM L2 communication when using stretched networks.

تحسين وتجنب تدفقات نسبة استخدام الشبكة غير المتماثلة

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

هام

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

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

إذا اخترت مسار NE على سبيل المثال، يجب أن تعالج مسارات نهج MON الشبكة الفرعية على وجه التحديد على الجانب المحلي؛ وإلا، يتم استخدام المسار الافتراضي 0.0.0.0/0. يمكن العثور على مسارات النهج ضمن مقطع NE، عن طريق تحديد خيارات متقدمة.

بشكل افتراضي، يتم تضمين جميع عناوين IP RFC 1918 في تعريف مسارات نهج MON.

Screenshot showing the egress traffic flow with default policy-based routes.

يؤدي هذا إلى توجيه جميع حركة مرور خروج RFC 1918 عبر مسار NE وجميع حركة الإنترنت وحركة المرور العامة التي يتم توجيهها إلى بوابة T0.

Diagram showing the RFC 1918 egress and egress traffic flow.

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

إشعار

الاعتبار الخاص لاستخدام MON في Azure VMware Solution هو إعطاء المسارات /32 المعلن عنها عبر BGP لأقرانها؛ يتضمن ذلك الاتصال المحلي وAzure عبر اتصال ExpressRoute. على سبيل المثال، يتعلم الجهاز الظاهري في Azure المسار إلى Azure VMware Solution VM على مقطع تمكين Azure VMware Solution MON. بمجرد إرسال حركة مرور الإرجاع مرة أخرى إلى بوابة T0 كما هو متوقع، إذا كانت الشبكة الفرعية العائدة مطابقة RFC 1918، يتم فرض نسبة استخدام الشبكة عبر NE بدلا من T0. ثم الخروج عبر ExpressRoute مرة أخرى إلى Azure على الجانب المحلي. يمكن أن يسبب هذا ارتباكا لجدار الحماية ذات الحالة في سلوك التوجيه الأوسط وغير المتماثل. من الجيد أيضا تحديد كيفية احتياج الأجهزة الظاهرية على شرائح NE MON إلى الوصول إلى الإنترنت، إما عبر بوابة T0 في Azure VMware Solution أو فقط من خلال NE مرة أخرى إلى أماكن العمل. بشكل عام، يجب إزالة جميع مسارات النهج الافتراضية لتجنب حركة المرور غير المتماثلة. تمكين مسارات النهج فقط إذا كانت البنية الأساسية للشبكة كما تم تكوينها بطريقة لحساب حركة المرور غير المتماثلة ومنعها.

يمكن حذف مسارات نهج MON مع عدم تحديد أي منها. يؤدي هذا إلى توجيه كافة نسبة استخدام الشبكة الخارجة إلى بوابة T0.

Screenshot showing the egress traffic flow with no policy-based routes.

يمكن تحديث مسارات نهج MON بمسار افتراضي (0.0.0.0/0). يؤدي هذا إلى توجيه جميع حركة الخروج عبر مسار NE.

Screenshot showing the egress traffic flow with a 0.0.0.0/0 policy-based route.

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

لمعرفة المزيد حول مسارات النهج، راجع مسارات نهج الشبكات المحسنة للتنقل.