تصميم تطبيقات HA للتعامل مع استرداد البيانات بعد حدوث خطأ فادح

مكتمل

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

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

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

عند تكوين حساب تخزين لـ GRS أو RA-GRS، يكتب العميل البيانات إلى نقطة النهاية الأساسية أو المنطقة. ثم تُنسخ البيانات تلقائيًا إلى المنطقة الثانوية، كما هو موضح في النسخة التالية:

Diagram of the replication workflow.

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

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

يظهر فشل في المنطقة الأساسية في النسخة التالية:

Diagram of the replication failover process.

هام

يكون تجاوز الفشل تلقائي ويتم التحكم فيه بواسطة Microsoft. لا يكون تجاوز فشل يدوي لحساب تخزين Azure ممكناً في معظم مناطق Azure. ومع ذلك، فقد أتاحت Microsoft ميزةً جديدةً في منطقتي WestUS2 وCentralUS، والتي يمكنك من خلالها تجاوز فشل يدوي لحساب التخزين باستخدام الأمر التالي:

az storage account failover --name "storageaccountname"

الآثار المترتبة على تجاوز الفشل في حساب التخزين

عند حدوث تجاوز فشل لحساب تخزين قد تفقد البيانات. قد لا يتم إجراء نسخ متماثل للبيانات من المنطقة الأساسية الحالية إلى المنطقة الثانوية في وقت تجاوز الفشل. يُمكنك التحقق من خاصية "Last Sync Time" من أجل تحديد احتمالية حدوث فقدان البيانات. لقد استخدمت الأمر للبحث عن هذه القيمة في التمرين السابق لمراجعة حالة النسخ المتماثل لحساب التخزين.

تصميم تطبيق مرن

عند تصميم التطبيق الخاص بك، ضع في الاعتبار العوامل التالية:

  • المرونة: القدرة على الاسترداد عند حدوث فشل والاستمرار في العمل من أجل تجنب وقت التعطل وفقدان البيانات.

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

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

  • التناسق النهائي: يعمل RA-GRS عن طريق إجراء النسخ المتماثل للبيانات من نقطة النهاية الأساسية إلى نقطة النهاية الثانوية. البيانات، التي يتم نسخها بين المناطق، غير متوفرة على الفور في الموقع الثانوي. يعني التناسق النهائي أن جميع المعاملات في المنطقة الأساسية تظهر في النهاية في المنطقة الثانوية. البيانات لم تُفقد، ولكن قد يكون هناك بعض التأخير.

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

    الوقت الحركة النسخ المتماثل وقت آخر وقت مزامنة النتيجة
    T0 الطبيب يضيف سجل المريض أُضيفت المعاملة ولكن لم تُنسخ نسخًا متماثلاً
    T1 يُنسخ السجل نسخًا متماثلاً T1 تحديث حقل "آخر وقت مزامنة"
    T2 استشاري يعمل على تحديث سجل المرضى T1 يُحدَّث السجل في المنطقة الأساسية ولكن لم يتم نسخه نسخًا متماثلاً
    T3 قراءة السجل من المنطقة الثانوية البيانات من المنطقة الثانوية قديمة، لأن التحديثات لم تُنسخ بعد من المنطقة الأساسية
    T4 سجل منسوخ نسخًا متماثلاً T4 ويجري الآن تحديث البيانات في المنطقة الثانوية، يتم تحديث حقل "آخر وقت مزامنة"

أفضل الممارسات للتطبيقات المستندة إلى مجموعة النظراء مع RA-GRS

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

إعادة المحاولة بعد حالات الفشل العابرة

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

معالجة عمليات الكتابة الفاشلة

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

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

يُمكن لأحد التطبيقات التي تستخدم مكتبة العميل لـ Azure Storage تعيين "LocationMode" لطلب قراءة إلى إحدى القيم التالية:

  • "PrimaryOnly": يفشل طلب القراءة إذا كان الموقع الأساسي غير متوفّر. هذا الفشل هو السلوك الافتراضي.
  • PrimaryThenSecondary: جرِّب الموقع الأساسي أولاً ثم جرّب الموقع الثانوي في حال عدم توفّر الموقع الأساسي. فشل إذا كان الموقع الثانوي غير متوفر أيضًا.
  • "SecondaryOnly": جرِّب الموقع الثانوي فقط، وستفشل إذا لم يكن متوفراً.
  • "SecondaryThenPrimary": جرِّب الموقع الثانوي أولاً، ثم جرّب الموقع الأساسي.

معالجة الاتساق في نهاية المطاف

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

استخدم نمط قاطع الدوائر

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

في بعض الحالات، عندما يكون الانقطاع شديدًا، فمن المنطقي للتطبيق أن يتوقف عن إعادة محاولة العملية بدلاً من بدء تجاوز الفشل إلى موقع ثانوي.

لمنع تطبيق من إعادة محاولة العمليات التي فشلت، يمكنك تطبيق نمط قاطع الدوائر.

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

الفرق بين نمط Circuit Breaker ونمط "Retry" وهو أن نمط "Retry" يسمح لأحد التطبيقات بالاستمرار في إعادة محاولة الاتصال إلى مورد، والذي قد يكون غير متصل. نمط قاطع الدوائر يمنع هذا السلوك ويفشل عبر التطبيق إلى الاتصال الثانوي.

الغرض من تنفيذ نمط قاطع الدوائر هو توفير الاستقرار لتطبيقك في حين يسترد النظام من الفشل.

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

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

لمزيدٍ من المعلومات، تحقق من نمط Circuit Breaker.