Apa yang harus dilakukan jika kekuatan satu server tidak cukup untuk memproses semua permintaan, dan produsen perangkat lunak tidak menyediakan penyeimbangan beban? Ada banyak pilihan, mulai dari membeli penyeimbang beban hingga membatasi jumlah permintaan. Mana yang benar harus ditentukan oleh situasi, dengan memperhatikan kondisi yang ada. Pada artikel ini kami akan memberi tahu Anda apa yang dapat Anda lakukan jika anggaran Anda terbatas dan Anda memiliki server gratis.
Sebagai sistem yang perlu mengurangi beban pada salah satu server, kami memilih DLP (sistem pencegahan kebocoran informasi) dari InfoWatch. Fitur implementasinya adalah penempatan fungsi penyeimbang di salah satu server βtempurβ.
Salah satu masalah yang kami temui adalah ketidakmampuan menggunakan Source NAT (SNAT). Mengapa hal ini diperlukan dan bagaimana masalah ini diselesaikan, akan kami uraikan lebih lanjut.
Jadi, awalnya diagram logis dari sistem yang ada terlihat seperti ini:
Lalu lintas ICAP, SMTP, peristiwa dari komputer pengguna diproses di server Traffic Monitor (TM). Pada saat yang sama, server database dengan mudah mengatasi beban setelah memproses peristiwa di TM, tetapi beban pada TM itu sendiri berat. Hal ini terlihat dari munculnya antrian pesan di server Device Monitor (DM), serta dari beban CPU dan memori di TM.
Sekilas, jika kami menambahkan server TM lain ke skema ini, maka ICAP atau DM dapat dialihkan ke sana, tetapi kami memutuskan untuk tidak menggunakan metode ini, karena toleransi kesalahan telah berkurang.
Deskripsi solusi
Dalam proses mencari solusi yang sesuai, kami memilih perangkat lunak yang didistribusikan secara bebas bersama dengan . Karena keepalive memecahkan masalah pembuatan cluster failover dan juga dapat mengelola penyeimbang LVS.
Apa yang ingin kami capai (mengurangi beban pada TM dan mempertahankan tingkat toleransi kesalahan saat ini) seharusnya berjalan sesuai dengan skema berikut:
Saat memeriksa fungsinya, ternyata rakitan RedHat khusus yang diinstal di server tidak mendukung SNAT. Dalam kasus kami, kami berencana menggunakan SNAT untuk memastikan bahwa paket masuk dan responsnya dikirim dari alamat IP yang sama, jika tidak, kami akan mendapatkan gambar berikut:
Ini tidak bisa diterima. Misalnya, server proxy, setelah mengirim paket ke alamat IP Virtual (VIP), akan mengharapkan respons dari VIP, namun dalam kasus ini respons akan datang dari IP2 untuk sesi yang dikirim ke cadangan. Solusi ditemukan: perlu membuat tabel perutean lain pada cadangan dan menghubungkan dua server TM dengan jaringan terpisah, seperti yang ditunjukkan di bawah ini:
Pengaturan
Kami akan menerapkan skema dua server dengan layanan ICAP, SMTP, TCP 9100 dan penyeimbang beban diinstal pada salah satunya.
Kami memiliki dua server RHEL6, yang repositori standarnya dan beberapa paketnya telah dihapus.
Layanan yang perlu kita seimbangkan:
β’ ICAP β tcp 1344;
β’ SMTP β tcp 25.
Layanan transmisi trafik dari DM β tcp 9100.
Pertama, kita perlu merencanakan jaringan.
Alamat IP virtual (VIP):
β’ IP: 10.20.20.105.
Server TM6_1:
β’ IP Eksternal: 10.20.20.101;
β’ IP Internal: 192.168.1.101.
Server TM6_2:
β’ IP Eksternal: 10.20.20.102;
β’ IP Internal: 192.168.1.102.
Kemudian kami mengaktifkan penerusan IP di dua server TM. Cara melakukan ini dijelaskan di RedHat .
Kami memutuskan server mana yang akan kami miliki sebagai server utama dan server mana yang akan menjadi server cadangan. Biarkan master menjadi TM6_1, cadangan menjadi TM6_2.
Pada cadangan kami membuat tabel perutean penyeimbang dan aturan perutean baru:
[root@tm6_2 ~]echo 101 balancer >> /etc/iproute2/rt_tables
[root@tm6_2 ~]ip rule add from 192.168.1.102 table balancer
[root@tm6_2 ~]ip route add default via 192.168.1.101 table balancerPerintah di atas berfungsi hingga sistem di-boot ulang. Untuk memastikan bahwa rute dipertahankan setelah reboot, Anda dapat memasukkannya ke dalam /etc/rc.d/rc.local, tapi lebih baik melalui file pengaturan /etc/sysconfig/network-scripts/route-eth1 (catatan: sintaks berbeda digunakan di sini).
Instal keepalive di kedua server TM. Kami menggunakan rpmfind.net sebagai sumber distribusi:
[root@tm6_1 ~]#yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/keepalived-1.2.13-5.el6_6.x86_64.rpmDalam pengaturan keepalive, kami menetapkan salah satu server sebagai master, yang lain sebagai cadangan. Kemudian kita atur VIP dan layanan untuk loadbalancing. File pengaturan biasanya terletak di sini: /etc/keepalived/keepalived.conf.
Pengaturan untuk Server TM1
vrrp_sync_group VG1 {
group {
VI_1
}
}
vrrp_instance VI_1 {
state MASTER
interface eth0
lvs_sync_daemon_inteface eth0
virtual_router_id 51
priority 151
advert_int 1
authentication {
auth_type PASS
auth_pass example
}
virtual_ipaddress {
10.20.20.105
}
}
virtual_server 10.20.20.105 1344 {
delay_loop 6
lb_algo wrr
lb_kind NAT
protocol TCP
real_server 192.168.1.101 1344 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 1344
nb_get_retry 3
delay_before_retry 3
}
}
real_server 192.168.1.102 1344 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 1344
nb_get_retry 3
delay_before_retry 3
}
}
}
virtual_server 10.20.20.105 25 {
delay_loop 6
lb_algo wrr
lb_kind NAT
protocol TCP
real_server 192.168.1.101 25 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 25
nb_get_retry 3
delay_before_retry 3
}
}
real_server 192.168.1.102 25 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 25
nb_get_retry 3
delay_before_retry 3
}
}
}
virtual_server 10.20.20.105 9100 {
delay_loop 6
lb_algo wrr
lb_kind NAT
protocol TCP
real_server 192.168.1.101 9100 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 9100
nb_get_retry 3
delay_before_retry 3
}
}
real_server 192.168.1.102 9100 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 9100
nb_get_retry 3
delay_before_retry 3
}
}
}Pengaturan untuk Server TM2
vrrp_sync_group VG1 {
group {
VI_1
}
}
vrrp_instance VI_1 {
state BACKUP
interface eth0
lvs_sync_daemon_inteface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass example
}
virtual_ipaddress {
10.20.20.105
}
}Kami memasang LVS pada master, yang akan menyeimbangkan lalu lintas. Tidak masuk akal memasang penyeimbang untuk server kedua, karena kami hanya memiliki dua server dalam konfigurasi.
[root@tm6_1 ~]##yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/ipvsadm-1.26-4.el6.x86_64.rpmPenyeimbang akan dikelola oleh keepalive, yang telah kita konfigurasikan.
Untuk melengkapi gambarannya, mari tambahkan keepalive ke autostart di kedua server:
[root@tm6_1 ~]#chkconfig keepalived onKesimpulan
Memeriksa hasil
Mari kita jalankan keepalive di kedua server:
service keepalived startMemeriksa ketersediaan alamat virtual VRRP
Mari kita pastikan bahwa VIP ada di master:
Dan tidak ada VIP sebagai cadangan:
Menggunakan perintah ping, kami akan memeriksa ketersediaan VIP:
Sekarang Anda dapat mematikan master dan menjalankan perintah lagi ping.
Hasilnya akan tetap sama, dan pada cadangan kita akan melihat VIP:
Memeriksa keseimbangan layanan
Mari kita ambil SMTP sebagai contoh. Mari luncurkan dua koneksi ke 10.20.20.105 secara bersamaan:
telnet 10.20.20.105 25Di master kita akan melihat bahwa kedua koneksi aktif dan terhubung ke server yang berbeda:
[root@tm6_1 ~]#watch ipvsadm βLn
Oleh karena itu, kami telah menerapkan konfigurasi layanan TM yang toleran terhadap kesalahan dengan memasang penyeimbang di salah satu server TM. Untuk sistem kami, hal ini mengurangi beban pada TM hingga setengahnya, yang memungkinkan penyelesaian masalah kurangnya penskalaan horizontal menggunakan sistem.
Dalam kebanyakan kasus, solusi ini diimplementasikan dengan cepat dan tanpa biaya tambahan, namun terkadang terdapat sejumlah keterbatasan dan kesulitan dalam konfigurasi, misalnya saat menyeimbangkan lalu lintas UDP.
Sumber: www.habr.com