Автоматическое масштабирование EC2 с точечными экземплярами и экземплярами по требованию?

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

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

Кажется, я не могу найти способ сделать это, и я попытался просмотреть документацию AWS. Похоже, что ASG может быть либо по требованию, либо спотовым, но не гибридным.

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

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

Документация AWS находится в противоречии с самим собой, поскольку в одном месте говорится, что если вы введете минимум сервера, это число «гарантировано» будет там. Но тогда, когда вы читаете о точечных случаях, нет никаких гарантий. Разница в цене на спот неоспорима, поэтому я хотел бы максимально использовать это, сохраняя при этом постоянный базовый уровень. Это возможно?

На данный момент вы можете смешивать ondemand и находить экземпляры в одной ASG

Автоматическое масштабирование Amazon EC2 теперь позволяет вам предоставлять и автоматически масштабировать экземпляры по вариантам покупки, зонам доступности (AZ) и семействам экземпляров в одной группе автоматического масштабирования (ASG), чтобы оптимизировать масштаб, производительность и стоимость. Теперь вы можете включить точечные экземпляры с On-Demand и RI в одну ASG , чтобы сэкономить до 90% на вычислениях.

Подход, обсужденный выше, будет немного грязным и не таким гибким. Более канонический подход является просто создать 2 ASGs (один для пятна, один для по требованию) , а затем зарегистрировать их обоих с тем же УДРА (обсуждаются здесь ). Это дает вам возможность контролировать каждого независимо, вместо того, чтобы пытаться обмануть LC-свопами в одной ASG.

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

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

Потенциальный обходной путь

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

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

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

Тем не менее, выделенные части являются ключевыми, поскольку первая охватывает требование поддерживать экземпляры по требованию после перехода от соответствующей начальной конфигурации запуска по требованию к дополнительной конфигурации точечного запуска, и последняя больше не обязательно имеет место из-за недавно введенные Политики прекращения автоматического масштабирования (для изменений обычно не было фанфары через сопровождающее сообщение в блоге AWS), задокументированные в Политике прекращения использования экземпляров для вашей группы автоматического масштабирования :

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

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

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

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

Предостережение

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

Удачи!

Я черпал вдохновение из ответов здесь, чтобы придумать https://github.com/ashwanthkumar/matsya

Это поможет вам сделать следующее

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

Если вам нужна только 1 ASG со статическим числом экземпляров по требованию, должно работать следующее:

• Создайте группу автоматического масштабирования на основе конфигурации запуска точечного экземпляра.

• Приостановить автоматическое масштабирование на ASG

• Вручную добавьте экземпляры по требованию (статическая базовая нагрузка) в ASG и включите защиту экземпляров для этих экземпляров.

• Возобновить автомасштабирование на ASG

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