9 Oracle Clusterwareを使用したアプリケーションの高可用性の実現
クラスタ内でアプリケーション、プロセスまたはサーバーに障害が発生した場合、その影響をユーザーにまったく気付かれないようにすることはできないまでも、できるかぎり短時間に抑える必要があります。たとえば、サーバーでアプリケーションに障害が発生した場合、そのアプリケーションをクラスタ内の別のサーバーで再起動して、そのアプリケーションの使用に対する影響を最小限にするか、またはなくしてしまうことができることを意味します。同様に、クラスタ内のサーバーで障害が発生した場合、そのサーバーで実行されているすべてのアプリケーションおよびプロセスを別のサーバーにフェイルオーバーして、ユーザーへのサービスの提供を継続できる必要があります。Oracle Clusterwareでは、組込みのgeneric_application
リソース・タイプまたはカスタマイズ可能なスクリプトおよびアプリケーション・エージェント・プログラムと、アプリケーションとプロセスに割り当てられるリソース属性を使用することで、これらすべてのエンティティを管理し、高可用性を確保します。
この章では、Oracle Clusterwareを使用して、アプリケーションの起動、停止、監視、再起動および再配置を行う方法について説明します。Oracle Clusterwareは、Oracle Real Application Clusters(Oracle RAC)の基礎となるクラスタ・ソリューションです。Oracle RACデータベースを管理する場合と同じ機能および方針がアプリケーションの管理に適用されます。
この章の内容は次のとおりです。
9.1 Oracle Clusterwareリソースおよびエージェント
この項では、アプリケーションの高可用性を確保するために、Oracle Clusterwareでリソースの監視および管理に使用されるフレームワークについて説明します。
この項には次のトピックが含まれます:
9.1.1 Oracle Clusterwareのリソース
Oracle Clusterwareでは、アプリケーションおよびプロセスはOracle Clusterwareに登録するリソースとして管理されます。
アプリケーションを管理するためにOracle Clusterwareに登録するリソースの数は、アプリケーションによって異なります。1つのプロセスでのみ構成されるアプリケーションは、ほとんどの場合、1つのリソースでのみ表されます。複数のプロセスまたはコンポーネントに基づいて構築されたより複雑なアプリケーションでは、複数のリソースが必要となる可能性があり、このような場合はリソース・グループを作成できます。
各リソースは、テンプレートとして機能するリソース・タイプに基づいています。明示的なサーバー・リストを指定したり、サーバー・プールやポリシーなどの機能を使用することによって、Oracle Clusterwareでのアプリケーションのクラスタ内への配置方法を構成できます。アプリケーションとコンポーネントの間の関係は、依存性を使用して表されます。Oracle Clusterwareはリソースに対して操作を実行することによりアプリケーションを管理し、リソースの状態はアプリケーションの可用性を表します。
Oracle Clusterwareのリソースとしてアプリケーションを登録する場合は、実際にリソースをシステムに追加するだけでなく、リソースの特徴を示すリソース属性を使用してOracle Clusterwareでのアプリケーションの管理方法を定義します。リソース属性の例としては、リソースのチェック頻度、障害が発生してから別のサーバーで起動が試行される(フェイルオーバー)までの間に同じサーバーでリソースの再起動が試行される回数などがあります。また、登録情報には、アクション・スクリプトへのパス、またはアプリケーションの起動、停止、チェックおよびクリーンアップを実行するためにOracle Clusterwareによってコールされるアプリケーション固有のアクション・プログラムも含まれています。
アクション・スクリプトは、Oracle Clusterwareで提供されている汎用スクリプト・エージェントがコールするシェル・スクリプト(Windowsのバッチ・スクリプト)です。アプリケーション固有のエージェントは、ほとんどの場合、Oracle Clusterwareで提供されているAPIを直接コールするCまたはC++プログラムです。
クリティカル・リソース
リソース・グループとしてモデル化された一部の大規模なエンタープライズ・アプリケーションには、アプリケーションやインフラストラクチャのコンポーネントを表す複数のリソースが含まれることがあります。リソース・グループ内のいずれかのリソースに障害が発生した場合、Oracle Clusterwareはリソース・グループ全体をクラスタ内の別のサーバーにフェイルオーバーする必要があります。
リソース・グループのCRITICAL_RESOURCES属性内にリソースの名前を指定することによって、あるリソースをそのリソース・グループのクリティカル・リソースとしてマークできます。
9.1.1.1 仮想マシンのリソース
仮想マシンは、ゲスト・オペレーティング・システムと呼ばれる稼働中のオペレーティング・システム用に作成された環境です。仮想マシンは、コンピュータのデスクトップにウィンドウとして表示され、このウィンドウは全画面モードで表示することも、別のコンピュータ上にリモートで表示することもできます。
仮想マシンは基本的に、その動作を決定するパラメータのセットであり、コンピュータ・システム・ハードウェアと似ています。パラメータには、ハードウェア設定(仮想マシンのメモリー量など)や状態情報(仮想マシンが現在実行中かどうかなど)が含まれます。
ブラックボックス仮想マシンは、その内容が管理インタフェースに認識されない仮想マシンです。ブラックボックス仮想マシンについて認識される情報は、それに含まれる仮想ハードウェア、CPUの数、RAMの量、接続されたディスク、および接続されたネットワーク・インタフェースのみです。ただし、ハードウェアの内容は認識されません。たとえば、多数のディスクが接続されていたとしても、それらにどのオペレーティング・システムがインストールされているか、またネットワーク・カードが構成されているかどうかについては認識されません。
Oracle Clusterwareを使用して物理ハードウェア上のブラックボックスOracle仮想マシンを管理すると、可用性が向上し、仮想マシンの管理が容易になります。
注意:
これは仮想マシンに限定されることであり、Oracle VM VirtualBoxやその他のOracle VM製品には該当しません。たとえば、次の図では、2つの物理コンピュータがあり、それぞれで複数の仮想マシンが実行されています。各物理ホストに対するコンピュータの1つが、Oracle Grid Infrastructure仮想マシン(GIVM)です。
GIVM自体が1つのOracle Clusterwareクラスタを構成し、このクラスタ内に4つのブラックボックス仮想マシンOracle Clusterwareリソースがあって、それぞれがGIVM以外の仮想マシンの1つを監視しています。監視対象の仮想マシンはブラックボックス仮想マシンであるため、クラスタはこれらの仮想マシンの内容を認識しません。この例では、物理ホストの1つが停止した場合、そのGIVMも停止し、そのGIVMがクラスタから離脱します。これにより、リソースは他のGIVMにフェイルオーバーされ、新しい物理ホスト上でブラックボックス仮想マシンが起動されます。
仮想マシン・アーキテクチャ
Oracle仮想マシンは、仮想マシン・サーバーと仮想マシン・マネージャの2つの部分で構成されます。仮想マシン・サーバーは、Xenハイパーバイザを使用してゲストを管理するベア・ハードウェアにインストールされた最小オペレーティング・システムです。サーバーには、仲介役となるOracle仮想マシン・エージェントというエージェント・プロセスがあり、仮想マシン・マネージャはこれを介してサーバー上のドメインを操作します。
仮想マシン・マネージャは、仮想マシン・サーバーおよびその仮想マシンの管理に使用されるWebベースの管理コンソールです。仮想マシン・マネージャを実行するにはデータベースおよびOracle WebLogic Serverが必要であり、Oracle仮想マシン・サーバーのOracleサポート管理にはこの仮想マシン・マネージャが必要です。管理ドメインはできるだけ小さくする必要があるため、仮想マシン・マネージャをそこにインストールすることはできません。仮想マシン・マネージャは別のホストにインストールする必要があります。つまり、別の物理コンピュータを用意するか、Xen xm
コマンドを使用して一時的な仮想マシンを手動で作成します。
Oracle仮想マシン・マネージャは、仮想マシンを管理するための唯一のインタフェースです。すべてのAPIおよびユーティリティを含むすべてのリクエストは、これを介して転送されます。
仮想マシン・リソース(Oracle Clusterwareリソース)のリソース・タイプは、次のようになります。
ATTRIBUTE=DESCRIPTION
TYPE=string
DEFAULT_VALUE="Resource type for VM Agents"
ATTRIBUTE=AGENT_FILENAME
TYPE=string
DEFAULT_VALUE=%CRS_HOME%/bin/oraagent%CRS_EXE_SUFFIX%
ATTRIBUTE=CHECK_INTERVAL
DEFAULT_VALUE=1
TYPE=int
ATTRIBUTE=OVMM_VM_ID
TYPE=string
DEFAULT_VALUE=''
ATTRIBUTE=OVMM_VM_NAME
TYPE=string
DEFAULT_VALUE=''
ATTRIBUTE=VM
TYPE=strings
9.1.1.2 リソース・グループ
リソース・グループは、論理的に関連したリソースのグループのコンテナです。
アプリケーションは、アプリケーション・リソースと関連アプリケーション・リソース(WebServerなど)、およびインフラストラクチャ・リソース(ディスク・グループやVIPなど)を含むリソース・グループとしてモデル化されます。リソース・グループは、すべてのアプリケーション・クラスの高可用性モデリングのための論理的で直感的なエンティティを提供します。
CRSCTLを使用してリソース・グループを作成し、リソースをそのリソース・グループに追加します。リソース・グループは、ネーミング、説明および一般的な配置に対応する属性セットと、リソース・グループのメンバーであるリソースのフェイルオーバー・パラメータ値を提供します。
リソース・グループの原則
-
リソース・グループは、リソース・グループ・タイプに基づいて作成します。
-
リソースがメンバーになれるリソース・グループは、1つのみです。リソースを作成するときに、リソースにリソース・グループを指定できます。
リソースの作成時にリソース・グループを指定しない場合、リソースは、そのリソースに作成された自動リソース・グループのメンバーになります。後でリソースを別のリソース・グループに追加できます。
-
リソース・グループはクリティカル・リソースを認識し、リソース・グループの状態はそのクリティカル・リソースの状態によってのみ決まります。
クリティカルでないリソースはリソース・グループから削除でき(依存性チェックに従う)、後で別のリソース・グループに追加することもできます。
-
リソース・グループには、クラスタ内で同時に実行できるリソース・グループのインスタンス数を指定するためのカーディナリティがあります。
-
稼働中のリソース・グループ・インスタンスのすべてのメンバー・リソースは、同じサーバーに配置されます。
-
Oracle Clusterwareは、障害発生時にリソース・グループを再起動し、ローカルな再起動が失敗した場合にはリソース・グループを別のサーバーに再配置します。
自動リソース・グループ
リソース・グループを指定せずにリソースを作成した場合、Oracle Clusterwareによって暗黙的かつ自動的にリソースと同名のリソース・グループにリソースが追加されます。
自動リソース・グループは、リソース・グループに明示的に追加されていないリソースそれぞれに対して作成されます。リソース・グループを使用せずにリソースを作成しても、問題なくOracle Clusterwareを使用できます。ただし、リソース・グループを使用すると、SRVMや他の既存のユーティリティにより作成された(自動リソース・グループを介する)インフラストラクチャおよびアプリケーション・リソースの関係を定義できます。
リソースに対して作成された自動リソース・グループは、そのリソースによってのみ記述され、管理者が変更することはできません。リソース・グループを指定せずに作成したリソースは、後でリソース・グループに追加できます。リソースが明示的にリソース・グループに追加された場合、Oracle Clusterwareはそのリソースが属する自動リソース・グループを削除します。
リソース・グループ管理
-
リソースを作成するときに、リソースをリソース・グループに追加できます。
-
自動リソース・グループに属するリソースを別のグループに明示的に追加できます。ONLINEまたはOFFLINEのどちらのグループにリソースを追加する場合も、リソースはOFFLINEである必要があります。
-
クリティカルでないリソースは、リソース・グループ内の他のリソースがそれに依存していないかぎりは、リソース・グループ(OFFLINEまたはONLINE)から削除できます。この場合、削除したリソースは、その自動リソース・グループのメンバーとなります。後で、このリソースを別のグループに追加できます。
-
クリティカルでないリソースを削除することによって、そのリソースをリソース・グループから削除し、Oracle Clusterwareから削除できます。リソース・グループのクリティカル・リソースは、まずリソース・グループのクリティカル・リソース・リストを更新してリソースのクリティカルのマークを解除しないかぎり、削除できません。
-
リソース・グループは、作成された当初は空で、グループ内の各リソースが削除されたときにも空になります。空のリソース・グループは起動できず、その状態は常にOFFLINEになります。
リソースの共有
様々なOracle Clusterwareデプロイメントにおいては、複数のアプリケーションにより共有されるコンポーネント(ファイル・システムなど)が存在します。たとえば、1つのOracle ACFSリソースを、ファイルシステムを活用する複数のリソース・グループのメンバーにすることはできません。定義上、リソースがメンバーになれるリソース・グループは1つのみであるためです。
これらのタイプのリソースについては、明示的または自動的にそれぞれ個別のリソース・グループに配置し、アプリケーション・リソース・グループからこれらの共有リソース・グループへの適切な依存性を構成することをお薦めします。この方法で、複数のアプリケーションはコンポーネントを共有できます。
クリティカル・リソース
リソース・グループとしてモデル化された大規模なエンタープライズ・タイプ・アプリケーションには、アプリケーションやインフラストラクチャのコンポーネントに対応する複数のリソースが含まれることがあります。このようなリソース・グループ内のリソースのいずれかに障害が発生した場合、Oracle Clusterwareはリソース・グループ全体をクラスタ内の別のサーバーにフェイルオーバーします。ただし、リソース・グループにはアプリケーションにクリティカルでないリソースも含まれ、そのようなリソースのために、インスタンスの実行を不必要に中断させるようなリソース・グループ全体のフェイルオーバーが必要になるとはかぎりません。
リソース・グループ内の特定のリソースをクリティカルとして定義できます(これには、リソース・グループのCRITICAL_RESOURCESリスト属性内にリソース名を指定します)。これらのリソースのいずれかに障害が発生した場合、Oracle Clusterwareはリソース・グループをクラスタ内の別のサーバーにフェイルオーバーします。
さらに、リソース・グループの状態はそのクリティカル・リソースの状態によってのみ決まります。クリティカルでないリソースがリソース・グループの状態に影響することはなく、リソース・グループのフェイルオーバーをトリガーすることもありません。リソース・グループを起動してオンラインにするには、リソース・グループに1つ以上のクリティカル・リソースが含まれている必要があります。
リソース・グループ内の個々のリソースをクリティカルとして指定することも、リソース・タイプをクリティカルとして指定して、その特定タイプのすべてのリソースをクリティカルにすることもできます。次に例を示します。
CRITICAL_RESOURCES="r1 r2 r3"
前述の例では、空白で区切られた3つのリソースがクリティカルとしてマークされています。
CRITICAL_RESOURCES="appvip type:ora.export.type"
前述の例では、特定のリソース・タイプがクリティカルとして指定されているため、このタイプのリソースがすべてクリティカル・リソースとなります。
リソース・グループを作成したとき、またはそのメンバーを削除したとき、リソース・グループは空であり、したがってクリティカル・リソースは存在しません。リソース・グループのCRITICAL_RESOURCES属性内にリソース・タイプを指定していないかぎり、リソース・グループに追加した最初のリソースが、Oracle Clusterwareによって自動的にクリティカルとしてマークされます。Oracle Clusterwareは、リソース・グループを起動する前に、常に、クリティカル・リソースの存在を確認します。
リソース・グループの権限
リソース・グループおよびリソース・グループ・タイプを作成した後、リソースを作成してこれらのグループに追加できます。また、リソース・グループのACL属性を使用して、リソース・グループに対する変更権限および操作の実行権限を定義することもできます。また、リソース・グループ所有者は、リソース・グループのACL属性を適切に設定することにより、他のオペレーティング・システム・ユーザーに権限を割り当てることができます。リソース・グループ内のリソースは、そのACL属性内に指定された自身の権限指定を維持できます。具体的には、次のようになります。
-
リソース・グループに対する書込み権限およびリソースに対する書込み権限を持つユーザーは、リソースをグループに追加できます。
-
リソース・グループの所有者は常に、グループ内のすべてのリソースに対する実行権限を持ちます。グループに対する実行権限を付与されたユーザーまたはグループはいずれも、そのグループ内のすべてのリソースに対する実行権限を持ちます。
たとえば、リソース・グループ内の特定のインフラストラクチャ・リソースを
root
によって管理する必要がある場合、リソースの所有者をroot
として指定し、リソースに対する実行権限をグループ所有者に付与する必要があります。これは、root
ユーザーが明示的に行う必要があります。 -
ローカル管理ユーザー(UNIXでは
root
、Windowsでは管理者グループ・ユーザー)は、任意のリソース・グループを変更、削除、起動および停止できます。
リソース・グループの依存性
リソース・グループ間の依存性を設定することにより、アプリケーションとコンポーネントの間の関係を表すことができます。Oracle Clusterwareには、リソース・グループ間の依存性の様々な順序、場所および強制レベルを指定する修飾子が用意されています。リソース・グループの依存性に関して、次のことを考慮する必要があります。
-
リソース・グループは、別のリソース・グループとの依存関係を持つことはできますが、個々のリソースとの依存関係を持つことはできません。
-
明示的に作成されたリソース・グループは、自動リソース・グループとの依存関係を持つことができます。
-
グループ内のリソースは、同じグループ内の別のリソース・グループとの依存関係を持つことができます。
-
リソース・グループを指定せずに作成した(そのために自動リソース・グループに属する)リソースは、別のリソース・グループとの依存関係を持つことができます。
-
リソースがリソース・グループとの依存関係を持ったり、別のリソース・グループ内のリソースとの依存関係を持つことはできません。
Oracle Clusterwareリソースの使用可能な依存性はすべて、リソース・グループでも使用可能です。リソース・グループの依存性を指定するには、リソース・グループのSTART_DEPENDENCIESおよびSTOP_DEPENDENCIES属性を構成します。
表9-1 リソース・グループの依存性のタイプおよび修飾子
依存性のタイプ | 説明 |
---|---|
hard起動 |
このリソース・グループを起動する前に特定の他のリソース・グループが(クラスタ内のどこかで)オンラインになっている必要があるという要件を指定します。 次に例を示します。
いずれかの依存リソース・グループの起動に失敗すると、Oracle Clusterwareはこのリソース・グループの起動を中断します。 |
weak起動 |
このリソース・グループの起動前に特定の他のリソース・グループの起動を試行する必要があるという要件を指定します。特定の他のリソース・グループの起動に失敗した場合でも、Oracle Clusterwareによってこのリソース・グループが起動されます。 次に例を示します。
|
pullup |
依存リソース・グループの起動時にこのリソース・グループを自動的に起動する必要がある場合は、この依存性を使用します。 次に例を示します。
リソース・グループ間に停止依存性が存在する場合には、この依存性を使用することをお薦めします。 |
hard停止 |
この依存性は、特定の他のリソース・グループが実行を停止したときにこのリソース・グループを停止するという必須要件を指定します。 次に例を示します。
|
attraction |
特定の他のリソース・グループとの共存を優先することを指定します。 次に例を示します。
Oracle Clusterwareは、特定の他のリソース・グループがすでにオンラインになっている同じサーバー上で、このリソース・グループの起動を試行します。 |
dispersion |
特定の他のリソース・グループとの非共存を優先することを指定します。Oracle Clusterwareは、dispersion依存性を持つオンライン・リソース・グループの数が最も少ないサーバー上で、このリソース・グループの起動を試行します。 次に例を示します。
|
exclusion |
このリソース・グループを特定の他のリソース・グループと同じサーバー上で実行しないことを必須要件として指定します。Oracle Clusterwareは、このリソース・グループの起動を拒否するか、依存リソース・グループを停止して別のサーバー上で再起動します。 次に例を示します。
|
リソース・グループの障害とリカバリ
前述のように、クリティカル・リソースによってリソース・グループの状態とフェイルオーバーが決まります。
クリティカル・リソースの障害とリカバリ
-
リソース・グループのクリティカル・リソースに障害が発生すると、リソース・グループは即時にOFFLINE状態に移行します。
-
Oracle Clusterwareは、RESTART_ATTEMPTSおよびUPTIME_THRESHOLDリソース属性に従って、障害の発生したクリティカル・リソースのローカル再起動を試行します。
-
Oracle Clusterwareは、障害が発生したリソースに対する停止依存性を持つ同グループ内の他のリソースに対して即時チェック・アクションを開始します。
-
Oracle Clusterwareは、このリソース・グループに依存する他のリソース・グループに対して即時チェック・アクションを開始します。
-
リソースが正常に再起動された場合、リソース・グループはONLINE状態に移行し、Oracle Clusterwareはリソース・グループ内およびリソース・グループ間のpullup依存性評価を実行します。
-
Oracle Clusterwareがリソースのすべてのローカル再起動試行数に達した場合、Oracle Clusterwareはリソース・グループ全体を停止します。また、Oracle Clusterwareは、リソース・グループに対する停止依存性を持つ他のリソース・グループも即時に停止します。Oracle Clusterwareは、リソース・グループのローカル再起動を試行します(そのように構成されている場合)。すべての再起動試行数に達した場合、リソース・グループはクラスタ内の別のサーバーにフェイルオーバーします。
クリティカルでないリソースの障害とリカバリ
-
リソース・グループ内のクリティカルでないリソースに障害が発生した場合、Oracle Clusterwareは、RESTART_ATTEMPTSおよびUPTIME_THRESHOLDリソース属性の値に従って、障害の発生したクリティカル・リソースのローカル再起動を試行します。クリティカルでないリソースに障害が発生した場合、リソース・グループの状態に対する影響はありません。
-
Oracle Clusterwareは、障害が発生したリソースに対する停止依存性を持つ同グループ内の他のリソースに対して即時チェック・アクションを開始します。
-
リソースが正常に再起動された場合、Oracle Clusterwareはpullup依存性評価および対応する起動アクションを実行します。
-
Oracle Clusterwareがリソースのすべてのローカル再起動試行数に達した場合、リソース・グループの状態への影響はありません。障害の原因を修正した後、クリティカルでないリソースを明示的に起動する必要があります。
関連トピック
9.1.1.2.1 リソース・グループ・タイプ
Oracle Clusterwareにおいて、リソース・タイプはリソースのクラス用のテンプレートです。
リソース・グループ・タイプは、すべてのリソース・グループに共通に適用できる属性セットを提供します。リソース・グループの作成時に、リソース・グループ・タイプを指定する必要があります。Oracle Clusterwareには、2つのベース・リソース・グループ・タイプ(local_resource_group
およびcluster_resource_group
)が用意されています。ベース・リソース・タイプの属性はリソースと似ており、その一部は構成可能です。
ローカル・リソース・グループ・タイプ
ローカル・リソースのみを含むリソース・グループを作成する場合は、local_resource_group
タイプを使用します。このタイプのリソース・グループのインスタンスは、クラスタ内の各ノードで実行できます。ローカル・リソース・グループ・タイプの属性は次のとおりです。
- NAME
- DESCRIPTION
- ACL
- AUTO_START
- CRITICAL_RESOURCES
- DEBUG
- ENABLED
- INTERNAL_STATE
- RESOURCE_LIST
- RESTART_ATTEMPTS
- SERVER_CATEGORY
- START_DEPENDENCIES
- STOP_DEPENDENCIES
- STATE
- STATE_DETAILS
- UPTIME_THRESHOLD
クラスタ・リソース・グループ・タイプ
タイプcluster_resource_group
のリソース・グループには、クラスタ内の静的または動的なサーバー・セット上で実行される1つ以上のインスタンスを含めることができます。このようなリソース・グループは、グループの配置ポリシーに従って、クラスタ内の別のサーバーにフェイルオーバーできます。クラスタ・リソース・グループ・タイプの属性は次のとおりです。
- NAME
- DESCRIPTION
- ACL
- ACTIVE_PLACEMENT
- AUTO_START
- CARDINALITY
- CRITICAL_RESOURCES
- DEBUG
- ENABLED
- FAILURE_INTERVAL
- FAILURE_THRESHOLD
- HOSTING_MEMBERS
- INTERNAL_STATE
- PLACEMENT
- RESOURCE_LIST
- RESTART_ATTEMPTS
- SERVER_CATEGORY
- SERVER_POOLS
- START_DEPENDENCIES
- STOP_DEPENDENCIES
- STATE
- STATE_DETAILS
- UPTIME_THRESHOLD
9.1.2 Oracle Clusterwareのリソース・タイプ
通常、すべてのリソースは一意ですが、共通属性を持つリソースもあります。Oracle Clusterwareでは、これらの類似リソースの編成にリソース・タイプが使用されます。リソース・タイプのメリットは次のとおりです。
-
必要なリソース属性のみの管理
-
リソース・タイプに基づくすべてのリソースの管理
Oracle Clusterwareに登録するすべてのリソースには、特定のリソース・タイプが必要です。Oracle Clusterware制御(CRSCTL)ユーティリティを使用して、Oracle Clusterwareに含まれているリソース・タイプに加えて、カスタム・リソース・タイプを定義できます。含まれているリソース・タイプは次のとおりです。
-
ローカル・リソース: ローカル・リソースのインスタンス(タイプ名は
local_resource
)は、クラスタの各サーバーで実行されるか(デフォルト)、または特定のサーバー・カテゴリに属しているサーバーで実行されるように制限できます。サーバーをクラスタに追加すると、Oracle Clusterwareではローカル・リソースが自動的に拡張され、インスタンスは新しいサーバーに関連付けられます。サーバーをクラスタから削除すると、Oracle Clusterwareでは、削除するサーバーで実行されていたローカル・リソースのインスタンスが自動的に削除されます。ローカル・リソースのインスタンスは、対応するサーバーに固定されており、あるサーバーから別のサーバーにフェイルオーバーされることはありません。 -
クラスタ・リソース: タイプ名が
cluster_resource
のクラスタ対応リソース・タイプで、クラスタ環境を認識し、カーディナリティおよびサーバー間のスイッチオーバーとフェイルオーバーの対象となります。 -
汎用的なアプリケーション: このリソース・タイプ(タイプ名は
generic_application
)を使用すると、スクリプトを追加しなくても汎用的なアプリケーションを保護できます。アプリケーションの高可用性は、リソースをgeneric_application
リソース・タイプで定義し、リソースの重要な属性に価値を提供することで実現されます。generic_application
リソース・タイプは、cluster_resource
リソース・タイプから取得されるため、generic_application
リソース・タイプのすべてのリソースは、クラスタ対応のリソースです。属性は次のとおりです。-
START_PROGRAM
: アプリケーションを起動する実行可能ファイルの完全なパスで、適切なすべての引数が含まれています。実行可能ファイルは、Oracle Grid Infrastructureを構成してアプリケーションを実行する各サーバーに存在する必要があります。この属性は必須です。次に例を示します。/opt/my_app –start
また、実行可能ファイルは、アプリケーションが正常に起動してオンラインになっていることを示すために、アプリケーションが起動したらゼロ(0)の終了ステータス値を返すことを確認する必要もあります。実行可能ファイルがアプリケーションの起動に失敗した場合、実行可能ファイルは、ゼロ以外のステータス・コードで終了します。
-
STOP_PROGRAM
: アプリケーションを停止する実行可能ファイルの完全なパスで、適切なすべての引数が含まれています。実行可能ファイルは、Oracle Grid Infrastructureを構成してアプリケーションを実行する各サーバーに存在する必要があります。属性値を指定しない場合、Oracle Clusterwareは、オペレーティング・システムのkill
に相当するコマンドを使用します。次に例を示します。/opt/my_app –stop
また、実行可能ファイルは、アプリケーションが正常に停止したことを示すために、アプリケーションが停止したらゼロ(0)の終了ステータス値を戻すことを確認する必要もあります。実行可能ファイルがアプリケーションの停止に失敗した場合、実行可能ファイルは、ゼロ以外のステータス・コードで終了し、Oracle Clusterwareはリソースのクリーンアップを開始します。
-
CLEAN_PROGRAM
: アプリケーションをクリーンアップする実行可能ファイルの完全なパスで、適切なすべての引数が含まれています。実行可能ファイルは、Oracle Grid Infrastructureを構成してアプリケーションを実行する各サーバーに存在する必要があります。この属性に値を指定しない場合、Oracle Clusterwareは、オペレーティング・システムのkill -9
に相当するコマンドを使用します。次に例を示します。/opt/my_app –clean
注意:
STOP_PROGRAM
およびCLEAN_PROGRAM
との違いは、CLEAN_PROGRAM
は、アプリケーションを不正に停止する強制停止で、アプリケーションをいつでも停止できる必要があり、停止できない場合はアプリケーションが管理不能になります。 -
PID_FILES
: アプリケーションによって記述される、ファイルへの完全なパスのカンマ区切りのリストで、監視するためのプロセスID(PID)を含みます。プロセスに1回でも障害が起きると、完全なリソース障害として取り扱われます。次に例を示します。/opt/app.pid
注意:
PID_FILES
属性で指定するファイルは、STARTアクションが完了し、ファイルにリストされているPIDの監視が開始された直後に読み込まれます。 -
EXECUTABLE_NAMES
: 実行可能ファイルの名前のカンマ区切りのリストで、これは、アプリケーションが起動し、その後実行可能ファイルの状態が監視されると作成されます。実行可能ファイルに1回でも障害が起きると、完全なリソース障害として取り扱われます。次に例を示します。my_app
注意:
実行可能ファイルの完全な名前のみを指定する必要があります。この属性は実行可能ファイルまたはワイルド・カードのパスを受け入れません。STARTアクションが完了した後すぐに、実行可能ファイル名に一致するPIDがキャッシュされます。
-
CHECK_PROGRAMS
: 実行可能ファイルへの完全なパスのリストで、アプリケーションの状態を判断します。いずれのアプリケーションでも動作していない状態がレポートされると、リソース全体の障害として取り扱われます。次に例を示します。/opt/my_app –check
-
ENVIRONMENT_FILE
: アプリケーションの起動時にソースへの環境変数を含んでいるファイルへの完全なパスです。ファイルは、1行に1つのname=value
のペアを含んでいるテキスト・ファイルである必要があります。次に例を示します。/opt/my_app.env
-
ENVIRONMENT_VARS
: アプリケーションの起動時の環境に含まれるname=name
のペアのカンマ区切りのリストです。次に例を示します。USE_FILES=No, AUTO_START=Yes
-
SEND_OUTPUT_ALWAYS
: この属性は、STDOUTに送られるアプリケーション出力を送り、表示する役割を果たします。値が0の場合、アクションが失敗しないかぎり、いずれのアプリケーション出力も表示されません。アクションが失敗すると、エージェントによって保存されたアプリケーション出力が表示されます。値が0より大きい場合、すべてのアプリケーション出力を表示します。デフォルトの値は0。次に例を示します。SEND_OUTPUT_ALWAYS=1
注意:
STOP_PROGRAM
、CHECK_PROGRAMS
およびCLEAN_PROGRAM
属性を指定しない場合、PID_FILES
またはEXECUTABLE_NAMES
のいずれかを指定する必要があり、これを行わない場合は、Oracle Clusterwareでこのタイプのリソースを登録することはできません。すべての属性を指定する場合、次のルールが適用されます。
-
リソースを停止する場合、
STOP_PROGRAM
を指定すると、Oracle ClusterwareはSTOP_PROGRAM
をコールします。それ以外の場合では、Oracle Clusterwareは、PID_FILES
またはEXECUTABLE_NAMES
属性のいずれかから取得されたPIDでオペレーティング・システムのkill -9
に相当するコマンドを使用します。 -
アプリケーションの現在の状態を確立する必要がある場合、
CHECK_PROGRAMS
を指定すると、Oracle ClusterwareはCHECK_PROGRAMS
をコールします。それ以外の場合では、Oracle Clusterwareは、PID_FILES
またはEXECUTABLE_NAMES
属性のいずれかから取得されたPIDでオペレーティング・システムのps -p
に相当するコマンドを使用します。 -
リソースをクリーンアップする場合、
CLEAN_PROGRAM
を指定すると、Oracle ClusterwareはCLEAN_PROGRAM
をコールします。それ以外の場合では、Oracle Clusterwareは、PID_FILES
またはEXECUTABLE_NAMES
属性のいずれかから取得されたPIDでオペレーティング・システムのkill -9
に相当するコマンドを使用します。
-
9.1.3 Oracle Clusterwareのエージェント
Oracle Clusterwareでは、リソース固有のすべてのコマンドはエージェントと呼ばれるエンティティを介して実行されます。
注意:
セキュリティを強化し、管理業務をさらに分離するために、Oracle ClusterwareエージェントはSYSRAC管理権限で実行されるようになり、SYSDBA管理権限は不要になりました。SYSRAC管理権限は、SRVCTLなどのOracle RACユーティリティにかわってOracle Clusterwareエージェントによってデータベースに接続するためのデフォルト・モードであり、これによりOracle RACデータベース・クラスタの日常の管理にデータベースへのSYSDBA接続は不要になりました。エージェントは、リソースを管理するためのエージェント・フレームワークおよびユーザー・コードを含むプロセスです。エージェント・フレームワークは、アプリケーション固有のコードを組み込んで、カスタマイズされたアプリケーションを管理できるライブラリです。アプリケーションの起動、停止、状態のチェックなど、実際のアプリケーション管理機能のすべてをエージェントにプログラムします。これらの機能はエントリ・ポイントと呼ばれます。
Oracle Clusterwareにかわって、エージェント・フレームワークによりこれらのエントリ・ポイント機能が起動されます。エージェントの開発者は、これらのエントリ・ポイントを使用して、リソースの起動、停止および監視方法に関する、機能を特定のリソースに必要な機能を組み込むことができます。エージェントで複数のリソースを管理できます。
エージェントの開発者は、コードへのコールバックとして次のエントリ・ポイントを設定できます。
-
ABORT: エージェント・フレームワークでは、他のエントリ・ポイントがハングした場合にABORTエントリ・ポイントがコールされ、進行中のアクションを停止します。エージェントの開発者によって停止機能が指定されていない場合、エージェント・フレームワークによってエージェント・プログラムが終了します。
-
ACTION: ACTIONエントリ・ポイントは、カスタム・アクションが
crsctl request actionコマンドの
clscrs_request_actionAPIを使用して起動されたときに起動されます。
-
CHECK: CHECK (モニター)エントリ・ポイントは、リソースの状態をモニターします。エージェント・フレームワークでは、このエントリ・ポイントが定期的にコールされます。エージェント・フレームワークでは、このアクションで状態変更が検出されると、特定のリソースの状態における変更についてOracle Clusterwareに通知が行われます。
-
CLEAN: CLEANエントリ・ポイントは、リソースのクリーンアップが必要な場合に機能します。ユーザーがリソースを強制終了する必要がある場合に起動される操作で、正常な場合の操作ではありません。このコマンドによってリソース固有の環境がクリーンアップされ、リソースを再起動できます。
-
DELETE: DELETEエントリ・ポイントは、リソースが未登録のときにリソースを実行できるすべてのノードで起動されます。
-
MODIFY: MODIFYエントリ・ポイントは、リソース・プロファイルが変更されているときにリソースを実行できるすべてのノードで起動されます。
-
START: STARTエントリ・ポイントは、リソースをオンラインにします。エージェント・フレームワークでは、Oracle Clusterwareからstartコマンドを受信するたびにこのエントリ・ポイントがコールされます。
-
STOP: STOPエントリ・ポイントは、リソースを正常に停止します。エージェント・フレームワークでは、Oracle Clusterwareからstopコマンドを受信するたびにこのエントリ・ポイントがコールされます。
START、STOP、CHECKおよびCLEANエントリ・ポイントは必須であり、エージェントの開発者はエージェントの作成時にこれらのエントリ・ポイントを指定する必要があります。エージェントの開発者には、C、C++、スクリプトの使用を含め、これらのエントリ・ポイントを実装するいくつかのオプションがあります。CまたはC++とスクリプト・タイプのエントリ・ポイントの両方を使用するエージェントを開発することもできます。エージェント・フレームワークの初期化時に、必須エントリ・ポイントのいずれかが指定されていない場合、エージェント・フレームワークではACTION_SCRIPT
リソース属性が指すスクリプトが起動されます。
エージェント・フレームワークでは、各アプリケーションに対して常に1つのエントリ・ポイントのみが起動されます。エントリ・ポイントがハングした場合、エージェント・フレームワークによってABORTエントリ・ポイントがコールされ、現在の操作を終了します。エージェント・フレームワークによってCHECKエントリ・ポイントが定期的に起動され、リソースの状態が確認されます。このエントリ・ポイントによって、リソースの状態として次のいずれかが戻されます。
-
CLSAGFW_ONLINE
: リソースが正常に起動されて現在動作中の状態である場合には、CHECKエントリ・ポイントによってONLINEが戻されます。リソースがこの状態である場合、エージェント・フレームワークで引き続き監視されます。この状態では、scriptagent
の数値は0です。 -
CLSAGFW_UNPLANNED_OFFLINE
およびCLSAGFW_PLANNED_OFFLINE
: OFFLINE状態は、リソースが現在実行されていないことを示します。これら2つの状態では、scriptagent
の数値はそれぞれ1および2です。plannedおよびunplannedの2つのカテゴリによってリソースのOFFLINE状態が示されます。
リソースの状態がOracle Clusterwareを介してOFFLINEに遷移すると、CHECKエントリ・ポイントから戻される値にかかわらず、このリソースはオフライン(
TARGET=OFFLINE
)になるように意図されているとみなされます。ただし、Oracle以外のインタフェースを使用してリソースが停止されたなど、Oracle Clusterwareに関係なくリソースの状態が変更されたことをエージェントで検出した場合、この意図はエージェントからクラスタ・レディ・サービス・デーモン(CRSD)に引き継がれる必要があります。この意図が次を決定する要因となります。-
リソースの
TARGET
リソース属性の値をそのままにしておくか、変更するか。PLANNED_OFFLINE
は、リソースがそれまで実行されていた場合にのみTARGET
リソース属性をOFFLINEに変更する必要があることを示します。リソースが実行されていなかった場合(STATE=OFFLINE
、TARGET=OFFLINE
)、リソースを起動するリクエストが着信すると、TARGET
リソース属性の値はONLINEに変更されます。その後、エージェントにこの起動リクエストが送られ、エージェントはリソースの状態PLANNED_OFFLINE
をOracle Clusterwareにレポートし、TARGET
リソース属性の値はONLINEのままになります。TARGET
属性はUNPLANNED_OFFLINE
によって変更されません。 -
リソースの状態を
UNPLANNED_OFFLINE
のままにしておくか、ローカルで再起動することによってリソースのリカバリを試行するか、クラスタ内の別のサーバーにフェイルオーバーするか。PLANNED_OFFLINE
状態では、リソースはCRSDによってそのままにされますが、UNPLANNED_OFFLINE
状態では、リソースのリカバリが求められます。
-
-
CLSAGFW_UNKNOWN
: リソースの現在の状態が判別できない場合は、CHECKエントリ・ポイントによってUNKNOWNが戻されます。この状態に対して、Oracle Clusterwareではフェイルオーバーまたはリソースの再起動は試行されません。リソースの以前の状態がONLINEまたはPARTIALのいずれかであった場合、エージェント・フレームワークでは引き続きリソースが監視されます。この状態では、scriptagent
の数値は3です。 -
CLSAGFW_PARTIAL
: リソースが部分的にオンラインで、一部のサービスが使用可能であることが認識された場合は、CHECKエントリ・ポイントによってPARTIALが戻されます。Oracle Clusterwareでは、この状態は部分的にオンラインとみなされ、フェイルオーバーまたはリソースの再起動は試行されません。エージェント・フレームワークでは、この状態のリソースが引き続き監視されます。この状態では、scriptagent
の数値は4です。 -
CLSAGFW_FAILED
: リソースが動作中の状態ではなく、一部のコンポーネントが失敗し、リソースを再起動するためにクリーンアップが必要であることが検出された場合は、CHECKエントリ・ポイントによってFAILEDが戻されます。この状態に対して、Oracle ClusterwareでCLEANアクションがコールされ、リソースがクリーンアップされます。CLEANアクションが終了したら、リソースの状態はOFFLINEになります。リソースのポリシーによっては、次に、Oracle Clusterwareでフェイルオーバーまたはリソースの再起動が試行される場合があります。エージェント・フレームワークで、障害が発生したリソースが監視されることはありません。この状態では、scriptagent
の数値は5です。
エージェント・フレームワークでは、表9-2に示す状態のリソースが、CHECK_INTERVAL
リソース属性またはOFFLINE_CHECK_INTERVAL
リソース属性で指定される一定の間隔で暗黙的に監視されます。
表9-2 エージェント・フレームワークの監視特性
状態 | 条件 | 頻度 |
---|---|---|
ONLINE |
常時 |
\
|
PARTIAL |
常時 |
|
OFFLINE |
|
|
UNKNOWN |
監視されるのは、リソースが前述のいずれかの条件のために以前に監視されていた場合のみ。 |
ONLINEのときにのみ状態がUNKNOWNになる場合は、 |
エージェントが起動されるたびに、エージェントが監視するすべてのリソースの状態はUNKNOWNに設定されます。エージェント・フレームワークでは、Oracle Clusterwareからの最初のプローブ・リクエストを受信すると、すべてのリソースに対してCHECKエントリ・ポイントが実行され、現在の状態が確認されます。
リソースのCHECKアクションが正常に完了すると、リソースの状態は前述の状態のいずれかに遷移します。次に、エージェント・フレームワークによって、Oracle Clusterwareから発行されるコマンドに基づいてリソースが起動されます。エージェント・フレームワークでは、すべてのアクションが完了するとCHECKアクションが起動され、リソースの現在の状態が確認されます。エージェント・フレームワークでは、リソースが表9-2に示す監視対象の状態のいずれかである場合、CHECKエントリ・ポイントが定期的に実行され、リソースの状態に変更がないかどうかが確認されます。
デフォルトでは、エージェント・フレームワークでオフラインのリソースは監視されません。ただし、OFFLINE_CHECK_INTERVAL
属性の値が0より大きい場合、エージェント・フレームワークでオフラインのリソースが監視されます。
9.1.3.1 Oracle Clusterwareの組込みエージェント
Oracle Clusterwareでは、リソースの管理にエージェント・プログラム(エージェント)を使用しており、アプリケーションを保護する次の組込みエージェントが含まれています。
-
appagent
: このエージェントは(Windowsではappagent.exe
)、generic_application
リソース・タイプのリソースおよびapplication
リソース・タイプの以前のバージョンのOracle Clusterwareのリソースを自動的に保護します。注意:
非推奨である
application
リソース・タイプは、以前のOracle Clusterware 11g リリース2 (11.2)リソースのサポートのみを目的として提供しているため使用しないことをお薦めします。 -
scriptagent
: このエージェント(Windowsではscriptagent.exe
)は、シェル・スクリプトまたはバッチ・スクリプトを使用してアプリケーションを保護する場合に使用します。cluster_resource
とlocal_resource
の両方のリソース・タイプは、この・エージェントを使用するように構成されており、また、これらのタイプのリソースは、このエージェントを自動的に利用します。
また、任意の方法でリソースを管理するために独自のエージェントを作成することもできます。
9.1.4 アクション・スクリプト
アクション・スクリプトは、リソースを開始、停止、確認またはクリーンアップする1つ以上のアクションを定義します。
エージェント・フレームワークは、C/C++アクションなしに、これらのアクションを起動します。アクション・スクリプトを使用すると、C/C++エントリ・ポイントおよびスクリプト・エントリ・ポイントを含むエージェントを作成できます。すべてのアクションがアクション・スクリプトに定義されている場合、スクリプト・エージェントを使用して、アクション・スクリプトに定義されているアクションを起動できます。
アクション・スクリプトに定義されているアクションを起動する前に、エージェント・フレームワークは、必要なすべての属性をリソース・プロファイルから環境にエクスポートします。アクション・スクリプトは、stdout/stderr
にメッセージを記録でき、エージェント・フレームワークは、エージェント・ログにこれらのメッセージを出力します。ただし、アクション・スクリプトは、stdout/stderr
に出力されるメッセージに次のいずれかのタグを接頭辞として追加することで、特別なタグを使用して、進捗、警告またはエラーのメッセージをcrs*
クライアント・ツールに送信できます。
CRS_WARNING:
CRS_ERROR:
CRS_PROGRESS:
エージェント・フレームワークは、最終メッセージをcrs*
クライアントに送信するときに、接頭辞として追加されたタグを削除します。
リソース属性は、接頭辞_CRS_
を持つ環境変数としてアクション・スクリプト内からアクセス可能です。たとえば、START_TIMEOUT
属性は、_CRS_START_TIMEOUT
という環境変数になります。
9.1.5 エージェントの作成
特定のアプリケーションのエージェント作成では、次の手順が実行されます。
- スクリプト、CまたはC++のいずれかでエージェント・フレームワークのエントリ・ポイントを実装します。
- エージェントの実行可能ファイルを作成します(CエージェントおよびC++エージェントの場合)。
- エントリ・ポイントで必要なすべてのパラメータを収集し、新しいリソース・タイプを定義します。
AGENT_FILENAME
属性を、新しく作成した実行可能ファイルの絶対パスに設定します。
9.1.5.1 CおよびC++エージェントの作成およびデプロイ
Oracle Clusterwareには、アプリケーションに高可用性エージェントを実装するエージェント・フレームワークを使用したCおよびC++エージェントの例が含まれています。付録Fは、demoagent1.cpp
というエージェントの例を説明しています。このエージェントは、ディスク上のファイルを表す単純なリソースを管理し、次のタスクを実行します。
-
起動時: ファイルを作成します
-
停止時: ファイルを正常に削除します
-
チェック時: ファイルが存在するかどうかをチェックします
-
クリーンアップ時: ファイルを強制的に削除します
Oracle Clusterwareに対するこの特定のリソースを記述するには、このリソース・クラスのすべての特徴的な属性を含むリソース・タイプを最初に作成する必要があります。この場合、記述する必要のある属性は、管理するファイルの名前のみです。次の手順は、リソースおよびそのエージェントを設定して、リソースの機能をテストする方法を示しています。
9.1.6 Oracle Clusterwareへのリソースの登録
crsctl add resourceコマンドを使用して、Oracle Clusterware 12c
にリソースを登録します。
アプリケーションをリソースとして登録するには、次の手順を実行します。
$ crsctl add resource resource_name -type [-group group_name] resource_type
[-file file_path] | [-attr "attribute_name='attribute_value', attribute_name='
attribute_value', ..."]
リソースの作成対象のアプリケーションに基づいて、そのリソースの名前を選択します。たとえば、Apache Webサーバーのリソースを作成する場合は、このリソースの名前をmyApache
とします。-type
オプションの後に、既存のリソース・タイプの名前を指定します。オプションで、リソースを既存のリソース・グループに追加できます。
リソース属性は、-file
オプションで指定されたテキスト・ファイル、または-attr
オプションの後の二重引用符(""
)で囲まれたリソース属性/値ペアのカンマ区切りのリストで指定できます。空白文字またはカンマで区切られた属性名およびカッコで囲まれた値は一重引用符(''
)で囲む必要があります。
属性ファイルの例を次に示します。
PLACEMENT=favored
HOSTING_MEMBERS=node1 node2 node3
RESTART_ATTEMPTS@CARDINALITYID(1)=0
RESTART_ATTEMPTS@CARDINALITYID(2)=0
FAILURE_THRESHOLD@CARDINALITYID(1)=2
FAILURE_THRESHOLD@CARDINALITYID(2)=4
FAILURE_INTERVAL@CARDINALITYID(1)=300
FAILURE_INTERVAL@CARDINALITYID(2)=500
CHECK_INTERVAL=2
CARDINALITY=2
-attr
オプションの使用例を次に示します。
$ crsctl add resource resource_name -type resource_type [-attr "PLACEMENT='
favored', HOSTING_MEMBERS='node1 node2 node3', ..."]
9.2 Oracle Clusterwareを使用した高可用性の実現の概要
Oracle Clusterwareでは、可用性が向上するような構成方法に基づいてリソースおよびリソース・グループが管理されます。
リソースおよびリソース・グループは、Oracle Clusterwareで次の操作が実行されるように構成できます。
-
クラスタまたはサーバーの起動時のリソースおよびリソース・グループの起動
-
障害が発生した場合のリソースおよびリソース・グループの再起動
-
各サーバーへのリソースおよびリソース・グループの再配置(他のサーバーを使用できる場合)
Oracle Clusterwareを使用してアプリケーションを管理するには、次の手順を実行します。
-
generic_application
リソース・タイプを使用するか、スクリプト・エージェントにカスタム・スクリプトを記述するか、新しいエージェントを作成します。 -
アプリケーションをOracle Clusterwareにリソースとして登録します。
単一のアプリケーションで複数のリソースを登録する必要がある場合は、Oracle Clusterwareによって単一のリソースのように管理されるリソース・グループを作成できます。リソース・グループ内のリソース間の関連する依存性を定義することが必要となる場合があります。
-
リソースまたはリソース・グループに適切な権限を割り当てます。
-
リソースおよびリソース・グループを起動または停止します。
リソースで障害が発生すると、Oracle Clusterwareは、アプリケーションまたはプロセスをリソースとして登録したときに指定した属性値に基づいて、リソースの再起動を試行します。障害の発生したリソースがリソース・グループのクリティカルでないリソース・メンバーである場合、そのリソース・グループはONLINE状態を維持します。クラスタ内のサーバーで障害が発生した場合、障害が発生したサーバーで実行されるように指定されていたプロセスが別のサーバーで再起動されるようにリソースおよびリソース・グループを構成できます。Oracle Clusterwareでは、様々なリソース属性に基づいて様々な構成可能な例がサポートされています。
リソースをOracle Clusterwareに登録した場合、またはOracle Clusterwareでリソース・グループを作成した場合、アプリケーション関連の情報およびリソース関連の情報がOracle Cluster Registry (OCR)に格納されます。この情報には、次のものが含まれます。
-
アクション・スクリプトまたはアプリケーション固有のエージェントへのパス: これは、Oracle Clusterwareによってアプリケーションで実行されるstartアクション、stopアクション、checkアクションおよびcleanアクションを定義するスクリプトまたはアプリケーション固有のエージェントへの絶対パスです。
関連項目:
これらのアクションの詳細は、「Oracle Clusterwareのエージェント」を参照してください。
-
権限: Oracle Clusterwareには、高可用性操作のために、アプリケーションのすべてのコンポーネントの制御に必要な権限(他のユーザーIDでプロセスを起動する権限を含む)があります。Oracle Clusterwareは、権限を持つユーザーとして実行し、正しい起動および停止プロセスでアプリケーションを制御する必要があります。
-
リソース依存性: 操作の順序を示したり、クラスタ内のサーバーのリソース配置に影響するリソースおよびリソース・グループ間の関係を作成できます。たとえば、他のリソースが実行されている場合、Oracle Clusterwareは別のリソースに対するhard起動依存性が定義されているリソースのみを起動できます。Oracle Clusterwareでは、停止対象のリソースに依存する他のリソースが実行されている場合、そのリソースは停止されません。ただし、
crsctl stop resource -f
コマンドを使用して、停止対象のリソースに依存するすべてのリソースを最初に停止し、そのリソースを強制終了することができます。
9.2.1 リソース属性
リソース属性は、Oracle Clusterwareで特定のリソース・タイプのリソースを管理する方法を定義します。各リソース・タイプには一意の属性セットがあります。一部のリソース属性はリソースの登録時に指定されますが、その他のリソース属性はOracle Clusterwareによって内部的に管理されます。
注意:
新しいリソース属性を定義できる場合でも、使用できる文字はUS-7 ASCIIのみです。
9.2.2 リソースの状態
表9-3 予想されるリソースの状態
状態 | 説明 |
---|---|
ONLINE |
リソースは実行されています。 |
OFFLINE |
リソースは実行されていません。 |
UNKNOWN |
リソースの停止の試行に失敗しました。Oracle Clusterwareでは、この状態のリソースはアクティブに監視されません。アプリケーション固有のアクション(プロセスの停止など)を実行してリソースをオフラインにし、 |
INTERMEDIATE |
次の2つのイベントのいずれかにより、リソースがINTERMEDIATE状態になる場合があります。
Oracle Clusterwareでは、INTERMEDIATE状態のリソースはアクティブに監視され、通常、ユーザーの介入は必要ありません。前述の理由1のためリソースがINTERMEDIATE状態になっている場合、Oracle Clusterwareは、リソースの状態が確立されるとすぐにリソースをINTERMEDIATE状態から遷移させます。 前述の理由2のためリソースがINTERMEDIATE状態になっている場合、リソースは、部分的にオンラインであるかぎり、この状態のままになります。たとえば、VIPのホーム・サーバーは、VIPがスイッチオーバーできるようにクラスタに再度参加する必要があります。データベース管理者は、データベース・インスタンスをオープンするコマンドを発行する必要があります。 ただし、いずれの場合も、Oracle Clusterwareでは、リソースは適切になるとすぐにINTERMEDIATE状態から自動的に遷移します。 |
9.2.3 リソースの依存性
リソースは他のリソースに依存するように構成でき、これによって、依存先リソースの特定の条件が満たされる場合にのみ、依存リソースを起動または停止できます。たとえば、Oracle Clusterwareでリソースを起動しようとする場合、初期リソースが依存するリソースは実行中で、同じ場所に存在する必要があります。Oracle Clusterwareでリソースをオンラインにすることができない場合は、初期(依存)リソースをオンラインにすることもできません。Oracle Clusterwareによってリソースが停止された場合またはリソースで障害が発生した場合は、依存リソースも停止されます。
一部のリソースでは、他のリソースより起動に必要な時間が長くなります。一部のリソースはサーバーが起動されるたびに起動する必要がありますが、その他のリソースは手動のstartアクションが必要です。これらのリソース固有の動作の例および他の多くの例は、各リソースを予測される動作および他のリソースとの関連から説明する必要があることを示しています。
リソースがOracleリソースに依存するように構成できます。ただし、リソースを作成する際、リソース名に接頭辞oraを使用しないでください。この接頭辞は、Oracleでのみ使用するために予約されています。
以前のバージョンのOracle Clusterwareには、REQUIRED_RESOURCES
リソース属性およびOPTIONAL_RESOURCES
リソース属性という2つの依存性仕様のみが含まれていました。REQUIRED_RESOURCES
リソース属性は、リソースの起動依存性および停止依存性の両方に適用されます。
注意:
REQUIRED_RESOURCES
およびOPTIONAL_RESOURCES
リソース属性はapplication
タイプのリソースの場合のみ引き続き使用可能です。これらを使用してOracle Clusterware 12cのリソース依存性を定義することは非推奨です。
リソース依存性は、起動および停止カテゴリに分類されます。この分割によって、リソースとリソース・タイプ間の起動依存性および停止依存性が向上され、拡張されます。
この項には次のトピックが含まれます:
9.2.3.1 起動依存性
Oracle Clusterwareでは、リソースの起動試行の評価が開始されると、そのリソースのプロファイルに含まれる起動依存性が考慮されます。START_DEPENDENCIES
リソース属性を使用して、リソースの起動依存性を指定します。各依存性で修飾子を使用して、依存性をさらに詳細に構成できます。
この項では、次の起動依存性について説明します。
関連トピック
9.2.3.1.1 attraction
リソースBに対するattraction
依存性がリソースAに定義されている場合、Oracle ClusterwareはリソースBをホスティングしているサーバーにリソースAを配置します。この場合のリソースAのような依存リソースは、依存リソースでattraction
依存性が定義されている依存先リソースが実行されているサーバーで実行される傾向があります。Oracle Clusterwareは、依存リソースが誘引されるリソースのサーバーに依存リソースを配置します。
次の制約を使用して、attraction
起動依存性を構成できます。
-
START_DEPENDENCIES=attraction(intermediate:resourceB)
intermediate
修飾子を使用すると、INTERMEDIATE
状態になっているリソースにリソースが誘引されるかどうかを指定できます。 -
START_DEPENDENCIES=attraction(type:resourceB.type)
type
修飾子を使用すると、特定のリソース・タイプに対して依存性を有効にするかどうかを指定できます。依存リソースは特定のタイプのリソースを最も多くホスティングしているサーバーに誘引されます。
注意:
以前のバージョンのOracle Clusterwareでは、現在非推奨のOPTIONAL_RESOURCES
属性を使用してattraction依存性が表現されています。
9.2.3.1.2 dispersion
リソースにdispersion
起動依存性を指定すると、Oracle Clusterwareは、このリソースでdispersionが定義されているリソースが最も少ないサーバーでこのリソースを起動します。dispersionを使用するリソースでも、リソースを分散する十分なサーバーがない場合、同じサーバーで実行されることがあります。
次の修飾子を使用して、dispersion
起動依存性を構成できます。
-
START_DEPENDENCIES=dispersion(intermediate:resourceB)
intermediate
修飾子を使用すると、リソースBがONLINE
状態またはINTERMEDIATE
状態のいずれであっても、Oracle ClusterwareによってリソースAが分散されるように指定できます。 -
START_DEPENDENCIES=dispersion:active(resourceB)
通常、dispersionはリソースの起動時にのみ適用されます。リソースの起動時に十分なサーバーがないために、相互に分散するリソースが同じサーバーで起動される場合、サーバーがクラスタに追加されてもリソースが実行されていれば、Oracle Clusterwareはそのリソースを変更しません。
active
修飾子を指定する場合、Oracle Clusterwareは、新しいサーバーがクラスタに追加されると、リソースに対してdispersionを再適用します。 -
START_DEPENDENCIES=dispersion(pool:resourceB)
Oracle Clusterwareがリソースを別のサーバーではなく別のサーバー・プールに分散させるように指定するには
pool
修飾子を使用します。
9.2.3.1.3 exclusion
exclusion
起動依存性には、起動中にリソース間の排他的関係を定義する句が含まれています。exclusion
起動依存性が定義されているリソースは、同一のノード上で実行できません。たとえば、リソースBに対するexclusion
起動依存性がリソースAに定義されている場合、CRSDポリシーは、リソースAを起動する必要があるサーバー上でリソースBが既に実行されていると、次のオプションを提供します。
-
リソースBが既に実行されている場合、リソースAの起動を拒否します。
-
リソースBに割り込んでリソースAを起動します。割込み操作には2種類あります。
-
リソースBが停止され、可能であれば、別のノードで再起動されます。続いてリソースAが起動されます。
-
リソースAが最初に起動されます。続いてリソースBが停止され、可能であれば、別のノードで再起動されます。
-
次の修飾子を使用して、exclusion
起動依存性を構成できます。
-
START_DEPENDENCIES=exclusion([[preempt_pre: | preempt_post:]]
target_resource_name
| type:
target_resource_type
]*)
指定されているすべての修飾子は、リソースまたはリソース・タイプに基づきます。Oracle Clusterwareは、リソース依存性ツリーに基づいて、1つの
exclusion
依存性のみを許可します。preempt
修飾子がない場合、CRSDは、そのターゲット・リソースがオフラインのときにのみ起動しようとします。-
preempt_pre
: この割込み修飾子を選択すると、CRSDは、指定したターゲット・リソースまたは特定のリソース・タイプが定義するリソースを起動してから、ソースのリソースを起動します。停止されたリソースの再起動が可能な場合、CRSDは、割込みリソースを起動するのと同時にこれを実行できます。 -
preempt_post
: この割込み修飾子を選択すると、CRSDはソースのリソースを起動した後に停止し、可能であれば、指定のターゲットのリソースまたは特定のリソース・ライプが定義するリソースを再配置します。
CRSDがターゲットのリソースを停止できない場合、またはソースのリソースを起動できない場合、すべての操作が失敗します。次にOracle Clusterwareは、可能であれば、問題のあるリソースを元の状態に戻そうとします。
-
9.2.3.1.4 hard
依存リソースを起動する前に別のリソースが実行されている必要がある場合は、そのリソースにhard
起動依存性を定義します。たとえば、リソースBに対するhard
起動依存性がリソースAに定義されている場合は、リソースAを起動する前にリソースBが実行されている必要があります。同様に、両方のリソース(AとB)が最初にオフラインになっている場合、リソースAの依存性を満たすためにリソースBが最初に起動されます。
注意:
hard
起動依存性を持つリソースにはpullup
起動依存性も定義することをお薦めします。
次の制約を使用して、hard
起動依存性を構成できます。
-
START_DEPENDENCIES=hard(global:resourceB)
デフォルトでは、リソースAおよびBを同じサーバーに配置する必要があります。
global
修飾子を使用してリソースを同じ場所に配置する必要がないように指定します。たとえば、リソースBに対するhard(global:resourceB)
起動依存性がリソースAに定義されている場合は、リソースBがクラスタ内のノードで実行されていると、リソースAを起動できます。 -
START_DEPENDENCIES=hard(intermediate:resourceB)
intermediate
修飾子を使用すると、依存先リソースの状態がONLINE
またはINTERMEDIATE
のいずれかの場合に依存リソースを起動できるように指定できます。 -
START_DEPENDENCIES=hard(type:resourceB.type)
type
修飾子を使用すると、hard
起動依存性を特定のリソースに対して有効にするか、リソース・タイプに対して有効にするかを指定できます。たとえば、resourceB.type
タイプに対するhard
起動依存性がリソースAに定義されている場合は、resourceB.type
タイプのリソースが実行されているとリソースAを起動できます。 -
START_DEPENDENCIES=hard(uniform:resourceB)
uniform
修飾子を使用して、リソースBのすべてのインスタンスの起動を試行しますが、最低1つのインスタンスが起動されて依存性を満たす必要があります。 -
START_DEPENDENCIES=hard(resourceB, intermediate:resourceC, intermediate:global:type:resourceC.type)
修飾子を組み合せて、
START_DEPENDENCIES
リソース属性に複数のリソースを指定できます。注意:
修飾子句は、カンマで区切ります。
type
修飾子句は必ずリストの最後の修飾子句である必要があり、type
修飾子を必ずタイプの直前に指定する必要があります。
9.2.3.1.5 pullup
リソースBが起動するたびにリソースAを自動的に起動するには、pullup
起動依存性を使用します。この依存性は、リソースAが実行されていない場合にのみリソースAに影響します。他の依存性の場合と同様に、pullup
によって、依存リソースがすべてのサーバーで起動することがあります。リソースAがリソースBに依存し、リソースBが失敗した後リカバリした場合に、リソースAが再起動されるように、hard停止依存性がある場合は必ずpullup
依存性を使用します。
注意:
hard
起動依存性を持つリソースにはpullup
起動依存性も定義することをお薦めします。
次の制約を使用して、pullup
起動依存性を構成できます。
-
START_DEPENDENCIES=pullup(intermediate:resourceB)
intermediate
修飾子を使用すると、リソースBがONLINE
状態またはINTERMEDIATE
状態のいずれかの場合にリソースAを起動できるように指定できます。複数のリソースに対する
pullup
依存性がリソースAに定義されている場合、リソースAが依存するすべてのリソースが起動されたときにのみリソースAが起動されます。 -
START_DEPENDENCIES=pullup:always(resourceB)
always
修飾子を使用して、リソースAが依存するリソースのTARGET
属性の値がONLINE
またはOFFLINE
のいずれであっても、Oracle ClusterwareでリソースAを起動するかどうかを指定できます。デフォルトでは、always
修飾子を使用せず、依存先リソースのTARGET
属性の値がONLINE
の場合にのみpullup
によってリソースが起動されます。 -
START_DEPENDENCIES=pullup(type:resourceB.type)
type
修飾子を使用すると、特定のリソース・タイプに対して依存性を有効にするように指定できます。
9.2.3.1.6 weak
リソースBに対するweak
起動依存性がリソースAに定義されており、リソースBが実行されていない場合は、リソースAの起動を試行すると、リソースBの起動が試行されます。ただし、リソースBの起動の試行結果は、リソースAの起動結果に影響しません。
次の制約を使用して、weak
起動依存性を構成できます。
-
START_DEPENDENCIES=weak(global:resourceB)
デフォルトでは、リソースAおよびBは同じ場所に配置する必要があります。
global
修飾子を使用してリソースを同じ場所に配置する必要がないように指定します。たとえば、リソースBに対するweak(global:resourceB)
起動依存性がリソースAに定義されている場合は、リソースBがクラスタ内のノードで実行されていると、リソースAを起動できます。 -
START_DEPENDENCIES=weak(concurrent:resourceB)
concurrent
修飾子を使用すると、リソースAおよびリソースBが同時に起動できるように指定できます。 -
START_DEPENDENCIES=weak(type:resourceB.type)
type
修飾子を使用すると、resourceB.type
など、特定のリソース・タイプのリソースに対して依存性を有効にすることを指定できます。 -
START_DEPENDENCIES=weak(uniform:resourceB)
uniform
修飾子を使用して、リソースBのすべてのインスタンスの起動を試行します。
9.2.3.2 停止依存性
Oracle Clusterwareでは、リソースが停止される(リソースの状態がONLINE
から他の状態に変更される)たびに、リソース間の停止依存性が考慮されます。
9.2.3.2.1 hard
リソースBに対するhard
停止依存性がリソースAに定義されている場合は、リソースBの実行が停止されるときにリソースAも停止される必要があります。2つのリソースは、構成方法に応じて、起動または別のサーバーへの再配置を試行する場合があります。hard
停止依存性を持つリソースにはhard
起動依存性も定義することをお薦めします。
次の修飾子を使用して、hard
停止依存性を構成できます。
-
STOP_DEPENDENCIES=hard(intermedite:resourceB)
intermediate
修飾子を使用すると、リソースAをオンラインのままにするために、リソースBをONLINE
またはINTERMEDIATE
状態のいずれかにする必要があるかどうかを指定できます。 -
STOP_DEPENDENCIES=hard(global:resourceB)
global
修飾子を使用すると、リソースAをオンラインのままにするために、リソースBが同じサーバーまたはクラスタ内の任意のサーバーに存在する必要があるかどうかを指定できます。この制約が指定されていない場合、リソースAおよびBは同じサーバーで実行されている必要があります。この条件が満たされなくなると、リソースAはOracle Clusterwareによって停止されます。 -
STOP_DEPENDENCIES=hard(shutdown:resourceB)
crsctl stop crs
コマンドまたはcrsctl stop cluster
コマンドのどちらかを使用してOracle Clusterwareスタックを停止する場合にのみshutdown
修飾子を使用してリソースを停止します。
関連トピック
9.2.3.2.2 リソース状態のリカバリに対するリソース依存性の影響
リソースの実行を続行する計画である場合に、リソースが実行されている状態から実行されていない状態に遷移する場合、この遷移はリソース障害と呼ばれます。この時点で、Oracle Clusterwareでは、リソース状態のリカバリ手順(リソースの高可用性ポリシーおよびその時点のエンティティの状態に応じて、リソースのローカルでの再起動、別のサーバーへの再配置または依存リソースの停止が試行される)が適用されます。
複数のリソースが相互に依存している場合、そのいずれかの障害が原因で他のリソースにも障害が発生することがあります。ほとんどの場合、障害が検出される順序を制御または予測することは困難です。たとえば、リソースAがリソースBに依存する場合でも、Oracle Clusterwareでは、リソースBの障害がリソースAの障害よりも後で検出されることがあります。
このように、障害の順序が予測可能でない場合、Oracle Clusterwareでは依存リソースの再起動がパラレルで試行される可能性があり、これによって、依存先リソースが不適切な順序で再起動されるため、最終的に一部のリソースの再起動に失敗します。
この場合、hard
停止依存性およびpullup
依存性のいずれかまたはその両方が使用されていると、Oracle Clusterwareでは依存リソースのローカルでの再起動が再試行されます。たとえば、リソースAにリソースBに対するhard
停止依存性またはpullup
依存性のいずれかあるいはその両方が定義されている場合、リソースBで障害が発生したためにリソースAでも障害が発生すると、Oracle Clusterwareではその両方のリソースの再起動が同時に試行される可能性があります。リソースAの再起動の試行に失敗した場合、Oracle Clusterwareでは、リソースBが正常に再起動されるとすぐにリソースAの再起動が試行されます。
9.2.4 リソースの配置
起動試行の評価の一部としてOracle Clusterwareで最初に決定される必要があるのは、リソースを起動(または配置)する場所です。コール元がターゲットのサーバーを名前で指定する場合、これは容易に決定されます。ただし、ターゲットのサーバーが指定されない場合、Oracle Clusterwareでは、リソースの構成およびクラスタの現在の状態で配置に最適なサーバーの検索が試行されます。
Oracle Clusterwareでは、最初にリソースの配置ポリシーが考慮され、ポリシーに適合しないサーバーは除外されます。Oracle Clusterwareでは、リソースのPLACEMENT
リソース属性の値に応じた特定の順序で残りのサーバーがソートされます。
これが考慮された結果、Oracle Clusterwareによってリソースを起動できる候補サーバーのリストが最大2つ作成されます。一方のリストには優先サーバーが含まれ、もう一方のリストには配置可能なサーバーが含まれます。リソースのPLACEMENT
リソース属性の値がbalanced
またはrestricted
に設定されている場合、優先サーバーのリストは空になります。リソースの配置ポリシーによって、リソースを実行するサーバーが決定します。Oracle Clusterwareでは、優先リストにサーバーが示される場合、配置可能なサーバーよりも優先サーバーが考慮されます。
次に、リソースの依存性がある場合は、Oracle Clusterwareで考慮されてリソースの配置場所が判断されます。attraction起動依存性およびdispersion起動依存性は、一部の依存性修飾子と同様にリソースの配置決定に影響を及ぼします。Oracle Clusterwareによってこれらの配置ヒントが適用され、前述の2つのリストでサーバーがさらに順序付けられます。Oracle Clusterwareでは、リソースの配置ポリシーの影響と依存性の影響とを区別するために、サーバーの各リストが別々に処理されることに注意してください。
最後に、Oracle Clusterwareでは、優先サーバーがリストされている場合はそのリストから最初のサーバーが選択されます。Oracle Clusterwareでは、優先サーバーのリストにサーバーが示されていない場合、配置可能なサーバーがリストされていれば、その配置可能なサーバーのリストから最初のサーバーが選択されます。どちらのリストにもサーバーがない場合、Oracle Clusterwareではリソース配置エラーが生成されます。
注意:
Oracle Clusterwareで起動を試行しているリソースに関連する配置ポリシーまたはリソースの依存性のいずれも配置の決定に影響を及ぼしません。
関連トピック
9.3 リソースとしてのアプリケーションの登録
この項では、アプリケーションをOracle Clusterwareのリソースとして登録する手順の例を示します。
この手順では、(例として) Apache WebサーバーをOracle Clusterwareにリソースとして追加する方法を示します。この項の例では、Oracle ClusterwareおよびOracle Clusterwareで管理されるアプリケーションを所有するユーザーまたはグループに対する完全な管理権限がOracle Clusterware管理者に付与されていることを前提とします。登録処理が完了すると、オペレーティング・システム・ユーザーのかわりにOracle Clusterwareでアプリケーションを起動できます。
Oracle Clusterwareでは、登録されたリソースの所有者とユーザーは区別されます。リソースの所有者は、エージェントが実行されるオペレーティング・システム・ユーザーです。ユーザーおよび所有者の権限は、リソースのACL
リソース属性によって定義されます。リソースを変更できるのは、root
のみです。
注意:
-
接頭辞に
crs_
を持つOracle Clusterwareコマンドは、このリリースでサポート対象外となり、使用できなくなりました。これらのコマンドは、CRSCTLコマンドによって置換されます。CRSCTLコマンドのリストおよび対応するcrs_
コマンドは、「Oracle Clusterware制御(CRSCTL)ユーティリティ・リファレンス」を参照してください。 -
My Oracle Supportで指示された場合を除き、接頭辞
ora
を持つ名前のリソースで(Oracleリソースであるため)CRSCTLコマンドを使用しないでください。Oracleリソースを構成するには、サーバー制御ユーティリティ(SRVCTL)を使用します。SRVCTLによって、すべての構成可能なオプションが提供されます。
9.3.1 Oracle Clusterwareで管理されるアプリケーションVIPの作成
アプリケーションVIPは、Oracle Clusterwareによって管理されるクラスタ・リソースです(Oracle ClusterwareではアプリケーションVIP用の標準VIPエージェントが提供されます)。
アプリケーションのクライアントがネットワークを介してアプリケーションにアクセスし、アプリケーションの配置ポリシーによって別のノードへのフェイルオーバーが可能である場合は、アプリケーションが依存する仮想インターネット・プロトコル・アドレス(VIP)を登録する必要があります。システムで、クラスタにデプロイされたすべてのVIPの動作の一貫性が保持されるように、新しいアプリケーションVIPはこのVIPタイプに基づく必要があります。
Oracle Clusterwareが管理するその他のリソースを追加するときと同じ方法でVIPを追加することができますが、Oracleでは、Grid_home/bin/appvipcfg
コマンドライン・ユーティリティを使用して、ora.net1.network
がデフォルトで作成されるデフォルトのネットワークにアプリケーションVIPを作成または削除することをお薦めします。
アプリケーションVIPを作成するには、次の構文を使用します。
appvipcfg create -network=network_nummber -ip=ip_address -vipname=vip_name
-user=user_name [-group=group_name] [-failback=0 | 1]
注意:
VIP名は、リソースをオンラインにしたまま、リソースを再起動せずに変更できます。
デフォルトのネットワークにVIPを作成する場合、-network=1
を設定します。
デフォルト以外のネットワークにアプリケーションVIPを作成するには、場合によって、最初にsrvctl add network
コマンドを使用してネットワークを作成する必要があります。その後、-network=
non-default_network_number
を設定してアプリケーションVIPを作成できます。
Oracle Flex Clusterでは、srvctl add network
コマンドを次の構文で使用して、アプリケーションをリーフ・ノード上で実行できるように、アプリケーションVIPのリーフ・ノード・ネットワーク・リソースを追加することもできます。
srvctl add network -netnum=network_number -subnet subnet/netmask[/if1[|if2|...]] -leaf
関連項目:
リーフ・ノードの詳細は、「Oracle Flex Cluster」を参照してください
アプリケーションVIPを削除するには、次の構文を使用します。
appvipcfg delete -vipname=vip_name
前述の構文の例で、network_number
はネットワークの番号、ip_address
はIPアドレス、vip_name
はVIPの名前、user_name
はOracle Databaseをインストールしたユーザーの名前、group_name
はグループの名前です。-failback
オプションのデフォルト値は0です。オプションを1に設定すると、VIP(および、VIPに依存するすべてのリソース)は、元のノードが再び使用可能になると、元のノードにフェイルバックします。
注意:
-ip=ip_address
パラメータは必須ですが、グリッド・プラグ・アンド・プレイおよびDHCPとGNSが構成されている場合、このパラメータでは常にDHCPサーバーからのIPアドレスが取得され、コマンドで指定されたIPアドレスは無視されます。DHCPを使用する場合、-vipname=vip_name
パラメータの値も無視されます。
たとえば、root
として次のコマンドを実行します。
# Grid_home/bin/appvipcfg create -network=1 -ip=148.87.58.196 -vipname=appsVIP -user=root
スクリプトには、アプリケーションVIPリソースを所有するユーザーのほか、ネットワーク番号、IPアドレス、VIPリソースの名前のみが必要です。VIP関連の操作にはroot権限が必要であるため、通常、VIPリソースはroot
が所有します。
アプリケーションVIPを削除するには、delete
オプションで同じスクリプトを使用します。このオプションはVIPの名前をパラメータとして受け入れます。次に例を示します。
# Grid_home/bin/appvipcfg delete -vipname=appsVIP
この構成スクリプトを使用してアプリケーションVIPを作成したら、次のコマンドを使用してVIPプロファイルを表示できます。
$ Grid_home/bin/crsctl status res appsVIP -p
Grid_home/bin/crsctl modify res
コマンドを使用して次のパラメータの検証と、必要に応じて変更を行います。
appvipcfg
スクリプトは、-network=1
に設定されていても-network
オプションを指定する必要があります。
Oracle Databaseインストール所有者として、VIPリソースを起動します。
$ crsctl start resource appsVIP
9.3.1.1 Oracle Enterprise ManagerによるアプリケーションVIPの追加
- Oracle Enterprise Manager Cloud Controlにログインします。
- 変更するクラスタ・ターゲットを選択します。
- クラスタ・ターゲットのメニューから、「管理」→「リソース」→「管理」を選択します。
- クラスタ管理者のユーザー名およびパスワードを入力して、「リソースの管理」ページを表示します。
- 「アプリケーションVIPの追加」をクリックします。
- 「名前」フィールドにVIPの名前を入力します。
- 「ネットワーク番号」フィールドにネットワークの番号を入力します。
- 「インターネット・プロトコル・アドレス」フィールドにVIPのIPアドレスを入力します。
- 「プライマリ・ユーザー」フィールドにrootと入力します。Oracle Enterprise Managerは、ログイン時に使用するユーザー名をデフォルト値とします。
- VIPをすぐに起動する場合は、「作成後にリソースを開始」を選択します。
- 「続行」をクリックして「確認: VIPリソースの追加」ページを表示します。
- クラスタの資格証明としてrootおよびルート・パスワードを入力します。
- 「続行」をクリックしてアプリケーションVIPを作成します。
9.3.2 ユーザー定義のリソースの追加
Oracle Clusterwareにはいつでもリソースを追加できます。
ただし、別のリソースに依存しているリソースを追加する場合は、最初にそのリソースが依存しているリソースを追加します。
この項の例では、クラスタへのリソースの追加を簡単にするために、アクション・スクリプトmyApache.scr
が各ノードの/opt/cluster/scripts
ディレクトリに存在していると想定しています。また、アプリケーションをホストするために複数のプールが作成されていると想定します。このサーバー・プールは汎用のサブプールではありませんが、かわりに、最上位のサーバー・プールでアプリケーションをホスティングするために使用されます。
注意:
スクリプトのメンテナンスを軽減するために、Oracle Automatic Storage Management Cluster File System (Oracle ACFS)などの共有ストレージを使用してアクション・スクリプトを格納することをお薦めします。
この項には次のトピックが含まれます:
9.3.2.1 デプロイメント・スキームの決定
アプリケーションの管理者またはポリシー管理を使用するかどうかを決定する必要があります。管理者管理は、クラスタ構成が変更される可能性が低い、小規模な2ノード構成に使用します。ポリシー管理は、クラスタが3つ以上のノードで構成されている場合に、より動的な構成に使用します。たとえば、リソースがノード1およびノード2のみで実行されている場合、これらのノードにのみ必要なファイルが存在するため、管理者管理がより適切である可能性があります。
Oracle Clusterwareでは、匿名サーバーで構成され、必要なプール・サイズに厳密に基づく、アクセス制御されたサーバー・プールでのアプリケーションのデプロイメントがサポートされています。この場合、管理者定義のクラスタ・ポリシーを使用して、必要なサイズおよび重要度のレベルで、サーバー割当てを制御する必要があります。または、厳密なサーバー割当てまたは優先サーバー割当てを使用することもでき、この場合、リソースは具体的な名前が指定されたサーバーで実行されます。これは、以前のリリースのOracle Clusterwareで使用可能な既存のモデル(現在の管理者管理)を表します。
概念上、両方のデプロイメント・スキームで開発およびデプロイされたアプリケーションをホスティングするクラスタは、サーバーの、論理的に分割された2つのグループと考えることができます。一方のサーバー・グループはサーバー・プールに使用され、ロールの分離およびサーバーの容量制御が可能になります。もう一方のサーバー・グループでは、クラスタ内の名前付きのサーバーに基づく固定割当てが想定されます。
いずれかのデプロイメント・スキームを使用してアプリケーションを管理するには、クラスタにリソースを追加する前にサーバー・プールを作成する必要があります。Genericという名前の組込みサーバー・プールは、管理者ベース管理のアプリケーションによって使用されるサーバーを常に所有します。汎用サーバー・プールは論理的な分割で、異なる管理スキームを使用してクラスタの2つの部分を分割するために使用できます。
サード・パーティの開発者がこのモデルを使用してアプリケーションをデプロイするには、サーバー・プールを使用する必要があります。名前付きのサーバーに基づく、既存のアプリケーション開発およびデプロイメント・モデルを利用するには、汎用サブプール(汎用プールが親であるサーバー・プールで、サーバー・プール属性のPARENT_POOLS
で定義される)を使用する必要があります。親として汎用を使用するサブプールを作成し、サーバーをサブプール定義に名前で列挙することによって、名前付きのサーバーが、汎用内に存在すること、および名前付きのサーバー・モデルを使用するアプリケーション専用に使用されることがアプリケーションで保証されます。
9.3.2.2 特定のサーバー・プールへのリソースの追加
crsctl add resource
コマンドを使用して、リソースをサーバー・プールに追加します。
ポリシー・ベースのデプロイメント・スキームを使用して、特定のサーバー・プールにApache Webサーバーをリソースとして追加するには、Apacheサーバーを実行するユーザーとして次のコマンドを実行します(Apache Serverの場合、これは通常root
ユーザーです)。
$ crsctl add resource myApache -type cluster_resource -attr
"ACTION_SCRIPT=/opt/cluster/scripts/myapache.scr,
PLACEMENT=restricted,
SERVER_POOLS=server_pool_list,
CHECK_INTERVAL=30,
RESTART_ATTEMPTS=2,
START_DEPENDENCIES=hard(appsvip),
STOP_DEPENDENCIES=hard(appsvip)"
前述の例では、クラスタに追加されるリソースの名前はmyApache
です。
注意:
-
エラーにならないように、カンマ区切りまたはスペース区切りの属性値は単一引用符(' ')で囲む必要があります。単独の属性値を単一引用符で囲んだ場合、引用符は無視されてエラーは発生しません。
-
リソース名の先頭をピリオドまたはoraという文字列にすることはできません。
リソースは次のように構成されます。
-
このリソースは
cluster_resource
タイプです。 -
ACTION_SCRIPT=/opt/cluster/scripts/myapache.scr
: 必要なアクション・スクリプトへのパスです。 -
PLACEMENT=restricted
-
SERVER_POOLS=server_pool_list
: このリソースは、空白区切りリストで指定されているサーバー・プールでのみ実行できます。 -
CHECK_INTERVAL=30
: Oracle Clusterwareによって、リソースのステータスの確認のために30秒ごとにリソースがチェックされます。 -
RESTART_ATTEMPTS=2
: Oracle Clusterwareによって、リソースが別のノードにフェイルオーバーされる前に、リソースの再起動が2回試行されます。 -
START_DEPENDENCIES=hard(appsvip)
: このリソースには、appsvipリソースに対するhard起動依存性が定義されています。myApacheを起動するには、appsvipリソースがオンライン状態である必要があります。 -
STOP_DEPENDENCIES=hard(appsvip)
: このリソースには、appsvipリソースに対するhard停止依存性が定義されています。appsvipリソースがオフラインになると、myApacheリソースは停止します。
9.3.2.3 サーバー固有のデプロイメントを使用したリソースの追加
名前付きのサーバー・デプロイメントを使用するリソースとしてApache Webサーバーを追加する場合、定義上、汎用サーバー・プールのサブプールであるサーバー・プールにリソースが追加されていると想定します。crsctl add serverpool
コマンドを使用して、汎用サブプールであるサーバー・プールを作成します。これらのサーバー・プールでは、汎用サーバー・プールはPARENT_POOLS
サーバー・プール属性で親として定義されます。また、SERVER_NAMES
パラメータにはサーバー名のリストが含められ、それぞれのプールに割り当てる必要があるサーバーが指定されます。次に例を示します。
$ crsctl add serverpool myApache_sp -attr
"PARENT_POOLS=Generic, SERVER_NAMES=host36 host37"
サブプールを作成した後、Apache Webサーバー・リソースを次のように追加します。
$ crsctl add resource myApache -type cluster_resource -attr
"ACTION_SCRIPT=/opt/cluster/scripts/myapache.scr,
PLACEMENT='restricted',
SERVER_POOLS=myApache_sp,
CHECK_INTERVAL='30',
RESTART_ATTEMPTS='2',
START_DEPENDENCIES='hard(appsvip)',
STOP_DEPENDENCIES='hard(appsvip)'"
注意:
リソース名の先頭をピリオドまたはoraという文字列にすることはできません。
また、サーバー固有のデプロイメントを使用してリソースを追加する場合、SERVER_POOLS
リソース・パラメータにリストされたサーバー・プールは、汎用サーバー・プールの下位プールである必要があることに注意してください。
関連トピック
9.3.2.4 generic_applicationリソース・タイプを使用するリソースの作成
高可用性が必要で、アクション・スクリプトの作成が不要なタイプのアプリケーションのモデル化する場合は、crsctl add resourceコマンドで
generic_application
リソース・タイプを使用してリソースを作成します。
この項には、generic_application
リソース・タイプを使用するリソースをLinux/UNIXプラットフォームで作成する2つの例が示されています。
次のコマンドの例では、高可用性のSambaサーバー・リソースが作成されます。
$ crsctl add resource samba1 -type generic_application -attr
"START_PROGRAM='/etc/init.d/smb start',
STOP_PROGRAM='/etc/init.d/smb stop',
CLEAN_PROGRAM='/etc/init.d/smb stop',
PID_FILES='/var/run/smbd.pid,/var/run/nmbd.pid'"
前述の例で、リソースを定義する属性は次のように構成されます。
-
START_PROGRAM='/etc/init.d/smb start'
: この属性には、Sambaサーバーを起動するスクリプトへの完全なパスおよび引数が含まれています -
STOP_PROGRAM='/etc/init.d/smb stop'
: この属性には、Sambaサーバーを停止するスクリプトへの完全なパスおよび引数が含まれています -
CLEAN_PROGRAM='/etc/init.d/smb stop'
: この属性には、Sambaサーバーの起動または停止に障害が起きた場合に、サーバーを強制的に終了し、クリーンアップするスクリプトの完全なパスおよび引数が含まれています -
PID_FILES='/var/run/smbd.pid,/var/run/nmbd.pid'
: この属性には、プロセスID (PID)をリストしているテキスト・ファイルのパスが含まれており、このリストを監視して、Sambaサーバーおよびそのコンポーネントすべてが実行されているようにする必要があります
注意:
-
このSambaサーバー構成にスクリプト・ベースの監視が必要な場合、次のように、
PID_FILES
の代わりに、CHECK_PROGRAMS
属性を使用できます。CHECK_PROGRAMS='/etc/init.d/smb status'
-
Sambaサーバー・リソースの
HOSTING_MEMBERS
、SERVER_POOLS
、PLACEMENT
およびCARDINALITY
属性を構成して、標準的なOracle Clusterwareの配置およびカーディナリティ・プロパティを指定できます。
2番目のコマンドの例では、高可用性のデータベース・ファイル・サーバー(DBFS)リソースが作成されます。DBFSは、Oracle Databaseに格納されたデータにアクセスできるFilesystem in Userspace (FUSE)ファイル・システムを提供します。
generic_application
リソース・タイプを使用してDBFSファイル・システムに相当するリソースを定義できます。このDBFSリソースを使用して、DBFSファイル・システム・マウント・ポイントを起動、停止、監視およびフェイルオーバーすることができます。このリソースを作成するコマンドの構文は、次のとおりです。
$ crsctl add resource dbfs1 -type generic_application -attr
"START_PROGRAM='/app/oracle/12.2/bin/dbfs_client -o wallet
/@inst1 /scratch/mjk/data/dbfs_mount',
STOP_PROGRAM='/bin/fusermount -u /scratch/mjk/data/dbfs_mount',
CHECK_PROGRAMS='ls /scratch/mjk/data/dbfs_mount/dbfsdata1',
ENVIRONMENT_VARS='ORACLE_HOME=/app/oracle/12.2,
LD_LIBRARY_PATH=/app/oracle/12.2/lib:/app/oracle/12.2/rdbms/lib,
TNS_ADMIN=/app/oracle/12.2/network/admin',
CLEAN_PROGRAM='/bin/fusermount -u -z /scratch/mjk/data/dbfs_mount',
START_DEPENDENCIES='hard(ora.inst1_srv.svc)',
STOP_DEPENDENCIES='hard(ora.inst1_srv.svc)'"
上記の例には、必須のSTART_PROGRAM
、STOP_PROGRAM
、CHECK_PROGRAMS
およびCLEAN_PROGRAM
属性の他に、次のような属性が含まれています。
-
ENVIRONMENT_VARS
属性は、プログラムを起動したり停止するときに渡されるカスタム環境変数を指定します。 -
START_DEPENDENCIES
およびSTOP_DEPENDENCIES
依存属性は、DBFSファイル・システムのデータベース・ストアの基になっているデータベース・サービスに起動依存性および停止依存性を作成します。DBFSファイル・システムのアプリケーション要件に基づいた上位レベルのアプリケーション・リソースのDBFSリソースに依存性を作成できます。
注意:
-
前述の構文に示されている
ORACLE_HOME
ディレクトリは例です。 -
DBFSファイル・システム・リソースの
HOSTING_MEMBERS
、SERVER_POOLS
、PLACEMENT
およびCARDINALITY
属性を構成して、Oracle Clusterware標準の配置およびカーディナリティ・プロパティを指定できます。
9.3.3 Oracle Enterprise Managerを使用したリソースの追加
Enterprise Managerを使用してリソースを追加します。
Oracle Enterprise Managerを使用してOracle Clusterwareにリソースを追加するには、次の手順を実行します。
関連トピック
9.3.5 アプリケーションの配置ポリシー
リソースは、配置ポリシー、リソース起動依存性およびサーバーでのアクション・スクリプトの可用性に従って、任意のサーバーで実行できます。
PLACEMENT
リソース属性を使用して、リソースを起動するサーバーをOracle Clusterwareで選択する方法、およびサーバーの障害発生後にリソースを再配置する場所を指定します。HOSTING_MEMBERS
およびSERVER_POOLS
属性を使用してリソースのホスティングに適切なサーバーを指定し、PLACEMENT
属性を使用してリソースの配置をさらに調整します。
PLACEMENT
リソース属性の値を使用して、クラスタへのリソース追加時またはサーバーの障害発生時にOracle Clusterwareでリソースを配置する方法を指定します。HOSTING_MEMBERS
またはSERVER_POOLS
属性のいずれかとともに使用すると、Oracle Clusterwareでクラスタにリソースを配置する方法を構成できます。PLACEMENT
属性の値は次のとおりです。
-
balanced
: Oracle Clusterwareによって、配置に任意のオンライン・サーバー・プールが使用されます。負荷が低いサーバーは負荷が大きいサーバーより優先されます。サーバーの負荷を測定する場合、Oracle Clusterwareでは、そのサーバーでONLINE
状態になっているリソースのLOAD
リソース属性が使用されます。現行のサーバー負荷を測定する場合、Oracle Clusterwareでは、LOAD
の合計値が使用されます。 -
favored
: 値がHOSTING_MEMBERS
、SERVER_POOLS
またはSERVER_CATEGORY
リソース属性のいずれかに割り当てられている場合、この値がプリファレンスを示します。HOSTING_MEMBERS
が移入されSERVER_POOLS
またはSERVER_CATEGORY
のいずれかが設定されると、HOSTING_MEMBERS
によって配置のプリファレンスが示され、SERVER_POOLS
またはSERVER_CATEGORY
によって制限が示されます。たとえばora.cluster.vip
リソースにPLACEMENT
の値をfavored
に設定するポリシーがあり、SERVER_CATEGORY
はHub
に設定され、HOSTING_MEMBERS
はserver_name1
に設定されます。この場合、Oracle Clusterwareはora.cluster.vip
の配置をハブ・カテゴリのサーバーに限定し、server_name1
と呼ばれるサーバーを優先します。 -
restricted
: Oracle Clusterwareでは、SEVER_POOLS
リソース属性に示されているサーバー・プールに属しているサーバー、SERVER_CATEGORY
リソース属性で構成されているような特定のカテゴリのサーバーまたはHOSTING_MEMBERS
リソース属性に示されているサーバーのみがリソースの配置の対象として考慮されます。値を指定できるのは、これらのリソース属性のいずれか1つにのみであり、そうしないとエラーが発生します。
9.3.6 アプリケーションおよびアプリケーション・リソースの登録解除
リソースを登録解除するには、crsctl delete resource
コマンドを使用します。アプリケーションまたはリソースがONLINEであるか、または別のリソースで必要とされている場合は、-force
オプションを使用しないかぎり、そのアプリケーションまたはリソースを登録解除することはできません。次の例では、Apache Webサーバー・アプリケーションを登録解除します。
$ crsctl delete resource myApache
Oracle Clusterwareでリソースが管理されない場合は、クリーンアップ手順としてcrsctl delete resource
コマンドを実行します。不要なリソースは登録解除することをお薦めします。
9.4 リソースの管理
この項には次のトピックが含まれます:
9.4.1 アプリケーション・リソースの登録
Oracle Clusterwareで管理する各アプリケーションは、リソースとしてOCRに登録されて格納されます。
crsctl add resource
コマンドを使用して、アプリケーションをOCRに登録します。たとえば、前述の例のApache Webサーバー・アプリケーションを登録するには次のコマンドを入力します。
$ crsctl add resource myApache -type cluster_resource
-group group_name -attr "ACTION_SCRIPT=/opt/cluster/scripts/myapache.scr, PLACEMENT=restricted,
SERVER_POOLS=server_pool_list,CHECK_INTERVAL=30,RESTART_ATTEMPTS=2,
START_DEPENDENCIES=hard(appsvip),STOP_DEPENDENCIES=hard(appsvip)"
前述の例では、-group
パラメータを指定して、リソースをリソース・グループに割り当てることができます。
リソースを変更した場合は、crsctl modify resource
コマンドを実行してOCRを更新します。
9.4.2 アプリケーション・リソースの起動
crsctl start resource
コマンドを使用してリソースを起動します。
Oracle Clusterwareの外部でリソースを手動で起動または停止すると、リソースのステータスを無効にできます。また、Oracle Clusterwareによって、手動で停止操作を実行したリソースの再起動が試行される場合もあります。
Oracle Clusterwareに登録されているアプリケーション・リソースを起動するには、crsctl start resource
コマンドを使用します。次に例を示します。
$ crsctl start resource myApache
このコマンドは、アクション・プログラムがコールされるたびにそのアクション・プログラムから成功または失敗の通知を受け取るために待機します。Oracle Clusterwareでは、障害しきい値を超えたために停止したアプリケーション・リソースを起動できます。起動する前に、crsctl add resource
を使用してリソースを登録する必要があります。
crsctl start resource
コマンドをリソースで実行すると、リソースのTARGET
値がONLINE
に設定されます。Oracle Clusterwareは、start
アクションを指定してアクション・プログラムを実行し、TARGET
と一致するように状態の変更を試行します。
クラスタ・サーバーでリソースを起動中にそのサーバーで障害が発生した場合、crsctl status resource
コマンドを使用して、クラスタ上のリソースの状態をチェックします。
9.4.3 アプリケーションおよびアプリケーション・リソースの再配置
crsctl relocate resource
コマンドを使用して、アプリケーションおよびアプリケーション・リソースを再配置します。
たとえば、rac2
というサーバーにApache Webサーバー・アプリケーションを再配置するには、次のコマンドを実行します。
# crsctl relocate resource myApache -n rac2
アクション・プログラムがコールされるたびに、crsctl relocate resource
コマンドがSCRIPT_TIMEOUT
リソース属性の値に指定された期間待機して、アクション・プログラムから成功または失敗の通知を受け取ります。再配置の試行は、次の場合に失敗します。
-
アプリケーションに、初期サーバー上で実行される必須リソースが存在する。
-
指定したリソースが必要なアプリケーションが、初期サーバー上で実行される。
アプリケーションおよびその必須リソースを再配置するには、crsctl relocate resource
コマンドで-f
オプションを使用します。Oracle Clusterwareは、状態に関係なく、アプリケーションに必要なすべてのリソースを再配置または起動します。
また、crsctl relocate resourcegroup
コマンドを使用してリソース・グループを再配置することもできます。このコマンドでは、最初にリソース・グループ内のリソースを停止してから、宛先サーバーでリソース・グループを再配置します。
オンライン再配置
RELOCATE_KIND=online
)に設定できます。これにより、crsctl relocate resource
またはcrsctl relocate resourcegroup
コマンドを実行すると、宛先サーバーで新しいリソース・インスタンス(またはリソース・グループに属するリソースの複数のインスタンス)が起動されてから、元のサーバーでインスタンスが停止されます。
注意:
オンライン再配置を使用する前に、リソースがオンライン再配置中に起動された追加のリソース・インスタンスを管理できることを確認してください。9.4.4 アプリケーションおよびアプリケーション・リソースの停止
crsctl stop resource
コマンドを使用してアプリケーション・リソースを停止します。
コマンドによってリソースのTARGET
値はOFFLINE
に設定されます。Oracle Clusterwareは、常にリソースの状態をターゲットの状態に一致させようとするため、Oracle Clusterwareのサブシステムによって、アプリケーションが停止されます。次の例では、Apache Webサーバーを停止します。
# crsctl stop resource myApache
このリソースに対するhard停止依存性が別のリソースに定義されている場合、強制(-f
)オプションを使用しないかぎり、このリソースを停止することはできません。他のリソースが依存しているリソース上でcrsctl stop resource resource_name -f
コマンドを使用し、それらの依存リソースが実行されている場合は、停止するリソースに依存するリソースがOracle Clusterwareによって停止されます。
9.4.5 クラスタウェア・アプリケーションおよびアプリケーション・リソースのステータス情報の表示
crsctl status resource
コマンドを使用して、クラスタ・サーバー上のアプリケーションおよびリソースのステータス情報を表示します。
次の例では、Apache Webサーバー・アプリケーションのステータス情報を表示します。
# crsctl status resource myApache
NAME=myApache
TYPE=cluster_resource
TARGET=ONLINE
STATE=ONLINE on server010
このコマンドは、他にも次の情報を返します。
-
リソースが再起動された回数
-
障害間隔内にリソースで障害が発生した回数
-
リソースの再起動可能回数または障害発生許容回数の最大数
-
リソースのターゲット状態および通常のステータスの情報
特定のリソースの詳細を表示するには、crsctl status resource resource_name
コマンドで-f
オプションを使用します。
次のコマンドを入力して、すべてのアプリケーションおよびリソースの情報を表形式で表示します。
# crsctl status resource -t
9.5 Oracle Clusterwareによるリソースの自動再起動の管理
いくつかのリソース属性を設定することによって、Oracle Clusterwareが自動的にリソースを再起動しないようにできます。また、Oracle Clusterwareによるリソースの再起動カウンタの管理を制御することもできます。さらに、Oracle Clusterwareがリソースで実行するstart
、stop
およびcheck
アクションのタイムアウト値をカスタマイズすることもできます。
この項には次のトピックが含まれます:
9.5.1 Oracle Clusterwareリソースの自動再起動の回避
自動再起動を管理するには、AUTO_START
リソース属性を使用して、サーバーの再起動時にOracle Clusterwareによって自動的にリソースが起動されるかどうかを指定します。
サーバーを再起動すると、Oracle Clusterwareによって、サーバーの起動直後に実行されるリソースの起動が試行されます。ただし、リソースが依存するシステム・コンポーネント(ボリューム・マネージャ、ファイル・システムなど)が実行されていない場合は、リソースの起動が失敗する可能性があります。これは特に、リソースが依存するシステム・コンポーネントをOracle Clusterwareが管理しない場合に該当します。
注意:
リソースのAUTO_START
リソース属性の値にかかわらず、起動対象のリソースに対するhard起動依存性またはweak起動依存性が別のリソースに定義されている場合、または別のリソースに対するpullup起動依存性が起動対象のリソースに定義されている場合は、そのリソースを起動できます。
9.5.2 Oracle Clusterwareリソースの再起動試行カウンタの自動管理
リソースで障害が発生した場合、Oracle Clusterwareでは、RESTART_ATTEMPTS
リソース属性に指定された回数だけリソースの再起動が試行されます。この属性は、障害が発生したリソースの再起動を試行する回数を指定するものではなく(常に1回の試行)、ローカルでリソース障害が何回発生した場合にOracle Clusterwareによってフェイルオーバーが試行されるかを指定するものです。CRSDプロセスは、内部カウンタを保持して、リソースがOracle Clusterwareによって再起動される回数を追跡します。Oracle Clusterwareがリソースの再起動を試行した回数はRESTART_COUNT
リソース属性に反映されます。Oracle Clusterwareでは、リソースの安定性に基づいて再起動試行カウンタが自動的に管理されます。UPTIME_THRESHOLD
リソース属性は、リソースがオンラインである必要がある時間を決定し、その時間が経過すると、RESTART_COUNT
属性は0にリセットされます。また、RESTART_COUNT
リソース属性は、リソースがユーザーによって再配置または再起動された場合、あるいはリソースが別のサーバーにフェイルオーバーした場合にも、0にリセットされます。