Efektivní a spolehlivá správa clusterů v jakémkoli měřítku s Tupperware
Dnes na představili jsme Tupperware, náš systém správy clusteru, který organizuje kontejnery na milionech serverů, na kterých běží téměř všechny naše služby. Tupperware jsme poprvé nasadili v roce 2011 a od té doby se naše infrastruktura rozrostla až do celku . Celou tu dobu Tupperware nestál na místě a vyvíjel se s námi. Ukážeme vám, jak Tupperware poskytuje prvotřídní správu clusteru, včetně pohodlné podpory stavových služeb, jediného ovládacího panelu pro všechna datová centra a schopnosti distribuovat kapacitu mezi služby v reálném čase. Budeme také sdílet lekce, které jsme se naučili, jak se naše infrastruktura vyvíjí.
Tupperware plní různé úkoly. Vývojáři aplikací jej používají k dodávání a správě aplikací. Zabalí kód aplikace a závislosti do obrazu a doručí jej na servery jako kontejnery. Kontejnery poskytují izolaci mezi aplikacemi na stejném serveru, takže se vývojáři vypořádají s aplikační logikou a nemusí se starat o hledání serverů nebo správu aktualizací. Tupperware také monitoruje výkon serveru, a pokud zjistí selhání, přenese kontejnery z problematického serveru.
Inženýři plánování kapacity používají Tupperware k přidělování kapacity serveru týmům na základě rozpočtu a omezení. Používají jej také ke zlepšení využití serveru. Operátoři datových center se obracejí na Tupperware, aby správně rozmístili kontejnery mezi datovými centry a zastavili nebo přesunuli kontejnery během údržby. Díky tomu údržba serverů, sítí a zařízení vyžaduje minimální lidské zásahy.
Architektura Tupperware
Architektura Tupperware PRN je jednou z oblastí našich datových center. Region se skládá z několika budov datových center (PRN1 a PRN2), které se nacházejí v blízkosti. Plánujeme vytvořit jeden ovládací panel, který bude spravovat všechny servery v jednom regionu.
Vývojáři aplikací poskytují služby ve formě úloh Tupperware. Úloha se skládá z více kontejnerů a všechny obvykle spouštějí stejný aplikační kód.
Tupperware je zodpovědný za poskytování kontejnerů a správu jejich životního cyklu. Skládá se z několika komponent:
- Frontend Tupperware poskytuje rozhraní API pro uživatelské rozhraní, CLI a další automatizační nástroje, pomocí kterých můžete komunikovat s Tupperware. Skrývají celou vnitřní strukturu před majiteli pracovních míst Tupperware.
- Tupperware Scheduler je ovládací panel zodpovědný za správu životního cyklu kontejneru a úlohy. Je nasazen na regionální a globální úrovni, kde regionální plánovač spravuje servery v jedné oblasti a globální plánovač spravuje servery z různých oblastí. Plánovač je rozdělen na fragmenty a každý fragment spravuje sadu úloh.
- Tupperware Scheduler Proxy skrývá vnitřní střepy a poskytuje uživatelům Tupperware pohodlnou jedinou skleněnou tabuli.
- Tupperware alokátor přiřazuje kontejnery k serverům. Plánovač zpracovává zastavování, spouštění, aktualizaci a převzetí služeb při selhání kontejnerů. V současné době může jeden alokátor spravovat celý region, aniž by se rozděloval na střepy. (Všimněte si rozdílu v terminologii. Například plánovač v Tupperware odpovídá ovládacímu panelu v a alokátor Tupperware se v Kubernetes nazývá plánovač.)
- Zprostředkovatel ukládá zdroj pravdy pro server a servisní události. Pro každé datové centrum provozujeme jednoho zprostředkovatele zdrojů a ten ukládá všechny informace o serverech v daném datovém centru. Zprostředkovatel zdrojů a systém správy kapacity nebo systém poskytování prostředků dynamicky rozhodují o tom, které doručování plánovače řídí který server. Služba kontroly stavu monitoruje servery a ukládá data o jejich stavu do zprostředkovatele prostředků. Pokud má server problémy nebo potřebuje údržbu, zprostředkovatel prostředků řekne alokátoru a plánovači, aby kontejnery zastavil nebo je přesunul na jiné servery.
- Tupperware Agent je démon běžící na každém serveru, který se stará o poskytování a odstraňování kontejnerů. Aplikace běží uvnitř kontejneru, což jim poskytuje větší izolaci a reprodukovatelnost. Na Již jsme popsali, jak se jednotlivé kontejnery Tupperware vytvářejí pomocí obrázků, btrfs, cgroupv2 a systemd.
Charakteristické rysy Tupperware
Tupperware je v mnoha ohledech podobný jiným systémům pro správu clusteru, jako je Kubernetes a , ale existují také rozdíly:
- Vestavěná podpora pro stavové služby.
- Jediný ovládací panel pro servery v různých datových centrech pro automatizaci doručování kontejnerů na základě záměru, vyřazení clusterů z provozu a údržby.
- Přehledné rozdělení ovládacího panelu pro zoomování.
- Elastické výpočty umožňují distribuovat energii mezi služby v reálném čase.
Vyvinuli jsme tyto skvělé funkce pro podporu různých bezstavových a stavových aplikací v rámci obrovské globální flotily sdílených serverů.
Vestavěná podpora pro stavové služby.
Tupperware provozuje řadu kritických stavových služeb, které ukládají trvalá produktová data pro Facebook, Instagram, Messenger a WhatsApp. Mohou to být velké úložiště párů klíč–hodnota (např. ) a monitorování datových úložišť (např. и ). Udržovat stavové služby není jednoduché, protože systém musí zajistit, aby zásobování kontejnerů odolalo rozsáhlým výpadkům včetně výpadků sítě nebo výpadku proudu. A zatímco konvenční techniky, jako je distribuce kontejnerů napříč doménami chyb, fungují dobře pro bezstavové služby, stavové služby potřebují další podporu.
Pokud například selhání serveru způsobí nedostupnost jedné repliky databáze, měli byste povolit automatickou údržbu, která aktualizuje jádra na 50 serverech z fondu 10 50? Záleží na situaci. Pokud má jeden z těchto 2 serverů další repliku stejné databáze, je lepší počkat a neztratit XNUMX repliky najednou. Abychom mohli dynamicky rozhodovat o údržbě a výkonu systému, potřebujeme informace o interní replikaci dat a logice umístění každé stavové služby.
Rozhraní TaskControl umožňuje stavovým službám ovlivňovat rozhodnutí, která ovlivňují dostupnost dat. Pomocí tohoto rozhraní plánovač upozorňuje externí aplikace na operace kontejneru (restart, aktualizace, migrace, údržba). Stavová služba implementuje řadič, který informuje Tupperware, kdy je bezpečné provést každou operaci, a tyto operace lze dočasně vyměnit nebo zpozdit. Ve výše uvedeném příkladu mohl databázový řadič říct Tupperware, aby aktualizoval 49 z 50 serverů, ale zatím nechal konkrétní server (X) na pokoji. V důsledku toho, pokud uplyne období aktualizace jádra a databáze stále není schopna obnovit problematickou repliku, Tupperware bude stále aktualizovat X server.
Mnoho stavových služeb v Tupperware nepoužívá TaskControl přímo, ale prostřednictvím ShardManager, společné platformy pro vytváření stavových služeb na Facebooku. S Tupperware mohou vývojáři přesně specifikovat svůj záměr, jak by měly být kontejnery distribuovány napříč datovými centry. Pomocí ShardManager vývojáři specifikují svůj záměr, jak by měly být datové fragmenty distribuovány mezi kontejnery. ShardManager si je vědom umístění dat a replikace svých aplikací a komunikuje s Tupperware prostřednictvím rozhraní TaskControl za účelem plánování operací kontejnerů bez přímého zapojení aplikací. Tato integrace značně zjednodušuje správu stavových služeb, ale TaskControl umí více. Například naše rozsáhlá webová vrstva je bezstavová a používá TaskControl k dynamickému přizpůsobení rychlosti aktualizací kontejnerů. Nakonec za den, aniž by byla ohrožena dostupnost.
Správa serverů v datových centrech
Když byl Tupperware poprvé uveden na trh v roce 2011, každý serverový cluster byl spravován samostatným plánovačem. Tehdy byl cluster Facebooku skupinou serverových racků připojených k jednomu síťovému přepínači a datové centrum obsahovalo několik clusterů. Plánovač mohl spravovat servery pouze v jednom clusteru, což znamená, že se úloha nemohla rozšířit do více clusterů. Naše infrastruktura rostla, stále více jsme odepisovali clustery. Protože Tupperware nemohl přesunout úlohu z vyřazeného clusteru do jiných clusterů beze změn, vyžadovalo to velké úsilí a pečlivou koordinaci mezi vývojáři aplikací a operátory datových center. Tento proces vedl k plýtvání zdroji, když byly servery celé měsíce nečinné kvůli procedurám vyřazování z provozu.
Vytvořili jsme zprostředkovatele zdrojů, abychom vyřešili problém vyřazování clusteru z provozu a koordinovali další typy úkolů údržby. Zprostředkovatel sleduje všechny fyzické informace spojené se serverem a dynamicky rozhoduje o tom, který plánovač řídí jednotlivé servery. Dynamické propojení serverů s plánovači umožňuje plánovači spravovat servery v různých datových centrech. Vzhledem k tomu, že úloha Tupperware již není omezena na jeden cluster, mohou uživatelé Tupperware určit, jak by měly být kontejnery distribuovány mezi doménami chyb. Vývojář může například deklarovat svůj záměr (řekněme: „spustit svou úlohu na 2 poruchových doménách v oblasti PRN“), aniž by specifikoval konkrétní zóny dostupnosti. Tupperware sám najde vhodné servery k realizaci tohoto záměru, i když bude cluster nebo služba vyřazena z provozu.
Škálovatelné pro podporu celého globálního systému
Historicky byla naše infrastruktura rozdělena do stovek vyhrazených serverových fondů pro jednotlivé týmy. Kvůli roztříštěnosti a nedostatku standardů jsme měli vysoké provozní náklady a nečinné servery bylo opět obtížnější používat. Na loňské konferenci představili jsme , který by měl sjednotit naši infrastrukturu do velkého jediného serverového parku. Ale jeden serverový park má své vlastní potíže. Musí splňovat určité požadavky:
- Škálovatelnost. Naše infrastruktura rostla, když jsme přidali datová centra v každém regionu. Servery se zmenšily a byly energeticky účinnější, takže jich je v každém regionu mnohem více. Výsledkem je, že jediný plánovač na oblast nemůže zvládnout počet kontejnerů, které lze spustit na stovkách tisíc serverů v každé oblasti.
- Spolehlivost. I když lze plánovač tak zvětšit, velký rozsah plánovače znamená, že existuje vyšší riziko chyb a celá oblast kontejnerů by se mohla stát neovladatelnou.
- Odolnost proti chybám. V případě velkého selhání infrastruktury (například selhání serverů s plánovačem kvůli selhání sítě nebo výpadku napájení) by negativní důsledky měly postihnout pouze část serverů v regionu.
- Snadné použití. Může se zdát, že potřebujete spustit několik nezávislých plánovačů pro jednu oblast. Z hlediska pohodlí však jediný vstupní bod do sdíleného fondu regionu usnadňuje správu kapacity a úloh.
Rozdělili jsme plánovač na části, abychom vyřešili problémy s údržbou velkého sdíleného fondu. Každý fragment plánovače spravuje vlastní sadu úloh v regionu, což snižuje riziko spojené s plánovačem. Jak se sdílený fond rozrůstá, můžeme přidávat další fragmenty plánovače. Pro uživatele Tupperware vypadají úlomky a proxy servery jako jeden ovládací panel. Nemusí pracovat s hromadou úlomků, které organizují úkoly. Shardy plánovače se zásadně liší od plánovačů clusterů, které jsme používali dříve, kdy byl ovládací panel rozdělen bez statického rozdělení sdíleného fondu serverů podle topologie sítě.
Zlepšete efektivitu využití pomocí Elastic Computing
Čím větší máme infrastrukturu, tím důležitější je efektivně využívat naše servery k optimalizaci nákladů na infrastrukturu a snížení zátěže. Existují dva způsoby, jak zvýšit efektivitu používání serveru:
- Elastické výpočty – omezte online služby během klidových hodin a používejte uvolněné servery pro offline pracovní zátěž, jako je strojové učení a úlohy MapReduce.
- Přetížení – umístěte online služby a dávkové úlohy na stejné servery, aby se dávkové úlohy spouštěly s nízkou prioritou.
Úzké místo v našich datových centrech je . Proto dáváme přednost malým, energeticky účinným serverům, které společně poskytují vyšší výpočetní výkon. Bohužel na malých serverech s malým CPU a pamětí je přetížení méně efektivní. Samozřejmě můžeme umístit několik kontejnerů malých služeb na jeden malý energeticky účinný server, který spotřebuje málo procesorových zdrojů a paměti, ale velké služby budou mít v této situaci nízký výkon. Proto vývojářům našich velkých služeb doporučujeme optimalizovat je tak, aby využívali celé servery.
V zásadě zlepšujeme efektivitu využití pomocí elastického počítání. Mnoho našich hlavních služeb, jako je zdroj zpráv, funkce zasílání zpráv a front-endová webová vrstva, se liší v závislosti na denní době. Záměrně omezujeme online služby během klidových hodin a využíváme uvolněné servery pro offline pracovní zátěž, jako je strojové učení a úlohy MapReduce.
Ze zkušenosti víme, že je nejlepší poskytovat celé servery jako jednotky elastické kapacity, protože velké služby jsou jak hlavními dárci, tak hlavními spotřebiteli elastické kapacity a jsou optimalizovány pro použití celých serverů. Když je server uvolněn ze služby online během klidových hodin, zprostředkovatel zdrojů pronajme server plánovači, aby na něm spouštěl offline úlohy. Pokud online služba zaznamená špičkové zatížení, zprostředkovatel zdrojů rychle vyvolá vypůjčený server a spolu s plánovačem jej vrátí online službě.
Poučení a plány do budoucna
Během posledních 8 let jsme vyvíjeli Tupperware, abychom drželi krok s rychlým růstem Facebooku. Sdílíme, co jsme se naučili, a doufáme, že to pomůže ostatním spravovat rychle rostoucí infrastruktury:
- Nastavte flexibilní spojení mezi ovládacím panelem a servery, které spravuje. Tato flexibilita umožňuje ovládacímu panelu spravovat servery v různých datových centrech, pomáhá automatizovat vyřazování z provozu a údržbu clusterů a umožňuje dynamické přidělování kapacity pomocí elastických výpočtů.
- S jediným ovládacím panelem v regionu je práce s úkoly pohodlnější a správa velké flotily sdílených serverů je snadnější. Všimněte si, že ústředna si zachovává jeden vstupní bod, i když je její vnitřní struktura oddělena z důvodu rozsahu nebo odolnosti proti chybám.
- Pomocí modelu pluginu může ovládací panel upozorňovat externí aplikace na nadcházející operace kontejnerů. Stavové služby navíc mohou používat rozhraní pluginu k přizpůsobení správy kontejnerů. S tímto modelem pluginu poskytuje ovládací panel jednoduchost a zároveň efektivně obsluhuje mnoho různých stavových služeb.
- Věříme, že elastické výpočty, kdy odebereme celé servery dárcovským službám pro dávkové úlohy, strojové učení a další služby, které nejsou naléhavé, je optimálním způsobem, jak zlepšit efektivitu malých, energeticky účinných serverů.
S realizací teprve začínáme . V současné době je asi 20 % našich serverů ve sdíleném fondu. Chcete-li dosáhnout 100 %, je třeba vyřešit mnoho problémů, včetně údržby sdíleného úložiště, automatizace údržby, správy požadavků mezi klienty, zlepšení využití serverů a zlepšení podpory pro úlohy strojového učení. Nemůžeme se dočkat, až přijmeme tyto výzvy a podělíme se o naše úspěchy.
Zdroj: www.habr.com