VMware は、Horizon Cloud ソフトウェア コンポーネントを定期的に更新して、新機能、サービスのサポートと弾力性の向上、ユーザー エクスペリエンスの改善、およびバグ修正を追加します。VMware では通常、インクラウド管理環境を週ベースでアップデートし、デプロイされたポッドで使用されるソフトウェア コンポーネントをおよそ四半期ベースでアップデートします。VMware がデプロイされたポッドで使用されているソフトウェア コンポーネントを更新すると、ポッドのソフトウェアのマニフェスト番号が大きくなります。ポッドのサービス性およびサポート業務に重要と思われる改善がある場合、VMware は、以前のマニフェスト バージョンの四半期の途中であっても、新しいマニフェストを利用できるようにします。システムのダウンタイムを引き起こすことなく、通常のアップデートプロセスは実行されます。

重要: ポッドが古い Linux コネクタ バージョン 2017.12.1.0 を使用してクラウドでホストされる Workspace ONE Access にすでに統合されている場合は、ポッドを更新する前にコネクタをサポートされている最新のバージョンに更新する必要があります。今回の Horizon Cloud リリースでサポートされているコネクタのバージョンを選択するには、 https://www.vmware.com/resources/compatibility/sim/interop_matrix.phpにある VMware 製品の相互運用性マトリックスを参照してください。次に、 VMware Workspace ONE Access ドキュメントにある、選択したコネクタ バージョンの手順に従って、既存のコネクタを更新します。コネクタの更新が完了したら、ポッドを更新します。

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

どのポッドに対して利用可能な更新があるかについては、[キャパシティ] ページを使用して確認できます。[設定] > [キャパシティ] に移動します。ポッドのステータス列には、緑のドットではなく保留中のアイコンが表示されます。ポッドのバージョン番号は固定テキストではなくハイパーリンクになり、そのバージョン番号にカーソルを合わせると、更新が利用可能であることを示すツールチップが表示されます。次のスクリーンショットは、前述の動作を示しています。


Horizon Cloud on Microsoft Azure:更新が利用可能なポッドと、ツールチップが表示される場所を指す緑色の矢印を示す [キャパシティ] ページのスクリーンショット。

ポッドの詳細ページでは、特定のポッドの更新の詳細を表示できます。更新が利用可能になると、更新を説明する画面上のメッセージが表示されます。


Horizon Cloud on Microsoft Azure:更新メッセージを示すポッドの詳細ページのスクリーンショット。

注: ポッドを以前のリリースからそれ以降に更新した後で、ポッドの公開済みイメージ、ファーム、および VDI デスクトップ割り当てのエージェント関連ソフトウェアを、更新されたポッド バージョンに付属するものと同じエージェント バージョン レベルに更新できます。エージェントに関連するアップデートは、ポッド自体のアップデートとは別のプロセスで行われます。ポッドの更新後にエージェントに関連するソフトウェアを更新する方法の手順については、 Horizon Cloud の RDSH イメージのエージェント ソフトウェアをアップデートする専用 VDI デスクトップ割り当て用のエージェント ソフトウェアを更新する、および フローティング VDI デスクトップ割り当てによって使用されるイメージのエージェント ソフトウェアを更新するを参照してください。

この Horizon Cloud ポッドの更新プロセスは、Blue-Green デプロイとして知られるソフトウェア業界の手法を模したものです。


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

既存の更新対象のポッド コンポーネントは、Blue コンポーネントと見なされます。VMware が新しいポッド マニフェストをリリースした直後に、VMware Horizon Service オペレーション チームはいくつかの事前チェックを実行し、新しいマニフェスト バージョンを使用できるようにお使いの Horizon Cloud 顧客アカウントを指定します。新しいマニフェスト バージョンが顧客アカウントで指定されている時点で、サービスは Microsoft Azure サブスクリプションのポッドに対して Green セットのコンポーネントを構築します。この Green セットは、既存の Blue コンポーネントの並行環境です。

注: すべてのポッド更新プロセスがソフトウェア業界の Blue-Green デプロイ パターンに正確に準拠しているわけではありません。たとえば、ポッドの更新プロセスでは、既存のインスタンスのほかに新しいインスタンスが作成されると、新しいインスタンスがパワーオンされ、ポッドが新しいインスタンスへの移行を完了するまで実行を続けます。また、新しいコンポーネントでポッドが正常に実行されていることをデプロイヤが検証した後、古い仮想マシンはアイドル状態を維持するのではなく、削除されます。

