日本語PDF

8 Oracle Clusterwareを使用したアプリケーションの高可用性の実現

クラスタ内でアプリケーション、プロセスまたはサーバーに障害が発生した場合、その影響をユーザーにまったく気付かれないようにすることはできないまでも、できるかぎり短時間に抑える必要があります。たとえば、サーバーでアプリケーションに障害が発生した場合、そのアプリケーションをクラスタ内の別のサーバーで再起動して、そのアプリケーションの使用に対する影響を最小限にするか、またはなくしてしまうことができることを意味します。同様に、クラスタ内のサーバーで障害が発生した場合、そのサーバーで実行されているすべてのアプリケーションおよびプロセスを別のサーバーにフェイルオーバーして、ユーザーへのサービスの提供を継続できる必要があります。Oracle Clusterwareでは、組込みのgeneric_applicationリソース・タイプまたはカスタマイズ可能なスクリプトおよびアプリケーション・エージェント・プログラムと、アプリケーションとプロセスに割り当てられるリソース属性を使用することで、これらすべてのエンティティを管理し、高可用性を確保します。

この章では、Oracle Clusterwareを使用して、アプリケーションの起動、停止、監視、再起動および再配置を行う方法について説明します。Oracle Clusterwareは、Oracle Real Application Clusters(Oracle RAC)の基礎となるクラスタ・ソリューションです。Oracle RACデータベースを管理する場合と同じ機能および方針がアプリケーションの管理に適用されます。

この章の内容は次のとおりです。

• Oracle Clusterwareリソースおよびエージェント

• Oracle Clusterwareを使用した高可用性の実現の概要

• リソースとしてのアプリケーションの登録

• リソースの管理

• Oracle Clusterwareによるリソースの自動再起動の管理

Oracle Clusterwareリソースおよびエージェント

この項では、アプリケーションの高可用性を確保するために、Oracle Clusterwareでリソースの監視および管理に使用されるフレームワークについて説明します。

この項には次のトピックが含まれます:

• Oracle Clusterwareのリソース

• Oracle Clusterwareのリソース・タイプ

• Oracle Clusterwareのエージェント

• アクション・スクリプト

• エージェントの作成

• Oracle Clusterwareへのリソースの登録

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属性内にリソースの名前を指定することによって、あるリソースをそのリソース・グループのクリティカル・リソースとしてマークできます。

仮想マシンのリソース

仮想マシンは、ゲスト・オペレーティング・システムと呼ばれる稼働中のオペレーティング・システム用に作成された環境です。仮想マシンは、コンピュータのデスクトップにウィンドウとして表示され、このウィンドウは全画面モードで表示することも、別のコンピュータ上にリモートで表示することもできます。

仮想マシンは基本的に、その動作を決定するパラメータのセットであり、コンピュータ・システム・ハードウェアと似ています。パラメータには、ハードウェア設定(仮想マシンのメモリー量など)や状態情報(仮想マシンが現在実行中かどうかなど)が含まれます。

ブラックボックス仮想マシンは、その内容が管理インタフェースに認識されない仮想マシンです。ブラックボックス仮想マシンについて認識される情報は、それに含まれる仮想ハードウェア、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にフェイルオーバーされ、新しい物理ホスト上でブラックボックス仮想マシンが起動されます。

図8-1 Oracle Database Applianceでの高可用性仮想マシン

「図8-1 Oracle Database Applianceでの高可用性仮想マシン」の説明

仮想マシン・アーキテクチャ

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

リソース・グループ

リソース・グループは、論理的に関連したリソースのグループのコンテナです。

