Hej Habr! Vašoj pozornosti predstavljam prijevod članka autor: Adib Daw.
Ako vam od naslova ne prođe lagana jeza, prijeđite na sljedeći odlomak ili posjetite našu stranicu posvećenu - htjeli bismo razgovarati.
Tko smo
Mi smo tim od 4 pingvina koji vole pisati kod i raditi s hardverom. U svoje slobodno vrijeme odgovorni smo za implementaciju, održavanje i upravljanje flotom od preko 7000 fizičkih poslužitelja koji pokreću Linux, raspoređenih u 3 različita podatkovna centra diljem Sjedinjenih Država.
Imali smo priliku to učiniti i 10 km od lokacija, iz udobnosti vlastitog ureda koji se nalazi nekoliko minuta vožnje od plaže na Sredozemnom moru.
Problemi razmjera
Iako ima smisla da startup započne s hostingom svoje infrastrukture u oblaku zbog relativno niske početne investicije, mi u Outbrainu odlučili smo koristiti vlastite poslužitelje. To smo učinili jer troškovi infrastrukture u oblaku daleko premašuju troškove rada vlastite opreme smještene u podatkovnim centrima nakon razvoja do određene razine. Osim toga, vaš poslužitelj pruža najviši stupanj kontrole i mogućnosti rješavanja problema.
Kako se razvijamo, problemi su uvijek u blizini. Štoviše, obično dolaze u skupinama. Upravljanje životnim ciklusom poslužitelja zahtijeva stalno samousavršavanje kako bi moglo pravilno funkcionirati u kontekstu brzog porasta broja poslužitelja. Softverske metode za upravljanje grupama poslužitelja u podatkovnim centrima brzo postaju nezgrapne. Otkrivanje, rješavanje problema i ublažavanje kvarova uz ispunjavanje QoS standarda postaje stvar žongliranja iznimno raznolikim nizovima hardvera, različitim radnim opterećenjima, rokovima nadogradnje i drugim lijepim stvarima o kojima nitko ne želi brinuti.
Ovladajte svojim domenama
Kako bismo riješili mnoge od ovih problema, rastavili smo životni ciklus poslužitelja u Outbrainu na njegove glavne komponente i nazvali ih domenama. Na primjer, jedna domena pokriva zahtjeve za opremom, druga pokriva logistiku povezanu sa životnim ciklusom inventara, a treća pokriva komunikaciju s osobljem na terenu. Postoji još jedan koji se tiče vidljivosti hardvera, ali nećemo opisivati sve točke. Naš je cilj bio proučiti i definirati domene kako bi se mogle apstrahirati pomoću koda. Nakon što se razvije radna apstrakcija, ona se prenosi u ručni proces koji se postavlja, testira i dorađuje. Konačno, domena je konfigurirana za integraciju s drugim domenama putem API-ja, tvoreći holistički, dinamički sustav životnog ciklusa hardvera koji se stalno razvija i koji se može implementirati, testirati i promatrati. Baš kao i svi drugi naši proizvodni sustavi.
Usvajanje ovog pristupa omogućilo nam je ispravno rješavanje mnogih problema - stvaranjem alata i automatizacije.
Potrebna domena
Iako su e-pošta i proračunske tablice bili održiv način da se zadovolji potražnja u ranim danima, to nije bilo uspješno rješenje, pogotovo kada su broj poslužitelja i količina dolaznih zahtjeva dosegli određenu razinu. Kako bismo bolje organizirali i odredili prioritet dolaznih zahtjeva u uvjetima brzog širenja, morali smo upotrijebiti sustav izdavanja ulaznica koji je mogao ponuditi:
- Mogućnost prilagodbe prikaza samo relevantnih polja (jednostavno)
- Otvoreni API-ji (proširivi)
- Poznat našem timu (razumije se)
- Integracija s našim postojećim tijekovima rada (objedinjeno)
Budući da koristimo Jira za upravljanje našim sprintovima i internim zadacima, odlučili smo stvoriti još jedan projekt koji bi pomogao našim klijentima da predaju karte i prate svoje rezultate. Korištenje Jire za dolazne zahtjeve i za upravljanje internim zadacima omogućilo nam je stvaranje jedne Kanban ploče koja nam je omogućila da sagledamo sve procese u cjelini. Naši interni “klijenti” vidjeli su samo zahtjeve za opremom, bez ulaženja u manje značajne detalje dodatnih zadataka (poput poboljšanja alata, ispravljanja grešaka).
Kanban ploča u Jiri
Kao bonus, činjenica da su redovi čekanja i prioriteti sada vidljivi svima omogućila je razumijevanje "gdje je u redu čekanja" određeni zahtjev i što mu je prethodilo. To je omogućilo vlasnicima da ponovno odrede prioritete vlastitih zahtjeva bez potrebe da nas kontaktiraju. Povuci i to je to. Također nam je omogućio praćenje i procjenu naših SLA-ova prema vrstama zahtjeva na temelju metrike generirane u Jiri.
Domena životnog ciklusa opreme
Pokušajte zamisliti složenost upravljanja hardverom koji se koristi u svakom stalku poslužitelja. Ono što je još gore je da se mnogi dijelovi hardvera (RAM, ROM) mogu premjestiti iz skladišta u server sobu i natrag. Oni također kvare ili se otpisuju i zamjenjuju te vraćaju dobavljaču na zamjenu/popravak. Sve ovo mora biti priopćeno djelatnicima colocation servisa uključenim u fizičko održavanje opreme. Kako bismo riješili te probleme, stvorili smo interni alat pod nazivom Floppy. Njegov zadatak je:
- Upravljanje komunikacijama s terenskim osobljem, prikupljanje svih informacija;
- Ažuriranje “skladišnih” podataka nakon svakog obavljenog i verificiranog posla održavanja opreme.
Skladište se pak vizualizira pomoću Grafane, koju koristimo za iscrtavanje svih naših metrika. Dakle, koristimo isti alat za vizualizaciju skladišta i za ostale proizvodne potrebe.
Centrala skladišne opreme u Grafani
Za poslužiteljske uređaje koji su pod jamstvom koristimo drugi alat koji zovemo Dispatcher. On:
- Prikuplja zapisnike sustava;
- Generira izvješća u formatu koji zahtijeva dobavljač;
- Kreira zahtjev od dobavljača putem API-ja;
- Prima i pohranjuje identifikator aplikacije za daljnje praćenje njezina napredovanja.
Nakon što je naš zahtjev prihvaćen (obično unutar radnog vremena), rezervni dio se šalje u odgovarajući podatkovni centar i prihvaća ga osoblje.
Izlaz Jenkinsove konzole
Komunikacijska domena
Kako bismo držali korak s brzim rastom našeg poslovanja, koji zahtijeva sve veći kapacitet, morali smo prilagoditi način na koji radimo s tehničkim stručnjacima u lokalnim podatkovnim centrima. Ako je u početku skaliranje značilo kupnju novih servera, da bi nakon projekta konsolidacije (temeljenog na prelasku na Kubernetes) postalo nešto sasvim drugo. Naša evolucija od "dodavanja polica" do "prenamjene poslužitelja".
Korištenje novog pristupa zahtijevalo je i nove alate koji su omogućili udobniju interakciju s osobljem podatkovnog centra. Ovi su alati bili potrebni za:
- Jednostavnost;
- Autonomija;
- Učinkovitost;
- Pouzdanost.
Morali smo se isključiti iz lanca i strukturirati posao tako da tehničari mogu direktno raditi sa serverskom opremom. Bez naše intervencije i bez redovitog postavljanja svih ovih pitanja u vezi s opterećenjem, radnim vremenom, dostupnošću opreme itd.
Kako bismo to postigli, instalirali smo iPade u svaki podatkovni centar. Nakon spajanja na poslužitelj dogodit će se sljedeće:
- Uređaj potvrđuje da ovaj poslužitelj doista zahtijeva određeni rad;
- Aplikacije koje se izvode na poslužitelju se zatvaraju (ako je potrebno);
- Skup radnih uputa objavljen je na Slack kanalu s objašnjenjem potrebnih koraka;
- Po završetku rada uređaj provjerava ispravnost konačnog stanja poslužitelja;
- Ponovno pokreće aplikacije ako je potrebno.
Osim toga, pripremili smo i Slack bot za pomoć tehničaru. Zahvaljujući širokom spektru mogućnosti (konstantno smo širili funkcionalnost), bot je njima olakšao rad, a nama uvelike olakšao život. Na taj smo način optimizirali većinu procesa prenamjene i održavanja poslužitelja, eliminirajući se iz tijeka rada.
iPad u jednom od naših podatkovnih centara
Domena hardvera
Pouzdano skaliranje infrastrukture našeg podatkovnog centra zahtijeva dobru vidljivost svake komponente, na primjer:
- Otkrivanje kvara hardvera
- Stanja poslužitelja (aktivan, hostiran, zombi itd.)
- Potrošnja energije
- Verzija firmvera
- Analitika za cijeli posao
Naša rješenja omogućuju nam donošenje odluka o tome kako, gdje i kada kupiti opremu, ponekad čak i prije nego što je stvarno potrebna. Također, utvrđivanjem razine opterećenja različite opreme, uspjeli smo postići poboljšanu raspodjelu resursa. Konkretno, potrošnja energije. Sada možemo donositi informirane odluke o postavljanju poslužitelja prije nego što se instalira u stalak i spoji na izvor napajanja, tijekom njegovog životnog ciklusa i do eventualnog povlačenja.
Energy Dashboard u Grafani
A onda se pojavio COVID-19...
Naš tim stvara tehnologije koje osnažuju medijske tvrtke i izdavače na mreži da pomognu posjetiteljima pronaći relevantan sadržaj, proizvode i usluge koji bi ih mogli zanimati. Naša infrastruktura osmišljena je da služi prometu koji se stvori kada se objave neke uzbudljive vijesti.
Intenzivna medijska pokrivenost vezana uz COVID-19, zajedno s povećanjem prometa, značila je da hitno moramo naučiti kako se nositi s tim pritiscima. Štoviše, sve se to moralo učiniti tijekom globalne krize, kada su lanci opskrbe bili prekinuti, a većina osoblja bila kod kuće.
Ali, kao što smo rekli, naš model već pretpostavlja da:
- Oprema u našim podatkovnim centrima većinom nam je fizički nedostupna;
- Gotovo sve fizičke poslove obavljamo na daljinu;
- Rad se izvodi asinkrono, autonomno i u velikom opsegu;
- Potražnju za opremom zadovoljavamo metodom "izgradi iz dijelova" umjesto kupnje nove opreme;
- Imamo skladište koje nam omogućuje stvaranje nečeg novog, a ne samo obavljanje rutinskih popravaka.
Stoga su globalna ograničenja koja su mnogim tvrtkama onemogućavala fizički pristup svojim podatkovnim centrima imala mali utjecaj na nas. A što se tiče rezervnih dijelova i poslužitelja, da, pokušali smo osigurati stabilan rad opreme. No, to je učinjeno s ciljem sprječavanja mogućih incidenata kada se iznenada pokaže da neki hardver nije dostupan. Osigurali smo da su naše rezerve popunjene bez cilja da zadovoljimo trenutnu potražnju.
Ukratko, želio bih reći da naš pristup radu u industriji podatkovnih centara dokazuje da je moguće primijeniti načela dobrog dizajna koda na fizičko upravljanje podatkovnim centrom. A možda će vam biti zanimljivo.
izvorna:
Izvor: www.habr.com