設計手法管理レイヤー

管理レイヤーは、設計手法の4番目の層です。

Active Directory

決定する事項:フォレスト設計

マルチフォレスト環境には、デフォルトでフォレスト間のインタードメインの信頼関係がありません。AD管理者は複数のフォレスト間で信頼関係を確立し、あるフォレストのユーザーとコンピューターが別のフォレストのリソースを認証してアクセスできるようにすることができます。

インタードメインの信頼があるフォレストには、Delivery Controllerが両方のドメインと通信できるように適切な設定を構成することが推奨されます。適切な信頼関係が構成されていない場合は、各フォレストに対して複数のXenDesktopサイトを構成する必要があります。このセクションでは、製品ごとの記憶要件について概説し、サイジング計算について説明します。詳しくは、シトリックスの記事:CTX134971 - 「Successfully Deploying XenDesktop in a Complex Active Directory Environment」を参照してください。

決定する事項:組織単位構造

XenAppおよびXenDesktop環境用のインフラストラクチャコンポーネントは、それぞれ専用の組織単位(OU)内に配置する必要があります。管理目的で作業者と管理者を分けます。独自のOUを持つことで、内部のオブジェクトは管理の柔軟性が高まり、Citrix管理者は委任された制御を受けることができます。

Citrix OU構造の例を以下に示します。

Citrix OUイメージ

決定する事項:ユーザーグループ

可能であれば、権限と承認を個々のユーザーではなくユーザーグループに割り当てる必要があります。これにより、ユーザーアカウントの作成、変更、または削除時に大量のリソースの権限とユーザー権利を編集する必要がなくなります。権限アプリケーションの例:

  • 1,000人のユーザーからなる1つのグループに公開されたアプリケーションでは、1,000人すべてのユーザーに対して1つのオブジェクトのみを検証する必要があります。
  • 1,000の個々のユーザーアカウントに発行された同じアプリケーションでは、1,000のオブジェクトすべての検証が必要です。

データベース

このドキュメントで説明しているシトリックス製品の大多数はデータベースを必要とします。次の表に、製品ごとの使用状況の概要を示します:

この表では:

  • Yは、利用可能であることを示します。
  • Oは、オプションを示します。
製品 構成データ ランタイムデータ 監査/変更ログデータ 監視データ
XenDesktop Y Y Y Y
Provisioning Services Y   O  
デスクトッププレーヤー Y Y Y Y

決定する事項:エディション

Microsoft SQL Server 2012には複数のエディションがあります:Express、Web、Standard、Business Intelligence、およびEnterprise。利用可能なSQL Serverのさまざまなエディションの機能に基づいて、Standardエディションは実稼働環境でXenAppおよびXenDesktopデータベースをホストするためによく使用されます。

Standardエディションは、ほとんどの環境のニーズを満たすのに十分な数の機能を提供します。シトリックス製品でサポートされているデータベースの詳細については、「シトリックスデータベースサポートマトリックス(英語)」を参照してください。シトリックス製品のバージョンが異なると、SQLサーバーのバージョンも異なります。そのため、サポートマトリックスを確認して、使用されているSQLサーバーのバージョンが、展開されているシトリックス製品と互換性があることを確認することが重要です。

決定する事項:データベースサーバーのサイジング

SQL Serverは、環境のパフォーマンスと安定性を確保するために正しいサイズにする必要があります。各シトリックス製品はそれぞれ異なる方法でSQLサーバーを使用するため、一般的な包括的サイズ設定の推奨事項は提供できません。代わりに、製品ごとのSQLサーバーのサイズ設定に関する推奨事項を以下に示します。

XenAppおよびXenDesktop

XenAppおよびXenDesktopブローカーは、ブローカー通信、構成データの保存、および監視ログデータと構成ログデータの保存のためのデータベースをメッセージバスとして使用します。データベースは常に使用されており、SQLサーバーに対するパフォーマンスの影響は大きいと見なすことができます。

シトリックスの内部スケーラビリティテストの結果に基づいて、すべてのXenDesktopデータベースをホストしているサーバーに対して次のSQLサーバー仕様が推奨されます:

  • 最大5,000ユーザーの環境の場合、2コア / 4GB RAM
  • 最大15,000ユーザーの環境の場合、4コア / 8GB RAM
  • 15,000人超のユーザーの環境の場合、8コア / 16GB RAM

データベースファイルとトランザクションログは、多数のトランザクションに対処するために別々のハードディスクサブシステム上でホストする必要があります。たとえば、20,000台の仮想デスクトップを15分の起動ストームの間に登録すると、1秒間に最大500のトランザクションが引き起こされ、30分のログオンストームの間に20,000人のユーザーがログオンすると、1秒間に最大800のトランザクションがXenDesktopサイトデータベースで引き起こされます。

Provisioning Services

静的構成データに加えて、Provisioningサーバーはデータベースにランタイム情報と監査情報を格納します。起動と管理のパターンに応じて、データベースのパフォーマンスへの影響は低~中程度と考えられます。

この分類に基づいて、4コアと4GB RAMのSQLサーバー仕様から始めることが推奨されます。SQLサーバーの最適な構成を決定するために、テストおよびパイロット段階でSQLサーバーを注意深く監視する必要があります。

決定する事項:インスタンスのサイジング

SQLデータベースのサイズを決めるとき、2つの側面が重要です:

  • データベースファイル - データベースに格納されている表、インデックス、ストアドプロシージャ、ビューなどのデータとオブジェクトが含まれます。
  • トランザクションログファイル - すべてのトランザクションと各トランザクションによって行われたデータベースの変更の記録が含まれています。トランザクションログはデータベースの重要なコンポーネントであり、システム障害が発生した場合は、データベースを一貫した状態に戻すためにトランザクションログが必要になることがあります。トランザクションログの使用方法は、使用されているデータベース復旧モデルによって異なります:
    • 簡単な復旧 - ログバックアップは不要です。ログスペースは自動的に再利用され、スペース要件を小さく保ち、トランザクションログスペースを管理する必要性を本質的に排除します。最新のバックアップ以降のデータベースへの変更は保護されていません。災害が発生した場合は、それらの変更をやり直す必要があります。
    • 完全復旧 - ログバックアップが必要です。データベースのデータファイルが失われたり損傷したりしても作業は失われません。任意の時点のデータを復元できます(たとえば、アプリケーションやユーザーのエラーの前)。データベースのミラーリングには完全復旧が必要です。
    • 一括ログ - ログバックアップが必要です。これは高パフォーマンスの一括コピー操作を許可する完全復旧モデルの補助です。通常、シトリックスデータベースには使用されません。

詳細については、Microsoft Developer Networkの「復旧モデル(SQL Server)」を参照してください。

記憶要件を見積もるには、一般的なデータベースエントリのディスクスペース消費量を理解することが重要です。このセクションでは、製品ごとの記憶要件について概説し、サイジング計算について説明します。詳しくは、シトリックスの記事:CTX139508 - 「XenDesktop 7.x Database Sizing」を参照してください。

XenDesktopの全般

XenApp 7.xとXenDesktop 7.xは、3つの異なるデータベースを使用します:

  • サイト構成データベース - 静的構成と動的ランタイムデータが含まれます
  • 監視データベース - Director経由でアクセス可能な監視データが含まれます
  • 構成ログデータベース - サイト内で行われた各管理上の変更の記録が含まれます(Studio経由でアクセス可能)

サイト構成データベース

XenAppまたはXenDesktopサイトのデータベースには静的構成データと動的ランタイムデータが含まれているので、データベースファイルのサイズは、環境の物理サイズだけでなくユーザーパターンによっても異なります。次の要素がすべてデータベースファイルのサイズに影響します:

  • 接続済みセッションの数
  • 構成済みおよび登録済みのVDAの数
  • ログオン中に発生したトランザクションの数
  • VDAハートビートトランザクション

サイト構成データベースのサイズは、VDAとアクティブなセッションの数に基づきます。次の表は、ユーザー数、アプリケーション数、およびデスクトップ配信方法の例を使用してXenAppおよびXenDesktopをスケールテストしたときにシトリックスが観察した標準的な最大データベースサイズを示しています。

ユーザー アプリケーション デスクトップの種類 予想最大サイズ(MB)
1,000 50 ホストされた共有 30
10,000 100 ホストされた共有 60
100,000 200 ホストされた共有 330
1,000 - ホストされたプール 30
10,000 - ホストされたプール 115
40,000 - ホストされたプール 390

このサイジング情報はあくまで目安です。実際のデータベースサイズは、データベースの管理方法により、展開によってわずかに異なる場合があります。

サイト構成データベースのトランザクションログのサイズを決定することは、次のようなログに影響を与える可能性があるため困難です:

  • SQLデータベースの復旧モデル
  • ピーク時の起動率
  • 配信されているデスクトップの数

XenDesktopのスケーラビリティテストでは、システムがアイドル状態のときにシトリックスが確認したトランザクションログの増加率は1時間あたり3.5MBで、1日、1ユーザーあたりの増加率は最大32KBでした。大規模な環境では、トランザクションログを使用するには、過度の増加を防ぐために慎重な管理と定期的なバックアップが必要です。これはスケジュールされたジョブまたは保守計画によって達成することができます。

監視データベース

3つのデータベースのうち、監視データベースにはサイトの履歴情報が含まれているので、最大となることが予想されます。監視データベースのサイズは以下のような多くの要因に左右されます:

  • ユーザーの数
  • セッション数と接続数
  • ワーカーの数
  • 保有期間の設定 - Platinumのお客様は1年以上データを保存できます(デフォルトは90日)。Platinum以外のお客様は最大7日間データを保存できます(デフォルトは7日)。
  • 1秒あたりのトランザクション数。監視サービスはバッチで更新を行う傾向があります。1秒あたりのトランザクション数が20を超えることはめったにありません。
  • 監視サービスからの定期的な統合呼び出しによって発生したバックグラウンドトランザクション
  • 構成された保有期間外のデータを除去するために行われた夜間処理

