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

Из чего выбирать?

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

Кроме того, системы балансировки нагрузки могут перенаправлять трафик клиентов на избранный сервер несколькими способами. Самые популярные: трансляция сетевых адресов (Network Address Translation) и отсылка через шлюз TCP (TCP gateway). В первом случае балансировщик на лету подменяет в пакете IP-адреса, чем скрывает IP сервера от клиента и наоборот. Если же IP клиента нужно конечному приложению для статистики или любых других операций, его обычно сохраняют в HTTP-заголовке X-Forwarded-for. При использовании другого протокола следует убедиться, что подобная возможность реализована. В случае TCP gateway балансировщик умеет управлять трафиком на L4 (транспортном) уровне и даже на уровне приложения (L7). Для этого он устанавливает соединение и смотрит внутрь пакета. Обычно клиент и приложение обмениваются информацией через балансировщик. Но в последнее время становится все более популярной конфигурация сервера с прямым возвратом (Direct Server Return, DSR) когда ответ от сервера идет к клиенту напрямую, а не через устройство балансировки. Использование DSR уменьшает нагрузку на балансировщик, но не позволяет использовать куки и расшифровывать SSL. Данный способ на порядок быстрее, чем использование NAT-балансировки, и позволяет сервисам видеть реальные IP-адреса клиентов.

Также в системах можно встретить разные методы балансировки. Разберемся с назначением некоторых из них. В настройках продуктов они могут иметь отличные названия или свои особенности в реализации, но часто их суть одна.
Самый простой - Round Robin DNS, это специальный DNS-сервер, содержащий несколько А-записей и их вес (опционально) и выдающий при запросе клиентов различные IP-адреса. Минусы очевидны. Он абсолютно не владеет информацией о текущей загрузке и состоянии бэкендов, не учитывает предыдущие подключения клиентов (немного сглаживает ситуацию DNS-кеш).

Есть аналогичный по названию алгоритм, но реализованный средствами самого балансировщика - Round Robin. Все клиенты равномерно распределяются по бэкендам, и обычно какие-либо другие параметры не учитываются. Алгоритм распределения по весу (Round Robin Weighted) учитывает значение параметра Weight, указанного для каждого сервера. Проставив больший вес для более мощного сервера, мы сможем направить к нему больше клиентов. Несколько иначе действует распределение по приоритету. В этом алгоритме работает только сервер с большим приоритетом, остальные подключаются, как правило, только в случае его отказа. Этот вариант позволяет строить кластер с одним активным узлом, например когда второй сервер выполняет другую роль и только подстраховывает первый. Еще один вариант - Least Connection (Least Session) - соединение принимает сервер, обслуживающий наименьшее количество соединений (сессий), но соединения могут быть разные (пользователь активен или пассивен) и, соответственно, давать разную нагрузку на сервер. А вот алгоритм Least Bandwidth учитывает действительную загрузку сети.

Hash sticky client - клиент привязывается к одному серверу, для этого в специальную таблицу помещается хеш-строка, указывающая на его IP. Возможны варианты. Клиент всегда идет к одному серверу, а в случае его выхода подключение невозможно. Или, когда не отвечает «родной», он соединяется с другими системами.

Доступность бэкендов определяется двумя: активный (keepalives, балансировщик сам опрашивает серверы) и пассивный (In-Band, контролируются текущие соединения, ответы сервиса).

BalanceNG

Проект номер один в списке - BalanceNG , является развитием Open Source решения Balance , но распространятся уже под двойной лицензией (коммерческой и бесплатной Free Basic License). В бесплатной версии можно подключать один виртуальный сервер и два узла, чего с учетом возможностей достаточно, чтобы без проблем справиться со средней, а иногда и большой нагрузкой. Представляет собой решение для балансировки IP-нагрузки, поддерживающее IPv6, предлагает несколько методов управления выбора бэкенда (Round Robin, Random, Weighted Random, Least Session, Least Bandwidth, Hash, Agent и Randomized Agent).

