One-cloud — andmekeskuse taseme opsüsteem Odnoklassnikutes

Aloha, inimesed! Minu nimi on Oleg Anastasyev, töötan Odnoklassnikis Platvormi meeskonnas. Lisaks mulle töötab Odnoklassnikis suur hulk seadmeid. Meil on neli andmekeskust, milles on umbes 500 riiulit üle 8000 serveri. Ühel hetkel mõistsime, et uue juhtimissüsteemi rakendamine võimaldab meil tehnika kasutust tõhusamalt koormata, juurdepääsude haldamist lihtsustada, arvutusressursside (uuesti) jaotamist automatiseerida, uusi teenuseid kiiremini käivitada ja suurte avariide korral reageerimisaega kiirendada.

Mida me selle tulemusena saavutasime?

Lisaks mulle ja suurtele seadmetele on veel inimesi, kes nendega töötavad: insenerid, kes asuvad andmekeskustes; võrguinsenerid, kes seadistavad võrgulahendusi; adminnid ehk SRE-d, kes tagavad infrastruktuuri töökindluse; ja arendustiimid, kellest igaühel on oma roll portaali funktsioonides. Nende loodud tarkvara töötab umbes nii:

Kasutajate päringud saadetakse peamise portaali frontide kaudu www.ok.ru, ja ka teistele, näiteks muusika API frontendidele. Need töötlevad äri loogikat, kutsudes esile rakenduste serverit, mis vajadusel kutsub välja vajalikud spetsialiseeritud mikroteenused — one-graph (sotsiaalsete suhete graafik), user-cache (kasutajaprofiilide vahemälu) jne.

Igaüks neist teenustest on paigutatud paljudele masinatele ning igal neist on vastutavad arendajad, kes vastutavad moodulite toimimise, nende hoolduse ja tehnoloogilise arengu eest. Kõik need teenused käivitatakse raudserveritel, ja kuni hiljutise ajani käivitasime täpselt ühe ülesande ühe serveri peal, st see oli spetsialiseeritud konkreetsele ülesandele.

Miks nii? Sellel lähenemisel oli mitu eelist:

• Kergendab massilist haldust. Oletame, et ülesanne vajab teatud teeke, teatud seadeid. Ja siis kantakse server täpselt ühte kindlasse gruppi, kirjeldatakse selle grupi cfengine poliitikat (või see on juba kirjeldatud), ja see konfiguratsioon rakendatakse keskendunult ja automaatselt kõikidele selle grupi serveritele.
• Lihtsustab diagnostikat. Oletat, et vaatate suurenenud protsessori koormust ja mõistate, et selle koormuse võis genereerida ainult see ülesanne, mis töötab sellel raual. Süüdlaste leidmine lõppema väga kiiresti.
• Lihtsustab jälgimist,. Kui serveriga on midagi valesti, teatab monitor sellest, ja te teate täpselt, kes on süüdi.

Teenusele, mis koosneb mitmest koopiast, eraldatakse mitu serverit — igaühele üks. Nii et teenuse arvutusressursi jaotamine on väga lihtne: nii palju servereid, kui teenusel on, nii palju ressursse ta maksimaalselt tarbida saab. „Lihtne” ei tähenda siin, et seda on lihtne kasutada, vaid et ressursside jaotamine toimub käsitsi.

Selline lähenemine on võimaldanud meil ka teha spetsialiseeritud riistvarakonfiguratsioone ülesande jaoks, mis toimib sellel serveril. Kui ülesanne talletab suuri andmemahtusid, siis kasutame 4U-serverit, mille šassii mahutab 38 ketast. Kui ülesanne on puhtalt arvutuslik, saame osta odavama 1U-serveri. See on arvutusressursside mõttes efektiivne. Selline lähenemine võimaldab meil kasutada neli korda vähem seadmeid koormuse korral, mis on sarnane ühele meile sõbralikule sotsiaalmeediale.

Selline arvutusressursside kasutamise efektiivsus peaks tagama ka majandusliku efektiivsuse, kui lähtuda eeldusest, et kõige kallimad on serverid. Pikka aega olid kõige kallimad just riistvara, ja oleme pannud palju vaeva riistvara hinna vähendamiseks, välja töötades talitluspidevuse tagamise algoritme, et vähendada seadmete usaldusväärsuse nõudeid. Ja täna oleme jõudnud staadiumisse, kus serveri hind enam ei mängi määravat rolli. Kui mitte arvestada uusimat eksootikat, siis konkreetse serveri konfiguratsioon rackis ei oma tähtsust. Praegu seisame silmitsi teise probleemiga — serveri asukoha hind andmekeskuses, st racki kohaga.

Mõistes, et see nii on, otsustasime arvutada, kui efektiivselt me riiuleid kasutame.
Võtsime kõige võimsama serveri hinna, mis on majanduslikult põhjendatud, ja arvutasime välja, kui palju selliseid servereid saame riiulitesse mahutada, kui palju ülesandeid me nende peale käivitaksime vanast mudelist lähtudes, kus "üks server = üks ülesanne", ja kui palju need ülesanded suudaksid varustust ära kasutada. Arvutasime — silmi niiskasid. Selgus, et meie riiulite kasutamise efektiivsus on umbes 11%. Tulemused on selged: andmekeskuste kasutamise efektiivsust tuleb tõsta. Tundub, et lahendus on ilmne: peame ühel serveril korraga mitu ülesannet käivitama. Kuid siin hakkavad probleemid.

