AWS ECS Auto Scaling для контейнеров Windows

У нас есть несколько (›5) рабочих нагрузок веб-приложений Windows Framework 4.8 .Net MVC, размещенных в кластере ECS с несколькими зонами доступности (тип EC2: Windows), доступном извне с помощью ALB. Все эти приложения работают нормально в течение некоторого времени. Теперь требуется выборочно ввести автоматическое масштабирование для этих приложений (из 5, 3 нуждаются в масштабировании). Мы думаем об использовании двух перечисленных ниже функций вместе для достижения этой цели.

  1. Автоматическое масштабирование службы ECS для масштабирования каждого экземпляра контейнера (уровень задачи).

  2. Автоматическое масштабирование кластера ECS с использованием поставщиков емкости ECS на уровне экземпляра EC2. Это обеспечивает пространство для контейнеров, созданных задачей на шаге 1.

У меня вопрос: это достижимо? Или это правильный подход для контейнеров Windows? . Почему я подчеркиваю контейнер Windows, потому что AWS ECS не хватает многих функций по сравнению с контейнерами Linux, например, мы не можем установить мягкий предел памяти контейнера (резервирование памяти), но должны упомянуть жесткое ограничение (память) при настройке самой задачи, что я думаю, это серьезное ограничение.

если это недостижимо, каковы варианты? Сейчас мы не можем перейти на EKS, и очевидно, что Windows не поддерживает Fargate.


person user793886    schedule 30.07.2020    source источник


Ответы (2)


Да, это достижимо. У нас есть кластер ECS, на котором работает полдюжины служб, использующих контейнеры докеров Windows. Как вы упомянули, существует два типа автомасштабирования: на уровне задачи и на уровне экземпляров контейнера. Автоматическое масштабирование на уровне задач проще, чем автоматическое масштабирование экземпляров контейнера.

Экземпляры контейнеров

Для группы автоматического масштабирования экземпляров контейнера вам потребуются следующие ресурсы:

  1. Кластер ECS (который у вас уже есть).
  2. Конфигурация запуска для ваших экземпляров контейнера с использованием одного из AMI, оптимизированные для Windows ECS.
  3. Группа с автоматическим масштабированием, которая использует вашу конфигурацию запуска для создания новых экземпляров.
  4. Ваши политики масштабирования, которые могут быть комбинацией целевых политик резервирования, запланированных политик или поставщиков емкости.

В конфигурации запуска вам необходимо зарегистрировать новые экземпляры в кластере ECS. Мы используем UserData для этого и для настройки некоторых дополнительных параметров (например, для работы с ограничениями жесткой / программной памяти в Windows, о которых вы упомянули):

<powershell>
[Environment]::SetEnvironmentVariable(ECS_RESERVED_MEMORY, 256, Machine) 
[Environment]::SetEnvironmentVariable(ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE, $TRUE, Machine) 
[Environment]::SetEnvironmentVariable(ECS_ENABLE_CPU_UNBOUNDED_WINDOWS_WORKAROUND, $TRUE, Machine) 
Initialize-ECSAgent -Cluster <your-cluster> -EnableTaskIAMRole -LoggingDrivers '[json-file,awslogs]' 
</powershell>

Что касается политик автоматического масштабирования, у вас есть несколько вариантов, поэтому вам нужно выбрать то, что лучше всего для вашего варианта использования. Сейчас мы выполняем масштабирование с использованием целевого уровня резервирования памяти 80% и планируем некоторые действия по масштабированию в определенное время дня, чтобы убедиться, что у нас достаточно емкости на пару раз в течение дня, когда мы ожидаем скачков. Мы еще не начали использовать поставщиков емкости, так как вокруг них были некоторые ошибки и проблемы, поэтому я даю им еще время, чтобы они повзрослели (я думаю, что они уже решили многие проблемы ... вы можете узнать больше об этом из этого комментария и далее).

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

Имейте в виду, что без контейнеров емкости может возникнуть ситуация, когда группа не масштабируется, даже если в любом экземпляре недостаточно памяти или ЦП для добавления новых задач. Это будет зависеть от памяти ваших задач и конфигурации ЦП, а также от вашей цели резервирования (например, у вас есть задача, которая требует 20% вашей текущей доступной емкости памяти для всего кластера, ваш кластер использует 85% памяти, но ваша политика масштабирования не будет масштабироваться, пока вы не достигнете 90% использования памяти). Это проблема, которую поставщики мощности призваны решить. В нашем случае использования и наших конфигурациях задач у нас никогда не возникает проблемы с не масштабированием группы, но мы знаем, что мы чрезмерно выделяем наш кластер, чтобы избежать этого.

