Oracle Application Server 10g高可用性ガイド, 10g（9.0.4）

Transcription

1 Oracle Application Server 10g 高可用性ガイド 10g(9.0.4) 部品番号 : B 年 6 月

2 Oracle Application Server 10g 高可用性ガイド, 10g(9.0.4) 部品番号 : B 原本名 : Oracle Application Server 10g High Availability Guide, 10g (9.0.4) 原本部品番号 : B 原本著者 : Kai Li, Thomas Van Raalte 原本協力者 : Jay Feenan, Shari Yamaguchi, Ashesh Parekh, Susan Kornberg, Pradeep Bhat, Ashish Prabhu, Mukul Paithane, Wei Hu, Wayne Milsted, Jerry Bortveldt, Michael Moon, David Rowlands, Paul Mackin, Wes Root Copyright 2003, 2004 Oracle Corporation. All rights reserved. 制限付権利の説明 このプログラム ( ソフトウェアおよびドキュメントを含む ) には オラクル社およびその関連会社に所有権のある情報が含まれています このプログラムの使用または開示は オラクル社およびその関連会社との契約に記された制約条件に従うものとします 著作権 特許権およびその他の知的財産権と工業所有権に関する法律により保護されています 独立して作成された他のソフトウェアとの互換性を得るために必要な場合 もしくは法律によって規定される場合を除き このプログラムのリバース エンジニアリング 逆アセンブル 逆コンパイル等は禁止されています このドキュメントの情報は 予告なしに変更される場合があります オラクル社およびその関連会社は このドキュメントに誤りが無いことの保証は致し兼ねます これらのプログラムのライセンス契約で許諾されている場合を除き プログラムを形式 手段 ( 電子的または機械的 ) 目的に関係なく 複製または転用することはできません このプログラムが米国政府機関 もしくは米国政府機関に代わってこのプログラムをライセンスまたは使用する者に提供される場合は 次の注意が適用されます U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation, and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the Programs, including documentation and technical data, shall be subject to the licensing restrictions set forth in the applicable Oracle license agreement, and, to the extent applicable, the additional rights set forth in FAR , Commercial Computer Software--Restricted Rights (June 1987). Oracle Corporation, 500 Oracle Parkway, Redwood City, CA このプログラムは 核 航空産業 大量輸送 医療あるいはその他の危険が伴うアプリケーションへの用途を目的としておりません このプログラムをかかる目的で使用する際 上述のアプリケーションを安全に使用するために 適切な安全装置 バックアップ 冗長性 (redundancy) その他の対策を講じることは使用者の責任となります 万一かかるプログラムの使用に起因して損害が発生いたしましても オラクル社およびその関連会社は一切責任を負いかねます Oracle は Oracle Corporation およびその関連会社の登録商標です その他の名称は Oracle Corporation または各社が所有する商標または登録商標です

3 目次 はじめに はじめに... ix 対象読者... x このマニュアルの構成... x 関連ドキュメント... xi 表記規則... xi 1 概要 高可用性とは Oracle Application Server 10g の高可用性 障害のタイプ このマニュアルの構成について 他のドキュメントの高可用性に関する情報 中間層の高可用性 OracleAS Middle Tier の概要 OracleAS Middle Tier の用語 使用できるサービス J2EE HTTP Portal Business Intelligence Oracle Application Server Forms Services Single Sign-On キャッシュ 中間層の高可用性を実現するための機能とコンポーネント i

4 Oracle Application Server インスタンスの高可用性 Oracle Application Server Cluster Oracle Application Server Cluster のタイプ リポジトリを使用して管理される Oracle Application Server Cluster のクラスタレベルの構成 リポジトリを使用して管理される Oracle Application Server Cluster に結合するための Oracle Application Server インスタンスの要件 リポジトリを使用して管理される Oracle Application Server Cluster 内の Oracle Application Server インスタンスの特性 Oracle Application Server Web Cache クラスタ OC4J アイランド OC4J アイランドによる Web アプリケーションのセッション状態レプリケーション ソフトウェアの問題を防止する Web アプリケーションのセッション状態 ハードウェアの問題を防止する Web アプリケーションのセッション状態レプリケーション 高可用性を備えた OC4J アイランドの構成 EJB クラスタリングを使用したステートフル セッション EJB の高可用性 JNDI ネームスペースのレプリケーション OC4J Java Object Cache を使用した分散キャッシュ プロセスの監視と再起動 Oracle Process Manager Oracle Notification Server 分散構成による高可用性 その他の高可用性コンポーネント 外部ロード バランサによる可用性の向上 外部ロード バランサのタイプ 外部ロード バランシングによる高可用性の利点 オペレーティング システム クラスタによる可用性の向上 HTTP サービスの高可用性 Web Cache と Oracle HTTP Server の高可用性の要約 mod_oc4j を使用した OC4J ロード バランシング OC4J ローカル アフィニティおよび重み付けされたルーティング オプションを使用したロード バランシング mod_oc4j のルーティング アルゴリズムの選択 J2EE の高可用性 EJB クライアント ルーティング Oracle Application Server Portal の高可用性 Oracle Application Server Wireless の高可用性 ii

5 Business Intelligence の高可用性 Oracle Application Server Reports Services の高可用性 高可用性ソリューション Oracle Application Server Discoverer の高可用性 Oracle Application Server Forms Services の高可用性 Oracle Application Server Integration の高可用性 中間層のリカバリ ソリューション プロセスの再起動 コールド バックアップからのリストア オンライン バックアップからのリストア 障害時リカバリ DCM アーカイブおよびリカバリ 構成のクローニング Infrastructure の高可用性 Oracle Application Server 10g Infrastructure の概要 Oracle Application Server 10g Infrastructure のコンポーネント Oracle Application Server Metadata Repository Oracle Application Server Metadata Repository が必要な配置 Oracle Identity Management Oracle Internet Directory Oracle Application Server Single Sign-On Oracle HTTP Server Oracle Application Server Containers for J2EE(OC4J) Oracle Enterprise Manager - Application Server Control Infrastructure の高可用性構成 Oracle Application Server Cold Failover Cluster 用語 ハードウェア クラスタ フェイルオーバー 次ノード 次ノード 論理 IP または仮想 IP 仮想ホスト名 共有記憶域 アーキテクチャ (UNIX) アーキテクチャ (Windows) iii

6 OracleAS Cold Failover Cluster ノード上の中間層 Oracle Application Server Active Failover Cluster(UNIX) ロード バランサの構成 中間層の高可用性の管理と操作 中間層の高可用性構成の概要 リポジトリを使用して管理される OracleAS Cluster の構成の概要 Oracle Application Server Cluster managed using database repository Oracle Application Server Cluster managed using file-based repository OracleAS Cluster の構成に共通の作業 手動で構成された OracleAS Cluster の構成の概要 OracleAS Web Cache クラスタの概要 OracleAS Cluster の管理と構成 OracleAS Cluster の作成と管理 インスタンスとファームの関連付け データベース リポジトリを使用して管理されるようにインスタンスを関連付ける ファイルベースのリポジトリを使用して管理されるようにインスタンスを関連付ける Application Server Control を使用した OracleAS Cluster の作成 Application Server Control を使用した OracleAS Cluster の管理 OracleAS Cluster 内のアプリケーション サーバー インスタンスの管理 OracleAS Cluster へのアプリケーション サーバー インスタンスの追加 OracleAS Cluster からのアプリケーション サーバー インスタンスの削除 OracleAS Cluster でのファイルベースのリポジトリの使用 ファイルベースのリポジトリ ホストの初期化およびファームへのインスタンスの追加 whichfarm を使用したインスタンスのテストおよびファームからの削除 ファイルベースのリポジトリのリポジトリ ホスト インスタンスの初期化 ファイルベースのリポジトリを使用して管理されるファームへの結合 ファイルベースのリポジトリを使用するファーム内のインスタンスの管理 ファイルベースのリポジトリを使用した Oracle Application Server インスタンスおよび Oracle Application Server Cluster の管理 ファイルベースのリポジトリを使用する OracleAS Cluster の可用性に関する問題 ファイルベースのリポジトリを使用した構成情報のエクスポートとインポート リポジトリ間のインスタンスの移動 データベースベースのリポジトリへの移動 別のファイルベースのリポジトリへの移動 ファイルベースのリポジトリを使用しているインスタンス間の通信での SSL の有効化 キーストアの生成 iv

7 各インスタンスでの Oracle Application Server プロセスの停止 ファーム内の各インスタンスでのキーストア情報ファイルの設定 dcmcache.xml の構成による SSL の有効化 構成変更の適用の確認 ファーム内の各インスタンスの起動 SSL が有効化されたファームへの新規インスタンスの追加 OracleAS Cluster での OC4J の構成 OC4J インスタンス用の OracleAS Cluster 構成の概要 クラスタレベルの構成の変更および OC4J インスタンスの変更 OracleAS Cluster での OC4J インスタンスの作成または削除 OracleAS Cluster へのアプリケーションのデプロイ OracleAS Cluster 用の Web アプリケーション状態レプリケーションの構成 OracleAS Cluster 用の EJB アプリケーション状態レプリケーションの構成 OracleAS Cluster 用のステートフル Session Bean レプリケーションの構成 コール終了時のレプリケーション JVM 終了時のレプリケーション OC4J インスタンス固有のパラメータの構成 OC4J アイランドおよび OC4J プロセスの構成 ポート番号およびコマンドライン オプションの構成 OracleAS Cluster での Oracle HTTP Server の構成 OracleAS Cluster を使用した mod_oc4j ロード バランシング ロード バランシングの概要 ロード バランシング オプションの設定 Oracle HTTP Server インスタンス固有のパラメータの構成 セキュリティ : Single Sign-On の構成 高度なクラスタリング構成 同じファーム内のインスタンス間のルーティング ファイアウォールを越えたインスタンス間のルーティング OracleAS Port Tunnel を介したイントラネット通信のオープン イントラネットを介して通信するための OracleAS ポートのオープン Infrastructure の高可用性の管理 Oracle Application Server Cold Failover Cluster 起動 停止 Oracle Application Server Active Failover Cluster(UNIX) 起動 v

8 停止 監視 停止中のフェイルオーバー 停止後のリジリエンスの回復 Oracle Application Server Active Failover Cluster Runtime Control Utility(afcctl) を使用した構成ファイルの同期化 afcctl のセットアップ afcctl ユーティリティの入手 afcctl ユーティリティのインストール afcctl の使用 デフォルトのベースライン タイムスタンプの設定 OracleAS Active Failover Cluster 内のノード間でのファイルの同期化 前回の同期化以降に変更された ノード上のファイルのリスト 特定の構成ファイルの同期化からの除外 例 afcctl の使用のベスト プラクティス Oracle Application Server Disaster Recovery Oracle Application Server 10g Disaster Recovery ソリューション 用語 要件 トポロジ OracleAS Disaster Recovery 環境のセットアップ ホスト名の計画と割当て 物理ホスト名 論理ホスト名 仮想ホスト名 ホスト名解決の構成 ローカル ホスト名ファイル解決の使用 DNS 解決の使用 DNS サーバーへの Oracle Data Guard 用エントリの追加 Secure Shell(SSH) ポート フォワーディング Oracle Application Server 10g ソフトウェアのインストール Oracle Data Guard のセットアップ 本番データベースの ARCHIVELOG モードの有効化 本番データベースのデータ ファイルの識別 vi

9 本番データベースのコピーの作成 スタンバイ データベース用の制御ファイルの作成 スタンバイ データベースにコピーする初期化パラメータ ファイルの準備 本番システムからスタンバイ システムへのファイルのコピー フィジカル スタンバイ データベース用の初期化パラメータの設定 Windows サービスの作成 (Microsoft Windows システムの場合 ) スタンバイ システムでの新しいパスワード ファイルの作成 本番およびスタンバイ データベース用のリスナーの構成 スタンバイ システムでのデッド接続検出の有効化 Oracle Net サービス名の作成 スタンバイ データベース用のサーバー パラメータ ファイルの作成 フィジカル スタンバイ データベースの起動 フィジカル スタンバイ データベースへのアーカイブの有効化 リモート アーカイブの開始 フィジカル スタンバイ データベースの確認 ベースライン インストールとスタンバイ サイトの同期化 本番サイトのバックアップ Infrastructure データベースのアーカイブ ログの転送 構成ファイルのバックアップ (Infrastructure および中間層 ) スタンバイ サイトへのリストア 構成ファイルのリストア (Infrastructure および中間層 ) Infrastructure データベースのリストア : ログ ファイルの適用 スケジューリングした停止 サイト スイッチオーバー操作 計画外停止 サイト フェイルオーバー操作 新しいスタンバイ データベースのセットアップ ワイド エリア DNS の操作 ワイド エリア ロード バランサの使用 DNS 名の手動変更 A DNS サーバーのセットアップ 索引 vii

10 viii

11 はじめに はじめに の項目は次のとおりです 対象読者 このマニュアルの構成 関連ドキュメント 表記規則 ix

12 対象読者 Oracle Application Server 10g 高可用性ガイド は 高可用性が必要とされる Oracle Application Server 10g を配置および管理する役割を持つ管理者や開発者を対象としています このマニュアルの構成 このマニュアルは 次の章から構成されています 第 1 章 概要 第 1 章では Oracle Application Server 10g での高可用性の概要を説明します 第 2 章 中間層の高可用性 第 2 章では Oracle Application Server 10g Middle Tier における高可用性について説明します 第 3 章 Infrastructure の高可用性 第 3 章では Oracle Application Server 10g Infrastructure で使用できる高可用性ソリューションについて説明します 第 4 章 中間層の高可用性の管理と操作 第 4 章では 中間層の高可用性環境を管理および操作するための手順について説明します 第 5 章 Infrastructure の高可用性の管理 第 5 章では Infrastructure の高可用性ソリューションを設定および管理するための手順について説明します 第 6 章 Oracle Application Server Disaster Recovery 第 6 章では OracleAS の障害時リカバリ ソリューションについて説明します このソリューションは 中間層と Infrastructure 層の両方を対象としています 付録 A DNS サーバーのセットアップ 付録 A では Oracle Application Server Disaster Recovery ソリューションに関連する DNS サーバーのセットアップ手順について説明します x

13 関連ドキュメント リリース ノート インストール関連ドキュメント ホワイト ペーパーまたはその他の関連ドキュメントは OTN-J(Oracle Technology Network Japan) から 無償でダウンロードできます OTN-J を使用するには オンラインでの登録が必要です 登録は 次の Web サイトから無償で行えます すでに OTN-J のユーザー名およびパスワードを取得している場合は 次の URL で OTN-J Web サイトのドキュメントのセクションに直接接続できます 表記規則 この項では このマニュアルの本文およびコード例で使用される表記規則について説明します この項の内容は次のとおりです 本文の表記規則 コード例の表記規則 Microsoft Windows オペレーティング システム環境での表記規則 本文の表記規則本文では 特定の項目が一目でわかるように 次の表記規則を使用します 次の表に その規則と使用例を示します 規則太字 意味 太字は 本文中で定義されている用語および用語集に記載されている用語を示します 例この句を指定すると 索引構成表索引構成表が作成されます 固定幅フォントの大文字 固定幅フォントの大文字は システム指定の要素を示します このような要素には パラメータ 権限 データ型 Recovery Manager キーワード SQL キーワード SQL*Plus またはユーティリティ コマンド パッケージおよびメソッドがあります また システム指定の列名 データベース オブジェクト データベース構造 ユーザー名およびロールも含まれます NUMBER 列に対してのみ この句を指定できます BACKUP コマンドを使用して データベースのバックアップを作成できます USER_TABLES データ ディクショナリ ビュー内の TABLE_NAME 列を問い合せます DBMS_STATS.GENERATE_STATS プロシージャを使用します xi

14 規則 固定幅フォントの小文字 意味 固定幅フォントの小文字は 実行可能ファイル ファイル名 ディレクトリ名およびユーザーが指定する要素のサンプルを示します このような要素には コンピュータ名およびデータベース名 ネット サービス名および接続識別子があります また ユーザーが指定するデータベース オブジェクトとデータベース構造 列名 パッケージとクラス ユーザー名とロール プログラム ユニットおよびパラメータ値も含まれます 例 sqlplus と入力して SQL*Plus をオープンします パスワードは orapwd ファイルで指定します /disk1/oracle/dbs ディレクトリ内のデータ ファイルおよび制御ファイルのバックアップを作成します hr.departments 表には department_id department_name および location_id 列があります QUERY_REWRITE_ENABLED 初期化パラメータを true に設定します oe ユーザーとして接続します 注意 : プログラム要素には 大文字と小文 JRepUtil クラスが次のメソッドを実装します 字を組み合せて使用するものもあります これらの要素は 記載されているとおりに入力してください 固定幅フォントの 固定幅フォントの小文字のイタリックは 小文字のイタリック プレースホルダまたは変数を示します parallel_clause を指定できます Uold_release.SQL を実行します ここで old_release とはアップグレード前にインストールしたリリースを示します コード例の表記規則コード例は SQL PL/SQL SQL*Plus または他のコマンドライン文の例です 次のように固定幅フォントで表示され 通常のテキストと区別されます SELECT username FROM dba_users WHERE username = 'MIGRATE'; 次の表に コード例で使用される表記規則とその使用例を示します 規則意味 [ ] 大カッコは カッコ内の項目を任意に選択することを表します 大カッコは 入力しないでください { } 中カッコは カッコ内の項目のうち 1 つが必須であることを表します 中カッコは 入力しないでください 例 DECIMAL (digits [, precision ]) {ENABLE DISABLE} xii

15 規則 縦線は 大カッコまたは中カッコ内の複数の選択項目の区切りに使用します 項目のうちの 1 つを入力します 縦線は 入力しないでください... 水平の省略記号は 次のいずれかを示します 例に直接関連しないコードの一部が省略されている... その他の記号 イタリック体 大文字 小文字 意味 コードの一部を繰り返すことができる 垂直の省略記号は 例に直接関連しない複数の行が省略されていることを示します 大カッコ 中カッコ 縦線および省略記号以外の記号は 記載されているとおりに入力する必要があります イタリック体は 特定の値を指定する必要があるプレースホルダや変数を示します 大文字は システム指定の要素を示します これらの要素は ユーザー定義の要素と区別するために大文字で示されます 大カッコ内にないかぎり 表示されているとおりの順序および綴りで入力します ただし 大 / 小文字が区別されないため 小文字でも入力できます 小文字は ユーザー指定のプログラム要素を示します たとえば 表名 列名またはファイル名などです 例 {ENABLE DISABLE} [COMPRESS NOCOMPRESS] CREATE TABLE... AS subquery; SELECT col1, col2,..., coln FROM employees; SQL> SELECT NAME FROM V$DATAFILE; NAME /fsl/dbs/tbs_01.dbf /fs1/dbs/tbs_02.dbf... /fsl/dbs/tbs_09.dbf 9 rows selected. acctbal NUMBER(11,2); acct CONSTANT NUMBER(4) := 3; CONNECT SYSTEM/system_password DB_NAME = database_name SELECT last_name, employee_id FROM employees; SELECT * FROM USER_TABLES; DROP TABLE hr.employees; SELECT last_name, employee_id FROM employees; sqlplus hr/hr xiii