Massiline konfiguratsioon muutub järsult keerulisemaks — nüüd ei saa serverile määrata ühte kindlat rühma. Küll aga võivad ühel serveril nüüd olla käivitatud mitmed erinevate meeskondade ülesanded. Lisaks võib konfiguratsioon olla erinevate rakenduste jaoks konfliktne. Diagnostika muutub samuti keerulisemaks: kui näete serveris suurenenud protsessorite või ketaste kasutamist, ei tea te, milline ülesanne põhjustab probleeme.

Kuid kõige tähtsam on see, et ühe masina peal käivitatavate ülesannete vahel ei ole eraldatust. Näiteks, siin on keskmise vastuseaja graafik serveriülesandele enne ja pärast seda, kui samal serveril käivitasime veel ühe, esimesega mitte seotud arvutusrakenduse — peamise ülesande vastamisaeg on oluliselt suurenenud.

Ilmselgelt tuleb ülesandeid käivitada kas konteinerites või virtuaalmasinates. Kuna praktiliselt kõik ülesanded käivitatakse meil ühe opsüsteemi (Linuxi) all või on selle jaoks kohandatud, ei ole meil vajalik ühegi erineva opsüsteemi toetamine. Seega ei ole virtualiseerimine vajalik, kuna selle täiendavad kulud muudavad selle vähem tõhusaks kui konteineriseerimine.

Dockeri konteinereid, mis käivitavad ülesandeid otse serverites, võib pidada heaks kandidaadiks: failisüsteemide pildid lahendavad konflikti tekkimise probleeme. Kuna pilte saab koostada mitmest kihist, suudame oluliselt vähendada andmete mahtu, mis on vajalik nende juurutamiseks infrastruktuuris, eraldades ühised osad eraldi baaskihiks. Nii et baaskihid (ja kõige mahukamad kihid) salvestatakse kogu infrastruktuuri piisavalt kiiresti ja erinevat tüüpi rakenduste ja versioonide edastamiseks tuleb edastada ainult väikesed kihid.

Lisaks pakuvad valmis registreerimise ja pilte märgistamise võimalused Dockeris meile valmis primitiive koodi versioonimiseks ja tootmisse toimetamiseks.

Docker, nagu iga teine sarnane tehnoloogia, pakub meile vaikimisi teatud taseme konteinerite isoleerimiseks. Näiteks mälu isoleerimine — iga konteinerile määratakse masina mälu kasutamise limiit, millest kõrgemat ta ei kasuta. Samuti on võimalik isoleerida konteinerite kasutust CPU puhul. Meie jaoks aga ei olnud standardne isoleerimine piisav. Kuid sellest räägime allpool.

Konteinerite otsene käivitamine serverites on ainult osa probleemidest. Teine osa on seotud konteinerite paigutamisega serveritesse. Tuleb mõista, milliseid konteinerite saab kellele serverisse paigutada. See ei ole nii lihtne ülesanne, sest konteinerid tuleb paigutada serveritesse võimalikult tihedalt, samas kiirusest loobumata. Selline paigutamine võib olla keeruline ja usaldusväärsuse seisukohalt. Tihti soovime paigutada sama teenuse koopiaid erinevatesse rackidesse või isegi erinevatesse andmekeskuste saalidesse, et racki või saali rikke korral ei kaotaks me kohe kõik teenuse koopiad.

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

Samuti soovisime anda arendajatele rohkem iseseisvust ressursside jaotamisel, et nad saaksid oma teenuseid ise tootmisesse paigutada ilma administraatori abita. Samas soovisime säilitada kontrolli, et mõni vähem oluline teenus ei kasutaks üles meie andmekeskuste ressursse.

Selgelt on vajalik juhtimistasand, mis tegeleb sellega automaatselt.

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

one-cloud masters — talitlushäired vältiv klaster, mis vastutab pilve orkestreerimise eest. Arendaja saadab meistrile manifesti, milles on kogu teenuse paigutamiseks vajalik teave. Meister annab selle alusel käske valitud minioonidele (masinatele, mis on mõeldud konteinerite käitamiseks). Minioonidel on meie agent, kes saab käsu, edastab juba oma käsud Dockerile ja Docker konfigureerib Linuxi kerneli vastava konteineri käivitamiseks. Lisaks käsude täitmisele edastab agent pidevalt meistrile muutusi nii minioonimasina seisundis kui ka käivitatud konteinerites.

Ressursside jaotamine

Nüüd vaatame keerulisemat ressursside jaotuse ülesannet mitme minioni jaoks.

Arvutusressurss one-cloudis on:

• Protsessori arvutusvõimsus, mida kasutatakse konkreetse ülesande jaoks.
• Mälu maht, mis on ülesandele saadaval.
• Võrguliiklus. Igal minionil on konkreetne võrguinterfeiss piiratud läbilaskevõimega, seega ei saa ülesandeid jaotada, arvesse võtmata edastatavate andmete mahtu.
• Kettad. Lisaks ilmselgelt ruumile ülesande andmete jaoks määrame ka ketta tüübi: HDD või SSD. Kettad suudavad teenindada piiratud arvu päringuid sekundis — IOPS. Seega, kui ülesanded genereerivad rohkem IOPS'i, kui üks kettas suudab teenindada, määrame ka "spindlid" — st ketas-seadmed, mis tuleb eraldi ülesande jaoks reserveerida.

Seega saame näiteks teenuse, nagu user-cache, ressursinõudluse kirjutada järgmisel viisil: 400 protsessorituuma, 2,5 TB mälu, 50 Gbit/s liiklust mõlemas suunas, 6 TB ruumi HDD-l, mis asub 100 spindlil. Või meie jaoks tuttavamal kujul nii:

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

