🥇 Kui Linux conntrack ei ole enam sõber

Ühenduste jälgimine („conntrack“) on Linuxi tuumastiku võrgu stack'i põhifunktsioon. See võimaldab tuumal jälgida kõiki loogilisi võrguühendusi või vooge ning seeläbi tuvastada kõik paketid, mis kuuluvad iga voolu, et neid saaks järjekindlalt ühiselt töödelda.

Conntrack on oluline tuumafunktsioon, mida kasutatakse mõnes peamises juhtumis:

NAT toetub conntrack'i teabele, et saaks kõiki sama voolu pakette võrdselt töödelda. Näiteks, kui pod pöördub Kubernetes'i teenuse poole, kasutab koormuse jaotaja kube-proxy NAT'i, et suunata liiklus konkreetse pod'i poole klastris. Conntrack salvestab, et teatud ühenduse korral peavad kõik teenuse IP-le saadetud paketid minema samasse pod'i ning et tagasipöördunud paketid backend pod'ilt peavad NAT'i kaudu olema suunatud tagasi pod'ile, kust pärines päring.
Olemasolevad oleku jälgimise tulemüüri lahendused, nagu Calico, tuginevad conntrack'i teabele, et lisada "vastus" liiklus valgesse nimekirja. See võimaldab teil kirjutada võrgu poliitika, mis ütleb: "luba minu pod'il ühenduda mis tahes kaug-IPsse" ilma vajaduseta kirjutada poliitikat vastusliiklusel selgelt lubamiseks. (Ilma selleta oleksite pidanud lisama palju vähem turvalise reegli "luba pakettide minu pod'ile igast IP-st.")

Lisaks suurendab conntrack tavaliselt süsteemi jõudlust (väheneb protsessori aja tarbimine ja paketide viivitus), kuna ainult esimene pakett voos
peab läbima kogu võrgu virna töötluse, et määrata, mida sellega edasi teha. Vaadake postitust "Kube-proxy režiimide võrdlemine", et näha näidet, kuidas see toimib.

Kuid conntrack'il on oma piirangud…

Nii et kus see kõik valesti läks?

Conntrack-tabelil on seadistatav maksimaalne suurus ja kui see on täis, hakkavad ühendused tavaliselt tagasi lükkuma või katki minema. Enamik rakendusi vajab tavaliselt vaid piisavalt ruumi ja see ei muutugi probleemiks. Siiski on mõned stsenaariumid, kus peaksite mõtlema conntrack-tabeli kasutamisele:

Kõige ilmsem juhtum on see, kui teie server töötleb erakordselt suurt hulka samal ajal aktiivseid ühendusi. Näiteks kui teie conntrack-tabel on seadistatud 128k kirje jaoks, kuid teil on > 128k samal ajal ühendusi, siis kindlasti kogete probleemi!
Veidi vähem ilmne juhtum: kui teie server töötab väga suure hulga ühendustega sekundis. Isegi kui ühendused on lühiajalised, jälgib Linux neid mingi aja jooksul (vaikimisi 120s). 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 neid mitmeid niširakenduste tüüpe, mis kuuluvad nende kategooriate alla. Kui teil on palju vaenlasi, siis võib teie serveri conntrack-tabeli täitmine poolavatud ühendustega olla osa teenuse keelamise (DOS) rünnakust. Mõlemas olukorras võib conntrack-aega olla teie süsteemis kitsaskohaks. Mõnel juhul piisab conntrack-tabeli parameetrite seadistamisest - suuruse suurendamine või ajakääride lühendamine võib teie vajadusi rahuldada (kuid kui teete selle valesti, võib see põhjustada suuri probleeme). Teistes olukordades on vajalik conntrack-i mööda pääseda agressiivse liikluse jaoks.

Tegelik näide

Toome konkreetselt välja: üks suur SaaS-teenusepakkuja, kellega me töötasime, omas mitmeid memcached-servereid füüsilistes hostides (mitte virtuaalmasinates), millest igaüks töötles üle 50 000 lühiajalist ühendust sekundis.

Nad eksperimenteerisid conntracki konfiguratsiooniga, suurendasid tabelite suurusi ja lühendasid jälgimisaja, kuid konfiguratsioon oli ebastabiilne, mille tulemusena suurenes mälukasutus märkimisväärselt (mitu gigabaiti!), ning seosed olid nii lühikesed, et conntrack ei suutnud saavutada oma tavapäraseid jõudluse eeliseid (protsessori tarbimise või paketilooduse vähenemine).

