自己紹介用のサイトをオレゴンに作ってしまった
大学で研究していた頃にいろいろな作品を製作していたのでそのポートフォリオサイトを作っておこうと思ったのですが、AWS の使い方をよく調べずにうっかり米国西部（オレゴン）リージョンにインスタンスを立ててしまいました。
メニューは一緒でもまずリージョンを切り替えてから操作をしなければならないことに気づいたのは一通り起動し終わった後でした ＼(^o^)／
ちなみにオレゴンの場所はここだそうです。
流石に太平洋の距離は馬鹿にできなかったようで、日本からサイトを表示しようとすると画像の読み込みは目に見えて遅いですし、コンソールで操作しようとするとコマンド打って帰ってくるまでに明らかな遅延を感じていました。
英語コンテンツだから良い気もしていたのですが、日本からのアクセスの方が多いこともありましたので今回東京リージョンに移行することにしました。
移行対象となったサイトはこちらです。
beniyama.com
ほとんど静的＆コンテンツの重要性も低いので冗長構成もとらず Web/DB/PHP (Wordpress) が１インスタンス (t2.micro) に収まっています。
リージョンをまたいだインスタンスの移行を試みる
インスタンス移行について調べてみると存外簡単にできそうな感じでした。
特に参考にさせていただいたのはこちらのサイト。
http://shakezoomer.com/?p=317shakezoomer.com
大まかな流れはこんな感じ。
- オレゴンでスナップショットをとる
- オレゴンから東京へスナップショットをコピー
- 東京でスナップショットからイメージを作成
- 東京でイメージからインスタンスを作成
とくにカーネル ID が大事！と書かれていたので移行元のインスタンス情報に目を凝らして見ますが
ない！わからない！
疑問に思いつつもとりあえずデフォルトカーネルのまま立ち上げてみますが、上記サイト中でも言及されているカーネルパニックを起こして死んでしまいます。
ec2 Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block
この後 Amazon EC2 CLI Tools をセットアップして カーネル ID を調べよう と試みましたが
$ ec2-describe-instance-attribute INSTANCE_ID --region us-west-2 --kernel
kernel INSTANCE_ID
とかなってやっぱりカーネル ID がわかりませんでした。そもそも CLI でわかるものはコンパネからもわかる様子。
そもそも仮想化タイプが違っていた
詰まってしまったので再度調べまわっていると同じように困っている人に遭遇。
stackoverflow.com
上記のようにカーネル ID を調査する方法を薦めていた人のコメントに追記があり、
edit: Just noticed this is an HVM; Not sure why you would want to make an image from a snapshot. If you create an image directly from the ec2 it will also create snapshots for you and then you can go to AMIs and make a new ec2 from the image you created and it will not ask for a kernel ID.
そもそも仮想化のタイプが HVM の場合はカーネル ID は関係なさそうな様子のことを言っています。もっと言うとスナップショット経由の必要はないとも。
そこで先ほどのインスタンス情報を確認してみると確かに HVM となっています。
そして参考にさせていただいたサイトをよく読むと
SnapshotからAMIをつくって、ということをせずに、AMIをそのままコピーしてやればもっとすんなりいけました。
という追記を発見。
確かに手順を振り返ってみると、スナップショットからイメージを作成する際にカーネル ID に加えて仮想化タイプを指定する項目があります。
ここで「準仮想化」ではなく「ハードウェアアシストの仮想化」を選んでカーネルはデフォルトのままで立ち上げたところ、少し時間はかかりましたが無事インスタンスを作成することができました。
スナップショットからイメージを作るべきではない
改めて手順を振り返ってみると、上述のコメントや追記にもあったように
- オレゴンでイメージを作成
- オレゴンから東京へイメージをコピー
- 東京でイメージからインスタンスを作成
とした方が上述の仮想化タイプの選択とか気にしなくて良いので確実です（イメージ作成時に自動的にスナップショットも作成されます）。
下記の「Amazon Machine Image (AMI) とスナップショットの違い」にもスナップショットからイメージ (AMI) を作成した場合、
アーキテクチャやカーネルの選択を誤ると正しく起動してこなかったり、動作が不安定な AMI が出来る可能性がある
とあります。
aws.typepad.com
仮想化タイプを問わず、インスタンス移行はイメージのコピーで実施した方が良さそうです。
HVM とはなんだったのか
余談になりますが準仮想化 (para-virtual VM) とハードウェアアシストの仮想化 (hardware-assisted VM) についてはこちらに詳しく書かれています。
docs.aws.amazon.com
HVM AMI は、完全に仮想化された一連のハードウェアを備えており、イメージのルートブロックデバイスのマスターブートレコードを実行することによって起動します。
PV AMI は、PV-GRUB と呼ばれる特別なブートローダーを使用して起動します。
HVM でカーネル ID が必要なかった理由は PV-GRUB というブートローダの仕組みに関係がありそうです。
Enabling User Provided Kernels in Amazon EC2 の「PVGRUB: A New Amazon Kernel Image (AKI) 」によれば、
To enable user provided kernels, Amazon has published AKIs that use a system called PVGRUB. PVGRUB is a para‐virtual
“mini‐OS” that runs a version of GNU GRUB, the standard Linux boot loader. PVGRUB selects the kernel to boot by
reading /boot/grub/menu.lst from your image. It will load the kernel specified by your image and then shut down the
“mini‐OS”, so that it no longer consumes any resources. One of the advantages of this solution is that PVGRUB
understands standard grub.conf or menu.lst commands, allowing it to work with most existing Linux distributions.
とあり、 AKI に PV-GRUB 対応のものを指定することでそこから grub.conf / menu.list を読んでユーザが指定したカーネルを読ませることができるようになる、とあります。AWS 初期ではそもそもユーザがカーネルを改変することができなかった（AKI として別に管理されていた）という背景があるようです。
HVM はそもそも AKI を使わない = PV-GRUB AKI のカーネル ID が要らない という理解で良いのかなと思います。
docs.aws.amazon.com
Cluster AMI は PV-GRUB をサポートせず、また、必要としません。完全ハードウェア仮想化（HVM）が使用されるためです。準仮想インスタンスは PV-GRUB を使用して起動します。一方、HVM インスタンスボリュームは実際のディスクのように扱われ、その起動プロセスはパーティション分割ディスクとブートローダーを備えるベアメタルオペレーティングシステムの起動プロセスに似ています。
と書かれているように、物理マシンの直上に Linux をインストールしたときのようにイメージ内のブートローダから直接上がってくるとのことです。
詳しくは下記のサイトが参考になります。
kanny.hateblo.jp
まとめ
- インスタンス移行はスナップショットから起こさずイメージで。
- 仮想化タイプを確認する。HVM の場合はカーネル ID を気にしなくて良い。
- システムログが真っ黒なときはまだ起動中。しばらく SSH できなくても辛抱強く待つ。
と書いていて、準仮想化のイメージをリージョンをまたいで移した際に、PV-GRUB AKI のカーネル ID の変換は誰がやってくれるのか疑問に思いました（同じカーネルでもリージョン間で ID は変わるため）。
