2.3.3 Online/Offline処理と状態遷移

以下の表に、「制御されるアプリケーション」の状態に応じたスケーラブルコントローラの状態を示します。

表2.1 子アプリケーションの状態とスケーラブルコントローラの状態の関係
コントローラの状態	子アプリケーションの状態
Online	任意のノード上で最低1つがOnline
Offline	すべてのノード上ですべてがOffline
Faulted	任意のノード上で最低1つがFaulted、すべてのノード上で他のすべてがOffline
Standby	任意のノード上で最低1つがStandby、すべてのノード上でOnlineがない
Warning	任意のノード上で最低1つがOnline、すべてのノード上で他はOffline

注意:異なるスケーラブルアプリケーションであれば、同一ノードまたは異なるノードで同時に2つ以上をOnlineにすることはできますが、個々のスケーラブルアプリケーションは、1つのノードでしかOnlineにすることができません。たとえば、Oracle RACのRMS構成設定を行う場合、Oracleデーモンプロセスは、複数のノードでOnlineにする必要があるため、単一のRMSアプリケーションではなく、複数の独立した制御されるRMSアプリケーション (デーモンごとに1つの子アプリケーション) として表す必要があります。これら子アプリケーションはすべて、Oracle RACの親スケーラブルコントローラから集中的に制御、管理および表示することができます。

2.3.3.2 アプリケーションが Online 状態になるノードについて

制御するアプリケーションと制御されるアプリケーションは、それぞれ異なるノード上でOnline 状態になる場合がありますが、アプリケーションの監視および制御に問題はありません。

注意

ノード故障などによりノードが異常停止し、その後、起動した場合、制御するアプリケーションが複数ノード上でOnline 状態になる場合がありますが、運用上問題ないため、対処は必要ありません。

2.3.3.3 制御されるアプリケーションへの要求の伝播

コントローラからの優先Online要求は、制御されるすべてのアプリケーションに伝播され、それらの各アプリケーションはPriorityList属性に定義されたノードの順序に従ってOnline状態に遷移します。OfflineおよびStandby要求はすべてのノード上で、すべての制御されるアプリケーションに伝播されます。

IndependentSwitch属性は、スケーラブルコントローラオブジェクトでは1に設定されなければなりません。この属性により、制御される子アプリケーションに影響を与えずに、親アプリケーションをノード間で切替えることができるようになります。ただし、親アプリケーションが「hvswitch -f」などの強制要求によって切替えられる場合は、IndependentSwitch属性の設定は無視されます。この場合、コントローラによって切替え処理の一部としてOffline要求がそれぞれの子アプリケーションに伝播されます。

RMS の停止や OS のシャットダウンによって親アプリケーションと子アプリケーションが同時に切替わり、子アプリケーションが次に優先度の高いノード上で Online 状態になる前に RMS の再起動が完了した場合、子アプリケーションは、その PriorityList 属性に定義されたノードの順序に従ってOnline 状態に遷移します。このため、子アプリケーションは、切替え前のノードで再び Online 状態となります。

2.3.3.4 コントローラのWarning状態

スケーラブルコントローラは、以下のいずれかの条件を満たした場合、GUI およびhvdispコマンドでWarning状態を表示します。これは、スケーラブルを構成するクラスタアプリケーションの一部が動作していないことを管理者に警告するためです。

Online状態のコントローラに制御されるアプリケーションの少なくとも1 つがOnline状態からOffline、StandbyまたはFaulted状態に遷移した場合
Standby状態のコントローラに制御されるアプリケーションの少なくとも1 つがStandby状態からOfflineまたはFaulted状態に遷移した場合

注意

Online状態のコントローラに制御されるアプリケーションのうち、一部のアプリケーションが動作する、すべてのノードの RMS が停止している場合、異常が検知できないため、コントローラの状態は、Online状態のままとなります。

2.3.3.5 アプリケーションのWarning状態

スケーラブルコントローラのうち少なくとも1つが Warning 状態になると、スケーラブルコントローラを含むアプリケーションは Warning 状態になります。すべてのスケーラブルコントローラが送信されたWarning以外の状態になると、アプリケーションはそれぞれの状態に戻ります。コントローラの場合と同様、GUIおよびhvdispコマンドではWarning状態が表示され、管理者に対してスケーラブルな親アプリケーションの完全な機能が稼動していないことを警告します。

コントローラがOfflineまたはFaultedに遷移するか、制御されるすべてのアプリケーションがOnlineまたはStandbyに遷移すると、Warning状態はそれぞれの状態に変わります。

2.3.3.6 コントローラStateChangeScript

