Čau Habr! Předkládám vaší pozornosti překlad článku od Adiba Dawa.
Pokud vám z tohoto titulku neběhá mráz po zádech, měli byste přeskočit na další odstavec nebo navštívit naši stránku věnovanou - rádi bychom si promluvili.
Kdo jsme
Jsme tým 4 tučňáků, kteří milují psaní kódu a práci s hardwarem. Ve volném čase jsme zodpovědní za nasazení, údržbu a provoz flotily více než 7000 3 fyzických serverů se systémem Linux, které jsou distribuovány ve XNUMX různých datových centrech po celých Spojených státech.
Měli jsme také příležitost to udělat 10 000 km od míst, z pohodlí naší vlastní kanceláře, která se nachází kousek od pláže u Středozemního moře.
Problémy s měřítkem
Zatímco pro startup dává smysl začít hostováním své infrastruktury v cloudu kvůli relativně nízkým počátečním investicím, my v Outbrain jsme se rozhodli používat vlastní servery. Udělali jsme to proto, že náklady na cloudovou infrastrukturu výrazně převyšují náklady na provoz vlastního zařízení umístěného v datových centrech po vývoji na určitou úroveň. Kromě toho váš server poskytuje nejvyšší stupeň možností řízení a odstraňování problémů.
Jak se vyvíjíme, problémy jsou vždy nablízku. Navíc většinou přicházejí ve skupinách. Správa životního cyklu serveru vyžaduje neustálé sebezdokonalování, aby bylo možné správně fungovat v kontextu rychlého nárůstu počtu serverů. Softwarové metody pro správu skupin serverů v datových centrech se rychle stávají nepraktickými. Detekce, odstraňování problémů a zmírňování poruch při splnění standardů QoS se stává záležitostí žonglování s extrémně rozmanitým hardwarem, různým pracovním zatížením, dobou upgradu a dalšími pěknými věcmi, o které se nikdo nechce starat.
Ovládněte své domény
Abychom vyřešili mnoho z těchto problémů, rozdělili jsme životní cyklus serveru v Outbrain na jeho hlavní komponenty a nazvali jsme je domény. Jedna doména například pokrývá požadavky na vybavení, další pokrývá logistiku související s životním cyklem zásob a třetí pokrývá komunikaci s terénními pracovníky. Je tu ještě jeden, který se týká pozorovatelnosti hardwaru, ale nebudeme popisovat všechny body. Naším cílem bylo studovat a definovat domény tak, aby je bylo možné abstrahovat pomocí kódu. Jakmile je pracovní abstrakce vyvinuta, je převedena do ručního procesu, který je nasazen, testován a vylepšován. Nakonec je doména nakonfigurována tak, aby se integrovala s jinými doménami prostřednictvím rozhraní API a vytvořila holistický, dynamický a neustále se vyvíjející systém životního cyklu hardwaru, který je nasaditelný, testovatelný a pozorovatelný. Stejně jako všechny naše ostatní výrobní systémy.
Přijetí tohoto přístupu nám umožnilo vyřešit řadu problémů správně – vytvořením nástrojů a automatizací.
Potřebujete doménu
Přestože e-mail a tabulky byly v prvních dnech životaschopným způsobem, jak uspokojit poptávku, nebylo to úspěšné řešení, zvláště když počet serverů a objem příchozích požadavků dosáhl určité úrovně. Abychom mohli lépe organizovat a upřednostňovat příchozí požadavky tváří v tvář rychlé expanzi, museli jsme použít systém prodeje vstupenek, který by mohl nabídnout:
- Schopnost přizpůsobit zobrazení pouze relevantních polí (jednoduché)
- Otevřená rozhraní API (rozšiřitelná)
- Známý našemu týmu (rozumět)
- Integrace s našimi stávajícími pracovními postupy (sjednocené)
Vzhledem k tomu, že Jiru používáme ke správě našich sprintů a interních úkolů, rozhodli jsme se vytvořit další projekt, který by našim klientům pomohl zadávat vstupenky a sledovat jejich výsledky. Použití Jira pro příchozí požadavky a pro správu interních úkolů nám umožnilo vytvořit jedinou Kanban desku, která nám umožnila podívat se na všechny procesy jako na celek. Naši interní „klienti“ viděli pouze požadavky na vybavení, aniž by se zabývali méně významnými detaily dalších úkolů (jako je vylepšování nástrojů, oprava chyb).
Kanban deska v Jira
Jako bonus skutečnost, že fronty a priority byly nyní viditelné pro každého, umožnila pochopit, „kde ve frontě“ konkrétní požadavek byl a co mu předcházelo. To umožnilo vlastníkům změnit priority jejich vlastních požadavků, aniž by nás museli kontaktovat. Přetáhněte to a je to. Také nám to umožnilo monitorovat a vyhodnocovat naše SLA podle typů požadavků na základě metrik generovaných v Jira.
Doména životního cyklu zařízení
Zkuste si představit složitost správy hardwaru používaného v každém serverovém racku. Ještě horší je, že mnoho kusů hardwaru (RAM, ROM) lze přesunout ze skladu do serverové místnosti a zpět. Také selžou nebo jsou odepsány a nahrazeny a vráceny dodavateli k výměně/opravě. To vše musí být sděleno pracovníkům kolokační služby, kteří se podílejí na fyzické údržbě zařízení. K vyřešení těchto problémů jsme vytvořili interní nástroj nazvaný Floppy. Jeho úkolem je:
- Řízení komunikace s pracovníky v terénu, agregace všech informací;
- Aktualizace dat „skladu“ po každé dokončené a ověřené údržbě zařízení.
Sklad je zase vizualizován pomocí Grafany, kterou používáme k vykreslení všech našich metrik. Používáme tedy stejný nástroj pro vizualizaci skladu a pro další potřeby výroby.
Ovládací panel skladového zařízení v Grafaně
Pro serverová zařízení, která jsou v záruce, používáme jiný nástroj, který nazýváme Dispečer. On:
- Shromažďuje systémové protokoly;
- Generuje zprávy ve formátu požadovaném dodavatelem;
- Vytvoří požadavek od dodavatele přes API;
- Přijímá a ukládá identifikátor aplikace pro další sledování jejího průběhu.
Jakmile je naše reklamace přijata (obvykle v pracovní době), náhradní díl je odeslán do příslušného datového centra a přijat zaměstnanci.
Výstup konzole Jenkins
Komunikační doména
Abychom udrželi krok s rychlým růstem našeho podnikání, které vyžaduje stále rostoucí kapacitu, museli jsme přizpůsobit způsob spolupráce s technickými specialisty v místních datových centrech. Jestliže zpočátku škálování znamenalo nákup nových serverů, tak po konsolidačním projektu (na základě přechodu na Kubernetes) se z toho stalo něco úplně jiného. Náš vývoj od „přidávání stojanů“ k „přeměně použití serverů“.
Použití nového přístupu také vyžadovalo nové nástroje, které umožnily pohodlnější interakci s personálem datového centra. Tyto nástroje byly vyžadovány, aby:
- Jednoduchost;
- autonomie;
- Účinnost;
- Spolehlivost.
Museli jsme se vyloučit z řetězce a strukturovat práci tak, aby technici mohli přímo pracovat se serverovým zařízením. Bez našeho zásahu a bez pravidelného upozorňování na všechny tyto problémy týkající se pracovní zátěže, pracovní doby, dostupnosti vybavení atd.
Abychom toho dosáhli, nainstalovali jsme iPady do každého datového centra. Po připojení k serveru se stane následující:
- Zařízení potvrdí, že tento server skutečně vyžaduje nějakou práci;
- Aplikace běžící na serveru jsou uzavřeny (v případě potřeby);
- Sada pracovních pokynů je zveřejněna na kanálu Slack s vysvětlením požadovaných kroků;
- Po dokončení práce zařízení zkontroluje správnost konečného stavu serveru;
- V případě potřeby restartuje aplikace.
Kromě toho jsme také připravili robota Slack, který pomůže technikovi. Díky široké škále schopností (funkcionalitu jsme neustále rozšiřovali) jim robot usnadnil práci a výrazně nám usnadnil život. Tímto způsobem jsme optimalizovali většinu procesu změny účelu a údržby serverů, čímž jsme se vyloučili z pracovního postupu.
iPad v jednom z našich datových center
Hardwarová doména
Spolehlivé škálování naší infrastruktury datového centra vyžaduje dobrý přehled o každé komponentě, například:
- Detekce selhání hardwaru
- Stavy serveru (aktivní, hostovaný, zombie atd.)
- Spotřeba energie
- Verze firmwaru
- Analytics pro celou tuto firmu
Naše řešení nám umožňují rozhodovat o tom, jak, kde a kdy nakoupíme vybavení, někdy dokonce dříve, než je skutečně potřeba. Také stanovením úrovně zatížení různých zařízení jsme byli schopni dosáhnout lepší alokace zdrojů. Zejména spotřeba energie. Nyní můžeme činit informovaná rozhodnutí o umístění serveru před jeho instalací do stojanu a připojením ke zdroji napájení, po celou dobu jeho životního cyklu až do jeho případného vyřazení z provozu.
Energy Dashboard v Grafaně
A pak se objevil COVID-19...
Náš tým vytváří technologie, které umožňují mediálním společnostem a vydavatelům online pomáhat návštěvníkům najít relevantní obsah, produkty a služby, které by je mohly zajímat. Naše infrastruktura je navržena tak, aby obsluhovala provoz generovaný při zveřejnění zajímavých zpráv.
Intenzivní mediální pokrytí kolem COVID-19 spolu s nárůstem návštěvnosti znamenaly, že jsme se naléhavě potřebovali naučit, jak se s těmito tlaky vyrovnat. To vše se navíc muselo dělat během celosvětové krize, kdy byly narušeny dodavatelské řetězce a většina personálu byla doma.
Ale jak jsme řekli, náš model již předpokládá, že:
- Zařízení v našich datových centrech je pro nás z velké části fyzicky nedostupné;
- Téměř veškerou fyzickou práci děláme na dálku;
- Práce se provádí asynchronně, autonomně a ve velkém měřítku;
- Poptávku po vybavení uspokojujeme metodou „build from parts“ namísto nákupu nového vybavení;
- Máme sklad, který nám umožňuje vytvářet něco nového, a ne jen provádět běžné opravy.
Globální omezení, která mnoha společnostem bránila ve fyzickém přístupu do jejich datových center, na nás tedy měla jen malý dopad a co se týče náhradních dílů a serverů, ano, snažili jsme se zajistit stabilní provoz zařízení. Ale to bylo děláno s cílem předejít možným incidentům, když se náhle ukáže, že některý kus hardwaru není k dispozici. Zajistili jsme, aby naše rezervy byly naplněny, aniž bychom se snažili uspokojit aktuální poptávku.
V souhrnu bych rád řekl, že náš přístup k práci v odvětví datových center dokazuje, že je možné aplikovat principy dobrého návrhu kódu na fyzickou správu datového centra. A možná vás to bude zajímat.
Původní:
Zdroj: www.habr.com