Worldwide Consulting Solutions | XenDesktop＆XenApp - ベストプラクティス
XenDesktop＆XenApp
ベストプラクティス - リファレンスガイド
www.citrix.co.jp
目次
概要 ..................................................................................................................................................... 3
本書の構成 ....................................................................................................................................... 4
一般的な推奨事項................................................................................................................................. 5
制御レイヤ ............................................................................................................................................ 6
XenDesktop コントローラー ................................................................................................................ 6
XenApp コントローラー ....................................................................................................................... 8
SQL データベース ............................................................................................................................ 11
ライセンスサーバー .......................................................................................................................... 14
ネットワーキング .............................................................................................................................. 15
Active Directory .............................................................................................................................. 18
システム管理 ................................................................................................................................... 20
ハードウェア ........................................................................................................................................ 23
一般................................................................................................................................................ 23
Citrix XenServer ............................................................................................................................. 29
Microsoft Hyper-V ........................................................................................................................... 31
VMware vSphere ............................................................................................................................ 35
デスクトップ ......................................................................................................................................... 38
一般................................................................................................................................................ 38
Machine Creation Services（MCS） .................................................................................................. 40
Provisioning Services ..................................................................................................................... 41
アプリケーション .................................................................................................................................. 50
パーソナライズ .................................................................................................................................... 55
印刷................................................................................................................................................ 55
プロファイル ..................................................................................................................................... 56
Citrix Profile Manager ..................................................................................................................... 58
ポリシー .......................................................................................................................................... 59
アクセス .............................................................................................................................................. 60
ICA/HDX......................................................................................................................................... 60
Web Interface ................................................................................................................................. 64
Citrix Plug-In/Receiver .................................................................................................................... 66
ユーザー............................................................................................................................................. 67
トレーニングとサポート...................................................................................................................... 67
謝辞 ................................................................................................................................................... 69
改定履歴 ............................................................................................................................................ 69
2
概要
適切な XenDesktop および XenApp 環境を実現するためには、企業は、過去の導入事例やラボ検証から収集
された知識や、現場で学んだ教訓に基づく数多くのベストプラクティスに従って設計基盤を構築する必要がありま
す。このようなベストプラクティスは設計のための単なる出発点であり、組織に特有の設計においては推奨事項を
守れない場合もよくあることに注意してください。本書で示す推奨事項を出発点として利用することにより、各種の
配備シナリオをサポートするための堅牢な設計基盤を構築できます。
本書では、XenApp 環境および XenDesktop 環境向けのベストプラクティスをまとめて紹介します。なお、当然な
がら、製品が進化するにつれてベストプラクティスも変化します。本書で紹介するベストプラクティスは、下記の製
品とバージョンに対して適用されるものであることに注意してください。
•
XenDesktop 5.0、5.5、5.6
•
XenApp 6.0、6.5
また、本書では、XenDesktop および XenApp の両方に対して付加的な機能を提供する、以下の製品に関する
ベストプラクティスも紹介しています。
•
Citrix Provisioning Services
•
Citrix XenServer
•
Citrix Profile Manager
•
Microsoft Hyper-V
•
VMware vSphere
詳細については、XenDesktop Design Handbookを参照してください。
本書で紹介されている推奨事項は、すべての環境に対して当てはまるとは限りません。このため、本書で示され
ているすべてのベストプラクティスは、それらを実務環境に実装する前に、隔離されたテスト環境で評価する必要
があります。
注意: 本書で紹介するベストプラクティスの中には、ユーザーによるレジストリの編集を必要とするものがあります。
レジストリエディタの操作を誤った場合、オペレーティングシステムの再インストールが必要となるような重大な問
題が発生することがあります。レジストリエディタを誤って操作した結果発生した問題に関しては、弊社は一切の
保証を行いません。レジストリを編集する前には、必ずレジストリのバックアップを取るようにしてください。
3
本書の構成
本書の構成は、XenDesktop または XenApp インフラストラクチャー内にある共通のテクノロジーレイヤを反映し
ています。このレイヤモデルを下記の図に示します。
ユーザー
アクセス
パーソナライズ
アプリケーション
制御
デスクトップ
ハードウェア
•
一般的な推奨事項: すべてのシトリックス製品導入に対して適用できる、特定の機能やテクノロジーには
直接関連しないベストプラクティスや推奨事項を紹介します。
•
制御レイヤ: XenApp ファーム設計、XenDesktop サイト設計、データベース、ライセンスサーバー、ネッ
トワーク、Active Directory 統合に関するベストプラクティスや推奨事項を紹介します。
•
ハードウェアレイヤ: 3 つの主要ハイパーバイザー（Citrix XenServer、Microsoft Hyper-V、VMware
vSphere）に関するベストプラクティスを紹介します。
•
デスクトップレイヤ: デスクトップイメージ（最適化を含む）およびデスクトップイメージ配信に関するベスト
プラクティスを紹介します。
•
アプリケーションレイヤ: 仮想デスクトップでのアプリケーション統合に関するベストプラクティスを紹介し
ます。
•
パーソナライズレイヤ: 印刷、プロファイル、ポリシーに関するベストプラクティスを紹介します。
•
アクセスレイヤ: Citrix Web Interface や Citrix Receiver（およびそのプラグイン）に関するベストプラク
ティスを紹介します。
•
ユーザーレイヤ: トレーニングやサポートなど、当該システムを使用するユーザーに関するベストプラク
ティスを紹介します。
4
一般的な推奨事項
カテゴリ
方法論
アプリケーション互換
性のチェック
コ ン ポー ネン トの分
離
テスト環境
ホットフィックスと
サービスパック
ベストプラクティス
構造化された実績ある方法論に常に従う必要があります。Citrix Consulting Methodologyは明確に定義された 4 つの
フェーズ（分析、設計、構築/テスト、ロールアウト）から構成されています。各フェーズには、一連のチェックポイントと成
果物が対応しており、重要なステップを逃さないようになっています。
また、Desktop Transformation Modelは、デバイス中心型の分散管理パラダイムから、よりユーザー中心型の仮想化
モデルへと移行する方法に関して具体的なガイドラインを提供します。無料ツール、専門家によるガイダンス、ベンチ
マークに関するステップごとのヘルプについては、Desktop Transformation Acceleratorを参照してください。
新しいオペレーティングシステムやアプリケーションデリバリーテクノロジーへと移行する場合、できるだけ早期にアプリ
ケーション互換性を検証する必要があります。これは、必要な修復作業を実施するのに十分な時間が取れるようにする
ためです。Citrix AppDNAを使うと、アプリケーションの評価を迅速に実施すると同時に、必要な修復措置に関する詳
細情報を提供できます。
大規模配備では、主要なインフラストラクチャーロールを専用サーバー上でホスティングすることにより、セキュリティ、
スケーラビリティ、高可用性、サポートを強化する必要があります。例としては、Web Interface サーバー、XenDesktop
コントローラー、ゾーンデータコレクター、プロビジョニングサーバー、ライセンスサーバー、データベースサーバーなど
が挙げられます。
実務環境に実装する前に、ソフトウェア、構成、ハードウェアなどの変更を検証できるようにするために、隔離されたテ
ストインフラストラクチャーを実装する必要があります。テスト環境は、実務環境をできるだけ忠実に反映している必要
があります。
最適な性能、安定性、セキュリティを実現するために、オペレーティングシステム、アプリケーション、Citrix コンポーネン
トのホットフィックスやアップデートを最新状態に保つ必要があります。シトリックス固有のホットフィックスには、以下に
示す推奨事項が適用されます。
•
サービスパックおよびホットフィックスロールアップパックは必ずインストールすること
•
クリティカルであると示されているセキュリティフィックスやホットフィックスは必ずインストールすること
•
汎用ホットフィックスや限定リリース用ホットフィックスは、「必要な場合」にのみインストールすること
重要: アップデートやホットフィックスは、実務環境でロールアウトする前に、必ずテスト環境でテストしてください。また、
関連するサーバーロールや仮想デスクトップグループ間で、整合的にパッチを適用することを強く推奨します。
適用対象
XD 5.x
XA 6.x
XD 5.x
XA 6.x
XD 5.x
XA 6.x
XD 5.x
XA 6.x
XD 5.x
XA 6.x
制御レイヤ
XenDesktop コントローラー
カテゴリ
スケールアップ/ス
ケールアウト
ベストプラクティス
スケールアップ（サイトごとの仮想デスクトップ数/ユーザー数の増加）を行うか、それともスケールアウト（サイトの追加）
を行うかの判断は、以下の要因に左右されます。
•
ユーザーまたは自社組織のロケーションとニーズ: サービスプロバイダーの場合、サービス提供先の組織ごと
に専用のサイトを提供することが考えられます。複数のサイトを利用すると、特定の SLA を遵守していることの
実証が容易になる場合があります。
•
自社組織の地理的レイアウト: XenDesktop サイトは、フォールトトレラントな低レイテンシのリンクが提供され
ない限り、複数の物理ロケーションにまたがるべきではありません。これは XenDesktop コントローラーが、
SQL データベースに常にアクセスし、仮想デスクトップと定期的に通信する必要があるためです。コントロー
ラー、SQL データベース、仮想デスクトップ間で大きなレベルのレイテンシが存在する場合、XenDesktop は予
期せぬ動作をする場合があります。
•
サイト規模の機能停止（SQL データベースの故障など）による影響を最小化するには、複数の XenDesktop
サイトを利用することを検討します。環境によっては、複数の管理ポイントの導入により管理オーバーヘッドが
増加することよりも、リスクを減少させることの方が重要となる場合があります。
適用対象
XA 6.x
冗長性
すべての XenDesktop サイトは、冗長性を実現するために、少なくとも 2 台のコントローラーを持つ必要があります。
XD 5.x
コントローラーのロー
ル
XenDesktop Site Services ロールを、XenDesktop コントローラーに対して手動で割り当てないでください。これを行う
と、XenDesktop の自動負荷分散やフェイルオーバーのメカニズムが妨害される可能性があります。
XD 5.x
仮想デスクトップのリ
ブートポリシー
ブートストームを回避し、多数のユーザーの同時ログオフに起因する性能への悪影響が出ないようにするには、ログオ
フ時に自動的にリブートしないように仮想デスクトップを設定する必要があります。さらに、デスクトップグループ内部で
アイドルデスクトップ設定を実施し、デスクトップが 1 日 1 回、業務時間外にリブートするように設定します。詳細につい
ては、CTX127842 - XenDesktop 5 におけるデスクトップグループのログオフ動作の設定方法を参照してください。
VDA 登録プロセスで Kerberos 認証を使用するため、VDA とコントローラー間で時刻を同期させる必要があります。
NTP（Network Time Protocol）を使用して、すべてのコンポーネント間での時刻同期が実施されます。
XD 5.x
時刻の同期
XD 5.x
6
スケーラビリティ
ホスト接続のスロット
リング
Desktop Director
のホスティング
スケーラビリティテストの結果に基づいて、十分なリソースを XenDesktop コントローラーに対して割り当てる必要があ
ります。これにより、ブートストームやログオンストームのようなピークアクティビティ時に、コントローラーがボトルネック
とならないことを保証できます。シトリックスは、XenDesktop コントローラーロールのスケーラビリティに関する内部テス
トを実行した結果、以下のことを確認しています。
•
物理 XenDesktop コントローラー（クアッドコア 1.86GHz×2、16GB RAM）1 台で、20 分間のタイムフレーム
内で 20,000 件以上の仮想デスクトップブート/ユーザーログオンを処理できます。
•
仮想 XenDesktop コントローラー（vCPU×2、4GB RAM）1 台で、4 時間のタイムフレーム内で 2,500 件以上
の仮想デスクトップブート/ユーザーログオンを処理できます。
詳細については、CTX128700 – XenDesktopプランニングガイド – XenDesktopのスケーラビリティを参照してくださ
い。
アクティブなアクションの最大数および 1 分ごとの新規アクションの最大数の各値を、ハイパーバイザープールの能力
に従って調整する必要があります。これらの初期値は、ホスト数の 2 倍になります。
この値を大きくすると、性能やユーザーエクスペリエンスに悪影響が出る可能性があるため、大きな値を有効にする前
に総合的なスケーラビリティテストを実施する必要があります。
Desktop Director の同時ユーザー数が 50 を超えるような大規模な XenApp および XenDesktop 配備の場合、
Desktop Director ロールを専用サーバー上でホスティングする必要があります。インテリジェントな負荷分散アプライア
ンス（Citrix NetScaler など）を通じて、複数の Desktop Director サーバーの負荷分散を行う必要があります。これによ
り、Windows Internet Information Service（IIS）の可用性および Desktop Director Web サイトの可用性を確認できま
す。
XD 5.x
XD 5.x
XD 5.x
XA 6.5
詳細については、Citrix eDocs – Desktop Directorのインストールとアップグレードを参照してください。
7
XenApp コントローラー
カテゴリ
ベストプラクティス
適用対象
ファームの数
ほとんどの XenApp 配備は単一のファームから構成されます。ただし、状況によっては、複数のファームを配備するこ
とに意義がある場合があります。単一ファームと複数ファームのどちらを実装するかの判断は、以下の要因に左右され
ます。
XA 6.x
ゾーンの数
専用のゾーンデータ
コ レ ク タ ー /XML ブ
ローカー
•
ユーザーまたは自社組織のロケーションとニーズ: サービスプロバイダーの場合、サービス提供先の組織ごと
に専用のファームを提供することが考えられます。複数のファームを実装すると、特定の SLA を遵守している
ことの実証が容易になる場合があります。
•
自社組織の地理的レイアウト: 自社の IT インフラストラクチャーが地域ごとに組織化されており、分散方式で管
理されている場合、複数のファームを実装することによりファームの性能を改善できます。また、複数のファー
ムを実装すると、ファーム管理の調整時に時間を節約することや、ファーム全体の問題のトラブルシューティン
グを簡素化することが可能になります。
•
ネットワークインフラストラクチャーの制限: レイテンシやエラー率の高い WAN 環境では、単一ファームを実装
して複数のゾーンを扱うよりも、複数のファームを実装した方が性能をアップできます。
•
サーバー通信に関する組織のセキュリティポリシー: 自社組織でセキュリティレベルに基づいてデータを分離す
る必要がある場合には、複数ファームの実装を検討します。同様に、規制コンプライアンスを実現するために
複数のファームが必要となる場合があります。
•
ファーム規模の機能停止による影響を最小化するには、複数のファームを導入することを検討します。環境に
よっては、複数の管理ポイントの導入により管理オーバーヘッドが増加することよりも、リスクを減少させること
の方が重要となる場合があります。
詳細については、Citrix eDocs – サーバーファームの数の決定を参照してください。
一般的に、シトリックスは、できるだけ少ない数の最適なゾーンを使用することを推奨します。すべてのファームサー
バーが同一場所に存在する場合、そのファーム用に 1 つのゾーンのみを構成します。これにより、性能が低下すること
やファームの管理が困難になることはありません。ただし、世界各地にデータセンターを持つ組織のような大規模ネット
ワークの場合、地理的に近い場所にあるサーバーをゾーン内にグループ化することにより、ファームの性能を改善でき
ます。詳細については、Citrix eDocs – XenApp展開環境のゾーンの設計を参照してください。
データコレクターとは、インメモリデータベースをホスティングするサーバーのことです。同データベースは、ゾーン内の
サーバーに関する動的情報（サーバー負荷、セッション状態、公開されているアプリケーション、接続ユーザー、ライセ
ンス利用状況など）を保持します。データコレクターは、ゾーン内のサーバーからのインクリメンタルなデータのアップ
XA 6.x
XA 6.x
8
デートやクエリを受信します。データコレクターは、ファーム内にある自分以外のすべてのデータコレクターに対して情報
を中継します。専用のゾーンデータコレクターを利用すると、高負荷時のユーザーログオン処理や管理タスクの性能を
改善できます。
Citrix XML ブローカーは、ファーム内の他のサーバーと Web Interface 間の仲介者として機能します。ユーザーが
Web Interface で認証を行うと、XML ブローカーは以下の処理を実施します。
•
同ユーザーのクレデンシャルを Web Interface から受信した後、同ユーザーがアクセスを許可されている公開
アプリケーションのリストをサーバーファームに問い合わせます。XML ブローカーは、このようなアプリケーショ
ンセットを Independent Management Architecture（IMA）システムから取り出し、それを Web Interface に戻
します。
•
ユーザーからのアプリケーション起動要求を受け取った場合、XML ブローカーは、そのアプリケーションをホス
ティングしているファーム内の複数のサーバーを見つけた後、いくつかの要因に基づいて、当該接続に最も適
したサーバーを 1 台特定します。その後、XML ブローカーは、このサーバーのアドレスを Web Interface に戻
します。
専用のデータコレクターや XML ブローカーを実装する場合の推奨事項を以下に示します。
セッションオンリー
モード
•
サーバー数が 10 台を超える XenApp ファームの場合、専用のゾーンデータコレクターを実装します。専用の
ゾーンデータコレクターは、「コントローラーモード」を有効にした状態でインストールされる XenApp サーバーで
あり、同サーバーの Zone Election Preference は“Most Preferred”に設定されます。このサーバーでは、ユー
ザーアプリケーションのホスティングは一切行いません。
•
サーバー数が 20 台を超える XenApp ファームの場合、専用のゾーンデータコレクターに加えて、専用のバッ
クアップゾーンデータコレクターを実装することを推奨します。バックアップゾーンデータコレクターは、「コント
ローラーモード」を有効にした状態でインストールされる XenApp サーバーであり、同サーバーの Zone
Election Preference は“Preferred”に設定されます。このサーバーでは、ユーザーアプリケーションのホスティ
ングは一切行いません。
•
同時ユーザー数が 2,000 名を超える XenApp ファームや、重いログオントラフィック期間が予想されるファーム
の場合、専用の XML ブローカーを実装します。まず 2 台の専用 XML ブローカーから始めて、その後、必要に
応じてスケールアウトを実施します。専用 XML ブローカーは、「コントローラーモード」を有効にした状態でイン
ストールされる XenApp サーバーであり、同サーバーにはデフォルトの Zone Election Preference が割り当
てられます。同サーバーは Web Interface と XenApp ファーム間の通信に使用されるものであり、ユーザーア
プリケーションのホスティングは一切行いません。
詳細については、Citrix eDocs – ゾーンとバックアップデータコレクターを設定するにはを参照してください。
XenApp 6.5 は、「セッションオンリーモード」と呼ばれる XenApp サーバー向けの新しいモデルを導入しています。これ
により、ファームのジョインやローカルホストキャッシュ（LHC）同期を実施する場合の IMA やデータストアの性能を改善
XA 6.x
9
専用の管理サー
バー
ホットフィックス展開
の順番
できます。XenApp のサーバーモードでは、サーバーでセッションのホスティングのみを行う（セッションオンリーモード）
か、それともデータコレクターとして選択されることや XML ブローカーロールのホスティングを可能にするためにコント
ローラー機能も実行できるようにする（コントローラーモード）かのどちらかを指定できます。「コントローラーモード」を有
効にする必要があるのは、サーバーをゾーンデータコレクターまたは XML ブローカーとする場合のみです。詳細につ
いては、
Citrix eDocs – XenAppを構成する前にを参照してください。
エンタープライズクラスのインフラストラクチャーの場合、XenApp ファーム管理に必要となるすべてのツールとアプリ
ケーションをホスティングする専用の XenApp 管理サーバーを実装することを推奨します。管理者は、「公開アプリケー
ション」または「公開デスクトップの一部」として、これらのプログラムにアクセスします。これにより、通常の日常的な管
理タスクがゾーンデータコレクターやアプリケーションサーバーの性能に影響を与えないことを保証できます。管理サー
バーは、「コントローラーモード」を有効にしてインストールする必要があります。これを行わない場合、その管理サー
バー上では、XenApp コンソール要求をローカルに処理できなくなります。
特に大規模または複雑なファーム構成の場合、ホットフィックス展開の順番は極めて重要です。シトリックスでは、ホット
フィックスを以下の順番で展開することを推奨します。
XA 6.x
XA 6.x
1. ゾーンデータコレクター
2. バックアップゾーンデータコレクター
3. メンバーサーバー
構成のロギング
（Configuration
Logging）
詳細については、CTX120842 - Citrix XenApp Hotfix Rollup Packのインストールと配備に関するベストプラクティスを
参照してください。
構成のロギング（Configuration Logging）機能を使うと、XenApp 環境に対して実施された管理上の変更をトラッキング
できます。この機能は、すべての高セキュリティ環境で有効にする必要があります。同機能により利用可能となるレポー
トを生成することにより、変更の内容、変更日時、変更を実施した管理者などを判定できるようになります。この機能
は、複数の管理者が同じサーバーファームの設定を変更する場合に特に便利です。また、これにより、変更の特定が
容易になるため、必要に応じて管理上の変更を元に戻すことも可能となります。
XA 6.x
10
SQL データベース
カテゴリ
SQL データベースの
冗長性
ベストプラクティス
XenDesktop コントローラーは、SQL データベースを利用することにより、静的な設定や動的なユーザーセッション関連
情報を保存しています。SQL データベースの機能停止が発生した場合、既存の接続は影響を受けませんが、新しい
ユーザーは仮想デスクトップにアクセスできなくなります。このため、ミラーリングやクラスタリングなどの方法により、
SQL データベースを冗長化する必要があります。
•
ミラーリング: データベースのミラーリングは、主にソフトウェアソリューションとして実現されるものであり、ほぼ
瞬間的なフェイルオーバーをサポートすることによりデータベースの可用性を強化します。データベースのミ
ラーリングを利用すると、対応する実稼働データベース（プリンシパルデータベース）ごとに、単一のスタンバイ
データベース（ミラーデータベース）を維持できるようになります。データベースのミラーリングは、高セイフティー
モードでは同期操作と共に、高性能モードでは非同期操作と共に実行されます。自動フェイルオーバー付きの
高セイフティーモード（XenDesktop で推奨）の場合、3 つ目のサーバーインスタンス（ウィットネスと呼ばれる）
が必要となります。これにより、ミラーサーバーをホットスタンバイサーバーとして動作させることが可能となりま
す。プリンシパルデータベースからミラーデータベースへのフェイルオーバーは自動的に発生します（通常、こ
れは数秒間で実施されます）。複数サーバーが機能停止した場合に SQL サービスの利用可能性を保証する
ために、少なくともウィットネスで VM レベルの HA（または同様の自動リスタート機能）を有効にしておくことを
推奨します。
•
クラスタリング: フェイルオーバークラスタリングを使うと、1 つの SQL Server インスタンス全体に対する高可
用性サポートを提供できます。1 つのフェイルオーバークラスタは、1 つ以上のノード（ないしサーバー）と、2 つ
以上の共有ディスクから構成されます。SQL Server フェイルオーバークラスタインスタンスは、ネットワーク上
では単一のコンピューターとして認識されますが、現在のノードが利用できなくなった場合、そのノードから別の
ノードへとフェイルオーバーする機能を提供します。ノード間の移行は、同クラスタに接続しているクライアント
にとってシームレスに実施されます。
適用対象
XD 5.x
テスト環境の場合、3 つ目のオプションである「VM レベルの HA」が利用できます。VM レベルの HA は、仮想 SQL
Server でのみ機能します。その仮想 SQL Server は、ハイパーバイザーレイヤで「高可用性」に関してマーク付けされ
ている必要があります。これは、仮想マシンや基盤となるホストの予期せぬシャットダウンが発生した場合、ハイパーバ
イザーが当該 VM のリスタートを直ちに試みることを意味します。「VM レベルの HA」を使うと電源停止時のダウンタイ
ムを最小化できますが、OS レベルの障害を防ぐことはできません。
詳細については以下の文書を参照してください。
11
•
MSDN – SQL Server 2008 R2 高可用性ソリューションの概要
•
Citrix eDocs – 高可用性の計画
•
CTX127939 – SQL データベースのサイジングとミラーリング
データストアは、XenApp ファームのあらゆる静的情報を格納する中央リポジトリです。これには、構成、公開アプリ
ケーション、ワーカーグループ、ロードエバリュエーターなどに関する情報が含まれます。正常なファーム運用時には、
各サーバーのローカルホストキャッシュが最新であることを保証するために、各サーバーによるデータストアへのアクセ
スが 30 分ごとに発生します。ファーム構成が変更された場合や、Citrix AppCenter Console やその他のクエリベース
のシトリックスのユーティリティなどのツールによって静的情報が要求された場合にも、データストアへのアクセスが発
生します。
SQL データベースの
バックアップ
ユーザーのファームへのログイン時、ファームからの切断時、ファームへの再接続時には、データストアへのアクセスは
発生しません。クライアントがXenAppサーバーへの接続を確立するために必要となる情報はすべて、ローカルホスト
キャッシュ（LHC）に保存されています。このため、データストアが利用できない場合でも、ユーザーはXenAppファーム
に接続できます。ただし、この場合、サポートスタッフはCitrix AppCenter Consoleやその他のクエリベースのシトリック
スのユーティリティ経由での設定の変更は行えなくなります。このため、SQLミラーリングやクラスタリングを利用して、
データストアの高可用性を保証する必要があります。詳細については、CTX111311 – SQLデータベースのミラーリン
グを使用してCitrix XenAppサーバーファームの災害復旧機能を改善するにはを参照してください。
障害による影響を軽減し、SQLトランザクションログのサイズを縮小するために、XenDesktopおよびXenDesktopデー
タベースのバックアップを定期的に取る必要があります。詳細については、CTX126916 – XenDesktop 5 のデータ
ベースログのサイズが過剰に肥大した場合の処置を参照してください。
XA 6.x
XD 5.x
XA 6.x
12
デ ータベ ースのロッ
ク
大 規 模 環 境 で は 、 XenDesktop デ ー タ ベ ー ス が 高 負 荷 で 利 用 さ れ て い る 状 態 に な る 場 合 が あ り ま す （ getbrokerdesktopusage を実行した場合など）。このため、XenDesktop データベース上で Read_Committed_Snapshot
オプションを有効にすることにより、読み取りクエリからデータベース上の競合を取り除くことを推奨します。これにより、
Desktop Studio と Desktop Director 間の対話性が改善されます。なお、このオプションを指定すると、tempdb ファイ
ル上の負荷が増加することに注意してください。
XD 5.x
Read_Committed_Option を有効にするには、以下のコマンドを使用します。
ALTER DATABASE CitrixXenDesktopDB SET READ_COMMITTED_SNAPSHOT ON
注: Read_Committed_Option を有効にするにはデータベースをシングルユーザーモードに切り替えなければならない
場合があります。これを行うには以下のコマンドを使用します。
ALTER DATABASE CitrixXenDesktopDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE
ALTER DATABASE CitrixXenDesktopDB SET READ_COMMITTED_SNAPSHOT ON
ALTER DATABASE CitrixXenDesktopDB SET MULTI_USER
SQL Server の ス
ケーラビリティ
注: ミラーリングされているデータベースを使用する場合、Microsoftブログに投稿された記事 – ミラーリングを行ってい
るデータベースでRCSIを有効にするにはを参照してください。
スケーラビリティテストの結果に基づいて、十分なリソースを SQL Server に対して割り当てる必要があります。これに
より、ピークアクティビティ時に同サーバーがボトルネックとならないことを保証できます。シトリックスは、SQL Server
ロールのスケーラビリティに関する内部テストを実施した結果、以下のことを確認しています。
•
物理 SQL 2008 R2 サーバー（クアッドコア 1.86GHz×2、16GB RAM、HA ミラーリング構成）1 台で、20,000
台を超える仮想デスクトップを提供する XenDesktop サイトをサポートできます。
•
仮想 SQL 2008 R2 サーバー（vCPU×2、4GB RAM、HA ミラーリング構成）1 台で、2,500 台を超える仮想デ
スクトップを提供する XenDesktop サイトをサポートできます。
XD 5.x
13
ライセンスサーバー
カテゴリ
ベストプラクティス
適用対象
Citrix License
Server の冗長性
通常の環境（エンタープライズクラスの環境を含む）では、単一のライセンスサーバーを仮想マシンまたは仮想アプライ
アンス（VMレベルのHA（自動リブート）用に設定されているもの）として実装することを推奨します。同サーバーは単一
障害点として認識されることになりますが、これは全体的なCitrixインフラストラクチャーの可用性には影響を与えませ
ん。なぜなら、すべてのシトリックス製品は、いかなる機能性を低下させることなく、最大で 30 日間のライセンスサー
バーの停止をサポートするためです。ライセンスサーバーHAのその他のオプションとしては、クラスタリングやホット/
コールドスタンバイ実装が挙げられます。詳細についてはCitrix eDocs – ライセンスシステムのアーキテクチャの概要
を参照してください。
XD 5.x
Citrix License
Server のスケーラビ
リティ
Microsoft License
Server の冗長性
注: XenAppサーバーの場合、30 日間のライセンス猶予期間を提供するために必要となる情報は各サーバー上にロー
カルに格納されています。Provisioning Servicesベースのインフラストラクチャーの場合、ランタイム中に各XenApp
サーバー上で関連情報がアップデートされます。ただし、リブートを行うと、この情報はvDisk内に保存されている状態
へとリセットされます。最後の 30 日間内にvDiskが保守状態になっていない場合に、ライセンスサーバーが失敗し、
XenAppサーバーがリブートされると、それ以降、新しいユーザーセッションは確立されなくなります。この場合、MPSWSXICA_MPS-WSXICA.iniをファイルシェアに対してリダイレクトする必要があります。詳細については、CTX131202
- ライセンスサーバーが利用できない場合にプロビジョニング済みのXenAppサーバーをリスタートすると、同サーバー
は接続の受付を中止するを参照してください。
スケーラビリティテストを実施して、Citrix License Server に割り当てられている仕様で環境の要求を満足できることを
確認する必要があります。シトリックスによるスケーラビリティテストでは、単一の Citrix License Server（2 コア、2GB
RAM）で、1 秒間に約 170 件のライセンス（30 分間に約 306,000 件のライセンス）を発行できることが実証されていま
す。
Microsoft は、冗長性を提供するために、2 台の Remote Desktop Services（RDS）License Server を実装し、これら
のマシン間で公平にライセンスを分割することを推奨しています。これらの RDS サーバーを指定するには、Microsoft
のグループポリシーを使用します。セッションホストが接続を試みた 1 台目のライセンスサーバーが利用できないか、ま
たは同サーバーが利用可能なライセンスを保有していない場合、2 台目のライセンスサーバーへの接続が試みられま
す。グループポリシー設定は以下の場所に格納されます。
•
XA 6.x
XD 5.x
XA 6.x
XA 6.x
Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop
Services\Remote Desktop Session Host\Licensing
14
ネットワーキング
カテゴリ
様々な形でルーティ
ングされるネットワー
ク接続
ベストプラクティス
現在、多くのサーバーは、2 つ以上のポートを持つネットワークカードを搭載しています。このため、単一カードの障害に
よりボンドがダウンしないように、あらゆるボンドが 2 つの独立した物理ネットワークカードからの接続を含むようにする
必要があります。管理、仮想マシン、プロビジョニング用のトラフィックをそれぞれ処理するネットワークボンドを提供する
ために、3 つのデュアルポートネットワークカードを設定する方法を下記の図に示します。
適用対象
XD 5.x
XA 6.x
ボンド 0：管理／NIC: eth0 と eth2／負荷分散対象外
ボンド 1：仮想マシン／NIC: eth1 と eth4／負荷分散の対象
サービス品質（QoS）
ボンド 2：Provisioning Services／NIC: eth3 と eth5／負荷分散の対象
利用頻度の高い WAN 接続（アップストリームおよびダウンストリーム）ではサービス品質（QoS）を有効にする必要が
あります。これにより、重度の輻輳時であっても Citrix ICA/HDX 接続において一定レベルの性能を保証できます。これ
を実現するには、TCP ポート 1494 番および 2598 番を最上位の QoS クラスに含める必要があります。また、「Audio
over UDP Real-time Transport」や「Multi-Stream ICA」のような高度な機能で使用されるポートについても、QoS を有
効にすることを検討してください。
XD 5.x
XA 6.x
15
エンドツーエンドの接
続速度
速度と二重化設定
DHCP の冗長性
DNS の冗長性
DNS の動的更新
DNS エイリアス
セキュリティ
ポート
最適なユーザー性能を実現するには、十分な帯域幅が存在すること、およびネットワークレイテンシが最小に保たれて
いることを保証する必要があります。短期間の LAN/WAN 輻輳であっても、性能に対して著しく影響する場合がありま
す。
XenDesktop および XenApp 環境に関連するすべてのネットワークリンクを監視することにより、ボトルネックを先回り
して検出できることを保証する必要があります。一般的なボトルネックとしては、ブレードスイッチやファイルサーバー用
のアップリンク、WAN 接続、セキュリティゾーン間の接続、ブランチ接続などが挙げられます。
10/100BASE-T ネットワークの場合、NIC 上およびスイッチ上のすべてのポート（サーバーおよびクライアント）の速度
設定と二重化設定をハードコーディングすることを推奨します。
1000/10GBASE-Tネットワークの場合、RFC802.3-2008 に定義されているような、速度設定と二重化設定の自動ネゴ
シ エ ーシ ョ ンが必要 とな りま す。詳 細に つい ては、RFC802.3-2008 – Local and Metropolitan Area Network
Standards（608 ページ/第 28D.5 章）を参照してください。
プロビジョニング済みの仮想デスクトップおよび XenApp サーバーは、DHCP を利用して IP アドレスを配布します。こ
のため、以下に示すオプションを使用して、高可用性に対応した DHCP インフラストラクチャーを実装する必要がありま
す。
•
単一のアクティブ DHCP サーバーと「コールドスタンバイ」サーバー
•
2 台のアクティブ DHCP サーバーと「分割スコープ」機能
•
DHCP クラスタまたは DHCP HA アプライアンス
詳細については、Microsoft TechNet – DHCPの可用性とフォールトトレランスに関する設計オプションを参照してくださ
い。
XenDesktop および XenApp 環境では、コンポーネント間の通信を行うために DNS を必要とします。このため、冗長性
を提供するために、すべてのサーバーおよび仮想デスクトップ上の各ゾーンで、最小でも 2 台の DNS サーバーを構成
する必要があります。
XenDesktop は、XenDesktop コントローラーや仮想デスクトップを実現するために、完全な機能を持つ DNS ソリュー
ションを必要とします。通常、仮想デスクトップは DHCP 経由で IP アドレスを取得するため、DNS の A レコードを動的
に更新できることが必要となります。
XenDesktop サーバーおよび XenApp サーバーは、Citrix License Server やデータベースサーバーなどのインフラス
トラクチャーコンポーネントにアクセスする場合に、ホスト名や IP アドレスではなく、DNS エイリアスを使用するように設
定する必要があります。こうすることで、保守シナリオや災害復旧シナリオの適用時に、管理を簡素化できます。
仮想デスクトップ/XenApp サーバーや、XenDesktop/XenApp の任意のインフラストラクチャーコンポーネントを、信頼
できないネットワーク（インターネットなど）に直接公開しないでください。ユーザーのクレデンシャルの転送に使用される
接続（エンドポイントと Web Interface 間の接続など）はすべて、SSL 暗号化などを使って保護する必要があります。
XenDesktop インフラストラクチャーコンポーネント間やクライアントコンポーネント間で、以下に示す TCP/UDP ポート
XD 5.x
XA 6.x
XD 5.x
XA 6.x
XD 5.x
XA 6.x
XD 5.x
XA 6.x
XD 5.x
XA 6.x
XD 5.x
XA 6.x
XD 5.x
XA 6.x
XD 5.x
16
が開かれていることを確認してください。
XA 6.x
XenDesktop コントローラー  XenDesktop コントローラー/インフラストラクチャーサーバー
•
Citrix XenServer
TCP 80/443
•
Microsoft Hyper-V
TCP 8100
•
VMware vSphere
TCP 443
•
XenDesktop コントローラー
TCP 80/443
•
Citrix License Server
TCP 7279 / 27000
•
SQL データベース
TCP 1433 / 1434
•
ドメインコントローラー
TCP 135、139、389
•
DNS
TCP 53
XenDesktop コントローラー  仮想デスクトップ
•
TCP 80、135、3389、5985
仮想デスクトップ  ICA クライアント
•
TCP 1494、2598
•
UDP 16500～16509
詳細については、CTX101810 – Citrixテクノロジーが使用する通信ポートを参照してください。
17
Active Directory
カテゴリ
Active Directory
の構成
ベストプラクティス
グループポリシーの適用や、その他の Active Directory 関連の管理タスクがより柔軟に行えるようにするために、通
常、Citrix インフラストラクチャーコンポーネント、仮想デスクトップ、XenApp サーバーは専用の組織ユニット内部に配
置する必要があります。
適用対象
XD 5.x
XA 6.x
シトリックスは、Active Directory を使用する XenApp サーバーファームに関して以下の構成を推奨します。
•
XenApp サーバーがそれぞれ専用の組織単位（OU）内に存在すること。
•
ワーカーグループ用の OU（アプリケーションサイロ）を作成し、異なるワーカーグループをそれぞれに固有の
OU 内にまとめること（ただし、複数の OU にまたがるワーカーグループを作成することは可能）。
•
サーバーファームドメインは、非 Active Directory ドメインとは信頼関係を持たないこと（信頼ドメインを必要と
する操作に影響する可能性があるため）。
•
すべてのサーバーが同一ドメイン内に存在すること（ただし、複数の信頼ドメインおよび非信頼ドメインを通じて
ファームを展開することは可能）。
•
サーバーファームが単一の Active Directory フォレスト内に存在すること。1 つのファームが複数のフォレスト
内にあるサーバーを含んでいる場合、ユーザーはユーザープリンシパル名（UPN）を入力することではログオ
ンできません。UNP ログオンでは、「ユーザー名@UPN 識別子」という形式を使用します。Active Directory を
使用する場合、UPN ログオンでドメインの指定は不要です。これは、Active Directory は当該ディレクトリ内で
完全な UPN ログオンを検索できるためです。ただし、サーバーファームが複数のフォレストを含んでいる場
合、 独立した フ ォレ スト内 の 2 つのド メイ ンに 同 じ UPN 識別子 が存在 すると 、問題が発 生し ます 。
重要: 1 つのサーバーファームが複数の Active Directory フォレストにまたがっている場合、Citrix XenApp は
UNP ログオンをサポートしません。
シトリックスは、Active Directory を使用する XenDesktop 環境に関して以下の構成を推奨します。
•
XenDesktop コントローラーと仮想デスクトップが独立した組織単位（OU）内に配置されていること。
•
XenDesktop コントローラーと仮想デスクトップが同一の Active Directory フォレスト内に配置されていること
（ただし、複数のフォレストを通じて XenDesktop 環境を展開することは可能）。
詳細については、以下の Citrix Knowledgebase および eDocs の記事を参照してください。
•
Citrix eDocs – Active Directory に関する推奨事項
18
ループバックポリ
シー
•
Citrix eDocs – アカウントと信頼関係の計画
•
Citrix eDocs – Active Directory に関する注意事項
•
CTX122417 – 複数の Active Directory フォレストで XenDesktop を使用するには
グループポリシーに基づくユーザー設定を、ローカルエンドポイントデバイスと仮想デスクトップ/XenApp サーバー間で
変える必要がある場合、シトリックスは、「グループポリシーループバック処理モード」を使用することを推奨します。この
モードを使うと、ユーザーオブジェクトではなく、コンピューターオブジェクトの OU にリンクされている GPO を通じてユー
ザー設定を適用することが可能となります。コンピューターごとのユーザー設定を指定するには、以下の手順を実行し
ます。
XD 5.x
XA 6.x
1. Group Policy Microsoft Management Console（MMC）で、[Computer Configuration]をクリックします。
2. [Administrative Templates]→[System]→[Group Policy]をクリックし、[Loopback Policy]オプションを有効に
します。
詳細については、Microsoft Knowledgebase Article KB231287 - グループポリシーのループバック処理を参照してく
ださい。
19
システム管理
カテゴリ
モニタリング
キャパシティプランニ
ング/管理
バックアップ
ベストプラクティス
許容可能なしきい値を超過した場合に、性能低下を引き起こすことなくサポート可能な最大ユーザー数を決定するに
は、スケーラビリティテストを実施する必要があります。プロセッサ、メモリ、ディスク、ネットワークサブシステムの最大し
きい値を特定するには、スケーラビリティテストの実施中に主要な数値指標を記録する必要があります。
すべての実務インフラストラクチャーコンポーネント（仮想マシン、仮想化ホスト、ストレージインフラストラクチャー、ネッ
トワークアプライアンスを含む）を、常時緊密に監視する必要があります。スケーラビリティテストの結果に基づいてア
ラートを設定することにより、主要なしきい値を超過した場合に主な担当者にアラートが送付されるようにします。
モニタリングツールを使って収集した結果を定期的に分析することで、ビジネス要件をサポートするのに十分なインフラ
ストラクチャーが配備されていることを保証する必要があります。適切なキャパシティプランニングと管理を実施すること
により、ビジネス成長の結果として性能ボトルネックが生成されないことを保証できます。
完全に障害から回復できるようにするには、最小でも以下に示す XenDesktop コンポーネントおよび XenApp コンポー
ネントのバックアップを取る必要があります。
•
XenDesktop データベース
•
XenApp データベース
•
Provisioning Services データベース
•
Provisioning Services の vDisk（仮想デスクトップと XenApp サーバー）
•
XenServer VM/プールのメタデータ（または、その他のハイパーバイザーにおける相当物）
•
専用の仮想デスクトップ
•
Web Interface 設定
•
ライセンスファイル
•
User profiles/Home フォルダ
適用対象
XD 5.x
XA 6.x
XD 5.x
XA 6.x
XD 5.x
XA 6.x
注: バックアップおよび復元手順を簡素化するために、ユーザーデータは仮想デスクトップ上や XenApp サーバー上に
は保存しないようにします。
サーバー（XenDesktop コントローラー、XenApp サーバー、Web Interface サーバー、Provisioning Server など）向け
の自動化された高速な再構築手順が存在することを仮定しています。自社組織でこの仮定が成り立たない場合、すべ
てのインフラストラクチャーサーバーのバックアップを取る必要があります。
20
バックアップの保持
復元のテスト
XenDesktop のアッ
プグレード
シトリックス関連のバックアップはすべて、GFS（Grandfather-Father-Son）の原則に従う必要があります。さらに、オン
サイ トのバック ア ップが破 損した 場日でも シ トリックス のデー タを復元で きる よう に 、毎月の完全バックア ッ プ
（Grandfather（祖父）世代のバックアップ）を、オフサイトのストレージロケーションに少なくとも 6 ヶ月間保持する必要が
あります。詳細についてはGFS（Grandfather-Father-Son）方式のバックアップを参照してください。
バックアップの整合性を確認し、サポートスタッフが復元手順に精通していること保証するために、完全な災害復旧によ
る復元テストを少なくとも年 2 回実施する必要があります。
XD 5.x
シトリックスは、既存の XenDesktop サイトをアップグレードする場合、以下の手順に従うことを推奨します。
XD 5.x
XA 6.x
XD 5.x
XA 6.x
1. 専用のテスト環境内部でアップグレードをテストします。
2. XenDesktop サイトデータベースのバックアップを取ります。
3. ピーク負荷時以外の時間帯で、実務環境のアップグレードを実行します。
4. 必要に応じ、新バージョンの XenDesktop との互換性を保証するために、ライセンスサーバーをアップグレード
します。
5. XenDesktop コントローラーの 50%をアップグレードします。
6. XenDesktop Desktop Studio を使用するか、または自動生成された SQL スクリプトを使用して、XenDesktop
データベースをアップグレードします（注: データベースをアップグレードするには、DB_Owner パーミッション
が必要となります）。
7. 残りの XenDesktop コントローラーをアップグレードします。
変更管理
詳細については、CTX128748 – XenDesktop 5 サイトのアップグレードに関するベストプラクティスを参照してくださ
い。
ほとんどの企業の XenApp または XenDesktop 配備環境は、複数の個人またはチームにより管理されているため、変
更をトラッキングすることが困難です。自社組織内部で変更管理計画を作成すると、変更をピンポイントで特定すること
が容易になり、トラブルシューティングがより効率的になります。また、XenApp の構成ロギング機能を有効にすると、管
理コンソール内で行った変更を記録しておき、後でそれを表示できます。
XD 5.x
XA 6.x
21
テスト環境
シトリックスは、できるだけ実務環境に一致した完全なテスト環境を実装することを強く推奨します。この環境には、サー
バーだけでなく、スイッチ、ルータ、ファイアウォール、NAT デバイス、LAN/WAN シミュレーション装置なども含める必
要があります。専用のテスト環境がない場合、各種の変更やシナリオを完全にテストすることは不可能です。理想的に
は、少なくとも以下のような独立した環境を用意する必要があります。
XA 6.x
環境
サンドピット
保守作業
管理の委任
命名スキーム
目的
実務ネットワーク外で、IT 部門による初期テストを実施します。装置は、できるだ
け実務環境に近づけるようにします。
UAT
実務環境と同様の環境をユーザーや IT スタッフに提供することで、新しいアプリ
ケーション、サーバー構成、パッチなどをテストできるようにします。ここでサインオ
フされた変更は、計画段階へと移され、最終的に実務環境へと移されます。この
サイクルを継続することにより、実務環境で問題が発生するリスクを著しく削減で
きます。装置は、できるだけ実務環境に近づけるようにします。
XenDesktop および XenApp 環境の定期的な保守（日次、週次、月次、年次）を実施することにより、同環境がフルポ
テンシャルで運用されていることを保証する必要があります。典型的な保守作業としては以下のものが挙げられます。
XD 5.x
•
イベントログやアラートの確認
•
リブートスケジュールのチェック
•
構成ロギングの確認
•
ホットフィックスの確認
•
プリントドライバの確認
•
プラグインのアップグレード
•
証明書の置き換え
•
キャパシティの評価
•
バックアップ復元のテスト
詳細については、CTX128596 – 運用および保守ガイドを参照してください。
高セキュリティ環境では、ロールに基づいて管理権限を制限できることを保証するために、管理の委任を実装する必要
があります。これにより、セキュリティを改善し、環境内での不正な設定を減らすことができます。
主要なインフラストラクチャーコンポーネント（サーバー、データベース、サービスアカウントなどを含む）のすべてに関し
て、各コンポーネントのロールや機能、場所、所属を特定できるような、標準的な命名規則を定義する必要があります。
XD 5.x
XA 6.x
XD 5.x
XA 6.x
XD 5.x
XA 6.x
サーバーの命名スキームに関する詳細は、KB909264 - Active Directoryにおけるコンピューター、ドメイン、サイト、
OU向けの命名規則を参照してください。
22
ハードウェア
一般
カテゴリ
スケールアップ/ス
ケールアウト
ア ド レス 空 間レ イ ア
ウトに関する推奨
高可用性
ベストプラクティス
スケールアップ（サイトごとの仮想デスクトップ数/ユーザー数の増加）を行うか、それともスケールアウト（サイトの追加）
を行うかの判断は、利用可能なスペースの量、リスクに対する許容度、冷却/電源キャパシティ、保守費用、ハードウェ
ア費用、ホスティング費用などに基づいて行われます。具体的な要件を考慮する必要があるため、シトリックスは、一般
的にはスケールアップよりもスケールアウトを推奨します。
Address Space Layout Randomization（ASLR）は、システムコードとアプリケーションをメモリ内の別の場所にロード
することにより、バッファオーバーラン攻撃を防ぎます。詳細については、Microsoftブログの記事– Windows 7 および
Windows 2008 R2 SP1 による新しい仮想化イノベーションの追加を参照してください。
多くの組織が、ウィルス、マルウェア、その他のオペレーティングシステムの弱点を突いた攻撃などから、自社の
XenApp サーバーや仮想デスクトップを保護しようとしているため、デフォルト設定のまま ASLR を有効な状態に保つこ
とを推奨します。ASLR 機能は、Windows 2008、Windows 2008 R2、Windows Vista、Windows 7 に含まれていま
す。
単一サーバー障害が原因でリソース競合が引き起こされないようにするために、仮想化ホストの各グループには少なく
とも 1 台の追加ホスト（N+1）を含める必要があります。これにより、実務ワークロードに影響を与えることなく、定期的な
アップデートや保守を行う時間帯を計画できるようになります。
適用対象
XD 5.x
XA 6.x
XD 5.x
XA 6.x
XD 5.x
XA 6.x
仮想化ホスト用に選択されたハードウェアは、各種のビジネス要件（ディスク、電源、冷却、ストレージ、ネットワーク接
続を含む）を満たすために十分な内部冗長性を持つ必要があります。要件によっては、仮想化プールごとに異なるレベ
ルの冗長性を提供することが必要となる場合もあります。例えば、SLA によって、サーバーの機能停止時に複数のプー
ルが高レベルの性能を提供しなければならないと定めてある場合もあれば、短期間ならば劣化したサービス運用を許
容すると定めてある場合もあります。Citrix XenServer 用のリソースプール設計には、これらの要件を反映させる必要
があります。
CPU の オ ーバ ーコ
ミット
各サーバーロール（Web Interface、ゾーンデータコレクター、XenDesktop コントローラー、SQL Server など）向けに複
数の仮想マシンが存在する場合、それらのロールすべてが同一の物理仮想化ホスト上でホスティングされていないこと
を確認します。これにより、単一の仮想化ホストが故障した場合でもサービス停止が発生しないことを保証できます。ま
た、理想的には、コアインフラストラクチャーコンポーネントをサポートしている物理仮想化ホストを、それぞれ別の筺体
またはラック内に配置する必要があります。
仮想マシンのプロセッサ要件が、ホストの結合 CPU 処理キャパシティを超えないようにします。また、ホストの実効
CPU 利用率が、正常運用時に 80%を超えないようにします。ホストの CPU キャパシティが過負荷状態になると、個々
の仮想マシンの性能が低下します。さらに、ハイパーバイザー自体にリソース（1 コア、2GB RAM など）を割り当てるこ
とも重要です。
XD 5.x
XA 6.x
ほとんどの XenDesktop 配備環境では、CPU のオーバーコミット率として 4:1～8:1 間の値を採用しています。ただし、
一部の高性能仮想デスクトップでは、仮想デスクトップ 1 台につき複数の物理 CPU が必要となる場合もあります。実務
環境へ移行する前に、拡張的なスケーラビリティテストを実施して、適切な仮想-物理 CPU 率を特定する必要がありま
す。仮想デスクトップを実現する場合の初期仮想マシン用推奨値を下記の表に示します。
ユーザー種別
OS
vCPU
RAM
IOPS
（推定値）
コア当たりの
ユーザー数
（推定値）
Light（ライト）
Windows XP
1
1～1.5GB
3～5
10～12
Windows 7
1
1～1.5GB
5～10
8～10
Windows XP
1
1～1.5GB
6～10
7～9
Windows 7
2
1.5～2GB
10～20
5～7
Windows XP
2
2～4GB
20～40
2～4
Windows 7
2
4GB
25～50
2～4
Normal（ノーマル）
Heavy（ヘビー）
XD 5.x
詳細については、CTX127277 – ホステッドVMベースのリソース割り当てを参照してください。
24
XenApp サーバーに割り当てる vCPU の数が、指定のハードウェア内部にある論理コアの数を超えないようにします。
経験的には、CPU のオーバーコミットを行わないことにより、より高いレベルのスケーラビリティを実現できることが示さ
れています。XenApp サーバーを実現する場合の初期仮想マシン用推奨値を下記の表に示します。
ソケット
コア /ソケッ
ト
コア/サーバー
VM カ ウ
ント
VM 当 た り
の vCPU
XA 6.x
VM 当たりの
RAM
32 ビット版オペレーティングシステム（Windows 2003、Windows 2008）
2
2
4
2
2
4
2
4
8
2
4
4
4
4
16
4
4
4
64 ビット版オペレーティングシステム（Windows 2003、Windows 2008、Windows
2008 R2）
メ モ リ のオ ーバ ーコ
ミット/動的メモリ
2
2
4
2
2
8
2
4
8
2
4
16
4
4
16
4
4
16
詳細については、CTX129761 – XenApp仮想化に関するベストプラクティスを参照してください。
メモリのオーバーコミットを使用すると、各仮想化ホストがサポートできる仮想デスクトップの数を増やすことができま
す。メモリのオーバーコミットは、実行中の仮想マシンのメモリ量を、指定された最小値と最大値の間で自動的に調整し
ます。これにより、仮想マシンは、必要に応じて追加メモリの貸し借りすることが可能となります。メモリのオーバーコミッ
ト率が大きい場合、より多くのRAMをディスクへとページングすることが必要となるため、ユーザーエクスペリエンスが
低下します。多くの組織では、5～10%のオーバーコミット率で、ユーザーエクスペリエンスに影響を与えることなくメモリ
のオーバーコミットを実現しています。また、メモリのオーバーコミットを使用することでフォールトトレランスを実現できま
す。例えば、障害が発生した場合、メモリのオーバーコミットを行うならば、少ない台数のホストでより多くのデスクトップ
をホスティングできるようになります。これにより、パフォーマンスヒットが生じる場合もありますが、それが起こるのは障
害時のみです。詳細については、Citrixブログの記事– メモリのオーバーコミットに関するセーフプラクティスを参照してく
ださい。
XD 5.x
25
プール/クラスタの設
計
ネットワーク接続
複数のXenAppサーバー間でユーザーが動的に負荷分散されるため、サーバー間のメモリ使用率は同じレベルになり
ます。このため、動的メモリ割り当ての必要性がなくなります。また、仮想マシン移行戦略を使用する場合、メモリのオー
バーコミットを行うと、アグレッシブなページングが発生するため、すべてのXenApp仮想マシン間で性能が低下します。
このため、仮想XenAppサーバーのメモリ確保のために固定値を設定することを推奨します。詳細については、
CTX129761 – XenApp仮想化に関するベストプラクティスを参照してください。
XenApp サーバー、仮想デスクトップ、インフラストラクチャーサーバー用にそれぞれ独立した仮想化プールを作成する
と、負荷分散を簡素化でき ると同時に 、仮想 デスク ト ップが主要なイ ンフ ラストラクチャ ーロ ール（AD、SQL、
XenDesktop コントローラー、ゾーンデータコレクター）に影響を与えないことを保証できます。また、独立した仮想化
プールを使うと、デスクトップやサーバーの特定の要件に合わせて、ハイパーバイザーの高可用性機能を作成できま
す。例えば、仮想デスクトップで VM レベルの HA が必要ない場合、高可用性機能を有効にすることなく、デスクトップ
プール全体を構築できます。この結果、ハイパーバイザーのライセンスコストを大幅に引き下げることができます。
仮想化ホストのネットワークキングリソースは、同ホストがサポートする複数の仮想マシンにより共有されます。このた
め、十分な帯域幅が存在しない場合、ユーザーエクスペリエンスが低下します。このような不安を解決するために、シト
リックスは、高速なネットワークカードとスイッチ（1Gbps 以上）を使用することを推奨します。
XA 6.x
XD 5.x
XA 6.x
XD 5.x
XA 6.x
十分なインフラストラクチャーが存在する場合、複数の物理 NIC を介して各種のネットワークトラフィックを分離すること
により性能を改善できます。例えば、管理、仮想マシン、ストレージ、プロビジョニング、バックアップの各トラフィックを互
いに隔離できます。実際の構成は、配備環境の特性や、利用可能なネットワークカードの数に応じて異なります。利用
可能なネットワークカードの数に基づく XenServer 環境の推奨構成例を下記に示します。
NIC×2
•
NIC×2（ボンディング）– 管理、ストレージ、仮想マシン、プロビジョニング、バックアップ
NIC×4
•
NIC×2（ボンディング）– 管理、プロビジョニング、仮想マシン
•
NIC×2（ボンディング）– ストレージ（iSCSI/NFS）、バックアップ
NIC×6
•
NIC×2（ボンディング）– 管理、仮想マシン
•
NIC×2（ボンディング）– プロビジョニング
•
NIC×2（ボンディング）– ストレージ（iSCSI/NFS）、バックアップ
NIC×8
•
NIC×2（ボンディング）– 仮想マシン
26
電力節約オプション
ハイパースレッディン
グ
•
NIC×2（ボンディング）– 管理/高可用性
•
NIC×2（ボンディング）– ストレージ（iSCSI/NFS）、バックアップ
•
NIC×2（ボンディング）– プロビジョニング
上記の推奨構成は、複数の 100MB または 1Gbps 対応 NIC を搭載しているホストに固有のものです。10GB 対応の
ネットワークカードを搭載しているホストの場合、通常、VLAN を使用して、仮想マシン、プロビジョニング、バックアップ
の各トラフィックを分離します。ただし、Citrix XenServer の「管理」トラフィックは 802.1Q VLAN タグに対応していない
ため、デフォルトの VLAN を使用する必要があります。
HP Virtual Connect や Cisco UCS のようなテクノロジーの進化に伴い、複数の仮想化された NIC を構成し、最大
10GB の総帯域幅量から可変量の低域幅を割り当てることも可能となっています。この場合、仮想化された NIC は、通
常、完全な冗長性を持つため、ハイパーバイザーレイヤでの追加的な保護を必要としません。
電力節約機能は、CPU コアスピードを低下させることで消費電力を削減するものであり、仮想ゲストの性能に悪影響を
及ぼします。このため、サーバーの BIOS 内部の電力節約機能（HP サーバーの Dynamic Power Savings Mode な
ど）は無効にしてください。
ハイパースレッディングはインテル社が開発したテクノロジーであり、単一の物理プロセッサをあたかも 2 台の論理プロ
セッサであるように見せかける技術です。ハイパースレッディングを使うと、VM 当たりのユーザー密度を増加すること
（XenApp のみ）、またはホスト当たりの VM 密度を増加すること（XenApp および XenDesktop）によってワークロード
性能を改善できる可能性があります。それ以外のタイプのワークロードに関しては、ハイパースレッディングを使用した
場合と使用しない場合のワークロード性能を比較検証する必要があります。また、ハイパースレッディングの有効化は、
ベンダー固有のハイパーバイザーの調整と組み合わせて実施する必要があります。ハイパースレッディングのメリットを
評価する場合、新世代のサーバーハードウェアとプロセッサ（Nehalem+など）に加えて、最新バージョンのハイパーバ
イザーを使用することを強く推奨します。ハイパースレッディングを使用すると、通常、20～30%性能をアップできます。
XD 5.x
XA 6.x
XD 5.x
XA 6.x
27
汎用ストレージ
ストレージインフラストラクチャーは、すべての仮想デスクトップ環境における重要なコンポーネントであり、適切に設計
されていない場合、安定性や性能に関して重大な問題を引き起こすことがあります。ストレージに関する主要なベストプ
ラクティスを以下に示します。
•
ストレージデバイス/アプライアンスは、完全冗長方式でセットアップすること。これは、すべてのコンポーネント
（ネットワークポートおよびリンク、ストレージコントローラー、電源アダプタ、RAID コントローラーなど）がフォー
ルトトレラントであることを意味します。
•
ファイバチャネルや iSCSI 経由でアクセスされる LUN では、20～30 台を超える数の仮想マシン向けのディス
クをホスティングしないこと。これは、SCSI 予約や SCSI キューイングなどにより引き起こされる読み書きレイ
テンシを防ぐためです。
•
高い I/O フットプリントを伴うワークロード（大規模データベースシステムなど）を、同一のディスクスピンドルセッ
ト上でホスティングしないこと。
•
すべてのレイヤ（仮想マシン、ハイパーバイザー、ストレージ）のファイルシステムを完全に揃えること。
XD 5.x
詳細については以下の記事を参照してください。
•
CTX118397 – ストレージテクノロジー入門
•
CTX130632 – ストレージ関連のベストプラクティス
•
Citrix ブログの記事 – LUN のサイジングに関する Citrix の見解
28
Citrix XenServer
カテゴリ
構成の最大値
ベストプラクティス
XenServer 配備が、指定されている設定の限界を超えないようにします。重要な構成に関する最大値としては以下の
ものがあります（本書の執筆時点で有効な値）。
•
ホスト当たりの同時汎用 VM の数: 75
•
ホスト（2940MB dom0 RAM）当たりの同時仮想デスクトップ VM の数: 75～130*
•
ホスト（2940MB dom0 RAM）当たりの同時仮想デスクトップ VM（IntelliCache を使用）の数: 50～130*
•
ホスト（HA 有効）当たりの同時保護 VM の数: 50～60*
•
プール当たりのホスト数: 16
適用対象
XD 5.x
XA 6.x
+
* 下限値は、システムが完全にサポートされる数を表しています。下限値と上限値の範囲内にある値は、仮想マシンの
ワークロード、システム負荷、特定の環境要因などに応じた条件付きでシステムが正常に機能できる数を表していま
す。システムが正常に機能できる範囲の上限値に影響を与える特定の環境要因が何であるかを決定する権利はシト
リックスにあります。
+ シトリックスは XenServer リソースプール当たり最大 16 台の仮想化ホストをサポートしますが、経験的には、
Machine Creation Services を使用するリソースプールのホスト数を 8 台に制限し、Provisioning Services を使用する
リソースプールのホスト数を 12 台に制限すると最も良い結果が出ることが実証されています。
詳細については、CTX131047 - XenServer 6.0 構成の限界値を参照してください。
XenApp 向 け の 最
適化
制御ドメインのス
ケーラビリティ
受信側コピー
注: これらの構成に関する最大値は理論値であり、環境の特性に応じて変わる場合があります。
Nehalem より前のプロセッサを使用するシステムでは、XenServer 設定で「Optimize for XenApp」機能を有効にする
ことでスケーラビリティを改善できました。Nehalem プロセッサのリリース以降、この機能はハードウェアレイヤ（Intel
EPT/AMD RVI）で提供されるようになりました。このため、最新のプロセッサを使用するホストでは、XenServer 設定で
「Optimize for XenApp」機能を有効にしないでください。
XenServer 5.6 Feature Pack 1 以降では、XenServer制御ドメイン（Dom0）は複数のコア（デフォルトで 4 つ）を利用で
きるため、制御ドメインとリソースプールのスケーラビリティを大幅に改善できます。通常、多数の仮想マシンから構成さ
れているXenDesktop配備では制御ドメインの負荷が高くなるため、XenServer 5.6 Feature Pack 1 以降を使用する
必要があります。詳細については、Citrixブログの記事– XenServerの調整により最大のスケーラビリティを実現を参照
してください。
XenServer 6.0 以降、XenServer 制御ドメイン（Dom0）は、ネットワークトラフィック処理タスクを、仮想ゲストに対してオ
XA 6.x
XD 5.x
XD 5.x
29
（Receive-Side
Copy）
フローディングできるようになりました。これにより、Dom0 の vCPU リソースを解放できますが、その一方で VM レベル
のネットワークスループットの最大値は低下することになります。このため、シトリックスは以下のことを推奨します。
•
各ホスト上で多数の小規模仮想マシン（仮想デスクトップなど）を仮想化する場合は、Receive-Side Copy
（RSC）機能を有効なままにしておくこと。
•
少数の強力な（最大のネットワークスループットを必要とする）仮想マシン（Provisioning Server など）を仮想化
する場合は、Receive-Side Copy（RSC）機能を無効化すること。以下のレジストリキーを使用することにより、
仮想ゲスト単位で RSC 機能を無効化できます。
HKLM\SYSTEM\CurrentControlSet\services\xenvif\Parameters
 “ReceiverMaximumProtocol” = 0（DWORD）
