Ufuatiliaji wa muunganisho ("conntrack") ni kipengele cha msingi cha safu ya mitandao ya Linux kernel. Huruhusu kernel kufuatilia miunganisho yote ya mtandao yenye mantiki au mtiririko na kwa hivyo kutambua pakiti zote zinazounda kila mtiririko ili ziweze kuchakatwa pamoja kwa kufuatana.
Contrack ni kipengele muhimu cha kernel ambacho hutumiwa katika hali zingine za kimsingi:
- NAT inategemea habari kutoka kwa ushawishi ili iweze kushughulikia pakiti zote kutoka kwa mkondo mmoja kwa usawa. Kwa mfano, ganda linapofikia huduma ya Kubernetes, kisawazisha cha kubeba proksi hutumia NAT kuelekeza trafiki kwenye ganda maalum ndani ya nguzo. Rekodi za Conntrack kwamba kwa muunganisho fulani, pakiti zote kwenye huduma ya IP lazima zitumwe kwenye ganda moja, na kwamba pakiti zilizorejeshwa na ganda la nyuma lazima NATed kurudishwa kwenye ganda ambalo ombi lilitoka.
- Ngome halali kama vile Calico hutegemea maelezo kutoka kwa kiunganishi hadi trafiki ya "majibu" ya orodha iliyoidhinishwa. Hii hukuruhusu kuandika sera ya mtandao inayosema "ruhusu pod yangu kuunganishwa kwa anwani yoyote ya mbali ya IP" bila kulazimika kuandika sera ili kuruhusu trafiki ya majibu kwa uwazi. (Bila hii, itabidi uongeze salama zaidi "ruhusu pakiti kwenye ganda langu kutoka kwa sheria yoyote ya IP".)
Zaidi ya hayo, uingiliaji kwa kawaida huboresha utendakazi wa mfumo (kwa kupunguza matumizi ya CPU na ucheleweshaji wa pakiti) kwani ni pakiti ya kwanza pekee katika mtiririko.
lazima upitie rundo lote la mtandao ili kubaini la kufanya nalo. Angalia chapisho "" kuona mfano wa jinsi hii inavyofanya kazi.
Walakini, contracking ina mapungufu yake ...
Kwa hivyo yote yalienda vibaya wapi?
Jedwali la mgongano lina ukubwa wa juu unaoweza kusanidiwa, na ikiwa imejaa, miunganisho kawaida huanza kukataliwa au kupunguzwa. Kuna nafasi ya kutosha kwenye jedwali kushughulikia trafiki ya programu nyingi, na hii haitakuwa shida kamwe. Walakini, kuna hali chache ambazo unaweza kutaka kuzingatia kutumia jedwali la ushawishi:
- Kesi iliyo wazi zaidi ni ikiwa seva yako inashughulikia idadi kubwa sana ya miunganisho inayotumika kwa wakati mmoja. Kwa mfano, ikiwa jedwali lako la uingiliaji limesanidiwa kwa maingizo 128k, lakini una > miunganisho ya wakati mmoja 128k, hakika utakumbana na tatizo!
- Kesi isiyo dhahiri kidogo: ikiwa seva yako itachakata idadi kubwa sana ya viunganisho kwa sekunde. Hata kama miunganisho ni ya muda mfupi, inaendelea kufuatiliwa na Linux kwa muda fulani (miaka 120 kwa chaguo-msingi). Kwa mfano, ikiwa meza yako ya uingiliaji imesanidiwa kwa maingizo 128k na unajaribu kushughulikia miunganisho 1100 kwa sekunde, itazidi saizi ya jedwali la uingiliaji hata kama viunganisho ni vya muda mfupi sana (128k/120s = 1092 miunganisho/s). )
Kuna aina kadhaa za programu ambazo ziko katika kategoria hizi. Zaidi ya hayo, ikiwa una watendaji wengi wabaya, kujaza jedwali la uingiliano la seva yako na miunganisho mingi iliyofunguliwa nusu inaweza kutumika kama sehemu ya shambulio la kunyimwa huduma (DOS). Katika visa vyote viwili, uingiliaji unaweza kuwa kizuizi katika mfumo wako. Katika baadhi ya matukio, kurekebisha vigezo vya meza ya conntrack inaweza kuwa ya kutosha ili kukidhi mahitaji yako - kwa kuongeza ukubwa au kupunguza muda wa conntrack (lakini ikiwa utafanya vibaya, utaingia kwenye shida nyingi). Kwa kesi nyingine itakuwa muhimu kukwepa contrack kwa trafiki fujo.
Mfano halisi
Hebu tutoe mfano maalum: mtoa huduma mmoja mkubwa wa SaaS tuliyefanya kazi naye alikuwa na idadi ya seva zilizohifadhiwa kwenye seva pangishi (sio mashine pepe), ambayo kila moja ilichakata miunganisho ya muda mfupi ya 50K+ kwa sekunde.
Walijaribu usanidi wa conntrack, kuongeza ukubwa wa meza na kupunguza muda wa kufuatilia, lakini usanidi haukuaminika, matumizi ya RAM yaliongezeka kwa kiasi kikubwa, ambayo ilikuwa tatizo (kwa utaratibu wa GBytes!), Na viunganisho vilikuwa vifupi sana kwamba conntrack haikufanya. kuunda manufaa yake ya kawaida ya utendakazi (CPU iliyopunguzwa ya matumizi au utulivu wa pakiti).
Waligeukia Calico kama njia mbadala. Sera za mtandao za Calico hukuruhusu usitumie udhibiti kwa aina fulani za trafiki (kwa kutumia chaguo la sera ya doNotTrack). Hii iliwapa kiwango cha utendakazi waliohitaji, pamoja na kiwango cha ziada cha usalama kilichotolewa na Calico.
Je, utalazimika kwenda kwa urefu gani ili kukwepa ulanguzi?
- Sera za mtandao za usifuatilie kwa ujumla zinapaswa kuwa linganifu. Kwa upande wa mtoa huduma wa SaaS: maombi yao yaliendeshwa ndani ya eneo lililolindwa na kwa hivyo, kwa kutumia sera ya mtandao, wanaweza kuorodhesha trafiki kutoka kwa programu zingine mahususi ambazo ziliruhusiwa ufikiaji wa memcached.
- Sera ya usifuatilie haizingatii mwelekeo wa muunganisho. Kwa hivyo, ikiwa seva ya memcached imedukuliwa, unaweza kujaribu kinadharia kuunganisha kwa mteja wowote uliohifadhiwa, mradi tu itumie mlango wa chanzo sahihi. Hata hivyo, ikiwa umefafanua kwa usahihi sera ya mtandao kwa wateja wako waliohifadhiwa kwenye kumbukumbu, basi majaribio haya ya kuunganisha bado yatakataliwa kwa upande wa mteja.
- Sera ya usifuatilie inatumika kwa kila pakiti, kinyume na sera za kawaida, ambazo hutumika tu kwa pakiti ya kwanza katika mtiririko. Hii inaweza kuongeza matumizi ya CPU kwa kila pakiti kwa sababu ni lazima sera itumike kwa kila pakiti. Lakini kwa viunganisho vya muda mfupi, gharama hii inasawazishwa na kupunguzwa kwa matumizi ya rasilimali kwa usindikaji wa contrack. Kwa mfano, katika kesi ya mtoa huduma wa SaaS, idadi ya pakiti kwa kila muunganisho ilikuwa ndogo sana, hivyo matumizi ya ziada ya CPU wakati wa kutumia sera kwa kila pakiti ilihesabiwa haki.
Hebu tuanze kupima
Tuliendesha jaribio kwenye ganda moja na seva iliyohifadhiwa na ganda nyingi za mteja zilizohifadhiwa zinazoendeshwa kwenye nodi za mbali ili tuweze kuendesha idadi kubwa sana ya miunganisho kwa sekunde. Seva iliyo na ganda la seva iliyohifadhiwa ilikuwa na cores 8 na maingizo 512k kwenye jedwali la uingiliano (ukubwa wa kawaida wa jedwali uliosanidiwa kwa mwenyeji).
Tulipima tofauti ya utendakazi kati ya: hakuna sera ya mtandao; na sera ya kawaida ya Calico; na sera ya usifuatilie ya Calico.
Kwa jaribio la kwanza, tuliweka idadi ya miunganisho hadi 4.000 kwa sekunde, ili tuweze kuzingatia tofauti katika matumizi ya CPU. Hakukuwa na tofauti kubwa kati ya kutokuwa na sera na sera ya kawaida, lakini usifuatilie uliongeza matumizi ya CPU kwa takriban 20%:
Katika jaribio la pili, tulizindua miunganisho mingi kadiri wateja wetu wangeweza kuzalisha na kupima idadi ya juu zaidi ya miunganisho kwa sekunde ambayo seva yetu ya memcached inaweza kushughulikia. Kama ilivyotarajiwa, kesi za "hakuna sera" na "sera za kawaida" zote zilifikia kikomo cha uzuiaji cha zaidi ya miunganisho 4,000 kwa sekunde (512k / 120s = miunganisho 4,369/s). Kwa sera ya kutofuatilia, wateja wetu walituma miunganisho 60,000 kwa sekunde bila matatizo yoyote. Tuna uhakika tunaweza kuongeza idadi hii kwa kuongeza wateja zaidi, lakini tunahisi kwamba nambari hizi tayari zinatosha kueleza hoja ya makala haya!
Hitimisho
Contrack ni kipengele muhimu cha kernel. Anafanya kazi yake kikamilifu. Mara nyingi hutumiwa na vipengele muhimu vya mfumo. Walakini, katika hali fulani mahususi, msongamano unaosababishwa na ukinzani huzidi faida za kawaida zinazotolewa. Katika hali hii, sera za mtandao za Calico zinaweza kutumika kuzima utumiaji wa uzuiaji kwa kuchagua huku ukiongeza usalama wa mtandao. Kwa trafiki nyingine zote, contrack inaendelea kuwa rafiki yako!
Pia soma nakala zingine kwenye blogi yetu:
Chanzo: mapenzi.com