One-cloud — andmekeskuse tasemel operatsioonisüsteem Odnoklassnikites

Aloha, inimesed! Minu nimi on Oleg Anastasjev, töötan Klassikaaslaste meeskonnas Platvormi osas. Lisaks mulle töötab Klassikaaslaste juures terve hulk tehnikat. Meil on neli andmekeskust, kus on umbes 500 riiulit üle 8000 serveriga. Ühel hetkel taipasime, et uue juhtimissüsteemi juurutamine võimaldab meil tehnika tõhusamat kasutamist, juurdepääsuhalduse lihtsustamist, arvutusressursside automatiseeritud (taas)jaotamist, uute teenuste käivitamise kiirendamist ning ulatuslike häirete korral kiiremat reageerimist.

Mida me sellest lõppkokkuvõttes saime?

Minu ja hulga tehnikate kõrval on ka inimesi, kes selle tehnikaga töötavad: insenerid, kes on otseselt andmekeskustes; võrguinsenerid, kes seadistavad võrgu infrastruktuuri; administraatorid ehk SRE-d, kes tagavad infrastruktuuri töökindluse; ja arendajate meeskonnad, kellel on igaühel oma osa portaali funktsioonidest. Nende loodud tarkvara töötab umbes niimoodi:

Kasutajate päringud tulevad nii põhiväravatesse www.ok.ru, kui ka muudele, näiteks muusika API frontidele. Need kutsuvad äriloogika töötlemiseks esile rakenduste serveri, mis päringu töötlemisel kutsub vajalikud spetsialiseeritud mikroteenused - one-graph (sotsiaalsete sidemete graaf), user-cache (kasutajaprofiilide vahemälu) jne.

Igaüks neist teenustest on paigaldatud paljudele masinatele ning igal neist on vastutavad arendajad, kes vastutavad moodulite toimimise, nende opereerimise ja tehnoloogilise arengu eest. Kõik need teenused käivitatakse rauas olevatel serveritel, ja kuni hiljutise ajani käivitasime täpselt ühe ülesande ühel serveril, st see oli spetsialiseeritud konkreetsele ülesandele.

Miks nii? Sellel lähenemisel oli mitmeid plusse:

• Lihtsustatakse massiivne haldamine. Oletame, et ülesanne nõuab mingisuguseid teeke, mingisuguseid seadistusi. Sel juhul määratakse server täpselt ühte kindlasse gruppi, sellele grupile kirjeldatakse cfengine poliitika (või see on juba kirjeldatud), ja see konfiguratsioon levitatakse keskelt ja automaatselt kõigile selle grupi serveritele.
• Lihtsustatakse diagnoosimine. Oletame, et vaatad suurenenud protsessori koormust ja mõistad, et selle koormuse võis genereerida ainult see ülesanne, mis töötab sellel raual. Süüdlase otsingud lõppesid väga kiiresti.
• Lihtsustatakse monitooring. Kui serveriga on midagi valesti, teavitab monitor sellest ning tead täpselt, kes on süüdi.

Teenusele, mis koosneb mitmest koopiast, eraldatakse mitu serverit — igaühele oma. Seega antakse teenusele arvutusressursse väga lihtsalt: sama palju ressursse, kui teenusel on servereid, seda ta saab maksimaalselt tarbida. "Lihtne" ei tähenda siin seda, et seda on lihtne kasutada, vaid et ressursi jaotamine toimub käsitsi.

See lähenemine võimaldas meil ka teha spetsialiseeritud raua konfiguratsioone ülesande jaoks, mis toimub sellel serveril. Kui ülesanne hoiab suuri andmehulkasid, kasutame 4U-serverit, mille šassiis on 38 ketast. Kui ülesanne on puhtalt arvutuslik, võime osta odavama 1U-serveri. See on efektiivne arvutusressursside aspektist. Samuti võimaldab see lähenemine meil kasutada neli korda vähem masinaid sama koormuse korral, mis on võrreldav ühe meie sõbralikule sotsiaalvõrgustikule.

Selline arvutusressursside efektiivne kasutamine peaks tagama ka majandusliku efektiivsuse, lähtudes väitest, et kõige kallim on serverid. Pikka aega oli kõige kallim just raua hind ja oleme investeerinud palju ressursse raua hinna alandamisse, välja mõeldes talitlushäirete vältimise algoritmid, et vähendada seadmete töökindluse nõudmisi. Ja täna oleme jõudnud faasi, kus serveri hind ei ole enam määrav. Kui mitte arvesse võtta värsket eksootikat, siis konkreetse serverikonfiguratsiooni paiknemine rackis ei oma tähtsust. Nüüd on meil tekkinud teine probleem — serveri hõivatud ruumi hind andmekeskuses, st ruumi rackis.

Mõistes, et see nii on, otsustasime arvutada, kui tõhusalt me racke kasutame.
Võtsime kõige võimsama serveri hinna, mis on majanduslikult põhjendatud, arvutasime, kui palju selliseid servereid mahub meie rack'idesse ja kui palju ülesandeid saaksime neile määrata, lähtuvalt vanast mudelist "üks server = üks ülesanne" ning kui hästi suudaksid need ülesanded varustust ära kasutada. Tegime arvutusi ja olime üllatunud. Selgus, et rackide kasutusefektiivsus meie juures on umbes 11%. Järeldus on ilmne: andmekeskuste kasutusefektiivsust tuleb parandada. Esmapilgul tundub, et lahendus on lihtne: tuleb ühel serveril samal ajal käivitada mitu ülesannet. Kuid siin tekivad probleemid.

