Horizon Cloud ポッド - メンテナンスと更新

このドキュメント ページでは、デプロイされた Horizon Cloud ポッドを構成するソフトウェア コンポーネントのメンテナンスに関する重要な事項について説明します。

概要

システムのメンテナンス アクティビティには、ポッドのソフトウェア コンポーネントの自動更新が含まれ、サービスのサポート性と回復性に関する新機能、修正、および改善が含まれます。

ほぼゼロのダウンタイムでポッドおよびゲートウェイ アプライアンスの更新を完了するために、システムはエンドユーザー セッションの数を使用します。アクティブなセッションで環境に接続されているユーザーの数が少ない場合、システムはセッション数を使用して更新を完了する最適なタイミングを決定します。

既存のポッドを新しいマニフェストに更新するメンテナンス アクティビティは、クラウド プレーンからシステムによって開始され、システムによって決定された日時に実行されます。

このようなシステム メンテナンス アクティビティを特定の時間と曜日に開始することを希望する場合は、コンソールを使用して各ポッドの優先メンテナンス ウィンドウを指定します。

コンソールで優先メンテナンス ウィンドウが指定されていないポッドは、Horizon Cloud チームがいつでも都合の良い時にそのポッドのメンテナンスをスケジュール設定できると解釈されます。

メモ:このドキュメント ページで説明されているように、2022 年初頭から、サービスでは、Azure Marketplace で提供されるオファーをプログラムで使用するようにアップグレード コードが強化されました。アップグレードの事前チェックで、サブスクリプションでオファーのプログラムによる使用が禁止されていると判断された場合は、そのドキュメント ページに記載されているアクションを完了して、更新をブロックするエラーを解決する必要があります。

たとえば、ポッドとそのゲートウェイ構成に使用されるサブスクリプションに関連付けられている Horizon Cloud サービス プリンシパルがカスタム ロール(非定型)を使用している場合、カスタム ロールにこれらの 2 つの権限が含まれていることを確認してください。強化されたアップグレード API コードは、これらの権限に依存してマーケットプレイスからオファー リストを取得し、オファーを取得します。カスタム ロールにこれらの 2 つの権限がまだ含まれていない場合は、ポッドとゲートウェイのアップグレード プロセスが実行される前に、カスタム ロールに追加してください。

Microsoft.MarketplaceOrdering/offertypes/publishers/offers/plans/agreements/read
Microsoft.MarketplaceOrdering/offertypes/publishers/offers/plans/agreements/write

デプロイされたポッドで使用されているソフトウェア コンポーネントが新しいバージョンに更新されると、ポッドのマニフェスト番号は 2632.0 などのより高いバージョン番号に増加します。ポッドのサービス性とサポート業務について重要と考えられる改善がある場合は、2632.1 などのポイント バージョンの新しいマニフェストを作成できます。コンソールの [キャパシティ] ページにポッドのマニフェストが表示されます。

3328 より前のマニフェストからのポッドの更新に関する重要な情報

2022 年 2 月以降、ポッド マネージャ仮想マシンの NIC は、Unified Access Gateway 仮想マシンの NIC と同じインフラストラクチャ設計パターンに従います。

その時点で開始された新しいポッドのデプロイ、およびマニフェスト 3328 より前のマニフェストからのポッドの更新では、デプロイヤはポッドの実行とその後の更新をサポートするために必要なすべてのネットワークをインスタンス化します。これで、ポッドのリソース グループの NIC が 8 個になります。

• ポッドの管理サブネットから 4 つの IP アドレスを予約する 4 つの NIC
• ポッドのプライマリ仮想マシン サブネット(旧称テナント サブネット)から 4 つの IP アドレスを予約する 4 つの NIC。

これらの 8 つのポッド NIC は保持され、割り当てられた IP アドレスをポッドの存続期間中予約し続けます。

