ヘッダーをスキップ
Oracle® Fusion Middlewareディザスタ・リカバリ・ガイド
11g リリース1(11.1.1)
B61394-01
  目次へ移動
目次		 索引へ移動
索引
前
前 		 次
次		  

3 設計上の考慮事項

この章では、エンタープライズ・デプロイメントにおけるOracle Fusion Middleware障害時リカバリ・ソリューションに関する設計上の考慮事項について説明します。

次のトピックがあります:

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


注意:

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

障害時リカバリの対称型の本番サイトとスタンバイ・サイトを1つの図に示したものについては、図1-1を参照してください。

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

図3-1の説明が続きます。
「図3-1 Oracle Fusion Middleware障害時リカバリの本番サイトとスタンバイ・サイトで使用するデプロイメント」の説明

図3-1は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』のOracle Access Managerエンタープライズ・デプロイメントを使用したmySOACompanyを示しています。このOracle SOA Suiteエンタープライズ・デプロイメントのインストールおよび構成に関する詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』を参照してください。

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

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

この項では、ネットワークに関する次の考慮事項について説明します。

3.1.1 ホスト名の計画

障害時リカバリ・トポロジでは、本番サイトのホスト名がスタンバイ・サイトの対応するピア・システムのIPアドレスに解決可能である必要があります。そのため、本番サイトとスタンバイ・サイトのホスト名を計画することが重要です。

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

各コンポーネントを構成する際には、コンポーネントでIPベースの構成を使用する必要がある場合を除き、IPベースの構成ではなく、ホスト名ベースの構成を使用してください。たとえば、Oracle Fusion Middlewareコンポーネントのリスニング・アドレスを123.1.2.113のような特定のIPアドレスに構成する場合は、123.1.2.113に解決されるホスト名SOAHOST1.MYCOMPANY.COMを使用します。

この後のサブセクションでは、次のエンタープライズ・デプロイメントの障害時リカバリの本番サイトとスタンバイ・サイトでホスト名を設定する方法を説明します。


注意:

このマニュアルの例では、最初の本番サイトのホストのIPアドレスは123.1.x.xという形式で、最初のスタンバイ・サイトのホストのIPアドレスは123.2.x.xという形式です。

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

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

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

IPアドレス 物理ホスト名脚注1  ホスト名別名

123.1.2.111

WEBHOST1

なし

123.1.2.112

WEBHOST2

なし

123.1.2.113

SOAHOST1

なし

123.1.2.114

SOAHOST2

なし

脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

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


注意:

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

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

IPアドレス 物理ホスト名脚注1  ホスト名別名

123.2.2.111

STBYWEB1

WEBHOST1

123.2.2.112

STBYWEB2

WEBHOST2

123.2.2.113

STBYSOA1

SOAHOST1

123.2.2.114

STBYSOA2

SOAHOST2

脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

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

図3-2の説明が続きます
「図3-2 Oracle SOA Suiteデプロイメントのスタンバイ・サイトで使用する物理ホスト名」の説明

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

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

表3-3 WebCenterの本番サイト・ホストのIPアドレスと物理ホスト名

IPアドレス 物理ホスト名脚注1  ホスト名別名

123.1.2.111

WEBHOST1

なし

123.1.2.112

WEBHOST2

なし

123.1.2.113

SOAHOST1

なし

123.1.2.114

SOAHOST2

なし

123.1.2.115

WCHOST1

なし

123.1.2.116

WCHOST2

なし

脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

表3-4に、Oracle WebCenter EDGデプロイメントのスタンバイ・サイト・ホストに使用するIPアドレス、物理ホスト名およびホスト名別名を示します。スタンバイ・サイトにおけるOracle WebCenter EDGデプロイメントの構成については、図4-4を参照してください。


注意:

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

表3-4 WebCenterのスタンバイ・サイト・ホストのIPアドレス、物理ホスト名およびホスト名別名

IPアドレス 物理ホスト名脚注1  ホスト名別名

123.2.2.111

STBYWEB1

WEBHOST1

123.2.2.112

STBYWEB2

WEBHOST2

123.2.2.113

STBYSOA1

SOAHOST1

123.2.2.114

STBYSOA2

SOAHOST2

123.2.2.115

STBYWC1

WCHOST1

123.2.2.116

STBYWC2

WCHOST2

脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

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

表3-5に、Oracle Identity Management EDGデプロイメントの本番サイト・ホストに使用するIPアドレスと物理ホスト名を示します。本番サイトにおけるOracle Identity Management EDGデプロイメントの構成については、図4-6を参照してください。

表3-5 Identity Managementの本番サイト・ホストのIPアドレスと物理ホスト名

IPアドレス 物理ホスト名脚注1  ホスト名別名

123.1.2.111

WEBHOST1

なし

123.1.2.112

WEBHOST2

なし

123.1.2.117

OAMADMINHOST

なし

123.1.2.118

IDMHOST1

なし

123.1.2.119

IDMHOST2

なし

123.1.2.120

OAMHOST1

なし

123.1.2.121

OAMHOST2

なし

123.1.2.122

OIDHOST1

なし

123.1.2.123

OIDHOST2

なし

123.1.2.124

OVDHOST1

なし

123.1.2.125

OVDHOST2

なし

