التحويل التلقائي والتحديثات لتحديثات Azure Managed Redis

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

في هذه المقالة، ستجد هذه المعلومات:

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

ما هو تجاوز الفشل؟

لنبدأ بنظرة عامة على التحويل التلقائي للعبة Azure Managed Redis.

ملخص سريع يتعلق ببنية ذاكرة التخزين المؤقت

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

يمكن العثور على تفاصيل معمقة عن هندسة الريديس المدارة Azure here.

شرح تجاوز الفشل

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

يحدث تجاوز الفشل المخطط له خلال وقتين مختلفين:

• تحديثات النظام، مثل تحديث جزئي من Redis أو ترقيات نظام التشغيل.
• عمليات الإدارة: مثل التحجيم وإعادة التشغيل.

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

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

كيف يحدث التحديث الجزئي؟

تقوم خدمة Azure Managed Redis بتحديث ذاكرة التخزين المؤقت بانتظام بأحدث ميزات وإصلاحات المنصة. ولتصحيح ذاكرة التخزين المؤقت، تتبع الخدمة الخطوات التالية:

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

يتم تصحيح كل جزء من ذاكرة التخزين المؤقت المجمعة بشكل منفصل ولا يغلق الاتصالات بجزء آخر.

إشعار

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

نظرا لأن مزامنة البيانات الكاملة تحدث قبل تكرار العملية، فمن غير المحتمل أن يحدث فقدان البيانات لذاكرة التخزين المؤقت. يمكنك المزيد من الحماية ضد فقدان البيانات عن طريق تصدير البيانات وتمكين الثبات.

تحميل ذاكرة التخزين المؤقت الإضافية

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

كيف يؤثر تجاوز الفشل على تطبيق العميل الخاص بي؟

قد تتلقى تطبيقات العميل بعض الأخطاء من نسخة Azure Managed Redis الخاصة بها. يعتمد عدد الأخطاء التي يراها تطبيق العميل على عدد العمليات المعلقة على هذا الاتصال في وقت تجاوز الفشل. أي اتصال يتم توجيهه عبر العقدة التي أغلقت اتصالاتها يرى أخطاء.

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

• استثناءات المهلة
• استثناءات الاتصال
• استثناءات مأخذ التوصيل

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

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

ما هي التحديثات المضمنة تحت الصيانة؟

تتضمن الصيانة هذه التحديثات:

• تحديثات خادم Redis: أي تحديث أو تصحيح لثنائيات خادم Redis.
• تحديثات الجهاز الظاهري (VM): أي تحديثات للجهاز الظاهري الذي يستضيف خدمة Redis. تتضمن تحديثات الجهاز الظاهري تصحيح مكونات البرامج في بيئة الاستضافة لترقية مكونات الشبكات أو إيقاف التشغيل.

هل يظهر سجل الصيانة في بوابة Azure؟

لمعرفة تاريخ الصيانة في بوابة Azure، تحقق من >Azure <سجل النشاط الخاص بنسخة الكاش الخاصة بك. يحدث حدث "الحدث الصحي" عند بدء الصيانة.

لتلقي الإعلامات تلقائيا، قم بإعداد تنبيه على سجل النشاط.

تغييرات تكوين شبكة العميل

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

• تبديل عنوان IP الظاهري لتطبيق العميل بين الفتحات المرحلية والإنتاجية.
• تحجيم حجم أو عدد مثيلات التطبيق الخاص بك.

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

بناء المرونة

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

كيف أعمل على جعل طلبي مرن؟

ارجع إلى أنماط التصميم هذه لبناء عملاء مرنين، لا سيما قاطع الدائرة وأنماط إعادة المحاولة:

• أنماط موثوقية - أنماط تصميم السحابة
• إرشادات إعادة المحاولة لخدمات Azure - أفضل الممارسات لتطبيقات السحابة
• تنفيذ إعادة المحاولة مع التراجع الأسي

المحتوى ذو الصلة

• مرونة الاتصال