Меню

Zen load balancer настройка

Высоко-доступный балансировщик ZEVENET Load Balancer Community Edition 3.10.1 на базе виртуальных машин oVirt c 64-битной ОС Debian GNU/Linux 8.6

В конечном итоге было собрано четыре пакета:

Остальные пакеты, требуемые для ZLB, могут быть подтянуты из официальных репозиториев Debian в ходе установки перечисленных четырёх пакетов.

Подготовка виртуальных машин oVirt

Поэтому, специально для виртуальных машин ZLB нам потребуется создать дополнительный профиль vNIC, в котором никаких фильтров использоваться не будет:

После создания профиля vNIC, нужно выполнить его привязку к виртуальной машине, на которой будет работать ZLB, то есть к тому виртуальному интерфейсу ВМ, который будет членом кластера ZLB.

Для вступления изменений свойств виртуального сетевого адаптера в силу, потребуется выполнить перезагрузку гостевой ОС.

На виртуальные машины в самой простой конфигурации с одним виртуальным диском в 30GB, двумя vCPU и 2GB ОЗУ, была установлена 64-битная версия ОС Debian GNU/Linux 8.6.

Установка ZEVENET Load Balancer

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

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

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

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

Добавим в iptables правило, разрешающее подключаться на соответствующий TCP порт для доступа к веб-консоли управления ZLB:

Если веб-интерфейс доступен, перезагрузим сервер и убедимся в том, что ZLB успешно автоматически стартует при запуске системы.

Послеустановочная настройка ZEVENET Load Balancer

Если не соблюсти это условие, то при сборке кластера могут возникнуть проблемы.

ZEVENET Load Balancer и iptables

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

Перед тем, как собирать кластер ZLB, необходимо снять ограничения на сетевой обмен для будущих участников кластера. Для этого можно полезть в дебри и изучить весь меж-узловой обмен, чтобы настроить точные правила iptables. А можно пойти по пути наименьшего сопротивления и полностью открыть доступ будущих узлов кластера друг к другу. Например, на первом сервере ZLB добавим правило разрешающее весь входящий трафик со второго сервера ZLB:

Ну и соответственно на втором сервере ZLB разрешаем весь входящий трафик с первого узла ZLB:

Вообще ZLB так устроен, что самостоятельно хозяйничает в таблицах iptables «nat» и «mangle«, добавляя туда нужные правила. Однако, в случае, если в iptables используется блокировка всего явно не разрешённого правилами трафика (политика по умолчанию «DROP» для цепочек INPUT и FORWARD), то для того, чтобы разрешить трафик от фронт-энда к бак-энду ферм балансировки ZLB, в общих правилах iptables нам потребуется самостоятельно добавлять нужные правила в цепочку FORWARD (для ферм балансировки «L4xNAT«) и INPUT (для ферм балансировки «HTTP«).

В этом примере клиентские запросы на балансировщик приходят из клиентской сети 10.0.0.0/8 на фронт-энд адрес фермы балансировки 10.1.0.16:25 (он не фигурирует в правилах), а оттуда в свою очередь перенаправляются на 2 бак-энд сервера ( 10.1.0.29:25 и 10.2.0.22:25 ).

В этом примере клиентские запросы на балансировщик приходят из сети 10.0.0.0/8 на фронт-энд адрес фермы балансировки 10.1.0.15:443

Где взять?

Ссылки на оригинальные исходные тексты ZEVENET Load Balancer Community Edition приведены в начале этой заметки.

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

Источник

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

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

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

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

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

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

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

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

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

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

Читайте также:  Стерлись контакты в телефоне андроид при базовых настройках

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

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

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

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

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

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

Проверим, что создался TCP-прослушиватель для 444 порта веб-сервера, через который мы будем управлять 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 есть строка:

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

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

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

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

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

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

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

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

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

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

После этого перезапускаем сервер (перезапустить 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 ) можно оставить без изменений.

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

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

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

Создаём кластер 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

Читайте также:  Utorrent настройка под роутер

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

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

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

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

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

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

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

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

После перемещаемся чуть ниже в текущей диалоговой веб-форме и конфигурируем тип кластера в окне 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 можно снова заблокировать, так как для дальнейшей работы кластера она уже не потребуется.

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

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

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

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

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

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

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

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

Читайте также:  Сброс до заводских настроек samsung galaxy star plus

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

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

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

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

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

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

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

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

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

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

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

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

На самом деле правильней будет отработать оба эти варианта, так как каждый из них представляет собой обработку отказа при разных исходных условиях. Второй вариант является более «мягким» и аналогичен ситуации, когда активный узел кластера 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 изменить параметры строки запуска службы с вида:

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

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

Где взять?

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

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

Источник