システムのメンテナンス アクティビティには、ポッドのソフトウェア コンポーネントの自動更新が含まれており、サービスのサポート性と回復性の修正と改善だけでなく、新機能も含まれます。既存のポッドを新しいマニフェストに更新するメンテナンス アクティビティは、クラウド プレーンからシステムによって開始され、システムによって決定された日時に実行されます。このようなシステム メンテナンス アクティビティを特定の時間と曜日に開始することを希望する場合は、コンソールを使用して、各ポッドの優先メンテナンス ウィンドウを指定します。コンソールで優先メンテナンス ウィンドウが指定されていないポッドは、VMware がいつでも都合の良い時にそのポッドのメンテナンスをスケジューリングできると解釈されます。

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

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

デプロイされた Horizon Cloud ポッドを構成する VMware ソフトウェア コンポーネントのメンテナンスは、そのポッドによってプロビジョニングされた仮想デスクトップおよびアプリケーションの正常性と安定性を維持するために必要な操作です。Horizon Service Description PDFで説明したように、VMware は、ポッドに常駐し、制御プレーンからそのポッドにダウンロードされるソフトウェア コンポーネントを担当します。この『Horizon Service Description』ドキュメントでは、次の内容についても説明します。

  • ポッドにダウンロードされるソフトウェア コンポーネントの正常性を維持するための変更管理手順に関する VMware の役割と責任。メンテナンス アクティビティには、ポッドのソフトウェア コンポーネントの更新が含まれます。
  • スケジュールされたメンテナンスや緊急メンテナンスが必要な場合の VMware との連携を含めた変更管理手順に関するユーザーの役割と責任。

Horizon Service Description』ドキュメントには、スケジュールされたメンテナンス、メンテナンス ウィンドウ、および緊急メンテナンスの定義が含まれます。これらの詳細については、該当ドキュメントを参照してください。本書のページの内容と『Horizon Service Description』ドキュメントの内容に不一致がある場合は、『Horizon Service Description』ドキュメントが優先されます。

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

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

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

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

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

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

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

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

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

コンソール内
  • コンソールの上部に表示されるパーシステント バナー。バナーの時間は、コンソールを表示しているときの、ブラウザのタイムゾーンに対するローカルなメンテナンス時間です。次のスクリーンショットは、2020 年 7 月 7 日の米国東部時間午後 4 時にポッドの更新がスケジューリングされている例です。[表示] ボタンを使用し、クリックしてポッドの詳細ページに移動し、ポッドの [メンテナンス] タブでスケジューリングされたメンテナンスの詳細を確認します。
    ポッドのスケジューリングされたメンテナンスに関する情報を提供するコンソールのバナーのスクリーン ショットの例
  • ポッドの [監査ログ] タブおよびコンソールの [アクティビティ] > [監査ログ] で、監査ログにポッドのアップグレードが VMware Operations によってスケジューリングされていることが示されます。監査ログ行には、ポッドの UUID が含まれます。
  • ポッドの [メンテナンス] タブで、[スケジューリングされたメンテナンス] セクションに、スケジューリングされたメンテナンスに関する情報が表示されます。
E メール
システムは、ポッドのメンテナンスに関する E メールをテナント環境の管理者(コンソールの [全般設定] > [My VMware アカウント] 設定で指定された管理者)に送信します。E メールには、システムが定期メンテナンスの特定のカレンダー日時を設定したときの E メールが含まれます。このような E メールの例には、スケジューリングされた日時より前の日と週の定期的なリマインダ、メンテナンス アクティビティの開始時、および完了時が含まれます。
注: スケジューリングされたメンテナンスの日時を再スケジューリングする場合は、VMware のサポートにお問い合わせください。

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

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

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

  • この事実についてのアラートと、エラーの修正に必要なアクションの詳細を記載した通知 E メールが送信されます。
  • コンソールには、そのポッドの事前チェック エラーを修正するために必要なアクションが視覚的アラートで表示されます。
重要: ポッドのアップグレード エラーに関する通知を受け取った場合は、指定したアクションを実行して、ただちにエラーを修正します。時間は重要な問題です。VMware で必要な時間内にこれらのエラーを解決するための操作に失敗すると、ポッドの更新プロセスを修正できなかったために、ポッドがサポートされていない状態になります。

ポッドの更新:概要

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

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


Blue-Green 更新プロセスの概念図

