nkjmkzk.net

一昔前までI/Aサーバ用のVMは完全に検証環境用でした。I/Aサーバ用の仮想化技術は当初デスクトップマシンに仮想化ソフトをインストールし、そのソフトがハードウェアをエミュレーションすることでOS上にさらに複数のOSを稼動させることができるという技術でした。この画期的な技術は主に検証時に度々必要となる新しいOS環境、H/W環境の用意を素早く効率的に行う目的で検証作業、開発作業において広く受け入れられています。

一方、「エミュレーション」という言葉から連想されるのは「高度な抽象化」であると同時に「顕著な性能劣化」です。エミュレーションといってもその実装は様々だと思いますが、とかく仮想化 = エミュレーション = 性能は望めない　という図式が通念となっていることは容易に想像できます。実際には現在サーバ仮想化分野で採用されている実装の主力はHypervisor型であり、従来のVMware Workstationのようなものとは全くことなる方式で複数OSの稼動が実現されています。Hyperviosr型仮想化ソフトウェアのパフォーマンスについては現在ではWebの記事掲載や各社が独自に性能検証を行っていることである程度知られるようになってきていると思います。ただしユーザの頭からはそう簡単には不安は消えません。性能劣化についての懸念や、漠然とした「安定性」への不安はソフトウェアベンダーがいくら理屈をこねてもすんなり受け入れられるものではないでしょう。それは性能や安定性を支える技術がOSやHypervisorのコアの部分に左右されるところであり、一部のカーネル開発者を除いて一般的なエンジニアにはその妥当性を技術的な観点で判断するのは極めて難しいことが理由だとおもいます。技術的には判断できないからこそ「事例」といった形の結果的、客観的な証明が求められるのだと思います。しかし事例というのは鶏と卵の関係で、ソフトウェアを開発してリリースした時点では当然事例は0です。そして事例がなければ受け入れられないのであれば事例が生まれることもありません。なのでソフトウェアベンダーはファーストリリースのソフトウェアの話に耳を傾けていただけるお客様に対して事例ではなく、技術的に、理論的に、そのコンセプトに熱意をもってアプローチしていかなければならないと思います。その観点で今回のポストは「事例があるかどうか」という話ではなくその前のフェーズで「VMを本番環境で使えるか？」について少し検証してみたいと思います。

多くのユーザはVMに漠然として不安を感じています。その不安の内訳は「性能劣化」と「安定性」が大部分を占めると思っています。今回は性能劣化について言及したいと思います。率直に言って現在のHypervisor型の、それもXenの準仮想化アーキテクチャは非常に優秀です。多くの方が抱かれている性能に関する不安はいろいろなテストを行えばほとんどは払拭できるのではないかと思っています。それどころか経験上は性能の良さに驚かれるケースの方が多いと感じています。特に純粋なCPUの演算能力についてはほとんどNativeのOSと際がない程です。仮想化環境で最も劣化が起こるのはI/O処理だと言われていますが、この劣化もそれほど影響が大きいものではありません。この劣化具合は残念ながら個別にテストしたデータをお見せするわけにはいかないのですが、第三者テスト機関のTolly GroupがOracle VM上のOracle Databaseに関するベンチマークを行い、そのレポートを公開しています。

Performance Evaluation of Oracle VM: Tolly Group Benchmark

これは性能データが公開されている極めて異例で貴重な資料です。この資料を参照するとOLTPの負荷に対してVMはNative OSと比較してわずか数%の劣化しか示していません。もちろん性能テストは環境やテスト内容によって結果は大きくことなりますが、一つの指標として有用な情報だと思います。この資料をもって全てのユーザが抱く性能についての不安払拭されることはないと思いますが、このようなデータをきっかけに興味を持っていただき、個別にテストを実施していただいて是非を判断いただければ良いなと思います。

@ITでOracle VMの世界、連載第三回が掲載されました。

