1

Page 1

Oracle Application Server 10gOracle Developer Suite 10g

機能概要

～ High Availability ～

2

Page 2

はじめに

Oracle Application Server 10g (9.0.4)では、サービスを継続して提供

するために様々な高可用性機能を提供しています。その中核となるのが各層でのクラスタ機能です。10g(9.0.4)での強化ポイントの１つとして、このクラスタの運用・管理性の向上があります。

このセッションでは、クラスタとその強

化ポイントを中心に解説いたします。

本資料ではOracle Application Server 10g(9.0.4)での新機能および強化部分を明確にするため、スライド上で「New」および「Enhanced」と記してあります。

3

Page 3

アジェンダ

� OracleAS 10g (9.0.4) High Availability– 高可用性機能の概要

� OracleAS 10g (9.0.4) クラスタ・ソリューション

– Infrastructureクラスタ

– WebCacheクラスタ

– OracleASクラスタ

� まとめ

4

Page 4

アジェンダ

� OracleAS 10g (9.0.4) High Availability– 高可用性機能の概要

� OracleAS 10g (9.0.4) クラスタ・ソリューション

– Infrastructureクラスタ

– WebCacheクラスタ

– OracleASクラスタ

� まとめ

5

Page 5

OracleAS 10g (9.0.4) High Availability

システム障害

データ障害、災害

人的ミス

OPMN、クラスタ

バックアップ & リカバリ、Disaster Recovery

DCM 、 DCMアーカイブ&リカバリ、バックアップ & リカバリ

システムのメンテナンス DCM、ローリングアップグレード

計画外停止

計画停止

� サービス停止に繋がるあらゆる要因に対するソリューションを提供

6

Page 6

End-to-Endのクラスタリング

Web Cache クラスタ

OracleAS クラスタInfrastructure

クラスタ

クライアント

Oracle Application Server 10g (9.0.4)

カスタマDB

Oracle DB 10g

（RAC）

� すべての層にわたってクラスタリングが可能

Oracle Application Server 10g(9.0.4)では3つの層でのクラスタリングをサポートしています。

キャッシュ層のWebCacheクラスタ、WebサーバとAPサーバ層のOracleASクラスタ、そして基盤部分のinfrastructureクラスタ。それぞれのコンポーネントの役割によってクラスタリングの仕組みや中身も違いますが、基本的には、クラスタによって高可用性およびスケーラビリティの2つの特性を見出そうとしています。詳細は後続セクションで説明します。

7

Page 7

プロセス障害への対応� OPMN （Oracle Process Manager and Notification Server）

Web Cache

OHSHTTP OC4JAJP

OPMN

mod_oc4j

– イベント・スクリプトの実行

– 各ノードのOPMNがプロセス状態を通達し合い、 OracleASクラスタでの障害時フェイルオーバーを実現

– プロセス監視と自動回復

– 監視下プロセスの情報収集

監視、　　

情報収集カスタムプ ロ セ ス

クライアント

カスタマDB

他ノードのOPMNとの通信

Oracle Application Server 10g

NEWENHANCED

ENHANCED

OPMNはOracle Process Manager and Notification Serverの略で、その名前のとおり2つの役割、Process Manager（プロセスの管理・監視）とNotification（通達）を持ちます。

1. プロセスの管理・監視

・Oracle Application Serverを構成するプロセスの監視と障害検知時の自動回復

・監視下プロセスの情報収集：プロセスに関するあらゆる情報（使用しているCPU、メモリ・リソース、プロセスID、起動時間等）をOPMNを通して参照できます。

2. 通達

・イベント・スクリプトの実行：OPMNが障害を検知した場合などに独自に定義した動作を行うよう、イベント・スクリプトを組み込むことが出来ます。例として、OPMNがOC4Jプロセスの停止を検知したら管理者にメールを送る、もしくは独自のログに書き込む等が考えられます。

・分散環境においては各ノードのOPMNがプロセス状態を通達し合い、障害時のフェイルオーバーを実現します。 この機能はOracleASクラスタのベースとなっています。

8

Page 8

プロセス障害への対応

� OPMN監視対象プロセス

