تكامل ExpressRoute مع الإصلاح بعد الكارثة لأجهزة Azure الظاهرية

توضح هذه المقالة كيفية تكامل Azure ExpressRoute مع Azure Site Recovery، عند الإصلاح بعد الكارثة بعد عطل فادح لأجهزة Azure الظاهرية في منطقة Azure الثانوية.

تتيح Site Recovery الإصلاح بعد الكارثة لأجهزة Azure الظاهرية الخاصة بعد عطل فادح عن طريق نسخ بيانات أجهزة Azure الظاهرية إلى Azure.

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

تمكنك ExpressRoute من توسيع الشبكات المحلية إلى سحابة Microsoft Azure عبر اتصال خاص، يتم تسهيله بواسطة موفر الاتصال. إذا قمت بتكوين ExpressRoute، فإنه يتكامل مع Site Recovery على النحو التالي:

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

قبل أن تبدأ

قبل أن تبدأ، تأكد من فهمك للمفاهيم التالية:

التوصيات العامة

للحصول على أفضل الممارسات، ولضمان فعالية Recovery Time Objectives (RTOs) للإصلاح بعد الكارثة، نوصيك بالقيام بما يلي عند إعداد Site Recovery للتكامل مع ExpressRoute:

  • توفير مكونات الشبكة قبل تجاوز الفشل في منطقة ثانوية:
    • عند تمكين النسخ المتماثل لأجهزة Azure الظاهرية، يمكن لـ Site Recovery نشر موارد الشبكة تلقائياً مثل الشبكات والشبكات الفرعية والبوابات في منطقة Azure الهدف بناءً على إعدادات الشبكة المصدر.
    • يتعذر على "Site Recovery" إعداد موارد الشبكات تلقائياً مثل بوابات الشبكة الظاهرية.
    • نوصي بتوفير موارد الشبكة الإضافية هذه قبل تجاوز الفشل. يقترن وقت تعطل بسيط بهذا النشر، ويمكن أن يؤثر على وقت الاسترداد الكلي، إذا لم تكن مسؤولاً عنه أثناء التخطيط للنشر.
  • قم بإجراء تدريبات منتظمة على الإصلاح بعد الكارثة:
    • يتحقق التدريب من إستراتيجية النسخ المتماثل الخاصة بك دون فقد البيانات أو وقت تعطلها، ولا يؤثر على بيئة التشغيل لديك. يساعد في تجنب مشاكل التكوين في اللحظة الأخيرة التي يمكن أن تؤثر سلباً على هدف وقت الاسترداد.
    • عند تشغيل اختبار تجاوز الفشل للانتقال، نوصي باستخدام شبكة جهاز Azure الظاهري منفصلة، بدلاً من الشبكة الافتراضية التي تم إعدادها عند تمكين النسخ المتماثل.
  • استخدم مساحات عناوين IP مختلفة إذا كانت لديك دائرة ExpressRoute واحدة.
    • نوصي باستخدام مساحة عنوان IP مختلفة للشبكة الظاهرية الهدف. هذا يجنب المشاكل عند إنشاء اتصالات أثناء الانقطاعات الإقليمية.
    • إذا لم تتمكن من استخدام مساحة عنوان منفصلة، فتأكد من تشغيل اختبار الإصلاح بعد كارثة على شبكة اختبار منفصلة بعناوين IP مختلفة. لا يمكنك توصيل شبكتي ظاهرية بمساحة عنوان IP متداخلة بدائرة ExpressRoute نفسها.

إجراء نسخ متماثل لأجهزة Azure الظاهرية عند استخدام ExpressRoute

