Hej Habr! Mi prezentas al via atento la tradukon de la artikolo de Adib Daw.
Se tiu titolo ne tremas vian spinon, vi devus salti al la sekva alineo aŭ viziti nian paĝon dediĉitan al — ni ŝatus paroli.
Kiu ni estas
Ni estas teamo de 4 pingvenoj, kiuj amas skribi kodon kaj labori kun aparataro. En nia libertempo, ni respondecas pri deplojado, konservado kaj funkciado de aro de pli ol 7000 fizikaj serviloj kurantaj Linukso, distribuitaj tra 3 malsamaj datumcentroj tra Usono.
Ni ankaŭ havis la ŝancon fari tion 10 km for de ejoj, de la komforto de nia propra oficejo, kiu situas mallongan veturon de la plaĝo ĉe la Mediteranea Maro.
Problemoj de skalo
Kvankam havas sencon, ke ekentrepreno komencu gastigante sian infrastrukturon en la nubo pro la relative malalta komenca investo, ni ĉe Outbrain decidis uzi niajn proprajn servilojn. Ni faris tion ĉar la kostoj de nuba infrastrukturo multe superas la kostojn de funkciigado de nia propra ekipaĵo situanta en datumcentroj post disvolviĝo al certa nivelo. Krome, via servilo provizas la plej altan gradon de kontrolo kaj solvo de problemoj.
Dum ni evoluas, problemoj ĉiam estas proksime. Krome, ili kutime venas en grupoj. Servila vivciklo-administrado postulas konstantan mem-plibonigon por povi funkcii ĝuste en la kunteksto de la rapida pliiĝo en la nombro da serviloj. Softvarmetodoj por administri servilgrupojn en datumcentroj rapide fariĝas maloportunaj. Detekti, solvi problemojn kaj mildigi malsukcesojn dum plenumado de QoS-normoj fariĝas demando pri ĵonglado de ekstreme diversaj aroj de aparataro, diversaj laborŝarĝoj, ĝisdatigaj limdatoj kaj aliaj belaj aferoj, pri kiuj neniu volas zorgi.
Majstri viajn Domajnojn
Por solvi multajn el ĉi tiuj problemoj, ni malkonstruis la servilan vivociklon en Outbrain en ĝiaj ĉefaj komponantoj kaj nomis ilin domajnoj. Ekzemple, unu domajno kovras ekipaĵpostulojn, alia kovras loĝistikon ligitan al la stokregistra vivociklo, kaj tria kovras komunikadon kun kamppersonaro. Estas alia pri aparataro-observebleco, sed ni ne priskribos ĉiujn punktojn. Nia celo estis studi kaj difini domajnojn tiel ke ili povus esti abstraktitaj uzante kodon. Post kiam laborabstraktado estas evoluigita, ĝi estas transdonita al mana procezo kiu estas deplojita, testita kaj rafinita. Finfine, la domajno estas agordita por integriĝi kun aliaj domajnoj per APIoj, formante holistikan, dinamikan kaj ĉiam evoluantan aparatan vivciklosistemon kiu estas deplojebla, testebla kaj observebla. Same kiel ĉiuj niaj aliaj produktadsistemoj.
Adoptante ĉi tiun aliron permesis al ni solvi multajn problemojn ĝuste - per kreado de iloj kaj aŭtomatigo.
Bezonas Domajnon
Kvankam retpoŝto kaj kalkultabeloj estis realigebla maniero renkonti postulon en la fruaj tagoj, ĝi ne estis sukcesa solvo, precipe kiam la nombro da serviloj kaj la volumeno de envenantaj petoj atingis certan nivelon. Por pli bone organizi kaj prioritatigi envenantajn petojn antaŭ rapida ekspansio, ni devis uzi biletsistemon kiu povus oferti:
- Kapablo personecigi la vidon de nur rilataj kampoj (simpla)
- Malfermaj APIoj (etendeblaj)
- Konata de nia teamo (komprenata)
- Integriĝo kun niaj ekzistantaj laborfluoj (unuigitaj)
Ĉar ni uzas Jira por administri niajn sprintojn kaj internajn taskojn, ni decidis krei alian projekton, kiu helpus niajn klientojn sendi biletojn kaj spuri iliajn rezultojn. Uzado de Jira por envenantaj petoj kaj por administri internajn taskojn permesis al ni krei ununuran Kanban-tabulo kiu permesis al ni rigardi ĉiujn procezojn kiel tuton. Niaj internaj "klientoj" vidis nur petojn pri ekipaĵo, sen enprofundiĝi en la malpli signifajn detalojn de pliaj taskoj (kiel plibonigo de iloj, ripari cimojn).
Kanban-tabulo en Jira
Kiel bonuso, la fakto, ke vicoj kaj prioritatoj nun estis videblaj por ĉiuj ebligis kompreni "kie en la vico" estas aparta peto kaj kio antaŭis ĝin. Ĉi tio permesis al posedantoj reprioritigi siajn proprajn petojn sen devi kontakti nin. Trenu ĝin kaj jen ĝi. Ĝi ankaŭ permesis al ni kontroli kaj taksi niajn SLA-ojn laŭ petaj tipoj bazitaj sur la metrikoj generitaj en Jira.
Equipment Lifecycle Domain
Provu imagi la kompleksecon de administrado de la aparataro uzata en ĉiu servila rako. Kio estas eĉ pli malbona estas, ke multaj pecoj da aparataro (RAM, ROM) povas esti movitaj de la magazeno al la servila ĉambro kaj reen. Ili ankaŭ malsukcesas aŭ estas forigitaj kaj anstataŭigitaj kaj resenditaj al la provizanto por anstataŭigo/riparo. Ĉio ĉi devas esti komunikita al la dungitoj de la koloka servo implikitaj en la fizika bontenado de la ekipaĵo. Por solvi ĉi tiujn problemojn, ni kreis internan ilon nomatan Floppy. Lia tasko estas:
- Administrado de komunikadoj kun kampopersonaro, agregado de ĉiuj informoj;
- Ĝisdatigi la datumojn de "magazeno" post ĉiu finita kaj kontrolita ekipaĵa prizorgado.
La magazeno, siavice, estas bildigita per Grafana, kiun ni uzas por bildigi ĉiujn niajn metrikojn. Tiel, ni uzas la saman ilon por magazena bildigo kaj por aliaj produktadbezonoj.
Stokekipaĵo kontrolpanelo en Grafana
Por servilaj aparatoj kiuj estas sub garantio, ni uzas alian ilon, kiun ni nomas Dispatcher. Li:
- Kolektas sistemajn protokolojn;
- Generas raportojn en la formato postulita de la vendisto;
- Kreas peton de la vendisto per API;
- Ricevas kaj konservas la aplikaĵidentigilon por plia spurado de ĝia progreso.
Post kiam nia aserto estas akceptita (kutime ene de komercaj horoj), la rezerva parto estas sendita al la taŭga datumcentro kaj akceptita de dungitaro.
Jenkins konzola eligo
Komunikada Domajno
Por daŭrigi la rapidan kreskon de nia komerco, kiu postulas ĉiam pli grandan kapablon, ni devis adapti la manieron kiel ni laboras kun teknikaj specialistoj en lokaj datumcentroj. Se komence pligrandigo signifis aĉeti novajn servilojn, tiam post firmiga projekto (bazita sur la transiro al Kubernetes) ĝi fariĝis io tute alia. Nia evoluo de "aldonado de rakoj" al "reutiligo de serviloj".
Uzi novan aliron ankaŭ postulis novajn ilojn kiuj ebligis interagi pli komforte kun datencentropersonaro. Ĉi tiuj iloj estis postulataj por:
- Simpleco;
- Aŭtonomeco;
- Efikeco;
- Fidindeco.
Ni devis ekskludi nin de la ĉeno kaj strukturi la laboron por ke teknikistoj povu rekte labori kun servila ekipaĵo. Sen nia interveno kaj sen regule levi ĉiujn ĉi tiujn aferojn pri laborkvanto, laborhoroj, ekipaĵhavebleco, ktp.
Por atingi ĉi tion, ni instalis iPad-ojn en ĉiu datumcentro. Post konekto al la servilo, la sekvanta okazos:
- La aparato konfirmas, ke ĉi tiu servilo ja postulas iom da laboro;
- Aplikoj kurantaj sur la servilo estas fermitaj (se necese);
- Aro da laboraj instrukcioj estas afiŝita sur Slack-kanalo klarigante la necesajn paŝojn;
- Post fino de laboro, la aparato kontrolas la ĝustecon de la fina stato de la servilo;
- Rekomencas aplikaĵojn se necese.
Krome, ni ankaŭ preparis Slack-boton por helpi la teknikiston. Dank' al vasta gamo de kapabloj (ni konstante vastigis la funkciojn), la roboto faciligis ilian laboron kaj multe plifaciligis nian vivon. Tiel ni optimumigis la plej grandan parton de la procezo de reuziĝo kaj konservado de serviloj, forigante nin de la laborfluo.
iPad en unu el niaj datumcentroj
Aparataro Domajno
Fidinde grimpi nian datumcentran infrastrukturon postulas bonan videblecon en ĉiu komponanto, ekzemple:
- Detekto de aparataro fiasko
- Servilŝtatoj (aktivaj, gastigitaj, zombiaj, ktp.)
- Potenca Konsumado
- Firmware versio
- Analytics por ĉi tiu tuta komerco
Niaj solvoj permesas al ni fari decidojn pri kiel, kie kaj kiam aĉeti ekipaĵon, foje eĉ antaŭ ol ĝi estas efektive bezonata. Ankaŭ, determinante la nivelon de ŝarĝo sur malsamaj ekipaĵoj, ni povis atingi plibonigitan asignon de rimedoj. Precipe, energikonsumo. Ni povas nun fari informitajn decidojn pri la lokigo de servilo antaŭ ol ĝi estas instalita en la rako kaj konektita al energifonto, dum ĝia vivociklo kaj ĝis ĝia eventuala emeritiĝo.
Energia Panelo en Grafana
Kaj tiam aperis COVID-19...
Nia teamo kreas teknologiojn, kiuj rajtigas amaskomunikilajn kompaniojn kaj eldonistojn interrete por helpi vizitantojn trovi koncernajn enhavojn, produktojn kaj servojn, kiuj povas interesi ilin. Nia infrastrukturo estas dizajnita por servi trafikon generitan kiam iuj ekscitaj novaĵoj estas publikigitaj.
La intensa amaskomunikila kovrado ĉirkaŭ COVID-19, kunligita kun la pliiĝo de trafiko, signifis, ke ni urĝe bezonis lerni kiel trakti ĉi tiujn premojn. Krome, ĉio ĉi devis esti farita dum tutmonda krizo, kiam provizoĉenoj estis interrompitaj kaj la plej granda parto de la dungitaro estis hejme.
Sed, kiel ni diris, nia modelo jam supozas tion:
- La ekipaĵo en niaj datumcentroj estas, plejparte, fizike neatingebla por ni;
- Ni faras preskaŭ ĉiujn fizikajn laborojn malproksime;
- Laboro estas farata nesinkrone, aŭtonome kaj grandskale;
- Ni renkontas la postulon pri ekipaĵo uzante la metodon "konstrui el partoj" anstataŭ aĉeti novajn ekipaĵojn;
- Ni havas magazenon, kiu permesas al ni krei ion novan, kaj ne nur fari rutinajn riparojn.
Tiel, la tutmondaj limigoj, kiuj malhelpis multajn kompaniojn akiri fizikan aliron al siaj datumcentroj, malmulte influis nin.Kaj pri rezervaj partoj kaj serviloj, jes, ni provis certigi stabilan funkciadon de la ekipaĵo. Sed tio estis farita kun la celo malhelpi eblajn incidentojn kiam subite montriĝas, ke iu aparataro ne estas disponebla. Ni certigis, ke niaj rezervoj estas plenigitaj sen celante renkonti nunan postulon.
Resume, mi ŝatus diri, ke nia aliro labori en la industrio de datumcentro pruvas, ke eblas apliki la principojn de bona koddezajno al la fizika administrado de datumcentro. Kaj eble vi trovos ĝin interesa.
Originala:
fonto: www.habr.com