User-cache'i teenused kasutavad ainult osa kõigist saadaval olevatest ressurssidest tootmisinfrastruktuuris. Seetõttu soovime tagada, et user-cache ei tarbiks ootamatult rohkem ressursse, kui talle on eraldatud, olgu see siis inimese vea tõttu või mitte. Peame ressursside kasutust piirama. Kuid mille põhjal saaksime kvooti määrata?

Naaseme meie tugevalt lihtsustatud komponentide suhtlemise skeemi juurde ja joonistame selle suuremate detailidega — nii:

Mida silma torkab:

• Veebifront ja muusika kasutavad sama rakenduste serveri isoleeritud klastreid.
• Saame määratleda loogilised kihid, mis kuuluvad nende klastrite alla: front'id, vahemälud, andmete salvestamise ja haldamise kiht.
• Frontend ei ole ühtlane, need on erinevad funktsionaalsed alamsüsteemid.
• Vahemälusid saab samuti jaotada alamsüsteemi järgi, mille andmeid nad vahemälustavad.

Joonistame pildi veel kord ümber:

Vau! Me näeme hierarhiat! See tähendab, et saame ressursse jagada suuremates tükkides: määrata vastutav arendaja selle hierarhia sõlmele, mis vastab funktsionaalsetele alam-süsteemidele (nagu „music“ pildil), ning siduda sellele tasemele hierarhias ka kvota. Selline hierarhia võimaldab meil ka paindlikumalt korraldada teenuseid, et need oleksid haldamise seisukohalt mugavamad. Näiteks jagame kõik veebiserverid, kuna see on väga suur serverite rühm, mitmeks väiksemaks grupiks, nagu pildil on näidatud group1, group2.

Eemaldades liigsed jooned, saame iga sõlme meie pildist kirja panna lamedamas vormis: group1.web.front, api.music.front, user-cache.cache.

Nii me jõuame mõisteteni "hierarhiline järjekord". Sel on nimi, näiteks "group1.web.front". Sellele määratakse ressursside kvoodid ja kasutajate õigused. DevOps töötajale anname õiguse teenuse järjekorda saatmiseks, ja selline töötaja võib järjekorras midagi käivitada, ning OpsDev töötajale adminniõigused, mis tähendab, et nüüd saab ta järjekorda hallata, sinna inimesi määrata, anda neile õigusi jne. Järjekorras käivitatavad teenused töötatakse välja järjekorra kvoodi piires. Kui järjekorra arvutuslik kvoot ei ole piisav kõigi teenuste samaaegseks täitmiseks, siis nad täidetakse järjestikku, moodustades seeläbi ise järjekorra.

Vaatame teenuseid lähemalt. Teenusel on täielik nimi, mis sisaldab alati järjekorra nime. Seega veebifront teenus saab nimeks ok-web.group1.web.front. Ja rakendusserveri teenus, millega see suhtleb, nimetatakse ok-app.group1.web.front. Iga teenusel on manifest, kus on kirjas kogu vajalik teave, et paigaldada see konkreetsetele masinatele: kui palju ressursse see ülesanne tarbib, milline konfiguratsioon on vajalik, kui palju koopiaid peaks olema, teenuse tõrkeotsingu omadused. Ja pärast teenuse paigaldamist masinatel ilmuvad selle eksemplarid. Need on samuti unikaalselt nimetatud — kui eksemplari number ja teenuse nimi: 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 selgeks teha.

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

Ülesannete isoleerimise klassid

Kõik ülesanded OKes (ja tõenäoliselt ka igal pool mujal) saab jagada rühmadesse:

• Lühikese viivitusega ülesanded — prod. Selliste ülesannete ja teenuste puhul on väga oluline vastuse viivitus (latency), kui kiiresti süsteem iga päringut töödelda suudab. Ülesannete näited: veebi esipinnad, sisedoosid, rakenduste serverid, OLTP salvestused jne.
• Arvutusülesanded — batch. Siin on igasuguste päringute töötlemise kiirus ebaoluline. Olulisem on, kui palju arvutusi antud (suur) ajavahemiku jooksul see ülesanne teostab (throughput). Selle alla käivad kõik MapReduce, Hadoop, masinõppe, statistika ülesanded.
• Taustülesanded — idle. Selliste ülesannete puhul ei ole ei latency ega throughput nii olulised. Siia kuuluvad erinevad testid, migratsioonid, ümberarvutused, andmete konverteerimine ühest formaadist teise. Ühelt poolt sarnanevad need aritmeetilistele ülesannetele, kuid teisalt pole meil väga oluline, kui kiiresti need lõpule viiakse.

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

Lühikese latentsusega ülesanded. Sellise ülesande proportsioon protsessori kasutuses näeb välja selline:

Kasutajalt tuleb päring, ülesanne hakkab kasutama kõiki saadaval olevaid protsessori tuumasid, töötleb, tagastab vastuse, ootab järgmist päringut ja seisab. Järgmisel päringul — taas kasutatakse kõike, mis oli, arvutatakse, ootame järgmist.

Minimaalse viivituse tagamiseks selle ülesande puhul peame me võtma maksimaalselt tarvitatavad ressursid ning reserveerima vajalikud tuumad minjoni (masina, mis täidab ülesannet) jaoks. Siis on meie ülesande reserveerimise valem järgmine:

alloc: cpu = 4 (max)

