サイドバイサイド アップグレードを実行する

Automation Suite のサイドバイサイド アップグレードを使用すると、インプレース アップグレードではなく、並列環境を使用して安全にアップグレード操作を実行できます。

この方法を使用すると、管理者は新しいデプロイを確認した後に、古い Automation Suite クラスター (ブルー デプロイなど) から新しい Automation Suite クラスター (グリーン デプロイなど) にトラフィックを切り替えることができます。問題が検出された場合は、古いデプロイに即時ロールバックできます。

サイドバイサイド アップグレードを実行する場合、2 つの並列クラスターは 1 つのライセンスを共有します。

要件

• AI Center が有効化されている場合は、 CUDA の要件を満たしていることを確認してください。
• 選択したモデルに応じたハードウェア要件:
  • サイドバイサイド アップグレード (ターゲット クラスターのサイズが同じ) - ソース環境とターゲット環境の両方が、同じ ハードウェア要件とソフトウェア要件を満たしている必要があります。
  • サイドバイサイド アップグレード (シングル ノードの起動) - シングル ノードのターゲット クラスターをセットアップしてから、スケール アップできます。選択した製品と使用状況の詳細に基づいて、 Automation Suite Install Sizing Calculator (インストール サイジング計算ツール ) が提案するハードウェア要件を満たしていることを確認します。
• ソフトウェア要件: ソース環境とターゲット環境の両方が、同じ ハードウェア要件とソフトウェア要件を満たしている必要があります。

データ移行と責任

データ	アップグレードのメカニズム
	ステータス	責任
SQL	保持	顧客 (Customer)
fqdn	保持、任意 新しいクラスターには新しい FQDN を選択する必要があります。オプションとして、必要に応じて以前の FQDN に戻すことができます。	顧客 (Customer)
オンデマンド バンドル	移行されない スクリプトを実行して、どのバンドルがクラスター内にあるかを確認します。手動でシーディングする必要があります。	顧客 (Customer)
証明書	移行されない 新しいクラスターのインストールの一部として証明書を提供する必要があります。	顧客 (Customer)
クラスターの構成	移行されない 元のソース クラスターから cluster_config.json を生成して、同じサービスを新しいクラスター インストールにマップする必要があります。	顧客 (Customer)
ユーザーが作成したカスタム アラートとダッシュボード	移行されない アップグレード後にカスタム アラートとダッシュボードを再構成する必要があります。	顧客 (Customer)
アプリケーション ログ/ユーザーが作成した Prometheus ストリーミング設定	移行されない アプリケーション ログと Prometheus ストリーミングを再構成する必要があります。	顧客 (Customer)
動的なワークロード	アプリケーションによって異なる AI Center のトレーニング ジョブは失われ、スキルは保持されます。	スキル (アップグレード後にスクリプトを実行する必要があります): UiPath® トレーニング ジョブ: 顧客
Object Store	保持	クラスター内の ObjectStore (Ceph): UiPath® 外部 ObjectStore: 顧客
Insights	保持	UiPath®
MongoDB データ	保持 MongoDB データがターゲット SQL に移動されます。	UiPath®
RabbitMQ	不要	UiPath®
監視 (データ)	不要 監視データは、新しいクラスターには適用されません。	N/A
Docker レジストリ	不要 クラスター内の Docker レジストリをインストールするか、外部の Docker レジストリを使用する必要があります。	N/A

プロセスの概要

#	アップグレード プロセスの手順
1	新しいクラスターを準備します。 cluster_config.json ファイルを準備します。 新しいクラスターをインストールします (インフラストラクチャと、クラスター内の ObjectStore (該当する場合) のみ)。 追加の CA 証明書を構成します。
2	データを新しいクラスターに移行します。 オフライン アップグレード イメージで Docker レジストリをハイドレートします。 クラスターをメンテナンス モードにします。 ソース クラスター データベースを複製します。 ソース クラスターでデータ移行スクリプトを実行します。 外部 ObjectStore を構成した場合は、ObjectStore のバケットを複製します。
3	アップグレードを完了します。 複製されたデータベースとバケットを指し示すように cluster_config.json ファイルを編集します。 ターゲット クラスターでインストーラーを実行します。 インストール時に証明書を指定しなかった場合は、インストール後に更新してください。 ターゲット クラスターが期待どおりに動作することを検証します。 サイドバイサイド アップグレード (ターゲット クラスターのサイズが同じ) を選択した場合は、必要に応じて、ターゲット クラスターの FQDN を更新してソース クラスターの FQDN と同じにすることができます。または、新しい FQDN を使用することもできます。 サイドバイサイド アップグレード (シングルノード起動) を選択した場合は、後で FQDN を更新できます。 ターゲット クラスターでバックアップを有効化します。
4	ターゲット クラスターのスケーリング - サイドバイサイド アップグレード (シングル ノード起動) を選択した場合にのみ適用されます。 ソース クラスターのバックアップを作成します (推奨)。 ソース クラスターに類似したサーバー ノードとエージェント ノードを追加します。 cluster_config.json ファイルを編集します。 インストーラーを再実行して、クラスターを HA セットアップにスケールします。 必要に応じて、ターゲット クラスターの FQDN を更新してソース クラスターの FQDN と同じにします。または、新しい FQDN を使用することもできます。

サイドバイサイド アップグレード モデル

サイドバイサイド アップグレード用に 2 つのモデルを提供しています。

1. サイドバイサイド アップグレード (同じサイズのターゲット クラスター):
   • ターゲット クラスターにソース クラスターと同じハードウェア リソースが必要です。
   • 一度トラフィックの準備が整いました。
     • データ移行が完了しました。
     • サニティ チェックに成功しました。
2. サイドバイサイド アップグレード (シングルノードで起動):
   • シングルノードの設定から開始し、HA 設定までスケールアップします。これにより、サイドバイサイド アップグレードに必要な初期ハードウェア要件が軽減されます。
   • シングルノード設定のハードウェアは、シングルノード設定の要件算出ツールの推奨事項を満たす必要があります。
   • スケーリングの場合:
     • ソース クラスターのノードを使用停止にして、ターゲット クラスターに追加できます。
   • 一度トラフィックの準備が整いました。
     • データ移行が完了しました。
     • クラスターはマルチノードにスケーリングされます。
     • サニティ チェックに成功しました。

注:

Automation Suite 2024.10.0 および 2024.10.1 のクラスター内レジストリを使用したオフライン環境でのクラスターのスケーリングには、既知の問題があります。

2 つのモデルの比較は下表のとおりです。

	サイドバイサイド アップグレード (同じサイズのターゲット クラスター)	サイドバイサイド アップグレード (シングルノード起動)
ハードウェア要件	ソース クラスターとターゲット クラスターの両方に同一のハードウェアが必要です。	最小限のハードウェアから開始し、必要に応じてスケールアップします。
ダウンタイム	完全に冗長化されたターゲット環境によるダウンタイムの最小化	ノードのスケーリング操作によるダウンタイムの増加。
ソース クラスターへの影響	影響はありません。	ソース ノードは使用停止にして、ターゲット クラスターに参加させることができます。
ロールバック プロセス	ソースは変更されないため、単純なロールバックが可能です。	ターゲット クラスターでスケーリング操作が失敗した場合、ロールバックではノードをソース クラスターに再統合する必要があります。
コストへの影響	インフラストラクチャの重複によるコストの増加。	初期ハードウェア要件の低減によるコスト削減。