Что делать, если мощности одного сервера не хватает для обработки всех запросов, а производителем ПО не предусмотрена балансировка нагрузки? Есть много вариантов – от покупки балансировщика нагрузки до ограничения числа запросов. Какой из них правильный, нужно смотреть по ситуации, принимая во внимание существующие условия. В этой статье мы расскажем, что можно сделать, если бюджет ограничен, а в наличии имеется свободный сервер.

В качестве системы, для которой необходимо было уменьшить нагрузку на один из серверов, мы выбрали 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.

Настройки для сервера 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
        }
    }
}

Настройки для сервера 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 
        } 
}

Устанавливаем на 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-трафика.

Источник: habr.com