Citrix XenAppをHP ProLiantサーバー上の

XenServerに配備するためのベストプラクティス

テクニカルホワイトペーパー

目次

エグゼクティブサマリー .......................................................................................................................... 2

投資対効果の検討 ............................................................................................................................... 2

仮想化の概要 ...................................................................................................................................... 3メリット ............................................................................................................................................ 4XenAppを仮想化する理由 ................................................................................................................. 4

パフォーマンステスト ............................................................................................................................. 5概要 ............................................................................................................................................... 5テストの結果 .................................................................................................................................... 8

ベストプラクティス ................................................................................................................................. 964ビット環境への移行可能性の検討 ................................................................................................... 9適したプラットフォームのみの仮想化 .................................................................................................. 10コストの考慮 .................................................................................................................................. 11vCPUの過剰割り当ての回避 ............................................................................................................ 11CPUリソースのフル活用 ................................................................................................................... 12プロセッサー使用率急増の防止 ........................................................................................................ 14各VMへの十分なメモリの割り当て ..................................................................................................... 15ライトキャッシュの使用 ..................................................................................................................... 19ネットワークパフォーマンスの監視 ..................................................................................................... 20可用性の強化 ................................................................................................................................ 20VMの配分の均一化 ........................................................................................................................ 21リソース使用率の最大化 .................................................................................................................. 21XenServerカーネルの最適化 ............................................................................................................ 21管理性の強化 ................................................................................................................................ 21

最新4Pサーバーのスケーラビリティの強化 ............................................................................................. 22ベアメタル64ビットプラットフォーム ..................................................................................................... 2232ビットプラットフォーム ................................................................................................................... 25

統合の例 .......................................................................................................................................... 28

付録A – テスト ................................................................................................................................... 31テストツール .................................................................................................................................. 31ユーザープロファイル ...................................................................................................................... 32テスト手順 ..................................................................................................................................... 32テストのトポロジ ............................................................................................................................. 34

詳細情報の入手先 ............................................................................................................................. 35

2

エグゼクティブサマリー 最初のハイパーバイザーが市場に登場して以来、企業は、使用率の低いサーバーを単一の物理マシンに統合すること

に取り組んできました。初期の実装は、仮想化のオーバーヘッドによってパフォーマンスが大幅に低下したために、期待

を裏切る結果になりましたが、その後、技術は大幅に進歩しました。現在のAMD Opteron™プロセッサーおよびインテ

ル®Xeon®

その一方で、企業は、限られたメモリアドレス指定能力のために、サポートできるユーザー数が本質的に制限されてい

る非仮想化x86プラットフォームを配備しつづけています。64ビットプラットフォームに移行しないという決断は、多くの

場合、ドライバーやアプリケーションに互換性がないために、移行に非常に大きなコストがかかることが、その根拠と

なっています。仮想化は、32ビットプラットフォームのこれまでにないレベルの拡張を可能にすることで、このジレンマに

対する実現可能なソリューションを提供します。

プロセッサーは、ハイパーバイザーからの直接ハードウェアコールを処理するオンチップ命令を提供することで、

関連オーバーヘッドを最小限に抑えます。この結果、仮想マシン（VM）のスケーラビリティが大幅に向上しています。

このホワイトペーパーでは、Citrix XenServerを使用して32ビットワークロードを32ビットと64ビットの両方のMicrosoft® Windows®

対象読者： このホワイトペーパーは、仮想化に関心を持つIT専門家のための情報を提供するものです。

プラットフォームに統合する多数の選択肢を検討するとともに、XenServer環境でのCitrix XenAppの仮想化

に関するベストプラクティス、調整、およびヒントを詳しく説明します。

このホワイトペーパーでは、2008年7月～2010年8月に実施されたテストについて説明しています。

投資対効果の検討 小規模の企業であっても、支所や支店またはデータセンターであっても、同一サーバー上で正常に共存させることがで

きない複数のアプリケーションをサポートしなければならないという同じ課題を抱えています。しかし、単一のアプリケー

ションによって、現在のHP ProLiantサーバーのいずれかに搭載されているマルチコアプロセッサーが過負荷状態にな

ることはあまり考えられません。つまり、サーバーを特定のアプリケーション専用に使用することは、貴重なリソースの

無駄遣いとなります。さらに、使用している環境によっては、ファイアウォール、DNS（Domain Name System）/DHCP（Dynamic Host Configuration Protocol）サーバー、仮想デスクトップ、デスクトップアプリケーションサーバー、Webサーバー、またはメールサーバーとして機能するインフラストラクチャサーバーが必要になる場合もあります。今後、こ

れらの機能のそれぞれに専用の物理サーバーを用意することは現実的ではありません。

同じ問題の別面として、古いソフトウェアおよびオペレーティングシステムを、旧式の（多くの場合は役に立たなくなって

いたり修理が困難になっていたりする）ハードウェアからより新しいサーバーに移行させなければならない場合がありま

す。新しいハードウェアは、比較的古いオペレーティングシステムやアプリケーションをサポートできない場合がありま

すが、その代わりにハードウェアとアプリケーションの両方を更新しようとすると、多大なコストがかかり、エラーが発生

する可能性も高まります。仮想化は、リソースの使用率を改善し、必要な物理サーバーの台数を統合によって減少させ

るため、これらの問題を解決するひとつの方法となります。

XenAppのユーザーは、一般に、全体的なコストを削減する方法を求めています。XenApp環境では、サーバーの電力

および冷却コストが高く、それらのコストは、ITインフラストラクチャコストのかなりの部分（最大部分ではないとしても）を

占めます。実際、ますます多くの調査によって、サーバーハードウェアがもはやデータセンター関連の最大の支出では

ないことが示されています。たとえば、新しい1Uサーバーについては、すでに、サーバーの維持に必要な電力および冷

却インフラストラクチャの資本コストがサーバーの購入価格を上回っており、近いうちに製品寿命全体のエネルギーコ

ストも購入価格を上回る可能性があります。この結果、消費電力が、HPのサーバーの購入を検討する企業の主要な関

心事になっています。多くの企業が、パフォーマンスを犠牲にすることなく、全体的な電力コストを削減したいと考えてい

ます。これは、従来は達成不可能な目標でしたが、HPが最近実施したパフォーマンス特性評価では、パフォーマンスと

消費電力の両立が可能であることが示されました。

3

現在では、仮想化により、ホストマシンで利用できるメモリ、CPU、およびディスクスペースに応じて、サポートしたい特

定のアプリケーションについて、複数のアプリケーションを1台のHP ProLiantサーバーに統合できます。さらに、厄介な

比較的古いオペレーティングシステムを実行するようにVMを設定することもできます。

統合に加えて、ハードウェアの仮想化には、一般に次のようなメリットがあります。

• VMが隔離され、特定のハードウェアリソースを使用するようにVMを設定できる

• VMのコピーと配備が容易であり、サービスを中断することなく物理マシン間でVMを移動できる

• VMを集中管理できる

仮想化の概要 Citrix社の仮想化ソリューションであるXenServerは、インテルバーチャライゼーション・テクノロジー（VT）とAMD Virtualization™（AMD-V™）の両方の機能をサポートするオープンソース仮想化プロジェクトのXenをベースとしていま

す。Xenにより、単一のマシンで、複数の隔離された環境を提供し、それぞれの環境でオペレーティングシステムとアプ

リケーションソフトウェアインスタンスを実行することができます。

2004年に、Xenプロジェクトは、仮想化プラットフォーム（ハイパーバイザー）の最初のバージョンをリリースしました。翌

年、プロジェクトの創始メンバーがXenSource社を設立し、後に同社からXenServerやXenEnterpriseなどの製品が発表

されました。2007年に、Citrix社がXenSource社を買収し、これらの製品名がXenServer Standard Editionおよび

XenServer Enterprise Editionに変更されました。

ハイパーバイザーは、パーティション（ドメイン）の管理、ドメインへのVMのインスタンス化、およびドメインのリソース

のスケジューリングと割り当てを担当する層です。一部の仮想化環境では、基盤となるハイパーバイザーがすべての

システムコンポーネントをエミュレートできるので、ゲストは環境が仮想化されていることを認識しません。I/Oコール

およびその他の権限付与されている要求は、ゲストによって通常どおりに実行されますが、基盤となるハイパーバイ

ザーによってトラップされ、エミュレートされる必要があるため、パフォーマンスが低下します。この方式は、多くの場合、