次の表は、さまざまなシナリオにおける一定期間の監視データベースの推定サイズを示しています。このデータは、XenAppおよびXenDesktopのスケールテストで確認されたデータに基づく推定値です(週に5日間働くと仮定)。

ユーザー 種類 1週間(MB) 1か月(MB) 3か月(MB) 1年(MB)
1,000 HSD 20 70 230 900
10,000 HSD 160 600 1,950 7,700
100,000 HSD 1,500 5,900 19,000 76,000
1,000 VDI 15 55 170 670
10,000 VDI 120 440 1,400 5,500
40,000 VDI 464 1,700 5,400 21,500

週5日の仕事で、1ユーザーにつき2接続と1セッションの見積もり

ユーザー 種類 1週間(MB) 1か月(MB) 3か月(MB) 1年(MB)
1,000 HSD 30 100 330 1,300
10,000 HSD 240 925 3,000 12,000
100,000 HSD 2,400 9,200 30,000 119,000
1,000 VDI 25 85 280 1,100
10,000 VDI 200 750 2,500 9,800
40,000 VDI 800 3,000 9,700 38,600

100,000件のHSDテストは、次の要素で構成されるテスト環境に基づいています:

  • 2台のDelivery Controller
  • 43人のホストされた共有デスクトップを使用する作業者
  • 1つのAlways On可用性グループ内に保持されているデータベースで構成された3つのSQLサーバー

詳しくは、シトリックスサポートの記事「XenDesktop 7.x Database Sizing」を参照してください。

監視データベースのトランザクションログのサイズを見積もるのは非常に困難ですが、XenAppおよびXenDesktopのスケーラビリティテストでは、システムがアイドル状態のときに1時間に約30.5MBの増加率、1日あたり1ユーザーにつき最大9KBの増加率が示されました。

構成ログデータベース

構成ログデータベースは、通常、3つのデータベースのうち最小のものです。構成ログデータベースのサイズと関連するトランザクションログのサイズは、Studio、Director、またはPowerShellスクリプトから開始される日々の管理作業に左右されるため、そのサイズを見積もるのは困難です。より多くの設定変更が行われるほど、データベースは大きくなります。データベースのサイズに影響を与える可能性がある要因には次のものが含まれます:

  • Studio、Director、およびPowerShellで実行されるアクションの数
  • 設定変更が行われていないときにデータベース上で発生する最小限のトランザクション
  • 更新中のトランザクションレート。更新は可能な限りバッチ処理されます。
  • データベースから手動で削除されるデータ。構成ログデータベース内のデータには保存ポリシーは適用されません。そのため、管理者が手動で行わない限り、データは削除されません。
  • セッションのログオフやリセットなど、セッションまたはユーザーに影響を与えるアクティビティ
  • デスクトップを展開するために使用されるメカニズム

MCSを使用していないXenApp環境では、データベースサイズは30〜40MBになる傾向があります。MCS環境では、すべてのVM構築データのログ記録により、データベースサイズは容易に200MBを超える可能性があります。

一時データベース

サイト、監視、および構成ログデータベースに加えて、システム全体の一時データベース(tempdb)はSQL Serverによって提供されます。この一時データベースは、Read-Committed Snapshot Isolationデータの保存に使用されます。XenApp 7.xおよびXenDesktop 7.xは、このSQL Server機能を使用して、XenAppおよびXenDesktopデータベースのロック競合を軽減します。シトリックスでは、XenApp 7.xおよびXenDesktop 7.xのすべてのデータベースにRead-Committed Snapshot Isolationを使用することが推奨されます。詳しくは、「How to Enable Read-Committed Snapshot in XenDesktop」を参照してください。

tempdbデータベースのサイズはアクティブなトランザクションの数によって異なりますが、一般的には数MB以上になることは想定されていません。新しいデータを生成するトランザクションはすべてtempdb領域を必要とするので、tempdbデータベースのパフォーマンスはXenAppおよびXenDesktopブローカーのパフォーマンスに影響を与えません。XenAppおよびXenDesktopは一時的なトランザクションを保有する傾向があり、これはtempdbのサイズを小さく保つのに役立ちます。

tempdbは、クエリが大きな中間結果セットを生成するときにも使用されます。tempdbのガイダンスとサイジングは、Microsoft TechNetの記事「tempdbのパフォーマンスの最適化」にあります。

Provisioning Services

Provisioning Servicesファームデータベースには、静的構成および構成ログ(監査記録)データが含まれています。以下に概説されているレコードサイズの要件は、データベースのサイズ変更に役立ちます:

構成アイテム 必要なDBスペース(KB) アイテム数(例) 合計(KB)
ベースファーム構成 112 - 112
ファームアクセスがある場合のユーザーグループ 50 10 250
サイト 4 5 20
デバイスコレクション 10 50 500
ファームビュー 4 10 40
ファームビューとデバイスの関係 5 1 5,000
サイトビュー 4 5 20
サイトビューとデバイスの関係 5 1 5,000
デバイス 2 5,000 10,000
デバイスブートストラップ 10 - -
デバイスとディスクの関係 35 1 175,000
デバイスプリンターの関係 1 - -
デバイスのパーソナリティデータ 1 - -
デバイスステータス(起動時) 1 5,000 5,000
デバイスカスタムプロパティ 2 - -
vDisk 1 20 20
vDiskバージョン 3 5 300
ディスクロケーター 10 1 200
ディスクロケーターカスタムプロパティ 2 - -
サーバー 5 10 50
サーバーIP 2 1 20
サーバーステータス(起動時) 1 20 20
サーバーカスタムプロパティ 2 - -
vDiskストア 8 5 40
vDiskストアとサーバーの関係 4 1 40
XenServerへの接続(VirtualHostingPool) 4 - -
vDisk更新タスク 10 10 100
管理上の変更(監査有効化) 1 10,000 10,000
合計     211,732KB(最大212MB)

PVSファームのセットアップ中に、初期ファイルサイズが20MBのデータベースが作成されます。PVSファームデータベース内のデータの性質上、大量の構成を実行しない限り、トランザクションログの急激な増加は想定されません。

管理上の変更を追跡する機能も提供するXenAppとは対照的に、関連情報は専用のデータベースに書き込まれるのではなく、直接Provisioning Servicesファームデータベースに書き込まれます。Provisioning Servicesデータベースのサイズを制限するために、監査記録データを定期的にアーカイブすることが推奨されます。

決定する事項:データベースの場所

XenAppおよびXenDesktopは、次の3つの異なるデータベースを使用します:サイト構成、監視、および構成ログ。3つのデータベースはすべて同じサーバーまたは異なるサーバーでホストできます。理想的な構成は、サイト構成および構成ログデータベースとは異なるサーバーで監視データベースをホストすることです。監視データベースは、より多くのデータを記録し、変更がより頻繁に発生し、監視データベースのデータは他のデータベースほど重要ではないと見なされるため、監視データベースは分離することをお勧めします。

必須ログ機能が有効になっているときに構成ログデータベースの場所を変更することはできません。

決定する事項: 高可用性

次の表は、データベースが停止したときのXenApp、XenDesktop、およびProvisioning Servicesへの影響を示しています:

コンポーネント データベース停止の影響
サイト構成データベース ユーザーは仮想デスクトップに接続または再接続できなくなります。:ローカルホストキャッシュを使用すると、サイト構成データベースが利用できない場合でも、ホストされた共有デスクトップ、ホストされたWindowsアプリケーションとWebブラウザーアプリケーション、およびパーソナルデスクトップを使用しているユーザーが自分のアプリケーションとデスクトップに再接続できます。
監視データベース Directorは履歴データを表示せず、Studioを起動できません。受信ユーザー要求と既存のユーザーセッションの仲介は影響を受けません。
構成ログデータベース XenAppおよびXenDesktopのログ記録設定で[データベースが切断されていても構成変更を許可する]が有効になっている場合は、構成ログデータベースを停止しても影響はありません(ログ記録されていない構成変更以外)。それ以外の場合、管理者はXenAppおよびXenDesktopサイトの構成に変更を加えることができません。ユーザーは影響を受けません。
Provisioning Servicesファームデータベース オフラインデータベースのサポートが有効になり、データベースが使用不能になると、Stream Processはデータベースのローカルコピーを使用してProvisioningサーバーの情報とそのサーバーで使用できるターゲットデバイスの情報を取得します。これにより、Provisioningサーバーとターゲットデバイスの運用が維持されます。ただし、データベースがオフラインのときは、以下にリストされているコンソールおよび管理機能は使用不可になります:自動追加ターゲットデバイス、vDisk作成と更新、Active Directoryのパスワード変更、Stream Processの起動、画像の更新サービス、PowerShellおよびMCLIベースの管理。オフラインデータベースのサポートが有効になっていないと、すべての管理機能が利用できなくなり、ターゲットデバイスの起動とフェールオーバーが失敗します。

サードパーティデータベースの高可用性オプション(たとえば、App-V、SCVMMまたはvCenter)を各ソフトウェアベンダーと確認してください。