– デフォルトでOracleAS Metadata Repository (DBインスタンス）を 除くすべてのプロセスが対象

– opmn.xmlの編集により

� カスタムプロセスの組み込みが可能

� 管理対象の依存関係 (起動順序) を設定可能

� 自動再起動する / しない、Pingの間隔などの指定が可能

ENHANCED

以下は、Standalone OC4Jプロセスを同じサーバで動かし、OPMNの監視下に置く場合の設定例(opmn.xmlの抜粋)になります。 opmn.xmlの完全な記述方式についてはOracle Process Manager and Notification Server Administrator‘s Guide 10g (9.0.4)をご参照く

ださい。

---

<ias-component id="Custom">

<process-type id="Custom" module-id="CUSTOM" working-dir="/home/oracle/work/rmuramot/oc4j/j2ee/home">

<process-set id="Custom" numprocs="1">

<module-data>

<category id="start-parameters">

<data id="start-executable" value="/opt/oracle/904_3/jdk/bin/java"/>

<data id="start-args" value="-jar /home/oracle/work/rmuramot/oc4j/j2ee/home/oc4j.jar"/>

</category>

<category id="restart-parameters">

<data id="restart-executable" value="/opt/oracle/904_3/jdk/bin/java"/>

<data id="restart-args " value="-jar /home/oracle/work/rmuramot/oc4j/j2ee/home/admin.jar ormi://localhost:23791 admin welcome -restart"/>

</category>

<category id="stop-parameters">

<data id="stop-executable" value="/opt/oracle/904_3/jdk/bin/java"/>

<data id="stop-args " value="-jar /home/oracle/work/rmuramot/oc4j/j2ee/home/admin.jar ormi://localhost:23791 admin welcome -shutdown"/>

</category>

</module-data>

</process-set>

</process-type>

</ias-component>

---

9

Page 9

構成管理

� Distributed Configuration Manager (DCM)– OC4JやOHS などのコンポーネントの設定情報を

管理する機能

– Application Server Controlのベースとなる機能

– Archive機能により、管理者の設定ミスに対して柔軟に対応

– 設定情報を管理リポジトリに保存することにより、分散環境でも容易に一貫性のとれた状態を保持

ENHANCED

NEW

Distributed Configuration Manager (DCM) はOracle Application Server 10gを構成するコンポーネントの設定・構成を管理する機能です。これらの情報を管理する際に単一のリポジトリを利用するという特徴があり、そのおかげでクラスタのような分散環境の管理に有効です。DCMに関してはいくつか機能の追加、エンハンスがされていますが、詳細は後続のセクションで詳解します。

10

Page 10

バックアップ&リカバリ

� 10g(9.0.4)よりバックアップ&リカバリ・ツールとマニュアルを製品に同梱

� Middle Tier および Infrastructure に対応

– 構成にあわせて必要な設定ファイルをバックアップするためのPerlスクリプト＆InfrastructureのデータベースをバックアップするためのRMANスクリプトで構成

� オフライン/オンラインでフル/差分バックアップの取得可能

� フルと差分バックアップを組み合わせた point-in-time リカバリが可能

NEW

R2(9.0.2/3)でOTNより提供していたバックアップ＆リカバリ・ツールを10g (9.0.4) からは正式に製品に同梱するようになりました。

各種設定ファイルをバックアップするためのPerlスクリプト群およびInfrastructure DBのバックアップを取得するためのRMANスクリプト群から構成されているこのツールを使うことで、例えば、インストール直後等にコールド・バックアップを一度取得し、その後の開発・運用時に適宜にオンラインで差分バックアップをとっていくことで、障害が発生した場合にpoint-in-timeリカバリが可能になります。

11

Page 11

Disaster Recovery� 地震、火事などによってサ

イト全体が障害にあった場合の対処策

� 地理的に分けられたActive/Standby 構成

– バックアップ & リカバリ機能を使用してプライマリとスタンバイ・サイトの構成ファイルを同期

– Infrastructure内のDBはData Guardで同期

プライマリ・サイト スタンバイ・サイト

DR Sync

DR Sync

DR Sync

ロードバランサ ロードバランサ

クライアント

MT1 MT2 MT1’ MT2’

INFRA INFRA’

NEW

地震や火災などでデータセンター全体が障害にあった、もしくはそこに繋がるネットワークに支障がきたされた場合は、ここまで解説してきたクラスタ等のソリューションでは対処できません。必要なのは、通常運用時に使う「プライマリ・サイト」に加え、災害時の代替としてすぐに利用可能な「スタンバイ・サイト」を物理的に分けられた位置に用意するといったDisaster Recoveryソリューションになります。この構成を実現するためにOracleAS10g(9.0.4)として提供するのは、プライマリとスタンバイ・サイトが障害時に切り替わったときに同等のサービスを提供できるよう、この二つを同期化する仕組みです。

1. バックアップ＆リカバリ・ツールをベースとした仕組みで構成ファイルの同期化

2. DataGuardでプライマリ・サイトのREDOログをスタンバイ・サイトに適用し、Infrastructure DB の同期化

このようにして同期化された２つのサイトを構築することによって、災害発生時でもサービスを継続して提供することが可能になります。

12

Page 12

Disaster Recovery

DR Sync

DR Sync

ロードバランサロードバランサ

プライマリ・サイト スタンバイ・サイト

DR Sync

� プライマリ・サイトとスタンバイ・サイトの切り替えをクライアントに認知させるための仕組みが必要

– Wide Area Load Balancer (global traffic manager)

– DNSエントリの手動切り替え

クライアント

MT1 MT2 MT1’ MT2’

INFRA INFRA’

NEW

障害時のルーティングに関してはOracleASが干渉する部分ではありませんが、一般的にはDNSのマッピング・設定の手動操作もしくはWide Area Load Balancingというソリューションを利用します。 DNSエントリの手動切り替えと違い、Wide Area Load Balancingを利用することで障害を瞬時/自動的に検知し、対応することができますが追加コストがかかります。

13

Page 13

アジェンダ

� OracleAS 10g (9.0.4) High Availability– 高可用性機能の概要

� OracleAS 10g (9.0.4) クラスタ・ソリューション

– Infrastructureクラスタ

– WebCacheクラスタ

– OracleASクラスタ

� まとめ

14

Page 14

Infrastructureのクラスタ

� Cold Failover Cluster (CFC)と呼ばれるActive/Standby構成でInfrastructureが提供するサービスの可用性を向上

� R2 (9.0.2) から利用可能

� 10g（9.0.4)より簡略化されたインストール作業

