リファレンスアーキテクチャ-Google Cloud でのCitrix の仮想化

はじめに

このガイドでは、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 Desktops-a-Service(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 DaaS:セッションブローカリング、負荷管理、単一インスタンスイメージ管理、監視、 コスト/キャパシティ管理サービスを提供します。
  • Citrix Workspace サービス: ソリューションのユーザーインターフェイス。このWebサービスは、Citrix Workspaceアプリの多要素認証、コンテンツ表示、および起動サービスを提供します。このサービスは、エンタープライズファイルストアに加えて、仮想アプリケーション、デスクトップ、Web、SaaS アプリケーションへのアクセスを統合します。
  • NetScaler Gateway Service: エンタープライズWebアプリケーションに加えて、仮想化されたアプリケーションとデスクトップへのパブリックネットワーク上のデバイスへの安全なアクセスを提供します。
  • Citrix Analytics Service: 高度な機械学習テクノロジーを使用して、エンタープライズグレードのセキュリティ、パフォーマンス、およびユーザー行動分析とレポートを提供します。

このデザインパターンをGoogle Cloud VPN/インターコネクトと組み合わせて、既存のActive Directory 投資(❽)をGoogle Cloudに拡張したり、従来のオンプレミスの顧客管理アプリケーションやインフラストラクチャへのアクセスを提供したりすることもできます。

クラウドフォワードデザインパターンのアーキテクチャによって、Citrix Cloudリソースの場所が作成されることは明らかです。これは、ここに示す3つのパターンすべてで共有されている共通の基盤です。パターンの違いは、次の表に示すCitrix仮想化システムの5つのコンポーネントにどのテクノロジーが使用されているかにあります。クラウドフォワードデザインパターンでは、次の5つのコンポーネントすべてにクラウドサービスが使用されます。

セッションの仲介と管理 Citrix のサービスとしてのデスクトップ-(DaaS) (クラウドサービス)
ユーザーインターフェイス (UI) サービス Citrix Workspace サービス(クラウドサービス)
認証 Citrix Workspace サービス、IdPとしてActive Directory を
HDXセッションプロキシ NetScaler Gateway Service(クラウドサービス)
分析 Citrix Analytics サービス(クラウドサービス)

クラウドフォワードデザインパターンは、同じ Active Directory(またはしない)を使用して、異なる Google Cloudリージョンで複製できます。これにより、このパターンは、地理的に分散したアプリケーションやデータを使用した展開に役立ちます。 本番環境でのデプロイでは、 Google Cloud VPN(Google Cloud Interconnect)を使用して GCP のリソースロケーションをカスタマー管理のデータセンターに接続することで、このパターンを拡張できることがよくあります。このようなプライベートネットワーク接続を使用すると、キーサービス(Microsoft Active Directory など)を Google Cloudに拡張できます。これにより、まだ移行されていないアプリケーションやリソースにVDAにアクセスできます。また、アプリやデータを Google Cloud に移行するためのコンジットとしても機能します。前の図には示されていませんが、 Citrix Workspace Environment Management サービスは 、特にシステムが本番環境に移行するときに一般的に使用されます。Workspace Environment Management サービスは、インテリジェントなリソース管理およびProfile Managementテクノロジを使用して、Citrix Virtual Apps and Desktopsの展開において、可能な限り最高のパフォーマンス、デスクトップログオン、およびアプリケーション応答時間を提供します。詳細については、このガイドの後半の「 ユーザー環境/設定管理 」を参照してください。

ハイブリッドデザインパターン

ハイブリッドデザインパターンは、クラウドフォワードデザインパターンに基づいて構築されます。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 ベースのユーザーインターフェイスの必要性。

hybrid-design-pattern

ハイブリッドデザインパターンでは、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仮想化システムの5つのコンポーネントのコンテキストにハイブリッドデザインパターンを配置するには:

仮想化システム機能 提供者
セッションの仲介と管理 Citrix DaaS (クラウドサービス)
ユーザーインターフェイス (UI) サービス Citrix Workspace サービス(クラウドサービス)またはCitrix StoreFront(カスタマー管理)
認証 NetScaler ADC/Gateway(顧客管理)の導入により、Citrix Workspaceサービス(クラウドサービス)またはCitrix StoreFront で使用できる多くの組み合わせ
HDXセッションプロキシ NetScaler Gateway Service(クラウドサービス)またはNetScaler ADC/Gateway(顧客管理)
分析 Citrix Analytics サービス(クラウドサービス)

クラウドサービスまたは顧客管理コンポーネントのいずれかを選択する前に考慮すべき重要な機能項目は他にもたくさんあります。以降のセクションでは、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 とGoogleが提供する最新のテクノロジーについて体系的にスタッフを再キルし、管理しやすいペースで組織のクラウド対応状態を構築しながら、テクノロジー、インフラストラクチャ、知識、プロセス、運用化への既存の投資を活用できます。手順。

一般的な例の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に移行できます。

クラウド移行の設計パターンは、前のセクションで説明したハイブリッドパターンから始まります。ハイブリッドパターンを使用して構築されたシステムは、新しいワークロードを導入する最新の新しい環境になります。クラウド移行パターンでは、Citrix StoreFront(➊)またはCitrix Workspace(❷)ユーザーインターフェイス、またはその両方を使用して、従来のCitrix環境(❸)を新しい環境に接続します。これは、両方のUIが単一のログインで複数の仲介環境を単一のビューに表示できるからです。これにより、ユーザーは両方の環境にアクセスするために使用できる単一の UI (❹) が提供されます。これにより、お客様は新しいワークロードを Google Cloud(❺)にデプロイし、ビジネスの機会や制約に応じて既存のワークロードを Google Cloud に体系的に移行できます。

cloud-migration-design-pattern

この同じ顧客は、StoreFrontと並行してCitrix Workspace を実行し、Citrix Cloudサイト集約機能を使用して従来の 「Citrixファーム」をワークスペースUIに追加することもできます。両方の UI は、同じユーザーに同じリソースへのアクセスを提供します。ビジネス上の優先度が許すように、エンドユーザーは、Citrix WorkspaceサービスのUIに徐々に移行できます。

site-aggregation.png

クラウド移行アプローチの利点は、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 DaaSを使用すると、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 インスタンスの関係を示しています。

cloud

注:

Citrix App Layering またはPVSサポートを完全にする要件をお持ちのお客様は、Citrix Cloudリソースの場所をGoogle Cloud VMware エンジンで実行することを検討する必要があります。現在、VMwareベースのプラットフォームでは、Citrix App Layering PVSの両方が利用可能です。

Google Cloud VMware Engine でのCitrix 仮想化ソリューションの設計と実装は、この設計ガイドの範囲外ですが、このガイドで説明されている概念とコンポーネントのほとんどは引き続き適用されます。VMware(クラウドファンデーション)でのCitrix Cloud リソースロケーションの設定に関する詳細については、 Citrix DaaSドキュメントを参照してください

ソリューションのコンポーネントと要件

仮想化システムの前提条件

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はCloud Connectorに登録され、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のCloud Connectorのデプロイシナリオについても説明します。

重要:

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仮想化システムのセキュアなクラウド管理プロキシとして機能します。Cloud Connectorは、リージョン内の個別のゾーンにある、ドメインに参加している Windows Server 専用のインスタンスです。また、インターネットアクセスが中断された場合のオフラインセッションブローカーとしても機能します (「ローカルホストキャッシュモード」)。可用性が極めて高いミッションクリティカルな展開に役立ちます。この機能については、この文書の後半でハイブリッドデザインパターンについて詳しく説明します。

Cloud Connectorは、通常、特定のリージョンの複数のゾーンに分散したVMインスタンスを使用して、N+1リソースとしてデプロイされます。これにより、リソースの場所を拡張でき、Cloud Connectorソフトウェアの自動更新が容易になります。

注:

Citrix Cloud Connectorのインスタンスのサイジングについて詳しくは、「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にプロキシするCloud Connectorのスケーラビリティが向上します。パブリックネットワーク経由でHDX接続をプロキシするもう1つのオプション-VPCの境界に顧客管理のNetScaler ADC/Gatewayインスタンスをデプロイします。

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

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 ライセンススペシャリストにご相談ください。ただし、この複雑なトピックについては、以下を参考にしてください。

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上で実行されます。これらの表示方法に関するオプションがあり、これによってユーザーがそのユーザーと対話する方法が決まります。個々のアプリケーションやファイルをユーザーに提示したり、「公開」したりできます。また、アプリケーションおよびデータを操作するデスクトップでそれらを表示することもできます。

published-desktops-published-apps

例: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インスタンスの永続クローンまたは非永続クローンを含めることができます。マシンカタログは、別のプロセスまたはテクノロジを使用してプロビジョニングすることもできます。どちらの方法でも、電源管理として作成されていることを確認する必要があります。

managed-unmanaged

電源管理されたマシンカタログを使用しない場合、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 で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形状の調整を特定できます。

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フリートをコスト最適化しながら、システム需要の予想外の変動に対応できる容量を確保できます。

需要パターンと言えば、各ワークロードの固有のパターンを理解するために、時間とリソースを投資したいと考えています。時間の経過とともに変化し、進化していくことを期待し、キャパシティ管理の戦略と戦術を調整して対応できるように準備してください。

パフォーマンスチューニング

Citrix仮想化システムでのパフォーマンスの認識には、多くの要因が挙げられます。VDAに適した形状のVMインスタンスの選択に加えて、パフォーマンスの最適化のために調査するその他の重要な領域は次のとおりです。

ユーザー環境および設定管理の選択: ポリシーとは、ユーザーのパフォーマンスを管理および最適化するときの友だちです。ポリシーは、Windows、アプリケーション、セッションなどの構成を制御します。さらに複雑にするために、複数のポリシーエンジンを使用できます。それぞれのポリシーエンジンは、ユーザーエクスペリエンスに独自の影響を与えます。適切なポリシーエンジンを選択し、一貫したベースラインを確立することは重要であり、 幸いにもベースラインポリシー設計で詳しく説明されています。また、 Citrix Workspace Environment Management サービスは 、さまざまな環境でのユーザーエクスペリエンスを最適化し、管理を簡素化するために使用できます。

Windows の最適化: Windows は汎用オペレーティングシステムであり、さまざまなユースケース、ハードウェアの種類などをカバーするように設計されています。Windowsのデフォルト設定の多くは、Citrix仮想化環境では不要です。幸いなことに、 Citrix Optimizer が役立ち、最高のパフォーマンスと全体的なリソース使用率を最小限に抑えるために、VDAに適用できる多くの包括的なテンプレートが含まれています。

ウイルス対策チューニング:Citrix VDAおよびサポートインフラストラクチャでウイルス対策ソフトウェアを実行することは、しっかりとした推奨方法です。しかし、誤ってインストール/構成すると、ユーザーエクスペリエンスに混乱を引き起こす可能性があります。それを正しく行うための優れた入門書については、 エンドポイントセキュリティとウイルス対策のベストプラクティスを参照してください

HDXプロトコルの最適化:CitrixのHDXディスプレイプロトコルスタックは、多くの自動検出と適応を即座に実行し、可能な限り最高のユーザーエクスペリエンスを提供します。UX のパフォーマンス、応答性、豊かさと帯域幅消費のバランスを取ろうとします。一部のユースケース (グラフィックス負荷の高いワークロード、低品質/低品質のネットワーク接続など) では、バランスを正しく得るための微調整によるメリットがしばしばあります。詳細については、「 HDXグラフィックの概要 」を参照してください。

また、Citrixでは、設定を特定のユースケースに柔軟に一致させるために使用できる、あらかじめ構築されたセッションポリシーテンプレートがいくつか用意されています。これらのポリシーは、Citrix Cloud Studio で構成および管理され、さまざまなフィルターを使用して適用できます。これらのフィルターを使用すると、特定のシナリオを最適化するために適切なポリシーが適用されていることを確認できます。

HDXプロトコル最適化

適切な価格モデルの選択

Google Cloud は、 お客様がそこで実行するさまざまなタイプのワークロードに使用できるさまざまな価格モデルを提供しています 。さまざまなユースケースの需要パターンを理解することで、コストとサービスの可用性/パフォーマンスのバランスを取るために、リソースごとに適切なモデルを選択できるようになります。Citrix仮想化システムでは、お客様は一般的に、GCP上で動作するリソースの持続的使用とコミット済み使用割引モデルを考慮します。持続的な使用割引はインスタンスタイプによって異なります(N1 とたとえば、N2) と一部のインスタンスタイプ (E2 など) では、継続的な使用割引が提供されません。詳細については、 VM インスタンスの料金を参照してください

以下に、 N1 インスタンスタイプの持続的使用とコミット済み使用の割引を示します。

optimizing-cost

一部のリソースは、一意で拡張性が高く、Citrix仮想化システムが機能するために利用可能である必要があります。そのため、通常は24時間365日稼働し、N+1を導入して可用性を確保し、コミットされた使用割引の候補として最適です。これには、Active Directory、Citrix Cloud Connector、NetScaler ADC/Gateway VPX、およびCitrix StoreFront 仮想マシンインスタンスが含まれます。

VDAインスタンスの場合、選択肢はそれほど単純ではありませんが、需要パターンをより明確に理解すればするほど、選択肢は明確になります。すべては、VDAの電源をオンにする必要がある時間まで低下します。次のグラフ( N1 インスタンスタイプに固有)を考えてみましょう。このグラフは、少しエンベロープ数学で再現できます。

break-even

この図は、特定の請求サイクル中に(N1 インスタンスタイプで実行されている)リソースが 50% 以上オンになる場合、3 年間の使用割引を適用できれば、コスト削減を開始することを示しています。1年間のコミット使用割引のブレーク偶数ポイントは約 82% です。請求サイクル中にリソースがそれ以上パワーオンされ、3 年間のコミットされた使用が利用できない場合、1 年間のコミットされた使用は理にかなっています。

ファイルストレージとデータレプリケーション

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 Cloud 上のCitrix NetScaler VPX

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

  • Citrix NetScaler VPX on GCP(Citrix ドキュメント):サポートされているVPXモデル、GCPリージョン、コンピューターエンジンインスタンスタイプ、その他のリソースリファレンスなど、GCP上のCitrix NetScalerの包括的な概要が記載されています。
  • Citrix NetScaler VPX GCPマーケットプレイス展開:GCPマーケットプレイスで利用可能なすべてのCitrix ネットワーキング導入ソリューション。Citrix Virtual Apps and Desktops Citrix DaaSを使用したCitrix Gatewayの導入にも機能的で関連性があります。
  • Citrix NetScaler GDM テンプレート:Citrix NetScaler GDM テンプレート用の GitHub リポジトリ。これは、Citrix ADC VPXインスタンスをGoogle Cloud プラットフォームにデプロイするためのCitrix NetScalerテンプレートをホストするリポジトリの優れたリファレンスです。

Citrix Docsの「 GCP上のCitrix NetScaler VPX 」で説明されているように、利用可能な展開オプションは主に2つあります。これには、次の種類のアカウントがあります:

  • スタンドアロン:Citrix NetScaler Gatewayの個々のインスタンスは、個別のエンティティとして展開および管理できます。これは、通常、高可用性が要求されない小規模な展開や POC 展開で使用されます。
  • 高可用性:これは本番環境で最も一般的に導入されているモデルです。Citrix NetScaler Gateway VPXインスタンスのペアは、HA構成を使用して同じゾーン内または同じリージョンの複数のゾーンに展開できます。このオプションについては、このセクションの後半で詳しく説明します。

ベストプラクティス:

Citrix NetScaler Gateway アプライアンスをGCPにデプロイする場合は、プレミアム階層(リージョン)の外部 IP アドレスを使用することをお勧めします。プレミアム層の外部 IP を使用する場合、ユーザーに最も近いエッジネットワークロケーションでトラフィックが入力および出力されます。トラフィックは、Google のプライベートネットワークを通過して、リソースがデプロイされているリージョンに到達します。これにより、標準層の外部 IP アドレスと比較して、スループット、低レイテンシ、一貫したパフォーマンス(ジッタが低い)が提供されます。詳細については、「Google Cloud ネットワークサービス階層」を参照してください。

NetScaler スタンドアロン

Citrix NetScaler VPXは通常、シングル、デュアル、または複数のNIC展開タイプをサポートしますが、GCPに展開する場合は、スループットとデータ分離を最適化するために、各NetScalerに少なくとも3つのVPCネットワークを使用し、各VPCにネットワークインターフェイスを用意することをお勧めします。Citrix Virtual Apps and Desktops をサポートするために展開する場合、管理インターフェイス(NSIP)は通常「プライベートCitrixインフラストラクチャサブネット」に接続され、サブネットIP(SNIP)は「プライベートCitrix VDAサブネット」に接続され、NetScaler Gateway 仮想IP(VIP) を「パブリックサブネット」に変更します。次の簡略化された概念図は、この構成を示しています。これは、単一のゾーン内の単一のVPXインスタンスを示しています。この設計パターンは、高可用性構成の場合(おそらく2番目のゾーンで)複製されます:

NetScaler スタンドアロン

次の表に、各 NIC の目的と、関連する VPC ネットワークを示します:

NIC 目的 関連する VPC ネットワーク
NIC 0 NSIP(管理トラフィックを処理する) (❶) 管理ネットワーク
NIC 1 クライアント側のトラフィック(VIP)をサービスする (❷) パブリックネットワーク
NIC 2 バックエンド・サーバ(SNIP)との通信 (❸) バックエンドサーバネットワーク

重要:

3つのNICを備えたCitrix NetScaler VPXインスタンスをGCP上で実行する場合、最低4つの仮想CPUが必要です。詳細については、 ネットワークインターフェースの最大数を参照してください

複数のゾーンにわたるNetScalerの高可用性

前述のように、これはCitrix仮想化システムの最も一般的な展開モデルです。このモデルでは、複数のゾーンにデプロイされた単一リージョン内のCitrix NetScaler VPXのペアを使用します。高可用性(アクティブ/パッシブ)は、複数の方法で実現できます。GCP HTTPSロードバランサーは、互いに独立して構成されたNetScalerを使用するか、独立ネットワーク構成(INC)モードで構成されたCitrix NetScalerss HAを使用して使用できます。後者のオプション/アーキテクチャは、パブリッククラウドの導入に人気があると考えられているので、ここではその点に焦点を当てます。

GCP上のCitrix NetScaler Gateway VPXアーキテクチャには潜在的なバリエーションがありますが、次の図は3NICのCitrix NetScaler HAソリューションを示しています。このソリューションは、事前に設定された VPC ネットワークとサブネットを含む Google Deployment Manager テンプレートでデプロイできます

conceptual-architecture

Google Deployment Managerテンプレートを使用する場合は、Citrix NetScalerアプライアンスをデプロイする前にVPCネットワークを構成する必要があります。3 つの VPC ネットワークは、(❶) 管理ネットワーク、(❷) パブリックネットワーク、(❸) バックエンドサーバーネットワーク、各 VPC ネットワーク内の適切なサブネットで構成する必要があります。

traffic-flow

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

NetScalerにリモートノードを追加してINCベースのHAペアを作成する方法について詳しくは、Citrixのドキュメントを参照してください。Googleクラウド上のNetScalerの一般的なHA展開情報については、「Google Cloud プラットフォームへのVPX高可用性ペアのデプロイ」を参照してください。

リファレンスアーキテクチャ-Google Cloud でのCitrix の仮想化