Bağlantı izləmə (“conntrack”) Linux nüvəsi şəbəkə yığınının əsas xüsusiyyətidir. O, nüvəyə bütün məntiqi şəbəkə bağlantılarını və ya axınlarını izləməyə və bununla da hər bir axını təşkil edən bütün paketləri müəyyən etməyə imkan verir ki, onlar ardıcıl olaraq birlikdə işlənə bilsinlər.
Conntrack bəzi əsas hallarda istifadə olunan mühüm nüvə xüsusiyyətidir:
- NAT eyni axındakı bütün paketləri bərabər şəkildə idarə edə bilməsi üçün conntrack-dən alınan məlumatlara əsaslanır. Məsələn, pod Kubernetes xidmətinə daxil olduqda, kube-proksi yük balanslaşdırıcısı trafiki klaster daxilində xüsusi poda yönəltmək üçün NAT-dan istifadə edir. Conntrack qeyd edir ki, müəyyən bir əlaqə üçün IP xidmətinə bütün paketlər eyni pod-a göndərilməli və backend pod tərəfindən qaytarılan paketlər sorğunun gəldiyi pod-a geri qaytarılmalıdır.
- Calico kimi statuslu firewalllar, konnekttrekdən ağ siyahıya alınmış “cavab” trafikinə qədər məlumatlara əsaslanır. Bu, cavab trafikinə açıq şəkildə icazə vermək üçün bir siyasət yazmadan "mənim podumun istənilən uzaq IP ünvanına qoşulmasına icazə verin" deyən şəbəkə siyasəti yazmağa imkan verir. (Bunsuz, daha az təhlükəsiz "hər hansı bir IP-dən mənim poduma paketlərə icazə verin" qaydasını əlavə etməli olacaqsınız.)
Əlavə olaraq, conntrack adətən sistem performansını yaxşılaşdırır (CPU istehlakını və paket gecikməsini azaltmaqla) axındakı yalnız ilk paketdən bəri
onunla nə edəcəyini müəyyən etmək üçün bütün şəbəkə yığınından keçməlidir. Posta baxın "" bunun necə işlədiyinə dair bir nümunə görmək üçün.
Bununla belə, conntrack-in məhdudiyyətləri var...
Bəs hər şey harada səhv oldu?
Conntrack cədvəlinin konfiqurasiya edilə bilən maksimum ölçüsü var və o, dolursa, bağlantılar ümumiyyətlə rədd edilməyə və ya kəsilməyə başlayır. Cədvəldə əksər proqramların trafikini idarə etmək üçün kifayət qədər boş yer var və bu heç vaxt problem olmayacaq. Bununla belə, əlaqə cədvəlindən istifadə etməyi düşünə biləcəyiniz bir neçə ssenari var:
- Ən açıq vəziyyət, serverinizin çox sayda eyni vaxtda aktiv əlaqəni idarə etməsidir. Məsələn, əgər əlaqə cədvəliniz 128k giriş üçün konfiqurasiya edilibsə, lakin siz >128k paralel bağlantınız varsa, şübhəsiz ki, problemlə üzləşəcəksiniz!
- Bir az daha az aşkar bir hal: əgər serveriniz saniyədə çox sayda əlaqə işlədirsə. Bağlantılar qısamüddətli olsa belə, müəyyən müddət ərzində Linux tərəfindən izlənməyə davam edir (standart olaraq 120 saniyə). Məsələn, əgər əlaqə cədvəliniz 128k giriş üçün konfiqurasiya edilibsə və siz saniyədə 1100 əlaqəni idarə etməyə çalışırsınızsa, bağlantılar çox qısamüddətli olsa belə, onlar əlaqə cədvəlinin ölçüsünü keçəcək (128k/120s = 1092 bağlantı/ s).
Bu kateqoriyalara aid olan bir neçə növ proqram var. Əlavə olaraq, çoxlu pis aktyorlarınız varsa, serverinizin əlaqə cədvəlini çoxlu yarı açıq bağlantılarla doldurmaq xidmətdən imtina (DOS) hücumunun bir hissəsi kimi istifadə edilə bilər. Hər iki halda conntrack sisteminizdə məhdudlaşdırıcı darboğaza çevrilə bilər. Bəzi hallarda, conntrack cədvəlinin parametrlərini tənzimləmək ehtiyaclarınızı ödəmək üçün kifayət ola bilər - ölçüsünü artırmaq və ya əlaqə vaxt aşımlarını azaltmaqla (lakin bunu səhv etsəniz, bir çox problemlə üzləşəcəksiniz). Digər hallarda aqressiv trafik üçün keçiddən yan keçmək lazım gələcək.
Həqiqi nümunə
Konkret bir misal verək: işlədiyimiz bir böyük SaaS provayderinin hər biri saniyədə 50K+ qısamüddətli əlaqəni emal edən hostlarda (virtual maşınlarda deyil) bir sıra yaddaş yaddaşına malik serverlərə malik idi.
Onlar conntrack konfiqurasiyası ilə sınaqdan keçirdilər, masa ölçülərini artırdılar və izləmə vaxtını azaltdılar, lakin konfiqurasiya etibarsız idi, RAM istehlakı əhəmiyyətli dərəcədə artdı, bu da problem idi (Gbayt sırasına görə!) və əlaqələr o qədər qısa idi ki, conntrack işləmədi adi performans faydasını yaradın (azaldılmış istehlak CPU və ya paket gecikməsi).
Alternativ olaraq Kalikoya üz tutdular. Calico şəbəkə siyasətləri sizə müəyyən trafik növləri üçün conntrack istifadə etməməyə imkan verir (doNotTrack siyasəti seçimindən istifadə etməklə). Bu, onlara lazım olan performans səviyyəsini və Calico tərəfindən təmin edilən əlavə təhlükəsizlik səviyyəsini verdi.
Bağlantı yolu keçmək üçün hansı uzunluğa getməli olacaqsınız?
- Şəbəkə izləmə siyasətləri ümumiyyətlə simmetrik olmalıdır. SaaS provayderi vəziyyətində: onların tətbiqləri qorunan zona daxilində işləyirdi və buna görə də şəbəkə siyasətindən istifadə edərək, memcached-ə giriş icazəsi verilmiş digər xüsusi proqramlardan gələn trafiki ağ siyahıya sala bilərdilər.
- Do-not-track siyasəti əlaqənin istiqamətini nəzərə almır. Beləliklə, əgər memcached server sındırılıbsa, siz nəzəri olaraq düzgün mənbə portundan istifadə etdiyi müddətcə memcached müştərilərdən hər hansı birinə qoşulmağa cəhd edə bilərsiniz. Bununla belə, əgər siz yaddaşda saxlanılan müştəriləriniz üçün şəbəkə siyasətini düzgün müəyyən etmisinizsə, o zaman bu əlaqə cəhdləri hələ də müştəri tərəfində rədd ediləcək.
- İzləmə siyasəti axındakı yalnız ilk paketə tətbiq edilən normal siyasətlərdən fərqli olaraq hər paketə tətbiq edilir. Bu, hər paket üçün CPU istehlakını artıra bilər, çünki siyasət hər bir paket üçün tətbiq edilməlidir. Lakin qısa müddətli əlaqələr üçün bu xərc əlaqənin işlənməsi üçün resurs istehlakının azalması ilə balanslaşdırılır. Məsələn, SaaS provayderi vəziyyətində, hər bir əlaqə üçün paketlərin sayı çox az idi, buna görə də hər bir paketə siyasət tətbiq edərkən əlavə CPU istehlakı əsaslandırıldı.
Test etməyə başlayaq
Biz saniyədə çoxlu sayda əlaqə qura bilməmiz üçün sınağı yaddaşda saxlanılan server və uzaq qovşaqlarda işləyən çoxsaylı yaddaş yaddaşlı müştəri podları ilə tək podda keçirdik. Memcached server pod ilə serverdə 8 nüvə və conntrack cədvəlində 512k giriş var (host üçün standart konfiqurasiya edilmiş cədvəl ölçüsü).
Biz performans fərqini ölçdük: şəbəkə siyasəti yoxdur; müntəzəm Calico siyasəti ilə; və Calico-nun izləmə siyasəti.
Birinci sınaq üçün biz bağlantıların sayını saniyədə 4.000-ə təyin etdik ki, CPU istehlakındakı fərqə diqqət yetirək. Heç bir siyasətlə adi siyasət arasında əhəmiyyətli fərqlər yox idi, lakin CPU istehlakının artmasını təqribən 20% izləməyin:
İkinci sınaqda biz müştərilərimizin yarada bildiyi qədər əlaqə yaratdıq və yaddaşda saxlanan serverimizin idarə edə biləcəyi saniyədə maksimum əlaqə sayını ölçdük. Gözlənildiyi kimi, "siyasət yoxdur" və "müntəzəm siyasət" hallarının hər ikisi saniyədə 4,000-dən çox əlaqə limitinə çatdı (512k / 120s = 4,369 əlaqə/s). İzləmə siyasəti ilə müştərilərimiz heç bir problem olmadan saniyədə 60,000 əlaqə göndərdilər. Əminik ki, daha çox müştəri əlavə etməklə bu rəqəmi artıra bilərik, lakin biz hesab edirik ki, bu rəqəmlər bu məqalənin mahiyyətini göstərmək üçün artıq kifayətdir!
Nəticə
Conntrack mühüm nüvə xüsusiyyətidir. İşini mükəmməl şəkildə yerinə yetirir. Tez-tez əsas sistem komponentləri tərəfindən istifadə olunur. Bununla belə, bəzi spesifik ssenarilərdə əlaqə ilə bağlı tıxac onun təmin etdiyi normal faydalardan üstündür. Bu ssenaridə, Calico şəbəkə siyasətləri şəbəkə təhlükəsizliyini artırarkən conntrack-in istifadəsini seçmə şəkildə aradan qaldırmaq üçün istifadə edilə bilər. Bütün digər trafik üçün conntrack sizin dostunuz olmağa davam edir!
Bloqumuzdakı digər məqalələri də oxuyun:
Mənbə: www.habr.com