В продукте использован оригинальный движок, работающий на Layer 2 (Ethernet), балансировка ведется на основе IP-адреса клиента, без привязки к портам работать может с любым сервисом. Поддерживает DNS GSLB (Global Server Load-Balancing) и конфигурацию сервера с прямым возвратом Direct Server Return (DSR), когда ответ от сервера идет к клиенту напрямую, а не через устройство балансировки. Содержит настраиваемый агент проверки UDP, поддерживает VRRP для установки высокодоступных конфигураций на многих узлах. Встроенные механизмы позволяют произвести захват и сохранение пакетов при помощи pcap для дальнейшего исследования. Предусмотрено несколько вариантов проверки работоспособности конечных систем: агент, ping, TCP Open, скрипт и другие инструменты вроде wget.

Возможно резервирование балансировщика с репликацией NAT-состояний между основным и резервным узлами, клиент при переподключении подсоединяется к тому же серверу. Для сохранения сессии используется IP-адрес клиента и порт назначения. Поддерживается Linux bonding. Все таблицы хранятся в ОЗУ, но требования невелики, для 4 миллионов сессий достаточно 512 Мб памяти.
Может работать в Linux (с использованием сокета API PF_PACKET) и SPARC/Intel Solaris (Streams/DLPI API). Для установки предлагаются rpm (Red Hat RHEL 6 / CentOS) и deb (Debian/Ubuntu) пакеты и тарбал для остальных дистрибутивов. Также доступен готовый образ для виртуальной машины (на базе Ubuntu 8.04), что позволяет быстро развернуть нужную функциональность. Во время закачки будут показаны все пароли для входа. Агент (bngagent) поставляется с открытым исходным кодом и поддерживает Linux, Solaris, OS X, HP-UX и другие.
Какой-либо интерфейс для настройки не предусмотрен, все установки производятся при помощи конфигурационного файла /etc/bng.conf. В принципе, сложным его назвать нельзя, особенно учитывая, что на сайте проекта доступно более десятка готовых примеров, часто нужно лишь выбрать наиболее подходящий и отредактировать под себя.

HAProxy

Работает на нескольких архитектурах x86, x86_64, Alpha, SPARC, MIPS, PARISC. Официально поддерживает Linux 2.6.32+ (рекомендуется для максимальной производительности) и 2.4, Solaris 8–10, FreeBSD, OpenBSD. Установка и настройка тривиальны, хотя пакет в репозиториях не присутствует. Проект предлагает исходный код под лицензией GPL v2 и готовые бинарники под Linux/x86 Glibc 2.2 и Solaris8/Sparc.

Pound - прокси и балансировка HTTP и HTTPS

Первоначальная цель проекта Pound - распределение нагрузки между несколькими серверами Zope, в итоге получился узконаправленный инструмент, представляющий собой обратный прокси и балансировщик нагрузки для HTTP и HTTPS.

Балансировка производится по состоянию сессии и другим параметрам (URL, аутентификации, cookies, HTTP headers). Полная поддержка WebDAV. В отличие от HAProxy обрабатывает SSL. Разработан в IT-компании, занимающейся безопасностью, что также сказалось на возможностях продукта. Особенностью является наличие базовых функций Web Application Firewall, Pound умеет контролировать корректность заголовков HTTP и HTTPS, отбрасывая неправильные. По умолчанию пропускаются все запросы, но можно создать шаблоны URL и тип запросов (стандартные, расширенные, RPC и WebDAV), которые будут проверяться на соответствие. По результатам выбирается конечный сервер или соединение блокируется. Дизайн изначально предусматривает минимальное вмешательство в трафик (например, встраивание cookie), но может прописывать X-Forwarded-for для передачи на бэкенд сервера IP-адреса пользователя.

Поддерживает IPv6, может перебрасывать IPv6 клиентов к серверам IPv4. Информация о сеансе сохраняется, и клиент в последующем подключается к своему серверу.