Massiline konfiguratsioon muutub järsult keeruliseks — nüüd ei saa serverile määrata ühte kindlat gruppi. Sest nüüd võivad ühel serveril töötada mitu erinevate meeskondade ülesannet. Lisaks võib konfiguratsioon olla erinevatele rakendustele konfliktselt. Diagnostika muutub samuti keeruliseks: kui saate serveris näha kõrgendatud protsessorite või ketta kasutust, ei tea te, milline ülesanne tekitab probleeme.

Kuid peamine asi on see, et ülesannete vahel, mis on käivitatud ühel masinal, pole isolatsiooni. Näiteks on graafik serveri ülesande keskmisest vastamisajast enne ja pärast seda, kui samal serveril käivitati veel üks, mitte mingil moel seotud arvutusrakendus — peamise ülesande vastamise aeg on oluliselt suurenenud.

Ilmselgelt on vaja ülesandeid käivitada kas konteinerites või virtuaalmasinates. Kuna praktiliselt kõik ülesanded käivitatakse meil ühe operatsioonisüsteemi (Linuxi) all või on selleks kohandatud, ei ole meil vajalik toetada mitmeid erinevaid operatsioonisüsteeme. Seega ei ole virtualiseerimine vajalik; tänu lisaülekandekuludele on see konteineriseerimisest vähem efektiivne.

Docker on konteinerite kasutamise jaoks hea lahendus serverites: failisüsteemi pildid lahendavad hästi konflikti kohanduste probleemid. Pildid, mida saab koostada mitmest kihist, võimaldavad meil oluliselt vähendada andmemahu, mis on vajalik nende juurutamiseks infrastruktuurile, eraldades ühised osad eraldi põhikihidesse. Sel juhul on põhikihid (ja kõige mahukamad) kiiresti vahemällu salvestatud kogu infrastruktuuris ning erinevate rakenduste ja versioonide kohaletoimetamiseks on vajalik edastada ainult väikesemahulisi kihte.

Lisaks pakub valmis register ja piltide märgistamine Dockeris meile valmis primitiivid versioonide haldamiseks ja koodi toimetamiseks tootmisse.

Docker, nagu iga teine sarnane tehnoloogia, pakub meile teatud isolatsioonitaseme konteinerite jaoks. Näiteks mälu isolatsioon – igale konteinerile määratakse masina mälu kasutuspiir, mida ta ei ületa. Samuti saab konteinerite CPU kasutust isoleerida. Ent meie jaoks oli standardne isolatsioon ebapiisav. Kuid sellest allpool.

Konteinerite vahetu käitamine serverites on vaid osa probleemidest. Teine osa on seotud konteinerite paigutamisega serveritesse. Tuleb aru saada, milline konteiner sobib millisele serverile. See ei ole nii lihtne ülesanne, kuna konteinerid tuleb paigutada serveritesse nii tihedalt kui võimalik, samas speedi aeglustamata. Selline paigutamine võib olla keeruline ka tõrkekindluse osas. Sageli soovime paigutada sama teenuse koopiaid erinevatesse riiulitesse või isegi erinevatesse andmekeskuse saalidesse, et korralduste või saali rikke korral ei kaotaks kohe kõiki teenuse koopiaid.

Konteinerite käsitsi jaotamine ei ole variant, kui sul on 8000 serverit ja 8000–16000 konteinerit.

Lisaks soovisime anda arendajatele rohkem iseseisvust ressursside jaotamisel, et nad saaksid oma teenuseid tootmisse paigutada ilma administraatori abita. Samal ajal soovisime hoida kontrolli, et mõni teisejärguline teenus ei kasutaks kõiki meie andmekeskuste ressursse.

On selge, et on vaja halduskihti, mis tegeleks sellega automaatselt.

Siin me oleme lihtsa ja arusaadava pildi juures, mida kõik arhitektid armastavad: kolm ruutu.

one-cloud meistrid — veakindel klaster, mis vastutab pilve orkestreerimise eest. Arendaja saadab meistrile manifesti, mis sisaldab kogu teenuse paigutamiseks vajalikku teavet. Meister annab selle põhjal käsklusi valitud minionidele (masinatele, mis on ette nähtud konteinerite käitamiseks). Minionitel on meie agent, kes saab käskluse, edastab juba oma käsud Dockerile, ning Docker konfigureerib Linuxi tuuma vastava konteineri käivitamiseks. Peale käskude täitmise teatab agent pidevalt meistrile muutustest nii minioni masina seisundis kui ka sellel käivitatavatest konteineritest.

Resursside jaotamine

Ja nüüd vaatame keerulisemat ülesannet, mis on ressursside jaotamine mitmete minionide jaoks.

Küsimus one-cloudi arvutusressursside kohta on:

• Protsessori arvutusvõime, mida konkreetne ülesanne tarbib.
• Mälu maht, mis on ülesandele saadaval.
• Void: iga minionil on spetsiaalne võrguliides piiratud ribalaiusega, seetõttu ei saa ülesandeid jaotada, arvestamata nende kaudu edastatavaid andmehulki.
• Kettad. Peale ilmselgelt andmete hoidmiseks mõeldud ruumi määrame ka ketta tüübi: HDD või SSD. Kettad saavad teenindada lõpetatud päringute arvu sekundis — IOPS. Seega, ülesannete puhul, mis genereerivad rohkem IOPS, kui üks ketas suudab teenindada, määrame eraldi 'spindlid' — st kettaseadmed, mis peavad olema rangelt reserveeritud ülesande jaoks.

Nii et mõne teenuse, näiteks user-cache'i, jaoks saame ressursid registreerida järgmiselt: 400 protsessorituuma, 2,5 TB mälu, 50 Gbit/s liiklust mõlemas suunas, 6 TB ruumi HDD-l, mis on paigutatud 100 spindlile. Või meie jaoks tuttavamas vormis nii:

alloc:
    cpu: 400
    mem: 2500
    lan_in: 50g
    lan_out: 50g
    hdd:100x6T

User-cache'i teenuse ressursid kasutavad vaid osa kõigist tootmistehnoloogiliste süsteemide kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt, seetõttu tahame saavutada, et user-cache ei kasutaks ootamatult, olenemata operaatori veast või mitte, rohkem ressursse, kui talle on määratud. See tähendab, et peame ressursse piiritama. Aga millega me saame kvooti siduda?

Naasime tagasi meie tugevalt lihtsustatud koostisosade koostööskeemi ja joonistame selle ümber suurema detailiga — nii.

Mida tähele panna:

• Veebi esikülg ja muusika kasutavad sama rakenduste serveri isoleeritud klastreid.
• Võime tuvastada loogilised kihid, mis hõlmavad neid klastreid: esifront, vahemälud, andmete salvestamise ja haldamise kiht.
• Esikülg ei ole homogeenne, need on erinevad funktsionaalsed alamsüsteemid.
• Vahemälud saab samuti jagada alamsüsteemide vahel, mille andmeid nad vahemälusse salvestavad.

Korrake pildi joonistamist:

Vau! Me näeme hierarhiat! See tähendab, et ressursse on võimalik jaotada suuremates plokkides: määrata vastutav arendaja selle hierarchia sõlme, mis vastab funktsionaalsele alamsüsteemile (nagu „muusika” pildil), ja siduda selle sama hierarhiatasemega kvota. Selline hierarhia võimaldab meil ka paindlikumalt korraldada teenuseid haldamise mugavuse huvides. Näiteks kõik web, kuna see on väga suur serverite rühm, jagame mitmeks väiksemaks grupiks, mida pildil on näidatud kui group1, group2.

Eemaldades liigsed jooned, saame iga meie pildi sõlme jäädvustada mitmekihilise kujul: group1.web.front, api.music.front, user-cache.cache.

Nii jõuame mõisteteni „hierarhiline järjekord”. Sellel on nimi, nagu „group1.web.front”. Talle määratakse ressursikvoot ja kasutajaõigused. DevOps inimesel on õigus saata teenuse järjekorda ja selline töötaja võib järjekorras midagi käivitada, seevastu OpsDev’ile antakse administraatoriõigused, mis annab talle võimaluse järjekorda hallata, seal inimesi määrata, nendele õigusi anda jne. Selle järjekorras käivitatavad teenused töötavad järjekorra kvoodi piirides. Kui järjekorra arvutite kvoot ei piisa kõigi teenuste samaaegseks käivitamiseks, käivitatakse need järjestikku, moodustades sellega tegeliku järjekorra.

Vaadakem teenuseid lähemalt. Igal teenusel on täielik nimi, mis alati sisaldab järjekorra nime. Seega, web esifront teenusel on nimi ok-web.group1.web.front. Ja rakenduste serveriteenusel, millega ta ühendust võtab, saab olema nimeks ok-app.group1.web.front. Igal teenusel on manifest, kus on kirjas kogu vajalik teave paigutamiseks konkreetsetesse masinatesse: kui palju ressursse see ülesanne tarbib, milline konfiguratsioon on vajalik, kui palju koopiaid peab olema, teenuse tõrke töötlemise omadused. Ja pärast teenuse paigutamist otse masinatesse tekivad selle eksemplarid. Need on samuti unikaalselt nimetatud — eksemplari numbri ja teenuse nimega: 1.ok-web.group1.web.front, 2.ok-web.group1.web.front, …

See on väga mugav: vaadates ainult käivitatud konteineri nime, saame kohe palju teada.

Ja nüüd tutvume lähemalt, mida need eksemplarid tegelikult teevad: ülesannete täitmisega.

Ülesannete isolatsiooniklassid

Kõik ülesanded OK-s (ja ilmselt igal pool mujal) saab jagada rühmadesse:

• Lühikese latentsusega ülesanded — prod. Selliste ülesannete ja teenuste jaoks on vastuse latentsus (latency) väga oluline, kui kiiresti iga päring süsteemi poolt töödeldakse. Näited ülesannetest: veebifrontid, vahemälud, rakenduste serverid, OLTP ladustamisruumid jne.
• Arvutusalased ülesanded — batch. Siin pole iga konkreetse päringu töötlemise kiirus oluline. Neile on oluline, kui palju arvutusi see ülesanne teatud (suure) ajavahemiku jooksul teeb (throughput). Sellisteks on igasugused MapReduce ülesanded, Hadoop, masinõpe, statistika.
• Taustal töötavad ülesanded — idle. Selliste ülesannete jaoks ei ole latentsus ega läbi viidud töötlemise kiirus eriti olulised. Siia kuuluvad erinevad testid, migratsioonid, ümberarvutamised, andmete konverteerimised ühest formaadist teise. Ühelt poolt sarnanevad nad arvutuslikele, teisalt — me ei pea väga oluliseks, kui kiiresti need lõpule jõuavad.

Vaatame, kuidas sellised ülesanded tarbivad ressursse, näiteks keskprotsessorit.

Lühikese latentsusega ülesanded. Sellise ülesande CPU tarbimise muster sarnaneb järgmisele:

Kasutajalt saabub päring, ülesanne hakkab kasutama kõik saadaval olevaid CPU tuumasid, töötleb, tagastab vastuse, ootab järgmist päringut ja seisab. Järgnev päring saabus — uuesti valisime kõik, mis oli, arvutasime läbi, ootame järgmist.

Tagamaks, et sellise ülesande latentsus oleks minimaalne, peame võtma maksimumi selle tarbimistest ja reserveerima vajalikud tuumad minjonile (masinale, mis peab ülesannet täitma). Seega on meie ülesande reserveerimise valem järgmine:

alloc: cpu = 4 (max)

Ja kui meil on 16 tuuma minion-masin, siis saame sellele paigutada täpselt neli sellist ülesannet. Eriti märgime, et nende ülesannete keskmine protsessoritarve on sageli väga madal — mis on ilmne, kuna suure osa ajast on ülesanne ooteolekus ja ei tee midagi.

Arvutamisülesanded. Neil on musternäide veidi erinev:

Selliste ülesannete keskmine protsessoritarve on piisavalt kõrge. Sageli tahame, et arvutamisülesanne täidetaks teatud ajavahemikus, seega tuleb reserveerida minimaalne protsessorite arv, mis on vajalik, et kogu arvutus lõpetataks vastuvõetava ajaga. Tema reserveerimise valem näeb välja järgmine:

alloc: cpu = [1,*)

„Palun paigalda see minioni, kus on vähemalt üks vaba tuum, ja edasi, mis iganes on — kõik läheb.”

Siin on ressursi kasutamise efektiivsus juba oluliselt parem kui lühikese viivitusega ülesannete puhul. Kuid kasu oleks palju suurem, kui kombineerida mõlemat tüüpi ülesandeid ühel minion-masinal ja jagada selle ressursse jooksvalt. Kui lühikese viivitusega ülesanne vajab protsessorit — saab ta selle kohe, ja kui ressursid ei ole enam vajalikud — edastatakse need arvutamisülesandele, st midagi sellist:

Aga kuidas seda teha?

Käime esmalt läbi prod ja tema alloc: cpu = 4. Me peame reserveerima neli tuuma. Docker run'is saab seda teha kahes viisist:

• Kasutades valikut --cpuset=1-4, st määrata ülesandele neli kindlat tuuma masinal.
• Kasutage --cpuquota=400_000 --cpuperiod=100_000, määrata kvota protsessoriaja, st näidata, et iga 100 ms reaalaega ülesanne tarbib mitte rohkem kui 400 ms protsessoriaega. Saame samad neli tuuma.

Aga milline neist viisidest sobib?

Cpuset näeb üsna atraktiivne välja. Ülesandel on neli pühendatud tuuma, mis tähendab, et protsessori vahemälud töötavad maksimaalselt efektiivselt. Sellel on ka tagasilööke: me peame võtma ülesande jagada arvutusi masin mittekoormatud tuumade vahel OS-i asemel, mis on üsna mitmekesine ülesanne, eriti kui püüame selles masinas käitada partiiülesandeid. Testid näitasid, et siin sobib paremini kvota variant: sel juhul on operatsioonisüsteemil rohkem vabadust ülesande täitmiseks tuuma valimisel hetkel ja protsessori aeg jaotub efektiivsemalt.

Selgitame, kuidas Dockeris alustada minimaalset tuumade reservi. Kvota partiiülesannete jaoks ei ole enam rakendatav, sest maksimumi piiramine ei ole vajalik, piisab vaid miinimumi tagamisest. Ja siia sobib hästi valik docker run --cpushares.

Oleme kokku leppinud, et kui partii nõuab garantii ühele tuumale, siis me määrame --cpushares=1024, ja kui minimaalselt kahel tuumal, siis määrame --cpushares=2048. Protsessori aktsiad ei sega protsessori aja jaotust, kuni aega piisab. Nii et kui prod ei kasuta hetkel kõiki nelja tuuma — ei ole midagi, mis piiraks partiiülesandeid, ja need saavad kasutada täiendavat protsessori aega. Kuid protsessori puuduse korral, kui prod on tarbinud kõik neli tuuma ja jõudnud kvotani — ülejäänud protsessori aeg jagatakse proportsionaalselt cpushares, st kolme vaba tuuma korral saab üks ülesanne 1024 cpushares ja ülejäänud kaks — 2048 cpushares.

Kuid kvota ja aktsiate kasutamine ei piisa. Peame tagama, et lühikese latentsuse ülesanne saaks prioriteedi partiiülesande ees protsessori aja jaotamisel. Ilma sellise prioriseerimiseta võtab partiiülesanne kogu protsessori aja hetkel, kui see on vajalik prod-ile. Docker runis ei ole mingit konteinerite prioriseerimise valikut, kuid CPU planeerija poliitikad Linuxis tulevad appi. Nendest saab lähemalt lugeda siit, kuid käesolevas artiklis käsitleme neid lühidalt:

• SCHED_OTHER
  Saavad vaikimisi kõik tavalised kasutaja protsessid Linuxi masinas.
• SCHED_BATCH
  Mõeldud ressursimahukate protsesside jaoks. Kui ülesanne protsessorisse suunatakse, kehtestatakse nn aktiveerimise trahv: selline ülesanne saab tõenäoliselt vähem protsessorit, kui seda kasutab ülesanne SCHED_OTHER.
• SCHED_IDLE
  Taustprotsess väga madala prioriteediga, isegi madalam kui nice –19. Me kasutame oma avatud lähtekoodiga raamatukogu. one-nio, et seadistada vajalik poliitika konteineri käivitamisel kutsumisega

one.nio.os.Proc.sched_setscheduler( pid, Proc.SCHED_IDLE )

Kuid isegi kui te ei programmeeri Java-s, saab sama teha käsuga chrt:

chrt -i 0 $pid

Kokkuvõtlikult koondame kõik meie isolatsiooni tasemed ühte tabelisse, et oleks selgem:

Isolatsiooni klass
Näide alloc
Docker run valikud
sched_setscheduler chrt*

Prod
cpu = 4
--cpuquota=400000 --cpuperiod=100000
SCHED_OTHER

Batch
Cpu = [1, * )
--cpushares=1024
SCHED_BATCH

Idle
Cpu= [2, *)
--cpushares=2048
SCHED_IDLE

