Windows Server 2012 環境の Microsoft 仮 想 デ ス ク ト ッ プ イ ン フ ラ ス ト ラ ク チ ャ (VDI) 上にプールされた 2,000 台の接続クライアントの仮想マシン コレクションのキャパシティ プランニング

Microsoft Corporation発行日: 2013 年 8 月

要約Microsoft 仮想デスクトップ インフラストラクチャ (VDI) では、ユーザーごとに個別の仮想マシン (VM) を提供し、その VM のデスクトップ (クライアント側) オペレーティング システム (Windows Server 2012) を使用します。Microsoft VDI でデスクトップを提供する方法には、セッション、プールされた VM、または個人用 VM を使用する 3 通りの方法があります。このホワイト ペーパーは、Microsoft Hyper-V を実行する 1 つ以上のサーバーに分散する複数の VM をプール化した VDI 環境のキャパシティ プランニングを行うための運用ガイドです。Windows Server 2012 を基盤とする VDI を使用すると、ユーザーは、データ センターで実行されている再現性の高い Windows 環境に任意のデバイスからシームレスにアクセスできるようになります。また、組織は VDI を採用することで次のメリットを享受できます。プラットフォーム。Windows Server 2012 は、ホストされたデスクトップを種類に関係なく提供できる単一のプラットフォームを提供し、展開を簡素化して管理を容易にします。エクスペリエンス。Microsoft RemoteFX は、アクセス先の仮想デスクトップの種類やユーザーが各自のデスクトップにアクセスしている場所に関係なく、一貫してリッチなユーザー エクスペリエンスを提供します。展開の選択。このドキュメントではプールされた VM を対象に説明していますが、VDI ではセッションベースのデスクトップや個人用 VM もホストできます。そのため、お客様はユーザーに適したタイプの VDI デスクトップを選択し、柔軟な展開が可能です。また、こうした作業はすべて単一のプラットフォームから行います。このホワイト ペーパーは、Windows Server 2012 の VDI にプールされた 2,000 台の接続クライアントの VM 展開について、Dell の Windows Server 2012 用デスクトップ仮想化サービス リファレンス アーキテクチャを用いてキャパシティ プランニングを実施する運用ガイドです。本書では、Login VSI ツールの実行により得られた、プールされた VM 展開の収容能力に影響を及ぼす最も関連が深い要素について説明し、Login VSI の中程

度のワークロードに対する一連のテスト結果を提供します。

著作権情報このドキュメントは暫定版であり、最終的な製品版の発売時に実質的に変更されることがあります。このドキュメントに含まれる情報は米国 Microsoft Corporation が所有する機密情報です。この機密情報は、受領者と米国 Microsoft Corporation との間で締結された機密保持契約書に基づいて開示されるものです。このドキュメントに記載された内容は情報提供のみを目的としており、明示的または黙示的にかかわらず、マイクロソフトはいかなる責任も負わないものとします。このドキュメントに記載されている情報 (URL 等のインターネット Web サイトに関する情報を含む) は、将来予告なしに変更することがあります。お客様がこのドキュメントを運用した結果の影響については、お客様が負うものとします。別途記載されていない場合、このソフトウェアおよび関連するドキュメントで使用している会社、組織、製品、ドメイン名、電子メール アドレス、ロゴ、人物、場所、出来事などの名称は架空のものです。実在する商品名、団体名、個人名などとは一切関係ありません。お客様ご自身の責任において、適用されるすべての著作権関連法規に従ったご使用を願います。このドキュメントのいかなる部分も、米国 Microsoft Corporation の書面による許諾を受けることなく、その目的を問わず、どのような形態であっても、複製、検索システムへの保存または譲渡することは禁じられています。ここでいう形態とは、複写や記録など、電子的な、または物理的なすべての手段を含みます。ただしこれは、著作権法上のお客様の権利を制限するものではありません。

マイクロソフトは、このドキュメントに記載されている内容に関し、特許、特許申請、商標、著作権、またはその他の無体財産権を有する場合があります。別途マイクロソフトのライセンス契約上に明示の規定のない限り、このドキュメントはこれらの特許、商標、著作権、またはその他の無体財産権に関する権利をお客様に許諾するものではありません。

© 2013 Microsoft Corporation. All rights reserved.

Microsoft、Active Directory、Excel、Hyper-V、Internet Explorer、Outlook、PowerPoint、SQL Server、Windows、および Windows Server は、米国 Microsoft Corporation および/またはその関連会社の商標です。

その他、記載されている会社名、製品名には、各社の商標のものもあります。

目次Windows Server 2012 環境の Microsoft 仮想デスクトップ インフラストラクチャ (VDI)

上にプールされた 2,000 台の接続クライアントの仮想マシン コレクションのキャパシティ プランニング.................................................................................................4このガイドについて...............................................................................................4はじめに...............................................................................................................5特定の展開のキャパシティ プランニング.................................................................6

システムの収容能力を決定する要因......................................................................7使用シナリオ...................................................................................................7ハードウェア リソース.....................................................................................8

VDI のアーキテクチャ.........................................................................................8一般的な評価手法.................................................................................................11

負荷シミュレーション テスト.............................................................................12シナリオの定義..............................................................................................13シナリオの実装..............................................................................................14テストの実行.................................................................................................14結果の評価....................................................................................................14

テスト方法..........................................................................................................15テスト展開の概要..............................................................................................15

高可用性の実現..............................................................................................16プールされた VM の構成.................................................................................17VDI の計算ノードおよび記憶域ノードの仕様に対応する Dell R720VDI ホスト

サーバー.....................................................................................................17Dell R620 インフラストラクチャ ホストの仕様................................................18Dell 910 Login VSI 負荷ランチャーの仕様.......................................................19

負荷の生成..........................................................................................................21応答時間の測定.................................................................................................22テスト結果.......................................................................................................23CPU の負荷......................................................................................................23ネットワークの負荷..........................................................................................24SQL Server の負荷...........................................................................................24高可用性 RD 接続ブローカー サーバーの負荷.......................................................26RD 接続ブローカーの構成..................................................................................261 台の VM の負荷.............................................................................................28

まとめ................................................................................................................30リソース.............................................................................................................32

Windows Server 2012 環境の Microsoft 仮 想 デ ス ク ト ッ プ イ ン フ ラ ス ト ラ ク チ ャ (VDI) 上にプールされた 2,000 台の接続クライアントの仮想マシン コレクションのキャパシティ プランニング

このガイドについてこのガイドでは、Dell の Windows Server 2012 オペレーティング システム用デスクトップ仮想化サービス (DVS) リファレンス アーキテクチャに変更を加えた展開と Login VSI 3.7 のテストに基づいて、Microsoft 仮想デスクトップ インフラストラクチャ (VDI) における 2,000 台の接続クライアントのプールされた仮想マシン (VM) コレクションに関する比較データを提供します。このガイドは、VDI を展開する際のインフラストラクチャ ニーズの特定に役立ててください。