Из специфики - возможна не только отправка соединения к бэкенду, но и редирект на другой URL.

Pound не требует много ресурсов, примечательно, что кроме как за считыванием SSL-сертификатов демон не обращается к харду. Может быть запущен в chroot и использовать setuid/setgid. Каких-либо встроенных механизмов отказоустойчивости нет. Проверка работоспособности бэкендов производится всегда по HTTP.

На процессоре уровня Pentium D позволяет достичь примерно 600–800 HTTP- и 200–300 HTTPS-соединений в секунду. Поэтому конек Pound - небольшие проекты с упором на доступность, безопасность и больший контроль над трафиком. Для более высокой нагрузки сами разработчики Pound рекомендуют воспользоваться другими решениями.

Установка и настройка не представляют больших сложностей, хотя и производятся при помощи конфигурационных файлов (документация очень подробная). Официально был протестирован на Linux, Solaris и OpenBSD. Проект предлагает только исходные тексты, в репозиториях SUSE, Debian и Ubuntu можно найти готовые пакеты, кроме этого, на сайте есть ссылки для Red Hat и готового дистрибутива, собранного на базе FreeBSD.

В терминологии компьютерных сетей балансировка (выравнивание) нагрузки – распределение процесса выполнения заданий между несколькими серверами сети с целью оптимизации использования ресурсов и сокращения времени вычисления.

Типы серверов, которые должны быть сбалансированы:

серверные кластеры;

межсетевые экраны;

серверы инспектирования содержания (такие как AntiVirus- или AntiSpam- серверы).

Обычно системы балансировки загрузки серверов используют возможности уровня L4 (UDP/TCP). При этом контролируется доступность сервера по IP-адресу и номеру порта и принимается решение: какому из доступных серверов следует переслать запрос. Наиболее часто для выбора сервера используется карусельный алгоритм (round-robin). В этом варианте предполагается, что все запросы создают одинаковую загрузку и длительность исполнения. В более продвинутых вариантах алгоритма используется уровень занятости сервера и число активных соединений.

Раньше возможности балансировки нагрузки встраивались в саму прикладную программу или операционную систему. Современные системы балансировки нагрузки должны удовлетворять следующим требованиям:

обеспечивать управление трафиком, чтобы гарантировать доступность приложения и распределение нагрузки в условиях фермы серверов (группа серверов, соединенных сетью передачи данных и работающих как единое целое);

ускорять выполнение приложений в несколько раз;

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

Здесь важно учитывать, что доступность IP-адреса и порта еще не гарантирует доступа к приложению.

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

Довольно существенные преимущества может предоставить система GSLB (Global Server Load Balancing), которая способна решать задачу балансировки для произвольно расположенных ферм серверов с учетом их удаленности от клиента. Эта система может поддерживать несколько разных алгоритмов распределения нагрузки и обеспечивать оптимальное обслуживание клиентов, разбросанных по всему миру. Для администраторов система дает возможность формирования гибкой политики управления ресурсами.

Одним из способов ускорения обслуживания является кэширование. В случае хорошо сконфигурированного кэша доля запросов, удовлетворяемых кэшем, может достигать 40%. При этом ускорение обслуживания может быть улучшено в 30 раз.

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

Управление балансировкой нагрузки можно совместить с функцией прикладного межсетевого экрана (70% успешных вторжений использует уязвимости приложений) и с использованием SSL по VPN-туннелю. SSL – Secure Sockets Layer – криптографический протокол, который обеспечивает установление безопасного соединения между клиентом и сервером.

