التعافي من الأعطال والكوارث

التعافي من الأعطال والكوارث

التكرار (الذي تناولناه في الدرس السابق) يجيب على السؤال: "هل لدينا طاقة احتياطية؟" أما التبديل عند الفشل فيجيب على التساؤل التالي: "كيف ننتقل فعلياً إلى تلك الطاقة الاحتياطية حين يتعطل شيء؟" والتعافي من الكوارث (DR) يجيب على السؤال الأصعب: "كيف ننجو من فشل كامل لموقع أو منطقة أو مركز بيانات ونعود بأدنى قدر من فقدان البيانات؟" هذه المفاهيم الثلاثة مترابطة ارتباطاً وثيقاً، وإتقانها هو الفارق بين نظام يدّعي توافراً بنسبة 99.9% ونظام يُحقق ذلك فعلاً.

التبديل النشط-السلبي مقابل التبديل النشط-النشط

ثمة طريقتان أساسيتان لترتيب المكونات المتكررة:

النشط-السلبي (الأساسي-الاحتياطي): تتعامل عقدة واحدة مع كل حركة المرور في أي وقت (العقدة النشطة). تجلس عقدة واحدة أو أكثر في وضع الخمول، وتستقبل باستمرار الحالة المنسوخة من العقدة النشطة، لكنها لا تخدم أي طلبات (عقد الاستعداد السلبي). عند فشل العقدة النشطة، تُرفَّع أفضل عقدة احتياطية لتصبح العقدة النشطة الجديدة، ويُعاد توجيه حركة المرور إليها.

النشط-النشط: تتعامل جميع العقد مع حركة المرور الحية في آنٍ واحد. تتوزع الطاقة والحمل والحالة (في بعض الإعدادات) بين العقد. عند فشل عقدة ما، تستوعب البقية حركة مرورها — دون الحاجة إلى خطوة "ترقية" صريحة لأن كل عقدة نشطة أصلاً.

المقايضات: الاختيار بين النموذجين

لا يوجد نموذج أفضل عالمياً. يعتمد الاختيار الصحيح على RTO وRPO وطبيعة بياناتك:

• النشط-السلبي أسهل في الاستيعاب — تذهب الكتابات إلى عقدة واحدة بالضبط، فلا خطر من تعارض الكتابات. العيب هو أن العقدة الاحتياطية تجلس خاملة مضيعةً للأجهزة، وهناك نافذة تبديل قابلة للقياس (عادةً 10 ثوانٍ إلى 3 دقائق تبعاً لسرعة الاكتشاف والترقية). MySQL Group Replication في وضع الأساسي الواحد، وPostgreSQL مع Patroni، ومعظم إعدادات قواعد البيانات العلائقية تعتمد هذا النموذج افتراضياً.
• النشط-النشط يُلغي تأخير الترقية ويُضاعف إنتاجية الكتابة. لكن إذا قبلت عقدتان كتابات في آنٍ واحد، فأنت بحاجة إلى استراتيجية لحل التعارضات — إما تجنّب التعارضات بتوجيه كتابات المفتاح ذاته إلى العقدة ذاتها (التجزئة المتسقة)، أو قبول دلالة "آخر كتابة تفوز"، أو استخدام بروتوكول توافق (Raft أو Paxos). Cassandra وDynamoDB وCockroachDB مُصمَّمة للكتابات متعددة المناطق نشط-نشط.

أهداف التعافي: RTO وRPO

مقياسان يُحددان معنى "التعافي من الكوارث" لعملك:

هدف وقت التعافي (RTO) — أقصى مدة مقبولة للانقطاع. كم من الوقت يمكن أن يكون النظام غير متاح قبل أن يتضرر العمل ضرراً ملموساً؟ قد يُحدد معالج الدفع RTO بـ30 ثانية. لوحة تحليلات داخلية قد تتحمل 4 ساعات.

هدف نقطة التعافي (RPO) — أقصى قدر مقبول من فقدان البيانات، مقاساً بالزمن. كم من العمل يمكننا تحمّل فقدانه؟ RPO = 0 يعني فقدان صفري للبيانات (يجب أن تكون كل كتابة مُؤكَّدة قابلة للاسترداد). RPO = ساعة يعني تحمّل فقدان ما يصل إلى ساعة من المعاملات.

RTO وRPO قرارات تجارية أولاً، وتقنية ثانياً. يجب على الأعمال أن تُقرر ما يمكنها تحمّله مالياً وسمعياً من فقدان البيانات والتوقف. ثم يختار الفريق الهندسي وضع النسخ المتماثل وتكرار النسخ الاحتياطية وبنية الاستعداد التي تُحقق تلك الأهداف.

