ProHoster > Blogs > Administrācija > Kad Linux conntrack vairs nav jūsu draugs

Kad Linux conntrack vairs nav jūsu draugs

Kad Linux conntrack vairs nav jūsu draugs

Savienojuma izsekoÅ”ana (ā€œconntrackā€) ir Linux kodola tÄ«kla steka galvenā funkcija. Tas ļauj kodolam izsekot visiem loÄ£iskajiem tÄ«kla savienojumiem vai plÅ«smām un tādējādi identificēt visas paketes, kas veido katru plÅ«smu, lai tās varētu secÄ«gi apstrādāt kopā.

Conntrack ir svarīga kodola funkcija, kas tiek izmantota dažos pamata gadījumos:

  • NAT paļaujas uz informāciju no conntrack, lai tas varētu vienādi apstrādāt visas paketes no vienas straumes. Piemēram, kad pods piekļūst Kubernetes pakalpojumam, kube starpniekservera slodzes lÄ«dzsvarotājs izmanto NAT, lai novirzÄ«tu trafiku uz noteiktu kopu klasterÄ«. Conntrack reÄ£istrē, ka konkrētajam savienojumam visas IP pakalpojuma paketes ir jānosÅ«ta uz vienu un to paÅ”u pod un ka aizmugursistēmas podziņa atgrieztās paketes ir jānosÅ«ta atpakaļ podā, no kura tika saņemts pieprasÄ«jums.
  • Stacionārie ugunsmÅ«ri, piemēram, Calico, paļaujas uz informāciju no savienojuma celiņa uz baltā saraksta ā€œatbildesā€ trafiku. Tādējādi varat uzrakstÄ«t tÄ«kla politiku, kas saka ā€œatļaut manam podam izveidot savienojumu ar jebkuru attālo IP adresiā€, nerakstot politiku, lai skaidri atļautu atbildes trafiku. (Bez tā jums bÅ«tu jāpievieno daudz mazāk droÅ”ais noteikums "atļaut paketes manam podam no jebkura IP".)

Turklāt conntrack parasti uzlabo sistēmas veiktspēju (samazinot CPU patēriņu un pakeÅ”u latentumu), jo tikai pirmā pakete straumē
ir jāiet cauri visai tīkla stekam, lai noteiktu, ko ar to darīt. Skatīt ziņu "Kube starpniekservera režīmu salīdzinājums", lai redzētu piemēru, kā tas darbojas.

Tomēr conntrack ir savi ierobežojumi...

Tātad, kur tas viss nogāja greizi?

Conntrack tabulai ir konfigurējams maksimālais izmērs, un, ja tā kļūst pilna, savienojumi parasti tiek noraidīti vai pārtraukti. Tabulā ir pietiekami daudz brīvas vietas, lai apstrādātu vairuma lietojumprogrammu trafiku, un tas nekad nekļūs par problēmu. Tomēr ir daži scenāriji, kuros jūs varētu vēlēties izmantot conntrack tabulu:

  • AcÄ«mredzamākais gadÄ«jums ir tad, ja jÅ«su serveris apstrādā ārkārtÄ«gi lielu skaitu vienlaikus aktÄ«vu savienojumu. Piemēram, ja jÅ«su conntrack tabula ir konfigurēta 128 128 ierakstiem, bet jums ir > XNUMX XNUMX vienlaicÄ«gu savienojumu, jÅ«s noteikti saskarsities ar problēmu!
  • Nedaudz mazāk acÄ«mredzams gadÄ«jums: ja jÅ«su serveris apstrādā ļoti lielu savienojumu skaitu sekundē. Pat ja savienojumi ir Ä«slaicÄ«gi, Linux tos turpina uzraudzÄ«t kādu laiku (pēc noklusējuma 120 s). Piemēram, ja jÅ«su conntrack tabula ir konfigurēta 128k ierakstiem un jÅ«s mēģināt apstrādāt 1100 savienojumus sekundē, tie pārsniegs conntrack tabulas lielumu, pat ja savienojumi ir ļoti Ä«slaicÄ«gi (128k/120s = 1092 savienojumi/ s).

Ir vairāki niÅ”as lietotņu veidi, kas ietilpst Å”ajās kategorijās. Turklāt, ja jums ir daudz slikto dalÄ«bnieku, servera conntrack tabulas aizpildÄ«Å”ana ar daudziem daļēji atvērtiem savienojumiem var tikt izmantota pakalpojuma atteikuma (DOS) uzbrukumā. Abos gadÄ«jumos conntrack var kļūt par ierobežojoÅ”u saÅ”aurinājumu jÅ«su sistēmā. Dažos gadÄ«jumos var pietikt ar conntrack tabulas parametru pielāgoÅ”anu, lai apmierinātu savas vajadzÄ«bas - palielinot izmēru vai samazinot conntrack taimautus (bet, ja to darÄ«sit nepareizi, jÅ«s saskarsities ar daudzām problēmām). Citos gadÄ«jumos bÅ«s nepiecieÅ”ams apiet conntrack agresÄ«vas satiksmes dēļ.

Reāls piemērs

Sniegsim konkrētu piemēru: vienam lielam SaaS pakalpojumu sniedzējam, ar kuru mēs sadarbojāmies, resursdatoros (nevis virtuālajās maŔīnās) bija vairāki atmiņai saglabāti serveri, no kuriem katrs apstrādāja 50 XNUMX+ Ä«stermiņa savienojumu sekundē.