إذا كنت تريد إعداد النسخ المتماثل لأجهزة Azure الظاهرية في موقع أساسي، وكنت تتصل بهذه الأجهزة الظاهرية من موقعك المحلي عبر ExpressRoute، فإليك ما تحتاج إلى القيام به:

  1. تمكين النسخ المتماثل لكل جهاز من أجهزة Azure الظاهرية.
  2. اسمح اختيارياً لـ Site Recovery بإعداد الشبكات:
    • عند تكوين النسخ المتماثل وتمكينه، تقوم "Site Recovery" بإعداد الشبكات والشبكات الفرعية للبوابة في منطقة Azure الهدف لمطابقة الشبكات الموجودة في منطقة المصدر. تقوم Site Recovery أيضاً بتعيين الشبكات الظاهرية المصدر والهدف.
    • إذا كنت لا تريد أن تقوم "Site Recovery" بذلك تلقائياً، فقم بإنشاء موارد الشبكة على الجانب الهدف قبل تمكين النسخ المتماثل.
  3. إنشاء عناصر أخرى للشبكات:
    • لا تقوم Site Recovery بإنشاء جداول التوجيه أو بوابات شبكة ظاهرية أو اتصالات بوابة شبكة ظاهرية أو نظير الشبكة الظاهرية أو موارد الشبكات والوصلات الأخرى في المنطقة الثانوية.
    • تحتاج إلى إنشاء عناصر الشبكة الإضافية هذه في المنطقة الثانوية، في أي وقت قبل تشغيل تجاوز الفشل من المنطقة الأساسية.
    • يمكنك استخدام خطط الاسترداد والبرامج النصية للأتمتة لإعداد وتوصيل موارد الشبكات هذه.
  4. إذا كان لديك جهاز شبكة ظاهري (NVA) تم نشره للتحكم في نسبة استخدام الشبكة، فلاحظ ما يلي:
    • مسار النظام الافتراضي لـ Azure للنسخ المتماثل لجهاز Azure الظاهري هو 0.0.0.0/0.
    • عادةً ما تحدد عمليات نشر جهاز شبكة ظاهري أيضاً مساراً افتراضياً (0.0.0.0/0) يفرض نسبة استخدام الشبكة الإنترنت الصادرة للتدفق عبر جهاز شبكة ظاهري (NVA). يتم استخدام المسار الافتراضي في حالة عدم العثور على تكوين مسار محدد آخر.
    • إذا كانت هذه هي الحالة، فقد يتم تحميل جهاز شبكة ظاهري (NVA) بشكل زائد إذا مرت كل نسبة استخدام الشبكة النسخ المتماثل عبر جهاز شبكة ظاهري (NVA).
    • ينطبق نفس القيد أيضاً عند استخدام المسارات الافتراضية لتوجيه كل نسبة استخدام الشبكة لشبكة Azure الظاهرية إلى عمليات النشر المحلية.
    • في هذا السيناريو، نوصي بأن تقوم بإنشاء نقطة نهاية خدمة شبكة في شبكتك الظاهرية لخدمة Microsoft.Storage، بحيث لا تترك نسبة استخدام الشبكة للنسخ المتماثل حدود Azure.

مثال على النسخ المتماثل

عادةً ما تحتوي عمليات النشر المؤسسية على أحمال العمل مقسمة عبر شبكة Azure الظاهرية المتعددة، مع محور اتصال مركزي للاتصال الخارجي بالإنترنت والمواقع المحلية. عادةً ما يتم استخدام هيكل المحور والمركز مع ExpressRoute.

On-premises-to-Azure with ExpressRoute before failover

  • ⁧⁧⁩⁩المنطقة.⁧⁧⁩⁩ يتم نشر التطبيقات في منطقة Azure East Asia.
  • الشبكات الظاهرية المحورية. يتم نشر التطبيقات في اثنتين من شبكات الشبكات الظاهرية المحورية:
    • الشبكة الظاهرية المصدر 1: 10.1.0.0/24.
    • Source vNet2: 10.2.0.0/24.
    • يتم توصيل كل شبكة ظاهرية المحورية مع شبكة ظاهرية مركزية.
  • شبكة ظاهرية مركزية. هناك شبكة محورية شبكة ظاهرية مركزية مصدر: 10.10.10.0/24.
    • تعمل الشبكة الظاهرية المركزية هذه كحارس بوابة.
    • تمر جميع الاتصالات عبر الشبكات الفرعية عبر هذا المركز.
      • شبكات فرعية للشبكة المركزية. تحتوي الشبكة الظاهرية المركزية على شبكتين فرعيتين:
      • الشبكة الفرعية للجهاز الظاهري للشبكة: 10.10.10.0/25. تحتوي هذه الشبكة الفرعية على جهاز ظاهري للشبكة (10.10.10.10).
      • الشبكة الفرعية للبوابة: 10.10.10.128/25. تحتوي هذه الشبكة الفرعية على بوابة ExpressRoute متصلة باتصال ExpressRoute يوجه إلى الموقع المحلي عبر مجال توجيه نظير خاص.
  • يحتوي مركز البيانات المحلي على اتصال دائرة ExpressRoute من خلال حافة شريك في هونغ كونغ.
  • يتم التحكم في كل التوجيه من خلال جداول توجيه Azure (UDR).
  • يتم توجيه كل نسبة استخدام الشبكة الصادرة بين الشبكات الظاهرية أو إلى مركز البيانات الداخلي عبر NVA.