122.12.126

OAAMHOST1

なし

122.12.127

OAAMHOST2

なし

122.12.128

OAPMHOST1

なし

122.12.129

OAPMHOST2

なし

脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

表3-6に、Oracle Identity Management EDGデプロイメントのスタンバイ・サイト・ホストに使用するIPアドレス、物理ホスト名およびホスト名別名を示します。スタンバイ・サイトにおけるOracle Identity Management EDGデプロイメントの構成については、図4-6を参照してください。


注意:

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

表3-6 Identity Managementのスタンバイ・サイト・ホストのIPアドレス、物理ホスト名およびホスト名別名

IPアドレス 物理ホスト名脚注1  ホスト名別名

123.2.2.111

STBYWEB1

WEBHOST1

123.2.2.112

STBYWEB2

WEBHOST2

123.2.2.117

STBYADM

OAMADMINHOST

123.2.2.118

STBYIDM1

IDMHOST1

123.2.2.119

STBYIDM2

IDMHOST2

123.2.2.120

STBYOAM1

OAMHOST1

123.2.2.121

STBYOAM2

OAMHOST2

123.2.2.122

STBYOID1

OIDHOST1

123.2.2.123

STBYOID2

OIDHOST2

123.2.2.124

STBYOVD1

OVDHOST1

123.2.2.125

STBYOVD2

OVDHOST2

脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

Oracle Portal、Forms、ReportsおよびDiscovererの本番サイト・ホストおよびスタンバイ・サイト・ホストのホスト名

表3-7に、Oracle Portal、Forms、ReportsおよびDiscovererエンタープライズ・デプロイメントの本番サイト・ホストに使用するIPアドレスと物理ホスト名を示します。本番サイトにおけるOracle Portalエンタープライズ・デプロイメントの構成については、図4-7を参照してください。本番サイトにおけるOracle Forms、ReportsおよびDiscovererエンタープライズ・デプロイメントの構成については、図4-8を参照してください。

表3-7 Oracle Portal、Forms、ReportsおよびDiscovererの本番サイト・ホストのIPアドレスと物理ホスト名

IPアドレス 物理ホスト名脚注1  ホスト名別名

123.1.2.111

WEBHOST1

なし

123.1.2.112

WEBHOST2

なし

123.1.2.126

APPHOST1

なし

123.1.2.127

APPHOST2

なし

脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

表3-8に、Oracle Portal、Forms、ReportsおよびDiscovererエンタープライズ・デプロイメントのスタンバイ・サイト・ホストに使用するIPアドレス、物理ホスト名およびホスト名別名を示します。本番サイトにおけるOracle Portalエンタープライズ・デプロイメントの構成については、図4-7を参照してください。本番サイトにおけるOracle Forms、ReportsおよびDiscovererエンタープライズ・デプロイメントの構成については、図4-8を参照してください。


注意:

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

表3-8 Oracle Portal、Forms、ReportsおよびDiscovererのスタンバイ・サイト・ホストのIPアドレス、物理ホスト名およびホスト名別名

IPアドレス 物理ホスト名脚注1  ホスト名別名

123.2.2.111

STBYWEB1

WEBHOST1

123.2.2.112

STBYWEB2

WEBHOST1

123.2.2.126

STBYAPP1

APPHOST1

123.2.2.127

STBYAPP2

APPHOST2

脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

表3-2、表3-4、表3-6および表3-7に示されているホスト名別名は、スタンバイ・サイトではローカルに正しいIPアドレスへと解決されます。Oracle Fusion Middleware障害時リカバリ・トポロジでホスト名解決を構成する2通りの方法については、第3.1.1.1項「ホスト名解決」を参照してください。

Oracle Enterprise Content Managementの本番サイト・ホストおよびスタンバイ・サイト・ホストのホスト名

表3-9に、Oracle Enterprise Content Management EDGデプロイメントの本番サイト・ホストに使用するIPアドレスと物理ホスト名を示します。本番サイトにおけるOracle Enterprise Content Management EDGデプロイメントの構成については、図4-9を参照してください。

表3-9 Oracle Enterprise Content Managementの本番サイト・ホストのIPアドレスと物理ホスト名

IPアドレス 物理ホスト名脚注1  ホスト名別名

123.1.2.111

WEBHOST1

なし

123.1.2.112

WEBHOST2

なし

123.1.2.113

ECMHOST1

なし

123.1.2.114

ECMHOST2

なし

脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

表3-10に、Oracle Enterprise Content Management EDGデプロイメントのスタンバイ・サイト・ホストに使用するIPアドレス、物理ホスト名およびホスト名別名を示します。スタンバイ・サイトにおけるOracle Enterprise Content Management EDGデプロイメントの構成については、図4-9を参照してください。


注意:

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

表3-10 Oracle Enterprise Content Managementのスタンバイ・サイト・ホストのIPアドレス、物理ホスト名およびホスト名別名

IPアドレス 物理ホスト名脚注1  ホスト名別名

123.2.2.111

STBYWEB1

WEBHOST1

123.2.2.112

STBYWEB2

WEBHOST2

123.2.2.113

STBYECM1

ECMHOST1

123.2.2.114

STBYECM2

ECMHOST2

脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

3.1.1.1 ホスト名の解決

