Yhteyden seuranta ("conntrack") on Linux-ytimen verkkopinon ydinominaisuus. Sen avulla ydin voi seurata kaikkia loogisia verkkoyhteyksiä tai -virtoja ja siten tunnistaa kaikki paketit, jotka muodostavat kunkin vuon, jotta ne voidaan käsitellä yhdessä peräkkäin.
Conntrack on tärkeä ytimen ominaisuus, jota käytetään joissakin perustapauksissa:
- NAT luottaa conntrackin tietoihin, jotta se voi käsitellä kaikkia paketteja samasta virrasta samalla tavalla. Esimerkiksi kun pod käyttää Kubernetes-palvelua, kube-välityspalvelimen kuormituksen tasapainottaja käyttää NAT:ta liikenteen ohjaamiseen tiettyyn klusterin podiin. Conntrack tallentaa, että tiettyä yhteyttä varten kaikki IP-palvelun paketit on lähetettävä samaan podiin ja että taustayksikön palauttamat paketit on NAToitava takaisin podiin, josta pyyntö tuli.
- Tilalliset palomuurit, kuten Calico, luottavat tietoihin yhteysradasta ja sallivat vastausliikenteen. Tämän avulla voit kirjoittaa verkkokäytännön, joka sanoo "salli podini muodostaa yhteys mihin tahansa IP-etäosoitteeseen" ilman, että sinun tarvitsee kirjoittaa käytäntöä, joka sallii vastausliikenteen. (Ilman tätä sinun olisi lisättävä paljon vähemmän turvallinen "salli paketit kotelooni mistä tahansa IP-osoitteesta" -sääntö.)
Lisäksi conntrack tyypillisesti parantaa järjestelmän suorituskykyä (vähentämällä suorittimen kulutusta ja pakettien viivettä), koska vain ensimmäinen paketti streamissa
täytyy käydä läpi koko verkkopino määrittääkseen, mitä sille tehdään. Katso viesti "" nähdäksesi esimerkin siitä, kuinka tämä toimii.
Conntrackilla on kuitenkin rajoituksensa...
Joten missä kaikki meni pieleen?
Conntrack-taulukolla on konfiguroitavissa oleva maksimikoko, ja jos se täyttyy, yhteyksiä yleensä aletaan hylätä tai katkaista. Taulukossa on tarpeeksi vapaata tilaa useimpien sovellusten liikenteen käsittelemiseen, eikä tästä tule koskaan ongelmia. On kuitenkin olemassa muutamia tilanteita, joissa sinun kannattaa harkita conntrack-taulukon käyttöä:
- Ilmeisin tapaus on, jos palvelimesi käsittelee erittäin suurta määrää samanaikaisesti aktiivisia yhteyksiä. Esimerkiksi jos conntrack-taulukkosi on määritetty 128 128 merkinnälle, mutta sinulla on > XNUMX XNUMX samanaikaisia yhteyksiä, kohtaat varmasti ongelman!
- Hieman vähemmän ilmeinen tapaus: jos palvelimesi käsittelee erittäin suuren määrän yhteyksiä sekunnissa. Vaikka yhteydet ovat lyhytikäisiä, Linux valvoo niitä edelleen jonkin aikaa (oletusarvoisesti 120 sekuntia). Jos yhteystaulukkosi on esimerkiksi määritetty 128 1100 merkinnälle ja yrität käsitellä 128 yhteyttä sekunnissa, ne ylittävät conntrack-taulukon koon, vaikka yhteydet olisivat hyvin lyhytaikaisia (120k/1092s = XNUMX yhteyttä/ s).
Näihin luokkiin kuuluu useita niche-tyyppisiä sovelluksia. Lisäksi, jos sinulla on paljon huonoja toimijoita, palvelimesi conntrack-taulukon täyttämistä monilla puoliavoimilla yhteyksillä voidaan käyttää osana palvelunestohyökkäystä (DOS). Molemmissa tapauksissa conntrack voi muodostua rajoittavaksi pullonkaulaksi järjestelmässäsi. Joissakin tapauksissa conntrack-taulukon parametrien säätäminen voi riittää vastaamaan tarpeitasi - lisäämällä kokoa tai vähentämällä conntrack-aikakatkaisuja (mutta jos teet sen väärin, joudut paljon vaikeuksiin). Muissa tapauksissa aggressiivisen liikenteen vuoksi on välttämätöntä ohittaa rata.
Todellinen esimerkki
Otetaan konkreettinen esimerkki: yhdellä suurella SaaS-palveluntarjoajalla, jonka kanssa työskentelimme, oli isännillä (ei virtuaalikoneilla) useita muistivälimuistiin tallennettuja palvelimia, joista jokainen käsitteli yli 50 XNUMX lyhytaikaista yhteyttä sekunnissa.
He kokeilivat conntrack-kokoonpanoa, suurentamalla taulukkokokoja ja lyhentäen seuranta-aikaa, mutta konfiguraatio oli epäluotettava, RAM-muistin kulutus kasvoi merkittävästi, mikä oli ongelma (suuruusluokkaa gigatavua!), ja yhteydet olivat niin lyhyitä, että conntrack ei toiminut. luo sen tavanomaisen suorituskykyedun (pienempi kulutus CPU tai pakettiviive).
Vaihtoehtona he kääntyivät Calicon puoleen. Calicon verkkokäytäntöjen avulla voit olla käyttämättä conntrack-toimintoa tietyntyyppisissä liikenteissä (käyttäen doNotTrack-käytäntövaihtoehtoa). Tämä antoi heille tarvitsemansa suorituskyvyn sekä Calicon tarjoaman lisäturvatason.
Mihin pituuksiin sinun on mentävä ohittaaksesi conntrackin?
- Älä seuraa verkkokäytäntöjen tulisi yleensä olla symmetrisiä. SaaS-palveluntarjoajan tapauksessa: heidän sovelluksensa toimivat suojatulla vyöhykkeellä, ja siksi he pystyivät verkkokäytäntöä käyttämällä sallimaan liikenteen muista tietyistä sovelluksista, joilla oli pääsy välimuistiin.
- Älä seuraa -käytäntö ei ota huomioon yhteyden suuntaa. Jos siis välimuistissa oleva palvelin on hakkeroitu, voit teoriassa yrittää muodostaa yhteyden mihin tahansa välimuistissa oleviin asiakkaisiin, kunhan se käyttää oikeaa lähdeporttia. Jos olet kuitenkin määrittänyt verkkokäytännön oikein memcached-asiakkaillesi, nämä yhteysyritykset hylätään silti asiakaspuolella.
- Älä seuraa -käytäntöä sovelletaan jokaiseen pakettiin, toisin kuin normaaleissa käytännöissä, joita sovelletaan vain kulun ensimmäiseen pakettiin. Tämä voi lisätä prosessorin kulutusta pakettia kohden, koska käytäntöä on sovellettava jokaiseen pakettiin. Mutta lyhytaikaisissa yhteyksissä tämä kustannus tasapainotetaan yhteydenkäsittelyn resurssien kulutuksen vähenemisellä. Esimerkiksi SaaS-palveluntarjoajan tapauksessa pakettien määrä kullekin yhteydelle oli hyvin pieni, joten prosessorin lisäkulutus kullekin paketille sovellettaessa oli perusteltua.
Aloitetaan testaus
Suoritimme testin yhdellä podilla, jossa oli välimuistissa oleva palvelin ja useita välimuistissa olevia asiakasryhmiä etäsolmuissa, jotta pystyimme ajamaan erittäin suuren määrän yhteyksiä sekunnissa. Palvelimella, jossa oli välimuistiin tallennettu palvelinpodikko, oli 8 ydintä ja 512 XNUMX merkintää conntrack-taulukossa (isäntäkoneen vakiomääritetty taulukkokoko).
Mittasimme suorituskyvyn eron seuraavien välillä: ei verkkopolitiikkaa; säännöllisen Calico-politiikan kanssa; ja Calico do not-track -käytäntö.
Ensimmäistä testiä varten asetimme yhteyksien määräksi 4.000 20 sekunnissa, jotta voimme keskittyä prosessorin kulutuksen eroihin. Ei-käytännön ja tavallisen politiikan välillä ei ollut merkittäviä eroja, mutta et-seuraa lisääntynyttä suorittimen kulutusta noin XNUMX %:
Toisessa testissä käynnistimme niin monta yhteyttä kuin asiakkaamme pystyivät luomaan ja mittasimme yhteyksien enimmäismäärän sekunnissa, jonka muistivälimuistipalvelimemme pystyi käsittelemään. Kuten odotettiin, "ei politiikkaa" ja "normaali politiikka" -tapaukset saavuttivat molemmat yli 4,000 512 yhteyden sekunnissa yhteysrajan (120 t / 4,369 s = 60,000 XNUMX yhteyttä/s). Älä seuraa -käytännöllä asiakkaamme lähettivät XNUMX XNUMX yhteyttä sekunnissa ilman ongelmia. Voisimme varmasti lisätä tätä määrää lisäämällä asiakkaita, mutta mielestämme nämä luvut ovat jo riittävät havainnollistamaan tämän artikkelin pointtia!
Johtopäätös
Conntrack on tärkeä ytimen ominaisuus. Hän tekee työnsä täydellisesti. Sitä käyttävät usein järjestelmän keskeiset komponentit. Joissakin erityisissä skenaarioissa liikenteen aiheuttama ruuhka on kuitenkin suurempi kuin sen tarjoamat normaalit hyödyt. Tässä skenaariossa Calicon verkkokäytäntöjä voidaan käyttää estämään valikoivasti conntrackin käyttö ja lisäämään verkon turvallisuutta. Kaikessa muussa liikenteessä conntrack on edelleen ystäväsi!
Lue myös muut artikkelit blogistamme:
Lähde: will.com