橡CoreTechAS_HighAvailability.PDF

1

Page 1

Oracle Application Server 10g

Oracle Developer Suite 10g

機能概要

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 10

g

(9.0.4) High Availability

–

高可用性機能の概要

Ÿ

OracleAS 10

g

(9.0.4) クラスタ・ソリューション

–

Infrastructureクラスタ

–

WebCacheクラスタ

–

OracleASクラスタ

Ÿ

まとめ

Page 4

アジェンダ

Ÿ

OracleAS 10

g

(9.0.4) High Availability

–

高可用性機能の概要

Ÿ

OracleAS 10

g

(9.0.4) クラスタ・ソリューション

–

Infrastructureクラスタ

–

WebCacheクラスタ

–

OracleASクラスタ

Ÿ

まとめ

5

Page 5

OracleAS 10

g

_{(9.0.4) High Availability}

システム障害 データ障害、災 害 人的ミス OPMN、クラスタ バックアップ & リカバリ、Disaster Recovery DCM 、 DCMアーカイブ&リカバリ、バック アップ & リカバリ システムのメン テナンス DCM、ローリングアップグレード 計画外停止 計画停止

Ÿ

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

提供

Page 6

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

Web Cache クラスタ OracleAS クラスタ Infrastructure クラスタ クライアント

Oracle Application Server 10

g

(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 OHS HTTP AJP _OC4J OPMN mod_oc4j –イベント・スクリプトの実行 –各ノードのOPMNがプロセス状態を通 達し合い、 OracleASクラスタでの障害 時フェイルオーバーを実現 –プロセス監視と自動回復 –監視下プロセスの情報収集 監視、   情報収集 カスタム_{プ ロ セ ス} クライアント カスタマDB 他ノードのOPMNとの通信

Oracle Application Server 10g

NEW ENHANCED

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クラスタのベースとなっています。

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に関してはいくつか機能の追加、エンハンスがされていますが、詳細は後 続のセクションで詳解します。

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

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 10

g

(9.0.4) High Availability

–

高可用性機能の概要

Ÿ

OracleAS 10

g

(9.0.4) クラスタ・ソリューション

–

Infrastructureクラスタ

–

WebCacheクラスタ

–

OracleASクラスタ

Ÿ

まとめ

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

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 10

g

(9.0.4) High Availability

–

高可用性機能の概要

Ÿ

OracleAS 10

g

(9.0.4) クラスタ・ソリューション

–

Infrastructureクラスタ

–

WebCacheクラスタ

–

OracleASクラスタ

Ÿ

まとめ

Page 18

Web Cache クラスタ

Ÿ

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

Ÿ

Web Cache クラスタを組むことにより

スケーラビリティ・

管理性の向上

– 複数のWeb Cacheインスタンスがひとつの論理キャッシュとし て動作し、キャッシュしたコンテンツを効率よく、共有する – インスタンス間で設定が共有されるため管理が容易

Web Cacheクラスタ _{APサ ー バ}

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

19

Page 19

アジェンダ

Ÿ

OracleAS 10

g

(9.0.4) High Availability

–

高可用性機能の概要

Ÿ

OracleAS 10

g

(9.0.4) クラスタ・ソリューション

–

Infrastructureクラスタ

–

WebCacheクラスタ

–

OracleASクラスタ

Ÿ

まとめ

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

クラスタ ロードバランサ DCM ス テ ー ト ス テ ー ト ス テ ー ト ス テ ー ト 状態の 複製 DCM クライアント クラスタ基本設定 管理    リポジトリ

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レプリケーションを設定する必要があります。

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

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

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

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

B

A

NEW

B

A

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

Page 32

まとめ

Ÿ

OracleAS 10g(9.0.4) はサービス停止に繋がるあら

ゆる要因に対する高可用性ソリューションを提供

Ÿ

OracleAS 10g(9.0.4)での機能強化によって可用性

を高める構成の構築、運用/管理、そして障害時の

回復がさらに容易に

33

Page 33

日 本 オ ラ ク ル 株 式 会 社 無断転載を禁ず この文書はあくまでも参考資料であり、掲載されている情報は予告なしに変更されることが あります。日本オラクル社は本書の内容に関していかなる保証もいたしません。また、本書 の内容に関連したいかなる損害についても責任を負いかねます。 Oracleは米国Oracle Corporationの登録商標です。文中に参照されている各製品名及びサービス 名は米国Oracle Corporationの商標または登録商標です。その他の製品名及びサービス名はそれ ぞれの所有者の商標または登録商標の可能性があります。