Балансировка нагрузки
В терминологии компьютерных сетей балансировка нагрузки или выравнивание нагрузки (англ. load balancing) — метод распределения заданий между несколькими сетевыми устройствами (например, серверами) с целью оптимизации использования ресурсов, сокращения времени обслуживания запросов, горизонтального масштабирования кластера (динамическое добавление/удаление устройств), а также обеспечения отказоустойчивости (резервирования).
В компьютерах балансировка нагрузки распределяет нагрузку между несколькими вычислительными ресурсами, такими как компьютеры, компьютерные кластеры, сети, центральные процессоры или диски. Цель балансировки нагрузки — оптимизация использования ресурсов, максимизация пропускной способности, уменьшение времени отклика и предотвращение перегрузки какого-либо одного ресурса. Использование нескольких компонентов балансировки нагрузки вместо одного компонента может повысить надежность и доступность за счет резервирования. Балансировка нагрузки предполагает обычно наличие специального программного обеспечения или аппаратных средств, таких как многоуровневый коммутатор или система доменных имен, как серверный процесс.
Балансировка нагрузки отличается от физического соединения тем, что балансировка нагрузки делит трафик между сетевыми интерфейсами на сетевой сокет (модель OSI уровень 4) основе, в то время как соединение канала предполагает разделение трафика между физическими интерфейсами на более низком уровне, либо в пакет (модель OSI уровень 3) или по каналу связи (модель OSI уровень 2).
Примеры устройств, к которым применима балансировка:
- Серверные кластеры
- Прокси-серверы
- Межсетевые экраны
- Коммутаторы
- Серверы инспектирования содержимого
- Серверы DNS
- Сетевые адаптеры
Балансировка нагрузки может быть использована для расширения возможностей фермы серверов, состоящей более чем из одного сервера. Она также может позволить продолжать работу даже в условиях, когда несколько исполнительных устройств (серверов) вышли из строя. Благодаря этому растёт отказоустойчивость, и появляется возможность динамически регулировать используемые вычислительные ресурсы за счёт добавления/удаления исполнительных устройств в кластере.
Интернет-услугиПравить
В разделе не хватает ссылок на источники (см. рекомендации по поиску). |
Один из наиболее часто используемых приложений балансировки нагрузки является создание единого интернет-сервиса с несколькими серверами, иногда известные как фермы серверов. Обычно с балансировкой нагрузки системы относятся популярные веб-сайты, большие Интернет-магазины, сайты использующие протокол передачи файлов (FTP), системы доменных имен (DNS), и базы данных.
Для интернета, балансировщик нагрузки — это обычно программа, которая прослушивает порт, где внешние клиенты подключаются к службам. Балансировщик нагрузки перенаправляет запросы на один из «серверов» сервера, который обычно отвечает балансировщику нагрузки. Это позволяет подсистеме балансировки нагрузки, отвечать клиенту не зная о внутреннем разделении функций. Это также позволяет клиентам связавшись с фоновыми серверами напрямую, которые могут иметь преимущества в плане безопасности и скрывает структуру внутренней сети и предотвращения атак на ядро, сетевой стек или несвязанные сервисы, работающие на других портах.
Некоторые балансировщики нагрузки обеспечивают механизм для того, чтобы делать что-то особенное в том случае, если все серверная часть сервера недоступна. Это может включать в себя переадресацию на резервную систему балансировки, или отображения сообщения о неисправности.
Важно также, что подсистема балансировки нагрузки не должна стать единой точкой отказа. Обычно балансировщики нагрузки реализуются в высокой доступности, которые могут также реплицировать сессии сохраняемости данных, если это требуется для конкретного применения.[1]
Циклический перебор 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 на А-запись позволяет быстро перенаправить трафик, если рухнет сервер. Необходимо учитывать возможность того, что эта методика может привести к возможности индивидуальных клиентов переключаться между отдельными серверами посередине сессии.
Алгоритмы планированияПравить
Множество алгоритмов планирования используются балансировщиками нагрузки, чтобы определить, какому серверу послать запрос. Простые алгоритмы включают в себя случайный выбор или по круговой системе. Более сложные подсистемы балансировки нагрузки могут принимать во внимание дополнительные факторы, такие как, какие сервера сообщили нагрузки, меньшее время отклика, вверх/вниз статус (определяется путём мониторинга опрос какой-то), количество активных соединений, географическое положение, возможности, или сколько трафика он недавно был назначен.
НастойчивостьПравить
Важным вопросом при работе службы балансировки нагрузки как работать с информацией, которая должна быть сохранена через несколько запросов в сессии пользователя. Если эта информация хранится локально на одном сервере серверной, то последующие запросы, идущие от различных внутренних серверов не смогут его найти. Это может быть кешированная информация, которая может быть пересчитана, и в этом случае запрос балансировки нагрузки на другой сервер серверной решает проблему производительности.
В идеале кластер серверов за балансировщиком нагрузки должны быть в курсе сессий, так, что если клиент подключается к любому серверу в любой момент история общения пользователя с конкретным сервером не имеет значения. Обычно это достигается с помощью общей базы данных или в памяти сессии базы данных, например memcached.
Одно основное решение проблемы данных сессии должны отправлять все запросы в сессии пользователя последовательно в тот же сервер. Это называется настойчивость (persistence) или липкость (stickiness). Существенным недостатком этой технологии является отсутствие автоматической отработки отказа: если сервер выходит из строя, его сессионная информация становится недоступной, из всех сеансов теряется. Та же проблема обычно актуальна для центральной базы данных сервера; даже если веб-сервера являются «лицами без гражданства» (stateless) и не «липкий» (sticky), центральной базе данных (см. ниже).
Отнесение к определенному серверу могут основываться на имени пользователя, клиентского IP-адреса, или могут быть случайными. Из-за изменения клиента воспринимаются адрес, вытекающих из протокола DHCP, трансляцию сетевых адресов и веб-прокси, этот метод может быть ненадежным. Случайные задания должны запоминаться балансировщиком нагрузки, который создает нагрузку на хранилище. Если балансировщик нагрузки заменяется или выходит из строя, эта информация может быть потеряна, и задания, возможно, должны быть удалены после заданного промежутка времени или в периоды высокой нагрузки, чтобы избежать превышения пространства, доступного для таблицы присвоений. Метод случайного присвоение также требует, чтобы клиенты поддерживают некоторые настройки, который может быть проблемой, например, когда Web-браузер отключил хранения файлов cookie. Сложные подсистемы балансировки нагрузки используют несколько методов сохранения, позволяющие избежать некоторых недостатков какого-либо одного метода.
Другим решением является хранить сессионные данные в БД. Вообще это плохо для производительности, так как это увеличивает нагрузку на базу данных: базу данных лучше использовать для хранения информации менее изменяющейся, чем сессионные данные. Чтобы база данных не стала единой точкой отказа, и для повышения масштабируемости, базы данных часто реплицируются между несколькими компьютерами, и балансировки нагрузки используется для распространения индекса нагрузки между этими репликами. Технология Microsoft ASP.net State Server является примером сеанса базы данных. Все серверы в веб-ферме хранят данные сессии на Главном State Server сервер и любой сервер в ферме может извлечь данные.
Очень распространены случаи когда клиентом является веб-браузер, простой, то эффективный подход-хранить сессионные данные в самом браузере. Одним из способов достижения этого является использование cookie браузера, временные зашифрованные метки. Другой способ — перезапись URL. Хранение данных сессии на клиенте, как правило, предпочтительное решение: тогда балансировщик нагрузки волен выбирать любой сервера для обработки запроса. Однако, этот метод обработки данных состояния плохо подходит для некоторых сложных сценариев бизнес-логики, где состояние сеанса является большой полезной нагрузкой и перечитывать его с каждым запросом на сервер не представляется возможным. Перезапись URL-адресов имеет серьезные проблемы безопасности, потому что конечный пользователь может легко изменять представленные URL и таким образом изменить потоки сессии.
Еще одно решение для хранения постоянных данных, чтобы связать имя с каждым блоком данных, использовать распределенную хеш-таблицу, чтобы псевдо-случайным образом присвоить имя одному из доступных серверов, а затем хранить, этот блок данных в назначенном сервере.
Возможности балансировщика нагрузкиПравить
Аппаратные и программные балансировщики нагрузки могут иметь различные специальные характеристики. Основная черта балансировщика нагрузки — иметь возможность распределять входящие запросы через несколько серверов в кластере по алгоритму планирования. Большинство из перечисленных ниже свойств конкретного поставщика:
- Асимметричная нагрузка: соотношение может быть назначено вручную вызывать некоторые сервера, чтобы получить большую долю нагрузки, чем другие. Это иногда используется в качестве способа когда одна часть серверов имеет больше возможностей, чем другие, и не всегда работают так, как хотелось.
- Приоритет активации: когда количество доступных серверов падает ниже определенного числа, или нагрузка становится слишком высокой, часть резервных серверов может быть переведено в оперативный режим.
- SSL разгрузка и ускорение: в зависимости от загруженности, обработка шифрования и аутентификации для SSL запроса может занимать значительную часть процессорного времени; поскольку запросы увеличивают время отклика для пользователей, так как протокол SSL увеличивает расходы распределяемые между веб-серверами. Снять этот спрос на веб-серверах, балансер может завершать SSL-соединения, передавая запросы https, как и http-запросов к веб-серверам. Если балансер сам по себе не перегружается, это не ухудшит производительность воспринимаемая конечными пользователями. Недостатком этого подхода является то, что вся обработка SSL сосредоточено на одном устройстве (балансировщик), который может стать новым «узким местом». В некоторое оборудование балансировки нагрузки входит специализированное оборудование для обработки SSL. Вместо того, чтобы модернизировать балансировщик нагрузки, который стоит достаточно дорого специализированного оборудования, может быть дешевле отказаться от SSL разгрузки и добавить несколько веб-серверов. Кроме того, некоторые серверные вендоры, такие как Oracle/Sun теперь включают аппаратное ускорение шифрования в свои процессоры такие как на контроллере T2000. F5 сети включает выделенное SSL ускорение аппаратных средств карты в их локальный трафик менеджер (ЛТМ), который используется для шифрования и расшифровки SSL-трафика. Одной из явных выгод для разгрузки SSL в балансировки заключается в том, что он позволяет делать балансировку или коммутацию контента на основе данных в https-запроса.
- Распределенный отказ в обслуживании (DDoS-атак) атаки защиты: балансировщики нагрузки обеспечивают защиту с помощью SYN куки файлов и задержки ответа (фоновые сервера не видят клиента, пока он не подтвердит себя по TCP) для смягчения SYN-флуд атак и разгружает серверы на более эффективную платформу.
- Http-сжатие: уменьшает объем передаваемых данных по http, используя сжатие GZIP поддерживается всеми современными браузерами. Чем дольше реакция и чем дальше клиент, тем больше эта функция может уменьшить время отклика. Компромисс в том, что эта функция добавляет дополнительную нагрузку на Балансировщик и снимает её с Веб-сервера.
- Разгрузка TCP: разные производители используют разные термины для этого, но идея заключается в том, что обычно каждый http-запрос от каждого клиента-это разные TCP-соединения. Данная функция использует протокол HTTP/1.1, чтобы объединить несколько http-запросов от нескольких клиентов в один TCP-сокет с фоновыми серверами.
- Буферизация TCP: балансировщик нагрузки может держать буфер ответов от сервера и постепенно отвечать для медленных клиентов, позволяя веб-серверу быть свободным для других задач. Это быстрее чем отправить весь запрос клиента серверу напрямую.
- Прямой Серверный Ответ: вариант для асимметричного распределения нагрузки, где запрос и ответ имеют различные сетевые пути.
- Проверка работоспособности: балансировщик опрашивает серверы на доступность и удаляет из пула недоступные серверы.
- Кэширование http: балансировщик сохраняет статическое содержимое так, что некоторые запросы могут быть обработаны без обращения к серверам.
- Фильтрация Контента: некоторые балансировщики могут произвольно изменять пути движения.
- Безопасности http: некоторые балансировщики могут скрыть ошибки http страниц, удалить сервер идентификации заголовки из http-ответы, и шифровать куки, так что конечные пользователи не могут манипулировать ими.
- Организация очередей с учетом приоритетов: также известен как формирование скорости трафика, возможность дать разные приоритеты для разных передач.
- Контентно-зависимые переключения: большинство балансировщиков нагрузки могут отправлять запросы на разные серверы на основе URL-адресов запрашивается, предполагая, что запрос не шифруется (http) или если он зашифрован (через https), что https-запрос расшифровывается в подсистеме балансировки нагрузки.
- Клиент аутентификация: аутентификация пользователей с различных источников аутентификации, прежде чем разрешить им доступ к сайту.
- Программный трафик манипуляции: по крайней мере один балансировщик позволяет использовать скриптовый язык, чтобы разрешить пользовательские методы балансировки, произвольные манипуляции с трафиком, и многое другое.
- Брандмауэр: прямые соединения с сервером имеют большие возможности, для сети. Из соображений безопасности балансировщик используют как Брандмауэр (это набор правил, которые решают, является ли полезным трафик и который проходит до бекенд серверов или нет).
- Система предотвращения вторжений: предложение безопасности на уровне приложений в дополнение к сетевому/транспортному уровню безопасности брандмауэра.
Использования в телекоммуникационных сетяхПравить
Балансировка нагрузки может оказаться полезным в приложениях с резервированием каналов связи. Например, компания может иметь несколько подключений к Интернету, обеспечивая доступ к сети, если одно из соединений не работает. В отказоустойчивых системах будет означать, что одно звено предназначено для нормального использования, а второе используется только в случае, если основной канал выйдет из строя.
Используя балансировку нагрузки, обе ссылки могут быть заняты все время. Устройство или программа контролирует наличие всех звеньев и выбирает путь для отправки пакетов. Использование нескольких ссылок одновременно увеличивает доступную полосу пропускания.
Кратчайший путь преодоленияПравить
Стандарт IEEE утвердил стандарт IEEE 802.1 р-р стандартный мая 2012 года[2] также известно и задокументировано в большинстве книг в качестве кратчайшего пути преодоления (КПП). КПП позволяет всем ссылкам, чтобы быть активными через несколько путей равной значимости, обеспечивает более быструю сходимость сокращая время простоя и упрощает использование балансировки нагрузки в сети ячеистой топологии (частично и/или полностью подключеной), позволяя трафику распределять нагрузку для всех путей сети.[3][4] КПП призвана практически исключить влияние человеческого фактора в процессе настройки и сохраняет природу «plug-and-play» подключи-и-играй, что создаёт Ethernet в качестве де-факто протокола во втором слое.[5]
МаршрутизацияПравить
Многие телекоммуникационные компании имеют несколько маршрутов через свои сети или к внешним сетям. Они используют сложные нагрузки для смены движения с одного пути на другой, чтобы избежать перегрузки сети на какой-либо конкретной ссылке, а иногда и свести к минимуму стоимость транзитных перевозок через внешние сети или улучшение надежности сети.
Другой способ использования балансировки нагрузки в сети с мониторингом деятельности. Балансировщики нагрузки могут быть использованы для разбиения огромных потоков данных на несколько суб-потоков и использовать несколько сетевых анализаторов, где каждый читает часть исходных данных. Это очень полезно для мониторинга быстрых сетей, таких как порта 10gbe или STM64, где комплекс обработки данных может быть невозможен на скорости проводного соединения.
Отношение к отказоустойчивостиПравить
Балансировка нагрузки часто используется для реализации отказоустойчивости—продолжение работы службы после отказа одного или нескольких её компонентов. Компоненты контролируются постоянно (например, веб-серверы могут контролироваться выборкой известных страниц), и когда один перестанет реагировать, балансировщик нагрузки информируется и больше не шлет трафик на этот сервер. Когда компонент возвращается на линию, балансировщик нагрузки начинает маршрутизировать трафик к нему снова. Для того чтобы это работало, должен быть по крайней мере один компонент в количестве, превышающем ёмкость службы (N+1 резервирование). Это гораздо дешевле и более гибкое, чем отказоустойчивые подходы, в которых каждый живой компонент работает в паре с единой резервной копией компонента, который берёт на себя в случае выхода из строя (двойное модульное резервирование). Некоторые типы RAID систем можно также использовать для горячего резервирования для подобного эффекта.
ПримечанияПравить
- ↑ «High Availability» Архивная копия от 11 января 2016 на Wayback Machine. linuxvirtualserver.org.
- ↑ Shuang Yu (8 May 2012)
- ↑ Peter Ashwood-Smith (24 Feb 2011).
- ↑ Jim Duffy (11 May 2012).
- ↑ «IEEE Approves New IEEE 802.1aq Shortest Path Bridging Standard» Архивная копия от 12 июня 2012 на Wayback Machine.
СсылкиПравить
- Системы балансировки нагрузки Web-серверов
- Habrahabr.ru — Переход на Percona XtraDB Cluster. Часть I. Одна из возможных конфигураций
- Dynamic Load Balancing and Scheduling
- A sample implementation with source codes by server routing for load balancing with full auto failure recovery and session-sticking/affinity supported
- Open source based Zen Load Balancer
В статье не хватает ссылок на источники (см. рекомендации по поиску). |