Единственный экземпляр Amazon EC2

Question

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

У нас есть отдельный сервер, не принадлежащий Amazon, который мы хотели бы использовать для мониторинга EC2, запуска нового экземпляра, если необходимо, и закрытия старого. Все наши пользовательские данные хранятся в Elastic Storage, поэтому мы не слишком беспокоимся о том, чтобы что-то потерять.

Мне было интересно, есть ли у кого-нибудь опыт использования EC2 таким образом и, в частности, автоматизации процесса запуска нового экземпляра? У нас нет проблем с созданием чего-либо с нуля, но кажется, что это должна быть решенная проблема, поэтому мне было интересно, есть ли у кого-нибудь какие-либо советы, ссылки, сценарии, учебные пособия и т. Д., Которыми можно поделиться.

Спасибо.

Answer 1

Вы должны взглянуть на puppet и его поддержку AWS . Я бы также посмотрел на библиотеку RightScale AWS , а также на этот пост о запуске сервера со скриптами RightScale . Вы также можете найти эту статью о веб-обслуживании с EC2 полезной. Я сделал что-то похожее на это, но без внешнего мониторинга узел контролировал себя и отключался, когда он больше не был нужен, после чего запускался новый, когда было больше работы.

Answer 2

Пара баллов:

Вы ДОЛЖНЫ ДОЛЖНЫ ДОЛЖНЫ создать резервную копию тома Amazon EBS.

Они заявляют о «лучшей» надежности, но не о 100%, и это НЕСКОЛЬКО порядков от долговечности S3 «12 9». Долговечность S3 >> Долговечность EBS. Это факт. EBS поддерживает функцию «моментальных снимков», которая позволяет эффективно и постепенно выполнять резервное копирование на S3. Кроме того, со снимками EBS вы платите только за сжатые дельты, которые обычно намного меньше, чем размер выделенного тома. В другой жизни я отправлял электронные письма о потерянных объемах таким маленьким клиентам, как вы, которые «думали», что EBS «долговечен», и доверяли ему единственную копию критически важной базы данных ... это душераздирающе.

Ваш вопрос: автоматизация запуска нового экземпляра

Упомянутый вами путь проектирования относительно не прослеживается; вот почему ... Многие компании используют избыточные «горячие» экземпляры, где второй экземпляр загружается и работает. Это позволяет осуществлять быстрое аварийное переключение (в секундах) в случае «сбоя» (может быть аппаратным или программным). Проблема с «холодным запасом» состоит в том, что сложнее поддерживать машину в актуальном состоянии и быть готовой забрать там, где остановилась старая коробка. Что еще более важно, СЛЕДУЕТ проверять, что запасные части способны успешно восстановить вашу производственную службу. Аппаратное обеспечение более надежно, чем непроверенные программные системы. ТЕСТ ТЕСТ ТЕСТ. Если вы не проверили свое переключение при сбое, оно не работает.

Простая автоматизация запуска нового экземпляра EBS проста, граничит с тривиальным. Это всего лишь однострочный bash-скрипт, вызывающий инструменты командной строки EC2 . Хитрость в том, что все это сверху. Такое решение в значительной степени предполагает полностью автоматизированный процесс развертывания. И это все специфично для вашего приложения. Может ли ваше приложение получить все данные, необходимые для запуска (может быть, оно хранится в S3?). Можете ли вы убить свой экземпляр сегодня и загрузить новый экземпляр с 0,000 шагов ручной настройки / установки?

Или, возможно, вы говорите о сценарии, который я назову «повторное создание тома EBS» :

1. Умирает коробка EC2 (корневой том EBS)
2. Принудительное отключение EBS громкости
3. Загрузка нового экземпляра EC2 с томом EBS

... То, что в основном работает. Полученные ошибки:

• Не защищает от сбоев EBS, как полной потери тома, так и потери доступности
• Время восстановления равно O (минутам), при условии, что все работает правильно
• Ваши службы должны быть настроены для автоматического перезапуска. Не стоит возвращать коробку, если Nginx не работает.
• Ваши DNS-маршруты или другие сервисы или что-то еще должно быть в порядке с изменением IP-адреса. Это можно обойти с помощью ElasticIP.
• Как обрабатываются SSH-ключи вашего хоста? То же имя, новый ключ хоста может нарушить автоматизацию на основе SSH, когда он получает строгое предупреждение об изменении ключа хоста.
• У меня нет доказательств этого (кроме случая, чтобы это произошло один раз), но я считаю, что EC2 / EBS _already_does_this_ автоматически для экземпляров загрузки из EBS

Опять же, самая сложная часть на вашей тарелке. Можете ли вы остановить свою производственную службу сегодня и НАДЕЖНО запустить ее на новом экземпляре? Если так, то часть истории EC2 действительно очень проста .

Answer 3

В качестве побочной точки:

Все наши пользовательские данные хранятся в Elastic Storage, поэтому мы не слишком беспокоимся о том, чтобы что-либо потерять.

Я бы настоятельно рекомендовал регулярно снимать ваш EBS (Elastic Block Storage) на S3, если вы этого еще не сделали.

Answer 4

1. Если вы не отметили «Защита от случайного завершения», возможно, вы захотите сделать это.
2. Даже если вы отключили «Детальный мониторинг» для своего экземпляра, вы все равно должны увидеть метрику «StatusCheckFailed» для своего экземпляра, с помощью которой вы можете настроить тревогу (на информационной панели CloudWatch)
3. Ваше приложение (размещенное на другом сервере) должно получить сигнал тревоги и запустить экземпляр, используя AWS API (или CLI)

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

Answer 5

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