🥇One-ewr - OS-ya asta navenda daneyê li Odnoklassniki

Aloha, gelî! Navê min Oleg Anastasyev e, ez li Odnoklassniki di tîmê Platformê de dixebitim. Û ji bilî min, di Odnoklassniki de gelek hardware dixebitin. Çar navendên me yên daneyê hene ku bi qasî 500 refikên ku ji 8 hezarî zêdetir server hene. Di xalek diyar de, me fêm kir ku danasîna pergalek rêveberiya nû dê rê bide me ku em amûran bi bandortir bar bikin, rêveberiya gihîştinê hêsantir bike, dabeşkirina (ji nû ve) çavkaniyên komputerê otomatîk bike, destpêkirina karûbarên nû bilez bike, û bersivan bileztir bike. ji qezayên mezin re.

Çi jê hat?

Ji bilî min û komek hardware, kesên ku bi vê hardware re dixebitin jî hene: endezyarên ku rasterast di navendên daneyê de cih digirin; torên ku nermalava torê saz dikin; rêvebiran, an jî SRE, yên ku berxwedêriya binesaziyê peyda dikin; û tîmên pêşveçûnê, her yek ji wan berpirsiyariya beşek ji fonksiyonên portalê ye. Nermalava ku ew diafirînin bi vî rengî dixebite:

Daxwazên bikarhêner hem li eniyên portala sereke têne wergirtin www.ok.ru, û li ser yên din, ji bo nimûne li eniyên API-ya muzîkê. Ji bo pêvajokirina mantiqa karsaziyê, ew gazî servera serîlêdanê dikin, ku, dema ku daxwazê dişoxilîne, gazî mîkroxizmetên pispor ên pêwîst dike - yek-graf (grafika girêdanên civakî), bikarhêner-cache (cache profîlên bikarhêner), hwd.

Her yek ji van karûbaran li ser gelek makîneyan têne bicîh kirin, û her yek ji wan xwedan pêşdebirên berpirsiyar in ku ji xebata modulan, xebitandina wan û pêşkeftina teknolojîk berpirsiyar in. Hemî van karûbaran li ser serverên hardware dimeşînin, û heya van demên dawî me tam yek peywirek ji bo serverek da destpêkirin, ango ew ji bo karek taybetî pispor bû.

Çima wisa ye? Vê rêbazê çend avantajên xwe hebûn:

Rehet kirin rêveberiya girseyî. Em bêjin ku karekî hin pirtûkxane, hin mîhengan hewce dike. Û dûv re server tam ji komek taybetî re tê veqetandin, polîtîkaya cfengine ji bo vê komê tête diyar kirin (an jî ew berê hatî diyar kirin), û ev veavakirin bi navendî û bixweber ji hemî pêşkêşkerên vê komê re tête kirin.
Simplified teşhîskirin. Ka em bibêjin hûn li barkirina zêde ya li ser pêvajoya navendî mêze bikin û fêm bikin ku ev barkirin tenê dikare ji hêla peywira ku li ser vê pêvajoya hardware dimeşîne were hilberandin. Lêgerîna ji bo kesek sûcdar pir zû bi dawî dibe.
Simplified çavdêrîkirina. Ger tiştek bi serverê re xelet be, çavdêr wê rapor dike, û hûn tam dizanin kî sûcdar e.

Karûbarek ku ji çend kopiyan pêk tê, çend server têne veqetandin - ji bo her yekê yek. Dûv re çavkaniya hesabkirinê ya ji bo karûbarê pir hêsan tê veqetandin: hejmara serverên ku karûbar hene, herî zêde çavkaniyên ku ew dikare bikar bîne. Li vir "hêsan" nayê vê wateyê ku karanîna wê hêsan e, lê di vê wateyê de ku veqetandina çavkaniyê bi destan tê kirin.

Vê nêzîkatiyê jî hişt ku em bikin veavakirinên hesinî yên pispor ji bo karekî ku li ser vê serverê dixebite. Ger peywir mîqdarên mezin daneyan hilîne, wê hingê em serverek 4U bi şaseyek bi 38 dîskê re bikar tînin. Ger peywir bi tenê hesabker e, wê hingê em dikarin serverek 1U erzan bikirin. Ev ji hêla hesabkirinê ve bikêrhatî ye. Di nav tiştên din de, ev nêzîkatî rê dide me ku em çar carî kêmtir makîneyên bi bargiraniyek ku bi yek tora civakî ya heval re tê berhev kirin bikar bînin.

Ger em ji pêşgotinê derbikevin ku tiştê herî biha servers in, pêdivî ye ku ev karîgerî di karanîna çavkaniyên komputerê de karbidestiya aborî jî peyda bike. Demek dirêj, hardware ya herî biha bû, û me gelek hewil da ku em bihayê hardware kêm bikin, bi algorîtmayên tolerasyona xeletiyê re peyda bikin da ku hewcedariyên pêbaweriya hardware kêm bikin. Û îro em gihîştine wê qonaxê ku tê de bihayê serverê ji diyarker namîne. Ger hûn exotîkên herî paşîn nahesibînin, wê hingê veavakirina taybetî ya serverên di rakê de ne girîng e. Naha pirsgirêkek me ya din heye - bihayê cîhê ku server di navenda daneyê de dagîrkirî ye, ango cîhê di rakê de.

Fêm kirin ku ev yek bû, me biryar da ku hesab bikin ka em çiqas bi bandor reqs bikar tînin.
Me bihayê servera herî bi hêz ji yên ku ji hêla aborî ve rastdar in girt, me hesab kir ka çend serverên weha em dikarin di rafikan de bi cîh bikin, em ê çend peywiran li ser wan bimeşînin li ser bingeha modela kevn "yek server = yek peywir" û çiqas weha kar dikarin amûrê bikar bînin. Hejmartin û hêsir barandin. Derket holê ku karbidestiya me di karanîna rakêşan de bi qasî 11%. Encam eşkere ye: pêdivî ye ku em karbidestiya karanîna navendên daneyê zêde bikin. Wusa dixuye ku çareserî diyar e: hûn hewce ne ku bi yekcarî çend karan li ser yek serverê bimeşînin. Lê li vir zehmetî dest pê dikin.

Veavakirina girseyî bi dramatîk tevlihevtir dibe - naha ne gengaz e ku meriv yek komê li serverek veqetîne. Beriya her tiştî, naha çend karên emrên cihêreng dikarin li ser yek serverê werin destpêkirin. Wekî din, dibe ku veavakirin ji bo serîlêdanên cûda nakok be. Teşhîs di heman demê de tevlihevtir dibe: ger hûn li ser serverek zêde vexwarina CPU an dîskê bibînin, hûn nizanin ka kîjan peywir dibe sedema pirsgirêkê.

