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

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

العمارة Tupperware PRN هي واحدة من مناطق مراكز البيانات لدينا. تتكون المنطقة من عدة مباني لمراكز البيانات (PRN1 و PRN2) تقع في مكان قريب. نخطط لإنشاء لوحة تحكم واحدة تدير جميع الخوادم في منطقة واحدة.
يقدم مطورو التطبيقات الخدمات في شكل وظائف Tupperware. تتكون المهمة من عدة حاويات ، وكلها عادة ما تنفذ نفس رمز التطبيق.
Tupperware هي المسؤولة عن توفير الحاويات وإدارة دورة الحياة. يتكون من عدة مكونات:
- يوفر Tupperware Frontend واجهة برمجة تطبيقات لواجهة المستخدم و CLI وأدوات التشغيل الآلي الأخرى التي يمكنك من خلالها التفاعل مع Tupperware. يخفون الهيكل الداخلي بأكمله من أصحاب وظائف Tupperware.
- The Tupperware Scheduler هو لوحة التحكم المسؤولة عن إدارة دورة حياة الحاوية والوظيفة. يتم نشرها على الصعيدين الإقليمي والعالمي ، حيث تدير جدولة إقليمية الخوادم في منطقة واحدة ، وجدول زمني عالمي يدير الخوادم من مناطق مختلفة. يتم تقسيم المجدول إلى شظايا ، ويتحكم كل شارد في مجموعة من المهام.
- يخفي وكيل الجدولة في Tupperware التقسيم الداخلي ويوفر لوحة تحكم موحدة مريحة لمستخدمي Tupperware.
- يعين موزع Tupperware حاويات للخوادم. المجدول مسؤول عن إيقاف الحاويات وبدء تشغيلها وتحديثها وفشلها. حاليًا ، يستطيع موزع واحد إدارة منطقة بأكملها دون تقسيمها إلى شظايا. (لاحظ الفرق في المصطلحات. على سبيل المثال ، يتوافق برنامج الجدولة في Tupperware مع لوحة التحكم في Kubernetes ، ويطلق على موزع Tupperware اسم المجدول في Kubernetes.)
- يخزن وسيط المصدر مصدر الحقيقة للخادم وأحداث الخدمة. نقوم بتشغيل وسيط مورد واحد لكل مركز بيانات ، ويقوم بتخزين جميع معلومات الخادم في مركز البيانات هذا. وسيط المورد ونظام إدارة السعة ، أو نظام تخصيص الموارد ، يقرران بشكل حيوي أي مزود جدولة يتحكم في الخادم. تقوم خدمة الفحص الصحي بمراقبة الخوادم وتخزين البيانات المتعلقة بصحتها في وسيط الموارد. إذا واجه الخادم مشاكل أو يحتاج إلى صيانة ، يطلب وسيط المورد من الموزع والجدولة إيقاف الحاويات أو نقلها إلى خوادم أخرى.
- عامل تثبرور هو برنامج خفي يعمل على كل خادم يقوم بإعداد الحاويات وإزالتها. تعمل التطبيقات داخل الحاوية ، مما يمنحهم مزيدًا من العزلة والتكرار. في مؤتمر SystemsScale العام الماضي ، وصفنا بالفعل كيف يتم إنشاء حاويات Tupperware الفردية باستخدام الصور و btrfs و cgroupv2 و systemd.
ميزات مميزة من تثبرور
تشبه Tupperware أنظمة إدارة الكتلة الأخرى ، مثل Kubernetes و Mesos ، ولكن هناك بعض الاختلافات:
- الدعم الأصلي لخدمات الدولة.
- لوحة تحكم واحدة للخوادم في مراكز بيانات مختلفة لأتمتة عملية تسليم الحاويات بناءً على مجموعات النوايا وإيقاف التشغيل والصيانة.
- فصل واضح من لوحة التحكم للتكبير.
- تتيح لك الحسابات المرنة توزيع الطاقة بين الخدمات في الوقت الفعلي.
لقد قمنا بتصميم هذه الميزات الرائعة لدعم مجموعة متنوعة من التطبيقات عديمة الحالة والحالة في حديقة خوادم مشتركة عالمية ضخمة.
الدعم الأصلي لخدمات الدولة.
يدير Tupperware العديد من الخدمات الجوهرية الهامة التي تخزن بيانات المنتج الثابتة في Facebook و Instagram و Messenger و WhatsApp. يمكن أن تكون هذه أزواج كبيرة ذات قيمة مفتاح (على سبيل المثال ، ZippyDB ) ومراقبة مخازن البيانات (على سبيل المثال ، ODS Gorilla و Scuba ). ليس من السهل الحفاظ على الخدمات الحكومية ، لأن النظام يجب أن يضمن قدرة شحنات الحاويات على تحمل الفشل على نطاق واسع ، بما في ذلك انقطاع التيار الكهربائي أو انقطاع التيار الكهربائي. على الرغم من أن الطرق التقليدية ، مثل توزيع الحاويات عبر مجالات الفشل ، مناسبة تمامًا للخدمات عديمي الجنسية ، إلا أن الخدمات الحكومية تحتاج إلى دعم إضافي.
على سبيل المثال ، إذا كنتيجة لفشل الخادم بسبب عدم توفر نسخة متماثلة واحدة من قاعدة البيانات ، فهل من الضروري السماح بالصيانة التلقائية التي ستقوم بتحديث النواة على 50 خادمًا من مجموعة 10 آلاف؟ ذلك يعتمد على الوضع. إذا كانت هناك نسخة متماثلة أخرى من قاعدة البيانات نفسها على أحد هذه الخوادم الخمسين ، فمن الأفضل الانتظار وعدم فقد نسختين متماثلتين في نفس الوقت. من أجل اتخاذ القرارات بشكل حيوي بشأن صيانة النظام وصحته ، تحتاج إلى معلومات حول النسخ المتماثل للبيانات الداخلية ومنطق موقع كل خدمة ذات خدمة.
تسمح واجهة TaskControl لخدمات الحالة للتأثير على القرارات التي تؤثر على توفر البيانات. باستخدام هذه الواجهة ، يخطر المجدول التطبيقات الخارجية لعمليات الحاويات (إعادة التشغيل والتحديث والترحيل والصيانة). تطبق خدمة Stateful وحدة تحكم تخبر Tupperware عندما يمكن إجراء كل عملية بأمان ، ويمكن تبديل هذه العمليات أو تأخيرها مؤقتًا. في المثال أعلاه ، قد تطلب وحدة التحكم في قاعدة البيانات من Tupperware ترقية 49 من الخوادم الخمسين ، ولكن لا تلمس خادمًا معينًا (X) حتى الآن. نتيجة لذلك ، إذا مرت فترة تحديث kernel ، ولم تتمكن قاعدة البيانات من استعادة النسخة المتماثلة للمشكلة ، ستستمر أداة Tupperware في ترقية خادم X.