ホスト名の解決は、通信のためにホスト名を適切なIPアドレスに解決するプロセスです。ホスト名の解決は、次のいずれかの方法で構成できます。

Oracle Fusion Middleware障害時リカバリ・トポロジのデプロイメントを計画する際には、トポロジで使用するホスト名の解決方法を決定する必要があります。ほとんどのサイト管理者は、ホスト名を管理する際にこれらの解決方法を優先順位に従って組み合せて使用しています。

各サイトのOracle Fusion Middlewareホストと共有ストレージ・システムは、相互に通信できる必要があります。

ホスト名解決の優先順位

特定のホストで使用するホスト名の解決方法を決定するには、ホストの/etc/nsswitch.confファイルでhostsパラメータの値を検索します。

ホストでローカルにホスト名を解決する場合は、例3-1に示されているように、filesエントリをhostsパラメータの最初のエントリにします。filesがhostsパラメータの最初のエントリである場合、ホストの/etc/hostsファイル内のエントリがホスト名の解決で最初に使用されます。

例3-1 ローカルでのホスト名解決を使用する場合の指定

hosts:   files   dns   nis

ホストでDNSを使用してホスト名を解決する場合は、例3-2に示されているように、dnsエントリをhostsパラメータの最初のエントリにします。dnsがhostsパラメータの最初のエントリである場合、DNSサーバーのエントリがホスト名の解決に最初に使用されます。

例3-2 DNSによるホスト名解決を使用する場合の指定

hosts:   dns    files   nis

わかりやすくすると同時に整合性を保つために、サイト(本番サイトまたはスタンバイ・サイト)内のすべてのホストで同じホスト名の解決方法(ローカルでのホスト名の解決か、個別のDNSサーバーまたはグローバルDNSサーバーを使用したホスト名の解決)を使用することをお薦めします。

次の項に記載されている推奨事項は全般的な推奨事項です。企業で使用しているホスト名解決の標準に合わせて調整できます。

3.1.1.2 ローカルでのホスト名の解決

ローカルでのホスト名の解決では、ホストの/etc/hostsファイルで定義したホスト名とIPのマッピングが使用されます。障害時リカバリ・トポロジでこの方法を使用してホスト名を解決する場合、次のガイドラインが適用されます。

  1. 本番サイトとスタンバイ・サイトのすべてのホストで/etc/nsswitch.confファイルのhostsパラメータが次のようになっていることを確認します。

    hosts:   files   dns   nis

  2. 本番サイトのホストの/etc/hostsファイル・エントリで、物理ホスト名がIPアドレスにマップされている必要があります。保守を簡潔かつ容易にするために、本番サイトのすべてのホストで同じエントリを使用することをお薦めします。例3-3に、SOAエンタープライズ・デプロイメント・トポロジの本番サイトの/etc/hostsファイルを示します。

    例3-3 本番サイト・ホストの/etc/hostsファイル・エントリの作成

    127.0.0.1      localhost.localdomain    localhost
123.1.2.111    WEBHOST1.MYCOMPANY.COM    WEBHOST1
123.1.2.112    WEBHOST2.MYCOMPANY.COM    WEBHOST2
123.1.2.113    SOAHOST1.MYCOMPANY.COM    SOAHOST1
123.1.2.114    SOAHOST2.MYCOMPANY.COM    SOAHOST2

  3. スタンバイ・サイトのホストの/etc/hostsファイル・エントリで、物理ホスト名がIPアドレスにマップされているとともに、本番サイトの対応するピアの物理ホスト名がホスト名別名として定義されている必要があります。保守を簡潔かつ容易にするために、スタンバイ・サイトのすべてのホストで同じエントリを使用することをお薦めします。例3-4に、SOAエンタープライズ・デプロイメント・トポロジの本番サイトの/etc/hostsファイルを示します。

    例3-4 スタンバイ・サイト・ホストの/etc/hostsファイル・エントリの作成

    127.0.0.1      localhost.localdomain    localhost
123.2.2.111    STBYWEB1.MYCOMPANY.COM    WEBHOST1
123.2.2.112    STBYWEB2.MYCOMPANY.COM    WEBHOST2
123.2.2.113    STBYSOA1.MYCOMPANY.COM    SOAHOST1
123.2.2.114    STBYSOA2.MYCOMPANY.COM    SOAHOST2

  4. /etc/hostファイル・エントリを使用してホスト名解決を設定したら、pingコマンドを使用してホスト名解決をテストします。例3-3に示されている静的IPアドレス指定と/etc/hostsファイル・エントリを使用して構成したシステムの場合、本番サイトでping webhost1コマンドを実行すると、適切なIPアドレス(123.1.2.111)が返され、ホスト名が完全修飾されていることがわかります。

  5. 同様に、例3-4に示されている静的IPアドレス指定と/etc/hostsファイル・エントリを使用して構成したシステムの場合、スタンバイ・サイトでping webhost1コマンドを実行すると、適切なIPアドレス(123.2.2.111)が返され、WEBHOST1という名前がそのIPアドレスと関連付けられていることがわかります。

3.1.1.3 個別のDNSサーバーを使用したホスト名の解決

