مشاركة عبر

استمرارية الأعمال والتعافي من الكوارث للتحليات على نطاق السحابة

  • مقالة

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

يمكن أحيانا دمج قابلية الوصول العالية والتعافي من الكوارث. يحتوي المجالان على استراتيجيات مختلفة قليلا، خاصة عندما يتعلق الأمر بالبيانات. لمعرفة المزيد، راجع Microsoft Azure Well-Architected Frameworkومبادئ الموثوقية الخاصة به.

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

استراتيجيات النسخ الاحتياطي

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

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

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

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

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

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

الإصلاح بعد كارثة وقابلية وصول عالية لخدمات Azure

تناقش الأقسام التالية خدمات Azure المختلفة.

Azure Cosmos DB

للحصول على نظرة عامة حول قابلية الوصول العالية مع Azure Cosmos DB، راجع كيف يوفر Azure Cosmos DB قابلية وصول عالية.

Azure Data Factory

من المحتمل أن يكون لتكامل البيانات ومنتج البيانات مستودعات Azure DevOps مرتبطة ب Azure Data Factory. يمكنك نشر البنية الأساسية لبرنامج ربط العمليات التجارية إلى Data Factory آخر بأقل وقت تعطل. لاستخدام برنامج التحكم في إصدار التعليمات البرمجية بصرف النظر عن GitHub وAzure DevOps repo، استخدم Azure Data Factory SDK لتأليف المسارات وعناصر Azure Data Factory الأخرى.

Azure Data Lake

يدعم Azure Data Lake Storage Gen2 بالفعل النسخ المتماثل 3x للحماية من فشل الأجهزة المترجمة. تعمل خيارات النسخ المتماثل الأخرى، مثل التخزين المتكرر للمنطقة (ZRS) أو التخزين المتكرر للمنطقة الجغرافية (GZRS)، على تحسين قابلية الوصول العالية. يعمل التخزين المتكرر جغرافيا (GRS) والتخزين المتكرر جغرافيا (RA-GRS) للوصول إلى القراءة على تحسين التعافي من الكوارث. للحصول على قابلية وصول عالية، إذا كان هناك انقطاع في الخدمة، يحتاج حمل العمل إلى الوصول إلى أحدث البيانات في أسرع وقت ممكن. يمكن لعبء العمل التبديل إلى مثيل منسوخ نسخا متماثلا محليا أو إلى منطقة جديدة.

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

يجب أن يكون لكل منطقة هبوط بيانات هدف نقطة استرداد لمنتجات البيانات الخاصة بها. يجب أن يكون لكل منطقة من مناطق هبوط البيانات استراتيجية نسخ متماثل محددة لحالات استخدامها.

ملاحظة

لم يتم دعم تجاوز فشل الحساب المدار من قبل العميل بعد في الحسابات التي تحتوي على مساحة أسماء هرمية (Azure Data Lake Storage Gen2).

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

لمزيدٍ من المعلومات، راجع «الإصلاح بعد كارثة وتجاوز الفشل في حساب تخزين».

Azure Databricks

للحصول على نظرة عامة على بنية الإصلاح بعد كارثة لمجموعات Azure Databricks، راجع الإصلاح بعد كارثة الإقليمية لمجموعات Azure Databricks.

التعلم الآلي من Azure

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

Azure Key Vault

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

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

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

للحصول على نظرة عامة حول استمرارية الأعمال باستخدام قاعدة بيانات Azure SQL، راجع نظرة عامة على استمرارية الأعمال باستخدام قاعدة بيانات Azure SQL.

Azure Synapse Analytics

للحصول على نظرة عامة حول استمرارية الأعمال باستخدام Azure Synapse Analytics، راجع قابلية الوصول العالية ل Azure Synapse Analytics.

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