リファレンスアーキテクチャ-Google CloudでのCitrix 仮想化
注：
このドキュメントの内容は再構成され、 Google Cloud上のCitrix DaaS ソリューションハブに組み込まれています。元の文書の内容は、完全性と参照可能性のために移行中にここに残されます。
はじめに
このガイドでは、GCP上でCitrix仮想化システムを設計する手順について説明します。移動が進むにつれ、必要な意思決定の意味について議論し、その途中でより多くの参照リソースをキュレーションします。このガイドは生きている文書です。それをブックマークし、定期的にチェックして、時間の経過とともに物事がどのように変化するかを確認してください。
まず、Google Cloud上のCitrix 仮想化テクノロジーの一般的な設計パターンを確認します 。これらの「デザインパターン」を「リファレンスアーキテクチャ」と考える人もいますが、インフラストラクチャをコードおよびクラウドサービスとして扱う場合、「デザインパターン」はもっと理にかなっています。
次に、 ソリューションのコンポーネントと要件について説明します。ソリューションの前提条件を示し、Citrix Cloud の「リソースの場所」を作成するために必要なサービス/コンポーネントの概要を示します。
次に、Google Cloud上のCitrix 仮想化システムのサービス/コンポーネントをより深く理解することで、設計パターンを再検討し、さらに深く掘り下げます。最後に、 Virtual Delivery Agent（VDA）の設計と管理、Google Cloud上のNetScaler ADC/Gateway、Google Cloud上のCitrixStoreFrontなど、特定のトピック領域について深く掘り下げます。
あなたが私たちと一緒にこの旅に参加する場合、私たちは途中であなたのコメント、貢献、質問、提案、フィードバックを共有することをお勧めします。 フィードバックはこちらから送信してください。
GoogleクラウドでのCitrix仮想化のデザインパターン
私たちは、「クラウド」への移行において、お客様によって異なる段階にあることを認識しています。そのため、「みんな入っている」から「そこに着くけどしばらくかかる」までのスペクトルを表す3つのデザインパターンを概説します。観察された技術者は、3つすべての共通の要素を参照してください。顧客マネージドサービスとクラウドサービスを組み合わせて、さまざまなビジネスニーズや環境への影響に対応できる方法を理解し始めます。 このガイドの後半でこれら 3 つの設計パターンを再検討するときに 、このサブシステムのモジュール性について調べます。
クラウドフォワード設計パターン
あらゆる形態と規模の組織が、「クラウド」とサブスクリプションベースのマネージドサービスに移行しています。すべての「クラウド」を利用している（またはクラウドが提供する最高のものを体験することに興味がある）お客様にとって、クラウドフォワード設計パターンは最適です。クラウドフォワードデザインパターン：
- CitrixとGoogleが提供する最先端のクラウドサービスを使用します。
- テクノロジ評価、校正、トレーニング、および導入のシンプルさ、柔軟性、スピードを重視するその他のユースケースに加えて、新しい導入に一般的に使用されます。
- 既存のインフラストラクチャやライセンスは必要なく、 Citrix on GCP GitHub プロジェクトなどのGoogle Deployment Manager テンプレートを使用して 30 分未満で構築できます。
- すべての重要なサービスの高可用性を提供
- Citrix Cloud の「リソースの場所」を作成します。これは、ここで説明する他の2つのパターンの基盤です。
始めるために必要なのは、GCPプロジェクトとCitrix Cloud DaaS（DaaS ）サブスクリプションへのアクセスだけです。Citrix Cloudの評価サブスクリプションは、CitrixおよびCitrix認定リセラーを通じて利用できます。また、Google は新規のお客様に、300 USD の Google Cloud クレジットを含む無料トライアルも提供しています 。
注:
GCP の無料トライアルには、 Google Cloud 無料利用枠のドキュメントに記載されているように、Windows Server イメージの使用は含まれていません。Windows Server イメージを使用するには、GCP で有料アカウントにアップグレードする必要があります。Google Cloud 無料利用枠のドキュメントの「 有料アカウントへのアップグレード」セクションに記載されているように、有料アカウントにアップグレードしても無料クレジットが適用されます 。
このデザインパターンでは、特定の Google Cloud リージョンの個別のゾーンにデプロイされたすべての主要リソース（➊）を複数使用して、高可用性を実現します。
Citrix Cloud Connector（❷）は、インターネットを介したCitrix Cloudサービスへの送信TLS接続を使用して、Citrix Cloud（❻）との通信を担当します。ドメインに参加しているWindows Server VMインスタンスにインストールされると、Cloud Connector ソフトウェアは自動的に更新され、Citrix Cloudによって保守されます。
アプリとデスクトップは、WindowsまたはLinux VMインスタンス、またはその両方がCitrixのVirtual Delivery Agent（VDA）ソフトウェア（❸）を実行することによって提供されます。Citrix VDAソフトウェアは、 Citrixの高度なHDXテクノロジーを使用して 、仮想化されたアプリケーションとデスクトップで可能な限り最高のユーザーエクスペリエンスを提供します。VDAはCitrix Cloud Connectorに登録され、VDAへのHDXセッション接続の仲介を行います。HDXセッションは、デフォルトでCloud Connector経由でVPCにプロキシされます。または、必要に応じて「ランデブー」ポリシーを構成してNetScaler Gateway Serviceを介してプロキシされます。オプションで VM インスタンスを Google Cloud GPU でバッキングして仮想ワークステーションを作成し、グラフィックを多用するアプリケーションを高速化できます。
Citrix VDAは、配信されるアプリケーション（❹）に必要なインフラストラクチャの近くに配置されることが最も一般的です。そのため、通常、アプリケーションインフラストラクチャはCitrix VDAと同じリージョンに展開または移行されます。
エンドユーザーは、 Citrix Workspace アプリ （❺）（CWA）を使用して、 Citrixの革新的なHDXセッションリモートプロトコルを使用して、仮想化されたアプリケーションやデスクトップに接続して操作します。CWA は、Chrome OS、Windows、OSX、iOS、Android、Linux など、ほぼすべてのデバイスまたはオペレーティングシステムで利用できます。
このパターンでは、Citrixの次のクラウドサービス（❻）が使用されます。これらのクラウドサービスは、安全性と可用性が高く設計されています。
- Citrix Virtual Apps and Desktop Service： セッション仲介、負荷管理、シングルインスタンスイメージ管理、監視、コスト/容量管理サービスを提供します。
- Citrix Workspace サービス： ソリューションのユーザーインターフェイス。このWebサービスは、Citrix Workspaceアプリの多要素認証、コンテンツ表示、および起動サービスを提供します。このサービスは、エンタープライズファイルストアに加えて、仮想アプリケーション、デスクトップ、Web、SaaS アプリケーションへのアクセスを統合します。
- NetScaler Gateway Service： エンタープライズWebアプリケーションに加えて、仮想化されたアプリケーションとデスクトップへのパブリックネットワーク上のデバイスへの安全なアクセスを提供します。
- Citrix Analytics Service： 高度な機械学習テクノロジーを使用して、エンタープライズグレードのセキュリティ、パフォーマンス、およびユーザー行動分析とレポートを提供します。
このデザインパターンは、Google Cloud VPN/InterConnect、または Citrix SD-WAN（❼）などの目的に構築されたソリューションと組み合わせて、既存の Active Directory 投資（❽）を Google Cloud に拡張したり、従来型のオンプレミス、顧客管理アプリケーションやインフラストラクチャへのアクセスを提供したりすることもできます。
ハイブリッドデザインパターン
ハイブリッドデザインパターンは、クラウドフォワードデザインパターンに基づいて構築されます。Citrix（➊）から顧客管理型のアクセスレイヤーコンポーネントを導入し、特定の顧客人口統計とユースケースのニーズを柔軟に満たします。カスタマー管理コンポーネントには、次のものがあります。
-
NetScaler ADC/Gateway（❷）：GCPに仮想アプライアンスとして展開されるこのコンポーネントは、次の1つ以上を必要とするユースケースによく使用されます。
- SAML/OAUTH 2/OpenID フェデレーション、RADIUS、スマートカード、条件付きアクセス要件など、高度な認証シナリオ。
- パブリックネットワーク上のエンドユーザーデバイスに対して、高度に最適化された柔軟なセッションアクセス。
- コンテンツスイッチング、Web アプリケーションファイアウォール、統合 Web キャッシング、攻撃の軽減、アプリケーション負荷分散、SSL オフロードなどの高度なネットワークサービス
- 高度で柔軟性が高く、コンテキストに応じたポリシーに基づいて、特定のユーザー/デバイスを特定の「ストア」に誘導できます。ポリシーの決定は、ユーザープロファイルの属性、場所、デバイスタイプ、デバイスの健全性、認証結果などに基づいて決定できます。
-
Citrix StoreFront（❸）：Citrix Workspace サービスの前身であるStoreFrontは、Citrix のUIサービスの「クラシック」プロバイダーです。StoreFront は、顧客管理型のWindows Serverインスタンスにインストールされ、多くの場合、以下の1つ以上を必要とするユースケースで使用されます。
- 非常に高い可用性。特に、高可用性構成に導入した場合に、より広範な障害シナリオに耐えることができます。
- 柔軟なセッションルーティング。Citrix Gateways経由で外部ユーザーを送信しながら、内部ユーザーセッショントラフィックを直接VDAにルーティングする機能を備えています。
- カスタマー管理型のオンプレミスデバイスからのシングルサインオン。
- 同じシステム上で多様なユースケースをサポートするために、異なる構成プロパティを持つ複数の「ストア」を提供する必要があります。
- 高度にカスタマイズされた、またはブランド化された HTML ベースのユーザーインターフェイスの必要性。
ハイブリッドデザインパターンでは、Citrixアクセスレイヤーコンポーネントがお客様のGoogle Cloud環境（➊）に展開されます。コンポーネントは、通常、高可用性を実現するために、複数のゾーンに分散されたペアで展開されます。
このパターンでは、CitrixのADC/Gateway VPX（仮想）アプライアンスを使用して、お客様の環境（❷）内のVDAにHDXセッションを安全にプロキシします。NetScaler ADC/Gatewayアプライアンスは、シンプルなセッションプロキシサービス、複雑な認証シナリオ、またはその両方（UIオプションA）にCitrix Workspaceサービスとともに使用できます。また、Citrix StoreFront（UIオプションB）とペアリングすることもできます。
このパターンでは、UIサービスにCitrix StoreFront (❸) を使用することもできます。これにより、システムは上記のように複雑なユースケースの要件を満たすことができます。これは、UIおよびHDXセッションプロキシサービスに加えて認証を処理するNetScaler ADC/Gatewayとペアリングします。
クラウド移行の設計パターン
クラウド移行設計パターンは、ハイブリッド設計パターンに基づいてさらに構築されます。これにより、Citrixテクノロジーに既存の投資を行っているお客様は、インフラストラクチャを体系的にモダナイズしながら、ワークロードをクラウドにシームレスに移行できます。この移行は、既存のシステムや重要なシステムやユースケースを中断しないペースで実行できます。これにより、技術的に保守的なお客様は、ワークロードごとにクラウドに「ウェイド」し、お客様の条件に沿ってリスクを軽減できます。また、お客様は、Citrix とGoogleが提供する最新のテクノロジーについて体系的にスタッフを再キルし、管理しやすいペースで組織のクラウド対応状態を構築しながら、テクノロジー、インフラストラクチャ、知識、プロセス、運用化への既存の投資を活用できます。手順。
クラウド移行の設計パターンは、前のセクションで説明したハイブリッドパターンから始まります。ハイブリッドパターンを使用して構築されたシステムは、新しいワークロードを導入する最新の新しい環境になります。クラウド移行パターンでは、Citrix StoreFront（➊）またはCitrix Workspace（❷）ユーザーインターフェイス、またはその両方を使用して、従来のCitrix環境（❸）を新しい環境に接続します。これは、両方のUIが単一のログインで複数の仲介環境を単一のビューに表示できるからです。これにより、ユーザーは両方の環境にアクセスするために使用できる単一の UI (❹) が提供されます。これにより、お客様は新しいワークロードを Google Cloud（❺）にデプロイし、ビジネスの機会や制約に応じて既存のワークロードを Google Cloud に体系的に移行できます。
デザインパターンを確認したので、レイヤーを少し剥がしましょう。それでは、GoogleクラウドでCitrix仮想化システムを構築するために必要なものを見てみましょう。
ソリューションのコンポーネントと要件
仮想化システムの前提条件
Google Cloud上でCitrix仮想化システムを構築するには、少なくとも2つの作業を開始する必要があります。
- Googleクラウドプロジェクト
- Citrix の DaaS サブスクリプション
注：
GCP 無料トライアルには、 Google Cloud 無料利用枠のドキュメントに記載されているように、Windows Server イメージの使用は含まれていません。Windows Server イメージを使用するには、GCP で有料アカウントにアップグレードする必要があります。無料クレジットは、Google Cloud 無料利用枠ドキュメントの「 有料アカウントへのアップグレード」セクションに記載されているように、有料アカウントにアップグレードする場合にも適用されます 。
前提条件が並んだ？よかった！それでは、あなたが構築しているものを紹介しましょう。
ヒント：
このサービスはソリューションの中核となるため、Citrix DaaSのドキュメントは適切です。ビルドを始める前に必ず読んで、さらに情報が必要なときに便利にしておいてください。 Citrix ドキュメントサイトにあります。
Citrix Cloudリソースの場所
Google Cloud上のCitrix仮想化システムの基盤は、「リソースの場所」と呼ばれるCitrix Cloud構造です。Citrix Speakにおけるリソースの場所は、GCP上のリージョンとほぼ同じです。これは、Active Directory を備えたプライベートネットワーク、インターネット出力（CitrixおよびGoogleのセキュアなクラウドサービスを利用）、および仮想化し、世界中のあらゆるデバイスに安全に提供したいアプリケーションやデータを適切に結合したリソースグループです。仮想化されたアプリとデスクトップは、「VDA」と呼ばれるGCP上のVMインスタンスから配信されます。CitrixのVDAソフトウェアを実行するWindowsまたはLinux VMインスタンスで、CitrixのHDX表示プロトコルを使用してデスクトップまたはアプリケーションのユーザーインターフェイスをクライアントデバイスにリモートできます。VDAはクラウドコネクタに登録され、Citrix Cloud Servicesとの通信を安全にプロキシします。
ヒント：
認識すべき仮想化アプリケーションを提供するための経験則の 1 つです。アプリケーション（Citrix VDA上で実行されている）をデータ（アプリに必要なインフラストラクチャ）の近くに配置する場合。アプリケーションとデータを互いにローカルに持たないと、レイテンシーが増加し、アプリケーションの速度が低下し、最終的にはユーザーエクスペリエンスが低下する可能性があります。
通常、リソースの場所は可用性を高めるように構築されます。つまり、主要なサービスは GCP リージョンのゾーンに分散されます。必要に応じて、可用性と管理性の目的で、キーサービス用に複数の VM インスタンスがデプロイされます。リソースの場所に必要な主なサービスは次のとおりです。
- *Microsoft Active Directory
- *Citrix Cloud Connector
- *クラウドNATなど、信頼性の高いインターネット出力のための方法
- *Citrix VDA（配信されるアプリケーションの下にCitrixのVDAソフトウェアがインストールされたGCP VMインスタンス）
- 必要に応じて、配信されるアプリケーションをサポートするためのその他のインフラストラクチャ
Google Cloud上に機能するCitrix Cloudリソースの場所を必要とするため、これらのサービス*の一部をさらに詳しく見ていきましょう。
Microsoft Active Directory
Googleクラウド上のCitrix仮想化システムの設計パターンはすべて、Microsoft Active Directory が必要です。魅力的なユーザーエクスペリエンスを実現するには、Active Directory サービスは、VDAを展開したすべてのGCPリージョンで利用可能である必要があります。したがって、Citrix Cloudリソースの場所のコアコンポーネントと見なされます。AD は認証に加えて構成管理 (グループポリシー) にも使用されます。ただし、後で学習するように、AD をシステムの ID プロバイダーにする必要はありません。多くのお客様は、既存のADをGoogle Cloudに拡張しますが、Citrixの仮想化はさまざまなAD設計とサービスモデルに柔軟に統合できます。
Google Cloud に Active Directory をデプロイする場合、お客様は Windows Server インスタンスを使用して独自の Active Directory ドメインコントローラを構築/保守するか、 Microsoft Active Directory 用の Google マネージドサービスを使用するか、またはこの 2 つの組み合わせを使用できます。Active Directory 信頼を使用して、お客様のニーズに応じて、2 つ以上の AD フォレスト/ドメインを接続することもできます。
機能的な Active Directory サービスの構築と維持に必要な管理オーバーヘッドを最小限に抑えたいお客様には、 Microsoft Active Directory 向け Google マネージドサービス (略してマネージド Microsoft AD) を検討する価値があります。このサービスは、Windows Server VM インスタンスを構築および保守するオーバーヘッドなしで、完全に機能する Active Directory フォレスト/ドメインを提供します。マネージド Microsoft AD サービスは、可用性の高い Google 管理インフラストラクチャ上に構築され、マネージドサービスとして提供されます。各ディレクトリは複数の GCP ゾーンにデプロイされ、監視によって障害が発生したドメインコントローラーが自動的に検出され、置き換えられます。ソフトウェアをインストールする必要はないので、Googleはすべてのパッチ適用とソフトウェアの更新を処理します。Microsoft Active Directory 用 Google の管理サービスを使用すると、Microsoft のネイティブ管理ツールを使用したり、Microsoft グループポリシーを使用して Windows マシンとユーザーを管理したりできます。VM インスタンスを VM インスタンスに参加させることもできます。また、Active Directory の信頼を既存の AD インスタンスに設定して、さまざまな複雑なエンタープライズシナリオをサポートすることもできます。
Citrix仮想化テクノロジで Google のマネージド AD サービスを使用するお客様は、これらのテクノロジが機能することを期待できます。ただし、その前に考慮すべき重要な点をいくつか挙げてください。まず、ドメイン管理者、エンタープライズ管理者、またはその他の「スーパーユーザー」タイプの AD インスタンスへのアクセス権はありません。ただし、ユーザー、コンピューター、グループ、OU、およびグループポリシーを作成できる、ディレクトリのルートにある独自のコンテナを完全に制御できます。また、他のディレクトリとのさまざまな種類の信頼関係を設定して使用することもできます。
あなたができない他のいくつかのこと：
- AD オブジェクトは、既定のコンテナ (/Computers など) のいずれかに作成します。読み取り専用です。これにより、Citrixのマシン作成サービス（MCS）プロビジョニングテクノロジを使用するときに一部の顧客が犯す一般的な間違いがあります。MCS管理VDAのマシンアカウントを、書き込み可能なコンテナ/OUに作成する必要があります。このような場所を選択しない場合、MCSはマシンアカウントを作成できません。
- 証明書サービスなど、一部の AD 統合機能をインストールして構成します。このため、Citrixのフェデレーション認証サービス（FAS）テクノロジを使用する予定のお客様は、AD統合証明書サービスを必要とするお客様に影響します。このようなお客様は、Windows Server VM インスタンスを使用して Google Cloud上に独自の Active Directory を構築および管理する必要があります。
- デフォルトでは、ローカルサーバアドミニストレータに相当します。「ボックス外の」Active Directory インストールでは、ドメイン管理者グループは既定でローカルサーバー管理者グループに追加されます。Microsoft AD 用 Google マネージドサービスを使用している場合は、独自のサーバー管理者グループを作成し、独自のユーザーを追加し、グループポリシーを作成して適用して、メンバーサーバー/ワークステーションの組み込みの Server Administrators グループにグループを追加する必要があります。
信頼関係、サイト/サービスの構成、レプリケーション、およびその他のAD関連のトピックについてはここでは説明しませんが、Citrixでは、3つの展開モデルすべてに適用可能なこれらのトピックに関する広範なドキュメントを提供しています。
注：
Google CloudでのCitrix仮想化のActive Directory 要件の詳細については、「 Citrix Cloud Connectorの技術的な詳細」を参照してください。この記事では、 サポートされているActive Directory の機能レベルについて説明するほか、 AcActive Directory yのクラウドコネクタの導入シナリオについても説明します。
重要：
DNS 名前解決は、適切に機能するシステムにとって重要です。GCP の DHCP は、常に Google のネームサーバーを使用します。VM インスタンスが GCP で Active Directory インスタンスを「検索」して参加するには、マネージド Microsoft AD サービスを使用する場合は必要ありませんが、プライベートマネージド DNS ゾーンを実装する必要があります。詳細については、Google Cloud DNS の概要をご覧ください 。
DNS名解決は、 EDT/Citrix アダプティブトランスポートの使用など、HDXセッションプロキシにCitrixのランデブー機能を実装する場合にも重要です。詳細については、 ランデブープロトコルのドキュメントを参照してください 。
Citrix Cloud Connector
Citrix Cloud Connectorは、Citrix仮想化システムのセキュアなクラウド管理プロキシとして機能します。クラウドコネクタは、リージョン内の個別のゾーンにある、ドメインに参加している Windows Server 専用のインスタンスです。また、インターネットアクセスが中断された場合のオフラインセッションブローカーとしても機能します (「ローカルホストキャッシュモード」)。可用性が極めて高いミッションクリティカルな展開に役立ちます。この機能については、この文書の後半でハイブリッドデザインパターンについて詳しく説明します。
Cloud Connectorは、通常、特定のリージョンの複数のゾーンに分散したVMインスタンスを使用して、N+1リソースとしてデプロイされます。これにより、リソースの場所を拡張でき、Cloud Connectorソフトウェアの自動更新が容易になります。
注：
Citrix Cloud Connectorのインスタンスのサイジングについて詳しくは、「Cloud Connectorのスケールとサイズの考慮事項」を参照してください。
クラウドコネクタは、Active Directory およびCitrix VDAに到達できる任意のVPC上に配置できます。また、正常に機能するためには、信頼できるインターネット出力が必要です。インターネット出力を提供するシンプルで可用性の高い方法の 1 つが Google Cloud NAT ですが、他にも多くの方法もサポートされています。厳格な下り制御または監査要件のあるユースケースでは、Cloud ConnectorからCitrix Cloud への下りトラフィックをプロキシできます。
注：
Citrix仮想化テクノロジーが使用するポートとプロトコルの詳細については、「Citrix Technologiesが使用する通信ポート」を参照してください。このドキュメントは、Google Cloud 上で確立するファイアウォールルールの基盤を提供します。
Citrix VDA
Citrix仮想化システムを機能させる必要がある最後のリソースタイプは、VDAと呼ばれ、実際のワークロードです。前述したように、これらはCitrixの「Virtual Delivery Agent」ソフトウェアを実行するWindowsまたはLinux VMインスタンスです。これにより、CitrixのHDX表示プロトコルを使用してデスクトップまたはアプリケーションのユーザーインターフェイスをクライアントデバイスにリモートできます。VDAは、任意のプロビジョニングメカニズムを使用して、システムの外部で作成および管理できます。たとえば、Googleデプロイメントマネージャーのテンプレートを使用できますが、どのような種類のスケールでも、CitrixのMCSテクノロジを使用できます。
MCSは、1つまたは複数の「ゴールデンマスター」VMインスタンスから構築された、同一の構成のVDAのグループである「マシンカタログ」の作成を自動化します。MCSは、通常ディスクのスナップショットを使用して、インストールされているオペレーティングシステムとアプリケーションスタックの状態をキャプチャします。また、「ゴールデンマスター」仮想マシンインスタンスのインスタンス属性を使用してインスタンステンプレートを作成し、これらの属性をMCS管理下のVDAに適用します。また、MCSは「ゴールデンマスター」ディスクの同様のスナップショットを使用してVDA上のシステムディスクの更新を自動化し、自動スケール機能のコストと容量を自動的に管理するための取り組みをオーケストレーションします。
VDAについて知っておくべきことはたくさんありますが、このガイドでは後で詳しく説明します。待てない？ VDAの設計と管理に関する考慮事項に直接進んでください。
注：
Google Cloudで確立するファイアウォールルールを確認するには、Citrix Technologiesが使用する通信ポートを参照してください 。
追加注意:
VDAはインターネット出力を持つ必要がありません。また、特定のユースケースでは設計上ではありません。ただし、VDAにインターネット下り接続がある場合は、 Citrixポリシーを介して「[ランデブープロトコル](/ja-jp/citrix-virtual-apps-desktops/technical-overview/hdx/rendezvous-protocol.html)」機能を有効にして、クライアントデバイス（CitrixWorkspaceアプリを実行する）とVDAがNetScaler Gateway サービスを介して安全に接続できるようにします。これにより、HDX接続をVDAにプロキシするクラウドコネクタのスケーラビリティが向上します。パブリックネットワーク経由でHDX接続をプロキシするもう1つのオプション-VPCの境界に顧客管理のNetScaler ADC/Gatewayインスタンスをデプロイします。
デザインパターン-より深くなる
この文書の前半で、Google Cloud上でのCitrix仮想化に関する3つの異なる関連デザインパターンを紹介しました。これらのパターンはお互いの上に構築され、途中でより複雑なユースケースに効果的に役立てられます。私たちはそれらを次のように参照します：
- クラウドフォワード設計パターン
- ハイブリッドデザインパターン
- クラウド移行の設計パターン
クラウドフォワード設計パターン
これは、Google CloudでのCitrix仮想化の基本的な設計パターンであると述べました。クラウドフォワードデザインパターンのアーキテクチャによって、Citrix Cloudリソースの場所が作成されることは明らかです。これは、ここに示す3つのパターンすべてで共有されている共通の基盤です。パターンの違いは、次の表に示すCitrix仮想化システムの5つのコンポーネントにどのテクノロジーが使用されているかにあります。クラウドフォワードデザインパターンでは、次の5つのコンポーネントすべてにクラウドサービスが使用されます。
| セッションの仲介と管理 | Citrix DaaS-(DaaS) (クラウドサービス) |
|---|---|
| ユーザーインターフェイス (UI) サービス | Citrix Workspace サービス（クラウドサービス） |
| 認証 | Citrix Workspace サービス、IdPとしてActive Directory を |
| HDXセッションプロキシ | NetScaler Gateway Service（クラウドサービス） |
| 分析 | Citrix Analytics サービス（クラウドサービス） |
クラウドフォワードデザインパターンは、同じ Active Directory（またはしない）を使用して、異なる Google Cloudリージョンで複製できます。これにより、このパターンは、地理的に分散したアプリケーションやデータを使用した展開に役立ちます。このパターンは、本番環境での展開では、多くの場合、GCP のリソースの場所を、 Google Cloud VPN、Google CloudInterconnect、 またはCitrix のSD-WANなどの専用製品を使用して顧客が管理するデータセンターに接続することによって拡張されます。このようなプライベートネットワーク接続を使用すると、キーサービス（Microsoft Active Directory など）を Google Cloudに拡張できます。これにより、まだ移行されていないアプリケーションやリソースにVDAにアクセスできます。また、アプリやデータを Google Cloud に移行するためのコンジットとしても機能します。前の図には示されていませんが、 Citrix Workspace Environment Management サービスは 、特にシステムが本番環境に移行するときに一般的に使用されます。Workspace Environment Management サービスは、インテリジェントなリソース管理およびProfile Managementテクノロジを使用して、Citrix Virtual Apps and Desktopsの展開において、可能な限り最高のパフォーマンス、デスクトップログオン、およびアプリケーション応答時間を提供します。詳細については、このガイドの後半の「 ユーザー環境/設定管理 」を参照してください。
ハイブリッドデザインパターン
以前は、ハイブリッドデザインパターンも紹介しました。クラウドフォワードパターンのバリエーションであるハイブリッドデザインパターンは、UIサービス、認証、HDXプロキシ機能を提供するために、エンタープライズで実績のあるCitrixアクセスレイヤーテクノロジを顧客管理で導入します。これらのオプションにより、仮想化システムはより複雑なユースケースに対応できます。その多くは、クラウドへの移行を開始したばかりの企業で一般的です。
Citrix仮想化システムの5つのコンポーネントのコンテキストにハイブリッドデザインパターンを配置するには：
| 仮想化システム機能: | 提供者: |
|---|---|
| セッションの仲介と管理 | Citrix DaaS (クラウドサービス) |
| ユーザーインターフェイス (UI) サービス | Citrix Workspace サービス（クラウドサービス）またはCitrix StoreFront（カスタマー管理） |
| 認証 | NetScaler ADC/Gateway（顧客管理）の導入により、Citrix Workspaceサービス（クラウドサービス）またはCitrix StoreFront で使用できる多くの組み合わせ |
| HDXセッションプロキシ | NetScaler Gateway Service（クラウドサービス）またはNetScaler ADC/Gateway（顧客管理） |
| 分析 | Citrix Analytics サービス（クラウドサービス） |
以前は、NetScaler ADC/GatewayとCitrix StoreFront の導入は、Googleクラウド上のCitrixの仮想化システムに導入することが有用であるときのハイポイントを与えました:
-
NetScaler ADC/Gateway（❷）：GCPに仮想アプライアンスとして展開されるこのコンポーネントは、次の1つ以上を必要とするユースケースによく使用されます。
- SAML/OAUTH 2/OpenID フェデレーション、RADIUS、スマートカード、条件付きアクセス要件など、高度な認証シナリオ。
- パブリックネットワーク上のエンドユーザーデバイスに対して、高度に最適化された柔軟なセッションアクセス。
- コンテンツスイッチング、Web アプリケーションファイアウォール、統合 Web キャッシング、攻撃の軽減、アプリケーション負荷分散、SSL オフロードなどの高度なネットワークサービス
- 高度で柔軟性が高く、コンテキストに応じたポリシーに基づいて、特定のユーザー/デバイスを特定の「ストア」に誘導できます。ポリシーの決定は、ユーザープロファイルの属性、場所、デバイスタイプ、デバイスの健全性、認証結果などに基づいて決定できます。
-
Citrix StoreFront（❸）：Citrix Workspace サービスの前身であるStoreFrontは、Citrix のUIサービスの「クラシック」プロバイダーです。StoreFront は、顧客管理型のWindows Serverインスタンスにインストールされ、多くの場合、以下の1つ以上を必要とするユースケースで使用されます。
- インターネットおよびクラウドサービスの停止に耐えることができる、極めて高い可用性。
- 柔軟なセッションルーティング。Citrix Gateways経由で外部ユーザーを送信しながら、内部ユーザーセッショントラフィックを直接VDAにルーティングする機能を備えています。
- カスタマー管理型のオンプレミスデバイスからのシングルサインオン。
- 同じシステム上で多様なユースケースをサポートするために、異なる構成プロパティを持つ複数の「ストア」を提供する必要があります。
- 高度にカスタマイズされた、またはブランド化された HTML ベースのユーザーインターフェイスの必要性。
これらは高いポイントです。クラウドサービスか顧客管理コンポーネントを選択する前に、他の多くの機能項目も考慮する必要があります。以降のセクションでは、GCP上のNetScaler ADC/GatewayおよびCitrix StoreFront について詳しく説明します。各レイヤーでさまざまなテクノロジの組み合わせを使用して、特定の成果を達成したり、特定のニーズを満たすことができます。
たとえば、NetScaler ADC/Gateway VPXアプライアンスをシステムに追加して、Citrix Workspacefor UIサービスを使用して認証またはHDXプロキシ機能に使用できます。これにより、システムはほぼすべてのIDおよび認証戦略 (フェデレーションシナリオを含む) をサポートし、 HDXのEnlightened Data Transportを使用して 、最適ではないネットワーク上で最高のセッションパフォーマンスを実現できます。
また、Citrix Workspaceと並行して、またはCitrix Workspaceの代わりにUIサービスに使用するCitrix StoreFront を導入することもできます。StoreFront では、ほとんどのユースケースでNetScaler ADC/Gatewayが必要ですが、この組み合わせは、極端な高可用性要件、高度なUIカスタマイズ要件、およびユーザーグループ、デバイスのプロパティごとに異なるプロパティを持つ複数の異なる「ストア」を作成する機能を備えたユースケースに対応します、物理的な場所など。
クラウド移行の設計パターン
クラウド移行の設計パターンは、お客様が従来のCitrix仮想化システムとCitrix CloudをGCP上で並行して実行できるように設計されています。UIサービス（Citrix WorkspaceサービスとCitrix StoreFront）を提供するどちらのオプションでも、レガシー環境とCitrix Cloudのリソースを単一のユーザーインターフェイスに集約できます。これにより、リソースの起動元に関係なく、一貫したアクセスエクスペリエンスがユーザーに提供されます。
一般的な例の1つは、既存のCitrixのお客様で、Citrix Virtual Apps and Desktopsの顧客が管理するCitrix Virtual AppsとDesktopsの導入に多大な投資をしており、GCP上でアプリケーションとデスクトップワークロードの実行を開始したいと考えています。おそらく、現在オンプレミスで管理している複数の「Citrixファーム」もあります。お客様は、認証、UIサービス、およびHDXプロキシサービスを提供するために、Citrix StoreFront およびおそらくNetScaler ADC/Gatewayアプライアンスを展開しています。
このシナリオでは、顧客は、複数のCitrixファームから1つのUIにアプリとデスクトップを集約するStoreFrontの機能を使用している可能性があります。Google Cloudに「移動」するには、選択したリージョンにCitrix Cloudリソースの場所を作成することから始めます。すべてが同じネットワーク上にあると仮定すると、StoreFront に新しい「Citrixファーム」を追加し、最初の仮想化ワークロードをGoogle Cloudに展開できます。これにより、Citrixワークロードを2つの環境（オンプレミス、一部はGCP上）で並んで実行でき、ビジネスの優先順位に応じてワークロードをGCPに移行できます。
この同じ顧客は、StoreFrontと並行してCitrix Workspace を実行し、Citrix Cloudサイト集約機能を使用して従来の 「Citrixファーム」をワークスペースUIに追加することもできます。両方の UI は、同じユーザーに同じリソースへのアクセスを提供します。ビジネス上の優先度が許すように、エンドユーザーは、Citrix WorkspaceサービスのUIに徐々に移行できます。
クラウド移行アプローチの利点は、IT 部門が従来のオンプレミスインフラストラクチャから Google Cloud にアプリケーションとデスクトップのワークロードを適切なペースで移行できることです。ユーザーは、ワークロードがオンプレミスか Google Cloud から配信されているかにかかわらず、同じ方法でアプリケーションとデスクトップに引き続きアクセスできます。
サイトアグリゲーションを使用すると、お客様はCitrix Analytics を使用して、オンプレミスとクラウドでホストされるインフラストラクチャの両方のセキュリティ、パフォーマンス、および運用に関する洞察を得ることができます。これにより、ワークロードをオンプレミスから Google Cloud Platform に移行する必要がある時期の意思決定プロセスに役立ちます。Citrix Security Analyticsを使用すると、ワークロードがオンプレミスのインフラストラクチャとGoogle Cloudに分散されるにつれて、お客様のセキュリティ体制を強化できます。
Google VMware エンジンを使用した移行
クラウド移行の設計パターンを検討している場合は、おそらくVMware でCitrixを実行している可能性があります。お客様によっては、既存のVMware ベースのインフラストラクチャを Google Cloud に拡張するオプションも魅力的です。このようなお客様にとって、このパスにより、既存の知識とプロセスへの投資を活用して、ワークロードの移行を迅速化することが約束されます。 Google Cloud VMware Engineを使用すると、お客様は Google Cloud 上で VMware Cloud Foundation (VCF) ベースのソフトウェア定義データセンター (SDDC) をプロビジョニングして実行できます。
Citrixの仮想アプリとデスクトップサービスにより、VMware VCFベースのパブリッククラウドでのVDAのプロビジョニングとイメージ管理が可能になります。発売前に、Google Cloud VMware Engineは包括的な互換性テストを受け、 Citrix Ready Verifiedになりました。Citrix Provisioningプラットフォーム（MCSおよびPVS）は両方ともテストされ、期待どおりに機能しました。詳細については、「 Citrix Ready 上の Google Cloud VMware エンジン」を参照してください。
お客様が Google VMware Engine を使用して VCF ベースの SDDC をスピンアップすると、SDDC（コンピューティング、ストレージ、ネットワーク、および管理を含む）が Google コンピュートエンジン上の VPC ネットワークにピア接続されます。これにより、SDDC または Google コンピュートエンジンでワークロードを実行し、さまざまなワークロードのオプションを顧客に提供できます。次の論理図は、Google Cloud、Citrix Cloud、マネージド SDDC インスタンスの関係を示しています。
注：
Citrix App Layering またはPVSサポートを完全にする要件をお持ちのお客様は、Citrix Cloudリソースの場所をGoogle Cloud VMware エンジンで実行することを検討する必要があります。現在、VMwareベースのプラットフォームでは、Citrix App Layering PVSの両方が利用可能です。
Google VMware EngineでのCitrix仮想化ソリューションの設計および実装は、この設計ガイドの対象外ですが、このガイドで説明されている概念とコンポーネントのほとんどが適用されます。VMware（クラウドファンデーション）でのCitrix Cloud リソースロケーションの設定に関する詳細については、 Citrix DaaSドキュメントを参照してください。
まとめ
ご覧のとおり、これらのパターンは、既存のCitrixのお客様に最大限の柔軟性を提供し、お客様の条件に応じてクラウドに移行することができます。1つの規範的なアプローチはありません。代わりに、Citrixのお客様は、自社のビジネスに最適なソリューションと移行アプローチを設計できます。これをサポートするために、Citrix Cloudライセンスを購入されたお客様には、ハイブリッド使用権も付与されます。また、多くのお客様には、Citrixカスタマーサクセスマネージャーが割り当てられ、そのプロセスを案内しています。詳細については、Citrix 営業担当にお問い合わせください。
Google CloudでのCitrix仮想化のデザインパターンのコンテキストで、いくつかのレイヤーを剥がしました。それでは、さらにいくつかのトピックについて詳しく説明しましょう。
VDAの設計と管理に関する考慮事項
Citrix仮想化システムの最も動的な部分はVDAです。VDAは、実際の作業が行われる場所（Citrix仮想化システム上でユーザーに提供するアプリとデスクトップは、GCP上のVMインスタンスから実行されます）であることを覚えておいてください。あなたはこのレイヤーを正しく取得することを確認したいが、完璧が進歩の邪魔にならないでください！宿題を前もってやれ。システムが時間の経過とともに変化するという期待をユーザーに設定。… そして、変更を処理するためのシンプルで効果的なプロセスを構築する：それは避けられません！Citrix仮想化テクノロジのパワーと柔軟性により、変更の管理は大きな負担になる必要はありません。
このセクションでは、コンテキストを失うことなく深く潜ることができるように、トピックを論理的に分割しようとしました。私たちは、各セクションに必要な詳細を提供し、その途中で主要なプラクティスと推奨事項を呼び出せるよう最善を尽くしています。
まず、アプリとデスクトップのミックスを配信するためのさまざまなVDA関連オプションを調べることから始めて、かなりの数があります！次に、Citrix CloudのVDAフリートとイメージ管理テクノロジー（MCSや自動スケール機能を含む）を構成して使用する方法について説明します。次に、ユーザー環境管理 (レジストリ設定、ドライブ/プリンタのマッピングなど) とユーザー設定管理 (ユーザープロファイル、個人用設定レイヤー、ホームドライブなど) のオプションを紹介し、コスト最適化と容量管理について詳しく説明し、パフォーマンスの調整によりセクションをまとめて説明します。考慮事項。
これは野心的な知識の量です-それを後にしましょう！
ワークロード配信のオプションと考慮事項
ワークロードデリバリを開始する際には、適切な足で始めることが重要です。これは、最初に考慮する必要があるVDA以外の要素に触れることを意味します。優れたCitrixコンサルタントが新規顧客と最も重要な会話の1つは、サービスするユースケースに関するものです。これらの会話（顧客のニーズ、ビジネスの気候、テクノロジーが時間の経過とともに進化するため、複数のもの）は、通常、合理的に明確に定義されたユーザーとアプリのグループの定義につながります。これらのグループを「デリバリーグループ」と呼びます。このセクションで説明するオプションのほとんどは、デリバリーグループとユースケースごとに再評価されます。通常、顧客にはかなりのバリエーションがあり、デリバリーグループ間で重複することさえあります。ただし、一日の終わりには、各デリバリーグループの最も基本的な要素は、提供されるアプリケーション、データ、サービスの組み合わせです。定義が完了したら、このセクションで説明した決定の評価を開始できます。
重要：
ユースケース/デリバリーグループごとに、必要なアプリ、データ、サービスの組み合わせを定義してから、次の考慮事項に従って、それぞれに最適な配信オプションを決定します。
ヒント：
VDAは、 マシンカタログと呼ばれるリソースグループで管理されます。マシンカタログは、仮想マシンインスタンスのグループで、ユーザーグループの一般的なユースケースとして機能します。通常、同じ「ゴールデンマスター」仮想マシンインスタンステンプレートに基づいており、VM インスタンスプロパティと通常ディスクの一般化されたコピーを継承します。
VDAオペレーティングシステム
WindowsかLinux
各デリバリーグループ/ユースケースに必要なアプリ、データ、サービスを定義しました。次に、VDAに最も適したオペレーティングシステムについて検討します。最も基本的な質問：WindowsかLinuxが必要ですか？多くの場合、この決定は、提供しているアプリケーションまたは一連のアプリケーションの要件によって強制されます。アプリがWindowsでのみ実行されている場合は、Windowsです！アプリがLinuxでのみ実行されている場合は、明らかに同じことが当てはまります。
ビジネスアプリケーションは多くの場合、Windows上に構築されるため、Citrix仮想アプリの大部分が、GCP上のWindowsベースの仮想マシンインスタンス上で実行されます。Windows が選択されるのは、IT チームが知っていることであり、Linux のような新しい OS で運用コンピテンシーをスピンアップするコストが高すぎると見なされるため、アプリケーションセットを Linux で実行できる場合でも Windows が使用されます。ただし、アプリケーションセットを Linux で実行できる場合は、考慮する価値があります。複雑さとコストの大部分 (Windows OS とクライアントライセンス) を避けることができます。
サーバOSかデスクトップOSか
Linux を OS として使用できる場合、「サーバーまたはデスクトップ」の選択は比較的簡単です。GUIを備え、 Google Cloudで実行でき、 Citrix Linux VDAでサポートされているバージョンを選択する必要があります。
Windows を展開すると、サーバーOSとデスクトップOSの選択が少し複雑になります。どちらのオプションも共通の GUI を共有し、どちらもユーザーに仮想デスクトップを提示できます。実際、ほとんどの Windows アプリケーションは Windows Server と Windows 10 デスクトップオペレーティングシステムの両方で実行されますが、多くの場合、アプリケーションベンダーはドキュメントで Windows Server のサポートを呼び出しません。Windowsサーバーの最も大きな意味合いとWindows 10デスクトップはライセンスを取得しています-それは大きなものです。
パブリッククラウドで Windows 10 (またはその他の「デスクトップ」オペレーティングシステム) を実行する場合は、Microsoft のライセンスポリシーが制限されます。これらのポリシーベースの制限により、GCP を含むパブリッククラウドで Windows デスクトップOSを実行するコストが高くなります。Microsoft のライセンスポリシーの詳細については、Microsoft ライセンススペシャリストにご相談ください。ただし、この複雑なトピックについては、以下を参考にしてください。
- Microsoft ボリュームライセンス製品条項 (2020 年 4 月 1 日) -Windows クライアント、Windows Server、および Windows サービスを対象としています。
- Microsoft Office ライセンスページ - ライセンス概要を入手してください。
GCP で Windows を実行している場合、Windows Server はほとんどのユースケースとアプリケーションのミックスを提供し、インスタンスの使用量とともにライセンス使用量に対して支払うだけです。多くの場合、Windows デスクトップよりも費用対効果が高く、Google Cloud 上の多くの仮想化システムの選択肢となります。
共有OS（マルチユーザー）またはシングルユーザー（「VDI」）
よくある誤解の 1 つは、複数のユーザー間で OS を共有しているか、ユーザーごとに 1 つの OS/VM インスタンスがあるかにかかわらず、Windows Server がデスクトップユースケースに対応できないことです。この誤解は偽りだ！マルチユーザーモード (つまり、RDSH 役割がインストールされている) に展開すると、Windows Server は「ホストされた共有」デスクトップをユーザーに提示できます。Windows Server は「VDI」ユースケースにも使用できます。マルチユーザー/共有OSオプションほど費用対効果が高くスケーラブルではありませんが、シングルユーザーのデスクトップには正当な選択肢です。このデリバリモデルを「サーバーVDI」と呼んでいます。
要約すると、ユースケースに応じて、以下のオプション/オペレーティングシステムの組み合わせを使用できます。
| デリバリモデル | シングルユーザーまたはマルチユーザー | 共通の OS バージョン/コンポーネント | Google Cloudで実行するための相対コスト |
|---|---|---|---|
| ホストされた共有 | マルチユーザー | Windows Server (2016 または 2019)、RDSH の役割とデスクトップエクスペリエンスが有効になっています。 | ⭐ |
| サーバーVDI | シングルユーザー | Windows サーバー (2016 または 2019)、デスクトップエクスペリエンスが有効になっています。 | ⭐⭐⭐ |
| デスクトップVDI | シングルユーザー | Windows 10 (BYOライセンスとSTNが必要) | ⭐⭐⭐⭐⭐ |
もう 1 つの一般的な誤解は、Google Cloud のソールテナントノード（STN）が「デスクトップ」ユースケースを提供する必要があることです。唯一のテナントノードは、Windows 10 (デスクトップ) OS などのMicrosoft の BYO ライセンスシナリオに準拠する必要があります。前述のように、Windows Server は、マルチユーザーデスクトップ (Hosted Shared) に加えて、シングルユーザーデスクトップ (「Server VDI」) を提供するために使用できます。独自の Windows Server ライセンスを取得する場合は、単独のテナントノードを Windows Server インスタンスに使用することもできます。
Linux のほとんどのフレーバーは、マルチユーザー対応です。そのため、ホスト共有モデルまたは「サーバーVDI」モデルのいずれかに展開でき、コストも同様です。
注：
意思決定プロセスを支援するために、次のDecision Treeでは、 ホストされた共有デスクトップ (サーバーOSマルチユーザーデスクトップ) とVDIデスクトップを比較しています。このツリーでは、クライアント VDI モデルとサーバーの VDI モデルを明示的に区別しませんが、提示された決定は両方に対して有効です。ユースケースから VDI がワークロードに適した配信モデルであると示唆された場合、Google Cloud 上で実行するために可能な限りサーバー VDI を考慮する必要があります。
公開デスクトップか公開アプリですか
1日の終わりに、Citrix仮想化システムでユーザーに配信する仮想アプリは、VDA上で実行されます。これらの表示方法に関するオプションがあり、これによってユーザーがそのユーザーと対話する方法が決まります。個々のアプリケーションやファイルをユーザーに提示したり、「公開」したりできます。また、アプリケーションおよびデータを操作するデスクトップでそれらを表示することもできます。
例：Windows向けCitrix Workspaceアプリでウィンドウアプリとして表示される、ホストされた共有デスクトップ。
この選択肢にはさらに多くのものがあります（そして多くのお客様が両方を使用しています）。しかし、以下に要約する試みを示します。
公開デスクトップ （ホスト共有と VDI の両方）:
| + | システム上のアプリやデータを操作するための使い慣れたメタファーをユーザーに提供します。ユーザーにとってより簡単に把握し、生産性を高めることができます。多くのアプリケーションで柔軟な環境を提供するのに最適です。 |
| - | ユーザーは、デスクトップ上で行うように動作することを期待しています。セキュリティとアクセスと機能のバランスをとるために懸命に取り組んでおり、Windows デスクトップを管理しています。ユーザープロファイル、アプリケーション設定、データストレージ、デスクトップ構成の管理が重要になります。ユーザーがリージョン間で設定をローミングすると予想される場合は、二重になります。 |
| - | より多くの仮想マシンインスタンスリソースを必要とする-Windows デスクトップサービスは、公開アプリよりもユーザーごとに多くのリソースを消費します。 |
公開アプリケーション:
| + | 公開アプリは、多くの場合、セキュリティ保護が容易で、配信に必要なリソースが少なくて済みます。また、ユーザーエクスペリエンスがよりシンプルになります。Citrix では、この「シームレスなウィンドウ」と呼んでいます。 |
| - | 公開アプリの数が多いと、ユーザーエクスペリエンスが複雑になる可能性があります。 |
| + | それでもユーザープロファイル、アプリケーション設定、データストレージの管理が必要ですが、多くの場合、公開デスクトップに比べて、よりシンプルかつ柔軟に実行することができます。 |
| + | 必要な仮想マシンインスタンスリソースの削減とWindows デスクトッププレゼンテーション。複数の公開アプリは通常、同じセッション内で実行されます。この機能は、Citrixがセッション共有を呼び出します。 |
プールされたか永続的
この選択肢は、マシンカタログの別のプロパティであり、カタログの作成時に定義されます。ホスト共有デリバリーモデルでは、通常、プールされたVDA/非永続VDAを使用しますが、どちらのVDIモデルでもプールされたマシンカタログまたは永続的なマシンカタログを使用できます。プールされたモデルでは、VDAのログオフまたは再起動時にOSインスタンスがMCSによってリセットされます。このモデルにより、ユーザーは「クリーン」なシステムイメージを取得できます。システムイメージは、テンプレートまたは「ゴールデンイメージ」仮想マシンインスタンスとその通常ディスクのスナップショットに基づきます。VDAのプールが維持され、ユーザーはプール内の利用可能/未使用のVDAに動的に接続されるため、「プール」と呼ばれます。ユーザー設定およびデータは、いくつかの異なる方法で管理できます。プールされたVDAでは、ログインしているVDAに関係なく、ユーザーが同じ構成とエクスペリエンスを取得するように処理されます。このトピックの詳細については、このドキュメントの「ユーザー環境/設定管理」を参照してください。
永続マシンカタログには、個々のユーザーに割り当てられたVDAインスタンスが含まれており、再起動後も保持されます。このモデルは、ユーザーが独自のアプリケーション（開発者環境など）をインストールする必要があるシナリオ、および必要なアプリケーションがマルチユーザー互換でないユースケースに役立ちます。
CitrixのMCSでは、プールされたインスタンスに接続されたシステムディスクを数回のクリックで更新できるため、プールされたインスタンスは長期的に管理しやすくなる傾向があります。また、アイドル状態のインスタンスプールは多くのユーザーにサービスを提供できるため、キャパシティとコストの管理も効率的です。プールされたインスタンスへの変更は、通常、再起動後も保持されないため、プールされたインスタンスは専用インスタンスよりも少し柔軟性が低くなります。 Citrix User Personalization Layerなどのテクノロジーを使用して 、プールされた異なるVDA上のセッション間でユーザーが開始した変更を保持できます。ただし、単一ユーザーの「VDI」ユースケースとのみ互換性があります。
永続インスタンスは、VM 内でOS/アプリケーションのパッチ適用、アップグレード、メンテナンスを処理する必要があるため、導入が簡単になりますが、長期間にわたって管理が厳しくなります。また、多くの場合、ユーザーがログオンするタイミングを予測するのは難しいため、コスト/容量の観点からはより高価になる可能性があります。つまり、ユーザーはインスタンスの起動を待たなければなりません。または、管理者は各ユーザーがログオンすることが予想されるタイムウィンドウの間も、そのインスタンスを実行し続ける必要があります。
管理されているか非管理ですか
MCSによって作成および管理されるカタログには、テンプレート（または「ゴールデンマスター」）VMインスタンスの永続クローンまたは非永続クローンを含めることができます。マシンカタログは、別のプロセスまたはテクノロジを使用してプロビジョニングすることもできます。どちらの方法でも、電源管理として作成されていることを確認する必要があります。
電源管理されたマシンカタログを使用しない場合、Citrix Autocaleなどの主要な機能は機能せず、コストと容量を管理することはできません。VDAフリートのプロビジョニングと管理にMCSを使用すると、管理者には多くの便利なメリットがもたらされますが、Citrixの外部にプロビジョニングされた「管理されていない」VDAも使用できます。 フリートとイメージ管理のこれらの利点については 、このガイドの後半で説明します。
GPUアクセラレーション
VDAにデプロイされた特定の種類のアプリケーションは、仮想マシンインスタンスで使用可能であれば、GPUリソースの恩恵を受けることができます。3 つのデリバリーモデル（Linux と Windows の両方で、ホスト型共有、サーバー VDI、デスクトップ VDI）はすべて、 Google Cloud のグラフィックワークロードに NVIDIA アクセラレーション GPU インスタンスを使用できます。これらの仮想ワークステーションGPUは、3Dビジュアライゼーション、チップ設計、CAD/CAM、グラフィックス、ビデオ編集など、グラフィックス負荷の高いワークロード向けの汎用N1マシンに接続でき、必要なGRIDライセンスを含めることができます。
インスタンスに適切なNVIDIA GRIDドライバがインストールされている場合、CitrixのVDAソフトウェアはGPUの存在を検出し、適切に構成します。
ヒント：
CitrixのHDXディスプレイプロトコルスタックは、可能な限り最高のユーザーエクスペリエンスを提供するために、その場で多くの自動検出と適応を行います。ただし、UX のパフォーマンス、応答性、豊かさと、帯域幅の消費量のバランスを取ろうとします。そのため、グラフィックス負荷の高いワークロードは、バランスを正しく得るために微調整によってメリットを得られることがよくあります。詳細については、「 HDXグラフィックの概要 」を参照してください。Citrix は、「超高精細ユーザーエクスペリエンス」と呼ばれるポリシーテンプレートを提供しています（「 ベースラインポリシー設計」を参照）。このテンプレートは、特定の環境に合わせて微調整するための開始点として使用できます。
フリートとイメージ管理
Google CloudでのCitrixの仮想化には、VDAのプロビジョニングとイメージ管理を大規模に簡素化するために設計された機能が組み込まれています。これらの機能は、しばしば「マシン作成サービス」、略してMCSと呼ばれます。MCSは、Googleクラウド上のIAMサービスアカウントを使用して、GCPでのVDAの管理を容易にします。
ヒント：
GCPでMCSを設定して使用する前に、 Google Cloud Platform仮想化環境でのMCSの設定と使用に関するCitrixドキュメントを確認してください。このドキュメントでは、Google Cloud API の有効化、IAM サービスアカウントの作成と設定、ホスティング接続とリソースの作成などについて説明します。
MCS の問題と制限事項
MCSには、今日のGCPにCitrix仮想化システムを導入する前に知っておく必要がある重要な制限がいくつかあります。MCS フィーチャセットはクラウドサービスとして提供されるため、サービスの進化に伴い、この一覧は時間の経過とともに変化すると予想されます。暫定的に、あなたはそれに応じて設計および実行計画を調整できるように、それらについて知る必要があります。
現在の既知の問題/制限は次のとおりです。
- Linux VDAのプロビジョニング。GCP上のMCSは、Linux VDAのプロビジョニングについて完全にテストされていないため、このオプションは現在サポートされていません。Google Cloud上でLinuxのVDAを実行しても、GPUが接続されていると、です。この問題を回避するには、Google Deployment Managerテンプレートまたは別のメカニズムを使用して、MCSの外部でLinux VMインスタンスをプロビジョニングし、割り当てと電源管理のために事前にプロビジョニングされたインスタンスを電源管理されたマシンカタログに追加します。
オンプレミスからのVDAイメージのインポート
カスタムVDAイメージは、多くのお客様がすでに持っていて、GCPで使用したいものです。新しいインスタンスをデプロイし、それをゼロから設定することが望ましいですが、実現できない場合があります。たとえば、アプリケーション所有者またはアプリケーションの依存関係は知られていないが、重要なビジネス運用のために依存しているオンプレミスで構成されたベースイメージが存在する可能性があります。幸い、GCP では、オンプレミスイメージを GCP にインポートできます。Windows クライアントオペレーティングシステムは Google Cloud のイメージカタログでネイティブで利用できないため、Windows クライアント OS バリアント (Windows 10) を展開する場合にもインポートが必要です。詳細については、「 仮想ディスクのインポート」を参照してください。
注：
既存のディスクをインポートする前に、 オンプレミス環境から仮想ディスクをインポートする場合の違いを必ず読んで理解してください 。可能であれば、パブリックイメージライブラリから新しいインスタンスをデプロイし、マスターイメージを最初から作成することをお勧めします。
GCP でのソールテナントノードの使用
Google Cloudには単一テナントノードと呼ばれる機能があり、 Windows OS用の独自のライセンスの持ち込み、GCPへのWindowsクライアントVDAの展開など、さまざまなユースケースに役立ちます。ソールテナントノードを構成する場合、GCP リージョン内の 1 つ以上のゾーンでそれらのノードを構成できます。Citrix MCSは、ソールテナントノードでのVDAのプロビジョニングを完全にサポートしますが、ソールテナントノードがデプロイされているGCPゾーンは自動的に認識されません。VDAを単一テナントノードに展開する場合は、 GCPゾーンの選択ドキュメントで詳細を確認してください 。
注：
GCP に Windows 10 をデプロイするための優れたチュートリアルについては、「 オプションの共有 VPC カタログ作成を含む GCP Windows 10 唯一のテナント POC ガイド」を参照してください。この記事では、カスタムイメージのインポートと GCP でのソールテナントノードの使用方法の両方について説明します。
コスト最適化と容量管理
Google Cloud でVDAを実行する場合、使用するコンピューティング、ストレージ、ネットワークリソースに対して料金を支払うことになります。つまり、消費する容量と発生するコストには直接的な相関関係があります。お客様が行う選択と採用するプラクティスは、仮想化システムの運用コストに直接相関関係があります。
まず、 適切なワークロードデリバリーオプション 、つまりこれを最初から最後まで読んでいる場合に読んだトピックを選択してください。これらのソリューションは、ソリューションの総コストに大きな影響を与える可能性があります。ここでは、コストと容量とのバランスを取って、ユーザーエクスペリエンスを最適化するために考慮すべきその他の推奨事項とトピックをいくつか紹介します。
オンデマンドプロビジョニング
MCSを使用してCompute Engineで非永続的なマシンカタログを作成する場合、MCSはオンデマンドプロビジョニングを使用してストレージコストを削減し、カタログの作成を迅速化し、インスタンスの電源操作を高速化します。オンデマンドプロビジョニングでは、Compute Engine インスタンスは Citrix DaaS がパワーオンアクションを開始したときにのみ作成されます。非永続的なマシンカタログでは、オンデマンドプロビジョニングが使用されます。
注：
一部の管理者は、MCSの電源を入れるまでVDAインスタンスがGoogle Cloudコンソールに表示されないため、最初はオンデマンドプロビジョニングが混乱します。また、インスタンスは新しい仮想 NIC と MAC アドレスを受信するため、Active Directory DNS エントリが正常に更新またはレプリケートされるまでには時間がかかる場合があります。VDA IDディスクは、再起動と作成/削除イベントの間も保持されます。
VDAインスタンスの適切なサイジング
ワークロード配信オプションに関する重要な決定事項について理解できたので、VDAインスタンスの適切なサイジングについて詳しく説明しましょう。 VDI ベースのデリバリモデルでは、適切なインスタンスタイプを選択するのは簡単です。いくつかの宿題を終えて、VDI インスタンスの OS、アプリ、ユーザーのリソース要件を十分に理解していれば、これらの要件を、選択した Google Cloud リージョンで使用可能なインスタンスタイプに簡単にマッピングできます 。利用可能なインスタンスタイプとワークロード要件に完全に一致していない場合でも、心配する必要はありません。Google Cloudはカスタムインスタンスタイプをサポートしているため、VDAインスタンスの形状を調整することができます。カスタムインスタンスタイプには、引き続き継続使用割引と継続使用割引が適用されます。したがって、適切なサイズを前面に上げるために必要に応じて調整することを防いでください。
また、Google Cloudの推奨サイズ設定機能を使用して 、時間の経過とともに行う必要があるVDA形状の調整を特定できます。
注：
注意すべき重要な点の1つは、ワークロード・リソースの消費は時間の経過とともに変化する可能性があります。管理者が環境に最適化を適用する場合など、イベントやアクティビティによって、リソース要件が削減されることがあります。逆に、OS やアプリの脆弱性がパッチが適用されたり、更新プログラムが適用された場合など、これらの要件が上がる場合があります。ベースラインを特定しますが、時間の経過に伴う消費傾向を監視し、必要に応じて調整して、ユーザーのパフォーマンスとコストの最適なバランスを見つけることが重要です。
ホストされた共有VDAに適したインスタンスサイズを選択すると、作業が少し複雑になります。最終的に探しているのは、パフォーマンス、コスト、管理性の適切なバランスがとれた移動ターゲットです。物事をさらに複雑にするために、すべてのワークロードは異なります。OS、アプリケーション、設定、チューニング、ユーザーの期待値の違いにより、VDAに適した形状を突き刺すのは困難です。また、時間の経過とともに変化する傾向もあります。
幸いにも、パフォーマンス、コスト、管理性の間で「ゴルディロック」のバランスが取れていることを見つけるためのツールとテクニックは十分に知られており、徹底的に文書化されています。最初に推奨する優れた記事の1つは、 Cloud World 2018エディションのCitrix スケーラビリティです。この記事では、パフォーマンス、管理性、コスト、利用可能な価格モデル、LoginVSI スケーラビリティテストに基づくインスタンス選択に関する主要なプラクティスについて説明するため、今日でも関連性があります。これらの概念と考慮事項は、インスタンスの選択肢と価格が、最初の公開後に変更されている可能性が高いにもかかわらず、今日でも有効です。
言及する価値のある別の記事は、 Google Cloud PlatformでのCitrix の適切なサイジングです。少しは日付がありますが、この記事では、考慮事項をさらに詳しく説明し、単一のVDAのスケーリングとインスタンスコストに基づいて、最も費用対効果の高いインスタンスタイプを見つける方法の例を示します。
最後に、VDAコストを最適化するための戦略に関する追加の洞察については、Citrix TechZoneのこのAutoscale 技術概要を参照してください 。これにより、インスタンスのコスト見積もりを、垂直負荷分散の使用など、 Citrix Autoscale 機能の機能に合わせることができます。
Citrix Autocale（Citrix Autocale）について言えば、それを読んで、それを使用する：少し考えと巧妙な設計により、VDAフリートをコスト最適化しながら、システム需要の予想外の変動に対応できる容量を確保できます。
需要パターンと言えば、各ワークロードの固有のパターンを理解するために、時間とリソースを投資したいと考えています。時間の経過とともに変化し、進化していくことを期待し、キャパシティ管理の戦略と戦術を調整して対応できるように準備してください。
適切な価格モデルの選択
Google Cloud は、 お客様がそこで実行するさまざまなタイプのワークロードに使用できるさまざまな価格モデルを提供しています 。さまざまなユースケースの需要パターンを理解することで、コストとサービスの可用性/パフォーマンスのバランスを取るために、リソースごとに適切なモデルを選択できるようになります。Citrix仮想化システムでは、お客様は一般的に、GCP上で動作するリソースの持続的使用とコミット済み使用割引モデルを考慮します。持続的な使用割引はインスタンスタイプによって異なります（N1 とたとえば、N2) と一部のインスタンスタイプ (E2 など) では、継続的な使用割引が提供されません。詳細については、 VM インスタンスの料金を参照してください 。
以下に、 N1 インスタンスタイプの持続的使用とコミット済み使用の割引を示します。
一部のリソースは、一意で拡張性が高く、Citrix仮想化システムが機能するために利用可能である必要があります。そのため、通常は24時間365日稼働し、N+1を導入して可用性を確保し、コミットされた使用割引の候補として最適です。これには、Active Directory、Citrix Cloud Connector、NetScaler ADC/Gateway VPX、およびCitrix StoreFront 仮想マシンインスタンスが含まれます。
VDAインスタンスの場合、選択肢はそれほど単純ではありませんが、需要パターンをより明確に理解すればするほど、選択肢は明確になります。すべては、VDAの電源をオンにする必要がある時間まで低下します。次のグラフ（ N1 インスタンスタイプに固有）を考えてみましょう。このグラフは、少しエンベロープ数学で再現できます。
この図は、特定の請求サイクル中に（N1 インスタンスタイプで実行されている）リソースが 50% 以上オンになる場合、3 年間の使用割引を適用できれば、コスト削減を開始することを示しています。1年間のコミット使用割引のブレーク偶数ポイントは約 82% です。請求サイクル中にリソースがそれ以上パワーオンされ、3 年間のコミットされた使用が利用できない場合、1 年間のコミットされた使用は理にかなっています。
パフォーマンス・チューニングに関する考慮事項
Citrix仮想化システムでのパフォーマンスの認識には、多くの要因が挙げられます。VDAに適した形状のVMインスタンスの選択に加えて、パフォーマンスの最適化のために調査するその他の重要な領域は次のとおりです。
ユーザー環境および設定管理の選択: ポリシーとは、ユーザーのパフォーマンスを管理および最適化するときの友だちです。ポリシーは、Windows、アプリケーション、セッションなどの構成を制御します。さらに複雑にするために、複数のポリシーエンジンを使用できます。それぞれのポリシーエンジンは、ユーザーエクスペリエンスに独自の影響を与えます。適切なポリシーエンジンを選択し、一貫したベースラインを確立することは重要であり、 幸いにもベースラインポリシー設計で詳しく説明されています。また、 Citrix Workspace Environment Management サービスは 、さまざまな環境でのユーザーエクスペリエンスを最適化し、管理を簡素化するために使用できます。
Windows の最適化: Windows は汎用オペレーティングシステムであり、さまざまなユースケース、ハードウェアの種類などをカバーするように設計されています。Windowsのデフォルト設定の多くは、Citrix仮想化環境では不要です。幸いなことに、 Citrix Optimizer が役立ち、最高のパフォーマンスと全体的なリソース使用率を最小限に抑えるために、VDAに適用できる多くの包括的なテンプレートが含まれています。
ウイルス対策チューニング：Citrix VDAおよびサポートインフラストラクチャでウイルス対策ソフトウェアを実行することは、しっかりとした推奨方法です。しかし、誤ってインストール/構成すると、ユーザーエクスペリエンスに混乱を引き起こす可能性があります。それを正しく行うための優れた入門書については、 エンドポイントセキュリティとウイルス対策のベストプラクティスを参照してください 。
HDXプロトコルの最適化：CitrixのHDXディスプレイプロトコルスタックは、多くの自動検出と適応を即座に実行し、可能な限り最高のユーザーエクスペリエンスを提供します。UX のパフォーマンス、応答性、豊かさと帯域幅消費のバランスを取ろうとします。一部のユースケース (グラフィックス負荷の高いワークロード、低品質/低品質のネットワーク接続など) では、バランスを正しく得るための微調整によるメリットがしばしばあります。詳細については、「 HDXグラフィックの概要 」を参照してください。CitrixのSD-WANは、 HDXユーザーエクスペリエンスの最適化と測定にも役立ちます。
また、Citrixでは、設定を特定のユースケースに柔軟に一致させるために使用できる、あらかじめ構築されたセッションポリシーテンプレートがいくつか用意されています。これらのポリシーは、Citrix Cloud Studio で構成および管理され、さまざまなフィルターを使用して適用できます。これらのフィルターを使用すると、特定のシナリオを最適化するために適切なポリシーが適用されていることを確認できます。
ユーザー環境/設定の管理
ユーザー設定とデータの設計と管理は、Citrix仮想化システムのより複雑で重要な要素の1つです。正しく完了すると、セッションのログオン/ログオフは高速で信頼性が高くなります。アプリはユーザー用に事前に構成されており、ユーザーはログインするVDAに関係なく、一貫性のある予測可能なエクスペリエンスを提供します。間違っていたり、無視されたりすると、ユーザーエクスペリエンスが劇的に苦しむ可能性があります。
幸いなことに、ユーザー環境と設定管理の決定は、VDAが展開されているプラットフォームに関係なく、Citrix仮想化システム全体で共通です。彼らはまた、徹底的に文書化されています。これらの決定は、ユーザーの場所、エンドユーザーの接続、セキュリティ要件に大きく依存します。そのため、ここではこのトピックについて詳しく説明しませんが、いくつかの参考文献から始めます。お客様固有のニーズに合わせてカスタマイズできる多くのオプションがあります。
以下に、開始するためのいくつかのリンクを示します。
| Workspace Environment Managementサービス | Workspace Environment Management サービスでは、インテリジェントなリソース管理とProfile Managementテクノロジを使用して、Citrix Virtual Apps and Desktops展開環境で可能な限り最高のパフォーマンス、デスクトップログオン、アプリケーションの応答時間を提供します。 |
| ベースラインポリシー設計 | この記事では、Citrixポリシーを使用する際に行われるさまざまなポリシーに関する決定について説明します。 |
| Profile Management | Profile Managementに関するベストプラクティスを概説した記事。 |
| 展開計画 | Citrix仮想化システムにおけるProfile Managementの計画に役立つ優れたリソースです。 |
| Citrixユーザーのパーソナライゼーションレイヤー | VDIの使用例（シングルユーザー、シングルOSインスタンス）では、Citrixのユーザーパーソナライゼーションレイヤーテクノロジを使用して、システム管理を大幅に簡素化できます。Citrix UPLを使用すると、管理者はプール/非永続的なマシンカタログを使用しながら、VDAインスタンス全体で一貫したパーソナライズされたユーザーエクスペリエンスをユーザーに提供できます。ユーザーレイヤーは、Windows ファイル共有上の仮想ハードディスクファイルとして保持されます。ログオン時にVDAにマウントされ、ユーザーがインストールしたアプリケーションを含む、セッション内のユーザー変更を取得します。ユーザーレイヤーはログオン時にVDAにマウントされ、ログオフ時にデタッチされます。 |
ファイルストレージとデータレプリケーション
GCP上のほとんどのCitrix仮想化システムでは、ユーザー設定、ユーザーデータ、およびアプリケーションデータを永続化するために、少なくともWindows互換ファイル共有への基本的なアクセスが必要です。Windowsファイル共有は、 Citrix ユーザー個人設定レイヤーの保存にも使用されます。これらの共有を使用できない場合、ユーザーエクスペリエンスとアプリケーション機能が損なわれます。提供するソリューションが何であれ、Windows互換のファイル共有の高可用性を確保し、データを定期的にバックアップすることが重要です。
マルチサイト導入では、可用性、RPO、RTO（目標復旧時点）のニーズを満たすために、信頼性とパフォーマンスの高いデータ・レプリケーションも必要になる場合があります。これは、ユーザーが 2 つ以上のリージョンのデスクトップ/アプリに接続でき、アプリケーション/デスクトップが実行されるリージョンでアプリケーションデータ/ユーザー設定を使用できるようにする必要がある環境に特に当てはまります。次のセクションでは、GCP でファイルストレージおよびデータ複製サービスを提供するために考慮すべきいくつかのソリューションについて説明します。
Windows ファイル共有を提供する Windows 以外のソリューションは存在しますが、これらのソリューションのほとんどは、Windows デスクトップ内の検索機能や Windows で実行されている Microsoft Outlook などのアプリケーションに必要なインデックス作成機能を提供できません。そのため、ほとんどのお客様は、少なくともユーザープロファイルと永続的なアプリケーションデータを格納するために、Windowsベースのファイルサーバソリューションに目を向けています。幸いにも、GCP上でCitrix仮想化システムを実行する場合、カスタマーマネージドとクラウドサービスの両方のオプションを使用できます。
カスタマー管理:Google コンピューティングエンジン上の Windows ファイルサーバー
多くのお客様が GCP で Windows 互換のファイルサービスを提供するために検討している最初のソリューションは、コンピューティングエンジン上に独自の Windows ファイルサーバーを構築して GCP 上の各リソースの場所を提供することです。Windows ファイルサーバは、さまざまな種類のアプリケーションやワークロードで必要とされているため、多くのITショップでは、自社の構築と管理に活用できます。これは、その方法がわかっているためです。最も基本的なレベルでは、お客様は 1 つ以上の Windows インスタンスを作成し、通常ディスクをアタッチし、インスタンスを Active Directory に追加して、Windows ファイルサービスの構成を完了します。
このオプションは、ご想像のとおり、最も優れた制御性と柔軟性をお客様に提供します。これは、特定の種類の顧客や特定の垂直企業にとって非常に魅力的ですが、Windows OSからすべてをサイズ変更、拡張、構築、管理、パッチ適用、保護、保守する責任というコストもかかります。このルートを選択しているお客様は、これらのファイル・サーバの高可用性も確保する必要があります。これは、多くの場合、複数のゾーンにあるファイルサーバーを使用し、Windows DFS-N/DFS-R、 Windowsフェールオーバークラスタ、またはストレージスペースを直接使用して実現されます。注意しないと、サポートされていない構成（Microsoftあたり）で終わるのは簡単です。
注：
このオプションを検討しているお客様は、移動プロファイル共有とフォルダーリダイレクト共有に DFS-R と DFS-N を使用することに関する Microsoft のサポートステートメントを確認する必要があります 。
サードパーティ
別の解決策は、 NetApp Cloud Volumes [ONTAPやGCP向けのクラウドボリュームサービスなどのサードパーティソリューションを使用することです](https://cloud.google.com/solutions/partners/netapp-cloud-volumes)。どちらのソリューションでも、ストレージのニーズに応じて使用できる互換性のある SMB 共有を作成できます。独自のWindowsファイル・サーバを管理するのではなく、サードパーティ製のストレージ・ソリューションを使用するメリットがあります。たとえば、ストレージ管理時の管理オーバーヘッドが軽減されます。詳細については、 Compute Engine のファイルサーバーを参照してください 。
Googleクラウド上のNetScaler ADC/Gateway VPX
GCPへのNetScaler ADC/Gatewayの展開は、オンプレミスでの展開とは異なります。ただし、最終的には自分で管理します。幸いにも、GCPにNetScaler ADC/Gatewayを展開することは完全に文書化設計を固めて実装を開始する前に、次のリソースを確認することをお勧めします。
- Citrix DocsのGCP上のNetScaler ADC VPX：サポートされているVPXモデル、GCPリージョン、コンピューターエンジンインスタンスタイプ、およびその他のリソース参照など、GCP上のNetScaler ADC Cの包括的な概要を提供します。
- NetScaler ADC VPX GCPマーケットプレイス展開：GCPマーケットプレイスで利用可能なすべてのCitrix ネットワーク展開ソリューション。CVAD/DaaSを使用したNetScaler Gatewayの導入にも機能的で関連性があります。
- NetScaler ADC GDMテンプレート:NetScaler ADC GDMテンプレート用のGitHubリポジトリです。これは、Google Cloud Platform 上にNetScaler ADC VPXインスタンスを展開するためのNetScaler ADCテンプレートをホストするリポジトリの優れたリファレンスです。
Citrix DocsのGCP上のNetScaler ADC VPXで説明したように 、2つの主要な展開オプションが利用可能です。これには、次の種類のアカウントがあります。
- スタンドアロン：NetScaler ADC/Gatewayの個々のインスタンスは、個別のエンティティとして展開および管理できます。これは、通常、高可用性が要求されない小規模な展開や POC 展開で使用されます。
- 高可用性：これは、本番環境で最も一般的に展開されるモデルです。NetScaler ADC/Gateway VPXインスタンスのペアは、同じゾーン内または同じリージョン内の複数のゾーンにHA構成を使用して展開できます。このオプションについては、このセクションの後半で詳しく説明します。
ベストプラクティス：
GCPにNetScaler ADC/Gatewayアプライアンスを展開する場合は、プレミアム層（リージョン）の外部 IP アドレスを使用することをお勧めします。プレミアム層の外部 IP を使用する場合、ユーザーに最も近いエッジネットワークロケーションでトラフィックが入力および出力されます。トラフィックは、Google のプライベートネットワークを通過して、リソースがデプロイされているリージョンに到達します。これにより、標準層の外部 IP アドレスと比較して、スループット、低レイテンシ、一貫したパフォーマンス（ジッタが低い）が提供されます。詳細については、「Google Cloud ネットワークサービス階層」を参照してください。
ADCスタンドアロン
NetScaler ADC VPXは通常、シングル、デュアル、または複数のNIC展開タイプをサポートしますが、GCPに展開する場合は、各ADCに少なくとも3つのVPCネットワークを使用し、スループットとデータの分離を最適化するために、各VPCにネットワークインターフェイスを備えて使用することをお勧めします。Citrix Virtual Apps and Desktops をサポートするために展開する場合、管理インターフェイス（NSIP）は通常「プライベートCitrixインフラストラクチャサブネット」に接続され、サブネットIP（SNIP）は「プライベートCitrix VDAサブネット」に接続され、NetScaler Gateway 仮想IP（VIP) を「パブリックサブネット」に変更します。次の簡略化された概念図は、この構成を示しています。これは、単一のゾーン内の単一のVPXインスタンスを示しています。この設計パターンは、高可用性構成の場合（おそらく2番目のゾーンで）複製されます。
次の表に、各 NIC の目的と、関連する VPC ネットワークを示します。
| NIC | 目的 | 関連する VPC ネットワーク |
|---|---|---|
| NIC 0 | NSIP（管理トラフィックを処理する） | (❶) 管理ネットワーク |
| NIC 1 | クライアント側のトラフィック（VIP）をサービスする | (❷) パブリックネットワーク |
| NIC 2 | バックエンド・サーバ（SNIP）との通信 | (❸) バックエンドサーバネットワーク |
重要：
3つのNICを搭載したNetScaler ADC VPXインスタンスでは、GCP上で実行する場合、最低4つの仮想CPUが必要です。詳細については、 ネットワークインターフェースの最大数を参照してください 。
ゾーン全体にわたるADCの高可用性
前述のように、これはCitrix仮想化システムの最も一般的な展開モデルです。このモデルは、複数のゾーンにまたがって展開された単一のリージョンで、NetScaler ADC VPXの一対を使用します。高可用性（アクティブ/パッシブ）は、複数の方法で実現できます。GCP HTTPSロードバランサーは、互いに独立して構成されたADCを使用するか、または独立したネットワーク構成（INC）モードで構成されたNetScaler ADC HAを使用して使用できます。後者のオプション/アーキテクチャは、パブリッククラウドの導入に人気があると考えられているので、ここではその点に焦点を当てます。
GCP上のNetScaler ADC/Gateway VPXアーキテクチャには潜在的なバリアントがありますが、次の図は、3つのNINetScaler ADC HAソリューションを示しています。このソリューションは、事前に設定された VPC ネットワークとサブネットを含む Google Deployment Manager テンプレートでデプロイできます 。
Googleデプロイメントマネージャーテンプレートを使用する場合は、NetScaler ADCアプライアンスをデプロイする前に、VPCネットワークを構成する必要があります。3 つの VPC ネットワークは、(❶) 管理ネットワーク、(❷) パブリックネットワーク、(❸) バックエンドサーバーネットワーク、各 VPC ネットワーク内の適切なサブネットで構成する必要があります。
前の図では、各ADCが異なるGateway仮想IP（VIP）を持っていることがわかります。これは、 独立ネットワーク構成 (INC)の特徴です。HA ペアの VPX が異なるゾーンに存在する場合、セカンダリ ADC には INC が必要です。マッピングされた IP アドレス、仮想 LAN、またはネットワークルートを共有できないためです。NSIPとSNIPはこの構成ではADCごとに異なりますが、NetScaler Gateway VIPはIPsetと呼ばれるNetScaler ADC機能、つまりマルチIP仮想サーバーを使用します。この機能は、異なるサブネットのクライアントで同じサーバーセットに接続するために使用できます。IPSet を使用すると、プライベート IP を各プライマリインスタンスおよびセカンダリインスタンスに関連付けることができます。パブリックIPは、ペア内のプライマリADCにマッピングできます。フェールオーバーの場合、パブリック IP マッピングは新しいプライマリに動的に変化します。
リモートノードをADCに追加してINCベースのHAペアを作成する方法の詳細については、 Citrix のドキュメントを参照してください。GoogleクラウドでのADCの一般的なHA展開情報については、「 VPX高可用性ペアをGoogle Cloud Platformに展開する」を参照してください。
Googleクラウド上のCitrix StoreFront
Citrix StoreFront は、UIサービスを提供し、認証戦略でも役割を果たすCitrix仮想化スタックのコンポーネントです。StoreFront は、Citrix Workspaceサービスの顧客管理の前任者と見なされ、10年以上にわたってCitrix仮想化システムのフロントエンドに使用されています。StoreFront は、ダウンロード可能なMSI/EXEとして配信され、1つ以上のWindows Serverインスタンスにインストールされます。StoreFrontサーバーグループを作成すると、複数のStoreStoreFront ontインスタンスが構成（およびオプションでサブスクリプション）データを共有できます。NetScaler ADC/Gatewayアプライアンスなどのサービス対応ロードバランサーによってフロントエンドされた複数のインスタンスを使用して、高可用性サブシステムを作成します。
Citrix StoreFront をGoogleクラウドに展開することは、オンプレミスに展開することと大差ありません。最後に、StoreFront のすべてのコンポーネントを自分で管理することもできます。
Google Cloud上のStoreFrontを含むすべての展開に適用される一般的な考慮事項については、「StoreFrontの展開を計画する 」を参照してください。
GCP上のStoreFront との主な違いは、通常、複数のGoogleクラウドゾーンにまたがるStoreFront StoreFront サーバーグループに複数のStoreFrontインスタンスを展開することです。この設計で有効になっている機能は、 ゾーン間のレイテンシーに依存することに注意してください。 StoreFront展開/スケーラビリティプランでは、StoreFrontサーバーグループの展開は、サーバーグループ内のサーバー間のリンクの遅延が40ミリ秒未満（サブスクリプションが無効な場合）または3ミリ秒（サブスクリプションが有効な場合）未満の場合にのみサポートされます。GCPのゾーン間レイテンシーは通常1ミリ秒未満ですが、StoreFront をホストする予定のすべてのゾーンのインスタンス間のレイテンシーを測定し、それに応じてサブスクリプションを有効または無効にしてください。
これについては、このドキュメントの前半ですでに説明しましたが、繰り返し述べておく価値があります。耐障害性要件が厳しい環境では、Citrix DaaSのローカルホストキャッシュ機能を最大限に活用するために、StoreFrontの実装を強くお勧めします。このアーキテクチャは、Cloud ConnectorがCitrix Cloudに到達できない場合に復元力を提供します。このような状況が発生しても、ユーザーは停止のシナリオ中に新しいセッションと既存のセッションに接続できます。ローカルホストキャッシュアクティベーションの詳細、制限事項、および影響については、「 ローカルホストキャッシュ (DaaS)」を参照してください。
上記のように、Google CloudでのStoreFront の実装は、高可用性を実現するために複数のGoogle Cloudゾーンにまたがる必要がありますが、NetScaler ADC/Gatewayの設計を考慮してください。NetScaler ADC/Gatewayは、通常、StoreFrontインスタンスの前で使用して、負荷分散、高度な監視、およびサービスの回復力を強化することを推奨します。