組み込みデータベースの冗長性オプションに加えて、Microsoft SQL Server、および基盤となるハイパーバイザー(仮想環境における)が高可用性機能を多数提供します。これらにより、管理者はXenAppおよびXenDesktopインフラストラクチャ上の単一サーバーの停止による影響(存在する場合)を最小限に抑えることができます。次のSQLおよびハイパーバイザーの高可用性機能が使用可能です:

  • VMレベルHA - この高可用性オプションは、仮想SQLサーバーでのみ使用可能で、ハイパーバイザー層で高可用性のマークを付ける必要があります。仮想マシンまたは基盤となるハイパーバイザーホストが予期せずシャットダウンされた場合、ハイパーバイザーは別のホスト上で直ちにVMの再起動を試みます。VMレベルHAは、停電時にダウンタイムを最小限に抑えることができますが、オペレーティングシステムレベルの破損から保護することはできません。このソリューションは、組み込みハイパーバイザー機能を使用するため、データベースのミラーリングやクラスタリングよりも安価です。ただし、自動フェールオーバープロセスは、停止を検出して別のホストで仮想SQLサーバーを起動するのに時間がかかることがあるので、低速です。これによりユーザーへのサービスが中断される場合があります。
  • ミラーリング - データベースのミラーリングは、ほとんど瞬時のフェールオーバーでデータベースの可用性を高めます。データベースのミラーリングは、対応するプリンシパルデータベースまたは実稼働データベースに対して、単一のスタンバイデータベースまたはミラーデータベースを維持するために使用できます。データベースのミラーリングは、高セーフティモードでの同期動作、または高性能モードでの非同期動作のどちらかにより実行されます。自動フェールオーバーでの高セーフティモード(XenDesktopの場合に推奨)では、ミラーサーバーをホットスタンバイサーバーとして機能させることができる、監視と呼ばれる第3のサーバーインスタンスが必要です。プリンシパルデータベースからミラーデータベースへのフェールオーバーは自動的に行われ、通常は数秒以内に完了します。VMレベルHA(または同様の自動再起動機能)を有効にして、マルチサーバーが停止した場合に少なくとも監視がSQLサービスの可用性を確実にできるようにすることをお勧めします。

MicrosoftはSQL Serverの将来のリリースで高可用性オプションとしてミラーリングを削除することを計画しており、新しいネットワーク開発での使用を推奨していません。詳しくは、Microsoftの記事「データベースミラーリング(SQL Server)」を参照してください

  • AlwaysOnフェールオーバークラスターインスタンス - フェールオーバークラスタリングはMicrosoft SQL Serverのインスタンス全体に対して高可用性サポートを提供します。フェールオーバークラスターは、共有ストレージを使用する2つ以上のノードまたはサーバーの組み合わせです。SQL Server 2012で導入されたMicrosoft SQL Server AlwaysOnフェールオーバークラスターインスタンスは、ネットワーク上で単一のコンピューターとして表示されますが、現在のノードが使用できなくなった場合にノード間のフェールオーバーを提供する機能を備えています。あるノードから別のノードへの移行は、クラスターに接続されているクライアントにとってシームレスです。AlwaysOnフェールオーバークラスターインスタンスには、Windows Serverフェールオーバークラスタリング(WSFC)リソースグループが必要です。WSFCリソースグループでサポートされているノード数は、SQL Serverのエディションによって異なります(この章の前半の決定する事項:エディションの表を参照してください)。詳細については、MSDN「AlwaysOnフェールオーバークラスターインスタンス(SQL Server)」を参照してください。
  • AlwaysOn可用性グループ – AlwaysOn可用性グループは、Microsoft SQL Server 2012で導入されたエンタープライズレベルの高可用性および障害回復ソリューションで、これによって管理者は1つまたは複数のユーザーデータベースの可用性を最大化できます。AlwaysOn可用性グループでは、Windows Serverフェールオーバークラスタリング(WSFC)ノード上にMicrosoft SQL Serverインスタンスが存在する必要があります。フェールオーバークラスタリングと同様、単一仮想IPまたはネットワーク名はデータベースユーザーに公開されます。データはネットワーク接続を使用して転送されるため、フェールオーバークラスタリングとは対照的に、共有ストレージは必要ありません。1つまたは複数のセカンダリサーバーへの同期レプリケーションと非同期レプリケーションの両方がサポートされています。ミラーリングやクラスタリングとは対照的に、セカンダリサーバーは受信する読み取り専用要求の処理、バックアップ、または整合性チェックに積極的に使用できます。この機能を使用すると、XenDesktop環境でユーザーリソースの列挙要求をセカンダリSQLサーバーにオフロードし、SQLサーバーインフラストラクチャを本質的にスケールアウトできます。アクティブなセカンダリサーバー上のデータは、プライマリサーバーよりも数秒遅れる可能性があるので、この時点では、読み取り専用ルーティング機能を他のXenDesktopデータベース要求に使用することはできません。詳しくは、MSDN「AlwaysOn可用性グループ(SQL Server)」を参照してください。

次の表に、シトリックスデータベースに推奨される高可用性機能の概要を示します:

表中の表記:

  • Yは、推奨されていることを示しています。
  • oは、実行可能であることを示しています。
  • Nは、サポート対象外であることを示しています。
  • Tは、テスト環境専用であることを示しています。
コンポーネント VMレベル - HA ミラーリング AlwaysOnフェールオーバークラスターインスタンス AlwaysOn可用性グループ
サイト構成データベース T Y o o
構成ログデータベース T o o o
監視データベース T Y o o
Provisioning Servicesファームデータベース T Y o o
DesktopPlayerデータベース T N o o

Citrixライセンスサーバー

シトリックスは、一般的な使用シナリオと一致する複数のライセンスモデルの柔軟性を組織に提供します。ライセンスモデルは、使用されているシトリックス製品によって異なりますが、 ユーザーやデバイス毎、および同時ユーザー毎に含まれます。いくつかのシトリックス製品はライセンスサーバーを使用しますが、他の製品は製品自体にインストールされるライセンスを必要とします。

Citrixライセンスサーバー

  • XenDesktop
  • XenApp
  • Provisioning Services
  • XenServer

製品について:

  • NetScaler
  • NetScaler Gateway

XenDesktop 7.xのライセンスの詳細については、CTX128013「FAQ: XenApp and XenDesktop 7.x Licensing」を参照してください。

Microsoftライセンスの詳細については、Microsoftのドキュメント「Microsoftの仮想デスクトップインフラストラクチャ(VDI)テクノロジのライセンス」を参照してください。

決定する事項:サイジング

内部スケーラビリティテストによって、2つのコアと2GBのRAMを備えた単一の仮想ライセンスサーバーが、1秒あたり約170ライセンス、または30分あたり306,000ライセンスを発行できることが示されています。必要に応じて、ライセンスサーバーの仕様をスケールアウトして、1秒あたりのライセンス要求数を増やすことができます。

決定する事項:高可用性

一般的な環境では、単一のライセンスサーバーで十分です。ライセンスサーバーが利用できなくなった場合は、依存するシトリックス製品が30日の猶予期間に入ります。この期間は接続の問題を解決し、ライセンスサーバーを復元または再構築するのに十分な時間です。

  • ライセンスサーバーとシトリックス製品が2ハートビート(5~10分)以内に通信しない場合、シトリックス製品は猶予期間に入り、最大30日間接続を許可します。ライセンスサーバーとの通信が再構築されたら、ライセンスサーバーは一時ライセンスと実際のライセンスを調整します。
  • DNSのCNAMEレコードは、ライセンスサーバーを参照するのに便利な方法です。CNAMEを使用すると、シトリックス製品を更新せずにライセンスサーバー名を変更できます。

追加の冗長性が必要な場合、シトリックスはライセンスサーバーに対して次の高可用性ソリューションをサポートします。

  • Windowsクラスタリング - クラスターサーバーは、可用性を高めるために連携して動作するコンピューターのグループです。クラスタリングにより、障害が発生した場合にライセンスサーバーの役割を自動的にフェールオーバーすることができます。クラスタリングの詳細については、Citrix Docsの記事「ライセンスサーバーのクラスター化」を参照してください。
  • ライセンスサーバーの複製 - ライセンスサーバーのVMレベルのバックアップを作成します。このバックアップは、ライセンスサーバーと同じホストに保存しないでください。代わりに、可用性の高いストレージソリューションなどの安全な場所に保管するか、テープやディスクにバックアップしてください。複製サーバーはアクティブではなく、アクティブライセンスサーバーを復元する必要が生じるまでスタンバイのままになります。このバックアップを使用してライセンスサーバーを復元する場合は、新しいライセンスをすべてサーバーに再ダウンロードする必要があります。

詳しくは、Citrix eDocs「ライセンスアーキテクチャの概要」を参照してください。

いずれの方法でも、管理者はサービスを中断することなく単一のライセンスサーバーを別のライセンスサーバーに交換できます。この場合、変更が猶予期間中に発生し、次の制限が考慮されると仮定します。

  • ライセンスファイルは、割り当てプロセス中に指定されたサーバーを参照します。つまり、ライセンスファイルは、以前に指定されたサーバーと同じバインド情報(Hostname)を持つサーバー上でしか使用できません。
  • 2つのWindowsベースのドメインに参加しているライセンスサーバーは、同じ名前を共有し、同時に環境内でアクティブになることはできません。
  • ライセンスサーバーは互いに通信しないため、アクティブライセンスサーバーとバックアップライセンスサーバーの両方に追加のライセンスを配置する必要があります。

決定する事項:最適化

ライセンスサーバーのパフォーマンスは、「受信」スレッドと「処理」スレッドの数を調整することによって最適化できます。スレッド数が少なすぎると、スレッドが使用可能になるまで要求はキューに入れられます。逆に、スレッド数が多すぎると、ライセンスサーバーが過負荷になります。

最適値は、サーバーハードウェア、サイト構成、およびライセンス要求の量により異なります。適切な構成を決定するために、さまざまな値をテストおよび評価することをお勧めします。大規模環境では、手始めに最大処理スレッド数を30に、最大受信スレッド数を15に設定するとよいでしょう。

この最適化により、ライセンス要求を受信して処理する機能が向上し、Citrixライセンスサーバーのライセンス提供機能が向上します。

詳しくは、Citrix Docs「使用されるスレッド数を指定してパフォーマンスを向上させる」を参照してください。

Delivery Controller

決定する事項:サーバーのサイジング

Delivery ControllerのスケーラビリティはCPU使用率に基づいています。利用可能なプロセッサコアが多いほど、Controllerがサポートできる仮想デスクトップも多くなります。デスクトップのスタートアップ、登録、列挙、起動の各要求は、Controllerのプロセッサに影響を与えます。ストームが激しくなるにつれて、ControllerのCPU使用率は増加します。CPUが限界しきい値である約80%に達すると、サイトはスケールアップまたはスケールアウトする必要があります。

