مقدمة في الحوسبة عالية التوافر: المفاهيم والنظرية

دعونا نركز أكثر على بعض المبادئ المعمارية الأكبر لإدارة المجموعات أكثر من التركيز على أي حل تقني منفرد.

سنرى بعض عمليات التنفيذ الفعلية لاحقًا في الكتاب - ويمكنك معرفة الكثير حول كيفية عمل ذلك على AWS من Amazon في كتاب Learn Amazon Web Services في كتاب شهر الغداء من Manning. لكن في الوقت الحالي ، لنتأكد أولاً من أننا مرتاحون للأساسيات.

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

قد يحدث هذا من خلال توزيع أعباء العمل بذكاء بين بيئات جغرافية ومتطلبات متنوعة (موازنة الأحمال) ،

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

سنصل إلى كل ذلك. أولاً ، فيما يلي بعض التعريفات الأساسية:

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

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

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

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

Failback : استعادة المسؤوليات إلى عقدة الخادم أثناء تعافيها من الفشل.

النسخ المتماثل : إنشاء نسخ من مخازن البيانات الهامة للسماح بوصول متزامن موثوق من عدة عقد أو عملاء للخادم ولضمان نجاةهم من الكوارث. يتم استخدام النسخ المتماثل أيضًا لتمكين موازنة تحميل موثوقة.

التكرار : توفير عدة عقد خوادم فعلية أو افتراضية متطابقة يمكن لأي شخص منها أن يتبنى العملاء المعزولين لعقد آخر يفشل.

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

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

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

التعافي من الكوارث y: بالكاد يمكن اعتبار البنية التحتية الخاصة بك متاحة بدرجة عالية إذا لم يكن لديك نظام نسخ احتياطي مؤتمت إلى جانب خطة استرداد مدمجة ومختبرة. ستحتاج خطتك إلى حساب إعادة نشر كل خادم من الخوادم في مجموعتك.

الكتلة النشطة / السلبية

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

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

الكتلة النشطة / النشطة

سيكون للكتلة التي تستخدم تصميمًا نشطًا / نشطًا عقدتان أو أكثر تم تكوينهما بشكل متماثل لخدمة العملاء بشكل مستقل.

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

بمجرد استعادة العقدة الأولى أو استبدالها ، سيتم تقسيم العملاء مرة أخرى بين عقدتي الخادم.

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

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

Shared-Nothing مقابل مجموعات الأقراص المشتركة

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

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

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

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

التوفر

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

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

هناك معادلة بسيطة نسبيًا يمكنك استخدامها لبناء تقدير مفيد للتوافر (أ). الفكرة هي تقسيم متوسط ​​الوقت قبل الفشل على متوسط ​​الوقت قبل الفشل بالإضافة إلى متوسط ​​الوقت للإصلاح.

أ = MTBF / (MTBF + MTTR)

كلما اقتربت قيمة A من 1 ، كلما توفرت مجموعتك بشكل أكبر. للحصول على قيمة واقعية لـ MTBF ، ستحتاج على الأرجح إلى قضاء بعض الوقت في تعريض نظام حقيقي لبعض العقوبات الخطيرة ، ومشاهدته بعناية بحثًا عن أعطال البرامج والأجهزة والشبكات. أفترض أنه يمكنك أيضًا الرجوع إلى مقاييس دورة الحياة المنشورة لبائعي الأجهزة أو المستهلكين على نطاق واسع مثل Backblaze للحصول على فكرة عن المدة التي يمكن توقع استمرار الأجهزة المستخدمة بكثرة.

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

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

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

أحد الاعتبارات ذات الصلة ، إذا كنت تنشر مواردك على موفر نظام أساسي تابع لجهة خارجية مثل VMWare أو Amazon Web Services ، هو اتفاقية مستوى الخدمة (SLA) الخاصة بالموفر. تضمن EC2 من Amazon ، على سبيل المثال ، أن توفر مثيلاتها الحاسوبية وأجهزة تخزين كتل التخزين نسبة تشغيل شهرية لا تقل عن 99.95٪ - وهو أقل من خمس ساعات من التعطل سنويًا. ستصدر AWS أرصدة للأشهر التي فاتتهم فيها أهدافهم - على الرغم من أنها ليست كافية لتعويض إجمالي تكاليف العمل في وقت تعطلك. باستخدام هذه المعلومات ، يمكنك الترتيب لمستوى تكرار الخدمة المناسب لاحتياجاتك الفريدة.

بطبيعة الحال ، بصفتك مقدم خدمة لعملائك ، قد تحتاج إلى نشر اتفاقية مستوى الخدمة الخاصة بك بناءً على تقديرات MTBF و MTTR.

التعامل مع الجلسة

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

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

لا أعرف بالضبط كيف تتعامل Amazon مع هذا ، ولكن غالبًا ما تتم معالجة المشكلة من خلال أداة نسخ البيانات مثل memcached التي تعمل على

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

هذه المقالة مقتبسة من " Teach Yourself Linux Virtualization and High Availability: التحضير لامتحان شهادة LPIC-3 304 ". تحقق من كتبي الأخرى حول إدارة AWS و Linux ، بما في ذلك Linux in Action و Linux in Motion  - دورة تدريبية مختلطة تتكون من أكثر من ساعتين من الفيديو وحوالي 40٪ من نص Linux قيد التشغيل.