「完全仮想化」と呼ばれます。

第1世代のハイパーバイザーはエミュレーションテクノロジーに依存してオペレーティングシステムを仮想化していまし

たが、Xenは、オペレーティングシステムおよびCPUテクノロジーの進歩を利用して、準仮想化およびハードウェア補助

による仮想化を提供するとともに、64ビットを完全にサポートしています。

準仮想化では、オペレーティングシステムが、仮想化されたI/Oサービスやハイパーバイザーによってサポートされるそ

の他の権限付与された操作を直接コールできるように変更され、リソースを大量に消費するバイナリトランスレーションお

よびエミュレーションが不要になっています。ストレージおよびネットワークインターフェイスカード（NIC）のドライバーは、

ホストドメインを介して高速I/Oチャネルを提供する仮想化対応ドライバーに置き換えられ、優れたゲストI/Oパフォーマ

ンスが実現されます。

仮想化に対応していないオペレーティングシステムをXenとともに使用することもできますが、これらのオペレーティング

システムは、仮想化を補助するプロセッサー拡張機能に依存します。ハードウェア補助によるドメインがXen上で機能す

るには、基盤となるハードウェアがインテルVTまたはAMD-V対応であり、その機能がハードウェアで有効になっている

必要があります。現行のすべてのHP ProLiantサーバーは、32ビットまたは64ビット環境におけるハードウェア補助によ

る仮想化をサポートしています。

4

注： 仮想化のハードウェア補助は、一部のHP ProLiantサーバー・モデルではデフォ

ルトで無効になっている場合があります。この機能を有効にするには、『HP ROMベース セットアップ ユーティリティ ユーザー ガイド』を参照してください。 ファームウェアを更新すると、これらの設定はデフォルト値に戻ります。

メリット 仮想化には、以下のようなメリットがあります。

• サーバーの使用率の改善 データセンターのサーバーの平均使用率は5～10%1

使用率の低いサーバーおよびアプリケーションサイロを統合することにより、ITリソースの使用率を最大化し、環境保

全（グリーン）イニシアチブに準拠することができます。

程度である可能性があり、インフラストラクチャサーバー（DNS（Domain Name System）またはMicrosoft Active Directoryコントローラーなど）やその他の使用率の低いマシンは

統合の非常に有力な候補となります。

• ビジネス継続ソリューション 多大なコストのかかる物理マシンのクラスターは、一般に、単一のサーバーが使用不能になる場合のリスクを最小

限に抑えるために使用されます。しかし、仮想化によって、単一クラスター上の複数のアプリケーションに対してフェ

イルオーバーとリダンダンシが実現され、このクラスターを構成するマシンが同一に設定される必要もなくなります。

これらのサーバーのプロビジョニングは、容易であり、柔軟性があります。

• ディザスタリカバリソリューション

ひとつの事業所またはデータセンター全体が使用不能になる場合のリスクの解消を容易にするために、VMを別の

サイトにほぼリアルタイムで複製することができます。

• 動的なワークロード管理

VMを使用することにより、VMを移動させて需要の急増に対応し、動的なワークロード管理をサポートすることができ

ます。

• 管理の柔軟性の向上 VMは、データセンターの自動化レベルを向上させるために役立ちます。管理API（Application Programming Interface）によるスクリプトおよびプログラムの公開により、管理の柔軟性が向上します。

XenAppを仮想化する理由 XenAppを通じてアプリケーションをユーザーに提供するメリットについては実績がありますが、XenApp配備の規模や

複雑さの増大によって、投資回収率を大幅に改善できる機会が生まれています。

1 『DataCenter Journal』（2009年3月12日）

5

XenServer上のXenAppには、以下のようなメリットがあります。

• サーバー/データセンターの設置面積の縮小 サーバーの統合により、データセンターに必要な物理サーバーの台数を減らすことができます（「統合の例」を参照）。

XenServerを使用すると、複数のアプリケーションを（これらのアプリケーションが非仮想化環境では互換性がない場

合でも）同じサーバーに配備することができます。

• フェイルオーバーおよびリダンダンシの改善 非仮想化環境では、しばしば、アプリケーション固有のリダンダンシおよびフェイルオーバーを簡素化するためにサイ

ロが作成されますが、これによって、通常、大量の未使用容量が発生します。物理サーバーの設置面積を減らしつ

つ可用性に関するリダンダンシのメリットを保持するために、使用率の低いXenAppサーバーを仮想化することがで

きます。

• ゼロダウンタイムのハードウェアメンテナンス 非仮想化環境では、通常、ハードウェアのメンテナンスによってアプリケーションの可用性が低下します。サーバー

の電源を切って、障害の発生したハードウェアや古くなったハードウェアを交換できるように、通常、メンテナンスは、

業務時間外にスケジューリングする必要があります。

しかし、XenServerのXenMotion機能を使用すると、稼動中のVMを、サービスを中断することなく物理サーバー間で

移動させることができるため、ゼロダウンタイムのメンテナンスがサポートされます。

• サーバー、アプリケーション、および容量の迅速なプロビジョニング 非仮想化環境では、XenApp容量を手動で増やすために数時間、場合によっては数日間もかかることがあります。し

かし、XenServerを使用する場合、XenAppがプリインストールされたVMをテンプレートに変換しておき、リソースプー

ルと組み合わせて、迅速なプロビジョニングのために使用することができます。

• 迅速かつ容易でポータブルなテストおよびデモンストレーション環境 テスト、デモンストレーション、およびトレーニング環境を作成するためのハードウェアの必要性を正当化できない場

合は、XenServerを使用して、実務環境のコピーを提供することができます。この結果、アプリケーション、ホットフィッ

クス、および設定の変更の品質と影響を、実務環境に適用する前にテストすることができます。さらに、組織全体に

新しいサービスやアプリケーションを導入するために、完全でポータブルなトレーニングおよびデモンストレーション

環境を作成することができます。

パフォーマンステスト HPでは、32および64ビットXenApp環境に配備される仮想化されたHP ProLiantサーバーのスケーラビリティを比較す

るために設計された多数のパフォーマンス特性評価を実施しました。基準値を提供するために、ベアメタル構成もテス

トしました。

テストした構成とテスト環境について詳しくは、「付録A - テスト」を参照してください。

概要 HPは、テストするサーバーのワークロードについて、Microsoft Office 2003ベースの「ヘビーユーザー」プロファイルを

ベースとしました。ヘビーユーザー（「構造化タスクワーカー」とも呼ばれる）は、複数のアプリケーションを同時に開き、

長時間にわたってアクティブなままにする傾向があります。これらのユーザーは、使用していないアプリケーションも、し

ばしば、開いたままにします。

スケーラビリティの特性を評価するために、次の基準に焦点を合わせました。

• Windowsパフォーマンスモニター（Perfmon）によって報告されるシステムパフォーマンス

• カナリアスクリプトによって測定されるユーザー応答時間

6

理想としては、仮想化環境と非仮想化環境の両方でまったく同じツールを使用してパフォーマンスの特性を評価するこ

とが望まれます。しかし、仮想化環境では幅広い離散データ値2

ベアメタルサーバー用に確立された方法論からのこれらの逸脱はあるとしても、HPでは、仮想化されたサーバーの測

定基準における誤差の範囲が10%未満であると予測しています。

が生成されるため、離散値よりも移動平均の使用を選

択しました。また、VMによって生成される大量のパフォーマンスデータを収集するカスタムツールも開発しました。

注： VMのパフォーマンスを監視するためのひとつの選択肢は、ラウンドロビンデー

タベース（RRD）の使用です。XenServerは、持続的なパフォーマンス測定基準

をRRDに記録してこのデータへの長期アクセスを提供し、履歴傾向の分析をサ

ポートします。RRDは、ホストサーバーとVMについて保持されます。詳しくは、

HPのホワイトペーパー『Analyzing Citrix XenServer persistent performance metrics from Round Robin Database logs』を参照してください。

一般に、80%のプロセッサー使用率は、クリティカルパフォーマンススレッショルドと考えられており、通常、特定のサー

バー構成によってサポートされる最適ユーザー数を指定するためにこの基準が利用されます。しかし、プロセッサー使

用率は、テストの実行時に必ずしも80%に達するわけではありません。そのような場合、HPでは、Perfmonの結果を分

析してスケーラビリティが制限された要因を判断します。たとえば、ベアメタル32ビットプラットフォームをテストしている

