Start メソッドの仕組み (Sun Cluster データサービス開発ガイド (Solaris OS 版))

Sun Cluster データサービス開発ガイド (Solaris OS 版)

`Start` メソッドの仕組み

データサービスリソースのあるリソースグループがクラスタノードまたはゾーン上でオンラインになったとき、またはリソースグループがすでにオンラインになっていてリソースが有効になったとき、RGM はそのノードまたはゾーン上で Start メソッドを実行します。サンプルのアプリケーションでは、Start メソッドはそのノード上の大域ゾーン内で in.named DNS デーモンを起動します。

この節では、サンプルのアプリケーションの Start メソッドの重要な部分だけを説明します。parse_args() 関数など、すべてのコールバックメソッドに共通な機能については説明しません。また、syslog() 関数の使用法についても説明しません。共通の機能については、「すべてのメソッドに共通な機能の提供」を参照してください。

Start メソッドの完全なリストについては、「Start メソッドのコードリスト」を参照してください。

`Start` メソッドの動作

DNS を起動する前に、サンプルのデータサービスの Start メソッドは、構成ディレクトリと構成ファイル (named.conf) がアクセス可能で利用可能であるかどうかを確認します。DNS が正常に動作するためには、named.conf の情報が重要です。

このコールバックメソッドは、PMF (pmfadm) を使って DNS デーモン (in.named) を起動します。DNS がクラッシュしたり、起動に失敗したりすると、PMF は、指定の期間に所定の回数だけ DNS デーモンの起動を試行します。再試行の回数と期間は、データサービスの RTR ファイル内のプロパティーで指定されます。

構成の確認

DNS が動作するためには、構成ディレクトリ内の named.conf ファイルからの情報が必要です。したがって、Start メソッドは、DNS を起動しようとする前にいくつかの妥当性検査を実行し、ディレクトリやファイルがアクセス可能であるかどうかを確認します。

Confdir 拡張プロパティーは、構成ディレクトリへのパスを提供します。プロパティー自身は RTR ファイルに定義されています。しかし、実際の位置は、クラスタ管理者がデータサービスを構成するときに指定します。

サンプルのデータサービスでは、Start メソッドは scha_resource_get() 関数を使用して構成ディレクトリの位置を取得します。

注 –

Confdir は拡張プロパティーであるため、scha_resource_get() はタイプと値の両方を戻します。したがって、awk コマンドで値だけを取得し、シェル変数 CONFIG_DIR にその値を格納します。

# クラスタ管理者がリソースの追加時に設定した Confdir の
# 値を検索。
config_info=`scha_resource_get -O Extension -R $RESOURCE_NAME \
-G $RESOURCEGROUP_NAME Confdir`

# scha_resource_get は、拡張プロパティーの値とともにタイプを返す。
# 拡張プロパティーの値だけを取得。 
CONFIG_DIR=`echo $config_info | awk '{print $2}'`

Start メソッドは CONFIG_DIR の値を使用し、ディレクトリがアクセス可能であるかどうかを確認します。アクセス可能ではない場合、Start メソッドはエラーメッセージを記録し、エラー状態で終了します。「Start の終了状態」を参照してください。

# $CONFIG_DIR がアクセス可能かどうかを確認。
if [ ! -d $CONFIG_DIR ]; then
   logger -p ${SYSLOG_FACILITY}.err \
         -t [$SYSLOG_TAG] \
         "${ARGV0} Directory $CONFIG_DIR is missing or not mounted"
   exit 1
fi

アプリケーションデーモンを起動する前に、このメソッドは最終検査を実行し、named.conf ファイルが存在するかどうかを確認します。ファイルが存在しない場合、Start メソッドはエラーメッセージを記録し、エラー状態で終了します。

# データファイルに相対パス名が含まれている場合は $CONFIG_DIR
# ディレクトリに移動。
cd $CONFIG_DIR

# named.conf ファイルが $CONFIG_DIR ディレクトリに存在することを確認。
if [ ! -s named.conf ]; then
   logger -p ${SYSLOG_FACILITY}.err \
         -t [$SYSLOG_TAG] \
         "${ARGV0} File $CONFIG_DIR/named.conf is missing or empty"
   exit 1
fi

アプリケーションの起動

このメソッドは、プロセス監視機能 (pmfadm) を使用してアプリケーションを起動します。pmfadm コマンドを使用すると、指定した期間内にアプリケーションの再起動を試みる回数を設定できます。RTR ファイルには、2 つのプロパティーがあり、Retry_count は、アプリケーションを再起動する回数を指定し、Retry_interval は、アプリケーションを再起動する期間を指定します。

Start メソッドは、scha_resource_get() 関数を使用して Retry_count と Retry_interval の値を取得し、これらの値をシェル変数に格納します。次に Start メソッドは、-n オプションと -t オプションを使用し、これらの値を pmfadm に渡します。

# RTR ファイルから再試行回数の値を取得する。
RETRY_CNT=`scha_resource_get -O Retry_count -R $RESOURCE_NAME \
-G $RESOURCEGROUP_NAME`
# RTR ファイルから次の再試行までの時間 (秒数) を取得。この値は pmfadm
# に渡されるため分数に変換される。変換時に端数が切り上げられる点に注意。
# たとえば 50 秒は 1 分に変換される。
((RETRY_INTRVAL=`scha_resource_get -O Retry_interval -R $RESOURCE_NAME \
-G $RESOURCEGROUP_NAME` / 60))

# PMF 制御下で in.named デーモンを起動する。RETRY_INTERVAL の期間、
# $RETRY_COUNT の回数だけクラッシュおよび再起動できる。
# それ以上の回数クラッシュした場合、PMF はそれ以上再試行しない。
# <$PMF_TAG> タグで登録済みのプロセスがある場合、PMF はプロセスが
# すでに実行中であるという警告メッセージを送信する。
pmfadm -c $PMF_TAAG -n $RETRY_CNT -t $RETRY_INTRVAL \
    /usr/sbin/in.named -c named.conf

# HA-DNS が起動していることを示すメッセージを記録。
if [ $? -eq 0 ]; then
   logger -p ${SYSLOG_FACILITY}.err \
         -t [$SYSLOG_TAG] \
         "${ARGV0} HA-DNS successfully started"
fi
exit 0

`Start` の終了状態

Start メソッドは、実際のアプリケーションが本当に動作して実行可能になるまで、成功状態で終了してはなりません。特に、ほかのデータサービスが依存している場合は注意する必要があります。これを実現するための 1 つの方法は、Start メソッドが終了する前に、アプリケーションが動作しているかどうかを確認することです。複雑なアプリケーション (データベースなど) の場合、RTR ファイルの Start_timeout プロパティーに十分高い値を設定することによって、アプリケーションが初期化され、クラッシュ回復を実行できる時間を提供します。

注 –

サンプルのデータサービスのアプリケーションリソース (DNS) は直ちに起動するため、サンプルのデータサービスは、成功状態で終了する前に、ポーリングでアプリケーションが動作していることを確認していません。

このメソッドが DNS の起動に失敗し、失敗状態で終了すると、RGM は Failover_mode プロパティーを検査し、どのように対処するかを決定します。サンプルのデータサービスは明示的に Failover_mode プロパティーを設定していないため、このプロパティーはデフォルト値 NONE が設定されています (ただし、クラスタ管理者がデフォルト値を変更して異なる値を指定していないと仮定します)。したがって、RGM は、データサービスの状態を設定するだけで、ほかのアクションは行いません。同じノードまたはゾーン上での再起動や、別のノードまたはゾーンへのフェイルオーバーは、クラスタ管理者が行う必要があります。