Для достижения максимальной пропускной способности и отказоустойчивости межсетевые экраны позволяют распределить или сбалансировать нагрузку, используя все имеющиеся каналы Интернета (серверов) одновременно. Например, можно избежать такой ситуации, когда передаваемые по сети пакеты идут через одного провайдера, в то время как выход в Интернет через другого провайдера простаивает без дела. Или распределить сервисы и направить трафик через все имеющиеся Интернет-каналы. Возможна настройка балансировки нагрузки, если соединения с провайдерами осуществляются с разными типами подключения (Static IP, PPPoE, PPTP/L2TP), а также – для балансировки трафика, проходящего через VPN-туннели, установленные на разных физических интерфейсах.

Рис. 4.12. Балансировка нагрузки по нескольким маршрутам

В межсетевых экранах D-Link серии NetDefend предусмотрена функция, предназначенная для балансировки сетевой нагрузки по разным маршрутам – Route Load Balancing (RLB ) , возможности которой обеспечивают:

балансировку трафика между интерфейсами на основе политик;

балансировку нагрузки трафика при одновременном множественном доступе в Интернет, пользуясь услугами двух и более провайдеров;

балансировку трафика, проходящего через VPN-туннели, установленные на разных физических интерфейсах.

Функция балансировки нагрузки в межсетевых экранах NetDefend активируется на основе таблицы маршрутизации путем создания объекта RLB Instance , в котором определены два параметра: таблица маршрутизации и RLB-алгоритм. С таблицей маршрутизации может быть связан только один объект Instance.

Рис. 4.13. Выбор алгоритма распределения нагрузки в межсетевых экранах NetDefend

Есть возможность выбрать один из алгоритмов распределения нагрузки между Интернет-интерфейсами:

Алгоритм Round Robin распределяет нагрузку между интерфейсами WAN1 и WAN2 последовательно (поочередно). Каждый раз, когда возникает новая исходящая сессия с интерфейса LAN, выбирается интерфейс WAN1 или WAN2 для отправки пакетов. В дальнейшем, пакеты данной сессии будут использовать ранее определенный WAN-интерфейс. TCP-сессия открывается и закрывается на одном и том же WAN-интерфейсе.

Алгоритм Destination позволит избежать проблем с некоторыми протоколами при использовании балансировки, например FTP. Данный алгоритм работает аналогично алгоритму Round Robin, за исключением того, что все данные к удаленному хосту идут через тот интерфейс, через который соединение было установлено.

Значение Spillover определяет предельное значение нагрузки для основного WAN-порта (Routing → Route Load Balancing > Algoritm Setings ) . При достижении этой нагрузки за указанный период начнет использоваться второй WAN-порт (для новых сессий). Как только загрузка основного канала упадет, новые сессии будут открываться на нем.

Round Robin

Метрика каждого маршрута по умолчанию равна нулю. При использовании взаимосвязанных алгоритмов Round Robin и Destination можно устанавливать разные значения метрик, позволяющие создать приоритет выбора маршрутов. Маршруты с минимальным значением метрики будут выбираться чаще, чем маршруты с более высоким значением.

Если в сценарии с двумя Интернет-провайдерами (часто встречается выражение "ISP-провайдер", т.е. Internet Service Provider) требуется, чтобы большая часть трафика проходила через одно из ISP-подключений, то следует активировать RLB и назначить меньшее значение метрики для маршрута основного ISP-подключения (например, 90) относительно второго (например, 100).

Если задача заключается в равномерной балансировке трафика между двумя Интернет-провайдерами, то значение метрик для обоих маршрутов следует назначать одинаковое.

Использование метрик маршрута с алгоритмом Spillover

При использовании алгоритма Spillover для каждого маршрута обязательно должна быть определена метрика. В этом случае система NetDefendOS всегда выбирает маршрут с самым низким значением метрики. Алгоритм не предназначен для работы с одинаковыми метрическими значениями маршрутов, поэтому администратору следует устанавливать различные значения метрик для всех маршрутов, к которым применяется алгоритм Spillover .

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

Можно создать несколько альтернативных маршрутов с различными метрическими значениями, для каждого из которых определена пороговая величина настроек алгоритма – Spillover Setting – для каждого интерфейса. Сначала выбирается маршрут с минимальной метрикой; после того как превышен допустимый порог настроек алгоритма, будет выбран следующий маршрут.

