技術概要：Citrix Cloud レジリエンシー
はじめに
デジタルトランスフォーメーションの取り組みは、現在、大規模な企業にとって最優先事項です。アプリケーションおよびデスクトップ配信インフラストラクチャをクラウドに移行することは、CIOの主な考慮事項の1つです。クラウドプロバイダーは、クラウドのみのソリューションまたはクラウドベースのリソースを、魅力的な価格で提供しています。また、運用が簡素化され、管理コストの削減というメリットも加えられています。クラウドへの移行を検討する際に、IT 部門で最初に評価すべき事項は、提案されたクラウドベースのソリューションの稼働時間と耐障害性です。この考慮事項は、Citrix CloudをWorkspaceソリューションとして活用したいと考えている見込み顧客または既存のCitrix Cloud のお客様にも同様に適用されます。
この概要は、次のことを説明するために設計されています。
- これらの信頼性の考慮事項と、Citrix Cloudとサービスの障害に対する弾力性の向上を目指して、Citrixが取り組んでいるさまざまな方法を説明します。
- まれにサービスにアクセスできないようにCitrix Cloudがどのように展開されているか、エンドユーザーは、サービスの利用不能の影響を受けないリソースに引き続きアクセスできます。
- Citrix Cloudがクラウドプロバイダーによって公開されているテクノロジをどのように使用しているか、Citrix Cloudサービスを実行してサービスを高可用性とフォールトトレラントにします。
注意すべき重要な点は、文書に記載されているすべての項目が組み合わされたソリューションとして連携して、網の複数の層を形成し、システム停止から組織を保護し、1 つの間にアクセスを可能にするということです。
高可用性
まず、クラウドサービスと基盤となるインフラストラクチャが改善され、サービスが障害にならないようにしましょう。この耐障害性は、顧客の需要を満たすために容易に拡張できる高可用性サービスを構築することによって達成されます。
Azure アベイラビリティーゾーンを利用することで、ブローカーおよび関連するデータベースは、クラウドの停止に対する回復力を確保できます。
プラットフォームの高可用性と地理的ノード導入モデル
Citrixが提供するクラウドサービスは、連携して動作するさまざまなプラットフォームの上に構築され、Workspaceおよびワークスペースから利用可能なリソースへのアクセスをユーザーに提供します。これらのプラットフォームの各アーキテクチャは、可用性と耐障害性を備えるように、継続的に改善されています。プラットフォームを Azure ジオードパターンに基づいて展開するように設計上の決定が下されました。各プラットフォームは、このパターンを採用するための旅の異なる段階にあります。
地理的ノードパターンでは、プラットフォームはグローバルに多様であり、他の導入環境ではストレージ・レプリケーションを利用する、異なるノード内の複数の展開環境に分散されます。各ジオード内で、完全に自己完結型のプラットフォームサービスは、さまざまな Azure フォールトドメインにデプロイされます。最も重要なサービスは、これらの展開間でフェイルオーバーできます。
Azure リージョン全体にアクセスできない場合でも、プラットフォームサービスは、別のリージョンからの別のジオードからのリクエストを処理できます。データの主権に関する規制要件がある組織では、必要な地理的場所にサーバを導入できるように、プラットフォームを導入します。組織は異なるCitrix Cloudインスタンスを選択して、データ主権のニーズを保証できます。
Citrix DaaS
Citrix DaaSには、耐障害性と耐障害性を実現するために実装されたさまざまな機能があります。機能のいくつかは次のとおりです。
ランデブープロトコル
Citrix Cloud Connectorのスケーラビリティを向上させるため、HDXプロトコルはCVADバージョン1912で変更されました。ランデブープロトコルを使用すると、HDXセッションでCitrix Cloud Connectorをバイパスし、NetScaler Gatewayサービスに直接安全に接続できます。HDXトラフィックをバイパスして、Cloud Connector 帯域幅とコンピューティングリソースを解放します。コネクタを有効にして、より多くの接続要求を処理し、Cloud Connector で管理できるリソースの数を増やします。
ランデブープロトコルの詳細と、ポリシーを介して有効にする方法については、 こちらをご覧ください。
サービス継続性
Citrixがサポートするスケール制限を盛り上げて、クラウド展開の耐障害性を強化するさまざまな方法を確認したら、クラウドサービスの障害や停止が発生した場合に、ユーザーが複数のリソースにアクセスし続けることができるように、Citrixが保証する方法に注目しましょう。リソースの場所。 Citrix Cloudサービスにアクセスできない場合でもリソースを利用できるようにすることを目標として、Citrixのチームは、サービス継続性の傘の下、ゼロから多くの改善を実施しました。
サービス継続性の下で実装される一連の機能には、以下が含まれますが、これらに限定されません。
-
Workspace 接続リースを作成して各クライアントエンドポイントに配布するメカニズム。少なくとも 1 回認証された Workspace 接続リースは、Workspace に対して少なくとも 1 回認証されています。Workspace 接続リースファイルは、そのエンドポイント (ユーザー単位) に、どのアプリとデスクトップリソースがどのCloud Connectorによって管理されているかを示します。基本的に、単一のリソースの場所の制限を排除します。
-
Citrix Workspaceアプリ内のプログレッシブWebアプリ（PWA）の実装では、特定のサービスにアクセスできない場合に検出でき、それに基づいて現在アクセス可能なリソースがユーザーに表示されます。また、接続が失われたことをユーザに知らせるバナーが表示されます。
-
高可用性とマルチクラウドのプレゼンスを内蔵し、グローバルNetScaler Gatewayプレゼンス（PoP）へのフットプリントは増え続けるため、ユーザーは常にNetScaler Gatewayサービスにアクセスできるようになります。
これらのソリューションの仕組みについて詳しく説明する前に、さまざまなシナリオがCitrix Cloudサービスの可用性にどのように影響するか、およびそのようなシナリオが発生したときにどのリソースが使用できるかを見てみましょう。
-
ワークスペース URL/
Cloud.comストアサービスコンティニュイティでは、ユーザーがワークスペース URL にアクセスできない場合、Workspace アプリの上部にあるバナーによって、リソースのサブセットが使用できないことがユーザーに通知されます。Citrix Workspaceアプリでは、リソースアイコンが変更され、まだ利用可能なリソースを簡単に識別できます。
-
Citrix DaaS/ブローカーサービスのみ
このシナリオでは、DaaS または Broker Service のみで停止が発生し、ユーザーは仮想アプリとデスクトップリソースに加えて、Web アプリと SaaS アプリに引き続きアクセスできます。WorkspaceアプリUI（PWAによって強化）は、サービスフィードのすべてのリソースを集約し、Citrix DaaSアプリのみに対してWorkspace接続リースに依存します（フィードごとのアプリ内キャッシュ図を参照）。
Citrix Cloud Connectorがリソースの場所のすべての仲介業務を引き継ぐようになりました。プライマリCloud Connector へのVDAの再登録がトリガーされます。負荷管理およびその他の操作も、Cloud Connector によって処理されます。停止中のVDA電源管理について詳しくは、 こちらをご覧ください。
-
アイデンティティーサービス
アイデンティティサービスにアクセスできないシナリオでは、ユーザーはCloud Connectorsから到達可能なすべてのCitrix DaaSリソースに引き続きアクセスできます。接続リース（少し後で説明）には、リソースとユーザーの認証トークンが含まれています。ユーザーは、VDAからデスクトップまたはアプリでの認証とログインを求められます（マシンが同じユーザーのセッションを共有していて、以前の接続リースベースの起動からすでに認証されている場合を除く）。
-
インターネット — (接続がある場合は内部リソースのみアクセス可能)
クライアントエンドポイントがインターネットに接続できないが、Cloud ConnectorとVDAへのネットワーク接続（内部ネットワーク上）がある場合。内部ネットワーク上でアクセス可能なすべての仮想アプリとデスクトップリソースは、インターネットアクセスが失われたときに使用できます。
-
ゲートウェイまたはSecure Private Accessサービス — 別の PoP へのフェイルオーバー
NetScaler Gatewayサービスは、サービスの複数のインスタンスで可用性を高めるように構築されており、世界中のさまざまな場所の複数のポイントオブプレゼンス（PoP）に展開されています。また、このサービスは異なるクラウドプロバイダーでホストされています。 POPのリストはこちらで見つけてください。
プログレッシブウェブアプリ
プログレッシブウェブアプリは、ウェブサーバーにアクセスできない場合に表示されるキャッシュ要素のバックグラウンド処理を含み、キャッシュを使用してアプリの UI を設定するという点で、通常のウェブアプリとは異なります。サービス継続性については、Workspace サービスにアクセスできない場合や、ユーザーに割り当てられているリソースのリストを返せない場合でも、プログレッシブ Web アプリは同じように動作します。
Citrix Workspaceアプリは、新しいCLXMTP（接続リース交換および相互信頼プロトコル）を使用して、Cloud Connector またはゲートウェイサービスと通信します。内部ユーザーの場合、Citrix Common Gateway Protocol（CGP）TCPポート2598で実行され、外部ユーザーはCGS TCPポート443で実行されます。このプロセス全体はユーザーに対して透過的です。
ユーザーエクスペリエンスの変更
サービス継続性が有効になった後、Citrix WorkspaceアプリがWorkspaceへの接続を試みたがストアにアクセスできない場合。ユーザーが有効な接続リースを持っている場合、キャンセル可能な認証 UI のサポートと、ネイティブ Workspace アプリでキャッシュされたアセットへのフォールバックがサポートされます。
バナーが表示され、接続が失われたことをユーザに知らせます。リソースはキャッシュから表示されます。影響に応じて（前のセクションで説明したように）、現在アクセスできないリソースが動的にグレー表示されます。
アクセス可能なリソースのリストは、エンドポイントに格納されている接続リース（次のセクションで説明）から取得されます。
接続が再確立されると、Workspace アプリはユーザーに Workspace に再接続できるようになります。ユーザーは、バナーの [ワークスペースに再接続] リンクをクリックして、以前に灰色表示されていたリソースへのアクセスを復元できます。
ユーザーがリソースにアクセスできるようにするには、Workspace Identity サービスが認証にアクセスできない場合、接続リースは長期間有効な認証トークンのように動作します。ユーザーは、起動時に AD 資格情報またはスマートカード PIN を使用して、アプリまたはデスクトップにアクセスするためにリソースで認証する必要があります。
Citrix WorkspaceアプリとVDAが同じドメインに参加しており、WorkspaceアプリでSSOパススループラグインを構成すると、SSOが実現されます。セッション共有もサポートされているため、ユーザーがワークスペース接続リース経由で既存のセッションも起動している同じVDAからWorkspace接続リースを介して後続のアプリを起動すると、SSOが達成されます。
ワークスペース接続リースとその仕組み
すべてのサービスが到達可能になると、クライアントがアプリケーションまたはデスクトップに接続できるようにする.ICAファイルが生成されます。このファイルは、1 回限りの短命アクセスチケットを提供します。このチケットには、ユーザーが接続するリソースに関する情報が含まれています。.ICAファイルは、Workspaceによって生成されます。このファイルは、ユーザーに割り当てられたリソースの一覧（.k.a列挙）を取得し、セッションをホストできるVDAを特定します（解決方法）。
必要なサービスのいずれかが到達不能の場合、 .ICA ファイルを生成できません。起動/再接続の要件ごとにこれを克服するために、Workspace 接続リースが設計されました。
デフォルトでは、Workspace 接続リースは 7 日間有効です (1 ～ 30 日間に設定可能)。これは、ユーザーが割り当てられているすべてのリソースについて、長期間有効な認証トークンです。リソースにアクセスするために使用できるCloud Connectorのリストが表示されます（直接またはNetScaler Gatewayサービスを経由）。CGSが関与する場合、ワークスペース接続リースには、リソースへの接続に使用できるグローバルNetScaler GatewayサービスのFQDNアドレスも含まれます。
Workspace 接続リースは、ユーザーごとの、エンドポイントのトークンのセットごとに、ユーザーに資格が与えられているすべてのリソースのキャッシュを含みます。これには、NetScaler Gatewayサービスの情報、および接続要求を処理できるすべてのCloud Connectorが含まれます。接続リースはユーザーとエンドポイントにバインドされるため、別のデバイスにコピーしてセッションの起動に使用することはできません。
Workspace接続リースを作成するには、ユーザーはCitrix Workspaceアプリを使用してCitrix Workspaceに少なくとも1回はサインインする必要があります（ブラウザ経由ではなく）。ユーザーがサインインすると、Citrix Cloudの接続リース発行サービス（CLIS）は、ユーザーとエンドポイントの組み合わせに対するリースを生成する要求を受信します。接続リース発行サービスは、この要求をキューに入れ、クラウドブローカーに転送します (過負荷にならないように)。接続リースには、ユーザーのセッション要求を処理できるCloud Connectorとリソースのすべての組み合わせが含まれているため、このプロセスは非同期的に実行され、リースが生成されると、エンドポイントにプッシュされます。このプロセスは、ブローカーの負荷に応じて最大10分かかることがあります。
Workspace接続リースは、Citrix Cloudによって暗号化および署名され、エンドポイントに安全に格納される3つの連結ファイルで構成されています。3 つのファイルは、メタデータ、共通パラメータ、リソースの場所です。Windows エンドポイントでは、各ユーザーの AppData\ Local フォルダーに格納されます。パスは%LOCALAPPDATA%\Citrix\SelfService\ConnectionLeases\<StoreName>\<SiteName>\<username>\leasesです
次の画像に見られるように、ユーザーは6つのリソースに資格を与えられているので、フォルダ内に18のファイルがあります。
接続リースは改ざん防止されています。不良アクターは、リースを編集できません。たとえば、リースの期間を延長します。改ざんが検出されるとすぐに、接続リースのハッシュが無効になります。接続リースは、IT管理者がCitrix DaaSリモートPowerShell SDKを使用して、閉鎖または侵害されたユーザーアカウント、盗まれたエンドポイント、またはデバイスの割り当て解除などの状況でブロックできます。これらのポリシーの適用方法については、 こちらをご覧ください。
次に、ユーザーがエンドポイントから初めて認証し、セッションを起動したときの、接続リースの作成プロセス図を示します。
Citrix Cloudサービスの一部にWorkspaceアプリからアクセスできない場合に発生するプロセスは次のとおりです。
Citrix Virtual Apps and Desktops 7.15 LTSRまでのVDAバージョンを使用して、現在の顧客ベースのより大きなサブセットを有効にするには、クラウドブローカーにアクセスできない場合に、ローカルホストキャッシュ付きCloud Connector（LHC）が使用されます。そうしないと、サービス継続性を有効にする変更では、VDAをアップグレードする必要がありました。詳細については、 LHCテックブリーフをお読みください。
注：Citrix Cloud Brokerサービスにアクセス可能なシナリオ（ワークスペースストアにアクセスできるかどうかに関係なく）では、Cloud Connectorは常にブローカーサービスを使用して仲介を行います。
リソースの場所が「内部のみ」として構成されている場合、プロセスは同じですが、この場合、Workspace アプリは、目的のアプリがホストされているリソースの場所にあるCloud Connectorと直接やり取りします。
注:接続リースが存在する場合でも、リソースを起動するデフォルトのメカニズムは.ICAファイルの取得を試みます。これが不可能な場合、Citrix Workspaceアプリはユーザーに対して透過的かつサイレントにWorkspace接続リースに依存するようにフォールバックします。
ユーザーが Workspace アプリからログアウトすると、Workspace 接続リースはシステムから消去されます。ユーザーがCitrix Workspaceアプリを終了しても、ワークスペース接続リースは保持されます。
この動作は、IT 管理者がクラウドブローカーインスタンスに対してリモートの PowerShell コマンドを介して変更できます。
システム要件
現在の要件のリストについては、 ドキュメントページをご覧ください。
-
お客様は、Citrix DaaS とワークスペースエクスペリエンスを使用しています。
-
ワークスペースUIには、Windows 2106およびMac 2106以降用のネイティブCitrix Workspace kspaceアプリからアクセスする必要があり、ブラウザー（Web向けCitrix SDX Hypervisorアプリ）からはアクセスできません
-
Citrix Virtual Delivery Agent（VDA）バージョン1912以降、LTSR、または現在のCRのいずれか
-
最新のCloud Connector。サービスの継続性はローカルホストキャッシュ機能に依存するため (ただし、オンプレミスのアクセスレイヤーは必要ありません)、LHC に推奨するサイズと同じサイズでコネクタのサイズを設定することをお勧めします。詳細については、 LHC のスケールとサイズの考慮事項を確認してください 。
-
ワークスペースアイデンティティ:AD (または Azure AD Connect 同期)、AD + トークン (OTP)、AD + RADIUS、Azure AD、オンプレミスの NetScaler Gateway では、プライマリ要求が AD ベースの認証に基づきます。ポリシーベースの認証は、サービス継続性と互換性がないため、相互に排他的です。
-
お客様のVDAはオンライン状態：AWS/Azure/DCの停止の影響を受けない、または自動スケールによる電源オフはありません。 注意：リソースロケーションがCitrix HypervisorまたはvSphereを使用している場合、Cloud Connector はクラウドブローカーがオフラインであっても電源管理アクションを実行できます。
-
サポートされるワークロード:ホストされた共有アプリまたはデスクトップ、静的/専用デスクトップ、ランダム/プールデスクトップ、リモートPCアクセス
-
CWA と Connector とリソースを実行しているVDAとのエンドポイント間のレイヤ 3 ネットワーク接続（
-
ダイレクト（LAN）（この場合、コネクタとVDAはTCP 2598経由で到達可能である必要があります）
-
NetScaler Gateway サービス (TCP 443)
-
サービス継続性を構成する手順については、 こちらを参照してください。
スケーラビリティの向上を監視する
Citrix DaaS環境の2日目以降の維持は、環境を簡単に管理し、ユーザーの問題を迅速かつ効果的に解決する管理者の能力に依存しています。Monitorが、大規模なマルチテナント展開をサポートするCitrix DaaSベースのソリューションを作成する大規模な組織、パートナー、およびリセラーを確実にサポートできるように、Monitorにはこれらの機能が含まれており、回復力を高めています。
-
パフォーマンスを向上させるためにリードレプリカが使用されている
Director は、DB への読み取りクエリのほとんどがデータベースのリードレプリカに再ルーティングされるメカニズムを実装しています。リードレプリカは、データベースの読み取り専用コピーです。これにより、ソースデータベースでの書き込み操作の完了がはるかに高速になり、拡張性と復元性が向上します。
-
ベストプラクティスに従るデータベースの展開
サイト DB と設定ログとモニター DB を分割すると、より多くのクエリと DB の Auto Scaling がサポートされます。
-
セッション管理者ロールが導入されました
大規模な展開では、Citrix DaaSはセッション管理者の役割を提供します。このロールは、レベル 1 のヘルプデスクロールの [モニタ] の権限を提供します。セッション管理者の役割では、同じCitrix DaaSインスタンスがヘルプデスク管理者の同時実行率を高めます。
-
サポートされる管理者数の増加
大規模な組織やリセラーは、膨大な展開を管理できる多数の管理者を必要としています。これには、DB が拡張され、より多くの同時クエリを処理する必要があります。これらの顧客をサポートするために、サポートされる管理者の数が増加しました。
NetScaler Gatewayサービス
NetScaler Gatewayサービスは、サービスの複数のインスタンスで可用性を高めるように構築されており、世界中のさまざまな場所の複数のポイントオブプレゼンス（PoP）に展開されています。また、このサービスは異なるクラウドプロバイダーでホストされています。 POPのリストはこちらで見つけてください。
NetScaler GatewayサービスPoP内では、マイクロサービスとテナントは、完全に冗長化されたアクティブ/アクティブモデルで展開されます。この機能により、障害が発生した場合に、任意のコンポーネントをスタンバイに切り替えることができます。まれに、PoP 内のコンポーネントのすべてのサービスに障害が発生した場合、Gateway サービスは自身をダウンとしてマークします。
Citrixでは、インテリジェントトラフィックマネージャーを使用してPoPの状態を監視し、必要に応じてDNSを使用してトラフィックを代替POPに切り替えます。
サービスコンティニュイティは、ゲートウェイサービスの耐障害性と組み合わせることで、クライアントから Gateway サービスと/または [リソースの場所] にアクセスできる限り、仮想アプリとデスクトップリソースにアクセスできます。