Групи автоматичного масштабування AWS EC2: Я отримую мінімальну і максимальну кількість, але для чого потрібні обмеження бажаних екземплярів?

Коли вам налаштувати з'єднання групи Auto Scaling в AWS EC2 Minі Maxкордонів , здається, має сенс:

• Мінімальна кількість випадків для зменшення на основі політики
• Максимальна кількість екземплярів для масштабування на основі політик

Однак я ніколи не міг обернути голову навколо того, на що Desiredмає намір вплинути.

Я завжди просто встановлював Desiredрівне Min, оскільки, як правило, я хочу платити Amazon мінімальну десятину, і якщо вам не потрібен екземпляр для обробки навантаження, він повинен складатись із Minкількості екземплярів.

Я знаю, якщо ви використовуєте ElasticBeanstalkі встановлюєте Minзначення 1, а Maxзначення 2 - Desiredзначення 2 (звичайно!) - ви не можете вибрати значення для Desired.

Яким буде варіант використання для різної Desiredкількості випадків і чим він відрізняється? Коли ви очікуєте, що AWS зменшиться нижче, ніж ваш, Desiredякщо бажаєте, більший ніж Min?

Ось пояснення щодо значень "мінімальне, бажане та максимальне" від служби підтримки AWS:

MIN: Це буде мінімальна кількість екземплярів, які можуть працювати у вашій групі автоматичного масштабування. Якщо спрацьовує сигнал тривоги CloudWatch, ваша група автоматичного масштабування ніколи не припиняє екземпляри нижче цього числа

БАЖАНИЙ: Якщо ви відключите сигнал тривоги CloudWatch для збільшення масштабу, він повідомить автоматичний масштабатор про необхідність змінити бажану величину на зазначену більшу суму, і автоматичний шкалер запустить екземпляри, щоб відповідати цьому номеру. Якщо ви відключите сигнал будильника CloudWatch, щоб зменшити масштаб, він змінить бажаний автоматичний масштабувач на вказане нижче число, і автоматичний масштабувач завершить екземпляри / екземпляри, щоб дістатися до цього числа.

МАКС. Це буде максимальна кількість випадків, які ви можете запустити у своїй групі автоматичного масштабування. Якщо сигнал масштабування CloudWatch продовжує спрацьовувати, ваша група автоматичного масштабування ніколи не створюватиме екземплярів, що перевищують вказану максимальну суму.

Думайте про це як про елемент ковзаючого інтерфейсу.

За допомогою min та max ви встановлюєте нижню межу масштабування вашого екземпляра. З бажаною ємністю ви встановлюєте те, що ви хотіли б в даний час наводити кількість екземплярів.

Приклад: Ви знаєте, що ваша програма матиме велике навантаження через маркетингову електронну пошту або запуск продукту ... просто заздалегідь збільште бажану потужність:

aws autoscaling set-desired-capacity --auto-scaling-group-name my-auto-scaling-group --desired-capacity 2 --honor-cooldown

Джерело

Коли ви очікуєте, що AWS буде масштабуватись нижче, ніж бажаний, якщо бажано більше, ніж Min?

Це трапляється, коли ви встановлюєте будильник CloudWatch на основі певної політики автомасштабування. Щоразу, коли спрацьовує цей сигнал, він буде оновлювати DesiredCount до того, що згадується в config.

Наприклад, якщо конфігурація AutoScalingGroup має Min = 1, Desired = 3, Max = 5, а на AutoScalingPolicy встановлено сигнал тривоги, який говорить, що якщо використання центрального процесора становить <50% протягом 10 хвилин поспіль, Remove 1 instancesтоді він буде продовжувати зменшувати кількість екземплярів на 1 щоразу, коли спрацьовує будильник, поки DesiredCount = MinCount.

Вивчені уроки: Встановіть MinCount> 0 або = DesiredCount. Це гарантує, що програма не буде виведена з ладу, коли mincount = 0, а використання процесора зменшиться.

"Бажане" (неодмінно) неоднозначне.

• Це означає " початкову " кількість екземплярів. Чому б тоді не просто "початковий"? Оскільки число може змінюватися внаслідок подій автомасштабування.
• Отже, це означає " поточний " номер екземпляра. Чому тоді не просто "поточний"? Оскільки під час події автомасштабування екземпляри запускаються / припиняються. Ці екземпляри не враховуються до "поточної" кількості екземплярів. Під "поточним" користувач очікує екземплярів, які працюють.
• Отже, це означає " цільову " кількість екземплярів. Чому б тоді не просто "націлити"? Думаю, "ціль" настільки ж добра (неоднозначна), як і "бажана" ...

Виходячи з мого прочитання, неспеціалістично кажучи, DesiredCapacityзначення автоматично оновлюється щодо масштабних та масштабних подій.

Іншими словами,

Масштабування або масштабування здійснюється шляхом зменшення або збільшення DesiredCapacityзначення.

Бажана ємність просто означає кількість екземплярів, які з’являться / спрацьовують при запуску автомасштабування. Це означає, що якщо бажана ємність = 4, то 4 екземпляри продовжуватимуть працювати до тих пір, доки не спрацює будь-яка подія збільшення чи зменшення. Якщо відбувається подія масштабування, кількість екземплярів збільшиться до максимальної ємності, а якщо подія зменшення масштабу зменшиться до мінімальної ємності.

Виправте мене, якщо помилився, дякую.

Я помітив, що бажана ємність знизилася, і жоден новий екземпляр не з’явився, коли

1. Я перевів один із випадків у режим очікування. Він продовжував працювати, але був від'єднаний від ELB (запити не пересилались до цього конкретного екземпляра при доступі через ELB DNS). AWS не ініціювала жодного нового екземпляра. Швидше бажана потужність була зменшена на 1.
2. Коли я змінив стан екземпляра (з режиму очікування), екземпляр знову був приєднаний до ELB (екземпляр почав отримувати запити при доступі через ELB DNS). Бажана потужність була збільшена на 1 і стала 2.

Отже, здається, жоден екземпляр, приєднаний до ELB, не може переступити порогове обмеження, встановлене на min і max, але бажана ємність регулюється або змінюється автоматично залежно від появи масштабу в події або масштабу. Це було точно щось невідоме для мене.

Це може бути спосіб повідомити AWS, що це бажана потужність, необхідна для відповідного ELB в даний момент часу.

Мінімальне та максимальне значення є зрозумілими, але бажане викликало заплутаність, поки я не приєднав політику автоматичного масштабування відстеження цілей до ASG, де цільовою метрикою було використання центрального процесора. Тут бажані екземпляри масштабувались та масштабувались на основі використання цільового процесора. Якщо будь-який бажаний підрахунок проводиться за допомогою хмарного форматування / вручну, ASG тим часом створить таку ж кількість примірників, як бажаний підрахунок. Але пізніше політика ASG автоматично налаштує екземпляри бажань на основі використання цільового процесора.