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

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

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

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

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

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

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

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

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

تكوين مثيلات خدمة SignalR متعددة

يتم دعم مثيلات خدمة SignalR المتعددة على كل من خوادم التطبيقات وAzure Functions.

بمجرد أن يكون لديك خدمة SignalR وخوادم التطبيقات/وظائف Azure التي تم إنشاؤها في كل منطقة، يمكنك تكوين خوادم التطبيق/وظائف Azure للاتصال بجميع مثيلات خدمة SignalR.

التكوين على خوادم التطبيقات

هناك طريقتان للقيام بذلك:

من خلال التكوين

يجب أن تعرف بالفعل كيفية تعيين خدمة SignalR سلسلة الاتصال من خلال متغيرات البيئة/إعدادات التطبيق/web.cofig، في إدخال تكوين يسمى Azure:SignalR:ConnectionString. إذا كان لديك نقاط نهاية متعددة، يمكنك تعيينها في إدخالات تكوين متعددة، كل منها بالتنسيق التالي:

Azure:SignalR:ConnectionString:<name>:<role>

في الاتصال ionString، <name> هو اسم نقطة النهاية وهو <role> دوره (أساسي أو ثانوي). الاسم اختياري ولكنه مفيد إذا كنت تريد تخصيص سلوك التوجيه بشكل أكبر بين نقاط النهاية المتعددة.

من خلال التعليمات البرمجية

إذا كنت تفضل تخزين سلسلة الاتصال في مكان آخر، يمكنك أيضا قراءتها في التعليمات البرمجية واستخدامها كمعلمات عند الاتصال AddAzureSignalR() (في ASP.NET Core) أو MapAzureSignalR() (في ASP.NET).

إليك عينة التعليمة البرمجية:

ASP.NET Core:

services.AddSignalR()
        .AddAzureSignalR(options => options.Endpoints = new ServiceEndpoint[]
        {
            new ServiceEndpoint("<connection_string1>", EndpointType.Primary, "region1"),
            new ServiceEndpoint("<connection_string2>", EndpointType.Secondary, "region2"),
        });

ASP.NET:

app.MapAzureSignalR(GetType().FullName, hub,  options => options.Endpoints = new ServiceEndpoint[]
    {
        new ServiceEndpoint("<connection_string1>", EndpointType.Primary, "region1"),
        new ServiceEndpoint("<connection_string2>", EndpointType.Secondary, "region2"),
    };

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

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

التكوين على Azure Functions

راجع هذه المقالة.

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

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

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

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

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

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

Fig.3 وقت قصير بعد الاسترداد الأساسي

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

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

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

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

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

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

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

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

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

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

في هذه المقالة، تعلمت كيفية تكوين التطبيق الخاص بك لتحقيق المرونة لخدمة SignalR. لفهم المزيد من التفاصيل حول اتصال الخادم/العميل وتوجيه الاتصال في خدمة SignalR، يمكنك قراءة هذه المقالة لداخلية خدمة SignalR.

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

للحصول على تفاصيل حول كيفية تكوين Azure Functions مع مثيلات خدمة SignalR متعددة، اقرأ دعم مثيلات خدمة Azure SignalR المتعددة في Azure Functions.