Delivery ControllerにCPUコアを追加すると、全体的なCPU使用率が低下するため、1つのControllerでサポートされるデスクトップの数が増えます。仮想CPUの追加はかなり簡単で単純明快なので、これは実際には仮想化されたControllerを扱うときにのみ実現可能です。もう1つの方法は、サイト構成に別のControllerを追加することです。Controllerは他のControllerと同じ構成になり、負荷はすべてのControllerに均等に分散されるため、各単一のControllerの全体的な負荷を軽減できます。

テストにより、次の構成を使用する単一のDelivery Controllerで5,000台を超えるデスクトップをサポートできることが示されました。

コンポーネント 仕様
プロセッサ 仮想CPU×4
メモリ 4GBのRAM
ネットワーク 結合仮想NIC
ホストストレージ 40GBの共有ストレージ
オペレーティングシステム Windows Server 2012 R2
XenDesktop 7

次の数式を使用することで、シトリックスサイトに必要なDelivery Controllerの数を計算できます。

Delivery Controllerの数の画像

決定する事項:高可用性

Delivery Controllerをホストしているサーバーが利用できない場合、ユーザーは自分の仮想デスクトップまたは公開アプリケーションにアクセスできません。したがって、少なくとも2つのDelivery Controller(N+1冗長性)は、このコンポーネントが単一障害点にならないようにするために、ゾーンごとに異なる物理サーバーに配置する必要があります。一方のControllerに障害が発生しても、他方のControllerで接続を管理し、サイトを制御できます。

すべてのDelivery Controllerの場所はVDA上で指定されているので、1つのDelivery Controllerとの通信が利用できない場合でも自動的にフェールオーバーできます。VDAは以下の場所を順にチェックして、最初に見つかったDelivery Controllerを使用します:

  1. 自動更新機能により維持される永続的なストレージ。自動更新が有効な場合、VDAのインストール直後の初回登録以降では、ここにController情報が格納されます。インストール後の初回登録、または自動更新が無効の場合、VDAは次の場所を確認します。
  2. ポリシー設定(Delivery Controller、Delivery Controller SID)。
  3. VDA ListofDDCsレジストリキーのDelivery Controller情報。これらの値は、VDAのインストール時に指定する情報に基づいて、VDAのインストーラーにより事前設定されます。
  4. 組織単位ベースの検出。これは、後方互換性を維持するための従来の方法です。
  5. Machine Creation Servicesにより作成されるPersonality.iniファイル。

Citrix Consultingは、自動更新機能を利用することを推奨します(デフォルトでは有効)。この機能は、Delivery Controllerを追加および削除するときにVDAを常に最新の状態に保つことによって、環境管理を簡素化します。

決定する事項:ローカルホストキャッシュ

SQLデータベースの可用性が高い場合でも、Delivery ControllerとSQLデータベース間のネットワーク接続が失敗した場合、データベースにアクセスできないリスクがあります。これは、地理的な場所にまたがるサイトにとって重要な問題です。

このリスクを克服するために、Delivery Controllerがデータベースとの接続を失った場合にのみ使用されるSQLデータベースのローカルコピーを作成するローカルホストキャッシュ機能をDelivery Controllerは利用できます。

ローカルホストキャッシュを使用するときは、次の点を考慮する必要があります:

  • 選択 - ゾーンがSQLデータベースとの接続を失うと、単一のDelivery Controllerをマスターとして指名する選択が行われます。残りのすべてのControllerはアイドルモードになります。選択されるControllerは、アルファベット順で決定されます。
  • サイジング - ローカルホストキャッシュモードを使用する場合、単一のDelivery ControllerがすべてのVDAの登録、列挙、起動、および更新の責任を負います。選択されたControllerには、ゾーンの全体の負荷を処理するための十分なリソース(CPUとRAM)が必要です。1台のControllerで10,000人のユーザーに拡張でき、これがゾーンの設計に影響します。
    • RAM - ローカルホストキャッシュサービスは、停止期間および停止中のユーザー起動数に応じて、2+GBのRAMを消費する場合があります。
    • CPU - ローカルホストキャッシュは単一ソケットで最大4コアを使用する場合があります。
    • ストレージ - ローカルホストキャッシュモード中、記憶域は毎秒平均10ログオンで2~3分ごとに1MB増加しました。
  • 電源オプション - Delivery Controllerがローカルホストキャッシュモードの場合、電源がオフになっている仮想リソースは起動しません。セッション終了時に再起動したプールされた仮想デスクトップはメンテナンスモードになります。
  • コンソール - ローカルホストキャッシュモードを使用している場合、StudioとPowerShellは使用できません。

決定する事項:XML Serviceの暗号化

一般的なセッションでは、StoreFrontサーバーはDelivery ControllerのCitrix XML Serviceに資格情報を渡します。難読化を使用して送信されるパスワードを除いて、Citrix XMLプロトコルはすべてのデータを交換するためにクリアテキストを使用します。

StorefrontサーバーとXenDesktopのコントローラー間のトラフィックが傍受される可能性がある場合、次の攻撃に対して脆弱になります:

  • 攻撃者はXMLトラフィックを傍受し、リソースセット情報とチケットを盗むことができます。
  • 難読化を解読する能力を持つ攻撃者はユーザーの資格情報を入手できます。
  • 攻撃者はXenDesktopのコントローラーを偽装し、認証要求を傍受することができます。

ほとんどの組織では、Citrix XMLトラフィックは専用の物理データセンターまたは仮想データセンターネットワーク上で分離され、傍受される可能性は低くなります。ただし、安全のため、SSL暗号化を使用して安全なHTTP接続を介してStoreFrontデータを送信することを検討してください。

決定する事項:サーバーOSの負荷管理

デフォルトの負荷管理ポリシーは、すべてのサーバーOSデリバリーグループに適用されます。デフォルト設定では、サーバーが250でホストできるセッションの最大数を指定し、CPUとメモリの使用状況を考慮しません。キャッピングセッション数は、負荷を正確に示すものではありません。これは、サーバーOSデリバリーグループの過負荷を招き、パフォーマンスの低下やサーバーOSデリバリーグループの使用率の低下を招き、リソースの非効率的な使用につながります。

Citrix Consultingは、パフォーマンスとスケーラビリティのテストに基づいて、デリバリーグループごとに独自の「カスタム」負荷管理ポリシーを作成することをお勧めします。テスト中に識別されたさまざまなリソースのボトルネックに応じて、さまざまなルールとしきい値を各デリバリーグループに適用できます。利用可能な負荷管理ポリシー構成の詳細については、Citrix Docs「負荷管理のポリシー設定」を参照してください。

実稼働前に十分なテストを実行できない場合は、Citrix Consultingは、すべてのサーバーにベースラインとして適用できる次の「カスタム」負荷管理ポリシーを実装することをお勧めします:

  • CPU使用率 - 全負荷:80%
  • CPU使用率から除外するプロセスの優先順位 - 通常以下または低
  • メモリ使用率 - 全負荷:80%
  • メモリ使用率ベースロード - ゼロ負荷を報告(MB):786
  • 最大セッション数 – X

「最大セッション数」ポリシーは上限設定の目的で含まれています。これは回復性のためのベストプラクティスと考えられています。組織は初期値として250(上記「X」で表します)を選択できます。スケーラビリティテストの結果に基づいてこの値などをカスタマイズすることを強くお勧めします

Cloud Connector

Citrix Cloud内のXenAppおよびXenDesktop Serviceは、Citrix Cloud Connectorに含まれる一連のサービスを利用します。Cloud Connector仮想マシンの冗長セットを、VDAホストを含んでいる各データセンターまたはリソースの場所に配置する必要があります。

決定する事項:サーバーのサイジング

Cloud ConnectorのスケーラビリティはCPU使用率に基づいています。利用できるプロセッサコアが多いほど、Cloud Connectorがサポートできる仮想デスクトップも多くなります。デスクトップのスタートアップ、登録、列挙、起動の各要求は、Cloud Connectorのプロセッサに影響を与えます。ストームが激しくなるにつれて、Cloud ConnectorのCPU使用率は増加します。CPUが限界しきい値である約80%に達すると、サイトはスケールアップまたはスケールアウトする必要があります。

テストにより、次の構成を使用する単一のCloud Connector Controllerが5,000台のデスクトップをサポートできることが示されました。

コンポーネント オンプレミス仕様 Azureでホストされる場合の仕様
VM数(N+1耐故障性) 3 Standard_A2_V2インスタンス×6
仮想マシン1台あたりのプロセッサ 仮想CPU×4 仮想CPU×2
仮想マシン1台あたりのメモリ 4GBのRAM 4GBのRAM
仮想マシン1台あたりのホストストレージ 40GBの共有ストレージ 200GBの一時ストレージ
オペレーティングシステム Windows Server 2012 R2 Windows Server 2012 R2

Provisioning Services

Citrix Provisioning Services(PVS)は、ストリーミング技術を使用して、仮想マシンと物理マシンの展開を簡素化します。単一の共有ディスクイメージからリアルタイムでコンピューターをプロビジョニングしたり、再プロビジョニングしたりします。これにより、個々のシステムを管理・更新する必要性を完全に排除できます。その代わりに、すべてのイメージ管理をマスターイメージで行います。

決定する事項:トポロジ

Provisioning ServicesファームはProvisioning Servicesインフラストラクチャの最上位レベルを表します。これはさらにサイトに分類できます。ファーム内のすべてのProvisioningサーバーは、同じSQLデータベースとCitrixライセンスサーバーを共有します。

各サイトは、Provisioningサーバー、vDiskプール、およびターゲットデバイスコレクションを含む論理エンティティです。ファーム内のすべてのサイトは同じデータベースを共有しますが、ターゲットデバイスは同じサイト内の他のProvisioningサーバーにのみフェールオーバーできます。

PVSサイト構成の画像

