Կապի հետագծումը («conntrack») Linux միջուկի ցանցային փաթեթի հիմնական առանձնահատկությունն է: Այն թույլ է տալիս միջուկին հետևել բոլոր տրամաբանական ցանցային կապերին կամ հոսքերին և դրանով իսկ բացահայտել բոլոր փաթեթները, որոնք կազմում են յուրաքանչյուր հոսք, որպեսզի դրանք կարողանան հաջորդաբար մշակվել միասին:
Conntrack-ը միջուկի կարևոր հատկանիշ է, որն օգտագործվում է որոշ հիմնական դեպքերում.
- NAT-ը հիմնվում է conntrack-ի տեղեկատվության վրա, որպեսզի կարողանա նույն հոսքի բոլոր փաթեթները հավասարապես վերաբերվել: Օրինակ, երբ pod-ը մուտք է գործում Kubernetes ծառայություն, kube-proxy load balancer-ն օգտագործում է NAT-ը՝ կլաստերի ներսում երթևեկությունն ուղղորդելու համար: Conntrack-ը արձանագրում է, որ տվյալ կապի համար IP ծառայության բոլոր փաթեթները պետք է ուղարկվեն նույն pod, և որ backend-ի կողմից վերադարձված փաթեթները պետք է NAT-ով վերադարձվեն այն pod, որտեղից եկել է հարցումը:
- Պետական հրդեհային պատերը, ինչպիսին է Calico-ն, հիմնվում են կապի երթևեկությունից մինչև սպիտակ ցուցակի «պատասխան» տրաֆիկի վրա: Սա թույլ է տալիս գրել ցանցային քաղաքականություն, որն ասում է՝ «թույլ տվեք իմ պատին միանալ ցանկացած հեռավոր IP հասցեի», առանց պատասխանի տրաֆիկի հստակ թույլատրելու քաղաքականություն գրելու: (Առանց դրա, դուք պետք է ավելացնեք շատ ավելի քիչ անվտանգ «Թույլատրել փաթեթները իմ պատին ցանկացած IP-ից» կանոնը):
Բացի այդ, conntrack-ը սովորաբար բարելավում է համակարգի կատարումը (նվազեցնելով պրոցեսորի սպառումը և փաթեթների ուշացումը), քանի որ հոսքի մեջ միայն առաջին փաթեթն է:
պետք է անցնի ամբողջ ցանցի կույտը՝ որոշելու, թե ինչ անել դրա հետ: Դիտեք գրառումը"«Դիտելու օրինակ, թե ինչպես է այն աշխատում:
Այնուամենայնիվ, contrack-ն ունի իր սահմանափակումները...
Այսպիսով, որտե՞ղ է այդ ամենը սխալվել:
Conntrack աղյուսակը ունի կարգավորելի առավելագույն չափ, և եթե այն լցվի, կապերը սովորաբար սկսում են մերժվել կամ անջատվել: Աղյուսակում բավականաչափ ազատ տարածություն կա հավելվածների մեծ մասի տրաֆիկը կարգավորելու համար, և դա երբեք խնդիր չի դառնա: Այնուամենայնիվ, կան մի քանի սցենարներ, որոնց դեպքում դուք կարող եք հաշվի առնել՝ օգտագործելով contrack աղյուսակը.
- Ամենաակնառու դեպքն այն է, եթե ձեր սերվերը կառավարում է չափազանց մեծ թվով միաժամանակ ակտիվ կապեր: Օրինակ, եթե ձեր conntrack աղյուսակը կազմաձևված է 128k մուտքերի համար, բայց դուք ունեք >128k միաժամանակյա միացումներ, դուք, անշուշտ, խնդիր կունենաք:
- Մի փոքր ավելի քիչ ակնհայտ դեպք. եթե ձեր սերվերը մեկ վայրկյանում մշակում է շատ մեծ թվով կապեր: Նույնիսկ եթե կապերը կարճատև են, դրանք շարունակում են վերահսկվել Linux-ի կողմից որոշ ժամանակով (լռելյայն 120-ականներ): Օրինակ, եթե ձեր conntrack աղյուսակը կազմաձևված է 128k մուտքերի համար, և դուք փորձում եք կարգավորել 1100 կապ վայրկյանում, դրանք կգերազանցեն conntrack աղյուսակի չափը, նույնիսկ եթե կապերը շատ կարճատև են (128k/120s = 1092 կապ/ s).
Կան հավելվածների մի քանի խորշ տեսակներ, որոնք պատկանում են այս կատեգորիաներին: Բացի այդ, եթե դուք ունեք շատ վատ դերակատարներ, ձեր սերվերի կոնտրեք աղյուսակը լրացնելը բազմաթիվ կիսաբաց կապերով կարող է օգտագործվել որպես ծառայության մերժման (DOS) հարձակման մաս: Երկու դեպքում էլ conntrack-ը կարող է դառնալ սահմանափակող խոչընդոտ ձեր համակարգում: Որոշ դեպքերում, conntrack աղյուսակի պարամետրերի ճշգրտումը կարող է բավարար լինել ձեր կարիքները բավարարելու համար՝ մեծացնելով չափը կամ նվազեցնելով conntrack-ի ժամկետները (բայց եթե դա անեք սխալ, դուք շատ դժվարությունների կբախվեք): Այլ դեպքերում անհրաժեշտ կլինի շրջանցել ագրեսիվ երթևեկության կոնտրակտը:
Իրական օրինակ
Եկեք կոնկրետ օրինակ բերենք. մեկ խոշոր SaaS պրովայդեր, որի հետ մենք աշխատել ենք, ուներ մի շարք memcached սերվերներ հոսթների վրա (ոչ վիրտուալ մեքենաներ), որոնցից յուրաքանչյուրը մեկ վայրկյանում մշակում էր 50K+ կարճաժամկետ կապ:
Նրանք փորձարկեցին conntrack-ի կոնֆիգուրացիան՝ ավելացնելով աղյուսակի չափերը և կրճատելով հետևելու ժամանակը, բայց կոնֆիգուրացիան անվստահելի էր, RAM-ի սպառումը զգալիորեն ավելացավ, ինչը խնդիր էր (Գբայթերի կարգով), և միացումներն այնքան կարճ էին, որ conntrack-ը չհաջողվեց: ստեղծել իր սովորական կատարողական առավելությունը (կրճատված սպառման պրոցեսորի կամ փաթեթների ուշացում):
Նրանք որպես այլընտրանք դիմեցին Calico-ին։ Calico ցանցի քաղաքականությունը թույլ է տալիս չօգտագործել conntrack-ը որոշակի տեսակի տրաֆիկի համար (օգտագործելով doNotTrack քաղաքականության տարբերակը): Սա նրանց տվեց անհրաժեշտ կատարողականության մակարդակը, գումարած Calico-ի կողմից տրամադրվող անվտանգության հավելյալ մակարդակը:
Ի՞նչ երկարություններ պետք է անցնեք, որպեսզի շրջանցեք contrack-ը:
- «Չհետևել» ցանցի քաղաքականությունը հիմնականում պետք է լինի սիմետրիկ: SaaS մատակարարի դեպքում. նրանց հավելվածներն աշխատում էին պաշտպանված գոտու ներսում և, հետևաբար, օգտագործելով ցանցային քաղաքականությունը, նրանք կարող էին սպիտակ ցուցակում ներառել այլ հատուկ հավելվածների երթևեկությունը, որոնց թույլատրվում էր մուտք գործել memcached:
- «Չհետևել» քաղաքականությունը հաշվի չի առնում կապի ուղղությունը: Այսպիսով, եթե memcached սերվերը կոտրված է, ապա տեսականորեն կարող եք փորձել միանալ memcached հաճախորդներից որևէ մեկին, քանի դեռ այն օգտագործում է ճիշտ աղբյուրի պորտը: Այնուամենայնիվ, եթե դուք ճիշտ եք սահմանել ցանցային քաղաքականությունը ձեր memcached հաճախորդների համար, ապա այս կապի փորձերը դեռ կմերժվեն հաճախորդի կողմից:
- «Չհետևել» քաղաքականությունը կիրառվում է յուրաքանչյուր փաթեթի նկատմամբ՝ ի տարբերություն սովորական քաղաքականության, որը կիրառվում է հոսքի միայն առաջին փաթեթի նկատմամբ: Սա կարող է մեծացնել CPU-ի սպառումը մեկ փաթեթի համար, քանի որ քաղաքականությունը պետք է կիրառվի յուրաքանչյուր փաթեթի համար: Բայց կարճատև կապերի դեպքում այս ծախսը հավասարակշռվում է հսկողության վերամշակման համար ռեսուրսների սպառման կրճատմամբ: Օրինակ, SaaS մատակարարի դեպքում յուրաքանչյուր կապի համար փաթեթների թիվը շատ փոքր էր, ուստի CPU-ի լրացուցիչ սպառումը յուրաքանչյուր փաթեթի նկատմամբ քաղաքականություն կիրառելիս արդարացված էր:
Եկեք սկսենք փորձարկումը
Մենք փորձարկումն անցկացրինք մեկ պատի վրա՝ memcached սերվերով և մի քանի memcached հաճախորդի pods, որոնք աշխատում էին հեռավոր հանգույցների վրա, որպեսզի կարողանանք վայրկյանում շատ մեծ թվով կապեր գործարկել: Սերվերը memcached սերվերի pod-ով ուներ 8 միջուկ և 512k գրառում conntrack աղյուսակում (ստանդարտ կազմաձևված աղյուսակի չափը հոսթի համար):
Մենք չափել ենք կատարողականի տարբերությունը. ցանցային քաղաքականություն չկա; կանոնավոր Calico քաղաքականությամբ; և Calico-ն՝ չհետևել քաղաքականությանը:
Առաջին փորձարկման համար մենք միացումների թիվը սահմանել ենք վայրկյանում 4.000, այնպես որ կարող ենք կենտրոնանալ պրոցեսորի սպառման տարբերության վրա: Չկան էական տարբերություններ առանց քաղաքականության և կանոնավոր քաղաքականության միջև, բայց չհետևել պրոցեսորի սպառման աճին մոտ 20%-ով.
Երկրորդ փորձարկման ժամանակ մենք գործարկեցինք այնքան կապեր, որքան մեր հաճախորդները կարող էին ստեղծել, և չափեցինք վայրկյանում կապերի առավելագույն քանակը, որը կարող էր աշխատել մեր memcached սերվերը: Ինչպես և սպասվում էր, «առանց քաղաքականության» և «կանոնավոր քաղաքականության» դեպքերը երկուսն էլ հասել են վայրկյանում 4,000 կապի սահմանաչափին (512k / 120s = 4,369 կապ/վրկ): «Չհետևել» քաղաքականության միջոցով մեր հաճախորդներն առանց որևէ խնդրի ուղարկել են վայրկյանում 60,000 կապ: Մենք վստահ ենք, որ կարող ենք ավելացնել այս թիվը՝ ավելացնելով ավելի շատ հաճախորդներ, բայց կարծում ենք, որ այս թվերն արդեն բավական են այս հոդվածի իմաստը լուսաբանելու համար:
Ամփոփում
Conntrack-ը միջուկի կարևոր հատկանիշ է: Նա հիանալի է կատարում իր աշխատանքը։ Այն հաճախ օգտագործվում է համակարգի հիմնական բաղադրիչների կողմից: Այնուամենայնիվ, որոշ կոնկրետ սցենարներում, կոնտրակտի հետևանքով առաջացած գերբեռնվածությունը գերազանցում է այն նորմալ օգուտները, որոնք այն տալիս է: Այս սցենարում Calico-ի ցանցային քաղաքականությունը կարող է օգտագործվել՝ ընտրողաբար անջատելու համար conntrack-ի օգտագործումը՝ միաժամանակ բարձրացնելով ցանցի անվտանգությունը: Մնացած բոլոր տրաֆիկի համար conntrack-ը շարունակում է մնալ ձեր ընկերը:
Կարդացեք նաև մեր բլոգի այլ հոդվածներ.
Source: www.habr.com