設計手法リソースレイヤー

リソースレイヤーは設計手法の3番目のレイヤーであり、特にユーザーグループに焦点を当てている最後のレイヤーです。

ソリューションに対するユーザーの全体的な受け入れは、リソースレイヤー内で行われる決定によって定義されます。プロファイル、印刷、アプリケーション、およびデスクトップイメージの全体的なデザインは、評価フェーズで特定されたユーザーグループの要件にデスクトップがどの程度一致しているかを左右する重要な役割を果たします。

ユーザーエクスペリエンス

優れたVDIエクスペリエンスを提供するには、知覚がすべてです。ユーザーは、従来の物理デスクトップと同等か、またはそれを上回るエクスペリエンスを期待しています。

コーデック、トランスポートプロトコル、 およびセルフサービス機能が、全体的なエクスペリエンスに影響します。グラフィックの質が低かったり、ビデオの遅れが生じたり、ログオンに120秒も要したりすると、ユーザーエクスペリエンスを損なう可能性があります。ユーザーエクスペリエンスが適切に設計されていると、あらゆるネットワークの課題に対応できます。

決定事項:表示プロトコル

正しい表示プロトコルを選択するかどうかで、ユーザーのセッション内の静止画像、ビデオ、およびテキストの質と、単一サーバーのスケーラビリティへの影響が決まります。管理者には次のオプションがあります:

  • レガシ - Windows 7およびWindows 2008R2グラフィックエンジン用に最適化されています(GDI/GDI+)。
  • デスクトップコンポジションのリダイレクト - Desktop Window ManagerのDirectXコマンドをエンドポイントにオフロードしますが、Windows Desktop VDAのみをサポートします。また、7.15 LTSRリリースでは、デスクトップコンポジションのリダイレクトは廃止されている機能です。
  • Framehawk - 主にブロードバンドのワイヤレス接続で見られる、広いネットワーク帯域幅を利用するために遅延が長く、パケット損失が大きいシナリオの環境で、高い更新頻度を提供できるUDPベースのプロトコルです。
  • H.264 - ビデオコーデックとも呼ばれ、ネットワーク帯域幅を節約しながら高品質のビデオに必要な最高のフレームレートを提供します。代わりにCPUの処理時間が長くなり、単一サーバーのスケーラビリティが低下します。ユーザーが主にマルチメディアアプリケーションを使用する場合は、H.264が推奨コーデックになります。
  • Thinwire - 1990年代の最初のCitrixの特許をベースにしており、データはワイヤを介して圧縮方式で転送されます。Thinwireは、最小限のリソースコストで優れたユーザーエクスペリエンスを提供するため、多くのユースケースで使用できます。Thinwireには次の2つのバリエーションがあります:
    • レガシ - Windows 7およびWindows 2008R2グラフィックエンジン用に最適化されています(GDI/GDI+)。
    • Thinwire+ - Windows 8、Windows 10、Windows 2012およびWindows 2016のDesktop Window Manager(DWN)グラフィックエンジン用に最適化されています。
  • 選択的H.264(状況に応じたディスプレイ) - 複数のコーデック(H.264とThinwire+)を画面の各部分に対して同時に使用します。
    • 使用しない - Thinwire+のみを使用し、H.264は使用しません。サーバー側でレンダリングしたビデオや、グラフィックの負荷が大きいその他のアプリケーションを使用しないユーザーに最適です。
    • 画面全体に使用 - H.264のみを使用します。特に帯域幅が低い状況で、サーバー側でレンダリングしたビデオや3Dグラフィックを多用するユーザーに最適です。
    • 領域をアクティブに変更 - 常に変化する画面部分にはH.264を使用し、残りの部分にはThinwire+を使用します。多くのユーザーにとって最適なオプションです。

適切なコーデックを選択することは、全体的なユーザーエクスペリエンスだけでなく、サーバーのスケーラビリティにも影響を与えます。

単一サーバーに対するコーデックの影響の画像

決定事項:トランスポートプロトコル

ネットワーク上でのHDXプロトコルのトランスポート方法は3つあります:

  • TCP - 業界標準のTCPトランスポートプロトコルを使用します。LAN接続および遅延の少ないWAN接続の共通トランスポートプロトコルですが、接続距離が長くなると問題が発生し、遅延が長くなり、再送信の回数が増えます。
  • EDT - UDPをベースとした、Enlightened Data Transportと呼ばれるCitrix独自のトランスポートプロトコルを使用します。遅延やパケット損失が大きいネットワーク、特に長距離WANリンクに適しています。サーバーのCPU負荷を増やさずに、よりインタラクティブなユーザーエクスペリエンスを提供しますが、TCPよりも多くのネットワーク帯域幅を消費します。
  • アダプティブトランスポート - TCPおよびEDTトランスポートプロトコルを使用します。ネットワーク上でのEDTのトランスポートがサポートされていない場合を除き、EDTが使用されます。使用できない場合は、自動的にTCPに切り替わります。

ネットワークで適切なファイアウォールポートが開かれていない場合、またはNetScaler Gatewayが適切に構成されていない場合を除き、多くの環境では標準のトランスポートオプションとしてアダプティブトランスポートが使用されます。

決定事項:ログオン最適化

ユーザーがXenAppまたはXenDesktopセッションにログオンするときは、必ずログオンプロセスが完了する必要があります。これにはセッションの初期化、ユーザープロファイルのロード、グループポリシー設定の実行、ドライブマッピング、プリンターマッピング、ログオンスクリプトの実行、およびデスクトップの初期化が含まれます。各プロセスに時間がかかり、ログオン時間が長くなります。

多くの組織には、多数のマッピングと複雑なログオンスクリプトがあります。これらの各項目を実行すると、ログオン時間が大幅に長くなります。

ログオン時間の画像

Workspace Environment Managementにより、標準のログオンプロセスからドライブマッピング、プリンターマッピング、ログオンスクリプト、および移動プロファイルが除外されます。ログオン最適化により、Workspace Environment Managementによってセッション後にマッピング、スクリプト、およびプロファイルがバックグラウンドで適用され、デスクトップが初期化されます。ユーザーの環境は変わりませんが、デスクトップインターフェイスの表示速度が速くなります。詳しくは、「ログオン最適化」の動画をご覧ください。

多くの環境では、デフォルト構成としてログオン最適化を有効にする必要があります。

決定事項:ユーザーセルフサービス

セルフサービスにより、ユーザーがヘルプデスクトップの介入を必要とせずに自分で自分の環境の変更、更新、およびトラブルシューティング実行できるようになります。多くの組織には、60日~90日の間隔でパスワードの変更をユーザーに求めるポリシーがあります。パスワードが保存されたエンドポイントデバイスをユーザーが複数持っている場合、各デバイスが更新されるまで、アカウントのロックアウトが非常に発生しやすくなります。

StoreFrontを使用し、次の機能によって自分のアカウントに対するセルフサービスを実行することで、時間を節約できます:

  • アカウントのロック解除 - 複数のデバイスを使用する場合によくあることですが、ログオン試行の失敗回数が多すぎてユーザーのアカウントがロックされた場合、セキュリティの質問に対する答えを知っていれば、アカウントのロックを解除できます。
  • パスワードリセット - ユーザーが新しく作成したパスワードを忘れた場合、セキュリティの質問に対する答えを知っていれば、パスワードをリセットできます。

セルフサービスパスワードリセットアーキテクチャにより、SSPRサービス、中央ストア、および以下の2つのアカウントが導入されます:

  • データプロキシアカウント - ユーザーのセキュリティの質問に対する暗号化された答えが含まれている中央ストアへのアクセスを管理します。
  • セルフサービスアカウント - パスワードリセットとアカウントのロック解除の権限を持つActive Directoryアカウントです。

SSPRアーキテクチャイメージ

また、セルフサービスパスワードリセットを適切に設計するには、ユーザーが回答するセキュリティの質問を管理者が作成する必要があります。管理者がさまざまなカテゴリに関する質問のグループを作成し、ユーザーに各グループの質問のサブセットに答えるよう求めるのが理想的です。質問は、変わることがなく、他の人に知られておらず、ユーザー自身が知っているものにする必要があります。

ユーザープロファイル

ユーザーのプロファイルは、仮想デスクトップまたは仮想アプリケーションのシナリオ内で常にポジティブなエクスペリエンスを提供するために重要な役割を果たします。適切に設計された仮想デスクトップソリューションでも、ログオン時間が長かったり、設定が失われたりするためにユーザーが不満を感じると、優れたエクスペリエンスを提供できない可能性があります。

選択されたユーザープロファイルソリューションは、評価フェーズでキャプチャされたユーザーグループの個人設定特性や、選択されたVDIモデルと適合している必要があります。

決定事項:プロファイルタイプ

このセクションでは、利用可能なさまざまなプロファイルタイプの概要と、各VDIモデルに対して最適なユーザープロファイルに関するガイダンスが提供されています。

  • ローカルプロファイル - ローカルプロファイルは各サーバーまたはデスクトップオペレーティングシステムに保存され、最初はデフォルトのユーザープロファイルに基づいて作成されます。そのため、これらのリソースにアクセスするユーザーは、各システムで独自のプロファイルを作成します。ユーザーは各システムでローカルプロファイルへの変更を保持できますが、変更にはそのシステム上の今後のセッションでのみアクセスできます。ローカルプロファイルは構成が不要です。サーバーまたはデスクトップオペレーティングシステムにログインしているユーザーに管理者が定義したプロファイルパスがない場合は、デフォルトでローカルプロファイルが作成されます。
  • 移動プロファイル - 移動プロファイルは、各ユーザーの中央ネットワークリポジトリに保存されます。移動プロファイルは、プロファイル内の情報(プリンター、レジストリ設定、ドキュメントフォルダーに格納されているファイル)を環境内のすべてのシステムからアクセスされるユーザーセッションで利用可能にできる点で、ローカルプロファイルと異なります。移動プロファイル用のユーザーを構成するには、管理者がユーザーの(仮想デスクトップ用)プロファイルパス、または特定のネットワーク共有へのターミナルサーバープロファイルパスを指定する必要があります。サーバーまたはデスクトップオペレーティングシステムへのユーザーの初回ログオン時には、ユーザーの移動プロファイルの作成にデフォルトユーザープロファイルが使用されます。ログオフ時に、プロファイルは管理者が指定したネットワークの場所にコピーされます。
  • 固定プロファイル - 通常、固定プロファイルは多くのユーザーにとって中央の場所に保存されます。ただし、ユーザーの変更はログオフ時に保持されません。固定プロファイル用のユーザーを構成するには、管理者が固定プロファイルファイル(NTUSER.MAN)を既存の移動プロファイルまたはローカルプロファイルから作成し、ターミナルサービスプロファイルパスをユーザーに割り当てる必要があります。この処理は、Microsoftグループポリシーを使用し、Active DirectoryまたはCitrix Profile Managementでユーザープロパティをカスタマイズすることによって実行できます。

  • ハイブリッドプロファイル - ハイブリッドプロファイルでは、堅牢なプロファイルコア(固定プロファイルまたはローカルデフォルトプロファイル)と、ログオン時にマージされるユーザー固有のレジストリキーまたはファイルが組み合わされます。この手法により、管理者が保持される変更を厳密に管理し、ユーザープロファイルのサイズを小さく維持することができます。さらに、ハイブリッドプロファイルは、別のセッションで行われた変更を上書きする可能性がある同時書き込みを自動的に検出して防止する成熟したキューイング技術を使用して、最後の書き込みが優先される問題を解決します。これにより、複数のサーバーまたは仮想デスクトップに同時にアクセスする場合にプロファイルの変更が失われることによるユーザーのストレスが最小限に抑えられます。また、ログオフ時にプロファイル全体を書き込むのではなく、プロファイル内の変更のみをキャプチャして記録します。ハイブリッドプロファイルソリューションの良い例が、Citrix Profile Managementです。これについては、この章で詳しく説明します。

