Konektspurado ("conntrack") estas kerna funkcio de la Linukso-kerna retstako. Ĝi permesas al la kerno konservi trakon de ĉiuj logikaj retkonektoj aŭ fluoj kaj tiel identigi ĉiujn pakaĵetojn kiuj konsistigas ĉiun fluon tiel ke ili povas esti prilaboritaj kune sinsekve.
Conntrack estas grava kerntrajto, kiu estas uzata en iuj bazaj kazoj:
- NAT dependas de informoj de conntrack tiel ĝi povas trakti ĉiujn pakaĵetojn de la sama rivereto egale. Ekzemple, kiam pod aliras Kubernetes-servon, la kube-proxy-ŝarĝbalancilo uzas NAT por direkti trafikon al specifa pod ene de la areto. Conntrack registras ke por antaŭfiksita konekto, ĉiuj pakaĵetoj al la IP-servo devas esti senditaj al la sama pod, kaj ke pakaĵetoj resenditaj de la malantaŭa pod devas esti NATigitaj reen al la pod de kiu la peto venis.
- Ŝtataj fajroŝirmiloj kiel Calico dependas de informoj de connecttrack al blanklista "responda" trafiko. Ĉi tio permesas al vi verki retan politikon, kiu diras "permesu al mia pod konektiĝi al iu malproksima IP-adreso" sen devi skribi politikon por eksplicite permesi respondtrafikon. (Sen ĉi tio, vi devus aldoni la multe malpli sekuran "permesi pakaĵetojn al mia pod de ajna IP" regulo).
Plie, conntrack tipe plibonigas sisteman rendimenton (reduktante CPU-konsumon kaj pakaĵetan latentecon) ekde nur la unua pakaĵeto en rivereto.
devas trairi la tutan retan stakon por determini kion fari kun ĝi. Vidu la afiŝon "" por vidi ekzemplon pri kiel ĝi funkcias.
Tamen, conttrack havas siajn limojn...
Do kie ĉio misfunkciis?
La conntrack-tabelo havas agordeblan maksimuman grandecon, kaj se ĝi pleniĝas, ligoj kutime komencas esti malakceptitaj aŭ forigitaj. Estas sufiĉe libera spaco en la tabelo por trakti la trafikon de plej multaj aplikoj, kaj ĉi tio neniam fariĝos problemo. Tamen, ekzistas kelkaj scenaroj, en kiuj vi eble volas konsideri uzi la konttrack-tabelon:
- La plej evidenta kazo estas se via servilo pritraktas ege grandan nombron da samtempe aktivaj konektoj. Ekzemple, se via conntrack-tabelo estas agordita por 128k enskriboj, sed vi havas >128k samtempajn konektojn, vi certe renkontos problemon!
- Iomete malpli evidenta kazo: se via servilo prilaboras tre grandan nombron da konektoj sekundo. Eĉ se la konektoj estas mallongdaŭraj, ili daŭre estas kontrolataj de Linukso dum iom da tempo (120s defaŭlte). Ekzemple, se via conntrack-tabelo estas agordita por 128k enskriboj kaj vi provas pritrakti 1100 konektojn je sekundo, ili superos la grandecon de la conntrack-tabelo, eĉ se la konektoj estas tre mallongdaŭraj (128k/120s = 1092 konektoj/ s).
Estas pluraj niĉaj specoj de programoj, kiuj falas en ĉi tiujn kategoriojn. Aldone, se vi havas multajn malbonajn aktoroj, plenigi la kontraktabelon de via servilo kun multaj duonmalfermaj konektoj povus esti uzata kiel parto de nea servo (DOS) atako. En ambaŭ kazoj, conntrack povas fariĝi limiga proplemkolo en via sistemo. En iuj kazoj, ĝustigi la parametrojn de la tabelo de conntrack povas sufiĉi por kontentigi viajn bezonojn - pliigante la grandecon aŭ reduktante la tempodaŭrojn de conntrack (sed se vi faras ĝin malĝuste, vi havos multajn problemojn). Por aliaj kazoj estos necese preteriri konntrack por agresema trafiko.
Vera ekzemplo
Ni donu specifan ekzemplon: unu granda SaaS-provizanto kun kiu ni laboris havis kelkajn memcached-servilojn sur gastigantoj (ne virtualaj maŝinoj), ĉiu el kiuj prilaboris 50K+ mallongperspektivajn konektojn sekundo.
Ili eksperimentis kun la konntrack-agordo, pliigante tabelgrandecojn kaj reduktante spurtempon, sed la agordo estis nefidinda, la RAM-konsumo pliiĝis signife, kio estis problemo (sur la ordo de GBytes!), kaj la ligoj estis tiel mallongaj ke conntrack ne faris. krei ĝian kutiman rendimentan avantaĝon (reduktita konsuma CPU aŭ paka latenco).
Ili turnis sin al Calico kiel alternativo. Calico-retaj politikoj permesas vin ne uzi conntrack por certaj specoj de trafiko (uzante la doNotTrack-politikopcion). Ĉi tio donis al ili la nivelon de efikeco kiun ili bezonis, kaj plie la aldonitan nivelon de sekureco disponigita fare de Calico.
Al kiom da distancoj vi devos iri por preteriri kontrantrakon?
- Ne-spuraj retaj politikoj ĝenerale devus esti simetriaj. En la kazo de la provizanto SaaS: iliaj aplikoj funkciis ene de protektita zono kaj tial, uzante retan politikon, ili povis enlistigi trafikon de aliaj specifaj aplikoj kiuj estis permesitaj aliro al memcached.
- La politiko pri ne spuri ne konsideras la direkton de la konekto. Tiel, se la memcached-servilo estas hakita, vi povas teorie provi konektiĝi al iu ajn el la memcached-klientoj, kondiĉe ke ĝi uzas la ĝustan fontan havenon. Tamen, se vi ĝuste difinis la retan politikon por viaj memcached-klientoj, tiam ĉi tiuj konektoprovoj ankoraŭ estos malakceptitaj ĉe la kliento.
- La politiko de ne-spuro estas aplikata al ĉiu pakaĵeto, kontraste al normalaj politikoj, kiuj estas aplikataj nur al la unua pakaĵeto en fluo. Ĉi tio povas pliigi la CPU-konsumon per pako ĉar la politiko devas esti aplikata por ĉiu pako. Sed por mallongdaŭraj konektoj, ĉi tiu elspezo estas ekvilibrigita de la redukto de la konsumo de rimedoj por la pretigo de kontraŭtraka. Ekzemple, en la kazo de SaaS-provizanto, la nombro da pakoj por ĉiu konekto estis tre malgranda, do la kroma CPU-konsumo dum aplikado de politikoj al ĉiu pako estis pravigita.
Ni komencu testi
Ni kuris la teston sur ununura pod kun memcached servilo kaj pluraj memcached kliento pods kurantaj sur foraj nodoj por ke ni povus ruli tre grandan nombron da konektoj sekundo. La servilo kun la memcached servilo-podo havis 8 kernojn kaj 512k enirojn en la kontrack-tabelo (la norma agordita tabelgrandeco por la gastiganto).
Ni mezuris la rendimentan diferencon inter: neniu retopolitiko; kun regula Calico-politiko; kaj Calico-ne-spuri politikon.
Por la unua testo, ni fiksis la nombron da konektoj al 4.000 sekundo, do ni povus koncentriĝi pri la diferenco en CPU-konsumo. Ne estis signifaj diferencoj inter neniu politiko kaj regula politiko, sed ne-spuri pliigitan CPU-konsumon je ĉirkaŭ 20%:
En la dua provo, ni lanĉis tiom da konektoj kiom niaj klientoj povis generi kaj mezuris la maksimuman nombron da konektoj je sekundo, kiujn nia memcached-servilo povis manipuli. Kiel atendite, la kazoj de "neniu politiko" kaj "regula politiko" ambaŭ atingis la kontraŭtraklimon de pli ol 4,000 konektoj je sekundo (512k / 120s = 4,369 konektoj/s). Kun politiko pri ne-spurado, niaj klientoj sendis 60,000 XNUMX konektojn sekundo sen problemoj. Ni certas, ke ni povus pliigi ĉi tiun nombron aldonante pli da klientoj, sed ni sentas, ke ĉi tiuj nombroj jam sufiĉas por ilustri la punkton de ĉi tiu artikolo!
konkludo
Conntrack estas grava kerna trajto. Li faras sian laboron perfekte. Ĝi estas ofte uzata de ŝlosilaj sistemkomponentoj. Tamen, en iuj specifaj scenaroj, la obstrukciĝo pro conntrack superas la normalajn avantaĝojn kiujn ĝi provizas. En ĉi tiu scenaro, Calico-retaj politikoj povas esti uzataj por selekteme malŝalti la uzon de conttrack dum pliigas retan sekurecon. Por ĉiu alia trafiko, contrack daŭre estas via amiko!
Legu ankaŭ aliajn artikolojn en nia blogo:
fonto: www.habr.com