Tere Habr! Esitan teie tähelepanu artikli tõlkele autor Adib Daw.
Kui see pealkiri ei tekita kerget külmavärinat, peaksite liikuma järgmise lõigu juurde või külastama meie lehte, mis on pühendatud - me tahaksime rääkida.
Kes me oleme
Oleme 4-liikmeline pingviini meeskond, kes armastab koodi kirjutamist ja riistvaraga töötamist. Vabal ajal vastutame enam kui 7000 füüsilisest serverist koosneva pargi juurutamise, hooldamise ja käitamise eest, kus töötab Linux ja mis on jaotatud kolmes erinevas andmekeskuses üle Ameerika Ühendriikide.
Meil oli ka võimalus seda teha 10 000 km kaugusel objektidest, mugavalt oma kontorist, mis asub Vahemere rannast lühikese autosõidu kaugusel.
Mastaabiprobleemid
Kuigi idufirmal on suhteliselt väikese alginvesteeringu tõttu mõistlik alustada oma infrastruktuuri pilves majutamisest, otsustasime Outbrainis kasutada oma servereid. Tegime seda seetõttu, et pilvetaristu kulud ületavad pärast teatud tasemeni arendust kõvasti meie enda andmekeskustes asuvate seadmete käitamise kulusid. Lisaks pakub teie server kõrgeimat juhtimis- ja tõrkeotsinguvõimalust.
Arenedes on probleemid alati lähedal. Pealegi tulevad nad tavaliselt rühmadena. Serverite elutsükli haldamine nõuab pidevat enesetäiendamist, et serverite arvu kiire kasvu tingimustes korralikult toimida. Andmekeskuste serverirühmade haldamise tarkvarameetodid muutuvad kiiresti kohmakaks. Rikete tuvastamine, tõrkeotsing ja nende leevendamine QoS-i standardite järgimisel muutub väga erinevate riistvaramassiivide, erineva töökoormuse, versiooniuuendusaegade ja muude toredate asjadega žongleerimiseks, mille pärast keegi ei taha muretseda.
Hallake oma domeene
Paljude nende probleemide lahendamiseks jagasime Outbrainis serveri elutsükli põhikomponentideks ja nimetasime need domeenideks. Näiteks üks domeen hõlmab nõudeid seadmetele, teine varude elutsükliga seotud logistikat ja kolmas suhtlust välipersonaliga. Riistvaralise jälgitavuse kohta on veel üks, kuid me ei kirjelda kõiki punkte. Meie eesmärk oli uurida ja defineerida domeene nii, et neid saaks koodi abil abstraheerida. Kui töötav abstraktsioon on välja töötatud, viiakse see üle käsitsi protsessi, mis võetakse kasutusele, testitakse ja täpsustatakse. Lõpuks on domeen konfigureeritud integreeruma teiste domeenidega API-de kaudu, moodustades tervikliku, dünaamilise ja pidevalt areneva riistvara elutsükli süsteemi, mis on juurutatav, testitav ja jälgitav. Täpselt nagu kõik teised meie tootmissüsteemid.
Selle lähenemisviisi kasutuselevõtt võimaldas meil palju probleeme õigesti lahendada – luues tööriistu ja automatiseerimist.
Vaja domeeni
Kuigi e-post ja tabelid olid algusaegadel mõistlikud viisid nõudluse rahuldamiseks, ei olnud see edukas lahendus, eriti kui serverite arv ja sissetulevate päringute maht jõudsid teatud tasemeni. Sissetulevate päringute paremaks korraldamiseks ja tähtsuse järjekorda seadmiseks kiire laienemise tingimustes pidime kasutama piletimüügisüsteemi, mis võiks pakkuda:
- Võimalus kohandada ainult asjakohaste väljade vaadet (lihtne)
- Avatud API-d (laiendatavad)
- Meie meeskonnale teada (arusaadav)
- Integratsioon meie olemasolevate töövoogudega (ühtne)
Kuna kasutame oma sprintide ja sisemiste ülesannete haldamiseks Jirat, otsustasime luua veel ühe projekti, mis aitaks meie klientidel pileteid esitada ja nende tulemusi jälgida. Jira kasutamine sissetulevate päringute jaoks ja sisemiste ülesannete haldamiseks võimaldas meil luua ühe Kanbani tahvli, mis võimaldas meil vaadata kõiki protsesse tervikuna. Meie sisemised "kliendid" nägid ainult seadmete taotlusi, süvenemata lisaülesannete vähem olulistesse üksikasjadesse (nt tööriistade täiustamine, vigade parandamine).
Kanbani tahvel Jiras
Boonusena oli see, et järjekorrad ja prioriteedid olid nüüd kõigile nähtavad, võimaldas aru saada, kus konkreetne päring asub ja mis sellele eelnes. See võimaldas omanikel oma taotluste prioriteete ümber seada, ilma et oleks pidanud meiega ühendust võtma. Lohistage ja ongi kõik. Samuti võimaldas see jälgida ja hinnata meie SLA-sid vastavalt päringutüüpidele, mis põhinevad Jiras loodud mõõdikutel.
Seadmete elutsükli domeen
Proovige ette kujutada igas serveririiulis kasutatava riistvara haldamise keerukust. Veelgi hullem on see, et paljusid riistvara tükke (RAM, ROM) saab laost serveriruumi teisaldada ja tagasi. Need ka ebaõnnestuvad või kantakse maha ja asendatakse ning tagastatakse tarnijale asendamiseks/parandamiseks. Kõigest sellest tuleb teavitada seadmete füüsilise hooldusega seotud kolokatsiooniteenistuse töötajaid. Nende probleemide lahendamiseks lõime sisemise tööriista nimega Floppy. Tema ülesanne on:
- Suhtluse juhtimine välipersonaliga, kogu teabe koondamine;
- "Lao" andmete värskendamine pärast iga lõpetatud ja kontrollitud seadmete hooldustööd.
Ladu omakorda visualiseeritakse Grafana abil, mille abil joonistame kõik oma mõõdikud. Seega kasutame sama tööriista lao visualiseerimiseks ja muudeks tootmisvajadusteks.
Laoseadmete juhtpult Grafanas
Garantii alla kuuluvate serveriseadmete puhul kasutame teist tööriista, mida kutsume Dispetšeriks. Ta:
- Kogub süsteemi logisid;
- Loob aruandeid hankija nõutud vormingus;
- Loob API kaudu päringu hankijalt;
- Võtab vastu ja salvestab rakenduse identifikaatori selle edenemise edasiseks jälgimiseks.
Kui meie nõue on vastu võetud (tavaliselt tööaja jooksul), saadetakse varuosa vastavasse andmekeskusesse ja töötajad võtavad selle vastu.
Jenkinsi konsooli väljund
Suhtlusdomeen
Et meie äritegevuse kiire kasvuga kaasas käia, mis nõuab järjest suuremat võimsust, tuli meil kohandada kohalike andmekeskuste tehniliste spetsialistidega koostööd. Kui algul tähendas skaleerimine uute serverite ostmist, siis peale konsolideerimisprojekti (Kubernetesile ülemineku alusel) sai sellest hoopis midagi muud. Meie areng alates "riiulite lisamisest" kuni "serverite ümberpaigutamiseni".
Uue lähenemise kasutamine nõudis ka uusi tööriistu, mis võimaldasid andmekeskuse töötajatega mugavamalt suhelda. Need tööriistad olid vajalikud:
- Lihtsus;
- autonoomia;
- Tõhusus;
- Töökindlus.
Pidime end ketist välja jätma ja töö struktureerima nii, et tehnikud saaksid otse serveriseadmetega töötada. Ilma meie sekkumiseta ja kõiki neid töökoormuse, töötundide, seadmete saadavuse jms probleeme regulaarselt tõstatamata.
Selle saavutamiseks paigaldasime igasse andmekeskusesse iPadid. Pärast serveriga ühenduse loomist toimub järgmine:
- Seade kinnitab, et see server nõuab tõepoolest tööd;
- Serveris töötavad rakendused on suletud (vajadusel);
- Slacki kanalile postitatakse tööjuhiste komplekt, mis selgitab vajalikke samme;
- Töö lõpetamisel kontrollib seade serveri lõppseisundi õigsust;
- Vajadusel taaskäivitab rakendused.
Lisaks valmistasime tehnikule abiks ka Slacki boti. Tänu paljudele võimalustele (täiendasime pidevalt funktsionaalsust) tegi bot nende töö lihtsamaks ja muutis meie elu palju lihtsamaks. Nii optimeerisime suurema osa serverite ümberpaigutamise ja hooldamise protsessist, eemaldades end töövoost.
iPad ühes meie andmekeskuses
Riistvara domeen
Meie andmekeskuse infrastruktuuri usaldusväärne skaleerimine nõuab iga komponendi head nähtavust, näiteks:
- Riistvara rikke tuvastamine
- Serveri olekud (aktiivne, hostitud, zombi jne)
- Energiatarbimine
- Püsivara versioon
- Kogu selle ettevõtte analüüs
Meie lahendused võimaldavad meil teha otsuseid selle kohta, kuidas, kust ja millal seadmeid osta, mõnikord isegi enne, kui seda tegelikult vaja läheb. Samuti suutsime erinevate seadmete koormuse taseme määramisega saavutada parema ressursside jaotuse. Eelkõige energiakulu. Nüüd saame teha teadlikke otsuseid serveri paigutuse kohta enne selle paigaldamist püstikusse ja toiteallikaga ühendamist kogu selle elutsükli ja kuni selle lõpliku kasutusest kõrvaldamiseni.
Energia armatuurlaud Grafanas
Ja siis ilmus COVID-19...
Meie meeskond loob tehnoloogiaid, mis võimaldavad meediaettevõtetel ja kirjastajatel veebis aidata külastajatel leida asjakohast sisu, tooteid ja teenuseid, mis võivad neile huvi pakkuda. Meie infrastruktuur on loodud liikluse teenindamiseks, mis tekib siis, kui avaldatakse põnevaid uudiseid.
COVID-19 ümbritsev intensiivne meediakajastus koos liikluse kasvuga tähendas, et meil oli kiiresti vaja õppida, kuidas selle survega toime tulla. Pealegi tuli seda kõike teha ülemaailmse kriisi ajal, mil tarneahelad olid häiritud ja suurem osa töötajatest oli kodus.
Kuid nagu me ütlesime, eeldab meie mudel juba järgmist:
- Meie andmekeskuste seadmed on meile enamasti füüsiliselt kättesaamatud;
- Peaaegu kõiki füüsilisi töid teeme eemalt;
- Tööd tehakse asünkroonselt, autonoomselt ja suures mahus;
- Nõudlust seadmete järele rahuldame uute seadmete ostmise asemel "ehitage osadest" meetodil;
- Meil on ladu, mis võimaldab meil luua midagi uut, mitte teha ainult rutiinset remonti.
Seega globaalsed piirangud, mis takistasid paljudel ettevõtetel oma andmekeskustele füüsilist juurdepääsu, ei mõjutanud meid vähe.Ja mis puudutab varuosasid ja servereid, siis jah, püüdsime tagada seadmete stabiilse töö. Aga seda tehti eesmärgiga ära hoida võimalikke intsidente, kui äkki selgub, et mõni riistvara pole saadaval. Tagasime, et meie reservid täidetakse, püüdmata rahuldada praegust nõudlust.
Kokkuvõtvalt tahan öelda, et meie lähenemine andmekeskuste tööstuses töötamisele tõestab, et andmekeskuse füüsilisel juhtimisel on võimalik rakendada hea koodikujunduse põhimõtteid. Ja võib-olla on see teile huvitav.
Originaal:
Allikas: www.habr.com