Lê ya sereke ev e ku di navbera karên ku li ser heman makîneyê têne xebitandin de îzolasyon tune. Mînakî, li vir grafiyek dema bersivdana navînî ya peywirek serverê ye berî û piştî ku serîlêdana hesabkerî ya din li ser heman serverê hate destpêkirin, bi ti awayî bi ya yekem re têkildar nabe - dema bersivê ya peywira sereke pir zêde bûye.

Zelal, hûn hewce ne ku peywiran di konteyneran de an jî di makîneyên virtual de bimeşînin. Ji ber ku hema hema hemî karên me di bin yek OS-ê (Linux) de têne xebitandin an jî ji bo wê têne adaptekirin, ne hewce ye ku em gelek pergalên xebitandinê yên cihêreng piştgirî bikin. Li gorî vê yekê, virtualkirin ne hewce ye; ji ber sermaya zêde, ew ê ji konteynerê kêmtir bikêr be.

Wekî pêkanîna konteyneran ji bo meşandina peywiran rasterast li ser serveran, Docker berendamek baş e: Wêneyên pergala pelan pirsgirêkên bi mîhengên nakokî re baş çareser dikin. Rastiya ku wêne dikarin ji çend qatan pêk werin rê dide me ku em bi girîngî mîqdara daneya ku ji bo bicihkirina wan li ser binesaziyê hewce ne kêm bikin, parçeyên hevpar li qatên bingehîn ên cihêreng veqetînin. Dûv re qatên bingehîn (û herî mezin) dê bi lez û bez li seranserê binesaziyê bêne cache kirin, û ji bo radestkirina gelek celeb serîlêdan û guhertoyên cihêreng, dê tenê qatên piçûk werin veguheztin.

Zêdeyî, qeydek amade û nîşankirina wêneyê li Docker ji bo guhertokirin û gihandina kodê ji hilberînê re prîmîtîvên amade dide me.

Docker, mîna her teknolojiyek din a bi vî rengî, ji me re hin astek îzolekirina konteynerê ji qutiyê peyda dike. Mînakî, veqetandina bîranînê - ji her konteynir re sînorek li ser karanîna bîranîna makîneyê tê dayîn, ku ji derveyî wê ew ê nexwe. Her weha hûn dikarin konteyneran li ser bingeha karanîna CPU-yê veqetînin. Ji bo me, lêbelê, însulasyona standard ne bes bû. Lê bêtir li ser ku li jêr.

Rasterast vekirina konteynerên li ser serveran tenê beşek pirsgirêkê ye. Parçeyek din bi mêvandariya konteynerên li ser serveran ve girêdayî ye. Pêdivî ye ku hûn fêm bikin ka kîjan konteynir dikare li ser kîjan serverê were danîn. Ev ne karekî ew qas hêsan e, ji ber ku konteynir pêdivî ye ku bêyî kêmkirina leza wan bi qasî ku pêkan be li ser serveran bêne danîn. Cihkirina weha dikare ji hêla tolerasyona xeletiyê ve jî dijwar be. Pir caran em dixwazin kopiyên heman karûbarê li rafikên cihêreng an jî di odeyên cihêreng ên navenda daneyê de bi cîh bikin, da ku heke refikek an jûreyek têk bibe, em tavilê hemî kopiyên karûbarê winda nekin.

Dema ku we 8 hezar server û 8-16 hezar konteynir hebin, belavkirina konteyniran bi destan ne vebijarkek e.

Wekî din, me xwest ku di veqetandina çavkaniyê de bêtir serxwebûnê bidin pêşdebiran da ku ew bi xwe di hilberînê de, bêyî arîkariya rêveberek, mêvandariya karûbarên xwe bikin. Di heman demê de, me xwest ku em kontrolê biparêzin da ku hin karûbarên piçûk hemî çavkaniyên navendên daneyên me nexwe.

Eşkere, em hewceyê qatek kontrolê ye ku dê vê yekê bixweber bike.

Ji ber vê yekê em gihîştin wêneyek hêsan û têgihîştî ku hemî mîmar jê hez dikin: sê çargoşe.

masterên yek-ewr komek têkçûyî ye ku berpirsiyarê orkestrasyona ewr e. Pêşdebir manîfestoyek ji masterê re dişîne, ku tê de hemî agahdariya ku ji bo mêvandariya karûbarê pêdivî ye vedihewîne. Li ser bingeha wê, master fermanan dide minyonên bijartî (makîneyên ku ji bo rêvekirina konteyneran hatine çêkirin). Minionan xwediyê nûnerê me ye, ku fermanê distîne, emrên xwe ji Docker re dişîne, û Docker kernel linux mîheng dike ku konteynera têkildar bide destpêkirin. Digel pêkanîna fermanan, ajan bi domdarî di derheqê guheztinên di rewşa makîneya minion û konteynerên ku li ser wê dixebitin de bi domdarî ji master re rapor dike.

Dabeşkirina Çavkaniyê

Naha em li pirsgirêka veqetandina çavkaniyê ya tevlihevtir ji bo gelek minyonan binihêrin.

Çavkaniyek komputerê di yek-ewrê de ev e:

Mîqdara hêza pêvajoyê ya ku ji hêla peywirek taybetî ve tê vexwarin.
Hêjmara bîranîna ku ji peywirê re peyda dibe.
trafîka torê. Her yek ji minyonan xwedan pêwendiyek torê ya taybetî ya bi bandûra tixûbdar e, ji ber vê yekê ne gengaz e ku meriv peywiran belav bike bêyî ku jimareya daneya ku ew li ser torê vediguhezîne hesab bike.
Dîskên. Wekî din, eşkere, cîhê van karan, em celebê dîskê jî veqetînin: HDD an SSD. Dîskan dikarin her çirkeyek hejmareke bêdawî ya daxwazan pêşkêş bikin - IOPS. Ji ber vê yekê, ji bo peywirên ku ji yek dîskê bêtir IOPS diafirînin, em "spindles" jî vediqetînin - ango, amûrên dîskê yên ku divê bi taybetî ji bo peywirê bêne veqetandin.

Dûv re ji bo hin karûbar, mînakî ji bo cache-a bikarhêner, em dikarin çavkaniyên serfkirî bi vî rengî tomar bikin: 400 korikên pêvajoyê, 2,5 TB bîra, 50 Gbit/s seyrûsefera di her du alîyan de, 6 TB cîhê HDD-ê ku li ser 100 spindles pêk tê. An jî bi rengek naskirîtir mîna vê:

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

