Oracle® Fusion Middleware

高可用性ガイド

12c (12.2.1.0.0)

E69925-01(原本部品番号:E56928-01)

2015年10月

Oracle Fusion Middleware高可用性ガイド, 12c (12.2.1.0.0)

E69925-01

Copyright © 2013, 2015, Oracle and/or its affiliatesAll rights reserved.

原本著者: Christine Ford

原本協力著者: Michael Blevins、Suvendu Ray、Lingaraj Nayak、Maneesh Jain、Peter LaQuerre

原本協力者:  Gururaj BS

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、このソフトウェアまたはハードウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

図一覧

表一覧

タイトルおよび著作権情報

はじめに

- 対象読者

- このガイドの目的

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

第I部 高可用性の概要

1 概要とロードマップ

- 1.1 このガイドの使用方法

- 1.2 高可用性環境の設定

- 1.3 このリリースの新機能と変更された機能

- 1.4 高可用性とは

- 1.4.1 アクティブ/アクティブの高可用性ソリューション

- 1.4.2 アクティブ/パッシブの高可用性ソリューション

- 1.5 高可用性ソリューション

- 1.6 Oracle Fusion Middlewareの標準的なHAトポロジの理解

2 高可用性の概要

- 2.1 Oracle Fusion Middlewareの概念

- 2.2 高可用性環境でのサーバーのロード・バランシング

- 2.2.1 ロード・バランシングについて

- 2.2.2 サード・パーティ製のロード・バランサの要件

- 2.2.3 サード・パーティ製のロード・バランサの構成

- 2.2.4 Oracle HTTP ServerまたはOracle Traffic Directorによるサーバーのロード・バランシング

- 2.3 アプリケーション・フェイルオーバー

- 2.3.1 フェイルオーバー、アプリケーションのフェイルオーバーと状態について

- 2.3.2 セッションのフェイルオーバー要件

- 2.3.3 アプリケーションのフェイルオーバーの予想される動作

- 2.4 Real Application Clusters

- 2.5 Coherenceクラスタと高可用性

- 2.6 障害時リカバリ

- 2.7 インストール時の構成(プロファイル)

- 2.7.1 ドメイン(トポロジ)プロファイル

- 2.7.2 コンポーネント/サービスのデータベースとファイルの永続性プロファイル

- 2.7.3 構成後のデフォルト設定

- 2.8 アプリケーションおよびサービスのフェイルオーバー

- 2.8.1 自動移行サービス(JMS/JTA)について

- 2.9 高可用性トポロジの設定手順

3 サーバー全体の移行

- 3.1 サーバー全体の移行について

- 3.2 管理対象サーバーのフェイルオーバー用のサーバー全体の移行の構成

第II部 高可用性環境の構築

4 共有記憶域の使用

- 4.1 共有記憶域の概要

- 4.2 共有記憶域に関する前提条件

- 4.3 バイナリ(Oracleホーム)ディレクトリ用の共有記憶域の使用

- 4.3.1 バイナリ(Oracleホーム)・ディレクトリについて

- 4.3.2 単一Oracleホームの共有について

- 4.3.3 冗長バイナリ(Oracleホーム)・ディレクトリの使用について

- 4.4 ドメイン構成ファイル用の共有記憶域の使用

- 4.4.1 Oracle WebLogic Server管理サーバーおよび管理対象サーバーのドメイン構成ファイルについて

- 4.4.2 管理サーバー構成ディレクトリの共有記憶域に関する考慮事項

- 4.4.3 管理対象サーバー構成ファイルの共有記憶域に関する考慮事項

- 4.5 JMSストアおよびJTAログ用の共有記憶域の要件

- 4.6 ディレクトリ構造と構成

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

- 5.1 Oracle Real Application Clustersについて

- 5.2 Oracle Real Applicationクラスタの設定手順

- 5.3 RACのデータベース接続およびフェイルオーバーについて

- 5.3.1 XAトランザクションについて

- 5.4 データ・ソースについて

- 5.4.1 アクティブなGridLinkデータ・ソース

- 5.4.2 マルチ・データ・ソース

- 5.5 Oracle RACでのアクティブなGridLinkデータ・ソースの構成

- 5.5.1 アクティブなGridlinkデータ・ソースとしてのコンポーネント・データ・ソースを構成するための要件

- 5.5.2 アクティブなGridLinkデータ・ソースとしてのコンポーネント・データ・ソースの構成

- 5.5.3 ホストおよびポートでのSCANアドレスの使用方法

- 5.6 マルチ・データ・ソースの構成

- 5.6.1 Oracle RACでのマルチ・データ・ソースの構成

- 5.6.1.1 Oracle RACでのマルチ・データ・ソースを構成するための要件

- 5.6.1.2 マルチ・データ・ソースとしてのコンポーネント・データ・ソースの構成

- 5.6.1.3 マルチ・データ・ソースのRACデータベースへの追加について

- 5.6.1.4 初期構成後のマルチ・データ・ソースの変更または作成

- 5.6.1.5 警告メッセージのトラブルシューティング(XAデータ・ソースのトランザクション・タイムアウト値の増加)

- 5.6.1.6 トランザクション・リカバリ権限のスキーマの構成

- 5.6.2 MDSリポジトリのためのマルチ・データ・ソースの構成

6 トポロジのスケール・アウト(マシンのスケール・アウト)

- 6.1 マシンのスケール・アウトについて

- 6.2 トポロジのスケール・アウト手順

- 6.3 オプションのスケール・アウト手順

- 6.4 スケール・アウトの前提条件について

- 6.5 リソース要件

- 6.6 新しいマシンの作成

- 6.6.1 管理対象サーバーの停止

- 6.6.2 新しいマシンの作成(管理コンソールの使用)

- 6.6.3 新しいマシンへの管理対象サーバーの割当て

- 6.7 マシンのスケール・アップまたはスケール・アウト後のWLS JMSの構成

- 6.8 APPHOST1上のドメインのパック

- 6.9 新しいマシンの準備

- 6.10 テンプレートを転送するためのアンパックの実行

- 6.11 ノード・マネージャの起動

- 6.12 管理対象サーバーの起動

- 6.13 マシンのスケール・アウトの検証

- 6.14 クラスタ用マルチキャスト・メッセージングの構成

- 6.14.1 クラスタ用マルチキャストとユニキャスト・メッセージングについて

- 6.14.2 マルチキャスト・メッセージングを構成するための要件

- 6.14.3 マルチキャスト・メッセージングの構成

7 JMSおよびJTAの高可用性

- 7.1 JMSおよびJTAの高可用性サービスについて

- 7.2 JMSおよびJTAサービスのための移行可能ターゲットについて

- 7.3 JMSおよびJTAの高可用性の移行可能ターゲットの構成

- 7.4 ユーザー優先サーバーと候補サーバー

- 7.5 ファイル永続性を使用するうえでの考慮事項(WebLogic JMS)

- 7.6 NFSでのファイル・ストアの使用

- 7.6.1 サーバーの再開動作の検証

- 7.6.2 デフォルトのファイル・ストアのファイル・ロックの無効化

- 7.6.3 カスタム・ファイル・ストアのファイル・ロックの無効化

- 7.6.4 JMSページング・ファイル・ストアのファイル・ロックの無効化

- 7.6.5 診断ファイル・ストアのファイル・ロックの無効化

- 7.7 データベース永続ストアを使用したWLS JMSの構成

- 7.7.1 永続ストアについて

- 7.7.2 データベース永続ストアを使用したWLS JMSの構成の前提条件

- 7.7.3 WLS JMSでのファイルベースの永続ストアからデータベース永続ストアへの切替え

- 7.8 トランザクション・ログを永続化するためのデータベース・ストアの構成

- 7.8.1 JDBC TLOGストアを構成するための要件

- 7.8.2 JDBC TLOGストアの構成

8 管理サーバーの高可用性

- 8.1 管理サーバーの役割

- 8.1.1 管理サーバーの障害と再起動

- 8.1.2 共有記憶域と管理サーバーの高可用性

- 8.2 ノード・マネージャの役割

- 8.3 管理サーバーの高可用性トポロジ

- 8.4 管理サーバーの高可用性の構成

- 8.4.1 管理サーバーの高可用性の要件

- 8.4.2 高可用性の管理サーバーの構成

- 8.5 管理サーバーのフェイルオーバーまたはフェイルバック

- 8.5.1 元のホストに障害が発生した場合の管理サーバーのフェイルオーバー

- 8.5.2 元のホストへの管理サーバーのフェイルバック

第III部 コンポーネントの構成手順

9 Web層コンポーネントの高可用性の構成

- 9.1 Oracle HTTP Serverと高可用性の概要

- 9.2 Oracle HTTP Serverの単一インスタンスの特性

- 9.3 Oracle HTTP Serverおよびドメイン

- 9.4 Oracle HTTP Serverの起動とシャットダウンのライフサイクル

- 9.5 Oracle HTTP Serverの起動と停止

- 9.6 Oracle HTTP Serverの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

- 9.7 Oracle HTTP Serverの障害保護および予想される動作

- 9.8 複数のマシンでのOracle HTTP Serverインスタンスの構成

- 9.9 高可用性のためのOracle HTTP Serverの構成

- 9.9.1 高可用性OHSの構成の前提条件

- 9.9.1.1 ロード・バランサに関する前提条件

- 9.9.1.2 ロード・バランサの仮想サーバー名とポートの構成

- 9.9.1.3 ロード・バランサのポート番号の管理

- 9.9.1.4 WEBHOST1へのOracle HTTP Serverのインストールと検証

- 9.9.1.5 WEBHOST1での仮想ホストの作成

- 9.9.1.6 mod_wl_ohs.confの構成

- 9.9.1.7 SSL終端使用時のmod_wl_confの構成

- 9.9.2 WEBHOST2へのOracle HTTP Serverのインストールと検証

- 9.9.3 OHS高可用性デプロイメントの構成と検証

- 9.9.3.1 WEBHOST2での仮想ホストの作成

- 9.9.3.2 Oracle HTTP Serverの構成の検証

10 Oracle WebCenterコンポーネントの高可用性の構成

- 10.1 WebCenter Content: Inbound Refineryコンポーネントの拡張について

- 10.2 WebCenter Contentのスケール・アップについて

- 10.3 WebCenter Portalコンポーネントの複数ノード上での作成について

- 10.4 WebCenter CaptureドメインのOracle SOAでの作成について

- 10.5 WebCenter Captureのスケール・アウトとOWSMの構成

- 10.6 WebCenter Sitesコンポーネント接続につい

- 10.7 WebCenter Sitesとマルチキャストについて

11 その他のコンポーネントの高可用性の構成

- 11.1 Oracle Data Integratorのデプロイ

- 11.1.1 ソース接続およびターゲット接続に対するOracle RACの再試行の接続

- 11.1.2 Oracle RACへのODIリポジトリ接続の構成

- 11.1.3 Oracle Data Integratorスケジューラ・ノードの障害

- 11.2 Oracle Application Development Frameworkのデプロイ

- 11.2.1 Oracle JRF非同期Webサービス(固定サービスの動作)

- 11.3 BIのデプロイ

- 11.3.1 BIセッションのフェイルオーバーについて

- 11.3.2 BI Essbaseについて

- 11.3.3 BI Studioについて

- 11.3.4 複数のノード・マネージャへのポートの指定について

- 11.3.5 RACデータベースのインストール後の構成について

- 11.3.6 BI Publisherのスケール・アウトについて

- 11.4 Formsのデプロイ

- 11.4.1 Forms HTTPセッションのフェイルオーバーについて

- 11.5 Reportsのデプロイ

- 11.5.1 Reportsでのスケール・アップについて

- 11.5.2 Reportsのマルチキャスト通信について

- 11.5.3 Reportsの共有ファイル・ベース・キャッシュについて

- 11.5.4 Reportsのデータベース・サービス障害について

- 11.5.5 ReportsのOID/共有キャッシュ・ファイル・システムの障害について

図一覧

- 1-1 Oracle Fusion Middlewareの高可用性デプロイメント・トポロジ(一般的な企業)

- 4-1 共有記憶域のディレクトリ構造

- 8-1 管理対象サーバーの高可用性トポロジ

- 9-1 Oracle HTTP Serverの高可用性アーキテクチャ

表一覧

- 1-1 高可用性環境の設定

- 1-2 Oracle Fusion Middlewareインフラストラクチャの標準的な高可用性トポロジ内の要素の説明

- 2-1 Oracle Fusion Middlewareの概念

- 2-2 サーバーのロード・バランシング製品

- 2-3 CoherenceおよびCoherenceクラスタ

- 2-4 データベースおよびファイルの永続性プロファイルの永続性タイプ

- 2-5 ドメインの構成に関する各項

- 2-6 高可用性トポロジの設定手順

- 4-1 共有記憶域に関する項目

- 4-2 共有記憶域要素のディレクトリ構造

- 5-1 Oracle RACの設定手順

- 5-2 推奨されるマルチ・データ・ソース構成

- 5-3 XAデータ・ソース構成

- 5-4 XA以外のデータ・ソース構成

- 6-1 トポロジのスケール・アウト手順

- 6-2 マルチキャスト詳細パラメータ

- 8-1 管理サーバーおよびノード・マネージャに関する項目

- 8-2 ホストおよびノード・マネージャの用語

- 9-1 OHS障害タイプと障害保護

はじめに

「はじめに」には次の項が含まれます:

- 対象読者

- このガイドの目的

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

対象読者

『Oracle Fusion Middleware高可用性ガイド』12c (12.2.1.0.0)は、管理者や開発者など、高可用性を目的としてOracle Fusion Middlewareをデプロイおよび管理することを役割としている方を対象としています。

このガイドの目的

このガイドは、高可用性環境を構成するための参照ドキュメントです。ご使用の製品のインストレーション・ガイドおよび管理ガイドとあわせて、このガイドを参照してください。

ドキュメントのアクセシビリティについて

オラクル社のアクセシビリティへの取組みの詳細は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