Если на всех альтернативных маршрутах достигнуты пороговые значения Spillover Setting, то маршрут не меняется.

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

Балансировка нагрузки сети и НА-кластеризация (резервирование устройств) межсетевых экранов NetDefend

Высокий уровень сетевой отказоустойчивости достигается за счет использования двух межсетевых экранов NetDefend: основного устройства (master) и резервного устройства (slave). Основной и резервный межсетевые экраны взаимосвязаны и составляют логический HA-кластер.

Межсетевые экраны NetDefend не поддерживают балансировку нагрузки в НА-кластеризации устройств, т.е. распределение нагрузки между ними не обеспечиваетс , так как одно устройство всегда является активным (active), в то время как другое находится в режиме ожидания (passive).

Рис. 4.14. НА-кластеризация межсетевых экранов NetDefend

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

Инфраструктура без балансировки нагрузки выглядит так:

Пользователь → Интернет → Веб-сервер → Сервер баз данных

То есть пользователь подключается непосредственно к веб-серверу (к вашему домену, yourdomain.com). И если этот единственный веб-сервер прекращает работу, пользователь не сможет попасть на сайт. Кроме того, если множество пользователей одновременно попытается открыть сайт, сервер может попросту не справиться с нагрузкой: сайт будет загружаться очень медленно или же пользователь вовсе не сможет открыть его.

Устранить единую точку отказа можно с помощью балансировщика нагрузки и дополнительного веб-сервера на бэкэнде.

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

Пользователь
↓
Интернет
↓
Балансировщик нагрузки
↓ ↓
Веб-сервер 1 Веб-сервер 2
(реплицируемые серверы)

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

Какой трафик обрабатывает балансировщик нагрузки?

Администраторы балансировщиков создают правила для четырех основных типов трафика:

• HTTP: стандартная балансировка HTTP распределяет запросы согласно еханизмам HTTP. Балансировщик устанавливает заголовки X-Forwarded-For, X-Forwarded-Proto и X-Forwarded-Port, чтобы передать серверу бэкэнда информацию исходного запроса.
• HTTPS: балансировка HTTPS работает почти так же, как HTTP, но с поддержкой шифрования. Шифрование данных обрабатывается одним из двух способов: с помощью ретрансляции SSL (поддерживает шифрование вплоть до бэкэнда) или SSL-терминации (дешифровку данных выполняет балансировщик, после чего трафик отправляется на бэкэнд в незашифрованном виде).
• TCP: приложения, которые не используют HTTP или HTTPS, могут распределять трафик TCP. Например, можно разделить трафик кластера базы данных.
• UDP: совсем недавно некоторые балансировщики нагрузки добавили поддержку основных интернет-протоколов, которые используют UDP (например, DNS и syslogd).

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

Как балансировщик выбирает сервер на бэкэнде?

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

Проверка состояния сервера

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

Алгоритмы балансировки нагрузки

1. Согласно алгоритму Round Robin (или алгоритм кругового обслуживания) серверы получают трафик последовательно. Балансировщик выбирает первый сервер в списке и передаёт ему первый запрос, второй сервер получит второй запрос и т.д.
2. Балансировщик выбирает для обслуживания трафика наименее загруженный сервер (то есть сервер с наименьшим количеством подключений на текущий момент). Такой алгоритм особенно полезен, если для обслуживания трафика нужны длинные сессии.
3. Балансировщик нагрузки выбирает сервер на основе хэша исходного IP запроса (например, на основе IP-адреса посетителя). При этом все запросы конкретного пользователя будут обслуживаться одним и тем же сервером бэкэнда.

Обработка состояния

Некоторым приложениям необходимо, чтобы в течение работы пользователь оставался подключенным к одному и тому же серверу бэкэнда. Алгоритм, использующий IP-адрес посетителя, может обеспечить это условие. Также привязать сессию к серверу можно с помощью так называемых липких сессий (sticky sessions): при этом балансировщик устанавливает куки, и после этого все запросы этой сессии будут направлены на один и тот же физический сервер.