Çavkaniyên karûbarê bikarhêner-cache tenê beşek ji hemî çavkaniyên berdest ên di binesaziya hilberînê de vedixwe. Ji ber vê yekê, ez dixwazim piştrast bikim ku ji nişkê ve, ji ber xeletiyek operator an na, kaşê-karhêner ji ya ku jê re hatî veqetandin bêtir çavkaniyan naxwe. Ango divê em çavkaniyan bisînor bikin. Lê em dikarin kotayê bi çi ve girêbidin?

Ka em vegerin ser diyagrama xweya pir hêsan a pêwendiya pêkhateyan û wê bi hûrguliyên bêtir ji nû ve xêz bikin - mîna vê:

Tiştê ku bala we dikişîne:

Pêşiya malperê û muzîkê komên veqetandî yên heman servera serîlêdanê bikar tînin.
Em dikarin qatên mentiqî yên ku van koman tê de ne ji hev cuda bikin: pêşî, kaş, hilanîna daneyê û qata rêveberiyê.
Pêşî heterojen e; ew ji bine pergalên fonksiyonel ên cihê pêk tê.
Caches jî dikarin li ser bine-pergala ku daneya ku ew vedişêrin belav bibin.

Ka em dîsa wêneyê ji nû ve xêz bikin:

Bah! Erê, em hiyerarşiyekê dibînin! Ev tê vê wateyê ku hûn dikarin çavkaniyan li perçeyên mezintir belav bikin: pêşdebirek berpirsiyar bi girêkek vê hiyerarşiya ku bi binepergala fonksiyonel ve têkildar e (wek "muzîk" di wêneyê de) veqetînin, û kotayek bi heman astê hiyerarşiyê ve girêdin. Ev hiyerarşiya di heman demê de rê dide me ku em karûbaran ji bo hêsankirina rêveberiyê bi nermî organîze bikin. Mînakî, em hemî tevneyê dabeş dikin, ji ber ku ev kombûnek pir mezin a pêşkêşkeran e, li çend komên piçûktir, ku di wêneyê de wekî koma1, koma2 têne xuyang kirin.

Bi rakirina xêzên zêde, em dikarin her girêka wêneya xwe bi rengek xweştir binivîsin: group1.web.ber, api.music.front, user-cache.cache.

Bi vî awayî em digihîjin têgîna "rêşa hiyerarşîk". Navekî wê wekî "group1.web.front" heye. Kotayek ji bo çavkanî û mafên bikarhêner jê re tê destnîşankirin. Em ê mafê kesê ji DevOps bidin ku karûbarek bişîne rêzê, û karmendek wusa dikare tiştek di rêzê de bide destpêkirin, û kesê ji OpsDev dê xwediyê mafên rêveberiyê be, û naha ew dikare rêzê bi rê ve bibe, mirovan li wir tayîn bike, mafên van kesan bidin, hwd. Xizmetên ku li ser vê dorê dixebitin dê di nav kotaya dorê de bimeşin. Ger kotaya jimartinê ya rêzê têrê neke ku hemî karûbar bi yekcarî bêne darve kirin, wê hingê ew ê bi rêzê bêne darve kirin, bi vî rengî dorê bixwe çêbike.

Werin em ji nêzîk ve li ser xizmetên binêrin. Xizmetek navek bi tevahî jêhatî ye, ku her gav navê rêzê vedihewîne. Dûv re karûbarê webê ya pêşîn dê nav hebe ok-web.group1.web.front. Û karûbarê servera serîlêdanê ya ku ew digihîje dê were gazî kirin ok-app.group1.web.front. Her karûbar xwedan manîfestoyek e, ku hemî agahdariya pêwîst ji bo danîna li ser makîneyên taybetî diyar dike: ev peywir çend çavkaniyan dixwe, ji bo wê çi veavakirinê hewce ye, divê çend kopiyek hebin, taybetmendiyên ji bo birêvebirina têkçûnên vê karûbarê. Û piştî ku karûbar rasterast li ser makîneyan tê danîn, mînakên wê xuya dibin. Ew jî bi eşkereyî têne binav kirin - wekî jimareya nimûne û navê karûbarê: 1.ok-web.group1.web.front, 2.ok-web.group1.web.front,…

Ev pir hêsan e: bi nihêrîna tenê li navê konteynera xebitandinê, em dikarin tavilê gelek tiştan bibînin.

Naha em nihêrînek nêzîk li tiştên ku van mînakan bi rastî didin: karan.

Dersên îzolekirina peywirê

Hemî peywirên di OK de (û, dibe ku, li her deverê) dikarin li koman bêne dabeş kirin:

Karên Derengiya Kurt - prod. Ji bo kar û karûbarên weha, derengiya bersivê (derengbûn) pir girîng e, ka dê her yek ji daxwaznameyê çiqas zû ji hêla pergalê ve were pêvajo kirin. Nimûneyên peywiran: eniyên malperê, kaş, serverên serîlêdanê, hilanîna OLTP, hwd.
Pirsgirêkên hesabkirinê - batch. Li vir, leza pêvajoyê ya her daxwazek taybetî ne girîng e. Ji bo wan, girîng e ku ev peywir dê di demek diyarkirî (dirêj) de çend hesaban bike. Ew ê her karên MapReduce, Hadoop, fêrbûna makîneyê, statîstîk bin.
Karên paşîn - bêkar. Ji bo karên weha, ne dereng û ne jî rêgez pir girîng in. Di vê yekê de ceribandinên cihêreng, koçberî, ji nû ve hesabkirin, û veguheztina daneyan ji yek formatek din vedihewîne. Ji aliyekî ve, ew dişibin yên hesapkirî, ji hêla din ve, ji me re ne girîng e ka ew çiqas zû têne qedandin.

Ka em bibînin ka karên weha çawa çavkaniyan dixwe, mînakî, pêvajoya navendî.

Karên derengiya kurt. Karûbarek wusa dê şêwazek xerckirina CPU-yê mîna vê hebe:

Daxwazek ji bikarhêner ji bo pêvajoyê tête wergirtin, peywir dest pê dike ku hemî navikên CPU-yê yên berdest bikar bîne, wê pêvajoy dike, bersivek vedigerîne, li benda daxwaziya din dimîne û disekine. Daxwaza din hat - dîsa me her tiştê ku li wir bû hilbijart, hesab kir û li benda ya din in.

Ji bo garantîkirina derengiya hindiktirîn a peywirek wusa, divê em çavkaniyên herî zêde ku ew dixwe hilînin û li ser minionê (makîneya ku dê peywirê bi cih bîne) hejmara pêwîst ya koran veqetînin. Wê hingê formula veqetandinê ji bo pirsgirêka me dê wiha be:

alloc: cpu = 4 (max)

