Tupperware: قاتل Kubernetes فیس بوک؟

مدیریت کارآمد و قابل اعتماد خوشه ها در هر مقیاسی با Tupperware

امروز در کنفرانس Systems@Scale ما Tupperware را معرفی کردیم، سیستم مدیریت خوشه‌ای ما که کانتینرها را در میلیون‌ها سرور که تقریباً همه سرویس‌های ما را اجرا می‌کنند، هماهنگ می‌کند. ما برای اولین بار Tupperware را در سال 2011 مستقر کردیم و از آن زمان زیرساخت های ما رشد کرده است 1 مرکز داده به کل 15 مرکز داده با توزیع جغرافیایی. در تمام این مدت، Tupperware ثابت نماند و با ما توسعه یافت. ما به شما نشان خواهیم داد که چگونه Tupperware مدیریت کلاستر درجه یک را ارائه می دهد، از جمله پشتیبانی راحت از خدمات stateful، یک پنل کنترل واحد برای همه مراکز داده، و توانایی توزیع ظرفیت بین سرویس ها در زمان واقعی. ما همچنین درس هایی را که آموخته ایم با توسعه زیرساخت ها به اشتراک خواهیم گذاشت.

Tupperware وظایف مختلفی را انجام می دهد. توسعه دهندگان برنامه از آن برای ارائه و مدیریت برنامه ها استفاده می کنند. کد برنامه و وابستگی ها را در یک تصویر بسته بندی می کند و آن را به عنوان کانتینر به سرورها تحویل می دهد. کانتینرها بین برنامه های کاربردی در همان سرور ایزوله می کنند تا توسعه دهندگان با منطق برنامه برخورد کنند و نگران یافتن سرورها یا مدیریت به روز رسانی ها نباشند. Tupperware نیز عملکرد سرور را کنترل می کند و در صورت مشاهده خرابی، کانتینرها را از سرور مشکل دار منتقل می کند.

مهندسان برنامه ریزی ظرفیت از Tupperware برای تخصیص ظرفیت سرور به تیم ها بر اساس بودجه و محدودیت ها استفاده می کنند. آنها همچنین از آن برای بهبود استفاده از سرور استفاده می کنند. اپراتورهای مرکز داده برای توزیع مناسب کانتینرها در مراکز داده و توقف یا حرکت کانتینرها در حین نگهداری به Tupperware مراجعه می کنند. به لطف این، نگهداری سرورها، شبکه ها و تجهیزات به حداقل مداخله انسانی نیاز دارد.

معماری Tupperware

معماری PRN Tupperware یکی از مناطق مراکز داده ما است. این منطقه شامل چندین ساختمان مرکز داده (PRN1 و PRN2) است که در نزدیکی آن قرار دارند. ما قصد داریم یک کنترل پنل بسازیم که تمام سرورها را در یک منطقه مدیریت کند.

توسعه دهندگان برنامه خدمات را در قالب کارهای تاپرور ارائه می دهند. یک کار از چندین کانتینر تشکیل شده است و همه آنها معمولاً یک کد برنامه را اجرا می کنند.

Tupperware مسئول تهیه ظروف و مدیریت چرخه حیات آنها است. از چندین جزء تشکیل شده است:

• بخش جلویی تاپرور، APIهایی را برای رابط کاربری، CLI و سایر ابزارهای اتوماسیون ارائه می‌کند که از طریق آنها می‌توانید با تاپرور تعامل داشته باشید. آنها کل ساختار داخلی را از صاحبان مشاغل Tupperware پنهان می کنند.
• Tupperware Scheduler یک کنترل پنل است که مسئولیت مدیریت کانتینر و چرخه عمر کار را بر عهده دارد. در سطوح منطقه ای و جهانی مستقر است، جایی که زمانبندی منطقه ای سرورها را در یک منطقه مدیریت می کند و زمانبندی جهانی سرورهای مناطق مختلف را مدیریت می کند. زمانبندی به قطعات تقسیم می شود و هر خرده مجموعه ای از کارها را مدیریت می کند.
• Tupperware's Scheduler Proxy تقسیم بندی داخلی را پنهان می کند و یک شیشه تک شیشه ای راحت را برای کاربران Tupperware فراهم می کند.
• تخصیص دهنده Tupperware کانتینرها را به سرورها اختصاص می دهد. زمانبند توقف، راه اندازی، به روز رسانی و خرابی کانتینرها را کنترل می کند. در حال حاضر، یک تخصیص دهنده می تواند کل منطقه را بدون تقسیم به خرده ها مدیریت کند. (به تفاوت در اصطلاح توجه کنید. به عنوان مثال، زمانبندی در Tupperware با کنترل پنل در مطابقت دارد کوبرنیتسو تخصیص دهنده Tupperware در Kubernetes زمانبندی نامیده می شود.)
• کارگزار منبع منبع حقیقت را برای رویدادهای سرور و سرویس ذخیره می کند. ما یک کارگزار منبع را برای هر مرکز داده اجرا می کنیم و تمام اطلاعات مربوط به سرورهای آن مرکز داده را ذخیره می کند. کارگزار منابع و سیستم مدیریت ظرفیت یا سیستم تامین منابع به صورت پویا تصمیم می گیرند که تحویل زمانبندی کدام سرور را کنترل می کند. سرویس بررسی سلامت سرورها را نظارت می کند و داده های مربوط به سلامت آنها را در کارگزار منابع ذخیره می کند. اگر سروری مشکل داشته باشد یا نیاز به تعمیر و نگهداری داشته باشد، کارگزار منابع به تخصیص دهنده و زمانبندی می گوید که کانتینرها را متوقف کنند یا آنها را به سرورهای دیگر منتقل کنند.
• Tupperware Agent یک دیمون در حال اجرا بر روی هر سرور است که تهیه و حذف کانتینرها را انجام می دهد. برنامه ها در داخل یک ظرف اجرا می شوند که به آنها انزوا و تکرارپذیری بیشتری می دهد. بر کنفرانس سال گذشته Systems @Scale قبلاً توضیح داده‌ایم که چگونه کانتینرهای Tupperware با استفاده از تصاویر، btrfs، cgroupv2 و systemd ایجاد می‌شوند.

ویژگی های متمایز Tupperware

Tupperware از بسیاری جهات به سایر سیستم های مدیریت خوشه مانند Kubernetes و مزوس، اما تفاوت هایی نیز وجود دارد:

• پشتیبانی داخلی برای خدمات دولتی.
• یک پنل کنترل واحد برای سرورها در مراکز داده مختلف برای خودکارسازی تحویل کانتینرها بر اساس قصد، از کار انداختن خوشه‌ها و نگهداری.
• تقسیم بندی کنترل پنل را برای بزرگنمایی پاک کنید.
• محاسبات الاستیک به شما این امکان را می دهد که نیرو را بین سرویس ها در زمان واقعی توزیع کنید.

ما این ویژگی‌های جالب را برای پشتیبانی از انواع برنامه‌های کاربردی بدون حالت و حالت در سراسر ناوگان عظیم سرورهای مشترک جهانی توسعه دادیم.

پشتیبانی داخلی برای خدمات دولتی.