6

はじめにサーバーベースのコンピューティング環境では、アプリケーションの実行とデータの処理はすべてサーバー上で行われます。このため、サーバーの負荷がピークに達すると、リソース不足により展開全体のサービスが中断する事態に陥りやすくなります。したがって、サーバー システムのスケーラビリティと収容能力をテストして、特定の展開シナリオに対して 1 台のサーバーがサポートできるクライアント セッション数を判断しておくことが非常に重要です。このホワイト ペーパーでは、特定の展開におけるシステムの収容能力を評価するガイドラインと一般的な評価手法について説明します。その展開とは、Windows Server 2012 オペレーティング システムの VDI 上の 2,000 台の接続クライアントのプールされた VM 展開であり、Windows Server 2012 用 DVS リファレンス アーキテクチャに似ています。また、重要は推奨事項については、Microsoft Office アプリケーションを使用したシナリオにより用例を示しながら説明します。また、サーバーで実際にサポートできるセッション数に大きな影響を及ぼす可能性がある、ハードウェアとソフトウェアのパラメーターに関するガイドラインも提供します。VDI 展開のキャパシティ プランニングは多数の要因に左右され、画一的な解決策というものはありません。使用シナリオとハードウェア構成によっては、収容能力の差が 100 倍に達することもあります。正確な見積もりが要求される場合、信頼できる手段は、パイロット展開か独自の負荷シミュレーションの実行のどちらか一方であることがほとんどです。つまり、パフォーマンス データはワークロードとシステム構成に影響を受けやすいため、結果も異なります。

7

特定の展開のキャパシティ プランニングサーバーの VDI を計画する際に直面する主な疑問点の 1 つに「ホストごとのユーザー数」があります。つまり、「特定の構成で何人のユーザーをホストできるか」、あるいは「N 人のユーザーをホストするにはどのような構成が必要か」を把握する必要があります。複数のユーザーによって生じる負荷をサポートできるシステム構成の決定は、あらゆるサービス (Microsoft Exchange Server、インターネット インフォメーション サービス (IIS)、SQL Server など) で直面する代表的な課題です。これは、サーバーの役割でサポートするワークロードが、ワークロードのプロファイルを示す比較的少数のトランザクションやパラメーターによって定義される場合でさえ、答えを出すのが難しい質問です。ドメイン ネーム システム (DNS) は、DNS クエリだけで負荷を定義できる良い例です。VDI では、ユーザーごとに個別の VM および関連付けられたハードウェアが必要です。ユーザーのアクセス頻度が低く、リソースの負担も少ない、比較的軽量のアプリケーション (データ入力アプリケーションなど) をホストする VM もあれば、大量の CPU、RAM、ディスク、ネットワーク帯域幅などが必要な、非常に要件が厳しいコンピューター支援設計 (CAD) アプリケーションをホストする VM もあります。特に、正確なサイズ設定と構成は、次のように下限と上限の両方で明確にする必要があります。 許容できるレベルでユーザーのアプリケーションが機能するように、展開のサイズを調整する必要がある。たとえば、Microsoft Office 2013 を実行する 500 人のユーザーが存在し、それぞれ 20 GB のメモリが必要な場合、すべてのユーザーをホストするには 10 TB のサーバー ディスク領域が必要になる

展開の目標を達成するために必要な数を大幅に超えることなく、適切な数のリソースをプロビジョニングする

下限については、要因となるアプリケーションやそのようなアプリケーションにユーザーがアクセスできる方法が多岐にわたるため、パフォーマンスの評価基準を客観的に説明するのが困難です。仮想サーバー アプリケーションのパフォーマンスに対するユーザーによる典型的な不満の 1 つは、パフォーマンスが低いか、システムからの応答がないことです。しかし、パフォーマンスの低下が他の形で現れることもあります。たとえば、パフォーマンスの平均は許容範囲内に収まっていても、円滑で安定した応答ではなくぎくしゃくした動作が発生し、応答はあるものの時折一気に進んだり待ちが発生したりすると、きわめて操作性が悪化します。パフォーマンスの低下の許容範囲は、展開ごとに大きく異なります。業務上不可欠で、パフォーマンスの大きな低下がどの時点でも許容されないシステムもあれば、パフォーマンスが大きく低下するピーク時の負荷が短期間なら許容されるシステムもあります。展開の収容能力のサイズ調整作業においては、パフォーマンスに関するユーザーの期待値が明確になっていることが重要な要素です。

システムの収容能力を決定する要因サーバーの特定のシナリオをテストする方法について詳しく説明する前に、サーバーのスケーラビリティに影響を及ぼす要因を把握しておくことが重要です。このような要因は、大きく分けると使用シナリオとハードウェア リソースの 2 種類に分類できます。

使用シナリオ特定のサーバーの収容能力を決定するうえで非常に重要な要因は、使用シナリオです。使用シナリオとは、サーバーに展開されたアプリケーションに対してユーザーが行う一般的な操作の流れです。あるハードウェア構成の 1 台のサーバーでも、シナリオによっては、サポートできるユーザー数が 2 人から 200 人まで変化することがあります。リソース使用量が少ないシナリオであれば、そのサーバーは多数のユーザーをサポートできます。こ

8

のような負荷の低いシナリオの例としては、ユーザーがシンプルな基幹業務アプリケーションでデータを入力する場合が挙げられます。一方、リソース使用量が多いシナリオでは、サーバーはそれほど多くのユーザーをサポートできません。負荷の高いシナリオの例としては、CPU の使用率が高く入出力 (I/O) 回数が多い CAD アプリケーションを操作する場合や、複雑なソフトウェア開発環境を操作する場合が挙げられます。注 サーバーでサポートできるユーザー数を見積もる場合、そのユーザー数が有効なのは特定のシナリオに該当するときだけです。シナリオが変化すれば、サポートできるユーザー数も変化します。

シナリオを決定する一般的な要因は、システム ソフトウェアの構成、使用されるアプリケーション、アプリケーションごとに実行される特定の機能、処理対象データの量と内容、行う操作、および操作の速度です。ドキュメント編集のような単純なシナリオでも影響を及ぼす可能性がある重要要因がいくつかあります。その例を次に示します。 ユーザーがメモ帳と Microsoft Word のどちらで入力しているか

使用している Word のバージョン

スペル チェックが有効になっているか

ドキュメントに画像が含まれているかどうか、ドキュメントにグラフが含まれているかどうか

どの程度の速さで入力するか

セッションにおける色の解像度はどの程度か

ユーザーが Microsoft PowerPoint のプレゼンテーションの編集に負荷の高いアニメーションを使用するかどうか

上記の要因のいずれかを変更すると、結果が大きく異なる可能性があります。

ハードウェア リソースサーバーのハードウェアは、サーバーの収容能力に大きな影響を及ぼします。考慮する必要がある主なハードウェア要素は、CPU、メモリ、ディスク記憶域、およびネットワークです。これらの各要素による影響の詳細については、このホワイト ペーパーの後半で説明します。

