medamaの日記

技術的な事をメインにしてみる。

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

それでは、GFSを使ってみましょう。
ただし、ちょっとその前に。

まず、きっちりとした環境を作りたい場合は以下のサーバ群を用意してください。

CentOS5.2以上の

Cluster管理(Conga)専用サーバ 1台
GFSを利用するCluster Memberサーバ 3台以上

Cluster管理専用サーバはCluster Memberサーバで兼務させることは可能ですが、やれどのサーバが管理サーバであっただの、という面倒な事になるので

面倒がらずに始めから別にCluster管理サーバを構築しておきましょう。

構築も設定のバックアップも簡単なので何かあってもすぐに代替を用意することは可能です。

クラスタ管理サーバが倒れてもGFSの動作にはなんら影響しません。

安心してください。
なので、管理サーバを冗長化するほどでもないでしょう。
(といっても要件次第でしょう。)

そして管理サーバがあると、Cluster Memberを一気に構築することが出来ます。
そう、Cluster MemberにRHCSパッケージをインストールさせたりCluster Memberに参加させたりできるのです。
何台もあるCluster Memberのセットアップなんて面倒なのではしょるに限ります。
必要であればあるnodeをCluster Memberから外したりリブートさせることも出来ます。
(若干嘘あり。やはり細かい設定は必要となりますが、最低限動作可能な状態には一気にもっていけます。それによって手作業をはしょれるのでミスも減ります。)

次にCluster Memberサーバを3台以上用意する理由ですが。
RHCSでは2ノード自体特殊な環境として考えられています。
cluster設定にも

<cman two_node="1" expected_votes="1"/>

とさりげなく余計な設定を要求されます。
本当に面倒な理由はここではなくfencingという仕組みにあるのですが、この辺りはまた今度。

それでは、管理サーバの用意が出来ましたね?
以下のコマンドを叩いてください。

yum groupremove "Cluster Storage" "Clustering"
yum -y luci
chkconfig luci on
luci_admin init
/etc/init.d/luci start

これだけでOKです。
groupremoveした理由は念のために余計なパッケージが入っていないことを確認するためで何もありませんでした、としても問題ではありません。

yum -y install luci する前に

rm -rf /var/lib/luci

すれば更に完璧でしょう。
(過去に構築したluciデータが削除されるので、必要な場合はmv /var/lib/luci /var/lib/luci.OLD して下さい。)

そうそう、CentOS5.2のLuciにはバグがあり、ブラウザの言語設定が日本語にセットされている場合、ログイン画面にたどり着きません。
そういう場合は、

/var/lib/luci/etc/zope.conf にある

# default_zpublisher_encoding utf-8

コメントを外しつつ_を-に変更します。

default-zpublisher-encoding utf-8

落とし穴を回避しつつ

/etc/init.d/luci restart

すればあとは

https://(Server IP):8084/

するだけでConga管理画面にたどり着けるはずです。
次にCluster構築を始める前に管理サーバの/etc/hostsを修正してください。
そうです。
Cluster MemberのIPをhostsに登録するのです。
DNSサーバ参照に失敗してクラスタ環境が破綻した、なんて馬鹿げたトラブルなんて起こさないに限ります。
なお、ここで慎重になりましょう。
Cluster Memberをhostsに登録する際、FQDNを使いましょう。

RHCSは/etc/hostsに登録されたサーバを参照する際、参照順序を保証していません。

ああ怖い怖い。
しょうも無いトラブルの目なんて事前につぶしておくに限ります。
なお、CongaはLuciとricciで構成されます。

管理サーバに必要なのはluci、Cluster Memberに必要なのはricciのみです。

意味も無く汚れたCluster Memberを作らないようにご注意ください。
最後に管理サーバ及びCluster Memberサーバには2NIC以上用意してください。
1つはapacheといった一般公開用(public)ネットワーク、2つ目はClusterのみで利用する非公開(private)NICです。
最低でもprivate NICはbondingしましょう。

え?publicじゃないの?

GFSのデータが破壊する = 一般サービスも結局停止

そんな恐怖を味わいたい方はどうぞ。
データが残っていれば一般サービスが止まっても何とかなるでしょうし、GFSを使うんだからL7 Switchで更に分散しているでしょ?
サービスの切り替えはそちらに任せて重要なデータをまず保護しましょう。
くどいですが。

データが残っていればサービスは復旧します。

最優先で守るべきはデータです。
両方守るというのは更にベターな方針ですが、NICリソースが限られている場合、守るべきはデータです。
VLAN+LACP(802.3ad)を使ってうまくやりくりをする、という方法もあるでしょうが、本題から外れるのでここでは触れません。