إعدادات النظراء المركزية والمحورية

المحور إلى المركز

الاتجاه الإعداد الولاية
المحور إلى المركز السماح بعنوان الشبكة الظاهرية تم التمكين
المحور إلى المركز السماح بنسبة استخدام الشبكة المعاد توجيهها تم التمكين
المحور إلى المركز السماح بعبور البوابة ⁧⁩مُعطل⁧⁩
المحور إلى المركز استخدم بوابات الإزالة تم التمكين

Spoke to hub peering configuration

المحور إلى المركز

الاتجاه الإعداد الولاية
المحور إلى المركز السماح بعنوان الشبكة الظاهرية تم التمكين
المحور إلى المركز السماح بنسبة استخدام الشبكة المعاد توجيهها تم التمكين
المحور إلى المركز السماح بعبور البوابة تم التمكين
المحور إلى المركز استخدم بوابات الإزالة ⁧⁩مُعطل⁧⁩

Hub to spoke peering configuration

خطوات المثال

في مثالنا، يجب أن يحدث ما يلي عند تمكين النسخ المتماثل لأجهزة Azure الظاهرية في الشبكة المصدر:

  1. يمكنك تمكين النسخ المتماثل لجهاز ظاهري.
  2. ستقوم Site Recovery بإنشاء الشبكات الظاهرية للنسخة المتماثلة والشبكات الفرعية والشبكات الفرعية للبوابة في المنطقة الهدف.
  3. يقوم "Site Recovery" بإنشاء تعيينات بين شبكات المصدر والشبكات الهدف للنسخة المتماثلة التي يقوم بإنشائها.
  4. يمكنك إنشاء بوابات شبكة ظاهرية يدوياً أو اتصالات عبّارة الشبكة الظاهرية أو نظارة الشبكة الظاهرية أو أي موارد أو اتصالات أخرى للشبكات.

فشل في تجاوز أجهزة Azure الظاهرية عند استخدام ExpressRoute

بعد فشل أجهزة Azure الظاهرية في منطقة Azure الهدف باستخدام Site Recovery، يمكنك الوصول إليها باستخدام النظير الخاص لـ ExpressRoute.

  • تحتاج إلى توصيل ExpressRoute بشبكة الشبكة الظاهرية الهدف باتصال جديد. لا يتم نقل اتصال ExpressRoute الحالي تلقائياً.
  • تعتمد طريقة إعداد اتصال ExpressRoute الخاص بك بالشبكة الظاهرية الهدف على طوبولوجيا ExpressRoute الخاص بك.

الوصول باستخدام دائرتين

دائرتان مع موقعين للتناظر

يساعد هذا التكوين في حماية دوائر ExpressRoute من الكوارث الإقليمية. إذا تعطل موقع النظير الأساسي الخاص بك، يمكن أن تستمر الاتصالات من الموقع الآخر.

  • عادة ما تكون الدائرة المتصلة ببيئة التشغيل هي الدائرة الأساسية. عادةً ما يكون للدائرة الثانوية عرض نطاق ترددي منخفض، ويمكن زيادته في حالة حدوث كارثة.
  • بعد تجاوز الفشل، يمكنك إنشاء اتصالات من دائرة ExpressRoute الثانوية بالشبكة الظاهرية الهدف. بدلاً من ذلك، يمكنك إعداد اتصالات وتكون جاهزة في حالة وقوع كارثة لتقليل وقت الاسترداد الإجمالي.
  • من خلال الاتصالات المتزامنة بالشبكات الظاهرية الأساسية والهدف، تأكد من أن التوجيه الداخلي الخاص بك يستخدم فقط الدائرة الثانوية والاتصال بعد تجاوز الفشل.
  • يمكن للشبكات الظاهرية المصدر والهدف تلقي عناوين IP جديدة، أو الاحتفاظ بنفس العناوين بعد تجاوز الفشل. في كلتا الحالتين، يمكن إنشاء التوصيلات الثانوية قبل تجاوز الفشل.

دائرتان مع موقع تناظر واحد

يساعد هذا التكوين في الحماية من فشل دائرة ExpressRoute الأساسية، ولكن ليس في حالة تعطل موقع تناظر ExpressRoute الفردي، ما يؤثر على كلتا الدائرتين.

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

