ما المقصود بتجاوز الفشل وإرجاع الموارد؟

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

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

أدوار المثيل النشطة والسلبية

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

يتطلب المكون، أو مجموعة من المكونات التي تم تكوينها لتجاوز الفشل وإرجاع الموارد، مثيلات متعددة. يفترض كل من هذه المثيلات دورا معينا:

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

هناك عدد من الطرق لتكوين المثيلات السلبية. تتضمن كل طريقة مفاضلات بين وقت الاسترداد وعوامل أخرى، مثل التكلفة والتعقيد التشغيلي:

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

Tip

تم إنشاء بعض الحلول لاستخدام نهج نشط-نشط ، ما يعني أن مثيلات متعددة تخدم جميع الطلبات. لا يتطلب النظام النشط-النشط تجاوز الفشل، لأن جميع المثيلات تخدم الطلبات بنشاط في جميع الأوقات.

نطاقات تجاوز الفشل

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

  • تكرار المنطقة عن طريق وضع النسخ والنسخ المتماثلة في مناطق توفر مختلفة داخل منطقة Azure.
  • التكرار الجغرافي باستخدام موازن تحميل عمومي للفشل بين المناطق.

فيما يلي رسم تخطيطي مبسط يوضح البنية العامة في العمليات العادية:

رسم تخطيطي يوضح بنية الحل التي تستخدم نسخا متماثلة متعددة من قاعدة بيانات في مناطق توفر مختلفة، في منطقتين منفصلتين.

قد تؤدي المواقف المختلفة إلى أحداث تجاوز فشل مختلفة في هذا الحل. يتوافق كل من هذه مع نطاق تجاوز الفشل، والذي يمثل دقة المكونات التي تفشل عبر:

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

    رسم تخطيطي يوضح بنية الحل حيث تمت ترقية النسخة المتماثلة السلبية لتكون النسخة المتماثلة النشطة الجديدة.

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

    رسم تخطيطي يوضح بنية الحل حيث لا تتوفر منطقة توفر واحدة.

  • قد يحدث تجاوز فشل المنطقة إذا كانت هناك خسارة كارثية لمنطقة Azure الأساسية بأكملها.

    رسم تخطيطي يوضح بنية الحل حيث لا تتوفر منطقة واحدة.

في حين أن كل نطاق من هذه النطاقات يوفر نوعا من تجاوز الفشل، فقد يكون لها متطلبات وعمليات مميزة لتجاوز الفشل. أيضا، قد تكون Microsoft مسؤولة عن بعض نطاقات تجاوز الفشل، مثل عند استخدام خدمات المنطقة المكررة، بينما قد تكون مسؤولا عن تجاوز الفشل في نطاقات أوسع، مثل الفشل بين المناطق Azure.

تجاوز الفشل وتخطيط استمرارية الأعمال

جزء من تخطيط استمرارية الأعمال هو تصميم استراتيجيات تجاوز الفشل، بما في ذلك النطاقات المختلفة التي يمكنك تجاوز الفشل فيها.

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

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

ضع في اعتبارك أن تضمين إجراءات تجاوز الفشل في تخطيط استمرارية الأعمال يتطلب منك القيام بتصميم واختبار أكثر تفصيلا. لمزيد من المعلومات، راجع ما هي استمرارية الأعمال، وقابلية الوصول العالية، والتعافي من الكوارث؟.

عمليات تجاوز الفشل المخطط لها وغير المخطط لها

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

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

كيفية عمل تجاوز الفشل

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

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

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

  3. حدد مثيلا أساسيا جديدا. يجب أن يصبح أحد المثيلات المتبقية هو الأساسي الجديد.

    في بعض الحالات، قد تكون قد حددت مسبقا المثيل الذي يجب أن يصبح الأساسي الجديد، أو قد يكون لديك مثيل واحد فقط للتبديل إليه.

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

  4. إعادة توجيه الطلبات. قم بتكوين بيئتك بحيث يتم توجيه الطلبات إلى المثيلات السليمة، أو إلى المثيل الأساسي الجديد.

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

نظرا لأن عمليات تجاوز الفشل يمكن أن تتضمن تأخيرات، فمن المهم بالنسبة لك تخطيط إجراءات تجاوز الفشل لتلبية متطلبات التوقف (هدف نقطة الاسترداد أو RTO) وفقدان البيانات (هدف نقطة الاسترداد أو هدف نقطة الاسترداد). لمعرفة المزيد، راجع ما هي استمرارية الأعمال، وقابلية الوصول العالية، والتعافي من الكوارث؟.

إرجاع الموارد

إرجاع الموارد هو عملية إعادة حركة المرور وإعادة توجيهها مرة أخرى إلى المثيل الأساسي الأصلي.

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

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

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

    من الشائع أن تتطلب مشكلات مزامنة البيانات تدخلا يدويا. إذا لم تكن بحاجة إلى البيانات المتعارضة، فقد تختار إعادة تعيين قاعدة البيانات أو حالة أخرى.

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

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

  • وقت تعطل إضافي. يمكن أن يكون وقت التعطل أثناء عملية إرجاع الموارد أطول مما كان عليه أثناء تجاوز الفشل بسبب إعادة التكوين المطلوبة أو العمليات لاستعادة تناسق البيانات.

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

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

    وينبغي إبقاء أصحاب المصلحة التجاريين على علم بالحالة طوال العملية، وينبغي أن يكونوا على دراية تامة بالحاجة إلى إعادة الموارد وعواقب إجراءات إعادة الموارد. قد تتمكن من التفاوض على وقت مناسب لإجراء التغييرات.

تجاوز الفشل وإرجاع الموارد في خدمات Azure

في حين أنه من المهم فهم كيفية عمل تجاوز الفشل بشكل عام، ضع في اعتبارك أن كل خدمة Azure يمكن أن تتعامل مع تجاوز الفشل وإرجاع الموارد بشكل مختلف. للحصول على معلومات حول كيفية عمل خدمات Azure المحددة من منظور الموثوقية، راجع دليل موثوقية كل خدمة.

تتعامل العديد من خدمات Azure مع أنواع معينة من تجاوز الفشل تلقائيا. على سبيل المثال، عند استخدام خدمات Azure التي تم تكوينها لتكون زائدة عن الحاجة للمنطقة، Microsoft تنفيذ تجاوز الفشل تلقائيا بين مناطق التوفر نيابة عنك. لمعرفة المزيد، راجع ما هي مناطق التوفر؟وأدلة موثوقية الخدمة Azure.

إذا كنت تستخدم الأجهزة الظاهرية، استرداد موقع Azure نسخ الأجهزة الظاهرية وأقراصها بين مناطق التوفر أو إلى منطقة Azure أخرى، ويمكن تنفيذ تجاوز الفشل نيابة عنك.

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

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