アプリケーションは、アプリケーション・リソースと関連アプリケーション・リソース(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属性を構成します。

表8-1 リソース・グループの依存性のタイプおよび修飾子

依存性のタイプ	説明
hard起動	このリソース・グループを起動する前に特定の他のリソース・グループが(クラスタ内のどこかで)オンラインになっている必要があるという要件を指定します。 たとえば: START_DEPENDENCIES=hard([global: | intermediate: | uniform: ] other_resource_group) いずれかの依存リソース・グループの起動に失敗すると、Oracle Clusterwareはこのリソース・グループの起動を取り消します。
weak起動	このリソース・グループの起動前に特定の他のリソース・グループの起動を試行する必要があるという要件を指定します。特定の他のリソース・グループの起動に失敗した場合でも、Oracle Clusterwareによってこのリソース・グループが起動されます。 たとえば: START_DEPENDENCIES=weak([global: | concurrent: | uniform: ] other_resource_group)
pullup	依存リソース・グループの起動時にこのリソース・グループを自動的に起動する必要がある場合は、この依存性を使用します。 たとえば: START_DEPENDENCIES=pullup([intermediate: | always: ]other_resource_group]) リソース・グループ間に停止依存性が存在する場合には、この依存性を使用することをお薦めします。
hard停止	この依存性は、特定の他のリソース・グループが実行を停止したときにこのリソース・グループを停止するという必須要件を指定します。 たとえば: STOP_DEPENDENCIES=hard([intermediate: | global: | shutdown: ]other_resource_group)
attraction	特定の他のリソース・グループとの共存を優先することを指定します。 たとえば: START_DEPENDENCIES=attraction([intermediate:]other_resource_group) Oracle Clusterwareは、特定の他のリソース・グループがすでにオンラインになっている同じサーバー上で、このリソース・グループの起動を試行します。
dispersion	特定の他のリソース・グループとの非共存を優先することを指定します。Oracle Clusterwareは、dispersion依存性を持つオンライン・リソース・グループの数が最も少ないサーバー上で、このリソース・グループの起動を試行します。 たとえば: START_DEPENDENCIES=dispersion([intermediate: | active: | pool:]:other_resource_group)
exclusion	このリソース・グループを特定の他のリソース・グループと同じサーバー上で実行しないことを必須要件として指定します。Oracle Clusterwareは、このリソース・グループの起動を拒否するか、依存リソース・グループを停止して別のサーバー上で再起動します。 たとえば: START_DEPENDENCIES=exclusion[(preempt_pre: | preempt_post )] other_resource_group)

リソース・グループの障害とリカバリ

前述のように、クリティカル・リソースによってリソース・グループの状態とフェイルオーバーが決まります。

クリティカル・リソースの障害とリカバリ

• リソース・グループのクリティカル・リソースに障害が発生すると、リソース・グループは即時に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がリソースのすべてのローカル再起動試行数に達した場合、リソース・グループの状態への影響はありません。障害の原因を修正した後、クリティカルでないリソースを明示的に起動する必要があります。

リソース・グループ・タイプ

Oracle Clusterwareにおいて、リソース・タイプはリソースのクラス用のテンプレートです。

リソース・グループ・タイプは、すべてのリソース・グループに共通に適用できる属性セットを提供します。リソース・グループの作成時に、リソース・グループ・タイプを指定する必要があります。Oracle Clusterwareには、2つのベース・リソース・グループ・タイプ(local_resourcegroupおよびcluster_resourcegroup)が用意されています。ベース・リソース・タイプの属性はリソースと似ており、その一部は構成可能です。

ローカル・リソース・グループ・タイプ

ローカル・リソースのみを含むリソース・グループを作成する場合は、local_resourcegroupタイプを使用します。このタイプのリソース・グループのインスタンスは、クラスタ内の各ノードで実行できます。ローカル・リソース・グループ・タイプの属性は次のとおりです。

• 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_resourcegroupのリソース・グループには、クラスタ内の静的または動的なサーバー・セット上で実行される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

リソース・グループの使用

CRSCTLを使用して、リソース・グループおよびリソース・グループ・タイプを作成し、リソースをリソース・グループに追加します。

リソース・グループを使用するには、まず、組込みリソース・グループ・タイプまたは作成したリソース・グループ・タイプに基づいて、リソース・グループを作成する必要があります。リソース・グループを作成したら、リソースをそれに追加できます。

1. リソース・グループを作成するには、次のコマンドを使用します。

   $ crsctl add resourcegroup group_name -type group_type

   前述のコマンドでは空のリソース・グループが作成され、これにリソースを追加できます。リソース・グループの名前およびリソース・グループ・タイプを指定する必要があります。カスタム・リソース・グループ・タイプに基づくリソース・グループにすることを選択した場合は、次のステップの説明に従って、まずリソース・グループ・タイプを作成する必要があります。
2. カスタム・リソース・グループ・タイプに基づくリソース・グループを作成する場合は、次のようにして、リソース・グループ・タイプを作成する必要があります。

   $ crsctl add resourcegrouptype group_type_name –basetype base_group_type {-file file_path | -attr "attribute_name=attribute_value"}

   前述のコマンドではリソース・グループ・タイプが作成され、このリソース・グループ・タイプに基づいて作成したすべてのリソース・グループに対する単一の属性セットが提供されます。既存のリソース・グループ・タイプをベース・リソース・グループ・タイプとして指定し、行区切りの属性リスト/属性値ペアを含むファイルのパスを指定するか、コマンドラインでカンマ区切りの属性リスト/属性値ペアを指定する必要があります。