Viņi eksperimentēja ar conntrack konfigurāciju, palielinot tabulu izmērus un samazinot izsekoÅ”anas laiku, taču konfigurācija nebija uzticama, ievērojami palielinājās RAM patēriņŔ, kas bija problēma (GBaitos!), un savienojumi bija tik Ä«si, ka conntrack nedarbojās. izveidot savu parasto veiktspējas ieguvumu (samazināts CPU patēriņŔ vai pakeÅ”u latentums).

Viņi vērsās pie Calico kā alternatÄ«vas. Calico tÄ«kla politikas ļauj neizmantot conntrack noteiktiem trafika veidiem (izmantojot politikas opciju doNotTrack). Tas nodroÅ”ināja viņiem nepiecieÅ”amo veiktspējas lÄ«meni, kā arÄ« papildu droŔības lÄ«meni, ko nodroÅ”ināja Calico.

Cik ilgi jums būs jāiet, lai apietu conntrack?

  • NeizsekoÅ”anas tÄ«kla politikām parasti jābÅ«t simetriskām. SaaS nodroÅ”inātāja gadÄ«jumā: viņu lietojumprogrammas darbojās aizsargātajā zonā, tāpēc, izmantojot tÄ«kla politiku, tās varēja baltajā sarakstā iekļaut datplÅ«smu no citām specifiskām lietojumprogrammām, kurām bija atļauta piekļuve memcached.
  • NeizsekoÅ”anas politika neņem vērā savienojuma virzienu. Tādējādi, ja keÅ”atmiņā saglabātais serveris ir uzlauzts, teorētiski varat mēģināt izveidot savienojumu ar jebkuru no atmiņā saglabātajiem klientiem, ja vien tas izmanto pareizo avota portu. Tomēr, ja esat pareizi definējis tÄ«kla politiku saviem atmiņā saglabātajiem klientiem, Å”ie savienojuma mēģinājumi joprojām tiks noraidÄ«ti klienta pusē.
  • NeizsekoÅ”anas politika tiek piemērota katrai paketei, atŔķirÄ«bā no parastajām politikām, kas tiek piemērotas tikai pirmajai plÅ«smas paketei. Tas var palielināt CPU patēriņu uz vienu paketi, jo politika ir jāpiemēro katrai paketei. Bet Ä«slaicÄ«giem savienojumiem Å”ie izdevumi tiek lÄ«dzsvaroti ar resursu patēriņa samazinājumu conntrack apstrādei. Piemēram, SaaS nodroÅ”inātāja gadÄ«jumā pakeÅ”u skaits katram savienojumam bija ļoti mazs, tāpēc papildu CPU patēriņŔ, piemērojot politikas katrai paketei, bija pamatots.

Sāksim testÄ“Å”anu

Mēs veicām testu vienā podā ar keÅ”atmiņā saglabātu serveri un vairākiem atmiņu keÅ”atmiņā saglabātiem klientu podiem, kas darbojas attālos mezglos, lai mēs varētu palaist ļoti lielu savienojumu skaitu sekundē. Serverim ar keÅ”atmiņā saglabāto servera podziņu conntrack tabulā (standarta konfigurētās tabulas izmērs resursdatoram) bija 8 kodoli un 512 XNUMX ieraksti.
Mēs izmērÄ«jām veiktspējas atŔķirÄ«bu starp: nav tÄ«kla politikas; ar regulāru Calico politiku; un Calico neizsekoÅ”anas politika.

Pirmajā testā mēs iestatÄ«jām savienojumu skaitu uz 4.000 sekundē, lai mēs varētu koncentrēties uz CPU patēriņa atŔķirÄ«bu. Nebija bÅ«tisku atŔķirÄ«bu starp politiku bez politikas un parasto politiku, taču neizsekojiet palielināto CPU patēriņu par aptuveni 20%.

Kad Linux conntrack vairs nav jūsu draugs

Otrajā testā mēs izveidojām tik daudz savienojumu, cik mÅ«su klienti varēja Ä£enerēt, un izmērÄ«jām maksimālo savienojumu skaitu sekundē, ko varēja apstrādāt mÅ«su keÅ”atmiņā saglabātais serveris. Kā gaidÄ«ts, ā€œbez politikasā€ un ā€œregulāras politikasā€ gadÄ«jumi sasniedza vairāk nekā 4,000 savienojumu sekundē (512 k / 120 s = 4,369 60,000 savienojumi/s). Izmantojot neizsekoÅ”anas politiku, mÅ«su klienti bez problēmām nosÅ«tÄ«ja XNUMX XNUMX savienojumu sekundē. Mēs esam pārliecināti, ka mēs varētu palielināt Å”o skaitu, pievienojot vairāk klientu, taču mēs uzskatām, ka Å”ie skaitļi jau ir pietiekami, lai ilustrētu Ŕī raksta bÅ«tÄ«bu!

Kad Linux conntrack vairs nav jūsu draugs

Secinājums

Conntrack ir svarÄ«ga kodola funkcija. Savu darbu viņŔ dara perfekti. To bieži izmanto galvenie sistēmas komponenti. Tomēr dažos konkrētos scenārijos sastrēgumi, kas raduÅ”ies kontrakta dēļ, pārsniedz parastos ieguvumus, ko tas sniedz. Å ajā scenārijā Calico tÄ«kla politikas var izmantot, lai selektÄ«vi atspējotu conntrack izmantoÅ”anu, vienlaikus palielinot tÄ«kla droŔību. Visai pārējai satiksmei conntrack joprojām ir jÅ«su draugs!

Lasiet arī citus rakstus mūsu emuārā:

Avots: www.habr.com

Pievieno komentāru