1. ディザスタ・リカバリ・ガイド
  2. 設計上の考慮事項

2 設計上の考慮事項

エンタープライズ・デプロイメントにOracle Fusion Middleware障害時リカバリ・ソリューションを適合させる場合に留意する設計上の考慮事項について学習します

この章では、LinuxおよびUNIXオペレーティング・システムでOracle Fusion Middleware障害時リカバリの本番サイトとスタンバイ・サイトを設定する方法に関する手順を説明します。エンタープライズ・デプロイメントのOracle Fusion Middleware障害時リカバリ・ソリューションを設定する方法の例では、Oracle SOA Suiteエンタープライズ・デプロイメント(図2-1を参照)を使用します。Oracle SOA Suiteエンタープライズ・トポロジの障害時リカバリを設定する方法を理解したら、この情報を使用して他のエンタープライズ・デプロイメントの障害時リカバリも設定します。

ノート:

図2-1に、本番サイトとスタンバイ・サイトの両方でOracle SOA Suiteエンタープライズ・デプロイメントを使用するOracle Fusion Middleware障害時リカバリのトポロジを示します。これは、一方のサイトのみのデプロイメントを示しています。この図では、デプロイメントの詳細をわかりやすくするために、両方のサイトのデプロイメントを1つの図に示していません。

図1-1に、Oracle Fusion Middleware障害時リカバリの本番サイトおよびスタンバイ・サイトを示しています。

図2-1 Oracle Fusion Middleware障害時リカバリの本番サイトとスタンバイ・サイトで使用するデプロイメント

この画像は、Oracle SOA SuiteおよびOracle Business Activity Monitoringのエンタープライズ・デプロイメントを示しています。

図2-1は、Oracle SOA、Business Process Management (BPM)およびOracle Service Busエンタープライズ・デプロイメント・トポロジのダイアグラムを示しています。Oracle SOA Suiteエンタープライズ・デプロイメントのインストールおよび構成の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』を参照してください。

設計するOracle Fusion Middleware障害時リカバリ・トポロジは、本番サイトとスタンバイ・サイトで次の点について対称である必要があります。

  • ディレクトリ名およびパス

    本番サイトのホストに存在するすべてのファイルが、スタンバイ・サイトのピア・ホストの同一ディレクトリ・パスに存在する必要があります。

    つまり、Oracleホームの名前とディレクトリ・パスが本番サイトとスタンバイ・サイトで同じである必要があります。

  • ポート番号

    ポート番号は、リスナーによってリクエストのルーティングに使用されます。ポート番号は構成に保存され、本番サイトのホストとスタンバイ・サイトのピア・ホストで同じである必要があります。

  • セキュリティ

    本番サイトとスタンバイ・サイトの両方に同じユーザー・アカウントが必要です。また、本番サイトとスタンバイ・サイトで、ファイル・システム、SSLおよびシングル・サインオンを同様に構成する必要があります。たとえば、本番サイトでSSLを使用している場合、スタンバイ・サイトでも、本番サイトとまったく同様に構成したSSLを使用する必要があります。

  • ロード・バランサと仮想サーバー名

    本番サイトについては、仮想サーバー名を使用してフロントエンド・ロード・バランサを設定する必要があります。スタンバイ・サイトについては、同じ仮想サーバー名を使用して同一のフロントエンド・ロード・バランサを設定する必要があります。

  • ソフトウェア

    本番サイトとスタンバイ・サイトで同じバージョンのソフトウェアを使用する必要があります。また、両方のサイトでオペレーティング・システムのパッチ・レベルが同じである必要があります。さらに、本番サイトとスタンバイ・サイトの両方にOracleまたはサード・パーティ・ソフトウェアのパッチを適用する必要があります。

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

  • ネットワークに関する考慮事項
    障害時リカバリ・ソリューションを計画する場合、ホスト名、ロード・バランスおよび外部クライアントを考慮します。
  • ストレージに関する考慮事項
    障害時リカバリ・ソリューション用のストレージを設計する場合、Fusion Middlewareのアーティファクトおよびストレージ・レプリケーションを考慮します。
  • データベースに関する考慮事項
    障害時リカバリ・ソリューションを計画する場合、Oracle Data Guardでシステムのデータベースを同期化することを検討します。
  • 開始ポイント
    障害時リカバリ・ソリューションを計画する場合、既存のサイトを基にすることも、新しいサイトを作成することもできます。
  • トポロジに関する考慮事項
    障害時リカバリ・ソリューションを計画する場合、対称トポロジまたは非対称トポロジを検討します。

ネットワークに関する考慮事項

障害時リカバリ・ソリューションを計画する場合、ホスト名、ロード・バランスおよび外部クライアントを考慮します。

この項には次のトピックが含まれます:

  • ホスト名の計画
    障害時リカバリ・トポロジでは、FMWコンポーネントで使用されるホスト名アドレスは、各サイトの適切なシステムのIPアドレスに解決可能である必要があります。本番サイトでは、これらのアドレスを本番ホストのIPに解決する必要があり、スタンバイ・サイトでは、これらのアドレスをスタンバイ・サイト・ホストのIPに解決する必要があります。
  • 仮想IPに関する考慮事項
    Oracle SOA Suite 12c以降、SOA Suite製品は自動サービス移行をサポートしています。その結果、ドメイン内の管理対象サーバーごとに仮想IPを予約する必要はなくなりました。仮想IPが必要なのは管理サーバーのみになりました。
  • ロード・バランサに関する考慮事項
    障害時リカバリ・トポロジでは、本番システムとDRシステムの両方に、同等の構成を持つハードウェア・ロード・バランサが必要です。各ロード・バランサは、ローカル・サイトのサーバー間のトラフィックのバランスを取ります。
  • 仮想サーバーに関する考慮事項
    様々な種類のネットワーク・トラフィックや監視に対応するように、仮想サーバーや関連するポートをロード・バランサに構成する必要があります。
  • 外部クライアントの考慮事項
    トポロジでサーバーに直接アクセスするシステムは、別のOracle WebLogic Serverインスタンスで使用されるリスニング・アドレスを認識している必要があります。
  • ワイド・エリアDNSの操作
    サイトのスイッチオーバーまたはフェイルオーバーを実行した場合、クライアント・リクエストは本番ロールを引き継ぐ新しいサイトに透過的にリダイレクトされる必要があります。

親トピック: 設計上の考慮事項

ホスト名の計画

障害時リカバリ・トポロジでは、FMWコンポーネントで使用されるホスト名アドレスは、各サイトの適切なシステムのIPアドレスに解決可能である必要があります。本番サイトでは、これらのアドレスを本番ホストのIPに解決する必要があり、スタンバイ・サイトでは、これらのアドレスをスタンバイ・サイト・ホストのIPに解決する必要があります。

