Ускорение запуска экземпляров Amazon EC2 для Windows


16

Я работаю над веб-сервисом, который размещен на EC2 и должен иметь разное количество запущенных экземпляров, в зависимости от нагрузки. У нас есть базовая служба, которая запущена и работает, но одной из вещей, с которой мы боремся, является время, необходимое для подготовки и запуска экземпляра Windows (мы используем некоторые третьи prty инструменты, которые работают только в Windows). Я видел, что это заняло где-то от 10 минут до довольно потрясающих 45 минут.

У кого-нибудь есть советы, как ускорить запуск экземпляра EC2? Так как AMI для серверов Windows являются большими по сравнению с Linux AMI, например, мне интересно, может ли быть одна вещь, чтобы убедиться, что корзина S3, содержащая AMI, находится в той же зоне, где запускается экземпляр, что предположительно сделать подготовку нового экземпляра быстрее.

Ответы:


8

Прошлой ночью я установил 3 экземпляра ванильного сервера Windows 2003. Первые два заняли приблизительно 45 минут, третье, приблизительно час спустя, заняло целых 2 часа, прежде чем это было готово!

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

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

После того, как вы определили максимальное время подготовки, опередите загрузку / использование на столько минут.


Спасибо за предложения - 2 часа довольно экстремально. С тех пор, как я задал этот вопрос, я заметил, что EC2 иногда перезагружает экземпляры Windows сразу после запуска. Я не знаю, почему это так (я не выяснил, почему некоторые экземпляры перезагружаются, а другие нет), но это может добавить еще 5 или 10 минут ко времени запуска.
gareth_bowles

2
@gareth - это потому, что машина имеет то же имя, что и другое в сети (т. е. это изображение). EC2ConfigService обнаруживает это, назначает новое имя и перезагружает его. Вы можете отключить это с помощью установленной утилиты конфигурации ec2config.
Кирен Джонстон

20

Экземпляры Amazon windows перезагружаются при запуске, поскольку конфигурация службы Windows «Конфигурация EC2» по умолчанию заключается в переименовании вашего хоста во внутреннее DNS-имя экземпляра. Переименование хостов требует перезагрузки на Windows. Если вам не нужно использовать внутреннее DNS-имя вашего экземпляра, вы можете отключить функцию SetComputerName. Преимущество экземпляров Windows также состоит в том, что им не нужно инициализировать загрузочные диски, на которых вы, возможно, уже связали свою конфигурацию, что экономит еще некоторое время при запуске экземпляра. Все это возможно через службу конфигурации Windows EC2.

Служба конфигурации Windows: http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/appendix-windows-config.html

Маленькие экземпляры Windows обычно загружаются за 15-18 минут (большие быстрее). В зависимости от ваших требований, вы можете объединить все свое программное обеспечение в AMI и иметь возможность загружать и запускать все в течение этого периода. Я понимаю оговорки, чтобы не связывать все в AMI, но, возможно, стоило бы улучшить время запуска, чтобы иметь производственные AMI со всем, что было в них включено. Храните сценарии сборки отдельно, если хотите, в своих средах сборки.

Кроме того, теперь, когда Amazon выпустила корневые тома EBS, а не корневые тома хранилища экземпляров. Небольшие образы Windows, работающие на томе EBS, загружаются почти за 5 минут против почти 20 минут, которые требовались ранее. Кроме того, вам не нужно завершать работу - вы можете останавливать / запускать их - в зависимости от ваших настроек это потенциально экономит несколько минут в некоторых сценариях запуска.

По сути, настройка службы Windows EC2 Config, AMI и, возможно, использование загрузочного тома EBS должны сократить время запуска почти до 5 минут. Вы можете избежать sysprep, который запускается при запуске экземпляра ec2 в зависимости от вашего приложения, особенно в целях разработки. Образ m1.large без sysprepped, который позволяет избежать изменения имени хоста при запуске, может запуститься примерно через 2 минуты, что совсем неплохо.

На данный момент, насколько я понимаю, это лучшее, что вы можете сделать с Windows на Amazon EC2, но на самом деле это не так уж плохо. Если вы сможете прогнозировать на будущее около 10 минут на основе средних моделей использования, вы должны иметь возможность раскрутить дополнительные экземпляры и справиться с дополнительной нагрузкой.


Переименование внутреннего хоста - отличный совет - спасибо! Я также хочу попробовать корневые тома EBS, не в последнюю очередь потому, что это значительно упростит резервное копирование. Я предполагаю, что мне придется прогнозировать среднее время запуска 10 минут; это не такая проблема сама по себе, но высокая изменчивость времени запуска все еще является настоящей болью.
gareth_bowles

На это следует ссылаться в документах AWS.
Питер Маунс

4

Иметь минимальную систему, хранить как можно больше в EBS может помочь? Или, возможно, использовать подход в стиле Apache и запустить один или два в резерве?


4

Мы столкнулись с этой проблемой, но очень серьезно - наш новый стартап расширяет Amazon EC2 в среду виртуальной лаборатории (многопользовательский, политики, совместное использование и т. Д.), Поэтому нам нужно было ускорить время запуска Windows машины. Нашим главным решением было поддерживать только тома на основе EBS в нашем приложении, потому что они единственные, которые могут запускаться через 5-10 минут. В нашем тестировании мы обнаружили, что время запуска магазина экземпляров сильно различается и иногда занимает слишком много времени, что делает их бесполезными для нас.

Simon @ LabSlice Управление виртуальной лабораторией в EC2

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.