障害の発生時に、プールマスターロールをホスト間で自動的に移動するには、XenServer HA を有効にする必要があり
ます。
XA 6.x
o
VM 高可用性
XenDesktop ホスト
接続
2 つのホストからなるリソースプールでは、ネットワーク障害の発生時にホストフェンシングの可能性を回避するために、
管理およびストレージ通信が別々の物理ネットワークを使用する必要があります。これが実現されない場合、3 つのホ
ストからなるプールが必要となります。詳細については、CTX119717 – XenServerの高可用性を参照してください。
プールされている仮想デスクトップは、自動的にリスタートするように設定しないでください。そのように設定した場合、
XenDesktop により発行される電源操作コマンドと衝突します。
ユーザーをサポートするために十分なリソースが利用できるように、XenApp サーバーの高可用性優先順位を「Restart
if Possible」に設定する必要があります。
XenServer プールマスターホストが利用不可になった場合、XenDesktop コントローラーは、影響を受けるプール内に
ある仮想マシンの電源状態を管理できなくなります。この典型的な副作用として、デスクトップグループでは利用可能な
電源がオンのデスクトップが不足し、新規ユーザーが接続できなく なります。このシナリオを回避するには、各
XenServer リソースプールで高可用性を有効化し、新しいプールマスターが自動的に選ばれるようにします。各プール
メンバーは、HTTP リダイレクトを通じて、プール管理要求をプールマスターへとリダイレクトできます。このため、
XenDesktop が各プール内の複数の XenServer ホストと通信できるように設定されていることを確認します。プールマ
スターが利用不可になった場合、同プールで高可用性が有効になっていないならば、各プール内で複数の XenServer
ホストを設定しても効果はありません。
XD 5.x
XA 6.x
XD 5.x
XA 6.x
XD 5.x
30
Microsoft Hyper-V
カテゴリ
構成の最大値
ベストプラクティス
Hyper-V/System Center Virtual Machine Manager（SCVMM）インフラストラクチャーが、Microsoft により指定された
構成の最大値を超えないようにします。重要な構成に関する最大値としては以下のものがあります（本書の執筆時点で
有効な値）。
•
ホスト当たりの同時 VM 数: 384
•
クラスタ当たりの同時 VM 数: 1000
•
クラスタ当たりのホスト数: 16
•
論理プロセッサ当たりの最大 vCPU 数: 12:1（Windows 7 ゲストのみの場合）/8:1（それ以外）
•
SCVMM Server 当たりのホスト数: 400*
•
SCVMM Server 当たりの稼働 VM 数: 8000
適用対象
XD 5.x
XA 6.x
* 150 台を超える Hyper-V ホストを含む SCVMM 実装の場合、Microsoft は、サーバー向けに最適化されたガベージ
コレクターを有効にすることを強く推奨しています（詳細については下記のベストプラクティスを参照のこと）。
詳細については以下の記事を参照してください。
SCVMM の最適化
•
Microsoft TechNet - Windows Server 2008 R2 における仮想マシンと Hyper-V に関する要件および制限
•
Microsoft TechNet - SCVMM でサポートされている構成
注: これらの構成に関する最大値は理論値であり、環境の特性に応じて変わる場合があります。
以下のレジストリ値を実装することにより、SCVMM を VDI 向けに最適化する必要があります。
•
XD 5.x
HKLM\SOFTWARE\Microsoft\Microsoft System Center Virtual Machine Manager Server\Settings
o
“VMUpdateInterval” = 7200（DWORD）
o
“HostUpdateInterval” = 7200（DWORD）
o
“VMPropertiesUpdateInterval” = 1800（DWORD）
o
“VHDMountTimeoutSeconds” = 3600（DWORD）