この設計では、より高速で回復力の高いポッドの更新がサポートされます。この設計より前は、ポッドの更新では、Green ポッドのビルドアウトの一部として新しい NIC を作成し、更新時にポッドのサブネットからそれらの NIC の IP アドレスを取得する必要がありました。この設計では、Azure でタイムアウトが発生し、更新プロセスが中断される可能性があります。

デプロイヤが必要なすべてのネットワークを事前にインスタンス化するこの設計では、管理サブネットと仮想マシン(テナント)サブネットの NIC とその IP アドレスが保持され、後続のポッドの更新で使用されます。この設計は、Unified Access Gateway インスタンスで使用されるパターンに合わせて調整されます。

ポッドのリソース グループにまだ 8 つの NIC がなく、ポッドがマニフェスト 3328 以降に更新されるようにスケジュール設定されている場合は、次のアクションを実行する必要があります。

• そのポッドを更新する前に、ポッドの管理サブネットの IP アドレスとプライマリ仮想マシン(テナント)サブネットの IP アドレスが、Horizon Cloud on Microsoft Azure が作成および構成したアイテムによってのみ取得されることを確認します

  • 管理サブネット - ポッド デプロイヤが作成および構成した Horizon Cloud on Microsoft Azure デプロイの特定の NIC のみが、ポッドの管理サブネットからの IP アドレスを使用する必要があります。これらの NIC は、ポッド マネージャの NIC とポッドの Unified Access Gateway インスタンスの NIC です。ポッドの管理サブネットには、ポッドがデプロイされていないリソースやアイテムを接続したり、ポッドから IP アドレスを取得したりすることはできません。
  • テナント サブネット - ポッド デプロイヤが作成および構成する、Horizon Cloud on Microsoft Azure デプロイの特定の NIC およびロード バランサのみが、ポッドのテナント サブネットからの IP アドレスを使用する必要があります。ポッドのテナント サブネットには、デプロイ以外のリソースやアイテムを接続したり、ポッドから IP アドレスを取得したりすることはできません。 『デプロイ ガイド』には、ポッドで使用されるサブネットには、ポッドのデプロイのリソース以外に追加のリソースを接続する必要があると正確に記載されています。手動でリソースを作成し、ポッドの管理サブネットまたはテナント サブネットからそのような追加のリソースに IP アドレスを割り当てた場合は、ポッドの更新を実行する前にそれらのリソースからそれらの IP アドレスを削除する必要があります。そうしないと、ポッドの更新に失敗し、Horizon Cloud のサポートが必要になります。

• ポッドを更新した後、更新前に設定したファイアウォール ルールに、ポッドのリソース グループ内のデプロイヤが作成した NIC によって予約されたすべての IP アドレスを追加してください

  ポッド マネージャ仮想マシンの NIC の IP アドレスからのトラフィックを制御する既存のファイアウォール ルールがある場合があります。ポッドの更新後も更新前と同様にトラフィック通信が機能するようにするには、ポッドのリソース グループ内の NIC によって予約された 8 つの IP アドレスすべてが更新後にファイアウォール ルールに反映されるようにする必要があります。

ポッドのメンテナンスに関する情報

デプロイされた Horizon Cloud ポッドを構成するソフトウェア コンポーネントのメンテナンスは、そのポッドによってプロビジョニングされた仮想デスクトップとアプリケーションの健全性と安定性を維持するために必要な操作です。Horizon Cloud - 追加のサービスの詳細 (KB87894) で説明されているように、ポッドに常駐し、制御プレーンからそのポッドにダウンロードされるソフトウェア コンポーネントについては、当社が責任を負います。このナレッジベースの記事に添付されている『 Horizon Cloud - 追加のサービスの詳細」 PDF には、次の情報が記載されています。

• ポッドにダウンロードされるソフトウェア コンポーネントの健全性を維持するための変更管理手順に関する私たち (Omnissa) の役割と責任。メンテナンス アクティビティには、ポッドのソフトウェア コンポーネントの更新が含まれます。
• 変更管理手順に関するお客様(ユーザー)の役割と責任(定期的または緊急のメンテナンスが必要な場合の当社への協力を含む)。

