Şopandina girêdanê ("conntrack") taybetmendiyek bingehîn a stûna torê ya kernel Linux ye. Ew destûrê dide kernelê ku hemî girêdan an herikîna torê ya mantiqî bişopîne û bi vî rengî hemî pakêtên ku her herikekê pêk tînin nas bike da ku ew bi hevûdu re bi hev re bêne hilberandin.
Conntrack taybetmendiyek kernelê ya girîng e ku di hin rewşên bingehîn de tê bikar anîn:
- NAT xwe dispêre agahdariya ji kontrackê ji ber vê yekê ew dikare hemî pakêtên ji heman çemê wekhev derman bike. Mînakî, dema ku pod digihîje karûbarek Kubernetes, balansa barkirinê ya kube-proxy NAT bikar tîne da ku seyrûseferê berbi podek taybetî ya di nav komê de rêve bike. Conntrack tomar dike ku ji bo pêwendiyek diyarkirî, divê hemî pakêtên karûbarê IP-yê ji heman podê re bêne şandin, û ew pakêtên ku ji hêla podê paşîn ve têne vegerandin divê ji podê ku daxwaz jê hatî vegere NAT.
- Firewallên dewletî yên wekî Calico xwe dispêre agahdariya ji girêdana bi seyrûsefera "bersiv"ê ya navnîşa spî. Ev dihêle hûn siyasetek torê binivîsin ku dibêje "destûrê bide podê min ku bi her navnîşana IP-ya dûr ve girêbide" bêyî ku hûn siyasetek binivîsin da ku bi eşkere destûr bide seyrûsefera bersivê. (Bêyî vê, hûn neçar in ku qaîdeya pir kêmtir ewledar "destûr bide pakêtên li ser podê min ji her IP-yê" zêde bikin.)
Wekî din, conntrack bi gelemperî performansa pergalê çêtir dike (bi kêmkirina xerckirina CPU û derengiya pakêtê) ji ber ku tenê pakêta yekem di herikekê de ye.
pêdivî ye ku di tevahiya stoka torê re derbas bibe da ku diyar bike ka meriv bi wê re çi bike. Postê bibînin"" ji bo ku mînakek çawa dixebite bibînin.
Lêbelê, contrack sînorên xwe hene ...
Ji ber vê yekê ew hemî xelet çû ku derê?
Tabloya conntrack xwedan mezinahiyek herî zêde ya mîhengkirî ye, û heke ew tije bibe, girêdan bi gelemperî dest bi red kirin an avêtinê dikin. Di tabloyê de cîhê belaş têra xwe heye ku meriv seyrûsefera piraniya serlêdanan bi rê ve bibe, û ev ê çu carî nebe pirsgirêk. Lêbelê, çend senaryo hene ku tê de dibe ku hûn bixwazin bi karanîna tabloya kontrakê bifikirin:
- Doza herî eşkere ev e ku ger servera we hejmareke pir mezin a girêdanên hevdemî çalak digire dest. Mînakî, heke tabloya weya kontrakê ji bo têketinên 128k hatî mîheng kirin, lê we > 128k girêdanên hevdemî hene, hûn ê bê guman pirsgirêkek biqewirînin!
- Bûyerek hindik kêmtir eşkere: heke servera we di çirkeyê de hejmareke pir mezin a girêdanan pêvajoyê dike. Tewra ku girêdan kurtedemî bin jî, ew ji hêla Linux-ê ve ji bo demek demkî têne şopandin (ji hêla xwerû 120-an). Mînakî, heke tabloya weya kontrakê ji bo têketinên 128k hatî mîheng kirin û hûn hewl didin ku di çirkekê de 1100 girêdan bi rê ve bibin, ew ê ji mezinahiya tabloya kontrakê derbas bibin jî heke girêdan pir kurt bin jî (128k/120 = 1092 girêdan/s ).
Gelek celeb celebên serîlêdanên ku di van kategoriyan de cih digirin hene. Wekî din, heke we gelek aktorên xirab hebin, dagirtina tabloya kontrakê ya servera xwe bi gelek girêdanên nîv-vekirî dikare wekî beşek ji êrîşa înkarkirina karûbarê (DOS) were bikar anîn. Di her du rewşan de, conntrack dikare di pergala we de bibe astengek sînordar. Di hin rewşan de, verastkirina parametreyên tabloya kontrakê dibe ku ji bo peydakirina hewcedariyên we bes be - bi zêdekirina mezinbûnê an kêmkirina demên kontrakê (lê heke hûn wiya xelet bikin, hûn ê bikevin nav gelek tengasiyan). Ji bo rewşên din, ew ê hewce be ku ji bo seyrûsefera aggressive rêgez were derbas kirin.
Mînaka rastîn
Ka em mînakek taybetî bidin: pêşkêşkerek mezin a SaaS-ê ku em pê re xebitîn li ser mêvandaran (ne makîneyên virtual) hejmarek serverên memcached hebûn, ku her yek ji wan 50K+ girêdanên kurt-kurt di çirkeyê de pêvajo kirin.
Wan bi veavakirina conntrack ceriband, mezinahiya tabloyê zêde kir û dema şopandinê kêm kir, lê veavakirin ne pêbawer bû, mezaxtina RAM bi girîngî zêde bû, ku ev pirsgirêk bû (li ser fermana GBytes!), û girêdan ew qas kurt bûn ku conntrack nekir. feyda performansa wê ya asayî biafirîne (kêmkirina xerckirina CPU an derengiya pakêtê).
Wan wekî alternatîfek berê xwe da Calico. Polîtîkayên torê yên Calico dihêle hûn ji bo hin celeb seyrûseferê conntrack bikar neynin (bikaranîna vebijarka siyaseta doNotTrack). Vê yekê asta performansa ku ew hewce bû da wan, plus asta ewlehiya zêde ya ku ji hêla Calico ve hatî peyda kirin.
Ji bo derbaskirina kontrakê divê hûn bi çi dirêjî biçin?
- Polîtîkayên torê ne-şopandin divê bi gelemperî simetrîk bin. Di doza peydakerê SaaS de: sepanên wan di hundurê herêmek parastî de dimeşin û ji ber vê yekê, bi karanîna siyaseta torê, ew dikarin seyrûsefera ji serîlêdanên taybetî yên din ên ku destûr ji gihandina memcached re hatî dayîn navnîş bikin.
- Siyaseta neşopandinê rêgeza girêdanê li ber çavan nagire. Bi vî rengî, heke servera memcached were hack kirin, hûn dikarin bi teorîkî hewl bidin ku bi yek ji xerîdarên memcached ve girêbidin, heya ku ew porta çavkaniya rast bikar tîne. Lêbelê, heke we polîtîkaya torê ya ji bo xerîdarên xweyên memcached rast diyar kir, wê hingê ev hewildanên girêdanê dê dîsa jî li alîyê xerîdar bêne red kirin.
- Siyaseta neşopandinê li ser her pakêtê tê sepandin, berevajî polîtîkayên normal, yên ku tenê li ser pakêta yekem di herikandinê de têne sepandin. Ev dikare serfkariya CPU-yê ji bo her pakêtê zêde bike ji ber ku divê siyaset ji bo her pakêtê were sepandin. Lê ji bo girêdanên demkurt, ev lêçûn bi kêmkirina xerckirina çavkaniyê ji bo pêvajoyek kontrakê tê hevseng kirin. Mînakî, di mijara peydakerek SaaS de, ji bo her pêwendiyê hejmara pakêtan pir hindik bû, ji ber vê yekê dema ku polîtîkayên li ser her pakêtê sepandin serfkirina CPU-yê zêde rastdar bû.
Ka em dest bi ceribandinê bikin
Me îmtîhanê li ser yek podek bi serverek memcached û gelek podên xerîdar ên memcached ên ku li ser girêkên dûr têne xebitandin meşandin da ku em karibin di çirkeyê de hejmareke pir mezin a girêdanan bimeşînin. Pêşkêşkara bi pod servera memcached di tabloya conntrackê de 8 core û 512k têketin hebûn (mezinahiya tabloya mîhengkirî ya standard ji bo mêvandar).
Me ferqa performansê di navbera pîva: polîtîkaya torê tune; bi siyaseta Calico bi rêkûpêk; û siyaseta Calico-ne-şopandinê.
Ji bo ceribandina yekem, me jimara pêwendiyan di saniyeyê de 4.000 danî, ji ber vê yekê em dikarin balê bikişînin ser cûdahiya vexwarina CPU. Di navbera bê siyaset û polîtîkaya birêkûpêk de cûdahiyên girîng tune bûn, lê ne-şopandin bi qasî 20% xerckirina CPU zêde kir:
Di ceribandina duyemîn de, me bi qasî ku xerîdarên me dikaribûn biafirînin û jimareya herî zêde ya girêdanan ku servera meya memcached dikaribû bi rê ve bibe, me dest pê kir. Wekî ku tê çaverê kirin, dozên "bê polîtîka" û "siyaseta birêkûpêk" her du jî gihîştin sînorê 4,000 girêdanê di çirkekê de (512k / 120s = 4,369 girêdan / s). Bi polîtîkaya neşopandinê re, xerîdarên me di çirkeyê de 60,000 girêdan bêyî pirsgirêk şandin. Em pê bawer in ku em dikarin vê hejmarê bi lê zêdekirina xerîdar zêde bikin, lê em hîs dikin ku ev hejmar jixwe têra ronîkirina xala vê gotarê dikin!
encamê
Conntrack taybetmendiyek kernelê ya girîng e. Ew karê xwe bêkêmasî dike. Ew pir caran ji hêla hêmanên pergalê yên sereke ve tê bikar anîn. Lêbelê, di hin senaryoyên taybetî de, qerebalixiya ji ber vegirtinê ji feydeyên normal ên ku ew peyda dike girantir dike. Di vê senaryoyê de, polîtîkayên torê yên Calico dikare were bikar anîn da ku bi hilbijartî karanîna kontrakê neçalak bike dema ku ewlehiya torê zêde bike. Ji bo hemî seyrûseferên din, conntrack berdewam dike ku bibe hevalê we!
Her weha gotarên din ên li ser bloga me bixwînin:
Source: www.habr.com