OCIでのWeb層の準備

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

ノート:

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

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

Oracle Cloud InfrastructureOracle 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. 「Create」をクリックします。
  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ユーザーでセカンダリ・ホストにログインし、sudooracleユーザーにログインし、コマンドidを実行します。
    [opc@hydrwls1 ~]$ sudo su - oracle
    [oracle@hydrwls1 ~]$ 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@hydrwls1 ~]$ sudo -s  
      [root@hydrwls1 ~]$ more /etc/group | grep 1005
      IDが使用されていないことを確認したら、グループのIDを新しいIDに変更します。
      [opc@hydrwls1 ~]$ sudo -s 
      [root@hydrwls1 ~]$ groupmod -g 1005 docker
      [root@hydrwls1 ~]$ find / -group 1002 -exec chgrp -h docker {} \;
    2. セカンダリ内のグループoracleはID 1001を使用しますが、これはプライマリ・グループdbaのIDと競合します。
      競合を解決するには、セカンダリ・ホスト内のグループoracleのIDを、競合しない別のIDに変更します。たとえば、新しいIDとして1006を選択し、/etc/groupファイルに表示されないことを確認して使用されていないことを確認します。
      [opc@hydrwls1 ~]$ sudo -s 
      [root@hydrwls1 ~]$ more /etc/group | grep 1006
      IDが使用されていないことを確認したら、グループのIDを新しいIDに変更します。
      [opc@hydrwls1 ~]$ sudo -s 
      [root@hydrwls1 ~]$ groupmod -g 1006 oracle
      [root@hydrwls1 ~]$ find / -group 1001 -exec chgrp -h oracle {} \;
    3. プライマリIDと同じIDを持つセカンダリ・ホストにoracleユーザーのグループoinstallおよびdbaを作成します。
      [opc@hydrwls1 ~]$ sudo -s
      [root@hydrwls1 ~]$ groupadd oinstall -g 1002
      [root@hydrwls1 ~]$ groupadd dba -g 1001
    4. ユーザーoracleの名前とIDはプライマリとスタンバイの両方で同じであるため、変更は必要ありません。
      ただし、セカンダリ・ホストでユーザーのメイン・グループをoinstallに変更する必要があります。
      [root@hydrwls1 ~]$ usermod -g oinstall oracle
      次に、ユーザーをグループdbaに追加します。
      [root@hydrwls1 ~]$ 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@hydrwls1 ~]$ 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 WLS 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 WebLogic
                                    Server are added too
    virtual_IP_for_admin          virtualIP_fqdn  virtualIP_hostname    ALIASES_OF_ADMINVHN
    apphost1_compute_instance_IP  apphost1_fqdn   apphost1_hostname     ALIASES_OF_APPHOST1
    apphost2_compute_instance_IP  apphost2_fqdn   apphost2_hostname     ALIASES_OF_APPHOST2

    ノート:

    Oracle HTTP Serverホストの仮想名を別名として追加する以外に、Oracle WebLogic Serverホストの仮想名が、セカンダリWebLogicサーバー・ホストのIPを指し示して追加されます。Oracle HTTP Serverは、仮想ホスト名を使用してWebLogic Serverホストと通信するためです。
    次に、セカンダリOracle HTTP Serverコンピュート・インスタンスの/etc/hostsファイルの例を示します:
    #################################
    # ALIASES for WLS 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 WLS hosts
    100.70.10.20 hydrwls-vip.midTiersubnet.hydrvcn.oraclevcn.com hydrwls-vip ADMINVHN.example.com ADMINVHN
    100.70.10.13 hydrwls1.midTiersubnet.hydrvcn.oraclevcn.com    hydrwls1    APPHOST1.example.com APPHOST1
    100.70.10.14 hydrwls2.midTiersubnet.hydrvcn.oraclevcn.com    hydrwls2    APPHOST2.example.com APPHOST2
    次に、プライマリOracle HTTP Serverホストの既存の/etc/hostsファイルの例を示します:
    #################################
    # ALIASES for WLS 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 WebLogic
                                    Server hosts
    10.10.10.20    host-vip1.myopnetwork.com         host-vip1       ADMINVHN.example.com   ADMINVHN
    10.10.10.13    host3.myopnetwork.com             host3           APPHOST1.example.com   APPHOST1
    10.10.10.14    host4.myopnetwork.com             host4           APPHOST2.example.com   APPHOST2
