AWS EC2 Auto Scaling Groups: Я получаю Min и Max, но для чего нужны целевые ограничения?
Когда вы настраиваете группы автоматического масштабирования в границах AWS EC2 Min и Max, кажется, имеет смысл:
- Минимальное количество экземпляров для масштабирования на основе политик
- Максимальное количество экземпляров для масштабирования на основе политик
Тем не менее, мне никогда не удавалось обернуть голову тем, что должно затронуть черт Desired.
Я всегда устанавливал Desired равным Min, потому что, как правило, я хочу заплатить Amazon минимальную десятину, и если вам не нужен экземпляр для обработки нагрузки, он должен быть в Min экземпляры.
Я знаю, если вы используете ElasticBeanstalk и установите Min в 1 и Max на 2, он устанавливает Desired в 2 (конечно!) - вы не можете выбрать значение для Desired.
Какой будет вариант использования для другого числа экземпляров Desired и как он отличается? Когда вы ожидаете, что AWS будет масштабироваться ниже вашего Desired, если требуется, больше, чем Min?
Ответы
Ответ 1
Ниже приведены объяснения значений "мин., желаемого и максимального" от поддержки AWS:
MIN: Это будет минимальное количество экземпляров, которые могут выполняться в вашем автомасштабирование. Если срабатывает аварийный сигнал CloudWatch, ваша группа автоматического масштабирования никогда не прекратит экземпляры ниже этого числа.
ЖЕЛАЕТСЯ: Если вы отключите будильник CloudWatch для события масштабирования, тогда будет уведомлять автоматический сканер, чтобы изменить его на заданный более высокая сумма, и автоматический сканер начнет экземпляр/с это число. Если вы отключите будильник CloudWatch, чтобы уменьшить масштаб, изменит автоматически масштабируемый сканер на заданное меньшее число и автоматический сканер завершит экземпляр /s, чтобы перейти к этому номеру.
MAX: Это будет максимальное количество экземпляров, которые вы можете запустить в вашей группы автомасштабирования. Если ваша шкала превысит будильник CloudWatch триггер, ваша группа автомасштабирования никогда не будет создавать экземпляры больше, чем максимальная указанная сумма.
Ответ 2
Подумайте об этом, как элемент пользовательского интерфейса с раздвижным диапазоном.
![введите описание изображения здесь]()
С min и max вы устанавливаете нижнюю границу масштабирования экземпляра. Желаемая мощность, вы устанавливаете то, что вам в настоящее время нужно, чтобы число экземпляров зависало.
Пример: Вы знаете, что ваше приложение будет иметь большую нагрузку из-за маркетинга электронной почты или запуска продукта... просто увеличьте желаемую емкость заблаговременно:
aws autoscaling set-desired-capacity --auto-scaling-group-name my-auto-scaling-group --desired-capacity 2 --honor-cooldown
Источник
Ответ 3
Если вы ожидаете, что AWS будет масштабироваться ниже желаемого, если это необходимо, больше Min?
Это происходит, когда вы устанавливаете будильник CloudWatch на основе некоторой политики AutoScaling. Всякий раз, когда срабатывает эта тревога, он обновляет DesiredCount до того, что указано в config.
Например, если в конфигурации AutoScalingGroup есть Min = 1, Desired = 3, Max = 5, и на AutoScalingPolicy установлен будильник, который говорит, что если использование ЦП составляет менее 50% в течение последовательных 10 минут, тогда Remove 1 instances, тогда будет продолжать уменьшать количество экземпляров на единицу при каждом срабатывании будильника до DesiredCount = MinCount.
Извлеченные уроки: установите MinCount равным > 0 или = DesiredCount. Это позволит убедиться, что приложение не сбрасывается, когда mincount = 0 и загрузка процессора снижается.
Ответ 4
Исходя из моего прочтения, с точки зрения непрофессионала, значение DesiredCapacity автоматически обновляется при масштабировании и уменьшении масштаба событий.
Другими словами,
Увеличение или уменьшение масштаба выполняется путем уменьшения или увеличения значения DesiredCapacity.
Ответ 5
Требуемая емкость просто означает количество экземпляров, которые появятся/запустятся, когда вы запустите автоматическое масштабирование. Это означает, что если требуемая мощность = 4, то 4 экземпляра будут работать до тех пор, пока не произойдет событие увеличения или уменьшения масштаба. Если происходит событие масштабирования, количество экземпляров возрастает до максимальной емкости, а если происходит событие масштабирования, оно снижается до минимальной емкости.
Поправьте меня, если не прав, спасибо.
Ответ 6
"Желаемый" является (обязательно) неоднозначным.
- Это означает " начальное " количество экземпляров. Почему не просто "начальный" тогда? Потому что число может измениться путем автоматического масштабирования событий.
- Так что это означает " текущий " номер экземпляра. Почему бы не просто "текущий" тогда? Потому что во время события автоматического масштабирования экземпляры будут запускаться/завершаться. Эти экземпляры не учитываются в "текущем" количестве экземпляров. Под "текущим" пользователь ожидает экземпляры, которые могут работать.
- Так что это означает " целевой " номер экземпляра. Почему бы не просто "цель" тогда? Я предполагаю, что "цель" так же хороша (неоднозначна), как и "желаема"...
Ответ 7
Я заметил желаемую способность падать, и никакой новый экземпляр не появился, когда
- Я установил один из экземпляров в режим ожидания. Он продолжал работать, но был отсоединен от ELB (запросы не пересылались этому конкретному экземпляру при доступе через ELB DNS). Ни один новый экземпляр не был инициирован AWS. Скорее желаемая емкость была уменьшена на 1
- Когда я изменил состояние экземпляра (из режима ожидания), экземпляр снова был подключен к ELB (экземпляр начал получать запросы при доступе через ELB DNS). Желаемая емкость была увеличена на 1 и стала 2
Следовательно, кажется, что ни один из экземпляров, прикрепленных к ELB, не может пересечь пороговый предел, установленный min и max, но желаемая емкость регулируется или изменяется автоматически в зависимости от того, происходит ли масштабирование или масштабирование. Это было определенно что-то неизвестное для меня.
Это может быть способом сообщить AWS, что это требуемая емкость, требуемая для соответствующего ELB в данный момент времени.
