خدمات Windows - سيناريوهات التوافر العالية ونهج التصميم

Question

لنفترض أن لدي خدمة Windows المستقلة تعمل في جهاز Windows Server. كيف تتأكد من أنها متوفرة للغاية؟

1). ما هي كل إرشادات مستوى التصميم التي يمكنك اقتراحها؟

2). كيفية جعلها متاحة للغاية مثل الأساسي/الثانوي ، على سبيل المثال ، حلول التجميع المتاحة حاليًا في السوق

3). كيفية التعامل مع المخاوف المتقاطعة في حالة أي سيناريوهات فاشلة

إذا كان هناك أي شخص آخر يمكنك التفكير فيه ، فيرجى إضافته هنا ..

ملحوظة:السؤال يتعلق فقط بخدمات Windows و Windows ، يرجى محاولة طاعة هذه القاعدة :)

Answer 1

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

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

بالنسبة لأوامر Idempotent ، يمكن تحقيق التسامح مع الإخفاقات المتقطعة (مثل الموارد المقفلة) عن طريق إعادة تأكيد الأمر بعدد معين من المرات. يتيح ذلك للخدمة حماية العميل من الفشل (إلى حد ما.) يجب أيضًا ترميز العميل لتوقع الفشل. يمكن للعميل التعامل مع فشل الخدمة بعدة طرق - التسجيل ، ودفع المستخدم ، وإعادة محاولة X Times ، وتسجيل خطأ مميت والخروج كلها معالجات محتملة - وهو ما يعتمد عليك على متطلباتك. إذا كانت الخدمة "حالة محادثة" ، عندما تفشل الخدمة بجد (تم إعادة تشغيل عملية أي) ، يجب أن يكون العميل على دراية بموقف THS والتعامل معه ، حيث يعني ذلك عادةً حالة المحادثة الحالية.

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

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

هذا هو في الحقيقة مجرد غيض من جبل الجليد ، لكنني آمل أن يمنحك أفكارًا للبدء في مزيد من البحث.

خدمة التجميع Microsoft (MSCs)

Answer 2

إذا قمت بتفكيك المشكلات التي تحاول حلها ، أعتقد أنك ستتوصل إلى بعض الإجابات بنفسك. كما ذكر جوستين في التعليق ، لا يوجد إجابة واحدة. يعتمد الأمر تمامًا على ما تفعله خدمتك وكيف يستخدمه العملاء. أنت أيضًا لا تحدد أي تفاصيل حول تفاعل خادم العميل. http؟ TCP؟ UDP؟ آخر؟

إليك بعض الأشياء التي يجب التفكير فيها لتبدأ.

1) ماذا تفعل إذا سقطت الخدمة أو الخادم؟

• ماذا عن تشغيل أكثر من مثال من خدمتك على خوادم منفصلة؟

2) حسنًا ، ولكن الآن كيف يعرف العملاء عن الخدمات المتعددة؟

• يمكنك رمز القائمة الثابتة في كل عميل (غير موصى به)
• يمكنك استخدام DNS Round-Robin لترتد الطلبات عبرها جميعًا.
• يمكنك استخدام جهاز توازن التحميل.
• يمكنك الحصول على خدمة منفصلة تعرف عن جميع الخدمات الأخرى ويمكنك توجيه العملاء إلى الخدمات المتاحة.

3) إذن ماذا لو سقطت خدمة واحدة؟

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

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

Answer 3

إذا لم تعرض الخدمة أي واجهة لاتصال العميل ، فيمكنك:

• بث أو فضح رسالة "أنا على قيد الحياة" أو إشارة إلى قاعدة بيانات/سجل/TCP/مهما كنت على قيد الحياة

• احصل على خدمة ثانية (شاشة) تتحقق من إشارات "أنا على قيد الحياة" ومحاولة إعادة تشغيل الخدمة في حالة انخفاضها

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