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

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

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

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

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


person Peter McEvoy    schedule 15.05.2020    source источник


Ответы (2)


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

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

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

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

  1. Запустить отдельный экземпляр в желаемой зоне доступности
  2. Временно приостановить Terminate процесс масштабирования] (это предотвращает автоматическое завершение дополнительного экземпляра на следующем этапе)
  3. Присоедините экземпляр из (1.) к группе автоматического масштабирования.
  4. Завершить исходный экземпляр (количество желаемых экземпляров и фактическое количество экземпляров теперь должны снова синхронизироваться)
  5. Возобновить процесс масштабирования Terminate
person Dennis Traub    schedule 15.05.2020
comment
Я обновил ответ, потому что в обоих вариантах произошла путаница с запуском и остановкой. - person Dennis Traub; 15.05.2020
comment
Optino B звучит как наиболее работоспособный, просто потому, что я точно знаю, где создается экземпляр. Интересно, есть ли у вас ссылка на процесс AZRebalance? похоже, что моя виртуальная машина будет перемещена из одной зоны доступности в другую - конечно, это нежелательно, поскольку такой тип операции должен приостановить виртуальную машину, чтобы переместить ее? - person Peter McEvoy; 18.05.2020
comment
Просто прочтите о AZRebalance и о том, что происходит не миграция - это kill-n-create: при перебалансировке Amazon EC2 Auto Scaling запускает новые инстансы перед завершением работы старых, чтобы перебалансировка не ставила под угрозу производительность или доступность вашего приложения. - к сожалению, учитывая время, необходимое для развертывания нашего программного обеспечения, мы не хотели бы быть разоблаченными, пока это происходит - person Peter McEvoy; 18.05.2020
comment
Вариант А содержит меньше движущихся частей, которыми вы можете явно управлять, а с вариантом Б вы полностью контролируете весь процесс. Так что все зависит от того, с чем вы чувствуете себя лучше. - person Dennis Traub; 18.05.2020
comment
Относительно вашего второго комментария: да. Виртуальные машины нельзя перемещать между зонами доступности, они воссоздаются. Если у вас долгое время запуска, вариант B, безусловно, может быть предпочтительнее. - person Dennis Traub; 18.05.2020

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

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

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

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

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

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

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

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

person John Rotenstein    schedule 15.05.2020
comment
Я думаю, что это денежная цитата прямо здесь: иметь достаточную мощность, чтобы временная замена неисправного экземпляра не оказала значительного влияния на систему. @ dennis-traub ответил на мой вопрос технически, но я думаю, что вы ответили на него философски, и мне придется вернуться к своим базовым предположениям ... - person Peter McEvoy; 18.05.2020
comment
Да, полностью согласен. И, честно говоря, если бы мне пришлось выбирать между ответом Джона и моим ответом, я бы определенно взял его на себя, потому что он не только технически правильный, но и передает аргументы, лежащие в основе хорошо спроектированного приложения. Облако предоставляет множество новых возможностей, которых у нас никогда не было в локальной среде, и это позволяет нам заново изобретать и переосмысливать способы управления нашими приложениями. - person Dennis Traub; 18.05.2020