DR ل Azure Data Platform - التوصيات

دروس مستفادة

1. تأكد من أن جميع الأطراف المعنية تفهم الفرق بين قابلية الوصول العالية (HA) والتعافي من الكوارث (DR): يتمثل الخطأ الشائع في الخلط بين المفهومين واختلاف الحلول المرتبطة بهما
2. مناقشة مع أصحاب المصلحة في الأعمال حول توقعاتهم فيما يتعلق بالجوانب التالية لتحديد أهداف نقطة الاسترداد (RPO) وأهداف وقت الاسترداد (RTO):
   1. كم من وقت التعطل يمكنهم تحمله، مع الأخذ في الاعتبار أنه عادة، كلما كان الاسترداد أسرع، زادت التكلفة
   2. نوع الحوادث التي يريدون الحماية منها، مع الإشارة إلى الاحتمال ذي الصلة لمثل هذا الحدث. على سبيل المثال، احتمال تعطل الخادم أعلى من الكارثة الطبيعية التي تؤثر على جميع مراكز البيانات عبر المنطقة
   3. ما تأثير النظام غير المتوفر على أعمالهم؟
   4. ميزانية OPEX للحل للمضي قدما
3. ضع في اعتبارك خيارات الخدمة المتدهورة التي يمكن للمستخدمين النهائيين قبولها. وقد تشمل هذه الإجراءات ما يلي:
   1. لا يزال لديه حق الوصول إلى لوحات معلومات المرئيات حتى بدون أحدث البيانات، أي إذا لم تعمل مسارات الاستيعاب، فلا يزال بإمكان المستخدمين النهائيين الوصول إلى بياناتهم
   2. الحصول على حق الوصول للقراءة ولكن بدون وصول للكتابة
4. يمكن لمقاييس RTO وRPO المستهدفة تحديد استراتيجية التعافي من الكوارث التي تختار تنفيذها:
   1. نشط/نشط
   2. نشط/سلبي
   3. نشط/إعادة توزيع عند حدوث كارثة
   4. الاعتماد على اتفاقية مستوى الخدمة من Microsoft
5. تأكد من فهم جميع المكونات التي قد تؤثر على توفر الأنظمة الخاصة بك، مثل:
   1. إدارة الهوية
   2. مخطط الشبكات
   3. إدارة البيانات السرية/المفاتيح
   4. مصادر البيانات
   5. مجدول الأتمتة/الوظيفة
   6. مستودع المصدر وتدفقات التوزيع (GitHub وAzure DevOps)
6. الكشف المبكر عن الانقطاعات هو أيضا طريقة لتقليل قيم RTO وRPO بشكل كبير. فيما يلي بعض الجوانب التي يجب تغطيتها:
   1. حدد ما هو الانقطاع وكيف يتم تعيينه إلى تعريف Microsoft للانقطاع. يتوفر تعريف Microsoft في صفحة اتفاقية مستوى خدمة Azure على مستوى المنتج أو الخدمة.
   2. سيساعد نظام مراقبة وتنبيه فعال مع فرق مسؤولة لمراجعة تلك المقاييس والتنبيهات في الوقت المناسب على تحقيق الهدف
7. تعني اتفاقيات مستوى الخدمة المركبة أنه كلما زاد عدد المكونات الموجودة لديك في البنية الخاصة بك، زادت احتمالية الفشل. يمكنك استخدام اتفاقية مستوى الخدمة المركبة لتحديد فرص انقطاع المكون.
8. فيما يتعلق بتصميم الاشتراك، يمكن تخزين البنية الأساسية الإضافية للتعافي من الكوارث في الاشتراك الأصلي. عادة ما تحتوي خدمات PaaS مثل ADLS Gen2 أو Azure Data Factory على ميزات أصلية تسمح بالفشل في المثيلات الثانوية في مناطق أخرى مع البقاء مضمنة في الاشتراك الأصلي. قد يرغب بعض العملاء في التفكير في وجود مجموعة موارد مخصصة للموارد المستخدمة فقط في سيناريوهات الإصلاح بعد الكوارث لأغراض التكلفة
   1. تجدر الإشارة إلى أن حدود الاشتراك قد تعمل كقيد لهذا النهج
   2. قد تتضمن القيود الأخرى تعقيد التصميم وعناصر التحكم في الإدارة لضمان عدم استخدام مجموعات موارد DR لسير عمل إدارة الرسائل