下の表は、各プロファイルタイプの機能を比較したものです。

表中の表記:

  • Yは、利用可能な機能を示しています。
  • oは、オプションを示しています。
  • Nは、利用できない機能を示しています。
機能 ローカル 移動 固定 ハイブリッド
集中管理/ユーザーとともに移動 N Y o はい
ユーザー設定が永続的に保存される Y Y N はい
ユーザー設定の詳細なキャプチャ N N N はい

各ユーザーグループに最適なプロファイルタイプを選択するには、割り当てられたVDIモデルに加えて、それぞれの個人設定要件を理解することが重要です。

次の表に、VDIリソースに基づいて適切なユーザープロファイルタイプを選択する場合の推奨事項を示します:

表中の表記:

  • Yは、推奨されていることを示しています。
  • Xは、非推奨であることを示しています。
  • oは、実行可能であることを示しています。

ユーザー設定の永続性が必要(個人設定特性:基本/完全)

ローカル 移動 固定 ハイブリッド  
ホストされたWindowsアプリ X Y X Y
ホストされたブラウザーアプリ X Y X Y
ホストされた共有デスクトップ X Y X Y
ホストされたプールデスクトップ X Y X Y
ホストされた個人用デスクトップ º Y X Y
ホストされたプログラフィックデスクトップ º Y X Y
ローカルストリーミングデスクトップ X Y X Y
ローカル仮想マシンデスクトップ Y º X º
リモートPCアクセス Y º X º

ユーザー設定の永続性が不要または推奨(個人設定特性:なし)

ローカル 移動 固定 ハイブリッド  
ホストされたWindowsアプリ X X Y X
ホストされたブラウザーアプリ X X Y X
ホストされた共有デスクトップ X X Y X
ホストされたプールデスクトップ Y X Y X
ホストされた個人用デスクトップ X X Y X
ホストされたプログラフィックデスクトップ º X Y X
ローカルストリーミングデスクトップ Y X Y X
ローカル仮想マシンデスクトップ º X Y X
リモートPCアクセス º X Y X

決定事項:フォルダーのリダイレクト

特別なフォルダーをリダイレクトすることで、前述のプロファイルタイプを補完することができます。ユーザードキュメントやお気に入りなどのプロファイルフォルダーをネットワーク共有にリダイレクトすることはプロファイルサイズを最小化するために推奨されますが、アプリケーションがAppDataなどのプロファイルフォルダーとの間で頻繁にデータを読み書きする場合があるため、ファイルサーバーの使用率や応答性の問題が発生する可能性があることを設計者が認識しておく必要があります。これらの問題を回避するには、実稼働環境に実装する前にプロファイルのリダイレクトを徹底的にテストすることが重要です。したがって、実稼働環境に移行する前に、プロファイルの読み取りと書き込みのアクティビティを調査し、パイロットを実行することが重要です。Microsoft Outlookは、メールが作成されるたびにユーザーの署名がユーザープロファイルから読み取られるため、プロファイルの読み取りアクティビティを定期的に実行するアプリケーションの一例です。

次の表は、リダイレクトする適切なフォルダーを特定するのに役立つ一般的な推奨事項を示しています:

表中の表記:

  • Yは、推奨されていることを示しています。
  • Xは、非推奨であることを示しています。
  • oは、実行可能であることを示しています。
フォルダー ローカル 移動 固定 ハイブリッド
アプリケーション データ X o X o
アドレス帳 X Y X o
デスクトップ X Y X o
ダウンロード X o X o
お気に入り o Y o Y
リンク X Y X o
マイドキュメント o Y o Y
マイ ミュージック o Y o o
マイピクチャ o Y o o
マイ ビデオ o Y o o
保存したゲーム X o X o
検索 X Y X o
スタートメニュー X X X X

決定事項:フォルダー除外

移動プロファイルまたはハイブリッドプロファイルの一部としての永続的な保存からフォルダーを除外すると、プロファイルのサイズとログオン時間の削減につながります。デフォルトで、WindowsではAppData\LocalフォルダーとAppData\LocalLowフォルダーが除外されます。これには、履歴、一時ファイル、インターネット一時ファイルなどのすべてのサブフォルダーが含まれます。また、ダウンロードフォルダーと保存したゲームフォルダーも除外されます。リダイレクトされるフォルダーはすべて、プロファイルソリューションから除外されます。

決定事項:プロファイルキャッシュ

サーバーまたは仮想デスクトップ上の移動ユーザープロファイルまたはハイブリッドユーザープロファイルのローカルキャッシュはWindowsのデフォルト動作であり、ログイン時間とファイルサーバーの使用率およびネットワークトラフィックの削減につながります。プロファイルキャッシュを使用すると、システムでプロファイルの変更をダウンロードするだけで済みます。プロファイルキャッシュのマイナス面は、ホストされる共有デスクトップホストなど、マルチユーザーシステムで大量のローカルディスク記憶域が消費される可能性があることです。

特定のVDIモデルおよび構成では、VDIリソースが初期状態にリセットされます。ローカルにキャッシュされたプロファイルがログオフ時に削除されると、リソースが不要に消費されます。そのため、一般的に、次のVDIモデルではローカルでキャッシュされたプロファイルを削除しないことが推奨されています:

  • ホストされる個人用デスクトップ
  • ホストされるプールデスクトップ - ログオフ後に再起動が行われる状況のみ
  • ローカル仮想マシンデスクトップ
  • リモートPCアクセス

[キャッシュしたプロファイルを削除する前の待ち時間]Citrixポリシーを構成すると、オプションとして、ローカルにキャッシュされたプロファイルがログオフ時に削除される前の待ち時間が設定されます。ログオフ時にファイルやレジストリハイブにアクセスするプロセスがある場合は、ここで待機時間を延長できます。これにより、大きなプロファイルのログオフ時間も短縮できます。

決定事項:プロファイル権限

セキュリティ上の理由により、管理者はデフォルトではユーザープロファイルにアクセスできません。このレベルのセキュリティは、非常に機密性の高いデータを扱う組織には必要な場合がありますが、多くの環境では不要であり、運用と保守が複雑になる可能性があります。そのため、[管理者セキュリティグループを移動ユーザープロファイルに追加する]ポリシー設定を有効にすることを検討してください。このポリシーの構成は、評価フェーズでキャプチャされたユーザーグループのセキュリティ特性と一致する必要があります。ユーザープロファイルとデータをホストしているファイル共有に必要な権限について詳しくは、Microsoft TechNet -「Deploying Roaming Profiles」を参照してください。

決定事項:プロファイルパス

ユーザープロファイルのネットワークパスの決定は、ユーザープロファイルの設計プロセスにおける最も重要な決定事項の1つです。一般的に、冗長で高性能のファイルサーバーまたはNASデバイスを利用することを強くお勧めします。 プロファイル共有については、次の4点に考慮する必要があります:

  • パフォーマンス - ファイルサーバーのパフォーマンスはログオン時間とログオフ時間に影響し、リダイレクトされたフォルダーやプロファイルストリーミングなどの他の決定事項によっては、セッション内のユーザーエクスペリエンスに影響を及ぼす可能性があります。大規模なVDIの場合、単一のファイルサーバークラスターではピーク時のアクティビティを処理するのに十分ではない可能性があります。負荷を複数のファイルサーバーに分散するには、ファイルサーバーアドレスおよび共有名を調整する必要があります。
  • 場所 - ユーザープロファイルは、SMBプロトコルを使用してネットワーク経由で転送されます。遅延時間が長いネットワーク接続では、パフォーマンスが低くなります。また通常、WAN接続では帯域幅が制限されているため、プロファイルのロードプロセスにさらに時間がかかる可能性があります。したがって、ファイルサーバーは、ログオン時間を最小限に抑えるため、サーバーと仮想デスクトップのすぐ近くに配置することが望ましいです。
  • オペレーティングシステムプラットフォーム - ユーザープロファイルは基盤となるオペレーティングシステムと緊密に統合されており、単一のユーザープロファイルを異なるオペレーティングシステムや異なるプラットフォーム(64ビット(x64)と32ビット(x86)など)で再利用することはサポートされていません。

詳しくは、Microsoftのナレッジベース記事KB2384951 - 「Sharing 32 and 64-bit User Profiles」を参照してください。Windows 2008およびWindows Vistaでは、新しいユーザープロファイル構造が導入されました。これは、プロファイルディレクトリのサフィックス.V2によって識別できます。これにより、古いユーザープロファイルはWindows 2012、7、8などの新しいオペレーティングシステムとの互換性がなくなります。プラットフォームごとに別のプロファイルが使用されるようにするには、プロファイルディレクトリを調整する必要があります。

  • インデックス機能 - ユーザーのリダイレクトされたデータに対してWindows Search機能を最大限に活用するには、NASアプライアンス上の共有ではなく、ユーザーのデータにインデックスを付けるWindowsファイルサーバーを使用する必要があります。これは、Windows Searchに大きく依存しているか、低速や遅延の体感に特に敏感なユースケースで重要です。