Alternatiivina pöördusid nad Calico poole. Calico võrgupoliitikad võimaldavad konkreetse liikluse tüübi osas conntracki mitte kasutada (kasutades poliitikate seadistamisel doNotTrack valikut). See tagas neile vajaliku jõudluse taseme koos täiendava turvalisusega, mida pakkus Calico.

Mille nimel tuleb conntracki ületamiseks vaeva näha?

Do-not-track võrgupoliitikad peavad tavaliselt olema sümmeetrilised. SaaS-teenusepakkuja puhul töötasid nende rakendused kaitstud tsoonis ja seetõttu said nad võrgupoliitika abil valge nimekirja lisada liiklust teistelt konkreetselt määratud rakendustelt, millele oli lubatud juurdepääs memcachedile.
Do-not-track poliitika ei arvesta ühenduse suunda. Seega, kui memcached-serverit rikutakse, võib teoorias proovida ühendust luua mistahes memcached-klientidega, kui need kasutavad õiget lähteportaali. Kuid kui olete õigesti määratlenud oma memcached-klientide võrgu poliitika, siis need ühenduse loomise katsed lükatakse ikkagi kliendi poolt tagasi.
Do-not-track poliitika kehtib igale paketile, erinevalt tavalistest poliitikutest, mis kehtivad ainult voogude esimeses paketis. See võib suurendada CPU ressursikulu ühes paketis, kuna iga paketi jaoks tuleb poliitika rakendada. Kuid lühiajaliste ühenduste puhul tasakaalustatakse see ressursside kulu vähenemisega, mis on seotud conntracki töötlemisega. Näiteks, SaaS-teenuse pakkuja puhul oli igaühenduse paketihulk väga väike, seega oli täiendav CPU ressursside kulu poliitikate rakendamisel igale paketile põhjendatud.

Alustame testidega

Vi viisime läbi testi ühe pod'i, mis sisaldas memcached-serverit ja mitmeid memcached-kliendi pod'e, mis töötasid eemal asuvates sõlmedes, et saaksime luua väga suure arvu ühendusi sekundis. Memcached-serveri pod'il oli 8 tuuma ja 512k kirjet conntrack tabelis (standardne tabeli suurus hosti jaoks).
Mõõtsime jõudluse erinevust järgmiste vahel: ilma võrgu poliitikata; tavalise Calico poliitikaga; ja Calico do-not-track poliitikaga.

Esimese testi jaoks seadsime ühenduste arvu 4.000 sekundi kohta, et saaksime keskenduda CPU tarbimise erinevusele. Siin ei olnud olulisi erinevusi poliitika puudumise ja tava poliitika vahel, kuid do-not-track tõstis CPU tarbimist umbes 20% võrra.

Teises testis käivitasime nii palju ühendusi, kui meie kliendid suudavad genereerida, ja mõõtsime maksimaalset ühenduste arvu sekundis, mida meie memcached-server suudab töödelda. Nagu oodata võis, saavutasid 'ilma poliitikateta' ja 'tavalise poliitika' puhul mõlemad conntracki piiri, ületades 4000 ühendust sekundis (512k / 120s = 4369 ühendust/s). 'Do-not-track' poliitikaga saatsid meie kliendid 60,000 ühendust sekundis ilma igasuguste probleemideta. Oleme kindlad, et võiksime seda numbrit suurendada, ühendades rohkem kliente, kuid arvame, et need numbrid on juba piisavad, et illustreerida selle artikli sõnumit!

Kokkuvõte

Conntrack on oluline funktsioon kernelis. See täidab oma ülesannet suurepäraselt. Sageli kasutavad seda süsteemi peamised komponendid. Kuid teatud stsenaariumites võivad conntracki tõttu tekkivad ülekoormused kaaluda üles tavapärased eelised, mida see pakub. Sellises stsenaariumis saab Calico võrgu poliitikaid kasutada, et valikuliselt keelata conntracki kasutamine, samal ajal suurendades võrgu turvalisust. Kõikjal mujal liikluses jääb conntrack siiski teie sõbraks!