3. リソース・グループを作成した後は、次のようにして、リソース・グループへのリソースの追加を開始できます。

   $ crsctl add resource resource_name -group group_name

   リソースの追加先のリソース・グループが存在している必要があり、かつ、追加するリソースがオフライン状態になっている必要があります。リソースがメンバーになれるリソース・グループは、1つのみです。複数のアプリケーションによって共有されているリソース(ファイル・システムなど)がある場合は、これらのリソースをそれぞれ個別のリソース・グループに配置することをお薦めします。

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でこのタイプのリソースを登録することはできません。

  すべての属性を指定する場合、次のルールが適用されます。

  1. リソースを停止する場合、STOP_PROGRAMを指定すると、Oracle ClusterwareはSTOP_PROGRAMをコールします。それ以外の場合では、Oracle Clusterwareは、PID_FILESまたはEXECUTABLE_NAMES属性のいずれかから取得されたPIDでオペレーティング・システムのkill -9に相当するコマンドを使用します。

  2. アプリケーションの現在の状態を確立する必要がある場合、CHECK_PROGRAMSを指定すると、Oracle ClusterwareはCHECK_PROGRAMSをコールします。それ以外の場合では、Oracle Clusterwareは、PID_FILESまたはEXECUTABLE_NAMES属性のいずれかから取得されたPIDでオペレーティング・システムのps -pに相当するコマンドを使用します。

  3. リソースをクリーンアップする場合、CLEAN_PROGRAMを指定すると、Oracle ClusterwareはCLEAN_PROGRAMをコールします。それ以外の場合では、Oracle Clusterwareは、PID_FILESまたはEXECUTABLE_NAMES属性のいずれかから取得されたPIDでオペレーティング・システムのkill -9に相当するコマンドを使用します。

Oracle Clusterwareのエージェント

Oracle Clusterwareでは、リソース固有のすべてのコマンドはエージェントと呼ばれるエンティティを介して実行されます。

アプリケーションがOracle Clusterwareにリソースとして登録されると、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_action APIを使用して起動されたときに起動されます。

• 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です。

エージェント・フレームワークでは、表8-2に示す状態のリソースが、CHECK_INTERVALリソース属性またはOFFLINE_CHECK_INTERVALリソース属性で指定される一定の間隔で暗黙的に監視されます。

表8-2 エージェント・フレームワークの監視特性

状態	条件	頻度
ONLINE	常時	\ CHECK_INTERVAL
PARTIAL	常時	CHECK_INTERVAL
OFFLINE	OFFLINE_CHECK_INTERVALリソース属性の値が0より大きい場合のみ。	OFFLINE_CHECK_INTERVAL
UNKNOWN	監視されるのは、リソースが前述のいずれかの条件のために以前に監視されていた場合のみ。	ONLINEのときにのみ状態がUNKNOWNになる場合は、CHECK_INTERVALの値が使用されています。それ以外の場合は、監視されていません。

エージェントが起動されるたびに、エージェントが監視するすべてのリソースの状態はUNKNOWNに設定されます。エージェント・フレームワークでは、Oracle Clusterwareからの最初のプローブ・リクエストを受信すると、すべてのリソースに対してCHECKエントリ・ポイントが実行され、現在の状態が確認されます。

リソースのCHECKアクションが正常に完了すると、リソースの状態は前述の状態のいずれかに遷移します。次に、エージェント・フレームワークによって、Oracle Clusterwareから発行されるコマンドに基づいてリソースが起動されます。エージェント・フレームワークでは、すべてのアクションが完了するとCHECKアクションが起動され、リソースの現在の状態が確認されます。エージェント・フレームワークでは、リソースが表8-2に示す監視対象の状態のいずれかである場合、CHECKエントリ・ポイントが定期的に実行され、リソースの状態に変更がないかどうかが確認されます。

デフォルトでは、エージェント・フレームワークでオフラインのリソースは監視されません。ただし、OFFLINE_CHECK_INTERVAL属性の値が0より大きい場合、エージェント・フレームワークでオフラインのリソースが監視されます。

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の両方のリソース・タイプは、この・エージェントを使用するように構成されており、また、これらのタイプのリソースは、このエージェントを自動的に利用します。

また、任意の方法でリソースを管理するために独自のエージェントを作成することもできます。

アクション・スクリプト

アクション・スクリプトは、リソースを開始、停止、確認またはクリーンアップする1つ以上のアクションを定義します。

エージェント・フレームワークは、C/C++アクションなしに、これらのアクションを起動します。アクション・スクリプトを使用すると、C/C++エントリ・ポイントおよびスクリプト・エントリ・ポイントを含むエージェントを作成できます。すべてのアクションがアクション・スクリプトに定義されている場合、スクリプト・エージェントを使用して、アクション・スクリプトに定義されているアクションを起動できます。

