Oracle® Fusion Middleware

Oracle WebLogic Serverクラスタの管理

12c (12.2.1.1.0)

E77389-02(原本部品番号:E69781-03)

2016年8月

このドキュメントでは、クラスタについての説明、およびWebLogic Serverクラスタを含む本番環境のプランニング、実装、およびサポートに関連する情報が提供されています。

Oracle Fusion Middleware Oracle WebLogic Serverクラスタの管理, 12c (12.2.1.1.0)

E77389-02

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

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

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

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

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

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

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

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

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

目次

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

はじめに

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

- 表記規則

1 概要とロードマップ

- ドキュメントのスコープと対象読者

- このドキュメントの手引き

- 関連ドキュメント

- このリリースでのクラスタリングの新機能と変更点

2 WebLogic Serverのクラスタリングの理解

- WebLogic Serverクラスタとは

- 動的クラスタとは

- クラスタとドメインの関係

- クラスタリングの利点とは

- クラスタの重要な機能とは

- クラスタリング可能なオブジェクトの種類

- サーブレットとJSP

- EJBとRMIオブジェクト

- JMSとクラスタリング

- クラスタリングできないオブジェクトの種類

3 クラスタでの通信

- WebLogic Serverのクラスタ・メッセージング・プロトコルの選択

- IPマルチキャストの使用

- マルチキャストとクラスタの構成

- クラスタがWAN内の複数のサブネットにまたがる場合

- ファイアウォールがマルチキャスト通信を遮断することがある

- クラスタのマルチキャスト・アドレスを他のアプリケーションと共有しない

- マルチキャスト・ストームが起こったら

- ユニキャストを使用した1対多通信

- WebLogic Serverユニキャスト・グループ

- グループへのサーバー・インスタンスの割当て

- ユニキャストの構成

- ユニキャストを使用する場合の考慮事項

- ユニキャストかマルチキャストかを選択する際の考慮事項

- IPソケットを使用したピア・ツー・ピア通信

- pure-Javaとネイティブ・ソケット・リーダーの実装の比較

- Javaソケット実装用にリーダー・スレッドを構成する

- ソケットの使用数を確定する

- ソケット経由のクライアント通信

- クラスタ全体のJNDIネーミング・サービス

- WebLogic Serverによるクラスタ全体のJNDIツリー作成の仕組み

- JNDI名の競合が発生する仕組み

- 均一なデプロイメントによってクラスタ・レベルのJNDIの競合を回避する

- WebLogic ServerによるJNDIツリー更新の仕組み

- クライアントとクラスタ全体のJNDIツリーとの対話

4 クラスタの構成の理解

- クラスタの構成とconfig.xml

- 管理サーバーの役割

- 管理サーバーに障害が発生した場合

- 動的構成の仕組み

- クラスタ化構成でのアプリケーションのデプロイメント

- デプロイメント方法

- 2フェーズ・デプロイメントの概要

- デプロイメントの第1フェーズ

- デプロイメントの第2フェーズ

- クラスタへのデプロイメントのガイドライン

- WebLogic Serverがサポートする「緩和されたデプロイメント」ルール

- 部分的なクラスタへのデプロイメントの許可

- WebLogic Serverの完全なクラスタへのデプロイメント

- 固定サービスを複数の管理対象サーバーにデプロイ可能

- クラスタを構成する方法

5 クラスタでのロード・バランシング

- サーブレットとJSPのロード・バランシング

- プロキシ・プラグインによるロード・バランシング

- プロキシ・プラグインによるセッションの接続とフェイルオーバーの仕組み

- 外部ロード・バランサによるHTTPセッションのロード・バランシング

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

- ロード・バランサとWebLogicセッションCookie

- 関連するプログラミングの考慮事項

- ロード・バランサでのセッション接続およびフェイルオーバーの仕組み

- EJBとRMIオブジェクトのロード・バランシング

- ラウンドロビン・ロード・バランシング

- 重みベースのロード・バランシング

- ランダム・ロード・バランシング

- サーバー・アフィニティ・ロード・バランシング・アルゴリズム

- サーバー・アフィニティと初期コンテキスト

- サーバー・アフィニティとCSIv2を使用したIIOPクライアント認証

- ラウンドロビン・アフィニティ、重みベース・アフィニティ、およびランダム・アフィニティ

- サーバー・アフィニティの例

- クラスタ化オブジェクトのパラメータ・ベースのルーティング

- 連結されたオブジェクトの最適化

- トランザクションの連結

- XAトランザクション・クラスタ・アフィニティ

- JMSのロード・バランシング

- 分散JMS宛先のサーバー・アフィニティ

- クライアント接続の初期コンテキスト・アフィニティとサーバー・アフィニティ

6 クラスタのフェイルオーバーとレプリケーション

- WebLogic Serverで障害を検出する仕組み

- IPソケットを使用した障害検出

- WebLogic Serverの「ハートビート」

- サーブレットとJSPのレプリケーションとフェイルオーバー

- HTTPセッション状態のレプリケーション

- HTTPセッション状態のレプリケーションに関する要件

- サポート対象のサーバー・ソフトウェアとプロキシ・ソフトウェア

- ロード・バランサの要件

- クラスタ化されるサーブレットおよびJSPのプログラミング上の考慮事項

- レプリケーション・グループの使用

- クラスタ化サーブレットとJSPへのプロキシ経由のアクセス

- プロキシ接続の手順

- URL書換えを利用したセッション・レプリカの追跡

- プロキシ・フェイルオーバーのプロセス

- クラスタ化サーブレットとJSPへのロード・バランシング・ハードウェアを利用したアクセス

- ロード・バランシング・ハードウェアを利用した接続

- ロード・バランシング・ハードウェアを利用したフェイルオーバー

- MAN/WAN内のクラスタ間でのセッション状態レプリケーション

- クラスタ間レプリケーションのネットワーク要件

- グローバル・ロード・バランサ

- ローカル・ロード・バランサ

- レプリケーション

- フェイルオーバー

- クラスタ間レプリケーションの構成要件

- クラスタ間でのセッション状態レプリケーションの構成

- レプリケーション・チャネルの構成

- MANでのHTTPセッション状態のレプリケーション

- MAN内でのレプリケーション

- MANにおけるフェイルオーバーのシナリオ

- MANでのレプリケーション、ロード・バランサ、セッションの固定

- WANでのHTTPセッション状態のレプリケーション

- WAN内でのレプリケーション

- WANにおけるフェイルオーバーのシナリオ

- WANでのセッション状態レプリケーション用のデータベースの構成

- EJBとRMIのレプリケーションとフェイルオーバー

- レプリカ対応スタブによるオブジェクトのクラスタリング

- 各種のEJBでのクラスタリング・サポート

- クラスタ化EJBHomes

- クラスタ化されたEJBObject

- ステートレス・セッションBean

- ステートフル・セッションBean

- ステートフル・セッションEJBのフェイルオーバー

- エンティティEJB

- エンティティBeanとEJBハンドルのフェイルオーバー

- RMIオブジェクトのクラスタリング・サポート

- オブジェクト・デプロイメントの必要条件

- 他のフェイルオーバーの例外

7 サーバー全体の移行

- サーバーおよびサービスの移行の理解

- 移行関連の用語

- リース

- リースを使用する機能

- リースの種類

- 使用するリースの種類の決定

- 高可用性データベース・リース

- RACクラスタ上でのデータベース・リースによるサーバーの移行

- コンセンサス(非データベース)リース

- サーバー全体の自動移行

- サーバー全体の自動移行の準備

- サーバー全体の自動移行の構成

- 状態データ用高可用性ストレージの使用

- サーバーの移行プロセスと通信

- 移行可能サーバーのあるクラスタの起動プロセス

- サーバー全体の自動移行のプロセス

- サーバー全体の手動移行のプロセス

- サーバー全体の移行における管理サーバーの役割

- クラスタでの移行可能サーバーの動作

- サーバー全体の移行におけるノード・マネージャの役割

- サーバー全体の移行におけるクラスタ・マスターの役割

- 動的クラスタおよび複合クラスタでのサーバー全体の移行

- 動的クラスタでのサーバー全体の移行の構成

- 複合クラスタでのサーバー全体の移行の構成

8 サービスの移行

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

- 移行可能サービス

- JMS関連サービス

- JTAトランザクション・リカバリ・サービス

- ユーザー定義のシングルトン・サービス

- クラスタ内の移行可能ターゲットの理解

- 手動および自動のサービス移行ポリシー

- 手動移行

- Exactly-Once

- Failure-Recovery

- 障害が発生したサービスを移行前に再起動するオプション

- 優先サーバーと候補サーバー

- クラスタ内の移行可能ターゲットの例

- JMSサーバーのターゲット指定ルール

- SAFエージェントのターゲット指定ルール

- SAFエージェントの移行可能ターゲットのターゲット指定の変更

- メッセージ・スループットを向上させるための移行可能SAFエージェントのターゲット指定方法

- サービス品質を安定させるためのSAFエージェントのターゲット指定方法

- パス・サービスのターゲット指定ルール

- パス・サービスをターゲット指定する場合の特別な考慮事項

- カスタム・ストアのターゲット指定ルール

- JTAトランザクション・リカバリ・サービス用の移行可能ターゲット

- 移行処理ツール

- 管理コンソール

- WebLogic Scripting Tool

- サービス自動移行インフラストラクチャ

- 移行可能サービスのリース

- データベース・リース

- コンセンサス・リース

- ノード・マネージャ

- サービスの移行時に管理サーバーは不要

- サービスのヘルス・モニタリング

- JTAトランザクション・リカバリ・サービスのヘルス・モニタリングが自動移行をトリガーする仕組み

- JMS関連サービスのヘルス・モニタリングが自動移行をトリガーする仕組み

- 障害が発生した移行可能サービスのインプレースでの再起動

- 使用不能サーバーからのサービスの移行

- JMSとJTAのサービスの自動移行の相互作用

- 移行前の要件

- JMSサービスで使用できるカスタム・ストア

- JTAで使用できるデフォルト・ファイル・ストア

- サーバーの状態とサービスの手動移行

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

- ステップ1: 管理対象サーバーとノード・マネージャを構成する

- ステップ2: 移行リース基盤を構成する

- ステップ3: 移行可能ターゲットを構成する

- 移行可能サーバーを自動的な移行可能ターゲットとして構成する

- 新しい移行可能ターゲットを作成する

- ユーザー優先サーバーを選択する

- サービス移行ポリシーを選択する

- 制約付き候補サーバーを選択する(オプション)

- 移行前/移行後スクリプトを指定する(オプション)

- インプレースでの再起動オプションを指定する(オプション)

- ステップ4: カスタム・ストアを構成およびターゲット指定する

- ステップ5: JMSサービスをターゲット指定する

- SAFエージェントまたはパス・サービスをターゲット指定する場合の特別な考慮事項

- ステップ6: 変更した移行ポリシーで管理サーバーと管理対象サーバーを再起動する

- ステップ7: JMSサービスを元のサーバーに手動で戻す

- サービスの自動移行の構成でJMSをターゲット指定する際のベスト・プラクティス

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

- ステップ1: 管理対象サーバーを構成する

- ステップ2: 移行可能ターゲットを構成する

- 移行可能サーバーを移行可能ターゲットとして構成する

- 新しい移行可能ターゲットを作成する

- 優先サーバーを選択する

- デフォルトのサービスの手動移行ポリシーを受け入れる

- 制約付き候補サーバーを選択する(オプション)

- 移行前/移行後スクリプトを指定する(オプション)

- インプレースでの再起動オプションを指定する(オプション)

- ステップ3: カスタム・ストアを構成およびターゲット指定する

- ステップ4: JMSサービスをターゲット指定する

- SAFエージェントまたはパス・サービスをターゲット指定する場合の特別な考慮事項

- ステップ5: 変更した移行ポリシーで管理サーバーと管理対象サーバーを再起動する

- ステップ6: JMSサービスを手動で移行する

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

- ステップ1: 管理対象サーバーとノード・マネージャを構成する

- ステップ2: 移行基盤を構成する

- ステップ3: JTAの自動移行を有効にする

- 自動JTA移行ポリシーの選択

- 候補サーバーを選択する(オプション)

- 移行前/移行後スクリプトを指定する(オプション)

- ステップ4: トランザクション・リカバリ・サービスの移行用にデフォルト永続ストアを構成する

- ステップ5: 変更した移行ポリシーで管理サーバーと管理対象サーバーを再起動する

- ステップ6: トランザクション・リカバリ・サービスを自動フェイルバックによって元のサーバーに戻す

- JTAトランザクション・リカバリ・サービスの手動移行

- ユーザー定義のシングルトン・サービスの自動移行

- シングルトン・サービスの移行の概要

- シングルトン・マスター

- 移行の失敗

- シングルトン・サービス・インタフェースの実装

- シングルトン・サービスのデプロイと移行動作の構成

- アプリケーション内にシングルトン・サービスをパッケージ化してデプロイする

- シングルトン・サービスをWebLogic Serverにスタンドアロン・サービスとしてデプロイする

- シングルトン・サービスの移行を構成する

9 クラスタ・アーキテクチャ

- アーキテクチャとクラスタ関連の用語

- アーキテクチャ

- Webアプリケーションの層

- 組合せ層アーキテクチャ

- 非武装地帯(DMZ)

- ロード・バランサ

- プロキシ・プラグイン

- 推奨基本アーキテクチャ

- 組合せ層アーキテクチャを使用しない状況

- 推奨複数層アーキテクチャ

- ハードウェアとソフトウェアの物理レイヤー

- Web/プレゼンテーション・レイヤー

- オブジェクト・レイヤー

- 複数層アーキテクチャの利点

- 複数層アーキテクチャでのクラスタ化オブジェクトのロード・バランシング

- 複数層アーキテクチャの構成に関する考慮事項

- IPソケットの使用数

- ハードウェア・ロード・バランサ

- 複数層アーキテクチャに関する制限

- 連結の最適化が行われない

- ファイアウォールに関する制限

- 推奨プロキシ・アーキテクチャ

- 2層プロキシ・アーキテクチャ

- ハードウェアとソフトウェアの物理レイヤー

- Webレイヤー

- サーブレット/オブジェクト・レイヤー

- 複数層プロキシ・アーキテクチャ

- プロキシ・アーキテクチャの利点

- プロキシ・アーキテクチャの制限

- プロキシ・プラグインとロード・バランサ

- クラスタ・アーキテクチャのセキュリティ・オプション

- プロキシ・アーキテクチャの基本ファイアウォール

- プロキシ・レイヤーとクラスタの間のファイアウォール

- 基本ファイアウォール構成のDMZ

- ファイアウォールとロード・バランサの組み合わせ

- 内部クライアントに対するファイアウォールの拡張

- 共有データベースに対するセキュリティの追加

- ファイアウォールが2つある構成のDMZ

10 WebLogicクラスタの設定

- 開始する前に

- 構成プロセスについて

- クラスタ・アーキテクチャを決定する

- ネットワーク・トポロジとセキュリティ・トポロジを検討する

- クラスタをインストールするマシンを選択する

- マルチCPUマシン上のWebLogic Serverインスタンス

- ホスト・マシンのソケット・リーダー実装をチェックする

- 切断されたWindowsマシン上のクラスタの設定

- 名前とアドレスを識別する

- リスニング・アドレスの問題を回避する

- DNS名とIPアドレス

- 内部DNS名と外部DNS名が異なる場合

- localhostの考慮事項

- WebLogic Serverリソースへの名前割当て

- 管理サーバーのアドレスとポート

- 管理対象サーバーのアドレスとリスニング・ポート

- クラスタのマルチキャスト・アドレスとマルチキャスト・ポート

- マルチキャストと複数のクラスタ

- マルチキャストと複数層クラスタ

- クラスタ・アドレス

- 動的なクラスタ・アドレス

- 本番環境でクラスタ・アドレスを明示的に定義する

- 開発およびテスト環境でクラスタ・アドレスを明示的に定義する

- 単一のマルチホーム・マシンでクラスタ・アドレスを明示的に定義する

- クラスタ実装の手順

- 構成のロードマップ

- WebLogic Serverをインストールする

- クラスタ化ドメインを作成する

- WebLogic Serverクラスタを起動する

- ノード・マネージャを構成する

- EJBとRMIのロード・バランシング方式を構成する

- RMIのタイムアウト値を指定する

- 分散JMS宛先のサーバー・アフィニティを構成する

- パッシブなCookieの永続性をサポートするロード・バランサを構成する

- プロキシ・プラグインを構成する

- HttpClusterServletを設定する

- web.xmlのサンプル

- weblogic.xmlのサンプル

- プロキシ・サーブレットのデプロイメント・パラメータ

- プロキシ・サーバー経由のアプリケーションへのアクセス

- レプリケーション・グループを構成する

- 固定サービスの移行可能ターゲットを構成する

- デプロイメント用にアプリケーションをパッケージ化する

- アプリケーションをデプロイする

- 1つのサーバー・インスタンスにデプロイする(固定デプロイメント)

- コマンド行からの固定デプロイメント

- クラスタのデプロイメントを取り消す

- コマンド行からデプロイメントを取り消す

- WebLogic Server管理コンソールを使用したデプロイメントの取消し

- デプロイ済アプリケーションを表示する

- デプロイ済アプリケーションをアンデプロイする

- 移行可能サービスをデプロイ、アクティブ化、および移行する

- 移行可能ターゲット・サーバー・インスタンスにJMSをデプロイする

- 移行可能サービスとしてJTAをアクティブ化する

- ターゲット・サーバー・インスタンスに固定サービスを移行する

- 現在アクティブなホストがない場合の移行

- インメモリーHTTPレプリケーションを構成する

- 構成に関するその他のトピック

- IPソケットを構成する

- サーバー・インスタンスのホスト・マシン上でネイティブのIPソケット・リーダーを構成する

- サーバー・インスタンスのホスト・マシン上のリーダー・スレッドの数を設定する

- クライアント・マシン上のリーダー・スレッド数を設定する

- マルチキャスト存続時間(TTL)を構成する

- マルチキャスト・バッファのサイズを構成する

- マルチキャスト・データの暗号化を構成する

- マシン名を構成する

- 複数層アーキテクチャの構成に関する注意

- URL書換えを有効にする

11 動的クラスタ

- 動的クラスタとは

- 動的クラスタを使用する理由

- 動的クラスタの仕組み

- 動的クラスタの作成と構成

- サーバー・テンプレートの使用

- サーバー固有の属性の計算

- サーバー名の計算

- リスニング・ポートの計算

- マシン名の計算

- 動的クラスタ内のサーバーの起動と停止

- 動的クラスタの拡張と縮小

- 動的クラスタでのサーバー全体の移行の使用

- 動的クラスタへのアプリケーションのデプロイ

- 動的クラスタでのWebLogic Webサーバー・プラグインの使用

- 動的クラスタを使用する際の制限事項と考慮事項

- 動的クラスタの例

12 Coherenceクラスタの構成と管理

- Coherenceクラスタの概要

- Coherenceクラスタの設定

- Coherenceクラスタ・リソースの定義

- スタンドアロンの管理対象Coherenceサーバーの作成

- Coherenceデプロイメント層の作成

- Coherenceデータ層の構成と管理

- Coherenceデータ層の作成

- データ層の管理対象Coherenceサーバーの作成

- Coherenceアプリケーション層の構成と管理

- Coherenceアプリケーション層の作成

- アプリケーション層の管理対象Coherenceサーバーの作成

- Coherenceプロキシ層の構成と管理

- Coherenceプロキシ層の作成

- プロキシ層の管理対象Coherenceサーバーの作成

- Coherenceプロキシ・サービスの構成

- ネーム・サービスの使用

- Coherenceクラスタの構成

- Coherenceクラスタ・メンバーの追加と削除

- クラスタ構成の詳細オプションの設定

- クラスタ通信の構成

- Coherenceクラスタ・モードの変更

- Coherenceクラスタ・トランスポート・プロトコルの変更

- キャッシュ構成ファイルのオーバーライド

- Coherenceロギングの構成

- キャッシュ永続性の構成

- キャッシュ・フェデレーションの構成

- 管理対象Coherenceサーバーの構成

- Coherenceクラスタ・メンバーのストレージ設定の構成

- Coherenceクラスタ・メンバーのユニキャスト設定の構成

- Coherence管理プロキシの削除

- Coherenceクラスタ・メンバーのID設定の構成

- Coherenceクラスタ・メンバーのロギング・レベルの構成

- 単一サーバー・クラスタの使用

- CoherenceでのWLSTの使用

- WLSTによるCoherenceキャッシュの保持

13 クラスタリングのベスト・プラクティス

- 一般的な設計上の考慮事項

- シンプルにする

- リモート呼出しを最小限にする

- セッションFacadeでリモート呼出しが削減される

- 転送オブジェクトでリモート呼出しが削減される

- 分散トランザクションでリモート呼出しが増加する

- Webアプリケーション設計の考慮事項

- インメモリー・レプリケーションを構成する

- 多重呼出し不変性に留意して設計する

- プログラミングの考慮事項

- EJB設計の考慮事項

- 多重呼出し不変のメソッドを設計する

- 使用方法および構成のガイドラインに従う

- クラスタ関連の構成オプション

- クラスタでの状態管理

- アプリケーション・デプロイメントの考慮事項

- アーキテクチャに関する考慮事項

- 問題の回避

- 命名の考慮事項

- 管理サーバーについての考慮事項

- ファイアウォールについての考慮事項

- 本番環境で使用する前にクラスタのキャパシティを評価する

14 一般的な問題のトラブルシューティング

- クラスタを起動する前に

- サーバーのバージョン番号のチェック

- マルチキャスト・アドレスのチェック

- CLASSPATHの値のチェック

- クラスタ起動後の作業

- コマンドのチェック

- ログ・ファイルの生成

- Oracle HotSpot VMスレッド・ダンプの取得

- ガベージ・コレクションのチェック

- utils.MulticastTestの実行

15 マルチキャスト構成のトラブルシューティング

- マルチキャスト・アドレスおよびポートの構成の検証

- 発生する問題

- マルチキャスト・アドレスおよびポートの確認

- ネットワーク構成の問題の特定

- 物理的な接続

- アドレスの競合

- UNIXシステムのnsswitch.confの設定

- MulticastTestユーティリティの使用

- マルチキャスト機能のチューニング

- マルチキャスト・タイムアウト

- クラスタ・ハートビート

- マルチキャスト送信遅延

- オペレーティング・システム・パラメータ

- マルチキャスト・ストーム

- マルチキャストとマルチホーム・マシン

- 別々のサブネットでのマルチキャスト

- マルチキャストのデバッグ

- デバッグ・ユーティリティ

- MulticastMonitor

- MulticastTest

- デバッグ・フラグ

- コマンド・ラインでデバッグ・フラグを設定する

- WLSTを使用したデバッグ属性の設定

- その他の問題

- AIXでのマルチキャスト

- ファイル記述子の問題

- マルチキャスト構成のトラブルシューティングに関するその他のリソース

A WebLogicクラスタのAPI

- APIの使用方法

- カスタム呼出しルーティングと連結の最適化

B クラスタに関するBIG-IPハードウェアの構成

C MAN/WANフェイルオーバーに関するF5ロード・バランサの構成

- 要件

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

- 仮想サーバーのIPおよびプール

- フェイルオーバー・トリガーの仮想サーバーおよびプールの作成

- マルチレイヤーの仮想サーバーおよびIPプールの作成

- 3-DNSグローバル・ハードウェア・ロード・バランサの構成

- DNSゾーンの構成

- 3-DNSによって管理されるBIG-IPアドレスの構成

- データ・センターの構成

- ワイドIPの構成

- WebLogic Serverコンポーネントの構成

D MAN/WANフェイルオーバーに関するRadwareロード・バランサの構成

- 要件

- ステップ1: 信頼できる委任ゾーンの構成

- ステップ2: ファームの仮想IPおよびサーバーの構成

- ファームIPの作成

- サーバー・ファームのディスパッチ・メソッドの構成

- ファーム・サーバーの作成

- ステップ3: ポートの多重化の構成

- ステップ4: HTTPリダイレクトの構成

- ステップ5: セッションIDの永続性の構成

- ステップ6: LRPの構成

- ステップ7: WebLogic Serverコンポーネントの構成

はじめに

ここでは、このガイド『Oracle WebLogic Serverクラスタの管理』で使用されているドキュメントのアクセシビリティ機能および表記規則について説明します。

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

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

サポートをご購入の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を参照してください。

表記規則

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

規則

意味

太字

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

斜体

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

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 概要とロードマップ

この章では、このガイド『Oracle WebLogic Serverクラスタの管理』の内容と構成について説明します。

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

- ドキュメントのスコープと対象読者

- このドキュメントの手引き

- 関連ドキュメント

- このリリースでのクラスタリングの新機能と変更点

ドキュメントのスコープと対象読者

このドキュメントは、1つまたは複数のクラスタでWebベース・アプリケーションを開発またはデプロイするアプリケーション開発者および管理者を対象としています。また、WebLogic Serverを評価するビジネス・アナリストや、特定のアプリケーションでWebLogic Serverクラスタの使用を考えているシステム設計者にとって便利な情報も掲載されています。

このドキュメントのトピックでは、主にWebLogic Serverクラスタを含む本番環境のプランニング、実装、およびサポートに関連する情報が提供されています。WebLogic Serverクラスタ上で実行されるアプリケーションを設計または開発するソフトウェア・エンジニア向けの主なガイドラインも記述されています。

このマニュアルは、Java EE、HTTP、HTMLコード、およびJavaプログラミング(サーブレット、JSP、またはEJBの開発)に精通している読者を対象としています。

このドキュメントの手引き

- この章「概要とロードマップ」では、このガイドの構成について説明します。

- 「WebLogic Serverのクラスタリングの理解」では、WebLogic Serverのクラスタの概要を示します。

- 「クラスタでの通信」では、WebLogic Serverインスタンス同士がクラスタ内で通信する仕組みと、クラスタ全体のJNDIツリーを利用する仕組みについて説明します。

- 「クラスタの構成の理解」では、クラスタの構成を定義する情報が格納および保持される仕組みを説明し、クラスタの構成作業を実施する方法を示します。

- 「クラスタでのロード・バランシング」では、各種のオブジェクトを対象としたWebLogic Serverクラスタでのロード・バランシングのサポートについて説明し、設計者および管理者向けに、ロード・バランシングに関連する計画および構成上の考慮事項を示します。

- 「クラスタのフェイルオーバーとレプリケーション」では、WebLogic Serverでクラスタ内の障害が検出される仕組みについて説明し、フェイルオーバー方式の概要をオブジェクトのタイプ別に示します。

- 「サーバー全体の移行」では、WebLogic Serverでサポートされている様々な移行メカニズムについて説明します。

- 「サービスの移行」では、WebLogic Serverでサポートされているサービスの移行メカニズムについて説明します。

- 「クラスタ・アーキテクチャ」では、WebLogic Serverクラスタの各種のアーキテクチャについて説明します。

- 「WebLogicクラスタの設定」では、WebLogic Serverクラスタを構成するためのガイドラインと手順を示します。

- 「動的クラスタ」では、動的クラスタについて説明します。

- 「Coherenceクラスタの構成と管理」では、Coherenceクラスタの構成および管理方法について説明します。

- 「クラスタリングのベスト・プラクティス」では、WebLogic Serverクラスタでホストされるアプリケーションのスケーラビリティ、信頼性、およびパフォーマンスを最大にする設計およびデプロイメントのベスト・プラクティスを紹介します。

- 「一般的な問題のトラブルシューティング」では、クラスタに関連する問題の発生を防ぎ、また問題が起きた場合にそれに対処するためのガイドラインを示します。

- 「WebLogicクラスタのAPI」では、WebLogicクラスタのAPIについて説明します。

- 「クラスタに関するBIG-IPハードウェアの構成」では、WebLogic Serverクラスタで動作するようにF5 BIG-IPコントローラを構成するオプションについて説明します。

- 「MAN/WANフェイルオーバーに関するF5ロード・バランサの構成」では、F5ハードウェア・ロード・バランサの構成方法について説明します。

- 「MAN/WANフェイルオーバーに関するRadwareロード・バランサの構成」では、Radwareハードウェア・ロード・バランサの構成方法について説明します。

関連ドキュメント

- 『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』のEnterprise JavaBeansの理解に関する項

- 『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のWebアプリケーションの作成と構成に関する項

このリリースでのクラスタリングの新機能と変更点

このリリースのWebLogic Serverでは、動的クラスタ・ライフサイクル操作の使いやすさを改善するためのWLSTコマンドが追加されています。WLSTのscaleUpコマンドとscaleDownコマンドを使用することで、動的クラスタ内の動的サーバーを簡単に起動および停止したり、動的クラスタのサイズを拡張または縮小したりすることができます。詳細は、「動的クラスタ内のサーバーの起動と停止」および「動的クラスタの拡張と縮小」を参照してください。

このリリースで導入された新しいWebLogic Server機能の包括的なリストは、『Oracle WebLogic Serverの新機能』を参照してください。

2 WebLogic Serverのクラスタリングの理解

この章では、WebLogic Serverクラスタにおける概要について説明します。

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

- WebLogic Serverクラスタとは

- 動的クラスタとは

- クラスタとドメインの関係

- クラスタリングの利点とは

- クラスタの重要な機能とは

- クラスタリング可能なオブジェクトの種類

- クラスタリングできないオブジェクトの種類

WebLogic Serverクラスタとは

WebLogic Serverクラスタは、同時に動作し、連携して高度なスケーラビリティと信頼性を実現する複数のWebLogic Serverサーバー・インスタンスで構成されます。クラスタはクライアントからは単一のWebLogic Serverインスタンスのように見えます。クラスタを構成する複数のサーバー・インスタンスは同じマシン上で実行することも、複数のマシンに分散配置することもできます。クラスタの能力は、既存のマシン上のクラスタにサーバー・インスタンスを追加することによって強化できます。また、新たにサーバー・インスタンスを配置するためのマシンをクラスタに追加することもできます。クラスタ内の各サーバー・インスタンスでは、同じバージョンのWebLogic Serverが動作している必要があります。

動的クラスタとは

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

動的クラスタを作成すると、動的サーバーが事前構成され、自動的に生成されます。これにより、追加のサーバー容量が必要な場合に動的クラスタ内のサーバー・インスタンスの数を簡単にスケール・アップできます。動的サーバーは、最初に手動で構成してそれをクラスタに追加する必要はなく、単に起動するだけで使用できます。

動的クラスタの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「動的クラスタ」および動的クラスタの作成に関する項を参照してください。

クラスタとドメインの関係

クラスタは特定のWebLogic Serverドメインの一部です。

ドメインとは、関連性があり1つの単位として管理されるWebLogic Serverリソースの集合のことです。ドメインには1つまたは複数のWebLogic Serverインスタンス(クラスタ化インスタンス、非クラスタ化インスタンス、またはクラスタ化インスタンスと非クラスタ化インスタンスの組合せが可能)が含まれます。ドメインには、複数のクラスタを構成できます。またドメインには、ドメインにデプロイされるアプリケーション・コンポーネントと、それらのアプリケーション・コンポーネントおよびドメイン内のサーバー・インスタンスが必要とするリソースおよびサービスも含まれます。アプリケーションおよびサーバー・インスタンスで使用されるリソースとサービスの例には、マシン定義、オプションのネットワーク・チャネル、コネクタ、起動クラスなどがあります。

WebLogic Serverインスタンスは、様々な基準によってドメインに分類できます。たとえば、ホストするアプリケーションの論理的な区分、地理的な考慮事項、あるいは管理対象リソースの数や複雑度に基づいてリソースを複数のドメインに割り当てることができます。ドメインの詳細は、『Oracle WebLogic Serverドメイン構成の理解』を参照してください。

各ドメイン内で、1つのWebLogic Serverインスタンスが管理サーバーとして機能します。このサーバー・インスタンスでは、ドメイン内のその他のサーバー・インスタンスおよびリソースのすべてを構成、管理、およびモニターします。各管理サーバーでは1つのドメインだけを管理します。ドメインに複数のクラスタが含まれる場合、ドメイン内の各クラスタは同じ管理サーバーによって管理されます。

あるクラスタ内のすべてのサーバー・インスタンスは同じドメイン内になければなりません; 1つのクラスタを複数のドメインにまたがって「分割」することはできません。同様に、構成済のリソースまたはサブシステムを複数のドメインで共有することはできません。

クラスタ化されたWebLogic Serverインスタンスの動作は、フェイルオーバーとロード・バランシングの機能を備えること以外は、クラスタ化されないインスタンスと同様です。クラスタ化されたWebLogic Serverインスタンスの構成に使用するプロセスおよびツールは、クラスタ化されないインスタンスの場合と同じです。ただし、クラスタリングによって可能になるロード・バランシングとフェイルオーバーの効果を実現するためには、クラスタの構成に関する特定のガイドラインに従う必要があります。

WebLogic Serverで使用されるフェイルオーバーおよびロード・バランシングのメカニズムと、個別の構成オプションとの関係については、「クラスタでのロード・バランシング」,および「クラスタのフェイルオーバーとレプリケーション」を参照してください。

構成上の推奨事項については、「WebLogicクラスタの設定」の手順説明で詳しく示しています。

クラスタリングの利点とは

WebLogic Serverクラスタを利用することによってもたらされる利点には、次のものがあります。

- スケーラビリティ
WebLogic Serverクラスタにデプロイされるアプリケーションの能力を、必要に応じて動的に増強することができます。サービスを中断させることなく、つまり、クライアントおよびエンド・ユーザーへの影響なしにアプリケーションを動作させ続けながら、クラスタにサーバー・インスタンスを追加できます。

- 高可用性
WebLogic Serverクラスタでは、サーバー・インスタンスで障害が発生してもアプリケーションの処理を継続できます。アプリケーション・コンポーネントの「クラスタリング」は、クラスタ内の複数のサーバー・インスタンス上にコンポーネントをデプロイすることによって行います。そのため、コンポーネントが動作しているサーバー・インスタンスに障害が発生した場合、同じコンポーネントがデプロイされている別のサーバー・インスタンスがアプリケーションの処理を継続できます。

WebLogic Serverインスタンスのクラスタリングは、アプリケーション開発者およびクライアントからは意識されません。ただし、クラスタリングを可能にする技術インフラストラクチャを理解しておくことは、プログラマおよび管理者が、各自が扱うアプリケーションのスケーラビリティと可用性を最大限に高める上で役立ちます。

クラスタの重要な機能とは

この項では、スケーラビリティと高可用性を実現する重要なクラスタリングの機能を、技術的でない分かりやすい用語で定義します。

- アプリケーションのフェイルオーバー
簡単に言うと、フェイルオーバーとは、特定の「ジョブ」つまり何らかの処理タスクの集合を実行しているアプリケーション・コンポーネント(以降の箇所では、主に「オブジェクト」と呼びます)が何らかの理由によって使用不可になったときに、障害を起こしたオブジェクトのコピーがそのジョブを引き継いで完了することを意味します。

障害を起こしたオブジェクトの処理を新しいオブジェクトが引き継ぐためには:

- ジョブを引き継ぐことのできる、障害を起こしたオブジェクトのコピーが存在している必要があります。

- すべてのオブジェクトの場所および動作のステータスを定義する情報が存在し、他のオブジェクトと、フェイルオーバーを管理するプログラムから参照できることが必要です - これにより、ジョブを完了する前に障害を起こした最初のオブジェクトを特定できます。

- 実行中のジョブの進捗状況についての情報が、他のオブジェクトと、フェイルオーバーを管理するプログラムから参照できることが必要です - これにより、中断されたジョブを引き継ぐオブジェクトは、最初のオブジェクトで障害が発生した時点でジョブがどの程度完了していたか(たとえば、どのデータが変更され、プロセス内のどの手順が完了しているか)を認識します。

WebLogic Serverは、標準に基づいた通信技術および通信機能であるIPソケット、およびJNDI (Java Naming and Directory Interface)を利用して、クラスタ内のオブジェクトの可用性に関する情報を共有および保持します。WebLogic Serverはこれらの技術によって、ジョブを完了する前にオブジェクトが停止したことと、中断されたジョブを完了するためのオブジェクトのコピーが存在する場所を特定します。

注意:

旧バージョンとの後方互換性のために、WebLogic Serverではクラスタ間の通信にマルチキャストを使用できます。

あるジョブに関してどのような処理が完了しているかについての情報を状態(ステート)と呼びます。WebLogic Serverでは、セッション・レプリケーションおよびレプリカ対応スタブと呼ばれる技術を利用して、状態についての情報を保持します。レプリケーション技術により、特定のオブジェクトが不意にそのジョブの実行を停止したとき、障害を起こしたオブジェクトがどこで停止したかをオブジェクトの別のコピーが認識し、代わりにそのジョブを完了することが可能になります。

- WebLogic Serverでは、クラスタ化サーバー・インスタンスを、あるマシンから別のマシンに、自動的にまたは手動で移行できます。移行できる管理対象サーバーは、移行可能サーバーと呼ばれます。この機能は、高可用性が求められる環境に向けて設計されています。サーバー移行機能は、次の場合に役立ちます。

- シングルトン・サービスの中断のない可用性の保証: シングルトン・サービスとは、ホストとなるサーバー・インスタンスで障害が発生した場合にJMSやJTAトランザクション・リカバリ・システムなど、常に1つのサーバー・インスタンス上のみで実行する必要があるサービスのことです。障害が発生した場合、自動移行のために構成されている管理対象サーバーは別のマシンに自動的に移行されます。

- 管理対象サーバーとそれがホストするすべてのサービスを計画的なシステム管理プロセスの一部として再配置する場合のプロセスの簡略化。管理対象サーバーの移行を開始するには、『Oracle WebLogic Serverの理解』のシステム管理ツールおよびAPIの概要に関する項にリストされたいずれかの管理ツールを使用できます。

サーバー移行プロセスによって、管理対象サーバー(IPアドレスおよびホストされるアプリケーションを含む)は、そのまま全部が定義済の使用可能なホスト・マシンの1つに再配置されます。

- ロード・バランシング
ロード・バランシングとは、環境内のコンピューティング・リソースおよびネットワーキング・リソース間で、ジョブとそれに関連する通信を均等に分配することです。ロード・バランシングが実行されるには:

- 特定のジョブを実行できるオブジェクトの複数のコピーが存在している必要があります。

- すべてのオブジェクトの場所および動作のステータスについての情報が入手できることが必要です。
WebLogic Serverでは、オブジェクトをクラスタリング、つまり複数のサーバー・インスタンス上にデプロイすることにより、同じジョブを実行する代替オブジェクトを用意することができます。WebLogic Serverは、デプロイされるオブジェクトの可用性および場所の情報を、ユニキャスト、IPソケット、およびJNDIを利用して共有し、保持します。

注意:

以前のバージョンのWebLogic Serverとの互換性を維持するため、クラスタ間の通信にマルチキャストを使用することも可能です。

WebLogic Serverでの通信およびレプリケーション技術の利用形態について、詳しくは「クラスタでの通信」を参照してください

クラスタリング可能なオブジェクトの種類

クラスタ化されるアプリケーションまたはアプリケーション・コンポーネントは、クラスタ内の複数のWebLogic Serverインスタンス上で利用可能なものです。オブジェクトをクラスタリングすると、そのオブジェクトに対してフェイルオーバーとロード・バランシングが有効になります。クラスタの管理、保守、およびトラブルシューティングの手順を簡素化するには、オブジェクトを均一に、つまりクラスタ内のすべてのサーバー・インスタンスにデプロイします。

Webアプリケーションは、Enterprise JavaBeans (EJB)、サーブレット、Java Server Pages (JSPs)などを含む様々な種類のオブジェクトで構成できます。それぞれのオブジェクトの種類ごとに、制御、呼び出し、およびアプリケーション内部での機能に関連する動作の一意の集合が定義されています。この理由から、クラスタリングをサポートし、またその結果としてロード・バランシングとフェイルオーバーを実現するためにWebLogic Serverで利用される手法は、オブジェクトの種類ごとに異なる可能性があります。WebLogic Serverのデプロイメントでは、次の種類のオブジェクトのクラスタリングが可能です。

- サーブレット

- JSP

- EJB

- Remote Method Invocation (RMI)オブジェクト

- Java Messaging Service (JMS)の宛先

種類の異なるオブジェクト間で、一部の動作が共通している可能性があります。その場合、類似したオブジェクト・タイプについては、クラスタリングのサポートおよび実装上の考慮事項が一致することがあります。次の項では、次のオブジェクト・タイプの組合せ別に説明および手順を示しています。

- サーブレットとJSP

- EJBとRMIオブジェクト

次の項では、WebLogic Serverでのクラスタリング、フェイルオーバー、およびロード・バランシングのサポートについて、オブジェクトのタイプ別に簡単に説明します。

サーブレットとJSP

WebLogic Serverでは、クラスタ化されたサーブレットおよびJSPにアクセスするクライアントのHTTPセッション状態をレプリケートすることで、サーブレットとJSPに対するクラスタリング・サポートが提供されます。WebLogic Serverでは、HTTPセッションをメモリー、ファイル・システム、またはデータベースに保持できます。

サーブレットまたはJSPの自動フェイルオーバーを有効にするには、セッション状態をメモリーに保持する必要があります。サーブレットまたはJSPでのフェイルオーバーの仕組み、および関連する要件とプログラミングにおける考慮事項については、「HTTPセッション状態のレプリケーション」を参照してください

WebLogic Serverのプロキシ・プラグインまたは外部ロード・バランシング・ハードウェアを使用して、クラスタ内にサーブレットおよびJSPロードをバランスよく配置できます。WebLogic Serverプロキシ・プラグインは、ラウンドロビン・ロード・バランシングを使用します。通常、外部のロード・バランサでは、様々なセッション・ロード・バランシング・メカニズムがサポートされます。詳細は、「サーブレットとJSPのロード・バランシング」を参照してください

EJBとRMIオブジェクト

EJBとRMIオブジェクトのロード・バランシングとフェイルオーバーは、レプリカ対応スタブを使用して処理されます。このスタブは、クラスタ全体の中からオブジェクトのインスタンスを見つけ出すためのメカニズムです。レプリカ対応スタブは、オブジェクトのコンパイル処理の結果としてEJBおよびRMIオブジェクトに対して作成されます。EJBとRMIオブジェクトは均一に、つまりクラスタ内のすべてのサーバー・インスタンスにデプロイされます。

EJBとRMIオブジェクトのフェイルオーバーは、オブジェクトのレプリカ対応スタブを使用して実現されます。クライアントがレプリカ対応スタブを通じて障害が発生したサービスに対して呼出しを行うと、スタブはその障害を検出し、別のレプリカに対してその呼出しを再試行します。様々な種類のオブジェクトに対するフェイルオーバーのサポートについては、「EJBとRMIのレプリケーションとフェイルオーバー」を参照してください

WebLogic Serverクラスタは、クラスタ化されるEJBおよびRMIオブジェクト間でロード・バランシングを行うための複数のアルゴリズム(ラウンドロビン、重みベース、ランダム、ラウンドロビン・アフィニティ、重みベース・アフィニティ、およびランダム・アフィニティ)をサポートしています。デフォルトでは、WebLogic Serverクラスタはラウンドロビン方式を使用します。WebLogic Server管理コンソールを使用して、他の方式を使用するようにクラスタを構成できます。選択した方式は、クラスタ化オブジェクト用に取得したレプリカ対応スタブの内部で保持されます。詳細は、「EJBとRMIオブジェクトのロード・バランシング」を参照してください

JMSとクラスタリング

WebLogic JMS (Java Messaging Service)のアーキテクチャでは、クラスタ内のあらゆるWebLogic Serverサーバー・インスタンスから宛先への透過的なアクセスをクラスタ全体でサポートすることによって、複数のJMSサーバーのクラスタリングを実装しています。WebLogic Serverでは、JMS宛先および接続ファクトリをクラスタ全体に分散させることができますが、同じJMSトピックまたはJMSキューは引き続き、クラスタ内の個々のWebLogic Serverインスタンスによって個別に管理されます。

ロード・バランシングはJMSに対してサポートされています。ロード・バランシングを有効にするには、JMSサーバーのターゲットを構成する必要があります。ロード・バランシングとJMSコンポーネントの詳細は、「JMSのロード・バランシング」,を参照してください。クラスタ化されたJMSの設定手順については、「固定サービスの移行可能ターゲットを構成する」,および「移行可能サービスをデプロイ、アクティブ化、および移行する」を参照してください。

クラスタリングできないオブジェクトの種類

次のAPIおよび内部サービスは、WebLogic Serverでクラスタリングできません。

- ファイルの共有を含むFileサービス

- Timeサービス

これらのサービスは、クラスタ内の個々のWebLogic Serverインスタンスでは使用できます。ただし、これらのサービスに関してロード・バランシングやフェイルオーバー機能は利用できません。

3 クラスタでの通信

この章では、WebLogic Serverクラスタが、IPソケットおよびIPユニキャストまたはマルチキャストを使用してどのように通信するかについて説明します。

クラスタ内のWebLogic Serverインスタンスは、2つの基本的なネットワーク技術を利用して互いに通信します。

- IPユニキャストまたはマルチキャスト - サーバー・インスタンスが、サービスの可用性と、継続的な可用性を示すハートビートをブロードキャストするために使用します。ユニキャストかマルチキャストかの選択の詳細は、「ユニキャストかマルチキャストかを選択する際の考慮事項」を参照してください。

- IPソケット - クラスタ化サーバー・インスタンス間でピア・ツー・ピア通信を行うための導管として機能します。

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

- WebLogic Serverのクラスタ・メッセージング・プロトコルの選択

- IPソケットを使用したピア・ツー・ピア通信

- ソケット経由のクライアント通信

- クラスタ全体のJNDIネーミング・サービス

WebLogic Serverのクラスタ・メッセージング・プロトコルの選択

WebLogic Serverは、2つのクラスタ・メッセージング・プロトコルをサポートしています。

- マルチキャスト: このプロトコルは、UDPマルチキャストを使用します。WebLogic Server 4.0以降のWebLogic Serverクラスタでサポートされています。

- ユニキャスト: このプロトコルは、ポイント・ツー・ポイントTCP/IPソケットを使用します。WebLogic Server 10.0で追加されました。

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

- IPマルチキャストの使用

- ユニキャストを使用した1対多通信

- ユニキャストかマルチキャストかを選択する際の考慮事項

IPマルチキャストの使用

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

注意:

マルチキャスト・アドレスは、範囲が224.0.0.0 - 239.255.255.255のIPアドレスです。WebLogic Serverで使用されるデフォルトのマルチキャスト・アドレスは、239.192.0.0です。x.0.0.1の範囲内のマルチキャスト・アドレスを使用することはできません。マルチキャスト・ポートには、通常のUDPポート範囲(0から65535)がありますが、一部のUDPポートは、特定の目的のために予約されており、通常は回避する必要があります。

マルチキャストはアプリケーションに対してメッセージをブロードキャストしますが、メッセージが実際に届くことは保証されていません。アプリケーションのローカル・マルチキャスト・バッファがいっぱいの場合、新規のマルチキャスト・メッセージをそのバッファに書込めないので、アプリケーションにはメッセージが「届いた」ことがわかりません。この制約のため、WebLogic Serverインスタンスでは、マルチキャストに対してブロードキャストされたメッセージが届かない可能性を考慮しています。

WebLogic Serverのマルチキャストの実装では、標準のUDPマルチキャストを使用して、メッセージが送信されるマルチキャスト・アドレスおよびポートを明示的にリスニングしているグループにクラスタ・メッセージをブロードキャストします。UDPは、信頼性のあるプロトコルではないため、WebLogic Serverは、信頼性のある独自のメッセージング・プロトコルを、送信するメッセージに組み込み、失われたメッセージを検出して再送信します

ほとんどのオペレーティング・システムおよびスイッチは、同じサブネット内のマシン間でUDPマルチキャストをデフォルトでサポートしています。ただし、ほとんどのルーターは、サブネット間のUDPマルチキャスト・メッセージの伝播をデフォルトではサポートしていません。UDPマルチキャスト・メッセージの伝播をサポートしている環境では、UDPマルチキャストには、プロトコルに組み込まれた存続時間(TTL)メカニズムがあります。メッセージがルーターに到着するたびに、メッセージがルーティングされる前にTTLが1ずつ減ります。TTLがゼロになると、メッセージはネットワーク間で伝播されず、UDPマルチキャスト・メッセージの範囲に対する効率的な制御が行われます。WebLogic Serverでは、デフォルトで、マルチキャスト・クラスタ・メッセージのTTLは1に設定されます。これにより、メッセージが現在のサブネットに制限されます。

マルチキャストを使用している場合、ハートビート・メッセージが3回続けて届かないと、クラスタ・ハートビート・メカニズムにより、クラスタからサーバー・インスタンスが削除されます(つまり、UDPは信頼性のあるプロトコルであるとは見なされません)。デフォルトのハートビート頻度は、10秒ごとに1回のハートビートです。つまり、最大30秒で、あるサーバー・インスタンスがクラスタを離れたことを検出できるということです。ソケットの停止が検出されたり、接続の試行が失敗した場合も、サーバーがクラスタから離れたと認識されます。

要約すると、WebLogic Serverのマルチキャスト・クラスタ・メッセージング・プロトコルは、次のように動作します。

- 非常に効率的でスケーラブルなピア・ツー・ピア・モデルを使用します。このモデルでは、サーバー・インスタンスは、各メッセージを直接ネットワークに1回送信し、各クラスタ・メンバーは、ネットワークから直接メッセージを受信します。

- クラスタ・メンバーが同じサブネット内に存在するほとんどの環境で、即時利用可能な状態で動作します。

- クラスタ・メンバーが複数のサブネットにまたがっている場合は、ルーターとWebLogic Serverの追加の構成(マルチキャストTTLなど)を行う必要があります。

- ハートビートが3回続けて届かないと、別のサーバーのクラスタ・メンバーシップ・リストからサーバー・インスタンスが削除されます。

ある環境でWebLogic Serverのマルチキャスト・メッセージング・プロトコルがサポートされているかどうかをテストするために、WebLogic Serverには、MulticastTestというJavaコマンド行ユーティリティが用意されています。

WebLogic Serverは、クラスタ内のサーバー・インスタンス間のすべての1対多通信でマルチキャストを使用します。この通信には次が含まれます。

- クラスタ全体のJNDIの更新 - クラスタ内の個々のWebLogic Serverインスタンスはマルチキャストを使用して、ローカルでデプロイされたり、削除されたりしたクラスタ化オブジェクトが使用可能かどうかを通知します。クラスタ内の各サーバー・インスタンスはこれらの通知をモニターし、クラスタ化されるオブジェクトの最新のデプロイメント状況に合わせてインスタンスのローカルJNDIツリーを更新します。詳細は、「クラスタ全体のJNDIネーミング・サービス」を参照してください

- クラスタの「ハートビート」 - WebLogic Serverは、マルチキャストを使用して、クラスタ内の個々のサーバー・インスタンスが使用可能であることを通知するために、定期的に「ハートビート」メッセージをブロードキャストします。クラスタ内のサーバー・インスタンスは、ハートビート・メッセージをモニターすることにより、どの時点でサーバー・インスタンスに障害が発生したかを特定します。(クラスタ化サーバー・インスタンスは、サーバー・インスタンスで障害が発生した時点を特定するためのより直接的な手段として、IPソケットのモニターも行います。)

- 複数のノードがあるクラスタ - 複数のノードがあるクラスタでは、オプションでマルチキャスト通信を使用できます。

マルチキャストとクラスタの構成

マルチキャスト通信は、(「クラスタ全体のJNDIネーミング・サービス」で説明するように)障害の検出とクラスタ全体のJNDIツリーの保守に関わる重要な機能を制御するので、クラスタの構成もマルチキャスト通信とのネットワーク・トポロジ・インタフェースも重要ではありません。次の項では、クラスタ内でのマルチキャスト通信に伴う問題を回避するためのガイドラインを示します。

クラスタがWAN内の複数のサブネットにまたがる場合

多くのデプロイメント構成で、クラスタ化されるサーバー・インスタンス群は単一のサブネットの内部に置かれます。これは、マルチキャスト・メッセージの確実な転送を保証するための構成です。ただし必要に応じて、ワイド・エリア・ネットワーク(WAN)内の複数のサブネット間にWebLogic Serverクラスタを分散させて冗長性を確保したり、あるいはクラスタ化されるサーバー・インスタンスをより広範な地理的領域に分散させることができます。

クラスタをWAN (または複数のサブネット)上に分散する場合、マルチキャスト・メッセージがクラスタ内のすべてのサーバー・インスタンスに必ず転送されるようにネットワーク・トポロジを計画および構成します。特に、ネットワークが次の要件を満たす必要があります。

- IPマルチキャスト・パケットの伝播の完全サポート。つまり、すべてのルーターおよびその他のトンネリング技術がマルチキャスト・メッセージをクラスタ化されているサーバー・インスタンスに伝播するように構成されている必要があります。

- 大半のマルチキャスト・メッセージがその最終的な宛先に約10ミリ秒以内に到達することを保証する、低いネットワーク待機時間。

- マルチキャスト・パケットが最終的な宛先に届くまでにルーターがパケットを破棄しないことを保証する、クラスタのマルチキャストTTL (Time-To-Live: 存続時間)の高い値。マルチキャストTTLパラメータの設定手順については、「マルチキャスト存続時間(TTL)を構成する」を参照してください。

注意:

WAN上にWebLogic Serverクラスタを分散するには、上記のマルチキャスト要件を満たす以外にも、ネットワーク機能を追加しなければならない場合があります。たとえば、不要なネットワーク・ホップを経由せずにクライアント・リクエストを最短経路でサーバー・インスタンスに送るには、ロード・バランシング・ハードウェアを構成する必要があります。

ファイアウォールがマルチキャスト通信を遮断することがある

マルチキャスト・トラフィックをファイアウォール内にトンネリングすることは可能ですが、WebLogic Serverクラスタではお薦めしません。個々のWebLogic Serverクラスタは、Webアプリケーションのクライアントに対して1つまたは複数の別個のサービスを提供する論理単位として扱うようにします。複数の異なったセキュリティ・ゾーン間にこの論理単位を分割しないでください。さらに、IPトラフィックの速度低下や中断につながる可能性のある技術は、ハートビートの不達が誤って障害として判断されることによって、WebLogic Serverクラスタを分断させることがあります。

クラスタのマルチキャスト・アドレスを他のアプリケーションと共有しない

複数のWebLogic Serverクラスタは単一のIPマルチキャスト・アドレスおよびポートを共有できますが、クラスタによって使用されているマルチキャスト・アドレスおよびポートは、他のアプリケーションでブロードキャストまたはサブスクライブしないでください。つまり、クラスタのホストとなっている1台または複数台のマシンが、マルチキャスト通信を使用する他のアプリケーションのホストも兼ねている場合、それらのアプリケーションでは必ず、クラスタが使用しているものと異なるマルチキャスト・アドレスおよびポートを使用してください。

クラスタのマルチキャスト・アドレスを他のアプリケーションと共有すると、クラスタ化サーバー・インスタンスは不必要なメッセージを処理しなければならなくなり、オーバーヘッドが増します。また、マルチキャスト・アドレスの共有は、IPマルチキャスト・バッファの過負荷と、WebLogic Serverハートビート・メッセージの送信遅延につながる可能性があります。ハートビートが適切なタイミングで受信されないため、こうした遅延によって、WebLogic Serverインスタンスがエラーとしてマークされる可能性があります。

こうした理由から、WebLogic Serverクラスタ用には専用のマルチキャスト・アドレスを割り当てて、そのアドレスを使用するすべてのクラスタのトラフィックをそのアドレスでブロードキャストできるようにします。

マルチキャスト・ストームが起こったら

クラスタ内のサーバー・インスタンスで受信メッセージが適時に処理されない場合は、否定応答(NAK)メッセージやハートビートの再送信を含むネットワーク・トラフィックが増大します。ネットワーク上でマルチキャスト・パケットが繰り返し送信されることは、マルチキャスト・ストームと呼ばれ、それが発生するとネットワークとそのネットワークに接続されたステーションに負荷がかかり、エンドステーションでハングまたは障害が発生する可能性があります。マルチキャスト・バッファのサイズを増やすと、通知が送信および受信されるレートが改善されて、マルチキャスト・ストームを防止できます。「マルチキャスト・バッファのサイズを構成する」を参照してください

ユニキャストを使用した1対多通信

WebLogic Serverのユニキャスト・プロトコルは、標準のTCP/IPソケットを使用して、クラスタ・メンバー間でメッセージを送信します。すべてのネットワークおよびネットワーク・デバイスでTCP/IPソケットがサポートされているため、ユニキャストでは、初期状態のクラスタ構成が容易になります。通常、クラスタ・メンバー間のネットワーク・トポロジに関係なく、追加の構成は不要です。加えて、ユニキャストでは、マルチキャスト・アドレスの競合によって発生する可能性がある潜在的なネットワーク・エラーが低減されます。WebLogic Serverでは、ユニキャストをデフォルトのクラスタ・プロトコルとして使用します。

WebLogic Serverユニキャスト・グループ

TCP/IPソケットはポイント・ツー・ポイント・メカニズムであるため、すべてのクラスタ・メンバーがメッセージを直接受信します。クラスタの拡大につれて必要になるソケット数を制限するために、WebLogic Serverのユニキャスト実装ではグループ・リーダー・メカニズムを使用します。このメカニズムでは、次のようになります。

- WebLogic Serverは、クラスタ内のサーバー・インスタンスを固定数のグループに分割します。

- 各グループには、グループ・リーダーとしても機能する1つのサーバー・インスタンスが含まれます。グループ・リーダーに障害が発生すると、そのグループは別のグループ・リーダーを選択します。

- クラスタ・メッセージを送受信するために、グループ内の各サーバー・インスタンスはグループ・リーダーにのみTCP/IPソケット接続を行います。グループ・リーダーは、そのすべてのグループ・メンバーおよびクラスタ内の他のすべてのグループ・リーダーに接続します。

- グループ・リーダーは、そのグループ内のサーバー・インスタンスからクラスタ・メッセージを受信すると、そのメッセージをグループ内の他のすべてのメンバーおよびクラスタ内の他のすべてのグループ・リーダーに再送信します。他のグループ・リーダーは、そのすべてのグループ・メンバーにメッセージを再送信します。これにより、各サーバー・インスタンスは、そのサーバーがクラスタ内の他のすべてのサーバー・インスタンスへの接続を確立する必要なしに、クラスタ内のすべてのメッセージを受信できます。

ユニキャストを使用する場合、サーバー・インスタンスはハートビートを送信して、その可用性を通知します。これはマルチキャストと同様です。サーバー・インスタンスは、ハートビート・メッセージをモニターすることにより、どの時点で別のサーバー・インスタンスに障害が発生したかを特定します。ただし、ユニキャストでは、ハートビート・メッセージが1回でも届かないと、クラスタ・ハートビート・メカニズムにより、クラスタからサーバー・インスタンスが削除されます(TCP/IPは信頼性のあるプロトコルであると見なされているため)。

マルチキャストでは10秒ごとにハートビートの喪失がチェックされるのに対し、ユニキャストでは15秒ごとにチェックされます。この追加の5秒により、メッセージがリモート・グループのメンバーからリモート・グループのリーダー、さらにローカル・グループのリーダーに移動し、最終的にローカル・グループのメンバーに届くための十分な時間が確保されます。デフォルトのハートビート頻度は、10秒ごとに1回のハートビートです。つまり、15秒以内に、あるサーバー・インスタンスがクラスタを離れたことが検出されるということです。ソケットの停止が検出されたり、接続の試行が失敗した場合も、サーバーがクラスタから離れたと認識されます。

グループへのサーバー・インスタンスの割当て

注意:

グループへのサーバー・インスタンスへの割当てに使用されるアルゴリズムは、WebLogic Server 12.1.2およびそれ以前のバージョンで使用されていたアルゴリズムから変更されました。新しいアルゴリズムについて、次の項で説明します。これは、実行中のクラスタの拡張の柔軟性を向上させ、クラスタの実行中に管理対象サーバーがWebLogic Serverクラスタに追加されるユースケースのサポートを向上させるように最適化されています。

WebLogic Serverのユニキャスト実装は、クラスタのサーバー・インスタンスを10グループに内部的に編成します。WebLogic Serverは、サーバー・インスタンスをグループに割り当て、サーバーのネーミング・パターンに従って各グループ内のサーバー・インスタンスをソートします。グループに含まれるサーバー・インスタンス数は動的であるため、クラスタ・サーバー・インスタンスの数と名前によっては非対称または空のグループが存在することがあります。

サーバー・インスタンスをグループに割り当てるために、WebLogic Serverは各サーバー名を接頭辞と整数の2つの部分に分離します。たとえば、server1という名前のサーバー・インスタンスは接頭辞<server>と整数<1>に分離されます。

サーバー・インスタンスには任意の名前を使用できます。構成されるサーバーでは、サーバー名が整数で終わらない場合に、WebLogic Serverは初期値を計算し、サーバー・インスタンスに割り当てます。この値を使用して、サーバー・インスタンスを自動的に割り当てる適切なグループを特定します。たとえば、サーバー・インスタンスserverAおよびserverBには名前に整数がありません。WebLogic Serverは、接頭辞に名前全体を使用し、serverAには728 、serverBには729など、整数に使用する値を計算します。

動的クラスタはサーバー・テンプレート設定を使用し、接頭辞と整数の連番を使用して動的サーバーに自動的に名前を付けるため、動的サーバーは常にこのパターンに従います。

整数を各サーバー名に関連付けた後で、WebLogic Serverはアルゴリズムを使用し、その整数に基づいてサーバー・インスタンスをグループに割り当てます。各グループ内で、サーバー・インスタンスは最初に接頭辞のアルファベット順にソートされてから、整数でソートされます。

各グループ内の最初のサーバー・インスタンスはグループ・リーダーとして機能します。この割当てモデルでは、クラスタ内のすべてのサーバー・インスタンスは、既存の実行中サーバーと新規に追加されたサーバーのどちらであるかにかかわらず、グループ・メンバーシップとグループ・リーダー・ロールで一貫性のあるビューを共有します。

次の表に、ユニキャスト・ネーミング・パターンと、WebLogic Serverがサーバー・インスタンスをグループにどのように割り当て、ソートするかを示します。この例では、10個のグループを使用します。クラスタには、server1からserver15までの15個のサーバー・インスタンスと、serverAからserverEまでの5つの追加サーバー・インスタンスが含まれます。

表3-1 サーバー名の接頭辞と整数への分離

サーバー名

接頭辞

Integer

server1

server

1

server2

server

2

server3

server

3

server4

server

4

server5

server

5

server6

server

6

server7

server

7

server8

server

8

server9

server

9

server10

server

10

server11

server

11

server12

server

12

server13

server

13

server14

server

14

server15

server

15

serverA

serverA

計算結果は728

serverB

serverB

計算結果は729

serverC

serverC

計算結果は730

serverD

serverD

計算結果は731

serverE

serverE

計算結果は732

表3-2 グループへのサーバー・インスタンスの割当て

グループ

グループ内のサーバー・インスタンス

group0

server10 (group leader), serverC

group1

server1 (group leader), server11, serverD

group2

server2 (group leader), server12, severE

group3

server3 (group leader), server13

group4

server4 (group leader), server14

group5

server5 (group leader), server15

group6

server6 (group leader)

group7

server7 (group leader)

group8

server8 (group leader), serverA

group9

server9 (group leader), serverB

server16という新規サーバー・インスタンスを追加した場合、WebLogic Serverは、それをgroup6のserver6の後に割り当てます。

group6: server6 (group leader), server 16

server20という新規サーバー・インスタンスを追加した場合、WebLogic Serverは、それをgroup0のserver10の後、serverCの前に割り当てます。

group0: server10 (group leader), server20, serverC

接頭辞は整数より前にソートされるため、clonedServer16という新規サーバーを追加した場合、WebLogic Serverはそれをgroup6のserver6の前に割り当てます。clonedServer16がグループ内の最初のサーバー・インスタンスになったため、グループ・リーダーはclonedServer16に変更されます。

group6: clonedServer16 (new group leader), server6, server16

ユニキャストの構成

ユニキャストは、ClusterMBean.setClusterMessagingMode MBean属性を使用して構成します。このパラメータのデフォルト値はunicastです。このMBeanへの変更は動的には反映されません。変更を有効にするには、クラスタを再起動する必要があります。

特定のユニキャスト・チャネルを定義するには、最初にcluster-broadcastまたはcluster-broadcast-secureプロトコルとのユニキャスト通信用のカスタム・ネットワーク・チャネルを定義します。このカスタム・ネットワーク・チャネルを定義した後、ClusterMBean.ClusterBroadcastChannel MBean属性でチャネル名を指定することで、このチャネルをクラスタに関連付けることができます。ユニキャストが有効になると、サーバーはこのMBean属性で定義された値をクラスタ間の通信に使用しようとします。ユニキャスト・チャネルが明示的に定義されていない場合は、デフォルトのネットワーク・チャネルが使用されます。

注意:

ClusterMBean.ClusterBroadcastChannel属性の使用は、ユニキャストでのみサポートされます。

WebLogic Serverクラスタでユニキャスト通信を構成するときに、TCP接続が正常に確立されるようにするためには、すべての静的サーバーおよび動的サーバーに対してリスニング・ポートおよびリスニング・アドレス(IPアドレスまたはDNS名)を設定する必要があります。または、カスタムのユニキャスト・ブロードキャスト・チャネルを構成できます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのカスタム・ネットワーク・チャネルの構成に関する項を参照してください。

ユニキャストを使用する場合の考慮事項

WebLogic Server 12.1.3でユニキャストを使用してクラスタ通信を処理する場合は、次の点を考慮に入れてください。

- クラスタのすべてのメンバーで同じメッセージ・タイプを使用する必要があります。メッセージングとしてマルチキャストとユニキャストを混在させることはできません。

- 個別のクラスタ・メンバーで、クラスタのメッセージング・タイプをオーバーライドすることはできません。

- すべてのサーバー・インスタンスは、リスニング・ポートおよびリスニング・アドレスの組合せが固有である必要があります。

- クラスタ全体を停止し、再起動してメッセージ・モードを変更する必要があります。

- JMSトピックは、クラスタ・アドレスに依存しない独自のマルチキャスト・アドレスに対してメッセージをパブリッシュするので、マルチキャスト向けに構成されたJMSトピックでもユニキャスト向けに構成されたWebLogicクラスタにアクセスできます。ただし、次の点を考慮に入れてください。

- クラスタのユニキャスト通信を可能にするルーター・ハードウェア構成では、JMSマルチキャスト・サブスクライバが機能しない場合があります。

- JMSマルチキャスト・サブスクライバは、マルチキャスト・アクセスが可能なネットワーク・ハードウェア構成を必要とします。
詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』のWebLogic JMSでのマルチキャストの使用に関する項を参照してください。

ユニキャストかマルチキャストかを選択する際の考慮事項

ユニキャストは、初期状態のクラスタ構成を容易にし、ほとんどのユーザー要件を満たす可能性が高いので、デフォルトのプロトコルとなっています。ただし、Oracleでは、両方のプロトコルを同じように完全にサポートしています。いずれのプロトコルでも、クラスタ・メンバーには、クラスタ・メッセージの送受信をタイムリーに行うための十分な処理時間があることが必要です。これにより、クラスタ・メンバーシップの不要な変更を回避し、クラスタから離れたりクラスタに再参加したりすることに伴う固有の再同期コストの発生を防ぐことができます。使用可能なリソースの過度な利用を招くため、クラスタ・メンバーシップの不要な変更が行われないようにすることをお薦めします。

ユニキャストの使用時は特に、グループ・リーダーがリソース面の制約を受けることがないようにしてください。グループ・リーダーは、メッセージ・リレーを行って、クラスタの他のメンバーにクラスタ・メッセージを配信する役目を担うからです。グループ・リーダーになんらかの遅延が生じると、複数のクラスタ・メンバーが影響を受け、そのグループ内で新しいグループ・リーダーが選出されるという結果を招くこともあります。

これに対して、マルチキャストでは、速度の遅いメンバーが実際に影響を及ぼす可能性があるのは、そのクラスタの固有のメンバーシップに対してのみです。マルチキャスト・クラスタは通常、クラスタ・メッセージの伝播に関してはより効率的であり、そのため、リソースのオーバーサブスクリプションに対する抵抗力がより高い傾向があります。これらの理由から、ネットワーク環境でWebLogic ServerクラスタUDP要件がサポートされている場合、マルチキャストはスループット要件の高い非常に大きなクラスタに適したオプションとなる可能性があります。

各プロトコルには固有の利点があります。表3-3に、マルチキャストとユニキャストの違いをいくつか示します。

表3-3 マルチキャストとユニキャストの違いのサマリー

マルチキャスト

ユニキャスト

UDPマルチキャストを使用します。

TCP/IPを使用します。

複数のサブネットにまたがるクラスタリングでは、ルーターへの追加の構成(TTL)が必要です。

ネットワーク・トポロジのための追加の構成は不要です。

マルチキャストのリスニング・アドレスおよびリスニング・ポートを構成する必要があります。複数のNICが搭載されているマシン上では、使用するネットワーク・インタフェースを指定する必要がある場合があります。

必要なのは、リスニング・アドレスの指定のみです。クラスタ通信でのデフォルト・チャネルまたはカスタム・ネットワーク・チャネルの使用をサポートしています。

各メッセージは、ネットワークに直接配信され、ネットワークから直接受信されます。

各メッセージは、グループ・リーダーに配信されます。グループ・リーダーは、そのメッセージを、他のグループ・メンバー(N - 1)および他のグループ・リーダー(M - 1) (存在する場合)に再送信します。他のグループ・リーダーはその後、各自のグループ・メンバーにメッセージを再送信します。この結果、すべてのクラスタ・メッセージについて最大でN x M個のネットワーク・メッセージが存在することになります。各クラスタ・メンバーへのメッセージ配信は、1つから3つのネットワーク・ホップを経由して行われます。

すべてのサーバーは、他のすべてのサーバーの存在を認識しています。

グループ・リーダーは、メッセージ・リレー・ポイントとして機能し、そのグループ・メンバーおよび他のグループ・リーダーにメッセージを再送信します。

ハートビート・メッセージが3回続けて届かないと、クラスタ・メンバーシップの変更が発生し、クラスタ・リストからメンバーが削除されます。

ハートビート・メッセージが1回でも届かないと、クラスタ・メンバーシップの変更が発生し、クラスタからメンバーが削除されます。

IPソケットを使用したピア・ツー・ピア通信

IPソケットは、2つのアプリケーション間でメッセージおよびデータを転送するための、シンプルでパフォーマンスの高いメカニズムです。クラスタ化されるWebLogic Serverインスタンスは、次の目的でIPソケットを使用します。

- 別のマシンでクラスタ化されている別のサーバー・インスタンスにデプロイされた、クラスタ化されていないオブジェクトへのアクセス。

- HTTPセッション状態とステートフル・セッションEJBの状態の、プライマリ・サーバー・インスタンスとセカンダリ・サーバー・インスタンス間でのレプリケーション。

- リモート・サーバー・インスタンス上にあるクラスタ化オブジェクトへのアクセス。(これは一般に、「推奨複数層アーキテクチャ」で説明するような複数層クラスタ・アーキテクチャでのみ発生します)。

注意:

WebLogic ServerでのIPソケットの使用方法はクラスタ関連にとどまらず、たとえば、Javaクライアント・アプリケーションがリモート・オブジェクトにアクセスする場合など、すべてのRMI通信がソケットを使用して行われます。

WebLogic Serverクラスタのパフォーマンスは、ソケットの構成によって大きく左右されます。WebLogic Serverでのソケット通信の効率は、次の2つの要因によって決まります。

- サーバー・インスタンスのホスト・システムではネイティブ・ソケット・リーダー実装とpure-Javaソケット・リーダー実装のどちらを使用しているか

- pure-Javaソケット・リーダーを使用しているシステムの場合は、サーバー・インスタンスが十分な数のソケット・リーダー・スレッドに対応するよう構成されているかどうか

pure-Javaとネイティブ・ソケット・リーダーの実装の比較

ソケット・リーダー・スレッドのpure-Java実装は、ピア・ツー・ピア通信を行うための信頼性が高く移植可能な方法ですが、ソケットに大きな負荷がかかるWebLogic Serverクラスタで使用する場合には、最適なパフォーマンスを提供できません。pure-Javaソケット・リーダーを使用すると、スレッドは、ソケットにデータが入っているかどうかを調べるために、オープンしているソケットにポーリングする必要があります。つまり、ソケット・リーダー・スレッドはソケットのポーリングで常に「ビジー」となります。これはソケットがデータを持っていない場合でも変わりません。この不必要なオーバーヘッドにより、パフォーマンスが低下する可能性があります。

パフォーマンスの問題は、サーバー・インスタンスがソケット・リーダー・スレッドよりも多くのオープン・ソケットを持つとき(各リーダー・スレッドが複数のオープン・ソケットをポーリングしなければならないとき)に顕著になります。ソケット・リーダーはアクティブでないソケットに遭遇すると、別のソケットにサービスを提供する前にタイムアウトを待ちます。このタイムアウト待ちの間、図3-1に示すように、アクティブでないソケットをソケット・リーダーがポーリングする一方で、アクティブなソケットが未読のままになる場合があります。

図3-1 pure-Javaソケット・リーダー・スレッドがアクティブでないソケットをポーリングする

ソケットの最適なパフォーマンスを実現するには、pure-Java実装ではなく、オペレーティング・システムに対応したネイティブ・ソケット・リーダー実装を使用するようWebLogic Serverホスト・マシンを構成します。ネイティブ・ソケット・リーダーは、ソケット上のデータの有無を非常に効率的な手法で調べます。ネイティブ・ソケット・リーダー実装では、リーダー・スレッドはネイティブ・ソケットをポーリングする必要がなく、アクティブなソケットに対してだけサービスとして、特定のソケットがアクティブになった場合には、(割込みによって)直ちに通知されます。

注意:

アプレットはネイティブ・ソケット・リーダー実装を使用できないので、ソケット通信では十分な効果が出ません。

オペレーティング・システムに対応したネイティブ・ソケット・リーダーの実装を使用するようにWebLogic Serverホスト・マシンを構成する方法については、「サーバー・インスタンスのホスト・マシン上でネイティブのIPソケット・リーダーを構成する」を参照してください

Javaソケット実装用にリーダー・スレッドを構成する

pure-Javaソケット・リーダー実装を使用する場合は、サーバー・インスタンスごとにソケット・リーダー・スレッドの数を適切に構成することで、ソケット通信のパフォーマンスを向上できます。最適なパフォーマンスを実現するには、WebLogic Serverでのソケット・リーダー・スレッドの数を、同時にオープンするソケットの最大数に合わせる必要があります。この構成により、リーダー・スレッドが複数のソケットにサービスしなければならない状況が回避され、ソケット・データの即時読取りが保証されます。

クラスタ内のサーバー・インスタンスについて、リーダー・スレッドの適切な数を決定する方法については、次の項「ソケットの使用数を確定する」を参照してください

ソケット・リーダー・スレッドを構成する手順については、「サーバー・インスタンスのホスト・マシン上のリーダー・スレッドの数を設定する」を参照してください

ソケットの使用数を確定する

個々のWebLogic Serverインスタンスは、クラスタ内で自身を除くすべてのサーバー・インスタンスに対してソケットをオープンする可能性があります。ただし、実際に使用されるソケットの最大数は、クラスタの構成によって異なります。実際には、クラスタ化されるシステムではオブジェクトが均一に(クラスタ内の各サーバー・インスタンスに)デプロイされるため、他のどのサーバー・インスタンスに対してもソケットがオープンされないのが一般的です。

クラスタでHTTPセッション状態のインメモリー・レプリケーションを使用しており、オブジェクトを均一にデプロイする場合、図3-2に示すように、各サーバー・インスタンスが最大で2個のソケットしかオープンしない可能性があります。

図3-2 均一なデプロイメントによってソケットの必要数が最小限に抑えられる

この例の2つのソケットは、プライマリ・サーバー・インスタンスとセカンダリ・サーバー・インスタンスとの間でHTTPセッション状態をレプリケートするために使用されます。クラスタ化オブジェクトにアクセスする場合、WebLogic Serverが連結の最適化を行うために、ソケットは不要となります。(これらの最適化については、「連結されたオブジェクトの最適化」で説明されています)。この構成では、デフォルトのソケット・リーダー・スレッド構成のまま使用できます。

「固定」サービスのデプロイメント - サーバー・インスタンスは、固定オブジェクトにアクセスするために追加のソケットを開く必要があるので、一度に1つのみのサーバー上でアクティブになっている複数のサービスで、ソケット使用率が増加することがあります。(これは、固定オブジェクトにリモート・サーバー・インスタンスが実際にアクセスする場合にのみ考慮する必要があります。)図3-3は、クラスタ化されていないRMIオブジェクトをサーバーAにデプロイすることによる影響を示しています。

図3-3 クラスタ化されていないオブジェクトがソケットの潜在的な必要数を増加させる

この例では、各サーバー・インスタンスは、HTTPセッション状態をレプリケートするためと、サーバーA上の固定RMIオブジェクトにアクセスするために、最大で同時に3つのソケットをオープンする可能性があります。

注意:

「複数層アーキテクチャの構成に関する注意」で説明するように、複数層クラスタ・アーキテクチャのサーブレット・クラスタでは、さらにソケットが必要な場合があります

ソケット経由のクライアント通信

クラスタのクライアントは、ソケット・リーダー・スレッドのJava実装を使用します。

WebLogic Serverでは、Javaクライアント・アプリケーションによって開かれるIPソケットの数を削減するサーバー・アフィニティ・ロード・バランシング・アルゴリズムを構成できます。サーバー・インスタンス上の複数のオブジェクトにアクセスするクライアントが、ソケットを1つだけ使用します。オブジェクトに障害が発生した場合、クライアントはソケットがすでに開かれているサーバー・インスタンスにフェイルオーバーします(可能な場合)。WebLogic Serverの旧バージョンでは、状況によっては、クライアントはクラスタ内の各サーバー・インスタンスでソケットを開きます。

最高のパフォーマンスを引き出すには、クライアントを実行するJava仮想マシン(JVM)において十分な数のソケット・リーダー・スレッドを構成します。手順については、「クライアント・マシン上のリーダー・スレッド数を設定する」 を参照してください

クラスタ全体のJNDIネーミング・サービス

クラスタ化されないWebLogic Serverサーバー・インスタンスのクライアントは、JNDI準拠のネーミング・サービスを使用してオブジェクトとサービスにアクセスします。JNDIネーミング・サービスには、サーバー・インスタンスが提供する公開サービスの、ツリー構造のリストが含まれています。WebLogic Serverインスタンスは、そのサービスを表す名前をJNDIツリーにバインドすることによって新しいサービスを提供します。クライアントはサーバー・インスタンスに接続し、バインドされたサービス名をルックアップすることによってサービスを取得します。

クラスタ内のサーバー・インスタンスは、クラスタ全体のJNDIツリーを利用します。クラスタ全体のJNDIツリーは、ツリーが使用可能なサービスのリストを格納しているという点では、1つのサーバー・インスタンスのJNDIツリーと似ています。ただし、クラスタ全体のJNDIツリーは、ローカル・サービスの名前だけでなく、クラスタ内の他のサーバー・インスタンス上にあるクラスタ化オブジェクト(EJBやRMIクラス)が提供するサービスも格納します。

クラスタ内の各WebLogic Serverインスタンスは、クラスタ全体の論理JNDIツリーをローカルにコピーして保守します。次の項では、クラスタ全体のJNDIツリーが維持される方式と、クラスタ環境で発生しうる名前の競合を防ぐ方法について説明します。

注意:

クラスタ全体のJNDIツリーは、アプリケーション・データの永続性メカニズムまたはキャッシング・メカニズムとして使用しないでください。WebLogic Serverは、クラスタ化サーバー・インスタンスのJNDIエントリをクラスタ内の他のサーバー・インスタンスにレプリケートしますが、元のインスタンスで障害が発生すると、これらのエントリはクラスタから削除されます。また、JNDIツリー内に大きなオブジェクトを格納すると、マルチキャスト・トラフィックまたはユニキャスト・トラフィックが過負荷状態になり、クラスタの通常の処理の妨げとなる場合があります。

WebLogic Serverによるクラスタ全体のJNDIツリー作成の仕組み

クラスタ内の各WebLogic Serverは、クラスタのすべてのメンバーが提供するサービスが入ったクラスタ全体のJNDIツリーをローカルにコピーして保守します。クラスタ全体のJNDIツリーの作成では、まず各サーバー・インスタンスをローカルのJNDIツリーにバインドします。サーバー・インスタンスが起動する(または新規サービスが動作中のサーバー・インスタンスに動的にデプロイされる)と、サーバー・インスタンスはまず、それらのサービスの実装をローカルのJNDIツリーにバインドします。実装がJNDIツリーにバインドされるのは、名前が他のサービスと重複していない場合だけです。

注意:

クラスタで管理対象サーバーを起動すると、サーバー・インスタンスは、ClusterMBeanのMemberWarmupTimeoutSecondsパラメータで指定したウォームアップ時間の後で、ハートビートをリスニングしてクラスタ内で実行されている他のサーバー・インスタンスを識別します。デフォルトのウォームアップ時間は30秒です。

サーバー・インスタンスがサービスをローカルのJNDIツリーにバインドすると、レプリカ対応スタブを使用するクラスタ化オブジェクト向けに、次の手順が実行されます。クラスタ化オブジェクトの実装をローカルのJNDIツリーにバインドしたら、サーバー・インスタンスはそのオブジェクトのスタブを他のクラスタ・メンバーに送信します。クラスタの他のメンバーはマルチキャスト・アドレスまたはユニキャスト・アドレスをモニターして、リモート・サーバー・インスタンスが提供するサービスを追加したことを検出します。

図3-4は、JNDIをバインドするプロセスの一部を示しています。

図3-4 サーバーAがオブジェクトをそのJNDIツリーにバインドし、オブジェクトが使用可能であることをユニキャストする

前の図で、サーバーAはクラスタ化オブジェクトXの実装をローカルのJNDIツリーにバインドしました。オブジェクトXはクラスタ化されているので、このサービスはクラスタ内の他のすべてのメンバーに提供されます。サーバーCはオブジェクトXの実装をバインド中です。

クラスタ内でマルチキャスト・アドレスまたはユニキャスト・アドレスをリスニングしている他のサーバー・インスタンスは、サーバーAがクラスタ化オブジェクトXの新規サービスを提供し始めたことを検出します。これらのサーバー・インスタンスは、自身のローカルJNDIツリーを更新して、新規サービスをツリーに取り込みます。

ローカルのJNDIバインドは2つの方法のいずれかで更新されます。

- クラスタ化されたサービスがローカルのJNDIツリーにバインドされていない場合、サーバー・インスタンスは、サーバーA上でオブジェクトXが使用可能であることを示す新規のレプリカ対応スタブをローカル・ツリーにバインドします。サーバーBとサーバーDは自身のローカルJNDIツリーをこの方法で更新します。これらのサーバー・インスタンスにはクラスタ化オブジェクトがまだデプロイされていないためです。

- サーバー・インスタンスがクラスタ対応サービスをすでにバインドしている場合、サーバーはローカルのJNDIツリーを更新して、サービスのレプリカもサーバーA上で使用可能であることを示します。サーバーCはクラスタ化オブジェクトXをバインド済なので、自身のJNDIツリーを更新してそれを反映させます。

この方法によって、クラスタ内の各サーバー・インスタンスはククラスタ全体のJNDIツリーのコピーを独自に作成します。サーバーCが、オブジェクトXがローカルのJNDIツリーにバインドされたことを通知する場合にも、処理順序は同じです。すべてのブロードキャスト・メッセージが受信されたら、クラスタ内の各サーバー・インスタンスのローカルJNDIツリーは図3-5のように、サーバーAとサーバーC上でオブジェクトが使用可能であることを同じように示します。

図3-5 ユニキャスト・メッセージの受信後は各サーバーのJNDIツリーの内容は同じ

注意:

実際のクラスタでは、オブジェクトXは均一にデプロイされ、オブジェクトを呼び出すことのできる実装は4つのサーバー・インスタンスすべてで使用可能になります。

JNDI名の競合が発生する仕組み

単純なJNDI名の競合は、サーバー・インスタンスがJNDIツリー内にバインド済でクラスタ化されていないサービスと同じ名前を使用して、別のクラスタ化されていないサービスをバインドしようとすると発生します。クラスタ・レベルのJNDI名の競合は、サーバー・インスタンスがJNDIツリー内にバインド済でクラスタ化されていないサービスと同じ名前を使用して、クラスタ化されているオブジェクトをバインドしようとしたときに発生します。

WebLogic Serverは、ローカルのJNDIツリーにサービスをバインドするときに、(クラスタ化されていないサービスの)単純な名前の競合を検出します。クラスタ・レベルのJNDIの競合は、マルチキャストまたはユニキャストを使用して新規サービスの通知を行うときに発生します。たとえば、クラスタ内のあるサーバー・インスタンス上の固定RMIオブジェクトをデプロイする場合、同じオブジェクトでレプリカ対応のものを別のサーバー・インスタンス上にデプロイすることはできません。

クラスタ内の2つのサーバー・インスタンスが、クラスタ化された別々のオブジェクトを同じ名前を使用してバインドしようとした場合、どちらのバインドもローカルには成功します。ただし、JNDI名の競合が発生するので、各サーバー・インスタンスでは、他のサーバー・インスタンスのレプリカ対応スタブをJNDIツリーにバインドすることはできません。このタイプの競合は、2つのサーバー・インスタンスのどちらかが終了するか、どちらかのサーバー・インスタンスが競合の原因となったクラスタ化オブジェクトをアンデプロイするまで解決しません。これと同じ競合は、固定オブジェクトを両方のサーバー・インスタンスが同じ名前でデプロイしようとした場合にも発生します。

均一なデプロイメントによってクラスタ・レベルのJNDIの競合を回避する

クラスタ・レベルのJNDIの競合を回避するには、すべてのレプリカ対応オブジェクトを、クラスタ内のすべてのWebLogic Serverインスタンスに均一にデプロイする必要があります。デプロイメントがWebLogic Serverインスタンス間でバランスを欠いていると、起動時または再デプロイメント時にJNDI名の競合が発生する可能性が高まります。また、クラスタ内の処理負荷のバランスも取れなくなることがあります。

特定のRMIオブジェクトまたはEJBを個々のサーバー・インスタンスに固定する必要がある場合は、そのオブジェクトのバインドをクラスタ間でレプリケートしないようにします。

WebLogic ServerによるJNDIツリー更新の仕組み

クラスタ化オブジェクトが削除(サーバー・インスタンスからアンデプロイ)されるとき、JNDIツリーの更新は、新規サービスの追加時に行われる更新と似た方法で処理されます。アンデプロイされたサービスがあったサーバー・インスタンスは、そのサービスが提供されなくなったことを示すメッセージをブロードキャストします。すでに説明したように、マルチキャスト・メッセージまたはユニキャスト・メッセージを監視しているクラスタ内の他のサーバー・インスタンスは、JNDIツリーのローカル・コピーを更新して、オブジェクトをアンデプロイしたサーバー・インスタンス上でそのサービスが使用できなくなったことを反映させます。

クライアントがレプリカ対応スタブを取得すると、クラスタ内のサーバー・インスタンスは、クラスタ化オブジェクトのホスト・サーバーの追加と削除を続行できます。JNDIツリー内の情報が変更されると、クライアントのスタブも更新されます。その後のRMIリクエストには、クライアントのスタブが常に最新の情報を持つように、必要に応じて更新情報が含まれます。

クライアントとクラスタ全体のJNDIツリーとの対話

WebLogic Serverクラスタに接続してクラスタ化オブジェクトをルックアップするクライアントは、そのオブジェクトのレプリカ対応スタブを取得します。このスタブには、そのオブジェクトの実装のホストとして使用可能なサーバー・インスタンスのリストが入っています。スタブには、ホスト・サーバー間で負荷を分散するためのロード・バランシング・ロジックも含まれています。

EJBおよびRMIクラス用のレプリカ対応スタブの詳細は、「EJBとRMIのレプリケーションとフェイルオーバー」を参照してください

WebLogic JNDIがクラスタ環境に実装される仕組み、およびユーザー固有のオブジェクトをJNDIクライアントで使用可能にする方法については、『Oracle WebLogic Server JNDIアプリケーションの開発』のクラスタ環境でのWebLogic JNDIの使用方法に関する項を参照してください。

4 クラスタの構成の理解

この章では、クラスタの構成を定義する情報が格納および保持される仕組みと、構成作業を実施するために使用できる方法について説明します。

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

- クラスタの構成とconfig.xml

- 管理サーバーの役割

- 動的構成の仕組み

- クラスタ化構成でのアプリケーションのデプロイメント

- クラスタを構成する方法

注意:

この章の情報の多くは、サーバー・インスタンスがクラスタ化されていないWebLogicドメインの構成プロセスに関連するものです。

クラスタの構成とconfig.xml

config.xmlファイルは、WebLogic Serverドメインの構成を記述したXMLドキュメントです。config.xmlは、一連のXML要素で構成されます。Domain要素はトップレベルの要素であり、Domain内のすべての要素はDomain要素の子孫です。Domain要素には、Server、Cluster、Applicationなどの子要素があります。子要素の中にさらに子要素がある場合もあります。たとえば、Server要素には、子要素としてWebServer、SSL、およびLogがあります。Application要素にはEJBComponentとWebAppComponentという子要素があります。

各要素には、1つ以上の構成可能な属性があります。config.dtdに定義されている属性には、構成APIに対応する属性があります。たとえば、Server要素にはListenPort属性があり、同様に、weblogic.management.configuration.ServerMBeanにもListenPort属性があります。構成可能な属性は読取り可能かつ書込み可能であり、言い換えると、ServerMBeanにはgetListenPortメソッドとsetListenPortメソッドがあります。

config.xmlの詳細は、『Oracle WebLogic Serverドメイン構成の理解』のドメイン構成ファイルに関する項を参照してください。

管理サーバーの役割

管理サーバーは、そのドメイン内のWebLogic Serverインスタンス群を構成および管理するWebLogic Serverインスタンスです。

ドメインには複数のWebLogic Serverクラスタと、クラスタ化されないWebLogic Serverインスタンスが存在できます。厳密に言うと、ドメインは1つのWebLogic Serverインスタンスだけでも構成できます。ただしその場合、各ドメインには必ず1つの管理サーバーが存在しなければならないため、その唯一のサーバー・インスタンスが管理サーバーになります。

「クラスタを構成する方法」で説明されているように、管理サーバーのサービスを呼び出して構成タスクを実施する方法はいくつかありますどの方法を使用する場合でも、構成を修正するときはクラスタの管理サーバーが稼働している必要があります。

管理サーバーが起動すると、ドメインのconfig.xmlがロードされます。config.xmlは、次のディレクトリで検索されます。

ORACLE_HOME/user_projects/domains/domain_name/config

domain_nameはドメインに固有のディレクトリで、その名前はドメインと同じです。

管理サーバーが正常に起動するたびに、config.xml.bootedという名前のバックアップ構成ファイルがドメイン・ディレクトリに作成されます。サーバー・インスタンスの存続期間中に万一config.xmlファイルが破損した場合、このファイルを使用して以前の構成に戻すことができます。

図4-1は、1つの管理サーバーと複数のWebLogic Serverインスタンスで構成される典型的な本番環境を示しています。このようなドメインでサーバー・インスタンスを起動すると、まず管理サーバーが起動します。その他の各サーバー・インスタンスは、起動時に管理サーバーにアクセスしてその構成情報を取得します。このように、管理サーバーはドメイン全体の構成の一元的な制御エンティティとして動作します。

図4-1 WebLogic Serverの構成

管理サーバーに障害が発生した場合

ドメインの管理サーバーで障害が発生しても、ドメイン内の管理対象サーバーの動作には影響しません。管理対象のサーバー・インスタンスが(クラスタ化されているかいないかには関係なく)動作しているときにドメインの管理サーバーが使用できなくなっても、その管理対象サーバーは処理を続けます。ドメインにクラスタ化サーバー・インスタンスがある場合は、管理サーバーに障害が発生しても、ドメイン構成でサポートされているロード・バランシングおよびフェイルオーバー機能を使用できます。

注意:

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

管理サーバーを再起動する手順は、『Oracle WebLogic Serverサーバーの起動と停止の管理』のサーバー障害のリカバリとサーバー障害からのリカバリに関する項を参照してください。

動的構成の仕組み

WebLogic Serverでは、ドメイン・リソースの構成属性を動的に(サーバー・インスタンスの動作中に)変更できます。ほとんどの場合では、変更を有効にするためにサーバー・インスタンスを再起動する必要はありません。属性を構成し直すと、新しい値は、実行時の現在の属性値と、config.xmlに格納されている永続的な値の両方に直ちに反映されます。

構成へのすべての変更が動的に適用されるわけではありません。たとえば、管理対象サーバーのListenPort値を変更した場合、新しいポートは管理対象サーバーを次に起動するまで使用されません。更新された値はconfig.xmlに保存されますが、実行時の値は影響を受けません。

WebLogic Server管理コンソールは、範囲外エラーやデータ型の不一致エラーをチェックして属性の変更を検証し、エラーがあるエントリではエラー・メッセージを表示します。

WebLogic Server管理コンソールの起動後に、管理サーバーに割り当てられたリスニング・ポートを別のプロセスが獲得した場合、ポートを獲得したプロセスを停止することをお薦めします。リスニング・ポートを獲得したプロセスを削除できない場合、config.xmlファイルを編集して、ListenPort値を変更します。

クラスタ化された構成でのアプリケーションのデプロイメント

この項では、アプリケーションのデプロイメント・プロセスについて簡単に説明します。デプロイメントの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。

一般的なデプロイメント・タスクの実行手順については、「アプリケーションをデプロイする」 を参照してください

デプロイメント方法

次の方法を使用して、クラスタにアプリケーションをデプロイできます。

- WebLogic Server管理コンソール
WebLogic Server管理コンソールは管理サービスにアクセスするためのグラフィカル・ユーザー・インタフェース(GUI)です。

- weblogic.Deployer
weblogic.Deployerユーティリティは、WebLogic ServerデプロイメントAPIにコマンド行インタフェースを提供するJavaベースの開発ツールです。

- WebLogic Scripting Tool
WebLogic Scripting Tool (WLST)は、アプリケーションのデプロイメント構成やデプロイメント操作などドメインの構成タスクの自動化に使用できるコマンド行インタフェースです。

これらのデプロイメント・ツールは、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のデプロイメント・ツールに関する項で説明されています。

使用するデプロイメント・ツールに関係なく、デプロイメント・プロセスを開始するときは、デプロイするコンポーネントとデプロイ先のターゲット(クラスタ、またはクラスタかドメイン内の個々のサーバー・インスタンス)を指定します。

プロセスの間、ドメインの管理サーバーはクラスタ内の管理対象サーバーと通信しながらデプロイメント・プロセスを管理します。各管理対象サーバーはデプロイするコンポーネントをダウンロードし、ローカルのデプロイメント・タスクを開始します。デプロイメント状態は、デプロイされるコンポーネントの関連するMBeanに保持されます。詳細は、デプロイメント管理APIを参照してください。

注意:

WebLogic Serverにデプロイする前にアプリケーションをパッケージ化する必要があります。詳細は、『Oracle WebLogic Serverアプリケーションの開発』の分割開発ディレクトリからのデプロイとパッケージ化に関する項にあるパッケージ化に関するトピックを参照してください。

2フェーズ・デプロイメントの概要

WebLogic Serverでは、アプリケーションは2つのフェーズでデプロイされます。開始前に、WebLogic Serverはクラスタ内の管理対象サーバーが使用可能かどうかを判断します。

デプロイメントの第1フェーズ

デプロイメントの第1フェーズでは、アプリケーション・コンポーネントがターゲット・サーバー・インスタンスに配布されます。アプリケーション・コンポーネントが正常にデプロイされるように、計画されたデプロイメントが検証されます。このフェーズでは、デプロイされるアプリケーションへのユーザー・リクエストは許可されません。

配布および検証プロセス中に障害が発生した場合は、検証が成功したインスタンスも含めて、すべてのサーバー・インスタンス上でデプロイメントが中止されます。ステージングされたファイルは削除されませんが、準備中に実行されたコンテナ側の変更は元に戻されます。

デプロイメントの第2フェーズ

アプリケーション・コンポーネントは、ターゲットに配布されて検証された後で、ターゲット・サーバー・インスタンス上に完全にデプロイされます。デプロイされたアプリケーションはクライアントから使用できるようになります。

デプロイメントの第2フェーズ中に障害が発生した場合、サーバーは次のいずれかの動作で起動します。

- ターゲット・サーバー・インスタンスへのデプロイ中に失敗した場合は、サーバー・インスタンスがADMIN状態で起動します。『Oracle WebLogic Serverサーバーの起動と停止の管理』のADMIN状態に関する項を参照してください。

- クラスタ・メンバーがアプリケーションのデプロイに失敗した場合は、デプロイできなかったアプリケーションが使用不可能になります。

クラスタへのデプロイメントのガイドライン

デプロイメント・プロセス中は、クラスタ内のすべての管理対象サーバーが実行中で使用可能になっていることが理想的です。クラスタ内の一部のメンバーが使用できないときにアプリケーションをデプロイすることはお薦めしません。クラスタにアプリケーションをデプロイする前に、可能であれば、クラスタ内のすべての管理対象サーバーを実行し、管理サーバーからアクセスできるようにしておきます。

注意:

デプロイメント時に分断された管理対象サーバー(実行中だが管理サーバーからアクセスできない状態)にアプリケーションをデプロイすると、その管理対象サーバーがクラスタに復帰するときに、管理対象サーバーへのアクセスについて問題が発生する可能性があります。同期化期間中、クラスタ化された他の管理対象サーバーが以前に分断されたサーバー・インスタンスとの通信を再確立している間、デプロイ済アプリケーションへのユーザー・リクエストや、そのサーバー・インスタンスでのセカンダリ・セッションの作成は失敗します。ClusterConstraintsEnabledを設定することで、この状況が発生するリスクを減らせます。詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のすべての構成済クラスタ・メンバーへの一貫性のあるデプロイメントの実施に関する項を参照してください。

デプロイメント・プロセス中はクラスタ・メンバーシップを変更しないでください。デプロイメント開始後は、次の操作を行わないでください。

- 対象のクラスタへの管理対象サーバーの追加または削除

- 対象のクラスタ内の管理対象サーバーの停止

WebLogic Serverがサポートする「緩和されたデプロイメント」ルール

以前のバージョンのWebLogic Serverでは、クラスタへのデプロイメントに関して次の制限が課せられていました:

- 部分的なデプロイメントの禁止 - クラスタ内の1つまたは複数の管理対象サーバーが使用できない場合、デプロイメント・プロセスは終了し、デプロイメントを試行する前に、アクセスできない管理対象サーバーを再起動するか、クラスタから削除することを指示するエラー・メッセージが生成されます。

- 固定サービスはクラスタ内の複数の管理対象サーバーにデプロイできない - あるアプリケーションがクラスタにデプロイされていない場合、そのアプリケーションはクラスタ内の1つの管理対象サーバーにのみデプロイできます。

部分的なクラスタへのデプロイメントの許可

デフォルトでは、WebLogic Serverは部分的なクラスタへのデプロイメントを許可します。クラスタ内の1つまたは複数の管理対象サーバーが使用できない場合は、次のメッセージが表示されます。

Unable to contact "servername". Deployment is deferred until "servername" becomes available.

アクセスできない管理対象サーバーが使用可能になると、そのサーバー・インスタンスへのデプロイメントが開始されます。デプロイメント・プロセスが完了するまで、管理対象サーバーでは、クラスが見つからない、またはクラスが古いなどのエラーが発生する可能性があります。

WebLogic Serverの完全なクラスタへのデプロイメント

ClusterConstraintsEnabledを設定すると、クラスタ内のすべての管理対象サーバーがアクセス可能な場合にのみデプロイメントが実行されるようにできます。ClusterConstraintsEnabledを「true」に設定すると、クラスタ内のすべてのメンバーがアクセス可能で、指定したファイルをデプロイできる場合のみクラスタへのデプロイメントが成功します。詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のすべての構成済クラスタ・メンバーへの一貫性のあるデプロイメントの実施に関する項を参照してください。

固定サービスを複数の管理対象サーバーにデプロイ可能

固定サービスはクラスタ内の複数の管理対象サーバーにターゲット指定できます。この実践はお薦めしません。固定サービスをクラスタ内の複数の管理対象サーバーにデプロイすると、クラスタのロード・バランシング機能とスケーラビリティが悪影響を受ける可能性があります。固定サービスを複数の管理対象サーバーにターゲット指定すると、次のメッセージがサーバー・ログに出力されます。

Adding server servername of cluster clustername as a target for
module modulename. This module also includes server servername that
belongs to this cluster as one of its other targets. Having multiple
individual servers in a cluster as targets instead of having the entire
cluster as the target can result in non-optimal load balancing and
scalability. Hence this is not usually recommended.

クラスタを構成する方法

クラスタを構成するにはいくつかの方法があります。

- 構成ウィザード
新しいドメインやクラスタを作成するには、構成ウィザードを使用することをお薦めします。詳細は、『構成ウィザードによるWebLogicドメインの作成』の概要に関する項を参照してください。クラスタの作成と構成の詳細は、「クラスタ」を参照してください。

- WebLogic Server管理コンソール
WebLogic Server管理コンソールは管理サービスにアクセスするためのグラフィカル・ユーザー・インタフェース(GUI)です。コンソールからは、各種のドメイン構成およびモニター機能を実行できます。

- WebLogic Serverアプリケーション・プログラミング・インタフェース(API)
WebLogic Serverに付属する構成APIに基づいて、構成属性を変更するプログラムを記述することができます。この方法は、初期のクラスタ実装に対してはお薦めできません。

- WebLogic Scripting Tool (WLST)
WebLogic Scripting Tool (WLST)はコマンドライン・スクリプト・インタフェースです。システム管理者およびオペレータは、このインタフェースでWebLogic Serverのインスタンスやドメインの監視と管理を行います。詳細は、『WebLogic Scripting Toolの理解』を参照してください。

- Java Management Extensions (JMX)
JMXは、ネットワーク上のリソースをモニターおよび管理するためのJava EEソリューションです。WebLogic Serverには、JMXを使用してWebLogic Serverリソースを構成、モニター、および管理するための様々なMBeanが用意されています。

5 クラスタでのロード・バランシング

この章では、各種のオブジェクトを対象としたWebLogic Serverクラスタでのロード・バランシングのサポートについて説明し、設計者および管理者向けに、ロード・バランシングに関連する計画および構成上の考慮事項を示します。

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

- サーブレットとJSPのロード・バランシング

- EJBとRMIオブジェクトのロード・バランシング

- JMSのロード・バランシング

クラスタのレプリケーションとフェイルオーバーについては、「クラスタのフェイルオーバーとレプリケーション」を参照してください

サーブレットとJSPのロード・バランシング

サーブレットとJSPのロード・バランシングは、WebLogicプロキシ・プラグインに組み込まれたロード・バランシング機能を使用するか、またはロード・バランシング・ハードウェアを別途用意することによって実現できます。

注意:

HTTPトラフィックの分散に加えて、外部ロード・バランサは、t3とデフォルト・チャネルを介したJavaクライアントからの初期コンテキスト・リクエストを分散できます。WebLogic Serverでのオブジェクト・レベルのロード・バランシングについては、「EJBとRMIオブジェクトのロード・バランシング」を参照してください。

プロキシ・プラグインによるロード・バランシング

WebLogicプロキシ・プラグインは、クラスタ化されたサーブレットまたはJSPのホストであるWebLogic Serverインスタンスのリストを保持し、ラウンドロビン方式でHTTPリクエストをそれらのインスタンスに転送します。このロード・バランシング・メソッドは、「ラウンドロビン・ロード・バランシング」 で説明します

このプラグインは、WebLogic Serverインスタンスで障害が発生した場合に、クライアントのHTTPセッション状態のレプリカを見つけるために必要なロジックも備えています。

WebLogic Serverは、次のWebサーバーおよび関連プロキシ・プラグインをサポートしています。

- WebLogic ServerとHttpClusterServlet

- Netscape Enterprise ServerとNetscape (プロキシ)プラグイン

- ApacheとApache Server (プロキシ)プラグイン

- Microsoft Internet Information ServerとMicrosoft-IIS (プロキシ)プラグイン

プロキシ・プラグインの設定方法については、「プロキシ・プラグインを構成する」 を参照してください

プロキシ・プラグインによるセッションの接続とフェイルオーバーの仕組み

プロキシ・プラグインによるクラスタ内のHTTPセッションの接続およびフェイルオーバーの詳細は、「クラスタ化されたサーブレットとJSPへのプロキシ経由のアクセス」を参照してください

外部ロード・バランサによるHTTPセッションのロード・バランシング

ハードウェアによるロード・バランシング・ソリューションを利用するクラスタでは、ハードウェアが対応しているすべてのロード・バランシング・アルゴリズムを利用できます。この中には、個々のマシンの利用状況をモニターする負荷ベースの高度なバランシング戦略を採用しているものもあります。

ロード・バランサの構成要件

プロキシ・プラグインではなくロード・バランシング・ハードウェアを使用する場合、互換性のあるパッシブまたはアクティブなCookieの永続性メカニズムと、SSLの永続性にハードウェアが対応している必要があります。

- パッシブなCookieの永続性
パッシブなCookieの永続性を使用すると、WebLogic Serverは、ロード・バランサを介したクライアントへのセッション・パラメータ情報を含むCookieを記述できます。セッションCookieの詳細、およびロード・バランサがセッション・パラメータ・データを使用して、HTTPセッション状態をホストするプライマリWebLogic Serverとクライアントの関係を保持する仕組みについては、「ロード・バランサとWebLogicセッションCookie」を参照してください

- アクティブなCookieの永続性
ロード・バランサがWebLogic Server Cookieを変更しないのであれば、特定のアクティブなCookieの永続性メカニズムをWebLogic Serverクラスタで使用することもできます。WebLogic Serverクラスタでは、WebLogic HTTPセッションCookieを上書き、または変更するアクティブなCookieの永続性メカニズムはサポートされていません。ロード・バランサのアクティブなCookieの永続性メカニズムは、クライアント・セッションに独自のCookieを追加することによって機能する場合は、WebLogic Serverクラスタでロード・バランサを使用する際に、新たな構成は不要です。

- SSL永続性
SSL永続性を使用する場合、クライアントとWebLogic Serverクラスタの間でのデータの暗号化および復号化は、すべてロード・バランサが行います。そして、ロード・バランサは、WebLogic Serverがクライアントに挿入したプレーン・テキストのCookieを使用して、クライアントとクラスタ内の特定サーバー間の関連付けを維持します。

ロード・バランサとWebLogicセッションCookie

パッシブなCookieの永続性を使用するロード・バランサは、WebLogicセッションCookieに文字列を使用することで、クライアントをそのプライマリHTTPセッション状態のホストになるサーバーに関連付けることができます。文字列は、クラスタ内のサーバー・インスタンスを一意に識別します。ロード・バランサを構成する際に、文字列定数のオフセットと長さを指定する必要があります。オフセットと長さの正しい値は、セッションCookieの形式によって異なります。

セッションCookieの形式は次のとおりです。

sessionid!primary_server_id!secondary_server_id

説明:

- sessionidは、HTTPセッションの識別子で、ランダムに生成されます。値の長さは、アプリケーションのweblogic.xmlファイルの<session-descriptor要素にあるIDLengthパラメータで構成されます。デフォルトでは、sessionidの長さは52バイトです。

- primary_server_idとsecondary_server_idは、セッションのプライマリ・ホストとセカンダリ・ホストの10文字の識別子です。

注意:

非レプリケート・メモリー、Cookieまたはファイル・ベースのセッション永続性を使用するセッションの場合、secondary_server_idはありません。インメモリー・レプリケーションを使用するセッションで、2番目のセッションが存在しない場合は、secondary_server_idは「NONE」になります。

ロード・バランサの一般的な構成手順については、「パッシブなCookieの永続性をサポートするロード・バランサを構成する」を参照してくださいBIG-IPの構成手順については、「クラスタに関するBIG-IPハードウェアの構成」を参照してください

関連するプログラミングの考慮事項

クラスタ化されるサーブレットおよびJSPを対象とした、プログラミング上の制約および考慮事項については、「クラスタ化されるサーブレットおよびJSPのプログラミング上の考慮事項」を参照してください

ロード・バランサでのセッション接続およびフェイルオーバーの仕組み

ロード・バランシング・ハードウェアによるクラスタ内のHTTPセッションの接続およびフェイルオーバーの詳細は、「クラスタ化されたサーブレットとJSPへのロード・バランシング・ハードウェアを利用したアクセス」を参照してください

EJBとRMIオブジェクトのロード・バランシング

この項では、EJBとRMIオブジェクトのWebLogic Serverロード・バランシング・アルゴリズムについて説明します。

オブジェクトのロード・バランシング・アルゴリズムは、クラスタ化オブジェクトで取得されるレプリカ対応スタブに保持されます。

デフォルトでは、WebLogic Serverクラスタはラウンドロビン・ロード・バランシングを使用します(「ラウンドロビン・ロード・バランシング」を参照)。WebLogic Server管理コンソールを使用してweblogic.cluster.defaultLoadAlgorithmを設定することで、クラスタで別のデフォルトのロード・バランシング・メソッドを構成できます。手順については、「EJBとRMIのロード・バランシング方式を構成する」 を参照してくださいまた、rmicの-loadAlgorithmオプションを使用するか、またはEJBのデプロイメント記述子のhome-load-algorithmまたはstateless-bean-load-algorithmを使用して、特定のRMIオブジェクト用のロード・バランシング・アルゴリズムを指定できます。オブジェクトに構成したロード・バランシング・アルゴリズムは、クラスタのデフォルトのロード・バランシング・メソッドをオーバーライドします。

標準のロード・バランシング・アルゴリズムだけでなく、WebLogic Serverではパラメータ・ベースのカスタム・ルーティングもサポートされます。詳細は、「クラスタ化オブジェクトのパラメータ・ベースのルーティング」を参照してください

また、外部ロード・バランサはt3およびデフォルト・チャネル全体のJavaクライアントからの初期コンテキスト・リクエストを分散できます。ただし、EJBおよびRMIオブジェクトのWebLogic Serverロード・バランシングは、サーバー・アフィニティが採用される状況を含むレプリカ認識スタブ経由で制御されるため、初期コンテキスト・リクエストに続いてロード・バランサを通してクライアント・リクエストをルーティングしません。外部ロード・バランサとt3プロトコルを併用するとき、初期コンテキスト・リクエストのみがロード・バランサを通してルーティングされ、後続のリクエストがWebLogic Serverのロード・バランシングを使用してルーティングおよび制御されていることを確認する必要があります。

t3sプロトコルと外部ロード・バランサの併用はお薦めしません。t3やSSLを外部ロード・バランサと併用する必要がある場合、HTTPSを介したt3トンネリングの使用をお薦めします。サーバー・アフィニティが必要な場合、リクエストのルーティングには必ずHTTPセッションIDを使用し、セッションIDに基づいてリクエストの適切なルーティングを可能にするためのセッション・ベースのルーティングを実行するロード・バランサでは、SSLを終了する必要があります。

ラウンドロビン・ロード・バランシング

WebLogic Serverは、特定のアルゴリズムが指定されていない場合には、クラスタ化オブジェクト・スタブのロード・バランシング戦略としてデフォルトでラウンドロビン・アルゴリズムを使用します。このアルゴリズムは、RMIオブジェクトおよびEJB用にサポートされています。また、WebLogicプロキシ・プラグインで使用される手法でもあります。

このアルゴリズムは、WebLogic Serverインスタンスのリストを順番に循環します。クラスタ化オブジェクトの場合、サーバー・リストはそのオブジェクトのホストとなるWebLogic Serverインスタンスからなります。プロキシ・プラグインの場合、リストは、クラスタ化されたサーブレットまたはJSPのホストとなるすべてのWebLogic Serverインスタンスからなります。

ラウンドロビン・アルゴリズムの長所は、シンプルで、動作コストの面で有利で、非常に予測しやすいということです。主な短所は、コンボイの可能性が若干あることです。コンボイは、あるサーバーがその他のサーバーよりも著しく速度が低下したときに発生します。レプリカ対応スタブまたはプロキシは同じ順序でサーバーにアクセスするので、速度の遅いサーバーがあると、リクエストがそのサーバー上で「同期」するため、その他のサーバーが将来のリクエストに備えて停滞する可能性があります。

注意:

WebLogic Serverでは、オブジェクトのメソッド呼出しに対して常にロード・バランシングが実行されるわけではありません。詳細は、「連結されたオブジェクトの最適化」を参照してください

重みベースのロード・バランシング

このアルゴリズムは、EJBおよびRMIオブジェクトのクラスタリングだけに適用されます。

重みベース・ロード・バランシングは、ラウンドロビンアルゴリズムを向上させたもので、各サーバーにあらかじめ割り当てられた重みを考慮します。WebLogic Server管理コンソールの「サーバー」→「構成」→「クラスタ」ページを使用して、「クラスタの重み」フィールドで1から100の数値を設定してクラスタ内の各サーバーに重みを割り当てることができます。この値は、他のサーバーとの比較で、あるサーバーにかかる負荷の割合を決定します。すべてのサーバーの重みが同じ場合、各サーバーには等しい割合の負荷がかかります。1つのサーバーの重みが50で、他のすべてのサーバーの重みは100の場合、重み50があるサーバーに他のサーバーにかかる負荷の半分の負荷がかかります。このアルゴリズムを使用すると、均一でないクラスタにラウンドロビン・アルゴリズムの利点をもたらすことができます。

重みベースのアルゴリズムを使用する場合、各サーバー・インスタンスに割り当てる相対的な重みを慎重に決定してください。考慮すべき要因には、次のものがあります。

- 他のサーバーと比較したサーバーのハードウェアの処理能力(WebLogic Server専用のCPUの数と性能など)

- 各サーバーをホストとする、クラスタ化されていない(「固定された」)オブジェクトの数

サーバーに指定した重みを変更してサーバーを再起動すると、レプリカ対応スタブ経由で新しい重みの情報がクラスタ全体に伝播されます。詳細は、「クラスタ全体のJNDIネーミング・サービス」を参照してください

注意:

WebLogic Serverでは、オブジェクトのメソッド呼出しに対して常にロード・バランシングが実行されるわけではありません。詳細は、「連結されたオブジェクトの最適化」を参照してください

このバージョンのWebLogic Serverでは、RMI/IIOPプロトコルを使用して通信するオブジェクトに対して、重みベースのロード・バランシングはサポートされていません。

ランダム・ロード・バランシング

ランダム方式のロード・バランシングは、EJBおよびRMIオブジェクトのクラスタリングにのみ適用されます。

ランダム・ロード・バランシングでは、リクエストは無作為にサーバーに振り分けられます。ランダム・ロード・バランシングは、同様の構成がなされたマシン上で各サーバー・インスタンスが動作する、均一なクラスタ・デプロイメント環境でのみ推奨されます。リクエストを無作為に割り当てる方式では、サーバー・インスタンスが動作するマシン間で処理能力に差があることは問題となります。クラスタ内でサーバーをホストしているマシンの処理能力が、クラスタ内の他のマシンよりも著しく劣っているような場合、ランダム・ロード・バランシングによって、より強力なマシンに割り当てられるのと同じ分量のリクエストが能力の低いマシンに割り当てられてしまいます。

ランダム・ロード・バランシングでは、クラスタ内のサーバー・インスタンス間で均等にリクエストが分配され、累計のリクエスト数の増加とともに個別の分配量も増します。リクエストの数が少ない場合、負荷は厳密には均等に配分されない場合があります。

ランダム・ロード・バランシングの欠点としては、リクエストごとにランダムな番号を生成するため、プロセスに多少のオーバーヘッドが発生するということがあります。また、リクエストの数が少ない場合は、負荷が均等に分散されない可能性もあります。

注意:

WebLogic Serverでは、オブジェクトのメソッド呼出しに対して常にロード・バランシングが実行されるわけではありません。詳細は、「連結されたオブジェクトの最適化」を参照してください

サーバー・アフィニティ・ロード・バランシング・アルゴリズム

WebLogic Serverでは、サーバー・アフィニティ を実現する、RMIオブジェクトの新しい3つのロード・バランシング・アルゴリズムが提供されています。サーバー・アフィニティは外部クライアント接続のロード・バランシングを無効にしますが、そのかわりに、クライアント側でオブジェクトにアクセスするサーバー・インスタンスを選択するときにWebLogic Serverインスタンスとの既存の接続が尊重されます。オブジェクトがサーバー・アフィニティ対応に構成されている場合、クライアント側スタブではすでに接続されているサーバー・インスタンスを選択しようとし、メソッド呼出しに同じサーバー・インスタンスを使い続けます。そのクライアントのすべてのスタブが同じサーバー・インスタンスを使用しようとします。そのサーバー・インスタンスが利用不可になると、スタブはクライアントがすでに接続しているサーバー・インスタンスに可能であればフェイルオーバーします。

サーバー・アフィニティの目的は、外部Javaクライアントとクラスタ内のサーバー・インスタンスの間で開かれるIPソケットの数を最小限に抑えることです。WebLogic Serverはそのために、利用可能なサーバー・インスタンスの間でロード・バランシングを行うのではなく、オブジェクトに対するメソッド呼出しを既存の接続に「固定」します。サーバー・アフィニティ・アルゴリズムを使用する場合でも、低コストのサーバー間接続は構成されているロード・バランシング・アルゴリズムに従ってロード・バランシングされます。ロード・バランシングが無効になるのは、外部クライアント接続だけです。

サーバー・アフィニティは、標準のロード・バランシング方法(ラウンドロビン、重みベース、ランダム)のいずれか1つと組み合わせて使用されます。

- ラウンドロビン・アフィニティ - サーバー・アフィニティが外部Javaクライアントとサーバー・インスタンスの接続を管理します。ラウンドロビン・ロード・バランシングがサーバー・インスタンス間の接続に使用されます。

- 重みベース・アフィニティ - サーバー・アフィニティが外部Javaクライアントとサーバー・インスタンスの接続を管理し、重みベース・ロード・バランシングがサーバー・インスタンス間の接続に使用されます。

- ランダム・アフィニティ - サーバー・アフィニティが外部Javaクライアントとサーバー・インスタンスの接続を管理し、ランダム・ロード・バランシングがサーバー・インスタンス間の接続に使用されます。

サーバー・アフィニティと初期コンテキスト

クライアントは、クラスタ内の特定のサーバー・インスタンスまたはクラスタ(URLでクラスタのアドレスを指定)から初期コンテキストを取得できます。接続プロセスは、コンテキストの取得方法によって異なります。

- 初期コンテキストを特定の管理対象サーバーからリクエストする場合、コンテキストは指定されたサーバー・インスタンスとの新しい接続を使用して取得されます。

- 初期コンテキストをクラスタから取得する場合、デフォルトで、コンテキスト・リクエストはクラスタ化サーバー・インスタンスの間でラウンドロビンに基づいてロード・バランシングされます。特定のJVMとクラスタ間の既存の接続を再利用するには、コンテキストを取得するときに指定するweblogic.jndi.WLContextプロパティのハッシュ表でENABLE_SERVER_AFFINITYをtrueに設定します。(利用可能な接続がない場合は、新しい接続が作成されます。)ENABLE_SERVER_AFFINITYは、コンテキストをクラスタのアドレスから取得する場合のみサポートされています。

サーバー・アフィニティとCSIv2を使用したIIOPクライアント認証

WebLogic ServerのCSIv2 (Common Secure Interoperability)機能を使用してWebLogic ServerのJava EEアプリケーション・クライアント(「シン・クライアント」)とのステートフルな対話をサポートする場合は、アフィニティ・ベースのロード・バランシング・アルゴリズムを使用して、メソッド呼出しがサーバー・インスタンスに固定されるようにする必要があります。そうしないと、すべてのリモート呼出しが認証されます。ステートフルなCSIv2クライアントの冗長な認証を防ぐには、「ラウンドロビン・アフィニティ、重みベース・アフィニティおよびランダム・アフィニティ」で説明するロード・バランシング・アルゴリズムのいずれかを使用します。

ラウンドロビン・アフィニティ、重みベース・アフィニティ、およびランダム・アフィニティ

サーバー・アフィニティを実現するWebLogic Serverの3つのロード・バランシング・アルゴリズムは次のとおりです。

- ラウンドロビン・アフィニティ

- 重みベース・アフィニティ

- ランダム・アフィニティ

サーバー・アフィニティは、JMSオブジェクト、すべてのEJBホーム・インタフェース、およびステートレスEJBリモート・インタフェースを含むあらゆるタイプのRMIオブジェクトでサポートされています。

サーバー・アフィニティ・アルゴリズムでは、WebLogic Serverインスタンス間のクライアント負荷をロード・バランシングするときに外部Javaクライアントとサーバー・インスタンス間の既存の接続が尊重されます。サーバー・アフィニティは:

- 外部Javaクライアントとサーバー・インスタンス間のロード・バランシングを無効にします

- 外部Javaクライアントからのメソッド呼出しを接続がすでに開かれているサーバー・インスタンスに固定します(その接続で必要なプロトコルとQOSがサポートされているものと見なします)

- 障害が発生したときには、接続がすでに開かれているサーバー・インスタンスにクライアントがフェイルオーバーされるようにします(その接続で必要なプロトコルとQOSがサポートされているものと見なします)

- サーバー間の接続で実行されるロード・バランシングに影響しません

サーバー・アフィニティの例

次の例は、様々な環境でのサーバー・アフィニティの影響を示しています。各例で、デプロイされているオブジェクトはラウンドロビン・アフィニティ対応に構成されています。

例1: クラスタからコンテキスト取得

図5-1の例では、クライアントがクラスタからコンテキストを取得します。コンテキストのルックアップとオブジェクトの呼出しは1つの接続に固定されます。新しい初期コンテキストのリクエストは、ラウンドロビンに基づいてロード・バランシングされます。

図5-1 クラスタからコンテキストを取得するクライアント

1. クライアントがクラスタに新しい初期コンテキストをリクエストし(Provider_URL=clusteraddress)、MS1からコンテキストを取得します。

2. クライアントがそのコンテキストでオブジェクトAをルックアップします。そのルックアップはMS1へ向かいます。

3. クライアントがオブジェクトAに呼出しを発行します。その呼出しは、クライアントがすでに接続しているMS1に向かいます。オブジェクトAに対する以降のメソッド呼出しはMS1に固定されます。

4. クライアントがクラスタに新しい初期コンテキストをリクエストし(Provider_URL=clusteraddress)、MS2からコンテキストを取得します。

5. クライアントがそのコンテキストでオブジェクトBをルックアップします。呼出しは、クライアントがすでに接続されているMS2に向かいます。オブジェクトBに対する以降のメソッド呼出しはMS2に固定されます。

例2 - サーバー・アフィニティとフェイルオーバー

図5-2の例は、サーバー・アフィニティがオブジェクトのフェイルオーバーに与える影響を示しています。管理対象サーバーがダウンすると、クライアントはそれがすでに接続している別の管理対象サーバーにフェイルオーバーします。

図5-2 サーバー・アフィニティとフェイルオーバー

1. クライアントがMS1に新しい初期コンテキストをリクエストします。

2. クライアントがそのコンテキストでオブジェクトAをルックアップします。そのルックアップはMS1へ向かいます。

3. クライアントがオブジェクトAに呼出しを行います。その呼出しは、クライアントがすでに接続しているMS1に向かいます。オブジェクトAに対する以降の呼出しはMS1に固定されます。

4. クライアントがMS3に固定されているオブジェクトCのスタブを取得します。クライアントはMS3との接続を開きます。

5. MS1に障害が発生します。

6. クライアントがオブジェクトAに対して呼出しを行います。クライアントはもはやMS1への接続を保持していません。クライアントがMS3と接続されているため、MS3上のオブジェクトAのレプリカにフェイルオーバーされます。

例3 - サーバー・アフィニティとサーバー間接続

図5-3の例は、サーバー・アフィニティがサーバー・インスタンス間の接続に影響しないことを示しています。

図5-3 サーバー・アフィニティとサーバー間接続

1. MS4上のJSPがオブジェクトBのスタブを取得します。

2. JSPがMS1上のレプリカを選択します。メソッド呼出しごとに、JSPはオブジェクトBにアクセスできる管理対象サーバーをラウンドロビンに基づいて巡回します。

クラスタ化オブジェクトのパラメータ・ベースのルーティング

パラメータベースのルーティングを使用すると、ロード・バランシング動作をより詳細なレベルで制御できます。クラスタ化された任意のオブジェクトにCallRouterを割り当てることができます。これは、パラメータにより各呼出しの前に呼び出されるクラスです。CallRouterは、パラメータを自由に調べて、呼出しをルーティングする必要のあるネーム・サーバーを戻します。カスタムのCallRouterクラスの作成については、『Oracle WebLogic Server RMIアプリケーションの開発』のクラスタ化オブジェクトのパラメータ・ベースのルーティングに関する項を参照してください。

連結されたオブジェクトの最適化

WebLogic Serverでは、オブジェクトのメソッド呼出しに対して常にロード・バランシングが実行されるわけではありません。ほとんどの場合は、リモート・サーバーにあるレプリカを使用するよりも、スタブ自体と連結しているレプリカを使用する方が効率的です。図5-4は、このことを示します。

図5-4 連結の最適化はメソッド呼出しに対してロード・バランサのロジックをオーバーライドする

この例では、クライアントは、クラスタ内の最初のWebLogic Serverインスタンスにあるサーブレットに接続します。クライアントの動作に対するレスポンスとして、サーブレットはオブジェクトAのレプリカ対応スタブを取得します。オブジェクトAのレプリカは同じサーバー・インスタンス上にもあるので、そのオブジェクトはクライアントのスタブと連結していると判断されます。

WebLogic Serverでは、クラスタ内のオブジェクトAの他のレプリカにクライアントの呼出しを分散しないで、常に、ローカルにある連結されたオブジェクトAのコピーを使用します。クラスタ内の他のサーバーとのピア接続を確立するネットワーク・オーバーヘッドが避けられるので、ローカル・コピーを使用した方が効率的です。

この最適化は、WebLogic Serverクラスタの設計段階でよく見過ごされます。連結の最適化は、各メソッド呼出しでのロード・バランシングを必要としている管理者や開発者にとって混乱の元になることもよくあります。Webアプリケーションが単一のクラスタにデプロイされる場合、連結の最適化は、レプリカ対応スタブに固有のあらゆるロード・バランシング・ロジックをオーバーライドします。

クラスタ化オブジェクトに対する各メソッド呼出しでロード・バランシングが必要な場合、そのようにWebLogic Serverクラスタを設計する方法については、「推奨複数層アーキテクチャ」を参照してください。

トランザクションの連結

基本的な連結戦略の拡張として、WebLogic Serverでは、同じトランザクションの一部として登録されている連結されたクラスタ化オブジェクトの使用も試みられます。クライアントによってUserTransactionオブジェクトが作成されると、WebLogic Serverではそのトランザクションと連結されているオブジェクトのレプリカが使用されます。図5-5は、この最適化の仕組みを表しています。

図5-5 連結の最適化がトランザクション内のその他のオブジェクトへと拡張する

この例では、クライアントがクラスタ内の最初のWebLogic Serverインスタンスに接続し、UserTransactionオブジェクトを取得します。新しいトランザクションが開始された後、クライアントはトランザクションを処理するためにオブジェクトAとオブジェクトBをルックアップします。この場合は、AおよびBのスタブによるロード・バランシングに関係なく、WebLogic Serverは、常にUserTransactionオブジェクトと同じサーバーにあるAおよびBのレプリカを使用しようとします。

このようなトランザクションの連結方式は、「連結されたオブジェクトの最適化」で説明されている基本的な最適化よりも重要です。AとBのリモート・レプリカが使用される場合は、トランザクションが終了するまでの間、余計なネットワーク・オーバーヘッドが生じることになります。なぜなら、トランザクションがコミットされるまでAとBのピア接続がロックされるためです。WebLogic Server。トランザクションの間にクラスタ化オブジェクトを連結すると、WebLogic Serverでは個々のオブジェクトにアクセスするためのネットワーク負荷が削減されます。

XAトランザクション・クラスタ・アフィニティ

XAトランザクション・クラスタ・アフィニティにより、グローバル・トランザクションに参加しているサーバー・インスタンスが、関連リクエストを他のメンバー・サーバーにロード・バランシングせずに、処理することが可能になります。Enable Transaction Affinity=trueの場合、クラスタのスループットは次の理由で高くなります。

- サーバー間のトランザクション調整トラフィックの削減

- JDBC接続の削減など、リソース使用率の向上

- トランザクションの非同期処理の簡素化

クラスタ内にトランザクションに参加しているメンバーがない場合、リクエストは使用可能なクラスタ・メンバーにロード・バランシングされます。選択したクラスタ・メンバーで障害が発生した場合、「JTAトランザクション・リカバリ・サービスの自動移行を構成する手順」を使用して、JTAトランザクション・リカバリ・サービスを移行できます

Oracle WebLogic Server管理コンソール・オンライン・ヘルプのクラスタの構成に関する項を参照してください。-Dweblogic.cluster.TxnAffinityEnabled=trueを使用して、コマンド行でXAトランザクション・アフィニティを有効にすることも可能です。

JMSのロード・バランシング

WebLogic Server JMSでは、分散JMS宛先およびクライアント接続のサーバー・アフィニティがサポートされています。

デフォルトのWebLogic Serverクラスタでは、ラウンドロビンでオブジェクトのロード・バランシングが行われます。JMSオブジェクトのサーバー・アフィニティを実現するロード・バランシング・アルゴリズムを使用するには、クラスタ全体に対して目的の方法を構成する必要があります。ロード・バランシング・アルゴリズムを構成するには、WebLogic Server管理コンソールを使用してweblogic.cluster.defaultLoadAlgorithmを設定します。手順については、「EJBとRMIのロード・バランシング方式を構成する」 を参照してください

分散JMS宛先のサーバー・アフィニティ

サーバー・アフィニティは、分散宛先機能を使用するJMSアプリケーションでサポートされています。この機能は、スタンドアロンの宛先ではサポートされていません。JMS接続ファクトリのサーバー・アフィニティを構成した場合、分散宛先の複数のメンバー間でコンシューマまたはプロデューサをロード・バランシングしているサーバー・インスタンスはまず、同じサーバー・インスタンスで動作しているすべての宛先メンバー間でロード・バランシングを試みます。

JMS接続ファクトリの「サーバー・アフィニティの有効化」オプションが分散宛先メンバーのロード・バランシングのプリファレンスに与える影響の詳細は、『Oracle WebLogic Server JMSリソースの管理』のサーバー・アフィニティの有効化属性を使用した分散宛先ロード・バランシングへの影響に関する項を参照してください。

クライアント接続の初期コンテキスト・アフィニティとサーバー・アフィニティ

システム管理者は、複数のJMSサーバーを構成し、ターゲットを使用してそれらを定義済のWebLogic Serverに割り当てることで、クラスタ内の複数のJMSサーバー間での宛先のロード・バランシングを確立できます。各JMSサーバーは、厳密に1つのWebLogic Serverにデプロイされ、宛先の集合に対するリクエストを処理します。構成の段階で、システム管理者がJMSサーバーのターゲットを指定してロード・バランシングを有効にします。ターゲットの設定手順については、「固定サービスの移行可能ターゲットを構成する」を参照してくださいJMSサーバーを移行可能ターゲットにデプロイする手順については、「移行可能サービスをデプロイ、アクティブ化、および移行する」を参照してください

システム管理者は、複数の接続ファクトリを構成し、ターゲットを使用してそれらをWebLogic Serverに割り当てることで、クラスタ内のあらゆるサーバーから宛先へのクラスタ全体にわたる透過的なアクセスを確立できます。各接続ファクトリを複数のWebLogic Server上でデプロイできます。接続ファクトリの詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』のConnectionFactoryに関する項を参照してください。

アプリケーションでは、Java Naming and Directory Interface (JNDI)を使用して接続ファクトリをルックアップし、JMSサーバーとの通信を確立するための接続を作成します。各JMSサーバーでは、複数の宛先に対するリクエストが処理されます。JMSサーバーによって処理されない宛先に対してのリクエストは、適切なサーバーに転送されます。

WebLogic Serverでは、クライアント接続のサーバー・アフィニティが提供されています。アプリケーションが特定のサーバー・インスタンスと接続されている場合、JMSは同じサーバー・インスタンスと新しいJMS接続を確立しようとします。

接続の作成時に、JMSはまず初期コンテキスト・アフィニティの実現を試みます。クライアントが初期コンテキストを取得するために接続した同じサーバーに接続しようとします。その際、サーバー・インスタンスが接続ファクトリで構成されているものと仮定します。たとえば、接続ファクトリがサーバーAおよびBに対して構成されているが、クライアントはサーバーCのInitialContextを持っている場合、接続ファクトリはAとの新しい接続は確立しませんが、サーバーBとCから選択します。

接続ファクトリが初期コンテキスト・アフィニティを実現できない場合は、クライアントがすでに接続しているサーバーとのアフィニティを提供しようとします。たとえば、クライアントがサーバーAのInitialContextを持ち、サーバーBとの他の種類の接続を確立しているとします。クライアントがサーバーBおよびCに対して構成された接続ファクトリを使用する場合、初期コンテキスト・アフィニティは実現されません。接続ファクトリは代わりに、サーバーCではなく、すでに接続されているサーバーBとの接続を作成してサーバー・アフィニティを実現しようとします。

接続ファクトリが初期コンテキスト・アフィニティまたはサーバー・アフィニティを提供できない場合、接続ファクトリは可能な限り自由に接続を行うことができます。たとえば、クライアントがサーバーAの初期コンテキストを持ち、他の接続はなく、サーバーBおよびCに対して接続ファクトリが構成されているものとします。接続ファクトリはいかなるアフィニティも提供することができず、サーバーBまたはCのいずれかと新しい接続を自由に確立することができます。

注意:

最後のケースで、クライアントが同じ接続ファクトリを使用して2回目の接続を行おうとすると、初回と同じサーバーに接続されます。つまり、最初の接続にサーバーBを選択している場合、2回目の接続を行うと、クライアントはサーバーBと接続され、サーバー・アフィニティ・ルールが施行されます。

6 クラスタのフェイルオーバーとレプリケーション

この章では、WebLogic Server でクラスタ内の障害が検出される仕組みについて説明し、フェイルオーバー方式の概要をオブジェクトのタイプ別に示します。

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

- WebLogic Serverで障害を検出する仕組み

- サーブレットとJSPのレプリケーションとフェイルオーバー

- EJBとRMIのレプリケーションとフェイルオーバー

ここでは、アプリケーション・レベルでのフェイルオーバーとレプリケーションについて重点的に説明します。WebLogic Serverでは、障害発生後にサーバー・インスタンスやサービスを自動的に移行することも可能です。詳細は、「サーバー全体の移行」を参照してください。

WebLogic Serverで障害を検出する仕組み

クラスタ内のWebLogic Serverインスタンスは、次のものをモニターすることで、自身のピア・サーバー・インスタンスの障害を検出します。

- ピア・サーバーへのソケット接続

- サーバーの定期的なハートビート・メッセージ

IPソケットを使用した障害検出

WebLogic Serverインスタンスは、障害を直ちに検出するために、ピア・サーバー・インスタンス間でIPソケットが使用されているかどうかをモニターします。サーバーがクラスタ内のピアのいずれかに接続し、ソケットを使用してデータ転送を始めた場合、そのソケットが突然クローズされると、ピア・サーバーが「エラー」としてマークされ、その関連サービスがJNDIネーミング・ツリーから削除されます。

WebLogic Serverの「ハートビート」

クラスタ化サーバー・インスタンスがピア・ツー・ピア通信用にソケットをオープンしていない場合、障害が発生したサーバーはWebLogic Serverのハートビートによって検出できます。クラスタ内のすべてのサーバー・インスタンスはマルチキャストまたはユニキャストを使用して、定期的なサーバー・ハートビート・メッセージを他のクラスタ・メンバーにブロードキャストします。

個々のハートビート・メッセージには、メッセージの送信元のサーバーを一意に識別するデータが入っています。サーバーは、自身のハートビート・メッセージを10秒間隔で定期的にブロードキャストします。同時に、クラスタ内の各サーバーはマルチキャスト・アドレスまたはユニキャスト・アドレスをモニターして、すべてのピア・サーバーのハートビート・メッセージが送信されているかどうかを確認します。

マルチキャスト・アドレスまたはユニキャスト・アドレスをモニター中のサーバーにピア・サーバーからのハートビート・メッセージが3回届かなかった場合(たとえば、モニターする側のサーバーが他のサーバーから30秒以上ハートビートを受信していない場合)、モニターする側のサーバーはピア・サーバーを「エラー」としてマークします。次に、必要であればローカルのJNDIツリーを更新して、障害が発生したサーバーでホストされていたサービスを削除します。

このようにして、サーバーは、ピア・ツー・ピア通信でソケットがオープンされていない場合でも、障害を検出できます。

注意:

デフォルトのクラスタ・メッセージング・モードはユニキャストです。

WebLogic ServerでIPソケットとマルチキャスト通信(またはユニキャスト通信)がどのように使用されるかの詳細は、「クラスタでのWebLogic Serverの通信」を参照してください。

サーブレットとJSPのレプリケーションとフェイルオーバー

クラスタ内でのサーブレットとJSPの自動レプリケーションとフェイルオーバーをサポートするために、WebLogic ServerではHTTPセッション状態を保持する次の2種類のメカニズムがサポートされています。

- ハードウェア・ロード・バランサ
サポート対象のハードウェア・ロード・バランシング・ソリューションを使用しているクラスタの場合、ロード・バランシング・ハードウェアは、WebLogic Serverクラスタ内で使用可能な任意のサーバーにクライアントのリクエストを単純にリダイレクトします。クラスタ自身は、クライアントのHTTPセッション状態のレプリカをクラスタ内のセカンダリ・サーバーから取得します。

- プロキシ・プラグイン
サポート対象のWebサーバーおよびWebLogicプラグインを使用しているクラスタの場合、プラグインは、WebLogic Serverクラスタ内で使用可能な任意のサーバー・インスタンスにクライアントのリクエストをリダイレクトします。クラスタは、クライアントのHTTPセッション状態のレプリカをクラスタ内のプライマリ・サーバーまたはセカンダリ・サーバーのいずれかのインスタンスから取得します。

この項では、次のトピックを取り上げます。

- HTTPセッション状態のレプリケーション

- クラスタ化サーブレットとJSPへのプロキシ経由のアクセス

- クラスタ化サーブレットとJSPへのロード・バランシング・ハードウェアを利用したアクセス

- MAN/WAN内のクラスタ間でのセッション状態レプリケーション

HTTPセッション状態のレプリケーション

WebLogic Serverでは、複数のクラスタ間でHTTPセッション状態をレプリケートするために次の3つの方法が用意されています。

- インメモリー・レプリケーション
WebLogic Serverは、インメモリー・レプリケーションを使用してセッション状態をサーバー・インスタンス間でコピーします。プライマリ・サーバーはクライアントが最初に接続するサーバー上にプライマリ・セッション状態を作成し、クラスタ内の別のWebLogic Serverインスタンス上に予備のレプリカを作成します。サーブレットのホストとなっているサーバーで障害が起きた場合に使用できるように、レプリカは最新の状態に保たれます。

- JDBCベースの永続性
JDBCベースの永続性では、WebLogic Serverはファイル・ベースまたはJDBCベースの永続性メカニズムを使用して、サーブレットまたはJSPのHTTPセッション状態を保持します。それぞれの永続性メカニズムの詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のセッションの永続性の構成に関する項を参照してください。

JDBCベースの永続性は、ワイド・エリア・ネットワーク(WAN)内のHTTPセッション状態レプリケーションにも使用されます。詳細は、「WANでのHTTPセッション状態のレプリケーション」を参照してください

注意:

永続ストアのタイプがreplicatedまたはreplicated_if_clusteredに設定されているWebアプリケーションは、クラスタまたはクラスタ内のすべてのノードにターゲット指定される必要があります。クラスタ内の一部のノードのみにターゲット指定する場合、Webアプリケーションはデプロイされません。インメモリー・レプリケーションでは、Webアプリケーションがクラスタ内のすべてのノードに均一にデプロイされている必要があります。

- Coherence*Web
セッション・レプリケーションのためにCoherence*Webを使用することができます。Coherence*Webは、WebLogic ServerのインメモリーHTTP状態レプリケーション・サービスの代替ではありません。ただし、アプリケーションに大量くのHTTPセッション状態オブジェクトがある場合、HTTPセッション状態オブジェクト・データの格納によってメモリー制約が発生する場合、または既存のCoherenceクラスタを再利用する場合は、Coherence*Webを使用することをお薦めします。

詳細は、『Oracle Coherence*WebでのHTTPセッション・マネージメントの管理』を参照してください。

次の項では、インメモリー・レプリケーションを使用するセッション状態レプリケーションについて説明します。

HTTPセッション状態のレプリケーションに関する条件

HTTPセッション状態のインメモリー・レプリケーションを利用するためには、WebLogicプロキシ・プラグインの構成が同一であるWebサーバーの集合、またはロード・バランシング・ハードウェアのどちらかを使用してWebLogic Serverクラスタにアクセスする必要があります。

サポート対象のサーバー・ソフトウェアとプロキシ・ソフトウェア

WebLogicプロキシ・プラグインは、クラスタ化されたサーブレットまたはJSPのホストであるWebLogic Serverインスタンスのリストを保持し、ラウンドロビン戦略を使用してHTTPリクエストをそれらのインスタンスに転送します。このプラグインは、WebLogic Serverインスタンスで障害が発生した場合に、クライアントのHTTPセッション状態のレプリカを見つけるために必要なロジックも備えています。

HTTPセッション状態のインメモリー・レプリケーションは、次のWebサーバーおよびプロキシ・ソフトウェアでサポートされています。

- WebLogic ServerとHttpClusterServlet

- ApacheとApache Server (プロキシ)プラグイン

- Microsoft Internet Information ServerとMicrosoft-IIS (プロキシ)プラグイン

プロキシ・プラグインの設定方法については、「プロキシ・プラグインを構成する」 を参照してください

ロード・バランサの必要条件

プロキシ・プラグインではなくロード・バランシング・ハードウェアを使用する場合、互換性のあるパッシブまたはアクティブなCookieの永続性メカニズムと、SSLの永続性にハードウェアが対応している必要があります。これらの必要条件の詳細は、「ロード・バランサの構成要件」を参照してくださいロード・バランサの設定手順については、「パッシブなCookieの永続性をサポートするロード・バランサを構成する」を参照してください

クラスタ化されるサーブレットおよびJSPのプログラミング上の考慮事項

この項では、クラスタ環境にデプロイするサーブレットおよびJSPを対象とした、プログラミング上の重要な制限および考慮事項について説明します。

- セッション・データはシリアライズ可能でなければならない
HTTPセッション状態のインメモリー・レプリケーションを行うには、サーブレットとJSPのセッション・データがすべてシリアライズ可能でなければなりません。

注意:

シリアライゼーションとは、複雑なデータ構造を変換するプロセスのことです。この例には、データの並列な配置(多数のビットが並列チャネルを通じて同時に転送される)からシリアル形式(1ビットずつ順番に転送される)への変換などがあります。シリアル・インタフェースでは、この変換によってデータ転送を可能にしています。

オブジェクトをシリアライズ可能であると定義するための条件は、オブジェクトのすべてのフィールドがシリアライズ可能または一時的であることです。サーブレットまたはJSPでシリアライズ可能なオブジェクトと不可能なオブジェクトが組み合わせて使用される場合、WebLogic Serverではシリアライズ不可能なオブジェクトのセッション状態がレプリケートされません。

- setAttributeを使用してセッション状態を変更する
javax.servlet.http.HttpSessionを実装するHTTPサーブレットでセッション・オブジェクトの属性を変更するには、非推奨となったputValueに代わってHttpSession.setAttributeを使用します。setAttributeを使用してセッション・オブジェクトの属性を設定する場合、オブジェクトとその属性はインメモリー・レプリケーションを使用してクラスタにレプリケートされます。その他のsetメソッドを使用してセッションの内部でオブジェクトを変更する場合、WebLogic Serverではその変更はレプリケートされません。セッション内にあるオブジェクトに対して変更が行われるたびに、setAttribute()を呼び出してクラスタ全体でそのオブジェクトを更新してください。

同様に、セッション・オブジェクトから属性を削除するには、非推奨となったremoveValueに代わってremoveAttributeを使用します。

注意:

非推奨のputValueメソッドおよびremoveValueメソッドを使用しても、セッション属性はレプリケートされます。

- シリアライゼーションのオーバーヘッドを考慮する
セッション・データをシリアライズすると、セッション状態のレプリケーションでオーバーヘッドが生じます。オーバーヘッドは、シリアライズされるオブジェクトのサイズに比例して大きくなります。セッション内で非常にサイズの大きいオブジェクトを作成するような設計では、サーブレットのパフォーマンスをテストして適切なレベルを確保してください。

- フレームからのセッション・データへのアクセスを制御する
複数のフレームを利用するWebアプリケーションを設計する場合は、指定したフレーム・セットのフレームが同時にリクエストを送らないようにすることを心がけてください。たとえば、論理的にはクライアントが1つのセッションを作成する場合でも、1つのフレーム・セットの複数のフレームがクライアント・アプリケーションに代わって複数のセッションを作成する可能性があります。

クラスタ環境では、フレーム・リクエストを適切に調整しないとアプリケーションの予期しない動作が発生することがあります。プロキシ・プラグインは各リクエストを他のリクエストに関係なく処理するので、複数のフレーム・リクエストによって、アプリケーションとクラスタ化されたインスタンスとの関連付けが「リセット」される場合が考えられます。また、フレーム・セット内の複数のフレームを介して同じセッションの属性を変更することで、アプリケーションがセッション・データを壊してしまう可能性もあります。

アプリケーションの予期しない動作を防ぐには、フレームからのセッション・データへのアクセスを注意深く設計します。次のいずれかの規則に従うと、よくある問題を防ぐことができます。

- 指定のフレーム・セットでは、1つのフレームだけがセッション・データを作成および変更するようにします。

- 必ず、アプリケーションで使用する最初のフレーム・セットのフレームでセッションを作成します(たとえば、最初に訪れるHTMLページでセッションを作成します)。セッションを作成した後は、最初のフレーム・セット以外のフレーム・セットでセッション・データにアクセスします。

レプリケーション・グループの使用

デフォルトでは、WebLogic Serverはプライマリ・セッション状態が置かれるものとは別のマシン上にセッション状態のレプリカを作成しようと試みます。それ以外にも、レプリケーション・グループを使用することにより、セカンダリ状態が置かれる場所を独自に制御することができます。レプリケーション・グループは、セッション状態のレプリカを格納するために使用されるクラスタ内のサーバーの優先順リストです。

WebLogic Server管理コンソールを使用して、個別のサーバー・インスタンスのホストとなる固有のマシン名を定義できます。これらのマシン名を新しいWebLogic Serverインスタンスに関連付けると、システムでのサーバーの場所を識別できます。

マシン名は一般に、同じマシン上で動作するサーバーを表すために使用します。たとえば、同じマシンまたはサーバー・ハードウェア上で動作するすべてのサーバー・インスタンスに同じマシン名を割り当てます。

1台のマシン上で複数のWebLogic Serverインスタンスを実行しない場合、WebLogic Serverマシン名を指定する必要はありません。マシン名のないサーバーは、それぞれ別個のマシン上にあるものとして扱われます。マシン名を設定する手順の詳細は、「マシン名を構成する」を参照してください

クラスタ化されるサーバー・インスタンスを構成するとき、サーバーをレプリケーション・グループと優先セカンダリ・レプリケーション・グループに割り当てることができます。後者のグループは、そのサーバーに対して作成されるプライマリHTTPセッション状態のレプリカの保存先となります。

クライアントがクラスタ内のサーバーに接続されて、プライマリ・セッション状態が作成されると、そのプライマリ状態のホスト・サーバーではセカンダリのホスト・サーバーを決定するためにクラスタ内の他のサーバーがランク付けされます。サーバーのランクは、そのサーバーがプライマリ・サーバーと同じマシン上にあるかどうか、およびプライマリ・サーバーの優先レプリケーション・グループに属しているかどうか、という2つの情報を組み合わせて判断されます。表6-1は、クラスタ内のサーバーの相対的なランキングを示しています。

表6-1 セッション・レプリケーションのためのサーバー・インスタンスのランキング

サーバーのランク

別のマシンにある

優先レプリケーション・グループのメンバーである

1

はい

はい

2

いいえ

はい

3

はい

いいえ

4

いいえ

いいえ

プライマリWebLogic Serverは、このルールに従ってクラスタ内のその他のサーバーをランク付けし、最もランクの高いサーバーをセカンダリ・セッション状態のホストとして選択します。たとえば、図6-1は地理的な分類に基づいて構成されたレプリケーション・グループを示しています。

図6-1 地理的に分類されたレプリケーション・グループ

この例では、サーバーA、B、およびCは「Headquarters」というレプリケーション・グループのメンバーであり、「Crosstown」という優先的なセカンダリ・レプリケーション・グループを使用します。逆に、サーバーX、Y、およびZは「Crosstown」というグループのメンバーであり、「Headquarters」という優先的なセカンダリ・レプリケーション・グループを使用します。サーバーA、B、およびXは、「sardina」という同じマシン上にあります。

クライアントがサーバーAに接続し、HTTPセッション状態を作成する場合、

- サーバーYおよびZは別のマシン上にあり、サーバーAの優先セカンダリ・グループのメンバーであるため、これらのサーバーが最も高い確率でこの状態のレプリカのホストとなります。

- サーバーXは、次に高いランクに位置しています。プライマリと同じマシン上ではありますが、サーバーXも優先レプリケーション・グループのメンバーであるためです。

- サーバーCは、マシンは別ですが、優先的なセカンダリ・グループのメンバーではないためランクは3番目になります。

- サーバーBは最低のランクです。サーバーAと同じマシン上にあり(したがってハードウェアに障害があるとAと一緒にダウンする可能性があります)、かつ優先的なセカンダリ・グループのメンバーではないためです。

レプリケーション・グループ内のサーバーのメンバーシップを構成する手順、あるいはサーバーの優先セカンダリ・レプリケーション・グループを割り当てる手順については、「レプリケーション・グループを構成する」を参照してください

クラスタ化されたサーブレットとJSPへのプロキシ経由のアクセス

この項では、クラスタ化されたサーブレットおよびJSPにプロキシ経由で送られてくるリクエストを対象とした、接続およびフェイルオーバーのプロセスについて説明します。プロキシ・プラグインの設定方法については、「プロキシ・プラグインを構成する」 を参照してください

図6-2は、クラスタでホストされるサーブレットにクライアントがアクセスする状況を表しています。この例では、静的なHTTPリクエストのみを処理する1つのWebLogic Serverインスタンスを使用します。すべてのサーブレット・リクエストは、HttpClusterServlet経由でWebLogic Serverクラスタに転送されます。

図6-2 サーブレットとJSPへのプロキシ経由のアクセス

注意:

次の説明は、WebLogic ServerとHttpClusterServletではなくサード・パーティのWebサーバーとWebLogicプロキシ・プラグインを使用する場合にも有効です。

プロキシ接続の手順

HTTPクライアントがサーブレットをリクエストすると、HttpClusterServletがプロキシとして機能し、WebLogic Serverクラスタにそのリクエストを転送します。HttpClusterServletは、クラスタ内の全サーバーのリストと、クラスタへのアクセス時に使用するロード・バランシング・ロジックを管理します。上の例では、HttpClusterServletはクライアントのリクエストをWebLogic Server Aにあるサーブレットに転送します。WebLogic Server Aは、クライアントのサーブレット・セッションをホストするプライマリ・サーバーになります。

サーブレットのフェイルオーバー・サービスを提供するために、プライマリ・サーバーではクライアントのサーブレット・セッション状態がクラスタ内のセカンダリWebLogic Serverにレプリケートされます。このような処理により、たとえばネットワークの障害によってプライマリ・サーバーがダウンしても、セッション状態のレプリカを利用することができます。上の例では、サーバーBがセカンダリとして選択されています。

サーブレット・ページはHttpClusterServletを通じてクライアントに返され、クライアント・ブラウザはサーブレット・セッション状態のプライマリとセカンダリの場所を示すCookieを記述するように指示されます。クライアント・ブラウザでCookieがサポートされていない場合、WebLogic Serverでは代わりにURL書換えを利用できます。

URL書換えを利用したセッション・レプリカの追跡

デフォルト構成のWebLogic Serverでは、クライアント側のCookieを使用して、クライアントのサーブレット・セッション状態のホストであるプライマリ・サーバーとセカンダリ・サーバーが追跡されます。クライアント・ブラウザでCookieが無効になっている場合、WebLogic ServerではURL書換えを利用してもプライマリ・サーバーとセカンダリ・サーバーを追跡できます。URL書換えを利用する場合は、クライアント・セッション状態の両方の場所が、クライアントとプロキシ・サーバーの間で渡されるURLに挿入されます。この機能をサポートするには、WebLogic ServerクラスタでURL書換えを有効にする必要があります。URL書換えを有効にする方法は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のCookieにかわるURL書換えの使用に関する項を参照してください。

プロキシ・フェイルオーバーのプロセス

プライマリ・サーバーで障害が発生すると、HttpClusterServletはクライアントのCookie情報を利用して、セッション・ステートのレプリカのホストであるセカンダリWebLogic Serverの場所を確認します。HttpClusterServletは、クライアントの次のHTTPリクエストを自動的にセカンダリ・サーバーにリダイレクトします。フェイルオーバーは、クライアントには意識されません。

障害の発生後は、WebLogic Server Bがサーブレット・セッション状態のプライマリ・サーバーになり、新しいセカンダリ・サーバーが作成されます(前の例ではサーバーC)。HTTPレスポンスでは、今後のフェイルオーバーに備えて、新しいプライマリ・サーバーとセカンダリ・サーバーを反映するためにプロキシによってクライアントのCookieが更新されます。

注意:

現在、WebLogicプロキシ・プラグインはフェイルオーバー後にランダムにセカンダリ・サーバーを選択します。

2つのサーバーで構成されるクラスタでは、クライアントはセカンダリ・セッション状態のホスト・サーバーに透過的にフェイルオーバーされます。ただし、もう1つのWebLogic Serverがクラスタで利用可能にならない限り、クライアントのセッション状態のレプリケーションは継続されません。たとえば、元のプライマリ・サーバーが再起動されるか、ネットワークに再び接続されると、そのサーバーはセカンダリ・セッション状態のホストとして使用されます。

クラスタ化されたサーブレットとJSPへのロード・バランシング・ハードウェアを利用したアクセス

ロード・バランシング・ハードウェアを経由したクライアントの直接アクセスを可能にするために、WebLogic Serverのレプリケーション・システムでは、クライアントがフェイルオーバー先のサーバーとは無関係にセカンダリ・セッション・ステートを使用できます。WebLogic Serverは、プライマリ・サーバーとセカンダリ・サーバーの場所を記録する手段としてクライアント側のCookieまたはURL書換えを使用します。ただし、この情報はサーブレット・セッション・ステートの場所の履歴としてのみ使用されます。ロード・バランシング・ハードウェアを通じてクラスタにアクセスする場合、クライアントは障害発生後にサーバーを能動的に見つける手段としてはCookie情報を使用しません。

次の項では、HTTPセッション状態のレプリケーションをロード・バランシング・ハードウェアと組み合わせて使用する場合の、接続およびフェイルオーバーのプロセスについて説明します。

ロード・バランシング・ハードウェアを利用した接続

図6-3は、ロード・バランサを通じてクラスタにアクセスしているクライアントの接続手順を示しています。

図6-3 ロード・バランシング・ハードウェアを利用した接続

WebアプリケーションのクライアントがパブリックなIPアドレスを使用してサーブレットをリクエストする場合:

1. ロード・バランサはクライアントの接続リクエストを、構成済のポリシーに従ってWebLogic Serverクラスタに転送します。クラスタはリクエストをWebLogic Server Aに転送します。

2. WebLogic Server Aは、クライアントのサーブレット・セッション状態のプライマリ・ホストとして機能します。プライマリ・ホストは、「レプリケーション・グループの使用」で説明されているランキング・システムを使用して、セッション状態のレプリカのホストとなるサーバーを選択します。上の例では、WebLogic Server Bがレプリカのホストとして選択されています。

3. クライアントは、WebLogic ServerインスタンスAとBの場所をローカルのCookieに記録するように指示されます。クライアントでCookieを利用できない場合、プライマリ・サーバーとセカンダリ・サーバーの場所はURL書換えを利用してクライアントに返されるURLに記録できます。

注意:

Cookieを無効にしているクライアントに対応するには、「URL書換えを利用したセッション・レプリカの追跡」で説明しているように、WebLogic ServerのURL書換え機能を有効にする必要があります

4. クライアントがクラスタに対してさらにリクエストを行う場合、ロード・バランサはクライアント側のCookieに記録された識別子を利用して、リクエストが引き続き、クラスタ内の別のサーバーではなくWebLogic Server Aに確実に転送されるようにします。このような処理によって、クライアントはセッションが終了するまでプライマリ・セッション・オブジェクトのホスト・サーバーと関係を維持することができます。

ロード・バランシング・ハードウェアを利用したフェイルオーバー

クライアントのセッションの途中でサーバーAに障害が発生すると、図6-4に示すように、そのクライアントによるサーバーAへの次の接続リクエストは失敗します。

図6-4 ロード・バランシング・ハードウェアを利用したフェイルオーバー

接続の失敗へのレスポンスとして:

1. ロード・バランシング・ハードウェアは、構成されているポリシーを使用して、クラスタ内の利用可能なWebLogic Serverにリクエストを転送します。上の例では、WebLogic Server Aで障害が起こった後、クライアントのリクエストはWebLogic Server Cに転送されます。

2. クライアントがWebLogic Server Cに接続すると、そのサーバーはクライアントのCookieにある情報(URL書換えが使用される場合はHTTPリクエストの情報)を使用してWebLogic Server Bにあるセッション状態のレプリカを取得します。このフェイルオーバー・プロセスは、クライアントではまったく意識されません。

WebLogic Server Cはクライアントのプライマリ・セッション状態の新しいホストになり、WebLogic Server Bは引続きセッション状態のレプリカを保持します。プライマリ・ホストとセカンダリ・ホストに関するこの新しい情報は、クライアントのCookieまたはURL書換えで再び更新されます。

MAN/WAN内のクラスタ間でのセッション状態レプリケーション

クラスタ内のサーバー間でのHTTPセッション状態レプリケーションに加えて、WebLogic Serverでは、複数のクラスタ間でHTTPセッション状態をレプリケートする機能が提供されます。これにより、複数の地理的領域、電力網、インターネット・サービス・プロバイダに渡ってクラスタを分散できるようになるため、高可用性とフォルト・トレランスが向上します。この項では、WebLogic Serverでサポートされるクラスタ間のレプリケーションのメカニズムを説明します。

- クラスタ間レプリケーションのネットワーク要件

- クラスタ間レプリケーションの構成要件

- MANでのHTTPセッション状態のレプリケーション

- WANでのHTTPセッション状態のレプリケーション

HTTPセッション状態レプリケーションの概要については、「HTTPセッション状態のレプリケーション」を参照してくださいハードウェア・ロード・バランサの使用方法の詳細は、「クラスタ化されたサーブレットとJSPへのロード・バランシング・ハードウェアを利用したアクセス」を参照してください

クラスタ間レプリケーションのネットワーク要件

WebLogic Serverでクラスタ間のレプリケーションを実行するには、使用しているネットワークにグローバル・ハードウェア・ロード・バランサとローカル・ハードウェア・ロード・バランサが含まれている必要があります。図6-5に、クラスタ間のレプリケーションをサポートするマルチ・クラスタ環境で両方のタイプのロード・バランサが対話する仕組みを示します。WebLogic Server環境でのロード・バランサの使用に関する全般的な情報については、「ロード・バランシング・ハードウェアを利用した接続」を参照してください

図6-5 クラスタ間レプリケーションのロード・バランサの要件

次の項では、このネットワーク構成の各コンポーネントについて説明します。

グローバル・ロード・バランサ

クラスタ間のレプリケーションをサポートするネットワーク構成では、グローバル・ロード・バランサがクラスタ間のHTTPリクエストのバランシングを行います。リクエストが受信されると、グローバル・ロード・バランサは、各クラスタによって現在処理されているリクエスト数に基づいてそのリクエストの送信先となるクラスタを決定します。その後、リクエストは選択されたクラスタのローカル・ロード・バランサに渡されます。

ローカル・ロード・バランサ

ローカル・ロード・バランサは、グローバル・ロード・バランサからHTTPリクエストを受信します。ローカル・ロード・バランサは、クラスタ内にあるサーバー間のHTTPリクエストのバランシングを行います。

レプリケーション

クラスタ間でセッション・データをレプリケートするには、プライマリ・クラスタからセカンダリ・クラスタにセッション状態情報を送信するように、レプリケーション・チャネルが構成されている必要があります。セッション情報のレプリケーションに使用される特定の方法は、実装しているクラスタ間レプリケーションのタイプによって異なります。詳細は、「MANでのHTTPセッション状態のレプリケーション」または「WANでのHTTPセッション状態のレプリケーション」を参照してください

フェイルオーバー

クラスタ内のあるサーバーで障害が発生した場合、ローカル・ロード・バランサは、リクエストをクラスタ内のその他のサーバーに転送します。クラスタ全体で障害が発生した場合は、ローカル・ロード・バランサは、HTTPリクエストをグローバル・ロード・バランサに戻します。その後、グローバル・ロード・バランサはそのリクエストをもう一方のローカル・ロード・バランサにリダイレクトします。

クラスタ間レプリケーションの構成要件

次の手順は、クラスタ間レプリケーションを構成するために必要なステップの概要を示しています。

1. ネットワーク構成および要件に従って、WebLogic Serverをインストールします。この手順には、WebLogic Serverインスタンスのホストとなる物理的な各マシンへのWebLogic Serverインスタンスのインストールも含まれます。

2. ハードウェア・ロード・バランサをインストールし、構成します。ロード・バランサの要件の詳細は、「クラスタ間レプリケーションのネットワーク要件」を参照してくださいロード・バランサのインストールおよび構成の詳細は、使用するロード・バランサのドキュメントを参照してください。

次は、クラスタ間レプリケーションをサポートするようにハードウェア・ロード・バランサを構成する場合の一般的な考慮事項です。

- セッションIDを保持するようにロード・バランサを構成する必要があります。ロード・バランサがセッションIDを保持しない場合、後続のリクエストは常に新しいサーバーに送信されます。詳細は、「ロード・バランシング・ハードウェアを利用した接続」を参照してください

- クラスタのフェイルオーバーのタイムアウト値が大きい値を設定しないように注意します。この値は、およそ3 - 5秒に設定する必要があります。ハードウェア・ロード・バランサによっては、デフォルト値がそれよりかなり大きいものもあります。

- プライマリ・クラスタまたはサーバーで障害が発生した場合に使用するバックアップ・クラスタを識別するようにロード・バランサを構成する必要があります。

3. クラスタの要件に従って、ドメインを作成し、構成します。

注意:

クラスタ間レプリケーションでは、各クラスタが別々のドメインに割り当てられている必要があります。

ドメインの作成と構成だけでなく、クラスタおよび管理対象サーバーも作成し、構成する必要があります。ドメイン、クラスタ、および管理対象サーバーの作成と構成については、次のトピックを参照してください。

- 『Oracle WebLogic Serverドメイン構成の理解』のOracle WebLogic Serverドメインに関する項

- 『構成ウィザードによるWebLogicドメインの作成』のクラスタに関する項を参照してください。
次は、クラスタ間レプリケーションをサポートするようにドメインを構成する場合の一般的な考慮事項です。

- 各ドメインに対して、同じ設定および構成を行う必要があります。ドメイン、クラスタ、およびサーバーの構成を同じにするだけでなく、サーバーやクラスタの数なども同じにする必要があります。

- 各ドメインのアプリケーション・デプロイメントを同じにする必要があります。

- ドメインを設定するときは、両方のドメイン間の信頼関係を有効にする必要があります。ドメイン間の信頼関係の有効化の詳細は、『Oracle WebLogic Serverセキュリティの管理』のWebLogic Serverドメイン間の信頼関係の有効化に関する項を参照してください

4. WAN環境でクラスタ間のレプリケーションを使用する場合、セッション状態の保持に使用するデータ・ソースを作成する必要があります。詳細は、「WANでのセッション状態レプリケーション用のデータベースの構成」を参照してください

5. ドメイン、サーバー、およびクラスタの作成と構成が終わったら、クラスタ間レプリケーションに固有の構成要素が正しく構成されていることを確認する必要があります。次のパラメータの構成は、両方のドメインで同じでなければなりません。

表6-2に、クラスタ間レプリケーションの構成に使用されるconfig.xmlのクラスタ要素の下位要素を示します。

表6-2 config.xmlのクラスタ要素

要素

説明

cluster-type

この設定は、使用するレプリケーションのタイプと一致し、両方のクラスタ間で同じでなければなりません。

有効な値は、manまたはwanです

remote-cluster-address

もう一方のクラスタとのレプリケーション情報の通信に使用されるアドレスです。クラスタ間の通信はロード・バランサを通じて行われるように構成する必要があります。

replication-channel

もう一方のクラスタとのレプリケーション情報の通信に使用されるネットワーク・チャネルです。

注意: 名前付きのチャネルが、クラスタのすべてのメンバーに存在し、同じプロトコルを使用するように構成されている必要があります。選択したチャネルは、セキュア・プロトコルを使用するように構成できます。

data-source-for-session-persistence

JDBCベースのセッション永続性の使用時に、セッション情報の格納に使用されるデータ・ソースです。

セッション状態レプリケーションのこの方法は、WAN内のクラスタ間レプリケーションの実行に使用されます。詳細は、「WANでのセッション状態レプリケーション用のデータベースの構成」を参照してください

session-flush-interval

クラスタがHTTPセッションをバックアップ・クラスタにフラッシュする間隔(秒単位)です。

session-flush-threshold

HTTPセッションの数がsession-flush-thresholdの値に達すると、セッションはバックアップ・クラスタにフラッシュされます。これにより、負荷が大きい場合でもセッションを高速にフラッシュできます。

inter-cluster-comm-link-health-check-interval

2つのクラスタ間のリンクが復元されているかどうかを判断する連続チェック間の時間(ミリ秒単位)です。

クラスタ間でのセッション状態レプリケーションの構成

サード・パーティのレプリケーション製品を使用してクラスタ間で状態をレプリケートするか、またはWebLogic Serverを使用してクラスタ間でセッション状態をレプリケートすることができます。使用する方法に応じて、次の構成上の考慮事項に注意する必要があります。

- サード・パーティ製品を使用する場合は、jdbc-poolの値が指定されていることと、remote-cluster-addressが空白になっていることを確認します。

- WebLogic Serverを使用してセッション状態レプリケーションを処理する場合は、jdbc-poolとremote-cluster-addressの両方を構成する必要があります。

remote-cluster-addressがnullになっていると、WebLogic Serverではレプリケーションの処理にサード・パーティ製品が使用されると見なされます。この場合、セッション・データはリモート・データベースに保持されません(ローカルに保持されます)。

レプリケーション・チャネルの構成

レプリケーション・チャネルは、クラスタ間のレプリケーション・トラフィック専用のネットワーク・チャネルです。ネットワーク・チャネルの構成の概要については、『Oracle WebLogic Serverサーバー環境の管理』のネットワーク・リソースの構成に関する項を参照してください。

クラスタ間のレプリケーション・チャネルとして使用するネットワーク・チャネルを作成する場合は、次の点を考慮に入れてください。

- レプリケーション・チャネルは、すべてのクラスタ・メンバー上に同じ名前で作成されている必要があります。

- このチャネルは、レプリケーション専用として使用する必要があります。他の種類のネットワーク・トラフィックは、別のネットワーク・チャネルに転送する必要があります。

MANでのHTTPセッション状態のレプリケーション

メトロポリタン・エリア・ネットワーク(MAN)内のリソースは、多くの場合物理的に異なる場所にありますが、ネットワーク待機時間が問題になるほど地理的には離れていません。MANにおけるネットワーク通信では通常、低レイテンシで高速な相互接続が提供されます。MAN内のクラスタは物理的に異なる場所にインストールできるため、可用性が向上します。

MAN内でフェイルオーバーを提供するために、WebLogic Serverには2つのクラスタ間で機能するインメモリー・メカニズムが用意されています。ネットワーク待機時間が数ミリ秒であれば、この機能によりセッション状態はクラスタ間で同期的にレプリケートされます。同期的な方法を使用する利点は、インメモリー・レプリケーションの信頼性が保証されることです。

注意:

同期的な状態レプリケーションのパフォーマンスは、クラスタ間のネットワーク待機時間で決まります。この方法は、クラスタ間のネットワーク待機時間が許容可能な場合にのみ使用するようにしてください。

MAN内でのレプリケーション

この項では、MAN内の複数のクラスタ間で想定されるフェイルオーバーのシナリオについて説明します。図6-6に、MAN内における一般的なマルチ・クラスタ環境を示します。

図6-6 MANでのレプリケーション

この図には、HTTPセッション状態の次のシナリオが示されています。

1. クライアントが、グローバル・ロード・バランサを通じてリクエストを送信します。

2. グローバル・ロード・バランサが、現在のシステム負荷に基づいてリクエストをローカル・ロード・バランサに渡します。この場合、セッション・リクエストはローカル・ロード・バランサ1に渡されます。

3. ローカル・ロード・バランサが、システム負荷に基づいてリクエストをクラスタ内のサーバー(この場合はS1)に渡します。リクエストがS1に到達すると、この管理対象サーバーはこのHTTPセッションのプライマリ・サーバーになります。障害が発生しないかぎり、後続のリクエストはこのサーバーによって処理されます。

4. セッション状態情報は、プライマリ・クラスタのデータベースに格納されます。

5. サーバーによってHTTPセッションが確立されると、現在のセッション状態が指定されたセカンダリ・サーバーにレプリケートされます。

MANにおけるフェイルオーバーのシナリオ

次の項では、図6-6のMAN構成に基づいて、フェイルオーバーの様々なシナリオについて説明します。

フェイルオーバーのシナリオ1

クラスタ1内のすべてのサーバーで障害が発生した場合、グローバル・ロード・バランサは以降のセッション・リクエストをすべてクラスタ2に自動的にフェイルオーバーします。クラスタ2にレプリケートされたすべてのセッションが回復され、クライアントはデータ損失を回避できます。

フェイルオーバーのシナリオ2

プライマリ・サーバーS1はクラスタ1でホストされ、セカンダリ・サーバーS6はクラスタ2でホストされているとします。S1がクラッシュした場合、クラスタ1内の他のサーバー(S2またはS3)がリクエストを受信し、サーバーS6からセッション・データを取得します。S6は引き続き、バックアップ・サーバーとして機能します。

フェイルオーバーのシナリオ3

プライマリ・サーバーS1はクラスタ1でホストされ、セカンダリ・サーバーS6はクラスタ2でホストされているとします。セカンダリ・サーバーS6で障害が発生した場合、プライマリ・サーバーS1はクラスタ2から新しいセカンダリ・サーバーを自動的に選択します。クライアント・リクエストを受信すると、セッション情報は新しいセカンダリ・サーバーにバックアップされます。

フェイルオーバーのシナリオ4

2つのクラスタ間の通信で障害が発生した場合、プライマリ・サーバーはローカル・クラスタ内の新しいセカンダリ・サーバーにセッション状態を自動的にレプリケートします。2つのクラスタ間の通信が回復すると、以降のクライアント・リクエストはすべてリモート・クラスタにレプリケートされます。

MANでのレプリケーション、ロード・バランサ、セッションの固定

MANでのレプリケーションでは、クラスタ・アフィニティを管理するグローバル・ロード・バランサとサーバー・アフィニティを管理するローカル・ロード・バランサが使用されます。クラスタ内のあるサーバーで障害が発生した場合、ローカル・ロード・バランサはセッション状態がそのクラスタ内の別のサーバーにレプリケートされることを保証します。クラスタ内のすべてのサーバーで障害が発生した場合や、クラスタ内のすべてのサーバーが使用できなくなっている場合は、グローバル・ロード・バランサがセッション状態をもう一方のクラスタにレプリケートします。これにより、クラスタ全体で障害が発生しない限り、もう一方のクラスタへのフェイルオーバーは発生しないようになります。

クライアントは、ロード・バランサを通じてクラスタへの接続を確立したら、そのクラスタが正常な状態である限り、そのクラスタへの接続を保持する必要があります。

WANでのHTTPセッション状態のレプリケーション

ワイド・エリア・ネットワーク(WAN)内のリソースは、多くの場合異なる地理的領域に渡って分散されています。ネットワーク・トラフィックが長い距離を進む必要があるだけでなく、これらのリソースは通常、複数のルーターなどのネットワーク・ボトルネックによっても分離されています。WANにおけるネットワーク通信は通常、待機時間が比較的長く、相互接続の速度も遅くなります。

WANではネットワークのパフォーマンスが低いため、MANで使用されるような同期的なレプリケーション・メカニズムを使用することは困難です。WebLogic Serverは、非同期的なデータ・レプリケーション方式使用することで、WANにおけるクラスタ間のフェイルオーバーを提供します。

WAN内でのレプリケーション

この項では、WAN内の複数のクラスタ間で想定されるフェイルオーバーのシナリオについて説明します。図6-7に、WANにおける一般的なマルチ・クラスタ環境を示します。

図6-7 WANでのレプリケーション

この図には、HTTPセッション状態の次のシナリオが示されています。

1. クライアントが、グローバル・ロード・バランサを通じてリクエストを送信します。

2. グローバル・ロード・バランサが、現在のシステム負荷に基づいてリクエストをローカル・ロード・バランサに渡します。この場合、セッション・リクエストはローカル・ロード・バランサ1に渡されます。

3. ローカル・ロード・バランサが、システム負荷に基づいてリクエストをクラスタ内のサーバー(この場合はS1)に渡します。リクエストがS1に到達すると、この管理対象サーバーはこのHTTPセッションのプライマリ・サーバーになります。障害が発生しないかぎり、後続のリクエストはこのサーバーによって処理されます。

4. セッション状態情報は、プライマリ・クラスタのデータベースに格納されます。

5. サーバーによってHTTPセッションが確立されると、現在のセッション状態が指定されたセカンダリ・サーバーにレプリケートされます。

WANにおけるフェイルオーバーのシナリオ

この項では、WAN環境でのフェイルオーバーのシナリオについて説明します。

フェイルオーバーのシナリオ

クラスタ1内のすべてのサーバーで障害が発生した場合、グローバル・ロード・バランサは以降のセッション・リクエストをすべてクラスタ2に自動的にフェイルオーバーします。すべてのセッションは、認識されている最新のデータベースへのフラッシュに従ってバックアップされます。

WANでのセッション状態レプリケーション用のデータベースの構成

この項では、WANでのクラスタ間セッション状態レプリケーション用のデータ・ソースの構成要件について説明します。クラスタ間レプリケーションの設定の概要については、「クラスタ間レプリケーションの構成要件」を参照してください

WAN環境でのクラスタ間レプリケーションを有効にするには、セッション状態情報が格納されるデータベースを指定するJDBCデータ・ソースを作成する必要があります。次の手順を実行して、データベースを設定し構成します。

1. ベンダーのドキュメントに従って、データベース・サーバー・ソフトウェアをインストールし、構成します。

2. このデータベースを参照するJDBCデータ・ソースを作成します。JDBCデータ・ソースの作成の詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のJDBCデータ・ソースの構成に関する項を参照してください。

このデータ・ソースは、JDBCマルチ・データ・ソースとして構成することもできます。マルチ・データ・ソースの構成の詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のJDBCマルチ・データ・ソースの構成に関する項を参照してください。

3. このデータ・ソースを指定するように、プライマリ・クラスタとセカンダリ・クラスタの両方のDataSourceForSessionPersistenceを設定します。

4. 次のスキーマに従って、データベースにWLS_WAN_PERSISTENCEという表を作成します。

CREATE TABLE WLS_WAN_PERSISTENCE_TABLE (
WL_ID VARCHAR2(100) NOT NULL,
WL_CONTEXT_PATH VARCHAR2(50) NOT NULL,
WL_CREATE_TIME NUMBER(20),
WL_ACCESS_TIME NUMBER(20),
WL_MAX_INACTIVE_INTERVAL NUMBER(38),
WL_VERSION NUMBER(20) NOT NULL,
WL_INTERNAL_ATTRIBUTE NUMBER(38),
WL_SESSION_ATTRIBUTE_KEY VARCHAR2(100),
WL_SESSION_ATTRIBUTE_VALUE LONG RAW,
PRIMARY KEY(WL_ID, WL_CONTEXT_PATH,
WL_VERSION, WL_SESSION_ATTRIBUTE_KEY));

表6-3では、この表の各行が格納する内容について説明します。

表6-3 レプリケーション表の内容

データベースの行

説明

wl_id

HTTPセッションIDを格納します。

wl_context_path

セッションを作成したWebアプリケーションのコンテキスト・パスを格納します。

wl_create_time

セッション状態が作成された時刻を格納します。

wl_session_values

セッションの属性を格納します。

wl_access_time

セッション状態の最終の更新時刻を格納します。

wl_max_inactive_interval

セッション状態のMaxInactiveIntervalを格納します。

wl_version

セッションのバージョンを格納します。セッションの各更新にはバージョンが関連付けられています。

EJBとRMIのレプリケーションとフェイルオーバー

クラスタ化されるEJBとRMIのフェイルオーバーは、オブジェクトのレプリカ対応スタブを使用して実現されます。クライアントがレプリカ対応スタブを通じて障害が発生したサービスに対して呼出しを行うと、スタブはその障害を検出し、別のレプリカに対してその呼出しを再試行します。

クラスタ化オブジェクトについては、オブジェクトが多重呼出し不変の場合にだけ自動的なフェイルオーバーが行われます。メソッドを何回呼び出しても1回呼び出したときと効果に違いがなければ、オブジェクトは多重呼出し不変となります。このことは、恒久的な副作用を持たないメソッドに関して常に当てはまります。副作用のあるメソッドは、多重呼出し不変性に留意して作成する必要があります。

ここでショッピング・カートに商品を追加するショッピング・カード・サービス呼出しaddItem()を考えてみます。クライアントCがこの呼出しをサーバーS1上のレプリカで行うものとします。S1が呼出しを受け取った後、呼出しをCに戻す前に、S1がクラッシュしたとします。この時点では、商品がショッピング・カートに追加されていますが、レプリカ対応スタブは例外を受け取っています。スタブがサーバーS2でこのメソッドを再試行すれば、商品がショッピング・カートに2回追加されることになります。この理由から、レプリカ対応スタブは、デフォルトでは、リクエストが送られた後、そのリクエストが戻ってくるまでは、メソッドの再試行は行いません。この動作は、サービスを多重呼出し不変としてマークすることで、オーバーライドできます。

レプリカ対応スタブによるオブジェクトのクラスタリング

EJBまたはRMIオブジェクトをクラスタリングすると、オブジェクトのインスタンスがクラスタ内のすべてのWebLogic Serverにデプロイされます。クライアントでは、オブジェクトのどのインスタンスを呼び出すのかを選択できます。オブジェクトの各インスタンスはレプリカと呼ばれます。

レプリカ対応スタブは、WebLogic Serverでのオブジェクトのクラスタリングをサポートする主要テクノロジです。クラスタリングをサポート(デプロイメント記述子で定義)するEJBをコンパイルすると、appcによってEJBのインタフェースがrmicコンパイラに渡されてそのBeanのレプリカ対応スタブが生成されます。RMIオブジェクトの場合は、rmicのコマンド行オプションを使用して、明示的にレプリカ対応スタブを生成します。詳細は、『Oracle WebLogic Server RMIアプリケーションの開発』のWebLogic RMIコンパイラの使用に関する項を参照してください。

レプリカ対応スタブは、呼出し側では通常のRMIスタブとして認識されます。しかしながら、スタブは1つのオブジェクトではなく複数のレプリカを表します。レプリカ対応スタブは、オブジェクトがデプロイされるすべてのWebLogic ServerインスタンスでEJBクラスまたはRMIクラスを見つけるためのロジックを備えています。クラスタ対応のEJBオブジェクトまたはRMIオブジェクトをデプロイすると、その実装はJNDIツリーにバインドされます。「クラスタ全体のJNDIネーミング・サービス」で説明されているように、クラスタ化されたWebLogic Serverインスタンスではそのオブジェクトを利用できるすべてのサーバー・インスタンスをリストするためにJNDIツリーを更新できます。クライアントがクラスタ化オブジェクトにアクセスすると、その実装はクライアントに送信されるレプリカ対応スタブで置き換えられます。

スタブは、オブジェクトに対するメソッド呼出しを負荷分散するためのロード・バランシング・アルゴリズム(呼出しルーティング・クラス)を備えています。呼出しが行われるたびに、スタブではそのロード・アルゴリズムを利用して呼び出すレプリカを選択できます。この機能により、呼出し側からは意識されない方法でクラスタ全体でのロード・バランシングが実現されます。RMIオブジェクトおよびEJBで利用可能なロード・バランシング・アルゴリズムを理解するには、「EJBとRMIオブジェクトのロード・バランシング」を参照してください呼出しの途中で失敗した場合、スタブによってその例外が横取りされ、別のレプリカで呼出しが再試行されます。この機能により、同じように呼出し側からは意識されないフェイルオーバーが実現されます。

各種のEJBでのクラスタリング・サポート

EJBは、2つの異なったレプリカ対応スタブを生成できる点が通常のRMIオブジェクトと異なります。1つはEJBHomeインタフェースに対して、もう1つはEJBObjectインタフェースに対して生成されます。つまり、EJBでは次の2段階でロード・バランシングとフェイルオーバーのメリットを実現できることになります。

- クライアントがEJBHomeスタブを使用してEJBオブジェクトをルックアップするとき

- クライアントがEJBObjectスタブを使用してEJBに対するメソッド呼出しを行うとき

次の項では、EJBのタイプ別のクラスタリング・サポートについて説明します。

クラスタ化されたEJBHome

Beanインスタンスの検索や作成に使用されるすべてのBeanホーム・インタフェースは、weblogic-ejb-jar.xmlでhome-is-clusterable要素を指定することでクラスタリングできます。

注意:

ステートレス・セッションBean、ステートフル・セッションBean、およびエンティティBeanにはホーム・インタフェースがあります。メッセージドリブンBeanにはありません。

Beanをクラスタにデプロイするときに、各サーバーはBeanのホーム・インタフェースを同じ名前でクラスタJNDIツリーにバインドします。クライアントがクラスタにあるBeanのホーム・インタフェースをリクエストすると、ルックアップを行うサーバー・インスタンスは、各サーバー上のホームへの参照を持つEJBHomeスタブを返します。

クライアントがcreate()またはfind()呼出しを発行すると、スタブはロード・バランシング・アルゴリズムに従ってレプリカ・リストからサーバーを選択し、そのサーバー上のホーム・インタフェースに呼出しをルーティングします。選択されたホーム・インタフェースは呼出しを受け取り、そのサーバー・インスタンス上にBeanインスタンスを作成して、呼出しを実行します。

注意:

WebLogic Serverでは、EJBホーム・インタフェースのサーバー・アフィニティを提供するロード・バランシング・アルゴリズムがサポートされています。サーバー・アフィニティ、およびロード・バランシングとフェイルオーバーに対するその影響については、「ラウンドロビン・アフィニティ、重みベース・アフィニティ、およびランダム・アフィニティ」を参照してください

クラスタ化されたEJBObject

EJBObjectスタブは、クラスタ内のEJBの使用可能なレプリカを追跡します。

ステートレス・セッションBean

ホームでステートレスBeanが作成されると、Beanのデプロイ先となる、クラスタ内のすべてのサーバーのリストを示すEJBObjectスタブが返されます。ステートレスBeanでは状態が保持されないので、スタブではBeanのホストであるどのサーバーにでも呼出しを転送できます。スタブでは障害が起きたときに自動的にフェイルオーバーを実行できます。スタブでは、Beanは自動的には多重呼出し不変として扱われないので、あらゆる障害から自動的に回復することはありません。Beanが多重呼出し不変メソッドを利用して記述されている場合は、そのことをデプロイメント記述子で示すことができ、そうすればあらゆる場合で自動フェイルオーバーが有効になります。

注意:

WebLogic Serverでは、ステートレスEJBリモート・インタフェースのサーバー・アフィニティを提供するロード・バランシング・オプションがサポートされています。サーバー・アフィニティ、およびロード・バランシングとフェイルオーバーに対するその影響については、「ラウンドロビン・アフィニティ、重みベース・アフィニティ、およびランダム・アフィニティ」を参照してください

ステートフル・セッションBean

ステートフル・サービスに対するメソッド・レベルのフェイルオーバーには、状態のレプリケーションが必要です。WebLogic Serverでは、HTTPセッション状態で使用されるものと同様のレプリケーション方式を使用して、プライマリBeanインスタンスの状態をセカンダリ・サーバー・インスタンスにレプリケートすることで、この要件を満たします。

ホーム・インタフェースはステートレス・セッションBeanインスタンスを作成するときに、「レプリケーション・グループの使用」で定義した同じルールを使用して、レプリケートされた状態をホストするためのセカンダリ・インスタンスを選択しますホーム・インタフェースは、プライマリBeanインスタンスの場所とレプリケートされたBean状態の場所のリストを示すEJBObjectスタブをクライアントに戻します。

図6-8に、クラスタ化されたステートフル・セッションEJBにクライアントがアクセスする状況を示します。

図6-8 ステートフル・セッションEJBにアクセスするクライアント

クライアントによってEJBの状態が変更されると、状態の変更部分がセカンダリ・サーバーのインスタンスにレプリケートされます。トランザクションに関係しているEJBの場合、レプリケーションはトランザクションのコミットの直後に行われます。トランザクションに関係していないEJBの場合、レプリケーションは各メソッド呼出しの後に行われます。

両方の場合で、EJBの状態の実際の変更部分だけがセカンダリ・サーバーにレプリケートされます。このため、レプリケーション・プロセスに伴うオーバーヘッドが最小限に抑えられます。

注意:

EJB仕様で説明されているように、ステートフルEJBの実際の状態はトランザクション非対応です。可能性は低いですが、EJBの現在の状態が失われることもあり得ます。たとえば、EJBの関与しているトランザクションがクライアントによってコミットされ、状態の変更がレプリケートされる前にプライマリ・サーバーで障害が起きると、クライアントは以前に格納されていたEJBの状態にフェイルオーバーされます。あらゆる障害シナリオにおいて、EJBの状態の保持が重要な場合は、ステートフル・セッションEJBではなくエンティティEJBを使用してください。

ステートフル・セッションEJBのフェイルオーバー

プライマリ・サーバーで障害が起きると、以降のリクエストはクライアントのEJBスタブによって自動的にセカンダリWebLogic Serverインスタンスにリダイレクトされます。この時点で、レプリケートされた状態データを使用してセカンダリ・サーバーで新しいEJBインスタンスが作成され、セカンダリ・サーバーで処理が継続されます。

フェイルオーバーの後、WebLogic ServerではEJBセッション状態をレプリケートする新しいセカンダリ・サーバーが選択されます(クラスタ内に利用可能な別のサーバーがある場合)。新しいプライマリとセカンダリのサーバー・インスタンスの場所は、図6-9に示すように、次のメソッド呼出しのときにクライアントのレプリカ対応スタブで自動的に更新されます。

図6-9 フェイルオーバー後にレプリカ対応スタブが更新される

エンティティEJB

エンティティBeanには、読み書き対応エンティティBeanと読取り専用エンティティBeanの2種類があります。

- 読み書き対応エンティティ
ホームで読み書き対応エンティティBeanが検索または作成される場合は、ローカル・サーバーでインスタンスが取得され、そのサーバーに固定されたスタブが返されます。ロード・バランシングとフェイルオーバーはホームのレベルでのみ行われます。クラスタにはエンティティBeanの複数のインスタンスが存在する可能性があるため、各インスタンスは各トランザクションの前にデータベースから読み込まれ、各コミットで書き込まれなければなりません。

- 読取り専用エンティティ
ホームで読取り専用エンティティBeanが検索または作成される場合は、レプリカ対応スタブが返されます。このスタブでは、すべての呼出しでロード・バランシングが行われますが、回復可能な呼出しエラーが発生したときに自動的にフェイルオーバーは行われません。読取り専用Beanは、データベース読込みを防止するためにすべてのサーバーでキャッシュされます。

エンティティBeanとEJBハンドルのフェイルオーバー

エンティティBeanとEJBハンドルのフェイルオーバーは、クラスタ・アドレスの指定方法に依存します。「クラスタ・アドレス」で説明しているように、クラスタ・アドレスは明示的に定義することも、WebLogic Serverによって自動的に生成することもできますクラスタ・アドレスを明示的に定義する場合は、クラスタ内のすべてのサーバー・インスタンスにマップされ、かつクラスタ内のサーバー・インスタンスのみにマップされるDNS名として指定する必要があります。クラスタのDNS名は、クラスタに属していないサーバー・インスタンスに対応しないようにします。

RMIオブジェクトのクラスタリング・サポート

WebLogic RMIには、クラスタ化されたリモート・オブジェクト作成専用の拡張機能があります。これらの拡張機能を使用して、EJBの項で説明されているレプリカ対応スタブをビルドします。クラスタでのRMIの使用の詳細は、『Oracle WebLogic Server RMIアプリケーションの開発』のWebLogicのRMI機能に関する項を参照してください。

オブジェクト・デプロイメントの要件

WebLogic Serverクラスタで使用するEJBをプログラミングする場合は、この項の説明を参照して、クラスタ内の各種のEJBの機能について理解してください。そして確実にEJBのデプロイメント記述子でクラスタリングできるようにします。クラスタリングに関するXMLデプロイメント要素の詳細は、『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』のweblogic-ejb-jar.xmlデプロイメント記述子のリファレンスに関する項を参照してください。

EJBまたはカスタムRMIオブジェクトを開発する場合は、『Oracle WebLogic Server JNDIアプリケーションの開発』のクラスタ環境でのWebLogic JNDIの使用に関する項を参照して、クラスタ化オブジェクトをJNDIツリーにバインドすることの影響を理解してください。

他のフェイルオーバーの例外

クラスタ化オブジェクトが多重呼出し不変でない場合でも、WebLogic Serverは、ConnectExceptionまたはMarshalExceptionが発生したときに自動フェイルオーバーを実行します。いずれの例外もオブジェクトが変更されないことを示しているため、別のインスタンスにフェイルオーバーすることでデータの矛盾が起こる危険性はありません。

7 サーバー全体の移行

この章では、WebLogic Serverでサポートされている様々な移行メカニズムについて説明します。

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

- サーバーおよびサービスの移行の理解

- 移行関連の用語

- リース

- サーバー全体の自動移行

- 動的クラスタおよび複合クラスタでのサーバー全体の移行

これらの項では、サーバーで障害が発生した場合にサーバー全体を移行する方法について重点的に説明します。サーバー全体の移行では、移行可能サーバー・インスタンスとそのすべてのサービスを、物理的に別のマシンに移行します。WebLogic Serverでは、サービス・レベルの移行や、アプリケーション・レベルでのレプリケーションおよびフェイルオーバーもサポートされています。詳細は、「サービスの移行」および「クラスタのフェイルオーバーとレプリケーション」を参照してください。

サーバーおよびサービスの移行の理解

WebLogic Serverクラスタでは、ほとんどのサービスがクラスタ内のすべてのサーバー・インスタンスに均一にデプロイされます。これにより、サーバー・インスタンス間の透過的なフェイルオーバーが可能になります。対照的に、JMSやJTAトランザクション・リカバリ・システムなどの「固定サービス」はクラスタ内の個々のサーバー・インスタンスがターゲットとなります - これらのサービスについては、WebLogic Serverでは、フェイルオーバーではなく移行による障害リカバリがサポートされています。

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

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

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

移行関連の用語

サービスおよびサーバーの移行では、次の用語を使用します。

- 移行可能サーバー - ホストするすべてのサービスとともにそのまま全部移行する、クラスタ化サーバー・インスタンスのことです。移行可能なサーバーは、JMSサーバーやJTAトランザクション・リカバリ・サーバーなどの固定サービスをホストすることを目的としたものですが、クラスタ化可能なサービスもホストできます。移行可能サーバー上で実行されるすべてのサービスには高可用性が備わっています。

- サーバー全体の移行 - 障害が発生すると、WebLogic Serverインスタンスは手動または自動で、物理的に別のマシンに移行されます。

- サーバーの移行:

- サービスの手動移行 - サービスをホストするサーバー・インスタンスがエラーになった後、JTAやJMS関連の固定サービス(JMSサーバー、SAFエージェント、パス・サービスおよびカスタム・ストアなど)の手動移行のことです。サービスの移行を参照してください。

- サービスの自動移行 - JMS関連サービス、シングルトン・サービスおよびJTAトランザクション・リカバリ・サービスは、メンバー・サーバー・インスタンスで障害が発生したり再起動されたときに、別のメンバー・サーバー・インスタンスに自動的に移行するよう構成できます。サービスの移行を参照してください。

- クラスタ・リーダー - クラスタ内の過半数のサーバー・インスタンスによって選択される1つのサーバーです。このサーバー・インスタンスは、リース情報を保持します。「コンセンサス(非データベース)リース」を参照してください

- クラスタ・マスター - 移行可能サーバーを含むクラスタ内の1つのサーバー・インスタンスがクラスタ・マスターとして機能し、障害の発生時にサーバーの自動移行プロセスを調整します。固定サービスのホストであるかどうかに関係なく、クラスタ内のどの管理対象サーバーもクラスタ・マスターになることができます。「サーバー全体の移行におけるクラスタ・マスターの役割」を参照してください

- シングルトン・マスター - 自動移行可能な他のサービスをモニターする軽量シングルトン・サービスです。その時点でシングルトン・マスターをホストしているサーバー・インスタンスは、各移行可能サービスに関連付けられた移行タスクを開始および停止する役割を担います。「シングルトン・マスター」を参照してください。

- 候補マシン - クラスタ内で移行先のターゲットになる可能性のあるマシンのユーザー定義リストです。

- ターゲット・マシン - 移行可能サーバーの優先ホストとして指定されている一連のマシンです。

- ノード・マネージャ - 管理サーバーやスタンドアロンのノード・マネージャ・クライアントが使用するWebLogicサーバーのユーティリティで、移行可能なサーバーを起動または停止します。ノード・マネージャはクラスタ・マスターによって起動され、必要に応じて、移行可能なサーバーを停止または再起動します。ノード・マネージャの基本的な情報およびノード・マネージャがWebLogic Server環境に組み込まれる方法は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャの概要に関する項を参照してください。

- リース表 - 移行可能サーバーがそれぞれの状態を維持するデータベース表です。クラスタのマスターはこのデータベース表をモニターして、移行可能サーバーのヘルス状態とそれらが使用可能かどうかを確認します。リースの詳細は、「リース」を参照してください

- 管理サーバー - 移行可能サーバーとターゲット・マシンの構成、移行可能サーバーの実行時状態の取得、および手動による移行プロセスの調整に使用します。

- 浮動IPアドレス - ある物理的マシンから別の物理的マシンへの移行後もサーバー・インスタンスを追跡するIPアドレス。

リース

リースは、クラスタの複数のメンバーで同時に実行することができないサービスを管理するために使用するプロセスです。リースによって、クラスタ全体エンティティの排他的な所有権を確保できます。リースのオーナーは、クラスタ内に1つしか存在しません。また、サーバーやクラスタの障害時には、リースをフェイルオーバーさせることができます。これにより、シングル・ポイント障害を回避できます。

リースを使用する機能

リースは、次のWebLogicサーバー機能で使用されます。

- サーバー全体の自動移行 - クラスタ・マスターを選択するためにリースを使用します。クラスタ・マスターは、別のクラスタ・メンバーのモニター、および別の物理マシンでホストされるメンバーに障害が発生した場合にそのメンバーの再起動を担当します。
リースを使用することで、クラスタ・マスターが常に実行され、しかもクラスタ内のいずれか1つのサーバー・インスタンスでのみ実行されていることが保証されます。クラスタ・マスターの詳細は、「サーバー全体の移行におけるクラスタ・マスターの役割」を参照してください

- 自動サービス移行 - JMS関連サービス、シングルトン・サービスおよびJTAトランザクション・リカバリ・サービスは、ヘルス・モニタリング・サブシステムを利用して、異常のあるホスト・サーバー・インスタンスから正常なアクティブ・サーバー・インスタンスに自動的に移行するよう構成できます。移行可能ターゲットを移行すると、そのターゲットにホストされている固定サービスも移行されます。移行可能ターゲットでは、リースを使用してサービスの自動移行を実現しています。サービスの移行を参照してください。

- シングルトン・サービス - クラスタ内の複数のメンバーで同時に実行できないサービスです。この条件を満たすために、シングルトン・サービスではリースを使用します。「シングルトン・マスター」を参照してください。

- ジョブ・スケジューラ - クラスタ内で使用する永続タイマーです。ジョブ・スケジューラでは、タイマー・マスターを使用して、クラスタ間でのタイマーのロード・バランシングを行います。
この機能には、フェイルオーバーやレプリケーション情報を保持するために外部のデータベースが必要です。ただし、ジョブ・スケジューラでは非データベースのコンセンサス・リーシングを使用できます。

注意:

リース機能のほとんどは、基本的な構成の及ばない場所で、WebLogic Serverにより内部的に処理されます。

リースの種類

WebLogic Serverには、要件と環境に応じて、2種類のリーシング機能が用意されています。

- 高可用性データベース・リース - このバージョンのリースは、リース情報を格納するために高可用性データベースを必要とします。一般的な要件と構成は、「高可用性データベース・リース」を参照してください

- 非データベースのコンセンサス・リース - リース情報をクラスタ・メンバーのメモリー内に格納するリースです。このバージョンのリースは、ノード・マネージャがクラスタ内のすべてのサーバー・インスタンスを起動することを必要とします。「非データベースのコンセンサス・リース」を参照してください

1つのWebLogic Serverインストールでは、1種類のリースしか使用できません。1つの環境において、リースを使用する複数の機能を実装することは可能ですが、各機能には同じ種類のリースを使用する必要があります。

あるリースの種類をもう一方の種類に切り替える場合は、管理サーバーだけでなく、クラスタ全体を再起動する必要があります。リースの種類を動的に変更することはできません。

使用するリースの種類の決定

現在のWebLogic Server環境にどの種類のリースが適しているかを判断する場合は、次の考慮事項を参考にしてください。

- 高可用性データベース・リース
データベース・リースは、JMSストアのリカバリなどの機能を使用するためにOracle RACのような高可用性データベースがすでにある環境では有用です。最小限の追加の構成を行って、高可用性データベース・インスタンスがリースをサポートするように構成できます。これは、ノード・マネージャがシステムで実行されていない場合に、特に便利です。

- 非データベースのコンセンサス・リース
このタイプのリースは、高可用性データベースを必要としないリースの選択肢(コンセンサス)を提供します。これは、サーバー全体の自動移行の場合に便利です。高可用性データベースを必要としないため、コンセンサス・リースでは、サーバーの自動移行を実行するために必要な構成が少なくなります。

コンセンサス・リースでは、ノード・マネージャを構成して実行する必要があります。ノード・マネージャは、サーバー全体の自動移行においてもIPの移行および別のマシンでのサーバーの再起動のために必要となります。つまり、コンセンサス・リースの場合は、追加の要件がないうえに、負荷の高い要件を排除できます。

高可用性データベース・リース

このタイプのリースでは、リース情報を高可用性データベースの表内に保持します。サーバー・インスタンスがリース情報を常に利用できるようにするため、可用性の高いデータベースが必要になります。リース情報にアクセスし、リースを更新するために、クラスタの各メンバーがデータベースに接続できる必要があります。データベースが使用不能になり、リースを更新できなくなると、サーバー・インスタンスでは障害が発生します。

このリース方法は、クラスタ環境にすでに高可用性データベースが存在する場合に便利です。このメソッドにより、ノード・マネージャを必要としないリース機能を使用して、環境内のサーバー・インスタンスを管理できます。

次の手順は、リース用のデータベースを構成するために必要なステップの概要を示しています。

1. サーバーの移行用にデータベースを構成します。データベースには、サーバー・インスタンスが実行中であるかどうか、サーバーを移行する必要があるかどうかを決定するために使用されるリース情報が格納されます。

データベースには信頼性がある必要があります。サーバー・インスタンスは唯一信頼性のあるデータベースです。試験的な目的で使用する場合は、通常のデータベースで十分です。本番環境では、高可用性データベースのみ使用することをお薦めします。データベースが停止すると、すべての移行可能サーバーが停止します。

データベース内にリース表を作成します。この表は、サーバーの移行を可能にするためのマシンとサーバーの関連付けの格納に使用されます。この表のスキーマは、WL_HOME/server/db/dbname/leasing.ddlにあります。ここで、dbnameはデータベース・ベンダーの名前です。

注意:

リース表は高可用性データベースに格納する必要があります。移行可能サーバーの信頼性は、リース表の格納に使用されるデータベースの信頼性で決まります。

2. データ・ソースを設定し、構成します。このデータ・ソースは、前の手順で構成したデータベースを指している必要があります。

注意:

サーバーの移行では、XAデータ・ソースはサポートされていません。

JDBCデータ・ソースの作成の詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のJDBCデータ・ソースの構成に関する項を参照してください。

RACクラスタ上でのデータベース・リースによるサーバーの移行

RACクラスタ上でデータベース・リースによるサーバー移行を使用する場合は、環境内のすべてのRACノードを同期することをお薦めします。ノードが同期化されない場合、リースを更新している管理対象サーバーは、RACノードのクロックの値がリース表のタイムアウト値よりも大きいかどうかを評価する場合があります。これが30秒を超える場合、サーバー・インスタンスに不具合が生じて再起動し、次のログ・メッセージが表示されます。

<Mar 29, 2013 2:39:09 PM EDT> <Error> <Cluster> <BEA-000150> <Server failed
to get a connection to the database in the past 60 seconds for lease renewal.
Server will shut itself down.>

Oracle Grid Infrastructureインストレーション・ガイドのクラスタの時間同期の構成に関する項を参照してください。

非データベースのコンセンサス・リース

注意:

コンセンサス・リースでは、ノード・マネージャを使用してクラスタ内のサーバー・インスタンスを管理する必要があります。障害が発生した移行可能サーバーの候補マシンを含め、クラスタ内の管理対象サーバーをホストしているすべてのマシンで、ノード・マネージャが実行されている必要があります。詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャを使用したサーバーの制御に関する項を参照してください。

コンセンサス・リースは可用性の高いデータベースを必要としません。クラスタ・リーダーは、メモリー内にリースを保持します。すべてのサーバー・インスタンスがクラスタ・リーダーに接続することでリースを更新しますが、フェイルオーバーの場合は、リース表がクラスタの別のノードにレプリケートされます。

クラスタ・リーダーは、クラスタ内のすべての実行中のサーバー・インスタンスによって選出されます。サーバー・インスタンスは、過半数のサーバー・インスタンスから承認を受けた場合のみ、クラスタ・リーダーになります。ノード・マネージャがあるサーバー・インスタンスを停止として報告した場合、クラスタ・リーダーは、過半数のサーバー・インスタンスを数えると、このサーバー・インスタンスがリーダーとしてその報告を承認したと見なします。

コンセンサス・リースは、過半数のサーバー・インスタンスが機能し続けることを必要とします。ネットワークがパーティション化されている場合、多数派のパーティションに含まれるサーバー・インスタンスは継続して実行されますが、少数派のパーティションに含まれるサーバー・インスタンスは、クラスタ・リーダーと通信できないか、サーバー・インスタンスの過半数が得られず新しいクラスタ・リーダーを選出できないために、自主的に停止します。パーティション化の結果サーバー・インスタンスが同数に分割されている場合は、クラスタ・リーダーを含むパーティションのサーバー・インスタンスは継続して実行されますが、もう一方のパーティションのサーバー・インスタンスは失敗します。コンセンサス・リーシングは、到達可能なサーバー・インスタンスの過半数の一部としてカウントするため、ノード・マネージャと通信してそれが管理するサーバー・インスタンスのステータスを受信する機能に依存します。ネットワーク接続が失われたか、ハードウェアの障害のため、ノード・マネージャに接続できない場合、管理対象のサーバー・インスタンスは、たとえ実行されていても、過半数を構成するサーバーとしてカウントされません。

注意:

クラスタに含まれるサーバー・インスタンスが2つのみである場合、多数派のパーティションがクラスタ・リーダーになります(ネットワーク分割が発生した場合)。クラスタ・リーダーが失敗すると、正常に実行されているサーバー・インスタンスは、ノード・マネージャを通じてそのステータスを確認しようとします。正常に実行されているサーバー・インスタンスが、失敗したクラスタ・リーダーのステータスを特定できる場合、クラスタ・リーダーのロールを引き受けます。マシンの障害またはネットワーク分割のため、正常に実行されているサーバー・インスタンスがクラスタ・リーダーのステータスを確認できない場合、自身が多数派であると確信が持てないため、自主的に停止します。

このようなシナリオを避けるため、最低でも、別のマシン上で実行されている3つのサーバー・インスタンスの使用をお薦めします。

サーバーの自動移行が有効化されている場合、サーバー・インスタンスはクラスタ・リーダーと通信して定期的にリースを更新する必要があります。リースを更新できなかった場合、サーバー・インスタンスは自らを停止します。次に、不具合のあるサーバー・インスタンスは、多数派のパーティションに含まれるマシンに自動的に移行されます。

サーバー全体の自動移行

この項では、サーバー全体の自動移行を構成する手順の概略を示し、WebLogic Server環境内でサーバー全体の移行機能をどのように使用するかについて説明します。

次のトピックを扱います。

- サーバー全体の自動移行の準備

- サーバー全体の自動移行の構成

- 状態データ用高可用性ストレージの使用

- サーバーの移行プロセスと通信

サーバー全体の自動移行の準備

サーバー全体の自動移行を構成する前に、次の要件について確認します。

- 使用するプラットフォームでサーバー全体の移行がサポートされていることを確認します。Oracle WebLogic Server、WebLogic PortalおよびWebLogic Integration 10gR3 (10.3)のサーバー移行のサポートに関する情報を参照してください。

注意:

Solarisゾーン機能を使用してSolaris 10システムでのサーバー全体の自動移行のサポートは、http://www.oracle.com/technetwork/middleware/ias/oracleas-supported-virtualization-089265.htmlの注意3:「Sun Solaris 10のマルチ・ゾーン操作におけるサポート」を参照してください。

- 各管理対象サーバーで、同じサブネット・マスクを使用します。サーバー間のユニキャスト通信およびマルチキャスト通信では、各サーバー・インスタンスが同じサブネットを使用している必要があります。マルチキャスト通信またはユニキャスト通信を構成しないと、サーバーの移行は機能しません。
マルチキャストの使用の詳細は、IPマルチキャストの使用を参照してください。ユニキャストの詳細は、「ユニキャストを使用した1対多通信」を参照してください

- 移行可能サーバーをホストするすべてのサーバー・インスタンスの時刻が同期していることを確認します。移行はサーバー・インスタンスの時刻が同期していなくても機能しますが、クラスタ化された環境では時刻が同期したサーバー・インスタンスをお薦めします。

- 移行可能サーバー間でオペレーティング・システムのバージョンが異なる場合は、すべてのバージョンでifconfigに対して同じ機能がサポートされていることを確認してください。

- サーバー全体の自動移行では、IPの移行および別のマシンでのサーバーの再起動のために、ノード・マネージャが構成されて実行している必要があります。

- 移行可能サーバーで使用するプライマリ・インタフェース名が同じです。環境内で異なるインタフェース名を使用しなければならない場合は、移行可能サーバーごとにwlscontrol.shのローカル・バージョンを構成します。
wlscontrol.shの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャを使用したサーバーの制御に関する項を参照してください。

- WebLogic Serverでサーバーの自動移行がサポートされるデータベースのリストは、Oracle WebLogic Server、WebLogic PortalおよびWebLogic Integration 10gR3 (10.3)のWebLogic Server機能をサポートするデータベースに関する情報を参照してください。

- ファイルをマシン間で転送するための、信頼できる組込みのメカニズムはありません。ファイルの可用性を確保するには、すべてのマシンからアクセス可能なディスクを使用することをお薦めします。サーバー・インスタンス間でディスクを共有できない場合は、domain_dir/binの内容が各マシンにコピーされていることを確認する必要があります。

- nmEnroll() WLSTコマンドを使用して、ノード・マネージャのセキュリティ・ファイルが各マシンにコピーされていることを確認します。詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャを使用したサーバーの制御に関する項を参照してください。

- 状態データの格納に、高可用性ストレージを使用します。高い信頼性を実現するために、ストレージ・エリア・ネットワーク(SAN)などの、高可用性の備わっている共有ストレージ・ソリューションを使用してください。「状態データ用高可用性ストレージの使用」を参照してください

- 本番環境におけるキャパシティ・プランニングでは、サーバー起動によってCPU使用率が影響されることに注意してください。1つのマシンが同時に一定数のサーバー・インスタンスの同時実行を処理できるという理由で、同じマシンが同数のサーバー・インスタンスの同時起動を処理できると見なすことはできません。

サーバー全体の自動移行の構成

サーバーの移行を構成する前に、お使いの環境が「サーバー全体の自動移行の準備」で説明されている要件を満たしていることを確認してください

クラスタ内の管理対象サーバーに対してサーバーの移行を構成するには、次のタスクを実行します。

1. 移行を有効にする各管理対象サーバーの浮動IPアドレスを取得します。

移行可能サーバーには、それぞれ浮動IPアドレスを割り当てる必要があります。このIPアドレスは、物理的なマシンが変わってもサーバー・インスタンスを追跡します。浮動IPアドレスが割り当てられるすべてのサーバー・インスタンスでは、AutoMigrationEnabledをtrueに設定することも必要です。

注意:

移行可能なIPアドレスは、移行可能サーバーが起動されるまではどの候補マシンのインタフェースでも提示されないようにします。

2. ノード・マネージャを構成します。ノード・マネージャは実行中でなければなりません。また、サーバーの移行を許可するように構成されている必要があります。

Javaバージョンのノード・マネージャはWindowsまたはUNIXでのサーバー移行に使用できます。スクリプトベースのバージョンのノード・マネージャはUNIXでのサーバー移行にのみ使用できます。

Javaベースのノード・マネージャを使用する際には、nodemanager.propertiesを編集してInterface値とNetMask値を使用環境に追加する必要があります。

環境に最適なInterface値を決定するには、オペレーティング・システム・ユーティリティを使用して、マシンで使用できるネットワーク・インタフェースのリストを検索します。Unixプラットフォームでは、通常ifconfigコマンドです。Windowsプラットフォームでは、通常ipconfigコマンドです。

NetMaskを決定するには、同じサブネット上ですべてのトラフィックを発生させるために、その同じインタフェースのアドレスに対してすでに構成されている同じNetMask値を使用できます。また、共通のNetMask値を指定することもできるため、すべてのWebLogic Serverトラフィックに対するサブネットを指定できます。

nodemanager.propertiesファイルは、NodeManagerHomeで指定されるディレクトリ(通常ORACLE_HOME\user_projects\domains\domain_name\nodemanagerまたはORACLE_HOME\oracle_common\common\nodemanager)に格納されています。nodemanager.propertiesの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のnodemanager.propertiesの検討に関する項を参照してください。

スクリプトベースのバージョンのノード・マネージャを使用する場合は、wlscontrol.shを編集して、Interface変数をネットワーク・インタフェースの名前に設定します。

サーバーの移行でのノード・マネージャの使用に関する一般的な情報は、「サーバー全体の移行におけるノード・マネージャの役割」を参照してくださいノード・マネージャの一般的な情報は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャの概要に関する項を参照してください。

3. データベースを使用してリース情報を管理する場合は、「高可用性データベース・リース」の手順に従って、サーバーの移行に使用するデータベースを構成しますリースの全般的な情報については、「リース」を参照してください

4. データベース・リースをテスト環境内で使用しており、リース表をリセットする必要がある場合は、leasing.ddlスクリプトを再実行する必要があります。リセットによって、適切な表が削除されて再作成されます。

5. データベースを使用してリース情報を格納する場合は、「高可用性データベース・リース」の手順に従って、データ・ソースを設定して構成します

各クラスタの構成で、DataSourceForAutomaticMigrationをこのデータ・ソースに設定してください。

注意:

サーバーの移行では、XAデータ・ソースはサポートされていません。

JDBCデータ・ソースの作成の詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のJDBCデータ・ソースの構成に関する項を参照してください。

6. wlsifconfig.shスクリプト(UNIX)またはwlsifconfig.cmdスクリプト(Windows)にスーパーユーザー権限を付与します。

このスクリプトは移行中、IPアドレスを一つのマシンから別のマシンへ転送するとき使用されます。通常スーパーユーザーのみが利用可能なifconfigの実行が可能でなければなりません。sudoを使用して起動されるように、このスクリプトを編集できます。

Javaベースのノード・マネージャはwlsifconfig.cmdスクリプトを使用します。このスクリプトではnetshユーティリティが使用されます。

wlsifconfigスクリプトは、WL_HOME/common/binディレクトリまたはDOMAIN_HOME/bin/server_migrationディレクトリにあります。

7. 次のコマンドが使用するマシンのPATHに含まれていることを確認してください。

- wlsifconfig.sh (UNIX)またはwlsifconfig.cmd (Windows)

- wlscontrol.sh (UNIX)

- nodemanager.domains

wlsifconfig.shファイル、wlsifconfig.cmdファイルおよびwlscontrol.shファイルは、WL_HOME/common/binまたはDOMAIN_HOME/bin/server_migrationにあります。nodemanager.domainsファイルは、NodeManagerHomeで指定されているディレクトリにあります。Javaベースのノード・マネージャの場合、NodeManagerHomeは通常ORACLE_HOME\user_projects\domains\domain_name\nodemanagerまたはORACLE_HOME\oracle_common\common\nodemanagerにあります。スクリプト・ベースのノード・マネージャの場合、このファイルのデフォルトのNodeManagerHomeの場所は、WL_HOME/common/nodemanagerです。ここで、WL_HOMEはWebLogic Serverがインストールされている場所(ORACLE_HOME/wlserverなど)です。

.shスクリプトの最初の行は、UNIXで使用するデフォルトのシェルに応じて編集する必要があります。

8. この手順は、スクリプトベースのバージョンのノード・マネージャとUNIXにのみ適用されます。Windowsを使用している場合は、ステップ9に進んでください。

移行可能サーバーをホストするマシンは相互に信頼性がある必要があります。移行が行われるためには、ユーザー名とパスワードを明示的に入力する必要なしに、マシンBから「ssh/rsh machine_A」を使用して(同様にマシンAから「ssh/rsh machine_B」を使用して)シェル・プロンプトにアクセスできる必要があります。また、各マシンはSSHを使用して同じ方法で自身に接続できる必要があります。

注意:

シェルが対話型である場合は、ログイン・スクリプト(.cshrc、.profile、.loginなど)がシェル・プロファイルからのメッセージのみをエコーすることを確認してください。WebLogic Serverでは、sshコマンドを使用して、ログインしserver.stateファイルの内容をエコーします。この出力の最初の行のみがサーバーの状態の決定に使用されます。

9. サーバーの移行用の候補マシンを設定します。サーバー・インスタンスごとに異なる候補マシンのセットを設定、またはすべてのサーバー・インスタンスに同じセットを設定できます。

10. 管理サーバーを再起動します。

状態データ用高可用性ストレージの使用

サーバーの移行プロセスでは、サービスは移行されますが、障害の発生時に進行中だった作業に関連付けられた状態情報は移行されません。

高可用性を確保するには、こうした状態情報を移行後にサーバー・インスタンスやそれがホストするサービスで使用できるようにすることが重要です。そうしないと、障害の発生時に進行中だった作業に関するデータが失われてしまうおそれがあります。移行可能サーバーによって保持される状態情報(トランザクション・ログに格納されるデータなど)は、移行可能サーバーで障害が発生した場合にその移行先となる可能性のあるすべてのマシンからアクセスできる共有ストレージ・システムに格納する必要があります。高い信頼性を実現するために、ストレージ・エリア・ネットワーク(SAN)などの、高可用性の備わっている共有ストレージ・ソリューションを使用してください。

また、データベースを使用してリース情報を格納する場合は、リース表(次の項を参照)も高可用性データベースに格納する必要があります。リース表は移行可能なサーバーのヘルスや利用の可能性を追跡します。詳細は、「リース」を参照してください

サーバーの移行プロセスと通信

これ以降の項では、移行可能なサーバーを含むクラスタにおける主要なプロセスについて説明します。

- 移行可能サーバーのあるクラスタの起動プロセス

- サーバー全体の自動移行のプロセス

- サーバー全体の手動移行のプロセス

移行可能サーバーのあるクラスタの起動プロセス

図7-1に、移行可能なサーバーを含むクラスタの起動時に発生するプロセスと通信を示します。

例のクラスタには2つの管理対象サーバーが含まれており、それらは両方とも移行可能です。管理サーバーと2つの管理対象サーバーは、それぞれ別々のマシンで実行されています。4つ目のマシンは、いずれかの移行可能なサーバーで障害が発生した場合にバックアップとして使用できます。バックアップ・マシンと移行可能サーバーが実行されている各マシンでは、ノード・マネージャが実行されています。

図7-1 移行可能サーバーのあるクラスタの起動

図7-1に示されているように、クラスタの起動時には、次の主要なステップが発生します。

1. 管理者がクラスタを起動します。

2. 管理サーバーが、管理対象サーバー1を起動するためにマシンB上のノード・マネージャを呼び出し、管理対象サーバー2を起動するためにマシンC上のノード・マネージャを呼び出します。「サーバー全体の移行における管理サーバーの役割」を参照してください

3. 各マシン上のノード・マネージャのインスタンスが、そのマシン上で実行する管理対象サーバーを起動します。「サーバー全体の移行におけるノード・マネージャの役割」を参照してください

4. 管理対象サーバー1および2が、管理サーバーにアクセスしてそれぞれの構成を取得します。「クラスタでの移行可能サーバーの動作」を参照してください

5. 管理対象サーバー1と2が、起動時の構成をキャッシュします。

6. 管理対象サーバー1および2がそれぞれ、移行可能サーバーのリースをリース表から取得します。管理対象サーバー1がまず起動するので、管理対象サーバー1はクラスタ・マスターのリースも取得します。「サーバー全体の移行におけるクラスタ・マスターの役割」を参照してください

7. 管理対象サーバー1および2が、リース表の各自のリースを定期的に更新し、自身のヘルス状態と自身が使用可能であることを示します。

サーバー全体の自動移行のプロセス

図7-2に、管理対象サーバー2をホストしているマシンで障害が発生した後の自動移行のプロセスを示します。

図7-2 障害が発生したサーバーの自動移行

1. 管理対象サーバー2をホストしているマシンCで障害が発生します。

2. 次回の定期的なリース表の確認時に、クラスタ・マスターが管理対象サーバー2のリースが期限切れになっていることを検出します。「サーバー全体の移行におけるクラスタ・マスターの役割」を参照してください

3. クラスタ・マスターが、管理対象サーバー2を再起動するためにマシンC上のノード・マネージャにアクセスしようとしますが、マシンCはアクセスできなくなっているためアクセスは失敗します。

注意:

サーバーのハングが原因で、管理対象サーバー2のリースが期限切れになったとき、マシンCにアクセスできる場合は、クラスタ・マスターはノード・マネージャを使用してマシンC上の管理対象サーバー2を再起動します。

4. クラスタ・マスターが、マシンD上のノード・マネージャにアクセスします。マシンDはクラスタ内の移行可能サーバーのホストとして使用できるように構成されています。

5. マシンD上のノード・マネージャが管理対象サーバー2を起動します。「サーバー全体の移行におけるノード・マネージャの役割」を参照してください

6. 管理対象サーバー2が起動し、管理サーバーにアクセスして自身の構成を取得します。

7. 管理対象サーバー2は、起動時の構成をキャッシュします。

8. 管理対象サーバー2が、移行可能サーバーのリースを取得します。

移行する管理対象サーバーのクライアントでは、移行中にサービスの短い中断が発生するおそれがあります。その場合、再接続が必要になることもあります。SolarisおよびLinuxオペレーティング・システムでは、ifconfigコマンドを使用して再接続を行うことができます。移行されたサーバーのクライアントは、サーバーの移行先の特定のマシンを認識する必要はありません。

移行されたサーバー・インスタンスを移行前にホストしていたマシンが再び使用可能になった場合、移行プロセスの逆戻し(サーバー・インスタンスを元のホスト・マシンに移行して戻すこと)を行うことができます。これを、フェイルバックと呼びます。WebLogic Serverではフェイルバックのプロセスは自動化されていません。管理者は、サーバー・インスタンスを元のホストに手動で戻すことでフェイルバックを実行できます。

サーバー・インスタンスを元のホストに復元する一般的な手順は次のとおりです。

- サーバーの新しいインスタンスを正常に停止します。

- 障害が発生していたマシンを再起動した後に、ノード・マネージャと管理対象サーバーを再起動します。

詳細な手順は、サーバー・インスタンスおよびネットワーク環境によって異なります。

サーバー全体の手動移行のプロセス

図7-3に、管理者が移行可能サーバーを手動で移行するときに発生するプロセスと通信を示します。

図7-3 サーバー全体の手動移行

1. 管理者がWebLogic Server管理コンソールを使用して、マシンCからマシンBへの管理対象サーバー2の移行を開始します。

2. 管理サーバーがマシンC上のノード・マネージャにアクセスします。「サーバー全体の移行における管理サーバーの役割」を参照してください

3. マシンC上のノード・マネージャが、管理対象サーバー2を停止します。

4. 管理対象サーバー2がリース表から自身の行を削除します。

5. 管理サーバーがマシンB上のノード・マネージャを呼び出します。

6. マシンB上のノード・マネージャが、管理対象サーバー2を起動します。

7. 管理対象サーバー2が管理サーバーから自身の構成を取得します。

8. 管理対象サーバー2は、起動時の構成をキャッシュします。

9. 管理対象サーバー2がリース表に行を追加します。

サーバー全体の移行における管理サーバーの役割

移行可能サーバーを含むクラスタでは、管理サーバーは:

- 移行可能サーバーを起動するために、クラスタのメンバーをホストする各マシン上のノード・マネージャを呼び出します。この動作は、サーバーの移行性の前提条件です。最初にノード・マネージャによって起動されていない場合、そのサーバー・インスタンスは移行できません。

- 移行可能サーバーを停止および起動するために、手動による移行プロセスに関係する各マシン上のノード・マネージャを呼び出します。

- 通常の停止時にサーバー・インスタンスを停止するために、クラスタのメンバーをホストする各マシン上のノード・マネージャを呼び出します。この動作は、サーバーの移行性の前提条件です。ノード・マネージャを使用せずにサーバー・インスタンスを直接停止した場合、クラスタ・マスターは、そのサーバー・インスタンスが実行されていないことを検出したときに、ノード・マネージャを呼び出してそのサーバー・インスタンスを再起動します。

さらに管理サーバーには、管理者によって発行された構成の更新の保持、ドメインの実行時情報の表示などの、ドメイン内の移行可能サーバーも含めた通常のドメイン管理機能があります。

クラスタでの移行可能サーバーの動作

移行可能サーバーとは、移行可能として構成されている、クラスタ化された管理対象サーバーのことです。移行可能なサーバーには、次の主要な動作があります。

- データベースを使用してリース情報を管理する場合は、ノード・マネージャによる起動時および再起動時にリース表に行を追加します。移行可能サーバーの行には、タイムスタンプや、それが実行されているマシン名が記載されます。
リースの詳細は、「リース」を参照してください

- データベースを使用してリース情報を管理する場合には、移行可能なサーバーにより起動の結果としてデータベースに1行追加されます。クラスタ・マスターのロールの取得を試行し、それがクラスタに最初に参加するサーバー・インスタンスの場合には成功します。

- リース表のタイム・スタンプを更新することで、リースを定期的に更新します。
デフォルトでは、移行可能サーバーは30,000ミリ秒ごとにリースを更新します。このデフォルト値は、次の2つの構成可能なServerMBeanプロパティ値を掛け合わせた値です。

- HealthCheckIntervalMillis (デフォルトは10,000)

- HealthCheckPeriodsUntilFencing (デフォルトは3)

- 期限切れになる前にリース表にアクセスしてリースを更新できなかった場合は、移行可能サーバーはJava System.exitを使用してできるだけ迅速に終了します。この場合は、リース表にはそのサーバー・インスタンス用の行が引き続き格納されます。この動作と自動移行の関連の詳細は、「サーバー全体の移行におけるクラスタ・マスターの役割」を参照してください

- 動作時に、クラスタ・マスターからのハートビートをリスニングします。クラスタ・マスターがハートビートを送信していないことを検出すると、移行可能なサーバーはクラスタ・マスターのロールを引き受けようとし、他のサーバー・インスタンスがクラスタ・マスターになることをリクエストしていない場合にクラスタ・マスターとなります。

注意:

サーバー移行時に、サーバー起動によってCPU使用率が上昇することに注意してください。1つのマシンが同時に一定数のサーバー・インスタンスの同時実行をサポートできるという理由で、同じマシンが同数のサーバー・インスタンスの同時起動をサポートできると見なすことはできません。

サーバー全体の移行におけるノード・マネージャの役割

ノード・マネージャの使用は、サーバーの移行に不可欠です。それは、ホストとなる(またはホストとなる予定の)各マシン上で実行する必要があります。

ノード・マネージャは、次のようにサーバーの移行をサポートします。

- 移行可能サーバーの最初の起動には、ノード・マネージャを使用する必要があります。
WebLogic Server管理コンソールから管理対象サーバーの起動を開始すると、管理サーバーがノード・マネージャを使用してそのサーバー・インスタンスを起動します。ノード・マネージャを呼び出して、スタンドアロンのノード・マネージャ・クライアントを使用してサーバー・インスタンスを起動することもできます。ただし、起動する管理対象サーバーが自身の構成を取得するために管理サーバーが使用可能になっている必要があります。

注意:

最初にノード・マネージャによって開始していないサーバー・インスタンスの移行は失敗します。

- ノード・マネージャを使用して、移行可能なサーバーを一時停止、停止または強制停止する必要があります。

- ノード・マネージャは、リースが期限切れになっている移行可能サーバーを障害の発生時に実行されていたマシン上で再起動しようとします。
ノード・マネージャは、WebLogic Serverに用意されたカスタマイズ可能なシェル・スクリプトを実行することで、サーバーの移行プロセスのステップを実行します。これらのスクリプトは、サーバー・インスタンスを起動、再起動、停止し、IPアドレスを移行し、ディスクをマウントおよびアンマウントすることが可能です。これらのスクリプトは、SolarisおよびLinuxで使用できます。

- 自動移行では、クラスタ・マスターがノード・マネージャを呼び出して移行を実行します。

- 手動による移行では、管理サーバーがノード・マネージャを呼び出して移行を実行します。

サーバー全体の移行におけるクラスタ・マスターの役割

移行可能サーバーを含むクラスタでは、1つのサーバー・インスタンスがクラスタ・マスターとして機能します。クラスタ・マスターは、サーバーの移行プロセスを調整する役割を担います。クラスタ内のどのサーバー・インスタンスもクラスタ・マスターになることができます。移行可能サーバーを含むクラスタの起動時に、クラスタに参加した最初のサーバー・インスタンスがクラスタ・マスターになり、クラスタ・マネージャ・サービスを起動します。クラスタに移行可能サーバーが1つも含まれない場合はクラスタ・マスターは不要で、クラスタ・マネージャ・サービスは起動されません。クラスタ・マスターが存在しなくても、移行可能サーバーは動作を継続できますが、サーバーの移行はできません。クラスタ・マスターは、次の主要な機能を実行します。

- クラスタ内の他のサーバー・インスタンスに定期的なハートビートを発行します。

- 定期的にリース表を読み込み、移行可能サーバーのそれぞれに現在のリースがあることを確認します。期限切れになったリースによって、クラスタ・マスターはその移行可能サーバーを再起動する必要があると認識します。

- 移行可能サーバーのリースが期限切れになっていると判断すると、クラスタ・マスターはClusterMBeanのFencingGracePeriodMillisで指定された期間、待機します。その後、リースが期限切れになっている移行可能サーバーをホストするマシン上でノード・マネージャ・プロセスを呼び出してその移行可能サーバーの再起動を試行します。

- リースが期限切れになっている移行可能サーバーを再起動できない場合、クラスタ・マスターは次の方法でターゲット・マシンを選択します。

- 移行可能サーバーの優先宛先マシンのリストが作成されている場合は、クラスタ・マスターは、リストでのマシンの並び順に従ってリストからマシンを選択します。

- それ以外の場合は、クラスタ内の移行可能サーバーのホストとして使用できるように構成されているマシンのリストからマシンを選択します。
移行可能なサーバーをホストできるマシンのリストは、2つのレベル(クラスタ全体用と個々の移行可能なサーバー用)で構成できます。両方のレベルのマシン・リストを定義できます。少なくとも一方のレベルでマシン・リストを定義する必要があります。

- 新しいマシンへのサーバー・インスタンスの移行を実行するために、クラスタ・マスターは、ターゲット・マシン上でノード・マネージャ・プロセスを呼び出してサーバー・インスタンスのプロセスを作成します。
移行の実行に必要な時間は、サーバーの構成および起動時間によって異なります。

- クラスタ・マスターが移行可能サーバーを再起動するのにかかる最大時間は、(HealthCheckPeriodsUntilFencing * HealthCheckIntervalMillis) + FencingGracePeriodMillisです。

- サーバー・インスタンスがクライアント・リクエストに対して使用可能になるまでの合計時間は、サーバーの起動時間およびアプリケーションのデプロイメント時間によって決まります。

動的クラスタおよび複合クラスタでのサーバー全体の移行

WebLogic Serverでは、動的クラスタおよび複合クラスタでのサーバー全体の移行がサポートされています。動的クラスタ内の動的サーバーで障害が発生すると、構成済クラスタまたは複合クラスタ内で構成済のサーバーと同じように、サーバー・インスタンスが別の物理マシンへ移行されます。クラスタの種類に応じて構成は異なりますが、サーバー全体の移行の動作はすべてのクラスタで同じです。動的クラスタおよび複合クラスタに関する詳細は、「動的クラスタ」を参照してください。

サーバー全体の自動移行ではリースを使用して、クラスタ・マスターが選出されます。クラスタ・マスターは、別のクラスタ・メンバーのモニターおよび別の物理マシンでホストされるメンバーに障害が発生した場合の再起動を担当します。クラスタ構成でリースを構成します。詳細は、「リース」を参照してください

動的クラスタでのサーバー全体の移行の構成

構成済クラスタに対してサーバー全体の自動移行を構成する際には、移行できるようにするサーバー・インスタンスを個別に選択します。障害発生時にサーバー・インスタンスを移行するために使用可能なマシンのサブセットも選択します。

動的クラスタでは、サーバー・テンプレートでサーバー全体の自動移行を有効または無効にします。動的クラスタは、単一のサーバー・テンプレートを使用してその構成を定義し、動的クラスタ内のすべての動的サーバー・インスタンスがテンプレートの構成を継承します。動的クラスタのサーバー・テンプレート内でサーバー全体の自動移行が有効な場合、そのサーバー・テンプレートに基づいたすべての動的サーバー・インスタンスがサーバー全体の自動移行に対して有効になります。動的サーバー・インスタンスを個別に選択して移行することはできません。

また、移行先のマシンは選択できません。サーバー・テンプレートで動的クラスタに対してサーバー全体の自動移行を有効化すると、移行のために使用できるすべてのマシンが自動的に選択されます。

サーバー・テンプレートで候補マシンがリストされていないため、動的クラスタが指定する移行の候補マシンのリストを制限することはできません。各動的サーバーに対する候補マシンのリストは、次のように計算されます。

ClusterMBean.CandidateMachinesForMigratableServers = { M1, M2, M3 }

dyn-server-1.CandidateMachines = { M1, M2, M3}
dyn-server-2.CandidateMachines = { M2, M3, M1 }
dyn-server-3.CandidateMachines = { M3, M1, M2 }
dyn-server-4.CandidateMachines = { M1, M2, M3 }

WebLogic Server管理コンソールを使用して動的クラスタに対してサーバー全体の自動移行を有効にするには:

1. WebLogic Server管理コンソールの左ペインで、「環境」→「クラスタ」→「サーバー・テンプレート」の順に選択します。

2. 「サーバー・テンプレート」表で、動的クラスタのサーバー・テンプレートを選択します。

3. 「構成」→「移行」の順に選択します。

4. 「サーバーの自動移行を有効化」属性を選択します。

複合クラスタでのサーバー全体の移行の構成

複合クラスタには動的サーバーと構成済サーバーの両方が含まれます。複合クラスタに対してサーバー全体の自動移行を有効にするには:

1. 動的サーバー・インスタンスが複合クラスタ内で使用するサーバー・テンプレート内でサーバー全体の自動移行を有効化します。

そのサーバー・テンプレートに基づいたすべての動的サーバー・インスタンスがサーバー全体の自動移行に対して有効になります。

2. クラスタ内で任意の構成済サーバー・インスタンスに対してサーバー全体の自動移行を手動で有効化し、サーバー・インスタンスに障害が発生した場合に移行するマシンを選択します。

8 サービスの移行

この章では、WebLogic Serverでサポートされているサービス移行メカニズムについて説明します。

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

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

- 移行前の要件

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

- サービスの自動移行の構成でJMSをターゲット指定する際のベスト・プラクティス

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

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

- JTAトランザクション・リカバリ・サービスの手動移行

- ユーザー定義のシングルトン・サービスの自動移行

この章では、主に障害が発生したサービスの移行について説明します。WebLogic Serverでは、サーバーで障害が発生した場合に、サーバー全体を移行することも可能です。このサーバー全体の移行では、移行可能なサーバー・インスタンスとそのすべてのサービスを、物理的に別のマシンに移行します。失敗したサーバー移行の詳細は、「サーバー全体の移行」を参照してください。

WebLogic Serverでは、アプリケーション・レベルでのレプリケーションやフェイルオーバーもサポートされています。詳細は、「クラスタのフェイルオーバーとレプリケーション」を参照してください。

注意:

Solarisゾーン機能を使用してSolaris 10システムでのサーバー全体の自動移行のサポートは、http://www.oracle.com/technetwork/middleware/ias/oracleas-supported-virtualization-089265.htmlの注意3:「Sun Solaris 10のマルチ・ゾーン操作におけるサポート」を参照してください。

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

WebLogic Serverクラスタでは、ほとんどのサブシステム・サービスがクラスタ内のすべてのサーバー・インスタンスで均一にホストされます。これにより、サーバー間の透過的なフェイルオーバーが可能になります。対照的に、JMS関連のサービス、JTAトランザクション・リカバリ・サービス、およびユーザー定義のシングルトン・サービスなどの固定サービスは、クラスタ内の個別のサーバー・インスタンスでホストされます - これらのサービスについて、WebLogic Server移行フレームワークでは、フェイルオーバーとは対照的なサービス移行による障害リカバリがサポートされています。「移行可能サービス」を参照してください。

WebLogic Serverにおけるサービス・レベルの移行とは、あるサーバー・インスタンスに固定されているサービスを、クラスタ内の使用可能な別のサーバー・インスタンスに移動するプロセスです。サービス・レベルの移行は、論理的な移行可能ターゲットにより制御されます。移行可能ターゲットは、クラスタ内のいずれか1つの物理サーバー・インスタンスでホストされているサービスのグループとして機能します。特定の固定サービスをターゲット指定する場合には、サーバー・インスタンスやクラスタを選択するかわりに移行可能ターゲットを選択できます。元のサーバー・インスタンスで問題が発生した場合に、移行可能なターゲットをあるクラスタ化サーバー・インスタンスから別のクラスタ化サーバー・インスタンスに移行することにより、高可用性が実現します。また、定期的な保守を行うために移行可能ターゲットを手動で移行したり、自動移行が行われるように移行可能ターゲットを構成したりできます。「クラスタ内の移行可能ターゲットの理解」を参照してください

移行フレームワークは、ターゲットを構成および移行するためのツールとインフラストラクチャを提供します。また、サービスの自動移行の場合は、WebLogic Serverのヘルス・モニタリング・サブシステムを使用して、移行可能ターゲットでホストされているサービスの状態をモニターします。「移行処理ツール」および「サービス自動移行インフラストラクチャ」を参照してくださいサーバーおよびサービスの移行に関する用語の定義は、「移行関連の用語」を参照してください

移行可能サービス

WebLogic Serverでは、JMS関連サービス、JTAトランザクション・リカバリ・サービス、およびユーザー定義のシングルトン・サービスのサービス・レベルの移行がサポートされています。これらのサービスは、クラスタ内のあるサーバー・インスタンスから別のサーバー・インスタンスに移すことができるため移行可能サービスと呼ばれます。自動移行または手動移行では、次の移行可能サービスを構成できます。

JMS関連サービス

これらは移行可能なJMSサービスです。

- JMSサーバー - ターゲット指定されているJMSモジュール内のキューおよびトピックの管理コンテナです。『Oracle WebLogic Server JMSリソースの管理』のJMSサーバー構成に関する項を参照してください。

- ストア・アンド・フォワード(SAF)サービス - メッセージが送信された時点でリモート・エンドポイントが使用できない場合でも、ローカルの送信エンドポイントとリモートの受信エンドポイントの間でメッセージをストア・アンド・フォワードするサービスです。JMS SAF(送信機能のみ)用に構成された送信SAFエージェントのみを移行できます。『Oracle WebLogic Serverストア・アンド・フォワード・サービスの管理』を参照してください。

- パス・サービス - JMSメッセージ順序単位内のメッセージのグループからクラスタ内のメッセージ・リソースへのマッピングを保持するために使用できる永続マップです。サーブレットをホストするクラスタのメンバー、分散キュー・メンバーまたはストア・アンド・フォワード・エージェントにメッセージを固定することによって順序付けを実現できます。パス・サービスは、クラスタごとに1つずつ構成します。『Oracle WebLogic Server JMSリソースの管理』のWebLogicパス・サービスの使用に関する項を参照してください。

- カスタム永続ストア - ユーザーが定義するディスク・ベースのファイル・ストアまたは永続JMSメッセージやストア・アンド・フォワード・メッセージなどのサブシステム・データを格納するためのJDBC対応データベースです。WebLogic永続ストアの管理を参照してください。

クラスタのターゲット指定JMSサービスは、クラスタのメンバーに分散されます。クラスタのターゲット指定サービスをクラスタ・メンバー間で動的に自動で移行するようにWeblogic Serverを構成できます。『Oracle Fusion Middleware Oracle WebLogic Server JMSリソースの管理』のJMSクラスタと高可用性の簡略化された構成に関する項を参照してください。

シングルトンJMSサービスが原因で、クラスタ内の依存するアプリケーションに対するシングル・ポイント障害が発生しないようにするため、シングルトン・サービスを移行可能ターゲット・リスト内の任意のサーバー・インスタンスに自動または手動で移行できるようにWebLogic Serverを構成できます。「JMS関連サービスの自動移行を構成する手順」および「JMS関連サービスの手動移行を構成する手順」を参照してください。

JTAトランザクション・リカバリ・サービス

トランザクション・リカバリ・サービスは、システム起動時にトランザクションのリカバリを自動的に試行します。すべてのトランザクション・ログ・レコードを解析し、未完了のトランザクションを完了させます。詳細は、『Oracle WebLogic Server JTAアプリケーションの開発』のサーバーに障害が発生した場合のトランザクション・リカバリに関する項を参照してください。

ユーザー定義のシングルトン・サービス

アプリケーション内に、クラスタの複数のメンバーで同時に実行したくないタスクを実行するためのシングルトン・サービスを定義できます。「ユーザー定義のシングルトン・サービスの自動移行」を参照してください

クラスタ内の移行可能ターゲットの理解

注意:

動的クラスタを構成する場合、JMSサービスの移行動作を決定する移行ポリシーをカスタム永続ストア・レベルで指定できます。詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSリソースの管理』のJMSクラスタと高可用性の簡略化された構成に関する項を参照してください。

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

移行可能ターゲットでは、ターゲットをホストできるサーバー・インスタンスのセットを指定します。必要に応じて、そのサービスを優先的にホストするサーバー・インスタンスを指定したり、その優先サーバー・インスタンスで障害が発生した場合のバックアップ・サーバー候補を順序付けしたリストを指定したりできます。どの時点でも、これらのサーバー・インスタンスのうち1つのみが、移行可能ターゲットをホストできます。

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

管理者は、サーバー障害へのレスポンスとして、あるいは定期的な保守の一環として、固定された移行可能サービスをクラスタ内のサーバー間で手動で移行できます。クラスタ内に移行可能ターゲットを構成しない場合、移行可能サービスは、クラスタ内のどのWebLogic Serverインスタンスにでも移行できます。「JMS関連サービスの手動移行を構成する手順」を参照してください

手動および自動のサービス移行ポリシー

移行可能ターゲットでは、ヘルス・モニタリング・サブシステムを利用して、ホストしているサービスが異常なホスト・サーバー・インスタンスから正常なアクティブ・サーバー・インスタンスに手動で移行されるか(システムのデフォルト)、自動で移行されるかを定義した移行ポリシーを提供しています。自動サービス移行ポリシーには、次の項で説明するように2つのタイプがあります。

手動移行

移行可能ターゲットでmanualポリシー(システムのデフォルト)を使用している場合、管理者は、サーバーの障害へのレスポンスとして、あるいは定期的な保守の一環として、固定された移行可能サービスをクラスタ内のサーバー間で手動で移行できます。

「JMS関連サービスの手動移行を構成する手順」を参照してください

Exactly-Once

このポリシーでは、候補リスト内の1つ以上の管理対象サーバーが実行中である場合、サーバー・インスタンスで障害が発生するかサーバー・インスタンスが停止(正常停止または強制停止)されても、サービスはクラスタ内のどこかでアクティブになります。この値を使用すると、ターゲットのグループ化が生じることに注意してください。たとえば、exactly-onceの移行可能ターゲットが5つあるときに、クラスタ内の1つの管理対象サーバーのみを起動すると、5つのターゲットすべてがそのサーバー・インスタンス上でアクティブ化されます。

注意:

ベスト・プラクティスとして、パス・サービスをホストする移行可能ターゲットは常にexactly-onceに設定してください。そのホスト・サーバー・メンバーで障害が発生するかサーバー・メンバーが停止した場合、パス・サービスは自動的に別のサーバー・インスタンスに移行されるので、クラスタ内で常にアクティブになります。

JMSサーバーでのサンプル・ユース・ケース:

ドメイン内に3つの管理対象サーバーから成るクラスタがあり、1つのJMSサーバーがクラスタ内の1つのメンバー・サーバーにデプロイされています。クラスタにデプロイされているアプリケーションはそのJMSサーバーにターゲット指定されているキューにメッセージを送信します。他のドメインのMDBは、JMSサーバーに関連付けられているキューを消費します。MDBは同一のキューの複数のインスタンスではなく、キューの一つのセットから消費します。つまり、この環境でクラスタリングを使用しているのは、アプリケーションのためにスケーラビリティ、ロード・バランシング、フェイルオーバーを実現するためで、JMSサーバーのためではありません。したがって、この環境では、JMSサーバーをExactly-Onceサービスとして使用可能なクラスタ・メンバーに自動移行するのが適しています。

「JMS関連サービスの自動移行を構成する手順」を参照してください

Failure-Recovery

このポリシーでは、ユーザー優先サーバー(UPS)が起動されている場合にのみサービスが開始されます。管理者が手動でUPSを停止(正常停止または強制停止)した場合、failure-recoveryサービスは移行されません。ただし、UPSで内部エラーによる障害が発生した場合、failure-recoveryサービスは別の候補サーバー・インスタンスに移行されます。手動停止または内部エラーにより候補サーバー・インスタンスが使用できない場合、移行フレームワークはまず、UPSサーバー上でサービスを再アクティブ化しようとします。UPSサーバーがその時点で使用できない場合、サービスは別の候補サーバー・インスタンスに移行されます。

クラスタのターゲット指定JMSサービスの移行の場合、障害リカバリ・パラメータでストアを構成できます。

JMSサーバーでのサンプル・ユース・ケース:

ドメイン内に3つの管理対象サーバーから成るクラスタがあります。各メンバー・サーバー上にJMSサーバーがあり、各JMSサーバー上には分散キュー・メンバーがあります。また、このクラスタには、ローカルのサーバー・メンバー上にある分散キュー・メンバーからメッセージを消費するMDBがターゲット指定されています。つまり、この環境では全体的なスケーラビリティ、ロード・バランシング、フェイルオーバーを実現するためにクラスタリングを使用しています。したがって、この環境では、JMSサーバーをfailure-recoveryサービスとしてUPSメンバーに自動移行するのが適しています。

注意:

サーバー全体の自動移行フレームワークを使用するようにサーバー・インスタンスが構成されている場合、期限切れのリースが更新されないとサーバーが停止されます。そのとき、サーバー・インスタンス上で構成されているfailure-recoveryサービスは、サーバー・インスタンスが管理者によって手動停止(強制停止または正常停止)された場合でも、自動移行されなくなります。詳細は、「サーバー全体の自動移行」を参照してください

「JMS関連サービスの自動移行を構成する手順」を参照してください

障害が発生したサービスを移行前に再起動するオプション

移行可能ターゲットでは、サービスを移行する代わりに、障害が発生したサービスの非アクティブ化と再アクティブ化を試行するオプションが提供されています。「障害が発生した移行可能サービスのインプレースでの再起動」を参照してください

移行可能ターゲットのすべてのオプションのデフォルト値は、Oracle WebLogic Server MBeanリファレンスのMigratableTargetMBeanに関する項を参照してください。

優先サーバーと候補サーバー

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

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

クラスタ内の移行可能ターゲットの例

図8-1では、3つの管理対象サーバーから成るクラスタを示しています。すべての管理対象サーバーが移行可能ターゲットをホストしています。サーバーAは、JMSサーバーA (と2つのキュー)とカスタム・ストアに対する移行可能ターゲット(MT1)をホストしています。サーバーBは、パス・サービスとカスタム・ストアに対するMT2をホストし、JMSサーバーB (と2つのキュー)とカスタム・ストアに対するMT3もホストしています。サーバーCは、JMSサーバーC (と2つのキュー)とカスタム・ストアに対するMT4をホストしています。

すべての移行可能ターゲットが自動的に移行されるように構成されており、MT1、MT3、MT4ターゲットではfailure-recoveryポリシーが、MT2ターゲットではexactly-onceポリシーが使用されます。

図8-1 クラスタ内の移行可能ターゲット

上の例では、MT2 exactly-onceターゲットによって、候補リスト内の実行中の管理対象サーバー上で自動的にパス・サービスとストアが開始されます。このように、ホスト・サーバーで障害が発生した場合、ターゲットのユーザー優先サーバー(UPS)が正常停止されたとしても、サービスは常にクラスタ内のどこかでアクティブなることが保証されています。ただし、「手動および自動のサービス移行ポリシー」,で説明したように、このポリシーを使用すると、1つのサーバー・インスタンスにホストされている複数のJMSサービスでターゲットのグループ化が生じる可能性があります。

一方、UPSが正常停止または強制停止された場合、failure-recoveryターゲットであるMT1、MT3、MT4はUPS上で自動的にJMSサーバーとストア・サービスを開始しますが、固定サービスはどこにも移行されません。ただし、UPSが内部エラーによって停止した場合、サービスは別の候補サーバーに移行されます。

JMSサーバーのターゲット指定ルール

移行可能ターゲットを使用しない場合、JMSサーバーは、動的クラスタまたは特定のクラスタ・メンバーにターゲット指定でき、カスタム・ストアを使用できます。一方、移行可能ターゲットにターゲット指定する場合は、JMSサーバーでカスタム永続ストアを使用し、そのカスタム・ストアで使用する移行可能ターゲットにJMSサーバーをターゲット指定する必要があります。JMSサーバー、SAFエージェント、およびカスタム・ストアは、1つの移行可能ターゲットを共有できます。「JMSサービスで使用できるカスタム・ストア」を参照してください

WebLogic Serverは、クラスタ内のサーバー・インスタンスごとに移行可能ターゲットを作成し、JMSシステム・リソース・ターゲットがそのクラスタである場合は、移行可能なターゲットそれぞれに個別にターゲット指定される別々のJMSサーバーを作成します。

SAFエージェントのターゲット指定ルール

移行可能ターゲットを使用しない場合は、SAFエージェントをクラスタ全体にターゲット指定したり、クラスタ内のサーバー・インスタンス群のリストにターゲット指定したりできます。ただし、SAFエージェントおよびクラスタ内の各サーバー・インスタンスで、デフォルト永続ストアを使用する必要があります。一方、移行可能ターゲットにターゲット指定する場合は、JMSサーバーの場合と同様、SAFエージェントでカスタム永続ストアを使用し、そのカスタム・ストアで使用する移行可能ターゲットにSAFエージェントをターゲット指定する必要があります。SAFエージェント、JMSサーバー、およびカスタム・ストアは、1つの移行可能ターゲットを共有できます。「SAFエージェントまたはパス・サービスをターゲット指定する場合の特別な考慮事項」を参照してください

WebLogic Serverは、クラスタ内のサーバーごとに移行可能ターゲットを作成し、移行可能なターゲットそれぞれに個別にターゲット指定される別々のSAFエージェントを作成します。この処理により、スループットと高可用性が向上します。

さらに、SAFエージェントを移行可能ターゲットにターゲット指定する際には、次の点も考慮に入れてください。

SAFエージェントの移行可能ターゲットのターゲット指定の変更

SAFメッセージの一貫性を保持するために、WebLogic Serverでは既存のSAFエージェントを移行可能ターゲットに再割当てすることはできません。かわりに、既存のSAFエージェントを削除し、同じ値で構成した新しいSAFエージェントを移行可能ターゲットに割り当てる必要があります。

メッセージ・スループットを向上させるための移行可能SAFエージェントのターゲット指定方法

移行可能ターゲットを使用しない場合は、SAFエージェントをクラスタ全体またはクラスタ内の複数のサーバー・インスタンスにターゲット指定してメッセージ・スループットを向上させることができます。しかし、いったん1つの移行可能ターゲットにターゲット指定したSAFエージェントは、クラスタ内の他のサーバー・インスタンスにもクラスタ全体にもターゲット指定できなくなります。したがって、クラスタ内の別々のサーバー・インスタンス上の複数のSAFエージェントにJMS宛先をインポートしてスループットを向上させたい場合は、クラスタ内のサーバー・インスタンスごとに移行可能ターゲットを作成し、それぞれの移行可能ターゲットに個別にターゲット指定する複数のSAFエージェントを作成する必要があります。

サービス品質を安定させるためのSAFエージェントのターゲット指定方法

WebLogic Server管理者は同じクラスタ内や同じサーバー・インスタンス上に、任意の数のSAFエージェントを構成およびデプロイできます。したがって、移行可能なSAFエージェントと移行可能でないSAFエージェントが、1つのサーバー・インスタンスに混在する状況も考えられます。そのような場合、どちらのSAFエージェントがメッセージを処理するかによって、JMSクライアント・アプリケーションの動作が異なる可能性があります。

たとえば、インポートした宛先を複数のSAFエージェントにデプロイできる場合、その宛先に送信されたメッセージはすべてのSAFエージェントの間でロード・バランシングされます。SAFエージェントのリストに移行可能でないエージェントが含まれていると、そのJMSクライアント・アプリケーションの高可用性は限定的なものになります。したがってベスト・プラクティスとしては、インポートした宛先を、同じレベルの高可用性機能を提供する1つまたは複数のSAFエージェントにデプロイすることをお薦めします。つまり、転送の品質と動作を確実に安定させるには、インポートした宛先をターゲット指定する複数のSAFエージェントが、すべて移行可能ターゲットにターゲット指定されているか、すべて移行可能でないターゲットにターゲット指定されている必要があるということです。

パス・サービスのターゲット指定ルール

移行可能ターゲットを使用しない場合は、パス・サービスをクラスタ内の1つのメンバーにターゲット指定し、デフォルト・ファイル・ストアまたはカスタム・ストアのいずれかを使用できます。ただし、移行可能ターゲットにターゲット指定したパス・サービスではデフォルト・ストアを使用できないため、カスタム・ストアを構成し、同じ移行可能ターゲットにターゲット指定する必要があります。さらに、ベスト・プラクティスとしては、その移行可能ターゲットのユーザーを、パス・サービスとそのカスタム・ストアに限定する必要があります。一方、JMSサーバー、SAFエージェント、およびカスタム・ストアは、1つの移行可能ターゲットを共有できます。

パス・サービスをターゲット指定する場合の特別な考慮事項

クラスタのパス・サービスを移行可能ターゲットにターゲット指定する場合のベスト・プラクティスとしては、その移行可能ターゲットのユーザーをパス・サービスとそのカスタム・ストアに限定する必要があります。

パス・サービスを移行可能ターゲットにターゲット指定すると、JMS分散宛先のメッセージ順序単位(UOO)情報を格納するための拡張ストレージが提供されます。これは、そのUOO情報が、分散宛先メンバーをホストするサーバー・インスタンスのみでなく、移行可能ターゲット全体に基づく情報になるためです。

カスタム・ストアのターゲット指定ルール

すべてのJMS関連サービスには、それと同じ移行可能ターゲットにターゲット指定されているカスタム永続ストアが必要です。カスタム・ストアを移行可能ターゲットにターゲット指定する場合は、移行可能ターゲットのすべての候補サーバー・メンバーからストア・ディレクトリにアクセスできるように、ストアの<directory>パラメータを構成する必要があります。

WebLogic Serverは、クラスタ内のサーバー・インスタンスごとに移行可能ターゲットを作成し、JMSシステム・リソース・ターゲットがそのクラスタである場合は、移行可能なターゲットそれぞれに個別にターゲット指定される別々のJMSサーバーおよびファイル・ストアを作成します。

「JMSサービスで使用できるカスタム・ストア」を参照してください

JTAトランザクション・リカバリ・サービス用の移行可能ターゲット

JTAの場合は、JTA用の移行可能ターゲットがサーバー・レベルで自動的に定義されるため、移行可能ターゲットを構成する必要はありません。JTA自動移行を有効にするには、管理コンソールで「JTA移行ポリシー」を選択します。JTAのデフォルト移行ポリシーは「手動」です。自動サービス移行の場合、「障害リカバリ」または「停止リカバリ」のいずれかの移行ポリシーを選択します。これは、トランザクション・リカバリ・サービスが、ユーザー優先サーバー(UPS)の起動時にのみ開始されることを意味します。管理者がUPSを正常停止または強制停止した場合、このサービスは移行されません。

一方、UPSが内部エラーによって停止した場合、このサービスは別の候補サーバー・インスタンスに移行されます。手動停止または内部エラーにより候補サーバー・インスタンスが使用できない場合、移行フレームワークはまず、UPSサーバー・インスタンス上でサービスを再アクティブ化しようとします。UPSサーバーがその時点で使用できない場合、サービスは別の候補サーバー・インスタンスに移行されます。

移行処理ツール

WebLogic Serverの移行フレームワークでは、JMS関連サービスやJTAトランザクション・リカバリ・サービスの手動移行または自動移行を実行するためのインフラストラクチャと機能を提供しています。デフォルトでは、あるサーバー・インスタンスから別のサーバー・インスタンスにサービスを正常に移行するために、管理者はこのプロセスを手動で実行する必要があります。ただし、サーバーに障害が発生した場合に自動的に移行されるように、これらのサービスを簡単に構成することもできます。

管理コンソール

管理者はWebLogic Server管理コンソールを使用して、移行プロセスを構成し実行できます。

詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプにある次のトピックを参照してください。

- 「JMS関連サービス移行の構成」

- 「移行のためのJTAトランザクション・リカバリ・サービスの構成」

WebLogic Scripting Tool

管理者はWebLogic Scripting Tool (WLST)コマンド行インタフェース・ユーティリティを使用して、移行プロセスの構成や実行を含め、サーバー・インスタンスのライフ・サイクルを管理できます。

詳細は、『WebLogic Server WLSTコマンド・リファレンス』のライフ・サイクル・コマンドに関する項を参照してください。

サービス自動移行インフラストラクチャ

サービス移行フレームワークは、次のコンポーネントを使用してサーバーのヘルス状態の問題をモニターし、固定サービスを正常なサーバー・インスタンスに自動的に移行します。

移行可能サービスのリース

リースは、クラスタの複数のメンバーで同時に実行することができないサービスを管理するために使用するプロセスです。リースによって、クラスタ全体エンティティの排他的な所有権を確保できます。リースのオーナーは、クラスタ内に1つしか存在しません。また、サーバーやクラスタの障害時には、リースをフェイルオーバーさせることができます。これにより、シングル・ポイント障害を回避できます。「リース」を参照してください。

自動移行オプションを使用する場合は、クラスタの「移行基盤」ポリシーを、次のように「データベース」または「コンセンサス」リースに設定する必要があります。

データベース・リース

Oracle RACなどの高可用性データベースを使用してリース情報を管理する場合は、「高可用性データベース・リース」の手順に従って、サーバーの移行に使用するデータベースを構成します

「移行基盤」を「データベース」リースに設定するには、有効なJDBCシステム・リソースに「自動移行に使用するデータ・ソース」オプションが設定されている必要があります。この設定は、管理対象サーバーでリースに使用する表が、そのリソース上に作成されていることを示します。JDBCデータ・ソースの作成の詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のJDBCデータ・ソースの構成に関する項を参照してください。

コンセンサス・リース

「移行基盤」を「コンセンサス」リースに設定すると、メンバー・サーバーはリース情報をメモリー内に保持します。これにより、リースを使用するために高可用性データベースを用意する必要がなくなります。このバージョンのリースでは、ノード・マネージャを使用してクラスタ内のサーバー・インスタンスを管理する必要があります。また、移行可能な(または移行可能ターゲットをホストできる)すべてのサーバー・インスタンスにノード・マネージャを関連付ける必要もあります。ノード・マネージャは、関係するメンバー・サーバー・インスタンスに関するヘルス・モニター情報の取得の際に必要です。「コンセンサス(非データベース)リース」を参照してください

ノード・マネージャ

サービスの自動移行を使用する場合、次のように、メンバー・サーバーのヘルス・モニタリング情報を取得するため、ノード・マネージャが必要です。

- コンセンサス・リース - クラスタ内の管理対象サーバーをホストするすべてのマシンでノード・マネージャを実行する必要があります。

- データベース・リース - 移行前/移行後スクリプトが定義されている場合のみ、クラスタ内の管理対象サーバーをホストするすべてのマシンでノード・マネージャを実行する必要があります。移行前スクリプトおよび移行後スクリプトが定義されていない場合、ノード・マネージャは必要ありません。

ノード・マネージャの構成の詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャを使用したサーバーの制御に関する項を参照してください。

サービスの移行時に管理サーバーは不要

移行中のシングル・ポイント障害を排除するため、移行可能サービスの自動移行は、移行中に管理サーバーが使用可能かどうかには依存しません。

サービスのヘルス・モニタリング

サービス移行リクエストに対応するため、移行可能ターゲットでは、デプロイされているヘルス・モニタリング・インタフェースを実装する移行可能サービスの基本的なヘルス・モニタリングを実行します。移行可能ターゲットにこのジョブを実行させることの利点は、その実行がローカルに限定される点です。また、移行可能ターゲットはリース・システムと直接通信するためのチャネルを備えており、ヘルス状態の悪化が検出された場合、リースを解放する(つまり移行をトリガーする)ことをリクエストできます。

JTAトランザクション・リカバリ・サービスのヘルス・モニタリングが自動移行をトリガーする仕組み

JTAにおいて自動移行が有効になっている場合は、JTAサブシステムのヘルス状態が悪い(FAILED)ことが報告されると、デフォルトではサーバーが停止します。たとえばトランザクション・ログへのアクセス時にI/Oエラーが発生した場合、JTAのヘルス状態がFAILEDに変わります。

プライマリ・サーバーで障害が発生すると、移行可能サービス・フレームワークがトランザクション・リカバリ・サービスを自動的にバックアップ・サーバーに移行します。サービス自動移行フレームワークでは、構成されている候補サーバーの中からバックアップ・サーバーが選択されます。トランザクション・リカバリ・アクションを完了する前にバックアップ・サーバーで障害が発生し、その後再起動された場合、トランザクション・リカバリ・サービスはクラスタ内の別のサーバー・インスタンスに移行されることになります(プライマリ・サーバーがその返還を要求するか、移行フレームワークがバックアップ・サーバー・インスタンスのリースの期限切れを通知します)。

移行が成功した後、バックアップ・サーバーが正常に停止して再起動されると、そのバックアップ・サーバー上でトランザクション・リカバリ・サービスが再度アクティブ化になります。この動作は、サービスの手動移行とまったく同じです。サービスの手動移行では、実行中のプライマリ・サーバーからトランザクション・リカバリ・サービスを移行することはできません。

JMS関連サービスのヘルス・モニタリングが自動移行をトリガーする仕組み

JMS関連サービスの自動移行が有効になっている場合:

- JMSサーバー - 実行時の自身のヘルス状態を保持して、ヘルス・モニタリング・サブシステムに登録および更新します。JMSサーバーのターゲット指定された永続ストアなど、JMSサーバーが依存しているサービスがFAILEDヘルス状態を報告した場合、それは移行フレームワークによって検出されます。移行プロセスは、移行可能ターゲットの構成済自動移行ポリシーに基づいて実行されます。通常、移行フレームワークは現在のユーザー優先サーバー上でJMSサーバーと移行可能ターゲットのその他のユーザーを非アクティブ化し、控えの候補サーバー・リストにある正常で使用可能なサーバー・インスタンス上に移行します。

- SAFサービス - 構成済のSAFエージェントからSAFサービスのヘルス状態が取得されます。SAFサービスが異常なヘルス状態を検出すると、SAFエージェント・インスタンス全体が異常であると報告されます。SAFエージェントにはJMSサーバーと同じヘルス・モニタリング機能があります。通常、移行フレームワークは現在のユーザー優先サーバー上でSAFエージェントを非アクティブ化し、控えの候補サーバー・リストにある正常で使用可能なサーバー・インスタンス上に移行します。

- パス・サービス - パス・サービス自体は自身のヘルス状態を変更しませんが、そのかわりに、サーバー・インスタンスとそのカスタム・ストアに依存して移行をトリガーします。

- 永続ストア - 自身のヘルス状態をヘルス・モニタリング・サブシステムに登録します。永続ストアが読み書きを続行できず、再起動しないとデータの一貫性が保証されないような場合に、I/Oレイヤーによってエラーが報告されると、ストアのヘルス状態はFAILEDとしてマークされ、ヘルス・モニタリング・サブシステムにFAILEDと報告されます。この状態が自動移行フレームワークによって検出され、ストアとそのストアに依存しているサブシステム・サービスの自動移行がトリガーされ、現在のユーザー優先サーバー・インスタンスから控えの候補サーバー・リストにある正常で使用可能なサーバー・インスタンスに移行されます。

障害が発生した移行可能サービスのインプレースでの再起動

JMSのような一部の移行可能サービスは、場合によってはサービスを移行するよりもその場所(インプレース)で再起動する方が利点があるという独自の要件を備えています。そのため、移行可能ターゲットでは、サービスを移行する代わりに、障害が発生したサービスの非アクティブ化と再アクティブ化を試行するためのrestart-in-placeオプションが提供されています。動的クラスタにターゲット指定されたカスタム・ストアでは、クラスタのターゲット指定JMSサービスに対してrestart-in-place構成オプションも提供されます。

移行フレームワークは、サーバー・インスタンスのヘルス状態が正常(RUNNINGなど)である場合にのみ、サービスの再起動を試行します。サーバー・インスタンスがなんらかの理由で正常でない場合、フレームワークはすべてのインプレース再起動をスキップして、ただちに移行段階に進みます。

クラスタのシングルトン・モニターはサービスのMigratableTargetMBeanのRestartOnFailure値を確認します。値がfalseの場合、サービスは移行されます。値がtrueの場合、移行フレームワークはインプレースで非アクティブ化とアクティブ化を試行します。再アクティブ化が失敗すると、移行フレームワークはユーザーが指定したSecondsBetweenRestartsの秒数休止します。指定されたNumberOfRestartAttemptsの回数、この試行が繰り返されます。すべての再起動の試行が失敗すると、サービスは正常なサーバー・メンバーに移行されます。

使用不能サーバーからのサービスの移行

クラッシュした、または管理サーバーからアクセスできないサーバー・インスタンスからサービスを移行する場合は、特別な考慮事項があります。移行を行う時点で以前にアクティブだったサービスのホストに管理サーバーからアクセスできない場合、その管理対象サーバーのローカル構成情報(たとえば移行可能ターゲット)は、それがサービスのアクティブなホストでなくなっていることを反映して更新されることはありません。この場合は、アクセス不能な管理対象サーバーのローカル構成キャッシュを再起動前にパージする必要があります。そうすれば、以前にアクティブだったホストが、別の管理対象サーバーに移行しているサービスをホストするのを防ぐことができます。

JMSとJTAのサービスの自動移行の相互作用

サービスの自動移行では場合によって、コミットされていないトランザクションの進行中に、JMSサービスとJTAトランザクション・リカバリ・サービスの移行可能ターゲットが別々の候補サーバーに移行される可能性があります。しかし、JMSおよびJTAサービスの状態は時間や場所に依存していないため、JMSサービスが使用できるかどうかは、JTAトランザクションのリカバリが完了しているかどうかに依存しません。

ただし、両方のサービスが実行され、通信を再確立できるようになるまで、不明なトランザクションは解決されません。不明なトランザクションとは、複数の参加リソース(JMSサーバーやデータベースなど)が関与する不完全なトランザクションのことで、1つまたは複数のリソースが、トランザクション・マネージャからロールバック、コミット、あるいはトランザクションの一部であることを無視するように指示されるのを待機しています。トランザクション・マネージャまたは参加リソースがクラッシュしたときにトランザクションが進行中である場合、そのトランザクションは「不明」になる可能性があります。

リソースが使用可能でない場合、JTAはリカバリ中止期限(デフォルトは24時間)が切れるまで、トランザクションのリカバリを試行し続けます。

移行前の要件

WebLogic Serverでは、サービスの移行をサポートするために、サービスの構成に一定の制約と前提条件が課されます。これらはサービス固有の制約で、採用しているエンタープライズ・アプリケーション・アーキテクチャによって異なります。

JMSサービスで使用できるカスタム・ストア

移行可能なJMS関連サービスでは、デフォルト永続ストアを使用することはできないため、カスタム・ストアを構成し、JMSサービスまたはSAFエージェントと同じ移行可能ターゲットにそれをターゲット指定する必要があります。パス・サービスの場合は、専用のカスタム・ストアと移行可能ターゲットを使用するのがベスト・プラクティスです。

カスタム・ファイル・ストアまたはJDBCストアは次のいずれかである必要があります。

- 移行可能ターゲットのすべての候補サーバー・メンバーからアクセス可能です。

- アプリケーションでファイル・ベースの永続性(ファイル・ストア)を使用する場合は、移行可能ターゲットのすべての候補サーバー・メンバーからストア・ディレクトリにアクセスできるように、ストアの<directory>パラメータを構成する必要があります。高い信頼性を実現したい場合は、ストレージ・エリア・ネットワーク(SAN)やデュアル・ポートSCSIディスクなど、高可用性の備わっている共有ストレージ・ソリューションを使用してください。

- アプリケーションでJDBCベースの永続性(JDBCストア)を使用する場合は、すべての候補サーバー・メンバーからそのデータベース・インスタンスのJDBC接続情報(データ・ソース、接続プールなど)を使用できるようにする必要があります。

- ORACLE_HOME/user_projects/domains/mydomain/bin/service_migrationディレクトリ(mydomainはドメイン固有のディレクトリでドメインと同じ名前)に格納されている移行前および移行後スクリプトを使用して、バックアップ・サーバー・ターゲットに移行されています。

注意:

移行前スクリプトおよび移行後スクリプトを作成する基本的な手順は、このディレクトリ内のreadme.txtを参照してください。

状況によっては、スクリプトで移行元のサーバーからディスクをアンマウントし、バックアップ・サーバーにマウントする必要があります。これらのスクリプトは、Oracle WebLogic Server MBeanリファレンスに記載されたMigratableTargetMBeanのPreScript()メソッドおよびPostScript()メソッド、またはWebLogic Server管理コンソールを使用して、ノード・マネージャ上で構成されます。別のケースでは、カスタム・ファイル・ストアのディレクトリをバックアップ・サーバー・インスタンスに移動(コピーではなく)するためにスクリプトが必要となる場合があります。古いサーバー・インスタンスが次にその移行可能ターゲットをホストするときまで、古い構成済ファイル・ストア・ディレクトリを残さないでください。そのため、WebLogic Server管理者はこのファイルを削除するか、別のディレクトリに移動する必要があります。

JTAで使用できるデフォルト・ファイル・ストア

クラスタ内の障害が発生したサーバー・インスタンスから同じクラスタ内の別のサーバー・インスタンス(バックアップ・サーバー・インスタンス)にJTAトランザクション・リカバリ・サービスを移行するには、障害が発生したサーバーのトランザクション・ログ(TLOG)レコードにバックアップ・サーバーからアクセスできる必要があります。トランザクション・ログ・レコードは、サーバーのデフォルト永続ストアに格納されています。

障害が発生した場合にサービスを移行する予定がある場合は、障害が発生した移行可能サーバーからの移行先となり得るすべてのマシンからアクセスできる共有ストレージ・システムにレコードが格納されるよう、デフォルト永続ストアを構成する必要があります。高い信頼性を実現したい場合は、ストレージ・エリア・ネットワーク(SAN)やデュアル・ポート・ディスクなど、高可用性の備わっている共有ストレージ・ソリューションを使用してください。なお、同じデフォルト・ストアを共有できるのは、JTAを始めとする移行可能でないサービスのみです。

必要に応じて、移行前スクリプトおよび移行後スクリプトを使用して、共有ストレージのアンマウントとマウントを実行できます。移行前スクリプトおよび移行後スクリプトを作成する基本的な手順は、ORACLE_HOME/user_projects/domains/mydomain/bin/service_migrationディレクトリ内のreadme.txtファイルを参照してください。mydomainはドメインに固有のディレクトリで、ドメインと同じ名前です。

サーバーの状態とサービスの手動移行

自動移行の場合は、現在の(移行元の)サーバーで障害が発生すると、移行フレームワークがトランザクション・リカバリ・サービスをターゲット・バックアップ・サーバーに自動的に移行します。

手動の移行の場合、トランザクション・リカバリ・サービスを、実行中のサーバー・インスタンスからバックアップ・サーバー・インスタンスに移行できません。トランザクション・リカバリ・サービスを移行する前に、サーバー・インスタンスを停止する必要があります。

表8-1に、実行状態に基づく移行のサポートを示します。

表8-1 サーバーの実行状態と手動移行のサポート

現在のサーバーのサーバー状態情報

バックアップ・サーバーのサーバー状態情報

メッセージング移行の許可

JTA移行の許可

実行中

実行中

はい

いいえ

実行中

スタンバイ

はい

いいえ

実行中

実行されていない

はい

いいえ

スタンバイ

実行中

はい

いいえ

スタンバイ

スタンバイ

はい

いいえ

スタンバイ

実行されていない

はい

いいえ

実行されていない

実行中

はい

はい

実行されていない

スタンバイ

はい

いいえ

実行されていない

実行されていない

はい

はい

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

動的または混在クラスタでは、JMS関連サービスの自動移行の簡単な構成も可能です。詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSリソースの管理』のJMSクラスタと高可用性の簡略化された構成に関する項を参照してください。

自動移行の場合、WebLogic管理者は、JMSサーバーやSAFエージェントなどのJMS関連サービスに移行可能ターゲットを指定することもできます。管理者は、WebLogic Serverのヘルス・モニタリング機能に基づいて、障害が発生したサーバーから自動的に移行されるように移行可能サービスを構成することもできます。

注意:

JMSサービスはJTAトランザクション・リカバリ・サービスとは関係なく移行できます。ただし、JTAトランザクション・リカバリ・サービスは他のサブシステム・サービスのトランザクション制御を提供するため、通常は他のサブシステム・サービスと共に移行されます。これによって、サブシステム・サービスの移行前後でトランザクションの整合性が維持されます。

クラスタ内の移行可能ターゲットでJMSサービスの自動移行を構成するには、次のタスクを実行します。

- ステップ1: 管理対象サーバーとノード・マネージャを構成する

- ステップ2: 移行リース基盤を構成する

- ステップ3: 移行可能ターゲットを構成する

- ステップ4: カスタム・ストアを構成およびターゲット指定する

- ステップ5: JMSサービスをターゲット指定する

- ステップ6: 変更した移行ポリシーで管理サーバーと管理対象サーバーを再起動する

- ステップ7: JMSサービスを元のサーバーに手動で戻す

ステップ1: 管理対象サーバーとノード・マネージャを構成する

管理対象サーバーをマシンに割り当てるなど、クラスタ内の管理対象サーバーを移行用に構成します。特定の状況では、ノード・マネージャも実行中でなければなりません。また、サーバーの自動移行を許可するように構成されている必要があります。

これらのタスクをWebLogic Server管理コンソールで実行する手順は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプにある次のトピックを参照してください。

- 「管理対象サーバーの作成」

注意:

移行するJMSサーバーをホストすることになる管理対象サーバーのインスタンスには、一意のリスニング・アドレス値を設定する必要があります。そうしないと、移行は失敗します。

- 「マシンの作成と構成」

- 「ノード・マネージャの構成」

注意:

サービスの自動移行でコンセンサス・リースを使用する場合は、ノード・マネージャを使用してクラスタ内のサーバー・インスタンスを制御し、すべての移行可能サーバーにノード・マネージャのインスタンスを関連付ける必要があります。データベース・リースを使用する場合は、移行前スクリプトおよび移行後スクリプトを定義する場合にのみノード・マネージャが必要です。移行前スクリプトおよび移行後スクリプトが定義されていない場合、ノード・マネージャは必要ありません。

ノード・マネージャの構成の詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャを使用したサーバーの制御に関する項を参照してください。

ステップ2: 移行リース基盤を構成する

WebLogic Server管理コンソールの「クラスタ」→「構成」→「移行」ページで、データ永続性環境の構成方法に応じて、データベース・リーシングまたはコンセンサス・リーシングのいずれかを選択して、クラスタの「移行基盤」を構成します。「移行可能サービスのリース」を参照してください

ステップ3: 移行可能ターゲットを構成する

この手順は、JMS関連サービスをターゲット指定したり、JTAトランザクション・リカバリ・サービスの移行を有効にしたりする前に実行する必要があります。

移行可能サーバーを自動的な移行可能ターゲットとして構成する

WebLogic Server管理コンソールの移行可能ターゲットのサマリー表には、サーバー名を持つ、システム生成による移行可能ターゲットが表示されます(移行可能)。これらの移行可能ターゲットは、クラスタ内の実行中のサーバー・インスタンスごとに自動的に生成されるものです。ただし、汎用的なテンプレートしか含まれていないため、自動移行用にターゲット指定および構成する必要があります。

新しい移行可能ターゲットを作成する

新しい移行可能ターゲットを作成する際は、WebLogic Server管理コンソールを使用して移行ポリシーを作成、ターゲット指定および選択します。

ユーザー優先サーバーを選択する

WebLogic Server管理コンソールを使用して新しい移行可能ターゲットを作成する場合は、最初にクラスタ内の優先サーバー・インスタンスを選択してターゲットを関連付けることができます。ユーザー優先サーバーとは、移行可能ターゲットのホストに最適なサーバー・インスタンスです。

注意:

自動的に移行されたサービスは指定されたユーザー優先サーバーにホストされない可能性もあります。移行されたサービスをホストしているサーバーを確認するには、WebLogic Server管理コンソールを使用して、「移行可能なターゲット」→「制御」ページの「現在のホスト・サーバー」情報を参照してください。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「移行可能ターゲット: 制御」を参照してください。

サービス移行ポリシーを選択する

移行可能ターゲットのデフォルトの移行ポリシーは「サービスの手動での移行のみ」であるため、次のいずれかの自動移行ポリシーを選択する必要があります。

- 必ず1回のサービスを自動移行 - 候補リスト内の1つ以上の管理対象サーバーが実行中である場合、サーバー・インスタンスで障害が発生するかサーバー・インスタンスが停止(正常停止または強制停止)しても、サービスはクラスタ内のどこかでアクティブになります。

注意:

この値を使用するとターゲットのグループ化が生じる可能性があります。たとえば、exactly-onceの移行可能ターゲットが5つあるときに、クラスタ内の1つの管理対象サーバーのみを起動すると、5つのターゲットすべてがそのサーバー・インスタンス上でアクティブ化されます。

- 障害リカバリ・サービスの自動移行 - このポリシーでは、ユーザー優先サーバー(UPS)が起動されている場合にのみサービスが開始されます。管理者がUPSを正常停止または強制停止した場合、このサービスは移行されません。ただしUPSで内部エラーによる障害が発生した場合、サービスは別の候補サーバー・インスタンスに移行されます。手動停止または内部エラーにより候補サーバー・インスタンスが使用できない場合、移行フレームワークはまず、UPSサーバー上でサービスを再アクティブ化しようとします。UPSサーバーがその時点で使用できない場合、サービスは別の候補サーバー・インスタンスに移行されます。

「手動および自動のサービス移行ポリシー」を参照してください

制約付き候補サーバーを選択する(オプション)

exactly-onceサービス移行ポリシーを使用する移行可能ターゲットを作成する場合は、JMSサーバーの移行先になる可能性のあるメンバー・サーバーを制限することもできます。推奨されるベスト・プラクティスは、各移行可能ターゲットの候補サーバー・セットを1番目、2番目または3番目のサーバー・インスタンスに制限することです。各サーバーが起動しているとき、移行可能ターゲットでは最初にオンラインになったサーバー・インスタンスが割り当てられるのではなく、その候補のサーバー・インスタンスに制限されます。管理者はサービスを手動でアイドル状態のサーバー・インスタンスに移行できます。

一方、クラスタのパス・サービスの場合は、移行可能ターゲットの候補サーバー・インスタンスをクラスタ全体にする必要があり、これがデフォルトの設定です。

WebLogic Server管理コンソールの移行可能ターゲットの「構成」→「移行」ページで、控えの候補サーバーの「使用可能」ボックスには、移行可能ターゲットをサポートできるすべての管理対象サーバーの一覧が表示されます。管理対象サーバーは、「選択済み」ボックスに移動すると有効な候補サーバーになります。

移行前/移行後スクリプトを指定する(オプション)

移行可能ターゲットを作成したら、必要に応じて共有カスタム・ファイル・ストアのアンマウントやマウントを実行する移行前/移行後スクリプトを指定することもできます。

- 移行前スクリプトのパス - 移行可能ターゲットを実際にアクティブ化する前に実行する移行前スクリプトへのパスを指定します。

- 移行後スクリプトのパス - 移行可能ターゲットを完全に非アクティブ化にした後に実行する移行後スクリプトへのパスを指定します。

- 移行後スクリプトが失敗した場合に自動移行を取り消す - 移行後スクリプトの実行中に発生したエラーを、移行に対して致命的と判断するかどうかを指定します。

- 移行後スクリプトを別のマシンで実行できるようにする - 移行後スクリプトの実行を、別のマシンでも許可するかどうかを指定します。

移行前スクリプトおよび移行後スクリプトは、ORACLE_HOME/user_projects/domains/mydomain/bin/service_migrationディレクトリに配置する必要があります。mydomainはドメインに固有のディレクトリで、ドメインと同じ名前です。便宜を図るため、移行前スクリプトと移行後スクリプトのサンプルは、このディレクトリ内に置かれています。

インプレースでの再起動オプションを指定する(オプション)

移行可能ターゲットでは、サービスを移行せずに、障害が発生したサービスの非アクティブ化と再アクティブ化を試行するrestart-in-placeオプションが提供されています。「障害が発生した移行可能サービスのインプレースでの再起動」を参照してください

ステップ4: カスタム・ストアを構成およびターゲット指定する

「JMSサービスで使用できるカスタム・ストア」で説明したように、JMS関連サービスの場合、動的クラスタ、またはJMSサービスと同じ移行可能ターゲットにターゲット指定されたカスタム永続ストアを構成する必要があります。ストアが次のいずれかであることを確認します。

- 移行可能ターゲット内のすべての候補サーバー・インスタンスからアクセスできるように構成されていること。

- 移行前スクリプトおよび移行後スクリプトで移行されていること。「移行前/移行後スクリプトを指定する(オプション)」を参照してください

ステップ5: JMSサービスをターゲット指定する

移行可能ターゲットを使用する場合は、JMSサービスをカスタム永続ストアと同じ移行可能ターゲットにターゲット指定する必要があります。移行可能ターゲットを使用するJMSサービスのカスタム・ストアが指定されていない場合は、JMSサーバーのデプロイメントとWebLogic Serverの起動に失敗した後に検証メッセージが生成されます。たとえば、デフォルト・ファイル・ストアを使用するJMSサーバーを移行可能ターゲットにターゲット指定しようとすると、次のようなメッセージが生成されます。

Since the JMS server is targeted to a migratable target, it cannot use the default store.

移行可能ターゲットにターゲット指定されているSAFエージェントまたはパス・サービスでデフォルト・ストアを使用しようとした場合も、同様のメッセージが生成されます。また、カスタム・ストアが移行可能サービスと同じ移行可能ターゲットにターゲット指定されていない場合は、JMSサーバーのデプロイメントとWebLogic Serverの起動に失敗した後に、次のような検証ログ・メッセージが生成されます。

The JMS server is not targeted to the same target as its persistent store.

SAFエージェントまたはパス・サービスをターゲット指定する場合の特別な考慮事項

SAFエージェントまたはパス・サービスを移行可能ターゲットにターゲット指定する場合には、いくつか特別に考慮すべき事項があります。詳細は、「SAFエージェントのターゲット指定ルール」および「パス・サービスのターゲット指定ルール」を参照してください

ステップ6: 変更した移行ポリシーで管理サーバーと管理対象サーバーを再起動する

JMSサービスを自動移行用に構成したら、管理サーバーを再起動する必要があります。また、移行ポリシーを変更した管理対象サーバーも再起動する必要があります。

ステップ7: JMSサービスを元のサーバーに手動で戻す

移行元のプライマリ・サーバー・インスタンスが復旧したら、JMSサービスをもう一度移行して元のサーバー・インスタンスに戻す場合もあります。自動的にプライマリ・サーバー・インスタンスに移行されるJTAトランザクション・リカバリ・サービスとは異なり、JMSサービスは自動的には戻されないため手動で移行する必要があります。

WebLogic Server管理コンソールを使用してJMS関連サービスを手動で移行する手順は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMS関連サービスの手動移行に関する項を参照してください。

WLSTを使用してJMS関連サービスを手動で移行する手順は、『WebLogic Server WLSTコマンド・リファレンス』のWLSTコマンドおよび変数リファレンスに関する項を参照してください。

サービスの自動移行の構成でJMSをターゲット指定する際のベスト・プラクティス

- サーバー・インスタンスのデフォルトの移行可能ターゲットを使用すればほぼ問題ありません。サーバー・インスタンスごとに1つのデフォルトの移行可能ターゲットが存在します。または、サーバー・インスタンスごとに1つの移行可能ターゲットを構成することもできます。「ステップ3: 移行可能ターゲットを構成する」を参照してください

- 移行可能ターゲットごとに1つのカスタム・ストアを構成し、そのカスタム・ストアを移行可能ターゲットにターゲット指定します。「ステップ4: カスタム・ストアを構成およびターゲット指定する」を参照してください

- 各移行可能ターゲットにJMSサービス(JMSサーバーとSAFエージェント)を構成する際は、そのサービスが対応するカスタム・ストアを参照していることを確認します。その後、それらのサービスを各移行可能ターゲットにターゲット指定します。「ステップ5: JMSサービスをターゲット指定する」を参照してください

- デプロイメント・モジュールではなく、JMSシステム・モジュールを使用します。WebLogic Server管理コンソールでは、システム・モジュールのみ構成できます。『Oracle WebLogic Server JMSリソースの管理』のJMSシステム・モジュール構成に関する項を参照してください。

- 予想されるターゲット・セットごとにシステム・モジュールを1つ作成し、そのモジュールを1つのクラスタにターゲット指定します。たとえば、1つの宛先が1つのJMSサーバーにまたがり、別の宛先が6つのJMSサーバーにまたがるようにするには、2つのモジュールを作成し、それらを同じクラスタにターゲット指定します。

- モジュールごとにサブデプロイメントを1つ構成し、そのサブデプロイメントに同種のJMSサーバーまたはJMS SAFエージェントのターゲット・セットを設定します。サブデプロイメントにはWebLogic Serverやクラスタの名前を含めないでください。

- 接続ファクトリを同じクラスタ上で動作しているアプリケーションのクラスタにターゲット指定します。デフォルトのターゲット指定を使用して、モジュールのターゲットを継承させることができます。クラスタから離れた場所で実行しているアプリケーションを使用するには、WebLogic Server管理コンソール上で「高度なターゲット指定」を選択して接続ファクトリをサブデプロイメントにターゲット指定します。

- 宛先など、他のJMSモジュール・リソースについては、サブデプロイメントを使用してターゲット指定します。デフォルトのターゲット指定は利用しないでください。サブデプロイメントのターゲット指定は、WebLogic Server管理コンソールの「高度なターゲット指定」を選択すると実行できます。

- JMSサーバーやSAFエージェントを追加または削除したら、モジュールのサブデプロイメントでも必ず追加または削除してください。

- ロード・バランシングなど、クライアントの動作を制御する際にカスタム接続ファクトリを使用します。カスタム接続ファクトリは、他のリソースと同様にターゲット指定できますが、接続ファクトリのターゲット・セットは特別な意味を持ちます。接続ファクトリは、クラスタ、WebLogic Server、またはJMSサーバーやSAFエージェントに(サブデプロイメントを使用して)ターゲット指定できます。クライアントが使用するJMSサーバーやSAFエージェントに接続ファクトリをターゲット指定すると、パフォーマンス上のメリットがあります。これは、接続ファクトリのターゲット・セットにより、クライアント接続の候補ホスト・サーバー・インスタンスが決まるためです。JMSサーバーやSAFエージェントにターゲット指定すると、どのクラスタ・サーバー・インスタンス上にもSAFエージェントが存在しない場合に、JMSサーバーやSAFエージェントを持たないサーバー・インスタンスにクライアント接続が接続される可能性が低くなります。JMSサーバーやSAFエージェントが接続ホスト上に存在しない場合、クライアントからのリクエストは、最終的にJMSサーバーやSAFエージェントに届くまで、クライアントから接続ホスト・サーバーへのルートを常にダブル・ホップすることになります。

『Oracle WebLogic Server JMSリソースの管理』のJMSの初級ユーザーおよび上級ユーザー向けのベスト・プラクティスに関する項を参照してください。

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

WebLogic JMSでは、管理者がJMS関連サービスの移行可能ターゲットを指定できるため、移行フレームワークを有効に活用できます。正しく構成されているJMSサービスであれば、クラスタ内の別のWebLogic Serverに手動で移行できます。移行には、予定されている移行の他に、クラスタ内のWebLogic Serverの障害に応じて行われる手動移行があります。

JMS関連サービスをクラスタ内の移行可能ターゲットに手動で移行できるように構成するには、次のタスクを実行します。

- ステップ1: 管理対象サーバーを構成する

- ステップ2: 移行可能ターゲットを構成する

- ステップ3: カスタム・ストアを構成およびターゲット指定する

- ステップ4: JMSサービスをターゲット指定する

- ステップ5: 変更した移行ポリシーで管理サーバーと管理対象サーバーを再起動する

- ステップ6: JMSサービスを手動で移行する

ステップ1: 管理対象サーバーを構成する

管理対象サーバーをマシンに割り当てるなど、クラスタ内の管理対象サーバーを移行用に構成します。

これらのタスクをWebLogic Server管理コンソールで実行する手順は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプにある次のトピックを参照してください。

- 「管理対象サーバーの作成」

注意:

移行するJMSサーバーをホストすることになる管理対象サーバーのインスタンスには、一意のリスニング・アドレス値を設定する必要があります。そうしないと、移行は失敗します。

- マシンの作成と構成

ステップ2: 移行可能ターゲットを構成する

この手順は、JMS関連サービスをターゲット指定したり、JTAトランザクション・リカバリ・サービスの移行を有効にしたりする前に実行する必要があります。

移行可能サーバーを移行可能ターゲットとして構成する

WebLogic Server管理コンソールの移行可能ターゲットのサマリー表には、サーバー名を持つ、システム生成による移行可能ターゲットが表示されます(移行可能)。これらの移行可能ターゲットは、クラスタ内の実行中のサーバー・インスタンスごとに自動的に生成されるものです。ただし、汎用的なテンプレートしか含まれていないため、移行用にターゲット指定および構成する必要があります。

新しい移行可能ターゲットを作成する

新しい移行可能ターゲットを作成する際は、WebLogic Server管理コンソールを使用して移行ポリシーを作成、ターゲット指定および選択します。

優先サーバーを選択する

WebLogic Server管理コンソールを使用して新しい移行可能ターゲットを作成する場合は、最初にクラスタ内の優先サーバーを選択してターゲットを関連付けることができます。優先サーバー・インスタンスは、移行可能ターゲットのホストに最適なサーバー・インスタンスです。

デフォルトのサービスの手動移行ポリシーを受け入れる

すべての移行可能ターゲットのデフォルトの移行ポリシーは「サービスの手動での移行のみ」であるため、変更する必要はありません。

制約付き候補サーバーを選択する(オプション)

移行可能ターゲットを作成する際には、JMS関連サービスの移行先となり得るサーバー・インスタンスを、そのJMS関連サービスと同じ移行可能ターゲットにターゲット指定されたカスタム永続ストアにアクセスできるサーバーに限定することもできます。

一方、クラスタのパス・サービスの場合は、移行可能ターゲットの候補サーバー・インスタンスをクラスタ全体にする必要があり、これがデフォルトの設定です。

WebLogic Server管理コンソールの移行可能ターゲットの「構成」→「移行」ページで、控えの候補サーバーの「使用可能」ボックスには、移行可能ターゲットをサポートできるすべての管理対象サーバーの一覧が表示されます。管理対象サーバーは、「選択済み」ボックスに移動すると有効な候補サーバーになります。

移行前/移行後スクリプトを指定する(オプション)

移行可能ターゲットを作成したら、必要に応じて共有カスタム・ストアのアンマウントやマウントを実行する移行前/移行後スクリプトを指定することもできます。

- 移行前スクリプトのパス - 移行可能ターゲットを実際にアクティブ化する前に実行する移行前スクリプトへのパスを指定します。

- 移行後スクリプトのパス - 移行可能ターゲットを完全に非アクティブ化にした後に実行する移行後スクリプトへのパスを指定します。

- 移行後スクリプトが失敗した場合に自動移行を取り消す - 移行後スクリプトの実行中に発生したエラーを、移行に対して致命的と判断するかどうかを指定します。

- 移行後スクリプトを別のマシンで実行できるようにする - 移行後スクリプトの実行を、別のマシンでも許可するかどうかを指定します。

移行前スクリプトおよび移行後スクリプトは、ORACLE_HOME/user_projects/domains/mydomain/bin/service_migrationディレクトリに配置する必要があります。mydomainはドメインに固有のディレクトリで、ドメインと同じ名前です。移行前スクリプトおよび移行後スクリプトを作成する基本的な手順は、このディレクトリ内のreadme.txtを参照してください。

インプレースでの再起動オプションを指定する(オプション)

移行可能ターゲットでは、サービスを移行せずに、障害が発生したサービスの非アクティブ化と再アクティブ化を試行するrestart-in-placeオプションが提供されています。「障害が発生した移行可能サービスのインプレースでの再起動」を参照してください

ステップ3: カスタム・ストアを構成およびターゲット指定する

「JMSサービスで使用できるカスタム・ストア」で説明したように、JMS関連サービスの場合、JMSサービスと同じ移行可能ターゲットにターゲット指定されたカスタム永続ストアを構成する必要があります。ストアが次のいずれかであることを確認します。

- 移行可能ターゲット内のすべての候補サーバー・インスタンスからアクセスできるように構成されていること。

- 移行前スクリプトおよび移行後スクリプトで移行されていること。「移行前/移行後スクリプトを指定する(オプション)」を参照してください

ステップ4: JMSサービスをターゲット指定する

使用されるカスタム・ストアも同じ動的クラスタにターゲット指定される場合、JMSサービスを動的クラスタにターゲット指定できます。

移行可能ターゲットを使用する場合は、JMSサービスをカスタム永続ストアと同じ移行可能ターゲットにターゲット指定する必要があります。移行可能ターゲットを使用するJMSサービスのカスタム・ストアが指定されていない場合は、JMSサーバーのデプロイメントとWebLogic Serverの起動に失敗した後に検証メッセージが生成されます。たとえば、デフォルト・ファイル・ストアを使用するJMSサーバーを移行可能ターゲットにターゲット指定しようとすると、次のようなメッセージが生成されます。

Since the JMS server is targeted to a migratable target, it cannot use the default store.

移行可能ターゲットにターゲット指定されているSAFエージェントまたはパス・サービスでデフォルト・ストアを使用しようとした場合も、同様のメッセージが生成されます。

また、カスタム・ストアが移行可能サービスと同じ移行可能ターゲットにターゲット指定されていない場合は、JMSサーバーのデプロイメントとWebLogic Serverの起動に失敗した後に、次のような検証ログ・メッセージが生成されます。

The JMS server is not targeted to the same target as its persistent store.

SAFエージェントまたはパス・サービスをターゲット指定する場合の特別な考慮事項

SAFエージェントまたはパス・サービスを移行可能ターゲットにターゲット指定する場合には、いくつか特別に考慮すべき事項があります。詳細は、「SAFエージェントのターゲット指定ルール」および「パス・サービスのターゲット指定ルール」を参照してください

ステップ5: 変更した移行ポリシーで管理サーバーと管理対象サーバーを再起動する

JMSサービスを手動移行用に構成したら、管理サーバーを再起動する必要があります。

また、移行ポリシーを変更した管理対象サーバーも再起動する必要があります。

ステップ6: JMSサービスを手動で移行する

WebLogic Server管理コンソールを使用してJMS関連サービスを手動で移行する手順は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMS関連サービスの手動移行に関する項を参照してください。

WLSTを使用してJMS関連サービスを手動移行する手順については、『WebLogic Server WLSTコマンド・リファレンス』を参照してください。

注意:

移行元のプライマリ・サーバー・インスタンスが復旧したら、JMSサービスをもう一度移行して元のサーバー・インスタンスに戻す場合もあります。自動的にプライマリ・サーバー・インスタンスに移行されるJTAトランザクション・リカバリ・サービスとは異なり、JMSサービスは自動的には戻されないため手動で移行する必要があります。

JTAトランザクション・リカバリ・サービスの自動移行を構成する手順

JTAトランザクション・リカバリ・サービスは、クラッシュ後にトランザクションのリカバリを正常に行うために設計されたものです。サーバー・ヘルス・モニタリング・サービスを使用することで、トランザクション・リカバリ・サービスを異常のあるサーバー・インスタンスから正常なサーバー・インスタンスに自動的に移行できます。これにより、障害が発生したサーバー・インスタンスのトランザクション処理をバックアップ・サーバー・インスタンスで完了できます。

トランザクション・リカバリ・サービスがクラスタ内の移行可能ターゲットに自動移行されるように構成するには、次のタスクを実行します。

- ステップ1: 管理対象サーバーとノード・マネージャを構成する

- ステップ2: 移行基盤を構成する

- ステップ3: JTAの自動移行を有効にする

- ステップ4: トランザクション・リカバリ・サービスの移行用にデフォルト永続ストアを構成する

- ステップ5: 変更した移行ポリシーで管理サーバーと管理対象サーバーを再起動する

- ステップ6: トランザクション・リカバリ・サービスを自動フェイルバックによって元のサーバーに戻す

ステップ1: 管理対象サーバーとノード・マネージャを構成する

管理対象サーバーをマシンに割り当てるなど、クラスタ内の管理対象サーバーを移行用に構成します。ノード・マネージャも実行中で、サーバーの自動移行ができるように構成されている必要があります。ノード・マネージャは、関係するサーバー・インスタンスに関するヘルス・ステータス情報の取得の際に必要です。

これらのタスクをWebLogic Server管理コンソールで実行する詳しい手順は、管理コンソールオンライン・ヘルプの次のトピックを参照してください。

- 「管理対象サーバーの作成」

注意:

- JTAトランザクション回復サービスをホストすることになる管理対象サーバーのインスタンスには、一意のリスニング・アドレス値を設定する必要があります。そうしないと、移行は失敗します。

- プライマリ・サーバー・インスタンスとリカバリ・モードの別のバックアップ・サーバー・インスタンスが同時にトランザクション・ログにアクセスすることを防止するために、プライマリ・サーバー・インスタンスが管理対象サーバー独立モード(MSI)で起動しないよう構成する方法は、『Oracle WebLogic Server JTAアプリケーションの開発』の管理対象サーバーの独立性に関する項を参照してください。

- 「マシンの作成と構成」

- 「ノード・マネージャの構成」

注意:

サービスの自動移行でコンセンサス・リースを使用する場合は、ノード・マネージャを使用してクラスタ内のサーバー・インスタンスを制御し、すべての移行可能サーバーにノード・マネージャのインスタンスを関連付ける必要があります。データベース・リースを使用する場合は、移行前スクリプトおよび移行後スクリプトを定義する場合にのみノード・マネージャが必要です。移行前スクリプトおよび移行後スクリプトが定義されていない場合、ノード・マネージャは必要ありません。

ノード・マネージャの構成の詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャの概要に関する項を参照してください。

ステップ2: 移行基盤を構成する

WebLogic Server管理コンソールの「クラスタ」→「構成」→「移行」ページで、データ永続性環境の構成方法に応じて、データベース・リーシングまたはコンセンサス・リーシングのいずれかを選択して、クラスタの「移行基盤」を構成します。「移行可能サービスのリース」を参照してください

ステップ3: JTAの自動移行を有効にする

WebLogic Server管理コンソールの「サーバー」→「構成」→「移行」ページの「JTA移行の構成」セクションで、次のオプションを構成します。

自動JTA移行ポリシーの選択

JTA移行可能なターゲットでホストされるサービスに対して移行ポリシーを選択します。有効なオプションは次のとおりです。

- 手動

- 障害リカバリ

- 停止リカバリ

注意:

JTAの場合、「1回のみ」移行ポリシーは適用されません。

これらのポリシーの詳細は、『Oracle Fusion Middleware Oracle WebLogic Server Administration Consoleオンラインヘルプ』のサーバー: 構成: 移行に関する項を参照してください。

「JTA移行ポリシー」ドロップダウン・リストから、JTA移行可能ターゲットによってホストされているサービスの移行ポリシーを選択してJTAトランザクション・リカバリ・サービスの自動移行を構成します。

候補サーバーを選択する(オプション)

トランザクション・リカバリ・サービスの移行先となり得るサーバー・インスタンスを、現在のサーバー・インスタンスのデフォルトWebLogicストアに格納されているトランザクション・ログ・ファイルにアクセスできるサーバー・インスタンスのみに制限することもできます。候補サーバー・インスタンスを選択しない場合は、クラスタ内のいずれかのサーバー・インスタンスが候補サーバー・インスタンスとして選択されます。

候補サーバーの「使用可能」ボックスから、JTAログ・ファイルにアクセスできる管理対象サーバーを選択します。管理対象サーバーは、「選択済み」ボックスに移動すると有効な候補サーバーになります。

注意:

必要に応じてトランザクション・リカバリ・サービスを手動で移行して元のサーバー・インスタンスに戻せるように、選択済のリストに移行元のサーバー・インスタンスを含めておく必要があります。WebLogic Server管理コンソールでこのルールが実行されます。

移行前/移行後スクリプトを指定する(オプション)

共有ストレージのアンマウントおよびマウントを実行する移行前/移行後スクリプトを使用するかどうかを指定します。

- 移行前スクリプトのパス - 移行可能ターゲットを実際にアクティブ化する前に実行する移行前スクリプトへのパスを指定します。

- 移行後スクリプトのパス - 移行可能ターゲットを完全に非アクティブ化にした後に実行する移行後スクリプトへのパスを指定します。

- 移行後スクリプトが失敗した場合に自動移行を取り消す - 移行後スクリプトの実行中に発生したエラーを、移行に対して致命的と判断するかどうかを指定します。

- 移行後スクリプトを別のマシンで実行できるようにする - 移行後スクリプトの実行を、別のマシンでも許可するかどうかを指定します。

移行前スクリプトおよび移行後スクリプトは、ORACLE_HOME/user_projects/domains/mydomain/bin/service_migrationディレクトリに配置する必要があります。mydomainはドメインに固有のディレクトリで、ドメインと同じ名前です。移行前スクリプトおよび移行後スクリプトを作成する基本的な手順は、このディレクトリ内のreadme.txtを参照してください。

ステップ4: トランザクション・リカバリ・サービスの移行用にデフォルト永続ストアを構成する

「JTAで使用できるデフォルト・ファイル・ストア」で説明したように、トランザクション・マネージャはデフォルト永続ストアを使用してトランザクション・ログ・ファイルを格納します。トランザクション・リカバリ・サービスの移行を有効化するには、移行元のサーバー・インスタンスで障害が発生した場合に、クラスタ内の別のサーバー・インスタンスから使用できる永続ストレージ・ソリューションにデータ・ファイルが格納されるよう、デフォルト永続ストアを構成する必要があります。

ステップ5: 変更した移行ポリシーで管理サーバーと管理対象サーバーを再起動する

JTAトランザクション・リカバリ・サービスを自動移行用に構成したら、管理サーバーを再起動する必要があります。

また、移行ポリシーを変更した管理対象サーバーも再起動する必要があります。

ステップ6: トランザクション・リカバリ・サービスを自動フェイルバックによって元のサーバーに戻す

障害が発生したサーバー・インスタンスでトランザクションのリカバリが完了すると、トランザクション・リカバリ・サービスの所有権がバックアップ・サーバー・インスタンスにより解放されるため、ターゲット・サーバー・インスタンスが再起動される際に、元のサーバー・インスタンスはこの所有権の返還を要求できます。トランザクションのリカバリが完了する前にバックアップ・サーバーが停止(クラッシュ)した場合は、そのリースが期限切れになります。これにより、プライマリ・サーバー・インスタンスは起動時に所有権の変換を要求できるようになります。

トランザクション・リカバリ・サービスのプライマリ・サーバー・インスタンスへの自動フェイルバックには、次の2つのシナリオがあります。

- リカバリが完了した後に自動フェイルバック:

- プライマリ・サーバー・インスタンスが再起動する前にバックアップ・サーバー・インスタンスがトランザクション・ログのトランザクション・リカバリを完了した場合は、トランザクション・リカバリ・サービスのプライマリ・サーバー・インスタンスへの移行が暗黙的に開始されます。

- 非アクティブ化後のスクリプトは、手動移行か自動移行かに関係なく自動的に実行されます。

- リカバリが完了する前に自動フェイルバック:

- プライマリ・サーバー・インスタンスが起動したときにトランザクション・ログのトランザクションのリカバリが進行中だった場合は、プライマリ・サーバーの起動時にトランザクション・リカバリ・サービスを開始する間に、バックアップ・サーバー・インスタンスからのトランザクション・リカバリ・サービスの暗黙的な移行が開始されます。

JTAトランザクション・リカバリ・サービスの手動移行

JTAトランザクション・リカバリ・サービスは、クラッシュ後にトランザクションのリカバリを正常に行うために設計されたものです。サーバー・ヘルス・モニタリング・サービスを使用することで、トランザクション・リカバリ・サービスを異常のあるサーバー・インスタンスから正常なサーバー・インスタンスに手動で移行できます。この方法で、障害が発生したサーバー・インスタンスのトランザクション処理をバックアップ・サーバー・インスタンスで完了できます。

移行先サーバー・インスタンスとして元のサーバー・インスタンスを選択すると、トランザクション・リカバリ・サービスを手動で移行して元のサーバー・インスタンスに戻すことができます。ただし、バックアップ・サーバー・インスタンスが実行中である場合は、トランザクション・リカバリ・サービスを手動で移行して元のサーバー・インスタンスに戻すことはできません。

次に注意してください:

- トランザクション・リカバリ・アクションが完了する前にバックアップ・サーバー・インスタンスで障害が発生した場合は、プライマリ・サーバー・インスタンスがトランザクション・リカバリ・サービスの所有権の変換を要求できないため、リカバリはサーバー・インスタンスの再起動時に再試行されません。したがって、この場合はトランザクション・リカバリ・サービスを別のバックアップ・サーバー・インスタンスに手動で移行しなおす必要があります。

- バックアップ・サーバー・インスタンスによるトランザクションのリカバリ中に元のサーバー・インスタンスを再起動した場合は、バックアップ・サーバー・インスタンスが正常にトランザクション・リカバリ・サービスの所有権を解放します。バックアップ・サーバー・インスタンスを停止する必要はありません。詳細は、『Oracle WebLogic Server JTAアプリケーションの開発』の障害が発生したクラスタ・サーバーのトランザクションの回復に関する項を参照してください。

- プライマリ・サーバー・インスタンスとリカバリ・モードの別のバックアップ・サーバー・インスタンスが同時にトランザクション・ログにアクセスすることを防止するために、プライマリ・バックアップ・サーバー・インスタンスが管理対象サーバー独立モード(MSI)で起動しないよう構成する方法は、『Oracle WebLogic Server JTAアプリケーションの開発』の管理対象サーバーの独立性に関する項を参照してください。

WebLogic Server管理コンソールを使用してトランザクション・リカバリ・サービスを手動で移行する手順は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのトランザクション・リカバリ・サービスの手動移行に関する項を参照してください。

ユーザー定義のシングルトン・サービスの自動移行

シングルトン・サービスの自動移行では、シングルトン・サービスのヘルス・モニタリングと移行を自動化できます。シングルトン・サービスとは、クラスタ内の複数のサーバー・インスタンスで同時に実行できないサービスです。移行可能サービスで障害が発生した場合や、サービス・コードのバグ、サーバーの障害、ネットワークの障害などの理由で使用不能になった場合、その移行可能サービスは現在のサーバー・インスタンスで非アクティブ化され、新しいサーバー・インスタンスでアクティブ化されます。これらのサービスを別のサーバー・インスタンスに移行するプロセスは、シングルトン・マスターによって処理されます。「シングルトン・マスター」を参照してください。

WebLogic Serverでは、ユーザー定義のシングルトン・サービスを自動的に移行できます。

注意:

JTAトランザクション・リカバリ・サービスも、クラスタ内の複数のノードで同時に実行できないシングルトン・サービスですが、その自動移行を構成する方法はユーザー定義のシングルトン・サービスとは異なります。JMSおよびJTAサービスも手動で移行できます。「サービスの移行フレームワークの理解」を参照してください

シングルトン・サービスの移行の概要

この項では、シングルトン・サービスの自動移行をWebLogic Serverに実装する方法の概略を示します。

シングルトン・マスター

シングルトン・マスターは、自動移行可能な他のサービスをモニターする軽量シングルトン・サービスです。その時点でシングルトン・マスターをホストしているサーバー・インスタンスは、各移行可能サービスに関連付けられた移行タスクを開始および停止する役割を担います。

注意:

移行可能サービスは、シングルトン・マスターと同じサーバー・インスタンスでホストする必要はありませんが、同じクラスタ内でホストする必要があります。

シングルトン・マスターは、リースの競合によって維持される点や、同時に複数のサーバー・インスタンスで実行できない点で、クラスタ・マスターと似ています。クラスタ内の各サーバー・インスタンスは、シングルトン・マスターのリースの登録を継続的に試行します。現時点でシングルトン・マスターをホストしているサーバー・インスタンスに障害が発生すると、キュー内の次のサーバー・インスタンスがそのリースを引き継ぎ、シングルトン・マスターのホストを開始します。

クラスタ・マスターの詳細は、「サーバー全体の移行におけるクラスタ・マスターの役割」を参照してください

注意:

シングルトン・マスターとクラスタ・マスターはそれぞれ独立して機能するため、同じサーバー・インスタンスでホストする必要はありません。

シングルトン・マスターをホストするサーバー・インスタンスには、実行されたすべての移行の記録(ターゲット名、移行元サーバー、移行先サーバー、タイムスタンプなど)が保持されます。

移行の失敗

シングルトン・サービスの移行がクラスタ内のすべての候補サーバー・インスタンスで失敗すると、サービスは非アクティブ化されたままになります。シングルトン・マスターがクラスタ内のサーバー・インスタンスを再試行する回数を構成できます。

注意:

候補サーバー・インスタンスのリストを明示的に指定していない場合は、クラスタ内のすべてのメンバーが移行の候補と見なされます。

シングルトン・サービス・インタフェースの実装

シングルトン・サービスはアプリケーションの一部として、またはスタンドアロン・サービスとして定義できます。シングルトン・サービスは一度に1つのサーバー・インスタンス上でのみアクティブになるので、クラスタ内の1つのメンバーでのみ実行させるタスクに使用できます。

シングルトン・サービスを作成するには、シングルトン・サービスで実行するタスクに加えて、weblogic.cluster.singleton.SingletonServiceインタフェースを実装するクラスを作成する必要があります。

SingletonServiceインタフェースには、移行のプロセスで使用する次のメソッドが含まれています。

- public void activate()
このメソッドは、シングルトン・サービスがリクエストの処理を開始するために必要なシステム・リソースの取得とサービスの開始を行います。このメソッドは次の場合に呼び出されます。

- 新たにデプロイされたアプリケーションが起動したとき

- サーバーの起動中

- サービス移行のアクティブ化段階

- public void deactivate()
このメソッドは、サーバーの停止中、およびシングルトン・サービスの移行の非アクティブ化段階に呼び出されます。このメソッドを呼び出すことで、activate()メソッドで取得したすべてのリソースが解放されます。また、クラスタの1つのメンバーからしか使用できないサービスはすべて停止します。

シングルトン・サービスのデプロイと移行動作の構成

SingletonServiceインタフェースを使用してシングルトン・サービスを定義した方法に応じて、次の手順を実行してシングルトン・サービスをデプロイする必要があります。

- アプリケーション内にシングルトン・サービスをパッケージ化してデプロイします(アプリケーション・スコープ)。
~または~

- シングルトン・サービスをWebLogic Server内にスタンドアロン・サービスとしてデプロイします(ドメイン全体)。

- また、シングルトン・サービスの移行動作を構成できます。

注意:

アプリケーション・スコープのシングルトン・サービスをパッケージ化してデプロイする場合は、WebLogic Server管理コンソールを使用して、どの管理対象サーバーでサービスがホストされるかを制御できません。ただし、ドメイン全体のシングルトン・サービスをデプロイする場合は、WebLogic Server管理コンソールでサーバー名、クラス名および優先管理対象サーバーを指定できます。

次の項では、これらの詳細手順の概要を示します。

アプリケーション内にシングルトン・サービスをパッケージ化してデプロイする

アプリケーション内にパッケージ化されるシングルトン・サービスでは、SingletonServiceインタフェースを実装するクラスが、デプロイメント用のJARファイル内のAPP-INF/libまたはAPP-INF/classesディレクトリ、あるいはEAR-level内のlibディレクトリに格納される必要があります。アプリケーション・スコープのシングルトン・サービスのJNDIバインドは、SingletonServiceインタフェースでプログラムによって実行されます。アプリケーション・スコープのシングルトン・サービスのライフサイクルは、そのアプリケーションのライフサイクルと関連しています。

スタンドアロン・シングルトン・サービスのクラスは、WebLogic Serverシステムのクラスパスで使用できるようにする必要があります。

また、weblogic-application.xml記述子ファイルに次のエントリを追加します。

<weblogic-application>
...
<singleton-service>
<class-name>mypackage.MySingletonServiceImpl</class-name>
<name>Appscoped_Singleton_Service</name>
</singleton-service>
...
</weblogic-application>

注意:

<class-name>および<name>要素は必須です。

アプリケーション・スコープのシングルトン・サービスのデプロイメントは、アプリケーション・デプロイメントの一環として自動的に行われます。アプリケーションがデプロイされるクラスタ・メンバーがシングルトン・サービスの候補サーバー・インスタンスとなります。

シングルトン・サービスをWebLogic Serverにスタンドアロン・サービスとしてデプロイする

SingletonServiceインタフェースを使用するシングルトン・サービス・クラスを作成した後で、そのクラスをWebLogic Server内でシングルトン・サービスとして定義する必要があります。このシングルトン・サービス・オブジェクトには次の情報が格納されます。

- シングルトン・サービスとしてロードするクラスのパス

- シングルトン・サービスの優先サーバー・インスタンスとその他の候補サーバー・インスタンス

次に示すconfig.xmlファイルの<cluster>要素からの抜粋は、シングルトン・サービスをどのように定義するかを示しています。

<singleton-service>
<name>SingletonTestServiceName</name>
<user-preferred-server>myManaged1</user-preferred-server>
<class-name>mycompany.myprogram.subpackage.SingletonTestServiceImpl</class-name>
<cluster>myCluster</cluster>
</singleton-service>

シングルトン・サービスの移行を構成する

シングルトン・サービスは自動的にExactly-Onceサービスとして構成されます。つまり、候補リスト内の少なくとも1つの管理対象サーバーが実行されている場合は、サービスはクラスタ内のどこかでアクティブになります。次の方法を使用して、シングルトン・サービスの移行に関する特定のパラメータを変更できます。

- WebLogic Server管理コンソール - シングルトン・サービスを作成して構成できます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのシングルトン・サービスの構成に関する項を参照してください。

- WebLogic Scripting Tool (WLST) - MigratableTargetManagementMBeanを使用してサービスの自動移行を構成できます。『WebLogic Server WLSTコマンド・リファレンス』のWLSTコマンドおよび変数リファレンスに関する項を参照してください。

9 クラスタ・アーキテクチャ

この章では、WebLogic Serverクラスタの各種アーキテクチャについて説明します。

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

- アーキテクチャとクラスタ関連の用語

- 推奨基本アーキテクチャ

- 推奨複数層アーキテクチャ

- 推奨プロキシ・アーキテクチャ

- クラスタ・アーキテクチャのセキュリティ・オプション

アーキテクチャとクラスタ関連の用語

この項では、このドキュメントで使用する用語を定義します。

アーキテクチャ

ここでは、アーキテクチャという用語は、アプリケーションの層が1つまたは複数のクラスタにデプロイされる仕組みを指します。

Webアプリケーションの層

Webアプリケーションは、複数の「層」に分けられます。「層」は、アプリケーションで提供される論理的なサービスに対応します。すべてのWebアプリケーションが似通っているわけではないので、アプリケーションによっては、次に説明する層のすべてを利用しない場合があります。また、層はアプリケーションのサービスの論理的な区分を示すものであり、必ずしもハードウェアまたはソフトウェアのコンポーネント間の物理的な区分を示すものではありません。1つのWebLogic Serverインスタンスを実行している1台のマシンが、次に説明するすべての層を提供する場合もあります。

- Web層
Web層では、Webアプリケーションのクライアントに対して静的なコンテンツ(単純なHTMLページなど)が提供されます。Web層は、通常、外部クライアントがWebアプリケーションにアクセスする最初のポイントになります。単純なWebアプリケーションでは、Apache、Netscape Enterprise ServerまたはMicrosoft Internet Information Serverを実行している1つまたは複数のマシンで構成されるWeb層が存在する場合もあります。

- プレゼンテーション層
プレゼンテーション層では、Webアプリケーションのクライアントに対して動的なコンテンツ(たとえばサーブレットやJava Server Pages)が提供されます。Webアプリケーションのプレゼンテーション層は、サーブレットやJSPのホストになるWebLogic Serverインスタンスのクラスタで構成されます。クラスタでアプリケーションの静的なHTMLページも提供される場合は、クラスタにはWeb層とプレゼンテーション層の両方が含まれます。

- オブジェクト層
オブジェクト層では、Webアプリケーションのクライアントに対してJavaオブジェクト(Enterprise JavaBeansやRMIクラスなど)や、それらに関連付けられたビジネス・ロジックが提供されます。EJBのホストになるWebLogic Serverクラスタは、オブジェクト層を提供します。

組合せ層アーキテクチャ

Webアプリケーションのすべての層を単一のWebLogic Serverクラスタにデプロイするようなクラスタ・アーキテクチャを組合せ層アーキテクチャと呼びます。

非武装地帯(DMZ)

非武装地帯(DMZ)は、外部の信頼できないソースからアクセス可能な、ハードウェアおよびサービスの論理的な集合です。ほとんどのWebアプリケーションでは、Webサーバーのバンクは、ブラウザ・ベースのクライアントからの静的なHTMLコンテンツへのアクセスが許可されているDMZ内に存在します。

DMZには、ハードウェアおよびソフトウェアに対する外部からの攻撃に備えてセキュリティが用意されている場合もあります。ただし、DMZは信頼性のないソースから使用できるので、その安全性は内部システムよりは劣ります。たとえば、内部システムは、外部からのアクセスをすべて拒否するファイアウォールによって保護できます。DMZは、アクセス先の個々のマシン、アプリケーション、またはポート番号を隠すファイアウォールによって保護できますが、信頼性のないクライアントからそれらのサービスにアクセスすることは可能です。

ロード・バランサ

ロード・バランサという用語は、このドキュメントでは、クライアントの接続リクエストを1つまたは複数の別々のIPアドレスに分散させる技術を指します。たとえば、単純なWebアプリケーションでは、DNSラウンドロビン・アルゴリズムがロード・バランサとして使用される場合があります。大規模なアプリケーションでは、通常、Alteon WebSystemsなどから発売されている、ファイアウォール類似のセキュリティ機能を備えたハードウェア・ベースのロード・バランシング・ソリューションが使用されます。

ロード・バランサには、クライアント接続をクラスタ内の特定のサーバーに関連付ける機能があります。この機能は、クライアント・セッション情報のインメモリー・レプリケーションを使用する場合に必要です。一部のロード・バランシング製品では、インメモリー・レプリケーションで使用されるプライマリ・サーバーおよびセカンダリ・サーバーを追跡するWebLogic ServerのCookieを上書きしないように、Cookieの永続性メカニズムを構成する必要があります。詳細は、「外部ロード・バランサによるHTTPセッションのロード・バランシング」を参照してください。

プロキシ・プラグイン

プロキシ・プラグインとは、WebLogic Serverクラスタによって提供される、クラスタ化されたサーブレットにアクセスするApache、Netscape Enterprise Server、またはMicrosoft Internet Information ServerなどのHTTPサーバーに対するWebLogic Serverの拡張機能のことです。プロキシ・プラグインには、WebLogic Serverクラスタ内のサーブレットおよびJSPへのアクセスに対するロード・バランシング・ロジックが含まれます。また、クライアントのセッション状態のホストになっている主要なWebLogic Serverに障害が発生した場合の、セッション状態のレプリカへのアクセスに対するロジックも含まれます。

推奨基本アーキテクチャ

推奨基本アーキテクチャは、Webアプリケーションのすべての層が同じWebLogic Serverクラスタにデプロイされる組合せ層アーキテクチャです。このアーキテクチャを次の図9-1に示します。

図9-1 推奨基本アーキテクチャ

推奨基本アーキテクチャの利点は、次のとおりです。

- 管理の容易さ
1つのクラスタが、静的HTTPページ、サーブレットおよびEJBのホストになるため、WebLogic Server管理コンソールを使用して、Webアプリケーション全体を構成したり、オブジェクトをデプロイまたはアンデプロイしたりできます。クラスタ化されたサーブレットの利益を得るために、Webサーバーのバンクを別々に保持する(およびWebLogic Serverプロキシ・プラグインを構成する)必要はありません。

- 柔軟性の高いロード・バランシング
WebLogic Serverクラスタの前で直接ロード・バランシング・ハードウェアを使用することで、HTMLコンテンツとサーブレット・コンテンツ両方へのアクセスに対して高度なロード・バランシング・ポリシーを使用できます。たとえば、現在のサーバーの負荷を検出し、クライアントのリクエストを適切に送信するよう、ロード・バランサを構成できます。

- 堅牢なセキュリティ
ロード・バランシング・ハードウェアの前にファイアウォールを配置することで、Webアプリケーションに対して、最小限のファイアウォール・ポリシーを使用する非武装地帯(DMZ)を設定できます。

- 最適なパフォーマンス
組合せ層アーキテクチャでは、プレゼンテーション層のほとんどまたはすべてのサーブレットあるいはJSPがオブジェクト層のオブジェクト(EJBなど)に通常アクセスするアプリケーションに対して、最適なパフォーマンスを提供します。

注意:

インメモリー・セッション・レプリケーションでサード・パーティ製のロード・バランサを使用する場合は、プライマリ・セッション状態のホストとなるWebLogic Serverインスタンス(接続先サーバー)へのクライアント接続を、ロード・バランサが保持するようにしなければなりません。ロード・バランサの詳細は、「外部ロード・バランサによるHTTPセッションのロード・バランシング」を参照してください

組合せ層アーキテクチャを使用しない状況

推奨基本アーキテクチャなどの組み合わせ層アーキテクチャは多くのWebアプリケーションのニーズに適していますが、クラスタのロード・バランシングおよびフェイルオーバー機能を活用できる度合いは多少限定されます。ロード・バランシングおよびフェイルオーバーは、Webアプリケーションの各層間のインタフェースでのみ導入できます。そのため、すべての層を単一のクラスタにデプロイするときは、クライアントとクラスタの間でのロード・バランシングしか行うことができません。

ロード・バランシングとフェイルオーバーの大部分は、クライアントとクラスタ自身の間で発生するので、組合せ層アーキテクチャでも、ほとんどのWebアプリケーションのニーズを満たすことができます。

しかし、組み合わせ層クラスタには、クラスタ化されたEJBへのメソッド呼出しに対してロード・バランシングを実行する機会がありません。クラスタ化オブジェクトは、クラスタ内のすべてのWebLogic Serverインスタンスにデプロイされるので、各オブジェクト・インスタンスは各サーバーでローカルに使用できます。WebLogic Serverでは、常にローカルのオブジェクト・インスタンスを選択することにより、クラスタ化されたEJBに対するメソッド呼出しが最適化されます。リクエストをリモート・オブジェクトに分散させないので、ネットワークのオーバーヘッドが増加しません。

この連結戦略は、ほとんどの場合で、異なるサーバーへの各メソッド・リクエストに対してロード・バランシングを行うよりも効率的です。ただし、各サーバーの負荷が不均衡な場合は、ローカルでメソッドを処理するよりも、リモート・オブジェクトにメソッド呼出しを送信する方が結果的に効率的になる場合もあります。

クラスタ化されたEJBへのメソッド呼出しに対してロード・バランシングを行うには、次の項で説明するように、Webアプリケーションのプレゼンテーション層とオブジェクト層を物理的に異なるクラスタ上に分割する必要があります。

組合せ層アーキテクチャと複数層アーキテクチャのどちらかに決定する際には、プレゼンテーション層によるオブジェクト層の呼出しの頻度を考慮してください。プレゼンテーション・オブジェクトが通常オブジェクト層を呼び出す場合、組合せ層アーキテクチャは、複数層アーキテクチャよりも高いパフォーマンスを示す可能性があります。

推奨複数層アーキテクチャ

この項では、推奨複数層アーキテクチャについて説明します。このアーキテクチャでは、アプリケーションの各層が複数の異なったクラスタにデプロイされます。

推奨多層アーキテクチャでは、2つの異なるWebLogic Serverクラスタを使用します。1つは静的なHTTPコンテンツを提供するクラスタであり、もう1つはクラスタ化されたEJBを提供するクラスタです。多層クラスタは、次のようなWebアプリケーションにお薦めします。

- クラスタ化されたEJBへのメソッド呼出しに対するロード・バランシングが必要です。

- HTTPコンテンツを提供するサーバーとクラスタ化オブジェクトを提供するサーバーの間により柔軟性の高いロード・バランシングが必要です。

- より高い可用性(シングル・ポイント障害がより少ないこと)が必要です。

注意:

複数層アーキテクチャを検討する場合は、プレゼンテーション層からオブジェクト層への呼出しの頻度を考慮してください。プレゼンテーション・オブジェクトが通常オブジェクト層を呼び出す場合、組合せ層アーキテクチャは、複数層アーキテクチャよりも高いパフォーマンスを示す可能性があります。

図9-2は、推奨複数層アーキテクチャを示します。

図9-2 推奨複数層アーキテクチャ

ハードウェアとソフトウェアの物理レイヤー

推奨複数層アーキテクチャでは、アプリケーションの各層が2つの異なった物理レイヤー(ハードウェアとソフトウェア)上に配置されます。

Web/プレゼンテーション・レイヤー

Web/プレゼンテーション・レイヤーは、静的なHTTPページ、サーブレット、およびJSPの専用ホストになっているWebLogic Serverインスタンスのクラスタで構成されます。このサーブレット・クラスタは、クラスタ化オブジェクトのホストにはなりません。そのかわりに、プレゼンテーション層クラスタ内のサーブレットは、オブジェクト・レイヤーにある異なるWebLogic Serverクラスタ内のクラスタ化オブジェクトのクライアントとして機能します。

オブジェクト・レイヤー

オブジェクト・レイヤーは、Webアプリケーションで必要なクラスタ化オブジェクト(EJBオブジェクトおよびRMIオブジェクト)専用のホストになるWebLogic Serverインスタンスのクラスタで構成されます。専用クラスタにオブジェクト層のホストを配置することで、クラスタ化オブジェクトへのアクセスに対するデフォルトの連結の最適化(「連結されたオブジェクトの最適化」を参照)が失われますただし、次の項で説明するように、特定のクラスタ化オブジェクトへの各メソッド呼出しに対するロード・バランシングは可能になります。

複数層アーキテクチャの利点

複数層アーキテクチャには、これらの利点があります。

- EJBメソッドのロード・バランシング
サーブレットとEJBのホストを異なるクラスタに配置することで、サーブレットのEJBへのメソッド呼出しで、複数のサーバーにわたるロード・バランシングが可能になります。このプロセスについては、「複数層アーキテクチャでのクラスタ化オブジェクトのロード・バランシング」で詳しく説明しています。

- 改良されたサーバー・ロード・バランシング
プレゼンテーション層とオブジェクト層を別々のクラスタに分割することで、Webアプリケーションの負荷分散に関するオプションが増加します。たとえば、アプリケーションがEJBコンテンツよりも頻繁にHTTPおよびサーブレット・コンテンツにアクセスする場合は、プレゼンテーション層のクラスタで数多くのWebLogic Serverインスタンスを使用し、EJBのホストになるサーバーを少数にしてアクセスを集中させることができます。

- より高い可用性
追加のWebLogic Serverインスタンスを利用することで、複数層アーキテクチャの障害ポイントはベース・クラスタ・アーキテクチャよりも少なくなります。たとえば、EJBのホストになっているWebLogic Serverに障害が発生しても、WebアプリケーションのHTTPやサーブレットのホストとなる機能には影響しません。

- 改良されたセキュリティ・オプション
プレゼンテーション層とオブジェクト層を別々のクラスタに分割することで、DMZにサーブレット/JSPクラスタだけを配置するファイアウォール・ポリシーを使用できます。信頼性のないクライアントからの直接アクセスを拒否することで、クラスタ化オブジェクトのホストになっているサーバーの保護を強化できます。詳細は、「クラスタ・アーキテクチャのセキュリティ・オプション」を参照してください。

複数層アーキテクチャでのクラスタ化オブジェクトのロード・バランシング

「連結されたオブジェクトの最適化」で説明されているように、クラスタ化オブジェクトに対するWebLogic Serverの連結の最適化は、クラスタ化オブジェクト(EJBまたはRMIクラス)のホストが、オブジェクトを呼び出すレプリカ対応スタブと同じサーバー・インスタンスに配置されることに基づいています。

オブジェクト層を分離することの最終的な効果としては、クライアント(HTTPクライアント、Javaクライアントまたはサーブレット)が、クラスタ化オブジェクトのホストになるサーバーと同じサーバーにあるレプリカ対応スタブを取得できなくなります。このため、WebLogic Serverでは、連結の最適化を使用できず(「連結されたオブジェクトの最適化」を参照)、クラスタ化オブジェクトに対するサーブレット呼出しはレプリカ対応スタブにあるロジックに従って自動的にロード・バランシングされます。図9-3は、複数層アーキテクチャ内のクラスタ化されたEJBインスタンスにアクセスするクライアントを示します。

図9-3 複数層アーキテクチャでのオブジェクトのロード・バランシング

クライアント接続の経路をトレースすると、異なるハードウェアとソフトウェアにオブジェクト層を分離させる意味が理解できます。

1. HTTPクライアントは、Web/サーブレット・クラスタ内に複数あるWebLogic Serverインスタンスのいずれか1つに接続し、ロード・バランサを経由して最初のサーバーに到達します。

2. クライアントはWebLogic Serverクラスタにホストが配置されたサーブレットにアクセスします。

3. サーブレットはWebアプリケーションで必要になるクラスタ化オブジェクトのクライアントとして機能します。前述の例では、サーブレットはステートレス・セッションEJBにアクセスします。
サーブレットは、クラスタ化オブジェクトのホストになる、WebLogic ServerクラスタにあるEJBをルックアップします。サーブレットは、Beanのレプリカ対応スタブを取得します。スタブには、Beanのホストになるすべてのサーバーのアドレスと、Beanのレプリカへのアクセスに対するロード・バランシング・ロジックが示されています。

注意:

EJBデプロイメント記述子の要素を使用して、EJBレプリカ対応スタブおよびEJBホーム・ロード・アルゴリズムを指定します。詳細は、『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』のweblogic-ejb-jar.xmlデプロイメント記述子のリファレンスに関する項を参照してください。

4. 次にEJBにアクセスしたとき(たとえば、別のクライアントに対するレスポンスとして)、サーブレットは、Beanのスタブに示されているロード・バランシング・ロジックを使用してレプリカを見つけます。上記の例では、複数のメソッド呼出しがロード・バランシングのラウンドロビン・アルゴリズムを使用して送信されます。

この例では、同じWebLogic ServerクラスタがサーブレットとEJBの両方のホストになっている場合(「推奨基本アーキテクチャ」を参照)、WebLogic ServerではEJBのリクエストに対するロード・バランシングは実行されません。その代わり、サーブレットは常に、ローカル・サーバーがホストになっているEJBレプリカでメソッドを呼び出します。ローカルのEJBインスタンスを使用した方が、別のサーバーにあるEJBに対してリモート・メソッド呼出しを行うよりも効率的です。しかし、複数層アーキテクチャでは、EJBメソッド呼出しのロード・バランシングを必要とするアプリケーションに対してリモートEJBアクセスが可能です。

複数層アーキテクチャの構成に関する考慮事項

複数層アーキテクチャでは、次の項で説明するように、構成の調整が必要になる場合があります。

IPソケットの使用数

複数層アーキテクチャではクラスタ化オブジェクトへの呼出しに対するロード・バランシングが提供されるため、システムでは通常、組合せ層より多いIPソケットが使用されます。特に、ソケットの最大使用時には、サーブレットおよびJSPをホストするクラスタ内の各WebLogic Serverインスタンスは、次を最大限に使用する可能性があります。

- プライマリ・サーバーとセカンダリ・サーバーの間でHTTPセッション状態をレプリケートするためのソケット

- EJBクラスタ内の各WebLogic Serverに1つずつある、リモート・オブジェクトにアクセスするためのソケット

たとえば、図9-2では、サーブレット/JSPクラスタ内の各サーバーは最大で5つのソケットをオープンする可能性があります。この最大数は、プライマリおよびセカンダリの各セッション状態が均等にサーブレット・クラスタ全体に分散していて、サーブレット・クラスタ内の各サーバーがオブジェクト・クラスタ内の各サーバーのリモート・オブジェクトに同時にアクセスするという、最悪のケースを表しています。ほとんどの場合、実際に使用されるソケット数はこの最大数より小さくなります。

複数層アーキテクチャでpure-Javaソケット実装を使用する場合は、ソケットの最大使用に対応できるだけのソケット・リーダー・スレッドを構成していることを確認してください。詳細は、「Javaソケット実装用にリーダー・スレッドを構成する」を参照してください。

ハードウェア・ロード・バランサ

複数層アーキテクチャではハードウェア・ロード・バランサを使用するため、インメモリー・セッション状態レプリケーションを使用する場合は、クライアントの接続先サーバーに対するセッション維持型の接続を保持するように、ロード・バランサを構成しなければなりません。手順については、「EJBとRMIのロード・バランシング方式を構成する」を参照してください。

複数層アーキテクチャに関する制限

この項では、複数層クラスタ・アーキテクチャでの制限の概要を示します。

連結の最適化が行われない

推奨複数層アーキテクチャでは、連結戦略を使用してオブジェクト呼出しを最適化できないので、Webアプリケーションでは、クラスタ化オブジェクトに対するすべてのメソッド呼出しでネットワークのオーバーヘッドが発生します。ただし、このオーバーヘッドは、Webアプリケーションで「複数層アーキテクチャの利点」で説明した利点のいずれかが必要な場合には許容できる場合もあります。

たとえば、WebクライアントがサーブレットおよびJSPを頻繁に使用するものの、クラスタ化オブジェクトへのアクセスは比較的少ない場合、複数層アーキテクチャではサーブレットおよびオブジェクトの負荷を適切に集中させることができます。各サーバーの処理能力を最大限に利用しながら、10個のWebLogic Serverインスタンスを含むサーブレット・クラスタと3個のWebLogic Serverインスタンスを含むオブジェクト・クラスタを構成できます。

ファイアウォールに関する制限

複数層アーキテクチャのサーブレット・クラスタとオブジェクト・クラスタの間にファイアウォールを配置する場合は、オブジェクト・クラスタ内のすべてのサーバーをIPアドレスではなく、外部に公開されているDNS名にバインドさせる必要があります。サーバーをIPアドレスにバインドさせると、アドレス変換に関する問題が発生し、サーブレット・クラスタが各サーバー・インスタンスにアクセスできなくなる場合があります。

WebLogic Serverインスタンスの内部DNS名と外部DNS名が同じでない場合、サーバー・インスタンスのExternalDNSName属性を使用して、サーバーの外部DNS名を定義します。ファイアウォールの外で、ExternalDNSNameはサーバーの外部IPアドレスに変換されます。

クライアントがt3およびデフォルト・チャネルを使用してWebLogic Serverにアクセスする場合を除き、ファイアウォールがネットワーク・アドレス変換を実行する構成では、ExternalDNSNameを使用する必要があります。たとえば、ファイアウォールがネットワーク・アドレス変換を実行し、クライアントがプロキシ・プラグインを介してHTTPでWebLogic Serverにアクセスする構成では、ExternalDNSNameが必須です。

推奨プロキシ・アーキテクチャ

既存のWebサーバーと連携して動作するよう、WebLogic Serverクラスタを構成することができます。そのようなアーキテクチャではWebサーバーのバンクはWebアプリケーションの静的なHTTPコンテンツを提供し、WebLogicプロキシ・プラグインまたはHttpClusterServletを使用してクラスタにサーブレット・リクエストおよびJSPリクエストを送信します。

次の項では、2種類の代替プロキシ・アーキテクチャについて説明します。

2層プロキシ・アーキテクチャ

図9-4に示す2層プロキシ・アーキテクチャは、推奨基本アーキテクチャとほぼ同じです。異なる点は、静的なHTTPサーバーのホストがWebサーバーのバンクに配置されることのみです。

図9-4 2層プロキシ・アーキテクチャ

ハードウェアとソフトウェアの物理レイヤー

2層プロキシ・アーキテクチャには、ハードウェアとソフトウェアの物理レイヤーが2つあります。

Webレイヤー

プロキシ・アーキテクチャでは、アプリケーションのWeb層を提供するタスクに特化したハードウェアとソフトウェアのレイヤーが利用されます。この物理的なWebレイヤーは、次のアプリケーションの組合せのいずれか1つのホストである、1つまたは複数の同じように構成されたマシンで構成されます。

- WebLogic ServerとHttpClusterServlet

- ApacheとWebLogic Server Apache Server (プロキシ)プラグイン

- Netscape Enterprise ServerとWebLogic Server NSAPI (プロキシ)プラグイン

- Microsoft Internet Information ServerとWebLogic Server Microsoft-IIS (プロキシ)プラグイン

選択するWebサーバー・ソフトウェアに関係なく、Webサーバーの物理層では静的なWebページのみが提供されるようにする必要があります。動的なコンテンツ(サーブレットやJSP)は、プロキシ・プラグインまたはHttpClusterServletを経由して、プレゼンテーション層のサーブレットやJSPのホストになるWebLogic Serverクラスタにプロキシされます。

サーブレット/オブジェクト・レイヤー

推奨2層プロキシ・アーキテクチャでは、プレゼンテーション層およびオブジェクト層のホストはWebLogic Serverインスタンスのクラスタに配置されます。このクラスタは、単一のマシンまたは複数の異なるマシンにデプロイできます。

サーブレット/オブジェクト・レイヤーは、組合せ層クラスタ(「推奨基本アーキテクチャ」を参照)とは、アプリケーションのクライアントに静的なHTTPコンテンツを提供しないという点で異なります。

複数層プロキシ・アーキテクチャ

また、Webサーバーのバンクを、プレゼンテーション層およびオブジェクト層のホストになる1対のWebLogic Serverクラスタに対するフロント・エンドとして使用することもできます。このアーキテクチャを次の図9-5に示します。

図9-5 複数層プロキシ・アーキテクチャ

このアーキテクチャには、「推奨複数層アーキテクチャ」と同じ利点(および同じ制限)があります。異なる点は、Web層がWebLogicプロキシ・プラグインを利用するWebサーバーの異なるバンクに配置されることのみです。

プロキシ・アーキテクチャの利点

スタンドアロンWebサーバーとプロキシ・プラグインを使用すると、次の利点があります。

- 既存のハードウェアの利用
静的なHTTPコンテンツをクライアントに提供するWebアプリケーション・アーキテクチャがすでに存在する場合は、1つまたは複数のWebLogic Serverクラスタを持つ既存のWebサーバーを簡単に統合して、動的なHTTPおよびクラスタ化オブジェクトを提供できます。

- 一般的なファイアウォール・ポリシー
WebアプリケーションのフロントエンドでWebサーバー・プロキシを使用することで、一般的なファイアウォール・ポリシーを使用してDMZを定義できます。通常は、アーキテクチャの残りのWebLogic Serverクラスタへの直接接続を禁止している間は、DMZ内に引続きWebサーバーを配置することができます。上記の図には、このDMZポリシーが示されています。

プロキシ・アーキテクチャの制限

スタンドアロンWebサーバーとプロキシ・プラグインを使用すると、Webアプリケーションが次のような制限を受けます。

- 追加の管理
プロキシ・アーキテクチャ内のWebサーバーは、サード・パーティ・ユーティリティを使用して構成する必要があり、WebLogic Server管理ドメインには表示されません。また、クラスタ化されたサーブレットへのアクセスおよびフェイルオーバーの恩恵を受けるためには、WebサーバーにWebLogicプロキシ・プラグインをインストールおよび構成する必要があります。

- 限定的なロード・バランシング・オプション
プロキシ・プラグインまたはHttpClusterServletを使用して、クラスタ化されたサーブレットにアクセスする場合は、ロード・バランシング・アルゴリズムが単純なラウンドロビン戦略に制限されます。

プロキシ・プラグインとロード・バランサ

WebLogic Serverクラスタでロード・バランサを直接使用すると、サーブレット・リクエストのプロキシに関する利点がもたらされます。まず、ロード・バランサを持つWebLogic Serverを使用することにより、クライアントの設定における追加管理が不要になります。HTTPサーバーのレイヤーを別に設定し保持する必要もなく、1つまたは複数のプロキシ・プラグインをインストールおよび構成する必要もありません。また、Webプロキシ・レイヤーの削除により、クラスタへのアクセスに必要なネットワーク接続数も削減されます。

ロード・バランシング・ハードウェアを使用することで、システムの能力に適合したロード・バランシング・アルゴリズムをより柔軟に定義できるようになります。使用するロード・バランシング・ハードウェアでサポートされている、任意のロード・バランシング戦略(ロード・ベースのポリシーなど)を使用できます。プロキシ・プラグインまたはHttpClusterServletを使用する場合、クラスタ化されたサーブレットへのリクエストについては、単純なラウンドロビン・アルゴリズムに制限されます。

ただし、インメモリー・セッション状態レプリケーションを使用している場合、サード・パーティ製のロード・バランサを使用するには、さらに構成を行う必要があります。この場合は、クライアントがプライマリ・セッション状態情報にアクセスできるようにするため、クライアントと接続先のサーバー間でセッション維持型の接続を保持するように、ロード・バランサを構成しなければなりません。プロキシは自動的にセッション維持型の接続を保持するため、プロキシ・プラグインを使用する場合は特別な構成は不要です。

クラスタ・アーキテクチャのセキュリティ・オプション

推奨構成にあるハードウェアとソフトウェアの物理レイヤーの間の境界には、Webアプリケーションの非武装地帯(DMZ)を定義できるポイントがあります。ただし、すべての境界で物理的なファイアウォールがサポートされているわけではありません。特定の境界で典型的なファイアウォール・ポリシーのサブセットがサポートされているだけです。

次の項では、DMZを定義して、様々なレベルのアプリケーション・セキュリティを作成する方法について説明します。

プロキシ・アーキテクチャの基本ファイアウォール

基本ファイアウォール構成では、信頼性のないクライアントとWebサーバー・レイヤーの間に1つのファイアウォールを使用します。このファイアウォール構成は、推奨基本アーキテクチャまたは推奨複数層アーキテクチャのクラスタ・アーキテクチャで使用できます。

図9-6 ファイアウォールを使用する基本プロキシ・アーキテクチャ

図9-6の構成では、1つのファイアウォールで任意のポリシー(アプリケーション・レベルの制限、NAT、IPマスカレード)の組合せを使用して、3つのHTTPサーバーへのアクセスをフィルタ処理しています。ファイアウォールの最も重要な役割は、システム内のその他のサーバーへのアクセスを拒否することです。つまり、信頼性のないクライアントからは、サーブレット・レイヤー、オブジェクト・レイヤー、およびデータベースにはアクセスできないようにする必要があります。

物理的なファイアウォールは、DMZ内のWebサーバーの前後どちらにも配置できます。Webサーバーの前にファイアウォールを配置すると、Webサーバーへのアクセスを許可し、その他のすべてのシステムへのアクセスを拒否するだけで済むので、ファイアウォール・ポリシーを簡素化できます。

プロキシ・レイヤーとクラスタの間のファイアウォール

プロキシ・レイヤーとクラスタの間にファイアウォールを配置する場合は、次の構成ガイドラインに従ってください。

- プロキシ・プラグインがクラスタ内の各サーバーにアドレス変換エラーなしで接続できるようにするため、IPアドレスではなく外部に公開されたDNS名を使用して、クラスタ化サーバー・インスタンスにバインドします。IPアドレスを使用すると、「ファイアウォールについての考慮事項」で説明するようにアドレス変換エラーが発生する可能性があります。

- クラスタ化サーバー・インスタンスの内部DNS名と外部DNS名が同じでない場合、サーバー・インスタンスのExternalDNSName属性を使用して、その外部DNS名を定義します。ファイアウォールの外で、ExternalDNSNameはサーバー・インスタンスの外部IPアドレスに変換されます。

注意:

クラスタ化サーバーが、1組のカスタム・チャネルのHTTPSトラフィックおよびHTTPトラフィックを分離する場合は、『Oracle WebLogic Serverサーバー環境の管理』のチャネル、プロキシ・サーバー、およびファイアウォールに関する項を参照してください。

基本ファイアウォール構成のDMZ

Webサーバー・レイヤーへのアクセス以外のすべてのアクセスを拒否することによって、基本ファイアウォール構成では、3つのWebサーバーのみが含まれる小規模なDMZが作成されます。ただし、DMZをどんなに慎重に定義しても、悪意のあるクライアントがプレゼンテーション層とオブジェクト層のホストになっているサーバーにアクセスする可能性があることは考慮に入れておいてください。

たとえば、ハッカーがWebサーバーのホストになっているマシンの1つにアクセスしたと仮定します。アクセスのレベルによっては、動的なコンテンツを求めてWebサーバーがアクセスする、プロキシされたサーバーに関する情報を、ハッカーが入手できる場合もあります。

DMZをより慎重に定義する場合には、追加のファイアウォールを配置できます(「共有データベースに対するセキュリティの追加」を参照)。

ファイアウォールとロード・バランサの組合せ

推奨クラスタ・アーキテクチャでロード・バランシング・ハードウェアを使用する場合は、基本ファイアウォールとの関連を考慮してハードウェアのデプロイ方法を決定する必要があります。数多くのハードウェア・ソリューションでは、ロード・バランシング・サービスに加えてセキュリティ機能も提供されていますが、ほとんどのサイトではWebアプリケーションの防御の最前線としてファイアウォールが使用されています。通常、ファイアウォールでは、Webトラフィックを制限するための、最もよくテストされた一般的なセキュリティ・ソリューションが提供されます。ファイアウォールは、次の図9-7に示すようにロード・バランシング・ハードウェアの前で使用する必要があります。

図9-7 ファイアウォールとロード・バランサを使用する基本プロキシ・アーキテクチャ

前述の設定では、Web層を含むDMZ内にロード・バランサが配置されています。この構成でファイアウォールを使用すると、ファイアウォールはロード・バランサへのアクセスを制限するのみで済むため、セキュリティ・ポリシーの管理を簡素化できます。また、この設定では、次の説明のように、Webアプリケーションにアクセスする内部クライアントをサポートするサイトの管理を簡素化することもできます。

内部クライアントに対するファイアウォールの拡張

Webアプリケーションへの直接アクセスを必要とする内部クライアント(独自のJavaアプリケーションを実行するリモート・マシンなど)をサポートする場合は、プレゼンテーション層への制限されたアクセスを許可できるよう、基本ファイアウォール構成を拡張できます。アプリケーションへのアクセスを拡張する方法は、リモート・クライアントを信頼性のある接続として扱うか、または信頼性のない接続として扱うかによって変わります。

仮想プライベート・ネットワーク(VPN)を使用して、リモート・クライアントをサポートする場合は、クライアントを信頼性のある接続として扱うことができ、クライアントはファイアウォールの向こう側のプレゼンテーション層に直接接続できます。この構成は、次の図9-8のようになります。

図9-8 VPNユーザーのファイアウォール経由のアクセスは制限される

VPNを使用しない場合は、Webアプリケーションへのすべての接続(独自のクライアント・アプリケーションを使用するリモート・サイトからの接続も含む)は、信頼できない接続として扱う必要があります。この場合は、図9-9に示すように、プレゼンテーション層をホストするWebLogic Serverインスタンスへのアプリケーション・レベルの接続を許可するようにファイアウォール・ポリシーを変更できます。

図9-9 アプリケーション・コンポーネントのファイアウォール経由のアクセスは制限される

共有データベースに対するセキュリティの追加

Webアプリケーションの内部データと外部から入手できるデータの両方をサポートする1つのデータベースを使用する場合は、データベースにアクセスするオブジェクト・レイヤーの間に強固な境界を配置することを検討する必要があります。この場合、ファイアウォールを追加することによって、「プロキシ・アーキテクチャの基本ファイアウォール」で説明されているDMZ境界を簡単に強化できます。

ファイアウォールが2つある構成のDMZ

図9-10の構成では、Webアプリケーションと内部(信頼性のある)クライアントによって共有されているデータベース・サーバーの前に追加のファイアウォールが配置されています。この構成では、最初のファイアウォールが万一破られた場合や、ハッカーが最終的にオブジェクト層のホストになっているサーバーにアクセスした場合のための追加のセキュリティが提供されています。本番環境では、この環境はあり得ません。サイトでは、ハッカーがオブジェクト・レイヤーにあるマシンにアクセスするよりもずっと前に、悪意のある侵入を検出し、くい止める機能が必要になります。

図9-10 ファイアウォールが2つあるアーキテクチャのDMZ

上記の構成では、オブジェクト層とデータベースの間の境界は追加のファイアウォールによって強固になっています。ファイアウォールは、オブジェクト層のホストになっているWebLogic ServerからのJDBC接続以外のすべての接続を拒否する厳密なアプリケーション・レベルのポリシーを保持します。

10 WebLogicクラスタの設定

この章では、WebLogic Serverクラスタを構成するためのガイドラインと手順を示します。

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

- 開始する前に

- クラスタ実装の手順

開始する前に

この項では、WebLogic Serverクラスタを設定するための前提条件となる作業および情報についてまとめています。

構成プロセスについて

クラスタの構成プロセスと、構成タスクの実施方法の基本を理解しておくと、この項で示す情報がより有益なものとなります。

WebLogic Serverが備える構成機能と、それらの機能を通じて実施できるタスクの詳細は、「クラスタの構成の理解」を参照してください

クラスタ・アーキテクチャを決定する

どのクラスタ・アーキテクチャが、ターゲット・アプリケーションのニーズに最も適しているかを決定します。アーキテクチャ上の重要な決定には、次のものがあります。

- すべてのアプリケーション層を1つのクラスタにまとめるか、それともアプリケーションの各層を複数のクラスタ間に分離するか

- クラスタ内のサーバー・インスタンス間での負荷調整の方法。次のうちどの方法を使用するか

- WebLogic Serverの基本ロード・バランシング機能を使用する

- サード・パーティ製のロード・バランサを実装する、または

- アプリケーションのWeb層を1つ以上のセカンダリHTTPサーバーにデプロイし、Web層へのリクエストをプロキシで中継する

- Webアプリケーションに対して、1つ以上のファイアウォールを備えた非武装地帯(DMZ)を定義するか

これらを決定するためには、「クラスタ・アーキテクチャ」,および「クラスタでのロード・バランシング」の情報が参考になります。

選択するアーキテクチャによって、クラスタの設定方法も変わります。クラスタ・アーキテクチャによっては、ロード・バランサ、HTTPサーバー、プロキシ・プラグインなどの、他のリソースのインストールまたは構成が必要になる場合もあります。

ネットワーク・トポロジとセキュリティ・トポロジを検討する

アプリケーションのセキュリティ要件は、適切なセキュリティ・トポロジを設計するための基礎となります。多様なレベルのアプリケーション・セキュリティを提供する各種の代替アーキテクチャの詳細は、「クラスタ・アーキテクチャのセキュリティ・オプション」を参照してください

注意:

一部のネットワーク・トポロジは、マルチキャスト通信に干渉することがあります。WANにクラスタをデプロイしている場合の注意事項については、「クラスタがWAN内の複数のサブネットにまたがる場合」 を参照してください

1つのクラスタ内のサーバー・インスタンス群を、ファイアウォールをまたいでデプロイしないでください。ファイアウォールを通過するマルチキャスト・トラフィックのトンネリングの影響については、「ファイアウォールがマルチキャスト通信を遮断することがある」を参照してください

クラスタをインストールするマシンを選択する

WebLogic Serverをインストールする予定の1台以上のマシン(この項では「ホスト」と呼ぶ)を確定し、各マシンが必要なリソースを備えていることを確認します。WebLogic Serverでは、クラスタを非マルチホーム環境の1台のマシン上に設定できます。この新しい機能は、デモンストレーションまたは開発用の環境で役立ちます。

注意:

IPアドレスが動的に割り当てられるマシンにWebLogic Serverをインストールしないでください。

マルチCPUマシン上のWebLogic Serverインスタンス

WebLogic Serverには、クラスタ内のサーバー・インスタンス数に関する制限はありません。したがって、Sun MicrosystemsのSun Enterprise 10000などの大規模マルチプロセッサ・サーバーを、大規模なクラスタまたは複数のクラスタのホストとすることができます。

CPUごとに1つのサーバーを起動し、予期される動作に基づいてスケール・アップすることをお薦めします。ただし、あらゆるキャパシティ・プランニングと同様、サーバー・インスタンスの最適数および分散方法を決定する場合は、ターゲットWebアプリケーションで実際のデプロイメントをテストする必要があります。追加情報は、『Oracle WebLogic Serverのパフォーマンスのチューニング』のマルチ・コア・マシン上で複数のサーバー・インスタンスの実行に関する項を参照してください。

ホスト・マシンのソケット・リーダー実装をチェックする

ソケットの最適なパフォーマンスを実現するには、pure-Java実装ではなく、オペレーティング・システムに対応したネイティブ・ソケット・リーダー実装を使用するようWebLogic Serverホスト・マシンを構成します。ネイティブ・ソケットを構成する、またはpure-Javaソケット通信を最適化する理由とその手順については、「IPソケットを使用したピア・ツー・ピア通信」を参照してください

切断されたWindowsマシン上のクラスタの設定

WebLogic Serverクラスタを単一の切断されたWindowsマシン上に置く場合は、WindowsにTCP/IPスタックをロードさせる必要があります。デフォルトでは、物理的なネットワーク接続が検出されない場合、WindowsはTCP/IPスタックをロードしません。

WindowsにTCP/IPスタックをロードさせるには、「How to disable Media Sensing for TCP/IP in Windows」(http://support.microsoft.com/default.aspx?scid=kb;en-us;239924)の指示に従ってWindowsのメディア・センス機能を無効にします。

名前とアドレスを識別する

クラスタの構成プロセスの間、クラスタ内のサーバー・インスタンスについてアドレス情報(IPアドレスまたはDNS名、およびポート番号)を指定します。

クラスタ内通信の概要と、クラスタ内通信を利用したロード・バランシングとフェイルオーバーの仕組みについては、「WebLogic Serverのクラスタ・メッセージング・プロトコルの選択」を参照してください

クラスタを設定するときは、次に関するロケーション情報を指定する必要があります。

- 管理サーバー

- 管理対象サーバー

- マルチキャスト・ロケーション

次の項では、指定しなければならない情報と、リソースの識別に用いる手法に影響する要因について説明しています。

リスニング・アドレスの問題を回避する

クラスタを構成するときには、アドレス情報をIPアドレスまたはDNS名を使用して指定できます。

DNS名とIPアドレス

DNS名とIPアドレスのどちらを使用するかを決定するときは、クラスタの目的を考慮してください。本番環境では一般に、DNS名を使用することをお薦めします。IPアドレスを使用すると、次の場合に変換エラーが発生する可能性があります。

- クライアントがファイアウォールを経由してクラスタに接続する、または

- プレゼンテーション層とオブジェクト層の間にファイアウォールを設けている - たとえば、推奨複数層クラスタの説明箇所で示しているように、サーブレット・クラスタとEJBクラスタの間にファイアウォールを置く場合。

変換エラーは、個別のサーバー・インスタンスのアドレスをDNS名にバインドすることによって回避できます。サーバー・インスタンスのDNS名が、ファイアウォールの両側で必ず一致するようにしてください。また、ネットワーク上のNTシステムの名前でもあるDNS名は使用しないでください。

IPアドレスの代わりにDNS名を使用する場合の注意事項については、「ファイアウォールについての考慮事項」 を参照してください

内部DNS名と外部DNS名が異なる場合

WebLogic Serverインスタンスの内部DNS名と外部DNS名が同じでない場合、サーバー・インスタンスのExternalDNSName属性を使用して、サーバーの外部DNS名を定義します。ファイアウォールの外で、ExternalDNSNameはサーバーの外部IPアドレスに変換されます。クライアントがデフォルト・チャネルとT3を介してWebLogic Serverにアクセスしている場合は、WebLogic Serverインスタンスの内部DNS名と外部DNS名が異なる場合でも、ExternalDNSName属性を設定しないでください。

localhostの考慮事項

サーバー・インスタンスのリスニング・アドレスをlocalhostとして識別すると、非ローカルのプロセスがそのサーバー・インスタンスに接続できなくなります。サーバー・インスタンスのホスト・マシン上のプロセスのみ、そのサーバー・インスタンスに接続できます。サーバー・インスタンスがlocalhostとしてアクセス可能である必要がある場合(たとえばlocalhostに接続する管理スクリプトがある場合)で、かつリモート・プロセスからもアクセス可能である必要がある場合は、リスニング・アドレスを空白にします。リスニング・アドレスを空白にすると、サーバー・インスタンスはマシンのアドレスを判別してそのアドレスでリスニングします。

WebLogic Serverリソースへの名前割当て

WebLogic Server環境の構成可能な各リソースには、一意の名前を割り当てる必要があります。ドメイン、サーバー、マシン、クラスタ、データ・ソース、仮想ホストなどのリソースには一意の名前が必要です。

管理サーバーのアドレスとポート

クラスタに対して使用する管理サーバーのDNS名またはIPアドレスおよびリスニング・ポートを識別します。

管理サーバーは、そのドメイン内のすべての管理対象サーバーを構成および管理するために使われるWebLogic Serverインスタンスです。管理対象サーバーを起動するときには、対応する管理サーバーのホストとポートを識別します。

管理対象サーバーのアドレスとリスニング・ポート

クラスタ用の各管理対象サーバーのDNS名とIPアドレスを識別します。

クラスタ内の各管理対象サーバーについて、アドレスとリスニング・ポート番号の組合せは固有であることが必要です。非マルチホーム環境の1台のマシン上でクラスタ化されるサーバー・インスタンスについては、インスタンス間でアドレスが重複してもかまいませんが、使用するリスニング・ポートはインスタンスごとに異なっている必要があります。

クラスタのマルチキャスト・アドレスとマルチキャスト・ポート

クラスタのマルチキャスト通信専用のアドレスとポートを識別します。マルチキャスト・アドレスは、224.0.0.0から239.255.255.255までの範囲のIPアドレスです。

注意:

WebLogic Serverで使用されるデフォルトのマルチキャスト・アドレスは、239.192.0.0です。x.0.0.1の値のマルチキャスト・アドレスを使用することはできません。

クラスタ内のサーバー・インスタンスは、マルチキャストを使用して互いに通信します。具体的には、マルチキャストを使用して各自のサービスを全体に通知し、インスタンスが継続的に使用可能であることを知らせるハートビートを一定間隔で発行します。

クラスタのマルチキャスト・アドレスは、クラスタ通信以外の目的には使用しないことをお薦めします。クラスタのマルチキャスト・アドレスが存在するマシンが、マルチキャスト通信を使用するクラスタ外部のプログラムのホストであるか、またはそのようなプログラムによってアクセスされる場合、そのマルチキャスト通信では必ず、クラスタのマルチキャスト・ポートとは異なるポートを使用してください。

マルチキャストと複数のクラスタ

ネットワーク上の複数のクラスタは、必要に応じてマルチキャスト・アドレスとマルチキャスト・ポートの組合せを共有できます。

マルチキャストと複数層クラスタ

「クラスタ・アーキテクチャ」で説明しているような、クラスタ間にファイアウォールを設ける推奨多層アーキテクチャを設定している場合、専用のマルチキャスト・アドレスが2つ必要になります。1つはプレゼンテーション(サーブレット)クラスタ用であり、もう1つはオブジェクト・クラスタ用です。2つのマルチキャスト・アドレスを使用することにより、ファイアウォールはクラスタの通信に干渉しなくなります。

クラスタ・アドレス

WebLogic Serverクラスタでは、クラスタ・アドレスは、リクエストURLのホスト名部分を構築するためにエンティティBeanおよびステートレスBeanで使用されます。

クラスタを構成するときに、クラスタ・アドレスを明示的に定義できます。定義しない場合、WebLogic Serverは新しいリクエストごとにクラスタ・アドレスを動的に生成します。WebLogic Serverによるクラスタ・アドレスの動的生成を有効にするほうが、システム管理上簡単であり、開発環境および本番環境の両方に適しています。

動的なクラスタ・アドレス

クラスタを構成するときにクラスタ・アドレスを明示的に定義しない場合は、クラスタ化サーバー・インスタンスがリモート・リクエストを受信するときに、WebLogic Serverは次の形式でクラスタ・アドレスを生成します。

listenaddress1:listenport1,listenaddress2:listenport2;listenaddress3:
listenport3

クラスタ・アドレス内の各listen address:listen portの組合せは、リクエストを受信した管理対象サーバーとネットワーク・チャネルに対応します。

- リクエストが管理対象サーバーのデフォルト・チャネルで受信された場合、クラスタ・アドレス内のlisten address:listen portの組合せには、関連付けられるServerMBeanおよびSSLMBeanインスタンスのListenAddress値とListenPort値が反映されます。詳細は、『Oracle WebLogic Serverサーバー環境の管理』のデフォルト・ネットワーク・チャネルに関する項を参照してください。

- リクエストがカスタム・ネットワーク・チャネルで受信された場合、クラスタ・アドレス内のlisten address:listen portには、そのチャネルを定義するNetworkAccessPointMBeanのListenAddress値とListenPort値が反映されます。クラスタ内のネットワーク・チャネルの詳細は、『Oracle WebLogic Serverサーバー環境の管理』のクラスタにおけるネットワーク・チャネルの構成に関する項を参照してください。

クラスタ・アドレスに含まれるListenAddress:ListenPortの組合せの数には、ClusterMBeanのNumberOfServersInClusterAddress属性の値(デフォルトは3)が適用されます。

NumberOfServersInClusterAddressの値は、WebLogic Server管理コンソールの「環境」→「クラスタ」→「Cluster@Name」→「構成」→「全般」ページで変更できます。

- クラスタ内で使用可能な管理対象サーバーの数がNumberOfServersInClusterAddressの値より少ない場合、動的に生成されるクラスタ・アドレスには実行中の各管理対象サーバーのListenAddress:ListenPortの組合せが含まれます。

- クラスタ内で使用可能な管理対象サーバーの数がNumberOfServersInClusterAddressの値より多い場合、WebLogic Serverは使用可能なインスタンスからNumberOfServersInClusterAddressの値と同数のインスタンスのサブセットを選択し、それらのインスタンスのListenAddress:ListenPortの組合せを使用してクラスタ・アドレスを生成します。

ListenAddress:ListenPortの組み合わせはランダムな順序でクラスタ・アドレスに表示され、リクエストごとにその順序は変わります。

本番環境でクラスタ・アドレスを明示的に定義する

本番環境でクラスタのクラスタ・アドレスを明示的に定義する場合は、クラスタ内の各WebLogic ServerインスタンスのIPアドレスまたはDNS名にマップするDNS名としてクラスタ・アドレスを指定します。

クラスタ・アドレスをDNS名として定義した場合、クラスタ・メンバーのリスニング・ポートは、クラスタ・アドレスで指定されません。クラスタ内の各管理対象サーバーが同じリスニング・ポート番号を持っていると見なされます。クラスタ内の各サーバー・インスタンスは固有のアドレスとリスニング・ポートの組合せを持つ必要があるため、クラスタ・アドレスがDNS名の場合、クラスタ内の各サーバー・インスタンスには次のものが必要です。

- 一意のアドレス

- 共通のリスニング・ポート番号

クライアントがクラスタDNS名を提供して初期JNDIコンテキストを取得すると、weblogic.jndi.WLInitialContextFactoryはそのDNS名にマップされているすべてのアドレスのリストを取得します。このリストはWebLogic Serverインスタンスによってキャッシュされ、新しい初期コンテキスト・リクエストは、キャッシュされているリスト内のアドレスをラウンドロビン・アルゴリズムで使うことによって実行されます。キャッシュされているリスト内のサーバー・インスタンスが使用できない場合、そのサーバーはリストから削除されます。アドレス・リストは、サーバー・インスタンスがキャッシュ内のどのアドレスにもアクセスできない場合にのみ、DNSサービスによってリフレッシュされます。

キャッシュされているアドレス・リストを使用すると、DNSラウンドロビンだけを利用する場合の問題を避けることができます。たとえば、DNSラウンドロビンでは、アドレスがアクセス可能かどうかに関わりなく、ドメイン名にマップされているすべてのアドレスが使用され続けます。アドレス・リストをキャッシュすると、WebLogic Serverはアクセス不能なアドレスを削除できるので、初期コンテキスト・リクエストで接続の失敗が繰り返されることはありません。

注意:

管理サーバーをクラスタに参加させないでください。必ず、管理サーバーのIPアドレスがクラスタ全体のDNS名に含まれないようにしてください。詳細は、「管理サーバーについての考慮事項」を参照してください

開発およびテスト環境でクラスタ・アドレスを明示的に定義する

開発環境で使用するクラスタ・アドレスを明示的に定義する場合は、前の項で説明したようにクラスタ・アドレスにクラスタDNS名を使用できます。

または、次の例で示すように、DNS名(またはIPアドレス)およびクラスタ内の各管理対象サーバーのリスニング・ポートを格納するリストとしてクラスタ・アドレスを定義することもできます。

DNSName1:port1,DNSName1:port2,DNSName1:port3
IPaddress1:port1,IPaddress2:port2;IPaddress3:port3

各クラスタ・メンバーは、一意のアドレスとポートの組み合わせを持っています。

単一のマルチホーム・マシンでクラスタ・アドレスを明示的に定義する

マルチホーム環境の1台のマシン上でクラスタが動作しており、クラスタ内の各サーバー・インスタンスで異なったIPアドレスを使用する場合、クラスタ内のサーバー・インスタンスのIPアドレスにマップするDNS名を使用してクラスタ・アドレスを定義します。クラスタ・アドレスをDNS名として定義する場合、クラスタ内の各管理対象サーバーで共通のリスニング・ポート番号を指定します。

クラスタ実装の手順

この項では、アプリケーションをクラスタ構成にして実行する手順を、WebLogic Serverのインストールからアプリケーション・コンポーネントの初期デプロイメントまで順を追って説明します。

構成のロードマップ

この項では、典型的なクラスタ実装のタスクをリストし、構成に関する重要な考慮事項を説明します。実際のプロセスは、環境ごとに一意の特性およびアプリケーションの性質によって決まります。これらのタスクが説明されています。

1. WebLogic Serverをインストールする

2. クラスタ化ドメインを作成する

3. ノード・マネージャを構成する

4. EJBとRMIのロード・バランシング方式を構成する

5. 分散JMS宛先のサーバー・アフィニティを構成する

6. パッシブなCookieの永続性をサポートするロード・バランサを構成する

7. プロキシ・プラグインを構成する

8. レプリケーション・グループを構成する

9. 固定サービスの移行可能ターゲットを構成する

10. デプロイメント用にアプリケーションをパッケージ化する

11. アプリケーションをデプロイする

12. 移行可能サービスをデプロイ、アクティブ化および移行する

13. インメモリーHTTPレプリケーションを構成する

14. 構成に関するその他のトピック

クラスタの実装によっては、一部の手順が不要である場合があります。また、ここで示す以外の手順が必要になる場合もあります。

WebLogic Serverをインストールする

まだインストールしていない場合は、WebLogic Serverをインストールします。手順については、『Oracle WebLogic ServerおよびCoherenceのインストールと構成』を参照してください。

- クラスタを1台のマシン上で実行する場合、/Oracleディレクトリの下に、クラスタ化されたすべてのインスタンスに使用される単一のWebLogic Serverをインストールします。

- ネットワーク上のリモート・マシンについては、各マシンに同じバージョンのWebLogic Serverをインストールします。各マシンは:

- 永続的に割り当てられる静的なIPアドレスを持つ必要があります。クラスタリング環境では、動的に割り当てられるIPアドレスは使用できません。

- クライアントからアクセス可能であることが必要です。サーバー・インスタンスとクライアントの間にファイアウォールがある場合、各サーバー・インスタンスには、クライアントから到達できるパブリックな静的IPアドレスを割り当てる必要があります。

- すべてのマシンが同じローカル・エリア・ネットワーク(LAN)上にあり、IPマルチキャストによって通信できることが必要です。

クラスタ化ドメインを作成する

クラスタ化ドメインの作成方法は複数あります。リストについては、「クラスタを構成する方法」を参照してください

クラスタの作成手順については、次を使用してください。

- 構成ウィザード。ドメインの作成手順は、『構成ウィザードによるWebLogicドメインの作成』のWebLogicドメインの作成に関する項を参照してください。クラスタの構成方法は、クラスタに関する項を参照してください。

- WebLogic Server管理コンソールの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのクラスタの作成と構成に関する項を参照してください。

WebLogic Serverクラスタを起動する

クラスタを起動するには複数の方法があります。コマンド行インタフェース、必要なコマンドを含むスクリプト、およびノード・マネージャなどを使用できます。

注意:

ノード・マネージャを使用すると、サーバーを起動したり、障害発生後にサーバーを再起動したりするプロセスが簡単になります。

ノード・マネージャを使用するには、最初に、クラスタ内の管理対象サーバーをホストする各マシンでノード・マネージャ・プロセスを構成する必要があります。「ノード・マネージャを構成する」を参照してください

どの方法を使用してクラスタを起動する場合でも、最初にクラスタ内の管理サーバーを起動し、次に管理対象サーバーを起動します。

次の手順に従って、コマンド・シェルからクラスタを起動します。各サーバー・インスタンスを別々のコマンド・シェルで起動することに注意してください。

1. コマンド・シェルを開きます。

2. 構成ウィザードで作成したドメイン・ディレクトリに移動します。

3. 次のコマンドを入力して管理サーバーを起動します。

StartWebLogic

4. 「WebLogic Serverを起動するためのユーザー名を入力してください」というプロンプトが表示されたら、ドメインのユーザー名を入力します。

5. 「WebLogic Serverを起動するためのパスワードを入力してください」というプロンプトが表示されたら、ドメインのパスワードを入力します。

起動プロセスのステータスを知らせるメッセージがコマンド・シェルに表示されます。

6. 管理対象サーバーを起動するために、別のコマンド・シェルを開きます。

7. 構成ウィザードで作成したドメイン・ディレクトリに移動します。

8. このコマンドを入力します

StartManagedWebLogic server_name address:port

説明:

server_nameは、起動する管理対象サーバーの名前です

addressは、ドメインの管理サーバーのIPアドレスまたはDNS名です

portは、ドメインの管理サーバーのリスニング・ポートです

9. 「WebLogic Serverを起動するためのユーザー名を入力してください」というプロンプトが表示されたら、ドメインのユーザー名を入力します。

10. 「WebLogic Serverを起動するためのパスワードを入力してください」というプロンプトが表示されたら、ドメインのパスワードを入力します。

起動プロセスのステータスを知らせるメッセージがコマンド・シェルに表示されます。

注意:

管理対象サーバーを起動すると、クラスタ内の他の実行中のサーバーからのハートビートがリスニングされます。管理対象サーバーは、クラスタ全体のJNDIツリーのローカル・コピーをビルドし(「WebLogic ServerによるJNDIツリーの更新方法」を参照)、クラスタ内の実行中の各管理対象サーバーと同期したら、ステータス・メッセージを表示します。同期化プロセスには1分ほどかかります。

11. クラスタ内の別のサーバー・インスタンスを起動するには、ステップ6に戻ります。ステップ10まで続けてください。

12. クラスタ内のすべての管理対象サーバーを起動したら、クラスタの起動プロセスは完了です。

ノード・マネージャを構成する

ノード・マネージャは、WebLogic Serverで提供されるスタンドアロンプログラムであり、管理サーバーとは別のマシンにある管理対象サーバーの起動に利用できます。また、ノード・マネージャには、クラスタ内の管理対象サーバーの可用性の向上に役立つ機能もあります。ノード・マネージャの詳細および構成方法と使用方法は、『Oracle WebLogic Serverノード・マネージャの管理』を参照してください。

EJBとRMIのロード・バランシング方式を構成する

この項の手順に従うと、EJBおよびRMIオブジェクトのロード・バランシング・アルゴリズムを選択できます。

他のものを明示的に指定しない場合、WebLogic Serverはクラスタ化されるオブジェクトのスタブに対して、デフォルトのロード・バランシング戦略であるラウンドロビン・アルゴリズムを使用します。それ以外のロード・バランシング方式については、「EJBとRMIオブジェクトのロード・バランシング」を参照してくださいデフォルトのロード・バランシング・アルゴリズムを変更するには:

1. WebLogic Server管理コンソールを起動します。

2. 「環境」>「クラスタ」の順に選択します。

3. 表でクラスタの名前を選択します。

4. クラスタの名前をすでに選択している場合は、コンソールの左上隅にある「ロックして編集」をクリックします。

5. 「デフォルトのロード・バランス・アルゴリズム」フィールドに、使用するロード・バランシング・アルゴリズムを入力します。

6. 「詳細」を選択します。

7. 「サービス期間しきい値」フィールドに任意の値を入力します。

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

9. 変更をアクティブ化するには、左上隅にある「変更のアクティブ化」をクリックします。

RMIのタイムアウト値を指定する

ClusterMBeanのReplicationTimeoutEnabledをtrueに設定することで、ReplicationManagerの呼出し時にタイムアウト・オプションを有効にできます。

タイムアウト値はマルチキャスト・ハートビートのタイムアウト値と同じです。マルチキャストのタイムアウト値はカスタマイズできますが、ReplicationManagerのタイムアウト値は変更できません。この制限があるのは、ReplicationManagerのタイムアウトはクラスタのメンバーシップに影響しないからです。マルチキャスト・ハートビートがなくなるとそのメンバーはクラスタから削除され、ReplicationManagerの呼出しがタイムアウトすると接続先の新しいセカンダリ・サーバーが選択されます。

注意:

クラスタ・メンバーはマルチキャスト・ハートビートを送信し続けることができますが、レプリケーション・リクエストは処理できません。そのため、セカンダリ・サーバーの分散が不均一になるおそれがあります。このような状態になると、警告メッセージがサーバー・ログに記録されます。

分散JMS宛先のサーバー・アフィニティを構成する

WebLogic Serverが提供するJMSのサーバー・アフィニティのサポートについては、「JMSのロード・バランシング」を参照してください

パッシブなCookieの永続性をサポートするロード・バランサを構成する

パッシブなCookieの永続性をサポートするロード・バランサは、セッションをホストするWebLogic Serverインスタンスをクライアントと関連付けるためにWebLogic ServerセッションCookieの情報を使用できます。セッションCookieには、ロード・バランサがセッションのプライマリ・サーバー・インスタンスを識別する文字列が含まれています。

外部ロード・バランサ、セッションCookieの永続性、およびWebLogic ServerセッションCookieの詳細は、「外部ロード・バランサによるHTTPセッションのロード・バランシング」を参照してください

クラスタで動作するようにロード・バランサを構成するには、ロード・バランサの機能を使用して、文字列定数のオフセットと長さを定義します。

セッションCookieのセッションID部分がデフォルト長の52バイトであると想定して、ロード・バランサで次を設定します。

- 文字列のオフセットは、ランダム・セッションID長に区切り文字用の1バイトを加えた53バイト

- 文字列の長さは10バイト

アプリケーションまたは環境によって、ランダム・セッションIDの長さをデフォルト値の52バイト以外に変更しなければならない場合は、それに応じて文字列のオフセットをロード・バランサで設定してください。文字列のオフセットは、セッションIDの長さに、区切り文字用の1バイトを加えたものと同じ値にする必要があります。

注意:

BIG-IPロード・バランサのベンダー固有の構成手順については、「クラスタに関するBIG-IPハードウェアの構成」を参照してください。

プロキシ・プラグインを構成する

プロキシ・プラグインを使用してサーブレットおよびJSPのロード・バランシングを行う場合は、この項で示す手順を参考にしてください。プロキシ・プラグインは、リクエストをWebサーバーからクラスタ内のWebLogic Serverインスタンスに中継し、プロキシを経由するHTTPリクエストのロード・バランシングとフェイルオーバーを可能にします。

プロキシ・プラグインによるロード・バランシングの詳細は、「プロキシ・プラグインによるロード・バランシング」を参照してくださいプロキシ・プラグインによる接続とフェイルオーバーの詳細は、サーブレットとJSPのレプリケーションとフェイルオーバーおよびクラスタ化されたサーブレットとJSPへのプロキシ経由のアクセスを参照してください

- WebサーバーとしてWebLogic Serverを使用する場合、「HttpClusterServletを設定する」の指示に従って、HttpClusterServletを設定します

- サポートされているサード・パーティ製Webサーバーを使用する場合、『Oracle WebLogic Serverプロキシ・プラグインの使用』の手順に従って、その製品に固有のプラグインを設定します(サポートされているWebサーバーの一覧については、「プロキシ・プラグインによるロード・バランシング」を参照)。

注意:

リクエストをクラスタにプロキシ経由で中継する各Webサーバーでは、プラグインが同じように構成されている必要があります。

HttpClusterServletを設定する

HTTPクラスタ・サーブレットを使用するには、次の手順で説明するように、プロキシ・サーバー・マシン上でサーブレットをデフォルトWebアプリケーションとして構成します。Webアプリケーションの詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のWebアプリケーション、サーブレット、およびJSPの理解に関する項を参照してください。

1. まだ構成していない場合は、独立したクラスタ化されていない管理対象サーバーを構成して、HTTPクラスタ・サーブレットをホストするようにします。

2. サーブレットのweb.xmlデプロイメント記述子ファイルを作成します。このファイルは、Webアプリケーション・ディレクトリの\WEB-INFサブディレクトリに配置する必要があります。プロキシ・サーブレットのサンプルのデプロイメント記述子は、「サンプルのweb.xml」に示しますweb.xmlの詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のWebアプリケーション、サーブレット、およびJSPに関する項を参照してください。

a. web.xmlの<servlet>要素で、サーブレットの名前とクラスを定義します。サーブレット名はHttpClusterServletです。サーブレット・クラスはweblogic.servlet.proxy.HttpClusterServletです。

b. web.xmlの<servlet>要素で、WebLogicClusterパラメータを定義して、プロキシ・サーブレットのリクエストの転送先となる、クラスタ化サーバー・インスタンスを指定します。

c. 独自のID証明書とキーで双方向SSLを使用する場合は、必要に応じて次の<KeyStore>初期化パラメータを定義します。デプロイメント記述子に<KeyStore>が指定されていない場合、プロキシでは一方向SSLと見なされます。

- <KeyStore> - Webアプリケーションのキーストアの場所。

- <KeyStoreType> - キーストアのタイプ。定義されていない場合、デフォルトのタイプが使用されます。

- <PrivateKeyAlias> - 秘密鍵の別名。

- <KeyStorePasswordProperties> - Webアプリケーション内のプロパティ・ファイル。キーストアおよび秘密鍵の別名にアクセスするための暗号化されたパスワードを定義します。このファイルは次のような内容を持ちます。

KeyStorePassword={AES}yWv/i0qhfM4/IvzoghzjHj/xpJUkQPF8OWuSfh0f0Ss=
PrivateKeyPassword={AES}wr86u9Z5DHr+5p7WIbzTDSy4M/sl7EYnX/K5xzcarDQ=

パスワードを暗号化するためにweblogic.security.Encryptコマンド行ユーティリティを使用する必要があります。EncryptユーティリティおよびCertGenとder2pemユーティリティの詳細は、『Oracle WebLogic Serverコマンド・リファレンス』のWebLogic Server Javaユーティリティの使用に関する項を参照してください。

d. <servlet-mapping>スタンザを作成して、サーブレットがクラスタにプロキシするリクエストを指定します。<url-pattern>要素を使用して特定のファイル拡張子(*.jspまたは*.htmlなど)を指定します。パターンごとに別々の<servlet-mapping>スタンザに定義します。
<url-pattern>を「/」に設定すると、WebLogic Serverによって解決できないリクエストをリモート・サーバー・インスタンスにプロキシできます。その場合、拡張子が*.jsp、*.htm、および*.htmlのファイルをプロキシするために、これらの拡張子もマップしなければなりません。例については、「サンプルのweb.xml」を参照してください

e. WLProxyPassThrough属性を有効化すると、一連のプロキシおよびWLProxySSLPassThrough属性を介してヘッダーを渡すことが可能になるため、SSLの使用がWebLogic Serverに渡されます。これらの属性の詳細は、『Oracle WebLogic Serverプロキシ・プラグインの使用』のWeb Serverプラグインのための汎用パラメータに関する項を参照してください。

f. 必要に応じて、追加のパラメータを定義します。主なパラメータのリストについては、表10-1を参照してください。完全なリストについては、『Oracle WebLogic Serverプロキシ・プラグインの使用』のWebサーバー・プラグインのパラメータに関する項を参照してください。「プロキシ・サーブレットのデプロイメント・パラメータ」の構文の指示に従ってください

3. サーブレットのweblogic.xmlデプロイメント記述子ファイルを作成します。このファイルは、Webアプリケーション・ディレクトリの\WEB-INFサブディレクトリに配置する必要があります。
<weblogic-web-app>スタンザの<context-root>要素をフォワード・スラッシュ文字(/)に設定して、プロキシ・サーブレットをプロキシ・マシンにある管理対象サーバーのデフォルトWebアプリケーションとして割り当てます。例については、「サンプルのweblogic.xml」を参照してください

4. WebLogic Server管理コンソールで、プロキシ・サーバー・マシン上の管理対象サーバーにサーブレットをデプロイします。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのアプリケーションおよびモジュールのデプロイに関する項を参照してください。

サンプルのweb.xml

この項ではHttpClusterServletのサンプルのデプロイメント記述子ファイル(web.xml)を示します。

web.xmlでは、プロキシ・サーブレットの位置と動作を指定する様々なパラメータを定義します。

- DOCTYPEスタンザは、web.xmlの有効性を検証するためにWebLogic Serverで使用されるDTDを指定します。

- servletスタンザは:

- プロキシ・プラグイン・サーブレット・クラスの場所を指定します。ファイルは、WL_HOME/server/libディレクトリのweblogic.jarにあります。WebLogic Serverの起動時にweblogic.jarがCLASSPATHに配置されるため、web.xmlではサーブレットのフル・ディレクトリ・パスを指定する必要はありません。

- WebLogicClusterパラメータを使用して、クラスタ内の各管理対象サーバーのホスト名(DNS名またはIPアドレス)とリスニング・ポートを識別します。

- 独自のID証明書とキーで双方向SSLを使用するためのキーストア初期化パラメータを識別します。

- 4つのservlet-mappingスタンザは、サーブレットが「/」、「htm」、「html」、または「jsp」で終わるURLをクラスタにプロキシすることを指定します。

パラメータの定義については、「プロキシ・サーブレットのデプロイメント・パラメータ」を参照してください

<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd";>

<web-app>
<servlet>
<servlet-name>HttpClusterServlet</servlet-name>
<servlet-class>
weblogic.servlet.proxy.HttpClusterServlet
</servlet-class>
<init-param>
<param-name>WebLogicCluster</param-name>
<param-value>hostname1:7736|hostname2:7736|hostname:7736</param-value>
</init-param>
<init-param>
<param-name>KeyStore</param-name>
<param-value>/mykeystore</param-value>
</init-param>
<init-param>
<param-name>KeyStoreType</param-name>
<param-value>jks</param-value>
</init-param>
<init-param>
<param-name>PrivateKeyAlias</param-name>
<param-value>passalias</param-value>
</init-param>
<init-param>
<param-name>KeyStorePasswordProperties</param-name>
<param-value>mykeystore.properties</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>HttpClusterServlet</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>HttpClusterServlet</servlet-name>
<url-pattern>*.jsp</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>HttpClusterServlet</servlet-name>
<url-pattern>*.htm</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>HttpClusterServlet</servlet-name>
<url-pattern>*.html</url-pattern>
</servlet-mapping>
</web-app>

サンプルのweblogic.xml

この項ではサンプルのweblogic.xmlファイルを示します。<context-root>デプロイメント・パラメータは「/」に設定されています。この設定により、プロキシ・サーブレットがプロキシ・サーバーのデフォルトWebアプリケーションになります。

<!DOCTYPE weblogic-web-app PUBLIC "-//BEA Systems, Inc.//DTD Web Application 9.1//EN" "http://www.bea.com/servers/wls810/dtd/weblogic
810-web-jar.dtd">
<weblogic-web-app>
<context-root>/</context-root>
</weblogic-web-app>

プロキシ・サーブレットのデプロイメント・パラメータ

web.xmlでプロキシ・サーブレットの動作を構成するための主なパラメータを開始する前にに示します。

プロキシ・サーブレットのパラメータは、Apache、MicrosoftおよびNetscape Webサーバー用のWebLogic Serverプラグインの構成に使用するパラメータと同じです。プロキシ・サーブレットおよびサード・パーティ製Webサーバーのプラグインを構成するパラメータの詳細なリストは、『Oracle WebLogic Serverプロキシ・プラグインの使用』のWebサーバー・プラグインのパラメータに関する項を参照してください。

パラメータを指定する際の構文と指定先のファイルは、プロキシ・サーブレットとプラグインごとに異なります。

プロキシ・サーブレットの場合、web.xmlでパラメータを指定します。パラメータごとに、web.xmlの<servlet>スタンザ内の<init-param>スタンザで指定します。次に例を示します。

<init-param>
<param-name>ParameterName</param-name>
<param-value>ParameterValue</param-value>
</init-param>

表10-1 プロキシ・サーブレットのデプロイメント・パラメータ

パラメータ

使用方法

WebLogicCluster

<init-param>
<param-name>WebLogicCluster</param-name>
<param-value>WLS1.com:port|WLS2.com:port
</param-value>

この場合、WLS1.comとWLS2.comはクラスタ内のサーバーのホスト名で、portはホストがHTTPリクエストをリスニングするポートです。

プラグインとWebLogic Serverの間でSSLを使用している場合は、ポート番号をSSLリスニング・ポートに設定して(「リスニング・ポートの構成」を参照)、SecureProxyパラメータを「ON」に設定します。

SecureProxy

<init-param>
<param-name>SecureProxy</param-name>
<param-value>ParameterValue</param-value>
</init-param>

有効な値はONおよびOFFです。

プラグインとWebLogic Serverの間でSSLを使用している場合は、ポート番号をSSLリスニング・ポートに設定して(「リスニング・ポートの構成」を参照)、SecureProxyパラメータを「ON」に設定します。

DebugConfigInfo

<init-param>
<param-name>DebugConfigInfo</param-name>
<param-value>ParameterValue</param-value>
</init-param>

有効な値はONおよびOFFです。

ONに設定する場合、任意のリクエストに?__WebLogicBridgeConfigというリクエスト・パラメータを追加して、HttpClusterServletにデバッグ情報を問い合わせることができます。(注意: ?の後は2つのアンダースコ( _ )文字です。)セキュリティ上の理由により、本番環境ではDebugConfigInfoパラメータをOFFに設定することをお薦めします。

ConnectRetrySecs

サーバー・インスタンスへの接続試行の間に、サーブレットがスリープする間隔(秒単位)。ConnectTimeoutSecsより小さい値を割り当てます。

HTTP 503/Service Unavailableレスポンスがクライアントに返されるまでにサーブレットが接続を試行する回数は、ConnectTimeoutSecsをConnectRetrySecsで除算した数です。

構文:

<init-param>
<param-name>ConnectRetrySecs</param-name>
<param-value>ParameterValue</param-value>
</init-param>

ConnectTimeoutSecs

サーブレットがサーバー・インスタンスへの接続を試行する最大時間(秒単位)。ConnectRetrySecsより大きい値を割り当てます。

接続が成功する前にConnectTimeoutSecsが経過した場合は、HTTP 503/Service Unavailableレスポンスがクライアントに送信されます。

構文:

<init-param>
<param-name>ConnectTimeoutSecs</param-name>
<param-value>ParameterValue</param-value>
</init-param>

PathTrim

リクエストがクラスタに転送される前に、元のURLの先頭からプラグインによって取り除かれる文字列。

構文:

<init-param>
<param-name>PathTrim</param-name>
<param-value>ParameterValue</param-value>
</init-param>

例:

URL

http://myWeb.server.com/weblogic/foo

が解析用にプラグインに渡され、PathTrimが次の値に設定される場合

/weblogic

WebLogic Serverに転送されるURLは次のとおりです。

http://myWeb.server.com:7001/foo

TrimExt

URLの末尾から取り除かれるファイル拡張子。

構文:

<init-param>
<param-name>TrimExt</param-name>
<param-value>ParameterValue</param-value>
</init-param>

clientCertProxy

クライアント証明書を信頼するために、WL-Proxy-Client-Certヘッダーで指定します。

有効な値はtrueおよびfalseです。デフォルト値はfalseです。

この設定は、ユーザー認証がプロキシ・サーバーで実行される場合に役立ちます。clientCertProxyをtrueに設定すると、プロキシ・サーバーはWL-Proxy-Client-Certという特別なヘッダーでクラスタに証明書を渡します。

WL-Proxy-Client-Certヘッダーは、WebLogic Serverに直接アクセス可能なクライアントで使用できます。WebLogic Serverは、安全なソース(プラグイン)からのものであることを信用してヘッダーの証明書情報を受け取り、その情報を使用してユーザーを認証します。

そのため、clientCertProxyをtrueに設定する場合は、接続フィルタを使用してWebLogic Serverがプラグインが実行されているマシンからの接続のみを受信するようにします。『WebLogicセキュリティ・サービスによるアプリケーションの開発』のネットワーク接続フィルタの使用を参照してください。

PathPrepend

PathTrimが取り除かれた後、URLがクラスタに転送される前に、元のURLの先頭にサーブレットが付加する文字列。

<init-param>
<param-name>PathPrepend</param-name>
<param-value>ParameterValue</param-value>
</init-param>

RoutingHandlerClassName

Webサービスのクラスタ・ルーティングをサポートするようプロキシ・サーブレットを拡張します。詳細は、『Oracle WebLogic Server JAX-WS Webサービスの開発』のクラスタのWebサービスの管理に関する項を参照してください。

<init-param>
<param-name>RoutingHandlerClassName</param-name>
<param-value>
weblogic.wsee.jaxws.cluster.proxy.SOAPRoutingHandler
</param-value>
</init-param>

プロキシ・サーバー経由のアプリケーションへのアクセス

クライアントがプロキシ・サーバー経由でアクセスするアプリケーションを、クラスタにデプロイします。クライアント・リクエストの送信先として、プロキシ・サーバーのリスニング・アドレスおよびリスニング・ポートを指定します。

問題がある場合は:

- すべてのサーバー・インスタンスが一意のアドレスとポートの組み合わせになっているかどうかを確認します
構成内の各サーバー・インスタンスは、リスニング・アドレスとリスニング・ポートの組合せが固有である必要があります。

- プロキシ・サーブレットがプロキシ・サーバーのデフォルト・アプリケーションになっていることを確認します
アプリケーションにアクセスしようとして「ページが見つからない」エラーが発生した場合は、weblogic.xmlがアプリケーションの\WEB-INFにあり、context-rootデプロイメント・パラメータが「/」に設定されていることを確認してください。

- 解決しない場合は再起動します
問題がある場合は、すべてのサーバーを再起動してみてください。構成時に行った変更の一部が構成ファイルに保持されていない可能性があります。

- 構成を確認します
HttpClusterServletの構成を確認するには:

1. web.xmlでDebugConfigInfoパラメータをONに設定します。

2. Webブラウザを使用して、次のURLにアクセスします。

http://myServer:port/placeholder.jsp?__WebLogicBridgeConfig

説明:

myServerはHttpClusterServletが動作するプロキシ・マシン上の管理対象サーバーです。portは、HTTPリクエストをリスニングしているサーバー上のポート番号です。placeholder.jspは、サーバー上に存在しないファイルです。

プラグインは構成情報と実行時統計を収集して、その情報をブラウザに返します。詳細は、『Oracle WebLogic Serverプロキシ・プラグインの使用』のWebサーバー・プラグインのパラメータに関する項を参照してください。

レプリケーション・グループを構成する

WebLogic Serverでは、HTTPセッション状態をメモリー内にレプリケートすることによって、サーブレットおよびJSPの自動フェイルオーバーを行います。それ以外にも、レプリケーション・グループを使用することにより、セカンダリ状態が置かれる場所を独自に制御することができます。レプリケーション・グループは、セッション状態のレプリカの格納先として使用する、クラスタ内のサーバー・インスタンスの優先順を定義するリストです。

クラスタがサーブレットまたはステートフル・セッションEJBのホストになる場合は、WebLogic Serverインスタンスのレプリケーション・グループを作成して、セッション状態のレプリカのホストにすることができます。

各レプリケーション・グループに参加させるサーバー・インスタンスと、各サーバー・インスタンスの優先レプリケーション・グループを決定する手順については、「レプリケーション・グループの使用」を参照してください

次に、個々のWebLogic Serverインスタンスについて、次の手順に従ってレプリケーション・グループを構成します。

WebLogic Serverインスタンスのレプリケーション・グループを構成するには:

1. WebLogic Server管理コンソールを起動します。

2. 「環境」、「サーバー」の順に選択します。

3. 表で、構成するサーバーの名前を選択します。

4. 「クラスタ」ページを選択します。

5. クラスタの名前をすでに選択している場合は、コンソールの左上隅にある「ロックして編集」をクリックします。

6. 次の属性フィールドに値を入力します。

- レプリケーション・グループ: このサーバー・インスタンスが属するレプリケーション・グループ名を入力します。

- セカンダリ・プリファレンス・グループ: このサーバー・インスタンスを、レプリケートされたHTTPセッション状態のホストにする場合に使用するレプリケーション・グループ名を入力します。

7. 「保存」をクリックして変更を保存します。

8. 左上隅にある「変更のアクティブ化」をクリックして、変更をアクティブ化します。

固定サービスの移行可能ターゲットを構成する

WebLogic Serverでは、必要に応じて移行可能ターゲットを構成できます。移行可能ターゲットとは、クラスタ内のサーバーから別のサーバーに移行できる特別なターゲットです。つまり、移行可能ターゲットを使用することで、一緒に移行する必要のある固定サービスをグループ化できます。移行可能ターゲットを移行すると、そのターゲットによってホストされているすべてのサービスが移行されます。固定サービスには、JMS関連サービス(JMSサーバー、SAFエージェント、パス・サービス、永続ストアなど)、とJTAトランザクション・リカバリ・サービスが含まれます。

移行可能ターゲットを使用する場合、クラスタ内でサービスをデプロイまたはアクティブ化する前に、ターゲット・サーバー・リストを構成します。クラスタ内に移行可能ターゲットを構成しない場合、移行可能サービスは、クラスタ内で使用可能などのWebLogic Serverインスタンスにでも移行できます。移行可能ターゲットの詳細は、「クラスタ内の移行可能ターゲットの理解」を参照してください

デプロイメント用にアプリケーションをパッケージ化する

WebLogic Serverにデプロイする前にアプリケーションをパッケージ化する必要があります。詳細は、『Oracle WebLogic Serverアプリケーションの開発』の分割開発ディレクトリからのデプロイとパッケージ化に関する項にあるパッケージ化に関するトピックを参照してください。

アプリケーションをデプロイする

WebLogic Serverでクラスタリングするオブジェクトは、均一にデプロイすることをお薦めします。均一なデプロイメントが確実に行われるようにするには、ターゲットを選択するときに、クラスタ内の個別のWebLogic Serverインスタンスではなくクラスタ名を使用します。クラスタが動的または混在クラスタ・タイプの場合、クラスタ全体で1つのインスタンスが必要か、クラスタ・メンバーごとに1つのインスタンスが必要かに基づき、シングルトン・デプロイメントまたは分散デプロイメントを選択できます。

コンソールでは、レプリカ対応オブジェクトのクラスタへのデプロイが自動化されます。クラスタにアプリケーションまたはオブジェクトをデプロイすると、コンソールでは、それらがクラスタのすべてのメンバー(管理サーバーのローカル・メンバーとリモート・マシンにあるメンバーの両方)に自動的にデプロイされます。クラスタリング環境でのアプリケーションのデプロイメントの詳細は、「クラスタの構成方法」を参照してくださいデプロイメントに関する全般的なトピックは、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。

注意:

WebLogic Server管理コンソールを使用してアプリケーションをクラスタにデプロイするときは、クラスタ内のすべてのサーバー・インスタンスを動作させておく必要があります。

1つのサーバー・インスタンスにデプロイする(固定デプロイメント)

クラスタのすべてのメンバーでなく、1つのサーバー・インスタンスにアプリケーションをデプロイする形態を固定デプロイメントと呼びます。固定デプロイメントでは特定のサーバー・インスタンスがターゲットとなりますが、デプロイメント・プロセスの間は、クラスタ内のすべてのサーバー・インスタンスが動作していなければなりません。

固定デプロイメントは、管理コンソールから実行することも、weblogic.Deployerを使用してコマンド行から実行することもできます。

コマンド行からの固定デプロイメント

コマンド・シェルから、次の構文を使用してサーバー・インスタンスをターゲット指定します。

java weblogic.Deployer -activate -name ArchivedEarJar -source C:/MyApps/JarEar.ear -target server1

クラスタのデプロイメントを取り消す

デプロイメントは、WebLogic Server管理コンソールを使用して取り消すか、weblogic.Deployerを使用してコマンド行から取り消すことができます。

コマンド行からデプロイメントを取り消す

コマンド・シェルから、次の構文を使用してデプロイメント・タスクIDを取り消します。

java weblogic.Deployer -adminurl http://admin:7001 -cancel -id tag

WebLogic Server管理コンソールを使用したデプロイメントの取消し

WebLogic Server管理コンソールで「タスク」ノードを開き、現在のデプロイメント・タスクを表示して取り消します。

デプロイ済アプリケーションを表示する

デプロイ済のアプリケーションをWebLogic Server管理コンソールで表示するには:

1. WebLogic Server管理コンソールで、「デプロイメント」を選択します。

2. 表にデプロイ済アプリケーションのリストを表示します。

デプロイ済アプリケーションをアンデプロイする

デプロイ済のアプリケーションをWebLogic Server管理コンソールからアンデプロイするには:

1. WebLogic Server管理コンソールで、「デプロイメント」を選択します。

2. 表では、アンデプロイするアプリケーションの左にあるチェック・ボックスを選択します。

3. クラスタの名前をすでに選択している場合は、コンソールの左上隅にある「ロックして編集」をクリックします。

4. 「停止」をクリックします。

5. アプリケーションを停止(アンデプロイ)する時期を選択します。

6. 「はい」をクリックします。

7. コンソールの左上隅にある「変更のアクティブ化」をクリックして、変更をアクティブ化します。

移行可能サービスをデプロイ、アクティブ化、および移行する

次の項では、移行可能サービスをデプロイ、アクティブ化、および移行するためのガイドラインと手順を示します。

移行可能ターゲット・サーバー・インスタンスにJMSをデプロイする

ここで作成する移行可能ターゲットは、移行可能サービスのホストとなることができるクラスタ内のサーバー・インスタンスのスコープを定義します。後からターゲット・サーバー・リストの内部でサービスを移行するためには、移行可能ターゲットとして登録されているいずれかのサーバー・インスタンス上で固定サービスをデプロイまたはアクティブ化する必要があります。次の手順に従って移行可能ターゲット上にJMSサービスをデプロイするか、後から移行できるようにJTAトランザクション・リカバリ・システムをアクティブ化します。

注意:

移行可能ターゲットを構成していない場合は、単純にJMSサーバーをクラスタ内の任意のWebLogic Serverインスタンスにデプロイします。その後、クラスタ内の任意の別サーバー・インスタンスにJMSサーバーを移行できます(移行可能ターゲットは使用しません)。

はじめに、「固定サービス用の移行可能ターゲットを構成する」の指示に従って、クラスタの移行可能ターゲットを作成します。次に、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次のトピックの説明に従って、JMS関連サービスを移行可能ターゲットにデプロイします。

- JMSサーバー・ターゲットの変更

- SAFエージェント・ターゲットの変更

- パス・サービス・ターゲットの変更

- ファイル・ストアの作成およびJDBCストアの作成

移行可能サービスとしてJTAをアクティブ化する

JTAリカバリ・サービスは、クラスタの移行可能ターゲットとして登録されているいずれかのサーバー・インスタンス上で自動的に起動されます。選択したサーバー・インスタンスにサービスをデプロイする必要はありません。

JTA移行可能ターゲットを構成しない場合、WebLogic Serverはクラスタ内で使用可能な任意のWebLogic Serverインスタンス上でサービスをアクティブ化します。JTAサービスのホストである現在のサーバー・インスタンスを変更するには、「ターゲット・サーバー・インスタンスに固定サービスを移行する」で示されている手順に従います

ターゲット・サーバー・インスタンスに固定サービスを移行する

移行可能サービスをデプロイした後で、WebLogic Server管理コンソールを使用して、サービスを手動でクラスタ内の別のサーバー・インスタンスに移行できます。サービスに対して移行可能ターゲットが構成されている場合、移行可能ターゲットとして登録されているサーバー・インスタンスであれば、動作していない場合でもそのサーバー・インスタンスにサービスを移行することができます。移行可能ターゲットを構成しない場合、クラスタ内のその他の任意のサーバー・インスタンスにサービスを移行できます。

停止しているサーバー・インスタンスにサービスを移行する場合、そのサーバー・インスタンスは次回の起動時に直ちにサービスをアクティブ化します。動作中のWebLogic Serverインスタンスにサービスを移行する場合、移行は直ちに有効になります。

はじめに、「移行可能ターゲット・サーバー・インスタンスにJMSをデプロイする」の指示に従って、固定サービスをクラスタにデプロイします。次に、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの該当する指示に従って、WebLogic Server管理コンソールを使用して固定サービスを移行します。

- JMS関連サービスの手動移行

- トランザクション・リカバリ・サービスの手動移行

コンソール・ヘルプでは説明されていない追加手順を次に示します。

1. 現在のサーバーに管理サーバーからアクセスできない場合は、WebLogic Server管理コンソールに次のメッセージが表示されます。

Unable to contact server MyServer-1, the source server from which services are being migrated.
Please ensure that server MyServer-1 is NOT running! If the administration
server cannot reach server MyServer-1 due to a network partition, inspect the
server directly to verify that it is not running. Continue the migration only
if MyServer-1 is not running. Cancel the migration if MyServer-1 is running,
or if you do not know whether it is running.

このメッセージが表示される場合は、「現在アクティブなホストがない場合の移行」の手順を行ってください

2. 宛先サーバーが停止している場合は、WebLogic Server管理コンソールがその停止しているサーバー・インスタンスを通知し、移行を続行するかどうか尋ねます。停止しているサーバー・インスタンスへの移行を続けるには「続行」を、移行を中止して別のサーバー・インスタンスを選択するには「取消し」をそれぞれクリックします。

3. サーバー・インスタンスの構成によっては、移行プロセスを完了するまでに数分以上かかる場合があります。ただし、移行を実行しながら、WebLogic Server管理コンソールで他の作業を続けることができます。後から移行のステータスを確認するには、左ペインで「タスク」ノードをクリックし、ターゲット・ドメインに対して実行中であるタスクを表示します。次に、移行タスクの説明を選択して、現在の状況を表示します。

現在アクティブなホストがない場合の移行

移行可能サービスのアクティブ・サーバーだったクラスタ化されている管理対象サーバーがクラッシュしたか、アクセス不能になった場合は、この移行手順を使用します。

この手順では、障害の発生した管理対象サーバーの構成キャッシュをパージします。キャッシュをパージする目的は、障害の発生したサーバー・インスタンスが再び利用可能になったときに、別の管理対象サーバーに移行したサービスが再デプロイされないようにすることです。キャッシュをパージすると、サービスのアクティブなホストだった管理対象サーバーが再び起動したときに、そのサーバーによってローカルの古い構成データが使用されるリスクがなくなります。

1. マシンのネットワークとの接続を完全に切断します。管理サーバーやクライアント・トラフィックからアクセスできないようにする必要があります。マシンにデュアル・ポート・ディスクがある場合は、それを切断します。

2. 移行可能なサービスを別のマシン上の管理対象サーバー・インスタンスに移行します。管理サーバーは動作している必要があります。動作していれば、移行を調整し、アクティブ化表を更新できます。

- 移行にコマンド行を使用する場合は、-sourcedownフラグを使用します。

- コンソールを使用する場合は、ソース・サーバーが再起動しないよう確認する必要があります。

この時点で、移行可能サービスは別のマシンの別の管理対象サーバーで利用可能になっています。次の手順は、時間があるときに行ってください。

3. 障害の発生したマシンで必要な修理または保守を行います。

4. マシンを再起動します。ただし、ネットワークへの接続は行いません。

ノード・マネージャがサービスまたはデーモンとして起動し、マシン上の管理対象サーバーを起動しようとします。

- 管理対象サーバーの独立が有効な場合、管理対象サーバーは管理サーバーに接続できなくても起動します。

- 管理対象サーバーの独立が無効な場合、管理対象サーバーは管理サーバーに接続できないため起動しません。

5. マシンをネットワークおよび共有ストレージ(デュアル・ポート・ディスクなど)に再接続します。

6. ノード・マネージャ・デーモン/サービスを再起動するか、マシンを再起動して、残りのすべての管理対象サーバーを起動します。

7. 無効にした管理対象サーバーを起動します。これは、ノード・マネージャによって実行される再起動ではなく通常の起動です。管理サーバーは動作していて、アクセス可能である必要があります。管理サーバーがその状態であれば、管理対象サーバーは管理サーバー上にある移行可能サービスのアクティブ化表と同期をとって、それが現在は移行可能サービスのアクティブなホストでないことを認識できます。

インメモリーHTTPレプリケーションを構成する

WebLogic Serverでは、HTTPセッション状態をメモリー内にレプリケートすることによって、サーブレットおよびJSPの自動フェイルオーバーを行います。

注意:

WebLogic Serverでは、ファイル・ベースまたはJDBCベースの永続性メカニズムを利用して、サーブレットまたはJSPのHTTPセッション状態を保持することもできます。それぞれの永続性メカニズムの詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のセッションとセッション永続性の使用を参照してください。

インメモリーでのHTTPセッション状態レプリケーションは、デプロイするアプリケーションごとに個別に制御されます。レプリケーションを制御するパラメータ(PersistentStoreType)は、ターゲット・アプリケーションのWebLogicデプロイメント記述子ファイルであるweblogic.xmlのsession-descriptor要素の内部にあります。

domain_directory/applications/application_directory/WEB-INF/weblogic.xml

クラスタ内のサーバー・インスタンス間でインメモリーでのHTTPセッション状態レプリケーションを使用するには、PersistentStoreTypeをreplicatedに設定します。次に示すのは、weblogic.xmlでの適切な設定例です。

<session-descriptor>
<persistent-store-type>replicated</persistent-store-type>
</session-descriptor>

構成に関するその他のトピック

次の項では、クラスタの特殊な構成を行うときに役に立つヒントを示します。

IPソケットを構成する

最適なパフォーマンスを得るために、WebLogic Serverインスタンスのホストであるマシン上では、pure-Java実装ではなくネイティブのソケット・リーダー実装を使用することをお薦めします。

ホスト・マシンでpure-Javaソケット・リーダー実装を使用しなければならない場合でも、サーバー・インスタンスおよびクライアント・マシンごとにソケット・リーダー・スレッドの数を適切に構成することによって、ソケット通信のパフォーマンスを向上させることができます。

- クラスタ内でのIPソケットの使用方法と、ネイティブ・ソケット・リーダー・スレッドが最適なパフォーマンスをもたらす理由については、「IPソケットを使用したピア・ツー・ピア通信」および「ソケット経由のクライアント通信」を参照してください。

- クラスタで必要なソケット・リーダー・スレッドの数を決定する方法については、「ソケットの使用数を確定する」を参照してください複数層クラスタ・アーキテクチャにサーブレット・クラスタをデプロイしている場合、「複数層アーキテクチャの構成に関する考慮事項」で説明しているように、これは必要なソケットの数に影響します

次の項では、ホスト・マシンに対してネイティブ・ソケット・リーダー・スレッドを構成する方法と、ホストおよびクライアント・マシンに対してリーダー・スレッドの数を設定する方法について説明します。

サーバー・インスタンスのホスト・マシン上でネイティブのIPソケット・リーダーを構成する

ネイティブのソケット・リーダー・スレッド実装を使用するようにWebLogic Serverインスタンスを構成するには:

1. WebLogic Server管理コンソールを起動します。

2. 「環境」、「サーバー」の順に選択します。

3. 構成するサーバー・インスタンスの名前を選択します。

4. クラスタの名前をすでに選択している場合は、コンソールの左上隅にある「ロックして編集」をクリックします。

5. 「構成」、「チューニング」の順に選択します。

6. 「ネイティブIOの有効化」チェック・ボックスを選択します。

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

8. コンソールの左上隅にある「変更のアクティブ化」をクリックして、変更をアクティブ化します。

サーバー・インスタンスのホスト・マシン上のリーダー・スレッドの数を設定する

デフォルトでは、WebLogic Serverインスタンスは起動時に3つのソケット・リーダー・スレッドを作成します。クラスタ・システムがピーク時に4つ以上のソケットを使用する可能性がある場合は、ソケット・リーダー・スレッド数を増やします。

1. WebLogic Server管理コンソールを起動します。

2. 「環境」、「サーバー」の順に選択します。

3. 構成するサーバー・インスタンスの名前を選択します。

4. クラスタの名前をすでに選択している場合は、コンソールの左上隅にある「ロックして編集」をクリックします。

5. 「構成」、「チューニング」の順に選択します。

6. 「ソケット・リーダー」フィールドでJavaリーダー・スレッドの割合を編集します。Javaソケット・リーダーの数が、合計実行スレッド数(「実行スレッド」フィールドに表示)の割合として計算されます。

7. 「保存」をクリックして変更を保存します。

8. コンソールの左上隅にある「変更のアクティブ化」をクリックして、変更をアクティブ化します。

クライアント・マシン上のリーダー・スレッド数を設定する

クライアント・マシン上では、クライアントを実行するJava仮想マシン(JVM)内でソケット・リーダーの数を構成できます。クライアントのJavaコマンド行で-Dweblogic.ThreadPoolSize=valueオプションおよび-Dweblogic.ThreadPoolPercentSocketReaders=valueオプションを定義してソケット・リーダーを指定します。

マルチキャスト存続時間(TTL)を構成する

クラスタがWAN内の複数のサブネットにまたがっている場合、マルチキャスト・パケットが最終の宛先に到達する前にルーターがパケットを破棄しないように、クラスタのマルチキャスト存続時間(TTL)パラメータの値を十分に大きく設定する必要があります。マルチキャスト存続時間パラメータには、パケットが破棄されるまでにマルチキャスト・メッセージが経由できるネットワーク・ホップ数を設定します。マルチキャスト存続時間パラメータを適切に設定することにより、クラスタ内のサーバー・インスタンス間で送受信されるマルチキャスト・メッセージが消失するリスクが少なくなります。

マルチキャスト・メッセージが確実に転送されるようにネットワーク・トポロジを設計する方法については、「クラスタがWAN内の複数のサブネットにまたがる場合」 を参照してください

クラスタのマルチキャスト存続時間(TTL)を構成するには、WebLogic Server管理コンソールで、ターゲットとなるクラスタの「マルチキャスト」ページにある「マルチキャストTTL」の値を変更します。次のconfig.xmlの抜粋部分は、マルチキャスト存続時間(TTL)値に3を指定したクラスタを示します。この値によって、破棄される前にクラスタのマルチキャスト・メッセージを3つのルーターに渡すことができます。

<Cluster
Name="testcluster"
ClusterAddress="wanclust"
MulticastAddress="wanclust-multi"
MulticastTTL="3"
/>

注意:

マルチキャストTTL値に依存する場合は、クラスタ化環境において、サーバー間のタイム・スタンプが同期しない場合がある点に注意してください。この現象は、たとえばレプリケートされたHTTPセッションやEJBで発生します。

ClusterDebugフラグが有効になっていると、クラスタ・メンバーのクロックが同期していない場合に、サーバー・ログにエラーが記録されます。

マルチキャスト・バッファのサイズを構成する

クラスタ内のサーバー・インスタンスが受信メッセージを適時に処理しないことが原因でマルチキャスト・ストームが発生する場合は、マルチキャスト・バッファのサイズを増やすことができます。マルチキャスト・ストームの詳細は、「マルチキャスト・ストームが起こったら」を参照してください

TCP/IPカーネル・パラメータは、UNIXのnddユーティリティを使用して構成できます。udp_max_bufパラメータでは、UDPソケットの送信および受信バッファのサイズをバイト単位で管理します。udp_max_bufの適切な値は、デプロイメントによって異なります。マルチキャスト・ストームが発生する場合は、udp_max_bufの値を32K単位で増やして、その変更の効果を評価します。

必要な場合以外は、udp_max_bufの値を変更しないでください。udp_max_bufを変更する前に、『Solaris Tunable Parameters Reference Manual』(http://docs.oracle.com/docs/cd/E19253-01/817-0404/chapter4-70/index.html)の「Internet Protocol Suite Tunable Parameters」章のUDP Parameters with Additional Cautionsに記載されているSunの警告をご確認ください。

マルチキャスト・データの暗号化を構成する

WebLogic Serverでは、クラスタ間で送信されるマルチキャスト・メッセージを暗号化できます。WebLogic Server管理コンソールで「環境」→「クラスタ」→「cluster_name」→「マルチキャスト」ノードに移動し、「詳細」オプションを選択して、「マルチキャスト・データの暗号化を有効にする」を選択することで、このオプションを有効にできます。

マルチキャスト・メッセージのデータ部分のみが暗号化されます。マルチキャスト・ヘッダーの情報は暗号化されません。

マシン名を構成する

次の場合にマシン名を構成します。

- クラスタが複数のマシンにまたがっており、複数のサーバー・インスタンスがクラスタ内の各マシンで動作する、あるいは

- 管理サーバーをホストしないマシンでノード・マネージャを実行する

WebLogic Serverでは、構成されたマシン名を使用して、2つのサーバー・インスタンスが物理的に同じハードウェアに存在しているかどうかを調べることができます。マシン名は一般に、複数のサーバー・インスタンスのホストとなるマシンで使用されます。そのようなインストール用のマシン名を定義していない場合、各インスタンスは物理的に異なるハードウェア上に存在するものとして扱われます。このことは、「レプリケーション・グループの使用」で説明しているように、セカンダリHTTPセッション状態のレプリカのホストになるサーバー・インスタンスの選択に悪影響を与えることがあります

複数層アーキテクチャの構成に関する注意

複数層アーキテクチャのクラスタの構成については、「複数層アーキテクチャの構成に関する考慮事項」のガイドラインを参照してください

URL書換えを有効にする

デフォルト構成のWebLogic Serverでは、クライアント側のCookieを使用して、クライアントのサーブレット・セッション状態のホストであるプライマリ・サーバー・インスタンスとセカンダリ・サーバー・インスタンスが追跡されます。クライアントのブラウザでCookieが無効になっている場合、WebLogic ServerではURL書換えによってもプライマリ・サーバー・インスタンスとセカンダリ・サーバー・インスタンスを追跡できます。URL書換えを利用する場合は、クライアント・セッション状態の両方の場所が、クライアントとプロキシ・サーバーの間で渡されるURLに挿入されます。この機能をサポートするには、WebLogic ServerクラスタでURL書換えを有効にする必要があります。URL書換えを有効にする方法は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のCookieにかわるURL書換えの使用に関する項を参照してください。

11 動的クラスタ

この章では、動的クラスタの概要と、WebLogic Server内で動的クラスタを作成、構成および使用する方法について説明します。

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

- 動的クラスタとは

- 動的クラスタを使用する理由

- 動的クラスタの仕組み

- 動的クラスタを使用する際の制限事項と考慮事項

- 動的クラスタの例

動的クラスタとは

動的クラスタは、アプリケーションのリソース・ニーズを満たすように動的にスケール・アップできるサーバー・インスタンスで構成されます。動的クラスタは、指定した数の生成された(動的)サーバー・インスタンスの構成を定義する単一のサーバー・テンプレートを使用します。動的クラスタを作成すると、動的サーバーが事前構成され、自動的に生成されます。これにより、追加のサーバー容量が必要な場合に動的クラスタ内のサーバー・インスタンスの数を簡単にスケール・アップできます。動的サーバーは、最初に手動で構成してそれをクラスタに追加する必要はなく、単に起動するだけで使用できます。

最初に指定した数のサーバー・インスタンスに追加が必要となった場合、動的クラスタの構成でサーバー・インスタンス(動的)の最大数を増やすか、構成済サーバー・インスタンスを手動で動的クラスタに追加することが可能です。動的サーバー・インスタンスと構成済サーバー・インスタンスの両方が含まれた動的クラスタを複合クラスタと呼びます。

次の表に、動的クラスタに関連する用語の定義を示します。

用語

定義

動的クラスタ

1つの共有サーバー・テンプレートに基づいた生成済(動的)サーバー・インスタンスを1つ以上備えたクラスタ。

構成済クラスタ

手動で構成し、各サーバー・インスタンスを追加するクラスタ。

動的サーバー

動的クラスタの作成時にWebLogic Serverで生成されるサーバー・インスタンス。構成は、共有サーバー・テンプレートに基づきます。

構成済サーバー

属性を手動で構成するサーバー・インスタンス。

複合クラスタ

動的サーバー・インスタンスと構成済サーバー・インスタンスの両方を備えたクラスタ。

サーバー・テンプレート

一連のサーバー・インスタンスに割り当てることができ、テンプレートの構成を継承する、デフォルト以外の共通の設定と属性が含まれたプロトタイプ・サーバーの定義。動的クラスタでは、サーバー・テンプレートを使用して動的サーバーを生成します。『Oracle WebLogic Serverドメイン構成の理解』のサーバー・テンプレートに関する項を参照してください。

動的サーバーは個別に構成できません。動的クラスタを使用する際には、config.xmlファイルにサーバー・インスタンスの定義が存在しません。したがって、サーバー・テンプレートをサーバー固有の属性でオーバーライドしたり、アプリケーションを個別の動的サーバー・インスタンスにターゲット指定したりできません。例11-1は、動的クラスタを含むconfig.xmlファイルの例を示しています。

例11-1 動的クラスタを使用するconfig.xmlファイルの例

<server-template>
<name>dynamic-cluster-server-template</name>
<accept-backlog>2000</accept-backlog>
<auto-restart>true</auto-restart>
<restart-max>10</restart-max>
<startup-timeout>600</startup-timeout>
</server-template>

<cluster>
<name>dynamic-cluster</name>
<dynamic-servers>
<server-template>dynamic-cluster-server-template</server-template>
<maximum-dynamic-server-count>10</maximum-dynamic-server-count>
<calculated-machine-names>true</calculated-machine-names>
<machine-name-match-expression>dyn-machine*</machine-name-match-expression>
<server-name-prefix>dynamic-server-</server-name-prefix>
</dynamic-servers>
</cluster>

動的クラスタを使用する理由

動的クラスタを使用すると、サーバーの容量を追加する必要があるときに、1つまたは複数の構成済動的サーバー・インスタンスを起動するだけで、簡単にクラスタをスケール・アップできます。新しいサーバー・インスタンスを手動で構成してそれをクラスタに追加したり、システムの再起動を実行する必要はありません。

動的クラスタの仕組み

次の各項では、動的クラスタの使用方法について説明します。

- 動的クラスタの作成と構成

- サーバー・テンプレートの使用

- サーバー固有の属性の計算

- 動的クラスタ内のサーバーの起動と停止

- 動的クラスタの拡張と縮小

- 動的クラスタでのサーバー全体の移行の使用

- 動的クラスタへのアプリケーションのデプロイ

- 動的クラスタでのWebLogic Webサーバー・プラグインの使用

動的クラスタの作成と構成

動的クラスタを作成する場合には、次の処理を実行します。

- ピーク負荷時に必要となると考えられるサーバー・インスタンスの数の指定

- サーバーの構成の基準とするサーバー・テンプレートの作成または選択

- WebLogic Serverでサーバー固有の属性を計算する方法の定義

WebLogic Serverでは、指定された数の動的サーバー・インスタンスを生成し、各動的サーバー・インスタンスに計算した属性値を適用します。

注意:

動的クラスタの構成に指定したサーバー・インスタンスの最大数を処理できる性能があることを確認します。クラスタを作成する際の設計およびデプロイメントに関するベスト・プラクティスは、「クラスタリングのベスト・プラクティス」を参照してください。

WebLogic Scripting Tool (WLST)、WebLogic Server管理コンソールまたはEnterprise Manager (EM)のFusion Middleware Control (FMWC)コンポーネントを使用して、動的クラスタを作成します。

例11-2はWLSTを使用した場合の例を示しています。WebLogic Server管理コンソールの使用の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの動的クラスタの作成に関する項を参照してください。FMWCの使用の詳細は、『Oracle Fusion Middleware Fusion Middleware ControlによるOracle WebLogic Serverの管理』の新しい動的クラスタの作成に関する項を参照してください。いずれかのコンソールで動的クラスタを作成する際、WebLogic Serverにより、サーバー・テンプレート、動的クラスタ、および指定された数のサーバー・インスタンスが作成されます。それらを別々に指定する必要はありません。動的クラスタを構成するには、『Oracle WebLogic Serverの理解』のシステム管理ツールおよびAPIの概要に関する項にリストされた、いずれかの管理ツールを使用します。

サーバー・テンプレートの使用

サーバー・テンプレートは、一連のサーバー・インスタンスが共有する構成属性を定義します。動的クラスタでは、動的サーバーの構成にサーバー・テンプレートが使用されます。サーバー・テンプレートの詳細は、『Oracle WebLogic Serverドメイン構成の理解』のサーバー・テンプレートに関する項を参照してください。

サーバー固有の属性の計算

動的クラスタを使用する際には、動的サーバー・インスタンスを個別に構成したり、動的サーバー・レベルでサーバー・テンプレートの値をオーバーライドしたりできません。サーバー名、マシン、リスニング・ポートなどのサーバー固有の属性は、動的クラスタを作成する際に提供された情報を使用して計算する必要があります。

注意:

JTAトランザクション回復サービスをホストすることになる管理対象サーバーのインスタンスには、一意のリスニング・アドレス値を設定する必要があります。そうしないと、移行は失敗します。

WebLogic Serverは、動的サーバーのインスタンスIDを使用して、次のサーバー固有の属性を計算して適用します。

- サーバー名

- (オプション)リスニング・ポート(クリア・テキストおよびSSL)

- (オプション)ネットワーク・アクセス・ポイントのリスニング・ポート

- (オプション)マシンまたは仮想マシン

サーバー名の計算

計算済のサーバー名は、ServerNamePrefix属性によって制御されます。サーバー名には、指定された接頭辞が付き、その後に索引番号が続きます。たとえば、接頭辞がdyn-server-に設定されている場合、動的サーバーの名前は、(指定したサーバー・インスタンスの数に応じて)dyn-server-1、dyn-server-2などのようになります。

リスニング・ポートの計算

動的クラスタの構成やサーバー・テンプレートにおける設定に応じて、動的クラスタ内のサーバー・インスタンスのリスニング・ポートが決まります。動的クラスタを作成する際にリスニング・ポートを計算しない場合には、WebLogic Serverではサーバー・テンプレート内の値が使用されます。動的クラスタ構成やサーバー・テンプレート内でリスニング・ポートを定義しない場合、WebLogic Serverではデフォルト値が使用されます。リスニング・ポート設定は、CalculatedListenPorts属性によって制御されます。これらの設定の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの動的クラスタの作成に関する項を参照してください。

サーバー・テンプレートまたは動的クラスタ構成で動的クラスタの基本リスニング・ポートを明示的に定義すると、最初の動的サーバー・インスタンスのリスニング・ポート値は基本のリスニング・ポートになり、値が1ずつ増えていきます。動的サーバー・インスタンスを追加するたびに、リスニング・ポート値は1ずつ増えていきます。デフォルトの基本リスニング・ポートを使用する場合、WebLogic Serverは、動的サーバー・インスタンスごとに、百の位を1つ増やし、そこから続けます。表11-1に、計算されたリスニング・ポート値を示します。

表11-1 リスニング・ポートの計算

リスニング・ポートのタイプ

サーバー・テンプレート内の構成設定

動的サーバーのリスニング・ポート値

サーバーのリスニング・ポート

基本リスニング・ポートは設定されません

dyn-server-1: 7101

dyn-server-2: 7102

...

サーバーのリスニング・ポート

基本リスニング・ポートは7300に設定されます

dyn-server-1: 7301

dyn-server-2: 7302

...

サーバーのSSLリスニング・ポート

SSL基本リスニング・ポートは設定されません

dyn-server-1: 8101

dyn-server-2: 8102

...

サーバーのSSLリスニング・ポート

SSL基本リスニング・ポートは8200に設定されます

dyn-server-1: 8201

dyn-server-2: 8202

...

サーバーのネットワーク・アクセス・ポイントのリスニング・ポート

ネットワーク・アクセス・ポイントのリスニング・ポートは設定されません

dyn-server-1: 9101

dyn-server-2: 9102

...

サーバーのネットワーク・アクセス・ポイントのリスニング・ポート

ネットワーク・アクセス・ポイントのリスニング・ポートは9200に設定されます

dyn-server-1: 9201

dyn-server-2: 9202

...

サーバーのレプリケーション・ポート

レプリケーション・ポートは8100に設定されます

dyn-server-1: 8100

dyn-server-2: 8101

...

サーバーのレプリケーション・ポート

レプリケーション・ポートは8100-8104に設定されます

dyn-server-1: 8100-8104

dyn-server-2: 8105-8109

dyn-server-3: 8110-8114

...

システム・プロパティを使用して、サーバーの起動時にリスニング・ポートをオーバーライドできます。次に例を示します。

リスニング・ポートをオーバーライドする手順は次のとおりです。

-Dweblogic.ListenPort=7305

SSLリスニング・ポートをオーバーライドする手順は次のとおりです。

-Dweblogic.ssl.ListenPort=7403

mynapという名前のネットワーク・アクセス・ポイントのリスニング・ポートをオーバーライドする手順は次のとおりです。

-Dweblogic.networkaccesspoint.mynap.ListenPort=8201

マシン名の計算

動的クラスタのCalculatedMachineNames属性およびMachineNameMatchExpression属性は、動的クラスタ内のサーバー・インスタンスがマシンにどのように割り当てられるかを制御します。CalculatedMachineNames属性がfalseに設定されている場合、動的クラスタはマシンに割り当てられません。CalculatedMachineNames属性がtrueに設定されている場合、MachineNameMatchExpression属性が使用されて、動的サーバーで使用されているマシンのセットが選択されます。MachineNameMatchExpression属性が設定されていない場合、ドメイン内のすべてのマシンが選択されます。割当は、ラウンド・ロビン・アルゴリズムを使用して行われます。表11-2は、動的クラスタにおけるマシン割当の例を示しています。

表11-2 マシン名の計算

ドメイン内のマシン

MachineNameMatchExpression構成

動的サーバーのマシン割当

M1、M2

設定されません

dyn-server-1: M1

dyn-server-2: M2

dyn-server-3: M1

...

Ma1、Ma2、Mb1、Mb2

Ma1、Mb*

dyn-server-1: Ma1

dyn-server-2: Mb1

dyn-server-3: Mb2

dyn-server-4: Ma1

...

動的クラスタ内のサーバーの起動と停止

動的クラスタ内のサーバーの起動と停止を簡単に管理するには、WLSTのscaleUpコマンドとscaleDownコマンドを使用します。

scaleUpコマンドにより、指定した動的クラスタの実行サーバーの数が増加します。サーバーIDが最も小さい非実行サーバー・インスタンスが最初に起動し、指定した数のサーバー・インスタンスが起動するまで、次に大きなIDの非実行サーバー・インスタンスの起動が続きます。

動的クラスタ内で1つ、すべて、または任意の数のサーバー・インスタンスを起動するには、scaleUpコマンドでnumServers引数を使用して目的の数を指定します。利用可能なすべてのサーバー・インスタンスがすでに実行している場合、指定した数のサーバーを起動する前に、scaleUpコマンドにより、リクエストしたサーバー・インスタンスの最小数までクラスタのサイズを増やします。クラスタ・サイズの拡張の詳細は、「動的クラスタの拡張と縮小」を参照してください。

scaleDownコマンドでは、指定した数の実行サーバーを適切に停止します。サーバーIDが最も大きいサーバー・インスタンスが最初に停止し、指定した数のサーバー・インスタンスが停止するまで、次に大きなIDのサーバー・インスタンスの停止が続きます。詳細は、『Oracle Fusion Middleware WebLogic Server WLSTコマンド・リファレンス』のscaleUpに関する項およびscaleDownに関する項を参照してください。

構成済クラスタ内のサーバー・インスタンスの起動および停止に使用する方法と同じ方法で、動的クラスタ内のサーバー・インスタンスを起動および停止することもできます。つまり、WebLogic Server管理コンソール、Fusion Middleware Control、WLSTのstartコマンドとshutdownコマンド、ノード・マネージャおよび起動スクリプトを使用します。選択する起動方法や実行済のタスクに応じて、サーバー・インスタンスを起動する前に他の手順の実行が必要になる場合があります。詳細は、『Oracle WebLogic Serverサーバーの起動と停止の管理』のサーバーの起動と停止に関する項を参照してください。

注意:

始める前に、WebLogic Serverが、サーバー・インスタンスを実行するすべてのホストにインストールされていることを確認します。ノード・マネージャを使用してサーバー・インスタンスを起動および停止する場合は、それらのホスト上でノード・マネージャも実行する必要があります。

動的クラスタの拡張と縮小

動的クラスタを作成すると、WebLogic Serverでは指定した数の動的サーバーが生成されます。サーバー・インスタンスの数を決定する前に、希望の数を処理するための性能があることを確認してください。

動的サーバー・インスタンスは、サーバー・テンプレートで指定した構成と計算された属性に基づいています。クラスタを拡張する必要がある場合には、任意の数の構成済動的サーバーを指定します。動的クラスタを縮小するには、余分な数の動的サーバーを停止します。

最初に指定した数のサーバー・インスタンスに追加が必要となった場合、動的クラスタの構成で動的サーバーの最大数を増やすことができます。動的クラスタ内のサーバー・インスタンスの数を減らすには、動的サーバーの属性の最大数の値を減らします。この値を小さくする前に、削除する予定のサーバー・インスタンスを停止します。

WLSTのscaleUpコマンドとscaleDownコマンドを使用して、動的クラスタを管理することもできます。動的クラスタ内の動的サーバーの数を増やすには、scaleUpコマンドを使用して、updateConfiguration引数を有効にします。WLSTでは、指定した数のサーバーの分だけクラスタの最大サイズを増やし、サーバー・インスタンスを起動します。

動的クラスタの最大サイズを減らすには、scaleDownコマンドを使用して、updateConfiguration引数を有効にします。WLSTでは、指定した数の実行サーバー・インスタンスを適切に停止して、それらを動的クラスタから削除します。詳細は、『Oracle Fusion Middleware WebLogic Server WLSTコマンド・リファレンス』のscaleUpに関する項およびscaleDownに関する項を参照してください。

注意:

動的サーバー・インスタンスでは、WLSTのscaleUpコマンドとscaleDownコマンドのみ使用できます。手動で構成したサーバー・インスタンスと動的サーバー・インスタンスの両方が含まれる混在クラスタの場合、scaleUpコマンドとscaleDownコマンドでは、構成済サーバーが無視されます。混在クラスタ内の構成済サーバー・インスタンスを手動で起動して停止する必要があります。

たとえば、クラスタ内に、実行中の動的サーバー2台と実行していない構成済サーバー2台があるとします。scaleUpコマンドを使用する場合、WLSTでは、クラスタに動的サーバー・インスタンスを1つ追加して、動的サーバーを起動します。

WLSTのscaleUpコマンドとscaleDownコマンドには、動的クラスタを手動でスケーリングする方法が用意されています。自動スケーリングの場合、動的クラスタの拡張度を構成できます。拡張度を使用する場合、動的クラスタでは、要求に反応して、あるいはカレンダ・ベースのスケジュールのとおりにスケーリング操作や再プロビジョニング操作を自動で実行できます。WebLogic Serverでは、WebLogic診断フレームワーク(WLDF)のポリシーおよびアクション・システムによって動的クラスタに拡張度が提供されます。詳細は、『Oracle Fusion Middleware Oracle WebLogic Server動的クラスタの拡張度の構成』を参照してください。

動的クラスタでのサーバー全体の移行の使用

WebLogic Serverでは、動的クラスタおよび複合クラスタでのサーバー全体の移行がサポートされています。クラスタの種類に応じて構成は異なりますが、サーバー全体の移行の動作はすべてのクラスタで同じです。動的クラスタのサーバー全体の移行を有効化する方法の詳細は、「動的クラスタおよび複合クラスタでのサーバー全体の移行」を参照してください。

動的クラスタへのアプリケーションのデプロイ

アプリケーションを動的クラスタにデプロイする際には、そのアプリケーションをクラスタ全体にターゲット指定する必要があります。動的クラスタには個別の動的サーバー構成がないため、アプリケーションを個別のサーバー・インスタンスにターゲット指定できません。アプリケーションを動的クラスタにデプロイする際には、動的クラスタと静的クラスタの両方のクラスタ内のすべてのサーバーがそのアプリケーションをデプロイします。

アプリケーションを動的クラスタにデプロイするには、構成済クラスタへのデプロイと同じ手順を実行します。詳細は、「アプリケーションをデプロイする」および「クラスタ化構成でのアプリケーションのデプロイメント」を参照してください。

デプロイメントに関する全般的なトピックは、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。

動的クラスタでのWebLogic Webサーバー・プラグインの使用

動的クラスタでは構成済クラスタと同じWebLogic Webサーバー・プラグインが提供されます。デフォルトで、Webサーバー・プラグインはDynamicServerListパラメータを使用して、構成済クラスタまたは動的クラスタ内の新しいサーバー・インスタンスなどの、クラスタ変更の情報を受信します。クラスタ・メンバーシップの変更の再構成時に、プラグインは自動的にそのサーバー・リストを更新します。

WebLogic ServerでのWebサーバー・プラグインの使用の詳細は、『Oracle WebLogic Serverプロキシ・プラグインの使用』を参照してください。DynamicServerListパラメータまたはWebLogicClusterパラメータ(WebLogic Serverクラスタへのプロキシ中に必要)の詳細は、『Oracle WebLogic Serverプロキシ・プラグインの使用』のWebサーバー・プラグインの一般的なパラメータに関する項を参照してください。

動的クラスタを使用する際の制限事項と考慮事項

WebLogic Serverで動的クラスタを使用する際には、次の制限と考慮事項に注意してください。

- 動的クラスタを使用する場合、config.xmlファイル内に個別サーバーの定義が存在しないため、個別の動的サーバー・レベルではサーバー・テンプレートの値をオーバーライドできません。

- 各動的サーバーが必須パラメータのために一意の値を継承するよう、サーバー・テンプレート上でそれらの値が設定されていることを確認する必要があります。たとえば、サーバー・テンプレート構成の下のLLR表に対してその値をLLR_DYN_SRV_${id}に設定します。${id}は、動的サーバーごとの実行時のサーバー番号に置き換えられます。

注意:
詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのサーバー: 構成: 要約に関する項を参照してください

- 動的クラスタの構成に指定したサーバー・インスタンスの最大数を処理できる性能があることを確認する必要があります。

- 動的クラスタでは、個別の動的サーバー・インスタンスに対するターゲット指定はサポートされていません。したがって、次の項目は動的クラスタでは使用できません。

- 移行可能ターゲットを含む、クラスタへのターゲット指定ができないデプロイメント。そのため、動的クラスタ用の移行可能ターゲットは作成できません。

- 個々のサーバーを参照する構成属性。これには、JTA移行可能ターゲット、制約付き候補サーバー、ユーザーの優先サーバー、すべての候補サーバーおよびホスト・サーバーが含まれます。そのため、移行可能ターゲットのユーザー優先サーバーとして動的サーバーを指定できません。

- サーバー固有の構成属性。これには、レプリケーション・グループ、セカンダリ・プリファレンス・グループおよび候補マシン(サーバー・レベル)が含まれます。

- シングルトン・サービスに対する控えの候補。動的サーバーへのシングルトン・サービスを制限できません。

- 動的クラスタでサーバー全体を移行する場合、サーバー・テンプレートで候補マシンをリストしないため、動的クラスタが指定する候補マシンのリストを制限できません。

- 動的クラスタにもJMS制限があります。詳細は、『Oracle WebLogic Server JMSリソースの管理』の簡素化されたJMSクラスタ構成に関する項を参照してください。

- 複数のネットワーク・チャネルが構成される動的サーバーでは、それらのチャネルが様々なインタフェースに対してリスニングすることはできません。

動的クラスタの例

例11-2では、WLSTを使用して動的クラスタを作成する方法を示します。この例には、インライン・コメントと次の作業の実行方法が示されています。

1. サーバー・テンプレートを作成し、サーバー・テンプレートで必要なサーバー属性を指定します。

2. 動的クラスタを作成し、必要なクラスタ属性を指定します。

3. 動的クラスタのサーバー・テンプレートを設定します。

4. 動的クラスタで希望のサーバー・インスタンスの最大数を設定します。

5. 動的クラスタ内のサーバーを起動および停止します。

例11-2 WLSTでの動的クラスタの作成

#
# This example demonstrates the WLST commands needed to create a dynamic cluster
# (dynamic-cluster). The dynamic cluster uses a server template
# dynamic-cluster-server-template. To keep this example simple, error handling
# was omitted.
#
connect()
edit()
startEdit()
#
# Create the server template for the dynamic servers and set the attributes for
# the dynamic servers. Setting the cluster is not required.
#
dynamicServerTemplate=cmo.createServerTemplate("dynamic-cluster-server-template")
dynamicServerTemplate.setAcceptBacklog(2000)
dynamicServerTemplate.setAutoRestart(true)
dynamicServerTemplate.setRestartMax(10)
dynamicServerTemplate.setStartupTimeout(600)
#
# Create the dynamic cluster, set the number of dynamic servers, and designate the server template.
#
dynCluster=cmo.createCluster("dynamic-cluster")
dynServers=dynCluster.getDynamicServers()
dynServers.setMaximumDynamicServerCount(10)
dynServers.setServerTemplate(dynamicServerTemplate)
#
# Dynamic server names will be dynamic-server-1, dynamic-server-2, ...,
# dynamic-server-10.
#
dynServers.setServerNamePrefix("dynamic-server-")
#
# Listen ports and machines assignments will be calculated. Using a round-robin
# algorithm, servers will be assigned to machines with names that start with
# dyn-machine.
#
dynServers.setCalculatedMachineNames(true)
dynServers.setMachineNameMatchExpression("dyn-machine*")
#
# activate the changes
#
activate()

この結果得られるconfig.xmlファイルは次のようになります。

<server-template>
<name>dynamic-cluster-server-template</name>
<accept-backlog>2000</accept-backlog>
<auto-restart>true</auto-restart>
<restart-max>10</restart-max>
<startup-timeout>600</startup-timeout>
</server-template>

<cluster>
<name>dynamic-cluster</name>
<dynamic-servers>
<server-template>dynamic-cluster-server-template</server-template>
<maximum-dynamic-server-count>10</maximum-dynamic-server-count>
<calculated-machine-names>true</calculated-machine-names>
<machine-name-match-expression>dyn-machine*</machine-name-match-expression>
<server-name-prefix>dynamic-server-</server-name-prefix>
</dynamic-servers>
</cluster>

12 Coherenceクラスタの構成と管理

この章では、WebLogic ServerドメインでCoherenceクラスタを定義する手順、およびCoherenceクラスタを複数のWebLogic Serverクラスタに関連付ける方法について説明します。この章の手順は、WebLogic Serverドメインがすでに作成されていることを前提としています。

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

- Coherenceクラスタの概要

- Coherenceクラスタの設定

- Coherenceデプロイメント層の作成

- Coherenceクラスタの構成

- 管理対象Coherenceサーバーの構成

- 単一サーバー・クラスタの使用

- CoherenceでのWLSTの使用

Coherenceクラスタの概要

Coherenceクラスタは、アプリケーションのスケーラビリティ、可用性およびパフォーマンスを向上させるためにデータをメモリー内に分散する、複数の管理対象Coherenceサーバー・インスタンスで構成されています。アプリケーションは、ローカル・キャッシュ内のデータと相互作用し、データの分散とバックアップは、クラスタ・メンバー間で自動的に実行されます。

Coherenceクラスタは、WebLogic Serverクラスタとは異なります。これらのクラスタは、別のクラスタリング・プロトコルを使用し、別々に構成されます。複数のWebLogic ServerクラスタをCoherenceクラスタに関連付けることができ、WebLogic Serverドメインには通常、単一のCoherenceクラスタが含まれます。Coherenceクラスタ・メンバーとして構成されている管理対象サーバーは、管理対象Coherenceサーバーと呼ばれます。

管理対象Coherenceサーバーは、Coherenceクラスタに明示的に関連付けることができます。または、Coherenceクラスタに関連付けられているWebLogic Serverクラスタに関連付けることも可能です。管理対象Coherenceサーバーは通常、タイプに基づいた層(データを格納する場合はデータ層、アプリケーションをホストする場合はアプリケーション層、および外部クライアントがキャッシュにアクセスできるようにするにはプロキシ層)で設定されます。

図12-1に、WebLogic Serverドメイン内のCoherenceクラスタの概念を示します。

図12-1 Coherenceドメインのトポロジの概念

Coherenceクラスタの設定

WebLogic Serverドメインには通常、単一のCoherenceクラスタが含まれます。クラスタは、単一のシステムレベル・リソース(CoherenceClusterSystemResource)として表されます。CoherenceClusterSystemResourceインスタンスは、WebLogic Server管理コンソールまたはWLSTを使用して作成されます。

Coherenceクラスタには、任意の数の管理対象Coherenceサーバーを含めることができます。サーバーは、スタンドアロンの管理対象サーバーでも、Coherenceクラスタに関連付けられているWebLogic Serverクラスタのメンバーでもかまいません。通常、Coherenceクラスタには、複数のWebLogic Serverクラスタが関連付けられています。Coherenceが使用するWebLogic Serverクラスタの作成の詳細は、「Coherenceデプロイメント層の作成」を参照してください

注意:

管理対象Coherenceサーバーをクローニングしても、Coherenceクラスタへの関連付けはクローニングされません。管理対象サーバーは、Coherenceクラスタのメンバーにはなりません。クローニングされた管理対象サーバーをCoherenceクラスタに手動で関連付ける必要があります。

Coherenceクラスタ・リソースの定義

Coherenceクラスタ・リソースを定義する手順は次のとおりです。

1. WebLogic Server管理コンソールの「ドメイン構造」ペインで、「環境」を開き、「Coherenceクラスタ」をクリックします。

2. 「Coherenceクラスタのサマリー」ページで、「新規」をクリックします。

3. 「Coherenceクラスタ構成の作成」ページの「名前」フィールドに、クラスタの名前を入力します。「次」をクリックします。

4. 「Coherenceクラスタのアドレス指定」セクションで、クラスタリング・モードを選択するか、デフォルトの設定のままにします。ほとんどのクラスタの場合、デフォルトのクラスタ・リスニング・ポート(7574)を変更する必要はありません。クラスタリング・モードの構成の詳細は、「クラスタ通信の構成」を参照してください

5. 「Coherenceクラスタ・メンバー」セクションで、Coherenceクラスタのメンバーとする管理対象CoherenceサーバーまたはWebLogic Serverクラスタをクリックして選択します。管理対象CoherenceサーバーおよびWebLogicクラスタがまだ定義されていない場合は、このセクションをスキップします。

6. 「終了」をクリックします。「Coherenceクラスタのサマリー」画面が表示され、「Coherenceクラスタ」表にクラスタ・リソースが示されます。

スタンドアロンの管理対象Coherenceサーバーの作成

管理対象Coherenceサーバーは、Coherenceクラスタに関連付けられている管理対象サーバー・インスタンスです。管理対象Coherenceサーバーは、全体でCoherenceクラスタを形成し、多くの場合、クラスタ・メンバーと呼ばれます。クラスタ・メンバーには年功序列があり、古参のメンバーがクラスタ・タスク(クラスタ・ハート・ビートの発行など)を実行します。

注意:

- 管理対象Coherenceサーバーおよび(WebLogic Serverドメイン内で管理されていない)スタンドアロンのCoherenceクラスタ・メンバーが、同じクラスタに参加できます。ただし、スタンドアロンのクラスタ・メンバーはWebLogic Serverドメイン内からは管理できません。操作構成およびアプリケーション・ライフサイクルは手動で管理およびモニターする必要があります。

- 管理サーバーは通常、本番環境では管理対象Coherenceサーバーとしては使用されません。

管理対象Coherenceサーバーは、クラスタにおけるそれぞれのロールによって区別されます。ベスト・プラクティスは、クラスタ・ロールごとに異なる管理対象サーバー・インスタンス(およびできれば異なるWebLogic Serverクラスタ)を使用することです。

- ストレージが有効 – クラスタへのデータの格納を行う管理対象Coherenceサーバー。Coherenceアプリケーションは、グリッド・アーカイブ(GAR)としてパッケージ化され、ストレージが有効な管理対象Coherenceサーバーにデプロイされます。

- ストレージが無効 – クラスタへのデータの格納を行わず、Coherenceアプリケーション(キャッシュ・クライアント)のホストに使用される管理対象Coherenceサーバー。CoherenceアプリケーションGARは、EAR内にパッケージ化され、ストレージが無効な管理対象Coherenceサーバーにデプロイされます。

- プロキシ – ストレージが無効であり、かつ外部クライアント(非クラスタ・メンバー)によるキャッシュの使用を許可する管理対象Coherenceサーバー。CoherenceアプリケーションGARは、管理対象Coherenceプロキシ・サーバーにデプロイされます。

管理対象Coherenceサーバーを作成する手順は次のとおりです。

1. WebLogic Server管理コンソールの「ドメイン構造」ペインで、「環境」を開き、「サーバー」をクリックします。

2. 「新規」をクリックして、新しい管理対象サーバーを作成します。

3. 「新しいサーバーの作成」ページで、必要に応じてサーバーのプロパティを入力します。

4. このサーバーをWebLogic Serverクラスタのメンバーとするかどうかを選択します。Coherenceデプロイメント層として使用するWebLogic Serverクラスタの作成の詳細は、「Coherenceデプロイメント層の作成」を参照してください

5. 「終了」をクリックします。「サーバーのサマリー」ページが表示され、新しいサーバーが示されます。

6. 新しいサーバーを選択して、その設定を構成します。

7. 「Coherence」タブの「Coherenceクラスタ」ドロップダウン・リストを使用して、Coherenceクラスタを選択してこの管理対象サーバーに関連付けます。デフォルトでは、管理対象サーバーは、「ローカル記憶域有効」フィールドに示されているとおり、ストレージが有効なCoherenceメンバーです。管理対象Coherence設定の変更の詳細は、「管理対象Coherenceサーバーの構成」を参照してください

8. 「保存」をクリックします。「サーバーのサマリー」ページが表示されます。

9. 「サーバーのサマリー」ページで、「制御」タブをクリックし、サーバーを起動します。

Coherenceデプロイメント層の作成

Coherenceは、WebLogic Serverドメイン内で複数のトポロジをサポートしており、それにより、様々なレベルのパフォーマンス、スケーラビリティおよび使いやすさが提供されます。たとえば、開発時、単一のスタンドアロンの管理対象サーバー・インスタンスを、キャッシュ・サーバーとキャッシュ・クライアントの両方として使用できます。単一サーバー・トポロジは、設定と使用が容易ですが、最適なパフォーマンスまたはスケーラビリティを提供しません。本番では、Coherenceは通常、WebLogic Serverクラスタを使用して設定されます。1つのWebLogic Serverクラスタが、Coherenceデータ層として使用され、1つ以上のキャッシュ・サーバーをホストします。Coherenceアプリケーション層には別のWebLogic Serverクラスタが使用され、1つ以上のキャッシュ・クライアントをホストします。そして、(必要な場合) 1つ以上の管理対象Coherenceプロキシ・サーバーをホストするCoherenceプロキシ層、および拡張クライアントをホストするCoherence拡張クライアント層には、さらに別のWebLogic Serverクラスタが使用されます。階層型トポロジのアプローチにより、最適なスケーラビリティとパフォーマンスが提供されます。

この項の手順では、WebLogic Server管理コンソールのクラスタ設定ページとサーバー設定ページの両方を使用して、Coherenceデプロイメント層を作成します。WebLogic Serverクラスタおよび管理対象サーバー・インスタンスは、それぞれClusterMBeanおよびServerMBean MBeanを使用してCoherenceクラスタ・リソースに関連付けることができます。WebLogic Serverクラスタに関連付けられている管理対象サーバーは、クラスタのCoherence設定を継承します。ただし、設定はサーバー設定ページに反映されない場合があります。

Coherenceデータ層の構成と管理

Coherenceデータ層は、Coherenceクラスタに関連付けられているWebLogic Serverクラスタであり、ストレージが有効な任意の数の管理対象Coherenceサーバーをホストします。データ層内の管理対象Coherenceサーバーは、クラスタに(プライマリとバックアップの両方の)データを格納および分散します。データ層で必要な管理対象Coherenceサーバーの数は、Coherenceクラスタ内に格納されるデータの予想量および各サーバーで使用可能なメモリー量によって異なります。さらに、コンピュータの障害の際にデータが失われる可能性を回避するために、クラスタには、少なくとも4台の物理コンピュータが含まれている必要があります。

Coherenceアーティファクト(Coherence構成ファイル、POFシリアライゼーション・クラス、フィルタ、エントリ・プロセッサ、Aggregatorなど)は、GARとしてパッケージ化され、データ層にデプロイされます。Coherenceアプリケーションのパッケージ化とデプロイの詳細は、『Oracle WebLogic Server Oracle Coherenceアプリケーションの開発』を参照してください。キャッシュ・サイズの計算およびハードウェア要件の詳細は、『Oracle Coherenceの管理』の本番環境に移行する際のチェックリストを参照してください。

Coherenceデータ層の作成

Coherenceデータ層を作成する手順は次のとおりです。

1. WebLogic Serverクラスタを作成します。詳細は、「WebLogicクラスタの設定」を参照してください。

2. 「クラスタのサマリー」ページの「クラスタ」表でクラスタを選択してそれを構成します。

3. 「Coherence」タブの「Coherenceクラスタ」ドロップダウン・リストを使用して、Coherenceクラスタを選択してこのWebLogic Serverクラスタに関連付けます。デフォルトでは、このWebLogic Serverクラスタに割り当てられる管理対象サーバーは、「ローカル記憶域有効」フィールドに示されているとおり、ストレージが有効なCoherenceメンバーになります。

4. HTTPセッション・レプリケーションにCoherenceを使用している場合は、「Coherence Webローカル記憶域有効」または「Coherence Webフェデレーテッド記憶域有効」オプションのどちらかを選択してセッション・レプリケーションを有効にします。フェデレーテッド記憶域オプションを選択すると、構成されているデフォルトのフェデレーション・トポロジが使用されます。フェデレーションの構成の詳細は、キャッシュ・フェデレーションの構成を参照してください。

データ層の管理対象Coherenceサーバーの作成

Coherenceデータ層の管理対象サーバーを作成する手順は次のとおりです。

1. WebLogic Server管理コンソールの「ドメイン構造」ペインで、「環境」を開き、「サーバー」をクリックします。

2. 「新規」をクリックして、新しい管理対象サーバーを作成します。

3. 「新しいサーバーの作成」ページで、必要に応じてサーバーのプロパティを入力します。

4. 「はい」オプションをクリックしてサーバーを既存のクラスタに追加し、ドロップダウン・リストを使用してデータ層のWebLogic Serverクラスタを選択します。管理対象サーバーは、データ層のWebLogic ServerクラスタからCoherence設定を継承します。

5. 「終了」をクリックします。「サーバーのサマリー」ページが表示され、新しいサーバーが示されます。

6. これらの手順を繰り返して、必要に応じて追加の管理対象サーバーを作成します。

7. 「制御」タブで、起動するサーバーを選択し、「起動」をクリックします。

Coherenceアプリケーション層の構成と管理

Coherenceアプリケーション層は、Coherenceクラスタに関連付けられているWebLogic Serverクラスタであり、ストレージが無効な任意の数の管理対象Coherenceサーバーをホストします。アプリケーション層内の管理対象Coherenceサーバーは、Coherenceクラスタ・メンバーであり、アプリケーション(キャッシュ・ファクトリ・クライアント)をホストします。異なるアプリケーションに対して複数のアプリケーション層を作成できます。

アプリケーション層内のクライアントは、EARとしてデプロイされ、サーブレット、JSP、EJBなどのJava EE標準を使用して実装されます。Coherenceアーティファクト(Coherence構成ファイル、POFシリアライゼーション・クラス、フィルタ、エントリ・プロセッサ、Aggregatorなど)は、GARとしてパッケージ化され、EAR内にもデプロイされる必要があります。Coherenceアプリケーションのパッケージ化とデプロイの詳細は、『Oracle WebLogic Server Oracle Coherenceアプリケーションの開発』を参照してください。

Coherenceアプリケーション層の作成

Coherenceアプリケーション層を作成する手順は次のとおりです。

1. WebLogic Serverクラスタを作成します。詳細は、「WebLogicクラスタの設定」を参照してください。

2. 「クラスタのサマリー」ページの「クラスタ」表でクラスタを選択してそれを構成します。

3. 「Coherence」タブの「Coherenceクラスタ」ドロップダウン・リストを使用して、Coherenceクラスタを選択してこのWebLogic Serverクラスタに関連付けます。

4. 「ローカル記憶域有効」チェック・ボックスをクリックして、チェック・マークを削除し、アプリケーション層でストレージを無効にします。このWebLogic Serverクラスタに割り当てられる管理対象Coherenceサーバーは、ストレージが無効なCoherenceメンバー(キャッシュ・ファクトリ・クライアント)になります。アプリケーション層内のサーバーは、キャッシュ・データの格納には使用しないでください。ストレージが有効なサーバーは、データを格納および分散するためのリソースを必要とし、クライアントのパフォーマンスに悪影響を与えるおそれがあります。

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

アプリケーション層の管理対象Coherenceサーバーの作成

Coherenceアプリケーション層の管理対象サーバーを作成する手順は次のとおりです。

1. WebLogic Server管理コンソールの「ドメイン構造」ペインで、「環境」を開き、「サーバー」をクリックします。

2. 「新規」をクリックして、新しい管理対象サーバーを作成します。

3. 「新しいサーバーの作成」ページで、必要に応じてサーバーのプロパティを入力します。

4. 「はい」オプションをクリックしてサーバーを既存のクラスタに追加し、ドロップダウン・リストを使用してアプリケーション層のWebLogic Serverクラスタを選択します。管理対象サーバーは、データ層のWebLogic ServerクラスタからCoherence設定を継承します。

5. 「終了」をクリックします。「サーバーのサマリー」ページが表示され、新しいサーバーが示されます。

6. これらの手順を繰り返して、必要に応じて追加の管理対象サーバーを作成します。

7. 「制御」タブで、起動するサーバーを選択し、「起動」をクリックします。

Coherenceプロキシ層の構成と管理

Coherenceプロキシ層は、Coherenceクラスタに関連付けられているWebLogic Serverクラスタであり、任意の数の管理対象Coherenceプロキシ・サーバーをホストします。管理対象Coherenceプロキシ・サーバーにより、Coherence*Extendクライアントは、クラスタ・メンバーにならなくてもCoherenceキャッシュを使用することが可能になります。プロキシ層で必要な管理対象Coherenceプロキシ・サーバーの数は、予想されるクライアントの数によって異なります。ロード・バランシングを可能にするには、少なくとも2台のプロキシ・サーバーを作成する必要があります。ただし、多数のクライアント接続およびリクエストをサポートする場合は、追加のサーバーが必要になることがあります。

Coherence*Extendおよび拡張クライアントの作成の詳細は、『Oracle Coherenceリモート・クライアントの開発』を参照してください。

Coherenceプロキシ層の作成

Coherenceプロキシ層を作成する手順は次のとおりです。

1. WebLogic Serverクラスタを作成します。詳細は、「WebLogicクラスタの設定」を参照してください。

2. 「クラスタのサマリー」ページの「クラスタ」表でクラスタを選択してそれを構成します。

3. 「Coherence」タブの「Coherenceクラスタ」ドロップダウン・リストを使用して、Coherenceクラスタを選択してこのWebLogic Serverクラスタに関連付けます。

4. 「ローカル記憶域有効」チェック・ボックスをクリックして、チェック・マークを削除し、プロキシ層でストレージを無効にします。プロキシ・サーバーは、キャッシュ・データの格納には使用しないでください。プロキシ・サービスによって、ストレージが有効なクラスタ・メンバーが悪影響を受けるおそれがあります。プロキシ・サービスは、クライアント負荷の処理に追加のリソースを必要とします。

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

プロキシ層の管理対象Coherenceサーバーの作成

Coherenceプロキシ層の管理対象サーバーを作成する手順は次のとおりです。

1. WebLogic Server管理コンソールの「ドメイン構造」ペインで、「環境」を開き、「サーバー」をクリックします。

2. 「新規」をクリックして、新しい管理対象サーバーを作成します。

3. 「新しいサーバーの作成」ページで、必要に応じてサーバーのプロパティを入力します。

4. 「はい」オプションをクリックしてサーバーを既存のクラスタに追加し、ドロップダウン・リストを使用してプロキシ層のWebLogic Serverクラスタを選択します。管理対象サーバーは、データ層のWebLogic ServerクラスタからCoherence設定を継承します。

5. 「終了」をクリックします。「サーバーのサマリー」ページが表示され、新しいサーバーが示されます。

6. これらの手順を繰り返して、必要に応じて追加の管理対象サーバーを作成します。

7. 「制御」タブで、起動するサーバーを選択し、「起動」をクリックします。

Coherenceプロキシ・サービスの構成

Coherenceプロキシ・サービスは、拡張クライアントからのリモート接続を管理するクラスタ化されたサービスです。プロキシ・サービスは、<proxy-scheme要素内のcoherence-cache-config.xmlファイルで定義および構成されます。定義には、その他の設定の他に、クライアント接続の受入に使用されるTCPリスナー・アドレス(IPまたはDNS名、およびポート)があります。<proxy-scheme要素の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。プロキシ・サービスを設定する方法は2つあります。1つはネーム・サービスを使用する方法、もう1つはアドレス・プロバイダを使用する方法です。ネーミング・サービスを使用すると、効率的な設定を行うことができ、Coherenceプロキシ層では通常、ネーミング・サービスの使用が推奨されます。

ネーム・サービスの使用

ネーム・サービスは、拡張クライアントがプロキシ・サービスに名前で接続できるようにする専用のリスナーです。クライアントは、ネーム・サービスに接続し、ネーム・サービスは、クラスタ上のすべてのプロキシ・サービスのアドレスを戻します。

注意:

ドメインに複数の層(データ層、アプリケーション層、プロキシ層など)が含まれている場合、クライアントがプロキシに接続できるようにするために、まずプロキシ層を起動する必要があります。

プロキシ・サービスを管理対象Coherenceプロキシ・サーバー上で構成すると、ネーム・サービスがポート7574 (TCMPソケットが使用するものと同じデフォルト・ポート)で自動的に起動します。同じポートを再利用することで、Coherenceが使用するポートの数を最小限に抑え、ファイアウォール構成を簡素化できます。

プロキシ・サービスを構成し、デフォルトのTCMPポート上でネーム・サービスを有効にする手順は次のとおりです。

1. coherence-cache-config.xmlファイルを編集し、<proxy-scheme>定義を作成します。この際、ソケット・アドレスは明示的に定義しないでください。次の例では、TcpExtendという名前のプロキシ・サービスを定義し、クラスタ・ネーム・サービスを自動で有効にします。プロキシ・アドレスとエフェメラル・ポートは、自動的に割り当てられ、クラスタのネーム・サービスに登録されます。

...
<caching-schemes>
...
<proxy-scheme>
<service-name>TcpExtend</service-name>
<autostart>true</autostart>
</proxy-scheme>
</caching-schemes>
...

2. Coherenceプロキシ層内の管理対象Coherenceプロキシ・サーバーそれぞれにcoherence-cache-config.xmlファイルをデプロイします。通常、coherence-cache-config.xmlファイルは、GARファイル内に含まれています。ただし、プロキシ層の場合、クラスタ・キャッシュ構成ファイルを使用して、GARに格納されているcoherence-cache-config.xmlファイルをオーバーライドします。このため、単一のGARをクラスタとプロキシ層にデプロイできます。クラスタ・キャッシュ構成ファイルの使用の詳細は、「キャッシュ構成ファイルのオーバーライド」を参照してください

ネーム・サービスに接続するには、クライアントのcoherence-cache-config.xmlファイルのリモート・キャッシュまたはリモート呼出し定義の<tcp-initiator要素内に、<name-service-addresses要素が含まれている必要があります。<name-service-addresses要素は、管理対象Coherenceプロキシ・サーバー上のネーム・サービスのソケット・アドレスを提供します。次の例では、リモート・キャッシュを定義し、ポート7574でホスト192.168.1.5をリスニングするネーム・サービスを指定します。クライアントは、ネーム・サービスに自動的に接続し、TcpExtendプロキシ・サービスが含まれているすべての管理対象Coherenceプロキシ・サーバーのリストを取得します。クラスタ上のキャッシュも、TcpExtendという名前である必要があります。この例では、単一のアドレスが提供されます。プライマリ・アドレスでの障害に備えて、2つ目のネーム・サービス・アドレスを提供することも可能です。クライアント構成およびプロキシ・サービスのロード・バランシングの詳細は、『Oracle Coherenceリモート・クライアントの開発』を参照してください。

<remote-cache-scheme>
<scheme-name>extend-dist</scheme-name>
<service-name>TcpExtend</service-name>
<initiator-config>
<tcp-initiator>
<name-service-addresses>
<socket-address>
<address>192.168.1.5</address>
<port>7574</port>
</socket-address>
</name-service-addresses>
</tcp-initiator>
</initiator-config>
</remote-cache-scheme>

ネーム・サービスは、デフォルトでクラスタ・ポート(7574)にリスニングし、Coherenceクラスタ・ノードを実行するすべてのマシンで利用できます。ターゲット・クラスタでデフォルトのTCMPクラスタ・ポートを使用する場合、構成からポートを省略できます。

注意:

- <service-name>値は、プロキシ・スキームの<service-name>値に一致している必要があります。それ以外の場合、プロキシ・スキーム内で構成されている<service-name>要素の値を含むリモート・キャッシュおよびリモート呼び出しスキームで、<proxy-service-name>要素も提供する必要があります。

- 以前のCoherenceリリースでは、ネーム・サービスは、クラスタ・ポートではなくメンバーのユニキャスト・ポートに自動でリスニングしていました。

- アドレス・プロバイダを使用して、ネーム・サービス・アドレスを指定することもできます。

アドレス・プロバイダの使用

アドレス・プロバイダは、プロキシ・サービスのTCPリスナー・アドレス(IPまたはDNS名、およびポート)を指定します。リスナー・アドレスは、coherence-cache-config.xmlファイルの<proxy-scheme>要素で明示的に定義できます。ただし、望ましい方法は、クラスタ構成ファイルでアドレス・プロバイダを定義し、<proxy-scheme>要素内からアドレスを参照することです。後者の方法では、アプリケーション構成からデプロイメント構成を分離し、coherence-cache-config.xmlファイルを更新せずにネットワーク・アドレスを変更することが可能です。

アドレス・プロバイダを使用する手順は次のとおりです。

1. Coherenceクラスタの「設定」ページの「アドレス・プロバイダ」タブを使用して、アドレス・プロバイダ定義を作成します。CoherenceAddressProvidersBean MBeanも、アドレス・プロバイダ定義を公開します。アドレス・プロバイダには、プロキシ・サービスのリスナー・アドレスに加えて、一意の名前が含まれます。たとえば、proxy1というアドレス・プロバイダでは、リスナー・アドレスとしてホスト192.168.1.5およびポート9099を指定することが考えられます。

2. 手順1を繰り返し、各プロキシ・サービスのアドレス・プロバイダ定義を作成します(それぞれの管理対象Coherenceプロキシ・サーバーについて少なくとも1つ)。

3. 管理対象Coherenceプロキシ・サーバーそれぞれについて、coherence-cache-config.xmlファイルを編集し、<proxy-scheme>定義を作成して、<address-provider>要素内のアドレス・プロバイダ定義を名前で参照します。次の例では、proxy1というアドレス・プロバイダを参照するプロキシ・サービスを定義します。

...
<caching-schemes>
<proxy-scheme>
<service-name>TcpExtend</service-name>
<acceptor-config>
<tcp-acceptor>
<address-provider>proxy1</address-provider>
</tcp-acceptor>
</acceptor-config>
<autostart>true</autostart>
</proxy-scheme>
</caching-schemes>
...

4. 各coherence-cache-config.xmlファイルを、それぞれの管理対象Coherenceプロキシ・サーバーにデプロイします。通常、coherence-cache-config.xmlファイルは、GARファイル内に含まれています。ただし、プロキシ層では、クラスタ・キャッシュ構成ファイルを使用します。クラスタ・キャッシュ構成ファイルは、GARに格納されているcoherence-cache-config.xmlファイルより優先されます。これにより、同じGARをすべてのクラスタ・メンバーにデプロイできますが、この場合プロキシ層に固有の一意の設定が使用されます。クラスタ・キャッシュ構成ファイルの使用の詳細は、「キャッシュ構成ファイルのオーバーライド」を参照してください

プロキシ・サービスに接続するには、クライアントのcoherence-cache-config.xmlファイルのリモート・キャッシュまたはリモート呼出し定義の<tcp-initiator>要素内に、<remote-addresses>要素(これにはアドレス・プロバイダ名が含まれます)が含まれている必要があります。次に例を示します。

<remote-cache-scheme>
<scheme-name>extend-dist</scheme-name>
<service-name>TcpExtend</service-name>
<initiator-config>
<tcp-initiator>
<remote-addresses>
<address-provider>proxy1</address-provider>
</remote-addresses>
</tcp-initiator>
</initiator-config>
</remote-cache-scheme>

クライアントは、リモート・アドレスを明示的に指定することもできます。次の例では、リモート・キャッシュを定義し、ホスト192.168.1.5およびポート9099でプロキシ・サービスを指定します。クライアントは、プロキシ・サービスに自動的に接続し、TcpExtendという名前のクラスタ上のキャッシュを使用します。この例では、単一のアドレスが提供されます。プライマリ・アドレスでの障害に備えて、2つ目のアドレスを提供することも可能です。クライアント構成およびプロキシ・サービスのロード・バランシングの詳細は、『Oracle Coherenceリモート・クライアントの開発』を参照してください。

<remote-cache-scheme>
<scheme-name>extend-dist</scheme-name>
<service-name>TcpExtend</service-name>
<initiator-config>
<tcp-initiator>
<remote-addresses>
<socket-address>
<address>192.168.1.5</address>
<port>9099</port>
</socket-address>
</remote-addresses>
</tcp-initiator>
</initiator-config>
</remote-cache-scheme>

Coherenceクラスタの構成

Coherenceクラスタ・リソースは、特定のドメイン用に構成可能ないくつかのクラスタ設定を公開します。次のタスクを使用して、クラスタ設定を構成します。

- Coherenceクラスタ・メンバーの追加と削除

- クラスタ構成の詳細オプションの設定

- クラスタ通信の構成

- キャッシュ構成ファイルのオーバーライド

- Coherenceロギングの構成

- キャッシュ永続性の構成

- キャッシュ・フェデレーションの構成

多くの設定では、必要に応じて変更可能なデフォルト値が使用されます。次の手順は、クラスタ・リソースがすでに作成されていることを前提としています。クラスタ・リソースの作成の詳細は、Coherenceクラスタの設定を参照してください。この項には、Coherenceを保護する手順は含まれていません。セキュリティの詳細は、『Oracle Coherenceの保護』を参照してください。

Coherenceクラスタの「設定」ページの「Coherence」タブを使用して、クラスタ通信を構成します。CoherenceClusterSystemResource MBeanおよびそれに関連付けられているCoherenceClusterResource MBeanがクラスタ設定を公開します。CoherenceClusterResource MBeanは、Coherenceクラスタを構成するために複数のMBeanにアクセスできるようにします。

Coherenceクラスタ・メンバーの追加と削除

既存のどの管理対象サーバー・インスタンスも、Coherenceクラスタに追加できます。さらに、管理対象Coherenceサーバーをクラスタから削除できます。クラスタ・メンバーの追加と削除は、Coherenceクラスタの構成時に行うことができ、各インスタンスを明示的に構成するかわりに使用できる簡便な方法です。ただし、既存の管理対象サーバー・インスタンスを追加する場合は、デフォルトのCoherence設定を変更する必要があります。管理対象Coherenceサーバーの構成の詳細は、「管理対象Coherenceサーバーの構成」を参照してください

Coherenceクラスタの「設定」ページの「メンバー」タブを使用して、Coherenceクラスタに関連付ける管理対象サーバーまたはWebLogic Serverクラスタを選択します。WebLogic Serverクラスタを選択する場合は、WebLogic Serverクラスタ内のすべての管理対象サーバーをCoherenceクラスタに関連付けることをお薦めします。CoherenceClusterSystemResourceは、すべての管理対象Coherenceサーバーをターゲットとして公開します。CoherenceMemberConfig MBeanが各管理対象サーバーに対して作成され、Coherenceクラスタ・メンバーのパラメータを公開します。

クラスタ構成の詳細オプションの設定

WebLogic Server MBeanは、ほとんどのユースケースで十分なCoherence操作設定のサブセットを公開します。これについては、この章全体で詳細に説明します。これらの設定は、WLSTユーティリティおよびWebLogic Server管理コンソールでネイティブに使用できます。より高度なユースケースでは、外部Coherenceクラスタ構成ファイル(tangosol-coherence-override.xml)を使用します。このファイルは、Coherence操作設定に対する完全な制御を提供します。

注意:

外部クラスタ構成ファイルの使用をお薦めするのは、提供されているMBeanでは使用できない操作設定に対してのみです。つまり、外部クラスタ構成ファイルとMBeanの両方で同じ操作設定を構成することは避けてください。

Coherenceクラスタの「設定」ページの「全般」タブを使用して、管理サーバー上にあるクラスタ構成ファイルのパスと名前を入力するか、CoherenceClusterSystemResource MBeanを使用します。Coherenceクラスタ構成ファイルの使用の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。このマニュアルには、各要素の使用方法および詳細なスキーマ・リファレンスも記載されています。

どの操作構成が使用されるかのチェック

Coherenceは、WebLogic Server MBean、Coherenceクラスタ構成ファイル(インポートされている場合)およびCoherenceシステム・プロパティ(設定されている場合)から操作構成を生成します。システム・プロパティweblogic.debug.DebugCoherence=trueが設定されている場合、結果は、管理対象Coherenceサーバーのログに書き込まれます。WebLogic起動スクリプトを使用すると、JAVA_PROPERTIES環境変数を使用できます。次に例を示します。

export JAVA_PROPERTIES=-Dweblogic.debug.DebugCoherence=true

クラスタ通信の構成

クラスタ・メンバーは、Tangosol Cluster Management Protocol (TCMP)を使用して通信します。このプロトコルは、WLSクラスタ・プロトコルとは関係なく動作します。TCMPは、クラスタ・メンバーの検出、クラスタの管理、サービスのプロビジョニングおよびデータの送信を行うためのIPベースのプロトコルです。TCMPでは、様々なトランスポート・プロトコルを介して送信でき、マルチキャストとユニキャストの両方を使用できます。デフォルトでは、TCMPは、UDPを介して送信され、ユニキャストを使用します。別のトランスポート・プロトコルおよびマルチキャストを使用する場合は、基礎となるネットワークがそれをサポートしている必要があります。

Coherenceクラスタの「設定」ページの「全般」タブを使用して、クラスタ通信を構成します。CoherenceClusterParamsBeanおよびCoherenceClusterWellKnownAddressesBean MBeanは、クラスタ通信パラメータを公開します。

Coherenceクラスタ・モードの変更

Coherenceクラスタは、ユニキャスト通信とマルチキャスト通信の両方をサポートしています。マルチキャストは、デフォルトのオプションではありません。明示的に構成する必要があります。マルチキャストが適切にサポートされていない環境やマルチキャストが許可されていない環境では、マルチキャストの使用は避けてください。ユニキャストの使用により、すべてのマルチキャスト送信は無効になり、自動的にCoherence Well Knownアドレス(WKA)機能を使用して、クラスタ・メンバーの検出およびクラスタ・メンバー間の通信が行われます。「Well Knownアドレス・メンバーの指定」を参照してください。

Coherenceでのマルチキャスト、ユニキャストおよびWKAの使用の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

Coherenceクラスタ・モードでのユニキャストの選択

クラスタ通信でユニキャストを使用するには、「クラスタリング・モード」ドロップダウン・リストから「ユニキャスト」を選択し、クラスタ・ポートを入力するか、デフォルト・ポート7574のままにします。ほとんどのクラスタの場合、ポートの変更は必要ありません。ただし、複数のCoherenceクラスタが同じコンピュータで実行する場合、ポートの変更が必要です。別のポートが必要な場合、お薦めのベスト・プラクティスとして、1024から8999までの値を選択します。

Well Knownアドレス・メンバーの指定

ユニキャストが有効な場合は、「ウェル・ノウン・アドレス」タブを使用してWKAマシン・アドレスを明示的に構成します。クラスタに対してアドレスが定義されていない場合、アドレスが自動的に割り当てられます。ユニキャストを使用する際は、お薦めのベスト・プラクティスとして、WKAマシン・アドレスを常に明示的に指定します。

さらに、異なるマシン上にある複数の管理対象Coherenceサーバーがドメインに含まれる場合、Coherenceクラスタが確実に形成されるように少なくとも1つの非ローカルWKAマシン・アドレスを定義する必要があります。そうでない場合、各マシンに複数の個別クラスタが形成されます。管理対象Coherenceサーバーがすべて同じマシン上で実行している場合、非ローカル・リスニング・アドレスを指定せずにクラスタを作成できます。

注意:

WKAマシン・アドレスは、本番環境で明示的に定義される必要があります。本番モードで、WKAマシン・アドレスが明示的に定義されていない場合、管理対象Coherenceサーバーは起動に失敗します。自動的に割り当てられたWKAマシン・アドレスは、設計時の便宜を図るためのもので、開発時に単一サーバー上でのみ使用する必要があります。

Coherenceクラスタ・モードでのマルチキャストの選択

クラスタ通信でマルチキャストを使用するには、「クラスタリング・モード」ドロップダウン・リストから「マルチキャスト」を選択し、クラスタ・ポートとマルチキャスト・リスニング・アドレスを入力します。ほとんどのクラスタの場合、デフォルトのクラスタ・ポート(7574)の変更は必要ありません。ただし、複数のCoherenceクラスタが同じコンピュータ上で実行する場合や複数のクラスタで同じマルチキャスト・アドレスを使用する場合、ポートの変更が必要です。別のポートが必要な場合、お薦めのベスト・プラクティスとして、1024から8999までの値を選択します。

「存続時間」フィールドを使用して、マルチキャスト・パケットが到達できるネットワーク範囲を指定します。存続時間値(TTL)はパケットが存続し続けるホップの数で表現されます。1つのネットワーク・インタフェース、ルーターまたは管理対象スイッチが1ホップと見なされます。TTL値には、実効性のある最も小さい整数値を指定します。

Coherenceクラスタ・トランスポート・プロトコルの変更

次のトランスポート・プロトコルは、TCMPでサポートされており、「トランスポート」ドロップダウン・リストを使用して選択できます。CoherenceClusterParamsBean MBeanは、トランスポート・プロトコル設定を公開します。

- ユーザー・データグラム・プロトコル(UDP) – UDPは、デフォルトのTCMPトランスポート・プロトコルで、マルチキャスト通信とユニキャスト通信の両方に使用されます。マルチキャストが無効な場合、すべての通信はUDPユニキャストを使用して行われます。

- 伝送制御プロトコル(TCP) – TCPトランスポート・プロトコルは、TCP通信が優先されているネットワーク環境で使用されます。ユニキャストが有効な場合、すべてのTCMP通信はTCPを使用します。マルチキャストが有効な場合、TCPはユニキャスト通信でのみ使用され、マルチキャスト通信にはUDPが使用されます。

- Secure Sockets Layer (SSL) – SSL/TCPトランスポート・プロトコルは、クラスタ・メンバー間で高度にセキュアな通信が必要なネットワーク環境で使用されます。SSLは、ユニキャスト通信でのみサポートされています。SSLを使用する場合は、マルチキャストを無効にしてください。SSLを使用するには、追加の構成が必要です。WebLogic Server内のCoherenceの保護の詳細は、『Oracle Coherenceの保護』を参照してください。

- TCPメッセージ・バス(TMB) – TMBプロトコルは、TCP/IPのサポートを提供します。

- SSL付きTMB (TMBS) – TMBSにはSSLソケット・プロバイダを使用する必要があります。『Oracle Coherenceでのアプリケーションの開発』を参照してください。

- ソケット・ダイレクト・プロトコル・メッセージ・バス(SDMB) – ソケット・ダイレクト・プロトコル(SDP)は、ストリーム接続のサポートを提供します。SDMBは、Exalogicでのみ有効です。

- SSL付きSDMB (SDMBS) – SDMBSはOracle Exalogicシステムでのみ使用でき、SSLソケット・プロバイダの使用が必要です。『Oracle Coherenceでのアプリケーションの開発』を参照してください。

- インフィニバンド・メッセージ・バス(IMB) – IMBは、ネイティブのInfiniBand Verbに基づいた最適なプロトコルを使用します。IMBは、Exalogicでのみ有効です。

- 軽量メッセージ・バス(LWMB) – LWMBはInfinibus通信にIMBのMSGQLT/LWIPCライブラリを使用します。LWMBはOracle Exalogicシステムでのみ使用でき、サービス通信とユニキャスト通信の両方でデフォルト・トランスポートになっています。LWMBは、TCMPがSSLで構成されていなければ、自動的に使用されます。

キャッシュ構成ファイルのオーバーライド

Coherenceキャッシュ構成ファイルでは、アプリケーションが使用するキャッシュを定義します。通常、キャッシュ構成ファイルは、GARモジュールに含まれています。GARは、データ層内のすべての管理対象Coherenceサーバーにデプロイされますが、EARの一部としてアプリケーション層にデプロイすることもできます。GARにより、キャッシュ構成がすべてのOracle Coherenceクラスタ・メンバー上で使用できるようになります。ただし、特定の管理対象Coherenceサーバーで別のキャッシュ構成ファイルを使用する必要があるユースケースも存在します。たとえば、プロキシ層では、GAR内のすべてのアーティファクトにアクセスする必要がありますが、起動するプロキシ・サービスが定義されている別のキャッシュ構成ファイルが必要です。

キャッシュ構成ファイルは、実行時にWebLogicクラスタまたは管理対象Coherenceサーバーに関連付けることができます。この場合、そのキャッシュ構成が、GARに含まれているキャッシュ構成ファイルをオーバーライドします。GARファイル内のキャッシュ構成ファイルを省略し、実行時に割り当てることもできます。実行時にキャッシュ構成ファイルをオーバーライドするには、キャッシュ構成ファイルがJNDI名にバインドされている必要があります。JNDI名は、<cache-configuration-ref要素のoverride-property属性を使用して定義されます。この要素は、GARファイル内にパッケージ化されているcoherence-application.xmlファイルにあります。coherence-application.xmlファイルの詳細は、『Oracle WebLogic Server Oracle Coherenceアプリケーションの開発』を参照してください。

次の例では、GAR内のMETA-INF/example-cache-config.xmlキャッシュ構成ファイルのオーバーライドに使用できる、cache-config/ExamplesGarという名前のオーバーライド・プロパティを定義します。

...
<cache-configuration-ref override-property="cache-config/ExamplesGar">
META-INF/example-cache-config.xml</cache-configuration-ref>
...

実行時、Coherenceクラスタの「設定」ページの「キャッシュ構成」タブを使用して、キャッシュ構成ファイルをオーバーライドします。override-property属性で定義されているものと同じJNDI名を指定する必要があります。キャッシュ構成は、管理サーバーに置くことも、URLで場所を指定することもできます。さらに、ドメインにファイルをインポートするか、それを指定の場所から使用するかを選択できます。「ターゲット」タブを使用して、どのOracle Coherenceクラスタ・メンバーがキャッシュ構成ファイルを使用するかを指定します。

次のWLST(オンライン)の例では、CoherenceClusterSystemResourceオブジェクトを使用してクラスタ・キャッシュ構成をどのようにオーバーライドできるかを示します。

edit()
startEdit()
cd('CoherenceClusterSystemResources/myCoherenceCluster/CoherenceCacheConfigs')
create('ExamplesGar', 'CoherenceCacheConfig')
cd('ExamplesGar')
set('JNDIName', 'ExamplesGar')
cmo.importCacheConfigurationFile('/tmp/cache-config.xml')
cmo.addTarget(getMBean('/Servers/coh_server'))
save()
activate()

WLSTの例では、CoherenceCacheConfigリソースを子として作成します。このスクリプトでは次に、キャッシュ構成ファイルがドメインにインポートされ、リソースのバインド先となるJNDIが指定されます。ファイルは、指定されたパスに存在している必要があります。最後に、キャッシュ構成が特定のサーバーにターゲット指定されます。キャッシュ構成リソースを特定のサーバーまたはWebLogic Serverクラスタにターゲット指定できることで、アプリケーションが、サーバーのコンテキスト(キャッシュ・サーバー、キャッシュ・クライアント、プロキシ・サーバーなど)に応じて異なる構成をロードすることが可能になります。

キャッシュ構成リソースをURLとして構成することもできます。

edit()
startEdit()
cd('CoherenceClusterSystemResources/myCoherenceCluster/CoherenceCacheConfigs')
create('ExamplesGar', 'CoherenceCacheConfig')
cd('ExamplesGar')
set('JNDIName', 'ExamplesGar')
set('CacheConfigurationFile', 'http://cache.locator/app1/cache-config.xml')
cmo.addTarget(getMBean('/Servers/coh_server'))
save()
activate()

Coherenceロギングの構成

WebLogic Server管理コンソールのCoherenceクラスタの「設定」ページにある「ロギング」タブ、またはCoherenceLoggingParamsBean MBeanを使用して、クラスタ・ロギングを構成します。WebLogic Serverロギングの詳細は、『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理』を参照してください。Coherenceロギング構成には次のものが含まれます。

- ロギングの無効化と有効化

- デフォルトのロガー名の変更
WebLogic Serverには、Coherenceロギングで使用できる2つのロガーが用意されています。1つはデフォルトのcom.oracle.coherenceロガー、もう1つはcom.oracle.wlsロガーです。com.oracle.wlsロガーは、汎用的なもので、WebLogic Serverログ出力用に構成されているのと同じハンドラを使用します。このロガーでは、Coherence固有の構成は許可されません。com.oracle.coherenceロガーでは、Coherenceログで別のハンドラを使用するなど、Coherence固有の構成が許可されます。

注意:

標準のlogging.propertiesファイルを通じてロギングを構成する場合、そのファイルで、Coherenceロギング用に現在構成されているものと同じロガー名が使用されていることを確認してください。

- ログ・メッセージの書式の変更
ログ・メッセージに情報を追加、またはログ・メッセージから情報を削除します。ログ・メッセージには、静的テキストの他に、実行時に置き換えられるパラメータ({date}など)も含めることができます。サポートされているログ・メッセージ・パラメータの詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

キャッシュ永続性の構成

Coherence保持は、Coherence分散キャッシュの永続性およびリカバリを管理します。致命的障害や、計画的メンテナンスによるクラスタ再起動の後に迅速なリカバリができるように、キャッシュされたデータは保持されます。Coherenceのキャッシュ永続性の全詳細は、キャッシュの保持を参照してください。

Coherenceクラスタ設定ページの「永続性」タブを使用して、アクティブ永続性を有効にし、永続性ファイルの格納先となるデフォルトの場所をオーバーライドします。CoherencePersistenceParamsBean MBeanが永続性パラメータを公開します。永続性の変更を有効にするために、管理対象Coherenceサーバーを再起動する必要があります。

オンデマンド永続性では、キャッシュ・サービスを手動で永続化し、リクエスト時(スナップショット)に永続性コーディネータを使用してリカバリできます。永続性コーディネータは、キャッシュ・サービスのスナップショットの作成、アーカイブおよびリカバリの操作を提供するMBeanインタフェース(PersistenceCoordinatorMBean)として公開されています。MBeanを使用するには、JMXをクラスタに対して有効にする必要があります。JMX管理の有効化およびCoherence MBeanへのアクセスの詳細は、JMXの使用によるOracle Coherenceの管理を参照してください。アクティブ永続性では、キャッシュの内容はすべてのミューテーションで自動的に永続化され、内容はクラスタ/サービスの起動時に自動的にリカバリされます。その場合も、永続性コーディネータをアクティブ永続性モードで使用して、オンデマンド・スナップショットを実行できます。

キャッシュ・フェデレーションの構成

フェデレーション・キャッシュ機能は、地理的に分散している複数のクラスタ間で非同期的にキャッシュ・データを結合します。キャッシュ内のデータはクラスタ間で結合され、地理的に異なる場所のアプリケーション・ユーザーに対して冗長性、オフサイト・バックアップおよび複数のアクセス・ポイントを提供します。Coherenceフェデレーションの全詳細は、複数クラスタにわたるキャッシュのフェデレートを参照してください。

Coherenceクラスタ設定ページの「フェデレーション」タブを使用して、フェデレーション・トポロジを有効にし、キャッシュをフェデレートするリモート・クラスタ・メンバーを構成します。トポロジを選択すると、トポロジ構成が自動的に作成され、Default-Topologyという名前が付けられます。フェデレーションは、ローカル・クラスタ・メンバーとリモート・クラスタ・メンバーの両方で構成する必要があります。リモート・クラスタ上のホストを1つ以上提供する必要があります。リモート・クラスタ・メンバー上でカスタム・ポートが使用されている場合は、それに応じてクラスタ・ポートを変更します。フェデレーションの変更を有効にするために、管理対象Coherenceサーバーを再起動する必要があります。CoherenceFederationParamsBean MBeanは、クラスタ・フェデレーション・パラメータも公開し、キャッシュ・フェデレーションを構成するために使用できます。

注意:

- Default-Topologyトポロジ構成が作成され、キャッシュ構成ファイルでフェデレーション・トポロジが指定されていない場合に使用されます。

- フェデレーションの使用時は、ローカル・クラスタとリモート・クラスタの両方で一致するトポロジを構成する必要があります。たとえば、ローカル・クラスタでのトポロジにnoneを、リモート・クラスタでのトポロジとしてactive-activeを選択すると、予期しない動作が発生する可能性があります。同様に、ローカル・クラスタをactive-passiveを使用するよう設定した場合は、リモート・クラスタをpassive-activeを使用するよう設定する必要があります。

管理対象Coherenceサーバーの構成

管理対象Coherenceサーバーは、特定のドメイン用に構成可能ないくつかのクラスタ・メンバー設定を公開します。次のタスクを使用して、管理対象Coherenceサーバーを構成します。

- Coherenceクラスタ・メンバーのストレージ設定の構成

- Coherenceクラスタ・メンバーのユニキャスト設定の構成

- Coherence管理プロキシの削除

- Coherenceクラスタ・メンバーのID設定の構成

- Coherenceクラスタ・メンバーのロギング・レベルの構成

多くの設定では、必要に応じて変更可能なデフォルト値が使用されます。この項に記載されている手順は、管理対象サーバーがすでに作成されて、Coherenceクラスタに関連付けられていることを前提としています。管理対象Coherenceサーバーの作成の詳細は、「スタンドアロンの管理対象Coherenceサーバーの作成」を参照してください

管理対象サーバーの「設定」ページの「Coherence」タブを使用して、Coherenceクラスタ・メンバー設定を構成します。CoherenceMemberConfig MBeanが各管理対象サーバーに対して作成され、Coherenceクラスタ・メンバーのパラメータを公開します。

Coherenceクラスタ・メンバーのストレージ設定の構成

必要に応じて、管理対象Coherenceサーバーのストレージ設定を構成できます。サーバー上でストレージを有効にするということは、サーバーがCoherenceクラスタのプライマリ・データとバックアップ・データの両方の一部を格納することを意味します。データを格納するサーバーは、ストレージが有効なサーバーとして構成されている必要があります。キャッシュ・アプリケーションをホストするサーバーおよびクラスタ・プロキシ・サーバーは、ストレージが無効なサーバーとして構成する必要があり、通常は、データの格納を行いません。共有リソースに問題が生じ、アプリケーションとクラスタのパフォーマンスに影響を及ぼすおそれがあるためです。

注意:

管理対象CoherenceサーバーがWebLogic Serverクラスタのメンバーである場合、WebLogic Serverクラスタで指定されているCoherenceストレージ設定は、サーバー上のストレージ設定をオーバーライドします。ストレージ設定は、サーバー設定がWebLogic Serverクラスタ設定をオーバーライドするという原則の例外です。さらに、最終ランタイムの構成は、コンソールに反映されません。したがって、WebLogic Serverクラスタの「Coherence」タブでストレージが有効化されているにもかかわらず、管理対象Coherenceサーバーでは、ストレージが無効であると表示される場合があります。管理対象Coherenceサーバーのストレージが有効か無効かを判別するには、必ずWebLogic Serverクラスタの設定を確認してください。

「Coherence」タブ上の次のフィールドを使用して、ストレージ設定を構成します。

- ローカル記憶域有効 – このフィールドでは、管理対象Coherenceサーバーがデータを格納するかどうかを指定します。このオプションが選択されない場合、管理対象Coherenceサーバーは、データを格納せず、クラスタ・クライアントと見なされます。

- Coherence Webローカル記憶域有効 – このフィールドでは、管理対象CoherenceサーバーがHTTPセッション・データを格納するかどうかを指定します。Coherenceを使用したセッション・データの格納の詳細は、『Oracle Coherence*WebでのHTTPセッション・マネージメントの管理』を参照してください。

Coherenceクラスタ・メンバーのユニキャスト設定の構成

管理対象Coherenceサーバーは、ユニキャスト(ポイント・ツー・ポイント)通信を使用して相互に通信します。クラスタがマルチキャスト通信を使用するように構成されている場合でも、ユニキャストが使用されます。Coherenceにおけるユニキャストの詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

「Coherence」タブ上の次のフィールドを使用して、ユニキャスト設定を構成します。

- ユニキャスト・リスニング・アドレス – このフィールドでは、サーバーがユニキャスト通信をリスニングするアドレスを指定します。アドレスを指定しない場合、ルーティング可能IPアドレスが自動的に選択されます。アドレス・フィールドでは、クラスレス・ドメイン間ルーティング(CIDR)表記法もサポートされています。この表記法は、正確なIPアドレスを指定するかわりに、バインド先のローカルIPアドレスのサブネットおよびマスク・パターンを使用します。アドレス・フィールドでは、クラスレス・ドメイン間ルーティング(CIDR)表記法もサポートされています。この表記法は、正確なIPアドレスを指定するかわりに、バインド先のローカルIPアドレスのサブネットおよびマスク・パターンを使用します。

- ユニキャスト・リスニング・ポート – このフィールドでは、サーバーがユニキャスト通信をリスニングするポートを指定します。クラスタ・メンバーは、オペレーティング・システムの使用可能なエフェメラル・ポート範囲(値0で示される)から自動で割り当てられる2つのユニキャストUDPポートを使用します。デフォルト値の場合、Coherenceが原因で他のアプリケーションとのポート競合が誤って生じることはありません。ただし、クラスタ・メンバー間でファイアウォールが必要な場合(特殊な構成)、ポートを手動で割り当てることができ、2番目のポートが自動的に選択されます(port1 +1)。

- ユニキャスト・ポートの自動調整 – このフィールドでは、ポートがすでに使用されている場合、ポートを自動的に増分するかどうかを指定します。

Coherence管理プロキシの削除

Coherenceクラスタは、JConsoleやJava VisualVMなど、JMX互換の任意のクライアントから管理できます。管理情報には、実行時統計と操作設定が含まれています。この管理情報はCoherence管理ドメイン固有であり、com.bea管理ドメインの一部としてCoherenceに提供されている管理情報とは異なります。Coherence MBeansの詳細は、Oracle Coherenceの管理を参照してください。

1つのクラスタ・メンバーが管理プロキシとして自動で選択され、他のすべてのクラスタ・メンバーの管理情報を集約する責任があります。その後、管理情報はWebLogicドメインの管理サーバーによって統合され、ドメイン・ランタイムMBeanサーバーを通じて使用できるようになります。そのクラスタ・メンバーが稼働していない場合、別のクラスタ・メンバーが管理プロキシとして自動で選択されます。

管理対象Coherenceサーバーの「Coherence」タブで「Coherence管理ノード」フィールドを使用して、クラスタ・メンバーを管理プロキシとして選択できるかどうかを指定します。デフォルトでは、すべてのクラスタ・メンバーを管理プロキシとして選択できます。そのため、管理プロキシとしての選択からクラスタ・メンバーを除外する場合のみ、オプションの選択を解除します。

実行時にJMXクライアントを使用してドメイン実行時MBeanサーバーに接続します。Coherence管理情報はこのサーバーのCoherence管理ネームスペース内に格納されています。ドメイン実行時MBeanサーバーへの接続の詳細は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』を参照してください。

Coherenceクラスタ・メンバーのID設定の構成

クラスタ内の管理対象CoherenceサーバーにIDを付与するために、一連の識別子が使用されます。ID情報は、クラスタ内でサーバーを区別し、サーバーのロールを伝達するために使用されます。一部のIDは、クラスタ・タスクの実行時にクラスタ・サービスによっても使用されます。最後に、管理情報(JMXなど)を表示する際は、ID情報が役に立ちます。また、ID情報により、ログ・エントリの解釈が容易になります。

「Coherence」タブ上の次のフィールドを使用して、メンバーID設定を構成します。

- サイト名 – このフィールドでは、管理対象Coherenceサーバーをホストしている地理的サイトの名前を指定します。名前が指定されない場合、サーバーのドメイン名が使用されます。WANクラスタリングの場合、この値は、メンバーが存在するデータセンターを識別します。インテリジェントなルーティング、ロード・バランシングおよび障害回復計画(つまり、別の地理的サイトにあるデータの明示的なバックアップ)の基盤として、サイト名を使用できます。サイト名は、分散キャッシングの使用時のデータのバックアップ先や、デフォルト・パーティションの割当て戦略を決定するために役立ちます。最後に、管理情報(JMXなど)を表示したり、ログ・エントリを解釈したりする際は、名前が役に立ちます。

- ラック名 – このフィールドでは、管理対象Coherenceサーバーがホストされている地理的サイト内の場所の名前を指定します。これは多くの場合、ケージ、ラックまたはブレードフレームの識別子です。インテリジェントなルーティング、ロード・バランシングおよび障害回復計画(つまり、別のブレードフレームにあるデータの明示的なバックアップ)の基盤として、ラック名を使用できます。ラック名は、分散キャッシングの使用時のデータのバックアップ先や、デフォルト・パーティションの割当て戦略を決定するために役立ちます。最後に、管理情報(JMXなど)を表示したり、ログ・エントリを解釈したりする際は、名前が役に立ちます。

- ロール名 – このフィールドでは、クラスタにおける管理対象Coherenceサーバーのロールを指定します。ロール名により、アプリケーションは、クラスタ・メンバーを、ストレージが有効、ストレージが無効など、特化したロールに編成することができます。
管理対象CoherenceサーバーがWebLogic Serverクラスタのメンバーである場合、ロール名としてクラスタ名が自動的に使用され、このフィールドを設定することはできません。名前が指定されない場合、使用されるデフォルトのロール名はWebLogicServerです。

Coherenceクラスタ・メンバーのロギング・レベルの構成

各管理対象Coherenceサーバーについてロギング・レベルを構成できます。デフォルトのロギング・レベルはD5で、これはサーバーの「ロギング」タブを使用して変更できます。WebLogic Serverロギングの詳細は、『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理』を参照してください。

管理対象Coherenceサーバーのロギングを構成するには:

1. 「サーバーのサマリー」画面で、管理対象Coherenceサーバーを選択します。

2. サーバーの設定ページで、「ロギング」タブを選択します。

3. 「一般」タブで、「詳細」を選択します。

4. 「プラットフォーム・ロガー・レベル」フィールドに、ロギング・レベルを入力します。

値

表示されるメッセージ

com.oracle.coherence=FINEST

D9

com.oracle.coherence=INFO

D3

値なし

D5 (デフォルト)

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

単一サーバー・クラスタの使用

単一サーバー・クラスタは、単一の管理対象サーバー・インスタンス上で実行するように制限されている、ネットワークにアクセスしないクラスタです。サーバー・インスタンスは、ストレージが有効なクラスタ・メンバー、クライアントおよびプロキシとして機能します。単一サーバー・クラスタは、セットアップが容易で、クラスタを起動および停止するための簡単な方法を提供します。単一サーバー・クラスタは、開発時に使用されます。本番環境またはテスト環境では使用しないでください。

単一サーバー・クラスタを作成する手順は次のとおりです。

- Coherenceクラスタ・リソースの定義 – Coherenceクラスタを作成し、クラスタのメンバーにする管理対象サーバー・インスタンスを選択します。管理サーバー・インスタンスを使用して、容易に設定を行うことができます。

- クラスタ通信の構成 – クラスタを構成し、存続時間の値を0に設定します(マルチキャスト通信を使用している場合)。

- Coherenceクラスタ・メンバーのユニキャスト設定の構成 – 管理対象サーバー・インスタンスを構成し、ユニキャスト・アドレスを、ループバックにルーティングされるアドレスに設定します。ほとんどのコンピュータで、アドレスを127.0.0.1に設定すれば問題ありません。

CoherenceでのWLSTの使用

WebLogic Scripting Tool (WLST)は、Coherenceクラスタの構成と管理などのドメイン構成タスクの自動化に使用できるコマンド行インタフェースです。WLSTの詳細は、『WebLogic Scripting Toolの理解』を参照してください。

readDomain('/ORACLE_HOME/user_projects/domains/base_domain')

WLSTによるCoherenceの設定(オフライン)

WLSTを使用してCoherenceクラスタを設定できます。次の例では、WLSTをオフライン・モードで使用してCoherenceクラスタを作成および構成する方法を示します。この例は、ドメインはすでに作成されており、記載されている順番で実行されることを前提としています。また、この例では、データ層のみが作成されます。その他の層は、必要に応じて作成できます。最後に、この例は、すべてのCoherence MBeanの例を示すことを意図していません。Coherence MBeanの完全なリストは、Oracle WebLogic Server MBeanリファレンスを参照してください。

Coherenceクラスタの作成

create('myCoherenceCluster', 'CoherenceClusterSystemResource')

管理対象Coherenceサーバーの層の作成

create('coh_server1', 'Server')
cd('Server/coh_server1')
set('ListenPort', 7005)
set('ListenAddress', '192.168.0.100')
set('CoherenceClusterSystemResource', 'myCoherenceCluster')

cd('/')
create('coh_server2','Server')
cd('Server/coh_server2')
set('ListenPort', 7010)
set('ListenAddress', '192.168.0.101')
set('CoherenceClusterSystemResource', 'myCoherenceCluster')

cd('/')
create('DataTier', 'Cluster')
assign('Server', 'coh_server1,coh_server2','Cluster','DataTier')
cd('Cluster/DataTier')
set('MulticastAddress', '237.0.0.101')
set('MulticastPort', 8050)

cd('/CoherenceClusterSystemResource/myCoherenceCluster')
set('Target', 'DataTier')

Coherenceクラスタ・パラメータの構成

cd('CoherenceClusterSystemResource/myCoherenceCluster/CoherenceResource/
myCoherenceCluster/CoherenceClusterParams/NO_NAME_0')
set('ClusteringMode', 'unicast')
set('SecurityFrameworkEnabled','false')
set('ClusterListenPort', 7574)

Well Knownアドレスの構成

create('wka_config','CoherenceClusterWellKnownAddresses')
cd('CoherenceClusterWellKnownAddresses/NO_NAME_0')

create('WKA1','CoherenceClusterWellKnownAddress')
cd('CoherenceClusterWellKnownAddress/WKA1')
set('ListenAddress', '192.168.0.100')
cd('../..')

create('WKA2','CoherenceClusterWellKnownAddress')
cd('CoherenceClusterWellKnownAddress/WKA2')
set('ListenAddress', '192.168.0.101')

ロギング・プロパティの設定

cd('/')
cd('CoherenceClusterSystemResource/myCoherenceCluster/CoherenceResource/
myCoherenceCluster')
create('log_config)','CoherenceLoggingParams')
cd('CoherenceLoggingParams/NO_NAME_0')
set('Enabled', 'true')
set('LoggerName', 'com.oracle.coherence')

管理対象Coherenceサーバーの構成

cd('/')
cd('Servers/coh_server1')
create('member_config', 'CoherenceMemberConfig')
cd('CoherenceMemberConfig/member_config')
set('LocalStorageEnabled', 'true')
set('RackName', '100A')
set('RoleName', 'Server')
set('SiteName', 'pa-1')
set('UnicastListenAddress', '192.168.0.100')
set('UnicastListenPort', 0)
set('UnicastPortAutoAdjust', 'true')

cd('/')
cd('Servers/coh_server2')
create('member_config', 'CoherenceMemberConfig')
cd('CoherenceMemberConfig/member_config')
set('LocalStorageEnabled', 'true')
set('RackName', '100A')
set('RoleName', 'Server')
set('SiteName', 'pa-1')
set('UnicastListenAddress', '192.168.0.101')
set('UnicastListenPort', 0)
set('UnicastPortAutoAdjust', 'true')

updateDomain()
closeDomain()

WLSTによるCoherenceキャッシュの保持

WLSTには、ディスクのキャッシュ済データの保持と回復に使用できる一連のコマンドがあります。コマンドは、管理サーバー・ドメインのランタイムMBeanサーバーに接続されている場合に自動で利用できます。Coherenceキャッシュの保持の詳細は、『Oracle Fusion Middleware Oracle Coherenceの管理』を参照してください。

表12-1に、Coherenceキャッシュを保持するためのWLSTコマンドを示します。例12-1で、コマンドの使用を実証します。

表12-1 WLSTのCoherence保持コマンド

コマンド

説明

coh_createSnapshot(snapshotName, serviceName)

サービスのデータ・パーティションをディスクに保持します

- snapshotName – 任意のユーザー定義名

- serviceName – スナップショットが作成されるパーティション化またはフェデレーテッド・キャッシュ・サービスの名前

coh_recoverSnapshot(snapshotName, serviceName)

サービスのデータ・パーティションをディスクから復元します。サービスのキャッシュ内の既存データが失われます。

- snapshotName – 回復するスナップショットの名前

- serviceName – スナップショットが作成されたパーティション化またはフェデレーテッド・キャッシュ・サービスの名前

coh_listSnapshots(serviceName)

使用可能なスナップショットのリストを返します

- serviceName – スナップショットがリストされるパーティション化またはフェデレーテッド・キャッシュ・サービスの名前

coh_validateSnapshot(snapshotDir, verbose)

エラーが発生せずにスナップショットが完了するかどうかを確認します

- snapshotDir – スナップショット名を含むスナップショットのフル・パス。スナップショットのデフォルトの場所はUSER_HOME/coherence/snapshotです。

- verbose – 確認情報の詳細を返します

coh_archiveSnapshot(snapshotName, serviceName)

スナップショットを中央の場所に保存します。場所は、サービスに関連付けられているスナップショット・アーカイバ定義で指定します。

- snapshotName – アーカイブするスナップショットの名前

- serviceName – スナップショットが作成されたパーティション化またはフェデレーテッド・キャッシュ・サービスの名前

coh_retrieveArchivedSnapshot(snapshotName, serviceName)

coh_recoverSnapshotコマンドを使用して回復できるように、アーカイブ済スナップショットを取得します

- snapshotName – 取得するスナップショットの名前

- serviceName – スナップショットが作成されたパーティション化またはフェデレーテッド・キャッシュ・サービスの名前

coh_listArchivedSnapshots(serviceName)

使用可能なアーカイブ済スナップショットのリストを返します

- serviceName – スナップショットが作成されたパーティション化またはフェデレーテッド・キャッシュ・サービスの名前

coh_validateArchivedSnapshot(snapshotName, clusterName, serviceName, achviverName, verbose)

エラーが発生せずにアーカイブ済スナップショットが完了するかどうかを確認します。アーカイバを含む操作オーバーライド構成ファイルがクラスパスで利用できる必要があります。

- snapshotName – 確認するアーカイブ済スナップショットの名前

- clusterName – パーティション化またはフェデレーテッド・キャッシュ・サービスが実行しているクラスタの名前

- serviceName – アーカイブ済スナップショットが作成されたパーティション化またはフェデレーテッド・キャッシュ・サービスの名前

- archiverName – サービスで使用されるスナップショット・アーカイバ定義の名前。

- verbose – 確認情報の詳細を返します

coh_removeArchivedSnapshot(snapshotName, serviceName)

アーカイブ済スナップショットをディスクから削除します

- snapshotName – 削除するアーカイブ済スナップショットの名前

- serviceName – アーカイブ済スナップショットが削除されるパーティション化またはフェデレーテッド・キャッシュ・サービスの名前

coh_removeSnapshot(snapshotName, serviceName)

スナップショットをディスクから削除します

- snapshotName – 削除するスナップショットの名前

- serviceName – スナップショットが削除されるパーティション化またはフェデレーテッド・キャッシュ・サービスの名前

例12-1で、WLSTの永続性APIを使用した、パーティション化キャッシュ・サービスのキャッシュを保持する例を実証します。

例12-1 キャッシュを保持するWLSTの例

serviceName   = '"ExampleGAR:ExamplesPartitionedPofCache"';
snapshotName  = 'new-snapshot'

connect('weblogic','password','t3://machine:7001')

# Must be in domain runtime tree otherwise no MBeans are returned
domainRuntime()

try:
coh_listSnapshots(serviceName)
coh_createSnapshot(snapshotName, serviceName)
coh_listSnapshots(serviceName)
coh_recoverSnapshot(snapshotName, serviceName)
coh_archiveSnapshot(snapshotName, serviceName)
coh_listArchivedSnapshots(serviceName)
coh_removeSnapshot(snapshotName, serviceName)
coh_retrieveArchivedSnapshot(snapshotName, serviceName)
coh_recoverSnapshot(snapshotName, serviceName)
coh_listSnapshots(serviceName)
except PersistenceException, rce:
print 'PersistenceException: ' + str(rce)
except Exception,e:
print 'Unknown Exception' + str(e)
else:
print 'All operations complete'

13 クラスタリングのベスト・プラクティス

この章では、WebLogic Serverクラスタでホストされるアプリケーションのスケーラビリティ、信頼性およびパフォーマンスを最大にする設計およびデプロイメントの推奨プラクティスを紹介します。

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

- 一般的な設計上の考慮事項

- Webアプリケーション設計の考慮事項

- EJB設計の考慮事項

- クラスタでの状態管理

- アプリケーション・デプロイメントの考慮事項

- アーキテクチャに関する考慮事項

- 問題の回避

一般的な設計上の考慮事項

次の項では、クラスタ化されたアプリケーションの一般的な設計上のガイドラインを説明します。

シンプルにする

分散システムは本質的にどうしても複雑になります。さまざま理由から、設計ではシンプルさを第一の目標にしてください。「可動部品」を最小限に抑え、アルゴリズムが複数のオブジェクトに分散しないようにします。

リモート呼出しを最小限にする

リモート呼出しを最小限に抑えると、パフォーマンスが向上し、障害の影響が少なくなります。

セッションFacadeでリモート呼出しが削減される

クライアントまたはサーブレット・コードからEJBエンティティBeanにアクセスしないようにします。そのかわりに、セッションBean (Facadeと呼ばれる)を使用して複雑な対話を内包し、WebアプリケーションからRMIオブジェクトへの呼出しを削減します。クライアント・アプリケーションが直接エンティティBeanにアクセスする場合、各ゲッター・メソッドはリモート呼出しです。セッションFacade BeanはエンティティBeanにローカルでアクセスし、データを構造体に収集して、それを値で戻すことができます。

転送オブジェクトでリモート呼出しが削減される

EJBの実行には、システム・リソースとネットワーク帯域幅が著しく消費されます。このため、EJBはアプリケーションのすべてのオブジェクトの適切な実装になるとは考えられません。

EJBを使用すると、情報と関連するビジネス・ロジックの論理的なグループをモデル化できます。たとえばEJBを使用して、インボイスの項目の論理的な部分集合(割引、払い戻し、税金などの調整が適用される項目群など)をモデル化できます。

一方、インボイスの個々の項目は細かいので、それをEJBとして実装するのはネットワーク・リソースの浪費になります。データ・フィールドの集合のみを表すオブジェクト(getとsetの機能のみを必要とする)は、転送オブジェクトとして実装します。

転送オブジェクト(値オブジェクトまたはヘルパー・クラスとも呼ばれる)は、常に一緒にアクセスされる属性のグループを格納するエンティティをモデル化するのに適しています。転送オブジェクトは、関連する属性をグループ化して複合値を形成するEJB内のシリアライズ可能クラスです。このクラスは、リモート・ビジネス・メソッドの戻り値の型として使用されます。

クライアントは、大まかなビジネス・メソッドを呼び出してこのクラスのインスタンスを受信し、ローカルでその転送オブジェクト内の細かな値にアクセスします。サーバーとの間を1往復するだけで複数の値を取得すると、ネットワーク・トランザクションが削減され、待機時間とサーバー・リソースの使用量が最小限に抑えられます。

分散トランザクションでリモート呼出しが増加する

複数のサーバー・インスタンスにまたがるトランザクションは避けます。分散トランザクションではリモート呼出しが発行され、ネットワーク帯域幅が消費されて、リソース調整のオーバーヘッドが生じます。

Webアプリケーション設計の考慮事項

次の項では、クラスタ化されたサーブレットおよびJSPの設計上の考慮事項について説明します。

インメモリー・レプリケーションを構成する

サーブレットまたはJSPの自動フェイルオーバーを有効にするには、セッション状態をメモリーに保持する必要があります。HTTPセッション状態のインメモリー・レプリケーションを構成する手順は、「HTTPセッション状態のレプリケーションに関する条件」および「インメモリーHTTPレプリケーションの構成」を参照してください。

多重呼出し不変性に留意して設計する

障害か、または性急なユーザーにより、サーブレット・リクエストが重複する場合があります。サーブレットは、リクエストの重複に耐えられるように設計してください。

プログラミングの考慮事項

「クラスタ化されたサーブレットおよびJSPのプログラミング上の考慮事項」を参照してください

EJB設計の考慮事項

次の項では、クラスタ化されたRMIオブジェクトの設計上の考慮事項について説明します。

多重呼出し不変のメソッドを設計する

サーバー・インスタンスでいつ障害が発生したのかを、その障害が発生したときに行われていた処理との関連で判断するのは必ずしも可能ではありません。たとえば、クライアント・リクエストの処理後、レスポンスを戻す前にサーバー・インスタンスで障害が発生した場合は、そのリクエストが処理されたのかを確認する手段がありません。レスポンスを受信していないユーザーは再試行するので、余分なリクエストが発行されることになります。

RMIオブジェクトのフェイルオーバーでは、メソッドが多重呼出し不変でなければなりません。多重呼出し不変のメソッドは、ネガティブな副作用なしに繰り返すことができます。

使用方法および構成のガイドラインに従う

表13-1は、EJBの使用方法と構成のガイドラインを要約したものです。構成可能なクラスタ動作とリソースのリストおよびそれらの構成方法については、表13-2を参照してください。

表13-1 EJBのタイプとガイドライン

オブジェクトの種類

使用方法

構成

全タイプのEJB

EJBを使用すると、情報と関連するビジネス・ロジックの論理的なグループをモデル化できます。「転送オブジェクトでリモート呼出しが削減される」を参照してください

クラスタリング可能なホームを構成します。表13-2を参照してください。

ステートフル・セッションBean

規模が大きく、書込みの多いトランザクションで推奨されます。

EJBコンテナのオーバーヘッドを最小限に抑えるために、ステートフル・セッションBeanは終了時点で削除します。ステートフル・セッションBeanのインスタンスは特定のクライアントと関連付けられ、クライアントによって明示的に削除されるか、タイムアウトでコンテナによって削除されるまでコンテナに留まります。その間、コンテナはアクティブでないインスタンスをディスクにパッシブ化することもあります。その処理はオーバーヘッドを消費し、パフォーマンスに影響します。

注意: まれに、ステートフル・セッションBeanの現在の状態が失われることがあります。たとえば、Beanの関与しているトランザクションがクライアントによってコミットされ、状態の変更がレプリケートされる前にプライマリ・サーバーで障害が起きると、クライアントは以前に格納されていたBeanの状態にフェイルオーバーされます。あらゆる障害シナリオにおいて、Beanの状態の保持が重要な場合は、ステートフル・セッションEJBではなくエンティティEJBを使用します。

クラスタリング可能なホームを構成します。表13-2を参照してください。

EJBのインメモリー・レプリケーションを構成します。表13-2を参照してください。

ステートレス・セッションBean

クライアント単位でインスタンス化され、急激に増加してリソースを消費する可能性のあるステートフル・セッションBeanより、スケーラビリティにおいて優れています。

ホームでステートレスBeanが作成されると、Beanがデプロイされたどのサーバーにでも呼出しを転送できるレプリカ対応スタブが返されます。ステートレスBeanでは状態が保持されないので、スタブではBeanのホストであるどのサーバーにでも呼出しを転送できます。

クラスタリング可能なホームを構成します。表13-2を参照してください。

クラスタ・アドレスを構成します。表13-2を参照してください。

メソッド呼出し時のフェイルオーバーをサポートするように、メソッドを多重呼出し不変であるように構成します(表13-2を参照)。(フェイルオーバーは、メソッド呼出しの間に障害が発生した場合またはメソッドがサーバーに接続できなかった場合のデフォルトの動作です)。

ステートレス・セッションBeanホームのメソッドは、自動的に多重呼出し不変に設定されます。これらについては多重呼出し不変を明示的に設定する必要はありません。

読取り専用エンティティBean

古いデータでも問題ない場合に推奨されます。製品カタログや多くのアプリケーションの内容の大部分に適しています。読取りは、タイマーに基づいて無効化されるローカル・キャッシュに対して実行されます。読取り専用エンティティのパフォーマンスは、トランザクション対応エンティティよりも3 - 4倍高速です。

注意:クライアントは読取り専用エンティティBeanでセッター・メソッドを正常に呼び出すことができますが、データが永続ストアに移動することはありません。

クラスタリング可能なホームを構成します。表13-2を参照してください。

クラスタ・アドレスを構成します。表13-2を参照してください。

メソッドはデフォルトで多重呼出し不変になるよう構成されます。

読み書き対応エンティティBean

リクエストや更新が頻繁に行われることのない共有永続データに最適です。アクセスや更新の負荷が高い場合は、セッションBeanおよびJDBCを検討します。

顧客口座の管理など、高度なデータ一貫性が要求されるアプリケーションで推奨されます。読み書きはすべてデータベースで実行されます。

isModifiedメソッドを使用すると、書込みが少なくなります。

read-mostlyアプリケーション(頻繁に読込みが行われ、更新はまれであるカタログなど)では、読取り専用Beanと読取り専用Beanを拡張する読み書き対応Beanの組合せが適しています。読取り専用Beanでは高速で一貫性の乏しい読込みが行われ、読み書き対応Beanでは一貫性の優れた書込みが行われます。

クラスタリング可能なホームを構成します。表13-2を参照してください。

メソッド呼出し時のフェイルオーバーをサポートするように、メソッドを多重呼出し不変であるように構成します(表13-2を参照)。(フェイルオーバーは、メソッド呼出しの間に障害が発生した場合またはメソッドがサーバーに接続できなかった場合のデフォルトの動作です)。

読取り専用エンティティBeanのメソッドは、自動的に多重呼出し不変に設定されます。

クラスタ関連の構成オプション

表13-2に、クラスタで構成できる主要な動作と関連する構成方法を表示します。

表13-2 クラスタ関連の構成オプション

構成可能な動作またはリソース

構成方法

クラスタリング可能なホーム

weblogic-ejb-jar.xmlでhome-is-clusterable をtrueに設定します。

多重呼出し不変

Beanレベルでは、weblogic-ejb-jar.xmlでstateless-bean-methods-are-idempotentをtrueに設定します。

メソッド・レベルでは、weblogic-ejb-jar.xmlでidempotent-methodsを設定します。

EJBのインメモリー・レプリケーション

weblogic-ejb-jar.xmlでreplication-typeをInMemoryに設定します。

クラスタ・アドレス

クラスタ・アドレスは、クラスタ内の管理対象サーバーを識別します。クラスタ・アドレスは、URLのホスト名部分を構築するためにエンティティBeanおよびステートレスBeanで使用されます。クラスタ・アドレスは明示的に割り当てることも、WebLogic Serverでリクエストごとに自動的に生成することもできます。詳細は、「クラスタ・アドレス」を参照してください

clients-on-same-server

EJBにアクセスするクライアントのすべてが、そのBeanがデプロイされているのと同じサーバー上からアクセスする場合には、weblogic-ejb-jar.xmlでclients-on-same-serverをTrueに設定します。

clients-on-same-serverがTrueの場合、サーバー・インスタンスはデプロイメント時にEJBのJNDI通知をマルチキャストしないため、大きなクラスタの起動時間が短縮されます。

エンティティBeanおよびエンティティEJBのホームのロード・バランシング・アルゴリズム

weblogic-ejb-jar.xmlのhome-load-algorithmでは、EJBホームのレプリカ間でのロード・バランシングに使用するアルゴリズムを指定します。この要素が定義されていない場合は、config.xmlのweblogic.cluster.defaultLoadAlgorithm属性で指定されたアルゴリズムが使用されます。

エンティティEJB、ステートフル・セッションEJB、およびステートレス・セッションのカスタム・ロード・バランシング

weblogic-ejb-jar.xmlのhome-call-router-class-nameを使用すると、これらのタイプのBeanのBeanメソッド呼出しをルーティングするために使用するカスタム・クラスの名前を指定できます。このクラスはweblogic.rmi.cluster.CallRouterを実装する必要があります。詳細は、「WebLogicクラスタのAPI」を参照してください。

ステートレス・セッションBeanのカスタム・ロード・バランシング

weblogic-ejb-jar.xmlのstateless-bean-call-router-class-nameを使用すると、ステートレス・セッションBeanのメソッド呼出しのルーティングに使用するカスタム・クラスの名前を指定できます。このクラスはweblogic.rmi.cluster.CallRouterを実装する必要があります。詳細は、「WebLogicクラスタのAPI」を参照してください。

ステートレス・セッションBeanのクラスタリング可能の構成

weblogic-ejb-jar.xmlでstateless-bean-is-clusterableをtrueに設定すると、EJBをクラスタにデプロイできます。

ステートレス・セッションBeanのロード・バランシング・アルゴリズム

weblogic-ejb-jar.xmlのstateless-bean-load-algorithmを使用すると、EJBホームのレプリカ間でのロード・バランシングに使用するアルゴリズムを指定できます。このプロパティが定義されていない場合は、config.xmlのweblogic.cluster.defaultLoadAlgorithm属性で指定されたアルゴリズムが使用されます。

マシン

WebLogic Serverマシン・リソースは、サーバー・インスタンスとそのインスタンスが動作するコンピュータを関連付けます。詳細は、「マシン名を構成する」を参照してください

レプリケーション・グループ

レプリケーション・グループを使用すると、HTTPセッション状態がどこにレプリケートされるかを制御できます。詳細は、「レプリケーション・グループを構成する」を参照してください

クラスタでの状態管理

WebLogic Serverクラスタの様々なサービスによって、いろいろな種類と程度の状態管理が提供されます。次のリストでは、メモリーまたは永続ストレージでの状態の保持方法によって区別される4つのカテゴリを定義します。

- ステートレス・サービス - ステートレス・サービスは、呼出し間でメモリーを状態に保持しません。

- 会話型サービス - 会話型サービスは、あるセッションの期間中に特定のクライアント専用になります。セッションの期間中、そのクライアントからのリクエストのみをすべて処理します。一般に、セッションの間は、アプリケーション・サーバーがリクエスト間で保持する必要のある状態情報が存在します。通常、会話型サービスはメモリーに一時的なステートを保持します。このステートは障害が発生すると失われる可能性があります。セッション・ステートが呼出しの間に共有の永続ストレージに書き込まれる場合、サービスはステートレスになります。ステートの永続ストレージが必要ない場合は、パフォーマンスとスケーラビリティを向上するために次のような選択肢があります。

- セッション状態を背後でクライアント/サーバー間で往復させることができます。結果として再びステートレス・サービスになります。この方法は、特に大量のデータがある場合には、必ずしも実現可能で望ましいとは限りません。

- より一般的には、リクエスト間でセッション状態をアプリケーション・サーバー上のメモリーに保持することができます。メモリーを解放する必要がある場合は、セッション状態をメモリーからページ・アウトできます。個々の更新はディスクに書き込まれず、サーバーに障害が発生した場合はデータが失われるため、この場合もパフォーマンスとスケーラビリティは向上します。

- キャッシュ済サービス - キャッシュ済サービスはメモリーに状態を保持し、その状態を使用して複数のクライアントからのリクエストを処理します。キャッシュ済サービスの実装は、キャッシュされるデータのコピー同士の一貫性や、バッキング・ストア内の関連データとの一貫性をどの程度維持するかによって異なります。

- シングルトン・サービス - シングルトン・サービスは、実行時にクラスタ内の1つのサーバー上でのみアクティブになり、複数のクライアントからのリクエストを処理します。通常、シングルトン・サービスは、メモリーにキャッシュしたプライベートな永続データによってバックアップされます。メモリーに一時的なステートを保持することもできます。このステートは障害が発生した場合は再生成されるか、または失われます。障害が発生した場合、シングルトン・サービスは同じサーバー上で再起動するか、新しいサーバーに移行する必要があります。

表13-3は、Java EEとWebLogicが各カテゴリのサービスをどのようにサポートしているかをまとめたものです。ステートレス・サービスと会話型サービスは、2つのタイプのクライアントごとに説明されています。

- 疎結合クライアントには、標準のプロトコルを使用してアプリケーション・サーバーと通信するブラウザまたはWebサービス・クライアントが含まれます。

- 密結合クライアントは、アプリケーション層またはクライアント側環境で動作し、独自のプロトコルを使用してアプリケーション・サーバーと通信するオブジェクトです。

表13-3 サービス・タイプごとのJ2EEとWebLogicのサポート

サービス

Java EEのサポート

WebLogic Serverのスケーラビリティと信頼性の機能

疎結合クライアントを使用したステートレス・サービス

すべてのJava EE APIは、ステートレスであるか、または、呼出し間で状態情報を共有永続ストレージに書き込むことでステートレスとして実装できます。

Java EEはロード・バランシングとフェイルオーバーに対する標準を指定していません。疎結合クライアントの場合、ロード・バランシングは外部のIPベースのメカニズムによって実行する必要があります。

WebLogic Serverは、サービスの複数のインスタンスをクラスタにデプロイすることで、ステートレス・サービスの可用性を向上させます。

ステートレス・サービスの疎結合クライアントの場合、WebLogic Serverは外部ロード・バランシング・ソリューションをサポートし、セッション・フェイルオーバーとロード・バランシング用のプロキシ・プラグインを提供します。

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

- ステートレス・セッションBean

- 外部ロード・バランサによるHTTPセッションのロード・バランシング

- プロキシ・プラグインによるロード・バランシング

密結合クライアントを使用したステートレス・サービス

次のJava EE APIは、ステートレス・サービスへの密結合アクセスをサポートします;

- JNDI (初期アクセスの後)

- ファクトリ(EJBホーム、JDBC接続プール、およびJMS接続ファクトリなど)

- ステートレス・セッションBean

- エンティティBean (呼出し間で共有永続ストレージに書き込まれる場合)

WebLogic Serverは、サービスの複数のインスタンスをクラスタにデプロイすることで、ステートレス・サービスの可用性を向上させます。

ステートレス・サービスの密結合クライアントの場合、WebLogic ServerはRMI実装でロード・バランシングとフェイルオーバーをサポートします。

クラスタ化されたRMIオブジェクトに対するWebLogic Serverのレプリカ対応スタブは、オブジェクトに対してサービスと構成済ロード・バランシング・アルゴリズムを現在提供している、クラスタ内のサーバー・インスタンスのリストを示します。WebLogic Serverはスタブを使用して、ロード・バランシングとフェイルオーバーに関する決定を行います。

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

- ステートレス・セッションBean

- EJBとRMIオブジェクトのロード・バランシング

会話型サービス(疎結合クライアント)

次のJava EE APIは、会話型サービスへの疎結合アクセスをサポートします。

- サーブレット

- Webサービス

Java EEはロード・バランシングとフェイルオーバーに対する標準を指定していません。

ロード・バランシングは、外部のIPベースのメカニズム、またはプレゼンテーション層のアプリケーション・サーバーのコードによって実現できます。会話型サービスのプロトコルはステートレスであるため、ロード・バランシングはセッションの作成時にのみ発生します。以降のリクエストは選択したサーバーに固定されます。

WebLogic Serverは次によってセッションの信頼性を向上させます。

- セッション状態のインメモリー・レプリケーションと、クラスタ全体でのプライマリとセカンダリの分散に基づくフェイルオーバー。

- 構成可能なレプリケーション・グループと、セカンダリをホストするための優先レプリケーション・グループの指定機能。

- 外部ロード・バランサまたはプロキシ・プラグインを使用したロード・バランシング。

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

- HTTPセッション状態のレプリケーション

- サーブレットとJSPのロード・バランシング

会話型サービス(密結合クライアント)

Java EE標準はEJBステートフル・セッションBeanを提供して、密結合クライアントでの会話型サービスをサポートします。

WebLogic Serverは次の機能でステートフル・セッションBeanの可用性と信頼性を向上させます。

- キャッシング

- パッシブ化されたBeanの状態の永続ストレージ。

- Beanを作成するためにEJBホームが選択されるときに、最初のロード・バランシングが発生します。レプリカ対応スタブは選択されたサーバーに固定され、セッション・アフィニティを提供します。

- プライマリ/セカンダリ・レプリケーションが有効な場合、スタブはセカンダリを追跡してフェイルオーバーを実行します。

- 更新は、トランザクション境界上でのみ、プライマリからセカンダリに送信されます。

詳細は、「ステートフル・セッションBean」を参照してください

キャッシュ済サービス

Java EEはキャッシュ済サービスに対する標準を指定していません。

Bean管理による永続性を持つエンティティBeanはカスタム・キャッシュを実装できます。

Weblogic Serverは次に対するキャッシングをサポートします。

ステートフル・セッションBean

ステートフル・セッションBeanのスケーラビリティと信頼性を向上させるWebLogic機能のリストについては、上記の行の説明を参照してください。

エンティティBean

WebLogic ServerはエンティティBeanに対する次のキャッシング機能をサポートします。

- 短期間またはトランザクション間のキャッシング

- リレーションシップ・キャッシング

- 組合せキャッシング。同じJava EEアプリケーションに属する複数のエンティティBeanが1つの実行時キャッシュを共有できます。

キャッシュと外部データ・ストアの一貫性は、次により向上させることができます。

- キャッシュのフラッシュ

- 外部データ・ストアの更新後のキャッシュのリフレッシュ

- キャッシュの無効化

- 同時実行性制御

「read-mostlyパターン」

WebLogic Serverは読取り専用EJBと読み書き対応EJBを組み合わせて「read-mostlyパターン」をサポートします。

JSP

WebLogic ServerはカスタムJSPタグを提供して、フラグメント・レベルまたはページ・レベルのキャッシングをサポートします。

シングルトン・サービス

シングルトン・サービスの実装に使用されるJava EE APIは次のとおりです。

- JMS宛先

- JTAトランザクション・マネージャ

- ペシミスティックな同時実行性制御を持つ、キャッシュされたエンティティBean

サービスを複数のインスタンスに「分割」することでスケーラビリティを向上させることができます。各インスタンスはバッキング・データの別々の断片とそれに関連付けられたリクエストを処理します。

シングルトン・サービスの可用性を高めるWebLogic Server機能には次のものがあります。

- 個々のサーバーを障害に対して強くするための、サーバーの複数スレッド・プールのサポート

- 障害が発生したサーバーや不調なサーバーの検出と再起動をサポートするためのヘルス・モニタリングAPIとライフサイクルAPI

- サービスを中断することなくソフトウェアをアップグレードする機能

- JMSサーバーとJTAトランザクション・リカバリ・サービスを移行する機能

アプリケーション・デプロイメントの考慮事項

クラスタリング可能なオブジェクトは、クラスタ内の個別の管理対象サーバーではなくクラスタにデプロイします。詳細および推奨事項は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。

アーキテクチャに関する考慮事項

各種のクラスタ・アーキテクチャ、ロード・バランシング・オプション、およびセキュリティ・オプションについては、「クラスタ・アーキテクチャ」を参照してください。

問題の回避

次の項では、クラスタのプランニングと構成で留意すべき考慮事項を示します。

命名の考慮事項

クラスタのサーバー・インスタンスの命名とアドレッシングのガイドラインについては、「名前とアドレスを識別する」を参照してください

管理サーバーについての考慮事項

クラスタに参加しているWebLogic Serverインスタンスを起動する場合、各管理対象サーバーは、そのクラスタを含むドメインの構成情報を管理している管理サーバーに接続できなくてはなりません。セキュリティ上の理由から、管理サーバーはWebLogic Serverクラスタと同じDMZ内に配置する必要があります。

管理サーバーは、クラスタに参加しているすべてのサーバー・インスタンスの構成情報を保持します。管理サーバー上にあるconfig.xmlファイルには、クラスタ化されているかどうかに関係なく、管理サーバーのドメイン内の全サーバーの構成データが格納されます。クラスタ内のサーバーごとに個別の構成ファイルは作成しません。

クラスタ化されたWebLogic Serverインスタンスが起動するためには、管理サーバーが使用可能になっている必要があります。ただし、いったんクラスタが起動したら、管理サーバーに障害が発生しても実行中のクラスタの動作には影響しません。

管理サーバーをクラスタに参加させないでください。管理サーバーがサーバーの管理(構成データの保持、サーバーの起動と停止、およびアプリケーションのデプロイメントとアンデプロイメント)プロセスだけを受け持つような構成を採ることをお薦めします。管理サーバーにクライアントからのリクエストも処理させると、管理タスクの実行に遅れが生じるリスクが発生します。

管理サーバーをクラスタリングする利点はありません。管理オブジェクトはクラスタリング可能でなく、管理サーバーで障害が発生した場合、他のクラスタ・メンバーにフェイルオーバーされません。管理サーバーにアプリケーションをデプロイすると、サーバーおよびサーバーが提供している管理機能の安定性が損なわれる可能性があります。管理サーバーにデプロイしたアプリケーションが予期しない動作を見せた場合、管理サーバーの動作に影響するおそれもあります。

以上の理由から、管理サーバーのIPアドレスがクラスタ全体のDNS名に含まれていないことを確認してください。

ファイアウォールについての考慮事項

構成にファイアウォールが含まれている場合は、プロキシ・サーバーまたはロード・バランサをDMZに配置し、クラスタ(WebコンテナとEJBコンテナの両方とも)をファイアウォールの背後に配置します。WebコンテナをDMZに配置することはお薦めしません。「プロキシ・アーキテクチャの基本ファイアウォール」を参照してください

複数層アーキテクチャのサーブレット・クラスタとオブジェクト・クラスタの間にファイアウォールを配置する場合は、オブジェクト・クラスタ内のすべてのサーバーをIPアドレスではなく、外部に公開されているDNS名にバインドさせます。サーバーをIPアドレスにバインドさせると、アドレス変換に関する問題が発生し、サーブレット・クラスタが各サーバー・インスタンスにアクセスできなくなる場合があります。

WebLogic Serverインスタンスの内部DNS名と外部DNS名が同じでない場合、サーバー・インスタンスのExternalDNSName属性を使用して、サーバーの外部DNS名を定義します。ファイアウォールの外で、ExternalDNSNameはサーバーの外部IPアドレスに変換されます。WebLogic Server管理コンソールの「サーバー」→「構成」→「全般」ページで、この属性を設定します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「サーバー」>「構成」>「全般」を参照してください。

1つまたは複数のファイアウォールを利用するクラスタ・アーキテクチャでは、すべてのWebLogic ServerインスタンスをIPアドレスではなく、外部に公開されているDNS名を使用して識別することが重要です。DNS名を使用することで、信頼性のないクライアントに対して内部IPアドレスをマスクする場合に使用されるアドレス変換ポリシーに関連する問題を回避できます。

注意:

クライアントがt3およびデフォルト・チャネルを使用してWebLogic Serverにアクセスする場合を除き、ファイアウォールがネットワーク・アドレス変換を実行する構成では、ExternalDNSNameを使用する必要があります。たとえば、ファイアウォールがネットワーク・アドレス変換を実行し、クライアントがプロキシ・プラグインを介してHTTPでWebLogic Serverにアクセスする構成では、ExternalDNSNameが必須です。

図13-1に、WebLogic Serverインスタンスの識別にIPアドレスを使用する場合に発生する可能性のある問題を示します。この図では、ファイアウォールがサブネット「xxx」の外部IPリクエストをサブネット「yyy」の内部IPアドレスに変換します。

図13-1 サーバーがIPアドレスによって識別されるときに変換エラーが発生する可能性がある

次のステップは、接続プロセスと、考えられる障害ポイントについての説明です。

1. クライアントは、205.20.xxx.100:7001にある最初のサーバーへの接続をリクエストしてWebLogic Serverクラスタへのアクセスを開始します。ファイアウォールは、このアドレスを205.20.yyy.100:7001というIPアドレスに変換し、クライアントをそのアドレスに接続します。

2. クライアントは、クラスタ内の3番目のWebLogic Serverインスタンスにある、固定されているオブジェクトCのJNDIルックアップを実行します。オブジェクトCのスタブには、そのオブジェクトのホストになっているサーバーの内部IPアドレス205.20.yyy.300:7001が含まれています。

3. オブジェクトCをインスタンス化しようとする場合、クライアントはIPアドレス205.20.yyy.300:7001を使用してオブジェクトCのホストになっているサーバーへの接続をリクエストします。ファイアウォールはこの接続を拒否します。クライアントが、外部に公開されているサーバーのアドレスではなく、制限されている内部IPアドレスを使用してリクエストしたことが原因です。

外部IPアドレスと内部IPアドレスの間の変換が行われなかった場合は、上記のようなクライアント・リクエストがファイアウォールで問題なく処理されます。ただし、ほとんどのセキュリティ・ポリシーでは内部IPアドレスへのアクセスは拒否されます。

本番環境で使用する前にクラスタのキャパシティを評価する

クラスタのアーキテクチャは、システムのキャパシティに影響します。本番環境で使用するためにアプリケーションをデプロイする前に、パフォーマンスを評価して、実際の運用におけるクライアント負荷を処理するためにサーバーまたはサーバー・ハードウェアを追加する必要があるかどうか、また必要であればどの場所に追加するべきかを判断してください。Mercury InteractiveのLoadRunnerのようなテスト・ソフトウェアを使用すると、多数のクライアントによる利用時の負荷をシミュレートできます。

14 一般的な問題のトラブルシューティング

この章では、クラスタに関連する問題の発生を防ぎ、また問題が起きた場合にそれに対処するためのガイドラインを示します。

IPマルチキャスト構成の問題のトラブルシューティングについては、「マルチキャスト構成のトラブルシューティング」を参照してください。

この章には、次の項が含まれます。

- クラスタを起動する前に

- クラスタ起動後の作業

クラスタを起動する前に

クラスタを起動する前に、問題を防止するためにできることがいくつかあります。

サーバーのバージョン番号のチェック

安定した状態の操作では、クラスタ内のすべてのサーバーが同じメンテナンス・レベル(メジャーおよびマイナー・バージョン番号、パッチ・セット番号、パッチ・セット更新番号、および仮パッチ/個別パッチがすべて同じ)である必要があります。WebLogic Serverでは、次を目的としたローリング・アップグレード(クラスタ内のサーバーへの保守の順次適用)がサポートされています。

- 仮パッチ/個別パッチの適用

- パッチ・セット更新(PSU)の適用

- WebLogic Server 10.3.xパッチ・セットの適用(例: WebLogic Server 10.3.5から10.3.6へのローリング・アップグレード)

通常、クラスタの管理サーバーはクラスタ・メンバーとして構成されませんが、一般には管理対象サーバーと同じ保守レベルを実行する必要があります。場合によっては、管理サーバーが、単一ドメイン内の異なるメンテナンス・レベルの複数クラスタを管理していることがあります。この場合、管理サーバーは、ドメイン内の管理対象サーバーの最も高いメンテナンス・レベルにする必要があります。

マルチキャスト・アドレスのチェック

マルチキャスト・アドレスに関する問題は、クラスタが起動しないか、またはサーバーがクラスタに参加できないことの最も一般的な理由の1つです。

マルチキャスト・アドレスはクラスタごとに必要です。マルチキャスト・アドレスには224.0.0.0から239.255.255.255までの範囲のIPアドレスか、またはその範囲内のIPアドレスを持つホスト名を使用できます。

WebLogic Server管理コンソールの「構成」→「マルチキャスト」ページで、クラスタのマルチキャスト・アドレスとポートを確認できます。

ネットワーク上の各クラスタで、マルチキャスト・アドレスとポートの組み合わせは一意でなければなりません。ネットワーク上の2つのクラスタで同じマルチキャスト・アドレスを使用する場合、それぞれのクラスタのポートは異なっている必要があります。複数のクラスタでマルチキャスト・アドレスが異なっていれば、それらのクラスタで同じポートまたはデフォルトの7001番ポートを使用できます。

クラスタを起動する前に、クラスタのマルチキャスト・アドレスとポートが正しいことと、ネットワーク上の他のクラスタとの間でマルチキャスト・アドレスとポートの組み合わせが重複していないことを確認してください。

マルチキャスト・アドレスが不正な場合に最も起こりやすいエラーには、次のものがあります。

Unable to create a multicast socket for clustering
Multicast socket send error
Multicast socket receive error

CLASSPATHの値のチェック

CLASSPATHの値が、クラスタ内のすべての管理対象サーバー間で一致していることを確認します。CLASSPATHはsetEnvスクリプトによって設定されます。このスクリプトは、startManagedWebLogicを実行して管理対象サーバーを起動する前に実行します。

デフォルトでは、setEnvはCLASSPATHの値を次のように設定します(Windowsシステム上での表現形式)。

set WL_HOME=C:\bea\wlserver_10.00
set JAVA_HOME=C:\bea\jdk131
.
.
set CLASSPATH=%JAVA_HOME%\lib\tools.jar;
%WL_HOME%\server\lib\weblogic_sp.jar;
%WL_HOME%\server\lib\weblogic.jar;
%CLASSPATH%

ある管理対象サーバーでCLASSPATHの値を変更するか、またはsetEnvによるCLASSPATHの設定内容を変更する場合、クラスタ内のすべての管理対象サーバーで同じ変更を行う必要があります。

クラスタ起動後の作業

クラスタの起動後は、次の操作を行って問題のトラブルシューティングを行います。

コマンドのチェック

クラスタが起動できないかまたはサーバーがクラスタに参加できない場合は、まず最初に、startManagedWebLogicのコマンドやjavaインタプリタ・コマンドなどの入力間違いをチェックします。

ログ・ファイルの生成

クラスタ関連の問題についてOracleにお問い合わせになる前に、診断情報を収集してください。最も重要な情報は、管理対象サーバーからの複数のスレッド・ダンプが出力されたログ・ファイルです。ログ・ファイルは特に、クラスタのフリーズやデッドロックを診断する場合に重要です。

複数のスレッド・ダンプが出力されたログ・ファイルは、問題を診断するための前提条件となります。

1. サーバーを停止します。

2. この時点でログ・ファイルがあればすべて削除するか、バックアップします。既存のログ・ファイルに追加書込みを行うよりも、サーバーを起動するたびに新しいログ・ファイルを作成することをお薦めします。

3. 次のコマンドでサーバーを起動します - このコマンドは、詳細ガベージ・コレクションを有効化し、標準エラーと標準出力の両方をログ・ファイルにリダイレクトします。

% java -ms64m -mx64m -verbose:gc -classpath $CLASSPATH
-Dweblogic.domain=mydomain -Dweblogic.Name=clusterServer1
-Djava.security.policy==$WL_HOME/lib/weblogic.policy
-Dweblogic.admin.host=192.168.0.101:7001
weblogic.Server >> logfile.txt

標準エラーと標準出力の両方をリダイレクトすることにより、サーバーの通知メッセージとエラー・メッセージを含む、適切なコンテキストのスレッド・ダンプ情報が得られ、問題を解析しやすくなります。

4. 問題が再発生するまで、クラスタの実行を継続します。

5. サーバーがハングした場合は、kill -3コマンドまたは[Ctrl]-[Break]を使用して、問題を診断するために必要なスレッド・ダンプを作成します。デッドロックの診断を行うには、この作業を各サーバーに対して、約5 - 10秒間隔で何度か行うようにしてください。

6. UNIXユーティリティを使用してログ・ファイルを圧縮します。

% tar czf logfile.tar logfile.txt

または、Windowsのzipユーティリティを使用して圧縮します。

7. Oracleサポートの担当者宛の電子メールに、圧縮したログ・ファイルを添付します。ログ・ファイルをメールの本文にコピー・アンド・ペーストしないでください。

Oracle HotSpot VMスレッド・ダンプの取得

Oracle HotSpot VMを使用する場合は、次のいずれかの方法でスレッド・ダンプを生成します。

- WLSTのthreadDUMPコマンドを使用します。

- jstackユーティリティを使用します。

- LinuxでOracle HotSpot VMを使用している場合は、Kill -3 PIDを使用します。ここで、PIDは、プロセス・ツリーのルートです。
ルートPIDを取得するには、次を実行します。

ps -efHl | grep 'java' **. **

サーバー起動コマンドと一致するプロセス・スタックで見つかる文字列と同じgrep引数を使用します。報告される最初のPIDはルート・プロセスです。その際、psコマンドは別のルーチンにパイプされていないものと見なされます。

Linuxにおいて、各実行スレッドはLinuxプロセス・スタックで独立したプロセスとして扱われます。LinuxでKill -3を使用する場合は、メインのWebLogic実行スレッドのPIDと一致させる必要があり、一致しない場合はスレッド・ダンプは生成されません。

- WindowsでOracle HotSpot VMを使用している場合は、アプリケーション・コンソールで[Ctrl]-[Break]コマンドを使用して、スレッド・ダンプを生成できます。

ガベージ・コレクションのチェック

クラスタで問題が発生している場合、管理対象サーバー上でガベージ・コレクションを確認することも必要です。ガベージ・コレクションに時間がかかりすぎる場合、サーバーが使用可能であることを他のクラスタ・メンバーに通知する定期的なハートビート・シグナルをサーバーから発行できなくなります。

ガベージ・コレクション(最初または2度目の生成)に10秒以上かかる場合、システム上のヒープ割当て(msmxパラメータ)を調整する必要があります。

utils.MulticastTestの実行

管理対象サーバーの1つからutils.MulticastTestを実行して、マルチキャストが機能しているかどうかを確認できます。『Oracle WebLogic Serverコマンド・リファレンス』のOracle WebLogic Server Javaユーティリティの使用に関する項を参照してください。

15 マルチキャスト構成のトラブルシューティング

この章では、IPマルチキャスト構成の問題を解決するためのヒントを提供します。IPマルチキャストを使用すると、クラスタ内の複数のWebLogic Serverインスタンスで、単一のIPアドレスとポート番号を共有できます。この機能により、クラスタのすべてのメンバーを単一のエンティティとして扱うことができ、クラスタのメンバー間の通信が可能になります。

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

- マルチキャスト・アドレスおよびポートの構成の検証

- ネットワーク構成の問題の特定

- MulticastTestユーティリティの使用

- マルチキャスト機能のチューニング

- マルチキャストのデバッグ

- その他の問題

- マルチキャスト構成のトラブルシューティングに関するその他のリソース

クラスタ内でのマルチキャストの使用および構成については、「クラスタの構成とconfig.xml」を参照してください

マルチキャスト・アドレスをコンソールから構成する方法は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「クラスタ: 構成: マルチキャスト」を参照してください。

クラスタの一般的なトラブルシューティングについては、「一般的な問題のトラブルシューティング」を参照してください。

マルチキャスト・アドレスおよびポートの構成の検証

マルチキャストで問題が発生した場合のトラブルシューティングは、まずマルチキャストのアドレスとポートが正しく構成されているかどうかの検証から始めます。マルチキャスト・アドレスは、クラスタごとに正しく構成されている必要があります。

クラスタが起動しなかったり、サーバーがクラスタに参加できなかったりする場合、最も一般的な原因の1つが、このマルチキャスト・アドレスおよびポートの構成の問題です。マルチキャスト・アドレスについては、次の点を考慮に入れてください。

- マルチキャスト・アドレスとして使用できるのは、224.0.0.0から239.255.255.255までの範囲のIPアドレスか、またはその範囲内のIPアドレスを持つホスト名のみです。

- WebLogic Serverで使用されるデフォルトのマルチキャスト・アドレスは、239.192.0.0です。

- x.0.0.1 (xは0 - 9の数字)というマルチキャスト・アドレスはいずれも使用できません。

起こり得るエラー

マルチキャスト構成の問題により、一般的に次のタイプの問題が発生します。

- クラスタリングのためのマルチキャスト・ソケットを作成できない

- マルチキャスト・ソケットの送信エラー

- マルチキャスト・ソケットの受信エラー

マルチキャスト・アドレスおよびポートの確認

マルチキャスト・アドレスおよびポートを確認するには、次のいずれかを行います。

- WebLogic Server管理コンソールを使用して、クラスタのマルチキャスト・アドレスとポートを確認します。

- config.xml内の<cluster>要素のマルチキャスト情報を確認します。

ネットワーク構成の問題の特定

マルチキャスト・アドレスおよびポートが正しく構成されていることが確認できたら、ネットワークの問題が原因でマルチキャスト通信が不通になっていないかを検証します。

物理的な接続

ネットワーク内に物理的な問題がないか確認します。

- クラスタ内のサーバーをホストする各マシンのネットワーク接続を確認します。

- ネットワークのすべてのコンポーネント(ルーター、DNSサーバーを含む)が正しく接続され、正しく機能していることを確認します。

アドレスの競合

ネットワーク内でアドレスが競合していると、マルチキャスト通信が不通になる場合があります。

- netstatユーティリティを使用して、そのクラスタ・マルチキャスト・アドレスが他のネットワーク・リソースによって使用されていないことを確認します。

- 各マシンのIPアドレスが一意になっていることを確認します。

UNIXシステムのnsswitch.confの設定

UNIXシステムでは、UnkownHostExceptionsエラーが発生する場合があります。このエラーは、サーバーに過大な負荷がかかっていないときでも不定期に発生する可能性があります。このエラーを回避するには、/etc/nsswitch.conf を確認し、その順序を「files,DNS,NIS」に変更します。

詳細は、使用しているシステムのnsswitch.confのmanページを参照してください。

MulticastTestユーティリティの使用

マルチキャスト・アドレスおよびポートが正しく構成されており、ネットワークに物理的な問題や構成の問題がないことを確認できたら、utils.MulticastTestを使用してさらに検証します。このユーティリティを使用すると、マルチキャストが機能しているかどうかを検証したり、クラスタ間で不必要なトラフィックが発生していないかを確認したりできます。

MulticastTestユーティリティの使用の詳細は、『Oracle WebLogic Serverコマンド・リファレンス』のOracle WebLogic Server Javaユーティリティの使用に関する項にあるMulticastTestを参照してください。

MulticastTestがうまく機能せず、そのマシンがマルチホームである場合は、プライマリ・アドレスが使用されているかどうかを確認してください。詳細は、「マルチキャストとマルチホーム・マシン」を参照してください

注意:

デュアルIPv4/IPv6スタックを実行しているLinuxマシン上でマルチキャスト・アドレスについてIPv4形式のアドレスを指定する場合は、-Djava.net.preferIPv4Stack=trueを設定してください。

マルチキャスト機能のチューニング

次の項では、WebLogic Serverで使用できる様々なマルチキャスト機能をチューニングする方法について説明します。

マルチキャスト・タイムアウト

マルチキャスト・タイムアウトは、ネットワーク・インタフェース・カード(NIC)がフェイルオーバーする際に発生します。タイムアウトが発生すると、次のようなエラー・メッセージが生成されます。

<Error><Cluster><Multicast socket receive error:
java.io.InterruptedIOException: Receive timed out>

このエラーが発生した場合は、次を行うことができます。

- NICのフェイルオーバーを無効にします。

- igmp snoopingスイッチを無効にします。このスイッチは、IGMP (Internet Group Management Protocol)の一部で、管理対象スイッチでのマルチキャストのフラッディングを回避するために使用します。

- Windows 2000の場合は、IGMPのレベルをチェックして、マルチキャスト・パケットがサポートされていることを確認します。

- マルチキャスト存続時間を次のように設定します。

MulticastTTL=32

詳細は、「マルチキャスト存続時間(TTL)を構成する」を参照してください。

クラスタ・ハートビート

WebLogic Serverでは、クラスタ内の個々のサーバー・インスタンスが使用可能であることを通知するために、マルチキャストを使用して定期的にハートビート・メッセージがブロードキャストされます。クラスタ内のサーバー・インスタンスは、ハートビート・メッセージをモニターすることにより、どの時点でサーバー・インスタンスに障害が発生したかを特定します。

次の項では、クラスタのハートビートに問題が発生した場合の解決策について説明します。

マルチキャスト送信遅延

マルチキャスト送信遅延は、サーバーがマルチキャストを使用してメッセージ・フラグメントを送信するために待機する時間を示します。これにより、OSレベルのバッファ・オーバーフローを回避できます。マルチキャスト送信遅延は、クラスタMBeanのMulticastSendDelay属性で設定できます。詳細は、Oracle WebLogic Server MBeanリファレンスを参照してください。

オペレーティング・システム・パラメータ

マルチキャスト送信遅延を設定した後も問題が発生する場合は、UDP設定に関係する次のオペレーティング・システム・パラメータの設定が必要になることがあります。

- xdp_xmit_hiwat

- udp_recv_hiwat

これらのパラメータが低い値(たとえば8K)に設定されている場合は、マルチキャスト・パケットのサイズが最大値(32K)に設定されていると問題が発生する可能性があります。これらのパラメータを64Kに設定してみてください。

マルチキャスト・ストーム

マルチキャスト・ストームとは、マルチキャスト・パケットがネットワーク上で繰返し転送される現象です。マルチキャスト・ストームが発生すると、ネットワークとそのネットワークに接続されているステーションに負荷がかかり、末端のステーションでハングや障害が発生するおそれがあります。

マルチキャスト・バッファのサイズを増やすと、通知が送信および受信されるレートが改善されて、マルチキャスト・ストームを防止できます。「マルチキャスト・バッファのサイズを構成する」を参照してください

マルチキャストとマルチホーム・マシン

マルチホーム環境内でマルチキャストを使用する場合は、次の点を考慮に入れてください。

- WebLogic Server管理コンソールからUnixMachineのインスタンスを構成し、マルチキャスト・トラフィックを処理するために各サーバー・インスタンスのInterfaceAddressを指定する必要があります。

- /usr/sbin/ifconfig -aを実行して、マルチホーム環境内の各マシンのMACアドレスを確認します。各マシンのMACアドレスは、必ず一意のアドレスにしてください。複数のマシンが同じMACアドレスを使用していると、マルチキャストに問題が生じる可能性があります。

別々のサブネットでのマルチキャスト

クラスタ・メンバーが別々のサブネットに配置されているケースでマルチキャストで問題が発生した場合は、マルチキャスト存続時間を構成する必要があります。クラスタのマルチキャスト存続時間パラメータの値は、マルチキャスト・パケットが最終的な宛先に届くまでにルーターがパケットを破棄しないような大きさにする必要があります。

マルチキャスト存続時間パラメータには、パケットが破棄されるまでにマルチキャスト・メッセージが経由できるネットワーク・ホップ数を設定します。マルチキャスト存続時間パラメータを適切に設定することにより、クラスタ内のサーバー・インスタンス間で送受信されるマルチキャスト・メッセージが消失するリスクが少なくなります。

詳細は、「マルチキャスト存続時間(TTL)を構成する」を参照してください。

マルチキャストのデバッグ

これまでに説明したトラブルシューティングのヒントを実行してもマルチキャスト・アドレスの問題が解決しない場合は、マルチキャストのデバッグ情報を収集します。

デバッグ・ユーティリティ

次のユーティリティを使用して、マルチキャスト構成の問題をデバッグできます。

MulticastMonitor

MulticastMontiorは、特定のマルチキャスト・アドレスおよびポートのマルチキャスト・トラフィックをモニターするスタンドアロンJavaコマンド行ユーティリティです。このコマンドの構文は次のとおりです。

java weblogic.cluster.MulticastMonitor <multicast_address> <multicast_port> <domain_name> <cluster_name>

MulticastTest

MulticastTestユーティリティは、WebLogicクラスタの構成時にマルチキャストに関する問題をデバッグする場合に便利です。このユーティリティは、マルチキャスト・パケットを送信し、ネットワーク上で、マルチキャストがどのくらい効果的に機能しているかについての情報を返します。

デバッグ・フラグ

次のデバッグ・フラグは、マルチキャスト専用です。

- DebugCluster

- DebugClusterHeartBeats

- DebugClusterFragments

コマンド行でデバッグ・フラグを設定する

これらのフラグをコマンド行から設定する場合は、サーバーの起動時に次のオプションを追加します。

- -Dweblogic.debug.DebugCluster=true

- -Dweblogic.debug.DebugClusterHeartBeats=true

- -Dweblogic.debug.DebugClusterFragments=true

WLSTを使用したデバッグ属性の設定

次のWLSTコマンドを使用してデバッグ属性を設定します。

connect()
edit()
startEdit()
servers=cmo.getServers()
for s in servers:
d=s.getServerDebug()
d.setDebugCluster(true)
activate()

その他の問題

次の項では、マルチキャストで発生する可能性のあるその他の問題について説明します。

AIXでのマルチキャスト

AIXバージョン5.1では、IPv4でマッピングされたマルチキャスト・アドレスはサポートされません。IPv4マルチキャスト・アドレスを使用している場合は、IPv6に切り替えてもマルチキャスト・グループに参加できません。AIXでMulticastTestを実行する場合は、次の例に従ってコマンド行からコマンドを入力してください。

java -Djava.net.preferIPv4Stack=true utils.Multicast <options>

また、クラスタの動作を正しく構成するため、AIXの次の設定も確認してください。

- 次のコマンドを実行してからマシンを再起動することで、MTUサイズを1500に設定します。

chdev -1 lo0 -a mtu=1500 -P

- /etc/netsvc.conf:に次の行が追加されていることを確認します。

hosts=local,bind4

この行は、IPを解決するためのネーム・サービスに、IPv4アドレスのみが送信されるようにするために必要です。

ファイル記述子の問題

オペレーティング・システムによっては、開かれているファイル記述子の数が問題になる場合があります。UNIXでは、losesを使用して、1つのプロセスがディスク上のファイルをいくつ開いているかを確認できます。この問題が発生した場合は、マシン上のファイル記述子の数を増やすことを検討してください。

マルチキャスト構成のトラブルシューティングに関するその他のリソース

次のリソースがマルチキャストの問題の解決に役立つ可能性があります。

- Oracle Fusion Middlewareリリース・ノート for Microsoft Windows

- Oracleサポート: https://support.oracle.com/

- Oracleフォーラム: http://forums.oracle.com/

A WebLogicクラスタのAPI

この付録ではWebLogicクラスタAPIの使用方法を説明します。

この付録では、以下について説明します。

- APIの使用方法

- カスタム呼出しルーティングと連結の最適化

APIの使用方法

WebLogicクラスタの公開APIは、単一インタフェースweblogic.rmi.cluster.CallRouterに含まれています。

Class java.lang.Object
Interface weblogic.rmi.cluster.CallRouter
(extends java.io.Serializable)

パラメータ・ベースのルーティングを可能にするには、このインタフェースを実装するクラスをRMIコンパイラ(rmic)に与える必要があります。次のオプション(1行に入力する必要があります)を使用して、サービス実装時にrmicを実行します。

$ java weblogic.rmic -clusterable -callRouter
<callRouterClass> <remoteObjectClass>

リモート・メソッドが呼び出されるたびに、クラスタリング可能なスタブからコール・ルーターを呼び出します。コール・ルーターは、その呼出しの宛先のサーバーの名前を返します。

クラスタ内の各サーバーは、WebLogic Serverコンソールで定義された名前で一意に識別されます。これらは、メソッド・ルーターがサーバーの識別のために使用する必要がある名前です。

例: fooというメソッドでリモート・インタフェースExampleを実装する、ExampleImplクラスを考えます。

public class ExampleImpl implements Example {
public void foo(String arg) { return arg; }
}

このCallRouterを実装したExampleRouterでは、'arg' < "n"の場合にすべてのfoo呼出しがserver1 (server1が到達不能な場合はserver3)に送られ、'arg' >= "n"の場合にすべての呼出しがserver2 (server2が到達不能な場合はserver3)に送られます。

public class ExampleRouter implements CallRouter {
private static final String[] aToM = { "server1", "server3" };
private static final String[] nToZ = { "server2", "server3" };

public String[] getServerList(Method m, Object[] params) {
if (m.GetName().equals("foo")) {
if (((String)params[0]).charAt(0) < 'n') {
return aToM;
} else {
return nToZ;
}
} else {
return null;
}
}
}

次のrmic呼出しは、ExampleRouterとExampleImplを関連付けて、パラメータ・ベースのルーティングを有効にします。

$ rmic -clusterable -callRouter ExampleRouter ExampleImpl

カスタム呼出しルーティングと連結の最適化

オブジェクトがレプリカを呼び出している同じサーバー・インスタンス上にレプリカがある場合、ローカル・レプリカを使用する方が効率的であるため、そのコールはロード・バランシングの対象にはなりません。詳細は、「連結されたオブジェクトの最適化」を参照してください

B クラスタに関するBIG-IPハードウェアの構成

F5 BIG-IPコントローラをWebLogic Serverクラスタで動作するように構成する設定と管理手順の詳細は、http://www.f5.com/でF5製品のドキュメントを参照してください。

WebLogic Serverが外部ロード・バランサとどのように機能するかについては、「外部ロード・バランサによるHTTPセッションのロード・バランシング」を参照してください。

C MAN/WANフェイルオーバーに関するF5ロード・バランサの構成

この付録では、F5ハードウェア・ロード・バランサを構成する方法を説明します。

WebLogic Serverでは、MANおよびWANネットワーク内でフェイルオーバー機能が提供されています。広範囲な地理的領域にまたがってフェイルオーバーを行うことによって、信頼性を高めることができます。複数のWebLogic Serverドメインにまたがってフェイルオーバーを行うこともできます。

MAN/WAN環境でフェイルオーバー機能を実装するには、ハードウェア・ロード・バランサを使用する必要があります。ここでは、F5ハードウェア・ロード・バランサがWebLogic Serverとともに機能するように構成する手順の概要を示します。

WebLogic ServerでMAN/WANを使用するように構成する方法は、「MAN/WAN内のクラスタ間でのセッション状態レプリケーション」を参照してくださいF5ハードウェア・ロード・バランサの構成の詳細は、http://www.f5.comを参照してください。

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

- 要件

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

- 3-DNSグローバル・ハードウェア・ロード・バランサの構成

- WebLogic Serverコンポーネントの構成

要件

この付録で説明する手順を実行する前に、次が実行済であることが必要です。

- WebLogic Server環境をインストールおよび構成済。これには、クラスタおよび管理対象サーバーの作成および構成が含まれます。

- 少なくとも1つのF5 3-DNSグローバル・ロード・バランサと2つのF5 BIG-IPローカル・ロード・バランサをインストールおよび構成済。これは、MAN/WAN環境でフェイルオーバー機能を実装するための最低限のハードウェア要件です。

- 現在のネットワークおよびDNSが正常に構成されていることを確認済。

これらの要件が満たされている場合、次の手順を実行して、ロード・バランサがMAN/WAN環境内で機能するように構成します。

ローカル・ロード・バランサの構成

この項では、F5ローカル・ロード・バランサがMAN/WAN環境内でWebLogic Serverとともに機能するように構成する手順について説明します。

仮想サーバーのIPおよびプール

各ローカル・ロード・バランサで2つの仮想サーバーIP、1つのマルチレイヤー・プールおよび1つのフェイルオーバー・トリガー・プールを構成する必要があります。図C-1は、これらのプールと仮想サーバーIPがMAN/WAN環境で機能する方法を示します。

図C-1 MAN/WAN環境におけるハードウェア・ロード・バランサ

この図では、複数の管理対象サーバーが、物理的に離れた場所に分散されています。この図は、個々の管理対象サーバーを示していますが、クラスタリング構成も表しています。

各ローカル・ロード・バランサは、マルチレイヤー・プールを参照する仮想サーバーIPを持ちます。マルチレイヤー・プールは、各ローカルWebLogic Server IPアドレス、ホスト名、およびフェイルオーバー・トリガー・プールの仮想サーバーを参照します。フェイルオーバー・トリガーは、サイトが停止していることを示すために使用されます。このトリガーは、他のローカル・ロード・バランサにフェイルオーバーします。

次の項では、マルチレイヤー・プールおよびフェイルオーバー・トリガー・プールを構成する方法について説明します。

フェイルオーバー・トリガーの仮想サーバーおよびプールの作成

ロード・バランシング対象のローカルWebLogic Serverのホスト名およびポートをそれぞれ参照するローカル・ロード・バランサでBIG-IPプールを作成します。次に、このプールを指定する仮想サーバーを新規に作成します。この仮想サーバーは3-DNSグローバル・ロード・バランサによってヘルス・モニタリングに利用され、後で、別のローカル・ロード・バランサのプールおよび仮想サーバー内に組み込まれます。

1. BIG-IPのナビゲーション・パネル内で、「Pools」をクリックします。

2. プール名を追加します。

3. ロード・バランシング対象のWebLogicサーバーのhost:portの組合せをすべて追加します。
デフォルトの優先度を使用できます。セッション永続性は、構成する必要はありません。

4. BIG-IPのナビゲーション・パネル内で、「Virtual Servers」をクリックします。

5. 新しいプールを参照する仮想サーバーを追加します。

a. フェイルオーバー・トリガー・ポートとなるポートを指定する必要があります(17001など)。

b. 仮想サーバーのIPアドレスを指定します(10.254.34.151など)。

マルチレイヤーの仮想サーバーおよびIPプールの作成

F5管理ユーティリティを使用して、ローカルWebLogicサーバー・インスタンスのホスト、ポート、およびフェイルオーバー・トリガーの仮想サーバーをそれぞれ参照するローカル・ロード・バランサでBIG-IPプールを新規作成します。フェイルオーバー・トリガーの仮想サーバーは、WebLogicサーバーより優先度を低くする必要があります。低い優先度を割り当てることによって、フェイルオーバー・トリガーの仮想サーバーは、すべてのWebLogicサーバーで障害が発生しないかぎり、クライアントのリクエストを受け取ることはありません。セッションの永続性も構成する必要があります。

1. BIG-IPのナビゲーション・パネル内で、「Pools」をクリックします。

2. プール名を追加します(たとえば、multilayeredPool)。

a. ロード・バランシング対象のWebLogicサーバーのhost:portの組合せをすべて追加します。host:portの組合せはすべて、priority=10で構成する必要があります。

b. priority=1のフェイルオーバー・トリガーの仮想サーバーを追加します。

c. プールの永続性の属性を指定します(挿入モードでアクティブ)。

d. BIG-IPのナビゲーション・パネル内で、「Virtual Servers」をクリックします。

3. 新しいプールを参照する仮想サーバーを作成します(10.254.34.151:7001など)。

3-DNSグローバル・ハードウェア・ロード・バランサの構成

認証DNSサーバーとして機能し、選択した条件に基づいて複数のBIG-IP仮想サーバーに対してWebリクエストを分散できるネットワーク・ハードウェアのグローバル・ロード・バランサの一種です。クライアントはhttpリクエストをグローバル・ロード・バランサに送信しますが、グローバル・ロード・バランサでは、組込みのヘルス・モニターが使用され、選択したロード・バランシング方法に基づいてWebリクエストが最適なサーバーに送信されます。

通常のDNSサーバーはグローバル・ロード・バランサが実行できることをモニターできないため、グローバル・ロード・バランサは、DNSの信頼できるソースである必要があります。通常のDNSサーバーは、デフォルトのラウンドロビン・ロード・バランシング方法において次の順番にあるサーバーが停止している場合でも、そのサーバーにhttpリクエストを送信します。通常のDNSサーバーの複数の短所を補うために、F5などの多くのベンダーは、DNS解決のみでなく、ネットワーク・トラフィックのインテリジェント・ルーティングも実行可能な専用のハードウェアおよびソフトウェアを作成しています。

F5の3-DNSグローバル・ロード・バランサの主な構成手順は次のようになります。DNS名を定義し、BIG-IPホストを構成し、データ・センターを構成し、複数の仮想サーバー(VIP)へのタスクの3-DNS分散を構成します。これらの手順については、以降の節で説明します。

DNSゾーンの構成

グローバル・サーバー・ロード・バランサは、自身のDNSゾーンを管理するように構成する必要があります。これには、ローカルのDNS管理マシン上に新しい委任を作成します。次の手順は、DNSゾーンを構成する方法を示しています。

1. DNS管理マシン上で、新しい委任(gslbなど)を作成します。

2. ネーム・サーバーとして3-DNSマシンの完全修飾名を指定します。

3. ネーム・サーバーとして3-DNSマシンのIPアドレスを指定します。

3-DNSによって管理されるBIG-IPアドレスの構成

3-DNSグローバル・バランサは、BIG-IPローカル・ロード・バランサのアドレスを使用して構成する必要があります。次の手順は、BIG-IPアドレスを構成する方法の概要を示しています。

1. 3-DNSのナビゲーション・パネルで、「Servers」、「BIG-IP」の順にクリックします。

2. BIG-IPを追加します

3. BIG-IPボックスの名前およびそのIPアドレスを指定します。

4. BIG-IPボックスのリストを再度表示すると、各BIG-IPボックスで利用可能な仮想サーバーの数が含まれた列が3-DNSデバイスで表示されます。仮想サーバーのこの数をクリックします。

5. マルチレイヤーの仮想サーバーを検索し、依存関係をクリックします。

6. 依存関係として、関連フェイルオーバー・トリガーの仮想サーバーを指定します。

データ・センターの構成

多くの場合、グローバル・ロード・バランサは、複数の物理的なサイトにある仮想サーバーにサービス・リクエストを分散します。これらのサイトはデータ・センターと呼ばれ、データ・センターは2つ作成する必要があります。データ・センターは、BIG-IPローカル・ロード・バランサの2つの異なるサブネットに解決します。

ワイドIPの構成

3-DNSデバイスが一方のデータ・センター内の1つのVIP内の複数のサーバーに均等にリクエストを分散するように構成することが推奨されます。これらのサーバーで障害が発生すると、もう一方のデータ・センターのVIPにリクエストを送信できません。均等にリクエストを分散するためには、ワイドIPアドレスを作成する必要があります。このワイドIPアドレスは、クライアント・リクエストのターゲットとなり、完全修飾ドメイン名が与えられます。ワイドIPによって、ローカル・ロード・バランサの複数の仮想サーバーに接続が分散される方法が定義されます。

次の手順は、ワイドIPを構成する方法を示しています。

1. 3-DNSのナビゲーション・パネルで、「Wide IPs」、「Add Wide IP」の順にクリックします。

2. ワイドIPに利用できるネットワーク・アドレス、ワイドIPのポート(7001など)、および、関連する完全修飾ドメイン名(cs.gslb.bea.comなど)を指定します。

3. ローカル・ロード・バランサ上の仮想サーバーを指定する3-DNSプールを追加します。3-DNSグローバル・ロード・バランサは、BIG-IPホストを構成すると、各ローカル・ロード・バランサで利用可能な仮想サーバーを自動的に識別します。マルチレイヤーの仮想サーバーを指定します。

4. DNSネーム・サーバー上のDNSデータベースに、wideipに解決する2つのエントリを作成します。

WebLogic Serverコンポーネントの構成

F5デバイスを構成したら、WebLogic ServerでMAN/WANフェイルオーバー機能を使用するように構成する必要があります。WebLogic ServerでMAN/WANを使用するように構成する方法は、「MAN/WAN内のクラスタ間でのセッション状態レプリケーション」を参照してください

D MAN/WANフェイルオーバーに関するRadwareロード・バランサの構成

この付録では、Radwareハードウェア・ロード・バランサを構成する方法を説明します。

WebLogic Serverでは、MANおよびWANネットワーク内でフェイルオーバー機能が提供されています。広範囲な地理的領域にまたがってフェイルオーバーを行うことによって、信頼性を高めることができます。複数のWebLogic Serverドメインにまたがってフェイルオーバーを行うこともできます。

MAN/WAN環境でフェイルオーバー機能を実装するには、ハードウェア・ロード・バランサを使用する必要があります。ここでは、Radwareハードウェア・ロード・バランサがWebLogic Serverとともに機能するように構成する手順の概要を示します。

WebLogic ServerでMAN/WANを使用するように構成する方法は、「MAN/WAN内のクラスタ間でのセッション状態レプリケーション」を参照してくださいRadwareハードウェア・ロード・バランサの構成の詳細は、http://www.radware.comを参照してください。

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

- 要件

- ステップ1: 信頼できる委任ゾーンの構成

- ステップ2: ファームの仮想IPおよびサーバーの構成

- ステップ3: ポートの多重化の構成

- ステップ4: HTTPリダイレクトの構成

- ステップ5: セッションIDの永続性の構成

- ステップ6: LRPの構成

- ステップ7: WebLogic Serverコンポーネントの構成

要件

この付録で説明する手順を実行する前に、次が実行済であることを確認します。

- WebLogic Server環境をインストールおよび構成済。これには、クラスタおよび管理対象サーバーの作成および構成が含まれます。

- 少なくとも2つのRadware Web Server Directorロード・バランサをインストールおよび構成済。これは、MAN/WAN環境でRadwareデバイスを使用するための最低限のハードウェア要件です。この2つのうち少なくとも1つをグローバル・ロード・バランサとして構成する必要があります。

- 現在のネットワークおよびDNSが正常に構成されていることを確認済。

これらの要件が満たされている場合、次の手順を実行して、ロード・バランサがMAN/WAN環境内で機能するように構成します。

ステップ1: 信頼できる委任ゾーンの構成

Web Server Directorの構成の最初の手順は、ローカルDNS内に信頼できる委任ゾーンを作成することです。これを行うには、Radware管理ユーティリティで次の手順を実行します。

1. ローカルDNSの名前をクリックします。

2. 「New Delegation」をクリックします。

3. 新しい委任ゾーンの名前を入力します。

4. 各RadwareデバイスのIPアドレスを追加します。

ステップ2: ファームの仮想IPおよびサーバーの構成

Web Server Directorは、サーバー・ファーム内の複数のサーバー間で負荷を調整します。クライアントは、仮想IPアドレスを使用してサーバーにアクセスします。Web Server Directorは、この仮想IPアドレスから適切なサーバーにトラフィックを導きます。次の項では、サーバー・ファームの仮想IPを作成および構成する方法について説明します。

ファームIPの作成

ファームIPを作成するには、Radware管理ユーティリティで次の手順を実行します。

1. 「WSD」を選択します。

2. 「Farms」を選択します。

3. 「Farm Table」を選択します。

4. 「Create a Farm」をクリックします。

5. このファームのIPアドレスおよびDNS別名を入力します。

6. 「Admin Status」が有効化されていることを確認します。

7. 「Set」をクリックします。

サーバー・ファームのディスパッチ・メソッドの構成

サーバー・ファームのディスパッチ・メソッドを構成するには、Radware構成ユーティリティで次の手順を実行します。

1. 「WSD」を選択します。

2. 「Farms」を選択します。

3. 「Farm Table」を選択します。

4. 構成するファームを選択します

5. 「Farm Properties」ウィンドウで、「Dispatch Method」の横にあるメニューを選択します。

6. 希望するアルゴリズムを選択します。

7. 「Set」をクリックします。

ファーム・サーバーの作成

ファーム・サーバーを構成するには、Radware管理ユーティリティで次の手順を実行します。

1. 「WSD」を選択します。

2. 「Servers」を選択します。

3. 「Application Servers」を選択します。

4. 上の手順で作成したファームIPを選択します。

5. サーバーのIPアドレスを追加します。

6. サーバー名を追加します。

7. 「Admin Status」が有効化されていることを確認します。

ステップ3: ポートの多重化の構成

次の手順を実行して、ポートの多重化を構成します。

1. 「WSD」を選択します。

2. 「Farms」を選択します。

3. 「Farm Table」を選択します。

4. 構成するファームを選択します。

5. 「Properties」ウィンドウで、「Multiplexed Port」フィールドに値を入力します。

6. 「WSD」を選択します。

7. 「Servers」を選択します。

8. 「Application Servers」を選択します。

9. 各ローカル・サーバーについて、表からサーバーを選択し、「Multiplexed Port」フィールドにアプリケーション・ポートを入力します。

10. 「Set」をクリックします。

ステップ4: HTTPリダイレクトの構成

MAN/WAN環境内でグローバル・ロード・バランサが機能するように構成するには、HTTPリダイレクトを構成する必要があります。HTTPリダイレクトによって、複数のWeb Server Directorデバイス間でトラフィックが適切に分散されます。

HTTPリダイレクトを構成するには、Radware管理ユーティリティで次の手順を実行します。

1. 「WSD」を選択します。

2. 「Farms」を選択します。

3. 「Farm Table」を選択します。

4. 構成するファームを選択します。

5. 「Redirection Mode」セクションで「HTTP Redirection」を選択します。

6. 「DNS Redirection Fallback」セクションで「HTTP Redirection」を選択します。

7. 「Set」をクリックします。

8. 「WSD」を選択します。

9. 「Servers」を選択します。

10. 「Application Servers」を選択します。

11. リモートWSD上で分散されたファームを表すファーム内のサーバーを選択します。

ステップ5: セッションIDの永続性の構成

サーバーの永続性は、HTTPセッションIDに基づきます。Web Server Directorは、ファームへの受信トラフィックを検査し、HTTPヘッダー内のセッション情報に基づいて適切なサーバーを選択します。セッションIDの永続性を構成するには、Radware管理ユーティリティで次の手順を実行します。

1. 「WSD」を選択します。

2. 「L7 Load Balancing」を選択します。

3. 「Session Persistency」を選択します。

4. 「Create」をクリックします。

5. 構成するファームを選択します。

6. ファームのアプリケーション・ポートを設定します。

7. 「Persistency Identification」を「JESESSIONID」に設定します。

8. 「Value Offset」を53に設定します。

9. 「Stop Chars」を「:!」に設定します。

10. 「Inactivity Timeout」をセッション・タイムアウトの値に設定します。

ステップ6: LRPの構成

LRPコンポーネントを構成することによって、複数のリモートの場所にトラフィックを適切に分散できます。LRPを構成するには、次の手順を実行します。

1. 「WSD」を選択します。

2. 「Distributed Systems」を選択します。

3. 「Report Configuration」を選択します。

4. 「Create Distributed Farm Address」をクリックします。

5. 「Distributed Farm Address」をリモート・ファームIPアドレスに設定します。

6. 「Remote WSD Address」を2つ目のRadwareデバイスのIPアドレスに設定します。

7. 「Set」をクリックします。

ステップ7: WebLogic Serverコンポーネントの構成

Radwareデバイスを構成したら、WebLogic ServerでMAN/WANフェイルオーバー機能を使用するように構成する必要があります。WebLogic ServerでMAN/WANを使用するように構成する方法は、「MAN/WAN内のクラスタ間でのセッション状態レプリケーション」を参照してください

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2017, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

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

保証免責

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

制限付権利について

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

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

危険な用途への使用について

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

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

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

第三者のコンテンツ、製品、サービスに対する免責事項

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

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

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

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

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。