û heke me makîneyek minion bi 16 core hebe, wê hingê tam çar peywirên weha dikarin li ser werin danîn. Em bi taybetî destnîşan dikin ku mezaxtina navînî ya pêvajoyek van peywiran bi gelemperî pir kêm e - ku ev eşkere ye, ji ber ku beşek girîng a demê peywir li benda daxwazekê ye û tiştek nake.

Karên hesabkirinê. Nimûneya wan dê hinekî cûda be:

Xerca navînî ya çavkaniya CPU ji bo karên weha pir zêde ye. Bi gelemperî em dixwazin ku karekî hesabkirinê di demek diyarkirî de biqede, ji ber vê yekê em hewce ne ku hejmara herî hindik a pêvajoyên ku jê re hewce dike veqetînin da ku tevahiya hesab di demek pejirandî de were qedandin. Formula rezervasyona wê dê wiha xuya bike:

alloc: cpu = [1,*)

"Ji kerema xwe wê li ser minyonek ku bi kêmî ve bingehek belaş lê heye bixin, û dûv re bi qasî ku hebin, ew ê her tiştî bixwe."

Li vir karbidestiya karanîna jixwe ji karên bi derengî kurt pir çêtir e. Lê heke hûn her du celeb peywiran li ser yek makîneyek minionê bidin hev û çavkaniyên wê di rê de belav bikin dê qezenc pir mezintir be. Dema ku peywirek bi derengek kurt pêvajoyek pêdivî ye, ew tavilê wê distîne, û gava ku çavkanî êdî hewce nebin, ew vediguhezînin peywira hesabkirinê, ango tiştek weha:

Lê çawa wiya dikin?

Pêşî, em li prod û alokê wê binêrin: cpu = 4. Divê em çar core rezerv bikin. Di Docker run de ev dikare bi du awayan were kirin:

Vebijêrk bikar tînin --cpuset=1-4, ango çar bingehên taybetî yên li ser makîneyê ji peywirê re veqetînin.
Bikar bînin --cpuquota=400_000 --cpuperiod=100_000, ji bo dema pêvajoyê kotayekê destnîşan bikin, ango destnîşan bikin ku her 100 ms dema rast ev kar ji 400 ms wexta pêvajoyê zêdetir naxwe. Heman çar core têne wergirtin.

Lê kîjan ji van rêbazan guncan e?

cpuset pir balkêş xuya dike. Peywir çar bingehên veqetandî hene, ku tê vê wateyê ku kaşeyên pêvajoyê dê bi qasî ku gengaz bixebitin. Ev jî kêmasiyek heye: em neçar in ku li şûna OS-ê, erka belavkirina hesaban li ser navikên nebarkirî yên makîneyê hilgirin ser xwe, û ev karekî pir ne hindik e, nemaze ku em hewl bidin ku peywirên hevûdu li ser karek weha bi cih bikin. makîne. Testan destnîşan kir ku vebijarka bi kotayê li vir çêtir e: Bi vî rengî pergala xebitandinê di hilbijartina bingehîn de bêtir azadî heye ku di dema niha de peywirê pêk bîne û dema pêvajoyê bi bandortir tê belav kirin.

Ka em fêr bibin ka meriv çawa li Docker-ê li ser bingeha herî hindiktirîn hejmaran rezervan çêdike. Kotaya ji bo peywirên komê êdî nayê sepandin, ji ber ku ne hewce ye ku herî zêde were sînorkirin, bes e ku meriv hindiktirîn garantî bike. Û li vir vebijêrk baş li hev dike docker run --cpushares.

Me li hev kir ku ger komek ji bo herî kêm yek bingehîn garantiyek hewce bike, wê hingê em destnîşan dikin --cpushares=1024, û heke bi kêmî ve du core hene, wê hingê em destnîşan dikin --cpushares=2048. Parçeyên Cpu bi tu awayî destwerdanê nadin belavkirina dema pêvajoyê heya ku têra wê hebe. Ji ber vê yekê, heke prod naha her çar bingehên xwe bikar neyîne, tiştek peywirên hevîrê sînordar tune, û ew dikarin dema pêvajoyek zêde bikar bînin. Lê di rewşek ku kêmbûna pêvajoyan hebe, heke prod her çar core xwe xwaribe û gihîştibe kotaya xwe, dê dema mayî ya pêvajoyê li gorî cpushareyan were dabeş kirin, ango di rewşek sê hebên belaş de, yek dê bibe. ji bo karekî bi 1024 cpushare tê dayîn, û du yên mayî dê ji bo karekî bi 2048 cpushares.

Lê bikaranîna kota û parvekirinê têrê nake. Pêdivî ye ku em pê ewle bin ku dema veqetandina dema pêvajoyê de peywirek bi derengiyek kurt pêşanî li ser peywirek berhevokê digire. Bêyî pêşanîkirinek wusa, peywira hevîrê dê hemî dema pêvajoyê di dema ku ew ji hêla hilberîner ve hewce be digire. Di Docker run de vebijarkên pêşînkirina konteyneran tune, lê polîtîkayên plansazkirina CPU-ya Linux bi kêr têne. Hûn dikarin li ser wan bi berfirehî bixwînin vir, û di çarçoveya vê gotarê de em ê bi kurtasî li ser wan derbas bibin:

SCHED_OTHER
Bi xwerû, hemî pêvajoyên bikarhêner ên normal ên li ser makîneyek Linux distînin.
SCHED_BATCH
Ji bo pêvajoyên çavkanî-dijwar hatî çêkirin. Dema ku peywirek li ser pêvajoyek tê danîn, bi navê cezayê çalakkirinê tê destnîşan kirin: karekî weha kêmtir dibe ku çavkaniyên pêvajoyê werbigire ger ku ew niha ji hêla peywirek bi SCHED_OTHER ve tê bikar anîn.
SCHED_IDLE
Pêvajoyek paşîn a bi pêşanîyek pir kêm, ji xweş -19 jî kêmtir. Em pirtûkxaneya xweya çavkaniya vekirî bikar tînin yek-nio, ji bo ku gava ku konteynerê bi bangkirinê dest pê dike polîtîkaya pêwîst were danîn

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

Lê her çend hûn di Java-yê de bername nekin jî, heman tişt dikare bi karanîna fermana chrt were kirin:

chrt -i 0 $pid

Werin em ji bo zelaliyê hemî astên xwe yên îzolekirinê di yek tabloyê de kurt bikin:

Dersa insulasyonê
Mînak dabeş bikin
Vebijarkên rêvekirina Docker
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

*Heke hûn chrt ji hundurê konteynerek dikin, dibe ku hûn hewceyê kapasîteya sys_nice bin, ji ber ku bi xwerû Docker dema ku konteynerê dest pê dike vê kapasîteyê jê dike.

