Ускорение создания AMI и ASG

Ответ 1

Используйте AMI с поддержкой EBS вместо AMI с поддержкой Instance Store. Из документов AWS:

           Amazon EBS-Backed             Amazon Instance Store-Backed
Boot time  Usually less than 1 minute    Usually less than 5 minutes

- http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ComponentsAMIs.html#storage-for-the-root-device

Ответ 2

Я задал аналогичный вопрос через билет поддержки AWS, здесь был ответ:

Основной процесс, требующий много времени при запуске нового экземпляра EC2 является процессом загрузки ОС в экземпляре: наличие более или менее групп безопасности/сетевых ACL, различного количества ключей SSH и роли, связанные с экземпляром, не должны оказывать время, необходимое для его запуска. Большую часть времени, которое требуется для запуск экземпляра потребляется самой ОС.

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

• Локальная файловая система монтирует: если вашему экземпляру необходимо подключить большое количество файловых систем, это добавит немного времени на загрузку обработать. В зависимости от типов файловой системы, которые вы используете, вам может потребоваться периодически проверять каждое фиксированное количество дней - например, на Linux вам может потребоваться запустить fsck в файловой системе ext4 каждые 90 дней (этот период может меняться в зависимости от ваших настроек) и ОС автоматически запускает эту проверку, когда файловая система монтируется если он обнаружит, что период был превышен. Одна стратегия для предотвращение этого может выполнять эти проверки перед созданием AMI, который вы будете использовать для запуска новых экземпляров, чтобы любые экземпляры, запущенный из этого AMI, будет недавно проверена их файловая система и вы не столкнетесь с неожиданными действиями fsck при запуске экземпляров в первый раз. В зависимости от типа файловой системы вы возможно, можно вообще отключить эти периодические проверки, но я бы не рекомендовал его, поскольку они необходимы для поддержания целостность файловой системы во времени.

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

• Обычные сценарии инициализации ОС: большая часть времени, затрачиваемого процессом загрузки, будет выполняться при запуске ОС Сервисы. В Linux существуют модели для двух типов: традиционный SystemV init (который запускает службы в последовательном порядке, один после другого) и относительно новая система (которая способна запускать службы параллельно и, таким образом, уменьшить время загрузки в некоторых обстоятельства). Какие из них вы будете использовать, будет зависеть от Linux распространение, которое вы запускаете в своих экземплярах. Например, если вам нужно запустите сервер БД, который может занять много времени при каждом загрузке Например, было бы целесообразно рассмотреть systemd, поскольку это позволит для остальной части несвязанных услуг, которые будут запущены параллельно, поскольку поскольку они не имеют этого сервера БД в качестве предварительного условия.

• Пользовательские данные и сценарии cloud-init: они выполняются после завершения обычных скриптов ОС. Как и в предыдущих статьях, вы может потребоваться проверить, что любой из этих пользовательских скриптов, которые вы выполняете, оптимизированы, чтобы они могли потребовать минимальное время; его рекомендуется тестировать любые пользовательские сценарии пользовательских данных по отдельности для измерьте свое время, прежде чем добавлять их в новый запуск экземпляра, чтобы вы могут лучше понять их влияние в общее время запуск экземпляра. Если ваши скрипты извлекают любые файлы, внешние по отношению к экземпляр (если вы загружаете что-то из ведра S3, запустите автоматическое обновление установленных пакетов и т.д.), то же самое соображения, которые я упомянул в элементе "Удаленная файловая система" упомянутые выше - убедитесь, что нет проблем с сетью, которые может замедлить или предотвратить это соединение, поскольку это добавит больше времени для всего процесса запуска вашего экземпляра.

• Тип экземпляра: тип экземпляра влияет на время, необходимое для завершения загрузки ОС. При тех же обстоятельствах, t2.large экземпляр загрузится быстрее, чем t2.nano, просто потому, что он имеет больше RAM, vCPU и большее количество кредитов ЦП - все это позволяет ОС для ускорения процесса загрузки. Кроме того, если вам нужно извлекать большие объемы данных как часть процесса запуска экземпляра, вы можете использовать расширенный сетевой режим и оптимизированный EBS чтобы обеспечить максимальную пропускную способность для вашего потребностей; см. ссылки в конце этого сообщения для получения дополнительной информации о это.

• Тип тома EBS: как и в случае с типом экземпляра, производительность ваших томов EBS также является фактором, который может повлиять на общее время времени запуска экземпляра. Если вашему экземпляру нужно читать большие количество данных во время процесса загрузки с тома sc1 (жесткий диск объём с низкой производительностью, разработанный для редкодоступных данных), процесс загрузки будет медленнее, чем если ваш экземпляр читает то же самое данные с объема PIOPS с гораздо более высокой производительностью - если ваше использование случай содержит сценарий, в котором вы затронуты этим, вы можете хотите протестировать разные типы томов, чтобы выбрать тот, который лучше соответствует вашим потребностям. Аналогично, тип вашего корневого тома экземпляра также повлияет на производительность загрузки, поскольку во всех случаях вы будете должны прочитать информацию от него. В большинстве случаев значение по умолчанию "Общее SSD". a.k.a. gp2 Объемы EBS достаточно хороши, например, root томов.

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

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

Я надеюсь, что эта информация была вам полезна. Пожалуйста, дайте мне знать, если у вас есть вопросы.

Спасибо,

Ссылки по теме: - Типы экземпляров EC2: https://aws.amazon.com/ec2/instance-types/- Типы томов EBS: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html- Оптимизированные экземпляры EBS: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimized.html- Рекомендации по производительности для томов EBS: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSPerformance.html- Улучшение сетевого режима в экземплярах Linux EC2: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html