VDI のアーキテクチャVDI は、スケーリングの問題に対処するいくつかの手段を提供します。VDI 環境を構成するには、3 通りの方法があります。必要とされるサーバーの空き容量順に図 1 に示します。 セッション

プールされた VM 個人用 VM

9

図 1. VDI 展開オプション

Windows Server 2012 の VDI では、セッション、個人用 VM、またはプールされた VM をすべて同じプラットフォームを使用して展開できます。しかし、実際の状況に適したアーキテクチャをどのように選択すればよいでしょうか。この 3 つの展開モデルには、次のようないくつかの共通の利点があります。 Microsoft System Center テクノロジを利用したシンプルなセットアップ、インテリジェントな修正プログラムの適用、および統合管理を可能にする、システム標準の管理コンソールを使用した強力な管理機能

LAN および WAN 全体での一貫してリッチなユーザー エクスペリエンス

次の要点に基づいて適切なアーキテクチャを判断することができます。 カスタマイズ。ユーザーは各自のデスクトップをカスタマイズできる必要があります

か。その場合、ユーザーはどのレベルのカスタマイズを必要としていますか。セッションおよびプールされた VM では、異なるログイン間でデータを保持する機能など、ユーザーがユーザー プロファイル ディスクを使用してカスタマイズできる機能が限られます。一方、個人用デスクトップでは (当然、ユーザーが各自のデスクトップに対して管理者権限を持っていることを前提とします)、ユーザーはユーザーがインストールしたアプリケーションをログイン間で保持することはできませんが、独自のアプリケーションを複数のログインでインストールするなど、各自のデスクトップのあらゆる要素を変更できます。

アプリケーションの適合性。セッションベースのデスクトップでは、共通のサーバー オペレーティング システムを共有します。そのため、インストールされるアプリケーションはすべて Windows Server オペレーティング システムとの適合性が必要になります。一方、どちらのプールされた VM シナリオでも、VM 内で実行されているのは Windows クライアント オペレーティング システムです。したがって、アプリケーションの適合性は常にセッションよりも VM の方が高くなります。ただし、プールされた VM では、ユーザーに表示されるアプリケーションが IT によって決定されるのに対し、個人用 VM では、ユーザーが独自のアプリケーションをインストールできます。そのため、3 つすべての展開モデルの中でアプリケーションの適合性レベルが最も高いのは、個人用 VM だと言えます。

ユーザー集約率。セッションでは、1 つのサーバー オペレーティング システムを共有するため、1 台のセッションベース サーバーでホスト可能なユーザーの数は、常に VM ベース モデル (個人用、プール化共に) よりも多くなります。場合によっては、セッションでのユーザー密度が VM でのユーザー密度の 2 倍になることもあります。プールされた VM では、すべての VM インスタンスが共通の親ディスクを共有するため、通常、プールされた VM ごとに約 3 ～ 5 GB の範囲で差分ディスクを使用します。

10

また、ユーザー データはローカルに保存されない、あるいは個別のユーザー プロファイル ディスクに保存されるので、それらのサイズは個人用 VM よりも小さくなるのが一般的です。そのため、記憶域のサイズ設定の観点から、プールされた VM の密度は他と比べてはるかに高くなります。使用される記憶域の容量は、VM にユーザーの状態とアプリケーション仮想化テクノロジを採用することによって削減できますが、それでも密度はセッションよりも低くなります。

イメージ。単一のイメージを実現するのが目標であれば、セッションベースのデスクトップを使用するか、プールされた VM を展開するのが目標達成に向けた最善の方法です。セッションベースのデスクトップでは、すべてのユーザーが単一のサーバー イメージを共有するのに対し、プールされた VM では、すべてのユーザーが単一のマスター イメージから複製されたコピーを取得します。単一イメージの構成は、より管理しやすく、各ユーザーが独自のイメージを取得する個人用 VM よりもコストが低くなります。

コスト。セッションは密度が最も高く単一イメージであるため、一般的により管理しやすく、また最もコストが低くなります。プールされた VM では、セッションの単一イメージと管理上のメリットを得られますが、比較的高い密度と高度な管理作業によってセッションよりも展開にコストがかかります。個人用 VM では、最も低い密度と最も高度な管理作業により、3 つの展開モデルの中で最もコストが高くなります。ただし、Windows Server 2012 では、コストの低い記憶域 (サーバー メッセージ ブロック (SMB)や、DAS 記憶域など)、アプリケーションの仮想化、動的メモリ、およびユーザー プロファイル ディスクをサポートしているため、企業は全体的な VDI の総保有コスト (TCO) を低減できることを念頭に置いてください。

このホワイト ペーパーでは、このユーザー シナリオに最適な展開モデルとしてプールされた VM に焦点を当てています。

11

一般的な評価手法上記の考慮事項から、キャパシティ プランニングの疑問点には、事前に構成した一連の数値に基づいても、それほど正確な結論を下せないことがわかります。実際の展開やシミュレーションで測定した数値のいずれかを選んで、シナリオやハードウェア構成がかなり異なる別の展開に適用することは、発生する可能性がある誤差を考えれば、必ずしも実用的ではありません。したがって、展開シナリオに影響を及ぼす要因を慎重に考慮しない限り、高い精度は期待できません。見積もりの誤差を減らして適切な数値にする実用的な手法は存在しています。通常、これらの手法では、費やす労力と結果の精度との間でさまざまなトレードオフが発生します。以下に、いくつかの手法を示します。 パイロット。これは、おそらく最も一般的でシンプルな手法です。1 台のテスト サー

バーを構成して展開したら、ユーザーのフィードバックを監視しながら徐々に負荷を増やします。ユーザーのフィードバックを基に、許容範囲のユーザー エクスペリエンスが実現されるほぼ最高レベルで負荷が安定するまで、システムの負荷を増減して調整します。この手法は、非常に信頼性が高く、シンプルであるというメリットがあります。しかし、最終的には展開目標に適していないと判断が下される場合でも、ハードウェアやソフトウェアに初期投資を行う必要があります (たとえば、必要な強化を実現できるほどのメモリをサーバーでサポートできないかもしれません )。さまざまな負荷指標 (CPU 使用率、ページング、ディスク キューやネットワーク キューの長さなど) を監視して、ボトルネックになる可能性がある箇所を特定し、ハードウェア リソース (CPU、RAM、ディスク、ネットワーク アダプターなど ) を追加してボトルネックを解消することで、この手法をさらに強化できます。ただし、負荷の度合いは制御できないため、負荷指標の変化と実際のシステム操作の関連付けは困難です。

