Bir sunucunun gücü tüm istekleri işlemek için yeterli değilse ve yazılım üreticisi yük dengeleme sağlamıyorsa ne yapmalısınız? Yük dengeleyici satın almaktan istek sayısını sınırlamaya kadar birçok seçenek vardır. Hangisinin doğru olduğu mevcut koşullar dikkate alınarak duruma göre belirlenmelidir. Bu yazımızda bütçeniz kısıtlıysa ve ücretsiz bir sunucunuz varsa neler yapabileceğinizi anlatacağız.
Sunuculardan birinin yükünün azaltılması gereken bir sistem olarak InfoWatch'tan DLP'yi (bilgi sızıntısını önleme sistemi) seçtik. Uygulamanın bir özelliği, dengeleyici işlevinin "savaş" sunucularından birine yerleştirilmesiydi.
Karşılaştığımız sorunlardan biri de Kaynak NAT'ın (SNAT) kullanılamamasıydı. Buna neden ihtiyaç duyuldu ve sorunun nasıl çözüldüğünü daha ayrıntılı olarak açıklayacağız.
Yani başlangıçta mevcut sistemin mantıksal şeması şuna benziyordu:
ICAP trafiği, SMTP, kullanıcı bilgisayarlarından gelen olaylar Traffic Monitor (TM) sunucusu üzerinde işlendi. Aynı zamanda veritabanı sunucusu, TM'deki olayları işledikten sonra yükle kolayca başa çıktı, ancak TM'nin üzerindeki yük ağırdı. Bu, Aygıt Monitörü (DM) sunucusundaki bir mesaj kuyruğunun görünümünden ve ayrıca TM üzerindeki CPU ve bellek yükünden açıkça anlaşılmaktadır.
İlk bakışta, bu şemaya başka bir TM sunucusu eklersek, ICAP veya DM'ye geçiş yapılabilirdi, ancak hata toleransı azaldığı için bu yöntemi kullanmamaya karar verdik.
Çözümün açıklaması
Uygun bir çözüm arama sürecinde özgürce dağıtılan yazılımda karar kıldık ile . Çünkü keepalived, yük devretme kümesi oluşturma sorununu çözüyor ve aynı zamanda LVS dengeleyiciyi de yönetebiliyor.
Başarmak istediğimiz şey (TM üzerindeki yükü azaltmak ve mevcut hata toleransı seviyesini korumak) aşağıdaki şemaya göre çalışmalıydı:
İşlevselliği kontrol ederken, sunuculara kurulu özel RedHat derlemesinin SNAT'ı desteklemediği ortaya çıktı. Bizim durumumuzda, gelen paketlerin ve bunlara verilen yanıtların aynı IP adresinden gönderilmesini sağlamak için SNAT kullanmayı planladık, aksi takdirde aşağıdaki resmi elde ederdik:
Bu kabul edilemez. Örneğin, bir Sanal IP (VIP) adresine paket gönderen bir proxy sunucusu VIP'den bir yanıt bekleyecektir, ancak bu durumda yedeklemeye gönderilen oturumlar için yanıt IP2'den gelecektir. Çözüm bulundu: Yedekte başka bir yönlendirme tablosu oluşturmak ve iki TM sunucusunu aşağıda gösterildiği gibi ayrı bir ağa bağlamak gerekiyordu:
Ayarlar
ICAP, SMTP, TCP 9100 hizmetlerine sahip iki sunucu ve bunlardan birinde yük dengeleyici kurulu olan iki sunucudan oluşan bir şema uygulayacağız.
Standart depoların ve bazı paketlerin kaldırıldığı iki RHEL6 sunucumuz var.
Dengelememiz gereken hizmetler:
• ICAP – tcp 1344;
• SMTP – TCP 25.
DM – tcp 9100'den trafik iletim hizmeti.
Öncelikle ağı planlamamız gerekiyor.
Sanal IP adresi (VIP):
• IP: 10.20.20.105.
Sunucu TM6_1:
• Harici IP: 10.20.20.101;
• Dahili IP: 192.168.1.101.
Sunucu TM6_2:
• Harici IP: 10.20.20.102;
• Dahili IP: 192.168.1.102.
Daha sonra iki TM sunucusunda IP yönlendirmeyi etkinleştiriyoruz. Bunun nasıl yapılacağı RedHat'ta anlatılıyor .
Sahip olacağımız sunuculardan hangisinin ana, hangisinin yedek olacağına biz karar veriyoruz. Ana TM6_1, yedek TM6_2 olsun.
Yedeklemede yeni bir dengeleyici yönlendirme tablosu ve yönlendirme kuralları oluşturuyoruz:
[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 balancerYukarıdaki komutlar sistem yeniden başlatılana kadar çalışır. Yeniden başlatmanın ardından rotaların korunduğundan emin olmak için bunları /etc/rc.d/rc.local, ancak ayarlar dosyası aracılığıyla daha iyi /etc/sysconfig/network-scripts/route-eth1 (not: burada farklı sözdizimi kullanılmıştır).
Keepalived'ı her iki TM sunucusuna da yükleyin. Dağıtım kaynağı olarak rpmfind.net'i kullandık:
[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.rpmKeepalive ayarlarında sunuculardan birini master, diğerini yedek olarak atadık. Daha sonra yük dengeleme için VIP ve hizmetleri ayarlıyoruz. Ayarlar dosyası genellikle burada bulunur: /etc/keepalived/keepalived.conf.
TM1 Server'a ilişkin ayarlar
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
}
}
}TM2 Server'a ilişkin ayarlar
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
}
}Trafiği dengeleyecek LVS’yi master üzerine kuruyoruz. Yapılandırmada yalnızca iki sunucumuz olduğundan ikinci sunucuya dengeleyici kurmanın bir anlamı yok.
[root@tm6_1 ~]##yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/ipvsadm-1.26-4.el6.x86_64.rpmDengeleyici, önceden yapılandırdığımız keepalived tarafından yönetilecektir.
Resmi tamamlamak için her iki sunucuda da otomatik başlatmaya canlı tutma özelliğini ekleyelim:
[root@tm6_1 ~]#chkconfig keepalived onSonuç
Sonuçları kontrol etme
Keepalived'i her iki sunucuda da çalıştıralım:
service keepalived startVRRP sanal adresinin kullanılabilirliğini kontrol etme
VIP'nin master'da olduğundan emin olalım:
Ve yedeklemede VIP yok:
Ping komutunu kullanarak VIP'nin kullanılabilirliğini kontrol edeceğiz:
Artık master'ı kapatabilir ve komutu tekrar çalıştırabilirsiniz. ping.
Sonuç aynı kalmalı ve yedeklemede VIP'yi göreceğiz:
Hizmet dengelemeyi kontrol etme
Örnek olarak SMTP'yi ele alalım. 10.20.20.105'e aynı anda iki bağlantı başlatalım:
telnet 10.20.20.105 25Master'da her iki bağlantının da aktif olduğunu ve farklı sunuculara bağlı olduğunu görmeliyiz:
[root@tm6_1 ~]#watch ipvsadm –Ln
Böylece, TM sunucularından birine dengeleyici kurarak TM hizmetlerinin hataya dayanıklı bir yapılandırmasını hayata geçirdik. Sistemimiz için bu, TM üzerindeki yükü yarı yarıya azalttı ve bu da sistemi kullanarak yatay ölçeklendirme eksikliği sorununu çözmeyi mümkün kıldı.
Çoğu durumda, bu çözüm hızlı bir şekilde ve ek maliyet olmadan uygulanır, ancak bazen, örneğin UDP trafiğini dengelerken yapılandırmada bir takım sınırlamalar ve zorluklar ortaya çıkar.
Kaynak: habr.com