التعافي من انقطاع الخدمة على مستوى المنطقة

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

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

الخدمات السحابية

إدارة الموارد

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

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

إشعار

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

موازنة التحميل

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

الاستراتيجيات

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

• إعادة توزيع عند الكوارث: في هذا النهج، يتم إعادة توزيع التطبيق من الصفر في وقت وقوع الكارثة. هذا مناسب للتطبيقات غير الهامة التي لا تتطلب وقت استرداد مضمون.

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

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

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

الأجهزة الظاهرية

يشبه استرداد البنية الأساسية كخدمة (IaaS) الأجهزة الظاهرية (VMs) استرداد حساب النظام الأساسي كخدمة (PaaS) في العديد من النواحي. ومع ذلك، هناك اختلافات مهمة لأن الجهاز الظاهري IaaS يتكون من كل من الجهاز الظاهري وقرص الجهاز الظاهري.

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

• افصل قرص البيانات عن قرص نظام التشغيل. أحد الاعتبارات المهمة لأجهزة IaaS الظاهرية هو أنه لا يمكنك تغيير قرص نظام التشغيل دون إعادة إنشاء الجهاز الظاهري. هذه ليست مشكلة إذا كانت استراتيجية الاسترداد الخاصة بك هي إعادة التوزيع بعد الكارثة. ومع ذلك، قد تكون هناك مشكلة إذا كنت تستخدم نهج Warm Spare لحجز السعة. لتنفيذ هذا بشكل صحيح، يجب أن يكون لديك قرص نظام التشغيل الصحيح الموزع على كل من المواقع الأساسية والثانوية، ويجب تخزين بيانات التطبيق على محرك أقراص منفصل. إذا كان ذلك ممكنا، استخدم تكوين نظام تشغيل قياسي يمكن توفيره على كلا الموقعين. بعد تجاوز الفشل، يجب عليك بعد ذلك إرفاق محرك أقراص البيانات بالأجهزة الظاهرية لـ IaaS الموجودة في DC الثانوي. استخدم AzCopy لنسخ لقطات من قرص (أقراص) البيانات إلى موقع بعيد.

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

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

التخزين

الاسترداد باستخدام التخزين المتكرر جغرافيا للكائن الثنائي كبير الحجم والجدول وقائمة الانتظار وتخزين قرص الجهاز الظاهري

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

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

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

لمزيد من المعلومات حول كل من تخزين GRS وRA-GRS، راجع النسخ المتماثل لتخزين Azure.

تعيينات منطقة النسخ المتماثل الجغرافي

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

أسعار النسخ المماثل الجغرافي

يتم تضمين النسخ المتماثل الجغرافي في التسعير الحالي لـ Azure Storage. يسمى هذا التخزين المتكرر جغرافيا (GRS). إذا كنت لا تريد نسخ بياناتك جغرافيا، يمكنك تعطيل النسخ المتماثل الجغرافي لحسابك. ويسمى هذا التخزين المتكرر محليا (LRS)، ويتم تحصيله بسعر مخفض مقارنة بـ GRS.

تحديد ما إذا كان قد حدث تجاوز فشل جغرافي

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

قاعدة البيانات

قاعدة بيانات SQL

توفر Azure SQL Database نوعين من الاسترداد: الاستعادة الجغرافية والنسخ المتماثل الجغرافي النشط.

الاستعادة الجغرافية

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

النسخ الجغرافي النشط

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

SQL Server على أجهزة Azure الظاهرية

تتوفر مجموعة متنوعة من الخيارات للاسترداد وقابلية الوصول العالية لـ SQL Server 2012 (والأحدث) قيد التشغيل في Azure Virtual Machines. لمزيد من المعلومات، راجع قابلية الوصول العالية والإصلاح بعد الكوارث لـ SQL Server على Azure Virtual Machines.

خدمات النظام الأساسي الأخرى لـ Azure

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

إشعار

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

ناقل الخدمة

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

App Service

لترحيل تطبيق Azure App Service، مثل تطبيقات الويب أو تطبيقات الأجهزة المحمولة إلى منطقة Azure ثانوية، يجب أن يكون لديك نسخة احتياطية من موقع الويب متاح للتوزيع. إذا لم يتضمن الانقطاع مركز بيانات Azure بأكمله، فقد يكون من الممكن استخدام FTP لتنزيل نسخة احتياطية حديثة من محتوى الموقع. ثم قم بإنشاء تطبيق جديد في المنطقة البديلة، ما لم تكن قد قمت بذلك مسبقا لحجز السعة. توزيع الموقع إلى المنطقة الجديدة، وإجراء أي تغييرات التكوين الضرورية. قد تتضمن هذه التغييرات سلاسل اتصال قاعدة البيانات أو إعدادات أخرى خاصة بالمنطقة. إذا لزم الأمر، أضف شهادة SSL للموقع وغير سجل DNS CNAME بحيث يشير اسم المجال المخصص إلى عنوان URL لتطبيق ويب Azure الذي تم إعادة توزيعه.