ほとんどの場合、ポッドの更新は業界の 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 のビルドアウトがオーケストレーションされます。この一時的なジャンプ ボックス仮想マシンとそのリソース グループは、Green のパラレル環境が正常に構築された後に削除されます。
  • 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 の管理ロックがあればすべて削除します。名前に vmw-hcs-podID のような部分(podID はポッドの ID 値)を持つすべての仮想マシンはポッドに属します。Microsoft Azure では、Microsoft Azure ポータルを使用してリソースが変更されないようにロックすることができます。このような管理ロックは、リソース グループ全体または個々のリソースに適用できます。ユーザーまたは組織がポッドの仮想マシンに管理ロックを適用した場合、更新を実行する前にそれらのロックを削除する必要があります。そうしないと、更新プロセスは正常に完了しません。ポッドの ID 値は、[キャパシティ] ページからアクセスできるポッドの詳細ページで確認できます。

    組織のニーズに応じて、スケジュールリングされたメンテナンス時間より前であればいつでも VMware のサポートに連絡して、別のスケジューリングされたメンテナンス日をリクエストできます。

    重要: コンソールに表示されるスケジューリングされた時間は、ブラウザのタイム ゾーンに対してローカルです。
  4. スケジューリングされたメンテナンス時に、サービスは再度ジャンプ ボックス仮想マシンを展開してメンテナンス アクティビティをオーケストレーションします。外部と内部の両方の Unified Access Gateway 構成を持つポッドの場合、プロセスが完了するまでに通常最大 20 分かかりますが、システムは、正常な結果を保証するために、全体的なメンテナンス アクティビティに 4 時間を割り当てます。

    メンテナンス アクティビティ実行中には、次の制限が適用されます。

    • 更新が行われているポッド上で、管理タスクを実行することができません。
    • 更新されているポッドによってサービスが提供される、仮想デスクトップまたはリモート アプリケーションにセッションを接続していないエンド ユーザーは、接続を試みると失敗します。
    • 更新されているポッドによってサービスが提供されるセッションを接続しているエンド ユーザーに対して、それらのアクティブなセッションが切断されることになります。メンテナンスが完了した後に、これらのユーザーは再接続できます。ファームと VDI デスクトップ割り当てのタイムアウト処理に [ただちに] オプションを使用していない限り、データは失われません。
    注意: ファームおよび VDI デスクトップ割り当てによって提供されるデスクトップまたはリモート アプリケーションに接続されたセッションを持つユーザーは、 [切断済みセッションのログオフ][ただちに] に設定されている場合はすぐに切断され、切断されたセッションもすぐにログオフされます。このような状況では、進行中のユーザーの作業はすべて失われます。

    このシナリオで進行中のエンド ユーザーのデータが失われるのを回避するには、メンテナンスを開始する前に、ファームおよび VDI デスクトップ割り当ての [切断済みセッションのログオフ] の設定を、ユーザーが作業を保存する時間を確保できる値に変更します。更新が完了したら、設定を元の値に戻すことができます。

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

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

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

注目: ポッドの更新後、既存のすべてのイメージ、ファーム、および VDI 割り当てのエージェントが利用可能な最新バージョンに更新されていることを確認します。これらの仮想マシンにインストールされているエージェントが更新されない場合、ポッドはサポートされていない構成になります。メンテナンス プロセスでは、それらのインストールされているエージェントは自動的に更新されません。コンソールにイメージまたは割り当てに対して青いドットが表示されている場合は、エージェントを更新する必要があります。 Horizon Cloud ポッドの更新:エージェントの互換性とサポートを継続するための手順
重要: 構成済みの Radius サーバが同じ VNet にデプロイされている場合は、メンテナンス アックティビティへの移行後に、新しい内部 Unified Access Gateway 仮想マシンの新しいプライベート IP アドレスを受け入れるように Radius サーバ側の設定を更新する必要があります。これは、ポッドでの最初の更新に対する 1 回限りの要件であり、そのポッドの将来の更新で繰り返す必要はありません。
重要: 2019 年 9 月の四半期サービス リリース以降、ポッド アーキテクチャは、高可用性 (HA) を保有する機能をサポートするように更新されています。高可用性機能が有効になっていなくても、HA 対応の新しいアーキテクチャにはポッドのマネージャ仮想マシンの前に Microsoft Azure ロード バランサが含まれています。ポッドをマニフェスト 1600 に更新した後、ポッドが直接接続用に構成されていた場合は、更新されたポッドの詳細ページに新たに表示されるポッド マネージャの Azure ロード バランサの IP アドレスをポイントするように、DNS 設定を再マッピングする必要があります。DNS マッピングを更新するまでは、これらの直接ユーザー接続は引き続き機能しますが、アクティブなポッド マネージャ仮想マシンがダウンした場合に、これらの接続では HA 対応ポッドが提供するように設計されている高可用性フェイルオーバーは行われません。このユースケースでは、 コネクタがポッド マネージャ仮想マシンへの接続を信頼できるように、Workspace ONE Access コネクタ アプライアンスを Microsoft Azure の Horizon Cloud ポッドと統合する場合には、ポッド マネージャ仮想マシンで SSL 証明書を直接構成します。の説明に従って、ポッドの詳細ページに表示される、 [ポッド マネージャのロード バランサの IP アドレス] フィールドの IP アドレスに FQDN をマッピングします。ポッド マニフェスト 1600 以前は、その IP アドレスはテナント サブネット上のポッドのマネージャ仮想マシンの NIC に割り当てられたものでした。ポッド マニフェスト 1600 以降では、マッピングするポッドの IP アドレスは、ポッドのマネージャ仮想マシンに使用される Microsoft Azure ロード バランサのプライベート IP アドレスになります。このリリースのマニフェスト バージョンに更新された既存のポッドの場合、マニフェスト 1493.1 以前のポッドのテナント アプライアンスの IP アドレスをポイントするように DNS 名を構成した場合は、更新したポッドの詳細ページの [ポッド マネージャのロード バランサの IP アドレス] ラベルに表示される IP アドレスをポイントするように DNS 設定を再マッピングする必要があります。