SUSE Linux Enterprise 10 SP1+XEN3.04 ->SLES10 SP2+XEN(3.2) のアップデート

SLES 10 sp1 -> SLES10 SP2 へのアップデートを行いました。XENカーネルが動くCPU装置全体のアップデートです。


Transrate This Blog English

まず、結論から言います。止めた方が無難でしょう。

アップデートの詳細は Domain-U をアップデートした方法と同じく DVD Media から起動し Update を実行しました。詳細はこちらのブログを参考にします。

SUSE Linux DeskTop (SLED) on SLES+XEN の 10　sp1 から 10　sp2 へのアップグレード

SUSE Linux (SLES) 10 sp1 on SLES+XEN -> SP2 へのアップデート

いよいよ、本番の XEN Domain-0 のアップデートです。さてどんな変化があるのでしょうか。期待半分、怖さ半分です。

--注意すること

1) インストール中にリブートが掛かります。その際、XEN カーネルで起動するのでできれば Grub のブートローダーを通常カーネルで起動できるよう Default のチェックを通常カーネルにしておくと良かったかも知れません。

2) /etc/xen/auto にあるシンボリックリンクは削除しておきます。インストールからの再起動を行う場合、 XEN Deamon が起動して、登録された Domain-U が起動してしまうのはあまり好ましいものではありません。どのようなトラブルが出るかはわかりませんから。

私は 2) の方法をあえて選びました。

アップデートの結果については特に問題がなかったと言えます。 2) の対策は行っていましたが、再起動中にトイレにも行かず、 Grub のスクリーンから XEN カーネルで起動しても、インストールの Finalize は問題なく行えました。
しかし、インストールの途中でトイレに行く予定があるヒトは 1) の方法も考慮しておくべきです。



--インストールしてどうなったか

1) まず、既存の Windows XP イメージの仮想マシン ( Domain-U) が見事にブルースクリーンで起動できなくなりました。起動ができるのですが、他のドメインを起動すると、 Domain-u の起動中に、Windows XP は見事にクラッシュしました。どうもビジーなジョブを走らせると Windows XP はブルースクリーンに陥るようです。



2) Windows 2003 イメージのサーバは起動できるものの、リモートデスクトップはほとんど使い物にならないくらい、レスポンスが悪くなりました。Hesitate するような怪しい動作です。



3) Domain-0 を shutdown -r 0 すると xend の終了すると同時に、現在稼動中の DOmain-U を５分間の間 xm save しようとリトライします。 Windows, OES NetWare は XM Save できませんから、これらの仮想マシンが xm save に失敗するまで 300 秒待たなければなりません。仮想マシンが３台動いていると、１５分も待つことになります。

これにはなんらかのチューニングが必要なのかも知れません。

Windows の XEN Driver Package を一度 Uninstall してもう一度 Setup しなおすと以前より安定はしていますが、使い物になるには程遠いレベルです。

4) 半日と持たない xend デーモン。再起動した Domain-0 ですが、一晩放置しておくと、見事に xend が異常終了していました。安定しているとはとても言いがたい状況です。

-- Live Migration

SLES 10 SP2 に搭載された XEN 3.2 の売りは、仮想化された Windows の Live Migration です。しかし、私の貧弱なテスト環境ではこの機能をテストすることはできません。なぜなら、 Live Migration を行うためには、 Source, Destination, 共有ディスクの３つのコンポーネントを必要とするからです。これらをテストのために準備することは容易ではありません。

確かに Live Migration はデモンストレーションを行うと観客の注目を浴びることは間違えありません。しかし、システムの耐障害性を考えて Live Migration を検討するととんでもない目にあうことは間違えないでしょう。システムが一番弱い場所、つまりディスクドライブ装置の二重化を検討しない限り、Live Migration による、耐障害性の向上は望めないのです。

「こけおどし」に過ぎません。

Live Migration によって耐障害性の確保するには Fiber Channel や二重化された iSCSI ネットワーク、二重化されたディスクコントロールシステムや、二重化された Fail Recovery の仕掛けが必要です。数千万円の投資が必要です。それでも自動的な Fail Over は実現できません。

その点まで考慮すると、Live Migration による耐障害性を検討しているシステム企画者には VMware をお勧めしたくなります。Live Migration は。かつて Novell が NetWare 4 で実現していた SFT-III のような強力に完璧に機能する Fail Over のシステムではありません。

むしろ、マルチに稼動する、仮想化システムの負荷とロードバランスを調整するための Live Migration であり、Live Migration はオペレーターの操作の介在が必要です。

負荷監視はオペレーターの業務であり、その調整を Live Migration で実現できると考えるのが一番正しい考え方です。ですが、一瞬でも止められないシステムであれば、実用的ですが、よほどのハイエンドを目指すのでなければ、 Live Migration の機能はあまり実用的とは思えません。また、負荷監視が容易にできる管理ツールが貧弱な現在ではこれを売りものにすることは困難だと言わざるを得ないでしょう。

-- Conclusion

SLES 10 SP2 に搭載された XEN 3.2 にはまだまだ改善の余地がありそうです。現在 SLES 10 SP1 をご利用しているお客様には、あわててアップデートしないことを強くお勧めします。ただし、 SLES on SLES+XEN で運用するのであれば、それほど問題がなさそうだと報告することができます。 Windows or OES NetWare on SLES+XEN 環境で動かすことが目的であれば、 SLES 10 SP1 の方がよほど安定して安心してお勧めすることができます。

SUSE Linux Enterprise Server (SLES) 10. SP1, SP2, Update, Domain-0, Windows Blue Screen, Windows Crash, on XEN 3.2 Environment,

非番のエンジニア