実際の物理ホスト名(サイトごとに異なる)をFMWコンポーネントで使用されるホスト名(サイトに関係なく同じ)から分離するために、物理ホスト名に別名を作成することをお薦めします。プライマリ・サイトからスタンバイ・サイトへのフェイルオーバー後に、スタンバイ・サイトの中間層ホストのホスト名別名がアクティブになります。スタンバイ・サイトの別名を設定する場合、スタンバイ・サイトのホストのホスト名を再構成する必要はありません。

この項では、本番サイトとスタンバイ・サイトでOracle Fusion Middlewareインスタンスを使用する中間層ホストについて、物理ホスト名およびホスト名別名を計画する方法を説明します。ホスト名の例として、図2-1に示されているOracle SOA Suiteエンタープライズ・デプロイメントを使用します。この項に記載されているホスト名の例は、障害時リカバリの対称サイトを設定することを前提としています(つまり、本番サイトとスタンバイ・サイトのホスト数は同じです)。本番サイトとスタンバイ・サイトの各ホストに他方のサイトのピア・ホストがあります。ピア・ホストは、他方のサイトの対応するホストと同じポートを使用するなど、同様に構成されます。

各コンポーネントを構成する際には、IPベースの構成ではなく、ホスト名ベースの構成を使用します。たとえば、Oracle Fusion Middlewareコンポーネントのリスニング・アドレスを特定のIPアドレス(172.11.2.113など)に構成する場合は、172.11.2.113に解決されるホスト名SOAHOST1.EXAMPLE.COMを使用します。

次の項では、障害時リカバリの本番サイトとスタンバイ・サイトでホスト名を設定する方法を説明します。

ノート:

示されている例では、最初の本番サイトのホストのIPアドレスは172.11.x.xという形式で、最初のスタンバイ・サイトのホストのIPアドレスは172.22.x.xという形式です。

親トピック: ネットワークに関する考慮点

Oracle SOA Suiteの本番サイト・ホストおよびスタンバイ・サイト・ホストのホスト名

Oracle SOA Suiteの本番サイトおよびスタンバイ・サイトについて学習します。

表2-1に、『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』(EDG)のデプロイメントの本番サイト・ホストに使用するIPアドレス、物理ホスト名および別名を示します。本番サイトにおけるOracle SOA Suite EDGデプロイメントの構成については、図2-1を参照してください。

表2-1 SOA Suiteの本番サイト・ホストのIPアドレスと物理ホスト名

IPアドレス 物理ホスト名 ホスト名別名

172.11.2.111

prweb1.example.com

WEBHOST1

172.11.2.112

prweb2.example.com

WEBHOST2

172.11.2.113

prsoa1.example.com

SOAHOST1

172.11.2.114

prsoa2.example.com

SOAHOST2

表2-2に、『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』(EDG)のデプロイメントのスタンバイ・サイト・ホストに使用するIPアドレス、物理ホスト名および別名を示します。

表2-2 SOA Suiteのスタンバイ・サイト・ホストのIPアドレスおよび物理ホスト名

IPアドレス 物理ホスト名 ホスト名別名

172.22.2.111

stbyweb1.example.com

WEBHOST1

172.22.2.112

stbyweb2.example.com

WEBHOST2

172.22.2.113

stbysoa1.example.com

SOAHOST1

172.22.2.114

stbysoa2.example.com

SOAHOST2

ノート:

個別のDNSサーバーを使用してホスト名を解決する場合、本番サイトのホストとスタンバイ・サイトのホストに同じ物理ホスト名を使用できるので、ホスト名別名をスタンバイ・サイトのホストで定義する必要はありません。個別のDNSサーバーを使用してホスト名を解決する方法の詳細は、 「個別のDNSサーバーを使用したホスト名の解決」を参照してください。

ただし、実際の物理ホスト名(サイトごとに異なる)をFMWコンポーネントで使用されるホスト名(サイトに関係なく同じ)から分離するために、異なるホスト名と同じ別名を使用することをお薦めします。

図2-2に、スタンバイ・サイトでOracle SOA Suite EDGデプロイメントに使用する物理ホスト名を示します。

図2-2 Oracle SOA Suiteデプロイメントのスタンバイ・サイトで使用する物理ホスト名

この画像は、Oracle SOA Suiteデプロイメントのスタンバイ・サイトで使用される物理ホスト名を示しています。

Fusion Middlewareバージョン12c以降では、サーバー移行に代わる優れたフェイルオーバーとして、EDG環境で自動サービス移行が使用されます。サーバー移行とは異なり、サービス移行では、管理対象サーバーが仮想IPを使用する必要はありません。したがって、各サイトに浮動IPアドレスをプロビジョニングする必要があるのは、管理サーバーのみです。表2-3を参照してください。

浮動IPアドレスは、本番サイトとスタンバイ・サイトの両方で、同じ仮想ホスト名でプロビジョニングしてください。

表2-3 浮動IPアドレス

仮想IP 仮想名 ホスト名別名

172.11.2.134

prsoa-vip.example.com

(本番サイト)

ADMINVHN

172.22.2.134

stbysoa-vip.example.com

(スタンバイ・サイト)

ADMINVHN

次の各トピックで、ホスト名およびテストについて説明します。

親トピック: ホスト名の計画

ホスト名の解決

ホスト名の解決とは、通信のためにホスト名を適切なIPアドレスにマップするということです。

ホスト名の解決は、次のいずれかの方法で構成できます。

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のマッピングが使用されます。

