この章では、エンタープライズ・デプロイメントにおける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 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またはサード・パーティ・ソフトウェアのパッチを適用する必要があります。
この項では、ネットワークに関する次の考慮事項について説明します。
障害時リカバリ・トポロジでは、本番サイトのホスト名がスタンバイ・サイトの対応するピア・システムの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を使用します。
この後のサブセクションでは、次のエンタープライズ・デプロイメントの障害時リカバリの本番サイトとスタンバイ・サイトでホスト名を設定する方法を説明します。
Oracle Portal、Forms、ReportsおよびDiscovererの本番サイト・ホストおよびスタンバイ・サイト・ホストのホスト名
Oracle Enterprise Content Managementの本番サイト・ホストおよびスタンバイ・サイト・ホストのホスト名
注意: このマニュアルの例では、最初の本番サイトのホストの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デプロイメントのスタンバイ・サイトで使用する物理ホスト名
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.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 |
なし |
122.1.2.126 |
OIFHOST1 |
なし |
122.1.2.127 |
OIFHOST2 |
なし |
122.1.2.128 |
OAMHOST1 |
なし |
122.1.2.129 |
OAMHOST2 |
なし |
122.1.2.130 |
OAAMHOST1 |
なし |
122.1.2.131 |
OAAMHOST2 |
なし |
122.1.2.132 |
OIMHOST1 |
なし |
122.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 |
122.12.126 |
STBYOIF1 |
OIFHOST1 |
122.12.127 |
STBYOIF2 |
OIFHOST2 |
122.12.128 |
STBYOAM1 |
OAAMHOST1 |
122.12.129 |
STBYOAM2 |
OAAMHOST2 |
122.12.130 |
STBYOAAM1 |
OAAMHOST1 |
122.12.131 |
STBYOAAM2 |
OAAMHOST2 |
122.12.132 |
STBYOIM1 |
OIMHOST1 |
122.12.133 |
STBYOIM2 |
OIMHOST2 |
脚注1 物理ホスト名の定義については、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」および第3.1.1.4項「グローバルDNSサーバーを使用したホスト名の解決」を参照してください。
管理サーバー、Oracle Identity Manager管理対象サーバーおよびSOA管理対象サーバーには、各サイトでのプロビジョニング用に浮動IPアドレスが必要です(表3-7)。浮動IPアドレスは、本番サイトとスタンバイ・サイトの両方で、同じ仮想IP名でプロビジョニングしてください。
表3-7 浮動IPアドレス
物理ホスト名 | 仮想IP | 浮動IP |
---|---|---|
AdminServer |
ADMINVHN |
122.12.134 |
OIMHOST1 |
OIMVHN1 |
122.12.135 |
OIMHOST2 |
OIMVHN2 |
122.12.136 |
SOAHOST1 |
SOAVHN1 |
122.12.137 |
SOAHOST2 |
SOAVHN2 |
122.12.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 Enterprise Content Managementの本番サイト・ホストおよびスタンバイ・サイト・ホストのホスト名
表3-10に、Oracle Enterprise Content Management EDGデプロイメントの本番サイト・ホストに使用するIPアドレスと物理ホスト名を示します。本番サイトにおけるOracle Enterprise Content Management EDGデプロイメントの構成については、図4-11を参照してください。
表3-10 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-11に、Oracle Enterprise Content Management EDGデプロイメントのスタンバイ・サイト・ホストに使用するIPアドレス、物理ホスト名およびホスト名別名を示します。スタンバイ・サイトにおけるOracle Enterprise Content Management EDGデプロイメントの構成については、図4-11を参照してください。
注意: 個別のDNSサーバーを使用してホスト名を解決する場合、本番サイトのホストとスタンバイ・サイトのホストに同じ物理ホスト名を使用できるので、表3-11で推奨されているホスト名別名をスタンバイ・サイトのホストで定義する必要はありません。個別のDNSサーバーを使用してホスト名を解決する方法の詳細は、第3.1.1.3項「個別のDNSサーバーを使用したホスト名の解決」を参照してください。 |
表3-11 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サーバーを使用したホスト名の解決」を参照してください。
ホスト名の解決は、通信のためにホスト名を適切なIPアドレスに解決するプロセスです。ホスト名の解決は、次のいずれかの方法で構成できます。
ローカルでのホスト名の解決では、各ホストの/etc/hosts
ファイルで指定したホスト名とIPアドレスのマッピングが使用されます。
/etc/hosts
ファイルを使用してローカルでホスト名の解決を実装する方法の詳細は、第3.1.1.2項「ローカルでのホスト名の解決」を参照してください。
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
ファイル内のエントリがホスト名の解決で最初に使用されます。
ホストでDNSを使用してホスト名を解決する場合は、例3-2に示されているように、dns
エントリをhosts
パラメータの最初のエントリにします。dns
がhosts
パラメータの最初のエントリである場合、DNSサーバーのエントリがホスト名の解決に最初に使用されます。
わかりやすくすると同時に整合性を保つために、サイト(本番サイトまたはスタンバイ・サイト)内のすべてのホストで同じホスト名の解決方法(ローカルでのホスト名の解決か、個別のDNSサーバーまたはグローバルDNSサーバーを使用したホスト名の解決)を使用することをお薦めします。
次の項に記載されている推奨事項は全般的な推奨事項です。企業で使用しているホスト名解決の標準に合わせて調整できます。
ローカルでのホスト名の解決では、ホストの/etc/hosts
ファイルで定義したホスト名とIPのマッピングが使用されます。障害時リカバリ・トポロジでこの方法を使用してホスト名を解決する場合、次のガイドラインが適用されます。
本番サイトとスタンバイ・サイトのすべてのホストで/etc/nsswitch.conf
ファイルのhosts
パラメータが次のようになっていることを確認します。
hosts: files dns nis
本番サイトのホストの/etc/hosts
ファイル・エントリで、物理ホスト名がIPアドレスにマップされている必要があります。保守を簡潔かつ容易にするために、本番サイトのすべてのホストで同じエントリを使用することをお薦めします。例3-3に、SOAエンタープライズ・デプロイメント・トポロジの本番サイトの/etc/hosts
ファイルを示します。
スタンバイ・サイトのホストの/etc/hosts
ファイル・エントリで、物理ホスト名がIPアドレスにマップされているとともに、本番サイトの対応するピアの物理ホスト名がホスト名別名として定義されている必要があります。保守を簡潔かつ容易にするために、スタンバイ・サイトのすべてのホストで同じエントリを使用することをお薦めします。例3-4に、SOAエンタープライズ・デプロイメント・トポロジの本番サイトの/etc/hosts
ファイルを示します。
/etc/host
ファイル・エントリを使用してホスト名解決を設定したら、ping
コマンドを使用してホスト名解決をテストします。例3-3に示されている静的IPアドレス指定と/etc/hosts
ファイル・エントリを使用して構成したシステムの場合、本番サイトでping webhost1
コマンドを実行すると、適切なIPアドレス(123.1.2.111)が返され、ホスト名が完全修飾されていることがわかります。
同様に、例3-4に示されている静的IPアドレス指定と/etc/hosts
ファイル・エントリを使用して構成したシステムの場合、スタンバイ・サイトでping webhost1
コマンドを実行すると、適切なIPアドレス(123.2.2.111)が返され、WEBHOST1という名前がそのIPアドレスと関連付けられていることがわかります。
このマニュアルでは、本番サイトとスタンバイ・サイトに独自のDNSサーバーがある障害時リカバリ・トポロジを表す場合に「個別のDNSサーバー」という用語を使用します。障害時リカバリ・トポロジで個別のDNSサーバーを使用してホスト名を解決する場合、次のガイドラインが適用されます。
本番サイトとスタンバイ・サイトのすべてのホストで/etc/nsswitch.conf
ファイルのhosts
パラメータが次のようになっていることを確認します。
hosts: dns files nis
本番サイトとスタンバイ・サイトのDNSサーバーが相互を認識してはいけません。独自のサイト内で使用されるホスト名のエントリはそれぞれのDNSサーバーで構成されている必要があります。
本番サイトのDNSサーバーのエントリで、物理ホスト名がIPアドレスにマップされている必要があります。例3-5に、SOAエンタープライズ・デプロイメント・トポロジの本番サイトで使用するDNSサーバーのエントリを示します。
スタンバイ・サイトのDNSサーバーのエントリで、本番サイトの物理ホスト名がIPアドレスにマップされている必要があります。例3-6に、SOAエンタープライズ・デプロイメント・トポロジのスタンバイ・サイトで使用するDNSサーバーのエントリを示します。
本番サイトおよびスタンバイ・サイトのいずれのホストについても、/etc/hosts
ファイルにエントリがないことを確認します。
ping
コマンドを使用してホスト名解決のテストを行います。例3-5に示されている本番サイトのDNSエントリで構成したシステムの場合、本番サイトでping webhost1
コマンドを実行すると、適切なIPアドレス(123.1.2.111)が返され、ホスト名が完全修飾されていることがわかります。
同様に、例3-6に示されているスタンバイ・サイトのDNSエントリで構成したシステムの場合、スタンバイ・サイトでping webhost1
コマンドを実行すると、適切なIPアドレス(123.2.2.111)が返され、ホスト名が完全修飾されていることがわかります。
このマニュアルでは、本番サイトとスタンバイ・サイト両方に対して1つのDNSサーバーを使用する障害時リカバリ・トポロジを表す場合に「グローバルDNSサーバー」という用語を使用します。障害時リカバリ・トポロジでグローバルDNSサーバーを使用してホスト名を解決する場合、次のガイドラインが適用されます。
グローバルDNSサーバーを使用する場合、簡潔にするために、ローカルでのホスト名解決とDNSによるホスト名解決を組み合せることをお薦めします。
この例では、本番サイトでDNSによるホスト名解決を使用し、スタンバイ・サイトではローカルでのホスト名解決を使用することを前提とします。
グローバル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
本番サイトのすべてのホストで/etc/nsswitch.conf
ファイルのhosts
パラメータが次のようになっていることを確認します。
hosts: dns files nis
スタンバイ・サイトのすべてのホストで/etc/nsswitch.conf
ファイルのhosts
パラメータが次のようになっていることを確認します。
hosts: files dns nis
スタンバイ・サイトのホストの/etc/hosts
ファイルのエントリで、物理ホスト名がIPアドレスにマップされているとともに、本番サイトの対応するピアの物理ホスト名がホスト名別名として定義されている必要があります。保守を簡潔かつ容易にするために、スタンバイ・サイトのすべてのホストで同じエントリを使用することをお薦めします。例3-8に、SOAエンタープライズ・デプロイメント・トポロジの本番サイトの/etc/hosts
ファイルを示します。
ping
コマンドを使用してホスト名解決のテストを行います。本番サイトでping webhost1
コマンドを実行すると、適切なIPアドレス(123.1.2.111)が返され、ホスト名が完全修飾されていることがわかります。
同様に、スタンバイ・サイトでping webhost1
コマンドを実行すると、適切なIPアドレス(123.2.2.111)が返され、ホスト名が完全修飾されていることがわかります。
Oracle Fusion Middlewareコンポーネントを高可用性トポロジでデプロイする場合には、ハードウェア・ロード・バランサが必要です。次の機能を備えたハードウェア・ロード・バランサをお薦めします。
仮想ホスト名を使用して実際のサーバーのプールにトラフィックの負荷を分散する機能: クライアントは、実際のホスト名を使用するかわりに、仮想ホスト名を使用してサービスにアクセスします。これによって、ロード・バランサはプール内のサーバーにリクエストの負荷を分散できます。
ポート変換の構成。
ポート(HTTPおよびHTTPS)の監視。
仮想サーバーとポートの構成: 外部ロード・バランサで仮想サーバー名およびポートを構成する機能。仮想サーバー名とポートは次の要件を満たす必要があります。
ロード・バランサでは、複数の仮想サーバーの構成が可能である必要があります。各仮想サーバーについては、複数のポート上のトラフィック管理を構成できることが必要です。たとえば、Oracle Internet Directoryクラスタの場合、ロード・バランサでは、LDAPおよびLDAPSトラフィックの仮想サーバーとポートを構成する必要があります。
仮想サーバー名がIPアドレスと関連付けられており、DNSの一部である必要があります。クライアントは、仮想サーバー名を使用してロード・バランサにアクセスできる必要があります。
ノードの障害を検出し、障害が発生したノードへのトラフィックのルーティングを即座に停止する機能。
リソースの監視、ポートの監視およびプロセスの障害の検出: ロード・バランサは、通知などの方法を使用してサービスやノードの障害を検出し、障害が発生したノードへのOracle Net以外のトラフィックの送信を停止できる必要があります。ロード・バランサで障害を自動的に検出できる場合は、その機能を使用してください。
フォルト・トレラント・モード: ロード・バランサをフォルト・トレラント・モードで構成することを強くお薦めします。
その他: トラフィックの転送先となるバックエンド・サービスが使用できない場合、コール元のクライアントに即座に戻るようにロード・バランサの仮想サーバーを構成することを強くお薦めします。この構成は、クライアント・システムにおけるTCP/IPの設定に基づいてタイムアウト後にクライアント側で接続を切断する構成よりも推奨されます。
スティッキーなルーティング機能: CookieやURLに基づいてコンポーネントへのスティッキーな接続を維持する機能。
SSLアクセラレーション: この機能は推奨されますが、必須ではありません。
Oracle Access Managerを使用したIdentity Managementの構成については、タイムアウトの数値を大きくして(59分など)、ディレクトリ層でロード・バランサを構成します。
Oracle Access Managerでは、パフォーマンスを向上させるために永続LDAP接続が使用されますが、この永続LDAP接続が中断される傾向があるため、サーバーとディレクトリ・サーバー間でのロード・バランサの使用はサポートされていません。
様々な種類のネットワーク・トラフィックや監視に対応するように、仮想サーバーや関連するポートをロード・バランサに構成する必要があります。これらは、実際のホストおよびポートに対して適切に構成し、サービスが継続されるようにする必要があります。また、可用性を確保するために、実際のホストおよびポートを監視して、サービスが停止した場合はできるだけ早く、それらのホストやポートへのトラフィックが停止されるようにロード・バランサを構成する必要があります。これによって、特定の仮想ホストの着信トラフィックが他の層の使用不可のサービスに送信されることがなくなります。
外部トラフィックと内部トラフィックを処理する場合は、ロード・バランサを2つ使用することをお薦めします。このようなトポロジでは、一方のロード・バランサを外部HTTPトラフィック用に設定し、もう一方のロード・バランサを内部LDAPトラフィック用に設定します。様々な理由から、デプロイメントで使用されるロード・バランサ・デバイスが1つになる場合があります。このような構成もサポートされていますが、これに伴うセキュリティへの影響を考慮する必要があります。その構成が適切であることがわかったら、様々なDMZ間のトラフィックを許可するように、関連するファイアウォール・ポートを開いてください。いずれの場合も、特定のロード・バランサ・デバイスをフォルト・トレラント・モードでデプロイすることを強くお薦めします。各種Oracle Fusion Middleware製品に必要な仮想サーバーを次の表に示します。
表3-12 Oracle SOA Suite用の仮想サーバー
コンポーネント | アクセス | 仮想サーバー名 |
---|---|---|
Oracle SOA |
外部 |
soa.mycompany.com |
Oracle SOA |
内部 |
soainternal.mycompany.com |
管理コンソール |
内部 |
admin.mycompany.com |
表3-13 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-14 Oracle Identity Management用の仮想サーバー
コンポーネント | 仮想サーバー名 |
---|---|
Oracle Internet Directory |
oid.mycompany.com |
Oracle Virtual Directory |
ovd.mycompany.com |
Oracle Identity Federation |
oif.mycompany.com |
Oracle Identity Manager |
oiminternal.mycompany.com |
シングル・サインオン |
sso.mycompany.com |
管理コンソール |
admin.mycompany.com |
表3-15 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-16 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ドメインを使用して拡張する場合に必要です。
サイトのスイッチオーバーまたはフェイルオーバーを実行した場合、クライアント・リクエストは本番ロールを引き継ぐ新しいサイトに透過的にリダイレクトされる必要があります。本番サイトのエントリ・ポイントにクライアント・リクエストを送信するには、DNS解決を使用します。このリダイレクションを実現するには、本番サイトへのリクエストを解決するワイド・エリアDNSをスタンバイ・サイトにスイッチオーバーする必要があります。DNSスイッチオーバーを実行するには、グローバル・ロード・バランサを使用するか、DNS名を手動で変更します。
注意: ハードウェア・ロード・バランサは、各サイトのフロントエンドにあることを前提とします。サポートされているロード・バランサについては、次のWebサイトを参照してください。 |
この項では、次の項目について説明します。
グローバル・ロード・バランサを本番サイトとスタンバイ・サイトの前面にデプロイすると、両方のサイトについて、障害検出サービスとパフォーマンスベースのルーティング・リダイレクションが提供されます。さらに、このロード・バランサは、信頼できるDNSネーム・サーバーと同等の機能を提供できます。
通常の操作時には、本番サイトのロード・バランサの名前とIPのマッピングを使用してグローバル・ロード・バランサを構成できます。DNSスイッチオーバーが必要な場合は、グローバル・ロード・バランサのこのマッピングを変更して、スタンバイ・サイトのロード・バランサのIPにマップします。これにより、本番ロールを引き継いだスタンバイ・サイトにリクエストが送信されるようになります。
DNSスイッチオーバーを使用するこの方法は、サイトのスイッチオーバーおよびフェイルオーバーとして機能します。グローバル・ロード・バランサを使用する利点の1つは、名前とIPの新しいマッピングがほとんど即時に有効になる点です。マイナス面は、グローバル・ロード・バランサに対する追加投資が必要な点です。
DNSスイッチオーバーを使用するこの方法では、当初は本番サイトのロード・バランサのIPアドレスにマップされていた名前とIPのマッピングを手動で変更する必要があります。マッピングはスタンバイ・サイトのロード・バランサのIPアドレスにマップするように変更します。スイッチオーバーを実行する手順は次のとおりです。
本番サイトのロード・バランサ・マッピングの現在の存続時間(TTL)値を書き留めます。このマッピングはDNSキャッシュ内にあり、TTLが経過するまでそこに保持されます。例として、TTLが3600秒であるとします。
TTL値を短い間隔(60秒など)に変更します。
元のTTLの間隔が1回経過するまで待ちます。これは、ステップ1で書き留めた元のTTL値である3600秒です。
スタンバイ・サイトがリクエストを受信するようにスイッチオーバーされていることを確認します。
スタンバイ・サイトのロード・バランサを解決するようにDNSマッピングを変更します。通常の操作に適したTTL値(3600秒など)を指定してください。
DNSスイッチオーバーを使用するこの方法は、スイッチオーバー操作またはフェイルオーバー操作として機能します。ステップ2で設定するTTL値は、その時間内にクライアント・リクエストを十分に処理できないような値にする必要があります。TTLを変更する場合、実質的には、アドレス解決のキャッシュ・セマンティックを長い時間から短い時間に変更することになります。キャッシュ時間が短くなるため、DNSリクエストが増加する可能性があります。
この項では、エンタープライズ・デプロイメントの障害時リカバリ・ソリューションで使用するストレージを設計する際の推奨事項について説明します。
通常、特定の環境内の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プロバイダやトランザクション・ログなどの永続ストア。
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
ファイルを使用します。これは、このトポロジに示されているものに加えてインストールしたノードで必要になります。
この項では、共有ストレージにボリュームを作成する際のガイドラインを説明します。ストレージ・デバイスで使用可能なストレージ・レプリケーション・テクノロジの機能によっては、層内の各ノードでマウント・ポイント、ディレクトリおよびシンボリック・リンクを作成しなければならないことがあります。
ストレージ・デバイスのストレージ・レプリケーション・テクノロジによって複数のボリューム間で一貫性のあるレプリケーションが保証される場合:
その層で実行されるサーバーごとにボリュームを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にあります。
|
WebLogic Serverアプリケーション・サーバーは通常、高可用性を確保するためにクラスタ化されています。Oracle SOA Suiteトポロジのローカル・サイトの高可用性については、Java Message Service(JMS)およびトランザクション・ログ(TLog)にファイルベースの永続ストアを使用します。このファイルベースの永続ストアは、クラスタのすべてのメンバーがアクセス可能な共有ストレージに配置する必要があります。
SANストレージ・システムでは、Oracle Clustered File System(OCFS2)など、ホスト・ベースのクラスタまたは共有ファイル・システム・テクノロジを使用する必要があります。OCFS2は、対称型の共有ディスク・クラスタ・ファイル・システムです。これを使用すると、各ノードでメタデータとデータの両方をSANに対して直接読み書きできます。
NASストレージ・システムを使用している場合、クラスタ・ファイル・システムを追加する必要はありません。
この項では、Oracle Fusion Middleware障害時リカバリ・トポロジで使用するOracleデータベースの設定に関する推奨事項と考慮事項を説明します。
使用するトポロジの要件に応じて、本番サイトとスタンバイ・サイトの両方にReal Application Clusterデータベースを作成することをお薦めします。
メタデータ・リポジトリを実行するデータベースについては、障害時保護テクノロジとしてOracle Data Guardをお薦めします。
使用するOracle Data Guard構成は、データベースのデータ損失要件に加えて、REDO生成と比較した場合の使用可能な帯域幅や待機時間など、ネットワークに関する考慮事項に基づいて決定する必要があります。Oracle Data Guard構成を設定する前に、これが正しく特定されていることを確認してください。
詳細は、Oracle Data Guardの概念と管理、および関連事項として次のURLにある最大可用性アーキテクチャに関する情報を参照してください。
http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm
同期REDO転送によってレスポンス時間やスループットに影響が生じる可能性があるため、十分な帯域幅を備えた、待機時間の少ないネットワークを構成します。
スタンバイ・サイトのデータベースのLOG_ARCHIVE_DEST_n
パラメータにLGRW SYNCおよびAFFIRMアーカイブ属性を指定しておく必要があります。
スタンバイ・サイトのデータベースは、管理リカバリ・モードである必要があります。これによって、スタンバイ・サイトのデータベースは常にメディア・リカバリの状態になります。管理リカバリ・モードを使用すると、フェイルオーバー時間を短縮できます。
本番サイトとスタンバイ・サイトのtnsnames.ora
ファイルに、本番サイトとスタンバイ・サイト両方のデータベースをエントリしておく必要があります。
中間層の同期が実行された場合は必ず、Data Guardでデータベースの手動同期を強制的に実行することを強くお薦めします。これは特に、メタデータ・リポジトリに構成データを格納するコンポーネントに該当します。
本番サイトとスタンバイ・サイトの両方でデータベース・ホスト名の別名を設定することを強くお薦めします。これによって、シームレスなスイッチオーバー、スイッチバックおよびフェイルオーバーが実現します。
Oracle Data Guardでは本番データベースとスタンバイ・データベースが同期されるため、本番データベースとスタンバイ・データベースが相互を参照できる必要があります。
Oracle Data Guardでは、tnsnames.ora
ファイル・エントリを使用して、本番データベースとスタンバイ・データベースにリクエストを送信します。そのため、本番データベースとスタンバイ・データベースのエントリをtnsnames.ora
ファイルに作成する必要があります。Oracle Data Guardでtnsnames.oraファイルを使用する方法の詳細は、Oracle Databaseのドキュメント・セットにあるOracle Data Guardの概念と管理を参照してください。
中間層の構成データをOracleデータベース・リポジトリに格納するOracle Fusion Middlewareコンポーネントについては、中間層の同期が実行された場合は必ず、Oracle Data Guardを使用して、データベースを手動で強制的に同期してください。alter system archive log all
というSQL文を使用して、ログを切り替えます。これにより、本番サイトとスタンバイ・サイトのデータベースの同期が強制的に行われます。
例3-9に、本番サイトのデータベースとスタンバイ・サイトのデータベースを強制的に同期する場合に使用するSQL文を示します。
必要に応じて、本番サイトとスタンバイ・サイトのデータベースにデータベース・ホスト名の別名を設定できます。この別名は、DNSまたはデータベース・インスタンスを実行する各ノードの/etc/hosts
ファイルで定義する必要があります。
障害時リカバリ環境では、アクティブに接続を受け取るサイトが本番サイトになります。フェイルオーバー操作またはスイッチオーバー操作が正常に完了すると、スタンバイ・サイトが新しい本番サイトになります。
この項の例では、custdbhost1およびstbycustdbhost1という名前のデータベース・ホストの別名を定義します。表3-17に、別名を定義する前のデータベース・ホスト名とデータベース接続文字列を示します。
表3-17 データベース・ホスト名と接続文字列
サイト | データベース・ホスト名 | データベース接続文字列 |
---|---|---|
本番 |
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-18に示されているように、データベース・ホスト名に「proddb1」という別名を作成することで、接続文字列を手動で変更しなくて済むようにすることができます。これにより、シームレスなフェイルオーバーとスイッチオーバーが実現します。
表3-18 データベース・ホストの別名の指定
サイト | データベース・ホスト名 | 別名 | データベース接続文字列 |
---|---|---|---|
本番 |
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
スタンバイ・サイトを設定する前に、管理者はプロジェクトの開始ポイントを評価する必要があります。通常、Oracle Fusion Middleware障害時リカバリ・トポロジを設計する際の開始ポイントは次のいずれかです。
本番サイトがすでに作成されており、スタンバイ・サイトが計画および作成中です。
既存の本番サイトがある場合にOracle Fusion Middleware障害時リカバリのスタンバイ・サイトを設計する方法については、第3.4.1項「既存のサイトを基にした設計」を参照してください。
既存の本番サイトもスタンバイ・サイトもありません。両方とも設計して作成する必要があります。
既存の本番サイトもスタンバイ・サイトもない場合にOracle Fusion Middleware障害時リカバリの本番サイトとスタンバイ・サイトを新しく設計する方法については、第3.4.2項「新しいサイトの設計」を参照してください。
一部のホストやコンポーネントが現在の本番サイトに存在するものの、そのサイトまたはスタンバイ・サイトに新しいホストやコンポーネントを追加して、適切に機能するOracle Fusion Middleware障害時リカバリ・トポロジを設定する必要があります。
この章に記載されている関連情報を参考にして、Oracle Fusion Middleware障害時リカバリ・トポロジを設計および実装してください。
管理者の開始ポイントが既存の本番サイトである場合、本番サイトの構成データおよびOracleバイナリがファイル・システムにすでに存在します。また、ホスト名、ポートおよびユーザー・アカウントもすでに定義されています。本番サイトが存在する場合、管理者は次の方法を選択できます。
対称スタンバイ・サイトを設計します。第3.5.1項「対称トポロジの設計に関する考慮事項」を参照してください。
非対称スタンバイ・サイトを設計します。第3.5.2項「非対称トポロジの設計に関する考慮事項」を参照してください。
本番サイトが共有ストレージにない場合、本番サイトを共有ストレージに移行し、対称スタンバイ・サイトまたは非対称スタンバイ・サイトを作成します。第3.4.1.1項「共有ストレージへの既存の本番サイトの移行」を参照してください。
Oracle Fusion Middleware障害時リカバリ・ソリューションでは、共有ストレージを使用して、Oracle Fusion Middlewareの中間層構成の障害時保護に使用するストレージ・レプリケーションを実装します。本番サイトがすでに作成されている場合、サイトを構成するOracle Fusion MiddlewareインスタンスのOracleホーム・ディレクトリが共有ストレージに配置されていない可能性があります。その場合、Oracle Fusion Middleware障害時リカバリ・ソリューションを実装するには、それらのホームをすべて共有ストレージに移行する必要があります。
ローカル・ディスクから共有ストレージに本番サイトを移行する際のガイドラインは次のとおりです。
実行するバックアップはすべて、オフライン・バックアップである必要があります。詳細は、『Oracle Fusion Middleware管理者ガイド』のバックアップのタイプに関する項および推奨されるバックアップ計画に関する項を参照してください。
ルート・ユーザーとしてバックアップを実行する必要があり、その権限を保持している必要があります。『Oracle Fusion Middleware管理者ガイド』のバックアップ計画の概要に関する項を参照してください。
これは1回のみの操作なので、ドメイン全体をリカバリすることをお薦めします。
共有ストレージのディレクトリ構造は、第4.1.1項「ディレクトリ構造とボリューム設計」の説明に従って設定する必要があります。
Oracle SOA Suiteについては、『Oracle Fusion Middleware管理者ガイド』のOracle SOA Suiteのバックアップおよびリカバリの推奨事項に関する項を参照してください。
Oracle WebCenterについては、『Oracle Fusion Middleware管理者ガイド』のOracle WebCenterのバックアップおよびリカバリの推奨事項に関する項を参照してください。
Oracle Identity Managementについては、『Oracle Fusion Middleware管理者ガイド』のOracle Identity Managementのバックアップおよびリカバリの推奨事項に関する項を参照してください。
Oracle WebLogic Serverについては、『Oracle Fusion Middleware管理者ガイド』のOracle JRFインストールのバックアップおよびリカバリの推奨事項に関する項を参照してください。
Web層については、『Oracle Fusion Middleware管理者ガイド』のWeb層インストールのバックアップおよびリカバリの推奨事項に関する項を参照してください。
Oracle Portal、Oracle Forms、Oracle ReportsおよびDiscovererのバックアップとリカバリに関する推奨事項については、『Oracle Fusion Middleware管理者ガイド』のOracle Portal、Oracle Forms ServicesおよびOracle Reportsインストールのバックアップおよびリカバリの推奨事項に関する項を参照してください。
この項では、Oracle Fusion Middleware障害時リカバリ・トポロジの新しい本番サイトを実装する際の考え方を紹介します。ここでは、ホスト名を事前に計画し、ホスト名別名と物理ホスト名を解決するようにホストを構成して、これらの名前に基づいて構成をスタンバイ・サイトにコピーするようにストレージ・レプリケーションを設定することによって、本番サイトを計画および設定する方法について説明します。本番サイトを設計する際には、スタンバイ・サイトについても計画する必要があります。対称スタンバイ・サイトまたは非対称スタンバイ・サイトのいずれかを選択できます。
既存の本番サイトを使用せずに新しい本番サイトを設計する場合は、Oracle Universal Installerを使用して本番サイトにソフトウェアをインストールし、ホスト名別名やソフトウェア・パスなどのパラメータが両方のサイトで同じになるように慎重に設計する必要があります。
Oracle Fusion Middleware障害時リカバリの本番サイトとスタンバイ・サイトを新しく作成する場合、次のような柔軟性があります。
本番サイトとスタンバイ・サイトの各ホストが目的のホスト名別名および物理ホスト名を使用するように、Oracle Fusion Middleware障害時リカバリ・ソリューションを設計できます。ホスト名の計画については、第3.1.1項「ホスト名の計画」を参照してください。
本番サイトを最初から設計して作成する場合、各Fusion MiddlewareインストールのOracleホーム名およびOracleホーム・ディレクトリを選択できます。
サイトを最初から設計して作成する方が、この章で説明した設計要件に合わせて既存のサイトを変更するよりも簡単です。
本番サイトのホストのFusion Middlewareインストールに、スタンバイ・サイトのホストで使用するポートと競合しないポートを割り当てることができます。
既存の本番サイトとスタンバイ・サイト間におけるポートの競合を確認して解決するよりも、この方が簡単です。
この項では、次のトポロジの設計に関する考慮事項について説明します。
対称トポロジ
非対称トポロジ
対称トポロジは、Oracle Fusion Middleware障害時リカバリ構成の一つで、本番サイトとスタンバイ・サイト間で各階層がまったく同じように構成されます。対称トポロジでは、本番サイトとスタンバイ・サイトに同じ数のホスト、ロード・バランサ、インスタンスおよびアプリケーションを使用します。また、両方のサイトで同じポートが使用されます。システムはまったく同じように構成され、アプリケーションは同じデータにアクセスします。このマニュアルでは、エンタープライズ構成用に、Oracle Fusion Middleware障害時リカバリで対称トポロジを設定する方法について説明します。
非対称トポロジは、Oracle Fusion Middleware障害時リカバリ構成の一つで、本番サイトとスタンバイ・サイト間で各階層の構成に相違があります。非対称トポロジでは、スタンバイ・サイトで使用するハードウェアの数が少ない場合があります(本番サイトには4つのホストと4つのFusion Middlewareインスタンスがあるのに対して、スタンバイ・サイトには2つのホストと4つのFusion Middlewareインスタンスがある場合など)。また、別の非対称トポロジでは、スタンバイ・サイトで使用するFusion Middlewareインスタンスの数が少ない場合があります(本番サイトのFusion Middlewareインスタンスが4つであるのに対して、スタンバイ・サイトのFusion Middlewareインスタンスが2つである場合など)。さらに別の非対称トポロジでは、データベースの構成が異なる場合があります(本番サイトではReal Application Clustersデータベースを使用し、スタンバイ・サイトでは単一インスタンス・データベースを使用する場合など)。