サポートを購入したオラクル社のお客様は、My Oracle Supportを介して電子的なサポートにアクセスできます。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info) か、聴覚に障害のあるお客様は (http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

関連ドキュメント

詳細は、次のOracleドキュメントを参照してください。

- Oracle Fusion Middleware Oracle Fusion Middlewareコンセプトの理解

- Oracle Fusion Middleware Oracle Fusion Middlewareの管理

- Oracle Fusion Middlewareパフォーマンスのチューニング・ガイド

- Oracle Fusion Middleware Oracle WebLogic Serverクラスタの管理

このマニュアルやその他のマニュアル内の不明な用語の定義は、用語集を参照してください。

表記規則

このドキュメントでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するグラフィカル・ユーザー・インタフェース要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、パラグラフ内のコマンド、URL、例に記載されているコード、画面に表示されるテキスト、または入力するテキストを示します。

第I部

高可用性の概要

第I部は、次のトピックで構成されています。

- 第1章「概要とロードマップ」

- 第2章「高可用性の概要」

- 第3章「サーバー全体の移行」

1 概要とロードマップ

この項では、このガイドの使用方法と使用する理由および高可用性環境について、それぞれの情報を説明します。この項には次のトピックが含まれます:

- 第1.1項「このガイドの使用方法」

- 第1.2項「高可用性環境の設定」

- 第1.3項「このリリースの新機能と変更された機能」

- 第1.4項「高可用性とは」

- 第1.5項「高可用性ソリューション」

- 第1.6項「Oracle Fusion Middlewareの標準的なHAトポロジの理解」

1.1 このガイドの使用方法

このドキュメントは、高可用性の概念やタスクに関する情報のリファレンス・ガイドとして、高可用性環境を設定するときに使用します。

このガイドを使用する前には、標準的なインストール・トポロジが製品に設定されている必要があります。これは、高可用性の設定に必要な開始点です。標準的なインストール・トポロジの設定方法については、Oracle Fusion Middlewareインフラストラクチャの標準的なインストール・トポロジの理解に関する項および標準的なインストール・トポロジのインストールと構成の手順に関する項を参照してください。

1.2 高可用性環境の設定

次の表は、このガイドに記載されていない、高可用性環境を設定するためのタスクとリソースを示しています。

表1-1 高可用性環境の設定

作業

説明

参照先

管理タスクの実行および環境の準備

新しく作成したドメインで実行する共通のタスクです。

製品インストレーション・ガイドのWebLogicドメインの可用性を高めるための管理と準備に関する項を参照してください。

WebLogic Serverのインストールの計画

トポロジを理解して、必要なディストリビューション、コンポーネント、機能を特定するための説明です。

『Oracle Fusion Middlewareのインストールのプランニング』を参照してください。

WebLogic Serverソフトウェアのインストール

インストール・プロセスの開始方法とインストール画面の各過程についての説明です。

製品インストレーション・ガイドのOracle Fusion Middlewareインフラストラクチャのソフトウェアのインストールに関する項を参照

ドメインの構成

ドメインの作成と構成を行います。

製品インストレーション・ガイドのOracle Fusion Middlewareインフラストラクチャのドメインの構成に関する項を参照してください。

Oracle Fusion Middlewareの管理

起動および停止、ポートの変更、アプリケーションのデプロイ、Oracle Fusion Middlewareのバックアップおよびリカバリの各手順が含まれます。

『Oracle Fusion Middleware管理者ガイド』を参照

Oracle Fusion Middleware環境のパフォーマンスのモニタリングおよび最適化

パフォーマンスに影響するコンポーネントの場合は、複数のコンポーネントを使用して、パフォーマンスを最適化したり、パフォーマンス重視のアプリケーションを設計します。

『Oracle Fusion Middlewareパフォーマンスのチューニング・ガイド』を参照

製品固有のエンタープライズ・デプロイメントの設定

製品固有のエンタープライズ・デプロイメントについて、実証済の高可用性テクノロジ、セキュリティ・テクノロジおよび推奨事項に基づいたベスト・プラクティスの青写真です。

製品のエンタープライズ・デプロイメント・ガイドを参照

製品環境の管理

製品を使用して、アプリケーションのデプロイ、管理、モニターおよび構成を行います。

製品の管理者ガイドを参照

ノード・マネージャの構成

ノード・マネージャを使用して、離れた場所から管理サーバー・インスタンスや管理対象サーバー・インスタンスを起動、停止および再起動します。これは、高可用性環境の基本ツールです。

『Oracle WebLogic Serverノード・マネージャの管理』を参照してください。

1.3 このリリースの新機能と変更された機能

Oracle Fusion Middleware 12c (12.1.3)では、次の概念と機能が新しく追加および変更されています。

- WebCenterのサポート。第10章「Oracle WebCenterコンポーネントの高可用性の構成」

- BIのサポート。第11.3項「BIのデプロイ」を参照してください。

関連項目:
新しく追加された内容と非推奨になった内容の包括的なリストは、次の各項を参照してください。

- このリリースのWebLogic Serverの新機能については、『Oracle Fusion Middleware Oracle WebLogic Serverの新機能』を参照してください。

- このリリースの用語については、『Oracle Fusion Middlewareコンセプトの理解』の12cで新しく追加された用語と非推奨になった用語に関する項を参照してください。

1.4 高可用性とは

高可用性とは、必要なシステムまたはデバイスに対して、常にアクセス可能な状態を維持する能力のことです。

高可用性アーキテクチャにより、サービスを中断することなく、ユーザーはシステムにアクセスできます。高可用性システムをデプロイすることで、システムの停止時間つまり使用不可の時間が最小化され、システムの稼働時間つまり使用可能な時間が最大化されます。

高可用性は、冗長なシステムおよびコンポーネントから生じます。高可用性ソリューションは、冗長性のレベルによってアクティブ/アクティブ・ソリューションとアクティブ/パッシブ・ソリューションに分類されます。

次のトピックを参照してください。

- 第1.4.1項「アクティブ/アクティブの高可用性ソリューション」

- 第1.4.2項「アクティブ/パッシブの高可用性ソリューション」

1.4.1 アクティブ/アクティブの高可用性ソリューション

アクティブ/アクティブ・ソリューションは、スケーラビリティの向上および高可用性の提供のために、複数のアクティブなサーバーをデプロイします。アクティブ/アクティブのデプロイメントでは、すべてのインスタンスが同時にリクエストを処理します。単一サイトにミドルウェアをデプロイする場合は、常にアクティブ/アクティブ・ソリューションを使用することをお薦めします。

1.4.2 アクティブ/パッシブの高可用性ソリューション

アクティブ/パッシブ・ソリューションでは、リクエストを処理するアクティブ・インスタンスと、スタンバイ状態のパッシブ・インスタンスをデプロイします。アクティブ・ノードで障害が発生すると、スタンバイ・ノードがアクティブ化され、中間層コンポーネントはそのノードからクライアント・リクエストの処理を続行します。すべての中間層コンポーネントが新しいアクティブ・ノードにフェイルオーバーします。フェイルオーバー後、障害ノードでは中間層コンポーネントは実行されなくなります。Oracleでは、すべてのコンポーネントでアクティブ/パッシブ・デプロイメントがサポートされます。

1.5 高可用性ソリューション

高可用性ソリューションは、単一データ・センターのデプロイメントで高可用性を実現するローカル高可用性ソリューションと、障害時リカバリ・ソリューションに分類できます。

ローカル高可用性ソリューションは、プロセス障害、ノード障害、メディア障害および人為ミスから保護することができ、単一データ・センターのデプロイメントで高可用性を提供します。

障害時リカバリ・ソリューションは、一般的に地理的に分散されたデプロイメントで、洪水や広範囲のネットワーク停止などの災害からアプリケーションを保護します。障害時リカバリ・ソリューションを地理的に分散してデプロイすることで、データ・センター全体に影響を及ぼす物理的災害から保護できます。Oracle Fusion Middlewareコンポーネントの障害時リカバリの詳細は、『Oracle Fusion Middlewareディザスタ・リカバリ・ガイド』を参照してください

1.6 Oracle Fusion Middlewareの標準的なHAトポロジの理解

次の図では、Oracle Fusion Middlewareのローカルの高可用性デプロイメントで推奨される標準的な高可用性トポロジを示します。

『Oracle Fusion Middleware Oracle Fusion Middleware Infrastructureのインストールと構成』および『Oracle Fusion Middleware Oracle HTTP Serverのインストールと構成』の手順に従って構成すると、このデプロイメントは、インフラストラクチャの標準的なインストール・トポロジおよびOracle HTTP Serverの標準的なインストール・トポロジと同じ状態になります。

図1-1 Oracle Fusion Middlewareの高可用性デプロイメント・トポロジ(一般的な企業)

このトポロジは多層アーキテクチャを表しています。ユーザーはクライアント層からシステムにアクセスします。リクエストはハードウェア・ロード・バランサを通過し、Web層のOracle HTTP Serverが稼働しているWebサーバーにルーティングされます。Webサーバーでは、プロキシ・プラグイン(mod_wl_ohs)を使用して、リクエストをアプリケーション層のWebLogicクラスタにルーティングします。次に、アプリケーション層のWebLogicクラスタで稼働しているアプリケーションが、データ層のデータベース・クラスタと対話して、リクエストに応じます。

次の表では、前述の図の要素を説明しています。

表1-2 Oracle Fusion Middlewareインフラストラクチャの標準的な高可用性トポロジ内の要素の説明

要素

説明および関連ドキュメントへのリンク

APPHOST

アプリケーション層がホストされるマシン。

WEBHOST

Web層がホストされるマシン。

WebLogicドメイン

Javaコンポーネントの論理的に関連したグループです。ここでは、管理サーバー、管理対象サーバーおよびその他のソフトウェア・コンポーネントが含まれています。

詳細は、Oracle Fusion Middlewareの理解のOracle WebLogic Serverドメインの概要に関する項を参照してください。

管理サーバー

ドメインの集中管理エンティティです。ドメインの構成オブジェクトを保持し、構成の変更を管理対象サーバーに配布します。

Enterprise Manager

Oracle Enterprise Manager Fusion Middleware Control。ドメインの管理で主に使用するツールです。

クラスタ

複数のWebLogic Serverインスタンスが同時に稼働し、相互に作用する集合です。

マシン

1つまたは複数のWebLogic Serverインスタンス(サーバー)をホストするコンピュータを論理的に表します。マシンは管理対象サーバーとノード・マネージャ間を論理的に結び付けます。ノード・マネージャを使用して管理対象サーバーを起動または停止するには、管理対象サーバーがマシンと関連付けられている必要があります。

管理対象サーバー

アプリケーション、アプリケーション・コンポーネント、Webサービスおよび関連リソースをホストします。

『Oracle Fusion Middlewareコンセプトの理解』のOracle Enterprise Manager Fusion Middleware Controlに関する項を参照してください。

インフラストラクチャ

次のものを含むサービスの集合です。

- メタデータ・リポジトリ(MDS)。これにはOracle Application Developer Frameworkなどのコンポーネントのメタデータが含まれます。詳細は、『Oracle Fusion Middlewareコンセプトの理解』のメタデータ・リポジトリの概要に関する項を参照してください。

- Oracle Application Developer Framework (Oracle ADF)

- Oracle Web Services Manager (OWSM)

関連項目:

- インフラストラクチャの標準的なインストール・トポロジの図を確認して、そのインストール手順を実行する場合は、『Oracle Fusion Middleware Oracle Fusion Middleware Infrastructureのインストールと構成』のインフラストラクチャの標準的なインストール・トポロジの理解に関する項を参照してください。

- Oracle HTTP Serverの標準的なインストール・トポロジの図を確認して、そのインストール手順を実行する場合は、『Oracle HTTP Serverのインストールと構成』のOracle HTTP Serverの標準的なインストール・トポロジの概要に関する項を参照してください。

2 高可用性の概要

この項では、高可用性の概要と次の項目について説明します。

- 第2.1項「Oracle Fusion Middlewareの概念」

- 第2.2項「高可用性環境でのサーバーのロード・バランシング」

- 2.3項「アプリケーション・フェイルオーバー」

- 第2.4項「Real Application Clusters」

- 第2.5項「Coherenceクラスタと高可用性」

- 第2.6項「障害時リカバリ」

- 第2.7項「インストール時の構成(プロファイル)」

- 第2.8項「アプリケーションおよびサービスのフェイルオーバー」

- 第2.9項「高可用性トポロジの設定手順」

2.1 Oracle Fusion Middlewareの概念

Oracle Fusion Middlewareの概要については、『Oracle Fusion Middleware Oracle Fusion Middlewareコンセプトの理解』の次の各項を参照してください。

表2-1 Oracle Fusion Middlewareの概要

情報

参照先

Oracleホーム、Oracle Common、WebLogic Serverドメイン

「Oracle Fusion Middlewareの主要ディレクトリとは」

WebLogic Serverドメイン

「Oracle WebLogic Serverドメインとは」

管理サーバー

「管理サーバーとは」

管理対象サーバーおよび管理対象サーバー・クラスタ

「管理対象サーバーおよび管理対象サーバー・クラスタの理解」

ノード・マネージャ

「ノード・マネージャとは」

関連項目:
『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの管理』のクラスタ内での通信に関する項

2.2 高可用性環境でのサーバーのロード・バランシング

この項の内容は次のとおりです。

- 第2.2.1項「ロード・バランシングについて」

- 第2.2.2項「サード・パーティ製のロード・バランサの要件」

- 第2.2.3項「サード・パーティ製のロード・バランサの構成」

- 第2.2.4項「Oracle HTTP ServerまたはOracle Traffic Directorによるサーバーのロード・バランシング」

2.2.1 ロード・バランシングについて

ロード・バランシングとは、環境内のコンピューティングおよびネットワーキング・リソース全体において、ジョブとそれに関係する通信を均等に分散することです。

一般的に、ロード・バランサは、高可用性デプロイメントのフロントエンド処理を行います。Oracle HTTP ServerまたはOracle Traffic Directorを使用して、異なるコンポーネントまたはアプリケーション間のロード・バランシングを構成します。第2.2.4項「Oracle HTTP ServerまたはOracle Traffic Directorによるサーバーのロード・バランシング」を参照してください。

また、(図1-1に示されているように)ロード・バランサとOracle HTTP Serverを組み合せて、最大限の高可用性を実現することも可能です。

2.2.2 サード・パーティ製のロード・バランサの要件

Oracle Fusion Middlewareの高可用性デプロイメントには、サード・パーティ製のロード・バランサを使用できます。固定セッション・ルーティングをサポートするロード・バランサの使用をお薦めします。固定セッション・ルーティングは、最初のリクエストを処理するサーバーに、セッション全体を通じてトラフィックをルーティングする機能です。

その場合、外部ロード・バランサは次の機能を備えている必要があります。

- 仮想ホスト名を使用してトラフィックを実際のサーバーのプールにロード・バランシングする機能: クライアントは、実際のホスト名ではなく、仮想ホスト名を使用してサービスにアクセスします。これにより、ロード・バランサは、プール内のサーバーに対するリクエストをロード・バランシングできます。通常は、ロード・バランサがOracle HTTP Serverインスタンス全体のバランスを取り、その後でOracle HTTP Serverがアプリケーション・サーバー全体のバランスを取ります。

- ポート変換の構成。

- ポート(HTTPおよびHTTPS)のモニタリング。

- 仮想サーバー名およびポートをロード・バランサ上に構成する機能。

- 複数の仮想サーバーの構成。各仮想サーバーについては、複数のポート上のトラフィック管理を構成できることが必要です。たとえば、クラスタの場合、ロード・バランサを1つの仮想サーバーとHTTPおよびHTTPSの両トラフィック用のポートに構成する必要があります。

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

- リソースの監視/ポートの監視/プロセス障害の検出: ロード・バランサは、サービス障害およびノード障害を検出し、障害のあるノードへの非Oracleネット・トラフィックの転送を停止する必要があります。外部ロード・バランサで障害の自動検出が可能な場合は、それを使用することをお薦めします。

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

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

- SSLアクセラレーション。この機能の使用をお薦めしますが、必須ではありません。

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

2.2.3 サード・パーティ製のロード・バランサの構成

ロード・バランサの詳細な構成手順は、次の内容によって異なります。

- ロード・バランサを使用する環境

- 使用するロード・バランサのタイプ

これらの理由から、ご使用のロード・バランサのマニュアルに従うことをお薦めします。高度なロード・バランサの構成手順については、操作するコンポーネントのエンタープライズ・デプロイメント・ガイドを参照してください。

2.2.4 Oracle HTTP ServerまたはOracle Traffic Directorによるサーバーのロード・バランシング

この項では、Oracleのロード・バランシング製品について説明します。

表2-2 サーバーのロード・バランシング製品

製品

説明

Oracle HTTP Server(OHS)

WebLogic Serverプロキシ・プラグイン・モジュールが組み込まれたWebサーバーで、1つ以上のWebLogic ServerのHTTPフロントエンドとして機能します。クライアントからのリクエストを受信し、1つ以上のWebLogic Serverでリクエストごとに負荷のバランスを取ります。OHSのmod_wl_ohsモジュールは、リクエストを1つ以上のWebLogicサーバーにルーティングします。mod_weblogic (Apache HTTP Server用のOracle WebLogic Serverプラグイン)と同じロード・バランシング機能を提供します。詳細は、Oracle Fusion Middleware Oracle WebLogic ServerにおけるWebサーバー1.1プラグインの使用のOracle HTTP Serverのmod_wl_ohsプラグインの構成に関する項を参照してください。mod_wl_ohsモジュールの詳細は、第9.8.1.4項「mod_wl_ohs.confの構成」を参照してください。

Oracle Traffic Director

WebLogicの相互運用性が強化された可用性に優れたアプリケーション・デリバリ・コントローラです。1つ以上のクラスタへのリクエストを効率的に処理します。高速で、信頼性と拡張性のあるレイヤー7のソフトウェア・ロード・バランサです。すべてのHTTP、HTTPSおよびTCPトラフィックに対する信頼できるエントリ・ポイントです。指定されたロード・バランシング・メソッドに基づくクライアントから受信したリクエストの分散、指定されたルールに基づくリクエストのルーティング、頻繁にアクセスされるデータのキャッシュ、トラフィックの優先付け、およびサービス品質の制御を行います。詳細は、『Oracle Traffic Director管理者ガイド』を参照してください。

2.3 アプリケーション・フェイルオーバー

この項では、異なるタイプのフェイルオーバーおよび動作について説明します。内容は次のとおりです。

- 第2.3.1項「フェイルオーバー、アプリケーションのフェイルオーバーと状態について」

- 第2.3.2項「セッションのフェイルオーバー要件」

- 第2.3.3項「アプリケーションのフェイルオーバーの予想される動作」

2.3.1 フェイルオーバー、アプリケーションのフェイルオーバーと状態について

フェイルオーバーとは、過負荷のリソースや障害の発生したリソース(サーバー、ディスク・ドライブ、ネットワークなど)を、バックアップの場所に移動させる機能のことです。

アプリケーション・フェイルオーバーでは、特定のジョブを実行するアプリケーション・コンポーネントが使用できなくなった場合に、障害の発生したコンポーネントのコピーがかわりにジョブを完了します。

状態とは、ジョブに対して何が実行されたかに関する情報を指します。WebLogic Serverでは、セッション・レプリケーションおよびレプリカ対応スタブを使用して、状態の情報を保持します。コンポーネントでジョブの実行が予期せず停止すると、レプリケーション手法によって、障害の発生したコンポーネントが停止した箇所をコンポーネントのコピーで特定し、ジョブを完了できます。

2.3.2 セッションのフェイルオーバー要件

注意:
Oracleのアプリケーションは、特定の例外がアプリケーションに適用されないかぎり、これらのセッションのフェイルオーバー要件を満たします。

シームレスなフェイルオーバーを実現するために、アプリケーションは次の条件を満たす必要があります。

- アプリケーションがクラスタ内にあり、アプリケーション・クラスタの少なくとも1つのメンバーが、リクエストへの対応に利用できます。

- ステートフル・アプリケーションに対し、状態のレプリケーションが正しく構成されています。

- Oracle HTTP Serverを使用している場合は、WebLogic Clusterディレクティブを使用して、すべての使用可能なアプリケーション・インスタンス間でバランスが取られるようにサーバーが構成されています。

- ハードウェア・ロード・バランサを使用する場合は、ロード・バランサが:

- 利用可能なインスタンスすべてに対してトラフィックをルーティングしています

- 利用できないインスタンスをマークするように、ヘルス・モニターで正しく構成されています

- セッションの状態の永続性をサポートするように構成されています

2.3.3 アプリケーションのフェイルオーバーの予想される動作

環境を正しく構成している場合には、クラスタ内のアプリケーション・インスタンスがいつ使用できなくなったか、ユーザーは気が付きません。たとえば、アプリケーション・フェイルオーバーにおけるイベントの順序は次のようになります。

1. ユーザーがリクエストを行い、ハードウェア・ロード・バランサによって、そのリクエストがアプリケーションのインスタンスAにルーティングされます。

2. ノード、プロセスまたはネットワークに障害が発生したため、アプリケーションのインスタンスAが使用できなくなります。

3. ハードウェア・ロード・バランサによって、インスタンスAが使用不可とマークされます。

4. ユーザーが後続のリクエストを行います。このリクエストがインスタンスBにルーティングされます。

5. インスタンスBがインスタンスAのレプリケーション・パートナとして構成され、ユーザーのセッションの状態が格納されます。

6. インスタンスBのセッションの状態を使用してアプリケーションが再開し、ユーザーは中断されることなく、引き続き操作します。

関連項目:
高可用性をサポートするドメイン・テンプレートおよび拡張テンプレートの詳細は、ドメイン・テンプレート・リファレンスを参照してください。
アプリケーション・レベルにおけるフェイルオーバーおよびレプリケーションの詳細は、『Oracle WebLogic Serverクラスタの管理』のクラスタにおけるフェイルオーバーおよびレプリケーションに関する項を参照してください。

2.4 Real Application Clusters

Oracle Real Application Clusters (RAC)を使用すると、Oracle Databaseのクラスタを構成できます。クラスタは、相互に接続された複数のコンピュータまたはサーバーで構成され、エンド・ユーザーおよびアプリケーションからは1つのサーバーとして認識されます。Oracle RACでは、インフラストラクチャとしてOracle Clusterwareを使用し、複数のサーバーを関連付けてそれらが1つのシステムとして動作するように構成します。ハードウェアの集合(クラスタ)とともに、各コンポーネントの処理能力を結合して単一の堅牢なコンピューティング環境を構成します。Oracle RACは、Oracle Fusion Middlewareに対して、スケーラビリティおよび可用性の高いデータベースを提供します。

クラスタ内のすべてのOracle RACインスタンスは、同じアクセス権および認可レベルを持ちます。ノードおよびインスタンスに障害が発生しても、障害が発生していないサーバー・インスタンスでデータベース・サービスが利用可能であるか、利用可能な状態にすることができるため、パフォーマンスに影響を及ぼす場合はありますが、停止することはありません。

関連項目:
Oracle RACの詳細は、次のものを参照してください。

- Oracle Fusion Middleware Oracle WebLogic Serverクラスタの管理

- Oracle Real Application Clusters管理およびデプロイメント・ガイド

- Oracle Clusterware管理およびデプロイメント・ガイド

2.5 Coherenceクラスタと高可用性

『Oracle Fusion Middleware Oracle WebLogic ServerおよびCoherenceのインストールと構成』または製品固有のインストレーション・ガイドの手順に従っている場合、標準的なインストール・トロポジには、追加構成の開始点となるCoherenceクラスタが含まれます。

Coherenceクラスタは、Coherenceを実行するJava Virtual Machine (JVM)プロセスの集合です。12cでは、これらのプロセスをWebLogic管理対象Coherenceサーバーと呼びます。クラスタに参加しているJVMはクラスタ・メンバーまたはクラスタ・ノードです。クラスタ・メンバーには次のものが含まれます。

- 専用記憶域メンバー

- 記憶域が無効になっているクライアント・メンバー

- プロキシ・メンバー(Coherenceキャッシュにアクセスできる非クラスタ・メンバー)

クラスタ・メンバーどうしは、Tangosol Cluster Management Protocol (TCMP)を使用して通信します。クラスタ・メンバーでは、マルチキャスト通信(ブロードキャスト)とユニキャスト通信(Point-to-Point通信)の両方でTCMPを使用します。

Coherenceの特徴は次のとおりです。

- 各ドメインには通常、1つのCoherenceクラスタが含まれます。

- ドメイン内の各管理対象Coherenceサーバーは、Coherenceクラスタ・システム・リソースを通じて定義されるCoherenceクラスタに関連付けられます。

- 各アプリケーションのCoherence構成は、アプリケーションとともにすべての専用記憶域ノードにデプロイされるグリッド・アーカイブ(GAR)ファイル内にあります。

Coherenceを使用するすべてのアプリケーションは、管理対象Coherenceサーバーに関連付けられたクラスタを使用し、各アプリケーションと同じ場所にそれぞれのGARファイルをデプロイします。次の表に、Coherenceに関する参照情報を示します。

表2-3 CoherenceおよびCoherenceクラスタ

情報

参照先

Coherenceの概要と機能

『Oracle Fusion Middleware Oracle Coherenceでのアプリケーションの開発』のCoherenceの概要に関する項

Coherenceクラスタの作成

『Coherence管理者ガイド』のCoherence用のWebLogic Serverドメイン・トポロジの設定に関する項

Coherenceクラスタの構成

『Oracle WebLogic Serverクラスタの管理』のCoherenceクラスタの構成と管理に関する項

2.6 障害時リカバリ

可用性を最大限に高めるために、地理的に離れた複数の場所にサービスをデプロイして、予期せぬ障害や自然災害によるサイト全体の障害に備えることが必要な場合があります。Oracle Fusion Middleware製品は、バックアップとして機能する、地理的に離れたスタンバイ・サイトの構成をサポートしています。本番サイトで自然災害や計画外停電が発生した場合は、このバックアップにアプリケーションやサービスをフェイルオーバーすることができます。

障害時リカバリに関する詳細は、『Oracle Fusion Middlewareディザスタ・リカバリ・ガイド』を参照してください。

2.7 インストール時の構成(プロファイル)

この項の内容は次のとおりです。

- 第2.7.1項「ドメイン(トポロジ)プロファイル」

- 第2.7.2項「コンポーネント/サービスのデータベースとファイルの永続性プロファイル」

- 第2.7.3項「構成後のデフォルト設定」

2.7.1 ドメイン(トポロジ)プロファイル

ドメインを設定するには、構成ウィザードまたはWebLogic Scripting Tool (オフライン)を使用します。ドメインの作成、更新、構成の詳細は、『Oracle Fusion Middleware構成ウィザードによるWebLogicドメインの作成』を参照してください。

12c (12.2.1.0.0)のすべてのインストレーション・ガイドには、標準インストール・トポロジである単一マシンのマルチサーバー・ドメインを設定する手順が示されています。第1.6項「Oracle Fusion Middlewareの標準的なHAトポロジの理解」では、このトポロジの詳細を説明します。詳細は、次を参照してください。

- Oracle Fusion Middleware Oracle HTTP Serverのインストールと構成

- Oracle Fusion Middleware Oracle Fusion Middleware Infrastructureのインストールと構成

2.7.2 コンポーネント/サービスのデータベースとファイルの永続性プロファイル

永続性プロファイルとは、特定の永続環境の実現をするためにお薦めする設定の集合です。データベースとファイル・ベースの2種類の永続性プロファイルがあります。次の表に、それぞれのプロファイルの永続性タイプを示します。

表2-4 データベースおよびファイルの永続性プロファイルの永続性タイプ

コンポーネント/サービス

データベース永続性プロファイル

ファイル永続性プロファイル

JMS

データベース・ストア内のWLS JMS

ファイル・ストア内のWebLogic Server JMS

JTA

データベース・ストア内のJTA

ファイル・ストア内のJTA

OPSS

データベース・ストア

データベース・ストア

MDS

データベース・ストア

データベース・ストア

サービス表

データベース・ストア

データベース・ストア

フェイルオーバー

サーバー全体の移行

サーバー全体の移行

永続性プロファイルはコンポーネントやサービスと様々な組合せが可能ですが、永続性タイプのグループは最適な組合せで処理されます。それぞれのプロファイル内では、すべて同じオプションを使用することをお薦めします。

注意:
MDSデータ・ソースには、WebLogic Serverファイル永続性ストアがデータ・ソースとともに割り当てられています。ファイル永続性ストアを開発モードのみで使用するため、高可用性目的では無視できます。障害発生時にファイル永続性ストアをリカバリする必要ありません。

関連項目:
特定の製品および機能におけるデータベースのバージョン要件は、『相互運用性および互換性ガイド』のサポートされるデータベースとの相互運用性に関する項を参照してください。

2.7.3 構成後のデフォルト設定

標準的なインストールの後、ドメインはファイル・ベースの永続性プロファイルで設定されます。JMS/JTAリソースにデータベース・ベースの永続性を構成するには、第7章「JMSおよびJTAの高可用性」を参照してください。サーバー全体の移行を設定するには、第3章「サーバー全体の移行」を参照してください。

注意:
一部の製品は、共有ファイル・ストアに対して特定の要件が適用される場合がありますので、ご使用の製品の要件をよく確認してください。

次の表に、その他の参照情報を示します。

表2-5 ドメインの構成に関する各項

詳細情報

参照先

共有ファイル・システムでのファイル永続性プロファイルの使用

第4章「共有記憶域の使用」

JMSおよびJTA

第7.2項「JMSおよびJTAサービスのための移行可能ターゲットについて」

フェイルオーバー

2.3項「アプリケーション・フェイルオーバー」

2.8 アプリケーションおよびサービスのフェイルオーバー

WebLogic Serverにおける移行とは、クラスタ化されたWebLogic Serverインスタンスやクラスタ化されたインスタンスで実行されているコンポーネントを、障害が発生したときに別の場所に移動するプロセスのことです。サーバー全体の移行は、サーバー・インスタンスを物理的に別のシステムに移行したときに行います。サービスレベルの移行は、クラスタ内の別のサーバー・インスタンスにサービスを移動することを意味します。

この項では、JMSおよびJTAのサーバーとサービスのフェイルオーバーについて説明します。

2.8.1 自動移行サービス(JMS/JTA)について

WebLogic Server内のサービスレベルの移行とは、あるサーバー・インスタンスからクラスタ内の別の利用可能なサーバー・インスタンスに固定サービスを移動するプロセスのことです。

移行可能ターゲットを使用すると、JMSサービスやJTAサービスを構成して可用性を高めることができます。移行可能ターゲットとは、クラスタ内のサーバーから別のサーバーに移行できる特別なターゲットです。移行可能ターゲットを使用することにより、一緒に移行する必要のある移行可能サービスをグループ化できます。元のサーバー上で問題が発生した場合に、移行可能ターゲットをクラスタ・サーバー間で移行することにより、高可用性が実現します。移行可能ターゲットを移行すると、その対象によってホストされているすべてのサービスも移行されます。

製品で自動サービス移行がサポートされていない場合、全体サービス移行を使用できます。

関連項目:
詳細は、『Oracle Fusion Middleware Oracleクラスタの管理』で次のトピックを含むサービスの移行に関する項を参照してください。

- サービスの移行フレームワークの理解

- 移行前の要件

- JMS関連サービスの自動移行を構成する手順

- JTAトランザクション回復サービスの自動移行を構成する手順

2.9 高可用性トポロジの設定手順

次の表に、高可用性ミドルウェア・トポロジのサンプルを設定するために必要な高度な手順を示します。

表2-6 高可用性トポロジの設定手順

作業

説明

マニュアル

1. Real Application Clustersのインストール

Real Application Clustersをインストールします。

Oracle Real Application Clusters管理およびデプロイメント・ガイド

2. ミドルウェア・コンポーネントのインストールおよび構成

アプリケーションのインストレーション・ガイドの手順に従って、アプリケーションをインストールおよび構成します。

『Oracle Fusion Middleware Oracle Fusion Middleware Infrastructureのインストールと構成』または製品のインストレーション・ガイド

3. Oracle HTTP Serverのインストールおよび構成

同じドメインにOracle HTTP Serverをインストールおよび構成します。

Oracle HTTP Serverのインストールと構成

4. ロード・バランサの構成

特定の要件を満たすサード・パーティ製のロード・バランサ、またはOracle HTTP Server、Oracle Traffic Directorのいずれかを構成します。

第2.2項「高可用性環境でのサーバーのロード・バランシング」

5. Oracle Fusion Middleware Oracle Fusion Middlewareのトポロジのスケールアウト(マシンのスケールアウト)

手順に従って、Fusion Middleware WebLogic Serverドメイン内のすべての製品にトポロジをスケール・アウト(マシンをスケール・アウト)します。

第6章「トポロジのスケール・アウト(マシンのスケール・アウト)」

6. 管理サーバーの高可用性の構成

管理サーバーの高可用性を構成します。

第8章「管理サーバーの高可用性」

3 サーバー全体の移行

この項では、サーバー全体の移行およびそれを管理対象サーバーのフェイルオーバー用に構成する方法について説明します。サーバー全体の移行が行われると、障害の発生時に、サーバー・インスタンスが別の物理マシンに移行されます。使用する環境でJMSおよびJTAなどの特殊な(固定)サービスを使用している場合、サーバー全体の移行を構成する必要があります。

この項には次のトピックが含まれます:

- 第3.1項「サーバー全体の移行について」

- 第3.2項「管理対象サーバーのフェイルオーバー用のサーバー全体の移行の構成」

3.1 サーバー全体の移行について

クラスタは、クラスタ内の冗長化された管理対象サーバー上にオブジェクトやサービスを複製することによって、高可用性とフェイルオーバーを実現します。一方、JMSサーバーやJTAトランザクション回復サービスなどの一部のサービスは、クラスタ内で動作しているサービスのアクティブなインスタンスが常に1つのみ存在するという前提の下に設計されています。このようなタイプの場合、サーバー・インスタンス上で同時にアクティブな状態になるのは1つのみであるため、固定サービスと呼ばれます。

ほとんどのサービスがクラスタ内のすべての管理対象サーバーに均一にデプロイされることで、管理対象サーバー間の透過的なフェイルオーバーが可能になります。ただし、固定サービスは、クラスタ内の個別のサーバー・インスタンスをターゲットにします。固定サービスの場合、WebLogic Serverは、フェイルオーバーのかわりに、移行による障害リカバリをサポートしています。

WebLogic Serverには、JMSやJTAトランザクション・システムの可用性を高めるための機能(移行可能なサーバー)が用意されています。移行可能なサーバーは、サービスレベルではなく、サーバーレベルで自動または手動で移行できます。

移行可能なサーバーがなんらかの理由(ハング、ネットワークからの切断、ホスト・システムの障害など)で使用できなくなると、自動的に移行が行われます。障害が発生した場合、移行可能なサーバーは、可能であれば同じシステム上で自動的に再起動されます。障害が発生した同じシステム上で再起動できないときは、別のシステムに移行されます。また、手動でサーバー・インスタンスの移行を開始することもできます。

関連項目:

サーバー全体の自動移行の準備、サーバー全体の自動移行の構成、およびサーバーの移行プロセスおよび通信の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの管理』のサーバー全体の移行に関する項を参照してください。

サービス移行メカニズムの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの管理』のサービスの詳細に関する項を参照してください。

JMSおよびJTAサービスの詳細は、第7章「JMSおよびJTAの高可用性」を参照してください。

3.2 管理対象サーバーのフェイルオーバー用のサーバー全体の移行の構成

この項では、サーバー全体の移行を使用してフェイルオーバー用のクラスタを構成する、高レベルな手順を説明します。クラスタ内の1つのサーバーに障害が発生した場合、そのサーバーは、サーバー全体の移行によって別のマシン上で再起動されます。

サーバー全体の自動移行を構成するには、システムが特定の要件を満たす必要があります。Oracle WLSクラスタの管理のサーバー全体の自動移行の説明を参照してください。

サーバー全体の移行を構成するには、『Oracle WebLogic Serverクラスタの管理』のサーバー全体の移行の構成に関する項で示されている手順を実行します。

サーバー全体の移行の構成に関する詳細は、次の項目を参照してください。

- 「状態データ用の高可用性記憶域の使用方法」

- 「サーバー移行処理と通信」

第II部

高可用性環境の構築

第II部では、高可用性環境を作成する際の推奨事項および実行する手順について説明します。

この部の内容は次のとおりです。

- 第4章「共有記憶域の使用」

- 第5章「データベースに関する考慮事項」

- 第6章「トポロジのスケール・アウト(マシンのスケール・アウト)」

- 第7章「JMSおよびJTAの高可用性」

- 第8章「管理サーバーの高可用性」

4 共有記憶域の使用

この項では、高可用性環境で共有記憶域を使用する際の推奨事項について説明します。また、複数のホストやサーバーが共有する共通の場所にアーティファクトを配置する利点についても説明します。通常は、この共通の場所を共有ファイル・システムに配置し、NFSやCIFSのような標準のオペレーティング・システム・プロトコルを使用して、各サーバーからマウントします。

この項には次のトピックが含まれます:

- 第4.1項「共有記憶域の概要」

- 第4.2項「共有記憶域に関する前提条件」

- 第4.3項「バイナリ(Oracleホーム)ディレクトリ用の共有記憶域の使用」

- 第4.4項「ドメイン構成ファイル用の共有記憶域の使用」

- 第4.5項「JMSストアおよびJTAログ用の共有記憶域の要件」

- 第4.6項「ディレクトリ構造と構成」

4.1 共有記憶域の概要

共有記憶域では、動的状態およびサーバー構成が共有されます。これにより、管理、構成、フェイルオーバーおよびバックアップ/リカバリが簡略化されます。

高可用性環境でファイル・ベースの永続ストア(JMSおよびJTAログ用)や特定のOracle製品を使用する場合は、共有記憶域が必要になります。製品バイナリやドメイン・ディレクトリの共有記憶域はオプションです。

一般的に次のようなアーティファクトが共有ファイル・システムに配置されます。

- 製品バイナリ: 製品の実行可能ファイル、JARファイル、スクリプトに関連するすべてのファイルとディレクトリ(製品のインストール時にインストールされます)

- ドメイン・ディレクトリ: WebLogic Serverのドメインとその構成を含むディレクトリ

- ファイル・ベースの永続ストア: JMS永続性ログやJTAトランザクション・ログに使用するファイル・ベースの永続ストア

共有記憶域の詳細は、次の表を参照してください。

表4-1 共有記憶域に関する項目

項目/タスク

参照先

Oracleホームの構造とコンテンツ

『Oracle Fusion Middleware Oracle Fusion Middleware Infrastructureのインストールと構成』のOracle Fusion Middlewareインフラストラクチャのディレクトリ構造の理解に関する項

ファイル・ストアへのJMSおよびJTA情報の保存

WebLogic Server永続ストアの管理のWebLogic永続ストアに関する項。

『Oracle WebLogic Server JMSリソースの管理』の永続ストアの高可用性に関する項

『Oracle WebLogic Serverクラスタの管理』のJTAのデフォルト・ファイル・ストアの可用性に関する項

4.2 共有記憶域に関する前提条件

共有記憶域の次の前提条件は、ファイル・ベースの永続ストアを使用するときにのみ適用されます。

- 障害発生時に適切にリカバリできるようにするため、すべてのノードからアクセスできて、管理対象サーバーで障害が発生した後に操作を再開できる場所に、JMSとJTAトランザクションの両方のログを格納する必要があります。この設定には、複数のノードから参照できる共有記憶域の場所が必要です。推奨のディレクトリ構造については、第4.6項「ディレクトリ構造と構成」を参照してください。

- 共有記憶域のデバイスには、ネットワーク接続ストレージ(NAS)またはストレージ・エリア・ネットワーク(SAN)の使用をお薦めします。
NFSマウント・システムを使用する場合は、ファイルのロックに関連する問題および突然のノード障害が検出されます。第7.6項「NFSでのファイル・ストアの使用」を参照し、ストレージのベンダーに、マウント・オプションとして使用する主な推奨パラメータについて問い合せてください。

NASデバイス別のコマンド例を次に示します。注意: この例のオプションは、ご使用の環境のものと異なる場合がありますので、mountコマンドおよびそのオプションの詳細は、UNIXまたはLinuxのドキュメントを参照してください。

mount nasfiler:/vol/vol1/u01/oracle /u01/oracle -t nfs -o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768

- 可用性が最大になるよう、共有記憶域には高可用性NASデバイスまたはSANデバイスの使用をお薦めします。高可用性に対応していない共有記憶域デバイスはシングル・ポイント障害になる可能性があります。高可用性を実現するためのオプションについては、ストレージ・プロバイダに確認してください。

JMSおよびJTA情報のファイル・ストアでの保存の詳細は、WebLogic Server永続ストアの管理のWebLogic永続ストアに関する項を参照してください。

4.3 バイナリ(Oracleホーム)ディレクトリ用の共有記憶域の使用

次の項では、Oracleホーム・ディレクトリで共有記憶域を使用するためのガイドラインについて説明します。

- 第4.3.1項「バイナリ(Oracleホーム)・ディレクトリについて」

- 第4.3.2項「単一Oracleホームの共有について」

- 第4.3.3項「冗長バイナリ(Oracleホーム)・ディレクトリの使用について」

4.3.1 バイナリ(Oracleホーム)ディレクトリについて

Oracle Fusion Middleware製品をインストールする際には、Oracleホーム(ORACLE_HOME)に製品バイナリをインストールします。このバイナリ・ファイルは読取り専用であり、Oracleホームにパッチが適用されるか新しいバージョンにアップグレードされるまで変更されることはありません。

通常の製品環境では、Oracleホーム・ファイルは、Oracle Fusion Middleware構成ウィザードを使用して作成したドメイン構成ファイルとは別の場所に保存されます。

Oracle Fusion Middlewareインストール用のOracleホームには、Oracle WebLogic Serverのバイナリ、Oracle Fusion Middlewareインフラストラクチャ・ファイルおよび任意のOracle Fusion Middleware製品固有のディレクトリが含まれています。

注意:
デフォルトでは、構成ウィザードはOracleホーム内のログ・ディレクトリにログを書き込みます。読取り専用のOracleホームを使用する場合は、-logオプションを指定して、別のディレクトリにログを転送する必要があります。

関連項目:
Oracleホームの構造とコンテンツの詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareコンセプトの理解』の「Oracle Fusion Middlewareの主要ディレクトリとは」を参照してください。

4.3.2 単一Oracleホームの共有について

複数のサーバーを単一Oracleホームから構成できます。これにより、共有ボリューム上の1つの場所にOracleホームをインストールして、複数のサーバーをインストールするためにOracleホームを再利用できます。

Oracleホームが、異なるホスト上の複数のサーバーで共有されている場合、実施する必要のあるいくつかのベスト・プラクティスがあります。たとえば、Oracleインベントリ・ディレクトリ(oraInventory)は、Oracleホームが最初にインストールされたホストからのみ更新されるため、Oracleホームで実行するその後のすべての操作(パッチ適用やアップグレードなど)は、元のホストから実行することをお薦めします。そのホストが使用できない場合は、もう一方のホストからOracleホームにパッチやアップグレードを適用する前に、必ず別のホスト上でOracleインベントリが更新されるようにしてください。

oraInventoryの詳細は、Oracle Universal Installerコンセプト・ガイドのOracle Universal Installerインベントリに関する項を参照してください。

4.3.3 冗長なバイナリ(Oracleホーム)ディレクトリの使用について

可用性が最大になるように、共有記憶域上でバイナリの冗長インストールを使用することをお薦めします。

このモデルでは、Oracle Fusion Middlewareソフトウェアの2つの同じOracleホームを2つの異なる共有ボリュームにインストールします。まず、Oracleホームの1つをサーバーの1セットにマウントし、もう一方を残りのサーバーにマウントします。いずれのOracleホームも同じマウント・ポイントを持つため、サーバーがどのOracleホームを使用しているかにかかわらず、Oracleホームは常に同じパスを持ちます。

片方のOracleホームが破損したり使用不可になっても、影響を受けるのは半分のサーバーのみです。さらに保護を強化するために、これらのボリュームのディスク・ミラーを行うことをお薦めします。影響を受けたサーバーの機能は、影響を受けていないOracle Homeを再マウントするだけで、完全にリストアできます。

共有記憶域で個別ボリュームが使用不可の場合、同じボリューム内の別々のディレクトリを使用して個別ボリュームをシミュレートしたり、ホスト側の同じマウント場所に個別ボリュームをマウントしたりすることをお薦めします。これによって複数のボリュームによる保護が保証されるわけではありませんが、ユーザーによる削除や個々のファイルの破損からは保護されます。

注意:
最大の保護を得るには、クラスタのメンバーを、冗長なバイナリOracleホーム全体に、均等に分散することをお薦めします。これは、クラスタのメンバーが使用可能なすべてのサーバー上で実行されてはいない場合に、特に重要です。

4.4 ドメイン構成ファイル用の共有記憶域の使用

次の項では、エンタープライズ・デプロイメントでOracle Fusion Middleware製品を構成する際に作成するOracle WebLogic Serverドメイン構成ファイルで共有記憶域を使用するためのガイドラインについて説明します。

- 第4.4.1項「Oracle WebLogic Server管理サーバーおよび管理対象サーバーのドメイン構成ファイルについて」

- 第4.4.2項「管理サーバー構成ディレクトリの共有記憶域に関する考慮事項」

- 第4.4.3項「管理対象サーバー構成ファイルの共有記憶域に関する考慮事項」

4.4.1 Oracle WebLogic Server管理および管理対象サーバー・ドメイン構成ファイルについて

Oracle Fusion Middleware製品を構成すると、Oracle WebLogic Serverドメインが作成または拡張されます。各Oracle WebLogic Serverドメインは、1つの管理サーバーおよび1つ以上の管理対象サーバーで構成されます。

WebLogicは、管理サーバーの永続的な変更内容をすべての管理対象サーバーにプッシュするために、レプリケーション・プロトコルを使用します。これにより、管理サーバーが稼働していなくても、管理対象サーバーに冗長性がもたらされます。これを管理対象サーバーの独立モードと呼びます。

Oracle WebLogic Serverドメインの詳細は、Oracle WebLogic Serverドメイン構成の理解を参照してください。

4.4.2 管理サーバー構成ディレクトリの共有記憶域に関する考慮事項

ドメイン構成ファイルを共有記憶域に格納することは必須ではありません。しかし、管理サーバーのリカバリをサポートするためには、管理サーバーの構成ディレクトリを共有記憶域に配置し、管理サーバーが稼働しているホストでマウントする必要があります。そのホストに障害が発生した場合は、そのディレクトリを別のホストでマウントし、障害の発生した管理サーバーを別のホストで復旧することができます。第8章「管理サーバーの高可用性」を参照してください。

4.4.3 管理対象サーバー構成ファイルの共有記憶域に関する考慮事項

管理対象サーバーの構成ファイルは、ローカル(ホストのプライベート記憶域)に保存することをお薦めします。

管理対象サーバーの構成ファイルを共有記憶域に保存できます。ただし、そうすることで、複数のサーバーが同じ記憶域ボリュームにアクセスするようになるため、パフォーマンスに影響する可能性があります。

4.5 JMSストアおよびJTAログ用の共有記憶域の要件

高可用性設定でファイル・ベースの永続性を使用する場合は、JMS永続ストアとJTAトランザクション・ログのディレクトリが共有記憶域に配置されるように構成する必要があります。

詳細は、第7.5項「ファイル永続性を使用するうえでの考慮事項(WebLogic JMS)」を参照してください。

4.6 ディレクトリ構造と構成

共有記憶域を使用する場合、記憶域の要素をレイアウトする方法は複数あります。次のベスト・プラクティスを使用することをお薦めします。

表4-2 共有記憶域要素のディレクトリ構造

要素

場所

ORACLE_HOME

すべてのサーバーにより、読取り専用モードで共有されます。

JMSファイル・ストアおよびトランザクション・ログ

ファイルベースの永続性を使用する場合は、共有記憶域に配置されます。

管理サーバー・ドメインの構成ディレクトリ

管理サーバーの別のホストへのフェイルオーバーを容易にするため、共有記憶域に配置されます。

注意:
管理対象サーバーのドメイン構成ディレクトリは、対応するホストのローカル記憶域に配置します。詳細は、第4.4.2項「管理サーバー構成ディレクトリの共有記憶域に関する考慮事項」を参照してください。

次の図は、ディレクトリ構造を表しています。

図4-1 共有記憶域のディレクトリ構造

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

この項では、Oracle Fusion Middlewareの高可用性を設定して、データベース接続を構成するときの考慮事項について説明します。また、よくデプロイされるデータベースの高可用性ソリューションでOracle Real Application Clusters (Oracle RAC)を使用する利点についても説明します。コンポーネントのほとんどでは、そのデータの永続ストアとしてデータベースが使用されます。ここでOracle Databaseを使用すると、高可用性の様々な構成が可能になります。

データベースのオプションの詳細は、『Oracle Database高可用性概要』を参照してください。

この項の内容は次のとおりです。

- 第5.1項「Oracle Real Application Clustersについて」

- 第5.2項「Oracle Real Applicationクラスタの設定手順」

- 第5.3項「RACのデータベース接続およびフェイルオーバーについて」

- 第5.4項「データ・ソースについて」

- 第5.5項「Oracle RACでのアクティブなGridLinkデータ・ソースの構成」

- 第5.6項「マルチ・データ・ソースの構成」

5.1 Oracle Real Application Clustersについて

クラスタは、相互に接続された複数のコンピュータまたはサーバーで構成され、エンド・ユーザーおよびアプリケーションからは1つのサーバーとして認識されます。Oracle RACは、Oracle Databaseのクラスタを構成し、スケーラビリティおよび可用性に優れています。

Oracle WebLogic ServerにデプロイされるOracle Fusion Middlewareコンポーネントはすべて、Oracle RACをサポートします。

クラスタ内のすべてのOracle RACインスタンスは、同じアクセス権および認可レベルを持ちます。ノードおよびインスタンスに障害が発生しても、障害が発生していないサーバー・インスタンスでデータベース・サービスが利用可能であるか、利用可能な状態にすることができるため、パフォーマンスに影響を及ぼす場合はありますが、停止することはありません。

5.2 Oracle Real Applicationクラスタの設定手順

次の表に、タスクの概要と、Oracle RAC設定の参照先を示します。

表5-1 Oracle RACの設定手順

タスク/項目

参照先

Oracle RACについて

『Oracle Real Application Clusters管理およびデプロイメント・ガイド』のOracle RACの概要に関する項

Oracle RACのインストール

Oracle Real Application Clusters管理およびデプロイメント・ガイド

Oracle RACの管理

『Oracle Real Application Clusters管理およびデプロイメント・ガイド』のOracle RAC環境の管理の概要に関する項

GridLinkおよびマルチ・データ・ソースの構成とチューニング

Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理

単一クライアント・アクセス名(SCAN)のURLの構成(WebLogicコンソールで、TNSおよびONSのリスナーに使用するホストとポートを指定します)

『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のSCANアドレスに関する項。

5.3 RACのデータベース接続およびフェイルオーバーについて

接続プールを確立する場合、Oracle Fusion Middlewareでは、XA JDBCドライバとXA以外のJDBCドライバ両方に対して、Oracle RACバックエンドのアクティブなGridLinkデータ・ソースおよびマルチ・データ・ソースがサポートされます。これらのデータ・ソースでも同様に、Oracle RACノード全体のロード・バランシングがサポートされます。

Oracle RACのノードまたはインスタンスに障害が発生すると、WebLogic ServerまたはOracle Thin JDBCドライバによって、セッション・リクエストがクラスタ内の別のノードにリダイレクトされます。既存の接続はフェイルオーバーしません。新しいアプリケーションの接続要求は、WebLogicプールの既存の接続を使用して処理されるか、稼働中のOracle RACインスタンスへの新しい接続によって処理されます。

データベースがトランザクション・マネージャの場合、通常、進行中のトランザクションはロールバックされます。

WebLogic Serverがトランザクション・マネージャの場合、進行中のトランザクションはフェイルオーバーされ、障害発生時のトランザクションの状態に基づいて、完了するかロールバックするかが判断されます。

XAトランザクションの詳細は、第5.3.1項「XAトランザクションについて」を参照してください。

5.3.1 XAトランザクションについて

XAトランザクションは、同一のトランザクション内から複数のリソース(データベース、アプリケーション・サーバー、メッセージ・キュー、トランザクション・キャッシュなど)にアクセスできます。XA以外のトランザクションに関係するリソースは、常に1つのみです。

XAトランザクションは、1つ以上のデータベースや、JMSのような他のリソースとのトランザクション調整マネージャを使用し、これらをすべて単一グローバル・トランザクションに集約しています。

Java EEでは、用語のJTAトランザクション、XAトランザクション、ユーザー・トランザクション、グローバル・トランザクションと同じ意味で、グローバル・トランザクションと呼ぶ場合もあります。このトランザクション・タイプには、複数の異なるXA対応のリソースやXA以外のリソース、さらには異なるリソース・タイプの操作も含まれる場合があります。JTAトランザクションは、常に現在のスレッドに関連付けられており、1つのアプリケーション呼出しとしてサーバー間で受け渡すこともできます。一般的なXAトランザクションの例は、WebLogic JMSとJDBC (データベース)の両方の操作を含む構成です。

5.4 データ・ソースについて

データ・ソースは、リレーショナル・データベースへの接続を取得するためにコンポーネントで使用する抽象概念です。URLまたはユーザー名とパスワードなどの特定の接続情報が、データ・ソース・オブジェクト上でプロパティとして設定されます。アプリケーション・コードで、プロパティを明示的に定義する必要はありません。この抽象化により、アプリケーションが特定のバックエンド・データベースに関連付けらなくなるため、アプリケーションをポータブルな方法で構築できます。データベースは、アプリケーション・コードに影響を与えずに変更できます。

アクティブなGridLinkデータ・ソースとマルチ・データ・ソースが、データベース接続の高可用性、ロード・バランシング、フェイルオーバーをサポートします。ご使用のOracle RACデータベース・バージョンに応じて、次のデータ・ソース・タイプをお薦めします。

- Oracle RACデータベースのバージョンが11gリリース2以降の場合は、アクティブなGridLinkデータ・ソースを使用します。

- Oracle RACデータベースのバージョンが11gリリース2より前の場合や、Oracle Database以外のデータベースを使用している場合は、マルチ・データ・ソースを使用します。

注意:
Oracle RACデータベースの可用性を最大限に高めるために、アクティブなGridLinkデータ・ソースの使用をお薦めします。アクティブなGridLinkデータ・ソースをサポートしていないOracle RACデータベースのバージョンの場合は、マルチ・データ・ソースを使用して可用性を高めることをお薦めします。

データ・ソース・タイプの詳細は、次の各項を参照してください。

- 第5.4.1項「アクティブなGridLinkデータ・ソース」

- 第5.4.2項「マルチ・データ・ソース」

5.4.1 アクティブなGridLinkデータ・ソース

アクティブなGridLinkデータ・ソースは、Oracle RACクラスタに含まれる可能性があるWebLogic ServerとOracle Databaseサービス間の接続を提供します。アクティブなGridLinkデータ・ソースには、汎用データ・ソースの機能に加え、Oracle RACに対する次のサポートがあります。

- ONSを使用して、Oracle RACにおける状態変化に対応します。

- 高速アプリケーション通知(FAN)イベントに応答して、高速接続フェイルオーバー(FCF)、ランタイム接続ロード・バランシング、およびRACインスタンスの正常な停止を提供します。FANは、構成やワークロードに関するアラートをアプリケーションにすばやく伝えることができる、Oracle RACの通知メカニズムです。

- セッションのすべてのデータベース操作がRACクラスタの同じインスタンスに送信されて、最適なパフォーマンスが得られるように、アフィニティ(XAアフィニティ)ポリシーを提供します。

- SCANアドレス

- Oracleウォレットを使用したセキュアな通信

次の各トピックの詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のアクティブなGridLinkデータ・ソースの使用に関する項を参照してください。

- アクティブなGridLinkデータ・ソースとは

- ソケット・ダイレクト・プロトコルの使用

- 接続プール機能の構成

- Oracleパラメータの構成

- ONSクライアントの構成

- アクティブなGridLinkデータ・ソース接続プールのチューニング

- GridLink JDBCリソースのモニタリング

5.4.2 マルチ・データ・ソース

マルチ・データ・ソースとは、データ・ソースのグループに関する抽象化のことです。この抽象化により、ロード・バランシングやフェイルオーバー処理を実現します。マルチ・データ・ソースは、XAデータ・ソースとXA以外のデータ・ソース両方のロード・バランシングをサポートします。

マルチ・データ・ソースでは、接続リクエストを満たすために、データ・ソースの順序付きリストが提供されます。通常、このようなマルチ・データ・ソースへの接続リクエストはすべて、リストの先頭のデータ・ソースによって処理されます。データベース接続テストが失敗して接続を置き換えられなかった場合、またはデータ・ソースが中断された場合は、リストの次のデータ・ソースから順番に接続が検索されます。

マルチ・データ・ソースは、通常のデータ・ソースと同様に、JNDIツリーまたはローカル・アプリケーション・コンテキストにバインドされます。アプリケーションは、単純なデータ・ソースと同様に、JNDIツリーまたはローカル・アプリケーション・コンテキスト(java:comp/env)でマルチ・データ・ソースを検索してから、データベース接続を要求します。マルチ・データ・ソースによって、マルチ・データ・ソース構成で選択されたアルゴリズム(ロード・バランシングまたはフェイルオーバー)に応じて、リクエストに対応するために使用するデータ・ソースが決定します。

関連項目:
Oracle RACでのマルチ・データ・ソースの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のOracle RACでのマルチ・データ・ソースの使用に関する項を参照してください。

5.5 Oracle RACでのアクティブなGridLinkデータ・ソースの構成

Active GridLinkデータ・ソースの構成は、次の内容により異なります。

- 操作しているOracleコンポーネント

- 作成しているドメイン

この項では、ドメインの作成時に、RACデータベース用のアクティブなGridLinkデータ・ソースとして、コンポーネント・データ・ソースを構成する方法について説明します。

この項の内容は次のとおりです。

- 第5.5.1「アクティブなGridlinkデータ・ソースとしてのコンポーネント・データ・ソースを構成するための要件」

- 第5.5.2項「アクティブなGridLinkデータ・ソースとしてのコンポーネント・データ・ソースの構成」

- 第5.5.3項「ホストおよびポートでのSCANアドレスの使用方法」

関連項目:
アクティブなGridLinkデータ・ソースの作成および構成方法については、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のアクティブなGridlinkデータ・ソースの使用に関する項を参照してください。

5.5.1 アクティブなGridlinkデータ・ソースとしてのコンポーネント・データ・ソースを構成するための要件

Oracle RACデータベースで使用するアクティブなGridLinkデータ・ソースとしてコンポーネント・データ・ソースを構成する前に、システムが次の要件を満たしている必要があります。

- Oracle RACデータベースのバージョン11gリリース2以降を使用している。

- RCUを実行してコンポーネント・スキーマが作成されている。

- ドメインを作成または構成するための構成ウィザードで、「JDBCコンポーネント・スキーマ」画面まで進み、「コンポーネント・データソース」を選択する。

5.5.2 アクティブなGridLinkデータ・ソースとしてのコンポーネント・データ・ソースの構成

アクティブなGridLinkデータ・ソースとしてコンポーネント・データ・ソースを構成するには、次の手順を実行します。

1. 「JDBCコンポーネント・スキーマ」画面で、1つ以上のコンポーネント・スキーマを選択してGridLinkデータ・ソースを構成します。

2. 「GridLinkへ変換」を選択して、「次へ」を選択します。

3. 「GridLink Oracle RACコンポーネント・スキーマ」画面で、いずれかのGridLink JDBCドライバを選択します。

4. 「サービス名」フィールドに、データベースのサービス名を小文字で入力します。たとえば、mydb.example.comです。

5. 「スキーマ所有者」フィールドに、対応するコンポーネントのデータベース・スキーマ所有者の名前を入力します。

6. 「スキーマ・パスワード」フィールドに、データベース・スキーマ所有者のパスワードを入力します。

7. 「サービス・リスナー」、「ポート」、「プロトコル」の各フィールドに、RACデータベースで使用するSCANアドレスとポートを入力します。イーサネット用のプロトコルはTCP、Infinibandの場合はSDPです。複数のリスナーのアドレスを入力する場合は、「追加」をクリックします。
SCANアドレスは、TCPプロトコルを使用してデータベース内の適切なパラメータを問い合せることで識別できます。

show parameter remote_listener

NAME TYPE VALUE

--------------------------------------------------------------------

remote_listener string db-scan.example.com:1521

SCANアドレスの識別には、srvctl config scanコマンドを使用することもできます。SCANリスナー・ポートを識別する場合は、コマンドsrvctl config scan_listenerを使用します。

8. 「FANの有効化」を選択して、FANイベントを受信および処理できるようにします。アドレスおよびポート情報をリスニングするONSデーモンを1つ以上入力します。複数のエントリを入力する場合は、「追加」を選択します。

注意:
ONSデーモン用に入力したリスニング・アドレスが有効かどうかを検証してください。ドメインの作成プロセスでは、アドレスは検証されません。

ONSホスト・アドレスの場合は、Oracle RACデータベースのSCANアドレスおよびデータベースから報告されたONSリモート・ポートを使用します。

srvctl config nodeapps -s

ONS exists: Local port 6100, remote port 6200, EM port 2016

9. ONSとSSL通信を行うために「SSLの有効化」を選択します。SSL証明書を格納するウォレット・ファイルを入力し、ウォレットのパスワードを入力します。

10. 「次へ」を選択します。すべての接続が正常かどうかを検証します。

関連項目:
詳細は、次を参照してください:

- 「JDBCコンポーネント・スキーマ」画面の詳細は、『Oracle Fusion Middleware構成ウィザードによるWebLogicドメインの作成』のJDBCコンポーネント・スキーマに関する項を参照してください。

- コンポーネント・スキーマの構成方法の詳細は、『Oracle Fusion Middleware構成ウィザードによるWebLogicドメインの作成』のGridLink Oracle RACコンポーネント・スキーマに関する項を参照してください。

- GridLink RACデータ・ソースの詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のアクティブなGridLinkデータ・ソースの使用に関する項を参照してください。

5.5.3 ホストおよびポートでのSCANアドレスの使用方法

WebLogicコンソールでTNSリスナーとONSリスナーにホストおよびポートを指定するには、Oracle単一クライアント・アクセス名(SCAN)アドレスを使用することをお薦めします。Oracle RACノードを追加または削除する場合、SCANアドレスを含むアクティブなGridLinkデータ・ソースを更新する必要はありません。ご使用の環境に対して適切に構成されたSCAN URLについては、御社のネットワーク管理者に問い合せてください。『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のSCANアドレスに関する項を参照してください。

5.6 マルチ・データ・ソースの構成

マルチ・データ・ソースは、次のものを使用して構成します。

- Oracle Fusion Middlewareの構成ウィザード(WebLogic Serverドメインの作成時)

- Oracle WebLogic Server管理コンソール

- WLSTコマンド

この項の内容は次のとおりです。

- 第5.6.1項「Oracle RACでのマルチ・データ・ソースの構成」

- 第5.6.2項「MDSリポジトリのためのマルチ・データ・ソースの構成」

5.6.1 Oracle RACでのマルチ・データ・ソースの構成

この項の内容は次のとおりです。

- 第5.6.1.1項「Oracle RACでのマルチ・データ・ソースを構成するための要件」

- 第5.6.1.2項「マルチ・データ・ソースとしてのコンポーネント・データ・ソースの構成」

- 第5.6.1.4項「初期構成後のマルチ・データ・ソースの変更または作成」

- 第5.6.1.6項「トランザクション・リカバリ権限のスキーマの構成」

5.6.1.1 Oracle RACでのマルチ・データ・ソースを構成するための要件

マルチ・データ・ソースとして、Oracle RACデータベース用のコンポーネント・データ・ソースを構成する前に、次の要件が満たされていることを確認します。

- Oracle RACデータベースを使用している。

- RCUを実行してコンポーネント・スキーマが作成されている。

- ドメインを作成または構成するための構成ウィザードで、「JDBCコンポーネント・スキーマ」画面まで進み、「コンポーネント・スキーマ」を選択する。「JDBCコンポーネント・スキーマ」画面まで進む前に、「データベース構成タイプ」画面で「手動構成」オプションを選択する必要があります。

5.6.1.2 マルチ・データ・ソースとしてのコンポーネント・データ・ソースの構成

マルチ・データ・ソースとしてコンポーネント・データ・ソースを構成するには、次の手順を実行します。

1. 「コンポーネント・データソース」画面で、1つ以上のコンポーネント・スキーマを選択してRACマルチ・データ・ソースを構成します。

2. 「RACマルチ・データ・ソースへ変換」を選択し、「次へ」を選択します。

3. 「Oracle RACマルチ・データ・ソース・コンポーネント・スキーマ」画面で、JDBCドライバにOracle RACサービス・インスタンス接続用Oracleのドライバ(Thin)、バージョン:10以降を選択します。

4. 「サービス名」フィールドに、データベースのサービス名を小文字で入力します(例: mydb.example.com)。

5. 「スキーマ所有者」フィールドに、対応するコンポーネントのデータベース・スキーマ所有者のユーザー名を入力します。

6. 「スキーマ・パスワード」フィールドに、データベース・スキーマ所有者のパスワードを入力します。

7. 「ホスト名」、「インスタンス名」、「ポート」の各フィールドに、RACノードのホスト名、データベース・インスタンス名、ポート番号を入力します。複数のリスナーのアドレスを入力する場合は、「追加」をクリックします。

8. 「次へ」をクリックします。すべての接続が正常かどうかを検証します。

5.6.1.3 マルチ・データ・ソースのRACデータベースへの追加について

マルチ・データ・ソースには、データベース・サービスを提供するRACインスタンスごとの構成データ・ソースが存在します。RACのバックエンドにインスタンスを追加する場合は、Fusion Middleware層でマルチ・データ・ソースにデータ・ソースを追加することをお薦めします。

非RACのデータベースをRACデータベースに移行する場合は、影響を受けるデータ・ソースごとに同等のマルチ・データ・ソースを新しく作成する必要があります。作成するマルチ・データ・ソースには、各RACインスタンスを構成するデータ・ソースが必要です。データ・ソースのプロパティ値は、第5.6.1項で説明するプロパティに関して、元の単一インスタンス・データ・ソースの値と同じである必要があります。たとえば、単一インスタンス・データ・ソース・ドライバがoracle.jdbc.xa.client.OracleXADataSourceである場合、新しいマルチ・データ・ソースの各構成データ・ソースのドライバはoracle.jdbc.xa.client.OracleXADataSourceである必要があります。

5.6.1.4 初期構成後のマルチ・データ・ソースの変更または作成

手動で作成されたマルチ・データ・ソースまたは初期構成の後に変更されたマルチ・データ・ソースについては、可用性を最大限に高めるために、次のXAデータ・ソースおよびXA以外のデータ・ソースのプロパティ値に設定することを強くお薦めします。環境の要件により変更が必要な場合は、検討とテストを十分に行ってから変更してください。

次の各表は、XAおよびXA以外のデータ・ソースについて、プロパティの推奨値を示しています。

表5-2 推奨されるマルチ・データ・ソース構成

プロパティ名

推奨値

test-frequency-seconds

5

algorithm-type

ロード・バランシング

高可用性環境では、個々のデータ・ソースに対して次の設定をお薦めします。その他のパラメータについても、アプリケーション要件に従って設定することをお薦めします。

表5-3 XAデータ・ソース構成

プロパティ名

推奨値

ドライバ

oracle.jdbc.xa.client.OracleXADataSource

プロパティ・コマンド

<property>

<name>oracle.net.CONNECT_TIMEOUT</name>

<value>10000</value>

</property>

initial-capacity

0

connection-creation-retry-frequency-seconds

10

test-frequency-seconds

300

test-connections-on-reserve

true

test-table-name

SQL SELECT 1 FROM DUAL

seconds-to-trust-an-idle-pool-connection

0

global-transactions-protocol

TwoPhaseCommit

keep-xa-conn-till-tx-complete

true

xa-retry-duration-seconds

300

xa-retry-interval-seconds

60

5.6.1.5 警告メッセージのトラブルシューティング(XAデータ・ソースのトランザクション・タイムアウト値の増加)

サーバー・ログに次の例外を含む警告メッセージが表示された場合は、XAのタイムアウトの設定値を増やす必要があります。

[javax.transaction.SystemException: Timeout during commit processing

XAデータ・ソース設定のトランザクション・タイムアウト値を増やすには、管理コンソールで次の手順を実行します。

1. データ・ソース構成にアクセスします。

2. 「トランザクション」タブを選択します。

3. XAトランザクション・タイムアウトを、300のように大きな値に設定します。

4. 「XAトランザクション・タイムアウトの設定」チェック・ボックスを選択します。このチェック・ボックスは、新しいXAトランザクション・タイムアウト値を有効にするために選択する必要があります。

5. 「保存」をクリックします。

XAマルチ・データ・ソースの個々のデータ・ソースすべてに対してこの構成を繰り返します。

表5-4 XA以外のデータ・ソース構成

プロパティ名

推奨値

ドライバ

oracle.jdbc.OracleDriver

設定するプロパティ

<property>

<name>oracle.net.CONNECT_TIMEOUT</name>

<value>10000</value>

</property>

initial-capacity

0

connection-creation-retry-frequency-seconds

10

test-frequency-seconds

300

test-connections-on-reserve

true

test-table-name

SQL SELECT 1 FROM DUAL

seconds-to-trust-an-idle-pool-connection

0

global-transactions-protocol

なし

5.6.1.6 トランザクション・リカバリ権限のスキーマの構成

次の操作に対してWebLogic Serverのトランザクション・マネージャを有効にするには、適切なデータベース権限が必要です。

- トランザクション状態情報の問合せ

- WebLogic Serverコンテナで障害が発生した後の処理中トランザクションのリカバリ時における、コミットやロールバックなどの適切なコマンドの発行

トランザクション・リカバリ権限のスキーマを構成する手順は次のとおりです。

1. sysdba権限を持つユーザーとしてSQL*Plusにログオンします。例:

sqlplus "/ as sysdba"

2. sys.dba_pending_transactionsに対してselectをappropriate_userに付与します。

3. 任意のトランザクションに対してforceをappropriate_userに付与します。

5.6.2 MDSリポジトリのためのマルチ・データ・ソースの構成

MDSデータベース・ベースのリポジトリを使用するアプリケーションは、高可用性Oracleデータベースへのアクセス用に構成できます。この構成により、MDS(およびWebLogicインフラストラクチャ)による障害検出、リカバリおよび再試行が、アプリケーションの読取り専用のMDS操作を、Oracle RACデータベースの計画停止および計画外停止から保護します。

Fusion Middleware Controlのナビゲーション・ツリーに、マルチ・データ・ソースがMDSリポジトリとして公開されます。これらのマルチ・データ・ソースは、アプリケーション・デプロイメントのカスタマイズ時に選択したり、MDS WLSTコマンドで使用することもできます。

- 読取り専用操作を再試行できるようなアプリケーションの構成
接続を再試行できるようにアプリケーションを構成するには、アプリケーションのMDS AppConfig MBeanのRetryConnection属性を構成します。『Oracle Fusion Middleware管理者ガイド』を参照してください。

- MDSマルチ・データ・ソースの登録
第5.6.1項「Oracle RACでのマルチ・データ・ソースの構成」で説明した手順以外にも、次の点に注意してください。

- MDSリポジトリに使用されるマルチ・データ・ソースを構成する子データ・ソースは、XA以外のデータ・ソースとして構成する必要があります。

- マルチ・データ・ソースの名前には、接頭辞mds-を付ける必要があります。これにより、MDS管理機能に使用できるMDSリポジトリとして、マルチ・データ・ソースが認識されるようになります。

注意:
MDSデータ・ソースをマルチ・データ・ソースの子として追加すると、このデータ・ソースはMDSリポジトリとしては公開されなくなります。Fusion Middleware Controlのナビゲーション・ツリーの、「メタデータ・リポジトリ」フォルダの下には表示されません。それに対するMDSリポジトリの操作を実行できず、選択可能なリポジトリのリストにデプロイメント時に表示されません。

- マルチ・データ・ソースへのデータ・ソースの変換
データ・ソースをマルチ・データ・ソースに変換して、アプリケーションの構成を検証する場合は、次の2点を考慮する必要があります。

- 新しい一意の名前を持つマルチ・データ・ソースを新規作成するには、アプリケーションを再デプロイして、デプロイメント・プランのカスタマイズ時に、この新しいマルチ・データ・ソースをMDSリポジトリとして選択します。

- アプリケーションの再デプロイを回避するには、データ・ソースを削除し、同じ名前とjndi-name属性を使用して、新しいマルチ・データ・ソースを再作成できます。

6 トポロジのスケール・アウト(マシンのスケール・アウト)

この項では、WebLogic Serverドメイン内のすべてのFusion Middleware製品にトポロジをスケール・アウト(マシンをスケール・アウト)する手順について説明します。高可用性を実現するためには、別のホスト・コンピュータへのフェイルオーバー機能を備える必要があります。そうすることで、1台のコンピュータが停止した場合に、デプロイ済アプリケーションの環境を中断させることなく、ユーザーに継続してサービスを提供できます。

この項の内容は次のとおりです。

- 第6.1項「マシンのスケール・アウトについて」

- 第6.2項「トポロジのスケール・アウト手順」

- 第6.3項「オプションのスケール・アウト手順」

- 第6.4項「スケール・アウトの前提条件について」

- 第6.5項「リソース要件」

- 第6.6項「新しいマシンの作成」

- 第6.7項「マシンのスケール・アップまたはスケール・アウト後のWLS JMSの構成」

- 第6.8項「APPHOST1上のドメインのパック」

- 第6.9項「新しいマシンの準備」

- 第6.10項「テンプレートを転送するためのアンパックの実行」

- 第6.11項「ノード・マネージャの起動」

- 第6.12項「管理対象サーバーの起動」

- 第6.13項「マシンのスケール・アウトの検証」

- 第6.14項「クラスタ用マルチキャスト・メッセージの構成」

6.1 マシンのスケール・アウトについて

スケーラビリティとは、将来のニーズや状況に応じて、ハードウェア、ソフトウェア、ネットワークの構成を拡張または縮小できる能力を表します。スケーラブルなシステムとは、リクエストが増加してもレスポンス時間およびスループットに悪影響をもたらすことなく処理できるシステムです。

マシンのスケール・アウトとは、高可用性を実現するために、1つのマシン上に複数あるサーバーの1つを別のマシンに移行するプロセスを表します。マシンのスケール・アウトは、管理対象サーバーのスケール・アップとは異なります(管理対象サーバーのスケール・アップとは、すでに1つ以上の管理対象サーバーが稼働しているマシンに対して新しい管理対象サーバーをマシンに追加するプロセスです)。『Oracle Fusion Middleware Oracle Fusion Middlewareの管理』の環境のスケール・アウトに関する項を参照してください。

6.2 トポロジのスケール・アウト手順

次の表は、トポロジをスケール・アウトするときに必要となる、一般的な手順を示しています。

標準トポロジがすでにインストールされている場合(『Oracle Fusion Middleware Oracle Fusion Middleware Infrastructureのインストールと構成』および『Oracle Fusion Middleware Oracle SOA SuiteおよびBusiness Process Managementのインストールと構成』などの製品のインストレーション・ガイドで説明するとおり)、第6.5項、第6.6項および第6.7項の手順を繰り返す必要はありません。次の表では、トポロジの標準インストール手順を完了していない場合の、初めから終わり間瀬の手順を示します。

表6-1 トポロジのスケール・アウト手順

作業

説明

参照先

スケール・アウト用の製品の準備

製品のインストールと構成を行い、管理対象サーバーのクラスタを有効にして、標準的なインストール・トポロジに製品を配置します。

第6.4項「スケール・アウトの前提条件について」

リソース要件を満たしているかどうかの確認

ご使用の環境が特定の要件を満たしているかどうかを確認する必要があります。

第6.5項「リソース要件」

新しいマシンの作成およびサーバーの割当て

管理コンソールを使用して、新しいマシンを作成し、それに管理対象サーバーを追加します。

第6.6項「新しいマシンの作成」

新しいJMSサーバーの作成およびターゲットの指定

新しいJMSサーバーを作成し、新しい管理対象サーバーをターゲットに指定します。

第6.7項「マシンのスケール・アップまたはスケール・アウト後のWLS JMSの構成」

packコマンドの実行

ドメイン・ディレクトリをパックします。

第6.8項「APPHOST1上のドメインのパック」

新しいマシンの準備

最初のマシンにインストールしたソフトウェアと同じものをインストールします。

第6.9項「新しいマシンの準備」

unpackコマンドの実行

管理対象サーバーのテンプレートを作成します。

第6.10項「テンプレートを転送するためのアンパックの実行」

サーバーの起動

新しいマシン上で管理対象サーバーを起動します。

第6.12項「管理対象サーバーの起動」

トポロジの検証

新しい設定をテストします。

第6.13項「マシンのスケール・アウトの検証」

「クラスタのメッセージング・モード」を「マルチキャスト」に設定します。

メッセージング・モードを「ユニキャスト」から「マルチキャスト」に変更します(マルチサーバー・ドメインに適した設定)。

第6.14項「クラスタ用マルチキャスト・メッセージの構成」

注意:
この項では、APPHOSTは物理ホスト・コンピュータを指します。マシンは、そのホストを説明名するWebLogic Serverマシンの定義を指します。詳細は『Oracle Fusion Middleware Infrastructureのインストールと構成』のOracle Fusion Middlewareインフラストラクチャの標準的なインストール・トポロジの理解に関する項を参照してください。

6.3 オプションのスケール・アウト手順

標準的なインストール手順に従うと、トポロジは複数の管理対象サーバーが1つのホスト・コンピュータに割り当てられます。

このアプローチは、変更要件に合せてドメイン・トポロジを作成したりスケール・アウトできる、最も柔軟性の高い手法です。追加のコンピューティング・リソースが必要になった場合は、1) 単一ホスト・ドメインを作成および検証して、1つのホスト・コンピュータ上の1つのマシンにターゲット指定し、2)管理対象サーバーのターゲットを追加のマシンに変更します。また、先に基本ドメインを検証してから、スケール・アップやスケール・アウト(トラブルシューティング)を行うため、トラブルシューティングが容易になります。

