Efektívna a spoľahlivá správa klastrov v akomkoľvek rozsahu s Tupperware
Dnes na predstavili sme Tupperware, náš systém správy klastrov, ktorý organizuje kontajnery na miliónoch serverov, na ktorých bežia takmer všetky naše služby. Tupperware sme prvýkrát nasadili v roku 2011 a odvtedy sa naša infraštruktúra rozrástla do celku . Celý ten čas Tupperware nestál na mieste a vyvíjal sa s nami. Ukážeme vám, ako Tupperware poskytuje prvotriednu správu klastrov vrátane pohodlnej podpory stavových služieb, jediného ovládacieho panela pre všetky dátové centrá a možnosti distribúcie kapacity medzi službami v reálnom čase. Podelíme sa aj o ponaučenia, ktoré sme sa naučili pri vývoji našej infraštruktúry.
Tupperware vykonáva rôzne úlohy. Vývojári aplikácií ho používajú na poskytovanie a správu aplikácií. Balí kód aplikácie a závislosti do obrazu a dodáva ho na servery ako kontajnery. Kontajnery poskytujú izoláciu medzi aplikáciami na rovnakom serveri, takže vývojári riešia aplikačnú logiku a nemusia sa starať o hľadanie serverov alebo správu aktualizácií. Tupperware tiež monitoruje výkon servera a ak zistí poruchu, prenesie kontajnery z problematického servera.
Inžinieri plánovania kapacity používajú Tupperware na prideľovanie serverovej kapacity tímom na základe rozpočtu a obmedzení. Používajú ho aj na zlepšenie využitia servera. Operátori dátových centier sa obracajú na Tupperware, aby správne distribuovali kontajnery medzi dátovými centrami a zastavili alebo presunuli kontajnery počas údržby. Vďaka tomu si údržba serverov, sietí a zariadení vyžaduje minimálny zásah človeka.
Architektúra Tupperware
Architektúra Tupperware PRN je jedným z regiónov našich dátových centier. Región pozostáva z niekoľkých budov dátových centier (PRN1 a PRN2), ktoré sa nachádzajú v blízkosti. Plánujeme vytvoriť jeden ovládací panel, ktorý bude spravovať všetky servery v jednom regióne.
Vývojári aplikácií poskytujú služby vo forme úloh Tupperware. Úloha pozostáva z viacerých kontajnerov a všetky zvyčajne spúšťajú rovnaký aplikačný kód.
Tupperware je zodpovedný za poskytovanie kontajnerov a riadenie ich životného cyklu. Skladá sa z niekoľkých komponentov:
- Tupperware frontend poskytuje API pre užívateľské rozhranie, CLI a ďalšie automatizačné nástroje, prostredníctvom ktorých môžete komunikovať s Tupperware. Skrývajú celú vnútornú štruktúru pred majiteľmi pracovných miest Tupperware.
- Tupperware Scheduler je ovládací panel zodpovedný za správu kontajnera a životného cyklu úlohy. Je nasadený na regionálnej a globálnej úrovni, kde regionálny plánovač spravuje servery v jednom regióne a globálny plánovač spravuje servery z rôznych regiónov. Plánovač je rozdelený na časti a každá časť spravuje súbor úloh.
- Tupperware Scheduler Proxy skryje vnútorné črepy a poskytuje pohodlnú jednu tabuľu skla pre používateľov Tupperware.
- Tupperware alokátor priraďuje kontajnery k serverom. Plánovač sa stará o zastavenie, spustenie, aktualizáciu a núdzové prepnutie kontajnerov. V súčasnosti môže jeden alokátor spravovať celý región bez toho, aby sa rozdelil na črepiny. (Všimnite si rozdiel v terminológii. Napríklad plánovač v Tupperware zodpovedá ovládaciemu panelu v a alokátor Tupperware sa v Kubernetes nazýva plánovač.)
- Sprostredkovateľ zdrojov uchováva zdroj pravdy pre server a servisné udalosti. Pre každé dátové centrum prevádzkujeme jedného sprostredkovateľa zdrojov, ktorý ukladá všetky informácie o serveroch v tomto dátovom centre. Sprostredkovateľ prostriedkov a systém riadenia kapacity alebo systém poskytovania prostriedkov dynamicky rozhodujú, ktoré doručenie plánovača riadi ktorý server. Služba kontroly stavu monitoruje servery a ukladá údaje o ich stave v sprostredkovateľovi prostriedkov. Ak má server problémy alebo potrebuje údržbu, sprostredkovateľ zdrojov povie alokátorovi a plánovaču, aby zastavili kontajnery alebo ich presunuli na iné servery.
- Tupperware Agent je démon bežiaci na každom serveri, ktorý sa stará o poskytovanie a odstraňovanie kontajnerov. Aplikácie bežia vo vnútri kontajnera, čo im poskytuje väčšiu izoláciu a reprodukovateľnosť. Zapnuté Už sme opísali, ako sa jednotlivé kontajnery Tupperware vytvárajú pomocou obrázkov, btrfs, cgroupv2 a systemd.
Charakteristické črty Tupperware
Tupperware je v mnohých ohľadoch podobný iným systémom správy klastrov, ako sú Kubernetes a , ale sú tu aj rozdiely:
- Zabudovaná podpora pre stavové služby.
- Jediný ovládací panel pre servery v rôznych dátových centrách na automatizáciu doručovania kontajnerov na základe zámeru, vyradenia klastrov z prevádzky a údržby.
- Prehľadné rozdelenie ovládacieho panela pre zoomovanie.
- Elastické výpočty vám umožňujú rozdeliť výkon medzi služby v reálnom čase.
Tieto skvelé funkcie sme vyvinuli na podporu rôznych bezstavových a stavových aplikácií v rámci obrovskej globálnej flotily zdieľaných serverov.
Zabudovaná podpora pre stavové služby.
Tupperware prevádzkuje množstvo kritických stavových služieb, ktoré uchovávajú trvalé produktové dáta pre Facebook, Instagram, Messenger a WhatsApp. Môžu to byť veľké úložiská párov kľúč – hodnota (napr. ) a monitorovanie dátových úložísk (napr. и ). Udržiavanie stavových služieb nie je jednoduché, pretože systém musí zabezpečiť, aby zásobovanie kontajnerov odolalo rozsiahlym výpadkom vrátane výpadkov siete či výpadku elektriny. A zatiaľ čo konvenčné techniky, ako je distribúcia kontajnerov cez chybové domény, fungujú dobre pre služby bez stavu, stavové služby potrebujú ďalšiu podporu.
Ak napríklad zlyhanie servera spôsobí nedostupnosť jednej repliky databázy, mali by ste povoliť automatickú údržbu, ktorá aktualizuje jadrá na 50 serveroch z fondu 10 50? Závisí od situácie. Ak má jeden z týchto 2 serverov ďalšiu repliku tej istej databázy, je lepšie počkať a nestratiť XNUMX repliky naraz. Aby sme mohli dynamicky rozhodovať o údržbe a výkone systému, potrebujeme informácie o internej replikácii údajov a logike umiestnenia každej stavovej služby.
Rozhranie TaskControl umožňuje stavovým službám ovplyvňovať rozhodnutia, ktoré ovplyvňujú dostupnosť údajov. Pomocou tohto rozhrania plánovač upozorňuje externé aplikácie na operácie kontajnera (reštart, aktualizácia, migrácia, údržba). Stavová služba implementuje ovládač, ktorý informuje Tupperware, kedy je bezpečné vykonať každú operáciu, a tieto operácie je možné dočasne zameniť alebo odložiť. Vo vyššie uvedenom príklade by databázový kontrolér mohol povedať Tupperware, aby aktualizoval 49 z 50 serverov, ale zatiaľ nechal konkrétny server (X) na pokoji. V dôsledku toho, ak uplynie obdobie aktualizácie jadra a databáza stále nie je schopná obnoviť problematickú repliku, Tupperware bude stále aktualizovať X server.
Mnoho stavových služieb v Tupperware nepoužíva TaskControl priamo, ale prostredníctvom ShardManager, bežnej platformy na vytváranie stavových služieb na Facebooku. Pomocou Tupperware môžu vývojári presne špecifikovať svoj zámer, ako by mali byť kontajnery distribuované v dátových centrách. Pomocou ShardManager vývojári špecifikujú svoj zámer, ako by sa mali zlomky údajov distribuovať medzi kontajnermi. ShardManager si je vedomý umiestňovania údajov a replikácie svojich aplikácií a komunikuje s Tupperware cez rozhranie TaskControl, aby naplánoval operácie kontajnerov bez priameho zapojenia aplikácií. Táto integrácia výrazne zjednodušuje správu stavových služieb, ale TaskControl dokáže viac. Napríklad naša rozsiahla webová vrstva je bezstavová a používa TaskControl na dynamickú úpravu rýchlosti aktualizácií kontajnerov. Nakoniec za deň bez ohrozenia dostupnosti.
Správa serverov v dátových centrách
Pri prvom spustení Tupperware v roku 2011 bol každý serverový klaster riadený samostatným plánovačom. V tom čase bol klaster Facebooku skupinou serverových stojanov pripojených k jednému sieťovému prepínaču a dátové centrum obsahovalo niekoľko klastrov. Plánovač mohol spravovať servery iba v jednom klastri, čo znamená, že úloha sa nemohla rozšíriť medzi viacero klastrov. Naša infraštruktúra rástla, klastre sme čoraz viac odpisovali. Keďže Tupperware nemohol presunúť úlohu z vyradeného klastra do iných klastrov bez zmien, vyžadovalo si to veľa úsilia a starostlivú koordináciu medzi vývojármi aplikácií a operátormi dátových centier. Tento proces viedol k plytvaniu zdrojmi, keď boli servery celé mesiace nečinné v dôsledku postupov vyraďovania z prevádzky.
Vytvorili sme sprostredkovateľa zdrojov na vyriešenie problému vyraďovania klastra a koordináciu iných typov úloh údržby. Sprostredkovateľ zdrojov sleduje všetky fyzické informácie spojené so serverom a dynamicky rozhoduje o tom, ktorý plánovač riadi jednotlivé servery. Dynamické prepojenie serverov s plánovačmi umožňuje plánovaču spravovať servery v rôznych dátových centrách. Keďže úloha Tupperware už nie je obmedzená na jeden klaster, používatelia Tupperware môžu špecifikovať, ako by mali byť kontajnery distribuované v chybových doménach. Vývojár môže napríklad deklarovať svoj zámer (povedzme: „spustiť svoju prácu na 2 poruchových doménach v oblasti PRN“) bez špecifikovania konkrétnych zón dostupnosti. Tupperware sám nájde vhodné servery na realizáciu tohto zámeru, aj keď je klaster alebo služba vyradená z prevádzky.
Škálovateľné na podporu celého globálneho systému
Naša infraštruktúra bola v minulosti rozdelená do stoviek vyhradených serverových oblastí pre jednotlivé tímy. Z dôvodu fragmentácie a nedostatku štandardov sme mali vysoké prevádzkové náklady a nečinné servery bolo ťažšie znovu použiť. Na minuloročnej konferencii sme prezentovali , ktorý by mal zjednotiť našu infraštruktúru do jedného veľkého serverového parku. Ale jeden serverový park má svoje vlastné ťažkosti. Musí spĺňať určité požiadavky:
- Škálovateľnosť. Naša infraštruktúra rástla, keď sme pridávali dátové centrá v každom regióne. Servery sú menšie a energeticky efektívnejšie, takže ich je v každom regióne oveľa viac. V dôsledku toho jeden plánovač na región nedokáže spracovať počet kontajnerov, ktoré možno spustiť na stovkách tisíc serverov v každom regióne.
- Spoľahlivosť. Aj keď je možné plánovač tak zväčšiť, veľký rozsah plánovača znamená, že existuje vyššie riziko chýb a celá oblasť kontajnerov sa môže stať neovládateľnou.
- Odolnosť proti chybám. V prípade veľkého zlyhania infraštruktúry (napríklad zlyhanie serverov s plánovačom v dôsledku zlyhania siete alebo výpadku napájania) by negatívne dôsledky mali postihnúť iba časť serverov v regióne.
- Pohodlie použitia. Môže sa zdať, že potrebujete spustiť niekoľko nezávislých plánovačov pre jeden región. Z hľadiska pohodlia však jediný vstupný bod do zdieľaného fondu regiónu uľahčuje správu kapacity a pracovných miest.
Rozdelili sme plánovač na časti, aby sme vyriešili problémy s údržbou veľkého zdieľaného fondu. Každý zlomok plánovača spravuje svoj vlastný súbor úloh v regióne, čo znižuje riziko spojené s plánovačom. Ako sa zdieľaný fond rozrastá, môžeme pridať ďalšie zlomky plánovača. Pre používateľov Tupperware vyzerajú zlomky a servery proxy plánovača ako jeden ovládací panel. Nemusia pracovať s kopou črepín, ktoré organizujú úlohy. Črepy plánovača sa zásadne líšia od plánovačov klastrov, ktoré sme používali predtým, keď bol ovládací panel rozdelený bez statického rozdelenia zdieľanej oblasti serverov podľa topológie siete.
Zlepšite efektivitu používania pomocou elastickej výpočtovej techniky
Čím väčšia je naša infraštruktúra, tým dôležitejšie je efektívne využívať naše servery na optimalizáciu nákladov na infraštruktúru a zníženie zaťaženia. Existujú dva spôsoby, ako zvýšiť efektivitu používania servera:
- Elastické výpočty – znížte online služby počas tichých hodín a využite uvoľnené servery na offline pracovné zaťaženie, ako je strojové učenie a úlohy MapReduce.
- Preťaženie – Umiestnite online služby a dávkové pracovné zaťaženia na rovnaké servery, aby sa dávkové pracovné zaťaženia spúšťali s nízkou prioritou.
Prekážkou v našich dátových centrách je . Preto uprednostňujeme malé, energeticky úsporné servery, ktoré spolu poskytujú väčší výpočtový výkon. Bohužiaľ, na malých serveroch s malým CPU a pamäťou je preťaženie menej efektívne. Samozrejme, môžeme umiestniť niekoľko kontajnerov malých služieb na jeden malý energeticky efektívny server, ktorý spotrebuje málo procesorových zdrojov a pamäte, ale veľké služby budú mať v tejto situácii nízky výkon. Preto vývojárom našich veľkých služieb odporúčame optimalizovať ich tak, aby využívali celé servery.
V podstate zlepšujeme efektivitu používania pomocou elastického výpočtového systému. Mnohé z našich hlavných služieb, ako je informačný kanál, funkcia správ a front-endová webová vrstva, sa líšia v závislosti od dennej doby. Zámerne zmenšujeme online služby počas tichých hodín a využívame uvoľnené servery na offline pracovné zaťaženie, ako je strojové učenie a úlohy MapReduce.
Zo skúseností vieme, že najlepšie je poskytovať celé servery ako jednotky elastickej kapacity, pretože veľké služby sú hlavnými darcami aj hlavnými spotrebiteľmi elastickej kapacity a sú optimalizované na používanie celých serverov. Keď je server uvoľnený z online služby počas pokojných hodín, sprostredkovateľ zdrojov prenajme server plánovačovi, aby na ňom spúšťal offline pracovné zaťaženia. Ak online služba zaznamená vrchol zaťaženia, sprostredkovateľ zdrojov rýchlo vyvolá vypožičaný server a spolu s plánovačom ho vráti online službe.
Získané poznatky a plány do budúcnosti
Za posledných 8 rokov sme vyvíjali Tupperware, aby sme držali krok s rýchlym rastom Facebooku. Zdieľame to, čo sme sa naučili, a dúfame, že to pomôže ostatným spravovať rýchlo rastúce infraštruktúry:
- Nastavte flexibilné spojenie medzi ovládacím panelom a servermi, ktoré spravuje. Táto flexibilita umožňuje ovládaciemu panelu spravovať servery v rôznych dátových centrách, pomáha automatizovať vyraďovanie a údržbu klastrov a umožňuje dynamické prideľovanie kapacity pomocou elastických výpočtov.
- S jediným ovládacím panelom v regióne je práca s úlohami pohodlnejšia a správa veľkej flotily zdieľaných serverov je jednoduchšia. Všimnite si, že ústredňa si zachováva jeden vstupný bod, aj keď je jej vnútorná štruktúra oddelená z dôvodu rozsahu alebo odolnosti voči chybám.
- Pomocou modelu pluginu môže ovládací panel upozorňovať externé aplikácie na nadchádzajúce operácie kontajnera. Stavové služby môžu navyše použiť rozhranie doplnku na prispôsobenie správy kontajnerov. S týmto modelom pluginu poskytuje ovládací panel jednoduchosť a zároveň efektívne obsluhuje mnoho rôznych stavových služieb.
- Veríme, že elastická výpočtová technika, pri ktorej odoberáme celé servery darcovským službám pre dávkové úlohy, strojové učenie a ďalšie služby, ktoré nie sú urgentné, je optimálnym spôsobom, ako zlepšiť efektivitu malých, energeticky efektívnych serverov.
S realizáciou len začíname . V súčasnosti je asi 20 % našich serverov v zdieľanom fonde. Na dosiahnutie 100 % je potrebné vyriešiť mnoho problémov, vrátane údržby zdieľaného úložného priestoru, automatizácie údržby, správy požiadaviek medzi nájomníkmi, zlepšenia využitia servera a zlepšenia podpory pre úlohy strojového učenia. Už sa nevieme dočkať, kedy prijmeme tieto výzvy a podelíme sa o naše úspechy.
Zdroj: hab.com