Ühenduse jälgimine („conntrack“) on Linuxi tuuma võrgustiku virna peamine funktsioon. See võimaldab tuumal jälgida kõiki loogilisi võrguühendusi või vooge ja seeläbi tuvastada kõik paketid, mis moodustavad iga vooge, et neid saaks järjestikuste töötlemiseks kokku koguda.
Conntrack on oluline tuuma funktsioon, mida kasutatakse mitmetes põhijuhtumites:
- NAT toetub conntrack'i teabele, võimaldades tal töödelda kõiki pakette ühest voogust ühtemoodi. Näiteks kui pod pöördub Kubernetes’e teenuse poole, kasutab kube-proxy koormuse tasakaalustaja NAT-i, et suunata liiklust konkreetse pod’i poole klastris. Conntrack salvestab, et teatud ühenduse korral tuleb kõik teenuse IP aadressile saadetud paketid suunata samasse pod'i, ning et tagasi saadetavad paketid backend'i pod'ist peavad NAT’i kaudu liikuma tagasi pod'i, kust pärines päring.
- Riistvara tulemüürid, nagu Calico, toetuvad conntrack'i teabele, et lisada „vastutav“ liiklus lubatud nimekirja. See võimaldab teil koostada võrgu poliitika, mis ütleb: „luba minu pod’il ühenduda mis tahes kaug- IP aadressiga“, ilma et oleks vaja kirjutada poliitikat vastutava liikluse selgeks lubamiseks. (Ilma selleta peaksite lisama palju vähem turvalise reegli „luba pakette minu pod'i mistahes IP-lt“.)
Lisaks tõstab conntrack tavaliselt süsteemi jõudlust (vähendades protsessori aega ja paketidelay'd), kuna ainult esimene paket voos
peab läbima kogu võrgu virna töötlemise, et määrata, mida selle paketiga teha. Vaadake postitust „“, et näha näidet, kuidas see töötab.
Siiski on conntrack'il oma piirangud...
Nii et kus kõik valesti läks?
Conntrack'i tabelil on kohandatav maksimaalne suurus ja kui see täitub, hakkavad ühendused tavaliselt tõrkeid või katkestusi saama. Enamiku rakenduste liikluse töötlemiseks piisab tabelis vabast ruumist ega muutu kunagi probleemiks. Siiski on mitmeid stsenaariume, kus tasub mõelda conntrack'i tabeli kasutamisele:
- Ilmselt kõige silmatorkavam juhtum on see, kui teie server käsitleb erakordselt suurt arvu samal ajal aktiivseid ühendusi. Näiteks, kui teie conntrack tabel on seadistatud 128k kirje jaoks, kuid teil on > 128k samaaegset ühendust, siis kindlasti seisate silmitsi probleemiga!
- Veidi vähem ilmne juhtum: kui teie server käsitleb väga suurt arvu ühendusi sekundis. Isegi kui ühendused on lühiajalised, jälgib Linux neid teatud aja jooksul (vaikimisi 120 s). Näiteks, kui teie conntrack tabel on seadistatud 128 000 kirje jaoks ja proovite töödelda 1100 ühendust sekundis, ületavad need conntrack tabeli suurust, isegi kui ühendused on väga lühiajalised (128k / 120s = 1092 ühendust / s).
On mitmeid nišityype rakendusi, mis kuuluvad nende kategooriate alla. Lisaks, kui teil on palju pahatahtlikke isikuid, võib teie serveri conntrack tabeli täitmine paljude poolavatud ühendustega olla osa teenusetõkestamise (DoS) rünnakust. Mõlemal juhul võib conntrack teie süsteemis kitsaskohaks kujuneda. Mõnel juhul võib conntrack tabeli parameetrite seadistamine olla piisav, et rahuldada teie vajadusi - suurendades suurust või vähendades conntrack ajakulu (kuid kui teete seda valesti, võib teil olla suuri raskusi). Teistel juhtudel tuleb aggressiivse liikluse jaoks conntrackist ümber minna.
Reaalne näide
Toome konkreetsena näite: üks suur SaaS teenusepakkuja, kellega me töötasime, omas mitmeid memcached servereid hostides (mitte virtuaalmasinates), kus igaüks töötles 50k+ lühiajalist ühendust sekundis.
Nad katsetasid conntrack konfiguratsiooni, suurendades tabelite suurusi ja lühendades jälgimisaega, kuid konfiguratsioon oli ebastabiilne, oluliselt suurenes mälutarbimine, mis oli probleem (ühe GiB-i ulatuses!), ja ühendused olid nii lühikesed, et conntrack ei saavutanud oma tavalist tulemuse kasu (protsessori tarbimise vähenemine ega pakettide viivitused).
Alternatiivina pöördusid nad Calico poole. Calico võrgupoliitikad võimaldavad mitte kasutada conntrack'i teatud tüüpi liikluse jaoks (kasutades poliitikate jaoks valikut doNotTrack). See tagas neile vajaliku jõudluse taseme pluss täiendava turvalisuse taseme, mida pakkus Calico.
Milleks peate minema, et vältida conntrack'i?
- Do-not-track võrgupoliitikad peavad reeglina olema sümmeetrilised. SaaS-teenuse pakkuja puhul: nende rakendused töötasid kaitstud tsoonis ja seetõttu said nad võrgupoliitika abil lisada valge nimekirja liiklust teistelt konkreetsetelt rakendustelt, millele anti juurdepääs memcached'ile.
- Do-not-track poliitika ei arvestanud ühenduse suunda. Seega, kui memcached-serverit rünnatakse, võib teoreetiliselt proovida ühendust luua mis tahes memcached-klientiga, juhul kui see kasutab õiget algusporta. Kuid kui olete õigesti määratlenud oma memcached-klientide jaoks võrgupoliitika, siis need ühenduse loomise katsetused lükatakse ikkagi kliendi poole tagasi.
- Do-not-track poliitika rakendatakse iga paketi puhul, erinevalt tavapärastest poliitikatest, mis kehtivad ainult voolu esimeses paketis. See võib suurendada CPU ressursikasutust ühe paketi kohta, kuna iga paketi puhul tuleb rakendada poliitika. Kuid lühiajaliste ühenduste puhul tasakaalustatakse see ressursside kasutuse vähenemisega conntrack'i töötlemisel. Näiteks SaaS-teenuse pakkuja puhul oli iga ühenduse pakettide arv väga väike, mistõttu oli CPU liikluses poliitikate rakendamise täiendav ressursside kasutamine õigustatud.
Hakkame testima
Me viisime testi läbi ühes pod'is memcached-serveriga ja paljude memcached-klientide pod'idega, mis töötasid kaugrežiimis, et saaksime sekundis luua väga suure arvu ühendusi. Memcached-serveri pod'il oli 8 tuuma ja 512k kirjet conntrack'i tabelis (standardselt seadistatud tabeli suurus hosti jaoks).
Mõõtsime jõudluse erinevust: ilma võrgupoliitikata; tavalise Calico poliitikaga; ja Calico do-not-track poliitikaga.
Esimese testi jaoks seadsime ühenduste arvu 4000 sekundis, seega saime keskenduda CPU tarbimise erinevusele. Poliitika puudumisel ja tavalise poliitika vahel ei olnud olulisi erinevusi, kuid do-not-track suurendas CPU tarbimist umbes 20% võrra:
Teises testis käivitasime nii palju ühendusi, kui suutsid genereerida meie kliendid, ja mõõtsime maksimaalset ühenduste arvu sekundis, mis meie memcached-server suutis taluda. Nagu oodata võis, saavutasid nii 'ilma poliitikateta' kui ka 'tavalise poliitikaga' mõlemad conntracki piiri üle 4000 ühenduse sekundis (512k / 120s = 4369 ühendust/s). Do-not-track poliitikaga saatsid meie kliendid 60000 ühendust sekundis ilma probleemideta. Oleme kindlad, et oleksime suutnud seda arvu suurendada, ühendades rohkem kliente, kuid usume, et need numbrid on juba piisavad, et illustreerida selle artikli sõnumit!
Kokkuvõte
Conntrack on oluline funktsioon kernelis. See täidab oma ülesande suurepäraselt. Seda kasutavad sageli süsteemi võtmekomponendid. Siiski, teatud olukordades võib ülekoormus, mis tuleneb conntrackist, ületada tavalised eelised, mida see pakub. Antud juhul saavad Calico võrgupoliitikad olla kasutatud, et valikuliselt keelata conntracki kasutamine, samal ajal kui suurendatakse võrgu turvalisust. Kõik muu liiklus jätkab conntrackiga koostööd!
Vaata ka teisi artikleid meie blogis:
Allikas: habr.com