HDInsight

يتم تخزين البيانات المقترنة بـ HDInsight بشكل افتراضي في Azure Blob Storage. يتطلب HDInsight أن تكون وظائف MapReduce لمعالجة نظام مجموعة Hadoop مجمعة في نفس المنطقة مثل حساب التخزين الذي يحتوي على البيانات التي يتم تحليلها. شريطة استخدام ميزة النسخ المتماثل الجغرافي المتوفرة لـ Azure Storage، يمكنك الوصول إلى بياناتك في المنطقة الثانوية حيث تم نسخ البيانات نسخا متماثلا إذا لم تعد المنطقة الأساسية متوفرة لسبب ما. يمكنك إنشاء مجموعة Hadoop جديدة في المنطقة حيث تم نسخ البيانات ومتابعة معالجتها.

تقديم تقارير SQL

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

Media Services

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

الشبكة الظاهرية

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

قوائم التحقق من الإصلاح بعد الكوارث

قائمة اختيار الخدمات السحابية

1. راجع قسم الخدمات السحابية في هذا المستند.
2. إنشاء استراتيجية الإصلاح بعد الكوارث عبر المناطق.
3. فهم المفاضلات في القدرة على الحجز في المناطق البديلة.
4. استخدم أدوات توجيه نسبة استخدام الشبكة، مثل Azure Traffic Manager.

قائمة اختيار الأجهزة الظاهرية

1. راجع قسم الأجهزة الظاهرية في هذا المستند.
2. استخدم Azure Backup لإنشاء نسخ احتياطية متسقة للتطبيق عبر المناطق.

قائمة اختيار التخزين

1. راجع قسم التخزين في هذا المستند.
2. لا تقم بتعطيل النسخ المتماثل الجغرافي لموارد التخزين.
3. فهم المنطقة البديلة للنسخ المتماثل الجغرافي في حالة حدوث تجاوز الفشل.
4. إنشاء استراتيجيات النسخ الاحتياطي المخصصة لاستراتيجيات تجاوز الفشل التي يتحكم فيها المستخدم.

قائمة اختيار قاعدة بيانات SQL

1. راجع قسم قاعدة بيانات SQL في هذا المستند.
2. استخدم الاستعادة الجغرافية أو النسخ المتماثل الجغرافي حسب الاقتضاء.

قائمة مراجعة SQL Server على الأجهزة الظاهرية (VMs)

1. راجع قسم SQL Server على الأجهزة الظاهرية في هذا المستند.
2. استخدم مجموعات قابلية وصول عالية التوفر AlwaysOn عبر المناطق أو النسخ المتطابق لقاعدة البيانات.
3. بدلا من ذلك، استخدم النسخ الاحتياطي والاستعادة إلى تخزين الكائن الثنائي كبير الحجم.

قائمة اختيار ناقل خدمة Azure

1. راجع قسم ناقل خدمة Microsoft Azure في هذا المستند.
2. تكوين مساحة اسم ناقل خدمة Microsoft Azure في منطقة بديلة.
3. ضع في اعتبارك استراتيجيات النسخ المتماثل المخصصة للرسائل عبر المناطق.

قائمة اختيار App Service

1. راجع قسم App Service في هذا المستند.
2. الاحتفاظ بالنسخ الاحتياطية للموقع خارج المنطقة الأساسية.
3. إذا كان الانقطاع جزئيا، فحاول استرداد الموقع الحالي باستخدام FTP.
4. خطط لتوزيع الموقع إلى موقع جديد أو موجود في منطقة بديلة.
5. تخطيط تغييرات التكوين لكل من التطبيق وسجلات DNS CNAME.

قائمة اختيار HDInsight

1. راجع قسم HDInsight في هذا المستند.
2. إنشاء مجموعة Hadoop جديدة في المنطقة مع البيانات المنسوخة نسخا متماثلا.

قائمة التحقق SQL Reporting

1. راجع قسم SQL Reporting في هذا المستند.
2. الاحتفاظ بمثيل تقارير SQL بديل في منطقة مختلفة.
3. احتفظ بخطة منفصلة لنسخ الهدف إلى تلك المنطقة.

قائمة اختيار خدمات الوسائط

1. راجع قسم خدمات الوسائط في هذا المستند.
2. إنشاء حساب خدمات الوسائط في منطقة بديلة.
3. ترميز المحتوى نفسه في كلتا المنطقتين لدعم تجاوز فشل البث.
4. إرسال مهام الترميز إلى منطقة بديلة في حالة حدوث انقطاع في الخدمة.

قائمة اختيار الشبكة الظاهرية

1. راجع قسم الشبكة الظاهرية في هذا المستند.
2. استخدم إعدادات الشبكة الظاهرية المصدرة لإعادة إنشائها في منطقة أخرى.