障害時リカバリ・トポロジでこの方法を使用してホスト名を解決する場合、次の手順を考慮します。

  1. 本番サイトとスタンバイ・サイトのすべてのホストで/etc/nsswitch.confファイルのhostsパラメータが次のようになっていることを確認します。
    hosts:   files   dns   nis
  2. 本番サイトのホストの/etc/hostsファイル・エントリで、物理ホスト名がIPアドレスにマップされているとともに、ホスト名別名がFMWコンポーネントで使用されている必要があります。保守を簡潔かつ容易にするために、本番サイトのすべてのホストで同じエントリを提供することをお薦めします。例2-3に、SOAエンタープライズ・デプロイメント・トポロジの本番サイトの/etc/hostsファイルを示します。
  3. スタンバイ・サイトのホストの/etc/hostsファイル・エントリで、物理ホスト名がIPアドレスにマップされているとともに、本番サイトの対応するピアのホスト名別名がホスト名別名として定義されている必要があります。保守を簡潔かつ容易にするために、スタンバイ・サイトのすべてのホストで同じエントリを使用することをお薦めします。例2-4に、SOAエンタープライズ・デプロイメント・トポロジのスタンバイ・サイトの/etc/hostsファイルを示します。
  4. /etc/hostファイル・エントリを使用してホスト名解決を設定したら、pingコマンドを使用してホスト名解決をテストします。例2-3に示されている静的IPアドレス指定と/etc/hostsファイル・エントリを使用して構成したシステムの場合、本番サイトでping webhost1コマンドを実行すると、適切なIPアドレス(172.11.2.111)が返され、ホスト名が完全修飾されていることがわかります。
  5. 同様に、例2-4に示されている静的IPアドレス指定と/etc/hostsファイル・エントリを使用して構成したシステムの場合、スタンバイ・サイトでping webhost1コマンドを実行すると、適切なIPアドレス(172.22.2.111)が返され、WEBHOST1という名前がその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サーバー」という用語は、本番サイトとスタンバイ・サイトに別のDNSサーバーがある障害時リカバリ・トポロジを表します。障害時リカバリ・トポロジで個別のDNSサーバーを使用してホスト名を解決する場合、次の手順を考慮します。

  1. 本番サイトとスタンバイ・サイトのすべてのホストで/etc/nsswitch.confファイルのhostsパラメータが次のようになっていることを確認します。
    hosts:   dns   files   nis
  2. 本番サイトとスタンバイ・サイトのDNSサーバーが相互を認識してはいけません。独自のサイト内で使用されるホスト名のエントリはそれぞれのDNSサーバーで構成されている必要があります。
  3. 本番サイトのDNSサーバーのエントリで、物理ホスト名がIPアドレスにマップされている必要があります。例2-5に、SOAエンタープライズ・デプロイメント・トポロジの本番サイトで使用するDNSサーバー・エントリを示します。
  4. スタンバイ・サイトのDNSサーバーのエントリで、物理ホスト名とホスト名別名がIPアドレスにマップされている必要があります。例2-6に、SOAエンタープライズ・デプロイメント・トポロジのスタンバイ・サイトで使用するDNSサーバー・エントリを示します。
  5. 本番サイトまたはスタンバイ・サイトのいずれのホストについても、/etc/hostsファイルにエントリがないことを確認します。
  6. pingコマンドを使用してホスト名解決のテストを行います。例2-5に示されている本番サイトのDNSエントリで構成したシステムの場合、本番サイトでping webhost1コマンドを実行すると、適切なIPアドレス(172.11.2.111)が返され、ホスト名が完全修飾されていることがわかります。
  7. 同様に、例2-6に示されているスタンバイ・サイトのDNSエントリで構成したシステムの場合、スタンバイ・サイトでping webhost1コマンドを実行すると、適切なIPアドレス(172.22.2.111)が返され、ホスト名が完全修飾されていることがわかります。

例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サーバーを使用したホスト名の解決

障害時リカバリ・トポロジでグローバルDNSサーバーを使用してホスト名を解決します。

「グローバルDNSサーバー」という用語は、本番サイトとスタンバイ・サイト両方に対して1つのDNSサーバーを使用する障害時リカバリ・トポロジを表します。障害時リカバリ・トポロジでグローバルDNSサーバーを使用してホスト名を解決する場合、次の手順を考慮します。

  1. グローバルDNSサーバーを使用する場合は、簡潔にするために、ローカルでのホスト名解決とDNSによるホスト名解決を組み合せて使用します。
  2. この例では、本番サイトでDNSによるホスト名解決を使用し、スタンバイ・サイトではローカルでのホスト名解決を使用することを前提とします。
  3. グローバルDNSサーバーに、本番サイトとスタンバイ・サイト両方のホストのエントリがある必要があります。例2-7に、SOAエンタープライズ・デプロイメント・トポロジのエントリを示します。
  4. 本番サイトのすべてのホストで/etc/nsswitch.confファイルのhostsパラメータが次のようになっていることを確認します。
    hosts:   dns   files   nis
  5. スタンバイ・サイトのすべてのホストで/etc/nsswitch.confファイルのhostsパラメータが次のようになっていることを確認します。
    hosts:   files   dns   nis
  6. スタンバイ・サイトのホストの/etc/hostsファイル・エントリで、物理ホスト名がIPアドレスにマップされているとともに、本番サイトの対応するピアの物理ホスト名がホスト名別名として定義されている必要があります。保守を簡潔かつ容易にするために、スタンバイ・サイトのすべてのホストで同じエントリを使用することをお薦めします。例2-9に、SOAエンタープライズ・デプロイメント・トポロジの本番サイトの/etc/hostsファイルを示します。
  7. pingコマンドを使用してホスト名解決のテストを行います。本番サイトでping webhost1コマンドを実行すると、適切なIPアドレス(172.11.2.111)が返され、ホスト名が完全修飾されていることがわかります。
  8. 同様に、スタンバイ・サイトでping webhost1コマンドを実行すると、適切なIPアドレス(172.22.2.111)が返され、ホスト名が完全修飾されていることがわかります。

例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
ホスト名解決のテスト

ホスト名の割当てを検証します。そのためには、本番サイトの各ホストに接続し、pingコマンドを使用して、ホストが本番サイトの他のホストを特定できることを確認します。

さらに、スタンバイ・サイトの各ホストに接続し、pingコマンドを使用して、ホストがスタンバイ・サイトの他のホストを特定できることを確認します。

仮想IPに関する考慮事項

Oracle SOA Suite 12c以降、SOA Suite製品は自動サービス移行をサポートするようになりました。その結果、ドメイン内の管理対象サーバーごとに仮想IPを予約する必要はなくなりました。仮想IPが必要なのは管理サーバーのみになりました。

障害時リカバリ・トポロジでは、前の項で説明したように、本番サイトの仮想IPホスト名別名がスタンバイ・サイトの対応するピア・システムのIPアドレスに解決可能である必要があります。そのため、本番サイトとスタンバイ・サイトのホスト名を計画することが重要です。プライマリ・サイトからスタンバイ・サイトへのフェイルオーバー後に、スタンバイ・サイトの中間層ホストのホスト名別名がアクティブになります。スタンバイ・サイトの別名を設定する場合、スタンバイ・サイトのホストのホスト名を再構成する必要はありません。

この項では、本番サイトとスタンバイ・サイトでOracle Fusion Middlewareインスタンスを使用する中間層ホストについて、仮想IPホスト名およびホスト名別名を計画する方法を説明します。これは、単一の企業DNSを使用している場合に必要です。

ホスト名の例として、図2-1に示されているOracle SOA Suiteエンタープライズ・デプロイメントを使用します。この項に記載されているホスト名の例は、障害時リカバリの対称サイトを設定することを前提としています(つまり、本番サイトとスタンバイ・サイトのホスト数は同じです)。本番サイトとスタンバイ・サイトの各ホストに他方のサイトのピア・ホストがあります。ピア・ホストは、他方のサイトの対応するホストと同じポートを使用するなど、同様に構成されます。

表2-4に、Oracle SOA Suite EDGデプロイメントの本番サイト・ホストに使用する仮想IPアドレスと仮想ホスト名を示します。本番サイトにおけるOracle SOA Suite EDGデプロイメントの構成については、図2-1を参照してください。

