仮想化方式(HVM と PV)についてまとめ
EC2 における仮想化方式や kernel の扱いにはいくつか種類があって、 カスタマイズ (パフォーマンスチューニングなど) をする上で必要になることがあります。 C3 インスタンスや I2 インスタンスの登場で、それらがより重要になってきた感があるので一度まとめてみます。 * この記事は基本的に Linux についてまとめています
大前提
世に出ている仮想化基盤はいくつかありますが EC2 に使われているのは Xen です。 ただし ハードウェアサポートの追加、インスタンスタイプに応じた各 VM リソースの割り当て方、 ネットワークの扱いなど、 Xen そのものに相当なカスタマイズが行われていることは想像に難くないと思います。 (とか言って API から上だけで実現されていたらそれはそれで面白いですね)
仮想化方式
PV (paravirtual)
EC2 ではサービス開始当初から PV (paravirtual, 準仮想化) 環境でインスタンスの提供を行っています。 paravirtual での起動方法は2種類提供されています。
AKI, ARI を使う方式
EC2 側であらかじめ用意された kernel (AKI) と initrd (ARI) を利用して起動し、 最後にルートデバイスとしてユーザが選択したボリュームをマウントします。 つまり、ルートデバイスの /boot に kernel が含まれていようと、利用される kernel は AKI のものになります。 この方式で起動する場合、ユーザ側で作成するルートデバイスに kernel 本体や initrd が不要になります。 つまり /boot が無くても起動に問題無いはずです。
PV-GRUB を使う方式
UPK (User Provided Kernel) などとも呼ばれています。EC2 では後発で提供されるようになりました。 EC2 における PV-GRUB についてはこのへん、 Xen における PV-GRUB についてはこのへんにドキュメントがあります。 PV-GRUB 用 AKI を指定しておくと、ユーザが指定したルートデバイス内に含まれる kernel を使って起動できるというものです。 PV-GRUB は、ユーザが提供したルートデバイス内に存在する grub.conf を読みに行き、その内容を使って起動します。 grub.conf のパスは固定しておく必要がありますし、kernel を置いておく必要があるので、/boot が必要になってきますが、 ルートデバイスに grub がインストールされている必要はありません。
PV, PV-GRUB ともに、ルートデバイス内に適切にファイルが配置されてさえいれば起動します。 なので AMI をゼロから作る際に、適当な AMI で起動して EBS をアタッチし、 ファイルを流し込めば起動できるようになるんですね。
HVM
クラスタインスタンスがリリースされた際に HVM (Hardware-assited VM) という方式がサポート(というか必須)されました。 その頃だとあまり馴染みのなかった HVM AMI ですが、先日 C3, M3, I2 インスタンスがリリースされた時にこの方式がサポート(もしくは必須)されるようになっており、 一般の利用者にも関係のあるものになってきています。
HVM の場合、起動シーケンスは物理マシンに OS をインストールした場合と何ら変わりません。 ルートデバイスにあるブートローダから、デバイス内に含まれる kernel を起動していきます。 つまり、ブート領域 (GPT or MBR) とブートローダ (grub など) が必要になります。 そのため、既存の PV AMI を HVM 環境で使うためには、ファイルを流した EBS に対して grub をインストールしないといけません。 (ちなみに grub-install は Xen の仮想デバイスに対応していないので grub コマンドからインストールする必要があります) ゼロから作るのであれば、がんばって EBS マウントしたりするより手元の VMware とかでサクッと作ってディスクイメージにした上で dd したほうが早いかもしれません。 事故には気をつけたいですね。
HVM は完全仮想化などと言われているので特にモジュールなど必要なさそうに見えますが、実際はそうではありません。 試しに C3 インスタンスや I2 インスタンスで HVM AMI を起動してみると、Xen のモジュールが色々ロードされていることに気づくと思います。 これは PV on HVM driver と言われているもので、HVM 環境下ではオーバーヘッドが発生しやすい I/O などを PV の時と同様にホスト OS 側のサポートを受けつつ処理できるようにするドライバです。 ドキュメントにもありますが、このドライバは kernel 2.6.36 でマージされて 2.6.37 で改善が入っていますので、新しい kernel を使えるならそれ以上のバージョンを使うと良いです。 RHEL6 (CentOS6) の kernel は 2.6.32 ですが、2.6.36 のドライバがバックポートされているため問題なく利用できるようです。
ハードウェアサポートの利用
HVM AMI を使う必要のあるインスタンスでハードウェアサポートを提供しているものがあります。 代表的なのは C3, I2 インスタンスの SR-IOV による 10G NIC サポート (実帯域が 10G というわけではない) だと思います。 オリジナルの AMI を使う場合、こういったハードウェアサポートを有効にするドライバなどを忘れずロードできるようにしましょう。
使い分けや注意事項
各インスタンスがどの方式をサポートしているかのマトリクスはこちら。 古いインスタンスタイプは PV しかサポートしていないので選択の余地はないとして、 新しい C3, M3 インスタンスは PV と HVM の両方をサポートしています。 (I2 インスタンスは HVM 必須です) 個人的には、 PV と遜色無いパフォーマンスが出るのであれば HVM が使えるインスタンスではもう PV AMI 使う理由は無いかなーと思っているのですが、 きちんと計測が必要ですね。 問題になってくるのは同一の AMI を PV, HVM で使いたい時でしょうか。メンテナンスしなきゃいけない AMI が倍になるので。
EC2 のドキュメントでもインスタンスに利用されている CPU やハードウェアサポートが明記されるなど、 インスタンスが稼働している環境そのものを意識することが増えてきました。 今後はどうなっていくのでしょう。EC2 でも使えるハードウェアが色々増えていくと楽しそうですね。