Lê peywir ne tenê pêvajoyê, lê di heman demê de seyrûseferê jî dixwe, ku ji veqetandina nerast a çavkaniyên pêvajoyê bêtir bandorê li derengiya peywirek torê dike. Ji ber vê yekê, em bi xwezayî dixwazin ku tam heman wêneyê ji bo trafîkê bistînin. Ango dema ku karekî prodîkê hin pakêtan dişîne torê, em leza herî zêde (formula veqetandin: lan=[*,500mbps) ), bi kîjan prod dikare vê yekê bike. Û ji bo komê em tenê rêjeya herî kêm garantî dikin, lê herî zêde sînordar nakin (formula veqetandin: lan=[10Mbps,*) ) Di vê rewşê de, seyrûsefera hilberînê divê pêşî li karên hevîrê bigire.
Li vir Docker ti primitives ku em dikarin bikar bînin tune. Lê ev ji bo alîkariya me tê Kontrola Trafîkê ya Linux. Me bi dîsîplînê karîbû encama ku tê xwestin bi dest bixin Curve Xizmeta Fair Hiyerarşîk. Bi arîkariya wê, em du çînên seyrûseferê ji hev vediqetînin: prod-ya-pêşeng û batch/bêkar-pêşeng. Wekî encamek, veavakirina ji bo seyrûsefera derketinê wiha ye:

li vir 1:0 "qdisc root" ya dîsîplîna hsfc ye; 1:1 - pola zarokan a hsfc bi sînorek firehiya bandê ya giştî 8 Gbit/s, ku di binê wê de çînên zarokan ên hemî konteyneran têne danîn; 1:2 - çîna zarokan a hsfc ji bo hemî karên hevseng û bêkar ên bi sînorek "dînamîk" re hevpar e, ku li jêr tê nîqaş kirin. Dersên zarokan ên hsfc yên mayî dersên veqetandî ne ji bo ku konteynerên hilberînê yên ku niha têne xebitandin bi tixûbên ku bi diyardeyên wan re têkildar in - 450 û 400 Mbit/s. Ji her pola hsfc re qdisc dorê fq an fq_codel, li gorî guhertoya kernel Linux-ê ve girêdayî ye, da ku di dema teqîna trafîkê de windabûna pakêtê nemîne.

Bi gelemperî, dîsîplînên tc xizmet dikin ku pêşî li seyrûsefera derketinê bigirin. Lê em dixwazin pêşî li seyrûsefera hatinê jî bigirin - her tiştî, hin peywirên hevberî dikarin bi hêsanî tevahiya kanala gihîştinê hilbijêrin, ji bo nimûne, komek mezin ji daneyên têketinê ji bo nexşe&kêmkirinê bistînin. Ji bo vê em modulê bikar tînin ifb, ku ji bo her navbeynkariya torê pêwendiyek virtual ya ifbX diafirîne û seyrûsefera hatî ji navbeynê ber bi seyrûsefera derketinê ya li ser ifbX ve beralî dike. Wekî din, ji bo ifbX, hemî heman dîsîplîn ji bo kontrolkirina seyrûsefera derketinê dixebitin, ji bo ku veavakirina hsfc dê pir dişibihe:

Di dema ceribandinan de, me dît ku hsfc encamên çêtirîn nîşan dide dema ku çîna 1: 2 ya seyrûsefera ne-pêşanî ya komê/bêkar li ser makîneyên minionê ne ji xelekek belaş be. Wekî din, seyrûsefera ne-pêşeng pir bandorek li ser derengiya karên prod dike. miniond her saniyeyê mîqdara heyî ya berfa belaş diyar dike, bipîvin mezaxtina trafîkê ya navînî ya hemî prod-karûbarên minionek diyarkirî û jêkirina wê ji firehiya pêwendiya torê bi marjînaleke biçûk, yanî.

Band ji bo seyrûsefera ketin û derketinê serbixwe têne destnîşan kirin. Li gorî nirxên nû, miniond sînorê çîna ne-pêşeng 1:2 ji nû ve saz dike.

Bi vî rengî, me her sê çînên îzolasyonê pêk anîn: prod, batch û bêkar. Van dersan pir bandor li taybetmendiyên performansa karan dikin. Ji ber vê yekê, me biryar da ku em vê taybetmendiyê li serê hiyerarşiyê bi cih bikin, da ku dema ku li navê rêza hiyerarşîk mêze bikin tavilê diyar bibe ku em bi çi re mijûl dibin:

Hemû hevalên me tevn и mûzîk eniyên paşê di hiyerarşiyê de di bin prod. Mînakî, di bin komê de, em karûbarê bicîh bikin kataloga muzîkê, ku bi awayekî periyodîk katalogek şopan ji komek pelên mp3 yên ku li Odnoklassniki hatine barkirin berhev dike. Mînakek karûbarek di bin bêkar de dê bibe veguherînerê muzîkê, ku asta dengê muzîkê normal dike.

Digel ku xêzên zêde ji nû ve hatine rakirin, em dikarin navên karûbarê xwe xweştir binivîsin û çîna veqetandina peywirê li dawiya navê karûbarê tevahî zêde bikin: web.front.prod, catalog.music.batch, transformer.music.idle.

Û naha, li navê karûbarê dinêrin, em ne tenê fonksiyona ku ew dike, lê di heman demê de çîna wê ya îzolekirinê jî fam dikin, ku tê wateya krîtîkbûna wê, hwd.

Her tişt mezin e, lê rastiyek tal heye. Ne gengaz e ku meriv karên ku li ser yek makîneyê têne xebitandin bi tevahî veqetînin.

Tiştê ku me karî bi dest bixin: ger kom bi zexmî vexwe bi tenê Çavkaniyên CPU-ê, wê hingê nexşerêya CPU-ya Linux-ê ya çêkirî karê xwe pir baş dike, û di pratîkê de ti bandorek li ser karê prod-ê tune. Lê heke ev peywira komê dest pê dike ku bi bîranînê re çalak bixebite, wê hingê bandora hevdu jixwe xuya dike. Ev diqewime ji ber ku peywira prod ji kaşên bîranîna pêvajoyê "şûştin" - di encamê de, kêmasiyên cache zêde dibin, û pêvajo hêdî hêdî peywira hilberînê dişoxilîne. Karûbarek weha ya berhevokê dikare derengiya konteynera meya hilberîna tîpîk% 10 zêde bike.

Veqetandina seyrûseferê hîn dijwartir e ji ber vê yekê ku qertên torê yên nûjen xwedan rêzek hundurîn a pakêtan in. Ger pakêta ji peywira hevîrê pêşî bigihîje wir, wê hingê ew ê yekem be ku li ser kabloyê were veguheztin, û tiştek li ser wê nayê kirin.

