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
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である。