Fencingの設定をしない、もしくは、Manual Fencingを選択してしまった場合、RedHatのサポートは受けられなくなってしまいます。

注意してください。

で、Fencingとはなにするものよ、です。
Clusterを構成しているNodeが何らかの原因で障害を起こしたとします。
この状態でこのノードは動作を続けるべきでしょうか？
恐らく答えはNoだと思います。
速やかにこのnodeは動作をやめるべきです。
他のnodeも参照しているGFSデータを破壊してしまうような動作を起こしてしまうかもしれないからです。
障害を起こしてしまった場合、恐らくCluster Memberとしてハートビートを返しませんので、その他のnodeはこのサーバを殺す処理を自動的に実行してくれます。
この動作をfencingといいます。

正常なClusterグループの一番若いIDを持つnodeがこのfencingという動作を実行します。

ですので、集団リンチが発生するということはありません。

これを実行せずスキップした場合、どうなるかというと。
fencing動作完了後、GFSジャーナルの修復を行います。
ダウンしたnodeが中途半端なデータを書き込みしっぱなしの可能性があるためです。
fencingしない場合、ジャーナル修復後ダウンしたと思われたnodeが復活して書き込みを再開したとします。

そうです。
データは矛盾したり破壊されてしまいます。
この矛盾動作を防ぐためにfencingを行う必要があるのです。
fencing動作に求められることは

確実かつ迅速に障害発生中のサーバの電源をOFF（もしくはリセット）することです。

とにもかくにもDISKに書き込もうとしている情報（memory）を確実に消し去ることが目的です。

