الإتاحة العالية وتحمّل الأخطاء

عطل الساعة 3 فجراً

يشغّل تطبيق حجوزات فندقية كل خوادمه على نسخة افتراضية واحدة. في الساعة 3 فجراً، يتعطّل الخادم المادي الذي تعمل عليه تلك النسخة، بصمت وبالكامل، كما يفعل العتاد عاجلاً أم آجلاً بصرف النظر عن اسم الشركة على الرف. تختفي النسخة، ويختفي معها الحجز، حتى ينتبه أحد المهندسين ويطلق نسخة بديلة. تلك النسخة الوحيدة كانت نقطة فشل وحيدة: مورداً واحداً كافياً تعطّله وحده لإسقاط النظام بأكمله معه. إزالة نقاط فشل وحيدة كهذه هي موضوع بقية هذا الدرس، ويتضح أن لها مستويين مختلفين من "الإزالة"، لا مستوى واحداً.

تذكير: الأدوات التي تملكها بالفعل

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

الإتاحة العالية: البقاء متاحاً عبر انقطاع قصير

توضّح نشرات Amazon RDS من وضع Multi-AZ هذا النمط بجلاء. تتولى نسخة أساسية كل عمليات القراءة والكتابة، بينما تبقى نسخة احتياطية في منطقة إتاحة مختلفة متزامنة في الخلفية، جاهزة لكنها خاملة. إن تعطّلت النسخة الأساسية، تكتشف RDS العطل، وترفع النسخة الاحتياطية، وتعيد توجيه سجل DNS الخاص بقاعدة البيانات إليها، عادة خلال 60 إلى 120 ثانية، بلا فقدان أي بيانات. لكن خلال تلك الثواني الـ60 إلى 120، تنقطع اتصالات قاعدة البيانات أو تنتظر في طابور.

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

تحمّل الأخطاء: البقاء متاحاً بلا أي انقطاع

عد الآن إلى تطبيق الحجوزات، لكن بتصميم مختلف. لنفترض أنه يحتاج 6 نسخ عاملة لتغطية حمله المعتاد. موزّعة على منطقتي إتاحة، 3 نسخ في كل منطقة، هذا إعداد عالي الإتاحة فعلاً: تفقد منطقة واحدة، وتبقى النسخ الثلاث الناجية تشغّل الحجز، لكن بنصف الطاقة فقط حتى تُطلق نسخ جديدة خلفها. وزّع الإعداد نفسه على 3 مناطق إتاحة بدلاً من ذلك، 3 نسخ في كل منطقة، 9 نسخ إجمالاً، وفقدان أي منطقة واحدة يترك 6 نسخ عاملة، بالضبط الطاقة التي يحتاجها الحجز. لا يتغيّر شيء من تجربة المستخدم. هذا هو تحمّل الأخطاء: لم يكن النظام يوماً ناقص الطاقة فعلياً، لأن النسخ "الاحتياطية" كانت تعمل بالفعل وتخدم الحركة قبل وقوع العطل.

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

أين يجب أن يصل التكرار: كل طبقة، لا الحوسبة فقط

النظام موثوق بقدر أقل طبقاته تكراراً. توزيع طبقة الحوسبة عبر مناطق الإتاحة لا يفيد شيئاً إن بقيت قاعدة البيانات، أو موازن الحمل، أو DNS نقطة فشل وحيدة تحته.

يبني مزودو السحابة موازنات الحمل المُدارة وفحوصات سلامة DNS المُدارة لتكون متكررة أصلاً، لذا تبقى الطبقتان اللتان يحتاج الفريق فعلياً لتصميمهما بنفسه عادة هما الحوسبة وقاعدة البيانات.

نشط-نشط مقابل نشط-خامل

لنمطي التكرار أعلاه اسمان، ويظهر الفرق بينهما مجدداً لاحقاً في هذا الموضوع. النشط-النشط يعني أن كل نسخة تخدم الحركة في اللحظة نفسها، تماماً كما يوزّع موازن الحمل الطلبات على كل نسخ الحوسبة السليمة الآن، لا فقط عند حدوث عطل. النشط-الخامل يعني أن جانباً واحداً يؤدي العمل بينما يبقى الآخر متزامناً وخاملاً، جاهزاً لتولّي المهمة، تماماً كما تتصرف نسخة RDS Multi-AZ الاحتياطية.

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

الالتباس: "متعدد مناطق الإتاحة" لا يعني تلقائياً "متحمّل الأخطاء"

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

إشارات الامتحان: قراءة سؤال الإتاحة العالية مقابل تحمّل الأخطاء

الفخ الذي عليك الحذر منه: سيناريو يصف إعداداً متيناً عبر عدة مناطق إتاحة ثم يسأل إن كان متحمّلاً للأخطاء. تحقق من حساب الطاقة، لا من عدد المناطق فقط، قبل الإجابة.

إلى أين يقودك هذا

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