Hei, Habr! Jeg presenterer for din oppmerksomhet en oversettelse av artikkelen av Adib Daw.
Hvis den overskriften ikke sender en liten skjelving nedover ryggraden din, bør du hoppe til neste avsnitt eller besøke siden vår dedikert til – Vi vil gjerne snakke.
Hvem er vi
Vi er et team på 4 pingviner som elsker å skrive kode og jobbe med maskinvare. På fritiden er vi ansvarlige for å distribuere, vedlikeholde og drifte en flåte på over 7000 fysiske servere som kjører Linux, fordelt på 3 forskjellige datasentre over hele USA.
Vi hadde også muligheten til å gjøre dette 10 000 km unna steder, fra komforten til vårt eget kontor, som ligger en kort kjøretur fra stranden ved Middelhavet.
Skalaproblemer
Selv om det er fornuftig for en oppstart å starte med å hoste sin infrastruktur i skyen på grunn av den relativt lave initialinvesteringen, bestemte vi oss i Outbrain for å bruke våre egne servere. Dette gjorde vi fordi kostnadene ved skyinfrastruktur langt overstiger kostnadene ved å drifte vårt eget utstyr plassert i datasentre etter utvikling til et visst nivå. I tillegg gir serveren den høyeste grad av kontroll og feilsøkingsmuligheter.
Når vi utvikler oss, er problemer alltid i nærheten. Dessuten kommer de vanligvis i grupper. Serverlivssyklusadministrasjon krever konstant selvforbedring for å kunne fungere skikkelig i sammenheng med den raske økningen i antall servere. Programvaremetoder for å administrere servergrupper i datasentre blir fort uhåndterlige. Å oppdage, feilsøke og redusere feil samtidig som de oppfyller QoS-standarder, blir et spørsmål om å sjonglere ekstremt varierte arrays av maskinvare, varierende arbeidsmengder, oppgraderingsfrister og andre fine ting som ingen vil bekymre seg for.
Mestre domenene dine
For å løse mange av disse problemene, delte vi ned serverlivssyklusen i Outbrain i hovedkomponentene og kalte dem domener. For eksempel dekker ett domene utstyrsbehov, et annet dekker logistikk knyttet til varelagerets livssyklus, og et tredje dekker kommunikasjon med feltpersonell. Det er en annen angående maskinvareobservabilitet, men vi vil ikke beskrive alle punktene. Målet vårt var å studere og definere domener slik at de kunne abstraheres ved hjelp av kode. Når en fungerende abstraksjon er utviklet, overføres den til en manuell prosess som distribueres, testes og foredles. Til slutt er domenet konfigurert til å integreres med andre domener via APIer, og danner et helhetlig, dynamisk og stadig utviklende maskinvarelivssyklussystem som er distribuerbart, testbart og observerbart. Akkurat som alle våre andre produksjonssystemer.
Ved å ta i bruk denne tilnærmingen kunne vi løse mange problemer riktig - ved å lage verktøy og automatisering.
Trenger domene
Selv om e-post og regneark var en levedyktig måte å møte etterspørselen på i de første dagene, var det ikke en vellykket løsning, spesielt når antall servere og volumet av innkommende forespørsler nådde et visst nivå. For bedre å organisere og prioritere innkommende forespørsler i møte med rask ekspansjon, måtte vi bruke et billettsystem som kunne tilby:
- Evne til å tilpasse visningen av kun relevante felt (enkelt)
- Åpne APIer (utvidbare)
- Kjent for teamet vårt (forstått)
- Integrasjon med våre eksisterende arbeidsflyter (samlet)
Siden vi bruker Jira til å administrere spurtene våre og interne oppgaver, bestemte vi oss for å lage et annet prosjekt som ville hjelpe kundene våre med å sende inn billetter og spore resultatene deres. Ved å bruke Jira for innkommende forespørsler og for å administrere interne oppgaver, kunne vi lage et enkelt Kanban-tavle som tillot oss å se på alle prosesser som en helhet. Våre interne "klienter" så bare forespørsler om utstyr, uten å dykke ned i de mindre viktige detaljene om tilleggsoppgaver (som å forbedre verktøy, fikse feil).
Kanban-styret i Jira
Som en bonus, det faktum at køer og prioriteringer nå var synlige for alle, gjorde det mulig å forstå "hvor i køen" en bestemt forespørsel var og hva som gikk foran den. Dette tillot eiere å omprioritere sine egne forespørsler uten å måtte kontakte oss. Dra det og det er det. Det tillot oss også å overvåke og evaluere SLAene våre i henhold til forespørselstyper basert på beregningene generert i Jira.
Utstyrs livssyklusdomene
Prøv å forestille deg kompleksiteten ved å administrere maskinvaren som brukes i hvert serverrack. Det som er enda verre er at mange deler av maskinvare (RAM, ROM) kan flyttes fra lageret til serverrommet og tilbake. De svikter også eller blir avskrevet og erstattet og returnert til leverandøren for utskifting/reparasjon. Alt dette må kommuniseres til de ansatte i samlokaliseringstjenesten som er involvert i det fysiske vedlikeholdet av utstyret. For å løse disse problemene laget vi et internt verktøy kalt Floppy. Hans oppgave er:
- Håndtering av kommunikasjon med feltpersonell, aggregering av all informasjon;
- Oppdatering av "lager"-data etter hver fullført og verifisert utstyrsvedlikeholdsjobb.
Lageret er på sin side visualisert ved hjelp av Grafana, som vi bruker til å plotte alle våre beregninger. Dermed bruker vi det samme verktøyet til lagervisualisering og til andre produksjonsbehov.
Kontrollpanel for lagerutstyr i Grafana
For serverenheter som er under garanti, bruker vi et annet verktøy vi kaller Dispatcher. Han:
- Samler systemlogger;
- Genererer rapporter i formatet som kreves av leverandøren;
- Oppretter en forespørsel fra leverandøren via API;
- Mottar og lagrer applikasjonsidentifikatoren for videre sporing av fremdriften.
Når kravet vårt er akseptert (vanligvis innen arbeidstiden), sendes reservedelen til det aktuelle datasenteret og godtas av personalet.
Jenkins konsoll utgang
Kommunikasjonsdomene
For å holde tritt med den raske veksten i virksomheten vår, som krever stadig økende kapasitet, måtte vi tilpasse måten vi jobber med tekniske spesialister i lokale datasentre. Hvis oppskalering først innebar å kjøpe nye servere, så ble det etter et konsolideringsprosjekt (basert på overgangen til Kubernetes) noe helt annet. Vår utvikling fra å «legge til rack» til å «gjenbruke servere».
Å bruke en ny tilnærming krevde også nye verktøy som gjorde det mulig å samhandle mer komfortabelt med datasenterpersonell. Disse verktøyene var nødvendig for å:
- Enkelhet;
- Autonomi;
- Effektivitet;
- Pålitelighet.
Vi måtte ekskludere oss selv fra kjeden og strukturere arbeidet slik at teknikere kunne jobbe direkte med serverutstyr. Uten vår intervensjon og uten regelmessig å ta opp alle disse spørsmålene angående arbeidsbelastning, arbeidstid, utstyrs tilgjengelighet, etc.
For å oppnå dette, installerte vi iPads i hvert datasenter. Etter tilkobling til serveren vil følgende skje:
- Enheten bekrefter at denne serveren faktisk krever litt arbeid;
- Applikasjoner som kjører på serveren lukkes (om nødvendig);
- Et sett med arbeidsinstruksjoner er lagt ut på en Slack-kanal som forklarer trinnene som kreves;
- Når arbeidet er fullført, kontrollerer enheten riktigheten av den endelige tilstanden til serveren;
- Starter programmer på nytt om nødvendig.
I tillegg har vi også utarbeidet en Slack-bot for å hjelpe teknikeren. Takket være et bredt spekter av funksjoner (vi utvidet funksjonaliteten hele tiden), gjorde boten arbeidet deres enklere og gjorde livet vårt mye enklere. På denne måten optimaliserte vi det meste av prosessen med å gjenbruke og vedlikeholde servere, og eliminerte oss selv fra arbeidsflyten.
iPad i et av våre datasentre
Maskinvaredomene
Pålitelig skalering av datasenterinfrastrukturen vår krever god synlighet i hver komponent, for eksempel:
- Deteksjon av maskinvarefeil
- Serverstatus (aktiv, vert, zombie, etc.)
- Strømforbruk
- Fastvareversjon
- Analytics for hele denne virksomheten
Våre løsninger lar oss ta beslutninger om hvordan, hvor og når vi skal kjøpe utstyr, noen ganger til og med før det faktisk er nødvendig. Ved å bestemme belastningsnivået på forskjellig utstyr kunne vi også oppnå forbedret ressursallokering. Spesielt energiforbruk. Vi kan nå ta informerte beslutninger om plassering av en server før den installeres i racket og kobles til en strømkilde, gjennom hele livssyklusen og frem til den eventuelt går av.
Energy Dashboard i Grafana
Og så dukket COVID-19 opp...
Teamet vårt lager teknologier som styrker mediebedrifter og utgivere på nettet for å hjelpe besøkende med å finne relevant innhold, produkter og tjenester som kan være av interesse for dem. Infrastrukturen vår er designet for å betjene trafikk som genereres når noen spennende nyheter slippes.
Den intense mediedekningen rundt COVID-19, kombinert med økningen i trafikken, gjorde at vi snarest måtte lære å takle dette presset. Dessuten måtte alt dette gjøres under en global krise, da forsyningskjeder ble forstyrret og de fleste av de ansatte var hjemme.
Men som vi sa, vår modell antar allerede at:
- Utstyret i våre datasentre er for det meste fysisk utilgjengelig for oss;
- Vi gjør nesten alt fysisk arbeid eksternt;
- Arbeidet utføres asynkront, autonomt og i stor skala;
- Vi møter etterspørselen etter utstyr ved å bruke «bygg av deler»-metoden i stedet for å kjøpe nytt utstyr;
- Vi har et lager som gjør at vi kan skape noe nytt, og ikke bare utføre rutinereparasjoner.
Dermed hadde de globale restriksjonene som hindret mange bedrifter i å få fysisk tilgang til sine datasentre liten innvirkning på oss.Og når det gjelder reservedeler og servere, ja, vi prøvde å sikre stabil drift av utstyret. Men dette ble gjort med sikte på å forhindre mulige hendelser når det plutselig viser seg at en eller annen maskinvare ikke er tilgjengelig. Vi sørget for at reservene våre ble fylt uten å ha som mål å møte dagens etterspørsel.
Oppsummert vil jeg si at vår tilnærming til å jobbe i datasenterindustrien beviser at det er mulig å anvende prinsippene for god kodedesign på den fysiske styringen av et datasenter. Og kanskje du vil finne det interessant.
original:
Kilde: www.habr.com