1. Pasang nginx
1. Muat turun nginx
# wget http://nginx.org/download/nginx-1.2.4.tar.gz
2. Muat turun tampung modul tcp
# wget https://github.com/yaoweibin/nginx_tcp_proxy_module/tarball/master
Kod sumber halaman: https://github.com/yaoweibin/nginx_tcp_proxy_module
3 Pasang nginx
# tar xvf nginx-1.2.4.tar.gz # tar xvf yaoweibin-nginx_tcp_proxy_module-v0.4-45-ga40c99a.tar.gz # cd nginx-1.2.4 # patch -p1 < ../yaoweibin-nginx_tcp_proxy_module-a40c99a/tcp.patch #./configure --prefix=/usr/local/nginx --with-pcre=../pcre-8.30 --add-module=../yaoweibin-nginx_tcp_proxy_module-ae321fd/ # make # make install
2. Ubah suai fail konfigurasi
Ubah suai fail konfigurasi nginx.conf
# cd /usr/local/nginx/conf # vim nginx.conf
worker_processes 1; events { worker_connections 1024; } tcp { upstream mssql { server 10.0.1.201:1433; server 10.0.1.202:1433; check interval=3000 rise=2 fall=5 timeout=1000; } server { listen 1433; server_name 10.0.1.212; proxy_pass mssql; } }
3 Mulakan nginx
# cd /usr/local/nginx/sbin/ # ./nginx
Lihat port 1433:
4. Ujian
#lsof :1433
5. Gunakan alat klien pelayan sql untuk menguji
6. Prinsip pelaksanaan pengimbangan beban tcp
Apabila nginx menerima pautan klien baharu daripada port mendengar, ia segera melaksanakan algoritma penjadualan penghalaan, mendapatkan IP perkhidmatan yang ditentukan yang perlu disambungkan, dan kemudian mencipta sambungan huluan baharu ke pelayan yang ditentukan.
imbangan beban tcp menyokong algoritma penjadualan asal nginx, termasuk round robin (lalai, penjadualan pengundian), cincang (pilih konsisten), dsb. Pada masa yang sama, data maklumat penjadualan juga akan berfungsi dengan modul pengesanan keteguhan untuk memilih pelayan huluan sasaran yang sesuai untuk setiap sambungan. Jika anda menggunakan kaedah penjadualan pengimbangan beban cincang, anda boleh menggunakan $remote_addr (IP klien) untuk mencapai sesi berterusan yang mudah (sambungan dengan IP klien yang sama sentiasa jatuh pada pelayan perkhidmatan yang sama).
Seperti modul huluan lain, modul strim tcp juga menyokong berat pemajuan pengimbangan beban tersuai (konfigurasi "berat=2"), serta parameter sandaran dan turun untuk menendang keluar pelayan yang gagal. Parameter max_conns boleh mengehadkan bilangan sambungan TCP pelayan dan menetapkan nilai konfigurasi yang sesuai mengikut kapasiti pelayan Terutamanya dalam senario konkurensi tinggi, ia boleh mencapai tujuan perlindungan lebihan.
nginx memantau sambungan klien dan sambungan huluan Setelah data diterima, nginx akan segera membaca dan menolaknya ke sambungan huluan tanpa melakukan pengesanan data dalam sambungan tcp. nginx mengekalkan penimbal memori untuk penulisan data klien dan huluan. Jika pelanggan atau pelayan menghantar sejumlah besar data, penimbal akan meningkatkan saiz memori dengan sewajarnya.
Apabila nginx menerima pemberitahuan penutupan sambungan daripada mana-mana pihak, atau sambungan tcp melahu lebih lama daripada masa yang dikonfigurasikan proxy_timeout, sambungan akan ditutup. Untuk sambungan panjang TCP, kita harus memilih masa proxy_timeout yang sesuai, dan pada masa yang sama, perhatikan parameter so_keepalive soket pemantauan untuk mengelakkan pemotongan pramatang.
ps: Pemantauan keteguhan perkhidmatan
Modul pengimbangan beban tcp menyokong pengesanan keteguhan terbina dalam Jika pelayan huluan menolak sambungan tcp lebih daripada masa yang dikonfigurasikan proxy_connect_timeout. wasiat tersebut dianggap telah tamat tempoh. Dalam kes ini, nginx segera cuba menyambung ke pelayan biasa lain dalam kumpulan huluan. Maklumat kegagalan sambungan akan direkodkan dalam log ralat nginx.
Jika pelayan gagal berulang kali (melebihi parameter yang dikonfigurasikan oleh max_fails atau fail_timeout), nginx juga akan menendang pelayan. 60 saat selepas pelayan dimulakan, nginx sekali-sekala akan cuba menyambung semula kepadanya untuk memeriksa sama ada ia kembali normal. Jika pelayan kembali normal, nginx akan menambahkannya kembali ke kumpulan huluan dan perlahan-lahan meningkatkan perkadaran permintaan sambungan.
Sebab mengapa
"perlahan-lahan meningkat" adalah kerana biasanya perkhidmatan mempunyai "data panas", iaitu, lebih daripada 80% atau lebih banyak permintaan sebenarnya akan disekat dalam " cache data panas". Hanya sebahagian kecil daripada permintaan yang sebenarnya diproses. Apabila mesin baru dimulakan, "cache data panas" sebenarnya belum ditubuhkan Pada masa ini, sejumlah besar permintaan dimajukan secara meletup, yang berkemungkinan menyebabkan mesin tidak dapat "menanggung" dan menutup telefon semula. . Mengambil mysql sebagai contoh, lebih daripada 95% pertanyaan mysql kami biasanya jatuh ke dalam cache memori, dan tidak banyak pertanyaan yang benar-benar dilaksanakan. Malah, sama ada mesin tunggal atau kluster, memulakan semula atau menukar dalam senario permintaan serentak yang tinggi akan mempunyai risiko ini:
(1 ) Permintaan meningkat secara beransur-ansur, daripada kurang kepada lebih, secara beransur-ansur mengumpul data tempat liputan, dan akhirnya mencapai status perkhidmatan biasa.
Modul pengimbangan beban tcp menyokong pengesanan kekukuhan terbina dalam Jika pelayan huluan menolak sambungan tcp lebih daripada masa yang dikonfigurasikan proxy_connect_timeout, ia akan dianggap gagal. Dalam kes ini, nginx segera cuba menyambung ke pelayan biasa lain dalam kumpulan huluan. Maklumat kegagalan sambungan akan direkodkan dalam log ralat nginx.
Jika pelayan gagal berulang kali (melebihi parameter yang dikonfigurasikan oleh max_fails atau fail_timeout), nginx juga akan menendang pelayan. 60 saat selepas pelayan dimulakan, nginx sekali-sekala akan cuba menyambung semula kepadanya untuk memeriksa sama ada ia kembali normal. Jika pelayan kembali normal, nginx akan menambahkannya kembali ke kumpulan huluan dan perlahan-lahan meningkatkan perkadaran permintaan sambungan.
Sebab "perlahan-lahan meningkat" adalah kerana biasanya perkhidmatan mempunyai "data panas", iaitu, lebih daripada 80% atau lebih banyak permintaan sebenarnya akan disekat dalam "cache data panas" , hanya sebahagian kecil daripada permintaan yang sebenarnya diproses. Apabila mesin baru dimulakan, "cache data panas" sebenarnya belum ditubuhkan Pada masa ini, sejumlah besar permintaan dimajukan secara meletup, yang berkemungkinan menyebabkan mesin tidak dapat "menanggung" dan menutup telefon semula. . Mengambil mysql sebagai contoh, lebih daripada 95% pertanyaan mysql kami biasanya jatuh ke dalam cache memori, dan tidak banyak pertanyaan yang benar-benar dilaksanakan.
Malah, sama ada mesin tunggal atau kluster, memulakan semula atau menukar dalam senario permintaan serentak yang tinggi akan mempunyai risiko ini:
(1 ) Permintaan meningkat secara beransur-ansur, daripada kurang kepada lebih, secara beransur-ansur mengumpul data tempat liputan, dan akhirnya mencapai status perkhidmatan biasa.
(2) Sediakan data "biasa digunakan" lebih awal, "panaskan" perkhidmatan secara proaktif, dan kemudian buka akses kepada pelayan selepas pemanasan awal selesai.
Prinsip pengimbangan beban tcp adalah sama seperti lvs, dsb. Ia berfungsi pada tahap yang lebih rendah dan prestasinya akan jauh lebih tinggi daripada pengimbangan beban http asal. Walau bagaimanapun, ia tidak akan lebih baik daripada lvs lvs diletakkan dalam modul kernel, manakala nginx berfungsi dalam mod pengguna, dan nginx agak berat. Satu lagi perkara, yang sangat dikesali, ialah modul ini adalah fungsi berbayar.
Atas ialah kandungan terperinci Bagaimana untuk mengkonfigurasi pengimbangan beban untuk TCP dalam pelayan Nginx. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!