VERITAS ClusterServer

2007/9/1更新

対応バージョン: 2

attributesは参照のみ可能な値と変更可能な値の2種類がある。

参照のみ可能な値に変更を加えようとすると上記のエラーメッセージが出力され変更することができない。

今回変更しようとしたリソースのattributesのArgListValuesは参照のみ可能な値である。

ArgListValuesは各システムでのエージェントに引き渡される引数の値を表示するものであり、この値に変更を加えることはできない。

引数の値を変更する場合にはリソースのattributesである引数を直接変更する。

FileOnOffエージェントを例にして説明すると、FileOnOffエージェントのタイプattributesのArgListにはPathNameが設定されている。

この時リソースattributesのArgListValuesにはPathNameの内容を表示しているがこのPathNameの内容を変更する為にはリソースattributesのPathNameの値を変更する必要がある。

PathNameの値を変更するとArgListValuesも変更されることになる。

2007/9/1更新

対応バージョン: 2

MultiNICAエージェントはNICの生存確認のためにNetworkHosts属性で指定したホストにpingを送るが、何らかの理由でこのホストが応答しない場合は代わりにブロードキャストアドレスにpingを送ってNICの生存確認を行う。

2007/9/1更新

対応バージョン: 2

同エージェントのNetworkHosts属性の値を確認する。

同属性が未設定の場合エージェントは該当NICの生存確認を行なうためにブロードキャストアドレスにpingパケットを送るが、ケーブルが抜かれているので別ホストからのreplyはないものの自身のNICからのreplyがあるためNICは正常動作しているとみなされて別NICに切り替わらない。

この属性にIPアドレスを設定することでpingの送出先をブロードキャストアドレスから指定したアドレスに変更でき、例えばこのIPアドレスを接続先のスイッチ等のIPアドレスに設定しておけば、ケーブルが抜けた時にpingのreplyがなくなって別NICに切り替わる。

このIPアドレスは複数指定でき、その場合は指定した複数のIPアドレスのうち最低1つのIPアドレスからreplyがあればよい。

ここでは例として以下の構成の場合の設定手順、及びNIC切替時のログを示す。

  (現用系)                            (待機系)
+----------+                        +----------+
|L2スイッチ|                        |L2スイッチ|
+----+-----+                        +-----+----+
     |172.20.61.185          172.20.61.186|
     |                                    |
     |qfe1 <--- 172.20.61.140/26 ---> qfe2|
+----+------------------------------------+-----+
|                   Sunサーバ                   |
|                                               |
| ・ホスト名                : host_a            |
| ・VCSシステム名           : sysa              |
| ・MultiNICAエージェント名 : sysa_MNIC         |
+-----------------------------------------------+

設定手順

# haconf -makerw

# hares -modify sysa_MNIC NetworkHosts {"172.20.61.185","172.20.61.186"}

# hares -display sysa_MNIC
#Resource  Attribute     System  Value
:
sysa_MNIC  NetworkHosts  global  172.20.61.185 172.20.61.186
:

# haconf -dump -makero

NIC切替時のログ(qfe1→qfe2)

/var/adm/messages

qfe1のリンクダウン後数秒後にカーネルが検知

NOTICE: SUNW,qfe1: No response from Ethernet network : Link Down - cable problem?
/var/VRTSvcs/log/engine_A.log
MultiNICA:sysa_MNIC:monitor: Device qfe1 FAILED ← (1)
MultiNICA:sysa_MNIC:monitor: Accquired a WRITE Lock ← (2)
MultiNICA:sysa_MNIC:monitor: Bringing down IP addresses ← (3)
MultiNICA:sysa_MNIC:monitor: Trying to online Device qfe2 ← (4)
MultiNICA:sysa_MNIC:monitor: Sleeping 5 seconds
MultiNICA:sysa_MNIC:monitor: Pinging 172.20.61.185 with Device qfe2 configured: iteration 1 ← (5)
MultiNICA:sysa_MNIC:monitor: Sleeping 5 seconds
MultiNICA:sysa_MNIC:monitor: Pinging Broadcast address 172.20.61.191 on Device qfe2, iteration 2 ← (6)
MultiNICA:sysa_MNIC:monitor: Migrated to Device qfe2 ← (7)
MultiNICA:sysa_MNIC:monitor: Releasing Lock ← (8)

