اختيار القائد في الأنظمة الموزعة

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

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

وبسبب هذه التعقيدات، ننظر بعناية في الخيارات الأخرى قبل تنفيذ عملية اختيار القائد. بالنسبة لمعالجة البيانات وتدفقات العمل، فإن خدمات تدفق العمل، مثل AWS Step Functions يمكن أن تحقق نفس الفوائد المرجوة من عملية اختيار القائد مع تجنب العديد من مخاطرها. وبالنسبة للأنظمة الأخرى، كثيرًا ما ننفِّذ واجهات برمجة تطبيقات متساوية القوى، والقفل المتفائل، والأنماط الأخرى التي تجعل من عملية اختيار قائد مفرد غير ضرورية.

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

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

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

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

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

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

يعتبر اختيار القائد نمط نشر على نطاق واسع عبر Amazon. على سبيل المثال:

• تعتمد جميع الأنظمة التي تستخدم أنظمة إدارة قواعد البيانات الارتباطية التقليدية (RDBMSs) تقريبًا على اختيار القائد لتحديد قاعدة بيانات قائدة تتعامل مع جميع عمليات الكتابة، وأحيانًا، جميع القراءات. في هذه الأنظمة، قد يتم إجراء الاختيار تلقائيًا، ولكن يتم إجراؤه بصورة متكررة يدويًا بواسطة مشغل بشري.
• توزع Amazon EBS بيانات القراءة والكتابة لأحد المجلدات على العديد من خوادم التخزين. ولضمان تحقيق الاتساق، تستخدم اختيار القائد لاختيار النسخ الأساسية لكل منطقة من المجلد ترتب بيانات القراءة والكتابة. إن فشلت النسخة الأساسية، تحل محلها نسخًا تابعة باستخدام آلية اختيار القائد نفسها. في Amazon EBS، يضمن اختيار القائد الاتساق، مع تحسين الأداء من خلال تجنب التنسيق على مستوى البيانات. تستخدم كل من DynamoDB وAmazon QLDB) Amazon Quantum Ledger Database( ، و Amazon Kinesis (Kinesis) مناهج متماثلة لنفس السبب.
• تستخدم Kinesis Client Library (KCL) عقود الإيجار للتأكد من أنه تتم معالجة كل قطعة Kinesis من خلال مالك مفرد، مما يجعل من السهل القيام بمعالجة تدفقات Kinesis.

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

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

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

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

نتبع في Amazon أفضل هذه الممارسات لاختيار القائد:

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

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

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

وعلى الرغم من الفروق الدقيقة، فإن اختيار القائد لا يزال أداة مفيدة في مجموعة أدوات الأنظمة الموزعة لدينا في Amazon، إلى جانب أنماط، مثل تساوي القوى والقفل المتفائل.

لمزيد من المعلومات حول كيفية عمل عقود الإيجار، راجع:

• كيفية القيام بالقفل الموزع
• Burrows، خدمة القفل الممتلئ للأنظمة الموزعة المتباعدة
• Gray and Cheriton، عقود الإيجار: آلية فعالة للتعامل مع الأعطال لاتساق التخزين المؤقت للملفات الموزعة