3 設計上の考慮事項

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

内容は次のとおりです。

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

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

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

• 開始ポイント

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

注意: Oracle Site Guardを使用してスイッチオーバーやフェイルオーバーなどの障害回復操作を自動化することができます。詳細は、第5章「Oracle Site Guardの使用方法」を参照してください。

この章では、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 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障害時リカバリ・トポロジは、本番サイトとスタンバイ・サイトで次の点について対称である必要があります。

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

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

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

• ポート番号

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

  本番サイトとスタンバイ・サイトのホスト間におけるポートの競合を確認する方法については、第3.4.1項「既存のサイトを基にした設計」を参照してください。

• セキュリティ

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

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

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

• ソフトウェア

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

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

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

• ホスト名の計画

• 仮想IPおよび仮想ホスト名に関する考慮事項

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

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

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

3.1.1 ホスト名の計画

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

物理ホスト名の別名は、ホスト名の解決に単一のグローバルDNSサーバーを使用する場合にのみ作成する必要があります。

この項では、本番サイトとスタンバイ・サイトで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を使用します。

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

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

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

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

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

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

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

注意: このマニュアルの例では、最初の本番サイトのホストの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 Oracle SOA Suiteデプロイメントのスタンバイ・サイトで使用する物理ホスト名」の説明

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

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

表3-3 Oracle WebCenter Portalの本番サイト・ホストの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	WCPHOST1	なし
123.1.2.116	WCPHOST2	なし

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

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

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

表3-4 Oracle WebCenter Portalのスタンバイ・サイト・ホストの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	STBYWCP1	WCPHOST1
123.2.2.116	STBYWCP2	WCPHOST2

^脚注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.118	IDMHOST1	なし
123.1.2.119	IDMHOST2	なし
123.1.2.122	OIDHOST1	なし
123.1.2.123	OIDHOST2	なし
123.1.2.124	OVDHOST1	なし
123.1.2.125	OVDHOST2	なし
123.1.2.126	OIFHOST1	なし
123.1.2.127	OIFHOST2	なし
123.1.2.128	OAMHOST1	なし
123.1.2.129	OAMHOST2	なし
123.1.2.130	OAAMHOST1	なし
123.1.2.131	OAAMHOST2	なし
123.1.2.132	OIMHOST1	なし
123.1.2.133	OIMHOST2	なし

^脚注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.122	STBYOID1	OIDHOST1
123.2.2.123	STBYOID2	OIDHOST2
123.2.2.124	STBYOVD1	OVDHOST1
123.2.2.125	STBYOVD2	OVDHOST2
123.2.2.126	STBYOIF1	OIFHOST1
123.2.2.127	STBYOIF2	OIFHOST2
123.2.2.128	STBYOAM1	OAAMHOST1
123.2.2.129	STBYOAM2	OAAMHOST2
123.2.2.130	STBYOAAM1	OAAMHOST1
123.2.2.131	STBYOAAM2	OAAMHOST2
123.2.2.132	STBYOIM1	OIMHOST1
123.2.2.133	STBYOIM2	OIMHOST2

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

管理サーバー、Oracle Identity Manager管理対象サーバーおよびSOA管理対象サーバーには、各サイトでのプロビジョニング用に浮動IPアドレスが必要です(表3-7)。浮動IPアドレスは、本番サイトとスタンバイ・サイトの両方で、同じ仮想ホスト名でプロビジョニングしてください。

表3-7 浮動IPアドレス

物理ホスト名	仮想ホスト名	浮動IP
AdminServer	ADMINVHN	122.1.2.134
OIMHOST1	OIMVHN1	122.1.2.135
OIMHOST2	OIMVHN2	122.1.2.136
SOAHOST1	SOAVHN1	122.1.2.137
SOAHOST2	SOAVHN2	122.1.2.138

注意: 詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。

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

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

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

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

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

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

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

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

IPアドレス	物理ホスト名脚注1	ホスト名別名
123.1.2.111	WEBHOST1	なし
123.1.2.112	WEBHOST2	なし
123.1.2.113	WCCHOST1	なし
123.1.2.114	WCCHOST2	なし

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

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

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

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