ja kui meil on 16 tuumaga minjoni masin, siis saame sellele täpselt neli sellist ülesannet paigutada. Eriti oluline on märkida, et nende ülesannete keskmine protsessori kasutus on sageli väga madal — mis on ilmselge, kuna suure osa ajast ootab ülesanne päringut ja ei tee midagi.

Arvutusülesanded. Nende muster on pisut erinev:

Nende ülesannete keskmine ressursi kasutus protsessoris on piisavalt kõrge. Sageli tahame, et arvutusülesanne teostataks kindla ajavahemiku jooksul, seega tuleb reserveerida minimaalne protsessorite arv, mis on vajalik, et kogu arvutus lõppeks vastuvõetava aja jooksul. Selle reserveerimise valem näeb välja järgmine:

alloc: cpu = [1,* )

„Palun paiguta minjoni, kus on vähemalt üks vaba tuum, ja ülejäänud võtavad kõik, mis saadaval on.”

Siin on ressursikasutuse efektiivsus tunduvalt parem kui lühikese latentsusega ülesannete puhul. Kuid kasu on palju suurem, kui kombineerida mõlemat tüüpi ülesandeid ühel masin-minionil ja jaotada selle ressursse jooksvalt. Kui lühikese latentsusega ülesanne nõuab protsessorit, saab ta selle kohe, ja kui ressursse enam ei vajata, antakse need edasi arvutusülesandele, st umbes nii:

Aga kuidas seda teha?

Alustame prod ja selle alloc’i mõistmisest: cpu = 4. Me peame reserveerima neli südamikku. Docker run'is saab seda teha kahes erinevas viisis:

• Kasutades valikut --cpuset=1-4, st määrata ülesandele neli kindlat südant masinas.
• Kasutage --cpuquota=400_000 --cpuperiod=100_000, määrata protsessori aja kvoot, st näidata, et iga 100 ms reaalajas tarbib ülesanne mitte rohkem kui 400 ms protsessori aega. Selgub, et need on samad neli südamikku.

Aga milline neist viisidest sobib?

Cpuset näeb üsna atraktiivne välja. Ülesandel on neli pühendatud tuuma, mis tähendab, et protsessori vahemälu töötab maksimaalselt efektiivselt. Kuid sellega kaasneb ka tagasilöök: me peaksime ise hakkama ülesandeid jaotama masiivi vähem koormatud tuumade vahel, mitte operatsioonisüsteemi, ja see on üsna keeruline ülesanne, eriti kui proovime viia sellisele masinale batch-ülesandeid. Testid näitasid, et siinkohal sobib paremini kvota variant: nii on operatsioonisüsteemil rohkem vabadust valida tuum, kus praegu ülesannet täita, ja protsessori aeg jaguneb efektiivsemalt.

Selgitame, kuidas Dockeris minimaalsete tuuma arvude tagamiseks töötada. Batch-ülesannete jaoks pole kvota enam rakendatav, kuna ei ole vajalik maksimaalselt piirata, piisab ainult minimaalse garanteerimisest. Siin sobib hästi valik docker run --cpushares.

Me lepime kokku, et kui batch nõuab minimaalset garantiid ühe tuuma jaoks, siis märkime --cpushares=1024, ja kui minimaalne on kahe tuuma jaoks, siis märkime --cpushares=2048. CPU jagatud ei sekku protsessorite aja jaotamisse seni, kuni seda jätkub. Seega, kui prod ei kasuta hetkel kõiki oma nelja tuuma - ei piira miski batch-ülesandeid ning need võivad kasutada lisaprotsessori aega. Kuid protsessori nappuse olukorras, kui prod on kasutanud kõik oma neli tuuma ja koperdab piirini - jagatakse ülejäänud protsessori aeg proportsionaalselt cpushares'i järgi. St kolme vabaga tuuma puhul saab ühe ülesanne, millel on 1024 cpushares, ja teised kaks - ülesanne, millel on 2048 cpushares.

Kuid kvota ja jagude kasutamine ei ole piisav. Me peame tagama, et madala viivitusega ülesanne saab prioriteedi batch-ülesande ees protsessori aja jaotamisel. Ilma sellise prioriteedita võtaks batch-ülesanne kogu protsessori aja ära, kui seda on vaja prod jaoks. Docker runis ei ole konteinerite prioriseerimiseks mingeid valikuid, kuid CPU ajakava poliitikad Linuxis tulevad appi. Nende kohta saab lugeda siin, ja selles artiklis käsitleme neid lühidalt:

• SCHED_OTHER
  Vaikimisi saavad kõik tavalised kasutaja protsessid Linuxi masinal.
• SCHED_BATCH
  Mõeldud ressursimahukatele protsessidele. Kui ülesanne paigutatakse protsessorisse, kehtestatakse nn aktiveerimisrakendus: sellisel juhul on tõenäolisem, et ülesanne ei saa protsessori ressursse, kui neid kasutab SCHED_OTHER ülesanne.
• SCHED_IDLE
  Taustaprotsess, mille prioriteet on väga madal, isegi madalam kui nice –19. Kasutame oma avatud lähtekoodiga teeki one-nio, et määrata vajalik poliitika konteineri käivitamisel kutsumisega

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

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

chrt -i 0 $pid

Kogume kõik meie isolatsioonitasemed ühte tabelisse selguse huvides:

Isolatsiooniklass
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 vaikimisi eemaldab Docker selle capability konteineri käivitamisel.