*Kui teete chrt konteineri seest, võib olla vajalik capability sys_nice, kuna Docker eemaldab selle capability konteineri käivitamisel vaikimisi.

Kuid ülesanded tarbivad mitte ainult protsessorit, vaid ka liiklust, mis mõjutab võrguülesande viivitust rohkem kui vale protsessorite jaotamine. Seetõttu tahame loomulikult saada sarnase pildi ka liiklusest. See tähendab, et kui prod-ülesanne saadab mõningaid pakette võrku, kvoteerime maksimaalse kiirus (valem alloc: lan=[*,500mbps) ), millega prod seda teha saab. Ja batch jaoks garanteerime ainult minimaalset läbilaskvust, kuid ei piira maksimaalset (valem alloc: lan=[10Mbps,*) ) Sel juhul peab prod liiklus olema kõrgema prioriteediga võrreldes batch-ülesannetega.
Siin pole Dockeril mingeid primitiive, mida me saaksime kasutada. Kuid meie abiks tuleb Linuxi liikluseregulatsioon. Oleme vajalikku tulemust saavutanud disipliini abil Hierarchical Fair Service Curve. Selle abil eraldame kaks liikluse klassi: kõrgema prioriteediga prod ja madalama prioriteediga batch/idle. Lõppkokkuvõttes on saateliikluse konfiguratsioon järgmine:

siin 1:0 — "juurne qdisc" distsipliin hsfc; 1:1 — alamhierarhia hsfc, millel on üldine ribalaiuse limiit 8 Gbit/s, kuhu kuuluvad kõik konteinerite alamhierarhiad; 1:2 — alamhierarhia hsfc, mis on ühine kõigi batch ja idle ülesannete jaoks "dünaamilise" limiidiga, mille kohta räägime allpool. Ülejäänud alamhierarhiad hsfc on eraldatud klassid hetkel töötavatele prod-konteineritele limiitidega, mis vastavad nende manifestidele — 450 ja 400 Mbit/s. Iga klassile hsfc on määratud qdisc järjekord fq või fq_codel, sõltuvalt linuxi tuumaversioonist, et vältida paketikaotust liikluspuhangute ajal.

Tavaliselt teenivad tc distsipliinid ainult väljamineva liikluse prioriseerimist. Kuid me tahame prioriseerida ka sissetulevat liiklust — nimelt võib mõni batch-ülesanne hõivata kogu sissetuleva kanali, saades näiteks suurt paketti sissetulevaid andmeid map&reduce jaoks. Selle jaoks kasutame moodulit ifb, mis loob virtuaalse liidese ifbX iga võrku liidese jaoks ja suunab sissetuleva liikluse liideselt väljaminevaks ifbX-le. Edasi töötavad kõik need samad distsipliinid väljamineva liikluse juhtimiseks, mille jaoks hsfc konfiguratsioon on väga sarnane:

Katsed on näidanud, et parimad tulemused hsfc saavutatakse siis, kui klass 1:2 prioriteedita batch/idle liiklust piiratakse masinatel-minionidel mitte rohkem kui teatud vabale ribalaiusele. Vastasel juhul mõjutab prioriteedita liiklus liiga palju prod-ülesannete latentsust. Praeguse vabade ribalaiuste suuruse määrab miniond iga sekundi tagant, mõõtes masinatega seotud prod-ülesannete keskmist liikluskasutust ja lahutades selle võrgu liidese ribalaiusest väikese varuga, st.

Ribalaiused määratakse sõltumatult sissetulevale ja väljaminevale liiklusele. Ja vastavalt uutele väärtustele miniond konfigureerib 1:2 prioriteedita klassi limiidi ümber.

Seega oleme saavutanud kõik kolm isolatsiooniklassi: prod, batch ja idle. Need klassid mõjutavad tugevalt ülesannete täitmise omadusi. Seetõttu otsustasime, et see tunnus tuleb asetada hierarhia tippu, et vaadates hierarhilise järjekorra nime oleks kohe selge, millega me tegeleme:

Kõik meie tuttavad web ja music frontid asetatakse siis hierarhiatesse prod alla. Näiteks asetame batch alla teenuse music catalog, mis perioodiliselt koostab lugude katalooge komplektist üleslaetud "Odnoklassniki" mp3-failidest. Ja näitena idle teenusest võib tuua muusikamuundur, mis normaliseerib muusika helitaseme.

Eemaldades taaskord liigsed read, saame kirjutada oma teenuste nimed nutikamalt, lisades teenuse täisnime lõppu ülesande isolatsiooni klassi: web.front.prod, catalog.music.batch, transformer.music.idle.

Ja nüüd, vaadates teenuse nime, mõistame mitte ainult seda, millist funktsiooni ta täidab, vaid ka tema isolatsiooni klassi, mis näitab tema kriitilisust jne.

Kõik on suurepärane, kuid on üks kibedat tõde. Ükski ülesandeid, mis töötavad samas masinas, ei saa täielikult isoleerida.

Mida me oleme suutnud saavutada: kui batch tarbib intensiivselt seda protsessori ressursse, siis Linuxi sisseehitatud protsessoriplaneerija täidab oma ülesande väga hästi ja sellel pole praktiliselt mingit mõju prod-ülesandele. Kuid kui see batch-ülesanne hakkab aktiivselt töötama mäluga, siis mõju on juba tajutav. See juhtub seetõttu, et prod-ülesande puhul "voolavad" protsessorikandjad mälust välja — lõpptulemusena kasvavad vahepead ja protsessor töötleb prod-ülesannet aeglasemalt. Tüüpiline batch-ülesanne võib suurendada meie tüüpilise prod-konteineri latentsust 10%.