『Horizon Cloud - 追加のサービスの詳細』ドキュメントには、スケジュール設定されたメンテナンス、メンテナンス ウィンドウ、および緊急メンテナンスの定義が含まれています。詳細については、そのドキュメントを参照してください。このドキュメント ページの内容と『 Horizon Cloud - 追加のサービスの詳細 』ドキュメントの内容に相違がある場合は、『 Horizon Cloud - 追加のサービスの詳細 』ドキュメントが優先されます。

注意: ポッドを更新する前に、ポッドのイメージ仮想マシン、ファーム仮想マシン、および VDI デスクトップ仮想マシンのすべてに、ポッドで使用可能な最新のエージェントがあることを確認する必要があります。ポッドを更新する前に最新のエージェントに更新しないと、ポッドの更新後に互換性のないエージェント バージョンが実行され、ポッドがサポートされていない状態になる可能性があります。エージェントを更新する必要があるかどうかはどうすればわかりますか。コンソールで、イメージまたは割り当ての横に青いドットがあるかどうかを確認します。青いドットが表示されている場合は、ポッドを更新する前に、コンソールからすべての青いドットを消します。Horizon Cloud ポッドの更新 — エージェントの互換性とサポートを継続するための手順を参照してください。

ポッドの優先メンテナンス ウィンドウの指定

ポッドのメンテナンス アクティビティを特定の時間と曜日に開始したい場合は、コンソールを使用して、そのポッドの優先メンテナンス ウィンドウと呼ばれるものを指定します。[キャパシティ] ページから、ポッドの詳細ページの メンテナンス タブに移動します。優先メンテナンス時間 というラベルを探し、画面上のコントロールに従って、その日の曜日の名前と時間 (UTC) を選択します。表示されるシステム事前定義されたデフォルト値からのみ選択できます。

コンソールの各ポッドの詳細ページで、各ポッドの優先メンテナンス時間を個別に指定します。

メモ: コンソールで優先メンテナンス ウィンドウが指定されていないポッドは、都合の良いときにいつでもそのポッドのメンテナンスをスケジュール設定できると解釈されます。

システムは、コンソールで指定した曜日と時刻を読み取り、そのデータをスケジューリング アルゴリズムに組み込みます。新しいポッド マニフェストがクラウド プレーンのデフォルトとして設定されている場合、システムのスケジューラは、ポッド フリート内の各ポッドで更新が発生する可能性があると判断した実際の更新日時を計算します。システムは、そのポッドの メンテナンス タブで指定された優先メンテナンス開始時間に対応できるように最善を尽くしますが、特定の更新操作に対するこの優先メンテナンス開始時間に対応できる保証はありません。

本書の執筆時点では、システムのスケジューラはメンテナンス アクティビティの期間に 4 時間を割り当てます。一般的なポッドの更新にかかる時間は、この割り当てられた期間よりも短い時間です。

メンテナンス アラートと通知

システムは、特定のポッドの特定のメンテナンスが実行されるようにスケジュール設定された特定のカレンダー日時をシステムがスケジュール設定したときに、テナント環境の管理者にアラートと通知を送信します。これらのアラートと通知には、次のものが含まれます。

• コンソール内

  • コンソールの上部に常設バナーが表示されます。バナーの時間は、コンソールを表示するときの、ブラウザのタイム ゾーンに対するローカルなメンテナンス時間です。次のスクリーンショットは、ポッドの更新が 2020 年 7 月 7 日の米国東部時間午後 4 時に実行されるようにスケジューリングされている例です。表示 ボタンを使用して、クリックしてポッドの詳細ページに移動し、ポッドの メンテナンス タブでスケジュール設定されたメンテナンスの詳細を表示します。

    

  • ポッドの [監査ログ ] タブ、およびコンソールの アクティビティ > 監査ログ で、監査ログには、ポッドのアップグレードが Operations によってスケジュール設定されていることが示されます。監査ログの行には、ポッドの UUID が含まれます。

  • ポッドの メンテナンス タブの スケジュール設定されたメンテナンス セクションに、スケジュール設定されたメンテナンスに関する情報が表示されます。

