インストールと環境構築：実践！ Xenで実現するサーバ統合（1）（1/3 ページ）

有力な仮想化技術として注目を集めるようになった「Xen」。このXenを活用してサーバ統合を実践していく手順を具体的に紹介します。（編集部）

[中嶋一樹, 高橋浩和，住商情報システム株式会社/VA Linux Systems Japan株式会社]

　今回から数回にわたって、仮想化ソフトウェア「Xen」を用いたシステム構築についてご紹介します。

　ご存じの方も多いと思いますが、Xenは、オープンソースで提供されている仮想化ソフトウェアで、手軽に仮想マシンを実現する手法として注目されています。この連載ではその概要については割愛し、システム構築の現場で、実際にどのように仮想化システムを設計・構築・運用していくかという実践的な部分に焦点を当てて解説を進めていきたいと思います。

【関連記事】

http://www.atmarkit.co.jp/flinux/special/xen01/xen01.html
仮想化技術の大本命「Xen」を使ってみよう ? インストール & Debian環境構築編〜

http://www.atmarkit.co.jp/flinux/special/xen02/xen01.html
仮想化技術の大本命「Xen」を使ってみよう ? Xen対応カスタムカーネル構築編〜

　初めに、XenをインストールしてゲストOSを動かすまでの基本的な手順を紹介したいと思います。ゲストOSを稼働させ、Xenの基本的なセットアップ方法を把握したところで、次回以降、実際の仮想化システム構築のプロセスを、パフォーマンス検証結果などとともに紹介していきます。

　なお、今回は仮想化環境のプラットフォームとしてRed Hat Enterprise Linux 5（以下RHEL 5）を想定して話を進めていきます。CentOS 5でもほぼ同様の手順で動作が確認できると思いますので、手元にRHEL 5がない場合はCentOSにて検証していただければ幸いです。

Xenのセットアップ手順

　Xenには「Hypervisor」「Domain0」「DomainU」という3つのモジュールが存在します（図1）。仮想化システムを稼働させるためには、まずこれらをセットアップしていかなければなりません。

図1　Xenのアーキテクチャ

　なお本稿では、簡便化のために、以下、HypervisorとDomain0のことを「ホストOS」、DomainUのことを「ゲストOS」と呼ぶことにします。

■ホストOSのセットアップ

　ホストOSのセットアップにはいくつかの方法があります。

1. ディストリビューションに付属している仮想化コンポーネントを有効にする
2. XenSource社のダウンロードサイトよりXenのバイナリを入手してインストールするよりXenのバイナリを入手してインストールする
3. XenSource社のダウンロードサイトよりXenのソース（tarボール）を入手して独自ビルドするよりXenのソース（tarボール）を入手して独自ビルドする

　この中で、最も導入が容易で安定していると考えられるのは、1のディストリビューションに付属している仮想化コンポーネントを利用する方法です。

　幸いにもRHEL 5では、Xenを用いた仮想化のためのコンポーネントが提供されています。具体的には、OSインストール時に「構成の選択」で「仮想化」にチェックを入れてインストールを行うだけで、ホストOS側についてはセットアップを行うことができます。また、OSインストール時にセットアップを行わなくとも、下記のように「ソフトウェアの追加と削除」によって後からインストールを行うこともできます。

画面1　ソフトウェアの追加と削除

　OSインストール後は、以下のようにyumコマンドを用いて、システムを最新の状態にしておくことをお勧めします。

# yum update -y

　これで、仮想化システムを構築するための土台が整いました。次は、ゲストOSの作成です。

■ゲストOSの方式

　ゲストOSを作成するに当たり、まず、その仮想化のモードについて決めておかなければなりません。

　Xenが実現する仮想化には、「準仮想化」と「完全仮想化」の2種類のモードがあります（コラム参照）。

　Xenでは、特に準仮想化モードを採用した場合に性能面でアドバンテージがあります。準仮想化ではゲストOSのカーネルを改変し、ハードウェアエミュレーションのオーバーヘッドを軽減させています。完全仮想化ではカーネルを改変せずにそのまま利用するためハードウェアエミュレーションのオーバーヘッドが大きく、特にI/O要求ではかなりのCPU時間をエミュレーション処理に費やすことになります。

　今回は、この準仮想化に絞って話を進めていきます。

　ゲストOSについては、仮想化のモードに加えて、その実体データの保存形式を「パーティションベース」のものと「ファイルベース」のものから選択することができます。

　パーティションベースの方では、ホストOSで認識しているブロックデバイスのパーティションをそのままゲストOSに貸し出し、その上にゲストOSをインストールします。このパーティションにはローカルマシン上のハードディスクが利用できるほか、iSCSIまたはファイバチャネル接続のSANも利用可能です。

　一方、ファイルベースの方はパーティションは必要とせず、ファイルを作成してその上にゲストOSをインストールします。ファイルは、ホストOSからアクセスできるところにさえあれば、ローカルマシン上のハードディスクにあってもリモートのNFSサーバ上にあっても構いません。

　一般的に、パーティションベースのゲストOSはディスクI/O性能がファイルベースのもの比べて優れているといわれています。一方ファイルベースのゲストOSは、ファイルとしてOSを取り扱えるという感覚から、移動やバックアップなどが容易であるといわれています。さらにファイルベースの場合、「Sparseファイル」という形式を用いることで、実際に消費するディスク容量を大幅に削減することが可能です。

　このあたりのパフォーマンスや利便性の実際については、後の連載の中で詳しく検証を行いたいと思います。

コラム●準仮想化と完全仮想化

　準仮想化ではゲストOSのカーネルを改変し、ハードウェアエミュレーションのオーバーヘッドを軽減させています。具体的には「ハイパーバイザーコール」という手続きを追加し、ハードウェアを操作する場合にはこのハイパーバイザーコールを発行することでXen Hypervisorに直接にハードウェア操作要求を依頼することができるという仕組みです。

　ハイパーバイザーコールがCPU特権操作、または割り込みコントローラ操作に関するものであった場合は、Xen Hyperviosrは自身でハードウェア操作を行います。また、ハイパーバイザーコールがI/O要求に関するものであった場合は、Xen Hypervisorはその処理をホストOSに依頼するという形をとります。

図2a　準仮想化でのI/O以外のハードウェア操作要求

図2b　準仮想化でのI/O操作要求

図2c　完全仮想化でのI/O以外のハードウェア操作要求

図2d　完全仮想化でのI/O操作要求（いずれもクリックで拡大します）

　一方完全仮想化のゲストOSはハードウェアのサポート（VT）を利用してそのままのカーネルを使用します。この場合は、ゲストOSからのハードウェア操作要求は直接Xen Hypervisorに対しては発行されず、CPUがその操作要求を捕捉した時点でXen Hyperviosrに制御が戻さます。

　ハードウェア操作要求がCPU特権操作、または割り込みコントローラ操作に関するものであった場合は、Xen Hyperviosrは自身でハードウェア操作を行います。ハードウェア操作要求がI/O操作要求に関するものであった場合はXen Hypervisorはその処理をホストOSのQEMUに転送します。QEMUはI/O操作要求を分析し、適切な形に変換してホストOSに処理を依頼します（この部分のオーバーヘッドが大きい）。

　現在の商用の仮想化製品では、完全仮想化のゲストOSであってもI/Oドライバは準仮想化のものを用いるといった手法を採用しています。今後は、ハードウェアのサポートによって高速に動作させれる部分は完全仮想化、それ以外のところは準仮想化といったハイブリッド型のゲストOSが主流になると考えられます。