同じベースディスクを使って多数の VM を並列して作成する場合、1800（DWORD）に設定しま
す。
31
•
HKLM\SOFTWARE\Microsoft\Microsoft System Center Virtual Machine Manager
Server\Settings\Sql\TaskGC
o
•
“TaskGC” = 7（DWORD）
HKLM\SOFTWARE\Microsoft\Microsoft System Center Virtual Machine Manager
Server\Settings\IndigoSendTimeout
o
VHDMountTimeoutSeconds = 300（DWORD）
VMM サ ー バ ー 上 で 、 サ ー バ ー 向 け に 最 適 化 さ れ た ガ ベ ー ジ コ レ ク タ ー （ GC ） を 有 効 に す る に は 、
vmmservice.exe.config と い う 名 前 の フ ァ イ ル を 作 成 し 、 同 フ ァ イ ル を VMM サ ー バ ー 上 の デ ィ レ ク ト リ
「%SYSTEMDRIVE%\Program Files\Microsoft System Center Virtual Machine Manager 2008 R2\Bin」に配置し
ます。このファイルの内容は以下の通りです。
<configuration>
<runtime>
<gcServer enabled="true"/>
</runtime>
</configuration>
詳細については、Microsoftブログの記事 – VDI配備向けにSCVMMを調整するにはを参照してください。
SCVMM 2008 の高
可用性
SCVMM 2008 はHA構成をサポートしていないため、Hyper-Vベースの環境では、複数のSCVMMインスタンスを構成
し、それに合わせてハイパーバイザーの管理を分割する必要があります。詳細については、Microsoft TechNet – 高可
用性に関するプランニングを参照してください。
XD 5.x
XA 6.x
32
Windows での電源
計画
各 Hyper-V サーバー上で電源計画として「High Performance」を有効にすると、プロセッサが最高の性能状態で稼働
することを保証できます。リソースを多用するワークロード（Hyper-V）の場合、デフォルトの電源計画である「Balanced」
のままだと性能の問題が発生し、タスクの平均応答時間が増加します。
XD 5.x
XA 6.x
電源計画を変更するには、以下の手順を実行します。
1. [Start]→[Control Panel]をクリックします。
2. [Control Panel]の下に表示されるメニュー項目リストから[Power Options]を選択すると、[Select a power
plan]ページが表示されます。[Power Options]メニューが表示されない場合、[Search Control Panel]ボック
スに「power」とタイプした後、[Chose a power plan]を選択します。
3. デフォルトでは、電源計画を変更するオプションは無効になっています。これを有効にするには、[Change
settings that are currently unavailable]というリンクをクリックします。
4. [High Performance]オプションを選択します。
5. [Power Option]ウィンドウを閉じます。
詳細については、Microsoft Knowledge Baseの記事KB2207548 - Windows Server 2008 R2 上の全体的な性能の
低下を参照してください。
仮想ディスクフォー
マット
統合 NIC
（Synthetic NIC）
すべてのHyper-Vベースの仮想マシンでは、固定サイズの仮想ハードディスク（VHD）を使用する必要があります。これ
は、固定サイズのVHDは、動的に拡張可能なVHDよりも書き込み性能が大幅に優れているためです。詳細について
は、Microsoftのホワイトペーパー - 仮想ハードディスクの性能を参照してください。
Hyper-V は、VM 向けに特別に設計された統合ネットワークアダプタをフィーチャーしています。統合ネットワークアダプ
タは、既存のハードウェアの振りをするエミュレート型のネットワークアダプタと比べた場合、ネットワーク I/O における
CPU オーバーヘッドを大幅に削減できます。統合ネットワークアダプタは、VMBus を通じて子パーティションと root
パーティション間の通信を行う場合に、共有メモリを使用することで、より効率的なデータ転送を実現しています。このた
め、可能ならば常に、レガシーNIC ではなく統合 NIC を利用することを推奨します。
XD 5.x
XA 6.x
XD 5.x
XA 6.x
統合 NIC は PXE ブートをサポートしていないことに注意してください。PXE ブートは、Provisioning Services のター
ゲットデバイスで必要となります。
詳細については以下の文書を参照してください。
•
Microsoft MSDN - チェックリスト: Hyper-V 上での性能の最適化
•
CTX128750 - 新しい Provisioning Services ターゲット上での Hyper-V 統合 NIC の再初期化
•
CTX124687 - XenDesktop と Microsoft Hyper-V: 設計ガイド
33
状態保存ファイル
Hyper-V の管理
Microsoft Hyper-Vは、各仮想マシン向けの状態保存ファイルを、仮想マシン設定ファイルと同じ場所に自動的に作成
します。この状態保存ファイルは拡張子.BINを持ち、そのサイズは、仮想マシンのブート時に同仮想マシンに割り当て
られるメモリ量に等しくなります。静的メモリ割り当ての場合、ディスク上の同ファイルのサイズは変化しません。一方、
動的メモリ割り当ての場合、同ファイルの初期サイズは動的メモリの最小割り当てサイズに等しくなり、その後、仮想マ
シンに割り当てられるメモリ量の増加に合わせて同ファイルのサイズも大きくなります。このため、ストレージ容量に関
するプランニングを行う場合、すべての仮想マシン用の動的メモリの最大サイズを含めるのに十分な空き容量がスト
レージにあることを確認する必要があります。詳細については、CTX124687 - XenDesktopとMicrosoft Hyper-V: 設計
ガイドを参照してください。
SCVMM の実装後に、Hyper-V Manager および Cluster Manager の各管理ツールを使用しないでください。これらを
使用すると、SCVMM データベース内で不整合が発生する場合があります。
XD 5.x
XA 6.x
XD 5.x
XS 6.x
34
VMware vSphere
カテゴリ
構成の最大値
ベストプラクティス
vSphere 配備が、指定された構成に関する最大値を超えないようします。重要な構成に関する最大値としては以下の
ものがあります（本書の執筆時点で有効な値）。
•
ホスト当たりの同時 VM 数: 512
•
クラスタ当たりの同時 VM 数: 3000
•
クラスタ当たりのホスト数: 32
•
vCenter Server 当たりのホスト数: 1000
•
vCenter Server 当たりの稼働 VM 数: 10000
•
vCenter 当たりの同時 vSphere クライアント数: 100
適用対象
XD 5.x
XA 6.x
詳細については以下の VMware ドキュメントを参照してください。
ハイパースレッディン
グ
•
VMware vSphere Configurations Maximums for vSphere 4.1
•
VMware vSphere Configurations Maximums for vSphere 5.0
•
VMware vCenter 4.1 Server Performance and Best Practices
•
vCenter Server 5.x and vSphere Client Hardware Requirements.
注: これらの構成に関する最大値は理論値であり、環境の特性に応じて変わる場合があります。
以下の条件を満たすように、HaltingIdleMsecPenalty パラメータの値をホスト上で調整する必要があります。これによ
り、いったん脱落した vCPU が再び追いつくことが可能となります。
•
CPU 使用率が 50%を超えていること
•
vCPU の数 = pCPU の数±25%
•
バースト的な CPU 使用パターンが存在すること
XD 5.x
XA 6.x
詳細については、VMware Knowledgebaseの記事KB1020233 - vSphereの公平性/スループットのバランスを変更す
る場合のガイドラインを参照してください。
35
vCenter
VMware vCenterは、XenDesktop環境における重要なコンポーネントです。vCenterの中心的な役割は、XenDesktop
とvSphere間のすべての通信を管理することです。各VMware vSphereサーバークラスタはvCenterを使用してクラス
タ管理やその他のホスティングインフラストラクチャータスクを実行するため、vCenterサーバーが高ストレス状態になり
処理速度の低下や利用不可状態になると、デスクトップの配信が妨げられます。Virtual Center 5.0 のインストールに
関するベストプラクティスについては、Knowledge Baseの記事2003790を参照してください。推奨事項の詳細について
は、VMware vSphere 5.0 の性能に関するベストプラクティス – ホワイトペーパーを参照してください。
XD 5.x
XA 6.x
Citrix Consulting は、すべての XenDesktop および XenApp 環境において vCenter サーバーの高可用性を実現する
ことを推奨します。vCenter サーバーが利用不可になった場合、現在の XenDesktop 接続は影響を受けませんが、管
理者は vSphere クラスタ設定の変更や管理が行えなくなります。vCenter の高可用性を実現するには、vCenter サー
バーを稼働している vSphere ホストを VMware HA クラスタ内に配置します。vCenter サーバーをサポートしているホ
ストが故障した場合、vCenter サーバーは同クラスタ内の別のホスト上でリスタートされます。これを実現するために
は、vCenter の起動優先順位をデフォルト値の「medium」から「high」へと変更する必要があります。また、vCenter
サーバーが依存しているその他のサービス（vCenter データストアをホスティングしている Active Directory、 DNS、
SQL サーバーなど）の起動優先順位も「high」に設定されていることを確認してください。
ネットワークアダプタ
ネットワークスループットを改善し、CPU利用率を引き下げるために、VMXNet3 ネットワークアダプタを選択します。詳
細につい ては、VMware提供の記事KB001805 - 自分の仮想マシ ンに合ったネットワークアダ プタの選択 およ
びVMXNET3 仮想ネットワークデバイスに関する性能評価を参照してください。
XD 5.x
XA 6.x
注: VMXNet3 ドライバを使用しているWindows 7、Windows Vista、Windows 2008、Windows 2008 R2 の各オペ
レーティングシステムイメージをProvisioning Services仮想ディスクとして作成する場合、マスターイメージ以外の仮想
ディスクからはターゲットデバイスをブートできないことに注意してください。この場合、ターゲットデバイスはブートに失
敗し、「STOP 7B」エラーでブルースクリーンが表示されます。詳細についてはCTX125361 – VMXNet3 ドライバを使う
とターゲットデバイスの起動に失敗するを参照してください。
SCSI アダプタ
透過的なページ共有
（Transparent
Page Sharing）
また、VMXNet3 ドライバを使用するターゲットデバイスのクラッシュを防ぐには、ホットフィックスCPVS56SP1E011を
Provisioning Services 5.1 および 5.6 環境に適用する必要があります。
I/Oフットプリントが大きい仮想マシン（データベースサーバーやProvisioning Serverなど）では、デフォルトのSCSIアダ
プタではなく、Paravirtual SCSIアダプタを使用するように設定する必要があります。詳細については、VMware
Knowledgebaseの記事KB1010398 - VMware Paravirtual SCSI（PVSCSI）アダプタを使うようにディスクを構成を参
照してください。
透過的なページ共有（Transparent Page Sharing: TPS）の有効化/無効化が、新しいシステム（Windows 2008、
Windows 2008 R2、Windows Vista、Windows 7）上での性能にどう影響するかについては示されていません。ただ
し、旧システム（Windows 2003 や Windows XP）上で TPS を有効化すると、ページサイズが４K に縮小され、メモリ
ページの共有が容易になるため、性能がアップします。TPS を有効化する場合、効率性をアップするには、Windows
Address Space Layout Randomization（ASLR）をオンにする必要があります。
XD 5.x
XA 6.x
XD 5.x
XA 6.x
36
ホットスワッピング
ほとんどの環境では、すべての XenApp サーバー/仮想デスクトップが同時に複数のユーザーをアクティブにホスティン
グしています。ある XenApp ホスト/仮想デスクトップからメモリをスワップアウトすると、メモリとディスク間での転送が絶
えず発生するため、すべての仮想マシンで性能が低下することになります。このため、典型的な XenApp/XenDesktop
の利用パターンに基づいて、仮想マシンで十分な物理メモリリソースが利用可能であることを保証することにより、ホット
スワップを回避する必要があります。
XD 5.x
XA 6.x
注: ホットスワップを回避できない場合、スワップキャッシュ用にソリッドステートドライブ（SSD）を導入することを検討し
てください。詳細については、VMware Knowledgebase Technical Paper – VMware vSphere 5.0 の性能に関する新
機能を参照してください。
37
デスクトップ
一般
カテゴリ
複数のイ メージ プロ
ビジョニングソリュー
ション
ベストプラクティス
可能な場合、Provisioning ServicesまたはMachine Creation Servicesのいずれかを使用して（両方は不可）、複雑さ
を低下させます。詳細については、CTX128543 – XenDesktopプランニングガイド: デスクトップイメージデリバリーを
参照してください。
適用対象
XD 5.x
仮 想 デ ス ク ト ップ の
公開
仮想デスクトップは、個々のユーザーアカウントではなく、グループに基づいて割り当てる必要があります。これ
は、Microsoft AGDLP（Account、Global、Domain Local、Permission）の原則に従うものです。
XD 5.x
一般的なデスクトップ
最適化
仮想デスクトップや XenApp アプリケーションサーバーのオペレーティングシステムを最適化することにより、IOPS 要
件の引き下げ、性能の改善、ログオン時間の短縮を実現する必要があります。詳細については、以下の Citrix
Knowledgebase の記事を参照してください。
XD 5.x
アンチウィルス設定
CTX124239 – Windows XP最適化ガイド
CTX127050 – Windows 7 最適化ガイド
CTX131577 – XenApp 6.x最適化ガイド
アンチウィルスソフトウェアを設定する場合、性能とセキュリティの間で適切なバランスを取ることが必要です。ガイドラ
インとして、以下の推奨事項の実装を検討してください。
•
書き込みイベント発生時やファイルが変更された場合にスキャンを実行します。通常、このような設定は、ほと
んどのアンチウィルスベンダーによって高いセキュリティリスクとして認識されていることに注意してください。高
セキュリティ環境では、メモリをターゲットとする脅威（Conficker の変種など）を防ぐために、読み取りおよび書
き込みの両イベントの発生時にスキャンを実行することを検討してください。
•
ローカルドライブのみをスキャンし、ネットワークスキャンを無効にします。この場合、すべてのリモートロケー
ション（ユーザープロファイルやリダイレクトされるフォルダをホスティングしているファイルサーバーを含む）は、
アンチウィルスソリューションおよびデータ整合性ソリューションによって監視されているものとします。
•
ページファイルをスキャン対象から除外します。
•
Print Spooler ディレクトリをスキャン対象から除外します。
•
頻繁にアクセスや変更が行われる\Program Files\Citrix ディレクトリ内のファイルやフォルダをスキャン対象か
ら除外します。
XA 6.x
XA 6.x
XA 6.x
XD 5.x
XA 6.x
38
スケジュール化され
たタスク
CPU リソース割り当
て
HDX モニタ
ブートストーム
ディスクアラインメン
ト
•
不 要 な ア ン チ ウ ィ ル ス 関 係 の エ ン ト リ を Run キ ー （ HKLM\Software\Microsoft\Windows\Current
Version\Run）から削除します。
•
XenDesktop や共有ホステッドデスクトップシナリオなどでパススルー認証を使用する場合、XenApp のオンラ
インプラグインビットマップ用キャッシュディレクトリ（通常、%AppData%\ICAClient\Cache）をスキャン対象か
ら除外します。
•
シトリックスのプロファイル管理でストリーミング型ユーザープロファイル機能を使用する場合、アンチウィルス
ソリューションが Hierarchical Storage Manager（HSM）ドライバを認識できるよう設定されていることを確認し
ます。
詳細については、CTX127030 – アンチウィルスソフトウェア構成に関するCitrixガイドラインを参照してください。
スケジュール化されたタスクを使用して、仮想デスクトップ、XenApp サーバー、サポートしているインフラストラクチャー
上での保守作業を実行する場合があります。スケジュール化されたタスクの使用は、性能が低下する時間帯を発生さ
せる可能性があります。このため、理想的には、スケジュール化されたタスクは業務時間外に実行する必要がありま
す。また、中央インフラストラクチャー（ストレージ、ネットワーク、データベース）の性能に与える影響を軽減するために
は、スケジュール化されたタスクの実行をランダム化する必要があります。
多くのユーザーのリソース要件を満たすためには、仮想デスクトップ当たり 1 台の vCPU で十分です。ただし、グラ
フィックスを多用する HDX 機能（RealTime、3D、RichGraphics など）では、2 台目の vCPU が必要となる場合があり
ます。
スマートカード、USBデバイス、ネットワーク性能などの問題のトラブルシューティング手順を簡素化するために、すべて
の仮想デスクトップおよびXenAppサーバー上にHDX Monitorツールをインストールする必要があります。本ツールを
使用することでリソースオーバーヘッドが発生するため、同ツールへのアクセスをサポートスタッフのみに制限する必要
があります。
複数の仮想デスクトップの同時起動は、特にストレージサブシステムにとってリソースを多用するプロセスとなるため、
性能が低下する時間帯を発生させる可能性が高くなります。この不安を解消するためには、営業日の開始前に仮想デ
スクトップのブートプロセスを完了しておく必要があります。また、仮想デスクトップのブートプロセスを調整することによ
り、環境で発生する負荷を軽減する必要があります。
Windows 2003 とWindows XPのインストールはデフォルトでは正しくアラインメントが行われないため、ストレージ性能
に影響を与える場合があります。このため、これらのオペレーティングシステムをインストールする前に、アラインメント
を修復する必要があります。詳細については、Microsoft Knowledgebaseの記事KB929491 – “Windows Server
2003、Windows XP、Windows 2000 で複数のディスクを使用する場合予想よりもディスク性能が低下する問題” か、
NetApp white paper TR3747 – “仮想環境でのファイルシステムのアラインメントに関するベストプラクティス”を参照し
てください。
XD 5.x
XA 6.x
XD 5.x
XD 5.x
XA 6.x
XD 5.x
XD 5.x
XA 6.x
39
Machine Creation Services（MCS）
カテゴリ
ストレージプロトコル
IntelliCache
ベストプラクティス
NFS は、Machine Creation Services 向けの推奨ストレージソリューションとなります。これは、NFS がシンプロビジョ
ニングを提供することにより、0KB リンクの作成や、オンデマンドでサイズが増加するスナップショットを可能にするため
です。この機能を使うと、ストレージ要件を大幅に引き下げると同時に、新規マシンの作成にかかる時間を最小化でき
ます（完全コピーではなく 0KB のスナップショットを作成するだけであるため）。また、NFS を使うと、SCSI ロックや
SCSI キューイング関連の性能問題を引き起こすことなく、多くの仮想マシンからの同時アクセスが可能となる大規模な
ストレージリポジトリを作成できます。これにより、XenDesktop インフラストラクチャーのプランニングや管理を簡素化で
きます。
IntelliCacheはXenServerの機能であり、MCSベースのデスクトップワークロード向けの一時ファイルや非永続ファイル
を、ホストサーバーのローカルディスク上にキャッシュします。IntelliCacheを使うと、仮想マシンのラインタイム読み取り
および書き込みの一部が、高価な共有ストレージ上ではなく、低コストのローカルストレージ上で発生するようになりま
す。このため、IntelliCacheの導入により、共有ストレージの要件を引き下げることができます。ローカルディスクサブシ
ステムには、IntelliCacheの追加的なIOPS要件を満たすために十分なリソースを提供する必要があります。これを行
わない場合、ユーザーエクスペリエンスや安定性の問題が発生することになります。詳細については、CTX129052 XenDesktopでIntelliCacheを使用するにはを参照してください。
適用対象
XD 5.x
XD 5.x
40
Provisioning Services
カテゴリ
Provisioning
Services – ス ケ ー
ルアップ/スケールア
ウト
分散ファーム
vDisk のタイプ
ベストプラクティス
スケールアップ（単一ホストに対するより多くの追加）を行うか、それともスケールアウト（ホストの追加）を行うかの判断
は、リスクやフェイルオーバー時間に対する許容度に基づいて行われます。これは、単一の Provisioning Server によ
り多くのターゲットデバイスが接続するほど、Provisioning Server 間のフェイルオーバーにより長い時間がかかること
になるためです。シトリックスの内部テストでは、ターゲットデバイス数が 1500 の場合、フェイルオーバー時間は約 8 分
であることが特定されています。
Provisioning Services ファームは複数のデータセンターにまたがることができますが、高い性能と高可用性を実現する
ために、各ファームは物理ロケーションごとに別々に作成する必要があります。
適用対象
XD 5.x
Provisioning Services は静的 vDisk および動的 vDisk の使用をサポートします。動的 vDisk は、必要とするストレー
ジスペースが少なくて済むため、vDisk のアップデート、配布、バックアップにかかる時間を短縮できます。どちらのタイ
プの vDisk を選択した場合でも、vDisk の大部分はメモリ内にキャッシュされるため、十分な量のメモリを搭載している
ならば Provisioning Services のターゲットデバイスや Provisioning Server の性能には影響しません。このため、標準
イメージ（読み取り専用）を使用する場合は、動的 vDisk の使用を推奨します。
XD 5.x
XA 6.x
XD 5.x
XA 6.x
XA 6.x
注: 動的 vDisk では、固定サイズの vDisk よりも書き込み性能が大幅に低くなります。このことは正常運用時の性能に
は影響しませんが、vDisk のマージ操作にかかる時間が長くなります。
vDisk の数
プライベートイメージ（読み取り/書き込み）の場合には、動的vDiskではなく固定サイズのvDiskを使用します。その方が
高い書き込み性能を実現できるためです。詳細については、Microsoft White Paper - 仮想ハードディスクの性能を参
照してください。
vDisk の保守にかかる管理オーバーヘッドを縮小するには、配備済みの vDisk の数を最小に保つ必要があります。
XD 5.x
XA 6.x
差分ディスク のマー
ジ
PVS 6.0 以降は、vDisk のバージョニングにより vDisk のアップデートや管理タスクを簡素化することで、より柔軟で堅
牢なアプローチにより vDisk を管理できます。1 つの vDisk は、VHD ベースのイメージファイル、任意の関連付けられ
ているサイドカーファイル、参照される VHD 差分ディスクのチェーン（適用可能な場合）から構成されます。差分ディス
クは、オリジナルのベースディスクイメージを元のままの状態に保ちつつ、ベースディスクイメージに対して行われた変
更を捕捉するために作成されるものです。1 つのベースディスクに関連付けられている個々の差分ディスクは、それぞ
れ異なるバージョンを表しています。
XD 5.x
XA 6.x
最適な性能を実現するには、VHD チェーンの数を最小に保つ必要があります（最大で 5～7）。個々の追加 AVHD
（ベース VHD ファイルのスナップショット）による全体的な IOPS オーバーヘッドの増加が引き起こす影響を制限するに
41
は、以下の推奨事項に従います。
•
vDisk の格納場所
書き込みキャッシュ
の宛先（Write
Cache
Destination）
vDisk をアップデートする場合、テスト AVHD を維持すること。これにより、テスト結果に基づいて変更のロール
バックが行えるようにします。
•
UAT/パイロット環境に移行する前に、AVHD をマージすること。これにより、ターゲットが参照する AVHD ファ
イルの数を減らし、ストレージ用のフットプリントを縮小できます。
•
アップデートが受け入れられたら、ベースとのマージを行うこと。これにより、単一の VHD をすべての実務ター
ゲットへと配信し、新しいベースをアーカイブ化できます。
vDisks を CIFS/SMB ネットワークシェア上に格納すると、必要となる vDisk コピーの数を減らせるため、vDisk 管理を
簡素化できます。Provisioning Server 上でメモリキャッシングを効果的に利用するには、以下の条件を満たす必要が
あります。
•
ネットワークシェアが完全な冗長構成を持ち、環境の要求を処理するために十分な性能を提供できること。
•
ネットワークシェア（またはタイプするファイルサーバー）が監視されており、機能停止やリソース不足を予見で
きること。
•
ネットワークシェアをホスティングしているファイルサーバーと Provisioning Server の両者が、SMB 2.x プロト
コルを使用できるように設定されていること。
•
すべての Provisioning Server 上で、以下の RegKey が設定されていること（下記の例は、W2K8R2 用の
RegKey）。
o
HKLM\SYSTEM\CurrentControlSet\services\LanmanWorkstation\Parameters
“EnableOplocks” = dword:0×00000001
o
HKLM\SYSTEM\CurrentControlSet\services\mrxsmb\Parameters
“OplocksDisabled” = dword:0×00000000
“CscEnabled” = dword:0×00000001
o
HKLM\SYSTEM\CurrentControlSet\services\LanmanServer\Parameters
“autodisconnect” = dword:0x0000ffff
“Smb2″ = dword:0×00000001
詳細については、Citrixブログの記事 – Provisioning ServicesとCIFSストアを参照してください。
プロビジョニング済みの仮想マシンのキャッシュファイルを格納する場合、以下の 5 つのオプションのいずれかを選択
できます。
•
XD 5.x
XA 6.x
XD 5.x
XA 6.x
Cache on Device HD（デバイス HD 上のキャッシュ）
42
ファイ ル/フォルダ を
永続的な書き込み
キャッシュドライブに
リダイレクトする
•
Cache on Device Hard Drive Persisted（永続的ハードドライブ上のキャッシュ）
•
Cache in Device RAM（デバイス RAM 内のキャッシュ）
•
Cache on a Server Disk（サーバーディスク上のキャッシュ）
•
Cache on Server Persisted（永続的サーバー上のキャッシュ）
ほとんどのXenDesktopおよびXenAppの実装では、「Cache on Device HD」を使用することを推奨します。これを使う
と、高価なRAMを消費することなく高速な性能を実現できるためです。「Cache on Server」は最も安価で実装しやすい
オプションですが、Provisioning Serverのスケーラビリティを大幅に低下させるため、同オプションは使用しないでくださ
い。また、書き込みキャッシュファイルを格納するためには、高可用性を持つネットワークシェアを実装する必要があり
ます。これを行わない場合、Provisioning Serverが単一障害点となってしまいます。詳細については、Citrix eDocs 標準vDiskイメージのキャッシュの書き込み先の選択を参照してください。
共有イメージを使用する場合、書き込みキャッシュファイルはリブート時に削除されるため、すべての変更がリセットされ
ます。リブート後にも重要な変更を保存し、かつ性能を改善するためには、以下のファイルやフォルダを書き込みキャッ
シュドライブへとリダイレクトすることを検討してください。
•
Windows のページファイル（PVS により自動的にリダイレクトされる）
•
Windows のイベントログ
•
Citrix のログ
•
アンチウィルスソフトウェアのパターンファイル
•
Microsoft App-V / Citrix Application Streaming のキャッシュ
•
Citrix EdgeSight データベース
XD 5.x
XA 6.x
重要: 書き込みキャッシュドライブに直接書き出されるファイルやフォルダは、ターゲットデバイスをリブートしても消去さ
れません。これにより、追加的な管理オーバーヘッドが引き起こされる場合があります。
43
オフラインデータベー
スのサポート
（Offline Database
Support）
「オフラインデータベースサポート」オプションは、Provisioning Services データベースへの接続が失われた場合に
Provisioning Server が同データベースのスナップショットを使えるようにします。このオプションはデフォルトで無効化さ
れているため、実務環境で安定して稼働しているファームでのみ有効化することを推奨します。評価環境で実行してい
る場合や、ファームコンポーネントを「オンザフライ」で再設定している場合には、本オプションを有効にしないでくださ
い。
XD 5.x
XA 6.x
データベースのスナップショットは、サーバー起動時に作成され初期化された後、ストリームプロセスにより継続的に
アップデートされます。データベースが利用不可になると、ストリームプロセスはスナップショットを使用して、サーバーで
利用可能なProvisioning Serverとターゲットデバイスに関する情報を取得します。これにより、Provisioning Serverと
タ ー ゲット デバイ スを 稼働し てい る状 態に 保つ ことがで き ます。た だ し、 デー タベ ース がオフライ ンに なる と、
Provisioning Servicesの管理機能とコンソールは利用できなくなります。詳細については、Citrix eDocs – オフライン
データベースのサポートを参照してください。
冗長性
ポート/スレッド
ブートに関するペー
シング（Boot
Pacing）
中間バッファリング
サーバーメモリ
各 Provisioning Services サイトでは、冗長性を実現するために、少なくとも 2 台の Provisioning Server が必要となり
ます。単一ホストの故障によりサービス停止が発生しないようにするために、仮想化された Provisioning Server を複
数のハイパーバイザーホスト間で分散させる必要があります。また、単一サーバーの故障により性能の低下が起こらな
いようにすることも重要です。例えば、2 台構成の Provisioning Server HA 配備の場合、1 台のサーバーが故障する
と、残る 1 台のサーバーが過負荷状態になります。
ストリーミングポートの総数（デフォルトで 20）に、ポート当たりのスレッド数を乗じた値が、単一のProvisioning Server
により同時にストリーミングされるターゲットの最大数になります（すなわち、「ポート数」×「ポート当たりのスレッド数」＝
「アクティブクライアントの最大数」）。ポート当たりのスレッド数が、Provisioning Server上で利用可能なコアの数を超え
ない場合に、最良の性能が得られます。詳細については、Citrixブログの記事 – ポートとスレッドを参照してください。
ブートするターゲットデバイスの数は、アクティブなターゲットデバイスの数よりも、Provisioning Server の性能に対して
非常に大きな影響を与えます。このため、利用可能なリソースに応じて、Provisioning Server 当たりの同時にブート可
能なデバイスの最大数を調整する必要があります。これにより、ブートするデバイスが、アクティブなデバイスの性能に
影響を与えないことを保証できます。
ブートするデバイスの最大数を設定するには、サーバープロパティ内の[Pacing]タブを使用します。
中間バッファリング機能を使うと、Windows Server、Windows Vista、Windows 7 の各オペレーティングシステムの性
能を大幅にアップできます。状況によっては（Windows XPなど）、中間バッファリングが役に立たない場合もあります。
また、中間バッファリングを有効にすると、書き込みキャッシュをホスティングしているディスクが満杯の場合、書き込み
キャッシュ内部でデータ損失が発生することがあります。このため、中間バッファリングを実務環境で有効にする前に、
開発環境で（あらゆるハードウェア構成に関して）同機能を徹底的にテストし、書き込みキャッシュのサイズを検証する
必要があります。詳細については、CTX126042 – ローカルハードドライブキャッシュで中間バッファリングを無効にする
場合を参照してください。
Provisioning Server のホスティングに使用する Windows オペレーティングシステムは、vDisk をメモリ内に部分的に
キャッシュできます。このキャッシング処理の効率性を最大化するには、PVS サーバーが十分な量の利用可能なメモリ
XD 5.x
XA 6.x
XD 5.x
XA 6.x
XD 5.x
XA 6.x
XD 5.x
XA 6.x
XD 5.x
44
を持つ必要があります。Provisioning Server 向けの最小メモリ量を決定する公式を下記に示します。
サーバーオペレー
ティングシステム
ハードウェア
•
システムキャッシュ = 512MB +（アクティブな vDisk の数×vDisk から読み取られる平均的なデータ量）
•
サーバーRAM の合計サイズ = 負荷状態でコミットされるバイト数 + システムキャッシュ
vDiskから読み取られる平均的なデータ量が不明な場合、一般的な通例として、デスクトップの場合はアクティブな
vDisk当たり最小 2GB、サーバーの場合はアクティブなvDisk当たり最小 10GBとして計算します。詳細については、
CTX125126 – Provisioning Services向けの高度なメモリおよびストレージに関する留意点を参照してください。
Provisioning Services は、64 ビット版のオペレーティングシステム（Windows Server 2008 R2 を推奨）上でホスティン
グする必要があります。これにより、大量のメモリをアドレッシングすることや、改善されたファイルキャッシング機能を利
用することが可能となります。
Provisioning Services は、通常、非常に大きな I/O フットプリントとメモリ消費量を持つため、仮想化の理想的な候補と
はなりません。それにもかかわらず、シトリックスの内部テストや世界中の実際の顧客の経験によれば、大規模なエン
タープライズ環境であっても Provisioning Services をうまく仮想化できることが実証されています。
XA 6.x
XD 5.x
XA 6.x
XD 5.x
XA 6.x
Provisioning Server を仮想化する場合、常に十分なリソースが利用可能であることを保証する必要があります。リソー
スの不足が原因でネットワークや CPU の輻輳などが発生した場合、ターゲットの読み取り/書き込み操作に遅延が発
生します。これは、すべての接続されているターゲットデバイスに対して直ちに悪影響を及ぼすことになります。
ネットワーキング
詳細については、CTX128645 - Provisioning Servicesを仮想化する場合の設計上の留意点を参照してください。
Provisioning Services ベースの環境において推奨される、ネットワーキング関係のベストプラクティスを以下に示しま
す。
•
Provisioning Server およびクリティカルなターゲットデバイスが、ネットワークに対して冗長構成で接続されて
いること（NIC チーミングなどを使用）。
•
Provisioning Server とターゲットデバイスが、同一データセンター内に配置されていること。
•
Provisioning Server とターゲットデバイス間のレイテンシをできるだけ低くすること。ファイアウォールやネット
ワークコンポーネントによる Provisioning Service のパケットインスペクションは実行しないこと。
•
スパニングツリーを無効にするか、またはクライアントや Provisioning Server に接続されているすべてのエッ
ジポートで PortFast を有効にすること。
•
高速ネットワークを使用すること。これにより、特にブートストーム時に、Provisioning Services のストリーミン
グトラフィックに起因するネットワークボトルネックの生成を回避できます。
•
大規模配備の場合や、ネットワークが飽和するような環境の場合、専用のネットワーク上で Provisioning
Services のストリーミングトラフィックを分離すること。
•
Citrix Provisioning Services は UDP ユニキャストを使用するため、ネットワーク装置上で「ストーム制御設定」
XD 5.x
XA 6.x
45
を行うと問題が起こる場合があります。
•
「TCP Large Send Offload」オプションを使うと、AIX TCP レイヤで、最大 64KB 長の TCP メッセージを構築
し、同メッセージを IP およびイーサネットデバイスドライバを介して 1 コール分のスタックで送信できます。続い
て、アダプタはメッセージを複数の TCP フレームに再セグメント化して、ワイヤー上を送信できるようにします。
送信パケットを再セグメント化し、大きなフレームに格納することで、Provisioning Server に対する遅延やタイ
ムアウトが引き起こされます。このため、「TCP Large Send Offload」オプションを無効化することを推奨しま
す。これを行うには、以下のレジストリキーを追加します。
ターゲットデバイス
o
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BNNS\Parameters\

