Oracle® Solaris Cluster リファレンスマニュアル

印刷ビューの終了

更新: 2014 年 7 月、E51742-01
 
 

scha_control(3HA)

名前

scha_control, scha_control_zone - リソースおよびリソースグループ制御をリクエストする関数

形式

cc [flags…] –I/usr/cluster/include file –L/usr/cluster/lib 
     –l scha#include <scha.h> scha_err_t scha_control(const char *
     tag, const char *rgname, const char *rname);
 scha_err_t scha_control_zone(const char *tag, const char *
     rgname, const char *rname, const char *zonename);

説明

scha_control() および scha_control_zone() 関数は、それぞれ、Resource Group Manager (RGM) の制御下にあるリソースまたはリソースグループの再起動または再配置をリクエストするためのインタフェースを提供します。これらの関数はリソースモニターで使用します。

scha_control_zone() 関数は、Global_zone プロパティーが TRUE に設定されているリソースタイプにのみ使用します。Global_zone プロパティーが FALSE に設定されている場合、この機能は必要ありません。詳細は、rt_properties(5) のマニュアルページを参照してください。 scha_control_zone() 関数は、大域ゾーンから呼び出されます。zonename 引数は、リソースグループが構成されているゾーンクラスタの名前を指定します。

指定されたリソースの Failover_mode プロパティーの設定により、リクエストされた scha_control() または scha_control_zone() のアクションが抑制される場合もあります。Failover_modeRESTART_ONLY である場合、SCHA_RESOURCE_RESTART のみが許可されます。SCHA_GIVEOVERSCHA_CHECK_GIVEOVERSCHA_RESTART、および SCHA_CHECK_RESTART を含む、その他のリクエストは SCHA_ERR_CHECKS 終了コードを返し、リクエストされたギブオーバーまたは再起動アクションは実行されず、syslog メッセージのみを作成します。Retry_count プロパティーと Retry_interval プロパティーがリソースで設定されている場合、リソース再起動の回数は Retry_interval 内での Retry_count の試行回数に制限されます。Failover_modeLOG_ONLY の場合、scha_control() または scha_control_zone() のギブオーバー、再起動、または無効化リクエストは SCHA_ERR_CHECKS 終了コードを返し、リクエストされたギブオーバーまたは再起動アクションは実行されず、syslog メッセージのみを作成します。

tag 引数

tag 引数には、リソースまたはリソースグループに対して、再配置を行うのか、再起動を行うのかを指定します。この引数は、scha_tags.h で定義された次のマクロのうちの 1 つで定義される文字列値にしてください。

SCHA_CHANGE_STATE_OFFLINE

rname 引数で指定したプロキシリソースをローカルノード上でオフラインにするようリクエストします。プロキシリソースは、リソースの状態を Oracle Clusterware などの別のクラスタからインポートする Oracle Solaris Cluster リソースです。Oracle Clusterware は、クラスタ環境のための、プラットフォームに依存しない一連のシステムサービスです。Oracle Solaris Cluster ソフトウェアのコンテキスト内での、状態のこの変化には、外部リソースの状態の変化が反映されます。

プロキシリソースの状態をこの tag 引数で変更すると、該当するプロキシリソースのメソッドは実行されません。

ノード上にある「依存先の」リソースで障害が発生して、リソースを回復できない場合、モニターはそのノード上のそのリソースをオフラインにします。モニターは scha_control() <![ %zones-deferred; [または scha_control_zone() ]]>関数を SCHA_RESOURCE_DISABLE 要求付きで呼び出すことにより、リソースをオフラインにします。また、モニターは、依存先リソースのオフライン、再起動に従属する対象をすべて、それらに対して再起動をトリガーすることにより、オフラインにします。クラスタ管理者が障害を解決し、依存されているリソースを再び有効にすると、モニターは、依存されているリソースのオフライン再起動依存リソースもオンラインに戻します。

SCHA_CHANGE_STATE_ONLINE

rname 引数で指定したプロキシリソースをローカルノード上でオンラインにするようリクエストします。プロキシリソースは、リソースの状態を Oracle Clusterware などの別のクラスタからインポートする Oracle Solaris Cluster リソースです。Oracle Solaris Cluster ソフトウェアのコンテキスト内での、状態のこの変化には、外部リソースの状態の変化が反映されます。

プロキシリソースの状態をこの tag 引数で変更すると、該当するプロキシリソースのメソッドは実行されません。

SCHA_CHECK_GIVEOVER

rgname 引数に指定したリソースグループに対して SCHA_GIVEOVER と同様の検証チェックを実行しますが、実際にリソースグループを再配置することはありません。

SCHA_CHECK_RESTART

rgname 引数に指定したリソースグループに対して SCHA_RESTART リクエストと同様の検証チェックを実行しますが、実際にリソースグループを再起動することはありません。

SCHA_CHECK_GIVEOVER および SCHA_CHECK_RESTART リクエストは、scha_control() または scha_control_zone() 関数を起動してギブオーバーまたは再起動を実行するのではなく、リソースに対してアクション (プロセスの終了や再起動など) を直接起こすリソースモニターが使用するためのものです。なお検証に問題が発生した場合、モニターはフェイルオーバー処理を行う代わりに、スリープ状態に置いてからプローブを再開する必要があります。エラー を参照してください。

rgname 引数には、再起動または再配置するリソースグループの名前を指定します。リクエスト元ノードでグループがオンラインになっていない場合、リクエストは拒否されます。

rname 引数には、リソースグループ内のリソースの名前を指定します。これは、モニターが scha_control() または scha_control_zone() のリクエストを実行するリソースと考えられます。指定されたリソースがリソースグループ内に存在しない場合、要求は拒否されます。

コマンドの終了コードは、要求された処理が拒絶されたかどうかを示します。要求が受け入れられた場合、リソースグループまたはリソースに対するオフラインから再オンライン化までの処理が終わった時点で、関数の値が返されます。scha_control() または scha_control_zone() 関数を呼び出した障害モニターは、リソースグループがオフラインになった結果、停止し、成功したリクエストの戻りステータスを受け取らない場合があります。

SCHA_GIVEOVER

rgname 引数に指定したリソースグループをローカルノード上でオフラインにし、RGM が選択する別のノード上で再度オンラインにするようリクエストします。リソースグループが 2 つ以上のノード上で現在オンライン状態にあり、これ以上オンライン化できるノードが存在しない場合、このリソースグループは、ローカルノード上でオフラインになったままオンラインにならない可能性があります。またこうした処理要求は、各種のチェックの結果を受けた結果として、拒絶される場合もあります。たとえば、あるノード上で SCHA_GIVEOVER リクエストにより、グループが Pingpong_interval プロパティーの指定された間隔でオフラインになったために、このノードがホストとして拒絶されることがあります。

クラスタ管理者が 1 つ以上のリソースグループの RG_affinities プロパティーを構成し、1 つのリソースグループで scha_control GIVEOVER 要求を発行する場合、複数のリソースグループが再配置される可能性があります。RG_affinities プロパティーについては、rg_properties(5) で説明されています。

MONITOR_CHECK メソッドは、リソースを含むリソースグループが、scha_control() または scha_control_zone() 関数の呼び出しあるいは障害モニターからの scha_control または scha_control_zone() コマンドの発行の結果として新しいノードに再配置される前に呼び出されます。scha_control(1HA) のマニュアルページを参照してください。

MONITOR_CHECK メソッドは、リソースグループの新しい潜在マスターである任意のノードから呼び出せます。MONITOR_CHECK メソッドは、リソースを実行するのにノードが十分に健全であるかどうかを確認します。MONITOR_CHECK メソッドは、並行して実行されるほかのメソッドと衝突しない方法で実装する必要があります。

MONITOR_CHECK メソッドが失敗した場合、コールバックが呼び出されたノードへのリソースグループの再配置は拒否されます。