لا تستخدم العديد من الخدمات الفعالة في Tupperware TaskControl مباشرة ، ولكن من خلال ShardManager ، وهي منصة مشتركة لإنشاء خدمات فعالة على Facebook. باستخدام Tupperware ، يمكن للمطورين الإشارة إلى نيتهم في كيفية توزيع الحاويات عبر مراكز البيانات. مع ShardManager ، يشير المطورون إلى نيتهم في كيفية توزيع أجزاء البيانات على الحاويات. يدرك ShardManager استضافة البيانات وتكرار تطبيقاتها ويتفاعل مع Tupperware من خلال واجهة TaskControl للتخطيط لعمليات الحاوية دون مشاركة مباشرة للتطبيق. هذا التكامل يبسط إلى حد كبير إدارة خدمات الدولة ، ولكن TaskControl قادر على أكثر. على سبيل المثال ، لدينا طبقة ويب واسعة النطاق هو عديمي الجنسية ويستخدم TaskControl لضبط سرعة التحديثات في الحاويات بشكل حيوي. ونتيجة لذلك ، يمكن لطبقة الويب إكمال العديد من إصدارات البرامج يوميًا دون المساس بالتوافر.
إدارة الخادم في مراكز البيانات
عندما ظهر Tupperware لأول مرة في عام 2011 ، كان هناك جدولة منفصلة تتحكم في كل مجموعة خوادم. ثم كانت مجموعة Facebook عبارة عن مجموعة من رفوف الخادم المتصلة بمحول شبكة واحد ، واحتوى مركز البيانات على عدة مجموعات. يمكن لجدولة إدارة الخوادم في كتلة واحدة فقط ، أي أن المهمة لا يمكن أن تمتد إلى عدة مجموعات. كانت بنيتنا التحتية تنمو ، وكنا نقذف على نحو متزايد المجموعات. نظرًا لعدم تمكن Tupperware من نقل المهمة من المجموعة التي تم إيقاف تشغيلها إلى مجموعات أخرى دون تغييرات ، فقد تطلب الأمر الكثير من الجهد والتنسيق الدقيق بين مطوري التطبيقات ومشغلي مركز البيانات. أدت هذه العملية إلى إهدار الموارد عندما كانت الخوادم في وضع الخمول لعدة أشهر بسبب إجراء وقف التشغيل.
لقد أنشأنا وسيط موارد لحل مشكلة إيقاف تشغيل المجموعات وتنسيق أنواع أخرى من مهام الصيانة. يقوم وسيط المورد بمراقبة جميع المعلومات الفعلية المرتبطة بالخادم ، ويقرر بشكل حيوي أي برنامج جدولة يدير كل خادم. يسمح الربط الديناميكي للخوادم بجدولة الجدولة بإدارة الخوادم في مراكز بيانات مختلفة. نظرًا لأن مهمة Tupperware لم تعد مقصورة على مجموعة واحدة ، فيمكن لمستخدمي Tupperware تحديد كيفية توزيع الحاويات عبر مجالات الفشل. على سبيل المثال ، قد يعلن المطور عن نيته (على سبيل المثال: "تشغيل مهمتي على مجالين للفشل في منطقة PRN") دون تحديد مناطق توفر معينة. سوف تجد Tupperware نفسها الخوادم المناسبة لتجسيد هذه النية حتى في حالة إيقاف تشغيل مجموعة أو خدمة.
التحجيم لدعم النظام العالمي بأكمله
تاريخياً ، تم تقسيم البنية التحتية لدينا إلى مئات من مجمعات الخوادم المخصصة للفرق الفردية. نظرًا للتفتت والافتقار إلى المعايير ، كان لدينا تكاليف معاملات مرتفعة ، وكان من الصعب استخدام خوادم الخمول مرة أخرى. في مؤتمر SystemsScale العام الماضي ، قدمنا البنية التحتية كخدمة (IaaS) ، والتي يجب أن تدمج بنيتنا التحتية في أسطول كبير وموحد من الخوادم. لكن أسطول خادم واحد لديه صعوباته الخاصة. يجب أن تفي بمتطلبات معينة:
- التدرجية. نمت البنية التحتية لدينا مع إضافة مراكز البيانات في كل منطقة. أصبحت الخوادم أصغر وأكثر كفاءة في استخدام الطاقة ، لذلك في كل منطقة هناك الكثير. نتيجة لذلك ، لا يمكن لجدولة واحدة لمنطقة ما أن تتعامل مع عدد الحاويات التي يمكن تشغيلها على مئات الآلاف من الخوادم في كل منطقة.
- الموثوقية. حتى إذا كان من الممكن زيادة حجم المجدول ، نظرًا للنطاق الكبير لجدول المواعيد ، فإن مخاطر الأخطاء ستكون أعلى ، وقد تصبح منطقة الحاويات بأكملها غير قابلة للإدارة.
- خطأ التسامح. في حالة حدوث عطل كبير في البنية التحتية (على سبيل المثال ، بسبب تعطل الشبكة أو انقطاع التيار الكهربائي ، ستفشل الخوادم التي يعمل فيها المجدول) ، ولن يكون لجزء من خوادم المنطقة عواقب سلبية.
- سهولة الاستخدام. قد يبدو أنك تحتاج إلى تشغيل عدة برامج جدولة مستقلة في منطقة واحدة. ولكن فيما يتعلق بالراحة ، فإن نقطة دخول واحدة إلى مجموعة مشتركة في المنطقة تعمل على تبسيط القدرة وإدارة الوظائف.
قمنا بتقسيم المجدول إلى أقسام لحل المشكلات المتعلقة بدعم تجمع مشترك كبير. يدير كل قسم جدولة مجموعة المهام الخاصة به في المنطقة ، وهذا يقلل من المخاطر المرتبطة بجدول المواعيد. مع نمو إجمالي عدد التجمعات ، يمكننا إضافة المزيد من عمليات جدولة الجداول. بالنسبة لمستخدمي Tupperware ، تبدو القطع وجداول البروكسي وكأنها لوحة تحكم واحدة. ليس لديهم للعمل مع مجموعة من القطع التي تنظم المهام. تختلف أجزاء برنامج الجدولة اختلافًا جوهريًا عن برامج جدولة الكتلة التي استخدمناها من قبل ، عندما تم تقسيم لوحة التحكم دون فصل ثابت لتجمع الخادم المشترك وفقًا لطوبولوجيا الشبكة.
تحسين الاستفادة مع الحوسبة المرنة
كلما كانت البنية التحتية الخاصة بنا أكبر ، كلما كان من المهم استخدام خوادمنا بكفاءة لتحسين تكاليف البنية التحتية وتقليل الحمل. هناك طريقتان لتحسين استخدام الخادم:
- الحوسبة المرنة - قلل من نطاق الخدمات عبر الإنترنت خلال ساعات الهدوء واستخدم الخوادم المحررة للتحميل في وضع عدم الاتصال ، على سبيل المثال ، للتعلم الآلي ومهام MapReduce.
- التحميل الزائد - استضافة خدمات عبر الإنترنت وأعباء عمل الدُفعات على نفس الخوادم بحيث يتم تنفيذ تحميل الدُفعات بأولوية منخفضة.
عنق الزجاجة في مراكز البيانات لدينا هو استهلاك الطاقة . لذلك ، نفضل الخوادم الصغيرة الموفرة للطاقة والتي توفر معًا المزيد من طاقة المعالجة. لسوء الحظ ، على الخوادم الصغيرة التي تحتوي على كمية صغيرة من موارد المعالج والذاكرة ، التحميل الزائد أقل كفاءة. بالطبع ، يمكننا وضع العديد من حاويات الخدمات الصغيرة على خادم صغير موفر للطاقة يستهلك القليل من موارد المعالج والذاكرة ، ولكن الخدمات الكبيرة ستكون منخفضة الأداء في هذا الموقف. لذلك ، ننصح مطوري خدماتنا الكبيرة بتحسينها بحيث يستخدمون الخادم بالكامل.
في الأساس ، نحسن الاستفادة من الحوسبة المرنة. تعتمد كثافة استخدام العديد من خدماتنا الكبيرة ، على سبيل المثال ، موجز الأخبار وميزات الرسائل ومستوى الويب الأمامي ، على الوقت من اليوم. نحن نخفض عن عمد نطاق الخدمات عبر الإنترنت خلال ساعات الهدوء ونستخدم الخوادم المحررة للتحميل في وضع عدم الاتصال ، على سبيل المثال ، للتعلم الآلي ومهام MapReduce.

