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

دروس مستفادة

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

الاعتبارات

مضادات التناثر

• نسخ/لصق سلسلة هذه المقالة تهدف سلسلة المقالات هذه إلى توفير إرشادات للعملاء الذين يبحثون عن المستوى التالي من التفاصيل لعملية الإصلاح بعد الكوارث الخاصة ب 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 - ملخص