Disaster Recovery - アクティブ/パッシブ

以下のデプロイ モデルは、プライマリ データセンターの高可用性構成をセカンダリ データセンター (以下の図表で DR データセンターとしてマークされている) の Disaster Recovery オプションで拡張しています。プライマリ データセンターが再構築されるまで、一時的な使用のために設定されることを考えると、Disaster Recovery データセンターには少ない端末数が想定されます。このソリューションは、データセンター間のネットワーク接続が遅い場合に適用できます。

Figure 1. Disaster Recovery - Active/Passive

以下の条件を満たす必要があります。

• Always On 可用性グループ機能の 1 つ以上の端末が Disaster Recovery データセンターに物理的に存在していること。
• プライマリ データセンターと Disaster Recovery データセンター間がネットワーク接続されていること。
• [スナップショット] ツールを使用してプライマリ データセンターで作成されるスナップショットを格納するために、Disaster Recovery データセンターに外部ストレージが提供されていること。これらのスナップショットは、Disaster Recovery データセンターにある Elasticsearch インデックスの [復元] ツールを使用して読み取り、適用します。
• オートメーション パッケージ (アーティファクト) が NuGet 形式で外部ストレージに格納されていること。各 Orchestrator インスタンスは、NuGet.Packages.Path 構成設定を使用してこのストレージを指定します。
• SignalR をスケールアウトし、設定とユーザー権限をキャッシュするために、High Availability Add-on クラスターが提供されます。

• 外部ストレージがミラー化されていること。(任意。図表には含まれていません)

  注: 上記で述べたスナップショットと復元ツールは Elasticsearch が提供します。詳細についてはこちらをご覧ください。

Disaster Recovery を Orchestrator 用に構成する際は、以下の点を考慮してください。

• Orchestrator のデプロイ: Disaster Recovery 用の Orchestrator は、別のデータセンターにセカンダリ ノードとしてインストールする必要があります。
• HAA のインストール: High Availability Add-on がインストールされていて、CRDB モードが有効化されていることを確認します。
• NLB の動作: DR の実際のロジックは NLB レイヤーに実装されます。以下のことが必要です。

  • インフラストラクチャと DR の期待される動作を明確に理解している。

  • 提供されているダイアグラムを理想的なリファレンス アーキテクチャとして扱う。これを特定のニーズに基づいて調整できます。

• SQL リスナーの使用: Orchestrator で使用される SQL リスナーの構成と可用性は、DBA チームが扱います。Orchestrator の観点から見ると、ユーザーは SQL Server のアドレスを直接指定する代わりに、UiPath.Orchestrator.dll.config ファイル内の SQL リスナーのアドレスを参照するだけで済みます。