Kuid ülesanded tarbivad mitte ainult protsessorit, vaid ka liiklust, mis mõjutab võrguülesande viivitust isegi rohkem kui protsessori ressursi vale jaotamine. Seetõttu soovime loomulikult saada täpselt sama pilti ka liikluse osas. See tähendab, et kui tootmisülesanne saadab võrku teatud pakette, siis me määratleme maksimaalse kiirus(piirangud) alloc: lan=[*,500mbps) ), mille kiirusel tootmine seda teha saab. Ja batch'i puhul garanteerime ainult minimaalse läbilaskevõime, kuid mitte maksimaalse (piirangud alloc: lan=[10Mbps,*) ) Samuti peab tootmise liiklus olema eelisseisundis batch-ülesannete ees.
Siin ei ole Dockeril mingeid primitiive, mida saaksime kasutada. Kuid meid aitab Linux Traffic Control. Me oleme saavutanud soovitud tulemuse distsipliini abil Hierarchical Fair Service Curve. Selle abil eraldame kaks liikluse klassi: kõrge prioriteet tootmine ja madala prioriteediga batch/idle. Lõpuks on väljamineva liikluse konfiguratsioon järgmine:

siin 1:0 — «juure qdisc» hsfc distsipliinis; 1:1 — alamklass hsfc, millel on 8 Gbit/s ühine ribalaiuse piirang, kuhu kuuluvad kõigi konteinerite alamklassid; 1:2 — hsfc alamklass, mis on ühine kõigile batch ja idle ülesannetele, millel on „dünaamiline” piirang, millest allpool. Ülejäänud hsfc alamklassid on pühendatud klassid hetkel töötavatele prod-konteineritele ja nende piirangud vastavad nende manifestidele, - 450 ja 400 Mbit/s. Iga hsfc klassi jaoks on määratud qdisc järjekord fq või fq_codel, sõltuvalt linuxi tuuma versioonist, et vältida pakettide kadumist liiklustipude ajal.

Tavaliselt teenivad tc distsipliinid ainult väljamineva liikluse prioriseerimist. Kuid me tahame prioriseerida ka sissetulevat liiklust — kuna mõni batch-ülesanne võib kergesti ära võtta kogu sissetuleva kanali, näiteks suurt andmepaketti map&reduce'i jaoks. Selleks kasutame moodulit ifb, mis loob iga võrgu liidese jaoks virtuaalse liidese ifbX ja suunab sissetuleva liikluse liideselt ifbX-i väljaminevaks. Edasi toimivad kõik samad distsipliinid väljamineva liikluse kontrollimiseks, mille jaoks hsfc konfiguratsioon on väga sarnane:

Eksperimentide käigus selgus, et parimad tulemused hsfc saavutab siis, kui klassi 1:2 madalama prioriteediga batch/idle liiklus on masinatel-minionidel piiratud mitte rohkem kui mingisuguse vaba ribalaiusega. Vastasel juhul mõjutab madalama prioriteediga liiklus liiga tugevalt prod-ülesannete viivitust. Praegust vaba ribalaiuse suurust määrab miniond iga sekundi jooksul, mõõtes kõigi käimasolevate prod-ülesannete keskmist liiklusnõudlust selle minioni lõikes ja lahutades selle võrgu liidese läbilaskevõimest mõningase varuga, st.

Ribalaiused määratakse sissetuleva ja väljamineva liikluse jaoks sõltumatult. Ja vastavalt uutele väärtustele miniond konfigureerib ümber madalama prioriteediga klassi 1:2 limiidi.

Nii oleme rakendanud kõiki kolme isolatsiooniklassi: prod, batch ja idle. Need klassid mõjutavad oluliselt ülesannete täitmise omadusi. Seetõttu otsustasime selle tunnuse hierarhiasse üles tõsta, et hierarhilise järjekorra nime vaadates oleks kohe selge, millega me tegeleme:

Kõik meie tuttavad web ja music frondid paigutatakse siis hierarhiatesse prod alla. Näiteks paigutame teenuse music catalog, mis perioodiliselt koostab muusikateoste katalooge, mis on üles laaditud "Odnoklassniki" mp3-failidest. Näiteks idle teenuse näiteks võib olla music transformer, mis normaliseerib muusika helitugevuse taseme.

Korrates, kui eemaldame tarbetud read, saame meie teenuste nimed kirjutada lamedamalt, lisades ülesande isolatsiooniklassi teenuse täieliku nime lõppu: web.front.prod, catalog.music.batch, transformer.music.idle.

Ja nüüd, vaadates teenuse nime, mõistame mitte ainult seda, millist funktsiooni see täidab, vaid ka tema isolatsiooniklassi, seega tema kriitilisust jne.

Kõik on suurepärane, kuid on üks kibedat tõde. Ülesannete, mis töötavad ühel masinal, täielik isolatsioon on võimatu.

Mida oleme saavutanud: kui batch tarbib intensiivselt ainult CPU ressursside osas, integreeritud Linuxi CPU ajakava täidab oma ülesande väga hästi, mõjutades tootmisülesannet peaaegu mitte midagi. Kuid kui see baatch-ülesanne hakkab aktiivselt mäluga töötama, siis ilmneb juba vastastikune mõju. See juhtub seetõttu, et tootmisülesande puhul "kannavad" mälust protsessori vahemällud — tulemusena kasvavad vahemälu tabamuste arv ja protsessor töötleb tootmisülesannet aeglasemalt. Selline baatch-ülesanne võib tõsta meie tüüpilise tootmisnõude latentsust kuni 10% võrra.

Liiklust isoleerida on veelgi keerulisem, kuna kaasaegsetel võrgukaartidel on olemas sisemine pakettide järjekord. Kui baatch-ülesande pakett jõuab sinna esimesena, siis saadetakse see ka esimesena üle kaabli, ja siin ei saa midagi teha.

