Mae gan ganolfannau data modern gannoedd o ddyfeisiau gweithredol a gwmpesir gan wahanol fathau o fonitro. Ond bydd hyd yn oed peiriannydd perffaith gyda monitro perffaith mewn llaw yn gallu ymateb yn iawn i fethiant rhwydwaith mewn ychydig funudau yn unig. Mewn adroddiad yng nghynhadledd Next Hop 2020, cyflwynais fethodoleg dylunio rhwydwaith canolfan ddata sydd â nodwedd unigryw - mae'r ganolfan ddata yn gwella ei hun mewn milieiliadau. Yn fwy manwl gywir, mae'r peiriannydd yn datrys y broblem yn dawel, tra nad yw'r gwasanaethau'n sylwi arno.
I lawer o beirianwyr rhwydwaith, mae rhwydwaith y ganolfan ddata yn dechrau, wrth gwrs, gyda ToR, gyda switsh yn y rac. Fel arfer mae gan ToR ddau fath o ddolen. Mae'r rhai bach yn mynd at y gweinyddion, eraill - mae N gwaith mwy ohonyn nhw - yn mynd tuag at y pigau lefel gyntaf, hynny yw, at ei uplinks. Mae uplinks fel arfer yn cael eu hystyried yn gyfartal, ac mae traffig rhwng uplinks yn cael ei gydbwyso yn seiliedig ar yr hash 5-tuple, sy'n cynnwys proto, src_ip, dst_ip, src_port, dst_port. Does dim syrpreis yma.
Nesaf, sut olwg sydd ar bensaernïaeth yr awyrennau? Nid yw pigau'r lefel gyntaf wedi'u cysylltu â'i gilydd, ond maent wedi'u cysylltu â superspins. Bydd y llythyren X yn gyfrifol am superspins, mae bron fel croesgysylltu.
Ac mae'n amlwg, ar y llaw arall, bod tori wedi'u cysylltu â holl asgwrn cefn y lefel gyntaf. Beth sy'n bwysig yn y llun hwn? Os oes gennym ryngweithio y tu mewn i'r rac, yna mae'r rhyngweithio, wrth gwrs, yn mynd trwy ToR. Os yw'r rhyngweithiad yn mynd y tu mewn i'r modiwl, yna mae'r rhyngweithiad yn mynd trwy asgwrn cefn y lefel gyntaf. Os yw'r rhyngweithiad yn rhyngfoddol - fel yma, ToR 1 a ToR 2 - yna bydd y rhyngweithiad yn mynd trwy asgwrn cefn y lefel gyntaf a'r ail lefel.
Yn ddamcaniaethol, mae pensaernïaeth o'r fath yn hawdd ei graddio. Os oes gennym gapasiti porthladd, cronfa wrth gefn o le yn y ganolfan ddata a ffibr wedi'i osod ymlaen llaw, yna gellir cynyddu nifer yr awyrennau bob amser, a thrwy hynny gynyddu gallu cyffredinol y system. Ar bapur, mae hyn yn hawdd iawn i'w wneud. Byddai felly mewn bywyd go iawn. Ond nid yw stori heddiw yn ymwneud â hynny.
Rwyf am i’r casgliadau cywir gael eu llunio. Mae gennym lawer o lwybrau y tu mewn i'r ganolfan ddata. Maent yn annibynnol yn amodol. Mae un ffordd y tu mewn i'r ganolfan ddata yn bosibl y tu mewn i ToR yn unig. Y tu mewn i'r modiwl, mae gennym yr un nifer o lwybrau â nifer yr awyrennau. Mae nifer y llwybrau rhwng modiwlau yn hafal i gynnyrch nifer yr awyrennau a nifer yr uwchdroelli ym mhob awyren. Er mwyn ei gwneud yn gliriach, i deimlo'r raddfa, byddaf yn rhoi'r niferoedd sy'n ddilys ar gyfer un o ganolfannau data Yandex.
Mae wyth awyren, mae gan bob awyren 32 superspis. O ganlyniad, mae'n ymddangos bod wyth llwybr y tu mewn i'r modiwl, a chyda rhyngweithio rhwng modiwlau mae 256 ohonynt eisoes.
Hynny yw, os ydym yn datblygu Llyfr Coginio, yn ceisio dysgu sut i adeiladu canolfannau data goddefgar sy'n gwella eu hunain, yna pensaernïaeth planar yw'r dewis cywir. Mae'n caniatáu ichi ddatrys y broblem graddio, ac yn ddamcaniaethol mae'n hawdd. Mae yna lawer o lwybrau annibynnol. Erys y cwestiwn: sut mae pensaernïaeth o'r fath yn goroesi methiannau? Mae yna amrywiol ddamweiniau. A byddwn yn trafod hyn yn awr.
Gadewch i un o'n superspins fynd yn sâl. Yma dychwelais at bensaernïaeth dwy awyren. Byddwn yn cadw gyda nhw fel enghraifft oherwydd bydd yn syml yn haws gweld beth sy'n digwydd yma gyda llai o rannau symudol. Gadewch i X11 fynd yn sâl. Sut bydd hyn yn effeithio ar wasanaethau sy'n byw y tu mewn i ganolfannau data? Mae llawer yn dibynnu ar sut olwg sydd ar y methiant mewn gwirionedd.
Os yw'r methiant yn dda, caiff ei ddal ar lefel awtomeiddio yr un BFD, mae awtomeiddio yn hapus yn rhoi cymalau problem ac yn ynysu'r broblem, yna mae popeth yn iawn. Mae gennym lawer o lwybrau, mae traffig yn cael ei ailgyfeirio ar unwaith i lwybrau amgen, ac ni fydd y gwasanaethau'n sylwi ar unrhyw beth. Mae hon yn senario dda.
Senario gwael yw os oes gennym golledion cyson, ac nid yw'r awtomeiddio yn sylwi ar y broblem. Er mwyn deall sut mae hyn yn effeithio ar y cais, bydd yn rhaid i ni dreulio ychydig o amser yn trafod sut mae'r protocol TCP yn gweithio.
Rwy'n gobeithio na fyddaf yn synnu unrhyw un gyda'r wybodaeth hon: Protocol ysgwyd llaw yw TCP. Hynny yw, yn yr achos symlaf, mae'r anfonwr yn anfon dau becyn, ac yn derbyn ad gronnus arnynt: "Cefais ddau becyn."
Ar ôl hynny, bydd yn anfon dau becyn arall, a bydd y sefyllfa'n ailadrodd. Ymddiheuraf ymlaen llaw am rywfaint o symleiddio. Mae'r senario hwn yn gywir os yw'r ffenestr (nifer y pecynnau yn hedfan) yn ddau. Wrth gwrs, nid yw hyn o reidrwydd yn wir yn gyffredinol. Ond nid yw maint y ffenestr yn effeithio ar y cyd-destun anfon pecynnau.
Beth fydd yn digwydd os byddwn yn colli pecyn 3? Yn yr achos hwn, bydd y derbynnydd yn derbyn pecynnau 1, 2 a 4. A bydd yn hysbysu'r anfonwr yn benodol gan ddefnyddio'r opsiwn SACK: "Rydych chi'n gwybod, daeth tri, ond collwyd y canol." Mae'n dweud "Ack 2, SACK 4".
Mae'r anfonwr ar hyn o bryd yn ailadrodd yn union y pecyn a gollwyd heb unrhyw broblemau.
Ond os collir y pecyn olaf yn y ffenestr, bydd y sefyllfa'n edrych yn wahanol iawn.
Mae'r derbynnydd yn derbyn y tri phecyn cyntaf ac yn gyntaf oll yn dechrau aros. Diolch i rai optimizations yn y pentwr TCP cnewyllyn Linux, bydd yn aros am becyn pâr, oni bai bod arwydd penodol yn y fflagiau mai hwn yw'r pecyn olaf neu rywbeth felly. Bydd yn aros nes i'r terfyn amser Oedi ACK ddod i ben ac yna'n anfon cydnabyddiaeth am y tri phecyn cyntaf. Ond nawr bydd yr anfonwr yn aros. Nid yw'n gwybod a yw'r pedwerydd pecyn wedi'i golli neu ar fin cyrraedd. Ac er mwyn peidio â gorlwytho'r rhwydwaith, bydd yn ceisio aros am yr arwydd clir bod y pecyn wedi'i golli, neu ddiwedd y terfyn amser RTO.
Beth yw terfyn amser RTO? Dyma'r uchafswm o'r RTT a gyfrifwyd gan y stac TCP a pheth cysonyn. Beth yw hyn yn gyson, byddwn yn awr yn trafod.
Ond mae'n bwysig os ydym yn anlwcus eto a bod y pedwerydd pecyn yn cael ei golli eto, yna mae'r RTO yn dyblu. Hynny yw, mae pob ymgais aflwyddiannus yn ddyblu'r terfyn amser.
Nawr gadewch i ni weld beth mae'r sylfaen hon yn hafal iddo. Yn ddiofyn, yr isafswm RTO yw 200ms. Dyma'r RTO lleiaf ar gyfer pecynnau data. Ar gyfer pecynnau SYN, mae'n wahanol, 1 eiliad. Fel y gallwch weld, bydd hyd yn oed yr ymgais gyntaf i ail-anfon pecynnau yn cymryd 100 gwaith yn hirach na RTT y tu mewn i'r ganolfan ddata.
Nawr yn ôl at ein senario. Beth sy'n digwydd gyda'r gwasanaeth? Mae'r gwasanaeth yn dechrau colli pecynnau. Gadewch i'r gwasanaeth fod yn ffodus i ddechrau a cholli rhywbeth yng nghanol y ffenestr, yna mae'n derbyn SACK, yn ail-anfon y pecynnau coll.
Ond os bydd lwc ddrwg yn digwydd eto, yna mae gennym ni RTO. Beth sy'n bwysig yma? Oes, mae gennym ni lawer o lwybrau yn y rhwydwaith. Ond bydd traffig TCP un cysylltiad TCP penodol yn parhau i fynd drwy'r un pentwr toredig. Nid yw colli pecyn, ar yr amod nad yw ein hud X11 yn mynd allan ar ei ben ei hun, yn arwain at draffig yn llifo i ardaloedd nad ydynt yn broblemus. Rydym yn ceisio dosbarthu pecyn drwy'r un pentwr toredig. Mae hyn yn arwain at fethiant rhaeadru: mae canolfan ddata yn set o gymwysiadau rhyngweithiol, ac mae rhai o gysylltiadau TCP yr holl gymwysiadau hyn yn dechrau diraddio - oherwydd bod y superspin yn effeithio ar bob cais sydd y tu mewn i'r DC. Fel yn y dywediad: os nad ydych chi'n pedoli ceffyl, mae'r ceffyl yn llipa; the horse limped - ni thraddodwyd yr adroddiad; ni thraddodwyd y neges - collasant y rhyfel. Dim ond yma mae'r cyfrif yn mynd am eiliadau o'r eiliad y mae'r broblem yn digwydd i'r cam diraddio y mae gwasanaethau'n dechrau ei deimlo. Mae hyn yn golygu efallai na fydd defnyddwyr yn derbyn rhywbeth yn rhywle.
Mae dau ateb clasurol sy'n ategu ei gilydd. Y cyntaf yw gwasanaethau sy'n ceisio gosod gwellt a datrys y broblem fel hyn: “Gadewch i ni newid rhywbeth yn y stac TCP. A gadewch i ni wneud seibiannau lefel cais neu sesiynau TCP hirhoedlog gyda gwiriadau iechyd mewnol. Y broblem yw bod atebion o'r fath: a) ddim yn graddio o gwbl; b) wedi'i brofi'n wael iawn. Hynny yw, hyd yn oed os yw'r gwasanaeth yn ffurfweddu'r stac TCP yn ddamweiniol fel ei fod yn dod yn well, yn gyntaf, mae hyn yn annhebygol o fod yn berthnasol i bob cais a phob canolfan ddata, ac yn ail, yn fwyaf tebygol, ni fydd yn deall beth a wnaed yn gywir a beth ddim. Hynny yw, mae'n gweithio, ond mae'n gweithio'n wael ac nid yw'n graddio. Ac os oes problem rhwydwaith, pwy sydd ar fai? Wrth gwrs NOC. Beth mae NOC yn ei wneud?
Mae llawer o wasanaethau yn credu bod gwaith yn mynd rhywbeth fel hyn yn NOC. Ond i fod yn onest, nid yn unig.
Mae NOC yn y cynllun clasurol yn ymwneud â datblygu llawer o fonitro. Mae'r rhain yn ddau fonitro blwch du a monitro blwch gwyn. Ynglŷn â'r enghraifft o focs du-monitro pigau Alexander Klimenko ar y gorffennol Next Hop. Gyda llaw, mae'r monitro hwn yn gweithio. Ond bydd hyd yn oed monitro perffaith yn cael oedi. Fel arfer mae'n sawl munud. Ar ôl iddo weithio, mae angen amser ar y peirianwyr sydd ar ddyletswydd i wirio ei weithrediad ddwywaith, i leoleiddio'r broblem, ac yna i ddiffodd yr ardal broblem. Hynny yw, yn yr achos gorau, mae trin y broblem yn cymryd 5 munud, ar y gwaethaf 20 munud, os nad yw'n amlwg ar unwaith lle mae'r colledion yn digwydd. Mae'n amlwg y bydd yr holl amser hwn - 5 neu 20 munud - yn parhau i frifo ein gwasanaethau, ac mae'n debyg nad yw hynny'n dda.
Beth hoffech chi ei dderbyn? Mae gennym ni gymaint o lwybrau. Ac mae problemau'n codi'n union oherwydd bod llif TCP sy'n anlwcus yn parhau i ddefnyddio'r un llwybr. Mae angen rhywbeth arnom a fydd yn caniatáu inni ddefnyddio llwybrau lluosog o fewn un cysylltiad TCP. Mae’n ymddangos bod gennym ni ateb. Mae TCP, a elwir felly - multipath TCP, hynny yw, TCP ar gyfer llawer o lwybrau. Yn wir, fe'i datblygwyd ar gyfer tasg hollol wahanol - ar gyfer ffonau smart sydd â nifer o ddyfeisiau rhwydwaith. Er mwyn gwneud y mwyaf o'r trosglwyddiad neu wneud y modd cynradd / wrth gefn, datblygwyd mecanwaith sy'n creu nifer o edafedd (sesiynau) yn dryloyw ar gyfer y cais ac sy'n caniatáu ichi newid rhyngddynt rhag ofn y bydd methiant. Neu, fel y dywedais, gwneud y mwyaf o'r lled band.
Ond mae naws yma. Er mwyn deall beth ydyw, bydd yn rhaid inni edrych ar sut y caiff ffrydiau eu sefydlu.
Mae edafedd yn cael eu gosod yn ddilyniannol. Gosodir y ffrwd gyntaf yn gyntaf. Yna caiff llifau dilynol eu gosod gan ddefnyddio'r cwci y cytunwyd arno eisoes o fewn yr edefyn hwnnw. A dyma'r broblem.
Y broblem yw, os na fydd yr edefyn cyntaf yn gosod, ni fydd yr ail a'r trydydd edafedd byth yn dod i fyny. Hynny yw, nid yw multipath TCP yn datrys colli'r pecyn SYN yn y ffrwd gyntaf. Ac os yw'r SYN yn cael ei golli, mae TCP aml-lwybr yn dod yn TCP arferol. Felly, mewn amgylchedd canolfan ddata, ni fydd yn ein helpu i ddatrys problem colledion yn y ffatri a dysgu sut i ddefnyddio llwybrau lluosog rhag ofn y bydd methiant.
Beth all ein helpu ni? Mae rhai ohonoch eisoes wedi dyfalu o'r enw mai'r maes pwysig yn ein stori bellach fydd maes pennawd label llif IPv6. Yn wir, mae hwn yn faes sy'n ymddangos yn v6, nid yw yn v4, mae'n cymryd 20 did, a bu dadlau am ei ddefnydd ers amser maith. Mae hyn yn ddiddorol iawn - roedd anghydfodau, gosodwyd rhywbeth o fewn fframwaith y Clwb Rygbi, ac ar yr un pryd, ymddangosodd gweithrediad yn y cnewyllyn Linux na chafodd ei ddogfennu erioed yn unrhyw le.
Awgrymaf ichi ymuno â mi ar ychydig o ymchwiliad. Gadewch i ni edrych ar yr hyn sydd wedi bod yn digwydd yn y cnewyllyn Linux dros yr ychydig flynyddoedd diwethaf.
flwyddyn 2014. Mae peiriannydd o gwmni mawr ag enw da yn ychwanegu at weithrediad y cnewyllyn Linux ddibyniaeth gwerth y label llif ar stwnsh y soced. Beth maen nhw'n ceisio ei drwsio yma? Mae hyn yn ymwneud â Chlwb Rygbi 6438 a drafododd y mater canlynol. Y tu mewn i'r ganolfan ddata, mae IPv4 yn aml wedi'i grynhoi mewn pecynnau IPv6, oherwydd mae'r ffatri ei hun yn IPv6, ond mae'n rhaid dosbarthu IPv4 rywsut. Am gyfnod hir bu problemau gyda switshis na allent edrych o dan ddau bennawd IP i gyrraedd TCP neu UDP a dod o hyd i src_ports, dst_ports yno. Mae'n troi allan bod y hash, os edrychwch ar y ddau bennawd IP cyntaf, drodd allan i fod bron yn sefydlog. Er mwyn osgoi hyn, fel bod cydbwyso'r traffig wedi'i amgáu hwn yn gweithio'n gywir, cynigiwyd ychwanegu hash o'r pecyn wedi'i amgáu 5-tuple i werth y maes label llif. Gwnaed tua'r un peth ar gyfer cynlluniau amgáu eraill, ar gyfer CDU, ar gyfer GRE, yn yr olaf defnyddiwyd maes Allwedd GRE. Un ffordd neu'r llall, mae'r nodau yma'n glir. Ac o leiaf ar yr adeg honno roeddent yn ddefnyddiol.
Yn 2015, daw clwt newydd gan yr un peiriannydd uchel ei barch. Mae'n ddiddorol iawn. Mae'n dweud y canlynol - byddwn yn rhoi'r hash ar hap rhag ofn y bydd digwyddiad llwybro negyddol. Beth yw digwyddiad llwybro negyddol? Dyma'r RTO a drafodwyd gennym yn gynharach, hynny yw, mae colli cynffon y ffenestr yn ddigwyddiad sy'n wirioneddol negyddol. Yn wir, mae'n gymharol anodd dyfalu beth ydyw.
2016, cwmni arall uchel ei barch, hefyd yn fawr. Mae'n dosrannu'r baglau olaf ac yn ei wneud fel bod yr hash a wnaethom yn flaenorol ar hap bellach yn cael ei newid ar bob ailddarllediad SYN ac ar ôl pob terfyn amser RTO. Ac yn y llythyr hwn, am y tro cyntaf a'r tro olaf, mae'r nod eithaf yn swnio - i wneud yn siŵr bod traffig yn achos colli neu orlwytho sianeli â'r posibilrwydd o ailgyfeirio meddal, gan ddefnyddio llwybrau lluosog. Wrth gwrs, ar ôl hynny roedd llawer o gyhoeddiadau, gallwch ddod o hyd iddynt yn hawdd.
Er na, ni allwch, oherwydd ni fu un cyhoeddiad ar y pwnc hwn. Ond rydyn ni'n gwybod!
Ac os nad ydych yn deall yn iawn yr hyn a wnaethpwyd, fe ddywedaf wrthych yn awr.
Beth sydd wedi'i wneud, pa ymarferoldeb sydd wedi'i ychwanegu at y cnewyllyn Linux? txhash yn newid i werth ar hap ar ôl pob digwyddiad RTO. Dyma'r un canlyniad llwybro negyddol. Mae'r hash yn dibynnu ar y txhash hwn ac mae'r label llif yn dibynnu ar yr hash skb. Mae rhai cyfrifiadau ar y swyddogaethau yma, ni ellir gosod yr holl fanylion ar un sleid. Os oes unrhyw un yn chwilfrydig, gallwch fynd drwy'r cod cnewyllyn a gwirio.
Beth sy'n bwysig yma? Mae gwerth y maes label llif yn newid i rif ar hap ar ôl pob RTO. Sut mae hyn yn effeithio ar ein ffrwd TCP anlwcus?
Yn achos SACH, nid oes dim wedi newid oherwydd ein bod yn ceisio ail-anfon pecyn coll hysbys. Hyd yn hyn mor dda.
Ond yn achos RTO, ar yr amod ein bod wedi ychwanegu label llif at y swyddogaeth hash ar ToR, gall traffig gymryd llwybr gwahanol. A pho fwyaf o awyrennau, y mwyaf tebygol yw hi o ddod o hyd i lwybr nad yw damwain yn effeithio arno ar ddyfais benodol.
Erys un broblem - RTO. Mae llwybr arall, wrth gwrs, i'w gael, ond treulir llawer o amser arno. Mae 200ms yn llawer. Yr ail yw gwylltineb yn gyffredinol. Yn gynharach, siaradais am seibiannau sy'n ffurfweddu gwasanaethau. Felly, mae eiliad yn amser terfyn sydd fel arfer yn sefydlu gwasanaeth ar lefel y cais, ac yn hyn o beth bydd y gwasanaeth hyd yn oed yn gymharol gywir. Ar ben hynny, rwy'n ailadrodd, mae'r RTT go iawn y tu mewn i ganolfan ddata fodern tua 1 milieiliad.
Beth ellir ei wneud ynglŷn â seibiannau RTO? Gellir ffurfweddu'r terfyn amser sy'n gyfrifol am RTO rhag ofn colli pecynnau data yn gymharol hawdd o ofod defnyddwyr: mae cyfleustodau IP, ac mae un o'i baramedrau yn cynnwys yr un rto_min. O ystyried, wrth gwrs, mae angen i chi droi RTO nid yn fyd-eang, ond ar gyfer rhagddodiaid a roddir, mae mecanwaith o'r fath yn edrych yn eithaf gweithio.
Gwir, gyda SYN_RTO mae popeth ychydig yn waeth. Mae'n cael ei hoelio i lawr yn naturiol. Mae'r gwerth yn sefydlog yn y craidd - 1 eiliad, a dyna ni. Ni allwch ei gyrraedd o ofod defnyddiwr. Dim ond un ffordd sydd.
eBPF yn dod i'r adwy. Yn syml, mae'r rhain yn rhaglenni bach C. Gellir eu gosod mewn bachau mewn gwahanol fannau wrth weithredu'r pentwr cnewyllyn a'r pentwr TCP, y gallwch chi newid nifer fawr iawn o osodiadau gyda nhw. Yn gyffredinol, mae eBPF yn duedd hirdymor. Yn lle llifio dwsinau o baramedrau sysctl newydd ac ehangu'r cyfleustodau IP, mae'r symudiad i gyfeiriad eBPF ac yn ehangu ei ymarferoldeb. Gydag eBPF, gallwch newid rheolaethau tagfeydd ac amryw o leoliadau TCP eraill yn ddeinamig.
Ond mae'n bwysig i ni eich bod yn gallu troelli gwerthoedd SYN_RTO gyda chymorth. Ac mae enghraifft a bostiwyd yn gyhoeddus: . Beth a wneir yma? Mae'r enghraifft yn gweithio, ond yn ei hun yn arw iawn. Tybir yma ein bod y tu mewn i'r ganolfan ddata yn cymharu'r 44 did cyntaf, os ydyn nhw'n cyfateb, yna rydyn ni'n cael ein hunain y tu mewn i'r DC. Ac yn yr achos hwn, rydym yn newid gwerth terfyn amser SYN_RTO i 4ms. Gellir gwneud yr un dasg yn llawer mwy gosgeiddig. Ond y mae yr engraifft syml hon yn dangos yr hyn sydd a) bosibl ; b) yn gymharol hawdd.
Beth ydym ni'n ei wybod yn barod? Bod y bensaernïaeth planar yn caniatáu graddio, mae'n troi allan i fod yn hynod ddefnyddiol i ni pan fyddwn yn troi ar y label llif ar ToR a chael y cyfle i lifo o gwmpas meysydd problem. Y ffordd orau o ostwng gwerthoedd RTO a SYN-RTO yw defnyddio rhaglenni eBPF. Erys y cwestiwn: a yw'n ddiogel defnyddio'r label llif ar gyfer cydbwyso? Ac mae naws yma.
Tybiwch fod gennych chi wasanaeth ar y rhwydwaith sy'n byw yn anycast. Yn anffodus, nid oes gennyf amser i fanylu ar anycast, ond mae'n wasanaeth dosbarthedig lle mae gwahanol weinyddion ffisegol ar gael ar yr un cyfeiriad IP. A dyma broblem bosibl: gall y digwyddiad RTO ddigwydd nid yn unig pan fydd traffig yn mynd trwy'r ffatri. Gall hefyd ddigwydd ar lefel byffer ToR: pan fydd digwyddiad incast yn digwydd, gall hyd yn oed ddigwydd ar y gwesteiwr pan fydd y gwesteiwr yn gollwng rhywbeth. Pan fydd digwyddiad RTO yn digwydd ac mae'n newid y label llif. Yn yr achos hwn, gall y traffig fynd i unrhyw enghraifft arall. Tybiwch ei fod yn anycast stateful, mae'n cynnwys cyflwr cysylltiad - gall fod yn Balancer L3 neu ryw wasanaeth arall. Yna mae problem yn codi, oherwydd ar ôl yr RTO, mae'r cysylltiad TCP yn cyrraedd y gweinydd, nad yw'n gwybod dim am y cysylltiad TCP hwn. Ac os nad oes gennym ni rannu gwladwriaeth rhwng gweinyddwyr anycast, yna bydd traffig o'r fath yn cael ei ollwng a bydd y cysylltiad TCP yn torri.
Beth ellir ei wneud yma? O fewn eich amgylchedd rheoledig, lle rydych chi'n galluogi cydbwyso label llif, mae angen i chi osod gwerth y label llif wrth gyrchu gweinyddwyr anycast. Y ffordd hawsaf yw ei wneud trwy'r un rhaglen eBPF. Ond dyma bwynt pwysig iawn - beth i'w wneud os nad ydych chi'n gweithredu rhwydwaith canolfan ddata, ond yn weithredwr telathrebu? Dyma'ch problem chi hefyd: gan ddechrau gyda fersiynau penodol o Juniper ac Arista, maent yn cynnwys y label llif yn y swyddogaeth hash yn ddiofyn - a dweud y gwir, am reswm nad wyf yn ei ddeall. Gall hyn achosi i chi ollwng cysylltiadau TCP gan ddefnyddwyr sy'n mynd trwy'ch rhwydwaith. Felly, rwy'n argymell yn fawr eich bod yn gwirio gosodiadau eich llwybrydd yn y lleoliad hwn.
Un ffordd neu'r llall, mae'n ymddangos i mi ein bod yn barod i symud ymlaen i arbrofion.
Pan wnaethom droi ar y label llif ar ToR, paratoi eBPF yr asiant, sydd bellach yn byw ar y gwesteiwyr, penderfynasom beidio ag aros am y methiant mawr nesaf, ond i gynnal ffrwydradau rheoledig. Fe wnaethon ni gymryd ToR, sydd â phedwar cyswllt i fyny, a gwneud diferion ar un ohonyn nhw. Fe wnaethon nhw dynnu rheol, medden nhw - nawr rydych chi'n colli pob pecyn. Fel y gwelwch ar y chwith, mae gennym ni fonitro fesul pecyn, sydd wedi gostwng i 75%, hynny yw, mae 25% o becynnau'n cael eu colli. Ar y dde mae graffiau o wasanaethau sy'n byw y tu ôl i'r Cylch Gorchwyl hwn. Mewn gwirionedd, mae'r rhain yn graffiau traffig o gymalau gyda gweinyddwyr y tu mewn i'r rac. Fel y gwelwch, fe suddon nhw hyd yn oed yn is. Pam wnaethon nhw suddo yn is - nid gan 25%, ond mewn rhai achosion gan 3-4 gwaith? Os yw'r cysylltiad TCP yn anlwcus, mae'n parhau i geisio cyrraedd trwy'r rhyngwyneb torri. Gwaethygir hyn gan ymddygiad nodweddiadol y gwasanaeth o fewn y DC - ar gyfer un cais defnyddiwr, cynhyrchir ceisiadau N i wasanaethau mewnol, a bydd yr ymateb yn mynd at y defnyddiwr, naill ai pan fydd yr holl ffynonellau data yn ymateb, neu pan fydd terfyn amser yn cael ei sbarduno ar lefel y cais, y mae angen ei ffurfweddu o hyd. Hynny yw, mae popeth yn ddrwg iawn, iawn.
Nawr yr un arbrawf, ond gyda'r label llif wedi'i alluogi. Fel y gwelwch, ar y chwith, suddodd ein monitro swp yr un 25%. Mae hyn yn gwbl gywir, oherwydd nid yw'n gwybod dim am ail-drosglwyddiadau, mae'n anfon pecynnau ac yn syml yn cyfrif cymhareb nifer y pecynnau a ddanfonwyd ac a gollwyd.
Ac ar y dde mae'r amserlen o wasanaethau. Ni fyddwch yn dod o hyd i effaith cymal problemus yma. Llifodd traffig yn yr un milieiliadau hynny o'r ardal broblem i'r tri chyswllt i fyny oedd yn weddill nad oedd y broblem wedi effeithio arnynt. Cawsom rwydwaith sy'n gwella ei hun.
Dyma fy sleid olaf, amser i bwyso a mesur. Nawr, gobeithio eich bod chi'n gwybod sut i adeiladu rhwydwaith canolfan ddata hunan-iacháu. Ni fydd angen i chi fynd trwy'r archif cnewyllyn Linux a chwilio am glytiau arbennig yno, rydych chi'n gwybod bod y label Llif yn datrys y broblem yn yr achos hwn, ond mae angen i chi fynd at y mecanwaith hwn yn ofalus. Ac rwy'n pwysleisio eto, os ydych chi'n gludwr, ni ddylech ddefnyddio'r label llif fel swyddogaeth hash, fel arall byddwch chi'n torri sesiynau eich defnyddwyr.
Ar gyfer peirianwyr rhwydwaith, mae angen newid cysyniadol: nid yw'r rhwydwaith yn dechrau gyda ToR, nid gyda dyfais rhwydwaith, ond gyda gwesteiwr. Enghraifft eithaf trawiadol yw sut rydym yn defnyddio eBPF i newid y RTO ac i osod y label llif tuag at unrhyw wasanaethau darlledu.
Mae'r mecanig label llif yn sicr yn addas ar gyfer defnyddiau eraill o fewn y segment gweinyddol rheoledig. Gall hyn fod yn draffig rhwng canolfannau data, neu gallwch ddefnyddio mecaneg o'r fath mewn ffordd arbennig i reoli traffig sy'n mynd allan. Ond fe soniaf am hyn, gobeithio, y tro nesaf. Diolch yn fawr iawn am eich sylw.
Ffynhonnell: hab.com