Wekî din, me heya nuha tenê karî pirsgirêka pêşîgirtina seyrûsefera TCP-ê çareser bike: nêzîkatiya hsfc ji bo UDP-yê naxebite. Tewra di mijara seyrûsefera TCP-ê de jî, heke peywira hevîrê gelek seyrûsefer çêdike, ev jî di derengiya peywira prod de% 10 zêde zêde dike.

tolerans xelet

Yek ji mebestên dema pêşkeftina yek-ewrê ew bû ku tolerasyona xeletiya Odnoklassniki baştir bike. Ji ber vê yekê, paşê ez dixwazim bi hûrgulî senaryoyên gengaz ên têkçûn û qezayan binirxînim. Ka em bi senaryoyek hêsan dest pê bikin - têkçûnek konteyneran.

Konteynir bixwe dikare bi çend awayan têk bibe. Ev dibe ku di manîfestoyê de celebek ceribandin, xeletî an xeletiyek be, ji ber vê yekê peywira prod dest pê dike ku ji ya ku di manîfestoyê de hatî destnîşan kirin bêtir çavkaniyan dixwe. Bûyerek me hebû: pêşdebirek algorîtmayek tevlihev pêk anî, gelek caran ew ji nû ve xebitand, xwe li ber xwe da û ew qas tevlihev bû ku di dawiyê de pirsgirêk ket nav xelekek pir ne hindik. Û ji ber ku peywira prod ji hemî yên din li ser heman minyonan pêşanîyek bilindtir e, wê dest pê kir ku hemî çavkaniyên pêvajoyê yên berdest bikar bîne. Di vê rewşê de, îzolasyon, an bêtir kotaya dema CPU, roj xilas kir. Ger ji karekî re kotayek were veqetandin, dê peywir zêde nexwe. Ji ber vê yekê, hevîng û karên prod ên din ên ku li ser heman makîneyê dimeşin tiştek nedîtin.

Pirsgirêka duyemîn a gengaz ketina konteynerê ye. Û li vir polîtîkayên ji nû ve destpêkirinê me xilas dikin, her kes wan dizane, Docker bixwe karekî mezin dike. Hema hema hemî peywirên prod xwedan polîtîkayek her gav ji nû ve dest pê dikin. Carinan em on_failure-ê ji bo peywirên berhevokê an jî ji bo verastkirina konteynerên hilberînê bikar tînin.

Hûn dikarin çi bikin heke tevahî minionek ne berdest be?

Eşkere ye, konteynerê li ser makîneyek din bimeşînin. Li vir beşa balkêş ev e ku çi diqewime navnîşana IP-ê (yên) ku ji konteynerê re hatî veqetandin.

Em dikarin konteyneran heman navnîşanên IP-yê wekî makîneyên minion ên ku van konteyneran li ser wan dimeşînin destnîşan bikin. Dûv re, gava ku konteynir li ser makîneyek din tê avêtin, navnîşana IP-ya wê diguhezîne, û pêdivî ye ku hemî xerîdar fam bikin ku konteynir bar kiriye, û naha ew hewce ne ku biçin navnîşanek cûda, ku karûbarek Vedîtina Karûbarê cihêreng hewce dike.

Vedîtina Xizmetê rehet e. Ji bo organîzekirina qeydek karûbarê gelek çareserî li ser sûkê bi dereceyên cihêreng ên tolerasyona xeletiyê hene. Bi gelemperî çareseriyên weha mantiqa balansa barkirinê bicîh dikin, veavakirina zêde di forma hilanîna KV de hilînin, hwd.
Lêbelê, em dixwazin ji hewcedariya pêkanîna qeydek cihêreng dûr bixin, ji ber ku ev tê wateya danasîna pergalek krîtîk ku ji hêla hemî karûbaran ve di hilberînê de tê bikar anîn. Ev tê vê wateyê ku ev xalek potansiyel a têkçûnê ye, û hûn hewce ne ku çareseriyek pir xelet-tolerant hilbijêrin an pêşve bibin, ku eşkere pir dijwar, dem-dixwe û biha ye.

Û kêmasiyek din a mezin: ji bo ku binesaziya meya kevn bi ya nû re bixebite, pêdivî ye ku em bi tevahî hemî peywiran ji nû ve binivîsin da ku cûreyek pergala Vedîtina Karûbarê bikar bînin. Pir kar heye, û li hin deveran hema hema ne gengaz e dema ku ew tê ser cîhazên nizm ên ku di asta kernel OS-ê de an rasterast bi hardware re dixebitin. Pêkanîna vê fonksiyonê bi karanîna şêwazên çareseriyê yên sazkirî, wek mînak side-car dê li hin deveran were wateya barek zêde, li hinên din - tevliheviyek operasyonê û senaryoyên têkçûnê yên zêde. Me nexwest ku tiştan tevlihev bikin, ji ber vê yekê me biryar da ku em karanîna Karûbar Vedîtina vebijarkî bikin.

Di yek-ewrê de, IP konteynerê dişopîne, ango her mînakek peywirê navnîşana IP-ya xwe heye. Ev navnîşan "statîk" e: dema ku karûbar yekem car ji ewr re tê şandin ji her nimûneyê re tê destnîşankirin. Ger karûbarek di dema jiyana xwe de hejmareke cûda mînakan hebe, wê hingê di dawiyê de ew ê bi qasî ku herî zêde mînakên wê hebûn navnîşanên IP-yê werin destnîşankirin.

Dûv re, ev navnîşan nayên guhertin: ew yek carî têne destnîşan kirin û di tevahiya jiyana karûbarê di hilberînê de hebûna xwe berdewam dikin. Navnîşanên IP-ê li seranserê torê konteyneran dişopînin. Ger konteynir ji minyonek din re were veguheztin, wê hingê navnîş wê li pey wê biçe.

Bi vî rengî, nexşeya navek karûbarê li navnîşa navnîşanên IP-ya wê pir kêm diguhezîne. Ger hûn dîsa li navên nimûneyên karûbarê ku me di destpêka gotarê de behs kiribûn binêrin (1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod,…), em ê bibînin ku ew dişibin FQDN-yên ku di DNS-ê de têne bikar anîn. Rast e, ji bo ku navên karûbarên karûbarê li navnîşanên IP-ya wan nexşînin, em protokola DNS bikar tînin. Digel vê yekê, ev DNS hemî navnîşanên IP-ya parastî yên hemî konteyneran vedigerîne - hem xebitîn û hem jî rawestandî (em bêjin sê kopya têne bikar anîn, û me pênc navnîşan li wir hatine veqetandin - her pênc dê werin vegerandin). Xerîdar, piştî ku ev agahdarî wergirtin, dê hewl bidin ku têkiliyek bi her pênc kopiyan re saz bikin - û bi vî rengî yên ku dixebitin destnîşan bikin. Vê vebijarkê ji bo destnîşankirina hebûna pir pêbawertir e; ew ne DNS û ne jî Vedîtina Karûbarê tê de nake, ku tê vê wateyê ku di dabînkirina têkildariya agahdarî û tolerasyona xeletiya van pergalan de pirsgirêkên dijwar tune ku werin çareser kirin. Digel vê yekê, di karûbarên krîtîk ên ku xebata tevahiya portalê pê ve girêdayî ye, em nikanin DNS-ê bi tevahî bikar bînin, lê tenê navnîşanên IP-ê têxin nav mîhengê.

