以下の操作を行ってください。
→ AutoSwitchOver = HostFailure | ResourceFailure | Shutdown
HaltFlag に "No" が設定されている場合には、二重故障が発生してもフェイルオーバは行われません。HaltFlag に "Yes" を設定することにより、二重故障が発生した場合にシャットダウン機構による故障ノードの強制停止（PANIC、 電源断、reboot）が実行され、フェイルオーバが行われます。
注意
AutoSwitchOver 属性を設定していても、二重故障発生時は HaltFlag が設定されていないとフェイルオーバは行われません。
ノード故障、リソース故障、RMS 停止時に userApplication をフェイルオーバさせたい
以下の操作を行ってください。
→ AutoSwitchOver = HostFailure | ResourceFailure | Shutdown
注意
二重故障発生時は、本属性値を設定していてもフェイルオーバは行われません。
二重故障発生時にもフェイルオーバを行う場合は、HaltFlag 属性も設定してください。
切替え先の userApplication が Fault 状態の場合、AutoSwitchOver属性を設定していても切替えは行われません。
フェイルオーバを行う場合、Fault 状態をクリアしてください。
RMS起動時に userApplication を自動起動させたい
以下の操作を行ってください。
→ AutoStartUp = Yes
AutoStartUp 属性が "Yes" に設定されている場合、クラスタアプリケーションは RMS 起動時に自動で Online 状態に遷移します。
RMS起動時、userApplicationの切替え時、またはuserApplicationの故障クリア時に userApplication を自動でStandby状態にしたい
以下の操作を行ってください。
→ StandbyTransitions = Startup | SwitchRequest | ClearFaultRequest
注意
AutoStartUp 属性が "Yes" に設定されている場合、待機系のクラスタアプリケーションは StandbyTransitions の 設定値に関係なく、RMS起動時に自動で Standby 状態に遷移します。
AutoStartUP と StandbyTransitions の関係を下表に示します。
RMS 起動ノード | AutoStartUp=Yes | AutoStartUp=No | |||
|---|---|---|---|---|---|
StandbyTransitions | StandbyTransitions | ||||
No | StartUP | No | StartUP | ||
複数ノード | 運用側 uap | Online | Online | Offline | Standby |
待機側 uap | Standby | Standby | Offline | Standby | |
片ノードのみ | Standby | Standby | Offline | Standby | |
StandbyCapable属性に"yes"(1) が設定されたリソースがuserApplication 配下に存在しない場合、StandbyTransitions属性の設定値に関わらず、そのuserApplication はStandby状態になりません。
スケーラブル型のクラスタアプリケーションにおいて、状態遷移時に Controller リソースのタイムアウトが発生しないようにしたい
スケーラブルを構成するクラスタアプリケーションの起動・停止に時間を要する場合、状態遷移時に Controller リソース（スケーラブルを示すリソース）でタイムアウトのエラーが発生し、状態遷移が異常終了する場合があります。
この場合は、スケーラブルを構成する各クラスタアプリケーションの起動停止の時間に応じて、Controller リソースの設定を変更する必要があります。
以下の手順で、スケーラブル型のクラスタアプリケーションの Timeout 値を算出し、設定します。
クラスタアプリケーションの最大状態遷移時間を算出する
Controller リソースは、配下の userApplication がすべて Online である場合に、Online 状態へと遷移します。そのため、クラスタアプリケーションを構成する各リソースの ScriptTimeout の合計値を算出します。
例えばクラスタアプリケーション配下に Cmdline リソース、Fsystem リソース、Gds リソース、Gls リソースが各 1つ存在する場合、以下のように算出できます。（ここでは、各リソースのタイムアウト値はデフォルトのままとします。）
Cmdline リソース 300（秒）+ Fsystem リソース 180（秒）+ Gds リソース 1800（秒）+ Gls リソース 60（秒）= 2340（秒）
この値はスケーラブル型のクラスタアプリケーションのデフォルト値 180（秒）より大きいので設定値を 2340（秒）にします。
参考
各リソースのデフォルトのスクリプトタイムアウト値
Cmdline : 300
Fsystem : 180
GDS : 1800
Gls : 60
SysNode 数を考慮する
クラスタアプリケーションを構成する SysNode 数を考慮した値を算出します。
1. の値そのものが SysNode 数を考慮した値になります。
1. で算出した値に、SysNode 数から 1 を引いた値を 2 倍し、掛け合わせます。
複数ノード間でのクラスタアプリケーションの最大状態遷移時間＝ "1) の値" × 2 ( "SysNode数" -1 )
例
例えば、userApplication が 3 ノード構成、Node1 上で Online 状態、タイムアウト間際で Online/Offline 処理が終了すると想定した場合、userApplication が最初のノードで状態遷移を開始後、最後のノードで Online となるまで、以下のように 4 倍（2 × ( "SysNode数" - 1 )）の状態遷移時間を要することになります。
Node1 で Offline 処理
Node2 で Online 処理
Node2 で Offline 処理
Node3 で Online 処理
各クラスタアプリケーションの 2. の合計値を算出する
3で算出した値をController リソースのタイムアウト値に設定する。
“PRIMECLUSTER RMS 導入運用手引書” の “5.2 コントローラのタイムアウト時間を変更” を参照し、Controller リソースのタイムアウト値を変更してください。
ハートビートで異常を検出した場合、運用系・待機系が相互に強制停止を行い全系ダウンにならないよう、強制停止を行うノードの生存優先度の設定をしています。運用系を優先的に停止し、調査資料を採取するための手順を以下に説明します。
注意
シャットダウン機構で設定する重み付けは、ノードに定義するものです。
フェイルオーバや切替え操作により、運用系と待機系が初期設定時とは反転している状態では、本設定変更しても有効になりません。従来と同じように、待機系で一定の待ち時間経過後に強制停止させます。
クラスタの切替えが発生した場合には、必ず切戻しをしてください。
システムのパニックやCPU 負荷、I/O 負荷が続いた場合、ハートビート異常とみえることがあります。このようなときは、生存優先度にかかわらず、異常が発生しているクラスタノードが強制停止されます。
生存優先度の低い待機系は運用系の強制停止処理が完了するまでの時間を待ちます。この待ち時間の間にハートビートが復旧すると、ハートビート異常の原因を調査するために有効な資料が採取できない場合があります。
このような状態は、運用系で CPU 負荷や I/O 負荷が一時的に高くなった場合に発生することがあります。
運用系： node1、待機系： node2 とした場合の設定例は以下のとおりです。
注意
手順 1.～4. の設定を運用系、待機系の両方で実施してください。
待機系（node2）の SF の設定（/etc/opt/SMAW/SMAWsf/rcsd.cfg）を vi エディタなどで修正し、待機系のノードの重み付けを高くします。node2 の weight 属性の値を、"1" から "2" に変更します。
node2# vi /etc/opt/SMAW/SMAWsf/rcsd.cfg
[変更前]
node1,weight=1,admIP=x.x.x.x:agent=SA_xx,timeout=20:agent=SA_yy:timeout=20 node2,weight=1,admIP=x.x.x.x:agent=SA_xx,timeout=20:agent=SA_yy:timeout=20
[変更後]
node1,weight=1,admIP=x.x.x.x:agent=SA_xx,timeout=20:agent=SA_yy:timeout=20 node2,weight=2,admIP=x.x.x.x:agent=SA_xx,timeout=20:agent=SA_yy:timeout=20
注意
rcsd.cfg ファイル内では 1 ノードの設定を 1 行で記述してください。
PRIMECLUSTER のバージョンにより、admIP の記述がない場合があります。
SF を sdtool -r コマンドで再起動します。
sdtool -r の実行には 5 秒程度かかります。この操作により、変更した SF の設定が SF に反映されます。
node2# sdtool -r
変更した SF の設定が SF に反映されたことを sdtool -C コマンドで確認します。
node2 の weight 属性の値が "2" になっていることを確認してください。
node2# sdtool -C
Cluster Host Type Weight Admin IP Agent List (Agent:timeout)
------------ ----- ------ -------- --------------------------
node1 CORE 1 x.x.x.x SA_xx:20,SA_yy:20
node2 CORE 2 x.x.x.x SA_xx:20,SA_yy:20
注意
PRIMECLUSTER のバージョンにより、"Type" は表示されない場合があります。
SF に定義されているすべての SA が正しく動作していることを sdtool -s コマンドで確認します。"Test State" が "TestWorked" に、"Init State" が "InitWorked" になっていることを確認してください。
node2# sdtool -s
Cluster Host Agent SA State Shut State Test State Init State
------------ ----- -------- ---------- ---------- ----------
node1 SA_xx Idle Unknown TestWorked InitWorked
node1 SA_yy Idle Unknown TestWorked InitWorked
node2 SA_xx Idle Unknown TestWorked InitWorked
node2 SA_yy Idle Unknown TestWorked InitWorked注意
以下の手順 5.～8. の設定は、運用系または待機のどちらか一方だけで実施してください。
クラスタアプリケーション（userApplication）の ShutdownPriority 属性値を確認してください。hvutil -W で確認できます。
ShutdownPriority 属性値が "0" 以外の場合、手順 6.～8. を実施してください。
"0" の場合は、これで設定は完了です。
node1# hvutil -W
4PRIMECLUSTER(RMS) を停止してください。
注意
PRIMECLUSTER(RMS) を停止させると業務も停止します。
node1# hvshut -aクラスタアプリケーション（userApplication）の ShutdownPriority 属性値を "NONE" に変更してください。
"Global Cluster Services" 画面で、<userApplication Configuration Wizard＞を選択します。
"userApplication Configuration Wizard" 画面の左のツリーから、変更したい userApplication を選択し、マウスの右ボタンをクリックして表示されるポップアップメニューで [userApplication や Resource の変更] を選択します。
"ShutdownPriority" を選択し、"NONE" にします。
属性変更後、<登録>ボタンをクリックし、RMS Configuration に登録します。
"0817 RMS Configuration 情報の配布を行いますか？" で「はい」をクリックします。
参照
詳細は、“11.1 クラスタアプリケーションの運用属性の変更”を参照してください。
PRIMECLUSTER(RMS) を起動してください。
node1# hvcm -a注意
クラスタの切替えが発生した場合には、必ず切戻しをしてください。
サブシステムハング時、運用系ノードを強制停止したい
運用ノード内の一部の I/O だけが異常になっているために、業務が停止しているが、その他の I/O は正常であるため、クラスタがその事象を検知していない場合（クラスタ監視からは正常に見えている場合）を、サブシステムハングと呼びます。
この場合、待機ノードに切替えれば業務再開の見込みがあります。サブシステムハングの場合、ping では正常に見えたり、ノードへのログイン操作が可能なこともあります。
サブシステムハングを検出した場合は、以下の方法で運用ノードを停止し業務を切替えてください。
待機ノードにログインできる場合
sdtool コマンドを使用して待機ノードから運用ノードを停止させます。
# sdtool -k node-name
node-name : 運用ノードの CF ノード名sdtool -kで運用ノードの強制停止に失敗した場合は、「いずれのノードにもログインできない場合」の対処を実施してください。
参照
sdtoolコマンドの詳細は、“PRIMECLUSTER 活用ガイド＜コマンドリファレンス編＞”の sdtool(1M) を参照してください。
いずれのノードにもログインできない場合
運用ノードを以下の方法により、手動で強制停止してください。
物理環境または制御ドメインを強制停止する場合
本体装置の取扱説明書を参照してください。
ゲストドメインを強制停止する場合
制御ドメインで ldm panic-domain コマンドなどを使用してください。
# ldm panic-domain <強制停止するゲストドメイン名>
カーネルゾーンを強制停止する場合
グローバルゾーンで zoneadm halt コマンドなどを使用してください。
# zoneadm -z <強制停止するカーネルゾーン名> halt
注意
アプリケーションの判断で上記の強制停止を制御することも可能ですが、その場合には複数のクライアントから判断する必要があります。すなわち、１つのクライアントから異常に見えても、実際にはクライアント内やネットワーク上に異常があるケースも考えられます。アプリケーションではこのようなケースも考慮して制御する必要があります。
LAN の伝送路に異常が発生した場合、フェイルオーバさせたい
PingHost は設定したホストと応答確認（ping）を行うために必要な情報です。ハブやルータの故障に影響されないために、クラスタシステムとして構成されていないノードを 2つ以上設定してください。
PingHost を設定していない場合、LANの伝送路に異常が発生してもリソース異常とはならず、切替えも発生しません。
PingHost の設定の有無にかかわらず、引継ぎ IP アドレスのインタフェースが UP 状態でなくなった、またはリンクダウンを検出した場合にリソース異常となり切替えが発生します。
PreCheck スクリプトをクラスタアプリケーションに設定したい
PreCheck スクリプトをクラスタアプリケーションに設定する手順については、“PRIMECLUSTER RMS 導入運用手引書”の“5.1 クラスタアプリケーションに PreCheckScript を設定”を参照してください。