Эфектыўнае і надзейнае кіраванне кластарамі ў любым маштабе з Tupperware
сёння на мы прадставілі Tupperware - нашу сістэму кіравання кластарамі, якая аркеструе кантэйнеры на мільёнах сервераў, дзе працуюць амаль усе нашы сэрвісы. Упершыню мы разгарнулі Tupperware у 2011 г., і з тых часоў наша інфраструктура разраслася з да цэлых . Увесь гэты час Tupperware не стаяў на месцы і разьвіваўся разам з намі. Мы раскажам, у якіх сітуацыях Tupperware забяспечвае першакласнае кіраванне кластарамі, уключаючы зручную падтрымку stateful-сэрвісаў, адзіную панэль кіравання для ўсіх датацэнтраў і магчымасць размяркоўваць магутнасці паміж сэрвісамі ў рэальным часе. А яшчэ мы падзелімся ўрокамі, якія засвоілі па меры развіцця нашай інфраструктуры.
Tupperware выконвае розныя задачы. Распрацоўнікі прыкладанняў з яго дапамогай пастаўляюць прыкладанні і кіруюць імі. Ён пакуе код і залежнасці прыкладання ў выяву і пастаўляе яго на серверы ў выглядзе кантэйнераў. Кантэйнеры забяспечваюць ізаляцыю паміж праграмамі на адным серверы, каб распрацоўшчыкі займаліся логікай прыкладання і не думалі аб тым, як знайсці серверы або кантраляваць абнаўлення. А яшчэ Tupperware адсочвае працаздольнасць сервера, і калі знаходзіць збой, пераносіць кантэйнеры з праблемнага сервера.
Інжынеры па планаванні магутнасцяў з дапамогай Tupperware размяркоўваюць серверныя магутнасці па камандах у адпаведнасці з бюджэтам і абмежаваннямі. А яшчэ яны выкарыстоўваюць яго, каб павысіць эфектыўнасць выкарыстання сервераў. Аператары датацэнтраў звяртаюцца да Tupperware, каб правільна размеркаваць кантэйнеры па датацэнтрах і спыняць або перамяшчаць кантэйнеры на час тэхабслугоўвання. Дзякуючы гэтаму абслугоўванне сервераў, сеткі і абсталяванні патрабуе мінімальнага ўдзелу чалавека.
Архітэктура Tupperware
Архітэктура Tupperware PRN - гэта адзін з рэгіёнаў нашых датацэнтраў. Рэгіён складаецца з некалькіх будынкаў датацэнтраў (PRN1 і PRN2), размешчаных побач. Мы плануем зрабіць адну панэль кіравання, якая будзе кіраваць усімі серверамі ў адным рэгіёне.
Распрацоўнікі прыкладанняў пастаўляюць сэрвісы ў выглядзе заданняў Tupperware. Заданне складаецца з некалькіх кантэйнераў, і ўсе яны звычайна выконваюць адзін і той жа код дадатку.
Tupperware адказвае за вылучэнне кантэйнераў і кіраванне іх жыццёвым цыклам. Ён складаецца з некалькіх кампанентаў:
- Франтэнд Tupperware дае API для карыстацкага інтэрфейсу, CLI і іншых інструментаў аўтаматызацыі, праз якія можна ўзаемадзейнічаць з Tupperware. Яны хаваюць усю ўнутраную структуру ад уладальнікаў заданняў Tupperware.
- Планавальнік Tupperware - гэта панэль кіравання, адказная за кіраванне жыццёвым цыклам кантэйнера і заданні. Ён разгортваецца на рэгіянальным і глабальным узроўнях, дзе рэгіянальны планавальнік кіруе серверамі ў адным рэгіёне, а глабальны планавальнік кіруе серверамі з розных рэгіёнаў. Планавальнік падзелены на шарды, і кожны шард кіруе наборам заданняў.
- Проксі планавальніка ў Tupperware хавае ўнутраны падзел на шарды і дае зручную адзіную панэль кіравання карыстальнікам Tupperware.
- Размеркавальнік Tupperware прызначае кантэйнеры серверам. Прыпынкам, запускам, абнаўленнем і адпрацоўкай адмовы кантэйнераў займаецца планавальнік. У цяперашні час адзін размеркавальнік можа кіраваць усім рэгіёнам без падзелу на шарды. (Звярніце ўвагу на розніцу ў тэрміналогіі. Напрыклад, планавальнік у Tupperware адпавядае панэлі кіравання ў , а размеркавальнік Tupperware называецца ў Kubernetes планавальнікам.)
- Брокер рэсурсаў захоўвае крыніцу ісціны для сервера і падзей абслугоўвання. Мы запускаем адзін брокер рэсурсаў для кожнага датацэнтра, і ён захоўвае ўсе звесткі аб серверах у гэтым датацэнтры. Брокер рэсурсаў і сістэма кіравання магутнасцямі, ці сістэма вылучэння рэсурсаў, дынамічна вырашаюць, якая пастаўка планавальніка якім серверам кіруе. Сэрвіс праверкі працаздольнасці маніторыць серверы і захоўвае дадзеныя аб іх працаздольнасці ў брокеры рэсурсаў. Калі ў сервера праблемы ці ён мае патрэбу ў абслугоўванні, брокер рэсурсаў загадвае размеркавальніку і планавальніку спыніць кантэйнеры або перанесці іх на іншыя серверы.
- Агент Tupperware - гэта дэман, запушчаны на кожным серверы, які займаецца падрыхтоўкай і выдаленнем кантэйнераў. Прыкладанні працуюць усярэдзіне кантэйнера, што дае ім больш ізаляцыі і ўзнаўляльнасці. На мы ўжо апісвалі, як асобныя кантэйнеры Tupperware ствараюцца з дапамогай выяў, btrfs, cgroupv2 і systemd.
Адметныя асаблівасці Tupperware
Tupperware шмат у чым падобны на іншыя сістэмы кіравання кластарамі, напрыклад Kubernetes і , але ёсць і адрозненні:
- Убудаваная падтрымка stateful-сэрвісаў.
- Адзіная панэль кіравання для сервераў у розных датацэнтрах для аўтаматызацыі пастаўкі кантэйнераў зыходзячы з намеру, вываду кластараў з эксплуатацыі і абслугоўвання.
- Зразумелае падзел панэлі кіравання для павелічэння маштабу.
- Эластычныя вылічэнні дазваляюць размяркоўваць магутнасці паміж сэрвісамі ў рэальным часе.
Мы распрацавалі гэтыя класныя функцыі, каб падтрымліваць разнастайныя stateless-і stateful-прыкладанні ў вялізным глабальным агульным парку сервераў.
Убудаваная падтрымка stateful-севісаў.
Tupperware кіруе мноствам крытычных stateful-сэрвісаў, якія захоўваюць пастаянныя дадзеныя прадуктаў для Facebook, Instagram, Messenger і WhatsApp. Гэта могуць быць вялікія сховішчы пар «ключ-значэнне» (напрыклад, ) і сховішчы дадзеных маніторынгу (напрыклад, и ). Падтрымліваць stateful-сэрвісы няпроста, бо сістэма павінна гарантаваць, што пастаўкі кантэйнераў вытрымаюць буйнамаштабныя збоі, у тым ліку абрыў сеткі або адключэнне электрычнасці. І хоць звычайныя метады, напрыклад, размеркаванне кантэйнераў па даменах збою, добра падыходзяць для stateless-сэрвісаў, stateful-севісам патрэбна дадатковая падтрымка.
Напрыклад, калі ў выніку сервернага збою адна рэпліка базы дадзеных стане недаступная, ці трэба дазволіць аўтаматычнае абслугоўванне, якое абновіць ядры на 50 серверах з 10-тысячнага пула? Залежыць ад сытуацыі. Калі на адным з гэтых 50 сервераў ёсць яшчэ адна рэпліка той жа базы дадзеных, лепш пачакаць і не губляць адразу 2 рэплікі. Каб у дынамічным рэжыме прымаць рашэнні аб абслугоўванні і працаздольнасці сістэмы, патрэбны звесткі аб унутранай рэплікацыі дадзеных і логіцы размяшчэння кожнага stateful-сэрвісу.
Інтэрфейс TaskControl дазваляе stateful-сэрвісам уплываць на рашэнні, якія адаб'юцца на даступнасці дадзеных. З дапамогай гэтага інтэрфейсу планавальнік паведамляе знешнія прыкладанні аб аперацыях з кантэйнерам (перазапуск, абнаўленне, міграцыя, абслугоўванне). Stateful-сэрвіс рэалізуе кантролер, які паведамляе Tupperware, калі можна бяспечна выканаць кожную аперацыю, і гэтыя аперацыі можна мяняць месцамі або часова адкладаць. У прыведзеным вышэй прыкладзе кантролер базы дадзеных можа загадаць Tupperware абнавіць 49 з 50 сервераў, але пакуль не чапаць вызначаны сервер (X). У выніку, калі мінуе тэрмін абнаўлення ядра, а база дадзеных так і не зможа аднавіць праблемную рэпліку, Tupperware усё роўна абновіць сервер X.
Многія stateful-сэрвісы ў Tupperware выкарыстоўваюць TaskControl не напрамую, а праз ShardManager – распаўсюджаную платформу стварэння stateful-сэрвісаў на Facebook. З Tupperware распрацоўшчыкі могуць паказаць свой намер аб тым, як менавіта кантэйнеры павінны размяркоўвацца па датацэнтрам. З ShardManager распрацоўшчыкі паказваюць свой намер аб тым, як шарды дадзеных павінны размяркоўвацца па кантэйнерах. ShardManager ведае аб размяшчэнні дадзеных і рэплікацыі сваіх прыкладанняў і ўзаемадзейнічае з Tupperware праз інтэрфейс TaskControl, каб планаваць аперацыі з кантэйнерамі без прамога ўдзелу прыкладанняў. Гэтая інтэграцыя значна спрашчае кіраванне stateful-сэрвісамі, але TaskControl здольны на большае. Напрыклад, наш шырокі вэб-узровень з'яўляецца stateless і выкарыстоўвае TaskControl для дынамічнай карэкціроўкі хуткасці абнаўленняў у кантэйнерах. У выніку у дзень без шкоды для даступнасці.
Упраўленне серверамі ў датацэнтрах
Калі Tupperware толькі з'явіўся ў 2011 годзе, кожным кластарам сервера кіраваў асобны планавальнік. Тады кластарам Facebook была група серверных стоек, падлучаных да аднаго сеткавага камутатара, а датацэнтр мясціў некалькі кластараў. Планавальнік мог кіраваць серверамі толькі ў адным кластары, гэта значыць заданне не магло распаўсюджвацца на некалькі кластараў. Наша інфраструктура расла, мы ўсё гушчару спісвалі кластары. Раз Tupperware не мог без змен пераносіць заданне са спісванага кластара на іншыя кластары, патрабавалася шмат высілкаў і старанная каардынацыя паміж распрацоўнікамі прыкладанняў і аператарамі датацэнтра. Гэты працэс прыводзіў да марнай траты рэсурсаў, калі серверы месяцамі прастойвалі з-за працэдуры вываду з эксплуатацыі.
Мы стварылі брокер рэсурсаў, каб вырашыць праблему спісання кластараў і каардынаваць астатнія тыпы задач па абслугоўванні. Брокер рэсурсаў адсочвае ўсе фізічныя звесткі, злучаныя з серверам, і ў дынамічным рэжыме вырашае, які планавальнік кіруе кожным серверам. Дынамічная прывязка сервераў да планавальнікаў дазваляе планавальніку кіраваць серверамі ў розных датацэнтрах. Паколькі заданне Tupperware больш не абмежавана адным кластарам, карыстачы Tupperware могуць паказваць, як кантэйнеры павінны распаўсюджвацца па даменах збою. Напрыклад, распрацоўшчык можа абвясціць свой намер (дапусцім: "запусці маё заданне на 2 даменах збою ў рэгіёне PRN"), не паказваючы канкрэтныя зоны даступнасці. Tupperware сам знойдзе прыдатныя серверы, каб увасабляць гэты намер нават у выпадку спісання кластара або абслугоўвання.
Маштабаванне для падтрымкі ўсёй глабальнай сістэмы
Гістарычна склалася, што наша інфраструктура падзелена на сотні выдзеленых пулаў сервераў для асобных каманд. З-за фрагментацыі і адсутнасці стандартаў у нас былі высокія аперацыйныя выдаткі, а прастойваюць серверы было складаней зноў выкарыстоўваць. На леташняй канферэнцыі мы прадставілі , якая павінна аб'яднаць нашу інфраструктуру ў вялікай адзіны парк сервераў. Але ў адзінага парка сервераў свае складанасці. Ён павінен адпавядаць пэўным патрабаванням:
- Маштабаванасць. Наша інфраструктура расла па меры дадання датацэнтраў у кожны рэгіён. Серверы сталі меншыя і энергаэфектыўныя, таму ў кожным рэгіёне іх размясцілася значна больш. У выніку адзіны планавальнік на рэгіён не спраўляецца з той колькасцю кантэйнераў, якую можна запусціць на сотнях тысячах сервераў у кожным рэгіёне.
- Надзейнасць. Нават калі маштаб планавальніка можна настолькі павялічыць, з-за вялікай вобласці дзеяння планавальніка рызыка памылак будзе вышэй, і цэлы рэгіён кантэйнераў можа стаць некіравальным.
- Адмаўстойлівасць. У выпадку збою велізарнай інфраструктуры (напрыклад, з-за абрыву сеткі ці адключэнні электрычнасці адмовяць серверы, дзе запушчаны планавальнік) негатыўныя наступствы павінны закрануць толькі частку сервераў рэгіёна.
- Зручнасць выкарыстання. Можа падацца, што трэба запускаць некалькі незалежных планіроўшчыкаў на адзін рэгіён. Але з пункту гледжання зручнасці адзіны пункт уваходу ў агульны пул у рэгіёне спрашчае кіраванне магутнасцямі і заданнямі.
Мы падзялілі планавальнік на шарды, каб вырашаць праблемы з падтрымкай вялікага агульнага пула. Кожны шард планавальніка кіруе сваім наборам заданняў у рэгіёне, і гэта дазваляе зменшыць рызыку, злучаны з планавальнікам. Па меры росту агульнага пула мы можам дадаваць больш шардоў планавальніка. Для карыстальнікаў Tupperware шарды і проксі планавальніка выглядаюць як адна панэль кіравання. Ім не даводзіцца працаваць з кучай шардаў, якія аркеструюць заданні. Шарды планавальніка прынцыпова адрозніваюцца ад планавальнікаў кластараў, якія мы выкарыстоўвалі раней, калі панэль кіравання была падзелена без статычнага падзелу агульнага пула сервераў па тапалогіі сеткі.
Павышэнне эфектыўнасці выкарыстання з дапамогай эластычных вылічэнняў
Чым большая наша інфраструктура, тым важней эфектыўна выкарыстоўваць нашы серверы, каб аптымізаваць выдаткі на інфраструктуру і знізіць нагрузку. Павысіць эфектыўнасць выкарыстання сервераў можна двума спосабамі:
- Эластычныя вылічэнні - памяншаць маштаб анлайн-сэрвісаў у спакойныя гадзіны і выкарыстоўваць якія вызваліліся серверы для афлайн-нагрузак, напрыклад, для машыннага навучання і заданняў MapReduce.
- Празмерная загрузка - размяшчаць анлайн-сэрвісы і пакетныя працоўныя нагрузкі на адных серверах, каб пакетныя нагрузкі выконваліся з нізкім прыярытэтам.
Вузкае месца ў нашых датацэнтрах . Таму мы аддаем перавагу невялікія энергаэфектыўныя серверы, якія разам падаюць больш вылічальнай магутнасці. Нажаль, на маленькіх серверах з маленькім аб'ёмам працэсарных рэсурсаў і памяці празмерная загрузка меней эфектыўная. Вядома, мы можам размясціць на адным маленькім энергаэфектыўным серверы некалькі кантэйнераў маленькіх сэрвісаў, якія спажываюць мала працэсарных рэсурсаў і памяці, але ў вялікіх сэрвісаў у такой сітуацыі будзе нізкая прадукцыйнасць. Таму мы раім распрацоўнікам нашых вялікіх сэрвісаў аптымізаваць іх, каб яны выкарыстоўвалі серверы цалкам.
У асноўным, мы падвышаем эфектыўнасць выкарыстання з дапамогай эластычных вылічэнняў. Інтэнсіўнасць выкарыстання шматлікіх нашых буйных сэрвісаў, напрыклад, стужкі навін, функцыі паведамленняў і фронтэнд-вэб-ўзроўню, залежыць ад часу сутак. Мы наўмысна памяншаем маштаб анлайн-сэрвісаў у спакойныя гадзіны і выкарыстоўваем якія вызваліліся серверы для афлайн-нагрузак, напрыклад, для машыннага навучання і заданняў MapReduce.
Па досведзе мы ведаем, што лепш за ўсё падаваць цэлыя серверы ў якасці адзінак эластычнай магутнасці, таму што вялікія сэрвісы - гэта адначасова галоўныя донары і галоўныя спажыўцы эластычнай магутнасці, і яны аптымізаваныя для выкарыстання цэлых сервераў. Калі сервер вызваляецца ад анлайн-сэрвісу ў спакойныя гадзіны, брокер рэсурсаў аддае сервер у часавае карыстанне планавальніку, каб ён запускаў на ім афлайн-нагрузкі. Калі ў анлайн-сэрвісе ўзнікае пік нагрузкі, брокер рэсурсаў хутка адклікае пазычаны сервер і разам з планавальнікам вяртае яго анлайн-сэрвісу.
Засвоеныя ўрокі і планы на будучыню
У апошнія 8 гадоў мы разьвівалі Tupperware, каб не адставаць ад хуткага развіцця Facebook. Мы расказваем пра тое, чаму навучыліся, і спадзяемся, што гэта дапаможа іншым кіраваць хутка растучымі інфраструктурамі:
- Наладжвайце гнуткую сувязь паміж панэллю кіравання і серверамі, якімі яна кіруе. Гэтая гнуткасць дазваляе панэлі кіравання кіраваць серверамі ў розных датацэнтрах, дапамагае аўтаматызаваць спісанне і абслугоўванне кластараў і забяспечвае дынамічнае размеркаванне магутнасцяў з дапамогай эластычных вылічэнняў.
- З адзінай панэллю кіравання ў рэгіёне становіцца зручней працаваць з заданнямі і прасцей кіраваць буйным агульным паркам сервераў. Звярніце ўвагу, што панэль кіравання падтрымлівае адзіную кропку ўваходу, нават калі яе ўнутраная структура падзелена па меркаваннях маштабу або адмоваўстойлівасці.
- Выкарыстоўваючы мадэль плагіна, панэль кіравання можа апавяшчаць знешнія прыкладанні аб маючых адбыцца аперацыях з кантэйнерам. Больш за тое, stateful-сэрвісы могуць выкарыстоўваць інтэрфейс плагіна, каб наладжваць кіраванне кантэйнерам. З дапамогай такой мадэлі плагіна панэль кіравання забяспечвае прастату і пры гэтым эфектыўна абслугоўвае мноства розных stateful-сэрвісаў.
- Мы лічым, што эластычныя вылічэнні, пры якіх мы забіраем у донарскіх сэрвісаў цэлыя серверы для пакетных заданняў, машыннага навучання і іншых несрочных сэрвісаў, - гэта аптымальны спосаб павысіць эфектыўнасць выкарыстання маленькіх і энергаэфектыўных сервераў.
Мы яшчэ толькі прыступаем да рэалізацыі . Цяпер каля 20% нашых сервераў знаходзяцца ў агульным пуле. Каб дасягнуць 100%, трэба вырашыць мноства пытанняў, у тым ліку падтрымку агульнага пула для сістэм захоўвання, аўтаматызаванне абслугоўвання, кіраванне патрабаваннямі розных кліентаў, павышэнне эфектыўнасці выкарыстання сервераў і паляпшэнне падтрымкі працоўных нагрузак машыннага навучання. Нам не церпіцца ўзяцца за рашэнне гэтых задач і падзяліцца сваімі поспехамі.
Крыніца: habr.com