IPアドレス	物理ホスト名脚注1	ホスト名別名
123.2.2.111	STBYWEB1	WEBHOST1
123.2.2.112	STBYWEB2	WEBHOST2
123.2.2.113	STBYWCC1	WCCHOST1
123.2.2.114	STBYWCC2	WCCHOST2

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

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

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

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

IPアドレス	物理ホスト名脚注1	ホスト名別名
123.1.2.111	WEBHOST1	なし
123.1.2.112	WEBHOST2	なし
123.1.2.113	BIHOST1	なし
123.1.2.114	BIHOST2	なし

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

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

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

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

IPアドレス	物理ホスト名脚注1	ホスト名別名
123.2.2.111	STBYWEB1	WEBHOST1
123.2.2.112	STBYWEB2	WEBHOST2
123.2.2.113	STBYBI1	BIHOST1
123.2.2.114	STBYBI2	BIHOST2

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

3.1.1.1 ホスト名の解決

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

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

  ローカルでのホスト名の解決では、各ホストの/etc/hostsファイルで指定したホスト名とIPアドレスのマッピングが使用されます。

  /etc/hostsファイルを使用してローカルでホスト名の解決を実装する方法の詳細は、第3.1.1.2項「ローカルでのホスト名の解決」を参照してください。

• DNSを使用したホスト名の解決

  DNSサーバーは、IPネットワークでDNSによる名前解決を提供する専用サーバーまたはサービスです。

  DNSサーバーによるホスト名の解決を実装する2通りの方法の詳細は、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。

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 WebLogic管理サーバーをホストしているマシンに障害が発生した際に、リクエストの処理が続行されるようOracle WebLogic管理サーバーを有効にするには、仮想IPアドレスおよび仮想ホスト名が必要です。仮想IPアドレスを使用すると、ドメインの管理サーバーによってサーバー移行が行われます。仮想サーバーは、アプリケーション層内の任意のホスト上でネットワーク・インタフェースにバインドできるように、アプリケーション層内でプロビジョニングされる必要があります。

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

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

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

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

• Oracle SOA Suiteの本番サイト・ホストおよびスタンバイ・サイト・ホストの仮想IPアドレスと仮想ホスト名

• Oracle WebCenter Portalの本番サイト・ホストおよびスタンバイ・サイト・ホストの仮想IPアドレスと仮想ホスト名

• Oracle Identity Managementの本番サイト・ホストおよびスタンバイ・サイト・ホストの仮想IPアドレスと仮想ホスト名

• Oracle Portal、Forms、ReportsおよびDiscovererの本番サイト・ホストおよびスタンバイ・サイト・ホストの仮想IPアドレスと仮想ホスト名

• Oracle WebCenter Contentの本番サイト・ホストおよびスタンバイ・サイト・ホストの仮想IPアドレスと仮想ホスト名

• Oracle Business Intelligenceの本番サイト・ホストおよびスタンバイ・サイト・ホストの仮想IPアドレスと仮想ホスト名

Oracle SOA Suiteの本番サイト・ホストおよびスタンバイ・サイト・ホストの仮想IPアドレスと仮想ホスト名

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

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

仮想IPアドレス	仮想ホスト名脚注 1	ホスト名別名
123.1.2.115	ADMINVHN	なし
123.1.2.116	SOAVHN1	なし
123.1.2.117	SOAVHN2	なし

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

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

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

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

仮想IPアドレス	仮想ホスト名脚注 1	ホスト名別名
123.2.2.115	STBYADMINVHN	ADMINVHN
123.2.2.116	STBYSOAVHN1	SOAVHN1
123.2.2.117	STBYSOAVHN2	SOAVHN2

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

Oracle WebCenter Portalの本番サイト・ホストおよびスタンバイ・サイト・ホストの仮想IPアドレスと仮想ホスト名

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

表3-16 Oracle WebCenter Portalの本番サイト・ホストの仮想IPアドレスと仮想ホスト名

