保守モードのアプリケーションが存在すると、同一グラフ内の他のオブジェクトは処理上の制限を受けます。この制限により、本章で前述したすべての処理が停止され、以下のオブジェクトに影響が生じます。
保守モードにあるアプリケーションのすべての子オブジェクト
保守モードのアプリケーションが存在するノードとその上位ノード
処理要求の種類によっては、制限があるためにエラーまたはタイムアウトのいずれかが発生する場合があります。
制限がどのように適用されるかを理解するため、2つのアプリケーション (app1およびapp2) が、それぞれ1つずつ依存資源 (Res1およびRes2) を持ち、2つのノード (NodeAおよびNodeB) のいずれでも実行されるような構成を使って説明します。以下の図は、app1が保守モードになった場合の、オブジェクトの状態を示しています。
図2.4 保守モード時の制限の例
この例は以下の機能について説明しています。
アプリケーションの保守モードは、アプリケーションがOnline化される可能性があるすべてのノード、すなわちPriorityList属性に記載されたすべてのノードに適用されます。このため、app1は実行の可能性があるノードにおいては、そのノードでの以前の状態に関係なく、すべてMaintenance状態にあります。
app1には各ノードにおける目標状態が設定されています。 これは、保守モード開始直前の状態です。目標状態は、GUIまたはCLIのhvdispで、アプリケーションのStateDetailsパラメタによって確認できます。
Res1はapp1の子であるため、いかなる場所においても制限を受けます。
app1が、NodeAとNodeBのいずれのグラフにも現れるため、両者にも制限があります(いずれのノードでもRMSの停止処理を開始すると、RMSがapp1の保守モードを停止するのを待ってから、停止処理を実行することを求められます)。
app1は、app2のグラフには表示されません。したがって、app2のOffline化やOnline化、別ノードへの切替えなど、app2とその資源に関する通常の処理は許可されます。
クラスタアプリケーションが保守モードに入った状態で、RMSやシステムを停止しないでください。停止する場合は、必ずすべてのクラスタアプリケーションの保守モードを終了してから行ってください。
すべてのクラスタアプリケーションの保守モードを終了せずに、forceオプションを使用してRMS を停止すると、オフライン処理が実行されない状態でOSが停止します。このため、RMS再起動時、GDS論理ボリュームのように、リソースの状態に影響がでる場合があります。
上記の内容は「hvutil -m on」または、各アプリケーションを右クリックしてから、GUIを使ってアプリケーションの保守モードを開始した場合の制限です。これとは別に、「hvutil -M on」が使用された場合や、ノードを右クリックしてGUIを使って処理を開始した場合は、保守モードがクラスタ全体に適用され、すべてのノードで処理が停止します。
あるuserApplicationとそのグラフ内の1つ以上のリソースがOffline状態またはFaulted状態にあり、同時にグラフ内の他のリソースがOnline状態またはFaulted状態にあるという状況が発生する場合があります。これは、管理者の手動操作による介入があった場合や、Faultクリア処理の失敗により、オブジェクトのいくつかがOnline状態またはFaulted状態で残った場合に起こります。
そしてこの場合、これらのOnline状態またはFaulted状態のリソースオブジェクトにClusterExclusive属性が設定されていると、複数のノードで同時にOnline状態になることはできません。userApplicationが単にOfflineまたはFaultedとマークされている場合であれば、そのuserApplicationはリソースとともに他のノードに切替えられてOnline状態になることができます。しかしこれはClusterExclusive属性の意図する動作とは矛盾し、その結果生じるリソースの競合によりデータの破損が生じる可能性があります。このような問題を回避するため、RMSは、userApplicationにOfflineやFaultedではなく、Inconsistentとマークを付けることによってuserApplicationの切替えをすべて禁止しています。正確な定義は以下のとおりです。
実際にはOffline状態、Standby状態またはFaulted状態にあるuserApplicationにInconsistent状態のマークが付けられ、かつ、そのグラフ内で1つ以上のオブジェクトがOnline状態またはFaulted状態にあり、そのオブジェクトのClusterExclusive属性が1に設定されている。
userApplicationは、Inconsistentの状態にあると表示または報告されますが、実際の状態は、Offline、StandbyまたはFaultedです。ほとんどの処理においては、Inconsistent状態にあるuserApplicationの動作は、実際の状態に基づいて決定されます。たとえば、実際の状態がOfflineの場合には、Offline要求が発行されてもOfflineスクリプトは起動されません ("2.1.4.5 グラフノードがすでにOffline状態である場合"を参照してください)。
例外は不整合のuserApplicationをリモートノードに切替える要求が発行された場合で、この要求は拒否されます。これによって、ClusterExclusiveリソースが、一度に1つのノードでのみOnlineになることが確保され、障害が発生する可能性が回避されます。
あるuserApplicationが、1つのノードでのみInconsistent状態にある場合は、そのノード上でOnline状態にすることは可能です。ただし、複数のノードでInconsistent状態が生じていると切替えはできません。この場合、たとえば、hvutil -fまたはhvutil -cによって、すべてのリソースをOffline状態にするなどして、まずInconsistent状態を解決する必要があります。
userApplicationが複数のノードでInconsistent状態にある場合、ClusterExclusiveリソースのいずれかが、複数のノードでOnline状態にある可能性があります。この場合には、userApplicationに対してhvutilコマンドを実行する前に、各ノードでリソースを正常終了させるための適切な処理を行ってください。リソースのタイプによっては、データの破損が生じていないかを確認する必要があります。
