Как заменить конкретный экземпляр в группе AWS Auto Scaling?

Question

Я ищу процедуру, которую я могу использовать для замены определенного экземпляра в масштабируемой группе AWS, при этом поддерживая "баланс" зоны доступности и не уменьшая емкость в ожидании подготовки нового экземпляра.

Иногда у нас могут быть причины для завершения определенного экземпляра EC2 в масштабной группе, и мы изо всех сил пытаемся найти эффективную процедуру для этого. Я знаю, что могу завершить работу экземпляра напрямую, и он будет заменен, но это временно снижает общую емкость масштабируемой группы при ожидании подготовки нового экземпляра. В нашем случае это десятки минут, так как мы должны настроить и развернуть наше программное обеспечение, прежде чем ALB сможет отправлять запросы.

Если мы увеличим desired_capacityна 1 мы можем подготовить новый экземпляр заранее, но нет гарантии, что он будет создан в той же зоне доступности, что и экземпляр, который мы хотим завершить. Кроме того, если я прерву нарушающий экземпляр и немедленно уменьшуdesired_capacity прекратит ли масштабная группа другой экземпляр?

Итак, как лучше всего управлять этой процедурой?

Answer 1

Вы можете временно приостановить и возобновить определенные процессы масштабирования. С помощью этой функции вы можете достичь желаемого результата несколькими способами, два из которых я описал ниже:

A: Используйте функцию перебалансировки Auto Scaling Group

1. Увеличьте желаемое количество экземпляров группы Auto Scaling на 1 и дождитесь, пока будет доступен новый экземпляр.
2. Временно приостановить Launch процесс масштабирования (это предотвращает автоматический запуск нового экземпляра на следующем шаге)
3. Завершите работу неисправного экземпляра
4. Уменьшите желаемое количество экземпляров группы Auto Scaling на 1 (количество требуемых экземпляров и фактическое количество экземпляров теперь должны снова синхронизироваться)
5. Возобновить Launchпроцесс масштабирования. Если остальные экземпляры не сбалансированы, группа автоматического масштабированияAZRebalance процесс подхватит это и постепенно перебалансирует все зоны доступности.

B: явно запустить новый экземпляр в желаемой зоне доступности:

1. Запустить отдельный экземпляр в желаемой зоне доступности
2. Временно приостановить Terminate процесс масштабирования] (это предотвращает автоматическое завершение дополнительного экземпляра на следующем этапе)
3. Присоедините экземпляр из (1.) к группе автоматического масштабирования.
4. Завершить исходный экземпляр (количество желаемых экземпляров и фактическое количество экземпляров теперь должны снова синхронизироваться)
5. Возобновить Terminate процесс масштабирования

Answer 2

Автоматическое масштабирование дает возможность:

• Присоедините конкретный экземпляр к группе Auto Scaling (которая была создана вне Auto Scaling)
• Отключить конкретный экземпляр от группы Auto Scaling
• Завершить конкретный экземпляр в группе Auto Scaling
• Временно перевести экземпляр из группы Auto Scaling в режим ожидания

При отсоединении, завершении работы или переводе в режим ожидания желаемая емкость группы Auto Scaling может быть автоматически уменьшена, чтобы не запускать заменяющий экземпляр, или ее можно оставить прежней, чтобы запустить заменяющий экземпляр.

Как правило, было бы неплохо, чтобы Auto Scaling запускал любые новые экземпляры, чтобы все экземпляры были идентичными. Таким образом, если вас беспокоит падение емкости, вам следует увеличить желаемую емкость, чтобы запустить новый экземпляр, а затем прекратить нежелательный экземпляр из группы автоматического масштабирования с уменьшением емкости, чтобы вернуть группу к предыдущей требуемой емкости.

Вы правы, что запущенный инстанс не будет гарантированно находиться в той же зоне доступности, что и удаляемый. Автоматическое масштабирование направлено на балансировку зон доступности. Он запустит инстанс в зоне доступности с наименьшим количеством инстансов. Предположим, есть две зоны доступности, которые имеют равное количество экземпляров, и вы хотите удалить экземпляр из зоны доступности А. Увеличение желаемой емкости может запустить экземпляр в зоне доступности Б. После удаления нежелательного экземпляра это будет означать, что зона доступности Б. имеет на два экземпляра больше, чем AZ A. Является ли это проблемой, зависит от общего количества экземпляров в группе Auto Scaling.

Рекомендуется использовать несколько зон доступности для обработки ситуаций, когда зона доступности может выйти из строя. Такой сбой может привести к временной потере экземпляров, пока Auto Scaling запускает новые экземпляры в оставшихся зонах доступности. Если такое падение вызывает беспокойство, рекомендуется запускать дополнительные экземпляры для обработки временного падения мощности. Таким образом, возвращаясь к вашему вопросу, ваша группа Auto Scaling должна иметь достаточную мощность для обработки одного удаляемого и заменяемого экземпляра.. Если временное снижение емкости повлияет на вашу систему, было бы неплохо запустить дополнительные экземпляры, исходя из предположения, что экземпляры могут или будут время от времени давать сбой. Это также поможет в редкой ситуации, в которой происходит сбой зоны доступности, поскольку наличие дополнительной емкости означает, что система не теряет сразу 50% требуемой минимальной емкости.

Итог: Иметь достаточную емкость, чтобы временная замена неисправного экземпляра не оказала существенного влияния на систему. Беспокойство по поводу несбалансированной зоны доступности будет незначительным (максимум 2 экземпляра в разных зонах доступности) по сравнению с последствиями потери 50% емкости при отключении зоны доступности, если постоянно развертывается только минимальная емкость.

В конце концов, все сводится к соотношению затрат и рисков. Использование более 2 зон доступности может снизить влияние отключений зоны доступности.