استبقاء عناوين IP أثناء تجاوز الفشل

هل هذه الصفحة مفيدة؟

هل لديك ملاحظات إضافية؟

سيتم إرسال الملاحظات إلى Microsoft: بالضغط على الزر «إرسال»، سيتم استخدام ملاحظاتك لتحسين منتجات Microsoft وخدماتها. نهج الخصوصية.

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

أثناء تجاوز الفشل، قد ترغب في الاحتفاظ بعنوان IP في المنطقة الهدف مطابقاً للمنطقة المصدر:

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

توفر هذه المقالة بعض الأمثلة لاستبقاء عناوين IP في أمثلة سيناريوهات أكثر تعقيداً. ومن الأمثلة على ذلك:

• تجاوز الفشل لشركة لديها كافة الموارد قيد التشغيل في Azure
• تجاوز الفشل لشركة ذات توزيع مختلط وموارد تعمل محلياً وفي Azure

الموارد في Azure: تجاوز الفشل الكامل

تعمل جميع تطبيقات الشركة A في Azure.

قبل تجاوز الفشل

[! "ملاحظة" يمكن الآن إجراء النسخ المتماثل بين أي منطقتين من مناطق Azure حول العالم. لم يعد العملاء مقتصرين على تمكين النسخ المتماثل داخل قارتهم.

إليك البنية قبل تجاوز الفشل.

• تمتلك الشركة A شبكات وشبكات فرعية متطابقة في مناطق Azure المصدر والهدف.
• لتقليل هدف وقت الاسترداد (RTO)، تستخدم الشركة عُقد النسخ المتماثل لمجموعات قابلية وصول عالية التوفر AlwaysOn على SQL Server، ووحدة التحكم في المجال، وما إلى ذلك. وتوجد عقد النسخ المتماثل في شبكة ظاهرية مختلفة في المنطقة الهدف، بحيث يمكنها إنشاء اتصالية VPN من موقع إلى موقع بين المناطق المصدر والهدف. إذا استُخدمَت مساحة عنوان IP نفسها في المصدر والهدف، فإن هذا غير ممكن.
• قبل تجاوز الفشل، تكون بنية الشبكة كما يلي:
  • المنطقة الرئيسية هي Azure شرق آسيا
    • تحتوي شرق آسيا على شبكة ظاهرية (الشبكة الظاهرية المصدر) مع مساحة العنوان 10.1.0.0/16.
    • لدى شرق آسيا حمل عمل مقسم عبر ثلاث شبكات فرعية في الشبكة الظاهرية:
      • الشبكة الفرعية 1: 10.1.1.0/24
      • الشبكة الفرعية 2: 10.1.2.0/24
      • الشبكة الفرعية 3: 10.1.3.0/24
  • المنطقة الثانوية (الهدف) هي Azure جنوب شرق آسيا
    • جنوب شرق آسيا لديها شبكة ظاهرية للاسترداد (الشبكة الظاهرية للاسترداد) مماثلة لـ الشبكة الظاهرية المصدر.
    • يحتوي جنوب شرق آسيا على شبكة ظاهرية إضافية (الشبكة الظاهرية Azure) مع مساحة العنوان 10.2.0.0/16.
    • الشبكة الظاهرية Azure تحتوي على شبكة فرعية (شبكة فرعية 4) مع مساحة عنوان 10.2.4.0/24.
    • توجد عقد النسخ المتماثل لمجموعات قابلية وصول عالية التوفر AlwaysOn على SQL Server ووحدة التحكم في المجال وما إلى ذلك في شبكة فرعية 4.
  • تتصل الشبكة الظاهرية المصدر والشبكة الظاهرية Azure باتصال VPN من موقع إلى موقع.
  • لا تتصل الشبكة الظاهرية للاسترداد بأي شبكة ظاهرية أخرى.
  • تُعين الشركة A/تتحقق من عناوين IP الهدف للعناصر المتماثلة. عنوان IP الهدف هو نفسه عنوان IP المصدر لكل جهاز ظاهري.

بعد تجاوز الفشل

في حالة حدوث انقطاع إقليمي في المصدر، يمكن أن تتجاوز الشركة A الفشل في جميع مواردها إلى المنطقة الهدف.

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

  • يمكن للشركة استخدام خطط الاسترداد لتحديد متى سيتم إنشاء الاتصالات.

  • يمكنهم الاتصال بين الشبكات الظاهرية باستخدام نظير الشبكة الظاهرية أو الشبكة الظاهرية الخاصة (VPN) من موقع إلى موقع.

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

    

الموارد في Azure: تجاوز فشل التطبيق المعزول

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

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

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

قبل تجاوز الفشل

قبل تجاوز الفشل، تكون البنية كما يلي:

• تُستضاف الأجهزة الظاهرية للتطبيق في منطقة Azure شرق آسيا الأساسية:

  • التطبيق 1 توجد الأجهزة الظاهرية في شبكة ظاهرية الشبكة الظاهرية المصدر 1: 10.1.0.0/16
  • التطبيق 2 توجد الأجهزة الظاهرية في شبكة ظاهرية الشبكة الظاهرية المصدر 1: 10.2.0.0/16
  • الشبكة الظاهرية المصدر 1 تحتوي على شبكتين فرعيتين.
  • الشبكة الظاهرية المصدر 2 تحتوي على شبكتين فرعيتين.

• المنطقة الثانوية (الهدف) هي Azure جنوب شرق آسيا - جنوب شرق آسيا فيها شبكات ظاهرية للاسترداد (الشبكة الظاهرية للاسترداد 1 والشبكة الظاهرية للاسترداد 2 ) التي تتطابق مع الشبكة الظاهرية المصدر 1 والشبكة الظاهرية المصدر 2. - تحتوي الشبكة الظاهرية للاسترداد 1 والشبكة الظاهرية للاسترداد 2 على شبكتين فرعيتين تتطابقان مع الشبكات الفرعية في الشبكة الظاهرية المصدر 1 والشبكة الظاهرية المصدر 2 - جنوب شرق آسيا تحتوي على شبكة ظاهرية إضافية (الشبكة الظاهرية Azure) بمساحة العنوان 10.3.0.0/16. - تحتوي الشبكة الظاهرية Azure على شبكة فرعية (الشبكة الفرعية 4) مع مساحة عنوان 10.3.4.0/24. - توجد عقد النسخ المتماثل لمجموعات قابلية وصول عالية التوفر AlwaysOn على SQL Server ووحدة التحكم في المجال وما إلى ذلك في شبكة فرعية 4.

• هناك عدد من اتصالات VPN من موقع إلى موقع:

  • الشبكة الظاهرية المصدر 1 والشبكة الظاهرية Azure
  • الشبكة الظاهرية المصدر 2 والشبكة الظاهرية Azure
  • تتصل الشبكة الظاهرية المصدر 1 والشبكة الظاهرية المصدر 2 بشبكة VPN من موقع إلى موقع

• لا تتصل الشبكة الظاهرية للاسترداد 1 والشبكة الظاهرية للاسترداد 2 بأي شبكات ظاهرية أخرى.

• تُكوّن الشركة A بوابات VPN على الشبكة الظاهرية للاسترداد 1 والشبكة الظاهرية للاسترداد 2 لتقليل هدف وقت الاسترداد.

• لا تتصل الشبكة الظاهرية للاسترداد 1 والشبكة الظاهرية للاسترداد 2 بأي شبكة ظاهرية أخرى.

• لتقليل هدف وقت الاسترداد (RTO)، تُكوّن بوابات VPN على الشبكة الظاهرية للاسترداد 1 والشبكة الظاهرية للاسترداد 2 قبل تجاوز الفشل.

  

بعد تجاوز الفشل

في حالة حدوث انقطاع أو مشكلة تؤثر في تطبيق واحد (في **الشبكة الظاهرية المصدر 2 في المثال)، يمكن للشركة A استرداد التطبيق المُتأثر على النحو التالي:

• اقطع اتصالات VPN بين الشبكة الظاهرية المصدر 1 والشبكة الظاهرية المصدر 2، وبين الشبكة الظاهرية المصدر 2 والشبكة الظاهرية Azure.
• أنشئ اتصالات VPN بين الشبكة الظاهرية المصدر 1 والشبكة الظاهرية للاسترداد 2، وبين الشبكة الظاهرية للاسترداد 2 والشبكة الظاهرية Azure.
• تجاوز فشل الأجهزة الظاهرية في الشبكة الظاهرية المصدر 2 إلى الشبكة الظاهرية للاسترداد 2.

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

الموارد المختلطة: تجاوز الفشل الكامل

في هذا السيناريو، تقوم الشركة B بتشغيل أعمال مختلطة، مع تشغيل جزء من البنية الأساسية للتطبيق على Azure، والباقي يعمل محلياً.

قبل تجاوز الفشل

إليك ما تبدو عليه بنية الشبكة قبل تجاوز الفشل.

• تُستضاف الأجهزة الظاهرية للتطبيق في منطقة شرق آسيا.
• تحتوي شرق آسيا على شبكة ظاهرية (الشبكة الظاهرية المصدر) مع مساحة العنوان 10.1.0.0/16.
  • لدى شرق آسيا حمل عمل مقسم عبر ثلاث شبكات فرعية في الشبكة الظاهرية المصدر:
    • الشبكة الفرعية 1: 10.1.1.0/24
    • الشبكة الفرعية 2: 10.1.2.0/24
    • الشبكة الفرعية 3: 10.1.3.0/24، باستخدام شبكة ظاهرية Azure مع مساحة العنوان 10.1.0.0/16. تسمى هذه الشبكة الظاهرية الشبكة الظاهرية المصدر
      • المنطقة الثانوية (الهدف) هي Azure جنوب شرق آسيا:
  • جنوب شرق آسيا لديها شبكة ظاهرية للاسترداد (الشبكة الظاهرية للاسترداد) مماثلة لـ الشبكة الظاهرية المصدر.
• تتصل الأجهزة الظاهرية في شرق آسيا بمركز بيانات محلي باستخدام Azure ExpressRoute أو VPN من موقع إلى موقع.
• لتقليل هدف وقت الاسترداد، توفر الشركة B بوابات على الشبكة الظاهرية للاسترداد في Azure جنوب شرق آسيا قبل تجاوز الفشل.
• تُعين الشركة B/تتحقق من عناوين IP الهدف للأجهزة الظاهرية المتماثلة. عنوان IP الهدف هو نفسه عنوان IP المصدر لكل جهاز ظاهري.

بعد تجاوز الفشل

في حالة حدوث انقطاع إقليمي في المصدر، يمكن أن تتجاوز الشركة B الفشل في جميع مواردها إلى المنطقة الهدف.

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

الموارد المختلطة: تجاوز فشل التطبيق المعزول

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

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

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

تعرف على خطط الاسترداد.