表2-4 SOA Suiteの本番サイト・ホストの仮想IPアドレスと仮想ホスト名

仮想IPアドレス 仮想ホスト名 ホスト名別名

172.11.2.134

prsoa-vip.example.com

ADMINVHN

表2-5に、Oracle SOA Suite EDGデプロイメントのスタンバイ・サイト・ホストに使用する仮想IPアドレス、仮想ホスト名およびホスト名別名を示します。図2-2に、スタンバイ・サイトでOracle SOA Suite EDGデプロイメントに使用する物理ホスト名を示します。図2-2に示されているOracle SOA Suiteのスタンバイ・サイト・ホストについては、表2-5に示されているホスト名別名を定義する必要があります。

ノート:

個別のDNSサーバーを使用してホスト名を解決する場合、本番サイトのホストとスタンバイ・サイトのホストに同じ仮想IPアドレスおよび仮想ホスト名を使用できるため、ホスト名別名を定義する必要はありません。

個別のDNSサーバーを使用してホスト名を解決する方法の詳細は、 「個別のDNSサーバーを使用したホスト名の解決」を参照してください。

表2-5 SOA Suiteのスタンバイ・サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名

仮想IPアドレス 仮想ホスト名 ホスト名別名

172.22.2.134

stbysoa-vip.example.com

ADMINVHN

親トピック: ネットワークに関する考慮点

ロード・バランサに関する考慮事項

障害時リカバリ・トポロジでは、本番システムとDRシステムの両方に、同等の構成を持つハードウェア・ロード・バランサが必要です。各ロード・バランサは、ローカル・サイトのサーバー間のトラフィックのバランスを取ります。

プライマリ・ロード・バランサとDRロード・バランサの両方が、外部ロード・バランサの必要な機能をサポートする必要があります。詳細は、『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』のハードウェア・ロード・バランサの要件に関する項を参照してください。

本番ロード・バランサとDRロード・バランサで使用される仮想フロントエンド名は同じである必要があります。その仮想フロントエンド名は、毎回プライマリ・ロールを持つサイトのロード・バランサのIPを使用してDNSで解決される必要があります。

親トピック: ネットワークに関する考慮点

仮想サーバーに関する考慮事項

様々な種類のネットワーク・トラフィックや監視に対応するように、仮想サーバーや関連するポートをロード・バランサに構成する必要があります。

実際のホストおよびポートに対して適切にこれらを構成し、サービスが継続されるようにします。また、ロード・バランサは、可用性を確保するために実際のホストおよびポートを監視するように構成し、サービスがダウンしたときにこれらのホストおよびポートへのトラフィックをできるだけ早く停止できるようにする必要があります。これによって、特定の仮想ホストの着信トラフィックが他の層の使用不可のサービスに送信されることがなくなります。

外部トラフィックと内部トラフィックを処理する場合は、ロード・バランサを2つ使用することをお薦めします。このようなトポロジでは、一方のロード・バランサを外部HTTPトラフィック用に設定し、もう一方のロード・バランサを内部LDAPトラフィック用に設定します。様々な理由から、デプロイメントで使用されるロード・バランサ・デバイスが1つになる場合があります。このような構成もサポートされていますが、これに伴うセキュリティへの影響を考慮する必要があります。その構成が適切であることがわかったら、様々なDMZ間のトラフィックを許可するように、関連するファイアウォール・ポートを開いてください。いずれの場合も、特定のロード・バランサ・デバイスをフォルト・トレラント・モードでデプロイすることを強くお薦めします。

ロード・バランサに定義された一部の仮想サーバーは、コンポーネント間の通信に使用されます。これらの仮想サーバーは内部トラフィック用に使用され、企業の内部DNSに定義されます。単一のグローバルDNSサーバーを使用してホスト名を解決する場合、これらの仮想サーバーの別名を作成することを強くお薦めします。個別のDNSサーバーを使用してホスト名を解決する場合は、別名を作成する必要はありません。

各種Oracle Fusion Middleware製品に必要な仮想サーバーを表2-6から表2-7に示します。

表2-6 Oracle SOA Suiteの本番サイトの仮想サーバー

コンポーネント アクセス 仮想サーバー名 別名

Oracle SOA

外部

soa.example.com

なし

Oracle SOA

内部

soainternal.example.com

なし

管理コンソール

内部

admin.example.com

なし

表2-7 Oracle SOA Suiteのスタンバイ・サイトの仮想サーバー

コンポーネント アクセス 仮想サーバー名 仮想サーバー名別名

Oracle SOA

外部

soa.example.com

なし

Oracle SOA

内部

stbysoainternal.example.com

soainternal.example.com

管理コンソール

内部

admin.example.com

なし

親トピック: ネットワークに関する考慮点

外部クライアントの考慮事項

トポロジでサーバーに直接アクセスするシステムは、別のOracle WebLogic Serverインスタンスで使用されるリスニング・アドレスを認識している必要があります。

サーバーでリスニング・アドレスとして使用されるホスト名別名が正しく解決されるように、適切なホスト名解決をクライアントに提供する必要があります。これは、Oracle JDeveloperデプロイメントにも適用されます。デプロイメントを成功させるには、Oracle Jdeveloperをホストしているクライアントが、SOAHOSTxおよびADMINVHN別名を適切なIPアドレスにマップする必要があります。

親トピック: ネットワークに関する考慮点

ワイド・エリアDNSの操作

サイトのスイッチオーバーまたはフェイルオーバーを実行した場合、クライアント・リクエストは本番ロールを引き継ぐ新しいサイトに透過的にリダイレクトされる必要があります。

本番サイトのエントリ・ポイントにクライアント・リクエストを送信するには、DNS解決を使用します。このリダイレクションを実現するには、本番サイトへのリクエストを解決するワイド・エリアDNSをスタンバイ・サイトにスイッチオーバーする必要があります。DNSスイッチオーバーを実行するには、グローバル・ロード・バランサを使用するか、DNS名を手動で変更します。

ノート:

ハードウェア・ロード・バランサは、各サイトのフロントエンドとして機能することを前提とします。サポートされているロード・バランサについては、次の場所を参照してください。

http://support.oracle.com

この項には次のトピックが含まれます:

  • グローバル・ロード・バランサの使用
    グローバル・ロード・バランサを本番サイトとスタンバイ・サイトの前面にデプロイすると、両方のサイトについて、障害検出サービスとパフォーマンスベースのルーティング・リダイレクションが提供されます。
  • DNS名の手動変更
    DNSスイッチオーバーでは、本番サイトのロード・バランサの名前とIPのマッピングを手動で変更します。

親トピック: ネットワークに関する考慮点

グローバル・ロード・バランサの使用

グローバル・ロード・バランサを本番サイトとスタンバイ・サイトの前面にデプロイすると、両方のサイトについて、障害検出サービスとパフォーマンスベースのルーティング・リダイレクションが提供されます。