Provisioning Servicesのトポロジ全体を決定するときに考慮する必要がある要素があります:

  • ネットワーク - Provisioningサーバーは、システム構成設定を取得するためにファームデータベースと常に通信しています。したがって、高速で堅牢な接続によりデータベースサーバーに接続されていない限り、ターゲットデバイスが存在する物理的な場所ごとに別々のファームを作成する必要があります。
  • 管理 - 組織は、部門別、地域別、または全国規模で管理業務の分離を維持する必要がある場合があります。Provisioning Servicesファームを追加すると、環境管理が複雑になります。ただし、このオーバーヘッドは通常、初期設定、デスクトップの作成、およびイメージの更新に制限されています。
  • 組織 - 複数のサイトを構築する実際的な理由は、組織の変更によるものです。たとえば、最近2社が買収により合併したが、統合が行われている間はリソースを分離しておく必要があるという場合があります。別々のサイトを使用するように組織を構成することは、ビジネスを別々に保つ一方でProvisioning Servicesコンソールを介して集中管理するための1つの方法です。

ビジネス要件によって保証されている場合にのみ、追加のサイトを作成してください。ファームごとの1つのサイトは、管理が簡単で、追加の構成は不要です。

決定する事項:デバイスコレクション

デバイスコレクションによってターゲットデバイスの論理的なグループを作成し管理できます。デバイスコレクションを作成するとターゲットデバイス単位ではなくコレクションの単位で操作を実行できるので、デバイス管理を簡素化できます。

デバイスコレクション構造の画像

デバイスコレクションは、物理的な場所、サブネット範囲、シャーシ、または組織内のさまざまな部署を表すことができます。コレクションを使用して、プロダクションターゲットデバイスをテスト用およびメンテナンス用のデバイスから論理的に分離することもできます。

特定のvDiskに割り当てられているすべてのターゲットデバイスのステータスをすばやく識別できるように、vDisk割り当てに基づいてデバイスコレクションを作成することを検討してください。

決定する事項:高可用性

Provisioning Servicesは、仮想デスクトップインフラストラクチャ(VDI)の重要なコンポーネントです。単一障害点を排除するために、以下の推奨事項に従う必要があります:

  • Provisioningサーバー - サイトごとに、常に最低2台のProvisioningサーバーを実装する必要があります。単一のサーバーで障害が発生しても、サイトごとにサポートできるターゲットデバイスの総数が減少しないように、十分な冗長性を設計に組み込む必要があります。Provisioning Servicesの起動ファイルは高可用性のために構成する必要があります。起動ファイルには、最大4つのProvisioningサーバーを表示できます。ターゲットデバイスは、リストされている順序でサーバーへの接続を試みます。応答するサーバーは、必ずしもStreaming Serviceをターゲットデバイスに提供するサーバーであるとは限りません。負荷分散が有効になっている場合、ターゲットデバイスは、サイト内の他のサーバーよりも負荷が低い別のサーバーに再割り当てされる可能性があります。
  • vDiskとストレージ - ローカルの直接接続ストレージ(DAS)または記憶域ネットワーク(SAN)でホストされているvDiskストアの場合、レプリケーションを使用してvDiskを同期する必要があります。ネットワーク接続ストレージ(NAS)を使用している場合、vDiskが高可用性ネットワーク共有でホストされていることを確認してください。
  • ネットワーキング - Provisioningサーバーには冗長NICが必要です。Provisioningサーバーを物理サーバーとして展開する場合は、冗長NICをチーム化し、Provisioningサーバーを仮想サーバーとして展開する場合は、基盤となるハイパーバイザーに冗長NICを組み込む必要があります。

ターゲットデバイスは、PXE起動に使用するNICと同じサブネットにあるNICにのみフェールオーバーします。

トリビアルファイル転送プロトコル(TFTP)は、マシン間で構成ファイルまたは起動ファイルを転送するために使用される通信プロトコルです。Provisioning ServicesはTFTPを使用してブートストラップファイルをターゲットデバイスに配信できます。TFTPサービスを高可用性にするには、いくつかのオプションがあります。より一般的に使用されるオプションのいくつかは以下のとおりです:

  • DNSラウンドロビン - ファーム内のProvisioningサーバーで実行されているTFTPサービスに対応する複数のAレコードを持つTFTPサービスのDNSエントリが作成されます。TFTPサービスの状態は監視されないので、この方法はお勧めできません。クライアントは非機能性サーバーに送信される可能性があります。
  • ハードウェアロードバランサー - Citrix NetScalerなどのハードウェアロードバランサーを使用して、Provisioningサーバーに対応する仮想IPを作成します。NetScalerは、Provisioningサーバー間でトラフィックをインテリジェントにルーティングできます。いずれかのサーバーが使用できなくなった場合、NetScalerはそのサーバーへのTFTP要求のルーティングを自動的に停止します。これはTFTPを高可用性にするための最善の方法ですが、セットアップが複雑になる可能性があります。
  • 複数のDHCPオプション66エントリ - この方法の実装は簡単ですが、オプション66に複数のエントリを入力できるDHCPサービスが必要です。Microsoft DHCPサーバーは1つのオプション66エントリを許可しているので、この方法はMicrosoft DHCPサービスがある環境では実行不可能です。Microsoft以外のDHCPサーバーまたはアプライアンスを使用する場合、製造元に問い合わせて、複数のオプション66エントリがサポートされていることを確認してください。

TFTPを使用せずに同じ結果を得ることができる他の利用可能なオプションがあります:

  • プロキシDHCP - ブートストラップ情報を提供するためにProvisioningサーバーのPXEサービスを使用します。いずれかのサーバーが停止している場合は、ファーム内で次に利用可能なサーバーがブートストラップ情報を提供できます。この方法では、Provisioningサーバーがターゲットデバイスと同じブロードキャストドメインに属している必要があります。ネットワーク上で他のPXEサービスが実行されている場合(Altiris、SCCMなど)、PXEサービスが互いに干渉しないようにするために、複数のVLANが必要になる場合があります。
  • Boot Device Manager - Boot Device Managerを使用して、ローカルハードドライブに配置されているか、起動可能なISOファイルとして使用されているブートストラップファイルを作成します。ISOファイルを使用する場合は、ターゲットデバイスをCD/DVD-ROMドライブから起動するように設定し、ISOファイルを各ターゲットデバイスの高可用性共有ネットワークの場所またはローカルストレージに配置します。どちらの方法を使用しても、TFTPサービスはまったく使用されません。

高可用性は常にProvisioning Servicesの設計に組み込まれる必要があります。高可用性は追加のリソースとコストの増加を必要とする場合がありますが、それは非常に安定した環境を提供するので、ユーザーが受けるサービス停止による影響は最小限になります。

決定する事項:ブートストラップ配信

ターゲットデバイスでは、ターゲットデバイスとProvisioningサーバー間のストリーム配信セッションを初期化するブートストラッププログラムを最初にロードすることで起動プロセスを開始します。ターゲットデバイスがブートストラッププログラムを受け取ることができる方法は3つあります:

DHCPオプションの使用 -

  1. ターゲットデバイスが起動すると、ターゲットデバイスはIPアドレスと起動情報をブロードキャストで送信します。DHCPはこの要求を処理し、IPとスコープオプションの設定66(Provisioning ServicesのTFTPサーバーの名前またはIPアドレス)および67(ブートストラップファイルの名前)を提供します。

    TFTPサービスにロードバランサーを使用している場合は、ロードバランサーのアドレスがオプション66に入力されます。

  2. ターゲットデバイスからProvisioningサーバーへ、ブートストラップファイルを求める要求がTFTPを使用して送信されます。Provisioningサーバーによりターゲットデバイスが起動ファイルをダウンロードします。

  3. ターゲットデバイスが割り当てられたvDiskイメージを起動します。

PXEブロードキャストを受信するために、ターゲットがDHCPサーバーと同じサブネット上にない場合に設定する、UDP/DHCPヘルパーが必要です。

PXEブロードキャストを使用する -

  1. ターゲットデバイスがネットワークから起動すると、ターゲットデバイスはIPアドレスと起動情報をブロードキャストで送信します。DHCPはこの要求を処理してIPアドレスを提供します。さらに、ブロードキャストを受信するすべてのProvisioningサーバーは、起動サーバーと起動ファイル名の情報を返します。ターゲットデバイスは受信した情報をマージして起動プロセスを開始します。

  2. ターゲットデバイスから最初に応答したProvisioningサーバーへ、ブートストラップファイルを求める要求がTFTPを使用して送信されます。Provisioningサーバーによりターゲットデバイスが起動ファイルをダウンロードします。

  • Altiris PXEサービスなど、同じサブネット上で他のPXEサービスが使用されていないことを確認するか、またはVLANを使用して分離してください。そうしないと、Provisioning Servicesとの競合が発生する可能性があります。
  • PXEブロードキャストを受信するために、ターゲットがDHCPサーバーおよびPVSサーバーと同じサブネット上にない場合に設定する、UDP/DHCPヘルパーが必要です。

Boot Device Managerの使用 - Boot Device Manager(BDM)は、ターゲットデバイスが物理CD/DVD、マウントされたISOイメージを通して、またはターゲットデバイスに割り当てられた仮想ハードディスクとして取得する起動ファイルを作成します。BDMパーティションは、次の3つの方法のいずれかでアップグレードできます:

  • コレクション別
  • 強調表示されたデバイスのグループ別
  • 単一デバイス別

次の表に、各配信方法の長所と短所の概要を示します:

配信方法 長所 短所
DHCPオプション 実装が簡単 実稼働DHCPサービスに変更が必要です。DHCPサービスは、オプション66のエントリを1つだけ許可します。異なるサブネット上のターゲットのためのUDP/DHCPヘルパーが必要です。
PXE 実装が簡単 同じサブネット上で実行中の他のPXEサービスを妨げる可能性があります。異なるサブネット上のターゲットのためのUDP/DHCPヘルパーが必要です。
BDM ISO PXEまたはTFTPサービスを必要としない 物理ターゲットデバイスを起動するのに余分な労力が必要です。単一のファイルが使用される場合、BDM ISOは単一障害点と見なされます。
BDMパーティション BDM起動パーティションのアップグレードにPXE、TFTP、またはTSBが必要ない。これは単一のステージブートローダーと見なされ、起動時にすべての関連PVSサーバー情報を自動的に検出し、PXE、TFTP、またはTSBによって提供される外部サービスを必要としません。 ターゲットデバイスごとに8MBの追加パーティションが作成されます。

