اختبار تجاوز الفشل وتشغيله

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

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

لتشغيل اختبار تجاوز الفشل في المدخل، حددوا العنصر المحمي، وانقروا فوق Test Failover، واختاروا نقطة استرداد (أحدث نقطة متسقة مع الأعطال، أو أحدث نقطة متسقة مع التطبيقات، أو نقطة زمنية محددة)، ثم حددوا شبكة افتراضية مستهدفة (عادةً شبكة VNet اختبارية معزولة مخصصة). يشغّل ASR الجهاز الافتراضي في المنطقة المستهدفة باستخدام الأقراص المنسوخة. يظهر الجهاز الافتراضي الاختباري بجوار النسخة المتماثلة، لكنه مستقل تمامًا؛ فلا يتأثر الإنتاج. بعد الاختبار، انقروا فوق Cleanup test failover لحذف الأجهزة الافتراضية الاختبارية.

أثناء تجاوز الفشل، تختارون نقطة استرداد من فترة الاحتفاظ في ASR. وتتوفر الخيارات التالية: Latest (lowest RPO) — أحدث نقطة استرداد متسقة مع الأعطال، وهي الأحدث وتقلل فقدان البيانات. Latest processed — أحدث نقطة تمت معالجتها، وقد تتأخر بضع دقائق. Latest app-consistent — أحدث نقطة استرداد متسقة مع التطبيقات، وقد تكون أقدم، لكنها تضمن استرداد التطبيقات بصورة سليمة. Custom — نقطة استرداد أقدم محددة لاسترداد النظام إلى حالة سليمة معروفة قبل وقوع حادث.

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

يوفر اختبار تجاوز الفشل فرصة لقياس RTO (Recovery Time Objective) الفعلي لديكم. ابدأوا تشغيل مؤقت عند بدء تجاوز الفشل، وأوقفوه عندما يصبح التطبيق فعالًا بالكامل ومتاحًا للمستخدمين. يكتمل تجاوز الفشل المعتاد من Azure إلى Azure خلال 15–30 دقيقة لجهاز افتراضي واحد، لكن التطبيقات متعددة الطبقات ذات التبعيات قد تستغرق وقتًا أطول. وثّقوا أي خطوات تضيف وقتًا غير متوقع، مثل انتشار DNS وتهيئة التطبيق، وعالجوها قبل الاختبار التالي.

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

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

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

يجب أن ينتج عن كل اختبار للتعافي من الكوارث تقرير اختبار التعافي من الكوارث يوثق تاريخ الاختبار والسيناريو الذي تم اختباره، ونقاط الاسترداد المستخدمة، وقيمتي RTO وRPO المحققتين، والمشكلات المكتشفة، وإجراءات المعالجة المتخذة. وتفي هذه الوثائق بمتطلبات المدققين للأطر، مثل ISO 27001 وSOC 2، التي تفرض إجراء اختبارات منتظمة للتعافي من الكوارث. خزّنوا تقارير الاختبارات في موقع آمن يمكن لفرق تكنولوجيا المعلومات واستمرارية الأعمال الوصول إليه.

يُحتسب سعر Azure Site Recovery لكل مثيل محمي شهريًا؛ وتشمل الرسوم خدمة النسخ المتماثل والتنسيق معًا. كما تُفرض رسوم على مساحة التخزين التي تشغلها الأقراص المُدارة المنسوخة في المنطقة المستهدفة وحساب تخزين ذاكرة التخزين المؤقت أثناء النسخ المتماثل. ويُحتسب نقل البيانات الصادر بين مناطق Azure لحركة بيانات النسخ المتماثل وفق معدلات الخروج العادية، بخلاف Azure Backup حيث يكون الخروج بين المناطق المقترنة مجانيًا. وبالنسبة إلى النسخ المتماثل من البيئة المحلية إلى Azure، يمكن لتراخيص Windows Server الخاصة بأجهزة Azure الافتراضية استخدام Azure Hybrid Benefit لتقليل التكاليف.

اختبروا مدى فهمكم لمفاهيم Microsoft Azure Fundamentals (AZ-900) الواردة في هذا الدرس.

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