Резервные балансировщики нагрузки

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

Пользователь
↓
Интернет
↓ ↓
Балансировщик 1 Балансировщик 2

Если первый балансировщик перестанет работать, DNS передаст пользователей второму балансировщику. Изменения DNS иногда требуют много времени. Чтобы ускорить и автоматизировать переключение между балансировщиками, многие администраторы используют системы, которые поддерживают плавающие IP-адреса (или другие технологии преобразования IP). Эти технологии позволяют устранить некоторые проблемы, возникающие во время изменений DNS, предоставляя статичные IP-адреса, которые в дальнейшем при необходимости можно преобразовать. Доменное имя может быть связано с тем же IP, в то время как сам IP-адрес перемещается между серверами бэкэнда.

Заключение

Теперь вы знакомы с основами балансировки нагрузки. Узнать об этой технологии больше можно в следующих статьях:

Эта документация перемещена в архив и не поддерживается.

Обзор балансировки сетевой нагрузки

Назначение: Windows Server 2008 R2

Средство балансировки сетевой нагрузки (NLB) в Windows Server 2008 R2 повышает надежность и масштабируемость серверных приложений Интернета, используемых на веб-, прокси- и FTP-серверах, серверах брандмауэра и виртуальной частной сети (VPN) и на других ответственных серверах. Сервер на основе одного компьютера под управлением Windows Server 2008 R2 не будет обладать достаточно высоким уровнем надежности и масштабируемой производительности. Однако при объединении ресурсов нескольких компьютеров, на которых установлены программные продукты Windows Server 2008 R2, в единый виртуальный кластер технология балансировки сетевой нагрузки может обеспечить надежность и производительность, необходимые для веб-сервера и других ответственных серверов.

На приведенной выше схеме изображены два связанных кластера балансировки сетевой нагрузки. Первый кластер состоит из двух узлов, а второй - из четырех. Это один из примеров использования NLB.

На каждом узле выполняется отдельная копия заданных серверных приложений (например, приложений для веб-, FTP- и Telnet-сервера). NLB распределяет входящие клиентские запросы между узлами в кластере. Нагрузку, которую должен обрабатывать каждый узел, можно настроить в соответствии с требованиями. Если нужно обработать дополнительную нагрузку, узлы можно добавлять к кластеру динамически. Кроме того, NLB может направлять весь поток данных на один предназначенный для этого узел, называемый узлом по умолчанию.

NLB позволяет обращаться ко всем компьютерам в кластере по одному и тому же набору IP-адресов кластера и поддерживает набор уникальных, выделенных IP-адресов для каждого узла. Для приложений с балансировкой нагрузки при сбое на узле или его отключении нагрузка автоматически перераспределяется между работающими компьютерами. При сбое или неожиданном отключении компьютера все активные подключения к такому серверу будут потеряны. Но если работа узла завершается намеренно, можно с помощью команды drainstop обслужить все активные подключения до отключения компьютера. В любом случае отключенный компьютер, когда он будет готов к работе, может снова присоединиться к кластеру в рабочем режиме и взять на себя часть нагрузки, что позволит снизить объем данных, приходящийся на другие компьютеры кластера.

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

• выявляют узлы, оставшиеся активными членами кластера;
• назначают узел с наивысшим приоритетом узлом по умолчанию;
• обеспечивают обработку новых запросов клиентов работающими узлами.

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

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

Новые возможности NLB

Средство NLB в Windows Server 2008 R2 включает следующие усовершенствования.