الوصول باستخدام دائرة واحدة

في هذا التكوين، توجد دائرة Expressroute واحدة فقط. على الرغم من أن الدائرة بها اتصال زائدة عن الحاجة في حالة تعطل أحدها، فإن دائرة مسار واحد لن توفر المرونة إذا تعطلت منطقة النظير لديك. لاحظ ما يلي:

  • إذا لم تكن منطقة Azure الهدف في نفس الموقع مثل المصدر، فستحتاج إلى تمكين ExpressRoute Premium إذا كنت تستخدم دائرة ExpressRoute واحدة. تعرف على معلومات حول مواقع ExpressRoute وأسعار ExpressRoute.
  • لا يمكنك توصيل الشبكات الظاهرية المصدر والهدف في نفس الوقت بالدائرة إذا تم استخدام نفس مساحة عنوان IP في المنطقة الهدف. في هذا السيناريو:
    • افصل اتصال جانب المصدر، ثم قم بتأسيس الاتصال الجانبي الهدف. يمكن كتابة تغيير الاتصال هذا كجزء من خطة استرداد Site Recovery. لاحظ ما يلي:
      • في حالة فشل إقليمي، إذا تعذر الوصول إلى المنطقة الأساسية، فقد تفشل عملية قطع الاتصال. قد يؤثر ذلك على إنشاء الاتصال بالمنطقة الهدف.
      • إذا قمت بإنشاء الاتصال في المنطقة الهدف واستردت المنطقة الأساسية لاحقاً، فقد تواجه حالات انقطاع الحزمة إذا حاول اتصالان متزامنان الاتصال بنفس مساحة العنوان.
      • لمنع هذا، قم بإنهاء الاتصال الأساسي على الفور.
      • بعد فشل عودة الجهاز الظاهري إلى المنطقة الأساسية، يمكن إنشاء الاتصال الأساسي مرة أخرى، بعد قطع الاتصال الثانوي.
  • إذا تم استخدام مساحات عنوان مختلفة على شبكة ظاهرية الهدف، يمكنك الاتصال في نفس الوقت بمصدر شبكات ظاهرية والهدف من نفس دائرة ExpressRoute.

مثال على تجاوز الفشل

في مثالنا، نستخدم الطوبولوجيا التالية:

  • دائرتان مختلفتان لـ ExpressRoute في موقعين مختلفين للتناظر.
  • احتفظ بعناوين IP الخاصة لأجهزة Azure الظاهرية بعد تجاوز الفشل.
  • منطقة الاسترداد الهدف هي Azure SouthEast Asia.
  • يتم إنشاء اتصال دائرة ExpressRoute ثانوي من خلال حافة شريك في سنغافورة.

للحصول على طوبولوجيا بسيطة تستخدم دائرة ExpressRoute واحدة، بنفس عنوان IP بعد تجاوز الفشل، راجع هذه المقالة.

خطوات المثال

لأتمتة الاسترداد في هذا المثال، إليك ما عليك القيام به:

  1. اتبع الخطوات لإعداد النسخ المتماثل.

  2. تجاوز فشل أجهزة Azure الظاهرية، باستخدام هذه الخطوات الإضافية أثناء تجاوز الفشل أو بعده.

    أ. قم بإنشاء Azure ExpressRoute Gateway في مركز المنطقة الهدف لشبكة ظاهرية. هذا يحتاج إلى توصيل المركز الهدف لشبكة ظاهرية بدائرة ExpressRoute.

    ب. قم بإنشاء الاتصال من المحور الهدف لشبكة ظاهرية إلى دائرة ExpressRoute الهدف.

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

    د. قم بإعداد UDRs في مركز شبكة ظاهرية، ومحور الاثنين عن الشبكات الظاهرية.

    • خصائص الجانب الهدف UDRs هي نفسها الموجودة على جانب المصدر عند استخدام نفس عناوين IP.
    • مع اختلاف عناوين IP الهدف، يجب تعديل UDRs وفقاً لذلك.

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

بعد الاسترداد

بعد استرداد الأجهزة الظاهرية واستكمال الاتصال، تكون بيئة الاسترداد كما يلي.

On-premises-to-Azure with ExpressRoute after Failover

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

تعرف على المزيد حول استخدام خطط الاسترداد لأتمتة تجاوز فشل التطبيقات.