ページの先頭行へ戻る
PRIMECLUSTER  導入運用手引書 4.3
FUJITSU Software

6.10.1 クラスタアプリケーションの設定内容

二重故障発生時にフェイルオーバさせたい

以下の操作を行ってください。

→  HaltFlag = 1 (yes)

→  AutoSwitchOver = HostFailure | ResourceFailure | Shutdown

HaltFlag に "No" が設定されている場合には、二重故障が発生してもフェイルオーバは行われません。HaltFlag に "Yes" を設定することにより、二重故障が発生した場合にシャットダウン機構による故障ノードの強制停止(PANIC、 電源断、reboot)が実行され、フェイルオーバが行われます。

注意

AutoSwitchOver 属性を設定していても、二重故障発生時は HaltFlag が設定されていないとフェイルオーバは行われません。

ノード故障、リソース故障、RMS 停止時に userApplication をフェイルオーバさせたい

以下の操作を行ってください。

→  AutoSwitchOver = HostFailure | ResourceFailure | Shutdown

注意

  1. 二重故障発生時は、本属性値を設定していてもフェイルオーバは行われません。
    二重故障発生時にもフェイルオーバを行う場合は、HaltFlag 属性も設定してください。

  2. 切替え先の userApplication が Fault 状態の場合、HostFailure, Shutdown を設定していてホスト故障やシャットダウンが発生しても切替えは行われません。
    リソース故障時にフェイルオーバを行う場合、Fault 状態をクリアしてください。

立上げ、切替え、故障クリア時に userApplication を自動起動させたい

以下の操作を行ってください。

→  AutoStartUp = 1 (yes)

→  StandbyTransitions = Startup | SwitchRequest | ClearFaultRequest

AutoStarUp 属性が "Yes" に設定されている場合は、クラスタアプリケーションは RMS 起動時に自動で Online 状態に遷移します。また、待機系は StandbyTransitions の Startup 属性に関係なく Standby 状態に遷移します。

一方、AutoStartUp 属性が "No" に設定されている場合の状態遷移は StandbyTransitions 属性にしたがいます。

AutoStartUP と StandbyTransition の関係を下表に示します。

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

注意

クラスタアプリケーションが Faulted 状態であった後のノード再起動時に、Faulted 状態を解除し待機状態で正常に起動したい場合は、PersistentFault 属性を "0(no)" に設定してください。

スケーラブル型のクラスタアプリケーションにおいて、状態遷移時に Controller リソースのタイムアウトが発生しないようにしたい

スケーラブルを構成するクラスタアプリケーションの起動・停止に時間を要する場合、状態遷移時に Controller リソース(スケーラブルを示すリソース)でタイムアウトのエラーが発生し、状態遷移が異常終了する場合があります。

この場合は、スケーラブルを構成する各クラスタアプリケーションの起動停止の時間に応じて、Controller リソースの設定を変更する必要があります。

以下の手順で、スケーラブル型のクラスタアプリケーションの Timeout 値を算出し、設定します。

設定手順
  1. クラスタアプリケーションの最大状態遷移時間を算出する

    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
  2. SysNode 数を考慮する

    クラスタアプリケーションを構成する SysNode 数を考慮した値を算出します。

    SysNode 数が 1 の場合

    1. の値そのものが SysNode 数を考慮した値になります。

    SysNode 数が 2 以上の場合

    1. で算出した値に、SysNode 数から 1 を引いた値を 2 倍し、掛け合わせます。

    複数ノード間でのクラスタアプリケーションの最大状態遷移時間
    = "1) の値" x 2 ( "SysNode数" -1 )

    例えば、userApplication が 3 ノード構成、Node1 上で Online 状態、タイムアウト間際で Online/Offline 処理が終了すると想定した場合、userApplication が最初のノードで状態遷移を開始後、最後のノードで Online となるまで、以下のように 4 倍(2 x ( "SysNode数" - 1 ))の状態遷移時間を要することになります。

    1. Node1 で Offline 処理

    2. Node2 で Online 処理

    3. Node2 で Offline 処理

    4. Node3 で Online 処理

  3. 各クラスタアプリケーションの 2. の合計値を算出する

  4. hvw コマンドで設定を変更する

    以下の手順で設定してください。

    1. hvw コマンドで RMS Wizard を起動します。

    2. "Main configuration menu" の "Application-Create" を選択します。

    3. "Application selection menu" の "Controller" を選択します。

    4. "Settings of application type" の "Controllers" を選択します。

    5. "SELECTED" を選択します。

    6. "Set *global* flags for all scalable (sub) applications" の "TIMEOUT(T)" を選択します。

    7. "FREECHOICE" を選択し、設定値(2340 を入力した場合)を入力します。

    8. "Set *global* flags for all scalable (sub) applications" の "SAVE+RETURN" を選択します。

    9. "Settings of application type" の "SAVE+EXIT" を選択します。

    参照

    RMS Wizard および属性の変更の詳しい操作については、"8.1 クラスタアプリケーションの変更"または"PRIMECLUSTER RMS 導入運用手引書"を参照してください。