ただし、ターゲットのトポロジが事前にわかっている場合は、ドメインの作成中に追加のマシンを作成して、パックとアンパックの手順のみを実行することができます。

最初のインストール中に、またはオンラインの管理操作を通じて、管理対象サーバーをターゲット・マシンに割り当てている場合は、手順(第6.2項「トポロジのスケール・アウト手順」)に含まれている第6.6項「新しいマシンの作成」をスキップしてください。

マシンのマッピングの詳細は、『Oracle Fusion Middleware Infrastructureのインストールと構成』などの製品固有のインストレーション・ガイドを参照してください。

6.4 スケール・アウトの前提条件について

スケール・アウトのプロセスを開始するには、製品の標準的なインストール・トポロジを設定しておく必要があります。この標準的なインストール・トポロジがスケール・アウトの開始点です。ご使用の製品のインストレーション・ガイドに従って手順を実行すると、標準的なインストール・トポロジが構成されます。標準的なインストール・トポロジの例は、『Oracle Fusion Middleware Oracle Fusion Middleware Infrastructureのインストールと構成』のOracle Fusion Middlewareインフラストラクチャの標準的なインストール・トポロジの理解に関する項を参照してください。

関連項目:
標準的なインストール・トポロジの詳細は、ご使用の製品のインストレーション・ガイド、または『Oracle Fusion Middlewareのインストールのプランニング』の「標準的なインストール・トポロジについて」を参照してください。