このマニュアルでは、本番サイトとスタンバイ・サイトに独自のDNSサーバーがある障害時リカバリ・トポロジを表す場合に「個別のDNSサーバー」という用語を使用します。障害時リカバリ・トポロジで個別のDNSサーバーを使用してホスト名を解決する場合、次のガイドラインが適用されます。

  1. 本番サイトとスタンバイ・サイトのすべてのホストで/etc/nsswitch.confファイルのhostsパラメータが次のようになっていることを確認します。

    hosts:   dns   files   nis

  2. 本番サイトとスタンバイ・サイトのDNSサーバーが相互を認識してはいけません。独自のサイト内で使用されるホスト名のエントリはそれぞれのDNSサーバーで構成されている必要があります。

  3. 本番サイトのDNSサーバーのエントリで、物理ホスト名がIPアドレスにマップされている必要があります。例3-5に、SOAエンタープライズ・デプロイメント・トポロジの本番サイトで使用するDNSサーバーのエントリを示します。

    例3-5 個別のDNSサーバー構成における本番サイト・ホストのDNSエントリ

    WEBHOST1.MYCOMPANY.COM    IN    A    123.1.2.111
WEBHOST2.MYCOMPANY.COM    IN    A    123.1.2.112
SOAHOST1.MYCOMPANY.COM    IN    A    123.1.2.113
SOAHOST2.MYCOMPANY.COM    IN    A    123.1.2.114

  4. スタンバイ・サイトのDNSサーバーのエントリで、本番サイトの物理ホスト名がIPアドレスにマップされている必要があります。例3-6に、SOAエンタープライズ・デプロイメント・トポロジのスタンバイ・サイトで使用するDNSサーバーのエントリを示します。

    例3-6 個別のDNSサーバー構成におけるスタンバイ・サイト・ホストのDNSエントリ

    WEBHOST1.MYCOMPANY.COM    IN    A    123.2.2.111
WEBHOST2.MYCOMPANY.COM    IN    A    123.2.2.112
SOAHOST1.MYCOMPANY.COM    IN    A    123.2.2.113
SOAHOST2.MYCOMPANY.COM    IN    A    123.2.2.114

  5. 本番サイトおよびスタンバイ・サイトのいずれのホストについても、/etc/hostsファイルにエントリがないことを確認します。

  6. pingコマンドを使用してホスト名解決のテストを行います。例3-5に示されている本番サイトのDNSエントリで構成したシステムの場合、本番サイトでping webhost1コマンドを実行すると、適切なIPアドレス(123.1.2.111)が返され、ホスト名が完全修飾されていることがわかります。

  7. 同様に、例3-6に示されているスタンバイ・サイトのDNSエントリで構成したシステムの場合、スタンバイ・サイトでping webhost1コマンドを実行すると、適切なIPアドレス(123.2.2.111)が返され、ホスト名が完全修飾されていることがわかります。

3.1.1.4 グローバルDNSサーバーを使用したホスト名の解決

このマニュアルでは、本番サイトとスタンバイ・サイト両方に対して1つのDNSサーバーを使用する障害時リカバリ・トポロジを表す場合に「グローバルDNSサーバー」という用語を使用します。障害時リカバリ・トポロジでグローバルDNSサーバーを使用してホスト名を解決する場合、次のガイドラインが適用されます。

  1. グローバルDNSサーバーを使用する場合、簡潔にするために、ローカルでのホスト名解決とDNSによるホスト名解決を組み合せることをお薦めします。

  2. この例では、本番サイトでDNSによるホスト名解決を使用し、スタンバイ・サイトではローカルでのホスト名解決を使用することを前提とします。

  3. グローバルDNSサーバーに、本番サイトとスタンバイ・サイト両方のホストのエントリがある必要があります。例3-7に、SOAエンタープライズ・デプロイメント・トポロジのエントリを示します。

    例3-7 グローバルDNSサーバー構成を使用する場合の本番サイト・ホストおよびスタンバイ・サイト・ホストのDNSエントリ

    WEBHOST1.MYCOMPANY.COM    IN    A    123.1.2.111
WEBHOST2.MYCOMPANY.COM    IN    A    123.1.2.112
SOAHOST1.MYCOMPANY.COM    IN    A    123.1.2.113
SOAHOST2.MYCOMPANY.COM    IN    A    123.1.2.114
STBYWEB1.MYCOMPANY.COM    IN    A    123.2.2.111
STBYWEB2.MYCOMPANY.COM    IN    A    123.2.2.112
STBYSOA1.MYCOMPANY.COM    IN    A    123.2.2.113
STBYSOA2.MYCOMPANY.COM    IN    A    123.2.2.114

  4. 本番サイトのすべてのホストで/etc/nsswitch.confファイルのhostsパラメータが次のようになっていることを確認します。

    hosts:   dns   files   nis

  5. スタンバイ・サイトのすべてのホストで/etc/nsswitch.confファイルのhostsパラメータが次のようになっていることを確認します。

    hosts:   files   dns   nis

  6. スタンバイ・サイトのホストの/etc/hostsファイルのエントリで、物理ホスト名がIPアドレスにマップされているとともに、本番サイトの対応するピアの物理ホスト名がホスト名別名として定義されている必要があります。保守を簡潔かつ容易にするために、スタンバイ・サイトのすべてのホストで同じエントリを使用することをお薦めします。例3-8に、SOAエンタープライズ・デプロイメント・トポロジの本番サイトの/etc/hostsファイルを示します。

    例3-8 グローバルDNSサーバー構成を使用する場合のスタンバイ・サイトの/etc/hostsファイル・エントリ

    127.0.0.1      localhost.localdomain    localhost