Lisaks oleme suutnud lahendada ainult TCP-liikluse prioriseerimise probleemi: UDP puhul ei tööta hsfc lähenemine. Ja isegi TCP-liiklusel, kui baatch-ülesanne genereerib palju liiklust, põhjustab see samuti umbes 10% tootmisülesande latentsuse suurenemist.

Katastroofitaluvus

Üheks eesmärgiks one-cloud arendamisel oli parandada Odnoklassniki tõrkevastupidavust. Seega sooviksin põhjalikumalt käsitleda võimalikke tõrke- ja hädaolukordi. Alustame lihtsast stsenaariumist — konteineri tõrkest.

Konteiner võib ise mitmeti ebaõnnestuda. See võib olla mingi eksperiment, bug või viga manifestis, mis sunnib prod-ülesannet tarbima rohkem ressursse kui manifestis määratud. Meil oli olukord: arendaja rakendas keerulist algoritmi, tegi seda korduvalt, muutis selle liiga keeruliseks ja segadusse sattudes, põhjustas, et ülesanne jäi tõeliselt keeruliselt lõksu. Kuna prod-ülesanne on prioriteetsed kõikidest teistest samadel mini-ressurssidel, hakkas see tarbima kõiki saadaval olevaid protsessorite ressursse. Sellises olukorras päästis isolatsioon, täpsemalt protsessori aja kvoot. Kui ülesandele on määratud kvoot, ei tarbi ülesanne rohkem. Seega batch- ja muud prod-ülesanded, mis töötasid samal masinal, ei märganud midagi.

Teine võimalik probleem on konteineri kokkuvarisemine. Ja siinkohal aitavad meid taaskäivitamise poliitikad, millest kõik teavad; Docker suudab sellega suurepäraselt toime tulla. Peaaegu kõik prod-ülesanded omavad taaskäivitamise poliitikat always. Mõnikord kasutame on_failure batch-ülesannete või prod-konteinerite silumise jaoks.

Mida saab teha, kui terve minion on kättesaamatuks muutunud?

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

Saame konteineritele määrata samu IP-aadresse nagu masinatel, mille minionid neid konteinerite käivitamiseks kasutavad. Siis kui konteiner käivitatakse teisel masinal, muutub tema IP-aadress, ja kõik kliendid peavad mõistma, et konteiner on kolinud; nüüd tuleb minna teise aadressi juurde, mis nõuab eraldi teenuse Service Discovery.

Service Discovery on mugav. Turul on palju lahendusi erineva rikke taluvuse tasemega teenuste registri korraldamiseks. Tihti sellistes lahendustes rakendatakse koormuse tasakaalustamise loogikat, lisakonfiguratsiooni salvestamist KV-poodide kujul jne.
Kuid me sooviksime vältida vajadust eraldi registri integreerimise järele, kuna see tähendaks kriitilise süsteemi loomist, mida kasutavad kõik teenused tootmises. See tähendab potentsiaalset rikke punkti, mistõttu tuleb valida või arendada väga tõrke-kindel lahendus, mis on ilmselgelt väga keeruline, aeganõudev ja kallis.

Veel üks suur puudus: meie vana infrastruktuuri töötamiseks uuega oleks pidanud kõik ülesanded ümber kirjutama mõne teenust avastava süsteemi kasutamise jaoks. Töö on ÄÄRMISELT palju ja mõnes kohas lausa võimatu, kui tegemist on madala taseme seadmetega, mis töötavad operatsioonisüsteemi tasandil või otse riistvaraga. Selle funktsionaalsuse rakendamine tuttavate lahendusmustritega, nagu näiteks side-car tähendaks mõnes kohas lisakoormust, mõnes — haldamise keerukust ja täiendavaid rikke stsenaariume. Me ei soovinud keerukust, seega otsustasime teha teenust avastamise valikuliseks.

One-cloud IP järgneb konteinerile, st iga ülesande eksemplaril on oma IP-aadress. See aadress on 'staatiline': see määratakse igale eksemplarile hetkest, mil teenus esmakordselt pilve saadetakse. Kui teenuse eluea jooksul oli erinev arv eksemplare, siis lõpuks on sellega seotud nii palju IP-aadresse, kui oli eksemplare maksimaalselt.

Hiljem neid aadresse ei muudeta: need määratakse kord ja püsivad teenuse elu jooksul tootmises. IP-aadressid järgivad konteinerite võrku. Kui konteiner kantakse teisele miniaturisatsioonile, siis läheb ka aadress tema kaasa.

Nii et teenuse nime ja tema IP-aadresside nimekirja sobitamine muutub väga harva. Kui veel kord vaadata teenuse eksemplaride nimesid, mida mainisime artikli alguses (1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod, …), siis märkame, et need sarnanevad DNS-is kasutatavatele FQDN-idele. Just selleks kasutame teenuste eksemplaride nimede sidumiseks nende IP-aadressidega DNS-protokolli. See DNS tagastab kõik reserveeritud IP-aadressid kõigile konteineritele — nii töötavatele kui ka peatatud (kui meil on näiteks kolm replikat ja seal on viis reserveeritud aadressi — tagastatakse kõik viis). Klientidele, kes saavad selle teabe, proovivad nad ühendust luua kõigi viie replikaga — ja tuvastavad seeläbi need, mis töötavad. See kättesaadavuse määramise variant on oluliselt usaldusväärsem, kuna see ei hõlma DNS-i ega teenuse avastamist, mistõttu ei teki ka keerulisi probleeme teabe ajakohasuse ja nende süsteemide talitluskatkestuse tagamisega. Veelgi enam, kriitilistes teenustes, mille töö sõltub kogu portaali toimimisest, võime DNS-i üldse mitte kasutada ja lihtsalt sisestada konfiguratsiooni IP-aadressid.