SCHA_IGNORE_FAILED_START

現在実行している Prenet_start メソッドまたは Start メソッドが失敗したリクエストは、Failover_mode プロパティーの設定をしていても、リソースグループのフェイルオーバーの原因にはなりません。

言い換えると、この要求は、Failover_Mode プロパティーが SOFT または HARD に設定されているリソースに対して、通常、そのリソースが起動に失敗したときに行われる回復アクションを無効にします。通常、リソースグループは異なるノードにフェイルオーバーします。代わりに、リソースは Failover_ModeNONE に設定されているかのように動作します。このリソースは START_FAILED 状態になり、その他のエラーが発生していない場合、リソースグループは ONLINE_FAULTED 状態で終了します。

このリクエストが意味を持つのは、あとで 0 以外のステータスで終了するかタイムアウトする Start または Prenet_start メソッドから呼び出された場合のみです。このリクエストは、現在の Start メソッドまたは Prenet_start メソッドの呼び出しに対してのみ有効です。別のノード上でリソースを正常に起動できないことが Start() メソッドで判明した場合は、このリクエストを指定してscha_control() または scha_control_zone 関数を呼び出してください。このリクエストがほかのメソッドから呼び出された場合、エラー SCHA_ERR_INVAL が返されます。この要求は、リソースグループの「ピンポン」フェイルオーバーを防ぐために存在します。SCHA_ERR_INVAL エラーコードについては、scha_calls(3HA) のマニュアルページを参照してください。

SCHA_RESOURCE_DISABLE

scha_control() または scha_control_zone() 関数が呼び出されたノード上で rname 引数によって指定されたリソースを無効にします。

ノード上にある「依存先の」リソースで障害が発生して、リソースを回復できない場合、モニターはそのノード上のそのリソースをオフラインにします。モニターは scha_control() または scha_control_zone() 関数を SCHA_RESOURCE_DISABLE リクエストで呼び出すことにより、リソースをオフラインにします。また、モニターは、依存先リソースのオフライン、再起動に従属する対象をすべて、それらに対して再起動をトリガーすることにより、オフラインにします。クラスタ管理者が障害を解決し、依存されているリソースを再び有効にすると、モニターは、依存されているリソースのオフライン再起動依存リソースもオンラインに戻します。

SCHA_RESOURCE_IS_RESTARTED

rname 引数に指定したリソースの再起動カウンタを、実際にリソースを再起動することなく、ローカルノード上で増分するようリクエストします。

SCHA_RESOURCE_RESTART リクエストで scha_control() または scha_control_zone() 関数を呼び出すことなく、リソースを直接再起動するリソースモニター (たとえば、pmfadm(1M) コマンドの使用) は、このリクエストを使用してリソースが再起動されたことを RGM に通知できます。このことは、今後 scha_resource_get() 関数を NUM_RESOURCE_RESTARTS クエリー付きで呼び出す場合に反映されます。

リソースの型が Retry_interval 標準プロパティーの宣言に失敗した場合、scha_control() または scha_control_zone() 関数の SCHA_RESOURCE_IS_RESTARTED リクエストは許可されず、scha_control() または scha_control_zone() 関数はエラーコード 13 (SCHA_ERR_RT) を返します。

SCHA_RESOURCE_RESTART

rname 引数に指定したリソースをオフラインにし、リソースグループ内のほかのリソースを停止させることなく、ローカルノード上で再度オンラインにするようリクエストします。リソースの停止と起動は、ローカルノード上で次の順序でメソッドを適用することで行われます:

MONITOR_STOP
STOP
START
MONITOR_START

リソースタイプが STOP メソッドおよび START メソッドを宣言していない場合は、代わりに POSTNET_STOP および PRENET_START を使用してリソースが再起動されます:

MONITOR_STOP
POSTNET_STOP
PRENET_START
MONITOR_START