Liiklust on veelgi raskem isoleerida, kuna tänapäevastes võrgukaartides on paigutatud pakettide sisemine järjekord. Kui pakett onde batch-ülesandest on sinna sattunud esimesena, siis tema edastamine kaabli kaudu toimub ka esimesena, ja siin ei ole midagi teha.

Lisaks oleme seni suutnud lahendada ainult TCP-liikluse prioriseerimise ülesande: UDP puhul ei toimi lähenemine hsfc. Ja isegi TCP-liikluse puhul, kui batch-ülesanne genereerib palju liiklust, annab see samuti umbes 10% suurenemise prod-ülesande latentsuses.

Talitluskatkestustunne

Üks eesmärke one-cloud'i arendamisel oli parendada Odnoklassniki' s tõrkele vastu pidavust. Seega soovin nüüd üksikasjalikumalt uurida võimalikke tõrke- ja avariisüsteeme. Alustame lihtsast stsenaariumist — konteineri tõrkest.

Konteiner võib ebaõnnestuda mitmel viisil. See võib olla mingi eksperiment, tõrge või vigane manifest, mille tõttu prod-ülesanne hakkab tarbima rohkem ressursse kui manifestis ette nähtud. Meil oli juhtum: arendaja rakendas ühe keerulise algoritmi, tegi seda mitmel korral ümber, segas end nii ära, et lõpuks hakkas ülesanne üsna keeruliselt lõppema. Kuna prod-ülesanne on prioriteetsem kui kõik teised samadel minionitel, hakkas see tarbima kõiki saadaval olevaid CPU ressursse. Sellises olukorras aitas isolatsioon, täpsemalt CPU ajakvoot. Kui ülesandele on määratud kvoot, ei tarbita rohkem. Seetõttu ei märganud batch- ja teised prod-ülesanded, mis töötasid samal masinal, midagi.

Teine võimalik probleem on konteineri kokkuvarisemine. Ja siin aitavad meid restart-poliitikad, mida kõik tunnevad, Docker ise hoolitseb selle eest kenasti. Peaaegu kõik prod-ülesanded omavad restart-poliitikat always. Mõnikord kasutame on_failure batch-ülesannete või prod-konteinerite silumiseks.

Aga mida teha, kui terve minion on mittesaadav?

Ilmselt tuleb konteiner käivitada teisel masinal. Kõige huvitavam on see, mis juhtub konteinerile määratud IP-aadressidega.

Saame määrata konteineritele sama IP-aadressi nagu masinatel, millel need konteinerid töötavad. Seega, kui konteiner käivitatakse teisel masinal, muutub selle IP-aadress ning kõik kliendid peavad mõistma, et konteiner on kolinud, nüüd tuleb minna uuele aadressile, mis nõuab eraldi teenust Service Discovery.

Service Discovery on mugav. Turul on palju lahendusi erineva tõrkekindluse tasemega teenuste registri korraldamiseks. Sageli sisaldavad sellised lahendused koormuse tasakaalustusloogika ja täiendava konfiguratsiooni hoidmise KV-hoidlas jne.
Kuid sooviksime läbi saada ilma eraldi registri rakendamata, sest see tähendaks kriitilise süsteemi sisseseadmist, mida kasutavad kõik teenused tootmises. Seega on see potentsiaalne tõrkepunkt ning tuleb valida või välja töötada väga tõrkekindel lahendus, mis on ilmselgelt väga keeruline, aeganõudev ja kallis.

Ja veel üks suur puudus: et meie vana infrastruktuur töötaks koos uuega, oleks pidanud ümber kirjutama kõik ülesanded millelegi, mis kasutab Service Discovery süsteemi. Töö on ÄÄRMUSLIKULT palju, ja kohati isegi võimatu, kui jutt on madala tasemega seadmetest, mis töötavad opsüsteemi kerneli tasemel või otse riistvara küljes. Selle funktsionaalsuse rakendamine tuntud lahenduste mustrite abil, nagu näiteks side-car tähendaks kohati täiendavat koormust, kohati — kasutamise keerukuse suurenemist ja täiendavaid tõrke stsenaariume. Meile ei meeldinud keerukuse suurendamine, seetõttu otsustasime muuta Service Discovery kasutamise valikuliseks.

one-cloudis järgneb IP konteinerile, st. igal ülesande eksemplaril on oma IP-aadress. See aadress on "staatiline": see kinnitatakse iga eksemplari puhul teenuse esmakordsel pilve saatmisel. Kui teenuse elu jooksul on olnud erinev arv eksemplare, siis lõpuks kinnitatakse temaga nii palju IP-aadresse, kui eksemplare kunagi kokku on olnud.

Hiljem need aadressid ei muutu: need on antud ainult üks kord ja püsivad terve teenuse elu jooksul produktsioonis. IP-aadressid järgivad konteinerite võrku. Kui konteiner liigub teise minioni, siis järgneb aadress ka temale.

Seega muutub teenuse nime ja selle IP-aadresside loendi seos väga harva. Kui vaadata veelkord teenuse eksemplaride nimesid, mida me artikli alguses mainisime (1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod, …), siis märkame, et need meenutavad DNS-is kasutatavaid FQDN-e. See on tõsi, teenuste eksemplaride nimede kuvamiseks nende IP-aadressides kasutame DNS-protokolli. Veelgi enam, see DNS tagastab kõik broneeritud IP-aadressid kõikidele konteineritele — nii töötavatele kui ka peatatud (kui meil on näiteks kolm koopiat, kuid viis aadressi on broneeritud — kõik viis aadressi tagastatakse). Klient, kes on selle teabe saanud, proovib luua ühendust kõigi viie koopiaga — ja määrab seega need, mis töötavad. See kättesaadavuse määramise variant on oluliselt usaldusväärsem, kuna see ei hõlma ei DNS-i ega teenuse avastamist, seega ei ole probleemi teabe ajakohasuse ja nende süsteemide tõrketaluvusega. Veelgi enam, kriitiliste teenuste puhul, mis sõltuvad kogu portaali töökindlusest, ei pea me DNS-i kasutama, vaid saame lihtsalt konfigureerida IP-aadresid.