注意:
このリリースのアプリケーション層製品は、動的クラスタをサポートしていません。動的クラスタは、アプリケーションのリソース・ニーズを満たすように動的にスケール・アップできるサーバー・インスタンスで構成されます。動的クラスタは、指定した数の生成された(動的)サーバー・インスタンスの構成を定義する単一のサーバー・テンプレートを使用します。

6.5 リソース要件

トポロジをスケール・アウトする前に、現在の環境が次の各要件を満たしていることを確認します。

- 1つ以上のマシンが、製品に構成された複数の管理対象サーバーを実行する。これは製品のインストレーション・ガイドまたは管理ガイドに従ってサーバーを追加した状態です。

- 開始時のホスト・コンピュータとは別にホスト・コンピュータがある。

- 製品のバイナリが格納されているOracleホームに対して、次のいずれかの方法で各ホスト・コンピュータからアクセスできる。

- 元のインストールのバイナリが格納されている共有ディスク

- 新しいインストール(元のインストールと同じ)が格納されている専用ディスク

- 元のインストールから複製したバイナリが格納されている専用ディスク
詳細は、第4章「共有記憶域の使用」を参照してください。

- ドメイン・ディレクトリに使用できる十分な記憶域がある。

- 元のインストールに使用したものと同じOracle Databaseまたはサード・パーティ・データベースにアクセスできる。

