Haai Habr! Ek bied die vertaling van die artikel aan u aandag deur Adib Daw.
As daardie opskrif nie 'n effense rilling van jou ruggraat af stuur nie, moet jy na die volgende paragraaf oorslaan of ons bladsy besoek wat toegewy is aan - ons wil graag praat.
Wie ons is
Ons is 'n span van 4 pikkewyne wat daarvan hou om kode te skryf en met hardeware te werk. In ons vrye tyd is ons verantwoordelik vir die ontplooiing, instandhouding en bedryf van 'n vloot van meer as 7000 3 fisiese bedieners met Linux, versprei oor XNUMX verskillende datasentrums regoor die Verenigde State.
Ons het ook die geleentheid gehad om dit 10 000 km weg van staanplekke te doen, vanuit die gerief van ons eie kantoor, wat 'n entjie se ry vanaf die strand aan die Middellandse See geleë is.
Skaalprobleme
Alhoewel dit sin maak vir 'n begin om te begin deur sy infrastruktuur in die wolk te huisves as gevolg van die relatief lae aanvanklike belegging, het ons by Outbrain besluit om ons eie bedieners te gebruik. Ons het dit gedoen omdat die koste van wolkinfrastruktuur tot 'n sekere vlak die koste van die bedryf van ons eie toerusting wat in datasentrums geleë is, ver oorskry. Boonop bied u bediener die hoogste graad van beheer en probleemoplossingsvermoëns.
Soos ons ontwikkel, is probleme altyd naby. Boonop kom hulle gewoonlik in groepe. Bediener lewensiklusbestuur vereis konstante selfverbetering om behoorlik te kan funksioneer in die konteks van die vinnige toename in die aantal bedieners. Sagtewaremetodes vir die bestuur van bedienergroepe in datasentrums word vinnig moeilik. Om foute op te spoor, op te los en te versag terwyl daar aan QoS-standaarde voldoen word, word 'n kwessie van jongleren met uiters uiteenlopende reekse hardeware, wisselende werkladings, opgraderingspertye en ander lekker dinge waaroor niemand wil bekommer nie.
Bemeester jou domeine
Om baie van hierdie probleme op te los, het ons die bedienerlewensiklus in Outbrain in sy hoofkomponente opgedeel en dit domeine genoem. Byvoorbeeld, een domein dek toerustingvereistes, 'n ander dek logistiek wat verband hou met die voorraadlewensiklus, en 'n derde dek kommunikasie met veldpersoneel. Daar is nog een oor hardeware waarneembaarheid, maar ons sal nie al die punte beskryf nie. Ons doel was om domeine te bestudeer en te definieer sodat dit met behulp van kode geabstraheer kan word. Sodra 'n werkende abstraksie ontwikkel is, word dit oorgedra na 'n handmatige proses wat ontplooi, getoets en verfyn word. Laastens is die domein gekonfigureer om met ander domeine te integreer via API's, wat 'n holistiese, dinamiese en voortdurend ontwikkelende hardeware-lewensiklusstelsel vorm wat ontplooi, toetsbaar en waarneembaar is. Net soos al ons ander produksiestelsels.
Deur hierdie benadering aan te neem, kon ons baie probleme korrek oplos - deur gereedskap en outomatisering te skep.
Benodig domein
Alhoewel e-pos en sigblaaie 'n lewensvatbare manier was om aan die vraag in die vroeë dae te voldoen, was dit nie 'n suksesvolle oplossing nie, veral nie wanneer die aantal bedieners en die volume van inkomende versoeke 'n sekere vlak bereik het. Om inkomende versoeke beter te organiseer en te prioritiseer in die lig van vinnige uitbreiding, moes ons 'n kaartjiestelsel gebruik wat die volgende kon bied:
- Vermoë om die aansig van slegs relevante velde aan te pas (eenvoudig)
- Oop API's (uitbreidbaar)
- Bekend aan ons span (verstaan)
- Integrasie met ons bestaande werkstrome (verenigde)
Aangesien ons Jira gebruik om ons naellope en interne take te bestuur, het ons besluit om nog 'n projek te skep wat ons kliënte sal help om kaartjies in te dien en hul resultate op te spoor. Die gebruik van Jira vir inkomende versoeke en vir die bestuur van interne take het ons toegelaat om 'n enkele Kanban-bord te skep wat ons toegelaat het om na alle prosesse as 'n geheel te kyk. Ons interne "kliënte" het slegs versoeke vir toerusting gesien, sonder om in die minder belangrike besonderhede van bykomende take (soos die verbetering van gereedskap, die regmaak van foute) te delf.
Kanban-raad in Jira
As 'n bonus het die feit dat rye en prioriteite nou vir almal sigbaar was dit moontlik gemaak om te verstaan "waar in die ry" 'n spesifieke versoek is en wat dit voorafgegaan het. Dit het eienaars toegelaat om hul eie versoeke te herprioritiseer sonder om ons te kontak. Sleep dit en dit is dit. Dit het ons ook toegelaat om ons SLA's te monitor en te evalueer volgens versoektipes gebaseer op die maatstawwe wat in Jira gegenereer word.
Toerusting Lewensiklusdomein
Probeer om die kompleksiteit van die bestuur van die hardeware wat in elke bedienerrek gebruik word, voor te stel. Wat nog erger is, is dat baie stukke hardeware (RAM, ROM) van die pakhuis na die bedienerkamer en terug geskuif kan word. Hulle misluk ook of word afgeskryf en vervang en teruggestuur aan die verskaffer vir vervanging/herstel. Dit alles moet gekommunikeer word aan die kolokasiedienswerknemers wat betrokke is by die fisiese instandhouding van die toerusting. Om hierdie probleme op te los, het ons 'n interne instrument genaamd Floppy geskep. Sy taak is:
- Bestuur van kommunikasie met veldpersoneel, samevoeging van alle inligting;
- Opdatering van die "pakhuis" data na elke voltooide en geverifieerde instandhoudingstaak van toerusting.
Die pakhuis word op sy beurt gevisualiseer deur Grafana te gebruik, wat ons gebruik om al ons metrieke te plot. Ons gebruik dus dieselfde instrument vir pakhuisvisualisering en vir ander produksiebehoeftes.
Pakhuistoerustingbeheerpaneel in Grafana
Vir bedienertoestelle wat onder waarborg is, gebruik ons 'n ander hulpmiddel wat ons Dispatcher noem. Hy:
- Versamel stelsel logs;
- Genereer verslae in die formaat wat deur die verkoper vereis word;
- Skep 'n versoek van die verkoper via API;
- Ontvang en stoor die toepassing identifiseerder vir verdere dop van sy vordering.
Sodra ons eis aanvaar is (gewoonlik binne besigheidsure), word die onderdeel na die toepaslike datasentrum gestuur en deur personeel aanvaar.
Jenkins-konsole-uitset
Kommunikasiedomein
Om tred te hou met die vinnige groei van ons besigheid, wat steeds groter kapasiteit verg, moes ons die manier waarop ons met tegniese spesialiste in plaaslike datasentrums werk, aanpas. As opskaling aanvanklik beteken het om nuwe bedieners te koop, dan het dit na 'n konsolidasieprojek (gebaseer op die oorgang na Kubernetes) iets heeltemal anders geword. Ons evolusie van "byvoeging van rakke" tot "hergebruik van bedieners."
Die gebruik van 'n nuwe benadering het ook nuwe gereedskap vereis wat dit moontlik gemaak het om meer gemaklik met datasentrumpersoneel te kommunikeer. Hierdie gereedskap was nodig om:
- Eenvoud;
- Outonomie;
- Doeltreffendheid;
- Betroubaarheid.
Ons moes onsself uitsluit van die ketting en die werk struktureer sodat tegnici direk met bedienertoerusting kon werk. Sonder ons ingryping en sonder om gereeld al hierdie kwessies rakende werklading, werksure, beskikbaarheid van toerusting, ens.
Om dit te bereik, het ons iPads in elke datasentrum geïnstalleer. Nadat u aan die bediener gekoppel is, sal die volgende gebeur:
- Die toestel bevestig dat hierdie bediener inderdaad werk verg;
- Toepassings wat op die bediener loop, is gesluit (indien nodig);
- 'n Stel werkinstruksies word op 'n Slack-kanaal geplaas wat die stappe wat vereis word, verduidelik;
- Na voltooiing van die werk, kontroleer die toestel die korrektheid van die finale toestand van die bediener;
- Herbegin toepassings indien nodig.
Daarbenewens het ons ook 'n Slack-bot voorberei om die tegnikus te help. Danksy 'n wye reeks vermoëns (ons het die funksionaliteit voortdurend uitgebrei), het die bot hul werk makliker gemaak en ons lewe baie makliker gemaak. Op hierdie manier het ons die meeste van die proses van herbestemming en instandhouding van bedieners geoptimaliseer, en onsself uit die werkvloei uitgeskakel.
iPad in een van ons datasentrums
Hardeware domein
Om ons datasentrum-infrastruktuur betroubaar te skaal vereis goeie sigbaarheid in elke komponent, byvoorbeeld:
- Opsporing van hardeware mislukking
- Bedienertoestande (aktief, gehuisves, zombie, ens.)
- Kragverbruik
- Firmware weergawe
- Ontleding vir hierdie hele besigheid
Ons oplossings stel ons in staat om besluite te neem oor hoe, waar en wanneer om toerusting te koop, soms selfs voordat dit werklik nodig is. Deur ook die vlak van las op verskillende toerusting te bepaal, kon ons verbeterde hulpbrontoewysing bewerkstellig. In die besonder, energieverbruik. Ons kan nou ingeligte besluite neem oor die plasing van 'n bediener voordat dit in die rek geïnstalleer word en aan 'n kragbron gekoppel word, regdeur sy lewensiklus en tot sy uiteindelike aftrede.
Energie Dashboard in Grafana
En toe verskyn COVID-19 ...
Ons span skep tegnologieë wat mediamaatskappye en uitgewers aanlyn bemagtig om besoekers te help om relevante inhoud, produkte en dienste te vind wat vir hulle van belang kan wees. Ons infrastruktuur is ontwerp om verkeer te bedien wat gegenereer word wanneer opwindende nuus vrygestel word.
Die intense mediadekking rondom COVID-19, tesame met die toename in verkeer, het beteken dat ons dringend moes leer hoe om hierdie druk te hanteer. Boonop moes dit alles gedoen word tydens 'n wêreldwye krisis, toe voorsieningskettings ontwrig is en die meeste van die personeel tuis was.
Maar, soos ons gesê het, ons model aanvaar reeds dat:
- Die toerusting in ons datasentrums is vir die grootste deel fisies ontoeganklik vir ons;
- Ons doen byna alle fisiese werk op afstand;
- Werk word asynchroon, outonoom en op groot skaal uitgevoer;
- Ons voldoen aan die vraag na toerusting deur die "bou uit onderdele"-metode te gebruik in plaas van om nuwe toerusting aan te koop;
- Ons het 'n pakhuis wat ons in staat stel om iets nuuts te skep, en nie net roetine herstelwerk uit te voer nie.
Die globale beperkings wat baie maatskappye verhinder het om fisiese toegang tot hul datasentrums te kry, het dus min impak op ons gehad. En wat onderdele en bedieners betref, ja, ons het probeer om 'n stabiele werking van die toerusting te verseker. Maar dit is gedoen met die doel om moontlike voorvalle te voorkom wanneer dit skielik blyk dat een of ander stuk hardeware nie beskikbaar is nie. Ons het verseker dat ons reserwes gevul is sonder om te poog om in die huidige vraag te voorsien.
Opsommend wil ek sê dat ons benadering tot werk in die datasentrumbedryf bewys dat dit moontlik is om die beginsels van goeie kode-ontwerp toe te pas op die prosesse van fisiese datasentrumbestuur. En miskien sal jy dit interessant vind.
Oorspronklik:
Bron: will.com