デザイン

デスクトップ仮想化ソリューションの設計は、実証済みのプロセスに従って、組織やユーザーの要件に合わせて技術的な決定を行うだけです。標準化された実証済みのプロセスがなければ、設計者は手当たり次第次々に作業を行うことになりがちで、これは混乱と誤りを招きます。推奨されるのは、5つの異なるレイヤーの活用に重点を置く方法です:

5レイヤー設計モデルの画像

上位3レイヤーは各ユーザーグループ用に個別に設計されます。これについては、評価フェーズのユーザーセグメンテーションセクションで説明しています。これらのレイヤーは、ユーザーのリソースと、ユーザーがそのリソースにアクセスする方法を定義します。これらの3つのレイヤーが完成したら、ソリューション全体の基本レイヤー(コントロールおよびハードウェア)を設計します。

このプロセスは、上位での決定が下位レベルのデザイン決定に影響を与えるという設計思考を導きます。

レイヤー0:概念アーキテクチャ

概念アーキテクチャは、ビジネス目標と組織構造に基づいて、ソリューション全体の包括的な戦略を定義するのに役立ちます。

組織の概念アーキテクチャはその後数年間で変化すると思われますが、デリバリーモデルに関する長期的な目標とソリューションの物理的および地理的配置を定義することにより、設計フェーズを開始する価値はあります。

決定する事項:デリバリーモデル

XenDesktopおよびXenAppソリューションでは、多数のデリバリー形態を利用できます。組織のビジネス目標は、適切な方法を選択するのに役立ちます。すべてのデリバリーモデルでインフラストラクチャは変わりませんが、ローカルITチームの管理範囲は変わります。

  • オンプレミス - すべてのコンポーネントが組織のローカルデータセンターでホストされる。オンプレミスモデルでは、ローカルITチームがソリューションのあらゆる側面を管理する必要があります。

オンプレミスアーキテクチャの画像

  • パブリッククラウド - すべてのコンポーネントがInfrastructure as a Service(IaaS)を使用したパブリッククラウドインフラストラクチャでホストされる。パブリッククラウドモデルでは、ローカルITチームの管理範囲からハードウェア管理が除外されます。

パブリッククラウドアーキテクチャの画像

  • ハイブリッドクラウド - オンプレミスデータセンターとパブリッククラウドで単一の実装を実行する。ソリューションのコンポーネントが異なるホスティングプロバイダーを使用していても、ソリューション全体は同じコードを使用し、単一のエンティティとして管理される単一のソリューションです。ローカルITチームは、クラウドでホストされるリソースに関連するハードウェアを除く、ソリューションのすべての側面を引き続き管理します。

ハイブリッドクラウドアーキテクチャの画像

  • Citrix Cloud - Citrix CloudのXenApp and XenDesktop Serviceオファリングでは、一般的な環境を複数の管理ドメインに分割します。アクセスレイヤーとコントロールレイヤーのコンポーネントは、Citrixにより、Citrixクラウドでホストおよび管理されますが、リソースレイヤーのコンポーネントは引き続きローカルITチームにより、オンプレミス、パブリッククラウド、ハイブリッドクラウドのいずれかのモデルで管理されます。Citrixがハードウェア、つまりサイジングの管理とアクセスコンポーネントおよびコントロールコンポーネントのアップデートを行い、ローカルITチームがリソースの管理を行います。さらに、パブリッククラウドでリソースをホストしている場合には、ローカルITチームがリソースハードウェアを管理する必要はありません。Citrix Cloudは、特定のユーザー事例を解決するのに役立つオファリングの数を増やし続けています。詳細とすべてのオファリングの内容については、「Citrix Cloud内のワークスペースサービス」をご覧ください 。

Citrix Cloudアーキテクチャの画像

決定する事項:サイトトポロジ

XenAppおよびXenDesktopサイトは、デスクトップとアプリケーションをグループ化し、単一のアーキテクチャおよび管理エンティティを形成します。サイトの構成、デスクトップの割り当て、セッション状態など、サイトの永続的で動的なデータはすべて、サイトのデータベースに保存されます。

サイトは、1つの場所に収めることも、複数の場所にまたがることも、ある場所の一部とすることもできます。厳格なテストにより、1つのXenAppまたはXenDesktopサイトで40,000以上の同時セッションをサポートできます。

デリバリーサイト1の画像

デリバリーサイト2の画像

デリバリーサイト3の画像

1つのサイトをさらに分割するのがゾーンで、通常、地理的な場所に関連付けられています。XenAppおよびXenDesktopソリューションの全体的なトポロジを決定する際には、考慮すべき点がいくつかあります:

  • リスク許容度 - 複数のXenDesktopサイトを作成して、サイト全体の停止の影響を最小限に抑えます。たとえば、XenDesktopサイトデータベースの破損はサイト全体の可用性に影響することがあります。多くの組織にとって、複数のサイトを実装することによるリスクの減少は、管理オーバーヘッドが増えることや必要なインフラストラクチャをサポートすることよりも重要です。

実際の例