EnableOffload = 0（DWORD）
Provisioning Server とターゲットデバイス
o
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters\

ブートストラップデリ
バリー
“DisableTaskOffload” = 1（DWORD）
詳 細 に つ い て は 、 CTX117374 – Best Practices for Configuring Provisioning Server on a Network お よ び
CTX121618 - ターゲットデバイスの性能とフリーズ問題を参照してください。
ターゲットデバイスがProvisioning Serverにコンタクトするために必要となる情報は、DHCPオプション、PXEブート、専
用ISOファイルなど複数の方法により提供されます。個々のサーバーやネットワークコンポーネントの機能停止を許容
するような冗長構成でブートプロセスを設計することが重要です、さもなければ、ターゲットデバイスはブートに失敗しま
す。詳細については、Citrix eDocs – ブートストラップファイルの取得を参照してください。
XD 5.x
XA 6.x
仮想デスクトップ/XenApp サーバーと Provisioning Server が同一のブロードキャストドメインの一部であるか、または
冗長 DHCP リレーが実装されている場合、PXE サービスを活用することで、インフラストラクチャーの複雑性を増すこと
なくフォールトトレランスを提供する必要があります。
DHCPオプション 66 および 67 を使用してブート情報を提供する場合、負荷分散装置（Citrix NetScalerなど）を使用し
て、複数のProvisioning Server間でTFTPサービスの負荷分散を行う必要があります。TFTPサービスで高可用性を実
現する方法の詳細については、CTX131954 - TFTPの高可用性を参照してください。
ISOファイルを使用してターゲットデバイスにブート情報を提供する場合、同ファイルがフォールトトレラントなCIFSシェア
上に配置されていることを確認してください。そうでない場合、同CIFSシェアが単一障害点となります。詳細について
は、Citrix eDocs – 起動デバイスマネージャーの使用方法を参照してください。
46
ログオンサーバー
アンチウィルス
冗長性を実現するために、最小で 2 台のProvisioning Serverをブートストラップファイル内に指定する必要がありま
す。ファーム内のすべてのProvisioning Serverは、すべてのサイトからのターゲットデバイスログインを処理できること
に注意してください。詳細については、CTX119286 – Provisioning Serverの高可用性に関する留意点を参照してくだ
さい。
Provisioning Services のターゲットデバイスは、指定されたシステムのリストから、ログオンサーバーをランダムに選択
することに注意してください。このため、ログオンサーバーの順番をソートする必要はありません。
Provisioning Services ベースの環境においてシトリックスが推奨する、アンチウィルス関係のベストプラクティスを以下
に示します。
•
•
•
XD 5.x
XA 6.x
XD 5.x
XA 6.x
ターゲットデバイスと Provisioning Server 上で、
o
書き込み/変更が発生した場合にのみスキャンを実行すること
o
ローカルデバイスのみをスキャンすること（ネットワークドライブを除外する）
o
書き込みキャッシュのスキャンを行わないこと
ターゲットデバイス上で、スキャン対象から以下のものを除外すること
o
BNDevice.exe
o
BNNS.sys / BNNS6.sys
o
BNNF.sys
o
BNPort.sys
o
Bnistack.sys / Bnistack6.sys
o
BNITDI.sys
Provisioning Server 上で、スキャン対象から以下のプロセスを除外すること
o
StreamService.exe
o
StreamProcess.exe
o
SoapServer.exe
詳細については、CTX124185 – Provisioning Servicesのアンチウィルスに関するベストプラクティスを参照してくださ
い。
47
Active Directory マ
シンのパスワード
ARP キャッシュ
ターゲットデバイスが標準イメージモードでvDiskにアクセスする場合、Provisioning Serverはターゲットデバイスに名
前を割り当てます。同ターゲットデバイスがドメインメンバーである場合、Provisioning Serverが割り当てる名前とパス
ワードは、当該ドメイン内の対応するコンピューターアカウント内にある情報と一致する必要があります。一致しない場
合、そのターゲットデバイスはログオンに失敗します。このため、Provisioning Serverは、vDiskを共有しているターゲッ
トデバイス向けのドメインパスワードを管理する必要があります。従って、「Disable machine account password
changes（マシンアカウントのパスワード変更を無効化する）」というセキュリティポリシーを、すべてのターゲットデバイ
スコンピューターオブジェクトで有効にする必要があります。詳細については、Citrix eDocs – ドメインパスワードの管理
を参照してください。
ARP キャッシュのデフォルトの寿命は Windows Server 2003 では 10 分でしたが、Vista/W2K8 ではこれが 15～45
秒の間のランダムな値へと引き下げられました。この結果、PVS ブートストラップが、Vista/W2K8（およびそれ以降）の
ブート時に、タイムアウトを経験する可能性が以前の 20 倍に増えました。ARP キャッシュエントリの寿命を延長するに
は、Provisioning Server、仮想デスクトップ、XenApp サーバー上で以下の手順を実行します。
XD 5.x
XA 6.x
XD 5.x
XA 6.x
1. コマンドシェルウィンドウを開きます。コマンドプロンプトで、以下を入力します。
netsh interface ipv4 show interfaces
2. APRky サッシュエントリの寿命を 600 秒に設定するには、以下のコマンドを実行します。
netsh interface ipv4 set interface <PVS interface number> basereachable=600000
3. 新しい設定を確認するには、以下のコマンドを実行します。
netsh interface ipv4 show interface <PVS interface number>
監査証跡のアーカイ
ブ化
「Base Reachable Time」には値として 600,000msを、「Reachable Time」には 300,000～900,000ms間の値をそれ
ぞれ指定する必要があります。詳細については、Microsoft Knowledgebaseの記事KB949589 – アドレス解決プロトコ
ル（ARP）の説明を参照してください。
管理アクションをトラッキングするためには、Provisioning Services の監査機能を有効にする必要があります。これは、
複数の管理者が構成を変更する場合に特に役立ちます。
XD 5.x
XA 6.x
監査機能はデフォルトでは無効化されています。監査を有効にするには以下を実行します。
1. Console ツリーで、ファームを右クリックした後、[Farm Properties]メニューでオプションを選択します。
2. [Options]タブで、[Auditing]の下にある[Enable auditing]チェックボックスをオンにします。
監査を有効にすると、監査証跡情報が汎用構成データと共に Provisioning Services データベース内に保存されます。
Provisioning Services は監査データを自動的に削除しないため、監査データをアーカイブ化することにより、データ
ベースが無限に増大することを防ぎます。監査証跡データをアーカイブ化するには、Provisioning Server 上で以下の
コマンドを実行します。
MCLI Run ArchiveAuditTrail –p filename=<filename>
監査情報には、Provisioning Services Console からアクセスできます。ファーム管理者は、Console ツリー内の親ノー
48
ドや子ノードを右クリックすることにより、監査情報にアクセスできます。その他の管理者がアクセスできる監査情報は、
同管理者に割り当てられているロールにより異なります。
49
アプリケーション
カテゴリ
アプリケーションの配
信方法
冗長性
ベストプラクティス
アプリケーションは、インストール型アプリケーションとして、XenApp 上でホスティングされるアプリケーションとして、ま
たは XenApp ストリーミングや Microsoft App-V により動的に配信されるアプリケーションとして、ユーザーのデスクトッ
プへと配信されます。アプリケーション種別に基づくアプリケーション配信方法の推奨例を下記の表に示します。
アプリケーション 基本的
変則的
リソースを多用す
技術的に困難
種別
る
説明
すべてのユー
ザーが必要とする
共通アプリケー
ション
例
Microsoft Office、
Adobe Acrobat
主な配信方法
デスクトップ上にイ
ンストールされる
ユニークなカスタ
ム構築アプリケー
ション
デスクトップにスト
リーミングされる
か、サーバー上で
ホスティングされる
高度なシステム要
件を持つ
可動部分や依存
性の多い、大規模
で複雑なミッション
クリティカルアプリ
ケーション
CAD/CAM、
Google Earth、
GIS
Epic、Cerner,
デスクトップにスト
リーミングされる
か、デスクトップ上
にインストールさ
れる
サーバー上でホス
ティングされる
複数の適切なアプローチが存在するため、一部のアプリケーション種別は、現在の組織内の専門知識レベルに基づい
て、ストリーミング型またはホスティング型のアプリケーションとして配信可能です。
1 台のサーバーの障害が原因で可用性が制限されることを防ぐために、各 XenApp ワーカーグループには少なくとも
N+1 冗長性を提供する必要があります。
適用対象
XA 6.x
XA 6.x
50
負荷評価基準
（Load Evaluator）
ア プリケーシ ョン/デ
スクトップの公開
ファームの健康状態
の監視
シトリックスは、性能テストやスケーラビリティテストに基づいたカスタムの負荷評価基準を実装することを推奨します。
複数のワーカーグループが存在する複雑な環境の場合、シトリックスはしばしば、ワークグループごとにユニークな「カ
スタム」の負荷評価基準を作成し、その結果として「負荷管理グループ（load managed group）」を作成することを推奨
します。これらの負荷評価基準は、テスト時に特定された各種のリソースボトルネックに応じて、それぞれ異なる規則と
しきい値を持ちます。実務環境への移行前に適切なテストを実行できない場合、Citrix Consulting は、以下に示すよう
な、すべてのサーバーに対して基準値として適用可能な「カスタム」の負荷評価基準を実装することを推奨します。
•
CPU 使用率 - 全負荷: 80%、負荷なし: 10%
•
メモリ使用率 - 全負荷: 80%、負荷なし: 10%
•
負荷スロットリング: 高
•
サーバーユーザー負荷:X
ログオンプロセスは、XenApp サーバーが実行する最もリソースを多用するアクションの 1 つであるため、「負荷スロット
リング（Load Throttling）」規則を追加する必要があります。これにより、任意の時点で発生する同時ログオンの数を効
果的に制限できます。また、キャッピングのために「サーバーユーザー負荷（Server User Load）」規則を含める必要が
あります。これは回復力を提供するためのベストプラクティスとして認識されています。この初期値として 100（上記で
は”X”と表記されている）を選択できますが、スケーラビリティテストの結果に基づいてこの値をカスタマイズすることを推
奨します。
多数のユーザーに対するパーミッションの割り当てを可能にするために、ユニークなロール向けのグループを作成しま
す。1,000 名のユーザーからなる 1 つのグループに対してアプリケーションを公開する場合、1,000 名のユーザー全員
に対して 1 つのオブジェクトを検証するだけで済みます。これに対して、1,000 件の個別ユーザーアカウントに対して同
じアプリケーションを公開する場合には、1,000 個のオブジェクトすべてを検証する必要があります。これは、Microsoft
AGDLP（Account、Global、Domain Local、Permission）の原則に従うものです。
XenApp環境内にあるすべてのサーバーの健康状態を監視し、問題が発生した場合や問題が近々発生しそうな場合に
はアラートを発行する必要があります。このため、シトリックスは、「XenApp Health Monitoring and Recovery」機能を
有効化することを推奨します。同機能を有効にすると、コアコンポーネントに関する各種のテストが実施され、それらの
テストのいずれかに失敗した場合、アラートがトリガされ、負荷分散からのサーバーの削除のようなアクションが実施さ
れます。詳細については、Citrix eDocs – サーバーヘルスの監視および復元機能でサーバーのパフォーマンスを監視
するを参照してください。
XA 6.x
XA 6.x
XD 5.x
XA 6.x
51
XenApp サ ー バ ー
のリブートポリシー
CPU 最適化
メモリ最適化
アプリケーションサー
バー
匿名ユーザー
SMB 1.x クライアン
トの調整
注: 混在環境
（2003/2008 R2）で
は SMB 2.0 が使用
できないため、SMB
1.0 の調整が必要と
なります。
潜在的なアプリケーションのメモリリークに対処し、プロビジョニング済みの XenApp サーバーに対して実施された変更
をリセット可能にするために、XenApp サーバーでは定期的なリブート（rolling reboot）スケジュールを導入する必要が
あります。リブートの間隔は、アプリケーションセットの特性や各ワーカーグループのユーザーベースの特徴に応じて異
なります。一般的には、週次リブートスケジュールの導入が出発点として推奨されます。
可能ならば、1 つのワーカーグループ内の XenApp サーバーが同じ日の夜にすべてリブートされないように、リブートプ
ロセスを調整します。これにより、アップデートが原因で単一ワークグループ内のすべてのサーバーがダウンすることを
回避できます。
CPU 使用率管理機能を使うと、ファームのリソース管理能力を増強することにより、ファームの性能が CPU を多用す
る操作によって制限された場合に CPU のピークを正常化できるようになります。CPU 使用率管理を有効にすると、
サーバーは各ユーザーに割り当てられている CPU のシェアを管理します。デフォルトではシェアは均等になります。こ
れにより、あるユーザーの振る舞いが別のユーザーの生産性に影響を与えることを回避し、より多くのユーザーがサー
バーに接続できるようになります。シトリックスは、XenApp の CPU 使用率管理機能を有効にすることを推奨します。
Windows Server 2008 R2 では、XenApp の CPU 使用率管理機能を有効にする前に、Remote Desktop Services
（RDS）の機能である「Dynamic Fair Share Scheduling（DFSS）」を無効化する必要があることに注意してください。
メモリ最適化を有効にすると、複数のセッションで利用可能な共有 DLL を作成することにより、物理および仮想メモリの
両方における DLL 割り当ての管理を改善できます。この機能を使うと一部のアプリケーションでは問題が発生すること
が知られているため、シトリックスは、メモリを多用するアプリケーションの互換性テストを実施した後でのみ、この機能
を有効にすることを推奨します。
仮想デスクトップ/XenApp サーバーとアプリケーションサーバー（メールサーバー、ファイルサーバー、データベース
サーバー、Web サーバーなど）の間で、高速ネットワーク接続を実装する必要があります。理想的には、なるべくルータ
のホップ数やファイアウォールの台数が少ない LAN を使用します。低速な接続は、アプリケーションの応答遅延や性能
低下の原因となります。
認証済みのユーザーに対してのみリソースを公開する場合、ローカルな匿名ユーザーアカウントを無効化または削除
することを推奨します。
Microsoft 環境におけるファイル共有は、Server Message Block（SMB）と呼ばれるアプリケーションプロトコルに基づ
いています。あるデバイスが、別のコンピューター上にある Microsoft のファイルシェアに接続する場合、同デバイスは
SMB クライアントとして動作します。
XA 6.x
XA 6.x
XA 6.x
XD 5.x
XA 6.x
XA 6.x
XA 6.x
デフォルトでは、SMB 1.0 クライアントネットワークリダイレクタが単一のファイルサーバーに対して発行できる未処理の
SMB 要求/コマンド数は 50 件のみになります。この件数は、レジストリ MaxCmds の値により制御されます。リモート
サーバーへのすべての接続は、ユーザー単位ではなくコンピューター単位となります。これは、XenApp サーバー上の
すべてのユーザーが、同じ SMB セッションを通じてファイルをオープンすることを意味します。この制限を克服し、その
他の SMB 関連の問題を回避するには、混在環境に置かれている各 XenApp サーバー上で以下のようなレジストリ設
定を行うことを推奨します。
52
•
HKLM\SYSTEM\CurrentControlSet\Services\Lanmanworkstation\Parameters
o
•
HKLM\SYSTEM\CurrentControlSet\Services\MRxSmb\Parameters
o
•
"MultiUserEnabled"=dword:00000001
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer
o
•
"MaxCmds"=dword:00002048（dec）
NoRemoteRecursiveEvents”=dword:00000001
HKLM\SYSTEM\CurrentControlSet\Services\Lanmanserver\Parameters
o
"MaxWorkItems"=dword:00008192（dec）
o
"MaxMpxCt"=dword:00002048（dec）
o
"MaxRawWorkItems"=dword:00000512（dec）
o
"MaxFreeConnections"=dword:00000100（dec）
o
"MinFreeConnections"=dword:00000032（dec）
また、XenApp システムと対話するすべてのファイルサーバー上で、以下のレジストリキーを設定することを推奨しま
す。
•
HKLM\SYSTEM\CurrentControlSet\Services\Lanmanserver\Parameters
o
"MaxWorkItems"=dword:00008192（dec）
o
"MaxMpxCt"=dword:00002048（dec）
o
"MaxRawWorkItems"=dword:00000512（dec）
o
"MaxFreeConnections"=dword:00000100（dec）
o
"MinFreeConnections"=dword:00000032（dec）
詳細については、CTX131577 - XenApp 6.xデスクトップ仮想化 - 最適化ガイドを参照してください。
SMB 2.x クライアン
トの調整
デフォルトでは、Windows SMB リダイレクタは、ネットワーク関連のタイムアウトを防ぐ必要がある場合には、高レイテ
ンシのネットワーク接続経由のスループットを調節します。DisableBandwidthThrottling レジストリの値を 1 に設定する
ことで、このようなスループットの調節を無効化し、高レイテンシのネットワーク接続を介してより高いファイル転送ス
ループットを実現できます。
XA 6.x
デフォルトでは、SMB リダイレクタは、1 件の要求につき約 64KB を超えるサイズのペイロードを転送しません。
53
DisableLargeMtu レジストリの値を 0 に設定することで、より大きな要求サイズが有効となるため、ファイル転送速度を
改善できます。
上記の理由により、すべての XenApp サーバーでは以下のレジストリ設定を行うことを推奨します。
•
•
HKLM\System\CurrentControlSet\Services\
o
LanmanWorkstation\Parameters
o
“DisableBandwidthThrottling"=dword:00000001
o
“DisableLargeMtu”=dword:00000000
HKLM\SOFTWARE\Microsoft\Windows\
o
CurrentVersion\Policies\Explorer
o
NoRemoteRecursiveEvents”=dword:00000001
ガイドラインの詳細については、CTX131577 - XenApp 6.xデスクトップ仮想化 - 最適化ガイドを参照してください。
54
パーソナライズ
印刷
カテゴリ
プリントドライバの数
ベストプラクティス
管理の手間を減らし、潜在的な安定性の問題を回避するためには、単一イメージ上にインストールするプリントドライバ
の数を最小に保つ必要があります。必要となるプリントドライバの数を減らすには、可能な場合には常に Citrix
Universal Print Driver を使うようにします。
適用対象
XD 5.x
XA 6.x
サードパーティ製のプリントドライバを使用する場合、トラブルシューティング手順を簡素化し、一貫したユーザーエクス
ペリエンスを実現するためには、XenApp のワーカーグループおよび XenDesktop のデスクトップグループを通じて、
同プリントドライバを整合的にインストールする必要があります。
プリントドライバの自
動インストール
カーネルモードドライ
バ
プリントドライバのテ
スト
印刷ジョブの送信
業務時間中に大量のプリントドライバを手動で複製しない でくだ さい。プリントド ライバの複製は、 Independent
Management Architecture Service（IMA）経由で実行されるため、データストアのデータベースにキューイングされま
す。ドライバの手動複製を行う場合、可能な限り業務時間後に実施してください。詳細については、CTX121060 –
XenAppでプリントドライバを交換する場合のベストプラクティスを参照してください。
仮想デスクトップと XenApp サーバー間の整合性を保証し、サポートやトラブルシューティングを容易にするために、プ
リントドライバの自動インストールを禁止する必要があります。
XD 5.x
XA 6.x
カーネルモードのプリントドライバは、サーバー障害を引き起こす可能性があるため使わないようにしてください。より新
しいユーザーモードのプリントドライバはより高いレベルで動作するため、プリントスプーラーサービスにしか影響しませ
ん。
サードパーティ製のプリントドライバは、実務環境で使用する前に、徹底的にテストする必要があります。プリントドライ
バの検証を行うには、Citrix StressPrintersツールを使用します。
XD 5.x
印刷性能の低下を防ぐために、プリントサーバーは、高スループットで低レイテンシのネットワーク接続を通じて、仮想
デスクトップや XenApp サーバーに接続する必要があります。RPC プロトコルは、WAN 接続のサポートを前提として
開発されたものではありません。
XD 5.x
XA 6.x
XD 5.x
XA 6.x
XA 6.x
55
プロファイル
カテゴリ
ユ ー ザー プロフ ァイ
ル戦略
ログオンスクリプト
ベストプラクティス
ユーザーのプロファイルは、仮想デスクトップシナリオにおけるユーザーエクスペリエンスの成否に関して重要な役割を
演じます。いかに周到に設計された仮想デスクトップ/アプリケーションデリバリーソリューションであっても、ログオンに
長い時間がかかることや設定の消失などが原因でユーザーが不満を抱えることになったとしたら、そのソリューションは
失敗です。初回の体験は強烈な印象を残すため、ユーザーによる受容度に大きく影響します。
Microsoft Windows自体が複数のプロファイルソリューションを提供しており、様々なサードパーティソフトウェア企業が
同ソリューションを補完する製品を提供しているため、すべての基本的なプロファイルテクノロジーに関する知識を取得
し、成功するための詳細なプランニングを実施することが必要です。ほとんどの環境では、標準的なWindowsのプロ
ファイルソリューション（ローミングプロファイルなど）ではなく、Citrix Profile Managementのような高度なユーザープロ
ファイルソリューションを実装することを推奨します。これにより、ユーザープロファイルの破損や膨張を防ぐと同時に、
ログオン時間を短縮できます。詳細については、CTX128701 – ユーザープロファイルプランニングガイドを参照してく
ださい。
ユーザーログオン時間を最小化するために、ユーザーログオンスクリプトの数を最小限に保つ必要があります。また、
ログオンスクリプトが、仮想デスクトップ環境の要件や制限事項に適合していることも必要です。例えば、Provisioning
Services や Machine Creation Services などにより仮想デスクトップのプロビジョニングを行っている場合には、ソフト
ウェアインベントリのチェックやアップデートのチェックを実施する必要はありません。
適用対象
XD 5.x
XA 6.x
XD 5.x
XA 6.x
注: 従来的なログオンスクリプトを「Group Policy Preferences」で置き換えると、多くの場合、ログオン時間を短縮でき
ます。
56
フォルダリダイレク
ション
フォルダリダイレクションを使うと、プロファイルのサイズを縮小し、ログオン時間を短縮できます。このため、以下に示す
フォルダをファイルシェアへとリダイレクトすることを検討してください。
•
Contacts
•
Desktop
•
Documents
•
Downloads
•
Favorites
•
Links
•
Music
•
Pictures
•
Saved Games
•
Searches
•
Start Menu
•
Videos
XD 5.x
XA 6.x
AppDataフォルダのリダイレクトについては慎重に検討する必要があります。これを行うと、対応するファイルシェアをホ
スティングしているファイルサーバーの負荷が大幅に増加するため、アプリケーションに問題を引き起こす可能性があ
ることに注意してください。詳細については、Citrixブログの記事 - Citrix Profile ManagementとVDIの適切な利用を参
照してください。
57
Citrix Profile Manager
カテゴリ
アクティブライトバッ
ク（Active Write
Back）
MFT キャッシュファ
イル
クロスプラットフォー
ム機能
ベストプラクティス
アクティブライトバック機能を有効にすると、Citrix Profile Manager は、アプリケーションによるファイルの書き込みやク
ローズがいつ実施されたかを検出し、アイドル期間中に、当該ファイルをプロファイルのネットワークコピーへとコピーし
ます。ただし、Citrix Profile Management は、オーダーされたログオフ時を除き、レジストリの変更のネットワークへの
コピーは行いません。このため、リブートのたびにローカルにキャッシュされたプロファイル情報が消去される場合、プロ
ビジョニング済みのシステム上でレジストリとファイルが揃わなくなるという危険性があります。このような理由から、非
永続的な Provisioning Services または Machine Creation Services シナリオでは、アクティブライトバック機能を無効
にすることを推奨します。
MFTファイルは、変更ジャーナル通知の処理を高速化するために、Citrix Profile Managementにより使用される内部
的なキャッシュファイルです。Provisioning Servicesによりプロビジョニングされたイメージ上でProfile Managementを
設定する場合、同イメージを共有モードに戻す前に、MFTファイルを同イメージから削除すると、ログオン時間を短縮で
きます。詳細については、Citrix eDocs – プロビジョニングと固定を参照してください。
Microsoft Windows XP および Windows Server 2003 におけるプロファイルのことを「バージョン 1 プロファイル」と呼
びます。これに対して、Windows Vista、Windows 7、Windows Server 2008、Windows Server 2008 R2 におけるプ
ロファイルのことを「バージョン 2 プロファイル」と呼びます。バージョン 1 プロファイルのフォルダ構造（またはネームス
ペース）同士は、ほぼ交換可能です。これは、Windows XP と Windows Server 2003 上のフォルダがほぼ同じである
ためです。同様に、バージョン 2 プロファイルのフォルダ構造同士は、ほぼ交換可能です。ただし、バージョン 1 プロファ
イルとバージョン 2 プロファイルではネームスペースが異なっています。ユーザーデータおよびアプリケーションデータ
用に隔離されたユーザー固有のフォルダを提供するために、後者のオペレーティングシステムではフォルダ構造が変
更されています。バージョン 1 プロファイルはデータをルート（root）フォルダである Documents and Settings に格納し
ます。一方、バージョン 2 プロファイルは、より直観的な名前のフォルダ（「Users」）にデータを格納します。例えば、
Windows 7 に お け る AppData\Local フ ォ ル ダ の 内 容 は 、 Windows XP に お け る Documents and
Settings\<username>\Local Settings\Application Data の内容と同じになります。
適用対象
XD 5.x
XA 6.x
XD 5.x
XA 6.x
XD 5.x
XA 6.x
Citrix Profile Managerの「Cross Platform」機能を使うと、バージョン 1 プロファイルとバージョン 2 プロファイル間で設
定を移行できます。この機能はログオン/ログオフ性能に悪影響を与える可能性があるため、設定の移行処理が完了し
た時点で、同機能を無効化する必要があります。詳細については、Citrix eDocs – クロスプラットフォーム設定を構成す
るにはおよびローミングユーザーデータの管理：配備ガイドを参照してください。
58
ポリシー
カテゴリ
設定のオーバーラッ
プ
ポリシー設定
ベストプラクティス
「Remote Desktop Session Host Configuration」および「Citrix XenDesktop/XenApp Policies」で、矛盾した設定や
重複した設定を行わないでください。「Remote Desktop Session Host Configuration」は、Citrix とポリシー設定と同様
の機能を提供している場合があります。可能であれば、トラブルシューティングを容易にするために、すべての設定のオ
ン/オフを一貫した状態に保つようにします。
通常、XenDesktop/XenApp 環境を中央で一元的に設定するには、Active Directory のグループポリシーを使用しま
す。Active Directory のグループポリシーを通じてポリシーを実装すると、Desktop Studio を使用した場合に比べて以
下のような多くのメリットがあります。
•
Citrix ポリシーと Microsoft ポリシーが単一の場所に維持される。
•
ポリシーが複数のドメインコントローラーで自動的に複製される。
適用対象
XD 5.x
XA 6.x
XD 5.x
XA 6.x
エンドポイント名や IP、マシンタイプ、タグ、アクセス制御（Smart Access）のフィルタリングのような、高度なフィルタリン
グメカニズムが必要となる場合、XenDesktop Studio/XenApp AppCenter 内において、例外ベースで Citrix ポリシー
を作成する必要があります。
重要: XenDesktop Studio/XenApp AppCenterPlease 内で作成したポリシーは、Active Directory を使用して適用し
たポリシーよりも優先度が低くなります。
ポリシーの数
すべてのユーザーおよび XenApp サーバー/仮想デスクトップに対して、基本ポリシーを適用する必要があります。これ
により、それらが企業ポリシーを遵守することを保証できます。基本ポリシーに対する例外を設ける必要がある場合、追
加ポリシーの作成、優先順位付け、フィルタリングを行います。ポリシー管理を合理化し、冗長なポリシーを減らすため
には、グループポリシーを組織単位（OU）構造に従って揃える必要があります。
ログオン時間を短縮するためには、使用するActive Directoryの数を最小に保つ必要があります。「Computer/User」の
設定セクシ ョンは、使用しない場合はオフに してくだ さい 。詳細については、Microsoft Knowledgebaseの記 事
KB315418 – グループポリシーを最適化してログオン性能をアップするにはを参照してください。
XD 5.x
XA 6.x
59
アクセス
ICA/HDX
カテゴリ
最適化
ベストプラクティス
帯域幅使用量と仮想デスクトップのリソース使用率を最適化するためには、以下の ICA/HDX プロトコル調整オプション
を適用することを検討します。
•
“View window contents while dragging”を無効にすること。
•
“Windows Media Redirection”を有効にすること。
•
クライアントサイドでのコンテンツフェッチングで“Flash acceleration”を有効にすること。
•
“Audio over UDP Real-Time Transport”を有効にすること。この設定を行うには、音声品質が「Medium –
optimized for speech」に設定されていることが必要です。
•
“Progressive compression level”を“Low”以上の値に設定すること。
•
非常に低い帯域幅を使用する場合、“Extra Color Compression”を有効にすること。その場合、「Extra Color
Compression Threshold」が適切な値に設定されている必要があります。
•
イメージ圧縮で“Lossy compression”を有効にすること。またはイメージ品質のロスを許容できない場合、
「Heavyweight compression」を有効にすること（この場合、より多くの CPU リソースが消費されます）。
適用対象
XD 5.x
XA 6.x
詳細については、CTX131859 - XenDesktop 5.5 向けのCitrix Receiver 3 およびHDXテクノロジーに関するベストプ
ラクティスと推奨事項を参照してください。また、以下のブログ記事も参照してください。
•
•
•
•
Citrix Blog – HDXプログレッシブディスプレイを必ずオンにすること
Citrix Blog – WAN経由でのHDX 2Dグラフィックスエクスペリエンスの微調整
Citrix Blog – 動的カラー圧縮で帯域幅消費量を 35%削減
Citrix Blog – HDX MediaStreamのサーバーレンダリング型マルチメディアデリバリーの調整
60
セッション共有
セッション共有とは、単一の ICA/HDX 接続内で複数の公開アプリケーションが動作するモードのことです。セッション共
有は、ユーザーが 1 つのセッションをオープンしている状態で、同じ XenApp 上で公開されている別のアプリケーション
を起動した場合に発生します。その結果、2 つのアプリケーションが同一セッション内で動作することになります。アプリ
ケーションがシームレスウィンドウモードで表示されるように設定すると、デフォルトでセッション共有が有効となります。
XA 6.x
複数のアプリケーションで暗号化や色深度のような要件の設定が異なっている場合、それらのアプリケーションを同一
セッションで実行すると不整合な結果が生成されます。セッション共有を使うと全体的なリソース使用率を削減できるた
め、可能な場合は、一貫した設定を持つ複数のアプリケーションを公開することを推奨します。
フレームレ ートの調
整
Microsoft Lync
マルチストリーム
Web カメラ
ヘッドセット
旧式のクライアントデバイス上でXenDesktopのデフォルトのフレームレート（24 FPS）を使用した場合、グラフィックスを
多用するコンテンツを表示している間（サーバーレンダリング型のビデオを再生する場合など）はプロセッサが常に使用
中となります。このため、使用するフレームレートを、エンドポイントデバイスの能力に従って調整する必要があります。
詳細については、CTX123543 – 低消費電力デバイスやモバイルデバイス向けのXenDesktopビデオユーザーエクス
ペリエンスを改善するにはを参照してください。
2 つの CPU（vCPU）が必要となる場合、仮想デスクトップ上のプロセッサ利用率を監視する必要があります。リアルタ
イムの音声/ビデオなどのリソースを多用するアクティビティの場合、2 つの vCPU を持つように設定するとメリットがあり
ます。
注: 2 つのvCPUを持つことは、物理CPUの数を 2 倍にすることを必ずしも意味しません。例えば、物理CPUは複数の
セッション間で共有できますが、vCPUはセッション間で共有できないからです。詳細については、CTX124124 –
Microsoft Lync 2010 を配信するようXenDesktop 5.5 を設定するにはを参照してください。
輻輳ネットワーク接続でサービス品質（QoS）を有効にしている場合、シトリックスは、ICA/HDX MultiStream 機能を使
用することにより ICA/HDX トラフィックを 4 つの独立した TCP ストリームへと分割することを推奨します。これにより、さ
らにきめ細かい優先順位付けの指定が可能となります。
注: Branch Repeater を使用する場合、MultiStream 機能を手動で有効にする必要はありません。
Web カメラを仮想デスクトップセッションへと対応付ける方法としては、汎用的な USB リダイレクションを使用するので
はなく、それを Web カメラオブジェクトとして接続することを推奨します。これは、Web カメラトラフィック用の仮想チャネ
ルは Citrix Webcam Video Compression（CTXMM 仮想チャネル）を活用することで、帯域幅の使用量が低くなり、し
かもネットワークレイテンシ（WAN 接続の場合）を許容可能になるためです。また、このテクノロジーを使うと、複数の
Web カメラ対応アプリケーション（GoToMeeting、HDFaces、Microsoft Lync など）で 1 台の Web カメラを「同時に」使
用することが可能になります。あるアプリケーションで Web カメラを使用していない場合、その Web カメラは同アプリ
ケーションから解放され、別のアプリケーションによって利用可能となるためです。
ヘッドセットを使用する場合、汎用 USB リダイレクションを使用するのではなく、双方向音声仮想チャネル（CTXCAM）
経由で音声を送信することを推奨します。このアプローチにより、帯域幅消費量を最小化できます。
XD 5.x
XD 5.x
XD 5.x
XA 6.x
XD 5.x
XD 5.x
61
USB 電話機
ソフトフォン – 音声デ
バイス
ソフトフォン – 音声
コーデック
ソフトフォン – 音声ト
ランスポート
クライアントリソース
セッションタイムアウ
ト
ICA 暗号化
HDX 3D Pro – ビデ
オオプション
USB 電話機をユーザーセッションにマッピングする場合、以下の 2 つの方法を使用できます。
•
音声デバイスとしてリダイレクトする
•
汎用 USB デバイスとしてリダイレクトする
USB 電話機を音声デバイスとしてリダイレクトする場合、音声信号のみが転送されます。この方法は非常に効率的で
あり、低帯域幅で高レイテンシのシナリオであっても機能します。「受話器を取る」や「番号をダイヤルする」などの制御
コマンドは、「音声デバイスとしてリダイレクトする」ではサポートされません。これらの高度な機能を使うためには、電話
機を汎用 USB デバイス（CTXGUSB 仮想チャネル）としてマッピングする必要があります。追加の帯域幅要件が存在
するため、WAN ユーザーの場合は「汎用 USB デバイスとしてリダイレクトする」を推奨します。
通常、周囲の騒音を拾うことや音声エコーの生成を防ぐために、マイク付きのヘッドセットを使用することを推奨します。
シトリックスは、コンピューターや Web カメラに内蔵のマイクではなく、ノイズおよびエコーキャンセル機能付きの適切な
品質のヘッドセットを使用することを推奨します。
Optimized-for-Speech コーデック（「Medium Quality（中音質）」とも呼ばれる）を使用するように双方向オーディオを設
定します。このコーデックの帯域幅消費量は約 56Kbps（各方向で 28Kbps）です。これは、音声通信に最適な遅延の
少ないコーデックです。
音声性能（特に WAN 接続経由での）を改善するために、シトリックスは、「Audio over UDP Real-Time Transport」を
有効にすることを推奨します。このテクノロジーは、ネットワーク輻輳とパケットロスに関して卓越した耐性を提供しま
す。この機能を使用するには、音声品質を「Medium – optimized for speech」に設定する必要があることに注意してく
ださい。
明示的に必要となる仮想デスクトップユーザーセッションに対して、クライアントリソースのみをマッピングします。各リ
ソース接続は、仮想デスクトップと物理エンドポイント間のトラフィックを生成するため、セッション起動にネットワーク使
用率が増加します。また、低帯域幅/高レイテンシの接続や低速エンドポイントの場合、ログオン時間が長くなります。ク
ライアントリソース接続を制御するにはポリシーを使用します。
アイドル状態または切断状態にあるユーザーセッションは、アクティブユーザーに対しては割り当てることができないリ
ソースを消費します。このため、指定の非アクティブ期間の経過後に、これらのリソースを再び要求できるように、すべ
てのユーザーセッション向けに「Idle and Disconnected Session Timeouts」を設定します。
エンドツーエンドのセキュリティを実現するために、128 ビット暗号化を使用して、エンドポイントデバイスと XenApp
サーバー/仮想デスクトップ間の ICA トラフィックを暗号化します。ICA 暗号化を設定するには、ポリシーを使用します。
以下のユーザー要件に基づいて、最も適した HDX 3D Pro ビデオオプションを選択します。
•
XD 5.x
XD 5.x
XA 6.x
XD 5.x
XA 6.x
XD 5.5
XD 5.x
XA 6.x
XD 5.x
XA 6.x
XD 5.x
XA 6.x
XD 5.5
3D アプリケーションでリモートアクセスが必要な場合、GPU 圧縮オプションを指定します。GPU 圧縮は、帯域
幅が制限されている高レイテンシの環境における最適なオプションです。これを行うには、最小で 96 個（推奨
は 128 個）の CUDA コアを搭載した CUDA 対応のグラフィックスカードと、ドライバ（サーバー上にある対応す
る CUDA ライブラリを含む）が必要となります。
62
•
•
HDX 3D Pro – エン
ドポイントハードウェ
ア
ユーザーが LAN 上に配置されている場合、CPU コーデックやロスレスのような、より高度な帯域幅オプション
を選択することを推奨します。どちらのオプションも、GPU コーデック経由での品質や詳細度をアップさせま
す。
o
CPU: GPU をサーバー上にインストールしていないユーザー向けのフォールバックを提供します。本オ
プションは、イメージ品質と帯域幅の間の妥協点を提供します。
o
ロスレス: 3D アプリケーションへのアクセスで、ピクセル完全なエクスペリエンス（医療関連で必要とされ
るレベル）を実現します。他のオプションよりも、サーバー上の CPU 使用率は低くなりますが、帯域幅使
用量は大幅に増加します。
固定品質と可変品質: GPU または CPU オプションを使用する場合、ユーザーはイメージ品質として固定か可
変のいずれかを選択できます。ユーザーが低帯域幅接続を利用している場合や、ユーザーがオブジェクトの移
動時に早すぎる/遅すぎる動作を経験している場合、可変品質設定を使用することを推奨します。
詳細については、Citrix eDocs – HDX 3D Proのユーザーエクスペリエンスを参照してください。
HDX 3D Pro ビデオストリームのリアルタイム復号化を行うのに十分なリソースを確保するためには、エンドポイント
ハードウェアデバイスは、1.5GHz 以上のプロセッサを搭載する必要があります。
XD 5.5
63
Web Interface
カテゴリ
Web Interface の冗
長性
Web Interface の負
荷分散
XenDesktop コ ン ト
ローラーの接続
ベストプラクティス
Web Interfaceが利用できない場合、ユーザーは新しい仮想デスクトップや公開アプリケーションの起動が行えなくなり
ます。このコンポーネントが単一障害点となることを防ぐために、少なくとも 2 台のWeb Interfaceサーバーを配備する
必要があります。詳細については、CTX125715 - 大規模な実務環境停止を回避するためのWeb Interfaceに関するベ
ストプラクティスを参照してください。
インテリジェントな負荷分散アプライアンス（Citrix NetScalerなど）を使用して、複数のWeb Interfaceサーバーの負荷
分散を行う必要があります。同アプライアンスを使うと、Web Interfaceサービスの可用性を常に確認できます。一方、
Windows NLBのような洗練されていない負荷分散メカニズムでは同様の検査を実施できないため、同メカニズムを使
用した場合、新規要求を処理できないWeb Interfaceサーバーに対してユーザー要求を転送してしまう可能性がありま
す。詳細については、CTX128563 - プランニングガイド: NetScalerによるWeb Interfaceの負荷分散を参照してくださ
い。
すべての XenDesktop コントローラーと通信できるように、XenDesktop 用の Web Interface サイトを設定する必要が
あります。これにより、コントローラーが機能停止した場合でも信頼性を保証できるほか、すべてのコントローラーを通じ
て、ユーザー認証/仮想デスクトップ集約にかかる負荷を分散できます。
適用対象
XD 5.x
XA 6.x
XD 5.x
XA 6.x
XD 5.x
詳細については、以下に示す Citrix Knowledgebase の記事を参照してください。
XenApp XML ブ
ローカーの冗長性
•
CTX131255 - XenDesktop の高可用性 - リファレンスアーキテクチャ
•
CTX131256 - XenDesktop の高可用性 - 実装ガイド
冗長性を提供するために、各 Web Interface サーバーは 2 つ以上の XML ブローカーをポイントする必要があります。
大規模な企業インフラストラクチャーでは、通常、より高度な冗長性要件を必要とするため、以下の 2 つの方法を使用
することを推奨します。
•
XML モニタリングとセッション持続性が組み込まれた、業界で定評のある負荷分散装置（Citrix NetScaler な
ど）を使用すること、これにより、最適な性能とユーザーエクスペリエンスを実現できます。
•
負荷分散装置を利用できない場合、各ファーム内で、少なくとも 2 つの XML ブローカーのアドレスを持つよう
に各 Web Interface サーバーを設定すること。
XA 6.x
トラブルシューティングや保守を容易にするために、Web Interface サイトと XML ブローカーを 1 対 1 の関係で実装す
ることを推奨します。これを行うには、Web Interface のプロパティで、XML ブローカーの自動負荷分散を無効化しま
す。とは言うものの、冗長性を提供するためには、すべての Web Interface サイトに 2 番目の XML ブローカーを追加
する必要があります。
64
詳細については、以下に示す Citrix Knowledgebase の記事を参照してください。
HTTP/XML トラフィッ
クの保護
Secure Ticket
Authority（STA）
スケーラビリティ
•
CTX131762 - Citrix XenApp の高可用性 - リファレンスアーキテクチャ
•
CTX131763 - Citrix XenApp の高可用性 - 実装ガイド
ユーザーデバイスとWeb Interfaceサーバー間のHTTPトラフィックや、Web InterfaceサーバーとXenDesktopサイト
/XenAppファーム間のXMLトラフィックを暗号化します。これにより、ユーザー名/ドメイン名がクリアテキストで転送され
ることや、パスワードが弱い暗号化を使用して転送されることを防止できます。詳細については、Citrix eDocs – Web
Interfaceのセキュリティ構成を参照してください。
Access Gateway または Secure Gateway を使用する場合、少なくとも 2 つの Citrix Secure Ticket Authority（STA）
を設定します。これにより、STA が単一障害点となることを防止できます。ログイン失敗を防ぎ、ログオン時間を最適化
するには、Access Gateway/Secure Gateway 内で指定された STA が、Web Interface 内で指定された STA に（指
定順も含めて）一致することを確認します。
スケーラビリティテストの結果に基づいて、十分なリソースを Web Interface サーバーに対して割り当てる必要がありま
す。これにより、ピークアクティビティ時に Web Interface サーバーがボトルネックにならないことを保証できます。シト
リックスが行った Web Interface サーバーロールのスケーラビリティに関する内部テストによれば、以下のことが判明し
ています。
•
ソケットプーリング
（Socket Pooling）
Web Interface の配
置場所
XD 5.x
XA 6.x
XD 5.x
XA 6.x
XD 5.x
XA 6.x
2.2GHz のデュアル CPU サーバーで Web Interface 5.4 を稼働させた場合、1 時間当たり 30,000 件を超え
る数のセッションを処理できます。
SSL を使用して Web Interface と XenDesktop ファーム/XenApp サイト間の XML 通信を暗号化する場合にのみ、ソ
ケットプーリングを有効にします。破損したソケットが存在する場合にプーリングを有効にすると、Web Interface はその
破損したソケットを継続して再利用する可能性があるため、問題が発生することがあります。ソケットプーリングを無効
にすると、Web Interface は、ソケットが必要となるたびにそれを再構築します。SSL を使用しない場合、これは高コスト
なプロセスにはならないため、それが原因で問題が発生することはありません。また、UNIX 版の XenApp を実行して
いる 1 台以上のサーバーを使用するように Web Interface を設定している場合には、ソケットプーリングを有効化しな
いでください。
セキュリティ上の理由から、Web Interface サーバーは、DMZ や外部ネットワーク上ではなく、内部ネットワーク上に配
置する必要があります。リモートアクセスシナリオでは、DMZ 内に配置した Citrix Access Gateway を使用することに
より、Web Interface トラフィックをプロキシ化する必要があります。
XD 5.x
XA 6.x
XD 5.x
XA 6.x
65
2 要素認証
セキュリティ上の理由から、信頼できないネットワーク（インターネットなど）向けの Access Gateway および Web
Interface ソリューションには 2 要素認証を組み込む必要があります。2 要素認証では、以下に示すような 2 つの「要
素」が存在することが必要となります。
•
「ユーザーが持っているもの」（ハードウェアトークンなど）
•
「ユーザーが知っているもの」（PIN など）
この認証モードを使用することで、権限のないユーザーが内部社員を装って環境にアクセスするリスクを軽減できま
す。
Citrix Plug-In/Receiver
カテゴリ
バージョン
インストール
ベストプラクティス
管理者は、XenApp/XenDesktop 環境に接続しているユーザーが、適切なタイプの Plug-In/Receiver を使用して接続
を行っていること、およびその Plug-In/Receiver が適切にアップデートされ構成されていることを保証する必要がありま
す。環境のサポートを簡素化するためには、すべてのユーザーが同じバージョンの Citrix Plug-In/Receiver を使用して
いることを保証する必要があります。クライアントデバイス上での Plug-in のインストール、アップデート、設定は、Active
Directory 経由で実施するか、または Receiver 経由で Merchandising Server を使用して実施します。
シトリックスは、スタンドアロンモードで対応するアイコンをダブルクリックするのではなく、Autorunを通じてのみVirtual
Desktop Agent MSI（XdsAgent.msi）を起動することを推奨します。これは、MSIがスタンドアロンモードでインストール
されている場合には、パーソナルvDisk機能が正しく動作しないためです。このような環境で同機能を正しく動作させる
には、Virtual Desktop Agentが必要とする構成情報を提供しなければなりません。また、MSIは、手動で実施された変
更を元に戻すことができません。それでもなお、Virtual Desktop Agent MSIをスタンドアロンモードで起動する必要が
ある場合には、eDocs - スタンドアロンモードでのVirtual Desktop Agent MSIの起動に示されているガイドラインに従っ
てください。
適用対象
XD 5.x
XA 6.x
XD 5.x
XA 6.x
66
ユーザー
トレーニングとサポート
カテゴリ
サポートロール
ベストプラクティス
XenApp/XenDesktop インフラストラクチャーをサポートするために、シトリックスは以下に示すサポートロールを推奨し
ます。
•
適用対象
XD 5.x
XA 6.x
レベル 1 サポート: 報告された問題に関する一次サポートを提供します。最初に、サポートメッセージを提供
し、電話での回答を行います。初期的な問題分析、問題の明確化、チケットルーティング、簡単な問題解決など
を実施する必要があります。また、アプリケーションアクセスや、プラグインの設定に関するサポートなどに関す
る要求を処理します。解決できない場合、問題をレベル 2 サポート（実務サポートエンジニア）へと昇格させま
す。
必要な経験期間: 1～2 年
•
レベル 2 サポート（実務サポートエンジニア）: 仮想デスクトップ環境の日常的な運用（先を見越した監視や管
理を含む）を主にサポートします。また、高度なトラブルシューティングを実施するために、利用可能なモニタリ
ング/トラブルシューティングツールを活用します。レベル 1 サポートから上がってきた問題を解決するための支
援を提供します。解決できない場合、問題をレベル 3 サポートへと昇格させます。
必要な経験期間: 2～3 年
•
レベル 3 サポート（ビルドエンジニア）: シトリックスのデスクトップおよびアプリケーション仮想化インフラストラ
クチャーの設計、実装、管理、保守を実施するための中心点です。このレベルのサポート担当者は、新しい
ユースケースの配備に注力し、ライフサイクル管理計画を主導します。通常、1 人のビルドエンジニアが、同時
に 2 つのユースケースを扱うことはありません。例えば、3 つの新しい同時ユースケースでは、3 名のビルドエ
ンジニアが必要となります。解決できない場合、問題をソフトウェアベンダーに固有のテクニカルサポートのレ
ベルへと昇格させ、その問題をレベル 4 サポートに通知します。
必要な経験期間: 3～4 年
•
レベル 4 サポート（アーキテクト）: ビジネス要件をテクニカルアーキテクチャへ変換、インフラストラクチャーの
設計、移行計画を主として担当します。日常的なサポートには関わりません。
必要な経験期間: 5 年以上
推奨される認定資格
上記に示したサポートロールに基づいて、シトリックスは以下のような認定資格を取得することを推奨します。
XD 5.x
67
•
レベル 1 サポート
o
•
Citrix Certified Advanced Administrator（CCAA）
レベル 3 サポート（ビルドエンジニア）
o
•
XenApp および XenDesktop に関する Citrix Certified Administrator（CCA）
レベル 2 サポート（実務サポートエンジニア）
o
•
XA 6.x
Citrix Certified Enterprise Engineer（CCEE）
レベル 4 サポート（アーキテクト）
o
Citrix Certified Integration Architect（CCIA）
68
謝辞
ベストプラクティス集を作成するにあたっては、長い時間と、数多くのシナリオを通じた実際の開発経験が必要と
なりました。我々Citrix Worldwide Consulting Solutions 部門は、本書の作成に協力してくれた以下の人々に対
して感謝の意を表します。
•
Daniel Feller
•
Nicholas Rintalan
•
Dan Allen