場合、スケーラビリティは、システム ページ テーブル エントリー（PTE）の不足によって制限される傾向があります。

関連カナリアスクリプトの結果を使用して、「Perfmonによって示される最適ユーザー数を超えていないときには応答時

間が許容可能であった」ことを確認します。ただし、80%のスレッショルドに達する前にユーザー応答時間がすでに許容

不可能になっている場合は、応答時間の低下が始まる直前にサポートされた最適ユーザー数を受け入れます。

サンプルテストの結果を図1に示します。

2 リンギング（つまり、プロセッサー使用率の値の大幅な振幅）による

7

図1. この64ビットHP ProLiant BL685c G6プラットフォームについて、ユーザー数が500（最適数）を超えない場合に応答時間が許容

可能であったことを示すサンプルテストの結果

テストの方法論について詳しくは、「付録A - テスト」を参照してください。

8

テストの結果 この項では、仮想化された32ビットおよび64ビットプラットフォームのテストの結果を示します。

表1. 一連の仮想化されたHP ProLiantサーバーによってサポートされる最適ユーザー数

サーバーモデル コア数 64ビットプラットフォーム 32ビットプラットフォーム

構成 ユーザー

数 オーバー

ヘッド 構成 ユーザー

数 統合率

DL380 G7 24 * 6/4 680 5.0

DL585 G5 16 4/43 242 16%

DL785 G5 32 8/4 430 3%

BL460c G6 16* 4/4 340 16% 4/4 401 2.7

Bl465c G5 8 4/2 139 10%

G6 12 6/2 360 0% 6/2 378 2.1

G6（i） 12 6/2 303 0%

G7 24 6/4 645 4.6

BL680c G5 24 6/4 291 25% 6/4 483 3.5

BL685c G6（ii） 16 4/4 404 2%

G6（iii） 24 6/4 500 0%

G7（i） 32 8/4 731 （iv）

(i) 低電力プロセッサー (ii) 4コアプロセッサー (iii) 6コアプロセッサー (iv) Windows Server 2003, Enterprise Edition（テストしたサーバーに配備）は32プロセッサースレッショルドをサポート

していないため、統合率を得るために必要なベアメタルテストを実行できませんでした。

* インテルHTテクノロジーを有効化

重要： インテルハイパースレッディングテクノロジー（インテルHTテクノロジー）が有効

になっている場合、オペレーティングシステムによって認識されるプロセッサー

コア数は2倍になります。

3 仮想化された構成 - x/y形式で表され、xはVMの数を示し、yは各VMに割り当てられる仮想CPU（vCPU）の数を示します。この構成がx/y/zで表される

場合があることに注意してください。この場合、zは、各VMに割り当てられるメモリ容量（GB単位）を示します。

9

ベストプラクティス 仮想化によって得られるメリットを最大限に活用するには、XenApp環境を理解する必要があります。このような環境

を仮想化する際にコスト効率のよいホストサーバーをサイジングするには、個々のアプリケーションと、サポート予定

のユーザー数および特定ユーザープロファイルを考慮する必要があります。

VMのパフォーマンスがアプリケーション、ゲストオペレーティングシステム、およびその他の要因によって変化する可能

性があることに注意してください。したがって、仮想化環境をプランニングする際の最大の課題は、ホストサーバーのサ

イジングおよびパフォーマンスに影響を与える可能性のある次のような変動項目にいかに対処するかということです。

• 単一のホストにVMをいくつ配備するべきか。

• 各VMに仮想CPUをいくつ割り当てるべきか。

• メモリとI/Oのボトルネックを取り除くために各VMにどれだけのメモリ容量が必要か。

• 内蔵ストレージよりもストレージアレイネットワーク（SAN）の方が適しているか。

• ネットワークインターフェイスカード（NIC）は十分にあるか。

このレベルの複雑さをさらに悪化させるものとして、XenApp環境には、同時に実行される膨大な数の処理や配備され

るアプリケーションの多くが持つ高いメモリ依存性による特有の課題があります。その結果として、このような環境を仮

想化する際には、選択するホストサーバーが適切なリソース（プロセッサー、メモリ、I/O、およびネットワーク）とスケー

ラビリティを提供できるように、サイジングプロセスを精緻化する必要があります。

ただし、仮想化のプランニングを開始する前に、まず、使用するアプリケーションが適したものであるかどうかを判断す

る必要があります。たとえば、使用率の低いXenAppサーバー、XenAppデータストアサーバー、およびインフラストラク

チャサービスを実行するサーバーは、仮想化に適している可能性があります。反対に、リソースを大量に消費するアプ

リケーションを実行するXenAppサーバーや使用率の高いインフラストラクチャサーバーは、仮想化に適していない可

能性があります。

この項では、仮想化されたHP ProLiantサーバーのスケーラビリティを最大化するためのガイドラインを提供します。

注： 一般論としては、VM数を増やす際、VM当たりのvCPU数を変更する際、または

VM当たりのメモリ容量を減らす際に、スケーラビリティが低下するときは、仮想

化サーバー構成（6/4/8など）が最適だと考えられます。

ただし、実際の環境が固有のものであることに十分注意する必要があります。このため、テストが、サーバーのスケー

ラビリティと統合率の最大化において不可欠の要素となります。

64ビット環境への移行可能性の検討 メモリの制約を受けている16または32ビットアプリケーションに対処するための最適なソリューションは、64ビット環境へ

の移行です。64ビット環境では、アドレス可能なメモリの容量は、もはや問題とはなりません。実際に、最新のサーバー製

品が512GB以上のメモリをサポートしていることは珍しくありません。64ビットのオペレーティングシステムではこの

512GBのメモリをフル活用できますが、32ビットのオペレーティングシステムがサポートするのは、最善の場合でも、

128GB4

4 4GBを超えるメモリにアクセスするには、物理アドレス拡張（PAE）のサポートが必要です。詳しくは、Microsoft社のWebサイト

です。

http://www.microsoft.com/whdc/system/platform/server/PAE/PAEdrv.mspxを参照してください。

10

64ビットプラットフォームの仮想化が、ベアメタル実装よりも全体的なユーザー密度を低下させるリソースオーバーヘッ

ドと関係していることに注意してください。ただし、このオーバーヘッドは、一般に、仮想化によって得られるさまざまなメ

リット（サーバー統合、エネルギー効率、拡張されたディザスタリカバリ機能、容易なサーバーメンテナンスなど）を考え

ると許容できます。

次のように、64ビット環境への移行が非実用的または非経済的になる可能性があるいくつかの理由が存在します。

• 32または64ビット配備に移植できない16ビットアプリケーションをサポートしつづける場合は、既存のアプリケーショ

ンを32ビット環境（仮想化環境であってもなくても）で実行する他に選択肢はありません。

• デバイスドライバーまたはアプリケーションが64ビット環境と互換性がない場合は、やはり、32ビット版のWindows上に環境を配備する他に選択肢はありません。

32ビットプラットフォームを仮想化することにより、他になにも変更しなくても、非常に優れたユーザー密度を実現すること

が可能です。比較的古いプラットフォームのスケーラビリティは、多くの場合、150ユーザー以下に制限されていますが、

最新のHP ProLiantサーバーでは、5.0もの統合率を実現できます。このため、仮想化により、5台の旧式のサーバーを1台の仮想化されたサーバー（HP ProLiant DL380 G7）に置き換えられる可能性があります。

注： 仮想化によって配備の複雑さが増加します5

適したプラットフォームのみの仮想化

。それでも、64ビット環境に移行で

きない場合には、仮想化が適している可能性があります。

仮想化に適した対象を特定する際には、多数の選択肢があります。一般に、使用率の低い旧式のサーバーについて

は、型式やモデルに関係なく、32ビットプラットフォームであっても64ビットプラットフォームであっても、任意のサーバー

を劇的に統合できる可能性があります。

注： HPでは、他社製サーバーからの移行に役立つツールを提供しています。たとえ

ば、HP Insight Control サーバー移行は、物理サーバーとProLiantサーバーの

間でのアプリケーションの移行をサポートします。

多くの場合、32ビットプラットフォームは、統合の対象として最適です。企業は、旧式のサーバーおよびアプリケーション

から生産性を限界まで引き出すために、長期にわたって奮闘してきました。実際、現時点では、ドライバーの非互換性

やカスタムアプリケーションの移植に関する問題のために、多数の32ビットプラットフォームが64ビットプラットフォーム

に移行できません。