من التجربة ، نعلم أنه من الأفضل توفير خوادم كاملة كوحدات ذات قدرة مرنة ، لأن الخدمات الكبيرة هي المانحون الرئيسيون والمستهلكون الرئيسيون للطاقة المرنة على حد سواء ، وقد تم تحسينها لاستخدام الخوادم بالكامل. عندما يتم تحرير الخادم من الخدمة عبر الإنترنت في الساعات الهادئة ، يمنح وسيط الموارد الخادم لجدولة للاستخدام المؤقت بحيث يتم تشغيله دون تحميل عليه. في حالة حدوث ذروة تحميل في خدمة عبر الإنترنت ، يسترجع وسيط الموارد بسرعة خادم الإقراض ، ويعيده مع المجدول إلى الخدمة عبر الإنترنت.
الدروس المستفادة وخطط المستقبل
على مدار الأعوام الثمانية الماضية ، قمنا بتطوير برنامج Tupperware لمواكبة التطور السريع لـ Facebook. نتحدث عن ما تعلمناه ونأمل أن يساعد الآخرين على إدارة البنى التحتية سريعة النمو:
- قم بإعداد اتصالات مرنة بين لوحة التحكم والخوادم التي تديرها. تتيح هذه المرونة للوحة التحكم إدارة الخوادم في مراكز بيانات مختلفة ، وتساعد على إيقاف تشغيل الكتل وصيانتها تلقائيًا ، وتوفر توزيعًا ديناميكيًا للطاقة باستخدام الحوسبة المرنة.
- مع وجود لوحة تحكم واحدة في المنطقة ، يصبح العمل مع المهام أكثر سهولة وأسهل لإدارة أسطول كبير مشترك من الخوادم. يرجى ملاحظة أن لوحة التحكم تدعم نقطة دخول واحدة ، حتى لو تم تقسيم هيكلها الداخلي لأسباب تتعلق بالتسقيف أو الخطأ.
- باستخدام نموذج المكوّن الإضافي ، يمكن لوحة التحكم إخطار التطبيقات الخارجية بعمليات الحاويات القادمة. علاوة على ذلك ، يمكن لخدمات الدولة استخدام واجهة البرنامج المساعد لتكوين إدارة الحاوية. باستخدام هذا النموذج الإضافي ، توفر لوحة التحكم البساطة وتخدم بفعالية العديد من الخدمات الحكومية المختلفة.
- نعتقد أن الحوسبة المرنة ، والتي نأخذ فيها خوادم كاملة للوظائف المجمعة ، والتعلم الآلي وغيرها من الخدمات غير العاجلة من خدمات الجهات المانحة ، هي أفضل طريقة لزيادة كفاءة استخدام الخوادم الصغيرة والكفاءة في استخدام الطاقة.
لقد بدأنا للتو تطبيق حديقة خوادم مشتركة عالمية واحدة . يوجد الآن حوالي 20٪ من خوادمنا في المجموعة المشتركة. لتحقيق 100 ٪ ، تحتاج إلى حل العديد من القضايا ، بما في ذلك دعم مجموعة مشتركة لأنظمة التخزين ، وأتمتة الصيانة ، وإدارة متطلبات العملاء المختلفة ، وتحسين استخدام الخادم وتحسين الدعم لأعباء عمل التعلم الآلي. لا يمكننا الانتظار لمعالجة هذه المهام وتبادل نجاحاتنا.