金融機関 - ある大手金融機関が1つのデータセンターで10,000台のデスクトップをホストしています。リスクを軽減するために、サイトのデスクトップは5,000台を超えないようにすることが決定されました。そのため、デスクトップが高速で冗長なネットワークで接続されているにもかかわらず、2つのサイトが作成されました。

  • セキュリティ - 委任管理は可能ですが、特定のサービスレベルアグリーメントへのコンプライアンスを示すために、高セキュリティの組織は環境の完全な分離が必要な場合があります。

実際の例

小売 - ある小売組織では、財務データの管理を担当する従業員を完全に分離する必要がありました。この要件を満たすために、同じデータセンター内に2つの個別のサイトを作成し、1つを財務担当従業員用に、もう1つをその他すべての従業員用にしました。

  • 行政区画 - 請求や払い戻しの要件や、ITの構成仕様により、複数のサイトで行政区画に分けることが必要になる場合があります。

  • 地理的な接続性 - ゾーンの実装により、1つのサイトが複数の地理的な場所にまたがることができるようになりますが、サテライトゾーンとプライマリゾーンの間には、サイトデータベースがセッション情報を取得するのに十分な帯域幅が必要です。長い待ち時間や大きなゾーンは、ユーザーの応答時間に影響を与えます。

変数 XenAppおよびXenDesktop 7.13 XenAppおよびXenDesktop 7.11
待ち時間(ミリ秒) 90 250
同時リクエスト 48 48
平均応答時間 3.7 7.6
1秒あたりの仲介要求 12.6 6.3
10,000人のユーザーを起動する時間 13分 26分
セッション数 最大同時セッション起動数 最小サイト間帯域幅 最大サイト間往復待ち時間
50未満 20 1Mbps 250ミリ秒
50~500 25 1.5Mbps 100ミリ秒
500〜1,000 30 2Mbps 50ミリ秒
1,000~3,000 60 8Mbps 10ミリ秒
3,000以上 60 8Mbps 5ミリ秒

通常、管理者はアーキテクチャの複雑さと管理作業を減らすために、XenDesktopのサイトとゾーンの数を最小にする必要があります。

決定する事項:イメージ管理戦略

XenAppおよびXenDesktopソリューションでは、マスターイメージの作成と管理が必要となります。組織は、どの戦略でイメージ管理を推進するかを早めに決定する必要があります。

インストール済みイメージ

インストール済みイメージでは、管理者がイメージごとにオペレーティングシステムとアプリケーションをインストールする必要があります。この方法は簡単ですが、管理者が同じオペレーティングシステムとコアアプリケーションを複数のマスターイメージでインストールするため、作業の重複が発生します。

同じオペレーティングシステムバージョンとコアアプリケーションが複数のイメージの一部となり、それぞれに同じアップデートプロセスが必要となるため、マスターイメージの管理でも作業の重複が発生します。

スクリプト化されたイメージ

管理者は、スクリプト作成ツールまたは自動化ツールを使用して、インストール済みイメージに関連する多くのタスクを自動化できます。多くのオペレーティングシステムやアプリケーションのインストールでは、自動スクリプトをサポートしています。これにより、インストール済みイメージにかかる管理者の時間に対して作業の重複が与える影響が軽減されます。

残念ながら、イメージ全体のスクリプトフレームワークの理解、作成、および管理は、困難で時間のかかる作業です。ビルド全体をスクリプト化するには時間がかかり、ディレクトリ構造が変更されてプロセスが完了するまでに時間がかかりすぎたり、ファイル名が変更されたりすると、予期しないエラーが発生することがあります。

レイヤー化されたイメージ

それぞれの固有のオペレーティングシステム(Windows 10、Windows 2012 R2、およびWindows 2016)、プラットフォーム(XenApp/XenDesktop 7.13 VDA、 XenApp/XenDesktop 7.14 VDA、およびXenApp/XenDesktop 7.15 VDA)、アプリケーション(Microsoft Office、Adobe Acrobat、Google Chrome、およびMozilla Firefox)がレイヤーです。マスターイメージは、1つのオペレーティングシステムレイヤー、1つのプラットフォーム、および多くのアプリケーションをマージしたものです。

レイヤー化されたイメージの手法では、インストール済みイメージとスクリプト化されたイメージに関連する作業の重複が排除されます。固有のレイヤーはそれぞれ、すべてのマスターイメージで使用できます。アプリケーションでアップデートが必要な場合、そのレイヤーがアップデートを受け取ると、そのレイヤーを使用するすべてのマスターイメージがアップデートを受け取ります。組織で10個の個別のWindows 10イメージが必要な場合、その10個の各イメージは同じWindows 10レイヤーを共有します。10個のイメージすべてでVDAをバージョン7.14から7.15にアップグレードする必要がある場合、管理者は1つのプラットフォームレイヤーのみをアップデートします。

最初、レイヤー化されたイメージの手法を展開するには時間がかかります。それは、管理者が組織のレイヤーライブラリを構築する必要があるためです。ただし、レイヤーが使用可能になれば、イメージを管理するための時間は大幅に短縮されます。