أهداف نموذجية حسب نوع العمل (إرشادات تقريبية):

• المعاملات المالية / المدفوعات: RTO أقل من دقيقة، RPO = 0 (فقدان صفري للبيانات، النسخ المتزامن إلزامي)
• إتمام طلبات التجارة الإلكترونية: RTO أقل من 5 دقائق، RPO أقل من 30 ثانية
• تطبيق SaaS: RTO أقل من 30 دقيقة، RPO أقل من 5 دقائق
• الأدوات الداخلية: RTO أقل من 4 ساعات، RPO أقل من ساعة

أنماط نشر التعافي من الكوارث

ثلاثة أنماط نشر تتوافق تقريباً مع تصاعد التكلفة وانخفاض RTO/RPO:

1. النسخ الاحتياطي والاستعادة — لقطات دورية (مثلاً ليلية) تُكتب في موقع منفصل. RTO من ساعات إلى أيام، RPO مساوٍ لفترة اللقطات. الأرخص؛ مناسب فقط للبيانات غير الحرجة.
2. الضوء الخافت (Pilot Light) — تعمل نسخة ضئيلة من النظام (نسخة مطابقة من قاعدة البيانات، الإعداد) باستمرار في موقع التعافي من الكوارث، لكن خوادم التطبيقات متوقفة. عند وقوع الكارثة، تُشغَّل خوادم التطبيقات ويُعاد توجيه DNS. RTO من 15 إلى 60 دقيقة، RPO قريب من الصفر لقاعدة البيانات (نسخ متماثل مستمر).
3. الاستعداد الدافئ / المواقع المتعددة النشطة — تعمل نسخة مصغرة لكنها مُشغَّلة بالكامل في منطقة ثانية في جميع الأوقات. RTO من ثوانٍ إلى دقائق. النهج النشط-النشط متعدد المناطق هو أقصى نقاط هذا الطيف: طاقة كاملة في كل منطقة، RTO قريب من الصفر، لكن بأعلى تكلفة وتعقيد تشغيلي.

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

يعدّ التبديل في قواعد البيانات الجزء الأصعب لأن الكتابات يجب ألا تُفقَد أو تُكرَّر. السؤال الجوهري أثناء الترقية هو: كم كانت النسخة متأخرة وقت وقوع الفشل؟ هذه الفجوة هي تأخر النسخ المتماثل، وتُحدد مباشرةً ما إذا كان RPO الفعلي قد حقق هدفك.

للحفاظ على تأخر النسخ المتماثل قريباً من الصفر لمتطلبات RPO = 0، استخدم النسخ المتماثل المتزامن: ينتظر الأساسي حتى تُقرّ نسخة واحدة على الأقل بالكتابة قبل تأكيدها للعميل. يُضيف هذا كموناً (~1–5 مللي ثانية لرحلات ذهاب وإياب عبر مراكز البيانات) لكنه يضمن فقداناً صفرياً للبيانات عند التبديل. PostgreSQL مع synchronous_commit = on، وMySQL Group Replication في وضع الأساسي الواحد، والنسخ المتزامن السداسي في AWS Aurora، كلها تُنفّذ هذا النمط.

لسيناريوهات التوافر العالي حيث يمكن تحمّل RPO صغير مقابل كمون كتابة أقل، يُستخدم النسخ المتماثل غير المتزامن — يؤكد الأساسي للعميل فوراً، وتلحق النسخة في الخلفية. المقايضة صريحة: إذا تعطّل الأساسي قبل اللحاق بالنسخة، فتلك الكتابات الأخيرة مفقودة.

ربط كل شيء معاً

تجمع استراتيجية التعافي من الكوارث المُصمَّمة جيداً عدة عناصر: هدف RTO وRPO واضح متفق عليه مع الأعمال، وبنية طوبولوجية (نشط-سلبي أو نشط-نشط) تتناسب مع متطلبات اتساق البيانات، ووضع نسخ متماثل (متزامن أو غير متزامن) يتوافق مع RPO، وتدريبات منتظمة على التعافي من الكوارث للتحقق من أن التبديل يعمل فعلاً ضمن الأهداف المُعلنة، ومراقبة تأخر النسخ المتماثل كمؤشر قيادي لصحة RPO. الهدف ليس منع كل فشل — بل ضمان أن لكل فشل تأثيراً معروفاً ومُختبَراً ومحدوداً.