• Расширенное сходство . Параметр «Расширенное» обеспечивает соответствие клиента при изменении конфигурации кластера балансировки сетевой нагрузки. Этот параметр также позволяет клиентам сохранять соответствие с узлом кластера в отсутствие активных текущих подключений от клиента к узлу.
• Оболочка Windows PowerShell для NLB-кластеров . Оболочка Windows PowerShell - это новая оболочка командной строки и язык сценариев. Оболочка Windows PowerShell увеличивает скорость автоматизации задач по администрированию системы. Windows PowerShell можно использовать для управления кластерами балансировки сетевой нагрузки. Дополнительные сведения об использовании оболочки Windows PowerShell для кластеров балансировки сетевой нагрузки см. в статье (может быть на английском языке) по адресу http://go.microsoft.com/fwlink/?LinkId=140180 .
• Поддержка чередующегося обновления . Балансировка сетевой нагрузки поддерживает чередующееся обновление Windows Server 2003 до Windows Server 2008 R2, а также Windows Server 2008 до Windows Server 2008 R2. Сведения о развертывании для NLB, в том числе о чередующемся обновлении, см. по адресу http://go.microsoft.com/fwlink/?LinkId=87253 .

  Настройка NLB

  Средство NLB работает как сетевой драйвер Windows. Его операции прозрачны для стека сетевых протоколов TCP/IP.

  

  На приведенной выше схеме показаны соотношения между NLB и другими компонентами в типовой конфигурации узла NLB.

  Возможности в балансировке сетевой нагрузки

  NLB включает следующие возможности.

  Масштабируемость

  Масштабируемость показывает, насколько можно расширить возможности компьютера, службы или приложения в соответствии с повышением требований к его производительности. Применительно к кластерам NLB масштабируемость - это возможность добавления одной или нескольких систем к существующему кластеру, когда общая нагрузка кластера превышает его текущую производительность. Поддержка масштабируемости реализуется в средстве балансировки сетевой нагрузки следующим образом.

  • Балансировка запросов нагрузки в пределах NLB-кластера для отдельных служб TCP/IP.
  • Поддержка до 32 компьютеров в одном кластере.
  • Балансировка запросов нагрузки для нескольких серверов (как от одного клиента, так и от нескольких клиентов) по нескольким узлам кластера.
  • Возможность добавления узлов к NLB-кластеру при возрастании нагрузки без перерыва в работе кластера.
  • Возможность удаления узлов из кластера при снижении нагрузки.
  • Реализация высокой производительности и снижение накладных расходов благодаря полнофункциональному конвейерному режиму. Этот режим позволяет отправлять запросы NLB-кластеру, не ожидая ответа на предыдущий запрос.

    Высокая надежность

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

    • Распознавание сбоя или отключения узла кластера и его восстановление.
    • Балансировка нагрузки сети при добавлении и удалении узлов.
    • Восстановление и перераспределение рабочей нагрузки в течение 10 секунд.

      Управляемость

      Имеются следующие возможности управления NLB.

      • Управлять несколькими кластерами NLB и узлами кластеров и настраивать их можно с одного компьютера с помощью диспетчера NLB.
      • Используя правила управления портами, можно задавать режим балансировки для отдельного IP-порта или группы портов.
      • Для каждого веб-сайта можно определить особые правила для портов. Если для нескольких приложений или веб-сайтов используется один набор серверов с балансировкой нагрузки, правила для портов выбираются по виртуальному IP-адресу назначения (с использованием виртуальных кластеров).
      • Все клиентские запросы можно направлять на один узел с помощью дополнительных правил одного узла. NLB будет направлять клиентские запросы на определенный узел, где выполняются заданные приложения.
      • Можно заблокировать доступ по сети к определенным IP-портам.
      • Для контроля переполнения коммутатора (при работе в многоадресном режиме) можно включить поддержку протокола IGMP (Internet Group Management Protocol).
      • Можно запускать, останавливать действия NLB и управлять ими с любого подключенного к сети компьютера под управлением Windows при помощи команд оболочки или сценариев.
      • События NLB можно просматривать в журнале событий Windows. В журнал событий записываются все действия NLB и изменения кластера.