- JMSおよびトランザクション・ログ・ファイル用の共有ディスクがある(ファイル永続性プロファイルを使用する場合は必須です)。

6.6 新しいマシンの作成

マシンは、1つまたは複数のWebLogic Serverインスタンス(サーバー)をホストするコンピュータを論理的に表します。WebLogicドメインでは、マシン定義によって物理ハードウェア単位が識別され、それらの定義はホストするインスタンスに関連付けられます。

新しいマシンを作成するには、次の手順を実行します。

- 第6.6.1項「管理対象サーバーの停止」

- 第6.6.2項「新しいマシンの作成(管理コンソールの使用)」

- 第6.6.3項「新しいマシンへの管理対象サーバーの割当て」

6.6.1 管理対象サーバーの停止

新しいマシンに移動する前に、管理対象サーバーを停止する必要があります。現在稼働している場合は、管理コンソール・オンライン・ヘルプのサーバー・インスタンスの停止に関する項を参照して、新しいマシンがホストする管理対象サーバーを停止してください。

6.6.2 新しいマシンの作成(管理コンソールの使用)

この項では、管理コンソールから新しいマシンを作成する方法について説明します。WLSTを使用して新しいマシンを作成する場合は、『Oracle Fusion Middleware Oracle Fusion Middlewareの管理』の特定のコンポーネントの新しいマシンの作成に関する項を参照してください。

注意:
この手順で作成するマシンには、ローカル・ホストの他に、特定のネットワーク・インタフェースのリスニング・アドレスを指定する必要があります。

ドメインに新しいマシンを作成する手順は、次のとおりです。

1. ドメイン管理サーバーが起動していなければ、起動します。DOMAIN_HOME/binディレクトリに移動して、次のように実行します。

./startWeblogic.sh

2. 管理サーバーが起動したら、管理コンソールにアクセスします。Webブラウザを開いて、次のURLを入力します。

http://hostname:port/console

「ようこそ」画面でログインします。

3. 管理コンソールの「チェンジ・センター」で、「ロックして編集」をクリックします。

注意:
本番環境のドメインは「本番モード」でドメインを作成し、「チェンジ・センター」を有効にすることをお薦めします。「本番モード」を有効にしない場合は、「チェンジ・センター」の手順は必要ありません。

4. 「ドメイン構造」で、「環境」を開いて、「マシン」をクリックします。

5. 「マシン」表の上(「サマリー」の上)にある「新規」をクリックします。

6. 「新しいマシンの作成」画面で、マシンの名前を入力します(machine_2など)。ドロップダウン・リストから「マシンのOS」を選択して、「次へ」をクリックします。

7. 次の画面で、「タイプ:」ドロップダウン・リストから「プレーン」を選択します。
ノード・マネージャの「リスニング・アドレス」には、このマシンを表すホスト・コンピュータのIPアドレスまたはホスト名を入力します。2つの新しいマシンが「マシン」表に表示されます。

8. 「終了」をクリックします。

9. チェンジ・センターで、変更のアクティブ化をクリックします。
メッセージ「すべての変更がアクティブ化されました。再起動は不要です。」が表示されます。このメッセージは新しいマシンが作成されたことを示します。

6.6.3 新しいマシンへの管理対象サーバーの割当て

新しく作成したマシンに管理対象サーバーを割り当てるには、管理コンソールで次の手順を実行します。

1. 「チェンジ・センター」で、「ロックして編集」をクリックします。

2. 「マシン」表で、machine_1用のチェック・ボックスを選択します。

3. マシン名(ハイパーリンクとして表示)をクリックします。

4. machine_1の「設定」で、「構成」タブ、「サーバー」サブタブの順にクリックします。

5. 「サーバー」表の上にある「追加」をクリックします。

6. 「マシンにサーバーを追加」ページで「新しいサーバーを作成してこのマシンに関連付けます。」をクリックします。「次へ」をクリックし、「サーバー名」と「サーバー・リスニング・ポート」の各フィールドを入力します(必須)。

7. 「ドメイン構造」の下で、「マシン」をクリックします。
「マシン」表で、マシン「machine_2」をクリックします。

8. machine_2の「設定」の下で、「構成」タブ、「サーバー」タブの順にクリックします。「サーバー」タブの上にある「追加」をクリックします。
「マシンにサーバーを追加」画面で「既存のサーバーを選択して、このマシンに関連付けます。」ボタンを選択します。

「サーバーの選択」ドロップダウン・リストから「server_2」を選択し、「終了」を選択します。

「サーバーが正常に作成されました。」というメッセージが表示されます。

9. すべての管理対象サーバーに、適切な「サーバー・リスニング・アドレス」が割り当てられていることを確認します。「ドメイン構造」で、「サーバー」をクリックします。「サーバー」表で、管理対象サーバー名をクリックします。「構成」タブを選択します。「リスニング・アドレス」を確認または関連付けられているマシンのIPアドレスに設定します。「保存」をクリックします。

10. 変更を完了するために、「チェンジ・センター」に戻ります。「変更のアクティブ化」をクリックします。メッセージ「すべての変更がアクティブ化されました。再起動は不要です。」が表示されます。
管理対象サーバー割当てのサマリーを表示するには、「ドメイン構造」の下にある「環境」で「サーバー」をクリックします。「サーバー」表に、そのドメイン内の全サーバー、およびそれらのマシンの割当てが表示されます。

6.7 マシンのスケール・アップまたはスケール・アウト後のWLS JMSの構成

クラスタに新しい管理対象サーバーを追加する場合は、その管理対象サーバー上のすべてのJMSシステム・リソースを、手動で再度作成する必要があります。新しいJMSシステム・リソースは、クラスタ内の既存の管理対象サーバーからクローンします。新しいJMSシステム・リソースには、ドメイン内で一意の名前を与える必要があります。ドメインを作成した際に、構成ウィザードによって、次のパターンに従ったJMSシステム・リソース名が作成されます。管理性と利便性の点から、同じ命名パターンに従って名前を付けることをお薦めします。

新しい管理対象サーバーserver_n上のJMSリソースを構成するには、次の手順を実行します。

1. 「ドメイン構造」ツリーで「サービス」、「メッセージング」の順に選択します。「JMSサーバー」を選択して、「JMSサーバー」表を開きます。

2. 「名前」列で、クラスタ内の既存の管理対象サーバー(たとえば、server_1)がターゲットに指定されているJMSサーバーを、すべて特定します。
JMSサーバー名の書式は、リソース名_auto_番号です。

- リソース名は、リソースを識別する名前です。

- 番号でJMSサーバーが識別されます(1または2の接尾辞を与えられているサーバーは、ドメインの作成時に作成されたサーバーです)。

3. JMSサーバーおよび永続ストアの名前をメモに記録します。例: UMSJMSServer_auto_1およびUMSJMSFileStore_auto_1。

4. 「新規」をクリックして、新しいJMSサーバーを作成します。

1. server_1と同じ書式に従って、server_nのJMSサーバーに名前を付けます。例: UMSJMSServer_auto_n。

2. 「永続ストア」で、「新しいストアの作成」をクリックします。

3. 「タイプ」で、server_1上でそのJMSサーバーにより使用されているのと同じ永続性プロファイルを選択します。「次へ」をクリックします。

4. 「名前」フィールドに、永続ストア名を入力します。server_1の永続ストアと同じと書式を使用します。例: UMSJMSFileStore_auto_n。

5. 「ターゲット」フィールドで、ドロップダウン・リストから、移行可能なターゲットserver_n (移行可能)用の移行可能なターゲットを選択します。

6. 「ディレクトリ」フィールドには、永続ストアと同じ名前を使用します。「OK」をクリックして、永続ストアを作成します。

7. 「新しいJMSサーバーの作成」画面で、新しい永続ストアを選択し、「次へ」をクリックします。

8. 「JMSサーバーターゲット」で、ドロップダウン・リストから、server_n (移行可能)用の移行可能なターゲットを選択します。

9. 「終了」をクリックし、JMSサーバーを作成します。

5. 対応するJMSモジュールのサブデプロイメント・ターゲットを更新し、新しいJMSサーバーを追加します。

1. 管理コンソールの「ドメイン構造」ツリーで、「サービス」ノードを開いて、「メッセージング」ノードを開いて、「JMSモジュール」を選択して、「JMSモジュール」表を開きます。

2. JMSサーバーに対応するJMSシステム・モジュールを特定します。名前に共通のルートが含まれています。たとえば、JMSサーバーUMSJMSServer_auto_1に対応したJMSモジュール名は、UMSJMSSystemResourceです。「名前」列で、JMSモジュール(ハイパーリンク)をクリックし、モジュールの「設定」ページを開きます。

3. 「サブデプロイメント」タブを開き、「名前」列で、JMSモジュールのサブデプロイメントをクリックします。

4. 新しい「JMSサーバー」server_nを選択します。「保存」をクリックします。

5. モジュールの「設定」ページに戻ります。「ターゲット」タブを選択します。「クラスタのすべてのサーバー」が有効になっていることを確認します。

6. 変更を行った場合は、「保存」をクリックします。

JMSリソースをクラスタ内に構成した新しい管理対象サーバーが使用できます。

6.8 APPHOST1上のドメインのパック

WebLogicドメイン上でpackコマンドを実行して、管理対象サーバーのテンプレートを作成します。

注意:
パックおよびアンパックの手順を実行する際には、APPHOST1上で管理サーバーが稼働している必要があります。

APPHOST1上でpackコマンドを実行して、テンプレート・パックを作成します。スケール・アウト・プロセスの後の方では、APPHOST2上でテンプレート・ファイルをアンパックします(アンパックの手順は第6.10項「テンプレートを転送するためのアンパックの実行」で説明しています)。

例:

ORACLE_HOME/oracle_common/common/bin/pack.sh \
-domain=DOMAIN_HOME \
-template=dir/domain_name.jar \
-managed=true \
-template_name="DOMAIN"

前述の例の説明:

- DOMAIN_HOMEを、ドメイン・ホーム・ディレクトリのフルパスに置き換えます。

- dirを、新しいテンプレート・ファイルの作成先となる予約済ディレクトリのフルパスに置き換えます。

- JARファイル名のdomain_nameをドメイン名に置き換えます。これは、packコマンドで作成するテンプレート・ファイルの名前です。たとえば、mydomain.jarです。

関連項目:
管理対象サーバーのテンプレートを作成する方法の詳細は、WebLogicドメインおよびドメイン・テンプレートの作成に関するドキュメントのpackおよびunpackのコマンド・リファレンスに関する項を参照してください。

6.9 新しいマシンの準備

新しいマシンmachine_2の準備として、OracleホームがインストールされているAPPHOST2から共有ディスクにアクセスできるかどうかを検証するか、machine_1上にインストールしたものと同じソフトウェアをインストールします。

たとえば、Oracle Fusion Middlewareインフラストラクチャのドメインをスケール・アウトする場合は、APPHOST2からインフラストラクチャのOracleホームにアクセスできることを検証します。

注意:
共有記憶域を使用する場合は、同じインストール場所を再利用できます。

注意:
新しいインストールを実行するか、共有記憶域を使用してバイナリを再利用する場合、新しいファイルのパスの場所は元のマシンのパスの場所と正確に一致する必要があります。

6.10 テンプレートを転送するためのアンパックの実行

テンプレートをアンパックして、APPHOST1からAPPHOST2にdomain_name.jarファイルを転送するには、次のunpackコマンドを実行します。

ORACLE_HOME/oracle_common/common/bin/unpack.sh \
-domain=user_projects/domains/base_domain2 \
-template=/tmp/domain_name.jar \
-app_dir=user_projects/applications/base_domain2

6.11 ノード・マネージャの起動

ノード・マネージャを起動するには、次のコマンドを実行します。

DOMAIN_HOME/bin/startNodeManager.sh &

ノード・マネージャがスコープ内にあるマシンを使用する場合、ノード・マネージャの起動オプションの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャの使用に関する項を参照してください。

6.12 管理対象サーバーの起動

管理コンソールから管理対象サーバーを起動するには、次の手順を実行します。

1. コンソールの左側のペインで、「環境」を開いて、「サーバー」を選択します。

2. 「サーバー」表で、新しいマシンに移動した管理対象サーバー名をクリックします。「制御」タブを選択します。

3. 起動するサーバー名の横のチェック・ボックスを選択し、「開始」をクリックして、サーバーを起動します。

関連項目:
WLSTコマンドまたはFusion Middleware Controlを使用して管理対象サーバーを起動する方法については、『Oracle Fusion Middleware Oracle Fusion Middlewareの管理』の管理対象サーバーの起動と停止に関する項を参照してください。

6.13 マシンのスケール・アウトの検証

マシンのスケール・アウトが正常に完了したかどうかを検証するには、管理コンソールを使用してサーバーを起動した後に、ステータスがRUNNINGになっていることを確認します。

6.14 クラスタ用マルチキャスト・メッセージングの構成

この項の内容は次のとおりです。

- 第6.14.1項「クラスタ用マルチキャストとユニキャスト・メッセージングについて」

- 第6.14.2項「マルチキャスト・メッセージングを構成するための要件」

- 第6.14.3項「マルチキャスト・メッセージングの構成」

6.14.1 クラスタ用マルチキャストとユニキャスト・メッセージングについて

クラスタでは、サービスの可用性、および継続的な可用性を示すハートビートをブロードキャストするために、メッセージングが使用されます。クラスタを構成して、ユニキャストまたはマルチキャスト・メッセージングを使用します。

- マルチキャストは、複数のアプリケーションがIPアドレスとポート番号にサブスクライブして、メッセージをリスニングできるようにする単純なブロードキャスト技術です。ハードウェアの構成およびサポートが必要なため、マルチキャストはユニキャストに比べて設定が複雑です。

- ユニキャストは、クラスタ・メッセージングのためのTCPベースの、信頼性ある、クラスタ用の1対多通信です。マルチキャストに比べて設定が簡単です。

構成ウィザードでクラスタを作成した場合は、クラスタ・メッセージング・モードが、デフォルトでユニキャストに設定されます。ドメイン内の管理対象サーバー数が増加した場合は、マルチキャスト・メッセージングをお薦めします。

6.14.2 マルチキャスト・メッセージングを構成するための要件

マルチキャスト・メッセージングを構成するための要件は、次のとおりです。

- 少なくとも1つのクラスタを持つドメインが構成されていること。

- ネットワークでマルチキャストをサポートするようハードウェアが構成されていること。

- クラスタ内にマルチキャスト通信用のIPアドレスおよびポート番号があること。マルチキャスト用のアドレスは、224.0.0.0から239.255.255.255までのIPアドレスです。(Weblogicでは、デフォルトで239.192.0.0が使用されます)。

- MulticastTestユーティリティを実行して、環境がマルチキャストをサポートすることを確認済であること。ユーティリティにより、マルチキャストの問題がデバッグされます。これは、マルチキャスト・パケットを送信し、ネットワーク上で、マルチキャストがどのくらい効果的に機能しているかに関するデータを返します。

関連項目:
マルチキャスト・メッセージングおよびクラスタ構成の詳細は、『Oracle WebLogic Serverクラスタの管理』のクラスタ内の通信に関する項を参照してください。

6.14.3 マルチキャスト・メッセージングの構成

マルチキャスト・メッセージングを構成するには、次の手順を実行します。

1. 管理コンソールにログインします。

2. マルチキャスト・メッセージングを使用するすべてのサーバーを停止します。

3. 左側の「ドメイン構造」ペインで、「環境」を開き、「クラスタ」をクリックします。

4. マルチキャストを有効にするクラスタ名を選択します。

5. 「構成」タブをクリックして、「メッセージング」タブをクリックします。

6. 「メッセージング・モード」で「マルチキャスト」を選択します。「マルチキャスト・アドレス」、「マルチキャスト・ポート」を入力します。
「マルチキャスト・アドレス」は、各クラスタにおいて一意である必要があります。マルチキャスト・アドレスのガイドラインは、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの管理』のクラスタのマルチキャスト・アドレスおよびポート番号に関する項を参照してください。

7. 「詳細」をクリックして、次のパラメータを構成します。

表6-2 マルチキャスト詳細パラメータ

パラメータ

説明

Multicast Send Delay

OSレベルでのバッファのオーバーフローを防止するために、マルチキャストによるメッセージ・フラグメントの送信が遅延されるミリ秒数(0から250の間で指定)。

Multicast TTL

クラスタ・マルチキャスト・メッセージが通過できるネットワーク・ホップ数(1から255の間で指定)。クラスタがWAN内の複数のサブネットをまたぐ場合は、マルチキャスト・パケットが最終的な宛先に届く前にルーターによって破棄されることのないよう、このパラメータに十分大きな値を設定する必要があります。このパラメータにより、パケットが破棄される前にマルチキャスト・メッセージに許可される、ネットワーク・ホップ数が設定されます。