Tupperware انواع سرویس‌های حیاتی را اجرا می‌کند که داده‌های محصول دائمی را برای فیس‌بوک، اینستاگرام، مسنجر و واتس‌اپ ذخیره می‌کنند. اینها می توانند فروشگاه های بزرگ جفت های کلید-مقدار باشند (مثلاً ZippyDBو نظارت بر مخازن داده ها (به عنوان مثال، گوریل ODS и غواصی). حفظ سرویس های دولتی آسان نیست، زیرا سیستم باید اطمینان حاصل کند که عرضه کانتینرها می تواند در برابر اختلالات در مقیاس بزرگ، از جمله قطع شبکه یا قطع برق مقاومت کند. و در حالی که تکنیک‌های مرسوم، مانند توزیع کانتینرها در دامنه‌های خطا، برای سرویس‌های بدون وضعیت به خوبی کار می‌کنند، سرویس‌های دارای وضعیت نیاز به پشتیبانی بیشتری دارند.

به عنوان مثال، اگر خرابی سرور باعث شود که یک نسخه از پایگاه داده در دسترس نباشد، آیا باید تعمیر و نگهداری خودکار را فعال کنید که هسته های 50 سرور را از یک مجموعه 10 به روز می کند؟ به موقعیت بستگی دارد. اگر یکی از این 50 سرور ماکت دیگری از همان دیتابیس داشته باشد، بهتر است منتظر بمانید و 2 ماکت را یکجا از دست ندهید. به منظور تصمیم گیری پویا در مورد نگهداری و عملکرد سیستم، به اطلاعاتی در مورد تکثیر داده های داخلی و منطق قرارگیری هر سرویس حالت دار نیاز داریم.

رابط TaskControl به سرویس های حالت دار اجازه می دهد تا بر تصمیماتی که در دسترس بودن داده ها تأثیر می گذارد تأثیر بگذارند. با استفاده از این رابط، زمان‌بند به برنامه‌های خارجی در مورد عملیات کانتینر (راه‌اندازی مجدد، به‌روزرسانی، مهاجرت، نگهداری) اطلاع می‌دهد. یک سرویس stateful کنترل‌کننده‌ای را پیاده‌سازی می‌کند که به Tupperware می‌گوید چه زمانی انجام هر عملیات ایمن است، و این عملیات را می‌توان تعویض کرد یا به‌طور موقت به تأخیر انداخت. در مثال بالا، کنترل کننده پایگاه داده می تواند به Tupperware بگوید که 49 سرور از 50 سرور را به روز کند، اما یک سرور خاص (X) را فعلا به حال خود رها کند. در نتیجه، اگر دوره به روز رسانی هسته بگذرد و پایگاه داده همچنان نتواند نسخه مشکل ساز را بازیابی کند، Tupperware همچنان سرور X را به روز می کند.

بسیاری از سرویس‌های دولتی در Tupperware از TaskControl نه مستقیم، بلکه از طریق ShardManager، یک پلتفرم رایج برای ایجاد سرویس‌های Stateful در فیس‌بوک، استفاده می‌کنند. با Tupperware، توسعه دهندگان می توانند هدف خود را برای نحوه توزیع کانتینرها در مراکز داده مشخص کنند. با ShardManager، توسعه دهندگان قصد خود را برای نحوه توزیع خرده داده ها در کانتینرها مشخص می کنند. ShardManager از قرار دادن داده ها و تکرار برنامه های خود آگاه است و از طریق رابط TaskControl با Tupperware ارتباط برقرار می کند تا عملیات کانتینر را بدون دخالت مستقیم برنامه زمان بندی کند. این ادغام مدیریت سرویس های دولتی را تا حد زیادی ساده می کند، اما TaskControl قادر به کارهای بیشتری است. به عنوان مثال، سطح وب گسترده ما بدون حالت است و از TaskControl برای تنظیم پویا نرخ به روز رسانی به کانتینرها استفاده می کند. در نهایت لایه وب قادر است به سرعت چندین نسخه نرم افزار را تکمیل کند در روز بدون به خطر انداختن در دسترس بودن.

مدیریت سرورها در مراکز داده

هنگامی که Tupperware برای اولین بار در سال 2011 راه اندازی شد، هر خوشه سرور توسط یک زمان بندی جداگانه مدیریت می شد. در آن زمان، یک خوشه فیس بوک، گروهی از رک های سرور بود که به یک سوئیچ شبکه متصل بودند و مرکز داده چندین خوشه را در خود جای داده بود. زمانبند فقط می تواند سرورها را در یک خوشه مدیریت کند، به این معنی که کار نمی تواند در چند خوشه پخش شود. زیرساخت های ما رشد کرد، ما به طور فزاینده ای خوشه ها را حذف کردیم. از آنجایی که Tupperware نمی توانست بدون تغییر کار را از خوشه از کار افتاده به خوشه های دیگر منتقل کند، به تلاش زیاد و هماهنگی دقیق بین توسعه دهندگان برنامه و اپراتورهای مرکز داده نیاز داشت. این فرآیند منجر به هدر رفتن منابع زمانی شد که سرورها برای ماه‌ها به دلیل روش‌های انحلال بیکار بودند.

ما یک کارگزار منبع برای حل مشکل از کار انداختن خوشه و هماهنگ کردن انواع دیگر وظایف تعمیر و نگهداری ایجاد کردیم. کارگزار منابع تمام اطلاعات فیزیکی مرتبط با یک سرور را ردیابی می کند و به صورت پویا تصمیم می گیرد که کدام زمانبندی هر سرور را کنترل کند. پیوند پویا سرورها به زمان‌بندها به زمان‌بند اجازه می‌دهد سرورها را در مراکز داده مختلف مدیریت کند. از آنجایی که یک کار Tupperware دیگر به یک خوشه محدود نمی شود، کاربران Tupperware می توانند نحوه توزیع کانتینرها در دامنه های خطا را مشخص کنند. به عنوان مثال، یک توسعه‌دهنده می‌تواند هدف خود را اعلام کند (مثلاً: "کار من را روی 2 دامنه خطا در منطقه PRN اجرا کنید") بدون تعیین مناطق در دسترس بودن خاص. خود Tupperware سرورهای مناسبی برای اجرای این هدف پیدا می کند، حتی اگر خوشه یا سرویس از کار افتاده باشد.

مقیاس پذیر برای پشتیبانی از کل سیستم جهانی

از لحاظ تاریخی، زیرساخت های ما به صدها سرور اختصاصی برای تیم های فردی تقسیم شده است. به دلیل پراکندگی و نبود استانداردها، هزینه های عملیاتی بالایی داشتیم و استفاده مجدد از سرورهای بیکار دشوارتر بود. در کنفرانس سال گذشته سیستم های @Scale ارائه کردیم زیرساخت به عنوان یک سرویس (IaaS)، که باید زیرساخت های ما را در یک پارک بزرگ سرور واحد متحد کند. اما یک پارک سرور تنها مشکلات خاص خود را دارد. باید الزامات خاصی را برآورده کند:

• مقیاس پذیری با افزودن مراکز داده در هر منطقه، زیرساخت ما رشد کرد. سرورها کوچکتر و کارآمدتر شده اند، بنابراین تعداد زیادی از آنها در هر منطقه وجود دارد. در نتیجه، یک زمان‌بندی واحد در هر منطقه نمی‌تواند تعداد کانتینرهایی را که می‌توان روی صدها هزار سرور در هر منطقه اجرا کرد، مدیریت کرد.
• قابلیت اطمینان. حتی اگر بتوان زمان‌بندی را تا این حد افزایش داد، دامنه وسیع زمان‌بندی به این معنی است که خطر خطاهای بیشتری وجود دارد و کل یک منطقه از کانتینرها غیرقابل مدیریت می‌شود.
• تحمل خطا. در صورت خرابی بزرگ زیرساخت (مثلاً سرورهایی که برنامه زمان‌بندی را اجرا می‌کنند به دلیل خرابی شبکه یا قطع برق از کار می‌افتند)، پیامدهای منفی باید تنها بر بخشی از سرورهای منطقه تأثیر بگذارد.
• سهولت استفاده ممکن است به نظر برسد که باید چندین زمانبندی مستقل برای یک منطقه اجرا کنید. اما از منظر راحتی، یک نقطه ورود به استخر مشترک یک منطقه مدیریت ظرفیت و مشاغل را آسان‌تر می‌کند.

ما زمانبندی را به قطعات تقسیم کردیم تا مشکلات نگهداری یک استخر مشترک بزرگ را حل کنیم. هر خرده زمان‌بندی مجموعه‌ای از مشاغل خود را در منطقه مدیریت می‌کند و این خطر مرتبط با زمان‌بندی را کاهش می‌دهد. با افزایش استخر مشترک، می‌توانیم خرده‌های زمان‌بندی بیشتری اضافه کنیم. برای کاربران Tupperware، خرده‌ها و پراکسی‌های زمان‌بند مانند یک کنترل پنل به نظر می‌رسند. آنها مجبور نیستند با دسته ای از خرده ها کار کنند که وظایف را هماهنگ می کنند. خرده‌های زمان‌بند اساساً با زمان‌بندی‌های خوشه‌ای که قبلاً استفاده می‌کردیم، متفاوت هستند، زمانی که کنترل پنل بدون تقسیم استاتیکی استخر مشترک سرورها بر اساس توپولوژی شبکه، پارتیشن بندی شد.

کارایی استفاده را با محاسبات الاستیک بهبود بخشید

هرچه زیرساخت ما بزرگتر باشد، استفاده کارآمد از سرورهایمان برای بهینه سازی هزینه های زیرساخت و کاهش بار اهمیت بیشتری دارد. دو راه برای افزایش کارایی استفاده از سرور وجود دارد:

• محاسبات الاستیک - خدمات آنلاین را در ساعات خلوت کاهش دهید و از سرورهای آزاد شده برای بارهای کاری آفلاین مانند یادگیری ماشین و مشاغل MapReduce استفاده کنید.
• اضافه بار - سرویس های آنلاین و بارهای کاری دسته ای را روی همان سرورها قرار دهید تا بارهای کاری دسته ای با اولویت پایین اجرا شوند.

گلوگاه در مراکز داده ما این است مصرف برق. بنابراین، ما سرورهای کوچک و کم مصرف را ترجیح می دهیم که با هم قدرت پردازش بیشتری را ارائه می دهند. متأسفانه، در سرورهای کوچک با CPU و حافظه کم، بارگذاری بیش از حد مؤثر کمتر است. البته ما می توانیم چندین کانتینر از سرویس های کوچک را روی یک سرور کوچک کم مصرف قرار دهیم که منابع پردازنده و حافظه کمی مصرف می کنند، اما سرویس های بزرگ در این شرایط عملکرد پایینی خواهند داشت. بنابراین، ما به توسعه دهندگان خدمات بزرگ خود توصیه می کنیم که آنها را بهینه کنند تا از کل سرورها استفاده کنند.


اساسا، با استفاده از محاسبات الاستیک، کارایی استفاده را بهبود می‌بخشیم. بسیاری از سرویس‌های اصلی ما، مانند فید خبری، ویژگی پیام‌رسانی، و ردیف وب جلویی، بسته به زمان روز متفاوت هستند. ما عمداً خدمات آنلاین را در ساعات خلوت کاهش می دهیم و از سرورهای آزاد شده برای بارهای کاری آفلاین مانند یادگیری ماشین و مشاغل MapReduce استفاده می کنیم.

ما از تجربه می دانیم که بهترین کار ارائه کل سرورها به عنوان واحدهای ظرفیت الاستیک است زیرا خدمات بزرگ هم اهداکنندگان اصلی و هم مصرف کنندگان عمده ظرفیت الاستیک هستند و برای استفاده از کل سرورها بهینه شده اند. هنگامی که سرور در ساعات خلوت از سرویس آنلاین خارج می شود، کارگزار منبع سرور را به زمانبندی اجاره می دهد تا بارهای کاری آفلاین را روی آن اجرا کند. اگر سرویس آنلاین اوج بار را تجربه کند، کارگزار منبع به سرعت سرور قرض گرفته شده را فراخوانی می کند و همراه با زمانبندی، آن را به سرویس آنلاین برمی گرداند.

درس های آموخته شده و برنامه ریزی برای آینده

در طول 8 سال گذشته، ما در حال توسعه Tupperware بوده ایم تا با رشد سریع فیس بوک همراه شویم. ما چیزهایی را که آموخته‌ایم به اشتراک می‌گذاریم و امیدواریم که به دیگران کمک کند زیرساخت‌های در حال رشد سریع را مدیریت کنند:

• یک اتصال انعطاف پذیر بین کنترل پنل و سرورهایی که آن را مدیریت می کند، تنظیم کنید. این انعطاف‌پذیری به کنترل پنل اجازه می‌دهد سرورها را در مراکز داده مختلف مدیریت کند، به از کار انداختن و نگهداری خوشه‌ها خودکار کمک می‌کند و تخصیص ظرفیت پویا را با استفاده از محاسبات الاستیک امکان‌پذیر می‌سازد.
• با یک کنترل پنل واحد در منطقه، کار با وظایف راحت‌تر و مدیریت ناوگان بزرگ سرور مشترک آسان‌تر می‌شود. توجه داشته باشید که پانل کنترل یک نقطه ورود واحد را حفظ می کند، حتی اگر ساختار داخلی آن به دلایل مقیاس یا تحمل خطا از هم جدا شده باشد.
• با استفاده از یک مدل پلاگین، کنترل پنل می تواند برنامه های خارجی را از عملیات کانتینر آینده مطلع کند. علاوه بر این، سرویس های stateful می توانند از رابط پلاگین برای سفارشی کردن مدیریت کانتینر استفاده کنند. با استفاده از این مدل پلاگین، کنترل پنل سادگی را فراهم می کند و در عین حال به طور کارآمد بسیاری از خدمات مختلف دولتی را ارائه می دهد.
• ما معتقدیم که محاسبات الاستیک، که در آن کل سرورها را از خدمات اهداکننده برای کارهای دسته‌ای، یادگیری ماشینی و سایر خدمات غیر فوری حذف می‌کنیم، راه بهینه برای بهبود کارایی سرورهای کوچک و کم مصرف است.

ما تازه شروع به اجرا کردیم ناوگان سرور مشترک جهانی واحد. در حال حاضر حدود 20 درصد از سرورهای ما در یک استخر مشترک هستند. برای دستیابی به 100٪، بسیاری از مسائل باید مورد توجه قرار گیرند، از جمله حفظ یک استخر ذخیره سازی مشترک، تعمیر و نگهداری خودکار، مدیریت نیازمندی های مستاجر متقابل، بهبود استفاده از سرور، و بهبود پشتیبانی از بارهای کاری یادگیری ماشین. ما نمی توانیم صبر کنیم تا این چالش ها را بپذیریم و موفقیت های خود را به اشتراک بگذاریم.

منبع: www.habr.com