Ndjekja e lidhjes (“conntrack”) është një veçori thelbësore e grupit të rrjeteve të kernelit Linux. Ai i lejon kernelit të mbajë gjurmët e të gjitha lidhjeve ose rrjedhave logjike të rrjetit dhe në këtë mënyrë të identifikojë të gjitha paketat që përbëjnë secilën rrjedhë në mënyrë që ato të mund të përpunohen së bashku në mënyrë sekuenciale.
Conntrack është një veçori e rëndësishme e kernelit që përdoret në disa raste themelore:
- NAT mbështetet në informacionin nga conntrack, kështu që mund të trajtojë të gjitha paketat nga i njëjti rrymë në mënyrë të barabartë. Për shembull, kur një pod akseson një shërbim Kubernetes, balancuesi i ngarkesës me proxy kube përdor NAT për të drejtuar trafikun në një pod specifik brenda grupit. Conntrack regjistron që për një lidhje të caktuar, të gjitha paketat në shërbimin IP duhet të dërgohen në të njëjtin pod dhe se paketat e kthyera nga pod backend duhet të kthehen në podin nga i cili erdhi kërkesa.
- Firewall-et shtetërore si Calico mbështeten në informacionin nga trafiku i "përgjigjeve" në listën e bardhë. Kjo ju lejon të shkruani një politikë rrjeti që thotë "lejo podin tim të lidhet me çdo adresë IP të largët" pa pasur nevojë të shkruani një politikë për të lejuar në mënyrë eksplicite trafikun e përgjigjes. (Pa këtë, do të duhet të shtoni rregullin shumë më pak të sigurt "lejo paketat në podin tim nga çdo IP".)
Për më tepër, conntrack zakonisht përmirëson performancën e sistemit (duke reduktuar konsumin e CPU-së dhe vonesën e paketave) pasi vetëm paketa e parë në një transmetim
duhet të kalojë nëpër të gjithë grupin e rrjetit për të përcaktuar se çfarë të bëhet me të. Shihni postimin"" për të parë një shembull se si funksionon.
Megjithatë, contrack ka kufizimet e veta...
Pra, ku shkoi gjithçka keq?
Tabela conntrack ka një madhësi maksimale të konfigurueshme dhe nëse mbushet, lidhjet zakonisht fillojnë të refuzohen ose të hiqen. Ka mjaft hapësirë të lirë në tabelë për të trajtuar trafikun e shumicës së aplikacioneve dhe kjo nuk do të bëhet kurrë problem. Sidoqoftë, ka disa skenarë në të cilët mund të dëshironi të merrni në konsideratë përdorimin e tabelës së kontrrollit:
- Rasti më i dukshëm është nëse serveri juaj trajton një numër jashtëzakonisht të madh lidhjesh njëkohësisht aktive. Për shembull, nëse tabela juaj e kontrollit është e konfiguruar për 128 mijë hyrje, por ju keni >128 mijë lidhje të njëkohshme, me siguri do të hasni në një problem!
- Një rast pak më pak i dukshëm: nëse serveri juaj përpunon një numër shumë të madh lidhjesh në sekondë. Edhe nëse lidhjet janë jetëshkurtër, ato vazhdojnë të monitorohen nga Linux për një periudhë kohore (120s si parazgjedhje). Për shembull, nëse tabela juaj conntrack është e konfiguruar për 128k hyrje dhe po përpiqeni të trajtoni 1100 lidhje në sekondë, ato do të tejkalojnë madhësinë e tabelës së kontrack, edhe nëse lidhjet janë shumë të shkurtra (128k/120s = 1092 lidhje/ s).
Ka disa lloje të veçanta të aplikacioneve që bien në këto kategori. Për më tepër, nëse keni shumë aktorë të këqij, mbushja e tabelës së kontrollit të serverit tuaj me shumë lidhje gjysmë të hapura mund të përdoret si pjesë e një sulmi të mohimit të shërbimit (DOS). Në të dyja rastet, conntrack mund të bëhet një pengesë kufizuese në sistemin tuaj. Në disa raste, rregullimi i parametrave të tabelës së kontrrollit mund të jetë i mjaftueshëm për të përmbushur nevojat tuaja - duke rritur madhësinë ose duke reduktuar kohëzgjatjen e lidhjes (por nëse e bëni gabim, do të hasni shumë telashe). Për raste të tjera do të jetë e nevojshme të anashkalohet kontrata për trafik agresiv.
Shembull i vërtetë
Le të japim një shembull specifik: një ofrues i madh SaaS me të cilin kemi punuar kishte një numër serverësh memcached në host (jo makina virtuale), secila prej të cilëve përpunonte 50K+ lidhje afatshkurtra në sekondë.
Ata eksperimentuan me konfigurimin e conntrack, duke rritur madhësinë e tabelave dhe duke zvogëluar kohën e gjurmimit, por konfigurimi nuk ishte i besueshëm, konsumi i RAM-it u rrit ndjeshëm, gjë që ishte një problem (në rendin e GBytes!), dhe lidhjet ishin aq të shkurtra sa conntrack nuk u bë krijoni përfitimin e tij të zakonshëm të performancës (konsumi i reduktuar i CPU ose vonesa e paketave).
Ata iu drejtuan Calico si një alternativë. Politikat e rrjetit Calico ju lejojnë të mos përdorni conntrack për lloje të caktuara trafiku (duke përdorur opsionin e politikës doNotTrack). Kjo u dha atyre nivelin e performancës që u nevojitej, plus nivelin e shtuar të sigurisë të ofruar nga Calico.
Në çfarë gjatësie do të duhet të shkoni për të anashkaluar kontrollin?
- Politikat e rrjetit të mos gjurmoni në përgjithësi duhet të jenë simetrike. Në rastin e ofruesit SaaS: aplikacionet e tyre funksiononin brenda zonës së mbrojtur dhe për këtë arsye, duke përdorur politikën e rrjetit, ata mund të listonin trafikun nga aplikacione të tjera specifike që u lejohej qasja në memcached.
- Politika mos gjurmoni nuk merr parasysh drejtimin e lidhjes. Kështu, nëse serveri memcached është hakuar, teorikisht mund të përpiqeni të lidheni me cilindo nga klientët e memcached, për sa kohë që ai përdor portën e saktë të burimit. Megjithatë, nëse e keni përcaktuar saktë politikën e rrjetit për klientët tuaj memcached, atëherë këto përpjekje për lidhje do të refuzohen përsëri nga ana e klientit.
- Politika mos gjurmoni zbatohet për çdo paketë, në krahasim me politikat normale, të cilat aplikohen vetëm për paketën e parë në një rrjedhë. Kjo mund të rrisë konsumin e CPU-së për paketë, sepse politika duhet të zbatohet për secilën paketë. Por për lidhjet jetëshkurtra, ky shpenzim balancohet nga reduktimi i konsumit të burimeve për përpunimin e kontrabandës. Për shembull, në rastin e një ofruesi SaaS, numri i paketave për çdo lidhje ishte shumë i vogël, kështu që konsumi shtesë i CPU-së gjatë aplikimit të politikave për secilën paketë ishte i justifikuar.
Le të fillojmë testimin
Ne e kryem testin në një pod të vetëm me një server memcached dhe memcached të shumta të klientëve që funksionojnë në nyje të largëta në mënyrë që të mund të ekzekutonim një numër shumë të madh lidhjesh për sekondë. Serveri me pod server të memcached kishte 8 bërthama dhe 512 mijë hyrje në tabelën e kontrack (madhësia standarde e tabelës së konfiguruar për hostin).
Ne matëm ndryshimin e performancës midis: pa politikë rrjeti; me politikë të rregullt Calico; dhe politikën e Calico-mos-përcjell.
Për testin e parë, ne vendosëm numrin e lidhjeve në 4.000 për sekondë, kështu që ne mund të fokusohemi në ndryshimin në konsumin e CPU. Nuk kishte dallime të rëndësishme midis politikës pa politikë dhe politikës së rregullt, por mos gjurmoni konsumin e rritur të CPU-së me rreth 20%:
Në testin e dytë, ne nisëm aq lidhje sa klientët tanë mund të gjeneronin dhe matëm numrin maksimal të lidhjeve në sekondë që serveri ynë memcached mund të trajtonte. Siç pritej, rastet "pa politikë" dhe "politikë e rregullt" arritën të dyja kufirin e kontaktit prej mbi 4,000 lidhjesh në sekondë (512k / 120s = 4,369 lidhje/s). Me një politikë të mos gjurmoni, klientët tanë dërguan 60,000 lidhje në sekondë pa asnjë problem. Jemi të sigurt se mund ta rrisim këtë numër duke shtuar më shumë klientë, por mendojmë se këto shifra tashmë janë të mjaftueshme për të ilustruar pikën e këtij artikulli!
Përfundim
Conntrack është një veçori e rëndësishme e kernelit. Ai e bën punën e tij në mënyrë perfekte. Shpesh përdoret nga komponentët kryesorë të sistemit. Megjithatë, në disa skenarë specifikë, mbingarkimi për shkak të kontrollit tejkalon përfitimet normale që ofron. Në këtë skenar, politikat e rrjetit Calico mund të përdoren për të çaktivizuar në mënyrë selektive përdorimin e conntrack duke rritur sigurinë e rrjetit. Për të gjithë trafikun tjetër, conntrack vazhdon të jetë miku juaj!
Lexoni gjithashtu artikuj të tjerë në blogun tonë:
Burimi: www.habr.com