– クラスタウェア要件の確認

– 論理ホスト名、論理IPのマッピングを指定

– 共有ディスクの用意

� サポートされるクラスタウェア– Sun Cluster, HP MC/Service Guard, Red Hat Cluster

Manager etc.

ENHANCED

CFCはいわゆるActive/Standby構成で、片方のノードがサービスを提供し、もう片方はそのサービスを提供しているノードの障害に備えて待機しています。この構成はクラスタウェアを利用してつなげたノードの共有ディスクに対してOracleAS Infrastructureをインストールするといった方法で構築します。R2(9.0.2)では一部ライブラリを置き換える等の追加作業が必要でしたが、10g(9.0.4)ではこの構築作業が非常に簡略化されています。

15

Page 15

Cold failover Cluster (CFC)

Active Standby

共有ディスク

論理IP、論理ホスト名

phy-host1 phy-host2物理ホスト名 物理ホスト名

ポイント②：Middle Tier は論理ホスト名を通してInfrastructure へリクエスト

ポイント③：phy-host1 が落ちた場合phy-host2 でサービス再開

ポイント①：Infrastructureのインス

トールは共有ディスクに格納

clusterware

切り替え

Middle Tier

INFRA INFRA

16

Page 16

Active Standby

共有ディスク

phy-host1 phy-host2

clusterware

切り替え

①

②

③ ④

⑥

Middle Tier

Cold failover Cluster (CFC)� フェールオーバー時の動作

⑤

論理IP、ホスト名

CFCでのフェールオーバー時の動作：

1. phy-host1で障害を検知

障害発生の判断基準としてMetadata Repositoryのバックグラウンド・プロセスを監視するのが一般的

2.phy-host1で

a. Infrastructureを停止

b. 論理 IPの非アクティブ化

c. 共有ボリューム切り離し

3.phy-host2で

a. 共有ボリュームマウント

b. 論理 IPのアクティブ化

c. Infrastructureを起動

4.phy-host2でサービス継続

17

Page 17

アジェンダ

� OracleAS 10g (9.0.4) High Availability– 高可用性機能の概要

� OracleAS 10g (9.0.4) クラスタ・ソリューション

– Infrastructureクラスタ

– WebCacheクラスタ

– OracleASクラスタ

� まとめ

18

Page 18