コントローラのStateChangeScript属性には、制御される子アプリケーションがOnline、Offline、Faulted、またはStandby状態に遷移するたびにスケーラブルコントローラで実行されるスクリプトを指定します。スクリプトは、制御する親アプリケーションが動作できるすべてのノードで実行されます。これはコントローラ自身から出された要求に代わって実行される場合でも同じです。StateChangeScriptスクリプトは、子アプリケーションが実行されているノードの状態がOfflineまたはFaultedに遷移した場合にも実行されます。このスクリプトは、状態遷移には影響しません。異常終了コードがswitchlogに記録されるだけです。

同時に複数の状態遷移イベントが送信された場合、それぞれのイベントに対してStateChangeScriptスクリプトが実行されます。イベントを受信すると、即座 (遅延なし) にStateChangeScriptスクリプトがスケジューリングされます。同じノードから複数のイベントが送信された場合は、必ずイベントを受信した順序に従ってStateChangeScriptが呼び出されます。

スクリプト実行時環境変数

StateChangeScriptの実行時には、以下のRMS環境変数が設定されています。各変数の名前と用途を以下に示します。各変数の内容およびフォーマットの詳細については、"E.2 RMSグローバル環境変数"、"E.4 RMSスクリプト実行環境変数"を参照してください。

RMSでは、状態変更スクリプトの呼び出しがアプリケーションの状態変化に起因するか、ノードの状態変化に起因するかに応じて、以下の2つのRMS環境変数が使用できます。

HV_APPLICATION_STATE_CHANGE_INFO
StateChangeScriptスクリプトの呼び出しが、「制御されるアプリケーション」の状態変化に起因する場合に設定されます。コロンで区切られた各文字列は以下の意味を持ちます。
- ノード上のアプリケーションの前の状態 (ローカルノードに記録された状態と同一)
- ノード上のアプリケーションの現在の状態 (ローカルノードに記録された状態と同一)
- アプリケーションの状態が変化したノードの名前
- 状態が変化したアプリケーションの名前
StateChangeScriptスクリプトの呼び出しがノードの状態変化に起因する場合、HV_APPLICATION_STATE_CHANGE_INFOは空になります。
HV_HOST_STATE_CHANGE_INFO
「制御される子アプリケーション」を実行可能なSysNodeの状態がOfflineまたはFaultedに変化したために、スケーラブルコントローラのStateChangeScriptスクリプトが呼び出された場合に設定されます。コロンで区切られた各文字列は以下の意味を持ちます。
- 前のノードの状態
- 現在のノードの状態
- ノードの名前
- ノードの状態変化の理由: シャットダウン機構、hvshutコマンド、または不明。
StateChangeScriptスクリプトの呼び出しが「制御される子アプリケーション」の状態変化に起因する場合、HV_HOST_STATE_CHANGE_INFOは空になります。

RMSが呼び出す他のスクリプトと同様に、StateChangeScriptでも以下のRMS環境変数を参照できます。

HV_APPLICATION
現在のオブジェクトを含む現在のサブツリーの最上位にあるuserApplicationオブジェクトの名前です。
HV_AUTORECOVER
1が設定されている場合、スクリプトの呼び出しがAutoRecoverの試行に起因することを示します。
HV_FORCED_REQUEST
1が設定されている場合、強制要求によるスクリプト呼び出しであることを示します。
HV_LAST_DET_REPORT
現在のオブジェクトに対して、ディテクタが検知した最新の状態です。
HV_OFFLINE_REASON
実行中のOffline処理の理由: 保守停止要求、手動切替え、リソース故障後のフォローアップ処理、またはアプリケーション停止要求
HV_NODENAME
現在のオブジェクトの名前です。
HV_SCRIPT_TYPE
スクリプトの種類です。
NODE_SCRIPTS_TIME_OUT
現在のオブジェクトおよびスクリプトの種類のタイムアウト値です。

スクリプト実行シーケンス

StateChangeScriptスクリプトは、イベントを受信すると即座に実行されます。その結果、他のRMSスクリプト (他のオブジェクトまたは現在のオブジェクトのStateChangeScriptスクリプトを含む) と並列に実行されることがあります。複数のイベントがほぼ同時に送信される可能性があるため、適切な順序で実行されるようユーザスクリプト側で調整する必要があります。スクリプトの作成者は、ロックまたはOSの他の機能を使用して、スクリプトから共有リソースへのアクセスが適切に行われるように配慮しなければなりません。

2.3.3.7 Online/Standby/Offline処理の順序制御とアプリケーショングループ

