Tá na céadta feiste gníomhach suiteáilte ag ionaid sonraí nua-aimseartha, clúdaithe ag cineálacha éagsúla monatóireachta. Ach beidh fiú innealtóir idéalach le monatóireacht foirfe ar láimh in ann freagairt i gceart ar theip líonra i gceann cúpla nóiméad. I dtuarascáil ag comhdháil Next Hop 2020, chuir mé modheolaíocht dearaidh líonra ionad sonraí i láthair, a bhfuil gné uathúil aige - cneasaíonn an t-ionad sonraí é féin i milleasoicindí. Níos cruinne, socraíonn an t-innealtóir an fhadhb go socair, agus ní thugann na seirbhísí faoi deara é.
I gcás go leor innealtóirí líonra, tosaíonn líonra lárionad sonraí, ar ndóigh, le ToR, le lasc sa raca. Tá dhá chineál naisc ag ToR de ghnáth. Téann na cinn bheaga go dtí na freastalaithe, cuid eile - tá N uair níos mó acu - téigh i dtreo spines an chéad leibhéal, is é sin, go dtí a naisc suas. De ghnáth meastar go bhfuil uplinks comhionann, agus déantar trácht idir uplinks a chothromú bunaithe ar hash ó 5-tuple, lena n-áirítear proto, src_ip, dst_ip, src_port, dst_port. Níl aon iontas anseo.
Ansin, cén chuma atá ar ailtireacht an phlean? Níl spines an chéad leibhéal ceangailte lena chéile, ach tá siad ceangailte trí superspines. Beidh an litir X freagrach as fordhromlaigh; tá sí beagnach cosúil le trasnasc.
Agus is léir, ar an láimh eile, go bhfuil tori ceangailte le gach spines den chéad leibhéal. Cad atá tábhachtach sa phictiúr seo? Má tá idirghníomhaíocht againn taobh istigh den raca, ansin téann an t-idirghníomhú, ar ndóigh, trí ToR. Má tharlaíonn an t-idirghníomhú taobh istigh den mhodúl, ansin tarlaíonn an t-idirghníomhú trí na spines chéad leibhéal. Má tá an idirghníomhaíocht idirmhodúil - mar atá anseo, ToR 1 agus ToR 2 - ansin rachaidh an t-idirghníomhú trí spines an chéad agus an dara leibhéal araon.
Go teoiriciúil, tá ailtireacht den sórt sin inscálaithe go héasca. Má tá toilleadh calafoirt againn, spás breise sa lárionad sonraí agus snáithín réamh-leagtha, is féidir líon na lánaí a mhéadú i gcónaí, rud a mhéadaíonn cumas iomlán an chórais. Tá sé seo an-éasca a dhéanamh ar pháipéar. Bheadh sé mar seo sa saol. Ach níl scéal an lae inniu faoi sin.
Ba mhaith liom go dtiocfar ar na conclúidí cearta. Tá go leor cosáin againn taobh istigh den ionad sonraí. Tá siad neamhspleách go coinníollach. Níl cosán amháin laistigh den ionad sonraí indéanta ach taobh istigh de ToR. Taobh istigh den mhodúl, ní mór dúinn líon na gcosán atá comhionann le líon na lánaí. Tá líon na gcosán idir modúil comhionann le táirge líon na n-eitleán agus líon na n-superspines i ngach eitleán. Chun é a dhéanamh níos soiléire, chun tuiscint a fháil ar an scála, tabharfaidh mé uimhreacha atá bailí do cheann de na hionaid sonraí Yandex.
Tá ocht n-eitleán ann, tá 32 sárdhromchla i ngach eitleán. Mar thoradh air sin, tharlaíonn sé go bhfuil ocht cosán taobh istigh den mhodúl, agus le hidirghníomhaíocht intermodule tá 256 acu cheana féin.
Is é sin, má táimid ag forbairt Cookbook, ag iarraidh a fháil amach conas a thógáil ionaid sonraí locht-fhulangach a leigheas iad féin, ansin is é ailtireacht phlánach an rogha ceart. Réitíonn sé an fhadhb scálaithe, agus go teoiriciúil tá sé éasca. Tá go leor cosáin neamhspleácha ann. Tá an cheist fós: conas a mhaireann ailtireacht den sórt sin teipeanna? Tá teipeanna éagsúla ann. Agus déanfaimid é seo a phlé anois.
Lig do dhuine dár n-uachtaráin “tinne” a bheith orthu. Anseo d'fhill mé ar an ailtireacht dhá-eitleán. Cloífimid leo seo mar shampla mar beidh sé níos éasca a fheiceáil cad atá ar siúl le níos lú páirteanna gluaisteacha. Lig do X11 éirí tinn. Cén tionchar a bheidh aige seo ar na seirbhísí a chónaíonn laistigh d’ionaid sonraí? Braitheann go leor ar an chuma atá ar an teip i ndáiríre.
Má tá an teip go maith, tá sé gafa ag leibhéal uathoibrithe an BFD céanna, cuireann an t-uathoibriú go sona sásta ar na hailt fhadhbacha agus an fhadhb a leithlisiú, ansin tá gach rud ceart go leor. Tá go leor cosáin againn, athraítear trácht láithreach chuig bealaí eile, agus ní thabharfaidh seirbhísí aon rud faoi deara. Is script maith é seo.
Is droch-scéal é má tá caillteanais leanúnacha againn, agus nach dtugann an uathoibriú an fhadhb faoi deara. Chun a thuiscint conas a théann sé seo i bhfeidhm ar fheidhmchlár, beidh orainn beagán ama a chaitheamh ag plé conas a oibríonn TCP.
Tá súil agam nach gcuirim iontas ar éinne leis an bhfaisnéis seo: is prótacal deimhnithe tarchurtha é TCP. Is é sin, sa chás is simplí, seolann an seoltóir dhá phaicéad agus faigheann sé ack carnach orthu: “Fuair mé dhá phaicéad.”
Tar éis sin, seolfaidh sé dhá phaicéad níos mó, agus beidh an scéal arís. Gabhaim leithscéal roimh ré as roinnt simplithe. Tá an cás seo ceart má tá an fhuinneog (líon na bpacáistí eitilte) dhá cheann. Ar ndóigh, sa chás ginearálta ní gá gurb é seo an cás. Ach ní chuireann méid na fuinneoige isteach ar chomhthéacs cur ar aghaidh na bpaicéad.
Cad a tharlóidh má chailleann muid paicéad 3? Sa chás seo, gheobhaidh an faighteoir paicéid 1, 2 agus 4. Agus inseoidh sé go sainráite don seoltóir ag baint úsáide as an rogha SACK: “Tá a fhios agat, tháinig trí cinn, ach cailleadh an lár.” Deir sé, "Ack 2, SACK 4."
Ag an nóiméad seo, déanann an seoltóir gan aon fhadhbanna go díreach an paicéad a cailleadh.
Ach má chailltear an paicéad deireanach san fhuinneog, beidh cuma go hiomlán difriúil ar an scéal.
Faigheann an faighteoir na chéad trí phaicéad agus ar an gcéad dul síos tosaíonn ag fanacht. Buíochas le roinnt optimizations i gcruach TCP an eithne Linux, fanfaidh sé le paicéad péireáilte mura léiríonn na bratacha go sainráite gurb é an paicéad deireanach é nó rud éigin cosúil leis. Fanfaidh sé go dtí go rachaidh an teorainn ama Moillithe ACK in éag agus ansin seolfaidh sé admháil ar na chéad trí phaicéad. Ach anois fanfaidh an seoltóir. Níl a fhios aige an bhfuil an ceathrú pacáiste caillte nó ar tí teacht. Agus ionas nach gcuirfear ró-ualú ar an líonra, déanfaidh sé iarracht fanacht le léiriú follasach go bhfuil an paicéad caillte, nó go rachaidh teorainn ama an RTO in éag.
Cad é teorainn ama RTO? Is é seo uasmhéid an RTT arna ríomh ag an stack TCP agus tairiseach éigin. Cén cineál tairiseach é seo, déanfaimid plé anois.
Ach is é an rud is tábhachtaí ná má bhíonn mí-ádh orainn arís agus an ceathrú paicéad caillte arís, ansin dúbailt an RTO. Is é sin, ciallaíonn gach iarracht nár éirigh leo an teorainn ama a dhúbailt.
Anois, déanaimis a fheiceáil cad is comhionann leis an mbonn seo. De réir réamhshocraithe, is é 200 ms an t-íosmhéid RTO. Is é seo an RTO íosta do phacáistí sonraí. I gcás paicéid SYN tá sé difriúil, 1 soicind. Mar a fheiceann tú, tógfaidh fiú an chéad iarracht paicéid a athsheoladh 100 uair níos faide ná an RTT taobh istigh den ionad sonraí.
Anois fillimis ar ár gcás. Cad atá ar siúl leis an tseirbhís? Tosaíonn an tseirbhís ag cailleadh paicéid. Bíodh an t-ádh coinníollach ar an tseirbhís ar dtús agus caillfidh sé rud éigin i lár na fuinneoige, ansin faigheann sé SACK agus athsheolann sé na paicéid a cailleadh.
Ach má tharlaíonn an droch-ádh arís, tá RTO againn. Cad atá tábhachtach anseo? Sea, tá go leor cosáin inár líonra. Ach leanfaidh an trácht TCP de nasc TCP ar leith amháin ag dul tríd an stack briste céanna. Caillteanais phaicéad, ar choinníoll nach dtéann an X11 draíochta seo againne amach ar a chuid féin, ní fhágann sé go sreabhann trácht isteach i gceantair nach bhfuil fadhbanna acu. Táimid ag iarraidh an paicéad a sheachadadh tríd an gcruach briste céanna. Tá teip cascáideach mar thoradh air seo: is sraith d’fheidhmchláir idirghníomhacha é lárionad sonraí, agus tosaíonn cuid de naisc TCP na n-iarratas seo go léir ag díghrádú - toisc go mbíonn tionchar ag superspin go ginearálta ar gach feidhmchlár atá taobh istigh den ionad sonraí. Mar a deir an abairt: mura ndearna tú capall, chuaigh an capall bacach; chuaigh an capall bacach - níor seachadadh an tuairisc; níor seachadadh an tuairisc - chailleamar an cogadh. Is anseo a dhéantar an comhaireamh i soicindí ón nóiméad a thagann an fhadhb chun cinn go dtí an chéim díghrádaithe a bhraitheann na seirbhísí. Ciallaíonn sé seo go bhféadfadh go mbeadh úsáideoirí in easnamh ar rud éigin áit éigin.
Tá dhá réitigh clasaiceacha ann a chomhlánaíonn a chéile. Is é an chéad cheann ná seirbhísí atá ag iarraidh sopanna a chur isteach agus an fhadhb a réiteach mar seo: “Déanaimis rud éigin a athrú sa chruach TCP. Déanaimis sosanna ama ag leibhéal an fheidhmchláir nó seisiúin TCP fadsaoil le seiceálacha sláinte inmheánacha.” Is í an fhadhb atá ann go bhfuil a leithéid de réitigh: a) nach scála ar chor ar bith; b) go bhfuil seiceáil an-lag orthu. Is é sin, fiú má dhéanann an tseirbhís an stack TCP a chumrú de thaisme ar bhealach a fhágann go bhfuil sé níos fearr, ar an gcéad dul síos, ní dócha go mbeidh sé infheidhme maidir le gach feidhmchlár agus gach ionad sonraí, agus sa dara háit, is dócha, ní thuigfidh sé go ndearnadh é. i gceart , agus cad nach bhfuil . Is é sin, oibríonn sé, ach oibríonn sé go dona agus ní scála. Agus má tá fadhb líonra, cé atá an milleán? Ar ndóigh, NOC. Cad a dhéanann NOC?
Creideann go leor seirbhísí go dtarlaíonn rud mar seo in obair NOC. Ach le bheith macánta, ní hamháin sin.
Tá NOC sa scéim chlasaiceach i mbun go leor córas monatóireachta a fhorbairt. Is monatóireacht bhosca dubh agus bosca bán iad seo. Maidir le sampla de mhonatóireacht spine bosca dubh Alexander Klimenko ag an chéad hop eile saor in aisce,. Dála an scéil, oibríonn an monatóireacht seo. Ach beidh moill ama ag fiú monatóireacht idéalach. De ghnáth is cúpla nóiméad é seo. Tar éis dó imeacht, beidh am ag teastáil ó na hinnealtóirí atá ar dualgas chun a oibriú a sheiceáil faoi dhó, an fhadhb a logánú agus ansin an limistéar fadhb a mhúchadh. Is é sin, sa chás is fearr, go dtógann an fhadhb a chóireáil 5 nóiméad, sa chás is measa, 20 nóiméad, mura bhfuil sé soiléir láithreach i gcás ina dtarlaíonn na caillteanais. Is léir an t-am seo ar fad - 5 nó 20 nóiméad - go leanfaidh ár seirbhísí ag fulaingt, rud nach bhfuil go maith is dócha.
Cad ba mhaith leat a fháil i ndáiríre? Tá an oiread sin bealaí againn. Agus tagann fadhbanna chun cinn go beacht toisc go leanann sreafaí TCP nach bhfuil an t-ádh leo an bealach céanna a úsáid. Teastaíonn rud éigin uainn a ligfidh dúinn ilbhealaí a úsáid laistigh d’aon nasc TCP amháin. Dhealródh sé go bhfuil réiteach againn. Tá TCP ann, ar a dtugtar TCP multipath, is é sin, TCP le haghaidh cosáin iolracha. True, forbraíodh é le haghaidh tasc go hiomlán difriúil - le haghaidh smartphones a bhfuil roinnt feistí líonra. Chun aistriú a uasmhéadú nó modh príomhúil/cúltaca a dhéanamh, forbraíodh meicníocht a chruthaíonn snáitheanna iolracha (seisiúin) go trédhearcach don fheidhmchlár agus a ligeann duit aistriú eatarthu i gcás teipe. Nó, mar a dúirt mé, an stríoc a uasmhéadú.
Ach tá nuance anseo. Chun tuiscint a fháil ar a bhfuil ann, beidh orainn féachaint ar conas a bhunaítear snáitheanna.
Tá snáitheanna suiteáilte go seicheamhach. Tá an chéad snáithe suiteáilte ar dtús. Socraítear snáitheanna ina dhiaidh sin ansin ag baint úsáide as an bhfianán a comhaontaíodh cheana laistigh den snáithe sin. Agus seo an fhadhb.
Is í an fhadhb atá ann, mura mbunaítear an chéad snáithe é féin, ní thiocfaidh an dara agus an tríú snáithe chun cinn riamh. Is é sin, ní réitíonn multipath TCP caillteanas paicéad SYN sa chéad sreabhadh. Agus má chailltear an SYN, iompaíonn multipath TCP ina TCP rialta. Ciallaíonn sé seo i dtimpeallacht lárionad sonraí nach gcuideoidh sé linn fadhb na gcaillteanas sa mhonarcha a réiteach agus foghlaim conas ilchosáin a úsáid i gcás teipe.
Cad is féidir cabhrú linn? Tá cuid agaibh tar éis buille faoi thuairim cheana féin ón teideal gur réimse tábhachtach inár scéal breise a bheidh sa réimse ceanntásc lipéad sreafa IPv6. Go deimhin, is réimse é seo atá le feiceáil i v6, níl sé i v4, áitíonn sé 20 giotán, agus tá conspóid ann maidir lena úsáid le fada an lá. Tá sé seo an-suimiúil - bhí díospóidí ann, socraíodh rud éigin laistigh den RFC, agus ag an am céanna bhí cur i bhfeidhm le feiceáil san eithne Linux, nach raibh doiciméadaithe in áit ar bith.
Tugaim cuireadh duit dul liom ar imscrúdú beag. Breathnaímid ar a bhfuil ag tarlú san eithne Linux le cúpla bliain anuas.
bhliain 2014. Cuireann innealtóir ó chuideachta mhór amháin a bhfuil meas air, le feidhmiúlacht an eithne Linux spleáchas luach an lipéid sreafa ar an hash soicéad. Cad a bhí siad ag iarraidh a shocrú anseo? Baineann sé seo le RFC 6438, a phléigh an tsaincheist seo a leanas. Taobh istigh den ionad sonraí, is minic go mbíonn IPv4 cuimsithe i bpacáistí IPv6, toisc go bhfuil an mhonarcha féin IPv6, ach ní mór IPv4 a thabhairt ar bhealach éigin lasmuigh. Ar feadh i bhfad bhí fadhbanna le lasca nach bhféadfaí breathnú faoi dhá cheanntásc IP chun TCP nó UDP a fháil agus src_ports, dst_ports a aimsiú ann. Iompaigh sé amach go bhfuil an hash, má fhéachann tú ar an chéad dá cheanntásc IP, iompaigh amach a bheith beagnach socraithe. Chun é seo a sheachaint, ionas go n-oibreodh cothromú an tráchta imchochlaithe seo i gceart, beartaíodh hash an phaicéid imchochlaithe 5-tuple a chur le luach réimse an lipéid sreafa. Rinneadh thart ar an rud céanna le haghaidh scéimeanna imchochlaithe eile, le haghaidh UDP, le haghaidh GRE, d'úsáid an dara ceann an réimse GRE Key. Bealach amháin nó bealach eile, tá na spriocanna anseo soiléir. Agus ar a laghad ag an bpointe ama sin bhí siad úsáideach.
In 2015, tagann paiste nua ón innealtóir measúil céanna. Tá sé an-suimiúil. Deir sé an méid seo a leanas - déanfaimid an hash a randamach i gcás imeacht ródaithe diúltach. Cad is imeacht ródaithe diúltach ann? Is é seo an RTO a phléamar níos luaithe, is é sin, go bhfuil caillteanas eireaball na fuinneoige ina imeacht atá fíor-dhiúltach. Fíor, tá sé sách deacair a buille faoi thuairim gurb é seo é.
2016, cuideachta creidiúnach eile, mór freisin. Díchóimeáil sé na crutches deiridh agus déanann sé é ionas go n-athraíonn an hash, a rinneamar go randamach roimhe seo, le haghaidh gach atarchuir SYN agus tar éis gach teorainn ama RTO. Agus sa litir seo, don chéad uair agus don uair dheireanach, luaitear an sprioc deiridh - a chinntiú go bhfuil an cumas ag an trácht i gcás caillteanais nó brú tráchta cainéal a athródú go bog agus cosáin iolracha a úsáid. Ar ndóigh, tar éis seo bhí go leor foilseachán, is féidir leat iad a fháil go héasca.
Cé nach bhfuil, ní féidir leat, toisc nach raibh foilseachán amháin ar an ábhar seo. Ach tá a fhios againn!
Agus mura dtuigeann tú go hiomlán cad a rinneadh, inseoidh mé duit anois.
Cad a rinneadh, cén fheidhmiúlacht a cuireadh leis an eithne Linux? athraíonn txhash go luach randamach tar éis gach teagmhais RTO. Is é seo an toradh an-diúltach ar ródú. Braitheann an hash ar an txhash seo, agus braitheann an lipéad sreafa ar an hash skb. Tá roinnt ríomhanna ar fheidhmeanna anseo; ní féidir na sonraí go léir a chur ar aon sleamhnán amháin. Má tá duine ar bith fiosrach, is féidir leat dul tríd an gcód eithne agus seiceáil.
Cad atá tábhachtach anseo? Athraíonn luach réimse an tsrea-lipéid go uimhir randamach tar éis gach RTO. Conas a théann sé seo i bhfeidhm ar ár sruth trua TCP?
Má tharlaíonn SACK, ní athraíonn aon rud mar go bhfuilimid ag iarraidh paicéad caillte a bhfuil aithne air a chur ar ais. Go dtí seo chomh maith.
Ach i gcás RTO, ar choinníoll go bhfuil lipéad sreafa curtha againn leis an bhfeidhm hash ar ToR, féadfaidh an trácht bealach eile a ghlacadh. Agus dá mhéad lánaí, is mó an seans go bhfaighidh sé cosán nach bhfuil tionchar ag teip ar fheiste ar leith air.
Tá fadhb amháin fós ann - RTO. Ar ndóigh, tá bealach eile ann, ach cuirtear go leor ama amú ar seo. Tá 200 ms go leor. Is é an dara go hiomlán fiáin. Roimhe seo, labhair mé faoi lasc ama go bhfuil seirbhísí cumraithe. Mar sin, is teorainn ama é an dara ceann, atá cumraithe de ghnáth ag an tseirbhís ag leibhéal an iarratais, agus leis seo beidh an tseirbhís sách ceart fiú. Thairis sin, deirim arís, tá an fíor-RTT taobh istigh d'ionad sonraí nua-aimseartha thart ar 1 milleasoicind.
Cad is féidir leat a dhéanamh le sosanna ama RTO? Is féidir an teorainn ama, atá freagrach as RTO i gcás caillteanas paicéid sonraí, a chumrú go measartha éasca ó spás úsáideora: tá fóntais IP ann, agus tá an rto_min céanna i gceann dá pharaiméadair. Ag cur san áireamh gur gá RTO, ar ndóigh, a choigeartú ní ar bhonn domhanda, ach i gcás réimíreanna tugtha, tá cuma sách inoibrithe ar mheicníocht den sórt sin.
Fíor, le SYN_RTO tá gach rud níos measa. Tá sé nailed síos go nádúrtha. Tá luach seasta de 1 soicind ag an eithne, agus sin é. Ní féidir leat teacht ann ó spás úsáideora. Níl ach bealach amháin ann.
Tagann eBPF chun tarrthála. Chun é a chur go simplí, is cláir bheaga C iad seo. Is féidir iad a chur isteach i gcrúcaí in áiteanna éagsúla le linn an chruach eithne agus an chruach TCP a fhorghníomhú, ar féidir leat líon an-mhór socruithe a athrú. Go ginearálta, is treocht fhadtéarmach é eBPF. In ionad na mórán paraiméadair sysctl nua a ghearradh agus an áirgiúlacht IP a leathnú, tá an ghluaiseacht ag bogadh i dtreo eBPF agus ag leathnú a fheidhmiúlacht. Trí úsáid a bhaint as eBPF, is féidir leat rialuithe plódaithe agus socruithe TCP éagsúla eile a athrú go dinimiciúil.
Ach tá sé tábhachtach dúinn gur féidir é a úsáid chun na luachanna SYN_RTO a athrú. Ina theannta sin, tá sampla a phostáiltear go poiblí: . Cad atá déanta anseo? Tá an sampla ag obair, ach ann féin tá sé an-gharbh. Glactar leis anseo go ndéanaimid comparáid laistigh den ionad sonraí leis na chéad 44 giotán; má mheaitseálann siad, táimid taobh istigh den ionad sonraí. Agus sa chás seo athraíonn muid an t-am istigh SYN_RTO go 4ms. Is féidir an tasc céanna a dhéanamh i bhfad níos galánta. Ach léiríonn an sampla simplí seo go bhfuil sé seo a) indéanta; b) réasúnta simplí.
Cad atá ar eolas againn cheana féin? Ós rud é go gceadaíonn ailtireacht an eitleáin scálú, bíonn sé thar a bheith úsáideach dúinn nuair a chuirimid ar chumas an lipéad sreafa ar ToR agus an cumas a fháil chun sreabhadh timpeall ar réimsí faidhbe. Is é an bealach is fearr chun luachanna RTO agus SYN-RTO a laghdú ná cláir eBPF a úsáid. Tá an cheist fós: an bhfuil sé sábháilte lipéad sreafa a úsáid le haghaidh cothromaíochta? Agus tá nuance anseo.
Cuir i gcás go bhfuil seirbhís agat ar do líonra a chónaíonn in aon chraoladh. Ar an drochuair, níl an t-am agam mionsonrú a dhéanamh ar cad is aon chraoladh ann, ach is seirbhís dáilte é le freastalaithe fisiceacha éagsúla atá inrochtana tríd an seoladh IP céanna. Agus tá fadhb féideartha anseo: is féidir leis an imeacht RTO tarlú, ní hamháin nuair a théann trácht tríd an bhfabraic. Is féidir leis tarlú freisin ag leibhéal maolánach ToR: nuair a tharlaíonn teagmhas incast, is féidir leis tarlú fiú ar an ósta nuair a dhoirteann an t-óstach rud éigin. Nuair a tharlaíonn teagmhas RTO agus athraíonn sé an lipéad sreafa. Sa chás seo, is féidir leis an trácht dul chuig cás ar bith eile. Glacaimis leis gur craoladh státmhar é seo, go bhfuil staid nasctha ann - d'fhéadfadh gur Cothromóir L3 nó seirbhís éigin eile a bheadh i gceist. Ansin tagann fadhb chun cinn, mar tar éis RTO go dtagann an nasc TCP chuig an bhfreastalaí, nach bhfuil aon eolas aige faoin nasc TCP seo. Agus mura bhfuil comhroinnt stáit againn idir freastalaithe teilgthe ar bith, ansin laghdófar an trácht sin agus brisfear an nasc TCP.
Cad is féidir leat a dhéanamh anseo? Laistigh de do thimpeallacht rialaithe, nuair a chumasaíonn tú comhardú lipéad sreafa, ní mór duit luach an lipéid sreafa a thaifeadadh agus tú ag rochtain ar fhreastalaithe aonchraolta. Is é an bealach is éasca é seo a dhéanamh tríd an gclár eBPF céanna. Ach tá pointe an-tábhachtach anseo - cad atá le déanamh mura n-oibríonn tú líonra ionad sonraí, ach gur oibreoir teileachumarsáide é? Is é seo an fhadhb atá agat freisin: ag tosú le leaganacha áirithe de Juniper agus Arista, cuimsíonn siad lipéad sreafa ina bhfeidhmeanna hash de réir réamhshocraithe - go frankly, ar chúis nach bhfuil soiléir domsa. D'fhéadfadh sé seo a bheith ina chúis le naisc TCP a scaoileadh ó úsáideoirí a théann trí do líonra. Mar sin molaim go mór do shocruithe ródairí a sheiceáil anseo.
Ar bhealach amháin nó ar bhealach eile, feictear domsa go bhfuil muid réidh le bogadh ar aghaidh chuig turgnaimh.
Nuair a chumasamar an lipéad sreafa ar ToR, d'ullmhaigh an gníomhaire eBPF, a bhfuil cónaí air ar na hóstach anois, shocraigh muid gan fanacht leis an gcéad teip mhór eile, ach pléascanna rialaithe a dhéanamh. Thógamar ToR, a bhfuil ceithre nasc suas aige, agus leagamar braon ar cheann acu. Tharraing siad riail agus dúirt - anois tá tú ag cailleadh gach paicéad. Mar a fheiceann tú ar an taobh clé, tá monatóireacht in aghaidh an phacáiste againn, a thit go 75%, is é sin, cailltear 25% de na paicéid. Ar dheis tá graif de sheirbhísí atá taobh thiar den ToR seo. Go bunúsach, is graif tráchta iad seo de na comhéadain le freastalaithe taobh istigh den raca. Mar a fheiceann tú, chuaigh siad go tóin poill níos ísle fós. Cén fáth ar thit siad níos ísle - ní ag 25%, ach i gcásanna áirithe ag 3-4 huaire? Má tá an nasc TCP mí-ádh, leanann sé ar aghaidh ag iarraidh a bhaint amach tríd an acomhal briste. Tá sé seo níos measa ag iompar tipiciúil na seirbhíse laistigh den DC - i gcás iarratas úsáideora amháin, gintear N iarratas ar sheirbhísí inmheánacha, agus rachaidh an freagra chuig an úsáideoir nuair a fhreagraíonn gach foinse sonraí, nó nuair a tharlaíonn teorainn ama ag an bhfeidhmchlár leibhéal, a bhfuil gá fós a chumrú. Is é sin, tá gach rud an-, an-dona.
Anois an turgnamh céanna, ach leis an luach lipéad sreafa cumasaithe. Mar a fheiceann tú, ar an taobh clé thit ár monatóireacht bhaisc faoi mar an gcéanna 25%. Tá sé seo fíor-cheart, toisc nach bhfuil a fhios aige rud ar bith faoi ath-chraoltaí, seolann sé paicéid agus ní dhéanann sé ach an cóimheas idir líon na bpacáistí seachadta agus caillte a chomhaireamh.
Agus ar dheis tá an sceideal seirbhíse. Ní bhfaighidh tú éifeacht alt fadhbach anseo. Sna milleasoicindí céanna sin, shreabh an trácht ó limistéar na faidhbe go dtí na trí nasc suas a bhí fágtha nach raibh tionchar ag an bhfadhb orthu. Tá líonra againn a leighiseann é féin.
Is é seo mo sleamhnán deireanach, am chun achoimre. Anois, tá súil agam go bhfuil a fhios agat conas líonra lárionad sonraí féin-leighis a thógáil. Ní bheidh ort dul tríd an gcartlann eithne Linux agus lorg paistí speisialta ann; tá a fhios agat go réitíonn an lipéad Sreabhadh sa chás seo an fhadhb, ach ní mór duit dul i ngleic leis an meicníocht seo go cúramach. Agus cuirim béim arís, más oibreoir teileachumarsáide tú, níor cheart duit lipéad sreafa a úsáid mar fheidhm hash, nó cuirfidh tú isteach ar sheisiúin d'úsáideoirí.
Caithfidh innealtóirí líonra dul faoi athrú coincheapúil: ní thosaíonn an líonra leis an ToR, ní leis an ngléas líonra, ach leis an óstach. Sampla an-suntasach is ea an chaoi a n-úsáidimid eBPF chun an RTO a athrú agus chun an lipéad sreafa a shocrú i dtreo aon seirbhísí teilgin.
Is cinnte go bhfuil na meicnic lipéad sreafa oiriúnach d'fheidhmchláir eile laistigh den deighleog riaracháin rialaithe. Is féidir gur trácht idir ionaid sonraí é seo, nó is féidir leat meicnic den sórt sin a úsáid ar bhealach speisialta chun trácht atá ag dul as oifig a bhainistiú. Ach inseoidh mé duit faoi seo, tá súil agam, an chéad uair eile. Go raibh míle maith agat as do aire.
Foinse: will.com