AWS ELB не распространяет запросы на автомасштабирующую группу экземпляров EC2 в некоторых случаях

Question

Я пытаюсь выполнить тестирование производительности для своей автоматической масштабирующей группы AWS с помощью jmeter.

Во-первых, я проверил масштаб в дюймах. Я установил порог в 70% использования процессора в течение 2 периодов, каждый период составляет 2 минуты. ELB работает нормально, и запросы были распределены по всем экземплярам EC2 в группе автоматического масштабирования, несмотря на неравноценность, после масштабирования системы.

В следующем случае я хочу проверить, может ли загрузка двух экземпляров быть дважды из одного экземпляра. Я установил номер экземпляра группы автоматического масштабирования, я установил счетчик min/max/желаемого экземпляра равным 2. Когда я нажимаю нагрузку с одного JMeter, всегда работает только один экземпляр, а его использование процессора достигает почти 100 процентов, но использование cpu другого экземпляра по-прежнему равно нулю. Если я выталкиваю нагрузку из кластера JMeter, который содержит несколько подчиненных устройств, все экземпляры принимают нагрузку.

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

Я нашел блог, в котором сказано, что ELB отлично подходит для HA, но не для балансировки нагрузки. https://www.stackdriver.com/elb-affinity-problems Но, я не думаю, что поведение, обрабатывающее запросы только одного экземпляра, является нормальным.

Какое черт в механизме балансировки нагрузки ELB? Я смущен.

Answer 1

Elastic Load Balancing механизм

• DNS-сервер использует DNS круговой, чтобы определить, какой узел балансировки нагрузки в определенной за доступность зоны получит запрос
• выбранной проверку балансировки нагрузки для «липкой сессии» печенья
• выбранный OAD балансир посылает запрос на наименее загруженный экземпляр

А более подробно:

Наличие зоны (маловероятно, что ваш случай)

По умолчанию, балансировки нагрузки узла маршруты движения к серверным экземпляров в пределах одной и той же зоне доступности. Чтобы ваши задние экземпляры могли обрабатывать нагрузку на запрос в каждой зоне доступности, важно иметь приблизительно эквивалентное количество экземпляров в каждой зоне. Например, если у вас есть десять экземпляров в зоне доступности us-east-1a и два экземпляра в us-east-1b, трафик будет по-прежнему распределяться между двумя зонами доступности. В результате два экземпляра в us-east-1b должны будут обслуживать тот же объем трафика, что и десять экземпляров в us-east-1a.

Сессии (, скорее всего, ваш случай)

По умолчанию Балансировщик Нагрузки перенаправляет каждый запрос независимо от экземпляра сервера с наименьшей нагрузкой. Для сравнения, липкий сеанс связывает сеанс пользователя с конкретным экземпляром сервера, так что все запросы, поступающие от пользователя во время сеанса, будут отправляться на тот же экземпляр сервера.

AWS Elastic Beanstalk использует файлы cookie, созданные с помощью балансировки нагрузки, когда для приложения разрешены липкие сеансы. Балансировщик нагрузки использует специальный файл cookie, созданный с помощью балансировки нагрузки, для отслеживания экземпляра приложения для каждого запроса. Когда балансировщик получает запрос, он сначала проверяет, присутствует ли этот файл cookie в запросе. Если это так, запрос отправляется экземпляру приложения, указанному в файле cookie. Если cookie не существует, балансировщик нагрузки выбирает экземпляр приложения на основе существующего алгоритма балансировки нагрузки. Куки-файл вставляется в ответ для привязки последующих запросов от одного и того же пользователя к экземпляру этого приложения. Конфигурация политики определяет срок действия файла cookie, который устанавливает продолжительность действия для каждого файла cookie.

маршрутизация Алгоритм (менее вероятно, ваш случай)

балансировки нагрузки узел посылает запрос на здоровые экземпляры в пределах одной зоны доступности с использованием leastconns алгоритма маршрутизации. Алгоритм маршрутизации lessconns поддерживает back-end экземпляры с наименьшими соединениями или невыполненными запросами.

Источник: Elastic Load Balancing Terminology And Key Concepts

Надежда это помогает.

Answer 2

У меня была эта проблема с несбалансированным трафиком ELB, когда экземпляры задней части, где в разных зонах доступности и ELB получали запросы от небольшого числа клиентов. В нашем случае мы использовали внутренний ELB в пределах уровней приложений. В вашем случае «нажимная нагрузка от одного JMeter», вероятно, означает небольшое количество клиентов, как видно ELB. Решение было включить перекрестную нагрузку зоны балансировки с помощью API, похожей на этот фрагмент: -

Elb-модифицирует-фунт-атрибуты $ {ELB} --region $ {REGION} --crosszoneloadbalancing "включен = истина"

http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/enable-disable-crosszone-lb.html