Автомасштабирование в AWS для веб-сервера
Я пытаюсь создать группу автомасштабирования для своего веб-сервера в AWS.
Я делаю следующее:
1.- Создайте балансировщик нагрузки. Этот балансировщик нагрузки проверяет первый экземпляр группы автомасштабирования.
Вкладка проверки работоспособности
Вкладка Слушатели
2.- Создайте группу автомасштабирования с AMI. Политика:
- УВЕЛИЧЕНИЕ: если Максимальный ЦП> = 70% в течение 1 минуты, запускается 1 экземпляр на основе AMI. Он ждет 60 секунд, прежде чем разрешить еще одну операцию масштабирования.
- УМЕНЬШЕНИЕ: если максимальное значение ЦП <= 25% в течение 5 минут, удаляется самый новый экземпляр. Он ждет 0 секунд, прежде чем разрешить другое действие масштабирования.
На вкладке ДЕТАЛИ группы автомасштабирования у меня есть следующее: - Желательно: 1
Мин: 1
Макс: 5
Тип проверки работоспособности: EC2
Льготный период проверки работоспособности: 60
Политика прекращения: NewestInstance
Перезарядка по умолчанию 60
Это конфигурации.
Видимо хорошо работает. Когда мы заряжаем экземпляр с помощью JMeter, AWS запускает новый экземпляр, используя политику INCREASE. Проблема в том, что кажется, что новый экземпляр не используется. Потому что, когда я проверяю графики мониторинга AWS, ЦП всегда остается на 0. Поэтому я думаю, что новые инстансы, запускаемые AWS, не используются. Я думаю, это потому, что у меня плохая конфигурация балансировщика нагрузки, но я действительно не знаю. Что я могу сделать?
Многие скучают по этому поводу.
При нагрузочном тестировании Elastic Load Balancers с несколькими экземплярами EC2 за ELB вам необходимо запускать тесты из нескольких клиентских местоположений. Каждый должен происходить с уникального IP-адреса.
Причина этого заключается в том, как ELB обрабатывает DNS-запросы. В зависимости от количества используемых зон доступности, количества имеющихся у вас внутренних экземпляров EC2 и т. Д. ELB может продолжать отправлять запросы, исходящие с одного и того же удаленного IP-адреса, на тот же серверный экземпляр EC2.
Некоторые примечания:
Это отличается от «липких сеансов», которые используют файлы cookie для отправки одного и того же сеанса браузера в один и тот же серверный экземпляр EC2.
Если вы используете несколько клиентов для нагрузочного тестирования, убедитесь, что ваши компьютеры не защищены одним NAT или брандмауэром. Поскольку все соединения проходят через NAT / брандмауэр, ELB будет видеть, что все соединения происходят с одного и того же IP-адреса (IP-адрес NAT / брандмауэра). Так что этого недостаточно.
Используйте такой инструмент, как http://whatismyipaddress.com чтобы узнать, какой у вас «внешний» IP-адрес.
Ссылки:
- Личный опыт
- Мои обсуждения с AWS Support
- Лучшие практики в оценке эластичной балансировки нагрузки - См. Раздел «Разрешение DNS».
- 6 правил использования AWS Elastic Load Balancers - См. Раздел "Не обращайте внимания на точки доступа инфраструктуры".
- Насколько эластичны балансировщики нагрузки Amazon Elastic Load Balancer (ELB)? Не очень похоже - Из этой статьи:
Таким образом, один клиент для нагрузочного тестирования может попасть только в один экземпляр ELB.
- Анализ Amazon ELB: 18 вещей, которые вы должны знать - См. Пункт 9.
Обновить:
Еще одна ссылка:
- Диспетчер кэша DNS: правильный способ тестирования приложений со сбалансированной нагрузкой - В этой статье конкретно упоминаются проблемы нагрузочного тестирования с использованием JMeter против AWS ELB.
2 Чем заняться здесь.
1) Если вы подключили балансировщик нагрузки к своей группе Auto Scaling, вы можете дополнительно настроить Auto Scaling, чтобы включить результаты проверок работоспособности эластичной балансировки нагрузки при определении статуса работоспособности экземпляра. После добавления этих проверок работоспособности Auto Scaling также отмечает экземпляр как неисправный, если Elastic Load Balancing сообщает о состоянии экземпляра как OutOfService. Рекомендуется установить HC на ELB, а не на EC2. Это не так, как показано на прилагаемом снимке экрана.
2) Проверьте вкладку ELB -> Instances, как только вы увеличите трафик и увидите, что другой экземпляр развернулся, чтобы проверить, действительно ли он зарегистрирован в ELB, на который вы ссылаетесь.
Ура!