1. Oracle SOA SuiteのハイブリッドDRソリューションの構成
  2. OCIでのWeb層の準備

OCIでのWeb層の準備

プライマリ・オンプレミス・サイトと一致するように、Oracle Cloud Infrastructure (OCI)でセカンダリ・サイトをプロビジョニングして構成します。

ノート:

この項で説明するリソース(OCI Load Balancer、SSL証明書、バックエンド・セットとバックエンド、ルーティング・ポリシー、リスナーおよびルール・セット)を作成するTerraformコードは、「コードのダウンロード」にあります。

(オプション)Oracle HTTP Serverホストの準備

Oracle Cloud InfrastructureでOracle HTTP Serverコンピュート・インスタンスを作成および構成します。

ノート:

Oracle HTTP Serverの作成および構成はオプションです。OCI Load Balancerのみを使用して(Oracle HTTP Serverを使用せずに)、OCIでWeb層を構成できます。

Oracle HTTP Serverホストのプロビジョニング

Create a compute instance on the Oracle Cloud Infrastructure (OCI) web-tier subnet for each primary, on-premises Oracle HTTP Server host.コンピュート・インスタンスでは、オンプレミスOracle HTTP Serverホストで使用されるイメージおよびシェイプに最も類似しているOSイメージおよびコンピュート・シェイプを使用する必要があります。

OCIで実行されている各Oracle HTTP Serverには、オンプレミスで実行されているOracle HTTP Serverをカバーするために使用されるライセンスおよびサポート契約に加えて、有効なライセンスおよびサポート契約が必要です。Oracle WebLogic Server for OCIイメージを使用して、Oracle CloudでOracle HTTP Serverのコンピュート・インスタンスを作成できます。これらのイメージを使用して作成されたコンピュート・インスタンスには、Oracle HTTP Serverを実行する権限が含まれ、WebLogicソフトウェアが実行中状態の場合に権限がOCPU/時間ごとに請求されます。Oracle WebLogic Server for OCIを使用してコンピュート・インスタンスを作成する場合は、コンピュート・インスタンス・コンソールまたはマーケットプレイスを使用できます。これらのイメージは、Oracle Linux 7.9およびOracle Linux 8.5オペレーティング・システムで使用できます。

この例では、表に示すように、コンパートメント内の1つの可用性ドメインにある2つのコンピュート・インスタンスを使用します。

名前 コンパートメント 可用性ドメイン イメージ 形状 VCN サブネット
hydrohs1 HyDRCompmt AD1 Oracle WebLogic Enterprise Edition UCMイメージ(Oracle Linux 7.9) VM.Standard2.2 Hydrvcn webTierSubnet
hydrohs2 HyDRCompmt AD1 Oracle WebLogic Enterprise Edition UCMイメージ(Oracle Linux 7.9) VM.Standard2.2 Hydrvcn webTierSubnet

コンピュート・インスタンス・コンソールを使用してコンピュート・インスタンスをプロビジョニングするには、次を実行します:

  1. テナンシのOCIコンソールにログインします。
  2. 適切な地域を選択します。
  3. ナビゲーション・メニューをクリックし、「コンピュート」を選択します。「インスタンス」、「インスタンスの作成」の順にクリックします。
  4. コンピュート・インスタンスおよびコンパートメントの名前を入力します。
  5. 「配置」で、インスタンスを作成する可用性ドメインを選択します。OCIリージョンに複数の可用性ドメインがある場合は、WebLogicコンピュート・インスタンスを別の可用性ドメインに配置できます。
  6. 「イメージとシェイプ」で、「イメージの変更」をクリックし、次を実行します:
    1. 「イメージ・ソース」ドロップダウン・リストから、「Oracleイメージ」を選択し、「Oracle WebLogic Server for OCI」イメージのリストから「Oracle WebLogic Server Enterprise Edition UCMイメージ」を選択します。
    2. 選択したイメージについて、右側の矢印をクリックし、有料イメージのイメージ・ビルド・バージョンを選択します。
      • Oracle Linux 7.9 (release- ol7.9- build- timestampというラベル)
      • Oracle Linux 8.5 (release- ol8.5- build- timestampというラベルが付いています)
    3. 契約条件を確認します。「Oracle使用条件」チェック・ボックスを選択し、「イメージの選択」をクリックします。
  7. 「イメージとシェイプ」で、「シェイプの変更」をクリックします。「インスタンス・タイプ」を選択し、プライマリ・ホストに最も類似したシェイプを選択します。
    サポートされているシェイプのリストは、Oracle WebLogic Server for OCIのイメージを参照してください。
  8. 環境のVCN、サブネット(Web層サブネット)および可用性ドメインを選択します。
    容量タイプおよびフォルト・ドメインを指定するには、「拡張オプションの表示」をクリックします。
  9. インスタンスのネットワークを構成します。詳細なネットワーク設定を指定するには、「詳細オプションの表示」をクリックします。
  10. 「SSHキーの追加」で、キーの生成、公開キーのアップロードまたはキーの貼付けを行います。
  11. 「Boot Volume」で、インスタンスのブート・ボリュームのサイズと暗号化のオプションを指定します。
  12. 「拡張オプションの表示」をクリックして、詳細設定を構成します。
  13. 「作成」をクリックします。
  14. このステップを繰り返して、別のコンピュート・インスタンスを作成します。

オペレーティング・システム・ユーザーおよびグループの準備

セカンダリ・コンピュート・インスタンスには、プライマリ・オンプレミスのOracleソフトウェアで使用されているものと同じユーザーおよびグループが必要です。

Oracle WebLogic Server for Oracle Cloud Infrastructureイメージには、すでにoracleユーザーおよびグループがあります。ただし、これらの値(ユーザー名、グループ名、uidおよびgid)はプライマリ・インスタンスにある値と一致しない可能性があるため、プライマリoracleユーザーおよびグループの値と一致するようにセカンダリ・ホストを構成する必要があります。次の例は、プライマリoracleユーザーおよびグループの値と一致するようにこの層のセカンダリ・ホストを構成する方法を示しています。

OCIコンピュート・インスタンス内の各グループおよびユーザーは、すべてのノードでプライマリと同じIDを持つ必要があります。
  1. oracleユーザーを使用してオンプレミス・ホストにログインし、コマンドidを使用して、プライマリ・ホスト内のoracleユーザーのユーザー、グループおよびIDを識別します。
    [oracle@host3.myopnetwork.com ~]$ id
uid=1001(oracle) gid=1002(oinstall) groups=1002(oinstall),1001(dba)

[oracle@host3.myopnetwork.com ~]$ more /etc/passwd | grep oracle
oracle:x:1001:1002::/home/oracle:/bin/bash

    次の表に、一般的なオンプレミス環境のサンプル・ユーザーおよびグループを示します。

    ユーザーまたはグループ 名前 ID 説明
    ユーザー oracle 1001 Oracleソフトウェアの所有者
    グループ oinstall 1002 oracleユーザーのプリンシパル・グループ
    dba 1001 oracleユーザーのセカンダリ・グループ
  2. SSHを使用して最近作成したインスタンスにopcユーザーとしてアクセスし、セカンダリ・ホストに存在するユーザー、グループおよびIDを特定します。opcユーザーでセカンダリ・ホストにログインし、sudoでoracleユーザーにログインし、コマンドidを実行します。
    [opc@hydrsoa1 ~]$ sudo su - oracle
[oracle@hydrsoa1 ~]$ id
uid=1001(oracle) gid=1001(oracle) groups=1001(oracle),1002(docker) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

    次の表に、セカンダリ・コンピュート・インスタンスにすでに存在するoracleユーザーおよびグループを示します。

    ユーザーまたはグループ 名前 ID 説明
    ユーザー oracle 1001 Oracleソフトウェアの所有者
    グループ oracle 1001 oracleユーザーのプリンシパル・グループ
    docker 1002 oracleユーザーのセカンダリ・グループ
  3. 使用可能なシナリオと解決策を次に示します。
    • セカンダリ内のユーザーおよびグループは、プライマリと異なる名前およびIDです。

      解答: プライマリに存在するユーザーとグループをセカンダリに作成します。

    • セカンダリ内のユーザーおよびグループは名前が同じですが、プライマリとIDが異なります。

      解答: プライマリのIDと一致するようにセカンダリ内のIDを変更します。

    • セカンダリ内のユーザーおよびグループは、プライマリと異なる名前ですが、同じIDです。

      解答: セカンダリ内のユーザーおよびグループの名前を変更します。

    • 競合があります。プライマリ・ユーザーまたはグループの一部のIDは、セカンダリ内の他のユーザーまたはグループによって使用されます。

      解答: セカンダリ内の競合するユーザーまたはグループのIDを変更して競合を修正し、セカンダリに1つ以上のグループを作成して、プライマリのユーザーまたはグループと一致させます。

    次の表に、競合を解決するために使用できるコマンドの概要を示します。

    アクション コマンド(rootとして実行)
    新しいグループを作成するには groupadd group_name -g group_id

    例:

    groupadd oinstall -g 1002 groupadd dba -g 1001
    新しいユーザーを作成するには useradd -u user_id user_name -g principal_group -G other groups

    例:

    useradd -u 1001 oracleuser -g oinstall -G dba
    ユーザーのプライマリ・グループを変更するには usermod -g new_primary_groupname user_name
    グループにユーザーを追加するには usermod -a -G secondary_groupname user_name
    ユーザーのIDを変更するには

    usermod -u new_id user_name

    find / -user old_uid -exec chown -h user_name {} \;

    たとえば、次の例では、ユーザーoracleのIDが1001から501に変更されます。

    usermod -u 501 oracle

    find / -user 1001 -exec chown -h oracle {} \;
    グループのIDを変更するには

    groupmod -g new_id group_name

    find / -group old_id -exec chgrp -h group_name {} \;

    たとえば、次の例では、グループoracleのIDが1001から501に変更されます。

    groupmod -g 501 oracle

    find / -user 1001 -exec chgrp -h oracle {} \;

    ノート:

    Oracleでは、セカンダリOCIコンピュート・インスタンスで変更を実行することをお薦めします。プライマリのID値は変更できません。

    次の例では、プライマリホストで使用されているグループのIDが、セカンダリホスト内のほかのグループですでに使用されています。この競合を解決するには、次のアクションが必要です。

    1. セカンダリ内のグループdockerはID 1002を使用していますが、これはプライマリ・グループoinstallのIDと競合します。
      競合を解決するには、セカンダリ・ホスト内のグループdockerのIDを、競合しない別のIDに変更します。たとえば、新しいIDとして1005を選択し、/etc/groupファイルに表示されないことを確認して使用されていないことを確認します。
      [opc@hydrsoa1 ~]$ sudo -s  
[root@hydrsoa1 ~]$ more /etc/group | grep 1005
      IDが使用されていないことを確認したら、グループのIDを新しいIDに変更します。
      [opc@hydrsoa1 ~]$ sudo -s 
[root@hydrsoa1 ~]$ groupmod -g 1005 docker
[root@hydrsoa1 ~]$ find / -group 1002 -exec chgrp -h docker {} \;
    2. セカンダリ内のグループoracleはID 1001を使用しますが、これはプライマリ・グループdbaのIDと競合します。
      競合を解決するには、セカンダリ・ホスト内のグループoracleのIDを、競合しない別のIDに変更します。たとえば、新しいIDとして1006を選択し、/etc/groupファイルに表示されないことを確認して使用されていないことを確認します。
      [opc@hydrsoa1 ~]$ sudo -s 
[root@hydrsoa1 ~]$ more /etc/group | grep 1006
      IDが使用されていないことを確認したら、グループのIDを新しいIDに変更します。
      [opc@hydrsoa1 ~]$ sudo -s 
[root@hydrsoa1 ~]$ groupmod -g 1006 oracle
[root@hydrsoa1 ~]$ find / -group 1001 -exec chgrp -h oracle {} \;
    3. プライマリIDと同じIDを持つセカンダリ・ホストにoracleユーザーのグループoinstallおよびdbaを作成します。 
      [opc@hydrsoa1 ~]$ sudo -s
[root@hydrsoa1 ~]$ groupadd oinstall -g 1002
[root@hydrsoa1 ~]$ groupadd dba -g 1001
    4. ユーザーoracleの名前とIDはプライマリとスタンバイの両方で同じであるため、変更は必要ありません。
      ただし、セカンダリ・ホストでユーザーのメイン・グループをoinstallに変更する必要があります。
      [root@hydrsoa1 ~]$ usermod -g oinstall oracle
      次に、ユーザーをグループdbaに追加します。 
      [root@hydrsoa1 ~]$ usermod -a -G dba oracle
    5. セカンダリ・ホストのoracleユーザーのコマンドidの出力が、メイン・グループおよびセカンダリ・グループのプライマリと一致することを確認します。
      プライマリでの出力: 
      [oracle@host3.myopnetwork.com ~]$ id
uid=1001(oracle) gid=1002(oinstall) groups=1002(oinstall),1001(dba)
      セカンダリでの出力(セカンダリは追加のグループを持つことができます): 
      oracle@hydrsoa1 ~]$ id
uid=1001(oracle) gid=1002(oinstall) groups=1002(oinstall),1001(dba),1005(docker)
        …
    6. (推奨)これらの変更後にホストのリブートを実行します。
  4. (オプションですが推奨) oracleユーザーへのSSHアクセスを有効にします。
    このDRトポロジでは、ファイル・システムのコンテンツをプライマリからセカンダリにコピーするために使用されるコマンドをoracleユーザーが直接実行できるようになるため、このDRトポロジで役立ちます。
    1. コンピュート・インスタンスへの接続に使用する公開キーをテキスト・ファイルにコピーします。これは、この手順の後半で使用します。
    2. インスタンスにログインし、rootユーザーにsudoします。
    3. 新規ユーザーのホーム・ディレクトリで.sshディレクトリを作成します。
      mkdir -p /home/oracle/.ssh
    4. コンピュートへの接続に使用するSSH公開キーをファイルにコピーします。
      /home/oracle/.ssh/authorized_keys
    5. /home/oracle/.sshディレクトリの所有者およびグループをoracleユーザーに変更します。
      chown -R oracle:oinstall /home/oracle/.ssh
    6. oracleユーザーおよび秘密キーを使用してSSHで接続して、接続を確認します。
    7. authorized_keysファイルの権限を600にします。
      chmod 600 /home/oracle/.ssh/authorized_keys

オペレーティングシステムの要件の準備

Oracle HTTP Serverバイナリは、プライマリOracle HTTP ServerホストからセカンダリOracle HTTP Serverホストにコピーされます。したがって、セカンダリ・ホストでruninstallerを実行する必要はありません。Oracle WebLogic Server for Oracle Cloud InfrastructureイメージはWebLogicソフトウェア用に準備されているため、WebLogicのパッケージを手動で追加する必要はありません。ただし、これらのOracle HTTP ServerホストはOracle HTTP Server製品を実行します。セカンダリ・ホストがOracle HTTP Serverの要件を満たしていることを確認します。
  1. ご使用の環境が、プライマリ・ホストにインストールされている製品の最小インストール要件を満たしていることを確認します。Oracle Fusion Middlewareのシステム要件と仕様の対応するドキュメントを確認してください。
  2. 使用しているバージョンおよびOSに必要なシステムパッケージを確認します。
  3. yumを使用して、欠落しているシステム・パッケージをインストールします。

    この例では、Oracle HTTP Server 12.2.1.4およびOracle Linux 7を使用します。必要なパッケージの一部は、Oracle Cloud Infrastructure (OCI)中間層コンピュート・インスタンスにすでにインストールされています。この例では、次のものがなく、yumを使用してインストールする必要がありました。 

    yum install compat-libcap1.x86_64
yum install compat-libstdc++-33.x86_64
yum install compat-libstdc++-33.i686 
yum install gcc-c++.x86_64
yum install libaio-devel.x86_64
yum install libstdc++.i686    
yum install libstdc++-devel.x86_64
yum install dejavu-serif-fonts
yum install numactl.x86_64
yum install numactl-devel.x86_64
yum install motif.x86_64
yum install motif-devel.x86_64
yum install redhat-lsb.x86_64
yum install xorg-x11-utils.x86_64
  4. /etc/security/limits.confファイルにファイルおよびprocの制限を構成します。オンプレミスのOracle HTTP Serverホストの制限を確認し、それに応じてOCI Oracle HTTP Serverコンピュート・インスタンスの値を設定します。

Oracle HTTP Serverのホスト名別名の準備

プライマリ環境のOracle HTTP Serverホストによって使用されるのと同じ仮想ホスト名を、セカンダリOracle Cloud Infrastructure (OCI) Oracle HTTP Serverコンピュート・インスタンスの別名として構成しますが、セカンダリ・ホストのIPアドレスを指定します。

これは、次の2つの方法で実装できます。

  • Oracle WebLogic Server for OCIコンピュート・インスタンスの/etc/hostsファイルに別名としてホスト名を追加します。
  • セカンダリOCI VCNでプライベートDNSビューを使用します。
/etc/hostsファイルの使用
プライマリ・サーバーの別名として使用される仮想ホスト名は、セカンダリ・ホストのIPアドレスを指し示して、セカンダリ・ホストの/etc/hostsファイルに追加されます。 このモードは、DNSサーバーがプライマリ・オンプレミスとセカンダリOracle Cloud Infrastructure (OCI)サイトで同じである場合、およびプライマリ・サイトとセカンダリ・サイトで分離されたDNSサーバーが使用されている場合、すべてのシナリオで有効です。/etc/hostsファイルのエントリは、DNS解決よりも優先されます。これは、/etc/nsswitch.confファイルのディレクティブhostsにあらかじめ定義されている優先順位であるためです。

ただし、この方法では、すべてのOracle HTTP Serverホストにエントリを手動で追加する必要があります:

  1. 各Oracle HTTP Serverコンピュート・インスタンスの/etc/oci-hostname.confファイルを編集し、インスタンスの再起動後も/etc/hostsエントリを保持するようにプロパティPRESERVE_HOSTINFO=3を設定します。
  2. コマンドhostname --fqdnを使用して、OCIコンピュート・インスタンスの完全なホスト名を識別します。
  3. OCI Oracle HTTP Serverコンピュート・インスタンスの/etc/hostsファイルに次のエントリを追加します: 
    #################################
# ALIASES for SOA DR
#################################
# Aliases of the Oracle HTTP Server hosts
ohshost1_compute_instance_IP  ohshost1_fqdn  ohshost1_hostname    ALIASES_OF_WEBHOST1
ohshost2_compute_instance_IP  ohshost2_fqdn  ohshost2_hostname    ALIASES_OF_WEBHOST2
# The aliases for SOA are added too
virtual_IP_for_admin          virtualIP_fqdn  virtualIP_hostname    ALIASES_OF_ADMINVHN
soahost1_compute_instance_IP  soahost1_fqdn   soahost1_hostname     ALIASES_OF_SOAHOST1
soahost2_compute_instance_IP  soahost2_fqdn   soahost2_hostname     ALIASES_OF_SOAHOST2

    ノート:

    Oracle HTTP Serverホストの仮想名を別名として追加する以外に、Oracle WebLogic Serverホストの仮想名が、セカンダリWebLogicサーバー・ホストのIPを指し示して追加されます。Oracle HTTP Serverは、仮想ホスト名を使用してWebLogic Serverホストと通信するためです。
    次に、セカンダリOracle HTTP Serverコンピュート・インスタンスの/etc/hostsファイルの例を示します: 
    #################################
# ALIASES for SOA DR - SECONDARY
#################################
# The aliases of the Oracle HTTP Server hosts
100.60.10.11 hydrohs1.webTiersubnet.hydrvcn.oraclevcn.com    hydrohs1    WEBHOST1.example.com WEBHOST1
100.60.10.12 hydrohs2.webTiersubnet.hydrvcn.oraclevcn.com    hydrohs2    WEBHOST2.example.com WEBHOST2
# The aliases of the SOA hosts
100.70.10.20 hydrsoa-vip.midTiersubnet.hydrvcn.oraclevcn.com hydrsoa-vip ADMINVHN.example.com ADMINVHN
100.70.10.13 hydrsoa1.midTiersubnet.hydrvcn.oraclevcn.com    hydrsoa1    SOAHOST1.example.com SOAHOST1
100.70.10.14 hydrsoa2.midTiersubnet.hydrvcn.oraclevcn.com    hydrsoa2    SOAHOST2.example.com SOAHOST2
    次に、プライマリOracle HTTP Serverホストの既存の/etc/hostsファイルの例を示します: 
    #################################
