التعافي الجغرافي من الكوارث باستخدام ناقل خدمة Microsoft Azure

تعد المرونة ضد الانقطاعات الكارثية لموارد معالجة البيانات مطلباً للعديد من المؤسسات، وفي بعض الحالات تتطلبها لوائح الصناعة.

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

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

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

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

النقاط الهامة التي يجب مراعاتها

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

تلميح

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

الانقطاعات والكوارث

من المهم ملاحظة الفرق بين "الانقطاعات" و "الكوارث".

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

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

تعد ميزة التعافي من الكوارث الجغرافية في ناقل خدمة Azure أحد حلول التعافي من الكوارث. تنطبق المفاهيم وسير العمل الموضحة في هذه المقالة على سيناريوهات الكوارث، وليس حالات الانقطاع المؤقتة أو المؤقتة. للحصول على مناقشة تفصيلية لاستعادة القدرة على العمل بعد الكوارث في Microsoft Azure، راجع هذه المقالة.

المفاهيم والمصطلحات الأساسية

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

تُستخدم المصطلحات التالية في هذه المقالة:

• الاسم المستعار: اسم تكوين التعافي من الكوارث الذي أعددته. يوفر الاسم المستعار سلسلة اتصالFully Qualified Domain Name (FQDN) ثابتة واحدة. تستخدم التطبيقات سلسلة اتصال الاسم المستعار هذه للاتصال بمساحة اسم. يضمن استخدام اسم مستعار عدم تغير سلسلة الاتصال عند تشغيل تجاوز الفشل.

• مساحة الاسم الأساسية / الثانوية: مساحات الأسماء التي تتوافق مع الاسم المستعار. مساحة الاسم الأساسية "نشطة" وتتلقى الرسائل (يمكن أن تكون مساحة اسم موجودة أو جديدة). مساحة الاسم الثانوية "سلبية" ولا تتلقى رسائل. بيانات التعريف بين كليهما متزامنة، لذلك يمكن لكليهما قبول الرسائل بسلاسة دون أي تغيير في كود التطبيق أو سلسلة الاتصال. للتأكد من أن مساحة الاسم النشطة فقط تتلقى الرسائل، يجب عليك استخدام الاسم المستعار.

• بيانات التعريف: الكيانات مثل قوائم الانتظار والموضوعات والاشتراكات؛ وخصائصها للخدمة المرتبطة بمساحة الاسم. يتم نسخ الكيانات وإعداداتها فقط تلقائيًا. لا يتم تكرار الرسائل والأحداث.

• تجاوز الفشل: عملية تنشيط مساحة الاسم الثانوية.

الإعداد

القسم التالي هو نظرة عامة لإعداد الاقتران بين مساحات الأسماء.

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

1. إنشاء مساحة الاسم الأساسية للطبقة المتميزة.

2. إنشاء مساحة اسم الطبقة المتميزة الثانوية في منطقة مختلفة. هذه الخطوة اختيارية. يمكنك إنشاء مساحة اسم ثانوية أثناء إنشاء الاقتران في الخطوة التالية.

3. في مدخل Microsoft Azure، انتقل إلى مساحة الاسم الأساسية الخاصة بك.

4. حدد Geo-recovery في القائمة اليمنى وحدد بدء الاقتران على شريط الأدوات.

   

5. في صفحة بدء الاقتران، اتبع الخطوات التالية:

   1. حدد مساحة اسم ثانوية موجودة أو أنشئ واحدًا في منطقة مختلفة. في هذا المثال، يتم استخدام مساحة اسم موجودة كمساحة اسم ثانوية.

   2. بالنسبة إلى الاسم المستعار، أدخل اسمًا مستعارًا لاقتران geo-dr.

   3. وبعد ذلك، حدد إنشاء.

      

6. يجب أن تشاهد صفحة "اسم مستعار للتعافي من الكوارث في الموقع الجغرافي لناقل خدمة " كما هو موضح في الصورة التالية. يمكنك أيضا الانتقال إلى صفحة الاسم المستعار لـ Geo-DR من صفحة مساحة الاسم الأساسية عن طريق تحديد الاسترداد الجغرافي في القائمة اليسرى.

   

7. في صفحة Geo-DR Alias ​​، حدد Shared access policies في القائمة اليمنى للوصول إلى سلسلة الاتصال الأساسية للاسم المستعار. استخدم سلسلة الاتصال هذه بدلاً من استخدام سلسلة الاتصال إلى مساحة الاسم الأساسية / الثانوية مباشرةً. في البداية، يشير الاسم المستعار إلى مساحة الاسم الأساسية.