ブートストラップファイルを構成するときは、最大4つのProvisioningサーバーを一覧表示できます。一覧内でのProvisioningサーバーの順序によって、Provisioningサーバーがアクセスされる順序が決定されます。最初のサーバーが応答しない場合は、リスト内の次のサーバーに連絡します。

決定する事項:vDiskフォーマット

Provisioning Servicesは、固定サイズまたはダイナミックvDiskの使用をサポートしています:

  • 固定サイズディスク - プライベートモードの固定サイズvDiskの場合、ディスクの断片化を防ぎ、ダイナミックディスクよりも書き込みパフォーマンスが向上します。
  • ダイナミックディスク - ダイナミックディスクは、必要な記憶域が固定サイズディスクよりも少なくて済みますが、書き込みパフォーマンスは大幅に低下します。共有モードのvDiskはvDiskへの書き込みを実行しませんが、vDiskのマージ操作を完了するのに必要な時間はダイナミックディスクでは長くなります。より多くの環境が更新時に新しいvDiskを作成することを選択するので、これは一般的なことではありません。

ほとんどの読み取りはRAM内のシステムキャッシュに対するものなので、固定サイズディスクまたはダイナミックディスクを使用してもパフォーマンスに大きな変化はありません。さらに、ダイナミックディスクでは、必要な記憶域が大幅に少なくなります。したがって、ダイナミックディスクをお勧めします。

決定する事項:vDiskのレプリケーション

ローカルの直接接続ストレージまたはSANでホストされているvDiskは、vDiskが作成または変更されるたびにvDiskストア間で複製する必要があります。Provisioning Servicesは、Provisioningサーバーに対してローカルなストアからのvDiskのレプリケーション、および共有ストレージを使用する複数のサイトにわたるレプリケーションをサポートしています。vDiskのレプリケーションは手動または自動で実行できます:

  • 手動 - 手動レプリケーションは簡単ですが、vDiskとvDiskストアの数によっては時間がかかる場合があります。レプリケーションプロセス中にエラーが発生した場合、管理者はすぐにそれらを見つけて解決するための適切な手順を実行できます。手動レプリケーションのリスクは、Provisioningサーバー間でvDiskが矛盾した結果、負荷分散とフェールオーバーが正しく機能しなくなることです。たとえば、vDiskが3つのサーバーに複製され、そのvDiskのうちの1つが更新された場合は、そのvDiskはほかの2つと同一ではなくなり、サーバーのフェールオーバーが発生したときに考慮されません。まったく同じ更新をほかの2つのvDiskに実行しても、各vDiskのタイムスタンプが異なるので、それらのvDiskは同一ではなくなります。
  • 自動化 - 大規模環境では、必要なvDiskとvDiskストアの数が多いので、自動レプリケーションは手動方式よりも高速です。Microsoft DFS-Rなどのいくつかの自動化ツールは、宛先ファイルが複製中のファイルと類似しているかどうかを判断するためにヒューリスティックスを使用する、帯域幅調整およびクロスファイルリモート差分圧縮(CF-RDC)をサポートしています。その場合、CF-RDCは、ネットワーク経由で転送されるデータ量を最小限に抑えるために、これらのファイルからのブロックを使用します。自動レプリケーションのリスクは、管理者が通常、レプリケーションイベントをリアルタイムで監視せず、自動化ツールに警告機能がない限り、エラーが発生したときに迅速に応答しないことです。一部のツールは、障害が発生した場合にコピープロセスを自動的に再開するように設定できます。たとえば、Robocopyはネットワーク接続が中断された場合の「コピー再開」をサポートします。

中規模および大規模のプロジェクトでは、ツールを使用してvDiskのレプリケーションを自動化します。ネットワークの中断から再開し、ファイル属性をコピーし、元のタイムスタンプを保持することができるツールを選択します。

vDiskのタイムスタンプが同一でないと、負荷分散と高可用性は機能しません。

決定する事項:サーバーのサイジング

一般に、Provisioningサーバーは次の仕様で定義されています:

コンポーネント 仕様
モデル 仮想
プロセッサ 4 - 8 vCPU
メモリ 2GB +(vDiskの数 * 2GB)
ネットワーク 10GBps NIC
ネットワーク 40GBの共有ストレージ
vDiskストレージ 画像または改訂の数の数による
オペレーティングシステム Windows Server 2012 R2

モデル

Citrix Provisioning Servicesは、仮想サーバーまたは物理サーバーにインストールできます:

  • 仮想 - 迅速なサーバープロビジョニング、即座の復旧またはロールバックシナリオのためのスナップショット、およびサーバーリソースをその場で調整する機能を提供します。仮想Provisioningサーバーを使用すると、ターゲットデバイスをより多くのサーバーに分散させることができ、サーバー障害による影響を軽減できます。仮想化はシステムリソースをより効率的に利用します。
  • 物理 - サーバーごとに仮想サーバーよりも高いレベルのスケーラビリティを提供します。物理Provisioningサーバーは、基盤となるハイパーバイザーリソースをめぐって競合する仮想マシンに関連するリスクを軽減します。一般に、仮想Provisioningサーバーは、十分なプロセッサ、メモリ、ディスク、およびネットワークリソースを利用可能にし、利用可能であることが保証できる場合に推奨されます。

高可用性のために、仮想Provisioningサーバーが複数の仮想化ホストに分散されていることを確認してください。複数のホストに仮想サーバーを分散させると、単一障害点がなくなり、ホストに障害が発生してもProvisioning Servicesファーム全体が停止することはありません。

CPU

Provisioning ServicesはCPUに負荷をかけません。ただし、CPUの割り当て数が少なすぎると、ネットワークストリームの最適化に影響があります。Provisioning Servicesサーバーが同時に実行できるストリームの数は、次の数式で決定できます:

最大ストリーム数 = ポート数 x スレッド数/ポート

デフォルトでは、Streaming Serviceは20個の順次ネットワークポートと1ポートあたり8個のスレッドで構成されています。したがって、デフォルトでは、Provisioningサーバーは160の同時ターゲットをサポートできます。160を超えるストリームが必要な場合、Provisioning Servicesはストリーミングターゲットデバイス間で継続的に切り替えます。

理想的には、環境で160を超える同時ターゲットをサポートする必要がある場合は、Provisioning Servicesコンソールでポート数、およびポートあたりのスレッド数を調整できます。ポートあたりのスレッド数がProvisioningサーバーで使用可能なコア数以下である場合、最高のパフォーマンスが得られます。Provisioningサーバーに十分なコアがない場合、サーバーのCPU使用率が高くなり、要求の処理を待機しているターゲットデバイスの読み取り待機時間が長くなります。

Provisioning ServicesはCPUに負荷をかけませんが、2つのCPUを割り当てるには、より広い連続ネットワークポート範囲が必要になります。

  • 小規模環境(最大約500台の仮想マシン)の4つのvCPUが推奨されます。
  • 大規模環境の8つのvCPUが推奨されます。

RAM

Provisioning ServicesをホストしているWindowsオペレーティングシステムがvDiskを部分的にメモリにキャッシュし(システムキャッシュ)、それによりストレージからの読み取り回数が減ります。ストレージからの読み取りは、メモリからの読み取りよりも大幅に遅くなります。したがって、Provisioningサーバーには、このキャッシュプロセスの利点を最大限に引き出すために十分なメモリを割り当てる必要があります。

次の数式を使用して、Provisioningサーバーに割り当てる必要のあるメモリの最適量を決定できます:

総サーバーRAM = 2GB +(vDsikの数 ∗ 2GB)

ネットワーク

他のほとんどのXenAppおよびXenDesktopコンポーネントとは異なり、Provisioning ServicesがCPUの妨げになることはありません。Provisioning Servicesのスケーラビリティはネットワークスループットに基づいています。

次の表は、Provisioning Servicesがさまざまなオペレーティングシステムを起動するために必要なデータ量の概算を示しています:

オペレーティングシステム 平均起動データ使用量(MB)
Windows 10 x64 240
Windows 8 x86 178
Windows 8 x64 227
Windows 7 x86 166
Windows 7 x64 210
Windows 2012 225
Windows 2012 R2 232
Windows 2008 R2 251
Windows Vista x86 190
Windows Vista x64 240

ターゲットデバイスを起動するのに必要な時間の決定は、次の数式を使用して推定できます:

起動するまでの秒数の数式の画像

オペレーティングシステム VMの数 ネットワークスループット 起動にかかる時間
Windows 10 x64 500 1GBps 960秒(16分)
Windows 10 x64 500 10GBps 96秒(1分36秒)

Provisioning Servicesでの使用には10Gbpsネットワークが推奨されます。10Gbpsネットワークが利用できない場合は、Provisioningサーバーまたは専用の物理ストリーミングネットワークに追加の帯域幅を提供するため、リンクアグリゲーションを検討してください。

ヒント

ファイアウォールは、Provisioning Services環境で待ち時間を追加し、帯域幅のボトルネックを引き起こす可能性があります。ファイアウォールの使用を避けられない場合、全機能を活用するために有効にする必要があるポートのリストについては、シトリックスのホワイトペーパー CTX101810「Communication Ports Used by Citrix Technologies」を参照してください。

成長

ファームが大きくなるにつれて、管理者はProvisioningサーバーにリソースを追加するか、ファームにProvisioningサーバーを追加するかを決定する必要があります。