Sellise IP-aadresside ülekande rakendamine konteinerite vahel võib olla keeruline — ja peatume selle toimimise juures järgmise näite abil:

Oletame, et one-cloudi meister annab käsu minion M1-l käivitada 1.ok-web.group1.web.front.prod aadressiga 1.1.1.1. Minionis töötab BIRD, mis kuulutab selle aadressi spetsiaalsetele serveritele route reflector. Viimastel on BGP-seanss võrguseadmest, kuhu transleeritakse marsruut aadressile 1.1.1.1 M1-l. M1 marsüreerib paketid konteinerisse juba Linuxi vahenditega. Route reflector'e servereid on kolm, kuna see on one-cloudi infrastruktuuri väga kriitiline osa — ilma nendeta ei tööta one-cloudis võrk. Paigutame need erinevatesse rack'idesse, võimaluse korral erinevatesse andmekeskuse saalidesse, et vähendada kõigi kolme samaaegse rikke tõenäosust.

Kujutame nüüd ette, et side one-cloudi meistri ja minion M1 vahel on kadunud. One-cloudi meister tegutseb nüüd oletuse põhjal, et M1 on täielikult ebaõnnestunud. See tähendab, et ta annab käsu minion M2-l käivitada web.group1.web.front.prod sama aadress 1.1.1.1. Nüüd on meil kaks konfliktset marsruuti võrgus aadressile 1.1.1.1: M1-l ja M2-l. Selliste konfliktide lahendamiseks kasutame Multi Exit Discriminatorit, mis määratakse BGP-teate kaudu. See number näitab kuulutatud marsruudi kaalu. Konfliktide korral valitakse marsruut väiksema MED-i väärtusega. One-cloudi domineerija toetab MED-i konteinerite IP-aadresside lahutamatu osana. Esmakordselt määratakse aadress piisavalt suure MED-iga = 1 000 000. Kui toimub selline hädaolukorra konteineri üleviimine, vähendab domineerija MED-i, ning M2 saab käsu kuulutada aadress 1.1.1.1 MED-iga = 999 999. Samal ajal jääb M1-l töötav näidis side puudumise tõttu ilma, ja selle edasine saatus ei ole meile oluline, kuni side taastub domineerijaga, mil ta peatatakse kui vana dubleerimine.

Hädad

Kõik andmekeskuste haldussüsteemid töötavad alati hästi välja väikseid rikkeid. Konteineri väljalangevus on enamikus kohtades norm.

Vaatame, kuidas me töötleme hädaolukorda, näiteks toitekatkestust ühes või enamas andmekeskuse saalis.

Mida tähendab avaria andmekeskuse haldussüsteemile? Esiteks on see massiline samal ajal toimuv mitme masina rike ning haldussüsteem peab samal ajal migreerima väga palju konteineri. Kuid kui avaria on väga ulatuslik, võib juhtuda nii, et kõiki ülesandeid ei saa teistele minionidele üle viia, kuna andmekeskuse ressursi maht langeb alla 100% koormusele.

Sageli kaasnevad hädad haldamise kihi rikke ning. See võib juhtuda, kuna selle varustus ebaõnnestub, kuid sagedamini seetõttu, et hädasid ei testita ning juhtimiskihid kukuvad ise kokku suurenenud koormuse tõttu.

Mida selle kõigega teha?

Massiivsed migreerimised tähendavad, et infrastruktuuris tekib suur hulk toiminguid, migreerimisi ja paigutusi. Iga migreerimine võib võtta aega, mis on vajalik konteinerite piltide kohaletoimetamiseks ja lahtipakkimiseks minionidel, konteinerite käivitamiseks ja initsialiseerimiseks jne. Seetõttu on soovitatav, et olulised ülesanded käivitatakse enne vähem olulisi.

Vaadakem uuesti tuttavat teenuste hierarhiat ja proovime otsustada, milliseid ülesandeid tahame esmalt käivitada.

Loomulikult on need protsessid, mis osalevad otseselt kasutaja päringute töötlemises, st prod. Me näitame seda paigutamise prioriteedi — numbreid, mis võivad olla määratud järjekorrale. Kui mõnel järjekorral on kõrgem prioriteet, paigutatakse selle teenused esimesena.

Prodis määrame kõrgemad prioriteedid, 0; batch-lähenemisel veidi madalam, 100; idle puhul veel madalam, 200. Prioriteedid rakendatakse hierarhiliselt. Kõikidel madalama taseme ülesannetel on vastav prioriteet. Kui soovime, et prodis käivituksid vahemälud enne esipinda, määrame vahemälu prioriteedi = 0 ja esipinna alamjärjekorrale = 1. Kui aga soovime, et esipindade seas käivituks esmalt põhivärav ja alles seejärel muusika front, siis võime viimasel määrata madalama prioriteedi — 10.

Järgmine probleem on ressursside puudus. Nii et meil on suures koguses varustust välja langenud, terveid andmekeskuse saale, ja oleme käivitanud nii palju teenuseid, et nüüd ei piisa ressursse kõigi jaoks. Peame otsustama, milliste ülesannetega ohverdada, et peamised kriitilised teenused töötaksid.

