リファレンスアーキテクチャ:Citrix DaaS-AWS

対象者と目的

この文書は、Citrixのパートナーとお客様が、AmazonのパブリッククラウドにCitrix仮想化テクノロジーを正常に展開するために必要な最も重要な設計上の決定事項を理解するためのものです。これは「ハウツー」のリファレンスではありません。Citrix はこれらの導入ガイドを考慮しリファレンスアーキテクチャとは別に提供および保守されるようになりました。このドキュメントでは、Citrixアーキテクチャ設計フレームワークを使用して、 Citrixおよび一部のCitrixコンサルティングパートナーが使用する主要なプラクティス、推奨事項、および設計パターンを整理し、提示しています。

概要とエグゼクティブサマリー

Citrixの仮想化およびネットワーキングテクノロジーは、30年近くにわたって大小企業のニーズにうまく対応してきました。これらのテクノロジのライセンス取得、導入、統合、管理には、さまざまな方法があります。この柔軟性により、Citrixテクノロジーは、さまざまなユースケース、ビジネスタイプ、統合要件、運用モデルに対応できます。このホワイトペーパーは、AWS のパブリッククラウドインフラストラクチャへのこれらのテクノロジの導入を検討または計画している Citrix のお客様またはパートナーを対象としています。

インフラストラクチャのモダナイゼーションを検討している既存のお客様と、Citrixの仮想化およびネットワークテクノロジの導入を検討している新規のお客様の両方にとって、導入を成功に導くためには、上位レベルと低レベルの重要な決定がいくつかあります。お客様とパートナーがこれらの決定点を理解できるように、適切なコンテキストを設定するためにいくつかの特定の用語を導入および定義し、このコンテキストを使用して、導入を計画する際に考慮すべき重要な決定と影響を強調しました。

まず、「 カスタマーマネージド 」と「 クラウドサービス」という 2 つの主要なテクノロジ採用モデルを定義します。次に、 Citrix 仮想化システムのコンポーネントを複数のサブシステムに分割し 、採用モデル別に分類します。

採用モデル/サブシステム機能 カスタマー管理(ダウンロードしたバイナリからインストール) クラウドサービス(Citrix Cloud経由で提供)
セッションの仲介と管理 Citrix Virtual Apps and Desktops(CVAD Citrix DaaS (DaaS)
ユーザーインターフェイス (UI) サービス Citrix StoreFront Citrix Workspace(Citrix WorkspaceアプリまたはWebブラウザ経由で消費されるサービス)
認証 Citrix StoreFront(ほとんどのユースケースではNetScaler ADC/Gateway) Citrix Workspace(特定のユースケースではNetScaler ADC/Gateway)
HDXセッションプロキシ NetScaler ADC/Gateway Citrix Gatewayサービス

クラウドサービスの立場ほとんどの組織では、可能な場合はクラウドサービスを使用または使用する予定があることを推奨しています 。これは盲目的に提供しているわけではありません。クラウドサービスは、最終的にはお客様に圧倒的にプラスのメリットをもたらすと考えていますが、 今日、すべての組織/展開がすべてのサブシステムに対してクラウドサービスを利用できるわけではないことを認識しています。ユースケース要件 (現在利用可能なクラウドサービスまたは固有のクラウドサービスの技術的属性または欠点) では、クラウドサービスと顧客管理コンポーネントの組み合わせを採用する必要がある場合があります。このホワイトペーパーでは、これらに焦点を当てます。その他の場合、技術以外の項目 (政治、予算/契約上の考慮事項、クラウドの準備不備、規制/コンプライアンスに関する考慮事項など) は、クラウドサービスの使用を妨げる可能性があります。このような場合、Citrix パートナー/営業/エンジニアリングチームと協力して、それらを克服することをお勧めします。このホワイトペーパーの残りの部分では、お客様がどの導入モデルをいつどのサブシステムに使用するかを決定するのに役立つ主要な機能、機能、属性を明確に説明しています。

次に、3 つの一般的な展開シナリオを定義および検討し、各サブシステムに使用される採用モデルを強調します。

  • Greenfield/クラウドのみ -すべての Citrix 仮想化システムサブシステムと AWS パブリッククラウドサービスでクラウドサービスを使用します。
  • ハイブリッド(「ハイブリッドクラウド 」と混同しないでください)-最も一般的な展開モデルであるハイブリッドモデルは、セッションの仲介と管理にDaaSを使用し、残りのサブシステムには顧客管理オプションとクラウドサービスオプションの両方を使用します。
  • リフトアンドシフト -名前のとおり、このモデルは、既存の顧客管理の CVAD、StoreFront、および ADC/Gateway を使用し、これらのコンポーネントを AWS にそのまま移行するか、AWS パブリッククラウドサービスへのワークロード移行の一環として AWS にインストールします。これは、特定の特定のユースケースで有効な展開モデルですが、重大な注意事項があります。

最後に、十分に文書化された Citrix アーキテクチャ設計フレームワークを使用して 、AWS に Citrix 仮想化テクノロジをデプロイする際に考慮すべき重要な設計決定を整理し、提示しています。わかりやすくするため、「Citrix on AWS の違いは何ですか」に重点を置き、必要に応じてより詳細な情報を提供する他のリソースへのリンクを提供しています。

最終的に、ほとんどのお客様は、 セッション仲介と管理に CVAD サービスを使用して、 初日からハイブリッド展開モデルを使用することをお勧めします。これにより、AWS で Citrix 仮想化システムをコスト効率よく実行するために必要な主要な機能がお客様に提供され、コストと複雑さが大幅に軽減され、利用可能な最新の機能へのアクセスが可能になり、未来。残りのサブシステムには、クラウドサービスまたはカスタマー管理コンポーネントのいずれも使用できます (顧客固有のニーズに応じて)。ただし、カスタマー管理コンポーネントを使用している理由は明確であり、クラウドサービスに移行してから将来クラウドサービスに移行する計画を立てることをお勧めします。特定のニーズを満たしています。

Citrix on AWS の主要なプラクティスに関する詳しい洞察については、以下のクラウドガイドポストの記事を参照してください。

主要な概念と展開シナリオ

このセクションでは、 Citrixアーキテクチャ設計フレームワークの各レイヤーについて具体的な考慮事項を説明する前に、いくつかの重要な概念と展開シナリオについて説明します。

テクノロジー導入モデル

Citrix DaaSテクノロジーは、さまざまな方法で「消費」または実装できます。最も一般的な方法は、 **一般的にカスタマーマネージドサービスおよびクラウドサービスとして記述することができます。3番目のモデルも言及する価値があります- **パートナー管理。ここではわかりやすくするためにこのモデルについて説明しますが、建築設計の観点からは、最初の2つが最も関連性があります。

リファレンス・アーキテクチャにおけるテクノロジー導入モデルについて議論するのはなぜですか。採用モデルまたは「消費」モデルの選択は、システム設計、機能、コスト、および管理責任の明確化に大きな影響を与えます。このセクションでは、これらのモデルを定義し、検討し、お客様がCitrix仮想化システムを設計する際に十分な情報に基づいた選択を行うための一般的なガイダンスを提供します。

カスタマー管理

長年にわたり、テクノロジを利用したい企業は、Citrix仮想化システムの構築に必要なテクノロジースタック全体を購入、インストール、構成、保守するしかありませんでした。Citrixの仮想化ソフトウェアは、インストール可能なバイナリとしてのみ利用可能でした。 Citrixの仮想化ソフトウェアを購入したお客様は、これらのバイナリを(多くの場合、ダウンロード可能なISOディスクイメージまたは自己解凍実行ファイルの形式)をダウンロードしてから、ソフトウェアをインストールし、構成し、保守します。Citrixソフトウェア(およびネットワークハードウェア)は、お客様が所有および保守しているインフラストラクチャ、およびお客様が所有および保守しているデータセンターにインストールされていることが最も一般的です。

概念的に言えば、Citrix仮想化システムは、さまざまなCitrixコンポーネントで構成されています。このホワイトペーパーでは、その多くについて詳しく説明します。また、Citrixビットで何かを実行する前に、サードパーティコンポーネントの異なるレイヤーが必要です。最終的には、これらすべてが統合され、機能的なCitrix仮想化システムが作成されます。この文書では、わかりやすくするために、このテクノロジ導入モデルを 「顧客管理」と呼んでいます。 この用語を使用して、Citrix仮想化システムのさまざまなコンポーネントについて説明します。これには、Citrixコンポーネントの下、横、および「上」のレイヤーにある必須のサードパーティコンポーネントが含まれます。このモデルは「自己管理」とも呼ばれます。

今日、お客様は顧客管理の導入モデルに代わる魅力的な選択肢を提供していますが、さまざまな理由からこのモデルを使用してテクノロジースタックの要素を採用しているものもあります。このモデルでは、 各コンポーネントを最も細かく制御できますが、コストはかかります。つまり、セキュリティ保護、運用、パッチ適用、アップグレード、高可用性の維持など、コンポーネントの管理と保守はお客様が負担します。このモデルは、 一般に「エアギャップ」システム( インターネットにアクセスできないため、パブリックネットワーク経由で一般かつ安全にアクセスされるクラウドサービスの使用能力が制限されています)にも導入されます

以下は、Elastic Compute Cloud(EC2)や仮想プライベートクラウド(VPC)ネットワークなどの基本的な AWS IaaS サービスを使用して AWS にデプロイされた 100% 顧客管理コンポーネントを使用する Citrix 仮想化システムのアーキテクチャの例です。このアーキテクチャの詳細については、このドキュメントの後のセクションで説明します。ただし、グリーンフィールド/クラウドのみの導入モデルと非常にシンプルな展開モデルとの類似点にはすぐにわかります。

図 1:100% カスタマー管理、AWS を IaaS としてのみ使用するリフト/シフトデプロイ図 1:100% カスタマー管理、AWS を IaaS としてのみ使用したリフト/シフトデプロイ。

クラウド サービス

過去15年間にわたり、多くの異なる分野における技術の進歩により、ハイパースケールのパブリッククラウド、洗練されたクラウドサービス、マイクロサービスアーキテクチャ、DevOps/アジャイル配信フレームワーク、サブスクリプションライセンスモデル、「エバーグリーン」ソフトウェアおよびシステムが生まれました。 これらの進歩は、世界のほぼすべての業界で技術の取得、採用、提供、維持方法に革命をもたらしました。

現在、Citrix仮想化システムを構成するコンポーネントまたはレイヤーの多くは「サービスとして」利用できます。カスタマーマネージド採用モデル(顧客が企業資産としてテクノロジーを購入し、システム自体を構築/維持する)とは対照的に、顧客はさまざまなサービスを「購読」し、Service Provider がこれらのサービスの提供と管理を担当します。これらのサービスは、多くの場合、パブリックネットワーク(つまり、インターネット)を介して消費され、その中には「クラウドサービス」または「Webサービス」採用モデルと呼ばれるものもあります。このホワイトペーパーでは、このタイプの導入モデルを「クラウドマネージドサービス」、または単に 「クラウドサービス」 モデルと呼びます。

Citrix は、従来の製品の多くを「サービスとして」提供しています。プラットフォームパートナーの最新の技術進歩により、導入の簡素化と合理化、革新のスピードの促進、品質の向上、長期にわたる顧客へのさらなる価値の提供を実現しています。Citrixは、このサービス提供プラットフォームを「Citrix Cloud」と呼んでいます。このプラットフォームは、Citrixの現在および将来の最新技術を表しています。

以下は、AWS 上の Citrix 仮想化システムで 100% クラウドサービスコンポーネントを使用しているシステムのアーキテクチャの例です。 この設計の詳細については、このドキュメントの後半のセクションで説明します。

図 2: AWS マネージドサービスを使った AWS の 100% クラウドサービス図 2: AWS マネージドサービスを使った AWS の 100% クラウドサービス

パートナー管理

多くの組織では、独自のCitrix仮想化システムの構築を選択していますが、お客様や市場へのサービス提供にリソースと注意を集中できるように、IT管理の業務から抜け出そうとするお客様もいます。これらのお客様にサービスを提供するために、Citrix はインテグレーションパートナーと協力し、Citrixテクノロジを使用して「完成品」サービスを顧客に提供しています。

利用可能なさまざまな統合パートナー/タイプ、および製品の定義と差別化については、このドキュメントでは説明しません。ただし、Citrixパートナーは、お客様がCitrix仮想化システムを設計するときと同じ選択肢に直面しています。Citrixパートナーは、Citrix Cloudから1つまたは複数のサービスを使用することも、顧客固有のニーズに合わせてシステムの一部のコンポーネントを構築および管理することもできます。したがって、このドキュメントに記載されているガイダンスは、Citrix パートナーとその顧客の両方に関連しています。理由は異なります。

Citrix仮想化システムコンポーネント

この文書で後述する設計上の意思決定の意味を理解するために、Citrix仮想化システムのコンポーネントを上位レベルの「バケット」に配置し、意思決定プロセスのガイドとして使用します。すべてのCitrix仮想化システムは、展開方法とライセンスに関係なく、これらのコンポーネントが機能し、最も安全なユーザーエクスペリエンスを提供する必要があります。特に、複雑なユースケース要件、サードパーティとの統合要件、極端な制御や可用性のニーズがある場合には、お客様が自己管理型のコンポーネントとクラウドサービスを組み合わせて組み合わせることは珍しいことではありません。

次の表では、わかりやすくするために、これらの主要コンポーネントを強調しています。1 つのオプションと別のオプションを使用する場合/場所の詳細については、このドキュメントの後半で説明します。

採用モデル/サブシステム機能 カスタマー管理(ダウンロードしたバイナリからインストール) クラウドサービス(Citrix Cloud経由で提供)
セッションの仲介と管理 -Citrix仮想化システムの中心:このコアサブシステムがないと、アプリやデスクトップがなく、管理できません!このサブシステムは、マシンカタログ(Citrix Virtual Delivery Agentまたは「VDA」仮想マシンインスタンスのコレクション)の定義、プロビジョニング、および更新を行う場所です。また、デリバリーグループの作成、ユーザーへのアプリ/デスクトップの割り当て、環境とユーザーセッションの管理も行います。 CVAD:Citrix Virtual Apps and Desktops(長期サービスリリース(LTSR)または最新リリース(CR)バージョン。環境内にDelivery Controllerをインストールして構成する場合、これは実行中のものです。また、お客様自身の Microsoft SQL Server インフラストラクチャをインストールおよび管理することも意味します。顧客管理(CVAD)展開の管理機能には、Citrix DirectorおよびCitrix Studio が含まれます。LTSR/CR バイナリを使用して、これらのファイルを自分でインストール、設定、および管理します。Directorには、Microsoft SQL Serverインフラストラクチャも必要です。Citrixライセンスもこのサブシステムの一部であり、お客様はCitrixライセンスサーバーとライセンスファイルをインストール/構成/管理します。 DaaS-Citrix Cloud 経由で配信されるCitrix DaaS。Citrix Cloudにログインし、環境にCloud Connectorをインストールして登録する場合は、このCitrix Cloudサービスを使用します。管理するWindowsインスタンスにCloud Connectorをインストールして登録すると、Citrixはそれらを常にグリーンかつ利用可能に保ちます。Citrix Cloudは、Citrix Cloudコンソールを介してWebブラウザを介してほとんどの管理機能を提供し、維持します。これには、Citrix StudioとCitrix Directorのクラウドサービスバージョンが含まれます。お客様がメンテナンス、高可用性、パッチ/更新を行う追加のインフラストラクチャはありません。この管理責任は、Citrix が所有します。
UI(ユーザーインターフェイス)サービス -ネイティブCitrix Workspaceアプリ(およびクライアントレスアクセスのためのWebブラウザ)は、最終的にURLに接続します。URL の背後にあるサブシステムは、認証に関する企業要件に合わせて IT 管理者によって構成され、仮想化されたアプリケーション/デスクトップ、SaaS アプリ、およびユーザーがアクセスできる可能性ははるかに多く表示されます。 Citrix Storefront. また、CVAD LTSR または CR バイナリからインストール/構成され、この役割は、最も複雑な展開シナリオに極めて柔軟に対応します。通常、ペアでデプロイされ、その前にNetScaler ADC/Gatewayインスタンスがあり、高可用性を実現します。顧客管理/仲介環境(CVAD)とCitrix Cloud 管理/仲介環境(DaaS)の両方のアプリケーションとデスクトップを集約して表示できます。 Citrix Workspace (Citrix Workspaceアプリではなくサービス)。Citrix Cloudを通じてクラウドサービスとして提供され、このサービスでのみ利用可能な多くの次世代機能が含まれています。顧客管理/仲介環境(CVAD)とCitrix Cloud 管理/仲介環境(DaaS)の両方のアプリケーションとデスクトップを集約して表示できます。
認証 -この文脈では、Citrix仮想化されたアプリ/デスクトップ、ファイル、SaaSアプリなどにアクセスする前にユーザーが認証する方法を参照します。Citrix環境での認証は通常、UIサービス層で構成されますが、NetScaler ADC/Gatewayはすべての展開モデルで認証にも使用できます。各UIService Provider オプション(Citrix StoreFront またはCitrix Workspace)には異なる認証オプションがあり、一部の認証オプションは顧客管理対象のNetScaler ADC/Gatewayを必要とします。 Citrix StoreFrontおよびほとんどのユースケースでNetScaler ADC/Gateway )。ユーザー認証サービスは、さまざまな方法で提供できますが、最終的には Active Directory インスタンスと有効なユーザーアカウントが必要です。通常、お客様は AD インスタンスを管理します。NetScaler ADC/Gatewayインスタンスは、認証サービスを提供するためにも使用できます。また、より複雑な環境によく使用される多数の高度な機能を提供します。Citrixフェデレーション認証サービス(FAS)をインストールし、複雑なユースケースにセッションSSOを提供するために使用することもできます。 Citrix Workspaceおよび特定のユースケースではNetScaler ADC/Gateway )。Citrix Workspace(サービス)では、Citrix Cloudテナントに対してユーザー認証ソースと要件が一度構成され、このURLを使用するすべてのユーザーによって使用されます。このファイルは Active Directory 用に構成されますが、高度なユースケースでは、他の認証プロバイダーをサポートするように構成できます。たとえば、Azure AD、Okta、カスタマーマネージドの NetScaler Gateway、Google Cloud ID、その他の SAML/OpenID/RADIUS プロバイダーなどがあります。一部のシナリオでは、ユーザーエクスペリエンスを最適化するには、顧客管理の NetScaler ADC/Gateways および Citrix フェデレーション認証サービス(FAS)が必要です。
HDXセッションプロキシ -プライベート企業ネットワークの外部にあるユーザー/デバイスを、内部のCVAD/DaaS配信アプリケーションおよびデスクトップに安全かつシームレスに接続する機能。 NetScaler ADC/Gatewayアプライアンス -これらのアプライアンス(またはインスタンス)は、多くの場合、Citrix仮想化システムに多くの追加機能を提供します。ただし、クライアントがパブリックネットワーク上にあるときに、HDXセッションをVDAに安全にプロキシすることです。インストール、設定、SSL 証明書などが必要です。StoreFront(カスタマー管理UIサービス)とワークスペースクラウドサービスの両方と互換性があります。また、Citrix管理および顧客管理の両方のセッション仲介オプションとも互換性があります。 NetScaler Gateway Service -Citrix Cloudによって提供されるこのサービスは、HDXセッショントラフィックをVDAにプロキシし、Citrix管理インフラストラクチャを使用してジョブを完了させます。パブリック IP アドレス、SSL 証明書、または入力ファイアウォールルールを操作する必要がありません。Citrix Workspace サービス、およびCitrix Cloud 管理および顧客管理の両方のセッション仲介オプション(CVADおよびDaaS)と互換性があります。

