Высоко-доступный балансировщик Zen Load Balancer (ZenLB) Community Edition на базе 64-битной ОС Ubuntu Server 14.04

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

Выбор был сделан на проекте Zen Load Balancer Community Edition (далее ZenLB). Однако попытка более или менее полноценно внедрить это решение на платформе виртуализации Microsoft Hyper-V без дополнительных трудозатрат оказалась безуспешной. Дело в том, что все бесплатные балансировщики, являющиеся ответвлением своих старших коммерческих “братьев”, в своей базовой конфигурации имеют ряд совершенно умышленных ограничений. ZenLB не стал исключением в этой ситуации, и поставляется в виде ISO-образа (zenloadbalancer-distro_37.iso размером 243MB) пред-настроенного дистрибутива 32-битной версии Linux Debian 6. Мои попытки заставить адекватно работать виртуальные машины Hyper-V с этим 32-битным дистрибутивом положительного результата не дали. То есть, на первый взгляд, система устанавливалась и работала, но попытка перезагрузки ВМ, инициированная из гостевой ОС, практически всегда приводила к зависанию ОС в самом начале процесса загрузки, и лечилось это только путём полного выключения (Power Off в консоли Hyper-V Manager) и повторного включения ВМ. Позже выяснилось, что в данной проблеме я не одинок, и эта проблема загрузки касается не только Debian, но и других 32-битных дистрибутивов Linux. А здесь дяденька из Microsoft Open Source Technology Center вообще намекнул, что я зря трачу время. Пришлось изменить вектор изучения вопроса.

Помимо готового дистрибутива из apt-репозитория http://zenloadbalancer.sourceforge.net/apt/x86 v3/ можно загрузить *.deb пакет ZenLB вместе с пакетами-зависимостями, которых, как я понял, нет в официальных apt-репозиториях Debian. Упоминание о таком способе установки можно найти в онлайн-руководстве ZLB Administration Guide v3. Однако попытки заставить работать эти пакеты на 32-битной Ubuntu Server 14.04 по ранее упомянутой причине успехом также не увенчались, к тому же, как оказалось, установка компонент интеграции Hyper-V в 32-битной Ubuntu может оказаться настоящей головоломкой, решения которой я так и не нашёл. Единственным оставшимся вариантом, который приходил в голову, - это попытаться завести 32-битные deb-пакеты ZenLB на ВМ с 64-битной Ubuntu Server, так как положительный опыт виртуализации этой системы на Hyper-V G2 уже есть. Но из этого опять ничего дельного не получилось – пакеты-зависимости начали требовать ряд 32-битных библиотек, которых в 64-битной системе не было, а включение режима поддержки 32-битных пакетов не помог. В отчаянии я обратился за помощью к своему коллеге Владимиру Леттиеву, который, выслушав мою длинную историю, предложил попробовать адаптировать исходные коды (благо, что они доступны под лицензией GPLv2) под 64-битную Ubuntu Server 14.04 с последующей сборкой собственных deb-пакетов, то есть фактически создать собственный форк ZenLB.

В конечном итоге, после ряда проб и ошибок, нам удалось добиться успешной установки самого ZenLB и необходимых ему зависимостей, а также стабильной работы основного требуемого нам функционала этого балансировщика. Собранные deb-пакеты для удобства последующего развёртывания были размещены на локальном apt-репозитории.

Далее я кратко опишу процесс развёртывания deb-пакетов ZenLB на двух виртуальных машинах Hyper-V Gen2 с 64-битной Ubuntu Server 14.04.3 и последующую конфигурацию высокой доступности балансировщика.

 

Планируемая конфигурация

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

• ВМ с именем KOM-AD01-NLB11
  Один сетевой интерфейс eth0 с настройками:
  IP 10.1.0.211 MASK 255.255.255.0 GW 10.1.0.1
• ВМ с именем KOM-AD01-NLB12
  Один сетевой интерфейс eth0 с настройками:
  IP 10.1.0.212 MASK 255.255.255.0 GW 10.1.0.1

После развёртывания балансировщики будут собраны в кластер
с именем KOM-AD01-NLBCL.holding.com и IP 10.1.0.213

