異常 (Fault) 状態の対処は、RMSの最も重要な機能です。RMSの障害処理方法は、アプリケーションの状態によって異なります。たとえば、実行中のアプリケーションのRMSグラフで発生した障害 (Fault) は、Offline状態のRMSグラフで発生した障害 (Fault) の対処とは異なります。
ディテクタがOnline状態のグラフノードの異常 (Fault) を検出し、かつ、そのグラフノード上のuserApplicationもOnline状態だった時は、RMSはそのグラフノードのFaultScriptを実行します。Online状態だったグラフノードがOffline状態となったことがディテクタで検出された場合は、要求が存在しなくても同じFaulted状態であるとして処理されます。
FaultScriptの完了後、RMSはFaultが発生したグラフノードの親に対してFault状態を通知します。親グラフノードでも同様にFaultScriptが実行され、Faultメッセージを転送します。
orOpグラフノードの場合は特殊で、子の状態の論理ORを通知します。ORグラフノードがFaultメッセージに反応するのは、Online状態の子グラフノードが存在しない場合のみです。orOpがOnline状態の子グラフノードが存在する場合は、RMSはこの段階でFault処理を終了します。
orOpグラフノードによるFault処理中断がなければ、FaultメッセージはuserApplicationに到達します。ここで、userApplicationはFaultScriptを実行します。この処理では、以下のAutoSwitchOverとPreserveStateの属性の組合せに従って、3種類の設定が考えられます。
AutoSwitchOverにResourceFailureが設定されている
AutoSwitchOverにResourceFailureの設定がなく、かつPreserveState=1 である
AutoSwitchOverにResourceFailureの設定がなく、かつPreserveState=0 であるか設定されていない
AutoSwitchOverにResourceFailureが設定されている
AutoSwitchOver属性にResourceFailureが設定されていると、RMSはPreserveState属性を無視してAutoSwitchOver属性だけが設定されているものとして処理を行います。この場合の処理の流れを以下に示します。
userApplicationは切替え処理を実行しようと試みます。切替えを行うためには、そのクラスタノード上でuserApplicationがOffline状態になっていなければならないため、Offline要求が発生します。
Offline処理が完了すると、Online要求がリモートクラスタノードの該当するuserApplicationに送信されます ("2.1.6 切替え処理"を参照してください)。ただし、通常のOffline要求の場合と異なり、userApplicationはOffline状態ではなく、Faulted状態となります。これにより、再度切替えが行われても、userApplicationが異常の発生したクラスタノードに戻る可能性がなくなります。
Offline処理中にさらに異常 (Fault) が発生した場合 (たとえば、Faulted状態として通知されたグラフノードに対応する資源を、RMSが正常に非活性化 (Offline) できなかった場合など) は、切替え処理は実行されません。これは、対象資源が未定義状態 (使用されているかいないかが判断できない) と判断されるためです。userApplicationはこれ以上のアクションを起こさず、すべての非強制である外部要求を抑止します。
ポイント
Offline処理中に発生した故障 (Fault) は、Double Faultと呼ばれます。
RMSはこの状態 (Double Fault) を解決することができないため、システム管理者の介入が必要となります。この場合、「データ破壊防止は、業務の可用性維持よりも重要」という方針で対処してください。
重要なユーザ業務である場合は、userApplication構成時に、HaltFlag属性を設定することができます。HaltFlag属性が設定されている場合は、Double Faultが発生した場合、Double Faultが発生したクラスタノードは他ノードから強制停止され、RMSは他のノードへuserApplicationの切替えを行います。
AutoSwitchOverにResourceFailureの設定がなく、かつPreserveState=1
この場合の処理の流れを以下に示します。
FaultScriptの実行後、userApplicationはそれ以上の処理を行わない。
全グラフノードの状態は現在の状態を保持する。
このPreserveState属性は、オブジェクトが監視している対象資源を、アプリケーション自らが修復可能な場合に使用されます。
AutoSwitchOverにResourceFailureの設定がなく、かつPreserveState=0または設定なし
この場合、障害 (Fault) 発生時にOffline処理が実行されます。しかし、Offline処理が成功しても失敗しても切替えは行われません。
切替え要求保留中のFault
Offline処理中に切替え要求で障害 (Fault) が発生した場合は、AutoSwitchOver属性がNoに設定されていても障害 (Fault) 発生によるOffline処理の成功、かつ終了後に切替えが行われます。これは、システム管理者によって送信された切替え要求により、切替え要求自体が発生しているためです。現在の切替え要求が指定切替え要求である場合は、切替え先は最も優先順位の高いノードではなく、指定切替え要求で明示的に指定されたノードになります。
参照
AutoSwitchOverとPreserveState属性の詳細については、"付録D 属性 "を参照してください。
ノード上のアプリケーションがOnline状態でない場合でも、RMSグラフ上でそのノードにアプリケーションが構成されていれば、RMSは監視を継続します。このようなグラフノードの1つで異常 (Fault) が発生し、ディテクタが検出すると、Faultが表示されますが、Fault処理は行われず、したがって、FaultScriptも実行されません。親グラフノードへのメッセージも送信されません。
この場合、1つの子オブジェクトがFaultedであっても、andOpオブジェクトはOffline状態となる可能性があります。
これは、userApplicationグラフ内のグラフノード間の必須依存関係は、userApplicationを実行する場合にのみ存在するためです。
ローカルファイルシステムを表すgResourceオブジェクトは、復旧が簡単で、かつ、Faulted状態に陥りやすいオブジェクトの一例です。グラフノード自体に発生する障害 (Fault) の原因は、ディスクのI/Oエラーを除けば、ほとんどの場合は管理者によるumount(1M) の誤操作が原因です。この場合、userApplication全体を切替えることは、最善のリカバリ処理とは言えません。したがって、Fault処理が最適な解決策でもありません。
このような場合の対処としては、管理者がオブジェクトのAutoRecover属性を設定する方法が考えられます。AutoRecover属性を設定したオブジェクトがOnline状態で異常 (Fault) が発生すると、FaultScriptの実行前にOnlineScriptが実行されます。OnlineScriptの実行後、一定時間内にオブジェクトがOnline状態になれば、Fault処理は行われません。
障害 (Fault) の原因がグラフノード自身にある場合、つまり、子のグラフノードの障害 (Fault) が原因ではない場合は、RMSはAutoRecover属性のみを評価します。したがって、RMSはディテクタが存在するグラフノードのAutoRecover属性のみを評価することになります。なお、各種要求の処理中、または、グラフノードがOffline状態で障害 (Fault) が発生した場合は、AutoRecover属性による復旧は行われません。
Offline処理中に障害が発生しても、グラフノードのOffline処理が直ちに停止することはありません。その時点のツリーのFaulted状態が保存され、リーフノードに到達するまで通常のOffline処理が継続します。しかし、成功または失敗のメッセージが上方のuserApplicationに向けて伝播され、途中でそのグラフノードに到達した時点で、この障害は再現されて処理されます。この方法により、障害を発生直後に処理することによって生じる競合状態の発生を回避することができます。
Fault処理の例を以下に示します。
例4
この例での処理の流れは次のとおりです。
アプリケーションappは、AutoSwitchOver属性がNoに設定され、ノードfuji2RMS上でOnline状態にあります。
要求はありません。
lfsオブジェクトにはAutoRecover属性が設定されていません。
システム管理者の誤操作により、lfsファイルシステムがアンマウントされました。
Fault処理は次のとおりです。
lfsオブジェクトのgResourceディテクタは、そのオブジェクトがOffline状態であることを検出します。対応するuserApplicationがOnlineであり、かつOffline要求が存在しないため、RMSはこのOffline通知を障害 (Fault) であると判断し親cmdに通知します。
ポイント
メッセージ: 予期しないOffline状態は障害 (Fault) になります。
この例のcmdオブジェクトには、FaultScriptは存在しません。cmdオブジェクトは直ちにFaulted状態になり、その障害 (Fault) を親に通知します。
andOp1にもFaultScriptがないため、直ちにFaulted状態に移行し、その障害 (Fault) を親appオブジェクトに通知します。
appオブジェクトは、Faulted状態になり、AutoSwitchOver属性がNo以外に設定されているため、切替えに備えてOffline処理を開始します。
この例では、ローカルファイルシステムlfsマウントポイント/mntを使用し、OfflineScriptlfsは、単純命令umount /mntで構成されているものとします。/mntは、すでにマウントされた状態にないため、OfflineScriptは終了コード0以外で終了します。
したがって、RMSのOffline処理は障害発生後に失敗します。ローカルの状態が依然明確でないため、切替えはできません。RMSは、システム管理者の介入を待ちます。
lfs に、より複雑なOfflineScriptを使用すればオブジェクトがマウントされているかを確認して、終了コード0で終了することも可能です。この場合、RMSは障害発生後fuji3RMSに切替えを行ってから、Offline処理を正しく終了することができます。fuji2RMS 上の全ノードはそれから、Online処理が成功した後にOffline状態になり、appだけが、Faulted状態のまま残ります。
例5
シナリオは、AutoRecover属性がlfsオブジェクトに設定されていることを除いて、と同じです。
Fault処理は次のとおりです。
lfsオブジェクトのgResourceディテクタは、そのオブジェクトがOffline状態であることを検出します。対応するuserApplicationがOnlineであり、かつOffline要求が存在しないため、RMSはこのOffline通知を障害 (Fault) であると判断し、通知を行います (上記を参照)。
AutoRecover属性が設定されているため、RMSが親cmdオブジェクトに直ちに障害 (Fault) を通知することはありません。RMSは、lfsオブジェクトのOnlineScriptを実行し、アンマウント処理が行われる前の状態に戻します。
数秒後にlfsオブジェクトのgResourceディテクタから、オブジェクトがOnlineの状態に戻ったことが通知されます。RMSは、オブジェクトをOnline状態に戻し、それ以上のFault処理は行いません。
例6
この例では、appがOnline要求を受信しますが、lfsで表されたファイルシステムは破損しています。
Fault処理は次のとおりです。
要求によりOnline処理が開始します。
lfsオブジェクトはOnlineScriptを開始し、0以外の終了コードで処理が終了します。
次に、lfsオブジェクトはFault処理を開始します。FaultScriptが用意されていればそれを実行したうえで、Faulted状態に移行し、RMSに障害 (Fault) を通知します。
この他の処理は、上記で説明した方法と同様に行われます。
ポイント
AutoRecover属性が設定されていても、この場合のFault処理は同じです。この属性はアプリケーションが、安定したOnline状態にある場合、すなわちアプリケーションがOnline状態で、かつ保留中の要求がない場合にのみ意味を持ちます。
Fault処理が成功すると、userApplication配下の全グラフノードはOffline状態となり、userApplicationオブジェクトのみがFaulted状態となります。障害によりOffline処理が失敗した場合や、アプリケーションのPreserveState属性が設定されている場合、グラフの少なくとも一部はOffline以外の状態すなわちOnline、Standby、Faultedのいずれかになります。
このような状態では、userApplicationのノードへの切替え要求はすべて抑止されます。これは、RMS BM (ベースモニタ) からはWait状態で制御不能であるグラフノードが存在するためです。システム管理者は、障害 (Fault) の原因を取り除いた後、RMSを通常の動作に戻すため以下のいずれかの手順でベースモニタに通知します。
次のコマンドを使用してuserApplicationオブジェクトとグラフノードのFaulted状態をクリアすることができます。
hvutil -c userApplication
このコマンドは親アプリケーションとそのグラフを矛盾のない状態に変更することによってFaultのクリアを行います。アプリケーションオブジェクトがOnline状態である場合は、Online処理が開始され、アプリケーションオブジェクトがOffline状態の場合は、Offline処理が開始されます(ユーザにはどちらの処理が開始されるかが通知され、その時点で処理の中止を選択することができます)。アプリケーションにつながるすべてのブランチが、Online状態またはOffline状態に揃った時点でFaultのクリアは完了します。最終状態がOfflineであれば、システム管理者は切替え要求を行い、userApplicationをOnline状態へ遷移させることができます。
userApplicationオブジェクトがOnline状態であった場合、「hvutil -c」を起動しても、ツリー内の一部のオブジェクトが処理されない場合があります。ツリー全体をOffline状態にするには、以下で説明するように「hvutil -f」を使用します。
次のコマンドは、Offline要求をuserApplicationオブジェクトに送信します。
hvutil -f userApplication
このコマンドを実行すると、アプリケーションのOffline処理が開始されます。コマンドの実行が完了すると、アプリケーションとグラフのすべてのオブジェクトがOffline状態に変更され、Faultはクリアされます。その後必要に応じて、システム管理者は切替え要求を行い、userApplicationをOnline状態へ遷移させることができます。
RMSは、SysNodeで発生した異常 (Fault) を、他のグラフノードで発生した異常 (Fault) とは別の方法で扱います。SysNode異常は以下の場合に発生します。
SysNodeディテクタがRMS BM (ベースモニタ) と通信できなくなった場合。
CF LEFTCLUSTERイベントが発生した場合。
上記のいずれかの状態が発生した場合、RMSは、自動切替えを行う前に、まず通信不可となったクラスタノードが停止されていることを確認します。この確認のために、RMSはシャットダウン機構 (SF) に対して該当クラスタノードの強制停止を依頼します。SFの詳細については、"PRIMECLUSTER Cluster Foundation導入運用手引書"を参照してください。
SFにより、クラスタノードが停止されていることを確認されると、停止されていることが確認できたクラスタノード上でOnline状態であり、AutoSwitchOver属性にHostFailureを含むすべてのuserApplicationオブジェクトが、正常に動作している切替え先ノードに対して優先切替えを行います。
例7
この例での処理の流れは次のとおりです。
RMSは、それぞれが、SysNodeオブジェクトのfuji2RMSとfuji3RMSで表される2つのノード、fuji2とfuji3とで構成されるクラスタ上で実行されています。
appは、fuji2RMS上でOnline状態にあり、AutoSwitchOver属性にはHostFailureが設定されています。
fuji2上でシステム障害が発生し、panicメッセージが表示されます。
RMSの反応は次のとおりです。
CFは、ノード障害が発生したと判断し、LEFTCLUSTERイベントを作成します。
ノードディテクタは、ノードがFaulted状態にあると通知し、SysNodeをWait状態に移行させます。RMSはLEFTCLUSTERイベントを受信するとSFに停止要求を送信します。
SFがノードの停止に成功するとDOWNイベントが送信されます。
RMSは、DOWNイベントを受信しSysNodeをFaultedとマークします。
fuji2RMSオブジェクトはFaultScript (構成されているものとします) を実行します。
fuji2RMSオブジェクトは、userApplicationオブジェクトにfuji2RMSが失敗したことを通知します。appは、fuji2RMSに障害が発生した時点でfuji2RMS上でOnlineであり、AutoSwitchOver属性にHostFailureが設定されているため、fuji3RMS上のオブジェクトappはOnline処理を開始します。
SFがノードの停止作業を行っている間に、SysNodeオブジェクトのWait状態の継続期間が、オブジェクトのScriptTimeoutを超過した場合、RMSはその旨のERRORメッセージをswitchlogに記録します。
この時点で未定義の状態のクラスタノードが1つ生じたことになるため、RMSは他のすべてのノードでそれ以上の処理を停止します。この状態を解決するには "PRIMECLUSTER Cluster Foundation導入運用手引書"で説明したように、通常、オペレータの介入が必要になります。処理が完了すると、CF がDOWNイベントを送信し、RMSは処理の停止を解除し、通常の運用が再開されます。
ScriptTimeout属性の詳細については、"付録D 属性 " を参照してください。
