Примечание: Я задавал этот вопрос и на форумах EC2, но не получил там никакой любви. Надеюсь, сообщество ServerFault станет еще круче.
Открытие нового региона AWS в Сиднее - это то, чего мы ждали долгое время, но у меня много проблем с переносом наших экземпляров из Северной Калифорнии.
Мне удалось перенести 1 экземпляр на использование CloudyScripts чтобы переместить снимок, а затем запустить новый экземпляр в районе Сиднея. Это был очень новый экземпляр, поэтому и источник, и место назначения работали на сервере Ubuntu 12.04 LTS, и у меня не было проблем.
Однако все остальные наши экземпляры - это Ubuntu 10.04 LTS, и с ними у меня много проблем.
Я пробовал следующее:
1- после Технический документ AWS на движущихся экземплярах, который был передан нам на недавнем Дне благодарности клиентов в Сиднее, где был запущен новый регион.
Проблема с этим подходом заключалась в последнем шаге (шаг 19), здесь вы регистрируете образ: ec2-register -s snap-0f62ec3f -n "Wombat" -d "migrated Wombat" --region ap-southeast-2 -a x86_64 --kernel aki-937e2ed6 --block-device-mapping "/ dev / sdk = ephemeral0"
Я продолжаю получать эту ошибку: Client.InvalidAMIID.NotFound: AMI ID 'ami-937e2ed6' не существует, что, как я думаю, связано с тем, что kernel_id не существует в регионе Сиднея?
2- Использование CloudyScripts для перемещения снимка, а затем создание нового тома и подключение к новому экземпляру в Сиднее.
Это приводит к тому, что экземпляр просто зависает при загрузке и не проходит проверку статуса. Я не могу войти по SSH или посмотреть журнал сервера
Я подозреваю, что моя проблема связана с поиском правильного kernel_id для тома в новом регионе. Однако я не могу понять, как найти этот kernel_id, те, которые я пробовал (из исходного экземпляра), не приводят к ошибке Client.InvalidAMIID.NotFound: AMI ID 'ami-937e2ed6' и любой другой идентификатор ядра просто не загружается.
Я пробовал версии Ubuntu 12.04 и 10.04. Кажется, ничего не работает, я уже давно бился головой о стену, пожалуйста, помогите!
Новый (битый) экземпляр i-a1acda9b ami-9b8611a1 aki-31990e0b
Исходный экземпляр i-08a6664e ami-b37e2ef6 aki-937e2ed6
p.s. Я также пробовал следовать этому руководству по обновлению моей версии Ubuntu LTS до 12.04 перед выполнением миграции, но, похоже, это тоже не сработало, все еще застревая при обновлении kernel_id http://ubuntu-smoser.blogspot.com.au/2010/04/upgrading-ebs-instance.html
Когда вы указываете несуществующий идентификатор ядра, ec2-register неправильно сообщает об ошибке «Client.InvalidAMIID.NotFound». Это ошибка в инструментах AWS.
Чтобы определить правильный идентификатор ядра, запустите новый экземпляр из AMI в целевой области, который максимально соответствует исходному AMI. В вашем примере запустите экземпляр на основе Ubuntu 10.04 LTS AMI. После запуска этого экземпляра вы можете увидеть, какой идентификатор ядра и идентификатор Ramdisk (если есть) использовались для этого экземпляра. Затем вы можете использовать тот же идентификатор ядра и идентификатор Randisk (если есть).
Да, это одна из неприятных особенностей AWS: AMI нельзя переносить из региона в регион. К сожалению, это несовместимые инфраструктуры.
Однако по крайней мере одна компания превратила миграцию инстансов EC2 в услугу. Ylastic предлагает «миграцию в один клик для EBS linux AMI и снимков между регионами». Я использовал эту службу в течение короткого периода в прошлом месяце, когда помог другу перенести экземпляр с us-east-1 на us-west-2. Переносить вручную стало настолько сложно, что я решил попробовать сервис, и он сработал.
Ylastic автоматически загружает экземпляры от вашего имени для выполнения работы, которая может занять некоторое время. Они в основном dd ваши данные передаются во временный экземпляр в новом регионе и создают новый снимок, который вы можете использовать для запуска экземпляров в этом регионе. Затем он очищается после себя, прекращая ресурсы, используемые для передачи.
Однако со стратегической точки зрения лучше всего иметь возможность автоматизировать процесс создания любой конфигурации экземпляра, которая вам нужна в любом регионе. Мы делаем это с помощью кулинарных книг Chef, поэтому мы можем иметь совместимые AMI, готовые к использованию в любом регионе для наших приложений. Единственная проблема - отслеживать, какие AMI и ядра использовать в каких регионах. Но если у вас есть набор рецептов, который работает везде, вам больше не нужно беспокоиться о переносе экземпляров.