Вопрос или проблема
У меня есть экземпляр Linux t1.micro, на котором работает небольшой веб-сайт на Apache/PHP/Postgresql уже пару лет (в дальнейшем будем называть его “оригинальный экземпляр”). Работает как часы.
Я хотел перенести сайт на новый (дешевле) экземпляр t2.micro. Я не смог найти пошаговые инструкции по этому процессу, но обратил внимание на это и это.
Мой базовый подход заключался в следующем:
- Создать снимки двух томов (корневого и диска данных для данных postgresql), используемых оригинальным экземпляром
- Создать новое HVM AMI из только что созданных снимков корневого и данных (ELASTIC BLOCK STORE > Снимки > выбрать снимок корневого экземпляра > Действия > Создать образ), с
- Архитектура = x86_64, такая же, как у оригинального экземпляра
- Имена устройств корневого устройства и тома данных = такие же, как у оригинального экземпляра
- Тип виртуализации = Виртуализация с аппаратной поддержкой (HVM, для совместимости с новым форматом VM t2)
- ID ядра = “Использовать значение по умолчанию” (я пытался использовать тот же ID ядра, что и у оригинального экземпляра, но создание AMI не удалось, сказав, что нельзя использовать это для HVM AMI)
- Создать и запустить новый экземпляр с только что созданным AMI на шаге 2
Проблема: при запуске этого нового экземпляра он сразу же выключается с ошибкой Client.InstanceInitiatedShutdown. Как я могу это устранить?
Я наивен, думая, что могу использовать снимок корня, который работает в PVM-окружении, в HVM-окружении? Есть ли более простой способ миграции с t1 на t2?
Я надеюсь, что не придется заново строить свой сервер в t2 с нуля и вручную переносить данные (я не использовал никаких автоматизированных скриптов сборки).
Редактировать: В итоге я заново собрал экземпляр t2 с нуля 😛
Я переходил с HVM на PV и заметил ту же проблему. Выяснилось, что я (моя автоматизация) всё ещё прикреплял блочное хранилище к /dev/sda1, что мне нужно для моего HVM AMI, но его нужно было прикрепить к /dev/xvda.
Я также столкнулся с аналогичной проблемой при создании экземпляра EC2 через Terraform.
Ошибка: ожидание создания экземпляра EC2 (i-0ccdd81d5227c88xx): неожиданное состояние ‘shutting-down’, требуемое состояние ‘running’. последняя ошибка: Client.UserInitiatedShutdown: Пользователь инициировал завершение работы.
Для меня обновление типа экземпляра с t2.micro до t3.large решило эту проблему.
Ответ или решение
Проблема миграции из t1 в t2: Ошибка "Client.InstanceInitiatedShutdown" на новом экземпляре t2
Миграция серверов в Amazon Web Services (AWS) может представлять собой сложный процесс, особенно когда речь идет о переходе с одного типа экземпляров на другой, как в вашем случае с t1.micro на t2.micro. При возникновении ошибки Client.InstanceInitiatedShutdown на новом экземпляре t2 есть несколько аспектов, которые следует учесть.
1. Понимание проблемы
Ошибка Client.InstanceInitiatedShutdown возникает, когда экземпляр EC2 инициирует завершение своей работы. Это может случаться по нескольким причинам:
- Проблемы с совместимостью образов (AMI и виртуализация).
- Некорректные конфигурации загрузочного устройства и параметров интерфейсов.
- Логические ошибки в конфигурации операционной системы.
2. Возможные причины и решения
2.1. Совместимость образов
Вы правы в своем предположении, что создание образа (AMI) из экземпляра, работающего на паравиртуализированном (PV) окружении, для использования в аппаратно-ассистированном (HVM) окружении может вызвать проблемы. Попробуйте следующее:
- Убедитесь, что создаваемый образ является образом HVM. Это необходимо, так как экземпляры t2.micro работают только на HVM.
- Проверьте, что вы используете правильные драйверы и настройки для HVM, особенно в конфигурационном файле системы.
2.2. Устройство загрузки
Некорректная конфигурация устройств может приводить к тому, что операционная система не может корректно загрузиться и инициирует завершение работы. Проверьте следующее:
- Убедитесь, что блочные устройства правильно настроены. Для HVM вам нужно использовать
/dev/xvdaдля корневого устройства, а не/dev/sda1, как у вас было ранее. - Если вы восстанавливаете данные, убедитесь, что все необходимые устройства соединены и правильно монтируются в системе.
2.3. Проверка логов
Логи являются важным источником информации для диагностики. Для диагностики:
- Подключитесь к экземпляру с помощью консоли восстановления (если доступно).
- Изучите системные журналы (в частности,
/var/log/syslogили/var/log/messages) для получения ошибок, которые произошли при загрузке.
3. Альтернативные подходы к миграции
Если описанные выше шаги не помогли, рассмотрите рекомендованные ниже альтернативные методы:
-
Ручная миграция данных:
- Создайте новый экземпляр t2.micro с минимальной конфигурацией.
- Установите необходимые программные зависимости (Apache, PHP и PostgreSQL).
- Перенесите файлы и данные вручную с помощью SCP, RSYNC или другого инструмента.
-
Использование инструментов инфраструктуры как кода:
- Настройте новую среду на основе существующих конфигурационных файлов (например, используя Terraform или AWS CloudFormation) для автоматизации создания экземпляров.
-
Disk Image Creation:
- Если ваши данные и конфигурация критичны, вы можете использовать сторонние инструменты для создания образов дисков (например, Clonezilla или аналогичные), чтобы позже восстановить их на новом экземпляре.
Заключение
Миграция между типами экземпляров в AWS требует тщательного планирования и понимания функциональности и архитект