シミュレーション。この手法では、特定の使用シナリオについて収集したデータを基に、シミュレーションを構築します。シミュレーションでは、テスト サーバーでさまざまなレベルの (通常は徐々に増加する) 負荷を生成するために特定のツールを使用して、ユーザー操作をタイムリーに処理させた際のサーバーの処理能力を監視します。この手法では、使用シナリオのシミュレーションを構築するために、非常に高額な初期投資が必要です。また、シミュレーションを行ったシナリオが実際の使用シナリオを正確に再現しているかどうかによって、結果が大きく異なります。ただし、シミュレーションが正確であれば、許容できる負荷のレベルと制限となる要因を非常に正確に特定でき、さまざまなソフトウェア構成とハードウェア構成を繰り返し調整可能な環境を構築できます。

シングル ユーザー システムに基づく予測。この手法では、シングル ユーザー システムから収集したデータを基に予測を立てます。この場合、メモリ使用量、ディスク使用量、ネットワーク使用率などの主要メトリックをシングル ユーザー システムから収集した後、これらの指標を参考にして、マルチ ユーザー システムにおいて想定される収容能力を予測します。この手法には、システムとアプリケーションの運用に関する詳しい知識が必要になるため、実装が非常に困難です。さらに、シングル ユーザー システムのデータには、システム ソフトウェアの影響による、かなりのレベルの "ノイズ" が含まれるため、信頼性もあまり高くはありません。また、高度なシステム モデリング機能が備わっていないため、データの収集に使用した参照システムから適用先サーバーにハードウェアのパフォーマンス メトリック (CPU 速度、ディスク速度) を変換する作業が、複雑で困難になります。

一般に、最初の手法を採用すると、比較的小規模な展開で時間とコスト効率が向上します。2 つ目の手法は、サーバーの収容能力を正確に特定することが購入決定に大きく影響する、大規模展開に適していることがあります。このホワイト ペーパーでは、Login VSI ツールを使用して 2 つ目の手法 (シミュレーション) を実行します。

12