XenServerを使用すると、パフォーマンスを犠牲にすることなく、旧式のサーバーをHPの最新のサーバー製品ファミリに

効率的に移行して、ホストすることができます。場合によっては、プロセッサー、メモリ、およびI/O機能の世代の向上に

より、パフォーマンスが向上する可能性もあります。よく知られている非仮想化32ビットプラットフォームのメモリ制限お

よびそれを拡張できないことを考えると、仮想化により、スケーラビリティを劇的に400%も向上させることができます

（HPのホワイトペーパー『Consolidation of x86 HP Server Based Computing environment with Citrix XenServer on HP ProLiant BL680c G5』を参照）。

5 大きなラーニングカーブが必要になる場合があります。

11

64ビットプラットフォームには、32ビット環境を悩ませる根本的なメモリ制限はありませんが、エミュレーションの要件は、

32ビットワークロードを64ビット環境で実行することによりスケーラビリティが制限されることを意味します。

注： 大半のエミュレーションがチップレベルで処理されるため、関連オーバーヘッド

は、16ビットWoW（Windows on Windows）エミュレーション関連オーバー

ヘッドよりもはるかに小さくなります。

実際、32ビットプラットフォームで32ビットワークロードを仮想化する場合には、同じ構成の64ビットプラットフォーム

で同じワークロードを仮想化する場合よりも優れたパフォーマンスを実現できます。HPがHP ProLiant BL680c G5サーバー

ブレードで32ビットワークロードを実行することによって得られた結果では、仮想化された32ビット環境で483ユーザーが

サポートされたのに対して、仮想化された64ビット仮想化でサポートされたのは291ユーザーでした。

64ビットプラットフォームで32ビットワークロードを仮想化すると非常に大きなオーハーヘッドが発生する可能性があり

ますが6

コストの考慮

、古いサーバーを新しいマシンに統合することによって非常に大きなメリットを得ることができます。さらに、物理

サーバーの台数が減るため、電力、冷却、データセンター施設、およびライセンスに関するコストを削減することができ

ます。つまり、さらなる節約へとつながります。

仮想化環境をプランニングする際には、必要なコストを考慮する必要があります。

「テストの結果」の項に示されているように、HPでは、さまざまな構成をテストして、64ビット環境では仮想化オーバー

ヘッドが大きく異なる（最適構成の場合で0～25%）可能性があることを確認しました。オーバーヘッドのレベルが重要

になる可能性があるとはいえ、慎重な調整によって最大限のスケーラビリティを実現し、それによって投資回収率を最

大化することができます。

注： 32ビット環境では、最新のHP ProLiantサーバーは、仮想化されている場合の

方が、ベアメタル構成の場合よりも多数のユーザーをサポートします。このため、

事実上、仮想化オーバーヘッドは存在しません。

ただし、オペレーティングシステムのライセンスコストが、配備されるVMの数と直接関係することに注意してください。実

際問題として、最適数のVMを配備するよりもライセンスコストを最小限に抑える方が有益である場合があります。たと

えば、HP ProLiant DL785 G5サーバーで実施したテストでは、8/4構成で430ユーザーをサポートできる一方で、4/8構成で420ユーザーをサポートできることが示されました。サポートするユーザー数を10増やすために、必要となる4つの追加OSライセンスのコストが正当化できるとは考えられません。

vCPUの過剰割り当ての回避 特定のVMに割り当てる仮想CPU（vCPU）を増やせば、VMがサポートできるユーザーが増えるように思えるかもしれま

せん。しかし、HPでは、vCPUの過剰割り当て（つまり、存在するプロセッサーコアよりも多いvCPUの割り当て）によって、

プロセッサーリソースをVM間で共有する必要が生じるために、サーバーのスケーラビリティが低下する傾向があること

を確認しました。

6 「テストの結果」の項に、このオーバーヘッドの例が示されています。

12

CPUリソースのフル活用 通常、CPUコアは、一度に1つのスレッドのみを実行できます。ただし、インテルHTテクノロジーは、1つのコアが2つのスレッドをサポートすることを可能にします。実際に、インテルHTテクノロジーが有効になっているクアッドコアプロ

セッサーは、オペレーティングシステムによって8コアプロセッサーとして認識されます（「インテルHTテクノロジーの

有効化」を参照）。

各コアは、仮想CPU（vCPU）をサポートできます。

vCPUを過剰に割り当てないことがベストプラクティスとなりますが、利用可能なすべてのプロセッサーコアを使用して、

パフォーマンスの最大化に役立てる必要があります。そのため、2基のクアッドコアAMD Opteronプロセッサーを搭載

するHP ProLiantサーバーを仮想化する場合には、8つのvCPUを配備する必要があります。しかし、2基のクアッドコア

インテルXeonプロセッサーを搭載するサーバーを仮想化する場合、インテルHTテクノロジーが有効になっているときは

16のvCPUを配備できます。

バランスの確保 最大限のサーバースケーラビリティを実現するための鍵のひとつは、特定のサーバーで設定するVMの数と各VMに割

り当てるvCPUの数のバランスをとることです。たとえば、HPでテストした次の仮想化されたHP ProLiant DL585 G5サー

バーについて考えてみます。

• 8/2: 184ユーザー

• 4/4: 242ユーザー（つまり、30%多い）

このように、VMの数を減らし、VM当たりのvCPUの数を2倍にすることによって、この特定サーバーのスケーラビリティ

は30%増加しました。

HPでは、VMを設定する際の出発点として使用できる次のガイドラインを提供します。

• 8コア：4/2

• 16コア：4/4

• 24コア：6/4

• 32コア：8/4

実際の環境に最適な設定を判断するために、パフォーマンステストを実行することを強くおすすめします。

インテルHTテクノロジーの有効化 インテルXeonプロセッサーを搭載した比較的新しい世代7

注：

のHP ProLiantサーバーを使用している場合は、インテルHTテクノロジーを有効にして、VMに使用できるプロセッサーコア数を2倍にすることができます。

関連オーバーヘッドのために、比較的初期に実装されたインテルHTテクノロ

ジーについては、有効にしないでください。

HPでは、2P/12C8のHP ProLiant DL380 G7サーバーブレードでインテルHTテクノロジーを有効化するメリットを確認し

ました9

7 G6以降

。図2に示すように、6/2/6構成では、XenApp環境で500ユーザーをサポートすることができました。

8 2基のプロセッサー（P）と合計12のコア（C）をサポートすることを示す 9 詳しくは、HPのホワイトペーパー『Performance of HP ProLiant DL380 G7 with Intel Xeon Processor X5680 (3.33 GHz) in 32- and 64-bit HP SBC

environments』および『Performance of HP ProLiant DL380 G7 with Intel Xeon Processor X5680 (3.3 GHz) in a 32-bit virtualized HP SBC environment』を参照してください。

13

図2. 12コアを使用するように設定し、この仮想化サーバーで500ユーザーのサポートを実現

インテルHTテクノロジーを使用することにより、使用可能なコア数を12から24に効率的に増加させました。これらの追

加リソースを最大限に活用することによって、このサーバーに配備するVMの数を2倍に増やしました。

注： この場合は、過剰割り当てとは判断されません。

図3に示されているように、結果として6/4/6構成を実現し、680ユーザー（36%増加）をサポートすることができました。

14

図3. vCPUの倍増（12から24に）により、この仮想化サーバーのCPUリソースがフル活用され、サポートされるユーザー数が36%増加

プロセッサー使用率急増の防止 プロセッサー使用率の急増を防止するために、ワークロードを適用する前にVMがオンラインになっていることを確認し

てください。多数のユーザーを同時に追加しないでください。可能であれば、VM間でワークロードを均一化してください。

15

各VMへの十分なメモリの割り当て 各VMに十分なメモリを割り当てることも重要です。たとえば、テストシステムは、多くの場合、比較的少ないメモリ容量

で構成されますが、各実務VM（32ビットと64ビットのどちらのアプリケーションを実行する場合でも）については、8GB以上のメモリ構成をおすすめします。この割り当ては、代表的なワークロードに適合していなければならず、ある適度の

拡張の余地も必要です。8GBのメモリを32ビットのVMに割り当てることは、64ビットプラットフォームに移行する際にホ

ストサーバーを物理的にアップグレード（追加のメモリオーバーヘッドが発生する場合がある）する必要がなくなることも

意味します。

ただし、8GBのメモリをサポートしないオペレーティングシステム（4GBのメモリしかサポートできない32ビットバージョン