仮想IPアドレス	仮想ホスト名脚注 1	ホスト名別名
123.1.2.111	ADMINVHN	なし
123.1.2.113	SOAVHN1	なし
123.1.2.114	SOAVHN2	なし
123.1.2.115	WCPVHN1	なし
123.1.2.116	WCPVHN2	なし

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

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

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

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

仮想IPアドレス	仮想ホスト名脚注 1	ホスト名別名
123.2.2.111	STBYADMINVHN	ADMINVHN
123.2.2.113	STBYSOAVHN1	SOAVHN1
123.2.2.114	STBYSOAVHN2	SOAVHN2
123.2.2.115	STBYWCPVHN1	WCVHN1
123.2.2.116	STBYWCPVHN2	WCVHN2

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

Oracle Identity Managementの本番サイト・ホストおよびスタンバイ・サイト・ホストの仮想IPアドレスと仮想ホスト名

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

表3-18 Identity Managementの本番サイト・ホストの仮想IPアドレスと仮想ホスト名

仮想IPアドレス	仮想ホスト名脚注 1	ホスト名別名
123.1.2.111	ADMINVHN	なし
123.1.2.118	IDMHVHN1	なし
123.1.2.119	IDMVHN2	なし
123.1.2.122	OIDVHN1	なし
123.1.2.123	OIDVHN2	なし
123.1.2.124	OVDVHN1	なし
123.1.2.125	OVDVHN2	なし
123.1.2.126	OIFVHN1	なし
123.1.2.127	OIFVHN2	なし
123.1.2.128	OAMVHN1	なし
123.1.2.129	OAMVHN2	なし
123.1.2.130	OAAMVHN1	なし
123.1.2.131	OAAMVHN2	なし
123.1.2.132	OIMVHN1	なし
123.1.2.133	OIMVHN2	なし

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

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

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

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

仮想IPアドレス	仮想ホスト名脚注 1	ホスト名別名
123.2.2.111	STBYADMINVHN	ADMINVHN
123.2.2.118	STBYIDMVHN1	IDMVHN1
123.2.2.119	STBYIDMVHN2	IDMVHN2
123.2.2.122	STBYOIDVHN1	OIDVHN1
123.2.2.123	STBYOIDVHN2	OIDVHN2
123.2.2.124	STBYOVDVHN1	OVDVHN1
123.2.2.125	STBYOVDVHN2	OVDVHN2
123.2.2.126	STBYOIFVHN1	OIFVHN1
123.2.2.127	STBYOIFVHN2	OIFVHN2
123.2.2.128	STBYOAMVHN1	OAAMVHN1
123.2.2.129	STBYOAMVHN2	OAAMVHN2
123.2.2.130	STBYOAAMVHN1	OAAMVHN1
123.2.2.131	STBYOAAMVHN2	OAAMVHN2
123.2.2.132	STBYOIMVHN1	OIMVHN1
123.2.2.133	STBYOIMVHN2	OIMVHN2

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

管理サーバー、Oracle Identity Manager管理対象サーバーおよびSOA管理対象サーバーには、各サイトでのプロビジョニング用に浮動IPアドレスが必要です(表3-7)。浮動IPアドレスは、本番サイトとスタンバイ・サイトの両方で、同じ仮想ホスト名でプロビジョニングしてください。

表3-20 浮動IPアドレス

物理ホスト名	仮想ホスト名	浮動IP
AdminServer	ADMINVHN	123.1.2.134
OIMHOST1	OIMVHN1	123.1.2.135
OIMHOST2	OIMVHN2	123.1.2.136
SOAHOST1	SOAVHN1	123.1.2.137
SOAHOST2	SOAVHN2	123.1.2.138

注意: 詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。

Oracle Portal、Forms、ReportsおよびDiscovererの本番サイト・ホストおよびスタンバイ・サイト・ホストの仮想IPアドレスと仮想ホスト名

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

表3-21 Oracle Portal、Forms、ReportsおよびDiscovererの本番サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名