9. تصميم سير عمل الإصلاح بعد الكارثة استنادا إلى أهمية الحل وتبعياته. على سبيل المثال، لا تحاول إعادة إنشاء مثيل Azure Analysis Services قبل أن يكون مستودع البيانات قيد التشغيل، لأنه سيؤدي إلى حدوث خطأ. اترك مختبرات التطوير لاحقا في العملية، واسترداد حلول المؤسسة الأساسية أولا
10. حاول تحديد مهام الاسترداد التي يمكن موازاتها عبر الحلول، ما يقلل من إجمالي RTO
11. إذا تم استخدام Azure Data Factory ضمن حل، فلا تنس تضمين أوقات تشغيل التكامل المستضاف ذاتيا في النطاق. يعد Azure Site Recovery مثاليا لتلك الأجهزة
12. يجب أتمتة العمليات اليدوية قدر الإمكان لتجنب الأخطاء البشرية، خاصة عندما تكون تحت الضغط. يوصى ب:
    1. اعتماد توفير الموارد من خلال Bicep أو قوالب ARM أو البرامج النصية PowerShell
    2. اعتماد تعيين إصدار التعليمات البرمجية المصدر وتكوين الموارد
    3. استخدام مسارات إصدار CI/CD بدلا من عمليات النقر
13. نظرا لأن لديك خطة لتجاوز الفشل، يجب مراعاة الإجراءات للرجوع إلى المثيلات الأساسية
14. تحديد مؤشرات/مقاييس واضحة للتحقق من نجاح تجاوز الفشل وتشغيل الحلول أو أن الوضع عاد إلى طبيعته (يعرف أيضا بالوظيفية الأساسية)
15. حدد ما إذا كان يجب أن تظل اتفاقيات مستوى الخدمة كما هي بعد تجاوز الفشل أو إذا كنت تسمح بالخدمة المتدهورة
    1. سيعتمد هذا القرار بشكل كبير على عملية خدمة الأعمال المدعومة. على سبيل المثال، سيبدو تجاوز الفشل لنظام حجز الغرف مختلفا كثيرا عن النظام التشغيلي الأساسي
16. يجب أن يستند تعريف RTO/RPO إلى سيناريوهات/حلول مستخدم محددة بدلا من مستوى البنية الأساسية. سوف يمنحك المزيد من التفاصيل حول العمليات والمكونات التي يجب استردادها أولا إذا كان هناك انقطاع أو كارثة
17. تأكد من تضمين عمليات التحقق من السعة في المنطقة المستهدفة قبل المضي قدما في تجاوز الفشل: إذا كانت هناك كارثة كبرى، فضع في اعتبارك أن العديد من العملاء سيحاولون تجاوز الفشل إلى نفس المنطقة المقترنة في نفس الوقت، ما قد يتسبب في تأخيرات أو تنازع في توفير الموارد
    1. إذا كانت هذه المخاطر غير مقبولة، فيجب مراعاة استراتيجية Active/Active أو Active/Passive DR
18. يجب إنشاء خطة التعافي من الكوارث والحفاظ عليها لتوثيق عملية الاسترداد ومالكي الإجراءات. أيضا، ضع في اعتبارك أن الأشخاص قد يكونوا في إجازة، لذا تأكد من تضمين جهات الاتصال الثانوية
19. يجب إجراء تدريبات منتظمة للتعافي من الكوارث للتحقق من صحة سير عمل خطة الإصلاح بعد الكوارث، وأنه يلبي RTO/RPO المطلوب، وتدريب الفرق المسؤولة
    1. يجب أيضا اختبار النسخ الاحتياطية للبيانات والتكوين بانتظام للتأكد من أنها "مناسبة للغرض" لدعم أي أنشطة استرداد