# ALIASES for SOA DR - PRIMARY
#################################
# The aliases of the Oracle HTTP Server hosts
100.10.10.11 host1.myopnetwork.com    host1    WEBHOST1.example.com WEBHOST1
100.10.10.12 host2.myopnetwork.com    host2    WEBHOST2.example.com WEBHOST2
# The aliases of the SOA hosts
10.10.10.20    host-vip1.myopnetwork.com         host-vip1       ADMINVHN.example.com   ADMINVHN
10.10.10.13    host3.myopnetwork.com             host3           SOAHOST1.example.com   SOAHOST1
10.10.10.14    host4.myopnetwork.com             host4           SOAHOST2.example.com   SOAHOST2
ドメイン名システム(DNS)の使用
プライマリOracle HTTP Serverホストで使用される仮想ホスト名は、セカンダリOracle HTTP ServerホストのVCNによって使用されるDNSリゾルバに追加され、セカンダリOracle HTTP ServerホストのIPアドレスを指します。 このモードは、個別のDNSサーバーがプライマリ・オンプレミスで使用され、セカンダリがOracle Cloud Infrastructure (OCI)で使用されている場合に有効です。そうしないと、ネーミング解決で競合が発生する可能性があります。各サイトのサーバーは、これらの名前を独自のIPで解決する必要があります。
この方法の利点は、すべてのホストの/etc/hostsファイルにすべてのエントリを追加するのではなく、プライベートDNSビューにすべてのエントリを追加できることです。

「OCIでの中間層の準備」のステップで、OCIで作成したプライベート・ビューにOracle HTTP Server仮想ホスト名のエントリを追加します:

  1. OCIコンソールで、セカンダリ・リージョンに移動し、プライベート・ビューを見つけます:
    1. 「ネットワーキング」、「DNS管理」、「プライベート・ビュー」をクリックします。
      例: HYBRID_DR_VIRTUAL_HOSTNAMES
    2. プライベート・ビューで、仮想ホストを追加するために作成したゾーン名をクリックします。
      例: example.com。
    3. Oracle HTTP Server仮想ホスト名をこのゾーンに追加します。ただし、セカンダリOracle HTTP ServerホストのIPで解決されます。

      レコードを追加するには、OCIコンソール・メニューでfqdn以外の名前を指定するだけです。ゾーンのDNSドメインがレコードに自動的に追加されます。

    4. 「変更の公開」をクリックします。
  2. 追加された仮想ホスト名のpingおよびnslookupを実行して、解決のSECONDARYホストを検証します。
    これらは、同等のSECONDARY IPで解決する必要があります。

OCIホストのファイアウォールで必要なポートを開く

各コンピュート・インスタンスには、ローカル・ファイアウォール・サービスがあります。セキュリティ上の理由から、デフォルトの構成では、最低限必要なポート(ssh、dhcp)を除くすべてのポートの接続を拒否します。Oracle HTTP Serverで使用されるポートを開く必要があります。
  1. ファイアウォール・サービスのステータスおよびルールを確認します。
    bash-4.2# firewall-cmd --state
running
bash-4.2# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens3
  sources:
  services: dhcpv6-client ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
    この出力は、22以外のポートが開いていないことを意味します。
  2. rootユーザーとして、firewall-cmdコマンドを使用して、各Oracle HTTP Serverコンピュート・インスタンスでOracle HTTP Serverによってリスニング・ポートとして使用されるポートを開きます。
    例: 
    firewall-cmd --permanent --add-port=7001/tcp 
firewall-cmd --permanent --add-port=8890/tcp 
service firewalld reload
  3. ファイアウォール・サービスのステータスおよびルールを確認します。
    bash-4.2# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens3
  sources:
  services: dhcpv6-client ssh
  ports: 7001/tcp 8890/tcp 8888/tcp
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

Oracle HTTP Serverのoracleユーザー環境変数の作成

Oracle HTTP Server関連の環境変数は、Oracle HTTP Serverホストのoracleユーザーのプロファイルに共通です。たとえば、ORACLE_HOME、JDK_HOME、PATH、WEB_DOMAIN_HOMEなどです。
  1. プライマリOracle HTTP Serverホストで、oracleユーザーのプロファイル・ファイルを確認します。
  2. セカンダリで、同じOracle HTTP Server関連の環境変数をoracleユーザーのプロファイル・ファイル(.bashrcまたは.bash_profile)に追加します。

    Oracle HTTP Serverホスト内のoracleユーザーの.bashrcファイルには、定義済の変数(MIDDLEWARE_HOME、WLS_HOMEなど)がすでに含まれている場合がありますが、これらはおそらく環境のフォルダ用であり、ユーザーには有効ではありません。必ず環境フォルダに従って削除または変更してください。

プライマリからのOracle HTTP Server製品および構成のレプリケート

セカンダリOracle HTTP Server OCIコンピュート・インスタンスはプライマリOracle HTTP Serverホスト(同じOS、ユーザーID、ホスト名別名など)として作成されるため、rsyncを使用して、プライマリOracle HTTP ServerノードからバイナリおよびOracle HTTP Server構成をコピーできます。

または、Oracle HTTP Serverソフトウェアをダウンロードし、OCI Oracle HTTP Serverコンピュート・インスタンスでゼロからインストールして構成することもできます。このアプローチは、このドキュメントの範囲外です。ただし、Oracle HTTP Server OCIコンピュート・インスタンスのオペレーティング・システムがプライマリOracle HTTP Serverホストと異なる場合は、このアプローチを使用する必要があります。

Oracle HTTP Serverのバイナリおよび構成ファイルは、通常、プライベート・ストレージに存在します。OCIでは、コンピュート・インスタンスがデフォルトで持っているブロック・ボリュームを使用できます。または、Oracle HTTP Serverコンピュートごとに新しいブロック・ボリュームを作成し(OCIブロック・ボリュームの準備を参照)、それぞれをOracle HTTP Serverコンピュート・インスタンスにマウントできます(OCIブロック・ボリュームのマウントを参照)。

