Настройка балансировки нагрузки на InfoWatch Traffic Monitor

Настройка балансировки нагрузки на InfoWatch Traffic Monitor

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

В качестве системы, для которой необходимо было уменьшить нагрузку на один из серверов, мы выбрали DLP (система предотвращения утечки информации) от InfoWatch. Особенностью реализации стало размещение функции балансировщика на одном из «боевых» серверов.

Одна из проблем, с которой мы столкнулись, – невозможность использования Source NAT (SNAT). Для чего это было нужно и как проблема была решена, мы расскажем далее.

Итак, первоначально логическая схема существующей системы выглядела следующим образом:

Настройка балансировки нагрузки на InfoWatch Traffic Monitor

Трафик ICAP, SMTP, события с компьютеров пользователей обрабатывались на сервере Traffic Monitor (TM). При этом сервер базы данных легко справлялся с нагрузкой после обработки событий на TM, а вот нагрузка на сам TM была большой. Это было видно по возникновению очереди сообщений на сервере Device Monitor (DM), а также по загрузке процессора и памяти на TM.

На первый взгляд, если в эту схему добавить еще один сервер TM, то на него можно было бы переключить либо ICAP, либо DM, но такой способ мы решили не использовать, т. к. снижалась отказоустойчивость.

Описание решения

В процессе поиска подходящего решения мы остановились на свободно распространяемом ПО keepalived совместно с LVS. Поскольку keepalived решает задачу создания отказоустойчивого кластера, а также может управлять балансировщиком LVS.

То, к чему мы хотели прийти (снизить нагрузку на TM и сохранить текущий уровень отказоустойчивости), должно было работать по следующей схеме:

Настройка балансировки нагрузки на InfoWatch Traffic Monitor

При проверке работоспособности выяснилось, что установленная на серверах кастомная сборка RedHat не поддерживает SNAT. В нашем случае мы планировали использовать SNAT для того, чтобы входящие пакеты и ответы на них отправлялись с одного и того же IP-адреса, иначе мы бы получили следующую картину:

Настройка балансировки нагрузки на InfoWatch Traffic Monitor

Это неприемлемо. Например, прокси-сервер, отправив пакеты на Virtual IP (VIP) адрес, будет ожидать ответ с VIP, но в данном случае он придет с IP2 для сессий, отправленных на backup. Решение было найдено: потребовалось создать еще одну таблицу маршрутизации на backup и соединить два сервера TM отдельной сетью, как показано ниже:

Настройка балансировки нагрузки на InfoWatch Traffic Monitor

Настройки

Реализуем схему из двух серверов с сервисами 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 и правила маршрутизации:

[[email protected]_2 ~]echo 101 balancer >> /etc/iproute2/rt_tables
[[email protected]_2 ~]ip rule add from 192.168.1.102 table balancer
[[email protected]_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:

[[email protected]_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, который будет балансировать трафик. Для второго сервера не имеет смысла устанавливать балансировщик, т. к. в конфигурации у нас всего два сервера.

[[email protected]_1 ~]##yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/ipvsadm-1.26-4.el6.x86_64.rpm

Управлять балансировщиком будет keepalived, который мы уже настроили.

Для полноты картины добавим keepalived в автозапуск на обоих серверах:

[[email protected]_1 ~]#chkconfig keepalived on

Заключение

Проверка результатов

Запустим keepalived на обоих серверах:

service keepalived start

Проверка доступности виртуального адреса VRRP

Убедимся, что VIP находится на master:

Настройка балансировки нагрузки на InfoWatch Traffic Monitor

А на backup нет VIP:

Настройка балансировки нагрузки на InfoWatch Traffic Monitor

С помощью команды ping проверим доступность VIP:

Настройка балансировки нагрузки на InfoWatch Traffic Monitor

Теперь можно выключить master и снова запустить команду ping.

Результат должен остаться таким же, а на backup мы увидим VIP:

Настройка балансировки нагрузки на InfoWatch Traffic Monitor

Проверка балансировки сервисов

Возьмем, к примеру, SMTP. Запустим одновременно два подключения к 10.20.20.105:

telnet 10.20.20.105 25

На master мы должны увидеть, что оба подключения активны и соединены на разные сервера:

[[email protected]_1 ~]#watch ipvsadm –Ln

Настройка балансировки нагрузки на InfoWatch Traffic Monitor

Таким образом, мы реализовали отказоустойчивую конфигурацию сервисов TM c установкой балансировщика на один из серверов TM. Для нашей системы это снизило нагрузку на TM в два раза, что позволило решить проблему отсутствия горизонтального масштабирования средствами системы.

Данное решение в большинстве случаев реализуется быстро и без дополнительных затрат, но иногда существует ряд ограничений и сложностей в настройке, например при балансировке UDP-трафика.

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

Добавить комментарий