コントローラのApplicationSequence属性は、Online、Offline、およびStandby要求がどのように子アプリケーションに伝播されるかを制御します。この属性では、コントローラのResource属性で指定されるコントローラのすべての子アプリケーションのリストが示されますが、並列処理または順次処理であるかどうかでグループに分けられます。

スペースで区切られたアプリケーションのグループを、要求グループと呼びます。要求グループのアプリケーションはすべて並列処理されます。

コロン (:) で区切られた要求グループは、順次処理されます。OnlineまたはStandby要求は、左から右へ順に処理されます。Offline要求は、右から左へ順に処理されます。

たとえば、コントローラのApplicationSequence属性が以下のように指定されているとします。

A1 A2:B:C1 C2

コントローラによって、以下のようにOnline要求が発行されます。

A1およびA2 (最初の要求グループ) は並列処理され、一方が他方を待つことはありません。ただし、A1およびA2の両方からOnline状態が送信されない限り、コントローラは次のグループには進みません。
B (2番目の要求グループ) が次に処理されます。BからOnline状態が送信されない限り、コントローラは次のグループには進みません。
C1およびC2 (3番目の要求グループ) が最後に並列処理されます。

Offline要求は、これと逆の順番で処理されます。つまり、C1およびC2が最初に処理され、次にB、最後にA1およびA2が処理されます。

処理順序が重要になるのは、スケーラブルコントローラからの要求が「制御されるアプリケーション」に伝播されている間のみです。手動切替えおよび自動切替えを含む他の理由でアプリケーションの状態が変化した場合、ApplicationSequence属性は無視されます。

Offline処理の順序は、「hvshut -l」などのローカルのhvshutでも維持されます。ただし、「hvshut -a」などのクラスタ規模の要求では、順序が無視されます。各ノードでは、アプリケーションのOffline処理が独立して行われます。

他のサブアプリケーションと同様に、「hvshut -L」および「hvshut -A」の処理時にはスケーラブルな要求グループは処理されません。

スケーラブルコントローラからの要求の伝播は、子アプリケーションが実行される可能性のあるノードの状態からも影響を受けます。同じ要求グループのアプリケーションのノードが使用可能でない場合、その要求は伝播されません。該当するノードが使用可能になるまで遅延されるか、ScriptTimeout属性に設定された時間が経過するまで遅延されます。

2.3.3.8 サブクラスタでの自動起動

一部のノードが停止している状態をサブクラスタと呼びます (以降「サブクラスタ」と記載)。この場合でも、「制御するアプリケーション」が自動起動できるように設定することができます。これが必要とされるのは、「制御される子アプリケーション」が親コントローラのApplicationSequence属性で定義される順序に従ってクラスタシステムの一部でOnlineになる場合があるためです。

たとえば、はじめにすべてのクラスタノードが停止している状態から一部のノードが起動し、他のノードは依然メンテナンス中であったとします。他のクラスタノードが現在OfflineまたはFaultedであるかどうかにかかわらず、起動中のサブクラスタで実行されるべき「制御されるアプリケーション」は、スケーラブルコントローラの要求に従ってOnlineに切り替わる必要があります。管理者が不在な場合もあるため、この場合「hvswitch -f」を使用するような設定は選択できません。クラスタ構成が自身で自動的に起動する必要があります。

上記の例は、userApplicationオブジェクトのPartialCluster属性により実現できます。1に設定すると、アプリケーションは自らのプライマリノードを含む他のノードがOfflineまたはFaultedであっても、現在オンラインであるノード内でOnline要求の処理ができます。0に設定すると、(現在の動作では) アプリケーションは実行が可能なすべてのノードがOnlineである場合にしか、Online要求の処理ができません。デフォルト値は0です。

スケーラブルコントローラを含むアプリケーション(制御するアプリケーション) において、アプリケーショングラフに ClusterExclusive 属性が設定されたリソースがない場合PartialCluster属性を 1 に設定できます。それ以外の場合は、PartialCluster属性を0 に設定する必要があります。

「制御するアプリケーション」にcontrollerオブジェクト以外のオブジェクトが含まれない場合は、PartialCluster属性を1に設定しても問題ありません。「制御するアプリケーション」が異なるサブクラスタで複数自動起動されても、排他リソースは共用されません。自動起動の一部として、それぞれの「制御されるアプリケーション」にOnline要求が伝播され、現在のサブクラスタからノードが要求された場合は、これらのアプリケーションがOnlineになることもあります。

しかし、一部の「制御されるアプリケーション」が複数のサブクラスタからノードを要求した場合、これらのアプリケーションはOnlineにはなりません (これが本来の動作です)。これらのアプリケーションのPartialCluster属性は0に設定されており、サブクラスタにまたがっている「制御されるアプリケーション」がOnline処理を拒否するようになっています。