Sellise IP edastamise rakendamine konteinerite taga võib olla mitte triviaalne — ja peatume selle toimimisel järgmise näite kaudu:

Kujutame ette, et one-cloud meister annab käsu minionile M1 käivitada 1.ok-web.group1.web.front.prod aadressiga 1.1.1.1. Minione töötab BIRD, mis kuulutab seda aadressi spetsiaalsetele serveritele route reflector. Viimastel on BGP-seanss võrgu seadmega, millele marsruut 1.1.1.1 edastatakse M1 kaudu. M1 suunab paketid konteinerisse juba Linuxi vahenditega. Route reflectorite arv on kolm, kuna see on one-cloudi infrastruktuuri väga kriitiline osa — ilma nendeta ei toimiks võrk one-cloudis. Me paigutame need erinevatesse rackidesse, võimalusel eri andmekeskuste saalidesse, et vähendada kõigi kolme samaaegse rikke tõenäosust.

Oletame nüüd, et side one-cloudi meistri ja minioni M1 vahel on katkenud. One-cloudi meister käitub nüüd eeldusel, et M1 on täielikult ebaõnnestunud. See tähendab, et ta annab käsu minionile M2 käivituda web.group1.web.front.prod sama aadressiga 1.1.1.1. Nüüd on meil kaks konfliktset marsruuti võrgus aadressile 1.1.1.1: M1 ja M2. Selliste konfliktide lahendamiseks kasutame Multi Exit Discriminator'it, mis on märgitud BGP-teates. See number näitab reklaamitud marsruudi kaalu. Konfliktsetest valitakse marsruut, millel on väiksem MED-väärtus. One-cloudi meister toetab MED'i kui IP-aadresside konteinerite lahutamatut osa. Esmakordselt väljastatakse aadress piisavalt suure MED = 1 000 000. Kui selline konteineri hädaolukord esineb, vähendab meister MED'i ja M2 saab juba käsu reklaamida aadressi 1.1.1.1 MED = 999 999. Samas M1-l töötav eksemplar jääb teie ühenduse puudumise tõttu ning selle edasine saatus meid ei huvitagi kuni ühenduse taastamiseni meistriga, mil ta ka lõpetatakse kui vana koopia.

Ohtlikud olukorrad

Kõik andmekeskuste haldamise süsteemid töötavad alati hästi välja väiksemaid tõrkeid. Koneetigear oli praktiliselt igal pool norm.

Vaatame, kuidas me hädaolukorraga toime tuleme, näiteks toitekatkestus ühes või mitmes andmekeskuse saalis.

Mida tähendab avarii andmekeskuse juhtimissüsteemile? Esiteks on see massiivne korraga juhtunud mitme seadme rike, mille korral peab juhtimissüsteem kohe migreerima väga palju konteynereid. Kuid kui avarii on väga ulatuslik, võib tekkida olukord, kus kõiki ülesandeid ei saa mujale jaotada, kuna andmekeskuse ressursside maht langeb alla 100% koormuse.

Sageli kaasnevad avariidega ka juhtimistasandi riketeid. See võib juhtuda tema seadmete rikke tõttu, kuid sagedamini seetõttu, et avariisid ei ole testeeritud, ja juhtimistasand ise kukub suure koormuse tõttu kokku.

Mida kõigega selle kohta teha saab?

Massilised migreerimised tähendavad, et infrastruktuuris tekib suur hulk tegevusi, migreerimisi ja paigutusi. Iga migreerimine võib võtta aega, mis on vajalik konteinerimoodulite piltide toimetamiseks ja lahtipakkimiseks minionides, konteinerite käivitamiseks ja initsialiseerimiseks jne. Seetõttu on soovitav, et olulisemad ülesanded käivituksid enne vähemolulisi.

Uurime taas tuttavat teenuste hierarhiat ja proovime otsustada, millised ülesanded me esmajärjekorras käima lükkame.

Loomulikult on need protsessid, mis otse osalevad kasutaja päringute töötlemises, st prod. Me märkime selle üles prioriteedi määramisega — numbriga, mis võib olla määratud järjekorrale. Kui mingi järjekorra prioriteet on kõrgem, paigutatakse selle teenused esmajärjekorras.

Prodile määrame kõrgemad prioriteedid, 0; batchile veidi madalamad, 100; idle-le veel madalamad, 200. Prioriteedid kehtivad hierarhiliselt. Kõikidel madalama hierarhiaga ülesannetel on vastav prioriteet. Kui tahame, et prod-i sees käivituksid vahemälud enne frontend-e, siis määrame prioriteedid cache = 0 ja frontend-i alamjärjekorrale = 1. Kui aga soovime, et frontidest käivituks esmalt põhiportaal, ja muusika front siis hiljem, võime viimasele määrata madalama prioriteedi — 10.

Järgmine probleem on ressursside puudus. Meil on suured varustuse rikkeid, terveid andmekeskuste saale, ja oleme käivitanud nii palju teenuseid, et nüüd ei jätku ressursse kõigile. Tuleb otsustada, millistest ülesannetest võib loobuda, et päästa kriitilised teenused.

