技術情報

技術情報

Xen特集 イアン・プラット インタビュー

2007年11月30日

技術文書トップへ

2007年7月20日、 VA Linux主催の「Xen Conference Japan 2007」が開催された。同コンファレンスは、「Xen Project」のリーダーであるイアン・プラット氏の他、「Xen」に精通したパネラー陣により「Xen」の技術と可能性、そして「仮想化」の現状と今後を再認識する場となった。同コンファレンスの基調講演の為に初来日したイアン・プラット氏に、VA LinuxにおいてXenの開発に携わる山幡とサイモンが話を伺った。

サイモン

「Xen Conference Japan 2007」で講演いただきましたが、ユーザーは「仮想化」に関してどのような期待を抱いていると思われますか?

イアン

考え方としては、ハードウェアが新しくなっていく中で、様々なコンポーネントのアップデートサイクルが維持出来るかどうかという事です。ユーザーの抱える典型的な問題の1つとして、ユーザーは自社で使用しているOS上で稼働するアプリケーションの検証に多くの時間と労力を費やす訳ですが、それでも、そのOSが新たに購入したりアップデートされていく全てのハードウェア上で動作が保障されるものではないという点が挙げられます。Linuxの導入にとても積極的な米国の謀大手銀行では、Linuxの最新バージョンを稼働させているのかというと、実際には殆どのアプリケーション・ソフトウェアはRed Hat Enterprise Linux(以下RHEL)3で動いており、場合によってはRHEL2で動いているものも存在します。しかし、殆どの新しいアプリケーションはRHEL4かRHEL5での稼働が前提となっています。OSのバージョンを変更しアプリケーションが使えなくなるというのは大問題ですので、多大な費用と労力を消費して「これでもか」というくらいの十分な検証を行う必要があります。更に、ハードウェアのサポート期限の点からも、最終的にはバージョンの変更をせざるを得なくなります。これらの問題を解決する手段として「仮想化」の導入を検討する事になります。先述の某大手銀行の場合は、プラットフォームの一部を仮想化する事によって、RHEL2やRHEL3が使える環境を維持出来るのです。

サイモン

ユーザー側のハードウェアやソフトウェアのサイクルはかなり遅く、メーカー側のそれとは大きな隔たりがあると感じます。

イアン

そうですね。そしてアプリケーション・ソフトウェアの検証・修正費用は莫大となるし、何よりも、現在は安定して稼働している訳ですので、余計な問題は持ち込みたくないというのが本音でしょう。そこで、問題を解決する為に「仮想化」の環境を構築するのです。

サイモン

「仮想化」はアプリケーション・ソフトウェアの継承問題を解決に導く大きな役割を果たしているという事ですね。さて、講演の中では将来のセキュリティについても少し話されましたが、この点をもう少し伺えますか?

イアン

私は他のハードウェアのサポートの為のアップデートや新しい機能の公開を考えていました。考え方は、ハードウェアにマッチしたものを出荷するという事です。そしてそれを正しく行う為にサイクル時間等も合わせる事が必要と考えています。
そこで問題となるのはハイパーバイザーのセキュリティアップデートの件です。最初の設計段階からセキュリティが正しく設計されている事を確認する事が重要です。ハイパーバイザーに関しては明らかにアップデート機能のニーズがあるのです。

山幡

講演の中でブロックディスクは極めて良い状態にあると話されていましたが、私はパフォーマンスとスケーラビリティーが十分でないと思っています。つまりI/Oリングが非常に小さく待ちが発生してしまいます。

イアン

確かにI/Oリングはサイズ変更が可能なように設計されていますので、単純に1ページあるよりはパッチが良いと思います、リストのページをパスし、パラメータはリングのサイズ内なので実際には更にページを追加してアップデート出来ます。更に、下位互換性を持っているので可変サイズリングをサポートが可能で、フロントエンドがページリストをバックエンドに提供し、ともに機能するのです。
パフォーマンスの問題があるのはコマンドです。実際にカーネルOSは設定可能、あるいは複数設定が可能で、殆ど誰も知らない事はブロックバックにパラメータがあり、いつでもゲストからのブロックバックのページ数がわかる仕組みなのですが、この値が高いパフォーマンスのI/Oサブシステムにはあまりに小さすぎて、すぐに限界点に達してしまうでしょう。
我々は「Xen」の機能の比較を行っているQ社と最新のデュアル・ポート4GB/秒ハイパーチャネルインターフェースを、例えば72ディスク配列に接続して、非常に高性能なシステムとしたものを使って検証しました。ディスク数による比較では、LinuxはI/Oパフォーマンスがもともと優れていて、値は上昇し、4GB/秒の限度に達したところでフラットになりました。その後、「Xen」のパフォーマンスが示されたのですが、値は少し上昇したところですぐフラットになってしまいました。Q社はこの結果に対してPCI/O、スマートHBA等が必要だと提案してきましたが、私はコマンドラインパラメータを変更して再び実験を行う事を提案し、Linuxのグラフと同様にの結果を残すことに成功しました。ですから、PCI IOVを使って多くの複雑な作業を導入し、その結果、全ゲストのHBAの為に限定されたドライバを準備しなくてはならなくなる前に、出来る事は全てやってみなければなりません。つまり、最初に最適化してみる、それからテープローダーやその他のデバイスの利用を考えてみる事です。しかし私はI/Oデバイスを直接ゲストに割り当てたり、マップしたりする必要を感じていません。少なくともそれがパフォーマンスに影響を与えるという証拠はまだありません。最適化に関しては何か考えがありますか?

山幡

実際には政府はプロジェクトを検討しており、それはI/Oパフォーマンスの、特に拡張性に関して重要なものです。
それよりも重要な問題はパフォーマンス分離で、例えば2つのドメイン問題ですね。同じディスクを複数ドメインが使用した場合のパフォーマンスは非常に悪いです。