各アプリケーショングループの「制御されるアプリケーション」がOnlineになるまで、Online要求の伝播がスケーラブルコントローラによって遅延するため、複数のノードが同じスケーラブルコントローラに対するOnline要求を同時に開始した場合でも、ApplicationSequence属性で指定された順序は維持されます。

2.3.3.9 サブクラスタでの切替え

「制御するアプリケーション」のPartialCluster属性が設定されている場合、サブクラスタのノード間で自動または手動 (「-f」強制オプションの有無による) でOnlineに切替えできます。これは、「制御するアプリケーション」自身については安全です。コントローラ以外には実際のリソースがないからです。また、「制御されるアプリケーション」についても安全です。それぞれのPartialCluster属性が0に設定されており、サブクラスタの境界をまたがった場合はOnlineにならないからです。

2.3.3.10 子アプリケーションの手動切替え

「hvutil -f」コマンドを使用して、Online状態の最後の子アプリケーションを手動でOfflineにしようとすると、親コントローラがFaulted状態になります。このような状況を回避するため、RMSではOnline状態にある最後の「制御されるアプリケーション」をOfflineにする「hvutil -f」コマンドが拒否され、以下のメッセージが生成されます。

ERROR: Application controlled from another online application - <application>.

2.3.3.11 保守モード時の操作

以下の例では、保守モード時のコントローラの動作について説明します。

ノードfuji2およびfuji3上にアプリケーションapp1、app2、およびapp3が構成されているとします。
app2はFollowモードコントローラでapp1を制御します。
app3はScalableモードコントローラでapp2を制御します。

以下は、この例のRMS構成ツリーおよび対応グラフを示しています。

図2.6 保守モード時のコントローラの例

ノード間でのアプリケーションの切替え

グラフの観点から、これらを「横方向」の切替え操作として考えることができます。

以下の図のように、スケーラブルコントローラに制御された子アプリケーションが保守モードに切替えられた場合、その親はhvswitchコマンドを使用してノード間で手動または自動で切替えることができます。app2を保守モードに切替えると、フォローコントローラに制御された子アプリケーションであるapp1も自動で保守モードに切り替わります。

図2.7 子が保守モードの場合にスケーラブルな親アプリケーションを切替える

同様に、以下の図のようにスケーラブルコントローラの親アプリケーションが保守モードに切替えられた場合、その子はhvswitchコマンドを使用してノード間で切替えることができます。ただし、保守モードでは親は処理要求を発行しないため、実際は手動コマンドによってのみ実行できます。app2を異なるノードに切替えると、フォローコントローラに制御された子アプリケーションであるapp1も自動的にそのノードに切り替わります。

図2.8 親が保守モードの場合にスケーラブルな子アプリケーションを切替える

つまり、これらの「水平」のhvswitchコマンドは正しく処理されます。

Online、Offline、およびFault処理の制約

グラフの観点から、これらを「縦方向」の切替え操作として考えることができます。

以下の図のように、app2が保守モードのときにapp3をhvutilコマンドでOfflineにすることを考えます。

図2.9 子が保守モードの場合に親をOfflineにするよう試行する

前述のhvswitchコマンドと異なり、この「hvutil -f」操作では、処理の続行に子アプリケーションからの応答を必要とします。保守モードでapp2が親からの通常の処理要求に応答できないため、Offline要求は最終的にタイムアウトになります。「hvutil -c」でFault処理を試行する場合も同じです。

以下の図のように、親が保守モードの場合に子をOfflineにするよう試行しても、やはり失敗しますが、前の場合のような長い遅延がありません。Offline処理を開始できるのは親だけであるため、RMSがすぐにエラーを生成します。

図2.10 親が保守モードの場合に子をOfflineにするよう試行する

親からの応答を必要としないため、Fault処理の「hvutil -c」要求を子に対して発行できます。

つまり、これらの「縦方向」のhvutilコマンド操作は、保守モードの子または親アプリケーションからの応答がアプリケーションで必要とされる場合に失敗します。

スケーラブルコントローラで推奨される操作

保守モードの要求は制御階層の最上位アプリケーションに対して発行することを強く推奨します。これは、予期しない動作を回避するのに役立ちます。

子アプリケーションは他のノードへ切替えるための自動要求を親から受信しません。また、自動のOnline、Offline、またはFault処理要求が親から伝播されることはありません。
リソース故障の場合、下位レベルオブジェクトからの切替え要求はすぐに失敗します。RMSはタイムアウト遅延を待機せずにFault処理を開始できます。