Zen Load Balancer. Все статьи >>
Почему ZEN
Прежде чем мой выбор остановился на ZEN Load balancer, я опробовал еще несколько кандидатов среди которых был классический HAProxy и не менее известный Linux Virtual Server. Все трое являются проектами с открытым исходным кодом. Касательно функционала они практически равны, по этому я не обращал на это особое внимание. Основными требованиями было легкость настройки и удобство управления. Во время установки и в процессе настройки дистрибутива Zen LB, присутствует чувство целостности, в нем все работает слаженно и предсказуемо. Именно благодаря этому пункту, практически не колеблясь выбор был сделан в пользу него.
Что из себя представляет Zen LB
Это дистрибутив Linux, в основе которого лежит переработанный Debian 6, от которого по сути оставлена лишь базовая система. Добавлен собственный балансировщик, и средства управления им. Первая версия была выпущена в 2011 году, текущий стабильный релиз 3.03. Обновления дистрибутива выходят по несколько раз в год.
Данный продукт представлен в двух редакциях:
- Бесплатная версия существует только в 32-х битном варианте, не имеет технической поддержки.
- Платная 64-х битная версия, стоит порядка 850 долларов. В стоимость включается техническая поддержка.
Получается, что единственным техническим ограничением бесплатной версии является предел по производительности и пропускной способности. У меня не было возможности произвести нагрузочное тестирование, но по тем данным, что я нашел в сети, 32-х битный Zen LB с легкостью справляется с тысячей пользователей Exchange, а так же с нескольким сотнями терминальных сессий. Конкретно в моем случаем, пользователей почты и терминального сервера было немного меньше. Но, главной задачей было прозрачное переключение на резервный сервер в случае выхода основного, и с этой задачей Zen LB справляется отлично.
Основные возможности Zen LB
- Классическая балансировка на транспортном (L4) уровне для протоколов TCP, UDP. Несколько алгоритмов распределения; по кругу, по весу (Weight), по приоритету (Priority) или по хэшу.
- Продвинутая балансировка на прикладном (L7) уровне для HTTP/HTTPS. На обоих уровнях (L4, L7) возможен возврат пользователя в открытую сессию. Идентификация уникальной сессии клиента возможна по нескольким алгоритмам;
- по IP-адресу клиента,
- по данным cookie,
- по основному заголовку при базовой аутентификации,
- по запрашиваемому URL,
- по настраиваемому полю заголовка HTTP.
- Возможна SSL-акселерация. В этом режиме Zen LB будет выполнять роль SSL-прокси. Это означает что канал будет шифроваться от клиента и до балансировщика, а взаимодействие самого Zen LB с реальными серверами фермы будет проходить без шифрования.
- Поддерживаются VLAN’ы.
- Допускается работа нескольких балансировщиков в кластерном режиме.
- Есть встроенная система резервного копирования и восстановления конфигурации.
- Присутствует система мониторинга и отображения нагрузки в виде графиков.
Так же, стоит отметить фирменный механизм проверки доступности реальных серверов – FarmGuardian. Эта технология позволяет использовать специальный скрипт для проверки работоспособности сервисов, нагрузка на которые должна быть распределена балансировщиком.
Профили балансировки
По сути, это выбор уровня балансировки. TCP и UDP балансируются классически на транспортном уровне, а HTTP соответственно прикладном. Помимо этого, присутствует вариант L4xNAT. Это та же балансировка на транспортном уровне только тут не учитываются номера портов. То есть трафик принимается на любых портах и перенаправляется в те же к реальным серверам. Это своего рода труба. Все что влетело, в том же виде и отправляется дальше.
Еще один профиль, не имеющий почти ничего общего с классической балансировкой нагрузки это DATALINK. Это новая функция в арсенале Zen LB. С его помощью можно осуществлять балансировку нагрузки между несколькими каналами связи. Например, когда организация имеет два канала в Интернет от различных провайдеров. Будучи в роли шлюза, Zen LB может прозрачно для пользователей переключаться между несколькими каналами или разделить по ним весь трафик.
Алгоритмы выбора сервера
Round-Robin: equal sharing – равное распределение. Примитивный алгоритм используемый по умолчанию. Входящие подключения равномерно распределяются между всеми реальными вычислительными узлами. Такие параметры серверов как Weight, Priority не учитываются.
Hash: sticky client – привязка клиента к одному серверу. Механизм работает следующим образом. Для каждого клиентского IP-адресса создается хеш-строка которая помещается в специальную таблицу. В дальнейшем, клиент идентифицируется по этой строке, а все принятые от него пакеты перенаправляются на один и тот же сервер.
Weight: connection linear dispatching by weight — распределение по весу. Этот алгоритм учитывает значение параметра Weight заданного (или не заданного) для каждого реального сервера. В зависимости от значения этого числового параметра будут распределены подключения. Это дает возможность более гибко настроить балансировку при разных по мощностям серверах.
Priority: connections to the highest priority available – распределение по приоритету (параметр сервера Priority). Этот алгоритм позволяет построить кластер по типу Активный-пасивный. Например, есть три узла. У первого значение приоритета выставлено в 12, у второго 8 и 4 у третьего. В таком случае, все входящие подключения будут направлены к серверу с наивысшим приоритетом, то есть к первому. В случае его отказа, трафик будет перенаправляться на следующий по значению приоритета сервер. И так, далее.
Как это работает
Базовая архитектура выглядит следующим образом. Zen LB располагается между клиентом и сервером. В идеале, реальные сервера доступны только ему и закрыты сетевым экраном от прямых клиентских подключений. Для получения доступа к тому или иному сервису, пользователю необходимо знать только адрес балансировщика. Собственно, к нему и направляются весь сетевой трафик. Далее в зависимости от отписанных правил, пакеты перенаправляются на наиболее подходящие сервера. В каждом конкретном случае, подходящий определяется в зависимости от выбранного алгоритма. Далее вся магия реализуется по средствам механизма sNAT, который занимается подменой IP-адресов, а также портов отправителя и получателя. В результате, сервер принимает пакеты как будто бы от самого балансировщика. Ему же он и возвращает ответ, в котором аналогичным образом заменяются IP-адреса и пакеты отправляются конечному клиенту. Таким образом распределение трафика происходит совершенно прозрачно для конечных пользователей и серверов его обрабатывающих.
Если откажет реальный сервер
Если по какой-то причине, реальный сервер не отвечает на указанном порту в течении времени определенном в параметре Backend response timeout (5 сек по умолчанию), то на этот сервер перестанут поступать новые подключения. В веб-консоли, не отвечающий узел будет помечен красной отметкой. Все активные сессии, естественно будут разорваны, а повторное подключение клиента уже будет выполнено к другому, рабочему серверу.
По умолчанию, через каждые 5 сек выполняется повторная проверка доступности отказавшего ранее узла (параметр Frecuency to check resurrected backends). Если сервер вновь начинает отвечать, то его ввод в эксплуатацию происходит автоматически.
Что из себя представляют правила
В правилах описывается, на каком интерфейсе и порте ожидать подключения и на какие адреса и порты их нужно отсылать. Это очень похоже на перенаправление портов – Port Riderect. Интерфейсов, на которых ожидаются подключения может быть множество.
Например, за балансировщиком, находится несколько веб-серверов, нагрузку на которые необходимо распределить равномерно. Для этого создается специальный, виртуальный сетевой интерфейс которому присваивается произвольный IP-адрес. Это обычный псевдоним (Alias) который не чем не отличается от такового в любой системе. Далее говорится, что необходимо слушать на этом интерфейсе и конкретном порту. Например на том, что используется по умолчанию на веб-сервере — 80. Затем следует список узлов находящихся за балансировщиком (адреса и порты реальных серверов) на которые нужно направлять поступающий трафик. В терминологии Zen, группа реальных серверов обслуживающих один сервис называется Фермой (Farm)
Все вышесказанное, можно наглядно увидеть на рисунке ниже.
Помогла ли вам статья?