仮想IPアドレス	仮想ホスト名脚注 1	ホスト名別名
123.1.2.111	ADMINVHN	なし
123.1.2.126	APPVHN1	なし
123.1.2.127	APPVHN2	なし

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

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

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

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

仮想IPアドレス	仮想ホスト名脚注 1	ホスト名別名
123.2.2.111	STBYADMINVHN	ADMINVHN
123.2.2.126	STBYAPPVHN1	APPVHN1
123.2.2.127	STBYAPPVHN2	APPVHN2

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

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

Oracle WebCenter Contentの本番サイト・ホストおよびスタンバイ・サイト・ホストの仮想IPアドレスと仮想ホスト名

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

表3-23 Oracle Enterprise Content Managementの本番サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名

仮想IPアドレス	仮想ホスト名脚注 1	ホスト名別名
123.1.2.111	ADMINVHN	なし
123.1.2.112	WCCVHN1	なし
123.1.2.114	WCCVHN2	なし

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

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

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

表3-24 Oracle WebCenter Contentのスタンバイ・サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名

仮想IPアドレス	仮想ホスト名脚注 1	ホスト名別名
123.2.2.111	STBYADMINVHN	ADMINVHN
123.2.2.112	STBYWCCVHN1	WCCVHN1
123.2.2.113	STBYWCCVHN2	WCCVHN2

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

Oracle Business Intelligenceの本番サイト・ホストおよびスタンバイ・サイト・ホストの仮想IPアドレスと仮想ホスト名

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

表3-25 Oracle Business Intelligenceの本番サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名

仮想IPアドレス	仮想ホスト名脚注 1	ホスト名別名
123.1.2.115	ADMINVHN	なし
123.1.2.116	BIVHN1	なし
123.1.2.117	BIVHN2	なし

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

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

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

表3-26 Oracle Business Intelligenceのスタンバイ・サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名

仮想IPアドレス	仮想ホスト名脚注 1	ホスト名別名
123.2.2.115	STBYADMINVHN	ADMINVHN
123.2.2.116	STBYBIVHN1	BIVHN1
123.2.2.117	STBYBIVHN2	BIVHN2

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

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

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

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

• ポート変換の構成。

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

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

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

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

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

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

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

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

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

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

• Oracle Access Managerを使用したIdentity Managementの構成については、TCP接続タイムアウトの数値を大きくして、ディレクトリ層でロード・バランサに仮想サーバーを構成します。この値は、Oracle Access Managerとディレクトリ層の間でトラフィックがない場合に、その予想される最大時間より大きい必要があります。

• クライアントIPアドレスを保持する機能: ロード・バランサには、リクエストの元のクライアントIPアドレスをX-Forwarded-For HTTPヘッダーに挿入し、クライアントIPアドレスを保持する機能がある必要があります。

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

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

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

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

個別のDNSサーバーを使用してホスト名を解決する場合は、別名を作成する必要はありません。

各種Oracle Fusion Middleware製品に必要な仮想サーバーを次の表に示します。

表3-27 Oracle SOA Suiteの本番サイトの仮想サーバー

コンポーネント	アクセス	仮想サーバー名	別名
Oracle SOA	外部	soa.mycompany.com	なし
Oracle SOA	内部	soainternal.mycompany.com	なし
管理コンソール	内部	admin.mycompany.com	なし

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

コンポーネント	アクセス	仮想サーバー名	仮想サーバー名別名
Oracle SOA	外部	soa.mycompany.com	なし
Oracle SOA	内部	stbysoainternal.mycompany.com	soainternal.mycompany.com
管理コンソール	内部	admin.mycompany.com	なし

表3-29 Oracle WebCenter Portalの本番サイトの仮想サーバー

コンポーネント	アクセス	仮想サーバー名	別名
Oracle WebCenter Portal	外部	wcp.mycompany.com	なし
Oracle WebCenter Portal	内部	wcpinternal.mycompany.com	なし
Oracle SOA Internal	内部	soainternal.mycompany.com脚注 1	なし
管理コンソール	内部	admin.mycompany.com	なし

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

