Un cwmwl - AO lefel canolfan ddata yn Odnoklassniki

Aloha, bobl! Fy enw i yw Oleg Anastasyev, rwy'n gweithio yn Odnoklassniki yn y tîm Platfform. Ac ar wahân i mi, mae llawer o galedwedd yn gweithio yn Odnoklassniki. Mae gennym bedair canolfan ddata gyda thua 500 o raciau gyda mwy nag 8 mil o weinyddion. Ar adeg benodol, sylweddolom y byddai cyflwyno system reoli newydd yn ein galluogi i lwytho offer yn fwy effeithlon, hwyluso rheoli mynediad, awtomeiddio (ail)ddosbarthu adnoddau cyfrifiadurol, cyflymu lansiad gwasanaethau newydd, a chyflymu ymatebion. i ddamweiniau ar raddfa fawr.

Beth ddaeth ohono?

Heblaw fi a chriw o galedwedd, mae yna hefyd bobl sy'n gweithio gyda'r caledwedd hwn: peirianwyr sydd wedi'u lleoli'n uniongyrchol mewn canolfannau data; rhwydwaithwyr sy'n sefydlu meddalwedd rhwydwaith; gweinyddwyr, neu SREs, sy'n darparu gwytnwch seilwaith; a thimau datblygu, mae pob un ohonynt yn gyfrifol am ran o swyddogaethau’r porth. Mae'r meddalwedd maen nhw'n ei greu yn gweithio rhywbeth fel hyn:

Derbynnir ceisiadau gan ddefnyddwyr ar flaen y prif borth www.ok.ru, ac ar eraill, er enghraifft ar flaenau API cerddoriaeth. I brosesu'r rhesymeg busnes, maen nhw'n galw gweinydd y cais, sydd, wrth brosesu'r cais, yn galw'r microwasanaethau arbenigol angenrheidiol - un graff (graff o gysylltiadau cymdeithasol), storfa defnyddiwr (storfa o broffiliau defnyddwyr), ac ati.

Mae pob un o'r gwasanaethau hyn yn cael eu defnyddio ar lawer o beiriannau, ac mae gan bob un ohonynt ddatblygwyr cyfrifol sy'n gyfrifol am weithrediad y modiwlau, eu gweithrediad a datblygiad technolegol. Mae'r holl wasanaethau hyn yn rhedeg ar weinyddion caledwedd, a than yn ddiweddar fe wnaethom lansio union un dasg fesul gweinydd, h.y. roedd yn arbenigo ar gyfer tasg benodol.

Pam hynny? Roedd gan y dull hwn nifer o fanteision:

• Rhyddhawyd rheoli torfol. Gadewch i ni ddweud bod tasg yn gofyn am rai llyfrgelloedd, rhai gosodiadau. Ac yna mae'r gweinydd yn cael ei neilltuo i un grŵp penodol yn union, mae'r polisi cfengine ar gyfer y grŵp hwn yn cael ei ddisgrifio (neu mae eisoes wedi'i ddisgrifio), ac mae'r cyfluniad hwn yn cael ei gyflwyno'n ganolog ac yn awtomatig i bob gweinydd yn y grŵp hwn.
• Syml diagnosteg. Gadewch i ni ddweud eich bod yn edrych ar y llwyth cynyddol ar y prosesydd canolog ac yn sylweddoli mai dim ond y dasg sy'n rhedeg ar y prosesydd caledwedd hwn y gellid cynhyrchu'r llwyth hwn. Mae'r chwilio am rywun ar fai yn dod i ben yn gyflym iawn.
• Syml monitro. Os oes rhywbeth o'i le ar y gweinydd, mae'r monitor yn ei adrodd, ac rydych chi'n gwybod yn union pwy sydd ar fai.

Mae gwasanaeth sy'n cynnwys sawl atgynhyrchiad yn cael ei ddyrannu i sawl gweinydd - un ar gyfer pob un. Yna mae'r adnodd cyfrifiadurol ar gyfer y gwasanaeth yn cael ei ddyrannu'n syml iawn: nifer y gweinyddwyr sydd gan y gwasanaeth, uchafswm yr adnoddau y gall eu defnyddio. Nid yw “hawdd” yma yn golygu ei fod yn hawdd ei ddefnyddio, ond yn yr ystyr bod dyrannu adnoddau yn cael ei wneud â llaw.

Roedd y dull hwn hefyd yn caniatáu i ni wneud cyfluniadau haearn arbenigol ar gyfer tasg sy'n rhedeg ar y gweinydd hwn. Os yw'r dasg yn storio llawer iawn o ddata, yna rydym yn defnyddio gweinydd 4U gyda siasi gyda 38 disg. Os yw'r dasg yn gwbl gyfrifiadol, yna gallwn brynu gweinydd 1U rhatach. Mae hyn yn gyfrifiadurol effeithlon. Ymhlith pethau eraill, mae'r dull hwn yn caniatáu inni ddefnyddio pedair gwaith yn llai o beiriannau gyda llwyth tebyg i un rhwydwaith cymdeithasol cyfeillgar.

Dylai effeithlonrwydd o'r fath yn y defnydd o adnoddau cyfrifiadurol hefyd sicrhau effeithlonrwydd economaidd, os awn ymlaen o'r rhagdybiaeth mai'r peth drutaf yw gweinyddwyr. Am gyfnod hir, caledwedd oedd y drutaf, a gwnaethom lawer o ymdrech i leihau pris caledwedd, gan lunio algorithmau goddefgarwch diffygion i leihau gofynion dibynadwyedd caledwedd. A heddiw rydym wedi cyrraedd y cam lle mae pris y gweinydd wedi peidio â bod yn bendant. Os nad ydych yn ystyried yr egsotigau diweddaraf, yna nid yw cyfluniad penodol y gweinyddwyr yn y rac o bwys. Nawr mae gennym broblem arall - pris y gofod a feddiannir gan y gweinydd yn y ganolfan ddata, hynny yw, y gofod yn y rac.

Gan sylweddoli bod hyn yn wir, fe benderfynon ni gyfrifo pa mor effeithiol oedden ni'n defnyddio'r raciau.
Fe wnaethon ni gymryd pris y gweinydd mwyaf pwerus o'r rhai y gellir eu cyfiawnhau'n economaidd, cyfrifo faint o weinyddion o'r fath y gallem eu gosod mewn rheseli, faint o dasgau y byddem yn eu rhedeg arnynt yn seiliedig ar yr hen fodel “un gweinydd = un dasg” a faint o'r fath gallai tasgau ddefnyddio'r offer. Maent yn cyfrif ac yn taflu dagrau. Mae'n troi allan bod ein heffeithlonrwydd wrth ddefnyddio raciau yw tua 11%. Mae'r casgliad yn amlwg: mae angen inni gynyddu effeithlonrwydd defnyddio canolfannau data. Mae'n ymddangos bod yr ateb yn amlwg: mae angen i chi redeg sawl tasg ar un gweinydd ar unwaith. Ond dyma lle mae'r anawsterau'n dechrau.

Mae cyfluniad màs yn dod yn llawer mwy cymhleth - mae bellach yn amhosibl aseinio unrhyw un grŵp i weinydd. Wedi'r cyfan, nawr gellir lansio sawl tasg o wahanol orchmynion ar un gweinydd. Yn ogystal, gall y cyfluniad fod yn gwrthdaro ar gyfer gwahanol gymwysiadau. Mae diagnosis hefyd yn dod yn fwy cymhleth: os gwelwch fwy o ddefnydd o CPU neu ddisg ar weinydd, nid ydych chi'n gwybod pa dasg sy'n achosi trafferth.

Ond y prif beth yw nad oes unrhyw ynysu rhwng tasgau sy'n rhedeg ar yr un peiriant. Yma, er enghraifft, mae graff o amser ymateb cyfartalog tasg gweinyddwr cyn ac ar ôl i raglen gyfrifiadol arall gael ei lansio ar yr un gweinydd, nad yw'n gysylltiedig mewn unrhyw ffordd â'r un cyntaf - mae amser ymateb y brif dasg wedi cynyddu'n sylweddol.

Yn amlwg, mae angen i chi redeg tasgau naill ai mewn cynwysyddion neu mewn peiriannau rhithwir. Gan fod bron pob un o'n tasgau yn rhedeg o dan un OS (Linux) neu wedi'u haddasu ar ei gyfer, nid oes angen i ni gefnogi llawer o systemau gweithredu gwahanol. Yn unol â hynny, nid oes angen rhithwiroli; oherwydd y gorbenion ychwanegol, bydd yn llai effeithlon na chynhwysiad.

Fel gweithrediad cynwysyddion ar gyfer rhedeg tasgau yn uniongyrchol ar weinyddion, mae Docker yn ymgeisydd da: mae delweddau system ffeiliau yn datrys problemau gyda chyfluniadau sy'n gwrthdaro yn dda. Mae'r ffaith y gall delweddau gynnwys sawl haen yn ein galluogi i leihau'n sylweddol faint o ddata sydd ei angen i'w defnyddio ar y seilwaith, gan wahanu rhannau cyffredin yn haenau sylfaen ar wahân. Yna bydd yr haenau sylfaenol (a mwyaf swmpus) yn cael eu storio'n weddol gyflym trwy'r seilwaith cyfan, ac i gyflwyno llawer o wahanol fathau o gymwysiadau a fersiynau, dim ond haenau bach y bydd angen eu trosglwyddo.

Hefyd, mae cofrestrfa barod a thagio delweddau yn Docker yn rhoi cyntefigau parod i ni ar gyfer fersiwn a danfon cod i'r cynhyrchiad.

Mae Docker, fel unrhyw dechnoleg debyg arall, yn rhoi rhywfaint o ynysu cynhwysydd i ni allan o'r bocs. Er enghraifft, ynysu cof - rhoddir terfyn ar y defnydd o gof peiriant i bob cynhwysydd, ac ni fydd yn bwyta y tu hwnt i hynny. Gallwch hefyd ynysu cynwysyddion yn seiliedig ar ddefnydd CPU. I ni, fodd bynnag, nid oedd inswleiddio safonol yn ddigon. Ond mwy am hynny isod.

Dim ond rhan o'r broblem yw rhedeg cynwysyddion yn uniongyrchol ar weinyddion. Mae'r rhan arall yn ymwneud â chynnal cynwysyddion ar weinyddion. Mae angen i chi ddeall pa gynhwysydd y gellir ei osod ar ba weinydd. Nid yw hon yn dasg mor hawdd, oherwydd mae angen gosod cynwysyddion ar weinyddion mor ddwys â phosibl heb leihau eu cyflymder. Gall lleoliad o'r fath fod yn anodd hefyd o safbwynt goddef diffygion. Yn aml, rydym am osod copïau o'r un gwasanaeth mewn gwahanol raciau neu hyd yn oed mewn gwahanol ystafelloedd yn y ganolfan ddata, fel na fyddwn yn colli'r holl atgynyrchiadau gwasanaeth ar unwaith os bydd rac neu ystafell yn methu.

Nid yw dosbarthu cynwysyddion â llaw yn opsiwn pan fydd gennych 8 mil o weinyddion ac 8-16 mil o gynwysyddion.

Yn ogystal, roeddem am roi mwy o annibyniaeth i ddatblygwyr wrth ddyrannu adnoddau fel y gallent gynnal eu gwasanaethau cynhyrchu eu hunain, heb gymorth gweinyddwr. Ar yr un pryd, roeddem am gadw rheolaeth fel na fyddai rhai mân wasanaethau yn defnyddio holl adnoddau ein canolfannau data.

Yn amlwg, mae angen haen reoli a fyddai'n gwneud hyn yn awtomatig.

Felly daethom at ddarlun syml a dealladwy y mae pob pensaer yn ei garu: tri sgwâr.

mae meistri un cwmwl yn glwstwr methiant sy'n gyfrifol am offeryniaeth cwmwl. Mae'r datblygwr yn anfon maniffest at y meistr, sy'n cynnwys yr holl wybodaeth angenrheidiol i gynnal y gwasanaeth. Yn seiliedig arno, mae'r meistr yn rhoi gorchmynion i minions dethol (peiriannau sydd wedi'u cynllunio i redeg cynwysyddion). Mae gan y minions ein hasiant, sy'n derbyn y gorchymyn, yn cyhoeddi ei orchmynion i Docker, ac mae Docker yn ffurfweddu'r cnewyllyn linux i lansio'r cynhwysydd cyfatebol. Yn ogystal â gweithredu gorchmynion, mae'r asiant yn adrodd yn barhaus i'r meistr am newidiadau yng nghyflwr y peiriant minion a'r cynwysyddion sy'n rhedeg arno.

Dyrannu Adnoddau

Nawr, gadewch i ni edrych ar y broblem o ddyrannu adnoddau mwy cymhleth ar gyfer llawer o minions.

Adnodd cyfrifiadura mewn un cwmwl yw:

• Faint o bŵer prosesydd a ddefnyddir gan dasg benodol.
• Faint o gof sydd ar gael i'r dasg.
• Traffig rhwydwaith. Mae gan bob un o'r minions ryngwyneb rhwydwaith penodol gyda lled band cyfyngedig, felly mae'n amhosibl dosbarthu tasgau heb ystyried faint o ddata y maent yn ei drosglwyddo dros y rhwydwaith.
• Disgiau. Yn ogystal, yn amlwg, i'r gofod ar gyfer y tasgau hyn, rydym hefyd yn dyrannu'r math o ddisg: HDD neu SSD. Gall disgiau wasanaethu nifer cyfyngedig o geisiadau yr eiliad - IOPS. Felly, ar gyfer tasgau sy'n cynhyrchu mwy o IOPS nag y gall disg sengl eu trin, rydym hefyd yn dyrannu “gwerthydau” - hynny yw, dyfeisiau disg y mae'n rhaid eu cadw'n gyfan gwbl ar gyfer y dasg.

Yna ar gyfer rhywfaint o wasanaeth, er enghraifft ar gyfer storfa defnyddiwr, gallwn gofnodi'r adnoddau a ddefnyddir yn y modd hwn: 400 craidd prosesydd, 2,5 TB o gof, traffig 50 Gbit yr eiliad i'r ddau gyfeiriad, 6 TB o ofod HDD wedi'i leoli ar 100 gwerthyd. Neu ar ffurf fwy cyfarwydd fel hyn:

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

Dim ond cyfran o'r holl adnoddau sydd ar gael yn y seilwaith cynhyrchu y mae adnoddau gwasanaeth storfa defnyddiwr yn ei ddefnyddio. Felly, rwyf am wneud yn siŵr yn sydyn, oherwydd gwall gweithredwr neu beidio, nad yw'r storfa defnyddiwr yn defnyddio mwy o adnoddau nag a ddyrennir iddo. Hynny yw, rhaid inni gyfyngu ar adnoddau. Ond at beth y gallem glymu'r cwota?

Gadewch i ni ddychwelyd at ein diagram symlach iawn o ryngweithio cydrannau a'i ail-lunio gyda mwy o fanylion - fel hyn:

Beth sy'n dal eich llygad:

• Mae blaen y we a cherddoriaeth yn defnyddio clystyrau ynysig o'r un gweinydd rhaglenni.
• Gallwn wahaniaethu rhwng yr haenau rhesymegol y mae'r clystyrau hyn yn perthyn iddynt: blaenau, celciau, storio data a haenau rheoli.
• Mae'r blaen yn heterogenaidd; mae'n cynnwys gwahanol is-systemau swyddogaethol.
• Gall caches hefyd gael eu gwasgaru ar draws yr is-system y maent yn storio data.

Gadewch i ni ail-lunio'r llun eto:

Ystyr geiriau: Bah! Ydym, rydym yn gweld hierarchaeth! Mae hyn yn golygu y gallwch chi ddosbarthu adnoddau mewn talpiau mwy: aseinio datblygwr cyfrifol i nod o'r hierarchaeth hon sy'n cyfateb i'r is-system swyddogaethol (fel “cerddoriaeth” yn y llun), ac atodi cwota i'r un lefel o'r hierarchaeth. Mae'r hierarchaeth hon hefyd yn ein galluogi i drefnu gwasanaethau'n fwy hyblyg er hwylustod. Er enghraifft, rydym yn rhannu'r we i gyd, gan fod hwn yn grŵp mawr iawn o weinyddion, yn nifer o grwpiau llai, a ddangosir yn y llun fel grŵp 1, grŵp2.

Trwy dynnu’r llinellau ychwanegol, gallwn ysgrifennu pob nod o’n llun ar ffurf fwy gwastad: grŵp1.gwe.front, api.music.front, user-cache.cache.

Dyma sut rydym yn dod at y cysyniad o “ciw hierarchaidd”. Mae ganddo enw fel "group1.web.front". Rhoddir cwota ar gyfer adnoddau a hawliau defnyddwyr iddo. Byddwn yn rhoi'r hawliau i'r person o DevOps anfon gwasanaeth i'r ciw, a gall gweithiwr o'r fath lansio rhywbeth yn y ciw, a bydd gan y person o OpsDev hawliau gweinyddol, a nawr gall reoli'r ciw, aseinio pobl yno, rhoi hawliau i'r bobl hyn, ac ati. Bydd gwasanaethau sy'n rhedeg ar y ciw hwn yn rhedeg o fewn cwota'r ciw. Os nad yw cwota cyfrifiadurol y ciw yn ddigon i weithredu'r holl wasanaethau ar unwaith, yna byddant yn cael eu gweithredu'n ddilyniannol, gan ffurfio'r ciw ei hun.

Gadewch i ni edrych yn agosach ar y gwasanaethau. Mae gan wasanaeth enw cwbl gymwys, sydd bob amser yn cynnwys enw'r ciw. Yna bydd gan y gwasanaeth gwe blaen yr enw iawn-web.group1.web.front. A bydd y gwasanaeth gweinydd cais y mae'n ei gyrchu yn cael ei alw iawn-app.group1.web.front. Mae gan bob gwasanaeth faniffest, sy'n nodi'r holl wybodaeth angenrheidiol ar gyfer gosod peiriannau penodol: faint o adnoddau y mae'r dasg hon yn eu defnyddio, pa gyfluniad sydd ei angen ar ei gyfer, faint o atgynhyrchiadau ddylai fod, priodweddau ar gyfer trin methiannau'r gwasanaeth hwn. Ac ar ôl i'r gwasanaeth gael ei osod yn uniongyrchol ar y peiriannau, mae ei achosion yn ymddangos. Maent hefyd yn cael eu henwi'n ddiamwys - fel rhif yr enghraifft ac enw'r gwasanaeth: 1.ok-web.group1.web.front, 2.ok-web.group1.web.front, …

Mae hyn yn gyfleus iawn: trwy edrych ar enw'r cynhwysydd rhedeg yn unig, gallwn ddarganfod llawer ar unwaith.

Nawr gadewch i ni edrych yn agosach ar yr hyn y mae'r achosion hyn yn ei gyflawni mewn gwirionedd: tasgau.

Dosbarthiadau ynysu Tasg

Gellir rhannu pob tasg yn Iawn (ac, yn ôl pob tebyg, ym mhobman) yn grwpiau:

• Tasgau Cudd Byr - prod. Ar gyfer tasgau a gwasanaethau o'r fath, mae'r oedi o ran ymateb (latency) yn bwysig iawn, pa mor gyflym y bydd pob un o'r ceisiadau'n cael eu prosesu gan y system. Enghreifftiau o dasgau: blaenau gwe, caches, gweinyddwyr cymwysiadau, storfa OLTP, ac ati.
• Problemau cyfrifo - swp. Yma, nid yw cyflymder prosesu pob cais penodol yn bwysig. Ar eu cyfer, mae'n bwysig faint o gyfrifiadau y bydd y dasg hon yn eu gwneud mewn cyfnod penodol (hir) o amser (trwybwn). Bydd y rhain yn unrhyw dasgau MapReduce, Hadoop, dysgu peirianyddol, ystadegau.
• Tasgau cefndir - segur. Ar gyfer tasgau o'r fath, nid yw hwyrni na thrwybwn yn bwysig iawn. Mae hyn yn cynnwys profion amrywiol, ymfudiadau, ailgyfrifiadau, a throsi data o un fformat i'r llall. Ar y naill law, maent yn debyg i rai a gyfrifwyd, ar y llaw arall, nid oes ots gennym ni pa mor gyflym y cânt eu cwblhau.

Gadewch i ni weld sut mae tasgau o'r fath yn defnyddio adnoddau, er enghraifft, y prosesydd canolog.

Tasgau oedi byr. Bydd gan dasg o'r fath batrwm defnydd CPU tebyg i hyn:

Derbynnir cais gan y defnyddiwr am brosesu, mae'r dasg yn dechrau defnyddio'r holl greiddiau CPU sydd ar gael, yn ei brosesu, yn dychwelyd ymateb, yn aros am y cais nesaf ac yn stopio. Cyrhaeddodd y cais nesaf - eto fe wnaethom ddewis popeth oedd yno, ei gyfrifo, ac rydym yn aros am yr un nesaf.

Er mwyn gwarantu'r hwyrni lleiaf ar gyfer tasg o'r fath, rhaid inni gymryd yr adnoddau mwyaf y mae'n eu defnyddio a chadw'r nifer gofynnol o greiddiau ar y minion (y peiriant a fydd yn cyflawni'r dasg). Yna bydd y fformiwla cadw ar gyfer ein problem fel a ganlyn:

alloc: cpu = 4 (max)

ac os oes gennym beiriant minion gydag 16 o greiddiau, yna yn union y gellir gosod pedair tasg o'r fath arno. Rydym yn nodi'n arbennig bod y defnydd o broseswyr ar gyfartaledd o dasgau o'r fath yn aml yn isel iawn - sy'n amlwg, gan fod rhan sylweddol o'r amser y dasg yn aros am gais ac yn gwneud dim.

Tasgau cyfrifo. Bydd eu patrwm ychydig yn wahanol:

Mae'r defnydd o adnoddau CPU cyfartalog ar gyfer tasgau o'r fath yn eithaf uchel. Yn aml rydym am i dasg gyfrifo gwblhau mewn cyfnod penodol o amser, felly mae angen inni gadw'r nifer lleiaf o broseswyr sydd eu hangen arno fel bod y cyfrifiad cyfan yn cael ei gwblhau mewn amser derbyniol. Bydd ei fformiwla cadw yn edrych fel hyn:

alloc: cpu = [1,*)

“Rhowch ef ar finion lle mae o leiaf un craidd rhad ac am ddim, ac yna cymaint ag sydd, bydd yn difa popeth.”

Yma mae effeithlonrwydd defnydd eisoes yn llawer gwell nag ar dasgau gydag oedi byr. Ond bydd y fantais yn llawer mwy os byddwch chi'n cyfuno'r ddau fath o dasg ar un peiriant minion ac yn dosbarthu ei adnoddau wrth fynd. Pan fydd angen prosesydd ar dasg gydag oedi byr, mae'n ei derbyn ar unwaith, a phan nad oes angen yr adnoddau mwyach, cânt eu trosglwyddo i'r dasg gyfrifiadol, h.y. rhywbeth fel hyn:

Ond sut i wneud hynny?

Yn gyntaf, gadewch i ni edrych ar y cynnyrch a'i alloc: cpu = 4. Mae angen inni gadw pedwar craidd. Yn Docker run gellir gwneud hyn mewn dwy ffordd:

• Gan ddefnyddio'r opsiwn --cpuset=1-4, h.y. dyrannu pedwar craidd penodol ar y peiriant i'r dasg.
• Defnyddio --cpuquota=400_000 --cpuperiod=100_000, neilltuo cwota ar gyfer amser prosesydd, h.y. dangoswch nad yw'r dasg yn defnyddio mwy na 100 ms o amser prosesydd bob 400 ms o amser real. Ceir yr un pedwar craidd.

Ond pa un o'r dulliau hyn sy'n addas?

Mae cpuset yn edrych yn eithaf deniadol. Mae gan y dasg bedwar craidd pwrpasol, sy'n golygu y bydd caches prosesydd yn gweithio mor effeithlon â phosibl. Mae anfantais i hyn hefyd: byddai'n rhaid i ni ymgymryd â'r dasg o ddosbarthu cyfrifiadau ar draws creiddiau dadlwytho'r peiriant yn lle'r OS, ac mae hon yn dasg braidd yn ddibwys, yn enwedig os byddwn yn ceisio gosod tasgau swp ar y fath peiriant. Mae profion wedi dangos bod yr opsiwn gyda chwota yn fwy addas yma: fel hyn mae gan y system weithredu fwy o ryddid wrth ddewis y craidd i gyflawni'r dasg ar hyn o bryd ac mae amser y prosesydd yn cael ei ddosbarthu'n fwy effeithlon.

Gadewch i ni ddarganfod sut i wneud archebion yn Docker yn seiliedig ar y nifer lleiaf o greiddiau. Nid yw'r cwota ar gyfer tasgau swp bellach yn berthnasol, oherwydd nid oes angen cyfyngu ar yr uchafswm, mae'n ddigon i warantu'r lleiafswm yn unig. Ac yma mae'r opsiwn yn cyd-fynd yn dda docker run --cpushares.

Fe wnaethom gytuno, os oes angen gwarant am o leiaf un craidd ar swp, yna rydym yn nodi --cpushares=1024, ac os oes o leiaf ddau graidd, yna rydym yn nodi --cpushares=2048. Nid yw cyfranddaliadau cpu yn ymyrryd mewn unrhyw ffordd â dosbarthiad amser prosesydd cyn belled â bod digon ohono. Felly, os nad yw prod yn defnyddio ei bedwar craidd ar hyn o bryd, nid oes unrhyw beth yn cyfyngu ar dasgau swp, a gallant ddefnyddio amser prosesydd ychwanegol. Ond mewn sefyllfa lle mae prinder proseswyr, os yw prod wedi defnyddio pob un o'i bedwar craidd ac wedi cyrraedd ei gwota, bydd yr amser prosesydd sy'n weddill yn cael ei rannu'n gymesur â cpushares, h.y. mewn sefyllfa o dri chraidd rhydd, bydd un yn cael ei rannu'n gymesur. rhoi i dasg gyda 1024 cpushares, a bydd y ddau sy'n weddill yn cael eu rhoi i dasg gyda 2048 cpushares.

Ond nid yw defnyddio cwota a chyfranddaliadau yn ddigon. Mae angen inni wneud yn siŵr bod tasg ag oedi byr yn cael blaenoriaeth dros dasg swp wrth ddyrannu amser prosesydd. Heb flaenoriaethu o'r fath, bydd y dasg swp yn cymryd yr holl amser prosesydd ar hyn o bryd pan fydd ei angen ar y prod. Nid oes unrhyw opsiynau blaenoriaethu cynhwysydd yn rhediad Docker, ond mae polisïau amserlennu Linux CPU yn ddefnyddiol. Gallwch ddarllen amdanynt yn fanwl yma, ac o fewn fframwaith yr erthygl hon byddwn yn mynd drwyddynt yn fyr:

• SCED_OTHER
  Yn ddiofyn, mae pob proses defnyddiwr arferol ar beiriant Linux yn derbyn.
• SCHED_BATCH
  Wedi'i gynllunio ar gyfer prosesau sy'n defnyddio llawer o adnoddau. Wrth osod tasg ar brosesydd, cyflwynir cosb actifadu fel y'i gelwir: mae tasg o'r fath yn llai tebygol o dderbyn adnoddau prosesydd os yw'n cael ei defnyddio ar hyn o bryd gan dasg gyda SCHED_OTHER
• SCED_IDLE
  Proses gefndir gyda blaenoriaeth isel iawn, hyd yn oed yn is na braf -19. Rydym yn defnyddio ein llyfrgell ffynhonnell agored un-nio, er mwyn gosod y polisi angenrheidiol wrth gychwyn y cynhwysydd trwy ffonio

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

Ond hyd yn oed os nad ydych chi'n rhaglennu yn Java, gellir gwneud yr un peth gan ddefnyddio'r gorchymyn chrt:

chrt -i 0 $pid

Gadewch i ni grynhoi ein holl lefelau ynysu mewn un tabl er eglurder:

Dosbarth inswleiddio
Enghraifft Alloc
Opsiynau rhedeg docwr
sched_setscheduler chrt*

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

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

Segur
Cpu= [2, *)
--cpushares=2048
SCED_IDLE

* Os ydych chi'n gwneud chrt o'r tu mewn i gynhwysydd, efallai y bydd angen y gallu sys_nice arnoch chi, oherwydd yn ddiofyn mae Docker yn dileu'r gallu hwn wrth gychwyn y cynhwysydd.

Ond mae tasgau'n defnyddio nid yn unig y prosesydd, ond hefyd traffig, sy'n effeithio ar hwyrni tasg rhwydwaith hyd yn oed yn fwy na'r dyraniad anghywir o adnoddau prosesydd. Felly, yn naturiol rydym am gael yr un darlun yn union ar gyfer traffig. Hynny yw, pan fydd tasg prod yn anfon rhai pecynnau i'r rhwydwaith, rydym yn cyfyngu ar y cyflymder uchaf (fformiwla aloc: lan=[*,500mbps) ), ag y gall prod wneyd hyn. Ac ar gyfer swp rydym yn gwarantu dim ond y mewnbwn lleiaf, ond nid ydym yn cyfyngu ar yr uchafswm (fformiwla aloc: lan=[10Mbps,*) ) Yn yr achos hwn, dylai traffig prod gael blaenoriaeth dros dasgau swp.
Yma nid oes gan Docker unrhyw cyntefig y gallwn ei ddefnyddio. Ond mae'n dod i'n cymorth ni Rheoli Traffig Linux. Roeddem yn gallu cyflawni'r canlyniad dymunol gyda chymorth disgyblaeth Cromlin Gwasanaeth Teg Hierarchaidd. Gyda'i help, rydym yn gwahaniaethu rhwng dau ddosbarth o draffig: prod â blaenoriaeth uchel a swp/segur â blaenoriaeth isel. O ganlyniad, mae'r ffurfweddiad ar gyfer traffig sy'n mynd allan fel hyn:

yma 1:0 yw “root qdisc” disgyblaeth hsfc; 1:1 - dosbarth plant hsfc gyda therfyn lled band o 8 Gbit yr eiliad, y mae dosbarthiadau plant yr holl gynwysyddion yn cael eu gosod oddi tano; 1:2 - mae dosbarth plant hsfc yn gyffredin i bob tasg swp a segur gyda therfyn “deinamig”, a drafodir isod. Mae'r dosbarthiadau plant hsfc sy'n weddill yn ddosbarthiadau pwrpasol ar gyfer rhedeg cynwysyddion prod ar hyn o bryd gyda chyfyngiadau sy'n cyfateb i'w maniffestau - 450 a 400 Mbit yr eiliad. Rhoddir ciw qdisc fq neu fq_codel i bob dosbarth hsfc, yn dibynnu ar y fersiwn cnewyllyn Linux, er mwyn osgoi colli pecynnau yn ystod ffrwydradau traffig.

Yn nodweddiadol, mae disgyblaethau tc yn rhoi blaenoriaeth i draffig sy'n mynd allan yn unig. Ond rydym am flaenoriaethu traffig sy'n dod i mewn hefyd - wedi'r cyfan, gall rhywfaint o dasg swp ddewis y sianel gyfan sy'n dod i mewn yn hawdd, gan dderbyn, er enghraifft, swp mawr o ddata mewnbwn ar gyfer map a lleihau. Ar gyfer hyn rydym yn defnyddio'r modiwl ifb, sy'n creu rhyngwyneb rhithwir ifbX ar gyfer pob rhyngwyneb rhwydwaith ac yn ailgyfeirio traffig sy'n dod i mewn o'r rhyngwyneb i draffig sy'n mynd allan ar ifbX. Ymhellach, ar gyfer ifbX, mae'r un disgyblaethau i gyd yn gweithio i reoli traffig sy'n mynd allan, y bydd y ffurfweddiad hsfc yn debyg iawn ar ei gyfer:

Yn ystod yr arbrofion, fe wnaethom ddarganfod bod hsfc yn dangos y canlyniadau gorau pan fo'r dosbarth 1:2 o draffig swp/segur nad yw'n flaenoriaeth wedi'i gyfyngu ar beiriannau minion i ddim mwy na lôn rydd benodol. Fel arall, mae traffig nad yw'n flaenoriaeth yn cael gormod o effaith ar hwyrni tasgau prod. Mae miniond yn pennu swm cyfredol y lled band rhad ac am ddim bob eiliad, gan fesur defnydd traffig cyfartalog holl dasgau prod minion penodol a'i dynnu o led band rhyngwyneb y rhwydwaith gydag ymyl bach, h.y.

Mae bandiau'n cael eu diffinio'n annibynnol ar gyfer traffig sy'n dod i mewn ac yn mynd allan. Ac yn ôl y gwerthoedd newydd, mae miniond yn ad-drefnu'r terfyn dosbarth nad yw'n flaenoriaeth 1:2.

Felly, fe wnaethom weithredu pob un o'r tri dosbarth ynysu: prod, swp a segur. Mae'r dosbarthiadau hyn yn dylanwadu'n fawr ar nodweddion perfformiad tasgau. Felly, penderfynasom osod y nodwedd hon ar frig yr hierarchaeth, fel y byddai'n amlwg ar unwaith wrth edrych ar enw'r ciw hierarchaidd yr hyn yr ydym yn delio ag ef:

Ein ffrindiau i gyd we и cerddoriaeth yna gosodir y blaenau yn yr hierarchaeth o dan prod. Er enghraifft, o dan swp, gadewch i ni osod y gwasanaeth catalog cerddoriaeth, sydd o bryd i'w gilydd yn llunio catalog o draciau o set o ffeiliau mp3 a uwchlwythwyd i Odnoklassniki. Enghraifft o wasanaeth dan segur fyddai trawsnewidydd cerddoriaeth, sy'n normaleiddio lefel cyfaint y gerddoriaeth.

Gyda'r llinellau ychwanegol wedi'u tynnu eto, gallwn ysgrifennu ein henwau gwasanaeth yn fwy gwastad trwy ychwanegu'r dosbarth ynysu tasgau at ddiwedd enw'r gwasanaeth llawn: gwe.front.prod, catalog.music.batch, trawsnewidydd.music.idle.

Ac yn awr, o edrych ar enw'r gwasanaeth, rydym yn deall nid yn unig pa swyddogaeth y mae'n ei chyflawni, ond hefyd ei ddosbarth ynysu, sy'n golygu ei gritigolrwydd, ac ati.

Mae popeth yn wych, ond mae un gwirionedd chwerw. Mae'n amhosibl ynysu tasgau sy'n rhedeg ar un peiriant yn llwyr.

Yr hyn y llwyddasom i'w gyflawni: os bydd swp yn bwyta'n ddwys yn unig Adnoddau CPU, yna mae'r amserlenydd CPU Linux adeiledig yn gwneud ei waith yn dda iawn, ac nid oes bron unrhyw effaith ar y dasg prod. Ond os yw'r dasg swp hon yn dechrau gweithio'n weithredol gyda'r cof, yna mae'r dylanwad ar y cyd eisoes yn ymddangos. Mae hyn yn digwydd oherwydd bod y dasg prod yn cael ei “golchi allan” o gelciau cof y prosesydd - o ganlyniad, mae cache yn colli cynnydd, ac mae'r prosesydd yn prosesu'r dasg prod yn arafach. Gall tasg swp o'r fath gynyddu hwyrni ein cynhwysydd prod nodweddiadol 10%.

Mae ynysu traffig hyd yn oed yn fwy anodd oherwydd bod gan gardiau rhwydwaith modern giw mewnol o becynnau. Os bydd y pecyn o'r dasg swp yn cyrraedd yno yn gyntaf, yna hwn fydd y cyntaf i gael ei drosglwyddo dros y cebl, ac ni ellir gwneud dim amdano.

Yn ogystal, hyd yn hyn, dim ond y broblem o flaenoriaethu traffig TCP yr ydym wedi llwyddo i'w datrys: nid yw'r dull hsfc yn gweithio i'r CDU. A hyd yn oed yn achos traffig TCP, os yw'r dasg swp yn cynhyrchu llawer o draffig, mae hyn hefyd yn rhoi tua 10% o gynnydd yn oedi'r dasg prod.

goddefgarwch fai

Un o'r nodau wrth ddatblygu un-cwmwl oedd gwella goddefgarwch namau o Odnoklassniki. Felly, nesaf hoffwn ystyried yn fanylach senarios posibl o fethiannau a damweiniau. Gadewch i ni ddechrau gyda senario syml - methiant cynhwysydd.

Gall y cynhwysydd ei hun fethu mewn sawl ffordd. Gallai hyn fod yn rhyw fath o arbrawf, byg neu wall yn y maniffest, ac oherwydd hynny mae'r dasg prod yn dechrau defnyddio mwy o adnoddau nag a nodir yn y maniffest. Roedd gennym achos: gweithredodd datblygwr un algorithm cymhleth, ei ail-weithio lawer gwaith, gor-feddwl ei hun a daeth mor ddryslyd fel bod y broblem yn y pen draw wedi dolennu mewn ffordd nad yw'n ddibwys iawn. A chan fod gan y dasg prod flaenoriaeth uwch na phawb arall ar yr un minions, dechreuodd ddefnyddio'r holl adnoddau prosesydd sydd ar gael. Yn y sefyllfa hon, ynysu, neu yn hytrach y cwota amser CPU, achubodd y dydd. Os rhoddir cwota i dasg, ni fydd y dasg yn defnyddio mwy. Felly, nid oedd swp a thasgau prod eraill a oedd yn rhedeg ar yr un peiriant yn sylwi ar unrhyw beth.

Yr ail broblem bosibl yw'r cynhwysydd yn cwympo. Ac yma mae polisïau ailgychwyn yn ein hachub, mae pawb yn eu hadnabod, mae Docker ei hun yn gwneud gwaith gwych. Mae gan bron pob tasg prod bolisi ailgychwyn bob amser. Weithiau rydym yn defnyddio on_failure ar gyfer tasgau swp neu ar gyfer dadfygio cynwysyddion prod.

Beth allwch chi ei wneud os nad yw minion cyfan ar gael?

Yn amlwg, rhedeg y cynhwysydd ar beiriant arall. Y rhan ddiddorol yma yw beth sy'n digwydd i'r cyfeiriad(au) IP a neilltuwyd i'r cynhwysydd.

Gallwn neilltuo'r un cyfeiriadau IP i gynwysyddion â'r peiriannau minion y mae'r cynwysyddion hyn yn rhedeg arnynt. Yna, pan fydd y cynhwysydd yn cael ei lansio ar beiriant arall, mae ei gyfeiriad IP yn newid, a rhaid i bob cleient ddeall bod y cynhwysydd wedi symud, ac yn awr mae angen iddynt fynd i gyfeiriad gwahanol, sy'n gofyn am wasanaeth Darganfod Gwasanaeth ar wahân.

Mae Darganfod Gwasanaeth yn gyfleus. Mae yna lawer o atebion ar y farchnad o wahanol raddau o oddefgarwch bai ar gyfer trefnu cofrestrfa gwasanaeth. Yn aml mae datrysiadau o'r fath yn gweithredu rhesymeg cydbwysedd llwyth, yn storio cyfluniad ychwanegol ar ffurf storfa KV, ac ati.
Fodd bynnag, hoffem osgoi’r angen i weithredu cofrestrfa ar wahân, oherwydd byddai hyn yn golygu cyflwyno system hollbwysig a ddefnyddir gan yr holl wasanaethau sy’n cynhyrchu. Mae hyn yn golygu bod hwn yn bwynt methiant posibl, ac mae angen i chi ddewis neu ddatblygu datrysiad goddefgar iawn, sy'n amlwg yn anodd iawn, yn cymryd llawer o amser ac yn ddrud.

Ac un anfantais fawr arall: er mwyn i'n hen seilwaith weithio gyda'r un newydd, byddai'n rhaid i ni ailysgrifennu'r holl dasgau i ddefnyddio rhyw fath o system Darganfod Gwasanaeth. Mae yna LLAWER o waith, ac mewn rhai mannau mae bron yn amhosibl o ran dyfeisiau lefel isel sy'n gweithio ar lefel cnewyllyn yr AO neu'n uniongyrchol gyda'r caledwedd. Gweithredu'r swyddogaeth hon gan ddefnyddio patrymau datrysiadau sefydledig, megis ochr-gar byddai'n golygu llwyth ychwanegol mewn rhai mannau, mewn eraill - cymhlethdod gweithredu a senarios methiant ychwanegol. Nid oeddem am gymhlethu pethau, felly fe wnaethom benderfynu gwneud y defnydd o Darganfod Gwasanaeth yn ddewisol.

Mewn un cwmwl, mae'r IP yn dilyn y cynhwysydd, h.y. mae gan bob tasg ei chyfeiriad IP ei hun. Mae'r cyfeiriad hwn yn “statig”: mae'n cael ei neilltuo i bob achos pan fydd y gwasanaeth yn cael ei anfon i'r cwmwl gyntaf. Os oedd gan wasanaeth nifer wahanol o achosion yn ystod ei oes, yna yn y diwedd bydd yn cael ei neilltuo cymaint o gyfeiriadau IP ag a oedd yn yr achosion mwyaf posibl.

Yn dilyn hynny, nid yw'r cyfeiriadau hyn yn newid: cânt eu neilltuo unwaith ac maent yn parhau i fodoli trwy gydol oes y gwasanaeth wrth gynhyrchu. Mae cyfeiriadau IP yn dilyn cynwysyddion ar draws y rhwydwaith. Os caiff y cynhwysydd ei drosglwyddo i finion arall, yna bydd y cyfeiriad yn ei ddilyn.

Felly, anaml iawn y mae mapio enw gwasanaeth i'w restr o gyfeiriadau IP yn newid. Os edrychwch eto ar enwau'r achosion gwasanaeth y soniasom amdanynt ar ddechrau'r erthygl (1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod, …), byddwn yn sylwi eu bod yn debyg i'r FQDNs a ddefnyddir yn DNS. Mae hynny'n iawn, i fapio enwau achosion gwasanaeth i'w cyfeiriadau IP, rydym yn defnyddio'r protocol DNS. Ar ben hynny, mae'r DNS hwn yn dychwelyd holl gyfeiriadau IP neilltuedig yr holl gynwysyddion - yn rhedeg ac wedi'u stopio (gadewch i ni ddweud bod tri atgynhyrchiad yn cael eu defnyddio, ac mae gennym ni bum cyfeiriad wedi'u cadw yno - bydd y pump yn cael eu dychwelyd). Bydd cleientiaid, ar ôl derbyn y wybodaeth hon, yn ceisio sefydlu cysylltiad â phob un o'r pum atgynhyrchiad - a thrwy hynny bennu'r rhai sy'n gweithio. Mae'r opsiwn hwn ar gyfer pennu argaeledd yn llawer mwy dibynadwy; nid yw'n cynnwys DNS na Darganfod Gwasanaeth, sy'n golygu nad oes unrhyw broblemau anodd i'w datrys wrth sicrhau perthnasedd gwybodaeth a goddefgarwch diffygion y systemau hyn. Ar ben hynny, mewn gwasanaethau hanfodol y mae gweithrediad y porth cyfan yn dibynnu arnynt, ni allwn ddefnyddio DNS o gwbl, ond dim ond nodi cyfeiriadau IP yn y ffurfweddiad.

Gall gweithredu trosglwyddiad IP o'r fath y tu ôl i gynwysyddion fod yn ddibwys - a byddwn yn edrych ar sut mae'n gweithio gyda'r enghraifft ganlynol:

Gadewch i ni ddweud bod y meistr un cwmwl yn rhoi'r gorchymyn i minion M1 redeg 1.ok-web.group1.web.front.prod gyda chyfeiriad 1.1.1.1. Yn gweithio ar minion GENI, sy'n hysbysebu'r cyfeiriad hwn i weinyddion arbennig adlewyrchydd llwybr. Mae gan yr olaf sesiwn BGP gyda chaledwedd y rhwydwaith, lle mae llwybr cyfeiriad 1.1.1.1 ar M1 yn cael ei gyfieithu. Mae M1 yn llwybrau pecynnau y tu mewn i'r cynhwysydd gan ddefnyddio Linux. Mae yna dri gweinydd adlewyrchydd llwybr, gan fod hon yn rhan hanfodol iawn o'r seilwaith un cwmwl - hebddynt, ni fydd y rhwydwaith mewn un cwmwl yn gweithio. Rydyn ni'n eu gosod mewn gwahanol raciau, os yn bosibl wedi'u lleoli mewn gwahanol ystafelloedd yn y ganolfan ddata, i leihau'r tebygolrwydd y bydd y tri yn methu ar yr un pryd.

Gadewch i ni dybio yn awr fod y cysylltiad rhwng y meistr un-cwmwl a'r minion M1 yn cael ei golli. Bydd y meistr un cwmwl nawr yn gweithredu ar y rhagdybiaeth bod M1 wedi methu'n llwyr. Hynny yw, bydd yn rhoi'r gorchymyn i'r M2 minion ei lansio web.group1.web.front.prod gyda'r un cyfeiriad 1.1.1.1. Nawr mae gennym ddau lwybr gwrthdaro ar y rhwydwaith ar gyfer 1.1.1.1: ar M1 ac ar M2. Er mwyn datrys gwrthdaro o'r fath, rydym yn defnyddio'r Gwahaniaethwr Aml Allanfa, a nodir yng nghyhoeddiad BGP. Dyma rif sy'n dangos pwysau'r llwybr a hysbysebir. Ymhlith y llwybrau sy'n gwrthdaro, bydd y llwybr gyda'r gwerth MED is yn cael ei ddewis. Mae'r meistr un-cwmwl yn cefnogi MED fel rhan annatod o gyfeiriadau IP cynhwysydd. Am y tro cyntaf, ysgrifennir y cyfeiriad gyda MED digon mawr = 1. Yn y sefyllfa o drosglwyddo cynhwysydd brys o'r fath, mae'r meistr yn lleihau'r MED, a bydd M000 eisoes yn derbyn y gorchymyn i hysbysebu'r cyfeiriad 000 gyda MED = 2.Bydd yr enghraifft sy'n rhedeg ar M1.1.1.1 yn aros yn yr achos hwn nid oes unrhyw gysylltiad, ac nid yw ei dynged bellach o ddiddordeb i ni hyd nes y bydd y cysylltiad â'r meistr yn cael ei adfer, pan fydd yn cael ei atal fel hen gymryd.

damweiniau

Mae holl systemau rheoli canolfannau data bob amser yn ymdrin â mân fethiannau yn dderbyniol. Gorlif cynhwysydd yw'r norm bron ym mhobman.

Edrychwn ar sut yr ydym yn ymdrin ag argyfwng, megis methiant pŵer mewn un neu fwy o ystafelloedd canolfan ddata.

Beth mae damwain yn ei olygu i system rheoli canolfan ddata? Yn gyntaf oll, mae hwn yn fethiant un-amser enfawr o lawer o beiriannau, ac mae angen i'r system reoli fudo llawer o gynwysyddion ar yr un pryd. Ond os yw'r trychineb ar raddfa fawr iawn, yna gall ddigwydd na ellir ail-ddyrannu'r holl dasgau i minions eraill, oherwydd bod gallu adnoddau'r ganolfan ddata yn disgyn o dan 100% o'r llwyth.

Yn aml mae methiant yr haen reoli yn cyd-fynd â damweiniau. Gall hyn ddigwydd oherwydd methiant ei offer, ond yn amlach oherwydd y ffaith nad yw damweiniau'n cael eu profi, ac mae'r haen reoli ei hun yn disgyn oherwydd y llwyth cynyddol.

Beth allwch chi ei wneud am hyn i gyd?

Mae mudo torfol yn golygu bod nifer fawr o weithgareddau, mudo, a defnydd yn digwydd yn y seilwaith. Efallai y bydd pob un o'r mudo yn cymryd peth amser i gyflwyno a dadbacio delweddau cynhwysydd i minions, lansio a chychwyn cynwysyddion, ac ati. Felly, mae'n ddymunol lansio tasgau pwysicach cyn rhai llai pwysig.

Edrychwn eto ar hierarchaeth y gwasanaethau yr ydym yn gyfarwydd â hwy a cheisio penderfynu pa dasgau yr ydym am eu rhedeg gyntaf.

Wrth gwrs, dyma'r prosesau sy'n ymwneud yn uniongyrchol â phrosesu ceisiadau defnyddwyr, h.y. prod. Rydym yn nodi hyn gyda blaenoriaeth lleoliad — rhif y gellir ei neilltuo i'r ciw. Os oes gan giw flaenoriaeth uwch, ei wasanaethau sy'n cael eu rhoi yn gyntaf.

Ar prod rydym yn pennu blaenoriaethau uwch, 0; ar swp - ychydig yn is, 100; ar segur - hyd yn oed yn is, 200. Mae blaenoriaethau'n cael eu cymhwyso'n hierarchaidd. Bydd gan bob tasg is yn yr hierarchaeth flaenoriaeth gyfatebol. Os ydym am i caches y tu mewn i'r prod gael eu lansio cyn frontends, yna rydym yn aseinio blaenoriaethau i cache = 0 ac i subqueues blaen = 1. Os, er enghraifft, rydym am i'r prif borth gael ei lansio o'r blaenau yn gyntaf, a'r blaen cerddoriaeth yn unig yna, yna gallwn neilltuo blaenoriaeth is i'r olaf - 10 .

Y broblem nesaf yw diffyg adnoddau. Felly, methodd llawer iawn o offer, neuaddau cyfan y ganolfan ddata, ac fe wnaethom ail-lansio cymaint o wasanaethau nad oes bellach ddigon o adnoddau i bawb. Mae angen i chi benderfynu pa dasgau i'w haberthu er mwyn cadw'r prif wasanaethau hanfodol i redeg.

Yn wahanol i flaenoriaeth lleoli, ni allwn aberthu pob tasg swp yn ddiwahân; mae rhai ohonynt yn bwysig ar gyfer gweithrediad y porth. Felly, rydym wedi amlygu ar wahân blaenoriaeth preemption tasgau. Pan gaiff ei gosod, gall tasg â blaenoriaeth uwch ragdybio, h.y. rhoi’r gorau iddi, tasg â blaenoriaeth is os nad oes mwy o finau rhydd. Yn yr achos hwn, mae’n debygol y bydd tasg â blaenoriaeth isel yn aros yn ei lle, h.y. ni fydd minion addas ar ei chyfer â digon o adnoddau am ddim mwyach.

Yn ein hierarchaeth, mae'n syml iawn nodi blaenoriaeth preemption fel bod tasgau prod a swp yn preempt neu'n atal tasgau segur, ond nid ei gilydd, trwy nodi blaenoriaeth ar gyfer segur sy'n hafal i 200. Yn union fel yn achos blaenoriaeth lleoli, rydym yn yn gallu defnyddio ein hierarchaeth i ddisgrifio rheolau mwy cymhleth. Er enghraifft, gadewch i ni nodi ein bod yn aberthu'r swyddogaeth gerddoriaeth os nad oes gennym ddigon o adnoddau ar gyfer y prif borth gwe, gan osod y flaenoriaeth ar gyfer y nodau cyfatebol yn is: 10.

Damweiniau DC cyfan

Pam y gallai'r ganolfan ddata gyfan fethu? Elfen. Roedd yn post da effeithiodd y corwynt ar waith y ganolfan ddata. Gellir ystyried yr elfennau yn bobl ddigartref a oedd unwaith yn llosgi'r opteg yn y manifold, a chollodd y ganolfan ddata gysylltiad â gwefannau eraill yn llwyr. Gall achos methiant hefyd fod yn ffactor dynol: bydd y gweithredwr yn cyhoeddi gorchymyn o'r fath y bydd y ganolfan ddata gyfan yn disgyn. Gallai hyn ddigwydd oherwydd byg mawr. Yn gyffredinol, nid yw cwymp canolfannau data yn anghyffredin. Mae hyn yn digwydd i ni unwaith bob ychydig fisoedd.

A dyma beth rydyn ni'n ei wneud i atal unrhyw un rhag trydar #yn fyw.

Y strategaeth gyntaf yw unigedd. Mae pob enghraifft un cwmwl yn ynysig a gallant reoli peiriannau mewn un ganolfan ddata yn unig. Hynny yw, mae colli cwmwl oherwydd bygiau neu orchmynion gweithredwr anghywir yn golygu colli un ganolfan ddata yn unig. Rydym yn barod ar gyfer hyn: mae gennym bolisi dileu swyddi lle mae copïau o'r cais a'r data wedi'u lleoli ym mhob canolfan ddata. Rydym yn defnyddio cronfeydd data sy'n goddef diffygion ac yn profi methiannau o bryd i'w gilydd.
Ers heddiw mae gennym bedair canolfan ddata, mae hynny'n golygu pedair achos ar wahân, cwbl ynysig o un cwmwl.

Mae'r dull hwn nid yn unig yn amddiffyn rhag methiant corfforol, ond gall hefyd amddiffyn rhag gwall gweithredwr.

Beth arall y gellir ei wneud gyda'r ffactor dynol? Pan fydd gweithredwr yn rhoi gorchymyn rhyfedd neu a allai fod yn beryglus i'r cwmwl, efallai y gofynnir iddo yn sydyn ddatrys problem fach i weld pa mor dda yr oedd yn meddwl. Er enghraifft, os yw hyn yn rhyw fath o stop torfol o lawer o atgynyrchiadau neu ddim ond gorchymyn rhyfedd - lleihau nifer y copïau neu newid enw'r ddelwedd, ac nid dim ond rhif y fersiwn yn y maniffest newydd.

Canlyniadau

Nodweddion unigryw un cwmwl:

• Cynllun enwi hierarchaidd a gweledol ar gyfer gwasanaethau a chynwysyddion, sy'n eich galluogi i ddarganfod yn gyflym iawn beth yw'r dasg, beth mae'n berthnasol iddo a sut mae'n gweithio a phwy sy'n gyfrifol amdani.
• Rydym yn gwneud cais ein techneg o gyfuno cynnyrch a swp-tasgau ar minions i wella effeithlonrwydd rhannu peiriannau. Yn lle cpuset rydym yn defnyddio cwotâu CPU, cyfranddaliadau, polisïau amserlennu CPU a Linux QoS.
• Nid oedd yn bosibl ynysu cynwysyddion sy'n rhedeg ar yr un peiriant yn llwyr, ond mae eu dylanwad cilyddol yn parhau o fewn 20%.
• Mae trefnu gwasanaethau yn hierarchaeth yn helpu gyda defnyddio adferiad awtomatig ar ôl trychineb blaenoriaethau lleoli a rhagbrynu.

FAQ

Pam na wnaethom ni gymryd ateb parod?

• Mae gwahanol ddosbarthiadau o ynysu tasgau yn gofyn am resymeg wahanol pan roddir ar minions. Os gellir gosod tasgau prod trwy gadw adnoddau yn unig, yna rhaid gosod tasgau swp a segur, gan olrhain y defnydd gwirioneddol o adnoddau ar beiriannau minion.
• Yr angen i ystyried yr adnoddau a ddefnyddir gan dasgau, megis:
  • lled band rhwydwaith;
  • mathau a “gwerthydau” o ddisgiau.
• Yr angen i nodi blaenoriaethau gwasanaethau yn ystod ymateb brys, hawliau a chwotâu gorchmynion ar gyfer adnoddau, sy'n cael eu datrys gan ddefnyddio ciwiau hierarchaidd mewn un cwmwl.
• Yr angen i gael enwau dynol ar gynwysyddion i leihau amser ymateb i ddamweiniau a digwyddiadau
• Amhosibilrwydd gweithrediad eang un-amser o Ddarganfod Gwasanaeth; yr angen i gydfodoli am amser hir gyda thasgau a gynhelir ar westeion caledwedd - rhywbeth sy'n cael ei ddatrys gan gyfeiriadau IP “statig” yn dilyn cynwysyddion, ac, o ganlyniad, yr angen am integreiddio unigryw gyda seilwaith rhwydwaith mawr.

Byddai’r holl swyddogaethau hyn yn gofyn am addasiadau sylweddol i’r atebion presennol i weddu i ni, ac, ar ôl asesu maint y gwaith, sylweddolasom y gallem ddatblygu ein datrysiad ein hunain gyda thua’r un costau llafur. Ond bydd eich datrysiad yn llawer haws ei weithredu a'i ddatblygu - nid yw'n cynnwys tyniadau diangen sy'n cefnogi ymarferoldeb nad oes ei angen arnom.

I'r rhai a ddarllenodd y llinellau olaf, diolch am eich amynedd a'ch sylw!

Ffynhonnell: hab.com