この章では、エンタープライズ・デプロイメントにおけるOracle Fusion Middleware障害時リカバリ・ソリューションに関する設計上の考慮事項について説明します。
含まれる内容は、次のとおりです。
注意: Oracle Site Guardを使用してスイッチオーバーやフェイルオーバーなどの障害回復操作を自動化することができます。詳細は、Oracle Enterprise Managerライフサイクル管理ガイドの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 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アドレスに解決可能である必要があります。そのため、本番サイトとスタンバイ・サイトのホスト名を計画することが重要です。プライマリ・サイトからスタンバイ・サイトへのフェイルオーバー後に、スタンバイ・サイトの中間層ホストのホスト名別名がアクティブになります。スタンバイ・サイトの別名を設定する場合、スタンバイ・サイトのホストのホスト名を再構成する必要はありません。
物理ホスト名の別名は、ホスト名の解決に単一のグローバルDNSサーバーを使用する場合にのみ作成する必要があります。
この項では、本番サイトとスタンバイ・サイトでOracle Fusion Middlewareインスタンスを使用する中間層ホストについて、物理ホスト名およびホスト名別名を計画する方法を説明します。ホスト名の例として、図3-1に示されているOracle SOA Suiteエンタープライズ・デプロイメントを使用します。この項に記載されているホスト名の例は、障害時リカバリの対称サイトを設定することを前提としています(つまり、本番サイトとスタンバイ・サイトのホスト数は同じです)。本番サイトとスタンバイ・サイトの各ホストに他方のサイトのピア・ホストがあります。ピア・ホストは、他方のサイトの対応するホストと同じポートを使用するなど、同様に構成されます。
各コンポーネントを構成する際には、コンポーネントでIPベースの構成を使用する必要がある場合を除き、IPベースの構成ではなく、ホスト名ベースの構成を使用してください。たとえば、Oracle Fusion Middlewareコンポーネントのリスニング・アドレスを特定のIPアドレス(172.16.10.255など)
に構成する場合は、172.16.10.2555
に解決されるホスト名SOAHOST1.EXAMPLE.COM
を使用します。
この後のサブセクションでは、次のエンタープライズ・デプロイメントの障害時リカバリの本番サイトとスタンバイ・サイトでホスト名を設定する方法を説明します。
注意: このガイドで示されている例では、最初の本番サイトのホストのIPアドレスは172.16.x.xという形式で、最初のスタンバイ・サイトのホストのIPアドレスは172.16.x.xという形式です。 |
Oracle SOA Suiteの本番サイト・ホストおよびスタンバイ・サイト・ホストのホスト名
表3-9に、『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』(EDG)のデプロイメントの本番サイト・ホストに使用するIPアドレスと物理ホスト名を示します。本番サイトにおけるOracle SOA Suite EDGデプロイメントの構成については、図3-1を参照してください。
表3-1 SOA Suiteの本番サイト・ホストのIPアドレスと物理ホスト名
IPアドレス | 物理ホスト名脚注1 | ホスト名別名 |
---|---|---|
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
脚注 1 物理ホスト名の定義の詳細は、第3.1.1.3項および第3.1.1.4項を参照してください。
表3-2に、Oracle SOA Suite EDGデプロイメントのスタンバイ・サイト・ホストに使用するIPアドレス、物理ホスト名およびホスト名別名を示します。図3-2には、スタンバイ・サイトでOracle SOA Suite EDGデプロイメントに使用する物理ホスト名を示します。図3-2に示されているOracle SOA Suiteのスタンバイ・サイト・ホストについては、表3-2に示されているホスト名別名を定義する必要があります。
表3-2 SOA Suiteのスタンバイ・サイト・ホストのIPアドレス、物理ホスト名およびホスト名別名
IPアドレス | 物理ホスト名脚注1 | ホスト名別名 |
---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
脚注 1 物理ホスト名の定義の詳細は、第3.1.1.3項および第3.1.1.4項を参照してください。
図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 | ホスト名別名 |
---|---|---|
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
脚注 1 物理ホスト名の定義の詳細は、第3.1.1.3項および第3.1.1.4項を参照してください。
表3-4に、Oracle WebCenter Portal EDGデプロイメントのスタンバイ・サイト・ホストに使用するIPアドレス、物理ホスト名およびホスト名別名を示します。スタンバイ・サイトにおけるOracle WebCenter Portal EDGデプロイメントの構成については、図4-4を参照してください。
表3-4 Oracle WebCenter Portalのスタンバイ・サイト・ホストのIPアドレス、物理ホスト名およびホスト名別名
IPアドレス | 物理ホスト名脚注1 | ホスト名別名 |
---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
脚注 1 物理ホスト名の定義の詳細は、第3.1.1.3項および第3.1.1.4項を参照してください。
Oracle Identity Managementの本番サイト・ホストおよびスタンバイ・サイト・ホストのホスト名
表3-5に、Oracle Identity Management EDGデプロイメントの本番サイト・ホストに使用するIPアドレスと物理ホスト名を示します。本番サイトにおけるOracle Identity Management EDGデプロイメントの構成については、図4-6を参照してください。
表3-5 Identity Managementの本番サイト・ホストのIPアドレスと物理ホスト名
IPアドレス | 物理ホスト名脚注1 | ホスト名別名 |
---|---|---|
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
脚注 1 物理ホスト名の定義の詳細は、第3.1.1.3項および第3.1.1.4項を参照してください。
表3-6に、Oracle Identity Management EDGデプロイメントのスタンバイ・サイト・ホストに使用するIPアドレス、物理ホスト名およびホスト名別名を示します。スタンバイ・サイトにおけるOracle Identity Management EDGデプロイメントの構成については、図4-6を参照してください。
表3-6 Identity Managementのスタンバイ・サイト・ホストのIPアドレス、物理ホスト名およびホスト名別名
IPアドレス | 物理ホスト名脚注1 | ホスト名別名 |
---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
脚注 1 物理ホスト名の定義の詳細は、第3.1.1.3項および第3.1.1.4項を参照してください。
管理サーバー、Oracle Identity Manager管理対象サーバーおよびSOA管理対象サーバーには、各サイトでのプロビジョニング用に浮動IPアドレスが必要です(表3-7)。浮動IPアドレスは、本番サイトとスタンバイ・サイトの両方で、同じ仮想ホスト名でプロビジョニングしてください。
表3-7 浮動IPアドレス
物理ホスト名 | 仮想ホスト名 | 浮動IP |
---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
注意: 詳細は、『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 | ホスト名別名 |
---|---|---|
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
脚注 1 物理ホスト名の定義の詳細は、第3.1.1.3項および第3.1.1.4項を参照してください。
表3-9に、Oracle Portal、Forms、ReportsおよびDiscovererエンタープライズ・デプロイメントのスタンバイ・サイト・ホストに使用するIPアドレス、物理ホスト名およびホスト名別名を示します。本番サイトにおけるOracle Portalエンタープライズ・デプロイメントの構成については、図4-9を参照してください。本番サイトにおけるOracle Forms、ReportsおよびDiscovererエンタープライズ・デプロイメントの構成については、図4-10を参照してください。
表3-9 Oracle Portal、Forms、ReportsおよびDiscovererのスタンバイ・サイト・ホストのIPアドレス、物理ホスト名およびホスト名別名
IPアドレス | 物理ホスト名脚注1 | ホスト名別名 |
---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
脚注 1 物理ホスト名の定義の詳細は、第3.1.1.3項および第3.1.1.4項を参照してください。
表3-2、表3-4、表3-6および表3-8に示されているホスト名別名は、スタンバイ・サイトではローカルに正しいIPアドレスへと解決されます。、第3.1.1.1項では、Oracle Fusion Middleware障害時リカバリ・トポロジでホスト名解決を構成する2通りの方法について説明しています。
Oracle WebCenter Contentの本番サイト・ホストおよびスタンバイ・サイト・ホストのホスト名
表3-10に、Oracle WebCenter Content EDGデプロイメントの本番サイト・ホストに使用するIPアドレスと物理ホスト名を示します。本番サイトにおけるOracle WebCenter Content EDGデプロイメントの構成については、図4-11を参照してください。
表3-10 Oracle WebCenter Contentの本番サイト・ホストのIPアドレスと物理ホスト名
IPアドレス | 物理ホスト名脚注1 | ホスト名別名 |
---|---|---|
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
脚注 1 物理ホスト名の定義の詳細は、第3.1.1.3項および第3.1.1.4項を参照してください。
表3-11に、Oracle WebCenter Content EDGデプロイメントのスタンバイ・サイト・ホストに使用するIPアドレス、物理ホスト名およびホスト名別名を示します。スタンバイ・サイトにおけるOracle WebCenter Content EDGデプロイメントの構成については、図4-11を参照してください。
表3-11 Oracle WebCenter Contentのスタンバイ・サイト・ホストのIPアドレス、物理ホスト名およびホスト名別名
IPアドレス | 物理ホスト名脚注1 | ホスト名別名 |
---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
脚注 1 物理ホスト名の定義の詳細は、第3.1.1.3項および第3.1.1.4項を参照してください。
Oracle Business Intelligenceの本番サイト・ホストおよびスタンバイ・サイト・ホストのホスト名
表3-12に、Oracle Business Intelligence EDGデプロイメントの本番サイト・ホストに使用するIPアドレスと物理ホスト名を示します。本番サイトにおけるOracle Business Intelligence EDGデプロイメントの構成については、図4-13を参照してください。
表3-12 Oracle Business Intelligenceの本番サイト・ホストのIPアドレスと物理ホスト名
IPアドレス | 物理ホスト名脚注1 | ホスト名別名 |
---|---|---|
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
脚注 1 物理ホスト名の定義の詳細は、第3.1.1.3項および第3.1.1.4項を参照してください。
表3-13に、Oracle Business Intelligence EDGデプロイメントのスタンバイ・サイト・ホストに使用するIPアドレス、物理ホスト名およびホスト名別名を示します。スタンバイ・サイトにおけるOracle Business Intelligence EDGデプロイメントの構成については、図4-13を参照してください。
表3-13 Oracle Business Intelligenceのスタンバイ・サイト・ホストのIPアドレス、物理ホスト名およびホスト名別名
IPアドレス | 物理ホスト名脚注1 | ホスト名別名 |
---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
脚注 1 物理ホスト名の定義の詳細は、第3.1.1.3項および第3.1.1.4項を参照してください。
ホスト名の解決は、通信のためにホスト名を適切なIPアドレスに解決するプロセスです。ホスト名の解決は、次のいずれかの方法で構成できます。
ローカルでのホスト名の解決では、各ホストの/etc/hosts
ファイルで指定したホスト名とIPアドレスのマッピングが使用されます。
/etc/hosts
ファイルを使用してローカルでホスト名のファイル解決を実装する方法の詳細は、第3.1.1.2項を参照してください。
DNSサーバーは、IPネットワークでDNSによる名前解決を提供する専用サーバーまたはサービスです。
DNSサーバーのホスト名解決を実装する2つの方法の詳細は、第3.1.1.3項および第3.1.1.4項を参照してください。
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アドレス(172.1.2.111)が返され、ホスト名が完全修飾されていることがわかります。
同様に、例3-4に示されている静的IPアドレス指定と/etc/hosts
ファイル・エントリを使用して構成したシステムの場合、スタンバイ・サイトでping webhost1
コマンドを実行すると、適切なIPアドレス(172.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アドレス(172.1.2.111)が返され、ホスト名が完全修飾されていることがわかります。
同様に、例3-6に示されているスタンバイ・サイトのDNSエントリで構成したシステムの場合、スタンバイ・サイトでping webhost1
コマンドを実行すると、適切なIPアドレス(172.2.2.111)が返され、ホスト名が完全修飾されていることがわかります。
このマニュアルでは、本番サイトとスタンバイ・サイト両方に対して1つのDNSサーバーを使用する障害時リカバリ・トポロジを表す場合に「グローバルDNSサーバー」という用語を使用します。障害時リカバリ・トポロジでグローバルDNSサーバーを使用してホスト名を解決する場合、次のガイドラインが適用されます。
グローバルDNSサーバーを使用する場合は、簡潔にするために、ローカルでのホスト名解決とDNSによるホスト名解決を組み合せて使用します。
この例では、本番サイトでDNSによるホスト名解決を使用し、スタンバイ・サイトではローカルでのホスト名解決を使用することを前提とします。
グローバルDNSサーバーに、本番サイトとスタンバイ・サイト両方のホストのエントリがある必要があります。例3-7に、SOAエンタープライズ・デプロイメント・トポロジのエントリを示します。
例3-7 グローバルDNSサーバー構成を使用する場合の本番サイト・ホストおよびスタンバイ・サイト・ホストのDNSエントリ
WEBHOST1.EXAMPLE.COM IN A 172.16.2.111 WEBHOST2.EXAMPLE.COM IN A 172.16.2.112 SOAHOST1.EXAMPLE.COM IN A 172.16.2.113 SOAHOST2.EXAMPLE.COM IN A 172.16.2.114 STBYWEB1.EXAMPLE.COM IN A 172.26.2.111 STBYWEB2.EXAMPLE.COM IN A 172.26.2.112 STBYSOA1.EXAMPLE.COM IN A 172.26.2.113 STBYSOA2.EXAMPLE.COM IN A 172.26.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アドレス(172.1.2.111)が返され、ホスト名が完全修飾されていることがわかります。
同様に、スタンバイ・サイトでping webhost1
コマンドを実行すると、適切なIPアドレス(172.2.2.111)が返され、ホスト名が完全修飾されていることがわかります。
Oracle WebLogic管理サーバーをホストしているマシンに障害が発生した際に、リクエストの処理が続行されるようOracle WebLogic管理サーバーを有効にするには、仮想IPアドレスおよび仮想ホスト名が必要です。仮想IPアドレスを使用すると、ドメインの管理サーバーによってサーバー移行が行われます。仮想サーバーは、アプリケーション層内の任意のホスト上でネットワーク・インタフェースにバインドできるように、アプリケーション層内でプロビジョニングされる必要があります。
障害時リカバリ・トポロジでは、本番サイトの仮想IPホスト名がスタンバイ・サイトの対応するピア・システムのIPアドレスに解決可能である必要があります。そのため、本番サイトとスタンバイ・サイトのホスト名を計画することが重要です。プライマリ・サイトからスタンバイ・サイトへのフェイルオーバー後に、スタンバイ・サイトの中間層ホストのホスト名別名がアクティブになります。スタンバイ・サイトの別名を設定する場合、スタンバイ・サイトのホストのホスト名を再構成する必要はありません。
この項では、本番サイトとスタンバイ・サイトでOracle Fusion Middlewareインスタンスを使用する中間層ホストについて、仮想IPホスト名およびホスト名別名を計画する方法を説明します。これは、単一の企業DNSを使用している場合に必要です。
ホスト名の例として、図3-1に示されている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 | ホスト名別名 |
---|---|---|
|
|
なし |
|
|
なし |
|
|
なし |
脚注 1 物理ホスト名の定義の詳細は、第3.1.1.3項および第3.1.1.4項を参照してください。
表3-15に、Oracle SOA Suite EDGデプロイメントのスタンバイ・サイト・ホストに使用する仮想IPアドレス、仮想ホスト名およびホスト名別名を示します。図3-2には、スタンバイ・サイトでOracle SOA Suite EDGデプロイメントに使用する物理ホスト名を示します。図3-2に示されているOracle SOA Suiteのスタンバイ・サイト・ホストについては、表3-15に示されているホスト名別名を定義する必要があります。
表3-15 SOA Suiteのスタンバイ・サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名
仮想IPアドレス | 仮想ホスト名脚注 1 | ホスト名別名 |
---|---|---|
|
|
|
|
|
|
|
|
|
脚注 1 物理ホスト名の定義の詳細は、第3.1.1.3項および第3.1.1.4項を参照してください。
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 | ホスト名別名 |
---|---|---|
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
脚注 1 物理ホスト名の定義の詳細は、第3.1.1.3項および第3.1.1.4項を参照してください。
表3-17に、Oracle WebCenter Portal EDGデプロイメントのスタンバイ・サイト・ホストに使用する仮想IPアドレス、仮想ホスト名およびホスト名別名を示します。スタンバイ・サイトにおけるOracle WebCenter Portal EDGデプロイメントの構成については、図4-4を参照してください。
表3-17 WebCenter Portalのスタンバイ・サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名
仮想IPアドレス | 仮想ホスト名脚注 1 | ホスト名別名 |
---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
脚注 1 物理ホスト名の定義の詳細は、第3.1.1.3項および第3.1.1.4項を参照してください。
Oracle Identity Managementの本番サイト・ホストおよびスタンバイ・サイト・ホストの仮想IPアドレスと仮想ホスト名
表3-18に、Oracle Identity Management EDGデプロイメントの本番サイト・ホストに使用する仮想IPアドレスと仮想ホスト名を示します。本番サイトにおけるOracle Identity Management EDGデプロイメントの構成については、図4-6を参照してください。
表3-18 Identity Managementの本番サイト・ホストの仮想IPアドレスと仮想ホスト名
仮想IPアドレス | 仮想ホスト名脚注 1 | ホスト名別名 |
---|---|---|
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
脚注 1 物理ホスト名の定義の詳細は、第3.1.1.3項および第3.1.1.4項を参照してください。
表3-19に、Oracle Identity Management EDGデプロイメントのスタンバイ・サイト・ホストに使用する仮想IPアドレス、仮想ホスト名およびホスト名別名を示します。スタンバイ・サイトにおけるOracle Identity Management EDGデプロイメントの構成については、図4-6を参照してください。
表3-19 Identity Managementのスタンバイ・サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名
仮想IPアドレス | 仮想ホスト名脚注 1 | ホスト名別名 |
---|---|---|
|
|
ADMINVHN |
|
|
IDMVHN1 |
|
|
IDMVHN2 |
|
|
OIDVHN1 |
|
|
OIDVHN2 |
|
|
OVDVHN1 |
|
|
OVDVHN2 |
|
|
OIFVHN1 |
|
|
OIFVHN2 |
|
|
OAAMVHN1 |
|
|
OAAMVHN2 |
|
|
OAAMVHN1 |
|
|
OAAMVHN2 |
|
|
OIMVHN1 |
|
|
OIMVHN2 |
脚注 1 物理ホスト名の定義の詳細は、第3.1.1.3項および第3.1.1.4項を参照してください。
管理サーバー、Oracle Identity Manager管理対象サーバーおよびSOA管理対象サーバーには、各サイトでのプロビジョニング用に浮動IPアドレスが必要です(表3-7)。浮動IPアドレスは、本番サイトとスタンバイ・サイトの両方で、同じ仮想ホスト名でプロビジョニングしてください。
表3-20 浮動IPアドレス
物理ホスト名 | 仮想ホスト名 | 浮動IP |
---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
注意: 詳細は、『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 | ホスト名別名 |
---|---|---|
|
|
なし |
|
|
なし |
|
|
なし |
脚注 1 物理ホスト名の定義の詳細は、第3.1.1.3項および第3.1.1.4項を参照してください。
表3-22に、Oracle Portal、Forms、ReportsおよびDiscovererエンタープライズ・デプロイメントのスタンバイ・サイト・ホストに使用する仮想IPアドレス、仮想ホスト名およびホスト名別名を示します。本番サイトにおけるOracle Portalエンタープライズ・デプロイメントの構成については、図4-9を参照してください。本番サイトにおけるOracle Forms、ReportsおよびDiscovererエンタープライズ・デプロイメントの構成については、図4-10を参照してください。
表3-22 Oracle Portal、Forms、ReportsおよびDiscovererのスタンバイ・サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名
仮想IPアドレス | 仮想ホスト名脚注 1 | ホスト名別名 |
---|---|---|
|
|
ADMINVHN |
|
|
APPVHN1 |
|
|
APPVHN2 |
脚注 1 物理ホスト名の定義の詳細は、第3.1.1.3項および第3.1.1.4項を参照してください。
表3-2、表3-4、表3-6および表3-8に示されているホスト名別名は、スタンバイ・サイトではローカルに正しいIPアドレスへと解決されます。、第3.1.1.1項では、Oracle Fusion Middleware障害時リカバリ・トポロジでホスト名解決を構成する2通りの方法について説明しています。
Oracle WebCenter Contentの本番サイト・ホストおよびスタンバイ・サイト・ホストの仮想IPアドレスと仮想ホスト名
表3-23に、Oracle WebCenter Content EDGデプロイメントの本番サイト・ホストに使用する仮想IPアドレスと仮想ホスト名を示します。本番サイトにおけるOracle WebCenter Content EDGデプロイメントの構成については、図4-11を参照してください。
表3-23 Oracle WebCenter Content Managerの本番サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名
仮想IPアドレス | 仮想ホスト名脚注 1 | ホスト名別名 |
---|---|---|
|
|
なし |
|
|
なし |
|
|
なし |
脚注 1 物理ホスト名の定義の詳細は、第3.1.1.3項および第3.1.1.4項を参照してください。
表3-24に、Oracle WebCenter Content EDGデプロイメントのスタンバイ・サイト・ホストに使用する仮想IPアドレス、仮想ホスト名およびホスト名別名を示します。スタンバイ・サイトにおけるOracle WebCenter Content EDGデプロイメントの構成については、図4-11を参照してください。
表3-24 Oracle WebCenter Contentのスタンバイ・サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名
仮想IPアドレス | 仮想ホスト名脚注 1 | ホスト名別名 |
---|---|---|
|
|
|
|
|
|
|
|
|
脚注 1 物理ホスト名の定義の詳細は、第3.1.1.3項および第3.1.1.4項を参照してください。
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 | ホスト名別名 |
---|---|---|
|
|
なし |
|
|
なし |
|
|
なし |
脚注 1 物理ホスト名の定義の詳細は、第3.1.1.3項および第3.1.1.4項を参照してください。
表3-26に、Oracle Business Intelligence EDGデプロイメントのスタンバイ・サイト・ホストに使用する仮想IPアドレス、仮想ホスト名およびホスト名別名を示します。スタンバイ・サイトにおけるOracle Business Intelligence EDGデプロイメントの構成については、図4-11を参照してください。
表3-26 Oracle Business Intelligenceのスタンバイ・サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名
仮想IPアドレス | 仮想ホスト名脚注 1 | ホスト名別名 |
---|---|---|
|
|
|
|
|
|
|
|
|
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アドレスを保持する機能がある必要があります。
様々な種類のネットワーク・トラフィックや監視に対応するように、仮想サーバーや関連するポートをロード・バランサに構成する必要があります。これらは、実際のホストおよびポートに対して適切に構成し、サービスが継続されるようにする必要があります。また、可用性を確保するために、実際のホストおよびポートを監視して、サービスが停止した場合はできるだけ早く、それらのホストやポートへのトラフィックが停止されるようにロード・バランサを構成する必要があります。これによって、特定の仮想ホストの着信トラフィックが他の層の使用不可のサービスに送信されることがなくなります。
外部トラフィックと内部トラフィックを処理する場合は、ロード・バランサを2つ使用することをお薦めします。このようなトポロジでは、一方のロード・バランサを外部HTTPトラフィック用に設定し、もう一方のロード・バランサを内部LDAPトラフィック用に設定します。様々な理由から、デプロイメントで使用されるロード・バランサ・デバイスが1つになる場合があります。このような構成もサポートされていますが、これに伴うセキュリティへの影響を考慮する必要があります。その構成が適切であることがわかったら、様々なDMZ間のトラフィックを許可するように、関連するファイアウォール・ポートを開いてください。いずれの場合も、特定のロード・バランサ・デバイスをフォルト・トレラント・モードでデプロイすることを強くお薦めします。
ロード・バランサに定義された一部の仮想サーバーは、コンポーネント間の通信に使用されます。これらの仮想サーバーは内部トラフィック用に使用され、企業の内部DNSに定義されます。ホスト名の解決に単一のグローバルDNSサーバーを使用する場合は、これらの仮想サーバーに別名を作成することを強くお薦めします。
個別のDNSサーバーを使用してホスト名を解決する場合は、別名を作成する必要はありません。
各種Oracle Fusion Middleware製品に必要な仮想サーバーを表3-27から表3-38に示します。
表3-27 Oracle SOA Suiteの本番サイトの仮想サーバー
コンポーネント | アクセス | 仮想サーバー名 | 別名 |
---|---|---|---|
Oracle SOA |
外部 |
|
なし |
Oracle SOA |
内部 |
|
なし |
管理コンソール |
内部 |
|
なし |
表3-28 Oracle SOA Suiteのスタンバイ・サイトの仮想サーバー
コンポーネント | アクセス | 仮想サーバー名 | 仮想サーバー名別名 |
---|---|---|---|
Oracle SOA |
外部 |
|
なし |
Oracle SOA |
内部 |
|
|
管理コンソール |
内部 |
|
なし |
表3-29 Oracle WebCenter Portalの本番サイトの仮想サーバー
コンポーネント | アクセス | 仮想サーバー名 | 別名 |
---|---|---|---|
Oracle WebCenter Portal |
外部 |
|
なし |
Oracle WebCenter Portal |
内部 |
|
なし |
Oracle SOA Internal |
内部 |
|
なし |
管理コンソール |
内部 |
|
なし |
脚注1 SOAドメインを使用して拡張する場合に必要です。
表3-30 Oracle WebCenter Portal Suiteのスタンバイ・サイトの仮想サーバー
コンポーネント | アクセス | 仮想サーバー名 | 仮想サーバー名別名 |
---|---|---|---|
Oracle WebCenter Portal |
外部 |
|
なし |
Oracle WebCenter Portal |
内部 |
|
|
Oracle SOA Internal |
内部 |
|
|
管理コンソール |
内部 |
|
なし |
脚注1 SOAドメインを使用して拡張する場合に必要です。
表3-31 Oracle Identity Managementの本番サイトの仮想サーバー
コンポーネント | アクセス | 仮想サーバー名 | 別名 |
---|---|---|---|
Oracle Internet Directory |
外部 |
|
なし |
Oracle Internet Directory |
内部 |
|
なし |
Oracle Virtual Directory |
外部 |
|
なし |
Oracle Virtual Directory |
内部 |
|
なし |
Oracle Identity Federation |
外部 |
|
なし |
Oracle Identity Federation |
内部 |
|
なし |
Oracle Identity Manager |
外部 |
|
なし |
Oracle Identity Manager |
内部 |
|
なし |
シングル・サインオン |
外部 |
|
なし |
シングル・サインオン |
内部 |
|
なし |
管理コンソール |
内部 |
|
なし |
表3-32 Oracle Identity Managementのスタンバイ・サイトの仮想サーバー
コンポーネント | アクセス | 仮想サーバー名 | 別名 |
---|---|---|---|
Oracle Internet Directory |
外部 |
|
なし |
Oracle Internet Directory |
内部 |
|
|
Oracle Virtual Directory |
外部 |
|
なし |
Oracle Virtual Directory |
内部 |
|
|
Oracle Identity Federation |
外部 |
|
なし |
Oracle Identity Federation |
内部 |
|
|
Oracle Identity Manager |
外部 |
|
なし |
Oracle Identity Manager |
内部 |
|
|
シングル・サインオン |
外部 |
|
なし |
シングル・サインオン |
内部 |
|
|
管理コンソール |
内部 |
|
なし |
表3-33 Oracle Portal、Forms、ReportsおよびDiscovererの本番サイトの仮想サーバー
コンポーネント | アクセス | 仮想サーバー名 | 別名 |
---|---|---|---|
Oracle Portal |
外部 |
|
なし |
Oracle Portal |
内部 |
|
なし |
Oracle FormsおよびOracle Reports |
外部 |
|
なし |
Oracle FormsおよびOracle Reports |
内部 |
|
なし |
Discoverer |
外部 |
|
なし |
Discoverer |
内部 |
|
なし |
管理コンソール |
内部 |
|
なし |
表3-34 Oracle Portal、Reports、FormsおよびDiscovererのスタンバイ・サイトの仮想サーバー
コンポーネント | アクセス | 仮想サーバー名 | 仮想サーバー名別名 |
---|---|---|---|
Oracle Portal |
外部 |
|
なし |
Oracle Portal |
内部 |
|
|
Oracle FormsおよびOracle Reports |
外部 |
|
なし |
Oracle FormsおよびOracle Reports |
内部 |
|
|
Discoverer |
外部 |
|
なし |
Discoverer |
内部 |
|
|
管理コンソール |
内部 |
|
なし |
表3-35 Oracle WebCenter Contentの本番サイトの仮想サーバー
コンポーネント | アクセス | 仮想サーバー名 | 別名 |
---|---|---|---|
Oracle WebCenter Content |
外部 |
|
なし |
Oracle WebCenter Content |
内部 |
|
なし |
Oracle SOA Internal |
内部 |
|
なし |
管理コンソール |
内部 |
|
なし |
脚注1 SOAドメインを使用して拡張する場合に必要です。
表3-36 Oracle WebCenter Contentのスタンバイ・サイトの仮想サーバー
コンポーネント | アクセス | 仮想サーバー名 | 仮想サーバー名別名 |
---|---|---|---|
Oracle Enterprise Content Management |
外部 |
|
なし |
Oracle Enterprise Content Management |
内部 |
|
|
Oracle SOA Internal |
内部 |
|
|
管理コンソール |
内部 |
|
なし |
脚注 1 Oracle SOAドメインを使用して拡張する場合に必要です。
表3-37 Oracle Business Intelligenceの本番サイトの仮想サーバー
コンポーネント | アクセス | 仮想サーバー名 | 別名 |
---|---|---|---|
Oracle Business Intelligence |
外部 |
|
なし |
Oracle Business Intelligence |
内部 |
|
なし |
Oracle Access Manager Internal |
内部 |
|
なし |
管理コンソール |
内部 |
|
なし |
脚注 1 Oracle Access Managerドメインを使用して拡張する場合に必要です。
表3-38 Oracle Business Intelligenceのスタンバイ・サイトの仮想サーバー
コンポーネント | アクセス | 仮想サーバー名 | 仮想サーバー名別名 |
---|---|---|---|
Oracle Business Intelligence |
外部 |
|
なし |
Oracle Business Intelligence |
内部 |
|
|
Oracle Access Manager Internal |
内部 |
|
|
管理コンソール |
内部 |
|
なし |
脚注 1 Oracle Access Managerドメインを使用して拡張する場合に必要です。
サイトのスイッチオーバーまたはフェイルオーバーを実行した場合、クライアント・リクエストは本番ロールを引き継ぐ新しいサイトに透過的にリダイレクトされる必要があります。本番サイトのエントリ・ポイントにクライアント・リクエストを送信するには、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ホームまたはWebLogicホームが、異なるノードの複数のサーバーによって共有されている場合、これらのノードのOracleインベントリとMiddlewareホーム・リストを常に最新の状態にして、インストールとパッチ・アプリケーションの整合性を確保することをお薦めします。
ノードでインベントリ・ファイルを更新して、これに共有ストレージのインストールを関連付けるには、ORACLE_HOME
/oui/bin/attachHome.sh
を使用します。
Middlewareホームの一覧を更新してWebLogicホームを追加または削除するには、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 Databaseの設定に関する推奨事項と考慮事項を説明します。
使用するトポロジの要件に応じて、本番サイトとスタンバイ・サイトの両方にOracle Real Application Cluster (Oracle RAC)データベースを作成することをお薦めします。
メタデータ・リポジトリを実行するデータベースについては、障害時保護テクノロジとして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
使用するOracle Data Guard構成は、データベースのデータ損失要件に加えて、REDO生成と比較した場合の使用可能な帯域幅や待機時間など、ネットワークに関する考慮事項に基づいて決定する必要があります。Oracle Data Guard構成を設定する前に、こうした情報が正しく特定されていることを確認してください。
詳細は、『Oracle Data Guard概念および管理』、および関連事項として次のURLにあるOracleの最大可用性アーキテクチャに関する情報を参照してください。
http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm
同期REDO転送によってレスポンス時間やスループットに影響が生じる可能性があるため、必ず十分な帯域幅を備えた、待機時間の少ないネットワークを構成してください。
スタンバイ・サイトのデータベースのLOG_ARCHIVE_DEST_n
パラメータにSYNC
またはASYNC
属性を指定しておく必要があります。属性を指定しなかった場合は、デフォルトでASYNC
に設定されます。
スタンバイ・サイトのデータベースは、管理リカバリ・モードである必要があります。これによって、スタンバイ・サイトのデータベースは常にメディア・リカバリの状態になります。管理リカバリ・モードを使用すると、フェイルオーバー時間を短縮できます。
本番サイトとスタンバイ・サイトのtnsnames.ora
ファイルに、本番サイトとスタンバイ・サイト両方のデータベースをエントリしておく必要があります。
Oracle Data Guardでは、中間層の同期が実行される場合はいつでも、必ず手動によるデータベース同期を実行することをお薦めします。これは特に、メタデータ・リポジトリに構成データを格納するコンポーネントにとって重要です。
本番サイトとスタンバイ・サイトの両方でデータベース・ホスト名の別名を設定することを強くお薦めします。これによって、シームレスなスイッチオーバー、スイッチバックおよびフェイルオーバーが実現します。
どちらかのサイトのデータベースの1つがOracle RACデータベースである場合、ピア・サイトの単一のインスタンス・データベースにinstance_name
の値と同じ値がある必要があります。
注意:
|
Oracle Data Guardでは本番データベースとスタンバイ・データベースが同期されるため、本番データベースとスタンバイ・データベースが相互を参照できる必要があります。
Oracle Data Guardでは、tnsnames.ora
ファイル・エントリを使用して、本番データベースとスタンバイ・データベースにリクエストを送信します。そのため、本番データベースとスタンバイ・データベースのエントリをtnsnames.ora
ファイルに作成する必要があります。Oracle Data Guardでtnsnames.ora
ファイルを使用する方法の詳細は、Oracle Databaseのドキュメント・セットにある『Oracle Data Guard概念および管理』を参照してください。
中間層の構成データをOracle Database・リポジトリに格納するOracle Fusion Middlewareコンポーネントについては、中間層の同期が実行された場合は必ず、Oracle Data Guardを使用して、データベースを手動で強制的に同期してください。alter system archive log all
というSQL文を使用して、ログを切り替えます。これにより、本番サイトとスタンバイ・サイトのデータベースの同期が強制的に行われます。
例3-9に、本番サイトのデータベースとスタンバイ・サイトのデータベースを強制的に同期する場合に使用するSQL文を示します。
必要に応じて、本番サイトとスタンバイ・サイトのデータベースにデータベース・ホスト名の別名を設定できます。この別名は、DNSまたはデータベース・インスタンスを実行する各ノードの/etc/hosts
ファイルで定義する必要があります。
障害時リカバリ環境では、アクティブに接続を受け取るサイトが本番サイトになります。フェイルオーバー操作またはスイッチオーバー操作が正常に完了すると、スタンバイ・サイトが新しい本番サイトになります。
この項の例では、custdbhost1およびstbycustdbhost1という名前のデータベース・ホストの別名を定義します。表3-39に、別名を定義する前のデータベース・ホスト名とデータベース接続文字列を示します。
表3-39 データベース・ホスト名と接続文字列
サイト | データベース・ホスト名 | データベース接続文字列 |
---|---|---|
本番 |
|
|
スタンバイ |
|
|
この例では、本番サイトのすべてのデータベース接続文字列にcustdbhost1.example.com:1521:orcl
という形式を使用します。フェイルオーバー操作またはスイッチオーバー操作の後、この接続文字列をstbycustdbhost1.example.com:1521:orcl
に変更する必要があります。ただし、表3-40に示されているように、データベース・ホスト名にproddb1
という別名を作成することで、接続文字列を手動で変更しなくて済むようにすることができます。これにより、シームレスなフェイルオーバーとスイッチオーバーが実現します。
表3-40 データベース・ホストの別名の指定
サイト | データベース・ホスト名 | 別名 | データベース接続文字列 |
---|---|---|---|
本番 |
|
|
|
スタンバイ |
|
|
|
この例では、本番サイトのデータベース・ホスト名とスタンバイ・サイトのデータベース・ホスト名にproddb1.example.com
という別名を作成します。また、本番サイトとスタンバイ・サイトの接続文字列にproddb1.example.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.example.com proddb1 custdbhost1.example.com custdbhost1
また、スタンバイ・サイトの/etc/hosts
ファイルで、ホストstbycustdbhost1のエントリは次のようになることを確認してください。
140.87.25.40 proddb1.example.com proddb1 stbycustdbhost1.example.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 Portalについては、『Oracle Fusion Middleware管理者ガイド』のOracle WebCenter Portalのバックアップおよびリカバリの推奨事項に関する説明を参照してください。
Oracle Identity Managementについては、『Oracle Fusion Middleware管理者ガイド』のOracle Identity Managementのバックアップおよびリカバリの推奨事項に関する説明を参照してください。
Oracle WebLogic Serverについては、『Oracle Fusion Middleware管理者ガイド』のOracle JRFインストールのバックアップおよびリカバリの推奨事項に関する説明を参照してください。
Web層については、『Oracle Fusion Middleware管理者ガイド』のWeb層インストールのバックアップおよびリカバリの推奨事項に関する説明を参照してください。
Oracle WebCenter Contentについては、『Oracle Fusion Middleware管理者ガイド』のOracle WebCenter Contentのバックアップおよびリカバリに関する推奨事項の項を参照してください。
Oracle Business Intelligenceについては、『Oracle Fusion Middleware管理者ガイド』のOracle Business Intelligenceのバックアップおよびリカバリの推奨事項に関する説明を参照してください。
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ホーム・ディレクトリを選択できます。
サイトを最初から設計して作成する方が、この章で説明した設計要件に合せて既存のサイトを変更するよりも簡単です。
本番サイトのホストのOracle Fusion Middlewareインストールに、スタンバイ・サイトのホストで使用するポートと競合しないポートを割り当てることができます。
既存の本番サイトとスタンバイ・サイト間におけるポートの競合を確認して解決するよりも、この方が簡単です。
この項では、次のトポロジの設計に関する考慮事項について説明します。
対称トポロジ
非対称トポロジ
対称トポロジは、Oracle Fusion Middleware障害時リカバリ構成の一つで、本番サイトとスタンバイ・サイト間で各階層がまったく同じように構成されます。対称トポロジでは、本番サイトとスタンバイ・サイトで同じ数のホスト、ロード・バランサ、インスタンスおよびアプリケーションを使用します。また、両方のサイトで同じポートが使用されます。システムはまったく同じように構成され、アプリケーションは同じデータにアクセスします。このマニュアルでは、エンタープライズ構成用に、Oracle Fusion Middleware障害時リカバリで対称トポロジを設定する方法について説明します。
非対称トポロジは、Oracle Fusion Middleware障害時リカバリ構成の一つで、本番サイトとスタンバイ・サイト間で各階層の構成に相違があります。非対称トポロジでは、スタンバイ・サイトで使用するハードウェアの数が少ない場合があります(本番サイトには4つのホストと4つのOracle Fusion Middlewareインスタンスがあるのに対して、スタンバイ・サイトには2つのホストと4つのOracle Fusion Middlewareインスタンスがある場合など)。または、別の非対称トポロジでは、スタンバイ・サイトで使用するOracle Fusion Middlewareインスタンスの数が少ない場合があります(本番サイトには4つのOracle Fusion Middlewareインスタンスがあるのに対して、スタンバイ・サイトには2つのOracle Fusion Middlewareインスタンスがある場合など)。別の非対称トポロジでは、データベースのための異なる構成が含まれている場合があります(本番サイトでOracle Real Application Clusters (Oracle RAC)データベースを、スタンバイ・サイトで単一のインスタンス・データベースを使用する場合など)。