Web Cache クラスタ

� 外部ロードバランサによる可用性の向上

� Web Cache クラスタを組むことによりスケーラビリティ・管理性の向上

– 複数のWeb Cacheインスタンスがひとつの論理キャッシュとして動作し、キャッシュしたコンテンツを効率よく、共有する

– インスタンス間で設定が共有されるため管理が容易

Web Cacheクラスタ APサ ー バ

カスタマDB

外部ロードバランサ

クライアント

WebCacheクラスタを利用し、インスタンスがひとつの論理キャッシュとして動作することにより次のメリットがあります。

・キャッシュしたコンテンツを効率よく共有することによるスケーラビリティの向上

・インスタンス間で設定が共有されるため管理が容易

コンテンツ共有の仕組みを簡単に説明すると、Web Cacheは起動時とともに、スロットと呼ばれる「箱」を各自一定数作成します。2ノードのクラスタを組んでいる場合では、このスロットの半分を自ノード、残りをもうひとつのノードという具合に割り当てます。次にリクエストがきた際、これをそのどちらかのスロットに割り当てて、どのリクエストがどのノードでキャッシュすべきか決めます。尚、この判断には、「http:/」の部分を除いたURLに対してハッシュ関数を適用して算出された値が利用されます。すべてのキャッシュ・ノードで同じアルゴリズムが使用されるので、どのノードがどのコンテンツの所有権を持っているのか・持つべきなのか、ピア間の通信なしで判断可能になっています。

19

Page 19

アジェンダ

� OracleAS 10g (9.0.4) High Availability– 高可用性機能の概要

� OracleAS 10g (9.0.4) クラスタ・ソリューション

– Infrastructureクラスタ

– WebCacheクラスタ

– OracleASクラスタ

� まとめ

20

Page 20

OracleAS クラスタ

� Webサーバ（OHS）とJ2EEコンテナ（OC4J）のクラスタ

� OracleAS クラスタを組むことによって得られる動作

1. 各ノードのOPMNが通信しあい、クラスタに含まれるOHSとOC4J間の負荷分散および障害時のフェール

オーバを自動的に調整

2. 複数のOC4J間でアプリケーションのステート（状態）を相互に複製し、フェイルオーバ時にセッションの引継ぎを可能に

3. DCM機能により、クラスタ内のOracleASインスタンスが同一構成（デプロイされているアプリケーションなど）になることを保証

OracleASクラスタとは、J2EEアプリケーションにスケーラビリティと高可用性を提供するのを目的とした、WebサーバとJ2EEコンテナ部分のクラスタを指します。

21

Page 21

OC4J

OHS

OracleAS クラスタ

OC4Jプロセス

状態の通知およ

びルーティング

OHS mod_oc4j

mod_oc4j

OPMN

OPMN

OC4J

J2EEアプリ

ケーション

クラスタ間の設定の同期化

Middle Tier A

Middle Tier B OracleAS クラスタ

ロー

ドバ

ラン

サ

DC

M

ステートステート

ステートステート

状態の

複製

DC

M

クライアント

クラスタ基本設定

管理　　　

リポジトリ

22

Page 22

レプリケーション（HTTP）� HTTPレプリケーション

– HTTPSessionオブジェクトが変更(setAttribute())されるとIPマルチキャスト方式で伝播

– アイランドでレプリケート範囲を指定

MiddleTierインスタンスA

OC4Jインスタンス

OHS

OracleAS クラスタ

OC4Jインスタンス

OHS

OC4Jインスタンス

OHS

アイランド

アイランドOC4J

プロセス

MiddleTierインスタンスB MiddleTierインスタンスC

OC4J プロセス

OC4J プロセス

OC4J プロセス

ステートフルなアプリケーションが障害時に透過的にフェールオーバーし、処理を継続する為にはセッション情報の複製（レプリケーション）を行う必要があります。

J2EEアプリケーションではWebコンテナおよびEJBコンテナもしくは両方でセッションの情報を保持する可能性があります。Webコンテナ層におけるセッション管理を実現するには、通常HttpSessionオブジェクトを使用します。OracleASではこのHTTPSessionオブジェクトが変更(setAttribute())されるとIPマルチキャスト方式で伝播することによってセッション情報のレプリケーションを実装しています。ただしスケーラビリティの面を考え、クラスタに属すすべてのOC4Jインスタンスにその変更情報を伝播するのではなく、アイランドという管理者が任意に定義する論理的なグループで伝播範囲を指定できます。

