Ефикасно и доверливо управување со кластери во која било скала со Tupperware
Денес на го воведовме Tupperware, нашиот систем за управување со кластери што ги организира контејнерите низ милиони сервери што ги извршуваат речиси сите наши услуги. Првпат го распоредивме Tupperware во 2011 година и оттогаш нашата инфраструктура се зголеми на целина . Сето ова време, Tupperware не застана и се развиваше со нас. Ќе ви покажеме како Tupperware обезбедува првокласно управување со кластери, вклучувајќи удобна поддршка за државните услуги, единствена контролна табла за сите центри за податоци и можност за дистрибуција на капацитетот помеѓу услугите во реално време. Ќе ги споделиме и лекциите што ги научивме додека нашата инфраструктура се развива.
Tupperware извршува различни задачи. Програмерите на апликации го користат за доставување и управување со апликации. Го пакува кодот на апликацијата и зависностите во слика и ги доставува до серверите како контејнери. Контејнерите обезбедуваат изолација помеѓу апликациите на истиот сервер, така што програмерите се справуваат со логиката на апликацијата и не мора да се грижат за наоѓање сервери или управување со ажурирања. Tupperware исто така ги следи перформансите на серверот и доколку открие дефект, ги пренесува контејнерите од проблематичниот сервер.
Инженерите за планирање на капацитетот користат Tupperware за да го распределат капацитетот на серверот на тимовите врз основа на буџетот и ограничувањата. Тие исто така го користат за подобрување на искористеноста на серверот. Операторите на центрите за податоци се свртуваат кон Tupperware за правилно да ги дистрибуираат контејнерите низ центрите за податоци и да ги стопираат или преместуваат контејнерите за време на одржувањето. Благодарение на ова, одржувањето на сервери, мрежи и опрема бара минимална човечка интервенција.
Архитектура на Tupperware
Архитектурата на Tupperware PRN е еден од регионите на нашите центри за податоци. Регионот се состои од неколку згради на центри за податоци (PRN1 и PRN2) кои се наоѓаат во близина. Планираме да направиме една контролна табла која ќе управува со сите сервери во еден регион.
Програмерите на апликации испорачуваат услуги во форма на работни места на Tupperware. Работата се состои од повеќе контејнери и сите тие обично го користат истиот код за апликација.
Tupperware е одговорен за обезбедување контејнери и управување со нивниот животен циклус. Се состои од неколку компоненти:
- Предниот дел на Tupperware обезбедува API за корисничкиот интерфејс, CLI и други алатки за автоматизација преку кои можете да комуницирате со Tupperware. Тие ја кријат целата внатрешна структура од сопствениците на работни места на Tupperware.
- Tupperware Scheduler е контролен панел одговорен за управување со контејнерот и работниот циклус. Распореден е на регионално и глобално ниво, каде што регионалниот распоредувач управува со серверите во еден регион, а глобалниот распоредувач управува со серверите од различни региони. Распоредувачот е поделен на парчиња, и секој дел управува со сет на задачи.
- Scheduler Proxy на Tupperware го крие внатрешното раздвојување и обезбедува практично единечно стакло за корисниците на Tupperware.
- Алокаторот Tupperware доделува контејнери на серверите. Распоредувачот се справува со запирање, стартување, ажурирање и откажување на контејнерите. Во моментов, еден алокатор може да управува со целиот регион без да се подели на парчиња. (Забележете ја разликата во терминологијата. На пример, распоредувачот во Tupperware одговара на контролната табла во , а распределувачот на Tupperware се нарекува распоредувач во Kubernetes.)
- Брокерот за ресурси го складира изворот на вистината за настаните на серверот и услугата. Ние работиме по еден посредник за ресурси за секој центар за податоци и тој ги складира сите информации за серверите во тој центар за податоци. Брокерот за ресурси и системот за управување со капацитет, или системот за обезбедување ресурси, динамично одлучуваат кој распоредувач за испорака контролира кој сервер. Услугата за здравствена проверка ги следи серверите и складира податоци за нивното здравје во брокерот за ресурси. Ако серверот има проблеми или има потреба од одржување, брокерот за ресурси им кажува на алокаторот и распоредувачот да ги запрат контејнерите или да ги преместат на други сервери.
- Агентот Tupperware е демон кој работи на секој сервер кој се справува со обезбедување и отстранување на контејнери. Апликациите работат во контејнер, што им дава поголема изолација и репродуктивност. На Веќе опишавме како се создаваат поединечни контејнери на Tupperware користејќи слики, btrfs, cgroupv2 и systemd.
Карактеристични карактеристики на Tupperware
Tupperware е сличен на многу начини со другите системи за управување со кластери како што се Kubernetes и , но има и разлики:
- Вградена поддршка за државни услуги.
- Единствена контролна табла за сервери во различни центри за податоци за автоматизирање на испораката на контејнерите врз основа на намерата, деактивирање на кластерите и одржување.
- Исчистете ја поделбата на контролната табла за зумирање.
- Еластичното пресметување ви овозможува да ја дистрибуирате енергијата помеѓу услугите во реално време.
Ги развивме овие интересни функции за поддршка на различни апликации без државјанство и државјанство низ огромната глобална флота на споделени сервери.
Вградена поддршка за државни услуги.
Tupperware работи со различни критични државни услуги кои складираат постојани податоци за производите за Facebook, Instagram, Messenger и WhatsApp. Овие би можеле да бидат големи складишта на парови клуч-вредност (на пр. ) и следење на складишта на податоци (на пример, и ). Одржувањето на државните услуги не е лесно, бидејќи системот мора да осигура дека снабдувањето со контејнери може да издржи пречки од големи размери, вклучително и прекини на мрежата или прекини на струја. И додека конвенционалните техники, како што е дистрибуција на контејнери низ домени со дефекти, добро функционираат за услугите без државјанство, на услугите со државјанство им е потребна дополнителна поддршка.
На пример, ако неуспехот на серверот направи една реплика на базата на податоци недостапна, дали треба да овозможите автоматско одржување што ќе ги ажурира јадрата на 50 сервери од базен од 10? Зависи од ситуацијата. Ако еден од овие 50 сервери има друга реплика на истата база на податоци, подобро е да почекате и да не изгубите 2 реплики одеднаш. Со цел динамично да донесуваме одлуки за одржување и перформанси на системот, потребни ни се информации за внатрешната репликација на податоците и логиката на поставување на секоја услуга со статус.
Интерфејсот TaskControl им овозможува на државните услуги да влијаат на одлуките што влијаат на достапноста на податоците. Користејќи го овој интерфејс, распоредувачот ги известува надворешните апликации за операциите на контејнерите (рестартирање, ажурирање, миграција, одржување). Услугата со статус имплементира контролер кој му кажува на Tupperware кога е безбедно да се изврши секоја операција и овие операции може да се заменат или привремено да се одложат. Во примерот погоре, контролорот на базата на податоци може да му каже на Tupperware да ажурира 49 од 50-те сервери, но засега да остави сам одреден сервер (X). Како резултат на тоа, ако периодот на ажурирање на јадрото помине и базата на податоци сè уште не може да ја врати проблематичната реплика, Tupperware сè уште ќе го ажурира серверот X.
Многу државни услуги во Tupperware користат TaskControl не директно, туку преку ShardManager, заедничка платформа за креирање државни услуги на Facebook. Со Tupperware, програмерите можат да ја специфицираат нивната намера за точно како контејнерите треба да се дистрибуираат низ центрите за податоци. Со ShardManager, програмерите ја одредуваат нивната намера за тоа како деловите на податоците треба да се дистрибуираат низ контејнерите. ShardManager е свесен за поставувањето податоци и репликацијата на неговите апликации и комуницира со Tupperware преку интерфејсот TaskControl за да закаже операции со контејнери без директно вклучување на апликацијата. Оваа интеграција во голема мера го поедноставува управувањето со државните услуги, но TaskControl е способен за повеќе. На пример, нашиот обемен веб-ниво е без државјанство и користи TaskControl за динамичко прилагодување на стапката на ажурирања на контејнерите. На крајот дневно без да се загрози достапноста.
Управување со сервери во центри за податоци
Кога Tupperware првпат беше лансиран во 2011 година, секој кластер на сервери беше управуван од посебен распоредувач. Тогаш, кластерот на Фејсбук беше група серверски лавици поврзани со еден мрежен прекинувач, а центарот за податоци имаше неколку кластери. Распоредувачот може да управува само со сервери во еден кластер, што значи дека работата не може да се шири низ повеќе кластери. Нашата инфраструктура растеше, сè повеќе отпишувавме кластери. Бидејќи Tupperware не можеше да ја премести работата од деактивираниот кластер во други кластери без промени, бараше многу напор и внимателна координација помеѓу развивачите на апликации и операторите на центрите за податоци. Овој процес резултираше со потрошени ресурси кога серверите беа неактивен со месеци поради процедурите за деактивирање.
Создадовме посредник за ресурси за да го решиме проблемот со деактивирање на кластерот и да ги координираме другите видови задачи за одржување. Брокерот за ресурси ги следи сите физички информации поврзани со серверот и динамички одлучува кој распоредувач го контролира секој сервер. Динамичкото поврзување на серверите со распоредувачите му овозможува на распоредувачот да управува со серверите во различни центри за податоци. Бидејќи задачата на Tupperware повеќе не е ограничена на еден кластер, корисниците на Tupperware можат да наведат како контејнерите треба да се дистрибуираат низ домени со дефекти. На пример, програмер може да ја изјави својата намера (да речеме: „да ја стартувам мојата работа на 2 домени со дефекти во регионот PRN“) без да наведе конкретни зони за достапност. Самиот Tupperware ќе најде соодветни сервери за спроведување на оваа намера, дури и ако кластерот или услугата се деактивирани.
Скалабилни за поддршка на целиот глобален систем
Историски гледано, нашата инфраструктура е поделена на стотици посветени серверски базени за индивидуални тимови. Поради фрагментација и недостаток на стандарди, имавме високи оперативни трошоци, а серверите во мирување беа потешки за повторно користење. На минатогодишната конференција презентиравме , кој треба да ја обедини нашата инфраструктура во голем единствен серверски парк. Но, еден серверски парк има свои тешкотии. Мора да исполнува одредени барања:
- Приспособливост. Нашата инфраструктура растеше како што додававме центри за податоци во секој регион. Серверите станаа помали и енергетски поефикасни, така што ги има многу повеќе во секој регион. Како резултат на тоа, еден распоредувач по регион не може да се справи со бројот на контејнери што може да се извршуваат на стотици илјади сервери во секој регион.
- Сигурност. Дури и ако распоредувачот може да се зголеми толку многу, големиот опсег на распоредувачот значи дека постои поголем ризик од грешки и цел регион на контејнери може да стане неуправлив.
- Толеранција на грешки. Во случај на огромен дефект на инфраструктурата (на пример, серверите што работат со распоредувачот откажуваат поради дефект на мрежата или прекин на струја), негативните последици треба да влијаат само на дел од серверите во регионот.
- Лесно користење. Можеби изгледа дека треба да извршите неколку независни распоредувачи за еден регион. Но, од перспектива на погодност, една единствена точка за влез во заедничкиот базен на регионот го олеснува управувањето со капацитетот и работните места.
Го поделивме распоредувачот на парчиња за да ги решиме проблемите со одржување на голем заеднички базен. Секој дел од распоредувачот управува со својот сет на работни места во регионот, а тоа го намалува ризикот поврзан со распоредувачот. Како што расте заедничкиот базен, можеме да додадеме повеќе делови од распоредувачот. За корисниците на Tupperware, фрагментите и проксите на распоредувачот изгледаат како една контролна табла. Тие не мора да работат со еден куп парчиња кои оркестрираат задачи. Парчињата на распоредувачот се фундаментално различни од распоредувачите на кластери што ги користевме претходно, кога контролната табла беше поделена без статички да се дели споделениот базен на сервери според мрежната топологија.
Подобрете ја ефикасноста на користењето со Elastic Computing
Колку е поголема нашата инфраструктура, толку е поважно ефикасно да ги користиме нашите сервери за да ги оптимизираме трошоците за инфраструктура и да го намалиме оптоварувањето. Постојат два начини да се зголеми ефикасноста на користењето на серверот:
- Еластично пресметување - намалете ги онлајн услугите за време на мирни часови и користете ослободени сервери за офлајн оптоварувања, како што се машинското учење и работните места на MapReduce.
- Преоптоварување - Поставете онлајн услуги и сериски оптоварувања на истите сервери, така што сериските оптоварувања работат со низок приоритет.
Тесното грло во нашите центри за податоци е . Затоа, претпочитаме мали, енергетски ефикасни сервери кои заедно обезбедуваат поголема процесорска моќ. За жал, на мали сервери со мал процесор и меморија, преоптоварувањето е помалку ефикасно. Се разбира, можеме да поставиме неколку контејнери со мали услуги на еден мал енергетски ефикасен сервер кој троши малку процесорски ресурси и меморија, но големите услуги ќе имаат ниски перформанси во оваа ситуација. Затоа, ги советуваме развивачите на нашите големи услуги да ги оптимизираат за да ги користат сите сервери.
Во основа, ја подобруваме ефикасноста на користење користејќи еластично пресметување. Многу од нашите главни услуги, како што се Новости, функцијата за пораки и предниот веб-ниво, се разликуваат во зависност од времето од денот. Намерно ги намалуваме услугите на Интернет за време на мирни часови и користиме ослободени сервери за офлајн оптоварувања, како што се машинското учење и работните места на MapReduce.
Од искуство знаеме дека е најдобро да се обезбедат цели сервери како единици со еластичен капацитет бидејќи големите услуги се и главни донатори и главни потрошувачи на еластичен капацитет и се оптимизирани да користат цели сервери. Кога серверот е ослободен од онлајн услугата за време на мирни часови, брокерот за ресурси го закупува серверот на распоредувачот за да работи офлајн работни оптоварувања на него. Ако онлајн услугата доживее максимално оптоварување, брокерот за ресурси брзо го повикува позајмениот сервер и, заедно со распоредувачот, го враќа на онлајн услугата.
Научени лекции и планови за иднината
Во текот на изминатите 8 години, развивавме Tupperware за да бидеме во чекор со брзиот раст на Facebook. Го споделуваме она што го научивме и се надеваме дека ќе им помогне на другите да управуваат со инфраструктурите кои брзо се развиваат:
- Поставете флексибилна врска помеѓу контролната табла и серверите со кои управува. Оваа флексибилност му овозможува на контролната табла да управува со серверите во различни центри за податоци, помага да се автоматизира деактивирањето и одржувањето на кластерите и овозможува динамична распределба на капацитетот со помош на еластично пресметување.
- Со една контролна табла во регионот, станува поудобно да се работи со задачи и полесно да се управува со голема заедничка флота на сервери. Забележете дека контролната табла одржува една влезна точка, дури и ако нејзината внатрешна структура е одвоена поради скала или толеранција на дефекти.
- Користејќи модел на приклучок, контролната табла може да ги извести надворешните апликации за претстојните операции на контејнерот. Покрај тоа, државните услуги можат да го користат интерфејсот на приклучокот за да го приспособат управувањето со контејнери. Со овој модел на приклучок, контролната табла обезбедува едноставност додека ефикасно опслужува многу различни државни услуги.
- Ние веруваме дека еластичното пресметување, каде што одземаме цели сервери од донаторски услуги за сериски работи, машинско учење и други неитни услуги, е оптималниот начин за подобрување на ефикасноста на малите, енергетски ефикасни сервери.
Само што почнуваме да имплементираме . Во моментов околу 20% од нашите сервери се во заеднички базен. За да се постигне 100%, треба да се решат многу прашања, вклучително и одржување на заеднички базен за складирање, автоматизирање на одржување, управување со барањата меѓу закупците, подобрување на искористувањето на серверот и подобрување на поддршката за машинско учење. Едвај чекаме да ги преземеме овие предизвици и да ги споделиме нашите успеси.
Извор: www.habr.com