(1) カーネルがqfe1のリンクダウンを検知後、概ね1〜2分後にMultiNICAエージェントも同リンクダウンを検知

(2) リソースに対する書き込みロックを獲得

(3) qfe1に割り当てていたIPアドレスを剥奪

(4) qfe2をオンラインにする

(5) qfe2を使ってスイッチにpingを投げる

(6) qfe2を使ってブロードキャストアドレスにpingを投げる

(7) NICをqfe2に切り替える

(8) (2)で獲得していたロックを開放する

2007/9/1更新

対応バージョン: 2

標準で用意されているNFSリソースはタイプがOnOnlyになっているのでそのままでは別のリソースとの接続ができない。

そこでNFSサーバの起動スクリプト(/etc/init.d/nfs.server)を変更し、OSブート時にはNFSのサーバ群「だけ」を起動するようにし、ShareについてはVCSのShareタイプを使って管理するようにする。

以下に作業手順を示す。

通常(OS標準)のShareシーケンス停止

# /usr/sbin/unshareall -F nfs
/etc/dfs/dfstabからShare部分をコメントアウト
NFSサーバの起動スクリプト変更
# cd /etc/init.d
# cp -p nfs.server nfs.server.org (*)

(*) 上記作業はmvではなくcpにする。これは以下のファイルがnfs.serverにハードリンクしているため、mvすると新しいnfs.serverのiノード番号が変わってしまい、リンクを張り直す必要がでてきてしまうからである。

/etc/rc0.d/K28nfs.server
/etc/rc1.d/K28nfs.server
/etc/rc2.d/K28nfs.server
/etc/rc3.d/S15nfs.server
/etc/rcS.d/K28nfs.server
/etc/dfs/dfstab内にnfsタイプのShareが指定されていなくてもNFSサーバ関連デーモン(mountd,nfsd)が起動するように同デーモン起動スイッチを最初から1(ON)にしておく
# vi nfs.server
:
  35          startnfsd=0 ← 0を1にする
:

VCSエージェント作成

ShareをVCS管理下で行なうためのVCSエージェントを作成する。

エージェントの設定はクラスタメンバの1つのマシン上で行なえばよい。

ここでは例として以下のようなShareエージェントを作成するものとして説明する。

システム

sysa,sysb

メンバグループ

grpa,grpb

リソース名

grpa_Share_ap (grpaに所属)

依存リソース

grpa_Mount_ap

Shareポイント

/opt/ap

Shareオプション

rw(Read Write)

host_aとhost_bからのrootの書き込み可

リソース定義モード変更(書き込み不可 → 可)

# haconf -makerw

リソース定義

# hares -add grpa_Share_ap Share grpa
# hares -modify grpa_Share_ap Critical 0 (*)

(*) 通常運用ではこの値を1(ON)にする。1にするとこのリソースにエラーが発生したり手動でオフラインにした場合に他のリソースを含めて全体がフェールオーバするのでテスト時には0にしておいてこのリソース単体の試験等によって全体がフェールオーバするのを防ぐ。

# hares -modify grpa_Share_ap PathName "/opt/ap"
# hares -modify grpa_Share_ap Options "rw,root=host_a:host_b"
# hares -link grpa_Share_ap grpa_Mount_ap

リソース有効化 & online

# hares -modify grpa_Share_ap Enabled 1
# hares -online grpa_Share_ap -sys sysa

リソース状況チェック

# hares -display grpa_Share_ap
#Resource     Attribute       System     Value
grpa_Share_ap Group           global     sysa 
grpa_Share_ap Type            global     Share
grpa_Share_ap AutoStart       global     1    
grpa_Share_ap Critical        global     0    
grpa_Share_ap Enabled         global     1    
grpa_Share_ap LastOnline      global     sysa 
grpa_Share_ap MonitorOnly     global     0    
grpa_Share_ap ResourceOwner   global     unknown
grpa_Share_ap TriggerEvent    global     0    
grpa_Share_ap ArgListValues   sysa       /opt/ap ""
grpa_Share_ap ArgListValues   sysb       /opt/ap ""
grpa_Share_ap ConfidenceLevel sysa       100
grpa_Share_ap ConfidenceLevel sysb       0
grpa_Share_ap Flags           sysa     
grpa_Share_ap Flags           sysb     
grpa_Share_ap IState          sysa       not waiting
grpa_Share_ap IState          sysb       not waiting
grpa_Share_ap Probed          sysa       1
grpa_Share_ap Probed          sysb       1
grpa_Share_ap Start           sysa       1
grpa_Share_ap Start           sysb       0
grpa_Share_ap State           sysa       ONLINE
grpa_Share_ap State           sysb       OFFLINE
grpa_Share_ap Options         global     rw,root=host_a:host_b
grpa_Share_ap PathName        global     /opt/ap