Bicîhanîna veguheztina IP-ya wusa li pişt konteyneran dikare ne hindik be - û em ê lê binihêrin ka ew bi mînaka jêrîn çawa dixebite:

Ka em bibêjin serwerê yek-ewr fermanê dide minion M1 ku biçe 1.ok-web.group1.web.front.prod bi navnîşana 1.1.1.1. Li ser minyonek dixebite TEYR, ku vê navnîşanê ji pêşkêşkerên taybetî re reklam dike refleksorê rê. Ya paşîn bi hardware torê re rûniştinek BGP heye, ku tê de riya navnîşana 1.1.1.1 li ser M1 tê wergerandin. M1 bi karanîna Linux pakêtan di hundurê konteynerê de rê dike. Sê serverên refleksa rêgezê hene, ji ber ku ev beşek pir krîtîk a binesaziya yek-ewr e - bêyî wan, tora di yek-ewrê de dê nexebite. Em wan di refikên cihêreng de, heke gengaz be li odeyên cihêreng ên navenda daneyê bicîh bikin, da ku îhtîmala têkçûna her sêyan di heman demê de kêm bikin.

Ka em naha texmîn bikin ku pêwendiya di navbera masterê yek-ewrê û minion M1 de winda dibe. Mamosteyê yek-ewra naha dê li ser vê yekê tevbigere ku M1 bi tevahî têk çûye. Ango, ew ê fermanê bide miniona M2 ku dest pê bike web.group1.web.front.prod bi heman navnîşanê 1.1.1.1. Naha ji bo 1.1.1.1 li ser torê du rêyên nakok hene: li ser M1 û li ser M2. Ji bo çareserkirina nakokiyên weha, em Vebijarkera Pir Derketinê, ku di ragihandina BGP de hatî destnîşan kirin, bikar tînin. Ev hejmar e ku giraniya riya reklamkirî nîşan dide. Di nav rêyên nakok de, dê riya bi nirxa MED-ê kêmtir were hilbijartin. Mastera yek-ewra MED-ê wekî beşek yekbûyî ya navnîşanên IP-ya konteynerê piştgirî dike. Cara yekem, navnîş bi MEDek têra xwe mezin = 1 tê nivîsandin. Di rewşa veguheztina konteynerek wusa acîl de, master MED-ê kêm dike, û M000 dê berê fermanê werbigire ku navnîşana 000 bi MED = reklam bike. 2. Mînaka ku li ser M1.1.1.1 dimeşe dê di vê rewşê de bimîne, têkiliyek tine ye, û çarenûsa wî ya din hindik me eleqedar dike heya ku têkiliya bi master re were vegerandin, gava ku ew ê wekî hilberek kevn were sekinandin.

qezayan

Hemî pergalên rêveberiya navenda daneyê her gav têkçûnên piçûk bi rengekî qebûl dikin. Zêdebûna konteyner hema hema li her deverê norm e.

Werin em binihêrin ka em çawa bi rewşek awarte re mijûl dibin, wek mînak têkçûna hêzê li yek an çend odeyên navendek daneyê.

Wateya qezayek ji bo pergala rêveberiya navenda daneyê çi ye? Berî her tiştî, ev têkçûnek yek-car a pir makîneyan e, û pergala kontrolê hewce dike ku di heman demê de gelek konteyneran koç bike. Lê heke karesat pir mezin be, wê hingê dibe ku biqewime ku hemî peywir nekarin ji nû ve ji mîsyonên din re werin veqetandin, ji ber ku kapasîteya çavkaniyê ya navenda daneyê ji% 100-ê barkirinê dadikeve.

Pir caran qeza bi têkçûna qata kontrolê re pêk tê. Ev dikare ji ber têkçûna alavên wê çêbibe, lê pir caran ji ber vê yekê ku qeza nayên ceribandin, û qata kontrolê bixwe ji ber barkirina zêde dikeve.

Hûn dikarin li ser van hemî çi bikin?

Koçberiyên girseyî tê wê wateyê ku di binesaziyê de hejmareke mezin ji çalakî, koçberî û bicihkirin hene. Dibe ku her yek ji koçkirinê hin dem bigire ku ji bo radestkirin û rakirina wêneyên konteynerê ji minyonan re, destpêkirin û destpêkirina konteyneran, hwd. Ji ber vê yekê, tê xwestin ku karên girîngtir berî yên kêmtir girîng werin destpêkirin.

Ka em dîsa li hiyerarşiya karûbarên ku em pê nas in binihêrin û hewl bidin ku biryar bidin ka kîjan peywiran em dixwazin pêşî bimeşînin.

Bê guman, ev pêvajoyên ku rasterast di pêvajoyên daxwazên bikarhêneran de têkildar in, ango prod. Em bi vê yekê nîşan didin pêşanî danînê - hejmareke ku dikare li dorê were veqetandin. Ger rêzek pêşanîyek bilindtir hebe, karûbarên wê pêşîn têne danîn.

Li ser prod em pêşîneyên bilindtir destnîşan dikin, 0; li ser hev - hinekî kêmtir, 100; li ser bêkar - hê kêmtir, 200. Pêşanî bi hiyerarşî têne sepandin. Hemî peywirên di hiyerarşiyê de jêrîn dê xwedî pêşanîyek têkildar bin. Ger em dixwazin ku kaşên hundurê prodê berî pêşan werin destpêkirin, wê hingê em pêşîniyan didin cache = 0 û li jêr rêzên pêşîn = 1. Heke, wek nimûne, em dixwazin ku portala sereke ji pêşiyê ve were destpêkirin, û tenê pêşiya muzîkê paşê, wê hingê em dikarin pêşanîyek jêrîn ji ya paşîn re bidin - 10.

Pirsgirêka din kêmbûna çavkaniyan e. Ji ber vê yekê, hejmareke mezin a alavan, tevahî salonên navenda daneyê têk çûn, û me ew qas karûbar ji nû ve da destpêkirin ku naha çavkaniyên têra her kesî tune. Pêdivî ye ku hûn biryar bidin ka kîjan peywiran bikin qurban da ku karûbarên sereke yên krîtîk bimeşînin.