23

Page 23

レプリケーション（EJB）

� EJBレプリケーション– Stateful Session Bean (SFSB)

� JVM終了時にレプリケート

­ JVM 終了時にのみセッション情報を転送するため、プロセス/ハードウェア障害には対応不可

� 呼び出し終了時にレプリケート

­ メソッド呼び出し毎にセッション情報をIPマルチキャスト

– JNDIツリー・レプリケーション

� EJBレプリケーションの設定を行うと自動的に有効

� JNDIツリー・レプリケーションだけ利用したいという場合でもEJBレプリケーションを設定する必要あり

NEW

JNDIツリー・レプリケーションはEJBレプリケーションの設定を行うと自動的に有効になります。尚、EJBレプリケーションを必要とせず、JNDIツリー・レプリケーションだけ利用したいという場合でもEJBレプリケーションを設定する必要があります。

24

Page 24

フェイルオーバ / ロードバランス

� mod_oc4jとOPMNとの連携により、アイランド内でのロードバランス、障害発生時のフェイルオーバを実現

� リソースを有効活用できるよう、いくつかのロードバランス方式から選択可能

– ラウンドロビン

– ランダム

– メトリックス・ベース� 各OC4Jプロセスの負荷状況をもとにルーティング

� ロードバランス方式のオプション– Local Affinity

� OHSと同一マシンのOC4Jに優先的にルーティング

– Weighted� OC4Jプロセスが動作する各ホストに指定された“Weight”をもとにリ

クエストの割り振りを決定

NEW

NEW

OHSに組み込まれたOracle独自のモジュール（mod_oc4j）とプロセスの障害を検知する仕組みのOPMNを連携させることにより、OC4Jプロセスの障害時のフェイルオーバー動作を実現します。ただしこれだけではなく、リソースを最大限に利用できるよう、3つのロードバランス方式と2つのオプション（＋デフォルトのオプションなし）で計８つの選択肢を提供しています（メトリックス・ベース＋Weightedオプションの組み合わせは不可）。

25

Page 25

OracleASクラスタの管理

� 10g(9.0.4)ではDistributed Configuration Management (DCM) をベースとしたOracleASクラスタの運用・管理性が向上

– Fileベースの管理リポジトリをサポート

– DCMリポジトリのArchive機能により、管理者の人

的ミスに迅速に対応

NEW

NEW

26

Page 26

DCM管理リポジトリの種類

管理リポジトリ（Fileシステム上）

登録同期

OracleAS Infrastructure

Fileベース管理リポジトリDatabaseベース管理リポジトリ

MTノード#1 MTノード#2

OracleAS クラスタ

管理リポジトリ（Metadata

Repository 内）

MTノード#1 MTノード#2

OracleAS クラスタ

OracleAS Infrastructure 不要 !!

登録 同期

NEW

R2(9.0.2/3)ではInfrastructureを利用したDBベース・リポジトリのみサポートしており、管理者にとってはDBを管理する負担が掛かっていました。そこで10g(9.0.4)からはDBベース・リポジトリに加え、ファイルシステムにリポジトリを配置するfileベース・リポジトリがサポートされるようになりました。もちろん、Infrastructureには管理リポジトリ以外にも認証サービスを提供するなどの役割を持ちますので、そのような用途でInfrastructureをすでに利用している場合にはDBベース・リポジトリを使用することをお勧めします。

27

Page 27

Fileベース・リポジトリの可用性

ノード#A ノード#B ノード#C

OracleAS クラスタ　（リポジトリ移動前）

リポジトリホスト

OracleAS クラスタ　（リポジトリ移動後）

ノード#A ノード#B ノード#C

リポジトリ

ホスト

① あらかじめリポジトリ情報をファイルにエキスポートし、安全な場所に保管

② 新しくリポジトリのホストとなるノードにリポジトリ情報を

インポート。この時点でクラスタの管理作業が再開可能

③ ノード2での障害が修復され、クラスタに戻る際にはリポジトリが移動したことを通知

リポジトリの

エ キ ス ポ ー ト

・ファイル

NEW