123.2.2.111    STBYWEB1.MYCOMPANY.COM    WEBHOST1
123.2.2.112    STBYWEB2.MYCOMPANY.COM    WEBHOST2
123.2.2.113    STBYSOA1.MYCOMPANY.COM    SOAHOST1
123.2.2.114    STBYSOA2.MYCOMPANY.COM    SOAHOST2

  7. pingコマンドを使用してホスト名解決のテストを行います。本番サイトでping webhost1コマンドを実行すると、適切なIPアドレス(123.1.2.111)が返され、ホスト名が完全修飾されていることがわかります。

  8. 同様に、スタンバイ・サイトでping webhost1コマンドを実行すると、適切なIPアドレス(123.2.2.111)が返され、ホスト名が完全修飾されていることがわかります。

3.1.1.5 ホスト名解決のテスト

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

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

3.1.2 ロード・バランサと仮想IPに関する考慮事項

Oracle Fusion Middlewareコンポーネントを高可用性トポロジでデプロイする場合には、ハードウェア・ロード・バランサが必要です。次の機能を備えたハードウェア・ロード・バランサをお薦めします。

  1. 仮想ホスト名を使用して実際のサーバーのプールにトラフィックの負荷を分散する機能: クライアントは、実際のホスト名を使用するかわりに、仮想ホスト名を使用してサービスにアクセスします。これによって、ロード・バランサはプール内のサーバーにリクエストの負荷を分散できます。

  2. ポート変換の構成。

  3. ポート(HTTPおよびHTTPS)の監視。

  4. 仮想サーバーとポートの構成: 外部ロード・バランサで仮想サーバー名およびポートを構成する機能。仮想サーバー名とポートは次の要件を満たす必要があります。

    • ロード・バランサでは、複数の仮想サーバーの構成が可能である必要があります。各仮想サーバーについては、複数のポート上のトラフィック管理を構成できることが必要です。たとえば、Oracle Internet Directoryクラスタの場合、ロード・バランサでは、LDAPおよびLDAPSトラフィックの仮想サーバーとポートを構成する必要があります。

    • 仮想サーバー名がIPアドレスと関連付けられており、DNSの一部である必要があります。クライアントは、仮想サーバー名を使用してロード・バランサにアクセスできる必要があります。

  5. ノードの障害を検出し、障害が発生したノードへのトラフィックのルーティングを即座に停止する機能。

  6. リソースの監視、ポートの監視およびプロセスの障害の検出: ロード・バランサは、通知などの方法を使用してサービスやノードの障害を検出し、障害が発生したノードへのOracle Net以外のトラフィックの送信を停止できる必要があります。ロード・バランサで障害を自動的に検出できる場合は、その機能を使用してください。

  7. フォルト・トレラント・モード: ロード・バランサをフォルト・トレラント・モードで構成することを強くお薦めします。

  8. その他: トラフィックの転送先となるバックエンド・サービスが使用できない場合、コール元のクライアントに即座に戻るようにロード・バランサの仮想サーバーを構成することを強くお薦めします。この構成は、クライアント・システムにおけるTCP/IPの設定に基づいてタイムアウト後にクライアント側で接続を切断する構成よりも推奨されます。

  9. スティッキーなルーティング機能: CookieやURLに基づいてコンポーネントへのスティッキーな接続を維持する機能。

  10. SSLアクセラレーション: この機能は推奨されますが、必須ではありません。

  11. Oracle Access Managerを使用したIdentity Managementの構成については、タイムアウトの数値を大きくして(59分など)、ディレクトリ層でロード・バランサを構成します。

    Oracle Access Managerでは、パフォーマンスを向上させるために永続LDAP接続が使用されますが、この永続LDAP接続が中断される傾向があるため、サーバーとディレクトリ・サーバー間でのロード・バランサの使用はサポートされていません。

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

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

表3-11 Oracle SOA Suite用の仮想サーバー

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

Oracle SOA

外部

soa.mycompany.com

Oracle SOA

内部

soainternal.mycompany.com

管理コンソール

内部

admin.mycompany.com

表3-12 Oracle WebCenter用の仮想サーバー

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

Oracle WebCenter

外部

wc.mycompany.com

Oracle WebCenter

内部

wcinternal.mycompany.com

Oracle SOA Internal

内部

soainternal.mycompany.com脚注1 

管理コンソール

内部

admin.mycompany.com

脚注1 SOAドメインを使用して拡張する場合に必要です。

表3-13 Oracle Identity Management用の仮想サーバー

コンポーネント 仮想サーバー名

Oracle Internet Directory

oid.mycompany.com

Oracle Virtual Directory

ovd.mycompany.com

Oracle Identity Federation

oif.mycompany.com

シングル・サインオン

sso.mycompany.com

管理コンソール

admin.mycompany.com

表3-14 Oracle Portal、Forms、ReportsおよびDiscoverer用の仮想サーバー

コンポーネント 仮想サーバー名

Oracle Portal