Provisioningサーバーをスケールアップするかスケールアウトするかを決定する場合に考慮する必要がある環境要因がいくつかあります:

  • 冗長性 - 性能の劣るサーバー間でユーザー負荷を分散することにより、単一のProvisioningサーバーの障害による影響を受けるユーザーの数を減らすことができます。ビジネスにおいて単一の高仕様サーバーの損失を受け入れることができない場合、スケールアウトを検討してください。
  • フェールオーバー時間 - 単一のProvisioningサーバーに接続されているターゲットデバイスが多いほど、サーバーに障害が発生した場合にそれらがフェールオーバーするのにかかる時間が長くなります。ターゲットデバイスが別のサーバーにフェールオーバーするのに必要な時間を短縮するためにスケールアウトを検討してください。
  • データセンター容量 - データセンターで利用できるスペース、電力、または冷却機能は限られている場合があります。この状況では、スケールアップを検討してください。
  • ハードウェアコスト - 初めに、スケールアップする方が費用対効果が高い可能性があります。ただし、スケールアウトが実際にはより費用対効果が高くなる点があります。その判断を下すには、コスト分析を実行する必要があります。
  • ホスティングコスト - 使用される物理サーバーの数に基づくホスティングやメンテナンスコストがある場合があります。その場合、これらのオーバーヘッドの長期コストを減らすためにスケールアップを検討してください。

決定する事項:ネットワーク構成

前述のように、ネットワークのボトルネックによってディスクアクセス時間が長くなり、仮想デスクトップのパフォーマンスに直接影響を与えることがないように、ネットワークのサイズを正しく設定することが重要です。次の図は、一般的なProvisioning Servicesネットワークインフラストラクチャの概要を示しています:

pvsネットワーク構成の例の画像

図内のネットワークセクションの概要には、次のネットワーク構成が推奨されます:

  • PVSアップリンク - ターゲットデバイスからのすべてのディスクアクセスは、PVSネットワークアップリンクを介して転送されます。これは、何百、何千ものデバイスがこのネットワーク接続を使用することを意味します。したがって、この接続が冗長であり、ダウンタイムなしでフェールオーバーできることは重要です。それに加えて、500台のターゲットデバイスあたり1Gbps以上の帯域幅が推奨されます。仮想Provisioningサーバーの場合、最高のパフォーマンスを確保するために、それぞれのQoSクォータまたは専用の物理ネットワークアップリンクを構成する必要があります。
  • ハイパーバイザーアップリンク - 特定のハイパーバイザーホスト上でホストされているすべてのPVSターゲットデバイスによって使用されます。したがって、透過フェールオーバーによる冗長性を強く推奨します。I/Oが非常に多く発生するワークロードをターゲットデバイスが実行しない限り、またはI/Oが多く発生するタスク(起動など)を同時に実施しない限り、このアップリンクには1Gbpsの帯域幅で十分です。
  • VMアップリンク - PVSストリーミングトラフィックを含む仮想マシンのすべてのネットワークトラフィックは、この仮想ネットワーク接続を通過します。ワークロードのI/Oが極端に多く発生しない限り、vDiskからの起動など、I/Oが多く発生するタスク中のピーク負荷を処理する場合でも、100Mbpsの帯域幅で十分です。たとえば、Windows 2012 R2 Serverは、Windowsログオン画面が表示されるまでの90秒間にvDiskから約232MBを読み取ります。この期間中、最大90Mbpsのピークを持つ平均データレート20.5Mbpsを観測できます。

Provisioning Servicesには、次のスイッチ設定をお勧めします:

  • スパニングツリーを無効にするまたはPortFastを有効にする - スイッチング環境では、スパニングツリープロトコル(STP)は、ブリッジプロトコルデータユニット(BPDU)を送信し、BPDUがループバック構成になっていないことを確認する間、ポートをブロック状態にします。ネットワークが収束するまで、ポートは転送状態になりません。ネットワークのサイズによっては、Preboot eXecution Environment(PXE)のタイムアウトを引き起こすのに十分な時間がかかる場合があります。この問題を解決するには、クライアントに接続されているエッジポートでSTPを無効にするか、PortFastを有効にします。
  • ストームコントロール - ストームコントロールはCiscoのスイッチで利用可能な機能で、これにより、マルチキャスト、ブロードキャスト、またはユニキャストトラフィックが抑制されるようしきい値を設定することができます。その目的は、悪意のあるまたは誤った送信者がLANをフラッディングしてネットワークパフォーマンスに影響を与えるのを防ぐことです。PVSサーバーは、ストームコントロールしきい値に収まるように設計により大量のトラフィックを送信する可能性があるので、機能はそれに応じて構成する必要があります。
  • ブロードキャストヘルパー - ブロードキャストヘルパーは、クライアントからのブロードキャストを、通常はルーティングされないサーバーに転送するために必要です。PVS環境では、クライアントがサーバーと同じサブネット上に存在しない場合はPXE起動要求を転送する必要があります。可能であれば、推奨されるネットワーク設計は、ターゲットデバイスと同じサブネット上にPVSサーバーを配置することです。これにより、他のネットワークインフラストラクチャコンポーネントによるサービス低下のリスクが軽減されます。

Provisioning Servicesのネットワークインターフェイスを選択するときは、次のネットワークインターフェイス機能を考慮に入れる必要があります:

  • TCPオフロード - I/OタスクのネットワークインターフェイスへのオフロードによりCPU使用率が減少し、システム全体のパフォーマンスが向上しますが、ネットワークアダプターに余分な作業がかかることが原因で、大量送信オフロードが有効になっていると、PVS Streaming Serviceに悪影響を及ぼす場合があります。多くのネットワークアダプターでは、デフォルトで大量送信オフロードおよびTCPチェックサムオフロードが有効になっています。

大量送信オフロードが有効で、トラフィックが通過しているスイッチが、大量送信オフロードエンジンによって送信されたフレームサイズをサポートしていない場合、スイッチはフレームをドロップしてデータの再送信を引き起こします。再送信すると、オペレーティングシステムはネットワークアダプターの代わりにフレームをセグメント化し、その結果パフォーマンスが大幅に低下する可能性があります。

  • 受信側スケーリング(RSS) - 受信側のスケーリングにより、ネットワークアダプターから受信したパケットを複数のCPU間で分散させることができます。これにより、受信TCP接続の負荷分散が可能になり、単一のCPUにボトルネックが発生するのを防ぎます。Windows Server 2008 R2およびWindows Server 2012/2012 R2の場合、RSSはデフォルトで有効になっています。

PVSネットワーキングのベストプラクティスの詳細については、「Best Practices for Configuring Provisioning Services Server on a Network」を参照してください。

低帯域幅ネットワーク(1Gbps以下)でのProvisioning Servicesの実装の場合、LAN上の他のネットワークトラフィックからストリーミングトラフィックを分離することで、パフォーマンスが向上する場合があります。

Microsoftは、Windows Server 2008 R2上のHyper-VによるNICチーミングをサポートしていません。ただし、サードパーティのソリューションは利用可能です。Microsoftは、Windows Server 2012/2012 R2上のHyper-VによるNICチーミングをサポートしています。Hyper-Vとのチーム編成に関するすべてのサポートクエリは、NIC OEMに送信する必要があります。

決定する事項:サブネットアフィニティ

Provisioning Servicesサブネットアフィニティは、ターゲットデバイスが最も適切なProvisioningサーバーに確実に接続されるようにするための負荷分散アルゴリズムです。サブネットアフィニティを設定するときは、次のオプションがあります:

  • なし - サブネットを無視し、最も負荷の低いサーバーを使用します。
  • ベストエフォート - 同じサブネット内で最も負荷の低いサーバーとNICの組み合わせを使用します。サブネット内に使用できるサーバーとNICの組み合わせがない場合は、サブネットの外部で最も負荷の低いサーバーを選択します。選択したサブネット内で複数のサーバーを使用できる場合は、それらのサーバー間で負荷分散を実行します。これがデフォルトの設定です。
  • 固定 - 同じサブネット内で最も負荷の低いサーバーとNICの組み合わせを使用します。サブネット内のサーバーで負荷分散を実行します。同じサブネット内にサーバーとNICの組み合わせがない場合は、このvDiskが割り当てられているターゲットデバイスを起動しません。

次の例は、物理Provisioningサーバーの一般的なネットワーク構成を示しています。パフォーマンスや機能性を犠牲にすることなく、仮想Provisioningサーバーに同様の構成を実装できます。

ブレード設計

Provisioningサーバーとそれらがサポートするターゲットデバイスは、同じシャーシ内にあります。ほとんどの場合、シャーシはシャーシ内のすべてのブレードサーバー間で共有される専用の10Gbpsスイッチを保有します。

ブレード筐体設計の画像

「ベストエフォート」のサブネットアフィニティオプションは、Provisioning Servicesのトラフィックを同じシャーシ内に維持するために使用されます。Provisioningサーバーが使用できなくなった場合、ターゲットは2台目のシャーシ内の2台目のProvisioningサーバー(ただし、同じProvisioning Servicesサイト内)にフェールオーバーします。

ラック設計

2番目の例は、ラック内のプロビジョニングトラフィックを維持するためにラックスイッチを使用するラック設計に基づいています。

PVSラック設計の画像

ブレードシャーシ設計とは対照的に、サブネットアフィニティ機能は使用されません。代わりに、2台のProvisioningサーバーを持つProvisioning Servicesサイトがサーバーラックごとに構成されます。これにより、ターゲットデバイスが同じラック内のProvisioningサーバーから確実にストリーミングされます。

実際の例

製造業 - ある製造会社は、5,000台の仮想デスクトップをサポートするためのProvisioning Servicesソリューションを設計しています。同社は、Provisioning Servicesのストリーミングトラフィックが他のアプリケーションに影響を与えるネットワーク上のボトルネックとなることを懸念しています。同社は、プロビジョニングトラフィックがブレード筐体内に含まれ、ネットワーク上の他のトラフィックに影響を与えないように、ブレードサーバー上で環境を構築することを選択しました。

決定する事項:読み取りキャッシュ

PVSアクセラレータにより、PVSプロキシをXenServerホスト上のコントロールドメインに配置できます。ここで、Provisioning Services vDiskのストリーミングは仮想マシンに転送される前にプロキシでキャッシュされます。キャッシュを使用すると、同じホスト上の仮想マシンの今後の起動(またはその他のIO要求)はネットワーク上のサーバーからではなくプロキシからストリーミングできます。PVSアクセラレータでは、XenServerホストでより多くのローカルリソースが消費されますが、ネットワーク経由のサーバーからのストリーミングはリソースを節約し、効果的にパフォーマンスを向上させます。