今回はOracle VMで特徴的なテンプレートを使った仮想マシンの作成手順をご紹介しています。

Oracle VMの世界　第三回　Oralce VMにおける仮想マシンの作成

Oracle VMの仮想マシンテンプレートは基本的に初期状態ではネットワーク設定はDHCP参照となっています。しかしながらDHCPを使用していない環境では当然リクエストしてもタイムアウトになります。そんなとき、このタイムアウトがちょっとばかし長いのが気になります。特に害はないのですが何回もやっているとストレスが溜まりますし、デモをしているときにここでひっかかると冷や汗モンです。ということでdhclientの設定ファイルを編集してタイムアウト時間を短くしておきます。

# vi /etc/dhclient.conf
timeout 3

これだけです。お粗末様でした。

＊ちなみにこの設定ファイルはデフォルトでは存在しないかもしれません。なかった場合はそのまま作成してしまいましょう。

現在、Linuxのファイルシステムのスタンダードと言えばext3に間違いないでしょう。しかしながらext3はext2との互換性を可能な限り保ちながらジャーナリング機能を追加するという基本設計です。なのでファイルシステムとしては少々古びており、技術的に最も優れているというわけではありません。最近ext4の安定板がkernel 2.6.28で利用可能となりましたが、ext4についてもext2からの設計を受け継いでいるため、それほど大きな機能追加や基本設計の変更というのは多くありません。

そんな中、Snapshot機能は差分バックアップとして効率的な考え方ですが、現在ファイルシステムでその機能をサポートしているものは多くありません。ext3もSnapshot機能は実装されておらず、実際LinuxでSnapshotを行うにはボリュームマネージャ（LVM）で行うことが最も手軽でポピュラーだと言えます。LVMのSnapshot機能はその使い方についてはそこら中に情報がありますが、実装についてはあまり知られていない気がします。僕もそこまで細かく見ているわけではありませんが、ユーザが往々にしてハマりそうなポイントをいくつかの例を見ながら挙げてみたいと思います。

あるLV, /dev/test/dataがあるとします。このLVのSnapshotをdata-snapとしてとります。dataの中のファイル, test.img (1Gbyte)をrmしたらどうなるでしょうか？　個人的な感覚では、test.imgのdata block情報がdata-snap領域にコピーされてからtest.imgが削除される。なのでdata-snapに確保してある領域が1Gbyte減る、と思います。

しかし実際にはdata-snapの領域はほとんど減りません。

また、dataの中にnew.img (1Gbyte）を新たに作成したらどうなるでしょうか？　個人的な感覚では、特段dataの中のデータを変更したわけじゃないのでdata-snapは関知しないのではと思います。

しかし実際にはdata-snapの領域は1Gbyte消費されます。何か納得いかない感じ。

つまりLVMのSnapshotはファイルシステムが実際にdata blockを更新したときにもとのblockをコピーするということに尽きる、という感じです。もし元のdata blockが空であっても。rmの場合はファイルシステムがdata blockを上書きするのはrm発行時ではなく、次にそのblockがファイルシステムによって確保されたときなので、それまではdata-snapの方にはそのデータはコピーされず、存続してるデータを参照し続けています。ある種効率的と言えば効率的です。でも、要は直感的でないのです。個人的には。

これに対し、先進的なファイルシステムの一つとしてZFSがあります。ZFSは現在Solarisのデフォルトファイルシステムとして採用されています。このファイルシステムは悔しいけど正直すごい。Linuxでもbtrfsってのが同じようなコンセプトで開発されていますが、こちらはまだunstableでkernel 2.6.29 rc1とかでようやくメインストリームにマージされた模様。かなり遅れをとっています。ZFSがすごいポイントは結構一杯あるので今回はSnapshotところに焦点を絞ります。ZFSはファイルシステムではあるものの同時にボリュームマネージャでもあります。ファイルシステムの機能でSnapshotが撮れてしまいます。そしてZFSのSnapshot実装はLinuxのLVMとは異なります。

先の２つの例では結果が逆になります。つまり、data中のファイルをrmした場合は即時data-snapの方にコピーされます。また、dataにファイルを新規作成した場合は関知しません。

LVMが「data blockを変更したらオリジナルのdata blockをコピーする」というスタンスであるのに対し、ZFSは「オリジナルのデータを維持する」というより上位の考え方で実装されている気がします。

＊ちなみに上記data blockはより正確にはchunkということになると思われます。

個人的にはZFSの方が好きです。あとZFSが優れているのがrollbackをちゃんと備えているところですね。LVMは残念ながらrollback（もしくはrevert）を行うためのコマンドを用意していません。なのでリストアするには少し七面倒くさい手順が必要です。ZFSの場合はzfs rollback xxxxxとすれば一発でオリジナルのファイルシステムをSnapshotを撮ったときの状態に戻すことができます。うーむ、ZFS良すぎ。

この他にもとんでもいい機能がかなりありますがそれはまた機会があれば。最後にOpenSolarisのスクリーンショットを。結構カッコいいのよね。。

CPUについて調べています。といってもテッキーな話ではなく、各サーバベンダが2009/3現在でどのようなプロセッサーを搭載してサーバラインナップをそろえているのかという話です。何故これをやってるかというと6コアが気になっているからです。現在スタンダードなコア数は2(dual)また4(quad)でしょう。でも昨今6コアが出回ってきているという噂を聞きます。実際どうなのでしょう。

各社のサーバの6コアプロセッサー搭載状況を調べました。

まず6コアが採用されているプロセッサーの型番を知っておく必要があります。下図はIntelのWebページからの引用です。

ということで、現在6コアが採用されているのは、以下の３つです。

• X7460
• L7455
• E7450

＊ちなみに7400番台以外で6コアを搭載しているプロセッサーはありません。

これらプロセッサーをオプションとして用意しているサーバ機種を各社毎に調べました。

HP

ラック型

• DL580 G5 (4way) \2114700 -

ブレード 

• BL680c G5 (4way) \1225350 - 

IBM

ラック型

• x3850 M2 (4way) \2551500 -
• x 3950 M2 (4way) \3349500 -

DELL

ラック型

• PowerEdge R900 (4way) \1080975 -

NEC

ラック型

• Express5800/R140a-4 (4way) \1550000 -

ブレード

• Express5800/B140a-T (4way) \?

日立

 ラック型

• HA8000/RS440 (4way) \2238000 -

ブレード

　　＊6コアモデルはないが、最上位のBS2000はNehalemを採用している

富士通

ラック型

• PRIMERGY RX600 S4 (4way) \1390000 -

各社ともラインナップには加えているようです。ただし特筆すべきはどのベンダも4wayサーバ、最上位機種にしか搭載していないということです。

なので結果として言えることは1ソケットで6コアというような構成は、2009/3現在では現実的ではないということです。6コアはハイパフォーマンスを求めるユーザに向けて提供されていますが、ローエンドにもすべからく供給しているわけではないようです。

E-DeliveryにてWeblogic Server 10g Release 3の仮想マシンテンプレートがリリースされています。

E-Delivery

実際にこのテンプレートをOracle VMにインポートして仮想マシンを作成するとわかるのですが、ホントに簡単です。今まで苦労してソフトウェアの要件に合わせてOSを設定したり必要なパッケージを入れたり、インストーラについて調べたり、、という作業がまるで必要ありません。

そしてこの仮想マシンテンプレートは決して簡単なテスト目的のために提供されているものではありません（もちろんその目的でも便利なのですが）。本番環境でそのまま使用することを前提にOracle側で入念なテストを重ねたものです。あまりに導入が簡単だと「これはテスト用だよね」となりがちですが、そうではありません。

これからのシステム構築作業は今までとは工程が変わっていきそうです。