アクション・スクリプトに定義されているアクションを起動する前に、エージェント・フレームワークは、必要なすべての属性をリソース・プロファイルから環境にエクスポートします。アクション・スクリプトは、stdout/stderrにメッセージを記録でき、エージェント・フレームワークは、エージェント・ログにこれらのメッセージを出力します。ただし、アクション・スクリプトは、stdout/stderrに出力されるメッセージに次のいずれかのタグを接頭辞として追加することで、特別なタグを使用して、進捗、警告またはエラーのメッセージをcrs*クライアント・ツールに送信できます。

CRS_WARNING:
CRS_ERROR:
CRS_PROGRESS:

エージェント・フレームワークは、最終メッセージをcrs*クライアントに送信するときに、接頭辞として追加されたタグを削除します。

リソース属性は、接頭辞_CRS_を持つ環境変数としてアクション・スクリプト内からアクセス可能です。たとえば、START_TIMEOUT属性は、_CRS_START_TIMEOUTという環境変数になります。

エージェントの作成

特定のアプリケーションのエージェント作成では、次のステップが実行されます。

1. スクリプト、CまたはC++のいずれかでエージェント・フレームワークのエントリ・ポイントを実装します。
2. エージェントの実行可能ファイルを作成します(CエージェントおよびC++エージェントの場合)。
3. エントリ・ポイントで必要なすべてのパラメータを収集し、新しいリソース・タイプを定義します。AGENT_FILENAME属性を、新しく作成した実行可能ファイルの絶対パスに設定します。

CおよびC++エージェントの作成およびデプロイ

Oracle Clusterwareには、アプリケーションに高可用性エージェントを実装するエージェント・フレームワークを使用したCおよびC++エージェントの例が含まれています。

付録Fは、demoagent1.cppというエージェントの例を説明しています。このエージェントは、ディスク上のファイルを表すリソースを管理し、次のタスクを実行します:

• 起動時: ファイルを作成します

• 停止時: ファイルを正常に削除します

• チェック時: ファイルが存在するかどうかをチェックします

• クリーンアップ時: ファイルを強制的に削除します

Oracle Clusterwareに対するこの特定のリソースを記述するには、このリソース・クラスのすべての特徴的な属性を含むリソース・タイプを最初に作成する必要があります。この場合、記述する必要のある属性は、管理するファイルの名前のみです。次のステップは、リソースおよびそのエージェントを設定して、リソースの機能をテストする方法を示しています。

1. 提供されるdemoagent1.cppソース・ファイルおよびmakefileを使用してC++エージェントをコンパイルします。ローカルのコンパイラ、リンカーのパスおよびインストール場所に基づいたmakefileを変更します。出力は、demoagent1という実行可能ファイルです。この例は、実行可能ファイルが、クラスタの各ノードの/path/to/というディレクトリにあることを想定しています。
2. CRSCTLを使用して、次のように新しいリソース・タイプを追加します。

   $ crsctl add type hotfile_type -basetype cluster_resource -attr
      "ATTRIBUTE=PATH_NAME,TYPE=string,DEFAULT_VALUE=default.txt,
      ATTRIBUTE=AGENT_FILENAME,TYPE=string,DEFAULT_VALUE=/path/to/demoagent1"

   前述のコマンドの例では、PATH_NAMEがこのタイプの各ノードのディレクトリ・パスです。PATH_NAMEの値をディスク上の適切なディレクトリ場所に変更します。

   AGENT_FILENAME属性は、このリソース・タイプのリソース管理コマンドを実装するエージェント・バイナリの場所を指定します。このステップにより、Oracle Clusterwareに新しいリソース・タイプが追加されます。

3. 上記ステップで定義されているタイプに基づいて、次のように新しいリソースを作成します。

   $ crsctl add res file1 -type hotfile_type -attr "PATH_NAME=/var/log/file1.txt"
   $ crsctl add res file2 -type hotfile_type -attr "PATH_NAME=/var/log/file2.txt"

   前述のコマンドにより、Oracle Clusterwareが管理および監視するfile1およびfile2というリソースが追加されます。

4. CRSCTLを使用して、次のようにリソースを起動および停止します。

   $ crsctl start res file1
   $ crsctl start res file2
   $ crsctl relocate res file1
   $ crsctl stop res file2

   リソースが起動および停止されると、Oracle Clusterwareはディスク・ファイルを作成および削除します。

Oracle Clusterwareへのリソースの登録

crsctl add resourceコマンドを使用して、Oracle Clusterwareにリソースを登録します。

アプリケーションをリソースとして登録するには:

$ 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', ..."]

Oracle Clusterwareを使用した高可用性の実現の概要

Oracle Clusterwareでは、可用性が向上するような構成方法に基づいてリソースおよびリソース・グループが管理されます。