PVS読み取りキャッシュの画像

PVSアクセラレータはXenServerのみの機能です。この統合技術を利用すると、PVSサーバー上の負荷が軽減され、ネットワーク全体の利用率が低下し、仮想マシンの起動にかかる時間が短縮されます。

PVSアクセラレータの画像

XenServerとProvisioning Servicesの関係の詳細については、ブログ記事「XenServer and PVS: Better Together」を参照してください。

決定する事項:書き込みキャッシュ

マスターイメージは読み取り専用のため、各仮想マシンにはすべての変更を保存するための書き込み可能なディスクがあります。管理者は書き込みキャッシュディスクの保存場所を決定する必要があります。

PVSサーバー - ローカルストレージ

Provisioning Servicesのローカルストレージには、各ターゲット仮想マシンの書き込みキャッシュドライブがあります。これはデフォルト設定ですが、これによりネットワーク帯域幅の要件が増え、Provisioning Servicesサーバーの使用率が増加します。

サーバー側ローカルストレージの画像

PVSサーバー - 共有ストレージ

Provisioning Servicesサーバーに関連付けられている共有ストレージには、各ターゲット仮想マシンの書き込みキャッシュドライブがあります。このオプションを選択すると、ネットワーク帯域幅の要件が増え、Provisioning Servicesサーバーの利用率が増加します。それにより高価な共有ストレージ上に一時データ(書き込みキャッシュ)も配置します。

サーバー側共有ストレージの画像

VM - ローカルストレージ

仮想マシンに関連付けられているローカルストレージは、各ターゲット仮想マシンの書き込みキャッシュドライブを保持します。このオプションは低コストのローカルストレージを使用し、Provisioning Servicesサーバー上の追加リソースを消費しません。ただし、ローカルストレージは、ホスト上のすべての仮想マシンのIOPSをサポートできなければなりません。

VMローカルストレージの画像

VM - RAMへのキャッシュ

仮想マシンに関連付けられているRAMは、各ターゲット仮想マシンの書き込みキャッシュドライブを保持します。このオプションはRAMの速度により高いパフォーマンスを発揮します。ただし、RAMキャッシュの容量が不足すると、仮想マシンは使用できなくなります。このオプションを使用するには、各仮想マシンに大量のRAMを割り当てる必要があり、全体のコストが増加します。

RAMへのVMキャッシュの画像

VM - ディスクへのオーバーフローを伴うRAMへのキャッシュ

書き込みキャッシュには、RAMとローカルストレージの組み合わせが使用されます。まず、書き込みはRAMキャッシュ内に格納されるため、高いパフォーマンスが得られます。RAMキャッシュが消費されると、大きなブロックがRAMキャッシュから削除され、ローカルストレージの書き込みキャッシュディスクに配置されます。このオプションは低コストのローカルストレージでハイレベルのパフォーマンスを提供します。

この統合技術を利用することで、書き込みIOPSが95%削減されます。

RAMへのVMキャッシュの画像

ディスクへのオーバーフローを使用してRAMにキャッシュすることをお勧めします。

RAMへのVMキャッシュの画像

決定する事項:アンチウイルス

デフォルトでは、ほとんどのウイルス対策製品はすべてのファイルとプロセスをスキャンし、それによりProvisioning Servicesのパフォーマンスが多大な影響を受けます。アンチウイルスプログラムをProvisioning Services用に最適化する方法の詳細については、CTX124185「Provisioning Services Antivirus Best Practices」を参照してください。

アンチウイルスプログラムによりProvisioningサーバーにおいてファイルロックの問題が引き起こされる可能性があります。ファイル競合の問題を防ぐために、vDiskストアおよび書き込みキャッシュはウイルススキャンから除外する必要があります。

仮想ディスクが標準モードで動作していて再起動する必要がある場合は、以前にロードされたすべてのウイルス定義がダウンロードされます。一度に複数のターゲットデバイスを再起動すると、パフォーマンスが低下する可能性があり、操作が持続している間にネットワークの輻輳が発生することがよくあります。極端な場合には、ターゲットデバイスとProvisioningサーバーの動作が遅くなり、必要以上に多くのリソースが消費されることがあります。アンチウイルスプログラムでサポートされている場合は、定義ファイルを書き込みキャッシュドライブにリダイレクトして、再起動後も定義ファイルを保存するようにします。

Machine Creation Services

Machine Creation Services(MCS)は、仮想マシンの展開を簡素化するディスククローニング技術を使用します。単一の共有ディスクイメージからリアルタイムでコンピューターをプロビジョニングしたり、再プロビジョニングしたりします。これにより、個々のシステムを管理・更新する必要性を排除できます。その代わりに管理者は、すべてのイメージ管理をマスターイメージで行います。

決定する事項:ストレージの場所

Machine Creation Servicesを使用すると、管理者は仮想デスクトップを複数のコンポーネントに分割し、それらをさまざまなストレージアレイに格納できます。

共有ストレージ

最初のオプションでは、オペレーティングシステムディスクと差分ディスク用の共有ストレージを利用します。

MCS共有ストレージの画像

このオプションでは、複数のハイパーバイザーホスト間でマスターイメージを共有できますが、一時データである差分ディスクもホストする必要があるので、ストレージアレイにより大きな負荷がかかります。

ハイブリッドストレージ

2番目のオプションでは、オペレーティングシステムディスク用に共有ストレージを使用し、差分ディスク用にローカルハイパーバイザーストレージを使用します。

MCSハイブリッドストレージの画像

これは最も一般的なオプションです。これにより、高価で一時的な書き込みIOPSを安価なローカルハイパーバイザーストレージにオフロードしながら、複数のハイパーバイザーホスト間でマスターイメージを共有することの利点を管理者は享受できます。

XenServer IntelliCacheストレージ

3番目のオプションでは、オペレーティングシステムディスク用の共有ストレージと、差分ディスク用のローカルハイパーバイザーストレージ、およびオペレーティングシステムディスクのローカルキャッシュ用のローカルXenServerストレージを使用します。

これはXenServer実装のための唯一のオプションです。ハイブリッドストレージアプローチと同じ価値を提供しながら、共有ストレージからの読み取りIOPSも削減します。IntelliCacheは、XenServer RAMが制限されている場合は、XenServer RAMベースの読み取りキャッシュと共存できます。

MCS IntelliCacheの画像

決定する事項:クローニングの種類

Machine Creation Servicesには、2種類のクローン作成技術が組み込まれています。

  • シン - カタログ内のすべてのVMは、すべての読み取りにおいて単一の読み取り専用の仮想ディスクを使用します。各VMに固有の2番目の仮想ディスクは、すべての書き込みIOアクティビティを取得します。
  • フル - カタログ内のすべてのVMは、マスターディスクイメージの完全なコピーを受け取ります。各VMはディスクを完全に所有しているので、読み取りおよび書き込みアクティビティが許可されます。フルクローン作成技術は、専用の仮想マシンがすべての変更をローカルディスクに保存するパーソナル仮想デスクトップでのみ利用できます。

シンクローン作成技術とフルクローン作成技術間で決定する場合、管理者は次の点を考慮する必要があります:

  シンクローン 完全なクローン
記憶域要件 記憶域を最大限に節約できます。単一のマスターディスクイメージが複数のVM間で共有されます。差分ディスク(書き込み)のみがスペースを消費し、VMが再起動するまで増加し続けます。 高レベルの記憶域要件です。各VMはマスターイメージの完全なコピーを受け取ります。VMに変更が加えられると、サイズは拡大し続けます。
バックアップ/復元 困難です。多くのサードパーティバックアップおよび障害回復ソリューションは、スナップショットやデルタディスクをサポートしていないため、シンプロビジョニングVMのバックアップまたは他のストレージアレイへの移動は困難または不可能です。 簡単です。VMは単一の仮想ディスク内に存在し、それによりバックアップと復元が簡単になります。
プロビジョニング速度 高速です。単一のディスクイメージのみが必要になります。 低速(マイグレート可能)です。各VMにはマスターイメージの完全なコピーが必要です。ストレージ最適化技術が軽減に役立つ場合があります。
パフォーマンス より低速になります。読み取りI/Oは、マスターディスク用に1回、差分ディスク用に1回の計2回発生する可能性があり、読み取りIOPSが増加します。 より高速になります。すべての読み取りおよび書き込みが単一のディスクに向けられます。
起動ストーム 大きく影響します。起動ストームでは、Windowsスタートアップからのすべての書き込みを保持するためにすべての差分ディスクのサイズが変更されます。これは一度に発生するため、ストレージに高い負荷がかかります。 影響は小さいです。

決定する事項:読み取りキャッシュ

起動時およびログオン時に、仮想デスクトップには高レベルのストレージ読み取りIOPSが発生し、そのため基盤となるストレージサブシステムに負荷がかかる可能性があります。Citrix XenServerに展開した場合、共有VDIモードとプールVDIモードでは、 各XenServerにホストされたRAMベースの読み取りキャッシュが利用されます。

MCS読み取りキャッシュの画像

この統合技術を利用することで、読み取りIOPSが50%~80%削減されます。

MCS読み取りキャッシュグリッドの画像

決定する事項:書き込みキャッシュ

定常状態では、仮想デスクトップに高レベルのストレージ書き込みIOPSが発生し、そのため基盤となるストレージサブシステムに負担がかかる可能性があります。共有およびプールVDIモードでは、仮想マシンのオペレーティングシステムからページ化されていないプールRAMを使用することで、RAMベースの書き込みキャッシュを利用できます。

MCS書き込みキャッシュの画像

この統合技術を利用することで、書き込みIOPSが95%削減されます。

MCS書き込みキャッシュグリッドの画像

セキュリティ

組織の要件に応じて、さまざまなセキュリティ標準をソリューション内に実装する必要があります。以下の資料を参照することをお勧めします:

設計手法管理レイヤー