portal.mycompany.com

Oracle FormsおよびOracle Reports

forms.mycompany.com

Discoverer

disco.mycompany.com

管理コンソール

admin.mycompany.com

表3-15 Oracle Enterprise Content Management用の仮想サーバー

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

Oracle Enterprise Content Management

外部

ecm.mycompany.com

Oracle Enterprise Content Management

内部

ecminternal.mycompany.com

Oracle SOA Internal

内部

soainternal.mycompany.com脚注1 

管理コンソール

内部

admin.mycompany.com

脚注1 SOAドメインを使用して拡張する場合に必要です。

3.1.3 ワイド・エリアDNSの操作

サイトのスイッチオーバーまたはフェイルオーバーを実行した場合、クライアント・リクエストは本番ロールを引き継ぐ新しいサイトに透過的にリダイレクトされる必要があります。本番サイトのエントリ・ポイントにクライアント・リクエストを送信するには、DNS解決を使用します。このリダイレクションを実現するには、本番サイトへのリクエストを解決するワイド・エリアDNSをスタンバイ・サイトにスイッチオーバーする必要があります。DNSスイッチオーバーを実行するには、グローバル・ロード・バランサを使用するか、DNS名を手動で変更します。


注意:

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

http://support.oracle.com

この項では、次の項目について説明します。

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

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

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

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

3.1.3.2 DNS名の手動変更

DNSスイッチオーバーを使用するこの方法では、当初は本番サイトのロード・バランサのIPアドレスにマップされていた名前と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リクエストが増加する可能性があります。

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

この項では、エンタープライズ・デプロイメントの障害時リカバリ・ソリューションで使用するストレージを設計する際の推奨事項について説明します。

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

通常、特定の環境内のOracle Fusion Middlewareコンポーネントは相互に依存するため、トポロジ内のコンポーネントが同期されていることが重要です。これは、ボリュームとコンシステンシー・グループを設計する際の重要な考慮事項です。アーティファクトの中には静的なものもあれば、動的なものもあります。

静的アーティファクト

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

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

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

  • BEAホームの一覧: UNIXの場合、user_home/bea/beahomelistにあります。

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

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

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

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

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

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

  • Oracle Fusion Middlewareで使用されるデータベース・メタデータ・リポジトリ。

  • JMSプロバイダやトランザクション・ログなどの永続ストア。

3.2.2 OracleホームとOracleインベントリ

Oracle Fusion Middlewareでは、1つのバイナリ・インストールから複数の管理対象サーバーを作成できます。これにより、共有ストレージの1つの場所にバイナリをインストールし、異なるノードのサーバーでそのインストールを再利用することが可能です。ただし、最大限の可用性を確保するには、冗長バイナリ・インストールの使用をお薦めします。

ORACLE_HOMEまたはWL_HOMEを異なるノードの複数のサーバーで共有する場合は、パッチのインストールおよび適用における整合性を確保するために、それらのノードのOracleインベントリとMiddlewareホームの一覧を常に最新の状態にしておくことをお薦めします。

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

Middlewareホームの一覧を更新してWL_HOMEを追加または削除するには、user_home/bea/beahomelistファイルを使用します。これは、このトポロジに示されているものに加えてインストールしたノードで必要になります。

3.2.3 ストレージ・レプリケーション

この項では、共有ストレージにボリュームを作成する際のガイドラインを説明します。ストレージ・デバイスで使用可能なストレージ・レプリケーション・テクノロジの機能によっては、層内の各ノードでマウント・ポイント、ディレクトリおよびシンボリック・リンクを作成しなければならないことがあります。

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

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

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

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

ストレージ・デバイスのストレージ・レプリケーション・テクノロジによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合:

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

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

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

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

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


注意:

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

Oracle Fusion Middlewareのリリース・ノートは次のURLにあります。

http://www.oracle.com/technology/documentation/middleware.html

3.2.4 ファイルベースの永続ストア

WebLogic Serverアプリケーション・サーバーは通常、高可用性を確保するためにクラスタ化されています。Oracle SOA Suiteトポロジのローカル・サイトの高可用性については、Java Message Service(JMS)およびトランザクション・ログ(TLog)にファイルベースの永続ストアを使用します。このファイルベースの永続ストアは、クラスタのすべてのメンバーがアクセス可能な共有ストレージに配置する必要があります。

SANストレージ・システムでは、Oracle Clustered File System(OCFS2)など、ホスト・ベースのクラスタまたは共有ファイル・システム・テクノロジを使用する必要があります。OCFS2は、対称型の共有ディスク・クラスタ・ファイル・システムです。これを使用すると、各ノードでメタデータとデータの両方をSANに対して直接読み書きできます。

NASストレージ・システムを使用している場合、クラスタ・ファイル・システムを追加する必要はありません。

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

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

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

  2. メタデータ・リポジトリを実行するデータベースについては、障害時保護テクノロジとしてOracle Data Guardをお薦めします。

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

    詳細は、Oracle Data Guardの概念と管理、および関連事項として次のURLにある最大可用性アーキテクチャに関する情報を参照してください。

    http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm

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

  5. スタンバイ・サイトのデータベースのLOG_ARCHIVE_DEST_nパラメータにLGRW SYNCおよびAFFIRMアーカイブ属性を指定しておく必要があります。

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

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

  8. 中間層の同期が実行された場合は必ず、Data Guardでデータベースの手動同期を強制的に実行することを強くお薦めします。これは特に、メタデータ・リポジトリに構成データを格納するコンポーネントに該当します。

  9. 本番サイトとスタンバイ・サイトの両方でデータベース・ホスト名の別名を設定することを強くお薦めします。これによって、シームレスなスイッチオーバー、スイッチバックおよびフェイルオーバーが実現します。