さらに、このロード・バランサは、信頼できるDNSネーム・サーバーと同等の機能を提供できます。

通常の操作時には、本番サイトのロード・バランサの名前とIPのマッピングを使用してグローバル・ロード・バランサを構成できます。DNSスイッチオーバーが必要な場合は、グローバル・ロード・バランサのこのマッピングを変更して、スタンバイ・サイトのロード・バランサのIPにマップします。これにより、本番ロールを引き継いだスタンバイ・サイトにリクエストが送信されるようになります。

DNSスイッチオーバーを使用するこの方法は、サイトのスイッチオーバーおよびフェイルオーバーとして機能します。グローバル・ロード・バランサを使用する利点の1つは、名前とIPの新しいマッピングがほとんど即時に有効になる点です。マイナス面は、グローバル・ロード・バランサに対する追加投資が必要な点です。

DNS名の手動変更

DNSスイッチオーバーでは、本番サイトのロード・バランサの名前とIPのマッピングを手動で変更します。

マッピングはスタンバイ・サイトのロード・バランサのIPアドレスにマップするように変更します。スイッチオーバーを実行する手順は次のとおりです。

  1. 本番サイトのロード・バランサ・マッピングの現在の存続時間(TTL)値を書き留めます。このマッピングはDNSキャッシュ内にあり、TTLが経過するまでそこに保持されます。例として、TTLが3600秒であるとします。
  2. TTL値を短い間隔(60秒など)に変更します。
  3. 元のTTLの間隔が1回経過するまで待ちます。これは、ステップ1で書き留めた元のTTL値である3600秒です。
  4. スタンバイ・サイトがリクエストを受信するようにスイッチオーバーされていることを確認します。
  5. スタンバイ・サイトのロード・バランサを解決するようにDNSマッピングを変更します。通常の操作に適したTTL値(3600秒など)が提供されます。

DNSスイッチオーバーを使用するこの方法は、スイッチオーバー操作またはフェイルオーバー操作として機能します。ステップ2で設定するTTL値は、その時間内にクライアント・リクエストを十分に処理できないような値にする必要があります。TTLを変更する場合、実質的には、アドレス解決のキャッシュ・セマンティックを長い時間から短い時間に変更することになります。キャッシュ時間が短くなるため、DNSリクエストが増加する可能性があります。

SOAを指すクライアントがJavaを実行している場合、別のTTLプロパティを考慮に入れることができます。正常なDNS解決をキャッシュするように、JavaでDNSキャッシュを構成します。その場合、Javaが再起動されるまで、DNSサーバーの変更はリフレッシュされません。プロパティnetworkaddress.cache.ttlを低い値に設定することにより、これを変更できます。

  • JAVA_HOME/jre/lib/security/java.securityファイルのプロパティ(:networkaddress.cache.ttl=60)を変更することにより、JVMで実行しているすべてのアプリケーションに対してグローバルに行うことができます。

  • アプリケーションの初期化コードのプロパティ(java.security.Security.setProperty("networkaddress.cache.ttl" , "60"))を設定することにより、特定のアプリケーションに対してのみ定義できます。

ストレージに関する考慮事項

障害時リカバリ・ソリューション用のストレージを設計する場合、Fusion Middlewareのアーティファクトおよびストレージ・レプリケーションを考慮します。

この項には次のトピックが含まれます:

  • Oracle Fusion Middlewareのアーティファクト
    通常、特定の環境内のOracle Fusion Middlewareコンポーネントは相互に依存するため、トポロジ内のコンポーネントが同期されていることが重要です。
  • OracleホームとOracleインベントリ
    Oracle Fusion Middlewareでは、単一のバイナリ・ファイルのインストールから複数のOracle WebLogic Serverの管理対象サーバーを作成できます。
  • ストレージの設定
    共有ストレージでボリュームを作成するガイドラインについて学習します。

親トピック: 設計上の考慮事項

Oracle Fusion Middlewareのアーティファクト

通常、特定の環境内のOracle Fusion Middlewareコンポーネントは相互に依存するため、トポロジ内のコンポーネントが同期されていることが重要です。

ボリュームとコンシステンシー・グループを設計する際は、この同期化は重要です。アーティファクトの中には静的なものもあれば、動的なものもあります。

静的アーティファクト

静的アーティファクトは、頻繁には変更されないファイルやディレクトリです。これには次のものがあります。

  • ホーム: Oracleホームは通常、OracleホームとOracle WebLogic Serverホームで構成されます。

  • Oracleインベントリ: これには、/etcディレクトリにある、oraInst.locおよびoratabファイルが含まれます。

動的またはランタイム・アーティファクト

動的またはランタイム・アーティファクトは、頻繁に変更されるファイルです。ランタイム・アーティファクトには、次のものがあります。

  • ドメイン・ホーム: 管理サーバーおよび管理対象サーバーのドメイン・ディレクトリ。

  • Oracleインスタンス: Oracleインスタンスのホーム・ディレクトリ。

  • .earファイルや.warファイルなどのアプリケーション・アーティファクト。

  • MDSリポジトリやJDBC永続ストアなどのデータベース・アーティファクト。

  • デプロイメント・プラン: ファイル・アダプタやJMSアダプタなどのテクノロジ・アダプタの更新に使用されます。これらは、アーティファクトがデプロイされるクラスタ内のすべてのノードにアクセスできる場所に保存する必要があります。

親トピック: ストレージに関する考慮事項

OracleホームおよびOracleインベントリ

Oracle Fusion Middlewareでは、単一のバイナリ・ファイルのインストールから複数のOracle WebLogic Serverの管理対象サーバーを作成できます。

共有ストレージ上の単一の場所にバイナリ・ファイルをインストールし、異なるノード内にあるサーバーでこのインストールを再利用できます。最大限の可用性を確保するには、冗長バイナリ・インストールを使用することをお薦めします。

OracleホームまたはWebLogicホームが、異なるノードの複数のサーバーによって共有されている場合、これらのノードのOracleインベントリとOracleホーム・リストを常に最新の状態にして、インストールとパッチ・アプリケーションの整合性を確保することをお薦めします。

ノードでインベントリ・ファイルを更新して、これに共有ストレージのインストールを関連付けるには、ORACLE_HOME/oui/bin/attachHome.shファイルを使用します。

親トピック: ストレージに関する考慮事項

ストレージの設定

共有ストレージでボリュームを作成するガイドラインについて学習します。

ストレージ・デバイスで使用可能なストレージ・レプリケーション・テクノロジの機能によっては、層内の各ノードでマウント・ポイント、ディレクトリおよびシンボリック・リンクを作成する必要がある場合があります。

