Балансировщик layer 4 работает в качестве посредника между клиентом и сервером, выступая от имени первого. Помимо этого, он проверяет доступность хостов пулах бэкэнда и раскидывает по ним входящие клиентские запросы по установленному алгоритму балансировки. Чтобы сделать его отказоустойчивым, можно воспользоваться технологиями, предоставляющими функционал failover ip (например carp или vrrp или что-то другое).
Все это хотелось бы использовать во благо конкретного сервиса, а именно Exchange Server 2013. Об этом и поговорим.
Если вам интересна тематика Debian и связанных с ним приложений, рекомендую обратиться к тегу Debian на моем блоге
Содержание
Простейший отказоустойчивый балансировщик layer 4
Предложенный в статье вариант балансировки вы можете использовать для любого сервиса, которому не нужна поддержка сеансов на уровне приложений.
Настройка
Для начала нам понадобится два сервера с Debian 9. Это могут быть физические или виртуальные машины с единственным статическим ip-адресом на каждом.
- Server 1: 192.168.0.1
- Server 2: 192.168.0.2
- failover ip: 192.168.0.3
Переходим к настройке утилит.
Ucarp
Ucarp – свободная реализация протокола CARP, который позволяет нескольким серверам иметь дополнительный одинаковый ip-адрес из одной подсети. В конкретный момент времени адрес может быть активен только на одном сервере.
Настройка Ucarp
Установим утилиту командой:
|
1 |
apt-get install ucarp |
Все настройки нужно прописывать в файле конфигурации сетевых настроек, открываем для редактирования /etc/network/interfaces первого сервера (Server 1, см. выше):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
auto lo iface lo inet loopback auto eth0 allow-hotplug eth0 iface eth0 inet static address 192.168.0.1 netmask 255.255.255.0 gateway 192.168.0.254 ucarp-vid 1 ucarp-vip 192.168.0.3 ucarp-password password iface eth0:ucarp inet static address 192.168.0.3 netmask 255.255.255.0 |
Конфигурация второго сервера будет отличаться лишь его собственным адресом, все остальное остается прежним:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
auto lo iface lo inet loopback auto eth0 allow-hotplug eth0 iface eth0 inet static address 192.168.0.2 netmask 255.255.255.0 gateway 192.168.0.254 ucarp-vid 1 ucarp-vip 192.168.0.3 ucarp-password password iface eth0:ucarp inet static address 192.168.0.3 netmask 255.255.255.0 |
Сохраняем конфигурацию, но сетку пока не перезапускаем.
Настройка ucarp на этом завершена. При отключении активного сервера, второй перехватит адрес за пару секунд. Вы можете включать в конфигурацию дополнительные опции, но для базового варианта рассмотренного выше более чем достаточно.
Тестирование Ucarp
Пришло время на обоих серверах выполнить команду:
|
1 |
service networking restart |
… и проверить как адрес “гуляет” между хостами. Для этого не поленитесь запустить ping отказоустойчивого ip и по очереди перезагружать хосты по несколько раз. Операция очень простая, но её выполнение даст вам железную уверенность в том, что все отработает как нужно в случае неблагоприятного сценария.
HAProxy
Перед настройкой HAProxy важно изменить один системный параметр.
Настройка ОС
При переезде отказоустойчивого ip на другой хост пришлось бы перезапускать HAProxy, поскольку он бы не прослушивал этот адрес. Исправить эту ситуацию поможет изменение параметра ядра net.ipv4.ip_nonlocal_bind 1.
Краткое описание:
Установка этой переменной позволяет отдельным локальным процессам выступать от имени внешнего (чужого) IP адреса. Это может оказаться полезным в некоторых случаях, когда необходимо прослушивать внешние (чужие) IP адреса, например сниффинг чужого траффика.
Активируем опцию парой команд:
|
1 2 |
echo "net.ipv4.ip_nonlocal_bind=1" >> /etc/sysctl.conf sysctl -p |
После этого идем к установке HAProxy.
Настройка HAProxy
Установим пакет командой:
|
1 |
apt-get install haproxy |
Забэкапим основной конфиг:
|
1 |
mv /etc/haproxy/haproxy.cfg{,.backup} |
Открываем для редактирования новый файл /etc/haproxy/haproxy.cfg и вставляем следующее содержимое (секция global имеет значения по умолчанию, в остальные секции для наглядности включены лишь самые необходимые параметры):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
global log /dev/log local0 log /dev/log local1 notice chroot /var/lib/haproxy stats socket /run/haproxy/admin.sock mode 660 level admin stats timeout 30s user haproxy group haproxy daemon ca-base /etc/ssl/certs crt-base /etc/ssl/private ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS ssl-default-bind-options no-sslv3 defaults balance roundrobin log global mode tcp option dontlognull frontend fe_exch_443 bind 192.168.0.3:443 default_backend be_exch_443 backend be_exch_443 server exch2 192.168.0.102:443 check server exch1 192.168.0.101:443 check |
Напомню, что балансировка осуществляется на 4 уровне, о чем явно говорит строка конфига – mode tcp. Алгоритм балансировки – простой round robin (balance roundrobin) с проверкой доступности каждого хоста бэкэнда (check).
Тестирование HAProxy
Тестирование HAProxy на этом этапе очень похоже на тестирование Ucarp, только в этом случае проверять нужно не только доступность адреса утилитой ping, но и доступность конечного сервиса, подключения которого собственно и балансируются.
По очереди перезагружайте виртуальные машины и тестируйте доступность сервиса.
Область применения
Рассмотренный в статье вариант конфигурации применим к любым сервисам, которые умеют работать с балансировкой tcp-соединений.
Если говорить про Exchange, то для Exchange Server 2010 балансировка на 4 уровне не подходит, только 7 уровень 2:
Many Exchange 2010 Client Access protocols required affinity—a relationship between the client and a particular Client Access server. In particular, Outlook Web App, the Exchange Control Panel, Exchange Web Services, Outlook Anywhere, Outlook TCP/IP MAPI connections, Exchange ActiveSync, the Exchange Address Book Service, and Remote PowerShell either required or benefited from client-to-Client Access server affinity.
Кстати, отсутствие необходимости балансировки на 7 уровне стало одним из основных и самых серьезных архитектурных изменений в Exchange 2013 и последующих версиях.
Для Exchange 2013/2016 все, однако, не ограничивается балансировкой на 4 уровне. Вы вполне можете использовать и 7 уровень, чтобы отслеживать доступность каждого виртуального каталога на конкретном сервере. Но помните, что на стороне балансировщика это будет затрачивать на порядки больше ресурсов, учтите этот факт при планировании решения 3.
Notes:
