22 ディザスタ・リカバリの構成
この章の内容は次のとおりです。
- 一般的なディザスタ・リカバリ・プロセス
一般的なディザスタ・リカバリ・プロセスには、rsyncを使用したサイト間のデータのコピー、Oracle Data Guardを使用したスタンバイ・データベースの作成、クラスタ・アーティファクトのバックアップとリストア、永続ボリュームの同期などがあります。 - Oracle Unified Directoryのディザスタ・リカバリの構成
Oracle Unified Directory (OUD)のディザスタ・リカバリは、アクティブ/パッシブ・ソリューションです。現在は、dsreplicationコマンドを使用して、リモート・レプリカを設定することはできません。 - Oracle Access Managerのディザスタ・リカバリの構成
Oracle Access Manager (OAM)のディザスタ・リカバリは、アクティブ/パッシブ・ソリューションです。 - Oracle Identity Governanceのディザスタ・リカバリの構成
Oracle Identity Governance (OIG)のディザスタ・リカバリは、アクティブ/パッシブ・ソリューションです。 - Oracle Identity Role Intelligenceのディザスタ・リカバリの構成
Oracle Identity Role Intelligence (OIRI)のディザスタ・リカバリは、アクティブ/パッシブ・ソリューションです。 - Oracle Advanced Authenticationのディザスタ・リカバリの構成
Oracle Advanced Authentication (OAA)のディザスタ・リカバリは、アクティブ/パッシブ・ソリューションです。
上位トピック: 「エンタープライズ・ドメインの構成」
一般的なディザスタ・リカバリ・プロセス
一般的なディザスタ・リカバリ・プロセスには、rsyncを使用したサイト間のデータのコピー、Oracle Data Guardを使用したスタンバイ・データベースの作成、クラスタ・アーティファクトのバックアップとリストア、永続ボリュームの同期などがあります。
次に、一般的なディザスタ・リカバリ・プロセスのリストを示します:
- rsyncを使用したコンテナの作成
- Data Guardデータベースの作成
- Kubernetesオブジェクトのバック・アップとリストア
- 永続ボリュームを同期するKubernetes CronJobの作成
- 永続ボリューム要求の作成
- DR ConfigMapの作成
- バックアップ/リストア・ジョブの作成
親トピック: ディザスタ・リカバリの構成
rsyncを使用したコンテナの作成
- ハードウェア・レプリケーション - クラウド・ベースのファイル・システム・レプリケーションのディスク・ベース・レプリケーションを使用します。
- ソフトウェア・レプリケーション - ソフトウェア・ツールを使用して、ファイル・システムを手動でレプリケートします。ソフトウェア・レプリケーションを実行するためのツールで、最も広く普及している効率的なものの1つにrsyncがあります。
この項では、Kubernetesクラスタ内で実行できるrsyncコマンドを使用して、軽量のコンテナを作成する方法について説明します。このコンテナは、Kubernetes CronJobを使用して起動できます。
rsyncを基礎となるワーカー・ノードでCronJobとして実行することは可能ですが、これにより、外部依存関係ができます。これを実現するもう1つの方法は、rsync操作を実行するクラスタ内で実行されるポッドを作成することです。
このジョブにより、アプリケーションのディザスタ・リカバリ・プロセスが、Kubernetesクラスタの一部として実行されます。CronJobsには、rsyncコマンドを含むコンテナ・イメージが必要です。2つの主要なLinuxコンテナ・イメージであるAlpineとBusyboxには、デフォルトではrsyncコマンドが含まれていません。ただし、拡張してそのコマンドを含めることが可能です。次のステップを実行すると、rsyncを含むAlpineコンテナに基づいてイメージを作成できます。
次のステップでは、rsyncユーティリティも含むAlpineに基づいて、コンテナ・イメージを作成する方法を説明します。これらのステップには、PodmanまたはDockerを使用したランタイム環境が必要で、DockerHubアカウントにログインし、リポジトリ・イメージにアクセスできるようにしておく必要があります。
親トピック: 一般的なディザスタ・リカバリ・プロセス
Data Guardデータベースの作成
rsyncを使用すると、あるサイトからKubernetesの外部にデータをコピーできます。ただし、データをコピーするより効率的な方法は、Kubernetes CronJobを作成することです。ディザスタ・リカバリを実行する際は、アプリケーションをスタンバイ・サイトにデプロイした後に、既存のデータベースを削除し、Oracle Data Guardを使用してスタンバイ・データベースを作成する必要があります。
Oracle Cloud以外をベースとしたデプロイメントを使用している場合(または手動で構成する場合)は、ディザスタ・リカバリ用のスタンバイ・データベースの構成の詳細に関する項で、手順を参照してください。
ノート:
Data Guardデータベースを作成したら、初期化パラメータ値がプライマリ・データベースと同一であることを確認してください。Oracle Cloud Infrastructureを使用している場合は、次のステップを実行します:
ノート:
A cross-region Data Guard association cannot be created between databases of DB systems that
belong to VCNs that are not peers.その場合は、Oracle Supportに、CrossRegionDataguardNetworkValidationの無効化をリクエストするサービス・リクエストを提出します。
親トピック: 一般的なディザスタ・リカバリ・プロセス
Kubernetesオブジェクトのバック・アップとリストア
Kubernetesクラスタはそれぞれが別のものであるため、個別のメンテナンスが必要です。クラスタ内のアーティファクトによって、アプリケーションの操作が決まります。アーティファクトには、ネームスペース、永続ボリューム、構成マップなどがあります。これらのアーティファクトは、アプリケーションを起動する前に、スタンバイ・クラスタで作成する必要があります。
スタンバイ・システムでアーティファクトを作成する方法には、次の2つがあります:
- 構成情報はプライマリ・サイトと同じものを使用しますが、使い捨てデータベースを使用して、別途インストールを実行します。インストールが完了したら、データベースとドメイン構成を破棄し、プライマリ・サイトのデータベースとドメイン構成に置き換えます。
- プライマリ・サイトのKubernetesオブジェクトをバック・アップし、スタンバイ・サイトにリストアして、永続ボリュームをスタンバイNFSサーバーに示します。この方法は、Oracle Advanced Authenticationにはお薦めしません。
オラクル社では、Kubernetesオブジェクトのバック・アップとリストアのプロセスを簡素化するツールを用意しています。このツールの詳細は、「Using the Oracle K8s Disaster Protection Scripts」を参照してください。
これらのスクリプトを使用するには:
ノート:
- リストア前にスタンバイ・サイトに永続ボリュームを作成しておかないと、アプリケーションが起動しません。または、リストア後にPVを作成することも可能ですが、この場合は、ボリュームが作成されるまでポッドが保留されたままになります。スタンバイ・サイトの永続ボリュームが、そのサイトのNFSサーバーを示していることを確認するのが重要です。
- バックアップ・プロセスで、バックアップに永続ボリュームを含めるようにリクエストすることが可能です。ただし、これにより、プライマリNFSサーバーに対するマウントもバックアップされます。プライマリ・デプロイメントが破損する可能性があるため、プライマリNFSサーバーを使用して、スタンバイ・サイトでアプリケーションが起動されないようにしてください。
- バックアップの作成時に、プライマリでアプリケーションが実行されている場合、リストアの実行中に、スタンバイでアプリケーションが起動されます。エラーを最小限に抑えるには、Data Guardデータベースをスナップショット・スタンバイとしてオープンする必要があります。それでも、SOAおよびOIGから実行されているジョブが原因でエラーが発生する場合がありますが、それは、サイトのステータスが非アクティブであることが原因のため、無視してかまいません。
ある時点で、Data Guardデータベースをスタンバイ・サイトに切り替えて、スタンバイ・サービスが機能していることを確認する必要があります。
親トピック: 一般的なディザスタ・リカバリ・プロセス
永続ボリュームを同期するKubernetes CronJobの作成
この項で説明するそれぞれの解決策では、永続ボリュームに保存されている構成情報をプライマリ・サイトとスタンバイ・サイト間で同期させ、サイトをスイッチオーバーする場合には、同期の方向を逆にできる必要があります。
前述したように、効率を最大限に高める最善の方法は、ファイル・システム・レプリケーションを使用することです。「Kubernetesオブジェクトのバック・アップとリストア」を参照するか、Kubernetesクラスタ内にcronジョブを作成して、このタスクを実行します。プロセスは製品ごとに同じで、基礎となるボリュームのみが異なります。すべての製品に対応するcronジョブではなく、製品ごとに個別のジョブを作成することをお薦めします。
次のステップで、この実行方法を説明します。簡略化するために、この例ではOracle Access Manager (OAM)を使用しますが、どの製品にも当てはまります。
バックアップ・ジョブのネームスペースの作成
製品ネームスペースの外部に別のネームスペースを作成し、製品ごとのバックアップ・ジョブまたはすべてのバックアップ・ジョブを格納します。
次のコマンドを使用して、ネームスペースを作成します:
create namespace <namespace>create namespace drns永続ボリュームの作成
各サイトには、リモートの場所にあるNFSファイラを指す永続ボリュームが必要です。
指定されたyamlファイルを使用して、サイト1に次の永続ボリュームを作成します:
site1_primary_pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: primary-oam-pv
labels:
type: primary-oam-pv
spec:
storageClassName: manual
capacity:
storage: 30Gi
accessModes:
- ReadWriteMany
nfs:
path: /export/IAMPVS/oampv
server: <site1_nfs_server>site1_standby_pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: standby-oam-pv
labels:
type: standby-oam-pv
spec:
storageClassName: manual
capacity:
storage: 30Gi
accessModes:
- ReadWriteMany
nfs:
path: /export/IAMPVS/oampv
server: <site2_nfs_server>指定されたyamlファイルを使用して、サイト2に次の永続ボリュームを作成します:
site2_primary_pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: primary-oam-pv
labels:
type: primary-oam-pv
spec:
storageClassName: manual
capacity:
storage: 30Gi
accessModes:
- ReadWriteMany
nfs:
path: /export/IAMPVS/oampv
server: <site2_nfs_server>site2_standby_pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: standby-oam-pv
labels:
type: standby-oam-pv
spec:
storageClassName: manual
capacity:
storage: 30Gi
accessModes:
- ReadWriteMany
nfs:
path: /export/IAMPVS/oampv
server: <site1_nfs_server>次のコマンドを使用して、永続ボリュームを作成します:
kubectl create -f site1_primary_pv.yamlkubectl create -f site1_standby_pv.yamlkubectl create -f site2_primary_pv.yamlkubectl create -f site2_standby_pv.yaml永続ボリューム要求の作成
永続ボリュームを作成したら、DRネームスペースに永続ボリューム要求を作成できます。
次のファイルを作成します(各サイトで、ファイルが同一になることに注意してください):
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: primary-oampv-pvc
namespace: <DRNS>
labels:
type: primary-oampv-pvc
spec:
storageClassName: manual
accessModes:
- ReadWriteMany
resources:
requests:
storage: 30Gi
selector:
matchLabels:
type: primary-oam-pvapiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: standby-oampv-pvc
namespace: <DRNS>
labels:
type: standby-oampv-pvc
spec:
storageClassName: manual
accessModes:
- ReadWriteMany
resources:
requests:
storage: 30Gi
selector:
matchLabels:
type: standby-oam-pvkubectl create -f primary_pvc.yamlkubectl create -f standby_pvc.yaml親トピック: 一般的なディザスタ・リカバリ・プロセス
DR ConfigMapの作成
各サイトには、サイトのロール、ドメイン名、プライマリ・データベースのスキャン・アドレス、サービス名など、サイトに関する構成情報を含むConfigMapオブジェクトがあります。
- サイトが実行しているロール。このロールによって、PVのレプリケート方法が決まります。レプリケーションは常に、プライマリからスタンバイに行われる必要があります。
- ドメインの名前(永続ボリューム上のDOMAIN_HOMEの場所を決定します)。
- プライマリ・データベースのスキャン・アドレスおよびサービス名。これらは、スタンバイ・サイトのデータベースを指すよう、レプリケートされた構成情報を変更するために使用されます。
- スタンバイ・データベースのスキャン・アドレスおよびサービス名。これらは、スタンバイ・サイトのデータベースを指すよう、レプリケートされた構成情報を変更するために使用されます。
apiVersion: v1
kind: ConfigMap
metadata:
name: dr-cm
namespace: <DRNS>
data:
ENV_TYPE: <ENV_TYPE>
DR_TYPE: <DR_TYPE>
OAM_DOMAIN_NAME: <OAM_DOMAIN_NAME>
OAM_LOCAL_SCAN: <OAM_LOCAL_SCAN>
OAM_REMOTE_SCAN: <OAM_REMOTE_SCAN>
OAM_LOCAL_SERVICE: <OAM_LOCAL_SERVICE>
OAM_REMOTE_SERVICE: <OAM_REMOTE_SERVICE>
OIG_DOMAIN_NAME: <OIG_DOMAIN_NAME>
OIG_LOCAL_SCAN: <OIG_LOCAL_SCAN>
OIG_REMOTE_SCAN: <OIG_REMOTE_SCAN>
OIG_LOCAL_SERVICE: <OIG_LOCAL_SERVICE>
OIG_REMOTE_SERVICE: <OIG_REMOTE_SERVICE>
OIRI_LOCAL_SCAN: <OIRI_LOCAL_SCAN>
OIRI_REMOTE_SCAN: <OIRI_REMOTE_SCAN>
OIRI_LOCAL_SERVICE: <OIRI_LOCAL_SERVICE>
OIRI_REMOTE_SERVICE: <OIRI_REMOTE_SERVICE>
OIRI_REMOTE_K8: <OIRI_REMOTE_K8>
OIRI_REMOTE_K8CONFIG: <OIRI_REMOTE_K8CONFIG>
OIRI_REMOTE_K8CA: <OIRI_REMOTE_K8CA>
OIRI_LOCAL_K8: <OIRI_LOCAL_K8>
OIRI_LOCAL_K8CONFIG: <OIRI_LOCAL_K8CONFIG>
OIRI_LOCAL_K8CA: <OIRI_LOCAL_K8CA>
OAA_LOCAL_SCAN: <OAA_LOCAL_SCAN>
OAA_REMOTE_SCAN: <OAA_REMOTE_SCAN>
OAA_LOCAL_SERVICE: <OAA_LOCAL_SERVICE>
OAA_REMOTE_SERVICE: <OAA_REMOTE_SERVICE>次に、ConfigMapオブジェクトのサンプルを示します:
site1_dr_cm.yamlapiVersion: v1
kind: ConfigMap
metadata:
name: dr-cm
namespace: <DRNS>
data:
ENV_TYPE: OTHER
DR_TYPE: PRIMARY
OAM_LOCAL_SCAN: site1-scan.dbsubnet.oke.oraclevcn.com
OAM_REMOTE_SCAN: site2-scan.dbsubnet.oke.oraclevcn.com
OAM_LOCAL_SERVICE: oamsvc.dbsubnet.oke.oraclevcn.com
OAM_REMOTE_SERVICE: oamsvc.dbsubnet.oke.oraclevcn.com
OIG_DOMAIN_NAME: governancedomain
OIG_LOCAL_SCAN: site1-scan.dbsubnet.oke.oraclevcn.com
OIG_REMOTE_SCAN: site2-scan.dbsubnet.oke.oraclevcn.com
OIG_LOCAL_SERVICE: oigsvc.dbsubnet.oke.oraclevcn.com
OIG_REMOTE_SERVICE: oigsvc.dbsubnet.oke.oraclevcn.com
OIRI_LOCAL_SCAN: site1-scan.dbsubnet.oke.oraclevcn.com
OIRI_REMOTE_SCAN: site2-scan.dbsubnet.oke.oraclevcn.com
OIRI_LOCAL_SERVICE: oirisvc.dbsubnet.oke.oraclevcn.com
OIRI_REMOTE_SERVICE: oirisvc.dbsubnet.oke.oraclevcn.com
OIRI_REMOTE_K8: 10.1.0.10:6443
OIRI_REMOTE_K8CONFIG: standby_k8config
OIRI_REMOTE_K8CA: standby_ca.crt
OIRI_LOCAL_K8: 10.0.0.5:6443
OIRI_LOCAL_K8CONFIG: primary_k8config
OIRI_LOCAL_K8CA:primary_ca.crt
OAA_LOCAL_SCAN: site1-scan.dbsubnet.oke.oraclevcn.com
OAA_REMOTE_SCAN: site2-scan.dbsubnet.oke.oraclevcn.com
OAA_LOCAL_SERVICE: oaasvc.dbsubnet.oke.oraclevcn.com
OAA_REMOTE_SERVICE: oaasvc.dbsubnet.oke.oraclevcn.comsite2_dr_cm.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: dr-cm
namespace: <DRNS>
data:
ENV_TYPE: OTHER
DR_TYPE: STANDBY
OAM_LOCAL_SCAN: site2-scan.dbsubnet.oke.oraclevcn.com
OAM_REMOTE_SCAN: site1-scan.dbsubnet.oke.oraclevcn.com
OAM_LOCAL_SERVICE: oamsvc.dbsubnet.oke.oraclevcn.com
OAM_REMOTE_SERVICE: oamsvc.dbsubnet.oke.oraclevcn.com
OIG_DOMAIN_NAME: governancedomain
OIG_LOCAL_SCAN: site2-scan.dbsubnet.oke.oraclevcn.com
OIG_REMOTE_SCAN: site1-scan.dbsubnet.oke.oraclevcn.com
OIG_LOCAL_SERVICE: oigsvc.dbsubnet.oke.oraclevcn.com
OIG_REMOTE_SERVICE: oigsvc.dbsubnet.oke.oraclevcn.com
OIRI_LOCAL_SCAN: site2-scan.dbsubnet.oke.oraclevcn.com
OIRI_REMOTE_SCAN: site1-scan.dbsubnet.oke.oraclevcn.com
OIRI_LOCAL_SERVICE: oirisvc.dbsubnet.oke.oraclevcn.com
OIRI_REMOTE_SERVICE: oirisvc.dbsubnet.oke.oraclevcn.com
OIRI_REMOTE_K8: 10.0.0.10:6443
OIRI_REMOTE_K8CONFIG: standby_k8config
OIRI_REMOTE_K8CA: standby_ca.crt
OIRI_LOCAL_K8: 10.1.0.5:6443
OIRI_LOCAL_K8CONFIG: primary_k8config
OIRI_LOCAL_K8CA:primary_ca.crt
OAA_LOCAL_SCAN: site2-scan.dbsubnet.oke.oraclevcn.com
OAA_REMOTE_SCAN: site1-scan.dbsubnet.oke.oraclevcn.com
OAA_LOCAL_SERVICE: oaasvc.dbsubnet.oke.oraclevcn.com
OAA_REMOTE_SERVICE: oaasvc.dbsubnet.oke.oraclevcn.comkubectl create -f site1_dr_cm.yamlkubectl create -f site2_dr_cm.yaml親トピック: 一般的なディザスタ・リカバリ・プロセス
バックアップ/リストア・ジョブの作成
次のステップでは、rsyncコマンドを使用してプライマリの永続ボリュームをバックアップし、スタンバイ・システムにリストアするために定期的に実行されるジョブを作成する方法について説明します。
親トピック: 一般的なディザスタ・リカバリ・プロセス
バックアップ/リストア・スクリプトの作成
永続ボリュームをバックアップし、そのバックアップをスタンバイ・サイトにコピーするスクリプトを作成する必要があります。デプロイメント自動化スクリプトには、このタスクを実行するサンプル・スクリプトが含まれています。このスクリプトは<product>_dr.shという名前で、SCRIPT_DIR/templates/<product>ディレクトリにあります。
SCRIPT_DIR/templates/oam/oam_dr.shにあります。次のいずれかの方法で、このスクリプトを永続ボリュームにコピーする必要があります:
- デプロイメント内の実行中のコンテナにスクリプトをコピーする。
- 永続ボリュームにアクセスするための単純なAlpineコンテナを作成する。
- スクリプトが開発されているホストにNFSを一時的にマウントする。
このドキュメントでは、スクリプトをコピーする必要がある場所をdr_scriptsと呼びます。
スクリプトは両方のサイトで実行されます。サイトがプライマリ・モードの場合は、永続ボリュームのバックアップが作成され、サイト2に送信されます。サイトがスタンバイ・モードの場合は、サイト1から受信したバックアップがサイト2にリストアされます。バックアップまたはリストア操作を実行する前に、スクリプトで永続ボリュームのローカル・コピーを作成することをお薦めします。
次のステップに従って、スナップショットなどのNFSユーティリティを使用するか、rsyncコマンドを使用して、スクリプトで永続ボリュームのローカル・コピーを事前に作成することを強くお薦めします。
親トピック: バックアップ/リストア・ジョブの作成
バックアップ/リストア・スクリプトを定期的に実行するためのCronJobの作成
バックアップ・プロセスを自動化するには、バックアップ・スクリプトを定期的に実行するジョブを作成する必要があります。このジョブに基づいて別のジョブが作成され、バックアップ・プロセスが初期化されます。CronJobが予期せず実行されないようにするには、作成直後に一時停止する必要があります。
ジョブのスケジュールの頻度は、構成の変更が行われる頻度をベースにする必要があります。変更の頻度が低い場合、ジョブの実行頻度は低くてかまいません。ただし、ジョブの実行頻度が高いほど、必要なリソースが多くなり、システム・パフォーマンスに影響する可能性があります。また、ジョブの間隔は、次の繰返しが始まる前にジョブが完了するよう、十分に時間を空けてください。適切な頻度は1日に1回で、必要な場合は、追加で手動の同期を行います。
ジョブが初めて実行されるときは、その後の実行より時間がかかります。CronJobを作成したらすぐに一時停止し、手動でジョブを実行して、DRサイトを初期化することをお薦めします。DRサイトを初期化したら、CronJobを再起動します。
drnsネームスペースにCronJobを作成するには、次の内容でoamdr-cron.yamlというファイルを作成します:
apiVersion: batch/v1
kind: CronJob
metadata:
name: <product>rsyncdr
namespace: <DRNS>
spec:
schedule: "*/720 * * * *"
jobTemplate:
spec:
template:
spec:
imagePullSecrets:
- name: regcred
containers:
- name: alpine-rsync
image: iad.ocir.io/mytenancy/idm/alpine-rsync:latest
imagePullPolicy: IfNotPresent
envFrom:
- configMapRef:
name: dr-cm
volumeMounts:
- mountPath: "/u01/primary_oampv"
name: oampv
- mountPath: "/u01/dr_oampv"
name: oampv-dr
command:
- /bin/sh
- -c
- /u01/primary_oampv/dr_scripts/oam_dr.sh
volumes:
- name: oampv
persistentVolumeClaim:
claimName: primary-oampv-pvc
- name: oampv-dr
persistentVolumeClaim:
claimName: standby-oampv-pvc
restartPolicy: OnFailureapiVersion: batch/v1
kind: CronJob
metadata:
name: oamrsyncdr
namespace: drns
spec:
schedule: "*/720 * * * *"
jobTemplate:
spec:
template:
spec:
imagePullSecrets:
- name: regcred
containers:
- name: alpine-rsync
image: iad.ocir.io/paasmaa/idm/alpine-rsync:latest
imagePullPolicy: IfNotPresent
envFrom:
- configMapRef:
name: dr-cm
volumeMounts:
- mountPath: "/u01/primary_oampv"
name: oampv
- mountPath: "/u01/dr_oampv"
name: oampv-dr
command:
- /bin/sh
- -c
- /u01/primary_oampv/dr_scripts/oam_dr.sh
volumes:
- name: oampv
persistentVolumeClaim:
claimName: primary-oampv-pvc
- name: oampv-dr
persistentVolumeClaim:
claimName: standby-oampv-pvc
restartPolicy: OnFailureこのジョブは1日に1回実行されます。KuberenetesでのCronJobのスケジューリングに関する詳細は、FreeBSDのファイル・フォーマット・マニュアルを参照してください。
このジョブでは、以前作成したカスタムのAlpineコンテナ・イメージが使用されます。「rsyncを使用したコンテナの作成」を参照してください。DRサイトの初期化には通常のリフレッシュより時間がかかりますが、この初期化を行うには、ただちにジョブを一時停止する必要があります。「CronJobの一時停止/再開」を参照してください。初期コピーの実行には時間がかかるため、一度に実行される同期ジョブが1つのみになるよう、初期化プロセスを実行する別のジョブを作成する必要があります。
親トピック: バックアップ/リストア・ジョブの作成
CronJobの一時停止/再開
kubectl patch cronjobs <product>rsyncdr -p '{"spec" : {"suspend" : true }}' -n <NAMESPACE>kubectl patch cronjobs oamrsyncdr -p '{"spec" : {"suspend" : true }}' -n drnsバックアップCronJobを再起動するには、次のコマンドを実行します:
kubectl patch cronjobs <product>rsyncdr -p '{"spec" : {"suspend" : false }}' -n <NAMESPACE>kubectl patch cronjobs oamrsyncdr -p '{"spec" : {"suspend" : false }}' -n drns親トピック: バックアップ/リストア・ジョブの作成
初期化ジョブの作成
kubectl create job --from=cronjob.batch/<product>rsyncdr <product>-initialise-dr -n <DRNS>たとえば:
kubectl create job --from=cronjob.batch/oamrsyncdr oam-initialise-dr -n drnsジョブが正常に完了するまで監視します。ジョブが完了したら、同じコマンドを使用して、2番目のサイトでリストアを開始できます。
親トピック: バックアップ/リストア・ジョブの作成
Oracle Unified Directoryのディザスタ・リカバリの構成
Oracle Unified Directory (OUD)のディザスタ・リカバリは、アクティブ/パッシブ・ソリューションです。現在は、dsreplicationコマンドを使用して、リモート・レプリカを設定することはできません。
DRサイトを設定するプロセスを次に示します:
- 標準的なデプロイ手順を使用して、サイト2で最小限のインストールを実行します。
- DRサイトのOUDプロセスを停止します。
- DRサイトのOUD永続ボリューム・データを削除します。
- 次の内の1つを実行します。
- 永続ボリュームのディスク・レプリケーションの有効化。
- ローカルとリモートの両方のOUD永続ボリュームにマウントするCronJobを使用した手動レプリケーションの有効化。このジョブでは、
rsyncコマンドを使用してデータが同期されます。レプリケーションが完了したら、ジョブを一時停止します。
- 初期データ同期を実行します。
- DRサイトが正常に起動することを確認します。
- DRサイトを停止します。
- CronJobを再起動して、データを定期的にコピーします。
次の項では、手順を詳しく説明します:
- 前提条件
- サイト2での空のOUDデプロイメントの作成
- 手動レプリケーションの有効化
- サイト2でのOUDインストールの停止
- サイト2の永続ボリューム・データの削除
- 初期化ジョブの作成
- DRサイトでのOUDの検証
- 自動同期プロセスの開始
親トピック: ディザスタ・リカバリの構成
前提条件
- ローカル・ポッドにリモート・ファイル・システムをマウントできること。このタスクには、ファイアウォールまたはセキュリティ・リストの権限が必要な場合があります。
- サイト間でディスク・レプリケーションを実行できること。このタスクには、ファイアウォールまたはセキュリティ・リストの権限が必要な場合があります。
- 手動レプリケーションを使用する場合は、
rsyncがインストールされているAlpineまたはBusyboxにアクセスできること。「バックアップ/リストア・ジョブの作成」を参照してください。
サイト2での空のOUDデプロイメントの作成
次の例外を除き、「Oracle Unified Directoryのインストールおよび構成」の手順に従って、サイト2でOUDデプロイメントを作成します:
- サイト1と同じスキーマ拡張ファイルを使用します。
- シード・ファイルは必要ありません。
- 最小のサーバー・オーバーライド・ファイルを使用します。たとえば:
image: repository: <OUD_REPOSITORY> tag: <OUD_VER> pullPolicy: IfNotPresent imagePullSecrets: - name: regcred oudConfig: baseDN: <LDAP_SEARCHBASE> rootUserDN: <LDAP_ADMIN_USER> rootUserPassword: <LDAP_ADMIN_PWD> sleepBeforeConfig: 300 persistence: type: networkstorage networkstorage: nfs: server: <PVSERVER> path: <OUD_SHARE> configVolume: enabled: true type: networkstorage networkstorage: nfs: server: <PVSERVER> path: <OUD_CONFIG_SHARE> mountPath: /u01/oracle/config-input replicaCount: <OUD_REPLICAS> ingress: enabled: false type: nginx tlsEnabled: false elk: enabled: false imagePullSecrets: - name: dockercred cronJob: kubectlImage: repository: bitnami/kubectl tag: <KUBERNETES_VER> pullPolicy: IfNotPresent imagePullSecrets: - name: dockercred baseOUD: envVars: - name: schemaConfigFile_1 value: /u01/oracle/config-input/99-user.ldif - name: restartAfterSchemaConfig value: "true" replOUD: envVars: - name: dsconfig_1 value: set-global-configuration-prop --set lookthrough-limit:75000
手動レプリケーションの有効化
CronJobを作成して、サイト間のデータのレプリケーションを手動で行う場合は、次の手順を実行します。
リモート永続ボリューム用の永続ボリュームの作成
リモートのOUD永続ボリューム用の永続ボリュームを作成するには:
この永続ボリュームは、サイト1とサイト2の両方に作成する必要があります。サイト1のREMOTE_PV_SERVERがサイト2のPVSERVERを指し、サイト2のREMOTE_PV_SERVERがサイト1のPVSERVERを指していることを確認します。両方のサイトにPVを作成することにより、サイト1とサイト2の役割を元に戻す必要がある場合に、構成をすぐに利用できます。
親トピック: 手動レプリケーションの有効化
リモートの永続ボリュームに対する永続ボリューム要求の作成
リモートのOUD永続ボリューム用の永続ボリューム要求を作成するには:
サイト1とサイト2の両方に同じPVC要求を作成できます。両方のサイトに作成することにより、サイト1およびサイト2の役割を元に戻す必要がある場合に、構成をすぐに利用できます。
親トピック: 手動レプリケーションの有効化
バックアップおよびリストア・スクリプトの作成
OUDインスタンスをバックアップして、スタンバイ・サイトにコピーするスクリプトを作成する必要があります。このスクリプトにより、スタンバイ・サイトでバックアップをリストアできるようになります。このスクリプトのサンプルが必要な場合は、デプロイメント自動化スクリプトの中に、oud_dr.shという名前で見つかります。このスクリプトは、SCRIPT_DIR/templates/oudディレクトリにあります。「バックアップ/リストア・スクリプトの作成」を参照してください。
このスクリプトには次の特性が必要です:
- プライマリ・サイトとスタンバイ・サイトのどちらで実行されているかを判断できる必要があります。
- 前のバックアップ/リストア・ジョブが進行中の場合は、実行しないようにする必要があります。
- プライマリ・サイトで実行している場合:
- スナップショット(使用可能な場合)またはrsyncを使用して、永続ボリュームのローカライズされたバックアップを(一時的な場所に)作成します。
- rsyncを使用して、作成したバックアップをスタンバイ・サイトの一時的な場所にコピーします。
- スタンバイ・サイトで実行している場合は、受信したバックアップのOUDインスタンスが、永続ボリュームにリストアされます。
ノート:
バックアップ・スクリプトではなく、インスタンスのみがリストアされます。
親トピック: 手動レプリケーションの有効化
永続ボリュームへのバックアップ・スクリプトのコピー
コンテナ・イメージでバックアップ・スクリプトを実行できることを確認する最も簡単な方法は、スクリプトを永続ボリュームにコピーすることです。次のコマンドを使用して、両方のサイトでこのステップを実行する必要があります:
kubectl exec -n <OUDNS> -ti <OUD_POD_PREFIX>-oud-ds-rs-0 -- mkdir /u01/oracle/user_projects/dr_scriptskubectl cp <WORKDIR>/oud_dr.sh <OUDNS>/<OUD_POD_PREFIX>-oud-ds-rs-0:/u01/oracle/user_projects/dr_scriptskubectl exec -n <OUDNS> -ti <OUD_POD_PREFIX>-oud-ds-rs-0 -- chmod 750 /u01/oracle/user_projects/dr_scripts/oud_dr.shたとえば:
kubectl exec -n oudns -ti edg-oud-ds-rs-0 -- mkdir /u01/oracle/user_projects/dr_scriptskubectl cp /workdir/OUD/oud_dr.sh oudns edg-oud-ds-rs-0:/u01/oracle/user_projects/dr_scriptskubectl exec -n oudns -ti edg-oud-ds-rs-0 -- chmod 750 /u01/oracle/user_projects/dr_scripts/oud_dr.sh親トピック: 手動レプリケーションの有効化
CronJobの作成
CronJobを作成して、ローカルおよびリモートの永続ボリュームを同期します。手順は、「バックアップ/リストア・スクリプトを定期的に実行するためのCronJobの作成」を参照してください。作成したら、すぐにCronJobを一時停止します。手順は、「CronJobの一時停止/再開」を参照してください。
親トピック: 手動レプリケーションの有効化
サイト2でのOUDインストールの停止
すべてが想定どおりに機能している場合は、サイト2のOUDインストールを停止します。次のコマンドを使用して、停止します:
helm upgrade -n oudns --set replicaCount=0 edg <WORKDIR>/samples/kubernetes/helm/oud-ds-rs --reuse-valuesサイト2の永続ボリューム・データの削除
サイト1のデータがすべてサイト2にコピーされるようにするには、インストールの一部として作成されたデータを削除することが重要です。永続ボリュームがローカルにマウントされている場合は、次のコマンドを使用してデータを削除できます:
rm -rf /nfs_volumes/oudpv/*oud-ds-rs*初期化ジョブの作成
前に定義したCronJob (「CronJobの作成」)を使用して、次のコマンドで1回かぎりのジョブを作成し、初期データ転送を実行します:
kubectl create job --from=cronjob.batch/rsyncdr initialise-dr -n <DRNS>kubectl create job --from=cronjob.batch/rsyncdr initialise-dr -n drnsノート:
このステップは、サイト1で実行します。DRサイトでのOUDの検証
初期データ・ロードが成功したら、次のコマンドを使用して、サイト2でOUDサーバーを起動できます:
helm upgrade -n <OUDNS> --set replicaCount=<REPLICA_COUNT> <OUD_POD_PREFIX> <WORKDIR>/samples/kubernetes/helm/oud-ds-rs --reuse-valueshelm upgrade -n oudns --set replicaCount=1 edg /workdir/OUD/samples/kubernetes/helm/oud-ds-rs --reuse-valuesサーバーの起動後、レプリケーション・ステータスを確認し、ldapsearchコマンドライン・ツールを実行して、プライマリ・サイトのデータの可用性を確認します。
すべてが想定どおりに機能している場合は、次のコマンドを使用してOUDを停止します:
helm upgrade -n oudns --set replicaCount=0 edg <WORKDIR>/samples/kubernetes/helm/oud-ds-rs --reuse-valuesOracle Access Managerのディザスタ・リカバリの構成
Oracle Access Manager (OAM)のディザスタ・リカバリは、アクティブ/パッシブ・ソリューションです。
次の項では、手順を詳しく説明します:
前提条件
Oracle Access Managerのディザスタ・リカバリを有効化する前に、次のことを確認します:
- Data Guardのプライマリ・サイトとスタンバイ・サイトが相互に通信していること。
- ファイル・システム・レプリケーションのプライマリ・サイトとスタンバイ・サイトが相互に通信していること。
- プライマリ・サイトとスタンバイ・サイトの両方のKubernetesクラスタが、すべてのサイトのNFSサーバー名を解決できること。
- 各Kubernetesクラスタが独立していること。
- 実行中のKubernetesクラスタが両方のサイトに存在すること。
スタンバイ・サイトでのディザスタ・リカバリ・サイトの作成
スタンバイ・サイトでディザスタ・リカバリ・サイトを作成する方法には、次の2つがあります:
サイト2に使い捨ての新しい環境を作成
- プライマリ・サイトと同じ値を使用して、サイト2に使い捨てのデプロイメントを作成します。EDG自動化スクリプトを使用した場合、変更が必要なのは、レスポンス・ファイルのワーカー・ノードとPVサーバーの値のみです。
- サイト2で実行されているKubernetesポッドを停止します。
- 永続ボリュームの内容を削除します。
- サイト1で取得したバックアップから、永続ボリュームのバックアップをリストアします。「永続ボリュームを同期するKubernetes CronJobの作成」を参照してください。
- リストアされたバックアップのデータベース接続文字列を修正し、サイト2のデータベースを指すようにします。
- リストアされたバックアップからサイト2のOracle HTTP Serverに、WebGateオブジェクトをコピーします。
- ディザスタ・リカバリ・サイトが機能していることを確認します。
- 初期インストールの実行に使用した使い捨てデータベースを削除します。
サイト2でKubernetesのリストアを実行
- スタンバイ・サイトのNFSサーバーを指すように、OAMドメインの永続ボリュームを作成します。unresolvable-reference.html#GUID-373A3448-D7BA-41F6-BFDB-4D7DDB2B03F1を参照してください。
- 次のData Guard Brokerコマンドを使用して、スタンバイ・データベースをスナップショット・スタンバイとして開きます:
dgmgrl sys/Passwordshow configurationconvert database standby_db_name to snapshot standby - サイト1で取得した永続ボリュームのバックアップをリストアします。「永続ボリュームを同期するKubernetes CronJobの作成」を参照してください。
- サイト1で取得したバックアップから、Kubernetesオブジェクトのバックアップをリストアします。「Kubernetesオブジェクトのバックアップとリストア」を参照してください。
- リストアされたバックアップのデータベース接続文字列を修正し、サイト2のデータベースを指すようにします。
- リストアされたバックアップからサイト2のOracle HTTP Serverに、WebGateオブジェクトをコピーします。
- ディザスタ・リカバリ・サイトが機能していることを確認します。
- 次のData Guard Brokerコマンドを発行して、スタンバイ・データベースを回復します:
dgmgrl sys/Passwordshow configurationconvert database standby_db_name to physical standbyデータベースをスイッチオーバーし、デプロイメントが完全に機能していることを確認します。
Oracle Identity Governanceのディザスタ・リカバリの構成
Oracle Identity Governance (OIG)のディザスタ・リカバリは、アクティブ/パッシブ・ソリューションです。
次の項では、手順を詳しく説明します:
- 前提条件
- プライマリ・サイトからのディザスタ・リカバリ・サイトの作成
- スタンバイ・サイトでのディザスタ・リカバリ・サイトの作成
- Oracle Identity Managerを構成するためのジョブ・スケジューラの無効化
親トピック: ディザスタ・リカバリの構成
前提条件
Oracle Identity Governanceのディザスタ・リカバリを有効化する前に、次のことを確認します:
- ファイル・システム・レプリケーションのプライマリ・サイトとスタンバイ・サイトが相互に通信していること。
- プライマリ・サイトのデータベース・システムが、データベース・レプリケーションのために相互に通信していること。
- プライマリ・サイトとスタンバイ・サイトの両方のKubernetesクラスタが、すべてのサイトのNFSサーバー名を解決できること。
- 各Kubernetesクラスタが独立していること。
- 実行中のKubernetesクラスタが両方のサイトに存在すること。
スタンバイ・サイトでのディザスタ・リカバリ・サイトの作成
スタンバイ・サイトでディザスタ・リカバリ・サイトを作成する方法には、次の2つがあります:
サイト2に使い捨ての新しい環境を作成
- プライマリ・サイトと同じ値を使用して、サイト2に使い捨てのデプロイメントを作成します。EDG自動化スクリプトを使用した場合、変更が必要なのは、レスポンス・ファイルのワーカー・ノードとPVサーバーの値のみです。
- サイト2で実行されているKubernetesポッドを停止します。
- 永続ボリュームの内容を削除します。
- サイト1で取得したバックアップから、永続ボリュームのバックアップをリストアします。「永続ボリュームを同期するKubernetes CronJobの作成」を参照してください。
- リストアされたバックアップのデータベース接続文字列を修正し、サイト2のデータベースを指すようにします。
- ディザスタ・リカバリ・サイトが機能していることを確認します。
- 初期インストールの実行に使用した使い捨てデータベースを削除します。
サイト2でKubernetesのリストアを実行
- スタンバイ・サイトのNFSサーバーを指すように、OIGドメインの永続ボリュームを作成します。unresolvable-reference.html#GUID-CF07EE44-34D9-4F36-97BE-6B3FBB4FCEA8を参照してください。
- 次のData Guard Brokerコマンドを使用して、スタンバイ・データベースをスナップショット・スタンバイとして開きます:
dgmgrl sys/Passwordshow configurationconvert database standby_db_name to snapshot standby - サイト1で取得した永続ボリュームのバックアップをリストアします。「永続ボリュームを同期するKubernetes CronJobの作成」を参照してください。
- サイト1で取得したバックアップから、Kubernetesオブジェクトのバックアップをリストアします。「Kubernetesオブジェクトのバックアップとリストア」を参照してください。
- リストアされたバックアップのデータベース接続文字列を修正し、サイト2のデータベースを指すようにします。
- ディザスタ・リカバリ・サイトが機能していることを確認します。
- 次のData Guard Brokerコマンドを発行して、スタンバイ・データベースを回復します:
dgmgrl sys/Passwordshow configurationconvert database standby_db_name to physical standbyデータベースをスイッチオーバーし、デプロイメントが完全に機能していることを確認します。
Oracle Identity Managerを構成するためのジョブ・スケジューラの無効化
Oracle Identity Governanceを構成するには、サイト2のOracle Identity Governanceジョブ・スケジューラを無効にする必要があります。
OIGジョブ・スケジューラでは、データベースに高い負荷がかかります。サイト間のトラフィックを最小限に保つために、データベースがプライマリではないサイトのジョブ・スケジューラを無効にする必要があります。サイト2のOIG管理対象サーバーを停止する場合、このステップは必要ありません。次のパラメータをサーバー起動引数に追加することで、ジョブ・スケジューラを無効にできます:
-Dscheduler.disabled=trueデータベースを切り替えると、このパラメータはこれらのサーバーから削除され、現在のスタンバイ・サイトのサーバー定義に追加されます。
Oracle Identity Role Intelligenceのディザスタ・リカバリの構成
Oracle Identity Role Intelligence (OIRI)のディザスタ・リカバリは、アクティブ/パッシブ・ソリューションです。
次の項では、手順を詳しく説明します:
親トピック: ディザスタ・リカバリの構成
前提条件
Oracle Identity Role Intelligenceのディザスタ・リカバリを有効化する前に、次のことを確認します:
- ファイル・システム・レプリケーションのプライマリ・サイトとスタンバイ・サイトが相互に通信していること。
- プライマリ・サイトのデータベース・システムが、データベース・レプリケーションのために相互に通信していること。
- プライマリ・サイトとスタンバイ・サイトの両方のKubernetesクラスタが、すべてのサイトのNFSサーバー名を解決できること。
- 各Kubernetesクラスタが独立していること。
- 実行中のKubernetesクラスタが両方のサイトに存在すること。
ディザスタ・リカバリ・サイトの作成
OIRIは、Kubernetesフレームワークに緊密に統合されています。クラスタと直接通信して、データ取込みタスクを実行できます。OIRIをデプロイすると、OIRIには、実行されているクラスタ名などの情報が格納されます。別のサイトからOIRIを実行する場合は、データベース接続情報に加えて、Kubernetesクラスタ情報も更新する必要があります。このタスクは、次の2つの方法で実行できます。
- OIRIを別のサイトで起動する場合は、Kubernetes構成を更新します。
- 各サイトの構成を永続ボリュームに格納します。次に、スタンバイ・サイトで永続ボリュームをリストアするときに、これらのファイルを使用してKubernetes構成を適切な値に置き換えます。
これらのファイルを作成できるのは、スタンバイ・サイトにOIRI Kubernetesオブジェクトを作成した後のみです。
推奨の方法は、Kubernetes構成オブジェクトのコピーを永続ボリュームに作成し、サイトに応じたラベルを付けることです。たとえば、
primary_ca.crtおよびprimary_k8configです。スタンバイ・サイトを作成し(「スタンバイ・サイトでのディザスタ・リカバリ・サイトの作成」を参照)、スタンバイ・クラスタに基づいて新しいca.crtおよびkubeconfigファイルを作成します。これらのファイルを、ファイルstandby_ca.crtおよびstandby_k8configをコールするプライマリ・サイトの永続ボリュームにコピーします。この命名規則により、永続ボリュームをスタンバイ・サイトにレプリケートするときに、プライマリ・クラスタとスタンバイ・クラスタの両方にca.crtおよびkubeconfigファイルのコピーがあることが保証されます。PVレプリケーション・タスクの実行後、ca.crtおよびkubeconfigファイルを、実行するサイトに関連する永続ボリュームにリストアします。たとえば:- プライマリ・サイトを使用する場合、
ca.crtファイルとconfigファイルでは、それぞれprimary_ca.crtファイルとprimary_k8configファイルの内容が使用されます。 - スタンバイ・サイトを使用する場合、
ca.crtファイルとconfigファイルでは、それぞれstandby_ca.crtファイルとstandby_k8configファイルの内容が使用されます。
- プライマリ・サイトを使用する場合、
スタンバイ・サイトでのディザスタ・リカバリ・サイトの作成
スタンバイ・サイトでディザスタ・リカバリ・サイトを作成する方法には、次の2つがあります:
サイト2に使い捨ての新しい環境を作成
サイト2でKubernetesのリストアを実行
- スタンバイ・サイトのNFSサーバーを指すように、OIRI永続ボリューム用の永続ボリュームを作成します。unresolvable-reference.html#GUID-CF07EE44-34D9-4F36-97BE-6B3FBB4FCEA8を参照してください。
- 次のData Guard Brokerコマンドを使用して、スタンバイ・データベースをスナップショット・スタンバイとして開きます:
dgmgrl sys/Passwordshow configurationconvert database standby_db_name to snapshot standby - サイト1で取得した永続ボリュームのバックアップをリストアします。「永続ボリュームを同期するKubernetes CronJobの作成」を参照してください。
- サイト1で取得したバックアップから、Kubernetesオブジェクトのバックアップをリストアします。「Kubernetesオブジェクトのバックアップとリストア」を参照してください。
- スタンバイ・システムでOIRI-CLIコンテナを起動します。「管理CLIの起動」を参照してください。
- スタンバイ・サイトに
kubeconfigファイルと証明書を作成します。「ca.crt証明書の生成」および「OIRI用のKubernetes構成ファイルの作成」を参照してください。結果ファイル
ca.crtおよびoiri_configを、プライマリ・サイトとスタンバイ・サイトの両方のOIRI-CLIの場所に格納します。/app/k8s/standby_ca.crt /app/k8s/standby_ca.crt /app/k8s/standby_config.crt - リストアされたバックアップのデータベース接続文字列を修正し、サイト2のデータベースを指すようにします。
次のファイルを更新します:
/app/oiri/data/conf/application.yaml /app/data/conf/custom-attributes.yaml /app/data/conf/data-ingestion-config.yaml /app/data/conf/dbconfig.yaml /app/data/conf/env.properties - リストアされたバックアップのKubernetesクラスタURLを修正し、スタンバイ・サイトのKubernetesクラスタを指すようにします。KubernetesクラスタURLを検索するには、次のコマンドを使用します:
grep server: $KUBECONFIG | sed 's/server://;s/ //g'次のファイルを更新します:
/app/data/conf/data-ingestion-config.yaml /app/data/conf/env.properties - Kubernetes構成ファイルをスタンバイ・サイトに適切なコピーに切り替えます。たとえば:
cp /app/k8s/standby_ca.crt /app/k8s/ca.crtcp /app/k8s/standby_ca.crt /app/ca.crtcp /app/k8s/standby_config.crt /app/k8s/config - ディザスタ・リカバリ・サイトが機能していることを確認します。
- 次のData Guard Brokerコマンドを使用して、スタンバイ・データベースを回復します:
dgmgrl sys/Passwordshow configurationconvert database standby_db_name to physical standbyデータベースをスイッチオーバーし、デプロイメントが完全に機能していることを確認します。
- プライマリ・サイトからスタンバイ・サイトに、永続ボリュームを定期的に再コピーします。たとえば、週に1回、またはOIRIデプロイメントに構成の変更を加えるごとです。
親トピック: ディザスタ・リカバリ・サイトの作成
Oracle Advanced Authenticationのディザスタ・リカバリの構成
Oracle Advanced Authentication (OAA)のディザスタ・リカバリは、アクティブ/パッシブ・ソリューションです。
次の項では、手順を詳しく説明します:
親トピック: ディザスタ・リカバリの構成
前提条件
Oracle Advanced Authenticationのディザスタ・リカバリを有効化する前に、次のことを確認します:
- ファイル・システム・レプリケーションのプライマリ・サイトとスタンバイ・サイトが相互に通信していること。
- プライマリ・サイトのデータベース・システムが、データベース・レプリケーションのために相互に通信していること。
- プライマリ・サイトとスタンバイ・サイトの両方のKubernetesクラスタが、すべてのサイトのNFSサーバー名を解決できること。
- 各Kubernetesクラスタが独立していること。
- 実行中のKubernetesクラスタが両方のサイトに存在すること。
- 両方のサイトで、OAuthプロバイダを使用できること。
ノート:
OAMをOAuthプロバイダとして使用していて、フェイルオーバー・シナリオが「すべてまたはなし」の場合、つまりOAMとOAAが同時に失敗するかスイッチオーバーする場合は、DRサイトを作成するために、OAMスタンバイ・データベースを一時的にスナップショット・スタンバイに変換し、そのデータベースを使用してOAMを起動することで、構成中にスタンバイ・サイトでOAMを有効にする必要があります。OAAを構成したら、OAMを停止し、データベースをフィジカル・スタンバイに戻します。
各OAMで、同じSSL証明書を使用する必要があります。