DR の構成要件

Automation Anywhere で災害復旧が有効なデータ センターを設定する場合は、記載された条件が満たされていることを確認します。

災害復旧の構成要件

  • 非同期レプリケーション - すべてのサポート サービスについて、同期レプリケーションではなく非同期レプリケーションを DR サイト間で設定します。これにより、オフサイト レプリケーションはプライマリ サイトのパフォーマンスに影響しません。

  • AD ドメイン—プライマリ サイトとバックアップ サイトの両方で同じ Active Directory ドメインを使用します。

  • サイト ドメイン—バックアップ サイトの Control Room およびデバイスマシンは、プライマリ サイトの Control Room およびマシンと同じドメインのメンバーであることを確認します。

  • ライセンス—ユーザーがバックアップ サイトのデバイスにログインできるように、フローティング ライセンスをユーザーに割り当てます。

  • バックアップサイトサービス—バックアップサイトの Control Room サービスを、必要になるまでシャットダウンさせます。

  • サイト設定—プライマリ サイトとバックアップ サイトのマシンの仕様と設定が同じであることを確認します。これには、Control RoomBot Runner、関連デバイス、およびログイン資格情報が含まれます。これは、停止中に同等レベルのサービスを確保するために必要です。

    注: スケジュールは UTC で保存されるため、サーバーの物理的な場所やタイムゾーンの設定に関係なく同時にスケジュールが実行されます。
  • アクティベーション ユーティリティ - DR バックアップ サイトの各 Bot Runner で、Automation Anywhere Bot アクティベーション ユーティリティを実行します。
  • web.config ファイル - DR セカンダリ (バックアップ) サイトで、Control Room 構成ファイルの web.config に構成パラメーターを追加します。パラメーターを使用して、DR バックアップ サイト用の Control Room を指定します。
  • バージョン管理—災害発生時には、プライマリ (本番) サイトとセカンダリ (バックアップ) サイトの両方の DR サイトでバージョン管理システム (VCS) を無効にします。

追加の考慮事項

  • スケジュールを作成したら、必ず UTC 形式でデータベースに保存します。これにより、スケジュールは指定したとおりに本番環境で実行されます。
  • リカバリー サイトの Bot Runner は、マッピング先である本番サイトの Bot Runner とまったく同じ設定にします。
  • ユーティリティが実行されているフォルダーに対するユーザー アクセス権を有効にします。設定ファイルの確認 –タイム スタンプを参照して、ClientConfiguration.json がアプリケーション パスに作成されていることを確認します。
  • ログと .dat ファイルが C:\Users\Public\Documents\Automation Anywhere Client Files にあることを確認します。

データベース レプリケーションの詳細

災害復旧用のデータベース レプリケーション設定は、高可用性設定の拡張です。この設定では、Always On 可用性グループを使用する必要があります。

  • プライマリ サイトのレプリカを同期-コミットモードに設定します。
  • 復旧サイトのレプリカを [非同期 - コミット] モードに設定します。[非同期 - コミット] モードの場合、データ センター間の遅延と信頼性はプライマリ サイトのパフォーマンスと可用性に影響しません。
  • 復旧フェールオーバーがトリガーされるまでは、データベース サービスを提供するように復旧サイトのレプリカを設定しないでください。

障害モード

非同期レプリケーションでは、障害が発生する前にプライマリ サイトで発生したトランザクションが復旧サイトのレプリカに到達しない可能性があります。

注: Automation Anywhere ソリューションだけでなく、非同期レプリケーションを使用するすべての DR 自動化アプリケーション ソリューションで、最新のトランザクションが失われる可能性があります。

導入は、地理的に離れた場所間で厳密に一致する必要があります。遅延が大きいレプリカ間で [同期 - コミット] を設定すると、Control Room のすべての操作に悪影響が生じます。

障害の発生時に同じ作業項目が 2 回処理されないように、デバイスへの配信待ちになっている一部の作業項目がエラー状態に設定されます。これにより、作業項目を手動で確認し、必要に応じて処理準備完了または完了済みとしてマークできます。