2014年7月にEC2のインスタンスファミリーにt2系のインスタンスが追加されました。一つ前の世代のインスタンスであるt1系のインスタンスの価格よりも安く、スペックは上がっているお得なインスタンスです。

こうなるとt1系のインスタンスを使い続ける理由は無いので、t1.micro → t2.micro へインスタンスをアップデートしたくなります。ただこのt2系のインスタンスを使用するには以下の制約があります。

  • EC2-VPCのみサポート
    EC2-Classicのプラットフォームはサポートしてないので、EC2-Classicの環境ではVPCを作成してそのVPCでインスタンスを起動する必要があります。
  • サポートしている仮想化方式はHVMのみ
    t2系のインスタンスはHVM AMIからしか起動できません。仮想化方式がPVのAMIからインスタンスを起動することはできません。

EC2-VPCの制約はVPCを作成すればいいので特に問題にはなりませんが、仮想化方式の方がネックになります。t1.microで起動しているインスタンスがPVのAMIであれば、そのままではt2系のインスタンスへ変更することはできません。AWSからも現時点では公式にPV→HVMの変換機能やツールは提供されていません。

ということで、今回は pv2hvm というツールを使って移行してみました。pv2hvmは作業用のインスタンスに元のAMIのスナップショットと新規に作成した移行先のディスクボリュームをマウントし、データのコピー、grubのインストール等を行い、HVMなAMIの作成を一括で行ってくれるツールです。

要件と制約

pv2hvmを使用するにあたり以下の要件を満たす必要があります。

  • 必ずEC2インスタンスで動かすこと
  • AWS SDK for Rubyが必要
  • EC2の管理権限を持つインスタンスプロファイルを持ってること
  • 元のAMIは自分のものかスナップショットの作成が許可されたものであること
  • 元のAMIにgrubがインストールされていること
  • テストは最近のAmazon Linuxでしか行われていない
  • マーケットプレイスのAMIは変換できない

では早速マイグレーション!

1. grubのインストール

移行対象のインスタンスにgrubをインストールします。

2. AMIの作成

移行対象のインスタンスを停止し、AMIを作成します。作成したAMIのIDをメモしときます。

3. 変換処理

変換処理を行うインスタンスを新しく起動します。起動の際にEC2のPower User権限を持ったIAM Roleを適用しておきます。
インスタンスが起動したらAWS SDK for Rubyをインストールします。

pv2hvmをダウンロードして変換処理を実行。

※変換処理を行う際にpv2hvm内部でddコマンドが発行されますが、bsオプションが付加されてない状態で実行されるのでddの実行に結構時間がかかります。そのため↓のようにddコマンドを発行する際にbsオプションを渡すよう変更しました。

変換処理実行。

以上で変換処理は終了です。image Id に記載されている新しく作られたAMIのIDをAMIのリストから選択して、t2系のインスタンスを選択して起動すれば完了です。移行処理はほぼpv2hvmが行ってくれるので簡単です。

※ PVとHVMの違い
  • PV(準仮想化)
    EC2のサービス開始当初から提供されている仮想化方式で、PV-GRUBと呼ばれる専用のブートローダで起動されます。特別なハードウェアの拡張には対応していません。
  • HVM(ハードウェア仮想マシン)
    完全に仮想化されたハードウェアを備えており、起動は物理マシンのOSと変りなく、ルートデバイスにあるブートローダからデバイス内のカーネルを起動します。PVと違いホスト上のハードウェアへの高速なアクセスをするためのハードウェア拡張が利用可能で、c3系のインスタンスで利用可能なSR-IOVによるパフォーマンスの向上などのメリットが享受できます。

もともとはPVの方が、IO系のハードウェアエミュレートのオーバーヘッドを回避するドライバを活用することでHVMより性能が優れていたようですが、HVMでもそのPVドライバが利用できるようなり、またHVM自体の機能強化により最近では、PVと同等かそれ以上の性能が出せるようになったようです。