| Oracle® Fusion Middlewareディザスタ・リカバリ・ガイド 12c (12.2.1.2) E82708-02 |
|
 前 |
 次 |
エンタープライズ・デプロイメントにOracle Fusion Middleware障害時リカバリ・ソリューションを適合させる場合に留意する設計上の考慮事項について説明します
この章では、LinuxおよびUNIXオペレーティング・システムでOracle Fusion Middleware障害時リカバリの本番サイトとスタンバイ・サイトを設定する方法に関する手順を説明します。エンタープライズ・デプロイメントのOracle Fusion Middleware障害時リカバリ・ソリューションを設定する方法の例では、Oracle SOA Suiteエンタープライズ・デプロイメント(図3-1を参照)を使用します。Oracle SOA Suiteエンタープライズ・トポロジの障害時リカバリを設定する方法を理解したら、この情報を使用して他のエンタープライズ・デプロイメントの障害時リカバリも設定します。
注意:
スイッチオーバーやフェイルオーバーなどの障害時リカバリ操作は、Oracle Site Guardを使用して自動化できます。製品の詳細は、Oracle Site Guard管理者ガイドを参照してください。
エンタープライズ・デプロイメントでのOracle SOA Suiteコンポーネントのインストールおよび構成に関する情報は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』を参照してください。
エラーに関する更新情報は、Oracle Fusion Middleware Oracle Fusion Middleware Infrastructureリリース・ノートを参照してください。
注意:
Oracle Fusion Middleware障害時リカバリの対称トポロジでは、本番サイトとスタンバイ・サイトの両方で、図3-1に示されているOracle SOA Suiteエンタープライズ・デプロイメントを使用しています。図3-1は、一方のサイトのみのデプロイメントを示しています。この図では、デプロイメントの詳細をわかりやすくするために、両方のサイトのデプロイメントを1つの図に示していません。
図1-1に、Oracle Fusion Middleware障害時リカバリの本番サイトおよびスタンバイ・サイトを示しています。
図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ホームの名前とディレクトリ・パスが本番サイトとスタンバイ・サイトで同じである必要があります。
ポート番号
ポート番号は、リスナーによってリクエストのルーティングに使用されます。ポート番号は構成に保存され、本番サイトのホストとスタンバイ・サイトのピア・ホストで同じである必要があります。
本番サイトとスタンバイ・サイトのホスト間におけるポートの競合を確認する方法については、「既存のサイトを基にした設計」を参照してください。
セキュリティ
本番サイトとスタンバイ・サイトの両方に同じユーザー・アカウントが必要です。また、本番サイトとスタンバイ・サイトで、ファイル・システム、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.255に解決されるホスト名SOAHOST1.EXAMPLE.COMを使用します。
次の項では、障害時リカバリの本番サイトとスタンバイ・サイトでホスト名を設定する方法を説明します。
注意:
示されている例では、最初の本番サイトのホストのIPアドレスは172.16.x.xという形式で、最初のスタンバイ・サイトのホストのIPアドレスは172.26.x.xという形式です。
Oracle SOA Suiteの本番サイトおよびスタンバイ・サイトについて確認します。
表3-9に、『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』(EDG)のデプロイメントの本番サイト・ホストに使用するIPアドレスと物理ホスト名を示します。本番サイトにおけるOracle SOA Suite EDGデプロイメントの構成については、図3-1を参照してください。
表3-1 SOA Suiteの本番サイト・ホストのIPアドレスと物理ホスト名
| IPアドレス | 物理ホスト名 | ホスト名別名 |
|---|---|---|
|
|
なし |
|
|
なし |
|
|
なし |
|
|
なし |
図3-2には、スタンバイ・サイトでOracle SOA Suite EDGデプロイメントに使用する物理ホスト名を示します。
注意:
個別のDNSサーバーを使用してホスト名を解決する場合、本番サイトのホストとスタンバイ・サイトのホストに同じ物理ホスト名を使用できるので、ホスト名別名をスタンバイ・サイトのホストで定義する必要はありません。個別のDNSサーバーを使用してホスト名を解決する方法の詳細は、 「個別のDNSサーバーを使用したホスト名の解決」を参照してください。
図3-2 Oracle SOA Suiteデプロイメントのスタンバイ・サイトで使用する物理ホスト名
管理サーバー、管理対象サーバーおよびSOA管理対象サーバーには、各サイトでのプロビジョニング用に浮動IPアドレスが必要です(表3-2)。浮動IPアドレスは、本番サイトとスタンバイ・サイトの両方で、同じ仮想ホスト名でプロビジョニングしてください。
表3-2 浮動IPアドレス
| 物理ホスト名 | 仮想ホスト名 | 浮動IP |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
次の各トピックで、ホスト名およびテストについて説明します。
/etc/hostsファイルで定義したホスト名とIPのマッピングが使用されます。 pingコマンドを使用して、ホストが本番サイトの他のホストを特定できることを確認します。ホスト名の解決とは、通信のためにホスト名を適切なIPアドレスにマップするということです。
ホスト名の解決は、次のいずれかの方法で構成できます。
ローカルでのホスト名の解決
ローカルでのホスト名の解決では、各ホストの/etc/hostsファイルで指定したホスト名とIPアドレスのマッピングが使用されます。
/etc/hostsファイルを使用してローカルでホスト名のファイル解決を実装する方法の詳細は、「ローカルでのホスト名の解決」を参照してください。
DNSを使用したホスト名の解決
DNSサーバーは、IPネットワークでDNSによる名前解決を提供する専用サーバーまたはサービスです。
DNSサーバーによるホスト名の解決を実装する2通りの方法の詳細は、「個別のDNSサーバーを使用したホスト名の解決」および「グローバル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サーバーを使用したホスト名の解決)を使用することをお薦めします。
次の項に記載されている推奨事項は全般的な推奨事項です。企業で使用しているホスト名解決の標準に合わせて調整できます。
例3-1 ローカルでのホスト名解決を使用する場合の指定
hosts: files dns nis
例3-2 DNSによるホスト名解決を使用する場合の指定
hosts: dns files nis
ローカルでのホスト名の解決では、ホストの/etc/hostsファイルで定義したホスト名とIPのマッピングが使用されます。
障害時リカバリ・トポロジでこの方法を使用してホスト名を解決する場合、次の点を考慮します。
例3-3 本番サイト・ホストの/etc/hostsファイル・エントリの作成
174.0.0.1 localhost.localdomain localhost 172.16.2.111 WEBHOST1.EXAMPLE.COM WEBHOST1 172.16.2.112 WEBHOST2.EXAMPLE.COM WEBHOST2 172.16.2.113 SOAHOST1.EXAMPLE.COM SOAHOST1 172.16.2.114 SOAHOST2.EXAMPLE.COM SOAHOST2
例3-4 スタンバイ・サイト・ホストの/etc/hostsファイル・エントリの作成
176.0.0.1 localhost.localdomain localhost 172.26.2.111 STBYWEB1.EXAMPLE.COM STBYWEB1 WEBHOST1.EXAMPLE.COM WEBHOST1 172.26.2.112 STBYWEB2.EXAMPLE.COM STBYWEB2 WEBHOST2.EXAMPLE.COM WEBHOST2 172.26.2.113 STBYSOA1.EXAMPLE.COM STBYSOA1 SOAHOST1.EXAMPLE.COM SOAHOST1 172.26.2.114 STBYSOA2.EXAMPLE.COM STBYSOA2 SOAHOST2.EXAMPLE.COM SOAHOST2
注意:
本番サイトとスタンバイ・サイトのサブネットは異なります。障害時リカバリ・トポロジで個別のDNSサーバーを使用してホスト名を解決します。
「個別のDNSサーバー」という用語は、本番サイトとスタンバイ・サイトに別のDNSサーバーがある障害時リカバリ・トポロジを表します。障害時リカバリ・トポロジで個別のDNSサーバーを使用してホスト名を解決する場合、次の点を考慮します。
例3-5 個別の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
例3-6 個別のDNSサーバー構成におけるスタンバイ・サイト・ホストのDNSエントリ
WEBHOST1.EXAMPLE.COM IN A 172.26.2.111 WEBHOST2.EXAMPLE.COM IN A 172.26.2.112 SOAHOST1.EXAMPLE.COM IN A 172.26.2.113 SOAHOST2.EXAMPLE.COM IN A 172.26.2.114
障害時リカバリ・トポロジでグローバルDNSサーバーを使用してホスト名を解決します。
「グローバルDNSサーバー」という用語は、本番サイトとスタンバイ・サイト両方に対して1つのDNSサーバーを使用する障害時リカバリ・トポロジを表します。障害時リカバリ・トポロジでグローバルDNSサーバーを使用してホスト名を解決する場合、次のガイドラインを考慮します。
例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
例3-8 グローバルDNSサーバー構成を使用する場合のスタンバイ・サイトの/etc/hostsファイル・エントリ
176.0.0.1 localhost.localdomain localhost 172.26.2.111 STBYWEB1.EXAMPLE.COM WEBHOST1 172.26.2.112 STBYWEB2.EXAMPLE.COM WEBHOST2 172.26.2.113 STBYSOA1.EXAMPLE.COM SOAHOST1 172.26.2.114 STBYSOA2.EXAMPLE.COM SOAHOST2
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アドレス | 仮想ホスト名 | ホスト名別名 |
|---|---|---|
|
|
なし |
|
|
なし |
|
|
なし |
表3-4に、Oracle SOA Suite EDGデプロイメントのスタンバイ・サイト・ホストに使用する仮想IPアドレス、仮想ホスト名およびホスト名別名を示します。図3-2には、スタンバイ・サイトでOracle SOA Suite EDGデプロイメントに使用する物理ホスト名を示します。図3-2に示されているOracle SOA Suiteのスタンバイ・サイト・ホストについては、表3-4に示されているホスト名別名を定義する必要があります。
注意:
個別のDNSサーバーを使用してホスト名を解決する場合、本番サイトのホストとスタンバイ・サイトのホストに同じ仮想IPアドレスおよび仮想ホスト名を使用できるため、ホスト名別名を定義する必要はありません。
個別のDNSサーバーを使用してホスト名を解決する方法の詳細は、 「個別のDNSサーバーを使用したホスト名の解決」を参照してください。
表3-4 SOA Suiteのスタンバイ・サイト・ホストの仮想IPアドレス、仮想ホスト名およびホスト名別名
| 仮想IPアドレス | 仮想ホスト名 | ホスト名別名 |
|---|---|---|
|
|
|
|
|
|
|
|
|
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-5から表3-6に示します。
表3-5 Oracle SOA Suiteの本番サイトの仮想サーバー
| コンポーネント | アクセス | 仮想サーバー名 | 別名 |
|---|---|---|---|
Oracle SOA |
外部 |
|
なし |
Oracle SOA |
内部 |
|
なし |
管理コンソール |
内部 |
|
なし |
表3-6 Oracle SOA Suiteのスタンバイ・サイトの仮想サーバー
| コンポーネント | アクセス | 仮想サーバー名 | 仮想サーバー名別名 |
|---|---|---|---|
Oracle SOA |
外部 |
|
なし |
Oracle SOA |
内部 |
|
|
管理コンソール |
内部 |
|
なし |
トポロジでサーバーに直接アクセスするシステムは、別のOracle WebLogic Serverインスタンスで使用されるリスニング・アドレスを認識している必要があります。
サーバーでリスニング・アドレスとして使用されるホスト名別名が正しく解決されるように、適切なホスト名解決をクライアントに提供する必要があります。これは、Oracle JDeveloperデプロイメントにも適用されます。デプロイメントを成功させるには、Oracle Jdeveloperをホストしているクライアントが、SOAHOSTxおよびSOAVHNx別名を適切なIPアドレスにマップする必要があります。
サイトのスイッチオーバーまたはフェイルオーバーを実行した場合、クライアント・リクエストは本番ロールを引き継ぐ新しいサイトに透過的にリダイレクトされる必要があります。
本番サイトのエントリ・ポイントにクライアント・リクエストを送信するには、DNS解決を使用します。このリダイレクションを実現するには、本番サイトへのリクエストを解決するワイド・エリアDNSをスタンバイ・サイトにスイッチオーバーする必要があります。DNSスイッチオーバーを実行するには、グローバル・ロード・バランサを使用するか、DNS名を手動で変更します。
注意:
ハードウェア・ロード・バランサは、各サイトのフロントエンドとして機能することを前提とします。サポートされているロード・バランサについては、次の場所を参照してください。
この項には次のトピックが含まれます:
グローバル・ロード・バランサを本番サイトとスタンバイ・サイトの前面にデプロイすると、両方のサイトについて、障害検出サービスとパフォーマンスベースのルーティング・リダイレクションが提供されます。
さらに、このロード・バランサは、信頼できるDNSネーム・サーバーと同等の機能を提供できます。
通常の操作時には、本番サイトのロード・バランサの名前とIPのマッピングを使用してグローバル・ロード・バランサを構成できます。DNSスイッチオーバーが必要な場合は、グローバル・ロード・バランサのこのマッピングを変更して、スタンバイ・サイトのロード・バランサのIPにマップします。これにより、本番ロールを引き継いだスタンバイ・サイトにリクエストが送信されるようになります。
DNSスイッチオーバーを使用するこの方法は、サイトのスイッチオーバーおよびフェイルオーバーとして機能します。グローバル・ロード・バランサを使用する利点の1つは、名前とIPの新しいマッピングがほとんど即時に有効になる点です。マイナス面は、グローバル・ロード・バランサに対する追加投資が必要な点です。
DNSスイッチオーバーでは、本番サイトのロード・バランサの名前とIPのマッピングを手動で変更します。
マッピングはスタンバイ・サイトのロード・バランサのIPアドレスにマップするように変更します。スイッチオーバーを実行する手順は次のとおりです。
DNSスイッチオーバーを使用するこの方法は、スイッチオーバー操作またはフェイルオーバー操作として機能します。ステップ2で設定するTTL値は、その時間内にクライアント・リクエストを十分に処理できないような値にする必要があります。TTLを変更する場合、実質的には、アドレス解決のキャッシュ・セマンティックを長い時間から短い時間に変更することになります。キャッシュ時間が短くなるため、DNSリクエストが増加する可能性があります。
JAVA_HOME/jre/lib/security/java.securityファイルのプロパティ(:networkaddress.cache.ttl=60)を変更することにより、JVMを実行しているすべてのアプリケーションに対してグローバルに行うことができます。
アプリケーションの初期化コードのプロパティ(java.security.Security.setProperty("networkaddress.cache.ttl" , "60"))を設定することにより、特定のアプリケーションに対してのみ定義できます。
障害時リカバリ・ソリューション用のストレージを設計する場合、Fusion Middlewareのアーティファクト、ストレージ・レプリケーションおよびファイルベースの永続ストアを考慮します。
この項には次のトピックが含まれます:
通常、特定の環境内のOracle Fusion Middlewareコンポーネントは相互に依存するため、トポロジ内のコンポーネントが同期されていることが重要です。
ボリュームとコンシステンシー・グループを設計する際は、この同期化は重要です。アーティファクトの中には静的なものもあれば、動的なものもあります。
静的アーティファクト
静的アーティファクトは、頻繁には変更されないファイルやディレクトリです。これには次のものがあります。
ホーム: Oracleホームは通常、OracleホームとOracle WebLogic Serverホームで構成されます。
Oracleインベントリ: これには、/etcディレクトリにある、oraInst.locおよびoratabファイルが含まれます。
動的またはランタイム・アーティファクト
動的またはランタイム・アーティファクトは、頻繁に変更されるファイルです。ランタイム・アーティファクトには、次のものがあります。
ドメイン・ホーム: 管理サーバーおよび管理対象サーバーのドメイン・ディレクトリ。
Oracleインスタンス: Oracleインスタンスのホーム・ディレクトリ。
.earファイルや.warファイルなどのアプリケーション・アーティファクト。
MDSリポジトリなどのデータベース・アーティファクト。
Oracle Fusion Middlewareで使用されるデータベース・メタデータ・リポジトリ。
JMSプロバイダやトランザクション・ログなどの永続ストア。
デプロイメント・プラン: ファイル・アダプタやJMSアダプタなどのテクノロジ・アダプタの更新に使用されます。これらは、アーティファクトがデプロイされるクラスタ内のすべてのノードにアクセスできる場所に保存する必要があります。
Oracle Fusion Middlewareでは、単一のバイナリ・ファイルのインストールから複数のOracle WebLogic Serverの管理対象サーバーを作成できます。
共有ストレージ上の単一の場所にバイナリ・ファイルをインストールし、異なるノード内にあるサーバーでこのインストールを再利用できます。最大限の可用性を確保するには、冗長バイナリ・インストールを使用することをお薦めします。
OracleホームまたはWebLogicホームが、異なるノードの複数のサーバーによって共有されている場合、これらのノードのOracleインベントリとOracleホーム・リストを常に最新の状態にして、インストールとパッチ・アプリケーションの整合性を確保することをお薦めします。
ノードでインベントリ・ファイルを更新して、これに共有ストレージのインストールを関連付けるには、ORACLE_HOME/oui/bin/attachHome.shを使用します。
共有ストレージでボリュームを作成するガイドラインについて確認します。
ストレージ・デバイスで使用可能なストレージ・レプリケーション・テクノロジの機能によっては、層内の各ノードでマウント・ポイント、ディレクトリおよびシンボリック・リンクを作成する必要がある場合があります。
ストレージ・デバイスのストレージ・レプリケーション・テクノロジによって複数のボリューム間で一貫性のあるレプリケーションが保証される場合:
その層で実行されるサーバーごとにボリュームを1つずつ作成します。たとえば、アプリケーション層では、WebLogicの管理サーバー用にボリュームを1つと管理対象サーバー用に別のボリュームを作成できます。
各層に対して、その層のボリュームをメンバーとするコンシステンシー・グループを1つ作成します。
2つのシステムによってボリュームが同時にマウントされる場合、ストレージ・サブシステムによっては、クラスタ・ファイル・システムが必要になることがあります。ただし、異なるシステム上のOracleプロセスが1つのファイルまたはディレクトリ・ツリーに同時にアクセスするという既知のケースはありません。NFSはクラスタ・ファイル・システムなので、NFSで接続されたストレージを使用している場合、クラスタ・ファイル・システム・ソフトウェアを追加する必要はありません。
ストレージ・デバイスのストレージ・レプリケーション・テクノロジによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合:
各層にボリュームを1つずつ作成します。たとえば、アプリケーション層用のボリューム、Web層用のボリュームというように作成できます。
その層の各ノード用に別個のディレクトリを作成します。たとえば、アプリケーション層のボリュームの下にSOAHOST1用のディレクトリを作成し、Web層のボリュームの下にWEBHOST1用のディレクトリを作成できます。
ボリューム上のそのディレクトリに対するマウント・ポイント・ディレクトリを各ノードに作成します。
マウント・ポイント・ディレクトリへのシンボリック・リンクを作成します。これにより、層内のノード間で同じディレクトリ構造を使用できるようになります。
2つのシステムによってボリュームが同時にマウントされる場合、ストレージ・サブシステムによっては、クラスタ・ファイル・システムが必要になることがあります。ただし、異なるシステム上のOracleプロセスが1つのファイルまたはディレクトリ・ツリーに同時にアクセスするという既知のケースはありません。NFSはクラスタ・ファイル・システムなので、NFSで接続されたストレージを使用している場合、クラスタ・ファイル・システム・ソフトウェアを追加する必要はありません。
注意:
障害時リカバリ・サイトの共有ストレージを設定する前に、『Oracle Fusion Middlewareリリース・ノート』の高可用性に関する章を参照して、高可用性環境で共有ストレージをベースとしたデプロイメントに関する既知の問題を確認してください。
Oracle Fusion Middlewareのリリース・ノートは次のURLにあります。
http://www.oracle.com/technology/documentation/middleware.html
Java Message Service (JMS)およびトランザクション・ログ(TLogs)では、Oracle SOA Suiteトポロジの高可用性のローカル・サイトでファイルベースの永続ストアを使用します。
通常、Oracle WebLogic Serversは高可用性実現のためにクラスタ化されています。このファイルベースの永続ストアは、クラスタのすべてのメンバーがアクセス可能な共有ストレージに配置する必要があります。
ストレージ領域ネットワーク(SAN)ストレージ・システムでは、Oracle Clustered File System (OCFS2)など、ホストベースのクラスタまたは共有ファイル・システム・テクノロジを使用する必要があります。OCFS2は、対称型の共有ディスク・クラスタ・ファイル・システムです。これを使用すると、各ノードでメタデータとデータの両方をSANに対して直接読み書きできます。
NASストレージ・システムを使用している場合、クラスタ・ファイル・システムを追加する必要はありません。
障害時リカバリ・ソリューションを計画している場合、Oracle Data Guardでシステムのデータベースを同期化することを検討します。
この項では、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およびOracle GoldenGateの詳細は、http://www.oracle.com/in/products/database/options/active-data-guard/index.htmlとhttp://www.oracle.com/technetwork/middleware/goldengate/overview/index.htmlを参照してください
使用するOracle Data Guard構成は、データベースのデータ損失要件に加えて、REDO生成と比較した場合の使用可能な帯域幅や待機時間など、ネットワークに関する考慮事項に基づいて決定する必要があります。Oracle Data Guard構成を設定する前に、こうした情報が正しく特定されていることを確認してください。
Oracle Maximum Availability Architectureの詳細は、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_HOME、home、ORACLE_INSTANCE、DOMAIN_HOMEの値は同一である必要があります。
データベース層のDB_NAME、INSTANCE_NAME、Listen PortおよびORACLE_SIDの値は同一である必要があります。
WLSデータソースの操作を回避するには、アプリケーション・データソースで指定されたSERVICE_NAMEが同一である必要があります。ただし、各データベースは、追加のサービスを定義できます。
次の各項では、データベース関連のポイントについて説明します。
Oracle Data Guardを使用して本番データベースとスタンバイ・データベースが同期化されるため、本番データベースとスタンバイ・データベースは相互に参照できます。
Oracle Data Guardでは、tnsnames.oraファイル・エントリを使用して、本番データベースとスタンバイ・データベースにリクエストを送信します。そのため、本番データベースとスタンバイ・データベースのエントリをtnsnames.oraファイルに作成する必要があります。Oracle Data Guardでtnsnames.oraファイルを使用する方法の詳細は、Oracle Databaseのドキュメント・セットにある『Oracle Data Guard概念および管理』を参照してください。
SQLを使用して、本番およびスタンバイ・データベースを同期化します。
alter system archive log allというSQL文を使用して、ログを切り替えます。これにより、本番サイトとスタンバイ・サイトのデータベースの同期化が強制的に行われます。
本番サイトとスタンバイ・サイトのデータベースを手動で同期化するには、次のSQL文を使用します。
ALTER SYSTEM ARCHIVE LOG ALL;
本番サイトとスタンバイ・サイトのデータベースにデータベース・ホスト名の別名を設定します。
この別名は、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障害時リカバリのスタンバイ・サイトを設計する方法については、「既存のサイトを基にした設計」を参照してください。
既存の本番サイトもスタンバイ・サイトもありません。両方とも設計して作成する必要があります。
既存の本番サイトもスタンバイ・サイトもない場合にOracle Fusion Middleware障害時リカバリの本番サイトとスタンバイ・サイトを新しく設計する方法については、「新しいサイトの設計」を参照してください。
一部のホストやコンポーネントが現在の本番サイトに存在するものの、そのサイトまたはスタンバイ・サイトに新しいホストやコンポーネントを追加して、適切に機能するOracle Fusion Middleware障害時リカバリ・トポロジを設定する必要があります。
この章に記載されている関連情報を参考にして、Oracle Fusion Middleware障害時リカバリ・トポロジを設計および実装してください。
この項には次のトピックが含まれます:
既存の本番サイトを基にする場合、本番サイトの構成データおよびOracleバイナリ・ファイルはファイル・システムにすでに存在しています。
また、ホスト名、ポートおよびユーザー・アカウントもすでに定義されています。既存の本番サイトを元にする場合、次の設計のいずれかを選択します。
対称スタンバイ・サイトを設計します。「対称トポロジの設計に関する考慮事項」を参照してください。
非対称スタンバイ・サイトを設計します。「非対称トポロジの設計に関する考慮事項」を参照してください。
最初に本番サイトを共有ストレージに移行し(本番サイトが共有ストレージにない場合)、移行したデータを使用して対称スタンバイ・サイトまたは非対称スタンバイ・サイトを作成します。
本番サイトを移行するには、次の項を参照してください。
Oracle Fusion Middleware障害時リカバリ・ソリューションでは、共有ストレージを使用して、Oracle Fusion Middlewareの中間層構成の障害時保護に使用するストレージ・レプリケーションを実装します。本番サイトがすでに作成されている場合、サイトを構成するOracle Fusion MiddlewareインスタンスのOracleホーム・ディレクトリが共有ストレージに配置されていない可能性があります。その場合、Oracle Fusion Middleware障害時リカバリ・ソリューションを実装するには、それらのホームをすべて共有ストレージに移行する必要があります。
ローカル・ディスクから共有ストレージに本番サイトを移行する際のガイドラインは次のとおりです。
実行するバックアップはすべて、オフライン・バックアップである必要があります。『Oracle Fusion Middleware Oracle Fusion Middlewareの管理』のバックアップのタイプおよび推奨されるバックアップ戦略に関する項を参照してください。
ルート・ユーザーとしてバックアップを実行する必要があり、その権限を保持している必要があります。『Oracle Fusion Middleware Oracle Fusion Middlewareの管理』のバックアップ戦略の概要に関する項を参照してください。
これは1回のみの操作であるため、ドメイン全体をリカバリする必要があります。
共有ストレージのディレクトリ構造は、「ディレクトリ構造とボリュームの設計」の説明に従って設定する必要があります。
Oracle SOA Suiteの詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareの管理』のバックアップとリカバリの概要に関する項を参照してください。
Web層の詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareの管理』のバックアップとリカバリの概要に関する項を参照してください。
Oracle Fusion Middleware障害時リカバリ・トポロジの新しい本番サイトを設計する際に、ホスト名を検討し、(これらの名前に基づいて)構成をスタンバイ・サイトにコピーするようにストレージ・レプリケーションを設定します。
新しい本番サイトを設計する場合、スタンバイ・サイトも計画し、Oracle Universal Installerを使用して、本番サイトにソフトウェアをインストールします。ホスト名別名やソフトウェア・パスなどのパラメータは、両方のサイトで同じになるように、注意して設計する必要があります。
Oracle Fusion Middleware障害時リカバリの本番サイトとスタンバイ・サイトを新しく作成する場合、次のような選択肢を検討します。
本番サイトとスタンバイ・サイトの各ホストが目的のホスト名別名および物理ホスト名を使用するように、Oracle Fusion Middleware障害時リカバリ・ソリューションを設計します。ホスト名の計画の詳細は、「ホスト名の計画」を参照してください。
Fusion MiddlewareインストールごとにOracleホーム名およびOracleホーム・ディレクトリを選択します。
サイトを最初から設計して作成する方が、この章で説明した設計要件に合せて既存のサイトを変更するよりも簡単です。
本番サイトのホストのOracle Fusion Middlewareインストールに、スタンバイ・サイトのホストで使用するポートと競合しないポートを割り当てます。
既存の本番サイトとスタンバイ・サイト間におけるポートの競合を確認して解決するよりも、この設定の方が簡単です。
障害時リカバリ・ソリューションを計画する場合、対称トポロジまたは非対称トポロジを考慮します。
この項には次のトピックが含まれます:
対称トポロジは、Oracle Fusion Middleware障害時リカバリ構成の1つで、本番サイトとスタンバイ・サイト間で各階層が同じように構成されます。
対称トポロジでは、本番サイトとスタンバイ・サイトで同じ数のホスト、ロード・バランサ、インスタンスおよびアプリケーションを使用します。また、両方のサイトで同じポートが使用されます。システムはまったく同じように構成され、アプリケーションは同じデータにアクセスします。このマニュアルでは、エンタープライズ構成用に、Oracle Fusion Middleware障害時リカバリで対称トポロジを設定する方法について説明します。
非対称トポロジは、Oracle Fusion Middleware障害時リカバリ構成の1つで、本番サイトとスタンバイ・サイト間で一部の階層の構成に相違があります。
非対称トポロジでは、スタンバイ・サイトで使用するハードウェアの数が少ない場合があります(本番サイトには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)データベースを、スタンバイ・サイトで単一のインスタンス・データベースを使用する場合など)。
