| Oracle® Fusion Middlewareディザスタ・リカバリ・ガイド 12c (12.1.3) E59392-01 |
|
 前 |
 次 |
この章では、エンタープライズ・デプロイメントにおけるOracle Fusion Middleware障害時リカバリ・ソリューションに関する設計上の考慮事項について説明します。
含まれる内容は、次のとおりです。
|
注意:
|
この章では、LinuxおよびUNIXオペレーティング・システムでOracle Fusion Middleware 12c障害時リカバリの本番サイトとスタンバイ・サイトを設定する際の詳細な手順を説明します。エンタープライズ・デプロイメントのOracle Fusion Middleware 12c障害時リカバリ・ソリューションを設定する方法の例では、主に、Oracle SOA Suiteエンタープライズ・デプロイメント(図3-1を参照)を使用します。Oracle SOA Suiteエンタープライズ・トポロジの障害時リカバリを設定する方法を理解したら、この章に記載されているその他の12cエンタープライズ・デプロイメントに関する情報を参照して、それらのデプロイメントの障害時リカバリを設定することもできます。
図3-1 Oracle Fusion Middleware障害時リカバリの本番サイトとスタンバイ・サイトで使用するデプロイメント
図3-1は、Oracle SOA、Business Process Management (BPM)およびOracle Service Busエンタープライズ・デプロイメント・トポロジのダイアグラムを示しています。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という形式です。 |
表3-9に、『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』(EDG)のデプロイメントの本番サイト・ホストに使用するIPアドレスと物理ホスト名を示します。本番サイトにおけるOracle SOA Suite EDGデプロイメントの構成については、図3-1を参照してください。
表3-1 SOA Suiteの本番サイト・ホストのIPアドレスと物理ホスト名
| IPアドレス | 物理ホスト名脚注1 | ホスト名別名 |
|---|---|---|
|
|
|
なし |
|
|
|
なし |
|
|
|
なし |
|
|
|
なし |
脚注 1 物理ホスト名の定義の詳細は、第3.1.1.1.3項および第3.1.1.1.4項を参照してください。
図3-2には、スタンバイ・サイトでOracle SOA Suite EDGデプロイメントに使用する物理ホスト名を示します。
|
注意: 個別のDNSサーバーを使用してホスト名を解決する場合、本番サイトのホストとスタンバイ・サイトのホストに同じ物理ホスト名を使用できるので、ホスト名別名をスタンバイ・サイトのホストで定義する必要はありません。個別のDNSサーバーを使用してホスト名を解決する方法の詳細は、第3.1.1.1.3項を参照してください。 |
図3-2 Oracle SOA Suiteデプロイメントのスタンバイ・サイトで使用する物理ホスト名
管理サーバー、Oracle Identity Manager管理対象サーバーおよびSOA管理対象サーバーには、各サイトでのプロビジョニング用に浮動IPアドレスが必要です(表3-2)。浮動IPアドレスは、本番サイトとスタンバイ・サイトの両方で、同じ仮想ホスト名でプロビジョニングしてください。
表3-2 浮動IPアドレス
| 物理ホスト名 | 仮想ホスト名 | 浮動IP |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
注意: 詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。 |
ホスト名の解決は、通信のためにホスト名を適切なIPアドレスに解決するプロセスです。ホスト名の解決は、次のいずれかの方法で構成できます。
ローカルでのホスト名の解決
ローカルでのホスト名の解決では、各ホストの/etc/hostsファイルで指定したホスト名とIPアドレスのマッピングが使用されます。
/etc/hostsファイルを使用してローカルでホスト名のファイル解決を実装する方法の詳細は、第3.1.1.1.2項を参照してください。
DNSを使用したホスト名の解決
DNSサーバーは、IPネットワークでDNSによる名前解決を提供する専用サーバーまたはサービスです。
DNSサーバーのホスト名解決を実装する2つの方法の詳細は、第3.1.1.1.3項および第3.1.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.16.2.111)が返され、ホスト名が完全修飾されていることがわかります。
同様に、例3-4に示されている静的IPアドレス指定と/etc/hostsファイル・エントリを使用して構成したシステムの場合、スタンバイ・サイトでping webhost1コマンドを実行すると、適切なIPアドレス(172.26.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.16.2.111)が返され、ホスト名が完全修飾されていることがわかります。
同様に、例3-6に示されているスタンバイ・サイトのDNSエントリで構成したシステムの場合、スタンバイ・サイトでping webhost1コマンドを実行すると、適切なIPアドレス(172.26.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.16.2.111)が返され、ホスト名が完全修飾されていることがわかります。
同様に、スタンバイ・サイトでping webhost1コマンドを実行すると、適切なIPアドレス(172.26.2.111)が返され、ホスト名が完全修飾されていることがわかります。
ホスト名が適切に割り当てられていることを検証します。そのためには、本番サイトの各ホストに接続し、pingコマンドを使用して、ホストが本番サイトの他のホストを特定できることを確認します。
続いて、スタンバイ・サイトの各ホストに接続し、pingコマンドを使用して、ホストがスタンバイ・サイトの他のホストを特定できることを確認します。
Oracle WebLogic管理サーバーをホストしているマシンに障害が発生した際に、リクエストの処理が続行されるようOracle WebLogic管理サーバーを有効にするには、仮想IPアドレスおよび仮想ホスト名が必要です。仮想IPアドレスを使用すると、ドメインの管理サーバーによってサーバー移行が行われます。仮想サーバーは、アプリケーション層内の任意のホスト上でネットワーク・インタフェースにバインドできるように、アプリケーション層内でプロビジョニングされる必要があります。
障害時リカバリ・トポロジでは、本番サイトの仮想IPホスト名がスタンバイ・サイトの対応するピア・システムのIPアドレスに解決可能である必要があります。そのため、本番サイトとスタンバイ・サイトのホスト名を計画することが重要です。プライマリ・サイトからスタンバイ・サイトへのフェイルオーバー後に、スタンバイ・サイトの中間層ホストのホスト名別名がアクティブになります。スタンバイ・サイトの別名を設定する場合、スタンバイ・サイトのホストのホスト名を再構成する必要はありません。
この項では、本番サイトとスタンバイ・サイトでOracle Fusion Middlewareインスタンスを使用する中間層ホストについて、仮想IPホスト名およびホスト名別名を計画する方法を説明します。これは、単一の企業DNSを使用している場合に必要です。
ホスト名の例として、図3-1に示されているOracle SOA Suiteエンタープライズ・デプロイメントを使用します。この項に記載されているホスト名の例は、障害時リカバリの対称サイトを設定することを前提としています(つまり、本番サイトとスタンバイ・サイトのホスト数は同じです)。本番サイトとスタンバイ・サイトの各ホストに他方のサイトのピア・ホストがあります。ピア・ホストは、他方のサイトの対応するホストと同じポートを使用するなど、同様に構成されます。
この後のサブセクションでは、次のエンタープライズ・デプロイメントの障害時リカバリの本番サイトとスタンバイ・サイトで仮想IPアドレスおよびホスト名を設定する方法を説明します。
Oracle SOA Suiteの本番サイト・ホストおよびスタンバイ・サイト・ホストの仮想IPアドレスと仮想ホスト名
表3-3に、Oracle SOA Suite EDGデプロイメントの本番サイト・ホストに使用する仮想IPアドレスと仮想ホスト名を示します。本番サイトにおけるOracle SOA Suite EDGデプロイメントの構成については、図3-1を参照してください。
表3-3 SOA Suiteの本番サイト・ホストの仮想IPアドレスと仮想ホスト名
| 仮想IPアドレス | 仮想ホスト名脚注 1 | ホスト名別名 |
|---|---|---|
|
|
|
なし |
|
|
|
なし |
|
|
|
なし |
脚注 1 物理ホスト名の定義の詳細は、第3.1.1.1.3項および第3.1.1.1.4項を参照してください。
表3-4に、Oracle SOA Suite EDGデプロイメントのスタンバイ・サイト・ホストに使用する仮想IPアドレス、仮想ホスト名およびホスト名別名を示します。図3-2には、スタンバイ・サイトでOracle SOA Suite EDGデプロイメントに使用する物理ホスト名を示します。図3-2に示されているOracle SOA Suiteのスタンバイ・サイト・ホストについては、表3-4に示されているホスト名別名を定義する必要があります。
|
注意: 個別のDNSサーバーを使用してホスト名を解決する場合、本番サイトのホストとスタンバイ・サイトのホストに同じ仮想IPアドレスおよび仮想ホスト名を使用できるため、ホスト名別名を定義する必要はありません。 個別のDNSサーバーを使用してホスト名を解決する方法の詳細は、第3.1.1.1.3項を参照してください。 |
表3-4 SOA Suiteのスタンバイ・サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名
| 仮想IPアドレス | 仮想ホスト名脚注 1 | ホスト名別名 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
脚注 1 物理ホスト名の定義の詳細は、第3.1.1.1.3項および第3.1.1.1.4項を参照してください。
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サーバーを使用してホスト名を解決する場合は、別名を作成する必要はありません。
トポロジで直接使用されている(つまり、JMXクライアントやRMIクライアントの場合のようにフロントエンド・ロード・バランサを使用していない)サーバーにアクセスするシステムは、異なるOracle WebLogic Serverインスタンスで使用されるリスニング・アドレスを認識する必要があります。適切なホスト名解決をクライアントに提供して、サーバーでリスニング・アドレスとして使用されるホスト名別名が正しく解決されるようにする必要があります。これは、Oracle JDeveloperデプロイメントにも適用されます。デプロイメントを成功させるには、Oracle Jdeveloperをホストしているクライアントが、SOAHOSTxおよびSOAVHNx別名を適切なIPアドレスにマップする必要があります。
サイトのスイッチオーバーまたはフェイルオーバーを実行した場合、クライアント・リクエストは本番ロールを引き継ぐ新しいサイトに透過的にリダイレクトされる必要があります。本番サイトのエントリ・ポイントにクライアント・リクエストを送信するには、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コンポーネントは相互に依存するため、トポロジ内のコンポーネントが同期されていることが重要です。これは、ボリュームとコンシステンシー・グループを設計する際の重要な考慮事項です。アーティファクトの中には静的なものもあれば、動的なものもあります。
静的アーティファクト
静的アーティファクトは、頻繁には変更されないファイルやディレクトリです。次のようなものがあります。
ホーム: Oracleホームは通常、OracleホームとOracle WebLogic Serverホームで構成されます。
Oracleインベントリ: これには、/etcディレクトリにある、oraInst.locおよびoratabファイルが含まれます。
BEAホームの一覧: UNIXの場合、user_home/bea/beahomelistにあります。
動的またはランタイム・アーティファクト
動的またはランタイム・アーティファクトは、頻繁に変更されるファイルです。ランタイム・アーティファクトには、次のものが含まれています。
ドメイン・ホーム: 管理サーバーおよび管理対象サーバーのドメイン・ディレクトリ。
Oracleインスタンス: Oracleインスタンスのホーム・ディレクトリ。
.earファイルや.warファイルなどのアプリケーション・アーティファクト。
MDSリポジトリなどのデータベース・アーティファクト。
Oracle Fusion Middlewareで使用されるデータベース・メタデータ・リポジトリ。
JMSプロバイダやトランザクション・ログなどの永続ストア。
デプロイメント・プラン: ファイル・アダプタやJMSアダプタなどのテクノロジ・アダプタの更新に使用されます。これらは、アーティファクトがデプロイされるクラスタ内のすべてのノードにアクセスできる場所に保存する必要があります。
Oracle Fusion Middlewareでは、1つのバイナリ・インストールから複数の管理対象サーバーを作成できます。そのため、共有ストレージの1箇所にバイナリ・ファイルをインストールして、異なるノードのサーバーでそのインストールを再利用できます。ただし、最大限の可用性を確保するには、冗長バイナリ・インストールを使用することをお薦めします。
OracleホームまたはWebLogicホームが、異なるノードの複数のサーバーによって共有されている場合、これらのノードのOracleインベントリとOracleホーム・リストを常に最新の状態にして、インストールとパッチ・アプリケーションの整合性を確保することをお薦めします。
ノードでインベントリ・ファイルを更新して、これに共有ストレージのインストールを関連付けるには、ORACLE_HOME/oui/bin/attachHome.shを使用します。
Oracleホームの一覧を更新して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-7に、別名を定義する前のデータベース・ホスト名とデータベース接続文字列を示します。
表3-7 データベース・ホスト名と接続文字列
| サイト | データベース・ホスト名 | データベース接続文字列 |
|---|---|---|
|
本番 |
|
|
|
スタンバイ |
|
|
この例では、本番サイトのすべてのデータベース接続文字列にcustdbhost1.example.com:1521:orclという形式を使用します。フェイルオーバー操作またはスイッチオーバー操作の後、この接続文字列をstbycustdbhost1.example.com:1521:orclに変更する必要があります。ただし、表3-8に示されているように、データベース・ホスト名にproddb1という別名を作成することで、接続文字列を手動で変更しなくて済むようにすることができます。これにより、シームレスなフェイルオーバーとスイッチオーバーが実現します。
表3-8 データベース・ホストの別名の指定
| サイト | データベース・ホスト名 | 別名 | データベース接続文字列 |
|---|---|---|---|
|
本番 |
|
|
|
|
スタンバイ |
|
|
|
この例では、本番サイトのデータベース・ホスト名とスタンバイ・サイトのデータベース・ホスト名に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管理者ガイド』のバックアップおよびリカバリの概要に関する項を参照してください。
Web層については、『Oracle Fusion Middleware管理者ガイド』のバックアップおよびリカバリの概要に関する項を参照してください。
この項では、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)データベースを、スタンバイ・サイトで単一のインスタンス・データベースを使用する場合など)。
