Автоматичне масштабування EC2 за допомогою точок та запитів на вимогу?


13

Я прагну оптимізувати вартість наших автомашинних груп EC2 шляхом їх запуску точкові екземпляри замість екземплярів на вимогу.

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

Я, здається, не знаходжу способу це зробити, і я спробував переглянути документацію AWS. Здається, що ASG може бути або на вимогу, або на місці, але не гібрид.

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

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

Документація AWS суперечить сама по собі, оскільки в одному місці йдеться про те, що якщо ви введете мінімум сервера, це число "гарантовано", щоб воно було там. Але тоді, коли ви читаєте про точкові екземпляри, запевнень немає. Різниця цін на спот є переконливою, тому я хотів би використати це наскільки я можу, зберігаючи постійно базовий рівень. Чи можливо це?

Відповіді:


1

На даний момент ви можете змішувати попит на замовлення та спостереження за окремими ASG

Тепер автоматичне масштабування Amazon EC2 дозволяє вам надавати та автоматично масштабувати екземпляри в різних варіантах придбання, зонах доступності (AZ) та сімействах екземплярів в одній групі автоматичного масштабування (ASG) для оптимізації масштабу, продуктивності та вартості. Тепер ви можете включити точкові екземпляри за запитом та RI в один ASG , щоб заощадити до 90% на обчисленні.


Так - дякую за оновлення цього питання. Я позначив вашу як нову канонічну відповідь на це.
платформи

15

Розглянутий вище підхід був би трохи безладним і не таким гнучким. Більш канонічний підхід полягає в тому, щоб просто створити 2 ASG (один для спотових, один за запитом), а потім зареєструвати їх обох тим самим ELB (обговорюється тут ). Це дає вам можливість керувати кожним незалежно, а не намагатися вилазити за допомогою LC-swaps в одному ASG.


7

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

Однак, ви могли б подолати це обмеження наступним чином (неперевірене, просто конструкція системи, над якою я жонглював деякий час):

Потенційний обхід

Як зазначено в застосуванні функції автоматичного масштабування для запуску екземплярів точок, точна цінова ставка є параметром використовуваної конфігурації запуску . Як ви зазначали, немає гібридної конфігурації запуску, вона повинна бути або на вимогу, або на місці, а це означає, що для використання випадку потрібні дві різні конфігурації запуску.

Це, мабуть, не допомагає відразу, оскільки ви можете одночасно приєднати лише одну конфігурацію запуску до групи автоматичного масштабування із такими (частково застарілими) обмеженнями (див. Конфігурація запуску ):

Коли ви додасте нову або оновлену конфігурацію запуску до групи автоматичного масштабування, будь-які нові екземпляри будуть запущені за допомогою нових параметрів конфігурації. На існуючі екземпляри це не впливає . Коли автоматичне масштабування потрібно зменшити, воно спочатку скасовує екземпляри, які мають старішу конфігурацію запуску . [акцент мій]

Підкреслені частини є ключовими, оскільки перша охоплює вимогу підтримувати запущені екземпляри після зміни від відповідної початкової конфігурації запуску на вимогу на додаткову конфігурацію запуску на місці, а остання вже не обов'язково більше тому нещодавно введена Політика припинення автоматичного масштабування (для змін зазвичай не було фанфару через супровідну публікацію блогу AWS), задокументовану в Політиці щодо припинення дії для Вашої Групи автоматичного масштабування :

Перш ніж автоматичне масштабування вибере екземпляр для припинення, він спочатку ідентифікує зону доступності, яка має більше примірників, ніж інші зони доступності, що використовуються групою. Якщо всі зони доступності мають однакову кількість примірників, вона визначає випадкову зону доступності. У межах визначеної зони доступності автоматичне масштабування використовує політику припинення для вибору примірника для припинення . [акцент мій]

Як зазначено у розділі " Як працює ваша політика припинення" , тепер ви можете вказати NewestInstance , якщо ви хочете, щоб останній запущений екземпляр був скасований , що було б одним із останніх запущених спот-екземплярів:

Автоматичне масштабування використовує час запуску екземпляра для ідентифікації екземпляра, який був запущений останнім часом.

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

Caveat

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

Удачі!


2
Це має сенс - велика детективна робота. Все ще існує ризик відключення, але, здається, ви виявили кілька нових способів зменшити цей ризик. Сподіваємось, колись у нас з’явиться простий прапорець для ASG: "Екземпляри на рівні або нижче мінімуму сервера - це екземпляри на вимогу". Спасибі!
платформи

1

Я взяв натхнення з відповідей тут, щоб придумати https://github.com/ashwanthkumar/matsya

Це допомагає вам зробити наступне

  • Вам завжди потрібен парк машин для ваших кластерних вимог Hadoop / Mesos / YARN
  • Ви хочете заощадити гроші, використовуючи Spot, а також резервний OD, тому що вам потрібна потужність обробки для задоволення вашої угоди про рівень обслуговування
  • Щоб повернути гроші знову, поверніться до Spot один раз на OD.

1
Будь ласка, пам’ятайте про нашу політику щодо самореклами
HBruijn

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

Якби я подумав, що ваша відповідь є фактичним спамом, я б позначив її вже такою, тому вам не потрібно видаляти свою публікацію. Посилання на просування товару є більш переважним тим, що, хоча така відповідь може бути цінною, існує прекрасний баланс, про який відносно нові користувачі, такі як ви, часто не знають. І як модератор я вважаю за краще зараз вас навчати, перш ніж переходити будь-які рядки, яких ви не знали, що існувало (це прикро повторюваний зразок)
HBruijn

Має сенс. Дякуємо за голову щодо політики.
ashwanthkumar

1

Якщо вам потрібен лише 1 ASG зі статичною кількістю екземплярів на вимогу, слід працювати наступним чином:

  • Створіть групу автоматичного масштабування на основі конфігурації запуску точкового інстанції.

  • Призупинити автоматичне масштабування на ASG

  • Вручну додайте екземпляри на вимогу (статичне базове навантаження) до ASG та увімкніть захист екземплярів для цих екземплярів.

  • Відновити автоматичне масштабування на ASG

  • Політика автоматичного масштабування за замовчуванням тепер ігнорує екземпляри на вимогу (завдяки захисту) та скасовує таку ж кількість точкових екземплярів, що й екземпляр на вимогу, щоб досягти бажаного числа групи. Будь-які заходи масштабування або вимкнення запускають або припиняють лише спот-екземпляри.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.