|
サイモン |
「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のバージョンに対しても検討を行っています。プロジェクトとして始動する前に、市場規模やユーザーニーズの調査、開発体制の整備が必要となります。しかし、このプロジェクトは非常にうまく進行していくと私は感じています。 |
|
サイモン |
イアンさん有難うございました。気長な意見交換が出来、感謝しています。今回、初来日との事でしたが、日本の印象はいかがですか？ |
|
イアン |
こちらこそ、皆さんの意見が聞けてとてもよかったです。
日本は素
敵な国ですね。ただ、残念ながら今回は観光する時間がなかったので、次回来日の際にはゆっくりと観光をしたいと思います。 |