確認

# share
-     /opt/ap   rw,root=host_a:host_b   ""

フェールオーバ確認

# hagrp -switch grpa -to sysb

この段階でsysb上でshareが正しく行われていることを確認し、問題なければフェールバックする。

# hagrp -switch grpa -to sysa

リソース設定変更

リソース定義時に0に設定していたCriticalフラグを必要に応じて1(フェールオーバ対象)に設定する。

hares -modify grpa_Share_ap Critical 1

リソース定義モード変更(書き込み可 → 不可)

# haconf -dump -makero

このようにNFSサーバとShareの関連性を切ることによってフェールオーバ時にもNFSのサーバ群には影響を与えずにUnshare/ShareがVCSの管理下で行える。

2007/9/1更新

対応バージョン: 2

lltstatを使用する。

例) sys_a,sys_bという2つのノードで構成されているクラスタでリンクが2つある場合

# /sbin/lltstat -n 
LLT node information:
   Node      State  Links
  * 0 sys_a  OPEN     2   ← lltstatを実行したノードに*印が付く。
    1 sys_b  OPEN     2

また、verboseオプションをつけるとさらに詳細な情報を得られる。

# /sbin/lltstat -nvv
LLT node information:
   Node      State    Link  Status  Address
  * 0 sys_a  OPEN
                      hme:0   UP      08:00:20:E7:34:A0
                      qfe:0   UP      08:00:20:E7:34:A0
    1 sys_b  OPEN
                      hme:0   UP      08:00:20:F0:2F:0A
                      qfe:0   UP      08:00:20:F0:2F:0A
    2        CONNWAIT
                      hme:0   DOWN
                      qfe:0   DOWN
    3        CONNWAIT
                      hme:0   DOWN
                      qfe:0   DOWN

LLTに接続しているポートに関する情報を取得するには-pオプションを使用する。

例) 2つのシステム(0と1)が接続されている場合。

# /sbin/lltstat -p
LLT port information:
  Port  Usage   Cookie
    0   gab     0x0
      opens:    0 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
      connects: 0 1

    7   gab     0x7
      opens:    0 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
      connects: 0 1

   31   gab     0x1F
      opens:    0 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
      connects: 0 1

2007/9/19更新

対応バージョン: 2

/etc/llthosts、/etc/llttabにて行う。

例) sys_a,sys_bという2つのノードで構成されているクラスタの場合

# cat /etc/llthosts
0 sys_a
1 sys_b

# cat /etc/llttab
set-node sys_a ← 現在ホストのノード名
set-cluster 2 ← クラスタメンバ数
link hme:0 /dev/hme:0 - ether - - ←ハートビートライン1
link qfe:0 /dev/qfe:0 - ether - - ←ハートビートライン2
start

2007/9/1更新

対応バージョン: 2

ハートビートラインはTCP/IPを使わずにVCS専用プロトコルであるLLT(Low Latency Transport)/GAB(Group Membership/Atomic Broadcast)を使って管理されているのでIPアドレスは割り当てられていない。

2007/9/1更新

対応バージョン: 2

このエラーはGAB通信において正常に通信が行われずメッセージをロストしたときに出力される。

GAB通信のメッセージをロストする原因としては、ハートビートラインの負荷が高くメッセージの送信に遅延が発生している場合やCPU高負荷時のGABのメッセージロストが報告されている。

また、別の原因でマシンがCPU Panicなどを起こしている場合にもこのようなことが起きる場合がある。

GABのメッセージロストが発生した場合、GABを再スタートさせる必要がある。

GABの再スタートを行う為にはGAB通信を行っている全てのマシンをリブートする必要がある。

2007/9/1更新