その為、OSに依存しないハードウェアによる電源OFF、ON出来る機材が別途必要になる、という事です。
（障害発生中のnodeなのでrebootが実行できる、できないという議論はここでは無意味。)
SANを移用している場合、データの書き込みを防げばよいので、SAN Switchに対してPortを強制Downさせて書き込みをさせない、というfencing方法も選択可能です。
この方法のみをfencingに採用した場合は自動的にPortをUPして良いかどうかまでの判断はfencing methodでは出来ないので障害を取り除いた後、手動でportをupする手間が必要になると思います。
そういうこともあり自動的に復旧可能である電源OFF、ONできる機材を用意しておいたほうが楽でしょう。
この場合は、リモート操作可能なPDUを利用する、IPMI(またはiLOなど）といったリモートマネージメントコンソールを利用する事になります。
どのような機材がサポートされているかを手っ取り早く調べるにはCluster Memberにログインして

ls /sbin/fence_*

するのが良いと思います。
CentOS5.2では以下の通りです。

/sbin/fence_apc
/sbin/fence_apc_snmp
/sbin/fence_bladecenter
/sbin/fence_brocade
/sbin/fence_bullpap
/sbin/fence_drac
/sbin/fence_egenera
/sbin/fence_ilo
/sbin/fence_ipmilan
/sbin/fence_manual
/sbin/fence_mcdata
/sbin/fence_node
/sbin/fence_rps10
/sbin/fence_rsa
/sbin/fence_rsb
/sbin/fence_sanbox2
/sbin/fence_scsi
/sbin/fence_scsi_test
/sbin/fence_tool
/sbin/fence_vixel
/sbin/fence_wti
/sbin/fence_xvm
/sbin/fence_xvmd

SAN Siwtchを利用している場合はfence_sanbox2やfence_brocadeを利用、リモートPDUであればfence_apcというコマンドにてfeincing methodがRedHatから提供されています。
これらが利用できる環境であり、適切に設定されているのであればきちんとサポートが受けられる、ということです。
（設定が適切でなくても適切な方法を教えてください、というサポートしてもらえると思います。）
なお、上記fencingコマンドに対応した機材が無いけど、fencing出来そうな機材はある、という場合は、/sbinにスクリプトを作成してcluster.confで呼び出すという方法もあります。
この場合は恐らくfencingの部分に関してはサポートは受けられなくなると思います。
（他人が作ったスクリプトですからね・・・。）

私の場合、やはり標準でfencing methodが用意されていない環境ですので自作してしまいました。
自作する場合、perlで記述されている/sbin/fence_sanbox2を参考にしてみてください。
作成する際はperlでもCでもshellスクリプトでも何でも構いません。
別にサポートいらないし、ただどのタイミングでfencingが実行されるのかをチェックしたい、という場合は、fencing方法にmanualがありますので、こちらを利用します。
fencing manualを使えば実際に各nodeがfencingするところを確認できますのでテスト段階では有用です。

くどいですが、fencing manualやそもそもfencingを設定しない環境はサポートされません。

サポートされない、という事は安定した動作環境ではないよ、という事なのでサポートが必要、不必要にかかわらず本番利用時には必ずきちんとfencing可能な機材を導入しておきましょう。
これこれの障害が想定されている、それに対応するための方法がfencingだよ、とわざわざ教えてくれているのでこれを採用しないのはちょっとどうかと思います。
リモートPDUなんて復旧の手間を考えれば余裕でお釣りがくるほど安価なものです。
方法的にいきなり電源OFF、ONには抵抗感があるかもしれませんが、そうせざるを得ないケースがある事もまぎれも無い事実です。

なお、きちんとfencingに対応した機材を購入、設置、設定、テストも完了したけど実際にfencing出来なかったという場合。
まさかその機材が1つのセッションしか受け付けず、fencingしたときに誰か他の人がその機材に対してアクセスしていた為、fencing要求がブロックされた事が原因でした、という間抜けな自体は起こさないように注意してください。
この手の機材は1セッションしか受け付けない、という事は多いです。
私もfencingではないですが、某ストレージに定期的にsnapshot命令を発行するというスクリプトを作った時にこの手の罠にはまったことがありました・・・。
事前に想定できるしょうもない罠なので先に書いておきます。

最後にさりげなく書いておきます。

grub等に意味も無く長いboot waitを設定している場合。
少なくとも標準の5秒に戻しましょう。（もしくはそれ以下。）
それが推奨なので。

(fencingは別途もう少し深く取り下げようと思います。）

それでは起動が完了しないというケースを再現させてみましょう。

Cluster Memberが全く起動していない状態で1nodeをシングルモードで起動します。
その他nodeは起動させません。
起動後、以下のコマンドを実行。

/etc/init.d/network start

この状態で/etc/init.d/cman startを実行し、その結果と時間を計測します。

Starting cluster:
Loading modules... done
Mounting configfs... done
Starting ccsd... done
Starting cman... done
Starting daemons... done
Starting fencing... failed

real 5m2.932s
user 0m0.057s
sys 0m0.195s

Starting daemonsまでは直ぐに完了しますが、Starting fencingにて失敗、更に失敗するまでに5分経過していました。
実際、fencedも起動していません。

cman_tool services
type level name id state
(空）

なぜでしょうか？
なお、これは正しい挙動です。

Starting fencingはCentOS5から/etc/init.d/cmanに集約されています。
/etc/init.d/cmanを覗いてみると

FENCED_START_TIMEOUT=300

という記述があります。
どうもこのパラメータによって起動までに5分も要したようです。
この状態のcman_tool statusの出力結果は以下の通りです。

Nodes: 1
Expected votes: 4
Total votes: 1
Quorum: 3 Activity blocked
Active subsystems: 5

起動時、誰とも通信できない為split brain状態(=Status:Activity blocked)であるとこのnodeは認識したようです。
確かにその通りですね。

次にStarting fencing(fence_tool join)に失敗した理由は以下の通りです。

fence_tool join(またはleave)を完了するためにはfenceドメインに参加、離脱するためにそのnodeが参加しているClusterがQuorumに達している必要がある。

というルールがfence_tool join (or leave)に存在していたからです。

Quorum: 3 Activity blocked

という状態(Quorumに達していない)、ですからStarting fencingに失敗して当然です。
今回、cman_tool joinする時/etc/cluster/cluster.confより自分が参加すべきClusterを見つけようとしましたが誰とも通信できませんでした。
従って、ひとまずClusterに自分独りの状態で参加します。
cman_tool joinに成功してもfence_tool joinまで完了しなければClusterサービスは開始されませんのでここまでは動作的にも何ら問題ありません。
次にClusterサービスを完全に開始させるためにfenceドメインに参加します。（しなければなりません。）
この時、

fence_tool join(またはleave)を完了するためにはfenceドメインに参加、離脱するためにそのnodeが参加しているClusterがQuorumに達している必要がある。

というルールに引っかかりfenceドメインの参加(fence_tool join)に失敗してしまったのです。
CLVMなしGFSをマウントするためには、

cman_tool join
fence_tool join

これらサービスの開始に成功した状態(Clusterサービスが完全に開始された状態)でなければGFSマウントはできません。

前回、同じ1node状態なのに4nodesから1nodesへ正常手順でCluster Memberをシャットダウンした時とは明らかに違うようです。
それはそうですよね。
前回は4nodes状態から意図的に各Cluster Memberがcman_tool leave removeした事を最後の1nodeは知っていますが、今回はそのような事をこの1nodeサーバは知りません。
従って、cluster.confから推測（推測せざるを得ない）してQuorumに達していない、fenceドメインに参加してはならない、Starting fencing NGとなる訳です。

それでは正しいCluster起動手順はどうすればよいのでしょうか？
推奨手順は以下の通りです。

一番初めに起動させたnodeがfence_tool joinに失敗するまでの時間である300秒以内にQuorumを得るに為に必要なその他nodesを起動させStarting fencing(fence_tool join)をそれぞれ実行する。

となります。
台数が多い管理者には残酷な手順ですが、これが推奨手順となります。
その他考えられる方法としては、初めの一台をシングルで起動、cman_tool expected -e 1などを実行して起動を継続する、または、qdiskを利用するでしょうか。
え？何十台もあってそんな時間で完了させるのは無理、という場合はFENCED_START_TIMEOUT
を調整するか推奨はされていませんが、/etc/init.d/cluster.confに以下の記述を追加します。

<fence_daemon clean_start="1" post_fail_delay="0" post_join_delay="3"/>

というようにclean_start="1"を追加します。
こちらの方法は推奨されていません。
詳しくはman 8 fencedしてください。（暇があれば追記します。）

なお、別途書きますが、fencing動作が実際に行われる前提として、

fencing動作を行うのはQuorumに達している場合だけである。

このケースの場合、cman_tool joinしてもQuorumには達していませんので、fencing動作は行われません。（行われないはず。）

ただし、例外があります。以前書きましたが、2nodes Clusterのケースです。

2nodes Clusterは1ノードだけ起動した状態でもQuorumに達します。
そんなこともあり、意図しないfencing合戦を招くことになります。
（お互いのnodeがお互いをfencingしあう状態の事。）
よって、2nodesの場合、基本的にはパラメータを調整しなければ1node起動したらもう一台も素早く起動する、というのが正しい手順になります。
そのようなこともあり2nodes Clusterはあまり推奨されない感じですのでご注意ください。
この辺りをきちんと理解せずサーバがリブートを繰り返すなどとサポートへ問い合わせると、あは～ん?言われるかもしれません。（嘘です。）
2nodesでもfencing設定をきちんと行っていればサポートされます。
つまり、2nodesでもそれ以上でも推奨fencing設定をしていなければサポートを受けられません。この辺りは後日fencingについて書く時にでも触れます。

最後にこのような理由から4node(3nodes以上）のケースの場合、のんびりCluster Memberを起動させてしまうとうまくサービスが起動しないCluster Memberが発生してしまう、という事です。
そしてそれは状況によっては正しい挙動なのです。

（非常に中途半端ですが、眠いので今日はここまで。次回はfencingについてかな。）

そもそもClusterを使う理由は何でしょうか。

それはサービスを出来る限り継続させるためです。

決して処理速度を向上させる事はその前提ではありません。

それ故かRHCSではアクティブ/アクティブ構成は実質サポートされていません。

基本的にはアクティブ/スタンバイな構成を作ることを目的としています。

なのでGFSは例外的な位置付けです。（当たり前といえば当たり前）

Clusterを構築するに当たってまず検討すべきなのがいくつのnodeでClusterを構成するか？です。

その数を算出する上で知っておくべき事があります。

知らないと落とし穴にはまります。

1) 2 nodes

2) 2 nodes以上

まずここが分かれ道となります。

今回は2 nodes以上を選択しましたがそれには理由があります。

2nodes以上で構成するClusterでは常について回る問題があります。

Split Brain問題

例えば3nodesで構成したcluster(A,B,C)にネットワーク障害が発生したとします。

AとB,Cは通信できません。

という障害です。

Clusterは分裂してClusterが2つ存在することになります。

AはB,Cと通信できない　= Aから見るとB,Cはダウンした。

B,CはAと通信できない  = B,Cから見るとAはダウンした。

そう判定せざるを得ません。ネットワークを頼りに双方チェックしていますから。

通信できないのですから、通信できない相手はダウンしたと考えるしかありません。 

この時、Cluster MemberであるA,B,Cはどう振舞うべきでしょうか。

言い換えると誰がサービスを継続してよいのでしょうか？

発生した障害内容によっては誰もサービスを継続してはならないかもしれません。

（実際問題、ありとあらゆる障害を想定してそれに対応する仕組みを事前に構築することは実質不可能でしょう。当初はだれも想定していない問題が発生することもままあります。）

そういう方針であれば、そういう設定も可能です。

障害が発生した場合、完全に正しくという判定を行うことは自動的には困難であるためサービスを管理者が手動で復帰させるまで全nodeのサービスを一時凍結（サービス停止）させてしまうという方法です。

しかし、それではあまりにも不便ですし、Clusterにする意味がありません。

となると、

誰がサービスを継続してよいのか？

という問題に対してある一定の厳密なルールを設けるしかありません。

ああかもしれない、こうかもしれない、ではなくシンプルなルールです。

（複雑なルールは判定が複雑になりすぎてまともに動作しないことも考えられます。

 なんせ障害が起こっているケースにおける判定ですからその結果もまた信用できないかもしれません。）

RHCSの場合は、こういったClusterが分裂した場合、誰がサービスを継続しても良いか、というルールを以下に定めています。

Quorum(クオラム)に達したClusterグループ

Quoram(クオラム）というのはちょっと日本語にしても分りづらいので、訳さずにそのまま使うことにします。

各Cluster Memberは投票数を与えられています。

デフォルトでは各Clusterは1票の投票数(Vote)を与えられています。

例えば、4nodesクラスタが正常に動作している場合、投票数の総計は4票になります。

この時期待される投票の最大数を

expected votes

と言います。

Quorumを決定する式は以下の通りです。

Quorum = (expected_votes / 2) + 1

(exptected_votes / 2の部分は小数点切り捨てです。)

上記ルールは丸暗記してください。

QuorumはClusterメンバー数の過半数に1を足した数

というのがデフォルト設定的な算出方法です。

3nodesの場合、Quorumは

(1 + 1 + 1 / 2 ) + 1  = 2

今回の例では2nodes認識しているCluster Memberが生き残りサービスを継続します。

残り1nodeのCluster Memberはサービスを停止します。

Split Brainに対応する基本的な方法はこの通りです。

従ってダウンしてもサービスが可能なCluster Node(s)は

・3 nodesの場合は1 nodeのみ {Quorum = (3 / 2) + 1 = 2}

・4 nodesの場合も1 nodeのみ {Quorum = (4 / 2) + 1 = 3}

・5 nodesの場合は2 nodes {Quorum = (5 / 2 ) + 1 = 3}

思った以上にダウンしてもサービス継続が可能なサーバは少ないかもしれませんね。

であれば、Votesパラメータを調整して1台でもサービス継続を可能にしてしまえば、よいのでは？という考え方もあると思います。

それはそれでOKですが、基本的にどんなサーバでも必ずダウンする可能性があり、稼働率もまた100%言い当てることは出来ません。

そもそもClusterを使う理由は

サーバはいつか必ず倒れるであろう。

というシンプルな事象を補うための仕組みですから、あまりVotesを駆使するのはお勧めしません。

ここまでくればcman_tool statusの意味も分かってくると思います。

Nodes: 4
Expected votes: 4
Total votes: 4
Quorum: 3

このClusterは現在4nodesで動作しています。

よって期待されるVotesの最大値であるExpected votesは4(1 + 1 + 1 + 1)となります。

現在時点で実際に投票されている数の総計(Total Votes)は4です。

つまり、4 nodesとも正常に稼動しています。

この時、Clusterを維持するために必要なQuorumは

(1 + 1 + 1 + 1 / 2 ) + 1 = 3

となります。

よって1台までのサーバ障害は許容されます。

ちなみに、メンテナンス時など正常にサーバをダウンさせた場合、Quorumに達することが出来ず、サービスも止まってしまうのでは？

とお考えのあなた。

その疑問は正しいです。

それでは、

Nodes: 4
Expected votes: 4
Total votes: 4
Quorum: 3
Active subsystems: 9

この状態から1台ずつサーバをpower off等を利用して正しい手順でサーバダウンさせてみます。

(3nodesになった場合）

Nodes: 3
Expected votes: 3
Total votes: 3
Quorum: 2

(2nodesになった場合）

Nodes: 2
Expected votes: 2
Total votes: 2
Quorum: 2

(1nodeだけになった場合)

Nodes: 1
Expected votes: 1
Total votes: 1
Quorum: 1

はい、安心してください。

正常手順でCluster Memberをダウンした場合は、きちんとQuorumを再計算してサービスは継続します。

Quorumに達しなくなりサービスが停止するかも、という状態になるのはあくまで正常にCluster Memberを切り離さなかった場合(fence_tool leave, cman_tool leaveしなかった場合)です。

それでは異常な状態を意図的に作り出してみます。

まだfencing設定をしていませんからQuorumに達しない状態になった場合、Clusterは活動を停止するはずです。

(ただし、2009/03/10時点のCentOS5.2最新版で構成した場合、上記の稼動状態である1node状態から1nodeだけ起動させると

そして元々正常稼動していたnodeはサービスが停止してしまいます。

後から起動したnodeはcman_tool joinには成功していますが、fencingドメインへの参加(fence_tool join)には失敗しています。つまり、当然こちらのnodeもサービス停止状態で起動を完了します。

これはおかしんじゃない？という気がする・・・。

正しくは4nodes状態から2nodes状態へ正しくnodeをダウンさせた時のように

Nodes: 2
Expected votes: 2
Total votes: 2
Quorum: 2

となるべきだと思うのですが。

-- 2009/06/11 追記 --

CentOS5.3になりcman_tool removeしてもexpected votesが減らなくなり、結果、どんどんnodeを正常シャットダウンさせると過半数以下に達した時点でinquorate -> activity blockedになりサービス停止・・・。

正しくはcman_tool leaveしたのだからexpected votesも正しく減少、例え最後の1nodeだけになってもサービスは継続すべき。

と、あれこれ考えても仕方ないし根本調査している時間もないのでlinux-cluster MLへサクッと症状を投げてみたところ。

> Eek! You're right.
> I've raised a bugzilla report for this:
> https://bugzilla.redhat.com/show_bug.cgi?id=505258

「いやぁーー、お前正しいよ。直しとく。」

というメールが即座に返ってきた。

ただ、優先順位が低い問題なのでRH5.4辺りで直されるみたい。

-- 追記終わり --

次回以降では正しくClusterを起動させる手順とcmanをもう少し掘り下げてみます。

cmanの実体がCentOS(RedHat4)の時と比較して大きく変わっていますので。

https://(管理サーバIP):8084/

ログインに利用するIDはadmin、パスワードはluci_admin initを実行した際に設定したパスワードを入力します。
もろもろのテンプレート変数化けが気になる方はブラウザの設定言語を英語にしましょう。
え？まともに動かない？
そういう方は

GFSフォーマットする前に。 (1) Cluster管理サーバを構築

を再度読み直してください。
それでもだめだ、という方は、

管理サーバで

rpm -e luci
rm -rf /var/lib/luci
yum -y luci
luci_admin init
chkconfig luci on
/etc/init.d/luci restart

以上です。
ここでせっかくなのでluciのバックアップ方法を書いておきます。

/etc/init.d/luci stop

を実行した後、

luci_admin backup

を実行します。

# luci_admin backup
Backing up the luci server...
The luci backup was successful.

The backup data is contained in the file "/var/lib/luci/var/luci_backup.xml"

実行後に生成される/var/lib/luci/var/luci_backup.xmlをバックアップ、その後、/etc/init.d/luci startするだけです。
冗長化するのが馬鹿らしいほど簡単です。

それでは実際にClusterを構成してみましょう。
ただし、Clusterに参加させるだけで実際には何のサービスも動かしません。
それではくどいですが、管理サーバを除くCluster Meberにて以下のコマンドをこの段階に到達する前実行した事を確認します。

mv /etc/cluster/cluster.conf /tmp/
rm -rf /etc/cluster/cluster.conf
yum -y groupremove "Cluster Storage" "Clustering"
yum -y install ricci
chkconfig ricci on
/etc/init.d/ricci start

うっかり忘れたうっかりさんは全Cluster Memberで上記コマンドを流しておいてください。
この段階では何のCluster設定もされていないはずなので再度実行しても問題は無いはずです。
再度構築しなおす場合は、luciを再インストール、上記コマンドを流せばきれいな環境で再セットアップできるはずです。
（ただし、ここまでであれば、のお話）

ログイン後、clusterタブにあるCreate a New Clusterをクリック、以下のようにCluster MemberをFQDNで登録、パスワードはrootのパスワードを入力します。
Cluster Nameは同一ネットワーク上で他のClusterと衝突しないようにユニークな名称をつけます。
（確か16文字以内）

Check if system passwords are identical.

に追加チェックを入れてSubmitをクリックします。

くどいですが。/etc/hostsに記述した

FQDNでSystem HostnameにCluster Memberを登録します。

つまらないトラブルに後々遭遇しないためにも重要な手間です。
なお、ここでエラーが発生する人は管理サーバからFQDNで設定しようとしているCluster Memberにping等で疎通チェックしてみてください。
hostsが間違えている、IPを振り違えているという単純なミスだと思います。
Cluster Memberにrucciを導入し忘れた、もしくはricciが起動していない可能性もあります。
その場合は慌てずそのCluster Memberにて

yum -y install ricci
chkconfig ricci on
/etc/init.d/ricchi start

すればOKです。
くれぐれも暴走して余計なパッケージは導入しないでください。

画面の関係上、一部切れていますが、以下のようにCluster Memberへ必要なパッケージの取得命令、デフォルトCluster設定の配布が行われます。

最新パッケージを取得してしまう事が気に入らない人は手動(rpmコマンドなどを利用）でパッケージを各Cluster Memberに導入後、Local Packageを使うように設定してください。

さて、基本的なCluster設定はここまで完了です。

おつかれさまでした。
思った以上に簡単なはずです。
（簡単になりました。）

初期導入チェックとして各Cluster Memberでcman_tool statusを実行してみましょう。
以下のような結果が返ってくればOKです。

cman_tool status
Version: 6.1.0
Config Version: 1
Cluster Name: hogehoge
Cluster Id: 26911
Cluster Member: Yes
Cluster Generation: 612
Membership state: Cluster-Member
Nodes: 4
Expected votes: 4
Total votes: 4
Quorum: 3
Active subsystems: 9
Flags: Dirty
Ports Bound: 0 11 177
Node name: cluster1-vip.hogehoge.jp
Node ID: 3
Multicast addresses: 239.192.105.136
Node addresses: 192.168.0.10

気になるポイントとして

Flags: Dirty

だと思いますが、現時点では問題ありません。
Dirtyであれば逆に問題ありません。
Dirtyという結果も含め詳細はまた別途。
現時点では、4台構成であれば、

Nodes: 4
Expected votes: 4
Total votes: 4
Quorum: 3
Active subsystems: 9

となっていれば問題ありません。

今日はここまで。
（単に眠いだけ）