のWindows Server 2003 Standard Editionなど）を実行する場合は、より少ないメモリを各VMに割り当ててください。

重要： スケーラビリティを最大化するために、VM内にページファイルを配備しないこと

をおすすめします。ただし、テスト環境では、HPは、ベアメタルサーバー構成と

一貫性を持たせるために、ページファイルをVM内に配備しています。なお、VM内にページファイルを配備することにはいくつかのメリットがあります。たとえば、

VMでトラップまたはBSOD10

XenServerでは、現在、メモリを過剰に割り当てることはできませんが、HPでは、この機能がXenApp環境に有益である

と考えていません。VMメモリ割り当ての総容量が物理メモリのサイズを超えないようにする必要があるだけです。個々

のVM割り当ては、ゲストオペレーティングシステムによってサポートされている制限を超えてはなりません。ハイパー

バイザー用に約1GBのメモリを用意することを忘れないでください。

が発生した場合、ローカルページファイルが存在し

ないと、解析用のダンプファイルを取得できません。

しかし、十分なメモリリソースを割り当てないと、パフォーマンスが大幅に低下する場合があります。

不十分なメモリリソースの例 十分なメモリをVMに割り当てない場合の影響を確認するために、HPでは、32ビットXenApp環境で次の構成のHP ProLiant BL465c G7サーバーブレード11

• 6/4/4

をテストしました。

• 6/4/6

図4は、6/4/4構成のスケーラビリティを示しています。

10 Blue Screen of Death（ブルースクリーンクラッシュ）の略 11 詳しくは、HPのホワイトペーパー『Performance of HP ProLiant BL465c G7 with AMD Opteron processor Model 6174 (2.2 GHz) in a 32-bit

virtualized HP SBC environment』を参照してください。

16

図4. 6/4/4構成のスケーラビリティ

使用可能なメモリリソースが6/4/4構成にないために、445人のヘビーユーザーがアクティブになったときに停止セッ

ション数が急増しました。

プロセッサー使用率が80%（一般にサーバーのスケーラビリティの特性評価に使用される基準）に達することはありま

せんでした。この特定サーバー構成の場合、HPでは、最適ユーザー数を435（445のアクティブセッションから10の停

止セッションを差し引いた数）と判断しました。これは、プロセッサーリソースよりもメモリ不足によって制限を受けた結果

です。

図5は、メモリリソースが少ない状態で稼動する個別のVMの状態を示しています。

17

図5. このVMは、メモリリソースが少ない状態で稼動しているときに、ディスクアイドル時間が急減し、サポート可能なユーザー数が減

少（停止セッション数が含まれていないことに注意してください）

図6に示されているように、メモリサイズを4GBから6GBに増やすと、スケーラビリティが大幅に向上しました。

18

図6. 6/4/6構成のスケーラビリティ

650人のヘビーユーザーがアクティブのときに平均プロセッサー使用率が80%に達しました。630～680人のヘビーユー

ザーがアクティブのときに停止セッション数が急増しはじめました。

このため、HPでは、最適ユーザー数を645人（650人のユーザーから5つの停止セッションを差し引いた数）と判断しま

した。

図7に示されているように、各VMに割り当てるメモリを4GBから6GBに増やすと、プロセッサーリソースがフル活用され

るようになり、スケーラビリティが48%向上しました。

19

図7. メモリ割り当ての比較

実務環境では、I/Oパフォーマンスを常に監視して、潜在的なボトルネックがないか確認する必要があります。次のよう

な使用状況の場合は、特に注意してください。

• I/Oサブシステムに大きな負荷をかけるアプリケーションは、仮想化環境では、ベアメタル構成の場合と同じように

は拡張されません。

• 既存のワークロードを最新の32ビットプラットフォーム上で仮想化した場合は、サーバーが仮想化前よりもはるかに

多くのユーザーをサポートしている可能性があることに注意してください。この場合は、明らかに潜在的なI/Oボトル

ネックが存在していると考えられます。

ディスクI/Oボトルネックの防止 ディスク I/Oボトルネックの防止を容易にするために、Microsoft社は、Windowsのパフォーマンス監視ツール

（Perfmon）を使用して次の測定基準をチェックすることを推奨しています12

• [%Idle Time] – 論理および物理ドライブのアイドル時間は、平均50%以上である必要があります。

。

• [Avg. Disk sec/Read]および[Avg. Disk sec/Write] – 読み取りまたは書き込みを完了するまでの平均時間

は25ミリ秒未満、ピーク時間は50ミリ秒未満である必要があります。

Microsoft社によって指定される上記の条件を満たすことができない場合、ディスクI/Oボトルネックが

高い確率で存在します。

注： I/Oボトルネックが存在する場合には、ディスクサブシステムを調整するか、

ユーザーまたはアプリケーションの数を減らすか、サーバーのメモリを増やす

必要があります。

ライトキャッシュの使用 HP Smartアレイコントローラーは、データキャッシュを備えています。このデータキャッシュは、ディスクに書き込み中ま

たはディスクから読み取り中のデータを一時的にキャッシュするために使用できるメモリです。このメモリへはディスクア

クセスよりもはるかに速くアクセスできるため、キャッシュによってサーバーの全体的なパフォーマンスを（特にログイン

動作時に）向上させることができます。

ライトキャッシュは、XenApp環境では特に注目されます。特定の書き込みコマンドに関係するすべてのデータをバッ

ファーすると、Smartアレイコントローラーは、データがまだディスクに書き込み中でも、ディスクへのデータ転送が完

了したとXenAppサーバーに通知します。これにより、サーバーのプロセッサーが解放されて他のタスクを実行できる

ようになり、データスループットが向上します。

12 詳しくは、Microsoft社のWebサイトを参照してください。

20

HPでは、まだ、XenApp環境におけるフラッシュバック式ライトキャッシュ（FBWC）パフォーマンスの特性評価を実施して

いませんが、バッテリバックアップ式ライトキャッシュ（BBWC）に関して実施したテストでは、XenAppサーバーが大量の

ログ処理をともなう操作を実行している場合や大量のページファイル書き込み操作を必要とする場合（ユーザーログイ

ン時など）に、ライトキャッシュによってパフォーマンスがもっとも向上することが確認されました。パフォーマンスの向上

率は、50～250%13

ネットワークパフォーマンスの監視

でした（実際の結果は、関係するアプリケーションや個々のXenApp環境によって異なります）。

これまでのところ、XenAppワークロードは、Citrix ICA（Independent Computing Architecture）に関する効率性のため

に、raw帯域幅よりもネットワークレイテンシに関連した問題を多く持っています。

今や、仮想化以前には複数のサーバー上で実行されていたワークロードが1台の物理サーバーで処理されるようにな

るため、すでに存在する可能性のあるあらゆるネットワークボトルネックについて、ホストを監視する必要があります。

ネットワークパフォーマンスを向上させるには、ネットワークポートを追加する、ネットワークインターフェイスカード

（NIC）のチーミングを実装する、HPバーチャルコネクトテクノロジーを使用するといった多数の方法があります。

可用性の強化 VMは柔軟であるため、必要なレベルの可用性を直ちに実装することができます。その上、HP StorageWorks製品に

よって構築されるSANを使用することにより、次のような機能によって可用性を強化することができます。

• リダンダンシを提供する複数パス

• 自動パスフェイルオーバー

• 高可用性クラスターのサポート

例 たとえば、1台ですべてが構成されているHP ProLiant BL460c G6サーバーブレードによって8つのVMが提供される環

境があるとします。このサーバーが故障すると、8つのVMのすべてが障害状態になります。

代わりに、それぞれが4つのVMを提供する2台のBL460c G6サーバーブレードを配備するとします。今度は、1台のサーバーが使用不能になっても4つのVMにしか影響しません。必要であれば、ダウン状態のVMを稼動している

方のサーバーに手動でインポートして、それらのVMを再起動することも可能です。

しかし、さらに、この2台のBL460c G6サーバーブレードが共有ストレージとともにプール構成になっており、XenServerの高可用性（HA）機能を使用していれば、ダウン状態になったVMを、稼動している方のサーバー上で自動的に再起動

させることができます。その上、共有ストレージがあるため、稼動中のVMを、XenServerのライブ移行（XenMotion）機能を使用してホスト間で移動することもできます。

XenMotionは、VMのダウンタイムの削減に役立ち、サーバー管理者はダウンタイムに関する作業から解放されて元の

ホストの修理やアップグレードにすぐに取りかかることができます。

