ZEN Load balancer часть №1. Теория и практика балансировки нагрузки

Zen Load Balancer. Все статьи >>

Когда нужна балансировка

Что есть балансировка нагрузки? Фактически, это распределение входящих сетевых подключений между несколькими вычислительными узлами. При этом, использование для этих целей аппаратных или программных решений, а так же применяемый алгоритм распределения сути, совершенно не меняет. Но, благодаря распределению нагрузки можно решить две достаточно серьезные проблемы.
Во-первых, это распределение нагрузки между вычислительными узлами в ситуации, когда ресурсов одного сервера не достаточно и вертикальное наращивание его мощности уже не возможно. В таком случае, необходимо добавление еще одной вычислительной единицы и применение одного из видов балансировки.
Во-вторых — обеспечение доступности. Как известно, отказоустойчивость любой системы, будь то аппаратное решение или программное достигается путем дублирования основных компонентов. К сожалению, не существует абсолютно надежных жестких дисков, RAID-контроллеров и прочего оборудования, а современный уровень программирования не гарантирует отсутствие сбоев в ПО. По этой причине, при построении отказоустойчивых сервисов, дублируется все, сетевые контроллеры, коммутаторы и в конце концов сами вычислительные узлы. Например, нагрузка создаваемая на один сервер может быть не большой, но при этом хочется, что бы выход одного или нескольких узлов не привел к простою сервиса. В этом случае решением снова может стать балансировщик нагрузки.

Основные виды и техники балансировки

По сути, все существующие виды балансировки можно разделить на три глобальные группы отличающиеся между собой «глубиной» анализа входящих запросов и степенью проверки доступности серверов.

Примитивные методы

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

Round robin DNS (циклический перебор)

Пожалуй, самый распространенный метод. Основан на том, что спецификация DNS позволяет создавать несколько одинаковых А-записей с отличными IP-адресами. Например, можно завести две записи для узла srv-01.company.com с различными IP-адресами принадлежащих, разным серверам. Дополнительно, должна быть включена специальная опция (Round robin) на DNS-сервере. В результате, при каждом новом запросе записи srv-01.company.com будут отдаваться разные IP-адреса, что приведет к равномерному распределению подключений между узлами.
Но, при всей легкости и дешевизне данного решения, имеется ряд ограничений. Во первых, нет никаких методов проверки доступности узлов. То есть, сервер может выйти из строя, но DNS все равно будет отдавать его IP-адрес клиентам. Во вторых, не учитывается число текущих сессий на том или ином узле. Может получиться ситуация, когда на одном из серверов, открытых сессий значительно больше чем на остальных, при этом подключения все равно будут распределяться равномерно. Ну и в-третьих, DNS не учитывает к какому серверу был подключен пользователь в прошлый раз. Возможно, что при каждом новом подключении, например, к терминалу или к веб-серверу, будет открываться новая сессия на другом узле, что может быть не желательно.
Отдельно, в этом пункте хочется выделить сервисы типа Amazon Route 53. Это облачный DNS-хостинг позволяющий кроме стандартных функций, указывать «вес» одинаковых А-записей, что позволяет распределять входящие запросы более гибко. Кроме этого, возможна интеграция с облачным балансировщиком нагрузки Elastic Load Balancing доступным в Amazon Web Services, что позволяет добиться еще более тонкой балансировки.

Так же, к примитивным методам можно отнести балансирование вручную

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

Балансировка на транспортном уровне (L4)

Это самый универсальный и распространенный механизм. Одинаково применим для TCP и UDP протоколов, а соответственно им можно распределять трафик практически любого сервиса. На этом уровне во входящих пакетах проверяется лишь IP-адрес и номер порта назначения. В случае совпадения с одним из правил, трафик будет попросту перенаправлен на указанные сервера, с помощью механизма sNAT в установленном порядке. Содержимое пакетов не проверяется. Так же нет никаких особых техник проверки доступности вычислительных узлов. Выполняется простая проверка доступности адреса и порта. В случае если порт открыт, сервер считается доступным и к нему продолжают отправляться запросы.
По такому механизму работает большинство популярных программных и аппаратных балансировщиков, в том числе Network Load Balancing (NLB) используемый в Windows Server. Так же, к этой категории можно отнести популярные нынче облачные сервисы типа Elastic Load Balancing от Amazon, упомянутый выше.

Балансировка на прикладном уровне (L7)

Динамично развивающийся вид распределения нагрузки на уровне приложений. Такие балансировщики еще называют контроллерами доставки приложений. Ориентированы на работу с высокоуровневыми протоколами. В основном HTTP\HTTPS. Здесь, как и в случае с предыдущим видом описываются правила. При установке соединения на некотором порту, пакеты перенаправляются на указанные адреса и порты вычислительных узлов. Но, при выборе конкретного сервера для ретрансляции на него трафика, учитывается тип клиента, URL, содержимое cookie, запрашиваемый контент и некоторые другие параметры. Кроме этого, проверка доступности сервиса на вычислительных узлах, проверяется значительно интеллектуальнее. Например, может запрашиваться некоторый URL и проверяться его содержимое.
Еще одной отличительной чертой этого типа от L4 является то, что сервера в кластере могут быть не идентичными. Например, одни узлы могут поставлять статические данные типа фото и видео а другие серверы доставляют контент с помощью скриптов, HTML и CSS. В таком случае, могут быть созданы правила для каждого типа контента с особыми алгоритмами перенаправления трафика на различные группы серверов. В этой категории, так же существует еще один класс профильных балансировщиков, типа Citrix NetScaler. Это решение специализируется на распределении нагрузки и повышении производительности продуктов Citrix (XenApp, XenDesktop), а так же веб-приложений. Кроме продвинутой балансировки он умеет выполнять компрессию контента, мощное кэширование, обеспечивает шифрование, а так же анализ трафика и его фильтрацию. Это лишь небольшая часть его возможностей, которые заслуживают отдельной статьи.