Автомасштабирование EC2 с точечными и экземплярами по запросу?
Это кажется, что Вы выполняете междоменный запрос Ajax, которые запрещены веб-браузерами из-за проблем безопасности.
Я создал бы страницу PHP серверной стороны, которая получает удаленный ресурс, к которому Вы пытаетесь получить доступ в своем запросе Ajax и просто выполнить запрос Ajax для той страницы серверной стороны. Страница серверной стороны действует как прокси между Вашим клиентским и Вашим удаленным ресурсом, который обходит власть веб-браузера на междоменных клиентских запросах.
В настоящее время вы можете смешивать инстансы по требованию и спотовые в одной ASG.
Amazon EC2 Auto Scaling теперь позволяет выделять и автоматически масштабировать инстансы для разных вариантов покупки, зон доступности (AZ), и семейства экземпляров в одной группе Auto Scaling (ASG) для оптимизации масштабирования, производительности и стоимости. Теперь вы можете включать спотовые инстансы с On-Demand и RI в одну ASG , чтобы сэкономить до 90% на вычислениях.
Этот гибридный подход с автоматическим масштабированием , к сожалению, действительно не доступен из коробки.
Однако вы можете работать обойти это ограничение следующим образом (непроверенный, просто проект системы, с которым я некоторое время жонглировал):
Возможное обходное решение
Как указано в Использование автоматического масштабирования для запуска спотовых экземпляров , место Price bid - это параметр используемой конфигурации запуска . Как вы отметили, нет доступной гибридной конфигурации запуска, она должна быть либо по запросу, либо точечно, что означает, что для варианта использования требуются две разные конфигурации запуска.
Это не похоже на помогите сразу, потому что Вы можете присоединить только одну конфигурацию запуска к группе Auto Scaling за раз , Группа масштабирования, любые новые экземпляры будут запускаться с использованием нового параметры конфигурации. Существующие экземпляры не затрагиваются . когда Автоматическое масштабирование необходимо уменьшить, оно сначала завершает экземпляры, иметь более старую конфигурацию запуска . [курсив мой]
Тем не менее, выделенные части являются ключевыми, причем первые покрывают требование поддерживать работу экземпляров по требованию после перехода от соответствующей начальной конфигурации запуска по требованию к дополнительной конфигурации спотового запуска, и последнее не обязательно имеет место из-за недавно введенных политик завершения автоматического масштабирования (для изменения обычно не было фанфар через сопутствующее сообщение в блоге AWS), задокументировано в Политика завершения экземпляра для вашей группы Auto Scaling :
Прежде чем Auto Scaling выберет экземпляр для завершения, он сначала определяет зону доступности, в которой больше экземпляров, чем другие зоны доступности, используемые группой. Если все зоны доступности имеют одинаковое количество экземпляров, он определяет случайную доступность Зона. В пределах идентифицированной зоны доступности автоматическое масштабирование использует политика завершения для выбора экземпляра для завершения . [выделено мной]
Как указано в Как работает ваша политика завершения , теперь вы можете указать NewestInstance , , если хотите, чтобы последний запущенный экземпляр был завершен , который будет одним из недавно запущенных спотовых экземпляров:
Auto Scaling использует время запуска экземпляра, чтобы идентифицировать экземпляр который был запущен последним.
Очевидно, это может быть немного больше, например, вы можете указать любую из политик как отдельную политику или вы можете перечислить несколько политик в упорядоченном списке , но этот подход должен гарантировать, что нагрузка всех экземпляров будет учтена в измерениях автоматического масштабирования и триггерах ; Однако остается одно предостережение:
Предостережение
Если балансировщик нагрузки завершает работу одного из экземпляров по запросу по любой другой причине (например, потому, что он сам по себе вышел из строя), он не будет заменен на экземпляр по запросу. экземпляр автоматически. Поэтому вам нужно будет отслеживать и учитывать это событие отдельно, например, снова временно активировав конфигурацию запуска по требованию.
Удачи!
Подход, описанный выше, был бы немного запутанным и не таким гибким. Более канонический подход состоит в том, чтобы просто создать 2 ASG (одну для спотовой, одну для запроса по запросу), а затем зарегистрировать их , обе с одним и тем же ELB (обсуждается здесь ). Это дает вам возможность управлять каждым независимо друг от друга, а не пытаться сбрасывать карты с помощью свопов LC в одной ASG.
Я черпал вдохновение из ответов здесь, чтобы придумать https://github.com/ashwanthkumar/matsya
Это поможет вам сделать следующее.
- Вам всегда нужен парк машин для ваших требований к кластеру Hadoop / Mesos / YARN
- Вы хотите сэкономить деньги, используя спотовую точку, но также можете вернуться к OD, потому что вам нужна вычислительная мощность в соответствии с вашим SLA
- Один раз переключитесь обратно на Spot на OD, чтобы снова сэкономить деньги.
Если вам нужна только 1 ASG со статическим числом экземпляров по требованию должно работать следующее:
Создать группу автоматического масштабирования на основе конфигурации запуска спотового экземпляра.
Приостановить автоматическое масштабирование на ASG
Добавление экземпляров по запросу вручную (статическая базовая нагрузка) в ASG и включите защиту экземпляров для этих экземпляров.
Возобновить автоматическое масштабирование на ASG
Политика автоматического масштабирования по умолчанию теперь будет игнорировать экземпляры по требованию (из-за защиты) и завершать то же количество спотовых экземпляров, что и на- Требовать экземпляр для достижения желаемого номера группы. Любые действия по увеличению или уменьшению масштаба будут запускать или завершать только спотовые экземпляры.