Erinevalt paigutuse prioriteedist ei saa me kõiki batch-ülesandeid lihtsalt kõrvale jätta, mõned neist on portaali toimimise jaoks olulised. Seetõttu oleme eraldanud prioriteedi välja tõrjumine ülesande. Paigutamise ajal võib kõrgema prioriteediga ülesanne kõrvale tõrjuda, st lõpetada madalama prioriteediga ülesande, kui ei ole enam vabu minione. Sel juhul jääb madalama prioriteediga ülesanne tõenäoliselt paigutamata, st ei leita talle enam sobivat minionit, kellel on piisavalt vabade ressursside.

Meie hierarhias on väga lihtne määrata selline prioriteet, et prod- ja batch-ülesanded tõukavad või peatavad idle-ülesanded, kuid mitte üksteist, määrates idle jaoks prioriteedi, mis on 200. Nii nagu paigutuse prioriteedi puhul, saame kasutada meie hierarhias, et kirjeldada keerukamaid reegleid. Näiteks määrame, et muusika funktsioon on midagi, millega me loobume, kui meie põhivebilehe ressursid ei piisa, seades vastavatele sõlmedele madalama prioriteedi: 10.

DC avariid täielikult

Miks võib kogu andmekeskus ebaõnnestuda? Loodusjõud. Oli hea postitus, kuidas orkaan mõjutas andmekeskuse tööd. Loodusjõududeks võib pidada ka kodutuid, kes kunagi suutsid optikat kollektoris põletada, ja andmekeskus kaotas täielikult ühenduse teiste paikadega. Rikkumise põhjuseks võib olla ka inimfaktor: operaator annab käsu, mille tulemusena kukub kogu andmekeskus. See võib juhtuda suure vea tõttu. Üldiselt kukuvad andmekeskused — see pole haruldane. Meil toimub see üks kord paarikuu jooksul.

Ja siin on, mida me teeme, et keegi #okživii ei postitaks Twitteris.

Esimene strateegia on isoleerimine. Iga one-cloud instants on isoleeritud ja suudab hallata vaid ühe andmekeskuse masinaid. Seega tähendab pilve kaotamine vigade või operaatori vale käsu tõttu vaid ühe andmekeskuse kaotamist. Oleme selleks valmis: meil on varukoopia poliitika, mille kohaselt rakenduse ja andmete koopiad on paigutatud kõikidesse andmekeskustesse. Kasutame tõrgeteta andmebaase ja testime perioodiliselt tõrkeid.
Kuna meil on täna neli andmekeskust, on ka neli eraldi, täielikult isoleeritud one-cloud instantsi.

Selline lähenemine mitte ainult ei kaitse füüsiliste rikete eest, vaid võib kaitsta ka operaatori vigu.

Mis veel saab inimfaktoriga teha? Kui operaator annab pilvele mingi kummalise või potentsiaalselt ohtliku käsu, võib temalt ootamatult nõuda väikese ülesande täitmist, et kontrollida, kui hästi ta on mõelnud. 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.

Kokkuvõte

one-cloudi eristuvad jooned:

• Hierarhiline ja selge teenuste ja konteinerite nimetamise skeem, mis võimaldab väga kiiresti teada saada, milline ülesanne see on, millele see viitab, kuidas see töötab ja kes selle eest vastutab.
• Kasutame oma prod- ja batch-ülesannete ühinemise tehnikat minikonteinerites, et suurendada masinate ühiskasutuse efektiivsust. Cpuset'i asemel kasutame CPU kvoote, aktsiaid, CPU ajakava poliitikat ja Linuxi QoS-i.
• Täielikult isoleerida sama masinaga töötavad konteinerid ei õnnestunud, kuid nende vastastikune mõju jääb 20% piiresse.
• Teenuste korraldamine hierarhias aitab automaatsete avariide likvideerimise puhul paigutus- ja tõrjumisprioriteetide.

KKK

Miks me ei valinud valmis lahendust.

• Erinevad ülesannete isolatsiooniklassid vajavad erinevat loogikat minikonteinerites paigutamisel. Kui prod-ülesandeid saab paigutada lihtsalt ressursside reserveerimise kaudu, siis batch ja idle tuleb paigutada, jälgides masinate minikonteinerite reaalseid ressursikasutusi.
• On oluline arvesse võtta selliseid ülesannete tarbimisressursse nagu:
  • võrgulaius;
  • ketaste tüübid ja "spindlid."
• Teenuste prioriteetide määramine hädaolukordade likvideerimise käigus, meeskondade õigused ja piirangud ressurssidele, mida lahendatakse hierarhiliste järjekordade abil one-cloudis.
• Inimlikult mõistetavate konteinerite nimetuste loomise vajadus, et vähendada reageerimisaega hädadele ja intsidentidele.
• Teenuse avastamise kohustusliku ja samal ajal laialdase rakendamise võimatus; vajadus kaua koos eksisteerida ülesannetega, mis on paigutatud füüsilisele riistvarale — seda lahendatakse «staatiliste» IP-aadressidega, mis järgnevad konteineritele, ja seetõttu on vajalik ainulaadne integratsioon suure võrguinfrastruktuuriga.

Kõik need funktsioonid nõuavad olemasolevate lahenduste olulisi ümberehitusi, ja arvestades töömahtu, mõistsime, et saame arendada oma lahenduse umbes sama tööjõu pingutusega. Kuid meie lahendust on oluliselt lihtsam kasutada ja edasi arendada — selles puuduvad ebavajalikud abstraktsioonid, mis toetavad meile mitteolulist funktsionaalsust.

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

Allikas: habr.com