اليوم سوف أخبركم قليلاً عن أفكاري حول فشل الرتانتول / الخرطوشة. أولاً ، بضع كلمات حول ماهية الخرطوشة: هذا جزء من كود lua يعمل داخل تارانتول ويجمع بين الرتيلاء مع بعضها البعض في "مجموعة" شرطية واحدة. وهذا لسببين:
- يعرف كل رتيلاء عناوين الشبكة لجميع الرتيلاء الأخرى ؛
- الرتيلاء بانتظام "بينغ" بعضها البعض عبر UDP لفهم من هو على قيد الحياة ومن ليس على قيد الحياة. هنا أبسط قليلاً عن قصد ، خوارزمية ping أكثر تعقيدًا من مجرد استجابة طلب ، لكن هذا ليس مهمًا جدًا للتحليل. إذا كنت مهتمًا - Google the SWIM algorithm.
داخل الكتلة ، يتم تقسيم كل شيء عادةً إلى رتيلاء ذي الحالة (رئيسي / نسخة متماثلة) وعديم الحالة (جهاز توجيه). تعتبر الرتيلاء عديمة الجنسية مسؤولة عن تخزين البيانات ، أما الرتيلاء عديمة الجنسية فهي مسؤولة عن طلبات التوجيه.
هذه هي الطريقة التي تظهر بها الصورة:
يقوم العميل بتقديم طلبات إلى أي من أجهزة التوجيه النشطة ، ويقوم بإعادة توجيه الطلبات إلى أحد المتاجر ، وهو الآن المدير النشط. في الصورة ، تظهر هذه المسارات بأسهم.
الآن لا أريد تعقيد الحديث عن اختيار القائد وإدخال التشرذم فيه ، لكن الموقف معه سيكون مختلفًا بعض الشيء. الفرق الوحيد هو أن جهاز التوجيه لا يزال بحاجة إلى تحديد مجموعة النسخ المتماثلة المراد استخدامها من المتجر.
أولاً ، لنتحدث عن كيفية معرفة العقد لعناوين بعضها البعض. للقيام بذلك ، كل واحد منهم لديه ملف yaml على القرص مع طوبولوجيا الكتلة ، أي مع معلومات حول عناوين الشبكة لجميع الأعضاء ، ومن منهم (مع أو بدون دولة). بالإضافة إلى إمكانية تخصيص إضافية ، ولكن في الوقت الحالي ، دعنا نترك ذلك جانبًا. تحتوي ملفات التكوين على الإعدادات الخاصة بالمجموعة بأكملها ككل ، وهي نفسها لكل رتيلاء. إذا تم إجراء تغييرات عليهم ، فسيتم إجراؤها بشكل متزامن لجميع الرتيلاء.
الآن يمكن إجراء تغييرات في التكوين من خلال واجهة برمجة التطبيقات لأي من الرتيلاء في المجموعة: ستتصل بأي شخص آخر ، وترسل لهم نسخة جديدة من التكوين ، وسيطبقها الجميع ، وفي كل مكان سيكون هناك إصدار جديد ، نفس الشيء مرة أخرى.
السيناريو - فشل العقدة ، التبديل
في حالة فشل جهاز التوجيه ، يكون كل شيء أكثر أو أقل بساطة: يحتاج العميل فقط إلى الذهاب إلى أي جهاز توجيه نشط آخر ، وسيقوم بتسليم الطلب إلى المتجر المطلوب. ولكن ماذا لو ، على سبيل المثال ، سقط سيد أحد ستوراجا؟
في الوقت الحالي قمنا بتطبيق خوارزمية "ساذجة" لمثل هذه الحالة ، والتي تعتمد على بروتوكول UDP ping. إذا لم "ترى" النسخة المتماثلة الاستجابات من البرنامج الرئيسي إلى اختبار ping لفترة قصيرة من الوقت ، فإنها تعتبر أن السيد قد سقط وأصبح السيد نفسه ، ويتحول إلى وضع القراءة والكتابة من القراءة فقط. تعمل أجهزة التوجيه بنفس الطريقة: إذا لم يروا بعض وقت استجابة ping من الرئيسي ، فإنهم يحولون حركة المرور إلى النسخة المتماثلة.
يعمل هذا بشكل جيد نسبيًا في الحالات البسيطة ، باستثناء حالة الدماغ المنقسمة ، عندما يتم فصل نصف العقد عن أخرى بسبب نوع من مشكلة الشبكة:
في هذه الحالة ، سوف ترى أجهزة التوجيه أن "النصف الآخر" من الكتلة غير متوفر ، وستعتبر أن نصفها هو النصف الرئيسي ، ويتضح أن هناك اثنين من الماجستير في النظام في نفس الوقت. هذه أول قضية مهمة يجب حلها.
البرنامج النصي - تحرير التكوين عند الإخفاقات
سيناريو مهم آخر هو استبدال الرتيلاء الفاشلة في الكتلة بأخرى جديدة ، أو إضافة العقد إلى المجموعة عندما تكون إحدى النسخ المتماثلة أو أجهزة التوجيه غير متوفرة.
في التشغيل العادي ، عندما يكون كل شيء في الكتلة متاحًا ، يمكننا الاتصال عبر API بأي عقدة ، ونطلب منها تعديل التكوين ، وكما قلت أعلاه ، فإن العقدة "تطرح" التكوين الجديد إلى المجموعة بأكملها.
ولكن عندما يكون شخص ما غير متاح ، لا يمكنك تطبيق التكوين الجديد ، لأنه عندما تصبح هذه العقد متاحة مرة أخرى ، سيكون من غير الواضح أي منها في المجموعة يحتوي على التكوين الصحيح وأيها غير متوفر. لا يزال عدم إمكانية الوصول إلى العقد مع بعضها البعض قد يعني أن هناك دماغًا منقسمًا بينهما. يعد تعديل التكوين ببساطة غير آمن ، لأنه يمكنك تعديله بطريق الخطأ بطرق مختلفة بنصفين مختلفين.
لهذه الأسباب ، نمنع الآن تعديل التهيئة عبر واجهة برمجة التطبيقات عندما لا يكون شخص ما متاحًا. يمكن تصحيحه فقط على القرص ، من خلال ملفات نصية (يدويًا). هنا يجب أن تفهم جيدًا ما تفعله وأن تكون حذرًا للغاية: لن تساعدك الأتمتة بأي شكل من الأشكال.
هذا يجعل العملية غير مريحة ، وهذه هي الحالة الثانية التي يجب حلها.
السيناريو - تجاوز فشل مستقر
مشكلة أخرى مع نموذج تجاوز الفشل الساذج هو أن التبديل من النسخة الرئيسية إلى النسخة المتماثلة في حالة الفشل الرئيسي لا يتم تسجيله في أي مكان. تتخذ جميع العقد قرارًا بالتبديل من تلقاء نفسها ، وعندما ينبض المحرك الرئيسي بالحياة ، ستتحول حركة المرور إليه مرة أخرى.
هذا قد يكون أو لا يكون مشكلة. قبل تشغيل البرنامج الرئيسي ، سوف "يلحق" المعلم الرئيسي بسجلات المعاملات من النسخة المتماثلة ، لذلك لن يكون هناك على الأرجح تأخر كبير في البيانات. ستكون المشكلة فقط في حالة وجود مشاكل في الشبكة ، وفقدان الحزم: فعلى الأرجح سيكون هناك "وميض" دوري للسيد (ترفرف).
الحل هو منسق "قوي" (etcd / consul / tarantool)
من أجل تجنب مشاكل الدماغ المنقسم ، ولتمكين تعديل التكوين عندما تكون الكتلة غير متوفرة جزئيًا ، نحتاج إلى منسق قوي مقاوم لتجزئة الشبكة. يجب توزيع المنسق على 3 مراكز بيانات بحيث إذا فشل أي منها ، يظل يعمل.
يوجد الآن منسقان مشهوران في RAFT يستخدمان etcd والقنصل لهذا الغرض. عندما يظهر النسخ المتزامن المتزامن في tarantool ، يمكن استخدامه أيضًا لهذا الغرض.
في هذا المخطط ، تنقسم تركيبات الرتيلاء إلى مركزين للبيانات ، وترتبط بتركيبها المحلي وما إلى ذلك. يعمل مثيل etcd في مركز البيانات الثالث كحكم بحيث في حالة فشل أحد مراكز البيانات ، يكون بالضبط أي منها بقي في الأغلبية.
إدارة التكوين مع منسق قوي
كما قلت أعلاه ، في حالة عدم وجود منسق وفشل أحد الرتيلاء ، لم نتمكن من تعديل التكوين مركزيًا ، لأنه بعد ذلك من المستحيل تحديد التكوين الصحيح لأي من العقد.
في حالة وجود منسق قوي ، يكون كل شيء أبسط: يمكننا تخزين التكوين على المنسق ، وسيحتوي كل مثيل من الرتيلاء على ذاكرة تخزين مؤقت لهذا التكوين في نظام الملفات الخاص به. عند الاتصال الناجح بالمنسق ، سيقوم بتحديث نسخته من التكوين إلى النسخة الموجودة في المنسق.
كما يصبح تحرير التكوين أسهل: يمكن إجراؤه من خلال واجهة برمجة التطبيقات لأي رتيلاء. سيستغرق الأمر قفلًا في المنسق ، واستبدال القيم المطلوبة في التكوين ، وانتظر حتى تقوم جميع العقد بتطبيقه ، ثم حرر القفل. حسنًا ، أو كحل أخير ، يمكنك تعديل التكوين في etcd يدويًا ، وسيتم تطبيقه على المجموعة بأكملها.
سيكون من الممكن تعديل التكوين حتى لو لم تكن بعض الرتيلاء متوفرة. الشيء الرئيسي هو أن معظم عقد المنسق متوفرة.
تجاوز الفشل مع منسق قوي
تم حل التبديل الموثوق للعقد مع المنسق نظرًا لحقيقة أنه بالإضافة إلى التكوين ، سنخزن في المنسق معلومات حول من هو الرئيس الحالي في النسخة المتماثلة ومكان إجراء المحولات.
تتغير خوارزمية تجاوز الفشل على النحو التالي:
- «» .
- UDP-, - , .
- , .
- .
- , read-only read-write.
- , , .
مع وجود منسق ، يمكن أيضًا حماية الرفرفة. في المنسق ، يمكنك تسجيل محفوظات التبديل بالكامل ، وإذا قام المدير خلال آخر X دقيقة بالتحويل إلى نسخة متماثلة ، فسيتم إجراء التبديل العكسي بشكل صريح فقط من قبل المسؤول.
نقطة أخرى مهمة هي ما يسمى ب "المبارزة". يجب أن تفترض الرتيلاء التي تجد نفسها معزولة عن مراكز البيانات الأخرى (أو متصلة بمنسق فقد الأغلبية) أن بقية الكتلة ، التي فقد الوصول إليها ، لديها الأغلبية على الأرجح. وهذا يعني أنه في غضون فترة زمنية معينة ، يجب أن تذهب جميع العقد المقطوعة عن الأغلبية للقراءة فقط.
مشكلة عدم توفر المنسق
بينما كنا نناقش مناهج العمل مع المنسق ، تلقينا طلبًا للتأكد من أنه في حالة سقوط المنسق ، ولكن جميع الرتيلاء سليمة ، لا تترجم المجموعة بأكملها إلى قراءة فقط.
في البداية بدا أنه لم يكن من الواقعي القيام بذلك ، ولكن بعد ذلك تذكرنا أن الكتلة نفسها تراقب مدى توفر العقد الأخرى عبر عمليات اتصال UDP. هذا يعني أنه يمكننا استهدافهم وعدم إعادة انتخاب الرئيسي داخل مجموعة النسخ المتماثلة ، إذا كان من الواضح من خلال اختبار اتصال UDP أن مجموعة النسخ المتماثلة بأكملها حية.
سيساعدك هذا الأسلوب على تقليل القلق بشأن توفر المنسق ، خاصة إذا كنت بحاجة إلى إعادة تشغيله على سبيل المثال للتحديث.
خطط التنفيذ
نحن الآن نجمع التعليقات ونبدأ في التنفيذ. إذا كان لديك ما تقوله - اكتب في التعليقات أو بشكل شخصي.
الخطة هي شيء من هذا القبيل:
- تقديم دعم etcd في tarantool [تم]
- تجاوز الفشل باستخدام etcd كمنسق ، ذو الحالة [تم]
- تجاوز الفشل باستخدام الرتيلاء كمنسق ، الإغلاق [تم]
- تخزين التكوين في etcd [قيد التقدم]
- كتابة أدوات CLI لإصلاح الكتلة [قيد التقدم]
- تخزين التكوين في الرتيلاء
- إدارة الكتلة عندما يكون جزء من الكتلة غير متوفر
- سياج
- حماية الخفقان
- تجاوز الفشل باستخدام القنصل كمنسق
- تخزين التكوين في القنصل
في المستقبل ، من شبه المؤكد أننا سنتخلى عن الكتلة بالكامل بدون منسق قوي. سيتزامن هذا على الأرجح مع التنفيذ المستند إلى RAFT للتكرار المتزامن في الرتيلاء.
شكر وتقدير
شكرًا للمطورين من Mail.ru Mail والمسؤولين على التعليقات والنقد والاختبار المقدم.