Я провожу стресс-тестирование нашей системы. В настоящее время у нас есть 5 экземпляров m1.large, работающих за ELB, в восточном регионе. В западном регионе есть 3 небольших экземпляра (с JMeter), которые я использую для взлома системы.
Выполняя тест, который подталкивает экземпляры приложения только до 80% -90% от их лимита ЦП (наша критическая точка в то время), я наблюдаю странное поведение, ELB сообщает, что ВСЕ 5 экземпляров находятся в состоянии «Не обслуживаются - Временная ошибка - проверьте позже », все экземпляры перестают получать запросы, и примерно через 5-10 секунд все возвращается в нормальное состояние. Это происходит каждые 30 секунд или около того. НО! Это происходит не каждый раз, когда я запускаю тест. Я только что провел получасовой стресс-тест с теми же настройками, и все работало отлично. Что происходит?
Кстати, моя проверка здоровья
Ping Target: HTTP:80/index.html Timeout: 60 seconds Interval: 300 seconds Unhealthy Threshold: 10 Healthy Threshold: 2
Так что это никак не может сделать это. Я никогда не сталкивался с этим до вчерашнего дня.
У нас также была временная проблема «коробки не проходят проверки работоспособности без уважительной причины», и при работе со службой поддержки Amazon выясняется, что существует взаимодействие между ELB и Apache KeepaliveTimeout. Если интервал проверки работоспособности больше таймаута, тогда программа проверки работоспособности может попытаться повторно использовать плохое соединение, и она не пройдет тест и выбросит ваш экземпляр из ELB. Они назвали наш 60-секундный интервал «необычно длинным». Сейчас мы возимся с этим, но попробуйте установить низкий интервал и сопоставить его с настройкой keepalive в Apache.
Это может быть связано с кешированием DNS на уровне JVM или ОС, поэтому все ваши запросы забивают 1 IP-адрес ELB или распределяются, поэтому сам ELB становится точкой отказа вместо обеспечения аварийного переключения.
Начиная с JMeter 2.12 и выше Диспетчер кеширования DNS Элемент конфигурации может использоваться для тестирования приложений с балансировкой нагрузки.
Видеть Диспетчер кэша DNS: правильный способ тестирования приложений со сбалансированной нагрузкой руководство для более подробных объяснений и инструкций.
Лучший способ стресс-тестирования ELB - использовать IP-адреса за предоставленным cname. Использовал их для работы с балансировщиком нагрузки. Убедитесь, что в каждом az, выбранном для ELB, есть хотя бы одно изображение. Amazon динамически масштабирует IP-адреса за ELB. Ваш балансировщик нагрузки, вероятно, использует только один IP-адрес. Я не уверен, что вы испытываете спорадическое поведение.