ストレージ・デバイスのストレージ・レプリケーション・テクノロジによって複数のボリューム間で一貫性のあるレプリケーションが保証される場合、次を完了します。

  • その層で実行されるサーバーごとにボリュームを1つずつ作成します。たとえば、アプリケーション層では、WebLogicの管理サーバー用にボリュームを1つと管理対象サーバー用に別のボリュームを作成できます。

  • 各層に対して、その層のボリュームをメンバーとするコンシステンシー・グループを1つ作成します。

  • 2つのシステムによってボリュームが同時にマウントされる場合、ストレージ・サブシステムによっては、クラスタ・ファイル・システムが必要になることがあります。ただし、異なるシステム上のOracleプロセスが1つのファイルまたはディレクトリ・ツリーに同時にアクセスするという既知のケースはありません。NFSはクラスタ・ファイル・システムなので、NFSで接続されたストレージを使用している場合、クラスタ・ファイル・システム・ソフトウェアを追加する必要はありません。

ストレージ・デバイスのストレージ・レプリケーション・テクノロジによって複数のボリューム間で一貫性のあるレプリケーションが保証される場合、次を完了します。

  • 各層にボリュームを1つずつ作成します。たとえば、アプリケーション層用のボリューム、Web層用のボリュームというように作成できます。

  • その層の各ノード用に別個のディレクトリを作成します。たとえば、アプリケーション層のボリュームの下にSOAHOST1用のディレクトリを作成し、Web層のボリュームの下にWEBHOST1用のディレクトリを作成できます。

  • ボリューム上のそのディレクトリに対するマウント・ポイント・ディレクトリを各ノードに作成します。

  • マウント・ポイント・ディレクトリへのシンボリック・リンクを作成します。これにより、層内のノード間で同じディレクトリ構造を使用できるようになります。

  • 2つのシステムによってボリュームが同時にマウントされる場合、ストレージ・サブシステムによっては、クラスタ・ファイル・システムが必要になることがあります。ただし、異なるシステム上のOracleプロセスが1つのファイルまたはディレクトリ・ツリーに同時にアクセスするという既知のケースはありません。NFSはクラスタ・ファイル・システムなので、NFSで接続されたストレージを使用している場合、クラスタ・ファイル・システム・ソフトウェアを追加する必要はありません。

ノート:

障害時リカバリ・サイトの共有ストレージを設定する前に、『Oracle Fusion Middlewareリリース・ノート』の高可用性に関する章を参照して、高可用性環境で共有ストレージをベースとしたデプロイメントに関する既知の問題を確認してください。

親トピック: ストレージに関する考慮事項

データベースに関する考慮事項

障害時リカバリ・ソリューションを計画している場合、Oracle Data Guardでシステムのデータベースを同期化することを検討します。

この項では、Oracle Fusion Middleware障害時リカバリ・トポロジで使用するOracle Databaseの設定に関する推奨事項と考慮事項を説明します。

  • 使用するトポロジの要件に応じて、本番サイトとスタンバイ・サイトの両方にOracle Real Application Cluster (Oracle RAC)データベースを作成することをお薦めします。

  • メタデータ・リポジトリを実行するデータベースについては、障害時保護テクノロジとしてOracle Data Guardをお薦めします。正確なOracle Fusion Middlewareコンポーネントでサポートされている場合は、Oracle Active Data GuardまたはOracle GoldenGateを使用することもできます。

    ノート:

    Oracle GoldenGateは、アクティブ-パッシブ構成でのみ使用できます。

  • 使用するOracle Data Guard構成は、データベースのデータ損失要件に加えて、REDO生成と比較した場合の使用可能な帯域幅や待機時間など、ネットワークに関する考慮事項に基づいて決定する必要があります。Oracle Data Guard構成を設定する前に、こうした情報が正しく特定されていることを確認してください。

  • 同期REDO転送によってレスポンス時間やスループットに影響が生じる可能性があるため、必ず十分な帯域幅を備えた、待機時間の少ないネットワークを構成してください。

  • Oracle Data Guardには、最大可用性、最大パフォーマンス(デフォルト)および最大保護という3つの保護モードが用意されています。可用性、パフォーマンス、およびデータ保護の要件より適切に満たす保護モードを使用することをお薦めします。詳細は、Oracle Data Guardの保護モードに関する項を参照してください。

  • スタンバイ・サイトのデータベースは、管理リカバリ・モードである必要があります。これによって、スタンバイ・サイトのデータベースは常にメディア・リカバリの状態になります。管理リカバリ・モードを使用すると、フェイルオーバー時間を短縮できます。

  • 本番サイトとスタンバイ・サイトのtnsnames.oraファイルに、本番サイトとスタンバイ・サイト両方のデータベースをエントリしておく必要があります。

  • Oracleデータベース・ファイルのボリューム・マネージャとしてASMを使用することをお薦めします。ASMは、Oracleが推奨するストレージ管理ソリューションで、これまでのボリューム・マネージャ、ファイル・システムおよびRAWデバイスの代替を提供し、単一インスタンスのOracle DatabaseおよびOracle Real Application Clusters (Oracle RAC)構成をサポートします。

    RACおよびASMの詳細は、『Oracle Automatic Storage Management管理者ガイド』および『Real Application Clustersインストレーション・ガイドfor Linux and UNIX』を参照してください。

  • どちらかのサイトのデータベースの1つがOracle RACデータベースである場合、ピア・サイトの単一のインスタンス・データベースにinstance_nameの値と同じ値がある必要があります。

    ノート:

    • 中間層のORACLE_HOME、home、ORACLE_INSTANCE、DOMAIN_HOMEの値は同一である必要があります。

    • データベース層のDB_NAME、INSTANCE_NAME、Listen PortおよびORACLE_SIDの値は同一である必要があります。

    • WLSデータソースの操作を回避するには、アプリケーション・データソースで指定されたSERVICE_NAMEが同一である必要があります。ただし、各データベースは、追加のサービスを定義できます。

次の項では、データベース関連のポイントについて説明します:

親トピック: 設計上の考慮事項

中間層のデータソースの設定