ハートビート異常発生時、運用系を優先的に停止したい

ハートビートで異常を検出した場合、運用系・待機系が相互に強制停止を行い全系ダウンにならないよう、強制停止を行うノードの生存優先度の設定をしています。運用系を優先的に停止し、調査資料を採取するための手順を以下に説明します。

注意

  • シャットダウン機構で設定する重み付けは、ノードに定義するものです。
    フェイルオーバや切替え操作により、運用系と待機系が初期設定時とは反転している状態では、本設定変更しても有効になりません。従来と同じように、待機系で一定の待ち時間経過後に強制停止させます。
    クラスタの切替えが発生した場合には、必ず切戻しをしてください。

  • システムのパニックやCPU 負荷、I/O 負荷が続いた場合、ハートビート異常とみえることがあります。このようなときは、生存優先度にかかわらず、異常が発生しているクラスタノードが強制停止されます。

  • 生存優先度の低い待機系は運用系の強制停止処理が完了するまでの時間を待ちます。この待ち時間の間にハートビートが復旧すると、ハートビート異常の原因を調査するために有効な資料が採取できない場合があります。
    このような状態は、運用系で CPU 負荷や I/O 負荷が一時的に高くなった場合に発生することがあります。

設定手順

運用系: node1、待機系: node2 とした場合の設定例は以下のとおりです。

注意

手順 1.~4. の設定を運用系、待機系の両方で実施してください。

  1. 待機系(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 の記述がない場合があります。

  2. SF を sdtool -r コマンドで再起動します。

    sdtool -r の実行には 5 秒程度かかります。この操作により、変更した SF の設定が SF に反映されます。

    node2# sdtool -r
  3. 変更した 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" は表示されない場合があります。

  4. 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. の設定は、運用系または待機のどちらか一方だけで実施してください。

  5. クラスタアプリケーション(userApplication)の ShutdownPriority 属性値を確認してください。hvutil -W で確認できます。

    ShutdownPriority 属性値が "0" 以外の場合、手順 6.~9. を実施してください。

    "0" の場合は、これで設定は完了です。

    node1# hvutil -W
    4
  6. PRIMECLUSTER(RMS) を停止してください。

    注意

    PRIMECLUSTER(RMS) を停止させると業務も停止することに留意してください。

    node1# hvshut -a
  7. クラスタアプリケーション(userApplication)の ShutdownPriority 属性値を "0" に変更してください。まず、RMS Wizard を起動します。

    node1# /opt/SMAW/SMAWRrms/bin/hvw -n testconf

    注意

    testconf は環境に応じて変更してください。

    詳細は、“8.5 userApplicationの運用属性の変更”を参照してください。

    1. "Main configuration menu" の "Application-Edit" を選択します。

    2. "Application selection menu" で構成変更を行うクラスタアプリケーション(userApplication)を選択します。

    3. "turnkey wizard" で "Machines+Basics" を選択します。

    4. "ShutdownPriority" を選択します。

    5. "FREECHOICE" を選択し、0 を入力します。

    6. "Machines+Basics" で "SAVE+EXIT" を選択します。

    7. "turnkey wizard" で "SAVE+EXIT" を選択します。

    8. "Application selection menu" で "RETURN" を選択します。

    9. "Configuration-Generate" を選択します。

    10. "Configuration-Activate" を選択します。

  8. PRIMECLUSTER(RMS) を起動してください。

    node1# hvcm -a

    注意

    クラスタの切替えが発生した場合には、必ず切戻しをしてください。

サブシステムハング時、運用系ノードを強制停止したい

運用ノード内の一部の I/O だけが異常になっているために、業務が停止しているが、その他の I/O は正常であるため、クラスタがその事象を検知していない場合(クラスタ監視からは正常に見えている場合)を、サブシステムハングと呼びます。

この場合、待機ノードに切替えれば業務再開の見込みがあります。サブシステムハングの場合、ping では正常に見えたり、ノードへのログイン操作が可能なこともあります。

サブシステムハングを検出した場合は、以下の方法で運用ノードを停止し業務を切替えてください。

待機ノードにログインできる場合

sdtool コマンドを使用して待機ノードから運用ノードを停止させます。

# sdtool -k node-name
  node-name : 運用ノードの CF ノード名
いずれのノードにもログインできない場合
[PRIMERGY の場合]

本体装置の NMI スイッチ、あるいはキー操作により運用ノードをパニックさせてください。

[PRIMEQUEST の場合]

Web-UI を使用して運用ノードのダンプを採取し、停止させてください。

注意

アプリケーションの判断で上記の強制停止を制御することも可能ですが、その場合には複数のクライアントから判断する必要があります。すなわち、1つのクライアントから異常に見えても、実際にはクライアント内やネットワーク上に異常があるケースも考えられます。アプリケーションではこのようなケースも考慮して制御する必要があります。