リソースタイプが MONITOR_STOP メソッドおよび MONITOR_START メソッドを宣言していない場合、STOP メソッドと START メソッド、または POSTNET_STOP メソッドと PRENET_START メソッドのみが呼び出され、再起動が実行されます。リソースのタイプは START メソッドと STOP メソッドを宣言する必要があります。SCHA_ERR_RT エラーコードについては、scha_calls(3HA) のマニュアルページを参照してください。

リソースの再起動時にメソッドの呼び出しに失敗した場合は、RGM はリソースの Failover_mode プロパティー設定に応じて、エラー状態の設定、リソースグループの再配置、またはノードのリブートを実行します。詳細は、r_properties(5)Failover_mode プロパティーを参照してください。

この要求を使用してリソースを再起動するリソースモニターは、scha_resource_getNUM_RESOURCE_RESTARTS() クエリーを使用して、最近の再起動の試行回数を記録できます。

PRENET_START または POSTNET_STOP メソッドを持つリソースタイプでは、注意して SCHA_RESOURCE_RESTART リクエストを使用する必要があります。リソースに対して使用できるのは MONITOR_STOPSTOPSTARTMONITOR_START のメソッドのみです。このリソースが依存するネットワークアドレスリソースは再起動されず、オンライン状態のままになります。

ノード上にある「依存先の」リソースで障害が発生して、リソースを回復できない場合、モニターはそのノード上のそのリソースをオフラインにします。モニターは scha_control() <![ %zones-deferred; [または scha_control_zone() ]]>関数を SCHA_RESOURCE_DISABLE 要求付きで呼び出すことにより、リソースをオフラインにします。また、モニターは、依存先リソースのオフライン、再起動に従属する対象をすべて、それらに対して再起動をトリガーすることにより、オフラインにします。クラスタ管理者が障害を解決し、依存されているリソースを再び有効にすると、モニターは、依存されているリソースのオフライン再起動依存リソースもオンラインに戻します。

SCHA_RESTART

rgname 引数に指定したリソースグループをオフラインにし、異なるノードに強制的に再配置することなく、再度オンラインにするようリクエストします。ただし、この要求を実行する際にグループ内のリソースの再起動が失敗した場合は、最終的にリソースグループが再配置されることもあります。このリクエストを使用してリソースグループを再起動するリソースモニターは、scha_resource_getNUM_RG_RESTARTS() クエリーを使用して、最近の再起動の試行回数を記録できます。

戻り値

これらの関数は、次の戻り値を返します。

0

関数の実行に成功。

0 以外

関数の実行に失敗。

エラー

SCHA_ERR_NOERR

関数の実行に成功。

SCHA_ERR_CHECKS

要求は取り消し済み再配置に失敗した箇所のチェックが必要。

その他のエラーコードについては、scha_calls(3HA) のマニュアルページを参照してください。

通常、scha_control() または scha_control_zone() 関数からエラーコードを受信する障害モニターは、しばらくの間スリープ状態になってから、その検証を再起動するようにしてください。これらの関数がこのような動作をするのは、エラー状態の中には、しばらく時間が経過したあと自分自身で解決するものがあるためです。そのようなエラー状態の例としては、広域デバイスサービスのフェイルオーバーがあり、これはディスクリソースが一時的に使用不可能になる原因になります。エラー状態が解決されたあと、リソース自体はふたたび正常な状態に戻ることがあります。そうでない場合、後続の scha_control() または scha_control_zone() リクエストが成功することがあります。

ファイル

/usr/cluster/include/scha.h

インクルードファイル

/usr/cluster/lib/libscha.so

ライブラリ

属性

次の属性の説明は、attributes(5) を参照してください:

属性タイプ
属性値
使用条件
ha-cluster/developer/api
インタフェースの安定性
発展中

関連項目

rt_callbacks(1HA), scha_control(1HA), pmfadm(1M), scha_calls(3HA), scha_resource_open(3HA), scha_strerror(3HA), attributes(5), r_properties(5), rg_properties(5), rt_properties(5)