この章では、Oracle Cluster Ready Servicesの概要と構成手順について説明します。次の項目が含まれます。
Oracle Clusterwareにより、クラスタ環境のユーザー・アプリケーションとOracleデータベースの可用性を管理します。Oracle Real Application Clusters(Oracle RAC)環境において、Oracle ClusterwareはすべてのOracleデータベース・プロセスを自動的に管理します。Oracle Clusterwareの管理対象はクラスタ・リソースと呼ばれます。これは、データベース・インスタンス、リスナー、仮想IP(VIP)アドレスまたはアプリケーション・プロセスになる場合があります。
当初、Oracle ClusterwareはOracle RACのサポート用に作成されました。しかし、その利点はOracle RACに限定されず、アドオン・モジュール(またはアクション・スクリプト)により、他のアプリケーションの管理にもOracle Clusterwareを使用できます。この柔軟性と拡張性から、Oracle ClusterwareはOracle Fusion Middlewareの高可用性ソリューションの基盤となっています。
Oracle Clusterwareの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。
Oracle Clusterwareには、リソース固有のアドオン・モジュールを使用して任意のリソースに保護を提供する高可用性フレームワークが含まれます。Oracle Clusterwareの用語では、リソースとは、アプリケーション、仮想IP、共有ディスクなどの管理対象エンティティを識別するためにOracle Clusterwareによって作成されたオブジェクトのことです。Oracle Clusterwareはリソースを監視し、リソースの状態を頻繁にチェックしてそれが常に利用可能であることを確認し、停止していたら再起動を試みます。再起動に失敗すると、リソースは新しいノードで起動されます。このプロセスはフェイルオーバーと呼ばれています。リソースのスイッチオーバーはリソースの運用環境の意図的な切替えのことですが、正規のユーザー・インタフェースを介してこれを使用することもできます。
この高可用性フレームワークによって、Oracle Clusterwareはユーザーが提供するアドオン・モジュールを介してリソースを管理します。たとえば、単一プロセスで実行されるアプリケーションを表すリソースを作成するには、プロセスを起動および停止し、その状態をチェックするモジュールをユーザーが提供する必要があります。このアプリケーションに障害が発生すると、Oracle Clusterwareではこのモジュールを使用してプロセスの再起動を試みます。このアプリケーションが現在実行されているノードで障害が発生したときに、アプリケーションおよびリソースが正しく構成されている場合、Oracle Clusterwareでは別のノードでアプリケーションの再起動を試みます。リソースの監視頻度を構成して、他のリソースとの関係を定義することができます。
Application Server Cluster Ready Services(ASCRS)を使用すると、重要で複雑なOracle Fusion Middlewareアプリケーション環境で独自のアドオン・モジュールを記述する労力が軽減され、Oracle Clusterwareの高可用性機能に容易にアクセスできます。
注意: ASCRSは、すでにCFCが有効なOracle Fusion Middleware環境を管理するためのソリューションです。様々なFusion MiddlewareコンポーネントでのCFCの有効化の詳細は、第12章「Oracle Fusion Middleware高可用性のためのアクティブ/パッシブ・トポロジ」を参照してください。 |
ASCRSはフロントエンドとバックエンドで構成されます。フロントエンドはコマンドライン・インタフェースであるascrsctlです。このインタフェースにより、リソースの作成、削除、更新、起動、停止、クラスタ・ノード間のスイッチオーバーなどの管理作業を実行できます。バックエンドは、様々なFusion Middlewareリソースのライフサイクル管理のためのロジックです。フロントエンドとバックエンドにはそれぞれ固有のログ・ファイルがあります。
UnixプラットフォームおよびWindows Server 2008では、ASCRSは仮想IP、共有ディスク、データベース・リスナー、データベース・インスタンス、OPMN管理対象インスタンス、およびWebLogic Serverをサポートします。これらのミドルウェア・コンポーネントからOracle Clusterwareリソースを作成し、Oracle ClusterwareとASCRSでクラスタ内の高可用性を維持できます。
Oracle ClusterwareとASCRSには、ホスティング環境が破損したり消失した場合に様々なリソースの残存性を向上する手段が用意されています。ただし、ディスクの破損や、ディスクの破損によるアプリケーションの誤作動を回避するわけではありません。
ASCRSでは、Oracle Clusterwareバージョン10.2.0.4または11.1.0.7以上をサポートしています。オンライン・ヘルプは、次のコマンドを使用して起動できます。
ascrsctl help -c command -t resource_type
たとえば、次のコマンドを実行すると、仮想IPリソースの作成に関するヘルプが表示されます。
ascrsctl help -c create -t vip
ascrsctlのオンライン・ヘルプの完全な内容については、付録E「ascrsctlのオンライン・ヘルプ」を参照してください。
ASCRSを使用するには、クラスタの各ノードにある各CRSホーム内で、CRSの拡張機能としてASCRSをインストールし、個別に構成する必要があります。
ASCRSコマンドライン・ツールのascrsctlにより、ASCRSで様々なミドルウェア・コンポーネントを制御できます。CRSの制御対象であるコンポーネントは、実行時の状態が詳細に監視され、障害発生時にCRSによって適切なアクションが実行されます。ascrsctlを使用して、CRSリソースを作成することができます。リソースを作成したら、そのリソースに対して、起動、停止、更新、切替え、ステータス監視および削除操作を実行できます。
古いバージョンのASCRSを使用している場合、次の手順を実行して最新のASCRSバージョンにアップグレードします。
ASCRSのstop
コマンドを使用して、すべてのASCRSリソースをオフラインにします。
ASCRSのstatus
コマンドを使用してFusion Middlewareリソースのステータスを表示し、そのすべての設定をメモしておきます。
それらのリソースを削除します。
CRS_HOME/ascrs
ディレクトリを削除します。
第13.3.2項「ASCRSのインストール」で説明されているように、ASCRSの新しいバージョンをインストールして、setup
コマンドを使用して終了します。
ステップ2の情報を使用し、ASCRSのcreate
コマンドを使用してFusion Middlewareリソースを再作成します。
クラスタの各ノードにASCRSをインストールします。個別ノードにASCRSを適切にインストールするには、次のことを確認してください。
オペレーティング・システム: ASCRSは、UnixプラットフォームおよびWindows Server 2008でサポートされます。システム・バージョンとパッチ・レベルは、そのプラットフォームでサポートされているCRSのリリースと互換性がある必要があります。
CRSおよびバージョン: CRSは、このシステムにインストールされ、起動され、適切に機能しています。CRSバージョンは、10.2.0.4以降であることが必要です。Oracle ClusterwareおよびCRSのインストールの詳細は、Oracle Clusterwareインストレーション・ガイドfor Linuxを参照してください。
ユーザー・アカウント: ASCRSインストール・ユーザーは、CRSホームの所有者と同一ユーザーである必要があります。これは、管理対象のアプリケーション・リソースの所有者とも同一である必要があります。Windowsでは、ユーザーに管理者権限が必要です。
注意: CRS 10.2.0.4に対してASCRSをインストールするには、ローカル・システムにSun JDK(またはJRE)1.5以上がインストールされている必要があります。これはコマンドライン・ツールのascrsctlで必要になります。 |
ASCRSをインストールする手順は次のとおりです。
CRSの所有者としてログインします。
Oracle Fusion Middleware Companion CDを挿入し、次のコマンドを実行してascrs.zipファイルを解凍およびインストールします。
cd CRS_HOME
unzip Disk1/ascrs/ascrs.zip
cd ascrs/bin
setup
JDK(JRE)1.5+以上がインストールされており、CRSのリリースが10.2.0.4である場合、次のコマンドを実行します。
setup -j JDK/JRE_HOME
インストールが完了すると、次のASCRSディレクトリ構造が表示されます。
CRS_HOME/ascrs/bin CRS_HOME/ascrs/config CRS_HOME/ascrs/lib CRS_HOME/ascrs/log CRS_HOME/ascrs/public CRS_HOME/ascrs/perl CRS_HOME/ascrs/sql CRS_HOME/ascrs/wlst
ASCRSがインストールされると、デフォルト構成で使用できます。ロギングの場所、ロギング・レベルまたはデフォルトのCRSプロパティをカスタマイズするには、CRS_HOME/ascrs/configディレクトリにあるconfig.xml
を編集します。
config.xml
ファイルには、ascrsctl ASCRSエージェント・ロギングの構成が格納されます。いずれかの場所を変更するには、既存のパス名を指定するか、ORACLE_HOME接頭辞を使用してこのCRSホーム内のパス名を指定します。利用可能なロギング・レベルは、冗長性の高い順に、ALL、FINEST、FINER、FINE、INFO、WARNINGおよびSEVEREです。それぞれのリソースには独自のエージェント・ログ・ファイルがあり、そのサイズがrollover_size バイトを超えるとロールオーバーします。
ポリシーのCRSプロパティが構成されます。ポリシー名は、そのポリシーにおけるCRSプロパティ値の特性を示しています。ポリシーはnormalまたはfastを指定できます。ポリシー「fast」はリソースのヘルス・チェックの頻度がより高くなり、フェイルオーバー時の遅延が低下します。
ASCRS付属のデフォルトconfig.xml
ファイルを次に示します。
<?xml version="1.0" ?> <config> <ascrsctl> <display level="normal"/> <log path="${ORACLE_HOME}/ascrs/log/ascrsctl.log" level="FINER"/> <resource-params target="vip" policy="normal"> <param name="AUTO_START" value="1"/> <param name="CHECK_INTERVAL" value="7"/> <param name="FAILOVER_DELAY" value="5"/> <param name="FAILURE_INTERVAL" value="50"/> <param name="FAILURE_THRESHOLD" value="5"/> <param name="RESTART_ATTEMPTS" value="2"/> <param name="SCRIPT_TIMEOUT" value="120"/> <param name="START_TIMEOUT" value="120"/> <param name="STOP_TIMEOUT" value="120"/> </resource-params> <resource-params target="vip" policy="fast"> <param name="AUTO_START" value="1"/> <param name="CHECK_INTERVAL" value="5"/> <param name="FAILOVER_DELAY" value="4"/> <param name="FAILURE_INTERVAL" value="30"/> <param name="FAILURE_THRESHOLD" value="5"/> <param name="RESTART_ATTEMPTS" value="2"/> <param name="SCRIPT_TIMEOUT" value="120"/> <param name="START_TIMEOUT" value="120"/> <param name="STOP_TIMEOUT" value="120"/> </resource-params> <resource-params target="disk" policy="normal"> <param name="AUTO_START" value="1"/> <param name="CHECK_INTERVAL" value="7"/> <param name="FAILOVER_DELAY" value="5"/> <param name="FAILURE_INTERVAL" value="50"/> <param name="FAILURE_THRESHOLD" value="5"/> <param name="RESTART_ATTEMPTS" value="2"/> <param name="SCRIPT_TIMEOUT" value="120"/> <param name="START_TIMEOUT" value="120"/> <param name="STOP_TIMEOUT" value="120"/> </resource-params> <resource-params target="disk" policy="fast"> <param name="AUTO_START" value="1"/> <param name="CHECK_INTERVAL" value="5"/> <param name="FAILOVER_DELAY" value="4"/> <param name="FAILURE_INTERVAL" value="30"/> <param name="FAILURE_THRESHOLD" value="5"/> <param name="RESTART_ATTEMPTS" value="2"/> <param name="SCRIPT_TIMEOUT" value="120"/> <param name="START_TIMEOUT" value="120"/> <param name="STOP_TIMEOUT" value="120"/> </resource-params> <resource-params target="dblsnr" policy="normal"> <param name="AUTO_START" value="1"/> <param name="CHECK_INTERVAL" value="50"/> <param name="FAILOVER_DELAY" value="20"/> <param name="FAILURE_INTERVAL" value="300"/> <param name="FAILURE_THRESHOLD" value="5"/> <param name="RESTART_ATTEMPTS" value="4"/> <param name="SCRIPT_TIMEOUT" value="120"/> <param name="START_TIMEOUT" value="120"/> <param name="STOP_TIMEOUT" value="120"/> </resource-params> <resource-params target="dblsnr" policy="fast"> <param name="AUTO_START" value="1"/> <param name="CHECK_INTERVAL" value="40"/> <param name="FAILOVER_DELAY" value="20"/> <param name="FAILURE_INTERVAL" value="250"/> <param name="FAILURE_THRESHOLD" value="5"/> <param name="RESTART_ATTEMPTS" value="4"/> <param name="SCRIPT_TIMEOUT" value="120"/> <param name="START_TIMEOUT" value="120"/> <param name="STOP_TIMEOUT" value="120"/> </resource-params> <resource-params target="db" policy="normal"> <param name="AUTO_START" value="1"/> <param name="CHECK_INTERVAL" value="120"/> <param name="FAILOVER_DELAY" value="30"/> <param name="FAILURE_INTERVAL" value="700"/> <param name="FAILURE_THRESHOLD" value="5"/> <param name="RESTART_ATTEMPTS" value="4"/> <param name="SCRIPT_TIMEOUT" value="300"/> <param name="START_TIMEOUT" value="300"/> <param name="STOP_TIMEOUT" value="300"/> </resource-params> <resource-params target="db" policy="fast"> <param name="AUTO_START" value="1"/> <param name="CHECK_INTERVAL" value="60"/> <param name="FAILOVER_DELAY" value="20"/> <param name="FAILURE_INTERVAL" value="400"/> <param name="FAILURE_THRESHOLD" value="5"/> <param name="RESTART_ATTEMPTS" value="4"/> <param name="SCRIPT_TIMEOUT" value="300"/> <param name="START_TIMEOUT" value="300"/> <param name="STOP_TIMEOUT" value="300"/> </resource-params> <resource-params target="as" policy="normal"> <param name="AUTO_START" value="1"/> <param name="CHECK_INTERVAL" value="50"/> <param name="FAILOVER_DELAY" value="20"/> <param name="FAILURE_INTERVAL" value="350"/> <param name="FAILURE_THRESHOLD" value="5"/> <param name="RESTART_ATTEMPTS" value="4"/> <param name="SCRIPT_TIMEOUT" value="600"/> <param name="START_TIMEOUT" value="600"/> <param name="STOP_TIMEOUT" value="600"/> </resource-params> <resource-params target="as" policy="fast"> <param name="AUTO_START" value="1"/> <param name="CHECK_INTERVAL" value="40"/> <param name="FAILOVER_DELAY" value="10"/> <param name="FAILURE_INTERVAL" value="300"/> <param name="FAILURE_THRESHOLD" value="5"/> <param name="RESTART_ATTEMPTS" value="4"/> <param name="SCRIPT_TIMEOUT" value="600"/> <param name="START_TIMEOUT" value="600"/> <param name="STOP_TIMEOUT" value="600"/> </resource-params> </ascrsctl> <agent> <log path="${ORACLE_HOME}/ascrs/log" level="FINER" rollover_size="5242880"/> </agent> </config>
注意: リソースのプロパティ値は、それが作成されたときの正しい範囲の中に収まる必要があります。ポリシーにパラメータが構成されていない場合、内部のデフォルト値が使用されます。表E-1に内部のデフォルトのパラメータ値を示します。 |
これらのプロパティの値を編集する場合は、事前にOracle Clusterwareのドキュメントで各パラメータの定義を確認してください。
コンピューティング環境によって処理速度が異なるため、スクリプト、起動および停止のタイムアウト値を設定する前に、アプリケーションの起動と停止における待機時間を測定することをお薦めします。これらの値を、測定された待機時間の約2倍に設定します。
ascrsctlコマンドラインにより、Fusion Middlewareコンポーネント用に作成したCRSリソースを管理します。このツールにより、リソースの作成、更新、起動、停止、スイッチおよび削除ができます。
前の項で述べたように、リソースとは、アプリケーション、仮想IP、共有ディスクなどの管理対象エンティティを識別するためにCRSによって作成されたオブジェクトのことです。各リソースの自動開始値を1
に設定すると、CRSの起動時にそのリソースが確実に起動されます。Fusion Middlewareリソースは相互に依存するため、1つのリソースを起動または停止すると、別のリソースに影響する場合があります。ascrsctl構文を使用してリソースの作成時にリソースの依存性を施行します。実行時に、CRSはこの依存性の情報を使用して起動/停止を行います。
UnixおよびWindows 2008では、ASCRSは、WebLogic Server、OPMN管理対象インスタンス、Oracleデータベース、Oracleデータベース・リスナー、仮想IPおよび共有ディスクをサポートします。これらの個別コンポーネントに対応するCRS管理対象リソースを作成し、そのリソースをCRSで管理できます。
ascrsctlコマンドラインでCRSリソースを作成する際、ネーミング規則が適用されます。リソースを適切に機能させるためには、このネーミング規則に従ってください。予期しないエラーを回避するために、CRSインストールはOracle Fusion Middleware専用にすることをお薦めします。それによって、すべてのCRS管理対象リソースがascrsctlで作成されます。
このネーミング規則では、正式なリソース名を次の形式にします。
ora.name.cfctype
nameは、リソースの短縮名(sharediskやmyvipなど)を表します。typeは、いずれかのリソース・タイプ(vip、disk、db、dblsnr、asなど)を表します。
たとえば、ネットマスクが255.255.255.0であるeth0ネットワーク・インタフェース上でIPアドレス192.168.1.10からora.myvip.cfcvipという仮想IPリソースを作成するには、次のコマンドを使用します。
ascrsctl create -name myvip -type vip -ipAddr 192.168.1.10 -netmask 255.255.255.0 -interface eth0
Windowsの場合:
ascrsctl create -name myvip -type vip -ipAddr 192.168.1.10 -netmask 255.255.255.0 -interface "Public network"
注意: リソースが依存リソースを持つ場合、依存リソースのチェックの間隔を依存先のリソースのチェックの間隔以上に設定します。 |
仮想IPリソースを作成するには、次の情報が必要です。
有効な仮想ホスト名またはIPアドレス。これらはネットワーク内の任意のホストで使用されていないものに限ります。
このホスト名またはIPの有効なネットマスク番号
1つ以上の有効なネットワーク・インタフェース名。これらはこのIPが使用されるすべてのクラスタ・ノードに存在します。Windowsでは、インタフェース名はネットワーク接続名と同じになります。
Windowsでは、インタフェース名はPublic networkなどのネットワーク接続名を指します。
仮想IPリソースはシステム・リソースであるため、Unixのcreateコマンドやupdateコマンドでスクリプトを生成して、これをrootユーザーが実行して操作を行う必要があります。
次のコマンドでは、Linux上でora.myvip.cfcvipという仮想IPリソースを作成します。
ascrsctl create -name myvip -type vip -ipAddr 192.168.1.10 -netmask 255.255.255.0 -interface eth0
Fusion Middleware環境において、共有ディスクは、Oracleデータベース・ソフトウェア、データベース・データファイル、WebLogic Server、OPMN管理対象サーバー、およびそれらのOracleホームの保持に使用されるディスク・ストレージです。共有ディスクにより、クラスタ内にある複数のノード間でアプリケーション・リソースが切り替えられても同じデータを使用できます。
共有ディスク・リソースを作成する際、次の考慮事項について入念に確認してください。
Unixの場合:
共有ディスク・リソースの作成前に、共有ディスクのルートに、.ascrssf
という名前で空のシグネチャ・ファイルを作成します。CRSホームの所有者がこのファイルを所有する必要があります。このファイルは、リソースの作成後、CRSによって使用されます。
マウント・コマンドとアンマウント・コマンドのどちらにも、nop
を指定できます。共有ディスクが常時オンラインの場合は、マウント・コマンドでこれを使用できます。なんらかの理由でディスクがオフラインになると、CRSによって検出され、停止としてマーキングされます。CRSによってディスクをアンマウントする必要がない場合は、アンマウント・コマンドにnop
コマンドを使用できます。この場合、ディスクがアンマウント不要であることを確認してください。共有ディスクが保護されずに2つのノードでマウントされると、ディスクが破損する場合があります。この場合も、共有ディスクには常にシグネチャ・ファイルが必要です。
共有ディスクを使用しているアクティブ・プロセスが存在する場合、マウント・コマンドが失敗することがあります。このコマンドの失敗を防止するには、このディスク・リソースがオンライン状態の間、他のアプリケーションでこのディスクにアクセスしないようにします。
マウント・コマンドやアンマウント・コマンドが複雑な場合は、実行可能スクリプトにロジックをカプセル化し、マウント・コマンドやアンマウント・コマンドとして、スクリプトのフルパスを指定します。適切なアンマウント・スクリプトでは、このディスクを使用している他のプロセスを強制終了して、クリーンで正常なディスク・アンマウントを実行できます。アンマウント・コマンドをスクリプトに記述している場合、fsckコマンドを実行するなどして、基本的なファイル・システム・チェックを実行します。このようなスクリプトでは、成功すると0を返し、失敗すると1を返します。
共有ディスク・リソースはシステム・リソースです。create、updateまたはdeleteのコマンドでは、rootとして実行する必要があるスクリプトが生成され、作成操作を実行します。画面出力の指示に従ってください。
シグネチャ・ファイルが共有ディスクのマウント・ポイントに存在すると、起動や停止の操作が失敗することがあります。シグネチャ・ファイルがマウント・ポイントに存在すると、実際にディスクがマウントされていなくても、マウントされているとASCRSでは認識されます。
mc
やumc
のパラメータまたはスクリプト・ファイルでマウント・コマンドやアンマウント・コマンドを使用する前に、コマンドを検証してください。ASCRSではコマンドの検証は行われません。
共有ディスクがクラスタ・ファイル・システムで保護されていない場合、複数のノードでマウントされていると破損することがあります。これを回避するには、ASCRSリソースを作成する前に、リソースを作成したノード上でのみディスクをマウントします。
Windows Server 2008の場合:
Microsoftディスク管理を開き、共有ディスク数を書き留めておきます。ディスク数は、0、2、5などの負でない整数です。
各クラスタ・ノードに、c:\oracle\asdisk
などの空のマウント・ディレクトリを作成します。
このディスクがいずれのノードのいずれのアプリケーションでも使用されていないことを確認します。
1つのノードの「ディスク管理」で、ドライブを右クリックしそれをオンラインにして、このハード・ドライブに単一のパーティションを作成し、これをNTFSでフォーマットします。それに割り当てられている任意のドライブ文字を削除して、作成したばかりのディレクトリにそれをマウントします。再度ドライブを右クリックして、それをオフラインにします。
それぞれのノードで、Microsoftディスク管理を開き、このドライブをオンラインにして、ドライブ文字があればそれを削除し、作成したばかりのディレクトリにそれをマウントします。ドライブを右クリックして、それをオフラインにします。
ディスク・リソースを作成したノードに進み、ディスクをオンラインにします。
ディスクのルートは、マウント・ディレクトリからアクセスできる必要があります。
共有ディスクのルートに、.ascrssfという名前で空のシグネチャ・ファイルを作成します。CRSホームの所有者がこのファイルを所有する必要があります。このファイルは、リソースの作成後、CRSによって使用されます。
マウント・コマンドは「diskmgr online disknumber」で、アンマウント・コマンドは「diskmgr offline disknumber」です。diskmgrはASCRSの組込みのコマンドです。diskmgrコマンドを使用するために、追加のソフトウェアをインストールする必要はありません。
共有ディスク・リソースを作成するには、Unix上で有効なマウント・ポイント、マウント・コマンドおよびアンマウント・コマンドを含む次のascrsctlコマンドを実行します。
ascrsctl create -n sharedisk -type disk -path /asdisk -mc "/bin/mount /dev/sda /asdisk" -umc "/bin/umount /asdisk"
Windows Server 2008で共有ディスクを作成するには、次のようにascrsctlコマンドを実行します。
ascrsctl create -n sharedisk -type disk -path c:\oracle\asdisk -mc "diskmgr online 2" -umc "diskmgr offline 2"
リソースを作成したら、createコマンドを実行するノード上でそれを明示的に起動し、すでにマウントされているディスクがASCRSの管理下にあることを確認します。
ascrsctl start -n ora.sharedisk.cfcdisk -node <disk resource creation node>
注意: Windows Server 2008では、マップされたデバイスを共有ディスク・リソースとして使用することはできません。一般的なクラスタ・ファイル・システムでは、このような目的で動作することは保証されていません。 |
Oracleリスナー・リソースを作成するには、次の情報が必要です。
有効なOracleデータベース・ホーム
リスナー名
リスナー・アドレスの仮想IPリソース名
Oracleホームのディスク・リソース名
データベース・リスナー・リソースを作成する前に、次の考慮事項について入念に確認してください。
データベース・リスナー・ホームが共有ディスクにインストールされていること。ascrsctlコマンドで共有ディスクのCRSリソースが作成され、リソースが起動されていること。
ascrsctlコマンドで仮想IPのCRSリソースが作成され、リソースが起動されていること。
リスナーがコールド・フェイルオーバー・クラスタ(CFC)対応になっていること。詳細は、第12.2.4項「Oracleデータベースの変換」を参照してください。
リスナー名およびOracleホームが有効なデータベースSIDおよびデータベース・ホームであることを確認します。このリリースでのこのタイプの情報を完全に検証する処理は、ASCRSでは実行されません。
Windowsでは、リスナーWindowsサービスの開始方法が「手動」であることを確認してください。
次に、リソースを作成する際の構文の例を示します。
ascrsctl create -n mydblsnr -type dblsnr -loh /cfcdb -ln LISTENER -disk ohdisk -vip myvip
Oracleデータベース・リスナー・リソース作成に関するオンライン・ヘルプ情報を表示するには、次のコマンドを使用します。
ascrsctl help -c create -t dblsnr
データベース・リソースは、次のいずれかのリソースになります。
Oracleデータベース・インスタンス
Oracle Database Console(dbconsole)プロセス
WindowsプラットフォームのOracleジョブ・スケジューラ・プロセス
WindowsプラットフォームのOracle Volume Shadow Copy Service
Oracleデータベース・インスタンス・リソースを作成するには、次のものが必要です。
有効なOracleデータベース・ホーム
データベースSID名
Oracleホームのディスク・リソース名
ディスク・リソース名(データファイルが、異なる共有ディスクに存在する場合)
リスナー・リソース名
Oracleデータベース・インスタンス・リソースを作成する前に、次の考慮事項について入念に確認してください。
Windowsでは、組込みのユーザー・システムはDBA_GROUPにあり、対応するWindowsサービスの開始方法が「手動」であることを確認してください。
データベース・ホームが共有ディスクにインストールされています。同じ共有ディスクまたは異なる共有ディスクに、このデータベースのデータファイルが配置されています。ascrsctlでこれらすべての共有ディスクのCRSリソースが作成され、起動されています。
ascrsctlコマンドでデータベース・リスナーのCRSリソースが作成され、リソースが起動されています。
データベースはCFC対応です。詳細は、第12.2.4項「Oracleデータベースの変換」を参照してください。
データベースSIDとOracleホームが有効であることを確認します。このリリースでこの情報を包括的に検証する処理は、ASCRSでは実行されません。
次に、データベース・インスタンス・リソースを作成する際の構文の例を示します。
ascrsctl create -n mydb -type db -oh /cfcdb -lsnr mydblsnr -disk ohdisk datadisk
その他すべてのデータベース・リソースを作成するには、次のものが必要です。
有効なOracleデータベース・ホーム
データベースSID名
Oracleホームのディスク・リソース名
有効な仮想IPリソース名。これは、Oracle Database Console(dbconsole)データベース・リソースのみに必要です。
データベースはCFC対応です。
Oracleデータベース・リソース作成に関するオンライン・ヘルプ情報を表示するには、次のコマンドを使用します。
ascrsctl help -c create -t db
OPMNインスタンスおよびWebLogicサービスは、まとめてアプリケーション・サーバー(AS)コンポーネントと呼ばれており、個別のリソースで管理されます。特に、すべてのOPMN管理対象コンポーネントは1つのリソースで管理し、WebLogicドメイン配下のすべてのサーバーは別のリソースで管理する必要があります。
OPMN管理対象インスタンスのリソースを作成するには、次の情報が必要です。
OPMN管理対象コンポーネントの有効なインスタンス・ホーム
インスタンス・ホームのディスク・リソース名
インスタンスのOracleホームのディスク・リソース名(異なる共有ディスクにある場合)
リソースに含めるOPMN管理対象アプリケーションの名前。すべてのコンポーネントのサブセットのみを含める場合は、残りのコンポーネントはCR Sで管理されないので外部のCRSで起動しないでください。デフォルトでは、すべてのコンポーネントが含まれます。
OPMNリソースを作成する前に、次の考慮事項について入念に確認してください。
Oracleホームが共有ディスクにインストールされていること。OPMNインスタンスが同一または異なる共有ディスクにあること。ascrsctlでこれらすべての共有ディスクのCRSリソースが作成され、起動されていること。すべてのOPMN管理対象アプリケーションをシャットダウンすること。
OPMNサーバーとその管理対象のOracle Fusion Middlewarコンポーネントは、CFCに対応しています。Oracle Fusion MiddlewareコンポーネントでCFCを有効にする手順の詳細は、第12.2.2.6項「Oracle Process Management and Notification Serverの変換」から第12.2.2.9項「インスタンス固有の考慮事項」および第12.2.3項「Oracle Fusion Middlewareコンポーネントの変換」を参照してください。
Windowsでは、このインスタンスに関するOPMN Windowsサービスの開始方法が「無効」であることを確認してください。
次に、リソースを作成する際の構文の例を示します(Oracleホームとインスタンス・ホームは、同じディスク上にあります。すべてのコンポーネントが含まれます。):
ascrsctl create -n myopmn -type as -ch /cfcas -disk ohdisk
OPMNインスタンス・リソース作成に関するオンライン・ヘルプ情報を表示するには、次のコマンドを使用します。
ascrsctl help -c create -t as
WebLogicドメインのCRSリソースを作成する場合、他のタイプのリソースを作成する場合よりも多くの準備が必要です。準備が複雑なため、その手順を次の項に分割します。
基本設定
ノード・マネージャの設定
管理サーバーの設定
リソースの作成
基本設定
基本設定の開始前に、WebLogicが共有ディスクにインストールされていることを確認してください。WebLogic Serverソフトウェアとドメイン・インスタンスは、同じ共有ディスクにでも別々の共有ディスクにでもインストールできます。
また、次のノード・マネージャおよびサーバーの設定処理を進める前に、WebLogic Server環境でCFCが有効であることを確認してください。Oracle WebLogic Server環境でのCFCの有効化の詳細については、第12.2.2.3項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」から第12.2.2.5項「ノード・マネージャの変換」を参照してください。CFCが有効にされていると、サーバー、元のノードおよびフェイルオーバー・ノードを、顕著な相違なしに手動で起動や停止ができます。
依存リソースを作成する手順は次のとおりです。
各共有ディスクのCRSリソースを作成し、作成場所のノードでリソースを起動します。
ascrsctlコマンドで仮想IPのCRSリソースを作成し、同じクラスタ・ノードでリソースを起動します。
ノード・マネージャの設定
ノード・マネージャを設定する手順は次のとおりです。
Windows Server 2008では、各ノードにノード・マネージャのWindowsサービスがない場合、WL_HOME/server/binディレクトリから次のコマンドを実行してそれを作成します。
installNodeMgrSvc.cmd
Windows Service Managerで、このサービスが手動の起動モードであることを確認します。
ノード・マネージャのユーザー名とパスワードが変更されていない場合は、それらを変更します。初期パスワードはランダムに生成されます。ノード・マネージャのパスワードを変更するには、WebLogic Server管理コンソールで「ドメイン」、「セキュリティ」、「一般」、「詳細」の順に選択します。新しいパスワードを入力して「保存」をクリックします。
ステップ1またはステップ2でなんらかの変更を行った場合、ノード・マネージャを再起動します。
Unixでは、WL_HOME/server/binディレクトリから次のコマンドを使用します。
startNodemanager.sh
Windowsでは、サービス・マネージャからノード・マネージャを起動します。
WL_HOME/common/binディレクトリにあるWebLogic Scripting Toolを起動します。ascrscf.dat
ファイルとascrskf.dat
ファイルにノード・マネージャのユーザー・ログイン情報を永続保持するため、次のコマンドを使用します。
nmConnect('nmUser','nmPasswd','hostname','nmPort','domainName','domainDir') storeUserConfig('WL_HOME/common/nodemanager/ascrscf.dat', 'WL_HOME/common/nodemanager/ascrskf.dat','true') nmDisconnect() exit()
Unixプラットフォームでは、CRS_HOME/ascrs/public/cfcStartNodeManager.shをWL_HOME/server/binディレクトリにコピーして、スクリプトを実行可能にします。
注意: 設定を常に同期するため、ノード・マネージャのパスワードやユーザー名を変更するたびにステップ4の操作を実行する必要があります。 |
ノード・マネージャを初めて起動した後で、nodemanager.properties
ファイルを編集してStartScriptEnabled
プロパティを定義できます。nodemanager.properties
ファイルは、ノード・マネージャを初めて起動するまでは存在していません。
WL_HOME/common/nodemanagerディレクトリで、nodemanager.properties
ファイルのStartScriptEnabled
プロパティをtrue
に設定します。
StartScriptEnabled=true
nodemanager.properties
ファイルをチェックして、ListenAddressに値が割り当てられていないことと、ListenPortに有効なポート番号が割り当てられていることを確認します。
このプロパティがnodemanager.properties
ファイルで設定されている場合には、同じプロパティをJAVA_OPTIONS環境変数で定義する必要はなくなります。
サーバーの設定
すべてのWebLogicサーバーは仮想IPでリスニングします。これが適切に構成されていることを確認するには、WebLogic Server管理コンソールにログインし、「環境」→「サーバー」→「server_name」→「構成」→「一般」ページに移動し、仮想IPとポート番号の両方が適切に設定されていることを確認して、「保存」をクリックします。
各サーバーはローカル・ホスト上でもリスニングする必要があります。これが正しく構成されていることを確認するには、WebLogic Server管理コンソールにログインして次の操作を行います。
ドメイン・ツリーで、「環境」→「サーバー」→「server_name」→「プロトコル」→「チャネル」を選択します。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「新規」をクリックしてチャネル名とt3プロトコルを選択し、次の画面に進みます。
「リスニング・アドレス」と「外部リスニング・アドレス」の両方のローカル・ホストを入力します。
「リスニング・ポート」と「外部リスニング・ポート」にポート番号を入力します。このポート番号は仮想IPで使用したポート番号と正確に同じにする必要があります。
次の画面に進んで、「有効」が選択されていることを確認します。
「終了」をクリックします。
「変更のアクティブ化」をクリックします。
これが管理サーバーの場合、DOMAIN_HOME/servers/serverName/securityディレクトリが存在することを確認します。このディレクトリにはboot.properties
ファイルが格納されている必要があります。このファイルが存在しない場合は作成して、次のプロパティを含めます。
username=<admin server user name> password=<admin server user password>
ドメインに管理サーバーがない場合、DOMAIN_HOME/servers/serverName/securityディレクトリが存在することを確認します。このディレクトリにはboot.properties
ファイルが格納されている必要があります。このファイルが存在しない場合は作成して、次のプロパティを含めます。
username=<admin server user name> password=<admin server user password>
DOMAIN_HOME/servers/serverName/data/nodemanager/startup.propertiesが存在する場合は、このファイルで定義されているAutoRestart
プロパティがfalse
に設定されていることを確認します。
すべてのサーバーについて前の手順を繰り返して、管理サーバー・コンソールですべてのサーバーを再起動します。
すべてのWebLogicプロセスを停止して、ノード・マネージャを強制終了します。
注意: 設定を常に同期するため、管理サーバーのパスワードを変更するたびにステップ3の操作を実行する必要があります。 |
リソースの作成
基本設定、ノード・マネージャの設定およびサーバーの設定を実行したら、次のコマンドを使用してCRSリソースを作成します。
ascrsctl create -n mywls -type as -ch /cfcas -disk sharedisk -vip myvip
注意: WebLogicコンポーネントのホーム引数(-ch)は有効である必要があります。この情報を包括的に検証する処理は、ASCRSでは実行されません。 |
注意: デフォルトでは、ASCRSエージェントはサーバーへのTCP接続を定期的に初期化してWebLogic Serverのヘルス・チェックを実行します。この動作を変更する場合は、第13.4.8項「ヘルス・モニターの構成および使用」を参照してください。 |
ascrsctlで作成したリソースは、updateコマンドを使用して更新できます。リソースのタイプに応じて、updateコマンドラインで適切なパラメータを指定することでリソース・プロファイルを更新できます。更新は、リソースがオフラインの状態の場合にのみ実行できます。
たとえば、前述の項で作成した仮想IPリソースを新しいIPアドレスと別のインタフェースで更新するには、次のコマンドを使用します。
ascrsctl update -n myvip -type vip -ip 192.168.1.20 -if eth1
注意: 特定のリソースをホストするノードのセットを変更する場合、すべての依存リソースを停止してそれぞれのリソースが同じノード・セットと順序になるようにクラスタ・ノードを更新する必要があります。関連するリソースを検索するには、このリソースに対してascrsctlのstatusコマンドを実行します。 |
リソースが起動されると、CRSに制御され、実行時の状態がCRSによって継続的に監視されます。リソースが他のリソースに依存する場合、そのリソースを起動すると、依存先のリソースが自動的に起動されます。リソース起動時のリソース配置ポリシーの役割の詳細は、Oracle Clusterwareのドキュメントを参照してください。ascrsctlのstartコマンドはCRSコマンドにマッピングされます。
たとえば、仮想IPリソースを起動するには、次のコマンドを使用します。
ascrsctl start -n ora.myvip.cfcvip
注意: リソースが複数のリソースに依存する場合は、そのリソースの起動時に、それらのリソースがオンラインになった場合、同じノードにターゲット指定されることを確認します。 |
リソースを停止すると、そのリソースはオフライン状態になり、CRSはその実行状態の監視を停止します。そのリソースがオンライン状態の他のリソースに依存している場合、プロンプトで確認するか(-np)オプションを指定しないと依存リソースは停止しません。リソース停止時におけるリソース依存性の影響の詳細は、Oracle Clusterwareのドキュメントを参照してください。ascrsctlのstopコマンドは、CRSコマンドのcrs_stop
にマッピングされます。
たとえば、仮想IPリソースを停止するには、次のコマンドを実行します。
ascrsctl stop -n ora.myvip.cfcvip
リソースのスイッチオーバーは、ノード上で実行しているリソースを停止してから別のノード上で再起動するプロセスです。新しいノードが指定されていない場合、配置ポリシーに基づいてCRSによって決定されます。スイッチ対象リソースが他のリソースに依存している場合や、オンライン状態のリソースがありそれらのリソースがスイッチ対象リソースに依存している場合、-npフラグでこのリソースのスイッチ操作を実行する必要があります。
クラスタ内で利用可能な別のノードにリソースをスイッチオーバーするには、次のコマンドを実行します。
ascrsctl switch -n ora.myvip.cfcvip
リソースをCRSの制御から削除できます。リソースを削除すると、対応するアプリケーションやコンポーネントの機能はCRSの影響を受けなくなり、CRSはそれ以降そのリソースを監視しません。依存リソースを持つリソースは削除できません。
CRSの制御からリソースを削除するには、次のコマンドを実行します。
ascrsctl delete -n ora.myvip.cfcvip
注意: CRSからリソースを削除すると、削除されたリソースのログ・ディレクトリおよびログ・ファイルは自動的には削除されません。今後これらを使用しない場合は、手動で削除する必要があります。ログ・ファイルは、デフォルトでは、ORA_CRS_HOME/ascrs/logディレクトリに格納されます。 |
ascrsctlのstatusコマンドを使用して、リソースのステータスをチェックできます。このコマンドにより、すべてのリソースとその依存リソースの状態を表示できます。特定のリソースを指定してstatusコマンドを実行すると、そのCRSプロファイル、直接的な依存関係や間接的な依存関係、および現在の状態に関する情報が表示されます。
たとえば、リソースのステータスをチェックするには、次のコマンドを実行します。
ascrsctl status -n ora.myvip.cfcvip
この仮想IPリソースがデータベース・リスナー・リソースによって使用されているときに、このリスナー・リソースがデータベース・インスタンス・リソースによって必要とされている場合、次のようなステータス出力に、他のステータス情報とともにすべての依存性情報がツリー構造で表示されます。
Basic information ------------------------+------------------------ Name | ora.myvip.cfcvip Type | Virtual IP Target state | ONLINE Resource state | ONLINE on stajz11 Restart count | 0 Failure count | 0 Hosting members | stajz11, stajz12 ------------------------+------------------------ Common CRS parameters ------------------------+------------------------ Auto start | Yes Check interval | 7 sec Failover delay | 5 sec Failure interval | 50 sec Failure threshold | 5 Restart attempts | 2 Script timeout | 30 sec Start timeout | 30 sec Stop timeout | 30 sec ------------------------+------------------------ Resource specific parameters ------------------------+------------------------ Interface(s) | eth2 Netmask | 255.255.252.0 Virtual IP address | 140.87.27.48 ------------------------+------------------------ Resource dependency tree(s) ------------------------------------------------- ora.mydb.cfcdb | +->ora.mydisk.cfcdisk | +->ora.mylsnr.cfcdblsnr | +->ora.mydisk.cfcdisk | +->ora.myvip.cfcvip ora.myopmn.cfcas | +->ora.mydisk.cfcdisk | +->ora.myvip.cfcvip ora.dbc.cfcdb | +->ora.mydisk.cfcdisk | +->ora.myvip.cfcvip ora.mywls.cfcas | +->ora.mydisk.cfcdisk | +->ora.myvip.cfcvip
リソースのヘルス状態は、CRSの再起動またはフェイルオーバーの決定において最も重要な情報です。ただし、サーバーの実際の状態を正確に特定することは容易な作業ではありません。たとえば、サーバー・プロセスが実行中でも実際にそのサービスが停止している状況があります。この場合、単にWebLogic ServerにTCP pingを実行しても、必ずしも正しい機能状態が通知されることにはなりません。かわりに、ASCRSではユーザー定義のモニターを介してWebLogic Serverの機能状態をチェックする限定的なサポートを提供します。
すべてのモニターはORA_CRS_HOME/ascrs/config/mconfig.xml
で定義されます。次にこのファイルの例を示します。
<monitors> <!-- HTTP code monitor --> <monitor name="http_cm"> <method type="ping" protocol="http" url="/index.html"/> <result type="code" code="200"/> </monitor> <!-- HTTP response content monitor that checks the response of a particular URL --> <monitor name="http_rcm"> <method type="ping" protocol="http" url="/index.html"/> <result type="exact_content" file="/crs/ascrs/public/index_content.txt"/> </monitor> <!-- HTTP response content monitor that checks the desired pattern in any line of the returned content --> <monitor name="http_regex"> <method type="ping" protocol="http" url="/cqi"/> <result type="regex_content"><![CDATA[.+Welcome.+]]></result> </monitor> <!-- WebLogic callout script monitor --> <monitor name="wls_sm"> <method type="script" command="/var/scripts/wlsrv3_checker.sh"/> <result type="code" code="0"/> </monitor> </monitors>
各モニターで、「method」と「result」の両方を定義する必要があります。「method type」は、「ping」または「script」を指定できます。「ping」のメソッドには「http」プロトコルのみがサポートされ、有効なURLを指定する必要があります。「result type」は、「code」、「exact_content」、または「regex_content」のいずれかになります。「http」プロトコルのpingの結果のコードで、想定されるHTTPリターン・コードを参照します。「exact_content」および「regex_content」で、正確な戻り値の内容と想定されるパターンを1行で指定します。
WebLogic Serverのモニターを使用するには、その作成または更新時に-mオプションを指定してモニター名をサーバー名に割り当てる必要があります。
たとえば、WebLogicリソースにAdminServerとwlsappという2つのサーバーがあるとすると、次のコマンドを使用してそのモニターをカスタマイズできます。
ascrsctl create -n mywls -type as -ch /cfcas -disk sharedisk -vip myvip -m AdminServer=http_cm wlsapp=http_rcm
注意: exact_contentメソッドを使用する場合、CRS_HOME/ascrs/bin/mu ユーティリティを使用して想定されるレスポンス・コンテンツのファイルを生成します。ブラウザで保存されるコンテンツは、サーバーから送信されたテキストと正確に一致しない場合がしばしばあるためです。 |
次の2つの例では、ASCRSを使用してFusion Middlewareリソースを管理する方法を示します。
図13-1は、CRSトポロジの例1を示しています。この例では、2ノードのクラスタにOracle HTTP ServerとSOAがインストールされています。Oracle HTTP ServerはOPMNで管理されます。SOAインストールでは、4つのJava EEアプリケーションをホストするWebLogic Serverが稼動します。
前提事項:
動作環境: これは2ノードのLinuxクラスタで、そのメンバーはnode1.company.comとnode2.company.comです。ノード1は1次ノードとして指定され、ノード2はフェイルオーバー・ノードです。両方のノードの/crshomeディレクトリにCRSがインストールされ、起動されています。両方のノードでASCRSがインストールおよび構成されています。
Oracle HTTP Server(Oracleホームおよびインスタンス・ホーム)とWebLogicインストール(SOAサーバーのサーバー・ソフトウェアおよびドメイン・ホーム)用に1台の共有ディスクが割り当てられています。これは/dev/sda1で識別されるSCSIドライブであり、ext2ファイル・システムが格納されています。これは/sharedisk1にマウントされます。この共有ディスクは、他の目的で使用されないことが前提になります。
Oracle HTTP ServerおよびWebLogicは、パブリック・リスニング・アドレスとして仮想IPの192.168.1.10を使用します。各ノードで、仮想IPのバインドでは2つのネットワーク・インタフェース・コントローラのeth0とeth1が利用可能です。ネットマスクは255.255.255.0です。
Oracle HTTP ServerのOracleホームは/sharedisk1/ohsohです。インスタンス・ホームは/sharedisk1/ohinstです。
WebLogic Serverソフトウェアは/sharedisk1/fmwディレクトリにインストールされています。ドメイン・ディレクトリは/sharedisk1/fmw/user_projects/domains/asdomainです。
これらの前提の下で、コールド・フェイルオーバー・クラスタの自動設定について説明します。
次の手順に従って、WebLogicソフトウェアをインストールし、コールド・フェイルオーバー・クラスタを有効にします。
ノード2に共有ディスク/dev/sda1がマウントされていれば、それをアンマウントします。ノード1の/shareddisk1に共有ディスクがマウントされていなければ、それをマウントします。
空のシグネチャ・ファイル.ascrssf
を/shareddisk1に作成します。このファイルを作成するのは、この共有ディスクのマウント後のみです。
/sbin/ifconfigを使用して仮想IPをeth0にバインドします。
SOAおよびOHSを共有ディスクにインストールします。仮想IPを使用して、SOAおよびOHSの両方に対してCFCを有効化する手順を実行します。CFCを有効にしたら、SOAサーバーおよびOHSインスタンスに属するすべてのプロセスをシャットダウンします。CFCの有効化の基本的なチェックを実行するには、ノード1上の共有ディスクをアンマウントしてそれをノード2にマウントし、ノード2でSOAとOHSの起動を試行します。起動に失敗したら、続行する前にそれを修正します。
ステップ3を実行したら、すべてのOHSおよびSOAプロセスをシャットダウンし、ノード2のディスクをアンマウントして、それをノード1にマウントします。
第13.4.1.5.2項「WebLogic Serverのリソースの作成」の手順(リソースの作成手順を除く)に従って、SOAインストール内のWebLogicサーバーをASCRS用に構成します。
任意のOHSおよびSOAプロセスをシャットダウンします。
仮想IPをアンバインドします。
CRSリソースを作成します。
ノード1で、cdコマンドを使用して、/CRS_HOME/ascrs/binディレクトリに移動します。
仮想IPリソースを作成します。
ascrsctl create -n asvip -t vip -if "eth0|eth1" -ip 192.168.1.10 -nm 255.255.255.0
共有ディスク・リソースを作成します。
ascrsctl create -n asdisk -t disk -path /sharedisk1 -mc "/bin/mount /dev/sda1/sharedisk1" -umc "/bin/umount /sharedisk1"
SOA WebLogic Serverリソースを作成します。
ascrsctl create -n soa -t as -vip asvip -disk asdisk -ch /sharedisk1/fmw/user_projects/domains/asdomain
その依存性としてSOAを含むOracle HTTP Serverリソースを作成します。
ascrsctl create -n ohs -t as -vip asvip -disk asdisk -as soa -ch /sharedisk1/ohsinst
ノード1上のすべてのリソースを起動します。Oracle HTP Serverリソースはその他すべてのリソースに依存するため、このリソースを起動すると自動的に他のリソースも起動します。
ascrsctl start -n ora.ohs.cfcas -node node1
図13-2は、CRSトポロジの例2を示しています。このトポロジ例では、次の特性を持つ2ノード構成クラスタに、WebLogic ServerとOracleデータベースがインストールされています。
このクラスタで実行されるWebLogic Serverは、WebLogic管理サーバーのみです。WebLogicソフトウェアとドメイン・ホームは同じ共有ディスク上に配置されています。
管理サーバーおよびOracle Enterprise Managerは、最初のノードを1次ノードとして、WebLogic Java EEコンテナで実行されます。
データベース・ソフトウェアとそのデータファイルは、2番目のノードを1次ノードとして、他の2台の共有ディスクに配置されています。
このトポロジの目的は、WebLogic管理サーバーとデータベース・インスタンスの両方のフェイルオーバー・ソリューションを実現することです。
前提事項:
動作環境: これは2ノードのLinuxクラスタで、そのメンバーはnode1.company.comとnode2.company.comです。ノード1はWebLogic Serverの1次ノードとして指定され、ノード2はこのフェイルオーバー・ノードとなっています。ノード2はOracleデータベースの1次ノードとして指定され、ノード1はこのフェイルオーバー・ノードとなっています。両方のノードの/crshomeディレクトリに、CRSがインストールされ、起動されています。両方のノードでASCRSがインストールおよび構成されています。
3台の共有ディスクが割り当てられています。いずれもSCSIドライブで、それぞれ/dev/sda1、/dev/sda2、/dev/sda3として識別され、ext2ファイル・システムが格納されています。/dev/sda1はWebLogicソフトウェアで使用されます。
ドメイン・ホーム: /dev/sda2はOracleデータベース・ソフトウェアで使用されます。/dev/sda3はデータベース・データファイルで使用されます。それらはそれぞれ、/sharedisk1、/sharedisk2、/sharedisk3にマウントされます。
WebLogic Serverは、パブリック・リスニング・アドレスに仮想IPの192.168.1.10を使用し、リスニング・ポートに7001を使用しています。各ノードで、この仮想IPのバインドでは2つのネットワーク・インタフェース・コントローラのeth0とeth1が利用可能です。
データベース・リスナーは、リスニング・アドレスに仮想IPの192.168.1.20を使用し、リスニング・ポートに1521を使用しています。各ノードで、この仮想IPのバインドにネットワーク・インタフェース・コントローラのeth2を使用します。
両方の仮想IPのネットマスクは255.255.255.0です。
WebLogic Serverは共有ディスクの/sharedisk1/fmwディレクトリにインストールされています。ドメイン・ディレクトリは/sharedisk1/fmw/user_projects/domains/asdomainです。
データベースは共有ディスクの/sharedisk2/dbhomeディレクトリにインストールされており、データファイルは/sharedisk3/dbdataディレクトリに作成されます。ここでは、orclはOracle SID名、LISTENERはリスナー名であることが前提になります。
これらの前提の下で、コールド・フェイルオーバー・クラスタの自動設定について説明します。
WebLogicソフトウェアをインストールしてコールド・フェイルオーバー・クラスタを有効にします。
ノード2に共有ディスク/dev/sda1がマウントされていれば、それをアンマウントします。ノード1の/shareddisk1に共有ディスクがマウントされていなければ、それをマウントします。
空のシグネチャ・ファイル.ascrssf
を/shareddisk1に作成します。このファイルを作成するのは、この共有ディスクのマウント後のみです。
/sbin/ifconfigを使用して仮想IPの192.168.1.10をeth0にバインドします。
WebLogicを共有ディスクにインストールします。この仮想IPを使用して、このインストールにコールド・フェイルオーバー・クラスタの有効化手順を実行します。
ASCRSでのWebLogic Serverの構成の詳細は、第13.4.1.5.2項「WebLogic Serverのリソースの作成」を参照しください。
WebLogic Serverをシャットダウンします。
仮想IPをアンバインドします。
WebLogic関連のリソースを作成します。
ノード1に移動し、cdコマンドを使用して、/CRS_HOME/ascrs/binディレクトリに移動します。
仮想IPリソースを作成します。
ascrsctl create -n asvip -t vip -if "eth0|eth1" -ip 192.168.1.10 -nm 255.255.255.0
共有ディスク・リソースを作成します。
ascrsctl create -n asdisk -t disk -path /sharedisk1 -mc "/bin/mount /dev/sda1 /sharedisk1" -umc "/bin/umount /sharedisk1"
WebLogic Serverリソースを作成します。
ascrsctl create -n adminserver -t as -vip asvip -disk asdisk -ch /sharedisk1/fmw/user_projects/domains/asdomain
ノード1上のすべてのWebLogic関連のリソースを起動します。WebLogicリソースはディスクおよび仮想IPリソースに依存するため、WebLogicリソースを起動すると自動的に他の2つも起動します。
ascrsctl start -n ora.adminserver.cfcas -node node1
Oracleデータベース・ソフトウェアをインストールしてコールド・フェイルオーバー・クラスタを有効にします。
ノード1に共有ディスク/dev/sda2がマウントされていれば、それをアンマウントします。ノード2の/shareddisk2に共有ディスクがマウントされていなければ、それをマウントします。
空のシグネチャ・ファイル.ascrssf
を/shareddisk2に作成します。このファイルを作成するのは、この共有ディスクのマウント後のみです。
ノード1に共有ディスク/dev/sda3がマウントされていれば、それをアンマウントします。ノード2の/shareddisk3に共有ディスクがマウントされていなければ、それをマウントします。
空のシグネチャ・ファイル.ascrssf
を/shareddisk3に作成します。このファイルを作成するのは、この共有ディスクのマウント後のみです。
/sbin/ifconfigを使用して仮想IPの192.168.1.20をeth2にバインドします。
/sharedisk2/dbhomeディレクトリにOracleデータベースをインストールして、データファイルを/sharedisk3/dbdataに配置します。
この仮想IPで、このインストールにCFCの有効化手順を実行します。
データベースをシャットダウンします。
仮想IPをアンバインドします。
Oracleデータベース関連のリソースを作成します。
ノード2で、cdコマンドを使用して、/CRS_HOME/ascrs/binディレクトリに移動します。
仮想IPリソースを作成します。
ascrsctl create -n dbdisk -t disk -path /sharedisk2 -mc "/bin/mount /dev/sda2 /sharedisk2" -umc "/bin/umount /sharedisk2"
データベース・ソフトウェアの共有ディスク・リソースを作成します。
ascrsctl create -n dbdisk -t disk -path /sharedisk2 -mc "/bin/mount /dev/sda2 /sharedisk2" -umc "/bin/umount /sharedisk2"
データベース・データファイルの共有ディスク・リソースを作成します。
ascrsctl create -n dfdisk -t disk -path /sharedisk3 -mc "/bin/mount /dev/sda3 /sharedisk3" -umc "/bin/umount /sharedisk3"
データベース・インスタンス・リソースを作成します。
ascrsctl create -n asdblsnr -t lsnr -vip dbvip -disk dbdisk -loh /sharedisk2/dbhome -ln LISTENER
データベース・リスナー・リソースを作成します。
ascrsctl create -n asdb -t db -lsnr asdblsnr -sid orcl -oh /sharedisk2/dbhome -disk dbdisk dfdisk
ノード2上のすべてのデータベース関連リソースを起動します。データベース・リソースは直接的または間接的にその他すべてのリソースに依存するため、データベース・リソースを起動すると自動的に他のリソースも起動します。
ascrsctl start -n ora.asdb.cfcdb -node node2
この項では、Oracle CRSのトラブルシューティング情報について説明します。
OPMNリソースは仮想IPリソースに依存しますが、作成または更新処理時にASCRSはOPMNインスタンスが依存している仮想IPリソースが実際に存在しているかどうかを検証していません。不正な仮想IPリソースが指定されていると、OPMNリソースは起動に失敗して、OPMNインスタンスは不整合な状態で残ることがあります。この問題を修正するには、次の手順に従ってください。
-f
オプションを使用してOPMNリソースを停止します。
すべての関連リソースが停止していることを確認します。停止していなければ、残りの稼動中のプロセスをすべて手動で停止します。
リソースを正しい仮想IPリソースで更新します。
リソースを起動します。