Comments
Description
Transcript
エンタープライズ規模の XenDesktop ソリューションの設計
WHITE PAPER Citrix XenDesktop エンタープライズ規模の XenDesktop ソリューションの設計 10,000 ユーザーにホステッドデスクトップ、ストリーム配信デスクトップ、インス トール済みデスクトップを提供するソリューションの作成 目次 概要............................................................................................................................................................... 4 要約............................................................................................................................................................... 4 重要なポイント............................................................................................................................................ 4 期待される利点 .......................................................................................................................................... 5 インフラストラクチャの概要.......................................................................................................................... 6 設計の概要 ................................................................................................................................................ 6 概念的なアーキテクチャ ................................................................................................................................. 7 簡素化されたアクセス................................................................................................................................. 7 シームレスな統合 ....................................................................................................................................... 8 スケーラブルなインフラストラクチャ ............................................................................................................. 8 仮想化インフラストラクチャの設計 ................................................................................................................ 10 仮想化の設計 .......................................................................................................................................... 10 ハードウェア ............................................................................................................................................. 11 キャパシティのプランニング....................................................................................................................... 13 高可用性.................................................................................................................................................. 14 ストレージ................................................................................................................................................. 17 オペレーティングシステムのデリバリーの設計............................................................................................... 19 Provisioning Services のオペレーティングシステム .................................................................................. 19 ハードウェア ............................................................................................................................................. 20 キャパシティのプランニング....................................................................................................................... 20 高可用性.................................................................................................................................................. 22 キャッシュ ................................................................................................................................................. 24 サーバーファームの設計 .......................................................................................................................... 25 アプリケーションデリバリーの設計 ................................................................................................................ 28 アプリケーション........................................................................................................................................ 28 統合 ......................................................................................................................................................... 32 最適化 ..................................................................................................................................................... 35 デスクトップデリバリーの設計 ....................................................................................................................... 36 キャパシティのプランニング....................................................................................................................... 36 デスクトップグループ................................................................................................................................. 38 デスクトップの設計 ....................................................................................................................................... 40 仮想マシンの仕様 .................................................................................................................................... 40 デスクトップイメージ .................................................................................................................................. 41 ストレージ................................................................................................................................................. 42 デスクトップの監視 ................................................................................................................................... 43 アクセスに関する設計 .................................................................................................................................. 44 リソースのデリバリー ................................................................................................................................ 44 社内でのサイトアクセス ............................................................................................................................ 45 社外からのサイトアクセス ......................................................................................................................... 46 ビジネスの継続性を維持するための設計...................................................................................................... 48 コンポーネントのフェイルオーバー............................................................................................................. 48 サイトのフェイルオーバー ......................................................................................................................... 49 次のステップ ................................................................................................................................................ 51 付録 I：参考例企業の詳細............................................................................................................................ 52 付録 II：参考資料 ......................................................................................................................................... 55 3 概要 エンタープライズ規模のデスクトップデリバリーソリューションの設計では、ユーザー、アプリケーション、デスクトッ プ、および基盤となるインフラストラクチャの設計を考慮する必要があります。単にすべてのユーザーをホステッド デスクトップのユーザーに移行することも可能ですが、そのような方法では技術的なソリューションでビジネス上 の難題に対応することはできません。デスクトップデリバリーソリューションでは、ユーザーの要件に応じた最適の 操作環境を提供する必要があります。特定のプロセスに焦点を合わせたアプリケーションが必要なユーザーもい れば、必要に応じて作業環境を作成したりカスタマイズしたりすることが可能な、より動的な環境が必要なユーザ ーもいるでしょう。この文書では、ある企業の要件と従業員の特徴に基づいた例を用いて、推奨されるソリューシ ョンを構築する方法を説明します。例とした企業の詳細な情報は記載せずに一般化して説明しています。対象と しているのは次のような企業です。 ユーザー数 10,000 の世界的規模の企業 4 箇所のデータセンターからユーザーをサポート ユーザーは本社のオフィス、支社のオフィス、小規模の支店のオフィス、ホームオフィス、および仮想オフィス で作業 各ユーザーには「ホーム」データセンターが割り当てられており、障害が発生していない限りユーザーはこの データセンターに接続 例とした企業のその他の情報については、「付録 I：参考例企業の詳細」を参照してください。 要約 この企業では、現在 4 箇所のデータセンター（マイアミ、ロサンゼルス、ロンドン、香港）を利用して、多数の現地オ フィス、支社オフィス、ホームオフィスにいる約 10,000 人のユーザーをサポートしています。企業内に配備されて いるデスクトップとラップトップの多くは、3 年間の製品ライフサイクルを迎えようとしています。部署によっては既 にデスクトップハードウェアをより強力な新しいシステムにアップグレードしていますが、これらのデバイスの使用 期間の延長を検討している部署もあります。 このような環境でさまざまな種類のラップトップとデスクトップが使用されており、多様なエンドポイントデバイスと 構成を含む既存の環境をサポートおよび保守をするために多数のツールを購入して使用しています。すでにいく つかのアプリケーションはをホストする Citrix XenApp サーバーは、一部の複雑なアプリケーション（CRM スイー トや ERP スイート）に対する一貫性を提供しています。この企業は新しいデスクトップ管理ソリューションに関心が あり、仮想デスクトップの導入を決定しています。 重要なポイント この企業の特徴から、1 つの画一的な仮想デスクトップソリューションでは、コストを抑えながら環境を簡素化する という全体的な目標を達成することができません。そこで Citrix は、単一の統一的なソリューションに統合可能な 4 各種技術を個別のユーザー要件に適合させることに焦点を合わせた混在環境をお勧めします。Citrix Delivery Center を使用すると、この企業では次の種類のデスクトップをサポートできるようになります。 ホステッド：担当業務に合わせてカスタマイズ可能な標準的な基本デスクトップイメージを必要とするユーザ ー向けのデスクトップです。これらのユーザーは、従来の物理的なワークステーション、ラップトップ、デバイ スを利用して、データセンター内でホストされる XenServer 上の仮想デスクトップに接続します。管理と保守 はデータセンター内で行われます。このホステッドデスクトップモデルでは、エンドポイントデバイスの使用期 間（ライフサイクル）を大幅に延長できます。 ストリーム配信：最近、新しい物理ワークステーションを支給されたユーザー向けのデスクトップです。ハード ウェアをアイドル状態のままにせずに、ワークステーションでネットワークストリームとして仮想デスクトップを 受信します。管理と保守はデータセンター内で行われます。このストリーム配信デスクトップモデルでは、デス クトップデリバリーモデルを標準化および簡素化するとともに、デスクトップ更新サイクルの一環として購入済 みのハードウェアを活用することができます。 モバイル/オフライン：オフラインのモバイル利用を必要とするユーザー向けのデスクトップです（例：ラップトッ プ）。これらのユーザーにはオペレーティングシステムをローカルにインストールする必要がありますが、アプ リケーションはネットワークストリームとして配信され、オフラインでのモバイル利用が可能になります。オペー レーティングシステムの管理と保守はリモートに行われますが、アプリケーションのサポートはデータセンター 内で行われます。この物理デスクトップモデルでは、アプリケーションのデリバリーを集中管理しながらモバイ ルユーザーをサポートできます。 期待される利点 新しくデスクトップデリバリーの方針を立てる場合は、環境全体を総合的に評価し、将来に目を向けた設計を行う 必要があります。以降のページに示す設計に沿って作業すると、次のような利点が期待できます。 簡素化：デスクトップとアプリケーションのデリバリーを簡素化できます。多様なハードウェアの数百ものデス クトップイメージをサポートする代わりに、あらゆる種類のエンドポイントデバイスをサポートしながら、イメー ジ数を少数で管理しやすい数まで大幅に削減できます。 スケーラビリティ：企業規模の拡大に応じてソリューションの規模を拡大できます。今回提案するアーキテクチ ャでは、単にグローバル Web アドレスをユーザーに指示するだけで新しいユーザーを追加できます。それら のユーザーには、アプリケーションがあらかじめ設定された状態でホステッドデスクトップをすぐに提供するこ とができます。 セキュリティの向上：モバイルデバイスへ配信するアプリケーションとデータをデータセンターを決めることに よって、環境のセキュリティを向上させることができます。モバイルユーザーは重要なデータを扱うほとんどの アプリケーションを離れた場所から利用でき、データはデータセンター内で保護されます。 パーソナライゼーション：ユーザーは完全にカスタマイズされた操作環境を受信できます。IT 部門は多くのオ ペレーティングシステムとアプリケーションの組み合わせをサポートする必要はありません。今回提案するソ リューションでは、ユーザーのデスクトップが複数の階層に分離され、それを多数のユーザー間で共有できま す。これらの階層は接続時に動的に結合されます。 5 インフラストラクチャの概要 Citrix XenDesktop などの仮想デスクトップデリバリーソリューションに移行する企業では、ホステッドデスクトップ とストリーム配信デスクトップをサポートできるインフラストラクチャが必要になります。高レベルのハードウェア要 件は次のように見積もられます（これらの数値はプロジェクトの構築段階やテスト段階で適宜修正します）。 データセンター ユーザー数 物理サーバー数 デスクトップイメージ数 ストレージ要件 マイアミ 5,000 119 全サイトで 3 イメージ 永続：320GB 一時：19.8TB ロサンゼルス 3,000 62 永続：220GB 一時：9TB ロンドン 1,000 29 永続：160GB 一時：4TB 香港 1,000 29 永続：160GB 一時： 4TB XenDesktop を使用しない場合のストレージ要件は約 144TB です。永続ストレージの要件は、Provisioning Services のストリーム配信イメージおよびバックアップイメージに必要な容量に相当します。一時ストレージ要件 には、デスクトップセッション中に作成され、Provisioning Services 経由で配信される一時的な書き込みキャッシ ュ情報に必要な容量を含みます。この一時ストレージは TB（テラバイト）単位で概算されていますが、データ重複 排除機能を含むティア 1 ストレージが採用されているため、実際に使用されるストレージ量はかなり少なくなりま す。以降では、サーバー数、イメージ数、およびストレージ要件の計算について詳しく説明します。 設計の概要 ここでは、以下の項目に関する設計関連の決定事項に焦点を当てて説明しています。 概念的なアーキテクチャ：高い視点から見たソリューション全体の概要 仮想化インフラストラクチャ：ハードウェア、キャパシティ、高可用性、ストレージに焦点を当てた、基盤となる 仮想化インフラストラクチャ上の詳細設計 オペレーティングシステムのデリバリー：サーバーファームの設計、キャパシティ、キャッシュ、高可用性に焦 点を当てた、ホステッドデスクトップおよびストリーム配信デスクトップへの基本オペレーティングシステムの デリバリの詳細設計 アプリケーションのデリバリー：デスクトップデリバリにおけるアプリケーション層の統合、特にアプリケーショ ン、統合、アプリケーションの最適化について デスクトップのデリバリー：キャパシティ、グループ、グループ設定に焦点を当てたデスクトップデリバリープロ セスの設計 6 仮想デスクトップ：ホステッドデスクトップおよびストリーム配信デスクトップ用のデスクトップイメージのコンポ ーネント定義。仮想デスクトップの仕様、デスクトップイメージ、およびストレージ要件について アクセスに関する設計：社内および社外ユーザーがリソースへアクセスする方法 ビジネスの継続性を維持するための設計：サービス障害によるユーザーへの影響を軽減するソリューション の設計 概念的なアーキテクチャ この企業のデスクトップデリバリーソリューションの主な要件は、次の 3 つです。 簡素化されたアクセス シームレスな統合 スケーラブルなインフラストラクチャ 以下に示す概念的なアーキテクチャは、高水準な XenDesktop の設計概要です。このアーキテクチャの細部につ いては、以降の節で詳しく説明します。 簡素化されたアクセス 社外ユーザー（インターネット経由でデータセンターに接続するユーザー）は単一の完全修飾ドメイン名を使用し て自動的に最適な場所に接続されます。このソリューションでは、ユーザーが接続場所に応じて異なるアドレスを 使い分ける必要がなく、単一のアドレスでホームデータセンターに接続されるため、アクセスが簡素化されます。 図 1 に示すように、NetScaler が各データセンターに組み込まれており、グローバルサーバー負荷分散機能 （GSLB）で相互接続されています。 図 1：サイト間の設計 社外ユーザーは公衆インターネット経由で接続するため、すべての通信を暗号化して改ざんや盗聴を防ぐ必要 があります。各サイトでは、NetScaler プラットフォームに組み込まれている Access Gateway を使って公衆回線 経由のアクセスを保護します。 7 シームレスな統合 さまざまな要件があるため、すべてのユーザーがデスクトップを使用しなければならないわけではありません。多 くのユーザーの要求は、XenApp のアプリケーションデリバリー機能で対応できます。シンプルな環境を維持して インフラストラクチャ内の既存の設備投資を活用するため、図 2 のように、アプリケーションとデスクトップのデリバ リーコンポーネントは統合されています。 図 2：アプリケーションとデスクトップのデリバリーの統合 ローカルユーザー、支社内のユーザー、およびリモートユーザーは、ホステッドデスクトップまたはストリーム配信 デスクトップ内でアプリケーションを受信するか、XenApp から直接アプリケーションを受信します。各ユーザーに は、ユーザー権限の割り当てに基づいて、適切なアプリケーションやデスクトップが Citrix Receiver から提供され ます。要求があったときに適切なリソースを提供することによって、すべてのユーザーが同じインフラストラクチャ でサポートされます。 スケーラブルなインフラストラクチャ この時点では、4 箇所のデータセンターで 8,000 のホステッドデスクトップおよびストリーム配信デスクトップをサポ ートするとともに、10,000 人の全ユーザーへのアプリケーションデリバリーをサポートする環境を想定した見積も りを行っていますが、環境のスケーラビリティも確保する必要があります。このインフラストラクチャでは、図 3 のよ うに新しいサーバーファーム、プール、サーバーをオンライン状態にしてシームレスに統合することができます。 8 図 3：XenDesktop サイトの設計 この図は、XenDesktop の単一のデータセンターの高レベルの概要を示しています。他のデータセンターも同様 に構築していきます。 9 仮想化インフラストラクチャの設計 データセンターの容量や所要電力に過度な影響を及ぼさずに、ビジネスのサポートに必要な数のホステッドデス クトップを提供するために、物理サーバーを Citrix XenServer で仮想化します。物理サーバー数、ストレージ要件、 および高可用性の要件を定めて設計を行う必要があります。 仮想化の設計 設計時にはまず、XenDesktop ソリューション内のどのコンポーネントを XenServer で仮想化するかを決定する 必要があります。この企業では、データセンターの容量を節約するとともに、基盤となる環境での柔軟性を得る必 要があるため、図 4 のように環境の大部分を仮想化します。 図 4：仮想化インフラストラクチャの設計 この図に示されているように、この環境は多数のリソースプールで構成されています。このような構成は環境の体 系化に役立つだけでなく、複数のグループが他のコンポーネントに直接影響を及ぼさずに環境のさまざまな側面 を管理することを可能にします。また、各リソースプールで個別に、高可用性などのリソースプールの設定項目を 完全にカスタマイズできます。XenDesktop サーバーファーム用に設計されたリソースプールには、次のものがあ ります。 XenDesktop Infrastructure（XDI）：XenDesktop Infrastructure リソースプールは、基盤となる XenDesktop ソリューション。サイト全体で使用される Web Interface、XenDesktop Controller、および XenDesktop デー タストアを含みます。 XenApp Infrastructure（XAI）：XenApp Infrastructure リソースプールは、アプリケーションデリバリーサーバ ー用のリソースプール。このリソースプールは、XenApp ホストサーバー、XenApp データコレクタ、および冗 長構成のアプリケーションハブ（アプリケーションのストリーム配信に使用）を含みます。 Provisioning Services Infrastructure（PSI-Site）：Provisioning Services Infrastructure リソースプールは、 基本オペレーティングシステムのイメージを環境全体に提供するサーバーを含みます。vDisk には、XenApp サーバー、XenDesktop サーバー、インフラストラクチャサーバー、ホステッドデスクトップ、およびストリーム 10 配信デスクトップが格納されます。ストリーム配信デスクトップを使用するリモートオフィスでは、ローカルの XenServer プールに、冗長構成の Provisioning Services サーバーが格納されます。 Hosted Desktop Infrastructure（HDI-#）：Hosted Desktop Infrastructure リソースプールは、実際のホステ ッドデスクトップで構成されます。サイト内で必要となるホステッドデスクトップの数によっては、複数の Hosted Desktop Infrastructure リソースプールが必要になります。 ハードウェア ハードウェア構成は（特にキャパシティが関わる場合に）XenDesktop のアーキテクチャに直接的な影響を及ぼし ます。XenServer で仮想化される物理ハードウェアをリソースプールごとに分類すると、次のようになります。 リソースプール プロセッサ メモリ NIC ストレージ XenDesktop 8 コア 32GB ボンディング構成のデュアルギガビ 次の機能を持つティア 2 ファ ットイーサネット（仮想マシンアクセ イバチャネル SAN ファブリッ ス用） ク ボンディング構成のデュアルオンボ データ重複排除 ード NIC（管理インターフェイス用） 10,000RPM のドライブ Infrastructure（XDI） マルチパス構成のデュアルファイ バチャネル（書き込みキャッシュス トレージ用） XenApp 16 コア 64GB Infrastructure（XAI） ボンディング構成のデュアルギガビ 次の機能を持つティア 2 ファ ットイーサネット（仮想マシンアクセ イバチャネル SAN ファブリッ ス用） ク ボンディング構成のデュアルオンボ データ重複排除 ード NIC（管理インターフェイス用） 10,000RPM のドライブ マルチパス構成のデュアルファイ バチャネル（書き込みキャッシュス トレージ用） ボンディング構成のデュアルギガビ 次の機能を持つティア 2 ファ Services ットイーサネット（仮想マシンアクセ イバチャネル SAN ファブリッ Infrastructure ス用） ク （PSI-Main） ボンディング構成のデュアルオンボ データ重複排除 ード NIC（管理インターフェイス用） 10,000RPM のドライブ Provisioning 4 コア 16GB マルチパス構成のデュアルファイ バチャネル（vDisk ストレージ用） Provisioning 2 コア 4GB ボンディング構成のデュアルギガビ Services ットイーサネット（仮想マシンアクセ Infrastructure ス用） （PSI-Remote） ボンディング構成のデュアルオンボ ローカルストレージ 11 リソースプール プロセッサ メモリ NIC ストレージ ード NIC（管理インターフェイス用） Hosted Desktop Infrastructure（HDI） 8 コア 128GB ボンディング構成のデュアルギガビ 次の機能を持つティア 2 ファ ットイーサネット（仮想マシンアクセ イバチャネル SAN ファブリッ ス用） ク ボンディング構成のデュアルオンボ データ重複排除 ード NIC（管理インターフェイス用） 10,000RPM のドライブ マルチパス構成のデュアルファイ バチャネル（書き込みキャッシュス トレージ用） 各リソースプールに対して規定されているハードウェアは、複数の物理サーバーにわたる冗長性を確保しながら そのプールでサポートする必要のある仮想マシン数の初期段階における見積もりに基づいています。たとえば、 Provisioning Services は主としてネットワークスループットに影響を受けます。単一の XenServer で過度に多く の Provisioning Services をホストすると、物理プロセッサやメモリが完全に消費される前に、物理ネットワークに 大きな負荷がかかります。プロセッサのコア数とメモリ量を減らすと、ネットワークの負荷が最大に達したときに XenServer ですべてのリソースが完全に消費されるようになります。各リソースプールでは Provisioning Services ストリームを受信または送信するため、十分なネットワーク帯域幅を確保することが不可欠です。このよ うなネットワーク要件があるため、PSI-Remote を除く各 XenServer には、3 セットのネットワークカードを搭載しま す。 デュアルポートのオンボード NIC をボンディングし、この NIC で XenServer の管理処理のみをサポートしま す。 別のボンディング構成のギガビットイーサネットポートのペアを使用して、仮想マシンのアクセス （Provisioning Services ストリーム、エンドユーザー接続、ネットワークサービス、その他）をサポートします。 各 XenServer にデュアルファイバチャネルカードを搭載して、ファイバチャネルストレージバックエンドへのマ ルチパスを有効にします。いずれかのファイバチャネルカード、スイッチ、ポートで障害が発生した場合は、 XenServer によって入出力処理が他のファイバチャネルカードに透過的に転送されます。 SAN バックエンドにデータを格納すると、XenServer は仮想マシンの高可用性（次の節を参照）を提供できるよう になります。SAN ストレージを使用すると、リソースプール内のすべての XenServer から各仮想マシンのストレー ジにアクセスできるようになります。仮想マシンに定義されたストレージへアクセスできるため、どの XenServer で も仮想マシンをホストできるようになります。SAN ストレージに格納されるデータには、Provisioning Services の 書き込みキャッシュおよびサーバーデータが含まれます。ピーク時間帯には各ホステッドデスクトップにつき 20 IOPS（1 秒あたりの入出力処理数回数）が発生し、日中の他の時間帯ではこれより IOPS が減少すると予測され ます。処理量が増加する時間帯にも良好な応答時間が得られるように、10,000 RPM のドライブとデータ重複排 除機能を備えたティア 2 の統合 SAN ストレージを使用します。リモートオフィスに設置する Provisioning Services Infrastructure（PSI-Remote）プールでは、メインサイト内の Provisioning Services Infrastructure プールと比較 して、ハードウェア仕様が大幅に軽減されています。PSI-Remote プールは、ストリーム配信デスクトップを使用す 12 る支社オフィス（ニューヨーク、アトランタ、サンフランシスコ、シアトル）の冗長構成の Provisioning Services サー バーをホストします。 注：仮想マシンハードウェアの規定については、以降のコンポーネントの設計に関する節でより詳しく説明します。 キャパシティのプランニング XenDesktop 環境における適正なハードウェアの数量を判断することは、エンドユーザーに許容範囲内のパフォ ーマンスを提供しながらソリューションのコストを最小限に抑える上で大変重要です。不要なハードウェアを追加 すると、ハードウェアコスト、サポートコスト、電力コストが大幅に増加します。次の表に、「付録 I：参考例企業の詳 細」のシナリオに基づいて算出した XenDesktop インフラストラクチャの初期段階の見積もり内容を示します。 コンポーネント サイト マイアミ デスクトップ 合計 Provisioning Desktop Web Interface XenServer Services Controller ホステッド： ローカルサーバ サーバー数： サーバー数：2 XenServer の合計数：119 サーバ 3800 ー数：9 4 （4:1 の割合） ー （40:1 の割合） （2:1 の割合） （4:1 の割合） ストリーム配信： 支社オフィスの Provisioning Services 1000 サーバー数：4 データセンター：6（5+1） （1:1 の割合） 支社オフィス： 4 デスクトップ：105（95+10%） XenDesktop Controller：2（1+1） Web Interface：2（1+1） ロサン ホステッド： ローカルサーバ サーバー数： サーバー数：2 XenServer の合計数：62 サーバ ゼルス 1800 ー数：6 2 （4:1 の割合） ー （40:1 の割合） （2:1 の割合） （4:1 の割合） ストリーム配信： 支社オフィスの Provisioning Services 600 サーバー数：4 データセンター：4（3+1） （1:1 の割合） 支社オフィス： 4 デスクトップ：50（45+10%） XenDesktop Controller：2（1+1） Web Interface：2（1+1） ロンドン ホステッド：800 サーバー数：3 サーバー数： サーバー数：2 XenServer の合計数：29 サーバ （40:1 の割合） （2:1 の割合） 2 （4:1 の割合） ー （4:1 の割合） デスクトップ：22（20+10%） Provisioning Services：3（2+1） XenDesktop Controller：2（1+1） Web Interface：2（1+1） 13 コンポーネント 香港 合計 ホステッド：800 サーバー数：3 サーバー数： サーバー数：2 XenServer の合計数：29 サーバ （40:1 の割合） （2:1 の割合） 2 （4:1 の割合） ー （4:1 の割合） デスクトップ：22（20+10%） Provisioning Services：3（2+1） XenDesktop Controller：2（1+1） Web Interface：2（1+1） 注：ここで算出した XenServer サーバーの数には、XenApp サーバーをホストするために必要なサーバーの数は 含まれていません。初期レベルの冗長性を確保するために、この初期段階の見積もりでは一定の小さな割合で ハードウェア量が追加されています。この追加のキャパシティは、ハードウェア障害に対処するために役立ちま す。 また、同時に 1,500 の XenDesktop プールサービスが起動されことが見積もられていますが、この企業の拠点の 地理的な配置も考慮に入れる必要があります。たとえば、マイアミのデータセンターでは 3,800 のホステッドデス クトップをサポートしますが、ユーザーは 2 つの異なるタイムゾーンに分散されています。デスクトップ接続の最初 のピークは、米国東部時間の午前 8:00 に発生します。その 1 時間後、米国中部時間（ミネアポリスおよびヒュー ストン）のユーザーが接続することで、ホステッドデスクトップ起動のピークがもう一度発生します。このように XenDesktop サーバーファームが複数のタイムゾーンに分散されていると、ホステッドデスクトップの同時起動数 も（特定の時間ではなく）数時間にわたって分散されるため、サーバーファームのスケーラビリティが向上します。 デスクトップ更新サイクルの関係から、ニューヨーク、アトランタ、サンフランシスコ、シアトルの各支社のユーザー は、ホステッドデスクトップではなくローカルデスクトップを使用できます。これらのデスクトップは、インストール済 みデスクトップとして配備するのではなく、Provisioning Services からイメージを取得するストリーム配信デスクト ップとします。ストリーム配信の帯域幅要件を考慮して、影響を受けるこれらの各支店オフィスに一対の Provisioning Service サーバーを割り当てます。それにより、データセンターの Provisioning Services サーバー の負荷が軽減されます。 高可用性 XenServer で XenDesktop 環境を仮想化すると、次の 3 つの異なるレベルの高可用性が得られます。 保護する：保護対象のサーバーは、物理サーバーで障害が発生すると自動的に再起動されます。保護対象 の仮想マシンは、使用可能なリソースを保持している別の XenServer で起動されます。重要度が最も高いシ ステムのみを保護するようにしてください。 可能なら再起動：仮想マシンをホストしている物理サーバーで障害が発生した場合、その仮想マシンは、 XenServer リソースプール内に十分なリソースがある場合にのみ再起動されます。一定レベルの冗長性が 既に組み込まれている XenDesktop インフラストラクチャコンポーネントでは、通常この設定を指定します。 再起動しない：仮想マシンをホストしている物理サーバーで障害が発生した場合、その仮想マシンは、他のシ ステムまたは管理者によって再起動されるまでオフのままになります。 14 これら 3 つの高可用性オプションに基づいて、次の表に各種リソースプール内のコンポーネントに対する推奨設 定を示します。 コンポーネント 保護レベル 理由 XenDesktop プライマリ：保護する 少なくとも 1 つの XenDesktop Controller の稼動を Controller： セカンダリ：可能なら再起動 保証する必要があります。スケーラビリティおよび リソースプール：XDI フォールトトレランスを確保するために、追加のコン トローラを設置することをお勧めします。 Web Interface プライマリ：保護する ユーザーがデスクトップやアプリケーションにアクセ セカンダリ：可能なら再起動 スできるように、少なくとも 1 つの Web Interface の 稼動を保証する必要があります。スケーラビリティ およびフォールトトレランスを確保するために、追加 の Web Interface サーバーを設置することをお勧 めします。 データストア 保護する XenDesktop データストアは、XenDesktop サーバ ーファームを正常に機能させるために不可欠です。 新しい仮想デスクトップ接続を確立するためには、 データストアが稼動している必要があります。 ライセンスサーバー 保護する Citrix ライセンスサーバーは、XenDesktop、 XenApp、および Provisioning Services を正常に 機能させるために不可欠です。 リソースプール：HDI ホステッドデスクトップ 再起動しない あるユーザーのホステッドデスクトップで障害が発 生した場合、そのユーザーは直ちに別のホステッド デスクトップに接続できます。接続時には、 XenDesktop グループのアイドル設定に基づいて、 適切な数のホステッドデスクトップが XenDesktop Controller によって起動されます。ただし、仮想デ スクトップがプールされていない専用のデスクトップ である場合、ユーザーはホステッドデスクトップが再 起動するまで待つ必要があります。この企業の設 計では、専用のホステッドデスクトップは定義されて いません。 リソースプール：XAI XenApp Controller プライマリ：保護する 少なくとも 1 つの XenApp Controller の稼動を保証 セカンダリ：可能なら再起動 する必要があります。追加の XenApp Controller を 15 コンポーネント 保護レベル 理由 提供すると、環境内で一定のフォールトトレランス が得られます。 アプリケーションハブ プライマリ：保護する アプリケーションのストリーム配信を行うためには、 セカンダリ：可能なら再起動 少なくとも 1 つのアプリケーションハブの稼動を保 証する必要があります。スケーラビリティおよびフォ ールトトレランスを確保するために、追加のアプリケ ーションハブを設置することをお勧めします。 XenApp ホスト 可能なら再起動 XenApp ホストは、ホステッドアプリケーションを配 信するために不可欠です。これらは不可欠ですが、 他の XenApp ホストでユーザー負荷の一時的な増 加に対応することもできます。 データストア 保護する XenApp サーバーファームはデータストアがなくて も機能しますが、データストアがないと基盤インフラ ストラクチャに変更を加えることができません。 リソースプール：PSI Provisioning Services 可能なら再起動 サーバーメインサイト Provisioning Services は、高可用性の独自の階層 を提供します。この環境は、1 つの Provisioning Services サーバーで障害が発生してもユーザーに 影響が及ばないように設計されています。後述の Provisioning Services および XenServer の設計に 従って、サーバーで障害が発生した場合は常に、 使用可能な XenServer 上でそのサーバーが自動 的に再起動されます。 Provisioning Services サーバーリモートサイト 適用外 支社オフィスの Provisioning Services サーバー は、ローカルストレージを使用するように設定され ています。そのため、これらのサーバーは別の使 用可能な XenServer に移行されません。ただし、こ の設計では、単一の Provisioning Server で支店オ フィス全体に十分なキャパシティが提供されるよう になっています。 16 ストレージ 各 XenDesktop コンポーネントは XenServer 上で仮想化されますが、そのためには共有ストレージを割り当てて、 物理ホスト間のライブマイグレーション（XenMotion）を有効にする必要があります。必要なストレージ容量は各コ ンポーネントによって異なります。ホステッドデスクトップ、Desktop Controller、および Web Interface サーバーは Provisioning Services からストリーム配信されるため、これらで必要となるのは書き込みキャッシュ用のストレー ジのみです。次の表に、この企業の環境で必要となるストレージ領域の容量に関する初期段階の予想値を示し ます。これらは、重複排除や未使用領域を考慮せずに算出した最大使用量の予想値です。 コンポーネント サイト デスクトップ Provisioning Desktop Services Controller Web Interface （メインサイト） 一時ストレージ：19.8TB サーバー：220 GB 一時ストレージ： 一時ストレージ： （3,800 のホステッドデス ライブイメージ： 24GB 8GB クトップ） 100GB ロサンゼル 一時ストレージ：9TB サーバー：120 GB 一時ストレージ： 一時ストレージ： ス （1,800 のホステッドデス ライブイメージ： 16GB 8GB クトップ） 100GB 一時ストレージ：4TB サーバー：60 GB 一時ストレージ： 一時ストレージ： （800 のホステッドデスクト ライブイメージ： 8GB 8GB ップ） 100GB 一時ストレージ：4TB サーバー：60 GB 一時ストレージ： 一時ストレージ： （800 のホステッドデスクト ライブイメージ： 8GB 8GB ップ） 100GB マイアミ ロンドン 香港 デスクトップ：この設計では、基本となる Provisioning Services イメージと異なる一時データを格納するため の書き込みキャッシュとして、各デスクトップにつき 5GB のストレージを割り当てることをお勧めしています。 これには、エンドユーザー監視データベース、ページファイル、および XenApp アプリケーションのストリーム 配信用プロファイルが含まれます。このストレージ領域は、デスクトップの電源をオフにすると解放されます。 ストレージはデスクトップの動作速度やパフォーマンスに直接影響するため、ティア 2 ストレージの使用をお 勧めします。ストレージ領域の実際の使用量は、ユーザーの使用パターンやデスクトップの稼働時間の長さ に大きく左右されます。平均使用量は推奨値の 5GB よりかなり低くなることが予想されますが、これについて は構築段階やテスト段階で確認する必要があります。また、ストレージの要件とコストをさらに削減するため にデータ重複排除を有効にします。 ストリーム配信デスクトップは、書き込みキャッシュとしてローカルストレージを使用します。一方、ホステッド デスクトップは、定義されている XenServer 共有ストレージを使用します。このソリューションでは、 Provisioning Server 上に書き込みキャッシュを格納する方法よりも高い書き込みキャッシュのパフォーマン 17 スが得られます。またこの機構によって、パフォーマンスが低下したり、ストレージの要件やコストが増加した りすることなく、最大の冗長性が得られます。 Provisioning Services：Provisioning Services サーバーはすべて、大きいサイズの Windows システムキャ ッシュを使用可能な 64 ビットのオペレーティングシステム上で実行します。システムキャッシュのサイズが大 きくなるため、Provisioning Services サーバーで vDisk データブロックを頻繁に要求する必要がなくなり、そ の結果ティア 1 ストレージファブリックの必要性が減少します。キャパシティについては、各サーバーでオペレ ーティングシステムおよび Provisioning Services のインストール用として 20GB のストレージが必要です。ま た、Provisioning Services では、現在のストリーム配信イメージまたはライブイメージの格納用として約 100GB のストレージが必要です（注：XenApp イメージは考慮されていません）。 デスクトップ：3 つのデスクトップイメージのそれぞれで 20GB Desktop Controller：1 つの Desktop Controller で 20GB Web Interface：1 つの Web Interface で 20GB Desktop Controller：各 Desktop Controller では、永続的なシステムレベルの情報および Provisioning Services の書き込みキャッシュの格納用として、5GB の共有ストレージが必要です。 Web Interface：各 Web Interface サーバーでは、永続的なシステムレベルの情報および Provisioning Services の書き込みキャッシュの格納用として、5GB の共有ストレージが必要です。 注：Provisioning Services を使用しない場合は、各ターゲットにつき 30GB と見積もると、約 144TB の永続ストレ ージが必要になります。 18 オペレーティングシステムのデリバリーの設計 XenDesktop は Provisioning Services を利用して、起動時に「白紙状態」のエンドポイント（ホステッドデスクトッ プ、ブレード PC、またはストリーム配信デスクトップ）にオペレーティングシステムを配信します。必要なスケーラビ リティとパフォーマンスが得られるよう、適切に Provisioning Services ソリューションを設計するには、ハードウェ ア仕様、高可用性オプション、およびキャッシュストレージを定義する必要があります。 Provisioning Servicesのオペレーティングシステム 配信するオペレーティングシステムのビットレベル（32 ビットまたは 64 ビット）は、場合によっては環境全体のキャ パシティに大きな影響を及ぼします。64 ビット版の Windows Server 2008 を実行しているシステムでは、より大 量のメモリがサポートされており、それをサーバーサブシステムに割り当てることができます。ただし、この企業で は 64 ビットプラットフォームに標準化する計画にまだ着手していないため、プロビジョニング対象のサーバーでは すべて 32 ビット版の Windows Server 2008 を使用します。ただし、Provisioning Server は例外です。 システムレベルの割り当て量を増加すると、Provisioning Services サーバーは利点を得ることができます。 vDisk 上の最近アクセスされたブロックはまずシステムキャッシュに格納され、その後通常はメモリに格納されま す。32 ビット版の Windows Server 2003 ではシステムキャッシュのサイズが 860MB に制限されていますが、64 ビット版の Windows Server 2008 では最大 1TB を使用できます。そのため、より多くの vDisk ブロックをメモリ上 に格納することができ、それ以降に同じブロックにアクセスしたときの読み取り時間が短縮されます（このような状 況は数百のユーザーが同じ vDisk にアクセスした場合に頻繁に発生します）。Provisioning Services システムの サーバー定義における RAM の容量は 1TB 未満ですが、64 ビット版では RAM のより多くの部分がシステムキャ ッシュとして使用されるため、イメージのデリバリーの処理速度が向上するとともに、物理サーバーへの影響が減 少します。 デスクトップとサーバーのデリバリー用の環境を最適化するために、Provisioning Services オペレーティングシス テムを次のように設定します。 システムキャッシュのパフォーマンスを最適化するように設定します。 /PAE オプションは有効にしません。 TCP オフロードは無効にします。 19 ハードウェア Provisioning Services サーバーは XenServer 上で仮想化されますが、各仮想 Provisioning Services サーバー には適切なハードウェア割り当て（プロセッサ、メモリ、ネットワークインターフェイス）を含める必要があります。以 下に、予定されている XenDesktop の設計に基づく推奨ハードウェア構成を示します。 コンポーネント プロセッサ メモリ NIC XenServer の 4 コア 16GB ボンディング構成のデュアルギガビットイーサネット（仮 物理ハードウェア 想マシンアクセス用） （メインサイト） ボンディング構成のデュアルオンボード NIC（管理インタ ーフェイス用） マルチパス構成のデュアルファイバチャネル（vDisk スト レージ用） 仮想 Provisioning 4 コア 8GB ボンディング構成のデュアルギガビットイーサネット（仮 Services ハードウェアの 想マシンアクセス用） 割り当て オンボード NIC（管理インターフェイス用） ファイバチャネル（vDisk ストレージ用） XenServer の 2 コア 4GB ボンディング構成のデュアルギガビットイーサネット（仮 物理ハードウェア 想マシンアクセス用） （リモートサイト） ボンディング構成のデュアルオンボード NIC（管理インタ ーフェイス用） 仮想 Provisioning 2 コア 2GB ボンディング構成のデュアルギガビットイーサネット（仮 Services ハードウェアの 想マシンアクセス用） 割り当て オンボード NIC（管理インターフェイス用） Provisioning Services は、通常、メモリやプロセッサに先立ってネットワークインターフェイスを最大限に利用しま す。これにより、メインサイトの単一の物理サーバーで、メモリやプロセッサを過度に割り当てることなく、2 つの Provisioning Services サーバーをホストすることができます。リモートサイトでは一部の少数のローカルユーザー にのみイメージを配信するため、リモートサイトの物理ハードウェア構成はメインサイトのハードウェア構成より低 くなっています。 注：Provisioning Services サーバーを XenServer 上で仮想化すると適切なスケーラビリティが得られない場合は、 Provisioning Services を物理サーバーからホストすることをお勧めします。 キャパシティのプランニング 仮想 Provisioning Services サーバーのデリバリーに使用する物理 XenServer システムの数は、単一の Provisioning Services サーバーでサポート可能なターゲットデバイスの数に基づいて判断します。この設計では 20 Web Interface および XenDesktop Controller のプロビジョニングを行うため、必要な XenServer と Provisioning Services サーバーの数を判断するときには、これらを考慮する必要があります。 注：ここで算出した Provisioning Services サーバーの数には、XenApp サーバーをストリーム配信するために必 要なサーバーの数は含まれていません。 コンポーネント サイト デスクトップ サーバーの合計数 XenDesktop Web Interface Controller Provisioning XenServer Services メインサイト マイアミ ホステッド：3800 4 つの仮想サーバ 2 つの仮想サーバー 9 つの仮想サーバー 6 つの物理サーバー ストリーム配信：400 ー数 必須： 1 必須： 8 必須： 5 必須：各サーバーフ 冗長： 1 冗長： 1 冗長： 1 ァームで 1 つ 冗長： 1 ロサンゼ ホステッド：1800 2 つの仮想サーバ 2 つの仮想サーバー 6 つの仮想サーバー 4 つの物理サーバー ルス ストリーム配信：300 ー 必須： 1 必須： 5 必須： 3 必須：各サーバーフ 冗長： 1 冗長： 1 冗長： 1 2 つの仮想サーバ 2 つの仮想サーバー 3 つの仮想サーバー 3 つの物理サーバー ー 必須： 1 必須： 2 必須： 2 必須：各サーバーフ 冗長： 1 冗長： 1 冗長： 1 2 つの仮想サーバ 2 つの仮想サーバー 3 つの仮想サーバー 3 つの物理サーバー ー 必須： 1 必須： 2 必須： 2 必須：各サーバーフ 冗長： 1 冗長： 1 冗長： 1 適用外 2 つの仮想サーバー 2 つの物理サーバー 必須： 1 必須： 1 冗長： 1 冗長： 1 2 つの仮想サーバー 2 つの物理サーバー 必須： 1 必須： 1 ァームで 1 つ 冗長： 1 ロンドン ホステッド：800 ァームで 1 つ 冗長： 1 香港 ホステッド：800 ァームで 1 つ 冗長： 1 支社サイト ニューヨ ストリーム配信：450 適用外 ーク ストリーム配信：150 適用外 適用外 21 コンポーネント サンフラ ストリーム配信：200 サーバーの合計数 適用外 適用外 ンシスコ ストリーム配信： 適用外 適用外 100 冗長： 1 冗長： 1 2 つの仮想サーバー 2 つの物理サーバー 必須： 1 必須： 1 冗長： 1 冗長： 1 2 つの仮想サーバ 2 つの物理サーバー ー 必須： 1 必須： 1 冗長： 1 冗長： 1 Provisioning Services は、ストリーム配信デスクトップとホステッドデスクトップの両方にイメージを配信し、それ により、保守と管理を簡素化しながらユーザーが各自の物理ハードウェアを利用できるようにします。メインデー タセンターと、ストリーム配信デスクトップを含む 4 つの支社オフィスとの間のネットワーク接続の帯域幅が十分で はないため、ローカルの Provisioning Services サーバーが必要になります。環境を簡素化するために、支社サ イトのアーキテクチャは、Provisioning Services が XenServer 上の仮想サーバーとなっているメインデータセンタ ーと同様に設計されています。 注：Provisioning Services のキャパシティは、1 サーバーあたり 500 ストリームと予測しています。これはこの段 階の設計における値です。1 サーバーあたりのストリーム数は、プロジェクトの構築段階またはテスト段階で決定 します。 高可用性 ホステッドデスクトップ、ストリーム配信デスクトップ、XenDesktop Controller、Web Interface、および XenApp は、 Provisioning Services によって配信されます。ある Provisioning Services サーバーで障害が発生した場合、接 続されているターゲットデバイスは別の使用可能な Provisioning Services サーバーからストリーム接続を再取得 できなければなりません。高可用性環境では、各 Provisioning Services サーバーが他の Provisioning Services サーバーと同じ vDisk にアクセスできるようにする必要があります。メインデータセンターでは、図 5 のようにネット ワーク接続ストレージデバイスを使って vDisk イメージをホストしています。 22 図 5：データセンターでの Provisioning Services の高可用性 共有ストレージデバイスを使用せずに Provisioning Services の高可用性を確保することも可能ですが、その場 合は各サーバー上に vDisk イメージを置く必要があります。vDisk の更新時には、新しい vDisk イメージをすべて の Provisioning Services サーバー間で同期させる必要があります。さまざまなデスクトップ、XenDesktop Controller、Web Interface サーバー、XenApp サーバー用の複数の vDisk ファイルがあるため、それらの vDisk イメージをすべての Provisioning Services サーバー間で同期した状態に保つためには、追加の管理作業が必 要になります。共有ストレージデバイスを使用すると、環境の管理が簡素化されます。 また、ブートアップシーケンス中の冗長性を確保するためには、ブートファイルに最大 4 つの冗長構成の Provisioning Services のアドレスを加える必要があります。これには、任意の 4 つの Provisioning Services の アドレスを使用できます。各 XenServer は 2 つの Provisioning Services サーバーのみをホストしているため、4 つのアドレスを使用すると、Provisioning Services の冗長性とともに XenServers 間の冗長性が得られます。し かし、ストリーム配信デスクトップを配信している 4 箇所の支社オフィスでは、共有ストレージバックエンドはそれ 程重要ではありません。そのため、共有ストレージソリューションを使用する代わりに、次の図のようにローカルス トレージが使用されています。 23 図 6：支社サイトでの高可用性 Web Interface および XenDesktop Controller にはデータセンターの Provisioning Services サーバーからイメ ージが配信されるため、支社サイトの Provisioning Services サーバーでは 100～500 の物理的なローカルデス クトップにのみイメージを配信します。そのため、管理しなければならないイメージは少数です。データセンターで はイメージの同期という難題に対処するために共有ストレージが重要になりますが、支社サイトでは、2 つの Provisioning Services サーバーと数個のデスクトップイメージしかないため、この問題は生じません。しかし、デ ータセンターベースの Provisioning Services サーバーと同様に、支社サイトで高可用性を確保するためには、ロ ーカル Provisioning Services サーバーでローカルディスク上と同じ場所に vDisk イメージを格納する必要があり ます。 このようなリモートサイトの構成にも、Provisioning Services のブートファイルへの変更が含まれます。2 つのロ ーカル Provisioning Services サーバーのアドレスを追加してブートファイルを更新します。 キャッシュ Provisioning Services と接続される各ターゲットデバイスは（それがホステッドデスクトップ、ストリーム配信デス クトップ、XenDesktop Controller、Web Interface サーバー、XenApp サーバーのいずれであるかにかかわら 24 ず）そのターゲットデバイスのオペレーティングシステムが格納された共有イメージファイルを使用します。各イメ ージは同類のターゲットデバイス間で共有されるため、固有のイメージの数が減少し、管理が容易になるとともに デバイス間の一貫性が保証されます。共有イメージは読み取り専用であるため、ターゲットデバイスの稼動期間 中にターゲットデバイス用の書き込み可能キャッシュを維持する必要があります。次の表に、この XenDesktop 環 境の規模とスコープに基づいて定めた、Provisioning Services の書き込みキャッシュの推奨格納場所を示しま す。 ストリーム配信 設計に関する決定事項 理由 ターゲットデバイスのハードディスク上のキャッ ネットワークトラフィックが軽減 シュ（共有ストレージ） します。 ターゲットデバイスのハードディスク上のキャッ Provisioning Service サーバ シュ（ローカルストレージ） ーへ影響が軽減します。 ターゲットデバイスのハードディスク上のキャッ 仮想マシンのライブマイグレー シュ（共有ストレージ） ション（XenMotion）が容易にな ターゲットデバイスのハードディスク上のキャッ ります。 シュ（共有ストレージ） ローカル環境の範囲内で通信 ターゲットデバイスのハードディスク上のキャッ が行われるため、応答性が向 シュ（共有ストレージ） 上します。 コンポーネント ホステッドデスクトップ ストリーム配信デスクトップ XenDesktop Controller XenApp サーバー Web Interface サーバー ターゲットデバイスのハードディスクに書き込みキャッシュを格納するには、ローカルディスクに一定の空き容量 が必要です。デスクトップのストレージに関する設計は、「デスクトップの設計」で規定します。 サーバーファームの設計 物理的なローカルデスクトップへのデスクトップデリバリーを容易にするために、数箇所の支社（アトランタ、ニュ ーヨーク、サンフランシスコ、シアトル）に Provisioning Service サーバーを設置します。これは、Provisioning Services サーバーファームの構成を設計する際の重要な考慮事項です。サイト、データセンター、支社オフィス のそれぞれを別々の Provisioning Services サーバーファームとして作成することも可能ですが、そのような構成 では 4 つのメインデータセンターからインフラストラクチャを集中管理することができません。したがって、 Provisioning Services サーバーファームは次のように設計されています。 サイト名 サーバーファーム サイトの種類 サーバー ストア コレクション データセンター：マイアミ マイアミ マイアミファーム データセンター MIAPVS-1 XenApp のイメージ XenApp サーバー ～ XenDesktop のイメージ XenDesktop Controller MIAPVS-9 Web Interface のイメージ Web Interface ホステッドデスクトップのイメー ホステッドデスクトップ 25 サイト名 サーバーファーム サイトの種類 サーバー ストア ジ コレクション ストリーム配信デスクトップ ストリーム配信デスクトップの イメージ ニューヨーク アトランタ マイアミファーム マイアミファーム 支社オフィス 支社オフィス NYPVS-1 ストリーム配信デスクトップの ストリーム配信デスクトップ NYPVS-2 イメージ ATLPVS-1 ストリーム配信デスクトップの ATLPVS-2 イメージ LAPVS-1 XenApp のイメージ XenApp サーバー ～LAPVS-6 XenDesktop のイメージ XenDesktop Controller Web Interface のイメージ Web Interface ホステッドデスクトップのイメー ホステッドデスクトップ ジ ストリーム配信デスクトップ ストリーム配信デスクトップ データセンター：ロサンゼルス ロサンゼルス ロサンゼルスフ データセンター ァーム ストリーム配信デスクトップの イメージ サンフランシ ロサンゼルスフ スコ ァーム シアトル ロサンゼルスフ 支社オフィス 支社オフィス ァーム SFOPVS-1 ストリーム配信デスクトップの ストリーム配信デスクトップ SFOPVS-2 イメージ SEAPVS-1 ストリーム配信デスクトップの SEAPVS-2 イメージ UKPVS-1 XenApp のイメージ XenApp サーバー UKPVS-2 XenDesktop のイメージ XenDesktop Controller Web Interface のイメージ Web Interface ホステッドデスクトップのイメージ ホステッドデスクトップ ストリーム配信デスクトップのイメ ストリーム配信デスクトッ ージ プ HKPVS-1 XenApp のイメージ XenApp サーバー HKPVS-2 XenDesktop のイメージ XenDesktop Controller Web Interface のイメージ Web Interface ホステッドデスクトップのイメージ ホステッドデスクトップ ストリーム配信デスクトップのイメ ストリーム配信デスクトッ ージ プ ストリーム配信デスクトップ データセンター：ロンドン ロンドン ロンドンファーム データセンター データセンター：香港 香港 香港ファーム データセンター Provisioning Services のインフラストラクチャは、4 つのデータセンターに応じて 4 つの異なるサーバーファーム に分割されています。マイアミファームとロサンゼルスファームは、それぞれ 3 つのサイトで構成されており、サイ 26 トは Provisioning Services サーバーをホストするデータセンターおよび支社オフィスに対応しています。メインデ ータセンターのサイトは、各種ストリーム用のイメージストアとデバイスコレクションで構成されています。一方支 社オフィスは、ストリーム配信デスクトップのストアとコレクションのみからなります。 Provisioning Services サーバーが数箇所の支社オフィスに配備されているものの、この環境はメインデータセン ターから集中管理されています。イメージのデリバリーが最適化されるように、ターゲットデバイス（ホステッドデス クトップ、ストリーム配信デスクトップ、XenDesktop Controller、Web Interface サーバー、XenApp サーバー）は ローカルサイトからストリームを受信します。 1 つのサーバーファーム内の Provisioning Services サーバーでは同じイメージストアが使用されるため、それら のサーバー自体では同じ場所で vDisk イメージを取得できます。しかし、支社のサーバーではローカルストレージ およびデータセンターサーバーの共有ストレージが使用されるため、パスが異なります。これに対処するために、 支社オフィスのサーバーでは、ストリーム配信デスクトップのイメージストアに対して「パスのオーバーライド」を行 っています。支社の Provisioning Services は共有ストレージのパスをオーバーライドしてローカルパスを使用し ます。 27 アプリケーションデリバリーの設計 ユーザーの要件に応じてアプリケーションを提供することは、デスクトップの設計における重要な課題です。この 企業では約 80%のユーザーがデスクトップを必要としています。また、残りの 20%のユーザーもデスクトップのパ ーソナライゼーションが不要なアプリケーションを必要としています。両方のグループをサポートするソリューショ ンを作成するためには、2 つの異なる環境（デスクトップと非デスクトップ）を作成するのではなく、これらのユーザ ー要件をまとめて考慮する必要があります。アプリケーションデリバリーの設計に関するこの節では、アプリケー ションとデリバリーに焦点を当てながら、すべてのユーザー要件を満たす基盤を構築します。 アプリケーション 使用アプリケーションの種類は、個々のユーザーが仮想デスクトップを必要とするかどうかを判断する際に重要 な役割を果たします。アプリケーションの中には、マルチメディアや、ローカルデバイスのサポート、大量のリソー スを必要とするものもあれば、複雑な相互運用設定を持つものもあります。仮想デスクトップ環境で適切なアプリ ケーションデリバリーを行うためには、各アプリケーションの概略を理解する必要があります。 以下に、この企業のアプリケーション環境に基づいた確認事項を示します。 アプリケーション ユーザーグループ アプリケーションの特徴 オフィス生産性 すべて 文書処理、電子メール、表計算、個人用データベース、プレゼンテーション 用の多数の独立した（しかし統合されている）アプリケーションからなりま す。これらのアプリケーションは多くの場合単独で使用されますが、他のア プリケーションで必要となることもあります。 時間/人員管理 すべて 給与制の従業員はアプリケーションを使って作業時間を入力し、時給制の 従業員は作業時間を自動的に更新する機器を工場内で利用しています。 管理職者はこのアプリケーションの「人員管理」セクションで、時給制およ び給与制の従業員の作業時間を承認しています。時給制の従業員につい ては、給与課ではこの情報を使って全従業員の給与を削減しています。 ERP エンジニアリング さまざまなチームが、製造品に必要なリソースを調整するために ERP アプ 製造 リケーションを使用しています。このシステムは、リソースプランニング、資 財務 材プランニング、在庫スケジューリング、コスト管理といったさまざまなバッ クエンドシステムと連結されています。 CRM セールス 多数のグループが CRM アプリケーションを使って、購入、サポート契約、 サポート サポート電話、顧客の連絡先などの顧客情報を追跡管理しています。この マーケティング システムでは、顧客情報の取得と保存にバックエンドデータベースを利用 しています。 CAD/CAM エンジニアリング 設計図はエンジニアが作成し、製造部の従業員が工場内の配置を適切に 製造 行うために利用しています。CAD/CAM アプリケーションを使用しているユ ーザーは、極めてグラフィカルな図面を作成・利用しています。広範な機能 28 アプリケーション ユーザーグループ アプリケーションの特徴 を持つ複雑なアプリケーションであるため、多くのユーザーは生産性を上 げるためにユーザーインターフェイスをカスタマイズしています。この CAD/CAM アプリケーションでは、イメージの作成とレンダリングに大量の RAM と処理能力が使用される可能性があります。 DTP マーケティング DTP（デスクトップパブリッシング）アプリケーションを使って、自社製品に 関する極めてグラフィカルなコンテンツ（パンフレット、バナー、Web ペー ジ）を製作しています。これらの製作物は、業界誌、印刷広告、電子メー ル、Web ページなどに使用されています。利用するメディアに応じて、製作 物は静止グラフィックまたはアニメーション/ビデオになります。 マルチメディアアプ マーケティング リケーション DTP アプリケーションの一部として、一連のマルチメディアアプリケーション を音声コンテンツや動画コンテンツの作成に使用しています。これらのマ ルチメディアアプリケーションでは、ビデオの直接操作や DTP アプリケーシ ョンとの統合が可能です。 コラボレーション すべて コラボレーションアプリケーションを使って、複数のユーザーがあらゆる場 所から、同じ文書、プレゼンテーション、ビデオ上で共同作業できるように なっています。 管理 IT 部門では、一連のアプリケーションを利用してインフラストラクチャのサ IT ポートと保守を行っています。これらのアプリケーションは、IT 環境内のさ まざまな部分にネットワーク経由で接続します。 開発ツール サポート サポートチームでは、製造品のソフトウェアプログラミングに関する問題を 調査するために、一連のプログラミングツールを使用しています。 一部のユーザーのみがデスクトップを必要としています。これらのユーザーのデスクトップには、すべてのアプリ ケーションがインストールされているわけではありません。アプリケーションによっては、XenApp から配信するの が適切なものもあります。実際、次の表に示すように、デスクトップ上で実行しているのは一部の少数のアプリケ ーションのみで、大部分のアプリケーションは XenApp サーバー上で動作しています。 アプリケーション 配信場所 理由 オフィス生産性 モバイル/オフラインデスクトップ 切断状態のモバイル/オフラインデバイスを使用す ストリーム配信デスクトップ るユーザーを含むすべてのユーザーが、オフィス ホステッドデスクトップ 生産性アプリケーションを必要とします。また、他 XenApp サーバー のアプリケーションでもオフィス生産性アプリケー ションが利用されているため、このアプリケーション セットは仮想デスクトップおよび XenApp サーバー に含まれています。 時間/人員管理 XenApp サーバー この時間管理アプリケーションは、限られた機能を 29 アプリケーション 配信場所 理由 持つ自己完結型のアプリケーションですが、バック エンドデータベースへの接続を必要とします。この アプリケーションは XenApp からすべてのユーザ ーに対してホストされます。 ERP XenApp サーバー すべてのシステムが連係して正常に機能するよう に、この ERP アプリケーションセットは厳重に管理 されたさまざまな設定で構成されています。このア プリケーションは特定のワークフローに従って使用 する必要があり、あらかじめプログラミングされて いる操作から逸脱することはできません。このよう な厳重に管理された設定を維持するために、ERP アプリケーションは XenApp でホストされます。 CRM XenApp サーバー この CRM アプリケーションのユーザーは、標準の ワークフローに従って、顧客の連絡先情報の検索 と新規追加を行います。ユーザーのワークフロー では環境に対するカスタマイズは不要なため、 CRM アプリケーションは XenApp でホストされま す。XenApp によって、アプリケーション構成環境 内での標準化が実現されます。 CAD/CAM ストリーム配信デスクトップ このアプリケーションはデスクトップ統合に適してい ホステッドデスクトップ ます。CAD/CAM アプリケーションによって消費さ れるリソースは、ホステッドデスクトップやストリー ム配信デスクトップに割り当てられる量に制限され ます。また、ユーザーは（ホステッドまたはストリー ム配信）デスクトップを使用することによって、 XenApp 環境より簡単に各自の操作環境をパーソ ナライズできます。 DTP モバイル/オフラインデスクトップ この DTP アプリケーションは、デスクトップデリバリ ストリーム配信デスクトップ ー（ホステッドまたはストリーム配信）に最も適して ホステッドデスクトップ います。ユーザーはしばしば、特定のキャンペーン 用のコンテンツを製作するためにアプリケーション の設定をカスタマイズする必要があります。コンテ ンツ製作のためにバックエンドに接続する必要は ないため、このアプリケーションはオフラインでも使 用できるように提供されます。 マルチメディアアプリケー モバイル/オフラインデスクトップ マルチメディア機能の利用やアプリケーションのカ 30 アプリケーション 配信場所 理由 ション ストリーム配信デスクトップ スタマイズが必要なため、これらのマルチメディア ホステッドデスクトップ アプリケーションはデスクトップデリバリー（ホステッ ドまたはストリーム配信）に最も適しています。ま た、マルティメディアコンテンツ作成機能は DTP ア プリケーション内で利用されるため、両方のアプリ ケーションセットを同じ場所から配信するのが最適 です。 コラボレーション クラウド このコラボレーションソリューションは、クラウド内で ホストされます。クラウドベースのソリューションを 使用することによって、あらゆる場所からあらゆる デバイスを使って共同作業を行うことができます。 また、クラウドベースのソリューションを使用するこ とによって、すべてのユーザーがインタラクティブ に作業できる環境を確保しながら、ローカル IT チ ームによるサポートが必要なアプリケーションとシ ステムの数を減らすことができます。 管理 ストリーム配信デスクトップ これらの IT アプリケーションは通常特定のワークフ ホステッドデスクトップ ローで使用しますが、アプリケーションの特別な使 用シナリオが必要になったり、新しいプラグインが 必要になったりなど、さまざまなケースがあります。 これらのアプリケーションをデスクトップに配信する と、ユーザーは引き続きこれらのアプリケーション を独自の方法で使用できます。これらのアプリケー ションでは機能上ネットワーク接続が必要なため、 オフラインアクセスは拒否されます。 開発ツール ストリーム配信デスクトップ これらの開発ツールでは、プログラミング関連の問 ホステッドデスクトップ 題のデバッグ中にユーザーが各自の環境をカスタ マイズしなければならないことがよくあります。ま た、XenApp やターミナルサービスシステムでは、 このソリューションのマルチユーザー機能の関係 から、これらのツールの多くは正常に機能しませ ん。 既に説明したように、データの要件、相互運用性、標準化といった要因から、これらのアプリケーションの多くは XenApp サーバー上でも機能します。 31 統合 ホステッドデスクトップ、ストリーム配信デスクトップ、モバイル/オフラインデスクトップ、または XenApp サーバー へのアプリケーションのデリバリー方法は、持続可能性に大きな影響を及ぼします。XenDesktop ソリューション は、アプリケーション統合に関する次の 3 つの固有のオプションを提供します。 インストール済み：オペレーティングシステムにインストールされているアプリケーションが、システム（ストリー ム配信デスクトップ、モバイル/オフラインデスクトップ、またはホステッドデスクトップのイメージ）の一部となり ます。ホステッドデスクトップとストリーム配信デスクトップでは、特定のデスクトップイメージを使用するすべ てのユーザーにアプリケーションが提供されますが、アプリケーションはデスクトップイメージ内で集中管理さ れます。モバイル/オフラインデスクトップでは、インストール済みアプリケーションはエンドポイントで管理され ます。 ホステッド：ホステッドアプリケーションは、そのアプリケーションの実行権限を持つユーザーにのみ提供され ます。アクセス権を持っていないユーザーに対しては、該当するアプリケーションのアイコンは表示されませ ん。アプリケーションを起動すると、処理はすべてリモート XenApp サーバー上で実行されます。アプリケーシ ョン設定の変更は同じ XenApp サーバー上の他のユーザーに影響を及ぼすため、これらのアプリケーション は多くの場合パーソナライゼーションの観点から厳重に管理されます。 ストリーム配信：ストリーム配信アプリケーションは、権限を持つユーザーにのみ提供されます。アプリケーシ ョンが選択されると、そのアプリケーションのビットデータがネットワーク経由でターゲットデバイス（ホステッド デスクトップ、ストリーム配信デスクトップ、またはモバイル/オフラインデスクトップ）に送信され、分離環境内 で実行されます。ストリーム配信アプリケーションは集中管理されます。ストリーム配信アプリケーションは、 ネットワーク接続が切断された場合も動作し続けます（モバイル/オフラインデスクトップ上のリモートユーザ ー）。 この企業のアプリケーションセットのアプリケーション統合方法は、次のように規定されています。 アプリケーション アプリケーション統合方法 理由 オフィス生産性 インストール済みデスクトップにスト オフィスアプリケーションはすべてのターゲットデバイス リーム配信 （ストリーム配信デスクトップ、モバイル/オフラインデスクト ストリーム配信デスクトップにストリ ップ、ホステッドデスクトップ、XenApp サーバー）に簡単に ーム配信 インストールできますが、アプリケーションのストリーム配 ホステッドデスクトップにストリーム 信機能を使用すると、すべてのターゲットデバイス用の単 配信 一のアプリケーションプロファイルが作成されます。これに XenApp サーバーにストリーム配 より、アプリケーションの保守が簡素化され、ターゲット間 信 および環境間での一貫性が保証されます。また、更新が 必要な場合は、集中管理しているプロファイルを更新する と、すべてのターゲットに自動的に更新が反映されます。 時間/人員管理 XenApp からホスト 時間管理アプリケーションは XenApp サーバーにインスト ールします。詳しく調査したところ、このアプリケーションに は、XenApp のアプリケーションのストリーム配信機能に 32 アプリケーション アプリケーション統合方法 理由 よるプロファイル作成やストリーム配信が現時点では不可 能な Windows サービスが含まれていました。 ERP XenApp からホスト ERP アプリケーションは、XenApp サーバーにインストー ルして XenApp サーバーからホストします。広範な設定が あること、頻繁に更新されること、また ODBC 設定が必要 なことから、アプリケーションをストリーム配信する方法で はなく、インストールする方法を使用します。 CRM XenApp からホスト CRM アプリケーションは、XenApp サーバーにインストー ルして XenApp サーバーからホストします。この CRM ア プリケーションでは ODBC 接続設定が必要なため、ストリ ーム配信する方法ではなくインストールする方法を使用し ます。 CAD/CAM インストール済みデスクトップにスト CAD/CAM アプリケーションはデスクトップにストリーム配 リーム配信 信します。このアプリケーションはストリーム配信されるた ストリーム配信デスクトップにストリ め、権限を持つユーザーしかアクセスできません。また、 ーム配信 CAD/CAM アプリケーションをストリーム配信することによ ホステッドデスクトップにストリーム って、必要なデスクトップイメージの数が削減されます。 配信 CAD/CAM のユーザーは任意の汎用デスクトップイメージ を使用することができ、その上に CAD/CAM アプリケーシ ョンがユーザーのアカウント情報に基づいて自動的に配 信されます。 DTP インストール済みデスクトップにスト DTP アプリケーションはデスクトップにストリーム配信し、 リーム配信 設定をこのアプリケーションの最新のアップデートと同期 ストリーム配信デスクトップにストリ させます。このアプリケーションをストリーム配信すること ーム配信 によって、マーケティング部門で独自の基本デスクトップイ ホステッドデスクトップにストリーム メージを使用する必要がなくなります。 配信 マルチメディアアプ インストール済みデスクトップにスト マルチメディアアプリケーションはデスクトップにストリーム リケーション リーム配信 配信し、設定をこのアプリケーションの最新のアップデート ストリーム配信デスクトップにストリ と同期させます。このアプリケーションをストリーム配信す ーム配信 ることによって、マーケティング部門で独自の基本デスクト ホステッドデスクトップにストリーム ップイメージを使用する必要がなくなります。マルチメディ 配信 アアプリケーションは DTP アプリケーションに依存してい るため、アプリケーションのストリーム配信機能の分離環 境間通信が必要になります。 33 アプリケーション アプリケーション統合方法 理由 コラボレーション クラウドベース（ローカルエージェン このエージェントはコラボレーションアプリケーションスイー トをインストール） トのオプションのコンポーネントですが、このエージェント によってユーザー環境が簡素化されます。このエージェン トは、アプリケーションのストリーム配信に対応していない 2 つの Windows サービスをインストールします。これらの 要因を考慮して、ローカルエージェントをデスクトップにイ ンストールします。 管理 インストール済みデスクトップにスト インフラストラクチャ内の多くのコンポーネントは、この管 リーム配信 理ツールの適切なバージョンで管理する必要があります。 ストリーム配信デスクトップにストリ デスクトップにアプリケーションをストリーム配信すること ーム配信 によって、これらのツールの適切なバージョンが使用され ホステッドデスクトップにストリーム るようにします。 配信 開発ツール ストリーム配信デスクトップにイン これらの開発ツールは 3 つの Windows サービスをオペレ ストール ーティングシステムにインストールします。これらのアプリ ホステッドデスクトップにインストー ケーションは、基本オペレーティングシステムのイメージに ル インストールする必要があります。そのため、サポートチ ーム用の新しいデスクトップイメージを用意します。 34 最適化 アプリケーションの多くはデスクトップにストリーム配信します。それにより、サポートと保守が必要な固有のイメー ジの数が減少します。アプリケーションのストリーム配信は、次のことに関係しているため、環境に影響を及ぼし ます。 アプリケーションの起動にかかる時間：アプリケーションを事前にキャッシュしておくと、アプリケーションのプ ロファイルがネットワーク上のアプリケーションハブではなくローカルデスクトップから取得されるため、アプリ ケーションの起動が高速になります。 書き込みキャッシュのサイズ：ストリーム配信アプリケーションは、基本デスクトップイメージに対する変更で す。これらの変更は書き込みキャッシュ内に取り込まれます。基本デスクトップイメージにアプリケーションを 事前にキャッシュしておくと、ストリーム配信アプリケーションが書き込みキャッシュに影響を及ぼさなくなりま す。 XenDesktop の設計においてアプリケーションのデリバリーを最適化するには、ストリーム配信デスクトップおよび ホステッドデスクトップで以下のアプリケーションを事前にキャッシュします。 アプリケーション 事前キャッシュ 理由 オフィス生産性 ○ この企業のほぼすべてのユーザーが、勤務時間の最初に電子メールクライ アントを起動します。また、ほとんどのユーザーが勤務時間中にオフィスアプ リケーションを複数回起動します。これらのアプリケーションの事前キャッシュ により、アプリケーションのデリバリーが最適化されます。 CAD/CAM ○ CAD/CAM アプリケーションを利用するのは 2 つのユーザーグループのみで すが、これらのユーザーは全体の約 80%に相当します。したがって CAD/CAM アプリケーションの事前キャッシュを行うと、全体の 80%のユーザ ーにとっての必須アプリケーションのデリバリーを最適化できます。 35 デスクトップデリバリーの設計 ユーザーは、生産性を上げるために、すばやくデスクトップに接続して適切なオペレーティングシステムとアプリケ ーションを受信する必要があります。デスクトップデリバリーコンポーネントは、ユーザーとホステッドデスクトップ 間の接続を仲介します。この仲介コンポーネントによって環境の状態が維持され、リソースを過度に割り当てたり 浪費したりせずに、ユーザーからの要求を満たすのに十分な数のアイドル状態のホステッドデスクトップが確保さ れます。デスクトップデリバリーの設計では、サーバーファームの全体的な設計、デスクトップグループ、アイドル 設定、キャパシティのプランニングに焦点を当てます。 キャパシティのプランニング XenDesktop サーバーファームの設計では、リソースを過度に多く（または少なく）割り当てることなく、適切なバラ ンスでキャパシティを確保する必要があります。環境の規模にかかわらず、XenDesktop のアーキテクチャは図 7 のようになります。 図 7：XenDesktop サーバーファーム この XenDesktop サーバーファームは、地理的な場所とキャパシティに焦点を合わせて設計されました。以下に、 4 つのデータセンターに分散された 7,200 のホステッドデスクトップというこの企業の要件に基づく、設計の決定事 項を示します。 36 サイト マイアミ ホステッド XenDesktop デスクトップ サーバーファーム 3800 2 つの 4 つの仮想コントローラ 2 つの仮想サーバー 5 つのリソースプール XenDesktop サ 必須：各サーバーフ 必須： 1 . XDI： 1 ァームで 1 つ 冗長： 1 PSI： 1 HDI：4（各サーバーフ XenDesktop Controller Web Interface XenServer リソースプール ーバーファーム 冗長：各サーバーフ ァームで 1 つ ロサン 1800 ゼルス ァームで 2 つ） 1 つの 2 つの仮想サーバー 2 つの仮想サーバー 4 つのリソースプール XenDesktop サ 必須：各サーバーフ 必須： 1 XDI： 1 ァームで 1 つ 冗長： 1 PSI： 1 HDI： 2 ーバーファーム 冗長：各サーバーフ ァームで 1 つ ロンドン 800 1 つの 2 つの仮想サーバー 2 つの仮想サーバー 3 つのリソースプール XenDesktop サ 必須：各サーバーフ 必須： 1 XDI： 1 ァームで 1 つ 冗長： 1 PSI： 1 HDI： 1 ーバーファーム 冗長：各サーバーフ ァームで 1 つ 香港 800 1 つの 2 つの仮想サーバー 2 つの仮想サーバー 3 つのリソースプール XenDesktop サ 必須：各サーバーフ 必須： 1 XDI： 1 ァームで 1 つ 冗長： 1 PSI： 1 HDI： 1 ーバーファーム 冗長：各サーバーフ ァームで 1 つ 注：1 つのリソースプールで 28 の XenServer をサポートでき、各 XenServer で 40 のホステッドデスクトップをサ ポートできると見積もられています。これらの見積もり値は、この企業のハードウェア、デスクトップイメージ、ユー ザー負荷の分析に基づいて算出したものです。キャパシティに関するこれらの数値は、構築段階やテスト段階で 再検証する必要があります。 注：この設計には、XenApp に関する情報は含まれていません。XenApp のアーキテクチャにはリソースプールが 含まれていますが、サイズは規定されていません。 37 デスクトップグループ デスクトップグループを使用すると、特定のユーザーグループに他のグループと異なる設定を割り当てることがで きます。特定のユーザーグループで異なるサーバーファーム設定が必要になったり、異なるオペレーティングシス テムイメージを使用したりする場合があるため、この機能は重要です。次の表に、この企業における設計時のグ ループ定義を示します。 グループ サーバー プール ユーザー アイドル設定 ファーム データセンター：マイアミ Windows 7 デ 東部 1 VDI-1 姓の頭文字：A～M スクトップ 東部 2 VDI-2 姓の頭文字：N～Z （3600 のデス 開始時 ピーク終 終了時 了時 時刻 午前 7:00 午前 9:30 午後 6:00 デスクト 3000 500 100 開始時 ピーク終 終了時 クトップ） ップ サポート用デ 東部 1 スクトップ（200 VDI-1 マイアミのすべてのサ VDI-2 ポートユーザー 了時 のデスクトッ 時刻 午前 7:00 午前 9:30 午後 6:00 プ） デスクト 120 20 10 開始時 ピーク終 終了時 ップ データセンター：ロサンゼルス Windows 7 デ 西部 1 スクトップ VDI-1 ロサンゼルスのエンジ VDI-2 アリング、製造、IT、マ 了時 （1700 のデス ーケティングのすべて 時刻 午前 7:00 午前 9:30 午後 6:00 クトップ） のユーザー デスクト 1500 250 50 開始時 ピーク終 終了時 ップ サポート用デ 西部 1 スクトップ（100 VDI-1 ロサンゼルスのすべて VDI-2 のサポートユーザー 了時 のデスクトッ 時刻 午前 7:00 午前 9:30 午後 6:00 プ） デスクト 60 10 5 開始時 ピーク終 終了時 ップ データセンター：ロンドン Windows 7 デ ロンドン 1 VDI-1 ロンドンのエンジアリン スクトップ（650 グ、製造、IT、マーケテ のデスクトッ ィングのすべてのユー 時刻 午前 7:00 午前 9:30 午後 6:00 プ） ザー デスクト 230 65 30 了時 ップ 38 グループ サーバー プール ユーザー VDI-1 ロンドンのすべてのサ アイドル設定 ファーム サポート用デ ロンドン 1 開始時 ポートユーザー スクトップ（150 ピーク終 終了時 了時 のデスクトッ 時刻 午前 7:00 午前 9:30 午後 6:00 プ） デスクト 100 15 5 開始時 ピーク終 終了時 ップ データセンター：香港 Windows 7 デ 香港 1 VDI-1 香港のエンジアリン スクトップ グ、製造、IT、マーケテ （7000 のデス ィングのすべてのユー 時刻 午前 7:00 午前 9:30 午後 6:00 クトップ） ザー デスクト 450 70 35 開始時 ピーク終 終了時 了時 ップ サポート用デ スクトップ（100 香港 1 VDI-1 香港のすべてのサポ ートユーザー 了時 のデスクトッ 時刻 午前 7:00 午前 9:30 午後 6:00 プ） デスクト 65 10 5 ップ 各地域の Window 7 デスクトップグループは、エンジアリング、製造、IT、およびマーケティンググループのユーザ ーによって使用されます。これらの異なるユーザーグループ間で同じ基本オペレーティングシステムのイメージが 使用されるため、1 つの共有ワークステーショングループを設けています。ただし、サポートチームでは、ある必須 アプリケーションを基本オペレーティングシステムのイメージにインストールする必要があります。そのため、別の 新しいワークステーショングループが必要になりました。 ワークステーショングループを定義する際に重要な点は、定期的なアクティビティのピーク時間帯に十分な数のア イドル状態のワークステーションを確保できるようにすることです。各地域では午後 8 時から 9 時（現地時間）にか けてユーザーが殺到します。［開始時］パラメータでは、仮想デスクトップが迅速に配信されるように十分大きい値 を設定するとともに、ユーザー数がピークに達する前に余裕を持って環境の準備態勢を整えられるように、十分 早い時刻を設定する必要があります。ピーク時間帯が終了すると（同一地域内の複数のタイムゾーンを考慮する 必要があります）、電力とリソースを節約するためにアイドル状態のワークステーションの数を減らします。 39 デスクトップの設計 デスクトップの動作速度は、それがホステッドデスクトップ、ストリーム配信デスクトップ、インストール済みデスクト ップのいずれであるかにかかわらず、インストールされるアプリケーションやツールの数が増加すると低下します。 デスクトップを設計する時は、ユーザーにとってできる限り最適で高速な環境が得られるようにしながら、さまざま な要因を考慮する必要があります。リソースの割り当て、デスクトップイメージ、およびストレージ要件に焦点を合 わせて判断していきます。 仮想マシンの仕様 ホステッドデスクトップを利用するユーザーは、使用するアプリケーションがサポートされるように、特定の仕様の ハードウェアを必要とします。この仕様は、すべての地域において同じユーザーロールに基づいており、イメージ や仮想マシン定義を少なくすることに役立ちます。以下に仕様を示します。 ユーザーグループ ホステッドデスクトップ メモリ プロセッサ vDisk イメージ エンジニアリング-仮 3450 3GB の RAM 2 つの vCPU HostedWindows 7-Rev1 製造-仮想 2350 2GB の RAM 2 つの vCPU HostedWindows 7-Rev1 マーケティング-仮想 300 2GB の RAM 2 つの vCPU HostedWindows 7-Rev1 サポート 550 2GB の RAM 1 つの vCPU Support-Rev1 IT 550 2GB の RAM 2 つの vCPU HostedWindows 7-Rev1 想 表に示されているように、メモリ容量はグループ間で若干異なっていますが、vDisk イメージは、IT、サポート、製 造、エンジアリングのすべてのグループで同じものを使用します。なお、プロセッサ数に増減がある場合、vDisk 内の Windows 7 オペレーティングシステムでは、オペレーティングシステムの初回アクティベーション時からハー ドウェア構成が変更されたことになるため、再起動時に毎回アクティベーションを要求されます。 40 デスクトップイメージ ユーザーにシームレスな使用環境が提供されるように、デスクトップイメージ（vDisk ファイル）には適切なサポー トコンポーネントを含める必要があります。デスクトップイメージは、次の 4 つのコンポーネントで構成されます。 1. オペレーティングシステム 2. XenDesktop デリバリー 3. アプリケーションサポート 4. アプリケーション この企業では、これらの区分に基づいて、3 つのデスクトップイメージに次のものを含めています。 Streamed Windows 7 vDisk Support vDisk 20GB 20GB 20GB Windows 7 Enterprise 〇 〇 〇 Service Pack および Hotfix 〇 〇 〇 Hosted Windows 7 vDisk ディスク構成 サイズ オペレーティングシステム XenDesktop デリバリー Citrix Virtual Desktop Agent 〇 〇 Citrix Provisioning Services 〇 〇 〇 〇 〇 〇 〇 〇 〇 Target Device Client Citrix App Plug-in for Hosted Apps Citrix App Plug-in for Streamed Apps Citrix Tools for Virtual Machines 〇 〇 Citrix User Profile Manager 〇 〇 〇 Adobe Shockwave Player 11 〇 〇 〇 Adobe Flash Player ActiveX 9 〇 〇 〇 Symantec Antivirus 10 〇 〇 〇 Microsoft Silverlight 2 〇 〇 〇 〇 〇 〇 （GPO では有効になっていませ ん） 基本アプリケーション アプリケーション オフィス（事前キャッシュ） 開発ツール 〇 41 適切なデスクトップデリバリーには、オペレーティングシステムセクションおよび XenDesktop デリバリーセクション 内の多くの項目が必要です。ただし、Streamed Windows 7 vDisk では Virtual Desktop Agent や Citrix Tools for Virtual Machines が含まれないように変更されています。Streamed Windows 7 vDisk は、ベアメタルハード ウェア上で実行するデスクトップなので、これら 2 つのコンポーネントは不要であり、インストールされません。 この設計ではスタックを下降してサポートするアプリケーションに集中するため、ビジネスアプリケーションや、 Web サイト、プラグインで使用される基本アプリケーションに重点をおく必要があります。ユーザーは意識せずに これらのアプリケーションを常時使用します。XenApp のアプリケーションのストリーム配信機能を使ってこれらの 基本アプリケーションをストリーム配信することも可能ですが、一般的にはこれらのアプリケーションを基本デスク トップイメージに組み込むほうが簡単です。 コアアプリケーションのセクションでは、3 つのデスクトップイメージに事前キャッシュされたオフィスアプリケーショ ンが含まれています。すべてのユーザーがオフィスアプリケーションを常時使用するため、事前キャッシュを行う ことによって、アプリケーション起動の高速化、ネットワークトラフィックの軽減、書き込みキャッシュサイズの減少 などの効果が得られ、環境が効率化されます。 Support デスクトップイメージでは、Hosted Windows 7 イメージとは異なり、開発ツールをローカルにインストー ルする必要があります。設計の前段階におけるアプリケーションの分析結果から、これらの開発ツールには現時 点ではストリーム配信できないコンポーネントが含まれていることがわかっています。これらの開発ツールはこの イメージにインストールされ、その結果新しいデスクトップイメージが作成されます。 ストレージ 配信されたデスクトップでは、オペレーティングシステムとアプリケーションがそれぞれ Provisioning Services、 XenApp によってストリーム配信されるため、ストレージは必要ありませんが、書き込みキャッシュをネットワーク を介して Provisioning Services サーバーに戻す必要をなくしてデスクトップの動作を高速化するために、各デス クトップにストレージを割り当てます。以下に、設計とイメージの仕様に基づいて定めた、仮想デスクトップストレー ジの推奨構成を示します。 イメージ ハードウェア ストレージの種類 ストレージのサイズ Hosted Windows 7 vDisk 仮想 XenServer のローカルストレージ 5GB Streamed Windows 7 物理 ローカルディスクストレージ 適用外 仮想 XenServer のローカルストレージ 4GB vDisk Support vDisk アプリケーションの種類および書き込みキャッシュに対する影響に基づき、Windows 7 Standard イメージは約 5GB のストレージを必要とし、Support イメージは 4GB のストレージを使用します。Support イメージでは、ユー ザーグループで定義されているほぼすべてのアプリケーションがデスクトップイメージ内に含まれていますが、 Windows 7 Standard イメージではそのようになっていません。ホステッドデスクトップが想定量を超える領域を消 費することはまれですが、これらの推奨サイズのストレージを割り当てることによって、そのような状況で十分なバ ッファが提供されます。また、SAN バックエンドに組み込まれているデータ重複排除機能によって、ストレージの 合計消費量も大幅に削減されます。仮想デスクトップに割り当てるこれらのディスクは、NTFS 形式でフォーマット 42 する必要があります。Streamed Windows 7 vDisk では、既に NTFS 形式にフォーマットされているローカルワー クステーションディスクを使用します。 デスクトップの監視 この企業では Citrix EdgeSight などのエンドユーザーパフォーマンス監視ソリューションを環境内に組み込むこと を計画していませんが、このようなソリューションは強く推奨されます。新しい環境では新しい方式でデスクトップ デリバリーを行うため、この企業ではホステッドデスクトップやストリーム配信デスクトップが効率的に動作してい ることを検証する必要があります。エンドユーザーパフォーマンス監視ソリューションが導入されていない場合、管 理者は環境内に仮想マシンのリソース割り当てなどのインフラストラクチャ設定を変更することで簡単に解決でき るような欠陥があっても、それに気付くことができません。 43 アクセスに関する設計 サポートインフラストラクチャを構築したら、次にユーザーがその環境にアクセスできるようにする必要があります。 ユーザーは、社内から保護されたコネクションを介して接続するか、社外から保護されていないコネクションを介 して接続します。混乱を防ぐために、どちらの方法で接続する場合も、ユーザー側の手順が同じになるようにする 必要があります。アクセスの簡素化は、ローカルアクセスとリモートアクセスの設計に焦点を当てることによって達 成されます。 リソースのデリバリー ユーザーは、何らかの方法で使用可能なリソース（ホステッドデスクトップ、ホステッドアプリケーション、ストリーム 配信アプリケーション）の一覧を取得する必要があります。そのために、適切に設定した Web Interface を使って、 すべてのユーザーがリソースの種類にかかわらずに利用できる中央のデリバリーポイントを作成します。以下に、 この企業の Web Interface の設計を示します。 サイト サイトの種類 ユーザー 使用可能なリソース 理由 プライマリサイト XenApp 以下のデスクトップ XenDesktop サーバー すべてのエンドポイントを Services 上のユーザーを除 ファーム Citrix Receiver とともに構成 く、すべてのユーザ ホステッドデスクトッ します。ホステッドデスクトッ プ プとストリーム配信デスクトッ ーとすべてのデバイ ス XenApp サーバーファー プを除くすべてのエンドポイ ホステッドデスクト ム ントでは、Citrix Receiver で ップ ストリーム配信デ スクトップ ホステッドアプリケー プライマリ Web Interface サ ション イトに接続されます。ユーザ ストリーム配信アプリ ーは、このサイトでアプリケー ケーション ションまたはホステッドデスク トップを選択して、必要に応じ た最適な環境を選択できま す。 セカンダリサイト XenApp 以下のデスクトップ XenApp サーバーファ 事前にホステッドデスクトップ Services から接続するユーザ ーム およびストリーム配信デスク ー ホステッドアプリケー トップを Citrix Receiver ととも ション に構成します。この Citrix ストリーム配信アプリ Receiver インスタンスがセカ ケーション ンダリ Web Interface サイト ホステッドデスクト ップ ストリーム配信デ スクトップ に接続されます。セカンダリ サイトではプリケーションの みを配信します。それによ り、ユーザーはホステッドデ 44 サイト サイトの種類 ユーザー 使用可能なリソース 理由 スクトップ内でホステッドデス クトップを起動できなくなりま す。 このように複数のサイトを使用するように設計すると、物理エンドポイント上のユーザーがアプリケーションとホス テッドデスクトップのどちらを使用するかを選択できるようになります。一部のユーザーは、ある状況では単一の アプリケーションを必要とし、別の状況ではデスクトップ全体を必要とします。複数の異なる Web アドレスを記憶し なければならなかったり、必要なリソースに応じて特定の手順に従わなければならなかったりすると、ユーザーは 混乱します。リソースのデリバリーを簡素化するために、この企業では各データセンターで 2 つの Web Interface サイトを作成し、異なる構成の Citrix Receiver を介して接続します。各データセンターで 2 つのサイトを作成しま すが、そのために追加の Web Interface サーバーが必要になるわけではありません。1 つの Web Interface サー バーに複数のサイトを設定できます。 社内でのサイトアクセス 一部のユーザーは、サイト間や各地域のオフィス間を行き来します。これらのユーザーがどのサイトの社内ネット ワークからアクセスしても、Citrix Receiver を再設定することなくリソースを受け取れるようにする必要があります。 以下に、この環境がどのように構成されているかを示します。 図 8：社内でのサイトアクセス 社内ユーザーは、次のように DHCP、DNS、および負荷分散機能を組み合わせて、各自のデスクトップやアプリ ケーションへのアクセスを取得します。 45 マイアミデータセンター内では、接続されている支社オフィス内のすべてのデバイスが、IP アドレスやローカ ル DNS サーバーの情報を DHCP サーバーから受け取ります。 すべてのエンドデバイスには Citrix Receiver がインストールされており、「Delivery.company.com」というア ドレスからデスクトップやアプリケーションのデリバリーを受信します。 マイアミデータセンター内の DNS サーバーは、「Delivery.company.com」というアドレスをマイアミデータセン ター内の NetScaler 上の仮想 IP アドレスに変換します。 NetScaler は、「Delivery.company.com」というアドレスをローカルサイト内の使用可能な Web Interface サ ーバーのアドレスに変換します。インテリジェントな負荷分散アルゴリズムに基づいて、NetScaler は使用可 能な Web Interface サーバーにのみ要求を送信します。 他の 3 つのデータセンターでも同様の構成を使用します。ただし、「Delivery.company.com」というアドレスは、ロ ーカル DNS サーバーによって、ローカルサイトの一対の NetScaler のアドレスに変換されます。 社外からのサイトアクセス 多数のユーザーはリモートユーザーで、保護されていない公衆回線（インターネット）経由で接続します。これらの ユーザーにも社内ユーザーと同じ要求を満たし、できる限り適したデリバリー方法を選択できるようにする必要が あります。一部の社外ユーザーは、ある日にはデスクトップを必要とし、別の日にはアプリケーションを必要としま す。社内ユーザーと同様に、社外ユーザーも次のように Citrix Receiver をインストールして環境にアクセスしま す。 46 図 9：社外からのサイトアクセス 社外ユーザーは、NetScaler のグローバルサーバー負荷分散機能を使って各自のデスクトップやアプリケーショ ンへのアクセスを取得します。 ユーザーが世界各地のどの場所にいても、各自のワークステーションを起動すると Citrix Receiver が自動 的に「http://delivery.company.com」という URL を要求します。 この要求は、最終的にインターネット DNS サービスによって社内の多数のプライベート DNS サーバーにル ーティングされます。 社内のプライベート DNS サーバーは、4 つのデータセンターのいずれかに設置されている NetScaler デバイ スの 1 つに、この要求を転送します。 NetScaler デバイスによって相互に情報がやり取りされるため、各サイトでは他のサイトの動作状態が把握さ れています。ブラウザからの要求に応える NetScaler は、各サイトの動作状態と、どのサイトが最も高速に応 答するかを判断して、Access Gateway のアドレスをユーザーに送信します。 ユーザーが Access Gateway のアドレスを受け取ると、自動的にログオン画面が表示されます。認証後、ユ ーザーはアプリケーションとデスクトップの一覧を受信します。リソースを選択すると、そのユーザーのエンド ポイントと選択した公開リソースの間でセッションが確立されます。トラフィックはすべて、Access Gateway を 通過するときに SSL で暗号化されます。 47 ビジネスの継続性を維持するための設計 デスクトップデリバリーソリューションを作成する場合、フォールトトレランスおよびビジネスの継続性に関する的 確な分析と設計が必要になります。ユーザーのデスクトップやアプリケーションは社内のデータセンター拠点から ホストされるため、1 つのコンポーネントの障害が広範なユーザーに影響を及ぼす可能性があります。以降で説 明するように、この企業では前述の高可用性構成に加え、単一のデータセンター内で、また複数のデータセンタ ーにわたって、フェイルオーバーソリューションを導入します。 コンポーネントのフェイルオーバー ローカルサイトのユーザーは、各自のアプリケーションやデスクトップで最高のパフォーマンスと応答性を得るた めに、ローカルのシステムも利用できます。しかし、ローカルコンポーネントで障害が発生した場合にも、ユーザー が各自のエンドポイント設定を変更したり、異なる場所にあるリソースの使用を要求されることなく継続してデスク トップやアプリケーションを利用できるようにする必要があります。NetScaler は、既に負荷分散機能と安全なリモ ートアクセスが提供されるように設計されていますが、さらにコンポーネントレベルのバックアップサイトを指定し て、コンポーネントレベルのフェイルオーバー機能も提供されるようにします。図 10 に、このコンポーネントレベル のバックアップサイトの設計を示します。 図 10：コンポーネントレベルのバックアップサイトの設計 このシナリオでは、NetScaler によって Web Interface、XenDesktop Controller、および XenApp XML Broker サービスが、ローカル負荷分散構成で提供されます。サイト全体の Web Interface がオフライン状態になった場 合、NetScaler は定義された負荷分散設定に従ってバックアップサイトへのフォールバックを行います。 NetScaler の設定 サイト 負荷分散プール バックアッププール マイアミ Web Interface MIA-WIPRI-LB-POOL LA-WIPRI-LB-POOL MIA-XD-LB-POOL LA-XD-LB-POOL （デスクトップ/アプリケーション） XenDesktop Controller 48 NetScaler の設定 サイト 負荷分散プール バックアッププール Web Interface（アプリケーション） MIA-WISEC-LB-POOL LA-WISEC-LB-POOL XenApp XML Broker MIA-XML-LB-POOL LA-XML-LB-POOL LA-WIPRI-LB-POOL MIA-WIPRI-LB-POOL XenDesktop Controller LA-XD-LB-POOL MIA-XD-LB-POOL Web Interface（アプリケーション） LA-WISEC-LB-POOL MIA-WISEC-LB-POOL XenApp XML Broker LA-XML-LB-POOL MIA-XML-LB-POOL LON-WIPRI-LB-POOL MIA-WIPRI-LB-POOL XenDesktop Controller LON-XD-LB-POOL MIA-XD-LB-POOL Web Interface（アプリケーション） LON-WISEC-LB-POOL MIA-WISEC-LB-POOL XenApp XML Broker LON-XML-LB-POOL MIA-XML-LB-POOL HK-WIPRI-LB-POOL LA-WIPRI-LB-POOL XenDesktop Controller HK-XD-LB-POOL LA-XD-LB-POOL Web Interface（アプリケーション） HK-WISEC-LB-POOL LA-WISEC-LB-POOL XenApp XML Broker HK-XML-LB-POOL LA-XML-LB-POOL ロサンゼルス Web Interface （デスクトップ/アプリケーション） ロンドン Web Interface （デスクトップ/アプリケーション） 香港 Web Interface （デスクトップ/アプリケーション） この構成では、マイアミデータセンターの 2 つのプライマリ Web Interface サーバーのいずれかで障害が発生す ると、NetScaler の負荷分散機能がもう 1 つの Web Interface サーバーにすべての要求を転送します。マイアミ データセンターの 2 つの Web Interface サーバーで障害が発生した場合は、NetScaler の負荷分散機能は、ロ サンゼルスに設置されているバックアップ Web Interface サイトへ要求を転送します。ローカルリソースが復旧さ れると、NetScaler は自動的にプライマリサイトへのフォールバックを行います。このアーキテクチャでは、エンド ユーザーがサービスの中断を意識せずに、障害が発生したサービスへの要求が転送されている間も、仮想デス クトップのデリバリーにローカルリソースを利用できます。 サイトのフェイルオーバー コンポーネントレベルでフェイルオーバーを提供することは、ビジネスの継続性維持を目的としたソリューションに おいて最初に必要となることですが、設計時にはさらにサイトの全体的な動作状態に目を向ける必要があります。 たとえば、障害時にデータセンター全体が使用できなくなった場合は、ユーザーをバックアップデータセンターに 転送する必要があります。包括的なディザスタリカバリのシナリオでは、ユーザーは引き続き、障害が発生したサ イト以外の最も高速に応答しているサイトに接続します。ニューヨークのユーザーは、正常時にはマイアミのデー 49 タセンターに接続されますが、障害時には、最も高速に応答するロサンゼルスにこれらのユーザーの要求が転送 されます。次の図のように、この環境では NetScaler のグローバルサーバー負荷分散機能がリモートアクセス用 に配備されているため、サイトの全体的な障害への対処に必要となるインフラストラクチャが既に確保されていま す。 このアーキテクチャに基づいて、ユーザーはサイトで障害が発生していることをまったく意識せずに、引き続きリソ ースが提供されます。このサイトフェイルオーバープランでは、データセンター内で追加のハードウェアが必要に なります。たとえば、マイアミデータセンターで障害が発生した場合は、優先度が 2 番目のロサンゼルスサイトに ユーザーが殺到します。そのため、ロサンゼルスにはその対応に十分なハードウェアを確保する必要がありま す。 50 次のステップ この企業が統合デスクトップデリバリーソリューションでデスクトップ管理を効率化するプランを推進するには、す べての要件が満たされるように、適切なチェックポイントを設けた体系的なプランに従うことが重要です。そのため には、次の作業が必要です。 構築およびテスト 環境構築：この詳細な設計に基づいて、1 つのデータセンター内に初期インフラストラクチャを構築します。構 築するインフラストラクチャには、仮想化インフラストラクチャ、オペレーティングシステムのデリバリー、デスク トップのデリバリー、デスクトップイメージ、およびアクセス用のコンポーネントを含めます。 単体テスト：一次的なユーザー要件が満たされていることを検証するために、第一次テストを実施します。こ のテストでは、ユーザー環境の操作性、アプリケーションの可用性、およびエンドツーエンドの機能性を検証 します。 インフラストラクチャの統合：ユーザーにリソースを提供するには、構築した新しいデスクトップデリバリーソリ ューションを社内の現在動作しているデータセンターインフラストラクチャに統合する必要があります。この作 業では、ネットワーク機能、Active Directory、および監視機能の更新が必要になります。 チェックポイント：現在の環境構成に基づいて、設計に関する決定事項が適切であることを確認します。特に アプリケーションのデリバリーとオペレーティングシステムのデリバリーに焦点を当てます。 運用開始 試験運用：実ユーザーを対象とした実際に使用可能な小規模の環境を実装します。複数のグループから、こ の環境の各コンポーネントと要件をテストするユーザーを選出します。これらのユーザーからのフィードバック を取りまとめて評価します。 チェックポイント：試験運用環境のユーザーからのフィードバックをもとに、設計に関する決定事項が適切で あるかどうかを確認します。ここでは、特にユーザー環境の操作性とキャパシティのプランニングに焦点を当 てます。フィードバックに基づいた変更が必要な場合は、設計書に更新内容を詳しく記載した上で環境を更 新します。 運用開始：ユーザーの物理デスクトップを仮想デスクトップ（ストリーム配信デスクトップまたはホステッドデス クトップ）に順次移行して、段階的に新しい環境の運用を開始します。継続的にフィードバックを取りまとめ、 パフォーマンス測定基準をモニタしてキャパシティの見積もりを検証します。 51 付録I：参考例企業の詳細 この企業は、15 か国で事業を展開している多国籍の製造会社です。家庭用の電気器具から収納用品まで、さま ざまな商品を製造しています。同社の理念に沿って製造されたさまざまな商品は、各社からその品質が高く評価 されています。 世界各地に約 10,000 人の従業員を抱えるこの企業では、デスクトップデリバリーとサポート環境に関する物流面 および技術面の問題に悩まされていました。そこで、この企業では仮想デスクトップについて調査を行い、Citrix XenDesktop の設計を採用することが決定されました。この XenDesktop の設計に関する決定事項は、同社のイ ンフラストラクチャとユーザーコミュニティに基づいています。図 11 に、この企業のサイト配置図を示します。 図 11：サイト配置図 この企業は、4 つのデータセンター（マイアミ、ロサンゼルス、ロンドン、香港）および多数の支社オフィス（私設 WAN 経由でいずれかのデータセンターに接続）を持つ世界的な組織です。また、数千のユーザーが小規模な支 店オフィス 1、ホームオフィス、および仮想オフィス（移動中のユーザー）で仕事をしています。各ユーザーには「ホ ーム」データセンターが割り当てられており、障害が発生していない限りユーザーはこのデータセンターに接続し ます。障害時には、ユーザーは指定されたバックアップデータセンターに接続する必要があります。このアーキテ クチャに基づいて、各データセンターでは次の拠点とユーザーをサポートしています。 52 データセンター データセンター間の接続数 支社オフィス 支店オフィス 仮想オフィス ユーザー マイアミ 3（ロサンゼルス、ロンドン、 オフィス数：4 オフィス数：10 300 ユーザー 5000 ユーザー 香港） ロサンゼルス 3（マイアミ、香港、ロンドン） オフィス数：4 オフィス数：11 200 ユーザー 3000 ユーザー ロンドン 2（ロサンゼルス、マイアミ） オフィス数：3 オフィス数：5 50 ユーザー 1000 ユーザー 香港 2（ロサンゼルス、マイアミ） オフィス数：4 オフィス数：2 100 ユーザー 1000 ユーザー 1 ユーザーが多数のオフィスに分散しており、一部のオフィスにはITスタッフが配置されていない場合、仮想デスク トップを導入するとサポートや管理を容易にし、セキュリティを強化するという利点が明らかになります。しかし、仮 想デスクトップを必要とするのは同社 10,000 人のユーザーのうち一部のみで、その他のユーザーにはXenApp で仮想アプリケーションを提供することが適切です。ユーザーの内訳と各ユーザーグループの要件は次のとおり です。 ユーザーグループ 概要 拠点 ユーザー数 仮想デスクトップ エンジニア 新製品の設計と既存製品の 本社および支社 4000 ○ 支社 3000 ○ 本社および支社 500 × 本社 200 × 本社 550 ○ 本社 700 ○ 既存顧客や見込み顧客の接 本社、支社、支店、仮想 1500 × 客を担当 オフィス。常時、客先や公 550 ○ 機能強化 製造 最新設計の取り込みと工場 への実装を担当 財務 売り上げ情報や財務情報の 集計を担当 人事 オプションとメリットに関する 事柄について従業員を支援 することによって組織を統括 IT 業務のサポートに必要なイ ンフラストラクチャの構築と 保守 マーケティング さまざまな媒体を利用して広 告や販促キャンペーンを展 開 セールス 共の場所で外回り サポート 1 顧客に製品サポートを提供 本社 *IT スタッフは、支社オフィスには配置されていますが、支店オフィスには配置されていません。仮想オフィスは、 ホテル、空港、および従業員の自宅を示します。 53 多くのユーザーがデスクトップを必要としていますが、一部のユーザーは、既にハードウェア更新サイクルに従っ てハードウェアをアップグレードしており、物理デスクトップ上で最新のオペレーティングシステムとアプリケーショ ンを良好なパフォーマンスで実行できます。ハードウェアを使用していない状態にする代わりに、これらのデスクト ップをストリーム配信デスクトップとして定義して、全体的なホステッドデスクトップの数を以下のように削減しま す。 オフィス ホステッドデスクトップ ストリーム配信デスクトップ アトランタ 500 150 マイアミ 1500 450 ミネアポリス 550 0 ニューヨーク 700 400 ヒューストン 550 0 ロサンゼルス 800 300 メキシコシティ 250 0 フェニックス 250 0 サンフランシスコ 300 200 シアトル 200 100 データセンター：マイアミ データセンター：ロサンゼルス マイアミのデータセンターでは 4,800 のデスクトップを配信する必要がありますが、それらのうち 1,000 はホステッ ドデスクトップではなくストリーム配信デスクトップです。 54 付録II：参考資料 この文書で説明した XenDesktop の設計を作成するために、参考資料として以下のものを使用しました。これら の資料は手引きとして利用すべきですが、この文書で説明した設計に関する決定事項はすべて参考例企業のユ ーザー要件と経営目的に基づいています。 XenDesktop Design Handbook (CTX120760) XenDesktop 2.1 スケーラビリティ分析 (CTX120265) Provisioning Services for XenApp Reference Architecture (CTX120512) Provisioning Services for XenApp Best Practices (CTX120464) Application Delivery into a Virtual Desktop (CTX120516) 55 版 変更内容 更新者 日付 0.1 作成 Daniel Feller – Lead Architect 2009 年 5 月 7 日 1.0 完成 Daniel Feller – Lead Architect 2009 年 5 月 21 日 1.1 キャパシティに関する数値を更新 Daniel Feller – Lead Architect 2009 年 5 月 26 日 1.2 ストレージに関する記述を変更 Daniel Feller – Lead Architect 2009 年 5 月 28 日 1.3 HDI リソースプールの仕様を更新 Daniel Feller – Lead Architect 2009 年 6 月 3 日 シトリックス・システムズ・ジャパン株式会社 カスタマーサービス 0120-941-133 受付時間：月～金 9:45～17:30（土日・祝日は除く） E-mail:[email protected] URL: www.citrix.co.jp/customerservice/index.html Citrix Systems,Inc について Citrix Systems, Inc. (Nasdaq:CTXS) は、アプリケーションデリバリー インフラストラクチャーにおける世界的なリーダー企業で、最も信頼のおけるブランドです。世界中で 215,000 以上の企業や組織が、最良のパフォ ーマンス、最高のセキュリティを低コストで、あらゆるアプリケーションをあらゆるユーザーにデリバリーするために、Citrix を利用しています。Citrix の顧客には、FORTUNE 100 の 100％の企業、FORTUNE Global 500 の 99％の企業、数十万の小規模ビジネスやプロシューマーが含まれています。100 カ国以上に約 8,000 社以上のチャネル、アライアンスパートナーを有し、2008 年度の年間売上は 16 億ドルです。 ® ©Copyright 2009 Citrix Systems,Inc. All rights reserved. Citrix 、Citrix XenServer TM 、Citrix Essentials TM 、Citrix StorageLink TM は、Citrix Systems, Inc. の米国あるいはその他の国における登録商標または商標です。そ の他の社名、商品名はそれぞれの所有者の商標または登録商標です。記載された製品の仕様・機能等は改良のため予告なしに変更される場合があります。 www.citrix.co.jp 2009 年 7 月現在 XA/BRO/0709/5000 56