عقدة من العقدة - الشيطان بالتفصيل

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

يفضل العديد من الأشخاص التكتلات ثنائية العقدة لأنها تبدو أبسط من الناحية المفاهيمية ، وأيضًا أرخص بنسبة 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 متورطة وإذا كانت تشترك في الطاقة من أي من الرفوف) ، أو
  • يحترم النصاب ويفصل نفسه قبل الأوان عندما تفشل عقدة الشريك

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

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


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

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

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

All Articles