ドメイン名システム(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ホストのファイアウォールで必要なポートを開く

各コンピュート・インスタンスには、ローカル・ファイアウォール・サービスがあります。セキュリティ上の理由から、デフォルトの構成では、最低限必要なポート(sshdhcp)を除くすべてのポートの接続を拒否します。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 Serveroracleユーザー環境変数の作成

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

    Oracle HTTP Serverホスト内のoracleユーザーの.bashrcファイルには、定義済の変数(MIDDLEWARE_HOMEWLS_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接続し、sudorootユーザーに送信します。
    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 Load Balancerのプロビジョニング

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

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

証明書のアップロード

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

  1. コンソールで、「Load Balancer」「証明書」「証明書の追加」の順にクリックします。
  2. プライマリLoad Balancerが使用する証明書の公開SSL証明書および秘密キーをアップロードします。使用する場合は、CA (認証局)証明書をアップロードします。
  3. 証明書の名前を入力し、「証明書の追加」をクリックします。
    Load Balancerの証明書の一覧に新しい証明書が表示されます。
  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」をクリックします。

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

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

コンポーネント バックエンド・セット名 トラフィック分散ポリシー セッション永続性 Cookie名(例) 属性: secure ヘルス・チェック
管理サーバー OHS_Admin_backendset 重み付けラウンド・ロビン ロード・バランサCookieの永続性を有効化 X-Oracle-LBR-ADMIN-Backendset チェックなし TCPまたはHTTP
WebLogicクラスタ OHS_HTTP_backendset 重み付けラウンド・ロビン ロード・バランサCookieの永続性を有効化 X-Oracle-LBR-OHS-HTTP-Backendset チェック済 TCPまたはHTTP

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

コンポーネント バックエンド・セット名 トラフィック分散ポリシー セッション永続性 Cookie名(例) 属性: secure ヘルス・チェック
管理サーバー Admin_backendset 重み付けラウンド・ロビン ロード・バランサCookieの永続性を有効化 X-Oracle-LBR-ADMIN-Backendset チェックなし TCPまたはHTTP
Weblogicクラスタ 1 WLS_Cluster1_backendset 重み付けラウンド・ロビン ロード・バランサCookieの永続性を有効化 X-Oracle-LBR-WLSCluster1-Backendset チェック済 TCPまたはHTTP
Weblogicクラスタ 2 WLS_Cluster2_backendset 重み付けラウンド・ロビン ロード・バランサCookieの永続性を有効化 X-Oracle-LBR-WLSCluster2-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など)

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

バックエンド・セット名 バックエンド
Admin_backendset IPアドレス:
  • 以前に作成された管理サーバー仮想IP、管理サーバー・ポート(7001)
WLSCluster1_backendset コンピュート・インスタンス:
  • hydrwls1、WLSクラスタ1サーバー1ポート(8001)
  • hydrwls2、WLSクラスタ1サーバー1ポート(8001)
WLSCluster2_backendset コンピュート・インスタンス:
  • hydrwls1、WLSクラスタ2サーバー1ポート(9001)
  • hydrwls2、WLSクラスタ2サーバー2ポート(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コンソールで、Load Balancerをクリックします。
  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_Rules Admin_routerule

/console

/em

Admin_backendset
アプリケーション1 Application_Rules WLSCluster1_routerule

/app1

WLSCluster1_backendset
アプリケーション2 Application_Rules WLSCluster2_routerule

/app1

WLSCluster2_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 wlsfrontend.example.com いいえ
HTTPS_listener HTTPS 443

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

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

App_Rules wlsfrontend.example.com はい
HTTP_listener HTTP 80 N/A* 該当なし wlsfrontend.example.com いいえ

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

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

Oracle Cloud Infrastructure (OCI) Load BalancerでSSLヘッダーのルール・セットを作成し、HTTPSリスナーに関連付けます。

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

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

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

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

WLSコンピュートインスタンスへの仮想フロントエンドの名前とIPの追加

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

プライマリ・システムは、プライマリLoad BalancerのIPを使用してDNSによって解決されるフロントエンド仮想名をすでに使用している必要があります。ただし、各サイトのOracle WebLogic Serverホストは、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   hydrwls-vip.midTiersubnet.hydrvcn.oraclevcn.com      hydrwls-vip       ADMINVHN.example.com    ADMINVHN    
    100.70.10.13   hydrwls1.midTiersubnet.hydrvcn.oraclevcn.com         hydrwls1          APPHOST1.example.com    APPHOST1
    100.70.10.14   hydrwls2.midTiersubnet.hydrvcn.oraclevcn.com         hydrwls2          APPHOST2.example.com    APPHOST2
    
    # Front-end name (resolved to secondary OCI LBR IP)
    100.100.100.10    wlsfrontend.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             APPHOST1.example.com   APPHOST1
    10.10.10.14   host4.myopnnetwork.com       host4             APPHOST2.example.com   APPHOST2
    
    # Front-end name (resolved to primary Load Balancer IP)
    10.10.10.100    wlsfrontend.example.com
  3. Oracle WebLogic Serverシステムでより多くの仮想フロントエンド名を使用する場合は、同じルールに従ってファイルに追加します。
ドメイン名システム(DNS)の使用
このモードは、分離されたDNSサーバーがプライマリ・オンプレミスで使用され、セカンダリがOracle Cloud Infrastructure (OCI)で使用されている場合に有効です。そうしないと、ネーミング解決で競合が発生する可能性があります。

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

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