На базе этого кластера будет собрана NLB-ферма. Под ферму будет выделен собственный IP-адрес и имя для организации конечной точки подключения клиентов. В нашем примере будет создана ферма
с именем KOM-AD01-APPVCL.holding.com и IP 10.1.0.175, а бак-энд серверами будут KOM-AD01-APPV01 и KOM-AD01-APPV02.

 

Готовим виртуальные машины

В используемой у нас среде виртуализации Hyper-V на базе Windows Server 2012 R2 создаём две виртуальные машины второго поколения (Hyper-V G2) одинаковой конфигурации: 2 vCPU/2GB Static RAM/40GB Dynamic VHDX/1 сетевой интерфейс со статическим MAC-адресом/опция Безопасной загрузки (Secure boot) отключена. Для сетевого интерфейса обязательно нужно включить опцию разрешающую Спуфинг MAC-адресов:

На виртуальные машины устанавливаем ОС Ubuntu Server 14.04.3 LTS. Процесс установки ОС выполняем по аналогии с тем, что был описано ранее здесь. После установки обновляем все пакеты и ядро системы с последующей перезагрузкой:

sudo apt-get update
sudo apt-get dist-upgrade
sudo reboot

Затем устанавливаем дополнительные компоненты интеграции Hyper-V. Для этого выясняем текущую версию ядра ОС:

uname -r

В моём случае это 3.19.0-33-generic. Выполняем установку пакетов с подстановкой версии ядра:

sudo apt-get install hv-kvp-daemon-init linux-tools-3.19.0-33-generic linux-cloud-tools-3.19.0-33-generic

На вопрос о до-установке пакетов соглашаемся, а после окончания процесса установки перезагружаем систему и проверяем лог запуска:

cat /var/log/boot.log | grep Hyper 

* Starting Hyper-V File Copy Protocol Daemon           [ OK ]
* Starting Hyper-V VSS Protocol Daemon                 [ OK ]
* Starting Hyper-V KVP Protocol Daemon                 [ OK ]
* Stopping Hyper-V File Copy Protocol Daemon           [ OK ]
* Stopping Hyper-V VSS Protocol Daemon                 [ OK ]
* Stopping Hyper-V KVP Protocol Daemon                 [ OK ]

Явных ошибок запуска быть не должно. Теперь проверим наличие процессов установленных компонент Hyper-V в памяти:

ps -ef | egrep "hv.*daemon" 

root 884 1 0 20:16 ? 00:00:00 /usr/lib/linux-tools/3.19.0-33-generic/hv_vss_daemon
root 888 1 0 20:16 ? 00:00:00 /usr/lib/linux-tools/3.19.0-33-generic/hv_kvp_daemon 

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

На этом базовую настройку ВМ будем считать законченной, далее мы перейдём к установке ZenLB.

 

Устанавливаем ZenLB

Процедура установки пакетов ZenLB будет идентична для обоих виртуальных серверов. Перед началом установки хочу сделать одно важное предупреждение. ZenLB в процессе установки и последующей настройки модифицирует некоторые системные файлы, например безжалостно вычищает всё содержимое /etc/network/interfaces, поэтому крайне не рекомендуется разворачивать ZenLB на уже работающей продуктивной системе с какими-либо сетевыми сервисами.

Обновим кэш apt и посмотрим какая информация нам доступна о пакете zenloadbalancer из локального apt-репозитория

sudo apt-get update
sudo apt-cache show zenloadbalancer

Package: zenloadbalancer
Version: 3.7-1ubuntu11
Architecture: all
Maintainer: Vladimir Lettiev 
Installed-Size: 1833
Depends: mini-httpd, gdnsd, pen, pound, nagios-plugins-basic, ucarp, rrdtool, libnet-netmask-perl, libnet-ssh-perl, libexpect-perl, expect, libnet-ssh-expect-perl, libproc-daemon-perl, libnetwork-ipv4addr-perl, librrds-perl, libio-interface-perl, libgd-3dbargrapher-perl, libfile-grep-perl, libdata-validate-ip-perl, libpcap0.8, ntpdate, liblinux-inotify2-perl, iputils-arping, openssl, netstat-nat, libev4, snmpd
Homepage: http://www.zenloadbalancer.com/
Priority: optional
Section: net
Filename: pool/main/z/zenloadbalancer/zenloadbalancer_3.7-1ubuntu11_all.deb
Size: 598136
SHA256: 6395b0910440f0f0a808ccef57156e97c8a8d55f86684a733071cf2b1d7407dc
SHA1: ff66f7749a7fa71968bf9a15b01db79a21b04e49
MD5sum: 308a331fdf4beaec7a94d76cf1e68f14
Description: Multilayered load balancer with web GUI
 Zen Load Balancer is a multilayered and high performance load balancer whith an easy configuration, usability and user-friendly web GUI.
