المرونة والتعافي من الكوارث في خدمة Azure Web PubSub

مقالة
10/26/2023

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

للتعافي من الكوارث الإقليمية، نوصي باتباع النهجين التاليين:

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

بنية عالية التوفر لخدمة Web PubSub

هناك نمطان نموذجيان باستخدام خدمة Web PubSub:

أحدهما هو نمط خادم العميل الذي يرسل العملاء الأحداث إلى الخادم ويدفع الخادم الرسائل إلى العملاء.
آخر هو نمط العميل والعميل أن العملاء النشر / الرسائل الفرعية من خلال خدمة Web PubSub للعملاء الآخرين.

تصف الأقسام أدناه طرقا مختلفة لهذين النمطين للتعافي من الكوارث

بنية عالية التوفر لنمط خادم العميل

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

أحد الإعدادات النموذجية لسيناريو عبر المناطق هو أن يكون لديك زوجان (أو أكثر) من مثيلات خدمة Web PubSub وخوادم التطبيقات.

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

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

يمكن لخادم التطبيق استخدام واجهة برمجة تطبيقات التحقق من صحة الخدمة للكشف عن ما إذا كانت خدماته الأساسيةوالثانوية سليمة أم لا. على سبيل المثال، لخدمة Web PubSub تسمى demo، ترجع نقطة https://demo.webpubsub.azure.com/api/health النهاية 200 عندما تكون الخدمة سليمة. يمكن لخادم التطبيق استدعاء نقاط النهاية بشكل دوري أو استدعاء نقاط النهاية عند الطلب للتحقق مما إذا كانت نقاط النهاية سليمة. عادة ما يتفاوض عملاء WebSocket مع خادم التطبيق الخاص به أولا للحصول على عنوان URL المتصل بخدمة Web PubSub، ويستخدم التطبيق خطوة التفاوض هذه للفشل عبر العملاء في الخدمات الثانوية الصحية الأخرى. الخطوات التفصيلية كما يلي:

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

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

لم ندمج الاستراتيجية في SDK حتى الآن، لذلك يحتاج التطبيق في الوقت الحالي إلى تنفيذ هذه الاستراتيجية بنفسه.

باختصار، ما يحتاج التطبيق إلى تنفيذه هو:

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

فيما يلي رسم تخطيطي يوضح هذه الطوبولوجيا:

Diagram shows two regions each with an app server and a Web PubSub service, where each server is associated with the Web PubSub service in its region as primary and with the service in the other region as secondary.

تسلسل تجاوز الفشل وأفضل الممارسات

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

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

توضح الرسومات التخطيطية أدناه كيفية تنفيذ تجاوز الفشل:

Fig.1 قبل تجاوز الفشل Before Failover

Fig.2 بعد تجاوز الفشل After Failover

Fig.3 وقت قصير بعد الاسترداد الأساسي Short time after primary recovers

يمكنك أن ترى في الحالة العادية فقط خادم التطبيق الأساسي وخدمة Web PubSub لديها نسبة استخدام الشبكة عبر الإنترنت (باللون الأزرق).

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

بعد قطع اتصال جميع العملاء الحاليين، سيعود النظام إلى حالته الطبيعية (Fig.1).

هناك نمطان رئيسيان لتنفيذ بنية عالية التوفر عبر المناطق:

الأول هو أن يكون لديك زوج من خادم التطبيق ومثيل خدمة Web PubSub يأخذ كل نسبة استخدام الشبكة عبر الإنترنت، وأن يكون لديه زوج آخر كنسخة احتياطية (يسمى نشط/سلبي، موضح في Fig.1).
والآخر هو أن يكون لديك زوجان (أو أكثر) من خوادم التطبيقات ومثيلات خدمة Web PubSub، كل واحد يشارك في حركة المرور عبر الإنترنت ويعمل كنسخة احتياطية للأزواج الأخرى (تسمى نشطة / نشطة، على غرار Fig.3).

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

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

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

بنية عالية التوفر لنمط العميل والعميل

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

كيفية اختبار تجاوز الفشل

اتبع الخطوات لتشغيل تجاوز الفشل:

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