この例では、追加のブロック・ボリュームを作成せずに、Oracle HTTP Serverコンピュート・インスタンスのデフォルトのブロック・ボリュームを使用します。

  1. プライマリOracle HTTP Serverノード内のOracle HTTP Serverバイナリおよび構成のフォルダを識別します。
    例:
  2. OCI Oracle HTTP Serverコンピュート・インスタンスに同じフォルダを作成します。プライマリで使用されているのと同じパスを使用する必要があります。
    1. OSコンピュート・インスタンスにSSH接続し、sudoをrootユーザーに送信します。
    2. フォルダを作成し、oracleを所有者にします。
      例: 
      bash-4.2# mkdir -p /u02/oracle/products/ohs_12214
bash-4.2# mkdir -p /u02/oracle/config/ohsdomain_12214
bash-4.2# chown -R oracle:oinstall /u02
    3. Oracle HTTP Server OCIコンピュート・インスタンスごとに繰り返します。
  3. rsyncを使用して、オンプレミス・プライマリWEBHOST1からリモートWEBHOST1にproductsフォルダをコピーします。このステップを繰り返して、WEBHOST2からリモートWEBHOST2にproductsフォルダをコピーします。また、他のOracle HTTP Serverコンピュート・インスタンスに対してこのステップを繰り返します。

    ノート:

    Oracle HTTP Server製品フォルダをオンプレミス・プライマリWEBHOST1からリモートWEBHOST1にコピーするために使用できるサンプル・スクリプトがあります。

    「Download Code」に移動して、スクリプトをダウンロードします。

  4. rsyncを使用して、オンプレミスのプライマリWEBHOST1からリモートWEBHOST1にOracle HTTP Server構成フォルダをコピーします。ステップを繰り返して、構成フォルダをWEBHOST2からリモートWEBHOST2にコピーします。また、他のOracle HTTP Serverコンピュート・インスタンスに対してこのステップを繰り返します。

    ノート:

    オンプレミス・プライマリWEBHOST1からリモートWEBHOST1にOracle HTTP Server構成フォルダをコピーするために使用できるサンプル・スクリプトがあります。

    「Download Code」に移動して、スクリプトをダウンロードします。

  5. プライマリOracle HTTP Serverホストから/etc/oraInst.locファイルをコピーし、セカンダリ・ホストに保存します。
    このファイルにはoraInventoryの場所のみが含まれ、時間の経過とともに変化しないため、このコピーは1回かぎりのアクションです。
  6. oraInventoryフォルダがproductsフォルダの下にある場合は、Oracle HTTP Server Oracleホームとともにコピーされます。oraInventoryフォルダが別の場所にある場合は、必ずセカンダリ・ホストにコピーしてください。

Oracle HTTP Serverの構成およびバイナリは、頻繁な超過時間は変更されません。この最初のレプリケーションの後、ライフサイクル中に同じレプリケーションを繰り返すことができます。または、両方のサイトでOracle HTTP Server構成の変更を実装することで、Oracle HTTP Serverの構成をプライマリおよびセカンダリで手動で維持できます。

OCI Load Balancerの準備

クラウドでOracle Cloud Infrastructure Load Balancerを作成および構成します。

ノート:

この項で説明するリソース(OCI Load Balancer、SSL証明書、バックエンド・セットとバックエンド、ルーティング・ポリシー、リスナーおよびルール・セット)を作成するTerraformコードは、「コードのダウンロード」にあります。

OCIロード・バランサのプロビジョニング

プライマリ・オンプレミス・サイトと一貫性を持たせるには、システムのエントリ・ポイントとして、Oracle Cloud Infrastructure (OCI)のセカンダリ・サイトにロード・バランサをプロビジョニングします。

  1. OCIコンソールにログインします。
  2. 適切なリージョンとコンパートメントを選択します。
  3. 「ネットワーキング」、「ロード・バランサ」の順に移動します。「ロード・バランサの作成」をクリックします。
  4. 「ロード・バランサ」タイプを選択します。
  5. ロード・バランサの名前を指定します。
    例: hyDRlbr。
  6. 表示タイプ(パブリックまたはプライベート)およびニーズに一致する帯域幅を選択します。
    • システムにインターネット経由で外部クライアントからアクセスする場合は、「パブリック」表示を選択します。OCIロード・バランサはパブリックIPを使用します。
    • システムが内部的にクライアントからのみアクセスされる場合、プライベート表示を選択して、プライベートIPのみでロード・バランサをプロビジョニングできます。
  7. 適切なVCNおよびサブネットを選択します。
    たとえば、hydrvcnおよびwebTierSubnetです。
  8. この時点でバックエンドを追加しないでください。
  9. デフォルトのリスナーはデフォルト値のままにしておきます。
  10. 「発行」をクリックします。
OCI Load BalancerのIPを保存します(たとえば、100.100.100.10)。

証明書のアップロード

プライマリ・ロード・バランサで使用される証明書をアップロードします。

  1. コンソールで、「ロード・バランサ」、「証明書」、「証明書の追加」の順にクリックします。
  2. プライマリ・ロード・バランサが使用する証明書のパブリックSSL証明書と秘密キーをアップロードします。使用する場合は、CA (認証局)証明書をアップロードします。
  3. 証明書の名前を入力し、「証明書の追加」をクリックします。
    新しい証明書がロード・バランサの証明書リストに表示されます。
  4. 複数の証明書を使用してプライマリシステムにアクセスする場合は、これらの手順を繰り返してすべての証明書をアップロードします。

バックエンド・セットの作成

バックエンド・セットは、同じアプリケーションを実行するバックエンド・サーバーのリストを含む論理エンティティです。バックエンド・セットを定義する場合、ロード・バランシング・ポリシーとヘルス・チェック・テストを指定する必要があります。その後、バックエンド・サーバーのリストを追加できます。

バックエンド・セットの構成は、WebLogicサーバー・ホストの前でOracle HTTP Serverを使用しているかどうかによって異なります。

Oracle HTTP Serverを使用している場合、Oracle Cloud Infrastructure (OCI) Load BalancerはHTTPSサーバーにリクエストを送信します。HTTPSサーバーによって公開されているポートごとにバックエンド・セットを作成します。たとえば、アプリケーションへのアクセスを提供するOracle HTTP Serverリスナー用に1つのバックエンド・セットを作成し、各Oracle WebLogic Server管理コンソールへのアクセスを提供するOracle HTTP Serverリスナー用に別のバックエンド・セットを作成します。

