Что делать, если мощности одного сервера не хватает для обработки всех запросов, а производителем ПО не предусмотрена балансировка нагрузки? Есть много вариантов – от покупки балансировщика нагрузки до ограничения числа запросов. Какой из них правильный, нужно смотреть по ситуации, принимая во внимание существующие условия. В этой статье мы расскажем, что можно сделать, если бюджет ограничен, а в наличии имеется свободный сервер.
В качестве системы, для которой необходимо было уменьшить нагрузку на один из серверов, мы выбрали DLP (система предотвращения утечки информации) от InfoWatch. Особенностью реализации стало размещение функции балансировщика на одном из «боевых» серверов.
Одна из проблем, с которой мы столкнулись, – невозможность использования Source NAT (SNAT). Для чего это было нужно и как проблема была решена, мы расскажем далее.
Итак, первоначально логическая схема существующей системы выглядела следующим образом:
Трафик ICAP, SMTP, события с компьютеров пользователей обрабатывались на сервере Traffic Monitor (TM). При этом сервер базы данных легко справлялся с нагрузкой после обработки событий на TM, а вот нагрузка на сам TM была большой. Это было видно по возникновению очереди сообщений на сервере Device Monitor (DM), а также по загрузке процессора и памяти на TM.
На первый взгляд, если в эту схему добавить еще один сервер TM, то на него можно было бы переключить либо ICAP, либо DM, но такой способ мы решили не использовать, т. к. снижалась отказоустойчивость.
Описание решения
В процессе поиска подходящего решения мы остановились на свободно распространяемом ПО keepalived совместно с LVS. Поскольку keepalived решает задачу создания отказоустойчивого кластера, а также может управлять балансировщиком LVS.
То, к чему мы хотели прийти (снизить нагрузку на TM и сохранить текущий уровень отказоустойчивости), должно было работать по следующей схеме:
При проверке работоспособности выяснилось, что установленная на серверах кастомная сборка RedHat не поддерживает SNAT. В нашем случае мы планировали использовать SNAT для того, чтобы входящие пакеты и ответы на них отправлялись с одного и того же IP-адреса, иначе мы бы получили следующую картину:
Это неприемлемо. Например, прокси-сервер, отправив пакеты на Virtual IP (VIP) адрес, будет ожидать ответ с VIP, но в данном случае он придет с IP2 для сессий, отправленных на backup. Решение было найдено: потребовалось создать еще одну таблицу маршрутизации на backup и соединить два сервера TM отдельной сетью, как показано ниже:
Настройки
Реализуем схему из двух серверов с сервисами ICAP, SMTP, TCP 9100 и установленным на одном из них балансировщиком нагрузки.
Мы имеем два сервера RHEL6, из которых удалены стандартные репозитории и часть пакетов.
Сервисы, которые нам необходимо балансировать:
• ICAP – tcp 1344;
• SMTP – tcp 25.
Сервис передачи трафика от DM – tcp 9100.
Для начала нам надо спланировать сеть.
Виртуальный IP-адрес (VIP):
• IP: 10.20.20.105.
Сервер TM6_1:
• External IP: 10.20.20.101;
• Internal IP: 192.168.1.101.
Сервер TM6_2:
• External IP: 10.20.20.102;
• Internal IP: 192.168.1.102.
Затем включаем IP forwarding на двух серверах TM. Как это сделать на RedHat описано здесь.
Решаем, какой из серверов у нас будет главный, а какой – резервный. Пусть master – это TM6_1, backup – TM6_2.
На backup создаем новую таблицу маршрутизации balancer и правила маршрутизации:
[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 balancerВышеописанные команды работают до перезагрузки системы. Чтобы маршруты сохранились после перезагрузки, можно их вписать в /etc/rc.d/rc.local, но лучше через файл настроек /etc/sysconfig/network-scripts/route-eth1 (обратите внимание: здесь используется другой синтаксис).
Устанавливаем keepalived на оба сервера TM. В качестве источника дистрибутива мы использовали rpmfind.net:
[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.rpmВ настройках keepalived назначаем один из серверов master, другой – backup. Затем задаем VIP и сервисы для балансировки нагрузки. Файл настроек обычно расположен тут: /etc/keepalived/keepalived.conf.
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
}
}
}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
}
}Устанавливаем на master LVS, который будет балансировать трафик. Для второго сервера не имеет смысла устанавливать балансировщик, т. к. в конфигурации у нас всего два сервера.
[root@tm6_1 ~]##yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/ipvsadm-1.26-4.el6.x86_64.rpmУправлять балансировщиком будет keepalived, который мы уже настроили.
Для полноты картины добавим keepalived в автозапуск на обоих серверах:
[root@tm6_1 ~]#chkconfig keepalived onЗаключение
Проверка результатов
Запустим keepalived на обоих серверах:
service keepalived startПроверка доступности виртуального адреса VRRP
Убедимся, что VIP находится на master:
А на backup нет VIP:
С помощью команды ping проверим доступность VIP:
Теперь можно выключить master и снова запустить команду ping.
Результат должен остаться таким же, а на backup мы увидим VIP:
Проверка балансировки сервисов
Возьмем, к примеру, SMTP. Запустим одновременно два подключения к 10.20.20.105:
telnet 10.20.20.105 25На master мы должны увидеть, что оба подключения активны и соединены на разные сервера:
[root@tm6_1 ~]#watch ipvsadm –Ln
Таким образом, мы реализовали отказоустойчивую конфигурацию сервисов TM c установкой балансировщика на один из серверов TM. Для нашей системы это снизило нагрузку на TM в два раза, что позволило решить проблему отсутствия горизонтального масштабирования средствами системы.
Данное решение в большинстве случаев реализуется быстро и без дополнительных затрат, но иногда существует ряд ограничений и сложностей в настройке, например при балансировке UDP-трафика.
