So-net無料ブログ作成
検索選択

Linuxでクラスタ~heartbeatを試す(そして苦しむ)~その3 [Linux(CentOS/VineLinux)]

 はい。heartbeatが一応起動したってことで、まずはギッタンバッコンする前に、現状の確認から。
[root@nfs001 ~]# crm_mon
Defaulting to one-shot mode
You need to have curses available at compile time to enable console mode


============
Last updated: Mon Feb 28 17:24:40 2011
Current DC: nfs002.mycompany.com (6a838508-****-****-****-72e755b88326)
2 Nodes configured.
1 Resources configured.
============

Node: nfs002.mycompany.com (6a838508-****-****-****-72e755b88326): online
Node: nfs001.mycompany.com (47e72b74-****-****-****-18077e2dcd57): online

Resource Group: nfs_service
    ipaddr      (heartbeat::ocf:IPaddr):        Started nfs001.mycompany.com
    lvm (heartbeat::ocf:LVM):   Started nfs001.mycompany.com
    filesystem  (heartbeat::ocf:Filesystem):    Started nfs001.mycompany.com
    networkfilesystem   (heartbeat::ocf:NFS):   Started nfs001.mycompany.com


 ※あ、都合上、NFSのリソースがすでに定義され動作してしまっているが、ここではちと見なかったことにしていただきたい。(笑) 以下同じ。

 上記のコマンドから判ること。
 ・クラスタシステムに組み込まれているのはnfs001.mycompany.comnfs002.mycompany.comの2つのノード(サーバ)である。
 ・リソースを握っているのはnfs001.mycompany.comである。 → つまりこちらが稼動系ということ
 ・組み込まれているリソースは、クラスタの仮想IPアドレス、lvm(共有ディスク)、ファイルシステム(共有ディスク)、そしてNFSである。(NFSはあとで触れるので、今は見なかったことに…)

 この状態で、クラスタの仮想IPアドレスにpingを投げたり、sloginとか実行すると、nfs001側が応答する。
 sshで試してみよう。
[root@togame ~]# ssh nfscl01 uname -a
Linux nfs001.mycompany.com 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:52:25 EST 2011 x86_64 x86_64 x86_64 GNU/Linux

 「nfscl01」はクラスタの仮想IPアドレスに付けた名前である。
 unameしてみると、nfs001が反応していることがわかる。

 では、リソースの状態を個別に確認してみよう。
 まず、ifconfigをそれぞれのサーバで実行すると…
 nfs001側
[root@nfs001 ~]# ifconfig
eth1      Link encap:Ethernet  HWaddr 00:21:5A:D1:3C:C6
          inet addr:192.168.1.1  Bcast:192.168.1.3  Mask:255.255.255.252
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:5878 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5837 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1484641 (1.4 MiB)  TX bytes:1427366 (1.3 MiB)
          Interrupt:177 Memory:ca000000-ca012800

eth2      Link encap:Ethernet  HWaddr 00:1F:29:5D:3F:EA
          inet addr:192.168.2.1  Bcast:192.168.2.3  Mask:255.255.255.252
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:5866 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5823 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1460409 (1.3 MiB)  TX bytes:1390416 (1.3 MiB)
          Memory:dffe0000-e0000000

eth4      Link encap:Ethernet  HWaddr 00:17:A4:3F:70:18
          inet addr:172.16.40.101  Bcast:172.16.43.255  Mask:255.255.252.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:192492 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3194 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:12180665 (11.6 MiB)  TX bytes:543060 (530.3 KiB)
          Interrupt:162

eth4:0    Link encap:Ethernet  HWaddr 00:17:A4:3F:70:18
          inet addr:172.16.42.1  Bcast:172.16.43.255  Mask:255.255.252.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:162
(略)

 eth4:0が、クラスタシステムの仮想IPアドレス。

 nfs002側は…
[root@nfs002 ~]# ifconfig
eth1      Link encap:Ethernet  HWaddr 00:21:5A:DC:EA:70
          inet addr:192.168.1.2  Bcast:192.168.1.3  Mask:255.255.255.252
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6267 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6447 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1545104 (1.4 MiB)  TX bytes:1659913 (1.5 MiB)
          Interrupt:177 Memory:ca000000-ca012800

eth2      Link encap:Ethernet  HWaddr 00:1F:29:5D:43:1E
          inet addr:192.168.2.2  Bcast:192.168.2.3  Mask:255.255.255.252
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6260 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6438 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1519820 (1.4 MiB)  TX bytes:1619234 (1.5 MiB)
          Memory:dffe0000-e0000000

eth4      Link encap:Ethernet  HWaddr 00:17:A4:3F:60:C0
          inet addr:172.16.40.102  Bcast:172.16.43.255  Mask:255.255.252.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:206192 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3345 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:12914961 (12.3 MiB)  TX bytes:511954 (499.9 KiB)
          Interrupt:162
(略)

 待機側のnfs002にはeth4:0が無いことがわかる。

 続いて、LVMの状態。
 稼動系であるnfs001は…