リソースおよびリソース・グループは、Oracle Clusterwareで次の操作が実行されるように構成できます。

• クラスタまたはサーバーの起動時のリソースおよびリソース・グループの起動

• 障害が発生した場合のリソースおよびリソース・グループの再起動

• 各サーバーへのリソースおよびリソース・グループの再配置(他のサーバーを使用できる場合)

Oracle Clusterwareを使用してアプリケーションを管理するには:

1. generic_applicationリソース・タイプを使用するか、スクリプト・エージェントにカスタム・スクリプトを記述するか、新しいエージェントを作成します。

2. アプリケーションをOracle Clusterwareにリソースとして登録します。

   単一のアプリケーションで複数のリソースを登録する必要がある場合は、Oracle Clusterwareによって単一のリソースのように管理されるリソース・グループを作成できます。リソース・グループ内のリソース間の関連する依存性を定義することが必要となる場合があります。

3. リソースまたはリソース・グループに適切な権限を割り当てます。

4. リソースおよびリソース・グループを起動または停止します。

リソースで障害が発生すると、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コマンドを使用して、停止対象のリソースに依存するすべてのリソースを最初に停止し、そのリソースを強制終了することができます。

リソース属性

リソース属性は、Oracle Clusterwareで特定のリソース・タイプのリソースを管理する方法を定義します。各リソース・タイプには一意の属性セットがあります。一部のリソース属性はリソースの登録時に指定されますが、その他のリソース属性はOracle Clusterwareによって内部的に管理されます。

ノート:

新しいリソース属性を定義できる場合でも、使用できる文字はUS-7 ASCIIのみです。

リソースの状態

クラスタ内のすべてのリソースは、いつでも特定の状態になっています。その状態は、特定のアクションまたはイベントによって変更される可能性があります。

表8-3に、予想されるリソースの状態を示します。

表8-3 予想されるリソースの状態

状態	説明
ONLINE	リソースは実行されています。
OFFLINE	リソースは実行されていません。
UNKNOWN	リソースの停止の試行に失敗しました。Oracle Clusterwareでは、この状態のリソースはアクティブに監視されません。アプリケーション固有のアクション(プロセスの停止など)を実行してリソースをオフラインにし、crsctl stop resourceコマンドを実行してリソースの状態をOFFLINEに再設定する必要があります。
INTERMEDIATE	次の2つのイベントのいずれかにより、リソースがINTERMEDIATE状態になる場合があります。 Oracle Clusterwareでリソースの状態を判別できませんが、リソースはオンラインになろうとしていたか、または最後に正確に認識されたときのリソースの状態はオンラインでした。通常、checkアクションを阻止する条件が適用されなくなるため、リソースは時間の経過とともにこの状態から遷移します。 リソースが部分的にオンラインになっています。たとえば、Oracle Database VIPリソースのホーム・サーバーがクラスタから削除された場合、Oracle Database VIPリソースは別のサーバーにフェイルオーバーされます。ただし、このVIPがホーム・サーバー以外のサーバーに存在する間、アプリケーションはこのVIPを使用してデータベースにアクセスすることはできません。同様に、Oracle Databaseインスタンスが起動されていても、オープンされていない場合も、リソースは部分的にオンラインになり、このリソースは実行されていますが、サービスを提供することはできません。 Oracle Clusterwareでは、INTERMEDIATE状態のリソースはアクティブに監視され、通常、ユーザーの介入は必要ありません。前述の理由1のためリソースがINTERMEDIATE状態になっている場合、Oracle Clusterwareは、リソースの状態が確立されるとすぐにリソースをINTERMEDIATE状態から遷移させます。 前述の理由2のためリソースがINTERMEDIATE状態になっている場合、リソースは、部分的にオンラインであるかぎり、この状態のままになります。たとえば、VIPのホーム・サーバーは、VIPがスイッチオーバーできるようにクラスタに再度参加する必要があります。データベース管理者は、データベース・インスタンスをオープンするコマンドを発行する必要があります。 ただし、いずれの場合も、Oracle Clusterwareでは、リソースは適切になるとすぐにINTERMEDIATE状態から自動的に遷移します。STATE_DETAILSリソース属性を使用して、リソースがINTERMEDIATE状態である理由を説明し、リソースをこの状態から遷移させるための解決策を提供します。

リソース依存性

リソースは他のリソースに依存するように構成でき、これによって、依存先リソースの特定の条件が満たされる場合にのみ、依存リソースを起動または停止できます。たとえば、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以降のリリースでは非推奨です。

リソース依存性は、起動および停止カテゴリに分類されます。この分割によって、リソースとリソース・タイプ間の起動依存性および停止依存性が向上され、拡張されます。

