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

印刷ビューの終了

更新: 2015 年 9 月
 
 

scha_control_zone(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 Arguments

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 つ以上のノード上で現在オンライン状態にあり、これ以上オンライン化できるノードが存在しない場合、このリソースグループは、ローカルノード上でオフラインになったままオンラインにならない可能性があります。またこうした処理要求は、各種のチェックの結果を受けた結果として、拒絶される場合もあります。たとえば、Pingpong_interval プロパティーで指定された間隔内に、あるノード上で SCHA_GIVEOVER 要求によってグループがオフラインに移行されたために、そのノードがホストとして拒否されることがあります。

クラスタ管理者が 1 つまたは複数のリソースグループの RG_affinities プロパティーを構成している場合に、あるリソースグループで 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() <![ %zones-deferred; [または 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_get()NUM_RESOURCE_RESTARTS クエリーを使用して、最近の再起動の試行回数を記録できます。

PRENET_START または POSTNET_STOP メソッドを備えたリソースタイプは、SCHA_RESOURCE_RESTART 要求を慎重に使用する必要があります。このリソースに適用されるのは、MONITOR_STOPSTOPSTART、および MONITOR_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)