[root@nfs001 ~]# lvdisplay
  --- Logical volume ---
  LV Name                /dev/vgcontents/data
  VG Name                vgcontents
  LV UUID                rckNY1-1kmo-T2iB-wlBk-p1NK-6MXL-NrBaUP
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                12.70 TB
  Current LE             207999
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:1

 LV Statusが「available」であるので、この論理ボリュームが使用可能な状態に置かれている。
 では、nfs002はというと…
[root@nfs002 ~]# lvdisplay
  --- Logical volume ---
  LV Name                /dev/vgcontents/data
  VG Name                vgcontents
  LV UUID                rckNY1-1kmo-T2iB-wlBk-p1NK-6MXL-NrBaUP
  LV Write Access        read/write
  LV Status              NOT available
  LV Size                12.70 TB
  Current LE             207999
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto

 こちらはLV Statusが「NOT available」になっている。待機系であるから、この論理ボリュームにはアクセスできませんよ…という状態になっている。

 続いてファイルシステムのマウント状態。
 まあ、論理ボリュームはnfs001が使用可能、nfs002は使用不能であるから、結果はもうわかりきっているが。(笑)
[root@nfs001 ~]# mount
/dev/cciss/c0d0p3 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/cciss/c0d0p1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
/dev/mapper/vgcontents-data on /mnt/local/data type xfs (rw,noatime)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)
[root@nfs001 ~]# df -h
Filesystem          サイズ  使用  残り 使用% マウント位置
/dev/cciss/c0d0p3      59G  1.7G   54G   4% /
/dev/cciss/c0d0p1      97M   26M   67M  28% /boot
tmpfs                 6.9G     0  6.9G   0% /dev/shm
/dev/mapper/vgcontents-data
                       13T  8.7T  4.1T  69% /mnt/local/data

 マウントできてますな。
 ではnfs002側を念のため見てみると?
[root@nfs002 ~]# mount
/dev/cciss/c0d0p3 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/cciss/c0d0p1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)
[root@nfs002 ~]# df -h
Filesystem          サイズ  使用  残り 使用% マウント位置
/dev/cciss/c0d0p3      59G  1.8G   54G   4% /
/dev/cciss/c0d0p1      97M   26M   67M  28% /boot
tmpfs                 6.9G     0  6.9G   0% /dev/shm

 当然ありません。ということに。すばらしい!!(笑)

 では、クラスタの稼動系を交換してみよう。
 いきなりカーネルをkillしてみたい衝動に駈られるが、まずはちょっと自重して(笑)、heartbeatのコマンドで稼動系を交換してみる。
 稼動系を交換する場合は、現在の稼動系ノード(サーバ)をスタンバイ状態にするとよい。コマンドは crm_standby を用いる。
 書式は crm_standby -U 操作対象のノード名 -v スタンバイモードのON/OFF と、なる。なお、「操作対象のノード名」は、crm_monコマンドで表示される名前と完全に一致する必要があるので注意されたい。また、「スタンバイモードのON/OFF」は「on」または「off」で指定するが
  「on」…スタンバイモードがオン  つまりスタンバイ
  「off」…スタンバイモードがオフ  つまりアクティブ
 と、なることに注意。      …わかりづらいよねえ。(笑)

 では、nfs001をスタンバイモードにしてnfs002を稼動系にしてみよう。コマンドはこうなる。
 crm_standby -U nfs001.mycompany.com -v on
 実行結果はというと…
[root@nfs001 ~]# crm_mon
Defaulting to one-shot mode
You need to have curses available at compile time to enable console mode


============
Last updated: Mon Feb 28 18:27:02 2011
Current DC: nfs002.mycompany.com (6a838508-****-****-****-72e755b88326)
2 Nodes configured.
1 Resources configured.
============

Node: nfs002.mycompany.com (6a838508-****-****-****-72e755b88326): online
Node: nfs001.mycompany.com (47e72b74-****-****-****-18077e2dcd57): online

Resource Group: nfs_service
    ipaddr      (heartbeat::ocf:IPaddr):        Started nfs001.mycompany.com
    lvm (heartbeat::ocf:LVM):   Started nfs001.mycompany.com
    filesystem  (heartbeat::ocf:Filesystem):    Started nfs001.mycompany.com
    networkfilesystem   (heartbeat::ocf:NFS):   Started nfs001.mycompany.com
[root@nfs001 ~]# crm_standby -U nfs001.mycompany.com -v on
[root@nfs001 ~]# crm_mon
Defaulting to one-shot mode
You need to have curses available at compile time to enable console mode


============
Last updated: Mon Feb 28 18:27:28 2011
Current DC: nfs002.mycompany.com (6a838508-****-****-****-72e755b88326)
2 Nodes configured.
1 Resources configured.
============

Node: nfs002.mycompany.com (6a838508-****-****-****-72e755b88326): online
Node: nfs001.mycompany.com (47e72b74-****-****-****-18077e2dcd57): standby

