Cluster Server 7.3.1 エージェント開発者ガイド - AIX、Linux、Solaris、Windows
- 概要
- エージェントのエントリポイントの概要
- エージェントのエントリポイントについて
- エージェントエントリポイントの説明
- open エントリポイントについて
- monitor エントリポイントについて
- online エントリポイントについて
- offline エントリポイントについて
- clean エントリポイントについて
- action エントリポイントについて
- info エントリポイントについて
- attr_changed エントリポイントについて
- close エントリポイントについて
- shutdown エントリポイントについて
- imf_init エントリポイントについて
- imf_register エントリポイントについて
- imf_getnotification エントリポイントについて
- migrate エントリポイントについて
- meter エントリポイントについて
- エントリポイントの戻り値
- C++ またはスクリプトエントリポイントの使用上の注意事項
- エージェント情報ファイルについて
- ArgList 属性と ArgListValues 属性について
- C++ でのエントリポイントの作成
- C++ でのエントリポイントの作成について
- データ構造
- C++ のエントリポイントの構文
- エージェントフレームワークの基本関数
- VCSAgGetMonitorLevel
- VCSAgGetFwVersion
- VCSAgGetRegVersion
- VCSAgRegisterEPStruct
- VCSAgSetCookie2
- VCSAgRegister
- VCSAgUnregister
- VCSAgGetCookie
- VCSAgStrlcpy
- VCSAgStrlcat
- VCSAgSnprintf
- VCSAgCloseFile
- VCSAgDelString
- VCSAgExec
- VCSAgExecWithTimeout
- VCSAgGenSnmpTrap
- VCSAgSendTrap
- VCSAgLockFile
- VCSAgInitEntryPointStruct
- VCSAgSetStackSize
- VCSAgUnlockFile
- VCSAgValidateAndSetEntryPoint
- VCSAgSetLogCategory
- VCSAgGetProductName
- VCSAgMonitorReturn
- VCSAgSetResEPTimeout
- VCSAgDecryptKey
- VCSAgGetConfDir
- VCSAgGetHomeDir
- VCSAgGetLogDir
- VCSAgGetSystemName
- VCSAG_CONSOLE_LOG_MSG
- VCSAG_LOG_MSG
- VCSAG_LOGDBG_MSG
- VCSAG_RES_LOG_MSG
- コンテナサポートのためのエージェントフレームワーク基本関数
- スクリプトでのエントリポイントの作成
- スクリプトでのエントリポイントの作成について
- スクリプトエントリポイントの構文
- エージェントフレームワークの基本関数
- VCSAG_GET_MONITOR_LEVEL
- VCSAG_GET_AGFW_VERSION
- VCSAG_GET_REG_VERSION
- VCSAG_SET_RES_EP_TIMEOUT
- VCSAG_GET_ATTR_VALUE
- VCSAG_SET_RESINFO
- VCSAG_MONITOR_EXIT
- VCSAG_SYSTEM
- VCSAG_SU
- VCSAG_RETURN_IMF_RESID
- VCSAG_RETURN_IMF_EVENT
- VCSAG_BLD_PSCOMM
- VCSAG_PHANTOM_STATE
- VCSAG_SET_ENVS
- VCSAG_LOG_MSG
- VCSAG_LOGDBG_MSG
- VCSAG_SQUEEZE_SPACES
- コンテナをサポートするエージェントフレームワーク基本関数
- スクリプトのエントリポイントの例
- エージェントメッセージのログ
- カスタムエージェントの作成
- スクリプトベースの IMF 対応カスタムエージェントの作成
- エージェントのテスト
- 静的タイプ属性
- 静的属性について
- 静的タイプ属性の定義
- ActionTimeout
- AdvDbg
- AEPTimeout
- AgentClass
- AgentDirectory
- AgentFailedOn
- AgentFile
- AgentPriority
- AgentReplyTimeout
- AgentStartTimeout
- AlertOnMonitorTimeouts
- ArgList
- AttrChangedTimeout
- AvailableMeters
- CleanRetryLimit
- CleanTimeout
- CloseTimeout
- ContainerOpts
- ConfInterval
- EPClass
- EPPriority
- ExternalStateChange
- FaultOnMonitorTimeouts
- FaultPropagation
- FireDrill
- IMF
- IMFRegList
- InfoInterval
- InfoTimeout
- IntentionalOffline
- LevelTwoMonitorFreq
- LogDbg
- LogFileSize
- LogViaHalog
- ManageFaults
- Meters
- MeterControl
- MeterRegList
- MeterRetryLimit
- MeterTimeout
- MonitorInterval
- MonitorStatsParam
- MonitorTimeout
- MigrateTimeout
- MigrateWaitLimit
- NumThreads
- OfflineMonitorInterval
- OfflineTimeout
- OfflineWaitLimit
- OnlineClass
- OnlinePriority
- OnlineRetryLimit
- OnlineTimeout
- OnlineWaitLimit
- OpenTimeout
- Operations
- RegList
- RestartLimit
- ScriptClass
- ScriptPriority
- SourceFile
- SupportedActions
- SupportedOperations
- ToleranceLimit
- 状態の遷移図
- 国際化されたメッセージ
- First Failure Data Capture（FFDC）を使用した VCS リソースの予期しない動作のトラブルシューティング
- 付録 A. 5.0 より前の VCS エージェントの使用
状態遷移
ここでは、次の状態の遷移を説明します。
リソースのオープン
安定状態のリソース
リソースのオンライン化
リソースのオフライン化
リソース障害（自動再起動なし）
リソース障害（自動再起動あり）
永続的なリソースの監視
リソースのクローズ
リソースの移行
また、状態の遷移は、ManageFaults サービスグループ属性に関するリソースの処理について示しています。
ManageFaults 属性に関する状態の遷移を参照してください。
これらの図で示す状態は、エージェントフレームワークが判断するリソースの状態を示しています。これらの状態は、エージェントフレームワーク内でのみ使用され、エンジンによって指定される IState リソース属性値とは別の値です。
エージェントは、静的リソースタイプ属性である LogDbg パラメータが値 DBG_AGINFO に設定されている場合に、リソースの状態の遷移情報をエージェントログファイルに書き込みます。エージェント開発者は、エージェントのデバッグ時にこの情報を利用できます。
エージェントが起動したとき、各リソースの初期状態は、Detached です。Detached 状態（Enabled=0）では、エージェントはリソースをオンライン状態またはオフライン状態にするすべてのコマンドを拒否します。
リソースが安定した Online 状態または Offline 状態にある場合、これらのリソースには定期的な間隔で monitor エントリポイントが実行されます。この間隔は、Online 状態のリソースの場合は MonitorInterval 属性に、Offline 状態のリソースの場合は OfflineMonitorInterval 属性に従います。予期せず Offline として検出された Online リソースは、障害が発生したと見なされます。障害が発生しているリソースを説明している図を参照してください。
エージェントがエンジンからリソースのオンライン化要求を受信すると、リソースが Going Online 状態になり、オンラインエントリポイントが呼び出されます。
online エントリポイントが完了した場合は、リソースが Going Online Waiting 状態になり、次の monitor エントリポイントの実行を待ちます。
online エントリポイントがタイムアウトになると、エージェントは clean エントリポイントを呼び出します。
GoingOnlineWaiting 状態の監視が online の状態を返した場合、リソースは Online 状態に移行します。
GoingOnlineWaiting 状態の監視が Intentional Offline の状態を返した場合、リソースは Offline 状態に移行します。
しかし、monitor がタイムアウトになるか、「Online 以外」の状態（すなわち、unknown または offline）を返した場合は、次のアクションを検討します。
OnlineWaitLimit に到達していない場合は、リソースが GoingOnlineWaiting に戻り、次の監視のため待機します。
OnlineWaitLimit および OnlineRetryLimit に到達し、状態が unknown のままの場合は、リソースが GoingOnlineWaiting に戻り、次の監視のため待機します。
OnlineWaitLimit および OnlineRetryLimit に到達し、状態が offline のままの場合、リソースは Offline 状態に戻り、そのリソースは faulted としてマーク付けされます。
OnlineWaitLimit に到達し、OnlineRetryLimit に到達せず、CleanRetryLimit に到達していない場合は clean が実行されます。
OnlineWaitLimit および CleanRetryLimit に到達し、OnlineRetryLimit に到達しない場合は、リソースが GoingOnlineWaiting になり、ADMIN_WAIT とマーク付けされます。
CleanRetryLimit に到達せず、エージェントが clean を呼び出すと、次の内容が発生します。
clean 回数がタイムアウトになるか失敗した場合は、リソースが再び Going Online Waiting 状態に戻り、次の monitor エントリポイント実行まで待機します。
clean が正常に終了して OnlineRetryLimit に到達し、その後の監視で状態が offline と返された場合、リソースは Offline 状態に遷移し、FAULTED として設定されます。
エンジンからリソースの offline 化要求を受け取ると、エージェントはリソースを GoingOffline 状態にし、offline エントリポイントを実行し、定期監視を停止します。
offline が完了した場合、リソースは GoingOffline Waiting 状態になり、エージェントがリソースの定期監視を開始してリソースの monitor コマンドを挿入します。offline がタイムアウトすると、リソースに対し clean エントリポイントが呼び出されます。clean がタイムアウトまたは完了し、clean が正常に行われてリソースが Going Offline Waiting 状態に移行した場合、clean は定期監視を開始して Offline Wait カウントがリセットされます。
Going Offline Waiting 状態の監視が offline または intentional offline を返した場合、リソースは offline 状態に移行します。
GoingOffline Waiting 状態の監視が unknown または online を返した場合や、監視がタイムアウトした場合、次のようになります。
OfflineWait Limit に到達しない場合、リソースは GoingOffline Waiting 状態に移行します。
Offline Wait Limit に到達し、先にマウント解除されたリソースが呼び出されると、そのリソースは UNABLE_TO_OFFLINE とマーク付けされます。
CleantRetryLimit に到達しない場合、clean が呼び出されます。
CleantRetryLimit に到達した場合、リソースは ADMIN_WAIT 状態としてマーク付けされ、そのリソースは GoingOffline Waiting 状態に移行します。
ユーザーが「-clearadminwait」操作を開始した場合、ADMIN_WAIT フラグがリセットされます。ユーザーが「-clearaminwait -fault」操作を開始した場合、エージェントで ADMIN_WAIT フラグがリセットされます。
この図では、リソースに障害が発生し、RestartLimit に到達した場合に発生する動作を説明しています。 monitor エントリポイントが継続的にタイムアウトになり FaultOnMonitorTimeout に到達するか、monitor が offline を返して ToleranceLimit に到達した場合。
clean の再試行制限に達し、リソースに ADMIN_WAIT フラグが設定され、そのリソースが online 状態に移行した場合。再試行制限に達していない場合、エージェントが clean エントリポイントを呼び出します。
clean が失敗するかタイムアウトになった場合、エージェントは、障害が発生していないかのようにリソースを online 状態に設定し、定期監視を開始します。clean が正常に終了した場合は、リソースが Going Offline Waiting 状態になり定期監視が開始され、エージェントは次の monitor を待機します。
clean が正常に終了した場合は、リソースが GoingOffline Waiting 状態になり、エージェントは次の monitor を待機します。
monitor が online を報告した場合、リソースは障害が発生していないかのように online に戻ります。monitor が offline を返した場合は、リソースが offline 状態になり、FAULTED とマーク付けされます。monitor が IO を返した場合は、リソースが offline 状態になります。
monitor が unknown を返すかタイムアウトになった場合、エージェントはリソースを Going Offline Waiting 状態に戻し、エンジンに UNABLE_TO_OFFLINE フラグを設定します。
メモ:
clean が成功した場合、エージェントはリソースを GoingOfflineWait へ移行し、faulted とマーク付けします。GoingOfflineWaiting の監視が online を返した場合、リソースは online 状態に移行します。これは、エンジンはリソースが offline 状態に移行することを期待しておらず、GoingOfflineWaiting 状態がエージェントにより clean な成功の結果として設定されたためです。
この図では、リソースに障害が発生し、RestartLimit に到達していない場合に発生する動作を説明しています。 monitor エントリポイントが連続してタイムアウトになり、FaultOnMonitorTimeout に到達するか、monitor が offline を返して ToleranceLimit に到達した場合、エージェントは clean counter をチェックし、clean エントリポイントが呼び出し可能かをチェックします。
CleantRetryLimit に到達した場合、リソースは ADMIN_WAIT フラグが設定され、そのリソースは online 状態に移行します。clean 再試行制限に到達しない場合、エージェントは clean エントリポイントを呼び出します。
clean が正常に終了した場合、リソースは Going Online 状態に置かれます。次に、online エントリポイントが実行され、リソースが再起動されます。「リソースのオンライン化」の図を参照してください。
clean が失敗するかタイムアウトになった場合、エージェントは、障害が発生していないかのようにリソースを Online 状態と設定されます。
リソースに障害が発生し、RestartLimit に達した場合の動作の説明については、「リソース障害（自動再起動なし）」の図を参照してください。
monitor が offline を返し、ToleranceLimit に到達した場合は、リソースは Offline 状態になり、FAULTED として設定されます。monitor がタイムアウトして FaultOnMonitorTimeouts に到達した場合は、リソースは Offline 状態になり、FAULTED として設定されます。
この状態図は、リソースが Closing 状態に移行する可能性のあるすべての状態を示します。次の表は、リソースが Closing 状態に移行する可能性のあるさまざまな状態において実行されるアクションを示します。
|
状態 |
Action |
|---|---|
|
Online から Closing |
hastop - local - force または hares -delete または Enabled = 0（リソースが永続リソースの場合のみ） |
|
Offline から Closing |
Enabled = 0 または hastop - local または hastop - local - force または hares -delete |
|
GoingOnlineWaiting |
hastop - local - force または hares -delete |
|
GoingOfflineWaiting |
hastop - local - force または hares -delete |
|
GoingMigrateWaiting |
hastop - local - force または hares -delete |
|
GoingOnline |
hastop - local - force |
|
GoingOffline |
hastop - local - force |
|
GoingMigrate |
hastop - local - force |
|
Probing |
Enabled = 0 または hastop - local または hastop - local - force または hares - delete |
移行処理は、仮想マシン（VM）がオンラインで VM オフラインであるターゲットシステムに移行される、ソースシステムから開始します。ソースシステムのエージェントが、エンジンからリソースの移行要求を受信すると、リソースが Going Migrate 状態になり、 migrate エントリポイントが呼び出されます。 migrate エントリポイントがリターンコード 255 が発生して失敗した場合、リソースは online 状態に戻り、以降操作の失敗がエンジンに通信されます。これは、移行操作を実行することができないことを示します。
エージェントフレームワークは 101 から 254 の範囲の戻り値を無視し、online 状態に戻ります。migrate エントリポイントが正常に完了するか、タイムアウトに到達した場合は、リソースは Going Migrate Waiting 状態に移行し、次の監視サイクルを待ちます。monitor は MonitorInterval の設定に従った頻度で呼び出します。 monitor が offline 状態に戻ると、リソースは offline 状態に移行し、ソースシステムの移行は完了したとみなされます。
offline 状態に移行した後でも、エージェントは MonitorInterval の設定に従った同じ監視頻度でリソースを監視し続けます。 これにより、VM のソースノードでの障害をすばやく検出できます。ただし、monitor エントリポイントがタイムアウトするか、online または unknown 状態が返された場合、リソースは MigrateWaitLimit リソースサイクルが完了するのを待機します。
MigrateWaitLimit 内の監視のうちのどれかが offline 状態を返した場合、リソースは offline 状態に移行し、これがエンジンに返されます。MigrateWaitLimit に到達した後で monitor エントリポイントがタイムアウトするか、online または unknown 状態が返された場合、ADMIN_WAIT フラグが設定されます。
リソースの移行操作がソースノードで成功した場合、ターゲットノードで、エージェントは監視頻度を OfflineMonitorInterval から MonitorInternal に変更し、完全移行の成功をすばやく検出できるようにします。ただし、MigrateWaitLimit に到達した後でもターゲットノードでリソースが online と検出されない場合、リソースは ADMIN_WAIT 状態に移行し、エージェントは OfflineMonitorInterval で設定した監視頻度にフェールバックします。
メモ:
: エージェントは、migrate エントリポイントがタイムアウトになるか、migrate エントリポイントのタイムアウト後の監視で、MigrateWaitLimit に到達した後でも online または unknown 状態を返した場合、clean を呼び出しません。問題解決後、ADMIN_WAIT フラグを手動でクリアする必要があります。
