Përshëndetje, Habr! Unë paraqes në vëmendjen tuaj një përkthim të artikullit nga Adib Daw.
Nëse ky titull nuk ju bën të dridhet lehtë, duhet të kaloni te paragrafi tjetër ose të vizitoni faqen tonë të dedikuar për - do të donim të flisnim.
Kush jemi ne
Ne jemi një ekip prej 4 pinguinësh që duan të shkruajnë kode dhe të punojnë me pajisje. Në kohën tonë të lirë, ne jemi përgjegjës për vendosjen, mirëmbajtjen dhe funksionimin e një flote prej mbi 7000 serverësh fizikë që përdorin Linux, të shpërndarë në 3 qendra të ndryshme të të dhënave në të gjithë Shtetet e Bashkuara.
Ne patëm gjithashtu mundësinë për ta bërë këtë 10 km larg vendeve, nga komoditeti i zyrës sonë, e cila ndodhet pak me makinë nga plazhi në Detin Mesdhe.
Problemet e shkallës
Ndërsa ka kuptim që një startup të fillojë duke pritur infrastrukturën e tij në cloud për shkak të investimit fillestar relativisht të ulët, ne në Outbrain vendosëm të përdorim serverët tanë. Ne e bëmë këtë sepse kostot e infrastrukturës cloud tejkalojnë shumë kostot e funksionimit të pajisjeve tona të vendosura në qendrat e të dhënave pas zhvillimit në një nivel të caktuar. Përveç kësaj, serveri juaj ofron shkallën më të lartë të aftësive të kontrollit dhe zgjidhjes së problemeve.
Ndërsa zhvillojmë, problemet janë gjithmonë afër. Për më tepër, ata zakonisht vijnë në grupe. Menaxhimi i ciklit jetësor të serverit kërkon vetë-përmirësim të vazhdueshëm në mënyrë që të jetë në gjendje të funksionojë siç duhet në kontekstin e rritjes së shpejtë të numrit të serverëve. Metodat e softuerit për administrimin e grupeve të serverëve në qendrat e të dhënave bëhen shpejt të vështira. Zbulimi, zgjidhja e problemeve dhe zbutja e dështimeve gjatë përmbushjes së standardeve QoS bëhet një çështje e mashtrimit të grupeve jashtëzakonisht të ndryshme të pajisjeve, ngarkesave të ndryshme të punës, afateve të përmirësimit dhe gjërave të tjera të këndshme për të cilat askush nuk dëshiron të shqetësohet.
Zotëroni domenet tuaja
Për të zgjidhur shumë nga këto probleme, ne zbërthej ciklin e jetës së serverit në Outbrain në komponentët e tij kryesorë dhe i quajtëm domene. Për shembull, një fushë mbulon kërkesat e pajisjeve, një tjetër mbulon logjistikën që lidhet me ciklin e jetës së inventarit dhe një e treta mbulon komunikimet me personelin në terren. Ekziston një tjetër në lidhje me vëzhgimin e harduerit, por ne nuk do t'i përshkruajmë të gjitha pikat. Qëllimi ynë ishte të studiojmë dhe përcaktojmë domenet në mënyrë që ato të abstragohen duke përdorur kodin. Pasi të zhvillohet një abstraksion pune, ai transferohet në një proces manual që vendoset, testohet dhe rafinohet. Së fundi, domeni është konfiguruar për t'u integruar me domene të tjera nëpërmjet API-ve, duke formuar një sistem të ciklit të jetës së harduerit holistik, dinamik dhe gjithnjë në zhvillim, i cili është i vendosshëm, i testueshëm dhe i vëzhgueshëm. Ashtu si të gjitha sistemet tona të tjera të prodhimit.
Miratimi i kësaj qasje na lejoi të zgjidhim saktë shumë probleme - duke krijuar mjete dhe automatizim.
Nevojë për Domain
Megjithëse emaili dhe tabelat ishin një mënyrë praktike për të përmbushur kërkesën në ditët e para, nuk ishte një zgjidhje e suksesshme, veçanërisht kur numri i serverëve dhe vëllimi i kërkesave hyrëse arrinte një nivel të caktuar. Për të organizuar më mirë dhe për t'i dhënë përparësi kërkesave hyrëse përballë zgjerimit të shpejtë, na duhej të përdornim një sistem biletash që mund të ofronte:
- Aftësia për të personalizuar pamjen vetëm të fushave përkatëse (e thjeshtë)
- API-të e hapura (të zgjerueshme)
- I njohur për ekipin tonë (kuptohet)
- Integrimi me rrjedhat tona ekzistuese të punës (i unifikuar)
Meqenëse ne përdorim Jira për të menaxhuar sprintet dhe detyrat tona të brendshme, vendosëm të krijonim një projekt tjetër që do t'i ndihmonte klientët tanë të dorëzonin biletat dhe të gjurmonin rezultatet e tyre. Përdorimi i Jira për kërkesat hyrëse dhe për menaxhimin e detyrave të brendshme na lejoi të krijonim një bord të vetëm Kanban që na lejonte të shikonim të gjitha proceset në tërësi. "Klientët" tanë të brendshëm panë vetëm kërkesa për pajisje, pa u thelluar në detajet më pak të rëndësishme të detyrave shtesë (të tilla si përmirësimi i mjeteve, rregullimi i gabimeve).
Bordi Kanban në Jira
Si bonus, fakti që radhët dhe prioritetet ishin tashmë të dukshme për të gjithë, bëri të mundur të kuptonin "ku në radhë" ishte një kërkesë e veçantë dhe çfarë i parapriu. Kjo i lejoi pronarët të ripriorizonin kërkesat e tyre pa pasur nevojë të na kontaktojnë. Tërhiqeni dhe kaq. Gjithashtu na lejoi të monitoronim dhe vlerësonim SLA-të tona sipas llojeve të kërkesave bazuar në metrikat e krijuara në Jira.
Domeni i ciklit jetësor të pajisjeve
Mundohuni të imagjinoni kompleksitetin e menaxhimit të harduerit të përdorur në çdo raft serveri. Ajo që është edhe më e keqe është se shumë pjesë të harduerit (RAM, ROM) mund të zhvendosen nga depoja në dhomën e serverit dhe mbrapa. Ato gjithashtu dështojnë ose hiqen dhe zëvendësohen dhe kthehen te furnizuesi për zëvendësim/riparim. E gjithë kjo duhet t'i komunikohet punonjësve të shërbimit të kolokacionit të përfshirë në mirëmbajtjen fizike të pajisjeve. Për të zgjidhur këto probleme, ne krijuam një mjet të brendshëm të quajtur Floppy. Detyra e tij është:
- Menaxhimi i komunikimeve me personelin në terren, grumbullimi i të gjitha informacioneve;
- Përditësimi i të dhënave të "magazinës" pas çdo pune të përfunduar dhe të verifikuar të mirëmbajtjes së pajisjeve.
Magazina, nga ana tjetër, vizualizohet duke përdorur Grafana, të cilën ne e përdorim për të paraqitur të gjitha metrikat tona. Kështu, ne përdorim të njëjtin mjet për vizualizimin e magazinës dhe për nevoja të tjera të prodhimit.
Paneli i kontrollit të pajisjeve të magazinës në Grafanë
Për pajisjet server që janë nën garanci, ne përdorim një mjet tjetër që e quajmë Dispatcher. Ai:
- Mbledh regjistrat e sistemit;
- Gjeneron raporte në formatin e kërkuar nga shitësi;
- Krijon një kërkesë nga shitësi nëpërmjet API;
- Merr dhe ruan identifikuesin e aplikacionit për ndjekjen e mëtejshme të progresit të tij.
Pasi kërkesa jonë të pranohet (zakonisht brenda orarit të punës), pjesa rezervë dërgohet në qendrën e duhur të të dhënave dhe pranohet nga stafi.
Dalja e konsolës Jenkins
Domeni i komunikimit
Për të vazhduar me rritjen e shpejtë të biznesit tonë, i cili kërkon kapacitet gjithnjë në rritje, na u desh të përshtatnim mënyrën se si punojmë me specialistët teknikë në qendrat lokale të të dhënave. Nëse në fillim rritja nënkuptonte blerjen e serverëve të rinj, atëherë pas një projekti konsolidimi (bazuar në kalimin në Kubernetes) u bë diçka krejtësisht ndryshe. Evolucioni ynë nga "shtimi i rafteve" tek "ripërdorimi i serverëve".
Përdorimi i një qasjeje të re kërkonte gjithashtu mjete të reja që bënë të mundur ndërveprim më të qetë me personelin e qendrës së të dhënave. Këto mjete kërkoheshin për:
- Thjeshtësia;
- Autonomia;
- Efikasiteti;
- Besueshmëria.
Ne duhej të përjashtonim veten nga zinxhiri dhe të strukturonim punën në mënyrë që teknikët të mund të punonin drejtpërdrejt me pajisjet e serverit. Pa ndërhyrjen tonë dhe pa ngritur rregullisht të gjitha këto çështje në lidhje me ngarkesën, orarin e punës, disponueshmërinë e pajisjeve etj.
Për ta arritur këtë, ne instaluam iPad në çdo qendër të dhënash. Pas lidhjes me serverin, do të ndodhë si më poshtë:
- Pajisja konfirmon që ky server me të vërtetë kërkon punë;
- Aplikacionet që ekzekutohen në server mbyllen (nëse është e nevojshme);
- Një grup udhëzimesh pune është postuar në një kanal Slack duke shpjeguar hapat e kërkuar;
- Pas përfundimit të punës, pajisja kontrollon korrektësinë e gjendjes përfundimtare të serverit;
- Rinis aplikacionet nëse është e nevojshme.
Përveç kësaj, ne gjithashtu përgatitëm një bot Slack për të ndihmuar teknikun. Falë një game të gjerë aftësish (ne po zgjeronim vazhdimisht funksionalitetin), roboti ua lehtësoi punën dhe na e bëri jetën shumë më të lehtë. Në këtë mënyrë ne optimizuam pjesën më të madhe të procesit të ripërdorimit dhe mirëmbajtjes së serverëve, duke eleminuar veten nga rrjedha e punës.
iPad në një nga qendrat tona të të dhënave
Domeni i harduerit
Shkallëzimi i besueshëm i infrastrukturës sonë të qendrës së të dhënave kërkon shikueshmëri të mirë në secilin komponent, për shembull:
- Zbulimi i dështimit të harduerit
- Gjendjet e serverit (aktive, të pritura, zombie, etj.)
- Konsumi i energjisë
- Versioni i firmuerit
- Analiza për të gjithë këtë biznes
Zgjidhjet tona na lejojnë të marrim vendime se si, ku dhe kur të blejmë pajisje, ndonjëherë edhe para se të nevojiten realisht. Gjithashtu, duke përcaktuar nivelin e ngarkesës në pajisje të ndryshme, ne arritëm të arrijmë alokim të përmirësuar të burimeve. Në veçanti, konsumi i energjisë. Tani mund të marrim vendime të informuara për vendosjen e një serveri përpara se ai të instalohet në raft dhe të lidhet me një burim energjie, gjatë gjithë ciklit të tij jetësor dhe deri në daljen e tij në pension.
Paneli i Energjisë në Grafana
Dhe më pas u shfaq COVID-19...
Ekipi ynë krijon teknologji që fuqizojnë kompanitë e mediave dhe botuesit në internet për të ndihmuar vizitorët të gjejnë përmbajtje, produkte dhe shërbime përkatëse që mund të jenë me interes për ta. Infrastruktura jonë është krijuar për t'i shërbyer trafikut të krijuar kur publikohen disa lajme emocionuese.
Mbulimi intensiv i mediave rreth COVID-19, i shoqëruar me rritjen e trafikut, nënkuptonte se ne kishim nevojë urgjente për të mësuar se si t'i përballonim këto presione. Për më tepër, e gjithë kjo duhej të bëhej gjatë një krize globale, kur zinxhirët e furnizimit ishin ndërprerë dhe shumica e stafit ishte në shtëpi.
Por, siç thamë, modeli ynë tashmë supozon se:
- Pajisjet në qendrat tona të të dhënave janë, në pjesën më të madhe, fizikisht të paarritshme për ne;
- Pothuajse të gjitha punët fizike i bëjmë në distancë;
- Puna kryhet në mënyrë asinkrone, autonome dhe në shkallë të gjerë;
- Ne plotësojmë kërkesën për pajisje duke përdorur metodën "ndërtimi nga pjesët" në vend të blerjes së pajisjeve të reja;
- Ne kemi një depo që na lejon të krijojmë diçka të re, dhe jo vetëm të kryejmë riparime rutinë.
Kështu, kufizimet globale që penguan shumë kompani të fitonin akses fizik në qendrat e tyre të të dhënave kishin pak ndikim tek ne. Dhe sa i përket pjesëve rezervë dhe serverëve, po, ne u përpoqëm të siguronim funksionim të qëndrueshëm të pajisjeve. Por kjo është bërë me qëllim të parandalimit të incidenteve të mundshme kur papritur del se një pjesë e harduerit nuk është në dispozicion. Ne u siguruam që rezervat tona të mbusheshin pa synuar përmbushjen e kërkesës aktuale.
Si përmbledhje, do të doja të them se qasja jonë për të punuar në industrinë e qendrave të të dhënave dëshmon se është e mundur të zbatohen parimet e dizajnit të mirë të kodit në menaxhimin fizik të një qendre të dhënash. Dhe ndoshta do t'ju duket interesante.
origjinal:
Burimi: www.habr.com