GFSフォーマットする前に。 (4) RedHat Cluster と Quorum

Clusterの土台が完成しました。

それではGFSフォーマット、とその前に。

そもそも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

(exptected_votes / 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だけ起動させると

Nodes: 2
Expected votes: 4
Total votes: 2
Quorum: 3 Activity blocked

そして元々正常稼動していた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)の時と比較して大きく変わっていますので。