تابروير: قاتل Kubernetes على فيسبوك؟

إدارة فعالة وموثوقة للمجموعات على أي نطاق باستخدام Tupperware

اليوم مؤتمر Systems@Scale لقد قدمنا ​​Tupperware، وهو نظام إدارة المجموعة الخاص بنا والذي يقوم بتنسيق الحاويات عبر ملايين الخوادم التي تقوم بتشغيل جميع خدماتنا تقريبًا. قمنا بنشر Tupperware لأول مرة في عام 2011، ومنذ ذلك الحين تطورت بنيتنا التحتية 1 مركز بيانات حتى كله 15 مركز بيانات موزعة جغرافيًا. طوال هذا الوقت تابروير لم تقف ساكنة وتطورت معنا. سنوضح لك كيف توفر Tupperware إدارة مجموعة من الدرجة الأولى، بما في ذلك الدعم المناسب للخدمات ذات الحالة، ولوحة تحكم واحدة لجميع مراكز البيانات، والقدرة على توزيع السعة بين الخدمات في الوقت الفعلي. وسنشارك أيضًا الدروس التي تعلمناها مع تطور بنيتنا التحتية.

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

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

هندسة تابروير

تعد بنية Tupperware PRN إحدى مناطق مراكز البيانات لدينا. تتكون المنطقة من العديد من مباني مراكز البيانات (PRN1 وPRN2) الواقعة في مكان قريب. نخطط لإنشاء لوحة تحكم واحدة لإدارة كافة الخوادم في منطقة واحدة.

يقدم مطورو التطبيقات الخدمات في شكل وظائف Tupperware. تتكون المهمة من حاويات متعددة، وتقوم جميعها عادةً بتشغيل نفس رمز التطبيق.

تتولى شركة Tupperware مسؤولية توفير الحاويات وإدارة دورة حياتها. يتكون من عدة مكونات:

• توفر الواجهة الأمامية لـ Tupperware واجهات برمجة التطبيقات (APIs) لواجهة المستخدم وCLI وأدوات التشغيل الآلي الأخرى التي يمكنك من خلالها التفاعل مع Tupperware. إنهم يخفون الهيكل الداخلي بالكامل عن أصحاب وظائف Tupperware.
• Tupperware مجدولة هي لوحة تحكم مسؤولة عن إدارة الحاوية ودورة حياة المهمة. يتم نشره على المستويين الإقليمي والعالمي، حيث يقوم المجدول الإقليمي بإدارة الخوادم في منطقة واحدة ويقوم المجدول العالمي بإدارة الخوادم من مناطق مختلفة. يتم تقسيم المجدول إلى أجزاء، ويقوم كل جزء بإدارة مجموعة من الوظائف.
• يخفي وكيل جدولة Tupperware التقسيم الداخلي ويوفر لوحًا زجاجيًا واحدًا مناسبًا لمستخدمي Tupperware.
• يقوم مُخصص Tupperware بتعيين الحاويات للخوادم. يعالج المجدول إيقاف الحاويات وبدءها وتحديثها وتجاوز فشلها. حاليًا، يمكن لمخصص واحد إدارة المنطقة بأكملها دون تقسيمها إلى أجزاء. (لاحظ الفرق في المصطلحات. على سبيل المثال، المجدول في Tupperware يتوافق مع لوحة التحكم الموجودة في Kubernetes، ويُسمى مُخصص Tupperware بالمُجدول في Kubernetes.)
• يقوم وسيط الموارد بتخزين مصدر الحقيقة لأحداث الخادم والخدمة. نقوم بتشغيل وسيط موارد واحد لكل مركز بيانات، ويقوم بتخزين كافة المعلومات حول الخوادم الموجودة في مركز البيانات هذا. يقرر وسيط الموارد ونظام إدارة السعة، أو نظام توفير الموارد، ديناميكيًا تسليم المجدول الذي يتحكم في أي خادم. تقوم خدمة الفحص الصحي بمراقبة الخوادم وتخزين البيانات المتعلقة بحالتها في وسيط الموارد. إذا كان لدى الخادم مشاكل أو يحتاج إلى صيانة، فإن وسيط الموارد يخبر المُخصص والمجدول بإيقاف الحاويات أو نقلها إلى خوادم أخرى.
• وكيل Tupperware هو برنامج خفي يعمل على كل خادم يتولى توفير الحاويات وإزالتها. يتم تشغيل التطبيقات داخل حاوية، مما يمنحها مزيدًا من العزلة وإمكانية التكرار. على مؤتمر Systems @Scale العام الماضي لقد وصفنا بالفعل كيفية إنشاء حاويات Tupperware الفردية باستخدام الصور وbtrfs وcgroupv2 وsystemd.

مميزات تابروير المميزة

تتشابه Tupperware في العديد من النواحي مع أنظمة إدارة المجموعات الأخرى مثل Kubernetes و الميزوسولكن هناك أيضًا اختلافات:

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

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

دعم مدمج للخدمات ذات الحالة.

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

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

تسمح واجهة TaskControl للخدمات ذات الحالة بالتأثير على القرارات التي تؤثر على توفر البيانات. باستخدام هذه الواجهة، يقوم المجدول بإخطار التطبيقات الخارجية بعمليات الحاوية (إعادة التشغيل، التحديث، الترحيل، الصيانة). تطبق الخدمة ذات الحالة وحدة تحكم تخبر Tupperware عندما يكون تنفيذ كل عملية آمنًا، ويمكن تبديل هذه العمليات أو تأخيرها مؤقتًا. في المثال أعلاه، يمكن لوحدة التحكم في قاعدة البيانات أن تطلب من Tupperware تحديث 49 خادمًا من أصل 50 خادمًا، مع ترك خادم معين (X) بمفرده في الوقت الحالي. ونتيجة لذلك، إذا مرت فترة تحديث kernel ولا تزال قاعدة البيانات غير قادرة على استعادة النسخة المتماثلة التي بها مشكلات، فستستمر Tupperware في تحديث خادم X.

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

إدارة الخوادم في مراكز البيانات

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

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

قابلة للتطوير لدعم النظام العالمي بأكمله

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

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

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

تحسين كفاءة الاستخدام باستخدام الحوسبة المرنة

كلما كانت بنيتنا التحتية أكبر، زادت أهمية استخدام خوادمنا بكفاءة لتحسين تكاليف البنية التحتية وتقليل التحميل. هناك طريقتان لزيادة كفاءة استخدام الخادم:

• الحوسبة المرنة - قم بتقليص الخدمات عبر الإنترنت خلال ساعات الهدوء واستخدم الخوادم المجانية لأحمال العمل دون اتصال بالإنترنت، مثل التعلم الآلي ووظائف MapReduce.
• التحميل الزائد - ضع الخدمات عبر الإنترنت وأحمال العمل المجمعة على نفس الخوادم بحيث يتم تشغيل أحمال العمل المجمعة بأولوية منخفضة.

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


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

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

الدروس المستفادة والخطط للمستقبل

على مدى السنوات الثماني الماضية، قمنا بتطوير Tupperware لمواكبة النمو السريع لفيسبوك. نحن نشارك ما تعلمناه ونأمل أن يساعد الآخرين في إدارة البنى التحتية سريعة النمو:

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

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

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