Hallo, Habr! Ik presenteer onder uw aandacht een vertaling van het artikel van Adib Daw.
Als die kop geen lichte rilling over je rug doet gaan, ga dan naar de volgende paragraaf of bezoek onze pagina gewijd aan - wij willen graag praten.
Wie we zijn
Wij zijn een team van 4 pinguïns die dol zijn op het schrijven van code en het werken met hardware. In onze vrije tijd zijn we verantwoordelijk voor het inzetten, onderhouden en exploiteren van een vloot van meer dan 7000 fysieke servers met Linux, verdeeld over 3 verschillende datacenters in de Verenigde Staten.
We hadden ook de mogelijkheid om dit op 10 km afstand van locaties te doen, vanuit het comfort van ons eigen kantoor, dat zich op korte rijafstand van het strand aan de Middellandse Zee bevindt.
Schaalproblemen
Hoewel het logisch is dat een startup begint met het hosten van zijn infrastructuur in de cloud vanwege de relatief lage initiële investering, hebben wij bij Outbrain besloten om onze eigen servers te gebruiken. We hebben dit gedaan omdat de kosten van de cloudinfrastructuur veel hoger zijn dan de kosten van het exploiteren van onze eigen apparatuur die zich in datacenters bevindt na ontwikkeling tot een bepaald niveau. Bovendien biedt uw server de hoogste mate van controle en mogelijkheden voor probleemoplossing.
Terwijl we ons ontwikkelen, zijn problemen altijd dichtbij. Bovendien komen ze meestal in groepen. Server lifecycle management vereist constante zelfverbetering om goed te kunnen functioneren in de context van de snelle toename van het aantal servers. Softwaremethoden voor het beheren van servergroepen in datacenters worden al snel onpraktisch. Het detecteren, oplossen van problemen en het beperken van fouten terwijl wordt voldaan aan de QoS-standaarden wordt een kwestie van jongleren met extreem uiteenlopende hardware-arrays, variërende werklasten, upgrade-deadlines en andere leuke dingen waar niemand zich zorgen over wil maken.
Beheers uw domeinen
Om veel van deze problemen op te lossen, hebben we de levenscyclus van de server in Outbrain opgedeeld in de belangrijkste componenten en deze domeinen genoemd. Het ene domein heeft bijvoorbeeld betrekking op de apparatuurvereisten, het andere op de logistiek gerelateerd aan de levenscyclus van de inventaris, en een derde op de communicatie met veldpersoneel. Er is nog een vraag over de waarneembaarheid van hardware, maar we zullen niet alle punten beschrijven. Ons doel was om domeinen te bestuderen en te definiëren, zodat ze met behulp van code konden worden geabstraheerd. Zodra een werkende abstractie is ontwikkeld, wordt deze overgebracht naar een handmatig proces dat wordt geïmplementeerd, getest en verfijnd. Ten slotte is het domein geconfigureerd om via API's met andere domeinen te integreren, waardoor een holistisch, dynamisch en steeds evoluerend hardwarelevenscyclussysteem ontstaat dat inzetbaar, testbaar en waarneembaar is. Net als al onze andere productiesystemen.
Door deze aanpak toe te passen, konden we veel problemen correct oplossen - door tools en automatisering te creëren.
Domein nodig
Hoewel e-mail en spreadsheets in het begin een haalbare manier waren om aan de vraag te voldoen, was het geen succesvolle oplossing, vooral niet toen het aantal servers en het volume aan inkomende verzoeken een bepaald niveau bereikten. Om in het licht van de snelle uitbreiding de binnenkomende verzoeken beter te kunnen organiseren en prioriteren, moesten we een ticketingsysteem gebruiken dat het volgende kon bieden:
- Mogelijkheid om de weergave van alleen relevante velden aan te passen (eenvoudig)
- Open API's (uitbreidbaar)
- Bekend bij ons team (begrepen)
- Integratie met onze bestaande workflows (geünificeerd)
Omdat we Jira gebruiken om onze sprints en interne taken te beheren, hebben we besloten een ander project te maken waarmee onze klanten tickets kunnen indienen en hun resultaten kunnen volgen. Door Jira te gebruiken voor inkomende verzoeken en voor het beheren van interne taken, konden we één Kanban-bord creëren waarmee we alle processen als geheel konden bekijken. Onze interne ‘klanten’ zagen alleen verzoeken om apparatuur, zonder zich te verdiepen in de minder belangrijke details van aanvullende taken (zoals het verbeteren van tools, het oplossen van bugs).
Kanbanbord in Jira
Als bonus maakte het feit dat wachtrijen en prioriteiten nu voor iedereen zichtbaar waren, het mogelijk om te begrijpen “waar in de wachtrij” een bepaald verzoek zich bevond en wat eraan voorafging. Hierdoor konden eigenaren hun eigen verzoeken opnieuw prioriteren zonder dat ze contact met ons hoefden op te nemen. Sleep het en dat is alles. Het stelde ons ook in staat onze SLA's te monitoren en te evalueren op basis van verzoektypen op basis van de in Jira gegenereerde statistieken.
Levenscyclusdomein van apparatuur
Probeer je de complexiteit voor te stellen van het beheer van de hardware die in elk serverrack wordt gebruikt. Wat nog erger is, is dat veel hardwareonderdelen (RAM, ROM) van het magazijn naar de serverruimte en terug kunnen worden verplaatst. Ook deze gaan kapot of worden afgeschreven en vervangen en ter vervanging/reparatie teruggestuurd naar de leverancier. Dit alles moet worden gecommuniceerd aan de medewerkers van de colocatieservice die betrokken zijn bij het fysieke onderhoud van de apparatuur. Om deze problemen op te lossen, hebben we een interne tool gemaakt genaamd Floppy. Zijn taak is:
- Beheer van de communicatie met veldpersoneel, aggregatie van alle informatie;
- Het bijwerken van de “magazijn”-gegevens na elke voltooide en geverifieerde onderhoudstaak voor apparatuur.
Het magazijn wordt op zijn beurt gevisualiseerd met Grafana, dat we gebruiken om al onze statistieken in kaart te brengen. We gebruiken dus dezelfde tool voor magazijnvisualisatie en voor andere productiebehoeften.
Bedieningspaneel voor magazijnapparatuur in Grafana
Voor serverapparaten die onder de garantie vallen, gebruiken we een andere tool die we Dispatcher noemen. Hij:
- Verzamelt systeemlogboeken;
- Genereert rapporten in het door de leverancier vereiste formaat;
- Creëert een verzoek van de leverancier via API;
- Ontvangt en bewaart de applicatie-ID voor het verder volgen van de voortgang ervan.
Zodra onze claim is geaccepteerd (meestal binnen kantooruren), wordt het reserveonderdeel naar het juiste datacenter gestuurd en door het personeel geaccepteerd.
Jenkins-console-uitvoer
Communicatie domein
Om gelijke tred te houden met de snelle groei van ons bedrijf, die een steeds grotere capaciteit vereist, moesten we de manier aanpassen waarop we samenwerken met technische specialisten in lokale datacenters. Betekende het opschalen eerst dat er nieuwe servers moesten worden gekocht, maar na een consolidatieproject (gebaseerd op de transitie naar Kubernetes) werd het iets heel anders. Onze evolutie van “het toevoegen van racks” naar “het herbestemmen van servers.”
Het gebruik van een nieuwe aanpak vereiste ook nieuwe tools die het mogelijk maakten om comfortabeler te communiceren met datacenterpersoneel. Deze hulpmiddelen waren nodig om:
- Eenvoud;
- Autonomie;
- efficiëntie;
- Betrouwbaarheid.
We moesten onszelf uitsluiten van de keten en de werkzaamheden zo structureren dat monteurs direct met serverapparatuur aan de slag konden. Zonder onze tussenkomst en zonder regelmatig al deze kwesties met betrekking tot werkdruk, werkuren, beschikbaarheid van apparatuur, enz.
Om dit te bereiken hebben we in elk datacenter iPads geïnstalleerd. Nadat u verbinding heeft gemaakt met de server, gebeurt het volgende:
- Het apparaat bevestigt dat deze server inderdaad wat werk vereist;
- Applicaties die op de server draaien worden gesloten (indien nodig);
- Op een Slack-kanaal wordt een reeks werkinstructies geplaatst waarin de vereiste stappen worden uitgelegd;
- Na voltooiing van het werk controleert het apparaat de juistheid van de eindstatus van de server;
- Start applicaties indien nodig opnieuw op.
Daarnaast hebben we ook een Slack-bot voorbereid om de technicus te helpen. Dankzij een breed scala aan mogelijkheden (we breidden de functionaliteit voortdurend uit) maakte de bot hun werk eenvoudiger en ons leven een stuk eenvoudiger. Op deze manier hebben we het grootste deel van het proces van het herbestemmen en onderhouden van servers geoptimaliseerd, waardoor we onszelf uit de workflow hebben geëlimineerd.
iPad in één van onze datacenters
Hardwaredomein
Het betrouwbaar opschalen van onze datacenterinfrastructuur vereist goed inzicht in elk onderdeel, bijvoorbeeld:
- Detectie van hardwarefouten
- Serverstatussen (actief, gehost, zombie, enz.)
- Stroomverbruik
- Firmware versie
- Analytics voor dit hele bedrijf
Onze oplossingen stellen ons in staat beslissingen te nemen over hoe, waar en wanneer we apparatuur moeten aanschaffen, soms zelfs voordat deze daadwerkelijk nodig is. Door het belastingsniveau van verschillende apparatuur te bepalen, konden we bovendien een betere toewijzing van middelen realiseren. Met name het energieverbruik. We kunnen nu weloverwogen beslissingen nemen over de plaatsing van een server voordat deze in het rack wordt geïnstalleerd en op een stroombron wordt aangesloten, gedurende de gehele levenscyclus ervan en tot aan de uiteindelijke pensionering.
Energiedashboard in Grafana
En toen verscheen COVID-19...
Ons team creëert technologieën waarmee mediabedrijven en uitgevers online bezoekers kunnen helpen relevante inhoud, producten en diensten te vinden die voor hen interessant kunnen zijn. Onze infrastructuur is ontworpen om het verkeer te bedienen dat wordt gegenereerd wanneer er spannend nieuws wordt vrijgegeven.
De intense berichtgeving in de media over COVID-19, in combinatie met de toename van het verkeer, betekende dat we dringend moesten leren hoe we met deze druk om konden gaan. Bovendien moest dit alles gebeuren tijdens een mondiale crisis, toen de toeleveringsketens ontwricht waren en het merendeel van het personeel thuis zat.
Maar zoals we al zeiden, gaat ons model er al van uit dat:
- De apparatuur in onze datacenters is voor ons grotendeels fysiek ontoegankelijk;
- Wij doen vrijwel al het fysieke werk op afstand;
- Er wordt asynchroon, autonoom en op grote schaal gewerkt;
- Wij voldoen aan de vraag naar apparatuur door middel van de ‘build from parts’-methode in plaats van nieuwe apparatuur aan te schaffen;
- We hebben een magazijn waarmee we iets nieuws kunnen creëren en niet alleen routinematige reparaties kunnen uitvoeren.
De mondiale beperkingen die veel bedrijven ervan weerhielden fysieke toegang te krijgen tot hun datacenters hadden dus weinig impact op ons. En wat betreft reserveonderdelen en servers: ja, we hebben geprobeerd een stabiele werking van de apparatuur te garanderen. Maar dit werd gedaan met als doel mogelijke incidenten te voorkomen wanneer plotseling blijkt dat een stukje hardware niet beschikbaar is. We hebben ervoor gezorgd dat onze reserves werden aangevuld, zonder te streven naar de huidige vraag.
Samenvattend zou ik willen zeggen dat onze benadering van werken in de datacenterindustrie bewijst dat het mogelijk is om de principes van goed codeontwerp toe te passen op het fysieke beheer van een datacenter. En misschien vind je het interessant.
Origineel:
Bron: www.habr.com