مجموعة من عقدتين - الشيطان يكمن في التفاصيل

يا هبر! أقدم انتباهكم إلى ترجمة المقال عقدتان - الشيطان في التفاصيل بواسطة أندرو بيكهوف.

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

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

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

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

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

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

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

لذلك ، لمنع تلف البيانات الناتج عن فشل عقدة واحدة - نعتمد على شيء يسمى "ترسيم" (سياج).

مبدأ التباعد

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

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

يساعد النصاب في حالة استخدام كل من الطرق المباشرة وغير المباشرة.

التباعد المباشر

في حالة السياج المباشر ، يمكننا استخدام النصاب لمنع سباقات المبارزة في حالة فشل الشبكة.

مع وجود مفهوم النصاب القانوني ، هناك معلومات كافية في النظام (حتى بدون الاتصال بأقرانها) للعقد لتعرف تلقائيًا ما إذا كان ينبغي عليها بدء الفصل و / أو الاسترداد.

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

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

لسوء الحظ ، نادرًا ما يتم النظر في ميزات أجهزة IPMI و iLo في وقت شراء المعدات.

التباعد غير المباشر

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

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

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

تكمن مشكلة اختيار وضع واحد في عدم وجود مسار عمل يزيد من الإتاحة ويمنع فقدان البيانات.

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

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

إذا لم يكن هناك بديل آخر ، فإن أفضل نهج هو التضحية بإمكانية الوصول (هنا يشير المؤلف إلى نظرية CAP). لا يساعد التوفر العالي للبيانات التالفة أي شخص ، كما أن التوفيق بين مجموعات البيانات المختلفة يدويًا ليس أمرًا ممتعًا أيضًا.

النصاب القانوني

النصاب يبدو رائعًا ، أليس كذلك؟

العيب الوحيد هو أنه من أجل الحصول عليها في مجموعة بها N من الأعضاء ، يجب أن يكون لديك اتصال بين N / 2 + 1 من عقدك. وهو أمر غير ممكن في كتلة عقدة بعد فشل عقدة واحدة.

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

نصنع مجموعة من عقدتين تعمل

في بعض الأحيان لا يستطيع العميل أو لا يريد شراء عقدة ثالثة ، ونحن مضطرون للبحث عن بديل.

الخيار 1 - طريقة ترسيم الحدود مكررة

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

بعد الفشل ، يحاول الناجي أولاً الاتصال بجهاز المبارزة الأساسي (iLO أو IPMI). إذا نجحت ، يستمر التعافي كالمعتاد. فقط في حالة فشل جهاز iLO / IPMI ، يتم الوصول إلى PDU ، إذا كان الوصول ناجحًا ، يمكن أن يستمر الاسترداد.

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

في هذه المرحلة ، قد تسأل - أليست PDU نقطة فشل واحدة؟ الجواب بالطبع.

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

الخيار 2 - إضافة حكم

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

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

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

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

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

الخيار 3 - العامل البشري

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

خيار المكافأة

هل ذكرت أنه يمكنك إضافة عقدة ثالثة؟

رفين

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

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

الجواب المختصر هو أن هذا غير ممكن ، ومرة ​​أخرى نحن نتعامل مع جميع المشاكل في حالة عقدتين. او ناجية:

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

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

مركزان للبيانات

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

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

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

المصدر: www.habr.com