| Oracle® Clusterware管理およびデプロイメント・ガイド 11gリリース2 (11.2) B56289-08 |
|
 前 |
 次 |
クラスタ内でアプリケーション、プロセスまたはサーバーに障害が発生した場合、その影響をユーザーにまったく気付かれないようにすることはできないまでも、できるかぎり短時間に抑える必要があります。たとえば、サーバーでアプリケーションに障害が発生した場合、そのアプリケーションをクラスタ内の別のサーバーで再起動して、そのアプリケーションの使用に対する影響を最小限にするか、またはなくしてしまうことができることを意味します。同様に、クラスタ内のサーバーで障害が発生した場合、そのサーバーで実行されているすべてのアプリケーションおよびプロセスを別のサーバーにフェイルオーバーして、ユーザーへのサービスの提供を継続できる必要があります。Oracle Clusterwareは、カスタマイズ可能なアクション・スクリプトおよびアプリケーション・エージェント・プログラムを、アプリケーションとプロセスに割り当てられたリソース属性とともに使用してすべてのエンティティを管理することによって、高可用性を確保します。
この章では、Oracle Clusterwareを使用して、アプリケーションの起動、停止、監視、再起動および再配置を行う方法について説明します。Oracle Clusterwareは、Oracle Real Application Clusters(Oracle RAC)の基礎となるクラスタ・ソリューションです。Oracle RACデータベースを管理する場合と同じ機能および方針がアプリケーションの管理に適用されます。
内容は次のとおりです。
この項では、アプリケーションの高可用性を確保するために、Oracle Clusterwareでリソースの監視および管理に使用されるフレームワークについて説明します。
この項には次のトピックが含まれます:
Oracle Clusterwareでは、アプリケーションおよびプロセスはOracle Clusterwareに登録するリソースとして管理されます。アプリケーションを管理するためにOracle Clusterwareに登録するリソースの数は、アプリケーションによって異なります。1つのプロセスでのみ構成されるアプリケーションは、ほとんどの場合、1つのリソースでのみ表されます。複数のプロセスまたはコンポーネント上に構築されたより複雑なアプリケーションでは、複数のリソースが必要な場合があります。
Oracle Clusterwareのリソースとしてアプリケーションを登録する場合は、リソースの特徴を示すリソース属性を使用してOracle Clusterwareでのアプリケーションの管理方法を定義します。リソース属性の例としては、リソースのチェック頻度、障害が発生してから別のサーバーで起動が試行される(フェイルオーバー)までの間に同じサーバーでリソースの再起動が試行される回数などがあります。また、登録情報には、アクション・スクリプトへのパス、またはアプリケーションの起動、停止、チェックおよびクリーンアップを実行するためにOracle Clusterwareによってコールされるアプリケーション固有のアクション・プログラムも含まれています。
アクション・スクリプトは、Oracle Clusterwareで提供されている汎用スクリプト・エージェントがコールするシェル・スクリプト(Windowsのバッチ・スクリプト)です。アプリケーション固有のエージェントは、ほとんどの場合、Oracle Clusterwareで提供されているAPIを直接コールするCまたはC++プログラムです。
Oracle Clusterware 11gリリース2(11.2)では、リソースの管理にエージェント・プログラム(エージェント)を使用しており、アプリケーションを保護するスクリプトが使用可能になるように次の組込みエージェントが含まれています。
scriptagent: このエージェント(Windowsではscriptagent.exe)は、シェル・スクリプトまたはバッチ・スクリプトを使用してアプリケーションを保護する場合に使用します。cluster_resourceとlocal_resourceの両方のリソース・タイプは、この・エージェントを使用するように構成されており、また、これらのタイプのリソースは、このエージェントを自動的に利用します。
appagent: このエージェントは(Windowsではappagent.exe)、以前のバージョンのOracle Clusterwareで使用されたapplicationリソース・タイプのリソースを自動的に保護します。このエージェントを使用するために構成を行う必要はありません。以前のバージョンのOracle Clusterwareでの方法と同じ方法でアクション・スクリプトが起動されますが、applicationリソース・タイプに対してのみ使用する必要があります。
|
注意: application以外のすべてのタイプのリソースに、scriptagentを使用することをお薦めします。Oracleでは、非推奨のapplicationリソース・タイプとの下位互換用にアプリケーション・エージェントが提供されています。 |
デフォルトでは、リソース・タイプを作成し、(AGENT_FILENAME属性を使用して)リソース・タイプの仕様の一部として異なるエージェントを指定してこの動作を上書きしないかぎり、applicationリソース・タイプ以外のすべてのリソースでスクリプト・エージェントが使用されます。
また、任意の方法でリソースを管理するために独自のエージェントを作成することもできます。
通常、すべてのリソースは一意ですが、共通属性を持つリソースもあります。Oracle Clusterwareでは、これらの類似リソースの編成にリソース・タイプが使用されます。リソース・タイプのメリットは次のとおりです。
必要なリソース属性のみの管理
リソース・タイプに基づくすべてのリソースの管理
Oracle Clusterwareに登録するすべてのリソースには、特定のリソース・タイプが必要です。Oracle Clusterware制御(CRSCTL)ユーティリティを使用して、Oracle Clusterwareに含まれているリソース・タイプに加えて、カスタム・リソース・タイプを定義できます。含まれているリソース・タイプは次のとおりです。
ローカル・リソース: タイプ名がlocal_resourceのローカル・リソースのインスタンスで、クラスタの各サーバーで実行されます。サーバーをクラスタに追加すると、Oracle Clusterwareではローカル・リソースが自動的に拡張され、インスタンスは新しいサーバーに関連付けられます。サーバーをクラスタから削除すると、Oracle Clusterwareでは、削除するサーバーで実行されていたローカル・リソースのインスタンスが自動的に削除されます。ローカル・リソースのインスタンスは、対応するサーバーに固定されており、あるサーバーから別のサーバーにフェイルオーバーされることはありません。
クラスタ・リソース: タイプ名がcluster_resourceのクラスタ対応リソース・タイプで、クラスタ環境を認識し、カーディナリティおよびサーバー間のスイッチオーバーとフェイルオーバーの対象となります。
|
関連項目:
|
|
注意: 以前のバージョンのOracle Clusterwareでは、applicationリソース・タイプのみがサポートされていました。このリソース・タイプはまだ存在しますが、下位互換性を保つ目的でのみです。Oracle Clusterware 11gリリース2(11.2)では、cluster_resourceリソース・タイプを使用して、アプリケーション・タイプのリソースを登録することをお薦めします。cluster_resourceリソース・タイプを使用してアプリケーション・タイプのリソースを登録しない場合は、管理情報について、それらのアプリケーションに対応するドキュメントを参照してください。 |
アプリケーションがOracle Clusterwareにリソースとして登録されると、Oracle Clusterwareでそれらのアプリケーションが管理されます。Oracle Clusterwareでは、特定のリソースを起動、停止および監視できるアプリケーション固有のプリミティブにアクセスできます。Oracle Clusterwareでは、リソース固有のすべてのコマンドはエージェントと呼ばれるエンティティを介して実行されます。
エージェントは、リソースを管理するためのエージェント・フレームワークおよびユーザー・コードを含むプロセスです。エージェント・フレームワークは、アプリケーション固有のコードを組み込んで、カスタマイズされたアプリケーションを管理できるライブラリです。アプリケーションの起動、停止、状態のチェックなど、実際のアプリケーション管理機能のすべてをエージェントにプログラムします。これらの機能はエントリ・ポイントと呼ばれます。
Oracle Clusterwareにかわって、エージェント・フレームワークによりこれらのエントリ・ポイント機能が起動されます。エージェントの開発者は、これらのエントリ・ポイントを使用して、リソースの起動、停止および監視方法に関する、機能を特定のリソースに必要な機能を組み込むことができます。エージェントで複数のリソースを管理できます。
エージェントの開発者は、コードへのコールバックとして次のエントリ・ポイントを設定できます。
START: リソースをオンラインにするエントリ・ポイントです。エージェント・フレームワークでは、Oracle Clusterwareからstartコマンドを受信するたびにこのエントリ・ポイントがコールされます。
STOP: リソースを正常に停止するエントリ・ポイントです。エージェント・フレームワークでは、Oracle Clusterwareからstopコマンドを受信するたびにこのエントリ・ポイントがコールされます。
CHECK: リソースの状態を監視するエントリ・ポイントです。エージェント・フレームワークでは、このエントリ・ポイントが定期的にコールされます。エージェント・フレームワークでは、このアクションで状態変更が検出されると、特定のリソースの状態における変更についてOracle Clusterwareに通知が行われます。
CLEAN: リソースのクリーンアップが必要な場合に機能するエントリ・ポイントです。ユーザーがリソースを強制終了する必要がある場合に起動される操作で、正常な場合の操作ではありません。このコマンドによってリソース固有の環境がクリーンアップされ、リソースを再起動できます。
ABORT: エージェント・フレームワークでは、他のエントリ・ポイントがハングした場合にABORTエントリ・ポイントがコールされ、進行中のアクションが中断されます。エージェントの開発者によって中断機能が指定されていない場合、エージェント・フレームワークによってエージェント・プログラムが終了されます。
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です。
エージェント・フレームワークでは、表6-1に示す状態のリソースが、CHECK_INTERVALまたはOFFLINE_CHECK_INTERVALリソース属性で指定される一定の間隔で暗黙的に監視されます。
表6-1 エージェント・フレームワークの監視特性
| 状態 | 条件 | 頻度 |
|---|---|---|
|
ONLINE |
常時 |
|
|
PARTIAL |
常時 |
|
|
OFFLINE |
|
|
|
UNKNOWN |
監視されるのは、リソースが前述のいずれかの条件の結果として以前に監視されていた場合のみ。 |
|
エージェントが起動されるたびに、エージェントが監視するすべてのリソースの状態はUNKNOWNに設定されます。エージェント・フレームワークでは、Oracle Clusterwareからの最初のプローブ・リクエストを受信すると、すべてのリソースに対してCHECKエントリ・ポイントが実行され、現在の状態が確認されます。
リソースのCHECKアクションが正常に完了すると、リソースの状態は前述の状態のいずれかに遷移します。次に、エージェント・フレームワークによって、Oracle Clusterwareから発行されるコマンドに基づいてリソースが起動されます。エージェント・フレームワークでは、すべてのアクションが完了するとCHECKアクションが起動され、リソースの現在の状態が確認されます。エージェント・フレームワークでは、リソースが表6-1に示す監視対象の状態のいずれかである場合、CHECKエントリ・ポイントが定期的に実行され、リソースの状態に変更がないかどうかが確認されます。
デフォルトでは、エージェント・フレームワークでオフラインのリソースは監視されません。ただし、OFFLINE_CHECK_INTERVAL属性の値が0より大きい場合、エージェント・フレームワークでオフラインのリソースが監視されます。
アクション・スクリプトは、リソースを開始、停止、確認またはクリーンアップする1つ以上のアクションを定義します。エージェント・フレームワークは、C/C++アクションがない場合に、これらのアクションを起動します。アクション・スクリプトを使用すると、C/C++エントリ・ポイントおよびスクリプト・エントリ・ポイントを含むエージェントを作成できます。すべてのアクションがアクション・スクリプトに定義されている場合、スクリプト・エージェントを使用して、アクション・スクリプトに定義されているアクションを起動できます。
アクション・スクリプトに定義されているアクションを起動する前に、エージェント・フレームワークは、必要なすべての属性をリソース・プロファイルから環境にエクスポートします。アクション・スクリプトは、stdout/stderrにメッセージを記録でき、エージェント・フレームワークは、エージェント・ログにこれらのメッセージを出力します。ただし、アクション・スクリプトは、stdout/stderrに出力されるメッセージに次のいずれかのタグを接頭辞として追加することで、特別なタグを使用して、進捗、警告またはエラーのメッセージをcrs*クライアント・ツールに送信できます。
CRS_WARNING CRS_ERROR CRS_PROGRESS
エージェント・フレームワークは、最終メッセージをcrs*クライアントに送信するときに、接頭辞として追加されたタグを削除します。
リソース属性は、接頭辞_CRS_を持つ環境変数としてアクション・スクリプト内からアクセス可能です。たとえば、START_TIMEOUT属性は、_CRS_START_TIMEOUTという環境変数になります。
|
関連項目:
|
特定のアプリケーションのエージェント作成では、次の手順が実行されます。
スクリプト、CまたはC++のいずれかでエージェント・フレームワークのエントリ・ポイントを実装します。
エージェントの実行可能ファイルを作成します(CエージェントおよびC++エージェントの場合)。
エントリ・ポイントで必要なすべてのパラメータを収集し、新しいリソース・タイプを定義します。AGENT_FILENAME属性を、新しく作成した実行可能ファイルの絶対パスに設定します。
crsctl add resourceコマンドを使用して、Oracle Clusterware 11gリリース2(11.2)にリソースを登録します。
|
注意: CRS_REGISTERおよびCRS_PROFILEコマンドは、Oracle Clusterwareホームでも引き続き使用可能ですが、このリリースでは非推奨です。 |
アプリケーションをリソースとして登録するには、次の手順を実行します。
$ crsctl add resource resource_name -type 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にリソースとして登録します。
単一のアプリケーションで複数のリソースを登録する必要がある場合、リソース間の関連する依存性の定義が必要な場合があります。
適切な権限をリソースに割り当てます。
リソースを起動または停止します。
リソースで障害が発生すると、Oracle Clusterwareは、アプリケーションまたはプロセスをリソースとして登録したときに指定した属性値に基づいて、リソースの再起動を試行します。クラスタ内のサーバーで障害が発生した場合、障害が発生したサーバーで実行されるように指定されていたプロセスが別のサーバーで再起動されるようにリソースを構成できます。Oracle Clusterwareでは、様々なリソース属性に基づいて様々な構成可能な例がサポートされています。
リソースをOracle Clusterwareに登録すると、アプリケーション関連の情報およびリソース関連の情報がOracle Cluster Registry(OCR)に格納されます。この情報には、次のものが含まれます。
アクション・スクリプトまたはアプリケーション固有のエージェントへのパス: これは、Oracle Clusterwareによってアプリケーションで実行されるstartアクション、stopアクション、checkアクションおよびcleanアクションを定義するスクリプトまたはアプリケーション固有のエージェントへの絶対パスです。
権限: Oracle Clusterwareには、高可用性操作のために、アプリケーションのすべてのコンポーネントの制御に必要な権限(他のユーザーIDでプロセスを起動する権限を含む)があります。Oracle Clusterwareは、権限を持つユーザーとして実行し、正しい起動および停止プロセスでアプリケーションを制御する必要があります。
リソース依存性: 操作の順序を示したり、クラスタ内のサーバーのリソース配置に影響するリソース間の関係を作成することができます。たとえば、他のリソースが実行されている場合、Oracle Clusterwareは別のリソースに対するhard起動依存性が定義されているリソースのみを起動できます。Oracle Clusterwareでは、停止対象のリソースに依存する他のリソースが実行されている場合、そのリソースは停止されません。ただし、crsctl stop resource -fコマンドを使用して、停止対象のリソースに依存するすべてのリソースを最初に停止し、そのリソースを強制終了することができます。
この項には次のトピックが含まれます:
リソース属性は、Oracle Clusterwareで特定のリソース・タイプのリソースを管理する方法を定義します。各リソース・タイプには一意の属性セットがあります。一部のリソース属性はリソースの登録時に指定されますが、その他のリソース属性はOracle Clusterwareによって内部的に管理されます。
|
注意: 新しいリソース属性を定義できる場合でも、使用できる文字はUS-7 ASCIIのみです。 |
クラスタ内のすべてのリソースは、いつでも特定の状態になっています。その状態は、特定のアクションまたはイベントによって変更される可能性があります。
表6-2 予想されるリソースの状態
| 状態 | 説明 |
|---|---|
|
ONLINE |
リソースは実行されています。 |
|
OFFLINE |
リソースは実行されていません。 |
|
UNKNOWN |
リソースの停止の試行に失敗しました。Oracle Clusterwareでは、この状態のリソースはアクティブに監視されません。アプリケーション固有のアクション(プロセスの停止など)を実行してリソースをオフラインにし、 |
|
INTERMEDIATE |
次の2つのイベントのいずれかにより、リソースがINTERMEDIATE状態になる場合があります。
Oracle Clusterwareでは、INTERMEDIATE状態のリソースはアクティブに監視され、通常、ユーザーの介入は必要ありません。前述の理由1のためリソースがINTERMEDIATE状態になっている場合、Oracle Clusterwareは、リソースの状態が確立されるとすぐにリソースをINTERMEDIATE状態から遷移させます。 前述の理由2のためリソースがINTERMEDIATE状態になっている場合、リソースは、部分的にオンラインであるかぎり、この状態のままになります。たとえば、VIPのホーム・サーバーは、VIPがスイッチオーバーできるようにクラスタに再度参加する必要があります。データベース管理者は、データベース・インスタンスをオープンするコマンドを発行する必要があります。 ただし、いずれの場合も、Oracle Clusterwareでは、リソースは適切になるとすぐに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 11gリリース2(11.2)のリソース依存性を定義することは非推奨です。 |
Oracle Clusterware 11gリリース(11.2)では、リソース依存性が起動および停止カテゴリに分割されています。この分割によって、リソースとリソース・タイプ間の起動依存性および停止依存性が向上され、拡張されます。
この項には次のトピックが含まれます:
Oracle Clusterwareでは、リソースの起動試行の評価が開始されると、そのリソースのプロファイルに含まれる起動依存性が考慮されます。START_DEPENDENCIESリソース属性を使用して、リソースの起動依存性を指定します。各依存性で修飾子を使用して、依存性をさらに詳細に構成できます。
この項では、次の起動依存性について説明します。
hard
依存リソースを起動する前に別のリソースが実行されている必要がある場合は、そのリソースにhard起動依存性を定義します。たとえば、リソースBに対するhard起動依存性がリソースAに定義されている場合は、リソース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(resourceB, intermediate:resourceC, intermediate:global:type:resourceC.type)
修飾子を組み合せて、START_DEPENDENCIESリソース属性に複数のリソースを指定できます。
|
注意: 修飾子句は、カンマで区切ります。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修飾子を使用すると、リソースBが先に起動するのを待機するのではなく、リソースAおよびリソースBが同時に起動できるように指定できます。
START_DEPENDENCIES=weak(type:resourceB.type)
type修飾子を使用すると、resourceB.typeなど、特定のリソース・タイプのリソースに対して依存性を有効にすることを指定できます。
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依存性が表現されています。 |
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修飾子を使用すると、特定のリソース・タイプに対して依存性を有効にするように指定できます。
dispersion
リソースにdispersion起動依存性を指定すると、Oracle Clusterwareは、このリソースでdispersionが定義されているリソースが最も少ないサーバーでこのリソースを起動します。dispersionを使用するリソースでも、リソースを分散する十分なサーバーがない場合、同じサーバーで実行されることがあります。
次の修飾子を使用して、dispersion起動依存性を構成できます。
START_DEPENDENCIES=dispersion(intermedite:resourceB)
intermediate修飾子を使用すると、リソースBがONLINE状態またはINTERMEDIATE状態のいずれであっても、Oracle ClusterwareによってリソースAが分散されるように指定できます。
START_DEPENDENCIES=dispersion:active(resourceB)
通常、dispersionはリソースの起動時にのみ適用されます。リソースの起動時に十分なサーバーがないために、相互に分散するリソースが同じサーバーで起動される場合、サーバーがクラスタに追加されてもリソースが実行されていれば、Oracle Clusterwareはそのリソースを変更しません。active修飾子を指定する場合、Oracle Clusterwareは、新しいサーバーがクラスタに追加されると、リソースに対してdispersionを再適用します。
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のみです。
|
注意:
|
この項には次のトピックが含まれます:
アプリケーションのクライアントがネットワークを介してアプリケーションにアクセスし、アプリケーションの配置ポリシーによって別のノードへのフェイルオーバーが可能である場合は、アプリケーションが依存する仮想インターネット・プロトコル・アドレス(VIP)を登録する必要があります。アプリケーションVIPは、Oracle Clusterwareによって管理されるクラスタ・リソースです(Oracle ClusterwareではアプリケーションVIP用の標準VIPエージェントが提供されます)。システムで、クラスタにデプロイされたすべてのVIPの動作の一貫性が保持されるように、新しいアプリケーションVIPはこのVIPタイプに基づく必要があります。
Oracle Clusterwareで管理する他のリソースを追加できるように、VIPを追加することはできますが、Grid_home/bin/appvipcfgスクリプトを使用してアプリケーションVIPを作成または削除することをお薦めします。
アプリケーションVIPを作成するには、次の構文を使用します。
appvipcfg create -network=network_number -ip=ip_address -vipname=vip_name -user=user_name [-group=group_name] [-failback=0 | 1]
アプリケーション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に依存するすべてのリソース)は、元のノードが再び使用可能になると、元のノードにフェイルバックします。
たとえば、rootとして次のコマンドを実行します。
# Grid_home/bin/appvipcfg create -network=1 -ip=148.87.58.196 -vipname=appsVIP -user=root
スクリプトには、ネットワーク番号(デフォルトは1)、IPアドレス、VIPリソースの名前およびアプリケーション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スクリプトでは、デフォルトのora.vipネットワーク・リソース(ora.net1.network)がデフォルトとして使用されると想定されます。また、デフォルトのapp.appvip_net1.typeもそのために使用されると想定されます。
Oracle Databaseインストール所有者として、VIPリソースを起動します。
$ crsctl start resource appsVIP
Oracle Enterprise ManagerによるアプリケーションVIPの追加
Oracle Enterprise Managerを使用してアプリケーションVIPを追加するには、次の手順を実行します。
Oracle Enterprise Manager Database Controlにログインします。
「クラスタ」タブをクリックします。
「管理」をクリックします。
「リソースの管理」をクリックします。
クラスタ管理者のユーザー名およびパスワードを入力して、「リソースの管理」ページを表示します。
「アプリケーションVIPの追加」をクリックします。
「名前」フィールドにVIPの名前を入力します。
「ネットワーク番号」フィールドにネットワークの番号を入力します。
「インターネット・プロトコル・アドレス」フィールドにVIPのIPアドレスを入力します。
「プライマリ・ユーザー」フィールドにrootと入力します。Oracle Enterprise Managerは、ログイン時に使用するユーザー名をデフォルト値とします。
VIPをすぐに起動する場合は、「作成後にリソースを開始」を選択します。
「続行」をクリックして「確認: VIPリソースの追加」ページを表示します。
クラスタの資格証明としてrootおよびルート・パスワードを入力します。
「続行」をクリックしてアプリケーションVIPを作成します。
Oracle Clusterwareにはいつでもリソースを追加できます。ただし、別のリソースに依存しているリソースを追加する場合は、最初にそのリソースが依存しているリソースを追加します。
この項の例では、クラスタへのリソースの追加を簡単にするために、アクション・スクリプトmyApache.scrが各ノードの/opt/cluster/scriptsディレクトリに存在していると想定しています。また、アプリケーションをホスティングするためにサーバー・プールが作成されたと想定しています。このサーバー・プールは汎用のサブプールではありませんが、かわりに、最上位のサーバー・プールでアプリケーションをホスティングするために使用されます。
|
注意: スクリプトのメンテナンスを軽減するために、Oracle Automatic Storage Management Cluster File System (Oracle ACFS)などの共有ストレージを使用してアクション・スクリプトを格納することをお薦めします。 |
この項には次のトピックが含まれます:
アプリケーションの管理者またはポリシー管理を使用するかどうかを決定する必要があります。管理者管理は、クラスタ構成が変更される可能性が低い、小規模な2ノード構成に使用します。ポリシー管理は、クラスタが3つ以上のノードで構成されている場合に、より動的な構成に使用します。たとえば、リソースがノード1およびノード2のみで実行されている場合、これらのノードにのみ必要なファイルが存在するため、管理者管理がより適切である可能性があります。
Oracle Clusterwareでは、匿名サーバーで構成され、必要なプール・サイズに厳密に基づく、アクセス制御されたサーバー・プールでのアプリケーションのデプロイメントがサポートされています。この場合、管理者定義のクラスタ・ポリシーを使用して、必要なサイズおよび重要度のレベルで、サーバー割当てを制御する必要があります。または、厳密なサーバー割当てまたは優先サーバー割当てを使用することもでき、この場合、リソースは具体的な名前が指定されたサーバーで実行されます。これは、以前のリリースのOracle Clusterwareで使用可能な既存のモデル(現在の管理者管理)を表します。
概念上、両方のデプロイメント・スキームで開発およびデプロイされたアプリケーションをホスティングするクラスタは、サーバーの、論理的に分割された2つのグループと考えることができます。一方のサーバー・グループはサーバー・プールに使用され、ロールの分離およびサーバーの容量制御が可能になります。もう一方のサーバー・グループでは、クラスタ内の名前付きのサーバーに基づく固定割当てが想定されます。
いずれかのデプロイメント・スキームを使用してアプリケーションを管理するには、クラスタにリソースを追加する前にサーバー・プールを作成する必要があります。Genericという名前の組込みサーバー・プールは、管理者ベース管理のアプリケーションによって使用されるサーバーを常に所有します。汎用サーバー・プールは論理的な分割で、異なる管理スキームを使用してクラスタの2つの部分を分割するために使用できます。
サード・パーティの開発者がこのモデルを使用してアプリケーションをデプロイするには、サーバー・プールを使用する必要があります。名前付きのサーバーに基づく、既存のアプリケーション開発およびデプロイメント・モデルを利用するには、汎用サブプール(汎用プールが親であるサーバー・プールで、サーバー・プール属性のPARENT_POOLSで定義される)を使用する必要があります。親として汎用を使用するサブプールを作成し、サーバーをサブプール定義に名前で列挙することによって、名前付きのサーバーが、汎用内に存在すること、および名前付きのサーバー・モデルを使用するアプリケーション専用に使用されることがアプリケーションで保証されます。
ポリシー・ベースのデプロイメント・スキームを使用して、特定のサーバー・プールにApache Webサーバーをリソースとして追加するには、Apacheサーバーを実行するユーザーとして次のコマンドを実行します。Apacheサーバーの場合、これは通常、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"
このサブプールが作成されると、前述の例のようにリソースを追加できます。
$ 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リソース・パラメータにリストされたサーバー・プールは、汎用サーバー・プールの下位プールである必要があることに注意してください。
Oracle Enterprise Managerを使用してOracle Clusterwareにリソースを追加するには、次の手順を実行します。
Oracle Enterprise Manager Database Controlにログインします。
「クラスタ」タブをクリックします。
「管理」をクリックします。
「リソースの追加」をクリックします。
クラスタ管理者のユーザー名およびパスワードを入力して、「リソースの追加」ページを表示します。
「名前」フィールドにリソースの名前を入力します。
|
注意: リソース名の先頭をピリオドまたはoraという文字列にすることはできません。 |
「リソース・タイプ」ドロップダウン・リストからcluster_resourceまたはlocal_resourceのいずれかを選択します。
必要に応じて、「説明」フィールドにリソースの説明を入力します。
リソースをすぐに起動する場合は、「作成後にリソースを開始」を選択します。
「配置」セクションのオプションのパラメータは、Oracle Clusterwareによってリソースが配置されるクラスタ内の場所を定義します。
この項の属性は、付録B「Oracle Clusterwareのリソース・リファレンス」で説明されている属性に対応しています。
「アクション・プログラム」セクションの「アクション・プログラム」ドロップダウン・リストから、リソースを管理するためにOracle Clusterwareでアクション・スクリプトをコールするか、エージェント・ファイルをコールするか、またはその両方をコールするかを選択します。
また、ドロップダウン・リストでの選択に応じて、スクリプト、ファイルまたはその両方へのパスを指定する必要があります。
「アクション・スクリプト」を選択した場合、「新規アクション・スクリプトの作成」をクリックし、Oracle Enterprise Managerアクション・スクリプト・テンプレートを使用してリソース用のアクション・スクリプトを作成することができます(作成済でない場合)。
これ以上のリソースの構成を行うには、「属性」をクリックします。このページでは、開始属性、停止属性、ステータス属性、オフライン監視および定義した属性を構成できます。
「拡張設定」をクリックし、より詳細なリソース属性の構成を有効にします。
「依存性」をクリックして、リソース間の起動および停止の依存性を構成します。
リソースの構成が終了したら、「発行」をクリックします。
Oracle Clusterwareでは、リソースを追加したユーザーの権限に基づいてリソースが管理されます。最初にリソースを追加したユーザーがリソースを所有し、リソースはリソースの所有者として実行されます。特定のリソースはrootとして管理する必要があります。root以外のユーザーが、rootとして実行する必要があるリソースを追加する場合は、次のように、rootがリソースを管理するように権限をrootとして変更する必要があります。
rootとして次のコマンドを実行して、指定したリソースの権限をrootに変更します。
# crsctl setperm resource resource_name –o root
Oracle ClusterwareをインストールしたユーザーとしてOracle Databaseインストール所有者(次の例ではoracle)を有効にして、次のスクリプトを実行します。
$ crsctl setperm resource resource_name –u user:oracle:r-x
リソースを起動するには、次のスクリプトを実行します。
$ 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: 値がSERVER_POOLSまたはHOSTING_MEMBERSリソース属性のいずれかに割り当てられている場合、いずれかの属性のメンバー・リストに属しているサーバーがOracle Clusterwareで最初に考慮されます。サーバーを使用できない場合、リソースは、Oracle Clusterwareによってその他の使用可能なサーバーに配置されます。SERVER_POOLSとHOSTING_MEMBERSの両方の属性に値がある場合、SERVER_POOLSは、HOSTING_MEMBERSの値によって示される優先順位内のサーバーに選択肢を制限します。
restricted: Oracle Clusterwareでは、SEVER_POOLSリソース属性に示されているサーバー・プールに属しているサーバー、または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
-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)"
リソースを変更した場合は、crsctl modify resourceコマンドを実行してOCRを更新します。
crsctl start resourceおよびcrsctl stop 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 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
いくつかのリソース属性を設定することによって、Oracle Clusterwareが自動的にリソースを再起動しないようにできます。また、Oracle Clusterwareによるリソースの再起動カウンタの管理を制御することもできます。さらに、Oracle Clusterwareがリソースで実行するstart、stopおよびcheckアクションのタイムアウト値をカスタマイズすることもできます。
この項には次のトピックが含まれます:
サーバーを再起動すると、Oracle Clusterwareによって、サーバーの起動直後に実行されるリソースの起動が試行されます。ただし、リソースが依存するシステム・コンポーネント(ボリューム・マネージャ、ファイル・システムなど)が実行されていない場合は、リソースの起動が失敗する可能性があります。これは特に、リソースが依存するシステム・コンポーネントをOracle Clusterwareが管理しない場合に該当します。自動再起動を管理するには、AUTO_STARTリソース属性を使用して、サーバーの再起動時にOracle Clusterwareによって自動的にリソースが起動されるかどうかを指定します。
|
注意: リソースのAUTO_STARTリソース属性の値にかかわらず、起動対象のリソースに対するhard起動依存性またはweak起動依存性が別のリソースに定義されている場合、または別のリソースに対するpullup起動依存性が起動対象のリソースに定義されている場合は、そのリソースを起動できます。 |
リソースで障害が発生すると、リソースで障害が発生した回数に関係なく、RESTART_ATTEMPTSリソース属性に指定された回数だけOracle Clusterwareによってリソースの再起動が試行されます。crsdプロセスは、内部カウンタを保持して、リソースがOracle Clusterwareによって再起動される回数を追跡します。Oracle Clusterwareがリソースの再起動を試行した回数はRESTART_COUNTリソース属性に反映されます。Oracle Clusterwareでは、リソースの安定性に基づいて再起動試行カウンタが自動的に管理されます。UPTIME_THRESHOLDリソース属性は、リソースがオンラインである必要がある時間を決定し、その時間が経過すると、RESTART_COUNT属性は0にリセットされます。また、RESTART_COUNTリソース属性は、リソースがユーザーによって再配置または再起動された場合、あるいはリソースが別のサーバーにフェイルオーバーした場合にも、0にリセットされます。