Oracle HTTP Serverを使用していない場合、OCI Load BalancerはWebLogicサーバーにリクエストを直接送信します。Oracle WebLogic Serverクラスタごとにバックエンド・セットを作成し、管理サーバー用に別のバックエンド・セットを作成します。

  1. OCIコンソールにログインします。
  2. 適切なリージョンおよびコンパートメントを選択します。
  3. ナビゲーション・メニューで、「ネットワーキング」をクリックし、「ロード・バランサ」をクリックします。
  4. バックエンドを追加するロード・バランサをクリックします。
  5. 「リソース」メニューで「バックエンド・セット」をクリックし、「バックエンド・セットの作成」をクリックします。
  6. 「バックエンド・セットの作成」ダイアログ・ボックスに次を入力します:
    1. 名前: バックエンド・セットの名前を指定します。
      有効なバックエンド・セット名には、英数字、ダッシュおよびアンダースコアのみが含まれます。
    2. トラフィック分散ポリシー: 「重み付けラウンド・ロビン」を選択します。
    3. セッション永続性: 「ロード・バランサCookieの永続性を有効化」を選択します。
    4. Cookie名: セッション永続性を有効にするために使用するCookieの名前を入力します。
    5. 属性: 「セキュア」を選択します。
    6. ヘルス・チェック: ポートをチェックする場合は「TCP」を選択し、URLパス(URI)および予期される回答コードをチェックする場合は「HTTP」を選択します。
      次に、ヘルス・チェックのHTTPの例を示します。
      • OHS_Admin_backendset: URLパス/console、ステータス・コード302
      • OHS_HTTP_backendset:
        • URLパス/、ステータス・コード200 (またはOracle HTTP Server構成に応じて404)
        • URLパス/app1、ステータス・コード200
  7. 「Create」をクリックします。

Oracle HTTP Serverが他のサービスの追加ポートでリスニングしている場合は、同様の方法で各サービスのバックエンド・セットを作成します。

次に、Oracle HTTP Serverを使用する場合のバックエンド・セットの例を示します。

コンポーネント バックエンド・セット名 トラフィック分散ポリシー セッション永続性 Cookie名(例) 属性:セキュア ヘルス・チェック
管理サーバー OHS_Admin_backendset 重み付けラウンド・ロビン ロード・バランサCookieのCookieの永続性を有効化 X-Oracle-LBR-ADMIN-Backendset 選択解除 TCPまたはHTTP
すべてのSOAコンポーネント
  • Oracle SOA Suite
  • Oracle Service Bus
  • Oracle B2B
  • ビジネス・プロセス管理
  • Oracle Enterprise Scheduler (ESS)
  • Business Activity Monitoring(BAM)
 OHS_HTTP_backendset 重み付けラウンド・ロビン ロード・バランサCookieのCookieの永続性を有効化 X-Oracle-LBR-OHS-HTTP-Backendset チェック済 TCPまたはHTTP
Oracle Web Services Manager OHS_HTTP_internal_backendset 重み付けラウンド・ロビン ロード・バランサCookieのCookieの永続性を有効化 X-Oracle-LBR-OHS-Internal-HTTP-Backendset 選択解除 TCPまたはHTTP

Oracle HTTP Serverが他のサービスの追加ポートでリスニングしている場合は、同様の方法で各サービスのバックエンド・セットを作成します。

Oracle HTTP Serverを使用しない場合のバックエンド・セットの例を次に示します。

コンポーネント バックエンド・セット名 トラフィック分散ポリシー セッション永続性 Cookie名(例) 属性: secure ヘルス・チェック
すべての製品(admin) Admin_backendset 重み付けラウンド・ロビン ロード・バランサCookieのCookieの永続性を有効化 X-Oracle-LBR-ADMIN-Backendset チェックなし TCPまたはHTTP
Oracle Web Services Manager WSM_backendset 重み付けラウンド・ロビン ロード・バランサCookieのCookieの永続性を有効化 X-Oracle-LBR-WSM-Backendset チェックなし TCPまたはHTTP
Oracle SOA Suite、ビジネス・プロセス管理およびOracle B2B SOA_backendset 重み付けラウンド・ロビン ロード・バランサCookieのCookieの永続性を有効化 X-Oracle-LBR-SOA-Backendset チェック済 TCPまたはHTTP
Oracle Service Bus OSB_backendset 重み付けラウンド・ロビン ロード・バランサCookieの永続性を有効化 X-Oracle-LBR-OSB-Backendset チェック済 TCPまたはHTTP
Oracle Enterprise Scheduler (ESS) ESS_backendset 重み付けラウンド・ロビン ロード・バランサCookieの永続性を有効化 X-Oracle-LBR-ESS-Backendset チェック済 TCPまたはHTTP
Business Activity Monitoring(BAM) BAM_backendset 重み付けラウンド・ロビン ロード・バランサCookieの永続性を有効化 X-Oracle-LBR-BAM-Backendset チェック済 TCPまたはHTTP

追加のWebLogicクラスタがある場合、同様の方法で各クラスタのバックエンド・セットを作成します。

各バックエンド・セットのバックエンドの定義

Oracle Cloud Infrastructure (OCI) Load Balancerで、各バックエンド・セットのバックエンドを定義します。

Oracle HTTP Serverを使用している場合は、各バックエンド・セットのバックエンドとしてOracle HTTP Serverノードおよび適切なポートを追加します。

Oracle HTTP Serverを使用していない場合は、各バックエンド・セットのバックエンドとしてOracle WebLogic Serverノードおよび適切なポートを追加します。

  1. コンソールで、「バックエンド・セット」を選択します。「バックエンド」をクリックし、「バックエンドの追加」をクリックします。
  2. バックエンドであるサーバーのIPアドレスおよびポートを入力します。

この表は、Oracle HTTP Serverの使用時にこのドキュメントの例で作成されたバックエンド・セットを示しています:

バックエンド・セット名 バックエンド
OHS_Admin_backendset コンピュート・インスタンス:
  • hydrohs1、コンソール・リスナーのOracle HTTP Serverポート(7001など)
  • hydrohs2、コンソール・リスナーのOracle HTTP Serverポート(7001など)
OHS_HTTP_backendset コンピュート・インスタンス:
  • hydrohs1、HTTPリスナーのOracle HTTP Serverポート(8890など)
  • hydrohs2、HTTPリスナーのOracle HTTP Serverポート(8890など)
OHS_HTTP_internal_backendset コンピュート・インスタンス:
  • hydrohs1、HTTP内部リスナーのOracle HTTP Serverポート(8891など)
  • hydrohs2、HTTP内部リスナーのOracle HTTP Serverポート(8891など)

この表は、Oracle HTTP Serverを使用しない場合にこのドキュメントの例で作成されるバックエンド・セットを示しています:

バックエンド・セット名 バックエンド
Admin_backendset IPアドレス:
  • 以前に作成された管理サーバー仮想IP、管理サーバー・ポート(7001)
WSM_backendset コンピュート・インスタンス:
  • hydrsoa1、WSM server1ポート(7010)
  • hydrsoa2、WSM server2ポート(7010)
SOA_backendset コンピュート・インスタンス:
  • hydrsoa1、SOA server1ポート(8001)
  • hydrsoa2、SOA server2ポート(8001)
OSB_backendset コンピュート・インスタンス:
  • hydrsoa1、OSB server1ポート(8010)
  • hydrsoa2、OSB server2ポート(8010)
ESS_backendset コンピュート・インスタンス:
  • hydrsoa1、ESS server1ポート(8021)
  • hydrsoa2、ESS server2ポート(8021)
