Čau Habr! Do pozornosti dávam preklad článku od Adiba Dawa.
Ak vám z tohto titulku neprebehne mráz po chrbte, mali by ste preskočiť na ďalší odsek alebo navštíviť našu stránku venovanú - radi by sme sa porozprávali.
Kto sme
Sme tím 4 tučniakov, ktorí milujú písanie kódu a prácu s hardvérom. Vo voľnom čase sme zodpovední za nasadenie, údržbu a prevádzku flotily viac ako 7000 3 fyzických serverov so systémom Linux, ktoré sú distribuované v XNUMX rôznych dátových centrách po celých Spojených štátoch.
Mali sme možnosť to urobiť aj 10 000 km od lokalít, z pohodlia našej vlastnej kancelárie, ktorá sa nachádza kúsok od pláže pri Stredozemnom mori.
Problémy s mierkou
Aj keď má zmysel, aby startup začal hosťovaním svojej infraštruktúry v cloude kvôli relatívne nízkej počiatočnej investícii, my v Outbrain sme sa rozhodli použiť vlastné servery. Urobili sme to preto, lebo náklady na cloudovú infraštruktúru vysoko prevyšujú náklady na prevádzku vlastných zariadení umiestnených v dátových centrách po vývoji na určitú úroveň. Okrem toho váš server poskytuje najvyšší stupeň kontroly a možností odstraňovania problémov.
Ako sa vyvíjame, problémy sú vždy nablízku. Navyše zvyčajne prichádzajú v skupinách. Správa životného cyklu servera si vyžaduje neustále sebazlepšovanie, aby mohol správne fungovať v kontexte rýchleho nárastu počtu serverov. Softvérové metódy na správu skupín serverov v dátových centrách sa rýchlo stávajú nepraktickými. Detekcia, odstraňovanie problémov a zmierňovanie zlyhaní pri plnení štandardov QoS sa stáva záležitosťou žonglovania s extrémne rôznorodými poľami hardvéru, meniacim sa pracovným zaťažením, termínmi upgradu a ďalšími peknými vecami, o ktoré sa nikto nechce starať.
Ovládnite svoje domény
Aby sme vyriešili mnohé z týchto problémov, rozdelili sme životný cyklus servera v Outbrain na jeho hlavné komponenty a nazvali sme ich domény. Napríklad jedna doména pokrýva požiadavky na vybavenie, ďalšia pokrýva logistiku súvisiacu so životným cyklom zásob a tretia pokrýva komunikáciu s terénnym personálom. Je tu ďalší, ktorý sa týka pozorovateľnosti hardvéru, ale nebudeme popisovať všetky body. Naším cieľom bolo študovať a definovať domény tak, aby ich bolo možné abstrahovať pomocou kódu. Po vytvorení pracovnej abstrakcie sa prenesie do manuálneho procesu, ktorý sa nasadí, otestuje a zdokonaľuje. Nakoniec je doména nakonfigurovaná tak, aby sa integrovala s inými doménami prostredníctvom rozhraní API, čím sa vytvorí holistický, dynamický a neustále sa vyvíjajúci systém životného cyklu hardvéru, ktorý je nasaditeľný, testovateľný a pozorovateľný. Rovnako ako všetky naše ostatné výrobné systémy.
Prijatie tohto prístupu nám umožnilo správne vyriešiť mnohé problémy – vytvorením nástrojov a automatizáciou.
Potrebujete doménu
Hoci e-mail a tabuľky boli v prvých dňoch životaschopným spôsobom, ako uspokojiť dopyt, nebolo to úspešné riešenie, najmä keď počet serverov a objem prichádzajúcich požiadaviek dosiahli určitú úroveň. Aby sme mohli lepšie organizovať a uprednostňovať prichádzajúce požiadavky vzhľadom na rýchlu expanziu, museli sme použiť systém predaja lístkov, ktorý by mohol ponúkať:
- Schopnosť prispôsobiť zobrazenie iba relevantných polí (jednoduché)
- Otvorené API (rozšíriteľné)
- Známy nášmu tímu (rozumej)
- Integrácia s našimi existujúcimi pracovnými postupmi (zjednotené)
Keďže Jira používame na riadenie našich sprintov a interných úloh, rozhodli sme sa vytvoriť ďalší projekt, ktorý by našim klientom pomohol zadávať lístky a sledovať ich výsledky. Použitie Jira na prichádzajúce požiadavky a na správu interných úloh nám umožnilo vytvoriť jedinú tabuľu Kanban, ktorá nám umožnila pozrieť sa na všetky procesy ako celok. Naši interní „klienti“ videli iba požiadavky na vybavenie bez toho, aby sa ponorili do menej podstatných detailov dodatočných úloh (ako je zlepšovanie nástrojov, oprava chýb).
Kanban board v Jira
Ako bonus skutočnosť, že fronty a priority boli teraz viditeľné pre každého, umožnila pochopiť, „kde v rade“ sa konkrétna požiadavka nachádza a čo jej predchádzalo. Vlastníkom to umožnilo prehodnotiť priority svojich vlastných požiadaviek bez toho, aby nás museli kontaktovať. Potiahnite a je to. Tiež nám to umožnilo monitorovať a vyhodnocovať naše zmluvy SLA podľa typov požiadaviek na základe metrík generovaných v Jira.
Doména životného cyklu zariadenia
Skúste si predstaviť zložitosť správy hardvéru používaného v každom serverovom stojane. Ešte horšie je, že veľa kusov hardvéru (RAM, ROM) je možné presunúť zo skladu do serverovej miestnosti a späť. Tiež zlyhajú alebo sú odpísané a vymenené a vrátené dodávateľovi na výmenu/opravu. Toto všetko treba oznámiť zamestnancom kolokačnej služby, ktorí sa podieľajú na fyzickej údržbe zariadenia. Na vyriešenie týchto problémov sme vytvorili interný nástroj s názvom Floppy. Jeho úlohou je:
- Riadenie komunikácie s terénnym personálom, agregácia všetkých informácií;
- Aktualizácia údajov „skladu“ po každej dokončenej a overenej údržbe zariadenia.
Sklad je zas vizualizovaný pomocou Grafany, ktorú používame na vykreslenie všetkých našich metrík. Rovnaký nástroj teda používame pre vizualizáciu skladu a pre iné potreby výroby.
Ovládací panel skladových zariadení v Grafane
Pre serverové zariadenia, ktoré sú v záruke, používame iný nástroj, ktorý nazývame Dispečer. On:
- Zhromažďuje systémové denníky;
- Generuje správy vo formáte požadovanom predajcom;
- Vytvorí požiadavku od dodávateľa cez API;
- Prijíma a ukladá identifikátor aplikácie na ďalšie sledovanie jej priebehu.
Po prijatí našej reklamácie (zvyčajne v rámci pracovných hodín) sa náhradný diel odošle do príslušného dátového centra a personál ho prijme.
Výstup konzoly Jenkins
Komunikačná doména
Aby sme udržali krok s rýchlym rastom nášho podnikania, ktoré si vyžaduje neustále sa zvyšujúcu kapacitu, museli sme prispôsobiť spôsob, akým spolupracujeme s technickými špecialistami v lokálnych dátových centrách. Ak najprv škálovanie znamenalo nákup nových serverov, tak po konsolidačnom projekte (na základe prechodu na Kubernetes) sa z toho stalo niečo úplne iné. Náš vývoj od „pridania stojanov“ k „zmene účelu serverov“.
Použitie nového prístupu si vyžiadalo aj nové nástroje, ktoré umožnili pohodlnejšiu interakciu s personálom dátového centra. Tieto nástroje boli potrebné na:
- jednoduchosť;
- autonómia;
- efektívnosť;
- Spoľahlivosť.
Museli sme sa vylúčiť z reťazca a štruktúrovať prácu tak, aby technici mohli priamo pracovať so serverovým zariadením. Bez nášho zásahu a bez pravidelného upozorňovania na všetky tieto problémy týkajúce sa pracovného zaťaženia, pracovného času, dostupnosti vybavenia atď.
Aby sme to dosiahli, nainštalovali sme iPady do každého dátového centra. Po pripojení k serveru sa stane nasledovné:
- Zariadenie potvrdí, že tento server skutočne vyžaduje nejakú prácu;
- Aplikácie bežiace na serveri sú zatvorené (ak je to potrebné);
- Sada pracovných pokynov je zverejnená na kanáli Slack s vysvetlením požadovaných krokov;
- Po dokončení práce zariadenie skontroluje správnosť konečného stavu servera;
- V prípade potreby reštartuje aplikácie.
Okrem toho sme technikovi pripravili aj Slack bota. Vďaka širokému spektru schopností (funkcionalitu sme neustále rozširovali) im robot uľahčil prácu a výrazne nám uľahčil život. Týmto spôsobom sme optimalizovali väčšinu procesu zmeny účelu a údržby serverov, čím sme sa vylúčili z pracovného toku.
iPad v jednom z našich dátových centier
Hardvérová doména
Spoľahlivé škálovanie infraštruktúry nášho dátového centra si vyžaduje dobrý prehľad o každom komponente, napríklad:
- Detekcia zlyhania hardvéru
- Stavy servera (aktívny, hosťovaný, zombie atď.)
- Spotreba energie
- Verzia firmvéru
- Analytics pre celú túto firmu
Naše riešenia nám umožňujú rozhodovať sa o tom, ako, kde a kedy nakúpiť vybavenie, niekedy dokonca skôr, ako bude skutočne potrebné. Stanovením úrovne zaťaženia rôznych zariadení sme tiež dokázali dosiahnuť lepšie prideľovanie zdrojov. Najmä spotreba energie. Teraz môžeme robiť informované rozhodnutia o umiestnení servera pred jeho inštaláciou do stojana a pripojením k zdroju napájania, počas jeho životného cyklu až do jeho prípadného vyradenia z prevádzky.
Energy Dashboard v Grafane
A potom sa objavil COVID-19...
Náš tím vytvára technológie, ktoré umožňujú mediálnym spoločnostiam a vydavateľom online pomáhať návštevníkom nájsť relevantný obsah, produkty a služby, ktoré by ich mohli zaujímať. Naša infraštruktúra je navrhnutá tak, aby slúžila návštevnosti generovanej pri zverejnení zaujímavých správ.
Intenzívne mediálne pokrytie okolo COVID-19 spolu s nárastom návštevnosti znamenali, že sme sa naliehavo potrebovali naučiť, ako tieto tlaky zvládať. Toto všetko sa navyše muselo robiť počas globálnej krízy, keď boli narušené dodávateľské reťazce a väčšina personálu bola doma.
Ale ako sme povedali, náš model už predpokladá, že:
- Zariadenia v našich dátových centrách sú pre nás väčšinou fyzicky nedostupné;
- Takmer všetku fyzickú prácu robíme na diaľku;
- Práca sa vykonáva asynchrónne, autonómne a vo veľkom meradle;
- Dopyt po zariadeniach uspokojujeme metódou „stavať z dielov“ namiesto nákupu nových zariadení;
- Máme sklad, ktorý nám umožňuje vytvárať niečo nové a nielen vykonávať bežné opravy.
Globálne obmedzenia, ktoré mnohým firmám bránili vo fyzickom prístupe do ich dátových centier, na nás teda nemali veľký vplyv a čo sa týka náhradných dielov a serverov, áno, snažili sme sa zabezpečiť stabilnú prevádzku zariadení. Bolo to však urobené s cieľom predísť možným incidentom, keď sa zrazu ukáže, že nejaký hardvér nie je k dispozícii. Zabezpečili sme naplnenie našich rezerv bez toho, aby sme sa snažili uspokojiť aktuálny dopyt.
V súhrne by som chcel povedať, že náš prístup k práci v odvetví dátových centier dokazuje, že je možné aplikovať princípy dobrého návrhu kódu na fyzickú správu dátového centra. A možno vás to bude zaujímať.
pôvodná:
Zdroj: hab.com