Что делать, если мощности одного сервера не хватает для обработки всех запросов, а производителем ПО не предусмотрена балансировка нагрузки? Есть много вариантов – от покупки балансировщика нагрузки до ограничения числа запросов. Какой из них правильный, нужно смотреть по ситуации, принимая во внимание существующие условия. В этой статье мы расскажем, что можно сделать, если бюджет ограничен, а в наличии имеется свободный сервер.  В качестве системы, для которой необходимо было уменьшить нагрузку на один из серверов, мы выбрали 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 и правила маршрутизации: Вышеописанные команды работают до перезагрузки системы. Чтобы маршруты сохранились после перезагрузки, можно их вписать в /etc/rc.d/rc.local, но лучше через файл настроек /etc/sysconfig/network-scripts/route-eth1 (обратите внимание: здесь используется другой синтаксис). Устанавливаем keepalived на оба сервера TM. В качестве источника дистрибутива мы использовали rpmfind.net: В настройках keepalived назначаем один из серверов master, другой – backup. Затем задаем VIP и сервисы для балансировки нагрузки. Файл настроек обычно расположен тут: /etc/keepalived/keepalived.conf. Устанавливаем на master LVS, который будет балансировать трафик. Для второго сервера не имеет смысла устанавливать балансировщик, т. к. в конфигурации у нас всего два сервера. Управлять балансировщиком будет keepalived, который мы уже настроили.  Для полноты картины добавим keepalived в автозапуск на обоих серверах: Проверка результатов Запустим keepalived на обоих серверах: Проверка доступности виртуального адреса VRRP Убедимся, что VIP находится на master: А на backup нет VIP: С помощью команды ping проверим доступность VIP: Теперь можно выключить master и снова запустить команду ping. Результат должен остаться таким же, а на backup мы увидим VIP: Проверка балансировки сервисов Возьмем, к примеру, SMTP. Запустим одновременно два подключения к 10.20.20.105: На master мы должны увидеть, что оба подключения активны и соединены на разные сервера: Таким образом, мы реализовали отказоустойчивую конфигурацию сервисов TM c установкой балансировщика на один из серверов TM. Для нашей системы это снизило нагрузку на TM в два раза, что позволило решить проблему отсутствия горизонтального масштабирования средствами системы. Данное решение в большинстве случаев реализуется быстро и без дополнительных затрат, но иногда существует ряд ограничений и сложностей в настройке, например при балансировке UDP-трафика.