Resource Group: nfs_service
    ipaddr      (heartbeat::ocf:IPaddr):        Started nfs001.mycompany.com
    lvm (heartbeat::ocf:LVM):   Started nfs001.mycompany.com
    filesystem  (heartbeat::ocf:Filesystem):    Started nfs001.mycompany.com
    networkfilesystem   (heartbeat::ocf:NFS):   Stopped
[root@nfs001 ~]# crm_mon
Defaulting to one-shot mode
You need to have curses available at compile time to enable console mode


============
Last updated: Mon Feb 28 18:27:34 2011
Current DC: nfs002.mycompany.com (6a838508-****-****-****-72e755b88326)
2 Nodes configured.
1 Resources configured.
============

Node: nfs002.mycompany.com (6a838508-****-****-****-72e755b88326): online
Node: nfs001.mycompany.com (47e72b74-****-****-****-18077e2dcd57): standby

Resource Group: nfs_service
    ipaddr      (heartbeat::ocf:IPaddr):        Started nfs002.mycompany.com
    lvm (heartbeat::ocf:LVM):   Started nfs002.mycompany.com
    filesystem  (heartbeat::ocf:Filesystem):    Started nfs002.mycompany.com
    networkfilesystem   (heartbeat::ocf:NFS):   Started nfs002.mycompany.com

 ちょっと長いが、
 ①クラスタの稼動系切り替え前にまずはcrm_monをしてみた。
 ②crm_standbyコマンドでnfs001をスタンバイモードに。
 ③すぐさまcrm_monコマンドでクラスタの状態を確認してみると…
Node: nfs002.mycompany.com (6a838508-****-****-****-72e755b88326): online
Node: nfs001.mycompany.com (47e72b74-****-****-****-18077e2dcd57): standby
  と、nfs001はスタンバイモードになっているが、
Resource Group: nfs_service
ipaddr (heartbeat::ocf:IPaddr): Started nfs001.mycompany.com
lvm (heartbeat::ocf:LVM): Started nfs001.mycompany.com
filesystem (heartbeat::ocf:Filesystem): Started nfs001.mycompany.com
networkfilesystem (heartbeat::ocf:NFS): Stopped
  というように、NFSが止まった状態で他のリソースはまだnfs001が握っている。
 ④少し待ってから再度crm_monでクラスタの状態を確認すると、リソースもnfs002が握っている状態になっている。

 という具合で、nfs001→nfs002にクラスタの稼動系を交換することができた。

 ちなみに、クラスタシステムの世界では、稼動系の交換のことを「フェイルオーバー」とか呼んだりする。人によっては「切り倒し」なんて表現をする人も。

 そんな訳でクラスタの稼動系交換に成功したことが確認できた。
 アーティクルが長くなったので一旦ここで区切る。

Linuxでクラスタ~heartbeatを試す(そして苦しむ)~その2 [Linux(CentOS/VineLinux)]

 さて。2台のサーバが最少のクラスタ構成になったところで、フェイルオーバー・フェイルバックをギッタンバッコンして楽しみたいところではあるけども、今回の構成的には共有ディスクも共にギッタンバッコンできなければ意味が無いので、ちょっとだけ我慢して先に進む。
 それでは、共有ディスクをクラスタに組み込むこととする。

 今回、共有ディスクはLVMを組んで使用することとした。CLVMでなく単なるLVM。
 えっ!?クラスタ構成でLVMなの!?  と思う向きもあるかもしれないが、1:1のActive=Standby構成ならclvmである必要が無いので、面倒くさくないこっちを使用する。hb-sfexが必要かどうか、現時点では判断が付かなかったので、ひとまず使わない方向で試してみようと思う。

 手順としては
①共有ディスクにLVMの物理ボリュームを作成する(片方のサーバでのみ実施)
②LVMのボリュームグループを作成し、①で作成した物理ボリュームを追加する(片方のサーバでのみ実施)
③LVMのボリュームグループから論理ボリュームを作成する(片方のサーバでのみ実施)
④ファイルシステムを作成する(片方のサーバでのみ実施)
⑤cib.xmlにLVMとファイルシステムをマウントするリソース情報を追記する(両方のサーバで実施)
⑥ディスク監視デーモン「diskd」のインストール(両方のサーバで実施)
⑦ha.cfに「diskd」の起動設定を追記(両方のサーバで実施)
⑧cib.xmlに「diskd」の監視設定を追記(両方のサーバで実施)
 と、いうことになるかな。

①共有ディスクにLVMの物理ボリュームを作成する(片方のサーバでのみ実施)
 まずは、pvの作成から。片方のサーバでだけ実施すれば十分。ま、特殊なことは何も無くて…

 今回のmultipath.confの設定からすると、以下のような例になる。

 pvcreate /dev/mapper/mpcontents001

②LVMのボリュームグループを作成し、①で作成した物理ボリュームを追加する(片方のサーバでのみ実施)
 vgを作成して、そこにpvを追加する。これも片方のサーバでだけ実施すれば十分。同じく特殊なことは何もない…

 vgcreate -s 64M vgcontents /dev/mapper/mpcontents001