End-to-End のプロセス

VMware オペレーション チームがお使いの顧客アカウントを新しいマニフェスト バージョンを使用するように指定した時点から、End-to-End のシーケンスは次のようになります。

  1. サービスは、ポッドのサブスクリプション内にジャンプ ボックス リソース グループを作成し、ジャンプ ボックス仮想マシンをデプロイします。このジャンプ ボックス仮想マシンは、Green セットのコンポーネントの作成を調整します。
  2. Green セットのコンポーネントは、同じリソース グループ内の Blue コンポーネントとともに作成されます。ポッドの管理リソース グループでは、Green セットのポッド マネージャ仮想マシンと、NIC やディスクなどの関連するアーティファクトが作成されます。ポッドのゲートウェイ関連のリソース グループでは、Green セットの Unified Access Gateway 仮想マシンと関連するアーティファクトが作成されます。これらの Green の仮想マシンは起動されて、この全体的な End-to-End のシーケンスが完了するまで実行されたままになります。Green コンポーネントが正常に構築されて実行されるようになると、ジャンプ ボックス仮想マシンとそのリソース グループが削除されます。
    重要: このシーケンス ポイントからシーケンスの最後の手順まで、Blue 仮想マシンと Green 仮想マシンの両方の、重複した数の仮想マシンが実行されています。したがって、更新に移行できる状態になったとの通知バナーを確認次第すぐに、新しいポッド ソフトウェアに切り替えられるために、更新ワークフローを後ではなく一刻も早く実行するようにスケジューリングすることをお勧めします。

    このプロセスではダウンタイムは発生せず、パラレル仮想マシンはポッドの操作に影響を与えません。Microsoft Azure 環境でユーザーしか解決できないエラーが発生しない限り、この時点でのアクションは不要です。Green コンポーネントをデプロイするときにサービスに問題が発生した場合は、サービスはその問題の対処方法がユーザーの制御内であるかどうかを検出します。サービスは問題がユーザーによって対処できることを判断した場合、管理コンソールに通知が表示されます。対処方法はユーザーが管理し、VMware では解決できないため、更新エラーの通知を受け取った場合は、アクションを完了してエラーを解決し、VMware サポートに連絡してポッドの更新プロセスを続行する必要があります。対処できる問題のタイプの詳細については、Microsoft Azure で Horizon Cloud ポッドをアップグレードするために必要なコアと一般的なポッド更新エラーの対処法を参照してください。サービスは問題が VMware オペレーション チームによって解決できることを判断した場合、VMware オペレーション チームにアラート通知を送信します。VMware オペレーション チームはユーザーからのアクションなしで問題を解決します。

  3. ポッドの詳細ページでは、移行可能な更新があることを示すバナーが表示され、切り替えを実行するための日時をスケジューリングできます。
    Horizon Cloud on Microsoft Azure:更新メッセージを示すポッドの詳細ページのスクリーンショット。

  4. 次に、更新をスケジューリングして、現在の Blue の仮想マシンおよびコンポーネントの使用から Green の仮想マシンおよびコンポーネントの使用へとポッドを移行します。[更新] > [スケジュールの更新] の順に選択して、ポッドの [サマリ] ページからこの更新をスケジューリングします。サービスが新しい Green コンポーネントを使用するようにポッドを切り替える日時を設定します。サービスは、ポッド内のスケジューラを構成するためにジャンプ ボックス仮想マシンをデプロイし、スケジューリングされた日時までジャンプ ボックス仮想マシンを削除します。
    重要: 更新を実行する前に、ポッドの仮想マシン (VM) で設定した Microsoft Azure の管理ロックがあればすべて削除します。名前に vmw-hcs- podID のような部分( podID はポッドの ID 値)を持つすべての仮想マシンはポッドに属します。Microsoft Azure では、Microsoft Azure ポータルを使用してリソースが変更されないようにロックすることができます。このような管理ロックは、リソース グループ全体または個々のリソースに適用できます。ユーザーまたは組織がポッドの仮想マシンに管理ロックを適用した場合、更新を実行する前にそれらのロックを削除する必要があります。そうしないと、更新プロセスは正常に完了しません。ポッドの ID 値は、[キャパシティ] ページからアクセスできるポッドの詳細ページで確認できます。

    アップデートが発生するのに都合の良い時刻を決定します。通常は、アップデート自体、または既存のバージョンから新しいバージョンへの移行には、10 分ほどかかります。ベスト プラクティスとして、環境が最もビジーでないときにアップデートをスケジューリングします。更新がスケジューリングされると、コンソールの一番上のバナーにはスケジューリングされた時間が表示されます。組織のニーズによって要求される場合、スケジュール設定された時刻の前であればいつでもアップデート時刻のスケジュールを再設定することができます。

    重要: ポッドの詳細ページで更新をスケジュールすると、日付と時刻の入力を求められます。これは、ブラウザのタイム ゾーンでのローカルの時間です。

    Horizon Cloud on Microsoft Azure:上部バナーにスケジューリングされたポッド更新の時間が示されている [キャパシティ] ページのスクリーンショット。

  5. 選択した日時に、サービスはジャンプ ボックス仮想マシンを再びデプロイして、Green 仮想マシンとコンポーネントを使用するようにポッドの切り替えを調整します。Green コンポーネントは、現在の Blue コンポーネントになります。このプロセスは完了するのに 5 〜 15 分かかり、外部と内部の両方の Unified Access Gateway 構成を持つポッドでは時間がかかります。このプロセスは、既存の更新対象のポッドのインフラストラクチャから新しいインフラストラクチャにデータと構成を移行します。

    移行中には、次の制限が適用されます。

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

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

  6. すべてが新しい環境に移行され、新しいインスタンスでポッドが正常に実行されると、システムは、ポッドのリソース グループから Blue 仮想マシンを削除し、ジャンプ ボックス リソース グループとそのコンテンツを削除します。以前の Unified Access Gateway インスタンスの NIC など、一部のアーティファクトは次回のポッドの更新に必要な構成の値を保持するために残ります。

