إرشادات VMware HCX Mobility Optimized Networking (MON)
ملاحظة
يتم دعم HCX Mobility Optimized Networking رسميا بواسطة VMware و Azure VMware Solutions من الإصدار 4.1.0 من HCX.
هام
قبل تمكين HCX MON، يرجى قراءة القيود التالية والتكوينات غير المدعومة:
تعد شبكة HCX المحسنة للتنقل (MON) ميزة اختيارية لتمكينها عند استخدام ملحقات شبكة HCX (NE). يوفر MON التوجيه الأمثل لحركة المرور في ظل سيناريوهات معينة لمنع تجويف الشبكة بين الموارد المحلية والموارد المستندة إلى السحابة على الشبكات الموسعة.
نظرا لأن MON هي إحدى قدرات المؤسسات لميزة NE ، تأكد من تمكين الوظيفة الإضافية VMware HCX Enterprise من خلال طلب دعم. سيكون إصدار VMware HCX Enterprise Edition متاحا للعملاء لإضافته وتشغيله باستخدام بيئة Azure VMware Solution الخاصة بهم مجانا حتى 10/1/2022.
طوال دورة الترحيل ، تعمل MON على تحسين تنقل التطبيقات من أجل:
التحسين للاتصال بين الجهاز الظاهري (VM) و VM L2 عند استخدام الشبكات الممتدة
تحسين وتجنب تدفقات حركة المرور غير المتماثلة بين المحلي، وAzure VMware Solution، وAzure
في هذه المقالة، ستتعرف على حالات الاستخدام الخاصة ب Azure VMware Solution ل MON.
تحسين تدفقات حركة المرور عبر القطاعات القياسية والممتدة على الجانب السحابي الخاص
في هذا السيناريو، يتم ترحيل VM1 إلى السحابة باستخدام NE، والذي يوفر الكمون الأمثل VM إلى VM. ونتيجة لذلك، يحتاج VM1 إلى زمن انتقال منخفض إلى VM3 في قطاع حلول Azure VMware المحلي. نقوم بترحيل بوابة VM1 من الموقع إلى Azure VMware Solution (السحابة) لضمان مسار مثالي لحركة المرور (الخط الأزرق). إذا ظلت البوابة في مكان العمل (الخط الأحمر) ، ملاحظة تأثير التجول وزمن انتقال أعلى.
ملاحظة
عند تمكين MON دون ترحيل بوابة VM إلى الجانب السحابي ، فإنها لا تضمن مسارا مثاليا لتدفق حركة المرور. كما أنه لا يسمح بتقييم مسارات السياسة.
تحسين وتجنب تدفقات حركة المرور غير المتماثلة
في هذا السيناريو، نفترض أنه تم ترحيل جهاز ظاهري من محلي إلى Azure VMware Solution ويشارك في L2، وتتدفق حركة مرور L3 مرة أخرى إلى أماكن العمل للوصول إلى الخدمات. نفترض أيضا أن بعض اتصالات VM من Azure (في Azure VMware Solution المتصلة vNET) يمكن أن تصل إلى سحابة Azure VMware Solution الخاصة.
هام
النقطة الرئيسية هنا هي تخطيط وتجنب تدفقات حركة المرور غير المتماثلة بعناية.
بشكل افتراضي وبدون استخدام MON، يمكن للجهاز الظاهري في Azure VMware Solution على شبكة ممتدة بدون MON الاتصال مرة أخرى إلى أماكن العمل باستخدام المسار المفضل ExpressRoute. من الناحية المثالية ، واستنادا إلى حالة استخدام العملاء ، يجب على المرء تقييم كيفية عبور VM على جزء ممتد من Azure VMware Solution تم تمكينه باستخدام MON إلى أماكن العمل إما عبر بوابة NE أو T0 عبر ExpressRoute ، مع الحفاظ على تدفقات حركة المرور متماثلة.
في حالة اختيار مسار NE على سبيل المثال ، يجب أن تتناول مسارات سياسة MON على وجه التحديد الشبكة الفرعية على الجانب المحلي ؛ وإلا، يتم استخدام المسار الافتراضي 0.0.0.0/0. يمكن العثور على مسارات السياسة ضمن قطاع NE ، مع تحديد خيارات متقدمة. بشكل افتراضي، يتم تضمين كافة عناوين IP RFC1918 في تعريف مسارات نهج MON.
يتم تقييم مسارات النهج فقط إذا تم ترحيل بوابة VM إلى السحابة. تأثير هذا التكوين هو أن أي شبكات فرعية مطابقة للوجهة يتم نفقها فوق جهاز NE. إذا لم تكن متطابقة ، توجيهها عبر بوابة T0.
ملاحظة
الاعتبار الخاص لاستخدام MON في Azure VMware Solution هو إعطاء طرق /32 المعلن عنها عبر BGP لأقرانها ؛ يتضمن ذلك الاتصال المحلي وAzure عبر اتصال ExpressRoute. على سبيل المثال، يتعلم جهاز ظاهري في Azure المسار إلى جهاز ظاهري لحلول Azure VMware على مقطع ممكن من Azure VMware Solution MON. بمجرد إرسال حركة المرور المرتجعة مرة أخرى إلى T0 كما هو متوقع ، إذا كانت الشبكة الفرعية المرتجعة هي مطابقة RFC1918 ، فرض حركة المرور عبر NE بدلا من T0. ثم يخرج عبر ExpressRoute عائدا إلى Azure على الجانب المحلي. يمكن أن يسبب هذا ارتباكا لجدران الحماية ذات الحالة في سلوك التوجيه الأوسط وغير المتماثل. من الجيد أيضا تحديد كيفية وصول الأجهزة الظاهرية على شرائح NE MON إلى الإنترنت ، إما عبر T0 في Azure VMware Solution أو فقط من خلال NE مرة أخرى إلى محلي.
كما هو موضح في الرسم البياني أعلاه ، تكمن الأهمية في مطابقة مسار السياسة مع كل شبكة فرعية مطلوبة. خلاف ذلك ، يتم توجيه حركة المرور عبر T0 وليس NE.
لمعرفة المزيد حول مسارات النهج، راجع مسارات نهج الشبكات المحسنة للتنقل .