• emails

  システムは、ポッドのメンテナンスに関する E メールをテナント環境の管理者(コンソールの [全般設定 ] ユーザー インターフェイスのアカウント領域で指定された管理者)に送信します。E メールには、システムが定期メンテナンスの特定のカレンダー日時を設定したときの E メールが含まれます。このような E メールの例には、スケジュールされた日時より前の日と週の定期的なリマインダ、メンテナンス アクティビティの開始時、完了時などがあります。

メモ: スケジュール設定されたメンテナンスの日時を再スケジュールする場合は、Horizon Cloud サポートにお問い合わせください。

ポッドのメンテナンスを実行する前のシステム事前チェック

ポッドにポッド更新エラーがあることを通知する E メールを受け取った場合、またはコンソールがポッドのポッド更新エラーを報告した場合は、状況を修正するためのアクションを実行する必要があります。この問題が発生した場合は、コンソールの画面上のガイダンスまたは E メールの指示に従ってください。このようなエラーの通常の解決方法には、通常、ポッドのサブスクリプションの Microsoft Azure ポータルで手順を実行する必要があります。一般的なポッド更新エラーの修正方法の詳細については、 Horizon Cloud ポッド — 一般的な事前チェックの失敗に対する対処法を参照してください。

これらの事前チェックの目的は何ですか? ポッド更新のメンテナンス アクティビティは、ポッドの Microsoft Azure サブスクリプションおよびリソース グループで実行されます。システムが特定のポッドで特定の更新のために特定のカレンダー日時をスケジュール設定する少し前に、システムは事前チェック操作を実行して、ポッドの更新の成功を妨げる条件が存在するかどうかを判断します。これらの事前チェックの 1 つの例として、システムは、Microsoft Azure サブスクリプションに更新の要件を満たすのに十分な適切な仮想マシン シリーズの vCore があるかどうかを確認します。事前チェックの 1 つが失敗し、条件を修正するためのアクションが必要な場合は、次のことが発生します。

• この事実を通知する E メールが送信されます。この通知メールには、エラーの修正に必要なアクションの詳細が含まれています。
• コンソールには、そのポッドの事前チェック エラーを修正するために必要なアクションを示す視覚的なアラートが表示されます。

重要: ポッドのアップグレード エラーに関する通知を受け取った場合は、指定されたアクションを実行して、適時にエラーを修正します。時間は非常に重要です。必要な時間内にこれらのエラーを解決するための操作に失敗すると、ポッドの更新プロセスを修正できなかったために、ポッドはサポートされていない状態になります。

ポッドの更新 - 概要の概要

メンテナンス アクティビティがポッドの新しいマニフェスト バージョンへの更新である場合、システムはポッドの現在のインフラストラクチャ コンポーネントを適切により高いソフトウェア マニフェスト レベルに移動します。インフラストラクチャ コンポーネントは主に、ポッド マネージャ仮想マシンと、ポッド用に構成されているすべての Unified Access Gateway 仮想マシンです。たとえば、ポッドの更新には、ポッド管理ソフトウェア、Unified Access Gateway ソフトウェア、またはその両方の更新を含めることができます。

ポッドの更新プロセスは、Blue-Green デプロイとして知られるソフトウェア業界の手法を模したものです。更新される既存のポッド コンポーネントは、Blue コンポーネントと見なされます。

ほとんどの点で、ポッドの更新は業界の Blue-Green パターンに従いますが、標準の Blue-Green 更新とは若干の違いがあります。ポッドの更新では、Green のビルドアウト内のすべての Blue リソースが 100% 複製されるわけではありません。Unified Access Gateway インスタンスの NIC など、既存の Blue リソースの一部は、新しい Green のビルドアウトで再利用されます。もう 1 つの違いは、ポッドの更新プロセスでは、既存のインスタンスのほかに新しいインスタンスが作成されると、新しいインスタンスがパワーオンされ、ポッドが新しいインスタンスへの移行を完了するまで実行されたままになることです。また、システムがポッドを Green のビルドアウトに移行し、ポッドが新しいマニフェスト バージョンで正常に実行されていることを検証した後、古い Blue の仮想マシンがリソース グループから削除されます。(通常、正規の Blue-Green 更新では、Green に切り替えた後も古い Blue アーティファクトが保持され、古いアーティファクトはアイドル状態のままになります。)