主要なプラクティスと推奨事項

Citrix仮想化システムを自分で管理する場合でも、Citrixまたは認定パートナーを使用して管理する場合でも、 可能な限りクラウドサービスの使用を検討してください 。クラウドサービスがニーズを満たさないユースケース/環境では、カスタマー管理コンポーネントを使用できます。つまり、Citrix では、お客様が自己管理型のコンポーネントを導入している理由を明確にし、クラウドサービスが特定のニーズを満たしたらクラウドサービスに移行する準備をしておくことをお勧めします。Citrix Cloudを通じてCitrixが提供するクラウドサービスは、急速に進化しています。時間が経つと、最も複雑なユースケースを除くすべての機能を提供することが期待できます。Citrix Cloudサービスは、最終的に、お客様が管理および保守を担当するインフラストラクチャの量を最小限に抑えます。また、Citrix Cloudは、可用性の高い、統合済みのサービスも提供し、お客様が常に最新のセキュリティで保護された機能豊富なサービスにアクセスできるようにします。

AWS での Citrix 仮想化の一般的なデプロイモデル

AWS は、最も機能、最大の顧客コミュニティ、比類のない経験、成熟度を備えたクラウドプロバイダーとして、さまざまな業界の幅広い顧客が、システムとインフラストラクチャをクラウドに移行しています。時間の経過とともに、一般的な導入シナリオ/移行パターンが開発されてきました。このセクションでは、これらのパターン/シナリオを検討し、それらを使用して Citrix Virtual Apps and Desktopsワークロードを AWS に移行するタイミングと場所について説明し、一般的な移行シナリオで考慮すべきパターンに関する推奨事項をいくつか示します。

AWS で Citrix アプリとデスクトップを配信する最も一般的なシナリオは、次の 3 つです。

  • グリーンフィールド/クラウドのみのデプロイ 。Amazon EC2(Amazon Elastic Compute Cloud)サービスの「リソースロケーション」を持つ Citrix Cloud サービスを使用します。このシナリオは、お客様がサブスクリプションモデルに移行し、コントロールプレーンのインフラストラクチャと管理責任をCitrixにアウトソーシングする場合、またはCitrix Cloudサービスが提供する機能を体験/評価したい場合によく使用されます。
  • AWSへのハイブリッドデプロイ/ワークロード移行 、セッションの仲介と管理に Citrix Cloud サービスを使用し、コンテンツ集約/セッションプレゼンテーション/セッション起動には Workspace UI または StoreFront を使用します。また、HDX セッションプロキシには顧客管理の NetScaler ADC/Gateways も使用できます。複雑な認証シナリオ、またはその両方。
  • リフトアンドシフト。このシナリオでは、お客様は基本的に AWS に自己管理された Citrix インフラストラクチャを移動または再デプロイし、AWS でのデプロイを既存の顧客管理型のデプロイと同様に扱います。このシナリオでは、お客様は NetScaler ADC/Gateway および Citrix StoreFront を使用して、オンプレミスおよび AWS でホストされるサイトからリソースを集約します。これにより、AWS へのワークロードの移行が容易になります。ただし、お客様はオンプレミスのワークロードを維持し、AWS に別のサイトを追加するだけです。新しいサイトは、新しいワークロードや、災害復旧 (DR) とフェイルオーバーの使用例をサポートするために使用できます。このモデルは、セッション仲介、管理、UIサービス、認証、HDXセッションプロキシのための顧客管理コンポーネントの使用によって特徴付けられます。

このセクションでは、各シナリオが一般的にどのように設計されているかのアーキテクチャの概要を含め、これらのシナリオをより詳細に定義します。 主要なプラクティスはCitrix Cloudサービスを使用することであり、この文書では、Citrix Cloudの仲介型展開モデル(「グリーンフィールド」と「ハイブリッド」)に焦点を当てています。

グリーンフィールド・デプロイメント

グリーンフィールドデプロイモデルの最も一般的な例は、AWS クラウドでの Citrix 仮想化テクノロジの試用または概念実証デプロイです。本質的にゼロから始めているので、既存の「スタッフ」と統合しようとしていないので、「コードとしてのインフラストラクチャ」のパワーを体験することができます。また、さまざまなクラウドサービスと「プレイ」し、お客様や顧客のニーズへの適合性を評価する絶好の機会です。

グリーンフィールド導入は、お客様が構築できる最も迅速で簡単なCitrix仮想化システムでもあります。システムが不要になったときに単にそれを引き裂くことができ、消費したリソースの支払いを停止します。このタイプの展開に必要なのは、アクティブな AWS アカウントと、Citrix Cloud および Citrix DaaS の試用版または有料サブスクリプションだけです。これら 2 つのリソースを使用して、AWS の QuickStart CloudFormation テンプレートを使用してリファレンスデプロイを構築できます。Citrix とAWSは、 Citrix DaaS on AWSクイックスタートテンプレートで協力しています 。これは、Citrix仮想化システム全体をゼロから構築するか、既存のActive Directory yを持つ既存のVPCにCitrix Cloudの「リソースの場所」を作成するのに役立ちます。Citrix 仮想化システム全体をゼロからデプロイする場合、作成されるシステムは AWS 上に構築され、次のリファレンスアーキテクチャ図と密接にマッチします。

図 3: デプロイされたシステムアーキテクチャの詳細デフォルトパラメータ。Citrix Cloud Servicesは表示されていません図3:Citrix DaaS on AWS QuickStartテンプレートとデフォルトパラメータを使用してデプロイされたシステムアーキテクチャの詳細。Citrix Cloud サービスが表示されていません。

図 4: オプションの AWS サービスと Citrix Cloud Services を使用した Greenfield/Cloud Only デプロイの概念アーキテクチャ図 4: オプションの AWS サービスと Citrix クラウドサービスを含む Greenfield/Cloud Only デプロイの概念アーキテクチャ

このデプロイモデル (実際には 3 つのデプロイモデルすべて) は、 AWS アベイラビリティーゾーンを使用して高可用性設計を提供していることは注目に値します 。詳細については、このドキュメントの後半の「 アベイラビリティーゾーン 」を参照してください。

前述のように、これは AWS および Citrix Cloud サービスについて学ぶときに始めるのに最適な場所です。上の図に示したデザインパターンの多くは、ハイブリッド、さらにはリフトアンドシフトのデプロイタイプに使用されるため、これらのデザインパターンを学ぶことは、デプロイモデルに関係なく、Citrix on AWS アーキテクトに適しています。

要約すると、 グリーンフィールド導入モデルは 、少なくとも出発点として、すべてのクラウドサービスを使用します。