20. سيمكن التعاون المبكر مع الفرق المسؤولة عن الشبكات والهوية وتوفير الموارد من الاتفاق على الحل الأمثل فيما يتعلق بما يلي:
    1. كيفية إعادة توجيه المستخدمين وحركة المرور من موقعك الأساسي إلى موقعك الثانوي. يمكن تقييم مفاهيم مثل إعادة توجيه DNS أو استخدام أدوات معينة مثل Azure Traffic Manager
    2. كيفية توفير الوصول والحقوق إلى الموقع الثانوي في الوقت المناسب وبطريقة آمنة
21. أثناء وقوع كارثة، يكون التواصل الفعال بين العديد من الأطراف المعنية أساسيا للتنفيذ الفعال والسريع للخطة:
    1. صانعي
    2. فريق الاستجابة للحوادث
    3. الجمهور الداخلي المتأثر
    4. الفرق الخارجية
22. سيضمن تنسيق الموارد المختلفة في الوقت المناسب الكفاءة في تنفيذ خطة التعافي من الكوارث

الاعتبارات

الأنماط المضادة

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

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

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

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

• الاعتماد على Microsoft للقيام بكل ذلك داخل خدمات Microsoft Azure، هناك تقسيم واضح للمسؤولية، يستند إلى مستوى الخدمة السحابية المستخدم: حتى إذا تم استخدام مكدس SaaS كامل، سيظل العميل يحتفظ بالمسؤولية لضمان صحة/تحديث الحسابات والهويات والبيانات، إلى جانب الأجهزة المستخدمة للتفاعل مع خدمات Azure.

نطاق الحدث واستراتيجيته

نطاق حدث الكوارث

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

خيارات استراتيجية الكوارث

هناك أربعة خيارات عالية المستوى لاستراتيجية التعافي من الكوارث:

• انتظر Microsoft - كما يوحي الاسم، الحل غير متصل حتى الاسترداد الكامل للخدمات في المنطقة المتأثرة بواسطة Microsoft. بمجرد الاسترداد، يتم التحقق من صحة الحل من قبل العميل ثم إحضاره محدثا لاسترداد الخدمة
• إعادة النشر في حالات الكوارث - يتم إعادة نشر الحل يدويا في منطقة متاحة من البداية، حدث ما بعد الكارثة
• Warm Spare (Active/Passive) - يتم إنشاء حل ثانوي مستضاف في منطقة بديلة، ويتم نشر المكونات لضمان الحد الأدنى من السعة؛ ومع ذلك، لا تتلقى المكونات حركة مرور الإنتاج. قد تكون الخدمات الثانوية في المنطقة البديلة "متوقفة عن التشغيل" أو تعمل على مستوى أداء أقل حتى يحدث وقت حدوث حدث DR
• Hot Spare (نشط/نشط) - تتم استضافة الحل في إعداد نشط/نشط عبر مناطق متعددة. يتلقى الحل الثانوي المستضاف البيانات ويعالجها ويخدمها كجزء من النظام الأكبر

تأثيرات استراتيجية الإصلاح بعد الكوارث

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

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

مفتاح التصنيف

• هدف وقت الاسترداد (RTO) - الوقت المنقضي المتوقع من حدث الكارثة إلى استرداد خدمة النظام الأساسي
• تعقيد التنفيذ - تعقيد المؤسسة لتنفيذ أنشطة الاسترداد
• تعقيد التنفيذ - تعقيد المؤسسة لتنفيذ استراتيجية الإصلاح بعد الكوارث
• التأثير على العملاء - التأثير المباشر على عملاء خدمة النظام الأساسي للبيانات من استراتيجية DR
• تكلفة OPEX فوق السطر - التكلفة الإضافية المتوقعة من تنفيذ هذه الاستراتيجية مثل زيادة الفوترة الشهرية ل Azure للمكونات الإضافية والموارد الإضافية المطلوبة للدعم

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

الآن بعد أن تعرفت على التوصيات المتعلقة بالسيناريو، يمكنك معرفة كيفية نشر هذا السيناريو

الموارد ذات الصلة

• DR ل Azure Data Platform - نظرة عامة
• DR ل Azure Data Platform - البنية
• DR ل Azure Data Platform - تفاصيل السيناريو
• DR ل Azure Data Platform - ملخص