• ポッド マネージャ仮想マシンや Unified Access Gateway 仮想マシンなど、更新される既存のポッド コンポーネントは Blue コンポーネントと見なされます。
• サービスは、Microsoft Azure サブスクリプションのポッドに必要な Green のコンポーネントのセット(新しい Green のポッド マネージャ仮想マシン、Unified Access Gateway 仮想マシン、およびゲートウェイ コネクタ仮想マシン(外部ゲートウェイが専用の VNet にデプロイされている場合))を自動的に構築します。
• Green のビルドアウトで新しく作成されたコンポーネントは、Blue のコンポーネントと一緒に同じリソース グループに作成されます。
• Green のビルドアウトを作成するプロセスでは、ダウンタイムやデータ損失は発生しません。また、パラレル仮想マシンはポッドの操作に影響を与えません。
• Green セットはパラレル環境であり、Blue から Green に切り替わるスケジュール設定されたメンテナンス アクティビティの準備ができて待機しています。システムがポッドのメンテナンス アクティビティをスケジューリングする方法については、前のセクションで説明します。
• これらの Green の仮想マシンは、スケジュール設定されたメンテナンス アクティビティ(Blue から Green に移行するメンテナンス アクティビティ)が完了するまで起動され、実行されたままになります。
• Green のビルドアウトに移行するためのスケジュール設定されたメンテナンス アクティビティが完了し、ポッドが新しいインスタンスで正常に実行されると、システムはポッドのリソース グループから Blue の仮想マシンを削除します。Unified Access Gateway インスタンスの NIC など一部のリソースは、次回のポッドの更新で必要となる構成値を保持するために残ります。

メモ: Microsoft Azure ポータルおよびポッドのサブスクリプションにおいて、Green コンポーネントからのシステムのビルドに影響を与えたり、システムのポッドの更新およびメンテナンス プロセスに影響を与えるような変更を行わないようにする必要があります。

メンテナンス アクティビティの順序

この手順では、Green のビルドアウトへの移行について説明します。これは、ポッドの更新で Blue から Green に切り替わることです。

1. システムは、コンソールで指定したポッドの優先メンテナンス ウィンドウをチェックし、その情報をスケジューラのアルゴリズムで使用して、ポッドのメンテナンス アクティビティの実際のカレンダー日時をスケジューリングします。
2. システムのスケジューラは、メンテナンスが発生する実際のカレンダー日時を選択します。前のセクションで説明したように、コンソールにはスケジュール設定された日時が視覚的に表示され、テナントの管理者に E メールが送信されます。
3. 重要: スケジュール設定されたメンテナンスを実行する前に:

• ポッドのイメージ仮想マシン、ファーム仮想マシン、および VDI デスクトップ仮想マシンに、ポッドで使用可能な最新のエージェントがすべてあることを確認します。コンソールに青いドットが表示されている場合は、ポッドの更新が実行される前に、コンソールからすべての青いドットを消します。「Horizon Cloud ポッドの更新 — エージェントの互換性とサポートを継続するための手順」を参照してください。

• ポッドの仮想マシン (VM) で設定した Microsoft Azure の管理ロックをすべて削除します。hcs-podID( podID はポッドの ID 値)のような文字列を含む名前の仮想マシンは、ポッドに属します。Microsoft Azure には、Microsoft Azure ポータルを使用してリソースが変更されないようにロックする機能があります。このような管理ロックは、リソース グループ全体または個々のリソースに適用できます。ユーザーまたは組織がポッドの仮想マシンに管理ロックを適用している場合は、更新を実行する前にそれらのロックを削除する必要があります。そうしないと、更新プロセスが正常に完了しません。ポッドの ID 値は、[キャパシティ] ページのポッドの詳細ページで確認できます。 組織のニーズに応じて、スケジュール設定されたメンテナンス時間の前であればいつでも Horizon Cloud サポートに連絡して、別のスケジュール設定されたメンテナンス日をリクエストできます。

  重要: コンソールに表示されるスケジュール設定された時間は、ブラウザのタイム ゾーンに対してローカルです。