表3-30 Oracle WebCenter Portal Suiteのスタンバイ・サイトの仮想サーバー

コンポーネント	アクセス	仮想サーバー名	仮想サーバー名別名
Oracle WebCenter Portal	外部	wcp.mycompany.com	なし
Oracle WebCenter Portal	内部	stbywcpinternal.mycompany.com	wcinternal.mycompany.com
Oracle SOA Internal	内部	soainternal.mycompany.com脚注 1	soainternal.mycompany.com
管理コンソール	内部	admin.mycompany.com	なし

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

表3-31 Oracle Identity Managementの本番サイトの仮想サーバー

コンポーネント	アクセス	仮想サーバー名	別名
Oracle Internet Directory	外部	oid.mycompany.com	なし
Oracle Internet Directory	内部	oidinternal.mycompany.com	なし
Oracle Virtual Directory	外部	ovd.mycompany.com	なし
Oracle Virtual Directory	内部	ovdinternal.mycompany.com	なし
Oracle Identity Federation	外部	oif.mycompany.com	なし
Oracle Identity Federation	内部	oifinternal.mycompany.com	なし
Oracle Identity Manager	外部	oim.mycompany.com	なし
Oracle Identity Manager	内部	oiminternal.mycompany.com	なし
シングル・サインオン	外部	sso.mycompany.com	なし
シングル・サインオン	内部	ssointernal.mycompany.com	なし
管理コンソール	内部	admin.mycompany.com	なし

表3-32 Oracle Identity Managementのスタンバイ・サイトの仮想サーバー

コンポーネント	アクセス	仮想サーバー名	別名
Oracle Internet Directory	外部	oid.mycompany.com	なし
Oracle Internet Directory	内部	stbyoidinternal.mycompany.com	oidinternal.mycompany.com
Oracle Virtual Directory	外部	ovd.mycompany.com	なし
Oracle Virtual Directory	内部	stbyovdinternal.mycompany.com	ovdinternal.mycompany.com
Oracle Identity Federation	外部	oif.mycompany.com	なし
Oracle Identity Federation	内部	stbyoifinternal.mycompany.com	oifinternal.mycompany.com
Oracle Identity Manager	外部	oim.mycompany.com	なし
Oracle Identity Manager	内部	stbyoiminternal.mycompany.com	oiminternal.mycompany.com
シングル・サインオン	外部	sso.mycompany.com	なし
シングル・サインオン	内部	stbyssointernal.mycompany.com	ssointernal.mycompany.com
管理コンソール	内部	admin.mycompany.com	なし

表3-33 Oracle Portal、Forms、ReportsおよびDiscovererの本番サイトの仮想サーバー

コンポーネント	アクセス	仮想サーバー名	別名
Oracle Portal	外部	portal.mycompany.com	なし
Oracle Portal	内部	portalinternal.mycompany.com	なし
Oracle FormsおよびOracle Reports	外部	forms.mycompany.com	なし
Oracle FormsおよびOracle Reports	内部	formsinternal.mycompany.com	なし
Discoverer	外部	disco.mycompany.com	なし
Discoverer	内部	discointernal.mycompany.com	なし
管理コンソール	内部	admin.mycompany.com	なし

表3-34 Oracle Portal、Reports、FormsおよびDiscovererのスタンバイ・サイトの仮想サーバー

コンポーネント	アクセス	仮想サーバー名	仮想サーバー名別名
Oracle Portal	外部	portal.mycompany.com	なし
Oracle Portal	内部	stbyportalinternal.mycompany.com	portalinternal.mycompany.com
Oracle FormsおよびOracle Reports	外部	forms.mycompany.com	なし
Oracle FormsおよびOracle Reports	内部	stbyformsinternal.mycompany.com	formsinternal.mycompany.com
Discoverer	外部	disco.mycompany.com	なし
Discoverer	内部	stbydiscointernal.mycompany.com	discointernal.mycompany.com
管理コンソール	内部	admin.mycompany.com	なし