障害時リカバリ・トポロジでは、WebLogicデータソースのデータベース接続文字列で次の方法を使用できます:

  1. Dataguard準備完了("dual") JDBC文字列を使用します。この場合、DB接続文字列にはプライマリとスタンバイの両方のデータベース接続アドレスが含まれますが、サービスを提供するのはプライマリ・ロールを持つデータベースのみです。

    ノート:

    ロールがプライマリの場合、サービス名がアクティブになります。

    例:

        jdbc:oracle:thin:@
    (DESCRIPTION=
    (CONNECT_TIMEOUT=15)
    (RETRY_COUNT=5)
    (RETRY_DELAY=5)
    (ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=prmy-scan)(PORT=1521)))
    (ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=stby-scan)(PORT=1521)))
    (CONNECT_DATA=(SERVICE_NAME=soaedg.example.com))
    )

    メリット:

    • プライマリ・データソースとスタンバイ・データソースで同じ接続文字列が使用されるため、プライマリからWebLogicドメイン構成をコピーした後、スタンバイ構成で変更を実行する必要はありません。

    デメリット:

    • セカンダリでの遅延: 二重文字列で指定された最初のアドレスは、常に最初に試行されます。セカンダリ・システムがプライマリになると、まずJDBCは最初の位置にリストされているアドレスへの接続を試行します。接続が拒否される方法(リモート・スキャンが解決されないため即座に、またはリモート・スキャン名は解決されたがファイアウォールによって接続が拒否されるため遅延など)に応じて、セカンダリでのDB接続確立に遅延が発生する可能性があります。

    • クロス接続のリスク: デフォルトでは、サービスはプライマリでアクティブになるため、プライマリ・データベースに接続されます。しかし、スタンバイがスナップショット・モードで開き、サービスもそこでアクティブになっている場合、プライマリ・ロールの中間層からスタンバイのスナップショット・データベースへの接続を取得するリスクが生じます。

    この接続文字列は、ストレッチ・クラスタ・モデルの場合に役立ちます。たとえば、『Oracle Fusion Middleware SOA 12cマルチ・データセンター・アクティブ-アクティブ・デプロイメントのベスト・プラクティス』のSOAで説明されているように、同じSOAノードがプライマリ・データベースまたはセカンダリ・データベースに接続可能であることは期待できますが、リモート・データベースへのクロス接続が期待も推奨もされないアクティブ-パッシブDRモデルにとっては、最適な方法ではありません。

  2. もう1つの方法は、ローカル・データベースのみを指す、各サイトで異なるdualではないJDBC文字列を使用することです。この方法は、たとえばSOAMP DRホワイトペーパーなどで使用されています。

    例:

    プライマリ・サイトのデータソースの接続文字列:

    jdbc:oracle:thin:@
        (DESCRIPTION=
        (ADDRESS_LIST=
           (ADDRESS=(PROTOCOL=TCP)(HOST=prmy-scan)(PORT=1521)))
           (CONNECT_DATA=(SERVICE_NAME=prmy-service))
        )

    セカンダリ・サイトのデータソースの接続文字列:

    jdbc:oracle:thin:@
        (DESCRIPTION=
        (ADDRESS_LIST=
           (ADDRESS=(PROTOCOL=TCP)(HOST=stby-scan)(PORT=1521)))
           (CONNECT_DATA=(SERVICE_NAME=stby-service))
        )

    ノート:

    文字列は1行に入力することをお薦めします(これらの例では、読みやすさのために1行で記載されていません)。

    メリット:

    • 各サイトがローカル・データベースのみを指していることを考えると、中間層からリモート・データベースへのクロス接続のリスクはありません。

    デメリット:

    • データソースで使用されるDB接続文字列はサイトごとに異なるため、WebLogicドメイン構成をプライマリからスタンバイにコピーするたびに置換が必要になります。

  3. このガイドで推奨されるもう1つの方法は、WebLogicドキュメントのDB接続文字列のかわりにTNS別名を使用に関する項で説明されているように、データソースでTNS別名を使用することです。TNS別名がプライマリとセカンダリで同じ名前であるため、データソースのDB接続文字列も同じになります。TNS別名は、WebLogicドメイン構成とは別に格納されるtnsnames.oraファイルで解決され、サイト間でレプリケートされないため、サイトごとに異なるtnsnames.oraコンテンツを使用できます。各サイトでは、ローカル・データベースのみを指す、サイトごとに適切な接続文字列を使用して、TNS別名を解決します。

    例:

    プライマリ・サイトのデータソースの接続文字列:

    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))
        )

    メリット:

    • WebLogicドメイン構成で同じDB接続文字列が使用されるため、構成をプライマリからスタンバイにレプリケートした後にWebLogic構成を変更する必要はありません。

    • 各サイトがローカル・データベースのみを指しているため、中間層からリモート・データベースへのクロス接続のリスクはありません。

    デメリット:

    • この方法を使用するデメリットはありません。各サイトでtnsnames.oraを構成し、WebLogicで使用するようにするには、1回かぎりの設定ステップのみが必要です。

    ノート:

    GridLinkデータソースでのTNS別名の使用は、Oracle Fusion Middlewareバージョン12.2.1.3以降でサポートされています

このガイドでは、TNS別名の方法を使用します。これは、他の方法と同じメリットがあり、関連するデメリットがないためです。データ・ソースを構成する情報の詳細は、「Oracle Fusion Middlewareアクティブ-パッシブ・デプロイメントのデータ・ソースの構成」を参照してください。

親トピック: データベースに関する考慮事項

開始ポイント

障害時リカバリ・ソリューションを計画する場合、既存のサイトを基にすることも、新しいサイトを作成することもできます。

スタンバイ・サイトを設定する前に、管理者はプロジェクトの開始ポイントを評価する必要があります。通常、Oracle Fusion Middleware障害時リカバリ・トポロジを設計する際の開始ポイントは次のいずれかです。

  • 本番サイトがすでに作成されており、スタンバイ・サイトが計画および作成中です。

    既存の本番サイトがある場合にOracle Fusion Middleware障害時リカバリのスタンバイ・サイトを設計する方法については、「既存のサイトを基にした設計」を参照してください。

  • 既存の本番サイトもスタンバイ・サイトもありません。両方とも設計して作成する必要があります。

    既存の本番サイトもスタンバイ・サイトもない場合にOracle Fusion Middleware障害時リカバリの本番サイトとスタンバイ・サイトを新しく設計する方法については、「新しいサイトの設計」を参照してください。

  • 一部のホストやコンポーネントが現在の本番サイトに存在するものの、そのサイトまたはスタンバイ・サイトに新しいホストやコンポーネントを追加して、適切に機能するOracle Fusion Middleware障害時リカバリ・トポロジを設定する必要があります。

    この章に記載されている関連情報を参考にして、Oracle Fusion Middleware障害時リカバリ・トポロジを設計および実装してください。

この項には次のトピックが含まれます:

  • 既存のサイトを基にした設計
    既存の本番サイトを基にする場合、本番サイトの構成データおよびOracleバイナリ・ファイルはファイル・システムにすでに存在しています。また、ホスト名、ポートおよびユーザー・アカウントもすでに定義されています。
  • 新しいサイトの設計
    Oracle Fusion Middleware障害時リカバリ・トポロジの新しい本番サイトを設計する際に、ホスト名を検討し、(これらの名前に基づいて)構成をスタンバイ・サイトにコピーするようにストレージ・レプリケーションを設定します。

親トピック: 設計上の考慮事項

既存のサイトを基にした設計

既存の本番サイトを基にする場合、本番サイトの構成データおよびOracleバイナリ・ファイルはファイル・システムにすでに存在しています。また、ホスト名、ポートおよびユーザー・アカウントもすでに定義されています。

