Балансировщик нагрузки Azure обеспечивает высокую доступность и производительность сети для приложений. Это балансировщик нагрузки уровня 4 (TCP, UDP), распределяющий входящий трафик между работоспособными экземплярами служб, определенных в наборе балансировки нагрузки.
Вот какие функции можно настроить в службе Azure Load Balancer:
Каждый хост балансировки сетевой нагрузки может указывать процент нагрузки, который он будет обрабатывать, или загрузка может быть одинаково распределена между всеми хостами. Используя эти проценты нагрузки, каждый сервер балансировки сетевой нагрузки выбирает и обрабатывает часть рабочей нагрузки. Клиенты статистически распределяются между узлами кластера, поэтому каждый сервер получает свой процент входящих запросов. Этот баланс нагрузки динамически изменяется, когда хосты вводят или покидают кластер.
В этой версии баланс нагрузки не изменяется в зависимости от разных нагрузок сервера. Для приложений, таких как веб-серверы, которые имеют многочисленные клиенты и относительно недолговечные клиентские запросы, способность балансировки сетевой нагрузки распределять рабочую нагрузку посредством статистического сопоставления эффективно балансирует нагрузки и обеспечивает быструю реакцию на изменения кластера.
- балансировка нагрузки входящего интернет-трафика виртуальных машин. Такая конфигурация называется балансировкой нагрузки для Интернета .
- Балансировка нагрузки трафика между виртуальными машинами в виртуальной сети, между виртуальными машинами в облачных службах или между локальными компьютерами и виртуальными машинами в распределенной виртуальной сети. Такая конфигурация называется внутренней балансировкой нагрузки .
- Перенаправление внешнего трафика к определенному экземпляру виртуальной машины.
Чтобы все ресурсы облака были доступны через Интернет, им необходимы общедоступные IP-адреса. В облачной инфраструктуре Azure в ресурсах используются немаршрутизируемые IP-адреса. Azure использует преобразование сетевых адресов (NAT) с общедоступными IP-адресами для обмена данными с Интернетом.
Серверы кластеризации балансировки сетевой нагрузки посылают сообщение о сердцебиении другим хостам в кластере и прослушивают биение других хостов. Если сервер в кластере выходит из строя, остальные хосты корректируют и перераспределяют рабочую нагрузку, поддерживая непрерывное обслуживание своих клиентов. Хотя существующие соединения с автономным хостом теряются, интернет-службы, тем не менее, остаются постоянно доступными. В большинстве случаев клиентское программное обеспечение автоматически повторяет неудавшиеся подключения, а клиенты испытывают только несколько секунд «задержки при получении ответа».
Модели развертывания Azure
Важно понимать различия между классической Azure и моделью развертывания с помощью Resource Manager. В каждой модели Azure Load Balancer настраивается по-разному.
классическая модель развертывания Azure
Виртуальные машины, развернутые в пределах границ облачной службы, можно сгруппировать для использования балансировщика нагрузки. В этой модели облачной службе назначаются общедоступный IP-адрес и полное доменное имя. Подсистема балансировки нагрузки преобразует порты и балансирует нагрузку сетевого трафика, используя общедоступный IP-адрес для облачной службы.
Состояние приложения относится к данным, поддерживаемым серверным приложением от имени своих клиентов. Балансировка сетевой нагрузки может использоваться для масштабирования приложений, которые управляют состоянием сеанса, охватывающим несколько соединений.
Это позволяет поддерживать состояние сеанса в Однако при сбое сервера или сети во время сеанса клиента может потребоваться новый вход в систему для повторной аутентификации клиента и восстановления состояния сеанса. Использование нескольких прокси-серверов на сайте клиента заставляет запросы от одного клиента появляться из разных систем.
Трафик с балансировкой нагрузки определяется конечными точками. Конечные точки преобразования портов связывают (связь "один к одному") общедоступный порт общедоступного IP-адреса и локальный порт, назначенный службе на определенной виртуальной машине. Конечные точки балансировки нагрузки связывают (связь "один ко многим") общедоступный IP-адрес и локальные порты, назначенные службам на виртуальных машинах в облачной службе.
В дополнение к состоянию сеанса серверные приложения часто поддерживают постоянную, основанную на сервере информацию о состоянии, которая обновляется клиентскими транзакциями, например, инвентарь товаров на сайте электронной коммерции. Чтобы воспользоваться балансировкой сетевой нагрузки, приложения должны быть разработаны таким образом, чтобы позволить нескольким экземплярам одновременно обращаться к серверу общей базы данных, который синхронизирует обновления. Например, веб-серверы с активными страницами сервера должны обновлять свои клиентские версии на общем сервере базы данных.
Рис. 1. Azure Load Balancer в классической модели развертывания
Меткой домена для общедоступного IP-адреса, который подсистема балансировки нагрузки будет использовать в этой модели развертывания, будет <имя_облачной_службы>.cloudapp.net. На представленной ниже схеме показан Azure Load Balancer в этой модели.
Модель развертывания диспетчера ресурсов Azure
В модели развертывания с помощью Resource Manager нет необходимости создавать облачную службу. Можно явно создать подсистему балансировки нагрузки для маршрутизации трафика между несколькими виртуальными машинами.
Архитектура балансировки сетевой нагрузки
Чтобы максимизировать пропускную способность и высокую доступность, балансировка сетевой нагрузки использует полностью распределенную программную архитектуру. Аналогичная копия драйвера балансировки сетевой нагрузки выполняется параллельно на каждом узле кластера. Таким образом, входящие клиентские запросы разделены и сбалансированы по нагрузке среди узлов кластера.
Эта архитектура максимизирует пропускную способность, используя широковещательную подсеть для доставки входящего сетевого трафика на все узлы кластера и устраняя необходимость маршрутизации входящих пакетов на отдельные узлы кластера. Поскольку фильтрация нежелательных пакетов быстрее, чем пакетов маршрутизации, балансировка сетевой нагрузки обеспечивает более высокую пропускную способность сети, чем решения на основе диспетчера. По мере роста пропускной способности сети и сервера ее пропускная способность также увеличивается пропорционально, тем самым устраняя любую зависимость от конкретной реализации аппаратной маршрутизации.
Общедоступный IP-адрес является отдельным ресурсом с меткой домена (DNS-именем). Общедоступный IP-адрес связывается с ресурсом подсистемы балансировки нагрузки. Правила балансировщика нагрузки и правила для входящих подключений NAT используют общедоступный IP-адрес в качестве конечной точки Интернета для ресурсов, получающих сетевой трафик с балансировкой нагрузки.
Напротив, решения на основе диспетчера создают неотъемлемую единую точку отказа, которая должна быть устранена с использованием избыточного диспетчера что обеспечивает только однопотоковый переход на другой ресурс. Это обеспечивает менее надежное решение для отказоустойчивости, чем полностью распределенная архитектура. Однако этот подход увеличивает нагрузку на коммутаторы, занимая дополнительную пропускную способность порта. Обычно это не касается большинства приложений, таких как веб-службы и потоковые медиа, поскольку процент входящего трафика составляет небольшую часть общего сетевого трафика.
Частный или общедоступный IP-адрес назначается ресурсу сетевого интерфейса, подключаемому к виртуальной машине. После добавления сетевого интерфейса в пул внутренних IP-адресов балансировщика нагрузки балансировщик нагрузки начинает отправлять сетевой трафик с балансировкой нагрузки на основе созданных правил балансировки нагрузки.
Распределение кластерного трафика
Однако, если клиентские сетевые подключения к коммутатору значительно быстрее, чем серверные соединения, входящий трафик может занимать непомерно большую часть пропускной способности порта на стороне сервера. Балансировка сетевой нагрузки использует широковещательную или многоадресную рассылку уровня 2 для одновременного распространения входящего сетевого трафика на все узлы кластера. Входящие пакеты получают, таким образом, все хосты кластера и передаются на драйвер балансировки сетевой нагрузки для фильтрации.
На представленной ниже схеме показан Azure Load Balancer в этой модели.
Рис. 2. Azure Load Balancer в диспетчере Resource Manager
Функции подсистемы балансировки нагрузки
Поддержка нескольких IP-адресов с балансировкой нагрузки для виртуальных машин
Вы можете назначить несколько общедоступных IP-адресов с балансировкой нагрузки набору виртуальных машин. Благодаря этому можно разместить несколько веб-сайтов SSL и/или несколько прослушивателей групп доступности AlwaysОn SQL Server в одном и том же наборе виртуальных машин. Дополнительные сведения см. в статье Несколько виртуальных IP-адресов для облачной службы .
Использование переключателя уровня выше по потоку также ограничит затопление коммутатора. Одноадресный режим балансировки сетевой нагрузки имеет побочный эффект отключения связи между узлами кластера с использованием адаптеров кластера. Этого ограничения можно избежать, добавив вторую карту сетевого адаптера к каждому узлу кластера. В этой конфигурации балансировка сетевой нагрузки привязана к сетевой адаптер в подсети, которая принимает входящие клиентские запросы, а другой адаптер обычно помещается в отдельную локальную подсеть для связи между узлами кластера и с файловыми серверами и серверами баз данных.
Различия балансировки нагрузки
Есть различные варианты для распределения сетевого трафика с помощью Microsoft Azure. Эти варианты работают по-разному, имеют разные наборы функций и поддерживают разные сценарии. Их можно использовать по отдельности или вместе.
- Azure Load Balancer работает на транспортном уровне (уровень 4 в эталонном стеке сети OSI). Она обеспечивает распределение трафика на уровне сети по экземплярам приложения, работающего в одном центре обработки данных Azure.
- Шлюз приложений работает на прикладном уровне (уровень 7 в эталонном стеке сети OSI). Он выступает в качестве службы обратного прокси-сервера, завершая подключение клиента и перенаправляя запросы к конечным точкам серверной части.
- Диспетчер трафика работает на уровне DNS. Он использует ответы DNS для перенаправления трафика пользователей к глобально распределенным конечным точкам. Затем клиенты подключаются к этим конечным точкам напрямую.
В следующей таблице перечислены возможности, предоставляемые каждой службой:
Балансировка сетевой нагрузки использует только адаптер кластера для его пульса и трафик дистанционного управления. Обратите внимание, что связь между узлами кластера и хостами вне кластера никогда не зависит от одноадресного режима балансировки сетевой нагрузки.
Возможности в балансировке сетевой нагрузки
Балансировка сетевой нагрузки обеспечивает второй режим для распределения входящего сетевого трафика на все узлы кластера. Вызывается многоадресный режим, этот режим назначает адрес многоадресной рассылки уровня для адаптера кластера вместо изменения адреса станции адаптера.
| служба | Azure Load Balancer | Шлюз приложений | Диспетчер трафика |
|---|---|---|---|
| Технология | Транспортный уровень (уровень 4) | Прикладной уровень (уровень 7) | Уровень DNS |
| Поддерживаемые протоколы приложений | Любой | HTTP, HTTPS и WebSocket | Любой (конечная точка HTTP обязательна для мониторинга конечных точек) |
| Endpoints | Экземпляры роли ВМ и облачных служб Azure | Любой внутренний IP-адрес Azure, IP-адрес общедоступного сегмента Интернета, виртуальная машина Azure или облачная служба Azure | Виртуальные машины Azure, облачные службы, веб-приложения Azure и внешние конечные точки |
| Поддержка виртуальной сети | Может использоваться для приложений с выходом в Интернет и внутренних приложений (в виртуальной сети) | Поддерживает только приложения с выходом в Интернет | |
| Мониторинг конечных точек | Поддерживается посредством проб | Поддерживается через метод GET в HTTP или HTTPS |
Azure Load Balancer и шлюз приложений направляют трафик к конечным точкам, но их сценарии использования при обработке трафика отличаются. Приведенная ниже таблица поможет понять разницу между этими балансировщиками нагрузки.
| Тип | Azure Load Balancer | Шлюз приложений |
|---|---|---|
| Протоколы | UDP и TCP | HTTP, HTTPS и WebSocket |
| Резервирование IP-адресов | Поддерживаются | Не поддерживается |
| Режим балансировки нагрузки | 5 кортежей (исходный IP-адрес, исходный порт, IP-адрес назначения, порт назначения, тип протокола). | Циклический перебор, |
| Режим балансировки нагрузки (исходный IP-адрес или прикрепленные сеансы) | 2 кортежа (исходный IP-адрес и IP-адрес назначения), 3 кортежа (исходный IP-адрес, IP-адрес назначения и порт). Можно масштабировать вверх или вниз в зависимости от числа виртуальных машин | Сходство на основе файлов cookie, маршрутизация на основе URL-адреса. |
| Пробы работоспособности. | По умолчанию: интервал выборки - 15 секунд. Изъятие из ротации: 2 последовательных сбоя. Поддерживает пользовательские пробы. | Интервал простоя пробы - 30 секунд. Изъятие после 5 последовательных сбоев в интерактивном трафике или одного сбоя пробы в режиме простоя. Поддерживает пользовательские пробы. |
| Разгрузка SSL | Не поддерживается | Поддерживаются |
| Маршрутизация на основе URL-адреса | Не поддерживается | Поддерживаются |
| Политика SSL | Не поддерживается | Поддерживаются |
В компьютерах, балансировка нагрузки распределяет нагрузку между несколькими вычислительными ресурсами, такими как компьютеры, компьютерные кластеры, сети, центральные процессоры или диски. Цель балансировки нагрузки - оптимизация использования ресурсов, максимизация пропускной способности, уменьшение времени отклика и предотвращение перегрузки какого-либо одного ресурса. Использование нескольких компонентов балансировки нагрузки вместо одного компонента может повысить надежность и доступность за счет резервирования. Балансировка нагрузки предполагает обычно наличие специального программного обеспечения или аппаратных средств, таких как многоуровневый коммутатор или система доменных имен, как серверный процесс.
Одноадресный режим балансировки сетевой нагрузки индуцирует наводнение коммутатора, чтобы одновременно доставлять входящий сетевой трафик на все узлы кластера. Балансировка сетевой нагрузки использует полностью распределенный алгоритм фильтрации для сопоставления входящих клиентов с узлами кластера. Этот алгоритм был выбран для того, чтобы позволить узлам кластера принимать решение о балансировке нагрузки независимо и быстро для каждого входящего пакета. Он был оптимизирован для обеспечения статистически сбалансированного баланса нагрузки для большого числа клиентов, создающих многочисленные, относительно небольшие запросы, например, типичные для веб-серверов.
Балансировка нагрузки отличается от физического соединения в том, что балансировка нагрузки делит трафик между сетевыми интерфейсами на сетевой сокет (модель OSI слой 4) основе, в то время как соединение канала предполагает разделение трафика между физическими интерфейсами на более низком уровне, либо в пакет (модель OSI уровень 3) или по каналу связи (модель OSI уровень 2); Основы с, как протокол соединения кратчайшего пути
Балансировка балансировки нагрузки нагрузки - балансирует входящие клиентские запросы, направляя выбранный процент новых запросов на каждый кластерный хост; процент нагрузки устанавливается в диалоговом окне «Свойства балансировки сетевой нагрузки» для каждого диапазона портов, который должен быть сбалансирован по нагрузке. Алгоритм не отвечает на изменения нагрузки на каждом узле кластера. Тем не менее, отображение изменяется при изменении членства в кластере, и проценты нагрузки перенормируются соответственно.
При проверке входящего пакета все хосты одновременно выполняют статистическое сопоставление, чтобы быстро определить, какой хост должен обрабатывать пакет. В этом случае все клиентские запросы будут обрабатываться одним узлом кластера, а балансировка нагрузки будет побеждена. Однако, если сближение клиента не включено, распределение клиентских портов внутри брандмауэра обычно обеспечивает хороший баланс нагрузки.
Примеры устройств, которые могут быть сбалансированы:
- Серверы DNS
Балансировка нагрузки может быть использована для расширения возможностей фермы серверов , состоящей более чем из одного сервера. Она также может позволить продолжать работу даже в условиях, когда несколько исполнительных устройств (серверов) вышли из строя. Благодаря этому растёт отказоустойчивость, и появляется возможность динамически регулировать используемые вычислительные ресурсы, за счёт добавления/удаления исполнительных устройств в кластере .
Проверка состояния сервера
В целом качество баланса нагрузки статистически определяется количеством клиентов, которые делают запросы. Это поведение аналогично монетам, в которых две стороны монеты соответствуют количеству узлов кластера, а количество томов соответствует количеству клиентских запросов. Как правило, с установленным аффинментом клиента должно быть гораздо больше клиентов, чем кластерные узлы, чтобы начать наблюдать равномерный баланс нагрузки.
Поскольку статистический характер населения клиента колеблется, равномерность баланса нагрузки может незначительно меняться со временем. Важно отметить, что достижение точно идентичного баланса нагрузки на каждом кластерном узле накладывает штраф за производительность из-за накладных расходов, необходимых для измерения и реагирования на изменения нагрузки. Это ограничение производительности должно оцениваться в интересах максимизации использования ресурсов кластера. В любом случае избыточные ресурсы кластера должны поддерживаться для поглощения нагрузки клиента в случае отказа.
Интернет-услуги
Циклический перебор DNSАльтернативный метод балансировки нагрузки, которая не обязательно требует специального программного или аппаратного обеспечения узла, называется раунд Робин с DNS . В этой технике, несколько IP-адресов, связанных с одним доменным именем ; клиенты должны выбрать сервер для подключения. В отличие от использования выделенной подсистемы балансировки нагрузки, эта методика предоставляет клиентам существование несколько серверов. Техника имеет свои преимущества и недостатки, в зависимости от степени контроля над DNS-серверов и степень детализации требуемой нагрузки. Балансировка сетевой нагрузки использует подход с использованием очень простого, но мощного алгоритма балансировки нагрузки, который обеспечивает максимально возможную производительность и доступность. Параметры привязки клиента балансировки сетевой нагрузки реализуются путем изменения входных данных алгоритма статистического сопоставления. Когда в диалоговом окне «Свойства балансировки сетевой нагрузки» выбрано клиент, информация о порте клиента не используется как часть отображения. Следовательно, все запросы от одного и того же клиента всегда сопоставляются с одним и тем же узлом в кластере. Другой, более эффективный метод для балансировки нагрузки с помощью DNS можно делегировать www.example.org в качестве суб-домена, для которого зона обслуживается каждый же серверах, обслуживающих веб-сайт. Эта техника работает особенно хорошо, где отдельные серверы разбросаны географически в Интернете. Например: One.example.org A 192.0.2.1 two.example.org A 203.0.113.2 www.example.org NS one.example.org www.example.org NS two.example.org Ограничение не имеет значения тайм-аута и сохраняется до тех пор, пока не произойдет изменение членства в кластере. Вместо этого настройки привязки параметров сетевой нагрузки используются для поддержки сеансов клиентов. Когда узел кластера выходит из строя или выходит из кластера, его клиентские соединения всегда удаляются. После того, как новое классовое членство определяется конвергенцией, клиенты, которые ранее сопоставлены с неудавшийся хост переименовывается среди выживших хостов. Все остальные клиентские сеансы не подвержены влиянию сбоя и продолжают получать бесперебойную службу из кластера. Тем не менее, файл зоны для www.example.org на каждом сервере отличается таким образом, что каждый сервер решает как использовать IP-адрес в качестве A-записи. На сервере одного файла зоны для отчетов www.example.org: @ in a 192.0.2.1 На сервере два тот же файл зоны содержит: @ in a 203.0.113.2 Таким образом, когда первый сервер не работает, его DNS не отвечает, и веб-служба не получает какого-либо движения. Если линия на одном сервере перегружена, ненадежная служба DNS обеспечивает меньше http-трафика который достигнет этого сервера. Кроме того, самый быстрый ответ DNS разрешителю почти всегда от сети ближайшего сервера, обеспечение гео-чувствительный балансировки нагрузки [нужная цитация ] . Короткий TTL на a-запись позволяет обеспечить трафик быстро отвлекаются, когда рухнет сервер. Необходимо учитывать возможность того, что эта методика может привести к индивидуальным клиентам переключаться между отдельными серверами в середине сессии. Алгоритмы планированияОдно основное решение проблемы данных сессии должны отправлять все запросы в сессии пользователя последовательно в тот же сервер. Это называется настойчивость(persistence) или липкость(stickiness) . Существенным недостатком этой технологии является отсутствие автоматической отработки отказа : если сервер выходит из строя, его сессионные информация становится недоступной, из всех сеансов теряется. Та же проблема обычно актуальна для центральной базы данных сервера; даже если веб-сервера являются «лицами без гражданства»(stateless) и не «липкий»(sticky), центральной базе данных (см. ниже). Отнесение к определенному серверу могут основываться на имени пользователя, клиентского IP-адреса , или могут быть случайными. Из-за изменения клиента воспринимаются адрес, вытекающих из протокола DHCP , трансляцию сетевых адресов и веб-прокси, этот метод может быть ненадежным. Случайные задания должны запоминаться балансировщиком нагрузки, который создает нагрузку на хранилище. Если балансировщик нагрузки заменяется или выходит из строя, эта информация может быть потеряна, и задания, возможно, должны быть удалены после заданного промежутка времени или в периоды высокой нагрузки, чтобы избежать превышения пространства, доступного для таблицы присвоений. Метод случайного присвоение также требует, чтобы клиенты поддерживают некоторые настройки, который может быть проблемой, например, когда Web-браузер отключил хранения файлов cookie. Сложные подсистемы балансировки нагрузки используют несколько методов сохранения, позволяющие избежать некоторых недостатков какого-либо одного метода. Другим решением является хранить сессионные данные в БД . Вообще это плохо для производительности, так как это увеличивает нагрузку на базу данных: базу данных лучше использовать для хранения информации менее изменяющуюся, чем сессионные данные. Чтобы предотвратить стать единой точкой отказа базу данных, и для повышения масштабируемости , базы данных часто реплицируются между несколькими компьютерами, и балансировки нагрузки используется для распространения индекса нагрузки между этими репликами. Технология Microsoft ASP.net State Server является примером сеанса базы данных. Все серверы в веб-ферме хранят данные сессии на Главном State Server сервер и любой сервер в ферме может извлечь данные. Очень распространены случаи когда клиентом является веб-браузер, простой, то эффективный подход-хранить сессионные данные в самом браузере. Одним из способов достижения этого является использование cookie браузера , временные зашифрованные метки. Другой способ - перезапись URL. Хранение данных сессии на клиенте, как правило, предпочтительное решение: тогда балансировщик нагрузки волен выбирать любой сервера для обработки запроса. Однако, этот метод обработки данных состояния плохо подходит для некоторых сложных сценариев бизнес-логики, где состояние сеанса является большой полезной нагрузкой и перечитывать его с каждым запросом на сервер не представляется возможным. Перезапись URL-адресов имеет серьезные проблемы безопасности, потому что конечный пользователь может легко изменять представленные URL и таким образом изменить потоки сессии. Еще одно решение для хранения постоянных данных, чтобы связать имя с каждым блоком данных, и использовать распределенную хэш-таблицу , чтобы псевдо-случайным образом присвоить имя одному из доступных серверов, а затем хранить, этот блок данных в назначенном сервере. Возможности балансировщика нагрузкиАппаратные и программные балансировщики нагрузки могут иметь различные специальные характеристики. Основная черта балансировщика нагрузки - иметь возможность распределять входящие запросы через несколько серверов в кластере по алгоритму планирования. Большинство из перечисленных ниже свойств конкретного поставщика: соотношение может быть назначено вручную вызывать некоторые сервера, чтобы получить большую долю нагрузки, чем другие. Это иногда используется в качестве способа когда одна часть серверов имеет больше возможностей, чем другие, и не всегда работают так, как хотелось.Балансировка нагрузки может оказаться полезным в приложениях с резервированием каналов связи. Например, компания может иметь несколько подключений к Интернету, обеспечивая доступ к сети, если одно из соединений не работает. В отказоустойчивых системах будет означать, что одно звено предназначено для нормального использования, а второе используется только в случае, если основной канал выйдет из строя. Используя балансировку нагрузки, обе ссылки могут быть заняты все время. Устройство или программа контролирует наличие всех звеньев и выбирает путь для отправки пакетов. Использование нескольких ссылок одновременно увеличивает доступную полосу пропускания. Кратчайший Путь ПреодоленияСтандарт IEEE утвердил стандарт IEEE 802.1 р-р стандартный мая 2012 года также известно и задокументировано в большинстве книг в качестве Кратчайшего пути преодоления (КПП) . КПП позволяет всем ссылкам, чтобы быть активными через несколько путей равной значимости, обеспечивает более быструю сходимость сокращая время простоя и упрощает использование балансировки нагрузки в сети ячеистой топологии (частично и/или полностью подключеной), позволяя трафику распределять нагрузку для всех путей сети. КПП призвана практически исключить влияние человеческого фактора в процессе настройки и сохраняет природу «plug-and-play» подключи-и-играй, что создаёт Ethernet в качестве де-факто протокола во втором слое. МаршрутизацияМногие телекоммуникационные компании имеют несколько маршрутов через свои сети или к внешним сетям. Они используют сложные нагрузки для смены движения с одного пути на другой, чтобы избежать перегрузки сети на какой-либо конкретной ссылке, а иногда и свести к минимуму стоимость транзитных перевозок через внешние сети или улучшение надежности сети. Другой способ использования балансировки нагрузки в сети с мониторингом деятельности. Балансировщики нагрузки могут быть использованы для разбиения огромных потоков данных на несколько суб-потоков и использовать несколько сетевых анализаторов, где каждый читает часть исходных данных. Это очень полезно для мониторинга быстрых сетей, таких как порта 10gbe или STM64, где комплекс обработки данных может быть невозможен на скорости проводного соединеия. Отношение к отказоустойчивостиБалансировка нагрузки часто используется для реализации отказоустойчивости -продолжение работы службы после отказа одного или нескольких её компонентов. Компоненты контролируются постоянно (например, веб-серверы могут контролироваться выборкой известных страниц), и когда один перестанет реагировать, балансировщик нагрузки информируется и больше не шлет трафик на этот сервер. Когда компонент возвращается на линию, балансировщик нагрузки начинает маршрутизировать трафик к нему снова. Для того чтобы это работало, должен быть по крайней мере один компонент в количестве, превышающем емкость службы (N+1 резервирование). Это гораздо дешевле и более гибким, чем отказоустойчивого подходы в котором каждый живой компонент работает в паре с единой резервной копии компонента, который берет на себя в случае выхода из строя (двойное модульное резервирование). Некоторые типы RAID систем можно также использовать для горячий резервирования для подобного эффекта.
|