PRIMECLUSTER 活用ガイド ＜クラスタ構築・運用時の留意点＞ （Solaris(TM)オペレーティングシステム／Linux版）
目次 索引 前ページ次ページ
第1部 設計・構築編> 第2章 クラスタアプリケーションの設定内容および注意点> 2.1 Solaris/Linux 共通の説明

2.1.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 属性を "1(yes)" に設定してください。
 

● スケーラブル型のクラスタアプリケーションにおいて、状態遷移時に 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 数を考慮した値を算出します。

1) の値そのものが SysNode 数を考慮した値になります。
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 RMS management menu" の "Application-Create" を選択します。

    sweetpea: Main configuration menu, current configuration: aaa
    No RMS active in the cluster
    1) HELP　　　 　　　　　　　　　　　　　10) Configuration-Remove
    2) QUIT　　　　　　　　　　　　　　　　　11) Configuration-Freeze
    3) Application-Create　　　　　　　　12) Configuration-Thaw
    4) Application-Edit　　　　　　　　　　13) Configuration-Edit-Global-Settings
    5) Application-Remove　　　　　 　　14) Configuration-Consistency-Report
    6) Application-Clone　　 　　　 　　　15) Configuration-ScriptExecution
    7) Configuration-Generate　　　　　16) RMS-CreateMachine
    8) Configuration-Activate　　 　　　17) RMS-RemoveMachine
    9) Configuration-Copy
    Choose an action: 3

     

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

    Edit: Application selection menu (restricted):
    1) HELP
    2) QUIT
    3) RETURN
    4) OPTIONS
    5) APP1
    6) Cmd_APP1
    7) Controller
    8) app1
    Application Name: 7

     

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

    Settings of application type "Controller" (consistent)
    1) HELP
    2) NO-SAVE+EXIT
    3) SAVE+EXIT
    4) ApplicationName=Controller
    5) ControlPolicy=SCALABLE
    6) AdditionalAppToControl
    7) Controllers[0]=T180:app1
    8) (FaultScript=)
    9) (ApplicationSequence=)
    10) (StateChangeScript=)
    Choose the setting to process: 7

     

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

    1) HELP
    2) RETURN
    3) NONE
    4) FREECHOICE
    5) SELECTED:app1
    Set the application to control: 5

     

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

    Set *global* flags for all scalable (sub) applications: app1
    Currently set: TIMEOUT (T180)
    1) HELP
    2) -
    3) SAVE+RETURN
    4) DEFAULT
    5) MONITORONLY(M)
    6) TIMEOUT(T)
    Choose one of the flags: 6

     

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

    1) HELP
    2) RETURN
    3) FREECHOICE
    4) 180
    Set an appropriate timeout: 3
    　　　　>> 2340

     

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

    Set *global* flags for all scalable (sub) applications: app1
    Currently set: TIMEOUT (T2340)
    1) HELP
    2) -
    3) SAVE+RETURN
    4) DEFAULT
    5) MONITORONLY(M)
    6) TIMEOUT(T)
    Choose one of the flags: 3

     

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

    Settings of application type "Controller" (consistent)
    1) HELP
    2) NO-SAVE+EXIT
    3) SAVE+EXIT
    4) ApplicationName=Controller
    5) ControlPolicy=SCALABLE
    6) AdditionalAppToControl
    7) Controllers[0]=T2340:app1
    8) (FaultScript=)
    9) (ApplicationSequence=)
    10) (StateChangeScript=)
    Choose the setting to process: 3

RMS Wizard および属性の変更の詳しい操作については、"PRIMECLUSTER 導入運用手引書" または "PRIMECLUSTER RMS 導入運用手引書" を参照してください。
 

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

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

◆ 設定手順

運用系： 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

    　

  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. PRIMECLUSTER(RMS) を起動してください。

     node1# hvcm -a

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

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

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

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

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

アプリケーションの判断で上記の強制停止を制御することも可能ですが、その場合には複数のクライアントから判断する必要があります。すなわち、１つのクライアントから異常に見えても、実際にはクライアント内やネットワーク上に異常があるケースも考えられます。アプリケーションではこのようなケースも考慮して制御する必要があります。
目次 索引 前ページ次ページ
All Rights Reserved, Copyright(C) 富士通株式会社 2009