Балансировка нагрузки
Необходимость балансировки нагрузки в вычислениях обусловлена двумя основными требованиями: во-первых, высокий уровень доступности можно улучшить с помощью реплика. Во-вторых, с помощью параллельной обработки можно повысить производительность. Высокий уровень доступности — это свойство службы, которое доступно почти в 100 % случаев, когда клиент пытается получить доступ к службе. Качество обслуживания (QoS) для определенной службы обычно включает в себя несколько аспектов, таких как требования к пропускной способности и задержкам.
Что такое балансировка нагрузки?
Наиболее известной формой балансировки нагрузки является "DNS с циклическим перебором", который используется многими крупными веб-службами для балансировки запросов между несколькими серверами. Если говорить более конкретно, несколько веб-серверов переднего плана, каждый из которых имеет уникальный IP-адрес, используют одно DNS-имя. Для балансировки большого числа запросов к каждому из этих веб-серверов крупные компании, такие как Google, обслуживают целый пул IP-адресов, связанный с одной записью DNS. Когда клиент выполняет запрос (например, к домену www.google.com), DNS-служба Google выбирает один из доступных адресов из пула и отправляет его клиенту. Самая простая стратегия, используемая для диспетчеризации IP-адресов, — использование простой очереди циклического перебора, где после каждого ответа DNS список адресов сдвигается.
До появления облака балансировка нагрузки DNS была простым способом справиться с задержками соединений на больших расстояниях. Диспетчер на DNS-сервере был запрограммирован отправлять в ответ IP-адрес сервера, расположенного географически ближе всего к клиенту. Самый простым способом сделать это была отправка IP-адреса из пула, который был ближе всего к IP-адресу клиента по номеру. Этот метод, конечно, был ненадежным, так как IP-адреса не имеют глобальной иерархии. Современные технологии являются более сложными и используют программное сопоставление IP-адресов с местоположениями на основе физических карт поставщиков услуг Интернета (ISP). Поскольку это сопоставление реализуется с помощью сложного программного поиска, этот метод дает лучшие результаты, но требует затрат на вычисление. Однако стоимость медленного поиска окупается, так как поиск DNS выполняется только при первом соединении клиента с сервером. Весь последующий обмен данными осуществляется непосредственно между клиентом и сервером, которому принадлежит отправленный IP-адрес. Пример схемы балансировки нагрузки DNS показан на следующем рисунке.
Рис. 4. Балансировка нагрузки в облачной среде размещения
Недостаток этого метода заключается в том, что в случае сбоя сервера переключение на другой IP-адрес зависит от значения параметра срока жизни (TTL) кэша DNS. Известно, что записи DNS являются долгоживущими, и для распространения их изменений в Интернете требуется больше недели. Поэтому трудно быстро "скрыть" отказ сервера от клиента. Ситуацию можно улучшить, уменьшив срок жизни (TTL) IP-адреса в кэше, но это происходит за счет снижения производительности и увеличения числа поисковых запросов.
Современная балансировка нагрузки часто сводится к использованию выделенного экземпляра (или пары экземпляров), которые перенаправляют входящий трафик на тыловые серверы. Для каждого входящего запроса на указанном порте подсистема балансировки нагрузки перенаправляет трафик на один из тыловых серверов на основе стратегии распределения. Таким образом, подсистема балансировки нагрузки сохраняет метаданные запроса, включая такие сведения, как заголовки протокола приложения (например, заголовки HTTP). В этой ситуации отсутствуют проблемы с устареванием информации, так как каждый запрос проходит через подсистему балансировки нагрузки.
Хотя все типы подсистем балансировки сетевой нагрузки просто пересылают пользовательскую информацию с любым контекстом тыловым серверам, когда дело доходит до отправки ответа клиенту, они могут использовать одну из двух основных стратегий1.
- Прокси-сервер. В этом подходе подсистема балансировки нагрузки получает ответ от серверной части и передает его клиенту обратно. Подсистема балансировки нагрузки ведет себя как стандартный веб-прокси и участвует в обеих половинах сетевой транзакции, а именно пересылает запрос клиенту и отправляет ответ.
- Передача TCP. В этом подходе TCP-соединение с клиентом передается на тыловой сервер. Поэтому сервер отправляет ответ непосредственно клиенту, не проходя через подсистему балансировки нагрузки.
Рис. 5. Механизм передачи TCP от диспетчера к серверу серверной части
Влияние на доступность и производительность
Балансировка нагрузки является важной стратегией для маскировки сбоев в системе. Поскольку клиент системы взаимодействует с одной конечной точкой, которая распределяет нагрузку между несколькими ресурсами, сбои в отдельных ресурсах могут быть скрыты от клиента просто путем обслуживания запроса в другом ресурсе. Однако важно отметить, что подсистема балансировки нагрузки теперь является единой точкой отказа для службы. Если по какой-либо причине происходит сбой, даже если все тыловые серверы еще работают, запрос клиента обработать будет нельзя. Следовательно, для обеспечения высокого уровня доступности подсистемы балансировки нагрузки часто реализуются парами.
Балансировка нагрузки позволяет службе распределять рабочие нагрузки между несколькими вычислительными ресурсами в облаке. Наличие одного вычислительного экземпляра в облаке имеет несколько ограничений. Ранее мы уже обсуждали физическое ограничение производительности, когда для увеличения рабочих нагрузок требуется больше ресурсов. С помощью балансировки нагрузки большие объемы рабочих нагрузок можно распределить по нескольким ресурсам, чтобы каждый ресурс мог выполнять свои запросы независимо и параллельно, повышая тем самым пропускную способность приложения. Это также уменьшает среднее время обслуживания, так как существует больше серверов для обработки рабочей нагрузки.
Проверка и мониторинг служб являются ключевым средством, позволяющим успешно использовать стратегии балансировки нагрузки. Подсистема балансировки нагрузки должна обеспечить выполнение каждого запроса, гарантируя доступность каждого узла ресурсов. В противном случае трафик не будет направляться на этот конкретный узел. Мониторинг вида "запрос-ответ" — это одна из наиболее популярных тактик для проверки работоспособности определенного узла ресурса. Помимо работоспособности узла, для некоторых стратегий балансировки нагрузки требуются дополнительные сведения, такие как пропускная способность, задержка и загрузка ЦП, чтобы оценить наиболее подходящий ресурс для направления трафика.
Подсистемы балансировки нагрузки часто должны гарантировать высокий уровень доступности. Самый простой способ это сделать — создать несколько экземпляров подсистемы балансировки нагрузки (каждый с уникальным IP-адресом) и привязать их все к одному DNS-адресу. Всякий раз, когда экземпляр подсистемы балансировки нагрузки по какой-либо причине выходит из строя, он заменяется новым, а весь трафик передается в экземпляр отработки отказа с минимальным влиянием на производительность. Одновременно можно настроить новый экземпляр подсистемы балансировки нагрузки, чтобы заменить неисправный, при этом необходимо немедленно обновить записи в DNS.
Стратегии балансировки нагрузки
В облаке применяется несколько стратегий балансировки нагрузки.
Равное распределение
Это статический подход к балансировке нагрузки, где простой алгоритм циклического перебора используется для равномерного разделения трафика между всеми узлами и не учитывает использование отдельного узла ресурса в системе или времени выполнения отдельных запросов. Этот подход пытается обеспечить занятость каждого узла в системе и является одним из самых простых для реализации. Важным недостатком этого подхода является то, что тяжелые клиентские запросы могут объединяться и попадать в одни и те же центры обработки данных, что приводит к перегрузке нескольких узлов, в то время как другие остаются недостаточно загруженными. Однако для возникновения такой ситуации требуется очень специальная схема нагрузки, и на практике при большом числе клиентов и серверов с достаточно равномерным распределением и емкостью подключений вероятность этого мала. С другой стороны, эта стратегия усложняет реализацию стратегий кэширования в центре обработки данных, которые учитывают такие аспекты, как пространственное расположение (когда предварительная выборка и кэширование данных выполняется рядом с данными, которые были получены в данный момент), так как следующий запрос, сделанный одним и тем же клиентом, может в итоге выполниться на другом сервере.
AWS использует этот подход в своем предложении ELB (Elastic Load Balancer). AWS ELB подготавливает подсистемы балансировки нагрузки, которые распределяют трафик между подключенными экземплярами EC2. Подсистемы балансировки нагрузки — это, по сути, сами экземпляры EC2 со службой маршрутизации трафика. По мере масштабирования ресурсов, расположенных за подсистемой балансировки нагрузки, IP-адреса новых ресурсов обновляются в записи DNS подсистемы балансировки нагрузки. Этот процесс занимает несколько минут, так как требуется как мониторинг, так и время на подготовку. Этот период масштабирования (время до момента, когда подсистема балансировки нагрузки сможет обрабатывать более высокую нагрузку) называется "прогревом" подсистемы балансировки нагрузки.
Подсистемы балансировки нагрузки ELB от AWS также отслеживают каждый ресурс, подключенный для распределения рабочей нагрузки, чтобы поддерживать проверку работоспособности. Для обеспечения работоспособности всех ресурсов используется механизм проверки связи. Пользователи ELB могут настроить параметры проверки работоспособности, указав задержки и число повторных попыток.
Распределение на основе хэша
Этот подход пытается обеспечить, чтобы в любой момент запросы, сделанные клиентом через одно и то же подключение, всегда поступали на один и тот же сервер. Кроме того, чтобы сбалансировать распределение трафика запросов, это делается в случайном порядке. Такой подход имеет несколько преимуществ по сравнению с методом циклического перебора, так как он помогает в приложениях, поддерживающих сеансы, где стратегии сохранения состояния и кэширования могут быть намного проще. Он также менее уязвим к шаблонам трафика, которые приводят к заторам на одном сервере, так как распределение является случайным, но риск по-прежнему существует. Однако, поскольку каждый запрос должен оцениваться на наличие метаданных соединения, чтобы направить его на соответствующий сервер, это вносит небольшую задержку в каждый запрос.
Azure Load Balancer использует такой механизм распределения на основе хэша для распределения нагрузки. Этот механизм создает хэш для каждого запроса на основе исходного IP-адреса, исходного порта, IP-адреса назначения, порта назначения и типа протокола, чтобы гарантировать, что каждый пакет из одного подключения будет передаваться на один и тот же тыловой сервер. Хэш-функция выбрана для того, чтобы распределение подключений к серверам было по-настоящему случайным.
Azure предоставляет проверка работоспособности через три типа проб: пробы гостевого агента (на виртуальных машинах PaaS), пользовательские пробы HTTP и пользовательские пробы TCP. Все три пробы обеспечивают проверку работоспособности для узлов ресурсов с помощью механизма "запрос-ответ".
Другие популярные стратегии
Существуют и другие стратегии, используемые для балансировки нагрузки между несколькими ресурсами. Каждая из них использует разные метрики для оценки наиболее подходящего узла ресурса для конкретного запроса.
- Стратегии на основе времени выполнения запроса: эти стратегии используют алгоритм планирования приоритета, в котором время выполнения запроса используется для определения наиболее подходящего порядка распределения нагрузки. Основной сложностью при использовании такого подхода является точное прогнозирование времени выполнения конкретного запроса.
- Стратегии на основе использования ресурсов. Эти стратегии используют использование ЦП на каждом узле ресурсов для балансировки использования между каждым узлом. Подсистемы балансировки нагрузки сохраняют упорядоченный список ресурсов на основе уровня их использования, а затем направляют запросы на наименее загруженный узел.
Другие преимущества
Централизованная подсистема балансировки нагрузки предоставляет несколько стратегий, которые могут повысить производительность службы. Однако важно отметить, что эти стратегии работают только при условии, что подсистема балансировки нагрузки не находится под непреодолимой нагрузкой. В противном случае подсистема балансировки нагрузки сама по себе становится узким местом. Ниже перечислены некоторые из таких стратегий.
- Разгрузка SSL: сетевые транзакции через SSL имеют дополнительные затраты, так как они должны иметь обработку для шифрования и проверки подлинности. Вместо того чтобы обслуживать все запросы с помощью SSL, можно выполнить через SSL только клиентское подключение к подсистеме балансировки нагрузки, а перенаправленные запросы на каждый отдельный сервер осуществлять по протоколу HTTP. Это значительно сокращает нагрузку на серверы. Кроме того, это безопасно, если перенаправленные запросы не проходят через открытую сеть.
- Буферизация TCP. Это стратегия разгрузки клиентов с медленными подключениями к подсистеме балансировки нагрузки для облегчения обслуживания серверов, обслуживающих ответы на эти клиенты.
- Кэширование. В некоторых сценариях подсистема балансировки нагрузки может поддерживать кэш для наиболее популярных запросов (или запросов, которые можно обрабатывать без обращения к серверам, например статического содержимого), чтобы снизить нагрузку на серверы.
- Формирование трафика. Для некоторых приложений подсистема балансировки нагрузки может использоваться для задержки или повторения потока пакетов, таким образом, чтобы трафик можно было сформировать в соответствии с конфигурацией сервера. Это влияет на качество обслуживания для некоторых запросов, но гарантирует, что можно будет обслуживать входящую нагрузку.
Ссылки
- Арон, Мохит (Aron, Mohit), Сандерс, Даррен (Sanders, Darren), Друшел, Питер (Druschel, Peter), Цвенепоэл, Вилли (Zwaenepoel, Willy) (2000). Scalable content-aware request distribution in cluster-based network servers from Proceedings of the 2000 Annual USENIX technical Conference (Масштабируемое распределение запросов с учетом содержания в сетевых серверах на основе кластеров, материалы ежегодной технической конференции USENIX, 2000 г.)