Mae olrhain cysylltiad (“conntrack”) yn nodwedd graidd o stac rhwydweithio cnewyllyn Linux. Mae'n caniatáu i'r cnewyllyn gadw golwg ar yr holl gysylltiadau rhwydwaith neu lifoedd rhesymegol a thrwy hynny nodi'r holl becynnau sy'n rhan o bob llif fel y gellir eu prosesu gyda'i gilydd yn olynol.
Mae Conntrack yn nodwedd gnewyllyn pwysig a ddefnyddir mewn rhai achosion sylfaenol:
- Mae NAT yn dibynnu ar wybodaeth o conntrack fel y gall drin pob pecyn o'r un ffrwd yn gyfartal. Er enghraifft, pan fydd pod yn cyrchu gwasanaeth Kubernetes, mae'r cydbwysedd llwyth kube-proxy yn defnyddio NAT i gyfeirio traffig i god penodol o fewn y clwstwr. Mae Conntrack yn cofnodi, ar gyfer cysylltiad penodol, bod yn rhaid anfon yr holl becynnau i'r gwasanaeth IP i'r un pod, a bod yn rhaid i becynnau a ddychwelir gan y pod ôl-wyneb fod yn NAT yn ôl i'r pod y daeth y cais ohono.
- Mae waliau tân nodedig fel Calico yn dibynnu ar wybodaeth o tracktrack i draffig “ymateb” rhestr wen. Mae hyn yn caniatáu ichi ysgrifennu polisi rhwydwaith sy'n dweud "caniatáu i'm pod gysylltu ag unrhyw gyfeiriad IP anghysbell" heb orfod ysgrifennu polisi i ganiatáu traffig ymateb yn benodol. (Heb hyn, byddai'n rhaid i chi ychwanegu'r rheol llawer llai diogel "caniatáu pecynnau i'm pod o unrhyw IP".)
Yn ogystal, mae conntrack fel arfer yn gwella perfformiad system (trwy leihau defnydd CPU a hwyrni pecynnau) ers dim ond y pecyn cyntaf mewn ffrwd
rhaid mynd trwy'r pentwr rhwydwaith cyfan i benderfynu beth i'w wneud ag ef. Gweler y post"" i weld enghraifft o sut mae hyn yn gweithio.
Fodd bynnag, mae gan conntrack ei gyfyngiadau ...
Felly ble aeth y cyfan o'i le?
Mae gan y tabl conntrack uchafswm maint ffurfweddu, ac os yw'n mynd yn llawn, mae cysylltiadau fel arfer yn dechrau cael eu gwrthod neu eu gollwng. Mae digon o le rhydd yn y bwrdd i drin traffig y mwyafrif o gymwysiadau, ac ni fydd hyn byth yn dod yn broblem. Fodd bynnag, mae yna rai senarios lle efallai yr hoffech chi ystyried defnyddio'r tabl conntrack:
- Yr achos mwyaf amlwg yw os yw'ch gweinydd yn trin nifer fawr iawn o gysylltiadau gweithredol ar yr un pryd. Er enghraifft, os yw'ch tabl conntrack wedi'i ffurfweddu ar gyfer cofnodion 128k, ond bod gennych chi gysylltiadau cydamserol> 128k, mae'n siŵr y byddwch chi'n mynd i broblem!
- Achos ychydig yn llai amlwg: os yw'ch gweinydd yn prosesu nifer fawr iawn o gysylltiadau yr eiliad. Hyd yn oed os yw'r cysylltiadau'n fyrhoedlog, maent yn parhau i gael eu monitro gan Linux am beth amser (120au yn ddiofyn). Er enghraifft, os yw'ch tabl conntrack wedi'i ffurfweddu ar gyfer cofnodion 128k a'ch bod yn ceisio trin 1100 o gysylltiadau yr eiliad, byddant yn fwy na maint y tabl conntrack, hyd yn oed os yw'r cysylltiadau'n fyrhoedlog iawn (128k/120s = 1092 o gysylltiadau/ s).
Mae yna sawl math arbenigol o apiau sy'n perthyn i'r categorïau hyn. Yn ogystal, os oes gennych chi lawer o actorion drwg, gellid defnyddio llenwi tabl olrhain eich gweinydd gyda llawer o gysylltiadau hanner agored fel rhan o ymosodiad gwrthod gwasanaeth (DOS). Yn y ddau achos, gall conntrack ddod yn dagfa gyfyngol yn eich system. Mewn rhai achosion, efallai y bydd addasu paramedrau'r tabl conntrack yn ddigon i ddiwallu'ch anghenion - trwy gynyddu'r maint neu leihau'r terfynau amser cyswllt (ond os gwnewch bethau'n anghywir, byddwch yn mynd i lawer o drafferth). Mewn achosion eraill bydd angen osgoi conntrack ar gyfer traffig ymosodol.
Enghraifft go iawn
Gadewch i ni roi enghraifft benodol: roedd gan un darparwr SaaS mawr y buom yn gweithio ag ef nifer o weinyddion memcached ar westeion (nid peiriannau rhithwir), ac roedd pob un ohonynt yn prosesu 50K + o gysylltiadau tymor byr yr eiliad.
Fe wnaethon nhw arbrofi gyda'r cyfluniad conntrack, cynyddu maint tablau a lleihau amser olrhain, ond roedd y ffurfweddiad yn annibynadwy, cynyddodd y defnydd RAM yn sylweddol, a oedd yn broblem (yn ôl trefn GBytes!), Ac roedd y cysylltiadau mor fyr fel nad oedd conntrack yn gwneud hynny. creu ei fudd perfformiad arferol (defnydd llai o CPU neu hwyrni pecynnau).
Troesant at Calico fel dewis arall. Mae polisïau rhwydwaith Calico yn caniatáu ichi beidio â defnyddio conntrack ar gyfer rhai mathau o draffig (gan ddefnyddio'r opsiwn polisi doNotTrack). Rhoddodd hyn y lefel o berfformiad yr oedd ei angen arnynt, ynghyd â'r lefel ychwanegol o ddiogelwch a ddarparwyd gan Calico.
Pa mor hir y bydd yn rhaid i chi fynd iddo i osgoi conntrack?
- Yn gyffredinol, dylai polisïau rhwydwaith peidiwch â thracio fod yn gymesur. Yn achos y darparwr SaaS: roedd eu cymwysiadau'n rhedeg y tu mewn i'r parth gwarchodedig ac felly, gan ddefnyddio polisi rhwydwaith, gallent greu rhestr wen o draffig o gymwysiadau penodol eraill a ganiatawyd i gael mynediad i memcached.
- Nid yw'r polisi peidiwch ag olrhain yn ystyried cyfeiriad y cysylltiad. Felly, os caiff y gweinydd memcached ei hacio, yn ddamcaniaethol gallwch geisio cysylltu ag unrhyw un o'r cleientiaid memcached, cyn belled â'i fod yn defnyddio'r porth ffynhonnell cywir. Fodd bynnag, os ydych wedi diffinio'r polisi rhwydwaith yn gywir ar gyfer eich cleientiaid memcached, yna bydd yr ymdrechion cysylltu hyn yn dal i gael eu gwrthod ar ochr y cleient.
- Mae'r polisi peidiwch ag olrhain yn cael ei gymhwyso i bob pecyn, yn hytrach na pholisïau arferol, sy'n cael eu cymhwyso i'r pecyn cyntaf mewn llif yn unig. Gall hyn gynyddu'r defnydd CPU fesul pecyn oherwydd mae'n rhaid cymhwyso'r polisi ar gyfer pob pecyn. Ond ar gyfer cysylltiadau byrhoedlog, caiff y gost hon ei chydbwyso gan y gostyngiad yn y defnydd o adnoddau ar gyfer prosesu conntrack. Er enghraifft, yn achos darparwr SaaS, roedd nifer y pecynnau ar gyfer pob cysylltiad yn fach iawn, felly roedd y defnydd CPU ychwanegol wrth gymhwyso polisïau i bob pecyn yn gyfiawn.
Gadewch i ni ddechrau profi
Fe wnaethom redeg y prawf ar god sengl gyda gweinydd memcached a chodau cleient memcached lluosog yn rhedeg ar nodau anghysbell fel y gallem redeg nifer fawr iawn o gysylltiadau yr eiliad. Roedd gan y gweinydd gyda'r pod gweinydd memcached 8 cores a 512k o gofnodion yn y tabl conntrack (y maint tabl safonol wedi'i ffurfweddu ar gyfer y gwesteiwr).
Fe wnaethom fesur y gwahaniaeth perfformiad rhwng: dim polisi rhwydwaith; gyda pholisi rheolaidd Calico; a pholisi nad yw'n olrhain Calico.
Ar gyfer y prawf cyntaf, fe wnaethom osod nifer y cysylltiadau i 4.000 yr eiliad, felly gallem ganolbwyntio ar y gwahaniaeth yn y defnydd o CPU. Nid oedd unrhyw wahaniaethau sylweddol rhwng dim polisi a pholisi rheolaidd, ond peidiwch ag olrhain cynnydd o tua 20% yn y defnydd o CPU:
Yn yr ail brawf, fe wnaethom lansio cymaint o gysylltiadau ag y gallai ein cleientiaid eu cynhyrchu a mesur y nifer uchaf o gysylltiadau yr eiliad y gallai ein gweinydd memcached eu trin. Yn ôl y disgwyl, cyrhaeddodd yr achosion “dim polisi” a “pholisi rheolaidd” y terfyn olrhain o dros 4,000 o gysylltiadau yr eiliad (512k / 120s = 4,369 o gysylltiadau/au). Gyda pholisi peidiwch â thracio, anfonodd ein cleientiaid 60,000 o gysylltiadau yr eiliad heb unrhyw broblemau. Rydym yn siŵr y gallem gynyddu'r nifer hwn trwy ychwanegu mwy o gleientiaid, ond teimlwn fod y niferoedd hyn eisoes yn ddigon i ddangos pwynt yr erthygl hon!
Casgliad
Mae Conntrack yn nodwedd gnewyllyn pwysig. Mae'n gwneud ei waith yn berffaith. Fe'i defnyddir yn aml gan gydrannau system allweddol. Fodd bynnag, mewn rhai sefyllfaoedd penodol, mae'r tagfeydd oherwydd conntrack yn drech na'r buddion arferol y mae'n eu darparu. Yn y senario hwn, gellir defnyddio polisïau rhwydwaith Calico i analluogi'n ddetholus y defnydd o conntrack tra'n cynyddu diogelwch rhwydwaith. Ar gyfer pob traffig arall, mae conntrack yn parhau i fod yn ffrind i chi!
Darllenwch erthyglau eraill ar ein blog hefyd:
Ffynhonnell: hab.com