Multicast Buffer Size

マルチキャスト・ソケットの送信および受信バッファのサイズ(最小で64KB)。

タイムアウトまでのアイドル期間

クラスタの1つのメンバーがタイム・アウトするまでにクラスタ・メンバーが待機する最大回数。

Enable Data Encryption

マルチキャスト・データの暗号化を有効化します。マルチキャスト・データのみ暗号化され、マルチキャスト・ヘッダー情報は暗号化されません。

8. 「保存」をクリックします。

9. クラスタ内のすべてのサーバーを再起動します。

これで、クラスタでマルチキャスト・メッセージングを使用できます。管理コンソールの「ドメイン構造」ペインで、「クラスタ」を選択すると、「クラスタのメッセージング・モード」に「マルチキャスト」と表示されます。

7 JMSおよびJTAの高可用性

この項では、Java Message Service (JMS)およびJava Transaction API (JTA)の高可用性について説明します。

この項の内容は次のとおりです。

- 第7.1項「JMSおよびJTAの高可用性サービスについて」

- 第7.2項「JMSおよびJTAサービスのための移行可能ターゲットについて」

- 第7.3項「JMSおよびJTAの高可用性の移行可能ターゲットの構成」

- 第7.4項「ユーザー優先サーバーと候補サーバー」

- 第7.5項「ファイル永続性を使用するうえでの考慮事項(WebLogic JMS)」

- 第7.6項「NFSでのファイル・ストアの使用」

- 第7.7項「データベース永続ストアを使用したWLS JMSの構成」

- 第7.8項「トランザクション・ログを永続化するためのデータベース・ストアの構成

関連項目:
JMSまたはJTAの操作の詳細は、次を参照してください。

- 『Oracle Fusion Middleware Oracle WebLogic Server JMSリソースの管理』のWebLogic JMSクラスタリングの構成に関する項

- 『Oracle Fusion Middleware Oracle WebLogic Server JMSリソースの管理』のOracle AQ JMSとの相互運用性に関する項

- 『Oracle WebLogic Server JTAアプリケーションの開発』のJTAの構成に関する項。

- 管理コンソール・オンライン・ヘルプのJTAのドメイン構成およびクラスタ構成に関する項

7.1 JMSおよびJTAの高可用性サービスについて

Java Message Service (JMS)は、ネットワーク内のコンピュータ間でメッセージングと呼ばれる正式な通信をサポートするアプリケーション・プログラム・インタフェース(API)です。

Java Transaction API (JTA)は、トランザクション・マネージャと分散トランザクション・システム(リソース・マネージャ、アプリケーション・サーバーおよびトランザクション・サーバー)に関わるパーティ間の標準のJavaインタフェースを指定します。

WebLogic JMSでは、宛先のホストJMSサーバーが実行中の場合のみ、メッセージを使用可能です。メッセージが中央の永続ストアにある場合、それにアクセスできるのは、最初にメッセージを格納したサーバーのみです。WebLogicには、障害後にJMSサーバーを自動的に再起動または移行(あるいはその両方)する機能があります。また、同じクラスタ内の複数のJMSサーバー間で宛先をクラスタリング(分散)する機能もあります。

サーバー全体の移行または自動サービス移行のいずれかを使用すれば、JMSサーバーを自動的に再起動または移行(フェイルオーバー)する、あるいはその両方が可能です。

関連項目:
サーバー全体の移行の詳細は、第3章「サーバー全体の移行」を参照してください。

7.2 JMSおよびJTAサービスのための移行可能ターゲットについて

JMSサービスやJTAサービスを構成して可用性を高めるためには、それらのサービスを、移行可能ターゲット(クラスタ内のサーバーから別のサーバーに移行できる特別なターゲット)にデプロイします。移行可能ターゲットは、同時に移動する必要のある移行可能サービスをグループ化します。移行可能ターゲットを移行すると、その対象によってホストされているすべてのサービスも移行されます。

移行可能ターゲットは、ターゲットをホストできるサーバーのセットを指定します。移行可能なターゲットをホストできるサーバーは常に1つのみです。また、次を指定します。

- サービスのユーザー優先ホスト

- 優先サーバーが失敗した場合のバックアップ・サーバーの順序リスト

移行可能ターゲットを使用するようにサービスを構成すると、それは、現時点でそれをホストするサーバー・メンバーから独立した存在になります。たとえば、JMSキューがデプロイされているJMSサーバーを、移行可能ターゲットを使用するように構成した場合、そのキューは、特定のサーバー・メンバーが使用可能かどうかに依存せずに動作します。キューは、クラスタ内のいずれかのサーバーが移行可能ターゲットをホストしている場合、常に使用できます。

固定された移行可能サービスは、1) サーバーの障害または、2) 定期的に計画されるメンテナンスの場合、クラスタ内のサーバーから別のサーバーに手動で移行できます。クラスタ内に移行可能ターゲットを構成しない場合、移行可能サービスは、クラスタ内のどのサーバーにも移行できます。

移行可能ターゲットの構成は、第7.3項「JMSおよびJTAの高可用性の移行可能ターゲットの構成」を参照してください。

関連項目:
JMSの管理の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSリソースの管理』の、次の内容を参照してください。

- 高可用性ベスト・プラクティス

- 「Oracle AQ JMSとの相互運用性」

7.3 JMSおよびJTAの高可用性の移行可能ターゲットの構成

移行可能ターゲットを構成するには、管理コンソール・オンライン・ヘルプの次の項を参照してください。

- JMS関連サービスのための移行可能ターゲットの構成

- JTAトランザクション回復サービスの移行可能ターゲットの構成

7.4 ユーザー優先サーバーと候補サーバー

JMSサービスを移行可能ターゲットにデプロイする際は、サービスをホストするユーザー優先サーバーのターゲットを選択できます。ユーザー優先サーバーで障害が発生したときにサービスをホストできる控えの候補サーバー(CCS)を指定することもできます。移行可能ターゲットにCCSが指定されていない場合、JMSサーバーをクラスタ内で使用可能な任意のサーバーに移行できます。

個別の移行可能ターゲットをJMSサービスに作成すると、必要に応じて、クラスタ内の別々のサーバー上で常に各サービスを継続することができます。また逆に、JTAとJMS両方のCCSとして同じサーバー群を選択し、両方のサービスが確実にクラスタ内の同じサーバーに配置されるように構成することもできます。

7.5 ファイル永続性を使用するうえでの考慮事項(WebLogic JMS)

ファイル・システムを構成して、JMSメッセージとJTAログを格納します。高可用性を確保するためには、共有ファイル・システムを使用する必要があります。共有ファイル・システムを使用する際の考慮事項の詳細は、第4章「共有記憶域の使用」を参照してください。

関連項目:
詳細は、『Oracle WebLogic Server JMSリソースの管理』のWebLogic JMSのアーキテクチャおよび環境に関する項を参照してください。

7.6 NFSでのファイル・ストアの使用

JMSメッセージおよびトランザクション・ログをNFSにマウントされたディレクトリに格納している場合、予期しないマシン障害の後にサーバーの再開動作を確認することを強くお薦めします。NFSの実装に応じて、フェイルオーバーまたは再起動後に異なる問題が発生する可能性があります。

この項の内容は次のとおりです。

- 第7.6.1項「サーバーの再開動作の検証」

- デフォルトのファイル・ストアのファイル・ロックの無効化

- 第7.6.3項「カスタム・ファイル・ストアのファイル・ロックの無効化」

- 第7.6.4項「JMSページング・ファイル・ストアのファイル・ロックの無効化」

- 第7.6.5項「診断ファイル・ストアのファイル・ロックの無効化」

7.6.1 サーバーの再開動作の検証

サーバーの再起動の動作を確認するには、WebLogic Serverの実行時に、それらのサーバーをホストするノードを異常停止させます。

- サーバーをサーバー移行用に構成した場合、サーバーは、フェイルオーバー期間の経過後にフェイルオーバー・モードで自動的に起動します。

- サーバーをサーバー移行用に構成しなかった場合、ノードが完全に再起動した後、同じホスト上でWebLogic Serverを手動で再起動できます。

予期しないマシン障害の後にWebLogic Serverが再起動しない場合は、サーバーのログ・ファイルを参照して、次のようなI/O例外によるものかどうかを確認してください。

<MMM dd, yyyy hh:mm:ss a z> <Error> <Store> <BEA-280061> <The persistent
store "_WLS_server_1" could not be deployed:
weblogic.store.PersistentStoreException: java.io.IOException:
[Store:280021]There was an error while opening the file store file
"_WLS_SERVER_1000000.DAT"
weblogic.store.PersistentStoreException: java.io.IOException:
[Store:280021]There was an error while opening the file store file
"_WLS_SERVER_1000000.DAT"
at weblogic.store.io.file.Heap.open(Heap.java:168)
at weblogic.store.io.file.FileStoreIO.open(FileStoreIO.java:88)
...
java.io.IOException: Error from fcntl() for file locking, Resource
temporarily unavailable, errno=11

このエラーは、NFSv3システムでファイル・ストアに対するロックが解放されていないときに発生します。WebLogic Serverは、同じ管理対象サーバーの2つのインスタンスが偶然起動した場合にデータ破損が発生しないように、JMSデータおよびトランザクション・ログを格納しているファイルに対するロックを保持します。NFSv3ストレージ・デバイスはロック所有者を追跡しないため、ロック所有者が失敗した場合、NFSはロックを無期限に保持します。このため、予期しないマシン障害とそれに続く再起動の後に、WebLogic Serverがロックを取得しようとしても、失敗する可能性があります。

このエラーの解決方法は、NFS環境によって異なります(このトピックの更新については、『Oracle Fusion Middlewareリリース・ノート』を参照してください)。

- NFSv4環境の場合、サーバー移行を完了する所要時間内にロックを解放するよう、NASサーバーでチューニング・パラメータを設定できます(この項の手順に従う必要はありません)。ストレージ・デバイスでNFSにマウントされたディレクトリに格納されているファイルのロックに関する情報は、使用しているストレージのベンダーのドキュメントを参照し、結果をテストしてください。

- NFSv3環境の場合、次の項で、デフォルト・ファイル・ストア、カスタム・ファイル・ストア、JMSページング・ファイル・ストア、診断ファイル・ストアに対するWebLogicのファイル・ロック・メカニズムを無効化する方法について説明します。

警告:

NFSv3のファイル・ロックにより、複数の管理対象サーバーが任意の時点で同じファイル・ストアに書込みを行う場合に、深刻なファイルの破損が発生しないようにします。

NFSv3のファイル・ロックを無効化する場合は、特定のファイル・ストアに書込みを行う管理対象サーバーが1つのみとなるよう、管理手順や管理ポリシーを実装する必要があります。破損は、同じクラスタまたは別のクラスタ、同じノードまたは別のノード、あるいは同じドメインまたは別のドメインに管理対象サーバーが2つ存在することにより発生する可能性があります。

ポリシーの例としては、ドメインをコピーしない、WLS構成オブジェクト(サーバーやストア)の一意のネーミング・スキームを強制しない、各ドメインに独自の記憶域ディレクトリを必ず含める、2つのドメインに同じディレクトリを参照する同じ名前のストアを含めることはできない、などがあげられます。

ファイル・ストアを使用する場合は、サーバー移行用に、必ずデータベース・ベースのリース・オプションを構成してください。このオプションにより、データベース表を使用した追加のロック・メカニズムが強制的に適用され、特定の管理対象サーバーの複数のインスタンスが自動的に再起動しなくなります。

7.6.2 デフォルト・ファイル・ストアのファイル・ロックの無効化

管理コンソールを使用してデフォルト・ファイル・ストアのファイル・ロックを無効化するには、次の手順を実行します。

1. 必要に応じ、「チェンジ・センター」で「ロックして編集」をクリックします。

2. 「ドメイン構造」ツリーで、「環境」ノードを開いて「サーバー」を選択します。

3. 「サーバーのサマリー」リストで、変更するサーバーを選択します。

4. 「構成」→「サービス」タブを選択します。

5. 「デフォルト・ストア」セクションを下にスクロールし、「詳細」をクリックします。

6. 下にスクロールして、「ファイル・ロックの有効化」チェック・ボックスを選択解除します。

7. 「保存」をクリックします。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。

8. 変更したサーバーを再起動して変更を反映します。

生成されるconfig.xmlのエントリは、次のようになります。

<server>
<name>examplesServer</name>
...
<default-file-store>
<synchronous-write-policy>Direct-Write</synchronous-write-policy>
<io-buffer-size>-1</io-buffer-size>
<max-file-size>1342177280</max-file-size>
<block-size>-1</block-size>
<initial-size>0</initial-size>
<file-locking-enabled>false</file-locking-enabled>
</default-file-store>
</server>

7.6.3 カスタム・ファイル・ストアのファイル・ロックの無効化

管理コンソールを使用してカスタム・ファイル・ストアのファイル・ロックを無効化するには、次の手順を実行します。

1. 必要に応じて、「チェンジ・センター」で、「ロックして編集」をクリックしてドメインの編集ロックを取得します。

2. 「ドメイン構造」ツリーで「サービス」ノードを開きます。「永続ストア」を選択します。

3. 「永続ストアのサマリー」リストで、変更するカスタム・ファイル・ストアを選択します。

4. カスタム・ファイル・ストアの「構成」タブで、「詳細」をクリックします。

5. 下にスクロールして、「ファイル・ロックの有効化」チェック・ボックスを選択解除します。

6. 「保存」をクリックします。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。

7. カスタム・ファイル・ストアが使用中であった場合、変更を反映するには、サーバーを再起動する必要があります。

config.xmlのエントリは、次の例のようになります。

<file-store>
<name>CustomFileStore-0</name>
<directory>C:\custom-file-store</directory>
<synchronous-write-policy>Direct-Write</synchronous-write-policy>
<io-buffer-size>-1</io-buffer-size>
<max-file-size>1342177280</max-file-size>
<block-size>-1</block-size>
<initial-size>0</initial-size>
<file-locking-enabled>false</file-locking-enabled>
<target>examplesServer</target>
</file-store>

7.6.4 JMSページング・ファイル・ストアのファイル・ロックの無効化

管理コンソールを使用してJMSページング・ファイル・ストアのファイル・ロックを無効化するには、次の手順を実行します。

1. 必要に応じて、「チェンジ・センター」で、「ロックして編集」をクリックしてドメインの編集ロックを取得します。

2. 「ドメイン構造」ツリーで、「サービス」ノードを開き、次に「メッセージング」ノードを開いて「JMSサーバー」を選択します。

3. 「JMSサーバーのサマリー」リストで、変更するJMSサーバーを選択します。

4. 「JMSサーバー」の「構成」から「一般」タブに進み、スクロール・ダウンします。「ページング・ファイル・ロックの有効化」チェック・ボックスの選択を解除します。

5. 「保存」をクリックします。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。

6. 変更したサーバーを再起動して変更を反映します。

config.xmlファイルのエントリは、次の例のようになります。

<jms-server>
<name>examplesJMSServer</name>
<target>examplesServer</target>
<persistent-store>exampleJDBCStore</persistent-store>
...
<paging-file-locking-enabled>false</paging-file-locking-enabled>
...
</jms-server>

7.6.5 診断ファイル・ストアのファイル・ロックの無効化

管理コンソールを使用して診断ファイル・ストアのファイル・ロックを無効化するには、次の手順を実行します。

1. 必要に応じて、「チェンジ・センター」で、「ロックして編集」をクリックしてドメインの編集ロックを取得します。

2. 「ドメイン構造」ツリーで「診断」ノードを開きます。「アーカイブ」を選択します。

3. 「診断アーカイブのサマリー」リストで、変更するアーカイブのサーバー名を選択します。

4. 「[server_name]の設定」ページで、「診断ストアのファイル・ロックを有効化」チェック・ボックスを選択解除します。

5. 「保存」をクリックします。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。

6. 変更したサーバーを再起動して変更を反映します。

生成されるconfig.xmlファイルは、次のようになります。

<server>
<name>examplesServer</name>
...
<server-diagnostic-config>
<diagnostic-store-dir>data/store/diagnostics</diagnostic-store-dir>
<diagnostic-store-file-locking-enabled>false</diagnostic-store-file-locking-
enabled>
<diagnostic-data-archive-type>FileStoreArchive</diagnostic-data-archive-type>
<data-retirement-enabled>true</data-retirement-enabled>
<preferred-store-size-limit>100</preferred-store-size-limit>
<store-size-check-period>1</store-size-check-period>
</server-diagnostic-config>
</server>

関連項目:
『Oracle Fusion Middleware Oracle WebLogic Server JMSリソースの管理』のJMSサーバーおよび永続ストアに関する項を参照してください。

7.7 データベース永続ストアを使用したWLS JMSの構成

この項では、WLS JMS構成を、ファイルベースの永続ストア(デフォルト構成)からデータベースの永続ストアに変更する方法を説明します。

この項の内容は次のとおりです。

- 第7.7.1項「永続ストアについて」

- 第7.7.2項「データベース永続ストアを使用したWLS JMSの構成の前提条件

- 第7.7.3項「WLS JMSでのファイルベースの永続ストアからデータベース永続ストアへの切替え」

7.7.1 永続ストアについて

永続ストアは、永続性を必要とするWebLogic Serverのサブシステムおよびサービス用に組み込まれたストレージ・ソリューションです。たとえば、永続的なJMSメッセージを格納できます。永続ストアは、ファイルベースのストアまたはデータベースのJDBC対応ストアの永続性をサポートします。

永続ストアの詳細は、WebLogic Server永続ストアの管理のWebLogic永続ストアに関する項を参照してください。

WebLogicメッセージング・コンポーネントをモニター、制御および構成する一般的なタスクの詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のWebLogic Serverメッセージングに関する項を参照してください。

7.7.2 データベース永続ストアを使用したWLS JMSの構成の前提条件

データベース永続ストアを使用したWLS JMSを構成するには、ご使用の設定がこれらの要件を満たしていることを確認してください。

- 少なくとも1つのクラスタと1つ以上のJMSサーバーを使用するOracle Fusion Middlewareがインストールされていること

- JMSサーバーが、ファイル永続ストアを使用すること(デフォルト構成)

7.7.3 WLS JMSでのファイルベースの永続ストアからデータベース永続ストアへの切替え

次の手順は、データベース永続ストアを使用する構成のJMSサーバーごとに、実行する必要があります。

1. JDBCストアを作成します。『Oracle Fusion Middleware Oracle WebLogic Serverサーバー環境の管理』のJDBCストアの使用に関する項を参照してください。

注意:
JDBCストアのデータベース表に一意の名前を付けるための接頭辞を、指定する必要があります。

2. JDBCストアをJMSサーバーに関連付けます。

1. Weblogic Server管理コンソールで、「サービス」→「メッセージング」→「JMSサーバー」に移動します。

2. このサーバーに保留メッセージがないことを確認します。「制御」タブで、すべての宛先に対するメッセージの生成および挿入を停止し、残りのメッセージが排出されるのを待ちます。

3. 「全般的な構成」タブを選択します。「永続ストア」で新しく作成したJDBCストアを選択し、「保存」をクリックします。

データベース永続ストアを使用して、JMSサーバーが起動されます。

7.8 トランザクション・ログを永続化するためのデータベース・ストアの構成

この項の内容は次のとおりです。

- 第7.8.1項「JDBC TLOGストアを構成するための要件」

- 第7.8.2項「JDBC TLOGストアの構成」

7.8.1 JDBC TLOGストアを構成するための要件

JDBCトランザクション・ログ(TLOG)ストアを構成する前に、標準Oracle Fusion Middlewareがインストールされている必要があります。

インストールの後で、ファイル・システムにTLOGストアを構成します。場合によっては、TLOGをデータベースに格納するよう構成することをお薦めします。データベース・ストアに格納するためにJDBC TLOGを構成する詳細は、WebLogic永続ストアの管理のJDBC TLOGストアの使用に関する項を参照してください。

7.8.2 JDBC TLOGストアの構成

JDBC TLOGストアを構成するには、次のことが必要です。

- クラスタ内の管理対象サーバーごとに、この手順を繰り返してください。

- 管理対象サーバー名を接頭辞に使用して、それぞれの管理対象サーバーごとに一意のTLOGストア名を作成してください。

- 永続ストア用に作成したデータ・ソースが、高可用性設定でクラスタにターゲット設定されていることを確認してください。

構成を終了すると、構成済のデータベースベースの永続ストアに、TLOGが送信されます。

注意:
スケール・アップまたはスケール・アウトによって、クラスタに新しい管理対象サーバーを追加する場合は、新しい管理対象サーバー用のJDBC TLOGストアも作成する必要があります。

8 管理サーバーの高可用性

この項では、管理サーバーの高可用性について説明します。

この項には次のトピックが含まれます:

- 第8.1項「管理サーバーの役割」

- 第8.2項「ノード・マネージャの役割」

- 第8.3項「管理サーバーの高可用性トポロジ」

- 第8.4項「管理サーバーの高可用性の構成」

- 第8.5項「管理サーバーのフェイルオーバーまたはフェイルバック」

管理サーバーおよびノード・マネージャの詳細は、次の各項目を参照してください。

表8-1 管理サーバーおよびノード・マネージャに関する項目

情報

参照先

管理サーバーの起動と停止

『Oracle Fusion Middleware Oracle Fusion Middlewareの管理』の管理サーバーの起動と停止に関する項

仮想ホスティングの構成

『Oracle WebLogic Serverサーバー環境の管理』の仮想ホスティングの構成に関する項

ノード・マネージャの使用方法

『Oracle WebLogic Serverノード・マネージャの管理』の次の項:

- 「ノード・マネージャおよびシステム・クラッシュ・リカバリ」

- 「WLS環境でのノード・マネージャの動作」

- 「ノード・マネージャの構成およびログ・ファイル」

8.1 管理サーバーの役割

管理サーバーは、ドメイン全体を構成するための集中管理エンティティで、すべてのドメイン・リソースを管理およびモニターします。ドメインの構成ドキュメントを保持し、これらのドキュメント内の変更を管理対象サーバーに配布します。各ドメインには、管理サーバーとして機能する1つのサーバーが必要です。

8.1.1 管理サーバーの障害と再起動

ドメインの管理サーバーで発生する障害は、ドメイン内の管理対象サーバーの動作には影響しません。管理サーバーのホスト・コンピュータ上のハードウェアまたはソフトウェアの障害が原因で管理サーバーに障害が発生した場合は、同じコンピュータ上のその他のサーバー・インスタンスが影響を受けることがあります。

