Comments
Description
Transcript
ダウンロード
Citrix XenDesktopによる 5000 デスクトップのデリバリ Citrix XenDesktop と Provisioning Services、NetApp ストレージ、および VMWare サーバーの仮想化を使用 したスケーラブルな VDI 配備に関する検証レポートおよび提案 www.citrix.com 目次 はじめに........................................................................................................................................................................... 3 Citrix XenDesktop の概要................................................................................................................................................. 3 エグゼクティブサマリー.................................................................................................................................................. 4 主要な結果 ............................................................................................................................................................... 5 方法とワークロード ......................................................................................................................................................... 5 ワークロードの詳細 - Login Consultants 社の LoginVSI ......................................................................................... 5 コンポーネントのスケーラビリティに関する結果................................................................................................... 6 XenDesktop Desktop Delivery Controller (DDC) .............................................................................................................. 7 シングルサーバーのスケーラビリティ ............................................................................................................................ 8 Provisioning Services のスケーラビリティ...................................................................................................................... 9 結果 .................................................................................................................................................................................10 デスクトップと期待されるユーザーエクスペリエンス ......................................................................................... 10 Citrix XenDesktop Desktop Delivery Controller ...................................................................................................... 10 推奨されるストレージ ........................................................................................................................................... 11 サーバーハードウェアの結果................................................................................................................................. 12 サーバー仮想化の結果 ........................................................................................................................................... 13 スケーラビリティ設計に関するその他の結果........................................................................................................ 14 大規模テストの結果 ........................................................................................................................................................16 テストの詳細.......................................................................................................................................................... 16 大規模テスト結果のサマリー................................................................................................................................. 17 セッションのパフォーマンスとスタートアップ時間 ............................................................................................. 17 Desktop Delivery Controller と Provisioning Services のパフォーマンス............................................................... 20 Desktop Delivery Controller のパフォーマンス ...............................................................................................................20 Citrix Provisioning Services （PVS）のパフォーマンス ................................................................................................30 NetApp ストレージのパフォーマンス .................................................................................................................... 34 VMWare Virtual Center と ESX のパフォーマンス ................................................................................................ 35 ESX のパフォーマンス ...................................................................................................................................................40 要約 .................................................................................................................................................................................42 付録 A - ブレードサーバーハードウェアと配備 .............................................................................................................43 付録 B - ネットワーク図.................................................................................................................................................46 参考文献..........................................................................................................................................................................48 2 はじめに 本書は、設計者、技術者、コンサルタントなどの上級技術者に、最大 5000 デスクトップまで拡大可能な、 Citrix XenDesktop をホストとした VM ベースのソリューション（VDI ソリューション）を計画、設計、配備 するためのデータを提供します。本書では、大規模なエンタープライズ規模の VDI デスクトップ配備をシミュ レーションした Citrix の内部テストの結果を発表しています。 本書のデータは、単一 OS イメージが 5,000 のデスクトップユーザーにプロビジョニングされる配備例に基 づいています。本書はスケーラビリティの確定的な指針を示すものではありません。それぞれの環境に照ら して解釈し、適応する必要があります。データをわかりやすくするために、さまざまなシナリオに合わせて 調整できる推奨値の例を随所で紹介しています。 このテストから得られた情報は、常に追加されている総合的なスケーラビリティのガイドブックにも組み込まれて います。ビルディングブロックを何万ものデスクトップにまで拡張する方法については、XenDesktop Scalability Guidelines（http://support.citrix.com/proddocs/topic/xendesktop-bdx/cds-scalability-wrapper-bdx.html）を参照してく ださい。 Citrix XenDesktopの概要 近年、IT 企業では、迅速なプロビジョニング、Windows 7 への移行、セキュリティ、パッチの適用およびアッ プデート、リモートアクセスなど、さまざまなデスクトップの問題を解決するための新しい方法を探してい ます。これらの企業は、アウトソーシング、コンプライアンス、グローバル化など最新のビジネス戦略のソ リューションを求めています。多くの企業は、IT をハードウェア管理から開放し、本業であるコアソフトウェ アと知的財産に集中できるようにする方法として「私有パソコンの持ち込み」ポリシーに興味を持っていま す。 Citrix XenDesktop は、市販されている中で最も効果的で柔軟なデスクトップ仮想化ソリューションで、デス クトップをサービスとしてあらゆる場所のあらゆるデバイスのユーザーにデリバリできるようにします。 FlexCast デリバリテクノロジにより、XenDesktop は企業内の各ユーザーグループのパフォーマンス、セキュ リティ、およびコスト要件に仮想デスクトップモデルを適合させることができます。 本書では、6 種類の FlexCast デリバリモデルの 1 つである ホステッド VM ベースデスクトップ（VDI）のス ケーラビリティとテスト結果に注目しています。 3 エグゼクティブサマリー Citrix の内部テストでは、高可用性を目的とした VDI 配備のサンプルで、XenDesktop 4 を使用して現実的な ワークロードを シミュレーションしました。3300 を超える Windows XP 仮想デスクトップがエンドツーエ ンド環境に組み込まれました。さらに、重要なコンポーネントは個々にテストし、5000 以上のデスクトップ をサポートできることを確認しました。システム全体の結果と個々のコンポーネントテストを結合すること で、Citrix は最低でも 5000 のデスクトップをデリバリできる 1 つの仮想デスクトップインフラストラクチャ 設計の裏付けとなる結果を出しました。 完全な VDI インフラストラクチャは、以下のコンポーネントを使用して構成されました。 ○ 仮想デスクトップのブローカーリング、リモート処理、および管理のための Desktop Delivery Controller ○ OS プロビジョニングのための Citrix Provisioning Services ○ ユーザープロファイルを格納し、キャッシュと関連するデータベースを書き込むための NetApp 集 中管理ストレージ ○ VM のホストとなる HP ブレードサーバー ○ サーバー仮想化インフラストラクチャとなる VMWare ESX および vCenter ○ Cisco データセンターネットワークスイッチ 4 主要な結果 ○ ワークロードおよびブートまたはログオンストーム（急激な同時接続または同時ユーザーログオン による） は、この VDI 設計の規模に大きく影響します。 ○ Desktop Delivery Controllers は仮想化が可能で、最高のスケーラビリティと弾力性が得られるよう に役割を分散することができます。 ○ Citrix Provisioning Services （SP2 リリース 5.1）は、この VDI 配備の圧倒的な拡張性（1 物理サー バー当たり 3000 以上のユーザー ）と信頼性を実証しました。 ○ 仮想マシンの集約密度は OS、ワークロード、およびサーバーハードウェアによって異なります。 方法とワークロード テストは、個々のコンポーネントのスケーラビリティとシステム全体のスケーラビリティの 2 段階で行いま した。テストのどちらの段階でも中核を成すのは、実際のワークロードをシミュレートするツールとセッショ ンの起動時間を測定 （予想されるユーザーログオン時間を提供）するために内部で構築されたツールの使用 です。 ワークロードの詳細 - Login Consultants社のLoginVSI スケーラブルな VDI 配備を設計するために最も重要な要素の 1 つは、真のユーザーワークフローを理解し、 サーバーとストレージ容量の観点から適切に計画すると同時に、全体的なユーザーエクスペリエンスの基準 を設定することです。 実際のユーザーワークフローを正確に表すために、システム全体のテストには、Login Consultants 社のサー ドパーティーツールを使用しました。これらのツールは、セッション中の応答時間も測定し、ログインストー ムを初めとする大規模なテストを通してデスクトップへのアクセスで予想されるユーザーエクスペリエンス を測定する手段にもなります。 ワークロードシミュレーションツールとして幅広く利用されている LoginVSI 1.x も、アイドルプール （XenDesktop の機能）使用時に併用してセッションをスピンアップし、全ユーザーが同時にログオンして 作業を行うシナリオをシミュレーションしました（Login VSI はフリーウェアで、www.loginconsultants.com からダウンロードできます）。 Login VSI は、1 台のマシンで同時に実行できるセッション数に基づいて指標を計算するベンチマーク手法で す。これは、ユーザーエクスペリエンスを著しく低下させるような過度な負荷を生成するセッション数を見 つけることを目的としています。 5 Login VSI では、Microsoft Office 2007、Flash アプレットを含む Internet Explorer、および Adobe Acrobat Reader などの一般的なアプリケーション（注: このテスト用に、アプリケーションはストリームまたはホス トせずに、ローカルにインストールしました）を実行している中程度のワークロードユーザー（集約的なナ レッジワーカー）をシミュレーションします。実際のユーザーと同様に、スクリプトされたセッションでは、 同時に複数のアプリケーションが開かれたままになります。各セッションの最低ユーザーアクティビティは、 実際の使用率と同じく平均 20%です。 18 分のループ中に、毎回ユーザーは 1 分当たり 2～3 回ファイルを 開閉します。これは実際より過酷な条件だと思われます。 各ループで以下のアプリケーションを開いて使用します。 Outlook 2007で10件のメッセージを表示し、新しいメッセージを1件入力します。 Internet Explorerを1つ開いた状態で、もう1つ開きMicrosoft.com、VMware.com、およびCitrix.comを ブラウズします（これらのWebサイトのコピーをローカルにキャッシュします）。 Word 2007の1つのウィンドウで応答時間を測定し（9回）、もう1つのウィンドウでランダムドキュ メントを開いて編集し、印刷します。 Solidata PDF WriterおよびAcrobat Readerでは、ワード文書をPDFで印刷し、再表示します。 Excel 2007で、非常に大きなランダムシートを開き、編集します。 PowerPoint 2007でランダムプレゼンテーションを表示し、編集します。 間に 3 回のブレーク（40 秒、20 秒、40 秒）を挟んで、現実の使用法をエミュレートします。 コンポーネントのスケーラビリティに関する結果 以下のコンポーネントのスケーラビリティを個々にテストしました。 Desktop Delivery Controller (DDC) ブレードサーバーのVMWare ESX Server Provisioning Services （このテストは全面的なシステムテストの一環として行われました） 6 XenDesktop Desktop Delivery Controller (DDC) DDC を ESX サーバー上で仮想化し、DDC の役割の一部を特定の DDC に割り当てました。これは、Citrix XenApp 配備によく使用される方法です。 DDC は以下のように構成しました。 DDC 1: Farm Master および Pool Management DDC 2 および DDC 3: VDA レジストレーションおよび XML ブローカーリング この環境では、3 つの DDC （4vCPU、4GB RAM）で 6000 デスクトップのファームサイズを維持できるこ とが示され、5650 ユーザーのプールからの 12 万件を超えるログオンを確実に処理できることが実証されま した。 この規模を保持するには、複数の Virtual Center インスタンスが必要で、さらに各 VC インスタンスには新し い XenDesktop デスクトップグループが必要です。このテストでは、以下のディストリビューションに 5 つ の VC を使用しました。 2 x 2000 デスクトップ 2 x 700 デスクトップ 1 x 600 デスクトップ 配備の安定性は以下の方法で評価しました。 すべてのVMはIdle Pool Managementを使用して電源を投入します。XenDesktopのこの機能により、 ユーザーアクティビティがピークになる前に制御された状態で環境を自動的に立ち上げることがで きます。 7 初期のログオンストームは、1秒間に3人までユーザーをログオンさせて作成しました。 その後、ユーザーのログオフ、リブート、VDAの再登録などの定常負荷をかけました。 シングルサーバーのスケーラビリティ シングルサーバーのスケーラビリティテストは、特定のターゲットマシンでいくつの仮想デスクトップをサ ポートできるか判断することが目的です。特定の機能またはアーキテクチャを評価するために実行できる多 数の置換テストがあります。このテストは、総合的なスケーラビリティテストやガイドラインに先立って行 われるため、広範囲な構成の調査はプロジェクトの範囲外です。 使用している手法は、Project Virtual Reality Check （Project VRC: http://www.virtualrealitycheck.net）をベー スにしています。プロジェクト VRC は、VSI 1.0 を使用してハイパーバイザのスケーラビリティを測定する ことを目的とした 2 つのコンサルティング会社 （Login Consultants 社と PQR 社）の共同事業でした。Citrix と Project VRC のテスト方法には、以下のような重要な違いがあります。 Provisioning Servicesが取り入れられ、1つの共通vDiskからPooled XP Desktopを実行できるように なりました。セッションログインスクリプトの一部を変更し、PVS Write Cacheに影響する不要な ファイルコピー操作を回避しました。この操作はXenApp環境が対象です。 接続は直接ではなく、XenDesktop DDCを介します。 XP仮想デスクトップは512MB RAMに割り当てられますが、ProjectVRCの場合は1GB RAMです。 ローカルプロファイルの代わりに VDI 配備の象徴であるローミングユーザーを使用しました。 各ハードウェアプラットフォームのテストは、十分なメモリおよび CPU リソースがある環境の場合に加え、 メモリと CPU のバインド条件のスケーラビリティを示すことが目的でした。 大規模なテストのVM密度 以下の仕様が採用されました。 Windows XP プールデスクトップ 1vCPU および 512MB RAM ESX 3.5 Update 4 VM/ホスト VM/コア 28 3.5 50 6.25 NFS 上の 1.5 GB PVS キャッシュ （NetApp 3170HA） HP BL460c デュアルクワッドコア (1.86GHz L5320) 16GiB RAM HP BL460c デュアルクワッドコア (2.5GHz L5420) 32GB RAM 8 規模が小さい場合、シングルサーバーの密度をわずかに高くすることが可能ですが、大規模な場合はパフォー マンスの低下が認められました。 テストにより、BL460c 16GB ブレード上の 34 のデスクトップに関して、バルーニングが発生し、十分なメ モリを解放できなくなることがわかりました。 この結果、ESX ホストはゲストメモリとストレージティアのスワップを開始しました。この場合、メモリに あると思われたゲストが実際にはディスク上にあるため、それらのページへのアクセスに待ち時間が発生し、 エンドユーザーのユーザーエクスペリエンスに影響します。ホスト当たりのゲスト数を低減することで、ス ワッピング動作を回避し、環境がスケールアウトされたときに見られるユーザーエクスペリエンスへの影響 を排除できます。 32GB RAM でのテストでは、52 のデスクトップは可能でしたが、システムは CPU バインドが発生しやすい 状態になりました。ユーザーエクスペリエンスに影響するリスクを回避するために、大規模なテストに使用 する密度をわずかに減らしました。 Provisioning Services のスケーラビリティ Provisioning Services のスケーラビリティは、SSS テストの結果に基づいています。PVS からストリームさ れるデスクトップの数を増やしながら、Login VSI スコアとログオン時間をモニタし、ユーザーエクスペリエ ンスが許容範囲内にあることを確認しました。 PVS とストリーミングプールデスクトップの特性を理解す るために、標準の Perfmon 測定値もキャプチャしました。 システム全体のスケーラビリティテストが実行され、ハードウェアの最大容量までユーザーが追加されたた め、1 つの物理的 Provisioning Server で 3300 のデスクトップを簡単にサポートできることが確認できまし た。これは、旧バージョンのテクノロジに関する以前のテストからの劇的な改善と言えます。 9 結果 5000 VDI デスクトップ環境を構築する上で、この一連のテスト結果は、スケーラビリティに対する取り組み 全体に新たなガイドラインを示しました。これは、近い将来、総合的なスケーラビリティガイドに組み込ま れます。 デスクトップと期待されるユーザーエクスペリエンス 大規模な VDI 配備を適切に設計するには、平均的なユーザーがデスクトップとアプリケーションをどのよう に使用するかを十分に理解する必要があります。2 つの重要な要素がログインストームとセッション中のワー クロードです。 このテスト環境では、テストデータによると 5000 デスクトップのログインストーム に対応できます。 LoginVSI ワークロードは 「方法」セクションに記述されている通り、中程度のユーザーの場合です。 ユーザーのワークロードがこの設計に示された平均的ワークロードと大幅に違った場合、サーバーとスト レージコンポーネントサイズを別途概算するために、少なくとも 1 つのサーバー上でワークロードをモデル する必要があります。 Citrix XenDesktop Desktop Delivery Controller XenDesktop Desktop Delivery Controller 構成は、3 つの仮想化ブローカーに役割を分散できるように、エン タープライズ規模のインストレーションを以下のように調整しました。 Farm master （DDC1） DDCがVDAレジストレーションを拒否するようにレジストリを構成しました。 Pool Managementのスロットルは、デフォルトであるプールサイズの10% （グループによって最大 160～170デスクトップ）を変更して40デスクトップで構成しました 。 優先Farm masterとして構成しました。 VDAレジストレーションおよびXMLブローカーリング（DDC2 およびDDC3） プール管理が別のVDAにフェイルオーバーした場合は、前述のプール管理構成の変更が行われます。 この構成について、5000 セッションのサポートがテストされました。 10 推奨されるストレージ 大規模な VDI 配備にとって、スケーラブルなストレージソリューションは、コスト効果と信頼性に優れたソ リューションです。NetApp FAS3170HA には、2 つのコントローラ、ストレージとして 70 x 300GB のドラ イブ、および PAM II カードを使用しました。 NetApp FAS3170HA ファイラーの PAM II モジュールは、 ストレージ上のワークロードが書き込み中心であっ たため、一切ゲインを提供しませんでした。 このバージョンの XenDesktop および VDI 設計には、PAM II カードは必要ないため、推奨しません。 それ以外は、完全なフェイルオーバー状態（1 つの NetApp コントローラが故障するか、それと同様の障害） で何らかの機能低下の可能性が予想される場合、この特別な NetApp 構成が、5000 ユーザー向けの設計とし て推奨されます。 ユーザー固有のフェイルオーバー/リカバリー要件に合わせて NetApp のサイズを調整する ときは、NetApp セールスエンジニアにご相談ください。 FAS3170 は、OnTap バージョン 7.3.2 で PAM II カードが有効な状態で稼働していました。 下図のレイアウ トによると、複数ボリュームのコントローラごとに 1 つの集合体が、各集合体上に作成されました。 注：サイズは、アレイのボリュームサイズです。使用された量ではありません。 11 サーバーハードウェアの結果 実際の仮想デスクトップをホスティングする場合は、ブレードサーバー構成をお奨めします。この設計では、 以下の構成により 1 ホストで約 50 VM を実現できました。 HP BL460 2 x 1.86GHz Intel Xeon L5320 クワッドコア（8MiB L2キャッシュ1066MHzバス） 1 x 36GB HDD SAS 10K rpm 16 GB RAM 667Mhz Dual Broadcom 1Gb NICs QLogic QMH2462デュアルポートファイバチャネルHBA HP BL460c 2 x 2.5GHz Intel Xeon L5420クワッドコア（12MiB L2キャッシュ1333MHzバス） 1 x 72GB HDD SAS 10K rpm 32 GB RAM 667Mhz Dual Broadcom 1Gb NICs QLogic QMH2462デュアルポートファイバチャネルHBA 同様のハードウェア構成でも、最新の Intel Nehalem プロセッサ（55xx シリーズ）と 64～96GB のメモリ構 成を使用した場合、VM 密度が大幅に増加します。 Provisioning Services には、専用のサーバーを使用し、この 5000 デスクトップ設計に対して過剰な条件を設 定しました。HP BL680 を使用しました。 camb5e1b02 Citrix PVS サーバー OS: Windows 2008 64 ビット Service Pack: 1 メーカー: HP モデル: BL680 CPU: 4 x Intel E7450 2.4GHz RAM: 64GiB ディスク: 2 x 72GB 10k SAS ネットワーク： 8 x 1GbE Provisioning Services 5.1 SP2 テストデータから、このサーバーの使用率が極めて低かったことがわかります。 24 のコアサーバーは過剰な設定であったことは明白です。ピークが 30%未満であるということは、7.2 のコ アに匹敵します。 1 つのデュアルクワッドコアサーバーでこの負荷を処理できますが、最大利用に極めて近 くなるため、2 つの 24 コアサーバーの代わりに、3 つの 8 コアサーバーが適切と考えられます。 12 サーバー仮想化の結果 当社のテストでは、2 つのデスクトップグループを構成し、2 つの異なる VMWare Virtual Center サーバーを 指定しました。 Virtual Center 1 は 32 のブレードで 1604 のデスクトップセッションを実行します。 Virtual Center 2 は、61 のブレードで 1708 のデスクトップを実行します。 使用されるソフトウェアバージョン（VMWare ESX 3.5 Update 4）用の VMware のベストプラクティスと公 表されている最大値（1 つの Virtual Center で 2000 VM）に基づいて、環境を 2 つの Virtual Center インスタ ンスに分割しました。 その後、VMWare のバージョン 4.0 がリリースされ、バージョン 3.5 でテストされた 2000 VM という制限が 拡大されました （バージョン 4 では、この制限が 32 ビットのゲストでは 3000、64 ビットでは 4500 にな ります）。一般的に、Virtual Center の数を最小にする構成が推奨されます。 標準のインストレーションへの変更は行われず、推奨もされません。サーバーは論理クラスタに置かれ、1 つのクラスタが 1 つのブレードエンクロージャに対応します。 VMware ESX 3.5.0 ビルド 176894 を環境内のすべての ESX ホストで使用しました。各ホストは、vmnic0 と vmnic1 の両方が接続された 1 つの仮想スイッチを使用して構成されています。 VM Network は、vmnic0 をアクティブ、vmnic1 をスタンバイとして構成されます。 ○ これは、ICA、PVS、および一般的なネットワークトラフィックに使用されます。 サービスコンソールは特定の vmic にバインドされません。 VMotion は、vmnic1 をアクティブ、vmnic0 をスタンバイとして構成されます。 ○ これは NFS および VMotion トラフィックに使用されます。 13 サービスコンソールは 800MiB に割り当てました。 NFS 構成の変更は、『NetApp Technical Report TR-3428』の最新の NetApp ガイダンスに従って行われまし た。 NTP には同期時間を設定しました。 ESX ホストは、ハードウェアをモニタするために最新の HP ESX ユーティリティを使用してインストールし ました。 vmkernel とサービスコンソール間の共有が遮断される問題があるため、BIOS では USB を無効にしました。 VMWare KB の項目 1003710 を参照してください。BIOS では USB が無効ですが、iLO からは USB を使用 できるため、リモートキーボードからのアクセスは引き続き可能であることに注意してください。 スケーラビリティ設計に関するその他の結果 PVS vDiskをCIFSシェア上に置かない。 ○ Windows は、メモリ内のファイルシェアからファイルをキャッシュしないため、PVS サーバーが 呼び出されるたびに共有ストレージにアクセスする必要があります。 VMware Virtual CenterがVirtual Machineにリソース制限を設定していないことを確認 ○ 256MiB のゲストを使用した DDC テストから大規模なテストに移行したときに、VM メモリを 512MiB に増やしましたが、何らかの理由で 256MiB のゲストに使用できるメモリリソースに制限 が設定されました。この結果、512MiB RAM があるように見える VM でも 256MiB の物理的 RAM だけを使用するように制限され、残りは VMware スワップファイルに保持されるため、SAN への ストレージ IO の大幅な増加に繋がり、 大規模環境の機能は 100 デスクトップ未満まで低下します。 確認方法: ［Virtual Machine Properties］→ ［Resources］→［Memory］→［Limit］を選択 VMFSボリュームに過多のVirtual Machinesを置かない ○ NFS 実装には適用できませんが、VMFS ボリュームと VMFS ボリュームに付属する FC も使用した SSS テストでわかります。その影響はユーザーのログイン時間に顕著に表れ、単一の VMFS ボ リューム上の 40 以上のアクティブ VM で急激に拡大します。同数のディスク上で複数ボリューム にこれを分割することで、この問題が軽減されました。 DDCのスケーラビリティを改善するには、.NET 3.5 SP1 （最新のWindows アップデート済み）が必 要です。 14 ○ このアップデートが適用されていないと、ユーザーがシステムへのログインを開始した時点で VDA の登録が取り消されていることに気づきます。これは、デスクトップが 1500 以上の場合に見られ ます。Microsoft が.NET を修正して問題に対応したことで、最大 6000 のデスクトップをテストで きるようになりました。 デフォルトでは、Pool Managementはプール全体の 10%を起動しようとします。大規模な環境では、 このサイズがVirtual Centerの処理能力を超える可能性があります。 ○ 同時要求の数は、Pool Management Service 構成ファイルを編集することで抑制できます。 ○ C:¥Program Files¥Citrix¥VMManagement¥CdsPoolMgr.exe.config ○ <appSetting>セクションに以下のラインを追加します。 ○ <add key=”MaximumTransitionRate” value=”20”/> ○ 新しい構成が読み込まれるように Pool Management サービスを再起動する必要があります。 ○ VMware DRS を使用している場合、電源投入前に DRS がゲストの配置を考慮する時間も必要にな るため、より小さい値を設定する必要があります。DRS を有効にした当社のテストでは、20%に設 定しました。 ○ 当社のテストでは、DRS がフル稼働で初期 VM 配置を行えるようにしました。 その後 DRS を無 効にすると、VC が過負荷になることなく、MaxiumumTransisionRate を 40 に増やすことができま した。 Farm master の役割の割り当て方法は、CTX117477 で詳細に説明しています。XenDesktop PowerShell SDK を使用して、Farm master を適切に構成することもできます。 接続処理を行うFarm masterを停止する場合は、CTX117446 のMaxWorkersレジストリキーを参照し てください。 PVS NICチーミングにより、PVSサーバーの配備が簡単になります。 ○ NIC チーミングは信頼性も向上させます。1 つの PVS サーバーは 1 つの IP アドレスを持つため、1 つのネットワーク接続が遮断された場合、残りの接続で負荷を引き継ぎ、PVS サーバーは現行の IP で動作を継続します。これは、1 つのホストのログインサーバーに対して 1 つの IP アドレスを指定 するだけなので、特にフェイルオーバーと HA に有効です。 さらに、使用可能な NIC を介してク ライアント接続の負荷分散処理をネットワーク層でできるようにします。 15 大規模テストの結果 テストの詳細 3312 デスクトップのテストランは、アイドルプールのスピンアップで構成されます。この詳細は以下の通り です。 ○ すべてのセッションは約 60 分以内に開始されます。 ○ ログオン時間は個々に追跡され、ログオンパフォーマンスの大幅な低下を確実に回避します。 ○ 実行中のすべての Login VSI 1.1 ワークロードとその応答時間が記録されます。 ○ VSI ワークロードフェーズ終了時にユーザーはログアウトします。 これによって、Pool Management によるデスクトップのシャットダウンと再起動がトリガーされます。 ○ PVS HA のテストでは、PVS サーバーで障害が発生した場合でもすべてのデスクトップが稼働し続 けることを確認します。 ○ テスト中にさまざまな製品管理コンソールを使用して、一般的な管理タスクへの応答が常に可能で あることを確認します。 環境：2 つの異なる Virtual Center サーバーを指定する 2 つのデスクトップグループ。 ○ Virtual Center 1 は 32 のブレードで 1604 のデスクトップセッションを実行。 ○ Virtual Center 2 は 61 のブレードで 1708 のデスクトップセッションを実行。 ○ VMware のベストプラクティスと公開された最大値に基づいて、環境が 2 つの Virtual Center イン スタンスに分割されます。Virtual Center 内に、個々のクラスタが （最大 16 のブレードサーバー の）各ブレードシャーシ用に作成されます。 ○ Virtual Center 1 には、より強力なブレードサーバーの 2 つのシャーシ用クラスタがあります。Virtual Center 2 はブレードの残り 4 つのシャーシ用クラスタをホストします。 16 大規模テスト結果のサマリー XenDesktop Idle Pool Management機能を使用すると60分以内で 3312のデスクトップすべてに電源 を投入し、ユーザーがログインできる状態にできます。 起動速度に107/分を指定すると、99%のユーザーが31分でログオンしました。 PVSは1組のHAサーバーから3312のデスクトップを実行できることが示されました。独立したテス トで、PVSサーバーの1つがシャットダウンされるとHAフェイルオーバーがトリガーされました。最 大1600のセッションが 8分以内で他のサーバーに転送されました。 環境のスケーラビリティは、ログオン時間、Login VSIテストの応答時間、およびすべての主要コン ポーネントから収集されたパフォーマンス測定値を分析することにより検証されました。 perfmon（パフォーマンスモニタ）データは、サーバー数が過剰で、このテストで課された以上の負 荷を簡単に処理できることを裏付けています。 ICAファイルを読み込んでからデスクトップを完全に実行するまでにかかる時間は、平均19秒でした。 Login VSIの応答時間は、テスト中、システムはすべてのユーザーが納得できるパフォーマンスレベ ルを維持していることを示しています。 セッションのパフォーマンスとスタートアップ時間 LoginVSI の結果は開始されたセッション数に対する応答時間のキャプチャを示しています。セッション数が 増加するに連れて、名目上は最大応答時間が長くなりますが、全体的な平均応答時間は、一定期間 2000ms 以内に留まることがわかります。 17 起動されたセッションの合計数 3312 未修正最適パフォーマンス指標（UOPI） 3312 UOPI 以前のスタックセッションカウント（SSC） UOPI 以前の損失セッションカウント（LSC） 修正済み最適パフォーマンス指標 （COPI = UOPI ‐（SSC*50%） ‐LSC） 0 44 3268 セッションのスタートアップ時間は、成功した XML ブローカーリングリクエストから ICA ファイルを取得 して、クライアントランチャ上の ICA クライアントが起動してから、セッションのローディングおよび STAT ミニエージェント（Windows のスタートアップフォルダによってロードされた.NET アプリケーション）の ローディングまでの時間の測定値です。この方法で計算されたスタートアップ時間は、テスト環境での実際 のユーザーログオン時間に最も近い値です。 ログオン時間は 15～22 秒の幅でほとんど一致しているように見えます。ただし、いくつかの範囲外セッショ ンは、ログオンストームの終わり近くや初期のユーザー、最初のワークロード実行の途中で、40 秒近い時間 を消費します。 18 最低 最高 平均 11 秒 39 秒 19 秒 19 Desktop Delivery ControllerとProvisioning Servicesのパ フォーマンス 可能な場合は、スピンアップフェーズ中（これは XenDesktop Idle Pool Management によって制御されます） およびテストラン中に環境データが示されます。この場合、すべてのデスクトップでスクリプト一式が最低 でも 1 回実行されるまでに Login VSI 1.x ワークロードがすべてのセッションで実行され、その後 1 つのファ イルがネットワークシェア上にドロップされ、それが Login VSI スクリプトをトリガーし、次にスクリプト が完全に実行された後、ログオフが開始されます。 デスクトップはログオフ時にリブートするように構成されているため、ユーザーがログオフを開始するとシ ステム上に負荷が追加され、その後 Idle Pool Management が再度システムに電源を投入します。 標準の Microsoft Windows perfmon カウンタを使用して、以下のパフォーマンスメトリックを収集しました。 Desktop Delivery Controller のパフォーマンス 前述のように、このテストでは、特定の役割を割り当てた 3 つの DDC を使用しました。すべての DDC がデ スクトップ VM の別々の ESX サーバー上で仮想マシンとして実行されています。4vCPU と 4GB RAM から 構成され、2 x 1.8 GHz クワッドコア L5320 CPU および 16 GB RAM を備えた HP BL460c で実行されます。 20 DDC1: Farm Master + Pool Management プールスピンアップ テストラン中 注意が必要な主要項目は、プールスピンアップ中の高使用率プロセスは CdsPoolMgr プロセスであることで す。このプロセスは Virtual Center にゲストを起動するように指示します。UI が 2 つのデスクトップグルー プを Maintenance モードから切り離すことによって、プールスピンアップ中に IMA サービスのピークが 2 回発生します。 テストランの間は IMASrv がすべてのデスクトップのブローカーリングに関与しているため、デスクトップ の割り当てを決定する間ゾーンマスターがほとんどの負荷を受けます。実行の後半では、デスクトップがロ グオフを開始するため、Pool Management Service はデスクトップのシャットダウンと再起動を開始します。 21 この DDC のメモリ使用率は、ユーザーがログオフする実行の終わりに向けて著しく増加します。これによっ て、汚染検出コードがトリガーされ、VM がシャットダウンされます。一度シャットダウンされてから、Pool Management が再度電源を投入します。 テストの最後でメモリが劇的に増加することを詳しく知るためには、さらなる調査が必要になります。十分 な時間を掛ければ、ガーベッジコレクションがスパイクを収集すると考えられます。 22 テスト終了時のネットワークトラフィック内のスパイクは、プールマネージメントサービスによってシャッ トダウンされ再起動されるデスクトップに対応します。この時点で両方の VC でも同様にトラフィックが増 加することからわかるように、このトラフィックは DDC と Virtual Center サーバーの間です。 23 DDC21: XML + VDAレジストレーション プールスピンアップ テストラン中 DDC1 と比べると負荷は著しく低下しています。主要なアクティブプロセスは、ハートビートや新規登録な ど VDA との通信を処理する CdsController です。 24 IMA Service に関して以前にメモリリークがトレースされたため、ユーザーモードのスタックトレースデー タベースが imasrv.exe 用に作成されました。これ以上のトレースは、通常よりディスクの使用率を高くし、 使用率のベースラインが 20%で安定するのがわかります。 25 DDC3: XML + VDAレジストレーション プールスピンアップ テストラン中 26 負荷プロファイルは予想通り DDC2 と同様です。DDC1 と比べると負荷は著しく低下しています。主要なア クティブプロセスは、ハートビートや新規登録など VDA との通信を処理する CdsController です。 27 28 29 Citrix Provisioning Services （PVS）のパフォーマンス 2 つの PVS サーバーで環境内の 3312 のデスクトップに対応しています。これらのサーバーのプロセッサお よびメモリ構成は、明らかに大幅な過剰指定であることがわかります。サーバーの 8 GB の NIC は NIC チー ムとして構成され、ブレードシャーシにはコアスイッチにアップリンクされた 4x10GbE があります。 PVS サーバーはそれぞれ、4 x E7450 2.40 GHz hex core CPU と 64GB RAM を持つ BL680c ブレードで実行 されています。 PVS Server 1 プールスピンアップ テストラン中 30 トラフィックのピークは、テストランのユーザーログオンフェーズで発生し、2.3Gbps 近くに達します。 31 PVS Server 2 プールスピンアップ テストラン中 24 のコアサーバーは過剰な設定であったことは明白です。ピークが 30%未満であるということは、7.2 のコ アに匹敵します。 1 つのデュアルクワッドコアサーバーでこの負荷を処理できますが、最大利用に近づき過 ぎるため、2 つの 24 コアサーバーの代わりに、3 つの 8 コアサーバーが適切と考えられます。 32 このネットワーク負荷は、他の PVS サーバーに見られる 2.2Gbps 近いピークのある負荷を反映しています。 33 NetAppストレージのパフォーマンス 分析では、スピンアップフェーズより、負荷が著しく高くなる実際のテストランに注目します。以下のサマ リー（NetApp 提供）は、3312 のデスクトップテストに関する重要な読み込み/書き込みと IOPS 情報をまと めています。 3312 の仮想デスクトップの平均 読み込み 書き込み 平均ネットワーク読み込み/書き込み率 11.5% 88.5% 最大ネットワーク読み込み/書き込み率 20.5% 79.5% 平均ディスク読み込み/書き込み率 14.2% 85.8% 最大ディスク読み込み/書き込み率 17.8% 82.2% IOPS デスクトップ当たりの平均 IOPS 4.4 デスクトップ当たりの最大平均 IOPS 27.7 分析 ○ ストレージコントローラ上の 4 つの CPUS のうち 2 つ以上が完全に使用されている状態にはなら ず、正常な動作範囲内に留まり、クラスタフェイルオーバー中のパフォーマンスが不要な場合はさ らなる増加に対応する余裕がありました。 ○ すべてのプロトコルの平均待ち時間は、十分に妥当なパフォーマンスの範囲内で、優れたユーザー エクスペリエンスを与えられます。 ○ テストランの最初と最後に、CIFS ワークロードがプロトコル使用率の 50%を占めました。これは、 テスト開始時の大量の読み込み（ユーザープロファイルのロード時）およびテスト終了時の大量の 書き込み （ユーザープロファイルの書き込み時）と思われます。 ○ テストのそれ以外の部分では、PVS クライアント側キャッシュの利用に関して NFS が主要な役割 を果たしました。 ○ FCP （ファイバチャネル）は、ワークロードがファイラー上にない場合は、ほとんど影響しませ ん。FCP は、環境内のさまざまなコンポーネントのデータベーストラフィックに限定されました。 ○ すべての IO の大半は、すべてのプロトコルへの書き込みでした。 ○ 平均および最大ディスク使用率は 40%を超えたことはなく、これらのコントローラにより多くの仮 想マシンに対応できる余裕があることを示しています。 ○ クラスタが故障した場合、データからファイラーがパフォーマンスをほとんどまたはまったく損な うことなく、3000～4000 のデスクトップを処理できることがわかります。 34 VMWare Virtual CenterとESXのパフォーマンス 2 つのブレードサーバーを物理的 Virtual Center サーバーとしてインストールしました。各 VC 内に、最大 16 の ESX ホストのブレードシャーシごとに 1 つのクラスタが作成されます。実験室には 2 種類のハードウェア スペースがあるため、各 VC でホストされる仮想デスクトップの数は均等ではありません。 Virtual Center 1 ブレードシャーシ ホスト数 仮想マシン数 camb4e1 16 898 camb4e2 16 800 合計 32 1698 テスト中、1604 のデスクトップだけが実際に使用されました。残りの VM の電源はオフのままですが、Virtual Center と XenDesktop Pool Management ではこれもカウントしています。これらの追加の VM は、初期のブ ローカースケーラビリティテストから存在しています。 Virtual Center 2 ブレードシャーシ ホスト数 仮想マシン数 camr3e1 16 481 camr3e2 14 392 camr5e1 16 480 camr5e2 15 420 合計 61 1773 前述のデスクトップの他に、VC2 はいくつかのインフラストラクチャ VM （3 つのブローカーと 1 つの NetApp パフォーマンスモニタなど）をホストする camr5e2b13 も管理します。 1773 のデスクトップ VM のうち、1708 だけに電源を投入しました。VC1 と同様に、これらの追加の VM は、 初期のより高ホスト密度でのテストから存在していました。 35 Camr3e2b15: Virtual Center 1 プールスピンアップ テストラン中 vpxd サービスは、XenDesktop Pool Management が VM の電源投入またはシャットダウンを要求していると きに実行されます。この状況は、スピンアップ中とテストランの最後で見られます。 このサーバーには 8 つのコアがあるので、ピーク時の 200%は、2 つのコアがすべて使用されている状態と 同等です。 36 37 Camr3e2b16: Virtual Center 2 プールスピンアップ テストラン中 vpxd の負荷は 2 つの VC サーバー間で一致しています。 このサーバーには 8 つのコアがあるので、ピーク時の 230%は、2 つのコアがすべて使用されている状態よ り少し多くなります。 38 各VCで使用されるメモリは同じですが、VC2は300MiB以上になります。このことは、VC2が2倍の数のESX ホストとより多くのVMゲストを管理していることから予測できます。 39 ESX のパフォーマンス テスト環境は、デスクトップワークロードを実行する 2 種類のハードウェア構成から成ります。以下に、32 GB RAM と 2 つの L5420 クワッドコア CPU を持つ BL460c のデータを示します。 プールスピンアップ テストラン中 40 このトラフィックは、 NFS 共有ストレージ上にある VM のアクティビティの追跡ではなく、ESX ホストの ローカルの物理ディスク上で発生します。ディスクアクティビティの頻度は、VM のパフォーマンスデータ など一部のロギングの参考になります。トラフィック量は、実行されている仮想マシンの数に比例していま す。 41 要約 ユーザーワークロードは、すべての設計推奨値に大きく影響するので、そのシミュレーション方法には 十分すぎるほど時間と注意を費やしてください。 ○ ユーザーの総数とログインストームが発生する状況と時期を必ず考慮します。 現実に近いユーザーワークロードのシミュレーションには、Login Consultants社のLoginVSIなど、信 頼できるフリーツールを使用します。 フェイルオーバーの設計は、フェイルオーバー時の適切なユーザーエクスペリエンス（デグレードの有 無とその程度）に基づいて、インフラストラクチャのサイズを決定します。 ○ 拡張と信頼性を考慮して中央ストレージを使用します。 XenDesktopの主要コンポーネントのほとんどを仮想化します。 ○ この設計のプロビジョニングサーバーは仮想化されませんでした。高スケーラビリティのためには、 設計に専用の物理サーバーを用意する必要があります。仮想化 PVS の実行はオプションですが、 最近の文書ではこれを推奨しています。 42 付録A - ブレードサーバーハードウェアと配備 テスト環境は主に HP ブレードサーバーで構成されます。特別なテストコンポーネントのインフラストラク チャをホスティングする追加サーバーの一部について、この後本書で詳しく説明します。VMware ESX は、 （V1）、（V2）のラベルが付けられた 2 つの仕様の異なる BL460 サーバー上にインストールされ、Windows XP Desktop と小数の VMs for XenDesktop Brokers （DDC）の両方のホストとして使用されました。BL680 サーバーは、2 つの Citrix Provisioning Services と Microsoft SQL Server のホストとして使用されました。こ れらのマシンは、それぞれの役割について多少過剰に指定されました。 BL460c (v1) – 1.86Ghzデュアルプロセッサクワッドコア 16GB RAM 2 x 1.86GHz Intel Xeon L5320クワッドコア（8MiB L2キャッシュ 1066MHzバス） 1 x 36GB HDD SAS 10K rpm 16 GB RAM 667Mhz Dual Broadcom 1Gb NICs QLogic QMH2462デュアルポートファイバチャネルHBA 製品の概要: http://h18000.www1.hp.com/products/servers/proliant-bl/cclass/460c/index.html BL460c (v2) – 2.5Ghzデュアルプロセッサクワッドコア 32GB RAM 2 x 2.5GHz Intel Xeon L5420クワッドコア（12MiB L2キャッシュ 1333MHzバス） 1 x 72GB HDD SAS 10K rpm 32 GiB RAM 667Mhz Dual Broadcom 1Gb NICs QLogic QMH2462デュアルポートファイバチャネルHBA 製品の概要: http://h18000.www1.hp.com/products/servers/proliant-bl/cclass/460c/index.html 43 BL680 G5 – 2.4Ghzクワッドプロセッサ Hex Core 64GB RAM 4 x 2.4GHz Intel Xeon E7450 Hex Core （9MiB L2キャッシュ （12MiB L3キャッシュ） 1000MHzバス） 2 x 72GB HDD SAS 10K rpm 64 GiB RAM 667Mhz 8 x Broadcom 1Gb NICs QLogic QMH2462デュアルポートファイバチャネルHBA 製品の概要: http://h18000.www1.hp.com/products/servers/proliant-bl/cclass/680c/ind ex.html 44 45 付録B - ネットワーク図 これは、主に仮想マシンを実行している HP ブレードを基盤にした環境です。Dell 1950 1U Servers を使用し て、同じサーバー上で多数の ICA クライアントを実行し、環境に接続しています。 この環境は、元々ストレージトラフィックにファイバチャネルを使用するように設計されましたが、このテ ストでは、管理のシンプルさとスケーラビリティを備えた NFS が使用されました。 すべてのトラフィックはラック最上部の Cisco 2960-G スイッチか、中央の Cisco 4510 シャーシ背面のブレー ドにある Cisco ブレードスイッチモジュールのいずれかに送られます。 このシャーシには、監視モジュール の他に、複数の 1GbE および 10GbE ラインカードが格納されます。ブレードスイッチでスタックをサポート するところでは、この機能が使用されました。 46 ファイバチャネルストレージネットワーク ファイバチャネルネットワークは、BL680 ブレードサーバーの 1 つで実行されている SQL サーバーのデー タベースにだけ使用されます。他のすべてのストレージトラフィックは、Ethernet リンク上の NFS を使用し ます。 47 参考文献 Citrix (ナレッジベース記事) XenDesktopファームでファームデータストアとコントローラを別々のサーバーに設定する方法 (CTX118486) XenDesktopで使用される主なレジストリエントリ (CTX117842) NetApp: Deployment Guide for XenDesktop 3.0 and VMware ESX Server on NetApp (TR-3795) NetApp and VMware Virtual Infrastructure 3 Storage Best Practices (TR-3428) Citrix XenServer 5.0 and NetApp Storage Best Practices (TR-3732) Citrix XenDesktop 2.0 with NetApp Storage— Pilot Deployment Overview (TR-3711) 2,000-Seat VMware View on NetApp Deployment Guide Using NFS (TR-3770) Project VRC / Login Consultants: VRC, VSI and Clocks Reviewed VMware Platform Performance Index v1.1 XenServer Platform Performance Index v1.0 VMware: VMware Virtual Infrastructure 3.5 Configuration Maximums Comparison of Storage Protocol Performance NetApp FAS2020HA Unified Storage 48 Citrixについて Citrix Systems, Inc.（Nasdaq:CTXS）は、仮想化、ネットワーキング、およびソフトウェアに特化したトッ ププロバイダーであり、これらのサービス技術を世界中の 23 万社以上もの企業や組織に対して提供していま す。同社の Citrix Delivery Center、Citrix Cloud Center（C3）、Citrix Online Services の各製品ファミリーは、 ユーザーがどこにいて、どんなデバイスを使用していようとも、すべてのユーザーに対してアプリケーショ ンをオンデマンドで配信することにより、数百万ユーザーを対象としたコンピューティングを根本的に簡素 化します。Citrix の顧客には、世界最大級のインターネット企業である各社、Fortune Global 500 に選ばれて いる企業のうちの 99%、および数十万もの中小企業やプロシューマーが含まれています。また、Citrix は、 100 ヶ国以上の 1 万を超える企業とパートナー契約を結んでいます。同社は 1989 年に設立され、2008 年度 の収益は 16 億ドルでした。 ©2010 Citrix Systems, Inc. All rights reserved. Citrix®、Access Gateway™、Branch Repeater™、Citrix Repeater™、HDX™、XenServer™、XenApp™、XenDesktop™ および Citrix Delivery Center™は、Citrix Systems, Inc.またはその子会社の登録商標であり、米国の特許商標局およびその他の国に登録されています。 その他の商標や登録商標はそれぞれの各社が所有権を有するものです。 49