対応バージョン: 2

gabconfigを使用する。

例)

# /sbin/gabconfig -a
GAB Port Memberships
=================================
Port a gen dfb90011 membership 01
Port h gen 6cba0006 membership 01

Port行の最後の01はシステム0と1でVCS関連プロセスが動作していることを示す。

Portは2つあり、それぞれ以下の目的に使用される。

Port a : GAB制御
Port h : VCS制御

従ってVCSのデーモンが停止している時はPort hは表示されない。

関連資料・記事

2007/9/19更新

対応バージョン: 2

/etc/gabtabにて行う。

/sbin/gabconfig -c -n<N>
-c

GABドライバを使用可能にする。

-n

クラスタ内のシステム数

関連資料・記事

2007/9/1更新

対応バージョン: 2

文字通り、auto-disabledフラグが立っているシステムがある。

システムがpanicダウン等で正常に終了していない場合このような事象になる場合がある。

このような場合auto-disabledフラグを手動でクリアすることで対処できる。

例) システムsys_aが異常の場合

# hagrp -display grp_a
#Group  Attribute     System  Value
:
grp_a   AutoDisabled  sys_a   1 ← auto-disabledフラグが立っている
grp_a   AutoDisabled  sys_b   0
:

# hagrp -autoenable grp_a -sys sys_a

# hagrp -display grp_a
#Group  Attribute     System  Value
:
grp_a   AutoDisabled  sys_a   0 ← auto-disabledフラグがクリアされた
grp_a   AutoDisabled  sys_b   0
:

2007/9/1更新

対応バージョン: 2

事象としてはクラスタメンバの状態を見ると以下のようになっている。

# hastatus -summary
:
-- RESOURCES ONLINING
-- Group  Type   Resource  System  IState

E  grp_a  Mount  res_a     sys_a   W_ONLINE_REVERSE_PROPAGATE

この状態では以下のようにリソースのofflineやclearも受け付けられない。

# hares -offline res_a -sys sys_a
VCS:10278:Service group grp_a of Resource res_a has failed or
is switching,on/offlining prohibited

# hares -clear res_a -sys sys_a
VCS:10265:Cannot clear resource while group is going offline

これは、VCS上での動作状態とOS上での動作状態に整合が取れなくなっているのが原因なのでhagrp -flushにてVCS上の動作状態を正しい状態に更新すればよい。

# hagrp -flush grp_a -sys sys_a

2008/8/4更新

対応バージョン: 2

リソースの削除は以下の手順で行う。

# haconf -makerw ← 構成変更可能モードへ移行
# hares -delete <リソース>
# haconf -dump -makero ← 構成変更不可モードへ移行(平常時は必ずこのモードへ)

上記設定内容は全クラスタメンバの/etc/VRTSvcs/conf/config/main.cfに反映される。

リソースの一覧は以下のコマンドで参照することができる。

# hares -list

2007/9/1更新

対応バージョン: 2

IPMultiNICエージェントやMultiNICAエージェント等、IPアドレスに依存しているエージェントがあるので、以下の手順で変更対象となるNICの設定内容(IPアドレス)を変更する。

VCS停止

全クラスタメンバ上で動作しているVCSを停止させるコマンドをクラスタメンバの任意のホスト上で実行

# hastop -all

VCS設定変更

全クラスタメンバの各ホスト上の設定ファイルを変更する。

# vi /etc/VRTSvcs/conf/config/main.cf
:
(対象となるIPアドレスの記述箇所を全て変更する)
:

全クラスタメンバの各ホストのその他の設定(/etc/hosts等)を変更し、1台ずつリブートする。

2007/9/1更新

対応バージョン: 2

hares -depを使用する。

例)

# hares -dep
#Group  Parent              Child
grpa    grpa_IPM_vip1       grpa_MNIC_qfe1
grpb    grpb_IPM_vip2       grpb_Proxy_MNIC
grpa    grpa_Mount_apfs101  grpa_DiskGroup_apdg
grpa    grpa_Mount_apfs201  grpa_DiskGroup_apdg
grpa    grpa_home           grpa_Mount_apfs201
grpa    grpa_AP_1           grpa_Mount_apfs101
grpa    grpa_AP_2           grpa_Mount_apfs101

