Балансировка нагрузки
Масштабирование путем подключения новых виртуальных машин при увеличении трафика — это эффективная стратегия масштабирования для удовлетворения спроса. Тот факт, что виртуальные машины могут подготавливаться быстро, очень важен для достижения эластичности. Но подключение дополнительных серверов не принесет пользы, если трафик не будет распределяться между этими серверами. В целом это позволяет системе обрабатывать возросшую нагрузку. Именно поэтому балансировка нагрузки важна для эластичности, так как она может динамически корректировать количество ресурсов, выделенных задаче.
Потребность в балансировке нагрузки обусловлена двумя базовыми требованиями. Во-первых, пропускная способность повышается за счет параллельной обработки. Если один сервер может обслуживать 5000 запросов в единицу времени, то 10 серверов с балансировкой нагрузки могут обслуживать 50 000 запросов в единицу времени. Во-вторых, ресурсы с балансировкой нагрузки обеспечивают более высокий уровень доступности. Вместо того чтобы перенаправить запрос на сервер, который уже работает на грани, подсистема балансировки нагрузки может направить запрос на сервер с более низкой нагрузкой. Кроме того, если сервер переходит в автономный режим и подсистема балансировки нагрузки распознает это, она может направить запросы на другие серверы.
Что такое балансировка нагрузки?
Хорошо известная форма балансировки нагрузки — это DNS с циклическим перебором, которая используется многими крупными веб-службами для распределения запросов между несколькими серверами. В частности, несколько серверов переднего плана, каждый из которых имеет уникальный IP-адрес, используют одно DNS-имя. Для балансировки количества запросов к каждому веб-серверу крупные компании, такие как Google, обслуживают пул IP-адресов для каждой записи DNS. Когда клиент выполняет запрос (например, к www.google.com), DNS-служба Google выбирает один из доступных адресов из пула и отправляет его клиенту. Самая простая стратегия, используемая для диспетчеризации IP-адресов, — использование очереди циклического перебора, где после каждого ответа DNS список адресов перемешивается.
До появления облака балансировка нагрузки DNS была простым способом сократить задержку соединений с большим расстоянием. Диспетчер на DNS-сервере был запрограммирован отправлять в ответ IP-адрес сервера, географически расположенного ближе всего к клиенту. Самый простой способ сделать это — отправить IP-адрес из пула, который численно был ближе всего к IP-адресу клиента. Этот метод был ненадежным, так как IP-адреса не распределяются в глобальной иерархии. Современные технологии являются более сложными и используют программное сопоставление IP-адресов с местоположениями на основе физических карт поставщиков услуг Интернета (ISP). Поскольку это сопоставление реализуется в качестве дорогостоящего программного поиска, этот метод дает лучшие результаты, но требует затрат на вычисление. Однако стоимость медленного поиска окупается, так как поиск DNS выполняется только при первом соединении клиента с сервером. Весь последующий обмен данными осуществляется непосредственно между клиентом и сервером, которому принадлежит отправленный IP-адрес. Пример схемы балансировки нагрузки DNS показан на рисунке 9.
Рис. 9. Балансировка нагрузки в облачной среде.
Недостаток этого метода в том, что при сбое сервера переключение на другой IP-адрес зависит от конфигурации срока жизни (TTL) кэша DNS. Известно, что записи DNS являются долгосрочными, и для обновлений требуется больше недели. Это означает, что трудно быстро "скрыть" отказ сервера от клиента. Уменьшение срока жизни (TTL) IP-адреса в кэше улучшает ситуацию за счет повышения производительности и увеличения числа поисковых запросов.
Современная балансировка нагрузки часто сводится к использованию выделенного экземпляра (или пары экземпляров) для распределения входящих запросов по тыловым серверам. Для каждого входящего запроса на указанном порте подсистема балансировки нагрузки перенаправляет трафик на один из тыловых серверов на основе стратегии распределения. Таким образом подсистема балансировки нагрузки сохраняет метаданные запроса, включая такие сведения, как заголовки протокола приложения (например, заголовки HTTP). В этой ситуации устаревшая информация не представляет проблемы, так как каждый запрос проходит через подсистему балансировки нагрузки.
Хотя все типы подсистем балансировки сетевой нагрузки пересылают запросы с любым контекстом тыловым серверам, когда дело доходит до отправки ответа клиенту, они могут использовать одну из двух основных стратегий1:
Использование прокси-сервера — при таком подходе подсистема балансировки нагрузки получает ответ от серверной части и передает его обратно клиенту. Подсистема балансировки нагрузки ведет себя как стандартный веб-прокси и участвует в обеих половинах сетевой транзакции, а именно пересылает запрос клиенту и отправляет ответ.
Передача TCP — при таком подходе TCP-соединение с клиентом передается на тыловой сервер, и сервер отправляет ответ непосредственно клиенту, в обход подсистемы балансировки нагрузки.
Последняя из этих стратегий показана на рисунке 10.
Рис. 10. Механизм передачи TCP от диспетчера к внутреннему серверу.
Преимущества балансировки нагрузки
Одно из преимуществ балансировки нагрузки заключается в том, что она помогает маскировать сбои в системе. Пока клиент имеет связь с одной конечной точкой, которая представляет несколько ресурсов, сбои в отдельных ресурсах скрываются от клиента путем обслуживания запросов с помощью других ресурсов. Однако теперь подсистема балансировки нагрузки становится единственной точкой отказа. Если по какой-либо причине происходит сбой, даже если все тыловые серверы еще работают, клиентские запросы обрабатываться не будут. Следовательно, для обеспечения высокого уровня доступности подсистемы балансировки нагрузки часто реализуются парами.
Что еще важнее, балансировка нагрузки повышает скорость реагирования за счет распределения рабочих нагрузок между несколькими вычислительными ресурсами в облаке. Наличие одного вычислительного экземпляра в облаке имеет несколько ограничений. В предыдущих модулях мы обсуждали физическое ограничение производительности, где для увеличения рабочих нагрузок требуется больше ресурсов. С помощью балансировки нагрузки большие рабочие нагрузки распределяются по нескольким ресурсам, чтобы каждый ресурс мог выполнять свои запросы независимо и параллельно, улучшая пропускную способность приложения. Балансировка нагрузки также улучшает среднее время отклика, так как существует больше серверов для обработки рабочей нагрузки.
Проверки работоспособности крайне важны для реализации успешных стратегий балансировки нагрузки. Подсистема балансировки нагрузки должна знать о том, что ресурс становится недоступным, чтобы избежать перенаправления трафика к этому ресурсу. Мониторинг проверки связи, при котором подсистема балансировки нагрузки опрашивает серверы с помощью запросов по протоколу ICMP, является одной из наиболее популярных методик для проверки работоспособности конкретных ресурсов. Кроме работоспособности ресурса при пересылке на него трафика, некоторые стратегии балансировки нагрузки учитывают и другие метрики, такие как пропускная способность, задержка и загрузка ЦП.
Подсистемы балансировки нагрузки часто должны гарантировать высокий уровень доступности. Самый простой способ это сделать — создать несколько экземпляров подсистемы балансировки нагрузки (каждый с уникальным IP-адресом) и связать их с одним DNS-адресом. Всякий раз, когда подсистема балансировки нагрузки завершается сбоем по какой-либо причине, она заменяется новой, а весь трафик передается в экземпляр отработки отказа с минимальным влиянием на производительность. При этом можно настроить новый экземпляр подсистемы балансировки нагрузки, чтобы заменить отказавший, и необходимо немедленно обновить записи DNS.
Помимо распределения запросов между тыловыми серверами, подсистемы балансировки нагрузки часто используют механизмы для снижения нагрузки на серверы и повышения общей пропускной способности. Ниже перечислены некоторые из этих механизмов:
Разгрузка SSL — HTTPS-соединения вызывают снижение производительности, так как трафик по ним шифруется. Вместо того чтобы обслуживать все запросы с помощью SSL, клиентское подключение к подсистеме балансировки нагрузки можно выполнить через SSL, а запросы на перенаправление на каждый сервер осуществляются через незашифрованный HTTP. Этот метод значительно сокращает нагрузку на серверы. Кроме того, это безопасно, если запросы на перенаправление не поступают через открытую сеть.
Буферизация TCP — стратегия разгрузки клиентов с медленными подключениями с помощью подсистемы балансировки нагрузки для облегчения работы серверов, обслуживающих ответы этим клиентам.
Кэширование — в определенных сценариях подсистема балансировки нагрузки может поддерживать кэш для наиболее популярных запросов (или запросов, которые могут быть обработаны без перехода на серверы, например статическое содержимое), чтобы снизить нагрузку на серверы.
Формирование трафика — подсистема балансировки нагрузки может использовать этот метод для задержки или изменения приоритета для потока пакетов, чтобы оптимизировать трафик для конфигурации сервера. Это влияет на качество обслуживания для некоторых запросов, но гарантирует, что можно будет обслуживать входящую нагрузку.
Важно помнить, что балансировка нагрузки работает, только если сама подсистема балансировки нагрузки не находится под чрезмерной нагрузкой. В противном случае подсистема балансировки нагрузки становится узким местом. К счастью, подсистемы балансировки нагрузки, как правило, выполняют небольшой объем обработки запросов. Фактическую работу по преобразованию запросов в ответы выполняют тыловые серверы.
Равное распределение
В облаке используется несколько стратегий балансировки нагрузки. Один из наиболее распространенных способов — равное распределение, где используется простой алгоритм циклического перебора для равномерного распределения трафика между всеми узлами. Он не учитывает использование отдельных ресурсов в системе, а также время выполнения запроса. Этот подход пытается обеспечить занятость каждого узла в системе и является одним из самых простых для реализации.
AWS использует этот подход в своем предложении Elastic Load Balancer (ELB). ELB подготавливает подсистемы балансировки нагрузки, которые распределяют трафик между подключенными экземплярами EC2. Подсистемы балансировки нагрузки — это, по сути, сами экземпляры EC2 со службой маршрутизации трафика. По мере масштабирования ресурсов, расположенных за подсистемой балансировки нагрузки, IP-адреса новых ресурсов обновляются в записи DNS подсистемы балансировки нагрузки. Этот процесс занимает несколько минут, так как требуется как мониторинг, так и время на подготовку. Этот период масштабирования — время ожидания, пока подсистема балансировки нагрузки будет готова к обработке более высоких нагрузок, — называется "прогревом" подсистемы балансировки нагрузки.
Подсистемы балансировки нагрузки AWS также отслеживают ресурсы, подключенные к ним для распределения рабочей нагрузки, чтобы поддерживать проверку работоспособности. Для обеспечения работоспособности всех ресурсов используется механизм проверки связи. Пользователи ELB могут настроить параметры проверки работоспособности, указав задержки и число повторных попыток.
Распределение на основе хэша
Этот подход пытается обеспечить, чтобы запросы от одного клиента в течение сеанса направлялись на один и тот же сервер каждый раз, хэшируя метаданные, определяющие каждый запрос, и используя хэш для выбора сервера. Если хэширование выполняется правильно, запросы распределяются относительно равномерно между серверами. Одним из преимуществ такого подхода является то, что он предоставляется приложениям, поддерживающим сеансы, которые могут хранить данные сеанса в памяти, а не записывать их в общее хранилище данных, например в базу данных или кэш Redis. Недостаток состоит в том, что каждый запрос должен быть хэширован, что приводит к небольшой задержке.
Azure Load Balancer использует механизм на основе хэша для распределения нагрузок. Этот механизм создает хэш для каждого запроса на основе исходного IP-адреса, исходного порта, IP-адреса назначения, порта назначения и типа протокола, чтобы гарантировать, что при обычных обстоятельствах каждый пакет из одного сеанса будет находиться на одном и том же тыловом сервере. Хэш-функция выбрана для того, чтобы распределение подключений к серверам было случайным.
Другие стратегии балансировки нагрузки
Если определенный сервер медленно обрабатывает запрос (или набор запросов), подсистемы балансировки нагрузки, использующие циклический перебор или алгоритмы распределения на основе хэширования, будут пересылать к нему запросы в любом случае. Существуют и другие более сложные стратегии балансировки нагрузки между несколькими ресурсами, которые учитывают емкость. Две наиболее часто используемых метрики для измерения емкости:
Время выполнения запроса: стратегии на основе этой метрики используют алгоритм планирования приоритетов, при котором время выполнения запроса используется для выбора назначения для отдельных запросов. Основной сложностью при использовании такого подхода является точная оценка времени выполнения. Подсистема балансировки нагрузки может угадать время выполнения, используя (и постоянно обновляя) таблицу в памяти, в которой хранятся различия между моментом перенаправления запроса на каждый сервер и временем его возвращения.
Использование ресурсов — стратегии, основанные на этой метрике, используют загрузку ЦП для балансировки использования на разных узлах. Подсистема балансировки нагрузки поддерживает упорядоченный список ресурсов на основе их использования и направляет каждый запрос, который получает, в ресурс, где наблюдается минимальная нагрузка.
Балансировка нагрузки крайне важна для реализации масштабируемых облачных служб. Отсутствие эффективного способа распределения трафика между внутренними ресурсами значительно ограничивает эластичность, достигаемую благодаря созданию ресурсов и их отключению в нужный момент.
Ссылки
- Арон, Мохит (Aron, Mohit), Сандерс, Даррен (Sanders, Darren), Друшел, Питер (Druschel, Peter), Цвенепоэл, Вилли (Zwaenepoel, Willy) (2000). "Масштабируемое распределение запросов с учетом содержания в сетевых серверах на основе кластеров", материалы ежегодной технической конференции USENIX, 2000 г.