Berevajî pêşengiya cîhkirinê, em nekarin bêserûber hemî peywirên berhevokê bikin qurban; hin ji wan ji bo xebata portalê girîng in. Ji ber vê yekê, me ji hev cuda ronî kir pêşîniya pêşîn erkên. Dema ku were danîn, karek pêşîn a bilindtir dikare pêşî lê bigire, ango rawestîne, karek pêşînek kêmtir ger ku bêtir mîsyonên belaş nebin. Di vê rewşê de, peywirek bi pêşanî kêm dê bê cîh bimîne, ango dê êdî bi çavkaniyên belaş têra xwe mîhengek minasib ji bo wê tune be.

Di hiyerarşiya me de, pir hêsan e ku meriv pêşanînek pêşîlêgirtinê diyar bike wusa ku peywirên prod û komê pêşî li peywirên bêkar digirin an jî rawestînin, lê ne hevûdu, bi destnîşankirina pêşanîyek ji bo betaliyê bi qasî 200. Mîna ku di mijara pêşîniya cîhkirinê de, em dikare hiyerarşiya me ji bo danasîna qaîdeyên tevlihevtir bikar bîne. Mînakî, em destnîşan bikin ku em fonksiyona muzîkê feda dikin ger çavkaniyên me yên têr ji bo portala webê ya sereke nebin, pêşanî ji bo girêkên têkildar kêmtir destnîşan bikin: 10.

Tevahiya qezayên DC

Çima dibe ku tevahiya navenda daneyê têk bibe? Pêve. Postek baş bû bahozê bandor li xebatên navenda daneyê kir. Hêman dikarin mirovên bêmal werin hesibandin ku carekê optîka di pirjimarê de şewitandin, û navenda daneyê bi tevahî têkiliya xwe bi malperên din re winda kir. Sedema têkçûnê dikare faktorek mirovî jî be: operator dê fermanek wusa derxîne ku tevahiya navenda daneyê têkeve. Ev dibe ku ji ber xeletiyek mezin çêbibe. Bi gelemperî, hilweşîna navendên daneyê ne asayî ye. Ev çend mehan carekê tê serê me.

Û ev e ya ku em dikin ji bo ku kesek nehêle #zindî tweet bike.

Stratejiya yekem tecrîd e. Her mînakek yek-ewr veqetandî ye û dikare makîneyan tenê di navendek daneyê de birêve bibe. Ango windabûna ewr ji ber xeletî an fermanên nerast operator windabûna tenê navendek daneyê ye. Em ji bo vê amade ne: me siyasetek zêdebûnê heye ku tê de kopiyên serîlêdan û daneyan li hemî navendên daneyê hene. Em databasên xelet-tolerant bikar tînin û dem bi dem ji bo têkçûnê ceribandin.
Ji ber ku îro me çar navendên daneyê hene, ev tê vê wateyê ku çar mînakên veqetandî, bi tevahî veqetandî yên yek-ewrê.

Ev nêzîkatî ne tenê li hember têkçûna laşî diparêze, lê dikare li hember xeletiya operator jî biparêze.

Bi faktora mirovî ya din çi dikare were kirin? Gava ku operator fermanek xerîb an potansiyel xeternak dide ewr, dibe ku ji nişkê ve jê were xwestin ku pirsgirêkek piçûk çareser bike da ku bibîne ka ew çiqas baş difikire. Mînakî, heke ev celebek rawestana girseyî ya gelek kopiyan an tenê fermanek xerîb be - kêmkirina hejmara kopiyan an guheztina navê wêneyê, û ne tenê jimara guhertoya di manîfestoya nû de.

Encam

Taybetmendiyên cihêreng ên yek-ewrê:

Plana navên hiyerarşîk û dîtbarî ji bo karûbar û konteyneran, ku dihêle hûn pir zû fêr bibin ka peywir çi ye, bi çi re têkildar e û çawa dixebite û kî berpirsiyar e.
Em serlêdana xwe dikin teknîka tevhevkirina berhem- û hev-peywirên li ser minyonan ji bo baştirkirina karîgeriya parvekirina makîneyê. Li şûna cpuset em kotayên CPU, parvekirin, polîtîkayên plansazkerê CPU û QoS Linux bikar tînin.
Ne gengaz bû ku konteynerên ku li ser heman makîneyê dixebitin bi tevahî werin veqetandin, lê bandora wan a hevdu di nav 20% de dimîne.
Organîzekirina karûbaran di nav hiyerarşiyekê de bi karanîna vegerandina karesatê ya otomatîkî re dibe alîkar pêşîniyên cihgirtin û pêşîgirtinê.

FAQ

Çima me çareseriyek amade negirt?

Dema ku li ser minyonan têne danîn, çînên cihêreng ên veqetandina peywirê mentiqek cûda hewce dike. Ger peywirên prod bi tenê veqetandina çavkaniyan werin danîn, wê hingê divê peywirên kom û bêkar werin danîn, karanîna rastîn a çavkaniyan li ser makîneyên minion bişopînin.
Pêdivî ye ku meriv çavkaniyên ku ji hêla peywiran ve têne xerc kirin, wekî:
- bandwidth tora;
- cureyên û "spindles" dîskên.
Pêdivî ye ku di dema bersivdana acîl de pêşîneyên karûbaran, maf û kotayên fermanan ji bo çavkaniyan destnîşan bikin, ku bi karanîna rêzikên hiyerarşîk di yek-ewrê de têne çareser kirin.
Pêdivî ye ku navên mirovî yên konteyneran hebe da ku dema bersivdayînê ji qeza û bûyeran re kêm bibe
Nemimkûniya pêkanîna yek-car berfireh a Vedîtina Karûbarê; pêdiviya hevjiyana ji bo demek dirêj bi peywirên ku li ser hosteyên hardware têne çêkirin - tiştek ku ji hêla navnîşanên IP-ya "statîk" ên li dû konteyneran ve tê çareser kirin, û, wekî encam, hewcedariya yekbûnek bêhempa bi binesaziyek torê ya mezin re.

Hemî van fonksiyonan hewce dike ku guheztinên girîng ên çareseriyên heyî ku li gorî me bin, û, piştî ku hêjmara xebatê nirxand, me fêm kir ku em dikarin çareseriya xwe bi hema hema heman lêçûnên kedê pêş bixin. Lê çareseriya we dê xebitandin û pêşdebirina pir hêsantir be - ew abstraksyonên nehewce yên ku fonksiyonên ku em ne hewce ne piştgirî dikin vedihewîne.

Ji bo kesên ku rêzên dawî xwendin, spas ji bo sebir û bala we!

Source: www.habr.com

Yek-ewr - OS-ya asta navenda daneyê li Odnoklassniki