BAM_backendset コンピュート・インスタンス:
  • hydrsoa1、BAM server1ポート(9001)
  • hydrsoa2、BAM server2ポート(9001)

ルーティング・ポリシーの定義とルールの構成

ルーティング・ポリシーは、受信リクエストを正しいバックエンド・セットに送信するために使用されます。たとえば、/consoleへのリクエストは管理バックエンド・セットにディスパッチされ、/app1へのリクエストは、app1が実行されているクラスタのバックエンド・セットにディスパッチされます。

Oracle HTTP Serverを使用している場合は、通常、Oracle HTTP Server構成でルート(/app1、/app2、/consoleなど)を定義します。この場合、Oracle Cloud Infrastructure (OCI) Load Balancerでルーティング・ポリシーおよびルールを定義する必要はありません。

Oracle HTTP Serverを使用していない場合は、OCI Load Balancerでルーティング・ポリシーおよびルールを定義して、リクエストを適切なバックエンド・セットにディスパッチする必要があります。

  1. Oracle Cloud Infrastructureコンソールで、ロード・バランサをクリックします。
  2. 「ルーティング・ポリシー」をクリックし、「ルーティング・ポリシーの作成」をクリックしてポリシーを定義します。
    ルーティング・ポリシーは、後でLoad Balancerリスナーに追加されます。
  3. ルーティング・ポリシー(ルール・セット)の名前を入力します。
    たとえば、Admin_Rulesです。
  4. ルート・ポリシーにルールを作成するには、ルールの名前を入力します。
    たとえば、Admin_routeruleです。
  5. リクエストを異なるバックエンド・セットにルーティングするルール条件を定義します。「一致する場合」を選択し、「条件タイプ: パス」を選択し、「演算子: 次で始まる」を選択して、「URL文字列」を入力します。
    たとえば、いずれかの一致、パス、開始文字、/consoleなどです。
  6. メニューからバックエンド・セットを選択して、アクションを構成します。
    たとえば、OHS_Admin_backendsetです。
この表は、Oracle HTTP Serverが使用されていない場合にこのドキュメントの例に従って作成されたOracle Cloud Infrastructure Load Balancerのルーティング・ポリシーおよびルールを示しています。
コンポーネント ルーティング・ポリシー名 ルール 条件:任意の一致パスが次で始まる場合 処理:バックエンド・セットへのルート
すべての製品(admin) Admin_Rules Admin_routerule

/console

/em

 Admin_backendset
Oracle Service Bus (admin) Admin_Rules Admin_routerule

/sbconsole

/servicebus

 Admin_backendset
Oracle Web Services Manager Internal_Rules WSM_routerule

/wsm-pm

 WSM_backendset
Oracle Service Bus SOA_Rules OSB_routerule

/sbinspection.wsil

/sbresource

/osb

/alsb

OSB_backendset
Oracle SOA Suite SOA_Rules SOA_routerule

/soa-infra

/integration

/sdpmessaging

/userprefs-ui

/DefaultToDoTaskFlow

/workflow

/ADFAttachmentHelper

/soa/composer

(*)カスタム・タスクには、さらにカスタム・エイリアスが必要になる場合があります

 SOA_backendset
ビジネス・プロセス管理 SOA_Rules SOA_routerule

/bpm/composer

/bpm/workspace

/bpm/casemgmt

 SOA_backendset
Oracle Enterprise Scheduler (ESS) SOA_Rules ESS_routerule

/ess

/EssHealthCheck

/ess-async

/ess-wsjob

 ESS_backenset
Business Activity Monitoring(BAM) SOA_Rules BAM_routerule

/bam

/composer

/OracleBAMWS

/oracle/bam

 BAM_backendset
Oracle B2B SOA_Rules B2B_routerule

/b2bconsole

/b2b/services

/b2b/httpreceiver

 SOA_backendset

環境に必要な数のルーティング・ポリシー、ルールおよび条件を作成できます。

リスナーの作成

システムへのアクセスに使用されるフロントエンド名とポートの組合せごとにリスナーを作成します。プライマリ・ロード・バランサで使用されているものと同じホスト名(仮想フロントエンド名)およびポートを使用する必要があります。

  1. 仮想フロントエンド・ホスト名をホスト名としてOracle Cloud Infrastructure Load Balancerに追加します。
  2. リスナーを作成します。

次の表に、このドキュメントの例で作成されたリスナーと、それに関連付けられたプロトコル、ポート、バックエンド・セット、ルーティング・ポリシー、ホスト名およびSSL使用状況のサマリーを示します。これは参考例です。システムでプライマリOracle WebLogic Serverシステムで追加のフロントエンド・ホスト名、ポートまたはプロトコルを使用する場合は、ニーズに応じて対応するリスナーおよびホスト名を作成する必要があります。たとえば、代替フロントエンドを使用してOracle WebLogic ServerコンソールおよびOracle Enterprise Managerコンソールにアクセスする場合です。

リスナー プロトコル 港 バックエンド・セット ルーティング・ポリシー HostName SSLの使用
Admin_listener HTTP 7001

OHS_Admin_backendset (Oracle HTTP Serverが使用されている場合)

Admin_backendset (Oracle HTTP Serverが使用されていない場合)

Admin_Rules mysoa.example.com いいえ
HTTPS_listener HTTPS 443

OHS_HTTP_backendset (Oracle HTTP Serverが使用されている場合)

SOA_backendset (Oracle HTTP Serverが使用されていない場合)

SOA_Rules mysoa.example.com はい
HTTP_listener HTTP 80 該当なし* 該当なし mysoa.example.com いいえ
Internal_listener HTTP 8888

OHS_HTTP_internal_backendset (Oracle HTTP Serverが使用されている場合)

WSM_backendset (Oracle HTTP Serverが使用されていない場合)

Internal_Rules mysoa.example.com いいえ

*この例のHTTP_listenerは、リクエストをHTTPS_listener (HTTPS)にリダイレクトするためにのみ使用されます。割り当てられたバックエンドは使用されません。ただし、指定は必須であるため、SSLが選択されていないものを指定する必要があります(デフォルトの空のバックエンド・セットを使用します)。

SSLヘッダーのルール・セットの作成

Oracle Cloud Infrastructure (OCI)ロード・バランサにSSLヘッダーのルール・セットを作成し、それをHTTPSリスナーに関連付けます。