Description-md5: c1f2b3fa816801e2affaebf6becb4fdc

Устанавливаем:

sudo apt-get install zenloadbalancer

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

...
0 upgraded, 69 newly installed, 0 to remove and 0 not upgraded.
Need to get 9,302 kB of archives.
After this operation, 34.6 MB of additional disk space will be used.
Do you want to continue? [Y/n] Y
WARNING: The following packages cannot be authenticated!
  libdata-validate-ip-perl libfile-grep-perl libgd-3dbargrapher-perl
  libnet-ssh-expect-perl zenloadbalancer
Install these packages without verification? [y/N] Y
Get:1 http://my-repo.holding.com/ubuntu/ trusty/main libdata-validate-ip-perl all 0.24-1 [14.2 kB]
Get:2 http://my-repo.holding.com/ubuntu/ trusty/main libfile-grep-perl all 0.02-1 [8,388 B]
Get:3 http://my-repo.holding.com/ubuntu/ trusty/main libgd-3dbargrapher-perl all 0.9.6-1 [13.6 kB]
Get:4 http://my-repo.holding.com/ubuntu/ trusty/main libnet-ssh-expect-perl all 1.09-1 [23.7 kB]
Get:5 http://my-repo.holding.com/ubuntu/ trusty/main zenloadbalancer all 3.7-11 [584 kB]
...

Проверим, что создался TCP-прослушиватель для 444 порта веб-сервера, через который мы будем управлять ZenLB:

sudo ss -lnptu | grep 444

tcp    LISTEN     0      1024           :::444        :::*      users:(("mini-httpd",937,5))

Попробуем открыть в браузере ссылку https://KOM-AD01-NLB11:444, и при получении запроса аутентификации, указываем учётные данные по умолчанию – пользователь admin, пароль admin. Если веб-интерфейс доступен, перезагрузим сервер и убедимся в том, что ZenLB успешно автоматически стартует при запуске системы.

 

Меняем пароль администратора ZenLB

Итак, попав в веб-консоль управления ZenLB, в первую очередь уделим внимание вопросам безопасности. Перейдём в меню Settings > Users Management и изменим пароль пользователя admin с помощью кнопки Change. При установке пароля не имеет смыла задавать длинный пароль, так как используемый в ZenLB веб-сервер mini-httpd настроен таким образом, что пароли длиннее 9 символов усекаются (хотя веб-форма установки пароля никак об этом не предупреждает), и это может в дальнейшем привести к неприятным конфузам.

Также стоит отметить тот факт, что использовать кнопку Change & Sync with root passwd здесь смысла нет, так как в Ubuntu по умолчанию учётная запись root выключена (мы включим её позже на время процедуры создания кластера ZenLB, и только на одном из серверов).

Выполнить смену пароля учётной записи admin нужно на обоих наших серверах.

 

Меняем сертификат веб-сервера ZenLB

Выполнять замену сертификата используемого в веб-консоли ZenLB вовсе не обязательно, однако если вы не любите получать от браузера грозные предупреждения о недоверии самоподписанным сертификатам, то этот пункт для вас.

В конфигурационном файле /usr/local/zenloadbalancer/app/mini_httpd/mini_httpd.conf есть строка:

certfile=/usr/local/zenloadbalancer/app/mini_httpd/zenguicert.pem

То есть сертификат, расположенный в системе по указанному пути, отвечает за шифрование трафика при работе с веб-интерфейсом ZenLB.

Помимо этого, в веб-интерфейсе ZenLB (меню Manage > Certificates) вы можете обнаружить информацию ещё об одном сертификате с другим именем файла - zencert.pem

Фактически, этот сертификат расположен в системе по пути:
/usr/local/zenloadbalancer/config/zencert.pem. Если сравнить информацию об обоих этих сертификатах (zenguicert.pem и zencert.pem) с помощью команды типа…