Peter David
•
Dimitrios
Samorgiannidis
•
Rich Meesters
•
George Prado
•
Michael Palesch
•
Chase Wright
•
Peter Bats
改定履歴
リビジョン
改定内容
改定者
改定日付
1.0
初版
Citrix Consulting Solutions
2012 年 3 月 9 日
1.1
変更されたベストプラクティス
•
XenDesktop コントローラー: Desktop
Director のホスティング
•
ライセンスサーバー: Citrix License
Server の冗長性
•
ハードウェア一般: 高可用性
•
ネットワーキング: エンドツーエンド接
続の速度
•
Provisioning Services: オーディットト
レールのアーカイブ化
•
Microsoft Hyper-V: 仮 想 デ ィ ス ク
フォーマット
•
追加されたベストプラクティス
•
XenDesktop コントローラー: スケール
アップ/スケールアウト
•
XenApp コントローラー: 構成のロギン
グ
•
XenApp コ ン ト ロ ー ラ ー : 匿 名 ユ ー
ザー
•
Web Interface: Web Interface のロ
ケーション
•
Andy Baker
•
Thomas Berger
Citrix Consulting Solutions
•
Andy Baker
•
Thomas Berger
2012 年 4 月 11 日
•
Web Interface: 2 要素認証
•
ICA/HDX: セッション共有
•
Citrix Plug-In/Receiver: インストール
•
Provisioning Services: 分散ファーム
•
Provisioning Services: vDisk の数
•
Microsoft Hyper-V: Hyper-V の管理
•
システム管理: バックアップの保持
•
システム管理: テスト環境
•
システム管理: 管理の委任
•
システム管理: 命名スキーム
削除されたベストプラクティス
•
XenDesktop コ ン ト ロ ー ラ ー :
XenDesktop サイトと物理ロケーショ
ン（新しいスケールアップ/スケールア
ウトに関するベストプラクティスへと統
合）
Citrix について
70
Citrix Systems, Inc.（NASDAQ:CTXS）は、企業が IT をオンデマンドサービスとして配信できるようにする仮想コ
ンピューティングソリューションのトッププロバイダーです。1989 年に設立し、仮想化、ネットワーキング、クラウド
コンピューティングを完全な製品ポートフォリオへと結合することにより、ユーザー部門向けには仮想ワークスタイ
ルを実現し、IT 部門向けには仮想データセンターを提供する企業へと成長しました。世界中の 23 万社以上の企
業組織が、シトリックス製品を使用してよりシンプルでコスト効率の良い IT 環境を構築しています。シトリックスは、
100 ヶ国以上の 1 万社以上の企業と提携しています。同社の 2011 年度の年間収益は 22 億ドルでした。
®
©2012 Citrix Systems, Inc. All rights reserved. Citrix 、Access Gateway™、Branch Repeater™、Citrix
Repeater™、HDX™、XenServer™、XenApp™、XenDesktop™および Citrix Delivery Center™ は、Citrix
Systems, Inc.またはその子会社の登録商標であり、米国の特許商標局およびその他の国に登録されています。
その他の商標や登録商標はそれぞれの各社が所有権を有するものです。
71

会社概要

東邦銀行 - Citrix

Independent Bank

CXD-202-1I Citrix XenDesktop 5 Administration

確定申告システム

7.6 への移行を推奨する 5 つの理由

シトリックスのクラウドソリューションで実現するITサービスのクラウド化

Citrix 認定トレーニング申込みガイド