管理サーバーの障害の詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareの管理』の管理対象サーバーの障害の影響に関する項を参照してください。

管理サーバーを再起動する方法は、Oracle Fusion Middleware Oracle Serverクラスタの使用を参照してください。

8.1.2 共有記憶域と管理サーバーの高可用性

共有記憶域を使用すると、バックアップ・ホストは、アクティブ・ホストがアクセスできる同じアーティファクト(Oracleバイナリ、構成ファイル、ドメイン・ディレクトリおよびデータ)にアクセスできます。高可用性管理サーバーの構成において、アーティファクトをすべてのホストがアクセス可能な記憶域に配置することにより、このアクセスを構成できます。共有記憶域は、ネットワーク接続ストレージ(NAS)またはストレージ・エリア・ネットワーク(SAN)のいずれかのデバイスを使用します。第4章「共有記憶域の使用」を参照してください。

8.2 ノード・マネージャの役割

作成するWebLogic Serverドメインのそれぞれについて、ドメインごとのノード・マネージャ・インスタンスがデフォルトで作成されます。ノード・マネージャには、セキュリティ資格証明書、プロパティ・ファイル、ドメイン登録および起動スクリプトが付属しています

ノード・マネージャの範囲は構成可能です。

- ドメインごとのノード・マネージャは、ドメインと関連付けられ、マシン上のドメインのすべてのサーバーを制御します。デフォルトの構成です。

- ホストごとのノード・マネージャは、ドメインではなく、特定のマシンに関連付けられます。サーバー・インスタンスがノード・マネージャ・プロセスと同じマシン上に存在しているかぎり、ノード・マネージャ・プロセスを使用して任意のドメインのサーバー・インスタンスを制御できます。ホストごとのノード・マネージャは、ノード・マネージャで制御するWebLogic Serverインスタンスをホストするそれぞれのコンピュータ上で、WebLogic Serverインスタンスが管理サーバーか管理対象サーバーであるかにかかわらず、実行する必要があります。

注意:
ホスト・マシンが再起動した場合に、ノード・マネージャが自動的に再起動するよう、ノード・マネージャはオペレーティング・システムのサービスとして実行することをお薦めします。

ノード・マネージャに障害が発生しても、マシン上で実行しているサーバーには影響しません。

詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareコンセプトの理解』のノード・マネージャの概要に関する項を参照してください。

8.3 管理サーバーの高可用性トポロジ

管理サーバーは、1つのホスト上でいつでもアクティブ化できます。高可用性を設定するには、管理サーバーを仮想ホスト上に構成して、それを実行しているマシンに障害が発生した場合に、ドメイン内の別のホストにフェイルオーバーします。管理サーバーは、仮想IPを使用して、バックアップ・ホストとオーバーラップするように構成されます。この仮想IPをリスニングするように、管理サーバーを構成します。仮想ホストおよび仮想IPを使用する利点は第3のマシンを追加する必要がない点にあり、フェイルオーバーが発生した場合は仮想IPを移動することで、ドメイン内の障害の発生していないマシンに仮想ホストをマップできます。

2つのホストで、仮想ホスト名および仮想IPを共有します。ただし、この仮想IPを使用できるのは、常に1つのアクティブ・ホストに限定されます。アクティブ・ホストに障害が発生した場合はバックアップ・ホストがアクティブ化され、仮想IPを新しいアクティブ・ホストに(手動で)移動します。すべてのリクエストは、仮想IPを通じて、新しいアクティブ・ホストで処理されます。(この仮想IPをリスニングするように、高可用性デプロイメントを構成します。)

高可用性管理サーバーの障害を、次の図に示します。このトポロジでは、管理サーバーは仮想ホストAPPHOST0上で実行されます。APPHOST0は、仮想IPによってAPPHOST1またはAPPHOST2にオーバーラップされます。最初、APPHOST0はAPPHOST1にマップされますが、APPHOST1が原因で管理サーバーに障害が発生した場合は、仮想IPを移動することによって、APPHOST0をAPPHOST2にフェイルオーバーします。

図8-1 管理サーバーの高可用性トポロジ

8.4 管理サーバーの高可用性の構成

この項の内容は次のとおりです。

- 第8.4項「管理サーバーの高可用性の要件」

- 第8.4.2項「高可用性の管理サーバーの構成」

高可用性の管理サーバー環境では、両方のホストから共有記憶域にアクセスできる必要があります。ドメイン・ディレクトリは、共有記憶域に保持されます。通常の運用時は、アクティブ・ホスト上の管理サーバーによってドメイン・ディレクトリが所有されます。アクティブ・ホストに障害が発生した場合は、バックアップ・ホストによって引き継がれ、管理サーバーは共有ドメイン・ディレクトリから再起動されます。

8.4.1 管理サーバーの高可用性の要件

高可用性の管理サーバーを構成するには、ご使用の環境が次の要件を満たす必要があります。

- 標準インストール・トポロジに準拠すること。第1.6項「Oracle Fusion Middlewareの標準的なHAトポロジの理解」および図1-1「Oracle Fusion Middlewareの高可用性デプロイメント・トポロジ(一般的な企業)」を参照してください。

- 2つのホスト、APPHOST1およびAPPHOST2を組み込んで、WebLogic Serverクラスタ(cluster_1)を実装すること。第8.4.2項「高可用性の管理サーバーの構成」では、APPHOST1およびAPPHOST2のIPアドレスは、それぞれip1およびip2です。

- APPHOST1およびAPPHOST2に、共有記憶域から共通のディレクトリがマウントされ、そのディレクトリの読取り/書込み権限が与えられること。このディレクトリは、製品のインストールおよびドメイン・ディレクトリの格納に使用されます。

- 予約済仮想IPアドレス(vip0)によって管理サーバーを実行しているホストを指し示すこと。この仮想サーバーを示す浮動IPアドレスが、管理サーバーを実行しているホスト上で動的に構成されること。

- 管理サーバーは、ノード・マネージャ・インスタンスによって管理され、障害の発生したホストから指定されたスタンバイ・ホストに移行されること。

8.4.2 高可用性の管理サーバーの構成

高可用性の管理サーバーを構成するには、まず1つのクラスタ(cluster_1)を持つ標準高可用性トポロジを作成する必要があります。第1.6項「Oracle Fusion Middlewareの標準的なHAトポロジの理解」を参照してください。

高可用性の管理サーバーを設定するには、管理サーバーを別の仮想ホスト(APPHOST0)上で実行します。APPHOST0が、クラスタ内の既存のホストのうちの1つ(APPHOST1またはAPPHOST2)にマップされるように、APPHOST0用の(仮想)サーバーIPをそのホストに設定します。フェイルオーバーが発生した場合は、障害が発生していないホストにこの仮想IPが移行されることで、APPHOST0がフェイルオーバーされます。ドメイン設定は、障害の発生していないホストからアクセスできるように、共有記憶域に置かれます。

注意:
管理サーバーのサービスで構成タスクを完了するには、複数の方法があります。いずれの方法を使用するにしても、構成を変更する際はクラスタの管理サーバーが稼働している必要があります。

表8-2 ホストおよびノード・マネージャの用語

用語

説明

APPHOST0、machine_0

管理サーバーが実行される仮想マシン

APPHOST1、APPHOST2

アプリケーション層がホストされるマシン

vip0

管理サーバーによってリスリングされる仮想サーバーのIPアドレス

NMa

APPHOST0で実行される管理サーバーを管理する、ドメインごとのノード・マネージャ

NM1、NM2

APPHOST1およびAPPHOST2でそれぞれ実行されるノード・マネージャのインスタンス

ip1、ip2

それぞれ、APPHOST1およびAPPHOST2のIPアドレス

高可用性の管理サーバーを設定するには、次の手順を実行します。

1. 仮想ホストAPPHOST0を表す仮想サーバーIPアドレス(vip0)をAPPHOST1に構成します。
詳細は、『Oracle WebLogic Serverサーバー環境の管理』の仮想ホスティングの構成に関する項を参照してください。

2. Oracle Fusion Middleware拡張インストール手順を使用して、Oracle Fusion Middlewareバイナリをインストールし、共有記憶域のディレクトリ内にドメインを構成します。vip0を管理サーバーのリスニング・アドレスに使用します。

3. 仮想マシンmachine_0を作成し、そこに管理サーバーを追加します。このマシンmachine_0は、IPアドレスvip0の仮想サーバー・ホストAPPHOST0を表します。

4. machine_1 and machine_2にそれぞれ割り当てられた2つの管理対象サーバーserver_1およびserver_2,を持つクラスタ(cluster_1)を作成します。

- machine_1はAPPHOST1を表し、machine_2はAPPHOST2を表します。

- server_1およびserver_2を、それぞれip1およびip2をリスニングするよう設定します。

5. 仮想サーバーを、APPHOST1およびAPPHOST2にスケール・アウトします。第6.2項「トポロジのスケール・アウト手順.」を参照してください。スケール・アウトするには、共有記憶域でドメインをパックし、APPHOST1およびAPPHOST2のローカル・ディレクトリにアンパックします。

6. APPHOST1でドメインごとのノード・マネージャ(NMa)を起動し、構成済の仮想サーバーIPアドレスvip0をAPPHOST1でリスニングする管理サーバーを管理します。ノード・マネージャのこのインスタンスを、共有記憶域のドメイン・ディレクトリで起動します。

7. APPHOST1で、ドメインごとのノード・マネージャ(NM1)を起動し、ip1をリスニングするserver_1を管理します。このノード・マネージャ(NM1)を、手順5でAPPHOST1のローカル記憶域にアンパックしたドメイン・ディレクトリで起動します。

8. APPHOST2で、ドメインごとのノード・マネージャ(NM2)を起動し、ip2をリスニングするserver_2を管理します。このノード・マネージャ(NM2)を、手順5でAPPHOST2のローカル記憶域にアンパックしたドメイン・ディレクトリで起動します。

9. ノード・マネージャ(NMa)を使用して、APPHOST1で管理サーバーを起動します。

10. 管理サーバーserver_1およびserver_2を、それぞれNM1およびNM2を使用して起動します。

11. 管理サーバーおよび管理対象サーバーが適切に機能していることを確認します。仮想IPアドレスvip0を使用して、管理サーバーに接続します。

8.5 管理サーバーのフェイルオーバーまたはフェイルバック

ホストの障害の発生後、管理サーバーをフェイルオーバーまたはフェイルバックするには、次の各項目を参照してください。

- 第8.5.1項「元のホストに障害が発生した場合の管理サーバーのフェイルオーバー」

- 第8.5.2項「元のホストへの管理サーバーのフェイルバック」

8.5.1 元のホストに障害が発生した場合の管理サーバーのフェイルオーバー

APPHOST1に障害が発生した場合に、管理サーバーをAPPHOST2にフェイルオーバーには、次のようにします。

1. vip0をAPPHOST2に構成します。

2. APPHOST2の共有記憶域のドメイン・ディレクトリで、ノード・マネージャNMaを起動します。

3. APPHOST2でNMaを使用して、管理サーバーを起動します。

4. 管理コンソールを起動して、管理サーバーが実行されていることを確認します。

8.5.2 元のホストへの管理サーバーのフェイルバック

管理サーバーが再起動した後、元のホストにフェイルバックします。

APPHOST1がオンラインに復帰してから、管理サーバーをAPPHOST1にフェイルバックするには、次のようにします。

1. ノード・マネージャNMaを使用して、APPHOST2の管理サーバーを停止します。

2. vip0を、APPHOST2から削除します。

3. APPHOST2で、ノード・マネージャNMaを停止します。

4. vip0をAPPHOST1に構成します。

5. 共有記憶域のドメイン・ディレクトリを使用して、APPHOST1でノード・マネージャNMaを起動します。

6. ノード・マネージャNMaを使用して、APPHOST1で管理サーバーを起動します。

7. 管理コンソールを起動して、管理サーバーが実行されていることを確認します。

第III部

コンポーネントの構成手順

第III部では、特定のコンポーネント製品に固有の構成手順について説明します。

この部の内容は次のとおりです:

- 第9章「Web層コンポーネントの高可用性の構成」

- 第10章「Oracle WebCenterコンポーネントの高可用性の構成」

- 第11章「その他のコンポーネントの高可用性の構成」

9 Web層コンポーネントの高可用性の構成

Oracle Fusion MiddlewareのWeb層は、エンド・ユーザーに最も近い、アーキテクチャの最も外側にあります。この項の内容は次のとおりです。

- 第9.1項「Oracle HTTP Serverと高可用性の概要」

- 第9.2項「Oracle HTTP Serverの単一インスタンスの特性」

- 第9.4項「Oracle HTTP Serverの起動とシャットダウンのライフサイクル」

- 第9.5項「Oracle HTTP Serverの起動と停止」

- 第9.6項「Oracle HTTP Serverの高可用性アーキテクチャとフェイルオーバーに関する考慮事項」

- 第9.7項「Oracle HTTP Serverの障害保護および予想される動作」

- 第9.8項「複数のマシンでのOracle HTTP Serverインスタンスの構成」

- 第9.9項「Oracle HTTP Serverの高可用性の構成」

9.1 Oracle HTTP Serverと高可用性の概要

Oracle HTTP Server (OHS)は、Oracle Fusion MiddlewareのWebサーバー・コンポーネントで、主要なWeb層コンポーネントです。それは、Oracle WebLogic Server用のリスナーと、静的ページ、動的ページおよびWeb上のアプリケーションをホストするフレームワークを提供します。

関連項目:
OHSの操作の詳細は、次を参照してください。

- 『Oracle HTTP Serverの管理』のOracle HTTP Serverの管理に関する項。この項には、基本的なOHSタスクの実行、OHSインスタンスの作成、サーバー・プロセスの管理とモニタリングなどのトピックが含まれています。

- Oracle Fusion Middleware Oracle HTTP Serverのインストールと構成

9.2 Oracle HTTP Serverの単一インスタンスの特性

Oracle HTTP Server (OHS)は、Apacheインフラストラクチャをベースとしており、OHSのコア機能を拡張するためのOracleモジュールが含まれます。Oracle HTTP Serverには、クライアント・リクエストを処理するための次のコンポーネントが含まれます。

- HTTPリスナー: 受信リクエストを処理し、これを適切な処理ユーティリティにルーティングします。

- モジュール(mod): OHS機能を実装および拡張します。Oracle HTTP Serverには、多数の標準Apacheモジュールが含まれます。OHSおよびOHSコンポーネント統合をサポートするOHS固有のモジュールも含まれます。

Oracle HTTP Serverは、フォワード・プロキシ・サーバーにも、リバース・プロキシ・サーバーにもなります。リバース・プロキシでは、様々なサーバーで処理されたコンテンツを1つのサーバーから送信されたように処理することができます。

9.3 Oracle HTTP Serverおよびドメイン

Oracle HTTP ServerにとってOracle WebLogicドメインは必須ではありませんが、通常はOracle WebLogicドメインと組み合せて使用します。OHSを管理コンソールに組み込むことにより一元的な管理やモニタリングが実現するため、OHSはドメインと関連付けることをお薦めします。

mod_wl_ohsモジュールは、管理対象サーバーへのリンクを処理します。このモジュールは、特定のタイプ(JSPなど)のリクエストのルーティング、または特定の管理対象サーバーへのURL対するリクエストのルーティングによって構成されています。

Oracle HTTP Serverは、通常、クラスタのフロントエンド処理を行います。この構成では、特殊なmod_wl_ohsディレクティブ、WebLogicClusterにより、クラスタ・メンバーをカンマ区切りリストで指定します。

次の手順では、mod_wl_ohsディレクティブ・プロセスを説明します。

1. 管理対象サーバーへのリクエストがmod_wl_ohsで受信されると、そのリクエストは、ディレクティブのクラスタ・メンバーの1つに送信されます。少なくとも1つの管理対象サーバーが、要求を満たすために使用できる必要があります。

2. 管理対象サーバーがリクエストを受信すると、そのリクエストを処理して、クラスタ・メンバーの完全なリストをmod_wl_ohsに送り返します。

3. mod_wl_ohsがその更新されたリストを受信すると、未知のサーバーが既知のサーバーのリストに動的に追加されます。これにより、後続のリクエストはすべてクラスタ・メンバー・リスト間でロード・バランシングされます。これは、mod_wl_ohsを更新またはOHSを追加せずに、新しい管理対象サーバーがクラスタに追加されるという利点があります。

注意:
未知のサーバーが既知のサーバーのリストに追加されるかどうかは、mod_wl_ohsディレクティブDynamicServerListによって制御されます。動的なサーバーの追加を有効にするには、DynamicServerListをONに設定する必要があります。

注意:
開始時に、すべての現行の管理対象サーバーをmod_wl_ohsディレクトリに含める必要はありません。高可用性設定では、リスト内に2つのクラスタ・メンバーさえいれば、最初の呼出しが機能します。OHSの高可用性デプロイメントを実行する方法の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverプロキシ・プラグインの使用』のOracle HTTP Server用のWebLogicプロキシ・プラグインの構成に関する項を参照してください。

関連項目:
Oracle WebLogicクラスタの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』を参照してください。

9.4 Oracle HTTP Serverの起動とシャットダウンのライフサイクル

Oracle HTTP Serverが起動すると、HTTP(S)リクエストのリスニングおよび応答の準備が整います。

Microsoft Windowsシステムでのリクエスト処理モデルは、UNIXシステムでのモデルとは異なります。

- Microsoft Windowsの場合、1つの親プロセスと1つの子プロセスが存在します。子プロセスは、クライアント・リクエストを処理するスレッドを作成します。作成されるスレッド数は静的で、パフォーマンスに応じて構成できます。

- UNIXでは、複数の子プロセスを管理する1つの親プロセスがあります。子プロセスは、リクエストを処理します。親プロセスは、構成に基づき、必要に応じて追加の子プロセスを作成します。

関連項目:
OHS処理モデルの詳細は、『Oracle HTTP Server管理者ガイド』のOracle HTTP Server処理モデルに関する項を参照してください。

9.5 Oracle HTTP Serverの起動と停止

Fusion Middleware ControlまたはWebLogic Scripting Tool (WLST)を使用して、Oracle HTTP Serverを起動、停止および再起動します。WLSTの使用を予定している場合は、『Oracle Fusion Middleware管理者ガイド』のOracle WebLogic Scripting Tool (WLST)の使用のスタート・ガイドを参照してください。

関連項目:
OHSを開始および停止する手順は、『Oracle HTTP Server管理者ガイド』のOracle HTTP Serverの基本タスクの実行に関する項を参照してください。

9.6 Oracle HTTP Serverの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

次の図は、ロード・バランサの後方に配置された2つのOracle HTTP Serverを示しています。

図9-1 Oracle HTTP Serverの高可用性アーキテクチャ

ロード・バランサは、ユーザーからリクエストを受信して、それを接続されたOracle HTTP Serverに転送します。ロード・バランサは、リクエストを標準HTTP/HTTPSポート(80/443)で受信します。しかし、Oracle HTTP Serverにリクエストを渡すときは、まったく別のポートを使用します。この設定の利点は、次のとおりです。

- ユーザーからは実際のポートが見えなくなります。

- ユーザーは、ポート番号をURLに付加する必要がなくなります。

UNIXベースのシステムでは、root権限でのOHSの起動は必須ではありません。1024未満のポートを使用するプロセスを起動できるのは、rootのみです。ただし、1024未満のポート番号を使用するプロセスを起動するには、root権限を使用してプロセスを起動する必要があります。

ロード・バランサは、稼働中のOracle HTTP Serverにリクエストをルーティングします。

前述の図は、OHSから管理対象サーバーにリクエストが分散される仕組みも示しています。高可用性の場合、コンポーネントの各ペア(OHSと管理対象サーバー)は、別のホスト・コンピュータに存在する必要があります。管理対象サーバーは同じクラスタに存在しています。管理対象サーバー間でロード・バランシングするには、それらのサーバーが同じクラスタに存在する必要があります。

9.7 Oracle HTTP Serverの障害保護および予想される動作

Oracle HTTP Serverでは、プロセス障害とノード障害の2つのタイプの障害が発生します。プロセス障害は、個々のオペレーティング・システムで発生する可能性があります。一方、ノード障害は、Oracle HTTP Server (OHS)を実行しているホスト・コンピュータ全体の障害に及ぶ可能性があります。

Table 9-1 OHS障害タイプと障害保護

障害タイプ

保護

プロセス

ノード・マネージャは、OHSプロセスの保護と監視を行います。OHSプロセスに障害が発生すると、ノード・マネージャによって自動的にプロセスが再起動されます。

ノード

OHSの前面のロード・バランサは、最初のOHSが応答しない、またはURLピングが障害は発生したことを示している場合、別のOHSにリクエストを送信します。

管理対象サーバー

クラスタ内で管理対象サーバーに障害が発生すると、mod_wl_ohsによってアクティブなクラスタ・メンバーのいずれかにリクエストが自動的にリダイレクトされます。アプリケーションに状態が格納されている場合、状態のレプリケーションがクラスタ内で使用可能になり、これにより、リダイレクトされたリクエストが、同じ状態情報にアクセスできます。

データベース

通常、mod_oradavまたはmod_plsqlを使用している場合にのみ、問題になります。Oracle RACデータベースでは、Oracle RAC接続により、障害の特徴が判別されます。

クライアント接続フェイルオーバーが構成されている場合、進行中のトランザクションがロールバックされます。データベースが接続されている必要があります。

透過的アプリケーション・フェイルオーバー(TAF)が構成されている場合は、進行中のすべてのデータベースの書込みはロールバックされますが、データベースへの再接続が自動的に行われ、select文は自動的にリカバリされます。TAFはselect文のみをフェイルオーバーし、パッケージ変数は失われます。TAFのJDBC Oracle Call Interfaceドライバ機能により、接続先のデータベース・インスタンスに障害が発生した場合でも、アプリケーションはデータベースに自動的に再接続できます。この場合、アクティブ・トランザクションはロールバックされます。

9.8 複数のマシンでのOracle HTTP Serverインスタンスの構成

構成ウィザードを使用してOracle HTTP Server (OHS)を構成し、OHSがドメインの一部である場合、各インスタンスのmod_wl_ohs.confファイルを更新します。ファイルは、DOMAIN_HOME/config/fmwconfig/components/OHS/componentNameディレクトリ内にあります。管理サーバーを再起動して、ドメインのすべてのOHSインスタンス(たとえそれらが別のホストにある場合でも)に変更を伝搬します。

