Hej Habr! Jeg præsenterer for din opmærksomhed oversættelsen af artiklen af Adib Daw.
Hvis den overskrift ikke sender et lille gys ned ad din rygrad, bør du springe til næste afsnit eller besøge vores side dedikeret til - vi vil gerne snakke.
Hvem vi er
Vi er et team på 4 pingviner, der elsker at skrive kode og arbejde med hardware. I vores fritid er vi ansvarlige for at implementere, vedligeholde og drive en flåde på over 7000 fysiske servere, der kører Linux, fordelt på 3 forskellige datacentre i hele USA.
Vi havde også mulighed for at gøre dette 10 km væk fra websteder, fra vores eget kontor, som ligger en kort køretur fra stranden ved Middelhavet.
Skalaproblemer
Selvom det giver mening for en startup at starte med at hoste sin infrastruktur i skyen på grund af den relativt lave startinvestering, besluttede vi hos Outbrain at bruge vores egne servere. Det gjorde vi, fordi omkostningerne til cloud-infrastruktur langt overstiger omkostningerne ved at drive vores eget udstyr placeret i datacentre efter udvikling til et vist niveau. Derudover giver din server den højeste grad af kontrol og fejlfindingsmuligheder.
Mens vi udvikler os, er problemer altid i nærheden. Desuden kommer de som regel i grupper. Serverlivscyklusstyring kræver konstant selvforbedring for at kunne fungere korrekt i forbindelse med den hurtige stigning i antallet af servere. Softwaremetoder til styring af servergrupper i datacentre bliver hurtigt uhåndterlige. Detektering, fejlfinding og afhjælpning af fejl, samtidig med at QoS-standarder overholdes, bliver et spørgsmål om at jonglere med ekstremt forskellige hardware-arrays, varierende arbejdsbelastninger, opgraderingsfrister og andre gode ting, som ingen ønsker at bekymre sig om.
Mestre dine domæner
For at løse mange af disse problemer opdelte vi serverlivscyklussen i Outbrain i dens hovedkomponenter og kaldte dem domæner. For eksempel dækker et domæne udstyrskrav, et andet dækker logistik relateret til lagerets livscyklus, og et tredje dækker kommunikation med feltpersonale. Der er en anden vedrørende hardwareobservation, men vi vil ikke beskrive alle punkterne. Vores mål var at studere og definere domæner, så de kunne abstraheres ved hjælp af kode. Når en fungerende abstraktion er udviklet, overføres den til en manuel proces, der implementeres, testes og forfines. Endelig er domænet konfigureret til at integrere med andre domæner via API'er, hvilket danner et holistisk, dynamisk og konstant udviklende hardware-livscyklussystem, der kan implementeres, testes og observeres. Ligesom alle vores andre produktionssystemer.
Ved at vedtage denne tilgang kunne vi løse mange problemer korrekt - ved at skabe værktøjer og automatisering.
Brug for domæne
Selvom e-mail og regneark var en levedygtig måde at imødekomme efterspørgslen på i de tidlige dage, var det ikke en succesfuld løsning, især når antallet af servere og mængden af indgående anmodninger nåede et vist niveau. For bedre at kunne organisere og prioritere indkommende forespørgsler i lyset af hurtig udvidelse, var vi nødt til at bruge et billetsystem, der kunne tilbyde:
- Mulighed for at tilpasse visningen af kun relevante felter (simpelt)
- Åbne API'er (kan udvides)
- Kendt af vores team (forstået)
- Integration med vores eksisterende arbejdsgange (forenet)
Da vi bruger Jira til at styre vores sprints og interne opgaver, besluttede vi at oprette et andet projekt, der ville hjælpe vores kunder med at indsende billetter og spore deres resultater. Ved at bruge Jira til indgående anmodninger og til styring af interne opgaver, kunne vi oprette et enkelt Kanban-kort, der gjorde det muligt for os at se på alle processer som en helhed. Vores interne "klienter" så kun anmodninger om udstyr uden at dykke ned i de mindre væsentlige detaljer om yderligere opgaver (såsom forbedring af værktøjer, rettelse af fejl).
Kanban bestyrelse i Jira
Som en bonus kunne det faktum, at køer og prioriteringer nu var synlige for alle, gøre det muligt at forstå "hvor i køen" en bestemt anmodning var, og hvad der gik forud for den. Dette gjorde det muligt for ejere at omprioritere deres egne anmodninger uden at skulle kontakte os. Træk det og det er det. Det gjorde det også muligt for os at overvåge og evaluere vores SLA'er i henhold til anmodningstyper baseret på metrics genereret i Jira.
Udstyrs livscyklusdomæne
Prøv at forestille dig kompleksiteten i at administrere den hardware, der bruges i hvert serverrack. Hvad der er endnu værre er, at mange stykker hardware (RAM, ROM) kan flyttes fra lageret til serverrummet og tilbage. De fejler også eller afskrives og erstattes og returneres til leverandøren for udskiftning/reparation. Alt dette skal kommunikeres til de colocation service medarbejdere, der er involveret i den fysiske vedligeholdelse af udstyret. For at løse disse problemer har vi lavet et internt værktøj kaldet Floppy. Hans opgave er:
- Styring af kommunikation med feltpersonale, aggregering af al information;
- Opdatering af "lager"-data efter hvert afsluttet og verificeret udstyrsvedligeholdelsesjob.
Lageret er til gengæld visualiseret ved hjælp af Grafana, som vi bruger til at plotte alle vores metrics. Således bruger vi det samme værktøj til lagervisualisering og til andre produktionsbehov.
Kontrolpanel til lagerudstyr i Grafana
For serverenheder, der er under garanti, bruger vi et andet værktøj, vi kalder Dispatcher. Han:
- Samler systemlogfiler;
- Genererer rapporter i det format, som leverandøren kræver;
- Opretter en anmodning fra leverandøren via API;
- Modtager og gemmer applikationsidentifikatoren til yderligere sporing af dens fremskridt.
Når vores krav er accepteret (normalt inden for åbningstiden), sendes reservedelen til det relevante datacenter og accepteres af personalet.
Jenkins konsol udgang
Kommunikationsdomæne
For at følge med den hurtige vækst i vores forretning, som kræver stadigt stigende kapacitet, var vi nødt til at tilpasse den måde, vi arbejder på med tekniske specialister i lokale datacentre. Hvis opskalering i første omgang betød at købe nye servere, så blev det efter et konsolideringsprojekt (baseret på overgangen til Kubernetes) noget helt andet. Vores udvikling fra "tilføjelse af racks" til "genanvendelse af servere."
Brug af en ny tilgang krævede også nye værktøjer, der gjorde det muligt at interagere mere komfortabelt med datacenterpersonale. Disse værktøjer var nødvendige for at:
- Enkelhed;
- Autonomi;
- Effektivitet;
- Pålidelighed.
Vi skulle udelukke os selv fra kæden og strukturere arbejdet, så teknikere direkte kunne arbejde med serverudstyr. Uden vores indgriben og uden regelmæssigt at rejse alle disse spørgsmål vedrørende arbejdsbyrde, arbejdstider, tilgængelighed af udstyr osv.
For at opnå dette installerede vi iPads i hvert datacenter. Efter tilslutning til serveren sker følgende:
- Enheden bekræfter, at denne server faktisk kræver noget arbejde;
- Programmer, der kører på serveren, lukkes (hvis nødvendigt);
- Et sæt arbejdsinstruktioner er lagt ud på en Slack-kanal, der forklarer de nødvendige trin;
- Efter afslutning af arbejdet kontrollerer enheden rigtigheden af serverens endelige tilstand;
- Genstarter applikationer om nødvendigt.
Derudover har vi også forberedt en Slack-bot til at hjælpe teknikeren. Takket være en bred vifte af muligheder (vi udvidede konstant funktionaliteten), gjorde botten deres arbejde lettere og gjorde vores liv meget lettere. På denne måde optimerede vi det meste af processen med at genbruge og vedligeholde servere, hvilket eliminerede os selv fra arbejdsgangen.
iPad i et af vores datacentre
Hardware domæne
En pålidelig skalering af vores datacenterinfrastruktur kræver god synlighed i hver komponent, for eksempel:
- Registrering af hardwarefejl
- Servertilstande (aktiv, hostet, zombie osv.)
- Strømforbrug
- Firmware version
- Analytics for hele denne virksomhed
Vores løsninger giver os mulighed for at træffe beslutninger om hvordan, hvor og hvornår vi skal købe udstyr, nogle gange endda før det faktisk er nødvendigt. Ved at bestemme belastningsniveauet på forskelligt udstyr var vi også i stand til at opnå en forbedret ressourceallokering. Især energiforbruget. Vi kan nu træffe informerede beslutninger om placeringen af en server, før den installeres i racket og tilsluttes en strømkilde, gennem hele dens livscyklus og indtil dens endelige pensionering.
Energi Dashboard i Grafana
Og så dukkede COVID-19 op...
Vores team skaber teknologier, der styrker medievirksomheder og udgivere online og hjælper besøgende med at finde relevant indhold, produkter og tjenester, der kan være af interesse for dem. Vores infrastruktur er designet til at betjene trafik genereret, når nogle spændende nyheder udgives.
Den intense mediedækning omkring COVID-19, kombineret med stigningen i trafikken, betød, at vi havde et presserende behov for at lære, hvordan vi kan klare dette pres. Desuden skulle alt dette gøres under en global krise, hvor forsyningskæderne blev forstyrret, og det meste af personalet var hjemme.
Men som vi sagde, antager vores model allerede, at:
- Udstyret i vores datacentre er for det meste fysisk utilgængeligt for os;
- Vi udfører næsten alt fysisk arbejde på afstand;
- Arbejdet udføres asynkront, selvstændigt og i stor skala;
- Vi imødekommer efterspørgslen efter udstyr ved at bruge "byg af dele"-metoden i stedet for at købe nyt udstyr;
- Vi har et lager, der giver os mulighed for at skabe noget nyt, og ikke bare udføre rutinereparationer.
De globale restriktioner, der forhindrede mange virksomheder i at få fysisk adgang til deres datacentre, havde således ringe indflydelse på os.Og med hensyn til reservedele og servere, ja, så forsøgte vi at sikre en stabil drift af udstyret. Men dette blev gjort med det formål at forhindre mulige hændelser, når det pludselig viser sig, at et eller andet stykke hardware ikke er tilgængeligt. Vi sikrede, at vores reserver blev fyldt uden at sigte mod at imødekomme den nuværende efterspørgsel.
Sammenfattende vil jeg gerne sige, at vores tilgang til at arbejde i datacenterindustrien beviser, at det er muligt at anvende principperne for godt kodedesign til den fysiske styring af et datacenter. Og måske vil du finde det interessant.
Original:
Kilde: www.habr.com