End-to-End のプロセスの完了後

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

更新後

重要: 構成済みの Radius サーバが同じ VNet にデプロイされている場合は、新しいインフラストラクチャ要素への移行後に、新しい内部 Unified Access Gateway 仮想マシンの新しいプライベート IP アドレスを受け入れるように Radius サーバ側の設定を更新する必要があります。これは、ポッドでの最初の更新に対する 1 回限りの要件であり、そのポッドの将来の更新で繰り返す必要はありません。
重要: 2019 年 9 月の四半期サービス リリース以降、ポッド アーキテクチャは、高可用性 (HA) を保有する機能をサポートするように更新されています。高可用性機能が有効になっていなくても、HA 対応の新しいアーキテクチャにはポッドのマネージャ仮想マシンの前に Microsoft Azure ロード バランサが含まれています。ポッドをマニフェスト 1600 に更新した後、ポッドが直接接続用に構成されていた場合は、更新されたポッドの詳細ページに新たに表示されるポッド マネージャの Azure ロード バランサの IP アドレスをポイントするように、DNS 設定を再マッピングする必要があります。DNS マッピングを更新するまで、これらの直接ユーザー接続は機能しますが、アクティブなブローカ マネージャ仮想マシンが停止した場合、HA 対応ポッドのための高可用性フェイルオーバーは実行されません。このユースケースでは、 Horizon Cloud ポッドのマネージャ仮想マシンでの SSL 証明書の構成の説明に従って、ポッドの詳細ページに表示される、 [ポッド マネージャのロード バランサの IP アドレス] フィールドの IP アドレスに FQDN をマッピングします。ポッド マニフェスト 1600 以前は、その IP アドレスはテナント サブネット上のポッドのマネージャ仮想マシンの NIC に割り当てられたものでした。ポッド マニフェスト 1600 以降では、マッピングするポッドの IP アドレスは、ポッドのマネージャ仮想マシンに使用される Microsoft Azure ロード バランサのプライベート IP アドレスになります。このリリースのマニフェスト バージョンに更新された既存のポッドの場合、マニフェスト 1493.1 以前のポッドのテナント アプライアンスの IP アドレスをポイントするように DNS 名を構成した場合は、更新したポッドの詳細ページの [ポッド マネージャのロード バランサの IP アドレス] ラベルに表示される IP アドレスをポイントするように DNS 設定を再マッピングする必要があります。