関連項目:
mod_wl_ohsファイルの詳細は、第9.9.1.6項「mod_wl_ohs.confの構成」を参照してください。

注意:
OHSインスタンスを別々のドメインにインストールおよび構成する場合、変更を他のOracle HTTP Serverに手動でコピーする必要があります。すべてのOHSインスタンスに変更が適用されていることと、それらのインスタンスが同期されていることを確認する必要があります。

9.9 高可用性のためのOracle HTTP Serverの構成

この項では、Oracle HTTP Server (OHS)の高可用性デプロイメントの構成方法について、例をあげて説明します。

この項の内容は次のとおりです。

- 第9.9.1項「高可用性OHSの構成の前提条件」

- 第9.9.2項「WEBHOST2へのOracle HTTP Serverのインストールと検証」

- 第9.9.3項「OHS高可用性デプロイメントの構成と検証」

9.9.1 高可用性OHSの構成の前提条件

Oracle HTTP Serverの高可用性デプロイメントを構成する前に、次の前提条件を考慮します。

- 第9.9.1.1項「ロード・バランサの要件」

- 第9.9.1.2項「ロード・バランサの仮想サーバー名とポートの構成」

- 第9.9.1.3項「ロード・バランサのポート番号の管理」

- 第9.9.1.4項「WEBHOST1へのOracle HTTP Serverのインストールと検証」

- 第9.9.1.5項「WEBHOST1での仮想ホストの作成」

- 第9.9.1.6項「mod_wl_ohs.confの構成」

9.9.1.1 ロード・バランサに関する前提条件

Oracle HTTP Serverにリクエストを分散させるには、使用可能なOracle HTTP Server間でHTTP(S)リクエストを分散させるために、外部ロード・バランサを使用する必要があります。外部ロード・バランサを使用している場合は、第2.2.2項「サード・パーティ製のロード・バランサの要件」で説明する機能を備えている必要があります。

9.9.1.2 ロード・バランサの仮想サーバー名とポートの構成

OHSのインストールでは、これらの仮想サーバーはHTTP接続に対して構成され、この接続はHTTPサーバー全体に分散されます。

サイトでHTTPおよびHTTPS接続のリクエストを処理する場合は、HTTPSリクエストはロード・バランサで終了し、そのリクエストをHTTPリクエストとして通過させることをお薦めします。これを行うには、ロード・バランサでプロトコルを変換できることが必要です。また、永続HTTPセッションを実行できるように構成する必要があります。

この例では、ロード・バランサが次のように構成されていると想定します。

- 仮想ホスト: Myapp.example.com

- 仮想ポート: 7777

- サーバー・プール: Map

- サーバー: WEBHOST1、Port 7777、WEBHOST2、Port 7777

9.9.1.3 ロード・バランサのポート番号の管理

多くのOracle Fusion Middlewareコンポーネントおよびサービスはポートを使用します。管理者は、これらのサービスが使用するポート番号を把握し、1つのホスト・コンピュータ上の2つのサービスによって同じポート番号が使用されないようにする必要があります。

ほとんどのポート番号は、インストール中に割り当てられます。Oracle HTTP ServerからOracle WebLogic Serverに送信されるすべてのトラフィックは、すべてのファイアウォールを通じてアクセスできることが重要です。

9.9.1.4 WEBHOST1へのOracle HTTP Serverのインストールと検証

WEBHOST1上にOHSをインストールする方法については、『Oracle Fusion Middleware Oracle HTTP Serverのインストールと構成』のOracle HTTP Serverソフトウェアのインストールに関する項の手順を参照してください。

OHSホーム・ページにアクセスする次のURLを使用して、インストールを確認します。

http://webhost1:7777/

9.9.1.5 WEBHOST1での仮想ホストの作成

使用するそれぞれの仮想ホストまたはサイト名に対して、OHSの構成にエントリを追加します。次のように、ORACLE_HOME/config/fmwconfig/components/OHS/componentName/moduleconfディレクトリ内にvirtual_hosts.confという名前のファイルを作成します。

NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName http://myapp.example.com:80
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>

SSL/SSLターミネーション(*)を使用する場合は、次のようになります

NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName https://myapp.example.com:443
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>

注意:
また、Fusion Middleware Controlを使用して仮想ホストを作成できます。『Oracle Fusion Middleware Oracle Fusion Middlewareの管理』のコンポーネントを一緒にワイヤリングする方法に関する項を参照してください

9.9.1.6 mod_wl_ohs.confの構成

Oracle HTTP Serverのインストールと構成を終えたら、DOMAIN_HOME/config/fmwconfig/components/OHS/コンポーネント名ディレクトリにあるmod_wl_ohs.confファイルを編集して、定義済の管理対象サーバーにそれをリンクします。

mod_wl_ohs.confファイルを編集する方法の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverプロキシ・プラグイン12.1.2の使用』のOracle HTTP Server用のWebLogicプロキシ・プラグインの構成に関する項を参照してください。

注意:
また、Fusion Middleware Controlを使用して、OHSを管理対象サーバーにリンクできます。『Oracle Fusion Middleware Oracle Fusion Middlewareの管理』のコンポーネントを一緒にワイヤリングする方法に関する項を参照してください

次のサンプルは、mod_wl_ohs.confエントリを示します。

LoadModule weblogic_module PRODUCT_HOME/modules/mod_wl_ohs.so

<IfModule mod_weblogic.c>
WebLogicCluster apphost1.example.com:7050, apphost2.example.com:7050
MatchExpression *.jsp
</IfModule>

<Location /weblogic>
SetHandler weblogic-handler
WebLogicCluster apphost1.example.com:7050,apphost2.example.com:7050
DefaultFileName index.jsp
</Location>

<Location /console>
SetHandler weblogic-handler
WebLogicCluster apphost1.example.com
WebLogicPort 7003
</Location>

この例は、管理対象サーバーにリクエストをルーティングする2つの方法を示しています。

- <ifModule>ブロックでは、*.jspで終わるすべてのリクエストがAPPHOST1およびAPPHOST2上にあるWebLogic管理対象サーバーのクラスタに送信されます。

- <Location>ブロックでは、/weblogicの接頭辞を持つURLのすべてのリクエストがAPPHOST1およびAPPHOST2上にある管理対象サーバーのクラスタに送信されます。

9.9.1.7 SSL終端使用時のmod_wl_confの構成

SSLターミネーションを使用しており、なおかつWebLogicにリクエストをルーティングしている場合は、次の追加の構成手順が必要です。

1. WebLogicコンソールで、「WebLogicプラグインの有効化」が、ドメイン、クラスタ、または管理対象サーバーのレベルでtrueに設定されていることを確認します。

2. これらの行を、管理対象サーバーにリクエストを転送するLocationブロックに追加します。

WLProxySSL ON
WLProxySSLPassThrough ON

例:

<Location /weblogic>
SetHandler weblogic-handler
WebLogicCluster apphost1.example.com:7050,apphost2.example.com:7050
WLProxySSL On
WLProxySSLPassThrough ON
DefaultFileName index.jsp
</Location>

WebLogicプラグインを有効化した後、管理サーバーを再起動します。

9.9.2 WEBHOST2へのOracle HTTP Serverのインストールと検証

WEBHOST2上にOracle HTTP Serverをインストールする方法については、『Oracle Fusion Middleware Oracle HTTP Serverのインストールと構成』のOracle HTTP Serverソフトウェアのインストールに関する項を参照してください。

Oracle HTTP Serverホーム・ページにアクセスする次のURLを使用して、WEBHOST2上のインストールを確認します。

http://webhost2:7777/

9.9.3 OHS高可用性デプロイメントの構成と検証

OHS高可用性デプロイメントの構成と検証は、次の手順で実行します。

- 第9.9.3.1項「WEBHOST2での仮想ホストの作成」

- 第9.9.3.2項「Oracle HTTP Serverの構成の検証」

9.9.3.1 WEBHOST2での仮想ホストの作成

DOMAIN_HOME/config/fmwconfig/components/OHS/コンポーネント名ディレクトリに置かれているmod_wl_ohs.confファイルを更新します。管理サーバーを再起動して、ドメインのすべてのOHSインスタンスに変更を伝搬する必要があります。

9.9.3.2 Oracle HTTP Serverの構成の検証

次のURLを使用して構成を検証します。

http://myapp.example.com/

https://myapp.example.com (SSL/SSLターミネーションを使用している場合)

http://myapp.example.com:7777/weblogic

10 Oracle WebCenterコンポーネントの高可用性の構成

この項では、Oracle WebCenter製品に高可用性を構成する方法を説明します。

この項には次のトピックが含まれます:

- 第10.1項「WebCenter Content: Inbound Refineryコンポーネントの拡張について」

- 第10.2項「WebCenter Contentのスケール・アップについて」

- 第10.3項「WebCenter Portalコンポーネントの複数ノード上での作成について」

- 第10.4項「WebCenter CaptureドメインのOracle SOAでの作成について」

- 第10.5項「WebCenter Captureのスケール・アウトとOWSMの構成」

- 第10.6項「WebCenter Sitesコンポーネント接続について」

- 第10.7項「WebCenter Sitesとマルチキャストについて」

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

- Oracle Fusion Middleware Oracle WebCenter Contentのインストールと構成

- 『Oracle Fusion Middleware Oracle WebCenter Portalのインストールと構成』

- 『Oracle Fusion Middleware Oracle WebCenter Sitesのインストールと構成』

- Oracle Fusion Middleware Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイド

10.1 WebCenter Content: Inbound Refineryコンポーネントの拡張について

WebCenter Content: Inbound Refineryコンポーネントでは、WebLogic Serverクラスタリングを使用してスケール・アップおよびフェイルオーバーを実行しません。固有のInbound Refinery管理対象サーバーを複数構成して、WebCenter Contentで使用します。

10.2 WebCenter Contentのスケール・アップについて

Oracle WebCenter Contentをスケール・アップすることはできません。

10.3 WebCenter Portalコンポーネントの複数ノード上での作成について

WebCenter Portalの高可用性設定で、リフレッシュ間隔のデフォルトが10分であるために、2番目のノードでデータの表示が遅れる場合があります。たとえば、ノード1がリクエストの処理中で、ノード2上に作成した新しいポータル・コンポーネントへのアクセスを試みる場合に、発生することがあります。

10.4 WebCenter CaptureドメインのOracle SOAでの作成について

WebCenter CaptureドメインをOracle SOAコンポーネントで作成する場合、JRF-MAN-SVRおよびWSMPM-MAN-SVRサーバー・グループを選択する必要があります。これらのサーバー・グループによって、Oracle JRFとOracle Web Services Manager (OWSM)のサービスが、作成中の管理対象サーバーにターゲット設定されます。

10.5 WebCenter Captureのスケール・アウトとOWSMの構成

OWSMはクロス・コンポーネント・ワイヤリングを使用して、ドメイン内のポリシー・マネージャを自動検出します。構成ウィザードを使用してOWSMを含むドメインを作成または更新するとき、ローカル・サービス表にポリシー・マネージャURLが公開されます。ローカル・サービス表に公開されたエンドポイント・エントリを使用して、OWSMエージェントが自動的にOWSMポリシー・マネージャに接続されます。ただし、構成ウィザード以外のツール(WebLogic管理コンソール、Fusion Middleware ControlまたはWLSTなど)を使用してドメインを変更した場合、ポリシー・マネージャURLへの変更は自動的にローカル・サービス表に公開されますが、OWSMエージェントのクライアントは自動的に新しいURLにバインドされません。この場合、ポリシー・マネージャURLにOWSMエージェントを手動でバインドする必要があります。詳細は、 『Oracle Fusion Middleware Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のFusion Middleware Controlを使用したエージェント・バインディングの検証に関する項を参照してください。

10.6 WebCenter Sitesコンポーネント接続について

WebCenter Sitesでは、外部コンポーネントが開始され、実行されている時に、接続の確立を試みる必要があります。外部コンポーネントが停止中で起動していない場合、または接続がタイムアウトの場合、WebCenter Sitesは接続を再試行しません。

WebCenter Sitesは、データベース接続がアクティブであることを確認し、これがアクティブである時のみ接続を再確立します。

10.7 WebCenter Sitesとマルチキャストについて

WebCenter Sitesは、マルチキャスト・サポートに依存し、inCacheレプリケーションをクラスタ化環境内のノードに提供します。WebCenter SitesでのinCacheサポートの詳細は、『Oracle Fusion Middleware Oracle WebCenter Sitesの管理』のinCacheフレームワークの使用に関する項を参照してください。

11 その他のコンポーネントの高可用性の構成

この項では、その他のコンポーネント製品に固有の情報について説明します。

このリリースでの、この項の内容は次のとおりです。

- 第11.1項「Oracle Data Integratorのデプロイ」

- 第11.2項「Oracle Application Development Frameworkのデプロイ」

- 第11.3項「BIのデプロイ」

- 第11.4項「Formsのデプロイ」

- 第11.5項「Reportsのデプロイ」

11.1 Oracle Data Integratorのデプロイ

このトピックでは、Oracle Real Application ClustersへのOracle Data Integratorリポジトリ接続を構成する際の考慮事項について説明します。

- 第11.1.1項「ソース接続およびターゲット接続に対するOracle RACの再試行の接続」

- 第11.1.2項「Oracle RACへのODIリポジトリ接続の構成」

- 第11.1.3項「Oracle Data Integratorスケジューラ・ノードの障害」

11.1.1 ソース接続およびターゲット接続に対するOracle RACの再試行の接続

Oracle Data Integrator (ODI) Oracle Real Application Clusters (RAC)接続を構成する場合、ODIマスターまたはODI作業リポジトリに対してOracle RAC再試行がサポートされます。ODIは、ODIシナリオの実行中に、ソース接続およびターゲット接続へのトランザクション接続を使用します。これらのソース接続およびターゲット接続については、ODIはRAC再試行の接続をサポートしていません。これらのトランザクションをOracle RACの別のノードに移行することはできません。

11.1.2 Oracle RACへのODIリポジトリ接続の構成

リポジトリ作成ユーティリティ(RCU)を使用してODIリポジトリを作成する際、作業リポジトリ接続のJDBC URLを指定します。RCUは、このURLをマスター・リポジトリ・コンテンツに格納します。作業リポジトリのJDBC URLが単一ノードURLの場合、Oracle Real Application Clusters (Oracle RAC)のフェイルオーバー・アドレスを含むようにURLを変更する必要があります。

- Oracle RACが単一クライアント・アクセス名(SCAN)で構成されていない場合は、Oracle RACインスタンスの詳細を提供できます。作業リポジトリのJDBC URLフィールドで、Oracle RAC接続アドレスをhost:portの形式で入力します。次の例を参照してください。

- Oracle RACをSCANで構成している場合、Oracle RACインスタンスの詳細にSCANアドレスを提供します。

次の例に、SCANを使用しない場合に、2つのホストを持つOracle RACに接続するためのJDBC URL書式を示します。

jdbc:oracle:thin:(DESCRIPTION =(LOAD_BALANCE=ON) (ADDRESS =(PROTOCOL =tcp)
(HOST =host1)(PORT =port1)) (ADDRESS =(PROTOCOL =tcp)(HOST =host2)
(PORT =port2)) (CONNECT_DATA =(SERVER=dedicated)
(SERVICE_NAME=service_name)))

詳細は、『Oracle Data Integratorの管理』の作業リポジトリの作成に関する項を参照してください。

11.1.3 Oracle Data Integratorスケジューラ・ノードの障害

WebLogic Serverのフェイルオーバーが発生した場合は、他のWebLogic Serverインスタンスがスケジューラになります。Coherenceキャッシュによって、スケジューラ・ライフサイクルが処理されます。ロックにより、スケジューラの一意性が保証され、イベント通知はスケジューラの移行を知らせます。エージェントが再起動され、そのスケジュールが計算された場合は、進行中のスケジュールが考慮され、それらの実行サイクルは、サーバーの起動時間を過ぎても自動的に継続されます。新しいセッションは、スケジューラが停止しなかったかのようにトリガーされます。失効セッションは、エラー状態に移動され、再起動時にはその状態が保持されます。

Oracle Data Integratorエージェント・クラスタで、スケジューラ・ノードであるエージェント・ノードに障害が発生すると、クラスタ内の別のノードがスケジューラ・ノードとしての役割を引き継ぎます。新しいスケジューラ・ノードにより、すべてのスケジュールが再初期化され、その時点から実行されます。

ノードで障害が発生した際に反復可能な実行サイクルを持つスケジュール済シナリオが実行中の場合、スケジューラ・ノードがクラッシュした時点以降、そのシナリオは新しいスケジューラ・ノードでは反復が続行されません。たとえば、スケジュール済シナリオが2分間隔で10回実行を繰り返すように構成されている場合、3回目の実行中にスケジューラ・ノードで障害が発生すると、新しいスケジューラ・ノードでは、シナリオの残りの8回は実行されません。

11.2 Oracle Application Development Frameworkのデプロイ

この項には次のトピックが含まれます:

- 第11.2.1項「Oracle JRF非同期Webサービス(固定サービスの動作)」

関連項目:
Oracle Application Development Framework (ADF)の詳細は、次を参照してください。

- 「Oracle Application Development Frameworkの理解」の「Oracle ADFの主要概要」

- Oracle Fusion MiddlewareでのOracle ADFアプリケーションの管理

11.2.1 Oracle JRF非同期Webサービス(固定サービスの動作)

Oracle JRF非同期Webサービスを使用している場合は、非同期Webサービスがサービスに固定されるため、フェイルオーバーは実行されません。WS-RMなどの信頼性の高いプロトコルを使用している場合は、障害の発生後に、より上位レベルのプロトコルによって新しいサーバーへの再接続が実行されます。

Oracle JRF非同期Webサービスの詳細は、『ドメイン・テンプレート・リファレンス』を参照してください。

11.3 BIのデプロイ

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

- 第11.3.1項「BIセッションのフェイルオーバーについて」

- 第11.3.2項「BI Essbaseについて」

- 第11.3.3項「BI Studioについて」

- 第11.3.4項「複数のノード・マネージャへのポートの指定について」

- 第11.3.5項「RACデータベースのインストール後の構成について」

- 第11.3.6項「BI Publisherのスケール・アウトについて」

11.3.1 BIセッションのフェイルオーバーについて

BI管理対象サーバーまたはホスト(あるいはその両方)がクラッシュすると、再びログインが必要な場合があります。これは、クラッシュの発生時にどのアプリケーションを使用していたか、およびSSOを使用していたかどうかにより、異なります。

11.3.2 BI Essbaseについて

Essbaseは、高可用性構成をサポートしていません。サーバーで障害が発生した場合、Essbase Cubeをデプロイして障害をリカバリできます。

11.3.3 BI Studioについて

Studioは、高可用性構成をサポートしていません。xmlインポート/エクスポートを定期的に実行することを、お薦めします。これは、Studioのカタログ障害からリカバリするためのベスト・プラクティスです。

11.3.4 複数のノード・マネージャへのポートの指定について

マシンごとに1つ以上のノード・マネージャがある場合、ポートが指定されていることを確認してください。詳細は、『Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』を参照してください。

11.3.5 RACデータベースのインストール後の構成について

Oracle Business Intelligenceでは、インストール後にサーバー全体を移行するための追加の構成手順が必要です。これらの手順の詳細は、『Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』のエンタープライズ・デプロイメントでのサーバー全体の移行およびサービスの移行の使用に関する項を参照してください。

11.3.6 BI Publisherのスケール・アウトについて

Oracle Business Intelligenceでは、第6章「トポロジのスケール・アウト(マシンのスケール・アウト)」で説明するスケール・アウトの手順に従った後、追加の構成手順が必要です。Oracle BIでは、setDomainEnv.shを更新されたsingleton-data-directory設定(SDD)に変更する必要があります。

Oracle BIのスケール・アウトを完了するには、次のようにします。

1. SDDをローカルから共有記憶域に移動し、すべてのホストが同一のパスを使用してSDDにアクセスできるようにします。たとえば、次のように移動します。
DOMAIN_HOME/bidata/net/yoursystem/scratch/sdd

2. DOMAIN_HOME/config/fmwconfig/bienv/core/bi-environment.xml (要素 bi:singleton-data-directory)を開きます。

3. xdo.server.config.dirパスを変更して、新しく作成したSDDパスを参照します。

4. サーバーを再起動します。

11.4 Formsのデプロイ

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

- 第11.4.1項「Forms HTTPセッションのフェイルオーバーについて」

11.4.1 Forms HTTPセッションのフェイルオーバーについて

Forms HTTPセッションに障害が発生した場合、セッションをFormsアプリケーションに再接続し、再起動する必要があります。

11.5 Reportsのデプロイ

高可用性設定でのReportsには、次の考慮事項があります。

- 第11.5.1項「Reportsでのスケール・アップについて」

- 第11.5.1項「Reportsでのスケール・アップについて」

- 第11.5.2項「Reportsのマルチキャスト通信について」

- 第11.5.3項「Reportsの共有ファイル・ベース・キャッシュについて」

- 第11.5.4項「Reportsのデータベース・サービス障害について」

- 第11.5.5項「ReportsのOID/共有キャッシュ・ファイル・システムの障害について」

11.5.1 Reportsでのスケール・アップについて

Reportsコンポーネントをスケール・アップする場合、構成が完了したら、すべてのノードを停止し、再び開始することをお薦めします。

『Oracle Fusion Middleware Oracle Reports ServicesレポートWeb公開ガイド』のOracle Reports Serverの開始と停止に関する項を参照してください。

11.5.2 Reportsのマルチキャスト通信について

Reportsクラスタのメンバーまたは個別のクライアントは、他のノードを検出するためにマルチキャストを使用します。マルチキャスト使用の回避方法はありません。

11.5.3 Reportsの共有ファイル・ベース・キャッシュについて

Reportsには、シングルトンとして共有ファイル・ベース・キャッシュがあります。キャッシュが失敗すると、高可用性も失敗します。

回避策はありません。共有ファイル・ベースのキャッシュで障害が発生したら、Reportsサーバーを再起動する必要があります。

11.5.4 Reportsのデータベース・サービス障害について

Reportsコンポーネントは、データベース障害を容認します。Reportsは、データベース接続を3回試行します。データベースが起動してから、Reportsを再実行する必要があります。

11.5.5 ReportsのOID/共有キャッシュ・ファイル・システムの障害について

Reportsは、OID/共有キャッシュ・ファイル・システム障害が発生しても、再試行しません。回避策はありません。外部システムが起動してから、Reportsを再実行する必要があります。

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2016, Oracle and/or its affiliates.All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティについて

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。