Windowsの組み込み技術に基づくこれらの課題の解決方法には、次の2つがあります:

  • ユーザーオブジェクト - Active Directory内のすべてのユーザーオブジェクトに対して、ファイルサーバー名とプロファイルディレクトリを含む個別のプロファイルパスを指定できます。各ユーザーオブジェクトに対して1つのプロファイルパスのみを指定できるため、オペレーティングシステムプラットフォームごとに個別のプロファイルを確実に読み込むことはできません。
  • コンピューターグループポリシーまたはシステム変数 - ユーザープロファイルパスの構成には、コンピューター固有のグループポリシーまたはシステム変数も使用できます。これにより、管理者はユーザープロファイルをプラットフォーム専用にすることができます。コンピューター固有の構成はシステムのすべてのユーザーに影響するため、すべてのユーザープロファイルが同じファイルサーバーに書き込まれます。複数のサーバー間でユーザープロファイルの負荷を分散するには、ファイルサーバーごとに専用のXenDesktopデリバリーグループを作成する必要があります。

:Microsoftは、アクティブに使用されているユーザープロファイルに対し、DFS-NとDFS-Rを組み合わせて使用することをサポートしていません。

詳しくは、Microsoftの次の記事を参照してください:

Citrix Profile Managementを使用する場合、これらの課題を解決するための3つ目のオプションがあります:

ユーザーオブジェクトの属性と変数 - Citrix Profile Managementにより、管理者がActive Directoryにおけるユーザーオブジェクトのコンピューターグループポリシーに基づいてプロファイルパスを構成し、ファイルサーバーを動的に指定することができます。そのために、次の3つの手順を実行する必要があります:

  1. 実際のファイルサーバーを参照するDNSエイリアス(fileserver1など)の作成
  2. ユーザーオブジェクトの空のLDAP属性(lやUIDなど)へのDNSエイリアスの入力
  3. LDAP属性を参照するプロファイルパスを使用するためのGPOを使用したCitrix Profile Managementの構成(たとえば、属性UIDが使用される場合、プロファイルパスは\#UlD\#\Profiles\profiledirectoryになります)

さらに、Citrix Profile Managementでは、オペレーティングシステムプラットフォームに基づいてプロファイルパスを動的に指定するための変数が自動入力されます。Profile Managementの有効な変数は、以下のとおりです:

  • !CTX_PROFILEVER! - プロファイルバージョンに応じてv1またはv2に展開されます。
  • !CTX_OSBITNESS! - オペレーティングシステムのビットレベルに応じてx86またはx64に展開されます。
  • !CTX_OSNAME! - Windows 7など、オペレーティングシステムの短い名前に展開されます。

Citrix Profile Managementの両方の機能を組み合わせることで、完全に動的なユーザープロファイルパスを作成できます。これは、複数のファイルサーバー間で負荷分散でき、異なるオペレーティングシステムプラットフォームのプロファイルが混在しないようにします。完全に動的なユーザープロファイルパスの例を以下に示します:

\#UID#\profiles$%USERNAME%.%USERDOMAIN%\!CTX_OSNAME!!CTX_OSBITNESS!

決定事項:プロファイルストリーミング

:次の設計上の決定は、Citrix Profile Managementを使用する環境にのみ適用されます。

ユーザープロファイルストリーミングを使用する場合、プロファイルに含まれるファイルやフォルダーにユーザーがアクセスすると、それらがユーザーストア(ファイルサーバー)からローカルコンピューターにフェッチされます。ログオンプロセス中に、Citrix Profile Managementはプロファイルのロードプロセスが完了したことを即時にレポートするため、プロファイルロード時間がほぼゼロに削減されます。

すべてのシナリオで、プロファイルストリーミングを有効にすることをお勧めします。パフォーマンス上の理由により、ローカルにキャッシュされたユーザープロファイルのコピーを保持する必要がある場合は、[常時キャッシュ]設定を有効にし、サイズを0に構成することをお勧めします。これにより、ユーザープロファイルがバックグラウンドでダウンロードされ、このキャッシュされたコピーをシステムで今後も使用できるようになります。

実際の例

  • 一般 - AppDataがすでにVDIリソースにストリーミングされている場合、品質の低いアプリケーションのロード時間が短縮される可能性があります。プロファイルストリーミングの[常時キャッシュ]オプションを有効にすると、AppDataフォルダーがリダイレクトされない場合のパフォーマンスが向上する可能性があります。

決定事項:アクティブライトバック

:次の設計上の決定は、Citrix Profile Managementを使用する環境にのみ適用されます。

アクティブライトバック機能を有効にすることで、Citrix Profile Managerでアプリケーションがファイルを書き込んで閉じたことを検出し、アイドル期間中にそのファイルをプロファイルのネットワークコピーにコピーして戻します。1人のユーザーが複数の仮想デスクトップまたはホストされる共有デスクトップを同時に利用するシナリオでは、この機能は非常に有用です。ただし、Citrix Profile Managementでは、所定のログオフ中を除き、レジストリの変更をネットワークにコピーしません。そのため、ローカルでキャッシュされたプロファイル情報が再起動時に消去される非永続システムでは、レジストリとファイルの整合性が失われるリスクがあります。したがって、非永続シナリオではアクティブライトバック機能を無効にすることをお勧めします。

決定事項:構成アプローチ

:次の設計上の決定は、Citrix Profile Managementを使用する環境にのみ適用されます。

Citrix Profile Managementは、「.ini」ファイル、Microsoftグループポリシー、およびCitrixポリシー(Citrix Profile Management 5.0以降)を使用して構成できます。各オプションで同じ構成設定が提供されますが、管理者がWindowsとCitrixのプロファイル構成を1か所で実行でき、プロファイル管理に必要なツールを最小限に抑えることができるため、グループポリシーが推奨されています。

:Citrix Profile Management 5.0以降では、デスクトップタイプが自動で検出され、それに応じてCitrix Profile Managementポリシーが設定されます。詳しくは、Citrix Docs - 「How automatic configuration works」を参照してください。

決定事項:レプリケーション

ネットワークレベルでのアクティブ/アクティブデータセンターはGSLBで容易に実現できますが、ユーザーデータのレプリケーションを行うと、多くの状況で完全なアクティブ/アクティブ環境の実現は複雑になります。ユーザーが特定のデータセンターに静的に割り当てられないアクティブ/アクティブ構成では、ユーザーに個人設定の要件がない必要があります。これにより、ユーザーによる構成変更が制限され、ドキュメントや永続データを作成することができなくなります。これに対する例外は、 高速で遅延の少ないダークファイバーなどの接続をデータセンター間で利用できる場合です。これにより、両方の場所にあるリソースが同じファイルサーバーをポイントできるようになり、真のアクティブ/アクティブソリューションが実現します。また、データセンター間でアクティブに複製されるバックエンドデータベースのみに依存し、ユーザープロファイルにデータを保存しないアプリケーションを使用する場合も、アクティブ/アクティブ構成を実現できます。

冗長性とフェールオーバーのために、Windowsプロファイルやドキュメントなどのユーザーデータはデータセンター間で同期する必要があります。データセンター間でユーザーデータを複製することをお勧めしますが、複製はアクティブ/パッシブ構成になります。つまり、データは1つのデータセンターからのみアクティブに使用できます。この制限は、Windows内の分散ファイルロック方式によるもので、1人のユーザーしかファイルへのアクティブな書き込みができないためです。したがって、ユーザーデータのアクティブ/アクティブレプリケーションはサポートされていません。サポートされている構成は、常に単一のデータセンターでアクティブなデータの一方向レプリケーションを含みます。

たとえば、次の図は、ユーザーデータがデータセンターAからデータセンターBにパッシブに複製されるシナリオを示しています。この例では、ファイルサーバーAがデータセンターAにおけるユーザーデータのプライマリの場所で、ファイルサーバーBがデータセンターBのプライマリの場所です。フェールオーバーが発生した場合にユーザーデータを他方のデータセンターで利用できるよう、ユーザーデータの一方向レプリケーションが各ファイルサーバーに対して行われます。Microsoft DFSなどのレプリケーションテクノロジは、ユーザープロファイルとドキュメントを別のデータセンターのファイルサーバーにミラーリングするよう構成できます。DFS名前空間を使用して、ユーザーデータの場所に対するシームレスなパスを設定することもできます。ただし、このようなレプリケーションソリューションを実装するには、Microsoft DFSとユーザープロファイルに精通している管理者が必要です。

データセンターの画像

ユーザーデータ

ユーザーが効果的に作業するには、自分のデータにアクセスする必要があります。ユーザーエクスペリエンスを改善するには、データがユーザーのアプリケーションに近い場所に存在する必要があります。アプリケーションとデータの距離が長くなると、遅延が長くなり、すべてのファイル操作(開く、保存、変更)が遅くなります。

VDIベースの環境では、ユーザーがデータを保存する場所およびアクセスの影響を管理者が理解している必要があります。

決定事項:ユーザーデータの場所

従来、ユーザーはローカルデバイスまたはドライブマッピングで指定されたネットワークファイルサーバーにデータを保存していました。ITの記憶域の制限や他のモバイルデバイスにデータを引き継げないことにより、ユーザーはOneDrive、DropBox、Boxなどの無料のクラウドベースストレージサービスを使用するようになりました。データにアクセスするため、ユーザーはストレージベンダーのエージェントを従来型のWindows PCにインストールし、クラウドでホストされたストレージリポジトリに直接アクセスできるようにしていました。

管理者は、次の点を検討し、ユーザーのストレージを考慮しながらソリューションを設計する必要があります:

  • マルチエージェント方針 - VDIでは、ユーザーが管理者に各ストレージプロバイダーのエージェントのインストールと構成を依頼します。ストレージエージェントが非永続VDIモデルをサポートしていることが前提とされています。各エージェントは、管理者が管理および保守する必要がある新しいアプリケーションです。
  • ストレージコネクタ方針 - 単一のエージェントで、多数のクラウドホストプロバイダーおよびオンプレミスプロバイダーのストレージリポジトリを単一のフォルダー構造に統合します。たとえば、ユーザーがCitrix ShareFileに接続すると、クラウド(ShareFile、OneDrive、DropBox、Box、Googleドライブ)およびオンプレミス(SharePoint、Windowsネットワーク共有、ローカルエンドポイント共有)からのユーザーデータを含む統合フォルダー構造が表示されます。

決定事項:ユーザーデータアクセス

VDIソリューションの重要な成功要素は、ユーザーエクスペリエンスが従来のPCと同じであることです。ユーザーがアプリケーション内でファイルを開く場合に、その機能が停止しない必要があります。ユーザーがエクスプローラーを使用してファイルにアクセスした場合に、その機能が停止しない必要があります。

ユーザーのデータはローカルPCに存在する場合も、ネットワークファイル共有に存在する場合も、クラウドでホストされている場合もあります。

日付ストレージの場所のイメージ

ローカルPCでは、ユーザーがオンプレミスネットワーク共有とクラウドホストストレージのオプションを利用できます。管理者は、データにアクセスするユーザーがインフラストラクチャとVDIのエクスペリエンスに与える影響を理解する必要があります。

  • 直接データアクセス - ユーザーがリモートサーバー(オンプレミスWindowsサーバーまたはクラウドホスト記憶域プロバイダー)でファイルにアクセスします。アプリケーションとファイルの距離は、エクスペリエンスに直接影響します。距離が長いほど、遅延が長くなります。各ファイル操作(移動、開く、閉じる、保存など)にかかる時間は、アプリケーションとファイルストレージの間の遅延が増加するにつれて長くなります。多くの場合、WindowsファイルサーバーはユーザーのVDIデスクトップと同じデータセンターにあるため、直接データアクセスが可能です。ただし、VDIデスクトップとストレージリポジトリの接続で遅延が長くなると、クラウドホストソリューションおよびローカルPCへのアクセス時に応答時間が長くなります。
  • ローカル同期 - 従来のPCでは、ユーザーがファイルをローカルに保存することに慣れています。この場合、遅延が非常に短いため、アプリケーションの応答時間が長くても大きな問題にはなりません。多くのクラウドホストソリューションでは、データ同期が提供されており、ローカルストレージモデルと同様のアクセス速度が実現しています。多くのクラウドホストソリューションで、完全同期か、または特定のフォルダーとファイルを対象にしてユーザーが構成する部分同期が提供されています。部分同期では、同期されたファイルのみがデバイス上で表示され、アクセス可能になるため、ユーザーが混乱します。完全同期と部分同期は、VDIコストを増加させます。各セッションは、ユーザーのフォルダーとファイルの同期を必要とする完全に新しいデスクトップであり、時間、ネットワーク帯域幅、およびVDI記憶域が消費されます。VDIデスクトップに同期されているすべてのファイルを、VDIセッションの開始から終了まで組織のデータセンター内に保存する必要があります。
  • オンデマンド同期 - ファイルやフォルダーがデスクトップ上に物理的には存在しない場合でも、エクスプローラーではファイルとフォルダーの完全な仮想構造が表示されます。ファイルを選択すると、その単一ファイルを対象とするVDIデスクトップへの自動同期が開始されます。この時点で、ファイルにローカルでアクセスできるため、従来のPCと同様のユーザーエクスペリエンスが実現します。ユーザーがファイルを保存するか閉じると、ファイルがクラウドと同期されます。アクセスされたファイルのみが同期されるため、ローカルデータアクセスモデルで発生する無駄がなくなります。Citrix ShareFileにはDrive Mapperが含まれているため、ユーザーはエクスプローラーからデータを操作しながら、ファイルへのアクセス時にはオンデマンド同期を利用することができます。アクセスされたファイルのみが同期されるため、基盤となるストレージインフラストラクチャおよび関連するストレージに関するコストへの影響は最小限です。

表中の表記:

  • Yは、推奨されていることを示しています。
  • Nは、非推奨であることを示しています。
  直接データアクセス ローカル同期 オンデマンド同期
ネットワークファイルサーバー Y    
クラウドホスト N N Y
ローカルPC N N Y

決定事項:データ復旧

ファイルの破損は、多くのユーザーが経験する問題です。アプリケーションやPCを不適切にシャットダウンする(アプリケーションを閉じてオペレーティングシステムを正常にシャットダウンするのではなく、電源ボタンを押す)と、破損に関する問題が頻繁に発生します。

ユーザーが利用できるデータ復旧オプションがいくつかあります:

  • 複数ファイル - 従来のPCでは、ローカルファイルの復旧オプションは限られています。多くのユーザーは、データをある程度復旧させるため、毎日手動でファイルのコピーを新規作成しています。この解決策は、管理が困難です。
  • バックアップと復元 - 管理者は、ファイルの復旧に役立つバックアップおよび復元用のソリューションを実装できます。ただし、これらのソリューションはローカルファイルにはほぼ使用できず、ネットワークファイル共有についてもバックアッププロセスは通常は夜間または週に一度しか実行されません。また、破損したファイルを復元するには、ユーザーがサポートに連絡する必要があります。
  • バージョン管理 – Citrix ShareFileなどのクラウドホストオプションには、ファイルのバージョン管理が含まれています。これにより、変更が保存されると新しいバージョンのファイルが自動的に作成されます。バージョン管理はユーザーの介入を必要とせず、ユーザーはデータをほぼ失うことなく短時間で破損を回復することができます。

Sharefileバージョン管理イメージ

ポリシー

ポリシーは、XenAppおよびXenDesktop環境を構成および微調整するための基盤となり、組織がユーザー、デバイス、または接続の種類のさまざまな組み合わせに基づいて接続、セキュリティ、および帯域幅の設定を管理できるようにします。

ポリシーの決定時には、すべてのユーザーエクスペリエンス、セキュリティ、および最適化設定が考慮されるよう、MicrosoftとCitrixの両方のポリシーを考慮することが重要です。Citrix関連ポリシーの一覧については、「Citrixポリシー設定リファレンス」を参照してください。

決定事項:優先ポリシーエンジン

組織は、Citrix Studioか、またはActive DirectoryグループポリシーからCitrix ADMXファイルを使用して、Citrixポリシーを構成することができます。Citrix ADMXファイルにより、グループポリシーが拡張され、高度なフィルタリングメカニズムが提供されます。

Active Directoryグループポリシーを使用した場合、組織はWindowsポリシーとCitrixポリシーの両方を同じ場所で管理でき、ポリシー管理に必要な管理ツールの数を最小限に抑えることができます。グループポリシーはドメインコントローラー間で自動的に複製され、情報を保護し、ポリシーの適用を簡素化します。

Citrixの管理者がActive Directoryポリシーにアクセスできない場合は、Citrix管理コンソールを使用します。設計者は、組織のニーズに応じて上記2つのうちいずれかの方法を選択し、Citrixポリシーの場所が複数存在することによる混乱を避けるため、その方法を一貫して使用する必要があります。

ポリシーの結果セットの作成方法を理解するため、ポリシー優先順位と呼ばれるポリシーのアグリゲーションのフローを理解することが重要です。Active DirectoryおよびCitrixポリシーでは、優先順位は次のようになります:

ポリシー優先順位 ポリシーの種類
最初に処理される(最低優先順位) ローカルサーバーポリシー
2番目に処理される Citrix管理コンソールを使用して作成されたCitrixポリシー
3番目に処理される サイトレベルのADポリシー
4番目に処理される ドメインレベルのADポリシー
5番目に処理される ドメイン内の最高レベルOU
6番目以降に処理される ドメイン内の次のレベルのOU
最後に処理される(最高優先順位) オブジェクトを含む最下位レベルのOU

各レベルのポリシーは、ユーザーまたはコンピューターに適用される最終ポリシーにアグリゲートされます。多くのエンタープライズ展開で、Citrix管理者には、通常は最高優先順位レベルになる各管理者のOU外のポリシーを変更する権限がありません。例外が必要な場合は、OUツリーの上位からのポリシー設定の適用を[継承のブロック]および[上書きなし]設定を使用して管理できます。[継承のブロック]により、上位レベルOU(下位優先順位)からの設定がポリシーに統合されなくなります。ただし、上位レベルOUポリシーが[上書きなし]で構成されている場合、[継承のブロック]設定は適用されません。そのため、ポリシーの計画には注意を払う必要があり、「Active Directoryポリシーの結果セット」ツールや「Citrixグループポリシーモデル作成」ウィザードなどの利用可能なツールを使用し、確認された結果を予測された結果と比較して検証する必要があります。

いくつかのCitrixポリシー設定は、VDAを登録するために必要であるため、使用する場合はControllerやController登録ポートなどのActive Directoryグループポリシーを使用して構成する必要があります。

決定事項:ポリシー統合

ポリシーの構成時に、多くの組織では、完全に構成された環境を作成するためにActive DirectoryポリシーとCitrixポリシーの両方が必要になります。両方のポリシーセットを使用すると、ポリシーの結果セットの特定が難しくなる可能性があります。場合によっては、特にWindowsリモートデスクトップサービス(RDS)およびCitrixポリシーに関して、2つの異なる場所で類似する機能を構成できます。たとえば、Citrixポリシーではクライアントドライブマッピングを有効にし、RDSポリシーではクライアントドライブマッピングを無効にすることができます。希望する機能を使用できるかどうかは、RDSとCitrixのポリシーの組み合わせに依存する場合があります。Citrixポリシーは、リモートデスクトップサービスで利用可能な機能に基づいていることを理解することが重要です。必要な機能がRDSポリシーで明示的に無効化されている場合、基盤となる機能が無効化されているため、Citrixポリシーは構成に影響しません。

この混乱を避けるため、RDSポリシーは必要性に応じ、XenAppおよびXenDesktop構成に対応するポリシーが存在しないか、組織内でRDSを使用するための構成が特に必要である場合にのみ構成することをお勧めします。最小限のポリシーを構成することで、ポリシーの結果セットおよびトラブルシューティングポリシーの構成を理解しやすくなります。

決定事項:ポリシースコープ

作成したポリシーは、求められる結果に基づき、ユーザーやコンピューターのグループに適用する必要があります。ポリシーフィルタリングにより、必要なユーザーまたはコンピューターグループに対してポリシーを適用することができます。Active Directoryベースのポリシーでは、サイト、ドメイン、または組織単位(UI)オブジェクト内でコンピューターとユーザーのどちらにポリシーを適用するのかが重要な決定事項になります。Active Directoryポリシーは、ユーザー構成とコンピューター構成に分類されます。デフォルトでは、ユーザー構成内の設定はログオン時にOU内に属するユーザーに適用されます。一方、コンピューター構成内の設定はシステム起動時にコンピューターに適用され、システムにログオンするすべてのユーザーに影響します。Active DirectoryおよびCitrixの展開とポリシーの関係について、次の3つのコア領域に関する課題があります:

  • Citrix環境固有のコンピューターポリシー - 多くの場合、Citrixサーバーおよび仮想デスクトップには、この環境専用に作成および展開されたコンピューターポリシーがあります。これらのポリシーは、サーバーと仮想デスクトップ用に個別のOU構造を作成することで容易に適用できます。その場合、特定のポリシーを作成し、OU内およびその下位のコンピューターにのみ確実に適用することができます。要件に基づき、サーバーの役割、地理的な場所、または事業単位に基づき、仮想デスクトップおよびサーバーをOU構造内でさらに細分化することもできます。
  • Citrix固有のユーザーポリシー - XenAppおよびXenDesktopに対するポリシーの作成時には、ユーザーの接続に基づいて適用されるユーザーエクスペリエンスおよびセキュリティ固有のポリシーが多数あります。ただし、ユーザーのアカウントはActive Directory構造内のどこにあるか分からないため、ユーザー構成ベースのポリシーをシンプルに適用するのは困難です。設定はユーザーがログオンするすべてのシステムに適用されるため、ドメインレベルでCitrix固有の構成を適用することは望ましくありません。Citrixサーバーまたは仮想デスクトップがあるOUにユーザー構成設定を適用するだけでは、ユーザーアカウントがそのOU内に存在しないため、うまくいきません。この問題を解決するには、ループバックポリシーを適用します。これは、Active Directory内のユーザーの場所に関係なく、サーバーまたは仮想デスクトップにログオンするすべてのユーザーに対し、OUの割り当てられたユーザー構成ポリシーを適用するようコンピューターに強制するコンピューター構成ポリシーです。ループバック処理は、マージ設定と置換設定のいずれかを使用して適用できます。置換を使用する場合、Citrixサーバーまたは仮想デスクトップOUのポリシーにより、ユーザーのグループポリシーオブジェクト全体が上書きされます。マージでは、ユーザーのグループポリシーオブジェクトとCitrixサーバーまたはデスクトップOUのグループポリシーオブジェクトが統合されます。マージが使用された場合、コンピューターのグループポリシーオブジェクトはユーザーのグループポリシーオブジェクトの後に処理されるため、Citrix関連のOU設定が優先され、競合が発生した場合に適用されます。詳しくは、Microsoft TechNetの記事 - 「Understand User Group Policy Loopback Mode」を参照してください。
  • Active Directoryポリシーフィルタリング - より高度なケースでは、Citrix管理者などの少数のユーザーにポリシー設定を適用する必要性が生じる可能性があります。この場合、ポリシーはシステムにログオンするすべてのユーザーではなく一部のユーザーにのみ適用される必要があるため、ループバック処理は機能しません。Active Directoryポリシーフィルタリングを使用して、ポリシーが適用される特定のユーザーまたはユーザーグループを指定できます。特定の機能に対してポリシーを作成し、ポリシーフィルターを設定して、そのポリシーをCitrix管理者などのユーザーのグループにのみ適用することができます。ポリシーフィルタリングは、各ターゲットポリシーのセキュリティプロパティを使用して実行されます。

Citrix Studioを使用して作成されたCitrixポリシーには、固有のフィルター設定があります。これらの設定を使用して、グループポリシーを使用して対処できないポリシーフィルタリングの状況に対処できる場合があります。Citrixポリシーは、次のフィルターを任意に組み合わせて適用できます:

フィルター名 フィルターの説明 スコープ
アクセス制御 クライアントの接続時のアクセス制御条件に基づいてポリシーを適用します。たとえば、Citrix NetScaler Gatewayを介して接続しているユーザーに対して特定のポリシーを適用できます。 ユーザー設定
Citrix CloudBridge ユーザーセッションがCitrix CloudBridge経由で起動されたかどうかに基づいてポリシーを適用します。 ユーザー設定
クライアントのIPアドレス セッションへの接続に使用されるユーザーデバイスのIPv4またはIPv6アドレスに基づいてポリシーを適用します。予期しない結果を避けるため、IPv4アドレス範囲が使用されている場合には、このフィルターに注意を払う必要があります。 ユーザー設定
クライアント名 セッションへの接続に使用されるユーザーデバイスの名前に基づいてポリシーを適用します。 ユーザー設定
デリバリーグループ セッションを実行しているデスクトップのデリバリーグループメンバーシップに基づいてポリシーを適用します。 ユーザー設定
デリバリーグループの種類 セッションを実行しているマシンの種類に基づいてポリシーを適用します。たとえば、デスクトップがプールされたデスクトップか、専用デスクトップか、ストリーミングデスクトップかに応じて、異なるポリシーを設定できます。 ユーザーおよびコンピューター設定
組織単位 セッションを実行しているデスクトップまたはサーバーのOUに基づいてポリシーを適用します。 ユーザーおよびコンピューター設定
タグ セッションを実行しているデスクトップに適用されているタグに基づいてポリシーを適用します。タグは、XenDesktop環境の仮想デスクトップに追加し、デスクトップの検索やアクセス制限に使用できる文字列です。 ユーザーおよびコンピューター設定
ユーザーまたはグループ セッションに接続しているユーザーのActive Directoryグループメンバーシップに基づいてポリシーを適用します。 ユーザー設定

XenDesktop 7.xのCitrixポリシーでは、ユーザーレベルとコンピューターレベルで適用される設定のマージビューが提供されます。表24のスコープ列は、指定したフィルターがユーザー設定、コンピューター設定、その両方のうちどれに適用されるかを示しています。

決定事項:ベースラインポリシー

ベースラインポリシーには、組織内の多数のユーザーに対して高品位のエクスペリエンスを提供するために必要な一般的要素がすべて含まれていることが望ましいです。ベースラインポリシーは、ユーザーアクセスと、ユーザーグループ固有のアクセス要件に対処するために作成する必要がある場合がある例外の基準となります。できるだけシンプルなポリシー構造を作成し、ポリシーの結果セットを容易に特定することができるよう、ベースラインポリシーはできるだけ多くのユースケースをカバーするために包括的であり、優先順位は99などに最も低く設定されている必要があります(優先順位番号「1」が最高優先順位)。デフォルトポリシーとしてCitrixから提供されているフィルタリングされていないポリシーセットは、すべてのユーザーおよび接続に適用されるため、ベースラインポリシーの作成に使用できます。ベースライン構成では、望ましい動作を明示的に定義し、デフォルト設定が変更された場合の混乱を防ぐため、デフォルト値で構成される設定も含め、すべてのCitrixポリシー設定を有効にする必要があります。

Citrixポリシーテンプレートは、環境内でのエンドユーザーエクスペリエンスを効果的に管理するためのCitrixポリシーの構成に使用でき、ベースラインポリシーの初期開始ポイントとしても使用できます。テンプレートには、特定の環境またはネットワーク条件に対してパフォーマンスを最適化する事前構成済みの設定が含まれています。XenDesktopに含まれる組み込みのテンプレートは、以下のとおりです:

組み込みのテンプレート 説明
高品位ユーザーエクスペリエンス 高品質のオーディオ、グラフィック、およびビデオをユーザーに提供するための設定が含まれています。
高サーバースケーラビリティ 単一のサーバーでより多くのユーザーをホストしながら、最適なユーザーエクスペリエンスを提供するための設定が含まれています。
WANの最適帯域幅 接続の帯域幅が低いか、または遅延が長いユーザーに対して最適なエクスペリエンスを提供するための設定が含まれています。
セキュリティと制御 周辺デバイス、ドライブマッピング、ポートのリダイレクト、およびユーザーデバイス上のFlashアクセラレーションへのアクセスを無効にする設定が含まれています。

Citrixポリシーテンプレートについて詳しくは、Citrix Docs - 「Citrixポリシーテンプレートの管理」を参照してください。

ベースラインポリシー構成には、Windowsポリシーも含める必要があります。Windowsポリシーには、ユーザーエクスペリエンスを最適化し、XenDesktop環境では不要な機能を削除するユーザー固有の設定が反映されています。たとえば、これらの環境でオフになっている一般的な機能の1つにWindows Updateがあります。特にデスクトップやサーバーがストリーム配信される場合があり、非永続である仮想化環境では、Windows Updateによって処理とネットワークのオーバーヘッドが発生し、更新プロセスによって行われた変更は仮想デスクトップまたはアプリケーションサーバーの再起動後に保持されません。また多くの場合、組織はWindows Server Update Services(WSUS)を使用してWindows Updateを制御しています。このような場合、アップデートはマスターディスクに適用され、IT部門がスケジュールに従って有効化します。

上記の考慮事項に加えて、組織の最終ベースラインポリシーには、セキュリティ要件や一般的なネットワーク条件への対応、またはユーザーデバイスやユーザープロファイルの要件の管理を目的として作成された設定が含まれる場合があります:

印刷

Citrix XenAppとCitrix XenDesktopでは、さまざまな印刷ソリューションがサポートされています。適切な印刷ソリューションを計画し、正しく実装するには、利用可能なテクノロジとその利点および制限事項を理解することが重要です。

決定事項:プリンタープロビジョニング

XenAppまたはXenDesktopセッションの開始時におけるプリンターの作成プロセスを、プリンタープロビジョニングと呼びます。利用可能なアプローチは複数あります:

  • ユーザー追加 - ユーザーが手動でプリンターを追加できるようにすることで、プリンターを利便性に応じて柔軟に選択できるようになります。ネットワークベースのプリンターを手動で追加することの欠点は、ユーザーがプリンターのネットワーク名またはパスを知っている必要があることです。また、ネイティブプリンタードライバーがオペレーティングシステムにインストールされておらず、Citrixユニバーサルプリンタードライバーの互換性がないため、ユーザーが管理者のサポートを依頼する必要がある場合もあります。手動でプリンターを追加するのに最も適した状況は、次のとおりです:
    • ユーザーが、同じクライアントデバイス(ラップトップ、タブレット)を使用して異なる場所の間を移動する。
    • ユーザーが、プリンターの割り当てがほとんど変更されない割り当て済みのステーションまたはエリアで作業する。
    • 必要なプリンタードライバーをインストールするのに十分な権限がある個人用デスクトップをユーザーが持っている。
  • 自動作成 - 自動作成は、ユーザーセッションの開始時にクライアントデバイス上で利用可能なプリンターの一部またはすべての作成を試行する動的プロビジョニングの形式です。これには、ローカル接続プリンターとネットワークベースプリンターが含まれます。すべてのクライアントプリンターを自動作成すると、ログオンプロセスで各プリンターが列挙されるため、セッションログオン時間が長くなる可能性があります。
  • セッションベース - セッションプリンターは、各セッションの開始時にCitrixポリシーを使用してユーザーに割り当てられるネットワークベースプリンターのセットです。
    • 近接ベースのセッションプリンターは、IPサブネットによってフィルタリングされます。このポリシーで作成されるネットワークプリンターは、ユーザーのエンドポイントデバイスの場所によって異なる場合があります。近接プリンター機能は、ユーザーが同じエンドポイントデバイス(ラップトップ、タブレット)を使用して異なる場所の間を移動する場合、およびシンクライアントが使用されており、ネットワークベースプリンターに直接接続できない場合に推奨されます。
    • セッションプリンターは、[セッションプリンター]ポリシーまたは[プリンター割り当て]ポリシーを使用して割り当てることができます。[セッションプリンター]ポリシーは、ファーム、サイト、大規模グループ、またはOUのデフォルトプリンターの設定に使用することを目的としています。[プリンター割り当て] ポリシーは、大きなプリンターグループを複数のユーザーに割り当てるために使用されます。両方のポリシーが有効であり、構成されている場合、セッションプリンターは1つのリストにマージされます。
  • ユニバーサルプリンター - Citrixユニバーサルプリンターは、セッションの開始時に自動作成される汎用プリンターオブジェクトであり、印刷デバイスにはリンクされません。Citrixユニバーサルプリンターを使用する場合、ログオン時のクライアントプリンターの列挙が不要になるため、リソース負荷が軽減され、ユーザーが高速にログオンできるようになります。デフォルトでは、Citrixユニバーサルプリンターを使用するとクライアントのデフォルトプリンターで印刷が行われますが、動作を変更し、ユーザーが互換性のある任意のローカルプリンターまたはネットワークベースプリンターを選択できるようにすることができます。

Citrixユニバーサルプリンターは、次のようなシナリオに最適です:

  • ユーザーが、セッションごとに変化する可能性がある複数のローカルプリンターおよびネットワークベースプリンターにアクセスする必要がある。
  • ユーザーのログオンパフォーマンスが優先され、アプリケーション互換性のためにCitrixポリシー[プリンターの自動作成を待機する]を有効にする必要がある。
  • ユーザーが、Windowsベースのデバイスまたはシンクライアントから作業している。

Active Directoryグループポリシー、「Follow-me」中央印刷キューソリューション、その他のサードパーティ印刷管理ソリューションなど、プリンターのプロビジョニングに関するその他のオプションを使用して、Citrixセッションにプリンターをプロビジョニングできます。

決定事項:プリンタードライバー

XenAppおよびXenDesktopでのプリンタードライバーの管理は、特に何百台ものプリンターがある大規模環境では面倒なタスクになる可能性があります。XenAppとXenDesktopには、プリンタードライバー管理をサポートする手段がいくつかあります。

  • ユーザーインストール - XenAppまたはXenDesktopセッション内でのプリンターの追加時に、ネイティブプリンタードライバーを利用できない場合は、ユーザーがドライバーを手動でインストールできます。異なるリソースに多数の異なるプリンタードライバーがインストールされ、環境内で不整合が発生する可能性があります。印刷に関する問題のトラブルシューティングとプリンタードライバーのメンテナンスは、各ホストリソースに異なるプリンタードライバーのセットがインストールされている可能性があるため、非常に困難になる場合があります。整合性を確保し、サポートとトラブルシューティングを簡素化するため、ユーザーインストールドライバーは推奨されません。
  • 自動インストール - XenAppまたはXenDesktopセッション内でプリンターを接続すると、必要なプリンタードライバーがオペレーティングシステムにすでにインストールされているかどうかが確認されます。プリンタードライバーがインストールされていない場合、ネイティブプリンタードライバーがあればそれが自動でインストールされます。ユーザーが複数のエンドポイントおよび場所の間を移動すると、接続するたびに異なるホストリソースにアクセスする場合があるため、セッション間で不整合が発生する可能性があります。このような場合、印刷に関する問題のトラブルシューティングとプリンタードライバーのメンテナンスは、各ホストリソースに異なるプリンタードライバーのセットがインストールされている可能性があるため、非常に困難になる場合があります。整合性を確保し、サポートとトラブルシューティングを簡素化するため、自動インストールドライバーは推奨されません。
  • ユニバーサルプリンタードライバー – Citrixユニバーサルプリンタードライバー(UPD)は、デバイスに依存しないプリンタードライバーで、大部分のプリンターで機能するように設計されています。Citrixユニバーサルプリンタードライバー(UPD)は、マスターイメージで必要なドライバーの数を減らすことによって管理を簡素化します。自動作成クライアントプリンターの場合、ドライバーはエンドポイントデバイスをいっさい変更せずに、アプリケーションの出力を記録して送信します。エンドポイントでは、ローカルのデバイス固有ドライバーを使用してプリンターへのジョブの印刷を終了します。UPDをCitrixユニバーサルプリントサーバー(UPServer)と組み合わせて使用し、この機能をネットワークプリンターに拡張することができます。

決定事項:プリンターのルーティング

印刷ジョブは、クライアントデバイスやプリントサーバーを介し、さまざまなパスでルーティングされます。

  • クライアントデバイスルーティング - ローカル接続プリンター(USB、LPT、COM、TCPなどで接続されたプリンター)を使用するクライアントデバイスにより、印刷ジョブがクライアントデバイスからプリンターに直接ルーティングされます。
  • Windowsプリントサーバールーティング - デフォルトでは、自動作成されたネットワークベースプリンターに送信された印刷ジョブが、ユーザーのセッションからプリントサーバーにルーティングされます。ただし、次の条件のいずれかに該当する場合、印刷ジョブはクライアントデバイスを介してフォールバックルートをたどります:
    • セッションがプリントサーバーにアクセスできない
    • プリントサーバーが信頼が確立されていない別のドメインにある
    • ネイティブプリンタードライバーがユーザーのセッション内で利用できない
  • Citrixユニバーサルプリントサーバールーティング - ユーザーのセッションとCitrixユニバーサルプリントサーバーの間でユニバーサルプリンタードライバーが使用される点を除き、印刷ジョブのルーティングはWindowsプリントサーバールーティングと同じプロセスに従います。

印刷ジョブのルーティングに関する詳細は、プリンターのプロビジョニング方法に基づきます。自動作成プリンターとユーザー追加プリンターでは、次の図に基づいて印刷ジョブをルーティングできます:

印刷ジョブのルーティングの画像

ただし、プリンターがセッションプリンターとしてプロビジョニングされている場合、印刷ジョブのルーティングオプションはわずかに変わります。ユーザーのエンドポイントデバイスを介したジョブのルーティングはできなくなります。

セッションプリンターの画像

推奨されるオプションは、エンドポイントデバイスのネットワーク上の場所、ユーザーのセッション、およびプリントサーバーに基づきます。

  • クライアントデバイスルーティング
    • ローカル接続プリンターの実装に使用します。
    • Windowsエンドポイントデバイスとプリンターが、Windowsプリントサーバーと同じ高速の低遅延ネットワーク上にある場合に使用します。
  • Windowsプリントサーバールーティング
    • プリンターが、Windowsプリントサーバーおよびユーザーセッションと同じ高速の低遅延ネットワーク上にある場合に使用します。
  • Windowsプリントサーバールーティング(ユニバーサルプリントサーバーあり)
    • 非Windowsエンドポイントデバイスとプリンターが、Windowsプリントサーバーと同じ高速の低遅延ネットワーク上にある場合に使用します。

決定事項:プリントサーバーの冗長性

MicrosoftプリントサーバーまたはCitrixユニバーサルプリントサーバーを使用して管理されているネットワークベースプリンターは、単一障害点をなくすため、冗長性を構成する必要があります。Citrixユニバーサルプリントサーバーの冗長性は、Citrixポリシー内で定義する必要があります。

実際の例

ある印刷媒体会社が、シンクライアントおよびWindowsベースのワークステーションを本社で利用しています。ネットワークベースプリンターは、建物全体に配置されています(各階に1つ)。Windowsプリントサーバーはデータセンター内にあり、ネットワークプリンターを管理します。XenDesktopおよびXenAppサーバーもデータセンター内にあります。

地方オフィスには、ネットワーク接続プリンターを備えた多数のWindows、Linux、およびMacエンドポイントがあります。遠隔地の支社には、ローカル接続プリンターを備えたWindowsワークステーションがいくつかあります。

以下の3つの異なる印刷方法が適用されます:

  • 本社 - Citrixユニバーサルプリントサーバーが、XenAppおよびXenDesktopセッション内での印刷に使用されます。Windowsベースのワークステーションでは、ネイティブプリンタードライバーは必要ありません。階ごとにセッションプリンターポリシーが構成されており、各階のプリンターをデフォルトプリンターとして接続します。ポリシーは、近接プリンター機能のシンクライアントのサブネットに基づいてフィルタリングされます。QoS(サービス品質)ポリシーが実装されています。ポートTCP 1494およびTCP 2598上の送受信ネットワークトラフィックは、ほかのすべてのネットワークトラフィックよりも優先されます。これにより、HDXユーザーセッションが大きな印刷ジョブの影響を受けるのを防ぐことができます。
  • 地方オフィス - ユニバーサルプリントサーバーが、地方オフィス内に展開されています。印刷ジョブはユニバーサルプリンタードライバーを使用し、圧縮され、WANを介してユーザーのセッションからユニバーサルプリントサーバーに配信されます。その後、ジョブはオフィス内のネットワーク接続プリンターに送信されます。
  • 支社 - 支社のすべてのユーザーがWindowsベースのワークステーションを使用しているため、自動作成されたクライアントプリンターとCitrixユニバーサルプリンタードライバーが使用されます。印刷ジョブはICAを介して配信されるため、印刷データは圧縮され、帯域幅が節約されます。Citrixユニバーサルプリンタードライバーにより、使用されるプリンターモデルに関係なく、クライアントに接続されているすべてのプリンターをXenAppまたはXenDesktopセッション内で使用できるようになります。

アプリケーション

アプリケーションを正しく統合するには、互換性を理解していること、また、ユーザーやビジネスの要件が適切な配信方法にどのように影響を与えるかを理解している必要があります。

決定事項:互換性

通常、VDIでは、組織におけるアプリケーションの配信および管理方法の大幅な変更が必要になります。たとえば、多くの組織は、アプリケーションのストリーミング配信やアプリケーションの階層化などの手法を使用して、基本イメージにインストールされるアプリケーションの数を減らすことによって、デスクトップオペレーティングシステムをアップグレードし、管理を簡素化することができます。これらは、包括的な互換性テストを必要とする大規模な変更です。検証が必要な場合がある重要な互換性要件には、次のものがあります:

  • オペレーティングシステム - アプリケーションは、推奨オペレーティングシステムと互換性がある必要があります。
  • マルチユーザー - 一部のアプリケーションは、ホストされる共有デスクトップやホストされるWindowsアプリを介した配信に適している場合があります。このような状況では、Windows Server 2012R2などのサーバーオペレーティングシステムのマルチユーザー機能について、アプリケーションの互換性を検証する必要があります。
  • アプリケーションアーキテクチャ - 適切なオペレーティングシステムを選択するために、アプリケーションに16ビット、32ビット、64ビットのうちどのコードが含まれているのかを理解することが重要です。16ビットのコードは、64ビットのオペレーティングシステムでは実行できません。ただし、16ビットアプリケーションは、Windows 7、8、または10のx86版などの32ビットデスクトップベースオペレーティングシステムから、ホストされるWindowsアプリとしてユーザーに配信することができます。
  • 相互運用性 - アプリケーションによっては、同じオペレーティングシステム上に共存すると、問題が発生する可能性があります。原因として、共有レジストリハイブ、dllファイル、INIファイル、および互換性のない依存関係が考えられます。適切な修復措置を行ったり、代替配信モデルを選択したりできるよう、アプリケーションの相互運用性に関する問題を特定する必要があります。
  • 依存 - ユーザーにシームレスなエクスペリエンスを提供するため、アプリケーション間の対話が必要になる場合があります。たとえば、情報をPDF形式で表示するアプリケーションでは、適切なPDFビューアーを利用できる必要があります。依存(子)アプリケーションは、親アプリケーションのバージョン固有であることが多いです。
  • アプリケーション仮想化 - ストリーム配信や階層化などのアプリケーション仮想化技術を使用すると、基本イメージにインストールされるアプリケーションの数が減り、イメージ管理が簡素化されます。ただし、一部のアプリケーションは、デバイスドライバーがインストールされたり、COM+が使用されたり、オペレーティングシステムに組み込まれたりしている場合があるため、ストリーム配信や階層化には適していません。

手動のユーザーテストを組み合わせて実行するか、ソフトウェアベンダーが管理する事前検証済みのリストを利用するか、または互換性を検証するために何千ものテストを実行するCitrix AppDNAのような自動アプリケーション互換性ソリューションを使用することにより、アプリケーション互換性を実現できます。

決定事項:アプリケーション配信方法

1つの配信方法で、すべての要件を満たせることはほとんどありません。アプリケーション分類評価プロセスの結果と全体的なイメージ管理方針(インストール済みイメージ、スクリプト化されたイメージ、およびレイヤー化されたイメージ)に従って、複数のアプリケーション配信方法を検討できます。

適切なアプリケーション配信方法を選択することで、スケーラビリティ、管理性、ユーザーエクスペリエンスを高めることができます。

  • アプリのインストール - アプリケーションは、ベースのデスクトップイメージに含まれます。インストールプロセスでは、レジストリが変更されるとともに、dllファイルやexeファイルなどのファイルがイメージドライブにコピーされます。
  • アプリのストリーム配信(Microsoft App-V) - アプリケーションはプロファイル化され、オンデマンドでネットワーク上のデスクトップへ配信されます。アプリケーションファイルとレジストリの設定は仮想デスクトップのコンテナ内に配置され、ベースオペレーティングシステムや別の設定から隔離されるため、互換性の問題を解決しやすくなります。
  • アプリのレイヤー化(Citrix App Layering) - レイヤーごとに、アプリケーション、エージェント、またはオペレーティングシステムを1つ配置します。レイヤー化では1つのレイヤーに存在するOS、エージェント、アプリケーションが1つになるため、定期的なメンテナンスを簡単に行えます。レイヤーを更新すると、そのレイヤーを含む展開済みイメージがすべて更新されます。アプリケーション階層化には、次の2つの異なる配信オプションがあります:
    • レイヤー化されたイメージ – 管理者は、OSレイヤーを1つ、プラットフォームレイヤー(XenAppおよびXenDesktop VDA、Provisioning Servicesエージェント)を1つ、アプリケーションレイヤーを複数統合することで、展開可能な新しいイメージを簡単に作成できます。
    • Elasticレイヤー - XenAppおよびXenDesktopユーザーは、ログオンに基づく新しいアプリレイヤーを動的に取得できます。XenAppホストでは、Elasticレイヤーはセッションを認識し、接続されたレイヤーはレイヤーへのアクセスを許可されたユーザーのセッションでのみ利用可能です。
  • Windowsアプリのホスト - アプリケーションをマルチユーザーXenAppホストにインストールし、デスクトップではなくアプリケーションとして展開します。ユーザーは、アプリがリモートで実行されていることを意識することなく、VDIデスクトップまたはエンドポイントデバイスからホストされているWindowsアプリへシームレスにアクセスできます。
  • ローカルアプリ - アプリケーションをエンドポイントデバイスに展開します。アプリケーションがエンドポイント上で実行される場合でも、そのインターフェイスはユーザーのホストされたVDIセッション内に表示されます。

次の表は、アプリケーションをソリューション全体に統合するための優先アプローチに関する推奨事項を示しています。

表中の表記:

  • Yは、推奨されていることを示しています。
  • Nは、非推奨であることを示しています。
  • oは、実行可能であることを示しています。
アプリカテゴリ インストール済みアプリ ストリーミングアプリ 階層化アプリ ホストされたWindowsアプリ ローカルアプリ
共通 Y o Y o N
部門 o Y Y Y N
ユーザー N o Y o Y
管理 Y N Y o N

実際の例

  • エネルギー - あるエネルギー会社は、多数のユーザー用に基本イメージにアプリケーションをインストールし、必要に応じて部門アプリケーションをストリーム配信しています。
  • 金融 - ある銀行業界の顧客は、さまざまな部門の要求に応じ、ユーザーグループに焦点を当てたアプリケーションを含む複数のデスクトップイメージを管理および展開しています。

仮想マシン

仮想リソースには、プロセッサ、メモリ、およびディスクを適切に割り当てる必要があります。これらの決定は、必要なハードウェアの容量とユーザーエクスペリエンスに直接影響します。

リソースを正しく割り当てるには、仮想デスクトップとアプリケーションで物理デスクトップと同等のパフォーマンスが達成されることが重要です。この条件が満たされていないと、生産性と全体的なユーザー満足度に影響します。ただし、仮想マシンに必要以上のリソースを割り当てると、ビジネスの効率が低下し、コストが増加します。

割り当てられるリソースは、評価フェーズで特定された各ユーザーグループのワークロード特性に基づいている必要があります。

決定事項:仮想プロセッサ(vCPU)

ホストされるデスクトップベースのVDIモデル(ホストされるプールデスクトップとホストされる個人用デスクトップ)では、複数のスレッドを同時に実行できるよう、仮想マシンごとに2つ以上のvCPUが一般的に推奨されます。ワークロードが非常に低い場合には単一のvCPUを割り当てることができますが、セッションがハングする可能性が高くなります。

ホストされるサーバーベースのVDIモデル(ホストされるWindowsアプリ、ホストされるWebブラウザーアプリ、ホストされる共有デスクトップ)では、適切なvCPU割り当てはプロセッサのNon-Uniform Memory Access(NUMA)アーキテクチャに基づきます。

NUMAアーキテクチャイメージ

各ソケットは、1つまたは複数のNUMAノードに分割されています。ホストされるサーバーベースのVDIモデルでは、4つ以上のプロセッサを利用することが多くなります。NUMAノードよりもvCPUを多く割り当てると、パフォーマンスが低下します。NUMAノードの一部を仮想マシンに割り当てた場合、割り当てられた部分がNUMAノードのサイズで容易に割り切れないと、パフォーマンスが低下します。多くの場合、仮想マシンの数を2倍にしながら、仮想マシンにNUMAノード内のコアの数またはその半分を割り当てるのが理想的です。

ユーザーワークロード

オペレーティングシステム スケール用に構成されたvCPU エクスペリエンス用に構成されたvCPU
Windows 7 仮想CPU×2 仮想CPU×2
Windows 10 仮想CPU×2 仮想CPU×2
Windows 2012R2 NUMAまたはその半分 NUMAまたはその半分
Windows 2016 NUMAまたはその半分 NUMAまたはその半分
オペレーティングシステム スケール用に構成されたvCPU エクスペリエンス用に構成されたvCPU
Windows 7 仮想CPU×2 仮想CPU×3
Windows 10 仮想CPU×2 仮想CPU×3
Windows 2012R2 NUMAまたはその半分 NUMAまたはその半分
Windows 2016 NUMAまたはその半分 NUMAまたはその半分
オペレーティングシステム スケール用に構成されたvCPU エクスペリエンス用に構成されたvCPU
Windows 7 仮想CPU×3 仮想CPU×4
Windows 10 仮想CPU×3 仮想CPU×4
Windows 2012R2 NUMAまたはその半分 NUMAまたはその半分
Windows 2016 NUMAまたはその半分 NUMAまたはその半分

Windows 2012R2の推奨事項は、ホストされるWindowsアプリ、ホストされるWebブラウザーアプリ、およびホストされる共有デスクトップVDIモデルに基づいています。

決定事項:CPU最適化

共有仮想化環境では、暴走プロセスやExcelでの負荷の大きなデータ処理操作のため、単一のユーザーがCPUリソースを独占することがあります。プロセッサがオーバーサブスクライブされると、別のユーザーの要求を満たすことができなくなり、セッションがハングします。

XenAppおよびXenDesktopのコンポーネントであるCitrix Workspace Environment Managementには、CPU最適化が含まれています。一定の期間に一定割合のCPUがプロセスで消費されると、プロセスの優先順位が通常から低または非常に低いに下がり、残りの全プロセスの優先順位が高くなって、暴走プロセスのリスクを克服できます。また、CPU最適化ではCPU保護をトリガーしたプロセスが記憶され、将来の起動時にそのプロセスがより低い優先順位で自動的に開始されます。

多くの環境では、デフォルト構成としてCPU最適化を有効にする必要があります。

決定事項:仮想メモリ(vRAM)

各リソースに割り当てられるメモリの容量は、ユーザーの予想ワークロードとアプリケーションのフットプリントに基づきます。仮想マシンに割り当てられたメモリが不十分な場合、ディスクへのページングが過剰に発生し、ユーザーエクスペリエンスが悪化します。一方、過剰なRAMを割り当てると、ソリューション全体のコストが増加します。

次の表は、ワークロードに基づいて割り当てる必要がある仮想RAMに関するガイダンスを示しています。

ユーザーワークロード

オペレーティングシステム スケール用に構成されたvRAM エクスペリエンス用に構成されたvRAM
Windows 7 2GB 3GB
Windows 10 2GB 3GB
Windows 2012R2 ユーザーあたり256MB ユーザーあたり256MB
Windows 2016 ユーザーあたり320MB ユーザーあたり320MB
オペレーティングシステム スケール用に構成されたvRAM エクスペリエンス用に構成されたvRAM
Windows 7 3GB 4GB
Windows 10 3GB 4GB
Windows 2012R2 ユーザーあたり512MB ユーザーあたり512MB
Windows 2016 ユーザーあたり640MB ユーザーあたり640MB
オペレーティングシステム スケール用に構成されたvRAM エクスペリエンス用に構成されたvRAM
Windows 7 6GB 8GB
Windows 10 6GB 8GB
Windows 2012R2 ユーザーあたり1024MB ユーザーあたり1024MB
Windows 2016 ユーザーあたり 1280MB ユーザーあたり1280MB

  • Windows 2012R2の推奨事項は、ホストされるWindowsアプリ、ホストされるWebブラウザーアプリ、およびホストされる共有デスクトップVDIモデルに基づいています。
  • メモリ割り当てが4GBを超える場合には、64ビットオペレーティングシステムが必要です。
  • 使用する場合、RAM容量のMachine Creation ServicesおよびProvisioning Servicesキャッシュを仮想マシンのRAMの仕様に追加する必要があります。

決定事項:RAM最適化

ユーザーは一度に1つのアプリケーション内のみで作業しますが、多くのユーザーは5つ以上のアプリケーションをアイドル状態で実行しています。プロセスがアクティブからアイドルに移行すると、アプリケーションとオペレーティングシステムでプロセスのメモリのアクティブなワーキングセットが一部解放され、システムリソースが解放されます。ただし、これで解放されるのはアプリケーションワーキングセットのごく一部にすぎません。残りのワーキングセットはアプリケーションに対してロックされたままになり、利用可能なシステムリソースが大幅に制限されます。

Citrix Workspace Environment Management内でRAM最適化を使用すると、一定時間アイドル状態にある(ユーザーが操作していない)アプリケーションの不要なメモリは、アイドル状態が終了するまで強制的に解放されます。アプリケーションがアクティブ状態に戻ると、解放されたメモリはアクティブなワーキングセットにロードされます。

多くの環境では、デフォルト構成としてRAM最適化を有効にする必要があります。特定のプロセスで最適化に関する問題が発生した場合は、RAM最適化の除外の一覧を利用できます。

決定事項:ディスクキャッシュ

各VMで必要とされるストレージの容量は、ワークロードとイメージの種類によって異なります。イメージ管理ソリューションを利用せずにホストされる個人用デスクトップを作成する場合、各VMでOS全体およびローカルにインストールされたアプリケーションに対して十分なストレージが必要になります。

Machine Creation ServicesまたはProvisioning Servicesを介してマシンを展開すると、各仮想マシンの記憶要件を大幅に軽減できます。書き込みキャッシュと差分ディスクのディスクスペース要件は、アプリケーションの使用状況とユーザーの動作に依存します。ただし、次の表は、続くガイドラインに従い、vCPUとvRAMを含めてサイジングされたマシンに基づいてディスクスペース要件を見積もるための開始ポイントになります:

ユーザーワークロード

オペレーティングシステム 記憶域(差分ディスク/書き込みキャッシュディスク)
Windows 7 10GB
Windows 10 10GB
Windows 2012R2 40GB
Windows 2016 60GB
オペレーティングシステム 記憶域(差分ディスク/書き込みキャッシュディスク)
Windows 7 15GB
Windows 10 15GB
Windows 2012R2 40GB
Windows 2016 60GB
オペレーティングシステム 記憶域(差分ディスク/書き込みキャッシュディスク)
Windows 7 20GB
Windows 10 20GB
Windows 2012R2 40GB
Windows 2016 60GB

決定事項:RAMキャッシュ

Provisioning ServicesとMachine Creation Servicesには、仮想マシンのRAMの一部をストレージキャッシュのバッファーとして利用する機能があります。RAMキャッシュは、仮想マシンの非ページプールメモリを共有することによって従来のストレージのパフォーマンスを向上させるために使用されます。

ユーザーワークロード

オペレーティングシステム スケール用に構成されたRAMキャッシュ エクスペリエンス用に構成されたRAMキャッシュ
Windows 7 128MB 256MB
Windows 10 128MB 256MB
Windows 2012R2 2GB 2GB
Windows 2016 4GB 4GB
オペレーティングシステム スケール用に構成されたRAMキャッシュ エクスペリエンス用に構成されたRAMキャッシュ
Windows 7 256MB 512MB
Windows 10 256MB 512MB
Windows 2012R2 4GB 4GB
Windows 2016 8GB 8GB
オペレーティングシステム スケール用に構成されたRAMキャッシュ エクスペリエンス用に構成されたRAMキャッシュ
Windows 7 512MB 1024MB
Windows 10 512MB 1024MB
Windows 2012R2 6GB 6GB
Windows 2016 10GB 10GB

  • 使用する場合、RAM容量のMachine Creation ServicesおよびProvisioning Servicesキャッシュを仮想マシンのRAMの仕様に追加する必要があります。
  • ホストで追加のRAMが使用可能な場合は、RAMキャッシュの容量を増やしてより高いレベルのパフォーマンスを実現できます。

決定事項:ストレージIOPS

ストレージのパフォーマンスは、1秒間に処理できる操作の数(IOPS)によって制限されます。ストレージIOPSの割り当てが不足していると、VDIデスクトップにおけるアプリ、Webページ、およびデータの読み込みが遅くなります。

下の表は、ワークロードとオペレーティングシステムに基づいてユーザーごとに生成されるストレージIOPSの数に関するガイダンスです。ユーザーのログオンおよびログオフ時には、ストレージのIOアクティビティが増加します。

ユーザーワークロード

オペレーティングシステム ストレージIOPS(RAMベースのキャッシュなし) ストレージIOPS(RAMベースのキャッシュあり)
Windows 7 10 IOPS 1 IOPS
Windows 10 12 IOPS 1 IOPS
Windows 2012R2 3 IOPS 0.5 IOPS
Windows 2016 4 IOPS 1 IOPS
オペレーティングシステム ストレージIOPS(RAMベースのキャッシュなし) ストレージIOPS(RAMベースのキャッシュあり)
Windows 7 15 IOPS 1 IOPS
Windows 10 20 IOPS 1.5 IOPS
Windows 2012R2 4 IOPS 0.5 IOPS
Windows 2016 6 IOPS 1 IOPS
オペレーティングシステム ストレージIOPS(RAMベースのキャッシュなし) ストレージIOPS(RAMベースのキャッシュあり)
Windows 7 25 IOPS 2 IOPS
Windows 10 35 IOPS 3 IOPS
Windows 2012R2 5 IOPS 0.5 IOPS
Windows 2016 8 IOPS 1 IOPS

決定事項:IOの優先順位付け

共有環境では、すべてのユーザーのIOプロセスにリソースが等しく配分されます。IOが多く発生するタスクを実行しているユーザーは、ミッションクリティカルなアプリケーションに影響を与える可能性があります。Citrix Workspace Environment Managementにより、管理者がプロセスのIO優先順位を定義できます。

プロセスでより多くのIOリソースが必要となる場合、またはプロセスがIOリソースを独占している場合は、コンソールからプロセスおよびプロセス優先順位を手動で変更します。この詳細構成は、特別な状況でのみ使用されます。

決定事項:グラフィック(GPU)

グラフィック処理装置(GPU)がない場合、グラフィック処理はCPUによってソフトウェアで行われます。グラフィック処理装置(GPU)を利用して、サーバーのスケーラビリティとユーザーエクスペリエンスを改善したり、グラフィックを多用するアプリケーションの使用を可能にしたりすることができます。デスクトップのデザイン時には、GPU(使用されている場合)の仮想マシンへのマッピング方法を決定することが重要です。3つの方法があります。

  • パススルーGPU - 各物理GPUが、単一の仮想マシン(ホストされるアプリまたはホストされるデスクトップ)にパススルーされます。
  • ハードウェア仮想化GPU - ハイパーバイザーのvGPUテクノロジを使用して、NVIDIA GRIDまたはIntel Iris Proが仮想化され、複数のマシン間で共有されます。各仮想マシンは、GPUドライバーの全機能を備えており、GPUに直接アクセスできます。
  • ソフトウェア仮想化GPU - GPUはハイパーバイザーによって管理され、VDIデスクトップによって行われた要求を傍受します。このプロセスは、GPUがホスト内にインストールされていない場合に使用されます。

表中の表記:

  • Yは、利用可能であることを示します。
  • Xは、サポートされていないことを示します。

Citrix XenServer

  パススルーGPU ハードウェア仮想化GPU(NVidia) ハードウェア仮想化GPU(Intel) ハードウェア仮想化GPU(AMD) ソフトウェアエミュレートGPU
XenDesktop Y Y Y X Y
XenApp Y Y Y X Y

Microsoft Hyper-V

  パススルーGPU ハードウェア仮想化GPU(NVidia) ハードウェア仮想化GPU(Intel) ハードウェア仮想化GPU(AMD) ソフトウェアエミュレートGPU
XenDesktop Y X X X Y
XenApp Y X X X Y

VMware vSphere

  パススルーGPU ハードウェア仮想化GPU(NVidia) ハードウェア仮想化GPU(Intel) ハードウェア仮想化GPU(AMD) ソフトウェアエミュレートGPU
XenDesktop Y Y X Y Y
XenApp Y Y X Y Y

グラフィカルアプリケーションを多用するユーザーグループは、NVidiaハードウェア仮想化GPUを使用する必要がよくあります。Officeベースのアプリケーションを使用するユーザーグループは、Intelのハードウェア仮想化GPUを使用することで目に見えるメリットを得ることができます。