プライマリ・サイトと同様に、OCIロード・バランサはSSLを終了し、ロード・バランサとバックエンド・サーバー間の通信はHTTPプロトコルを介して実行されます。これが正常に機能するには、OCIロード・バランサにリクエスト・ヘッダーを追加する必要があります。これらのヘッダーは、WebLogicバック・エンドにディスパッチされる前に、HTTPSリスナーに着信するクライアント・リクエストに追加されます。ヘッダーは、エンド・クライアントからロード・バランサへの通信でHTTPSが使用されたことをWebLogicに通知します。このように、WebLogicが動的に構成するすべてのURLは、HTTPSを使用して正しく生成されます。
  1. コンソールでLoad Balancerを選択します。「ルール・セット」、「ルール・セットの作成」の順にクリックします。
  2. ルール名を入力します。
    たとえば、SSLHeadersです。
  3. 「リクエスト・ヘッダー・ルールの指定」を選択し、次のアクションを追加します:
    アクション ヘッダー Value
    リクエスト・ヘッダーの追加 is_ssl SSL
    リクエスト・ヘッダーの追加 WL-Proxy-SSL TRUE
  4. 「Create」をクリックします。
  5. 「ロード・バランサ」をクリックし、「リスナー」をクリックします。HTTPSを使用してルールをHTTPSリスナーに関連付けるリスナーを編集します。
  6. +Additionalルール・セットをクリックし、ルール・セットSSLHeadersを選択します。

HTTPプロトコルをHTTPSにリダイレクトするためのルール・セットの作成

リダイレクト・ルールを作成し、それをHTTP_listenerに関連付けて、ポート80をポート443にリダイレクトします。EDGトポロジの場合、ロード・バランサのポート80 (HTTP)に到達するすべてのリクエストは、ポート443 (HTTPS)にリダイレクトされる必要があります。

  1. コンソールで、ロード・バランサを選択します。
  2. 「ルール・セット」、「ルール・セットの作成」の順にクリックします。
  3. ルールの名前を入力します。
    たとえば、HTTP_to_HTTPS_redirectです。
  4. 「URLリダイレクト・ルールの指定」を選択し、次のアクションを追加します
    • ソース・パス: /
    • 照合タイプ:最長接頭辞の強制一致
    • 次にリダイレクト:
    • プロトコル: HTTPS
    • ホスト: {host} (デフォルト値のまま)
    • ポート: 443
    • パス: /{path} (デフォルト値のまま)
    • 問合せ: ?{query} (デフォルト値のまま)
    • レスポンス・コード: 301 -永続的に移動されました
  5. 「ロード・バランサ」、「リスナー」の順にクリックします。HTTPポート80を使用してHTTPリスナーに関連付けるリスナーを編集します。
  6. +Additionalルール・セットをクリックし、ルールHTTP_to_HTTPS_redirectを選択します。

SOAコンピュート・インスタンスへの仮想フロントエンド名およびIPの追加

ディザスタ・リカバリ・トポロジでは、クライアントは、データ・センターに非依存のフロントエンドFQDN (通常は仮想フロントエンド名またはバニティURLと呼ばれます)を使用してシステムにアクセスする必要があります。この仮想フロントエンド名は、現在アクティブな(プライマリ)サイトのロード・バランサIPアドレスに解決される必要があります。

プライマリ・システムは、プライマリLoad BalancerのIPを使用してDNSによって解決されるフロントエンド仮想名をすでに使用している必要があります。ただし、各サイトのOracle SOA Suiteホストでは、DNSでのクライアント対応の解決に関係なく、常にローカル・ロード・バランサでフロントエンド名を解決する必要があります。この場合、仮想フロントエンド名は各サイトで適切なIPアドレスを使用して/etc/hostsファイルに追加されます。これは、各サイトで異なるDNSサーバーを使用して実現することもできます。その場合、ローカルDNSサーバーは、各サイトで適切なロード・バランサIPを使用してフロントエンド名を解決します。

/etc/hostsファイルの使用
スイッチオーバーまたはフェイルオーバーがある場合は、プライマリおよびセカンダリOracle WebLogic Serverホストの/etc/hostsファイルを変更しないでください。Oracle WebLogic Serverホストは、常に仮想フロントエンド名をフロントエンドIPで解決します。スイッチオーバーおよびフェイルオーバーの手順で必要なDNS更新は、Oracle WebLogic Serverクライアントで使用されるDNSまたはホスト・ファイルで実行されます。
  1. rootユーザーとして、セカンダリOracle WebLogic Server for Oracle Cloud Infrastructureコンピュート・インスタンスの/etc/oci-hostname.confファイルを編集し、フロントエンド名をOracle Cloud Infrastructure (OCI) Load Balancer IPにマップします。

    次に、フロントエンド名のエントリを含む、セカンダリOracle WebLogic Server for OCIコンピュート・インスタンスの/etc/hostsファイルの例を示します。 

    #################################
# ALIASES in OCI 
#################################
100.70.10.20   hydrsoa-vip.midTiersubnet.hydrvcn.oraclevcn.com      hydrsoa-vip       ADMINVHN.example.com    ADMINVHN    
100.70.10.13   hydrsoa1.midTiersubnet.hydrvcn.oraclevcn.com         hydrsoa1          SOAHOST1.example.com    SOAHOST1
100.70.10.14   hydrsoa2.midTiersubnet.hydrvcn.oraclevcn.com         hydrsoa2          SOAHOST2.example.com    SOAHOST2

# Front-end name (resolved to secondary OCI LBR IP)
100.100.100.10    mysoa.example.com
  2. まだ実行されていない場合は、プライマリOracle WebLogic Serverホストの同じステップに従います。フロントエンド名は、プライマリ・ロード・バランサIPを指す必要があります。
    次に、フロントエンド名のエントリを含む、プライマリ・オンプレミスOracle WebLogic Serverホストの/etc/hostsファイルの例を示します。 
    #################################
# ALIASES in on-prem 
#################################
10.10.10.20   host-vip1.myopnetwork.com    host-vip1         ADMINVHN.example.com   ADMINVHN    
10.10.10.13   host3.myopnnetwork.com       host3             SOAHOST1.example.com   SOAHOST1
10.10.10.14   host4.myopnnetwork.com       host4             SOAHOST2.example.com   SOAHOST2

# Front-end name (resolved to primary Load Balancer IP)
10.10.10.100    mysoa.example.com
  3. Oracle WebLogic Serverシステムでより多くの仮想フロントエンド名を使用する場合は、同じルールに従ってファイルに追加します。
ドメイン名システム(DNS)の使用
このモードは、分離されたDNSサーバーがプライマリ・オンプレミスで使用され、セカンダリがOracle Cloud Infrastructure (OCI)で使用されている場合に有効です。そうしないと、ネーミング解決で競合が発生する可能性があります。

このアプローチに従っている場合は、セカンダリ・ミッドティアで使用されるDNSサービスにフロントエンド名(セカンダリ・ロード・バランサIPを指す)を追加できます。プライマリでは、フロントエンド名がプライマリ・ロード・バランサIPを指してすでに解決されていることが予想されます。

プライマリでは、フロントエンド名がプライマリ・ロード・バランサIPを指してすでに解決されていることが予想されます。