Citrix仮想化システムコンポーネント 提供者
セッションの仲介と管理 Citrix DaaS(「DaaS」、Citrix Cloud 経由)
UIサービス Citrix Workspace サービス(Citrix Cloud経由)
認証 Citrix Workspace サービス(Citrix Cloud経由)
HDXセッションプロキシ NetScaler Gateway Service(Citrix Cloud 経由)
VM コンピューティング、ネットワーキング、ストレージ Amazon Elastic Compute Cloud(Amazon EC2)、Amazon Virtual Private Cloud(Amazon VPC)、Amazon Elastic Block Store(Amazon EBS)
Active Directory とファイルシステム [Microsoft Active Directory および Amazon の Windows ファイルサーバー用 FSx 用 AWS ディレクトリサービス](https://aws.amazon.com/directoryservice/) (オプション)

先ほど説明しましたが、グリーンフィールド導入モデルは、概念実証システムおよび技術試験システムの出発点として使用されることがよくあります。 このモデルから始めて、StoreFront またはNetScaler ADC/Gateway VPXをでドロップすると、表向きは次のタイプの展開モデルであるハイブリッドを作成します。

ハイブリッド展開

ハイブリッド展開モデルでは、 Citrix 仮想化システムコンポーネントの一部を自分でインストール/構成/管理することを選択できますがセッション仲介および管理サブシステムは選択できません。ハイブリッド展開モデルでは、このサブシステムは「Citrix DaaS」と呼ばれるクラウドサービスとして提供され、Citrix Cloud からサブスクリプションとして提供されます。

ハイブリッド展開モデルは、今日見られる最も一般的な展開であり、ほとんどのお客様にお勧めするモデルです。このポジションを取る主な理由は次のとおりです。

  • シンプルさ -Citrix Cloudサービスでは、シンプルさは基本的な設計の基本です。複数のクラウドサービスを使用すると、連携して動作するように事前構成され、構成が必要な場合、ワークフローとオプションが大幅に簡素化されます。
  • インフラストラクチャとライセンスコストの削減 -お客様が管理するCitrix仮想化サービスでは、多くの場合、サポートにハードウェアとソフトウェアが追加され、それに伴うコストが発生します。 1 つの良い例は Microsoft SQL Server です。顧客管理の仲介および管理サービスにはデータベースが必要です。独自のデータベースを構築/管理する場合は、それらを提供する必要があります。別の方法として、SQL Server 用の AWS リレーショナルデータベースサービス (Amazon RDS) を使用することもできます。
  • 自動スケーリング -Citrix のマネージド仲介サービス(DaaS)には、 組み込みのVDA容量およびコスト管理機能を提供するCitrix Autoscale機能が含まれています。この機能により、お客様は使用した分だけをお支払いいただくと、インフラストラクチャにかかる費用を大幅に節約できます。AWS で Citrix 仮想化ワークロードを実行する場合、これは多くの場合、コミットされた使用割引の支払いと VM の使用量に対する支払いの違いを意味します。多くのユースケースでコストを大幅に削減でき、Citrixの自動スケール機能を使用すると、必要なものだけを消費できます。
  • 管理費の節約 -クラウドサービスでは、Citrix はサービスの可用性、パフォーマンス、安全性、および最新性を維持する責任を負っています。それでもVDAを構築および管理することはできますが、これらの責任を委任することの価値を過小評価しないでください。クラウドサービスは、ITリソースを解放し、これらの重要で面倒な(多くの場合時間がかかる)タスクではなく、ビジネスに独自の価値を提供することに集中することができます。
  • 「無料」アップグレードと継続的なイノベーション -お客様が管理するインフラストラクチャにより、お客様はコンポーネントをアップグレードしてパッチを適用できます。クラウドサービスでは、これらの作業の大半は消えます。Service Provider (Citrix や AWS など)は、常にイノベーションを起こす傾向があり、多くの場合、顧客に代わって作業を行うことなく、サービスを消費する顧客にこれらのイノベーションをもたらします。
  • より多くの機能、機能、サービスへのアクセス -最新のサービス提供プラットフォーム(Citrix Cloud や AWS EC2 など)により、テクノロジープロバイダーは、新しい機能、機能、サービスを市場に出すための強力でコスト効率の高い方法を提供します。Citrix などのベンダーは、デジタルトランスフォーメーションの途中で、顧客との出会いを約束していますが、コスト効率の高い方法で新しい機能を提供する唯一の方法は、クラウドサービスとして提供することです。
  • 柔軟性 -この展開モデルの基盤としてDaaSを使用すると、顧客はCitrix 仮想化システムの顧客管理コンポーネントまたはクラウドサービスコンポーネントを混在させることができます。これにより、システムはさまざまなユースケースに対応し、Citrix仮想化システムの複雑なエンタープライズ要件をサポートできます。これらの選択肢については、このホワイトペーパーの後半のセクションで詳しく説明します。

要約すると、 ハイブリッド展開モデルでは次のものが使用されます

Citrix仮想化システムコンポーネント 提供者
セッションの仲介と管理 Citrix DaaS(「DaaS」、Citrix Cloud 経由)
UIサービス Citrix Workspace サービス(Citrix Cloud経由) またはAmazon EC2 上のCitrix StoreFront(カスタマー管理)
認証 Citrix Workspace サービス(Citrix Cloud経由) またはEC2上のCitrix StoreFront(NetScaler ADC/Gateway オプションだが共通
HDXセッションプロキシ Amazon EC2 上の NetScaler Gateway Service(Citrix Cloud経由) またはCitrix ADC/Gateway VPX(NetScaler ADC/ゲートウェイはオプションですが、一般的です)
VM コンピューティング、ネットワーキング、ストレージ Amazon Elastic Compute Cloud(Amazon EC2)、Amazon Virtual Private Cloud(Amazon VPC)、Amazon Elastic Block Store(Amazon EBS)
Active Directory とファイルシステム [Microsoft Active Directory および Amazon の Windows ファイルサーバー用 FSx 用 AWS ディレクトリサービス](https://aws.amazon.com/directoryservice/) (オプション)

ハイブリッド展開モデルでお客様が選択できるオプションと、顧客管理コンポーネントが提供する柔軟性を考えると、すべてのお客様にフィットする簡潔なアーキテクチャはありません。しかし、顧客のニーズに合わせて混合/一致させることができるいくつかの一般的なデザインパターンがあります。ただし、基本パターンは、AWS 上の Citrix Cloud の「リソースの場所」のパターンです。これは、 Citrix DaaS on AWS QuickStart テンプレートによって構築されたパターンでもあり、次のアーキテクチャ図のようになります。

図 5: 概念アーキテクチャ、Citrix DaaS-AWS でのハイブリッド展開モデル図 5: 概念アーキテクチャ、Citrix DaaS-AWS でのハイブリッド展開モデル。

このデプロイモデルでは、 可用性の高い設計を提供するために AWS アベイラビリティーゾーンも使用されていることは注目に値します 。詳細については、このドキュメントの後半の「 アベイラビリティーゾーン 」を参照してください。

また、ハイブリッドデプロイモデル(AWS上のDaaSリソースロケーション)をハイブリッドクラウドモデルと組み合わせて、AWS Direct Connect、AWS VPN、またはその他のネットワークツールを使用して顧客が管理するデータセンター/リソースを AWS に接続できることも注目に値します。このモデルでは、お客様の既存の Active Directory が AWS に拡張されることが多く、お客様はさらに Citrix Cloud の「リソース場所」を作成して、お客様が管理するデータセンターからアプリ、デスクトップ、およびリソースを提供します。結果として得られる概念アーキテクチャは、次の図のようになります。 図6:概念アーキテクチャ、Citrix DaaS:ハイブリッド展開/ハイブリッドクラウドモデル図6 :概念アーキテクチャ、Citrix DaaS:ハイブリッド展開/ハイブリッドクラウドモデル。

リフトアンドシフト

Citrix 仮想化システムコンポーネントの定義を参照すると、リフトアンドシフトの導入シナリオについて話すとき、 重要なコンポーネントはセッション仲介および管理サブシステムと関連するインフラストラクチャです自己管理型ブローカーインフラストラクチャを使用している場合 (Cloud Connectorの代わりにDelivery Controllerをデプロイしている)、 このホワイトペーパーの目的でリフトとシフトを行います。

リフトアンドシフト-理由

このモデルに対するCitrixのガイダンスにもかかわらず、一部のお客様は、このモデルを使用してCitrix仮想化システムコンポーネント自体をデプロイ/管理することを選択しています。 CTX270373によると、AWSを含むパブリッククラウドの使用は、LTSR製品バージョンでのみサポートされています。リフトアンドシフト(自己管理)導入モデルを選択しているお客様にとって、技術面以外の理由がその背後にあることがよくあります。政治、時間の圧力、未知への恐怖、知覚されるスキルの欠損、制御の喪失、ライセンス取得はこのカテゴリに分類されます。しかし、このモデルが魅力的である理由はいくつかの技術的理由があります。次のようなものがあります。

  • システム分離 -インターネットにアクセスできないエアギャップシステムなど、一部のユースケースでは、リフトアンドシフトモデルが魅力的です。クラウドサービスは機能するためにアウトバウンドインターネットアクセスが必要であるため、厳密にエアギャップされた展開では、クラウドサービスは機能しません。これは、Citrix Cloudサービスとの通信および利用にアウトバウンドインターネット接続を必要とするため、主にCloud Connectors(マネージドセッション仲介サービスの主要コンポーネント)に適用されます。一部のお客様は、Cloud Connector用のセキュアなアウトバウンドプロキシの使用を検討できます (他のすべてのインフラストラクチャを厳密にエアーギャップ状態に保ちながら)。これは多くの場合、マネージドブローカーサービスを活用できる適切な譲歩ですが、一部の顧客やユースケースではこのオプションではない場合があります。
  • 構成の柔軟性 -1人のユーザーの「複合」は他のユーザーの「柔軟性」であり、柔軟性は、20年以上にわたり、お客様が管理するCitrix仮想化インフラストラクチャの強力なスイートとなっています。長年にわたり、この技術はいくつかの非常にニッチなユースケースとサードパーティとの統合をサポートする多くの機能を得ています。Citrix Cloudサービスは、シンプルさと事前統合に重点を置いています。そうすることで、これらのニッチな機能および統合の一部は使用できません。したがって、一部のエッジケースは、カスタマーマネージドスタックによって提供されるのが最も適しています。つまり、Citrix Cloudサービスにおけるイノベーションの急速なペースを踏まえて、これらのエッジケースはますますまれになっています。
  • 制御 -一部の組織、文化、およびビジネスモデルは、可能な限り多くの制御を要求します。お客様が管理するCitrix仮想化コンポーネントを使用すると、お客様は運命を完全に所有することができます。この制御にはコスト(インフラストラクチャ、複雑さ、人員など)がかかりますが、「あらゆるコストでの制御」は一部のお客様にとって重要なものです。

要約すると、 リフトとシフト展開モデルでは次のものが使用されます

Citrix仮想化システムコンポーネント 提供者
セッションの仲介と管理 Amazon EC2 で Citrix Virtual Apps and Desktops(LTSR または CR をダウンロードして管理)
UIサービス Amazon EC2 でのCitrix StoreFront(カスタマー管理)
認証 EC2上のCitrix StoreFront(NetScaler ADC/Gatewayはオプションだが共通
HDXセッションプロキシ Amazon EC2 上のNetScaler ADC/Gateway VPX(カスタマー管理)
VM コンピューティング、ネットワーキング、ストレージ Amazon Elastic Compute Cloud(Amazon EC2)、Amazon Virtual Private Cloud(Amazon VPC)、Amazon Elastic Block Store(Amazon EBS)
Active Directory とファイルシステム お客様が管理する EC2 の Windows Server インスタンス、 Microsoft Active Directory 用 AWS ディレクトリサービス 、および Windows ファイルサーバー用 Amazon の FSx (オプション)

最も単純な形式では、AWS への Citrix 仮想化テクノロジのリフトアンドシフトデプロイは、オンプレミスで顧客が管理する従来のデプロイに似ています。AWS リージョンにデプロイされた CVAD「サイト」を使用し、最低でも EC2 仮想マシンや VPC ネットワーキングなどの基本的な AWS IaaS サービスを使用します。前述したように、お客様は、すべてのシステム・コンポーネントに加え、SQLデータベースなどのサポートサービスを構築/構成/保守する必要があります。次の図は、このデプロイモデルを示しています。 図 1: 概念アーキテクチャ、CVAD: AWS のリフトアンドシフトデプロイモデル図 1: 概念アーキテクチャ、CVAD: AWS でのリフトアンドシフトデプロイモデル。

このデプロイモデルでは、 可用性の高い設計を提供するために AWS アベイラビリティーゾーンも使用されていることは注目に値します 。詳細については、このドキュメントの後半の「 アベイラビリティーゾーン 」を参照してください。

リフトアンドシフトデプロイモデルは、多くの場合、AWS Direct Connect、AWS VPN、または同様のネットワーキングテクノロジーを使用して、顧客が管理するデータセンターとリソースを AWS に接続するハイブリッドクラウドインフラストラクチャモデルと組み合わされます。お客様は、任意で AWS のより高度なクラウドサービス(移行に伴う簡素化の手段を提供する)の一部を採用できます。また、一部のサービス(SQL データベース、Citrix ライセンス、Citrix StoreFront、NetScaler ADC/Gateway など)を AWS で、顧客管理のデータでホストすることもできます。センター、または既存の投資、ユースケース要件などに応じて、またはその両方が異なります。次の図に、このデプロイモデルの概念的なアーキテクチャ(SQL Server 用 AWS RDS またはオンプレミス SQL Server を使用)を示します。Citrix Licensingのアクティブなインスタンスは1つだけ必要ですが、使用可能なオプションを示すために複数のインスタンスを示しました。 図8:概念アーキテクチャ、CVAD:ハイブリッドクラウドインフラストラクチャモデルを使用したリフトアンドシフト導入モデル、およびAWSマネージドクラウドサービス図8 :概念アーキテクチャCVAD: ハイブリッドクラウドインフラストラクチャモデルと AWS マネージドクラウドサービスを備えたリフトアンドシフトデプロイモデル。

リフトアンドシフト-なぜない

今では、Citrixの主要なプラクティス/推奨事項は、完全なリフトとシフトを行うことではないことを集めてきました。なぜこれがどこから来ているのか疑問に思えるかもしれません。 Citrix 仮想化システムコンポーネントの内訳を見るとセッション仲介および管理サブシステムは 、持ち上げたりシフトしたりしないことを検討したい最も重要なコンポーネントです。セッションの仲介と管理には、Citrixのクラウドサービスを使用することを強くお勧めします(デリバリーコントローラ+SQLデータベース+Directorサーバー+Citrixライセンスサーバーの展開ではなく、Cloud Connectorのみを展開します)。このポジションを取る主な理由は次のとおりです(そして、彼らはよく知られているかもしれません)。

  • シンプルさ -顧客管理によるセッション仲介サービス は、制御と構成の究極の柔軟性を提供しますが、複雑さと継続的なメンテナンス要件が犠牲になります。Citrix Cloudサービスでは、シンプルさは基本的な設計の基本です。複数のクラウドサービスを使用すると、連携して動作するように事前構成され、構成が必要な場合、ワークフローとオプションが大幅に簡素化されます。
  • インフラストラクチャとライセンスコストの削減 - お客様が管理するCitrix仮想化サービスでは、多くの場合、サポートにハードウェアとソフトウェアが追加され、それに伴うコストが発生します。 1 つの良い例は Microsoft SQL Server です。顧客管理のブローカーサービスにはデータベースが必要であり、独自のデータベースを構築/管理する場合は、それらを提供する必要があります。
  • インフラストラクチャのコスト削減について言えば、このことは、2つのセッション仲介オプション( Auto Scaling) の重要な差別化要因となります。Citrix のマネージド仲介サービス(DaaS)には、 組み込みのVDA容量およびコスト管理機能を提供するCitrix Autoscale機能が含まれています。この機能により、お客様は使用した分だけをお支払いいただくと、インフラストラクチャにかかる費用を大幅に節約できます。AWS で Citrix 仮想化ワークロードを実行する場合、これは多くの場合、コミットされた使用割引の支払いと VM の使用量に対する支払いの違いを意味します。多くのユースケースでコストを大幅に削減でき、Citrixの自動スケール機能を使用すると、必要なものだけを消費できます。重要な注意: この機能は、Citrix Cloudサービス(Citrix DaaS)のお客様のみが利用できます。お客様が管理する仲介インフラストラクチャ(Citrix Virtual Apps and Desktops LTSRまたはCRリリース)では使用できません。 - 管理の節約 -クラウドサービスでは、Citrix(およびこの場合は AWS)が、サービスの可用性、パフォーマンス、セキュリティ、および最新の状態を維持する責任を負います。それでもVDAを構築および管理することはできますが、これらの責任を委任することの価値を過小評価しないでください。クラウドサービスは、ITリソースを解放し、これらの重要で面倒で時間のかかるタスクではなく、ビジネスに独自の価値を提供することに集中することができます。
  • 「無料」アップグレードと継続的なイノベーション - お客様が管理するインフラストラクチャにより、お客様はコンポーネントをアップグレードしてパッチを適用できます。クラウドサービスでは、これらの作業の大半は消えます。Service Provider (この場合、Citrix と AWS)は常に革新的傾向にあり、これらの革新は、多くの場合、顧客に代わって作業を必要とせずに、サービスを消費する顧客にこれらの技術革新をもたらします。
  • より多くの機能、機能、サービスへのアクセス- 最新のサービス提供プラットフォーム(Citrix CloudやAmazon EC2 など)は、テクノロジープロバイダーが強力で費用対効果の高い方法で新しい機能、機能、サービスを市場に投入し、他の方法では不可能となります。Citrix などのベンダーは、デジタルトランスフォーメーションの途中で、顧客との出会いを約束していますが、コスト効率の高い方法で新しい機能を提供する唯一の方法は、クラウドサービスとして提供することです。

リフトアンドシフト-より多くのリソース

Citrix Cloud サービスが生まれる前は、お客様はすでに AWS で Citrix 仮想化テクノロジを正常にデプロイしていました。当時、Citrixは仮想アプリおよびデスクトップ製品をXenAppおよびXenDesktop と呼んでいました。この導入シナリオのリファレンスアーキテクチャと導入ガイドの作成および公開には、広範な作業が行きました。これらの古いリソースの詳細の大部分は、今日この道を歩む必要のある導入環境にも当てはまります。

このルートを下る必要があるお客様には、次の公開リソースを使用して、成功に役立つバックグラウンドの詳細情報を提供します。このドキュメントを続行する前に、これらの資料を確認することをお勧めします。これらの作業が完了してから変更された、重要な設計上の決定事項について強調しています。

設計の決定

このセクションでは、AWS で Citrix 仮想化システムを設計する際に考慮すべき重要な設計上の決定について説明します。Citrix アーキテクチャ設計フレームワークの各レイヤーについて、検討すべき重要な領域についてご検討ください。

Citrixアーキテクチャ設計フレームワークについて

CitrixのVirtual Apps and Desktopsソリューション(Citrixの仮想化テクノロジーを総称する製品ファミリ)を使用すると、仮想マシンの作成、制御、管理、アプリケーションとデスクトップの配信、および詳細なセキュリティポリシーの実装を行うことができます。Citrix Virtual Apps and Desktopsソリューションは、包括的なデジタルワークスペース製品を開発するための統合フレームワークを提供します。このサービスにより、Citrixユーザーは、デバイスのオペレーティングシステムやインターフェイスに関係なく、アプリケーションやデスクトップにアクセスできます。

Citrixアーキテクチャ設計フレームワークは、統一された標準化されたレイヤーモデルに基づいています。これは、一般的なVirtual Apps and Desktops の展開シナリオのほとんどにおける技術的なアーキテクチャを理解するための、一貫した容易なアクセス可能なフレームワークを提供します。これらのレイヤーは、次の概念図に示されています。 図9:概念アーキテクチャ、Citrix Virtual Apps and Desktops図9 :概念アーキテクチャ、Citrix Virtual Apps and Desktops。

  • ユーザーレイヤー -このレイヤーは、Citrix環境のユーザーグループと場所を定義します。

  • アクセス層 -この層は、 ユーザーがリソースにアクセスする方法を定義します。
  • 制御層 -このレイヤーは、 Citrixソリューションを制御するコンポーネントを定義します。
  • リソース層 -この層は、 Citrixワークロードのプロビジョニングと、特定のユーザーへのリソースの割り当て方法を定義します。
  • プラットフォーム層 -この層は、 CitrixワークロードをホストするためにハイパーバイザーコンポーネントとクラウドService Provider フレームワークを実行する物理要素を定義します。
  • 操作レイヤー -このレイヤーは、 コアソリューションの提供をサポートするツールを定義します。

ユーザー層に関する考慮事項

Citrixアーキテクチャ設計フレームワークでは、ユーザーレイヤーはユーザーグループ、その場所、特定の要件などを記述します。ユーザーレイヤーは、各ユーザーグループの環境の全体的な方向を適切に設定します。このレイヤーには、ビジネス優先度とユーザーグループの要件の評価基準が組み込まれ、エンドポイントとCitrix Workspaceアプリに効果的な戦略が定義されます。これらの設計上の決定事項は、各ユーザーグループの柔軟性と機能性に影響します。

Citrix仮想化システムを任意のプラットフォーム上で設計および展開する場合、慎重な評価後に採用された決定と戦略によって、Citrixアーキテクチャ設計フレームワークの他のレイヤーを順を追って作業する際に考慮すべき他の多くの意思決定の基盤が定められます。したがって、これは徹底的に理解し、正しく取得するための重要な層です。

アクセスレイヤに関する考慮事項

Citrix アーキテクチャ設計フレームワークでは、アクセスレイヤーは、ユーザーが AWS リソースにアクセスする方法を定義します。アクセスレイヤーの設計は、Citrix仮想化システムが提供する機能にとって重要です。これは、ユーザーがシステムに対して認証する方法を制御します。また、ユーザーが仮想化されたアプリケーションやデスクトップを表示および起動する方法、およびユーザーが利用できるアプリケーションやコンテンツの種類も制御します。また、アクセス層は、セッションを安全にプロキシまたは直接接続する方法とタイミングを制御します。

前に定義したCitrix 仮想化システムコンポーネントのコンテキストでは 、アクセスレイヤーには次のコンポーネントと選択肢が含まれています。

Citrix仮想化システムコンポーネント 提供者
UIサービス Citrix Workspace(Citrix Cloudによって提供) またはAmazon EC2 上のCitrix StoreFront(カスタマー管理)
認証 Citrix Workspace サービス(NetScaler ADC/Gateway オプション) または EC2 上の Citrix StoreFront(NetScaler ADC/Gatewayはオプションだが共通)
HDXセッションプロキシ NetScaler Gateway Service(Citrix Cloud によって提供) または Amazon EC2 の NetScaler ADC/Gateway VPX(カスタマー管理)

次の表に、デプロイするアクセスレイヤコンポーネントを決定する際の重要な決定ポイントを示します。ただし、選択はバイナリではありません。Citrixでは、ニーズに合わせてカスタマイズできるさまざまなアクセス方法をサポートしています。

UI サービスと認証に関する考慮事項

AWS で Citrix 仮想化システムに UI サービスを提供する方法を選択するときは、次の点を考慮してください。

属性/機能 カスタマー管理(ダウンロードしたバイナリからインストール) クラウドサービス(Citrix Cloud経由で提供)
複数の「Citrix Farms」から仮想化されたアプリとデスクトップを提示および起動する機能 はい -レガシー環境(XenAppとXenDesktop 7.x、Citrix Virtual Apps and Desktops CR/LTSR)とCitrix DaaS の両方。 はい -レガシー環境(XenAppとXenDesktop 7.x、Citrix Virtual Apps and Desktops CR/LTSR)とCitrix DaaS の両方。詳細については、 この記事を参照してください
認証要件など、ユースケースごとに異なる設定で複数の「ストア」を作成する機能。 はい -StoreFront は複数の異なるストアで構成でき、NetScaler ADC/Gateway VPXと組み合わせると、高度なルールを適用して特定のデバイスまたはユーザーグループを異なるストアに送信できます。詳しくは、「 Citrix Virtual Apps and Desktops でのSmartAccessの仕組み」を参照してください。2つのStoreFront を必要とする一般的なシナリオの1つは、ユーザーが公開デスクトップ内から公開アプリケーションを必要とする場合です。もう1つの一般的なシナリオとしては、特定のユースケースに対して内部のみのストア(NetScaler Gatewayアクセスなし)と、内部およびリモートアクセスの両方に対して別のストアを構成する必要があります。詳細については、「 ストアの構成と管理 」を参照してください。 いいえ -Workspace Serviceは、基本的に単一の URL 上の単一のストアです。すべてのユーザーが同じストアとワークスペース設定を使用します。認証要件は 1 回設定され、Workspace テナントのすべてのユーザーに適用されます。
Citrix Secure Private Accessサービスを使用して、SaaSおよびWebアプリケーションを列挙、起動、SSOする機能。Webフィルタリングと強化されたセキュリティ制御ポリシー、および高度なML拡張分析を活用します。 いいえ -Citrix Workspace を使用する必要があります。 はい -NetScaler Gateway Serviceでは、Citrix Cloudコンソールでの統合を「有効にする」だけで簡単です。SaaS アプリは Web ベースのウィザードから簡単に定義され、管理者は事前定義されたアプリケーションのかなりのリストを出発点として使用できます。
Citrix WorkspaceアプリとWebブラウザ(HTML)を使用して、Citrix Files(旧ShareFile)コンテンツにアクセス/インデックス作成/検索する機能。 いいえ -StoreFront には、ファイルベースのコンテンツをワークスペースアプリまたはStoreFront のHTML UIに統合する機能はありません。 はい :Citrix Cloudへのサブスクリプションに応じて、デフォルトで有効になります。さまざまなソース (オンプレミスのファイル共有を含む) からユーザーのファイルベースのコンテンツを、HTML と Workspace アプリの両方の Workspace UI に取り込みます。
Citrix リモートPCアクセス機能を使用して 、物理デスクトップへの接続を表示および起動する機能。 はい -仲介がCVADとDaaSのどちらによって処理されるかは関係ありません。 はい -仲介がCVADとDaaSのどちらによって処理されるかは関係ありません。
マルチサイトおよびDRの使用例では、ゾーンの優先度とフェイルオーバーを使用してセッション起動動作をきめ細かく制御できます。 はい -複数の AWS リージョンとアベイラビリティーゾーンにまたがるデプロイに Citrix ゾーンを使用することは、停止時にEast-West方向に拡張し、影響を受けるユーザーベースを制限するのに最適な方法です。また、リージョンの優先設定やプライマリゾーンへのフェイルオーバーをシームレスに行うことができます。 CVAD Zones のドキュメントを参照してください 部分 -Workspace サービスには、フル機能のゾーン設定およびフェイルオーバー機能は含まれませんが、ユーザーまたはアプリのホームゾーンを使用して同様の効果を実装できます。詳細については、 Citrix DaaS ゾーンのドキュメントを参照してください
リソースの場所/ゾーンとCitrix Cloud間の接続が失敗した場合、またはCitrix Delivery Controllerの下にあるデータベースが使用できない場合に、新規接続と既存の接続を仲介する機能。 はい -Cloud ConnectorとDelivery Controllerの両方でローカルホストキャッシュ機能を使用して、これら2つの潜在的な障害シナリオに復元力を提供します。回復力要件が広範囲な環境では、ローカルホストキャッシュを使用してStoreFront を展開することをお勧めします。詳細については、「 ローカルホストキャッシュ (CVAD)」を参照してください。 はい -Citrix Cloud通信障害が発生した場合に、Cloud Connectorはローカルホストキャッシュ機能を使用して、リソース接続を仲介します。これには、フェイルオーバーシナリオを処理するために、リソースの場所からアクセスできるパッシブStoreFront サーバーが必要です。詳細については、「 ローカルホストキャッシュ (DaaS)」を参照してください。
カスタマイズされた「バニティ URL」を構成し、エンドユーザーの消費に利用する機能。 はい -お客様は、使用およびユーザーに提示されたURLと証明書を完全に制御できます。パブリックネットワーク経由で入力するには、SSL証明書、DNSエイリアスの作成/管理、NetScaler ADC/Gatewayインスタンスが必要になりません。 Partial -すべてのワークスペースは cloud.com ドメインから配信されますが、 お客様は独自にカスタマイズしたプレフィックス (customername.cloud.com) を設定できます
NetScaler ADC/Gateway VPXまたはNetScaler Gateway Serviceを通じて、ネットワーク上のユーザーをVDAおよびオフネットワークユーザーにインテリジェントにルーティングできます。 はい -StoreFront では、管理者が定義した「ビーコン」が使用されます。このビーコンは、Citrix Workspaceアプリがユーザーのネットワーク上またはネットワーク外のどちらであるかを判断するために使用されます。 近日公開 -この機能は、ネットワークロケーションサービスのリリース後にCitrix Workspaceで利用できるようになります。詳細については、「 ネットワークロケーションサービスのプレビュー」を参照してください。
NetScaler Gateway Servicesを使用して、シンプルで事前構成済みのHDXセッションプロキシサービスを使用できます。 いいえ -Citrix仮想アプリへのネットワーク外アクセスが要件であり(展開環境の 99% の場合)、StoreFront では、HDXセッションプロキシ機能に顧客管理されたNetScaler ADC/Gatewayを使用する必要があります。 はい :この機能は、すべての新しいCitrix Workspaceテナントに対してデフォルトでプロビジョニングされ、有効になります。
Active Directory および TOTP を介した組み込みの多要素認証が含まれます。 はい -NetScaler ADCには、サードパーティ認証システムで使用するTOTP機能が組み込まれており、サードパーティ製アプリ/デバイス/サービスもサポートしています。 はい -Citrix Workspaceには、セルフサービスOTPデバイスのリカバリやエンドユーザーへの自動プッシュ通知など、この機能が含まれています。Citrix認証アプリとサードパーティ認証アプリの両方をサポートします。
SSO 機能 (仮想化、SaaS、および Web アプリケーション) 部分的 -SSO から仮想化されたアプリケーションへ。 はい :SSOから仮想化、SaaS、WebアプリケーションへのCitrix Workspaceでネイティブで利用可能です。GatewayサービスとSecure Private Accessには、Web フィルタリングとポリシー制御が含まれます。
事前定義された複数の認証方法から選択して、選択した方法をシステム上のすべてのユーザーに適用できます。 はい -より多くのオプションと柔軟性。Citrix StoreFront では、複数のストアを作成でき、認証方法はストアごとに構成されます。ストアごとに1つ以上のオプションを構成でき、管理者はActive Directory ユーザー名/パスワード、SAML認証、ドメインパススルー、スマートカード、HTTP基本、およびNetScaler Gatewayからのパススルーのオプションから選択できます。セルフサービスパスワードリセットを有効にすることもできます。詳細については 、「認証サービスを構成する 」を参照してください。NetScaler ADC/Gateway(顧客管理)をStoreFront で展開して使用すると、さまざまな認証オプションを構成し、必要に応じて特定のストアにユーザーを誘導する追加のロジックとともに、ほぼすべてのユースケースをサポートできます。 さまざまなユースケースで複雑な統合と異なる認証方法が必要な場合、Citrix StoreFront とNetScaler ADC/Gatewayを使用することをお勧めします。 はい -現在、Active Directory、Azure AD、Active Directory + TOTP トークン、Azure AD、および NetScaler Gateway が現在サポートされているオプションです。Okta と Google Cloud ID オプションは、プレビュー中または近日公開されています。詳細については、「 安全なワークスペース 」を参照してください。NetScaler Gatewayを除き、認証の選択は、Citrix Workspaceテナント/URLを通じて提供されるすべてのユーザーおよびすべてのサービスに適用されます。NetScaler Gatewayオプションを使用すると、さまざまな認証オプション(RADIUS MFA、スマートカード、フェデレーション、条件付きアクセスポリシーなど)をサポートし、さまざまなユーザーグループやユースケースに柔軟に適用できます。詳しくは、「オンプレミスのNetScaler GatewayをIDプロバイダーとしてCitrix Cloudに接続する」を参照してください。
フェデレーションIDプロバイダを使用して仮想化されたWindowsアプリ/デスクトップを起動するときに、VDA上のセッションにSSOする機能 はい -Citrix フェデレーション認証サービス (FAS)は、SAML(セキュリティアサーションマークアップ言語)などのフェデレーションIDプロバイダーを使用しているときに、VDAへのSSOを有効にします。 近日公開 -Citrix WorkspaceでCitrixフェデレーション認証サービス (FAS)を使用する。この機能は本執筆時点でプレビュー中です。詳しくは、「 Citrix FASを使用したワークスペースのSSOの有効化 」を参照してください。

HDXセッションプロキシに関する考慮事項

AWS で Citrix 仮想化システムに HDX セッションプロキシ機能を提供する方法を選択する場合は、次の点を考慮してください。

属性/機能 カスタマーマネージド(AWS での NetScaler ADC/Gateway VPX) クラウドサービス(Citrix Cloudが提供するNetScaler Gatewayサービス
シンプルな事前構成サービス。管理オーバーヘッドなしでHDXプロキシを提供 いいえ -これらのアプライアンスは、お客様が管理するコンポーネントとして、ライセンス、インストール、構成、保守が必要です。 はい - NetScaler Gateway Serviceは 、Citrixが管理する完全なHDXプロキシソリューションであり、クラウドサービスとして提供されます。
Citrix HDXのEDT(UDP)ベースのトランスポートプロトコルを使用する機能。詳細については、「 アダプティブトランスポート 」および「 HDX Enlightened Data Transport プロトコルの構成方法」を参照してください。 はい -この機能は、高レイテンシーサイトからのトラフィックを最適化し、お客様が管理する ADC/Gateway インスタンスで使用できます。 まだ -この機能はこの執筆時点でプレビュー中です。Gateway Serviceは、現在、VDAへのTCPベースの接続のみをサポートしています。
負荷分散、ヘルスチェック、SSL オフロード、その他の高度なネットワーキングおよびアプリケーション配信サービスを顧客管理インフラストラクチャに提供する機能。 はい -NetScaler ADC/Gateway VPXアプライアンスは、業界をリードする高度な機能を提供します。その多くは、アプライアンスに適切な種類のライセンスを適用するだけで有効にできます。 いいえ -Citrix CVAD および Citrix DaaS 仲介環境の場合、Gateway サービスは、お客様の AWS 環境またはオンプレミス環境で実行されている仮想アプリケーションへのシンプルで安全なアクセスを提供します。
データセンター、ゾーン、リージョン間で顧客が設定可能なグローバルサーバー負荷分散 (GSLB) のサポート。 はい -お客様が管理するNetScaler ADC/GatewayインスタンスをGSLB用にセットアップできますが、セットアップと管理はお客様の責任となります。 いいえ-… しかし、実際には必要ありません。Gatewayサービスは、 世界中の14以上のPOPと統合されたGSLBを使用して 、ユーザーが世界のどこにいても可能な限り最高のセッションパフォーマンスを得ることができます。
HDXセッションのプレゼンテーションと起動には、Citrix Workspace UIを使用する必要があります。 いいえ -ワークスペースUIとStoreFront の両方で、顧客管理のNetScaler ADC/Gateway VPXインスタンスを使用できます。 はい -Gateway Serviceは、HDXプロキシ用のCitrix Workspace UIを介してのみ構成できます。Citrix StoreFront のHDXプロキシ機能は提供されません。
セキュアなネットワークにセッションをプロキシするには、Cloud Connectorインスタンスで追加のリソースが必要です。 いいえ -Cloud Connectorは、お客様が管理するNetScaler ADC/Gateway VPXインスタンスに対してSTAチケット検証を実行しますが、すべてのHDXセッションがVPXを介してプロキシされるため、追加のリソースは必要ありません。 はい -現在、Gateway Serviceでは、Cloud ConnectorインスタンスからCitrix Cloudへの長期間有効なアウトバウンドTCP接続を使用して、HDXトラフィックをプライベートネットワークにプロキシします。これには、Cloud Connector インスタンスのサイジングと構成時に、リソースに関する追加の考慮事項が必要です。詳細については、 この記事を参照してください -Gateway ServiceとVDAが Rendezvous プロトコル/機能を使用できるようになると、ほとんどのユースケースでこの要件は問題になります。これには、Citrix VDA 1912以降が必要です。
Citrix Cloud Government テナントと共に使用する機能。 はい -オンプレミスと AWS EC2 ベースの ADC/Gateway/StoreFrontフロントの両方のデプロイがサポートされています。 はい -Citrix Workspace は、Citrix Cloud Government で利用できます。
アウトバウンドインターネット接続なしで、エアギャップされた AWS クラウド/環境をサポートする機能。 はい -ADC/Gateway(および StoreFront)の顧客管理型のデプロイは、オンプレミスと AWS EC2 ベースのインスタンスの両方でサポートされます。 いいえ -エアギャップされた AWS 環境は、Citrix Cloud または Citrix Cloud Government にアクセスできないため、Gateway ServiceとWorkspace Serviceは現時点では利用できません。

要約、推奨事項、主要なプラクティス

アクセスレイヤサブシステムについて、お客様が管理するサービスとクラウドサービスのどちらを決定するかを決定するのに役立つ属性/機能の一部を確認したので、 先ほど定義した導入モデルのコンテキストで最上位の決定を検討しましょう

アクセスレイヤー:グリーンフィールド/クラウドのみの展開

グリーンフィールドまたはクラウドのみのデプロイモデルでは、クラウドサービスは全面的に使用されるため、Citrix 仮想化システムの設計に対する AWS 固有の意味はシンプルです。 UI と HDX プロキシサービスの両方に必要なものはすべて提供され、設定され、「箱から出る」準備ができているため、AWS で何かを構築または設定する必要はありません。

Citrix展開のアクセスレイヤーは、仮想アプリとデスクトップをユーザーに配信するための重要な要件です。アクセスポイントに到達できない、または障害が発生した場合、ユーザーは自分のリソースにアクセスできません。ネットワークの設計と実装は複雑になりますが、NetScaler Gateway ServiceとCitrix Workspaceでは、冗長性、フェイルオーバー、メンテナンス、グローバルプレゼンスがすべてパッケージに含まれ、ネットワークの知識は必要ありません。NetScaler Gateway ServiceとCitrix Workspaceを使用すると、インフラストラクチャのフットプリント。アクセスレイヤーをクラウドサービスモデルに移行することで、ユーザーは世界中のどこからでもネットワークリソースに安全にアクセスできます。このアプローチでは、導入とメンテナンスの労力が最小限であるため、迅速な稼働を実現したい、ITスタッフに制限がある場合や、インフラストラクチャが重視されていない場合に最適な選択肢となります。すべてが事前に構成されているため、この展開モデルはカスタマイズ性が最も低くなりますが、シンプルで安全で、完全に機能し、グローバルにアクセス可能なシステムを展開するには、アクセスレイヤーにCitrix WorkspaceとGateway Serviceを使用するのが方法です。

アクセス層:ハイブリッド展開

ハイブリッド展開モデルでは、Citrix仮想化システムコンポーネントの一部を構築/管理します。そうでない場合は、定義上、グリーンフィールドまたはクラウドのみの展開になります。ハイブリッドモデルでは、AWS またはオンプレミスで NetScaler ADC/Gateway VPX をデプロイする可能性があり、要件によっては、AWS またはオンプレミスに Citrix StoreFront をデプロイすることもあります。オンプレミスのGatewayおよびIDソリューションに多額の投資を行ったお客様は、 NetScaler GatewayをWorkspaceのIDプロバイダーとして使用できるというメリットがあります

この導入モデルは、セキュリティ重視の導入、現在のオンプレミスインフラストラクチャ(ADCまたはStoreFront)を使用した展開、およびお客様が管理する既存のデータセンター用のDR/フェイルオーバーサイトでは共通です。このモデルの重要な考慮事項の 1 つは、ユーザー、リソース、およびアクセスポイントを、可能な限り緊密に保つことです。 アクセスレイヤーをデプロイする、オンプレミスのリソースロケーションの近くにある AWS リージョンを選択します。可能であれば、ADCとStoreFront サーバーをできるだけ近づけてください。これは物事がトリッキーになることができる場所です。ハイブリッド展開を設計するときは、 Citrix Virtual Apps and Desktopsの起動シーケンスを考慮してください 。特に、すべてのトラフィックはNetScaler ADCを経由してルーティングされることに注意してください。

AWS では、NetScaler ADC/Gateway と StoreFront を EC2 ベースのインスタンスとして使用すると、カスタマイズの可能性もはるかに高くなります。ハイブリッドデプロイでは、複数の StoreFront ストア、多要素認証、および業界をリードするさまざまなADC機能に加えて、リレーショナルデータベースサービス(RDS)や AWS ディレクトリサービスなどのネイティブ AWS サービスも使用できます。ハイブリッド展開は、より段階的なクラウド移行に効果があり、リフトやシフトの方法ではなく、途中でアーキテクチャを調整する余地を残します。

ハイブリッドアプローチでは、グリーンフィールド/クラウドのみのモデルよりも高いレベルの専門知識と導入リードタイムの向上が必要ですが、従来の顧客管理/オンプレミスの導入とクラウドのみの状態との間の堅実な移行状態として機能します。

アクセスレイヤ:展開のリフトアンドシフト

従来のリフトアンドシフトデプロイモデルでは、AWS に NetScaler ADC/Gateway VPX と Citrix StoreFront の両方をデプロイするか、またはこれらのテクノロジの既存のオンプレミスデプロイを同じ目的に再利用する可能性があります。この種類の展開は、オンプレミスのCitrix仮想化環境を使用しているお客様にとってリードタイムが最も少ない傾向にあり、運用とメンテナンスの観点からの移行も最も簡単です。オンプレミス環境の管理経験を持つスタッフは、リフトアンドシフトの導入モデルでは、Citrixインフラストラクチャはほとんど変更されないため、稼働時間が短くなります。特に、アクセスレイヤの場合、この方法は簡単で、多くのカスタマイズが可能です。このリフトアンドシフトは、クラウドへの既存のデプロイや、新規またはエアギャップの AWS リージョンの最初のステップですが、将来的にクラウドフォワードアーキテクチャを採用する妨げになる可能性があります。

AWS での NetScaler ADC/Gateway VPX

AWS での NetScaler ADC/Gateway のデプロイは、オンプレミスでデプロイすることとは異なります。ただし、最終的には自分で管理します。 幸いにも、AWS に NetScaler ADC/Gateway をデプロイすることは十分に文書化されているため、設計を固めて実装を開始する前に、次のリソースを確認することをお勧めします。

AWS上のNetScaler ADC/Gateway VPXアーキテクチャには潜在的なバリアントがありますが、次の図( NetScaler ADC for Webアプリケーションクイックスタート展開ガイドより)は、クイックスタートテンプレート(デフォルトのサブネット/CIDRブロックを使用)によってデプロイされたマルチAZ Citrix HAペア配置を示しています。

図10:概念アーキテクチャ、アベイラビリティーゾーンにまたがる高可用性を備えたAWS上のNetScaler ADC/Gateway VPX 図10:概念アーキテクチャ、アベイラビリティーゾーンにまたがるHAを備えたAWS上のCitrix ADC/Gateway VPX

Citrix Docs上のAWS上のNetScaler ADC VPXで説明したように 、2つの主要な展開オプションが利用可能です。これには、次の種類のアカウントがあります:

  • スタンドアロン:NetScaler ADC/Gatewayの個々のインスタンスは、個別のエンティティとして展開および管理できます。これは、通常、 高可用性が要求されない小規模な展開や POC 展開で使用されます。

  • 高可用性:これは、 本番環境で最も一般的に展開されるモデルです。NetScaler ADC/Gateway VPXインスタンスのペアは、AWSでネイティブのCitrix HAモードを使用してデプロイできます。古いファームウェアバージョンでは、ペアは同じ AWS アベイラビリティーゾーンにデプロイされます。NetScaler ADC 12.1ファームウェア以降 、可用性の高いVPXアプライアンスのペアをアベイラビリティーゾーン(AZ)全体に展開できます。AWS での高可用性の仕組みは 、同じ AZ 内と AZ にまたがる ADC のペアをデプロイすることの違いを説明しています。このオプションについては、このセクションの後半で詳しく説明します。

NetScaler ADC VPXは通常、シングル、デュアル、または複数のNICのデプロイタイプをサポートしますが、AWSにデプロイする場合は、各ADCに少なくとも3つのサブネットを使用し、スループットとデータの分離を最適化するために、各サブネットにネットワークインターフェイスを備えて使用することをお勧めします。Citrix Virtual Apps and Desktopsをサポートするために展開する場合、NSIPは通常「プライベートCitrixインフラストラクチャサブネット」、SNIPは「プライベートCitrix VDAサブネット」に、NetScaler Gateway VIPは「パブリックサブネット」に接続されます。次の簡略化された概念図は、この構成を示しています。単一の AZ に 1 つの VPX インスタンスが表示されます。高可用性構成の場合、このデザインパターンは重複します (2 つ目の AZ)。

図11:CVAD/DaaS展開用のNetScaler ADC VPXインスタンスインターフェイスマッピング図11 :CVAD/DaaS展開用のNetScaler ADC VPXインスタンスインターフェイスマッピング。

複数のアベイラビリティーゾーンにまたがる ADC 高可用性

前述のように、これはCitrix仮想化システムの最も一般的な展開モデルです。このモデルでは、NetScaler ADCのネイティブHA(アクティブ/パッシブ)機能、またはNetScaler ADCのネイティブグローバルサービス負荷分散(GSLB)機能とIPSet機能の組み合わせを使用して、アベイラビリティーゾーン全体に展開されたNetScaler ADC VPXのペアを使用します。 後者のオプション(2020年の初めに実現可能になった)では、AZ 間でアクティブ/アクティブ構成が可能になり、ADC が信頼できるDNSソースとして機能できるようにすることで機能します。この新しいオプション/アーキテクチャは、パブリッククラウドの導入に人気があると考えられているため、ここではその点に焦点を当てます。

クラウドロードバランサー用のドメインベースのサービスでは、動的クラウドサービスの自動検出が可能です。アクティブ-アクティブ構成の複数のAZ にまたがってNetScaler ADCを展開することにより、異なるAZ のクラウドリソースを使用して、高可用性/障害復旧を最適化できます。各 AZ には、 使い慣れたポッドインフラストラクチャにクラウドリソースを含めることができます。これにより、簡単に管理できる更新、パッチ適用、拡張のスケーラビリティが可能になります。AWS AZ 間の GSLB の設定について詳しくは、 Citrix のドキュメントを参照してください

図 12: マルチ AZ HA 配置における HA フェイルオーバー前後のトラフィックフロー図 12: マルチ AZ HA 配置における HA フェイルオーバー前後のトラフィックフロー

前の図では、各ADCが異なるGateway仮想IP(VIP)を持っていることがわかります。これは、 独立ネットワーク構成 (INC)の特徴です。 HA ペア内の VPX が異なるアベイラビリティーゾーンに存在する場合、セカンダリ ADC には INC が必要です。これはマッピングされた IP アドレス、仮想 LAN、またはネットワークルートを共有できないためです。NSIPはこの構成ではADCごとに異なりますが、SNIPと負荷分散VIPは、 IPsetと呼ばれる特別なNetScaler ADC機能、つまり異なるサブネットのクライアントが同じサーバーセットに接続するために使用できるマルチIP仮想サーバーを利用します。IPSet を使用すると、プライベート IP を各プライマリインスタンスおよびセカンダリインスタンスに関連付けることができます。パブリックIPは、ペア内のプライマリADCにマッピングできます。フェールオーバーの場合、パブリック IP マッピングは新しいプライマリに動的に変化します。AWS での GSLB デプロイの場合、サービス IP は IPv4 トラフィックと IPv6 トラフィックの両方の IPSet の一部にすることができます。

リモートノードをADCに追加してINCベースのHAペアを作成する方法の詳細については、 Citrix のドキュメントを参照してください

AWS でのCitrix StoreFront

Citrix StoreFront をAWSにデプロイすることは、オンプレミスにデプロイすることと大差ありません。最後に、StoreFront のすべてのコンポーネントも自分で管理します。 StoreFront on AWSを含むすべての展開に適用される一般的な考慮事項については、「StoreFront展開を計画する 」を参照してください。主な違いは、通常、複数のAWSアベイラビリティーゾーンにまたがるStoreFrontサーバーグループに複数のStoreFrontインスタンスをデプロイすることです。この設計で有効になっている機能は、 AZ 間のレイテンシーに依存することに注意してくださいStoreFront展開/スケーラビリティプランでは、StoreFrontサーバーグループの展開は、サーバーグループ内のサーバー間のリンクの遅延が40ミリ秒未満(サブスクリプションが無効な場合)または3ミリ秒(サブスクリプションが有効な場合)未満の場合にのみサポートされます。 StoreFront をホストする予定のすべてのAZ のインスタンス間のレイテンシーを測定し、それに応じてサブスクリプションを有効または無効にしてください。

これは、 このドキュメントの前半の「UIサービスと認証に関する考慮事項」の表ですでに説明しましたが、もう一度説明する価値があります。広範な耐障害性要件があるCitrix DaaS環境では、StoreFrontの実装を最大限に活用することを強くお勧めします。ローカルホストキャッシュ機能から (CVAD と DaaS の両方のセッション仲介インフラストラクチャタイプで利用可能)。CVAD の場合、データベース停止時の復元性が提供されます。 DaaSの場合、このアーキテクチャは、Cloud ConnectorがCitrix Cloud Cloudに到達できない場合の復元力を提供します。いずれの場合も、切断されたユーザーは、停止のシナリオでも、新しいセッションと既存のセッションに接続できます。ローカルホストキャッシュのアクティブ化の詳細、制限、および影響については、ローカルホストキャッシュ (DaaS)およびローカルホストキャッシュ (CVAD)を参照してください。

レジリエンスのトピックについては、StoreFront の実装を複数のAZ(AWS リージョンに複数の AZ が含まれる場合)にまたがることをお勧めします。ただし、ADCの設計を考慮してください。 NetScaler ADCは、負荷分散と追加のサービスの復元性を提供するために、StoreFrontインスタンスの前で使用されることがよくあります。

Citrix Zonesを利用することで、単一サイトのVPC内の2つ以上のAZにサテライトゾーンを分散させることで、StoreFrontの冗長性を構築できます。ゾーンの使用は、リソースをできるだけユーザーの近くに配置し、可用性を高めるための優れた方法です。Satellite ゾーンには、StoreFront サーバー、Delivery Controller、アプリ/デスクトップリソースが含まれており、プライマリゾーンには、ライセンスサーバーやSQLを含む完全なインフラストラクチャセットアップが残ります。 これにより、StoreFront のWeb UIのスケーラビリティが可能になり、ゾーンの作成/破棄を調整できます。ゾーンを小さくしておくと、East-Westのスケーラビリティが最適になり、システム停止時の影響を軽減できます。

StoreFront on AWS は、注目のアプリグループ、スプラッシュページ、カラーリング、ロゴなど、完全にカスタマイズ可能で、アプリケーションやデスクトップは、特定のニーズに合わせて最適な方法で配置できます。StoreFront on AWS では、知識豊富な管理とエンジニアリングを維持する必要がありますが、特にNetScaler ADCと統合すると、強力なウェブ UI を提供できます。

リソース層に関する考慮事項

リソースレイヤーのデザインは、パーソナライゼーション、アプリケーション、イメージデザインに重点を置いています。リソース層は、ユーザーがデスクトップやアプリケーションを操作する場所です。AWS に Citrix 仮想化システムをデプロイする場合、(ここでは説明しない「通常の」ものをすべて除いて)留意すべき重要な事項は次のとおりです。

  • CIFSストレージとデータ・レプリケーション :ユーザーのパーソナライゼーション設定(ユーザーのWindowsプロファイルとリダイレクトされたフォルダ) の管理に使用するツールに関係なく、Windowsファイル共有を保存する必要があります。複数のリージョンにVDAがあり(ユーザーが複数のアプリケーション/デスクトップにアクセスできる)、データレプリケーションも処理する必要があります。多くのアプリケーションでもWindowsファイル共有が使用されるため、CIFSストレージとデータ・レプリケーションも重要です。
  • イメージデザイン -Citrix App Layering Citrix Provisioning Services(PVS)は現在 Amazon EC2 をサポートしていません。AWS でリソースの場所をホストしているお客様は、VDA フリートの作成、管理、更新にマシン作成サービスを使用します。

CIFSストレージとデータ・レプリケーション

AWS のほとんどの Citrix 仮想化システムでは、ユーザー設定、ユーザーデータ、およびアプリケーションデータを永続化するために、Windows 互換ファイル共有への少なくとも基本的なアクセスが必要です。これらの共有を使用できない場合、ユーザーエクスペリエンスとアプリケーション機能が損なわれるため、Windows 互換ファイル共有を提供するために選択したソリューションはすべて、可用性が高く、データを定期的にバックアップすることが重要です。

マルチサイト導入では、可用性、RPO、RTO(目標復旧時点)のニーズを満たすために、信頼性とパフォーマンスの高いデータ・レプリケーションも必要になる場合があります。これは、ユーザーが 2 つ以上のリージョンのデスクトップ/アプリに接続でき、アプリケーション/デスクトップが実行されるリージョンでアプリケーションデータ/ユーザー設定を使用できるようにする必要がある環境に特に当てはまります。次のセクションでは、AWS で CIFS ストレージおよびデータレプリケーションサービスを提供するために考慮すべきいくつかのソリューションについて説明します。

Windows ファイル共有を提供する Windows 以外のソリューションは存在しますが、これらのソリューションのほとんどは、Windows デスクトップ内の検索機能や Windows で実行されている Microsoft Outlook などのアプリケーションに必要なインデックス作成機能を提供できません。そのため、ほとんどのお客様は、少なくともユーザープロファイルと永続的なアプリケーションデータを格納するために、Windowsベースのファイルサーバソリューションに目を向けています。幸いにも、AWS で Citrix 仮想化システムを実行する場合、カスタマーマネージドオプションとクラウドサービスオプションの両方を使用できます。

カスタマー管理:Amazon EC2 上の Windows ファイルサーバー

AWS で Windows 互換のファイルサービスを提供するために多くのお客様が検討する最初のソリューションは、EC2 上に独自の Windows ファイルサーバーを構築し、AWS の各リソースロケーションにサービスを提供することです。Windowsファイル・サーバは、さまざまな種類のアプリケーションやワークロードで必要とされているため、多くのITショップが自社で構築および管理することに重きをおく場合があります。これは、お客様が行う方法を知っているためです。最も基本的なレベルでは、お客様は 1 つ以上の Windows EC2 インスタンスをスピンアップし、追加の Amazon Elastic Block Store(EBS)ボリュームをアタッチし、インスタンスを Active Directory に参加して、Windows ファイルサービスの設定とセットアップに忙しくなります。

このオプションは、ご想像のとおり、最も優れた制御性と柔軟性をお客様に提供します。これは、特定の種類の顧客や特定の垂直企業にとって非常に魅力的ですが、Windows OSからすべてをサイズ変更、拡張、構築、管理、パッチ適用、保護、保守する責任というコストもかかります。このルートを選択しているお客様は、これらのファイル・サーバの高可用性も確保する必要があります。 これは、多くの場合、複数のアベイラビリティーゾーン内のファイルサーバーを使用し、Windows DFS-N/DFS-R を使用して実現しますが、注意しないと (Microsoft ごとに) サポートされていない構成になるのは簡単です。

*注: このオプションを検討しているお客様は、移動プロファイル共有とフォルダーリダイレクト共有に DFS-R と DFS-N を使用することに関する Microsoft のサポートステートメントを確認する必要があります 。* Citrix 仮想化システムは AWS で実行されるため、もう 1 つの点を考慮する必要があります。新しいデプロイまたは移行イベントは、独自のクラウドサービスを構築する代わりに、Windows ファイルサービスの使用を評価する絶好の機会となる可能性があります。幸いにも、Amazonには考慮する価値のあるクラウドサービスのオプションがいくつかあります。私たちは今、これらのいくつかに触れます。

クラウドサービス:Amazon FSx for Windows ファイルサーバー

AmazonのWindowsファイルサーバー向けFSxは 、お客様がAWSで利用できるクラウドサービスです。FSx for Windows ファイルサーバーは、完全に管理されたネイティブの Windows ファイルシステム、および SSD ベースのストレージをサブミリ秒単位で一貫したパフォーマンスを提供します。FSx は Windows Server 上に構築されているため、AWS 上の Citrix 仮想化システムのストレージと保護を提供する完全ネイティブの Windows 互換ファイルシステムを提供します。FSx for Windows ファイルサーバーも Citrix Ready 検証済みです。つまり、この AWS サポートソリューションは Citrix Virtual Apps and Desktopsとの互換性が Citrix によって検証されています。Citrixによって正式にサポートされていませんが、サービスは基本的にネイティブのMicrosoft Windowsファイルサーバーであり、顧客ではなくAWSによって管理されています。詳細については、「 Citrix Ready の Windows ファイルサーバー用 Amazon FSX」を参照してください。

ITチームにとって、これはストレージの導入と管理に関する日常的なタスクや価値の低いタスクの多くを排除する優れたオプションです。最も重要なことは、FSx を使用することで、セキュリティ、データ保護/バックアップ、コンプライアンス、ソフトウェアの更新/パッチ適用タスク、ストレージ・インフラストラクチャの監視の負荷を軽減し、必要なサービス・レベルを確実に満たすことができるということです。ITチームは、Windowsオペレーティング・システムのファイル・サーバ、ストレージ、ネットワークなどを管理するのではなく、FSx ファイル・サービス全体を単一の運用プラットフォームとして扱うことができます。また、FSx では、Active Directory (AD) の統合、Windows DFS 名前空間、DFS レプリケーションなど、既に使用されている一般的な管理ツールをすべてサポートしています。

作成した FSx 管理ファイルシステムは、基本的に、特定のアベイラビリティーゾーンの可用性と耐久性に優れたファイルサーバーになります。Citrix仮想化システムをサービスするためには、お客様は、これらの「ファイルシステム」の高可用性を確保する必要があります。これは、FSx 管理ファイルシステムを複数のアベイラビリティゾーンにプロビジョニングし、Windows DFS-N/DFS-R を使用して高可用性の Windows ファイル共有を作成することで実現できます。ただし、注意しないと、サポートされていない構成 (Microsoft あたり) になるのは簡単です。

*注: FSxはWindowsファイルサーバーであるため、このオプションを検討しているお客様は、 移動プロファイル共有とフォルダーリダイレクト共有にDFS-RおよびDFS-Nを使用することに関するMicrosoftのサポートステートメントを確認する必要があります 。*

その他のクラウドサービスオプション

Amazon が管理するファーストパーティの Windows ファイルサービスのほかに、AWS は拡張性と機能豊富なオプションをサポートしており、その一部は従来のオンプレミスストレージテクノロジーと統合されています。これらの他のオプションはこの文書では適用範囲外ですが、選択できるオプションは多数あります。オプションを検討し始めるのに適した場所は、 AWS Marketplaceです。これらのタイプのソリューションは、信頼性が高く耐障害性のあるデータ複製が必要な、より複雑なマルチリージョンのユースケースに特に適しています。

CIFSストレージとデータ・レプリケーション:概要と結論

お客様は独自の高可用性 DFS ファイル共有を管理し、AWS サービス(FSx)としてのメリットを活用して管理作業を節約できます。また、サードパーティのストレージアプライアンスソリューションを使用してオンプレミス環境で拡張することもできます。Citrix では、それぞれの長所と短所を分析して、お客様に最適なソリューションを決定することをお勧めします。

イメージデザインと管理

AWS 上の Citrix 仮想化システムでは、アプリケーションとデスクトップは「VDA」(Citrix 仮想化システムによって配信されるアプリケーションを含む Windows または Linux インスタンスにインストールされる Citrix のVirtual Delivery Agentソフトウェアにちなむ)と呼ばれる EC2 インスタンス経由で配信されます。同一のVDAのグループは、セッション仲介および管理サブシステム(DaaSとCVADの両方)によって定義および維持される管理構造である「マシンカタログ」でプロビジョニングおよび維持されます。多くのシステムには多数のVDAがあり、ホットフィックス、サービスパック、ソフトウェアの更新が適用されると、VDA内のソフトウェアスタックが頻繁に変更されるため、これらのインスタンスの作成、サイジング、および管理が重要です。このセクションでは、上位レベルの考慮事項をいくつか説明します。

VDAのプロビジョニングとイメージ管理

AWS EC2 では、Citrix 仮想化システムは、VDA のデプロイとイメージ管理に Citrix のマシン作成サービス(MCS)プロビジョニングテクノロジを使用します。MCS は EC2 上の IAM サービスアカウントを使用して、マスタリングプロセス(テンプレート仮想マシンのシステムディスクのスナップショットを一般化された AMI に変える)、クローンプロセス(テンプレート仮想マシンのスナップショットから作成された AMI に基づく VDA インスタンスのフリートを作成および管理)、自動スケーリングデリバリーをオーケストレーションします。グループ、展開されたイメージの更新など。AWS 上の MCS については、このドキュメントの「 コントロールレイヤーに関する考慮事項」 セクションで詳しく説明します。

注: オンプレミス環境で MCS を既に使用しているお客様は、AWS でマシンをプロビジョニングするときに利用できるオプションにいくつかの違いがあることに気づくことがあります。EC2上のMCS管理VDAインスタンスには、システムディスク(マスタリングプロセス中に作成されたテンプレートイメージAMIの読み取り/書き込みコピー)と1 GBのパーソナリティディスクの 2 つのディスクがアタッチされています。構成されているマシンカタログの種類とホスト接続オプションに応じて、シャットダウン時にシステムディスク(およびVMインスタンス)が削除され、「電源オン」(プールカタログまたは共有カタログの場合)に再作成されるか、永続的なカタログタイプの場合)保持されます。詳細については、 CTX234562を参照してください

配信および持続性モデル

適切なデリバリモデルを選択することは重要であり、単なるコストにとどまらない大きな影響があります。Citrix仮想化テクノロジは、3つの主要なデリバリーモデルをサポートしています。これらのデリバリーモデルを混在させて組み合わせて使用することで、さまざまなユースケースをサポートします。次の 3 つのデリバリモデルがあります。

  • ホスト共有: ホストされた共有モデルでは、通常、RDSH ロールがインストールされた Windows Server OS を使用しますが、Linux インスタンスは互換性のあるアプリに対して同じ機能を提供します。このモデルでは、1つのVDAインスタンスで複数の同時ユーザーをサポートでき、各ユーザーが完全なデスクトップを実行したり、1つ以上の公開アプリケーションに接続したりできます。デスクトップエクスペリエンスおよび関連コンポーネントをインストールして Windows Server OS/RDSH を使用すると、デスクトップとアプリは Windows デスクトップ OS で実行されているように見えます。特定のインスタンス上のすべてのユーザーが OS インスタンスを共有するため、管理者は通常、ホストされた共有インスタンス上にアプリケーションの組み合わせを事前にインストールして構成します。ユーザーには OS に対するローカル管理者権限がありません。 ホストされた共有インスタンスは、共有インフラストラクチャでも実行でき、オンデマンドとリザーブドインスタンスの料金モデルの両方を使用して使用することができます。 管理者は、通常、ホストされた共有モデルをサポートするためにインスタンスのフリートを展開します。また、Citrixブローカーサブシステムの顧客管理およびクラウドサービスの種類の両方が、高度な負荷分散機能を提供し、すべてのユーザーが適切なパフォーマンスを体験できるようにします。 ホストされた共有インスタンスは、AWS で GPU ベースのインスタンスタイプを使用して、GPU の恩恵を受けるグラフィカルな負荷の高いワークロードのパフォーマンスを向上させることもできますが、GPU ベンダーは追加のライセンスを必要とする場合があります。Windows Server OS と RDS CAL ライセンスは、Microsoft の SPLA ライセンスモデルで「レンタル」できますが、お客様は Linux を OS として使用することで、これらの追加コストを回避できます。このモデルは、手を下げ、AWS で実行するのに最も費用対効果の高いモデルです。
  • サーバーVDI: 「サーバーVDI」(仮想デスクトップインフラストラクチャ)モデルでは、Windows Server OSも使用しており、デスクトップエクスペリエンスおよび関連コンポーネントをインストールすると、ユーザーにとってWindowsデスクトップOSのように見た目と操作性が得られます。RDSH ロールはこのモデルではインストールされないため、1 つのインスタンスで一度に 1 人のユーザーがサポートされます。また、ユーザーは独自のアプリケーションをインストールできるように、サーバー OS への昇格された権限が付与されることがあります。ホストされた共有インスタンスと同様に、サーバー VDI インスタンスは共有インフラストラクチャでも実行でき、オンデマンドとリザーブドインスタンスの価格モデルの両方を使用して使用でき、GPU ベースのインスタンスタイプを使用でき、Microsoft OS と RDS CAL は Microsoft の SPLA ライセンスモデルで「レンタル」できます。現在利用可能なツールを考慮すると、Windows アプリケーションの 99% 以上を Windows Server OS にインストールして実行できます。また、ソフトウェアベンダーが Windows Server 上でアプリケーションを明示的にサポートしていない場合もありますが、ほとんどの Windows アプリケーションは Windows デスクトップOSの場合と同様に Windows Server でも実行されます。また、サーバー VDI インスタンスは、AWS で GPU ベースのインスタンスタイプを使用して、GPU の恩恵を受けるグラフィカルな負荷の高いワークロードのパフォーマンスを向上させることも注目に値します。ただし、GPU ベンダーは別のライセンスを必要とする場合があります。これは、AWS で実行する 2 番目に費用対効果の高い配信モデルです。
  • クライアント VDI: クライアントVDI配信モデルでは、通常、Windows 10やWindows 7などのWindowsデスクトップOSを使用しますが、サポートされているLinux OSバージョンも使用できます。クライアント VDI は 1:1 モデルです。つまり、一意のユーザーにはそれぞれ独自の OS インスタンスが必要です。Citrix仮想化テクノロジを初めて使用しているお客様は、コスト効率の高いモデルが利用可能であっても、クライアントVDIを求めるこれらのタイプのプロジェクトに参加することがよくあります。また、これらの言語は、テクノロジスタックがホスト共有またはサーバの VDI 導入モデルをサポートしていない他の仮想化ベンダーの影響を受けている可能性があります。クライアントVDIモデルは、表面上で「シンプルに」見ながら、より深く入り込むほど複雑になりますが、複雑さのほとんどは、LinuxをOSとして使用することで回避できます。この複雑さのほとんどは、Windows Server とは異なり、Microsoft の SPLA ライセンスプログラムでは使用できない Windows デスクトップ OS のライセンス要件によって発生します。そのため、お客様はこれらの製品のライセンスを持っていく必要があります。 また、Windows デスクトップベースのクライアント VDI インスタンスは、共有インフラストラクチャでは実行できません。つまり、クライアント VDI インスタンスは AWS ハードウェア専有インスタンスまたは AWS 専有ホストで実行する必要があります。これにより、必要なインフラストラクチャの管理にかかるコストと複雑性が大幅に向上し、柔軟性とコスト管理オプションが削減され、コストが急速に増大します。ご期待のとおり、クライアント VDI インスタンスは、AWS で GPU ベースのインスタンスタイプを使用して、GPU の恩恵を受けるグラフィカルな負荷の高いワークロードのパフォーマンスを向上させることもできますが、GPU ベンダーはより多くのライセンスを必要とする場合があります。クライアント VDI は、AWS で実行する最も高価な配信モデルです。 両方の VDI モデルについて、もう 1 つの重要な考慮事項は永続モデルです。VDI インスタンスは、永続性のないユーザーにランダムに割り当てる(プール)することも、永続的でパーソナライズされたマシン(専用)を割り当てることもできます。プールされたインスタンスは、特定のプール内のすべてのインスタンスが同一であるため、時間の経過とともに管理が容易になります。 CitrixのMCSは、プールされたインスタンスに接続されたシステムディスクを数クリックで更新できます。また、アイドル状態のインスタンスプールは多くのユーザーにサービスを提供できるため、容量/コスト管理がより効果的です。プールされたインスタンスは、通常、プールされたインスタンスに対するエンドユーザーによる変更は再起動後も持続しないため、プールされたインスタンスは専用インスタンスよりも少し柔軟性が低くなります。ただし、CVAD 1912でリリースされたCitrix App Layeringのユーザーレイヤーやパーソナライゼーションレイヤーなどのテクノロジを使用して、ユーザーエクスペリエンスへの影響を最小限に抑えることができます。ハードウェア専有インスタンスは、コストの観点からも管理が厳しくなります。多くの場合、ユーザーがログオンするタイミングを予測するのは難しいため、ユーザーはインスタンスが起動するまで待機するか、管理者が各ユーザーがログオンすることが予想される時間帯にインスタンスを実行し続ける必要があります。

先ほど説明しましたが、ここではわかりやすく説明しましょう。Linux上で1つ以上のアプリケーションが実行されている限り、Citrix仮想化システムではさまざまな種類のLinuxを使用できます。Citrixの仮想化テクノロジは、ホストされた共有およびVDIデリバリーモデル、永続モデルとプールモデル、GPUベースのインスタンスタイプの両方をサポートします。ユーザーと管理者の操作性はWindowsベースのインスタンスと異なりますが、LinuxベースのVDAは、Microsoftライセンスを必要としないため、実行コストが大幅に低くなります。

最後に、GPUアクセラレーションの検討を再検討しましょう。3 つの配信モデル(Linux と Windows の両方)はすべて、AWS で NVIDIA アクセラレート GPU インスタンスを使用できます。G シリーズインスタンスは、グラフィックアクセラレーションの使用例に使用できますが、一般用途ではまだ商業的に実行できません。現在、Citrix は AWS Elastic GPU をサポートしていませんが、Elastic GPU は OpenGL でのみ機能するため、エンタープライズの一般的なグラフィックスワークロードへの影響は最小限に抑えられます。

では、どのデリバリーモデルを使用していますか?異なるユーザーグループやユースケースのニーズを満たすために、同じシステム内でデリバリーモデルを混在させて照合できることは注目に値します。インフラストラクチャの観点から、最も費用対効果の高いデリバリモデルは、ホスト共有です。 サーバOSとマルチユーザー同時実行性の組み合わせは非常に効率的です。また、ユーザーの種類(タスクワーカー、ナレッジワーカー、パワーユーザーなど)に応じて、仮想マシンあたりのユーザー数を適切なサイズに設定して、優れたエクスペリエンスを実現できます。ホスト共有では満足できない追加の機能を必要とするユーザーやアプリの場合は、VDI を使用するのが方法です。サーバ VDI を最初に評価する必要があります。Windows ワークロードの場合は Windows 10 VDI よりも大幅にコスト効率が高く、Server VDIは、Windows 10に似た見た目と手触りのデスクトップを提供できます。また、サーバーVDIには、専用インスタンス/ホストを使用するためのMicrosoft EULA要件はありません。クライアントVDI(Windows 10または場合によってはWindows 7の展開)はそうします。AWS 上の Windows ベースのワークロードでは、クライアント VDI を最後の手段とみなし、ホストされた共有モデルとサーバー VDI 配信モデルが不可能な場合にのみデプロイする必要があります。

意思決定プロセスを支援するために、次のDecision Treeでは、 ホストされた共有デスクトップ (サーバーOSマルチユーザーデスクトップ) とVDIデスクトップを比較しています。 ツリーでは、クライアント VDI モデルとサーバーの VDI モデルを明示的に区別しません。ユースケースから、VDI がワークロードに適したデリバリモデルであることが示唆された場合、AWS で実行できる限りサーバー VDI はコスト効率が高く、管理が容易であるため、可能な限り考慮する必要があります。

AWS インスタンス請求モデル

使用する配信モデル(ホスト共有、サーバー VDI、クライアント VDI)を決定したら、次のステップは、時間単位のオンデマンド課金モデルまたは予約課金モデルを計画することです。理想的には、オンデマンド課金モデルでは、できるだけ多くのVDAを時間単位で支払い、 Citrix Autoscale 機能を使用してコストを管理します。Citrix Autoscale(DaaSクラウドサービス仲介サブシステム専用の機能)を使用することにより、ピーク時を見越して仮想マシンの電源を必要に応じてオンにします。ただし、ピーク時間外では VM はシャットダウンされるため、ホスト共有モデルと負荷を統合し、すべてのモデルについて、ユーザーが作業を保存し、理想的にはセッションから正常にログオフできるようにすることが重要です。 リザーブドインスタンスの容量は、Cloud Connectorなどのインフラストラクチャコンポーネント(24時間365日維持される)と、常に維持される所定の数のVDA(ピーク時の 10% など)に使用できます。リザーブドインスタンスは、オンデマンド料金と比較して大幅な割引を提供するだけでなく、特定のアベイラビリティーゾーンで使用された場合にキャパシティー予約も提供します。

VDAインスタンスのサイジングとコスト管理

AWS で複数の VDA を実行する場合、さまざまなワークロード(VDA)に適したインスタンスタイプを選択することは、パフォーマンス、管理性、コストに関する大きな考慮事項を考慮した重要な決定です。インスタンスの選択が小さすぎると、パフォーマンスが低下する可能性があります。インスタンスのサイズが大きすぎると、使用していないリソースに対して支払いが発生します。適切なインスタンスタイプを選択することはバランシング行為となり、多くの場合、特定のワークロードごとに微調整が必要になります。

VDA で選択する AWS EC2 インスタンスタイプは、特定のワークロードと配信タイプに大きく依存します。ただし、一般的なガイドラインとして、「M」シリーズのインスタンスはホスト共有に最も適しているのに対し、「T」シリーズインスタンスは VDI に適しています。「M」シリーズは、ホスト上の複数のセッションで予測可能なリソース消費のために設計された CPU と RAM のバランスがとれています。「T」シリーズは、VDIのほとんど予測できない特性(たとえば、ユーザーがアイドリングしていて、次にユーザーがマクロ計算を実行している場合など)のために「バースト可能」です。インスタンスタイプの選択と料金の詳細については、 Citrix on AWS のコスト見積もりプレゼンテーション (ソースセクション)を参照してください。

インスタンスの選択(特にホスト型共有配信モデルに適用)の詳細については、 「クラウドワールドにおけるCitrix スケーラビリティ」2018年版を参照してください。 この記事では、パフォーマンス、管理性、コスト、リザーブド価格モデルとオンデマンド価格モデル、LoginVSI スケーラビリティテストに基づくインスタンス選択に関する主要なプラクティスについて説明します。 これらの概念と考慮事項は、インスタンスの選択肢と価格が、最初の公開後に変更されている可能性が高いにもかかわらず、今日でも有効です。

*注: 一部の新しいAWSインスタンスタイプは、Studioのマシンカタログ作成ウィザード(CVADまたはDaaS)にデフォルトで表示されません。

UIには、Delivery Controller(CVAD)またはCloud Connector(DaaS)にある静的XMLファイルのインスタンスタイプが入力されます。このXMLは、新しいインスタンスタイプを含めるように変更できますが、アップグレード中(Citrixが開始したCloud Connectorの更新またはお客様が開始するDelivery Controller アップグレード)時に、このファイルはデフォルト値で上書きされます。利用可能なAWSインスタンスタイプのリストを更新する方法の詳細については、 CTX139707を参照してください 。* 今回のテスト(ある時点での基準)では、M5.2Xlarge インスタンスタイプ(8 vCPU、32 GB RAM)が(業界標準のサンプルワークロードによる)ユーザーあたりのコストという点で、勝者であることが判明しました。お客様の数値は、ワークロードの特性と利用可能な AWS 料金を考慮して異なる場合がありますが、プロセスとツールを使用すると、毎月 IaaS 原価計算をより正確に概算できます。インスタンスタイプをどのように決定するかに関係なく、時間の経過とともに使用状況を監視し、必要に応じて調整して、リソースの可用性、消費量、およびコストのバランスを保つことが重要です。お客様は、 Citrix Analytics for Performanceなどのサービスの使用を検討する必要があります 。そのようなサービスが提供する情報は、パフォーマンスを向上させ、コストを削減する上で重要な役割を果たします。

アプリケーション設計

追加の考慮事項には、アプリケーション設計が含まれます。AWS などのクラウドプラットフォームへのワークロード移行を計画しているお客様は、アプリケーションのパフォーマンスに影響を与えないようにする必要があります。20年以上にわたって適用されている経験則として、データはワークロードにできるだけ近い場所に配置する必要があります。つまり、より複雑なアプリケーションアーキテクチャでは、このルールを遵守する必要があります。 たとえば、フロントエンドとバックエンド (データベース) を持つアプリが含まれます。 アプリケーションのパフォーマンスに影響を与えるレイテンシーを追加しないようにするには、フロントエンドとバックエンドの両方を移行する必要があります。別の方法として、オンプレミス(複雑なアプリケーション用)とクラウドでホストされるワークロード(単純なアプリケーション用)を混在させたハイブリッドアプローチがあります。互換性については、アプリケーションベンダーと常に相談することが重要です。リンクされた Tech Zone Decision Matrix では、 ホストされた共有アプリケーション (シングルユースおよびマルチユース) とホステッド共有デスクトップなど、さまざまなホステッド共有配信方法を比較しています。ワークロードセグメンテーションの意思決定プロセスこの記事の概要は、ワークロード設計プロセスのガイドとして使用できます。

アプリケーション設計の最終的な単語として、Enterprise Layer Manager アプライアンスは AWS 上で実行されておらず、現在 AWS で使用するためにレイヤードイメージをすぐに消費可能なディスク形式にエクスポートすることはサポートされていません。AWS での App Layering サポートが移行またはデプロイに不可欠な場合は、プロジェクトに関する情報を添えて aws@citrix.com にメールしてください。今後のリリースの早期導入者候補としてリストに追加され、お客様の声が聞こえます。Citrix App Layering について詳しくは、 製品ドキュメントおよびAppLayeringのリファレンスアーキテクチャを参照してください

制御レイヤに関する考慮事項

Citrixアーキテクチャ設計フレームワークでは、制御層はCitrixソリューションを制御するコンポーネントを定義します。これには、Active Directory(フォレスト/ドメイン、OU、ユーザーグループの構造、グループポリシーなど)、Microsoft SQLデータベースの使用、Citrixライセンス、セッションの仲介と管理、負荷管理、VDAプロビジョニング/イメージ管理などのコンポーネントが含まれます。このドキュメントの前のセクションと同様に、ここでは AWS 上の Citrix 仮想化システムにとって最も重要な考慮事項に焦点を当て、他のユーザーに関する既存のドキュメント/ガイダンスへのリンクを提供します。

制御層コンポーネントに対して行っている最もインパクトのある決定の 1 つは、セッションの仲介と管理の選択です。この決定は極めて重要であり、コスト、複雑さ、可用性、継続的な保守作業に大きな影響を与えます。まず、このドキュメントで以前に紹介したデプロイモデルを確認してから、AWS 固有の考慮事項について詳しく説明します。

制御層:グリーンフィールド/クラウドのみの導入

緑のフィールドまたはクラウドのみの導入モデルでは、ボード全体でクラウドサービスが使用されます。n) Citrix 仮想化システムの設計に対する AWS 固有の影響は最小限ですが、いずれにせよ、それらについてご説明します。Citrix Cloudは、インフラストラクチャと管理コンポーネントのほとんどをサービスとして提供するため、SQLデータベース、Citrixライセンスサーバー、Citrix Directorサーバーなどについて心配する必要はありません。

制御層:ハイブリッド展開

ハイブリッド展開モデルでは、Citrix仮想化システムコンポーネントの一部を構築/管理します。そうでない場合は、定義上、グリーンフィールドまたはクラウドのみの展開になります。 ここで興味深いのは、コントロールレイヤのコンテキストでは、それらがほぼ同一であるということです。

制御層:展開のリフトとシフト

従来のリフトアンドシフトデプロイモデルでは、すべてのキーコントロールレイヤーコンポーネント(Active Directory およびすべての Citrix セッション仲介/管理コンポーネントを含む)を AWS にデプロイします。あなたが「リフトアンドシフト」の道を下りなければならないなら、それは祝福と呪いの両方です。これらの考察のほとんどは、すでに入手可能な様々な出版された作品で徹底的に文書化されていることは祝福です。これは、これらのコンポーネントの構築、管理、保護、保守を行うために、前もって時間とともに多くの作業を行う必要があるということは、呪いです。

「リフトアンドシフト」の場合は、続行する前に、次の内容を確認して参照する必要があります。リフトアンドシフトのデプロイモデルを使用して AWS で Citrix を正常にデプロイするために考慮する必要がある設計上の決定事項をまとめています。

Active Directory 考慮事項

AWS での Citrix 仮想化システムのすべてのデプロイモデルには、Microsoft Active Directory が必要です。魅力的なユーザーエクスペリエンスを実現するには、VDA をデプロイしたすべての AWS リージョンで、機能的な Active Directory サービスが提供されている必要があります。Active Directory の実装の構造と複雑さを慎重に検討する必要がありますが、幸いなことに、Citrixの仮想化は、さまざまなAD設計やサービスモデルと柔軟に統合できます。

AWS に Active Directory をデプロイする場合、お客様は Windows Server インスタンスを使用して独自の Active Directory ドメインコントローラを構築/維持するか、 Microsoft Active Directory 用の AWS ディレクトリサービスを使用するか、またはこの 2 つの組み合わせを使用できます。Active Directory 信頼を使用して、お客様のニーズに応じて、2 つ以上の AD フォレスト/ドメインを接続することもできます。

機能的な Active Directory サービスの構築と維持に必要な管理オーバーヘッドを最小限に抑えたいお客様には、 Microsoft Active Directory 用 AWS ディレクトリサービス (AWS マネージド Microsoft AD とも呼ばれる) を検討する価値があります。このサービスは、Windows Server VM インスタンスを構築および保守するオーバーヘッドなしで、完全に機能する Active Directory フォレスト/ドメインを提供します。AWS マネージド Microsoft AD は、可用性の高い AWS 管理インフラストラクチャ上に構築されています。各ディレクトリは複数のアベイラビリティーゾーンにまたがってデプロイされ、障害が発生したドメインコントローラーを監視が自動的に検出して置き換えられます。さらに、データレプリケーションと毎日の自動スナップショットも自動的に構成されます。ソフトウェアをインストールする必要はありません。AWS はすべてのパッチ適用とソフトウェアの更新を処理します。 AWS マネージド Microsoft AD を使用すると、Microsoft のネイティブ管理ツールを使用したり、Microsoft グループポリシーを使用して Windows マシンとユーザーを管理したり、EC2 インスタンスと AWS RDS for SQL Server インスタンスに参加したり、既存の AD インスタンスと Active Directory の信頼をセットアップして、さまざまな複雑なエンタープライズをサポートしたりできます。シナリオ。

AWS マネージド Microsoft AD サービスを Citrix 仮想化テクノロジとともに使用することを選択したお客様は、これらのテクノロジがこの AWS サービスで動作することを期待できますが、その前に考慮すべき重要な考慮事項がいくつかあります。まず、ドメイン管理者、エンタープライズ管理者、またはその他の「スーパーユーザー」タイプの AD インスタンスへのアクセス権はありません。ただし、ユーザー、コンピューター、グループ、OU、およびグループポリシーを作成できる、ディレクトリのルートにある独自のコンテナを完全に制御できます。

あなたができない他のいくつかのこと:

  • AD オブジェクトは、既定のコンテナ (/Computers など) のいずれかに作成します。読み取り専用です。これにより、CitrixのMCSプロビジョニングテクノロジを使用するときに一部の顧客が犯す一般的な間違いがあります。書き込み可能なコンテナ/OUにMCS管理VDAのマシンアカウントを作成する必要があります。このような場所を選択しないと、MCSはマシンアカウントを作成できません。
  • 証明書サービスなど、一部の AD 統合機能をインストールして構成します。そのため、Citrix のフェデレーション認証サービス(「FAS」)テクノロジー(AD 統合証明書サービスを必要とする)を使用するお客様に影響します。これらのお客様は、EC2 Windows Server インスタンスを使用して AWS で独自の Active Directory を構築および管理する必要があります。
  • デフォルトでは、ローカルサーバアドミニストレータに相当します。「ボックス外の」Active Directory インストールでは、ドメイン管理者グループは既定でローカルサーバー管理者グループに追加されます。AWS マネージド Microsoft AD サービスを使用している場合は、独自のサーバー管理者のグループを作成し、独自のユーザーを追加し、グループポリシーを作成して適用して、メンバーサーバー/ワークステーションの組み込みサーバー管理者グループにグループを追加する必要があります。

信頼関係、サイト/サービスの構成、レプリケーション、およびその他のAD関連のトピックについては、このホワイトペーパーでは説明しませんが、Citrixでは、3つの展開モデルすべてに適用可能なこれらのトピックに関する広範なドキュメントを提供しています。

*注: Microsoft Active Directory 向け AWS ディレクトリサービスは 「Citrix Ready 検証済み」オファリングです。Citrixによって正式にサポートされていませんが、サービスは基本的にネイティブのMicrosoft Active Directory です。顧客の代わりにAWSによって管理されています。このAWSサービスには、大規模なサービスとして提供するためにいくつかの制限が課されており、Citrix 環境で現在知られている/最も影響の大きい制限がここにリストされています。* グリーンフィールドおよびハイブリッド展開(セッションの仲介と管理にCitrix CloudとCVADサービスを使用する環境)のActive Directory tory要件の詳細については、 Citrix Cloud Connectorの技術的な詳細を参照してください。 この記事では、 サポートされているActive Directory の機能レベルについて説明するほかActive Directory yのCloud Connectorの導入シナリオについても説明します

リフトアンドシフト導入(Citrix Virtual Apps and Desktops LTSRまたはCRバージョンを介した顧客管理のセッション仲介および管理を使用する環境)のActive Directory要件について詳しくは、「CVADシステム要件」、「Active Directory 機能レベル」を参照してください。

セッションの仲介と管理に関する考慮事項

すでにすでに集まったように、セッション仲介および管理サービスの提供方法の選択は重要であり、Citrix仮想化システムの全体的なコスト、管理性、メンテナンス、および利用可能な機能に大きな影響を与えます。すでに説明したように、この重要なコンポーネントにはCitrix Cloudサービス(DaaS)の使用を推奨していますが、特定の要件とシナリオでは、顧客管理のセッション仲介および管理サブシステム(CVAD LTSRまたはCRリリース経由)の展開が必要または推奨される場合があります。次の表に、考慮すべきこれらの要件とシナリオの一部を示します。

属性/機能 顧客管理型のCVAD(Citrix Virtual Apps and Desktops、LTSR、またはCRバージョン) クラウドサービスDaaS(Citrix Cloudが提供するCitrix DaaS)
Citrix Cloudへのアウトバウンドインターネット接続が必要です。 いいえ - Delivery Controllerは、アウトバウンドインターネット接続を必要としません。ただし、MCS プロビジョニングが機能するためには、AWS インフラストラクチャと通信できる必要があります。 はい -Cloud Connectorはインターネット経由でCitrix Cloudと通信しますが、これらの接続はプロキシできます。詳細については 、「Citrix Cloud Connectorのプロキシサーバーをセットアップする方法 」を参照してください。厳密にエアギャップ展開の場合、これはしばしばショーストッパーになります。
お客様に、高可用性の Microsoft SQL データベースサービスを提供する必要があります。 はい -CVAD(LTSRとCRの両方のリリース・タイプで)では、お客様がMicrosoft SQLデータベース・サービスを提供し、可用性の高いMicrosoft SQLデータベース・サービスを提供する必要があります。これらは、EC2 インスタンスで SQL Server を構築するか、AWS RDS for SQL Server サービスを使用して提供できます。 いいえ -DaaSでは、お客様がSQLサーバーに触れる必要はありません。可用性の高いデータベースサービスは、Citrix Cloud 配信プラットフォームによって提供され、お客様には透過的です。
セキュリティとサポート性を維持し、新しい機能にアクセスするために、お客様はCitrixソフトウェアにパッチとアップグレードを長期的に適用する必要があります。 はい -お客様は、CVADベースのセッション仲介および管理システムのすべてのコンポーネントについて、Citrixソフトウェアおよび基盤となるオペレーティングシステムのインストール、構成、パッチ適用、保護、およびアップグレードを行う責任があります。また、Citrix Delivery Controller、Studio インストール、Director、Citrixライセンスなど、各コンポーネントの高可用性を維持する責任もあります。 いいえ -Cloud Connectors(顧客のVPCに存在する唯一のセッション仲介および管理コンポーネント)は、Citrixによって自動的に更新および保守されます。お客様は、EC2 Cloud Connector インスタンスで Windows Server オペレーティングシステムにパッチを適用し 、保守する責任があります。また、Cloud Connectorを手動で更新することなく、新しい機能をすぐに利用できます。
Citrix Autoscale e機能など、Citrix Cloudが提供する高度なサービスを使用する機能 場合によっては 、顧客管理の CVAD 展開ですべての高度なサービスが使用できるわけではなく、その場合は、追加のコンポーネントのインストールと構成が必要になる場合があります。自動スケール機能は、CVAD 環境では使用できません。 はい -DaaSは、他のCitrix Cloud サービスと「すぐに使える」ように設計されており、これらのサービスは通常、お客様がオンにするだけで事前に構成されています。 Autoscale 機能は、VDAの量と電力状態をきめ細かく制御する機能を提供し、パブリッククラウドでのVDA展開に影響を与えます。必要な容量だけをお支払いになるシナリオでは、インフラストラクチャのコストを大幅に削減できます。
アップグレードやメンテナンス作業のタイミングなど、すべてのサブシステムコンポーネントを完全に制御できます。 はい :すべてのコンポーネントのインストール、構成、保守はお客様によって行われるため、お客様は、各コンポーネントのバージョン管理、構成、可用性を完全に制御できます(ただし、インフラストラクチャや複雑さ、管理オーバーヘッドの大幅なコストは増大します)。 いいえ 。DaaS を使用すると、お客様はある程度の制御を放棄しますが、シンプルさ、インフラストラクチャコストの削減、および管理オーバーヘッドの大幅な削減を実現します。
同時ユーザーと指定ユーザーに基づいてライセンスを取得できます。 はい -CVAD は CCU によってライセンスを取得できます。 はい -CCUライセンスは利用可能です。詳細については 、このブログを参照してください

Cloud Connector、Delivery Controller、リソースの場所

グリーンフィールドモデルとハイブリッドモデルの両方で、セッションの仲介と管理にクラウドサービス(DaaS)を使用するため、Cloud Connectorを展開して、 VDAをホストする予定の各リージョンにリソースの場所を作成します 。リージョンにリソースの場所を作成するときは、 n+1 Cloud Connector インスタンスをデプロイし、Cloud Connectorをリージョン内のアベイラビリティーゾーンに分散することで、高可用性構成を構築します。通常、Cloud Connectorは、セキュリティポリシーアプリケーションを簡素化するために、VDAとは別のプライベートサブネットに配置されます。また、Citrix Cloudへの接続を容易にするために、Cloud Connectorインスタンスには送信インターネットアクセスが必要です。VDAとは別のサブネットに配置すると、管理者は2つの異なるリソースタイプに異なるルーティングポリシーを適用できます。

図13:VDAとCloud Connector用に別々のサブネットを持つCitrix DaaSリソースの場所の設計パターン 図13:VDAとCloud Connector用に別々のサブネットを持つCitrix DaaSリソースの場所の設計パターン。

デリバリーコントローラ(CVAD)について話す場合も同様の一般的な概念が適用されますが、顧客管理のブローカーサブシステムでは、ゾーンとリソースの場所という用語を使用します。また、EC2 上の Cloud Connector インスタンスは、システムを起動する必要があるときはいつでも実行されるため、予約料金の候補として最適です。Cloud Connectorインスタンスのサイジングの詳細については、 この記事を参照してください

Citrix DaaS サイトの設計に関する考慮事項

リソースの場所とゾーン

Citrix ゾーン (アベイラビリティーゾーンと混同しないでください)を使用すると、リモートリージョンのユーザーは、接続が WAN の大きなセグメントを通過するように強制することなく、リソースに接続できます。Citrix DaaS 環境では、各リソースの場所はゾーンと見なされます。リソースの場所を作成してCloud Connectorをインストールすると、ゾーンが自動的に作成されます。お客様のニーズと環境に応じて、各ゾーンにはさまざまなリソースを含めることができます。ゾーンの詳細については、 次のリンクを参照してください

マシンカタログ、デリバリーグループ、リソースの場所

Citrix管理者は、VDAもアベイラビリティーゾーン(AZ)に分散するようにする必要があります。AWS アベイラビリティーゾーン(AZ)は、AWS リージョンで、冗長電源、ネットワーキング、および接続を備えた 1 つ以上の個別のデータセンターです。AWS データセンターをクラスターする世界中の物理的な場所です。仮想プライベートクラウド(VPC)は、リージョンのアベイラビリティーゾーンにまたがる仮想ネットワークです。サブネットは VPC の必須サブコンポーネントであり、仮想ネットワークインターフェイスはそれぞれ 1 つのサブネットにアタッチされます。各サブネットは完全に 1 つのアベイラビリティーゾーン内に存在する必要があり、複数のゾーンにまたがることはできません。別のアベイラビリティーゾーンでVDAを起動すると、アプリケーションを1つの場所で障害から保護できます。 Amazon VPC って何ですか?を参照してください。 詳細については。AZ 間でVDAを分散させるには、AZごとにマシンカタログを作成し(AZごとに1つのホスト接続を使用)、それを1つのデリバリーグループにマッピングできます。

AWS でのプロビジョニング:マシン作成サービス

CVAD 1811 のリリース以降、ロールベースの認証は、 AWS で MCS プロビジョニング用のホスト接続を作成するときに使用できます。 EC2 インスタンスの Delivery Controller または Cloud Connector に関連付けられた IAM ロールまたは IAM ユーザーアカウントは、ユーザーの秘密キーと API キーの代わりに使用でき、セキュリティの強化、管理権限の委任、一時的な認証情報とセッショントークンを持つ PKI ベースの環境を実現できます。ロールベース認証を使用してホスト接続を設定するには、まず、 CTX140429で説明されている権限を持つIAMロールを作成しますこのロールを、CVAD 1811+ Delivery Controller または Cloud Connector を持つ EC2 インスタンスに関連付けます 。 1811 より前のバージョンの CVAD では、管理者は IAM ユーザーの API キー (アクセスキー) とシークレットキーを提供してホスト接続を作成する必要があります。

ホスト接続を作成したら、AWSのマスターVDAイメージから作成されたAMIを使用して、 ここでの説明に従ってマシンカタログを作成します 。AWSのMCSの詳細については、次の記事を参照してください: AWS Deep Dive 1上のCitrix MCSおよびAWSでプールされたVMが作成された後のMCSの仕組み

MCSを使用してAWSにVDAをデプロイする際に考慮すべきもう1つの項目は、 EBSボリュームの初期化 (事前ウォーミングまたはハイドレーションとも呼ばれます)です。スナップショットから復元されたボリュームの場合、ストレージブロックを Amazon S3 からプルダウンし、ボリュームに書き込む必要があります。この予備的なアクションには時間がかかり、各ブロックが最初にアクセスされるときの I/O 操作のレイテンシーが大幅に増加する可能性があります。ボリュームのパフォーマンスは、すべてのブロックがダウンロードされ、ボリュームに書き込まれた後に達成されます。「 Windows for AWS での Amazon EBS ボリュームの初期化」を参照してください。Windows インスタンスで Amazon EBS ボリュームを初期化するための推奨手順と、Linux インスタンス用 Linux での Amazon EBS ボリュームの初期化を参照してください

MCS に関連する VPC 設計の詳細については、 インフラストラクチャ (またはプラットフォーム) レイヤーの考慮事項を参照してください

マシン作成サービスのトラブルシューティング

このセクションでは、いくつかの一般的な問題と、関連する推奨事項/解決方法のリンクを示します。

インフラストラクチャ(またはプラットフォーム)層に関する考慮事項

Citrixアーキテクチャ設計フレームワークでは、インフラストラクチャ(またはプラットフォーム)層は、Citrixワークロードを実行する物理要素を定義します。このドキュメントでは、もちろん AWS を指します。AWS は多くのクラウドサービス(165 以上)を提供しており、現在存在するハイパースケールクラウドプロバイダーの中で最も古く、最大規模です。また、Citrix仮想化テクノロジーによってサポートされる最初のパブリッククラウドであり、既存のCitrix仮想化ワークロードを「クラウド」で移行または実行しようとしている新規または既存のCitrixのお客様にとって魅力的なオプションです。

コードとしてのインフラストラクチャと AWS オブジェクトモデル

Citrix 仮想化テクノロジが AWS 上でどのように統合され、実行されているかを理解するには、まず、一部のキー/関連サービスの背後にあるオブジェクトモデルの基本的な理解から始めると便利です。これにより、ほとんどの IT プロフェッショナルに馴染みのある言葉で AWS プラットフォームを説明することもできます。この理解を容易にするために、AWS 上の DaaS リソースロケーションの設計パターンを表す次の図を参照します。

図14: Citrix DaaSおよびAWSに導入された「リソースロケーション」アーキテクチャ/設計パターン 図14: AWS上のCitrix DaaSに導入された「リソースロケーション」アーキテクチャ/設計パターン。

この設計パターンは、AWS のほとんどの Citrix 仮想化システムアーキテクチャの基礎となります。また、これは単なる大規模なパターンではなく、AWS 上のエンタープライズ IT 向けのさまざまな異なる設計パターンに基づいて構築され、よく維持され、文書化されています。これらのパターンは、 AWS CloudFormation テンプレートを使用して表現、文書化、再現されます。AWS では、 クイックスタートテンプレートのライブラリを提供しています 。このテンプレートはそのまま実行でき、他のテンプレートと階層化 (「ネスト」) でき、独自のニーズに合わせて複製およびカスタマイズすることもできます。これは、パブリッククラウドインフラストラクチャのその他の主なメリット、すなわち、 コードとしてのインフラストラクチャと、多くのクラウドサービスの「お支払い」という性質を示しています。まもなくCitrix仮想化の世界のコードとしてのインフラストラクチャについて深く掘り下げますが、このホワイトペーパーで期待される読者に共感できるような迅速なタッチポイントで強調します。多くのエンタープライズITアーキテクトにとって、このような膨大なサービスライブラリ、デザインパターン、あなたの指先でテクノロジーツールは素晴らしいです。リソース消費時に料金を支払い、完了したら削除できる機能と組み合わせて?これは、新しいものについて学習または評価するための強力な方法であり、大規模な投資のROIを理解し、コミュニケーションをはるかに容易にします。

AWS オブジェクトモデルに戻りましょう。図 14 の最上位オブジェクトは AWS リージョンです。 AWS リージョンは、 アベイラビリティーゾーンと呼ばれる、適切に接続されているが戦略的に分離されたデータセンターのクラスターと考えることができます。 各リージョンには通常、2 つ以上のアベイラビリティーゾーンが含まれます。アベイラビリティーゾーンは、冗長電源、ネットワーキング、および接続性を備えた 1 つ以上の物理建物で構成されます。この執筆時点では、AWS は世界で 23 のリージョンがあり、69 のアベイラビリティーゾーンで構成されていますが、新しいリージョンや AZ に常に投資していることに注意することが重要です。これらの数字は、私たちのほとんどに驚異的ですが、あなたがこれを読む頃にはすでに時代遅れです。これは、AWS のパブリッククラウドインフラストラクチャに移行することのその他の利点の 1 つを強調しています。つまり、長期にわたって (ほとんどの IT 組織や政府の手の届かない規模で) 投資の恩恵を受け続けています。この継続的な進化/改善は、変化を嫌うIT組織やビジネス文化にとって困難な一方で、この「新しい」モデルに適応することで、エンタープライズITに幅広いメリットをもたらします。

AWS リージョンの採用は、多くの場合、近接性、利用可能なサービス、コスト、コンプライアンス、または SLA に基づきます。Citrix仮想化システムに適したリージョンを1つ以上選択することはこのドキュメントの対象外ですが、選択を行う際には、少なくとも次の点を考慮してください。

  • AWS に接続している既存のカスタマーマネージドデータセンターが 1 つ以上ある場合は、データセンターや主要オフィスへのネットワーク接続が最もレイテンシーが低いリージョンを 1 つ以上検討してください。
  • すべてのリージョンで、 お探しのある AWS サービスまたはインスタンスタイプを持つことはできません。AWS は、新しいサービスまたはインスタンスタイプを最初にいくつかのメインリージョンにデプロイし、その後時間の経過とともに残りのリージョンに展開します。 また、新しいリージョンには古いインスタンスタイプを含めることはできません。可能な限り、構築する前に調査を行ってください。
  • CVAD サイトと DaaS リソースの場所は、 特定のリージョンにバインドされています。サイト/リソースの場所の個々のコンポーネント(Cloud Connector、StoreFront サーバー、ADC/Gateway VPXインスタンスなど)の高可用性は、特定のリージョンの複数のアベイラビリティーゾーンにリソースを配置することによって実現されます。
  • インフラストラクチャを複数のリージョンに分散させないでください。AWS では簡単に実行できますが、システムを拡張する前に、予想されるペイオフと比較してコストと複雑さを考慮してください。場合によっては、ネットワークトラフィックとストレージトラフィックに支払うことになります。地域に対してローカルなトラフィックの場合、コストは些細なことがありますが、トラフィックが地域やインターネットを通過すると上昇します。

図 14 でレイヤーをステップアップすると、このデザインパターンのネットワーク構成の一部を見てみましょう。AWS の主要なネットワーク構成は VPC または「仮想プライベートクラウド」です。VPC はリージョンの構成物(AZ にまたがる)です。Citrix 仮想化テクノロジを展開する各リージョンに少なくとも 1 つの VPC があります。VPC には、IP アドレスの CIDR ブロックが定義されています。ネットワーク設計が複数の VPC 間でトラフィックをルーティングする場合は、一意である必要があります。VPC はさらにサブネットに分割され、サブネットは AZ に関連付けられます(つまり、リージョン内の AZ にまたがることはありません)。

サブネットには、ルーティングポリシーやセキュリティポリシーなど、さまざまな属性とオブジェクトが関連付けられています。このドキュメント(およびその他のCitrixドキュメント)で強調されているデザインパターンでは、Cloud Connectorとは別のサブネットにVDAを配置することを推奨しています。そのため、VDAとCloud Connectorに異なるルーティングポリシーとセキュリティポリシーを割り当てることができます。

VPC 内の任意のサブネット (リージョンの構成) からのアウトバウンドインターネットアクセスは、さまざまな方法で処理できますが、一般的な方法は、 NAT ゲートウェイを使用してプライベートサブネットへのインターネット接続を提供することです 。パブリックサブネットは、多くの場合、 インターネットゲートウェイによって提供されます。これにより、インターネットからアクセス可能なサービスへの受信接続のルーティングが容易になります。

サブネットは、一般に「パブリック」と「プライベート」というラベルが付けられます。パブリックサブネットは、(プライベート IP アドレスに加えて)インターネットルーティング可能な IP アドレスが割り当てられたサブネットであり、インバウンドおよびアウトバウンドの両方のインターネットトラフィックの Internet Gateway(IGW)へのルートを持つルートテーブルに関連付けられます。プライベートサブネットは、プライベート IP アドレスのみが割り当てられたサブネットで、パブリックサブネットに存在する NAT ゲートウェイまたは NAT インスタンスを介したアウトバウンドインターネットアクセス用のルートを持つルートテーブルに関連付けられます。Citrix仮想化システムでは、Gateway仮想サーバー(VIP)は通常、パブリックサブネットに存在します。これは、インターネット経由のクライアントデバイスからのインバウンド接続を受け入れ、Citrix仮想化トラフィックをVPC内のプライベートサブネットに安全にプロキシするために使用されます。

AWS でネットワークを構築する方法はたくさんありますが、他の場所では手に入れない革新的な機能やテクニックが多数用意されています。ここではそれらすべてを紹介するつもりはありませんが、検討する価値がある 2 つのツール/テクニックは VPC [ピアリングとトランジットゲートウェイです](https://aws.amazon.com/transit-gateway/)。これら 2 つの構成は、VPC 間のトラフィックのルーティングを単純に (VPC ピアリング)、またはエンタープライズ対応のハイブリッドクラウド対応モデル (トランジットゲートウェイ) でトラフィックをルーティングするのに役立ちます。

ここで掘り下げることができるのはもっとたくさんあります。好奇心旺盛でやる気のある人のために、パブリックドメインの知識が豊富にあり、あなたの指先で詳細を学ぶことができます。ここでは、このペーパーで見たすべての図の下に、パターンのデザインに戻しましょう。

AWS プラットフォームの魅力的な属性の 1 つは、パブリックに消費可能な API に基づいて構築されていることです。なぜこれは魅力的ですか?つまり、AWS で実行できるインフラストラクチャコンポーネントの多くは、 コードから再現可能な構築が可能ですAWS CloudFormationなどの強力で包括的なデプロイサービスと組み合わせると、お客様は IT システムについて学習、カスタマイズ、デプロイ、管理するための強力なフレームワークを手に入れることができます。 Infrastructure as Code(コードとしてのインフラストラクチャ )の概念は、多くの従来のエンタープライズにフォーカスした技術者にとっては新しいものであったり、困惑したりする可能性がありますが、採用され実践されると変革につながる可能性があります。

先に述べたように、AWS は CloudFormation ベースのクイックスタートテンプレートのライブラリを提供します 。このテンプレートはそのまま実行でき、他のテンプレートと階層化 (「ネスト」) でき、独自のニーズに合わせて複製およびカスタマイズすることもできます。このテンプレートライブラリは、Citrix などのテクノロジーパートナーと協力して AWS によって管理、保守されます。これらのテンプレートは、多くの場合、オープンソースです(つまり、必要に応じて複製および変更できます)。執筆時点では、AWS 上の Citrix テクノロジでは、次のクイックスタートテンプレートを使用できます。

  • Webアプリケーション向けNetScaler ADC -可用性の高いNetScaler ADC VPXインスタンスをAWSにデプロイします。ユースケースの焦点は若干異なりますが、この設計パターンは機能的であり、CVAD/DaaSを使用するCitrix Gatewayの導入にも関連しています。

概要 — AWS での Citrix のデザインパターンについて

まだ混乱してる?もしそうなら、心配しないでください。これは、Citrix on AWS パブリッククラウドへの移行の始まりになる可能性があります。ここでは、多くの深いトピックの表面を説明しただけです。しかし、うまくいけば、次の顕著な点をうまく説明しました。

  • コードとしてのインフラストラクチャは、完全なシステムの設計、構築、保守の方法に革命をもたらす強力なコンセプトです。
  • AWS のパブリッククラウドにシステムをデプロイする場合、任意のソリューションのさまざまなコンポーネントをコードで表し、AWS CloudFormation やその他のテクノロジーを使用してオンデマンドで構築できます。
  • これらのコンポーネントは、AWS CloudFormation の使用時にスタックテンプレートで表され、必要に応じてテンプレートをコピーおよび変更して、目的の結果を得ることができます。
  • テンプレートはネストして、個々のデザインパターン(テンプレート)から完全なシステム(AWS 上の完全に機能する DaaS リソースの場所など)を構築できます。
  • Citrix DaaS on AWSクイックスタートテンプレートは 、AWSが管理/保守する3つの基盤テンプレートに基づいて構築されており、これらは十分に文書化されています。次のリンクから始めて、それぞれの詳細をご覧ください。
  • エンタープライズテクノロジストは、テンプレートを使用してトライアルビルドを実行することにより、組織または顧客の特定のニーズを満たすシステムについて学習、評価、設計することができます。

AWS インフラストラクチャ層 — 追加リソース

AWS での Citrix 仮想化の要件と主要なプラクティスの詳細については、以下のリソースを使用できます。

操作レイヤに関する考慮事項

このセクションでは、管理者が定期的に実行する運用アクティビティを定義します。これらの多くは AWS に固有のものではなく、既存の公開ドキュメントに詳述されています。次の表は、より重要な AWS 固有のタスクの一部をまとめたものです。詳細については、Citrix 製品ドキュメントの「 監視」トピックを参照してください

オンデマンドタスク

次の表に、アプリケーション要件とトラブルシューティングの取り組みに基づいて、オンデマンドで実行することが予想されるタスクの概要を示します。

コンポーネント タスク 説明
汎用 ナレッジベースの更新 Citrix Teamが環境に関連する問題のトラブルシューティングを行う場合、問題の解決策を特定します。今後のトラブルシューティング活動をサポートするために、問題ごとにKBAを作成する必要があります。
Citrix DaaS イメージを修正 要求をサポートするために、必要に応じてイメージを更新する必要があります。更新は毎月行われる可能性がありますが、テストにはより頻繁な更新が必要になる場合があります。
Citrix DaaS 画像を公開 イメージが変更されると、それらはテストされ、公開されます。
AWS インスタンスの起動の確認 MCS 経由で新しいインスタンスを起動する場合は、インスタンスが AWS コンソールで作成されていること、および指定された VPC のプールに使用可能な IP があることを確認します。VPC プールに使用可能な IP がない場合、MCS プロビジョニングされたマシンは作成されません。
AWS オンプレム画像の有効性を検証する オンプレミスイメージから作成されたインスタンスは、本番インスタンスの更新に使用する前に、起動可能性と実行可能性をテストする必要があります。
AWS IAM ユーザー/グループのアクセス許可の変更 必要に応じて、IAM ユーザーとグループのアクセス許可を確認して、管理者アクセス権を持つユーザーの数を減らし、「最小特権」の方法を実装する必要があります。
AWS セキュリティグループの変更 必要に応じて、セキュリティグループを確認して、さまざまな IP または IP 範囲からのさまざまなトラフィックプロトコルのアクセスを許可または削除する必要があります。ネットワークトラフィックロックダウンを実装するには、入力ルールと出力ルールを変更する必要があります。
AWS と Citrix DaaS マシンカタログ内のマシンの更新 必要に応じて、マシンイメージを更新して、必要な変更を含めます。変更されたイメージから新しいAMIを作成し、マシンカタログを更新するために使用する必要があります。詳細については、このドキュメントの「更新およびアップグレードプロセス」セクションを参照してください。
AWS と Citrix DaaS マシンカタログへの更新のロールバック 必要に応じて、マシンイメージをロールバックする必要がある場合は、前回既知の作業構成を持つ以前のAMIを使用して、マシンカタログ内のマシンを更新できます。

毎日の定期的なタスク

次の表に、毎日実行すべきタスクの概要を示します。

コンポーネント タスク 説明
汎用 Citrix Director、Windowsパフォーマンスモニター、イベントログ、その他の監視ソフトウェアの通知の確認 Citrix Director、イベントログ、またはその他の監視ソフトウェア内の警告や通知を確認します。通知の根本原因がある場合は調査します。注: コンピュータとモニターを設定して、Citrix Directorダッシュボードを表示して、Citrix部門のヘッドアップディスプレイを作成し、環境のステータスが明確に表示されます。Citrix Virtual Apps and Desktopの監視に関する推奨事項は、『Citrix Virtual Apps and Desktopsのベストプラクティス』の[監視 ]セクションに含まれています。
汎用 バックアップが正常に完了したことを確認する スケジュールされたすべてのバックアップが正常に完了したことを確認します。これには、ユーザーデータ(ユーザープロファイル/ホームフォルダ)、アプリケーションデータ、Citrixデータベース、Citrix StoreFront 構成、Citrixライセンスファイルが含まれますが、これらに限定されません。
汎用 環境アクセスのテスト 内部と外部の両方の接続をシミュレートして、ほとんどのユーザーがその日にログオンする前に、デスクトップリソースとアプリケーションリソースが使用可能であることを検証します。この接続は1日を通してテストされ、自動化することもできます。
Citrix Virtual Apps and Desktops 仮想マシンの電源チェック アイドル状態のデスクトップとアプリケーションサーバーの適切な数が Delivery Controller に登録され、ユーザーのワークロードの可用性を確認します。
AWS インスタンスの健全性のチェックを実行する AWS コンソールをチェックして、インスタンスと基盤となるハードウェアの状態を確認します。すべてのインスタンスは、パワーオン時に 2 つのヘルスチェックに合格する必要があります。
Citrix Virtual Apps and Desktops Citrix関連データベースの増分バックアップの実行 次のCitrixデータベースの増分データバックアップの実行:サイトデータベース、構成ログデータベース、監視データベース

毎週の定期的なタスク

次の表に、週単位で実行されるタスクの概要を示します。

コンポーネント タスク 説明
汎用 最新のホットフィックスとパッチを確認する 最新のCitrix Hotfixを確認、テスト、および展開し、Delivery ControllerとサーバーベースOSまたはデスクトップベースOS仮想マシンにそれらが必要かどうかを把握します。SCCM または WSUS 経由で AWS のマシンにデプロイされた Microsoft の更新の場合、すべてのマシンがパワーオン時にこれらの更新を受け取ります。Citrix Power Managementを使用している場合は、マシンカタログに通常の電源が入っていないマシンが存在する可能性があります。イメージの更新を実行するときは、すべての更新サイクルでパワーオンされている動的マスターインスタンスを使用することをお勧めします。次に、このインスタンスから AMI を作成し、必要なパッチをすべて含めることができます。注: 必要な修正プログラムは、運用環境に実装する前に、推奨されるテストプロセスを使用してテストする必要があります。
汎用 Citrix環境ステータスレポートの作成 環境全体のパフォーマンス(サーバーの正常性、リソース使用率、ユーザーエクスペリエンス)とCitrixの問題(達成率、未解決の問題など)の数に関するレポートを作成します。
汎用 ステータスレポートの確認 Citrixステータスレポートを確認して、傾向や一般的な問題を特定します。
汎用 社内サポートの知識ベースの維持 KBAを作成し、レベル1およびレベル2のサポート要求に対処するための解決スクリプトを発行します。正確性、コンプライアンス、実現可能性について、KBAと問題解決スクリプトを確認します。
Citrix Virtual Apps and Desktops 構成ログレポートの確認 前週に実施されたCitrixサイト全体の変更が変更管理によって承認されたことを確認します。
Citrix Virtual Apps and Desktops Citrix関連データベースのフルバックアップの実行 サイトデータベース、構成ログデータベース、監視データベースのCitrixデータベースのフルデータバックアップを実行します。
AWS すべての EBS ボリュームのスナップショットを実行する すべての Elastic Block Storage ボリュームは、定期的にスナップショットされます。スナップショットは AWS EC2 コンソールで管理およびクリーンアップできます。

毎月の定期的なタスク

次の表に、毎月実行するタスクの概要を示します。

コンポーネント タスク 説明
汎用 容量評価の実行 Citrix環境の環境パフォーマンスと容量評価を実施し、環境の使用率と拡張性の要件を特定します。監視ツールの月次レポートを確認して、仮想サーバの計算(CPUおよびRAM)の割り当て、ライセンス、ネットワーク帯域幅など(ただしこれらに限定されない)環境のパフォーマンスと容量を評価します。必要に応じて、ソフトウェアまたはライセンスを調達し、追加のサーバーを構築します。注: 容量評価を実施するための推奨事項は、「 設計上の決定:単一サーバーの拡張性」に含まれています。
汎用 管理者特権アクセスの確認 環境への昇格されたアクセス許可を持っているユーザーとグループを確認し、継続的な昇格されたアクセスが必要かどうかを評価します。これらの管理者権限が不要になったアカウントをすべて削除します。主に、昇格された特権の割り当てに使用される IAM ユーザーとロールのみであり、個々のユーザー、ローカル、またはルートアカウントへのアクセスが厳しく制限されています。

毎年の定期的なタスク

次の表に、毎年実行するタスクの概要を示します。

コンポーネント タスク 説明
汎用 Citrixポリシー評価の実施 Citrixポリシーを確認し、新しいポリシーが必要かどうか、および既存のポリシーを更新する必要があるかどうかを判断します。
汎用 ソフトウェアアップグレードの確認 Citrixの新しいソフトウェアリリースまたはバージョンの要件を確認して評価します。
汎用 BCP(ビジネス継続性計画)/災害復旧(DR)テストの実行 DRの準備状態を確認するための機能的なBCPおよびDRテストを実施する。この計画では、毎年リストアテストを実施し、バックアップデータからの実際のリストアプロセスが正常に機能していることを検証します。
汎用 アプリケーション評価の実行 Citrix環境の外部および内部でのアプリケーションの使用状況を確認します。Citrixサイトへのアプリケーションの追加、不要になったアプリケーションの削除、または最新バージョンへのアプリケーションのアップグレードの有効性を評価します。
AWS ネットワークセキュリティグループアクセスの評価 Citrixインフラストラクチャサーバーまたはアプリケーションサーバーで機能またはアプリケーションが追加または削除されると、それらのインスタンスに関連付けられたネットワークセキュリティグループも評価および変更され、必要に応じてポートまたはプロトコルを追加または削除する必要があります。

ソース

このリファレンス・アーキテクチャの目的は、お客様独自の実装計画を支援することです。この作業を簡単にするために、独自の詳細な設計と実装ガイドに適応できるソース図を提供します。 ソース図です

リファレンスアーキテクチャ:Citrix DaaS-AWS

この記事の概要