Назад | Перейти на главную страницу

Правильный процесс запуска нового экземпляра EC2 из моментального снимка EBS

У меня есть экземпляр EC2, на котором запущен 32-битный AMI Ubuntu 12.04 (доступен на первой странице мастера Classic для запуска нового экземпляра). Корневое устройство - это том EBS. Затем я выполняю следующие шаги:

На 3-м шаге мастера я заметил эту строку для «Конфигурация запоминающего устройства».

Root    /dev/sda1   snap-xxxxxx 8GiB    standard    true

Мне кажется, это указывает на то, что он использует моментальный снимок в качестве корневого тома для нового экземпляра (фактически, это единственный том).

Затем я запускаю экземпляр. Однако он не проходит «проверки состояния» на этапе «инициализации». Если я щелкну правой кнопкой мыши по экземпляру и выберу «Получить системный журнал», это будет конец журнала:

Using IPI No-Shortcut mode
XENBUS: Timeout connecting to devices!
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.

EXT3-fs: sda1: couldn't mount because of unsupported optional features (240).
EXT2-fs: sda1: couldn't mount because of unsupported optional features (244).
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)

Что я здесь делаю не так? Меня беспокоит два раза:

Полученные вами ошибки предполагают, что ваша файловая система более новая, чем та, которая поддерживается ядром (скорее всего, ext4 в ядре, которое поддерживает только ext2 / 3). Некоторые AMI зависят от нестандартного AKI (Amazon Kernel Image) для обеспечения определенных функций.

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

Кроме того, лучший дизайн AMI будет использовать PV-GRUB в качестве загрузчика для загрузки ядра из самого AMI (вместо того, чтобы требовать определенного внешнего AKI), что упрощает процесс поддержания ядра в актуальном состоянии. В Документация AWS о предоставляемых пользователем ядрах стоит прочитать, если вы хотите реализовать это в своем AMI.

Поскольку вы специально упомянули Ubuntu, этот инструмент может быть вам полезен:

У меня произошло то же самое, и выбор правильного AKI для версии и архитектуры ОС с помощью инструмента выше работал как шарм.

Я столкнулся с аналогичной проблемой, и оказалось, что значения по умолчанию AWS EC2 отличаются для запуска экземпляра и создания AMI: в первом случае по умолчанию используется аппаратная виртуализация (HVM), но для создания образов по умолчанию используется паравиртуальная (PV).

Я наткнулся на это, когда попытался переместить экземпляр EC2 между зонами доступности, сделав снимок его тома EBS и создав новый AMI, и это несоответствие в настройках (на которое я тоже не обратил внимания) потратило для меня час.

Итак, tl; dr: просто выберите HVM при запуске из настроенного AMI, и ваш экземпляр должен нормально загрузиться.