【 ここから本文 】
システム／アプリケーション統合
ソーシャルブックマークに登録 ：
印刷用ページの表示
【解説】
サーバ仮想化導入ステップガイド［計画編］
VMwareの導入から配備までを「ハンズオン」
（2008年07月15日）
仮想サーバと物理サーバを選別する
ともあれ、アーキテクチャが決まった。Brown氏が次に取り組んだのは、仮想化環境に配備するサーバと、物理サーバとして残すサーバの選別である。この作業は、当初予想していたよりも難しかった。
サーバを選別するには、各サーバに対する負荷、つまり、物理的な仮想化ホストがいくつ必要かを決定する必要がある。初期テストの結果、ESX Serverのハイパーバイザが、ホスト・サーバの“生”のパフォーマンスを約10％消費していたため、仮想化ホストの実際的なキャパシティは、仮想化されていないホスト・サーバの90％であることがわかった。利用率90％以上のアプリケーションを仮想化環境で運用すれば、パフォーマンスが悪化するおそれがあるため、サーバを統合する意味もない。
さらに、利用率を測定するのは容易ではなかった。Windowsマシンで「Perfmon」、Linuxマシンで「SAR」などの性能測定ツールを使えば、特定サーバの利用率は簡単にわかるものの、そのサーバが別のサーバとどういう関係にあるかまでを把握するのは一筋縄ではいかなかったからだ。
例えば、医療費還付／給付金管理ソフトウェアを走らせていたサーバ「Thanatos」は、デュアルソケットに対応した動作周波数2.8GHzのシングルコアPentium 4プロセッサを搭載しており、平均ロードは4％だった。一方、ボイスメール・システムの「Hermes」は、デュアルソケットに対応した動作周波数2.2GHzのデュアルコアOpteron 275プロセッサを搭載しており、平均ロードは12％という稼働状況だった。これら2つのCPUは、アーキテクチャがまったく異なるうえに、HermesのCPUコア数はThanatosの2倍だ。しかも、仮想化環境をプランニングする際、基本的なリソースとしてCPUの利用率だけでなく、メモリ／ディスク／ネットワークの利用率も同じくくらい重要なことが、事態をさらに複雑にしていた。
Brown氏は、キャパシティ評価用のアプリケーションがなぜこれほど多く存在するのかを、このとき初めて理解した。10〜20台程度のサーバであれば、Excelをこじ開けて独力で解析するのにそれほど手間もコストもかからなかっただろう。負荷を段階的に仮想化して実環境での利用率を知るという手段もあったが、これでは予算がいくらかかるかわからず、Tersitan氏とCFOのクレイグ・ウィンダム（Craig Windham）氏から承認を得られるとは思えなかった。
そこでBrown氏は、市場調査を行った後、Richter氏に、サーバ仮想化のキャパシティ・プランニングを社外のコンサルティング会社に任せてはどうかと提案した。そしてBrown氏は、VMwareのパートナーに評価を依頼したところ、結果が出るまで1、2カ月かかるとの返答を得た。少なくとも1カ月間はサーバの稼働状況を観察しないことには、サーバ利用率を完全かつ正確に解析できないというのがその理由だ。それくらい時間をかけなければ、週報や月報など、処理業務が毎日発生するわけではないプロセスの負荷を反映できないのだ。
技術的には確かにコンサルティング会社の言うとおりだが、それだとBrown氏とRichter氏は、Tersitan氏と約束した実装プロポーザルの締め切りに間に合わなくなる。しかし、幸いにもWindham氏がプロポーザルは正確であるべきだと賛成してくれたおかげで、Tersitan氏も納得してくれた。
プロポーザルの延期は、Brown氏とTersitan氏の両者にとって、むしろ幸いだったと言える。システムの土台となるハードウェアやソフトウェアの選択など、プランニング作業にはまだまだ時間がかかりそうな案件が山ほどあったからだ。
しばらくするとキャパシティ・プランニングの最初の解析結果が届き、Fergenschmeirが抱えるアプリケーション・サーバの大半が10％以下のキャパシティで稼働していることが判明した。加えて、サーバを72台配備することを考えていたが、実際はかなりの数まで仮想化により統合できることがわかった。既存アプリケーションを余裕をもってホスティングし、将来的な拡張性を持たせつつ、1台のホスト・サーバに障害が起こった場合でもダウンタイムを極力抑えられるようにするためには、デュアルソケット対応のクアッドコアCPUを搭載した8、9台の物理サーバを、ESX Serverで仮想化するという構成が最良だと判断した。（7月18日掲載予定の［配備編］に続く）
VMwareの導入から配備までを「ハンズオン」
