Penjejakan sambungan (“conntrack”) ialah ciri teras tindanan rangkaian kernel Linux. Ia membolehkan kernel menjejaki semua sambungan rangkaian logik atau aliran dan dengan itu mengenal pasti semua paket yang membentuk setiap aliran supaya ia boleh diproses bersama secara berurutan.
Conntrack ialah ciri kernel penting yang digunakan dalam beberapa kes asas:
- NAT bergantung pada maklumat daripada conntrack supaya ia boleh merawat semua paket dari aliran yang sama secara sama rata. Contohnya, apabila pod mengakses perkhidmatan Kubernetes, pengimbang beban proksi kube menggunakan NAT untuk mengarahkan trafik ke pod tertentu dalam kelompok. Conntrack merekodkan bahawa untuk sambungan tertentu, semua paket ke perkhidmatan IP mesti dihantar ke pod yang sama, dan paket yang dikembalikan oleh pod hujung belakang mesti NATed kembali ke pod dari mana permintaan itu datang.
- Tembok api stateful seperti Calico bergantung pada maklumat daripada runut sambungan kepada trafik "tindak balas" senarai putih. Ini membolehkan anda menulis dasar rangkaian yang mengatakan "benarkan pod saya menyambung ke mana-mana alamat IP jauh" tanpa perlu menulis dasar untuk membenarkan trafik respons secara eksplisit. (Tanpa ini, anda perlu menambah peraturan "benarkan paket ke pod saya daripada mana-mana IP" yang kurang selamat.)
Selain itu, conntrack biasanya meningkatkan prestasi sistem (dengan mengurangkan penggunaan CPU dan kependaman paket) kerana hanya paket pertama dalam strim
mesti melalui keseluruhan timbunan rangkaian untuk menentukan perkara yang perlu dilakukan dengannya. Lihat siaran ""untuk melihat contoh cara ia berfungsi.
Walau bagaimanapun, conntrack mempunyai batasannya...
Jadi di manakah silapnya?
Jadual conntrack mempunyai saiz maksimum yang boleh dikonfigurasikan, dan jika ia menjadi penuh, sambungan biasanya mula ditolak atau digugurkan. Terdapat ruang kosong yang mencukupi dalam jadual untuk mengendalikan trafik kebanyakan aplikasi, dan ini tidak akan menjadi masalah. Walau bagaimanapun, terdapat beberapa senario yang anda mungkin ingin pertimbangkan menggunakan jadual conntrack:
- Kes yang paling jelas ialah jika pelayan anda mengendalikan sejumlah besar sambungan aktif serentak. Sebagai contoh, jika jadual conntrack anda dikonfigurasikan untuk 128k entri, tetapi anda mempunyai >128k sambungan serentak, anda pasti akan menghadapi masalah!
- Kes yang kurang jelas: jika pelayan anda memproses bilangan sambungan yang sangat besar sesaat. Walaupun sambungan adalah jangka pendek, ia terus dipantau oleh Linux untuk beberapa tempoh masa (120s secara lalai). Sebagai contoh, jika jadual conntrack anda dikonfigurasikan untuk 128k entri dan anda cuba mengendalikan 1100 sambungan sesaat, ia akan melebihi saiz jadual conntrack, walaupun jika sambungan adalah sangat singkat (128k/120s = 1092 sambungan/ s).
Terdapat beberapa jenis apl khusus yang termasuk dalam kategori ini. Selain itu, jika anda mempunyai banyak pelakon yang tidak baik, mengisi jadual conntrack pelayan anda dengan banyak sambungan separuh terbuka boleh digunakan sebagai sebahagian daripada serangan penafian perkhidmatan (DOS). Dalam kedua-dua kes, conntrack boleh menjadi halangan yang mengehadkan dalam sistem anda. Dalam sesetengah kes, melaraskan parameter jadual conntrack mungkin cukup untuk memenuhi keperluan anda - dengan meningkatkan saiz atau mengurangkan tamat masa conntrack (tetapi jika anda salah melakukannya, anda akan menghadapi banyak masalah). Untuk kes lain adalah perlu untuk memintas conntrack untuk trafik yang agresif.
Contoh sebenar
Mari kita berikan contoh khusus: satu pembekal SaaS besar yang kami bekerjasama mempunyai beberapa pelayan memcached pada hos (bukan mesin maya), yang setiap satunya memproses 50K+ sambungan jangka pendek sesaat.
Mereka bereksperimen dengan konfigurasi conntrack, meningkatkan saiz jadual dan mengurangkan masa penjejakan, tetapi konfigurasi tidak boleh dipercayai, penggunaan RAM meningkat dengan ketara, yang merupakan masalah (mengikut susunan GBytes!), dan sambungannya sangat pendek sehingga conntrack tidak mencipta manfaat prestasi biasa (penggunaan CPU dikurangkan atau kependaman paket).
Mereka beralih kepada Calico sebagai alternatif. Dasar rangkaian Calico membenarkan anda untuk tidak menggunakan conntrack untuk jenis trafik tertentu (menggunakan pilihan dasar doNotTrack). Ini memberikan mereka tahap prestasi yang mereka perlukan, ditambah dengan tahap keselamatan tambahan yang disediakan oleh Calico.
Berapakah panjang yang anda perlu pergi untuk memintas conntrack?
- Dasar rangkaian jangan jejak biasanya simetri. Dalam kes pembekal SaaS: aplikasi mereka dijalankan di dalam zon dilindungi dan oleh itu, menggunakan dasar rangkaian, mereka boleh menyenarai putih trafik daripada aplikasi khusus lain yang dibenarkan akses kepada memcached.
- Dasar do-not-track tidak mengambil kira arah sambungan. Oleh itu, jika pelayan memcached digodam, secara teori anda boleh cuba menyambung kepada mana-mana klien memcached, selagi ia menggunakan port sumber yang betul. Walau bagaimanapun, jika anda telah mentakrifkan dasar rangkaian dengan betul untuk klien memcached anda, maka percubaan sambungan ini masih akan ditolak di sisi klien.
- Dasar jangan jejak digunakan pada setiap paket, berbanding dasar biasa, yang digunakan hanya pada paket pertama dalam aliran. Ini boleh meningkatkan penggunaan CPU setiap paket kerana dasar mesti digunakan untuk setiap paket. Tetapi untuk sambungan jangka pendek, perbelanjaan ini diimbangi dengan pengurangan penggunaan sumber untuk pemprosesan sambungan. Sebagai contoh, dalam kes pembekal SaaS, bilangan paket untuk setiap sambungan adalah sangat kecil, jadi penggunaan CPU tambahan apabila menggunakan dasar pada setiap paket adalah wajar.
Mari mulakan ujian
Kami menjalankan ujian pada satu pod dengan pelayan memcached dan berbilang pod klien memcached berjalan pada nod jauh supaya kami boleh menjalankan bilangan sambungan yang sangat besar sesaat. Pelayan dengan pod pelayan memcached mempunyai 8 teras dan 512k entri dalam jadual conntrack (saiz jadual terkonfigurasi standard untuk hos).
Kami mengukur perbezaan prestasi antara: tiada dasar rangkaian; dengan dasar Calico biasa; dan dasar Calico do-not-track.
Untuk ujian pertama, kami menetapkan bilangan sambungan kepada 4.000 sesaat, supaya kami boleh menumpukan pada perbezaan dalam penggunaan CPU. Tiada perbezaan ketara antara tiada polisi dan polisi biasa, tetapi jangan-jejaki peningkatan penggunaan CPU sebanyak kira-kira 20%:
Dalam ujian kedua, kami melancarkan seberapa banyak sambungan yang pelanggan kami boleh menjana dan mengukur bilangan maksimum sambungan sesaat yang boleh dikendalikan oleh pelayan memcached kami. Seperti yang dijangkakan, kes "tiada dasar" dan "dasar biasa" kedua-duanya mencapai had sambungan lebih 4,000 sambungan sesaat (512k / 120s = 4,369 sambungan/s). Dengan dasar jangan jejak, pelanggan kami menghantar 60,000 sambungan sesaat tanpa sebarang masalah. Kami pasti kami boleh meningkatkan jumlah ini dengan menambah lebih ramai pelanggan, tetapi kami merasakan nombor ini sudah cukup untuk menggambarkan maksud artikel ini!
Kesimpulan
Conntrack ialah ciri kernel yang penting. Dia melakukan tugasnya dengan sempurna. Ia sering digunakan oleh komponen sistem utama. Walau bagaimanapun, dalam beberapa senario tertentu, kesesakan akibat conntrack melebihi faedah biasa yang diberikannya. Dalam senario ini, dasar rangkaian Calico boleh digunakan untuk melumpuhkan secara terpilih penggunaan conntrack sambil meningkatkan keselamatan rangkaian. Untuk semua trafik lain, conntrack terus menjadi rakan anda!
Baca juga artikel lain di blog kami:
Sumber: www.habr.com