Oracle® Fusion Middleware

高可用性ガイド

12c (12.1.3.0.0)

E56218-02(原本部品番号:E49894-02)

2014年7月

管理者や開発者など、高可用性を扱う方が参照するドキュメントとして、高可用性の概要について説明し、また高可用性を目的としてOracle Fusion Middlewareをデプロイおよび管理するための管理手順と構成手順についても説明します。

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

E56218-02

Copyright © 2014, Oracle and/or its affiliates. All rights reserved.

原本著者: Christine Ford

原本協力著者: Michael Blevins、Suvendu Ray、Peter LaQuerre

原本協力者:  Gururaj BS

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

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

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

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、このソフトウェアまたはハードウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(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の登録商標です。

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

目次

例一覧

図一覧

表一覧

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

はじめに

- 対象読者

- このガイドの目的

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

- 関連ドキュメント

- 表記規則

第I部 高可用性の概要

1 概要とロードマップ

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

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

- 1.3 高可用性とは

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

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

2 高可用性の概要

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

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

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

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

- 2.2 アプリケーションのフェイルオーバー

- 2.3 Real Application Clusters

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

- 2.5 障害時リカバリ

- 2.6 インストール時の構成

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

- 2.6.2 永続性プロファイル

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

3 サーバー全体の移行

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

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

- 3.2.1 サーバー全体の自動移行を構成するための前提条件

- 3.2.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.5 JMSストアおよびJTAログ用の共有記憶域の要件

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

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

- 5.1 Oracle Real Application Clustersについて

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

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

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

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

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

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

- 5.4.1 要件

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

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

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

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

- 5.5.1.1 要件

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

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

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

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

6 JMSおよびJTAの高可用性

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

- 6.2 JMSおよびJTAの高可用性サービスの構成

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

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

- 6.4.1 NFSでのファイル・ストアの使用に関する考慮事項

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

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

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

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

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

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

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

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

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

- 7.5 リソース要件

- 7.6 新しいマシンの作成

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

- 7.6.2 新しいマシンの作成

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

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

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

- 7.9 新しいマシンの準備

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

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

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

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

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

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

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

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

- 8.1 管理サーバーの役割

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

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

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

- 8.4.1 要件

- 8.4.2 管理サーバーの構成

- 8.4.2.1 管理サーバーのフェイルオーバー

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

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

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

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

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

- 9.2.1 Oracle HTTP ServerとOracle WebLogic 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.8.1 前提条件

- 9.8.1.1 ロード・バランサの構成

- 9.8.1.2 WEBHOST1へのOracle HTTP Serverのインストール

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

- 9.8.1.4 mod_wl_ohs.confの構成

- 9.8.2 WEBHOST2へのOracle HTTP Serverのインストール

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

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

- 9.8.3.2 Oracle HTTP Serverの構成の検証

10 Oracle SOA Suiteの高可用性の構成

- 10.1 高可用性のためのOracle BAMの構成

- 10.1.1 スケール・アップ後のOracle BAM管理対象サーバーのJMSシステム・リソースの構成

- 10.1.1.1 Oracle BAMサーバーのJMSサーバーの構成

- 10.1.1.2 Oracle BAM CQServiceのJMSサーバーの構成

- 10.1.2 Oracle BAMの自動サービス移行の構成

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

- 11.1 Oracle Data Integratorのデプロイ

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

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

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

- 11.2 Oracle Application Development Frameworkのデプロイ

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

- 11.2.2 mdsDSデータ・ソースのURLの変更

例一覧

- 11-1 JDBC URLの書式(Oracle RACがSCANで構成されていない場合)

図一覧

- 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 CoherenceおよびCoherenceクラスタ

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

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

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

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

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

- 5-1 Oracle RACの設定手順

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

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

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

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

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

- 8-1 管理サーバーに関する項目

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

はじめに

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

- 対象読者

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

- 関連ドキュメント

- 表記規則

対象読者

『Oracle Fusion Middleware高可用性ガイド』12c (12.1.3.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項「Oracle Fusion Middlewareの標準的なHAトポロジの理解」

1.1 このガイドの使用方法

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

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

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

表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.2 このリリースの新機能と変更された機能

Oracle Fusion Middleware 12c (12.1.3.0.0)は、以前のOracle Fusion Middlewareのリリースと比べて次のような新しい概念と機能、および変更された概念と機能を導入しています。

- サーバー全体の移行のサポート。第3章「サーバー全体の移行」を参照してください。

- 管理サーバーの高可用性のサポート。第8章「管理サーバーの高可用性」を参照してください。

- SOAのサポート。第10章「Oracle SOA Suiteの高可用性の構成」を参照してください。

関連項目:

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

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

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

1.3 高可用性とは

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

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

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

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

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

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

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

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

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

図1-1は、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では、図1-1の要素について説明します。

表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の制御に関する項を参照してください。

インフラストラクチャ

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

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

- Oracle Application Developer Framework (Oracle ADF)

- Oracle Web Services Manager (OWSM)

関連項目:

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

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

2 高可用性の概要

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

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

- 第2.2項「アプリケーションのフェイルオーバー」

- 第2.3項「Real Application Clusters」

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

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

- 第2.6項「インストール時の構成」

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

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.1 高可用性環境でのサーバーのロード・バランシング

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

通常、Oracle Fusion Middlewareの高可用性デプロイメントのフロントエンドには、受信したリクエストを分散するように、様々なアルゴリズムを使用して構成できるロード・バランサが配置されます。様々なコンポーネントまたはアプリケーション間のロード・バランシングを構成できます。

また、Oracle HTTP Serverを使用するか、Oracle Traffic Director (Exalogicのみに搭載)を使用して、様々なコンポーネント間やアプリケーション間で、ロード・バランシングを構成することもできます。詳細は、第2.1.3項「Oracle HTTP ServerまたはOracle Traffic Directorによるサーバーのロード・バランシング」を参照してください。

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

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

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

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

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

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

Oracle Fusion Middlewareの高可用性デプロイメントには、サード・パーティ製のロード・バランサを使用できます。

注意:

スティッキー・セッション・ルーティングをサポートするサード・パーティ製のロード・バランサの使用をお薦めします。スティッキー・セッション・ルーティングは、最初のリクエストを処理するサーバーに、セッション全体を通じてトラフィックをルーティングする機能です。

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

- 仮想ホスト名を使用してトラフィックを実際のサーバーのプールにロード・バランシングする機能: クライアントは仮想ホスト名を使用してサービスにアクセスします(実際のホスト名は使用しない)。これにより、ロード・バランサは、プール内のサーバーに対するリクエストをロード・バランシングできます。

注意:

通常は、ロード・バランサがOracle HTTP Serverインスタンス全体のバランスを取り、その後でOracle HTTP Serverがアプリケーション・サーバー全体のバランスを取ります。

- ポート変換の構成。

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

- 仮想サーバーとポートの構成: 外部ロード・バランサの仮想サーバー名とポートを構成する機能。さらに、仮想サーバー名とポートは次の要件を満たしている必要があります。

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

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

- ノード障害を検出し、障害が発生したノードへのトラフィックのルーティングを即座に停止する機能。

- リソースのモニタリング/ポートのモニタリング/プロセス障害の検出: ロード・バランサは、サービス障害およびノード障害を(通知またはその他の方法によって)検出し、障害のあるノードへの非Oracleネット・トラフィックの転送を停止する必要があります。外部ロード・バランサに障害の自動検出機能がある場合は、それを使用することをお薦めします。

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

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

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

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

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

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

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

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

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

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

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

Oracle HTTP Serverを使用したサーバーのロード・バランシング

Oracle HTTP Serverは、WebLogic Serverプロキシ・プラグイン・モジュールが組み込まれたWebサーバーであり、1つ以上のWebLogic ServerのHTTPフロントエンドとして機能します。この組込み機能がクライアントからのリクエストを受信し、1つ以上のWebLogic Serverで負荷のバランスを取ります。

Oracle HTTP Serverには、Oracle WebLogic Serverにリクエストをルーティングするmod_wl_ohsモジュールがあります。mod_wl_ohsモジュールは、Apache HTTP Server用のOracle WebLogic Serverプラグイン(mod_weblogic)と同じロード・バランシング機能を提供します。詳細は、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を使用したサーバーのロード・バランシング

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

2.2 アプリケーションのフェイルオーバー

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

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

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

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

注意:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

関連項目:

高可用性をサポートするドメイン・テンプレートおよび拡張テンプレートの詳細は、ドメイン・テンプレート・リファレンスを参照してください。

詳細は、『Oracle WebLogic Serverクラスタの管理』のクラスタにおけるフェイルオーバーおよびレプリケーションに関する項を参照してください。

2.3 Real Application Clusters

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

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

関連項目:

Oracle RACの詳細は、次のものを参照してください。

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

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

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

2.4 Coherenceクラスタと高可用性

『Oracle Fusion Middleware Oracle WebLogic ServerおよびCoherenceのインストールと構成』またはOracle Fusion Middleware Oracle Application Development FrameworkのためのOracle Fusion Middlewareのインストールと構成などの製品インストレーション・ガイドの手順に従っている場合、標準的なインストール・トポロジには、追加構成の開始点となる標準的な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)ファイル内に含まれます。アプリケーションとともにGARファイルがデプロイされ、すべての専用記憶域ノードに格納されます。

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

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

情報

参照先

Coherenceの概要と機能

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

Coherenceクラスタの作成

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

Coherenceクラスタの構成

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

2.5 障害時リカバリ

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

Oracle Fusion Middlewareコンポーネントの障害時リカバリの詳細は、『Oracle Fusion Middlewareディザスタ・リカバリ・ガイド』を参照してください。

2.6 インストール時の構成

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

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

- 第2.6.2項「永続性プロファイル」

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

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

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

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

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

2.6.2 永続性プロファイル

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

表2-3は、データベースとファイルの永続性プロファイルについて、それぞれの永続性タイプを示しています。

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

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

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

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

JMS

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

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

JTA

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

ファイル・ストア内のJTA

OPSS

データベース・ストア

データベース・ストア

MDS

データベース・ストア

データベース・ストア

サービス表

データベース・ストア

データベース・ストア

フェイルオーバー

サーバー全体の移行

サーバー全体の移行

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

注意:

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

関連項目:

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

構成後のデフォルト設定

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

注意:

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

表2-4は、その他の参照情報です。

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

詳細情報

参照先

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

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

JMSおよびJTA

第6.2項「JMSおよびJTAの高可用性サービスの構成」

フェイルオーバー

第2.2項「アプリケーションのフェイルオーバー」

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

この項では、第1.5項「Oracle Fusion Middlewareの標準的なHAトポロジの理解」で説明したトポロジのような、高可用性のミドルウェア・トポロジのサンプルを構成するための、高レベルな手順を示します。

表2-5に、高可用性トポロジの設定に必要な手順を示します。

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

作業

説明

マニュアル

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.1項「高可用性環境でのサーバーのロード・バランシング」を参照

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

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

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

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

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

第8章「管理サーバーの高可用性」を参照してください。

3 サーバー全体の移行

この章では、サーバー全体の移行およびそれを管理対象サーバーのフェイルオーバー用に構成する方法について説明します。サーバー全体の移行は、JMSやJTAなどの特殊なサービスを使用している場合に必要です。

サーバー全体の移行が行われると、障害の発生時に、サーバー・インスタンスが別の物理マシンに移行されます。

サーバー全体の移行の詳細は、『Oracle WebLogic Serverクラスタの管理』のサーバー全体の移行に関する項を参照してください。

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

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

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

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

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

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

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

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

関連項目:

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

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

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

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

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

この項では、次の項目について説明します。

- 第3.2.1項「サーバー全体の自動移行を構成するための前提条件」

- 第3.2.2項「サーバー全体の移行の構成」

3.2.1 サーバー全体の自動移行を構成するための前提条件

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

3.2.2 サーバー全体の移行の構成

サーバーの移行を構成する前に、ご使用の環境が第3.2.1項「サーバー全体の自動移行を構成するための前提条件」に示されている要件を満たしていることを確認してください。

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

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

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

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

第II部

高可用性環境の構築

第II部は、次の章で構成されています。

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

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

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

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

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

4 共有記憶域の使用

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

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

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

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

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

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

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

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

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

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

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

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

4.1 共有記憶域の概要

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

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

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

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

項目/タスク

参照先

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

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

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

『Oracle WebLogic Serverサーバー環境の構成』のWebLogic永続ストアの使用に関する項(永続ストアの高可用性に関する項)

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

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

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

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

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

- 共有記憶域のデバイスには、ネットワーク接続ストレージ(NAS)またはストレージ・エリア・ネットワーク(SAN)の使用をお薦めします。
NFSマウント・システムを使用する場合は、ファイルのロックに関連する問題および突然のノード障害が検出されます。第6.4.1項「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に関する情報をファイル・ストアに保存する方法の詳細は、『Oracle WebLogic Serverサーバー環境の管理』のWebLogic永続ストアの使用に関する項を参照してください。

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

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

- 第4.3.1項「バイナリ(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 Fusion Middlewareでは、1つの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.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.5 JMSストアおよびJTAログ用の共有記憶域の要件

高可用性設定でファイル・ベースの永続性を使用する場合は、JMS永続ストアとJTAトランザクション・ログのディレクトリが共有記憶域に配置されるように構成する必要があります。詳細は、第6.4項「ファイル永続性を使用するうえでの考慮事項(WebLogic JMS)」を参照してください。

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

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

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

要素

場所

ORACLE_HOME

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

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

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

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

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

注意:

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

図4-1は、ディレクトリ構造を表しています。

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

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

この章では、Oracle Fusion Middlewareの高可用性を設定して、データベース接続を構成するときの考慮事項について説明します。また、よくデプロイされるデータベースの高可用性ソリューションでOracle Real Application Clusters (Oracle RAC)を使用する利点についても説明します。

Fusion Middlewareコンポーネントのほとんどでは、そのデータの永続ストアとしてデータベースが使用されます。ここでOracle Databaseを使用すると、高可用性の様々な構成が可能になります。

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

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

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

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

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

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

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

5.1 Oracle Real Application Clustersについて

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

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

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

表5-1は、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.2 RACのデータベース接続およびフェイルオーバーについて

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

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

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

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

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

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

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

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

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

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

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

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

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

注意:

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

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

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

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

5.3.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.3.2 マルチ・データ・ソース

マルチ・データ・ソースとは、データ・ソースのグループの抽象概念であり、接続要求時には、マルチ・データ・ソースに関連付けられたデータ・ソースの間で、ロード・バランシングまたはフェイルオーバーが処理されます。マルチ・データ・ソースは、XAデータ・ソースとXA以外のデータ・ソース両方のロード・バランシングをサポートします。

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

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

関連項目:

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

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

アクティブなGridLinkデータ・ソースの構成方法は、使用しているOracleコンポーネントおよび作成するドメインによって異なります。

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

このトピックには、次の項があります。

- 第5.4.1項「要件」

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

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

関連項目:

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

5.4.1 要件

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

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

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

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

5.4.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. 「次へ」を選択します。すべての接続が正常かどうかを検証します。

注意:

顧客が用意したADFアプリケーションでアクティブなGridLinkデータ・ソースを使用する場合は、「mdsDSデータ・ソースのURLの変更」を参照してください。

関連項目:

詳細は、次を参照してください:

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

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

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

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

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

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

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

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

- Oracle WebLogic Server管理コンソール

- WLSTコマンド

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

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

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

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

この項では、Oracle RACでマルチ・データ・ソースを構成するための要件と手順について説明します。

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

- 第5.5.1.1項「要件」

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

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

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

5.5.1.1 要件

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

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

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

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

5.5.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.5.1.3 初期構成後のマルチ・データ・ソースの変更または作成

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

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

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

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

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

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

- 表5-4「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

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

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

[javax.transaction.SystemException: Timeout during commit processing

このような警告が表示された場合は、個々のデータ・ソースのXAタイムアウトを増加できます。

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.5.1.4 トランザクション・リカバリ権限のスキーマの構成

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

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

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

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

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

sqlplus "/ as sysdba"

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

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

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

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

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

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

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

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

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

注意:

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

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

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

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

注意:

顧客が用意したADFアプリケーションでマルチ・データ・ソースを使用する場合は、「mdsDSデータ・ソースのURLの変更」を参照してください。

6 JMSおよびJTAの高可用性

この章では、Java Message Service (JMS)およびJava Transaction API (JTA)の高可用性について説明します。

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

- 第6.1項「JMSおよびJTAの高可用性サービスについて」

- 第6.2項「JMSおよびJTAの高可用性サービスの構成」

- 第6.3項「ユーザー優先サーバーと候補サーバー」

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

- 第6.5項「データベース永続ストアを使用したWLS JMSの構成」

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

関連項目:

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のドメイン構成およびクラスタ構成に関する項

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

Java Message Service (JMS)は、ネットワーク内のコンピュータ間でメッセージングと呼ばれる正式な通信をサポートするApplication Program Interface (API)です。

Java Transaction API (JTA)は、トランザクション・マネージャと分散トランザクション・システム(リソース・マネージャ、アプリケーション・サーバーおよびトランザクション・サーバー)に関わるパーティ間の標準のJavaインタフェースを指定します。

WebLogic JMSでは、宛先のホストJMSサーバーが実行中の場合のみ、メッセージを使用可能です。メッセージが中央の永続ストアにある場合、それにアクセスできるのは、最初にメッセージを格納したサーバーのみです。WebLogicには、障害後にJMSサーバーを自動的に再起動または移行(あるいはその両方)する機能があります。また、同じクラスタ内の複数のJMSサーバー間で宛先をクラスタリング(分散)する機能もあります。

サーバー全体の移行または自動サービス移行のいずれかを使用すれば、JMSサーバーを自動的に再起動または移行(フェイルオーバー)する、あるいはその両方が可能です。

関連項目:

サーバー全体の移行の詳細は、第3章「サーバー全体の移行」を参照してください。

6.2 JMSおよびJTAの高可用性サービスの構成

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

JMSサービスを移行できるように構成するには、そのサービスを移行可能ターゲットにデプロイする必要があります。移行可能ターゲットでは、ターゲットをホストできるサーバーのセットを指定し、そのサービスを優先的にホストするサーバーを指定したり、その優先サーバーで障害が発生した場合のバックアップ・サーバー候補を順序付けしたリストを指定したりできます。移行可能なターゲットをホストできるサーバーは常に1つのみです。

移行可能ターゲットを使用するようにサービスを構成すると、そのサービスは、現時点でそれをホストしているサーバー・メンバーから独立した存在になります。たとえば、JMSキューがデプロイされているJMSサーバーを、移行可能ターゲットを使用するように構成した場合、そのキューは、特定のサーバー・メンバーが使用可能かどうかに依存せずに動作します。つまり、このキューは、移行可能ターゲットがクラスタ内のいずれかのサーバーでホストされているかぎり、常に使用できます。

固定された移行可能サービスは、サーバーの障害への対応として、または定期的に計画されるメンテナンスの一環として、クラスタ内のサーバー・インスタンスから別のサーバー・インスタンスに手動で移行できます。クラスタ内に移行可能ターゲットを構成しない場合、移行可能サービスは、クラスタ内のどのWebLogic Serverインスタンスにも移行できます。

関連項目:

JMSの管理の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSリソースの管理』の次の内容に関する各項を参照してください。

- 高可用性ベスト・プラクティス

- 「Oracle AQ JMSとの相互運用性」

6.3 ユーザー優先サーバーと候補サーバー

JMSサービスを移行可能ターゲットにデプロイする際は、サービスをホストするユーザー優先サーバーのターゲットを選択できます。また、移行可能ターゲットを構成する場合は、ユーザー優先サーバーで障害が発生したときにサービスをホストできる控えの候補サーバー(CCS: Constrained Candidate Server)を指定することもできます。移行可能ターゲットに控えの候補サーバーが指定されていない場合、JMSサーバーをクラスタ内で使用可能な任意のサーバーに移行できます。

WebLogic Serverでは、JMSサービスごとに別々の移行可能ターゲットを作成できます。これにより、必要に応じて、クラスタ内の別々のサーバーで常に各サービスを実行し続けることが可能になります。また逆に、JTAとJMS両方の控えの候補サーバーとして同じサーバー群を選択し、両方のサービスが確実にクラスタ内の同じサーバーに配置されるように構成することもできます。

関連項目:

詳細は、管理コンソール・オンライン・ヘルプの次の各項目を参照してください。

- JMS関連サービスのための移行可能ターゲットの構成

- JTAトランザクション回復サービスの移行可能ターゲットの構成

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

ファイル・システム上に格納されるJMSメッセージとJTAログを構成できます。高可用性を確保するためには、共有ファイル・システムを使用する必要があります。共有ファイル・システムを使用して、これらのアーティファクトを格納する際の考慮事項については、第4章「共有記憶域の使用」を参照してください。

関連項目:

詳細は、『Oracle WebLogic Server JMSリソースの管理』のWebLogic JMSのアーキテクチャおよび環境に関する項を参照してください。

6.4.1 NFSでのファイル・ストアの使用に関する考慮事項

JMSメッセージおよびトランザクション・ログをNFSにマウントされたディレクトリに格納している場合、予期しないマシン障害の後にサーバーの再起動の動作を確認することを強くお薦めします。NFSの実装に応じて、フェイルオーバーまたは再起動後に異なる問題が発生する可能性があります。

サーバーの再起動の動作を確認するには、WebLogic Serverの実行時に、それらのサーバーをホストするノードを異常停止させます。

- サーバーをサーバー移行用に構成した場合、サーバーは、フェイルオーバー期間の経過後にフェイルオーバー・モードで自動的に起動します。

- サーバーをサーバー移行用に構成しなかった場合、ノードが完全に再起動した後に同じホスト上のWebLogic Serverを手動で再起動できます。

予期しないマシン障害の後にOracle 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つのドメインに同じディレクトリを参照する同じ名前のストアを含めることはできない、などがあげられます。

ファイル・ストアを使用する場合は、サーバー移行用に、必ずデータベース・ベースのリース・オプションを構成してください。このオプションにより、データベース表を使用した追加のロック・メカニズムが強制的に適用され、特定の管理対象サーバーの複数のインスタンスが自動的に再起動しなくなります。

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

管理コンソールを使用してデフォルト・ファイル・ストアのファイル・ロックを無効化するには、次の手順を実行します。

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>

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

管理コンソールを使用してカスタム・ファイル・ストアのファイル・ロックを無効化するには、次の手順を実行します。

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>

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>

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

管理コンソールを使用して診断ファイル・ストアのファイル・ロックを無効化するには、次の手順を実行します。

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サーバーおよび永続ストアに関する項

- 『Oracle Fusion Middleware Oracle WebLogic Serverサーバー環境の構成』のWebLogic永続ストアの使用に関する項

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

永続ストアは、永続性を必要とするWebLogic Serverのサブシステムおよびサービスに対し、組込みの高性能なストレージ・ソリューションを提供します。たとえば、永続的なJMSメッセージを格納できます。

WLS JMS永続ストアは、ファイルベースのストアまたはデータベース内でJDBCでアクセス可能なストアへの永続性に対応しています。この項では、WLS JMS構成を、ファイルベースの永続ストア(デフォルト構成)からデータベースの永続ストアに変更する方法を説明します。

永続ストアの詳細は、『Oracle WebLogic Serverサーバー環境の管理』のWebLogic永続ストアの使用に関する項を参照してください。

WebLogicメッセージング・コンポーネントのモニター、制御および構成に必要な、一般的なタスクの詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のWebLogic Serverメッセージングに関する項を参照してください。

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

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

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

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

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

データベース永続ストアを使用したWLS JMSを構成するには、ご使用の設定が次の要件を満たしていることを確認してください。

- 少なくとも1つのクラスタと1つ以上のJMSサーバーを使用するOracle Fusion Middlewareがインストールされていること

- JMSサーバーが、ファイル永続ストアを使用すること(デフォルト構成)

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

この項では、WLS JMSを、デフォルトのファイルベースの永続ストアから、データベースベースの永続ストアに切り替える手順を説明します。

次の手順は、データベース永続ストアを使用する構成のJMSサーバーごとに、実行する必要があります。

1. JDBCストアを作成します。手順の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverサーバー環境の管理』のJDBCストアの使用に関する項を参照してください。

注意:

JDBCストアのデータベース表に一意の名前を付けるための接頭辞を、指定する必要があります。

2. JDBCストアをJMSサーバーに関連付けます。

1. Weblogic Server管理コンソールで、「サービス」→「メッセージング」→「JMSサーバー」に移動します。

2. このサーバーに保留メッセージがないことを確認します。「制御」タブで、すべての宛先に対するメッセージの生成および挿入を停止し、残りのメッセージが排出されるのを待ちます。

3. 「全般的な構成」タブを選択します。「永続ストア」で新しく作成したJDBCストアを選択し、「保存」をクリックします。

データベース永続ストアを使用して、JMSサーバーが起動されます。

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

この項では、トランザクション・ログ(TLOG)用のデータベースベースのストアを構成する手順を説明します。JDBC TLOGストアを構成する前に、Oracle Fusion Middlewareの標準的なインストールを行う必要があります。

標準的なインストールの後で、ファイル・システムにTLOGストアを構成します。場合によっては、TLOGをデータベースに格納するよう構成することをお薦めします。

JDBC TLOGをデータベース・ストアに格納するよう構成する手順の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverサーバー環境の管理』のJDBC TLOGストアの使用に関する項を参照してください。

次の点に注意してください。

- クラスタ内の管理対象サーバーごとに、この手順を繰り返してください。

- 管理対象サーバー名を接頭辞に使用して、それぞれの管理対象サーバーごとに一意のTLOGストア名を作成してください。

- 高可用性設定では、永続ストア用に作成したデータ・ソースが、このクラスタにターゲット設定されていることを確認してください。

構成を完了すると、構成済のデータベースベースの永続ストアに、TLOGが送信されます。

注意:

スケール・アップまたはスケール・アウトによって、クラスタに新しい管理対象サーバーを追加する場合は、新しい管理対象サーバー用のJDBC TLOGストアも作成する必要があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

作業

説明

参照先

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

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

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

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

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

第7.5項「リソース要件」

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

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

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

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

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

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

packコマンドの実行

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

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

新しいマシンの準備

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

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

unpackコマンドの実行

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

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

サーバーの起動

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

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

トポロジの検証

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

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

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

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

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

注意:

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

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

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

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

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

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

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

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

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

関連項目:

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

7.5 リソース要件

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

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

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

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

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

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

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

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

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

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

7.6 新しいマシンの作成

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

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

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

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

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

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

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

7.6.2 新しいマシンの作成

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

注意:

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

ドメイン内に新しいマシンを作成するには、管理コンソールで次の手順を実行します。

1. ドメインの管理サーバーが稼働していない場合は、起動する必要があります。DOMAIN_HOME/binディレクトリに移動して、次のように実行します。

./startWeblogic.sh

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

http://hostname:port/console

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

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

注意:

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

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

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

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

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

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

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

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

新しく作成したマシンに管理対象サーバーを割り当てるには、管理コンソールで次の手順を実行します。

1. 「チェンジ・センター」で、「ロックして編集」をクリックします。

2. 「マシン」表で、machine_1用のチェック・ボックスを選択します。

3. マシン名(ハイパーリンクとして表示)をクリックします。

4. machine_1の「設定」で、「構成」タブ、「サーバー」サブタブの順にクリックします。

5. 「サーバー」表の上にある「追加」をクリックします。

6. 「マシンにサーバーを追加」ページで「新しいサーバーを作成してこのマシンに関連付けます。」をクリックします。「次へ」をクリックし、「サーバー名」と「サーバー・リスニング・ポート」の各フィールドを入力します(必須)。

7. 「ドメイン構造」の下で、「マシン」をクリックします。
「マシン」表で、マシン「machine_2」をクリックします。

8. machine_2の「設定」の下で、「構成」タブ、「サーバー」タブの順にクリックします。「サーバー」タブの上にある「追加」をクリックします。
「マシンにサーバーを追加」画面で「既存のサーバーを選択して、このマシンに関連付けます。」ボタンを選択します。

「サーバーの選択」ドロップダウン・リストから「server_2」を選択し、「終了」を選択します。

「サーバーが正常に作成されました。」というメッセージが表示されます。

9. すべての管理対象サーバーに、適切な「サーバー・リスニング・アドレス」が割り当てられていることを確認します。「ドメイン構造」で、「サーバー」をクリックします。「サーバー」表で、管理対象サーバー名をクリックします。「構成」タブを選択します。「リスニング・アドレス」を確認または関連付けられているマシンのIPアドレスに設定します。「保存」をクリックします。

10. 変更を完了するために、「チェンジ・センター」に戻ります。「変更のアクティブ化」をクリックします。メッセージ「すべての変更がアクティブ化されました。再起動は不要です。」が表示されます。
管理対象サーバー割当てのサマリーを表示するには、「ドメイン構造」の下にある「環境」で「サーバー」をクリックします。右側の「サーバー」表に、そのドメイン内の全サーバー、およびそれらのマシンの割当てが表示されます。

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

この項では、マシンのスケール・アップまたはスケール・アウト後の、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リソースが格納された新しい管理対象サーバーが、クラスタで使用可能になります。

注意:

Oracle BAMコンポーネント用のWLS JMSを構成するには、第10.1.1項「スケール・アップ後の、Oracle BAM管理対象サーバーのJMSシステム・リソースの構成」を参照してください。第10.1.1項には、JMSシステム・リソースを構成した後で、Oracle BAMコンポーネント向きに実行する必要のある、追加の手順が記載されています。

7.8 APPHOST1上のドメインのパック

WebLogicドメイン上でpackコマンドを実行して、管理対象サーバーのテンプレートを作成します。

注意:

パックおよびアンパックの手順を実行する際には、APPHOST1上で管理サーバーが稼働している必要があります。

APPHOST1上でpackコマンドを実行して、テンプレート・パックを作成します。スケール・アウト・プロセスの後の方では、APPHOST2上でテンプレート・ファイルをアンパックします(アンパックの手順は第7.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のコマンド・リファレンスに関する項を参照してください。

7.9 新しいマシンの準備

新しいマシンmachine_2の準備として、OracleホームがインストールされているAPPHOST2から共有ディスクにアクセスできるかどうかを検証するか、machine_1上にインストールしたものと同じソフトウェアをインストールします。

たとえば、Oracle Fusion Middlewareインフラストラクチャのドメインをスケール・アウトする場合は、APPHOST2からインフラストラクチャのOracleホームにアクセスできることを検証します。

注意:

共有記憶域を使用する場合は、同じインストール場所を再利用できます。

注意:

新しいインストールを実行するか、共有記憶域を使用してバイナリを再利用する場合、新しいファイルのパスの場所は元のマシンのパスの場所と正確に一致する必要があります。

7.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

7.11 ノード・マネージャの起動

ノード・マネージャを起動するには、次のコマンドを実行します。

DOMAIN_HOME/bin/startNodeManager.sh &

ノード・マネージャがスコープ内にあるマシンを使用する場合、ノード・マネージャの起動オプションの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャの使用に関する項を参照してください。

7.12 管理対象サーバーの起動

管理コンソールから管理対象サーバーを起動するには、次の手順を実行します。

1. コンソールの左側のペインで、「環境」を開いて、「サーバー」を選択します。

2. 「サーバー」表で、新しいマシンに移動した管理対象サーバー名をクリックします。「制御」タブを選択します。

3. 起動するサーバー名の横のチェック・ボックスを選択し、「開始」をクリックして、サーバーを起動します。

関連項目:

WLSTコマンドまたはFusion Middleware Controlを使用して管理対象サーバーを起動する方法については、『Oracle Fusion Middleware Oracle Fusion Middlewareの管理』の管理対象サーバーの起動と停止に関する項を参照してください。

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

マシンのスケール・アウトが正常に完了したかどうかを検証するには、管理コンソールを使用してサーバーを起動した後に、ステータスがRUNNINGになっていることを確認します。

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

この項では、WebLogic Serverクラスタ通信用のマルチキャスト・メッセージングを構成する手順を説明します。

クラスタでは、サービスの可用性、および継続的な可用性を示すハートビートをブロードキャストするために、メッセージングが使用されます。ユニキャストまたはマルチキャスト・メッセージを使用するよう、クラスタを構成できます。

- マルチキャストは、複数のアプリケーションが指定されたIPアドレスとポート番号にサブスクライブして、メッセージをリスニングできるようにする単純なブロードキャスト技術です。マルチキャストは設定がより複雑で、ハードウェアの構成およびサポートが必要です。

- ユニキャストは、TCPベースの、信頼性ある、クラスタ用の1対多通信であり、マルチキャストに比べて設定が簡単です。

構成ウィザードでクラスタを作成した場合は、クラスタ・メッセージング・モードが、デフォルトでユニキャストに設定されます。ドメイン内のサーバー数が増加した場合は、マルチキャスト・メッセージングをお薦めします。

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

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

- 第7.14.2項「マルチキャスト・メッセージングの構成」

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

マルチキャスト・メッセージングを構成するための要件は、次のとおりです。

- 少なくとも1つのクラスタを持つドメインが構成されていること。

- ネットワークでマルチキャストをサポートするようハードウェアが構成されていること。

- クラスタ内にマルチキャスト通信用のIPアドレスおよびポート番号があること。マルチキャスト用のアドレスは、224.0.0.0から239.255.255.255までのIPアドレスです。(Weblogicでは、デフォルトで239.192.0.0が使用されます)。

- MulticastTestユーティリティを実行して、環境がマルチキャストをサポートすることを確認済であること。クラスタの構成時にMulticastTestユーティリティを使用すれば、マルチキャストに関する問題をデバッグできます。このユーティリティでは、マルチキャスト・パケットが送信され、ネットワークでマルチキャストが正常に動作しているかどうかの情報が返されます。

関連項目:

マルチキャスト・メッセージングおよびクラスタ構成の詳細は、『Oracle WebLogic Serverクラスタの管理』のクラスタ内の通信に関する項を参照してください。

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

マルチキャスト・メッセージングを構成するには、次の手順を実行します。

1. 管理コンソールにログインします。

2. マルチキャスト・メッセージングを使用するすべてのサーバーを停止します。

3. 左側の「ドメイン構造」ペインで、「環境」を開き、「クラスタ」をクリックします。

4. マルチキャストを有効にするクラスタ名を選択します。

5. 「構成」タブ、「メッセージング」タブの順にクリックします。

6. 「メッセージング・モード」で「マルチキャスト」を選択します。「マルチキャスト・アドレス」、「マルチキャスト・ポート」を入力します。
「マルチキャスト・アドレス」は、各クラスタにおいて一意である必要があります。マルチキャスト・アドレスのガイドラインは、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの管理』のクラスタのマルチキャスト・アドレスおよびポート番号に関する項を参照してください。

7. 「詳細」をクリックして、次のパラメータを構成します。

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

パラメータ

説明

Multicast Send Delay

OSレベルでのバッファのオーバーフローを防止するために、マルチキャストによるメッセージ・フラグメントの送信が遅延されるミリ秒数(0から250の間で指定)。

Multicast TTL

クラスタ・マルチキャスト・メッセージが通過できるネットワーク・ホップ数(1から255の間で指定)。クラスタがWAN内の複数のサブネットをまたぐ場合は、マルチキャスト・パケットが最終的な宛先に届く前にルーターによって破棄されることのないよう、このパラメータに十分大きな値を設定する必要があります。このパラメータにより、パケットが破棄される前にマルチキャスト・メッセージに許可される、ネットワーク・ホップ数が設定されます。

Multicast Buffer Size

マルチキャスト・ソケットの送信および受信バッファのサイズ(最小で64 KB)。

タイムアウトまでのアイドル期間

クラスタの1つのメンバーがタイム・アウトするまでにクラスタ・メンバーが待機する最大回数。

Enable Data Encryption

マルチキャスト・データの暗号化を有効化します。マルチキャスト・データのみ暗号化され、マルチキャスト・ヘッダー情報は暗号化されません。

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

9. クラスタ内のすべてのサーバーを再起動します。

これで、クラスタでマルチキャスト・メッセージを使用する準備ができました。管理コンソールの「ドメイン構造」ペインで、「クラスタ」を選択すると、「クラスタのメッセージング・モード」に「マルチキャスト」と表示されます。

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

この章では、管理サーバーの高可用性について説明します。

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

- 第8.1項「管理サーバーの役割」

- 第8.2項「ノード・マネージャの役割」

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

- 第8.4項「管理サーバーの高可用性の構成」

管理サーバーおよびノード・マネージャの詳細は、次の各項目を参照してください。

表8-1 管理サーバーに関する項目

情報

参照先

管理サーバーの起動と停止

『Oracle Fusion Middleware Oracle Fusion Middlewareの管理』の管理サーバーの起動と停止に関する項

仮想ホスティングの構成

『Oracle WebLogic Serverサーバー環境の管理』の仮想ホスティングの構成に関する項

ノード・マネージャの使用方法

『Oracle WebLogic Serverノード・マネージャの管理』の次の項目

- 「ノード・マネージャおよびシステム・クラッシュ・リカバリ」

- 「WLS環境でのノード・マネージャの動作」

- 「ノード・マネージャの構成およびログ・ファイル」

8.1 管理サーバーの役割

管理サーバーは、ドメイン全体を構成するための集中管理エンティティです。ドメインの構成ドキュメントを保持し、構成ドキュメント内の変更を管理対象サーバーに配布します。管理サーバーは、ドメイン内のすべてのリソースを管理およびモニターする中央の場所として機能します。

ドメインごとに、管理サーバーとして動作するサーバーが1つ必要です。

管理サーバーの障害

管理サーバーで障害が発生しても、ドメイン内の管理対象サーバーの動作には影響しません。管理サーバーのホスト・コンピュータ上のハードウェアまたはソフトウェアの障害が原因で管理サーバーに障害が発生した場合は、同じコンピュータ上のその他のサーバー・インスタンスが同様に影響を受けることがあります。

管理サーバーの障害の詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareの管理』の管理対象サーバーの障害の影響に関する項を参照してください。

管理サーバーを再起動する手順は、Oracle Fusion Middleware Oracleサーバー・クラスタの使用を参照してください。

共有記憶域

共有記憶域を使用すれば、バックアップ・ホストは、アクティブ・ホストと同じように、Oracleバイナリ、構成ファイル、ドメイン・ディレクトリおよびデータにアクセスできます。これらのアーティファクトを、高可用性管理サーバーの構成においてすべてのホストがアクセス可能な記憶域に配置することにより、このアクセスを構成できます。共有記憶域は、ネットワーク接続ストレージ(NAS)またはストレージ・エリア・ネットワーク(SAN)のいずれかのデバイスを使用します。詳細は、第4章「共有記憶域の使用」を参照してください。

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

デフォルトでは、作成した各WebLogic Serverドメインに対して、セキュリティ資格証明、プロパティ・ファイル、ドメイン登録および起動スクリプトを備えたドメインごとのノード・マネージャの構成が作成されます。

ノード・マネージャの範囲は構成可能です。

- ドメインごと: ドメインごとのノード・マネージャでは、ノード・マネージャがドメインと関連付けられ、マシン上のドメインのすべてのサーバーを制御するように構成されます。

- ホストごと: ホストごとのノード・マネージャでは、ノード・マネージャ・プロセスが特定のWebLogic Serverドメインとは関連付けられず、マシンと関連付けられます。ノード・マネージャ・プロセスと同じマシンに存在するサーバー・インスタンスであれば、任意のWebLogic Serverドメイン内のサーバー・インスタンスを、同じノード・マネージャ・プロセスで制御できます。ホストごとのノード・マネージャは、ノード・マネージャを使用して制御する必要があるWebLogic Serverインスタンス(管理サーバーまたは管理対象サーバーのどちらであっても)をホストする各コンピュータで実行する必要があります。

ノード・マネージャに障害が発生しても、マシン上で実行しているサーバーの動作には影響しません。

注意:

ホスト・マシンが再起動した場合に、ノード・マネージャが自動的に再起動するよう、ノード・マネージャはオペレーティング・システムのサービスとして実行することをお薦めします。

ノード・マネージャの詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareコンセプトの理解』の「ノード・マネージャとは」を参照してください。

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

単一のエンティティとして、管理サーバーは、単一のホスト上でいつでもアクティブ化できます。高可用性を実現するには、管理サーバーを仮想ホスト上に構成して、管理サーバーを実行しているマシンに障害が発生した場合に、ドメイン内の別のホストにフェイルオーバーします。管理サーバーは、仮想IPを使用して、バックアップ・ホストとオーバーラップするように構成されます。この仮想IPをリスニングするように、管理サーバーを構成します。仮想ホストおよび仮想IPを使用する利点は第3のマシンを追加する必要がない点にあり、フェイルオーバーが発生した場合は仮想IPを移動することで、ドメイン内の障害の発生していないマシンに仮想ホストをマップできます。

2つのホストで、仮想ホスト名および仮想IPを共有します。ただし、この仮想IPを使用できるのは、常に1つのアクティブ・ホストに限定されます。アクティブ・ホストに障害が発生した場合はバックアップ・ホストがアクティブ化され、仮想IPを新しいアクティブ・ホストに(手動で)移動します。すべてのリクエストは、仮想IPを通じて、新しいアクティブ・ホストで処理されます。(この仮想IPをリスニングするように、高可用性デプロイメントを構成します。)

図8-1は、高可用性管理サーバーを示しています。このトポロジでは、管理サーバーは仮想ホストAPPHOST0上で実行されます。APPHOST0は、仮想IPによってAPPHOST1またはAPPHOST2にオーバーラップされます。最初、APPHOST0はAPPHOST1にマップされますが、APPHOST1が原因で管理サーバーに障害が発生した場合は、仮想IPを移動することによって、APPHOST0をAPPHOST2にフェイルオーバーします。

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

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

この項では、高可用性を実現するための管理サーバーの構成方法について説明します。内容は次のとおりです。

- 第8.4.1項「要件」

- 第8.4.2項「管理サーバーの構成」

高可用性の管理サーバー環境では、両方のホストから共有記憶域にアクセスできる必要があります。ドメイン・ディレクトリは、共有記憶域に保持されます。通常の運用時は、アクティブ・ホスト上の管理サーバーによってドメイン・ディレクトリが所有されます。アクティブ・ホストに障害が発生した場合は、バックアップ・ホストによって引き継がれ、管理サーバーは共有ドメイン・ディレクトリから再起動されます。

8.4.1 要件

高可用性の管理サーバーを構成するには、ご使用の環境が次の要件を満たす必要があります。

- 標準インストール・トポロジに準拠すること。第1.5項「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.5項「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およびmachine_2にそれぞれ割り当てられた2つの管理対象サーバーserver_1およびserver_2を持つクラスタ(cluster_1)を作成します。

- machine_1はAPPHOST1を表し、machine_2はAPPHOST2を表します。

- server_1およびserver_2を、それぞれip1およびip2をリスニングするよう設定します。

5. 仮想サーバーを、APPHOST1およびAPPHOST2にスケール・アウトします。第7.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.4.2.1項「管理サーバーのフェイルオーバー」

- 第8.4.2.2項「元のホストへの管理サーバーのフェイルバック」

8.4.2.1 管理サーバーのフェイルオーバー

次の手順では、APPHOST1に障害が発生した場合に、管理サーバーをAPPHOST2にフェイルオーバーする方法を説明します。

1. vip0をAPPHOST2に構成します。

2. APPHOST2の共有記憶域のドメイン・ディレクトリで、ノード・マネージャNMaを起動します。

3. APPHOST2でNMaを使用して、管理サーバーを起動します。

4. 管理コンソールを起動して、管理サーバーが実行されていることを確認します。

8.4.2.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 SOA Suiteの高可用性の構成」

- 第11章「その他のコンポーネントの高可用性の構成」

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

Oracle Fusion MiddlewareのWeb層は、エンド・ユーザーに最も近い、アーキテクチャの最も外側にあります。Web層のコンポーネントの主要なコンポーネントはOracle HTTP Serverです。この章では、Oracle HTTP Serverの高可用性の概要と構成手順について、次の各項で説明します。

- 第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.1 Oracle HTTP Serverと高可用性の概要

Oracle HTTP Server (OHS)は、Oracle Fusion Middlewareの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は、Apacheインフラストラクチャをベースとしており、Oracle HTTP Serverのコア機能を拡張するためにOracleが開発したモジュールが含まれます。Oracle HTTP Serverには、クライアント・リクエストを処理するための次のコンポーネントが含まれます。

- HTTPリスナー: 受信リクエストを処理し、これを適切な処理ユーティリティにルーティングします。

- モジュール(mod): Oracle HTTP Serverの基本機能を実装および拡張します。標準的なApacheモジュールの多くは、Oracle HTTP Serverに組み込まれています。また、Oracle HTTP Serverと他のOracle HTTP Serverコンポーネントとの統合をサポートする、Oracle HTTP Serverに固有のモジュールも含まれています。

Oracle HTTP Serverは、フォワード・プロキシ・サーバーにも、リバース・プロキシ・サーバーにもなります。リバース・プロキシでは、様々なサーバーで処理されたコンテンツを1つのサーバーから送信されたように処理することができます。

9.2.1 Oracle HTTP ServerとOracle WebLogic Server

Oracle HTTP ServerにとってOracle WebLogicドメインは必須ではありませんが、通常はOracle WebLogicドメインと組み合せて使用します。Oracle HTTP Serverを管理コンソールに組み込むことにより一元的な管理やモニタリングが実現するため、Oracle HTTP ServerはWebLogicドメインと関連付けることをお薦めします。

WebLogic管理対象サーバーへのリンクは、mod_wl_ohsモジュールを介して処理されます。このモジュールは、特定のタイプ(JSPなど)のリクエストのルーティング、およびURL、つまり特定の管理対象サーバーへのリクエストのルーティングによって構成されています。

一般に、Oracle HTTP ServerはWebLogic Serverクラスタのフロントエンドに使用します。Oracle HTTP ServerをWebLogic Serverクラスタのフロントエンドにする場合、WebLogicClusterという特殊なmod_wl_ohsディレクティブにより、クラスタ・メンバーをカンマ区切りリストで指定します。このプロセスは次のように機能します。

1. 管理対象サーバーを必要とするリクエストがmod_wl_ohsで受信されると、そのリクエストは、ディレクティブにリストされているWebLogicクラスタ・メンバーの1つに送信されます。少なくとも1つ以上のサーバーが使用可能な状態になっており、リクエストに対応する必要があります。

2. 管理対象サーバーがリクエストを受信すると、そのリクエストを処理して、クラスタ・メンバーの完全なリストをmod_wl_ohsに送り返します。

3. mod_wl_ohsディレクティブがその更新されたリストを受信すると、未知のサーバーが既知のサーバーのリストに動的に追加されます。これにより、後続のリクエストはすべて完全なクラスタ・メンバー・リスト間でロード・バランシングされます。このプロセスは、mod_wl_ohsを更新したりOracle HTTP Serverを追加しなくても、新しい管理対象サーバーをクラスタに追加できるというメリットがあります。

注意:

未知のサーバーが既知のサーバーのリストに追加されるかどうかは、mod_wl_ohsディレクティブDynamicServerListによって制御されます。動的なサーバーの追加を有効にするには、DynamicServerListをONに設定する必要があります。

注意:

開始時に現行のすべての管理対象サーバーをmod_wl_ohsディレクティブに含める必要はなく、リスト内に2つのクラスタ・メンバーがあれば、最初にコールされたときに機能する高可用性を設定できます。Oracle HTTP Serverの高可用性デプロイメントを実行する方法の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverプロキシ・プラグインの使用』のOracle HTTP Server用のWebLogicプロキシ・プラグインの構成に関する項を参照してください。

関連項目:

Oracle WebLogicクラスタの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』を参照してください。

9.3 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.4 Oracle HTTP Serverの起動と停止

Oracle HTTP Serverの起動、停止および再起動は、Fusion Middleware ControlまたはWebLogic Scripting Tool (WLST)を使用して実行できます。WLSTの使用を予定している場合は、『Oracle Fusion Middleware管理者ガイド』のOracle WebLogic Scripting Tool (WLST)の使用のスタート・ガイドを参照してください。

関連項目:

OHSの起動と停止の詳細は、『Oracle HTTP Server管理者ガイド』のOracle HTTP Serverの起動、停止および再起動に関する項を参照してください。

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

図9-1は、ロード・バランサの後方に配置された2つのOracle HTTP Serverを示しています。

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

ロード・バランサは、ユーザーからリクエストを受信して、それを接続されたOracle HTTP Serverに転送します。図9-1のロード・バランサでは、標準的なHTTP/HTTPSポート(80/443)でリクエストを受信しています。しかし、Oracle HTTP Serverにリクエストを渡すときは、まったく別のポートを使用します。この設定には、次の利点があります。

- ユーザーからは実際のポートが見えなくなります。

- ユーザーは、ポート番号をURLに付加する必要がなくなります。

Unixベースのシステムでは、Oracle HTTP Serverをroot権限で起動する必要はありません。1024未満のポートを使用するプロセスを起動できるのは、rootのみです。ただし、1024未満のポート番号を使用するプロセスを起動するには、root権限が必要です。

ロード・バランサは、稼働中のOracle HTTP Serverにリクエストをルーティングします。

図9-1には、Oracle HTTP ServerからWebLogic管理対象サーバーにリクエストが分散される仕組みも示しています。高可用性の場合、コンポーネントの各ペア(Oracle HTTP ServerとWebLogic管理対象サーバー)は、別のホスト・コンピュータに存在することを前提としています。図9-1では、管理対象サーバーは同じクラスタに存在しています。管理対象サーバー間でロード・バランシングするには、それらのサーバーが同じクラスタに存在する必要があります。

9.6 Oracle HTTP Serverの障害からの保護および予想される動作

Oracle HTTP Serverの障害は、プロセス障害とノード障害という2つのカテゴリに分類できます。プロセス障害は、個々のオペレーティング・システムで発生する可能性があります。一方、ノード障害は、Oracle HTTP Serverを実行しているホスト・コンピュータ全体の障害に及ぶ可能性があります。この項では、障害タイプと、それらが発生したときのシステムまたはプロセスの引継ぎについて説明します。

プロセス障害

ノード・マネージャは、Oracle HTTP Serverプロセスの保護と監視を行います。Oracle HTTP Serverプロセスに障害が発生すると、ノード・マネージャによって自動的にプロセスが再起動されます。

ノード障害

ノード全体に障害が発生したときに、1つ目のOracle HTTP Serverが応答しない場合、またはURLのpingを使用して障害が発生していると判断された場合は、その前面にあるロード・バランサによってリクエストが別のOracle HTTP Serverに送信されます。

WebLogic管理対象サーバーの障害

高可用性デプロイメントでは、Oracle WebLogic管理対象サーバーはクラスタの一部になります。管理対象サーバーのいずれかに障害が発生した場合、mod_wl_ohsによってアクティブなクラスタ・メンバーのいずれかにリクエストが自動的にリダイレクトされます。アプリケーションに状態が格納されている場合、状態のレプリケーションがクラスタ内で使用可能になり、これにより、リダイレクトされたリクエストが、同じ状態情報にアクセスできます。

データベース障害

通常、データベース障害が問題となるのはmod_oradavまたはmod_plsqlを使用しているときのみです。このデータベースがOracle Real Application Clusters (Oracle RAC)データベースの場合は、定義済のOracle RAC接続により障害の特性が判断されます。

クライアント接続のフェイルオーバーが構成されている場合、進行中のすべてのトランザクションはロールバックされ、データベースへの再接続が必要になります。

透過的アプリケーション・フェイルオーバー(TAF)が構成されている場合は、進行中のすべてのデータベースの書込みはロールバックされますが、データベースへの再接続が自動的に行われ、select文は自動的にリカバリされます。このシナリオでは、TAFはselect文のみをフェイルオーバーし、パッケージ変数は失われます。TAFはJava Database Connectivity (JDBC) Oracle Call Interfaceドライバの機能です。この機能により、接続先のデータベース・インスタンスに障害が発生した場合でも、アプリケーションはデータベースに自動的に再接続できます。この場合、アクティブ・トランザクションはロールバックされます。

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

構成ウィザードを使用してOracle HTTP Server (OHS)のを構成し、かつOHSがドメインの一部である場合、各インスタンスごとにmod_wl_ohs.confファイル(DOMAIN_HOME/config/fmwconfig/components/OHS/コンポーネント名ディレクトリに置かれている)を更新します。管理サーバーを再起動して、ドメインのすべてのOHSインスタンス(たとえそれらが別のホストにある場合でも)に変更を伝搬します。

関連項目:

mod_wl_ohsファイルの詳細は、第9.8.1.4項「mod_wl_ohs.confの構成」を参照してください。

注意:

OHSインスタンスを別々のドメインにインストールおよび構成する場合、変更を他のOracle HTTP Serverに手動でコピーする必要があります。すべてのOHSインスタンスに変更が適用されていることと、それらのインスタンスが同期されていることを確認する必要があります。

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

この項では、Oracle HTTP Serverの高可用性デプロイメントの構成方法について、例を挙げて説明します。

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

- 第9.8.1項「前提条件」

- 第9.8.2項「WEBHOST2へのOracle HTTP Serverのインストール」

- 第9.8.3項「OHS高可用性デプロイメントの構成と検証」

9.8.1 前提条件

Oracle HTTP Serverの高可用性デプロイメントを構成する前に、次の前提条件を確認します。

- 第9.8.1.1項「ロード・バランサの構成」

- 第9.8.1.2項「WEBHOST1へのOracle HTTP Serverのインストール」

- 第9.8.1.3項「WEBHOST1での仮想ホストの作成」

- 第9.8.1.4項「mod_wl_ohs.confの構成」

9.8.1.1 ロード・バランサの構成

Oracle HTTP Serverにリクエストを分散させるには、使用可能なOracle HTTP Server間でHTTP(S)リクエストを分散させるために、外部ロード・バランサを使用する必要があります。外部ロード・バランサを使用している場合は、第2.1.1項「サード・パーティ製のロード・バランサの要件」で説明した次の機能を備えている必要があります:

- 仮想サーバー名とポートの構成

- プロセス障害の検出

- Oracle HTTPおよびHTTPSのためにポート(HTTP、HTTPS)のモニタリング

- SSLプロトコル交換(必要な場合)

次の項では、ロード・バランサを構成する手順について説明します。

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

- 「ポート番号の管理」

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

myapp.example.comなどの各アプリケーションに対して、ロード・バランサの仮想サーバー名および関連するポートを構成します。Oracle HTTP Serverのインストールでは、これらの仮想サーバーはHTTP接続に対して構成され、この接続はHTTPサーバー全体に分散されます。

サイトでHTTPおよびHTTPS接続のリクエストを処理する場合は、HTTPSリクエストはロード・バランサで終了し、そのリクエストをHTTPリクエストとして通過させることをお薦めします。これを行うには、ロード・バランサでプロトコルを変換できることが必要です。また、永続HTTPセッションを実行できるように構成する必要があります。

この例では、ロード・バランサが次のように構成されていると想定します。

- 仮想ホスト: Myapp.example.com

- 仮想ポート: 7777

- サーバー・プール: Map

- サーバー: WEBHOST1、Port 7777、WEBHOST2、Port 7777

ポート番号の管理

多くのOracle Fusion Middlewareコンポーネントおよびサービスはポートを使用します。管理者は、これらのサービスが使用するポート番号を把握し、1つのホスト上の2つのサービスによって同じポート番号が使用されないようにする必要があります。

ほとんどのポート番号は、インストール中に割り当てられます。Oracle HTTP ServerからOracle WebLogic Serverに送信されるすべてのトラフィックは、すべてのファイアウォールを通じてアクセスできることが重要です。

9.8.1.2 WEBHOST1へのOracle HTTP Serverのインストール

WEBHOST1上にOracle HTTP Serverをインストールする方法については、『Oracle Fusion Middleware Oracle HTTP Serverのインストールと構成』のOracle HTTP Serverソフトウェアのインストールに関する項の手順を参照してください。

OHSインストールの検証

次のOracle HTTP Serverホーム・ページにアクセスするURLを使用して、インストールを確認します。

http://webhost1:7777/

9.8.1.3 WEBHOST1での仮想ホストの作成

使用するそれぞれの仮想ホストまたはサイト名に対して、Oracle HTTP Serverの構成にエントリを追加します。次のように、ORACLE_HOME/config/fmwconfig/components/OHS/コンポーネント名/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.8.1.4 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>

注意:

SSLターミネーションを使用しており、なおかつWebLogicにリクエストをルーティングしている場合は、次の追加の構成が必要です。

WebLogicコンソールで、「WebLogicプラグインの有効化」を、ドメイン、クラスタ、または管理対象サーバーのレベルでtrueに設定する必要があります。

また、管理対象サーバーにリクエストを転送する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プラグインを有効化した後、管理サーバーを再起動します。

この例は、管理対象サーバーにリクエストをルーティングする2つの方法を示しています。

- <ifModule>ブロックでは、*.jspで終わるすべてのリクエストがApphost1およびApphost2上にあるWebLogic管理対象サーバーのクラスタに送信されます。

- <Location>ブロックでは、/weblogicで始まるURLのすべてのリクエストがApphost1およびApphost2上にある管理対象サーバーのクラスタに送信されます。

9.8.2 WEBHOST2へのOracle HTTP Serverのインストール

WEBHOST2上にOracle HTTP Serverをインストールする方法については、『Oracle Fusion Middleware Oracle HTTP Serverのインストールと構成』のOracle HTTP Serverソフトウェアのインストールに関する項の手順を参照してください。

OHSインストールの検証

Oracle HTTP Serverホーム・ページにアクセスする次のURLを使用して、WEBHOST2上のインストールを確認します。

http://webhost2:7777/

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

OHS高可用性デプロイメントの構成と検証は、次の手順で実行します。

- 第9.8.3.1項「WEBHOST2での仮想ホストの作成」

- 第9.8.3.2項「Oracle HTTP Serverの構成の検証」

9.8.3.1 WEBHOST2での仮想ホストの作成

DOMAIN_HOME/config/fmwconfig/components/OHS/コンポーネント名ディレクトリに置かれているmod_wl_ohs.confファイルを更新します。管理サーバーを再起動して、ドメインのすべてのOHSインスタンスに変更を伝搬する必要があります。

9.8.3.2 Oracle HTTP Serverの構成の検証

次のURLを使用して構成を検証します。

http://myapp.example.com/

https://myapp.example.com (SSL/SSLターミネーションを使用している場合)

http://myapp.example.com:7777/weblogic

10 Oracle SOA Suiteの高可用性の構成

この章では、Oracle SOA Suite製品の高可用性の構成方法を説明します。

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

- 第10.1項「高可用性のためのOracle BAMの構成」

注意:

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

- Oracle Fusion Middleware Oracle SOA SuiteおよびBusiness Process Managementのインストールと構成

- Oracle Fusion Middleware Oracle SOA SuiteおよびBusiness Process Managementのアップグレード

- Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド

10.1 高可用性のためのOracle BAMの構成

この項では、Oracle Business Activity Monitoring (Oracle BAM)の高可用性の構成を完了する方法を説明します。Oracle BAMでは、JMSシステム・リソースを構成するためにローカル・キューが使用されるため、高可用性を実現するには追加の手順を実行する必要があります。

注意:

この項のOracle BAM用の手順を開始する前に、第7.7項「マシンのスケール・アップまたはスケール・アウト後のWLS JMSの構成」に記載されているすべての手順を完了する必要があります。

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

- 第10.1.1項「スケール・アップ後のOracle BAM管理対象サーバーのJMSシステム・リソースの構成」

- 第10.1.2項「Oracle BAMの自動サービス移行の構成」

10.1.1 スケール・アップ後のOracle BAM管理対象サーバーのJMSシステム・リソースの構成

Oracle BAMでは第7.7項「マシンのスケール・アップまたはスケール・アウト後のWLS JMSの構成」に示されている標準的な構成手順に加えて、手動のJMS構成手順が必要です。

Oracle BAMでJMSシステム・リソースを構成する際は、次の点に注意してください。

- この項の手順では、新しく追加する管理対象サーバーを表す名前として、bam_server2を使用します。bam_server2を、実際の構成で使用する管理対象サーバー名で置き換えてください。

- BAM JMSシステム・リソースのターゲット指定には細心の注意を払い、特に、リソースが管理対象サーバーbam_server2にターゲット指定されるか、移行可能なターゲットbam_server2 (移行可能)にターゲット指定されるかには注意してください。

- この項の手順で指定されないJMSシステム・リソース・プロパティについては、デフォルト値を使用してください。

このトピックには、次の項があります。

- 第10.1.1.1項「Oracle BAMサーバーのJMSサーバーの構成」

- 第10.1.1.2項「Oracle BAM CQServiceのJMSサーバーの構成」

10.1.1.1 Oracle BAMサーバーのJMSサーバーの構成

この項では、Oracle BAMサーバーのJMSサーバーのJMSシステム・リソースを、新しい管理対象サーバーに手動で構成する手順を説明します。

Oracle BAMサーバーのJMSサーバー・リソースを、新しい管理対象サーバーに構成するには、次の手順を実行します。

1. 管理対象サーバーbam_server2にターゲット指定するディレクトリBamServerJmsFileStore_bam_server2を使用して、JMS永続ストアBamServerJmsFileStore_bam_server2を作成します。

2. bam_server2にターゲット指定する永続ストアBamServerJmsFileStore_bam_server2を使用して、JMSサーバーBamServerJmsServer_bam_server2を作成します。

3. 「JMSモジュール」を選択し、表からBamServerJmsSystemResourceを選択します。

4. 「サブデプロイメント」タブを選択します。サブデプロイメントBamServerSubdeploymentをクリックし、「JMSサーバー」セクションでBamServerJmsServer_bam_server2を選択します。

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

10.1.1.2 Oracle BAM CQServiceのJMSサーバーの構成

Oracle BAM CQServiceのJMSサーバーを、新しい管理対象サーバーに手動で構成するには、次の手順を実行します。

1. bam_server2にターゲット指定するディレクトリBamCQServiceJmsFileStore_bam_server2を使用して、JMS永続ストアBamCQServiceJmsFileStore_bam_server2を作成します。

2. bam_server2にターゲット指定する永続ストアBamCQServiceJmsFileStore_bam_server2を使用して、JMSサーバーBamCQServiceJmsServer_bam_server2を作成します。

3. JMSシステム・モジュールBamCQServiceJmsSystemResource_bam_server2を作成し、「クラスタのすべてのサーバー」にターゲット指定します。「このJMSシステム・モジュールにリソースを追加しますか。」を選択し、JMSシステム・モジュールにリソースを追加します。

注意:

次の手順で、

- このJMSシステム・モジュールで作成するJMS接続ファクトリおよびキューでは、「ローカルJNDI名」(ローカル名)のみ指定されます(「JNDI名」(グローバル名)フィールドは空白のままにします)。

- キューへのすべての参照は、キューのみに対する参照であり、分散キューに対する参照ではありません。

次の手順で、このJMSシステム・モジュールにリソースを追加します。

4. BAM JMSサーバーBamCQServiceJmsServer_bam_server2にターゲット指定するサブデプロイメントBamCQServiceReportCacheSubdeployment_bam_server2を作成します。

5. BAM JMSサーバーBamCQServiceJmsServer_bam_server2にターゲット指定するサブデプロイメントBamCQServiceAlertEngineSubdeployment_bam_server2を作成します。

6. JMS接続ファクトリBamCQServiceReportCacheConnectionFactoryを作成します。「JNDI名」フィールドは空白のままにします。

1. 「サブスクリプション共有ポリシー」を「排他」に設定します。

2. 「クライアントIDポリシー」を「制限なし」に設定します。

3. 「XA接続ファクトリの有効化」を選択します。

4. 接続ファクトリを、サブデプロイメントBamCQServiceReportCacheSubdeployment_bam_server2にターゲット指定します。これを行うには、「新しいJMSシステム・モジュール・リソースの作成」画面で「高度なターゲット指定」を選択します。プルダウン・リストから、「サブデプロイメント」を選択します。

5. 接続ファクトリが作成された後、それをクリックします。「一般」タブで、「詳細」セクションを開きます。「ローカルJNDI名」フィールドにqueue/oracle.beam.cqservice.mdbs.reportcacheと入力します。

7. JMSキューBamCQServiceReportCacheQueueを作成します。「JNDI名」フィールドは空白のままにします。

1. サブデプロイメントをBamCQServiceReportCacheSubdeployment_bam_server2に設定します。

2. キューが作成された後、それをクリックします。「一般」タブで、「詳細」セクションを開きます。「ローカルJNDI名」フィールドにqueue/oracle.beam.cqservice.mdbs.reportcacheと入力します。

8. JMS接続ファクトリBamCQServiceAlertEngineConnectionFactoryを作成します。「JNDI名」フィールドは空白のままにします。

1. 「サブスクリプション共有ポリシー」を「排他」に設定します。

2. 「クライアントIDポリシー」を「制限なし」に設定します。

3. 「XA接続ファクトリの有効化」を選択します。

4. 接続ファクトリを、サブデプロイメントBamCQService AlertEngineSubdeployment_bam_server2にターゲット指定します。これを行うには、「新しいJMSシステム・モジュール・リソースの作成」画面で「高度なターゲット指定」を選択し、プルダウン・メニューからそのサブデプロイメントを選択します。

5. 接続ファクトリが作成された後、それをクリックします。「一般」タブで、「詳細」セクションを開きます。「ローカルJNDI名」フィールドにqueuecf/oracle.beam.cqservice.mdbs.alertengineと入力します。

9. JMSキューBamCQServiceAlertEngineQueueを作成します。「JNDI名」フィールドは空白のままにし、サブデプロイメントはBamCQServiceAlertEngineSubdeployment_bam_server2に設定されたままにします。

1. キューが作成された後、それをクリックして「一般」タブに移動します。

2. 「詳細」セクションを開いて、JNDIローカル名フィールドにqueue/oracle.beam.cqservice.mdbs.alertengineと入力します。

10. 「保存」をクリックした後、「すべての変更をアクティブ化」をクリックします。

10.1.2 Oracle BAMの自動サービス移行の構成

Oracle BAM管理対象サーバーでは、サーバーごとのJMSサービスが使用されます。これらのサーバーごとのキューは、クラスタではなく特定の管理対象サーバーに固定されるため、固定サービスとも呼ばれます。これらのサーバー固有のキューの高可用性を実現し、別の管理対象サーバーへのフェイルオーバーを可能にするには、サーバーに自動サービス移行を構成する必要があります。

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

データ・ソースおよびリース構成はOracle BAMサーバーの構成中に作成されますが、特定のOracle BAMサービスの自動移行は、次の手順に従って手動で有効化する必要があります。

タスク1   Oracle WebLogic Server管理コンソールへのログイン

例:

ADMVHN:7001/console

タスク2   サービス移行を構成する管理対象サーバーの選択

1. 「ドメイン構造」ペインで、「環境」ノードを開いて「サーバー」ノードをクリックします。
「サーバーのサマリー」ページが表示されます。

2. 表の「名前」列で、サーバーWLS_BAM1の名前(ハイパーリンクとして表示)をクリックします。
選択したサーバーの設定ページが開き、「構成」タブがデフォルトで表示されます。

3. 「移行」タブをクリックします。

4. 「ロックと編集」をクリックして、変更を開始します。

5. ページの「JMSサービス移行の構成」セクションで、「使用可能」リスト・ボックスから管理対象サーバーWLS_BAM1およびWLS_BAM2を選択し、「移動」ボタンをクリックして、それらを「選択済み」リスト・ボックスに移動します。

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

タスク3   各管理対象サーバーへのサービス移行ポリシーの設定

1. 「ドメイン構造」ペインで、「環境」、「クラスタ」、「移行可能なターゲット」の順に選択します。

2. WLS_BAM1 (移行可能)をクリックします。

3. 「移行」タブをクリックします。

4. 「サービス移行ポリシー」ドロップダウン・リストで、「必ず1回のサービスを自動移行」を選択します。

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

6. WLS_BAM2管理対象サーバーについて手順3から5を繰り返します。

タスク4   UMS JMSサーバーおよび永続ストアの移行不可能なターゲットへの手動でのターゲット指定

Oracle User Messaging Service (UMS) 12c (12.1.3.0.0)では、サービスの移行がサポートされていません。したがって、UMS JMSサーバーおよび永続ストアを、移行不可能なターゲットにターゲット指定しなおす必要があり、そうしなければ、Oracle BAMのサービス移行は失敗します。

UMSサービスを移行不可能なターゲットにターゲット指定するには、次の手順を実行します。

1. 「ドメイン構造」ペインで、「環境」、「サービス」の順に開き、「永続ストア」をクリックします。
コンソールに永続ストアのリストが表示されます。リストには、UMSJMSFileStore_auto_という名前のUMS永続ストア名に数字を付加したものが、各管理対象サーバーに対して1つずつ表示されます。

2. WLS_BAM1 (移行可能)にターゲット指定されている1つ目のUMSファイル・ストアをクリックします。

3. 選択した永続ストアの「設定」ページで、「ターゲット」ドロップダウン・メニューで選択されている値をWLS_BAM1 (移行可能)からWLS_BAM1に変更します。

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

エラーが発生し、JMSサーバーは永続ストアと同じターゲットに指定されませんと表示される場合、このエラーは無視して構いません。

5. WLS_BAM1 (移行可能)にターゲット指定されている残りのUMSファイル・ストア・エントリに対し、手順2から4を繰り返します。

6. 「ドメイン構造」ウィンドウで、「環境」、「サービス」、「メッセージング」の順に開き、「JMSサーバー」をクリックします。
コンソールにJMSサーバーのリストが表示されます。リストには、UMSJMSServer_auto_という名前のUMS永続ストア名に数字を付加したものが、各管理対象サーバーに対して1つずつ表示されます。

7. 現在WLS_BAM1 (移行可能)にターゲット指定されている1つ目のJMSファイル・ストアをクリックします。

8. 選択したJMSサーバーの「設定」ページで、「ターゲット」タブをクリックします。

9. 「ターゲット」ドロップダウン・メニューの値をWLS_BAM1 (移行可能)からWLS_BAM1に変更します。

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

11. WLS_BAM1 (移行可能)にターゲット指定されている残りのUMS JMSサーバーに対し、手順7から10を繰り返します。

12. 「変更のアクティブ化」をクリックします。

注意:

自動サービス移行が発生し、指定されたOracle BAMサービスが別の管理対象サーバーに自動的に移行された場合は、元の管理対象サーバーがオンラインに復帰し再びクラスタに参加した後も、それらのサービスはフェイルオーバー・サーバーにターゲット指定されたままです。

手動で、それらのサービスを元のサーバーにフェイルバックすることをお薦めします。詳細は、『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』の自動サービス移行後のOracle BAMサービスのフェイルバックに関する項を参照してください。

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

この章では、その他のコンポーネント製品に固有の情報について説明します。

このリリースでの、この章の内容は次のとおりです。

- 第11.1項「Oracle Data Integratorのデプロイ」

- 第11.2項「Oracle Application Development Frameworkのデプロイ」

11.1 Oracle Data Integratorのデプロイ

このトピックでは、Oracle Real Application ClustersへのOracle Data Integratorリポジトリ接続を構成する際の考慮事項について説明します。

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

- 第11.1.2項「Oracle RACへのリポジトリ接続の構成」

- 第11.1.3項「スケジューラ・ノードの障害」

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へのリポジトリ接続の構成

リポジトリ作成ユーティリティ(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の形式で入力します。例11-1を参照してください。

- Oracle RACをSCANで構成している場合、Oracle RACインスタンスの詳細にSCANアドレスを提供します。

例11-1に、SCANを使用しない場合に、2つのホストを持つOracle RACに接続するためのJDBC URL書式を示します。

例11-1 JDBC URLの書式(Oracle RACがSCANで構成されていない場合)

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 スケジューラ・ノードの障害

WebLogic Serverのフェイルオーバーが発生した場合は、他のWebLogic Serverインスタンスがスケジューラになります。Coherenceキャッシュによって、スケジューラ・ライフサイクルが処理されます。ロックにより、スケジューラの一意性が保証され、イベント通知はスケジューラの移行を知らせます。エージェントが再起動され、そのスケジュールが計算された場合は、進行中のスケジュールが考慮され、それらの実行サイクルは、サーバーの起動時間を過ぎても自動的に継続されます。新しいセッションは、スケジューラが停止しなかったかのようにトリガーされます。失効セッションは、エラー状態に移動され、再起動時にはその状態が保持されます。

Oracle Data Integratorエージェント・クラスタで、スケジューラ・ノードであるエージェント・ノードに障害が発生すると、クラスタ内の別のノードがスケジューラ・ノードとしての役割を引き継ぎます。新しいスケジューラ・ノードにより、すべてのスケジュールが再初期化され、その時点から実行されます。

ノードがクラッシュした際に反復可能な実行サイクルを持つスケジュール済シナリオが実行中の場合、スケジューラ・ノードがクラッシュした時点以降、そのシナリオは新しいスケジューラ・ノードでは反復が続行されません。たとえば、スケジュール済シナリオが2分間隔で10回実行を繰り返すように構成されている場合、3回目の実行中にスケジューラ・ノードで障害が発生すると、新しいスケジューラ・ノードでは、シナリオの残りの8回は実行されません。

11.2 Oracle Application Development Frameworkのデプロイ

この項では、Oracle Application Development Framework (ADF)に固有の情報を説明します。

この項では、次の項目について説明します。

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

- 第11.2.2項「mdsDSデータ・ソースのURLの変更」

関連項目:

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.2.2 mdsDSデータ・ソースのURLの変更

顧客が用意したADFアプリケーションでGridLinkデータ・ソースまたはマルチ・データ・ソースを使用する場合は、管理サーバーの起動後に、WebLogic Server管理コンソールでmdsDSデータ・ソースのURLを変更する必要があります。

mdsDSデータ・ソースのURLを変更するには、次の手順を実行します。

1. WebLogic Server管理コンソールにログインします。「サービス」→「データ・ソース」を選択します。

2. 「mdsDS」→「接続プール」を選択します。

3. JDBCのURLを指定するように次の形式で変更します。

jdbc:oracle:thin:@hostname:port/service-name

たとえば、次のようなJDBCのURLを想定します。

jdbc:oracle:thin:@(DESCRIPTION=(ENABLE=BROKEN)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=slc00erterw-r.us.example.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=srv2_koala.us.example.com)))

このURLを次のように置き換えます。

jdbc:oracle:thin:@slc00erterw-r.us.example.com:1521/srv2_koala.us.example.com

4. 変更を保存して、管理サーバーを含むすべてのサーバーを再起動します。

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2015, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

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の登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

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

保証免責

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

制限付権利

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

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）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

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

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。