Erinevalt paigutamise prioriteedist ei saa me lihtsalt ohverdada kõiki batch-ülesandeid, mõned neist on portaali töö jaoks olulised. Seetõttu oleme eraldi välja toonud väljaarvamise prioriteedi ülesanne. Paigutamisel võib kõrgema prioriteediga ülesanne välja arvata, st peatada madalama prioriteediga ülesande, kui vabu minione enam ei ole. Samuti on madalama prioriteediga ülesanne tõenäoliselt ei paigutata, st sellele ei ole enam sobivat minionit piisava vabade ressurssidega.

Meie hierarchias on väga lihtne määrata selline väljaarvamise prioriteet, et prod- ja batch-ülesanded väljaaravad või peatavad idle-ülesandeid, kuid mitte üksteist, määrates idle jaoks prioriteedi, mis on võrdne 200. Nagu ka paigutamise prioriteedi puhul, saame kasutada meie hierarhiat, et kirjeldada keerukamaid reegleid. Näiteks saame määrata, et muusikafunktsiooniga ohverdame, kui meil ei piisa ressursse peamise veebiportaaliga, määrates vastavatele sõlmedele madalama prioriteedi: 10.

Andmekeskuse õnnetused täielikult

Miks võib kogu andmekeskus ebaõnnestuda? Loodusõnnetused. Oli hea postitus, kuidas orkan mõjutas andmekeskuse tööd. Elus võib pidada kodutuks inimeseks, kes ühel päeval hävitas optika kanaliseerimisse, mistõttu kaotas andmekeskus täielikult ühenduse teiste lokaliseerimistega. Rikkumise põhjuseks võib olla ka inimfaktor: operaator annab sellise käsu, et kogu andmekeskus kukub kokku. See võib juhtuda suurte vigade tõttu. Üldiselt, andmekeskuste tõrkeid esineb — see ei ole haruldane. Meil toimub see paar korda kuus.

Ja see on see, mida me teeme, et keegi #okelama ei postita Twitters.

Esimene strateegia on isoleerimine. Iga instance one-cloud on täielikult isoleeritud ja saab hallata masinate vaid ühes andmekeskuses. See tähendab, et pilve kaotus vigade või vale käsu tõttu operaatori poolt on kaotuseks vaid ühes andmekeskuses. Oleme sellele valmis: meil on varukoopiapoliitika, mille raames rakenduste ja andmete koopiad paigutatakse kõigis andmekeskustes. Kasutame vigadekindlaid andmebaase ja testime aeg-ajalt tõrkeid.
Kuna meil on täna neli andmekeskust, on ka neli eraldi, täielikult isoleeritud one-cloudi eksemplari.

Selline lähenemine kaitseb mitte ainult füüsiliste tõrgete eest, vaid võib kaitsta ka operaatori vigade eest.

Ja mida veel saab teha inimfaktoriga? Kui operaator annab pilvele mingi imeliku või potentsiaalselt ohtliku käsu, võib ta ootamatult pidada lahendama väikese ülesande, et kontrollida, kui hästi ta mõtles. Näiteks kui see on mingi massiline peatamine paljude koopiate puhul või lihtsalt kummaline käsk — koopiate arvu vähendamine või pildi nime muutmine, mitte ainult versiooni numbri muutmine uues manifestis.

Summary

One-cloudi eripära:

• Hierarhiline ja silmapaistev teenuste ja konteinerite nimetamise skeem, mis võimaldab väga kiiresti teada saada, mis see ülesanne on, millega see seondub ja kuidas see töötab ja kes on selle eest vastutav.
• Kasutame oma tehnika ühildamise prod- ja batch-ülesannete peal minionidel, et suurendada masinate ühisarendamise tõhusust. Cpuseti asemel kasutame CPU kvoote, aktsiaid, CPU ajajuhtimise poliitikaid ja Linuxi QoS-i.
• Konteinereid, mis töötavad ühel masinal, ei suutnud täielikult isoleerida, kuid nende omavaheline mõju jääb 20% piiresse.
• Teenuste korraldamine hierarhias aitab automaatse avarii likvideerimise korral paigutamise ja kõrvalduste prioriteetide abil.

KKK

Miks me ei valinud valmislahendust.

• Erinevad tööülesannete isoleerimise klassid nõuavad erinevat loogikat minionide paigutamisel. Kui tootmisseotud ülesandeid saab paigutada lihtsalt ressursside reserveerimise kaudu, tuleb batch ja idle ülesandeid paigutada, jälgides minionide masinatel tegelikku ressursside kasutust.
• Tegemist on ülesannete tarbitavate ressursside arvestamise vajadusega, nagu:
  • võrgu läbilaskevõime;
  • ketaste tüübid ja „spindlid“.
• Teenuste prioriteetide määramise vajadus hädaolukordade likvideerimise puhul, meeskondade õiguste ja kvotade määramine ressurssidele, mida lahendatakse one-cloudis hierarhiliste järjekordade abil.
• Vajadus omada inimlikku nimetust konteineritele, et vähendada reageerimisaega hädaolukordadele ja intsidentidele.
• Üheainsa ja ulatusliku Service Discovery rakendamise võimatus; vajadus koos eksisteerida pikalt raudvarale paigutatud ülesannetega - see lahendatakse konteinerite jälitamise kaudu „staatiliste“ IP-aadresside abil ja seeläbi ainulaadne integreerimine suure võrguinfrastruktuuriga.

Kõik need funktsioonid nõuaksid olemasolevate lahenduste põhjalikku ümbertegemist ning hinnates töömahtu jõudsime arusaamale, et saame välja töötada oma lahenduse ligikaudu samade tööjõuressurssidega. Kuid meie lahendus on oluliselt lihtsam käitada ja arendada - selles ei ole tarbetuid abstraktsioone, mis toetavad meile mittevajalikke funktsioone.

Neile, kes loevad viimaseid ridu - aitäh kannatlikkuse ja tähelepanu eest!

Allikas: habr.com