イアン

ディスクが作動すると、即座に後方や前方に行ったり来たりします。その場合、バックエンドでしなくてはならない事は連続したリクエストとして統合する事が必要です。つまり、次のリクエストを見越して、それが連続性のあるものならその2つを統合してしまうのです。ブロックバックの内部では非常に単純な要素ですね。
単に次のリクエストを見る、それだけなのです。しかし、必ずしもそれは最善策とは限りません。理由としては、1つのリクエストをあまりに大きくしすぎると、そのリクエストを実行している間にその他のリクエストは犠牲になってしまいます。パフォーマンス改善チーム等を作って、検討していきたいですね。もしあなた方も味があれば、ブロックパフォーマンスを改善する為に一緒に作業ができたら素晴らしいですね。

山幡

有難うございます。ほかのアイディアとしては、コンテナ担当者が同様のパフォーマンスの分離を考えています。ですから何かそのようなメカニズムを「Xen」に追加出来るでしょう。
例えば彼らは階層化されたI/Oスケジューラーを提案しています。彼らのアイディアを採用してそれぞれのコンテナをそれぞれのドメインにマップする事が出来ます。

イアン

確かに仮想化を考えるとよりスマートなスケジューラーがあればいいですね。我々は一般的にCFQを使っており、本当に焦点を絞りたい場合にはさほど差別化ができないのです。ですから確かにそこに改善の余地はありますね。シークタイムのないフラッシュドライブのようなものに対してスケジューリングするほうが遙かに簡単なのです。そしてフラッシュドライブの偉大なところはディスクのどこに対しても同等にアクセス出来るので、殆どシークタイムがない事です。つまり大きな差が出るのはランダムアクセスです。でもディスクの配列を考え始めると、複雑になってきます。予測がつかないので、それが問題です。
サイモンさんは、現在何を研究されているのですか?

サイモン

私は、KExecについて研究・開発を行っていますが、深く追求すればする程難しい箇所にぶつかってしまいます。現在私は「Xen」とLinuxで異なるページオフセットによって起きる問題について取り組んでいます。しかしセットアップが1度しかできないというのが、KExec から別のOSに移るときの問題です。

イアン

そうですね、解決しなくてはならない問題です。

山幡

私が今取り組んでいるのはIA64です。2日前(7月18日)にx86で「Xen」のパッチが取り込まれました。IA64ではまだ準備ができていないので、もっと一般的なものを考えています。現在はバイナリパッチについて考えています。

イアン

少なくともIA64に対するバイナリパッチはx86に対して行うよりも容易でしょう。

山幡

しかし、IA64の命令フォーマットの制限があり、難しいです。

イアン

そうですね。
「Xen」とIA64の安定性とパフォーマンスについてはどのように思われますか?

山幡

そんなに悪いとは思っていません。

サイモン

私は日本においては「Xen」とIA64の市場は有望であると感じています。コンシューマはIA64マシンを購入しませんので、企業ベースがターゲットとなります。ですから市場開拓において重要な点は特性とパフォーマンスの2つだと考えます。

イアン

なるほど。IA64自体の成長に関してはどのように考えていますか?

サイモン

ユーザーは非常に大きなマシンを持ち、それをパーティションで分割して利用しています。そして、現在のシステムの交換を検討する際にIA64を候補として考えています。この段階で、ハードウェアベンダへはユーザーから様々なリクエストが挙がり、格ハードウェアベンダは独自の特性付のためこのリクエストに応えるべく努力を行っていくでしょう。ですから、IA64は進化してゆくと思います。

イアン

XenSource社は現在x86に関する開発を行っていますが、IA64のバージョンに対しても検討を行っています。プロジェクトとして始動する前に、市場規模やユーザーニーズの調査、開発体制の整備が必要となります。しかし、このプロジェクトは非常にうまく進行していくと私は感じています。

サイモン

イアンさん有難うございました。気長な意見交換が出来、感謝しています。今回、初来日との事でしたが、日本の印象はいかがですか?

イアン

こちらこそ、皆さんの意見が聞けてとてもよかったです。
日本は素敵な国ですね。ただ、残念ながら今回は観光する時間がなかったので、次回来日の際にはゆっくりと観光をしたいと思います。

  • オープンソース・プロジェクト「Xen」の創始者であり、同プロジェクトのリーダー。現在はケンブリッジ大学コンピュータ研究所の教授を勤める一方で、XenSource社にも席を置く。2001年、偏在するハードウェアの集約と、複数の稼働環境を可能とする「仮想化」の新たな追求を目的とし、「Xenプロジェクト」を発足。ITインフラの再整備と増え続けるハードウェア問題を解決に導く「仮想化」市場を牽引する。

  • 1999年、ストレージ関連の開発に従事。現在は、主にLinux Kernelチューニング、ファイルシステム、仮想化関連の開発に取り組む。最近では「Xen/IA64」をメインに活動。「Xen」プロジェクトを含む多数のオープンソース・プロジェクトに参画し、積極的なパッチ投稿を行う。xm dump-coreダンプフォーマットの変更なども目新しい。「Linuxカーネル2.6解読室(共著)」等の執筆活動にも従事。

  • 幼少時からコンピュータに慣れ親しみ、オーストラリアのニューサウスウェールズ州大学でブログラミングを学ぶ。米VA Linux(現SourceForge, Inc.)にてLinuxのクラスタのソフトを開発。LVSPerditionUltraMonkeySuperSparrow、等の中心メンバーとして開発、保守に従事。Xenプロジェクトへの貢献も大きく、Xen Kexecの開発等を手がける。SimonのBlogはこちらから。

ページトップ