22 ディザスタ・リカバリの構成

これまでのディザスタ・リカバリ・プランの多くには、メイン・システムとバックアップ・システム間のファイル・システムの同期が伴っていました。最も効果的な方法は、ディスク・レプリケーションによる同期です。ただし、この選択ができない場合、次に最適な解決策は、rsyncユーティリティを使用して、ある場所から別の場所にデータをコピーすることです。ディザスタ・リカバリ環境の設定を支援するために、Oracleには、この章で説明する各Oracle製品にディザスタ・リカバリを設定するためのサンプル・スクリプトが用意されています。サンプル・スクリプトを直接、または追加の参照として使用して、特定のステップの実行方法を確認できます。これらの自動化スクリプトの詳細は、「ディザスタ・リカバリの設定の自動化」を参照してください。

この章の内容は次のとおりです。

一般的なディザスタ・リカバリ・プロセス

一般的なディザスタ・リカバリ・プロセスには、rsyncを使用したサイト間のデータのコピー、Oracle Data Guardを使用したスタンバイ・データベースの作成、クラスタ・アーティファクトのバックアップとリストア、永続ボリュームの同期などがあります。

次に、一般的なディザスタ・リカバリ・プロセスのリストを示します:

rsyncを使用したコンテナの作成

永続ボリューム・データは、様々な方法でレプリケートできます。これらは、2つのカテゴリに分けられます:
  • ハードウェア・レプリケーション - クラウド・ベースのファイル・システム・レプリケーションのディスク・ベース・レプリケーションを使用します。
  • ソフトウェア・レプリケーション - ソフトウェア・ツールを使用して、ファイル・システムを手動でレプリケートします。ソフトウェア・レプリケーションを実行するためのツールで、最も広く普及している効率的なものの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アカウントにログインし、リポジトリ・イメージにアクセスできるようにしておく必要があります。

  1. Alpineコンテナをダウンロードし、次のコマンドで起動します:
    podman run -dit alpine sh

    このコマンドでAlpineコンテナが起動します。

  2. 次のコマンドを使用して、コンテナIDを取得します:
    podman ps

    このコマンドの出力は次のようになります:

    CONTAINER ID  IMAGE                            COMMAND     CREATED         STATUS             
    7cb3c9de95ea  docker.io/library/alpine:latest  sh          20 minutes ago  Up 20 minutes ago

    コンテナIDは、7cb3c9de95eaです。

  3. コンテナIDを使用してコンテナに接続します。たとえば:
    podman attach 7cb3c9de95ea
  4. 次のコマンドを使用して、コンテナにrsyncをインストールします:
    apk update
    apk add rsync

    出力は次のようになります。

    / # apk update
    fetch https://dl-cdn.alpinelinux.org/alpine/v3.17/main/x86_64/APKINDEX.tar.gz
    fetch https://dl-cdn.alpinelinux.org/alpine/v3.17/community/x86_64/APKINDEX.tar.gz
    v3.17.0-136-gc113cb02a1 [https://dl-cdn.alpinelinux.org/alpine/v3.17/main]
    v3.17.0-137-ge9e378b388 [https://dl-cdn.alpinelinux.org/alpine/v3.17/community]
    OK: 17803 distinct packages available
    
    / # apk add rsync
    (1/5) Installing libacl (2.3.1-r1)
    (2/5) Installing lz4-libs (1.9.4-r1)
    (3/5) Installing popt (1.19-r0)
    (4/5) Installing zstd-libs (1.5.2-r9)
    (5/5) Installing rsync (3.2.7-r0)
    Executing busybox-1.35.0-r29.trigger
    OK: 8 MiB in 20 packages

    キーボードの[Ctrl]+[P]+[Q]を押してコンテナを終了します。

  5. 次のコマンドを使用して、イメージへの変更をコミットします:
    podman commit -m "Added rsync" 7cb3c9de95ea alpine-rsync -f docker

    出力は次のようになります。

    Getting image source signatures
    Copying blob ded7a220bb05 skipped: already exists
    Copying blob 6459a5a97a89 done
    Copying config 6cf4ad33ac done
    Writing manifest to image destination
    Storing signatures
    6cf4ad33aca33fe62cb0fee9354b0b8f548ab9983427c25c24f77fcb6542e17c
  6. 次のコマンドを使用して、alpine-rsyncがローカル・イメージ・ストアにあることを確認します:
    podman images

    出力は次のようになります。

    REPOSITORY                                          TAG                            IMAGE ID      CREATED         SIZE
    localhost/alpine-rsync                              latest                         6cf4ad33aca3  14 seconds ago  11.1 MB
    docker.io/library/alpine                            latest                         49176f190c7e  2 weeks ago     7.34 MB
  7. 次のコマンドを使用して、イメージにコンテナ・レジストリ名をタグ付けします:
    podman tag 6cf4ad33aca3  iad.ocir.io/mytenancy/idm/alpine-rsync:latest
  8. 次のコマンドを使用して、alpine-rsyncがローカル・イメージ・ストアにタグ付けされていることを確認します:
    podman images

    出力は次のようになります。

    iad.ocir.io/mytenancy/idm/alpine-rsync              latest                         6cf4ad33aca3  28 minutes ago  11.1 MB
    localhost/alpine-rsync                              latest                         6cf4ad33aca3  28 minutes ago  11.1 MB
    docker.io/library/alpine                            latest                         49176f190c7e  2 weeks ago     7.34 MB
  9. 次のコマンドを使用して、イメージをコンテナ・レジストリにプッシュします:
    podman login iad.ocir.io/mytenant -u paasmaa/oracleidentitycloudservice/myuser -p "mypassword"
    podman push iad.ocir.io/mytenancy/idm/alpine-rsync:latest
    これで、コンテナ・レジストリからイメージを使用できるようになります。

Data Guardデータベースの作成

rsyncを使用すると、あるサイトからKubernetesの外部にデータをコピーできます。ただし、データをコピーするより効率的な方法は、Kubernetes CronJobを作成することです。ディザスタ・リカバリを実行する際は、アプリケーションをスタンバイ・サイトにデプロイした後に、既存のデータベースを削除し、Oracle Data Guardを使用してスタンバイ・データベースを作成する必要があります。

Oracle Cloud以外をベースとしたデプロイメントを使用している場合(または手動で構成する場合)は、ディザスタ・リカバリ用のスタンバイ・データベースの構成の詳細に関する項で、手順を参照してください。

ノート:

Data Guardデータベースを作成したら、初期化パラメータ値がプライマリ・データベースと同一であることを確認してください。

Oracle Cloud Infrastructureを使用している場合は、次のステップを実行します:

  1. テナンシのOracle Cloud Infrastructureコンソールにログインします。
  2. リージョンが、プライマリ・データベースが存在するのと同じリージョンに設定されていることを確認します。
  3. 「Oracle Database」に移動し、「Oracleベース・データベース(VM、BM)」をクリックします。
  4. データベースを格納するデータベース・システムの名前を選択します。データベースがページの「データベース」セクションにリストされます。
  5. データベースの名前を選択します。
  6. 「Data Guardアソシエーション」サブメニューを選択します。
  7. 「Data Guardの有効化」をクリックします。
  8. ウィザードに次の情報を入力します。
    • 表示名: Data Guardデータベースの名前を入力します。
    • リージョン: スタンバイ・サイトがあるリージョンを選択します。
    • 可用性ドメイン: データベースを配置する可用性ドメインを選択します。
    • シェイプの構成: 必要に応じて、シェイプを編集します。
    • ライセンス・タイプ: 使用するライセンス・タイプを選択します。
    • 仮想クラウド・ネットワーク名: スタンバイ・サイトのVCNの名前を入力します。
    • クライアントのサブネット: スタンバイ・サイトのデータベース・サブネットの名前を入力します。たとえば、db-subnetです。
    • データベース・ノードのホスト名接頭辞を入力します。たとえば、regdbです(regはリージョンの名前です)。
    • デプロイするData Guardのタイプを入力します。たとえば、Active Data Guard (推奨)です。
  9. 「次」をクリックします。
  10. 「データベース情報」画面で、次の情報を入力します:
    • データベース・イメージ: データベース・イメージが、プライマリ・データベースのイメージと同一であることを確認します。
    • データベース・パスワード: スタンバイ・データベースのsysパスワードを入力します。
  11. 「Data Guardの有効化」をクリックします。
  12. Data Guardデータベースに、プライマリ・データベースと同じ初期化パラメータがあることを確認します。

    ノート:

    Data Guard作成プロセスのバグにより、プロセスなどの一部のパラメータで特定のインスタンスの値がオーバーライドされている場合があります。この問題が発生した場合は、次のコマンドを使用してオーバーライドしている値を削除します:
    alter system reset processes sid='instance_name';

ノート:

ネットワーク・アナライザの実行後に、リージョン間の通信パスが正常であることを確認しても、次のようなData Guardアソシエーション・エラーが発生します:
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」を参照してください。

これらのスクリプトを使用するには:

  1. 次のコマンドを使用して、スクリプトを適切な場所にダウンロードします:
    git clone -q https://github.com/oracle-samples/maa
    chmod 700 maa/kubernetes-maa/*.sh
  2. バックアップを格納するディレクトリを作成します。たとえば:
    mkdir -p /workdir/k8backup
  3. 次のコマンドを使用して、ネームスペースのバックアップを作成します:
    kubernetes-maa/maak8-get-all-artifacts.sh <Backup Directory> <Namespace>
    たとえば:
    kubernetes-maa/maak8-get-all-artifacts.sh /workdir/k8backup  oamns

    このプロセスの完了には数分かかります。バックアップの場所に日付のディレクトリが作成され、バックアップ・アーカイブである.gzファイルが格納されます。

  4. 任意のファイル転送メカニズムで、.gzファイルをスタンバイ・サイトに転送します。
  5. 次のコマンドを使用して、バックアップ・サイトをスタンバイ・クラスタにリストアします:
    kubernetes-maa/maak8-push-all-artifacts.sh <BACKUP_FILE> <WORKING DIRECTORY>
    たとえば:
    kubernetes-maa/maak8-push-all-artifacts.sh /workdir/k8backup/23-06-05-11-03-15/ /workdir/k8restore

ノート:

  • リストア前にスタンバイ・サイトに永続ボリュームを作成しておかないと、アプリケーションが起動しません。または、リストア後に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>

次のコマンドを使用して、永続ボリュームを作成します:

Site1
kubectl create -f site1_primary_pv.yaml
kubectl create -f site1_standby_pv.yaml
Site2
kubectl create -f site2_primary_pv.yaml
kubectl create -f site2_standby_pv.yaml

永続ボリューム要求の作成

永続ボリュームを作成したら、DRネームスペースに永続ボリューム要求を作成できます。

次のファイルを作成します(各サイトで、ファイルが同一になることに注意してください):

primary_pvc.yaml
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-pv
standby_pvc.yaml
apiVersion: 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-pv
次のコマンドを使用して、両方のサイトで永続ボリューム要求を作成します:
kubectl create -f primary_pvc.yaml
kubectl create -f standby_pvc.yaml

DR ConfigMapの作成

各サイトには、サイトのロール、ドメイン名、プライマリ・データベースのスキャン・アドレス、サービス名など、サイトに関する構成情報を含むConfigMapオブジェクトがあります。

  • サイトが実行しているロール。このロールによって、PVのレプリケート方法が決まります。レプリケーションは常に、プライマリからスタンバイに行われる必要があります。
  • ドメインの名前(永続ボリューム上のDOMAIN_HOMEの場所を決定します)。
  • プライマリ・データベースのスキャン・アドレスおよびサービス名。これらは、スタンバイ・サイトのデータベースを指すよう、レプリケートされた構成情報を変更するために使用されます。
  • スタンバイ・データベースのスキャン・アドレスおよびサービス名。これらは、スタンバイ・サイトのデータベースを指すよう、レプリケートされた構成情報を変更するために使用されます。
ConfigMapオブジェクトの説明:
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.yaml
apiVersion: 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.com

site2_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.com
次のコマンドを使用して、サイト1のConfigMapを作成します:
kubectl create -f site1_dr_cm.yaml
次のコマンドを使用して、サイト2のConfigMapを作成します。
kubectl create -f site2_dr_cm.yaml

バックアップ/リストア・ジョブの作成

次のステップでは、rsyncコマンドを使用してプライマリの永続ボリュームをバックアップし、スタンバイ・システムにリストアするために定期的に実行されるジョブを作成する方法について説明します。

バックアップ/リストア・スクリプトの作成

永続ボリュームをバックアップし、そのバックアップをスタンバイ・サイトにコピーするスクリプトを作成する必要があります。デプロイメント自動化スクリプトには、このタスクを実行するサンプル・スクリプトが含まれています。このスクリプトは<product>_dr.shという名前で、SCRIPT_DIR/templates/<product>ディレクトリにあります。

たとえば、Oracle Access Managerの場合、ディザスタ・リカバリに使用する必要があるスクリプトは、SCRIPT_DIR/templates/oam/oam_dr.shにあります。次のいずれかの方法で、このスクリプトを永続ボリュームにコピーする必要があります:
  • デプロイメント内の実行中のコンテナにスクリプトをコピーする。
  • 永続ボリュームにアクセスするための単純なAlpineコンテナを作成する。
  • スクリプトが開発されているホストにNFSを一時的にマウントする。

このドキュメントでは、スクリプトをコピーする必要がある場所をdr_scriptsと呼びます。

スクリプトは両方のサイトで実行されます。サイトがプライマリ・モードの場合は、永続ボリュームのバックアップが作成され、サイト2に送信されます。サイトがスタンバイ・モードの場合は、サイト1から受信したバックアップがサイト2にリストアされます。バックアップまたはリストア操作を実行する前に、スクリプトで永続ボリュームのローカル・コピーを作成することをお薦めします。

次のステップに従って、スナップショットなどのNFSユーティリティを使用するか、rsyncコマンドを使用して、スクリプトで永続ボリュームのローカル・コピーを事前に作成することを強くお薦めします。

  1. バックアップを小さくするには、不要なファイルを除外します。
    EXCLUDE_LIST="--exclude=\".snapshot\" --exclude=\"backups\" --exclude=\"domains/*/servers/*/tmp\" --exclude=\"logs/*\" --exclude=\"dr_scripts\" --exclude=\"network\" --exclude \"domains/*/servers/*/data/nodemanager/*.lck\" --exclude \"domains/*/servers/*/data/nodemanager/*.pid\" --exclude \"domains/*/servers/*/data/nodemager/*.state\" --exclude \"domains/ConnectorDefaultDirectory\"--exclude=\"backup_running\""
  2. プライマリPVおよびスタンバイPVがマウントされるコンテナ内の場所を設定します。
    PRIMARY_BASE=/u01/primary_oampv
    DR_BASE=/u01/dr_oampv
    rsync -avz $EXCLUDE_LIST $PRIMARY_BASE/ $PRIMARY_BASE/backups/backup_date
  3. rsyncコマンドを使用して、バックアップをスタンバイ・サイトに転送します:
    rsync -avz $EXCLUDE_LIST $PRIMARY_BASE/backups/backup_date/ $DR_BASE/backups/backup_date
  4. スタンバイ・サイトで、rsyncコマンドを使用してバックアップをリストアします:
    rsync -avz $EXCLUDE_LIST $PRIMARY_BASE/backups/backup_date / $PRIMARY_BASE
  5. ドメインを検索して、プライマリ・データベースのスキャン・アドレスとサービスを、スタンバイ・サイトで使用されているものに変更します。
    1. 次のコマンドを使用して、変更が必要なファイルをすべて特定します:
      cd $PRIMARY_BASE/domains/$OAM_DOMAIN_NAME/config
      grep -rl "$REMOTE_SCAN" . | grep -v backup
    2. DR ConfigMapオブジェクトの正しい情報で関連ファイルを更新します。
バックアップ/リストア・スクリプトを定期的に実行するための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: OnFailure
たとえば:
apiVersion: 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の一時停止/再開
バックアップ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
初期化ジョブの作成
前に定義したCronJob (「バックアップ/リストア・スクリプトを定期的に実行するためのCronJobの作成」)を使用して、次のコマンドで1回かぎりのジョブを作成し、初期データ転送を実行します:
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を再起動して、データを定期的にコピーします。

次の項では、手順を詳しく説明します:

前提条件

次の前提条件を満たしていることを確認します。
  • ローカル・ポッドにリモート・ファイル・システムをマウントできること。このタスクには、ファイアウォールまたはセキュリティ・リストの権限が必要な場合があります。
  • サイト間でディスク・レプリケーションを実行できること。このタスクには、ファイアウォールまたはセキュリティ・リストの権限が必要な場合があります。
  • 手動レプリケーションを使用する場合は、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. 次の内容で、ouddr-pv.yamlファイルを作成します:
    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: oudpv-dr
      labels:
        type: edgdr-pv
    spec:
      storageClassName: manual
      capacity:
        storage: 30Gi
      accessModes:
        - ReadWriteMany
      nfs:
        path: <OUD_SHARE>
        server: <PV_SERVER>
    たとえば:
    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: oudpv-dr
      labels:
        type: edgdr-pv
    spec:
      storageClassName: manual
      capacity:
        storage: 30Gi
      accessModes:
        - ReadWriteMany
      nfs:
        path: /exports/IAMPVS/oudpv
        server: <REMOTE_PVSERVER>
  2. 次のコマンドを使用して、永続ボリュームを作成します:
    kubectl create -f ouddr-pv.yaml
  3. 次のコマンドを使用して、永続ボリュームが作成されたことを確認します:
    kubectl get pv
    出力内容は次のようになります:
    NAME                      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                            STORAGECLASS   REASON   AGE
    edg-oud-ds-rs-pv          30Gi       RWX            Delete           Bound    oudns/edg-oud-ds-rs-pvc          manual                  21d
    edg-oud-ds-rs-pv-config   10Gi       RWX            Retain           Bound    oudns/edg-oud-ds-rs-pvc-config   manual                  21d
    oudpv-dr                  30Gi       RWX            Retain           Bound    oudns/ouddr-pvc                  manual                  54m

    ノート:

    現在のOUDデプロイメントの永続ボリュームと、リモートのOUDデプロイメント用に作成された新しいボリュームが表示されます。

この永続ボリュームは、サイト1とサイト2の両方に作成する必要があります。サイト1のREMOTE_PV_SERVERがサイト2のPVSERVERを指し、サイト2のREMOTE_PV_SERVERがサイト1のPVSERVERを指していることを確認します。両方のサイトにPVを作成することにより、サイト1とサイト2の役割を元に戻す必要がある場合に、構成をすぐに利用できます。

リモートの永続ボリュームに対する永続ボリューム要求の作成

リモートのOUD永続ボリューム用の永続ボリューム要求を作成するには:

  1. 次の内容で、ouddr-pvc.yamlを作成します:
    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: ouddr-pvc
      namespace: <OUDNS>
      labels:
        type: ouddr-pvc
    spec:
      storageClassName: manual
      accessModes:
      - ReadWriteMany
      resources:
         requests:
           storage: 30Gi
      selector:
        matchLabels:
          type: edgdr-pv
    たとえば:
    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: ouddr-pvc
      namespace: oudns
      labels:
        type: ouddr-pvc
    spec:
      storageClassName: manual
      accessModes:
      - ReadWriteMany
      resources:
         requests:
           storage: 30Gi
      selector:
        matchLabels:
          type: edgdr-pv
  2. 次のコマンドを使用して、永続ボリューム要求を作成します:
    kubectl create -f ouddr-pvc.yaml
  3. 次のコマンドを使用して、永続ボリュームが作成されたことを確認します:
    kubectl get pvc -n <OUDNS>
    出力は次のようになります:
    NAME                       STATUS   VOLUME                    CAPACITY   ACCESS MODES   STORAGECLASS   AGE
    edg-oud-ds-rs-pvc          Bound    edg-oud-ds-rs-pv          30Gi       RWX            manual         21d
    edg-oud-ds-rs-pvc-config   Bound    edg-oud-ds-rs-pv-config   10Gi       RWX            manual         21d
    ouddr-pvc                  Bound    oudpv-dr                  30Gi       RWX            manual         63m

    ノート:

    現在のOUDデプロイメントの永続ボリューム要求と、リモートの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_scripts
kubectl cp <WORKDIR>/oud_dr.sh <OUDNS>/<OUD_POD_PREFIX>-oud-ds-rs-0:/u01/oracle/user_projects/dr_scripts
kubectl 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_scripts
kubectl cp /workdir/OUD/oud_dr.sh oudns edg-oud-ds-rs-0:/u01/oracle/user_projects/dr_scripts
kubectl exec -n oudns -ti edg-oud-ds-rs-0 -- chmod 750 /u01/oracle/user_projects/dr_scripts/oud_dr.sh
サイトの特性を決定するConfigMapの作成

「DR ConfigMapの作成」を参照してください。

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-values
たとえば:
helm 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-values

自動同期プロセスの開始

サイト1でCronJobを起動し、サイト1の永続ボリュームからサイト2に、定期的に変更を同期します。「CronJobの一時停止/再開」を参照してください。

Oracle Access Managerのディザスタ・リカバリの構成

Oracle Access Manager (OAM)のディザスタ・リカバリは、アクティブ/パッシブ・ソリューションです。

次の項では、手順を詳しく説明します:

前提条件

Oracle Access Managerのディザスタ・リカバリを有効化する前に、次のことを確認します:

  • Data Guardのプライマリ・サイトとスタンバイ・サイトが相互に通信していること。
  • ファイル・システム・レプリケーションのプライマリ・サイトとスタンバイ・サイトが相互に通信していること。
  • プライマリ・サイトとスタンバイ・サイトの両方のKubernetesクラスタが、すべてのサイトのNFSサーバー名を解決できること。
  • 各Kubernetesクラスタが独立していること。
  • 実行中のKubernetesクラスタが両方のサイトに存在すること。

プライマリ・サイトからのディザスタ・リカバリ・サイトの作成

プライマリ・サイト:
  1. OAMデータ(oampv)が格納されている永続ボリュームのバックアップを作成します。「永続ボリュームを同期するKubernetes CronJobの作成」を参照してください。OAMのファイル除外リストは、次のように定義されています:
    EXCLUDE_LIST="--exclude=\".snapshot\" --exclude=\"backups\" --exclude=\"domains/*/servers/*/tmp\" --exclude=\"logs/*\" --exclude=\"dr_scripts\" --exclude=\"network\" --exclude \"domains/*/servers/*/data/nodemanager/*.lck\" --exclude \"domains/*/servers/*/data/nodemanager/*.pid\" --exclude \"domains/*/servers/*/data/nodemager/*.state\" --exclude \"domains/ConnectorDefaultDirectory\"--exclude=\"backup_running\""
  2. スタンバイ・サイトでのリストア用にKubernetesオブジェクトをバックアップします。「Kubernetesオブジェクトのバックアップとリストア」を参照してください。
  3. プライマリ・サイトとスタンバイ・サイトの間にOracle Data Guardを設定します。「Data Guardデータベースの作成」を参照してください。
  4. プライマリ・サイトで使用されているデータベース・サービスが、スタンバイにレプリケートされていることを確認します。データベースがPRIMARYまたはSNAPSHOT STANDBYのロールで実行されている場合、これらのサービスはアクティブであることが必要です。「データベース・サービスの作成」を参照してください。

スタンバイ・サイトでのディザスタ・リカバリ・サイトの作成

スタンバイ・サイトでディザスタ・リカバリ・サイトを作成する方法には、次の2つがあります:

サイト2に使い捨ての新しい環境を作成

  1. プライマリ・サイトと同じ値を使用して、サイト2に使い捨てのデプロイメントを作成します。EDG自動化スクリプトを使用した場合、変更が必要なのは、レスポンス・ファイルのワーカー・ノードとPVサーバーの値のみです。
  2. サイト2で実行されているKubernetesポッドを停止します。
  3. 永続ボリュームの内容を削除します。
  4. サイト1で取得したバックアップから、永続ボリュームのバックアップをリストアします。「永続ボリュームを同期するKubernetes CronJobの作成」を参照してください。
  5. リストアされたバックアップのデータベース接続文字列を修正し、サイト2のデータベースを指すようにします。
  6. リストアされたバックアップからサイト2のOracle HTTP Serverに、WebGateオブジェクトをコピーします。
  7. ディザスタ・リカバリ・サイトが機能していることを確認します。
  8. 初期インストールの実行に使用した使い捨てデータベースを削除します。

サイト2でKubernetesのリストアを実行

  1. スタンバイ・サイトのNFSサーバーを指すように、OAMドメインの永続ボリュームを作成します。unresolvable-reference.html#GUID-373A3448-D7BA-41F6-BFDB-4D7DDB2B03F1を参照してください。
  2. 次のData Guard Brokerコマンドを使用して、スタンバイ・データベースをスナップショット・スタンバイとして開きます:
    dgmgrl sys/Password
    show configuration
    convert database standby_db_name to snapshot standby
  3. サイト1で取得した永続ボリュームのバックアップをリストアします。「永続ボリュームを同期するKubernetes CronJobの作成」を参照してください。
  4. サイト1で取得したバックアップから、Kubernetesオブジェクトのバックアップをリストアします。「Kubernetesオブジェクトのバックアップとリストア」を参照してください。
  5. リストアされたバックアップのデータベース接続文字列を修正し、サイト2のデータベースを指すようにします。
  6. リストアされたバックアップからサイト2のOracle HTTP Serverに、WebGateオブジェクトをコピーします。
  7. ディザスタ・リカバリ・サイトが機能していることを確認します。
  8. 次のData Guard Brokerコマンドを発行して、スタンバイ・データベースを回復します:
    dgmgrl sys/Password
    show configuration
    convert database standby_db_name to physical standby

    データベースをスイッチオーバーし、デプロイメントが完全に機能していることを確認します。

Oracle Identity Governanceのディザスタ・リカバリの構成

Oracle Identity Governance (OIG)のディザスタ・リカバリは、アクティブ/パッシブ・ソリューションです。

次の項では、手順を詳しく説明します:

前提条件

Oracle Identity Governanceのディザスタ・リカバリを有効化する前に、次のことを確認します:

  • ファイル・システム・レプリケーションのプライマリ・サイトとスタンバイ・サイトが相互に通信していること。
  • プライマリ・サイトのデータベース・システムが、データベース・レプリケーションのために相互に通信していること。
  • プライマリ・サイトとスタンバイ・サイトの両方のKubernetesクラスタが、すべてのサイトのNFSサーバー名を解決できること。
  • 各Kubernetesクラスタが独立していること。
  • 実行中のKubernetesクラスタが両方のサイトに存在すること。

プライマリ・サイトからのディザスタ・リカバリ・サイトの作成

プライマリ・サイト:
  1. OIGデータ(oigpv)が格納されている永続ボリュームのバックアップを作成します。「永続ボリュームを同期するKubernetes CronJobの作成」を参照してください。OIGのファイル除外リストは、次のように定義されています:
    EXCLUDE_LIST="--exclude=\".snapshot\" --exclude=\"backups\" --exclude=\"domains/*/servers/*/tmp\" --exclude=\"logs/*\" --exclude=\"dr_scripts\" --exclude=\"network\" --exclude \"domains/*/servers/*/data/nodemanager/*.lck\" --exclude \"domains/*/servers/*/data/nodemanager/*.pid\" --exclude \"domains/*/servers/*/data/nodemager/*.state\" --exclude \"domains/ConnectorDefaultDirectory\" --exclude=\"backup_running\""
  2. スタンバイ・サイトでのリストア用にKubernetesオブジェクトをバックアップします。「Kubernetesオブジェクトのバックアップとリストア」を参照してください。
  3. プライマリ・サイトとスタンバイ・サイトの間にOracle Data Guardを設定します。

スタンバイ・サイトでのディザスタ・リカバリ・サイトの作成

スタンバイ・サイトでディザスタ・リカバリ・サイトを作成する方法には、次の2つがあります:

サイト2に使い捨ての新しい環境を作成

  1. プライマリ・サイトと同じ値を使用して、サイト2に使い捨てのデプロイメントを作成します。EDG自動化スクリプトを使用した場合、変更が必要なのは、レスポンス・ファイルのワーカー・ノードとPVサーバーの値のみです。
  2. サイト2で実行されているKubernetesポッドを停止します。
  3. 永続ボリュームの内容を削除します。
  4. サイト1で取得したバックアップから、永続ボリュームのバックアップをリストアします。「永続ボリュームを同期するKubernetes CronJobの作成」を参照してください。
  5. リストアされたバックアップのデータベース接続文字列を修正し、サイト2のデータベースを指すようにします。
  6. ディザスタ・リカバリ・サイトが機能していることを確認します。
  7. 初期インストールの実行に使用した使い捨てデータベースを削除します。

サイト2でKubernetesのリストアを実行

  1. スタンバイ・サイトのNFSサーバーを指すように、OIGドメインの永続ボリュームを作成します。unresolvable-reference.html#GUID-CF07EE44-34D9-4F36-97BE-6B3FBB4FCEA8を参照してください。
  2. 次のData Guard Brokerコマンドを使用して、スタンバイ・データベースをスナップショット・スタンバイとして開きます:
    dgmgrl sys/Password
    show configuration
    convert database standby_db_name to snapshot standby
  3. サイト1で取得した永続ボリュームのバックアップをリストアします。「永続ボリュームを同期するKubernetes CronJobの作成」を参照してください。
  4. サイト1で取得したバックアップから、Kubernetesオブジェクトのバックアップをリストアします。「Kubernetesオブジェクトのバックアップとリストア」を参照してください。
  5. リストアされたバックアップのデータベース接続文字列を修正し、サイト2のデータベースを指すようにします。
  6. ディザスタ・リカバリ・サイトが機能していることを確認します。
  7. 次のData Guard Brokerコマンドを発行して、スタンバイ・データベースを回復します:
    dgmgrl sys/Password
    show configuration
    convert 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ファイルの内容が使用されます。
プライマリ・サイトからのディザスタ・リカバリ・サイトの作成

プライマリ・サイト:

  1. workpv (OIRI-CLIコンテナで/app/k8sとしてマウントされています)にある既存のca.crtおよびconfigファイルのコピーを作成します。これらのファイルは、それぞれprimary_ca.crtおよびprimary_configと呼びます。
  2. OIRIデータ(oiripvdingpvおよびworkpv)が格納されている永続ボリュームのバックアップを作成します。「永続ボリュームを同期するKubernetes CronJobの作成」を参照してください。OIRIのファイル除外リストは、次のように定義されています:
    EXCLUDE_LIST="--exclude=\".snapshot\" --exclude=\"backups\" --exclude=\"dr_scripts\" --exclude=\"backup_running\""
  3. スタンバイ・サイトでのリストア用にKubernetesオブジェクトをバックアップします。「Kubernetesオブジェクトのバックアップとリストア」を参照してください。
  4. プライマリ・サイトとスタンバイ・サイトの間にOracle Data Guardを設定します。「Data Guardデータベースの作成」を参照してください。
  5. プライマリ・サイトで使用されているデータベース・サービスが、スタンバイにレプリケートされていることを確認します。データベースがPRIMARYおよびSNAPSHOTスタンバイのロールで実行されている場合、これらのサービスはアクティブであることが必要です。「データベース・サービスの作成」を参照してください。
スタンバイ・サイトでのディザスタ・リカバリ・サイトの作成

スタンバイ・サイトでディザスタ・リカバリ・サイトを作成する方法には、次の2つがあります:

サイト2に使い捨ての新しい環境を作成

  1. プライマリ・サイトと同じ値を使用して、サイト2に使い捨てのデプロイメントを作成します。EDG自動化スクリプトを使用した場合、変更が必要なのは、レスポンス・ファイルのワーカー・ノードとPVサーバーの値のみです。
  2. スタンバイ・サイトで生成されたca.crtおよびconfigファイルを、プライマリ・サイトのworkpvにコピーします。これらのファイルは、それぞれstandby_ca.crtおよびstandby_configと呼びます。
  3. サイト2で実行されているKubernetesポッドを停止します。
  4. 永続ボリュームの内容を削除します。
  5. サイト1で取得したバックアップから、永続ボリュームのバックアップをリストアします。「永続ボリュームを同期するKubernetes CronJobの作成」を参照してください。
  6. リストアされたバックアップのデータベース接続文字列を修正し、サイト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
  7. リストアされたバックアップの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
  8. Kubernetes構成ファイルをスタンバイ・サイトに適切なコピーに切り替えます。たとえば:
    cp /app/k8s/standby_ca.crt /app/k8s/ca.crt
    cp /app/k8s/standby_ca.crt /app/ca.crt
    cp /app/k8s/standby_config.crt /app/k8s/config
  9. ディザスタ・リカバリ・サイトが機能していることを確認します。
  10. サイト2で、初期インストールの作成に使用した使い捨てデータベースを削除します。

サイト2でKubernetesのリストアを実行

  1. スタンバイ・サイトのNFSサーバーを指すように、OIRI永続ボリューム用の永続ボリュームを作成します。unresolvable-reference.html#GUID-CF07EE44-34D9-4F36-97BE-6B3FBB4FCEA8を参照してください。
  2. 次のData Guard Brokerコマンドを使用して、スタンバイ・データベースをスナップショット・スタンバイとして開きます:
    dgmgrl sys/Password
    show configuration
    convert database standby_db_name to snapshot standby
  3. サイト1で取得した永続ボリュームのバックアップをリストアします。「永続ボリュームを同期するKubernetes CronJobの作成」を参照してください。
  4. サイト1で取得したバックアップから、Kubernetesオブジェクトのバックアップをリストアします。「Kubernetesオブジェクトのバックアップとリストア」を参照してください。
  5. スタンバイ・システムでOIRI-CLIコンテナを起動します。「管理CLIの起動」を参照してください。
  6. スタンバイ・サイトに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
  7. リストアされたバックアップのデータベース接続文字列を修正し、サイト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
  8. リストアされたバックアップの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
  9. Kubernetes構成ファイルをスタンバイ・サイトに適切なコピーに切り替えます。たとえば:
    cp /app/k8s/standby_ca.crt /app/k8s/ca.crt
    cp /app/k8s/standby_ca.crt /app/ca.crt
    cp /app/k8s/standby_config.crt /app/k8s/config
  10. ディザスタ・リカバリ・サイトが機能していることを確認します。
  11. 次のData Guard Brokerコマンドを使用して、スタンバイ・データベースを回復します:
    dgmgrl sys/Password
    show configuration
    convert database standby_db_name to physical standby

    データベースをスイッチオーバーし、デプロイメントが完全に機能していることを確認します。

  12. プライマリ・サイトからスタンバイ・サイトに、永続ボリュームを定期的に再コピーします。たとえば、週に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証明書を使用する必要があります。

ディザスタ・リカバリ・サイトの作成

OAAは、Kubernetesフレームワークに緊密に統合されています。OAAをデプロイすると、OAAには、実行されているクラスタ名などの情報が格納されます。そのため、永続ボリュームをレプリケートするときには、この情報を除外する必要があります。

プライマリ・サイトからのディザスタ・リカバリ・サイトの作成

プライマリ・サイト:

  1. OAAデータ(oaaconfigpvoaacreadpvoaavaultpvおよびoaalogspv)が格納されている永続ボリュームのバックアップを作成します。「永続ボリュームを同期するKubernetes CronJobの作成」を参照してください。OAAのファイル除外リストは、次のように定義されています:
    EXCLUDE_LIST="--exclude=\".snapshot\" --exclude=\"backups\" --exclude=\"dr_scripts\" --exclude=\"backup_running\" --exclude=\"k8sconfig\" --exclude=\"ca.crt\""
  2. プライマリ・サイトとスタンバイ・サイトの間にOracle Data Guardを設定します。
  3. プライマリ・サイトで使用されているデータベース・サービスが、スタンバイにレプリケートされていることを確認します。データベースがPRIMARYおよびSNAPSHOTスタンバイのロールで実行されている場合、これらのサービスはアクティブであることが必要です。「データベース・サービスの作成」を参照してください。
スタンバイ・サイトでのディザスタ・リカバリ・サイトの作成

スタンバイ・サイト:

  1. 次のData Guard Brokerコマンドを使用して、スタンバイ・データベースをスナップショット・スタンバイとして開きます:
    dgmgrl sys/Password
    show configuration
    convert database standby_db_name to snapshot standby
  2. サイト1で取得した永続ボリュームのバックアップをリストアします。「永続ボリュームを同期するKubernetes CronJobの作成」を参照してください。
  3. OAAのネームスペースを作成します(これは、プライマリ・サイトのネームスペースと同一にする必要があります)。「Kubernetesネームスペースの作成」を参照してください。
  4. コンテナ・レジストリ・シークレットを作成します。「コンテナ・レジストリ・シークレットの作成」を参照してください。
  5. OAA管理コンテナを作成します。「管理コンテナの起動」を参照してください。
  6. OAA管理コンテナに、Kubernetesクラスタへのアクセス権を付与します。「Kubernetesクラスタへの管理コンテナ・アクセス権の付与」を参照してください。
  7. プライマリ・サイトからコピーしたinstallOAA.propertiesファイルを変更します。このファイルは、OAA管理コンテナの/u01/oracle/scripts/settingsディレクトリにあります。「OAAプロパティ・ファイルの作成」を参照してください。
    次の変更を加えます。
    • database.hostをスタンバイ・データベースのスキャン・アドレスに変更します。
    • database.createschema=falseを設定します。
  8. OAA.shスクリプトを実行して、OAAデプロイメントを再作成します。「Oracle Advanced Authenticationのデプロイ」を参照してください。
  9. OAAポッドが正常に起動することを確認します。
  10. 次のData Guard Brokerコマンドを使用して、スタンバイ・データベースを回復します:
    dgmgrl sys/Password
    show configuration
    convert database standby_db_name to physical standby

    データベースをスイッチオーバーし、デプロイメントが完全に機能していることを確認します。

  11. プライマリ・サイトからスタンバイ・サイトに、永続ボリュームを定期的に再コピーします。たとえば、週に1回、またはOAAデプロイメントに構成の変更を加えるごとです。