Другая проблема заключается в масштабировании экземпляров вашего контейнера: вам нужно каким-то образом настроить инстансы на слив, чтобы у ваших задач было время корректно завершиться, что не обрабатывается AWS автоматически. Здесь есть открытая проблема, которую вы можете отслеживать. Мы решили эту проблему, используя лямбда-функцию и обработчик жизненного цикла автомасштабирования на основе этого репозитория Github из этого комментария.

Задания

Задачи масштабирования проще:

  1. Вам необходимо связать свои задачи с балансировщиком нагрузки, чтобы задачи автоматически регистрировались / отменялись в / из ELB.
  2. Вы создаете политику масштабирования для своей задачи (например, вы можете использовать ALBRequestCountPerTarget для увеличения в зависимости от количества запросов на цель или также запланировать действия автомасштабирования).

В определении задачи вы должны установить порт хоста на 0, чтобы он автоматически назначался ELB (прочтите документацию для hostPort здесь).

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

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

person Arturo Monge    schedule 31.07.2020
comment
Спасибо Артуро за подробное объяснение. Тем не менее, проблема существует для контейнеров Windows, если они не поддерживают мягкое ограничение (резервирование памяти) и будут вынуждены установить жесткое ограничение, и это ограничит гибкость / контроль при помещении n задач в Короче говоря, дорогостоящий обходной путь будет заключаться в использовании комбинации автоматического масштабирования уровня обслуживания ECS и автоматического масштабирования кластера с использованием поставщиков емкости. Первый будет инициировать новые запросы задач, а второй позаботится о экземплярах, когда они когда-либо потребуются задачам. github.com/aws/amazon-ecs-agent/issues/1144 - person user793886; 31.07.2020
comment
@ user793886 С точки зрения распределения памяти задач для контейнеров Windows, вы можете установить жесткое ограничение (которое будет использоваться поставщиками емкости для определения нагрузки) или использовать параметр ECS_ENABLE_RAM_UNBOUNDED_WINDOWS_WORKAROUND, чтобы не ограничивать память задач, и в этом случае поставщик емкости будет только использовать ЦП для определения нагрузки. С помощью этого параметра у вас может быть больше задач, пока их общее использование памяти не превышает доступную память. Применимость зависит от вашего варианта использования, но обеспечивает большую гибкость распределения. - person Arturo Monge; 01.08.2020
comment
PFB фрагмент PS1, который я вставил в LC, но мне все равно не повезло, я получаю, что Windows не поддерживает резервирование памяти ‹powershell› [Environment] :: SetEnvironmentVariable (ECS_RESERVED_MEMORY, 256, Machine) [Environment] :: SetEnvironmentVariable (ECS_ENABLE_RAM_UNBOUNDED_WINDOWS_ , Машина) [Environment] :: SetEnvironmentVariable (ECS_ENABLE_CPU_UNBOUNDED_WINDOWS_WORKAROUND, $ true, Machine) Initialize-ECSAgent -Cluster ‹cluster› -EnableTaskIAMRole -LoggingDrivers '[json-file, awslogshell]' ‹/powershell] '‹/powershell - person user793886; 03.11.2020
comment
В Task Def я пропустил Hard limit и предоставил Soft Limit как 256. Синтаксис в порядке? ничего не хватает? AMI - это оптимизированная для ECS Windows Server 2016. Какая минимальная версия агента требуется для этого у меня 1.35.0? - person user793886; 03.11.2020
comment
это ECS_ENABLE_MEMORY_UNBOUNDED_WINDOWS_WORKAROUND или ECS_ENABLE_RAM_UNBOUNDED_WINDOWS_WORKAROUND? - person user793886; 03.11.2020

Чтобы отключить жесткое ограничение памяти для контейнеров Windows, установите для переменной среды ECS_ENABLE_MEMORY_UNBOUNDED_WINDOWS_WORKAROUND значение true при запуске шаблона UserData.

  1. Пользовательские данные шаблона запуска AWS
<powershell>
[Environment]::SetEnvironmentVariable("ECS_RESERVED_MEMORY",256, "Machine") 
[Environment]::SetEnvironmentVariable("ECS_ENABLE_MEMORY_UNBOUNDED_WINDOWS_WORKAROUND", $true, "Machine") 
[Environment]::SetEnvironmentVariable("ECS_ENABLE_CPU_UNBOUNDED_WINDOWS_WORKAROUND", $true, "Machine") 
Initialize-ECSAgent -Cluster <clustername>-EnableTaskIAMRole -LoggingDrivers '["json-file","awslogs"]' 
</powershell>
  1. В определении задачи «Пропустить жесткое ограничение памяти» и указать «Мягкое ограничение» (резервирование), которое будет игнорироваться агентом.

Версия агента должна быть ›= 1.32.1 (чем больше, тем лучше).

person user793886    schedule 04.11.2020