ビジネスクリティカルな環境の場合は、3台目のBL460c G6サーバーブレードをプールに追加して、各ホストが2～3つのVMをサポートする環境を実現することも検討する余地があります。XenServerのライブ移行機能とワークロード均一

化機能を使用すると、VMがホスト間で自動的に移動され、各ホストのワークロードが最大限に均一化されるとともに、

リソース利用率が最大化されます。この構成では、1台のサーバーがオフラインになっても、プールの全体的なパフォー

マンスにはほとんど影響しません。

13 詳しくは、HPのWebサイト（英語）を参照してください。

21

VMの配分の均一化 VMの調整不足のために発生する内部ボトルネックによって、特に、複数の同じ設定のVMが同じホストサーバーに配

備されている場合に、ホストシステムに大きな負荷がかかる場合があります。たとえば、ホスト上のすべてのVMがメモ

リに関して制約を受けている場合、サーバーのディスクI/Oシステムに非常に大きな負荷かがかかります。このような

状態を防止するために、必ず、VMを適切に設定し、環境内に均一に配備してください。メモリスワッピングは、決して発

生させないでください。

リソース使用率の最大化 VMの最大限のパフォーマンスを実現するには、適切なサイジングに加えて、XenServerとゲストオペレーティングシス

テムを適切に設定する必要があります。スクリーンセーバーやその他のリソースを大量に消費するアプリケーションの

実行を見落とさないようにしてください。VMを慎重に調べて、ユーザーとアプリケーションのために貴重なリソースを節

約してください。この要件は、従来のXenApp環境でもよく知られていますが、仮想化すると重要性が増します。

XenServerカーネルの最適化 HPでは、通常、XenAppテスト環境でのパフォーマンスを最大化するためにXenServerカーネルには手を加えていませ

ん。ただし、実際のワークロードがメモリを大量に消費する場合に、スケーラビリティや信頼性に関する問題が発生する

ときは、ドメイン0（Dom0）に割り当てられるメモリ容量を増やさなければならない可能性があります。

このように、必要に応じて、XenServer /boot/extlinux.cnfファイルでDom0に割り当てられるRAMの容量を増や

して、追加のユーザーに対応することができます。

Dom0について詳しくは、XenのWebサイトhttp://wiki.xensource.com/xenwiki/Dom0を参照してください。

管理性の強化 VM管理に関する次の注意事項を考慮してください。

• 多数の管理ツールによってVMの状態を把握できますが、実際には、物理マシンと同様に、仮想化層の管理も必要

となることに注意してください。環境の管理に必要なツールの数を最小限に抑えるために、物理マシンと仮想マシン

に単一の統合プラットフォーム（XenServerとXenAppを実行するHP ProLiantサーバーなど）を使用することをおすす

めします。

• オンボードのハードウェア管理および通知機能を有効にすることを検討してください。これにより、事前障害アラート

を受け取り、障害が発生する前にVMを別の物理ホストに移動させることができます。

• 仮想化環境では、サーバーのパフォーマンスよりもアプリケーションを監視する方が困難な場合があるため、パフォー

マンスに関する問題が発生した場合にやみくもにVMを増やさないようにしてください。物理マシンのサイロをVMのサイ

ロに取り替えることになりかねません。

• 仮想化によってサービスの複製が非常に容易になるため、物理マシンの数を増やさなくても多数の新しいサービス

を管理できるようになっている場合があります。これらの追加のインスタンスによって、より多くのパッチが必要となり、

管理や監視の作業も増加します。

• しばしば、めったに使用されないアプリケーションを提供するVMが存在し、これらのVMは長期にわたってオフになって

いることがあります。管理ツールがこれらのVMをオンにしてパッチをインストールできず、潜在的なセキュリティリスク

が発生する場合があります。

このホワイトペーパーの残りの部分では、Windows Server 2003の機能によって制限を受ける可能性のある、最新の

4Pサーバーのスケーラビリティを仮想化によって向上させる方法について説明します。また、従来の環境の統合によっ

て得られるメリットの例も示します。

22

最新4Pサーバーのスケーラビリティの強化 HPでは、64ビット環境において、Windows Server 2003, Enterprise Editionが現行の4PのHP ProLiantサーバーに搭

載されているプロセッサーコアの数に対応できない場合があることを確認しました。

注： 32ビットのWindows Server 2003プラットフォームのスケーラビリティが制限さ

れることは、よく知られています。

この項では、HP ProLiant BL685c G7サーバーブレードの、ベアメタル64ビットプラットフォームとして配備される場合の

制限されたスケーラビリティ14と、仮想化された32ビットプラットフォームとして配備される場合の大幅に向上したスケーラ

ビリティ15

ベアメタル64ビットプラットフォーム

を比較します。

図8は、64ビットテスト環境の4P HP ProLiant BL685c G7サーバーブレードによってサポートされるヘビーユーザーの

数を示しています。

14 制限されたスケーラビリティのために、HPでは、64ビットプラットフォームのパフォーマンステストの結果を公表しませんでした。 15 詳しくは、HPのホワイトペーパー『Performance of HP ProLiant BL685c G7 with AMD Opteron processors Model 6128 HE (2.0 GHz) in a 32-bit virtualized HP SBC environment』を参照してください。

23

図8. ベアメタル64ビットプラットフォームによるヘビーユーザーの最適サポート数は208のみ

特定のサーバーがサポートする最適ユーザー数を判断するための測定基準として、HPでは、通常、プロセッサー使用

率を使用しますが、このテストの実行時には、プロセッサー使用率が80%に達することはほとんどありませんでした。し

かし、停止セッション数は、208人のユーザーがアクティブのときに急増しはじめました。

テストの実行時には600以上のセッションが開始されましたが、テストの終了時にはこれらのセッションの多数がすでに

停止していました。

このことから、HPでは、この64ビットテスト環境のベアメタルHP ProLiant BL685c G7サーバーブレードによってサポー

トされる最大ユーザー数は208と結論しました。一方で、HP ProLiant BL685c G6サーバーブレードは、同じ環境で500人のユーザーをサポートすることができました。

24

32コアサーバー（G7）によってサポートされるユーザー数が24コアサーバー（G6）よりもはるかに少ないということは、

直観的には受け入れがたい結果です。しかし、この不自然な結果は、テストするサーバーを動作させるためにHPがWindows Server 2003, Enterprise Editionを使用したことによって説明されます。

このエディションは、大きな負荷がかかっていなくても、32のスレッドの同時実行をサポートできません。このため、次の

ようなアップグレードの選択肢を検討することができます。

• Windows Server 2003, Datacenter Edition – 最大32コア

• Windows Server 2008 – WebまたはStandard Edition – 最大4プロセッサー

– Enterprise Edition – 最大8プロセッサー

– Datacenter Edition – 最大64プロセッサー

注： 64ビット環境ではスケーラビリティが高コア密度によって制限されるということ

が最近明らかになったため、HPでは、Windows Server 2003/Office 2003からWindows Server 2008/Office 2007へのテスト環境のアップグレードを積

極的に進めています。 現在のテスト環境におけるこのソフトウェアパフォーマンスに関する問題のため

に、HPでは、64ビットテスト環境におけるHP ProLiant BL685c G7サーバーブ

レードのベアメタルテストのレポートを公表しませんでした。しかし、このサー

バーのG6モデルと同じ方法論が使用されました。

カーネルの不安定性 図9に示されているように、390のセッションの開始後に特権化の割合（% Privilege Time）の値が急増しました。こ

れは、カーネルが不安定になり、必要な数のスレッドを同時に実行できなくなったことを示しています。同様に、プロセッ

サーキューの長さも急増しています。

25

図9. 390のセッションの開始後にカーネルが不安定化

•

このように、64ビットプラットフォームとして配備すると、HP ProLiant BL685c G7サーバーブレードのスケーラビリティが

制限されました。次の項では、このサーバーを仮想化された32ビットプラットフォームとして配備する場合に実現される

スケーラビリティの向上について詳しく説明します。

32ビットプラットフォーム HPでは、ベアメタル32ビットプラットフォームと比較するために、HP ProLiant BL685c G7サーバーブレードを仮想化さ

れた32ビットプラットフォームとしてテストしました。

ベアメタル32ビットプラットフォーム 図10は、予想されたとおりの、システムPTEの不足によって制限されたベアメタルプラットフォームのスケーラビリティを

示しています。

26

