Windows 2000を基幹システムで利用するには,そこで求められる高い可用性や安定性を確保するために,各種ハードウエアや関連技術との非常に綿密な動作確認が欠かせない。イーエムシー ジャパン(EMCジャパン),日本ユニシス,プライスウォーターハウスクーパース コンサルタント(PwCC),マイクロソフトの4社は,こうした課題や解決策を明確にするため,昨年10月に共同で「MOCHA」プロジェクトをスタートさせた。「Windows 2000システムでもエンタープライズ分野に必要な可用性,安定性が実現可能なことをアピールしたい」とマイクロソフトの大野貴弘ソリューションパートナー部マネージャーは語る。MOCHAは次のような2つの技術テーマを検証し,今年5月にその成果を明らかにした。

検証テーマ(1):
システム無停止でバックアップ実行

 MOCHAプロジェクトで検証したテーマの1つは,基幹業務システムを止めずにデータベースのバックアップを実行すること。無停止運用が求められるシステムには不可欠な技術である。

図1●検証テーマ(1):基幹業務システムを止めずにバックアップを実行する
ストレージ装置内にバックアップ用のミラー・ボリュームを作成し,業務システムとは独立して実行
 このテーマを検証するために用いたシステムの構成は図1[拡大表示]の通りである。カギを握るのは,EMCのストレージ装置(テストではSymmetrix 8430を使用)に搭載された「TimeFinder」というボリューム管理ツールだ。このツールにより,業務システム用のボリュームとは別に,バックアップ専用のミラー・ボリュームを作成できる。

 このミラー・ボリュームは,通常は業務システムがアクセスするメイン・ボリュームと全く同じ内容に維持されている。このボリュームをオフラインにしてバックアップ専用に使えば,業務システムのデータベース運用に影響を与えることなく,バックアップを高速に実行できるわけだ。

 この処理方式は,既にメインフレームやハイエンドUNIXサーバーの分野では実績がある。しかし,「EMC製品は高価なイメージがあるためか,NT/2000環境ではまだあまり使われていない」(EMCジャパンの清水マークプロダクト マネージャー)という。

 ストレージ装置の特徴に合わせて,サーバーのシステム構成も工夫した。ストレージ装置と同様に,業務システムとは別に,バックアップ専用のシステムを用意した。

 サーバー・マシンには,最大32プロセッサ構成が可能な日本ユニシスのES7000(テスト時は16プロセッサ構成)を用いた。ES7000はサーバーを最大8個のシステム空間(パーティション)に分割する機能を備えている。この機能を使ってサーバーを2つのパーティションに分割し,一方にWindows 2000 Datacenter Serverと統合業務パッケージのR/3,SQL Server2000による基幹業務システムの環境を構築。もう一方にバックアップ処理専用のシステムを導入した。

連携モジュールの不具合を回避

 バックアップ処理を開始する手順はやや複雑である。単純にボリュームをつなぎ直すだけでは正常に動作しない。例えば,「ミラー・ボリュームをオフラインにするとき,データベースに不整合が起こらないよう,処理途中のトランザクションやキャッシュ,チェック・ポイントなどを適切に制御しなければならない」(マイクロソフトの中川哲SQL Server製品グループシニアプロダクトマネージャ)。

 このような処理を自動化するために,TSIM(TimeFinder-SQL Server Integration Module)という,TimeFinderとSQL Serverを連携動作させるソフトを利用した。ただし,「MOCHAが初めてのユーザーだったので,試行錯誤しながら動作検証する場面もあった」(EMCジャパンの新井英記テクニカル・パートナー・マネージャー)。

 TSIMを使えば,本来なら一連のボリューム切り替え処理を自動的に実行してくれるはず。しかし,TSIMの不具合により,一部の処理が自動では実行されなかった。特に「ボリュームのマウントやキャッシュの扱い,リストアの手順に問題が出た」(同)。

 MOCHAはTSIMの機能を一通り検証し,問題点を徹底的に洗い出した。TSIMの不具合を修正したわけではないが,「一部にマニュアル操作を組み込み,手順そのものも若干見直した。問題なく動作する運用手順を確立できたことが大きな成果」とPwCCの鈴木広司シニアマネージャーは語る。

検証テーマ(2):
Win2000で複数のR/3システムを実行

 MOCHAが検証した2つ目のテーマは,1台のWindows 2000サーバー上で複数のSAP R/3システム(インスタンス)を安定動作させることである。できて当たり前のような感もあるが,「SAPジャパンはこれまで,Windows NT/2000環境で複数のR/3システムを実行するようなシステム構成を推奨していなかった」(日本ユニシスの柴田晴見SAPプログラムマネージャー)。サーバーの処理能力不足や,一部のシステムで起こった障害が他のシステムに悪影響を与えることを避ける,などの理由によるという。

図2●検証テーマ(2):SAP R/3をマルチインスタンスで安定動作させる
R/3の各インスタンスに割り当てるプロセッサ数を動的に変更し,余裕を持たせて安定動作を実現
 MOCHAはこのテーマを検証するために,図2[拡大表示]のようなテスト・システムを構築した。ES7000にWindows 2000 Datacenter Serverを搭載し,その上で3つのR/3インスタンスを実行させた。Datacenter ServerにはProcess Controlというリソース管理ツールがある。このツールを使って,R/3とSQL Serverの各インスタンスを1つのプロセス・グループとして定義し,それぞれ一定量のメモリーや4~5個のプロセッサを割り当てた。

 このシステム構成の特徴は,Process Controlツールによって割り当てるプロセッサ数を動的に変更できる点にある。各プロセス・グループにかかる負荷の大きさが変化しても,安定したレスポンスを保証できる。

 実際にシステムを稼働させてみたところ,R/3の動作に不安定なところは見られなかった。プロセッサ割り当て数の動的な変更も,仕様通りに動作することが確認できた。「R/3のインスタンスごとに割り当てるリソースを制御することで余裕が生まれ,これが安定動作につながったのではないか」と日本ユニシスの柴田マネージャーは見る。MOCHAの検証結果を受けて,「SAPジャパンはWindows 2000環境でR/3の複数インスタンスの実行を『推奨しない』とは言わなくなった」(PwCCの鈴木シニアマネージャー)。

(渡辺 享靖=takayasu@nikkeibp.co.jp)