3.3.1 データベースのTNSNAMES.ORAエントリの作成

Oracle Data Guardでは本番データベースとスタンバイ・データベースが同期されるため、本番データベースとスタンバイ・データベースが相互を参照できる必要があります。

Oracle Data Guardでは、tnsnames.oraファイル・エントリを使用して、本番データベースとスタンバイ・データベースにリクエストを送信します。そのため、本番データベースとスタンバイ・データベースのエントリをtnsnames.oraファイルに作成する必要があります。Oracle Data Guardでtnsnames.oraファイルを使用する方法の詳細は、Oracle Databaseのドキュメント・セットにあるOracle Data Guardの概念と管理を参照してください。

3.3.2 Oracle Data Guardを使用した手動によるデータベースの強制同期

中間層の構成データをOracleデータベース・リポジトリに格納するOracle Fusion Middlewareコンポーネントについては、中間層の同期が実行された場合は必ず、Oracle Data Guardを使用して、データベースを手動で強制的に同期してください。alter system archive log allというSQL文を使用して、ログを切り替えます。これにより、本番サイトとスタンバイ・サイトのデータベースの同期が強制的に行われます。

例3-9に、本番サイトのデータベースとスタンバイ・サイトのデータベースを強制的に同期する場合に使用するSQL文を示します。

例3-9 手動によるOracle Data Guardデータベースの強制同期

ALTER SYSTEM ARCHIVE LOG ALL;

3.3.3 データベース・ホスト名の別名の設定

必要に応じて、本番サイトとスタンバイ・サイトのデータベースにデータベース・ホスト名の別名を設定できます。この別名は、DNSまたはデータベース・インスタンスを実行する各ノードの/etc/hostsファイルで定義する必要があります。

障害時リカバリ環境では、アクティブに接続を受け取るサイトが本番サイトになります。フェイルオーバー操作またはスイッチオーバー操作が正常に完了すると、スタンバイ・サイトが新しい本番サイトになります。

この項の例では、custdbhost1およびstbycustdbhost1という名前のデータベース・ホストの別名を定義します。表3-16に、別名を定義する前のデータベース・ホスト名とデータベース接続文字列を示します。

表3-16 データベース・ホスト名と接続文字列

サイト データベース・ホスト名 データベース接続文字列

本番

custdbhost1.us.oracle.com

custdbhost1.us.oracle.com:1521:orcl

スタンバイ

stbycustdbhost1.us.oracle.com

stbycustdbhost1.us.oracle.com:1521:orcl

この例では、本番サイトのすべてのデータベース接続文字列に「custdbhost1.us.oracle.com:1521:orcl」という形式を使用します。フェイルオーバー操作またはスイッチオーバー操作の後、この接続文字列を「stbycustdbhost1.us.oracle.com:1521:orcl」に変更する必要があります。ただし、表3-17に示されているように、データベース・ホスト名に「proddb1」という別名を作成することで、接続文字列を手動で変更しなくて済むようにすることができます。これにより、シームレスなフェイルオーバーとスイッチオーバーが実現します。

表3-17 データベース・ホストの別名の指定

サイト データベース・ホスト名 別名 データベース接続文字列

本番

custdbhost1.us.oracle.com

proddb1.us.oracle.com

proddb1.us.oracle.com:1521:orcl

スタンバイ

stbycustdbhost1.us.oracle.com

proddb1.us.oracle.com

proddb1.us.oracle.com:1521:orcl

この例では、本番サイトのデータベース・ホスト名とスタンバイ・サイトのデータベース・ホスト名に「proddb1.us.oracle.com」という別名を作成し、本番サイトとスタンバイ・サイトの接続文字列に「proddb1.us.oracle.com:1521:orcl」という形式を使用できるようにします。フェイルオーバー操作およびスイッチオーバー操作の際、接続文字列を変更する必要がないため、シームレスなフェイルオーバーとスイッチオーバーが実現します。

/etc/hostsファイル・エントリで別名を指定する際の形式は次のとおりです。

<IP>    <ALIAS WITH DOMAIN> <ALIAS>    <HOST NAME WITH DOMAIN> <HOST NAME>

この例では、本番サイトのホストcustdbhost1とスタンバイ・サイトのホストstbycustdbhost1にproddb1というデータベース・ホスト名の別名を作成します。hostsファイル・エントリでは、<ALIAS WITH DOMAIN>パラメータでデータベース・ホスト名の完全修飾された別名を、<ALIAS>パラメータでデータベース・ホスト名の短い別名を、<HOST NAME WITH DOMAIN>パラメータで完全修飾されたホスト名を、<HOST NAME>パラメータで短いホスト名を指定する必要があります。

そのため、本番サイトの/etc/hostsファイルでは、ホストcustdbhost1のエントリが次のようになっていることを確認してください。

