Простейший отказоустойчивый балансировщик layer 4

Простейший отказоустойчивый балансировщик layer 4Балансировщик 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

Установим утилиту командой:

Примечание: небольшую справку и список обязательных/необязательных параметров вы можете увидеть в файле /usr/share/doc/ucarp/README.Debian. Либо выполните команду ucarp —help.

Все настройки нужно прописывать в файле конфигурации сетевых настроек, открываем для редактирования /etc/network/interfaces первого сервера (Server 1, см. выше):

Конфигурация второго сервера будет отличаться лишь его собственным адресом, все остальное остается прежним:

Примечание: отличаться также могут и имена интерфейсов, но в моем случае они совпали.

Сохраняем конфигурацию, но сетку пока не перезапускаем.

Настройка ucarp на этом завершена. При отключении активного сервера, второй перехватит адрес за пару секунд. Вы можете включать в конфигурацию дополнительные опции, но для базового варианта рассмотренного выше более чем достаточно.

Тестирование Ucarp

Пришло время на обоих серверах выполнить команду:

Примечание: если вы выполняете работы на виртуальной машине Hyper-V, то не забудьте в дополнительных настройках сетевого интерфейса выставить галочку «Включить спуфинг MAC-адресов». В противном случае отказоустойчивый ip будет постоянно висеть активным на обоих ВМ. На других гипервизорах такого поведения не будет (p.s. VMWare не тестировал).

… и проверить как адрес «гуляет» между хостами. Для этого не поленитесь запустить ping отказоустойчивого ip и по очереди перезагружать хосты по несколько раз. Операция очень простая, но её выполнение даст вам железную уверенность в том, что все отработает как нужно в случае неблагоприятного сценария.

HAProxy

Перед настройкой HAProxy важно изменить один системный параметр.

Настройка ОС

При переезде отказоустойчивого ip на другой хост пришлось бы перезапускать HAProxy, поскольку он бы не прослушивал этот адрес. Исправить эту ситуацию поможет изменение параметра ядра net.ipv4.ip_nonlocal_bind 1.

Краткое описание:

Установка этой переменной позволяет отдельным локальным процессам выступать от имени внешнего (чужого) IP адреса. Это может оказаться полезным в некоторых случаях, когда необходимо прослушивать внешние (чужие) IP адреса, например сниффинг чужого траффика.

Активируем опцию парой команд:

После этого идем к установке HAProxy.

Настройка HAProxy

Установим пакет командой:

Забэкапим основной конфиг:

Открываем для редактирования новый файл /etc/haproxy/haproxy.cfg и вставляем следующее содержимое (секция global имеет значения по умолчанию, в остальные секции для наглядности включены лишь самые необходимые параметры):

Примечание: в данном примере я балансирую клиентские подключения к Exchange Server 2013.

Напомню, что балансировка осуществляется на 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.

comments powered by HyperComments
Обратный прокси на Nginx - blog.bissquit.com
2018-04-14 15:26:52
[…] в статье Простейший отказоустойчивый балансировщик layer 4 шла речь о балансировке на уровне tcp-соединений, то в […]