この項には次のトピックが含まれます:

• 起動依存性

• 停止依存性

起動依存性

Oracle Clusterwareでは、リソースの起動試行の評価が開始されると、そのリソースのプロファイルに含まれる起動依存性が考慮されます。START_DEPENDENCIESリソース属性を使用して、リソースの起動依存性を指定します。各依存性で修飾子を使用して、依存性をさらに詳細に構成できます。

この項では、次の起動依存性について説明します。

• attraction

• dispersion

• exclusion

• hard

• pullup

• weak

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依存性が表現されています。

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修飾子を使用します。

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は、可能であれば、問題のあるリソースを元の状態に戻そうとします。

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修飾子を必ずタイプの直前に指定する必要があります。

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修飾子を使用すると、特定のリソース・タイプに対して依存性を有効にするように指定できます。

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のすべてのインスタンスの起動を試行します。

停止依存性

Oracle Clusterwareでは、リソースが停止される(リソースの状態がONLINEから他の状態に変更される)たびに、リソース間の停止依存性が考慮されます。

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修飾子を使用してリソースを停止します。

リソース状態のリカバリに対するリソース依存性の影響

リソースの実行を続行する計画である場合に、リソースが実行されている状態から実行されていない状態に遷移する場合、この遷移はリソース障害と呼ばれます。

この時点で、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の再起動が試行されます。

リソースの配置

起動試行の評価の一部として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で起動を試行しているリソースに関連する配置ポリシーまたはリソースの依存性のいずれも配置の決定に影響を及ぼしません。

リソースとしてのアプリケーションの登録

この項では、アプリケーションを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によって、すべての構成可能なオプションが提供されます。

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|...]]

アプリケーション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

Oracle Enterprise ManagerによるアプリケーションVIPの追加

Oracle Enterprise Managerを使用してアプリケーションVIPを追加するには、次の手順を実行します。

1. Oracle Enterprise Manager Cloud Controlにログインします。
2. 変更するクラスタ・ターゲットを選択します。
3. クラスタ・ターゲットのメニューから、「管理」→「リソース」→「管理」を選択します。
4. クラスタ管理者のユーザー名およびパスワードを入力して、「リソースの管理」ページを表示します。
5. 「アプリケーションVIPの追加」をクリックします。
6. 「名前」フィールドにVIPの名前を入力します。
7. 「ネットワーク番号」フィールドにネットワークの番号を入力します。
8. 「インターネット・プロトコル・アドレス」フィールドにVIPのIPアドレスを入力します。
9. 「プライマリ・ユーザー」フィールドにrootと入力します。Oracle Enterprise Managerは、ログイン時に使用するユーザー名をデフォルト値とします。
10. VIPをすぐに起動する場合は、「作成後にリソースを開始」を選択します。
11. 「続行」をクリックして「確認: VIPリソースの追加」ページを表示します。
12. クラスタの資格証明としてrootおよびルート・パスワードを入力します。
13. 「続行」をクリックしてアプリケーションVIPを作成します。

ユーザー定義のリソースの追加

Oracle Clusterwareにはいつでもリソースを追加できます。

ただし、別のリソースに依存しているリソースを追加する場合は、最初にそのリソースが依存しているリソースを追加します。

この項の例では、クラスタへのリソースの追加を簡単にするために、アクション・スクリプトmyApache.scrが各ノードの/opt/cluster/scriptsディレクトリに存在していると想定しています。また、アプリケーションをホストするために複数のプールが作成されていると想定します。このサーバー・プールは汎用のサブプールではありませんが、かわりに、最上位のサーバー・プールでアプリケーションをホスティングするために使用されます。

ノート:

スクリプトのメンテナンスを軽減するために、Oracle Automatic Storage Management Cluster File System (Oracle ACFS)などの共有ストレージを使用してアクション・スクリプトを格納することをお薦めします。

この項には次のトピックが含まれます:

• デプロイメント・スキームの決定

• 特定のサーバー・プールへのリソースの追加

• サーバー固有のデプロイメントを使用したリソースの追加

• generic_applicationリソース・タイプを使用するリソースの作成

デプロイメント・スキームの決定

アプリケーションの管理者またはポリシー管理を使用するかどうかを決定する必要があります。管理者管理は、クラスタ構成が変更される可能性が低い、小規模な2ノード構成に使用します。ポリシー管理は、クラスタが3つ以上のノードで構成されている場合に、より動的な構成に使用します。たとえば、リソースがノード1およびノード2のみで実行されている場合、これらのノードにのみ必要なファイルが存在するため、管理者管理がより適切である可能性があります。

