التحديات وأفضل الممارسات للفشل في الخدمات

Question

هل يعرف أي شخص أي أفضل الممارسات المعمول بها لتشغيل Windows Services (في حالتي ، تم تطويرها في .NET) بحيث ستفشل (تلقائيًا) بشكل صحيح إلى خادم آخر ، لأغراض توافر عالية؟

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

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

شكرًا

جون

Answer 1

هذا ما نجح بالنسبة لي.

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

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

مرة أخرى ، سوف يعتمد حقًا على ما تحتاجه الخدمة. أتمنى أن يساعدك هذا.

Answer 2

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

لمزامنة ، استخدم قاعدة بيانات المعاملات. عادةً ما تؤدي محاولة كتابة التزامن الخاص بك إلى الأخطاء.

Answer 3

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

Answer 4

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

في الحالات التي يجب أن تتعامل فيها مع الفشل في الكود:

1. اختبار الاتصال/مكالمة الخدمة
2. إذا فشل الاختبار ، أرسل التنبيهات
3. تفشل في نقطة نهاية الخدمة "المسجلة" التالية

Answer 5

هناك نوعان أساسيان.

1. يدرك العملاء عنوان نقطة النهاية المختلفة والمفتاح حسب الحاجة أو حسب توجيهات خدمة أخرى أو آلية تكوين. (كمثال على stocktrader demo application هل هذا.)

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

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