2 ディザスタ・リカバリ・デプロイメントの設定
この章では、LinuxおよびUNIXオペレーティング・システムでOracle Fusion Middlewareディザスタ・リカバリ・トポロジを設定する手順について説明します。特定のケースのOracle Fusion Middlewareディザスタ・リカバリ・ソリューションを設定する方法の例では、Oracle SOA Suiteエンタープライズ・デプロイメント(図2-1を参照)を使用します。Oracle SOA Suiteエンタープライズ・トポロジのディザスタ・リカバリを設定する方法を理解したら、同じ情報を使用して他のエンタープライズ・デプロイメントのディザスタ・リカバリ・システムを設定します。
図2-1 Oracle Fusion Middlewareディザスタ・リカバリの本番サイトとセカンダリ・サイトで使用するデプロイメント
ディザスタ・リカバリ・デプロイメント・プロセスの概要
Oracle Fusion Middlewareの障害保護システムを設定するには、次の手順を実行します。
-
ホスト名の計画
様々なコンポーネントで使用されるリスニング・アドレスの構成と仮想化をどのように行えば、構成をプライマリから伝播するときにセカンダリでの変更が不要になるかを判断します。これらのアドレスの解決方法を決定することで、システムの管理性や障害保護ソリューションのRTOに影響が及ぶ可能性があります。
-
ファイル・システム・レプリケーション戦略の計画
プライマリからセカンダリにコピーする必要がある様々なアーティファクトのRTO要件とRPO要件を満たすために、どのレプリケーション・テクノロジおよび方法を使用するかを決定します。
-
障害保護のためのプライマリ・システムの準備
構成を最適化するために、障害保護構成の準備の一環としてプライマリでいくつかの変更を適用する必要がある場合があります。これらの変更は、主にストレージ構成とデータベースのアドレス構成に影響します。
-
障害保護のためのセカンダリ・システムの準備
エンタープライズ・デプロイメント・ガイドに記載されている情報に基づいて、セカンダリ・システムも設定できます。Fusion Middlewareシステムで使用されるインフラストラクチャには、障害保護ソリューションの動作を最適化する特定の構成が必要です。
-
セカンダリ・システムの設定
セカンダリ・システムを設定するには、次の3つのタスクを実行する必要があります。
-
Fusion Middlewareで使用されるデータベースに対してData Guardを設定し、データベースをレプリケートする。
-
プライマリFusion Middlewareファイル・システムをセカンダリ・ストレージにレプリケートする。
-
セカンダリのデータベース・アドレスのTNS別名を更新する。
-
以降の項では、前述の手順について詳しく説明します。
ホスト名の計画
ディザスタ・リカバリ・トポロジでは、Fusion Middlewareコンポーネントで使用されるホスト名アドレスが、各サイトの有効なIPアドレスに解決可能である必要があります。
このドキュメントで使用されているホスト名には、様々なタイプがあります。
-
物理ホスト名
これらは、ネットワーク内のノードを一意に識別するために使用されるホスト名です。これは、そのノードへのSSH接続の確立に使用されるアドレスです。物理ホスト名は、ノードが使用するメイン・ネットワーク・インタフェース・コントローラ(NIC)にアタッチされている固定IPにマップされます。物理ホスト名は特定のホストにアタッチされており、別のホストに移動することはできません。物理ホスト名が属するマシンへのメイン・アクセス・ポイントを提供するためです。
-
ホスト名別名または仮想ホスト名
これらは、ノード間で浮動可能なホスト名です。あるノードに割り当てた後、そのノードで無効にして、別のノードに割り当てることができます。仮想ホスト名は、異なるノード間を移動できるプロセスやコンポーネントのリスニング・アドレスとして使用されます。これらを使用することで、アクセッサは、プロセスやコンポーネントがある正確な時点に実行される物理ホスト名から自身を抽象化できます。
エンタープライズ・デプロイメント・ガイドに記載されているように、既存の物理ホスト名の他にホスト名別名を作成して、それらの物理ホスト名(サイトごとに異なり、特定のノードにアタッチされている)からシステムの構成を切り離すことをお薦めします。通常、物理ホスト名はプライマリとセカンダリで異なりますが、Fusion Middleware構成では両方の場所で有効な仮想ホスト名が使用されます。
この項では、本番サイトとセカンダリ・サイトでOracle Fusion Middlewareインスタンスを使用する中間層ホストについて、ホスト名別名を計画する方法を説明します。ホスト名の例として、図2-1に示されているOracle SOA Suiteエンタープライズ・デプロイメントを使用します。本番サイトの各ホストにセカンダリ・サイトのピア・ホストがあります。セカンダリ・サイトにあるピア・ホストのFusion Middlewareコンポーネントは、プライマリの対応するコンポーネントと同じリスニング・アドレスおよびポートで構成されます。
各コンポーネントを構成する際には、IPベースの構成ではなく、ホスト名ベースの構成を使用します。たとえば、Oracle WebLogic管理対象サーバーで特定のIPアドレス(172.11.2.113など)をリスニングする場合は、ホスト名SOAHOST1.EXAMPLE.COMを構成で使用し、OSを使用してこのホスト名をIP 172.11.2.113に解決します。構成、WebLogicドメインおよびアプリケーション、またはOracle HTTP ServerなどのFusion Middlewareシステム・コンポーネントの構成に直接IPを含めることはできません。
次の項では、ディザスタ・リカバリの本番サイトとスタンバイ・サイトでホスト名を設定する方法を説明します。
ノート:
示されている例では、最初の本番サイトのホストのIPアドレスは172.11.x.xという形式で、最初のスタンバイ・サイトのホストのIPアドレスは172.22.x.xという形式です。
Oracle SOA Suiteの本番サイト・ホストおよびスタンバイ・サイト・ホストのホスト名の例
図2-2に、プライマリ・サイトでOracle SOA Suiteエンタープライズ・デプロイメントを使用するOracle Fusion Middlewareディザスタ・リカバリ・トポロジを示します。
図2-2 Oracle Fusion Middlewareディザスタ・リカバリの本番サイトとセカンダリ・サイトで使用するデプロイメント
表2-1に、『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』(EDG)のデプロイメントのプライマリ・サイト・ホストに使用するIPアドレス、物理ホスト名および別名を示します。本番サイトにおけるOracle SOA Suite EDGデプロイメントの構成については、図2-2を参照してください。
表2-1 SOA Suiteの本番サイト・ホストのIPアドレスと物理ホスト名
| IPアドレス | 物理ホスト名 | ホスト名別名 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ノート:
このドキュメントでは、実際のホスト名別名の抽象プレースホルダとして、WEBHOST1、WEBHOST2、SOAHOST1、SOAHOST2およびADMINVHNを使用します。たとえば、ご使用のシステムではSOAHOST1の値がsoahost1.example.comになることがあります。
図2-3に、スタンバイ・サイトでOracle SOA Suite EDGデプロイメントに使用する物理ホスト名を示します。
図2-3 Oracle SOA Suiteデプロイメントのスタンバイ・サイトで使用する物理ホスト名
表2-2に、『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』(EDG)のデプロイメントのスタンバイ・サイト・ホストに使用するIPアドレス、物理ホスト名および別名を示します。
表2-2 SOA Suiteのスタンバイ・サイト・ホストのIPアドレスおよび物理ホスト名
| IPアドレス | 物理ホスト名 | ホスト名別名 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ノート:
個別のDNSサーバーを使用してホスト名を解決する場合、本番サイトのホストとスタンバイ・サイトのホストに同じ物理ホスト名を使用できるので、ホスト名別名をスタンバイ・サイトのホストで定義する必要はありません。個別のDNSサーバーを使用してホスト名を解決する方法の詳細は、「個別のDNSサーバーを使用したホスト名の解決」を参照してください。
仮想IPに関する考慮事項
仮想ホスト名を使用して障害保護の構成を容易にする以外に、ローカル障害のコンテキストでは、一部のOracle WebLogic Serverで、様々なノードで有効にできるIPにマップされたリスニング・アドレスとして浮動ホスト名を使用できます。これらは浮動IPと呼ばれ、あるノードのネットワーク・インタフェースまたは仮想ネットワーク・インタフェースで無効にして、別のノードで有効にすることで、同じリージョン内の様々なノード間で移動できます。これにより、リスニング・アドレスを再構成せずに、WebLogic Serverおよびシステム・コンポーネントをフェイルオーバーできます。ただし、Oracle WebLogic管理サーバーの場合は、リスニング・アドレスの再構成が必要になります。Oracle WebLogicクラスタでは、VIPおよびサーバーをWebLogicインフラストラクチャによってノード間で移動することもできます。このメカニズムは、WebLogic Server移行と呼ばれます。
ノート:
WebLogic管理サーバーはクラスタ化できないため、サーバー移行は使用できません。
Oracle Fusion Middleware 14cでは、ほとんどのアプリケーションがOracle WebLogic自動サービス移行(ASM)をサポートしており、WebLogic内で実行されているサービス(JMS、JTA)のみが、実行中の他のWebLogic Serverに移行されます。これにより、サーバー全体が再起動されるかわりに、ごくわずかのWebLogicサブシステムがフェイルオーバーされるため、リカバリ時間が短縮されます。その結果、ドメイン内の管理対象サーバー用に仮想IPを予約する必要はなくなりました(サーバー移行には必要です)。ASMをサポートしていない製品またはアプリケーションでは、実行されているWebLogic Serverのサーバー移行を構成するためにVIPが必要になる場合があります。ASMがサポートされているかどうかを判断するには、特定のFusion Middlewareコンポーネントのドキュメントを参照してください。前述のとおり、管理サーバーには仮想ホスト名とそのマッピングVIPが必要です(エンタープライズ・デプロイメント・ガイドでの推奨事項)。WebLogic管理サーバーはクラスタ化できないため、ホストが失われた場合に他のノードにフェイルオーバーできるモバイル・ホスト名が必要になります。
管理サーバーの浮動IPアドレスは、本番サイトとスタンバイ・サイトで同じ仮想ホスト名を使用して指定してください。
表2-3 浮動IPアドレス
| 仮想IPアドレス | 仮想名 | ホスト名別名 |
|---|---|---|
|
|
(本番サイト) |
|
|
|
(スタンバイ・サイト) |
|
ホスト名の解決
ホスト名の解決とは、システム内のノード、サービスまたはエンドポイントへのアクセスに必要とされる適切なIPアドレスにホスト名をマップすることです。ホスト名の解決は、すべての障害保護システムにおいて重要な側面です。アドレスを仮想化して、プライマリ・サイトの構成を操作せずにセカンダリ・サイトで使用することが可能になるためです。プライマリ・システムに独自のホスト名解決メカニズムが存在する場合があります(エンタープライズ・デプロイメント・ガイドには、この分野の特定の方法は規定されていません)。ただし、ノードの数、仮想ホスト名の数、およびFusion Middlewareトポロジで使用されるコンポーネントによっては、システムでの必要性に基づいた別のホスト名解決メカニズムが必要になります。
障害保護システムでは、Fusion Middlewareの構成でホスト名別名または仮想ホスト名が使用されるため、セカンダリ・サイトで有効なIPに仮想ホスト名を再マッピングするだけで、別のサイトで変更を加えることなく構成を再利用できます。ホスト名の解決により、このホスト名からIPへの動的マッピングが可能になります。ホスト名の解決は、次のいずれかの手順を使用して構成できます。
-
ローカルでのホスト名の解決
ローカルでのホスト名の解決では、各ホストの
/etc/hostsファイルで指定したホスト名とIPアドレスのマッピングが使用されます。/etc/hostsファイルを使用してローカルでのホスト名のファイル解決を実装する方法の詳細は、「ローカルでのホスト名の解決」を参照してください。 -
DNSを使用したホスト名の解決
DNSサーバーは、IPネットワークでDNSによる名前解決を提供する専用サーバーまたはサービスです。グローバルDNSサービス(プライマリとセカンダリに共通)を使用することも、各場所で個別のDNSサービスを使用することもできます。
DNSサーバーによるホスト名の解決の実装に使用される2通りの方法の詳細は、「個別のDNSサーバーを使用したホスト名の解決」および「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。
Oracle Fusion Middlewareディザスタ・リカバリ・トポロジのデプロイメントを計画する際には、トポロジで使用するホスト名の解決方法を決定する必要があります。ほとんどのサイト管理者は、ホスト名を管理する際にこれらの解決方法を優先順位に従って組み合せて使用しています。各サイトのOracle Fusion Middlewareホストと共有ストレージ・システムは、相互に通信できる必要があります。
ホスト名解決の優先順位
特定のホストで使用するホスト名の解決方法を決定するには、ホストの/etc/nsswitch.confファイルでhostsパラメータの値を検索します。
ホストでローカルにホスト名を解決する場合は、例2-1に示されているように、filesエントリをhostsパラメータの最初のエントリにします。filesがhostsパラメータの最初のエントリである場合、ホストの/etc/hostsファイル内のエントリがホスト名の解決に最初に使用されます。
ホストでDNSを使用してホスト名を解決する場合は、例2-2に示されているように、dnsエントリをhostsパラメータの最初のエントリにします。dnsがhostsパラメータの最初のエントリである場合、DNSサーバーのエントリがホスト名の解決に最初に使用されます。
わかりやすくすると同時に整合性を保つために、サイト(本番サイトまたはスタンバイ・サイト)内のすべてのホストで同じホスト名解決方法(ローカルでのホスト名の解決か、個別のDNSサーバーまたはグローバルDNSサーバーを使用したホスト名の解決)を使用することをお薦めします。
以降の項に記載されている推奨事項は全般的なもので、企業が使用しているホスト名解決の標準に合せて調整できます。
例2-1 ローカルでのホスト名解決を使用する場合の指定
hosts: files dns nis
例2-2 DNSによるホスト名解決を使用する場合の指定
hosts: dns files nis
ローカルでのホスト名の解決
ローカルでのホスト名の解決では、ホストの/etc/hostsファイルで定義したIPマッピングに対応するホスト名が使用されます。
ディザスタ・リカバリ・トポロジのホスト名をこの方法で解決する場合、次の手順を使用します。
例2-3 本番サイト・ホストの/etc/hostsファイル・エントリの追加
127.0.0.1 localhost.localdomain localhost 172.11.2.134 prsoa-vip.example.com prsoa-vip ADMINVHN.EXAMPLE.COM ADMINVHN 172.11.2.111 prweb1.example.com prweb1 WEBHOST1.EXAMPLE.COM WEBHOST1 172.11.2.112 prweb2.example.com prweb2 WEBHOST2.EXAMPLE.COM WEBHOST2 172.11.2.113 prsoa1.example.com prsoa1 SOAHOST1.EXAMPLE.COM SOAHOST1 172.11.2.114 prsoa2.example.com prsoa2 SOAHOST2.EXAMPLE.COM SOAHOST2
例2-4 スタンバイ・サイト・ホストの/etc/hostsファイル・エントリの追加
127.0.0.1 localhost.localdomain localhost 172.22.2.134 stbysoa-vip.example.com stbysoa-vip ADMINVHN.EXAMPLE.COM ADMINVHN 172.22.2.111 stbyweb1.example.com stbyweb1 WEBHOST1.EXAMPLE.COM WEBHOST1 172.22.2.112 stbyweb2.example.com stbyweb2 WEBHOST2.EXAMPLE.COM WEBHOST2 172.22.2.113 stbysoa1.example.com stbysoa1 SOAHOST1.EXAMPLE.COM SOAHOST1 172.22.2.114 stbysoa2.example.com stbysoa2 SOAHOST2.EXAMPLE.COM SOAHOST2
ノート:
本番サイトとスタンバイ・サイトのサブネットは異なります。個別のDNSサーバーを使用したホスト名の解決
個別のDNSサーバーを使用して、ディザスタ・リカバリ・トポロジのホスト名(プライマリでのホスト名とセカンダリ・サイトでの別のホスト名)を解決することもできます。
個別のDNSサーバーを使用してディザスタ・リカバリ・トポロジのホスト名を解決する場合、次の手順を使用します。
例2-5 個別のDNSサーバー構成における本番サイト・ホストのDNSエントリ
PRSOA-VIP.EXAMPLE.COM IN A 172.11.2.134 PRWEB1.EXAMPLE.COM IN A 172.11.2.111 PRWEB2.EXAMPLE.COM IN A 172.11.2.112 PRSOA1.EXAMPLE.COM IN A 172.11.2.113 PRSOA2.EXAMPLE.COM IN A 172.11.2.114 ADMINVHN.EXAMPLE.COM IN A 172.11.2.134 WEBHOST1.EXAMPLE.COM IN A 172.11.2.111 WEBHOST2.EXAMPLE.COM IN A 172.11.2.112 SOAHOST1.EXAMPLE.COM IN A 172.11.2.113 SOAHOST2.EXAMPLE.COM IN A 172.11.2.114
例2-6 個別のDNSサーバー構成におけるスタンバイ・サイト・ホストのDNSエントリ
STBYSOA-VIP.EXAMPLE.COM IN A 172.22.2.134 STBYWEB1.EXAMPLE.COM IN A 172.22.2.111 STBYWEB2.EXAMPLE.COM IN A 172.22.2.112 STBYSOA1.EXAMPLE.COM IN A 172.22.2.113 STBYSOA2.EXAMPLE.COM IN A 172.22.2.114 ADMINVHN.EXAMPLE.COM IN A 172.22.2.134 WEBHOST1.EXAMPLE.COM IN A 172.22.2.111 WEBHOST2.EXAMPLE.COM IN A 172.22.2.112 SOAHOST1.EXAMPLE.COM IN A 172.22.2.113 SOAHOST2.EXAMPLE.COM IN A 172.22.2.114
ノート:
個別のDNSサーバーを使用してホスト名を解決する場合、本番サイトのホストとスタンバイ・サイトのホストに同じホスト名を使用できます。ホスト名別名を定義する必要はありません。グローバルDNSサーバーを使用したホスト名の解決
前述の2つのオプションに代わる方法として、グローバルDNSサーバーを使用してディザスタ・リカバリ・トポロジのホスト名を解決できます。
「グローバルDNSサーバー」という用語は、本番サイトとスタンバイ・サイト両方に対して1つのDNSサーバーを使用するディザスタ・リカバリ・トポロジを表します。
グローバルDNSサーバーを使用してディザスタ・リカバリ・トポロジのホスト名を解決する場合、次の手順を使用します。
例2-7 通常の運用中にグローバルDNSサーバー構成を使用する場合の本番サイト・ホストおよびスタンバイ・サイト・ホストのDNSエントリ(ワークロードが元のプライマリによって維持されている場合)
PRSOA-VIP.EXAMPLE.COM IN A 172.11.2.134 PRWEB1.EXAMPLE.COM IN A 172.11.2.111 PRWEB2.EXAMPLE.COM IN A 172.11.2.112 PRSOA1.EXAMPLE.COM IN A 172.11.2.113 PRSOA2.EXAMPLE.COM IN A 172.11.2.114 STBYSOA-VIP.EXAMPLE.COM IN A 172.22.2.134 STBYWEB1.EXAMPLE.COM IN A 172.22.2.111 STBYWEB2.EXAMPLE.COM IN A 172.22.2.112 STBYSOA1.EXAMPLE.COM IN A 172.22.2.113 STBYSOA2.EXAMPLE.COM IN A 172.22.2.114 ADMINVHN.EXAMPLE.COM IN A 172.11.2.134 WEBHOST1.EXAMPLE.COM IN A 172.11.2.111 WEBHOST2.EXAMPLE.COM IN A 172.11.2.112 SOAHOST1.EXAMPLE.COM IN A 172.11.2.113 SOAHOST2.EXAMPLE.COM IN A 172.11.2.114
例2-8 スタンバイ・サイトへのスイッチオーバー後にグローバルDNSサーバー構成を使用する場合の本番サイト・ホストおよびスタンバイ・サイト・ホストのDNSエントリ
PRSOA-VIP.EXAMPLE.COM IN A 172.11.2.134 PRWEB1.EXAMPLE.COM IN A 172.11.2.111 PRWEB2.EXAMPLE.COM IN A 172.11.2.112 PRSOA1.EXAMPLE.COM IN A 172.11.2.113 PRSOA2.EXAMPLE.COM IN A 172.11.2.114 STBYSOA-VIP.EXAMPLE.COM IN A 172.22.2.134 STBYWEB1.EXAMPLE.COM IN A 172.22.2.111 STBYWEB2.EXAMPLE.COM IN A 172.22.2.112 STBYSOA1.EXAMPLE.COM IN A 172.22.2.113 STBYSOA2.EXAMPLE.COM IN A 172.22.2.114 ADMINVHN.EXAMPLE.COM IN A 172.22.2.134 WEBHOST1.EXAMPLE.COM IN A 172.22.2.111 WEBHOST2.EXAMPLE.COM IN A 172.22.2.112 SOAHOST1.EXAMPLE.COM IN A 172.22.2.113 SOAHOST2.EXAMPLE.COM IN A 172.22.2.114
例2-9 グローバルDNSサーバー構成を使用する場合の本番サイトの/etc/hostsファイル・エントリ
127.0.0.1 localhost.localdomain localhost 172.11.2.134 prsoa-vip.example.com prsoa-vip ADMINVHN.EXAMPLE.COM ADMINVHN 172.11.2.111 prweb1.example.com prweb1 WEBHOST1.EXAMPLE.COM WEBHOST1 172.11.2.112 prweb2.example.com prweb2 WEBHOST2.EXAMPLE.COM WEBHOST2 172.11.2.113 prsoa1.example.com prsoa1 SOAHOST1.EXAMPLE.COM SOAHOST1 172.11.2.114 prsoa2.example.com prsoa2 SOAHOST2.EXAMPLE.COM SOAHOST2
例2-10 グローバルDNSサーバー構成を使用する場合のスタンバイ・サイトの/etc/hostsファイル・エントリ
127.0.0.1 localhost.localdomain localhost 172.22.2.134 stbysoa-vip.example.com stbysoa-vip ADMINVHN.EXAMPLE.COM ADMINVHN 172.22.2.111 stbyweb1.example.com stbyweb1 WEBHOST1.EXAMPLE.COM WEBHOST1 172.22.2.112 stbyweb2.example.com stbyweb2 WEBHOST2.EXAMPLE.COM WEBHOST2 172.22.2.113 stbysoa1.example.com stbysoa1 SOAHOST1.EXAMPLE.COM SOAHOST1 172.22.2.114 stbysoa2.example.com stbysoa2 SOAHOST2.EXAMPLE.COM SOAHOST2
外部T3/T3sクライアントの考慮事項
トポロジ内のWebLogic Serverに直接アクセスするシステムは、それらのWebLogic Serverで使用されるリスニング・アドレスを認識している必要があります。サーバーでリスニング・アドレスとして使用されるホスト名別名が正しく解決されるように、適切なホスト名解決をそれらのクライアントに提供する必要があります。このことは、Oracle JDeveloperや他の開発ツールおよびスクリプトからデプロイメントを実行する場合にも当てはまります。Oracle JDeveloperをホストするクライアントは、EDGで提供されているサンプル・アドレスを使用して、SOAHOSTx別名とADMINVHN別名(様々なWebLogic Serverと管理サーバーに対応)を適切なIPアドレスにマップし、管理操作とRMI操作を成功させる必要があります。外部クライアントがどの程度制御可能か、システムにアクセスしている外部クライアントがいくつあるかによっては、別のホスト名解決方法の方がRTOの最適化と管理の簡素化に適している場合もあります。
ノート:
この項は、T3/T3sサーバーと同じWebLogicドメインに存在するT3/T3sクライアントには適用されません。同じドメイン内のクラスタに接続する場合、内部クライアントは、cluster:t3://cluster_nameなどのT3/T3sクラスタ構文を使用できます。このクラスタ構文を使用できるのは、クラスタが同じドメイン内に存在する場合のみです。
WebLogicでは、Remote Method Invocation (RMI)にT3/T3sプロトコルが使用されます。これは、JMS、EJB、JTA、JNDI、JMX、WLSTなど、複数のWebLogicサービスで使用されます。T3/T3sサーバーと同じドメインで実行されない外部T3/T3sクライアントは、様々な方法でWebLogicクラスタに接続できます。詳細は、WebLogic RMIでのT3プロトコルの使用方法に関する項を参照してください。
t3://host1.example.com:9073,host2.example.com:9073外部T3/T3sクライアントは、TCPロード・バランサ(LBR)からもT3/T3sサービスにアクセスできます。このシナリオでは、クライアントはロード・バランサ・サービスおよびポートへのURLポイントを提供します。リクエストは、WebLogic ServerのT3/T3sポートにロード・バランシングされます。JNDIコンテキストを取得するために初めて接続する場合、外部クライアントはロード・バランサを介してWebLogic Serverに接続し、T3クライアント・スタブをダウンロードします。これらのスタブには、今後のリクエストに使用する接続情報が含まれています。
一般的に、WebLogic T3/T3sはTCP/IPベースであるため、JMSやEJBなど、サービスが同種である場合には、TCPロード・バランシングがサポートされます。たとえば、JMSフロントエンドは、リモートJMSクライアントが任意のクラスタ・メンバーに接続できるWebLogicクラスタに構成できます。これに対して、JTAサブシステムは、複数のWebLogicドメインにまたがるトランザクションで、TCPロード・バランシングを安全に使用することができません。JTAトランザクション・コーディネータは、トランザクションのコミット時またはロールバック時に、トランザクションのサブ・コーディネータとして機能するサーバー・インスタンスへのRMI直接接続を確立する必要があります。このため、ロード・バランサは通常、JNDI初期コンテキストの取得にのみ使用されます。WebLogic Serverのロード・バランシング・システムは、その後のT3/T3sリクエストを制御しますが、これは、この初期コンテキストの入手時に取得したスタブに示されているWebLogic管理対象サーバーのアドレスおよびポート(デフォルトまたはカスタム・チャネル)に接続します。
この項では、T3/T3sクライアントを管理する方法と、それが障害保護構成に及ぼす影響について説明します。また、JTAを使用しない場合に、すべてのT3/T3s通信(初期リクエストと後続のリクエストの両方)に対してロード・バランサを使用する方法についても説明します。
ノート:
外部クライアントは、HTTP経由のT3トンネリングを使用してT3サービスにアクセスできます。この方法では、RMIセッションごとにHTTPセッションが作成され、標準のHTTPプロトコルを使用してクライアントとサーバーの間でセッションIDが転送されます。このため、多少のオーバーヘッドが発生するので、あまり使用されません。
T3/T3sサービスにアクセスするための様々な方法
ディザスタ・リカバリのシナリオには、外部T3/T3sクライアントのホスト名解決の構成に影響する特殊な側面があります。このトピックでは、外部クライアントからT3/T3sサービスにアクセスする際に利用できるいくつかの方法と、ディザスタ・リカバリのシナリオでそれらを管理する方法を説明します。それぞれの方法について構成例を示し、クライアントとスイッチオーバーを管理する際のメリットとデメリットを説明します。
ノート:
これらの方法は、Fusion Middlewareを対象としたMAAガイドラインに準拠するディザスタ・リカバリのシナリオに適用されます。この場合、セカンダリ・ドメインの構成はプライマリ・システムのレプリカになります。デフォルト・チャネルを使用した直接T3/T3s
この方法では、外部T3/T3sクライアントは、WebLogic管理対象サーバーのデフォルト・チャネルに直接接続します。これらのデフォルト・チャネルは、各WebLogic管理対象サーバーの一般的な構成に指定されたリスニング・アドレスおよびリスニング・ポートをリスニングします。
図2-4 デフォルト・チャネルを使用した直接T3/T3s
構成
-
T3クライアントのプロバイダURLは、WebLogic Serverのデフォルトのリスニング・アドレスとポートのリストを使用します。
例: 次のディザスタ・リカバリの例では、WebLogic Serverのリスナー・アドレスはプライマリ・ホスト名です:
t3://soahost1.example.com:8001,soahost2.example.com:8001T3sプロトコルを使用する場合に備えて、ポートはサーバーの
SSLリスニング・ポートに設定する必要があります。例:t3s://soahost1.example.com:8002,soahost2.example.com:8002 -
外部クライアントは、これらのホスト名をプライマリ・ホストのIPで解決する必要があります。これらのIPには、クライアントからアクセスできる必要があります。各サーバーにNAT IPアドレスがある場合は、ネットワーク・アドレス変換(NAT)を使用できます。その場合、クライアントは、各サーバーの名前をそのサーバーの適切なNAT IPで解決します。
例: 外部クライアント側でのネーミング解決
これは、ローカルの
/etc/hostsまたは正式なDNSサーバー解決でも行うことができます。172.11.2.113 soahost1.example.com 172.11.2.114 soahost2.example.com
スイッチオーバー動作
スイッチオーバーのシナリオでは、クライアントのプロバイダURLを更新する必要はありません。クライアントのDNS (またはクライアントの/etc/hosts)にあるエントリを更新する必要があります。スイッチオーバー後、サーバーへの接続に使用される名前は、セカンダリ・サーバーのIPで解決する必要があります。
172.22.2.113 soahost1.example.com
172.22.2.114 soahost2.example.comメリット
-
サーバー側でもフロントエンド層でも追加の構成は必要ありません。必要なのは、クライアントへの特定のポートを開くことだけです。
デメリット
- スイッチオーバーが発生したら、ホスト・リゾルバ(DNSまたはクライアントの
/etc/hosts)を更新して、外部クライアントが管理対象サーバーへの接続に使用するすべてのホスト名の解決を変更する必要があります。クライアントのキャッシュへの影響の詳細は、「T3/T3sクライアントのDNSキャッシュについて」を参照してください。 - クライアントは、WebLogicの
リスニング・アドレスに設定されているホスト名を解決し、アクセスできる必要があります。デフォルト・チャネルではWebLogic Serverのデフォルトのリスニング・アドレスが使用されるため、代替名は使用できません。 - WebLogicのデフォルト・チャネルは、T3(s)リクエストだけでなく、HTTP(s)リクエストもリスニングします。この設定を無効にすることはできません。クライアントのデフォルトのポートを開くと、サーバーにHTTP(s)で直接アクセスすることもできるようになるため、セキュリティの問題が発生する可能性があります。
- WebLogicクラスタでスケール・アウトまたはスケール・インする必要がある場合は、クライアントのプロバイダURLを変更する必要があります。T3/T3s呼出しの最初の接続で使用されるのは、クライアントのプロバイダURLのリストのみです。リカバリされたスタブにすべてのメンバーがリストされるため、リストを更新しなくても、その後のリクエストはクラスタの任意のサーバーに接続することが可能です。最初の接続でのクライアントのプロバイダURLを、フェイルオーバー目的のサーバーの実際のリストと一致させることをお薦めします。
カスタム・チャネルを使用した直接T3/T3s
この方法では、外部T3/T3sクライアントは、クラスタのWebLogic Serverに定義されているカスタム・チャネルに直接接続します。カスタム・チャネルでは、リスニング・アドレス、外部リスニング・アドレス、外部ポートの値をカスタマイズできます。これらの値は、WebLogic Serverのデフォルトのリスニング値と違っていてもかまいません。
図2-5 カスタム・チャネルを使用した直接T3/T3s
最初のコンテキストの取得時にT3/T3s外部クライアントがサーバーに接続すると、その後のT3コールは、カスタム・チャネルに外部リスニング・アドレスおよび外部ポートとして構成されたいずれかのリスニング・アドレスとポートに直接接続します。これらのリクエストは、WebLogicに定義された接続ファクトリに指定され、クライアントで使用されているメカニズムに従ってロード・バランシングされます。
この方法は、デフォルト・チャネルを使用した直接T3/T3sと似ていますが、WebLogicカスタム・チャネルを使用すると、T3/T3sコールで使用するアドレスとポートをカスタマイズできる点が異なります。
構成
-
各WebLogicサーバーには適切なカスタム・チャネルが構成されており、これらのカスタム・チャネルでは、そのサーバー・ノードを指す一意の
外部リスニング・アドレスが使用されます。表2-4および表2-5に、サーバー1とサーバー2のカスタム・チャネルの例を示します。表2-4 サーバー1のカスタム・チャネル
名前 プロトコル 有効 リスニング・アドレス リスニング・ポート パブリック・アドレス パブリック・ポート t3_external_channelt3 はい soahost1.example.com8111 soahost1-t3ext.example.com8111 表2-5 サーバー2のカスタム・チャネル
名前 プロトコル 有効 リスニング・アドレス リスニング・ポート パブリック・アドレス パブリック・ポート t3_external_channelt3 はい soahost2.example.com8111 soahost2-t3ext.example.com8111 -
外部T3クライアントのプロバイダURLには、カスタム・チャネルの外部アドレスおよびポートのリストが含まれます。
例:
t3://soahost1-t3ext.example.com:8111,soahost2-t3ext.example.com:8111T3sプロトコルを使用している場合は、T3sプロトコルを使用してカスタム・チャネルを作成する必要があります。その後、クライアントはT3sプロトコルと適切なポートを使用して接続します。
例:
t3s://soahost1-t3ext.example.com:8112,soahost2-t3ext.example.com:8112T3sチャネルでは、
外部リスニング・アドレスとして使用される名前の特定のSSL証明書を追加できます。 -
外部T3/T3sクライアントは、カスタム・チャネルの外部ホスト名をプライマリ・ホストのIPで解決する必要があります。これらのホスト名には、クライアントからアクセスできる必要があります。各サーバーにNATアドレスがある場合は、NATを使用できます。その場合、クライアントは、各サーバーの名前をそのサーバーの適切なNAT IPで解決します。
例: 外部クライアント側でのネーミング解決
172.11.2.113 soahost1-t3ext.example.com 172.11.2.114 soahost2-t3ext.example.comこの方法では、外部クライアントからのすべてのリクエストが
soahost1-t3ext.example.comおよびsoahost2-t3ext.example.comに接続され、最初のコンテキストの取得とその後のコールの両方に使用されます。これらのリクエストは、WebLogic Serverのロード・バランシング・メカニズムで制御できます。
スイッチオーバー
スイッチオーバーのシナリオでは、クライアントのプロバイダURLを更新する必要はありません。DNSまたはクライアントの/etc/hostsにあるエントリを更新する必要があります。スイッチオーバー後、サーバーへの接続に使用される名前は、セカンダリ・サーバーのIPで解決する必要があります。
172.22.2.113 soahost1-t3ext.example.com
172.22.2.114 soahost2-t3ext.example.comメリット
-
この方法では、サーバーのデフォルトのリスニング・アドレスとは異なる特定のホスト名を外部T3/T3s通信に使用できます。これは、セキュリティ上の理由で、デフォルト・サーバーの
リスニング・アドレスを外部クライアントに公開しない場合に便利です。 -
この方法は、NAT IPを使用していて、内部でも外部でも、IPが異なるサーバーのデフォルトのリスニング・アドレスを解決しない場合に便利です。
-
この方法は、組織の目的にのみ、外部T3/T3sアクセスに異なる名前を使用する場合に便利です。この方法では、様々なインタフェースまたはネットワーク・ルートで、プロトコルを分離することも可能です。
-
カスタム・チャネルのプロトコルは、T3/T3sのみに制限できます。カスタム・チャネルでは、HTTPプロトコルを無効にすることが可能です。
デメリット
- スイッチオーバーが発生したら、管理対象サーバーへの接続に使用されるすべてのホスト名について、外部クライアント側でDNSまたはクライアントの
/etc/hostsを更新する必要があります。クライアントのキャッシュへの影響の詳細は、「T3/T3sクライアントのDNSキャッシュについて」を参照してください。 - T3sを使用している場合は、クライアントでSSLホスト名の検証エラーが発生しないよう、カスタム・チャネルの外部名の特定のSSL証明書を作成して構成する必要があります。
- WebLogicクラスタでスケール・アウトまたはスケール・インする必要がある場合は、クライアントのプロバイダURLを変更する必要があります。最初の接続で使用されるのは、クライアントのプロバイダURLのリストのみです。リカバリされたスタブにすべてのメンバーがリストされるため、リストを更新しなくても、その後のリクエストはクラスタの任意のサーバーに接続することが可能です。最初の接続でのクライアントのプロバイダURLを、フェイルオーバー目的のサーバーの実際のリストと一致させることを常にお薦めします。
最初の参照でのロード・バランサの使用
このシナリオでは、クライアントのプロバイダURLは、ロード・バランサのアドレスを指しています。
デフォルト・チャネルを使用した直接T3/T3s、およびカスタム・チャネルを使用した直接T3/T3sの方法では、最初にコンテキストを参照する際に、ロード・バランサを使用することもできます。
ただし、その後のT3/T3sコールは、WebLogic Serverに直接接続します。これらの呼出しにデフォルト・チャネルを使用する場合、リクエストはデフォルト・チャネルのリスニング・アドレスおよびポートに接続します。同様に、カスタム・チャネルを使用する場合、後続のリクエストは、カスタム・チャネルに定義されている外部リスニング・アドレスおよびポートに接続します。
図2-6 最初の参照でのロード・バランサの使用
構成
-
WebLogic ServerのT3/T3sポート(デフォルト・チャネル、または使用している場合はカスタム・チャネル)にリクエストをロード・バランシングするために、ロード・バランサ内にTCPサービスが必要です。
-
外部T3/T3sクライアントのプロバイダは、ロード・バランサのフロントエンド名とポートを接続先として使用します。
例:
t3://t3lbr.example.com:8111 -
「デフォルト・チャネルを使用した直接T3/T3s」および「カスタム・チャネルを使用した直接T3/T3s」のシナリオの説明に従って、デフォルト・チャネルまたはカスタム・チャネルを使用できます。外部T3/T3sクライアントは、カスタム・チャネルの外部ホスト名(またはデフォルト・チャネルを使用している場合は、デフォルト・サーバーのリスナー・ホスト名)をプライマリ・ホストのIPで解決する必要があります。クライアントがそれらにアクセスできる必要があります。各サーバーにNATアドレスがある場合は、NATを使用できます。その場合、クライアントは、各サーバーの名前をそのサーバーの適切なNAT IPで解決します。
例: 外部クライアント側でのネーミング解決111.111.111.111 t3lbr.example.com 172.11.2.113 soahost1-t3ext.example.com 172.11.2.114 soahost2-t3ext.example.com
スイッチオーバー
スイッチオーバーのシナリオでは、クライアントのプロバイダURLを更新する必要はありません。DNSまたはクライアントで使用される/etc/hostsにあるエントリを更新して、セカンダリ・サイトのIPで解決されるようにする必要があります。ロード・バランサへの接続に使用される名前は、セカンダリ・ロード・バランサのIPで解決し、その後のリクエストで使用されるサーバー名は、セカンダリ・サーバーのIPを指している必要があります。
222.222.222.222 t3lbr.example.com
172.22.2.113 soahost1-t3ext.example.com
172.22.2.113 soahost2-t3ext.example.comメリット
WebLogicクラスタのWebLogic Serverノードを追加または削除した場合に、クライアントのプロバイダURLを変更する必要がありません。
デメリット
-
ロード・バランサを前面に使用しているにもかかわらず、クライアントはサーバーに直接アクセスする必要があります。
-
スイッチオーバーが発生したら、外部クライアント側でサーバーのアドレスのDNS (または
/etc/hosts)を更新する必要があります。クライアントのキャッシュへの影響の詳細は、「T3/T3sクライアントのDNSキャッシュについて」を参照してください。 -
T3sの場合、この方法はさらに複雑になります。クライアントは、フロントエンドのLBR経由と、セキュアなプロトコルを使用して直接の両方でサーバーに接続します。この場合、クライアント側のホスト名検証をスキップするか、フロント・アドレスとバック・アドレス(ワイルドカードやSAN証明書など)に有効なSSL証明書を使用する必要があります。
すべてのトラフィックでのロード・バランサの使用
この方法では、最初にコンテキストを参照するときとその後の接続でロード・バランサが使用されます。外部T3/T3sクライアントは、サーバーに直接接続しません。
すべてのタイプのT3/T3s通信のロード・バランシングにLBRを使用することはお薦めしません。推奨されるのは、最初にコンテキストを参照するときのみです。詳細は、ロード・バランサとのWebLogic RMIの統合に関する項を参照してください。ただし、T3/T3s通信フロー全体でロード・バランサを使用できるT3/T3sのユース・ケースがあります。WebLogic T3/T3sはTCP/IPベースのプロトコルであるため、JMSやEJBなど、サービスが同種である場合には、TCPロード・バランシングがサポートされます。たとえば、WebLogicクラスタ内にLBRが前面にあるJMSサブシステムを構成すれば、そのシステムでは、リモートJMSクライアントが任意のクラスタ・メンバーに接続することができます。
ただし、この方法はJTA接続を使用する外部クライアントでは機能しません。JTAサブシステムは、複数のWebLogicドメインにまたがるトランザクションで、TCPロード・バランシングを安全に使用することができません。トランザクションがコミットまたはロールバックされると、JTAトランザクション・コーディネータは、トランザクションのサブ・コーディネータとして選択されたサーバー・インスタンスへのRMI直接接続を確立する必要があります。
この方法は、特定のサーバーのみに接続する際に、JMXやWLSTなど、特定のサーバーへの直接接続が必要な場合にも適していません。
図2-7 すべてのトラフィックでのロード・バランサの使用
構成
-
ロード・バランサには、カスタム・チャネルに定義されているWebLogic ServerのT3/T3sポートにリクエストをロード・バランシングするためのTCPサービスが必要です。
-
外部T3/T3sクライアントのプロバイダURLは、ロード・バランサのフロントエンド名とポートを接続先として使用します。
例:t3://t3lbr.example.com:8111 -
外部クライアントは、プライマリ・サイトのロード・バランサのIPを使用して、ロード・バランサ・アドレスを解決する必要があります。
例:111.111.111.111 t3lbr.example.com -
WebLogic Serverには、カスタム・チャネルが必要です。ロード・バランサのアドレスとポートを使用して、これらのカスタム・チャネルの外部リスニング・アドレスとポートを構成します。表2-6および表2-7に、サーバー1とサーバー2のカスタム・チャネルの例を示します。
表2-6 サーバー1のカスタム・チャネル
名前 プロトコル 有効 リスニング・アドレス リスニング・ポート パブリック・アドレス パブリック・ポート t3_external_channelt3 はい soahost1.example.com8111 t3lbr.example.com8111 表2-7 サーバー2のカスタム・チャネル
名前 プロトコル 有効 リスニング・アドレス リスニング・ポート パブリック・アドレス パブリック・ポート t3_external_channelt3 はい soahost2.example.com8111 t3lbr.example.com8111
スイッチオーバー
スイッチオーバーのシナリオでは、クライアントのプロバイダURLを更新する必要はありません。クライアントのDNS (または/etc/hosts)にあるエントリを更新する必要があります。スイッチオーバー後、サーバーへの接続に使用される名前は、セカンダリLBRサービスのIPで解決されます。
222.222.222.222 t3lbr.example.comメリット
-
すべての通信がロード・バランサを経由します。クライアントは、ロード・バランサのサービスを認識してアクセスするだけでかまいません。
-
WebLogicクラスタのWebLogic Serverノードを追加または削除する必要がある場合に、クライアントのプロバイダURLを変更する必要はありません
-
スイッチオーバーの場合に実行する必要があるのは、DNS (または
/etc/hosts)にあるロード・バランサのフロントエンド名の更新のみです。ノート:
更新されるDNS名が1つのみであっても、クライアントのDNSキャッシュをリフレッシュする必要があります。詳細は、「T3/T3sクライアントのDNSキャッシュについて」を参照してください。 -
T3sの場合、ロード・バランサ・サービスのフロントエンド名に関連付けられているすべてのカスタム・チャネルで、同じSSL証明書を使用できます。
デメリット
-
この方法が、すべてのT3/T3sのユース・ケースに適しているわけではありません。また、JTAを使用するシナリオでは使用できません。JTAは、トランザクションのサブ・コーディネータとして機能するサーバー・インスタンスに明示的に接続する必要があるためです。
T3/T3sクライアントのDNSキャッシュについて
上で説明したT3/T3sサービスへのすべてのアクセス方法では、ほとんどの場合、ディザスタ・リカバリのスイッチオーバー・シナリオでDNSの更新が必要になります。したがって、DNSサーバーとクライアントの特定のキャッシュにおけるDNSキャッシュのTTL (存続時間)制限を設定する必要があります。
DNSサービスのTTL制限の設定で、新しい問合せをリクエストするまでに、DNSリゾルバで問合せをキャッシュする期間が決まります。DNSエントリのTTLの値は、スイッチオーバーの有効なRTOに影響することに注意してください。TTLの値が大きい場合(20分など)、DNSの変更がクライアントのキャッシュで有効になるまで時間がかかります。TTLの値を小さくすると、スイッチオーバーは短時間で行われますが、クライアントがDNSをチェックする頻度が高くなるため、オーバーヘッドの原因になる可能性があります。DNSを更新する前に、TTLを一時的に小さい値(1分など)に設定することをお薦めします。変更とスイッチオーバーの手順が完了したら、TTLを通常の値に設定しなおします。
DNSサーバーのTTLに加えて、networkaddress.cache.ttl Javaプロパティも、JavaクライアントのキャッシュTTLを制御します。このJavaプロパティは、名前サービスからの名前の検索に成功した場合のキャッシング・ポリシーを示します。正常な参照をキャッシュする秒数を示す値を整数で指定します。クライアントのJavaキャッシュがDNSエントリをキャッシュし続けないよう、networkaddress.cache.ttl Javaプロパティに必ず制限を設定してください。そうしないと、スイッチオーバーのたびにクライアントの再起動が必要になることがあります。
ファイル・システム・レプリケーション戦略の計画
障害保護システムを設計する際には、ファイル・システム・レプリケーション戦略を定義することが重要です。セカンダリ・システムを作成および管理するためにインストールと構成のステップを繰り返すことはお薦めしません。
まずプライマリ・システムで変更を適用してから(データ・ソースをデプロイするなど)、セカンダリ・システムでそのステップを繰り返すことは、信頼性の高い方法ではありません。デプロイメント・スクリプトと自動パイプラインを使用する場合でも、トランザクションの保証はほとんどありません。そのため、変更がプライマリ・システムでのみ適用され、セカンダリ・システムに正しく伝播されない可能性があります。一部の構成変更では、WebLogic Serverが実行されていることが必要になるため、処理が重複し、望ましくない動作につながる場合があります。さらに重要なのは、二重に変更を行う方法を取った場合、一般的に、障害保護ソリューションのRTOおよびRPOに影響を与える可能性のある不整合や管理のオーバーヘッドの余地が生じることです。
かわりに、様々なファイル・レプリケーション戦略を使用して、サイト間で構成変更をレプリケートできます。ファイル・システム・レプリケーションは、初期設定とシステムの継続的なライフサイクルで使用されます。コスト、管理のオーバーヘッド、RTOおよびRPOは、設定と継続的なライフサイクルにおいて様々な影響を及ぼすため、ケースごとに異なるレプリケーション方式を使用できます。また、Fusion Middlewareトポロジには様々なデータ・タイプが関係しており、ファイル・システムのサイズや、データが生成および変更される頻度によっては、RTOとRPOのニーズがデータ・タイプごとに異なることもあります。まず、障害保護トポロジに関係する様々なデータ・タイプを理解して、ニーズに適したレプリケーション戦略を決定する必要があります。
Fusion Middlewareファイル・システムのデータ層
Fusion Middlewareシステムに含まれるすべてのファイルを同じ時点にプライマリからセカンダリにレプリケートする必要があります。ただし、管理コストを簡素化し、障害保護システムの総所有コストを削減するために、ファイル・タイプごとに異なるレプリケーション頻度が必要になる場合があります。このことが重要になるのは、レプリケーションに使用するボリュームおよびファイル・システムを設計する際です。アーティファクトの中には静的なものもあれば、動的なものもあります。
OracleホームおよびOracleインベントリ
Oracleホームとは、すべてのOracleソフトウェアがインストールされるディレクトリで、Fusion MiddlewareとWebLogicの環境変数によって参照されます。Oracle Fusion Middlewareでは、単一のバイナリ・ファイルのインストールから複数のOracle WebLogic Serverの管理対象サーバーを作成できます。Oracle Fusion Middlewareエンタープライズ・デプロイメント・ガイドは、Fusion Middlewareシステムの単一障害点を排除し、ストレージ・サイズの最適化と保守の簡素化を実現できるように、Oracleホームをインストールして使用するためのストレージの構成方法に関する推奨事項を提供します。
Oracle Fusion Middlewareインスタンスは本番サイトにインストールされるため、セカンダリ・サイトにインストールする必要はありません。本番サイトのストレージがセカンダリ・サイトのストレージにレプリケートされる際に、本番サイトのボリュームにインストールされているOracleソフトウェアがセカンダリ・サイトのボリュームにレプリケートされます。
セカンダリ・システムは、フェイルオーバーまたはスイッチオーバーが発生した場合に、プライマリ・システムとまったく同じように動作する必要があります。最高品質のインストールとして、パッチとアップグレードを受け入れる必要があります。つまり、フェイルオーバーまたはスイッチオーバーが発生した場合、セカンダリ・システムでは、パッチとアップグレードに標準のインベントリを使用する必要があります。一貫性を維持するため、Oracleインベントリは様々なFusion Middlewareコンポーネントが使用するOracleホームと同じ頻度でレプリケートする必要があります(OracleインベントリのRTO、RPOおよび一貫性の要件は、Oracleホームに規定されている要件と同じである必要があります)。Oracleインベントリには、/etcディレクトリにあるoraInst.locファイルとoratabファイルが含まれています。
OracleホームまたはWebLogicホームが、異なるノードの複数のサーバーによって共有されている場合、これらのノードのOracleインベントリとOracleホーム・リストを常に最新の状態にして、インストールとパッチの適用状況の整合性を確保することをお薦めします。ノードでインベントリ・ファイルを更新して、これに共有ストレージのインストールを関連付けるには、ORACLE_HOME/oui/bin/attachHome.shスクリプトを使用します。
OracleホームとOracleインベントリはどちらも、実行時には静的なアーティファクトであり、必要なRTOは短いのが一般的です(Fusion Middlewareドメインの実行元のバイナリであるため)。パッチと修正が適用された場合にのみ変更されるため、リージョン間で頻繁にコピーする必要はありません。一貫性の観点から見ると、通常ランタイム・アーティファクトにはあまり制限がありません。たとえば、ほとんどのパッチは、WebLogic Serverドメインの以前の構成をサポートします。したがって、WebLogicのOracleホームにあるパッチをリージョン間で伝播しなくても、セカンダリ・ドメイン構成は適切に機能します。
構成アーティファクト
構成アーティファクトは頻繁に変更されるファイルであり、次のものが含まれています。
-
WebLogicドメイン・ホーム: 管理サーバーおよび管理対象サーバーのドメイン・ディレクトリ。
-
Oracle HTTP Serverなどのシステム・コンポーネントのOracleインスタンス: Oracleインスタンスのホーム・ディレクトリ。
-
.earファイルや.warファイルなどのアプリケーション・アーティファクト。 -
MDSリポジトリやJDBC永続ストア定義などのデータベース・アーティファクト。
-
ファイル・アダプタやJMSアダプタなどのテクノロジ・アダプタの更新に使用されるデプロイメント・プラン。これらは、アーティファクトがデプロイされるクラスタ内のすべてのノードにアクセスできる場所に保存する必要があります。
構成アーティファクトは、アプリケーションの更新に応じて頻繁に変更されます。必要なRTOは短く、レプリケーション頻度は高くなります。様々なストアにある構成アーティファクトの一貫性を維持することが重要です。そうしないと、リストア後にアプリケーションが動作しなくなる可能性があります。たとえば、新しいJMSサーバーを反映したWebLogicドメイン構成は、永続ストアとして使用するデータベース表と一致している必要があります。関連する表をレプリケートせずにWebLogicドメイン構成のみをレプリケートすると、WebLogic Serverに障害が発生します。
ランタイム・アーティファクト
ランタイム・アーティファクトとは、実行時にアプリケーションによって生成されるファイルです。たとえば、SOAのファイルやFTPアダプタによって生成されるファイル、Oracle MFTによって管理されるファイル、アプリケーションがビジネス・ロジックを介して生成し、ファイル・システムに直接格納されるその他の情報などです。これらのファイルは頻繁に変更される可能性があります。それぞれのRTOとRPOは、純粋にビジネス・ニーズによって決まります。これらのタイプのアーティファクトは、短期間で破棄する必要が生じる場合があります。たとえば、短期間で失効する入札オーダーなどです。また、アプリケーションによって完了された操作のトランザクション・レコードがこれらのファイルに含まれ、そのレコードを保持する必要がある場合もあります。どの程度の頻度でレプリケートする必要があるか、このタイプのファイルを障害発生時に保持することがどの程度重要であるかは、通常、ビジネス主導の決定事項です。
主なレプリケーション・オプション
オラクルでは、ファイル・システム上のFusion Middlewareデプロイメントで使用される様々なタイプのデータをレプリケートするための様々な方法を検証しています。他のオプションもありますが、次のオプションのみが正式にテストされており、Fusion Middlewareデプロイメントで利用できます。
ストレージ・レベルのレプリケーション
Oracle Fusion Middlewareディザスタ・リカバリ・ソリューションでは、ストレージ・レプリケーション・テクノロジを使用して、セカンダリのOracle Fusion Middleware中間層プライマリ・システムをレプリケートできます。これは、特定のストレージ・ベンダー・テクノロジを使用して、リージョン間でストレージ・ボリュームをレプリケートすることを意味します。この分野の一般的なソリューションでは、EDGに示された様々なボリュームの初期(ベースライン)スナップショットを作成した後、手動で、またはスケジュールに従って、あるいは継続的に、変更をセカンダリの場所に増分的にレプリケートします。
Oracle Databaseの障害保護にストレージ・レプリケーション・テクノロジは使用しないでください。Oracle Fusion Middlewareディザスタ・リカバリの本番サイトに含まれているデータベースの障害保護機能がOracle Data Guardによって提供されていることを確認します。
ストレージ・デバイスのレプリケーション・テクノロジによって複数のボリューム間で一貫性のあるレプリケーションが保証されることを確認します。そうしないと、Fusion Middlewareシステムで使用される様々な構成アーティファクトおよびランタイム・アーティファクトが異なる時点にレプリケートされたときに問題が発生する可能性があります。ほとんどのストレージ・ベンダーは、複数のノードが異なるストレージ・ボリュームを使用している場合の一貫性を保証しており、ある正確な時点にそれらすべてのバックアップ(またはそれらのコンテンツのレプリケート)を行うことが求められます。ボリュームは1つの論理ユニットにグループ化されますが、このユニットは通常、コンシステンシー・ボリューム・グループ、コンシステンシー・グループまたはボリューム・グループと呼ばれます。ボリューム・グループは、EDGで使用される様々なボリュームのポイント・イン・タイム・コピーを提供するため、すべてのボリュームの一貫したスナップショットがセカンダリに伝播されます。データベース・モジュールのデプロイメントがボリュームAに存在し、それを使用するアプリケーションがボリュームBに存在する状況を考えてみてください。コンシステンシー・グループがないと、アプリケーションのWARの新しいバージョンがレプリケートされても、必要なデータ・ソース構成はレプリケートされず、セカンダリで一貫性の問題が発生する可能性があります。
ストレージ・レベルのレプリケーションは、EDG内のすべてのタイプのデータ(Oracleホーム/Oracleインベントリ、構成アーティファクトおよびランタイム・アーティファクト)に対する汎用的な方法として使用できます。これは、初期設定とシステムの存続期間中の継続的なレプリケーション・サイクルの両方で有効な方法です。
rsync
rsyncは、プライマリのFusion Middlewareシステムをセカンダリ・システムにレプリケートする際にストレージ・ベンダー固有のレプリケーションのかわりに使用できます。rsyncは汎用性の高いコピー・ツールで、ローカルにコピーしたり、リモート・シェルを介して別のホストとの間でコピーできます。動作のあらゆる面を制御する多数のオプションが用意されており、コピーするファイルのセットを非常に柔軟に指定できます。
rsyncはデルタ転送アルゴリズムを実装し、ソース・ファイルと宛先の既存のファイルとの違いのみを送信することにより、ネットワーク経由で送信されるデータの量を削減します。これらの利点と利便性により、バックアップとミラーリングに広く使用されているツールです。あらゆるケースでセキュアなコピーを保証するには、SSHでrsyncを使用することをお薦めします。
rsyncは信頼性が高く、暗黙的な再試行を実装しますが、ネットワークの停止やその他の接続の問題によってファイルの同期に失敗する可能性は依然としてあります。また、rsyncでは様々なノード間での一貫性は保証されません。分散ポイント・イン・タイム・レプリケーションは提供されません。そのため、次の条件下では、rsyncをストレージ・レベルのレプリケーションのかわりに使用できます。
-
ストレージ・レプリケーションが不可能または実現可能でない場合や、コスト要件を満たしていない場合。
-
プライマリおよびスタンバイで、コピーに信頼性が高く安全なネットワーク接続を使用する場合。
-
コピーに関係する様々なノードでチェックを実行して、コピーが有効であることを確認する場合。
-
ディザスタ・リカバリ・サイトが定期的に検証される場合。
最近では、rsyncはほとんどのLinuxディストリビューションに存在しています。本番サイトのホストからセカンダリ・サイトのピア・ホストへのファイルのレプリケーションが有効になるように、rsyncをインストールおよび設定できます。ユーティリティのインストール、設定および使用方法の詳細は、ユーティリティのマニュアルとrsyncを参照してください。
rsyncレプリケーション方式には、プライマリからセカンダリにコピーするための選択肢が主に2つあります。
図2-8 ピアツーピアのコピー
この場合、各ホストからリモート・ピアへのコピーを直接実行できます。各ノードは、ピアへのSSH接続を持ち、SSHでrsyncコマンドを使用してプライマリ・システムをレプリケートします。
SSHでrsyncコマンドを使用してプライマリ・システムをレプリケートする方法の概要を示します。
この方法では、各ノードは個々のスクリプトを使用して、Fusion Middlewareのインストールと構成をリモート・ピア・ノードにrsyncします。各ノードはスクリプトをcronできます。データのタイプごとにcronジョブの異なるスケジュールを設定できます。次に例を示します。
-
製品は1か月に1回。
-
構成は1日に1回。
これは、追加のハードウェア・リソースを必要としない簡単な設定です。ただし、スクリプトが一元化されていないため、多くのノードでメンテナンスが必要になります(たとえば、クラスタが大規模になるとソリューションの複雑さが増します)。また、各ノードに個別のコピーが格納されるため、ある時点での一貫性を保証することも困難です。この方法の一貫性と検証は、中央のホストを使用して、各ノード(単一のスケジューラのように動作)でスクリプトを起動し、コピーを検証することで改善できます。
ステージング場所
この方法では、ステージング場所が使用され、通常はノードが、レプリケートする必要のある個々のホストに接続するコーディネータとして機能します。このコーディネータは、必要な構成およびバイナリ・データをステージング場所にコピーします。これは、すべてのノードにアタッチされた共有ストレージ上で、またはステージング・ホストを介して実行できます。このステージング場所は、プライマリ・ノードやセカンダリ・ノードに影響を与えずに検証できます。この方法では、個々のノードにかかるコピーのオーバーヘッドをオフロードし、残りのノードに分散された単一のインストールを使用してバイナリの一貫性を維持します。通常、この方法がピアツーピアのコピーより好まれるのは、こうした理由によります。データ・センター間で許可される接続に関して厳しいセキュリティ制限がある場合、プライマリに対してローカルなノードを使用し、プライマリ・ノードのコピーをステージングしてセカンダリのステージング場所に分散することもできます。この方法を取る場合、リージョン間のアクセスが2つのノードのみに制限され、リモート・コピー(通常はレイテンシが長くなり、オーバーヘッドが増加する)の負荷がコーディネータ・ボックスにオフロードされます。
図2-9 ステージング場所
rsyncは、EDG内のすべてのタイプのデータに対する汎用的な方法として使用できますが、アプリケーションが実行時に(常に変化する)大量のデータを生成している場合は、特定のデプロイメントごとにテストする必要があります。rsyncは、レプリケーションを実行しているノードに過大な負荷をかける可能性があるため、ワークロード・テストを実行して有効性を検証する必要があります。構成およびバイナリの場合、初期設定と継続的なレプリケーションのどちらにおいても、rsyncがパフォーマンスの問題を引き起こさないようにしてください。ランタイム・アーティファクトの場合、データの変更率を計算するために必要なRTOおよびRPOと、rysncコピーによって発生する可能性のあるオーバーヘッドを考慮する必要があります。
Oracle Database File System
Oracle Database File System (DBFS)は、プライマリからスタンバイへのレプリケートに使用できるもう1つの方法です。これは主に、(接続レベルとストレージ・レベルの両方でデータベースで発生するオーバーヘッドにより)増大はしないが頻繁に変更される構成やデータを処理することを目的としています。概念的には、データベース・ファイル・システムは、データベース表に格納されているデータのファイル・システム・インタフェースです。
DBFSは、ローカル・ファイル・システムのような共有ネットワーク・ファイル・システムを提供し、サーバー・コンポーネントとクライアント・コンポーネントの両方を持つ、NFSプロトコルに似ています。DBFSファイル・システムは、中間層ホストからマウントし、通常の共有ファイル・システムとしてアクセスできます。DBFSマウントにコピーされたコンテンツは(データベース内に存在するため)、基礎となるData Guardレプリケーションを介してセカンダリ・サイトに自動的にレプリケートされます。
この方法では、Data Guardレプリカの堅牢性を活用できます。Oracleドライバの再試行ロジックにより可用性が高く、回復可能な動作を提供します。データ・センター間の待機時間が中または高であるシナリオで使用できます。ただし、構成レプリケーションにDBFSを使用すると、設定、データベース・ストレージおよびライフサイクルの観点から、次のような影響も生じます。
-
DBFSマウントに必要な構成およびメンテナンスのために、若干の複雑さが生じます。マウント先のホストにデータベース・クライアントをインストールする必要があり、データベース(表領域、ユーザーなど)およびクライアント(ウォレット、
tnsnames.oraおよびマウント・スクリプト)で初期設定が必要なアーティファクトがいくつかあります。 -
DBFSマウントにコピーされたコンテンツはデータベースに格納されるため、データベースに追加の容量が必要です。
-
WebLogicドメイン構成またはバイナリを、DBFSマウントに直接格納することはお薦めしません。Fusion Middlewareファイルとデータベースの間に非常に強い依存関係が生じます。かわりに、DBFSを中間ステージング・ファイル・システムのような「アシスタンス」ファイル・システムとして使用することをお薦めします。これは、セカンダリ・サイトにレプリケートされる情報を配置するためのものです。このモデルでのスタンバイへのレプリケーションは、プライマリのオリジン・フォルダから中間DBFSマウントへ、次にセカンダリ・サイトのDBFSマウントからスタンバイの宛先フォルダへという2段階で行われます。中間コピーはrsyncを使用して実行されます。これは低レイテンシのローカルrsyncコピーであるため、このモデルを使用すれば、リモートrsyncコピー操作で発生する問題の一部を回避できます。次の図は、レプリケーション・フローを示しています
図2-10 Oracle Database File System (DBFS)
-
DBFSディレクトリは、データベースがオープンされている場合にのみマウントできます。Data GuardがActive Data Guard (ADG)ではない場合、スタンバイ・データベースはマウント状態です。したがって、セカンダリ・サイトでDBFSマウントにアクセスするには、データベースをスナップショット・スタンバイに変換する必要があります。ADGを使用する場合、ファイル・システムを読取り用にマウントできるため、スナップショットに遷移する必要はありません。
前述の理由により、すべてのアーティファクト(特にランタイム・ファイル)をスタンバイにレプリケートするための汎用ソリューションとしてDBFSを使用することはお薦めしません。バイナリをレプリケートするためにDBFSを使用することは過剰です。ただし、この方法は、ストレージ・レプリケーションやrsyncなどの他の方法がシステムのニーズに合わない、ドメイン共有構成のような少数のアーティファクトを(ステージング・ディレクトリを介して)レプリケートするのに適しています。DBFSがファイル・レプリケーションに最適な方法になるのは、コストや、プライマリとセカンダリの間のネットワーク接続の信頼性が低いといった要因によります。
様々なレプリケーション方式の比較
ファイル・システム・レプリケーション戦略を定義することは、RTO、RPO、管理の複雑さ、および各方法の総所有コストを考慮して意思決定を行うことを意味します。様々な側面が決定要因となる可能性がありますが、最も関連性の高い機能を次に示します。具体的なアプリケーション・ニーズとこれらの側面がディザスタ・リカバリ設計に及ぼす影響を分析する必要があります。
管理の複雑さ
DBFS方式とrsync (ステージング場所を使用)方式における構成レプリケーション手順は、WebLogicドメインのノード数にかかわらず同様です。これとは対照的に、レプリケートされたボリュームの数が増加すると、共有ストレージ・レプリケーションの管理は複雑さが増します。様々なボリュームおよびボリューム・グループのライフサイクルを適切に管理することが求められます。また、ストレージ・レプリケーションを使用する場合のスイッチオーバー操作とフェイルオーバー操作は、rsync方式とDBFS方式を使用する場合よりも複雑です。レプリケートされたボリュームのアクティブ化やアタッチなど、スイッチオーバーまたはフェイルオーバーの前後に追加のステップが発生する場合があります。個別にレプリケートする必要があるプライベート・ボリュームを各WebLogic管理対象サーバー・ノードで使用する場合には、この複雑さがさらに増します。
コストへの影響
DBFS方式では、コストの増加は、データベースでDBFS表をホストするために必要な追加のストレージに関連しています。割当て済領域を効率的にリカバリするには、データベース表領域およびストレージの一般的なメンテナンス操作が必要です。通常、リージョン間コピーにおけるネットワーク・オーバーヘッドは、Data Guardの全体的なトラフィック要件と比較すると無視できる程度です。
rsyncの場合、WebLogicドメインのファイル・ストレージ割当ては通常100GB未満であるため、ストレージ要件は低く、rsyncを介したコピーがネットワークに大きな影響を与えることもありません。
ストレージ・レプリケーションの場合、ボリュームまたはシェアのレプリケーションを有効にすると、ほとんどのストレージ・ベンダーで追加コストが発生します。レプリケーションの効率性も、ネットワークとストレージのコストに影響を与える一因です。レプリケーション・プロセスの一環として、ソース・ボリュームまたはシェアで更新されているすべてのデータがボリューム・レプリカに転送されるため、絶えず更新が発生するボリュームほどネットワーク・コストは高くなります。
レプリケーションのオーバーヘッド
DBFSとrsyncのシナリオでステージング・ディレクトリを介してコピーすると、レプリケーション・コーディネータ・サーバー(通常はWeblogic管理ノード)に影響が及びます。コピーの頻度、WebLogicドメインの大きさ、およびその他のランタイム・ファイルを同じレプリケーション・サイクルでリージョン間でレプリケートする必要があるかどうかに応じて、追加のメモリーおよびCPUリソースが必要になる場合があります。
ファイル・システム・データのリカバリ時間目標(RTO)
DBFS、rsync、ストレージのいずれのレプリケーション方法でも、スイッチオーバーのRTOは同様です。フェイルオーバー操作の場合、共有ストレージ・レプリケーションでは追加のステップが必要になります(スナップショットのアクティブ化、ボリュームのアタッチまたはマウントなど)。通常、これらの操作によってフェイルオーバー中の停止時間が増加します。
ファイル・システム・データのリカバリ・ポイント目標(RPO)
ストレージ・レプリケーション・プロセスはほとんどのベンダーで継続的に行われており、リカバリ・ポイント目標(RPO)の一般的なターゲット速度はわずか数分です。ただし、RPOはソース・ボリューム上のデータの変更速度によって変わる可能性があります。DBFS方式とrsync方式では、WebLogic構成のRPOをより細かく制御できます。これは、スケジュール済のスクリプトを使用して情報がレプリケートされ、レプリケートされる情報の量がストレージ・ボリューム全体より少ないためです。その一方で、DBFS方式とrsync方式では、受け取ったドメイン構成の「マネージャ」として機能するのは通常、管理サーバーのノードであるため、このノードの可用性と容量に応じて構成コピーの速度が向上します。ストレージ・レプリケーションを使用する場合、オフライン・レプリケーション方式として使用できるセカンダリ・ノードが稼働しているかどうかに関係なく、レプリケーションは継続して実行されます。
要約すると、システムのRTO、RPOおよびコストのニーズは、可能なかぎり最適なレプリケーション方式の決定要因となります。アプリケーションの要件を分析して、最適なソリューションを決定してください。
プライマリ・システムの準備
プライマリ・サイトが、Oracle Fusion Middlewareエンタープライズ・デプロイメント・ガイドに規定されているベスト・プラクティスに従って作成されていることが前提となります。EDGで推奨されているネットワーク、ホスト名、ストレージおよびデータベースがプライマリ・システムにすでに存在している必要があります。
これにより、障害からの保護を提供する前に、様々なレイヤーでのローカル停止(データ・センター全体に影響を及ぼす障害よりもはるかに頻繁に発生することが予想される)も回避されることを保証できます。
EDGに記載されているリスニング・アドレス、ストレージ割当ておよびディレクトリの考慮事項は、すでに障害保護を考慮して設計されています。プライマリでなんらかの代替策が採用されている可能性もありますが、これらを修正して災害保護を実装できます。最も一般的なのは、バイナリおよび構成情報に(EDGで推奨されている共有ストレージではなく)ローカル・ストレージを使用しているケースや、様々なFusion Middlewareコンポーネントでリスニング・アドレスとして適切な別名を使用していないケースです。以降の項では、ディザスタ・リカバリ用にプライマリ・サイトを準備する方法について説明します。
ストレージ・レプリケーション用のプライマリ・ストレージの準備
共有ストレージへのOracleホームの移動
Oracle Fusion Middlewareディザスタ・リカバリにストレージ・レプリケーションを使用する場合、Oracleホームと中間層の構成は、Fusion Middlewareコンポーネントのエンタープライズ・デプロイメント・ガイドに記載されている推奨事項に従って、共有ストレージに配置する必要があります。これにより、少なくとも2つのOracleホームの場所が使用されるため(1つは偶数ノード用、もう1つは奇数ノード用)、Oracleホームのメンテナンスが容易になり、高可用性も得られます。
本番サイトを最初に作成したときにディザスタ・リカバリを考慮していなかった場合、サイトを構成するOracle Fusion Middlewareインスタンスのディレクトリが各ノード専用のローカル・ストレージに配置されることがあります。このシナリオでは、Oracle Fusion Middlewareディザスタ・リカバリ・ソリューションを実装するために、ホームを完全に共有ストレージに移行することをお薦めします。この操作を行う際には、プライマリ・システムで停止時間が発生する可能性があるため、適切に計画して影響を最小限に抑える必要があります。この変更が推奨されるのは、DR戦略が容易になるだけでなく、Oracleホームとドメイン構成の管理も簡素化されるためです。
ローカル・ディスクから共有ストレージに本番サイトを移行する際のガイドラインは次のとおりです。
-
共有ストレージに移動するフォルダのオフライン・バックアップを実行します。OSコマンドを使用してバックアップを実行する場合は、ルート・ユーザーとしてバックアップを実行し、その権限を保持している必要があります。
『Oracle Fusion Middleware Oracle Fusion Middlewareの管理』のバックアップのタイプおよび推奨されるバックアップ戦略に関する項を参照してください
-
コンテンツをNFSに移動しても、パスは保持されます。NFSに移動する予定の現在のフォルダ(
/u01/oracle/productsなど)がマウント・ポイントになります。これの準備として、マウント・ポイントが空になるように、現在のフォルダを別のパスに移動するか名前変更します。 -
共有ストレージがマウントされるマウント・ポイントが存在し、空であり、適切な所有権を持っていることを確認します。
-
共有ストレージを適切なマウント・ポイントにマウントします。共有ストレージのディレクトリ構造は、エンタープライズ・デプロイメント・ガイドの説明に従って設定する必要があります。
-
共有ストレージがマウントされたら、バックアップ(または名前を変更したフォルダ)のコンテンツを、共有ストレージにあるフォルダにコピーします。
たとえば、/u01/oracle/productsにある製品フォルダをローカル・ディスクからNFSフォルダに移動します。
-
ローカル・フォルダ内のコンテンツをバックアップするために、モードを保持したまま、ユーザー・ルートによってコピーが実行されます。
[root@soahost1]# cp -a /u01/oracle/products /backups/products_backup -
マウント・ポイントになるフォルダは空である必要があるため、現在のフォルダが移動されます。
[root@soahost1]# mv /u01/oracle/products /u01/oracle/products_local -
フォルダの名前を変更した後、マウント・フォルダ・ポイントが存在することをチェックし(存在しない場合は作成する必要があります)、マウント・フォルダ・ポイントが空であり、正しい所有権を持っていることを確認します。次の例では、マウント・ポイントは
/u01/oracle/productsです。[root@soahost1]# mkdir -p /u01/oracle/products [root@soahost1]# ls /u01/oracle/products [root@soahost1]# chown oracle:oinstall /u01/oracle/products -
NFSボリュームはマウント・ポイントにマウントされます。
[root@soahost1]# mount -t nfs nasfiler:VOL1/oracle/products/ /u01/oracle/products/ -
これを永続化するには、各ホストの
/etc/fstabにマウントを追加します。 -
これで、バックアップのコンテンツがマウントにコピーされます。
[root@soahost1]# cp -a /backups/products_backup /u01/oracle/products
同様の方法を使用して、プライベートのWebLogicドメイン・ディレクトリを共有ストレージに移動できます。これにより、管理対象サーバーのドメイン・ディレクトリ・コンテンツに使用するステージング場所が不要になり、レプリケーションが容易になります。管理対象サーバーのプライベート構成ディレクトリに共有ストレージを使用する方法の詳細は、EDGを参照してください。
ボリューム・グループの作成
共有ストレージ上の関連ボリュームがEDGの推奨事項に従って割り当てられたら、スナップショットとボリューム・グループをレプリケーション用に準備する必要があります。
ほとんどのストレージ・ベンダーは、複数のノードが異なるストレージ・ボリュームを使用している場合の一貫性を保証しており、ある正確な時点にそれらすべてのバックアップ(またはそれらのコンテンツのレプリケート)を行うことが求められます。ボリュームは1つの論理ユニットにグループ化されますが、このユニットは通常、コンシステンシー・ボリューム・グループ、コンシステンシー・グループまたはボリューム・グループと呼ばれます。ボリューム・グループは、エンタープライズ・デプロイメント・ガイドで使用される様々なボリュームのポイント・イン・タイム・コピーを提供するため、すべてのボリュームの一貫したスナップショットがセカンダリに伝播されます。
データベース・モジュールのデプロイメントがボリュームAに存在し、それを使用するアプリケーションがボリュームBに存在する状況を考えてみてください。コンシステンシー・グループがないと、アプリケーションのWARの新しいバージョンがレプリケートされても、必要なデータ・ソース構成はレプリケートされず、セカンダリで一貫性の問題が発生する可能性があります。このような状況を回避するために、Oracle Fusion Middlewareエンタープライズ・デプロイメント・トポロジで提案されている様々なボリュームを使用する場合には、次のコンシステンシー・グループをお薦めします。この例は、Oracle Fusion Middleware SOA Suiteの正確なケースを使用したものですが、他のFusion Middlewareシステムにも当てはまります。
-
管理サーバーおよび管理対象サーバーのドメイン・ディレクトリを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表2-8の
DOMAINGROUP)。Oracle Fusion Middleware 14.1.2では、EDGにより、様々なコンポーネント(ノード・マネージャ、WebLogic Server)のSSLの構成に必要なアイデンティティおよびトラストストアが、管理サーバーのドメイン構成と同じボリュームに配置されます。SSL証明書とストアを別の場所に配置する場合は、その場所がDOMAINGROUPコンシステンシー・グループの一部として含まれていることを確認してください。WebLogicコンポーネントのSSL構成には、KESYTORE_HOMEの場所への依存関係があるためです(様々なコンポーネントのSSL構成の詳細は、EDGを参照してください)。 -
WebLogic Serverドメインで実行されているアプリケーションによって生成されたランタイム・アーティファクト(存在する場合)を含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表2-8の
RUNTIMEGROUP)。 -
Oracleホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表2-8の
FMWHOMEGROUP)。
表2-8に、図2-1に示されているOracle SOA Suiteトポロジのコンシステンシー・グループに関する推奨事項の概要を示します。
表2-8 Oracle SOA Suiteのコンシステンシー・グループ
| 層 | グループ名 | メンバー | 備考 |
|---|---|---|---|
|
アプリケーション |
|
|
管理サーバー、管理対象サーバーのドメイン・ディレクトリ用のコンシステンシー・グループ |
|
アプリケーション |
|
|
共有ランタイム・コンテンツのコンシステンシー・グループ |
|
アプリケーション |
|
|
Oracleホーム用のコンシステンシー・グループ |
rsyncレプリケーション用のプライマリ・ストレージの準備
ピアツーピアの使用
ピアツーピア・モデルでrsyncレプリケーション方式を使用する場合、プライマリの準備の一環として、関連するrsyncスクリプトを各ピアへの初期コピー用に(ノードごとに1つ)準備する必要があります。プライマリ・システムにコピーとチェックサム検証の実行負荷がかからないようにすることをお薦めします。CPU、メモリーへの影響、およびディスクI/O操作の数の点では、セカンダリがプライマリから情報をプルしても、プライマリがファイル・システムのコピーをセカンダリにプッシュしても、大きな違いはありません。ただし、セカンダリからrsyncを起動すると、次のような利点が得られます。
-
cronジョブをスケジュールする際に、プライマリに干渉することはありません(プライマリで何かをスケジュールする必要はなく、rsync操作を開始するためにプライマリを操作する必要はありません)。
-
rsync操作中のエラーに対するハード・ストップの制御が向上します。
-
操作のログおよび分析がセカンダリに効果的にオフロードされます。
このような理由から、ピアツーピア・モデルでは通常、rsyncスクリプトはセカンダリで準備され、プライマリの準備の一部とはみなされません。考慮する必要がある側面は、セカンダリとプライマリの間の適切なSSH接続のみです。rsync操作を実行する前に、セカンダリの各ノードとプライマリのピアの間でSSH接続が許可され、機能していることを確認します。アクセスにはSSHキーを使用することをお薦めします。セカンダリのwlsnode1ピアから単純なssh -i path_to_keyfile primary_wlsnode1_ip_primaryを試します。トポロジに参加している各OHSノードおよびWLSノードについて検証を繰り返します。スクリプトと最初のレプリケーションは、セカンダリの設定の一部として実行されます。
ステージング場所の使用
ステージング方式を使用する場合は、ステージング・コピーをホストする中央の場所(共有ストレージ上が最適)と、プライマリ・ノードからステージング・ディレクトリに転送するスクリプト、およびステージング・ディレクトリからターゲットのセカンダリ・ノードに転送するスクリプトを作成する必要があります。2つのステージング場所を使用する場合(プライマリで1つ、セカンダリで1つ使用して、サイト間の接続要件を削減)、プライマリ・ノードからプライマリのステージング場所へのコピー用、プライマリのステージング場所からセカンダリのステージング場所へのコピー用、セカンダリのステージング場所からセカンダリの様々なノードへのコピー用に、3つのスクリプト・セットが必要です。この方法は、バックアップ計画の拡張版としても役立ちます。各場所に、様々なノードに分散できるバックアップ・コピーがあります。プライマリのノードごとに、ステージングを担当するノード(通常はセカンダリの管理サーバー・ノード)にスクリプトを準備します。各ノードのWebLogicドメイン・コピーを特徴付ける必要があります。たとえば、次のような構造を使用します。
図2-11 ステージング場所
rsync操作を実行する前に、プライマリの各ノードとプライマリのステージング・ノードの間、およびプライマリのステージング・ノードとセカンダリのステージング・ノードの間でSSH接続が許可され、機能していることを確認します(2ステージング場所モデルを使用する場合)。プライマリの各WebLogicノードおよびOHSノードから単純なssh -i path_to_keyfile primary_stagenode_ip_primaryを試します。プライマリとセカンダリの両方でステージング場所を使用している場合は、セカンダリでもステージング・オーケストレータからSSH接続を確認します。
1つ以上のOracle Fusion Middlewareコンポーネントがインストールされている本番サイトの各ホストについて、次のディレクトリおよびファイルを、セカンダリの同じディレクトリおよびファイルに、さらにはステージング・ホストにコピーするように、rsyncを設定します。
-
Oracleホームのディレクトリとサブディレクトリ。
-
Oracle中央インベントリ・ディレクトリ(Oracle Fusion Middlewareインストール用のOracle Universal Installerエントリを含む)。
-
WebLogic管理サーバーのドメイン・ディレクトリ、デプロイメント・プラン、アプリケーション、キーストアなどの共有構成フォルダ。このフォルダはEDG内のすべての中間層ホストで共有されるため、ホストごとにコピーを用意する必要はありません。共有WebLogicドメイン・ディレクトリのみをレプリケートしないでください。EDGのコンテキストでは、WebLogicドメイン構成とともにコピーする必要のある依存関係が
/u01/oracle/config/applicationsおよび/u01/oracle/config/keystoresディレクトリに存在します。 -
WebLogic管理対象サーバーのドメイン、ホスト上のローカル・ノード・マネージャ・ホームなどのプライベート構成フォルダ。
-
共有ランタイム・フォルダ(該当する場合)。
-
ホスト上のOracle HTTP Serverインストール用のOracle Fusion Middlewareの静的HTMLページ・ディレクトリ(該当する場合)。
たとえば、GitHubにあるスクリプトを使用すると、ステージング・コピー用にプライマリ・システムを準備できます。スクリプトrsync_for_WLS.shは、rsync_copy_and_validate.shを呼び出すラッパーです。この2番目のスクリプトは、推奨されるrsync構成でrsyncコピーを実行するための実際のロジックを含んでおり、コピーの完了後にファイルの徹底的な検証を実行します。検証を複数回再試行した後に差異が検出された場合、差異に対処できるようにログに記録されます。
デフォルトでは、rsync_copy_and_validate.shはユーザーとしてoracleを使用してコピーを実行します。別のユーザーがオリジン・フォルダを所有している場合は、スクリプト内のプロパティUSERをカスタマイズしてください。
また、環境変数DEST_FOLDERを使用して、コンテンツのrsyncに使用されるターゲットの場所を決定します。変数が設定されていない場合、スクリプトを実行しているノードの、ソース・ノードで使用されているものとまったく同じディレクトリ・パスにコンテンツをコピーします。ステージング方式を使用する際には、変数を(WLSノードの最初のプライベート構成などの)目的のパス/staging_share_storage/midtier/wls_private_config/wlsnode1_private_configに設定します。
-
プライマリ・ノードから任意のフォルダをrsyncするには、プライマリのステージング・ノードで、各プライマリ・ノードのディレクトリを所有するユーザーとして
rsync_for_WLS.shを使用します。SSH接続にSSHキー・ファイルを使用する場合、rsync_for_WLS.shは、3つのパラメータ(コピーのプル元となるノードのIP、レプリケートされるパス、およびSSHキー・ファイル)を指定して実行する必要があります。次に例を示します。./rsync_for_WLS.sh 10.1.1.1 /u01/oracle/config/domains/soaedg/ /home/oracle/keys/SSH_KEY.privまた、2つのパラメータ(コピーのプル元となるノードのIPとレプリケートされるパス)のみを指定して実行することもできます。この場合、rsyncで使用されるSSH接続は、SSHパスワードを要求します(スクリプトを実行する前に、パスワードベースのSSHを設定する必要があります)。
./rsync_for_WLS.sh 172.11.2.113 /u01/oracle/config/domains/soaedg/ -
まず、プライマリ管理サーバー・ノード全体をレプリケートします。次のように、製品フォルダ、共有構成フォルダおよびプライベート・ドメイン構成フォルダに対してスクリプトを実行します(このマニュアルに示す例を使用すると、172.11.2.113がプライマリ管理サーバーのIPになります)。
[oracle@staging_node]$ export DEST_FOLDER=/staging_share_storage/midtier/wls_products_home/wls_products_home1 [oracle@staging_node]$./rsync_for_WLS.sh 172.11.2.113 /u01/oracle/products /home/oracle/keys/SSH_KEY.priv [oracle@staging_node]$ export DEST_FOLDER=/staging_share_storage/midtier/wls_shared_config [oracle@staging_node]$./rsync_for_WLS.sh 172.11.2.113 /u01/oracle/config /home/oracle/keys/SSH_KEY.priv [oracle@staging_node]$ export DEST_FOLDER=/staging_share_storage/midtier/wls_private_config/wlsnode1_private_config [oracle@staging_node]$./rsync_for_WLS.sh 172.11.2.113 /u02/oracle/config/ /home/oracle/keys/SSH_KEY.priv -
次に、2番目のWLSサーバー・ノードをレプリケートします。次のように、製品フォルダとプライベート・ドメイン構成フォルダに対してスクリプトを実行します(このマニュアルに示す例を使用すると、172.11.2.114がプライマリWLSサーバー・ノード2のIPになります)。
[oracle@staging_node]$ export DEST_FOLDER=/staging_share_storage/midtier/wls_products_home/wls_products_home2 [oracle@staging_node]$./rsync_for_WLS.sh 172.11.2.114 /u01/oracle/products /home/oracle/keys/SSH_KEY.priv [oracle@staging_node]$ export DEST_FOLDER=/staging_share_storage/midtier/wls_private_config/wlsnode2_private_config [oracle@staging_node]$./rsync_for_WLS.sh 172.11.2.114 /u02/oracle/config /home/oracle/keys/SSH_KEY.priv -
2つのOHSノードをレプリケートします。OHSインスタンスはスタンドアロン・モードで実行されるため、共有構成フォルダはなく、プライベート・ドメイン構成のみを次のようにレプリケートする必要があります(このマニュアルに示す例を使用すると、172.11.2.111がプライマリOHSノード1になります)。
[oracle@staging_node]$ export DEST_FOLDER=/staging_share_storage/webtier/ohs_products_home/ohs_products_home1 [oracle@staging_node]$./rsync_for_WLS.sh 172.11.2.111 /u02/oracle/products /home/oracle/keys/SSH_KEY.priv [oracle@staging_node]$ export DEST_FOLDER=/staging_share_storage/webtier/ohs_private_config/ohsnode1_private_config [oracle@staging_node]$./rsync_for_WLS.sh 172.11.2.111 /u02/oracle/config /home/oracle/keys/SSH_KEY.priv
以上を実行すると、OHSノードとWLSノードすべての完全なコピーが(使用したステージング・モデルに応じて、プライマリまたはセカンダリの)ステージング場所に作成されます。
DBFS用のプライマリ・ストレージの準備
DBFSの場合、プライマリ・システムを準備するには、DBFSマウント・ポイントを使用するホストにDBクライアントをインストールする必要があります。そのためには、いくつかのアーティファクトをデータベース(表領域、ユーザーなど)とクライアント・ノード(ウォレット、tnsnames.oraなど)に作成する必要があります。GitHubからスクリプトをダウンロードし、次のステップを実行して必要なDBFSマウントを構成します。
-
edeliveryからOracle DBクライアントをダウンロードし、中間層ホストにアップロードします(まだインストールしません)。イメージベース・バージョンではなく、インストーラ・バージョンをダウンロードしてください。ソフトウェアをダウンロードし、すべての中間層ホストにアップロードします。たとえば、
/u01/install/V982064-01.zipです。 -
GitHubからダウンロードしたスクリプトの中からスクリプト
dbfs_dr_setup_root.shを見つけて、中間層ホストにコピーします。このスクリプトは、ホストでDBFSマウントを準備するために必要なタスクを実行します。DBクライアントと必要なオペレーティング・システム・パッケージをインストールし、DBFSユーザーおよびスキーマをデータベースに構成します。さらに、DBFSファイル・システムをマウントして、DBFSファイル・システムがホストの起動時にマウントされるようにcronを作成します。 -
次の構文を使用して、rootユーザーとしてスクリプトを実行します。
./dbfs_dr_setup_root.sh <local_db_scan_name> <db_port> <local_PDB_service> <pdb_sys_password> <path_to_dbclient_installer>入力パラメータとして、WLSで使用されるローカル・データベースへの接続に使用する接続データを指定する必要があります。プライマリ・サイトの中間層ノードにプライマリのPDB接続データを指定し、セカンダリ・サイトの中間層ノードにセカンダリのPDB接続データを指定します。各ドメインのデータ・ソースからローカルSCAN名、ポートおよびPDBサービス名を取得できます。
ノート:
セカンダリ・ホストでスクリプトを実行する前に、スタンバイ・データベースをスナップショット・モードに変換する必要があります。プライマリのPDB値を指定する必要があります。プライマリの中間層ホストを実行する例を次に示します(単一行である必要があります)。
./dbfs_dr_setup_root.sh drdba-scan.wlsdrvcnlon1ad2.wlsdrvcnlon1.oraclevcn.com 1521 PDB1.wlsdrvcnlon1ad2.wlsdrvcnlon1.oraclevcn.com mypassword /u01/install/V982064-01.zipDBFSがデフォルトのPDB管理サービスではなく、CRSサービスに接続するように、適切なサービス名を指定します。RACシナリオでの実行例を次に示します。
./dbfs_dr_setup_root.sh drdbrac2a-scan.subnetlon1.myvcnlon.oraclevcn.com 1521 mypdbservice.mycompany.com mypassword /u01/install/V982064-01.zip -
DBFSマウントが中間層ホストで使用可能になったかどうかを確認します。
[root@ wlsociprefix-wls-1]# df -h | grep dbfs dbfs-@PDB1:/ 32G 248K 32G 1% /u02/data/dbfs_root [root@ wlsociprefix-wls-1]# ls /u02/data/dbfs_root dbfsdir
すべての中間層ホストで、次のステップを繰り返します。
-
dbクライアント・ソフトウェアが中間層ホストのフォルダ
/u01/app/oracle/clientにインストールされます。dbクライアントに必要なパッケージがyumを使用してインストールされます。 -
DBFS用のユーザーがPDBデータベースに作成されます。ユーザー名はdbfsuserで、パスワードはスクリプトの入力として指定されたものと同じ
SYSパスワードに設定されます。 -
DBFSマウント用にDBFS表領域がPDBデータベースに作成され(表領域名は
tbsdbfs)、DBFSフォルダが作成されます(名前はdbfsdir)。 -
新しいフォルダがドメイン
DOMAIN_HOME/dbfsに作成されます。これには、dbfsuserのパスワードとその他の必要なアーティファクト(tnsnames.ora、sqlnet.ora)を格納するためのウォレットが含まれます。このウォレットは、dbfsマウントを中間層ホストにマウントするために、dbクライアントによって使用されます。 -
スクリプト
dbfsMount.shもDOMAIN_HOME/dbfsに作成されます。このスクリプトは、dbfsマウントを中間層にマウントするために使用されます。また、再起動時にcronに追加されるため、マシンの再起動時にスクリプトが実行されます。 -
DBFSマウントが、フォルダ
dbfsdirとして/u02/data/dbfs_rootマウント・ポイントにマウントされます。
エラーが発生した場合は、再度スクリプトを実行できます。再実行時には、いくつかのアーティファクト(dbユーザー、表領域など)がすでにDBに作成されている場合があるため、警告が発生しますが、これらのメッセージは無視しても構いません。
本番ホストのホスト名をリスナー・アドレスとして保持
障害時保護を考慮せずにプライマリ・サイトを作成した場合、Fusion Middlewareコンポーネントがリスナー・アドレスとしてホスト名別名を使用して構成されているのではなく(EDGで推奨され、このドキュメントのこれまでの項で説明されている方法)、Fusion Middlewareコンポーネントが存在するノードの物理ホスト名が使用されている可能性があります。この場合、次の2つの選択肢があります。
-
サーバーのリスナー・アドレスとしてホスト別名を使用するように、既存のサイトのWebLogicドメイン構成を変更します。WLSサーバーのエンドポイントにアクセスするすべてのクライアント(JMSクライアントやRMIクライアントなど)が新しいホスト名を直接認識する必要があるため、この変更を行うと他にも影響が出ます。
ノート:
フロントエンド・ロード・バランサの仮想サーバーがすでに使用されているため、これはHTTPアクセスには当てはまりません。 -
本番構成を変更できない場合は、構成をそのまま保持し(Fusion Middlewareコンポーネントのリスナー・アドレスとして物理ホスト名を引き続き使用し)、ホスト名解決を操作して、セカンダリをこれらのホスト名に合せることができます。
これを行えるのは、プライマリとセカンダリで個別のDNSサービスを使用する場合、または関連するセカンダリ・ノードでローカル・ホスト解決を操作する場合です(詳細は、「ホスト名の解決」の項を参照してください)。この場合、プライマリ物理ホスト名は、セカンダリ・サイト・ホストの
/etc/hostsに別名として追加する必要があります。例:
コンポーネントの別名を使用しない本番サイト・ホストの
/etc/hostsエントリ127.0.0.1 localhost.localdomain localhost 172.11.2.134 prsoa-vip.example.com prsoa-vip 172.11.2.111 prweb1.example.com prweb1 172.11.2.112 prweb2.example.com prweb2 172.11.2.113 prsoa1.example.com prsoa1 172.11.2.114 prsoa2.example.com prsoa2セカンダリ・サイト・ホストの
/etc/hostsエントリ127.0.0.1 localhost.localdomain localhost 172.22.2.134 scdrysoa-vip.example.com scdrysoa-vip prsoa-vip.example.com prsoa-vip 172.22.2.111 scdryweb1.example.com scdryweb1 prweb1.example.com prweb1 172.22.2.112 scdryweb2.example.com scdryweb2 prweb2.example.com prweb2 172.22.2.113 scdrysoa1.example.com scdrysoa1 prsoa1.example.com prsoa1 172.22.2.114 scdrysoa2.example.com scdrysoa2 prsoa2.example.com prsoa2
プライマリ中間層でのデータ・ソースの準備
WebLogicデータ・ソースで使用される接続文字列の構成に使用できる方法がいくつかあります。ディザスタ・リカバリおよび最大可用性の目的では、これらの接続文字列でTNS別名を使用することをお薦めします。その他の方法は、ローカル・データベース・スタンバイやストレッチ・クラスタといった特殊なケースのニーズに対応する場合に有効な代替手段です。
構成のメンテナンスおよび可用性の目的では、TNS別名を使用することをお薦めします。各WebLogicデータ・ソースで長い接続文字列を繰り返し使用するかわりに、JDBC URLでTNS別名を使用できます。詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のDB接続文字列のかわりにTNS別名を使用する方法に関する項を参照してください。これは、エンタープライズ・デプロイメント・ガイドでも規定されています。Oracle Fusion Middleware 14.1.2では、データベース・クライアント・モジュールを使用してtnsnames.oraファイルをデプロイし、それらがWebLogicインフラストラクチャで直接管理されるようにします。TNS別名はプライマリとセカンダリで同じであるため、データ・ソースが両方の場所で使用するDB接続文字列のテキストも同じになります。TNS別名は、WebLogicドメイン構成によって管理されるtnsnames.oraファイルで解決されます。このファイルをプライマリからスタンバイにレプリケートすることはできないため、別名はサイトごとにローカル・データベースにマップされます。
-
ストレージ・レプリケーションに含まれている場合は、各レプリケーション・サイクルの後に、セカンダリの適切なローカル・データベース・サービスおよびアドレスを使用して更新する必要があります。
-
rsyncまたはDBFSを使用する場合は、レプリカ・スクリプトの除外ファイル・リストに含めるだけです。これにより、初期設定とシステムのライフサイクルにおける継続的なレプリケーションの間に、文字列の置換や不要な操作が行われるのを回避できます。
各サイトでは、ローカル・データベースのみを指す適切な接続文字列を使用して、TNS別名を解決します。プライマリのデータ・ソースに新しいデータベース接続文字列を追加した場合、適切な新しい別名情報を使用して、セカンダリでtnsnames.oraファイルを再度更新する必要があります。
たとえば、プライマリ・サイトのデータ・ソースの接続文字列は次のようになります。
jdbc:oracle:thin:@soaedg
ここで、プライマリのtnsnames.oraファイルには次が含まれます。
SOAEDG =
(DESCRIPTION=
(ADDRESS_LIST=
(LOAD_BALANCE=ON)
(ADDRESS=(PROTOCOL=TCP)(HOST=prmy-scan)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME=soaedg.example.com))
)セカンダリ・サイトのデータ・ソースの接続文字列は次のようになります。
jdbc:oracle:thin:@soaedg
ここで、セカンダリのtnsnames.oraファイルには次が含まれます。
SOAEDG =
(DESCRIPTION=
(ADDRESS_LIST=
(LOAD_BALANCE=ON)
(ADDRESS=(PROTOCOL=TCP)(HOST=stby-scan)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME=soaedg.example.com))
)このtnsnames方式の利点は、WebLogicドメイン構成で同じDB接続文字列が使用されるため、構成をプライマリからスタンバイにレプリケートした後にWebLogic構成を変更する必要がないことです。各サイトがローカル・データベースのみを指しているため、中間層からリモート・データベースへのクロス接続のリスクはありません。
障害保護システムの初期レプリケーションおよび設定に進む前に、Fusion Middlwareシステムで使用される様々なデータ・ソースのすべてがTNS別名で構成されていることを確認してください。これにより、構成管理が簡素化され、システムのRTOが最適化されます。
セカンダリ・システムの準備
この項では、セカンダリ・システムの設定方法について説明します。
セカンダリ・サイトのネットワーク・コンポーネントの準備
ディザスタ・リカバリ・ソリューションを計画する場合は、セカンダリで正確なホスト名を割り当て、プライマリと同じ仮想サーバーでロード・バランサを構成し、障害発生時にシステムにアクセスするように外部クライアントを準備する必要があります。
ホスト名の準備
セカンダリの場所では、Fusion Middlewareコンポーネントで使用されるホスト名アドレスが、セカンダリ・サイトの有効なIPアドレスに解決可能である必要があります。
「ホスト名の解決」の項の説明に従い、優先ホスト名解決メカニズムを使用してこのマッピングを作成します。
EDGで規定されているように、実際の物理ノード名(サイトごとに異なる)をFusion Middlewareコンポーネントで使用されるホスト名(サイトに関係なく同じ)から分離するために、物理ホスト名の別名を作成することをお薦めします。
この項では、既存のプライマリ・サイトにセカンダリ・サイトのOracle Fusion Middlewareインスタンスを使用する中間層ホストについて、物理ホスト名およびホスト名別名を計画する方法を説明します。ホスト名の例として、図2-1に示されているOracle SOA Suiteエンタープライズ・デプロイメントを使用します。本番サイトの各ホストにセカンダリ・サイトのピア・ホストがあります。ピアのWebLogic Serverおよびプロセスは、もう一方のサイトの対応するポートと同じポートを使用します。
次の項では、セカンダリ・サイトでホスト名を設定してプライマリ・システムの構成をマップする方法を示します。
ノート:
示されている例では、最初の本番サイトのホストのIPアドレスは172.11.x.xという形式で、最初のセカンダリ・サイトのホストのIPアドレスは172.22.x.xという形式です。
Oracle SOA Suiteの本番サイトおよびセカンダリ・サイトのリスニング・アドレスに対するホスト名の例
Oracle SOA Suiteセカンダリ・サイトのホスト名マッピングについて学習します。
表2-9に、『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』(EDG)のデプロイメントの本番サイト・ホストに使用するIPアドレス、物理ホスト名および別名を示します。プライマリのWebLogic Serverのリスニング・アドレスおよびチャネル(存在する場合)では、IPアドレスや物理ホスト名ではなく、ホスト名別名を使用する必要があります。
表2-9 SOA Suiteの本番サイト・ホストのIPアドレスと物理ホスト名
| IPアドレス | 物理ホスト名 | ホスト名別名 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
表2-10に、『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』(EDG)のデプロイメントのセカンダリ・サイト・ホストに使用するIPアドレス、物理ホスト名および別名を示します。
表2-10 SOA Suiteのセカンダリ・サイト・ホストのIPアドレスと物理ホスト名
| IPアドレス | 物理ホスト名 | ホスト名別名 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ノート:
個別のDNSサーバーをプライマリとセカンダリで使用してホスト名を解決する場合、本番サイトのホストとセカンダリ・サイトのホストに同じ物理ホスト名を使用できるので、ホスト名別名をセカンダリ・サイトのホストで定義する必要はありません。個別のDNSサーバーを使用してホスト名を解決する方法の詳細は、「個別のDNSサーバーを使用したホスト名の解決」を参照してください。
ただし、実際の物理ホスト名(サイトごとに異なる)をFusion Middlewareコンポーネントで使用されるホスト名(サイトに関係なく同じ)から分離するために、異なるホスト名と同じ別名を使用することをお薦めします。
図2-12に、セカンダリ・サイトでOracle SOA Suite EDGデプロイメントに使用する物理ホスト名を示します。
図2-12 Oracle SOA Suiteデプロイメントのスタンバイ・セカンダリ・サイトで使用する物理ホスト名
必要な仮想IPの準備
通常のホスト名リスニング・アドレスに加えて、「仮想IPに関する考慮事項」の項で説明されているように、WebLogic Serverの移行をサポートしていないコンポーネント用に追加の仮想ホスト名が必要になる場合があります。Oracle SOA Suiteの場合、この仮想ホスト名およびマッピングIPが必要なのはWebLogic管理サーバーのみです。
表2-11に、Oracle SOA Suite EDGデプロイメントの本番サイト・ホストに使用した仮想IPアドレスと仮想ホスト名を示します。
表2-11 SOA Suiteの本番サイト・ホストの仮想IPアドレスと仮想ホスト名
| 仮想IPアドレス | 仮想ホスト名 | ホスト名別名 |
|---|---|---|
|
|
|
|
表2-12に、Oracle SOA Suite EDGデプロイメントのセカンダリ・サイト・ホストに使用する仮想IPアドレス、仮想ホスト名およびホスト名別名を示します。図2-2に、セカンダリ・サイトでOracle SOA Suite EDGデプロイメントに使用する物理ホスト名を示します。図2-2に示されているOracle SOA Suiteのセカンダリ・サイト・ホストについては、表2-12に示されているホスト名別名を定義する必要があります。
ノート:
個別のDNSサーバーを使用してホスト名を解決する場合、本番サイトのホストとセカンダリ・サイトのホストに同じ仮想IPアドレスおよび仮想ホスト名を使用できるため、ホスト名別名を定義する必要はありません。
個別のDNSサーバーを使用してホスト名を解決する方法の詳細は、「個別のDNSサーバーを使用したホスト名の解決」を参照してください。
表2-12 SOA Suiteのセカンダリ・サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名
| 仮想IPアドレス | 仮想ホスト名 | ホスト名別名 |
|---|---|---|
|
|
|
|
ノート:
本番サイトとセカンダリ・サイトのサブネットは異なります。ノート:
個別のDNSサーバーを使用してホスト名を解決する場合、本番サイトのホストとセカンダリ・サイトのホストに同じホスト名を使用できるため、ホスト名別名を定義する必要はありません。セカンダリ・サイトでのロード・バランサの準備
ディザスタ・リカバリ・トポロジでは、プライマリ・システムとセカンダリ・システムの両方で、すべてのHTTP/HTTPsリクエストのフロントエンドとして機能し、同等の構成を持つ、ハードウェア・ロード・バランサが使用されます。各ロード・バランサは、ローカル・サイトのサーバー間のトラフィックのバランスを取ります。
セカンダリ・ロード・バランサは、フロントエンドとして機能するために必要な機能をサポートしている必要があります。詳細は、『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』のハードウェア・ロード・バランサの要件に関する項を参照してください。
本番ロード・バランサとセカンダリ・ロード・バランサで使用される仮想フロントエンド名は同じである必要があります。その仮想フロントエンド名は、毎回プライマリ・ロールを持つサイトのロード・バランサのIPを使用してDNSで解決される必要があります。
プライマリで構成された様々なタイプのネットワーク・トラフィックや監視に対応するように、仮想サーバーや関連するポートをロード・バランサに構成する必要があります。
セカンダリのOracle HTTP Serverのリスニング・アドレスを使用し、リスナーに同じポートを使用して、仮想サーバーのバックエンド・プールを構成します。また、プライマリの場合と同様に、セカンダリ・ロード・バランサも可用性を監視するように構成して、サービスの停止時にこれらへのトラフィックができるだけ早く停止されるようにする必要があります。これによって、特定の仮想ホストの着信トラフィックが他の層の使用不可のサービスに送信されることがなくなります。
EDGで規定されているように、外部トラフィックと内部トラフィックを処理する際には、2つのロード・バランサ(または少なくとも個別のリスナー)を使用することをお薦めします。このようなトポロジでは、一方のロード・バランサまたはリスナーを外部HTTPトラフィック用に設定し、もう一方のロード・バランサを内部トラフィック用に設定します。いずれの場合も、セカンダリのロード・バランサはプライマリのロード・バランサのレプリカである必要があり、フォルト・トレラント・モードで構成することを強くお薦めします(詳細は、ロード・バランサのベンダーにお問い合せください)。
ロード・バランサに定義された一部の仮想サーバーは、コンポーネント間の通信に使用されます。これらの仮想サーバーは内部トラフィック用に使用され、企業の内部DNSに定義されます。単一のグローバルDNSサーバーを使用してホスト名を解決する場合、これらの仮想サーバーの別名を作成することをお薦めします。個別のDNSサーバーを使用してホスト名を解決する場合は、別名を作成する必要はありません。
各種Oracle Fusion Middleware製品に必要な仮想サーバーについては、各製品に関連するEDGで説明されています。
ノート:
ハードウェア・ロード・バランサは、各サイトのフロントエンドとして機能することを前提とします。サポートされているロード・バランサの詳細は、My Oracle Supportを参照してください。セカンダリ・サイトでのファイル・システムの準備
ファイル・システム、ディレクトリおよびボリューム
セカンダリ・ノードのストレージが、プライマリ・システムで使用されているストレージをレプリケートする場合のEDGの推奨事項に従って構成されているかどうかを確認します。EDGには、エンタープライズ・トポロジ用に作成する必要があるストレージ・ボリュームおよびマウント・ポイントに関する具体的な詳細が記載されています。プライマリで使用されているものと同じボリュームおよびマウント・ポイントをセカンダリで構成する必要があります。これを行わないと、セカンダリでシステムの構成をさらに操作する必要が生じます。その結果、管理のオーバーヘッドが増加し、ディザスタ・リカバリ・ソリューションのRTOも長くなります。プライマリと同じ構造を完全に反映したプライベート・ディレクトリおよび共有ディレクトリをセカンダリに作成してください。
セカンダリ・システムの設定
ネットワーク(ホスト名解決)、ストレージおよびデータベース接続のレベルで、これまでの項の情報に基づいてプライマリ・システムとセカンダリ・システムを準備した後、セカンダリ・システムを設定するには、次のステップを実行する必要があります。
Fusion Middlewareデータベース用のOracle Data Guardの構成
ディザスタ・リカバリ・ソリューションを計画する場合は、システムのデータベースをOracle Data Guardと同期させる必要があります。これは、Fusion Middlewareシステムに推奨される唯一の最大可用性アプローチです。
この項では、Oracle Fusion Middlewareディザスタ・リカバリ・トポロジで使用するOracle Databaseの設定に関する推奨事項と考慮事項を説明します。
-
エンタープライズ・デプロイメント・ガイドの説明に従って、本番サイトとセカンダリ・サイトの両方にOracle Real Application Cluster (Oracle RAC)データベースを作成することをお薦めします。
-
Oracle Data Guardは、Fusion Middleware永続ストアおよびFusion Middlewareメタデータ・リポジトリを実行しているデータベースに推奨される障害保護テクノロジです。
-
同期REDO転送によってレスポンス時間やスループットに影響が生じる可能性があるため、必ず十分な帯域幅を備えた低レイテンシのネットワークを構成してください。
-
Oracle Data Guardには、最大可用性、最大パフォーマンス(デフォルト)および最大保護という3つの保護モードが用意されています。可用性、パフォーマンスおよびデータ保護の要件を満たす保護モードを使用することをお薦めします。詳細は、Oracle Data Guard管理ドキュメントのOracle Data Guardの保護モードに関する項を参照してください。
-
通常の操作中は、セカンダリ・サイトのデータベースを管理リカバリ・モードにする必要があります。これにより、セカンダリ・サイトのデータベースは常にメディア・リカバリの状態になります。管理リカバリ・モードを使用すると、フェイルオーバー時間を短縮できます。
-
本番サイトとセカンダリ・サイトのデータベース・ノード上の
tnsnames.oraファイルには、本番サイトとセカンダリ・サイトの両方にあるデータベースのエントリが必要です。ノート:
これは、中間層の
tnsnames.oraファイルには当てはまりません。 -
Oracleデータベース・ファイルのボリューム・マネージャとしてAutomatic Storage Management (ASM)を使用することをお薦めします。ASMは、オラクル推奨のストレージ管理ソリューションであり、従来のボリューム・マネージャ、ファイル・システムおよびRAWデバイスに代わるものです。シングル・インスタンスのOracle Database構成とOracle Real Application Clusters (Oracle RAC)構成をサポートします。
Automatic Storage Management (ASM)およびReal Application Clusters (RAC)の詳細は、『Oracle Automatic Storage Management』および『Real Application Clustersインストレーション・ガイドfor Linux and UNIX』を参照してください。
-
プライマリのアプリケーションで使用される
SERVICE_NAMEは、セカンダリ・データベースでも同じである必要があります。ただし、各データベースにその他の目的で追加のサービスを定義できます。たとえば、セカンダリに特定の読取り専用サービスを作成して、レポート操作やビジネス・インテリジェンス操作をセカンダリ・サイトにオフロードできます。
前提条件
次の前提条件が満たされていることを確認してください。
-
セカンダリ・サイトのOracle RACクラスタおよびAutomatic Storage Management (ASM)インスタンスが作成済です。
-
セカンダリ・サイトおよび本番サイトのOracle RACデータベースでフラッシュ・リカバリ領域を使用しています。
-
Oracle RACデータベースが
archivelogモードで実行されています。 -
セカンダリ・サイトのデータベース・ホストにOracleソフトウェアがすでにインストールされています。
-
共有
ORACLE_HOME構成では、TNS_ADMINディレクトリはローカルの非共有ディレクトリである必要があります。
Oracle Data Guard環境の説明
この項で示す例には、表2-13で説明する環境変数が含まれています。
表2-13 プライマリおよびスタンバイ・データベースで使用される変数
| 変数 | プライマリ・データベース | スタンバイ・データベース |
|---|---|---|
|
データベース名 |
|
|
|
SOAデータベースのホスト名 |
|
|
| SCANアドレス |
|
|
|
データベースの一意の名前 |
|
|
|
インスタンス名 |
|
|
|
サービス名 |
|
|
Data Guardの構成手順
Data Guardの構成には、いくつかのステップがあります: 推奨パラメータを使用してプライマリ・データベースを準備する、プライマリ環境とスタンバイ環境でTNS別名を準備する、プライマリ・データベースの複製としてフィジカル・スタンバイ・データベースを作成する、Data Guard Brokerを構成する、などです。次のいずれかの方法を使用して、これらのアクションのほとんどを自動化できます。
-
オラクルは、MAAリポジトリ(GitHub、dg_setup_scripts)で使用可能なサンプル・スクリプトのセットを提供しています。これらのスクリプトは、サービスからのリストア機能およびData Guard Brokerを使用して、既存のプライマリ・データベースのスタンバイ・データベースを設定するように設計されています。カスタマイズが可能です(OSユーザー名とOracleホームは構成可能な値です)。TDE暗号化の有無にかかわらずデータベースをサポートし、読取り専用Oracleホーム(ROOH)または通常のOracleホームを使用した環境で動作します。スクリプトは、12c (12.2)、18c、19c、21cおよび23aiのRDBMSバージョンで検証済です。ファイルをダウンロードし、
README.mdに記載されている手順に従って、スタンバイ・データベースを構成します。 -
プライマリ・データベースとスタンバイ・データベースの両方がOracle Cloud Infrastructureにある場合は、OCIコンソールでData Guard構成オプションを使用します。これにより、設定操作における複雑さの大半が解消されます。詳細は、『Oracle Base Database Service』のDBシステムでのOracle Data Guardの有効化に関する項を参照してください。
-
Enterprise Manager Cloud Controlを使用します。Cloud Controlを使用したデータベースの設定および管理は、停止時間の制御およびディザスタ・リカバリ操作の簡略化に役立ちます。詳細は、『Oracle Enterprise Managerライフサイクル・マネージメント管理者ガイド』のOracleスタンバイ・データベースのプロビジョニングに関する項を参照してください。
-
前述の方法のいずれも特定の環境で実行できない場合は、次のいずれかのドキュメントに従ってData Guardを手動で構成できます。
Data Guard Broker構成の検証
次のステップを実行して、Data Guard Broker構成が正常に作成されたことを確認します。
例2-11 Data Guard Broker構成の検証
[oracle@dbhost1 ~]$ dgmgrl sys/'<password>' DGMGRL for Linux: Release 19.0.0.0.0 - Production on Tue Feb 1 09:00:16 2022 Version 19.6.0.0.0 Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved. Welcome to DGMGRL, type "help" for information. Connected to "soa_pri" Connected as SYSDBA. DGMGRL> show configuration Configuration - dg_config Protection Mode: MaxPerformance Databases: soa_pri - Primary database soa_stby - Physical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS
データベースのスイッチオーバーおよびスイッチバックのテスト
Oracle Data Guard Brokerを使用したスイッチオーバー操作の実行
Oracle Data Guard Brokerを使用してスイッチオーバー操作を実行するには、次のタスクを完了します。
-
次のコマンドを実行して、Oracle Data Guard Broker構成を確認します:
DGMGRL> show configuration; Configuration - dg_config Protection Mode: MaxPerformance Databases: soa_pri - Primary database soa_stby - Physical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS
-
SWITCHOVERコマンドを実行して、プライマリおよびスタンバイ・データベースのロールをスワップします。例2-11に、Data Guard Brokerが、古いプライマリ・データベースの停止および再起動を、スイッチオーバー操作の一部として自動的に実行する方法を示します。DGMGRL> switchover to 'soa_stby' Performing switchover NOW, please wait... Operation requires a connection to database "soa_stby" Connecting ... Connected to "soa_stby" Connected as SYSDBA. New primary database "soa_stby" is opening... Oracle Clusterware is restarting database "soa_pri" ... Connected to "soa_pri" Connected to "soa_pri" Switchover succeeded, new primary is "soa_stby"
-
スイッチオーバーの完了後、
SHOW CONFIGURATIONコマンドを使用して、スイッチオーバー操作が正常終了したかどうかを検証します。DGMGRL> show configuration; Configuration - dg_config Protection Mode: MaxPerformance Databases: soa_stby - Primary database soa_pri - Physical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS
ノート:
Oracle Data Guard Brokerのスイッチオーバーおよびフェイルオーバー操作の詳細は、『Oracle Data Guard Broker』のスイッチオーバーおよびフェイルオーバー操作に関する項を参照してください。
セカンダリ・サイトへのプライマリ・ファイル・システムのレプリケート
ストレージ・レプリケーション方式
ストレージ・レプリケーション・プロセスを使用してセカンダリにあるプライマリのコピーを取得するには、プライマリ・ボリュームから作成されたスナップショットをアクティブ化する必要があります。スナップショットをクローニングしてアクティブ化して、セカンダリ・ノードでマウントできるようにする、複数ステップのプロセスを提供しているベンダーもあります。関連するシェアまたはボリュームをアクティブ化して、セカンダリ・ノードにアタッチおよびマウントするには、ストレージ・ベンダーの正確な詳細を参照してください。セカンダリ内の各ノードが、プライマリのピアとまったく同じパスを使用して、まったく同じボリュームをマウントする必要があります。
rsyncレプリケーション方式
ピアツーピア・モデルでは、各セカンダリ・ノードでrsyncスクリプトを実行して、プライマリの各ピアからコンテンツをプルする必要があります。ステージrsyncアプローチでは、必要に応じて、ステージング場所から個々の各ノードに転送するスクリプトを実行し、Oracleホーム、WebLogicドメイン構成およびランタイム・アーティファクトのコピーを取得する必要があります。また、たとえばGitHubにあるスクリプトを使用すると、ピアツーピアでもステージング場所を使用する方法でも、セカンダリ・システムにレプリケートできます。
スクリプトrsync_for_WLS.shは、rsync_copy_and_validate.shを呼び出すラッパーです。この2番目のスクリプトは、推奨されるrsync構成でrsyncコピーを実行するための実際のロジックを含んでおり、コピーの完了後にファイルの徹底的な検証を実行します。検証を複数回再試行した後に差異が検出された場合、差異に対処できるようにログに記録されます。
デフォルトでは、rsync_copy_and_validate.shはユーザーとしてoracleを使用してコピーを実行します。別のユーザーがオリジン・フォルダを所有している場合は、スクリプト内のプロパティUSERをカスタマイズしてください。
また、環境変数DEST_FOLDERを使用して、コンテンツのrsyncに使用されるターゲットの場所を決定します。変数が設定されていない場合、スクリプトを実行しているノードの、ソース・ノードで使用されているものとまったく同じディレクトリ・パスにコンテンツをコピーします。ステージング方式を使用する際には、変数を(WLSノードの最初のプライベート構成などの)目的のパス/staging_share_storage/midtier/wls_private_config/wlsnode1_private_configに設定します。
ピアツーピアの使用
セカンダリ・サイトのホストごとに、次のディレクトリとファイルを各プライマリ・ピアの同じディレクトリとファイルにコピーするようにrsyncを設定します。
-
Oracleホームのディレクトリとサブディレクトリ。
-
Oracle中央インベントリ・ディレクトリ(Oracle Fusion Middlewareインストール用のOracle Universal Installerエントリを含む)。
-
WebLogic管理サーバーのドメイン・ディレクトリ、デプロイメント・プラン、アプリケーション、キーストアなどの共有構成フォルダ。このフォルダはEDG内のすべての中間層ホストで共有されるため、ホストごとにコピーを用意する必要はありません。共有WebLogicドメイン・ディレクトリのみをレプリケートしないでください。EDGのコンテキストでは、WebLogicドメイン構成とともにコピーする必要のある依存関係が
/u01/oracle/config/applicationsおよび/u01/oracle/config/keystoresディレクトリに存在します。 -
WebLogic管理対象サーバーのドメイン、ホスト上のローカル・ノード・マネージャ・ホームなどのプライベート構成フォルダ。
-
共有ランタイム・フォルダ(該当する場合)。
-
ホスト上のOracle HTTP Serverインストール用のOracle Fusion Middlewareの静的HTMLページ・ディレクトリ(該当する場合)。
-
まず、プライマリ管理サーバー・ノード全体をレプリケートします。次のように、製品フォルダ、共有構成フォルダおよびプライベート・ドメイン構成フォルダに対してスクリプトを実行します(共有構成のみのドメイン・ディレクトリはレプリケートしないでください)。このマニュアルに示す例を使用すると、172.11.2.113がプライマリのWLS管理サーバーのIP、172.22.2.113がセカンダリのWLS管理サーバーのIPになります。
[oracle@172.22.2.113]$./rsync_for_WLS.sh 172.11.2.113 /u01/oracle/products /home/oracle/keys/SSH_KEY.priv [oracle@172.22.2.113]$./rsync_for_WLS.sh 172.11.2.113 /u01/oracle/config /home/oracle/keys/SSH_KEY.priv [oracle@172.22.2.113]$./rsync_for_WLS.sh 172.11.2.113 /u02/oracle/config /home/oracle/keys/SSH_KEY.priv -
2番目のWLSサーバー・ノードをレプリケートします。次のように、製品フォルダとプライベート・ドメイン構成フォルダに対してスクリプトを実行します。このマニュアルに示す例を使用すると、172.11.2.114がプライマリのWLSサーバー・ノード2のIP、172.22.2.114がセカンダリのWLSサーバー・ノード2のIPになります。
[oracle@172.22.2.114]$./rsync_for_WLS.sh 172.11.2.114 /u01/oracle/products /home/oracle/keys/SSH_KEY.priv [oracle@172.22.2.114]$./rsync_for_WLS.sh 172.11.2.114 /u02/oracle/config /home/oracle/keys/SSH_KEY.priv -
2つのOHSノードをレプリケートします。OHSインスタンスはスタンドアロン・モードで実行されるため、共有構成フォルダはなく、プライベート・ドメイン構成のみをレプリケートする必要があります。このマニュアルに示す例を使用すると、172.11.2.111がプライマリのOHSサーバー・ノード1のIP、172.22.2.111がセカンダリのOHSサーバー・ノード1のIPになります。
[oracle@172.22.2.111]$./rsync_for_WLS.sh 172.11.2.111 /u02/oracle/products /home/oracle/keys/SSH_KEY.priv [oracle@172.22.2.111]$./rsync_for_WLS.sh 172.11.2.111 /u02/oracle/config /home/oracle/keys/SSH_KEY.priv
以上を実行すると、プライマリのOHSノードとWLSノードすべての完全なコピーがセカンダリの各ピア・ノードに作成されます。
ステージング場所の使用
-
プライマリのステージング場所からセカンダリのステージング場所にコピーする場合、
DEST_FOLDER環境変数を設定する必要はなく、プライマリのステージング場所にある同じパスをセカンダリのステージング場所にレプリケートする必要があります。次に例を示します。[oracle@staging_node_secondary]$./rsync_for_WLS.sh staging_node_primary_ip /staging_share_storage/midtier/wls_products_home/wls_products_home1 /home/oracle/keys/SSH_KEY.priv
セカンダリのステージング場所にコピーが作成されたら、セカンダリ・ノードから情報をプルする必要があります。次に例を示します(このマニュアルに示す例を使用すると、172.22.2.113がセカンダリのWLS管理サーバーのIPになります)。
[oracle@172.22.2.113]$ export DEST_FOLDER=/u01/oracle/products [oracle@172.22.2.113]$./rsync_for_WLS.sh staging_node_secondary_ip /staging_share_storage/midtier/wls_products_home/wls_products_home1 /home/oracle/keys/SSH_KEY.priv
-
単一のステージング場所からセカンダリ・ノードに直接コピーする場合は、単一のステージング場所から直接情報をプルする必要があります。次に例を示します(このマニュアルに示す例を使用すると、172.22.2.113がセカンダリのWLS管理サーバーのIPになります)。
[oracle@172.22.2.113]$ export DEST_FOLDER=/u01/oracle/products [oracle@172.22.2.113]$./rsync_for_WLS.sh staging_node_ip /staging_share_storage/midtier/wls_products_home/wls_products_home1 /home/oracle/keys/SSH_KEY.priv
DBFSレプリケーション方式
セカンダリ・システムは、関連するDBFSディレクトリにマウント可能なプライマリからコピーを受け取る必要があります。セカンダリにマウントするには、「DBFS用のプライマリ・ストレージの準備」で説明されているのと同じスクリプトおよびステップを使用します。セカンダリの中間層ホストでdbfs_dr_setup_root.shを実行する例を次に示します。セカンダリのデータベース・サービスの値を指定する必要があります。
./dbfs_dr_setup_root.sh drdbb-scan.wlsdrvcnfra1ad2.wlsdrvcnfra1.oraclevcn.com 1521 PDB1.wlsdrvcnfra1ad2.wlsdrvcnfra1.oraclevcn.com mypassword /u01/install/V982064-01.zip
セカンダリのDBFSマウントが使用可能になったら、プライマリ・ピアで使用可能なディレクトリ構造およびコンテンツをレプリケートすることで、各中間層ノードにコンテンツをレプリケートします。
ローカル・データベースでのセカンダリ・サイトの接続文字列の構成
tnsnames.oraをプライマリからレプリケートしたか、(関連するデータベース・クライアント・モジュールをレプリケートされたストレージ・マウントの外部に配置するか、rsyncのコピーからファイルを明示的に除外することで)コピーから除外したかに関係なく、セカンダリ・データベースのみを指すようにセカンダリの場所の接続文字列を更新する必要があります。リモート障害保護トポロジでは、(デュアル接続文字列を使用したり、様々なデータ・ソースで直接長い接続文字列を置換したりするかわりに) WebLogicデータ・ソースをローカル・データベース・アドレスのみで構成することをお薦めします。セカンダリのtnsnames.oraファイルをサービスで更新し、セカンダリ・データベースで使用されているアドレスをスキャンします。この構成では、WebLogicデータ・ソース内のJDBC URL情報はプライマリとセカンダリで同一のまま(jdbc:oracle:thin:@soaedg)ですが、プライマリのtnsnames.oraファイルには次のデータが含まれています。
SOAEDG =
(DESCRIPTION=
(ADDRESS_LIST=
(LOAD_BALANCE=ON)
(ADDRESS=(PROTOCOL=TCP)(HOST=prmy-scan)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME=soaedg.example.com))
)セカンダリのtnsnames.oraファイルを次のデータで更新する必要があります。
SOAEDG =
(DESCRIPTION=
(ADDRESS_LIST=
(LOAD_BALANCE=ON)
(ADDRESS=(PROTOCOL=TCP)(HOST=stby-scan)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME=soaedg.example.com))
)この例では、サービスはプライマリとセカンダリで同一のままですが、各ケースの接続ニーズによっては異なる場合もあります。通常、これらの更新は初期設定で一度だけ行う必要があります。プライマリ・システムで追加のサービスおよびデータベースを使用する場合にのみ、セカンダリで追加の別名を置換する必要があります。