③LVMのボリュームグループから論理ボリュームを作成する(片方のサーバでのみ実施)
 lvの作成。以下同文。

 lvcreate -l 100% -n data vgcontents

④ファイルシステムを作成する(片方のサーバでのみ実施)
 お好みのフォーマットでファイルシステムを作成。以下同文。

 mkfs -t xfs /dev/vgcontents/data

 ためしにマウントしてみるのも一興。
 mkdir -p /mnt/work
 mount -t xfs /dev/vgcontents/data /mnt/work
 あ、確認できたらちゃんとアンマウントしておくように!!!!!
 umount /mnt/work

⑤cib.xmlにLVMとファイルシステムをマウントするリソース情報を追記する(両方のサーバで実施)
 さて。いよいよ鬼門のcib.xmlです。(笑)

 記述するのは前のアーティクルでクラスタのVIPを設定したprimitiveブロックのすぐ下。同じgroupブロックの中に納める。
<resource>
<group id="nfs_server">
<primitive id="ip_address" class="ocf" type="IPaddr" provider="heartbeat">
<instance_attributes id="ia_ipaddr">
<attributes>
<nvpair id="ia_ipaddr_ip" name="ip" value="172.16.42.1">
<nvpair id="ia_ipaddr_nic" name="nic" value="eth4">
<nvpair id="ia_ipaddr_netmask" name="cidr_netmask" value="255.255.252.0">
</attributes>
</instance_attributes>
</primitive>
</group>
</resource>

 この、赤く表示した2行の間に、LVM・ファイルシステムの順にリソースを追加する。

 まずはLVMのリソース設定を示す。