この例では以下のような依存関係になっていることが分かる。

grpa_IPM_vip1はgrpa_MNIC_qfe1に依存

grpa_MNIC_qfe1(NICの物理デバイスqfe1)が利用可能にならないとgrpa_IPM_vip1(仮想IP)が利用できない、以下同様。

grpb_IPM_vip2はgrpb_Proxy_MNICに依存
grpa_Mount_apfs101とgrpa_Mount_apfs201はgrpa_DiskGroup_apdgに依存
grpa_homeはgrpa_Mount_apfs201に依存
grpa_AP_1とgrpa_AP_2はgrpa_Mount_apfs101に依存

2007/9/1更新

対応バージョン: 2

hacfコマンドを使用する。

# hacf -verify config

あるいは

# cd /etc/VRTSvcs/conf/config
# hacf -verify .

全ての設定ファイルが正しい記述になっていれば何も表示されない。

2007/9/1更新

対応バージョン: 2

hagrpコマンドを使用する。

# hagrp -switch <メンバグループ> -to <フェールオーバ先システム>

2007/9/1更新

対応バージョン: 2

VCSはhastartを実行した際にクラスタ内のマシンのうち1台でもhadが起動していればローカルディスクに保存されている構成情報を用いず、既に起動しているhadがメモリ上に保持している構成情報を転送してもらい起動する。

その為VCSを停止させたマシンでtypes.cfを変更してhastartを実行した場合、既にVCSが起動しているマシンがあればtypes.cfの変更内容は反映されないことになる。

以上をふまえ、types.cfを変更する方法は次のいずれかになる。

全てのマシンのVCSを停止させtypes.cfを変更後、変更を行ったマシンからhastartを順に実行する。

had起動中にhaattrコマンドを使用してtypeの属性値の変更を行う。

では実際にhaattrコマンドを利用したリソース設定例を示す。ここではリソースをJP1とする。

# haconf -makerw ← 構成変更可能モードへ移行
# hatype -add JP1 ← リソースタイプを追加(作成)
# haattr -add JP1 SystemType -string -scalar
# haattr -add JP1 LogicalHost -string -scalar

(*) -string -scalarはデフォルトのオプションなので省略してもよい。

# hatype -modify JP1 ArgList SystemType ← ArgListを設定
# hatype -modify JP1 NameRule resource.SystemType ← NameRuleを設定
# haconf -dump -makero ← 構成変更不可モードへ移行(平常時は必ずこのモードへ)

2007/9/1更新

対応バージョン: 2

これはVCSが「設定ファイルが古い」と思っているためにサービスが起動できない状態になっているので、以下の方法で復旧可能である。

# hastop -all
# hastart -force

ただしこの方法はメンバを構成しているホスト全体を停止させることになるのでそれが可能な場合に「のみ」実施すること。

2007/9/1更新

対応バージョン: 2

VCSのデフォルトの動作は(障害発生時以外の)通常のshutdown時にもフェールオーバするような設定になっているので、initスクリプトを以下のように変更することでこれを無効にできる。

# cd /etc/init.d
# vi vcs

(変更前)

   63       $HASTOP -local -evacuate > /dev/null 2>&1

(変更後)

   63       $HASTOP -local > /dev/null 2>&1 ← -evacuateを削除

また、VCSのデフォルトのインストールではランレベル毎のinitスクリプトが個別に配置されるので、上記ファイルへのシンボリックリンクとして再設定する。

# cd /etc/rc0.d
# rm K10vcs
# ln -s ../init.d/vcs K10vcs

# cd /etc/rc3.d
# rm S99vcs
# ln -s ../init.d/vcs S99vcs

2007/9/1更新

対応バージョン: 2

ソフトの動作にホスト固有の情報が必要なものはフェールオーバ不能である。

例えばライセンス管理をホストIDで行っているようなソフトがこれにあたる。

2007/9/1更新

対応バージョン: 2

以下のトラップがデフォルトで定義されている。

"A new system has joined the VCS Cluster"
"An existing system has changed its state"
"A service group has changed its state"
"One or more heartbeat links has gone down"
"An HA service has done a manual restart"
"An HA service has been manually idled"
"An HA service has been successfully started"

また、VCSのEnterpriseIDは.1.3.6.1.4.1.3.1.1である。