4. スケジュール設定されたメンテナンス時間に、サービスは更新アクティビティを開始します。外部と内部の両方の Unified Access Gateway 構成を持つポッドの場合、完全なプロセスは通常、開始から終了まで 20 分から 30 分かかります。

   メモ: プロセスが完了するまでの 20 分から 30 分の間、コンソールは更新中のポッドで管理タスクを実行できないようにします。たとえば、ポッド マネージャ アプライアンスがクラウド プレーンに更新の完了を通知するまで、ポッドの詳細ページの 編集 アクションをクリックしてそのポッドの特性を変更することはできません。

   • Unified Access Gateway アプライアンスのエンド ユーザー セッションと更新アクティビティについて

     エンドユーザー セッションのダウンタイムをほぼゼロにするため、システムは全体的なメンテナンス アクティビティ時間内で、アプライアンス上のエンドユーザー セッションの数を使用して、これらのアプライアンスの更新を完了するための最適なタイミングを決定します。

     完了時間は、アクティブなセッションで環境に接続されているユーザーの数が少ないときに発生するように最適化されています。

     このゼロに近い時間枠では、アクティブなセッションを持つエンド ユーザーのセッションは切断されます。数分後には、それらのユーザーは再接続できます。

     ファームと VDI デスクトップ割り当てのタイムアウト処理に ただちに オプションを設定したシナリオを除き、データが失われることはありません。このシナリオでは、タイムアウト処理に 直ちに実行 オプションを使用したアクティブなセッションを持つユーザーはすぐに切断され、その設定に従ってそれらのセッションもすぐにログオフされます。このような状況では、進行中のユーザーの作業はすべて失われます。このシナリオで処理中のエンド ユーザーのデータが失われるのを回避するには、メンテナンス アクティビティを開始する前に、ファームおよび VDI デスクトップ割り当ての 切断済みセッションのログオフ の設定を、ユーザーが作業を保存する時間を確保できる値に変更します。その後、更新が完了したら、設定を以前の状態に戻すことができます。

     また、ゼロに近い時間枠内で、ポッドから仮想デスクトップまたはリモート アプリケーションへのセッションをまだ接続していないエンド ユーザーが接続を試みると、プロセスが完了するまで接続できなくなります。

5. メンテナンス アクティビティが完了すると、システムは、Green のビルドアウトで再利用されない Blue コンポーネント(ポッド マネージャ仮想マシンや Unified Access Gateway 仮想マシンなど)など、不要になったコンポーネントを削除します。ポッド マネージャ インスタンスや Unified Access Gateway インスタンスの特定の NIC など、一部のアーティファクトは今後のメンテナンスに必要な構成値を保持するために残ります。

メンテナンス アクティビティの後

メンテナンス アクティビティが完了したら、ポッドで管理タスクを実行できます。ポッドで現在実行されているソフトウェアのバージョンを表示するには、 設定 > キャパシティ を選択し、ポッドをクリックしてそのサマリ ページを開きます。ページには、現在実行されているソフトウェア バージョンが表示されます。