<primitive id="lvm" class="ocf" type="LVM" provider="heartbeat">
<instance_attributes id="ia_lvm">
<attributes>
<nvpair id="ia_lvm_volgrpname" name="volgrpname" value="vgcontents"/>
</attributes>
</instance_attributes>
</primitive>

 こちらは1個しか記述することが無いので簡単。
 まずはprimitiveのブロックに、type="LVM"と書く。まずはここから。
 volgrpnameという設定項目のvalueに、クラスタリソースとして追加したいLVMのボリュームグループ名を指定する。ここでは「vgcontents」となっている。(vgcreateでそういう名前にしたからだよ!!)
 これによって、クラスタが起動した際、
  稼動系のサーバ → vgchange -ay vgcontents
  待機系のサーバ → vgchange -an vgcontents
 というコマンドがそれぞれ実行されたような状態になる。

 ということは、実施にこのボリュームグループにアクセスできるのは、稼動系のみということが約束されるのである。うっかりマウントしちゃった…というミスも防げてお買い得!!(ナニ

 続いて、このファイルシステムをマウントするためのリソース設定を見てみよう。

<primitive id="filesystem" class="ocf" type="Filesystem" provider="heartbeat">
<instance_attributes id="ia_filesystem">
<attributes>
<nvpair id="ia_filesystem_device" name="device" value="/dev/vgcontents/data"/>
<nvpair id="ia_filesystem_directory" name="directory" value="/mnt/local/data"/>
<nvpair id="ia_filesystem_fstype" name="fstype" value="xfs"/>
<nvpair id="ia_filesystem_options" name="options" value="noatime"/>
</attributes>
</instance_attributes>
</primitive>

 こちらは設定項目が4つ。
 こちらもまずはprimitiveディレクティブにtype="Filesystem"と書く。あ、大文字・小文字を区別するので念のため。
 nvpairで指定するのは
 device … マウントしたいデバイス名を記述する。ここではLVMを使用しているので、「/dev/vgcontents/data」としている。なお、生のデバイスを使うことも可能。
 directory … マウントポイントを記述する。上記のデバイスをどこにマウントするか、そのディレクトリ。サンプルでは「/mnt/local/data」と指定している。
 fstype … マウントするデバイスのファイルシステムを指定する。mountコマンドで言うところの「-t」オプションのアレ。ここでは「xfs」としている。mkfsでxfsを指定したからだよ!!
 options … ファイルシステムをマウントする際に使用するマウントオプション。mountコマンドで言うところの「-o」オプションのアレ。ここでは「noatime」とか指定している。リードオンリーにしたければ「ro」とかだろうし、「noexec」とか「async」とかお好みに応じてどうぞ!!!

 ということで、これらの記述をcib.xmlに書き足そう!!

⑥ディスク監視デーモン「diskd」のインストール(両方のサーバで実施)
 さて。ここで、heartbeatの足りないところを補ってくれる素晴らしいツールを紹介しよう。それは、「diskd」だ。開発してくれた人に感謝しよう!パチパチパチパチパチパチパチパチ…
 まず、http://sourceforge.jp/projects/linux-ha/wiki/hb-diskd からrpmパッケージをダウンロード。
 なお、この記事を書いている時点ではheartbeat の ver 2.1.4が必要とされるので、rpmでインストールしようとすると、依存性の問題でインストールできない。(CentOSのyumでインストールされるheartbeatは2.1.3なのだ!!!)
 そこでやむなく…

 rpm -ivh --nodeps hb-diskd-1.10-1.hb214.x86_64.rpm

 ↑は64ビット版のrpmパッケージなので32ビット環境の人は気をつけよう。

⑦ha.cfに「diskd」の起動設定を追記(両方のサーバで実施)
 久しぶりに/etc/ha.d/ha.cfを編集する。(笑)せっかくなので、共有ディスクの監視に加えてローカルのディスク(要するにOSとか入ってるディスク)も監視してしまおう。
   # diskd起動設定
   # ローカルディスク監視用(write)
respawn root /usr/lib64/heartbeat/diskd -w -d /tmp -a diskcheck_status -i 10
   # 共有ディスク監視用(read)
respawn root /usr/lib64/heartbeat/diskd -N /dev/mapper/mpcontents001 -a diskcheck_status -i 10

 詳しいことはdiskdのページを見てもらうとして、上記の例では1行目に内蔵ディスクの監視、2行目に共有ディスクの監視を設定した。
 なお、共有ディスクを監視する場合、くれぐれも「-w」オプションを設定したりしませんように!!!!!理由は判るよね!?

⑧cib.xmlに「diskd」の監視設定を追記(両方のサーバで実施)
 そして、再度鬼門のcib.xmlに戻る。(笑)

 今度は、「constraints」ディレクティブブロックを記述する。もう面倒臭いので一気にばーっと示してしまう。(笑)

<constraints>
<rsc_location id="rule_internal_disk" rsc="nfs_service">
<rule id="prefered_rule_internal_disk" score="-INFINITY" boolean_op="and">
<expression attribute="diskcheck_status" id="internal_disk_check1" operation="defined"/>
<expression attribute="diskcheck_status" id="internal_disk_check2" operation="eq" value="ERROR"/>
</rule>
</rsc_location>
<rsc_location id="rule_shared_disk" rsc="nfs_service">
<rule id="prefered_rule_shared_disk" score="-INFINITY" boolean_op="and">
<expression attribute="diskcheck_status" id="shared_disk_check1" operation="defined"/>
<expression attribute="diskcheck_status" id="shared_disk_check2" operation="eq" value="ERROR"/>
</rule>
</rsc_location>
</constraints>

 上側の緑色の塊は内蔵ディスクの監視設定、下側のオレンジ色の塊は共有ディスクの監視設定だ。
 ちょっとこのあたりはまだ調査がろくすっぽ進んでいないので、詳しい内容はよく判っていない!!そのうち調査したらまとめておこう。(期限は約束できないがな!!:笑)

 では、heartbeatを起動してみよう!!

 heartbeatカモン!!!!!
Defaulting to one-shot mode
You need to have curses available at compile time to enable console mode


============
Last updated: Mon Feb 14 18:57:49 2011
Current DC: nfs001.mycompany.com (47e72b74-****-****-****-18077e2dcd57)
2 Nodes configured.
1 Resources configured.
============

Node: nfs002.mycompany.com (6a838508-****-****-****-72e755b88326): online
Node: nfs001.mycompany.com (47e72b74-****-****-****-18077e2dcd57): online

Resource Group: nfs_service
    ipaddr      (heartbeat::ocf:IPaddr):        Started nfs002.mycompany.com
    lvm (heartbeat::ocf:LVM):   Started nfs002.mycompany.com
    filesystem  (heartbeat::ocf:Filesystem):    Started nfs002.mycompany.com

 キター!!!

 喜びの余りお腹がすいてきたので今日はこのへんで!!!!!

 次回はクラスタギッタンバッコンを軽く試してみた後で、NFSサーバとして調きょ…仕込むぜ!!

Linuxでクラスタ~heartbeatを試す(そして苦しむ)~その1 [Linux(CentOS/VineLinux)]

 確か、このblogが個人的に(ry

 で、以下本編。

 むか~しむかし(でもないけど)、あるところに(具体的にはhp)、「Service Guard for Linux」(以下「SGLX」と記述)というクラスタソフトがあったそうな。
 お爺さんは山へ(ry

 じゃない。そのSGLXが2009年に…
 あんまり売れないから、もう開発や~めた!サポートもそのうち終了するよ~ん!
 ということになったそうな。

 お爺さんとお婆さんは大層、困ったそうな。

 あるとき、お婆さんが川に洗濯にいくと、川の上流から、陽気なホモが(マテ
 じゃない、大桃美代子が(コラ
 じゃない、大きな桃が どんぶらこ~どんぶらこ~と流れてきたそうな。

 お婆さんは桃を持ち帰ると、中から「Heartbeat」という、クラスタソフトが出てきたそうな…

 というわけで、会社でhp製のサーバにhp製のクラスタソフトを導入していたんだけども、hpがかくのごとく通知をしてきたので、
  選択肢その1:最後まで使い切る
  選択肢その2:乗り換える。(ClusterProとか?)
 と、悩んでいたですよ。
 で、「Heartbeat」があるって事がわかったので、いっちょコイツを試してみようか!ということに。(笑)

 ちょうどいま、そのクラスタ構成のサーバが開店休業中で好き勝手にできるという幸運(?)が重なったため、好き勝手することにした。








 だがしかし。道のりはつらく苦しいものとなったのであった。(血涙)
 そしてその現在コレを書いている時点でもまだ道のりは半ばなのであってまだ完成を見ていないのであった。(滝涙)



 敢えて拾わん!火中の栗を!!


 をテーマに、元気良くがんばって逝きたいとおもいます。(笑)

 さて、今回ここで私が「好き勝手」する環境を以下に示そう。
ClusterServer01.png
 てな具合。豪華すぎるシステムだ!(笑)
 サーバは大量のデータを格納するためのNFSサーバって感じで、ファイバーチャネル接続されたディスクの塊がある。FCのカードも経路もストレージサーバ側のコントローラも全て二重化されており(もちろんサーバも!)、サーバから見るとストレージサーバ上にあるディスクは同じものが都合4個見えるという寸法だ。(笑)これはmultipathdを使用してdevice mapper multipathの機能により1個のディスクに見えるように仕立てる必要がある。

 一方、サーバのクラスタ動作についてはHeartbeatを使用し、
  1:VIPの管理
  2:共有ディスクの管理
  3:NFSデーモンの管理

 を担当させることとなる。

 それでは、さっそく両サーバのセットアップから。
① とにかくOSのインストールから。ここではCentOS 5.5 x86_64を使用した。
② パッケージのアップデート、必要なパッケージ類のインストール
③ (hp製サーバなので…)hp製のドライバやらサポートユーティリティ類のインストール
④ 共有ディスクの作成
⑤ device mapper multipath の設定
⑥ いよいよHeartbeatのインストール
⑦ Heartbeatの初期設定(~VIPの設定まで)

 この辺から手をつけよう。

① とにかくOSのインストール
 OSをインストールする。「クラスタシステム」ということもあり、サーバのハードウェア構成はもちろんのこと、ディスクの切り方等も同一にしておこう。まあ、Heartbeat的には、厳密に一緒じゃなくても問題なく動く。
 OSのインストールで他に気をつけるべきことは無いし、常識的なセットアップならまあ大丈夫だろうと思うので、ここでは具体的手順は省略する。
 なお、インストールパッケージはBaseのみを選択したことを付け加えておく。

② パッケージのアップデート、必要なパッケージ類のインストール
 サーバが起動したら、IPv6の無効化とか(必要なら)言語設定とかそういうのを実施。
 続いて yum -y update でパッケージ類のアップデートを実行。

 クラスタシステムを構築する以上、両サーバの時計の一致が非常に重要になってくる。よって、
 yum -y install ntp
 として、ntpを忘れずにインストールする。

 追加でインストールするパッケージだが、hp製のドライバとかサポートユーティリティをインストールするため
 yum -y install compat-libstdc++-296 libnl gcc kernel-devel kernel-headers rpm-build net-snmp

 あと、共有ディスクをxfsで使ってみようと思ったのでxfsがらみのパッケージをインストール
 yum -y install xfsdump xfsprogs kmod-xfs
 ext3でいくなら↑はいらないし、ext4ならそちらで必要なパッケージをインストールすることになろう。

③ (hp製サーバなので…)hp製のドライバやらサポートユーティリティ類のインストール
 ここは省略。IBMのサーバならIBMの、DELLのサーバならDELLの、NECのサーバならNECの、富士通のサーバなら富士通の、あとなんだっけw

④ 共有ディスクの作成
 ここも省略する。ストレージサーバ側で共有ディスクを作成する。
 まあ、ケースによってはWWNをメモしとけとかLUNをメモしとけとかあるかもしれないね。

⑤ device mapper multipath の設定
 multipathdの設定を行う。
 まずサーバ側のFCインタフェースからストレージ側のWWNが見えないことにはどうしようもないので、FCインタフェースに付属のツールを使うなりして、WWNの再取得を行う。…か、サーバを再起動してしまう。(笑)

 編集するのは /etc/multipath.conf で、デフォルトのままだと全てのパスをマルチパス設定しないことになっている。
 極論すると、
defaults {
        user_friendly_names yes
}

 だけ記述されていればだいたい問題になることはない。(笑)
 心配性な人は
blacklist {
        devnode "c0d0.*"
}

defaults {
        user_friendly_names yes
}

multipaths {
        multipath {
                wwid                    36001438005**********900000860000
                user_friendly_names     yes
                path_grouping_policy    failover
                alias                   mpcontents001
        }
}

 みたいに書いておく。
 「blacklist」のブロックは、multipathdによる管理の対象から外したいデバイスについて記述する。ここではhp製サーバなので、「/dev/cciss/c0d0t?」はmultipathdの管理対象から外しておこうという記述にしている。(書かなくてもここはちゃんと判断してくれるけども…)

 「multipaths」のブロックには、multipathdによって束ねたいデバイスを指定する。
 WWN(WWID)が同一なものは全て同じディスクであるので、ここでは「wwid」単位に束ねるようにしている。
 「multipath」のブロック(s無し)に個々のディスク・パスについて記述するが、上記の例ではWWNは「36001438005**********900000860000」のものについて、別名「mpcontents001」というのを定義している。この定義が無ければ、定義された順番に「dm-?」みたいな名前が付く。一方ここで別名を定義しておくと、定義された順番に関係なく同じデバイス名(別名)が使用できるようになる。上記の例では

 /dev/mapper/mpcontents001

 という名前で共有ディスクにアクセスできることとなる。共有ディスクが1個しか無いようなケースではとりたてて別名定義をする意味は大きくないが、複数存在する場合は別名定義をしておくことを強くオススメしたい。

 設定したら

 chkconfig multipathd on
 service multipathd start

 としてデーモンを起動&自動起動設定しよう。うまくいけば、上記の別名がlsコマンドで確認できたり、あとは

 multipath -ll

 を実行して状態が確認できる。

⑥ いよいよHeartbeatのインストール
 では、Heartbeatのインストールを行う。必要なパッケージ類はheartbeat heartbeat-pils heartbeat-stonith の3個だが、だからといって yum install heartbeat heartbeat-pils heartbeat-stonith と実行しても、
heartbeatのインストールでエラーになる。
 先人達の貴重な情報によれば、yum install heartbeat-pils heartbeat-stonith を実行してからheartbeatをインストールすればよいとのこと。

 まあぶっちゃけ、yum -y install heartbeat heartbeat-pils heartbeat-stonithを2回実行してしまっても…(笑)

⑦ Heartbeatの初期設定(~VIPの設定まで)
 まず、 /etc/ha.d/ha.cfを作成する。ha.cfについてはそこらじゅうのサイトで説明されているので細かい説明はここでは省略する。
 なお、respawnディレクティブでpingdを起動する設定を導入する際、32ビット版OSの場合は/usr/lib/heartbeat/pingdになるが、64ビット版OSの場合は/usr/lib64/heartbeat/pingdになるので要注意。よくあるサンプルをコピペするだけだとここで最初に躓く。(笑)

 続いて /etc/ha.d/authkeys を作成する。ぶっちゃけ
auth    1
1 sha1 password_hogehoge

 とかやっとけばおk。パスフレーズは何でも構わない。

 続いて、Heartbeat最大の難物、 /var/lib/heartbeat/crm/cib.xml だ。(笑)ちなみにこのファイルは32ビット版だろうと64ビット版だろうと「lib」の部分は変わらないので念のため。

 cib.xmlは、クラスタ・リソース・マネージャに関する設定を事細かに記述するファイルであるが、最初の「雛形」は自動生成することができるので、まずはその機能を利用しよう。
 heartbeatを起動すればよい。

 service heartbeat start

 ha.cfとかが問題なく用意されていればこれで起動出来る。
 cib.xmlには大きく分けて4つのカテゴリが用意されており、
  crm_config
  nodes
  resources
  constraints
 のうち、上の二つ「crm_config」と「nodes」について必要最低限の情報が自動作成される。
 あとはresourcesとconstraintsに情報を追加すれば終了ということになる。

 まずは、クラスタシステムが使うVIPを設定してみる。
 最低限必要な情報は次の3つ。
  ・IPアドレス
  ・IPアドレスを割り付けるNICのインタフェース名
  ・ネットマスク
 すぐに用意できる情報だろう。

 それでは、この情報をcib.xmlに記述する。まったくクールでない、手書きの方法で紹介するのでお付き合いいただきたい。(大笑)

 あ、まずheartbeatを停止しておくように。
 service heartbeat stop だ。
 なお、停止する際ものすご─────────く時間がかかることがある。あわててCtrl+Cしてしまわないように。(笑)気長に待つべし。

⑦-1:「<resource />」タグを書き換える
 <resource />タグが1個だけ記述されているので、これを

<resource>
</resource>

 という具合に書き換える。以降の追記はこの2つのタグの間に挟みこむように行う。

⑦-2:「<group>」タグを追加する
 必須ではないが、<group>タグを追加することをオススメする。グループ指定したリソースは記述された順に従って処理が行われる…らしい。同時に行われては困る処理(例えば、LVMを活性状態にしてからマウントするとか)は<group>タグで囲んでおく。

<resource>
<group id="適当な名前">
</group>
</resource>

 なお、<group>タグにid=でリソースグループに名前をつけることができる。後から見て判るように適切な名前を付けておこう。

⑦-3:「<primitive>」タグを記述する
 <primitive> でいよいよリソースの記述に入る。このタグにはオプション(と言っていいのか?)を指定する。
 <primitive id="リソースの名前" class="使用するフレームワーククラス名" type="使用するコマンド" provider="heartbeat">

 「リソースの名前」には何か適切な名前をつけておく。VIPの定義をするのだから、「IP Address」とかそれっぽい名前で。
 「使用するフレームワーククラス名」とは、リソース管理のために使うユーティリティみたいな物があり、それを記述する。ここでは、Open Cluster Frameworkというものを使用するので、「ocf」と記述する。
 「使用するコマンド」とは、リソースを登録するために用いられるプログラム(やらスクリプトやら…)を指定する。ocfでIPアドレスを追加登録する場合、「IPaddr」を用いる。なお、ocfの場合は/usr/lib/ocf/resource.d/heartbeatにさまざまなスクリプトが置かれているが、ここにあるスクリプトを「type=」の部分に記述して使用する。

 そんな訳で、クラスタシステムのVIPを追加したい場合は

<resource>
<group id="nfs_server">
<primitive id="ip_address" class="ocf" type="IPaddr" provider="heartbeat">
</primitive>
</group>
</resource>

 と、いうことになろう。

⑦-4:「<instance_attributes>」タグと「<attributes>」を記述する。
 <instance_attributes>タグを記述する。コレはいまいち判っていないが、まあ魔法の呪文だと思って書いておいてくれたまえ。。。。
 なお、id= で適当な名前が付けられるのでつけておくとよい模様。
 <attributes>タグも呪文だと思ってついでに書いておいて欲しい。こちらはid= タグは用いないみたいだ。

<resource>
<group id="nfs_server">
<primitive id="ip_address" class="ocf" type="IPaddr" provider="heartbeat">
<instance_attributes id="ia_ipaddr">
<attributes>
</attributes>
</instance_attributes>
</primitive>
</group>
</resource>

⑦-5:「<nvpair>」タグで定義情報を角
 やっと定義情報本体が記述できる。まずはタグの記述方法から見ておこう。

 <nvpair id="適当な名前" name="引数名" value="設定値" />

 このタグは>の前に「/」が必要な模様。詳しいことはXMLの達人にでも聞いてください。(笑)
 さて、この<nvpair>タグで必要な情報を設定するが、「引数名」については<primitive>タグで記述したフレームワークなりコマンドなりによって必要とされるパラメータが異なるが、ひとまずここでは以下の3つを使用してVIPの定義を行う。

 「ip」 にVIPのIPアドレスを記述する。 (例) 172.16.42.1
 「nic」 にVIPの割付を行うNICのデバイス名を記述する。 (例) eth4
 「cidr_netmask」 にVIPの所属するネットワークのネットマスクを記述する。 (例) 255.255.252.0

 では、これを書き並べてみよう。

<resource>
<group id="nfs_server">
<primitive id="ip_address" class="ocf" type="IPaddr" provider="heartbeat">
<instance_attributes id="ia_ipaddr">
<attributes>
<nvpair id="ia_ipaddr_ip" name="ip" value="172.16.42.1">
<nvpair id="ia_ipaddr_nic" name="nic" value="eth4">
<nvpair id="ia_ipaddr_netmask" name="cidr_netmask" value="255.255.252.0">
</attributes>
</instance_attributes>
</primitive>
</group>
</resource>

 このcib.xmlはクラスタシステムの両サーバに配置する。(ha.cfもauthkeysもだけどね)
 なお、/var/lib/heartbeat/crm のディレクトリ内にcib.xml以外のファイルが作成されることもある。
[root@nfs001 crm]# pwd
/var/lib/heartbeat/crm
[root@nfs001 crm]# ls -la
合計 24
drwxr-x--- 2 hacluster haclient 4096  2月 10 15:38 .
drwxr-xr-x 5 root      root     4096  2月 10 15:33 ..
-rw------- 2 hacluster haclient 2587  2月 10 15:38 cib.xml
-rw------- 2 hacluster haclient 2587  2月 10 15:38 cib.xml.last
-rw-r--r-- 2 hacluster haclient   32  2月 10 15:38 cib.xml.sig
-rw-r--r-- 2 hacluster haclient   32  2月 10 15:38 cib.xml.sig.last

 この場合、heartbeatの停止を確認してから、cib.xml以外のファイルは削除すること。(cib.xmlまで消さないように!w)

 では、heartbeatを起動してみよう!!両サーバ共に起動すると…
Defaulting to one-shot mode
You need to have curses available at compile time to enable console mode


============
Last updated: Thu Feb 10 17:45:43 2011
Current DC: nfs002.mycompany.com (6a838508-****-****-****-72e755b88326)
2 Nodes configured.
1 Resources configured.
============

Node: nfs002.mycompany.com (6a838508-****-****-****-72e755b88326): online
Node: nfs001.mycompany.com (47e72b74-****-****-****-18077e2dcd57): online

Resource Group: nfs_service
    ipaddr      (heartbeat::ocf:IPaddr):        Started nfs002.mycompany.com



 キター!!!!
メッセージを送る