Политика прекращения работы самого старого экземпляра AWS AutoScaling не всегда завершает работу самых старых экземпляров.

Сценарий

Я создаю сценарий, который запускает новые экземпляры в группу AutoScaling, а затем удаляет старые экземпляры. Цель состоит в том, чтобы представить недавно созданные (или обновленные) AMI группе AutoScaling. Это достигается за счет увеличения емкости Desired на удвоение текущего числа экземпляров. Затем, после того, как новые экземпляры будут Running, уменьшая емкость Desired на то же число.

Проблема

Когда я запускаю сценарий, я наблюдаю, как емкость группы увеличивается вдвое, новые экземпляры подключаются к сети, достигают состояния Running, а затем емкость группы уменьшается. Работает как шарм. Проблема в том, что ИНОГДА экземпляры, которые прекращаются из-за уменьшения, на самом деле являются новыми, а не старыми.

Вопрос

Как я могу гарантировать, что группа AutoScaling всегда завершает работу самого старого экземпляра?

Настройки

  • Группа AutoScaling имеет следующие Termination Polices: OldestInstance, OldestLaunchConfiguration. Политика Default была удалена.
  • Default Cooldown установлен на 0 секунд.
  • У группы есть только одна зона доступности.

Исправление проблем

  • Я поигрался с настройкой Cooldown. В итоге просто поставил на 0.
  • Я ждал разное время, чтобы увидеть, должны ли существующие серверы работать в течение определенного времени, прежде чем они будут остановлены. Похоже, что если им меньше 5 минут, они с меньшей вероятностью будут прерваны, но не всегда. У меня были серверы, которым было 20 минут, которые не были отключены вместо новых. Возможно, у недавно запущенных экземпляров есть льготный период защиты от прерывания?

Концессия

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

Я мог бы принудительно завершить работу определенных экземпляров, но это нарушило бы суть OldestInstance политики завершения.

Обновление: 12 февраля 2014 г. Я продолжаю видеть это в продакшене. Экземпляры со старыми конфигурациями запуска, которые работали в течение нескольких недель, останутся работающими, а новые экземпляры будут отключены. На данный момент я считаю это ошибкой. Пару лет назад на эту тему была открыта ветка на Amazon по этой теме. без разрешения.

Обновление: 21 февраля 2014 г. Я работал с сотрудниками службы поддержки AWS, и на данный момент они предварительно подтвердили, что это может быть ошибка. Они исследуют проблему.


amazon-web-services autoscaling
person SunSparc    schedule 24.01.2014    source источник
comment
В чем именно заключается вопрос?   -  person EkoostikMartin    schedule 25.01.2014

Ответы (3)


arrow_upward
3
arrow_downward

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

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

- http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/us-termination-policy.html

Если вы не в балансе, то сохранение баланса, возможно, является наиболее разумной стратегией, особенно если вы используете ELB. документация немного неоднозначна, но ELB будет рекламировать ее. публичный IP в DNS для каждой зоны доступности, где он настроен; эти три IP-адреса обеспечат балансировку нагрузки первого уровня за счет циклического DNS. Если все зоны доступности, в которых включен ELB, имеют работоспособные экземпляры, то, по всей видимости, существует корреляция 1: 1 между тем, какой внешний IP-адрес попадает на трафик, и серверами какой зоны доступности этот трафик будет предлагаться ELB - по крайней мере, это то, что показывают журналы моего сервера. Кажется, что ELB не направляет трафик между зонами доступности на альтернативные серверы, если только все серверы в данной зоне не обнаружены как неисправные, и это может быть одним из оправданий того, почему они внедрили автоматическое масштабирование таким образом.

Хотя этот алгоритм не всегда может сначала уничтожить самый старый экземпляр на региональной основе, если он действительно работает, как задокументировано, он уничтожит самый старый в выбранной зоне доступности, и в какой-то момент он должен закончить цикл через все их в течение нескольких смен нагрузки ... так что самый старый тоже не будет работать бесконечно. Чем больше количество экземпляров в группе, тем менее значительным должен быть этот эффект.

person Michael - sqlbot    schedule 25.01.2014
comment
Спасибо за ваши Коментарии. Я действительно считал зону доступности. Однако в моем случае я использую только одну зону, поэтому я предполагаю, что это не применимо. - person SunSparc; 27.01.2014
comment
Вы на 100% уверены, что ваша группа автоматического масштабирования не настроена на использование всех зон доступности? Я видел именно то поведение, которое описал ваш вопрос, и переход на единую зону доступности, похоже, устранил его. Я выполнил полдюжины непрерывных развертываний, и это надежно завершает работу самого старого экземпляра. Раньше, по крайней мере, каждый раз завершал новый экземпляр. Похоже, OldestInstance действительно может рассматривать зоны доступности, вопреки документации. - person Derek Lewis; 17.10.2014

arrow_upward
0
arrow_downward

Есть еще пара способов сделать это:

  1. Увеличить желаемое до 2x
  2. Дождитесь действия по увеличению емкости
  3. Когда новые экземпляры запущены, приостановите всю активность AS (as-suspend -cesses MyAutoScalingGroup)
  4. Сбросить желаемый
  5. Завершить старые экземпляры
  6. Возобновить деятельность AS.

Or:

  1. Создайте новую ASG с новой конфигурацией запуска.
  2. Приостановить работу AS, пока 1. не будет завершено.
  3. Если все в порядке, удалите старую ASG.
  4. Возобновить деятельность AS

Для окончательного развертывания отката:

  1. Создайте новый ELB (возможно, придется попросить Amazon выделить больше elb, если у вас много трафика, это немного хромает и делает его не удобным для автоматизации)
  2. Создать новую ASG с новым LC
  3. Переключить DNS на новый ELB
  4. Удалите старый ELB / ASG / LC, если все в порядке, если не просто измените DNS обратно

Или с новым API ASG, который позволяет вам присоединять / отсоединять экземпляры от ASG:

  1. Как-то создайте свои новые экземпляры (можно просто запустить экземпляры или создать временный asg)
  2. Приостановить активность AS, используйте http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/attach-instance-asg.html, чтобы прикрепить их к старому ASG,
  3. Используйте http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/detach-instance-asg.html или отключите старые экземпляры.
  4. Возобновить деятельность AS

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

A.

person ambakshi    schedule 04.10.2014

arrow_upward
0
arrow_downward

Мой вариант использования заключается в том, что нам нужно было уменьшить масштаб и иметь возможность выбирать, какие машины будут отключены. К сожалению, политика завершения "OldestFirst" у нас тоже не сработала. Я смог использовать вариант метода присоединения / отсоединения, которым поделился амбакши, чтобы удалить самый старый (или любой выбранный мной экземпляр) и в то же время снизить желаемое значение экземпляров группы автомасштабирования.

Шаг 1. Измените минимальное значение группы автомасштабирования на число, до которого вы хотите уменьшить масштаб.

Шаг 2. Приостановите работу ASG

Шаг 3 - Отсоедините экземпляры, которые вы хотите прекратить, вы можете выполнить несколько экземпляров одной командой. Обязательно используйте флаг Should-Decment-required-capacity

Шаг 4 - Возобновите работу ASG

Шаг 5. Завершите работу экземпляров с помощью консоли или интерфейса командной строки.

ОБНОВЛЕНИЕ

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

person kwackbars    schedule 03.12.2014