• ポッドの更新後、既存のすべてのイメージ、ファーム、および VDI 割り当てのエージェントが使用可能な最新バージョンに更新されていることを確認します。これらの仮想マシンのインストール済みエージェントが更新されない場合、ポッドはサポートされていない構成になります。メンテナンス プロセスでは、インストールされているエージェントは自動的に更新されません。コンソールにイメージまたは割り当ての青いドットが表示されている場合は、エージェントを更新する必要があります。Horizon Cloud ポッドの更新 — エージェントの互換性とサポートを継続するための手順。
• この更新がマニフェスト 3328 より前のマニフェストからのものである場合は、ポッドを更新した後、ポッドのリソース グループ内にある、デプロイヤが作成した NIC のすべての IP アドレスをファイアウォール ルールに追加してください。ポッド マネージャ仮想マシンの NIC の IP アドレスからのトラフィックを制御する既存のファイアウォール ルールがある場合があります。このポッドの更新後、およびその後の更新後も更新前と同様にトラフィック通信が機能するようにするには、ポッドのリソース グループ内の NIC によって予約された 8 つの IP アドレスすべてが、この更新後にファイアウォール ルールに反映されるようにする必要があります。
• 構成済みの 2 要素認証サーバが同じ VNet にデプロイされている場合は、メンテナンス アクティビティ後に、新しい内部 Unified Access Gateway 仮想マシンの新しいプライベート IP アドレスを受け入れるように 2 要素認証サーバの設定を更新する必要があります。これは、ポッドでの最初の更新の 1 回限りの要件であり、そのポッドの将来の更新で繰り返す必要はありません。必要なゲートウェイ情報を使用した 2 要素認証システムの更新を参照してください。
• 2019 年 9 月の四半期ごとのサービス リリース以降、ポッド アーキテクチャが更新され、高可用性 (HA) を実現する機能がサポートされるようになりました。高可用性機能が有効になっていない場合でも、新しい HA 対応アーキテクチャでは、ポッドのマネージャ仮想マシンの前に Microsoft Azure ロード バランサが含まれています。ポッドをマニフェスト 1600 に更新した後、ポッドが直接接続用に構成されていた場合は、更新されたポッドの詳細ページに新たに表示されるポッド マネージャの Azure ロード バランサの IP アドレスをポイントするように DNS 設定を再マッピングする必要があります。DNS マッピングを更新するまでは、これらの直接ユーザー接続は引き続き機能しますが、アクティブなポッド マネージャ仮想マシンが停止した場合、それらの接続には HA 対応ポッドが提供するように設計されている高可用性フェイルオーバーはありません。この使用事例では、Access Connector アプライアンスを Microsoft Azure の Horizon Cloud ポッドと統合する場合など、ポッド マネージャ仮想マシンで SSL 証明書を直接構成するの説明に従って、ポッドの詳細ページに表示される ポッド マネージャ ロード バランサの IP アドレス フィールドの IP アドレスに FQDN をマッピングします 。 これにより、 Connector はポッド マネージャ仮想マシンへの接続を信頼できるようになります。ポッド マニフェスト 1600 より前のバージョンでは、その IP アドレスはテナント サブネット上のポッドのマネージャ仮想マシンの NIC に割り当てられたものでした。ポッド マニフェスト 1600 以降では、マッピングするポッドの IP アドレスは、ポッドのマネージャ仮想マシンに使用される Microsoft Azure ロード バランサのプライベート IP アドレスです。このリリースのマニフェスト バージョンに更新された既存のポッドの場合、マニフェスト 1493.1 以前のポッドのテナント アプライアンスの IP アドレスをポイントするように DNS 名を構成した場合は、更新されたポッドの詳細ページの ポッド マネージャのロード バランサの IP アドレス ラベルに表示される IP アドレスをポイントするように DNS 設定を再マッピングする必要があります。
• 2474.x より前のマニフェストでは、システムは登録済みの Active Directory サーバのクロック スキューをチェックしませんでした。2474.x では、クロック スキューのチェックが導入されました。登録済みの Active Directory サーバに時刻同期の問題 (clockSkew > 4 minutes) がある場合、ポッドが 2474.x 以降にアップグレードされると、そのポッドでこのシステム検証が開始されます。その結果、クロック スキューの問題を解決するまで Active Directory サーバの検出が失敗し始め、検出が失敗すると、そのポッドへのエンド ユーザー デスクトップ接続要求が影響を受けることがあります。