8. انتقل إلى صفحة "Overview". يمكنك القيام بالإجراءات التالية:

   1. كسر الاقتران بين مساحات الأسماء الأساسية والثانوية. حدد Break pairing على شريط الأدوات.
   2. تجاوز الفشل يدوياً إلى مساحة الاسم الثانوية.

      1. حدد Failover على شريط الأدوات.

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

      3. تشغيل خيار تجاوز الفشل الآمن لتجاوز الفشل بأمان إلى مساحة الاسم الثانوي.

         إشعار

         • يتأكد تجاوز الفشل الآمن من اكتمال النسخ المتماثلة ل Geo-DR المعلقة قبل التبديل إلى الثانوي. في حين أن تجاوز الفشل القسري أو اليدوي لا ينتظر اكتمال النسخ المتماثلة المعلقة قبل التبديل إلى الثانوي.
         • حاليا، يفشل تجاوز الفشل الآمن إذا لم تكن مساحات الأسماء الأساسية والثانوية في نفس اشتراك Azure.

      4. بعد ذلك، حدد تجاوز الفشل.

         

         هام

         يؤدي تجاوز الفشل إلى تنشيط مساحة الاسم الثانوية وإزالة مساحة الاسم الأساسية من الاقتران Geo-Disaster Recovery. قم بإنشاء مساحة اسم أخرى للحصول على زوج جديد للتعافي من الكوارث الجغرافية.

9. أخيرًا، يجب عليك إضافة بعض المراقبة لاكتشاف ما إذا كان تجاوز الفشل ضرورياً. في معظم الحالات، تكون الخدمة جزءًا واحدًا من نظام بيئي كبير، وبالتالي نادرًا ما تكون عمليات تجاوز الفشل التلقائية ممكنة؛ حيث يجب إجراء عمليات تجاوز الفشل في كثير من الأحيان بالتزامن مع النظام الفرعي أو البنية التحتية المتبقية.

ناقل الخدمة القياسي إلى المميز

إذا قمت بترحيل مساحة الاسم القياسية ناقل خدمة Azure إلى ناقل خدمة Azure Premium، فيجب عليك استخدام الاسم المستعار الموجود مسبقا (أي مساحة الاسم القياسية لناقل الخدمة سلسلة الاتصال) لإنشاء تكوين التعافي من الكوارث من خلال PS/CLI أو REST API.

وذلك لأنه أثناء الترحيل، يصبح اسم مساحة الاسم القياسية ناقل خدمة Azure سلسلة الاتصال/DNS نفسه اسما مستعارا لمساحة الاسم المميزة ناقل خدمة Azure.

يجب أن تستخدم تطبيقات العميل هذا الاسم المستعار (أي ناقل خدمة Azure مساحة الاسم القياسية سلسلة الاتصال) للاتصال بمساحة الاسم المميزة حيث تم إعداد إقران التعافي من الكوارث.

إذا كنت تستخدم مدخل Microsoft Azure لإعداد تكوين التعافي من الكوارث، فإن المدخل يلخص هذا التحذير منك.

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

يتم تشغيل تجاوز الفشل يدوياً من قبل العميل (إما بشكل صريح من خلال أمر أو من خلال منطق العمل المملوك للعميل الذي يقوم بتشغيل الأمر) ولا يتم تشغيله بواسطة Azure. فهو يمنح العميل كامل الملكية والرؤية لقرار الانقطاع على الركيزة الأساسية لـ Azure.

بعد تشغيل تجاوز الفشل -

1. يتم تحديث سلسلة اتصال الاسم المستعار للإشارة إلى مساحة الاسم المميزة الثانوية.

2. العملاء (المرسلين والمستقبلين) يتصلون تلقائياً إلى مساحة الاسم الثانوي.

3. يتم قطع الاقتران الموجود بين مساحة الاسم المميزة الأساسية والثانوية.

بمجرد بدء تجاوز الفشل -

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

2. اسحب الرسائل من مساحة الاسم الأساسية السابقة بمجرد إتاحتها مرة أخرى. بعد ذلك، استخدم مساحة الاسم هذه للرسائل العادية خارج إعداد الاسترداد الجغرافي، أو احذف مساحة الاسم الأساسية القديمة.

إشعار

يتم دعم دلالات الفشل إلى الأمام فقط. في هذا السيناريو، تتجاوز الفشل مرة أخرى ثم تعيد الاقتران بمساحة اسم جديدة. الفشل في العودة غير معتمد؛ على سبيل المثال، في مجموعة SQL.

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

الإدارة

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

استخدام مساحة الاسم الموجودة كاسم مستعار

إذا كان لديك سيناريو لا يمكنك تغيير اتصالات المنتجين والمستهلكين فيه، يمكنك إعادة استخدام اسم مساحة الاسم كاسم مستعار. انظر عينة التعليمة البرمجية على GitHub هنا.

العينات

تُظهر العينات على GitHub كيفية إعداد وبدء تجاوز الفشل. توضح هذه العينات المفاهيم التالية:

• عينة .NET وإعدادات مطلوبة في معرف Microsoft Entra لاستخدام Azure Resource Manager مع ناقل خدمة Microsoft Azure لإعداد وتمكين التعافي من الكوارث الجغرافية.
• الخطوات المطلوبة لتنفيذ عينة التعليمة البرمجية.
• كيفية استخدام مساحة اسم موجودة كاسم مستعار.
• خطوات لتمكين استرداد الأعطال الجغرافية بدلاً من ذلك عبر PowerShell أو CLI.
• أرسل واستقبل من مساحة الاسم الأساسي أو الثانوي الحالي باستخدام الاسم المستعار.

الاعتبارات

لاحظ الاعتبارات التالية التي يجب وضعها في الاعتبار مع هذا الإصدار:

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

مجموعات التوافر

يدعم ناقل خدمة Microsoft Azure Premium SKU مناطق التوفر، ما يوفر مواقع معزولة عن الأخطاء داخل نفس منطقة Azure. يدير ناقل خدمة Microsoft Azure ثلاث نسخ من مخزن المراسلة (1 أساسي و2 ثانوي). يحافظ ناقل خدمة Microsoft Azure على مزامنة جميع النسخ الثلاث لعمليات البيانات والإدارة. إذا فشلت النسخة الأساسية، يتم ترقية إحدى النسخ الثانوية إلى النسخة الأساسية دون أي توقف محسوس. إذا رأيت التطبيقات قطع اتصال عابر من ناقل خدمة Microsoft Azure، فإن منطق إعادة المحاولة في SDK يعيد الاتصال تلقائيا بناقل الخدمة.

عند استخدام مناطق التوفر، يتم نسخ بيانات التعريف والبيانات (الرسائل) عبر مراكز البيانات في منطقة التوفر.

إشعار

يتوفر دعم مناطق التوفر لناقل خدمة Microsoft Azure المميز فقط في مناطق Azure حيث توجد مناطق التوفر.

عند إنشاء مساحة اسم الطبقة المتميزة من خلال المدخل، يتم تمكين دعم مناطق التوفر (إذا كان متوفرا في المنطقة المحددة) تلقائيا لمساحة الاسم. عند إنشاء مساحة اسم الطبقة المتميزة من خلال آليات أخرى، مثل قوالب ARM / Bicep أو CLI أو PowerShell، يجب تعيين الخاصية zoneRedundant بشكل صريح لتمكين true مناطق التوفر (إذا كانت متوفرة في المنطقة المحددة). لا توجد تكلفة إضافية لاستخدام هذه الميزة ولا يمكنك تعطيل هذه الميزة أو تمكينها بعد إنشاء مساحة الاسم.

نقاط النهاية الخاصة

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

أزواج جديدة

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

إشعار

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

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

الأزواج الموجودة

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

إشعار

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

التكوين الموصى به

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

لنفترض أن لديك شبكتين ظاهريتين: VNET-1 وVNET-2 ومساحات الأسماء الأساسية والثانوية هذه: ServiceBus-Namespace1-Primary، . ServiceBus-Namespace2-Secondary عليك القيام بالخطوات التالية:

• في ServiceBus-Namespace1-Primary، قم بإنشاء نقطتي نهاية خاصتين تستخدمان الشبكات الفرعية من VNET-1 وVNET-2
• في ServiceBus-Namespace2-Secondary، قم بإنشاء نقطتي نهاية خاصتين تستخدمان نفس الشبكات الفرعية من VNET-1 وVNET-2

تتمثل ميزة هذا الأسلوب في إمكانية حدوث تجاوز الفشل في طبقة التطبيق المستقلة عن مساحة اسم ناقل الخدمة. ضع في الاعتبار السيناريوهات التالية:

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

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

إشعار

للحصول على إرشادات حول استعادة النظام الجغرافي بعد الكوارث لشبكة افتراضية، راجع الشبكة الظاهرية - استمرارية الأعمال.

التحكم في الوصول استناداً إلى الدور

لا يتم نسخ تعيينات التحكم في الوصول المستند إلى الدور (RBAC) من Microsoft Entra إلى كيانات ناقل خدمة Microsoft في مساحة الاسم الأساسية إلى مساحة الاسم الثانوية. قم بإنشاء تعيينات الأدوار يدويًا في مساحة الاسم الثانوية لتأمين الوصول إليها.

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

• انظر المرجع التعافي من الكوارث الجغرافيةREST API هنا.
• قم بتشغيل عينة التعافي من الكوارث الجغرافية على GitHub.
• راجع عينة التعافي من الكوارث الجغرافية الذي يرسل رسائل إلى اسم مستعار.

لمعرفة المزيد حول رسائل ناقل الخدمة، راجع المقالات التالية:

• قوائم انتظار ناقل خدمة Microsoft Azure والموضوعات والاشتراكات
• بدء استخدام قوائم انتظار ناقل خدمة Microsoft Azure
• كيفية استخدام موضوعات واشتراكات ناقل الخدمة
• واجهة برمجة التطبيقات REST