表3-35 Oracle WebCenter Contentの本番サイトの仮想サーバー

コンポーネント	アクセス	仮想サーバー名	別名
Oracle WebCenter Content	外部	wcc.mycompany.com	なし
Oracle WebCenter Content	内部	wccinternal.mycompany.com	なし
Oracle SOA Internal	内部	soainternal.mycompany.com脚注1	なし
管理コンソール	内部	admin.mycompany.com	なし

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

表3-36 Oracle WebCenter Contentのスタンバイ・サイトの仮想サーバー

コンポーネント	アクセス	仮想サーバー名	仮想サーバー名別名
Oracle Enterprise Content Management	外部	ecm.mycompany.com	なし
Oracle Enterprise Content Management	内部	stbyecminternal.mycompany.com	ecminternal.mycompany.com
Oracle SOA Internal	内部	stbysoainternal.mycompany.com脚注 1	soainternal.mycompany.com
管理コンソール	内部	admin.mycompany.com	なし

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

表3-37 Oracle Business Intelligenceの本番サイトの仮想サーバー

コンポーネント	アクセス	仮想サーバー名	別名
Oracle Business Intelligence	外部	bi.mycompany.com	なし
Oracle Business Intelligence	内部	biinternal.mycompany.com	なし
Oracle Access Manager Internal	内部	oaminternal.mycompany.com脚注 1	なし
管理コンソール	内部	admin.mycompany.com	なし

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

表3-38 Oracle Business Intelligenceのスタンバイ・サイトの仮想サーバー

コンポーネント	アクセス	仮想サーバー名	仮想サーバー名別名
Oracle Business Intelligence	外部	bi.mycompany.com	なし
Oracle Business Intelligence	内部	stbybiinternal.mycompany.com	biinternal.mycompany.com
Oracle Access Manager Internal	内部	stbyoaminternal.mycompany.com脚注 1	oaminternal.mycompany.com
管理コンソール	内部	admin.mycompany.com	なし

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

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

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

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

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

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

• DNS名の手動変更

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

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

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

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

3.1.5.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 Databaseの設定に関する推奨事項と考慮事項を説明します。

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

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

   
   

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

   
   

   詳細は、次を参照してください。

   • Oracle Active Data Guard:

     http://www.oracle.com/in/products/database/options/active-data-guard/index.html

   • Oracle GoldenGate:

     http://www.oracle.com/technetwork/middleware/goldengate/overview/index.html

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パラメータにSYNCまたはASYNC属性を指定しておく必要があります。属性を指定しなかった場合は、デフォルトでASYNCに設定されます。

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 Database・リポジトリに格納する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-39に、別名を定義する前のデータベース・ホスト名とデータベース接続文字列を示します。

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

サイト	データベース・ホスト名	データベース接続文字列
本番	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-40に示されているように、データベース・ホスト名に「proddb1」という別名を作成することで、接続文字列を手動で変更しなくて済むようにすることができます。これにより、シームレスなフェイルオーバーとスイッチオーバーが実現します。

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

サイト	データベース・ホスト名	別名	データベース接続文字列
本番	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障害時リカバリ・トポロジを設計する際の開始ポイントは次のいずれかです。

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

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

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

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

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

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

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

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

• 対称スタンバイ・サイトを設計します。第3.5.1項「対称トポロジの設計に関する考慮事項」を参照してください。

• 非対称スタンバイ・サイトを設計します。第3.5.2項「非対称トポロジの設計に関する考慮事項」を参照してください。

• 本番サイトが共有ストレージにない場合、本番サイトを共有ストレージに移行し、対称スタンバイ・サイトまたは非対称スタンバイ・サイトを作成します。第3.4.1.1項「共有ストレージへの既存の本番サイトの移行」を参照してください。

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 Portalについては、『Oracle Fusion Middleware管理者ガイド』のOracle WebCenter Portalのバックアップおよびリカバリの推奨事項に関する説明を参照してください。

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

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

12. 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データベースを使用し、スタンバイ・サイトでは単一インスタンス・データベースを使用する場合など)。