16 規則 意味 注意 : プログラム要素には 大文字と小文字を組み合せて使用するものもあります これらの要素は 記載されているとおりに入力してください 例 CREATE USER mjones IDENTIFIED BY ty3mu9; 規則 ファイル名およびディレクトリ名 Windows コマンド プロンプト 特殊文字 HOME_NAME Microsoft Windows オペレーティング システム環境での表記規則 次の表に Microsoft Windows オペレーティング システム環境での表記規則とその使用例を示します 意味 ファイル名およびディレクトリ名は大 / 小 c: winnt" "system32 は文字が区別されません 特殊文字の左山 C: WINNT SYSTEM32 と同じです カッコ (<) 右山カッコ(>) コロン(:) 二重引用符 (") スラッシュ(/) 縦線 ( ) およびハイフン (-) は使用できません 円記号 ( ) は 引用符で囲まれている場合でも 要素のセパレータとして処理されます Windows では ファイル名が で始まる場合 汎用命名規則が使用されていると解釈されます Windows コマンド プロンプトには カレント ディレクトリが表示されます このマニュアルでは コマンド プロンプトと呼びます コマンド プロンプトのエスケープ文字はカレット (^) です Windows コマンド プロンプトで二重引用符 (") のエスケープ文字として円記号 ( ) が必要な場合があります 丸カッコおよび一重引用符 (') にはエスケープ文字は必要ありません エスケープ文字および特殊文字の詳細は Windows オペレーティング システムのドキュメントを参照してください Oracle ホームの名前を表します ホーム名には 英数字で 16 文字まで使用できます ホーム名に使用可能な特殊文字は アンダースコアのみです 例 C: oracle oradata> C: >exp scott/tiger TABLES=emp QUERY= "WHERE job='salesman' and sal<1600 " C: >imp SYSTEM/password FROMUSER=scott TABLES=(emp, dept) C: > net start OracleHOME_NAMETNSListener xiv

17 規則 ORACLE_HOME および ORACLE_BASE 意味 Oracle8i より前のリリースでは Oracle コンポーネントをインストールすると すべてのサブディレクトリが最上位の ORACLE_ HOME の直下に置かれました ORACLE_ HOME ディレクトリの名前は デフォルトでは次のいずれかです C: orant(windows NT の場合 ) C: orawin98(windows 98 の場合 ) このリリースは Optimal Flexible Architecture(OFA) のガイドラインに準拠しています ORACLE_HOME ディレクトリ下に配置されないサブディレクトリもあります 最上位のディレクトリは ORACLE_ BASE と呼ばれ デフォルトでは C: oracle です 他の Oracle ソフトウェアがインストールされていないコンピュータに最新リリースの Oracle をインストールした場合 Oracle ホーム ディレクトリは デフォルトで C: oracle ora90 に設定されます Oracle ホーム ディレクトリは ORACLE_BASE の直下に配置されます このマニュアルに示すディレクトリ パスの例は すべて OFA の表記規則に準拠しています 例 %ORACLE_HOME% rdbms admin ディレクトリへ移動します xv

18 xvi

19 1 概要 Oracle Application Server 10g のこのリリース 10g(9.0.4) では Oracle Application Server の高可用性ソリューションが強化および拡張されています Oracle Application Server 10g Infrastructure の複数の新規ソリューションのテストが実施されました これらのソリューションについては このマニュアルで説明されています これらのソリューションはすべて Oracle Application Server 10g に配置するアプリケーションがビジネス目標の達成に必要な可用性を実現することを目的としています このマニュアルで説明するソリューションと手順の目的は Oracle Application Server コンポーネントのシングル ポイント障害をなくし サービスをいっさい停止しないか最小限の停止にとどめることにあります この章では 高可用性とその重要性について Oracle Application Server の観点から説明します 概要 1-1

20 高可用性とは 高可用性とは システムまたはコンポーネントの可用性とは そのシステムまたはコンポーネントが正常に稼動している時間の割合を指します システムは 正確性およびパフォーマンスに関する仕様が満たされている場合に正常に機能します たとえば 1 日当たり 12 時間正常に稼動しているシステムの場合 そのシステムの可用性は 50% になります システムの可用性が 99% である場合 年間の非稼動日数は平均 3.65 日になります システム管理者は 重要なシステムに対して 99.99% あるいは % もの可用性を求めることもあります この場合のシステム停止時間は 年間 4 ~ 5 分程度にすぎません ある特定の期間にわたって可用性が一定に保たれない場合もあります たとえば 大多数のトランザクションが発生する日中は可用性が比較的高く 夜間や週末は可用性が比較的低くなります 火事や地震などの予期しない災害が発生すると システムが突然停止して一時期使用できなくなることがあります しかし インターネットのおかげでユーザーが世界的な規模に達したため システムが常時利用可能であることは一般的な要件となっています コンポーネントに冗長性を持たせることで 可用性が改善される場合もあります ただし これは 予備のコンポーネントが障害の発生したコンポーネントからの引継ぎを即座に行った場合に限ります たとえば コンポーネントの障害検出に 10 分費やし 予備のコンポーネントの起動にさらに 20 分費やしたとしてその 1 時間の稼動率を求めた場合 システムの可用性は 50% 低下したことになってしまいます Oracle Application Server は 様々な高可用性ソリューションを提供するように設計されています その範囲は ロード バランシングや基本的なクラスタリングから 壊滅的なハードウェアおよびソフトウェア障害時に最大限のシステム可用性を提供するものにまで及んでいます Oracle Application Server 10g の高可用性 Oracle Application Server は 分散トポロジに配置可能な様々なコンポーネントで構成されています Oracle Application Server では 高可用性を実現するための基礎となるパラダイムとしてクラスタリングを使用しています クラスタリングでは Oracle Application Server の各種コンポーネントが一定の組合せで結合され スケーラブルな統合機能を提供するとともに 個々のコンポーネントのいずれかで障害が発生した場合に備えて冗長性を提供します このマニュアルを読み進める前に Oracle Application Server 10g 概要 を通読して Oracle Application Server の様々なコンポーネントに関する知識を得ておくことをお薦めします これにより このマニュアルの以降の説明をより効率的に理解できるようになります 1-2 Oracle Application Server 10g 高可用性ガイド

21 Oracle Application Server 10g の高可用性 Oracle Application Server は 高可用性を実現する複数のソリューションと技法を備えており そのすべてがこのマニュアルで説明されています これらのソリューションと技法を使用すると 次の目標を達成できます 冗長性高可用性システムは 冗長性を確保するためにそのサブシステムを必要とします このマニュアルに記載されている手順とソリューションを使用すると Oracle Application Server のすべてのコンポーネントを冗長に配置できます コンポーネントは そのタイプに応じて アクティブ / アクティブ構成で配置することもアクティブ / パッシブ構成で配置することもできます アクティブ / アクティブ構成では コンポーネントの複数のインスタンスがクライアント リクエストを同時に処理します あるインスタンスで障害が発生した場合 そのインスタンスが処理していたリクエストをアクティブな別のインスタンスで実行できます このインスタンスの障害とフェイルオーバーは クライアントに対して透過的です 通常 アクティブ / アクティブ構成は コンポーネントのインスタンスをまとめてクラスタリングすることによって実現します アクティブ / パッシブ構成では 通常 リクエストはコンポーネントの 1 つのインスタンスによって処理されます そのコンポーネントで障害が発生すると 別のインスタンスがアクティブ化されて リクエストのワークロードに応答します 障害の検出と自動再起動 Oracle Application Server のコンポーネントに属するローカルまたは分散ソフトウェア プロセスは 集中的なプロセス管理システムによって管理されます このプロセス管理システムでは プロセスの障害を検出して プロセスが複数のマシンに分散している場合でもプロセスを再起動できます このシステムを使用すると プロセスの障害と再起動を定義するパラメータ値 ( ハートビートの回数など ) をカスタマイズできます プロセス管理システムを実装しているプロセスは それぞれシャドウ プロセスを備えており 冗長性を実現しています クラスタリングシステムのコンポーネントをまとめてクラスタリングすることにより クライアント側は これらのコンポーネントを機能的に 1 つのエンティティと見なすことができます クラスタにより コンポーネントのスケーラビリティ 可用性および管理性が向上します Oracle Application Server コンポーネントでは 複数のクラスタ タイプを使用できます これらのクラスタを作成および構成する手順は このマニュアルで詳しく説明します 概要 1-3

22 Oracle Application Server 10g の高可用性 状態のレプリケーションとルーティングステートフル クライアント リクエストでは これらのリクエストを処理しているプロセスに障害が発生した場合 Oracle Application Server は リクエストのステートフル フェイルオーバーを有効にするためにクライアント状態をレプリケートできます J2EE リクエストでは 使用する方法に応じて J2EE アプリケーションのクライアント状態を宣言的にレプリケートすることも プログラムによってレプリケートすることもできます その他の大部分のコンポーネントでは Cookie を使用した状態ベースのルーティングを使用できます 接続失敗管理多くの場合 クライアントはサーバー上のサービスに接続し その接続を再利用します サーバー上のサービスのいずれかを実装しているプロセスを再起動すると 接続の再確立が必要になることがあります Oracle Application Server コンポーネントでは 再利用の接続に失敗すると 失敗の状態がシステムの他の部分に伝播する前に再接続が試行されます これにより 接続の失敗をクライアントから透過的にすることができます バックアップとリカバリ Oracle Application Server は システム状態をバックアップして障害からのリカバリに使用する機能を備えています 特定の状況下では コンポーネントまたはシステムの障害が修復不可能なこともあります Oracle Application Server の Backup and Recovery Tool を使用すると システムを一定の間隔でバックアップして 修復不可能な障害が発生したときにバックアップをリストアできます HTTP リスナーと J2EE コンテナに固有の問題では ランタイム構成管理システムを使用して これらのコンポーネントに簡単にチェックポイントを設定できます さらに 構成エラーを元に戻す操作も可能です 障害時リカバリ 重要なアプリケーションをホストしている Oracle Application Server サイトが物理的に存在する場所で 自然災害や物理的な障害が発生することもあります このマニュアルでは こうした障害からリカバリするためのソリューションについて説明します このソリューションは サイト間リカバリ ソリューションです このソリューションでは Oracle Application Server のサイト全体の状態をバックアップして そのサイトから物理的に離れている別のサイトにリカバリすることができます 1-4 Oracle Application Server 10g 高可用性ガイド

23 このマニュアルの構成について 障害のタイプ 表 1-1 に Oracle Application Server システムで想定される様々な障害のタイプと 障害の防止または解決に使用する計画を示します 説明のために 計画停止時のメンテナンス アクティビティも記載してあります 表 1-1 システムの停止 障害および可用性ソリューション 停止のタイプ 障害のタイプ ソリューション 計画外停止 システム障害 ロード バランサ ファーム Oracle Process Manager and Notification Server Oracle Application Server Active Failover Cluster Oracle Application Server Cold Failover Cluster データ障害および災害 人為ミス リモート サイト バックアップとリカバリ Oracle Data Guard バックアップとリカバリ Oracle Data Guard 計画停止システム メンテナンス分散および動的構成 データ メンテナンス データは Oracle データベースに格納されているため 停止は不要 Backup and Recovery Tool( ファイル システム内の構成ファイル用 ) 表に示すように 予期しないシステム障害から意図的でない人為ミスまで 障害を回避またはリカバリするソリューションが用意されています これらのソリューションにより Oracle Application Server は堅牢で信頼性の高いものとなり ホストするアプリケーションの高可用性を実現できます このマニュアルの構成について このマニュアルは 中間層および Oracle Application Server Infrastructure のレイヤーに基づく複数の章で構成されています このマニュアルの 中間層 という用語は Oracle Application Server Middle Tier インストール タイプの総称として使用されています ただし Oracle Application Server Cluster の説明箇所では J2EE and Web Cache インストール タイプだけが想定されています これは このタイプが Oracle Application Server Cluster に組み込むことのできる唯一の中間層インストール タイプだからです 第 2 章と第 3 章には 高可用性を実現するための中間層の説明と構成がそれぞれ記載されています 第 3 章と第 5 章の情報構成は Infrastructure を除いて類似しています 第 6 章には サイト間の Oracle Application Server Disaster Recovery ソリューションのセットアップと操作に関する情報が記載されています 概要 1-5

24 他のドキュメントの高可用性に関する情報 他のドキュメントの高可用性に関する情報 次の表に 他のドキュメントの高可用性に関する情報の参照先一覧を示します この情報は Oracle Application Server の各種コンポーネントの高可用性に関連するものです 表 1-2 Oracle ドキュメントの高可用性に関する情報の参照先 コンポーネント 高可用性の概要 Oracle Installer Oracle Application Server Backup and Recovery Tool Oracle Application Server Web Cache Identity Management サービスのレプリケーション Identity Management の高可用性の配置 データベースの高可用性 Distributed Configuration Management コマンド Oracle Process Manager and Notification Server コマンド OC4J の高可用性 Java Object Cache OC4J プロセスのロード バランシング 情報の場所 Oracle Application Server 10g 概要 の高可用性の章 Oracle Application Server 10g のインストレーション ガイドの高可用性環境におけるインストールの章 Oracle Application Server 10g 管理者ガイド のバックアップとリストアの説明部分 Oracle Application Server Web Cache 管理者ガイド Oracle Application Server Single Sign-On 管理者ガイド の 拡張構成 の章 Oracle Internet Directory 管理者ガイド の ディレクトリ レプリケーションと高可用性 の章 Oracle Identity Management 概要および配置プランニング ガイド の Oracle Identity Management の配置プランニング の章 Oracle 高可用性アーキテクチャおよびベスト プラクティス Distributed Configuration Management リファレンス ガイド Oracle Process Manager and Notification Server 管理者ガイド Oracle Application Server Containers for J2EE サービス ガイド Oracle Application Server Containers for J2EE ユーザーズ ガイド Oracle Application Server Containers for J2EE Enterprise JavaBeans 開発者ガイド Oracle Application Server Web Services 開発者ガイド Oracle HTTP Server 管理者ガイド Oracle Application Server Wireless の高可用性 Oracle Application Server Reports Services の高可用性 Oracle Application Server Wireless 管理者ガイド Oracle Application Server Reports Services レポート Web 公開ガイド 1-6 Oracle Application Server 10g 高可用性ガイド

25 他のドキュメントの高可用性に関する情報 表 1-2 Oracle ドキュメントの高可用性に関する情報の参照先 ( 続き ) コンポーネント Oracle Application Server Discoverer の高可用性 情報の場所 Oracle Application Server Discoverer 構成ガイド Oracle Application Server Forms Services の高可用性 Oracle Application Server InterConnect の ini ファイルに関する情報 Oracle Application Server Forms Services 利用ガイド Oracle Application Server InterConnect ユーザーズ ガイド これらのドキュメントとその他のドキュメントへの参照情報は このマニュアルの本文にも適宜記載されています 概要 1-7

26 他のドキュメントの高可用性に関する情報 1-8 Oracle Application Server 10g 高可用性ガイド

27 2 中間層の高可用性 この章では Oracle Application Server Middle Tier を障害から保護するソリューションについて説明します この章は 次の主要な項で構成されています OracleAS Middle Tier の概要 中間層の高可用性を実現するための機能とコンポーネント HTTP サービスの高可用性 J2EE の高可用性 Oracle Application Server Portal の高可用性 Oracle Application Server Wireless の高可用性 Business Intelligence の高可用性 Oracle Application Server Forms Services の高可用性 Oracle Application Server Integration の高可用性 中間層のリカバリ ソリューション 中間層の高可用性 2-1

28 OracleAS Middle Tier の概要 OracleAS Middle Tier の概要 OracleAS Middle Tier は クライアントにフロントエンド アプリケーション サービスを提供するコンポーネントで構成されています 中間層は 次の 3 つのインストール タイプのいずれかを使用して作成できます J2EE and Web Cache このインストール タイプでは Oracle Application Server Containers for J2EE(OC4J) と Oracle Application Server Web Cache(OracleAS Web Cache) のコンポーネントがインストールされます これらのコンポーネントでは J2EE 1.3 ランタイム コンテナと静的および動的なコンテンツ キャッシュ機能を利用できます 3 つのインストール タイプのうち J2EE and Web Cache インストールのみが OracleAS Cluster としてクラスタリングできます Portal and Wireless このインストール タイプでは J2EE and Web Cache インストール タイプのコンポーネントに加えて Oracle Application Server Portal および Oracle Application Server Wireless コンポーネントがインストールされます Business Intelligence and Forms このインストール タイプでは Oracle Application Server Forms Services Oracle Application Server Reports Services Oracle Application Server Discoverer Oracle Application Server Personalization のコンポーネントと Portal and Wireless インストール タイプのコンポーネントがインストールされます 注意 : Oracle Application Server ProcessConnect と Oracle Application Server InterConnect は それぞれの CD-ROM から実行する独自のインストーラを備えています 関連項目 : Oracle Application Server のインストール タイプの詳細は 各プラットフォームの Oracle Application Server 10g のインストレーション ガイドを参照してください J2EE and Web Cache インストール タイプは J2EE アプリケーションの実行に必要なコア機能を提供します これには Oracle HTTP Server を使用した HTTP サービスなどがあります OracleAS Infrastructure の Oracle Identity Management フレームワークを使用するように中間層を構成している場合は J2EE アプリケーションでシングル サインオン機能を利用できます 2-2 Oracle Application Server 10g 高可用性ガイド

29 OracleAS Middle Tier の概要 注意 : Portal and Wireless および Business Intelligence and Forms インストール タイプは Oracle Application Server Metadata Repository および Oracle Identity Management サービスを常に必要とします これらのタイプの中間層のコンポーネントは Oracle Application Server Metadata Repository スキーマにアクセスする必要があるからです OracleAS Middle Tier の用語 Oracle Application Server Middle Tier の高可用性について検討する前に 次の各用語について確認しておくと役に立ちます Oracle Application Server インスタンス : Oracle Application Server インスタンス ( アプリケーション サーバー インスタンス OracleAS インスタンスともいいます ) は アプリケーション サーバー インストール内で構成されたコンポーネントの実行に必要なプロセスのセットです アプリケーション サーバー インスタンスは 各アプリケーション サーバー インストールに 1 つのみ存在します インストールとインスタンスという用語は同じ意味で使用されることもありますが インストールは Oracle ホームにインストールされたファイルのセットであるのに対し インスタンスはこれらのファイルに関連付けられたプロセスのセットを意味します コンポーネント インスタンス : コンポーネント インスタンスには 1 つの Oracle HTTP Server プロセスまたは複数の Oracle Application Server Containers for J2EE (OC4J) インスタンスが含まれます ( 図 2-2 を参照 ) Oracle Application Server Cluster: Oracle Application Server Cluster(OracleAS Cluster) は 同一の構成およびアプリケーション デプロイを持つアプリケーション サーバー インスタンスの集まりです Oracle Application Server Cluster により クラスタの一部であるインスタンス間で同質性が確保されるため クラスタはシングル インスタンスと見なされ シングル インスタンスとして機能します 適切なフロントエンド ロード バランシングを使用すれば Oracle Application Server Cluster 内のどのインスタンスでもクライアント リクエストを処理できます これにより 複数のインスタンス間で構成とデプロイが簡略化され Oracle Application Server Cluster にデプロイされたアプリケーションの高可用性が実現します Oracle Application Server Cluster は データベースまたはファイルベースのリポジトリを使用して管理できます クラスタはまた リポジトリを使用しないで手動で構成することもできます 詳細は 2-10 ページの Oracle Application Server Cluster を参照してください OC4J アイランド : Oracle Application Server Containers for J2EE(OC4J) アイランドは アイランドの一部である各 OC4J プロセス間でステートフル Web アプリケーションのセッション状態をレプリケートする OC4J プロセスのグループです アイランド内の OC4J プロセスは 複数のノードに分散できます OC4J アイランドが OracleAS インスタンス間で同じ名前を共有している場合は それらの OracleAS インスタンス間でセッション状態がレプリケートされます 中間層の高可用性 2-3

30 OracleAS Middle Tier の概要 使用できるサービス Oracle Application Server ファーム : ファームは 同じ Oracle Application Server Infrastructure を共有する またはファイルベースのリポジトリのホストに対して同じアプリケーション サーバー インスタンスを使用するアプリケーション サーバー インスタンスの集まりです Oracle Application Server ファームには OracleAS Cluster 内にあるものだけでなく 外部にあるアプリケーション サーバー インスタンスも含めることができます ( 図 2-2 を参照 ) 関連項目 : Oracle Application Server 10g 概要 前述の 3 つのインストール タイプは アプリケーション クライアントに次の各サービスを提供します J2EE J2EE サービスは OC4J によって提供されます OC4J は JSP サーブレットおよび EJB ランタイム環境を提供する J2EE 準拠のコンテナです OC4J をクラスタリングすることによって クライアントに対してフェイルオーバーと冗長性を実現できます 2-10 ページの Oracle Application Server Cluster および第 4 章 中間層の高可用性の管理と操作 を参照してください HTTP Oracle HTTP Server は Oracle Application Server に対する HTTP サポートを提供します このサービスは 複数の標準 Apache および OracleAS 固有のモジュールで構成された オープン ソースの Apache HTTP Server( バージョン ) に基づいています Oracle HTTP Server は 中間層の OracleAS インスタンスのコンポーネントです Oracle HTTP Server は Infrastructure 層の HTTP サポートも提供します (3-6 ページの Oracle HTTP Server を参照 ) さらに Oracle Application Server Web Cache(OracleAS Web Cache) によって リクエストされた HTTP オブジェクトのキャッシュが可能になります 詳細は 2-7 ページの キャッシュ を参照してください 関連項目 : Oracle HTTP Server 管理者ガイド 2-4 Oracle Application Server 10g 高可用性ガイド

31 OracleAS Middle Tier の概要 Portal OracleAS は 大規模なプログラミングやメンテナンスを必要としない すぐに使用できる企業ポータルを提供します Oracle Application Server Portal(OracleAS Portal) とその関連コンポーネントを使用すると 統合されたセルフサービスの企業ポータルの構築 配置およびメンテナンスを行うことができます OracleAS Portal では 拡張可能なフレームワークでセルフサービス コンテンツの管理と公開 ウィザードベースの開発 および Web サービスの配置と公開を行うことが可能です OracleAS Portal のこれらの機能は Oracle Application Server Portal Developer Kit Oracle Ultra Search および Oracle Application Server Syndication Services によってサポートされます 高可用性の詳細は 2-32 ページの Oracle Application Server Portal の高可用性 を参照してください 関連項目 : Oracle Application Server Portal 構成ガイド Business Intelligence Oracle Application Server 10g は 次の複数のコンポーネントにより Business Intelligence サービスを提供します Oracle Application Server Reports Services Oracle Application Server Reports Services では 動的に生成された高品質のレポートがスケーラブルでセキュアなプラットフォームで公開されます これらのレポートは Web ブラウザまたは非ブラウザ インタフェースを介して配信できます Oracle Application Server Discoverer Oracle Application Server Discoverer では 動的な非定型問合せ レポート作成 および Web ブラウザ配信の分析を実行できます Oracle Application Server Personalization Oracle Application Server Personalization では サイト閲覧時 登録済顧客と匿名ビジターの両方に対してパーソナライズされたコンテンツ リコメンデーションを動的に提供できます これらのコンポーネントの高可用性の詳細は 2-35 ページの Business Intelligence の高可用性 を参照してください 中間層の高可用性 2-5

32 OracleAS Middle Tier の概要 Oracle Application Server Forms Services Oracle Application Server Forms Services (OracleAS Forms Services) は 複数層環境における OracleAS Forms Services アプリケーションのデプロイのために最適化された包括的なアプリケーション フレームワークです Forms Services は 複雑なトランザクション Forms アプリケーションをデプロイするための 中間層アプリケーション フレームワークです Forms Developer でアプリケーションを新規に作成し OracleAS Forms Services でインターネットにデプロイできます 開発者は レガシー クライアント / サーバー モデルに以前に配置された現行アプリケーションを取得して アプリケーション コードを変更せずにそれらを 3 層アーキテクチャに移行することもできます 実行時 Oracle Application Server Forms Services では サーブレットおよび独立したランタイム プロセスの 2 つのコンポーネントが使用されます これらのコンポーネントで高可用性を実現する方法は 2-37 ページの Oracle Application Server Forms Services の高可用性 を参照してください Single Sign-On Oracle Application Server 10g のシングル サインオン サービスは Oracle Identity Management フレームワークの一部である Oracle Application Server Single Sign-On (OracleAS Single Sign-On) によって提供されます このフレームワークでは Oracle Application Server にデプロイされたすべてのアプリケーションとそのコンポーネント (OracleAS Portal OracleAS Reports Services など ) において 一元化されたユーザーの認証および認可システムを使用することができます ユーザーは一度ログインするだけで 認可されているすべてのアプリケーションとリソースにアクセスできます ユーザーの資格証明は LDAP バージョン 3 準拠のリポジトリ (Oracle Internet Directory) に格納されます 中間層では Apache モジュール mod_osso によって フレームワークの他のコンポーネントがインストールされている OracleAS Infrastructure 内のシングル サインオン サーバーにシングル サインオン リクエストを転送できます これらのコンポーネントには Oracle Internet Directory と Oracle Application Server Certificate Authority があります 両コンポーネントについては 第 3 章 Infrastructure の高可用性 で詳しく説明します 関連項目 : Oracle Identity Management の詳細は Oracle Application Server 10g 概要 を参照してください 2-6 Oracle Application Server 10g 高可用性ガイド

33 中間層の高可用性を実現するための機能とコンポーネント キャッシュ OracleAS では 次の 2 つの主要なキャッシュ メカニズムを使用できます OracleAS Web Cache OracleAS Web Cache は Oracle HTTP Server の前面に配置される HTTP レベルのキャッシュです OracleAS Web Cache は 静的コンテンツ (HTML GIF および JPEG) と動的コンテンツ ( サーブレットおよび JSP で生成 ) の両方をキャッシュします OracleAS Web Cache は Oracle HTTP Server インスタンスのロード バランサとして実行するように構成できます さらに OracleAS Web Cache をクラスタリングすることによって キャッシュされたコンテンツのフェイルオーバーと冗長性が実現し スケーラビリティが向上します 詳細は 2-16 ページの Oracle Application Server Web Cache クラスタ を参照してください OC4J Java Object Cache Java Object Cache は Java アプリケーションで使用されるインプロセスのキャッシュ サービスです Java Object Cache では アクセス頻度の高いオブジェクトや ( 作成のために ) リソースを大量に消費するオブジェクトがメモリー内またはディスク上に格納されます オブジェクトは 同じアプリケーションがデプロイされている複数の OC4J プロセス ( 同じ OracleAS Cluster 内の OC4J プロセスなど ) 間に分散できます 分散オブジェクトでは 調整と同期化が行われます そのため 1 つのプロセスで障害が発生しても キャッシュされたオブジェクトの可用性は低下しません Java Object Cache を使用すると Oracle Application Server 10g でコンテンツを迅速に取得できるようになり Java アプリケーションの負荷が減少します その結果 アプリケーションの可用性が向上します 詳細は 2-10 ページの Oracle Application Server Cluster を参照してください 中間層の高可用性を実現するための機能とコンポーネント 中間層のアーキテクチャでは 高可用性を実現する次のような機能と構成メンバーが使用されます Oracle Application Server インスタンスの高可用性 Oracle Application Server Cluster Oracle Application Server Web Cache クラスタ OC4J アイランド プロセスの監視と再起動 分散構成による高可用性 その他の高可用性コンポーネント 中間層の高可用性 2-7

34 中間層の高可用性を実現するための機能とコンポーネント Oracle Application Server インスタンスの高可用性 Oracle Application Server アーキテクチャでは 中間層における高可用性をサポートしており 多くの場合 デプロイされたアプリケーションで計画外の停止が発生することを回避できます この項では Oracle Application Server インスタンスにおけるアーキテクチャの概要を示し 中間層の高可用性機能についていくつか説明します それぞれの Oracle Application Server インスタンスでは 次の機能によってインスタンス内の高可用性だけでなく そのインスタンスが属するクラスタの高可用性も実現します プロセスの監視 : Oracle Process Manager and Notification Server を使用すると 監視しているプロセスで問題が検出された場合にプロセスの障害を検出してプロセスを再起動できます 構成のクローニング : 構成情報に対して Oracle Application Server Metadata Repository を使用する Distributed Configuration Management の機能により Oracle Application Server インスタンスおよびクラスタの一部である Oracle Application Server インスタンスで構成の分散と管理を行えます データ レプリケーション : Web アプリケーション レベルのステートフル セッションのレプリケーションを提供する OC4J アイランドとともに OC4J インスタンスを使用し EJB セッションを使用すると Oracle Application Server インスタンス内のプロセス間でデータがレプリケートされます Oracle Application Server Cluster の使用時には 別のホストに存在する別の Oracle Application Server インスタンス間でデータがレプリケートされます これにより Oracle Application Server インスタンス内のプロセスが使用できなくなるか それらのプロセスで障害が発生した場合でも ステートフル セッションベースのアプリケーションを引き続き利用することが可能になります スマート ルーティング : Oracle Application Server Web Cache および Oracle HTTP Server(mod_oc4j) により 構成可能でインテリジェントなルーティングを受信リクエストに対して使用できます Oracle Process Manager and Notification Server との通信を通じて mod_oc4j によって動作中と判断されたプロセスとコンポーネントにのみリクエストがルーティングされます 図 2-1 に Oracle Application Server インスタンスのアーキテクチャを示します このアーキテクチャには インスタンス内での冗長プロセスと自動リカバリを可能にする前述の機能も含まれています 2-8 Oracle Application Server 10g 高可用性ガイド

35 中間層の高可用性を実現するための機能とコンポーネント 図 2-1 Oracle Application Server インスタンスのアーキテクチャ 中間層の高可用性 2-9

36 中間層の高可用性を実現するための機能とコンポーネント Oracle Application Server Cluster Oracle Application Server Cluster(OracleAS Cluster) は 連携して機能することによってスケーラビリティと可用性がシングル インスタンスよりも大幅に向上するように構成されたアプリケーション サーバー インスタンスのセットです OracleAS Cluster を使用すると 単一のホストで発生するシングル ポイント障害が取り除かれます 単一のアプリケーション サーバー インスタンスでは 単一のホストのオペレーティング リソースを利用しますが クラスタでは複数のホストにわたって 多数の CPU にアプリケーションの実行を分散できます 単一のアプリケーション サーバー インスタンスは ホストやオペレーティング システムの障害に対して脆弱ですが クラスタではオペレーティング システムやホストの損失が発生しても引き続き機能します これらの障害はクライアントに対して透過的です この項の項目は次のとおりです Oracle Application Server Cluster のタイプ リポジトリを使用して管理される Oracle Application Server Cluster のクラスタレベルの構成 リポジトリを使用して管理される Oracle Application Server Cluster に結合するための Oracle Application Server インスタンスの要件 リポジトリを使用して管理される Oracle Application Server Cluster 内の Oracle Application Server インスタンスの特性 Oracle Application Server Cluster のタイプ Oracle Application Server Cluster には ファイルベースのリポジトリまたはデータベース リポジトリで管理する Oracle Application Server Cluster と 手動で構成する Oracle Application Server Cluster の 2 つのタイプがあります 注意 : OracleAS Cluster としてクラスタリングできるのは J2EE and Web Cache インストール タイプの OracleAS インスタンスのみです ファイルベースのリポジトリまたはデータベース リポジトリで管理される Oracle Application Server Cluster は 同一の構成とアプリケーション デプロイを持つアプリケーション サーバー インスタンスの集まりで構成されます Oracle Application Server Cluster により クラスタの一部であるインスタンス間で同質性が確保されるため クラスタはシングル インスタンスと見なされ シングル インスタンスとして機能します リポジトリを使用して管理される Oracle Application Server Cluster は クラスタ内のすべてのアプリケーション サーバー インスタンス間で構成情報を伝播します これにより 構成とデプロイが簡略化されます 2-10 Oracle Application Server 10g 高可用性ガイド

37 中間層の高可用性を実現するための機能とコンポーネント リポジトリを使用して管理される Oracle Application Server Cluster には Oracle Application Server Cluster managed using database repository と Oracle Application Server Cluster managed using file-based repository の 2 つのタイプがあります Oracle Application Server Cluster managed using database repository これらのクラスタでは データベースを使用してメタデータと構成情報が格納されます メタデータと構成情報は Infrastructure ホスト上にある Oracle Application Server Metadata Repository に格納されるため このタイプの Oracle Application Server Cluster では Oracle Application Server Infrastructure が必要です Oracle Application Server Cluster managed using file-based repository これらのクラスタでは リポジトリ ホストリポジトリ ホストとしてアプリケーション サーバー インスタンスが指定されます リポジトリ ホストは ファイル システムを使用して クラスタのメタデータと構成情報を保存する Oracle Application Server Metadata Repository を格納します 図 2-2 に データベース リポジトリを使用して管理される Oracle Application Server Cluster の例を示します 図 2-2 の例では 3 つのアプリケーション サーバー インスタンスがあります 3 つのアプリケーション サーバー インスタンスはすべて 同じ Oracle Application Server Metadata Repository を共有しています したがって このクラスタ内の 3 つのアプリケーション サーバー インスタンスはすべて同じファームの一部となります アプリケーション サーバー インスタンス 1 および 2 は データベース リポジトリを使用して管理される Oracle Application Server Cluster の一部です クラスタの前面にはフロントエンドのロード バランサが配置されています ロード バランサは Oracle Application Server Web Cache の場合もあれば ハードウェアのロード バランサ機器の場合もあります それぞれのアプリケーション サーバー インスタンスには 管理性機能である Oracle Process Manager and Notification Server(OPMN) と Distributed Configuration Management(DCM) およびインストールされたコンポーネントである Oracle HTTP Server と Oracle Application Server Containers for J2EE (OC4J) が含まれています 中間層の高可用性 2-11

38 中間層の高可用性を実現するための機能とコンポーネント 図 2-2 OracleAS Cluster のアーキテクチャ 2-12 Oracle Application Server 10g 高可用性ガイド

39 中間層の高可用性を実現するための機能とコンポーネント 手動で構成する Oracle Application Server Cluster では クラスタ内の各インスタンスの構成を管理者が手動で行います ( 図 2-3) Oracle Application Server Cluster を手動で構成する場合は アプリケーション サーバー インスタンスのグループをクラスタとして機能させる作業を管理者が行います これらの Oracle Application Server Cluster における構成およびアプリケーション デプロイ情報のメンテナンスは 難しい作業になることがあります 手動で構成された Oracle Application Server Cluster の場合 スケーラビリティと可用性は確保されますが 管理性は確保されません クラスタ間でのアプリケーション サーバー インスタンスの構成の同期化は 管理者が担当することになります 図 2-3 手動で構成された OracleAS Cluster 関連項目 : プロセスの監視と再起動 (2-22 ページ ) 分散構成による高可用性 (2-23 ページ ) OracleAS Cluster でのファイルベースのリポジトリの使用 (4-12 ページ ) 中間層の高可用性 2-13

40 中間層の高可用性を実現するための機能とコンポーネント リポジトリを使用して管理される Oracle Application Server Cluster のクラスタレベルの構成 リポジトリを使用して管理される Oracle Application Server Cluster は 同一の構成情報を持つアプリケーション サーバー インスタンスの集まりで構成されます Oracle Application Server では Oracle Application Server Cluster 内のすべてのアプリケーション サーバー インスタンス間で構成情報が伝播されます クラスタ内の各アプリケーション サーバー インスタンスでは 同じ基本構成が使用されます 基本構成は クラスタレベルの構成情報によって定義されます アプリケーション サーバー インスタンスが Oracle Application Server Cluster に結合されると Distributed Configuration Management システムによって新しいインスタンスに基本構成が適用され 新しいインスタンスは同じクラスタレベルの構成を使用するようになります Application Server Control または dcmctl を使用して アプリケーションをインスタンスにデプロイするか またはアプリケーション サーバー インスタンスを変更すると クラスタレベルの構成の変更内容が Oracle Application Server Cluster 間で他のすべてのアプリケーション サーバー インスタンスに伝播されます クラスタレベルの構成では 特定のインスタンス固有のパラメータが除外されます インスタンス固有のパラメータは クラスタ間ですべてのアプリケーション サーバー インスタンスには伝播されません インスタンス固有のパラメータを変更した場合 その変更内容は伝播されません このパラメータは 変更を加えた特定のアプリケーション サーバー インスタンスにのみ適用されます 関連項目 : クラスタレベルの構成の変更および OC4J インスタンスの変更 (4-25 ページ ) リポジトリを使用して管理される Oracle Application Server Cluster に結合するための Oracle Application Server インスタンスの要件 アプリケーション サーバー インスタンスを Oracle Application Server Cluster に結合するには そのアプリケーション サーバー インスタンスがクラスタリング可能である必要があります アプリケーション サーバー インスタンスをクラスタリング可能にするには 次の条件を満たす必要があります 1. アプリケーション サーバー インスタンスが Oracle Application Server Cluster が存在するファームの一部である必要があります アプリケーション サーバー インスタンスは インストール時またはインストール後に Application Server Control を使用して OracleAS Metadata Repository に関連付けることができます 2. クラスタ内の各アプリケーション サーバー インスタンスは 同じタイプのオペレーティング システム (UNIX など ) にインストールする必要があります 3. 各アプリケーション サーバー インスタンスには 1 つの Oracle HTTP Server のみをインストールできます 4. 各アプリケーション サーバー インスタンスには 1 つ以上の OC4J インスタンスをインストールできます 2-14 Oracle Application Server 10g 高可用性ガイド

41 中間層の高可用性を実現するための機能とコンポーネント 関連項目 : OracleAS Cluster へのアプリケーション サーバー インスタンスの追加 (4-9 ページ ) リポジトリを使用して管理される Oracle Application Server Cluster 内の Oracle Application Server インスタンスの特性 クラスタに結合されたアプリケーション サーバー インスタンスには 次の特性があります 各アプリケーション サーバー インスタンスでは 同じクラスタレベルの構成が使用されます つまり 任意のクラスタレベルのパラメータを変更すると 変更内容はクラスタ内のすべてのアプリケーション サーバー インスタンスに伝播されます 1 つのアプリケーション サーバー インスタンスにアプリケーションをデプロイすると そのアプリケーションはクラスタ間ですべてのアプリケーション サーバー インスタンスに伝播されます 実際には そのアプリケーションはアプリケーション サーバー インスタンス内の OC4J インスタンスにデプロイされ クラスタの他のアプリケーション サーバー インスタンス内の同じ OC4J インスタンスに伝播されます デプロイしたアプリケーションの構成の一部を変更することができます この変更は クラスタ間で他のアプリケーション サーバー インスタンス内の同じ OC4J インスタンスに伝播されます 通常 クラスタリングの管理 構成およびアプリケーション デプロイは Oracle Enterprise Manager を使用して処理します コマンドライン ツールを使用する場合は Distributed Configuration Management のコマンドライン ツール dcmctl を使用できます 基本構成は クラスタに結合される最初のアプリケーション サーバー インスタンスから作成されます アプリケーション サーバー インスタンスは クラスタから削除できます クラスタから削除する際 アプリケーション サーバー インスタンスは停止されます 最後のアプリケーション サーバー インスタンスを削除しても クラスタはそのまま保持されます クラスタを削除するには クラスタ自体を削除する必要があります 関連項目 : OracleAS Cluster 内のアプリケーション サーバー インスタンスの管理 (4-9 ページ ) dcmctl コマンドの詳細は Distributed Configuration Management リファレンス ガイド を参照してください 中間層の高可用性 2-15

42 中間層の高可用性を実現するための機能とコンポーネント Oracle Application Server Web Cache クラスタ 複数の OracleAS Web Cache インスタンスをクラスタリングして 1 つの論理キャッシュを作成できます このキャッシュは 物理的に複数のノード間に分散できます あるノードで障害が発生しても 障害が発生したノードが処理していたリクエストを 同じクラスタ内の残りのノードで処理できます ノードの障害はクラスタ内の残りのノードによって検出されます これらのノードによって 障害が発生したメンバーのキャッシュ可能なコンテンツの所有権が引き継がれます OracleAS Web Cache クラスタの前面に配置されたロード バランシング メカニズム ( ハードウェアのロード バランサ機器など ) によって 動作中の OracleAS Web Cache ノードにリクエストがリダイレクトされます さらに OracleAS Web Cache クラスタは OracleAS インスタンスの可用性を向上させます OracleAS インスタンスの前で静的および動的コンテンツをキャッシュすることにより OracleAS Web Cache によるリクエスト処理が可能になります これにより OracleAS インスタンス ( 特に Oracle HTTP Server) でリクエストを処理する必要性を軽減できます OracleAS インスタンスの負荷とストレスが減少し インスタンス内のコンポーネントの可用性が向上します Oracle Application Server Web Cache は Oracle HTTP Server に対してステートレスまたはステートフル ロード バランシング機能を果たすこともできます ロード バランシングは それぞれの Oracle HTTP Server の利用可能な容量の割合 ( すなわち 各 Oracle HTTP Server の重み付けされた利用可能容量 ) に基づいて実行されます 重み付けされた利用可能容量が複数の Oracle HTTP Server 間で等しい場合 OracleAS Web Cache はラウンドロビンを使用して負荷を分散します 重み付けされた利用可能容量を計算する式については Oracle Application Server Web Cache 管理者ガイド を参照してください Oracle HTTP Server で障害が発生すると OracleAS Web Cache は残りの Oracle HTTP Server に負荷を再分散し 障害が発生したサーバーがオンラインに復帰するまでこのサーバーを断続的にポーリングします その後 OracleAS Web Cache は スコープ内の回復した Oracle HTTP Server で負荷分散を再計算します 関連項目 : HTTP サービスの高可用性 (2-26 ページ ) Oracle Application Server Web Cache 管理者ガイド 2-16 Oracle Application Server 10g 高可用性ガイド

43 中間層の高可用性を実現するための機能とコンポーネント OC4J アイランド Oracle Application Server では 複数の方法で OC4J インスタンスの高可用性を実現できます 高可用性は アプリケーション サーバー インスタンス内と 複数のアプリケーション サーバー インスタンスで構成されるクラスタ間の両方で提供されます この項の項目は次のとおりです OC4J アイランドによる Web アプリケーションのセッション状態レプリケーション EJB クラスタリングを使用したステートフル セッション EJB の高可用性 JNDI ネームスペースのレプリケーション OC4J Java Object Cache を使用した分散キャッシュ この項で説明する高可用性機能に加えて Oracle Application Server の他の機能で OC4J プロセスの高可用性を実現することもできます これらの機能には Oracle HTTP Server のロード バランシング機能や プロセスの監視と再起動を自動的に行う Oracle Process Manager and Notification Server などがあります 関連項目 : HTTP サービスの高可用性 (2-26 ページ ) プロセスの監視と再起動 (2-22 ページ ) OC4J アイランドによる Web アプリケーションのセッション状態レプリケーション ステートフル Web アプリケーションを OC4J にデプロイすると 場合によっては 同じクライアントからの複数の HTTP リクエストがこのアプリケーションにアクセスする必要が生じます 一方 OC4J サーバーで実行中のアプリケーションで OC4J プロセスの障害が発生すると クライアント リクエストに関連付けられている状態が失われる恐れがあります Oracle Application Server は 次の 3 つの方法でこうした障害から保護します ステート セーフ アプリケーションでは その状態をデータベースまたは他の永続ストレージ システムに保存して サーバー停止時における状態の損失を防ぎます アプリケーションの状態を永続ストレージに継続的に書き込むことにより 当然 パフォーマンスへの負荷が発生します ステートレス アプリケーションには リクエスト間で維持する必要のある状態はありません このため ステートレス アプリケーションでは サーバー停止時の状態の整合性に関する考慮事項はありません 別のアクティブ サーバーがリクエストを処理できます ステートレス アプリケーションでは ステート セーフ アプリケーションやステートフル アプリケーションと比べて容易に高可用性を実現できます 中間層の高可用性 2-17

44 中間層の高可用性を実現するための機能とコンポーネント ステートフル アプリケーションでは OC4J アイランドで OC4J セッション状態レプリケーションを使用して 1 つのアプリケーション サーバー インスタンス内の複数のプロセス間 およびクラスタ内の他のノードで実行される複数のアプリケーション インスタンス間で セッション状態を自動的にレプリケートできます OC4J プロセスをアイランドにグループ化すると セッション状態レプリケーションがサポートされ Web アプリケーションの高可用性を実現できます Oracle HTTP Server の mod_oc4j リクエスト ルーティングとともに OC4J アイランドを使用すると ソフトウェアまたはハードウェアに問題が発生したときにステートフル フェイルオーバーを利用できます たとえば あるアイランドの一部である OC4J プロセスで障害が発生すると OPMN によってこの障害が mod_oc4j に通知されます mod_oc4j は 同じアイランド内の別の OC4J プロセスにリクエストをルーティングします ソフトウェアの問題を防止する Web アプリケーションのセッション状態 OC4J プロセスの障害やハングなどのソフトウェアの問題から保護するには 複数の OC4J プロセスを同じ OC4J アイランド内で実行するように OC4J インスタンスを構成します OC4J アイランド内のプロセスは それぞれのセッション状態を相互に伝達します この構成を使用すると アプリケーション サーバー インスタンスで実行している複数の OC4J プロセス間で状態をレプリケートすることにより フェイルオーバーと高可用性が実現します 障害が発生した場合 Oracle HTTP Server は OC4J アイランド内のアクティブな ( 動作中の )OC4J プロセスにリクエストを転送します この場合 クライアントの Web アプリケーション状態は維持されます サービスの損失はクライアントからは見えません 図 2-4 に アプリケーション サーバー インスタンス内で発生するこのタイプのソフトウェア障害を示します 2-18 Oracle Application Server 10g 高可用性ガイド

45 中間層の高可用性を実現するための機能とコンポーネント 図 2-4 OC4J インスタンス内の OC4J アイランドにおける Web アプリケーションのセッション状態のフェイルオーバー ハードウェアの問題を防止する Web アプリケーションのセッション状態レプリケーションアプリケーション サーバー インスタンスを実行しているノードの障害など ハードウェアの問題から保護するには OracleAS Cluster 内の複数ノードにあるアプリケーション サーバー インスタンス間で OC4J アイランドを構成します 複数のアプリケーション サーバー インスタンスで同じ名前を使用するように OC4J アイランドを構成すれば OC4J プロセスは OracleAS Cluster 間でセッション状態の情報を共有できます アプリケーション サーバー インスタンスを実行しているノードの停止など アプリケーション サーバー インスタンスに障害が発生したか または使用できなくなったときは Oracle HTTP Server が 使用可能なアプリケーション サーバー インスタンスの OC4J プロセスにリクエストを転送します このように Oracle HTTP Server では クラスタ内のアクティブな ( 動作中の )OC4J プロセスにのみリクエストが転送されます この場合 クライアントの Web アプリケーション状態は維持されます クライアントが異常に気付くことはありません 中間層の高可用性 2-19

46 中間層の高可用性を実現するための機能とコンポーネント 図 2-5 に OracleAS Cluster 内で構成された OC4J アイランドを示します 図 2-5 OracleAS Cluster 内の Web アプリケーションのセッション状態のフェイルオーバー 高可用性を備えた OC4J アイランドの構成 OC4J プロセス数が最小である状態を維持しつつ ソフトウェアまたはハードウェア障害から保護するには 個々のノードで実行している複数のアプリケーション サーバー インスタンス上の同じアイランド内に OC4J プロセスを 2 つ以上構成する必要があります たとえば インスタンス 1 とインスタンス 2 の 2 つのアプリケーション サーバー インスタンスがある場合は それぞれのアプリケーション サーバー インスタンスの default_island 内に 2 つの OC4J プロセスを構成できます この構成では ステートフル セッションのアプリケーションがハードウェアおよびソフトウェア障害から保護され 次のいずれかのタイプの障害が発生しても クライアントの状態は維持されます OC4J プロセスの 1 つで障害が発生すると 同じアプリケーション サーバー インスタンスの default_island 内の別の OC4J プロセスにクライアント リクエストがリダイクレクトされます 状態は維持され クライアントが異常に気付くことはありません アプリケーション サーバー インスタンス 1 が異常終了すると アプリケーション サーバー インスタンス 2 の default_island 内の OC4J プロセスにクライアントがリダイクレクトされます 状態は維持され クライアントが異常に気付くことはありません 2-20 Oracle Application Server 10g 高可用性ガイド

47 中間層の高可用性を実現するための機能とコンポーネント 関連項目 : OC4J アイランドおよび OC4J プロセスの構成 (4-31 ページ ) EJB クラスタリングを使用したステートフル セッション EJB の高可用性 OC4J では ステートフル セッション EJB を構成して アプリケーション サーバー インスタンス内で実行されているすべての OC4J プロセス間または OracleAS Cluster 間で状態をレプリケートできます この EJB レプリケーション構成では 複数の OC4J プロセスで同じステートフル セッション EJB のインスタンスを実行することにより ステートフル セッション EJB の高可用性が実現します 注意 : 高可用性を目的とする EJB レプリケーション (EJB クラスタ ) の使用は OracleAS Cluster に依存せず OracleAS Cluster の内部または外部にあるノード間でインストールされた複数のアプリケーション サーバー インスタンスを使用できます EJB クラスタでは ステートフル セッション EJB の高可用性が実現します EJB クラスタでは 同じマルチキャスト アドレス経由で通信する複数の OC4J プロセス間でこれらの EJB をフェイルオーバーできます このように ステートフル セッション EJB でレプリケーションを使用すると プロセスとノードの障害から保護し Oracle Application Server で実行されているステートフル セッション EJB の高可用性を実現できます 関連項目 : OracleAS Cluster 用の EJB アプリケーション状態レプリケーションの構成 (4-28 ページ ) Oracle Application Server Containers for J2EE ユーザーズ ガイド Oracle Application Server Containers for J2EE Enterprise JavaBeans 開発者ガイド JNDI ネームスペースのレプリケーション EJB クラスタリングを有効にすると OracleAS Cluster の OC4J インスタンス間の JNDI ネームスペースのレプリケーションも有効になります 1 つの OC4J インスタンス内の JNDI ネームスペースへの新規バインドは OracleAS Cluster 内の他の OC4J インスタンスに伝播されます 再バインドとアンバインドはレプリケートされません このレプリケーションは OC4J アイランドの有効範囲外で行われます つまり OC4J インスタンス内の複数のアイランドは 同じレプリケート済 JNDI ネームスペースへの可視性を持ちます 関連項目 : Oracle Application Server Containers for J2EE サービス ガイド 中間層の高可用性 2-21

48 中間層の高可用性を実現するための機能とコンポーネント プロセスの監視と再起動 OC4J Java Object Cache を使用した分散キャッシュ Oracle Application Server Java Object Cache では OC4J にデプロイされたアプリケーションに対する高可用性ソリューションとして機能する分散キャッシュが提供されます Java Object Cache は あらゆる Java プラットフォーム上のあらゆる Java アプリケーションで使用可能な Java オブジェクトのインプロセス キャッシュです これにより アプリケーションで 複数のリクエストおよびユーザー間でオブジェクトを共有し 複数のプロセス間でオブジェクトのライフサイクルを調整することが可能になります Java Object Cache は 同じ OC4J アイランド アプリケーション サーバー インスタンスまたは Oracle Application Server Cluster に属していないプロセスも含めた OC4J プロセス間でのデータ レプリケーションを可能にします Java Object Cache を使用すると オブジェクトの生成元のアプリケーションがどれであるかにかかわらず 共有 Java オブジェクトがローカルにキャッシュされるため パフォーマンスが向上します これにより 可用性も向上します オブジェクトのソースが使用できなくなっても ローカルにキャッシュされたバージョンは引き続き使用できます 関連項目 : Java Object Cache の使用方法の詳細は Oracle Application Server Web Services 開発者ガイド の Java Object Cache に関する章を参照してください アプリケーション サーバー インスタンス内および OracleAS Cluster 間で Oracle Process Manager and Notification Server(OPMN) は Oracle Application Server コンポーネントを監視します 監視対象のコンポーネントには Oracle HTTP Server OC4J OracleAS Web Cache Oracle Application Server Reports Services(OracleAS Reports Services) などがあります それ自体が Oracle Application Server コンポーネントである OPMN システムは Oracle Application Server プロセスを監視し 障害が発生したプロセスを自動的に再起動することによって Oracle Application Server の高可用性の実現を支援します あるプロセスが使用できなくなると OPMN は そのプロセスが使用できないことを Oracle Application Server の他の特定のコンポーネントに通知します たとえば OracleAS Cluster で OC4J プロセスに障害が発生すると Oracle HTTP Server の mod_oc4j モジュールにその障害が通知されます OPMN がイベントを使用して障害が発生した OC4J プロセスの再起動を通知するまで このモジュールはその OC4J プロセスにリクエストを送信しません OPMN は 次のサブコンポーネントで構成されます Oracle Process Manager Oracle Notification Server 2-22 Oracle Application Server 10g 高可用性ガイド

49 中間層の高可用性を実現するための機能とコンポーネント Oracle Process Manager Oracle Process Manager は Oracle Application Server プロセスの起動 再起動 停止および障害の検出を行います Oracle Process Manager は 次のいずれかの方法でプロセスを起動または停止できます opmn.xml 構成ファイルのディレクティブ Application Server Control の操作の選択 (OC4J インスタンスなどのコンポーネントの起動や停止など ) opmnctl コマンドライン ユーティリティの使用 分散構成による高可用性 Oracle Notification Server Oracle Notification Server は 障害 リカバリ 起動 およびコンポーネント間のその他の関連する通知のための通信メカニズムです この通知システムは サブスクライバ / パブリッシャ モデルに基づいて機能します このモデルでは 特定タイプのイベントの受信を必要とするコンポーネントが Oracle Notification Server をサブスクライブします こうしたイベントがパブリッシュされると Oracle Notification Server は 該当するすべてのサブスクライバにこのイベントを送信します Oracle Application Server Cluster では Oracle HTTP Server は Oracle Notification Server を使用して通信し Oracle Application Server Cluster 間でアクティブな OC4J プロセスを認識します この通信メカニズムによって 各 Oracle HTTP Server は Oracle Application Server Cluster 内で動作中の OC4J プロセスを認識し それらのプロセスに対して受信リクエストのロード バランシングを行うことができます 関連項目 : Oracle Process Manager and Notification Server 管理者ガイド Oracle Application Server では Distributed Configuration Management(DCM) システムを使用して Oracle Application Server Cluster におけるクラスタレベルの構成を管理します DCM では 次の操作をサポートしています 新しいアプリケーション サーバー インスタンスがクラスタに結合されると DCM はクラスタ内のすべてのインスタンスに基本構成を自動的にレプリケートします DCM は アプリケーション デプロイとその構成の変更をクラスタ間ですべてのアプリケーション サーバー インスタンスに伝播します Oracle Application Server の高可用性では Oracle Application Server Cluster 内のシステムが停止しても DCM のシングル ポイント障害は発生しません DCM は クラスタ内の使用可能な全ノードで引き続き使用できます DCM を使用すると クラスタ内のデプロイおよび構成エラーを減らすことができます DCM を使用しない場合 これらのエラーはシステムの停止時間をもたらす大きな原因になることがあります 中間層の高可用性 2-23

50 中間層の高可用性を実現するための機能とコンポーネント Enterprise Manager では DCM コマンドを使用してアプリケーション サーバーの構成と配置を行います dcmctl コマンドを使用して DCM コマンドを手動で発行することもできます DCM は 次の構成コマンドを制御します クラスタの作成または削除 アプリケーション サーバー インスタンスのクラスタへの追加またはクラスタからの削除 アプリケーション サーバー インスタンス間での構成変更の同期化 クラスタの構成変更またはクラスタへのアプリケーションのデプロイを行う際は 次の点に留意してください Enterprise Manager が稼動中でクラスタを管理している場合は クラスタリングされたアプリケーション サーバー インスタンスを実行している任意のホストから DCM コマンドライン ツールを起動できます DCM は リクエストされた機能を Enterprise Manager に通知し Enterprise Manager は クラスタ内の他のアプリケーション サーバー インスタンス上の別の DCM 管理機能とインタフェースをとり クラスタレベルの構成またはアプリケーション デプロイを行います Enterprise Manager が稼動中でなく クラスタを管理していない場合 構成変更をクラスタ間で動的に適用するには それぞれのクラスタで DCM デーモンが実行されている必要があります DCM デーモンを起動するには クラスタ内の各アプリケーション サーバー インスタンスで DCM コマンドライン ツール dcmctl を実行します その他の高可用性コンポーネント 関連項目 : Distributed Configuration Management リファレンス ガイド Oracle Application Server の可用性を向上させるため いくつかの外部コンポーネントを使用できます これらのコンポーネントについては 次の各項で説明します 外部ロード バランサによる可用性の向上 オペレーティング システム クラスタによる可用性の向上 2-24 Oracle Application Server 10g 高可用性ガイド

51 中間層の高可用性を実現するための機能とコンポーネント 外部ロード バランサによる可用性の向上 外部のロード バランサを使用すると クラスタリングされているかどうかに関係なく Oracle Application Server インスタンスの可用性を向上させることができます クライアントは ロード バランサを介してクラスタにアクセスします クラスタ構成は クライアントからは隠されます リクエストはクラスタ内のどのアプリケーション サーバー インスタンスでも処理できるので ロード バランサは クラスタ内の任意のインスタンスにリクエストを送信できます 管理者は 追加のアプリケーション サーバー インスタンスをクラスタに導入することにより システムの能力を高めることができます これらのインスタンスを複数のノードにインストールすれば ノードの障害に備えて冗長性を確保できます ロード バランサを使用すると 複数のノードにインストールされたクラスタリングできない Oracle Application Server インスタンス (Portal や Wireless など ) の可用性を向上させることもできます ロード バランサがノードのセットを処理するように構成されていれば リクエストは適切にルーティングされます 外部ロード バランサのタイプ Oracle Application Server インスタンスとともに使用可能なロード バランサには ハードウェア ロード バランサとネットワーク ロード バランサの 2 つのタイプがあります 表 2-4 に その要約を示します 表 2-1 外部ロード バランサのタイプの要約 ロード バランサのタイプ ハードウェア ロード バランサ Windows ネットワーク ロード バランサ (Oracle Application Server の Windows バージョンに適用 ) 説明 ハードウェアのロード バランシングでは Oracle Application Server インスタンスのグループまたは OracleAS Web Cache の前面に Big-IP や Alteon などのハードウェア ロード バランサを配置します ハードウェア ロード バランサは クライアントには透過的な方法で Oracle HTTP Server または OracleAS Web Cache のインスタンスにリクエストをルーティングします 一部の Windows オペレーティング システムでは オペレーティング システムを使用してネットワーク ロード バランシングを実行できます たとえば Microsoft Advanced Server では NLB 機能を使用して 同じ仮想 IP アドレスまたは MAC アドレスを共有している異なるマシンにリクエストを送信できます これらのサーバー自体をオペレーティング システム レベルでクラスタリングする必要はありません 外部ロード バランシングによる高可用性の利点クラスタの使用には スケーラビリティ 可用性および管理性という 3 つの大きな利点があります ロード バランシングでは アクセス ポイントの提供によってスケーラビリティが向上します このアクセス ポイントを通じて 使用可能な多数のインスタンスのいずれかにリクエストがルーティングされます ロード バランサが機能しているグループにインスタンスを追加すれば ユーザーの追加に対応できます 中間層の高可用性 2-25

52 HTTP サービスの高可用性 ロード バランシングでは 最も使用可能度が高いインスタンスにリクエストをルーティングすることにより 可用性が向上します あるインスタンスが停止した場合 または著しくビジーである場合 ロード バランサは別のアクティブなインスタンスにリクエストを送信できます ロード バランシングでは 最も使用可能度が高いインスタンスにアプリケーション デプロイとシステム構成のリクエストをルーティングすることにより システムの管理性が向上します あるインスタンスが停止した場合 または著しくビジーである場合 ロード バランサは別のアクティブなインスタンスにリクエストを送信できます オペレーティング システム クラスタによる可用性の向上 オペレーティング システム クラスタを使用するには オペレーティング システムまたはその他のクラスタリング システム ソリューション (HP MC Service Guard など ) によって作成されたハードウェア クラスタに Oracle Application Server をインストールします オペレーティング システム クラスタは Oracle Application Server 10g(9.0.4) でサポートされています HTTP サービスの高可用性 Oracle HTTP Server と Oracle Application Server Web Cache では Oracle Application Server リクエストに対して HTTP および HTTPS リクエスト処理を行うことができます リクエストされたコンテンツがキャッシュされている場合は Oracle HTTP Server または Web Cache からの応答によって各 HTTP リクエストにレスポンスすることが可能です この項の項目は次のとおりです Web Cache と Oracle HTTP Server の高可用性の要約 mod_oc4j を使用した OC4J ロード バランシング 2-26 Oracle Application Server 10g 高可用性ガイド

53 HTTP サービスの高可用性 Web Cache と Oracle HTTP Server の高可用性の要約 表 2-2 に Oracle HTTP Server および OracleAS Web Cache コンポーネントに対する Oracle Application Server の高可用性機能の要約を示します 表 2-2 Oracle HTTP Server と OracleAS Web Cache の高可用性の特性 コンポーネント OracleAS Web Cache ノード障害からの保護 OracleAS Web Cache Cluster は シングル ポイント障害から保護されています このクラスタの前面に外部ロード バランサを配置して 動作中の OracleAS Web Cache ノードにリクエストをルーティングする必要があります サービス障害からの保護 OracleAS Web Cache クラスタでは 各クラスタ メンバーの特定の URL に対して ping が実行され その URL が使用可能であることが確認されます プロセス障害からの保護 OPMN は OracleAS Web Cache プロセスを監視し 障害発生時にはそのプロセスを再起動します 自動再ルーティング クラスタ内の OracleAS Web Cache メンバーは 相互に ping を実行してクラスタ メンバーの障害の有無を確認します 状態レプリケーション OracleAS Web Cache クラスタリングでは レプリケートされたオブジェクトが管理されます 構成のクローニング OracleAS Web Cache クラスタでは クラスタ間で一貫した構成が維持されます 中間層の高可用性 2-27

54 HTTP サービスの高可用性 表 2-2 Oracle HTTP Server と OracleAS Web Cache の高可用性の特性 ( 続き ) コンポーネント Oracle HTTP Server ノード障害からの保護 OracleAS Cluster は シングル ポイント障害から保護されています ロード バランサは Oracle HTTP Server インスタンスの前面に配置する必要があります 配置するロード バランサは 外部ロード バランサの場合もあれば OracleAS Web Cache の場合もあります サービス障害からの保護 送信先の最初の Oracle HTTP Server からレスポンスがない場合や URL の ping の結果から Oracle HTTP Server に障害が発生したと思われる場合 Oracle HTTP Server の前面に配置されたロード バランサは 別の Oracle HTTP Server にリクエストを送信します ロード バランサは OracleAS Web Cache の場合もあればハードウェア機器の場合もあります プロセス障害からの保護 OPMN は Oracle HTTP Server プロセスを監視し 障害発生時にはそのプロセスを再起動します さらに OracleAS Cluster 内の別の Oracle HTTP Server プロセスで障害が発生した場合 OPMN はそれぞれの Oracle HTTP Server に障害を通知します 自動再ルーティング 最初の Oracle HTTP Server からレスポンスがない場合 Oracle HTTP Server の前面に配置されたロード バランサは 別の Oracle HTTP Server にリクエストを自動的に再ルーティングします 状態レプリケーション なし 構成のクローニング OracleAS Cluster では DCM によってクラスタ内の他の Oracle HTTP Server 間で構成をレプリケートできます 関連項目 : Oracle Application Server Web Cache クラスタ (2-16 ページ ) プロセスの監視と再起動 (2-22 ページ ) 外部ロード バランサのタイプ (2-25 ページ ) 2-28 Oracle Application Server 10g 高可用性ガイド

55 HTTP サービスの高可用性 mod_oc4j を使用した OC4J ロード バランシング Oracle HTTP Server のモジュール mod_oc4j は OC4J により処理される HTTP リクエストに対してインテリジェント ルーティングを提供します mod_oc4j が提供するインテリジェント ルーティングは Oracle Application Server の重要な高可用性機能です OC4J プロセスで障害が発生すると Oracle Process Manager and Notification Server はその障害を検出し mod_oc4j は 障害の発生した OC4J プロセスが再起動されるまでその OC4J プロセスにリクエストを送信しません 通常 mod_oc4j はステートレス HTTP リクエストを処理します ステートフル HTTP リクエストは 前回のリクエストを処理した OC4J プロセスに転送されるからです (Oracle Process Manager and Notification Server との通信を介して そのプロセスを使用できないと mod_oc4j が判断した場合は除きます この場合 mod_oc4j は使用可能な OC4J にリクエストを転送します ) mod_oc4j の構成オプションを使用すると 必要なルーティングのタイプと複雑さに応じて 異なるロード バランシング ルーティング アルゴリズムを指定できます 表 2-3 に mod_oc4j が提供するルーティング スタイルの要約を示します 表 2-3 には ルーティング スタイルごとに各種のアルゴリズムが記載されています これらのアルゴリズムを構成することにより ルーティングの動作を変更できます mod_oc4j のこれらの構成オプションによって 処理対象の受信 HTTP リクエストの送信先となる OC4J プロセスが決まります 関連項目 : OracleAS Cluster を使用した mod_oc4j ロード バランシング (4-33 ページ ) mod_oc4j ロード バランシング オプションによる 重み付けされたルーティングの使用およびローカル アフィニティの選択に関する詳細は Oracle HTTP Server 管理者ガイド を参照してください 中間層の高可用性 2-29

56 HTTP サービスの高可用性 表 2-3 mod_oc4j のルーティング アルゴリズムの要約 ルーティングの方法 ラウンドロビン ランダム メトリックベース 説明 単純なラウンドロビン構成では Oracle HTTP Server を実行しているアプリケーション サーバー インスタンスのすべてのリモートおよびローカル OC4J プロセスが 順序付けられたリストに配置されます Oracle HTTP Server は 最初のリクエストに対して OC4J プロセスを無作為に選択します Oracle HTTP Server は 以降のリクエストごとに別の OC4J プロセスにラウンドロビン法でリクエストを転送します ラウンドロビン構成は ローカル アフィニティおよび重み付けされたルーティング オプションをサポートしています 単純なランダム構成では Oracle HTTP Server を実行しているアプリケーション サーバー インスタンスのすべてのリモートおよびローカル OC4J プロセスが 順序付けられたリストに配置されます Oracle HTTP Server は リクエストごとに OC4J プロセスを無作為に選択し そのインスタンスにリクエストを転送します ランダム構成は ローカル アフィニティおよび重み付けされたルーティング オプションをサポートしています メトリックベース構成では Oracle HTTP Server を実行しているアプリケーション サーバー インスタンスのすべてのリモートおよびローカル OC4J プロセスが 順序付けられたリストに配置されます OC4J プロセスはそれぞれのビジー状況を Oracle HTTP Server に定期的に通知し Oracle HTTP Server は この情報を使用して よりビジーでない OC4J プロセスにリクエストを送信します メトリックベースの構成は ローカル アフィニティ オプションをサポートしています OC4J ローカル アフィニティおよび重み付けされたルーティング オプションを使用したロード バランシング mod_oc4j オプションを使用すると OC4J リクエストをルーティングするためのルーティング方法を選択できます ラウンドロビンまたはランダム ルーティングを選択した場合 ローカル アフィニティまたは重み付けされたルーティング オプションも使用できます メトリックベース ルーティングを選択した場合は ローカル アフィニティ オプションも使用できます 重み付けされたルーティング オプションを使用すると mod_oc4j のノード別の構成に基づいて ノード上の OC4J プロセスに重みが関連付けられます リクエストのルーティング時 mod_oc4j は ルーティングの重みを使用してリクエストの割当て先となる OC4J プロセスを決定します このように 異なるノードで実行されている OC4J プロセスに異なる重みを割り当てることができます 2-30 Oracle Application Server 10g 高可用性ガイド

57 HTTP サービスの高可用性 ローカル アフィニティ オプションを使用すると リクエスト処理に使用できる OC4J プロセスの 2 つのリスト ( ローカル リストとリモート リスト ) が mod_oc4j によって保持されます ローカル リストのプロセスが使用可能な場合 リクエストはランダム ルーティング法によってローカルに割り当てられます メトリックベース ルーティングでは メトリックベース ルーティングが使用されます ローカル リストに使用可能なプロセスがない場合 mod_oc4j は ランダム法ではリモート リストから無作為にプロセスを選択します ラウンドロビン ルーティングではラウンドロビン法 メトリックベース ルーティングではメトリックベース法が使用されます mod_oc4j のルーティング アルゴリズムの選択 表 2-3 に 使用可能なルーティング オプションの要約を示します mod_oc4j で構成するルーティング アルゴリズムを選択するには Oracle HTTP Server の実行環境のタイプについて考慮する必要があります mod_oc4j で使用する構成オプションを決定する際 次のガイドラインが役に立ちます Oracle HTTP Server および OC4J を実行している複数の同一マシンで構成される Oracle Application Server Cluster の設定では ローカル アフィニティ オプションによるラウンドロビン アルゴリズムが適しています この構成を使用すると 外部ルーターによって Oracle HTTP Server および OC4J を実行している複数のマシンにリクエストが分散されます この場合 同じマシン上の OC4J プロセスがすべて使用できないような極端なケースを除けば mod_oc4j を使用して他のマシンにリクエストをルーティングすることから得られる Oracle HTTP Server のメリットはほとんどありません あるマシンの層には Oracle HTTP Server があり 別の層にはリクエストを処理する OC4J インスタンスがあるような 複数層の配置では 単純なラウンドロビンおよびメトリックベースのアルゴリズムが適しています 特定の設定で 2 つのアルゴリズムのうち最適なものを決定するには それぞれを試してみて結果を比較することが必要な場合もあります 結果はシステムの動作および受信リクエストの分散によって異なるため こうした試行が必要になります 異なる特性を持つ複数のノードで異なるアプリケーション サーバー インスタンスを実行している異機種間の配置では 重み付けされたラウンドロビンのアルゴリズムが適しています それぞれのアプリケーション サーバー インスタンスで実行している OC4J プロセスの数をチューニングすることにより 最大限の効果をあげることも可能です たとえば 重みが 4 のマシンは重みが 1 のマシンの 4 倍のリクエストを処理しますが これは重みが 4 のマシンが 4 倍の数の OC4J プロセスを実行していない場合に当てはまります 関連項目 : OracleAS Cluster を使用した mod_oc4j ロード バランシング (4-33 ページ ) mod_oc4j ロード バランシング オプションによる 重み付けされたルーティングの使用およびローカル アフィニティの選択に関する詳細は Oracle HTTP Server 管理者ガイド を参照してください 中間層の高可用性 2-31

58 J2EE の高可用性 J2EE の高可用性 J2EE リクエストは OC4J によって処理されます その際 OracleAS Web Cache と Oracle HTTP Server(mod_oc4j) を必要とします そのため J2EE サービスの高可用性では これらのコンポーネントの高可用性を実現する必要があります Oracle HTTP Server および OracleAS Web Cache の高可用性については 2-26 ページの HTTP サービスの高可用性 に説明があります OC4J の高可用性については 2-7 ページの 中間層の高可用性を実現するための機能とコンポーネント に説明があります EJB クライアント ルーティング EJB クライアント ルーティングでは mod_oc4j が Oracle HTTP Server に対して提供するルーティング機能は EJB クラスによって実行されます Active Components for Java (AC4J) アーキテクチャを使用すると EJB は疎結合方式で連携できるようになります これにより 複雑な JMS プログラミングを使用しなくても 信頼性の高い非同期の 切断された 一方向のリクエストおよびレスポンスの相互作用に対するサポートが実現します EJB クライアント ルーティングでは 適切なサービス プロバイダにサービス リクエストが自動的にルーティングされ 自動的なセキュリティ コンテキストの伝播 認可 および ID 偽装を使用できます さらに EJB フレームワークに統合された 自動的な例外ルーティングと例外処理を行うこともできます Oracle Application Server Portal の高可用性 OracleAS Portal リクエストのライフサイクルは 複数の OracleAS コンポーネントによって処理されます それらのコンポーネントには次のものがあります OracleAS Web Cache Oracle HTTP Server と次の各モジュール mod_oc4j( 中間層および Infrastructure 層 ) mod_osso(infrastructure 層における OracleAS Single Sign-On へのアクセス ) mod_plsql( 中間層では OracleAS Portal DAD Infrastructure 層では ORASSO DAD とともに使用 ) mod_oradav( 中間層 ) OC4J( ステートレス サーブレットとして Portal Page Engine を実行 ) OracleAS Portal リポジトリ (OracleAS Portal スキーマを格納し Oracle Internet Directory からユーザーのグループ メンバーシップを取得後それらをキャッシュする ) OracleAS Single Sign-On Oracle Internet Directory(Oracle Delegated Administration Services と Oracle Directory Integration and Provisioning を含む ) 2-32 Oracle Application Server 10g 高可用性ガイド

59 Oracle Application Server Portal の高可用性 様々な Web およびデータベース ポートレット プロバイダ OracleAS Portal で高可用性を実現するには これらの全コンポーネントで個々に高可用性を実現する必要があります ポートレット セキュリティおよび管理機能のために OracleAS Portal で Oracle Identity Management が使用されるため Oracle Identity Management の可用性は特に重要です 次の表に 高可用性に関する情報の参照先を前述のコンポーネント別に示します 表 2-4 OracleAS Portal リクエストに関連するコンポーネントの高可用性に関する情報 コンポーネント OracleAS Web Cache Oracle HTTP Server 参照先 2-16 ページの Oracle Application Server Web Cache クラスタ を参照してください 次の項目を参照してください Oracle Application Server Cluster (2-10 ページ ) HTTP サービスの高可用性 (2-26 ページ ) OC4J OracleAS Portal リポジトリ OracleAS Single Sign-On Oracle Internet Directory 次の項目を参照してください J2EE の高可用性 (2-32 ページ ) 注意 : Portal Page Engine はステートレスです 次の項目を参照してください このマニュアルの第 3 章 Infrastructure の高可用性 および第 5 章 Infrastructure の高可用性の管理 Oracle Application Server Portal 構成ガイド 次の項目を参照してください このマニュアルの第 3 章 Infrastructure の高可用性 および第 5 章 Infrastructure の高可用性の管理 Oracle Identity Management 概要および配置プランニング ガイド 次の項目を参照してください このマニュアルの第 3 章 Infrastructure の高可用性 および第 5 章 Infrastructure の高可用性の管理 Oracle Internet Directory 管理者ガイド Oracle Identity Management 概要および配置プランニング ガイド 中間層の高可用性 2-33

60 Oracle Application Server Portal の高可用性 表 2-4 OracleAS Portal リクエストに関連するコンポーネントの高可用性に関する情報 ( 続き ) コンポーネント Web プロバイダ データベース プロバイダ 参照先 次の項目を参照してください Oracle Application Server Cluster (2-10 ページ ) HTTP サービスの高可用性 (2-26 ページ ) OC4J アイランド (2-17 ページ ) EJB クラスタリングを使用したステートフル セッション EJB の高可用性 (2-21 ページ ) 2-16 ページの Oracle Application Server Web Cache クラスタ (OracleAS Web Cache はプロバイダへのアクセスを提供している場合があります ) mod_plsql を使用するプロバイダでは Oracle HTTP Server の高可用性が関連します 2-26 ページの HTTP サービスの高可用性 および 2-10 ページの Oracle Application Server Cluster を参照してください データベースの高可用性については 次の項を参照してください Oracle Application Server Cold Failover Cluster (3-9 ページ ) Oracle Application Server Active Failover Cluster(UNIX) (3-18 ページ ) 関連項目 : 2-16 ページの Oracle Application Server Web Cache クラスタ (OracleAS Web Cache はプロバイダへのアクセスを提供している場合があります ) 関連項目 : Oracle Application Server Portal 構成ガイド 2-34 Oracle Application Server 10g 高可用性ガイド

61 Business Intelligence の高可用性 Oracle Application Server Wireless の高可用性 一般に 企業における Oracle Application Server Wireless(OracleAS Wireless) の配置 特に電気通信オペレータのインフラストラクチャでは 非常に高度な可用性とフォルト トレランスが求められます Oracle Application Server は これらの要件に対処するフレームワークとメカニズムを提供します OracleAS Wireless はこのフレームワークに統合され これらの機能はワイヤレス配置に拡張されています OracleAS Wireless コンポーネントは OC4J アプリケーションとしてデプロイされるため OracleAS Wireless アプリケーションで高可用性を実現するように Oracle HTTP Server を構成できます さらに OracleAS Wireless ランタイムはセッション状態レプリケーションに対応しているため 複数の OC4J コンテナ間でクライアント セッションのフェイルオーバーが透過的に実行されます 標準的な高可用性の配置は 複数のネットワーク コンポーネントを伴います そのため 構成トポロジ パフォーマンスおよびセキュリティについて考慮する必要があります 詳細は Oracle Application Server Wireless 管理者ガイド の Wireless Gateway 構成 および ロード バランシングおよびフェイルオーバー の章を参照してください Business Intelligence の高可用性 Oracle Application Server の Business Intelligence コンポーネントには Oracle Application Server Reports Services と Oracle Application Server Discoverer があります 以降の各項で 次の各コンポーネントの高可用性について説明します Oracle Application Server Reports Services の高可用性 Oracle Application Server Discoverer の高可用性 Oracle Application Server Reports Services の高可用性 実行時 Oracle Application Server Reports Services(OracleAS Reports Services) は表 2-5 に記載されているコンポーネントで構成されます 表 2-5 Oracle Application Server Reports Services のランタイム コンポーネント コンポーネント Reports Servlet Reports Server 特性 クライアント リクエストを HTTP と Reports Server 間で変換します Reports Servlet は OC4J でインプロセスで実行されるため OC4J の障害および高可用性ソリューションの対象になります クライアント リクエストを処理し Reports Engine に転送します Reports Server は スタンドアロン プロセスとして実行され ステートフルです その状態は 他の Reports Server プロセスにレプリケートされません 中間層の高可用性 2-35

62 Business Intelligence の高可用性 表 2-5 Oracle Application Server Reports Services のランタイム コンポーネント ( 続き ) コンポーネント Reports Engine 特性 リクエストされたデータをデータ ソースからフェッチし レポートをフォーマットし ジョブの完了を Reports Server に通知します Reports Engine は Reports Server とは別のプロセスとして実行されますが リクエストを処理するために Reports Server によって起動されます Reports Engine はステートレスです Reports Server は新規の Reports Engine プロセスを起動できるため Reports Engine プロセスで障害が発生しても Reports Services 全体に対する影響はごくわずかです この表に記載されている 3 つのコンポーネントのうち Reports Server プロセスは不可欠なプロセスです このプロセスで障害が発生すると OracleAS Reports Services の可用性に悪影響が及びます Reports Server プロセスはクライアント リクエストの状態を維持しますが その状態はレプリケートされないため このプロセスの障害はクライアント セッションの損失を招きます Reports Server プロセスは OPMN によって監視されます デフォルトでは OracleAS Reports Services は そのインストール時に OPMN に登録されます そのため OPMN は Reports Server プロセスを監視し 障害発生時には再起動することができます インストール後に Reports Server プロセスを追加する場合は これらのプロセスを (Application Server Control の )opmn.xml および targets.xml に追加する必要があります 高可用性の詳細と操作手順は Oracle Application Server Reports Services レポート Web 公開ガイド を参照してください Reports Server は OracleAS Infrastructure の OracleAS Portal リポジトリおよび Oracle Internet Directory へのデータベース接続を行います これらのいずれかの接続に失敗すると Reports Server は 例外をスローする前に接続を再試行します 接続に成功した場合 Reports Server を再起動する必要はありません これは Oracle Internet Directory への接続を行う Reports Servlet にも当てはまります 高可用性ソリューション Reports Server プロセスのシングル ポイント障害を解消するには OracleAS Reports Services の複数インストールを実行します ( Business Intelligence and Forms インストール タイプ ) これらのインストールは複数のノードでも実行し ノードの障害から保護する必要があります Oracle Identity Management を含めた OracleAS Reports Services インストールで使用される OracleAS Infrastructure では Oracle Application Server Cold Failover Cluster または OracleAS Active Failover Cluster の高可用性ソリューションを使用します これらの高可用性ソリューションについては 第 3 章 Infrastructure の高可用性 で説明します 2-36 Oracle Application Server 10g 高可用性ガイド

63 Oracle Application Server Forms Services の高可用性 関連項目 : Oracle Application Server Reports Services レポート Web 公開ガイド ( Reports Server のクラスタ化 の章 ) Oracle Application Server Discoverer の高可用性 Oracle Application Server Discoverer は 次の方法で高可用性を実現します プロセスの監視と再起動 それぞれの中間層ノードで Oracle Application Server Discoverer プロセスを監視および再起動するように OPMN を構成します Oracle Application Server Discoverer 構成ガイド の第 4 章を参照してください ロード バランシング OracleAS Web Cache は Oracle Application Server Discoverer リクエストのロード バランサとして実行するように設定できます Oracle Application Server Discoverer 構成ガイド の第 5 章を参照してください Oracle Application Server Forms Services の高可用性 実行時 Forms Services は 表 2-6 に記載されているコンポーネントで構成されます 表 2-6 Forms Services のランタイム コンポーネント コンポーネント Forms Servlet Forms Listener Servlet Forms Runtime Engine 機能 Forms Servlet は 最初のアプリケーション リクエストを処理し Forms の汎用 Java アプレットの起動 HTML ファイルを動的に生成します OracleAS Single Sign-On の使用時には ユーザー認証の確認にも Forms Servlet が使用されます Forms Listener Servlet は クライアント ブラウザの Forms Java クライアントと中間層サーバーの Forms ランタイム プロセス間の通信を処理するディスパッチャ サーブレットです Forms Listener Servlet は アプリケーション リクエストおよびユーザーごとに Forms ランタイム プロセスを起動します Forms Runtime Engine は Forms アプリケーション モジュール (fmx ファイル ) を解析し 含まれているビジネス ロジックを実行します Forms Runtime Engine は SQLNet を使用したデータベース接続も行います Forms Services は 中間層の専用サーバー プロセスとしては存在しません そのため Web で Forms アプリケーションをリクエストして実行するには Forms Services を実行するように構成されたサーブレット コンテナ (OC4J) を使用可能にするだけで済みます 中間層の高可用性 2-37

64 Oracle Application Server Forms Services の高可用性 Forms Services はユーザーごとに専用の Forms ランタイム プロセスを起動するため 透過的なアプリケーション フェイルオーバーは使用できません ユーザー セッションが中断された場合 そのユーザーは 新しいリクエストを Forms Servlet に発行して Forms Web アプリケーションを再起動する必要があります 中間層サーバーのクラッシュ時やサーブレット セッションの中断時には アプリケーションを再起動することによって障害からリカバリします Forms の高可用性を設定する際は 次のコンポーネントを使用できます mod_oc4j : OC4J インスタンスの障害に対処するために 異なる OC4J インスタンス間でアプリケーション リクエストのロード バランシングを行うように Forms を設定できます これにより 現行の OC4J インスタンスで障害が発生した場合は 使用可能な次の OC4J インスタンスにアプリケーション リクエストをルーティングできます OracleAS Web Cache : OracleAS Web Cache を HTTP ロード バランサとして使用すると 多数の Oracle Application Server インスタンス間で Forms リクエストを分散できます この場合 これらのインスタンスが同じ Infrastructure インストールを共有しているかどうかは関係ありません あるインスタンスで障害が発生した場合 次の Forms アプリケーション リクエストは 使用可能な次のインスタンスにルーティングされます また 各インスタンスは mod_oc4j を使用して OC4J インスタンス間で Forms セッションのロード バランシングを行うこともできます ハードウェア ロード バランサ : ハードウェア ロード バランサは OracleAS Web Cache の前面に配置できます これにより Forms リクエストに対するロード バランシングの層がもうひとつ追加されます または ハードウェア ロード バランサを OracleAS Web Cache に置き換えて リクエストを Oracle HTTP Server に直接ロード バランシングを行うこともできます Oracle Identity Management を含めた Forms Services インストールで使用される OracleAS Infrastructure では Oracle Application Server Cold Failover Cluster または Oracle Application Server Active Failover Cluster の高可用性ソリューションを使用します これらの高可用性ソリューションについては 第 3 章 Infrastructure の高可用性 で説明します Forms Services のアーキテクチャおよび設定の詳細は Oracle Application Server Forms Services 利用ガイド を参照してください 2-38 Oracle Application Server 10g 高可用性ガイド

65 中間層のリカバリ ソリューション Oracle Application Server Integration の高可用性 Oracle Application Server 10g の E-Business 統合製品である Oracle Application Server 10g InterConnect と Oracle Application Server 10g ProcessConnect の高可用性は Infrastructure の各種の高可用性ソリューションによって異なります (3-8 ページの Infrastructure の高可用性構成 を参照 ) これは InterConnect と ProcessConnect では Infrastructure のデータベースを使用して情報の格納とキューイングが行われるためです ただし Infrastructure の高可用性ソリューションによっては InterConnect または ProcessConnect で使用できないものもあります これについては 次の項目で詳しく説明します Oracle Application Server 10g InterConnect 高可用性は Oracle Application Server Cold Failover Cluster および Oracle Application Server Active Failover Cluster によってサポートされます adapter.ini および hub.ini ファイルに クラスタ内の全ノードのホスト情報 ポート情報およびインスタンス情報が移入されます ノードまたはデータベース インスタンスで障害が発生した場合は InterConnect アダプタで再接続を行ってメッセージ配信を続行できます メッセージの再発行は不要です 処理および配信のいかなる段階でもメッセージが失われることはありません adapter.ini および hub.ini の詳細は Oracle Application Server InterConnect ユーザーズ ガイド の第 8 章の RAC サポートに関する項を参照してください Oracle Application Server 10g ProcessConnect 接続情報がファイルに格納される InterConnect とは異なり ProcessConnect では Infrastructure のデータベースに接続情報が格納されます そのため ProcessConnect では Infrastructure の Oracle Application Server Cold Failover Cluster と Oracle Application Server Active Failover Cluster の両ソリューションにより高可用性が実現します 中間層のリカバリ ソリューション プロセスの再起動 システムで障害が発生した場合 その障害からのリカバリをできるだけ迅速に行うことが重要です 使用できるリカバリ ソリューションには 障害のタイプと重大度に応じて 4 つの主要なタイプがあります ほとんどすべてのタイプの障害からのリカバリでは システムで障害が発生したプロセスを 1 つ以上再起動する必要があります プロセス再起動には 次の 3 つのシナリオがあります プロセスの自動再起動 : 障害が検出されると OPMN によって障害の発生したプロセスが自動的に再起動されます 手動による介入は不要です 手動による個々のプロセスの再起動 : この方法は プロセスの障害の影響が他の中間層または Infrastructure プロセスに及ばない場合で 個々に再起動できるときに使用します 中間層の高可用性 2-39

66 中間層のリカバリ ソリューション 手動によるすべてのプロセスの再起動 中間層と Infrastructure のほとんどの障害タイプでは プロセスの再起動ソリューションのみを必要とします こうした障害には OPMN の障害 Oracle Application Server Metadata Repository の障害 Application Server Control のクラッシュなどがあります コールド バックアップからのリストア 一部の障害では 単なるプロセスの再起動ではない 複雑なリカバリ シナリオを必要とします 場合によっては 以前に実装したコールド バックアップ手順に基づくリストア操作を実行する必要があります これらのコールド バックアップには インストール済の OracleAS バイナリが含まれます コールド バックアップのリストア操作は 中間層と Infrastructure の両方で行うことができます コールド バックアップからの中間層のリストア : すべての Oracle Application Server Infrastructure プロセスと Oracle Application Server Metadata Repository を通常どおり正しく停止した後にバックアップされた Oracle ホーム 構成ファイル データベース ファイルなどを含む Oracle Application Server Middle Tier 全体のリストア コールド バックアップからの Infrastructure のリストア : すべての Oracle Application Server Infrastructure プロセスと Oracle Application Server Metadata Repository を通常どおり正しく停止した後にバックアップされた Oracle ホーム 構成ファイル データベース ファイルを含む Oracle Application Server Infrastructure インスタンス全体のリストア リカバリでコールド バックアップ ソリューションからのリストアを必要とする障害には ノードの完全な置換が必要なノード障害や Oracle ソフトウェアまたはバイナリ ファイルの削除や破損などがあります このタイプのリカバリ ソリューションを必要とする障害では 手動による全プロセスの再起動も必要になります 個々の障害タイプとそのリカバリ方法の詳細は Oracle Application Server 10g 管理者ガイド を参照してください オンライン バックアップからのリストア システムで発生した障害のタイプによっては オンライン バックアップからシステムをリストアする必要があります オンライン バックアップのリストア シナリオには 次の 4 つのタイプがあります オンライン バックアップからの中間層のリストア : 中間層でプロセスが稼動しているときにバックアップされた Oracle Application Server 構成ファイルのリストア このリストアにはタイムスタンプ付きバックアップのリストアも含まれます これには リストアを完了するために追加手順が必要になることもあります オンライン バックアップからの Infrastructure のリストア : Oracle Application Server インスタンスと Oracle Application Server Metadata Repository の適切なオンライン バックアップの完了後にバックアップされた Oracle Application Server Infrastructure 構成ファイルのリストア 2-40 Oracle Application Server 10g 高可用性ガイド

67 中間層のリカバリ ソリューション オンライン バックアップからの Oracle Application Server Metadata Repository のリストア : 適切なオンライン バックアップから取得された Oracle Application Server Metadata Repository のリストア データベース コンポーネントの完全なリカバリが必要です オンライン バックアップからの Infrastructure 構成ファイルのリストア : オンライン バックアップから取得された Infrastructure 構成ファイルのリストア リカバリでオンライン バックアップ ソリューションのリストアを必要とする障害には Oracle Application Server Metadata Repository のデータ障害や Oracle Application Server コンポーネントのランタイム構成ファイルの削除または破損などがあります このタイプのソリューションを必要とする障害では 1 つ以上のプロセスの再起動も必要になります 個々の障害タイプとそのリカバリ方法の詳細は Oracle Application Server 10g 管理者ガイド を参照してください 障害時リカバリ 障害時リカバリ (disaster recovery: DR) とは 壊滅的なサイト障害の発生後におけるシステムのリカバリ方法のことです 壊滅的な障害には 地震 竜巻 洪水 火事などがあります 最も基本的なレベルの DR では 個々のハードウェアやサブコンポーネントのレプリケーションだけでなく サイト全体を対象としたレプリケーションを行う必要があります DR のサービスレベルの要件は ビジネス アプリケーションによって異なります アプリケーションによっては 障害時リカバリ要件がまったくないものもあります バックアップ データ テープを作成し そのテープから新しい稼動サイトを一定の時間をかけて再構築すればよいアプリケーションもあります 一方で 障害発生後 数日または数時間以内に運用を開始する必要があるアプリケーションもあります 最も厳しい要件では 障害が発生しても引き続きサービスを実行することが求められます Oracle Application Server Disaster Recovery ソリューションは 同一の構成を持つ 2 つのサイトで構成されます これらのサイトは地理的に分散されていることもあります その場合 両サイトはネットワークでつながっています 障害が原因でプライマリ サイトが使用不能になったときは 妥当な時間内にセカンダリ サイトが運用可能になります クライアント リクエストは 本番ロールのサイトに必ずルーティングされます サイトの停止に伴うフェイルオーバーまたはスイッチオーバー処理が実行された後 クライアント リクエストは運用を引き継いだ別のサイトへとルーティングされます 各サイトには同一の中間層サーバーが配置されており これらのサーバーは 2 つのサイト間でまったく同一です 本番ロールのサイトは ホスト障害から保護するためにコールド フェイルオーバー クラスタ Infrastructure の高可用性ソリューションを使用する 本番用のバックエンド カスタマ データベースと本番用の Oracle Application Server Metadata Repository で構成されています スタンバイ ロールのサイトには Oracle Application Server Metadata Repository のフィジカル スタンバイがあります データベースのスイッチオーバーおよびフェイルオーバー機能を使用すると これらのロールをサイト間で交換できます 関連項目 : 第 6 章 Oracle Application Server Disaster Recovery 中間層の高可用性 2-41

68 中間層のリカバリ ソリューション DCM アーカイブおよびリカバリ 構成のクローニング DCM アーカイブおよびリカバリ機能により システム構成のスナップショットを取得できます すべてが正常に最適な状態で機能しているときにスナップショットを取得すれば 障害発生時にこの以前の構成にシステムをリストアできます 壊滅的な障害に対応して リモート ロケーションのシステムにスナップショットをリストアできます 関連項目 : アーカイブおよびリカバリ操作の実行手順は Distributed Configuration Management リファレンス ガイド を参照してください DCM ツール dcmctl を使用すれば 既存の Oracle Application Server インスタンスの構成を新しいインスタンスにクローニングできます 新しいインスタンスは最初のインスタンスとまったく同じ構成を持つため 新しいインスタンスの設定時に構成エラーが生じる可能性が少なくなります クローニング プロセスでは DCM アーカイブを新規作成して 新しいインスタンスに適用します これは DCM アーカイブの作成元のインスタンスにそのアーカイブをリストアする場合とは異なります 注意 : dcmctl アーカイブ コマンドを使用してクローニングできるのは DCM によって管理されている構成のみです 現在 DCM では OC4J OHS OPMN JAZN の各コンポーネントの構成データが管理されます 関連項目 : Distributed Configuration Management リファレンス ガイド の構成のアーカイブに関する章 2-42 Oracle Application Server 10g 高可用性ガイド

69 3 Infrastructure の高可用性 この章では Oracle Application Server 10g Infrastructure の高可用性について説明します この章では Infrastructure の高可用性に関する機能およびアーキテクチャのソリューションについて検討します この章の項目は次のとおりです Oracle Application Server 10g Infrastructure の概要 Oracle Application Server 10g Infrastructure のコンポーネント Infrastructure の高可用性構成 Infrastructure の高可用性 3-1

70 Oracle Application Server 10g Infrastructure の概要 Oracle Application Server 10g Infrastructure の概要 Oracle Application Server 10g では 完全に統合されたインフラストラクチャとフレームワークを使用して エンタープライズ アプリケーションを開発および配置できます Oracle Application Server 10g Infrastructure インストール タイプは Oracle Application Server 10g Middle Tier のための一元化された製品メタデータ セキュリティ サービスと管理サービス および構成情報とデータ リポジトリが提供されます 中間層で必要な Infrastructure サービスを統合することにより エンタープライズ アプリケーションの開発に必要な時間と労力が削減されます その結果 これらのアプリケーションの開発と配置に要する総コストが削減され 配置されたアプリケーションの信頼性が向上します Oracle Application Server 10g Infrastructure は 次のような総合的なサービスを提供します 製品メタデータ サービス Oracle Application Server 10g Infrastructure には Oracle Application Server 10g Middle Tier インスタンスが必要とするアプリケーション サーバーのメタデータがすべて格納されます このデータは Oracle9i データベースに格納されます そのため このデータベースの堅牢性を活かした スケーラブルで信頼性の高い 管理が容易なメタデータ リポジトリが提供されます セキュリティ サービスセキュリティ サービスは Oracle Application Server 10g に配置されたすべてのアプリケーションに対して一貫したセキュリティ モデルと識別情報管理を提供します このサービスにより シングル サインオンによる一元化された認証 Oracle Delegated Administration Services を使用した Web ベースの管理 およびユーザーの認証資格証明の一元化された格納が実現します このサービスでは 基礎となるリポジトリとして Oracle Internet Directory が使用されます 管理サービス このサービスは Distributed Configuration Management で Oracle Application Server 10g Middle Tier インスタンスと Oracle Application Server 10g Infrastructure を管理する際に使用されます このサービスはまた 中間層のクラスタリング サービスの管理にも使用されます Application Server Control を使用すると デプロイされた J2EE アプリケーションの管理が一元化され 総管理コストを削減できます 3-2 Oracle Application Server 10g 高可用性ガイド

71 Oracle Application Server 10g Infrastructure のコンポーネント Oracle Application Server 10g Infrastructure のコンポーネント Oracle Application Server 10g Infrastructure は そのロールと機能を提供する複数のコンポーネントによって構成されます これらのコンポーネントは相互に連携して Infrastructure の製品メタデータ セキュリティおよび管理サービスを提供します この項では Infrastructure の次のコンポーネントについて説明します Oracle Application Server Metadata Repository Oracle Identity Management Oracle HTTP Server Oracle Application Server Containers for J2EE(OC4J) Oracle Enterprise Manager - Application Server Control Oracle Application Server Metadata Repository Oracle Application Server Metadata Repository は Oracle9i Enterprise Edition のデータベース サーバーです このリポジトリには Oracle Application Server Middle Tier または Infrastructure のコンポーネントがアプリケーションの配置の一部としてアクセスするコンポーネント固有の情報が格納されます エンド ユーザーまたはクライアント アプリケーションは このデータに直接はアクセスできません たとえば 中間層の Portal アプリケーションは Portal ページの集合体の一部として Portal メタデータにアクセスします メタデータには Oracle Application Server の多数のコンポーネントのデモ データ (BC4J 用の Order Management Demo で使用するデータなど ) も含まれています Oracle Application Server のメタデータとカスタマ データまたはアプリケーション データは Oracle Application Server Metadata Repository 内で共存できます ただし アクセス可能なアプリケーションはデータによって異なります Oracle Application Server Metadata Repository には Oracle Application Server 10g Infrastructure の概要 の項で説明した 3 つの主要な Infrastructure サービスに対応する 3 つの主要なタイプのメタデータが格納されます それらのメタデータのタイプは次のとおりです 製品メタデータ 識別情報管理メタデータ 管理メタデータ 表 3-1 に アプリケーションの配置時にこれらのタイプのメタデータを格納して使用する Oracle Application Server コンポーネントを示します Infrastructure の高可用性 3-3

72 Oracle Application Server 10g Infrastructure のコンポーネント 表 3-1 メタデータと Infrastructure コンポーネント メタデータのタイプ 製品メタデータ ( デモ データを含む ) 識別情報管理メタデータ 管理メタデータ 関連する Infrastructure コンポーネント Oracle Application Server Metadata Repository OracleAS Single Sign-On Oracle Internet Directory Oracle Application Server Certificate Authority Distributed Configuration Management Oracle Enterprise Manager Oracle Application Server Metadata Repository が必要な配置 Oracle Application Server Metadata Repository(OracleAS Metadata Repository) は J2EE and Web Cache インストール タイプを使用する場合を除き すべてのアプリケーションの配置で必要になります Oracle Application Server では 次の 3 つの中間層インストール オプションを利用できます J2EE and Web Cache: Oracle HTTP Server Oracle Application Server Containers for J2EE(OC4J) Oracle Application Server Web Cache(OracleAS Web Cache) Web Services Oracle Business Components for Java(BC4J) および Application Server Control をインストールします Portal and Wireless: J2EE と OracleAS Web Cache に加えて UDDI Oracle Application Server Portal(OracleAS Portal) Oracle Application Server Syndication Services (OracleAS Syndication Services) Oracle Ultra Search および Oracle Application Server Wireless(OracleAS Wireless) のすべてのコンポーネントをインストールします Business Intelligence and Forms: J2EE と OracleAS Web Cache OracleAS Portal と Oracle Application Server 10g Wireless に加えて Oracle Application Server Forms Services Oracle Application Server Reports Services Oracle Application Server Discoverer および Oracle Application Server Personalization のすべてのコンポーネントをインストールします Oracle Application Server ProcessConnect Oracle Application Server InterConnect Oracle Workflow などの Integration コンポーネントは これらの中間層インストール オプションの上にインストールされます Distributed Configuration Management(DCM) コンポーネントにより 中間層の管理が可能になり Portal and Wireless Business Intelligence and Forms インストール オプション用のメタデータが OracleAS Metadata Repository に格納されます J2EE and Web Cache インストール タイプの場合 デフォルトでは DCM はファイルベースのリポジトリを使用します J2EE and Web Cache インストール タイプを Infrastructure に関連付けると ファイルベースのリポジトリが OracleAS Metadata Repository に移行します 3-4 Oracle Application Server 10g 高可用性ガイド

73 Oracle Application Server 10g Infrastructure のコンポーネント 注意 : OracleAS Metadata Repository は (Infrastructure の Oracle Identity Management コンポーネントを使用しないで ) 既存の Real Application Clusters データベースにインストールできます このインストール例の詳細は Oracle Application Server 10g のインストレーション ガイドを参照してください Oracle Identity Management 関連項目 : Oracle Application Server 10g のインストールの詳細は Oracle Application Server 10g のインストレーション ガイドを参照してください Infrastructure の Oracle Identity Management フレームワークは 次のコンポーネントで構成されています Oracle Internet Directory Oracle Application Server Single Sign-On 関連項目 : Oracle Identity Management 概要および配置プランニング ガイド Oracle Internet Directory Oracle Internet Directory は Lightweight Directory Access Protocol(LDAP) バージョン 3 を使用したディレクトリ サービスの Oracle による実装です Oracle Internet Directory は Oracle9i データベース上でアプリケーションとして実行され このデータベースの優れたパフォーマンス スケーラビリティおよび高可用性を利用します Oracle Internet Directory が提供する一元化されたリポジトリを使用して OC4J Oracle Application Server 10g Portal Oracle Application Server 10g Wireless など Oracle Application Server 10g のその他のコンポーネントのユーザーを作成および管理できます ユーザーの認可および認証の集中管理により Oracle Internet Directory 内でユーザーを一元的に定義し Oracle Application Server 10g のすべてのコンポーネント間で共有することが可能になります Oracle Internet Directory には Java ベースの管理ツール (Oracle Directory Manager) 信頼できるプロキシベースの管理を行う Web ベースの管理ツール (Oracle Delegated Administration Services) および複数のコマンドライン ツールが付属しています Oracle Delegated Administration Services を使用すると Oracle Internet Directory 管理者ではない委任管理者が Oracle Application Server 10g 環境のエンド ユーザーをプロビジョニングすることができます エンド ユーザーが各自の属性を変更することも可能です Infrastructure の高可用性 3-5

74 Oracle Application Server 10g Infrastructure のコンポーネント Oracle Internet Directory を使用して Oracle Application Server 10g コンポーネントでユーザーとグループ イベントに関するデータを同期化することもできます これにより ローカルなアプリケーション インスタンスに格納されているユーザー情報をこれらのコンポーネントで更新できます 関連項目 : ださい 詳細は Oracle Internet Directory 管理者ガイド を参照してく Oracle HTTP Server Oracle Application Server Single Sign-On OracleAS Single Sign-On は 中間層とデータベースの両機能で構成されるマルチパート環境であり パートナ アプリケーション間でシングル ユーザー認証を可能にします パートナ アプリケーションは SSOSDK を使用するか Apache mod_osso モジュールを介して実現します このモジュールを使用すると Apache( および以降の URL) でパートナ アプリケーションを作成できます OracleAS Single Sign-On は ユーザー情報を格納する Oracle Internet Directory と完全に統合されています これは Oracle Internet Directory による LDAP ベースのユーザーおよびパスワード管理をサポートします OracleAS Single Sign-On では 公開鍵インフラストラクチャ (PKI) クライアント認証をサポートしていて 広範な Web アプリケーションの PKI 認証が可能です さらに X.509 デジタル クライアント証明書や Kerberos セキュリティ チケットを使用してユーザー認証を行うことができます API を使用して サード パーティの認証メカニズム (Netegrity Site Minder など ) に OracleAS Single Sign-On を統合できます 関連項目 : Oracle Application Server Single Sign-On 管理者ガイド ( このマニュアルには Identity Management のレプリケーション手順も記載されています ) Infrastructure インストール タイプでは Infrastructure 用の Oracle HTTP Server がインストールされます Oracle HTTP Server は Infrastructure および中間層インスタンスの他の分散コンポーネントからのリクエストの処理に使用されます Infrastructure では Oracle HTTP Server により OracleAS Single Sign-On と Oracle Delegated Administration Services に対するリクエストが処理されます Oracle Delegated Administration Services は Infrastructure の OC4J プロセス内のサーブレットとして実装されます 関連項目 : Oracle HTTP Server 管理者ガイド 3-6 Oracle Application Server 10g 高可用性ガイド

75 Oracle Application Server 10g Infrastructure のコンポーネント Oracle Application Server Containers for J2EE(OC4J) Infrastructure では Oracle Delegated Administration Services と OracleAS Single Sign-On を実行するために OC4J が Infrastructure にインストールされます Oracle Delegated Administration Services は OC4J のサーブレットとして実行されます Oracle Delegated Administration Services では エンド ユーザーおよびアプリケーション管理者用のセルフサービス コンソールを利用できます このコンソールは サード パーティのアプリケーションをサポートするためにカスタマイズできます さらに Oracle Internet Directory データを操作するカスタマイズされた管理インタフェースを構築するための複数のサービスも提供されます Oracle Delegated Administration Services は Oracle Identity Management のコンポーネントです 関連項目 : Oracle Delegated Administration Services の詳細は Oracle Internet Directory 管理者ガイド を参照してください Oracle Enterprise Manager - Application Server Control Oracle Enterprise Manager - Application Server Control(Application Server Control) では Web ベースのインタフェースを使用して Oracle Application Server のコンポーネントとアプリケーションを管理できます Oracle Application Server Control を使用して 次の操作を行うことができます Oracle Application Server コンポーネント Oracle Application Server Middle Tier および Infrastructure のインスタンス OracleAS Cluster およびデプロイされた J2EE アプリケーションとそのコンポーネントの監視 Oracle Application Server のコンポーネント インスタンス OracleAS Cluster および配置されたアプリケーションの構成 OracleAS のコンポーネント インスタンス OracleAS Cluster および配置されたアプリケーションの操作 OracleAS コンポーネントおよび配置されたアプリケーションのセキュリティの管理 Oracle Enterprise Manager とその 2 つのフレームワークの詳細は Oracle Enterprise Manager 概要 を参照してください 関連項目 : Application Server Control に関する説明とその使用方法は Oracle Application Server 10g 管理者ガイド を参照してください Infrastructure の高可用性 3-7

76 Infrastructure の高可用性構成 Infrastructure の高可用性構成 前述のとおり Oracle Application Server 10g Infrastructure は次のサービスを提供します 製品メタデータ セキュリティ サービス 管理サービス 可用性の観点からすると これらのサービスは次のコンポーネントによって提供されます Infrastructure の可用性を実現するには これらのコンポーネントをすべて使用できるようにする必要があります OracleAS Metadata Repository Oracle Net listener Oracle HTTP Server Oracle Identity Management 用 Oracle Internet Directory および Oracle Internet Directory モニター OC4J Oracle Delegated Administration Services インスタンス OracleAS Single Sign-On Oracle Management Service 用 Distributed Configuration Management Infrastructure が必須サービスをすべて提供するには 前述のコンポーネントをすべて使用できるようにする必要があります UNIX プラットフォームでは これらのコンポーネントに関連付けられているプロセスを起動してアクティブにする必要があります Infrastructure コンポーネントに関連付けられているすべてのプロセスに対して 高可用性ソリューションでソフトウェア障害の発生を検出し リカバリできるようにする必要があります さらに Infrastructure を実行しているホストでも ハードウェア障害の発生を検出し リカバリできるようにする必要があります Oracle Application Server 10g では データベースとそのリスナーおよび Application Server Control を除く Infrastructure のすべてのプロセスが Oracle Process Manager and Notification Server(OPMN) フレームワークによって起動 管理および再起動されます つまり OPMN で管理されているプロセスで発生した障害は OPMN によって内部的に処理されます OPMN は インストール時に自動的にインストールおよび構成されます ただし データベース プロセスまたはデータベース リスナーの障害は OPMN では処理されません さらに OPMN プロセスで発生した障害が検出されず 適切なリカバリ手順が実行されない場合 Infrastructure は非リジリエンス モードのままとなります 3-8 Oracle Application Server 10g 高可用性ガイド

77 Infrastructure の高可用性構成 OracleAS では 次の 2 つのソリューションによって イントラサイトの高可用性を Infrastructure で実現します Oracle Application Server Cold Failover Cluster Oracle Application Server Active Failover Cluster(UNIX) これらのイントラサイトの高可用性ソリューションでは OPMN で検出およびリカバリできない ローカルなハードウェアおよびソフトウェア障害からの保護が実現します こうした障害には システム パニックやノードのクラッシュがあります ただし これらのソリューションを使用して データの破損や損失をもたらすサイト障害やメディア障害から Infrastructure を保護することはできません Oracle Application Server 10g では 障害時リカバリ ソリューションによって災害やサイト障害に対する保護を行います このソリューションは 第 6 章 Oracle Application Server Disaster Recovery で説明します 多くの場合 サイト障害や災害は 中間層 Infrastructure およびバックエンド データベースを含むすべてのシステムに影響します そのため 障害時リカバリ ソリューションでは 中間層および Infrastructure データベースを保護するメカニズムも提供されています つまり イントラサイトの高可用性ソリューションである OracleAS Cold Failover Cluster と OracleAS Active Failover Cluster は ローカルなハードウェアおよびソフトウェア障害に対するリジリエンスを OracleAS Infrastructure にのみ提供します 中間層は リジリエントな Infrastructure によって機能し続けることができます 一方 障害時リカバリ ソリューションでは Infrastructure だけでなく中間層のフェイルオーバーも必要とする 全面的なサイト障害を処理します Infrastructure のイントラサイトの高可用性ソリューションについては 以降の各項で説明します Oracle Application Server Cold Failover Cluster Infrastructure の Oracle Application Server Cold Failover Cluster(OracleAS Cold Failover Cluster) ソリューションでは 後述の図 3-1 OracleAS Cold Failover Cluster ソリューションの通常の操作 に示すように 2 つのノードを持つハードウェア クラスタが使用されます 用語 このソリューションの説明では OracleAS Cold Failover Cluster ソリューションの文脈で使用される次の用語の意味を明確にすることが重要になります Infrastructure の高可用性 3-9

78 Infrastructure の高可用性構成 ハードウェア クラスタ一般的な定義では クラスタとは疎結合されたコンピュータ ( ノードと呼ぶ ) の集まりであり ネットワーク サービス ( 例 : IP アドレス ) またはアプリケーション サービス ( 例 : データベース Web サーバー ) のシングル ビューをこれらのサービスのクライアントに提供します クラスタ内の各ノードは それぞれのプロセスを実行するスタンドアロン サーバーです これらのプロセスは相互に通信して アプリケーション システム リソースおよびデータを協調してユーザーに提供する単一のシステムのように機能します このタイプのクラスタリングでは 可用性の高いスケーラブルなアプリケーションの実現という点で 従来のシングル サーバー システムをしのぐ優位性がいくつか見られます ハードウェア クラスタとは ハードウェア ( クラスタ インターコネクト 共有記憶域 ) とソフトウェア ( ヘルス モニター リソース モニター ) を追加することにより 高可用性とスケーラビリティを実現するクラスタです ( クラスタ インターコネクトは ハートビート情報がノードの停止を検出する際にハードウェア クラスタで使用されるプライベート リンクです ) 追加のハードウェアとソフトウェアが必要であるため 通常 ハードウェア クラスタは Sun 社 HP 社 IBM 社 Dell 社などのハードウェア ベンダーによって提供されます 1 つのハードウェア クラスタ内で構成可能なノード数は ベンダーによって異なりますが Oracle Application Server Cold Failover Cluster ソリューションを使用する Oracle Application Server 10g Infrastructure High Availability では 2 つのノードのみを必要とします そのため このドキュメントでは 2 つのノードを持つハードウェア クラスタをこのソリューションで使用することを前提とします フェイルオーバーフェイルオーバーとは ハードウェア クラスタによって障害のあるノードから指定のスタンバイ ノードにアプリケーションの実行が自動的に再配置されるプロセスです フェイルオーバーの発生時には クライアントでサービスが短時間中断されることがあり フェイルオーバー操作の完了後に再接続が必要になる場合があります ただし アプリケーションおよびデータの供給元の物理サーバーをクライアントが認識することはありません ハードウェア クラスタのソフトウェアが提供する API によって ハードウェア クラスタの 2 つのノード間でアプリケーションの自動的な起動 停止 監視およびフェイルオーバーが可能になります 1 次ノード常に 1 つ以上の Infrastructure インストールを頻繁に実行しているノードです このノードで障害が発生すると ハードウェア クラスタによって Infrastructure が 2 次ノードに自動的にフェイルオーバーされます 1 次ノードではアクティブな Infrastructure インストールが実行されるため 1 次ノードはホット ノードと見なされます 2 次ノード 1 次ノードで障害が発生した場合に Infrastructure の実行を引き継ぐノードです それまで 2 次ノードでは Infrastructure が実行されていないため 2 次ノードはコールド ノードと見なされます アプリケーションがホット ノード (1 次 ) からコールド ノード (2 次 ) へフェイルオーバーされるため このタイプのフェイルオーバーはコールド フェイルオーバーと呼ばれます 3-10 Oracle Application Server 10g 高可用性ガイド

79 Infrastructure の高可用性構成 論理 IP または仮想 IP ネットワーク クライアントにクラスタのシングル システム ビューを提示するために ハードウェア クラスタでは論理または仮想 IP アドレスが使用されます これは クラスタへのエントリ ポイントとして外部に示される動的な IP アドレスです ハードウェア クラスタのソフトウェアは 外部クライアントによるこの IP アドレスへの接続中 クラスタの 2 つの物理ノード間でのこの IP アドレスの移動を管理します その際 外部クライアントは この IP アドレスが現在どの物理ノードでアクティブであるかを知る必要はありません 2 つのノードを持つ標準的なクラスタ構成の場合 各物理ノードは固有の物理 IP アドレスとホスト名を持ちますが 2 つのノード間で浮動または移行する複数の論理 IP アドレスを使用することもできます 特定の OracleAS Infrastructure インストールでは そのインストールに関連付けられている論理 IP と仮想名が その Infrastructure へのクライアント接続に使用される IP と名前になります インストール プロセスの詳細は Oracle Application Server 10g のインストレーション ガイドを参照してください 仮想ホスト名仮想ホスト名は 論理 IP または仮想 IP に関連付けられているホスト名です ハードウェア クラスタのシングル システム ビューを OracleAS Middle Tier に提示するために選択される名前です この名前と IP のエントリは サイトで使用される DNS に追加する必要があります これにより 中間層ノードでは このエントリをローカルな /etc/hosts ファイル ( または等価なファイル ) に追加せずに Infrastructure に関連付けることができます たとえば ハードウェア クラスタの 2 つの物理ホスト名が node1.mycompany.com と node2.mycompany.com であるとき このクラスタのシングル ビューを selfservice.mycompany.com という名前で示すことができます DNS では selfservice が Infrastructure の論理 IP アドレスにマップします この論理 IP アドレスは node1 と node2 の間で浮動します その際 中間層は どの物理ノードがアクティブでリクエストを処理しているのかを認識しません 注意 : このドキュメントで 仮想名 という語句を使用する場合 それが論理 IP アドレスに関連付けられることを前提とします 単に IP アドレスを必要とする場合または使用する場合には その旨を明示的に記載します 共有記憶域各ハードウェア クラスタ ノードが 各自のプロセス セットを実行するスタンドアロン サーバーの場合でも 通常 クラスタ対応のために必要とされる記憶域サブシステムは共有されます 共有記憶域とは 両方のノードから同じ記憶域 ( 通常はディスク ) にアクセスできるクラスタの機能のことです 両ノードはこの記憶域に対して等しくアクセスできますが 一方のノード (1 次ノード ) が記憶域に対して常に頻繁にアクセスします 1 次ノードで障害が発生すると ハードウェア クラスタのソフトウェアは 2 次ノードがこの記憶域にアクセスすることを許可します OracleAS Infrastructure では その ORACLE_HOME はこのような共有記憶域のファイル システムに配置されます このファイル システムは 1 次ノードによってマウントされます 1 次ノードで障害が発生した場合は 2 次ノードがファイル システムを引き継いでマウントします 場合によっては 1 次ノードが共有記憶域の制御を放棄することもあります たとえば ハードウェア クラスタのソフトウェアが 1 次ノードによる Infrastructure の使用は不可能と判断し 2 次ノードへの移行を決定した場合などです Infrastructure の高可用性 3-11

80 Infrastructure の高可用性構成 アーキテクチャ (UNIX) 図 3-1 は OracleAS Cold Failover Cluster 高可用性ソリューションにおける 2 つのノードを持つクラスタのレイアウトを示しています 2 つのノードは共有記憶域に連結されています この図では の仮想 / 論理 IP アドレスは 物理ノード 1 でアクティブになっています したがって ノード 1 は 1 次ノード ( アクティブなノード ) です 仮想名 selfservice.mycompany.com はこの仮想 IP アドレスにマップされ 中間層では Infrastructure が selfservice.mycompany.com に関連付けられます 図 3-1 OracleAS Cold Failover Cluster ソリューションの通常の操作 3-12 Oracle Application Server 10g 高可用性ガイド

81 Infrastructure の高可用性構成 通常の操作モードでは ハードウェア クラスタのソフトウェアは物理ノード 1 上の仮想 IP を有効にし このノードの Infrastructure プロセス ( データベース データベース リスナー Oracle Enterprise Manager プロセスおよび OPMN) をすべて起動します Oracle Internet Directory OC4J インスタンスおよび Oracle HTTP Server のいずれかの Infrastructure プロセスで障害が発生した場合 OPMN によってこれらのプロセスの起動 監視および再起動が必要に応じて行われます 図 次ノードのフェイルオーバー後の Infrastructure Infrastructure の高可用性 3-13

82 Infrastructure の高可用性構成 1 次ノードで障害が発生した場合は 2 次ノード上で仮想 IP アドレス を手動で有効にします ( 図 3-2) これにより Infrastructure プロセスはすべて 2 次ノード上で起動します 仮想 IP と共有記憶域が移行し データベース データベース リスナーおよび他のすべての Infrastructure プロセスが起動する際 Infrastructure にアクセスする中間層プロセスではサービスの一時的な損失が発生します Infrastructure プロセスが起動すると この間に再試行を行っていた中間層プロセスが再接続されます 新しい接続は フェイルオーバーが発生したことを認識しません ハードウェア クラスタ フレームワークでは Infrastructure プロセスの起動 監視 検出 再起動またはフェイルオーバーを行うことができますが これらの操作は自動的には実行されません なんらかのスクリプト作成や簡単なプログラミングを必要とします 必要とされるスクリプトについては 第 5 章 Infrastructure の高可用性の管理 で説明します Infrastructure の OracleAS Cold Failover Cluster ソリューションの設定および操作に関する詳細は Oracle Application Server 10g のインストレーション ガイドを参照してください このマニュアルでも インストール前の作業とインストール作業について説明します アーキテクチャ (Windows) OracleAS Cold Failover Cluster のソリューションは 2 つのノードを持つクラスタで構成されており そのクラスタが Infrastructure のデータ ファイルが格納された共有ディスク ( 図 3-3 を参照 ) にアクセスします 常にアクティブなのは 一方のノードのみです 通常の操作時は 2 番目のノードはスタンバイ状態です OracleAS Middle Tier のコンポーネントは サブネット内の仮想 IP にマップされた仮想ホスト名を介してクラスタにアクセスします 図 3-3 の例では 仮想ホスト名 selfservice.mycompany.com と仮想 IP が使用されています ノード 1 からノード 2 へのフェイルオーバーが発生したときは これらの仮想ホスト名と仮想 IP がスタンバイ ノードに移行し そちらがアクティブ ノードになります アクティブ ノードの障害は OracleAS Middle Tier のコンポーネントに対して透過的です 注意 : Windows の OracleAS Cold Failover Cluster ソリューションでは 静的な IP アドレスしか使用できません 3-14 Oracle Application Server 10g 高可用性ガイド

83 Infrastructure の高可用性構成 図 3-3 Windows での Oracle Application Server Cold Failover Cluster ソリューション 前の項 (UNIX での OracleAS Cold Failover Cluster) で説明した概要は Microsoft Cluster Server ソフトウェアを使用してハードウェア クラスタの高可用性を管理する Windows での OracleAS Cold Failover Cluster ソリューションにも該当します さらには Oracle Fail Safe と Microsoft Cluster Server を併用することで 次のコンポーネントを構成できます 仮想ホスト名と仮想 IP OracleAS Infrastructure データベース Oracle Process Manager and Notification サービス Application Server Control Infrastructure の高可用性 3-15

84 Infrastructure の高可用性構成 Windows での OracleAS Cold Failover Cluster ソリューションの中心は リソース グループという概念です グループは Oracle Fail Safe によって定義されたリソースの集合体です アクティブ ノードからスタンバイ ノードへのフェイルオーバー時は グループ つまりその中のリソースが 1 つの単位としてフェイルオーバーされます OracleAS Cold Failover Cluster のインストールおよび構成時に このソリューションに対して 1 つのグループが定義されます このグループは 次のもので構成されます クラスタの仮想 IP クラスタの仮想ホスト名 共有ディスク Infrastructure データベース データベースの TNS リスナー OPMN Application Server Control Oracle Fail Safe と Microsoft Cluster Server を統合すると OracleAS Cold Failover Cluster ソリューションで 環境と自動フェイルオーバー機能の管理が容易になります Infrastructure データベース その TNS リスナーおよび OPMN が Windows サービスとしてインストールされ Oracle Fail Safe と Microsoft Cluster Server によって監視されます これらの Windows サービスのいずれかに障害が発生したときは グループがスタンバイにフェイルオーバーされる前に Microsoft Cluster Server によって 問題のサービスの再起動が 3 回 ( デフォルトの設定 ) 試行されます さらには OPMN によって Oracle Internet Directory OC4J および Oracle HTTP Server の各プロセスが監視 起動および再起動されます 関連項目 : インストール プロセスとインストール要件の詳細は Oracle Application Server 10g のインストレーション ガイドを参照してください OracleAS Cold Failover Cluster ノード上の中間層 OracleAS Middle Tier は OracleAS Cold Failover Cluster ソリューションと同じノードにインストールすることもできます ( 図 3-4 を参照 ) OracleAS Middle Tier を OracleAS Cold Failover Cluster の両ノードにインストールすると 両方の中間層インストールが同時にアクティブになり リクエストを処理しますが Infrastructure は一方のノードでのみアクティブになります 図 3-4 に このメカニズムを図示します 3-16 Oracle Application Server 10g 高可用性ガイド

85 Infrastructure の高可用性構成 図 3-4 OracleAS Cold Failover Cluster ソリューションと同じノードにインストールされている OracleAS Middle Tier この設定には 次の特徴があります 中間層をローカル記憶域にインストールし 中間層の前面にロード バランサを配置して中間層間のロード バランシングを可能にする必要があります 中間層では ハードウェア クラスタ システムまたは OracleAS Cold Failover Cluster ソリューションのフェイルオーバー機能のメリットを享受しません これらの中間層は 独自の方法で高可用性を実現しています ( 第 2 章と第 4 章を参照 ) 中間層のインスタンス ( J2EE and Web Cache インストール タイプ ) をグループ化して Oracle Application Server 10g Cluster を形成することができます これにより 第 2 章で説明されている Oracle Application Server 10g Cluster の高可用性属性のメリットを享受することができます Infrastructure の高可用性 3-17

86 Infrastructure の高可用性構成 各ノードでは 中間層と Infrastructure 間のポートの競合を回避する必要があります 中間層と Infrastructure では それぞれ異なるポート番号を使用する必要があります staticports.ini ファイルを使用すると インストール時に競合を回避できます Oracle Application Server 10g のインストレーション ガイドを参照してください あるノードの Infrastructure でソフトウェア障害が発生しても 同じノードの中間層はそのまま使用できる場合があります この状態は Infrastructure が OracleAS Cold Failover Cluster のスタンバイ ノードにフェイルオーバーされた後も継続します 関連項目 : Oracle Application Server 10g のインストレーション ガイド Oracle Application Server Active Failover Cluster(UNIX) Oracle Application Server Active Failover Cluster (OracleAS Active Failover Cluster) は Infrastructure の堅牢なクラスタ アーキテクチャを提供します この高可用性ソリューションは OracleAS Cold Failover Cluster ソリューションよりもさらに透過的です OracleAS Active Failover Cluster ソリューションのノードはすべてアクティブであるため あるノードから別のノードへのフェイルオーバーが迅速に行われ 手動による介入を必要としません アクティブ / アクティブ設定によって 配置される Infrastructure のスケーラビリティも提供されます 図 3-5 に このソリューションの総合的なアーキテクチャを示します 3-18 Oracle Application Server 10g 高可用性ガイド

87 Infrastructure の高可用性構成 図 3-5 OracleAS Active Failover Cluster の高可用性ソリューション Infrastructure の高可用性 3-19

88 Infrastructure の高可用性構成 このソリューションでは OracleAS Active Failover Cluster テクノロジを実行しているハードウェア クラスタの各ノードに Infrastructure のソフトウェアがまったく同じ条件でインストールされます 各ノードには Infrastructure ソフトウェア (Oracle Identity Management ソフトウェアなど ) のローカル コピーとデータベースのインスタンスがあります データベース ファイルは すべてのノードがアクセス可能な共有記憶域にインストールされます データベース インスタンスでは 書込み / 読取り操作に対してデータベースが同時にオープンされます データベース内ではなくファイル システム内にある Infrastructure の構成ファイルは 各ノードでローカルです これらのファイルには ノード固有の構成情報が格納されています クラスタのフロント エンドには ロード バランサ機器があります ロード バランサの障害時に可用性を維持するために このロード バランサはフォルト トレラント モードで配置することをお薦めします ロード バランサ機器は 非 Oracle Net のトラフィックを中間層から Infrastructure に送る際に使用されます このトラフィックには HTTP リクエスト HTTPS リクエスト LDAP リクエストなどがあります ロード バランサの構成は 中間層から任意のアクティブな Infrastructure ノードにリクエストを送るように設定されます 中間層からの Oracle Net のトラフィックは ロード バランサを経由しません このトラフィックは アドレス リストに複数のアドレスが登録された接続記述子を介して Infrastructure ノードに送られます このアドレス リストは Oracle Net の特定のトラフィックを Infrastructure ノード間でロード バランシングする際に使用されます Oracle Net のトラフィックには 次のものによって開始された通信が含まれます JDBC OCI JDBC thin 接続文字列または tnsalias を使用したデータベース リンク データベース アクセス記述子 (DAD) などの tnsalias ベースのアクセス 接続記述子ベースのアクセス OracleAS Active Failover Cluster 高可用性ソリューションを使用すると ノード全体の障害およびノードの各コンポーネント ( データベース インスタンスや Oracle Internet Directory など ) の障害をフェイルオーバーできます このソリューションに関する考慮事項を次に示します 1. OracleAS Active Failover Cluster は ハードウェア クラスタに配置されます 2. クラスタ内のすべてのノードは次の点で同等です a. 実行するオペレーティング システムのバージョンが同じです b. 使用するすべてのソフトウェア (Java Runtime など ) のバージョンが同じであるか または互換性があります c. クラスタのすべてのノードで ORACLE_HOME のパスと構造が同じです d. 各ノードのデータベース インスタンスごとに ORACLE_SID が一意である必要があります 3-20 Oracle Application Server 10g 高可用性ガイド

89 Infrastructure の高可用性構成 e. すべてのデータベース インスタンスで サービス名が共通である必要があります f. Infrastructure コンポーネントのポート番号が同一です 3. Infrastructure コンポーネントは 1 つのクラスタに配置され ( 非対称に分散されるのではなく ) 1 つの OracleAS Active Failover Cluster データベースに配置されます すべてのノードで Infrastructure コンポーネント (OPMN Oracle HTTP Server OracleAS Single Sign-On Oracle Enterprise Manager プロセス Oracle Internet Directory LDAP サーバーおよび Oracle Delegated Administration Services) の構成は同一です Infrastructure の OracleAS Active Failover Cluster 高可用性ソリューションの設定および操作に関する詳細は 第 5 章 Infrastructure の高可用性の管理 を参照してください この高可用性ソリューションのインストール前の作業とインストール作業の詳細は Oracle Application Server 10g のインストレーション ガイドを参照してください ロード バランサの構成 OracleAS Active Failover Cluster で Oracle Internet Directory の LDAP および HTTP (OracleAS Single Sign-On と Oracle Delegated Administration Services 用 ) リクエストを処理するには OracleAS Active Failover Cluster 構成にロード バランサを配置する必要があります ロード バランサの仮想サーバーのホスト名は これらのリクエストに対して Infrastructure のホスト名として公開されます この項では OracleAS Active Failover Cluster のデフォルト インストールにおけるロード バランサの構成要件について説明します 高可用性の推奨事項を次に示します ロード バランサは フォルト トレラント構成で配置する必要があります 2 つのロード バランサを使用します フォルト トレラントのロード バランサは 構成と容量を同一にする必要があります ロード バランサのフェイルオーバーは 自動的に ( 中間層の見地からはシームレスに ) 行われる必要があります 使用するロード バランサのタイプは この章で説明した OracleAS Active Failover Cluster のデフォルト構成において HTTP と LDAP の両方のトラフィックを処理できる必要があります これらのプロトコルのうち 1 つしかサポートしていないロード バランシング メカニズム (HTTP 用の OracleAS Web Cache など ) は このデフォルト構成では使用できません ロード バランサは OracleAS Active Failover Cluster の配置のすべてのノードからアクセス可能である必要があります ロード バランサは Infrastructure へのアクセスを必要とするすべてのマシンからアクセス可能である必要があります ロード バランサでは アイドル接続を削除しないでください 接続の削除に関連付けられているタイムアウトが除去されます Infrastructure の高可用性 3-21

90 Infrastructure の高可用性構成 次に示すロード バランサの 2 つのパラメータは OracleAS Active Failover Cluster 構成で最も重要な意味を持ちます ロード バランサがトラフィックを送るノード ロード バランサの永続性の設定 表 3-2 に ロード バランサのこの 2 つのパラメータの推奨設定を示します ロード バランサには様々なタイプがあり 各タイプによって構成メカニズムが異なります これらの構成における具体的な手順については 各ロード バランサのドキュメントを参照してください 表 3-2 ロード バランサの推奨設定 配置フェーズ OracleAS Active Failover Cluster インストール OracleAS Active Failover Cluster の通常の操作 OracleAS Active Failover Cluster のノードまたはプロセスの停止時 トラフィックのリダイレクション設定 ロード バランサは インストールされるノードにのみトラフィックを送ります ロード バランサは 稼動中でこのトラフィックのロード バランシングが構成されている OracleAS Active Failover Cluster 構成のすべてのノードにトラフィックを送ります ハードウェア クラスタのノードのうち OracleAS Active Failover Cluster で使用されていないノードがある場合は トラフィックのロード バランシングを行うノード数がハードウェア クラスタ内のノード数よりも少なくなることがあります OracleAS Active Failover Cluster のいずれかのノードが使用できない場合や Oracle Internet Directory HTTP または SSO のプロセスのいずれかが停止している場合 ロード バランサはこれらのノードにトラフィックを送ることができません ノードまたはノード上の OracleAS Active Failover Cluster プロセスが停止すると 現行ノードは ロード バランサがトラフィックを送るノードのリストで無効になります 設定の詳細は ロード バランサのドキュメントを参照してください 永続性の設定 N/A LDAP および HTTP のトラフィック用に セッション レベルの永続性を構成する必要があります LDAP および HTTP のトラフィック用に セッション レベルの永続性を構成する必要があります 3-22 Oracle Application Server 10g 高可用性ガイド

91 Infrastructure の高可用性構成 表 3-2 ロード バランサの推奨設定 ( 続き ) 配置フェーズ トラフィックのリダイレクション設定 永続性の設定 中間層の関連付け 中間層のインストール時など 中 LDAP および HTTP リクエ間層を新規に関連付ける場合 スト用に セッション レロード バランサは OracleAS ベルの永続性を構成する必 Active Failover Cluster の 1 つの要があります ノードにのみトラフィックを送る必要があります このノードには クラスタ内の任意のノードを使用できます この操作が必要になるのは 中間層のインストール時のみです 中間層の関連付けが完了したら 以前の状態にロード バランサの構成を戻すことができます OracleAS Active Failover Cluster への既存の接続 ( プライマリ LDAP) を中断せずにこの作業を実行する手順については ロード バランサのドキュメントを参照してください 使用する永続性メカニズムは セッション レベルの持続性を備えている必要があります デフォルトでは HTTP リクエストと Oracle Internet Directory リクエストの両方で ロード バランサに対して構成されている同一の仮想ホスト アドレスが使用されます そのため 使用する永続性メカニズムは両方のタイプのリクエストで利用可能です ロード バランサで 同一の仮想サーバーに対してサーバー ポート (LDAP および HTTP) ごとに異なる永続性メカニズムを構成することが可能である場合は この構成が推奨方法となります この場合 HTTP のトラフィックでは セッション レベルのタイムアウトを設定した Cookie ベースの永続性がより適しています LDAP のトラフィックの場合 永続性の設定は不要です ロード バランサで LDAP と HTTP に対して異なる永続性メカニズムを指定することが許可されていない場合は 配置されたアプリケーションの要件に基づいて セッション レベルの持続性のタイムアウト値を構成する必要があります タイムアウト値はあまり大きくしないでください これは 特定の中間層インスタンスからのトラフィックが常に OracleAS Active Failover Cluster の同じノードに送られる可能性が高くなるためです タイムアウト値が小さすぎる場合は Infrastructure にアクセスする操作の実行時間が長くなると セッションのタイムアウトが発生する可能性が高くなります 持続性の推奨デフォルト タイムアウト値は 60 秒です この値は 配置の性質と OracleAS Active Failover Cluster ノード間のロード バランシングに基づいて調整してください Delegated Administration Services のユーザーにセッションのタイムアウトが発生する場合は この値を増やす必要があります ロード バランシングの効果が出ていない場合は この値を減らします Infrastructure の高可用性 3-23

92 Infrastructure の高可用性構成 ロード バランサの構成後は LDAP と HTTP の両方のトラフィックをテストする必要があります このテストは OracleAS Active Failover Cluster の外部にある任意のマシンで実行します このテストの適用範囲は次のとおりです Oracle Delegated Administration Services の URL に対するアクセスおよびテストを行って HTTP リクエストをテストします OracleAS Single Sign-On の URL に対するアクセスおよびテストを行って HTTP リクエストをテストします LDAP リクエストの ldapsearch コマンドをいくつか実行して Oracle Internet Directory に対するアクセスおよびテストを行います 前述のリクエスト タイプは OracleAS Active Failover Cluster の別なノードに送られる必要があります 目的の操作が正常に完了したら テストが成功したことになります 3-24 Oracle Application Server 10g 高可用性ガイド

93 4 中間層の高可用性の管理と操作 この章では OracleAS Cluster の構成変更および継続的なメンテナンスを行う方法について説明します ノードを個々に管理する場合 ある程度の複雑性は避けられません OracleAS Cluster では 複数のノードを単一のエンティティとして管理することにより 管理の複雑性を軽減することができます ここでは Oracle Enterprise Manager - Application Server Control(Application Server Control) を使用し また必要に応じて dcmctl コマンドライン ユーティリティを使用して OracleAS Cluster を管理および構成する手順について説明します この章の項目は次のとおりです 中間層の高可用性構成の概要 OracleAS Cluster の管理と構成 OracleAS Cluster でのファイルベースのリポジトリの使用 OracleAS Cluster での OC4J の構成 OracleAS Cluster での Oracle HTTP Server の構成 セキュリティ : Single Sign-On の構成 高度なクラスタリング構成 中間層の高可用性の管理と操作 4-1

94 中間層の高可用性構成の概要 中間層の高可用性構成の概要 Oracle Application Server では Oracle Application Server の中間層における高可用性をサポートするために 様々なクラスタリング構成オプションがサポートされています OracleAS Cluster では 構成情報の分散が可能であるため Oracle Application Server の複数のインスタンスを連携させ 外部クライアントに対して単一のシステムとして動作させることができます 全体で冗長なコンポーネントを使用するように構成すると OracleAS Cluster は 可用性の高いシステムをサポートし シングル ポイント障害が発生しない状態でアプリケーションをデプロイおよび実行することができます 注意 : OracleAS Cluster としてクラスタリングできるのは J2EE and Web Cache インストール タイプの OracleAS インスタンスのみです この項の項目は次のとおりです リポジトリを使用して管理される OracleAS Cluster の構成の概要 手動で構成された OracleAS Cluster の構成の概要 OracleAS Web Cache クラスタの概要 関連項目 : 第 2 章 中間層の高可用性 リポジトリを使用して管理される OracleAS Cluster の構成の概要 リポジトリを使用して管理される OracleAS Cluster を管理する場合 管理者は Application Server Control または dcmctl コマンドのいずれかを使用して 共通の構成情報を管理および構成します Oracle Application Server の管理コンポーネントでは クラスタ内の全 Oracle Application Server インスタンスで共通の構成情報がレプリケートされます OracleAS Cluster を使用する場合 そのクラスタで共通の構成情報はクラスタレベルの構成といいます 注意 : クラスタ内にある Oracle Application Server インスタンスごとに 個別に構成可能な構成情報もあります ( このような構成情報は インスタンス固有のパラメータともいいます ) OracleAS Cluster 内の各アプリケーション サーバー インスタンスの基本構成は同じです 基本構成には クラスタレベルの構成は含まれていますが インスタンス固有のパラメータは含まれていません 4-2 Oracle Application Server 10g 高可用性ガイド

95 中間層の高可用性構成の概要 この項の項目は次のとおりです Oracle Application Server Cluster managed using database repository Oracle Application Server Cluster managed using file-based repository OracleAS Cluster の構成に共通の作業 Oracle Application Server Cluster managed using database repository Oracle Application Server Cluster managed using database repository では Oracle9i データベースを使用して クラスタレベルの構成情報とインスタンス固有のパラメータの両方を含む構成情報およびメタデータが格納されます データベース リポジトリを使用すると 情報をデータベース内に格納することにより 構成情報を保護することができます データベースを Oracle Application Server の高可用性ソリューションと組み合せて使用すると 構成情報を保護できるだけでなく システム障害が発生した場合でも処理を続行することができます Oracle Application Server Cluster managed using file-based repository Oracle Application Server Cluster managed using file-based repository では ファイル システムを使用して クラスタレベルの構成情報とインスタンス固有のパラメータの両方を含む構成情報が格納されます Oracle Application Server Cluster managed using file-based repository を使用すると シングル ポイント障害は発生しません Oracle Application Server インスタンスが 1 つ以上停止しても クラスタ内の残りの Oracle Application Server インスタンスでクライアント リクエストを処理できます Oracle Application Server Cluster managed using file-based repository を構成および管理するには 管理者がファームを設定し dcmctl コマンドライン ユーティリティを使用して特定の構成作業を実行する必要があります 関連項目 : OracleAS Cluster でのファイルベースのリポジトリの使用 (4-12 ページ ) OracleAS Cluster の構成に共通の作業 図 4-1 に OracleAS Cluster の Oracle Application Server トップレベル ファームから始まるクラスタ構成階層を示します この図は ファイルベースのリポジトリを使用して管理されるものと データベース リポジトリを使用して管理されるものの両タイプの OracleAS Cluster に当てはまります 図 4-1 は 次のものを含む OracleAS Cluster の構成階層を示しています Oracle Application Server インスタンスを含むクラスタ 1 つの Oracle HTTP Server インスタンスおよび 1 つ以上の OC4J インスタンスを含む Oracle Application Server インスタンス 中間層の高可用性の管理と操作 4-3

96 中間層の高可用性構成の概要 次のものを含む OC4J インスタンス 1 つ以上の OC4J アイランド OC4J アイランド内の 1 つ以上の OC4J プロセス デプロイ済アプリケーション 図 4-1 Application Server Control のクラスタ構成ツリー 4-4 Oracle Application Server 10g 高可用性ガイド

97 OracleAS Cluster の管理と構成 手動で構成された OracleAS Cluster の構成の概要 手動で構成された OracleAS Cluster では 構成情報はローカルの構成ファイルに格納され データベース リポジトリもファイルベースのリポジトリも使用されません 手動で構成されたクラスタでは クラスタの一部である Oracle Application Server インスタンスの構成を同期化することは管理者の役割です OracleAS Web Cache クラスタの概要 OracleAS Web Cache クラスタでは OracleAS Web Cache の複数のインスタンスが 1 つの論理キャッシュとして動作し 高可用性を実現します クラスタ内の各 OracleAS Web Cache を キャッシュ クラスタ メンバーといいます キャッシュ クラスタは 2 つ以上のメンバーで構成できます キャッシュ クラスタ メンバーは互いに通信し 別のキャッシュ クラスタ メンバーがキャッシュしたキャッシュ可能なコンテンツを要求したり キャッシュ クラスタ メンバーに障害が発生したことを検出します あるキャッシュ クラスタ メンバーに障害が発生したことが検出されると 残りのキャッシュ クラスタ メンバーが障害の発生したメンバーのコンテンツの所有権を自動的に引き継ぎます 障害の発生したキャッシュ クラスタ メンバーが復帰すると OracleAS Web Cache によってコンテンツの所有権が再割当てされます OracleAS Cluster の管理と構成 関連項目 : OracleAS Web Cache のクラスタリングおよび OracleAS Web Cache クラスタの構成の詳細は Oracle Application Server Web Cache 管理者ガイド を参照してください この項では OracleAS Cluster の作成および使用方法について説明します この項の情報は データベース リポジトリを使用して管理されるものと ファイルベースのリポジトリを使用して管理されるものの両方の Oracle Application Server Cluster に当てはまります この項の項目は次のとおりです OracleAS Cluster の作成と管理 OracleAS Cluster 内のアプリケーション サーバー インスタンスの管理 注意 : Application Server Control を使用するかわりに dcmctl コマンドを使用して OracleAS Cluster を作成し アプリケーション サーバー インスタンスをクラスタに追加し クラスタを管理することができます 関連項目 : dcmctl コマンドの詳細は Distributed Configuration Management リファレンス ガイド を参照してください 中間層の高可用性の管理と操作 4-5

98 OracleAS Cluster の管理と構成 OracleAS Cluster の作成と管理 単一のリポジトリ ( データベース リポジトリまたはファイルベースのリポジトリのいずれか ) 内の Oracle Application Server インスタンスの集まりをファームといいます Oracle Application Server インスタンスが あるファームの一部である場合 Application Server Control の起動時に そのファームの一部であるアプリケーション サーバー インスタンスすべてのリストを表示することができます Application Server Control のファーム ホームページの スタンドアロン インスタンス 領域に表示されるアプリケーション サーバー インスタンスは クラスタに追加できます この項の項目は次のとおりです インスタンスとファームの関連付け Application Server Control を使用した OracleAS Cluster の作成 Application Server Control を使用した OracleAS Cluster の管理 インスタンスとファームの関連付け Oracle Application Server のインストール時に関連付けを行っていない場合は 次の方法のいずれかを使用して アプリケーション サーバー インスタンスをファームに関連付けることができます データベース リポジトリを使用して管理されるようにインスタンスを関連付ける ファイルベースのリポジトリを使用して管理されるようにインスタンスを関連付ける データベース リポジトリを使用して管理されるようにインスタンスを関連付けるデータベース リポジトリを使用するファームの場合は 次の手順でアプリケーション サーバー インスタンスをファームに追加します 1. Oracle Application Server のインスタンス ホームページにナビゲートします 2. ホーム 領域で Infrastructure リンクを選択し 指示に従ってアプリケーション サーバー インスタンスを Oracle Application Server Infrastructure に関連付けます 関連項目 : Oracle Application Server 10g 管理者ガイド ファイルベースのリポジトリを使用して管理されるようにインスタンスを関連付けるファイルベースのリポジトリを使用して管理されるファームの場合は dcmctl joinfarm コマンドを使用して スタンドアロンのアプリケーション サーバー インスタンスをファームに追加する必要があります 関連項目 : ファイルベースのリポジトリを使用して管理されるファームへの結合 (4-15 ページ ) 4-6 Oracle Application Server 10g 高可用性ガイド

99 OracleAS Cluster の管理と構成 Application Server Control を使用した OracleAS Cluster の作成 新規の OracleAS Cluster は Application Server Control のファーム ホームページを使用して作成します Application Server Control にファーム ホームページが表示されるのは Oracle Application Server インスタンスがファームの一部である場合のみです ファーム ホームページから 次の手順を実行して 新規の OracleAS Cluster を作成します 1. ファーム ホームページにナビゲートします 2. クラスタの作成 ボタンを選択します Application Server Control に クラスタの作成 ページが表示されます 図 4-2 に クラスタの作成 ページを示します 図 4-2 クラスタの作成 ページ 3. 新規クラスタの名前を入力して 作成 をクリックします ファーム内の新規クラスタの名前は それぞれ一意である必要があります 確認のページが表示されます 4. OK をクリックして ファーム ホームページに戻ります 新規の OracleAS Cluster を作成すると ファーム ホームページの クラスタ 領域にそのクラスタが表示されます 作成後の新規のクラスタは空であり アプリケーション サーバー インスタンスは何も含まれていません ファーム ホームページの クラスタへの結合 ボタンを使用して アプリケーション サーバー インスタンスをクラスタに追加します 注意 : ファイルベースのリポジトリを使用する Oracle Application Server Cluster の場合は 1 つのクラスタにつき 4 つ以下の OracleAS インスタンスとすることをお薦めします 中間層の高可用性の管理と操作 4-7

100 OracleAS Cluster の管理と構成 関連項目 : OracleAS Cluster 内のアプリケーション サーバー インスタンスの管理 (4-9 ページ ) Application Server Control を使用した OracleAS Cluster の管理 図 4-3 に cluster1 と cluster2 の 2 つのクラスタを含む Application Server Control ファーム ホームページを示します 図 4-3 Oracle Application Server 10g ファーム ページ 表 4-1 は ファーム ホームページで使用可能なクラスタ制御オプションの一覧です 表 4-1 Oracle Application Server ファーム ページのオプション 目的 OracleAS Cluster 内のすべてのアプリケーション サーバー インスタンスの起動 OracleAS Cluster 内のすべてのアプリケーション サーバー インスタンスの再起動 OracleAS Cluster 内のすべてのアプリケーション サーバー インスタンスの停止 操作 クラスタの横にあるラジオ ボタンを選択し 起動 をクリックします クラスタの横にあるラジオ ボタンを選択し 再起動 をクリックします クラスタの横にあるラジオ ボタンを選択し 停止 をクリックします 4-8 Oracle Application Server 10g 高可用性ガイド

101 OracleAS Cluster の管理と構成 表 4-1 Oracle Application Server ファーム ページのオプション ( 続き ) 目的 OracleAS Cluster の削除 ( そのクラスタ内のアプリケーション サーバー インスタンスを含む ) 操作 クラスタの横にあるラジオ ボタンを選択し 削除 をクリックします OracleAS Cluster 内のアプリケーション サーバー インスタンスの管理 Oracle Application Server では OracleAS Cluster 内で クラスタレベルの構成がレプリケートされます これは クラスタに含まれるアプリケーション サーバー インスタンスが 1 つだけであっても複数であっても同じです OracleAS Cluster を使用して Oracle Application Server Middle Tier の高可用性を実現するには クラスタにアプリケーション サーバー インスタンスを 2 つ以上含める必要があります この項の項目は次のとおりです OracleAS Cluster へのアプリケーション サーバー インスタンスの追加 OracleAS Cluster からのアプリケーション サーバー インスタンスの削除 関連項目 : クラスタレベルの構成の変更および OC4J インスタンスの変更 (4-25 ページ ) dcmctl コマンドの詳細は Distributed Configuration Management リファレンス ガイド を参照してください OracleAS Cluster へのアプリケーション サーバー インスタンスの追加 クラスタにアプリケーション サーバー インスタンスを追加するには 次の手順を実行します 1. ファーム ホームページにナビゲートします 2. スタンドアロン インスタンス セクションで クラスタに追加するアプリケーション サーバー インスタンスのラジオ ボタンを選択します 3. クラスタへの結合 をクリックします 図 4-4 に クラスタへの結合 ページを示します 中間層の高可用性の管理と操作 4-9

102 OracleAS Cluster の管理と構成 図 4-4 クラスタへの結合 ページ 4. アプリケーション サーバー インスタンスの結合先クラスタのラジオ ボタンを選択します 5. 結合 をクリックします 選択したクラスタにアプリケーション サーバー インスタンスが追加され 確認のページが表示されます 6. OK をクリックして ファーム ホームページに戻ります クラスタに結合する他のスタンドアロンのアプリケーション サーバー インスタンスについても それぞれこの手順を繰り返します OracleAS Cluster にアプリケーション サーバー インスタンスを追加するときは 次の点に注意してください OracleAS Cluster にアプリケーション サーバー インスタンスを追加する場合 追加する順番が重要です クラスタに最初に結合するアプリケーション サーバー インスタンスは その後クラスタに結合されるすべてのアプリケーション サーバー インスタンスの基本構成として使用されます 基本構成には クラスタレベルの構成情報がすべて含まれます インスタンス固有のパラメータは含まれません 最初のアプリケーション サーバー インスタンスをクラスタに結合すると その後クラスタに結合されるアプリケーション サーバー インスタンスでは 既存のクラスタレベルの構成情報がこの基本構成で上書きされます 最初のアプリケーション サーバー インスタンスの後にクラスタに結合されたアプリケーション サーバー インスタンスはそれぞれ クラスタに最初に結合されたアプリケーション サーバー インスタンスに指定されている基本構成を継承します アプリケーション サーバー インスタンスをクラスタに結合する前に Application Server Control によってそのインスタンスが停止されます アプリケーション サーバー インスタンスを再起動するには クラスタ リンクを選択し そのクラスタ内で該当するインスタンスを選択して 起動 ボタンをクリックします クラスタに結合されたアプリケーション サーバー インスタンスは スタンドアロン インスタンス 領域から削除されます 1 回の操作で 1 つのクラスタにスタンドアロンのアプリケーション サーバー インスタンスを複数追加するには dcmctl joincluster コマンドを使用します 4-10 Oracle Application Server 10g 高可用性ガイド

103 OracleAS Cluster の管理と構成 特定の Oracle Application Server コンポーネントを含むアプリケーション サーバー インスタンスはクラスタリングできません アプリケーション サーバー インスタンスがクラスタリング可能かどうかをテストするには dcmctl isclusterable コマンドを使用します クラスタリングできないアプリケーション サーバー インスタンスをクラスタに追加しようとすると Application Server Control からエラーが返されます クラスタリング可能にするには OracleAS Cluster のメンバーとなるアプリケーション サーバー インスタンスをすべて同じオペレーティング システム ( 同じ UNIX バリアントも含む ) にインストールする必要があります OracleAS Cluster からのアプリケーション サーバー インスタンスの削除 クラスタからアプリケーション サーバー インスタンスを削除するには 次の手順を実行します 1. ファーム ホームページで目的のクラスタを選択します クラスタ ページが表示されます 2. クラスタから削除するアプリケーション サーバー インスタンスのラジオ ボタンを選択し 削除 をクリックします スタンドアロンのアプリケーション サーバー インスタンスを複数削除するには この手順を複数回繰り返す必要があります OracleAS Cluster からアプリケーション サーバー インスタンスを削除するときは 次の点に注意してください アプリケーション サーバー インスタンスをクラスタから削除する前に Application Server Control によってそのインスタンスが停止されます 操作が完了したら ファーム ホームページの スタンドアロン インスタンス 領域からアプリケーション サーバー インスタンスを再起動します dcmctl leavecluster コマンドを起動するたびに アプリケーション サーバー インスタンスが 1 つずつクラスタから削除されます 最後のアプリケーション サーバー インスタンスをクラスタから削除すると クラスタに関連付けられているクラスタレベルの構成情報も削除されます クラスタは空になり 基本構成は設定されていない状態になります 以降 Oracle Application Server では クラスタに最初に結合されたアプリケーション サーバー インスタンスが 後からクラスタに結合されるすべてのアプリケーション サーバー インスタンスの基本構成として使用されます アプリケーション サーバー インスタンスは クラスタからいつでも削除することができます クラスタに最初に結合されるインスタンスには 特別なプロパティはありません 基本構成はクラスタに最初に結合されるインスタンスから作成されますが このインスタンスは 他のインスタンスと同様にクラスタから削除できます 中間層の高可用性の管理と操作 4-11

104 OracleAS Cluster でのファイルベースのリポジトリの使用 OracleAS Cluster でのファイルベースのリポジトリの使用 データベースに依存せずにクラスタレベルの構成や管理情報を格納する OracleAS Cluster を作成できます ファイルベースのリポジトリを使用すると クラスタレベルの構成情報および関連するメタデータは リポジトリ ホスト ( ホスト ) である Oracle Application Server インスタンスのファイル システムに格納されます ファイルベースのリポジトリを使用するファームの一部である Oracle Application Server インスタンスでは リポジトリ ホストに依存して クラスタレベルの構成情報が格納されます ファイルベースのリポジトリを使用して管理される Oracle Application Server インスタンスを含むファームを作成後 OracleAS Cluster を作成できます この項の項目は次のとおりです ファイルベースのリポジトリ ホストの初期化およびファームへのインスタンスの追加 ファイルベースのリポジトリを使用するファーム内のインスタンスの管理 ファイルベースのリポジトリ ホストの初期化およびファームへのインスタンスの追加 この項では ファイルベースのリポジトリを使用するファームの作成方法について説明します この項の項目は次のとおりです whichfarm を使用したインスタンスのテストおよびファームからの削除 ファイルベースのリポジトリのリポジトリ ホスト インスタンスの初期化 ファイルベースのリポジトリを使用して管理されるファームへの結合 ファイルベースのリポジトリを使用して管理される Oracle Application Server インスタンスを含むファームを作成後 Application Server Control または dcmctl コマンドを使用して OracleAS Cluster を作成できます whichfarm を使用したインスタンスのテストおよびファームからの削除 ファイルベースのリポジトリを作成するには スタンドアロンのアプリケーション サーバー インスタンスから開始する必要があります スタンドアロンのアプリケーション サーバー インスタンスとは ファームに関連付けられていないインスタンスです ファイルベースのリポジトリのリポジトリ ホストとして使用する Oracle Application Server インスタンスがスタンドアロン インスタンスであることを確認するには 次のコマンドを発行します % dcmctl whichfarm インスタンスがファームに関連付けられていない場合 このコマンドからは次の情報が返されます Standalone OracleAS instance 4-12 Oracle Application Server 10g 高可用性ガイド

105 OracleAS Cluster でのファイルベースのリポジトリの使用 注意 : 詳細モードをオンにして dcmctl を実行すると whichfarm コマンドから詳細な出力が返されます 詳細モードがオフの場合は whichfarm で返される出力は少なくなります 詳細モードをオフに設定するには dcmctl set -v off を使用します 同様に 詳細モードをオンに設定するには dcmctl set -v on を使用します 表 4-2 に whichfarm からの出力例を示します スタンドアロン インスタンスではない場合 whichfarm から そのインスタンスがファームの一部であることを示す情報が返されます 表 4-2 dcmctl whichfarm コマンドの詳細出力 whichfarm を実行するインスタンスのタイプ スタンドアロン インスタンス ファイルベースのリポジトリ : リポジトリ ホスト インスタンス ( ホスト ) ファイルベースのリポジトリ : リポジトリ ホスト インスタンス以外 データベース リポジトリ : Infrastructure インスタンス データベース リポジトリ : Infrastructure インスタンス以外 生成される出力 % dcmctl whichfarm Standalone OracleAS instance % dcmctl whichfarm Farm Name:.private.904M13.dcm.repository Host Instance: 904M13.sc-sun.us.oracle.com Host Name: sc-sun.us.oracle.com Repository Type: Distributed File Based (host) SSL In Use: false % dcmctl whichfarm Farm Name:.private.904M13.dcm.repository Host Instance: 904M13.sc-sun.us.oracle.com Host Name: sc-sun.us.oracle.com Repository Type: Distributed File Based SSL In Use: false % dcmctl whichfarm Host Instance: 904M12infra.sc-sun.us.oracle.com Host Name: sc-sun.us.oracle.com Repository Type: Database (host) % dcmctl whichfarm Farm Name: tv1.us.oracle.com Host Instance: 904M12infra.sc-sun.us.oracle.com Host Name: sc-sun.us.oracle.com Repository Type: Database ファイルベースのリポジトリで使用するインスタンスが既存のファームの一部である場合 まずファームからインスタンスを削除しないと ファイルベースのリポジトリを初期化することはできません 中間層の高可用性の管理と操作 4-13

106 OracleAS Cluster でのファイルベースのリポジトリの使用 注意 : あるインスタンスで leavefarm コマンドを使用すると そのインスタンスで実行されているすべての Oracle Application Server コンポーネントが停止します leavefarm コマンドを使用してファームからインスタンスを削除するには 次のように入力します % dcmctl leavefarm ファームからインスタンスが削除されると whichfarm から次の情報が返されます % dcmctl whichfarm Standalone OracleAS instance dcmctl leavefarm を使用してファームからインスタンスを削除する場合 次のような制限があります dcmctl leavefarm を Oracle Application Server Infrastructure システムで使用する場合 その Infrastructure システムがファーム内で唯一の Oracle Application Server インスタンスである場合を除き dcmctl からエラーが報告されます dcmctl leavefarm コマンドを実行すると その Oracle Application Server インスタンスで実行されているすべての Oracle Application Server コンポーネントが停止します 他の Oracle Application Server インスタンスのリポジトリの役割を果たしている Oracle Application Server Infrastructure システムでは leavefarm を使用できません Oracle Application Server Infrastructure で leavefarm を実行するには まず Oracle Application Server インスタンスに移動して そこで leavefarm を実行する必要があります ファイルベースのリポジトリのリポジトリ ホスト インスタンスの初期化 ファイルベースのリポジトリのリポジトリ ホストとする Oracle Application Server インスタンスを選択したら 次の手順でファームを作成し リポジトリ ホスト インスタンス上でファイルベースのリポジトリを初期化します 1. ファイルベースのリポジトリのリポジトリ ホスト インスタンスとなる Oracle Application Server インスタンスで次のコマンドを発行します dcmctl getrepositoryid 2. 取得したリポジトリ ID を使用して 次のコマンドを発行します dcmctl joinfarm -r <repositoryid> 4-14 Oracle Application Server 10g 高可用性ガイド

107 OracleAS Cluster でのファイルベースのリポジトリの使用 repositoryid は 手順 1 で返された値です dcmctl joinfarm コマンドにより リポジトリ ホスト インスタンスが設定され ファイルベースのリポジトリを使用して管理されるファームが初期化されます Oracle Application Server は ファームの構成情報をリポジトリ ホスト インスタンス上のファイルベースのリポジトリに格納します 注意 : dcmctl コマンドを使用してファームを作成した場合に Application Server Control を使用して変更を表示するには Application Server Control を再起動する必要があります Application Server Control を再起動するには emctl start および stop コマンドを使用します ファイルベースのリポジトリを使用して管理されるファームへの結合 ファイルベースのリポジトリのリポジトリ ホスト インスタンスを選択し ファイルベースのリポジトリを初期化したら 次の手順でアプリケーション サーバー インスタンスをファームに追加します 1. リポジトリ ホスト インスタンス上でリポジトリ ID を取得します この ID を取得するには 次のコマンドを発行します dcmctl getrepositoryid リポジトリ ホスト インスタンスのリポジトリ ID を取得するには 結合先のファームの一部である任意のシステムで getrepositoryid コマンドを発行します ( つまり 別のインスタンスで同じリポジトリ ホスト インスタンスが使用されている場合 dcmctl getrepositoryid コマンドをそのシステムで使用できます ) 2. ファームに追加するアプリケーション サーバー インスタンスで 次のコマンドを実行します dcmctl joinfarm -r <repositoryid> repositoryid には 手順 1 で返された値を指定します 注意 : この手順では 現在のインスタンスのリポジトリ ID は指定しないでください かわりに ファームのリポジトリ ホスト インスタンスのリポジトリ ID を使用するか またはすでに結合先のファームの一部である任意のインスタンスのリポジトリ ID を使用します ( この値は 同じファイルベースのリポジトリを使用しているすべての Oracle Application Server インスタンスで同じです ) また dcmctl joinfarm コマンドを実行後 Application Server Control を使用して変更を表示するには Application Server Control を再起動する必要があります Application Server Control を再起動するには emctl start および stop コマンドを使用します 中間層の高可用性の管理と操作 4-15

108 OracleAS Cluster でのファイルベースのリポジトリの使用 関連項目 : dcmctl コマンドの詳細は Distributed Configuration Management リファレンス ガイド を参照してください ファイルベースのリポジトリを使用するファーム内のインスタンスの管理 この項の項目は次のとおりです ファイルベースのリポジトリを使用した Oracle Application Server インスタンスおよび Oracle Application Server Cluster の管理 ファイルベースのリポジトリを使用する OracleAS Cluster の可用性に関する問題 ファイルベースのリポジトリを使用した構成情報のエクスポートとインポート リポジトリ間のインスタンスの移動 ファイルベースのリポジトリを使用しているインスタンス間の通信での SSL の有効化 ファイルベースのリポジトリを使用した Oracle Application Server インスタンスおよび Oracle Application Server Cluster の管理 ファイルベースのリポジトリを使用して管理するファームを設定したら Application Server Control または dcmctl コマンドを使用して ファーム内で OracleAS Cluster を作成および管理できます また ファーム内のスタンドアロンのインスタンスを クラスタに結合するように構成することもできます 注意 : ファイルベースのリポジトリを使用する Oracle Application Server Cluster の場合は 1 つのクラスタにつき 4 つ以下の OracleAS インスタンスとすることをお薦めします 関連項目 : OracleAS Cluster の管理と構成 (4-5 ページ ) dcmctl コマンドの詳細は Distributed Configuration Management リファレンス ガイド を参照してください 4-16 Oracle Application Server 10g 高可用性ガイド

109 OracleAS Cluster でのファイルベースのリポジトリの使用 ファイルベースのリポジトリを使用する OracleAS Cluster の可用性に関する問題 OracleAS Cluster をファイルベースのリポジトリとともに使用する際の重要な考慮事項は どの Oracle Application Server インスタンスをリポジトリ ホストとするかの判断です ファイルベースのリポジトリのリポジトリ ホストを選択するときは 次の点を考慮してください リポジトリ ホスト インスタンスが一時的に使用できない場合 ファイルベースのリポジトリを使用する OracleAS Cluster は引き続き正常に動作可能ですが 構成情報を更新することはできません リポジトリ ホスト インスタンスである Oracle Application Server インスタンスでは クラスタ関連の構成情報がそれ自体のファイル システムに格納および管理されるため リポジトリ ホスト インスタンスではミラー化ディスクまたは RAID ディスクを使用する必要があります リポジトリ ホスト インスタンスでディスクのミラー化を使用すると OracleAS Cluster の可用性が向上します リポジトリ ホスト インスタンスが使用できない場合 実行中のどの Oracle Application Server インスタンスでも 読取り専用の構成操作に影響はありません ( ファームのクラスタレベルの構成情報は ローカルの Oracle Application Server Java Object Cache によって分散 管理されます ) リポジトリ ホスト インスタンスが使用できない場合 ファイルベースのリポジトリ内の構成情報を変更しようとするとエラーが生成されます このような操作は リポジトリ ホスト インスタンスが使用可能になってから またはリポジトリ ホスト インスタンスがファーム内の別のアプリケーション サーバー インスタンスに移動されてから実行する必要があります ファイルベースのリポジトリを使用した構成情報のエクスポートとインポート Oracle Application Server では ファイルベースのリポジトリを保存して リポジトリ ホスト インスタンスが停止したりファイル システムが損傷した場合でも完全に失われないようにするためのコマンドが提供されています exportrepository コマンドを使用すると ファイルベースのリポジトリ全体を保存できます exportrepository コマンドを使用して構成情報を保存した後に importrepository を使用して リポジトリ ホスト インスタンスまたはファーム内の別のインスタンスに 保存した構成情報を復元できます リポジトリ ホスト インスタンスからリポジトリをエクスポートするには 次のコマンドを実行します dcmctl exportrepository -file <file_name> 保存済のファイルベースのリポジトリを ファームのリポジトリ ホスト インスタンスとなるシステムにインポートするには 次のコマンドを実行します dcmctl importrepository -file <file_name> 中間層の高可用性の管理と操作 4-17

110 OracleAS Cluster でのファイルベースのリポジトリの使用 注意 : importrepository オプションを指定して dcmctl を実行する前に 同じファーム内の dcmctl の実行元である現行のインスタンスを除くインスタンスに含まれる DCM デーモンをすべて停止します 各インスタンスで次のコマンドを使用します ORACLE_HOME/opmn/bin/opmnctl stopproc ias-component=dcm-daemon file_name には dcmctl exportrepository コマンドを使用して作成した保存済のファイルを指定します ファイルベースのリポジトリを別の Oracle Application Server インスタンスに復元すると importrepository を実行するインスタンスが新規のリポジトリ ホスト インスタンスになります それまでファイルベースのリポジトリのリポジトリ ホスト インスタンスだった Oracle Application Server インスタンスがリポジトリ ホスト インスタンスではなくなったことを指定するには 次のコマンドを発行します dcmctl repositoryrelocated 注意 : それまでリポジトリ ホスト インスタンスだったインスタンスをファームに結合する場合は 必ずその古いリポジトリ ホスト インスタンスで repositoryrelocated を実行してください リポジトリ間のインスタンスの移動 ファイルベースのリポジトリを使用するファームに結合されている Oracle Application Server インスタンスは ファイルベースでもデータベースベースでも 別のリポジトリに移動できます タイプの異なるリポジトリに移動するには ファームから削除した上で別のファームに結合する必要があります OracleAS インスタンスは ファームから削除すると 基本的にはスタンドアロンのインスタンスになります リポジトリ内にある インスタンスの DCM で管理されている構成メタデータは そのインスタンスに移動されます インスタンスのアーカイブもすべて削除されます ただし 他のコンポーネント (Oracle Application Server Single Sign-On JAAS および Oracle Internet Directory) 用に存在する Infrastructure データベースへの接続は削除されません ファームからインスタンスを削除するには OracleAS インスタンスで次のコマンドを実行します dcmctl leavefarm 4-18 Oracle Application Server 10g 高可用性ガイド

111 OracleAS Cluster でのファイルベースのリポジトリの使用 注意 : dcmctl leavefarm コマンドを実行したら ファームから削除したばかりのインスタンス用に新しいベースライン アーカイブを作成することをお薦めします アーカイブの手順は Distributed Configuration Management リファレンス ガイド を参照してください 次の各項では OracleAS インスタンスをファイルベースのリポジトリから他のリポジトリに移動する手順について説明します データベースベースのリポジトリへの移動 別のファイルベースのリポジトリへの移動 データベースベースのリポジトリへの移動 OracleAS インスタンスをファイルベースのリポジトリからデータベースベースのリポジトリへ移動する場合は まずリポジトリのファームからインスタンスを削除して インスタンスと現行のリポジトリの関連付けを解除する必要があります そうすると このインスタンスはスタンドアロン インスタンスとなり この時点でデータベースベースのリポジトリのファームに結合できるようになります これらの作業を実行する手順は次のとおりです 1. 次のコマンドを使用して 該当するインスタンスがまだファームの一部であるかどうかを確認します dcmctl whichfarm 2. コマンドからファーム名が返された場合 OracleAS インスタンスは まだファームの一部であり 既存のリポジトリに関連付けられています dcmctl leavefarm コマンドを使用して インスタンスをスタンドアロンの状態にします 3. データベースベースのリポジトリのファームに初めてインスタンスを結合する場合 その構成メタデータは リポジトリ内にありません Application Server Control を使用して リポジトリのファームに結合します この手順は Oracle Application Server 10g 管理者ガイド に記載されています 4. データベースをベースとするリポジトリのファームに 以前そのファームのメンバーだったインスタンスを結合する場合は 次のコマンドを使用してファームに再結合します dcmctl joinfarm 中間層の高可用性の管理と操作 4-19

112 OracleAS Cluster でのファイルベースのリポジトリの使用 別のファイルベースのリポジトリへの移動ファイルベースのリポジトリを使用している別のファームにインスタンスを結合するには dcmctl コマンドをファイルベースのリポジトリの ID とともに使用します OracleAS インスタンスのコマンドラインで 次の手順を実行します 1. 次のコマンドを実行します dcmctl whichfarm 2. コマンドからファーム名が返された場合 OracleAS インスタンスは まだファームの一部であり 既存のリポジトリに関連付けられています dcmctl leavefarm コマンドを使用して インスタンスをスタンドアロンの状態にします 3. このインスタンスがどのファームの一部でもないことを確認した上で 結合先のリポジトリのファームに結合されているインスタンスの 1 つで次のコマンドを実行します このコマンドを実行すると ファイルベースのリポジトリのリポジトリ ID を取得できます スタンドアロン インスタンスが存在するホストをリポジトリ ホストとして使用して ファイルベースのリポジトリを新規に設定および結合する場合は スタンドアロン インスタンスで次のコマンドを実行します dcmctl getrepositoryid ホスト名 : ポート という形式のリポジトリ識別子が返されます 4. 次のコマンドを使用して 目的のリポジトリのファームに結合します dcmctl joinfarm -r <repository_id> 注意 : dcmctl joinfarm コマンドを実行後 Application Server Control を使用して変更を表示するには Application Server Control を再起動する必要があります Application Server Control を再起動するには emctl start および stop コマンドを使用します 関連項目 : Distributed Configuration Management リファレンス ガイド ファイルベースのリポジトリを使用しているインスタンス間の通信での SSL の有効化 ファーム内のインスタンスでファイルベースのリポジトリが使用されている場合 インスタンス間での構成情報の送信に SSL を使用するように DCM を構成することができます この機能により ファーム内のすべてのインスタンス間で送信されるメッセージのセキュリティを確保し 認可されていないインスタンスがファームに結合されることを防止できます 4-20 Oracle Application Server 10g 高可用性ガイド

113 OracleAS Cluster でのファイルベースのリポジトリの使用 この項では ファイルベースのリポジトリを使用するインスタンス用に SSL および証明書ベースのセキュリティを設定する手順について説明します 全体の手順は次のとおりです キーストアの生成 各インスタンスでの Oracle Application Server プロセスの停止 ファーム内の各インスタンスでのキーストア情報ファイルの設定 dcmcache.xml の構成による SSL の有効化 構成変更の適用の確認 ファーム内の各インスタンスの起動 SSL が有効化されたファームへの新規インスタンスの追加 キーストアの生成 JDK の keytool コマンドを使用して 証明書を生成し キーストアを設定します これについては次のサイトに説明があります 鍵ペアをすでに生成していて OC4J の証明書を取得してある場合は 取得済の同じキーストアを使用できます SSL 証明書ベースのセキュリティを使用するには ファーム内のインスタンスごとに Java キーストアを設定する必要があります このキーストアは 他の Java アプリケーションで使用しているものと同じでも ファイルベースの DCM リポジトリ構成独自のものでもかまいません ファーム内のインスタンスごとに 各キーストアの場所へのパスを書き留めます 各インスタンスでの Oracle Application Server プロセスの停止ファームの各インスタンスで 次のコマンドを実行して Oracle Application Server プロセスを停止します UNIX の場合 $ORACLE_HOME/bin/emctl stop iasconsole $ORACLE_HOME/dcm/bin/dcmctl stopproc Windows の場合 %ORACLE_HOME% bin emctl stop iasconsole %ORACLE_HOME% dcm bin dcmctl shutdown ファーム内の各インスタンスでのキーストア情報ファイルの設定キーストアおよび証明書の情報を取得したら ファーム内の Oracle Application Server インスタンスごとに dcmctl configrepositoryssl コマンドを使用して キーストア情報を保存するファイルを作成する必要があります 中間層の高可用性の管理と操作 4-21

114 OracleAS Cluster でのファイルベースのリポジトリの使用 重要 : キーストア情報ファイルは ファーム内のどのインスタンスよりも前に ファイルベースのリポジトリのリポジトリ ホスト インスタンスに対して設定する必要があります リポジトリ ホストとホスト インスタンスを検索するには 次のコマンドを実行します dcmctl getrepositoryid キーストア情報ファイルを設定するには 最初にファイルベースのリポジトリのリポジトリ ホスト インスタンスに対して次の手順を実行します ( この手順が完了したら 残りのインスタンスに対して 順不同で同じ手順を実行できます ) 1. 最初のステップの キーストアの生成 で生成したキーストア ファイルを ローカル ホスト内の場所にコピーします 2. インスタンスごとに次のように configrepositoryssl を使用して キーストア情報ファイルを作成します dcmctl configrepositoryssl -keystore <path_to_keystore> -storepass <password> 生成されたファイル.ssl.conf は <ORACLE_HOME>/dcm/config に格納されます dcmcache.xml の構成による SSL の有効化 SSL の使用を有効または無効にするには dcmcache.xml キャッシュ構成の <usessl> 属性 ( 表 4-3 を参照 ) を変更します オプションで <sslconfigfile> 要素の値を変更することによって configrepositoryssl を使用して生成したファイルの場所を指定することができます この値を変更する場合は configrepositoryssl によって生成される.ssl.conf ファイルを <sslconfigfile> で指定する新規ファイルにコピーする必要があります dcmcache.xml ファイルは Unix の場合は $ORACLE_HOME/dcm/config ディレクトリ Windows の場合は %ORACLE_HOME% dcm config ディレクトリにあります 表 4-3 ファイルベースのリポジトリを使用しているファームで SSL を有効化するための要素 要素 <usessl> true false </usessl> 説明 ファイルベースの DCM リポジトリ通信メカニズムで SSL を使用する場合は true に SSL の使用を無効にする場合は false に設定します デフォルト値は false です 有効な値 : true false <sslconfigfile> sslfile </sslconfigfile> SSL 構成ファイルの名前 sslfile を指定します デフォルト値は.ssl.conf です ほとんどのインストールで この要素のデフォルト値を変更する必要はありません 4-22 Oracle Application Server 10g 高可用性ガイド

115 OracleAS Cluster でのファイルベースのリポジトリの使用 構成変更の適用の確認リポジトリ ホスト インスタンスから始めて ファーム内のすべてのインスタンスで次のコマンドを実行して 構成変更が適用されていることを確認します dcmctl getstate ファイルベースのリポジトリを使用するローカル インスタンスの同期状態が表示されます ファーム内の各インスタンスの起動ファーム内の全インスタンスでセキュリティ構成が一貫性のあるものになったら 次のコマンドを使用して リポジトリ ホスト インスタンスから始めて 各インスタンスを再起動します UNIX の場合 $ORACLE_HOME/opmn/bin/opmnctl startall $ORACLE_HOME/bin/emctl start iasconsole Windows の場合 %ORACLE_HOME% opmn bin opmnctl startall %ORACLE_HOME% bin emctl start iasconsole SSL が有効化されたファームへの新規インスタンスの追加 SSL を使用しているファームに スタンドアロンのインスタンスを追加できます それには スタンドアロン マシンで次の手順を実行します 1. 最初のステップの キーストアの生成 で生成したキーストア ファイルを ローカル ホスト内の場所にコピーします 2. インスタンスごとに次のように configrepositoryssl を使用して キーストア情報ファイルを作成します dcmctl configrepositoryssl -keystore <path_to_keystore> -storepass <password> 生成されたファイル.ssl.conf は <ORACLE_HOME>/dcm/config に格納されます ページの ファイルベースのリポジトリを使用して管理されるファームへの結合 の手順に従って ファームにインスタンスを結合します 中間層の高可用性の管理と操作 4-23

116 OracleAS Cluster での OC4J の構成 OracleAS Cluster での OC4J の構成 この項では リポジトリを使用して管理される OracleAS Cluster の一部である OC4J インスタンスおよびプロセスの OC4J 構成について説明します この項の項目は次のとおりです OC4J インスタンス用の OracleAS Cluster 構成の概要 クラスタレベルの構成の変更および OC4J インスタンスの変更 OC4J インスタンス固有のパラメータの構成 関連項目 : OC4J インスタンスの構成に関する詳細は Oracle Application Server Containers for J2EE ユーザーズ ガイド を参照してください OC4J インスタンス用の OracleAS Cluster 構成の概要 アプリケーション サーバー インスタンスを OracleAS Cluster に結合すると アプリケーション サーバー インスタンスとそのインスタンス上で実行される OC4J インスタンスのプロパティは 次のようになります 各アプリケーション サーバー インスタンスでは クラスタレベルの構成は同じです Application Server Control または dcmctl を使用して 任意のクラスタレベルの OC4J パラメータを変更すると 変更内容はクラスタ内のすべてのアプリケーション サーバー インスタンスに伝播されます クラスタレベルの OC4J 構成を変更するには 1 つのアプリケーション サーバー インスタンスで構成パラメータを変更します そうすると Oracle Application Server の Distributed Configuration Management システムによって クラスタ内のその他すべてのアプリケーション サーバー インスタンスに変更内容が伝播されます クラスタの一部である OC4J インスタンスで インスタンス固有のパラメータを変更しても 変更がクラスタ間で伝播されることはありません インスタンス固有のパラメータの変更は 変更が行われた特定のアプリケーション サーバー インスタンスにのみ適用されます システム メモリーの合計などの性能は クラスタ内のアプリケーション サーバー インスタンスを実行しているホストごとに異なる可能性があるため OC4J インスタンス内の OC4J プロセスを実行する際の構成オプションは 必要に応じて変えたほうがよい場合があります 表 4-4 は OC4J のインスタンス固有のパラメータを要約したものです その他の OC4J パラメータはクラスタレベルのパラメータであり OracleAS Cluster 間でレプリケートされます 4-24 Oracle Application Server 10g 高可用性ガイド

117 OracleAS Cluster での OC4J の構成 表 4-4 リポジトリを使用して管理される OracleAS Cluster の OC4J インスタンス固有のパラメータの要約 OC4J パラメータ アイランド定義 OC4J プロセスの数 ポート番号 説明 アプリケーション サーバー インスタンス間でアイランドの名前の一貫性を保つ必要がある一方 アイランドの定義および各アイランドに関連付けられる OC4J プロセスの数はインスタンスごとに構成され Oracle Application Server 構成管理システムがクラスタ間で構成をレプリケートすることはありません 注意 : 同じ名前を持つ OC4J アイランドでは アプリケーションの境界を越えて またクラスタ間で 状態がレプリケートされます そのため ステートフル アプリケーションで高可用性を確保するには クラスタ間の各 OC4J インスタンスで OC4J アイランドの名前を同じにする必要があります アプリケーション サーバー インスタンス間でアイランドの名前の一貫性を保つ必要がある一方 アイランドの定義および各アイランドに関連付けられる OC4J プロセスの数はインスタンスごとに構成され Oracle Application Server 構成管理システムがクラスタ間で構成をレプリケートすることはありません ホストの性能に応じて アイランドごとに実行するよう指定されている OC4J プロセスの数を調整することができます RMI JMS および AJP のポート番号は ホストごとに別々のものを使用できます コマンドライン オプション コマンドライン オプションは ホストごとに別々のものを使用できます クラスタレベルの構成の変更および OC4J インスタンスの変更 この項の項目は次のとおりです OracleAS Cluster での OC4J インスタンスの作成または削除 OracleAS Cluster へのアプリケーションのデプロイ OracleAS Cluster 用の Web アプリケーション状態レプリケーションの構成 OracleAS Cluster 用の EJB アプリケーション状態レプリケーションの構成 OracleAS Cluster 用のステートフル Session Bean レプリケーションの構成 関連項目 : OC4J の構成およびアプリケーションのデプロイに関する詳細は Oracle Application Server Containers for J2EE ユーザーズ ガイド を参照してください 中間層の高可用性の管理と操作 4-25

118 OracleAS Cluster での OC4J の構成 OracleAS Cluster での OC4J インスタンスの作成または削除 管理されている OracleAS Cluster 内の任意のアプリケーション サーバー インスタンス上に新規の OC4J インスタンスを作成すると その OC4J インスタンスはクラスタ間ですべてのアプリケーション サーバー インスタンスに伝播されます OC4J インスタンスを作成するには 次の手順を実行します 1. クラスタ内の任意のアプリケーション サーバー インスタンスにナビゲートします 2. OC4J インスタンスの作成 ボタンを選択します 新規インスタンスの名前の指定を求めるページが表示されます フィールドに名前を入力します 3. 作成 をクリックします 4. Oracle Application Server の Distributed Configuration Management システムによって 新規の OC4J インスタンスがクラスタ間で伝播されます 新規の OC4J インスタンスが 指定した名前で作成されます この OC4J インスタンスは クラスタ間で各アプリケーション サーバー インスタンスのページの システム コンポーネント セクションに表示されます OC4J インスタンスを削除するには 削除する OC4J インスタンスの横にあるラジオ ボタンを選択して 削除 をクリックします Oracle Application Server の Distributed Configuration Management システムによって OC4J の削除がクラスタ間で伝播されます OracleAS Cluster へのアプリケーションのデプロイ OracleAS Cluster を使用して 1 つのアプリケーション サーバー インスタンスにアプリケーションをデプロイすると そのアプリケーションはクラスタ間ですべてのアプリケーション サーバー インスタンスに伝播されます アプリケーションをクラスタ間でデプロイするには 次の手順を実行します 1. アプリケーションのデプロイ先のクラスタを選択します 2. クラスタ内から任意のアプリケーション サーバー インスタンスを選択します 3. アプリケーションのデプロイ先のアプリケーション サーバー インスタンスで OC4J インスタンスを 1 つ選択します 4. Application Server Control または dcmctl コマンドを使用して アプリケーションを OC4J インスタンスにデプロイします 5. Oracle Application Server の Distributed Configuration Management システムによって アプリケーションがクラスタ間で伝播されます 関連項目 : OC4J インスタンスへのアプリケーションのデプロイに関する詳細は Oracle Application Server Containers for J2EE ユーザーズ ガイド を参照してください 4-26 Oracle Application Server 10g 高可用性ガイド

119 OracleAS Cluster での OC4J の構成 OracleAS Cluster 用の Web アプリケーション状態レプリケーションの構成 Oracle Application Server で OracleAS Cluster 間でステートフル Web アプリケーションの状態を確実に維持できるようにするには Web アプリケーション用に状態レプリケーションを構成する必要があります ステートフル Web アプリケーションの状態レプリケーションを構成するには 次の手順を実行します 1. OC4J ホームページで 管理 リンクを選択します 2. インスタンス プロパティ 列の レプリケーション プロパティ を選択します 3. 下にスクロールして Web アプリケーション セクションを表示します 図 4-5 に このセクションを示します 4. セッション状態レプリケーション チェック ボックスを選択します オプションで マルチキャスト ホストの IP アドレスとポート番号を指定できます マルチキャスト アドレスのホストとポートを指定しない場合 デフォルトでは ホストの IP アドレスとして ポート番号として 9127 が使用されます ホストの IP アドレスは から までの間である必要があります HTTP 用と EJB 用のマルチキャスト アドレスには それぞれ異なるマルチキャスト アドレスを使用してください 注意 : マルチキャスト アドレスを選択する場合は 次のサイトにあるアドレスと重複しないよう注意してください アドレスの下位 23 ビットがローカル ネットワーク制御ブロック ( ~ ) と同じである場合 重複が発生する可能性があります これを避けるには アドレスの下位 23 ビットにこの範囲内のアドレスと同じビットを持つアドレスを使用しないでください 5. すべての Web アプリケーション内のすべての web.xml ファイルに <distributable/> タグを追加します Web アプリケーションがシリアライズ可能な場合 このタグを web.xml ファイルに追加する必要があります このタグを web.xml に追加する場合の例は 次のようになります <web-app> <distributable/> <servlet>... </servlet> </web-app> 中間層の高可用性の管理と操作 4-27

120 OracleAS Cluster での OC4J の構成 図 4-5 Web 状態レプリケーションの構成 関連項目 : Oracle Application Server Containers for J2EE ユーザーズ ガイド OracleAS Cluster 用の EJB アプリケーション状態レプリケーションの構成 EJB クラスタを作成するには クラスタに追加する OC4J インスタンスを指定し それぞれを同じマルチキャスト アドレス ユーザー名 パスワードで構成して クラスタリングする EJB をクラスタ内の各ノードにデプロイします HTTP クラスタリングとは異なり クラスタに追加される EJB は アイランド内でサブグループ化することはできません クラスタ内の EJB はすべて 1 つのグループに属します また Session Bean のみがクラスタリングされます 各メソッド コールの終了時に すべての Bean の状態が マルチキャスト トピックを使用してクラスタ内のすべてのノードにレプリケートされます EJB クラスタに含まれるノードはそれぞれ 同じマルチキャスト アドレスを使用するように構成されます クラスタ内で EJB オブジェクトの状態をレプリケートする方法を理解するための概要は Oracle Application Server Containers for J2EE Enterprise JavaBeans 開発者ガイド を参照してください EJB レプリケーションを構成するには 次の手順を実行します 1. OC4J ホームページで 管理 リンクを選択します 2. インスタンス プロパティ 列の レプリケーション プロパティ を選択します 3. EJB アプリケーション セクションで レプリケート状態 チェック ボックスを選択します 図 4-6 に このセクションを示します 4. クラスタ内の他のホストへの認証に使用するユーザー名とパスワードを入力します クラスタ内の他のホストでユーザー名とパスワードが異なる場合 通信は失敗します 1 つのマルチキャスト アドレスで ユーザー名とパスワードの組合せを複数使用できます ユーザー名とパスワードの組合せが同じものは 一意なクラスタと見なされます 4-28 Oracle Application Server 10g 高可用性ガイド

121 OracleAS Cluster での OC4J の構成 オプションで マルチキャスト ホストの IP アドレスとポート番号を指定できます マルチキャスト アドレスのホストとポートを指定しない場合 デフォルトでは ホストの IP アドレスとして ポート番号として 9127 が使用されます ホストの IP アドレスは から までの間である必要があります HTTP 用と EJB 用のマルチキャスト アドレスには それぞれ異なるマルチキャスト アドレスを使用してください 注意 : マルチキャスト アドレスを選択する場合は 次のサイトにあるアドレスと重複しないよう注意してください アドレスの下位 23 ビットがローカル ネットワーク制御ブロック ( ~ ) と同じである場合 重複が発生する可能性があります これを避けるには アドレスの下位 23 ビットにこの範囲内のアドレスと同じビットを持つアドレスを使用しないでください 5. JAR ファイル内の orion-ejb-jar.xml ファイルで EJB レプリケーションのタイプを構成します 詳細は 4-30 ページの OracleAS Cluster 用のステートフル Session Bean レプリケーションの構成 を参照してください これらは デプロイ前に orion-ejb-jar.xml ファイル内で構成するか またはデプロイ後に Application Server Control 画面を使用して追加することができます デプロイ後に追加するには アプリケーション ページから JAR ファイルにドリルダウンします 図 4-6 EJB 状態レプリケーションの構成 中間層の高可用性の管理と操作 4-29

122 OracleAS Cluster での OC4J の構成 OracleAS Cluster 用のステートフル Session Bean レプリケーションの構成 ステートフル Session Bean では orion-ejb-jar.xml ファイルを変更して状態レプリケーションの構成を追加する必要がある場合があります ステートフル Session Bean のレプリケーション タイプは Bean のデプロイメント ディスクリプタ内で構成するため Bean ごとに異なるタイプのレプリケーションを使用することができます ステートフル Session Bean では ノード間で状態をレプリケートする必要があります 実際に ステートフル Session Bean はノード間ですべての状態を送信する必要があり パフォーマンスにかなりの影響が出る場合があります そのため 次のレプリケーション モードを使用して レプリケーションがパフォーマンスに与える負荷の管理方法を決定することができます コール終了時のレプリケーション各 EJB メソッド コールの終了時に ステートフル Session Bean の状態が クラスタ内の同じマルチキャスト アドレスを持つすべてのノードにレプリケートされます あるノードの電源がオフになった場合 状態はレプリケートされています コール終了時のレプリケーションを使用するには orion-ejb-jar.xml ファイル内の <session-deployment> タグの replication 属性を "EndOfCall" に設定します たとえば 次のように設定します <session-deployment replication="endofcall".../> JVM 終了時のレプリケーション JVM 終了時に ステートフル Session Bean の状態が クラスタ内の同じマルチキャスト アドレスを持つ 1 つのノードのみにレプリケートされます 状態は 1 回だけレプリケートされるため これはパフォーマンスへの影響が最も小さいオプションです ただし 次の理由で 信頼性はあまり高くありません 電源が予期せずオフになった場合 状態はレプリケートされません JVM 終了時のレプリケーション モードでは 電源がオフになった場合の状態レプリケーションは保証されません Bean の状態は 常に 1 つのノード上にのみ存在します 障害深度は 1 ノードに相当します JVM 終了時のレプリケーションを使用するには orion-ejb-jar.xml ファイル内の <session-deployment> タグの replication 属性を "VMTermination" に設定します たとえば 次のように設定します <session-deployment replication="vmtermination".../> 4-30 Oracle Application Server 10g 高可用性ガイド

123 OracleAS Cluster での OC4J の構成 OC4J インスタンス固有のパラメータの構成 この項では リポジトリを使用して管理される OracleAS Cluster 間でレプリケートされないインスタンス固有のパラメータについて説明します この項の項目は次のとおりです OC4J アイランドおよび OC4J プロセスの構成 ポート番号およびコマンドライン オプションの構成 関連項目 : OC4J の構成およびアプリケーションのデプロイに関する詳細は Oracle Application Server Containers for J2EE ユーザーズ ガイド を参照してください OC4J アイランドおよび OC4J プロセスの構成 冗長な環境を提供し OracleAS Cluster を使用した高可用性をサポートするためには OC4J インスタンスごとに複数の OC4J プロセスを構成する必要があります OracleAS Cluster を使用すると 状態は クラスタ間で同じ名前を持つ OC4J インスタンス内の 同じ名前を持つ OC4J アイランドでレプリケートされます ステートフル アプリケーションで高可用性を確保するには OC4J インスタンス内の OC4J アイランド名を クラスタ間で対応する OC4J インスタンス内での名前と同じものにする必要があります クラスタ内でセッション状態レプリケーションが必要な場合にアイランド名の一致を確認することは 管理者の役割です クラスタ内の OC4J インスタンス上にある OC4J プロセスの数は インスタンス固有のパラメータです これは クラスタ内でアプリケーション サーバー インスタンスを実行しているホストの性能 ( システム メモリーの合計など ) はそれぞれ異なる可能性があるためです したがって クラスタ内の各アプリケーション サーバー インスタンスでは OC4J インスタンス内で実行する OC4J プロセスの数を必要に応じて変えたほうがよい場合があります OC4J アイランドおよび各 OC4J アイランドに含まれるプロセスの数を変更するには 次の手順を実行します 1. クラスタ内の目的のアプリケーション サーバー インスタンスの OC4J ホームページで 管理 リンクを選択します 2. インスタンス プロパティ 領域の サーバー プロパティ を選択します 3. 下にスクロールして 複数仮想マシン構成 セクションを表示します このセクションでは アイランド および各アイランドにおいてこのアプリケーション サーバー インスタンス上で起動する OC4J プロセスの数を定義します 図 4-7 に 複数仮想マシン構成 の アイランド セクションを示します 中間層の高可用性の管理と操作 4-31

124 OracleAS Cluster での OC4J の構成 図 4-7 OC4J インスタンスのアイランドおよびプロセス数の構成 4. クラスタ内のこの OC4J インスタンスに対してアイランドを作成するには 行の追加 をクリックします 各アイランドの名前は アイランド ID フィールドで指定できます 各アイランド内で起動する OC4J プロセスの数は プロセス数 フィールドで指定できます ポート番号およびコマンドライン オプションの構成 図 4-8 に ポートの変更やコマンドライン オプションの設定を実行するためのセクションを示します OC4J のポートやコマンドライン オプションを変更するには 次の手順を実行します 1. クラスタ内の目的のアプリケーション サーバー インスタンスの OC4J ホームページで 管理 リンクを選択します 2. インスタンス プロパティ 領域の サーバー プロパティ を選択します 3. 下にスクロールして 複数仮想マシン構成 セクションを表示します このセクションでは OC4J および OC4J プロセスを実行する JVM の ポートとコマンドライン オプションを定義します 図 4-8 に サーバー プロパティ ページの ポート および コマンドライン オプション 領域を示します 4-32 Oracle Application Server 10g 高可用性ガイド

125 OracleAS Cluster での Oracle HTTP Server の構成 図 4-8 OC4J のポートおよびコマンド ライン オプションの構成 OracleAS Cluster での Oracle HTTP Server の構成 この項では リポジトリを使用して管理される OracleAS Cluster 用の Oracle HTTP Server の構成について説明します この項の項目は次のとおりです OracleAS Cluster を使用した mod_oc4j ロード バランシング Oracle HTTP Server インスタンス固有のパラメータの構成 OracleAS Cluster を使用した mod_oc4j ロード バランシング この項の項目は次のとおりです ロード バランシングの概要 ロード バランシング オプションの設定 中間層の高可用性の管理と操作 4-33

126 OracleAS Cluster での Oracle HTTP Server の構成 ロード バランシングの概要 OracleAS Cluster を使用すると Oracle HTTP Server のモジュール mod_oc4j で OC4J プロセスに対するリクエストのロード バランシングが行われます Oracle HTTP Server では mod_oc4j 構成オプションを使用して 様々なロード バランシング ポリシーがサポートされています 構成可能なロード バランシング ポリシーを提供することにより OracleAS Cluster では ネットワーク トポロジやホスト マシンの性能に応じて 様々なタイプのシステムに対して パフォーマンス上のメリットだけでなく フェイルオーバーや高可用性を提供することができます デフォルトでは mod_oc4j は 重みを使用してリクエストの転送先ノードを選択します 特に指定しないかぎり 各ノードにはデフォルトの重み 1 が設定されます ノードの重みは 使用可能な他のノードの重みに対する比率として扱われ これによって クラスタ内の他のノードと比較してそのノードが処理すべきリクエストの数が定義されます 特定のリクエストを処理するノードが選択されると mod_oc4j は デフォルトで roundrobin ポリシーを使用してノード上の OC4J プロセスを選択します 受信リクエストが確立済のセッションに属する場合 そのリクエストは そのセッションを開始した同じノードおよび同じ OC4J プロセスに転送されます OC4J ロード バランシング ポリシーでは リクエストの送信先ノードを計算する際に ノード上で実行されている OC4J プロセスの数は考慮されません ノードの選択は ノードに対して構成済の重みと その可用性に基づいて行われます 実行する OC4J プロセスの数は Application Server Control を使用して構成されます 関連項目 : OC4J インスタンス固有のパラメータの構成 (4-31 ページ ) ロード バランシング オプションの設定 mod_oc4j ロード バランシング ポリシーを変更する際 管理者は mod_oc4j.conf ファイル内の Oc4jSelectMethod および Oc4jRoutingWeight 構成ディレクティブを使用します mod_oc4j.conf ファイルを構成するには Application Server Control を使用して 任意のアプリケーション サーバー インスタンスの HTTP_Server コンポーネントを選択します 次に 管理 リンクを選択し 拡張サーバー プロパティ リンクを選択します 拡張サーバー プロパティ ページで mod_oc4j.conf リンクを選択します mod_ oc4j.conf の編集 ページの <IfModule mod_oc4j.c> セクションで Oc4jSelectMethod および Oc4jRoutingWeight を変更して 必要なロード バランシング オプションを選択します Application Server Control を使用しない場合は 次のように mod_oc4j.conf を編集し dcmctl コマンドを使用して OracleAS Cluster 間で他の mod_oc4j.conf ファイルに変更を伝播します % dcmctl updateconfig -ct ohs % restartproc ias-component=http_server process-type=http_server 4-34 Oracle Application Server 10g 高可用性ガイド

127 OracleAS Cluster での Oracle HTTP Server の構成 opmnctl restartproc コマンドは OracleAS Cluster 内のすべての Oracle HTTP Server インスタンスを再起動して変更を有効にするために必要です Oracle HTTP Server インスタンス固有のパラメータの構成 次のものは Oracle HTTP Server によって使用されるインスタンス固有のパラメータです ApacheVirtualHost Listen OpmnHostPort Port User Group 関連項目 : NameVirtualHost ServerName PerlBlob OC4J インスタンス固有のパラメータの構成 (4-31 ページ ) Oracle HTTP Server 管理者ガイド (mod_oc4j ロード バランシング ディレクティブの使用について ) Oracle Application Server 10g パフォーマンス ガイド HTTP Server のポートおよびリスニング アドレスは HTTP Server ホームページからアクセスできる サーバー プロパティ ページで変更できます 仮想ホスト情報は HTTP Server ホームページの 仮想ホスト セクションで仮想ホストを選択することによって変更できます 中間層の高可用性の管理と操作 4-35

128 セキュリティ : Single Sign-On の構成 セキュリティ : Single Sign-On の構成 Oracle Application Server Single Sign-On を OracleAS Cluster と連携させるには Single Sign-On Server に クラスタへのエントリ ポイントを認識させる必要があります これは通常 Oracle HTTP Server の前面に配置されるロード バランシング メカニズムです このメカニズムは Oracle Application Server Web Cache ネットワーク ロード バランサ機器 Oracle HTTP Server インストールのいずれかになります OracleAS Cluster のエントリ ポイントを Single Sign-On Server に登録するには SSORegistrar ツールを使用します このツールは ossoreg.jar を使用して実行できます クラスタ内のすべての Oracle HTTP Server インスタンスが Single Sign-On の機能を利用できるようにするには それらのインスタンスがいずれも同じ Single Sign-On に登録されていることが必要です 各 Oracle HTTP Server は 同じ Single Sign-On Server に登録されます 各 Oracle HTTP Server は 成功 ログアウト 取消またはホームのメッセージをパブリックのネットワーク ロード バランサにリダイレクトします クラスタ環境では 各 Oracle HTTP Server がメッセージ URL をネットワーク ロード バランサにリダイレクトする必要があります クライアントは Oracle HTTP Server に直接アクセスできないため ネットワーク ロード バランサと対話します すべてのクラスタレベルの構成情報と同様に Single Sign-On の構成は クラスタ内のすべての Oracle HTTP Server インスタンスに伝播されます ただし 最初の構成については 構成および伝播を手動で行います 任意のアプリケーション サーバー インスタンスで ossoreg.jar ツールを使用して構成を定義します すると DCM によって その構成がクラスタ内にある他のすべての Oracle HTTP Server に伝播されます ネットワーク ロード バランサを使用しない場合は 受信ロード バランサとして使用可能なもの (Oracle Application Server Web Cache や Oracle HTTP Server など ) で Single Sign-On の構成を行う必要があります Single Sign-On 用にクラスタを構成するには クラスタ内のアプリケーション サーバー インスタンスのいずれか 1 つに対して ossoreg.jar コマンドを実行します このツールにより Single Sign-On Server およびリダイレクト URL が クラスタ内のすべての Oracle HTTP Server に登録されます 4-36 Oracle Application Server 10g 高可用性ガイド

129 セキュリティ : Single Sign-On の構成 ossoreg.jar コマンドは 次に示すようにすべてのオプションを指定して実行します ただし パラメータ値のイタリック体で表記された部分は 該当する情報に置き換えてください 値については 表 4-5 で詳細に説明します Single Sign-On Server で使用するデータベースのホスト ポートおよび SID を指定します mod_osso_url パラメータに フロントエンド ロード バランサのホストおよびポートを指定します このパラメータには OracleAS Single Sign-On で保護されるリソースへの SSL アクセスに関するサイトのセキュリティ ポリシーに応じて HTTP または HTTPS の URL を指定してください -u オプションに このツールを実行するホストのルート ユーザーを指定します $ORACLE_HOME/jdk/bin/java -jar $ORACLE_HOME/sso/lib/ossoreg.jar -oracle_home_path <orcl_home_path> -site_name <site_name> -config_mod_osso TRUE -mod_osso_url <URL> -u <userid> [-virtualhost <virtual_host_name>] [-update_mode CREATE DELETE MODIFY] [-config_file <config_file_path>] [-admin_info <admin_info>] [-admin_id <adminid>] 表 4-5 SSORegistrar のパラメータ値 パラメータ oracle_home_path <orcl_home_path> site_name <site_name> config_mod_osso TRUE mod_osso_url <URL> 値 アプリケーション サーバー インスタンスの Oracle ホームの絶対パス このパスを介して このツールが起動されます サイトの名前 通常は パートナ アプリケーションの有効なホスト名およびポートです (application.mydomain.com など ) TRUE に設定すると 登録されるアプリケーションが mod_osso であることを示します osso.conf を生成するには config_ mod_osso を含める必要があります パートナ アプリケーションの有効な URL これは パートナ アプリケーションへのアクセスに使用する URL です この値は次のような URL 形式で指定します 中間層の高可用性の管理と操作 4-37

130 セキュリティ : Single Sign-On の構成 表 4-5 SSORegistrar のパラメータ値 ( 続き ) パラメータ u <userid> virtualhost <virtual_ host_name> update_mode CREATE DELETE MODIFY config_file <config_ file_path> admin_id <name> admin_info <text> 値 Oracle HTTP Server を起動するユーザー名 UNIX では 通常は root です Windows NT/2000 では SYSTEM です パラメータ u は必須です ( オプション ) このパラメータは Oracle HTTP 仮想ホストを OracleAS Single Sign-On Server に登録する場合にのみ使用します 仮想ホストを作成する場合は 必ず httpd.conf ファイル内で 保護されている URL ごとに次のディレクティブを指定してください <VirtualHost host_name> OssoConfigFile $ORACLE_ HOME/Apache/Apache/conf/osso/host_name/osso.conf OssoIpCheck off #<Location /your_protected_url> # AuthType basic # Require valid-user #</Location> #Other configuration information for the virtual host </VirtualHost> コメント化されている行は アプリケーションをデプロイする前に非コメント化する必要があります ( オプション ) パートナ登録レコードを作成 削除または変更します CREATE( デフォルト ) を指定すると 新規のレコードが生成されます DELETE を指定すると 既存のレコードが削除されます MODIFY を指定すると 既存のレコードが削除され 新規のレコードが作成されます ( オプション ) 仮想ホストの osso.conf ファイルの場所 ( 仮想ホストを構成する場合 ) たとえば $ORACLE_ HOME/Apache/Apache/conf/osso/virtual_host_ name/osso.conf です 非仮想ホストの osso.conf は $ORACLE_ HOME/Apache/Apache/conf/osso にあります ( オプション )mod_osso 管理者のユーザー名 これは Single Sign-On ツールに連絡先情報として表示されます ( オプション ) 電子メール アドレスなど mod_osso 管理者に関する追加情報 これは Single Sign-On ツールに連絡先情報として表示されます 4-38 Oracle Application Server 10g 高可用性ガイド

131 高度なクラスタリング構成 SSORegistrar ツールを使用すると クラスタ内の Oracle HTTP Server と Single Sign-On Server 間のセキュアな通信を容易にするために必要なあらゆる情報が設定されます Single Sign-On をクラスタ内の Oracle HTTP Server とともに使用する場合 KeepAlive ディレクティブを OFF に設定する必要があります これは Oracle HTTP Server がネットワーク ロード バランサの背後にあるためです KeepAlive ディレクティブを ON に設定すると ネットワーク ロード バランサは同じ接続の Oracle HTTP Server を使用して状態を維持します その結果 HTTP 503 エラーが発生します KeepAlive ディレクティブの変更は Oracle HTTP Server の構成で行います このディレクティブは Oracle HTTP Server の httpd.conf ファイル内にあります 高度なクラスタリング構成 関連項目 : Oracle Application Server Single Sign-On 管理者ガイド クラスタリングの特定の限定された長所のみを提供するように OracleAS インスタンスのクラスタを構成することができます この項では このような高度なクラスタの構成方法について説明します 同じファーム内のインスタンス間のルーティング ファイアウォールを越えたインスタンス間のルーティング 同じファーム内のインスタンス間のルーティング ファーム内に複数の OracleAS インスタンスがある場合 Oracle HTTP Server の 1 つを全インスタンスのロード バランサとして構成できます これにより OracleAS インスタンス内に必要な Oracle HTTP Server は 1 つだけになります 1 つの Oracle HTTP Server をロード バランサとして構成する場合 ファーム内のすべての OC4J インスタンスを認識し 受信リクエストを適切にルーティングするように Oracle HTTP Server を構成する必要があります 構成の手順は次のとおりです 1. ファーム内のすべてのインスタンスについて OracleAS インスタンス名およびそのコンポーネントを検索します a. ファーム内の各 OracleAS インスタンスの DCM ディレクトリに移動します cd ORACLE_HOME_Instance/dcm/bin a. OracleAS インスタンス名を検索して その全コンポーネントのリストを表示します dcmctl whichinstance dcmctl listcomponents 中間層の高可用性の管理と操作 4-39

132 高度なクラスタリング構成 2. mod_oc4j.conf 構成ファイルを 各ルート コンテキストの OC4J インスタンス情報を使用して更新します これにより デプロイ済の各アプリケーションに mod_oc4j をルーティングできます a. クラスタ内の各 OracleAS インスタンスの Apache ディレクトリに移動します cd ORACLE_HOME_Instance/Apache/Apache/conf b. mod_oc4j.conf を編集して クラスタ内の他の OC4J インスタンスにあるデプロイ済アプリケーションのルート コンテキスト用のマウント ポイントを含めます 各 mod_oc4j 構成ファイルには 受信リクエストのルーティング先であるデプロイ済アプリケーションのルート コンテキストごとに 対応するマウント ポイントが含まれます 別のインスタンスにデプロイされているアプリケーションにルーティングするには instance:// という追加のキーワードを使用して 該当するインスタンスのアプリケーション ルート コンテキストに対応するマウント ポイントを追加する必要があります このキーワードの構文には OracleAS インスタンス名と OC4J インスタンス名が必要です 注意 : クラスタ内の各 mod_oc4j 構成ファイルのエントリが複数になることを避けるために クラスタリングされたアプリケーションはすべて同じルート コンテキストにマウントすることをお薦めします 別のクラスタにデプロイされているアプリケーションにルーティングするには cluster:// という追加のキーワードを使用して アプリケーション ルート コンテキストに対応するマウント ポイントを追加する必要があります このキーワードの構文には クラスタ名と OC4J インスタンス名が必要です 別のインスタンス 複数のインスタンス 別のクラスタへルーティングする場合の例は それぞれ次のとおりです Oc4jMount /myapp/* instance://inst2:oc4j_home Oc4jMount /myapp1/* instance://inst2:oc4j_home, Inst3:OC4J_Home Oc4jMount /myapp2/* cluster://cluster1:oc4j_home c. 構成の変更を DCM に通知して DCM を再起動します dcmctl updateconfig dcmctl restart クラスタの構成が完了したら OracleAS インスタンスおよび OC4J インスタンスの構成がそれぞれ同じであることを確認する必要があります このタイプのクラスタでは すべてのインスタンス間で構成がレプリケートされることはありません 構成は手動で管理する必要があります 4-40 Oracle Application Server 10g 高可用性ガイド

133 高度なクラスタリング構成 OC4J の状態レプリケーションは 管理されているクラスタリングと同様に Application Server Control を使用して構成できます 関連項目 : OC4J インスタンス固有のパラメータの構成 (4-31 ページ ) ファイアウォールを越えたインスタンス間のルーティング ファイアウォールによって 不正なネットワーク トラフィックを制限し 企業のインフラストラクチャを保護できます ファイアウォールを構成する場合 通常は ファイアウォールの一方の側で使用できるポートを制限する必要があります また HTTP など 特定のポートを通過できるトラフィックのタイプを制限するように設定することもできます 制限されているポートへの接続や 許可されていないプロトコルの使用を試みたクライアントは ファイアウォールによってただちに切断されます ファイアウォールを企業のイントラネット内で使用して 特定のサーバーへのユーザー アクセスを制限することもできます OracleAS の一部のコンポーネントを別々のノードにデプロイし ファイアウォールで分離することができます 図 4-9 に 2 つのファイアウォール間の OracleAS コンポーネントで推奨される編成の一例を示します 外側のファイアウォールは Oracle HTTP Server が外部から悪用されることを防ぎます 内側のファイアウォールは 最初のファイアウォールが突破された場合に イントラネット内の OC4J プロセスを保護します Oracle HTTP Server と OC4J プロセスの間の 2 番目のファイアウォールの背後の通信は すべて SSL 暗号化を使用して行う必要があります 認可は SSL クライアント証明書を使用して行う必要があります 中間層の高可用性の管理と操作 4-41

134 高度なクラスタリング構成 図 4-9 複数のファイアウォールを介した Oracle HTTP Server と OC4J プロセス間のルーティング ただし Oracle HTTP Server と OC4J プロセス間の通信は この通信用の DCM OPMN および mod_oc4j を使用して 複数のポート経由で行われます この通信は ファイアウォールが間に存在する場合でも続行する必要があります OC4J コンポーネント間の通信に必要な OracleAS コンポーネント ポートをファイアウォールを介して公開することにより 通信を続行することができます この通信に必要なポートをそれぞれ手動でオープンすることもできますが OracleAS Port Tunnel を使用して 1 つのポートをオープンし 通常は複数のポート経由で行われる通信をすべてそのポートで処理することもできます これらのオプションについては 次の各項で説明します OracleAS Port Tunnel を介したイントラネット通信のオープン イントラネットを介して通信するための OracleAS ポートのオープン OracleAS Port Tunnel を介したイントラネット通信のオープン イントラネット ファイアウォール上で複数のポートをオープンするかわりに OracleAS Port Tunnel を使用することができます Port Tunnel は DCM OPMN および mod_oc4j の通信を含む Oracle HTTP Server と OC4J 間の通信を容易にするプロセスです Port Tunnel では イントラネット ファイアウォールで公開される単一のポートが使用されます したがって 単一の OC4J プロセスの通信を行うために複数のポートを公開する必要はありません Port Tunnel では 1 つのポートのみを公開し 複数の OC4J プロセスのポート要件をすべて満たすことができます Oracle HTTP Server と Port Tunnel 間の通信は すべて SSL を使用して暗号化されます 4-42 Oracle Application Server 10g 高可用性ガイド

135 高度なクラスタリング構成 図 4-10 に 3 つの Oracle HTTP Server と 3 つの OC4J プロセスが Port Tunnel を介して通信する方法を示します イントラネット ファイアウォール上で公開されているポートは 1 つだけです Oracle HTTP Server はすべて 1 つのマシン上に存在し Port Tunnel と OC4J プロセスはそれぞれ別々のマシンに存在します 図 4-10 OracleAS Port Tunnel ただし Oracle HTTP Server と OC4J プロセス間の通信を管理しているプロセスが 1 つだけの場合は 高可用性やフェイルオーバーは保証できません それぞれ独自のポートでリスニングする複数の Port Tunnel プロセスを追加して 可用性やフェイルオーバーを管理できます マシンごとに Port Tunnel プロセスを 2 つずつ使用することをお薦めします セキュリティのためにはイントラネットで公開するポート数は最小限にすることが望ましいものの フェイルオーバーや可用性も提供する必要があります Port Tunnel プロセスの構成と初期化が完了すると Oracle HTTP Server では OC4J プロセスの場合と同様に Port Tunnel プロセス間のロード バランシングが自動的に行われます 中間層の高可用性の管理と操作 4-43

136 高度なクラスタリング構成 Port Tunnel プロセスごとにポートを 1 つ公開するというリスクはあるものの Port Tunnel を使用して公開されるポートの数は Oracle HTTP Server と OC4J プロセス間での直接通信のために必要なポートをすべて公開する場合に比べれば大幅に少なくなります 詳細は 4-44 ページの イントラネットを介して通信するための OracleAS ポートのオープン を参照してください Port Tunnel プロセスの構成および初期化の詳細は Oracle Application Server 10g セキュリティ ガイド の HTTP セキュリティに関する章を参照してください イントラネットを介して通信するための OracleAS ポートのオープン OC4J コンポーネント間の通信に必要な各 OracleAS コンポーネント ポートをファイアウォールを介して公開することにより イントラネット ファイアウォールの両側にある Oracle HTTP Server と OC4J プロセス間でルーティングを行うことができます ファイアウォール上でオープンするポートは 使用するサービスによって異なります 表 4-6 に オープンする必要のあるポートをサービス別に示します 表 4-6 各サービスで使用するポート サービス名 Oracle HTTP Server OPMN DCM 説明 受信リクエストでは 常に HTTP または HTTPS が使用されます OPMN は HTTP ポートを使用して OracleAS Cluster 内の他の OPMN プロセス間の通信を行います OPMN 通信は双方向であるため すべての OPMN プロセスのポートを 相互に また OC4J プロセスに対してオープンする必要があります DCM は JDBC を使用して バックエンドの Oracle ベースのリポジトリと対話します データベースへのポートをオープンすることが望ましくない場合は データベース リポジトリではなくファイルベースのリポジトリを使用できます ファイルベースのリポジトリの設定方法は 4-39 ページの 同じファーム内のインスタンス間のルーティング を参照してください DCM は Oracle Internet Directory からの情報を使用して LDAP ポート経由でブートストラップされます 構成 XML ファイル httpd.conf 構成ファイル内の listen ディレクティブに一覧表示されるポート ons.conf 構成ファイル 手動による編集で または Application Server Control の GUI を使用して変更されます これらのポート番号は dcmctl getopmnport を実行して確認することもできます JDBC のデフォルトのポート番号は 1521 です JDBC データベースのポート番号は Net8 データベース構成の listener.ora ファイルで定義します デフォルトのポートは LDAP の場合は 389 SSL 経由の LDAP の場合は 636 です デフォルトのポートが他で使用済の場合は 4031 ~ 4040 の範囲内で次に使用可能なポートが選択されます ポート番号は ORACLE_ HOME/config/ias.properties ファイルで変更できます 4-44 Oracle Application Server 10g 高可用性ガイド

137 高度なクラスタリング構成 表 4-6 各サービスで使用するポート ( 続き ) サービス名 mod_oc4j モジュール RMI または JMS 説明 AJP ポート経由で各 OC4J プロセスと通信します ポート範囲のデフォルトは 3001 ~ 3100 です RMI または JMS は OC4J との通信に使用できます RMI ポートのポート範囲のデフォルトは 3101 ~ 3200 です JMS ポートのポート範囲のデフォルトは 3201 ~ 3300 です 構成 XML ファイル opmn.xml ファイル内の <port> 要素で具体的に または範囲として定義されます 使用される OC4J プロセスの数に対して必要なポートの数を正確に指定することをお薦めします opmn.xml ファイル内の <port> 要素で具体的に または範囲として定義されます 使用される OC4J プロセスの数に対して必要なポートの数を正確に指定することをお薦めします Infrastructure Portal Infrastructure データベースは ポート 1521 のみで実行されます OC4J プロセス用に構成されるものと同じ AJP ポート範囲を使用します N/A opmn.xml ファイル内の <port> 要素で具体的に または範囲として定義されます インストール時に Oracle Installer によって使用可能なポートが選択され 該当するプロセスに割り当てられます Application Server Control を使用して デフォルトのホームページで ポート を選択すると すべてのコンポーネントに割り当てられているポートを確認できます 注意 : 一部のポート番号では 依存関係が複数あります ポート番号を変更する場合 他のコンポーネントでも変更が必要な場合があります ポート番号の管理方法に関する詳細は Oracle Application Server 10g 管理者ガイド の ポートの管理 の章を参照してください 使用中のすべてのポートを Application Server Control を使用して表示することができます OracleAS ホーム インスタンスで ページの左上にある ポート を選択します 図 4-11 では Oracle HTTP Server および OC4J のすべてのインスタンスを含めて この OracleAS インスタンスで使用されているすべてのポートが表示されています ポート管理の詳細は Oracle Application Server 10g 管理者ガイド の ポートの管理 の章を参照してください 中間層の高可用性の管理と操作 4-45

138 高度なクラスタリング構成 図 4-11 OracleAS で使用されているポート OracleAS 4-46 Oracle Application Server 10g 高可用性ガイド

139 5 Infrastructure の高可用性の管理 この章では Infrastructure の高可用性環境を管理する方法について説明します 停止 起動 スケジュールされた停止および計画外の停止からのリカバリなどの操作手順を説明します ここでは 次の 2 つの高可用性ソリューションを取り上げます Oracle Application Server Cold Failover Cluster Oracle Application Server Active Failover Cluster(UNIX) 注意 : 高可用性を実現するためのインストールの詳細は Oracle Application Server 10g のインストレーション ガイドを参照してください Infrastructure の高可用性の管理 5-1

140 Oracle Application Server Cold Failover Cluster Oracle Application Server Cold Failover Cluster この項では OracleAS Cold Failover Cluster で OracleAS Infrastructure を起動および停止する手順を詳細に説明します 起動 OracleAS Cold Failover Cluster で Infrastructure を起動するには 次の手順を使用します 1. ORACLE_HOME 環境変数に Infrastructure の Oracle ホームを設定します 2. ORACLE_SID 環境変数にメタデータ リポジトリのシステム識別子を設定します 3. PATH 環境変数を Infrastructure の $ORACLE_HOME/bin ディレクトリを含むように設定します 重要 : Oracle ホームが複数インストールされているマシンでは 稼動している Oracle ホームのパスを PATH 環境変数の最初のエントリとして指定します また 使用する実行可能ファイルの完全なパスを確実に指定してください 4. 必要に応じて ボリューム管理ソフトウェアを有効にし ファイル システムをマウントします 5. 仮想 IP アドレスを有効にします 6. メタデータ リポジトリ リスナーを起動します $ORACLE_HOME/bin/lsnrctl start 7. メタデータ リポジトリを起動します 8. OracleAS インスタンスごとに OPMN および OPMN で管理されているすべてのプロ セスをローカルに起動します OPMN デーモンが実行されていない場合は OPMN デーモンと OPMN で管理されているプロセスの両方を起動します $ORACLE_HOME/opmn/bin/opmnctl startall OPMN デーモンが実行されている場合は OPMN で管理されているすべてのプロセスを一括して起動します $ORACLE_HOME/opmn/bin/opmnctl startproc 5-2 Oracle Application Server 10g 高可用性ガイド

141 Oracle Application Server Cold Failover Cluster または 次の手順で OPMN で管理されているプロセスを個々に起動します a. Oracle HTTP Server を起動します $ORACLE_HOME/opmn/bin/opmnctl startproc ias-component=http_server b. Oracle Internet Directory を起動します $ORACLE_HOME/opmn/bin/opmnctl startproc ias-component=oid c. Delegated Administration Services インスタンスを起動します $ORACLE_HOME/opmn/bin/opmnctl startproc ias-component=oc4j instancename=oc4j_security d. 次のコマンドを使用して OPMN で管理されているプロセスの状態をチェックします $ORACLE_HOME/opmn/bin/opmnctl status 9. Application Server Control を起動します 次のいずれかのコマンドを使用します $ORACLE_HOME/bin/emctl start iasconsole または $ORACLE_HOME/bin/emctl startifdown iasconsole 停止 OracleAS Cold Failover Cluster で OracleAS Infrastructure を停止するには 次の手順を使用します 1. ORACLE_HOME 環境変数に Infrastructure の Oracle ホームを設定します 2. ORACLE_SID 環境変数にメタデータ リポジトリのシステム識別子を設定します 3. OracleAS インスタンスごとに OPMN および OPMN で管理されているすべてのプロセスをローカルに停止します OPMN デーモンおよび OPMN で管理されているすべてのプロセスを停止するには 次の手順を実行します $ORACLE_HOME/opmn/bin/opmnctl stopall OPMN で管理されているすべてのプロセスを停止し OPMN デーモンは実行したままにするには 次のコマンドを実行します $ORACLE_HOME/opmn/bin/opmnctl stopproc Infrastructure の高可用性の管理 5-3

142 Oracle Application Server Active Failover Cluster(UNIX) または 次の手順で OPMN で管理されているプロセスを個々に停止します a. Delegated Administration Services インスタンスを停止します $ORACLE_HOME/opmn/bin/opmnctl stopproc ias-component=oc4j instancename=oc4j_security b. Oracle Internet Directory を停止します $ORACLE_HOME/opmn/bin/opmnctl stopproc ias-component=oid c. Oracle HTTP Server を停止します $ORACLE_HOME/opmn/bin/opmnctl stopproc ias-component=http_server 4. メタデータ リポジトリを停止します 5. メタデータ リポジトリ リスナーを停止します $ORACLE_HOME/bin/lsnrctl stop 6. Application Server Control を停止します $ORACLE_HOME/bin/emctl stop iasconsole 7. 必要に応じて ボリューム管理ソフトウェアを無効にし ファイル システムをアンマウントします 8. 仮想 IP アドレスを無効にします Oracle Application Server Active Failover Cluster(UNIX) この項では OracleAS Active Failover Cluster の高可用性ソリューションで Infrastructure を起動および停止する手順を詳細に説明します 起動 OracleAS Active Failover Cluster が有効な Infrastructure では クラスタ内の各ノードは機能的に他のノードと等価です すべてのノードが共通のリポジトリにアクセスします データベース インスタンスと個々の OracleAS プロセスは クラスタのノードごとに起動する必要があります 常に アクティブなノードにのみトラフィックを送るようにロード バランサを構成する必要があります すべてのノード上で Infrastructure インスタンスを起動する順序は次のとおりです 1. 各ノード上で グローバル サービス デーモンを起動します $ORACLE_HOME/bin/gsd 5-4 Oracle Application Server 10g 高可用性ガイド

143 Oracle Application Server Active Failover Cluster(UNIX) 2. 次のコマンドを使用して すべてのノード上でデータベース インスタンスおよびリスナーを起動します ( このコマンドは クラスタ内のどのノードからでも実行可能です ) $ORACLE_HOME/bin/srvctl start -p <database_name> 各ノードのグローバル サービス デーモンによって 各ノードのローカル データベース プロセスが起動していることを確認できます 3. OPMN および OPMN で管理されているすべてのプロセスを起動します OPMN デーモンが実行されていない場合は OPMN デーモンと OPMN で管理されているプロセスの両方を起動します ( 次のコマンドを実行する必要があるのは 1 回だけです ) startall 注意 : OracleAS Active Failover Cluster ノードをより効率的に起動するために ノードが起動するたびに OPMN デーモンを起動するように各ノードのオペレーティング システムを構成することができます この作業の実行手順は オペレーティング システムによって異なります たとえば UNIX では システム管理者が rc スクリプトを構成することで この目的を達成できます OPMN デーモンが実行されている場合は OPMN で管理されているすべてのプロセスをすべてのノード上で起動できます ( 次のコマンドを実行する必要があるのは 1 回だけです ) startproc たとえば クラスタ内にノードが 2 つある場合 次のコマンドを実行します startproc または 次の手順で OPMN で管理されているプロセスをすべてのノード上で個々に起動します ( 次のコマンドを実行する必要があるのは 1 回だけです ) a. Oracle HTTP Server を起動します startproc ias-component=http_server Infrastructure の高可用性の管理 5-5

144 Oracle Application Server Active Failover Cluster(UNIX) b. Oracle Internet Directory を起動します startproc ias-component=oid c. Delegated Administration Services インスタンスを起動します startproc ias-component=oc4j instancename=oc4j_security 4. ロード バランサを構成して 現行ノードへのトラフィックを有効にします 5. 次のコマンドを使用して OPMN で管理されているプロセスの状態をすべてのノード 上でチェックします status 6. Application Server Control を起動します クラスタ内の各ノード上で 次のいずれかのコマンドを実行します $ORACLE_HOME/bin/emctl start iasconsole または $ORACLE_HOME/bin/emctl startifdown iasconsole 停止 OracleAS Active Failover Cluster が有効な Infrastructure では 他の Infrastructure インスタンスを使用可能な状態に維持しながら個々の Infrastructure インスタンスを停止できるため より高い可用性を実現できます インスタンスを停止する順序は次のとおりです 1. ロード バランサを構成して 現行ノードへのトラフィックを無効にします 2. OPMN および OPMN で管理されているプロセスをすべて停止します OPMN で管理されているすべてのプロセスを停止し OPMN デーモンは実行したままにするには 次のコマンドを 1 回実行します stopproc OPMN で管理されているプロセスをすべてのクラスタ ノード上で個々に停止するには 次のコマンドを 1 回実行します 5-6 Oracle Application Server 10g 高可用性ガイド

145 Oracle Application Server Active Failover Cluster(UNIX) a. Delegated Administration Services インスタンスを停止します stopproc ias-component=oc4j instancename=oc4j_security b. Oracle Internet Directory を停止します stopproc ias-component=oid c. Oracle HTTP Server を停止します stopproc ias-component=http_server 3. 次のコマンドを使用して すべてのノード上でデータベース インスタンスおよびリスナーを停止します ( このコマンドは クラスタ内のどのノードからでも実行可能です ) $ORACLE_HOME/bin/srvctl stop -p <database_name> 各ノードのグローバル サービス デーモンによって 各ノードのローカル データベース プロセスが停止していることを確認できます 4. Application Server Control を停止します クラスタ内のノード上で 次のコマンドを実行します $ORACLE_HOME/bin/emctl stop iasconsole 監視 OracleAS Active Failover Cluster が有効な Infrastructure の監視は 通常の Infrastructure の監視と同様です 特に注意が必要な点は ロード バランサを監視して トラフィックがアクティブなノードに送られていることを確認することだけです ロード バランサの可用性および構成の健全性を監視する方法については ロード バランサのベンダーに問い合せてください 停止中のフェイルオーバー OracleAS Active Failover Cluster が有効な Infrastructure は スケジュールされた停止および計画外の停止が発生しても 引き続き使用可能です 次の表 5-1 に このソリューションで自動的に処理される停止を示します Infrastructure の高可用性の管理 5-7

146 Oracle Application Server Active Failover Cluster(UNIX) 表 5-1 OracleAS Active Failover Cluster ソリューションで自動的に処理される停止 停止のタイプ スケジュールされた停止 計画外の停止 停止 ノード ハードウェアおよびオペレーティング システムのメンテナンスデータベース インスタンスのメンテナンス Infrastructure ソフトウェアのメンテナンスフォルト トレラントなロード バランサのメンテナンス ノードの障害データベース インスタンスの障害 Infrastructure プロセスの障害フォルト トレラントなロード バランサの部分的な障害 表 5-2 に示す停止が発生すると 短い停止時間が発生する場合があります 障害時リカバリ サイトを用意しておくと この停止時間を短縮することはできますが 完全になくすことはできません 本番サイトが停止している間 スタンバイ サイトをアクティブ化することもできます 詳細は 6-3 ページの Oracle Application Server 10g Disaster Recovery ソリューション を参照してください 表 5-2 OracleAS Active Failover Cluster ソリューションで自動的に処理されない停止 停止のタイプ スケジュールされた停止 計画外の停止 停止 クラスタのメンテナンスデータベースのメンテナンス クラスタの障害データ エラーユーザー エラーフォルト トレラントなロード バランサの全面的な障害 このような停止が発生した場合 システムの動作は次のようになります ノードに障害が発生した場合 ノード内のすべてのプロセスが使用できなくなります 障害が発生したノード上のデータベース インスタンスに接続されている他のノードからの中間層および Infrastructure のプロセスでは データベース セッションが失われます 5-8 Oracle Application Server 10g 高可用性ガイド

147 Oracle Application Server Active Failover Cluster(UNIX) 別のノード上の残りのインスタンスにより インスタンス リカバリが開始されます 障害が発生したインスタンスに送られたリクエストでは サービスが短時間中断されます 切断された場合 正常に接続されるまで接続を再試行できます リカバリを実行しているアクティブなインスタンスに接続しているプロセスでは サービスが中断されません これらのプロセスでは 遅延が発生する場合があります リクエストの処理に使用できる唯一のノードに障害が発生した場合 接続の再試行は 少なくとも 1 つのインスタンスが使用可能になって初めて成功します データベース インスタンスに障害が発生した場合は 次の処理を行う必要があります ロード バランサに障害を通知します すると 障害が発生したインスタンスのあるノードに Oracle Net 以外のトラフィックが送られなくなります 障害が発生したインスタンスのあるノード上の非データベース プロセスはすべて停止します これには Oracle HTTP Server OPMN Application Server Control Oracle Internet Directory などのプロセスが含まれます 障害が発生したインスタンスに接続されている他のノードからの中間層および Infrastructure のプロセスでは データベース セッションが失われます 別のノード上の残りのインスタンスにより インスタンス リカバリが開始されます 障害が発生したインスタンスに送られた中間層リクエストでは サービスが短時間中断されます 切断された場合 正常に接続されるまで接続を再試行できます リカバリを実行しているアクティブなインスタンスに接続しているプロセスでは サービスが中断されません 新規の中間層リクエストはすべて 残りのインスタンスに送られます 停止後のリジリエンスの回復 停止後にリジリエンスを回復するには Oracle Application Server 10g インスタンスを現行のアクティブな Oracle Application Server 10g インスタンス セットに追加する必要があります 主な手順は次のとおりです 1. 停止の原因となった問題を修正します 2. ノード上で Oracle データベース インスタンスを起動します 3. ノード上で Oracle Application Server 10g Infrastructure プロセスを起動します Infrastructure の起動および停止方法は Oracle Application Server 10g 管理者ガイド を参照してください 4. 現在起動されているノードにトラフィックを送るように ロード バランサを構成します Infrastructure の高可用性の管理 5-9

148 Oracle Application Server Active Failover Cluster(UNIX) Oracle Application Server Active Failover Cluster Runtime Control Utility(afcctl) を使用した構成ファイルの同期化 OracleAS Active Failover Cluster の各ノードのファイル システムには Infrastructure の一部であるものの OracleAS Metadata Repository に格納されていない構成ファイルがあります これらのファイルは 各ノード上で次のような管理操作を実行すると変更される可能性があります これらの構成ファイルへの手動による変更 これらの構成ファイルへの Application Server Control ベースの変更 Infrastructure への中間層インスタンスの関連付け OracleAS Active Failover Cluster の配置の主な要件は クラスタ内のすべてのノードを同じように構成することです 構成ファイルは 同一ではないとしても 類似している必要があります OracleAS Active Failover Cluster の全ノード間で Infrastructure の整合性を維持するために これらの構成ファイルをノード間で同期化するためのコマンドライン ユーティリティが提供されています このユーティリティは Oracle Application Server Active Failover Cluster Runtime Control Utility といい コマンド afcctl を使用して起動できます このユーティリティを使用したファイルの同期化は 少なくとも Oracle Application Server に対して管理上の変更が行われるたびに実行してください afcctl のセットアップ この項では afcctl ユーティリティをダウンロードおよびインストールして 初期構成を行う方法について説明します 全体の手順は次のとおりです afcctl ユーティリティの入手 afcctl ユーティリティのインストール afcctl ユーティリティの入手 afcctl ユーティリティは Oracle Application Server 10g 製品に付属のユーティリティ CD に収録されています このユーティリティが含まれているファイルは <mount-point>/utilities/ha/afcctl.zip(<mount-point> は CD-ROM ドライブのマウント ポイント ) です このファイルは Oracle Application Server 10g Backup and Recovery Tool とともにインストールされます したがって 後者を先にインストールする必要があります このツールのインストール方法は Oracle Application Server 10g 管理者ガイド を参照してください Oracle Application Server 10g Backup and Recovery Tool をノードにインストールしたら そのノード上にディレクトリ <ORACLE_HOME>/afcctl/ を作成し afcctl.zip をこの新しいディレクトリにコピーします OracleAS Active Failover Cluster 内のすべてのノードに対して この作業をそれぞれ実行します 5-10 Oracle Application Server 10g 高可用性ガイド

149 Oracle Application Server Active Failover Cluster(UNIX) 注意 : afcctl.zip を格納するディレクトリは ORACLE_HOME 外の別の場所に作成することもできます この項の手順では afcctl が <ORACLE_ HOME>/afcctl/ にあるものとします afcctl ユーティリティのインストール 1. <ORACLE_HOME>/afcctl/ ディレクトリに移動して afcctl.zip を解凍します 次のファイルが含まれているはずです afcctl afcctl.pl afcctl.jar afcctl_exclude.inp README 2. UNIX では 次のコマンドを実行して実行権限を有効にします > chmod 755 afcctl 3. afcctl ユーティリティを使用するには Oracle Application Server 10g Backup and Recovery Tool を入手してインストールする必要があります 後者のツールがインストールされていること およびこのツールの.inp ファイルに afcctl ユーティリティがアクセスできることを確認してください afcctl の使用 OracleAS Active Failover Cluster 内の任意のノード上で afcctl ユーティリティを実行し 次の作業を実行します デフォルトのベースライン タイムスタンプの設定 OracleAS Active Failover Cluster 内のノード間でのファイルの同期化 前回の同期化以降に変更された ノード上のファイルのリスト 特定の構成ファイルの同期化からの除外 注意 : ORACLE_HOME が設定されていることを確認してから afcctl を実行してください デフォルトのベースライン タイムスタンプの設定 OracleAS および afcctl のインストール直後に OracleAS Active Failover Cluster 間でデフォルトの構成タイムスタンプを設定する必要があります このベースライン タイムスタンプは インストール後のデフォルト構成をマークします Infrastructure の高可用性の管理 5-11

150 Oracle Application Server Active Failover Cluster(UNIX) このベースラインを設定した後に afcctl を sync オプションで使用して同期化を実行すると ベースライン以降 afcctl sync コマンドを実行するまでの間に変更されている構成ファイルのみが同期化されます タイムスタンプ ベースラインを作成するには 次のコマンドを使用します afcctl createbase -p <dbname> -r <host1>,<host2>,...,<hostn> [-c <cp_exec>] 各プレースホルダの意味は次のとおりです <dbname> は Infrastructure データベースの名前です <host1>,<host2>,..,<hostn> は OracleAS Active Failover Cluster 内のリモート ホストのリスト ( カンマ区切り形式 ) です <cp_exec> は 現行ノードからクラスタ内の他のノードにファイルをコピーする際に使用するリモート コピー ユーティリティのフルパスです デフォルトでは afcctl は /usr/bin/rcp を使用します rcp が見つからない場合は /usr/local/bin/scp を使用します いずれも存在しないか scp が rcp よりも優先して起動されるようしたい場合は -c <cp_exec> オプションを使用して 使用するコピー ユーティリティを指定します 注意 : OracleAS Active Failover Cluster ソフトウェアをインストールした直後に afcctl を createbase オプションで実行することを強くお薦めします OracleAS Active Failover Cluster 内のノード間でのファイルの同期化 createbase オプションを使用して初期構成のベースラインを設定したら sync オプションを使用して 構成変更をクラスタ間で同期化することができます このオプションでは 変更された構成ファイルのみを現行ノードから OracleAS Active Failover Cluster 内のすべてのノードにコピーすることによって 変更された構成を同期化します 同期化を実行するためのコマンドの構文は次のとおりです afcctl sync -p <dbname> -r <host1>,<host2>,...,<hostn> -f <filename> <file_list_dir> [-c <cp_exec>] [-l <hostname>] 各プレースホルダの意味は次のとおりです <dbname> は Infrastructure データベースの名前です <host1>,<host2>,..,<hostn> は OracleAS Active Failover Cluster 内のリモート ホストのリスト ( カンマ区切り形式 ) です <filename> は 同期化されるファイルの名前です <file_list_dir> は.inp ファイルが存在するディレクトリの名前です 5-12 Oracle Application Server 10g 高可用性ガイド

151 Oracle Application Server Active Failover Cluster(UNIX) <cp_exec> は 現行ノードからクラスタ内の他のノードにファイルをコピーする際に使用するリモート コピー ユーティリティのフルパスです デフォルトでは afcctl は /usr/bin/rcp を使用します rcp が見つからない場合は /usr/local/bin/scp を使用します いずれも存在しないか scp が rcp よりも優先して起動されるようしたい場合は -c <cp_exec> オプションを使用して 使用するコピー ユーティリティを指定します <hostname> は Infrastructure インストール時のローカル ホストのホスト名です 前述のコマンドラインを使用するときは 次の点に注意してください -p オプションは gsd プロセスが起動されていて実行中である場合にのみ使用できます また このオプションを使用するには Infrastructure データベースおよびそのインスタンスを srvm リポジトリ ( デフォルトの場合 ) に登録する必要があります -p オプションを指定すると OracleAS Active Failover Cluster の配置のノードが自動的に決定され 必要なファイルが他のノードに伝播されます -r オプションを -p のかわりに使用すると ユーティリティを実行するノードと同期化する必要のあるノードのホスト名を明示的に指定することができます この場合 プロセスの依存関係は 他にはありません 指定したホスト名が OracleAS Active Failover Cluster の配置の有効なノードであることを確認してください -f オプションの <file_list_dir> は Oracle Application Server 10g Backup and Recovery Tool の.inp ファイルが存在するディレクトリです afcctl ユーティリティでは これらのファイルを参照して 同期化が必要な構成ファイルのリストが検索されます -f オプションの <filename> は クラスタ間で同期化が必要なファイルが 1 つだけの場合にのみ使用します afcctl を使用する前に ユーザー等価を設定して 以降リモート ホストを認証せずに rcp および scp コピー ユーティリティを使用できるようにします ユーザー等価は OracleAS Active Failover Cluster インストールにも必要です ユーザー等価の設定方法は Oracle Application Server 10g のインストレーション ガイドの高可用性に関する章を参照してください -l はオプションです このオプションは afcctl を実行するホストを指定するために使用され Infrastructure インストール時のローカル ホスト名がデフォルトのホスト名と異なる場合にのみ指定する必要があります このユーティリティは OracleAS Active Failover Cluster の配置のすべてのノードにインストールすることを強くお薦めします このユーティリティは インストール先のクラスタのどのノードからでも起動できます ただし 1 つのノードを管理ノードとして指定し すべての管理操作およびその後の同期化をそのノードから実行することをお薦めします Infrastructure の高可用性の管理 5-13

152 Oracle Application Server Active Failover Cluster(UNIX) 前回の同期化以降に変更された ノード上のファイルのリスト OracleAS Active Failover Cluster のノード上の構成ファイルのうち 前回の同期化以降に変更されたものを確認するには 次のコマンドライン構文を使用します afcctl list -f <filename> <file_list_dir> 各プレースホルダの意味は次のとおりです <filename> は 前回の同期化以降に更新があったかどうかの確認対象となるファイルの名前です <file_list_dir> は Oracle Application Server 10g Backup and Recovery Tool の.inp ファイルが存在するディレクトリの名前です このディレクトリ内の 前回の同期化以降に変更されたファイルがリストされます 前回の同期化以降に変更されたファイルのリストを含むテキスト ファイルが /tmp ディレクトリに作成されます 5-15 ページの 例 に示す例を参照してください 前述の構文は OracleAS Active Failover Cluster の配置のどのノードでも使用できます 前回の同期化以降に変更されたファイルが実行元のノード上に表示されます 返されるファイルのリストは サイトによって異なる場合があります リスト内のファイルを個々に同期化するには ファイルの最新のバージョンを確認した後に afcctl sync コマンドの -f <filename> オプションを使用します 特定の構成ファイルの同期化からの除外すべてのノードを同様に構成することをお薦めします ただし 異なる内容にすることが必要な構成ファイルもあります 該当するファイルの名前を除外ファイル (afcctl_ exclude.inp) に追加して afcctl を実行してもクラスタ間で同期化されないようにすることができます afcctl_exclude.inp は afcctl.zip の解凍先と同じディレクトリにあります ファイルの除外は 特定のノードに対してのみデバッグをオンにする場合や システムへの影響を測定するために構成ファイルを一時的に変更する場合などに必要になります 除外ファイルにリストしたファイルは同期化されないため これらのファイルを変更する場合は 他のノード上の対応するファイルに変更内容を手動で伝播する必要があります 手動による伝播は 除外ファイルからそれらを削除するまで必要です 永続的に除外する場合を除き 同期化の実行後にファイル名を削除します 注意 : カスタム ファイルを含めて afcctl ユーティリティを実行するたびに OracleAS Active Failover Cluster ノード間で同期化することもできます ファイル config.inp に この作業に関するルールが含まれています 5-14 Oracle Application Server 10g 高可用性ガイド

153 Oracle Application Server Active Failover Cluster(UNIX) 例 Oracle Application Server 10g に対して Application Server Control または DCM を使用して 構成ファイルを変更する可能性のある管理操作を行った後に OracleAS Active Failover Cluster の各ノードで次の手順を実行します 1. ORACLE_HOME 環境変数を設定します たとえば Bourne シェル環境に 次のように入力します $ export ORACLE_HOME=/home/oracle/test1 2. afcctl を list オプションで起動し 現行ノードで変更された構成ファイルを表示します $ afcctl list -f./br_inp_dir Oracle Application Server Active Failover Cluster Run Time Control Utility Copyright (c) 2002, 2003 Oracle Corporation. All rights reserved. Last Sync up time was Mon Sep 8 11:09: Check the following for list of files that have changed since last sync work/files_to_change_and_copy Please look at log/afcctl.log for more information. Exiting... 前回の同期化以降に変更された構成ファイルのリストを含むファイル work/files_ to_change_and_copy が作成されます 3. 作成されたファイルを表示して OracleAS Active Failover Cluster の他のノードに伝播する必要のあるファイルがリストに含まれているかどうかを確認します たとえば 次のようなものです $ cat work/files_to_change_and_copy /home/oracle/test1/apache/apache/conf/ssl.wlt/default/ewallet.p12 /home/oracle/test1/ldap/admin/oidpwdlldap1 /home/oracle/test1/ldap/admin/oidpwdrgit11 Infrastructure の高可用性の管理 5-15

154 Oracle Application Server Active Failover Cluster(UNIX) 4. afcctl を sync オプションで起動して OracleAS Active Failover Cluster 内のあるノードから別のノードにファイルを同期化します $ afcctl sync -r hasun26 -f./backup_scripts Oracle Application Server Active Failover Cluster Run Time Control Utility Copyright (c) 2002, 2003 Oracle Corporation. All rights reserved. Files to massage & copy are listed in work/files_to_change_and_copy Files to copy are listed in work/files_to_copy Do you want to sync up files from hasun25.us.oracle.com to hasun26.us.oracle.com (y/n)? y Syncing up files......! Syncing completed Do you want to update the dcm repository with configuration files from "hasun25.us.oracle.com" (y/n)? y DCM update repository started DCM update repository completed Please look at log/afcctl.log for more information. Exiting... 注意 : オプションを何も指定せずに afcctl を入力すると 使用可能な全オプションのリストが表示されます 5-16 Oracle Application Server 10g 高可用性ガイド

155 Oracle Application Server Active Failover Cluster(UNIX) afcctl の使用のベスト プラクティス 構成ファイルを手動で変更することは できるかぎり避けてください Infrastructure の構成を変更する場合は Application Server Control または自動構成ツール (dcmctl) を使用します 手動で変更する必要がある場合は 任意のノードを管理ノードとして指定し すべての変更をそのノードから行います 次に afcctl ツールをこのノードから実行して OracleAS Active Failover Cluster 内の他のノードに変更を伝播します 構成ファイルを同期化するときは できれば OracleAS Active Failover Cluster のすべてのノードが稼動しているときに 管理上の変更とその後のノード間の同期化を行ってください これが不可能な場合は 停止しているノードが再び稼動した後に そのノードとの同期化を忘れずに行ってください クラスタのすべてのノードで list オプションを定期的に使用して 前回の同期化以降ローカルでは何も変更されていないことを確認します 必要に応じて 変更をノード間で調整します.inp ファイルを Oracle Application Server 10g Backup and Recovery Tool と共有する場合は このツールの除外ファイルやパーソナライズ ファイルになんらかの変更を行うと afcctl ユーティリティにも影響があることを覚えておいてください このツールの詳細は Oracle Application Server 10g 管理者ガイド を参照してください Infrastructure の高可用性の管理 5-17

156 Oracle Application Server Active Failover Cluster(UNIX) 5-18 Oracle Application Server 10g 高可用性ガイド

157 6 Oracle Application Server Disaster Recovery 障害時リカバリとは 自然災害またはそれ以外の災害によるサイトの壊滅的な障害からシステムを回復することを指します これら壊滅的な障害の例として 地震 竜巻 洪水 火事などがあります さらに システムの計画停止の管理方法も障害時リカバリに含まれます 障害時リカバリを必要とするほとんどの状況において 障害の解決には個々のハードウェアやサブコンポーネントのレプリケーションだけでなく サイト全体を対象としたレプリケーションを行う必要があります これは Oracle Application Server Disaster Recovery (OracleAS Disaster Recovery) ソリューションについても同様です この章では OracleAS Disaster Recovery ソリューション その環境の構成およびセットアップ方法 およびソリューションの高可用性の向上を目的とした管理方法について説明します ここでは 本番用およびスタンバイ用の 2 つのサイト内の OracleAS Middle Tier および Infrastructure 層の両方を対象にします スタンバイ サイトは本番サイトと同じように構成されます 通常の運用では 本番サイトがリクエストを積極的に処理します スタンバイ サイトは 本番サイトがホスティングするアプリケーションおよびコンテンツをミラー化するために維持されています これらのサイトは Oracle Application Server Backup and Recovery Tool( ファイル システム上の構成ファイル用 ) および Oracle Data Guard(Infrastructure データベース用 ) により同期化されます 次の表に OracleAS Disaster Recovery の実行計画を要約します 表 6-1 OracleAS Disaster Recovery の実行計画の概要 対象 ツール 目的 中間層構成ファイル Backup and Recovery Tool 本番サイトの中間層ノードにある OracleAS 構成ファイルをバックアップして スタンバイ サイトの中間層ノードで構成ファイルをリストア します Oracle Application Server Disaster Recovery 6-1

158 表 6-1 OracleAS Disaster Recovery の実行計画の概要 ( 続き ) 対象 Infrastructure 構成ファイル Infrastructure データベース ツール Backup and Recovery Tool Oracle Data Guard 目的 本番サイトの Infrastructure ノードにある OracleAS 構成ファイルをバックアップして スタンバイ サイトの Infrastructure ノードで構成ファイルをリストアします 本番サイトの Infrastructure データベースにあるアーカイブ ログをスタンバイ サイトの Infrastructure データベースへ転送します ログはすぐには適用されないことに注意してください これらリカバリの実行計画に加えて 両サイトの構成およびインストールについても説明します これらのタスクでは 中間層ノードをネーミングする 2 つの異なる方法 さらにはサイト間およびサイト内でホスト名を解決する 2 つの方法について説明します OracleAS Disaster Recovery では スタンバイ サイトに切り替えることで サービスを中断することなく本番サイトを計画停止できます 計画外停止は スタンバイ サイトにフェイルオーバーすることで管理されます スイッチオーバーおよびフェイルオーバーの手順についてもこの章で説明します この章は 次の主要な項で構成されています Oracle Application Server 10g Disaster Recovery ソリューション OracleAS Disaster Recovery 環境のセットアップ Oracle Application Server 10g ソフトウェアのインストール ベースライン インストールとスタンバイ サイトの同期化 本番サイトのバックアップ スタンバイ サイトへのリストア スケジューリングした停止 計画外停止 ワイド エリア DNS の操作 関連項目 : OracleAS Disaster Recovery ソリューションのインストール手順は Oracle Application Server 10g のインストレーション ガイドを参照してください 6-2 Oracle Application Server 10g 高可用性ガイド

159 Oracle Application Server 10g Disaster Recovery ソリューション Oracle Application Server 10g Disaster Recovery ソリューション Oracle Application Server Disaster Recovery ソリューションは プライマリ ( 本番 / アクティブ ) とセカンダリ ( スタンバイ ) という 同一の構成を持つ 2 つのサイトからなります 両方のサイトには 同数の中間層ノードと Infrastructure ノードがインストールされ 同数で同種のコンポーネントがインストールされます つまり 両サイトのインストールで中間層および Infrastructure は同じです これらのサイトは通常 地理的に分散されます その場合 Wide Area Network 経由でつながっています この項では ソリューション全体のレイアウト 関連する主要なコンポーネントおよびそれらのコンポーネントの構成について説明します この項の内容は次のとおりです 用語 要件 トポロジ 用語 OracleAS Disaster Recovery ソリューションについて その内容と詳細を説明する前に この章で説明する概念を正しく理解するために この章で使用されるいくつかの用語の定義を明確にしておく必要があります 注意 : 後述の用語定義は 特に OracleAS Disaster Recovery に当てはまります これ以外のコンテキストでは 定義が異なる場合があります 物理ホスト名この章の説明では 物理ホスト名と論理ホスト名という 2 つの用語が異なる意味で使用されます 物理ホスト名は 現行マシンの内部名を表すために使用されます UNIX では コマンド hostname により返される名前です 物理ホスト名は 現行マシンにインストールされている Oracle Application Server 10g コンポーネントにより ローカル ホストを参照する名前として使用されます 物理ホスト名は これらのコンポーネントのインストール時に インストーラにより現行マシンから取得され ディスク上の Oracle Application Server 10g 構成メタデータに格納されます 論理ホスト名論理ホスト名は /etc/hosts ファイル (UNIX の場合 ) C: WINDOWS system32 drivers etc hosts ファイル (Windows の場合 ) または DNS 解決のいずれかで指定される IP アドレスに割り当てられる名前です この名前は ホストが接続しているネットワークで参照可能です 多くの場合 論理ホスト名と物理ホスト名は同じものを指します ただし OracleAS Disaster Recovery ソリューションでは これらを用途に応じて明確に区別する必要があります Oracle Application Server Disaster Recovery 6-3

160 Oracle Application Server 10g Disaster Recovery ソリューション 仮想ホスト名仮想ホスト名は OracleAS インストーラの High Availability Addressing の指定 画面で指定された Infrastructure ホストの名前を表すために使用されます 仮想ホスト名は 中間層コンポーネントおよび Infrastructure コンポーネントが Infrastructure へのアクセスに使用する名前です Infrastructure が単一ノードのインストールであるか または OracleAS Cold Failover Cluster ソリューションの一部であるかどうかは関係ありません この章では 仮想ホスト名が Infrastructure ホストにのみ適用されます 要件 OracleAS Disaster Recovery ソリューションの実装を計画どおり動作させるには 次の要件を順守する必要があります スタンバイ サイトの各ホストでは 次の項目を本番サイトの同等のホストと同じにする必要があります 中間層ホストの場合は 物理ホスト名 Infrastructure の仮想ホスト名 仮想ホスト名は インストーラにより表示される High Availability Addressing の指定 画面で指定できます ハードウェア プラットフォーム オペレーティング システムのリリースとパッチ レベル Oracle Application Server のすべてのインストールで Oracle Application Server 10g のインストレーション ガイドに記載されている要件を順守する必要があります Oracle Application Server ソフトウェアは 本番サイトの各ホストとスタンバイ サイトの同等のホストで 同一のディレクトリ パスにインストールします Oracle Application Server をインストールしたユーザーのユーザー名とパスワードが本番サイトのホストとスタンバイ サイトの同等のホストで 同じである必要があります 特定のノードに Oracle Application Server をインストールしたユーザーのユーザー ID 番号 特定のノードに Oracle Application Server をインストールしたユーザーのグループ名 特定のノードに Oracle Application Server をインストールしたユーザーのグループ ID 番号 環境プロファイル シェル ( コマンドライン環境 ) ノード上にある OracleAS の各インストールの Oracle ホームのディレクトリ構造とパス パス内では シンボリック リンクをいっさい使用しないでください OracleAS インストール タイプ 6-4 Oracle Application Server 10g 高可用性ガイド

161 Oracle Application Server 10g Disaster Recovery ソリューション 中間層 : J2EE and Web Cache Portal and Wireless および Business Intelligence and Forms Infrastructure: Metadata Repository および Identity Management(OracleAS Disaster Recovery ソリューションの両サイトでは Infrastructure インストール タイプを使用して これらをインストールする必要があります ) トポロジ 図 6-1 に OracleAS Disaster Recovery ソリューションのトポロジを示します 図 6-1 Oracle Application Server 10g のサイト間の障害時リカバリ ソリューション ( 中間層ノードが 1 つの場合は ロード バランサ機器はオプション ) Oracle Application Server Disaster Recovery 6-5

162 Oracle Application Server 10g Disaster Recovery ソリューション OracleAS Disaster Recovery ソリューションの構成および運用手順では 本番サイトにおける 任意の数の中間層インストールがサポートされます スタンバイ サイトには 同じ数の中間層インストールを配置する必要があります 本番サイトとスタンバイ サイトでは 中間層を相互にミラー化します Infrastructure の場合は 本番サイトとスタンバイ サイトで同じ数のインストールが必要とされません たとえば 本番サイトには Oracle Application Server Cold Failover Cluster ソリューションを配置し スタンバイ サイトには 1 つのノードに Infrastructure インストールを配置できます このように OracleAS Cold Failover Cluster を使用して本番サイトの Infrastructure をホストの障害から保護します OracleAS Cold Failover Cluster の詳細は 第 3 章の Oracle Application Server Cold Failover Cluster を参照してください OracleAS Disaster Recovery ソリューションの重要な特徴は 次のとおりです 中間層インストールは 本番サイトとスタンバイ サイト間で同じです つまり 本番サイトの中間層の各インストールは スタンバイ サイトにまったく同等のインストールを持ちます 中間層ノードは複数にすることをお薦めします これにより それぞれのサイトの中間層インストールの各セットを冗長にできるためです 中間層インストールが複数のマシンにあるため そのサイトでの障害および停止はクライアントにとって透過的になります OracleAS Disaster Recovery ソリューションのサイト構成は同一にする必要があります これは プロセスおよび処理手順を両サイトで同一にすることで 運用タスクの実行および維持が容易になるためです また同一のサイト構成は Oracle Application Server 10g コンポーネント構成ファイルのサイト間での同期化を手動で行う際にエラーを防ぎます 障害が原因で本番サイトが使用不能になったときは 妥当な時間内に スタンバイ サイトが運用可能になります クライアント リクエストは 本番として運用されているサイトに必ずルーティングされます サイトの停止に伴うフェイルオーバーまたはスイッチオーバー処理が実行された後 クライアント リクエストは運用を引き継いだ別のサイトへとルーティングされます 新しい本番サイトが提供するサービスの質は 停止前に元の本番サイトが提供していたサービスと同じになります サイトは アクティブ / パッシブ構成でセットアップされます アクティブ / パッシブ セットアップは 本番として使用される 1 つのプライマリ サイトと最初はパッシブ ( スタンバイ ) になっている 1 つのセカンダリ サイトで構成されます セカンダリ サイトは フェイルオーバーまたはスイッチオーバーが実行された後にのみアクティブになります 両サイトには対称性があるため フェイルオーバーまたはスイッチオーバー後は 元のスタンバイ サイトを新しい本番サイトとしてアクティブな状態に維持できます 修復またはアップグレードが終わると 元の本番サイトは新しいスタンバイ サイトになります どちらのサイトも クライアントに対して同じレベルのサービスを提供します 6-6 Oracle Application Server 10g 高可用性ガイド

163 OracleAS Disaster Recovery 環境のセットアップ スタンバイとして運用されるサイトには Oracle Data Guard が管理する Oracle Application Server Infrastructure のフィジカル スタンバイがあります Oracle Data Guard と Infrastructure 構成ファイルのバックアップおよびリストア手順を組み合せることで 本番サイトとスタンバイ サイト間で構成を同期化できます スイッチオーバーおよびフェイルオーバー手順は 2 つのサイトの Infrastructure 間で 運用形態の切替えを可能にします OracleAS Disaster Recovery ソリューション用に Oracle Data Guard をセットアップする方法は 6-20 ページの Oracle Data Guard のセットアップ を参照してください OracleAS Disaster Recovery 環境のセットアップ OracleAS Disaster Recovery ソリューション用に OracleAS ソフトウェアをインストールする前に システム レベルでの構成がいくつか必要になります これらの構成を実行するタスクには 次のものがあります ホスト名の計画と割当て ホスト名解決の構成 ホスト名の計画と割当て Secure Shell(SSH) ポート フォワーディング この項では これらのタスクの実行に必要な手順について説明します 物理ホスト名および論理ホスト名のセットアップ手順を実行する前に OracleAS Disaster Recovery ソリューション全体で使用する物理ホスト名および論理ホスト名を計画します ホスト名の計画および割当てにおける全体的なアプローチとは 次の目標を達成することです 中間層および Infrastructure の OracleAS コンポーネントが 本番サイトまたはスタンバイ サイトのどちらにあるかに関係なく 構成設定で同一のホスト名を使用できること たとえば 本番サイトの中間層コンポーネントが同じサイト内のホストへのアクセスに名前 asmid1 を使用するのであれば スタンバイ サイトの同じコンポーネントはこの同じ名前を使用して スタンバイ サイト内にある asmid1 と同等のホストにアクセスできます スタンバイ サイトが本番サイトを引き継ぐ際に ホスト名 ( 物理 論理または仮想 ) の変更が必要ないこと 注意 : 本番サイトとスタンバイ サイトの物理ホスト名は両サイト間で統一する必要がありますが 物理ホスト名を解決した後の適切なホストは異なっていてもかまいません ホスト名解決の詳細は 6-12 ページの ホスト名解決の構成 で説明します Oracle Application Server Disaster Recovery 6-7

164 OracleAS Disaster Recovery 環境のセットアップ ホスト名の計画および割当てで実行する手順を 図 6-2 を例に説明します 図 6-2 本番サイトとスタンバイ サイトの名前割当ての例 6-8 Oracle Application Server 10g 高可用性ガイド