図10. ベアメタルHP ProLiant BL685c G7サーバーブレードは32ビットプラットフォームとして127人のユーザーをサポート可能

•

27

仮想化された32ビットプラットフォーム 図11は、仮想化された32ビットプラットフォームがHP ProLiant BL685c G7サーバーブレードのプロセッサーリソースを

フル活用できたことを示しています。

図11. HP ProLiant BL685c G7サーバーブレードは仮想化された32ビットプラットフォームとして731人のユーザーをサポート可能

•

このように、仮想化によって、HP ProLiant BL685c G7サーバーブレードは、32ビット環境において、サポート可能な

ユーザー数を大幅に増加16

さらに、ホストオペレーティングシステムによってサポートされる必要があるのは4つのCPUコアのみであるため、オペレー

ティングシステムがサポート可能なコア数を超える32コアを搭載するベアメタル構成の場合とは異なり、VMはカーネルの

制限を受けることなく動作することができました。

させることができました。

16 576%

28

テストの結果、これらのカーネルに関する制限のために、仮想化された32ビットプラットフォームはベアメタル64ビットプ

ラットフォームよりも351%も多いユーザーをサポートできることが示されました。このため、高密度4Pサーバーの動作

がベアメタル64ビットプラットフォームとして不十分と思われる場合には、このサーバーを仮想化し、32ビット環境に配

備することがソリューションとなる可能性があります（図12を参照）。

図12. スケーラビリティの比較

統合の例 統合のメリットを明確にするために、HPでは、従来は多数のブレードを使用してサポートしていたワークロードに対応す

るために最新のサーバーブレードが何台必要かを確認しました。

次のような課題について、調査しました。

• 1,500人以上のMicrosoft Office 2003ユーザーを1台のHP BladeSystem c7000エンクロージャーでサポートする

• 16台のHP ProLiant BL460c G1サーバーブレード（それぞれが96人のユーザー17

旧式のブレードを置き換えるために、HPでは、次の構成の2P HP ProLiant BL465c G7サーバーブレードを選択しま

した。

をサポート）を置き換える

• AMD Opteronプロセッサーモデル6174（2.2 GHz）

– 12コア

– 12MBの共有L3キャッシュ

• 64GBのRAM

• HP SmartアレイP410iコントローラー（RAID 0）

– 2台の146GBのSASドライブ（10,000rpm）

– 1GBのFBWC

• HP NC551iデュアルポートFlexFabric対応10Gbコンバージドネットワークアダプター

HPでは、XenApp環境において仮想化されたHP ProLiant BL465c G7サーバーブレードが645人のユーザーをサポー

トできることを確認しました。したがって、これらのブレードを3台18

使用すれば、以前は16台の旧式のブレードによって

サポートされていたワークロードに対応できます（図13を参照）。実際には、3台の最新のブレードによって、これらの旧

式のシステムでサポートされていたユーザー数よりも25%多いユーザーをサポートすることができ、将来の拡張に使用

できる13の空きスロットも残されました。

17 16 x 96 = 1,536ユーザーをサポート 18 3 x 645 = 1,935ユーザーをサポート

29

図13.16台の旧式システムは3台の仮想化されたHP ProLiant BL465c G7サーバーブレードによって置き換えることが可能（スペアを

搭載する余裕も発生）

注： 上記のHP ProLiant BL465c G7サーバーブレードのために想定されたユー

ザー数については、一般にシステムリソースをあまり消費しない他社製エー

ジェント（ウイルススキャン、ソフトウェアプロビジョニング、リモート管理、ファイ

アウォールなど）といった要素は考慮されていません。ユーザープロファイルや

ワークロードの変更がスケーラビリティに多大な影響を与える可能性があること

に注意してください。 旧式の実装の場合と同様に、管理サーバーは他の場所に設置されていること

が前提となっています。

電気代の最小化 サーバーの電力および冷却コストは小さくありません。それらのコストは、ITインフラストラクチャコストのかなりの部分

（最大部分ではないとしても）を占めます。実際、ますます多くの調査によって、サーバーハードウェアがもはやデータセ

ンター関連の最大の支出ではないことが示されています。たとえば、新しい1Uサーバーについては、すでに、サーバー

の維持に必要な電力および冷却インフラストラクチャの資本コストがサーバーの購入価格を上回っており、近いうちに

製品寿命全体のエネルギーコストも購入価格を上回ると思われます（詳しくは、HP ActiveAnswersを参照）。

ワークロードを少数台のハイパフォーマンスHP ProLiantサーバーブレードに統合することにより、年間の電気代を大幅に

削減することができます。たとえば、電気代がKWh当たり0.10ドルの場合、基本構成のHP ProLiant BL460c G1サーバー

ブレードにかかる電気代は5,168ドル（1日24時間×週7日間稼動の場合）です。3台のHP ProLiant BL465c G7サーバー

ブレードの場合は、電気代が、図14に示されているように、はるかに少なくなります19

19 ハイパフォーマンステクニカルコンピューティング（HPTC）の要件である1,935Wに基づく

。

30

注： 旧式の構成と統合構成の電力要件は、HP BladeSystem Power Sizer（BPS）を使用して推定されました。 許容可能な限界まで負荷をかけられたシステムに関する実際のコンポーネント

レベルの電力要件に基づいて推定するBPSは、個々のHP BladeSystem配備の

プランニングに役立ち、電力/冷却要件、コスト、および詳細な部品表を提供し

ます。

図14.はるかに高い従来の構成の年間電気代

31

付録A – テスト この付録Aでは、HP ProLiantサーバー上のVMによってサポートされる最適ユーザー数を特性評価するためにHPが使

用した方法論について説明します。

重要： 他の研究所におけるテストと同様に、このホワイトペーパーに示されているパ

フォーマンス測定基準も理想化されています。実務環境では、これらの測定基

準が、さまざまな要因の影響を受ける可能性があります。

すべてのアプリケーション配備のベストプラクティスとして、非実務環境におい

て、実際のターゲットアプリケーションを使用して、実証テストを実施することを

おすすめします。実際のターゲットアプリケーションを実務環境と同一の（しかし

分離された）テスト/診断環境でテストすることは、システムの動作を特性評価

するためのもっとも効果的な方法です。

この項では、テストツール、ユーザープロファイル、およびテスト手順について詳しく説明します。

テストツール シミュレートされるワークロードのXenAppサーバーへの配置および管理を容易にするために、HPでは、ターミナル サービ

ス スケーラビリティ プランニング ツール（TSScaling）を使用しました。これは、Windows Server 2003 Terminal Serverの容量プランニングを容易にするためにMicrosoft社によって開発された一連のツールです。

表A-1に、これらのツールの説明が示されています。

表A-1. TSScalingのコンポーネント

コンポーネント 説明

自動化ツール Robosrv.exe ワークロードシミュレーションのサーバー側を制御します。

Robocli.exe ワークロードシミュレーションのクライアント側の制御を補助

します。

テストツール Qidle.exe いずれかのスクリプトが失敗し、オペレーターによる操作が

必要となっているかどうかを判別します。

Tbscript.exe ワークロードシミュレーションのクライアント側の操作を補助

するスクリプトインタープリターです。

ヘルプファイル TBScript.doc ターミナル サーバー ベンチ スクリプトのマニュアルです。

TSScalingSetup.doc スケーラビリティテスト環境のセットアップガイドです。

TSScalingTesting.doc テストガイドです。

32

詳細情報 • Roboserver（Robosrv.exe）およびRoboclient（Robocli.exe）：『Terminal Server Capacity Planning』

• TSScaling：『Windows Server 2003 Terminal Server Capacity and Scaling』

ユーザープロファイル XenApp環境における一般的なワークロードをシミュレートするために、HPでは、ヘビーユーザープロファイルを選択し

ました。ヘビーユーザー（「構造化タスクワーカー」とも呼ばれる）は、複数のアプリケーションを同時に開き、長時間に

わたってアクティブなままにする傾向があります。ヘビーユーザーは、使用していないアプリケーションも、しばしば、開

いたままにします。

表A-2に、これらのユーザーによって実行される業務を示します。

表A-2. テストスクリプトに組み込まれる業務

業務 説明

Access データベースを開き、フィルターを適用し、レコードを検索、追加、および削除します。

Excel ファイル容量の大きなスプレッドシートを開き、印刷、および保存します。

InfoPath データ20をフォームに入力します。フォームを保存して既存のフォームを上書きします。

Outlook 第1段階：短いメッセージの電子メールを送信します。

