Zen Load Balancer. Все статьи >>
Развертывание
Образ дистрибутива может быть развернут как на физический сервер, так и в качестве виртуальной машины без каких-либо сложностей. Требование дистрибутива к оборудованию, самые демократичные. Подойдет любой Debian-совместимый компьютер или платформа виртуализации. Для работы Zen LB достаточно одного сетевого интерфейса. В идеале, не плохо что бы их было два, один для управления, а второй для приема клиентских подключений.
Установка Zen LB не чем не отличается от таковой процедуры у любого другого дистрибутива Linux. На первом шаге мастер предложит выбрать язык для процесса установки. В списке присутствует русский, что значительно упростит это мероприятие для неопытных специалистов. Единственное чем выделятся дистрибутив, так это тем, что после выбора языка и страны он автоматически подставляет доступные для этой местности часовые пояса. Это, пожалуй логично, но очень не удобно для тех кто говорит по-русски, но проживает не в России. Поэтому, на последнем шаге установщика, необходимо перейти в пункт «Другие» и из полного списка выбрать нужный часовой пояс.
После установки, управление всеми параметрами балансировщика, осуществляется с помощью веб-интерфейса. Который стоит отметить выполнен качественно, приятен глазу и работает быстро и безотказно.
Настройка правил
Основная часть настроек балансировщика производится из веб-консоли доступной по HTTPS/81. Учетные данные по умолчанию admin и такой же пароль. Интерфейс крайне прост. Всего четыре раздела в одном из которых (About) текст лицензии GNU/GPL, поэтому реально полезных остается три. Кратенько пробежимся по каждому.
Рисунок №2. Интерфейс консоли управления
Раздел Settings. Тут общие настройки. Параметры NTP, DNS, смена пароля администратора, резервное копирование конфигурации сервера. Наиболее важные пункты здесь это Interfaces – создание виртуальных интерфейсов и Cluster, где можно собрать кластер из нескольких серверов Zen. Раздел Monitoring содержит различные графики и дает возможность просмотреть лог балансировщика. Ну и на конец, Manage. Здесь можно загрузить сертификат, подписанный доверенным центром сертификации который будет использоваться при работе по HTTPS. Так же, тут расположен, пожалуй, главный пункт — Farms. Именно здесь указываются адреса реальных серверов, а так же описываются правила распределения трафика. Для более наглядной демонстрации механизма работы приведу пример настройки балансировки для терминальных серверов Windows.
Допустим, что у нас их два: первый 10.200.77.45 порт 3389, второй 10.200.77.46 порт 3389. Терминальные службы могут работать и на других портах, отличных от стандартных, это не принципиально. Первое, что нам необходимо сделать, это создать новый, виртуальный интерфейс на котором Zen LB будет принимать подключения к терминальным серверам. Идем в Settings –> Interfaces и в строке с нашим физическим интерфейсом в колонке Action находим пункт add new virtual network interface. В появившееся новой строке, указываем произвольный порядковый номер интерфейса и задаем ему IP-адрес. Фактически будет создан обычный Alias.
Теперь нужно настроить новую ферму (farm). Ферма, это своего рода группа реальных серверов и описание того, где будет приниматься и по какому алгоритму пересылаться трафик конкретного сервиса. Итак, идем Manage -> Farms и в поле Farm Description Name: пишем произвольное описание нашего сервиса. Далее в выпадающем поле Profile необходимо выбрать тип балансировки: TCP, UDP, HTTP, L4xNAT и DATALINK. Так как терминальный сервер Windows работает по протоколу TCP то его и оставляем. После нажатия save появится новый пункт Virtual IP. Это интерфейс на котором балансировщик будет принимать входящие подключения. Выбираем из списка ранее созданный Alias и в поле рядом, указываем порт на котором слушать. Я указываю стандартный (3389), но при желании можно указать произвольный. Тогда, клиенты должны будут использовать именно его при подключении.
Теперь, когда ферма создана, в поле Action новой фермы находим пункт Edit и переходим к списку параметров балансировки. Тут и алгоритм, и параметры проверки серверов и различные количественные ограничения. Но самое главное, это таблица внизу Edit real IP servers configuration – список реальных серверов. Выбираем Add real server и указываем адрес реального сервера, порт, а также такие параметры как Max connections, Weight, Priority. В список можно добавить сколько угодно серверов.
Теперь, в настройках терминального клиента, указываем адрес нашего виртуального интерфейса и порт если он не стандартный и прозрачно попадаем на одни из терминальный серверов из списка добавленных.
Отказоустойчивость балансировщика
Естественно, что в приведенных выше примерах, единой точкой отказа является сам балансировщик. В случае его отказа доступ к сервисам будет не возможен. Поэтому в идеале, необходимо обеспечить резервирование. Для этого в дистрибутив Zen LB включены средства кластеризации. Возможно построение двух узлового кластера, без каких либо дополнительных сетевых адаптеров и прочих сложностей. Делается это следующим образом.
На одном из двух хостов Zen LB в разделе Setings –> Interfaces необходимо создать новый виртуальный сетевой интерфейс как в примерах выше. Это интерфейс управления кластером. По этому адресу всегда будет доступен текущий мастер. Далее в разделе Setings –> Cluster из выпадающего списка выбираем созданный ранее виртуальный интерфейс. Жмем save VIP(Virtual IP). Именно так кнопка и подписана в интерфейсе и save с маленькой буквы. и становятся доступными поля Local hostname и Remote hostname. Во втором поле указываем имя второго хоста Zen LB и его IP-адресс. Далее вводим пароль суперпользователя (root) на втором хосте. После указания пароля необходимо выполнить Сonfigure RSA Connection between nodes для установки соединения между хостами. И последним действием выбираем из выпадающего списка тип кластера (Cluster type):
node1 master and node2 backup automatic failback – это режим в котором текущий хост будет являться мастером и все подключения будут проходить через него. Второй же хост будет находится в резерве и станет мастером только при выходе первого. При возвращении в строй которого, второй вновь станет резервным.
node1 or node2 can be masters – все так же как и в первом варианте. Единственное отличие в том, что резервный хост, став мастером им и останется, даже если первый хост вернется в строй. Этот вариант подходит в случае если оба хоста равные по производительности и кто из них будет мастером в тот или иной момент не важно.
Жмем Configure cluster type и менее чем через минуту в поле Cluster status появятся сообщения об успешной сборке кластера и о доступности его членов. После этого, все настройки и параметры включая созданные ранее фермы будут воссозданы на втором хосте. Управлять кластером в дальнейшем необходимо через созданный для этого виртуальный интерфейс. При отказе мастера, переключение на резервный хост будет выполнено в течении одной-двух секунд.
Помогла ли вам статья?
