IBMが考えるサーバ統合までのプロセス
サーバ仮想化／統合の成功の鍵は既存環境の把握とプロセスが重要
複雑になる一方のシステムを効率よく運用するために、サーバの仮想化／統合は避けて通れない道だ。IBMが考える「サーバ統合」により最短距離での統合を果たす！
サーバ統合、このテーマには昨今、多くの企業から熱い視線が注がれているのはご存知の通りだ。しかし、CPUプロセスを最適化するのか、あるいはディスクスペースを最適化するのかなど、サーバ統合前に明確化すべき項目があり、業種や部門により導き出される答えもさまざまだ。
このためIBMでは、こうした明確化すべき項目出しに悩む企業をサポートすべく、企業のサーバ統合環境を多角的に分析し、最適なソリューションを提案するプロセスを用意している。今回は、その入り口とも言える「サーバ統合のプロセス」というテーマに沿って解説してみたいと思う。
段階的なプロセスの実行がサーバ統合には必要
サーバ統合を行う目的は、企業によって異なる。業種、部門などによって扱うシステムに違いがあるのは当然として、物理的な問題でサーバの数を減らしたり、仮想化により運用中のアプリケーションを一括管理したりと、サーバ統合の規模や用途はさまざまだ。複雑なシステムをスムーズに統一するためにはどうすればよいのか。企業にとって、もっとも悩むポイントではないだろうか。
サーバ統合する場合、段階的なプロセスを実行するという視点を持たなければならない。この視点がなければ、サーバ統合を果たしたところで、思ったような恩恵を受けられない可能性があるのだ。IBMではこれを「統合の連続性」と表現している。
この考え方には大きく分けてインフラ系とアプリケーション系の2つの視点がある。インフラ系の統合は「Local centralization」、すなわち、少ない設置面積を有効に活用するための物理的問題を解決するケースと、仮想化を実現するために新しいテクノロジーやサーバに変更する「Physical Consolidation」というケースである。
また、アプリケーション系においては、複数のデータソースをシングルデータソースに変更する「Data Integration」と、複数のアプリケーションを統合して1つのプラットフォームとする「Application Integration」といったケースを考える必要がある。
《クリックで拡大》 サーバ統合といってもさまざまな段階があるのが分かる
インフラ系の視点から始めるサーバ統合
サーバ統合を行う際には、まず、インフラ系の視点から検討を始めるのが効果的だ。いきなりアプリケーションを統合しようとしても、プラットフォームや言語の違いなどにより、根本的に解決し難い問題を抱えてしまうケースが多いからだ。
IBMは「System x」をはじめ「BladeCenter」などの優れたサーバソリューションを用意しているのはご存知の通りだ。しかしそれだけではなく、サーバ統合を実現するための「プロセス」を提供している。この注目の「プロセス」の内容について簡単に触れてみよう。
企業がサーバ統合をプロジェクトとして進める上で、IBMでは検討フェーズを重視している。「現状調査」「初期システムデザイン」「分析／判断」の3項目だ。これにより、実際のプロジェクトへ移行できるのかどうかを明確にするのだ。その結果、サーバ統合によりメリットが生まれることが分かれば、詳細なシステムデザインや移行計画デザイン、運用管理、キッティング、システム構築などを行い、単体テスト、移行作業、チューニング、インフラ統合テストを実施するプロジェクトフェーズを実施することになる。
これら一連の流れの中で、特に重点を置きたいのは検討フェーズだ。この検討フェーズでつまずくと、それ以降の作業を行ったとしても指針に狂いが生じ、失敗に終わるケースが出てきてしまう。
《クリックで拡大》 IBMが考えるサーバ統合プロセス。ここでは、「検討フェーズ」に注目だ
既存のサーバ環境情報がExcel形式で確認できる
現在のサーバがどのような稼働状況にあるのか。検討フェーズでいう「現状調査」を実行するために、IBMでは「CDAT(Consolidation Discovery And Analysis Toolset)」というツールを開発した。このCDATはエージェントレスで、サーバ毎にツールをインストールすることも不要なため導入は非常に容易だ。また、このCDATにより、Windows環境ならパフォーマンスモニターの情報の確認を、LinuxならSSH経由でサーバリソース状況を取得するという具合に、複数OSが混在した環境に対応しているのも特徴だ。CDATはアプリケーション毎（一部除く）の状況までは取得しないため、別途アプリケーションやハードウェアの構成状況などの情報は個別に確認し、より効果的なサーバ統合の設計は必要である。
CDATにより集められた情報はMSDE2000a/SQL 2005 Expressにいったん格納され、Excel形式でエクスポートされる。このCDATにより得られた情報を分析することで、既存環境のサーバリソース状況を明確に把握することができるというわけだ。
《クリックで拡大》 CDATにより集められたサーバの稼働状況はExcel形式で確認できる
最適なシステムを指標化で予測する
検討フェーズの2つ目の項目になる「初期システムデザイン」では、4つのプロセスを経ることでサーバ統合へ向けた具体的な内容を検討する。仮想化統合の可能性を探る「仮想化統合の可能性アセス」、統合先サーバの必要スペックを明確化する「統合先サーバの要件算出」、そしてプラットフォームや導入費用を算出する「統合先プラットフォームの選択」「新規ハードウェア、ソフトウェア、導入費用」というプロセスだ。
例えば、統合先になるサーバを導入する場合、現在のシステムよりレスポンスが落ちるようなことがあってはならない。この初期システムデザインでは、そういった基本的な要件を踏まえつつ、どのようなシステムにすることが最適なのかを決定する作業を行うのだ。
また、新しいサーバの指標を100とした場合の現存するサーバの指標を知り、サーバ統合後のパフォーマンスを予測することが重要になってくる。この指標の数値は、調査会社などによる外部データを基準とすることで、客観的な判断を行っている。
《クリックで拡大》 統合化を行うには既存のシステムを指標化する必要がある
多角的な分析を行い正しいサーバ選択を
このようにして算出した指標値やCDATの結果、ここに成長率やVMwareのオーバーヘッドなどを加味することにより、サーバ統合に必要な新システムの要件を具体化していく。その後、検討フェーズでいうところの「分析／判断」を行うのだ。これにより、要件を満たすサーバの種類や製品、費用のROI算出や削減できるコストなどを考え、案件に対するインフラの統合化にはどのようなものが必要になるのかがようやく明確になるのだ。
もちろん、最終的に提案できるサーバは、企業によって違うことは言うまでもない。しかし、世界的ハードウェアベンダーでもあるIBMのサーバラインアップなら、ほぼすべての業種にマッチする製品が必ずそろうというメリットも忘れてはならない。主な選択肢としては、最新のアーキテクチャを搭載したSystem xへのアップグレードや、柔軟にサーバを追加できるBladeCenterの採用となるだろう。それぞれに特徴があるが、サーバ統合へ向けたプロセスを綿密に行うことができれば、統合化へ向けた製品選びは楽になる。IBMのサーバソリューションにより、的確なサーバ統合を実践してほしい。
《クリックで拡大》 コスト削減も重要な課題。TCO分析を含め、最終的な立案をしていく
Copyright © ITmedia, Inc. All Rights Reserved.