Oracle Clusterwareでは、匿名サーバーで構成され、必要なプール・サイズに厳密に基づく、アクセス制御されたサーバー・プールでのアプリケーションのデプロイメントがサポートされています。この場合、管理者定義のクラスタ・ポリシーを使用して、必要なサイズおよび重要度のレベルで、サーバー割当てを制御する必要があります。または、厳密なサーバー割当てまたは優先サーバー割当てを使用することもでき、この場合、リソースは具体的な名前が指定されたサーバーで実行されます。これは、以前のリリースのOracle Clusterwareで使用可能な既存のモデル(現在の管理者管理)を表します。

概念上、両方のデプロイメント・スキームで開発およびデプロイされたアプリケーションをホスティングするクラスタは、サーバーの、論理的に分割された2つのグループと考えることができます。一方のサーバー・グループはサーバー・プールに使用され、ロールの分離およびサーバーの容量制御が可能になります。もう一方のサーバー・グループでは、クラスタ内の名前付きのサーバーに基づく固定割当てが想定されます。

いずれかのデプロイメント・スキームを使用してアプリケーションを管理するには、クラスタにリソースを追加する前にサーバー・プールを作成する必要があります。Genericという名前の組込みサーバー・プールは、管理者ベース管理のアプリケーションによって使用されるサーバーを常に所有します。汎用サーバー・プールは論理的な分割で、異なる管理スキームを使用してクラスタの2つの部分を分割するために使用できます。

サード・パーティの開発者がこのモデルを使用してアプリケーションをデプロイするには、サーバー・プールを使用する必要があります。名前付きのサーバーに基づく、既存のアプリケーション開発およびデプロイメント・モデルを利用するには、汎用サブプール(汎用プールが親であるサーバー・プールで、サーバー・プール属性のPARENT_POOLSで定義される)を使用する必要があります。親として汎用を使用するサブプールを作成し、サーバーをサブプール定義に名前で列挙することによって、名前付きのサーバーが、汎用内に存在すること、および名前付きのサーバー・モデルを使用するアプリケーション専用に使用されることがアプリケーションで保証されます。

特定のサーバー・プールへのリソースの追加

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リソースは停止します。

サーバー固有のデプロイメントを使用したリソースの追加

名前付きのサーバー・デプロイメントを使用するリソースとして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リソース・パラメータにリストされたサーバー・プールは、汎用サーバー・プールの下位プールである必要があることに注意してください。

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標準の配置およびカーディナリティ・プロパティを指定できます。

Oracle Enterprise Managerを使用したリソースの追加

Enterprise Managerを使用してリソースを追加します。

Oracle Enterprise Managerを使用してOracle Clusterwareにリソースを追加するには:

1. Oracle Enterprise Manager Cloud Controlにログインします。
2. 変更するクラスタ・ターゲットを選択します。
3. クラスタ・ターゲットのメニューから、「管理」→「リソース」→「管理」を選択します。
4. クラスタ管理者のユーザー名およびパスワードを入力して、「リソースの追加」ページを表示します。
5. 「名前」フィールドにリソースの名前を入力します。

   ノート:

   リソース名の先頭をピリオドまたはoraという文字列にすることはできません。

6. 「リソース・タイプ」ドロップダウン・リストからcluster_resourceまたはlocal_resourceのいずれかを選択します。
7. 必要に応じて、「説明」フィールドにリソースの説明を入力します。
8. リソースをすぐに起動する場合は、「作成後にリソースを開始」を選択します。
9. 「配置」セクションのオプションのパラメータは、Oracle Clusterwareによってリソースが配置されるクラスタ内の場所を定義します。

   この項の属性は、「Oracle Clusterwareのリソース・リファレンス」で説明されている属性に対応しています。

10. 「アクション・プログラム」セクションの「アクション・プログラム」ドロップダウン・リストから、リソースを管理するためにOracle Clusterwareでアクション・スクリプトをコールするか、エージェント・ファイルをコールするか、またはその両方をコールするかを選択します。

    また、ドロップダウン・リストでの選択に応じて、スクリプト、ファイルまたはその両方へのパスを指定する必要があります。

    「アクション・スクリプト」を選択した場合、「新規アクション・スクリプトの作成」をクリックし、Oracle Enterprise Managerアクション・スクリプト・テンプレートを使用してリソース用のアクション・スクリプトを作成することができます(作成済でない場合)。

11. これ以上のリソースの構成を行うには、「属性」をクリックします。このページでは、開始属性、停止属性、ステータス属性、オフライン監視および定義した属性を構成できます。
12. 「拡張設定」をクリックし、より詳細なリソース属性の構成を有効にします。
13. 「依存性」をクリックして、リソース間の起動および停止の依存性を構成します。
14. リソースの構成が終了したら、「発行」をクリックします。

リソース権限の変更

Oracle Clusterwareでは、リソースを追加したユーザーの権限に基づいてリソースが管理されます。最初にリソースを追加したユーザーがリソースを所有し、リソースはリソースの所有者として実行されます。特定のリソースはrootとして管理する必要があります。root以外のユーザーが、rootとして実行する必要があるリソースを追加する場合は、次のように、rootがリソースを管理するように権限をrootとして変更する必要があります。

1. rootとして次のコマンドを実行して、指定したリソースの権限をrootに変更します。

   # crsctl setperm resource resource_name –o root
   

2. Oracle ClusterwareをインストールしたユーザーとしてOracle Databaseインストール所有者(次の例ではoracle)を有効にして、次のスクリプトを実行します。

   $ crsctl setperm resource resource_name –u user:oracle:r-x
   

3. リソースを起動します。

   $ crsctl start resource resource_name

アプリケーションの配置ポリシー

リソースは、配置ポリシー、リソース起動依存性およびサーバーでのアクション・スクリプトの可用性に従って、任意のサーバーで実行できます。

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つにのみであり、そうしないとエラーが発生します。

アプリケーションおよびアプリケーション・リソースの登録解除

リソースを登録解除するには、crsctl delete resourceコマンドを使用します。アプリケーションまたはリソースがONLINEであるか、または別のリソースで必要とされている場合は、-forceオプションを使用しないかぎり、そのアプリケーションまたはリソースを登録解除することはできません。次の例では、Apache Webサーバー・アプリケーションを登録解除します。

$ crsctl delete resource myApache

Oracle Clusterwareでリソースが管理されない場合は、クリーンアップ・ステップとしてcrsctl delete resourceコマンドを実行します。不要なリソースは登録解除することをお薦めします。

リソースの管理

この項には次のトピックが含まれます:

• アプリケーション・リソースの登録

• アプリケーション・リソースの起動

• アプリケーションおよびアプリケーション・リソースの再配置

• アプリケーションおよびアプリケーション・リソースの停止

• クラスタウェア・アプリケーションおよびアプリケーション・リソースのステータス情報の表示

アプリケーション・リソースの登録

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を更新します。

アプリケーション・リソースの起動

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コマンドを使用して、クラスタ上のリソースの状態をチェックします。

アプリケーションおよびアプリケーション・リソースの再配置

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 (RELOCATE_KIND=online)に設定できます。これにより、crsctl relocate resourceまたはcrsctl relocate resourcegroupコマンドを実行すると、宛先サーバーで新しいリソース・インスタンス(またはリソース・グループに属するリソースの複数のインスタンス)が起動されてから、元のサーバーでインスタンスが停止されます。

ノート:

オンライン再配置を使用する前に、リソースがオンライン再配置中に起動された追加のリソース・インスタンスを管理できることを確認してください。

アプリケーションおよびアプリケーション・リソースの停止

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によって停止されます。

クラスタウェア・アプリケーションおよびアプリケーション・リソースのステータス情報の表示

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

Oracle Clusterwareによるリソースの自動再起動の管理

いくつかのリソース属性を設定することによって、Oracle Clusterwareが自動的にリソースを再起動しないようにできます。また、Oracle Clusterwareによるリソースの再起動カウンタの管理を制御することもできます。さらに、Oracle Clusterwareがリソースで実行するstart、stopおよびcheckアクションのタイムアウト値をカスタマイズすることもできます。

この項には次のトピックが含まれます:

• Oracle Clusterwareリソースの自動再起動の回避

• Oracle Clusterwareリソースの再起動試行カウンタの自動管理

Oracle Clusterwareリソースの自動再起動の回避

自動再起動を管理するには、AUTO_STARTリソース属性を使用して、サーバーの再起動時にOracle Clusterwareによって自動的にリソースが起動されるかどうかを指定します。

サーバーを再起動すると、Oracle Clusterwareによって、サーバーの起動直後に実行されるリソースの起動が試行されます。ただし、リソースが依存するシステム・コンポーネント(ボリューム・マネージャ、ファイル・システムなど)が実行されていない場合は、リソースの起動が失敗する可能性があります。これは特に、リソースが依存するシステム・コンポーネントをOracle Clusterwareが管理しない場合に該当します。

ノート:

リソースのAUTO_STARTリソース属性の値にかかわらず、起動対象のリソースに対するhard起動依存性またはweak起動依存性が別のリソースに定義されている場合、または別のリソースに対するpullup起動依存性が起動対象のリソースに定義されている場合は、そのリソースを起動できます。

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にリセットされます。