負荷シミュレーション テストこのガイドでは、負荷シミュレーションを生成するために、 Windows Server 2012 用 DVS リファレンス アーキテクチャ (http://www.dell.com/Learn/us/en/555/business~solutions~engineering-docs~en/Documents~dvs-windows-server-2012.pdf?c=us&l=en&s=biz) と Login VSI ツ ー ル (http://www.loginvsi.com) に基づいて負荷シミュレーション テストを実行することにしました。使用した展開は、DVS アーキテクチャとまったく同じではありません。具体的には、Dell と Microsoft が、スケールアウト SMB サーバー (元のアーキテクチャでは、仮想化 SMB) とローミング ユーザー プロファイル (元のアーキテクチャでは、ユーザー仮想ハード ディスク (VHD)) を使用して、展開を共同で開発しました (図 2 参照)。

図 2. DVS の展開

負荷シミュレーションは、特定のシステムの収容能力を見積もる比較的正確な手法の 1 つです。この手法は、ユーザー シナリオを明確に把握でき、なおかつこのシナリオが比較的変化せず、それほど複雑ではない場合に適しています。通常、負荷シミュレーションは、それぞれ独立した次のフェーズで構成されます。

シナリオの定義展開の対象となる使用シナリオを適切に定義することが、重要な前提条件です。シナリオの定義は、シナリオに関連するアプリケーションが多岐にわたったり、使用パターンが複雑だったりするために、難しくなることがあります。妥当性のある正確さで使用シナリオを定義することは、おそらくこの手法の中で最もコストがかかるフェーズでしょう。また適切なユーザー操作の組み合わせを把握するだけでなく、適切な内容のデータ (ドキュメント、データ ファイル、メディア コンテンツなど) を使用することも重要です。これは、システムの全体的なリソース使用量ではデータの内容が重要な役割を果たす場合があるためです。このようなシナリオは、ユーザーへのインタビュー、ユーザー操作の監視、主要なインフラストラクチャ サーバーに関するメトリックの追跡、プロジェクトの目標などを基に組み立てることができます。

VDI における 2,000 台の接続クライアントから成るプールされた VM 展開

高可用性 VDI 管理インフラストラクチャ VDI の計算ノードと記憶域ノード

インフラストラクチャ サーバー 1 インフラ

ストラクチャ

サーバー2

イン

フラ

スト

ラク

チャ

サー

バー

1

と同じ

ワー

クロ

ード

1

ゲートウェイ

RD WEB

RD ブローカー

ネットワーク: LAN および iSCSI トラフィック用の 10 GB + VLAN 2 つ

SMB スケールアウト ユーザーのドキュメントと

設定用の記憶域

クラスター化

DELL S4810 スイッチ 2 台

クラスター化

プールされた VM

プールされた VM

プールされた VM

VDI ホスト 1 VDI ホスト

VDI ホスト

14

RAID 10/同等

VHD

記憶域

15,000 ディスク

15,000 ディスク

15,000 ディスク

15,000 ディスク15,000 ディスク

OS ブート ディスク 10x 15,000 ディスク (RAID1+0)

サーバー サーバー

13

シナリオの実装このフェーズでは、自動ツールを使用して、テスト システムに対して複数のコピーを同時実行できるようにシナリオを実装します。理想の自動ツールとは、クライアントからアプリケーションのユーザー インターフェイスを操作し、サーバーのリソースをほとんど使用せず、信頼性が高く、サーバー負荷の増大によりアプリケーションの動作が変更されても柔軟に対応できるツールです。また、このフェーズでは、システムを運用できる負荷レベルの範囲の測定に使用するメトリックを明確に把握することや、シナリオの自動ツールがこのようなメトリックの収集に対応するように調整できることも重要です。そこで、Login VSI の中程度の負荷シナリオを使用しました。

テストの実行テストの実行では、サーバーに対する負荷を徐々に増やしながら、システムの実行可能性評価に使用するパフォーマンス メトリックを監視します。また、システムのさまざまなパフォーマンス メトリックを収集して、システムの応答が低下した際に負荷がかかっているリソースの種類を後から特定できるようにしておくことも有効です。さまざまな調整を施すために、この手順を繰り返し実行することもできます。

結果の評価これが最後の段階です。この段階では、パフォーマンス メトリックなどのテスト中に収集したパフォーマンスに関するデータに基づいて、展開のパフォーマンス要件を満たしつつシステムでサポートできる許容範囲の負荷を判断でき、不足するとパフォーマンスが低下し始めるリソースの種類を特定できます。重大なリソースの不足を軽減して負荷の収容能力を増加させるためにハードウェアの調整を繰り返し行う場合、ここでの結論を元に進めることができます。この収容能力の評価手法は、かなり正確な数値が必要な場合にお勧めの手法です。特に、大規模システムの展開で、ハードウェアの規模を正確に調整するとコストが大きく削減される場合や、誤差が小さいことが望ましい場合は、この手法をお勧めします。ここでは、以下の理由から、さまざまな事項を説明するために使用したテスト データにも、同じ手法を使用しました。 特定の条件下でのサーバーの収容能力をきわめて正確に測定できる

第三者がテスト結果を再現して確認できる

参照テスト環境でのさまざまな構成変更をより正確に評価できる

14

テスト方法このホワイト ペーパーでは、ここで行う説明の多くの例を示すために、テスト ラボで得られたさまざまな結果を引用しました。これらのテストは、マイクロソフトのラボで実施しました。テストでは、前述の効果的な負荷テストを行うための要件がすべて満たされるよう、セッション ベースの VDI に対する負荷テストのシミュレーション専用に開発された一連の Login VSI ツールを使用しました。また、これらのツールを使用して、Office 2013 と Internet Explorer に基づくいくつかのシナリオを実装しました。さらに、これらのシナリオに対して行ったさまざまな操作の応答時間を使用して、各構成で許容できる負荷レベルを評価しました。

テスト展開の概要

高可用性を構成した Windows Server 2012 Hyper-V ハイパーバイザーと Office 2013 をインストールしました。前述のように、テスト コントローラー、クライアント コンピューター、およびテスト サーバーにテスト ツールを配置しました。この展開の収容能力は、主に VDI ホストの数に応じて決まります。管理インフラストラクチャをアップグレードしなくてもホストをさらに追加することで収容能力を高めることは容易ですが、ローミングまたはリダイレクトされるフォルダーが構成された従来のデスクトップの場合と同様に、ユーザーのドキュメントと設定用の記憶域を増やすことが必要な場合があることを念頭に置いてください。とはいえ、このアーキテクチャの別の利点として、ユーザーのドキュメントと設定用の記憶域の設計が VDI の設計とは切り離されるため、特にプールされた VM に適していることが挙げられます。このテスト展開は Windows Server 2012 用 DVS リファレンス アーキテクチャに基づくものの、まったく同じではありませんでした。具体的には、Dell と Microsoft が、スケールアウト SMB サーバー (元のアーキテクチャでは、仮想化 SMB) とローミング ユーザー プロファイル (元のアーキテクチャでは、ユーザー VHD) を使用して、展開を共同で開発しました。通常、テスト環境は分離されたネットワークで運用し、次の 3 つのカテゴリのコンピューターを含めます (図 3 参照)。 テスト対象のプールされた VM をホストする Hyper-V サーバー

シナリオに必要なインフラストラクチャ サーバー (IIS、SQL Server、Exchange Server など)、または基本サービス (DNS、動的ホスト構成プロトコル、Active Directory ドメイン サービスなど) を提供するインフラストラクチャ サーバー

負荷の生成に使用する複数のテスト クライアント

15

図 3. テスト インフラストラクチャの概要

分離されたネットワークを構築すると、VDI のトラフィックやアプリケーション固有のトラフィックによるネットワーク トラフィックの干渉が発生しないため、このネットワークの構築は非常に重要な作業です。このような干渉は、テスト メトリックに影響を及ぼすランダムな速度低下を招く原因となり、サーバーでのリソース不足に起因する速度低下と区別しにくくなることがあります。

高可用性の実現管理層の高可用性を実現するために、1 台のホストとさらに複数層の冗長性を追加しました。次の要素によって、ソリューション内の重要な各インフラストラクチャ コンポーネントが保護されます。 Hyper-V で管理ホストが構成されます。

管理 VM をホストする記憶域ボリュームがクラスターの共有ボリュームにアップグレードされます。

RD 接続ブローカーの高可用性をサポートするために、SQL Server インスタンスが環境に追加されます。

SQL Server の保護をより一層強化するために、必要に応じて SQL Server のミラーリングを構成できます。

高可用性を実現するために、RD 接続ブローカーが構成されます (図 4 参照)。

ランチャー

ランチャー

ランチャー

ランチャー

ランチャー

ランチャー

ランチャー

ランチャー マネージャー

ランチャー

ランチャー

ランチャー

ランチャー

ランチャー

ランチャー

ランチャー

高可用性ブローカー

Dell 910 HyperV Dell 910 HyperV

VDI 展開

2,000 VM…

ラン

チャ

ー V

M 5

0 台

ラン

チャ

ー V

M 5

0 台

16

図 4. 高可用性の構成

プールされた VM の構成プールされた VM は次のように構成しました。 Windows 8 (x86 ベース) Office 2013 1 基の仮想 CPU (vCPU) 起動メモリ: 512 MB 動的メモリ: 有効 ローミング ユーザー プロファイル: 有効

VDI の計算ノードおよび記憶域ノードの仕様に対応する Dell R720VDI ホスト サーバーサーバーは次のように構成しました。 オペレーティング システム名: Windows Server 2012 Datacenter Edition バージョン: 6.2.9200 ビルド 9200 システム製造元: Dell Inc. システム モデル: PowerEdge R720 システムの種類: x64 ベース PC プロセッサ: Intel Xeon CPU E5-2690 0 @ 2.90 GHz、2,900 MHz、8 コア、16 論理

プロセッサ

BIOS バージョン/日付: Dell Inc. 1.6.0、2013/3/7 SMBIOS バージョン: 2.7 埋め込みコントローラーのバージョン: 255.255 BIOS モード: レガシ

BaseBoard メーカー: Dell Inc.

Hyper-V 管理クラスタークラスターの共有ボリューム

管理 VM SQL ミラー RD 接続ブローカー クラスター

17

プラットフォームの役割: Enterprise Server ハードウェア アブストラクション レイヤー (HAL): バージョン = "6.2.9200.16420" インストール済みの物理メモリ (RAM): 256 GB 合計物理メモリ: 256 GB ページ ファイル領域: 34.0 GB

Dell R620 インフラストラクチャ ホストの仕様サーバーは次のように構成しました。 オペレーティング システム名: Windows Server 2012 Datacenter Edition バージョン: 6.2.9200 ビルド 9200 システム製造元: Dell Inc. システム モデル: PowerEdge R620 システムの種類: x64 ベース PC プロセッサ: Intel Xeon CPU E5-2680 0 @ 2.70 GHz、2,700 MHz、8 コア、16 論理

プロセッサ

BIOS バージョン/日付: Dell Inc. 1.6.0、2013/3/7 SMBIOS バージョン: 2.7 埋め込みコントローラーのバージョン: 255.255 HAL: バージョン = "6.2.9200.16384" インストール済みの物理メモリ (RAM): 96.0 GB 合計物理メモリ: 96.0 GB ページ ファイル領域: 12.5 GB

Dell 910 Login VSI 負荷ランチャーの仕様サーバーは次のように構成しました。 Dell 910 Hyper-V サーバー 2 台 1 台の Dell 910 マシンあたりランチャー VM 50 台 各ランチャー VM でリモート デスクトップ プロトコル (RDP) クライアント 20 台を起動

ランチャー VM の構成: 8 基の vCPU、8 GB オペレーティング システム名: Windows Server 2012 Datacenter Edition バージョン: 6.2.9200 ビルド 9200 システム製造元: Dell Inc. システム モデル: PowerEdge R910 システムの種類: x64 ベース PC

18

プロセッサ: Intel Xeon CPU L7555 @ 1.87 GHz、1,862 MHz、8 コア、16 論理プロセッサ

プロセッサ: Intel Xeon CPU L7555 @ 1.87 GHz、1,862 MHz、8 コア、16 論理プロセッサ

プロセッサ: Intel Xeon CPU L7555 @ 1.87 GHz、1,862 MHz、8 コア、16 論理プロセッサ

プロセッサ: Intel Xeon CPU L7555 @ 1.87 GHz、1,862 MHz、8 コア、16 論理プロセッサ

BIOS バージョン/日付: Dell Inc. 2.8.2、2012/10/25 SMBIOS バージョン: 2.6 埋め込みコントローラーのバージョン: 255.255 BIOS モード: レガシ

プラットフォームの役割: Enterprise Server HAL: バージョン = "6.2.9200.16420" インストール済みの物理メモリ (RAM): 512 GB 合計物理メモリ: 512 GB ページ ファイル領域: 68.0 GB

19

負荷の生成全ユーザーに対して、ユーザー プロファイルのテストおよび構成時にローミング ユーザー アカウントを作成しました。この作業には、Login VSI の中程度のワークロード (v 3.7) シナリオの各ユーザーに対する、アプリケーションで使用されるテンプレート ファイルのコピー、Internet Explorer のホーム ページのセットアップ、および Microsoft Outlook の電子メール アカウントの構成が含まれています。すべてのコンポーネントをクリーンな状態に戻すために、各テストの実行前にはサーバーおよびクライアント コンピューターの自動再起動を実行しました。テスト コントローラー (Login VSI Manager) で、1 時間に 100 のランチャーから 2,000 接続を開始しました (ランチャーごとに 20 台の RDP クライアントを起動)。その結果、VDI 全体で 3,600 秒間に 2,000 回のログイン (つまり、1 分間に約 33 回のユーザー ログイン) が行われました。ネットワーク レベルの認証を取得するために各起動がブローカーに送信されると、ブローカーはそれを 2,000 台のプールされた VM のいずれかに渡します。2,000 回のログインが 14 台のサーバーのそれぞれに対して約 140 ～ 150 回のログインに分散され、CPU 使用率のピークが 75 ～ 80% になるように保たれます。次の点に注意してください。 このワークロードでは、Office 2013、Internet Explorer、および PDF テクノロジの

中程度の負荷を想定しています。

セッションが開始された後、中程度のワークロードを 12 分ごとに繰り返し実行します。

各ループ中に、2 分ごとに応答時間を測定します。

中程度のワークロードで同時に 5 個のアプリケーションを開きます。

各文字の入力速度は 160 ミリ秒です。

実際のユーザーの動作をシミュレーションするために、約 2 分のアイドル時間を含めます。

各ループでは、次のアプリケーションで作業を実行します。 Microsoft Outlook 2013: 10 通の電子メールを閲覧

Internet Explorer: 1 つのインスタンスで BBC.co.uk を開いた状態にし、1 つのインスタンスごとに Wired.com と Lonelyplanet.com を表示

Microsoft Word 2013: 1 つのインスタンスで応答時間を測定し、1 つのインスタンスで文書を閲覧/編集

Bullzip PDF Printer および Acrobat Reader: Word 文書を出力し、PDF として閲覧

Microsoft Excel 2013: 非常に大きいランダムな表を開く

Microsoft PowerPoint 2013: プレゼンテーションを閲覧/編集 7-zip: コマンドライン バージョンを使用してセッションの出力を圧縮

応答時間の測定ユーザー シナリオは、一連の操作をグループ化することで組み立てられています。操作シーケンスは、テスト スクリプトによって開始されます。このスクリプトでは、セッションで実行しているアプリケーションの 1 つにクライアント経由でキー入力を送信します。キー入力の結果として、アプリケーションでなんらかの処理が実行されます。たとえば、

20

Ctrl キーを押しながら F キーを押す操作を Word に送信すると、Word で [ファイル] メニューが表示されます。基本的にここでのテスト方法は、アプリケーションでの処理につながるすべての操作 (テキストの入力を除く) の応答時間を測定することです。応答時間は、キー入力から結果として行われる処理までの時間と定義されます。キー入力がクライアント上のテスト ツールからプールされた VM クライアントに送信されると、クライアント側でタイムスタンプ (T1) が取得されます。サーバー アプリケーションで処理が行われるときに、各リモート デスクトップ セッション内で実行されているテスト フレームワーク ツールでこのことが検出されます。サーバー側のテスト ツールからクライアント側のツールに確認が送信されると、クライアント側のツールで別のタイムスタンプ (T2) が取得されます。操作の応答時間は、式 T2 − T1 で算出されます。この測定で、実際の応答時間を見積もることができます。この見積もりは、誤差が数ミリ秒以内に収まる程度に正確です。システムの応答性で定義されているように、応答時間の測定は、最も信頼性が高く直接的なユーザー エクスペリエンスの測定値となるため重要です。CPU 使用率やメモリ消費量などのパフォーマンス メトリックを参照しても、システムがまだ許容できる稼働状態にあるかどうかについてはおおよその状態しかわかりません。たとえば、CPU 使用率が 90% だとしても、ユーザー エクスペリエンスを正確に特定することは困難です。応答時間では、テスト中の任意のタイミングでのユーザー エクスペリエンスが正確にわかります。サーバーのユーザー数が増加するにつれて、ある時点から、すべての操作にかかる応答時間が低下し始めます。このようなパフォーマンスの低下が発生する一般的な原因は、サーバーの 1 つ以上のハードウェア リソースが不足し始めるためです。パフォーマンスの低下点は、そのシナリオでサーバーが応答しなくなり、その結果負荷がサーバーの収容能力を超えたと見なされる状況で判断されます。シナリオ全体のパフォーマンス低下点を判断するために、以下の条件に基づいて操作ごとにパフォーマンスの低下点が特定されます。 初期応答時間が 200 ミリ秒未満の操作の場合、平均応答時間が 200 ミリ秒と初期値の

110% を超えた時点がパフォーマンスの低下点と見なされます。

初期応答時間が 200 ミリ秒を超える操作の場合、平均応答時間の増加量が初期値の 10% を超えた時点がパフォーマンスの低下点と見なされます。

これらの条件は、応答時間が 200 ミリ秒未満であれば、ユーザーは応答時間の遅延を認識しないという前提に基づいています。一般に、サーバーの CPU 使用率が飽和状態になると、同じユーザー数でもほとんどの操作で応答時間の低下点に達します。サーバーのメモリが不足し始めると、ファイル I/O を伴う操作では、他の操作 (ダイアログ ボックスを開いて、開いたり保存したりするファイルを選択する操作など) に比べて急激にパフォーマンスが低下します (ページングが頻繁に行われることで I/O サブシステムに負荷がかかるため)。

テスト結果この収容能力の評価手法は、かなり正確な数値が必要な場合にお勧めの手法です。特に、大規模システムの展開で、ハードウェアの規模を正確に調整するとコストが大きく削減される場合や、誤差が小さいことが望ましい場合は、この手法をお勧めします。ここでは、以下の理由から、さまざまな事項を説明するために使用したテスト データにも、同じ手法を使用しました。 特定の条件下でのサーバーの収容能力をきわめて正確に測定できる

第三者がテスト結果を再現して確認できる

参照テスト環境でのさまざまな構成変更をより正確に評価できる

予期しない処理の急増が発生したときの "緩衝材" となる

21

CPU の負荷各ホストをその最大 CPU 使用率に達するようにすることも可能でしたが、実環境に近いユース ケースをテストするために CPU 使用率を 80% に維持し、ホストごとに 150 台の VM を実行することにしました。これは、予期しない処理の急増が発生したときの緩衝材となります。図 5 は、2,000 台の接続クライアントのプールされた VM 展開に対する Login VSI のベンチマーク結果を示しています。Login VSI の最大値には達しなかったことがわかります。

図 5. 14 台の Dell 720 サーバー上で実行されている 2,000 台のプールされた VM

この図は、各 VM がログインの約 15 秒以内に Login VSI の中程度のワークロードの実行を開始する環境で、60 分間に 2,000 回のログインが行われたことと、その応答時間 (ミリ秒単位) を示しています。ワークロード構成の結果である応答時間の詳細については、Login VSI の ド キ ュ メ ン ト (http://www.loginvsi.com/documentation/v3/analyzing-results/calculating-vsimax) を参照してください。VDI 管理インフラストラクチャ上の負荷は低いものでした。この管理インフラストラクチャでは、2,000 台の接続クライアントの実行による負荷は軽いことがわかるため、さらにホストを追加してこのような展開を容易に拡張することができます。

ネットワークの負荷セットアップした LAN 環境 (2x10 GB) では、ネットワーク上の RDP によって生成された負荷は、Login VSI の中程度のワークロードを実行している 1 台のプールされた VM あたり約 400 kbps (平均) でした。したがって、この 2,000 台の接続クライアントから成る展開のユーザー トラフィックは約 800 Mbps ということになり、展開したネットワーク インフラストラクチャの収容能力をはるかに下回りました。ローカル記憶域を使用しているため、ネットワーク上には RDP トラフィックのみが存在することに注意してください。

SQL Server の負荷図 6 は、SQL Server VM 上の CPU および I/O の負荷を示しています。SQL Server は、Windows Server 2012 の高可用性 RD 接続ブローカー モデルの重要な要素です。このモデルでは、高可用性 RD 接続ブローカー サーバーで SQL Server を使用して展開設定を保存します。お客様は、エンタープライズ間の高可用性を実現するブローカーを構成するた

VSI の最大値に達していないベースライン = 1588

VSI の最大値

最小応答平均応答最大応答VSI インデックス平均

22

めに、いくつかの SQL Server の高可用性モデルから選択できます。

図 6. 2,000 接続時の SQL Server の負荷

SQL Server インスタンスは次のように構成しました。 4 基の vCPU、8,192 GB (約 6 GB の空き領域、2 GB のみ使用) 1 時間に 2,000 接続

Dell R720 マシン上で実行されている SQL Server VMCPU の負荷 (図 6 の赤線) は実際の値の 10 倍で示されているため、負荷は約 3 ～ 4 パーセントの I/O であり、30 パーセントではないことに注意してください。つまり、1 時間のログイン期間に CPU の 4% しか使用しておらず、システムにはほとんど負荷がかかっていません。このように使用率が低いことから、既存の SQL Server 展開を使用することもできます。そのため、より多くの VM をホストしたり、より高速なログインを処理したりすることが容易にできます。CPU の負荷は経時的に増加します。特定時間あたりのユーザー数を半分の時間で処理できるようにしたい場合、負荷は約 3 ～ 4% から約 6 ～ 8% に増加することになります。たとえば、15 分間に 2,000 人のユーザーがログインすると、SQL Server インスタンスの負荷が 4 倍になり、CPU 使用率は約 20% になります。さらに、5 分で同じユーザー数を処理できるようにしたい場合、CPU 使用率は約 80% になります。

高可用性 RD 接続ブローカー サーバーの負荷ブローカーは次のように構成しました (図 7 参照)。 2 基の vCPU、8,192 GB (約 6 GB の空き領域、2 GB のみ使用) Dell R720 マシン上で実行されているブローカー VM

赤:

CPU%

(10 倍

の縮尺

)緑

: デ

ィス

ク IO

/ 秒 (1

倍の縮尺

)物理ディスク 3K ディスク転送数/秒 11.362

プロセッサ _合計 % プロセッサ時間 2.494

23

図 7. 2,000 接続時の高可用性ブローカーの負荷

図で示されているとおり、ブローカーには使用されていない多くの収容能力があり 、2,000 回のログインを容易に処理できました。おそらく、2 つ目のブローカーは必要なかったでしょう。スパイクは、各ユーザー ログインおよびさまざまなディスクでの値を示しています。VM はログインするまでオフの状態で、その後約 500 M/s のデータが Hyper-V メモリに読み込みまれます。このスパイクは、ユーザーがログインする前に VM を起動することで低減できます。

RD 接続ブローカーの構成図 8 は、14 台の VDI ホストのうち 1 台における CPU と記憶域の負荷を示しています。

図 8. Logon VSI の中程度のワークロードを実行している Office 2013 を搭載した 150 台の Windows 8 (x86 ベース) VM を使用した、2,000 台の接続クライアントから成る展開のベンチマークにおける 1 台の Dell 720 マシン上の CPU とディスク I/O の負荷

CPU%

(1 倍

の縮尺

) \\RDBRKR01 プロセッサ _合計 % プロセッサ時間 1.793

赤:

CPU%

(1 倍

の縮尺

)緑

: デ

ィス

ク読

み取

り数

/ 秒 (0

.01 倍

の縮尺

)青

: デ

ィス

ク書

き込

み数

/ 秒 (0

.01 倍

の縮尺

)

論理ディスク D: ディスクの速度 (秒)/読み取り0.006 ディスクの速度 (秒)/書き込み0.000

物理ディスク 1D: ディスク読み取り数/秒 991.159 ディスク書き込み数/秒 752.008

ピーク時の記憶域のパフォーマンス:

CPU ~ 75%

24

Logon VSI の中程度のワークロードを実行している 150 台の VM を使用した場合、CPU 使用率は約 80% です。負荷をかけている間、I/O 負荷は 1,000 回の読み取り/秒、ディスクへの書き込みは 800 回/秒でした。ホストごとのローカル記憶域は、RAID (Redundant Array of Independent Disks) 1+0 として構成された 10x 15,000 ディスクから成り、必要な 1 秒あたりの I/O (IOPS) を容易に処理できます。また、ディスクの応答時間は短く保持されます。つまり、この記憶域はより高い負荷やより高速なログインなどを処理できるはずです。正確なタイミングを特定することは困難ですが、確かな経験則としては、10 台のディスク アレイの I/O 能力を約 2,000 回の読み取り IOPS と 1,000 回の書き込み IOPS で見積もります。また、1 時間のログイン期間にわたる 150 台の VM からの I/O 負荷は約 1,743 回なので、30 分間での同じワークロードは約 3,500 IOPS になり、ローカル アレイの I/O 能力を超えてしまいます。ログイン期間がより短い (時間枠あたりのログイン数が多い) 場合、短いログイン サイクルでは I/O 負荷がローカルのスピンドル ディスクの I/O 能力を超えることがあります。そこで、ゴールド VM 用に 1 ～ 2 つのスピンドル ディスクを容量の小さな (250 GB) ソリッドステート ディスク (SSD) に交換することをお勧めします。10 コレクション未満の展開では、仮想デスクトップ テンプレート用に 250 GB SSD を使用することによって、より重いワークロードでの高速ログインの実現に必要な追加のパフォーマンスを容易に提供できるはずです。

1 台の VM の負荷図 9 では、1 台のゲスト VM が当初約 800 MB で動作しており (アイドル状態)、CPU 使用率も低いままであることがわかります。その後、緑の縦線で示されている 11:25 あたりで、ユーザー ログインが実行され、少ししてから Logon VSI のワークロードの実行が開始されています。ベンチマークが始まると、メモリ使用量と同様に CPU 使用率が増加し始め、そこで Hyper-V 動的メモリによって追加の RAM が提供されます。最終的に、ゲスト RAM は 1 GB 程度に落ち着きます。このパターンが VDI ホスト上のすべての VM に対して繰り返されます。VDI ホストでは、150 台の VM が CPU の約 75% の累積的な CPU 使用率で約 150 GB のメモリを消費します。各サーバーは 256 GB の RAM で構成されているため、CPU のスパイクや多くのメモリが必要になる可能性のある実際のワークロードに対応できるかなりの余裕があります (ただし、その 256 GB の一部は、親パーティションで実行されるサービス用に予約されています)。

25

図 9. 1 台の VM 上のワークロード

図 10 は、約 150 台の VM を実行していた 14 台の VDI ホストのうち 1 台におけるゲスト物理メモリの例を示しています (色付きの線は、それぞれ特定の VM のメモリ使用量を示します)。最大 2 GB に対応できるように動的メモリを構成し、スタートアップの値を 512 MB に設定しました。すべての VM でログオンが行われ、最初の 1 時間の終わりまで Logon VSI ワークロードが実行されています。すべての VM が約 500 MB のメモリで動作を開始し、Logon VSI の中程度のワークロードの実行中に 1 GB 程度に落ち着くことがわかります。

図 10. 1 台の Dell R720 マシンにおけるメモリ消費量: Logon VSI の中程度のワークロードを実行している Office 2013 を搭載した 150 台の Windows 8 (x86 ベース) コンピューター

1 台のゲスト VM が約 800 MB の RAM で動作を開始

ゲスト VM 内の可視メモリ

メモリ使用量が増加すると、Hyper-V 動的メモリによって使用可能な追加の RAM が提供され、最終的に 1 GB 程度に落ち着く

11:25 AM あたりでユーザー ログオンが実行され、VSI ベンチマークが始まると、メモリ使用量と CPU 使用率が増加することに注目してください。

ゲスト VM の vCPU 使用率

ゲス

トの

可視

物理

メモ

リ (1

0 M

B 単位

)

次の 1 時間最初の 1 時間

26

27

まとめこれらの結果は、説明目的での代表的なシナリオとして選択した中程度のワークロード シナリオを示しています。実際の構成は環境によって異なります。正確な見積もりが必要な場合は、独自の負荷シミュレーションを実行することをお勧めします。デュアル ソケットの E5-2690 @ 2.90 GHz サーバーでの Logon VSI 3.7 の中程度のワークロードについて、表 1 にまとめています。表 1. 1 台のサーバーあたりの中程度のワークロード

VM 密度 CPU の最大 80%、1 ユーザーあたり 1 基の vCPU で、10 ユーザー/コア

メモリ Office 2013 搭載 Windows 8 (x86 ベース) 用に 1 GB の RAM IOPS 10 IOPS/VMLAN 上の RDP ネットワーク負荷

最大 400 Kbit/秒 (平均すると Logon VSI の中程度のワークロード以上)

表 2 のように、表 1 の見積もりを参考にして、さまざまな規模の展開における VDI の CPU、RAM、および記憶域の要件を計画することができます。表 2. さまざまなユーザー数に対する記憶域の要件

ユーザー数 CPU ソケット数

RAM 記憶域のサイズ

記憶域の負荷

LAN トラフィック

150 2 192 GB 1 TB 1,500 IOPS 60 Mbps600 8 768 GB 3 TB 6,000 IOPS 240 Mbps1,200 16 1.5 TB 5 TB 12,000 IOPS 480 Mbps2,100 28 3 TB 10 TB 21,000 IOPS 1 Gbps

デュアル ソケットの E5-2690 @ 2.90 GHz サーバー、192 GB の RAM、10x 15,000 RAID 1+0 構成を使用して、必要なサーバー数を表にまとめることができます (表 3 参照)。表 3. さまざまなユーザー数に必要なサーバー数

ユーザー数 VDI サーバー数

150 1600 41,200 82,100 14

さらに、管理ワークロード (RD ブローカー、SQL Server など) を実行するために 2 台のサーバーが必要です。また、これらの VM 用に比較的容量の小さな共有記憶域と、ユーザーの設定、プロファイル、ドキュメントなどのために高可用性記憶域も必要になります。VDI によって、ハードウェアとソフトウェアを構成する際に特定のシナリオに対応するための強化を効果的に実現できます。このテストでは Dell のアーキテクチャに変更を加えた展開で、プールされた VM をホストする 14 台の Dell R720 マシンと高可用性 VDI 管理インフラストラクチャ用の 2 台の Dell R620 マシン を使用して、2,000 ユーザーによる Logon VSI の中程度のワークロード シナリオを容易に処理することができました。

28

リソース「How to Setup Mirroring in SQL Server」 (http://www.sqlserver-training.com/how-to-setup-mirroring-in-sql-server-screen-shots/-)

Microsoft TechNet のその他のリソース:

「ミラーリング用のミラー データベースを準備する方法 (Transact-SQL)」 (http://technet.microsoft.com/ja-jp/library/ms189047.aspx)

「データベース ミラーリング セッションを構成する方法 (SQL Server Management Studio)」 (http://technet.microsoft.com/ja-jp/library/ms188712(v=sql.105).aspx)

ブログ エントリ「Hot off the presses, get it now, the Windows 8 VDI optimization script, courtesy of PFE!」 (http://blogs.technet.com/b/jeff_stokes/archive/2013/04/09/hot-off-the-presses-get-it-now-the-windows-8-vdi-optimization-script-courtesy-of-pfe.aspx)

29