openssl x509 -inform pem -in /path/to/cert.pem -noout -text

…то станет понятно, что фактически это копии одного и того же pem-файла (достаточно сверить хотя бы серийные номера сертификатов). Но это базовая конфигурация, и мы в силах её изменить. Ещё раз для ясности определимся с назначением этих двух сертификатов:

• Сертификат zencert.pem и любые другие сертификаты, которые мы можем самостоятельно загрузить через веб-интерфейс ZenLB, могут использоваться для создания фермы балансировки (пример создания такой фермы рассматривался ранее) HTTP с защищённым прослушивателем - HTTPS Farm listener
• Сертификат zenguicert.pem используется исключительно для защиты соединения сессии администратора при работе с веб-консолью ZenLB. Заменить данный сертификат своим через веб-консоль ZenLB у нас не получится (такой функционал попросту не реализован), однако можно выполнить эту задачу путём нехитрых манипуляций ниже.

Для начала нам нужно создать собственный pem-сертификат.

Локальный Центр сертификации (ЦС), доверенный в рамках нашей локальной сети, работает на базе Windows Server. Поэтому я буду создавать нужный мне сертификат по аналогии с ранее описанным способом.

Создадим файл конфигурации запроса с именем mini_httpd-server.cnf и содержимым типа:

[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req  

[req_distinguished_name]
commonName = FQDN of server
commonName_default = KOM-AD01-NLBCL.holding.com
countryName = Country Name (2 letter code)
countryName_default = RU
0.organizationName = Organization Name (eg, company)
0.organizationName_default = JSC NefteGazInvestOtkat Branch KOMI
localityName = Locality Name (eg, city)
localityName_default = Syktyvkar
organizationalUnitName = Organizational Unit Name (eg, section)
organizationalUnitName_default = IT Department

[v3_req]
subjectAltName = @alt_names

[alt_names]
DNS.1 = KOM-AD01-NLBCL.holding.com
DNS.2 = KOM-AD01-NLB11.holding.com
DNS.3 = KOM-AD01-NLB12.holding.com
DNS.4 = KOM-AD01-NLBCL
DNS.5 = KOM-AD01-NLB11
DNS.6 = KOM-AD01-NLB12

Как видно, я создаю запрос на сертификат с поддержкой альтернативных имён (Subject Alternative Names), чтобы использовать его в дальнейшем для установки на обоих серверах ZenLB.

Выполнять генерацию запроса с помощью утилиты openssl можно, как непосредственно на Linux-сервере, так и на Windows-машине.

Следующими двумя командами для будущего сертификата мы генерируем ключ и на основе конфигурационного файла и ключа генерируем бинарный запрос на выдачу сертификата к ЦС:

openssl genrsa -out mini-httpd-server.key 1024
openssl req -config mini-httpd-server.cnf -new -key mini-httpd-server.key -out mini-httpd-server.req

Передаём req-файл администратору ЦС, получаем от него результирующий X.509 сертификат и сохраняем этот сертификат (*.cer) в кодировке DER. Затем конвертируем сертификат в понятный для нашего веб-сервера PEM формат:

openssl x509 -in mini_httpd-server.cer -inform d -out mini_httpd-server.pem

Теперь нам нужно объединить в один файл содержимое ключа mini_httpd-server.key и сертификата mini_httpd-server.pem. На Linux это можно сделать так:

cat mini_httpd-server.pem  mini_httpd-server.key > zenguicert.pem

Чтобы заменить сертификат веб-сервера ZenLB, перепишем ранее упомянутый файл /usr/local/zenloadbalancer/app/mini_httpd/zenguicert.pem на собственный.

sudo cp /home/user/zenguicert.pem /usr/local/zenloadbalancer/app/mini_httpd/zenguicert.pem

Не забудем удалить из временного каталога результирующие файлы сертификатов и закрытый ключ, а также установим на установленный в mini_httpd сертификат с закрытым ключом более жёсткие разрешения:

rm ~/*.pem ~/*.key
chmod 400 /usr/local/zenloadbalancer/app/mini_httpd/zenguicert.pem

После этого перезапускаем сервер (перезапустить mini_httpd как отдельный сервис не получится, так как его контролирует ZenLB) и убеждаемся в том, что веб-интерфейс управления ZenLB использует новый сертификат. Таким образом заменяем сертификат на обоих наших виртуальных серверах и проверяем соответствующие URL https://KOM-AD01-NLB11:444 и https://KOM-AD01-NLB12:444

 

Настраиваем базовые параметры сервера

Из настройки базовых параметров через веб-интерфейс управления ZenLB (меню Settings > Server) на каждом из наших серверов можно сконфигурировать адрес NTP-сервера для синхронизации времени. В качестве NTP-сервера я указал ближайший контроллер домена со службой NTP.

Сетевой интерфейс и номер порта HTTPS используемого для веб-интерфейса управления ZenLB оставляем в значении по умолчанию. Более того, так как мы планируем построение кластера, эти настройки лучше не менять вообще, чтобы не столкнуться в дальнейшем с проблемами.

Службу SNMP Service можно включить, если планируется использование мониторинга системы по SNMP.

Настройки источников APT repository (отображается содержимое файла /etc/apt/sources.list) можно оставить без изменений.

Настройки DNS servers здесь менять смысла особого нет, так как содержимое файла /etc/resolv.conf в Ubuntu, как отмечалось ранее, управляется утилитой resolvconf. В свою очередь resolvconf для генерации содержимого resolv.conf использует, в частности, данные из файла /etc/network/interfaces, который в свою очередь опять-таки безжалостно перетирается ZenLB. Поэтому нам придётся договариваться о нужных настройках DNS с resolvconf отдельно путём создания дополнительного настроечного файла:

sudo nano /etc/resolvconf/resolv.conf.d/tail

Содержимое этого файла:

#
# This settings auto-including to /etc/resolv.conf 
# from /etc/resolvconf/resolv.conf.d/tail by tool - resolvconf
#
nameserver 10.1.0.9
nameserver 10.1.6.8
search holding.com
domain holding.com

Выполним регенерацию resolv.conf

sudo resolvconf -u

Подобным образом настраиваем оба виртуальных сервера.

 

Создаём кластер ZenLB

Базовая настройка обоих серверов выполнена и теперь перейдём к созданию кластера. Для этого перейдём на веб-интерфейс первого сервера (KOM-AD01-NLB11) и в меню Settings > Interfaces на базе существующего физического интерфейса eth0 создадим виртуальный интерфейс, например eth0:1 и присвоим ему новый IP адрес, который будет использоваться для создания будущего UCARP-кластера. 

После этого перейдём в меню Settings > Cluster, и выбрав в окне Virtual IP for Cluster только что созданный виртуальный интерфейс, нажмём кнопку Save VIP.

После этого веб-форма расширится и появятся новые поля, в которых нужно будет занести информацию об узлах создаваемого кластера. Информация о текущем узле (KOM-AD01-NLB11) уже будет заполнена, нам потребуется заполнить поля о втором сервере (KOM-AD01-NLB12) Remote hostname и IP. Значения полей Cluster ID (идентификатор создаваемого кластера; нужно указывать если в сети используется несколько кластеров) и Dead ratio (интервал отсутствия ответа от узла, прежде чем он начнёт считаться недоступным) в большинстве случаев можно оставить в значениях по умолчанию. Нажимаем кнопку Save 

После нажатия Save появится окно ввода пароля административного пользователя на втором сервере (KOM-AD01-NLB12). Ввод административных учётных данных со второго сервера потребуется для того, чтобы первый сервер смог обменяться с ним служебными ключами и установить доверительные отношения, которые будут в дальнейшем использоваться для репликации настроек кластера между узлами.

Здесь нужно учесть тот факт, что веб-интерфейс ZenLB был написан под Debian, в котором учётная запись пользователя root по умолчанию включена и используется. В нашем случае используется Ubuntu, где эта учётная запись root отключена. На время операции создания RSA connection нам потребуется задать пароль для учётной записи root на удалённом сервере (KOM-AD01-NLB12):

sudo passwd root

Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully

После установки пароля разблокируем учётную запись:

sudo passwd -u root

passwd: password expiry information changed.

Убедиться в том, что пароль для учётной записи root установлен и учётная запись активирована, можно заглянув в файл /etc/shadow, где теперь строка относящаяся к пользователю во втором столбце вместо одного знака “!” (определяет запрет использования данного логина) содержит некий хэш пароля и не начинается с символа “!”.

Помимо этого, на том же втором сервере (KOM-AD01-NLB12) добавим пользователю root право входа в систему по протоколу SSH. Откроем на редактирование конфигурационный файл службы SSH-сервера:

sudo nano -Y sh /etc/ssh/sshd_config

и отредактируем в нём один параметр:

#PermitRootLogin without-password
PermitRootLogin yes

Если в конфигурационном файле /etc/ssh/sshd_config присутствует параметр ограничения доступа для перечисленных групп, то туда нужно будет добавить и группу root:

# User groups access contol
AllowGroups root adm kom-srv-adm-linux-admins scom-user

Сохраним изменения в файле sshd_config и перезапустим службу сервера SSH

sudo service ssh restart

После этого проверим любым SSH-клиентом возможность подключения к серверу по протоколу SSH с учётной записью root. Если подключение прошло успешно, возвращаемся на веб-интерфейс ZenLB сервера KOM-AD01-NLB11 и продолжаем конфигурирование кластера, введя в соответствующее окно только что заданный пароль пользователя root на сервере KOM-AD01-NLB12. Нажимаем кнопку Configure RSA connection between nodes 

Дожимаемся вывода сообщений об успешном установлении доверительных отношений между узлами кластера:

После перемещаемся чуть ниже в текущей диалоговой веб-форме и конфигурируем тип кластера в окне Cluster type. На выбор предлагается 2 варианта.

В первом случае текущий сервер KOM-AD01-NLB11 всегда будет выступать в качестве основного (master), а удалённый сервер KOM-AD01-NLB12 всегда будет выступать лишь в роли резервного (backup). То есть все будущие NLB-ресурсы (фермы балансировки) будут становиться активными на втором узле лишь в случае недоступности первого (failover), а сразу после появления первого узла снова будут возвращаться на него (failback). Такой вариант имеет смысл использовать в случае, если, например, первый сервер по техническим характеристикам лучше, чем второй сервер.

Во втором случае оба сервера могут выступать в качестве master (в такой конфигурации failback не используется). Так как у нас фактически обе виртуальные машины имеют одинаковую конфигурацию, нам предпочтительней выбрать именно этот вариант.

Определившись с выбором, нажимаем кнопку Configure cluster type

Дождёмся, когда выполнятся все действия по настройке служб на обоих узлах и появится ссылка на обновление страницы…

После нажатия иконки обновления мы фактически будем перенаправлены на страницу управления кластерами (Settings > Cluster), при открытии которой будет происходить автоматический опрос состояния служб кластера на обоих серверах, в результате которого мы увидим какой узел в кластере является активным…

Также в правом верхнем углу веб-интерфейса ZenLB появится информация о статусе текущего узла – текущий узел является основным активным узлом кластера:

Если же открыть веб-интерфейс ZenLB на втором сервере (KOM-AD01-NLB12) на странице управления кластерами (Settings > Cluster), то там мы увидим аналогичную информацию о состоянии служб кластера на текущем узле и определении активного узла:

Ну и соответственно в правом верхнем углу мы также увидим информацию о том, что данный сервер является резервным узлом кластера:

Рядом со статусом узла будет виден значок, который будет нам напоминать о том, что все изменения настроек ферм балансировки нужно выполнять именно на активном узле кластера.

После создания кластера будет предпринята попытка отреплицировать все ранее созданные фермы балансировки с активного узла кластера на резервный и остановлены. Однако в нашем примере таких ферм ещё не создано и мы рассмотрим их создание далее.

По завершению процедуры создания кластера настроенную нами ранее учётную запись root на сервере KOM-AD01-NLB12 можно снова заблокировать, так как для дальнейшей работы кластера она уже не потребуется.

sudo passwd -l root

passwd: password expiry information changed.

Не забудьте также отменить правки в сделанные в конфигурационном файле SSH-сервера /etc/ssh/sshd_config с последующим перезапуском службы ssh.

 

Создаём ферму балансировки

Перейдём на веб-интерфейс ZenLB сервера, который является активным узлом кластера (не забываем про то, что в кластере настройки ферм балансировки нужно редактировать только с master-узла) и в меню Settings > Interfaces создадим отдельный виртуальный интерфейс eth0:2, который в дальнейшем будем использовать для создания фермы балансировки. Зададим IP адрес виртуальному интерфейсу (в нашем примере 10.1.0.175).

Как вы наверно уже поняли, созданный здесь виртуальный IP будет являться точкой подключения пользователей к ресурсу, который мы будем подвергать балансировке (Front-End IP).

Теперь перейдём в меню Manage > Farms и приступим к созданию новой фермы балансировки. Укажем произвольное имя создаваемой фермы, выберем её тип в поле Profile (в нашем примере будет выбран тип балансировки – HTTP). Пару замечаний относительно имени создаваемой фермы. Не стоит использовать длинные имена и всевозможные спецсимволы. Например очевидно, что если в имя добавить дефисы, то при сохранении параметров новой фермы эти дефисы будут удалены, хотя вернуть их обратно потом можно через режим редактирования настроек фермы. Это будет видно дальше на нашем примере. Есть и явные грабли, которых стоит избегать, например не стоит в имени использовать слово service, так как в последствие это может вызвать непредсказуемое поведение веб-интерфейса.

После нажатия кнопки Save & continue на веб-форме появляются параметры, в которых нужно выбрать виртуальный IP, который мы создали ранее для фермы и номер порта (в нашем примере будет использоваться порт 8080)

Указав интерфейс и порт, нажимаем кнопку Save. Как я и говорил ранее, дефисы из названия фермы при создании были автоматически удалены. Чтобы продолжить настройку фермы воспользуемся кнопкой редактирования. 

В открывшейся форме параметров фермы можем изменить название на то, которое мы хотели задать изначально (как ни странно, оно будет сохранено). Предложенные по умолчанию значения основных параметров фермы в большинстве случаев можно оставить без изменений. Если всё-таки изменяется какой-то из параметров, то для его применения нужно использовать кнопку Modify, находящуюся рядом с этим параметром.

Внизу формы есть поле добавления службы Add service, в которое нам нужно вписать произвольное имя службы (здесь тоже лучше постараться избежать использования длинных имён и спецсимволов) и нажать кнопку Add

Здесь наверно стоит внести ясность в вопросе, что такое служба, и зачем она нужна. Если сама ферма (Farm) по своей сути является виртуальным объектом, хранящим описание настроек фронт-энда балансируемого ресурса, к которому подключаются пользователи, то служба (Service) является описанием настроек бак-энда, то есть отражает физической уровень ресурса (конечные серверы, параметры распределения сессий клиентов по этим серверам и т.п.).

После того как служба будет добавлена, веб-форма расширится рядом настроек, касающихся этой службы. В частности, здесь в поле Persistence session можно будет задать необходимость "приклеивания" сессий пользователей к конечным серверам фермы. Это может быть необходимо, например, для веб-ресурсов, требующих аутентификации пользователей и отслеживающих пользовательские сессии. В моём примере выбран вариант основанный на клиентском IP адресе. В таблицу, расположенную в нижней части веб-формы добавляем IP адреса и номера портов (могут отличаться от номера порта фермы) конечных веб-серверов (Back-End IP). Здесь при необходимости для бак-энд серверов можно задать вес (Weigth), который будет определять приоритезацию распределения нагрузки клиентских запросов  между этими серверами.

После того, как все необходимые настройки фермы/службы заданы, перемещаемся в верхнюю часть веб-страницы и нажимаем на значок перезапуска фермы рядом с надписью Restart HERE! 

Перезапуск фермы с новыми настройками не должен вызывать никаких явных ошибок.

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

Аналогичным образом при необходимости мы можем создать ещё несколько других HTTP ферм. При этом можно использовать один и тот же адрес VIP для разных ферм (главное, чтобы не было пересечения по используемым портам). Или же можно использовать для каждой фермы выделенный VIP.  

 

Создаём записи в DNS для VIP адресов кластера и ферм балансировки

Теперь, по условиям нашей задачи, нам нужно создать в DNS пару записей. Первую запись для имени самого кластера ZenLB, а вторую для имени только что созданной фермы балансировки.

Первую запись создавать на самом деле вовсе не обязательно, так как она нужна нам только для удобства в административных целях, например, чтобы быстро проверить, жив ли наш кластер, командой ping KOM-AD01-NLBCL.holding.com. А вот вторую запись создать очень желательно, чтобы клиенты для подключения к ферме использовали это имя (бак-энд веб-серверы фермы должны принимать в качестве HTTP хидера это имя фермы).

После создания A-записи проверяем доступность фермы балансировки по имени с клиентских компьютеров сети командой ping KOM-AD01-APPVCL.holding.com

 

Проверяем работу фермы балансировки в кластере ZenLB

Убеждаемся в доступности фермы балансировки с клиентских компьютеров локальной сети через веб-браузером по соответствующему URL : http://KOM-AD01-APPVCL.holding.com:8080 

Чтобы увидеть текущее состояние фермы балансировки а также то, каким образом ZenLB распределяет клиентов по бак-энд серверам можем заглянуть в меню Monitoring > Conns stats:

Итак, на данный момент мы считаем, что наша ферма балансировки работает, и клиенты успешно подключаются к ресурсам через наш сервер балансировки. Теперь настало время проверить работу переключения кластерных ресурсов (фермы балансировки и ассоциированные с ними VIP) с активного узла кластера ZenLB на резервный в случае недоступности первого. Для этого есть, как минимум, два пути:

• приостановить (функция Pause в консоли Hyper-V Manager) виртуальную машину – активный узел кластера
• использовать функцию тестирования отказа на странице управления кластерами в веб-интерфейсе ZenLB (Settings > Cluster) (кнопка доступна на активном узле кластера):

На самом деле правильней будет отработать оба эти варианта, так как каждый из них представляет собой обработку отказа при разных исходных условиях. Второй вариант является более "мягким" и аналогичен ситуации, когда активный узел кластера ZenLB перезагружается путём штатного завершения работы ОС Ubuntu и работающие на нём фермы балансировки "переезжают" на второй узел кластера. Первый же вариант имитирует мгновенную недоступность активного узла кластера (может произойти, например, в случае отказа некластеризованного хоста виртуализации на котором расположена ВМ с ZenLB).

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

Если все тесты прошли успешно, то можно начинать планировать перевод используемых Windows NLB кластеров на ZenLB :)

 

Решение возможных проблем

В этом разделе я буду собирать записки об обнаруженных проблемах при эксплуатации ZenLB на Ubuntu 64-bit (кроме тех, что уже были описаны в вышеизложенном описании), их причинах и методах их решения. Если вы обнаружите ещё какие-то неописанные здесь проблемы и найдёте методы их решения, то можно будет дополнить данный раздел этой информацией.

Проблема: После перезагрузки системы не запускаются какие-либо сетевые службы использующие привязку к сетевым интерфейсам. Например, не стартует сервер ssh если настроен запуск прослушивателя на конкретном IP в /etc/ssh/sshd_config (явно задан IP в параметре ListenAddress).

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

Решение: Изменить конфигурационные файлы запуска проблемных служб в /etc/init/ таким образом, чтобы они стартовали после поднятия сетевых интерфейсов. Например, в случае с сервером ssh нам необходимо в файле etc/init/ssh.conf изменить параметры строки запуска службы с вида:

start on runlevel [2345]

…на вид:

start on ( runlevel [2345] and net-device-up IFACE!=lo )

Другим возможным вариантом решения (по сути “костыль”) подобных проблем может стать правка файла /etc/rc.local (в процессе загрузки ОС содержимое файла выполняется уже по окончании запуска всех системных служб), в который можно добавить команды запуска/перезапуска некорректно стартующих из-за деятельности ZenLB сетевых служб, например для той же службы ssh в этот файл можно добавить строку:

service ssh restart

Первый вариант более культурный, и поэтому лучше использовать именно его.

 

Где взять?

Ссылки на оригинальные пакеты ZenLB приведены в начале этой заметки.

Исходные коды форка Zenloadbalancer 3.7 for Ubuntu 14.04 можно найти на GitHub. 

Скомпилированный пакет ZenLB с зависимостями, которых нет в официальных apt-репозиториях  можно загрузить в виде zip-архива по ссылке.

 

Дополнительные источники информации:

• A random blog from a sysadmin - Load Balancing Exchange 2013 (CAS) with clustered (Zen) Load Balancers
• The Sysadminosaurus' IT blog - Zen Load Balancer Posts
• Talking IT - ZLB – Clustering