![]()
| 要約 | |
| はじめに | |
| ソリューション フレームワーク | |
| Microsoft での Virtual Server 2005 の展開 | |
| Law and Corporate Affairs: 好適例 | |
| 結果 | |
| 今後の方向 | |
| まとめ | |
| 詳細情報 |
一般的に、物理的なインフラストラクチャの統合は、効果的なビジネス戦略です。部門や拠点に配置されている物理サーバーを統合することは、サーバーの増大を抑制し、IT 効率、柔軟性の向上、および総保有コスト (TCO) の削減につながることが立証されています。仮想化は統合を新しいレベルへと引き上げ、アプリケーションとサーバーの 1 対 1 の関係を切り崩します。仮想化は、アプリケーションを物理サーバーから抽出し、バーチャル マシン (VM) に配置することによって、さらなる利点を引き出す統合技術です。バーチャル マシンの多くは 1 つの物理ホストに共存することが可能です。
Microsoft の仮想化ソリューションである Virtual Server 2005 (VS) は、統合戦略の一部であり、IT サービス用のユーティリティ モデルを備えています。Microsoft IT によって作成された Virtual Server Utility (VSU) は、サービス レベル アグリーメント (SLA) によってサポートされる一元管理サービスとして、VS を Microsoft 社内のユーザーに提供します。VS は、拠点の Business Unit IT (BUIT) 部門によって準備および管理されているオンサイト サーバーを使用している従来のシナリオと比較すると、はるかに優れています。SLA は、数多くの評価尺度によって構成されており、これらは明確で有利なケースをユーザーに提示するだけでなく、VSU チームの努力目標にもなります。これらの評価尺度には、サーバーのプロビジョニング(準備)期間、サポート利用の可否、ホストの可用性、ゲストの可用性、およびホストの CPU 使用率などがあります。もちろん、基準測定値となるのはコストの削減です。
Microsoft では Virtual Server 2005 を実際に使用してみたところ、非常に望ましい結果が得られました。サーバーのプロビジョニング(準備)期間は、自己ホスト型の物理サーバーの場合には 22 〜 25 日でしたが、Virtual Serverでは 1 日に短縮されています。ユーザーのコスト削減は 3 年間で約 30% となり、満足度が向上しています。SLA 全体を通じて、どの評価尺度を取っても、実際の結果は期待通りであるか、期待を上回るものでした。
このホワイト ペーパーの目的は、Virtual Server 2005 のパイロット実装における Microsoft での経験を共有することです。Microsoft の IT 要件は世界でも最も厳しいレベルにあるため、このパイロット実装で Microsoft IT が採用した手段やそれから学んだ内容は、エンタープライズ規模の IT 環境における今後の一般向けリリースの実装において、お客様に非常に役に立つガイダンスを提供できることでしょう。
Microsoft の製品やソリューションを検討する際、企業の意思決定者は Microsoft 社内でのこれらの使用経験についてよく尋ねてきます。Microsoft IT では自社に従来の IT 機能を提供するだけでなく、新しいサーバーやビジネス生産性ソフトウェアの各リリースの最初のユーザーとしての役割も果たします。Microsoft IT の要件は世界でも最も厳しいレベルにあるため、Microsoft IT が採用する手段や初めての経験から学ぶ内容は、その後の一般向けリリースの実装において、お客様に非常に役に立つ展開および運用上のガイダンスとなります。
Microsoft IT では、ユーティリティ サービス チームに属する Compute Utility (演算ユーティリティ) チームを発足させています。ユーティリティ モデルにより、ユーティリティ サービス チームは社内のユーティリティまたはサービス プロバイダとして位置づけられており、社内のアプリケーションおよびサービス所有者のためにチームの専門リソースを提供します。サービスには、Compute (演算)、Storage (ストレージ)、および Data Protection (データ保護) があります。
Compute Utility は、Virtual Server 2005 に基づくサービスを提供します。このサービスは、何らかの分離手段を必要とする、低レベルから中レベルの負荷のアプリケーションおよびサービスをホストするように設計されています。このサービスはアプリケーションやサービスを統合し、これらをバーチャル マシン (VM) の形式で共有リソースに配置します。これらのバーチャル マシンのいくつかは、専門的なコンピュータ技術者チームの一元管理下にある 1 つの物理的なVirtual Server ホストに共存しています。このアプローチは、基幹業務 (LOB) アプリケーションおよびサービスのコンピューティング ニーズに対応するうえで、非常に信頼性が高く、効率的な手段となります。同時に、アプリケーション所有者は、物理的な各サーバーの日常の管理に直接関与するうえでの多くのリスクや複雑な要素から解放されます。これらのアプリケーション所有者は、機器に必要なコストを大幅に削減することができます。さらに、サーバー ソリューションに必要な物理的スペースが減り、データ センターの貴重なスペースが空くため、ラック スペース要件を軽減することができます。また、諸経費、電力、環境制御システムなどの運用コストも削減されます。さらに、VS によってプロビジョニング(準備)、移動、追加、変更などの作業が迅速に行われるので、機敏な運用が可能になります。セキュリティは常に考慮する必要があります。具体的な実装シナリオに応じて、仮想化によってセキュリティを強化することができます。これは、攻撃の対象となる規模の縮小、ハードウェアおよびオペレーティング システムの標準化、高度なセキュリティ システムの実装、および集中化されたユーティリティ サービス チームによる常時の警戒によって実現できます。各 VM(および実装により各アプリケーションは、仮想化する前の分離環境を維持することができます。これは、それぞれ独立したオペレーティング システムのインスタンスに関連づけられているからです。アプリケーションおよびサービスの所有者は、これらの恩恵をただちに享受できます。また、ビジネス ユニットのコンピューティングおよびネットワーキングの需要が高まり、その需要のサポートがさらに困難を極めていくにつれて、恩恵はさらに増加することが期待できます。
統合にはこのような利点があるにもかかわらず、一部のビジネス ユニットの関係者は、統合を不安を招くものとして捉える傾向にあります。これらの関係者は、日常の運用業務を集中化されたサービス ユーティリティにゆだねることで、所有するアプリケーションを制御する能力が全般的に低下することを恐れています。具体的に言うと、これらの関係者は、集中化されたユーティリティ サービス グループは拠点の IT サポート グループよりも対応面で劣ると考えており、それによって業務上重要なアプリケーションやサービスを含むシステムおよびネットワークの運用機敏性と総合的なパフォーマンスが低下し、主要なビジネス活動が影響を受けることを懸念しています。組織では、移行チームを作成することで、このような態度や見識に対応し、さまざまな手段を通じてこれらの懸念のほとんどを取り除くことができます。まず、周到な計画によって、負荷の高いアプリケーションやサービスは VS 環境に不適切なため、対象から外します。第 2 に、チームは非常に具体的な SLA を関係者と取り決める必要があります。
注 : ハイエンドのハードウェアを使用するように設計されている使用率の高いアプリケーションを VM 上で実行した場合、十分なパフォーマンスが得られない場合があります。これは、バーチャル層に固有のパフォーマンスの負荷が原因です。たとえば、Microsoft SQL Server および Microsoft Exchange Server は VM 上で実行できますが、特定の状況における負荷によっては、仮想化に適さない場合があります。
もちろん、ビジネス ユニットの関係者は、適切なアプリケーションおよびサービスを使用していても、ネットワークおよびコンピューティング システムに対する総需要がピークに達するわずかな期間においては、運用パフォーマンスの低下をある程度経験することがあります。ただし、数値として明確になるコスト削減やプロビジョニング(準備)期間の短縮などの利点を、機敏性の向上やセキュリティの強化などの主観的利点と合わせると、若干のパフォーマンスの欠点を十分補うことができます。VSU チームでは、周到に計画し、移行を慎重に実施して、SLA で確立された評価尺度に準ずるその後の運用パフォーマンスを向上させることによって、悲観的な態度や見識のほとんどを覆すことができました。このため、VS を最適なソリューションと見なす意見の一致をすばやく得ることができました。最適化の本質は、コストとパフォーマンス間で最適なバランスを保つことにあるためです。VS は、全体としても、すべての評価尺度を考慮しても、飛躍的な向上を実現できます。
このホワイト ペーパーでは、ソリューション フレームワークについてまず検討します。具体的には、ビジネス戦略としての統合、統合技術としての仮想化、特定の製品ソリューションとしての Virtual Server 2005、ソリューションへの移行プロセスなどを検討します。次に、仮想化と Virtual Server 2005 に関係のあるすべての用語を定義します。さらに、Microsoft 社内でのユーティリティ機能としての Virtual Server 2005 の展開について、コンサルティング フェーズから実装フェーズ、そして運用フェーズに至るまでを詳しく検討します。また、統合および仮想化に対する社内のユーザーグループの見識と姿勢、サービス レベルの向上をユーザーに保証するために確立された SLA、および SLA 評価尺度と比較したパイロット実装の結果について検討します。法務政策企画統括 (Law and Corporate Affairs) ビジネス ユニット用の LOB アプリケーションの移行に関しては、比較を利用したケース スタディも紹介します。最後に、Virtual Server 2005 の今後の方向に対する洞察を述べてこのホワイト ペーパーを締めくくります。
Virtual Server 2005 の検討は、組織の総合的な目標および目的のフレームワーク内で行われます。組織の最終的な目標は、投資収益率 (ROI) または効果を表すその他の基準測定値を最大化することにあります。営利目的の企業は、短期的および長期的に、株主利益率を最大化することを追求しています。その目標を達成するために、組織の部署は個々の部署として、および全体として、日常業務の最適化を行い、コストとパフォーマンスのバランスをうまく保つことを目的とする必要があります。統合は、定義された目標の達成に向けて実施できる戦略の 1 つです。仮想化は、このソリューション フレームワークの階層内における戦術オプションで、Virtual Server 2005 はその具体的な製品ソリューションです。
Microsoft では、1999 年以来、自社の IT インフラストラクチャを統合することに焦点を当ててきました。統合によるコスト削減には、合計で 6 つの異なるアプローチを特定しています。これらのアプローチは、物理的なサイト、サーバー、データベース、アプリケーションとサービス、運用管理、および運用環境です。このホワイト ペーパーでは、統合とは複数の物理サーバーを 1 つの場所にグループ化することを指します。個々のビジネス ユニットやワークグループの開発者は自分が使用するアプリケーションやサービスを専用の部門・拠点 サーバーに配置する傾向がありますが、このような統合によって分散されたサーバーを大幅に削減できます。したがって、統合を実施することにより、運用効率と柔軟性が向上し、TCO が削減されます。
仮想化は、バーチャル マシン (VM) にアプリケーションやサービスを再ホストするプロセスを通じて、物理コンピュータからアプリケーションやサービスを取り除くことで、さらに多くの恩恵をもたらす統合技術です。多くのバーチャル マシンは 1 つのVirtual Server (VS) ホストに共存できます。したがって、仮想化は複数のアプリケーションやサーバーを 1 つの集中化された場所にグループ化するだけでなく、アプリケーションとサーバー間の一対一の関係を崩す役割も果たします。ただし、各 VM、および一部の実装における各アプリケーションやサービスは、個別のオペレーティング システムのインスタンスとして捉えられているオペレーティング システムに関連付けられているため、何らかの形で分離されています。仮想化では、ハードウェアについてほとんど気にすることなくアプリケーションを 1 つの物理コンピュータから別のコンピュータへと簡単に移動できるため、アプリケーションやサービスの機敏性を向上することができます。
従来、アプリケーション所有者は、LOB アプリケーションやサービスを専用のホストに配置していました。このようなホストでは、関連付けられているサーバー リソースを最大限に活用していない場合があります。仮想化に適したアプリケーションは、入出力 (I/O)、処理または計算、メモリ、およびネットワーキングの要件が低レベルから中レベルのアプリケーションです。サーバーのリソースには大きな負荷がかからないため、通常、サーバーの寿命は保証期間を超えるだけでなく、技術的なライフサイクルをも上回り技術的にサポート不能となることがあります。寿命の終わりまたは終わり近くまで物理システムを使用し続けると、保守の面においてコストが高くなり、アプリケーションを危険にさらす場合もあります。これは、システムが古いオペレーティング システムで実行されている場合に特に言えることです。
移行とは、アプリケーション サーバー用ソフトウェアおよびハードウェアのアーキテクチャの変更またはアップグレードを実施するプロセスです。必要に応じて、Virtual Server 2005 では複数のオペレーティング システムを 1 台の物理コンピュータに配置できるので、以前は互換性のなかった複数のアプリケーションを、互いに完全に分離した状態を保ちながら 1 つの場所で同時に実行することができます。ただし、最新の Windows オペレーティング システムに移行することをお勧めします。それによって、特に新しいハードウェア プラットフォームに展開した場合には、セキュリティ、可用性、および管理性が飛躍的に向上するためです。どちらのプロセスにおいても、統合および仮想化の鍵となるのは、ソリューションの評価、計画、設計、および実装を行うための標準移行プロセスを開発することです。
Microsoft では、Virtual Server 2005 で実行されるバーチャル マシンに物理サーバーを移行するための新しいツールを提供しています。Virtual Server 2005 Migration Toolkit (VSMT) は、Microsoft Automated Deployment Services (ADS) と連携し、移行元の サーバーのディスク イメージをキャプチャして、そのイメージを元のハードウェア構成が仮想的に構築された環境で再展開します。物理的な環境から仮想的な環境への従来の移行シナリオに加えて、VSMT では VMWare バーチャル マシンから、Microsoft Virtual Server に適した形式への移行もサポートしています。
Virtual Serverまたは VS とも呼ばれる Virtual Server 2005 は、Microsoft の仮想化ソリューションです。VS について理解するには、物理コンピュータ、ホスト、バーチャル マシン、Virtual Server、バーチャル ゲストなどの用語を理解している必要があります。
物理コンピュータは、物理的に独立したホスト コンピュータまたはマシンで、I/O、処理または計算、メモリ、ストレージ、ネットワーキングなどのリソースや機能を提供します。
Virtual Server (VS) ホストは、Virtual Server サービスをホスト (実行) する物理コンピュータです。1 つの VS ホストは、複数のバーチャル マシンを同時にホストできるサーバーです。必要に応じて、各 VM は異なるオペレーティング システムを実行することもできます。たとえば、1 つの Virtual Server 2005 ホストは、Windows Server™ 2003 を実行している 1 つの VM、Windows NT® 4.0 を実行している 1 つの VM、Windows 2000 Server™ を実行している 1 つの VM を同時にサポートできます。これらの各 VM は互いに完全に分離しています。
バーチャル ゲストとも呼ばれるバーチャル マシン (VM) は、Virtual Server サービスを実行している物理サーバー上でホストされている論理コンピュータです。オペレーティング システム、構成情報、および 1 つ以上のバーチャル ディスク ファイルで構成される VM は、I/O、プロセッサ、オペレーティング システム、メモリ、ストレージ、ネットワーク インターフェイス カード (NIC) またはネットワーク アダプタを含む完全な物理コンピュータをエミュレートします。1 つの VM には多数のアプリケーションやサービスが共存できます。図 1 に示すように、1 つの VS ホストには複数の VM が共存できます。

図 1: バーチャルゲストとして仮想化されている各物理サーバーが 1 台の物理バーチャルホストに共存している
VS の展開には 2 つの形態があります。1 つは自己ホスト型で、もう 1 つはユーティリティ ホスト型です。自己ホスト型は、アプリケーション所有者が物理ホスト サーバー、VS 構成、および関連する VM の割り当ても保有しているシナリオに属します。サーバーは、アプリケーション所有者の手元に配置することも、リモートのデータ センターに配置することもできます。どちらの場合にも、所有者が所有にまつわるすべての責任を担います。ユーティリティ型は、集中化されたグループが VS サービスをアプリケーション所有者に提供するように委託されているシナリオに属します。VS Utility (VSU) チームは、物理ホスト コンピュータおよび VS ソフトウェア構成を所有し、コンピュータ上に存在する各VM をアプリケーション所有者に代わって割り当てます。ユーザーは VM への管理アクセス権を保持しますが、集中化された物理コンピュータおよび VS ソフトウェア構成を管理する役割は、VSU に移ります。
Microsoft ではまず物理的な統合に焦点を当て、Virtual Server 2005 を使用した仮想化技術を利用してさらなる改善を行うための土台を築きました。Microsoft では、1999 年に自社の IT インフラストラクチャの統合に着手し始めました。これには、Windows 2000 Server、Microsoft Active Directory® ディレクトリ サービス、および Exchange Server 2000 の展開が含まれます。Microsoft では、組織が分散されているコンピューティング インフラストラクチャの統合を実現できるように、合計で 6 つの基本的なオプションを提供しています。
| • | 物理サイト : リソースが存在する物理的な場所の数を削減する。 |
| • | サーバー : 1 つの物理サイトまたは複数のサイトにまたがる特定のアプリケーション用個別サーバーの合計数を削減する。 |
| • | データベース : 複数のデータベースのデータを 1 つのリポジトリにまとめる。 |
| • | アプリケーションとサービス : 複数のアプリケーションとサービスを、より少数の共有サーバーにまとめる。 |
| • | 運用管理 : 運用管理技術者を、より少数の物理的な場所にグループ化して配置する。 |
| • | 運用環境 : 1 つのオペレーティング システムに使用しているバージョンの数を削減して標準化する。 |
TCO の削減は、これらの統合オプションの実装に最もふさわしい理由です。サーバーのハードウェアとソフトウェアのコストを削減することで、効率、生産性、および他のコスト上の恩恵が飛躍的に向上し、それが数字にも現れるためです。さらに、システム管理、監視、および保守に従事するスタッフの数も削減できるため、優秀な技術者にさらに高度な役割を与えることで、これらの技術者は組織に一段と貢献できるようになります。また、システムの柔軟性、信頼性、可用性、セキュリティ、およびパフォーマンスも向上します。
Microsoft では、サーバーおよびデータ センターを統合することで、1,830 万米ドルのコスト削減を実現しました (2004 年 6 月)。これは、統合前のレベルと比較して、40% の削減になります。その合計のうち 890 万ドルはサーバーの統合によって実現されたもので、これは LOB や他の分散サーバーの排除、および各支社におけるリモート サーバーと管理されていないサーバーの排除によるものです。
多くの点で、物理レベル (物理サイト、サーバー、および運営管理スタッフ) の統合プロセスはわかりやすい作業です。このレベルでは状況分析の一般的なプロセスが周到に行われ、ソリューション オプションが明確なため、統合作業はよく理解されています。論理レベルでの統合は、すべてではありませんが、ある程度は、概念および関連するプロセスやソリューションを模索する作業になります。Microsoft 社内での Virtual Server 2005 の初期の実装は、この 2 つの統合の隙間を埋める一方で、企業が運用上の大幅な利益と見なす結果を生み出すことを目的としていました。
Microsoft での Virtual Server 2005 の展開は、3 つのフェーズに分かれています。コンサルティング フェーズでは、VSU チームとユーザー候補の Business Unit IT (BUIT) 部門との間でコンサルティング関係を築きます。プロビジョニング(準備) フェーズは、仮想化の候補となるアプリケーションをスクリーニングし、適正検査用ホストでテストし、運用ホストに最終的に移行するプロセスです。運用フェーズは、VSU チームとアプリケーション所有者の責任および VSU の具体的なサービス内容に対応します。
Microsoft では、新しいテクノロジの開発と、サポートするアプリケーションやサービスに対して多大な投資を行っています。Microsoft は、これらのソリューションを社内でテストするだけでなく、最も厳しい要件を持つ最初のユーザーとしての役目も果たします。これらの新しいテクノロジを導入するにあたって、Microsoft の IT 部門では、他のお客様の場合と同じかそれよりも厳しい困難に直面します。多くの Microsoft 社員は、ソフトウェア開発、システムとネットワークの設計、実装、運用、および管理において豊富な経験を持っています。彼らは技術レベルが非常に高いため、システムやアプリケーション ソフトウェアを統合しようとする試みは、特にユーティリティ モデルが導入される場合には、綿密に調査され、抵抗に合う場合もあります。ただし、Microsoft のビジネス ユニットおよび個人ユーザーでも、他のお客様と同じような多くの懸念を抱いています。これらの懸念事項には次のようなものがあります。
| • | 柔軟性の損失 |
| • | 応答性の低下 |
| • | セキュリティの低下 |
| • | パフォーマンスの低下 |
| • | 制御力の損失 |
| • | 仕事の安定性の損失 |
各アプリケーション所有者がもつハードウェアを、彼らが個々にもつサーバーを物理的に取り除くことで、データ センターに統合することは非常に困難な作業でした。バーチャル マシンの作成のため、物理ハードウェアからサーバーを抽出する作業の方も、同程度に困難でした。
Virtual Server 2005 のパイロット実装への参加は任意としました。パイロット テストを実施するために、Compute Utility チームでは Microsoft BUIT チームおよびそれらの各チームが対応しているアプリケーション所有者の懸念に対処しました。パイロット テストのコンサルティング フェーズでは、ユーザー候補がアプリケーションおよびサーバーの要件を提出し、VSU チームがそれを分析しました。結果として得たプレゼンテーションでは、BUIT のコンピューティング、メモリ、およびネットワーキングの要件に加えて、最適な保守期間が検討されました。VSU チームでは、必要に応じて、たとえば固有の例外プロセスを含むカスタム ソリューションを開発しました。
パイロット テストの成功に不可欠な作業は、VS の概念的な利点を SLA に取り入れることでした。SLA は、従来の社内の BUIT パフォーマンスとの比較だけでなく、自己ホスト型の VS ソリューションと比較した場合にも、明確で有益なケースをユーザーに提示する必要があります。SLA は、VSU チームにとって現実的な課題となりました。表 1 に示すように、標準的な VSU の SLA は、高レベルでは、自己ホスト型よりもかなり優位に立っています。
| SLA のプロビジョニング | 自己ホスト型物理サーバー | Virtual Server ユーティリティ |
サーバーのプロビジョニング(準備) | 22 〜 25 日以下 | 1 日 |
ハードウェアの移動/追加/変更の予定日数 | 7 日以下 | 1 日 |
サポートの利用 | 年中無休 : | 年中無休 : |
ホストの可用性 | 該当なし | 99.99% アップタイム |
ゲストの可用性 | ハートビートのアクティブな監視 | ハートビートのアクティブな監視 |
ホスト CPU 利用率 : 平均 | 該当なし | 70% |
ホスト CPU 利用率 : 最大 | アクティブな監視 | アクティブな監視 |
ユーザーの要求に対する応答1 | 30 分 | 30 分 |
| 1 | 解決はユーザーの要求の性質と内容によって異なります。 |
SLA のプロビジョニング内容はすべて、BUIT 部門によって管理されている従来の社内ソリューションと比較して優位に立っています。サーバーのプロビジョニング(準備)期間にはかなりの差があり、従来の方法では物理的に独立したサーバーをプロビジョニング(準備)するのに通常 22 〜 25 営業日を要するのに対し、VSU チームによるプロビジョニング(準備)はわずか 1 営業日に設定されています。多くのプロビジョニング(準備)作業は自己ホスト型物理サーバー モードでは適用されないため、ほとんど比較になりません。Microsoft の IT ユーティリティ サービス部門のリード プログラム マネージャである Chad Lewis は、次のように述べています。「我々はこのテクノロジにあまりにも慣れ親しんだため、ソリューションはおのずから立証されているように感じることがありました。同時に、ユーザーの見識は大きく異なる場合があることも理解しています。新しいアプリケーション プラットフォームへの移行に対する自然な反発を克服するために、我々は SLA および課金モデルを作成し、ユーザーが物理サーバーとバーチャル ゲスト間の作業やコストの違いを直接比較できるようにしました。我々の実装は、全体を通じ、これらの 2 つの面で期待通りであるか、期待を上回るものとなっています。」
|
提供するユーティリティ サービスの内容を有益なものにするために、VSU チームではパフォーマンスを強化するだけでなく、資本コストと運用コストの両方の面でコストの削減を図る必要があることを認識していました。VM のコストは物理サーバーのコストよりもはるかに低いため、ユーティリティ モデルを使用するとアプリケーション所有者は資本支出を大幅に削減できます。さらに、アプリケーション所有者のコンピューティング要件が時間の経過と共に変化するにつれて、VSU によってプロビジョニング(準備)される特定の VM の容量またはVirtual Serverの数を拡大または縮小できます。実質的に、アプリケーション所有者は必要なものだけを、必要なときにのみ支払えばよい仕組みになっています。
また、サーバー ハードウェアの所有に伴う多くの諸経費や運用コストは VSU に移行されます。これにはたとえば、保守や修理、ラック スペースのレンタル、電力、保険、ネットワーク接続などのコストが含まれます。統合、仮想化、およびスケール メリットによって、約 20% のコストを削減できることが予想されました。詳細なコスト比較が、パイロット テストのコンサルティング フェーズで Baits およびアプリケーション所有者に提示されました。
VSU では、管理対象サービスに対し、初期の買い取りにかかる臨時費用と月次請求を組み合わせることで、割引額を回復することを計画しました。月次請求は詳細が明白で、簡単に理解できる形式であるため、VSU に対するコスト計算はサービス サブスクライバ向けに定期的に検証され、補強されました。
ユーザーが VSU にサービスを要求すると、構築プロセスが始まります。VM の構築プロセスは、物理サーバーの構築プロセスと実質的に同じで、あらゆる点において同じデータ センター標準が適用されます。また、初期のプロビジョニング(準備)の一環として、同じ管理ツールがインストールされます。主な違いはプロビジョニング(準備)期間にあります。VM では目標期間は 1 日であるのに対し、物理サーバーの従来のプロビジョニング(準備)期間は 22 〜 25 日にも及びます。物理サーバーのプロビジョニング(準備)には、時間のかかるハードウェア調達プロセス、梱包された箱からサーバー ラックに移動する物理的な構築プロセス、およびオペレーティング システム、アプリケーション ソフトウェア、ドライバ、監視ソフトウェアのインストールが含まれます。VM ではハードウェアの調達は不要で、物理的な構築作業もありません。必要なのはソフトウェアのインストールのみです。インストールする必要のあるカスタム OEM ドライバもないため、ソフトウェアのインストールは標準化が可能です。したがって、物理サーバーと比較して効率の高いインストールが可能になります。VS ホストで VM スロットが使用可能である場合、プロビジョニング(準備)作業の大半は、VM をホストで構成し、必要なファイルをコピーするだけになります。
VM プロビジョニング(準備) フェーズは複数の手順に分割されます。まず、候補になるアプリケーションをスクリーニングする必要があります。前述のように、Microsoft SQL Server、Microsoft Exchange Server、およびマルチプロセッサ ハードウェアを使用するように設計されている他のエンタープライズ向けの使用率の高いアプリケーションは、仮想化に適していない場合があります。
アプリケーションのスクリーニングが完了したら、Virtual Serverのパフォーマンスをテストする目的で設計されている適性検査用ホストに VM をインストールします。このインストールは、IT ラボでコードテストおよび機能テストが完了した後、運用ホストにインストールする前に行われます。適性検査用ホストは運用ホストと同等の機能を持っており、VM およびVirtual Server環境でサポートされているアプリケーションのパフォーマンスをテストする手段を提供します。また、VS ホストに対する影響を判断する手段も提供します。このため、所有者とユーティリティチームの双方が、最終的なソリューションに関して適切な評価を行うことができ、必要に応じて調整ができます。
適性検査テストの結果は、運用ホストへの VM の移行おいて、プロビジョニング(準備)上の決定を行う際に役立ちます。VM は基になるハードウェアから取り出されたものであるため、適性検査用ホストから運用ホストには完全で容易な移植ができます。現在、これらのホストは 4Px2.2GHz のマシンで構成されています。つまり、これらは 4 台のプロセッサで構成されるマシンで、各プロセッサは 2.2GHz のクロック速度で実行されています。VM の移植作業では、VM の停止および運用ホストへの構成ファイルのコピーを行い、準備を整えます。この作業は通常 1 時間以内で完了します。VM ゲストには、 2 つの一般的なカテゴリがあります。これらは標準とカスタムです。
| オプション/仕様 | 物理ホスト | VM: ホスト | ネットワーク接続VM ごとに、専用の NIC および最高 3.6 GB の追加の RAM をそれぞれ 1 回限りの追加料金により入手できます。 | RAMVM ごとに、専用の NIC および最高 3.6 GB の追加の RAM をそれぞれ 1 回限りの追加料金により入手できます。 | HD追加の SAN ハード ドライブ容量には、MB 単位の増分で追加の月次料金が加算されます。 |
標準 | 4Px2.2GHz | ≥ 8:1 | 共有銅ケーブル Gbps | 512 MB | 36 GB、SAN |
カスタム | 4Px2.2GHz | ≤ 8:1 | 共有銅ケーブル Gbps | ≥ 1532 MB | 36 GB、SAN |
| • | 標準の VM はホスト システムに対して比較的軽いリソース要求を行うものになります。カスタム プロセッサの割り当ては構成されず、RAM の割り当ておよび接続の要件は、既定の構成でまかなわれます。したがって、8 台以上の標準の VM が 1 つのホストを共有することもあります。VMへの移行の対象としては、特に EOW/EOL ハードウェアで利用されており使用率が低レベルから中レベルであることがわかっているレガシ アプリケーションや、負荷が低レベルから中レベルになるように指定されプロファイリングされている新しいアプリケーションが適しています。このようなアプリケーションの例としては、部門別の Web アプリケーションや LOB アプリケーションがあります。大部分のアプリケーションはこのカテゴリに属します。 |
| • | カスタム VM には、パフォーマンス レベルが保証されることが要求されます。これは、SLA 要件に正式に記述されているか、もしくはビジネス上の要求によるもののどちらかです。このパフォーマンス レベルでは、保証された容量を予約する必要があります。これは、1 台のプロセッサまたはそれと同等のものになります。したがって、4 台のプロセッサで構成される運用ホストは、通常 4 台以下のカスタム VM をサポートするように構成されます。高いパフォーマンス レベルを常に保証できるようにカスタム リソースの割り当てが構成されている場合には、VM とホストの比率を 4:1 よりも高くしたり、VM とプロセッサの比率を増加することもできます。カスタム VM の例には、ドメイン コントローラがあります。ドメイン コントローラはネットワークの運用に重要で、Active Directory を高い負荷で使用するためです。よく知られた既存のパフォーマンス要件を持つ特定のアプリケーションにもカスタム VM が必要です。 |
注 : Virtual Server 2005 は、Windows Server 2003 を実行する x86 互換性コンピュータで実行されている 32 ビットのアプリケーションです。Windows Server 2003 SP1 x64 Edition を実行する x64 互換性システム用バージョンは、Virtual Server 2005 R2 のリリースと共に、2005 年後半にリリースされる予定です。このバージョンは、現在 Microsoft で使用されているものです。Virtual Server 2005 は、最高 32 台のプロセッサと 64 GB の RAM をサポートしており、1 台の VM あたりの RAM は最高 3.6 GB です。Virtual Server 2005 では、物理コンピュータのネットワークおよびストレージ機能を使用します。これには付属の SAN (ストレージ エリア ネットワーク) ドライブが含まれます。
ユーティリティ モデルが効果的に機能するには、保有責任を明確に定義し、Virtual Server ホストとVMゲストそれぞれの責任を正確に区分する必要があります。Virtual Server ホストは、VSU チームと VM ゲストによって所有されます。VM ゲストは、VSU チームによって割り当てられますが、アプリケーションまたはサービスの所有者によって所有されます。
VSU 運用チームでは、これらのホスト上の VM ゲストの割り当てと構成に関し、VS ホストの監視、管理、保守、およびセキュリティのすべての面で責任を担います。VM のオペレーティング システムはネットワーク上の個別のオペレーティング システムのインスタンスであるため、アプリケーション所有者は、物理サーバーに対する責任と同じように、オペレーティング システムのセキュリティ構成と特定の他の管理機能の責任を担います。物理層の接続性やデータ センターの運用などのインフラストラクチャ上の問題は、主にデータ センター サービス チームの責任になります。Virtual Server ホストには、データ センター内の他の物理サーバーと同じレベルの一般的な運用サポートが提供されます。VS ホストで実行されるインフラストラクチャ作業は、VSU 運用チームによって手配および管理されます。ここでも他の物理サーバーと同じように、実際の作業はデータ センター サービスによって行われます。VS ホストおよび VM ゲストの状態に関するすべてのクライアント通信は、VSU 運用チームの責任になります。ゲストの CPU 可用性、サーバーの利用率、またはその他の SLA コンポーネントが SLA レベルを下回った場合、VSU 運用チームではその事実を識別し、適切なソリューションを得るためにユーザーと協力して作業を行います。
VSU 運用チームは VS ホストを監視し、これらのホストがデータ センターの標準を満たしているかどうかを確認します。ただし、割り当てられている VM がこれらの標準を満たしていることを保証するのは VM ゲスト所有者の役割です。
VSU チームでは、VS ホストのサポート管理と一般的な VM の構成に対し、集中化されたサービスを提供します。VSU のサービス要素は、コスト、パフォーマンス、機敏性、およびサービス管理で構成されています。
VM ゲストには 2 つのカテゴリがあります。これらのカテゴリは標準とカスタムです。標準の VM ゲストは、固定された量の CPU リソース、多くの RAM、または専用のネットワーク接続を必要としないアプリケーションに対する使用が最適です。カスタム VM ゲストでは、特定の保証された CPU パフォーマンス、多くの RAM、および専用接続のオプションを提供します。表 2 に、これら両方の基本的な仕様を示します。
標準ゲストとカスタム ゲストのどちらにおいても、VS ホストの資本コストの一部を負担するため、1 回限りの料金が課されます。毎月発生する料金は、ホストの月次ホスティング料金の一部と、VM ゲストの管理サービス料金を反映したものになります。どちらの場合でも、コストのそれぞれの内訳を比較した場合、3 年間で約 30% のコスト削減につながります。
注 : 標準 VM の月次料金にはホストの月次料金の 1/8 が含まれます。カスタム VM の月次料金にはホストの月次料金の 1/4 が含まれます。どちらの場合にも、月次料金にはゲストのオペレーティング システムの管理サービス料金の 80% が含まれます。物理ホストの資本コストには、3 年間の減価償却スケジュールが適用されます。
VM ゲストのパフォーマンスは、低レベルから中レベルの負荷の Web アプリケーションを使用してベンチマーク テストされています。各 VM ゲストには、1 台の物理 CPU と 512 MB の RAM が割り当てられています。パフォーマンスは、4Px700MHz Pentium® III (2 GB RAM) または 2Px1.26GHz Pentium® 4 (1 GB RAM) で実行されているアプリケーションと同等であるか、それを上回るものでした。パフォーマンスは 2:1 (ゲスト対プロセッサ) の比率では同程度でした。VS ゲストのパフォーマンスは、VS ホストに高い負荷がかかったときにのみ、低下し始めました。ベンチマーク テスト中は、カスタム リソースは割り当てられませんでした。
VSU では、機敏性が最大化されるように VM ゲストを設計しました。VS ホスト間でVM ゲストをすばやく移植できることは、ユーティリティ サービスの最大の利点となるためです。この機敏性により、VSU チームは VM ゲストをわずか 1 時間以内に適性検査用ホストから運用ホストへと移動できるようになるため、アプリケーション所有者から注文を受けてから 1 日以内に VS ゲストをプロビジョニング(準備)できるようになります。ゲストのパフォーマンスが任意の VS ホストで低下し始めたときに VSU チームで講じることのできる 1 つの対策は、所有者と協力してゲストを別のホストに移動することです。たとえば、図 2 に示すように、バーチャル ホスト ABC のパフォーマンスは、持続する CPU 使用率が 90% に達したときに低下し始めました。一方、バーチャル ホスト XYZ の CPU 使用率は 50% を維持しています。図 3 に、バーチャル ホスト ABC 上の VM1 の Web アプリケーション 1 を、バーチャル ホスト XYZ 上の割り当てられていない VM2 スロットに移動する作業を示します。この目的は、バーチャル ホスト ABC 上のパフォーマンスの問題を軽減し、両方のホストの負荷のバランスを取って、CPU 使用率がどちらにおいても 70% になるようにすることです。このプロセスに必要な合計時間は、パフォーマンスの問題を認識してから、Web アプリケーションの移動が完了するまで、通常 1 日以内です。ゲスト所有者との取り決めが完了すれば、VSU チームは実際の移動プロセスを 1 時間以内で完了できます。

図 2. サーバー 1 が 90% の使用率、サーバー 2 が 50% の使用率で実行されている 2 つの VS ホストシステム

サーバー DCCUVS01 からサーバー DCCUVS02 に VM Web アプリケーション 1 が移動される。サーバー DCCUVS01 の CPU 使用率は 70% に削減され、サーバー DCCUVS02 の使用率は 70% に増加する。
VSU チームは、VM ゲストの稼働状態を常に監視し、各ホストがデータ センターの標準に従って稼働していることを確認することで、VS ホストを管理します。標準から逸脱しているか、VS ホストまたは他の VM ゲストを危険にさらしているか、目的の作業以外のことを行っていることが検出された VM ゲストには、トラブル チケット エスカレーションが直ちに生成され、問題の発生しているゲストの所有者に通告すると共に、解決に必要な時間が設けられます。解決策が時間内に実装されず、そのゲストが VS ホストまたは他の VM ゲストを危険にさらしていると VSU 運用チームが判断した場合、VSU 運用チームはその VM ゲストを停止します。これらの解決策を組み合わせることで、99.99% のホストの可用性が保証されます。所有者による適切な管理が行われることを前提にすると、このようなホストの可用性の高さによって、VM ゲストの可用性も最高 99.99% にまで高められます。
VM とカスタム VM の両方に対する SLA の目標を達成するために、VSU チームでは次の 4 つのメカニズムを利用して CPU 使用率を管理します。
| • | 配置 : 初期のスクリーニング プロセスにより、アプリケーションが標準またはカスタムの VS ホストに最適であるかどうかが判断されます。適性検査用ホストでのパフォーマンス テストによって、VM およびアプリケーションを運用ホストに移動する前に配置が検証されます。 |
| • | 相対的な負荷 : 各ゲストには相対的な負荷が手動で割り当てられます。相対的な負荷が高いゲストは、別のゲストに CPU サイクルを要求できます。負荷の低いゲストは、要求を受けた場合、より高い負荷を持つゲストに CPU サイクルを解放します。 |
| • | 最大容量 : 各 VS ホストには限定された CPU 容量が割り当てられており、これは VM ゲスト間で共有されます。このため、各ゲストには使用可能な最大 CPU 容量が手動で割り当てられます。これは他のゲストの需要によって変化します。 |
| • | 各 VM ゲストには、他のゲストの需要にかかわらず、常に使用可能な任意の CPU 容量が手動で割り当てられています。 |
VSU チームとアプリケーション所有者間の通信は、早期に頻繁に行うことが奨励されています。SLA では、VSU チームがユーザーの要求を確認するまでの時間の目標を 30 分に定めています。要求の解決は、その内容に左右されます。たとえば、故障の修理に要する時間の目標は 30 分で、これは物理サーバーでもVirtual Serverでも同じです。VSU では、故障と修理および変更に関する既存の通信プロセスをモデル化する作業に取り組んでいます。一般的に、VM ゲストに関する通信内容は、物理サーバーに関するユーザーとの通信内容に非常に類似しています。
VSU チームでは、VM ゲストに影響が及ぶ可能性のあるすべての変更を、電子メールで所有者に通知します。綿密に確立されたエスカレーション ポリシーにより、重大な問題には適切なレベルでの対応が図られ、迅速な応答が返されることが保証されます。一般的な重大度の順に、例を示します。
| • | VS ホストがVM ゲストのパフォーマンスに悪影響を及ぼしている VS ホスト |
| • | VM の破損 |
| • | VS ソフトウェアが原因の問題 |
| • | ホスト上の複数の VM の停止 |
| • | VS ホストの停止 |
変更管理は重要なものです。すべての変更要求は、さまざまな変更ツールにより入力および追跡されます。VSU チームは、VS ホストの構成に対して予定されている変更を事前に VM ゲスト所有者に通知し、必要に応じて所有者がこれらの変更を確認し、意見を述べる機会を提供します。VSU チームでは、CPU 使用率、VS のホスト可用性、およびユーザーの満足度を監視して、変更が成功に終わったか、失敗したかを測定します。VM ゲストへの変更は、VS ホストを保護するために必要でない限り、所有者が要求した場合にのみ行われます。いずれの場合も、所有者は変更前に通知を受けます。
System Management Server (SMS) および Microsoft Operations Manager (MOM) では、データ センターの標準に従い、VS ホストとVirtual Serverを常に監視します。さらに VSU チームでは、SLA が危険にさらされていることを示す特定の兆候が VS ホストにないかどうかを監視し、そのような兆候が見つかった場合は所有者に直ちに警告します。そのような兆候を示すものには、CPU 使用率、ネットワーク I/O、Storage Utility (SU) ストレージ、ホストの可用性、VM ゲストの可用性などがあります。
VS ホスト システムでは、標準の OEM ハードウェア固有エージェントに加えて、Microsoft Systems Management Server と Microsoft Operations Manager のホスト エージェントの標準機能を利用できます。MOM 2005がスタンドアロンノードとして用意され、あわせてMOM 2005 Virtual Server Management Pack(MOM VS MP) がすべてのホストに配置されることで、Virtual Server API、パフォーマンス カウンタ、およびイベント ログによって提供されるVirtual Serverとバーチャル マシンの各要素を管理および監視する機能が強化されます。MOM VS MP の機能には、各ホストとそれにつらなるゲストのマッピングや、シャットダウン、起動、一時停止、保存などの 各VMの 状態制御があります。これらの機能には、主要なカウンタのパフォーマンスモニタリング、主要なVirtual Server、およびバーチャル マシンの イベントの収集が含まれます。
バーチャル マシンはゲスト オペレーティング システムからみればで一意のノードであり、各バーチャル マシンには独自の SMS、MOM、およびその他のハードウェア固有でない監視・管理エージェントまたはツールが備わっています。
Microsoft では、Microsoft 自体、および社内と社外のすべてのお客様にとって、セキュリティを最も重要なものとして捉えています。Microsoft では、セキュリティの脅威の重大さを考慮して、Microsoft の製品やネットワークの安全を確実に保護するために常に努力しています。Virtual Serverは、所有者が異なる個別のアプリケーションを 1 つのオペレーティング システムのインスタンスに統合した場合と比較して、セキュリティの面で優位に立っています。たとえば、8 つの個別のアプリケーションを 1 つのオペレーティング システムのインスタンスに統合する場合を考えて見ましょう。もしきめ細かなアクセス権を設定できない場合やオペレーティング システムへの管理アクセスが必要とされる場合には、これらのアプリケーションの 8 人の所有者全員は、ホスト システムや、配置されている他のアプリケーションに対する責任がなくても、すべてのアプリケーションにアクセスすることができます。また、そのオペレーティング システムのインスタンスにおいて、より多くのユーザーが複数の異なる用途にこのシステムを利用するようになるため、各アプリケーションの攻撃される確率は高くなります。一方、Virtual Serverを使用して 8 つのアプリケーションを 1 つの物理ホストに統合した場合、各アプリケーションは独自のオペレーティング システムのインスタンス、独自の固有な管理者、独自の IP アドレス、および固有の IPSec とグループ ポリシー ルールを持つようになります。各ゲストは、同じ物理ホスト上の残りの 7 つのゲストとは関係がない、独立したセキュリティ エンティティとなります。VM ゲストの所有者は、VM を管理するための次のようないくつかのツールにアクセスできます。
| • | Virtual Server Web Console は、認証された安全な管理、およびクライアントからのリモート アクセスを可能にします。 |
| • | Automated Deployment Services と Virtual Server Migration Toolkit の組み合わせ は、物理マシンからバーチャル マシンへの変換、および他社バーチャルマシンからの変換を行うコマンド ライン ツールを提供し、バーチャル マシン環境への移行作業を軽減します。 |
アプリケーションの独立性を維持しながら物理的な統合を実現することは、Virtual Serverに大きなセキュリティ上の利点をもたらし、攻撃を受ける確率を大幅に削減します。VS ホストについてはVSUチームがセキュリティ更新プログラムの適用を厳密に制御しているため、その厳密なパッチ管理がセキュリティをさらに向上させます。ゲストの修正プログラム適用に関しては所有者の責任ですが、VSU では所有者と密接に協力し合い、ゲストおよびホストの修正プログラム適用プロセスで高度な連携を図ります。VS Utility チームは、VS ホストおよびゲストがセキュリティで保護されていることを保証します。
Microsoft IT では、古いハードウェアで実行されているレガシ アプリケーションの統合にVirtual Serverを使用することで、セキュリティが強化されることを見い出しています。このようなハードウェアは予備の部品が簡単に入手できない場合があるため、保守のコストが高くなるか、保守が不可能なことがあります。この事実は、SLA のプロビジョニング(準備)、事前対策的な保守作業、および管理に関する取り決めを削減させることにつながり、システムがセキュリティの標準に従って保守されなくなる可能性が高くなります。ビジネスにとってまだ必要なシステムを、古くてサポートされていないハードウェア プラットフォームからバーチャル マシンに移動すれば、アプリケーションを完全なサポートが可能な環境に配置し、より高いレベルのサービスを提供できるようになります。これにより、セキュリティのレベルも向上します。
ゲストをセキュリティで保護するには、ホストをセキュリティで保護する必要があります。これは明らかなことです。したがって、Virtual Serverおよび VM 管理機能へのアクセスは、認証された安全な接続を使用して行う必要があります。VM 所有者には、VS ホスト オペレーティング システムまたは VS アプリケーションおよびインターフェイスへの管理アクセス権はありません。
各VM には固有のセキュリティ ID があり、IPSec ポリシー、Windows ファイアウォール ルール、ネットワーク接続されたサービスなどに関しては、ネットワーク上の "優等生" です。ネットワークに接続される VM は、その環境に適したセキュリティ標準に準拠する必要があります。各 VM の管理者は、自分の VM の構成にアクセスできますが、VS オペレーティング システムまたは他の VM にアクセスすることはできません。各 VM には独自のセキュリティ ID があり、固有のグループ ポリシーや必要とされるその他の特定の構成を適用できます。
データをバックアップし、消失や盗難から保護することも重要です。VSU チームでは、ホストが標準のデータ センター バックアップ ポリシーに従っていることを確認します。ただし、アプリケーション データごとのバックアップ スケジュールを作成するのは VM ゲストの所有者の役割になります。ファイルレベルのドライブのバックアップでは、すべての VM およびネットワーク ファイルをコピーします。すべての仮想ハード ディスク ファイルのストレージは SAN 上にあります。
Virtual Serverによってハードウェアからサーバーが抽出されるように、Storage Utility (SU) によってハードウェアからストレージが抽出されます。VM の構成を含むすべての仮想ハード ディスク ファイル ストレージは、実質的に無限の容量を持つ SAN 上にあります。VS ホストはデュアル光ファイバ ケーブルおよびスイッチで構成される冗長パスを経由して、SU ファブリックに接続されます。データのバックアップは、高い冗長性を持つ SU ファブリックの複数のディスクにストライピングされます。VM ゲストには既定では 36 GB のストレージがプロビジョニング(準備)されますが、必要に応じて追加のストレージも利用できます。VS ホストおよびそのホスト上の VM 全体に障害が発生した場合、SAN ではこれらをサポートする新しい物理サーバーをわずか数分以内にプロビジョニング(準備)して、完全に復元することを可能にします。

VM 構成および仮想ハードディスクファイルが SAN 上にある、バーチャルマシンを実行しているVirtual Serverホストシステム
Virtual Server 2005 パイロット テストの早期の段階において、Compute Utility チームでは、Law and Corporate Affairs IT (LCAIT) と話し合い、既存の業務上重要なアプリケーションに VM を利用することを検討しました。これらの話し合いの結果、候補となるアプリケーションとして特定の内部ツールが選定されました。このツールは、システム内の中間層として実行され、法的書類へのアクセスの提供および管理に関するタスクを処理します。このアプリケーションは、ドキュメントの読み込み、グループ化、注釈の追加、検索、確認、印刷などの機能を実行します。このツールは複数のインスタンスが必要となるように設計されています。各インスタンスはそれぞれ別個のオペレーティング システム内にあり、一意の ID を保持します。このアプリケーションには高レベルの可用性が必要ですが、比較的古いハードウェアでの簡素な構成においても、リソース不足による制限は受けていませんでした。このツールは VS ホスト環境への移行に最適であるように思われました。
アプリケーション ツールは、データ センター #1 にある、寿命に近づいている 15 台のシステムで利用されており、これらのシステムは数か月以内にデータ センター #2 への移行が予定されていました。サーバーごとの IT 関連作業に必要な移行費用は約 900 ドルが予定されていました。LCAIP および Compute Utility チームが仮想環境に移行するアプリケーションを評価することで合意に達した後、VSU 適正検査用サーバー上に 3 台の VM が作成および構成されました。LCAIT チームでは約 3 週間のパフォーマンス テストを実施し、良好な結果を得ました。この結果に基づいて、これらのチームでは VSU チームが管理している複数の VS ホストにまたがる運用バーチャル マシンにアプリケーションを再展開することを決定しました。
展開後、このソリューションは LCAIT チームの期待に応え、さらにその期待を上回るものとなりました。LCAが期待していたこととは、15 台のスタンドアロン ユーティリティ サーバーを購入する代わりに共有の VS ホストを購入し、かつ管理の複雑性をいっさい増やさないことで、資本コストを 33,400 ドル削減することでした。加えて、物理サーバーの代わりに VM を利用することで、今後ホスト費用を年間約 8,800 ドル削減できます。Microsoft IT にとっては、15 台の古くなったサーバーの再配置を回避することで、13,500 ドル以上を削減でき、またこれらのシステムを維持した場合に引き続き必要とされたであろう保守コストを削減できました。、仮想化に関連するコスト削減に加えて、LCAIT では処理能力とスケーラビリティを向上できるだけでなく、ハードウェアの寿命サイクルに関する懸念を排除できます。共有 SAN SU のセキュリティは、スタンドアロンの SAN と同等のものであると見なされています。あらゆる評価尺度において、ユーティリティチームのSLA は、BUIT がスタンドアロンの自己ホスト型サーバーとして提供できるパフォーマンスと同等またはそれ以上のものを約束しています。Microsoft IT では SLA を法的に有効な契約として取り扱うため、ユーザーの期待は高いものになります。
Microsoft 社内でのVirtual Serverの実際の実装結果は、ベースラインとして自己ホスト型物理サーバーでの実績との比較、そしてVSU に設定されている初期目標との比較で検証するのが最適です。表 3 は、主要な SLA のプロビジョンに関するこのような見方を示しています。
| SLA プロビジョン | 結果 : 自己ホスト型物理サーバー | 目標 : Virtual Server ユーティリティ (標準) | 実績 : Virtual Server ユーティリティ (標準) |
サーバープロビジョニング(準備) | 22 〜 25 日以下 | 1 日 | 1 日以下 |
ハードウェアの | 7 日以下 | 1 日 | 1 日以下 |
サポートの利用 | 年中無休 : | 年中無休 : | 年中無休 : |
ホストの可用性 | 該当なし | 99.99% アップタイム | 99.99% アップタイム |
ゲストの可用性 | ハートビートのアクティブな監視 | ハートビートのアクティブな監視 | ハートビートのアクティブな監視 |
ホスト CPU 利用率 : 平均 | 該当なし | 70% アクティブな監視 | 20% アクティブな監視 |
ホスト CPU 利用率 : 最大 | アクティブな監視 | アクティブな監視 | アクティブな監視 |
ユーザーの要求に対する応答1 | 30 分 | 30 分 | 30 分 |
コスト | 該当なし | 20% のコスト削減 | 最高 30% のコスト削減 |
| 1 | 解決はユーザーの要求の性質と内容によって異なります。 |
SLA の比較 : 自己ホスト型物理サーバーとVirtual Serverユーティリティ
全体的に、Microsoft における VSU の試用実績は、ほとんど予想通りであり、意図的にハードルを高くした SLA のあらゆる評価尺度を満たしているか、それを上回るものでした。VS のパフォーマンスは非常に良好であったため、最初は 70% を目標にしていた平均ホスト CPU 使用率は、現在では平均 VS ホストではわずか 20% となっています。その結果、VSU チームは予測を調整し、候補となるアプリケーションの適正レベルをそれに合わせて変更することにしました。
重要な基準測定値には、コストとユーザーの満足度があります。コスト削減は予測を上回るものでした。VSU チームは、45% を超える資本コストの削減を実現しました。これは、ビジネス ユニットにとって、最初に予想した 20% のコスト削減を上回り、約 30% の削減となりました。ユーザーの満足度の測定値は、一対一のケースバイケースに基づくもので、これは非常に良好でした。一部のユーザーは、このサービスが非常に優れたもので、仮想環境であるとはわからないほどだ(transparent)と述べています。これは事例証拠ですが、VSU チームでは仮想化のこの透過的な特性を高い賞賛として受け止めています。パイロット実装の規模は、ユーザーの満足度の事例測定値を許容可能なものと見なすに十分なものでしたが、結論が出された直後には自動発券システムがサービスに導入されています。このシステムには、ユーザーの満足度の自動アンケート調査が関連付けられています。
Virtual Server 2005 は、高レベルのスケーラビリティを備えたソリューションとして設計されており、Microsoft の VSU による実装では、性能の高い VS ホストを使用することで、さらなるコストの削減を実現します。Virtual Server 2005 の現在の仕様では、最高 32 基のプロセッサと最高 64 GB の RAM を搭載したマルチコア コンピュータをサポートし、1 台の VM あたりの RAM は最高 3.6 GB となっています。64 ビット コンピュータおよび Windows Server 2003 x64 Edition オペレーティング システムのサポートは、Virtual Server 2005 R2 のリリースと共に、2005 年後半に予定されています。このパイロット テストでは、平均 CPU 使用率が約 70% に達することを予想して、4Px2.2GHz のマシンにおけるホストの統合比率を意図的に 8:1 に制限しています。結果の分析により、ホスト使用率の目標が過度に保守的であったこと、パフォーマンスを損なわずに VM 対ホストの統合比率を増加する余裕が十分あることが明確になりました。ハードウェア製品の容量は増加し続けており、VM 対ホストの統合比率はさらに改善することが可能になるでしょう。これにより効率が向上し、さらなるコストの削減へとつながっていきます。
自動化されたプロビジョニング(準備)、発券、および変更管理システムの今後の開発には、ユーザー インターフェイスが含まれます。VSU インターフェイスは Outlook での会議のスケジュールのように、直感的なものになることが予定されています。アプリケーション所有者は、VS ホスト群に対するビューが必要になります。それによって、任意の VM 上のパフォーマンス統計を表示および収集し、ホストの所有者によって定義されているルールの設定に基づいて構成を変更し、VM を停止し、最終的にはプロビジョンすることができるようになります。現在 VSU では、近い将来データ センターの 10% を仮想化することを計画しています。長期的には、仮想化によって IT 戦略が大幅に変化することが予想されます。IT を中心とした組織にとって、それはコア ビジネス戦略の変化を意味します。
Microsoft では、Windows 2000 Server、Microsoft Active Directory ディレクトリ サービス、および Exchange Server 2000 を有効なソリューションとして展開することで、自社の物理的な IT インフラストラクチャを統合する作業に数年前に着手しました。仮想化は、Virtual Server 2005 の開発と共に、統合の進行過程における次の論理的なステップとして登場しました。新しいサーバーやビジネス プロダクティビティ ソフトウェアをリリースする場合と同様に、Microsoft IT は Virtual Server 2005 の最初のユーザーとしての役割を果たしました。Micosoft IT の要件は世界でも最も厳しいレベルにあり、このパイロット実装がVirtual Server の機能を綿密にテストする絶好な機会とされることが意図されました。また、Microsoft IT が採用した手段や最初の経験から学んだことは、今後の一般向けリリースの実装において、お客様に非常に役に立つ展開と運用のガイダンスを提供することが期待されました。
Microsoft IT 部門は、Compute (演算)、Storage (ストレージ)、Data Protection (データ保護) のユーティリティで構成されるユーティリティ モデルの各ラインに従って編成されています。Compute Utility 内では、VSU は Virtual Server 2005 を集中化された管理サービスとして社内の Microsoft のユーザーに提供します。
社内のアプリケーション所有者の参加、および彼らにサービスを提供しているBUIT の参加を募るにあたって、ユーティリティ モデルへ移行する上での明確で有益なケースを構築する SLA 評価尺度を開発する必要がありました。これらの評価尺度には、サーバーのプロビジョニング(準備)にかかる時間、サポート利用の可否、ホストの可用性、ゲストの可用性、およびホストの CPU 使用率が含まれています。もちろん、基準測定値となったのはコスト削減とユーザーの満足度で、これらはあらゆるカテゴリにおいて期待通りであるか、期待を上回るものとなりました。今後 Microsoft が発展を遂げるには、さらに効率を向上し、コストを削減することが可能な能力の高い物理ホストを導入する必要があります。プロビジョニング(準備)、発券、および変更管理の各システムにおける強化には、直感的なユーザー インターフェイスが含まれます。このインターフェイスによって、制御手段は所有者の手に委ねられます。
World Wide Web 上の情報については、次のアドレスにアクセスしてください。
http://www.microsoft.com/japan/
http://www.microsoft.com/japan/showcase/
このドキュメントに関するご質問、ご意見、またはご提案をお寄せいただく場合、または「How Microsoft Does It」(英語) に関する詳細については、次のアドレスまで電子メールをお送りください。
showcase@microsoft.com (英語のみ)
Microsoft Virtual Server 2005 ホーム ページ
Solution Accelerator for Consolidating and Migrating LOB Applications (英語)
Deploying a Worldwide Site Consolidation Solution for Exchange Server 2003 at Microsoft (英語)
Windows Server System Reference Architecture (英語)
このドキュメントに記載されている情報は、このドキュメントの発行時点における Microsoft Corporation の見解を反映したものです。変化する市場状況に対応する必要があるため、このドキュメントは、記載された内容の実現に関する Microsoft の確約とは見なされないものとします。また、発行以降に発表される情報の正確性に関して、Microsoft はいかなる保証もいたしません。
このホワイト ペーパーに記載された内容は情報提供のみを目的としており、明示または黙示に関わらず、これらの情報について Microsoft はいかなる法律上の責任も負わないものとします。
お客様ご自身の責任において、適用されるすべての著作権関連法規に従ったご使用を願います。Microsoft では、個人の教育目的のみに対して、このホワイト ペーパーの一部または全体を複製する権利をユーザーに授与します。
Microsoft は、このドキュメントに記載されている内容に関し、特許、特許申請、商標、著作権、またはその他の無体財産権を有する場合があります。別途 Microsoft のライセンス契約上に明示の規定のない限り、このドキュメントはこれらの特許、商標、著作権、またはその他の無体財産権に関する権利をお客様に許諾するものではありません。