152.68.196.213 proddb1.us.oracle.com proddb1 custdbhost1.us.oracle.com custdbhost1

また、スタンバイ・サイトの/etc/hostsファイルでは、ホストstbycustdbhost1のエントリが次のようになっていることを確認してください。

140.87.25.40   proddb1.us.oracle.com proddb1 stbycustdbhost1.us.oracle.com stbycustdbhost1

3.4 開始ポイント

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

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

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

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

Oracle Fusion Middleware障害時リカバリ・ソリューションでは、共有ストレージを使用して、Oracle Fusion Middlewareの中間層構成の障害時保護に使用するストレージ・レプリケーションを実装します。本番サイトがすでに作成されている場合、サイトを構成するOracle Fusion MiddlewareインスタンスのOracleホーム・ディレクトリが共有ストレージに配置されていない可能性があります。その場合、Oracle Fusion Middleware障害時リカバリ・ソリューションを実装するには、それらのホームをすべて共有ストレージに移行する必要があります。

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

  1. 実行するバックアップはすべて、オフライン・バックアップである必要があります。詳細は、『Oracle Fusion Middleware管理者ガイド』のバックアップのタイプに関する項および推奨されるバックアップ計画に関する項を参照してください。

  2. ルート・ユーザーとしてバックアップを実行する必要があり、その権限を保持している必要があります。『Oracle Fusion Middleware管理者ガイド』のバックアップ計画の概要に関する項を参照してください。

  3. これは1回のみの操作なので、ドメイン全体をリカバリすることをお薦めします。

  4. 共有ストレージのディレクトリ構造は、第4.1.1項「ディレクトリ構造とボリューム設計」の説明に従って設定する必要があります。

  5. Oracle SOA Suiteについては、『Oracle Fusion Middleware管理者ガイド』のOracle SOA Suiteのバックアップおよびリカバリの推奨事項に関する項を参照してください。

  6. Oracle WebCenterについては、『Oracle Fusion Middleware管理者ガイド』のOracle WebCenterのバックアップおよびリカバリの推奨事項に関する項を参照してください。

  7. Oracle Identity Managementについては、『Oracle Fusion Middleware管理者ガイド』のOracle Identity Managementのバックアップおよびリカバリの推奨事項に関する項を参照してください。

  8. Oracle WebLogic Serverについては、『Oracle Fusion Middleware管理者ガイド』のOracle JRFインストールのバックアップおよびリカバリの推奨事項に関する項を参照してください。

  9. Web層については、『Oracle Fusion Middleware管理者ガイド』のWeb層インストールのバックアップおよびリカバリの推奨事項に関する項を参照してください。

  10. Oracle Portal、Oracle Forms、Oracle ReportsおよびDiscovererのバックアップとリカバリに関する推奨事項については、『Oracle Fusion Middleware管理者ガイド』のOracle Portal、Oracle Forms ServicesおよびOracle Reportsインストールのバックアップおよびリカバリの推奨事項に関する項を参照してください。

3.4.2 新しいサイトの設計

この項では、Oracle Fusion Middleware障害時リカバリ・トポロジの新しい本番サイトを実装する際の考え方を紹介します。ここでは、ホスト名を事前に計画し、ホスト名別名と物理ホスト名を解決するようにホストを構成して、これらの名前に基づいて構成をスタンバイ・サイトにコピーするようにストレージ・レプリケーションを設定することによって、本番サイトを計画および設定する方法について説明します。本番サイトを設計する際には、スタンバイ・サイトについても計画する必要があります。対称スタンバイ・サイトまたは非対称スタンバイ・サイトのいずれかを選択できます。

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

Oracle Fusion Middleware障害時リカバリの本番サイトとスタンバイ・サイトを新しく作成する場合、次のような柔軟性があります。

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

  2. 本番サイトを最初から設計して作成する場合、各Fusion MiddlewareインストールのOracleホーム名およびOracleホーム・ディレクトリを選択できます。

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

  3. 本番サイトのホストのFusion Middlewareインストールに、スタンバイ・サイトのホストで使用するポートと競合しないポートを割り当てることができます。

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

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

この項では、次のトポロジの設計に関する考慮事項について説明します。

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

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

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

非対称トポロジは、Oracle Fusion Middleware障害時リカバリ構成の一つで、本番サイトとスタンバイ・サイト間で各階層の構成に相違があります。非対称トポロジでは、スタンバイ・サイトで使用するハードウェアの数が少ない場合があります(本番サイトには4つのホストと4つのFusion Middlewareインスタンスがあるのに対して、スタンバイ・サイトには2つのホストと4つのFusion Middlewareインスタンスがある場合など)。また、別の非対称トポロジでは、スタンバイ・サイトで使用するFusion Middlewareインスタンスの数が少ない場合があります(本番サイトのFusion Middlewareインスタンスが4つであるのに対して、スタンバイ・サイトのFusion Middlewareインスタンスが2つである場合など)。さらに別の非対称トポロジでは、データベースの構成が異なる場合があります(本番サイトではReal Application Clustersデータベースを使用し、スタンバイ・サイトでは単一インスタンス・データベースを使用する場合など)。

  前
前 		 次
次
  目次へ移動
目次		 索引へ移動
索引