第2段階：電子メールにファイルを添付して返信します。

Outlook_2 長いメッセージの返信メールを作成します。

PowerPoint 新しいプレゼンテーションを作成し、クリップアートを挿入し、アニメーションを適用します。各スライドを作成した後に

プレゼンテーションを表示します。

PowerPoint2 データ量の多いアニメーションや多数の色および階調が使用されたファイル容量の大きなプレゼンテーションを開

き、表示します。

Word ドキュメントを作成、保存、および印刷し、電子メールで送信します。

テスト手順 HPでは、基準値を提供するためにベアメタルサーバーをテストしてから、仮想化構成をテストして、それらのスケーラビ

リティを比較しました。

また、同じ基本方法論、ツール、およびワークロードを使用して、ベアメタルサーバーとそのサーバー上

で動作するVMのパフォーマンスおよびスケーラビリティを特性評価しました。

基準値の取得 非仮想化サーバーのベアメタルパフォーマンスを特性評価するために、「ユーザープロファイル」で説明した業務に基づ

くワークロードを使用しました。

テストは、シミュレートするユーザーのグループが特定のワークロードを実行することによって開始されました。開始時

間は、認証オーバーヘッドをなくすためにずらして設定されました。これらのセッションが完了すると、別のユーザーグ

ループを追加して、テストを繰り返しました。最適ユーザー数（「パフォーマンスとスケーラビリティの測定基準」を参照）

に達するまで、さらにユーザーを追加しました。

VMのパフォーマンスの特性評価 HPでは、同様の方法論を使用して、テストするサーバー上のVM構成の総パフォーマンスを特性評価しました。ただし、

VMのパフォーマンスを特性評価する場合には、ハイパーバイザーの要求も考慮する必要があることに注意してくださ

い。ハイパーバイザーの要求とは、ユーザーセッション数の増え方が速すぎるか、多すぎるセッションが同時に実行さ

れる場合、物理サーバーのCPU使用率が劇的に増加する可能性があるというものです。

20 Office InfoPath 2003のデータ入力は、大量のプロセッサーリソースを必要とします。

33

テストするサーバーが過飽和状態になることを防ぐために、VMのパフォーマンスがテスト開始前にオンラインになって

いることを確認し、VMに追加するユーザー数を制御して、プロセッサー使用率の急増を最小限に抑えました。VMが必

ず同じ割合で飽和状態になるように、ユーザーを追加する際はラウンドロビン方式のアプローチを採用しました。

パフォーマンスとスケーラビリティの測定基準 Office 2003ベースのワークロードを実行すると同時に、HPでは、Windowsパフォーマンスモニター（Perfmon）のさま

ざまなカウンターを監視して、ベアメタルサーバーとVMのパフォーマンスおよびスケーラビリティを特性評価しました。

また、Office 2003ベースの業務に特化したカナリアスクリプトを使用して、ユーザー応答時間が許容不可能になる前

にサポートできたユーザー数を確認しました。

HPでは、通常、Perfmonの% Processor Timeカウンターを使用して、XenAppサーバーによってサポートされる最適

ユーザー数（定義によれば、プロセッサー使用率が80%に達するときにアクティブなユーザーの数）を確認しています。

このとき、限られた数の追加ユーザーまたはサービスがサポートされる場合がありますが、ユーザー応答時間が許容

不可能になる可能性があります。

32ビットXenApp環境では、32ビットWindowsプラットフォームのよく知られたスケーラビリティに関する制限により、プ

ロセッサー使用率が80%に達する前に、ベアメタルサーバー上のシステム ページ テーブル エントリー（PTE）の空き容

量がなくなる場合があります。

Perfmonから得られる測定基準の正当性を確認するために、HPでは、カナリアスクリプトを使用して、アプリケーション

の起動にかかる時間やモーダルボックスの表示にかかる時間といった、種々雑多な業務の応答時間を特性評価して

います。非常に実務的な測定基準である応答時間を、ログインユーザー数の増加に合わせて監視することにより、最

適数のユーザー（Perfmonのカウンター値で判断）がアクティブのときには応答時間が許容可能であることを確認するこ

とができました。

テストした一部のサーバーでは、プロセッサー使用率が80%に達する前に応答時間が増加しはじめました。このような

場合、HPでは、控えめに、応答時間が最初に許容不可能になったとき（つまり、応答時間が基準値レベルを顕著に超

え始めたとき）にサポートされていたユーザー数を最適とすることを選択しました

同じ基本方法論を使用して、ベアメタルサーバーとそのサーバー上で動作するVMのパフォーマンスお

よびスケーラビリティを特性評価しました。

仮想化環境の最適ユーザー数の特性評価 HPでは、各VMでPerfmonを実行して、特定の使用状態で消費されるCPUリソースを記録しました。また、個々の結果を

集めて、テストしたサーバーが仮想化されたときの機能を単一の見方にまとめました。ただし、非仮想化環境において

はPerfmonのカウンター値のプロットが比較的なめらかになる傾向があるのに対して、VMを配備する場合は、ハイパー

バイザーの動作によって不連続な値が散在するために、生のデータを解釈することが困難でした。そこで、移動平均を

使用して、これらの不連続な値を円滑化することによって、この環境でVMによってサポートされる最適ユーザー数を特

性評価するために役立つプロセッサー消費量の全体像を得ることができました。

特定の使用状況でテストした後は、すべてのVMに関するPerfmonのログを単一のファイルに保存しました。その後、

Office Excelを使用して、連続した10個のログ値の移動平均をプロットしました。

この方法論では、HPがベアメタル環境で使用した方法論よりも精度は低くなりますが、システムの全体的なパフォーマ

ンスと個々のVMのパフォーマンスに対する有効な洞察力を提供します。Perfmonの結果とカナリア応答時間を組み合

わせて分析することにより、各使用状況でVMによってサポートされる最適ユーザー総数を特定することができました。

34

テストのトポロジ 図A-1は、HPサーバーベースコンピューティング（HP SBC）テスト環境を示しています。

図A-1. テスト環境（HP ProLiant DL785 G5サーバー）

詳細情報の入手先 HP ProLiantサーバー HPのWebサイトhttp://www.hp.com/go/proliant

（英語）

Citrix XenAppおよびMicrosoftターミナルサービスを 含む、HP SBC向けのHP ActiveAnswersソリューションの

領域

HPのWebサイ

トhttp://www.hp.com/solutions/activeanswers/hpsbc（英語）

Citrix XenApp Citrix社のWebサイ

トhttp://www.citrix.com/site/PS/products/feature.asp?familyID=19&productID=186&featureID=4110

Citrix XenServer HPのWebサイ

トhttp://h71019.www7.hp.com/ActiveAnswers/cache/457122-0-0-225-121.html（英語）

HP Sizer for Citrix XenApp and Microsoft Terminal Services

HPのWebサイ

トhttp://h71019.www7.hp.com/ActiveAnswers/cache/70245-0-0-0-121.html（英語）

HPソリューションセンター HPのWebサイ

トhttp://www.hp.com/go/solutioncenters（英語）

HPサービス HPのWebサイトhttp://www.hp.com/hps/（英語）

AMD Opteronプロセッサー AMD社のWebサイ

トhttp://www.amd.com/us/products/server/Pages/server.aspx

インテルXeonプロセッサー インテル社のWebサイ

トhttp://www.intel.com/products/server/processors/index.htm

ドキュメントの改善のために、HPのWebサイトhttp://h20219.www2.hp.com/ActiveAnswers/ us/en/solutions/technical_tools_feedback.html（英語）からフィードバックをお寄せください。

© Copyright 2009 - 2010 Hewlett-Packard Development Company, L.P. 本書の内容は、将来予告なしに変更されることがあります。HP 製品およびサービスに対する保証については、当該製品およびサービスの保証規定書に記載されています。本書のいかなる内容も、新たな保証を追加するものではありません。本書の内容につきましては万全を期しておりますが、本書中の技術的あるいは校正上の誤り、脱落に対して、責任を負いかねますのでご了承ください。

Microsoft および Windows は、Microsoft Corporation の米国における登録商標です。AMD Opteron、AMD Virtualization、および AMD-V は、Advanced Micro Devices, Inc.の商標です。Intel、インテル、および Xeon は、アメリカ合衆国およびその他の国におけるインテル コーポレーションの商標です。

4AA2-5115JPN 2009 年 3 月作成、2010 年 9 月改訂第 2 版