既存の本番サイトから開始する場合、最初に本番サイトを共有ストレージに移行し(本番サイトが共有ストレージにない場合)、次に「対称トポロジの設計に関する考慮事項」の説明に従って対称スタンバイを作成します

本番サイトを移行するには、次の項を参照してください:

親トピック: 開始ポイント

共有ストレージへの既存の本番サイトの移行

Oracle Fusion Middleware障害時リカバリにストレージ・レプリケーションを使用する場合、Oracleホームおよび中間層構成が共有ストレージに存在する必要があります。本番サイトが障害時リカバリなしで最初に作成された場合、サイトを構成するOracle Fusion Middlewareインスタンスのディレクトリがローカル・ストレージに配置されることがあります。このシナリオでは、Oracle Fusion Middleware障害時リカバリ・ソリューションを実装するには、ホームをすべて共有ストレージに移行する必要があります。

ローカル・ディスクから共有ストレージに本番サイトを移行する際のガイドラインは次のとおりです。

  • 共有ストレージに移動するフォルダのオフライン・バックアップを実行します。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
本番ホストのホスト名をリスナー・アドレスとして保持

障害保護を考慮せずにプライマリ・サイトを作成した場合、FMWコンポーネントがホスト名別名をリスナー・アドレスとして使用せず、かわりにそれらが存在するノードの実際の物理ホスト名を使用する可能性があります。この場合、次の2つのオプションがあります。

  • 「ホスト名の計画」で説明されているように、ホスト別名をサーバーのリスナー・アドレスとして使用するには、既存のサイトのWebLogicドメイン構成を変更します。サーバーにアクセスするすべてのクライアント・ポイントに新しいホスト名を認識させる必要があるため、この変更にはさらなる影響があります。

  • または、本番構成を変更できない場合は、構成をそのまま保持し、FMWコンポーネントのリスナー・アドレスとして物理ホスト名を引き続き使用し、セカンダリでもこれらのホスト名を使用するように調整します。この方法をお薦めします。この場合、プライマリ物理ホスト名は、スタンバイ・サイト・ホストの/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  stbysoa-vip.example.com  stbysoa-vip prsoa-vip.example.com prsoa-vip
172.22.2.111  stbyweb1.example.com     stbyweb1    prweb1.example.com    prweb1
172.22.2.112  stbyweb2.example.com     stbyweb2    prweb2.example.com    prweb2
172.22.2.113  stbysoa1.example.com     stbysoa1    prsoa1.example.com    prsoa1
172.22.2.114  stbysoa2.example.com     stbysoa2    prsoa2.example.com    prsoa2

新しいサイトの設計

Oracle Fusion Middleware障害時リカバリ・トポロジの新しい本番サイトを設計する際に、ホスト名を検討し、(これらの名前に基づいて)構成をスタンバイ・サイトにコピーするようにストレージ・レプリケーションを設定します。

新しい本番サイトを設計する場合、スタンバイ・サイトも計画し、Oracle Universal Installerを使用して、本番サイトにソフトウェアをインストールします。ホスト名別名やソフトウェア・パスなどのパラメータは、両方のサイトで同じになるように、注意して設計する必要があります。

Oracle Fusion Middleware障害時リカバリの本番サイトとスタンバイ・サイトを新しく作成する場合、次のような選択肢を検討します。

  • 本番サイトとスタンバイ・サイトの各ホストが目的のホスト名別名および物理ホスト名を使用するように、Oracle Fusion Middleware障害時リカバリ・ソリューションを設計します。ホスト名の計画の詳細は、「ホスト名の計画」を参照してください。

  • Fusion MiddlewareインストールごとにOracleホーム名およびOracleホーム・ディレクトリを選択します。

    サイトを最初から設計して作成する方が、この章で説明した設計要件に合せて既存のサイトを変更するよりも簡単です。

  • 本番サイト・ホストにOracle Fusion Middlewareインストール用のポートを割り当てます。スタンバイ・サイト・ホストにも同じポートを使用できます。両方のサイトで同じポートを使用する必要があります。

    既存の本番サイトとスタンバイ・サイト間におけるポートの競合を確認して解決するよりも、この設定の方が簡単です。

親トピック: 開始ポイント

トポロジに関する考慮事項

障害時リカバリ・ソリューションを計画する場合、対称トポロジまたは非対称トポロジを検討します。

この項には次のトピックが含まれます:

親トピック: 設計上の考慮事項

対称トポロジの設計に関する考慮事項

対称トポロジは、Oracle Fusion Middleware障害時リカバリ構成の1つで、本番サイトとスタンバイ・サイト間で各階層が同じように構成されます。

対称トポロジでは、本番サイトとスタンバイ・サイトで同じ数のホスト、ロード・バランサ、インスタンスおよびアプリケーションを使用します。また、両方のサイトで同じポートが使用されます。システムはまったく同じように構成され、アプリケーションは同じデータにアクセスします。このマニュアルでは、エンタープライズ構成用に、Oracle Fusion Middleware障害時リカバリで対称トポロジを設定する方法について説明します。

親トピック: トポロジに関する考慮事項

非対称トポロジの設計に関する考慮事項

非対称トポロジは、Oracle Fusion Middleware障害時リカバリ構成の1つで、本番サイトとスタンバイ・サイト間で一部の階層の構成に相違があります。

非対称トポロジでは、スタンバイ・サイトで使用するハードウェアの数が少ない場合があります(本番サイトには4つのホストと4つのOracle Fusion Middlewareインスタンスがあるのに対して、スタンバイ・サイトには2つのホストと4つのOracle Fusion Middlewareインスタンスがある場合など)。

たとえば、スタンバイ・サイトの方が使用するOracle Fusion Middlewareインスタンスの数が少ない非対称トポロジを検討します(本番サイトには4つのOracle Fusion Middlewareインスタンスがあるのに対して、スタンバイ・サイトには2つのOracle Fusion Middlewareインスタンスがある場合など)。

別の非対称トポロジには、データベースのための異なる構成が含まれています(本番サイトでOracle Real Application Clusters (Oracle RAC)データベースを、スタンバイ・サイトで単一のインスタンス・データベースを使用する場合など)。

ノート:

本番サイトとスタンバイ・サイトの両方で対称トポロジと容量を構成することをお薦めします。ノード数または容量が異なると、機能レベルおよびパフォーマンス・レベルで不整合が発生する可能性があります。たとえば、本番サイトに3つのノードがあり、スタンバイ・サイトに2つのノードがある場合、不明なノードがあると、soa-infraアプリケーションがスタンバイ・サイトで起動しないことがあります(追加の本番ノードにはスタンバイ・サイトに同等のノードがありません)。

要約すると、非対称トポロジを構成することはリスクがあり、一般的には推奨されません。お客様の責任と認識において、特殊なケースにのみ適用されます。

親トピック: トポロジに関する考慮事項