DBベース・リポジトリの場合、CFCによりリポジトリの可用性を保証することができます。Fileベース・リポジトリの場合は、リポジトリのexport/import機能を利用して障害に対処します。下記はリポジトリが障害にあった場合に、それを新たなホストに移動し、サービスを継続する際の手順になります。尚、リポジトリが利用できない事態に陥った場合、管理作業を行うことは出来ませんが、実行中のアプリケーションには特に影響はありません。

1. ホストからリポジトリ情報をrep.dmpファイルにあらかじめexportしておく

% dcmctl exportrepository -file rep.dmp

2. rep.dmpファイルを安全な場所に保管し、リポジトリ障害時にはFTP等で新規ホストとなるノードに移動

3. このファイルをimportする前にクラスタに含まれるすべてのインスタンスでdcmデーモンを停止

% opmnctl stopproc ias-component=dcm-daemon

3. 新規ホストでrep.dmpファイルをimport

% dcmctl importrepository -file rep.dmp

4. ホストとなったことを確認

% dcmctl whichfarm

Farm Name: .opt.oracle.904_1.dcm.repository

Host Instance: 904_3.wo2.oracle.co.jp

Host Name: wo2.oracle.co.jp

Repository Type: Distributed File Based (host)　<= ★

SSL In Use: false

5. 旧ホストをクラスタのメンバーとして復活させる場合、自分がもうホストでないことを認識させる

% dcmctl repositoryrelocated

28

Page 28

DCM Archive機能

� 構成・設定のスナップショットをリポジトリに保持し、変更のロールバックを可能にする機能

� バックアップ＆リカバリより手軽・高速に設定ミスなどから回復

� アーカイブ取得のタイミング– 自動 (automatic)

� 設定の変更を実行する前にDCMが自動的にビフォア・イメージをアーカイブ� デフォルトでは15個の自動アーカイブまで保持（変更可）

– 明示的 (explicit)� 任意のタイミングでコマンド（dcmctl createArchive) を発行し

、アーカイブを取得

NEW

アーカイブを取得する方法は2通りあります。

1. dcmctlもしくはApplication Server Control GUIからの指示による構成・変更を適用する前にDCMが自動的取得する自動アーカイブ。

2. 管理者が任意のタイミングで取得する明示的アーカイブ（dcmctl createarchiveコマンドの発行）

自動アーカイブの最大数はデフォルトで15個となっていますが、ディスク領域に余裕がある等で最大数を変更したい場合は次のコマンドを利用します。

$ dcmctl set -arch 50 (アーカイブ数を50に設定。offにする場合は“0”を指定。）

また上書きを避けるためにも、アーカイブをリポジトリからファイルにエキスポートしておき、必要な時にインポートすることも可能です。

$dcmctl exportarchive -arch archive_name -f file_name

$dcmctl importarchive -arch archive_name -f file_name

取得したアーカイブを適用することによってアーカイブ取得時の構成に戻ることができます。

$dcmctl applyarchiveto -arch archive_name

尚、OracleAS10g(9.0.4)でアーカイブ機能が追加されたことにより、dcmctlコマンドのsaveInstance、restoreInstanceオプションはdeprecate扱いとなっています。

29

Page 29

OracleASクラスタ環境でDCM Archiveを使用する際の注意点

� アーカイブは2種類存在

– クラスタ・モード：クラスタ内のメンバーが共有する“クラスタ基本設定情報”を保存

– インスタンス・モード：指定したインスタンスの情報を保存

� クラスタ環境での自動アーカイブはクラスタ・モードで取得される

� クラスタに属すインスタンスの場合、インスタンス・モードのアーカイブは適用不可

NEW

アーカイブはクラスタ・モードおよびインスタンス・モードの2種類存在します。

この2つの大きな違いはクラスタ・モードではインスタンス固有の設定が含まれないということです。インスタンス固有の設定とは以下のようなものを指します。

　・OHS – 各種ディレクティブ（ApacheVirtualHost、Listen、Port、ServeName、User、Group等）

　・OC4J – OC4Jプロセス数、RMI、JMS、AJPポート、OC4J起動オプション等

完全なリストにつきましてはOracle Application Server 10g (9.0.4) High Availability Guideを参照してください。

OracleASクラスタを利用している場合の自動アーカイブはクラスタ・モードで行われるため、インスタンス固有の設定の変更を回復するためには明示的にインスタンス・モードのアーカイブを取得しておく必要があります。しかしインスタンス・モードで取得したアーカイブはクラスタに属したインスタンスには適用できないという制約があります。ではどうすればよいのでしょうか？後続のスライドで例を用いて、OracleASクラスタ環境でのDCM Archive利用方法を解説します。

尚、OracleASクラスタを組んでいない環境では、アーカイブがクラスタ/インスタンス・モードで取得されているかは気にする必要はありません。

30

Page 30

OracleASクラスタ環境でのDCM Archive利用方法 (1)

OracleAS クラスタ：状態A OracleAS クラスタ：状態B

①J2EEアプリケーションのデプロイ

②自動的にアーカイブが作成

状態Aのアーカイブ③デプロイ作業を取り消すため状態Bにアーカイブを適用

④状態Aに回復

NEW

OracleASクラスタ環境で、クラスタ全体に影響する変更をアーカイブを利用してロールバックする手順：

① クラスタ全体に影響する変更を行う（eg.J2EEアプリケーションのデプロイ）

% dcmctl deployapplication -file test.ear -a test -co home

② 自動的にクラスタ・モードのアーカイブが作成されていることを確認

% dcmctl listarchives

Name: dcm.autoarchive_219.101.158.145125d61e.f9abf2f4f9. -7ffa

Source: cluster: 904cluster　 <= ★

Version: 9.0.4.0.0

Comments: Automatic archival prior to deployment of application test　 <= ★

Created: 2004-01-20 15:51:20.182

Clusterable: true

③ アーカイブを適用（任意のインスタンスで）

% dcmctl applyarchiveto -src dcm.autoarchive_219.101.158.145125d61e.f9abf2f4f9.-7ffa -cl 904cluster

④ もとの状態にもどっていることを確認

% dcmctl listapplications

31

Page 31

OracleASクラスタ環境でのDCM Archive利用方法 (2)

OracleAS クラスタ：状態A OracleAS クラスタ：状態B

②ノードCのOHSリスニング・ポートを変更

Listen:7777 Listen:80

httpd.conf編集

①明示的にインスタンス・モードのアーカイブを作成

状態AのインスタンスCのアーカイブ

C

③ノードCをクラスタから切り離す

④アーカイブを適用

⑤再度クラスタに参加することによって状態Aに回復

C

C

BA

NEW

BA

OracleASクラスタ環境で、インスタンス固有の変更をアーカイブを利用してロールバックする手順：

① クラスタ環境ではクラスタ・モード(-cl)で自動アーカイブが取得されるためインスタンス固有の変更情報は含まれないので、手動でアーカイブを取得

% dcmctl createarchive -arch portchange -i 904_3.wo2.oracle.co.jp

% dcmctl listarchives

Name: portchange

Source: instance: 904_3.wo2.oracle.co.jp　 <= ★

Version: 9.0.4.0.0

Comments:

Created: 2004-01-20 16:08:12.999

Clusterable: true

② インスタンス固有の変更を行う（eg.OHSのリスニング・ポートの変更）

③ 変更を取り消すためにアーカイブを適用しようとするが、クラスタに属す場合、インスタンス・モードのアーカイブはそのままでは適用できないため、まず該当するインスタンスを一度クラスタから切り離す

% dcmctl leavecluster -cl 904cluster

④ アーカイブを適用し、リスニング・ポートが元の値にもどっていることを確認

% dcmctl applyarchiveto -src portchange -cl 904cluster

⑤ 再度クラスタに登録し、もとの状態に完全に回復

% dcmctl joincluster -cl 904cluster

32

Page 32

まとめ

� OracleAS 10g(9.0.4) はサービス停止に繋がるあらゆる要因に対する高可用性ソリューションを提供

� OracleAS 10g(9.0.4)での機能強化によって可用性を高める構成の構築、運用/管理、そして障害時の回復がさらに容易に

33

Page 33

日本オラクル株式会社

無断転載を禁ず

この文書はあくまでも参考資料であり、掲載されている情報は予告なしに変更されることがあります。日本オラクル社は本書の内容に関していかなる保証もいたしません。また、本書の内容に関連したいかなる損害についても責任を負いかねます。

Oracleは米国Oracle Corporationの登録商標です。文中に参照されている各製品名及びサービス名は米国Oracle Corporationの商標または登録商標です。その他の製品名及びサービス名はそれぞれの所有者の商標または登録商標の可能性があります。