ラベル GNBD の投稿を表示しています。 すべての投稿を表示
ラベル GNBD の投稿を表示しています。 すべての投稿を表示

2008/03/17

Red Hat Cluster: GNBD, CLVM and GFS・その10・考察と予告

今まで調査・実証してきた『GNBD, CLVM and GFS』について軽く考察してみたい。

今回の調査で、CentOS 5.1およびConga(Red Hat Cluster, Luci & Ricci)を用いて、GNBDをバックエンドとするクラスタ論理ボリューム(logical volume, LV)上でGFSを利用したファイル共有を実現できることが判った。ただし以下の点に注意する必要があった。
  1. GNBDには、起動スクリプト(init script)が準備されていない(『5・GNBDの設定』)。
  2. CongaはGNBDによるブロックデバイスを認識しない(『その8・Congaからの設定』)。
また、カーネルのバージョンによっては、うまく動かない場合もあったことを付け加えたい。

その後の検証で、次のことも判った。
  1. GNBDをバックエンドとすると、device-mapper multipath (DM-MP)を構成できない。
GNBDクライアントは、同一GNBD名のブロックデバイスを複数インポートできない。GNBDサーバは、どのネットワークインターフェースに対しても、同一GNBD名でブロックデバイスをエクスポートする。つまり、GNBDクライアント・サーバが複数のネットワークインターフェースを持っていてもこれを有効に活用することができない(汚い技を使えば可能かもしれないが)
ただし、一つのストレージに複数のホストバスアダプタを付け、複数のGNBDサーバから同一のブロックデバイスを異なる名前でエクスポートすれば、GNBDをバックエンドとするDM-MPを構成することは可能。この場合は、それなりのハードウェアが必要だし、設定も複雑になる。

そこで次は、iSCSI、DM-MP、CLVMおよびGFSを使ったファイル共有について検証したい。バックエンドにiSCSIを使う場合、サーバ側で同一デバイスを複数のネットワークインターフェースからエクスポートし、クライアント側でそれらを複数のインターフェースから別々にインポートすることが可能。また、これをDM-MPで扱うことも容易。
乞うご期待。

解説: その1その2その3
kernel-xenにバグか?
その4・CentOS 5.1での注意点
その5・GNBDの設定
その6・CLVMの設定
その7・GFS2の設定
その8・Congaからの設定
その9・ベンチマーク
その10・考察と予告

2008/03/11

Red Hat Cluster: GNBD, CLVM and GFS・その4・CentOS 5.1での注意点・補足

Red Hat Cluster: GNBD, CLVM and GFS・その4・CentOS 5.1での注意点』で、
現時点(2008/2/28)の最新版kernel-xen-2.6.18-53.1.13.el5およびkmod-gnbd-xen-0.1.4-12.el5をXen DomUで使うと、CPU負荷が異常に高くなるバグがある。
と書いたが、新しくリリースされたkernel-xen-2.6.18-53.1.14.el5ではこの問題が発生しない。
このカーネルに対するErrata、RHSA-2008:0154-15にはそれらしい記述がなく、原因は不明。

2008/03/07

Red Hat Cluster: GNBD, CLVM and GFS・その9・ベンチマーク

GNBD, CLVM and GFS・その8・Congaからの設定』までに構築した環境で、ファイルシステムの性能を測定する。測定に用いたのは、『CentOS用bonnie++のRPMを準備する』で作ったbonnie++のRPM。これをdc2およびfs1にインストール、測定した。
なお、今回の環境は、Xen Dom0がGNBDサーバで、Xen DomUがGNBDクライアントという特殊な環境のため、これをもってGFS・CLVM・GNBDの一般的な性能を推し量るのは不適切だ。あくまでも一つの参考として欲しい。何故なら、一般には、GNBDのサーバ=クライアント間や、GFS・CLVMを共有しているクラスタメンバ間の通信は、GbEなどの普通のネットワークだからだ。GNBDのサーバ=クライアントが同一CPU上で実行されるのも特殊なケースだ。


Sequential Output
Per Char Block Rewrite
K/sec %CPU K/sec %CPU K/sec %CPU
dc2 GFS/DomU 149 97 10,951 7 5,209 2
Latency msec 89.556 7,177.000 2,478.000
dc2 ext3/DomU 382 97 36,096 10 16,275 1
Latency msec 49.878 309.000 164.000
fs1 ext3/Dom0 96 98 40,998 23 22,036 5
Latency msec 176.000 1,788.000 812.000



Sequential Input
Per Char Block
K/sec %CPU K/sec %CPU
dc2 GFS/DomU 866 96 9,921 1
Latency msec 36.535 240.000
dc2 ext3/DomU 871 98 32,478 0
Latency msec 25.578 55.655
fs1 ext3/Dom0 169 97 62,977 4
Latency msec 159.000 22.596




Random Seeks
files/sec % CPU
dc2 GFS/DomU 233 15
Latency msec 690.000
dc2 ext3/DomU 729 1
Latency msec 49.561
fs1 ext3/Dom0 674 8
Latency msec 125.000



Sequential Create
Create Read Delete
files/sec %CPU files/sec %CPU files/sec %CPU
dc2 GFS/DomU 421 8 330 1 202 1
Latency msec 1,028.000 81.737 216.000
dc2 ext3/DomU 20,319 81 105,155 74 39,305 83
Latency msec 10.467 30.169 0.422
fs1 ext3/Dom0 16,480 76 169,230 90 25,541 82
Latency msec 8.949 0.777 0.710




Random Create
Create Read Delete
files/sec %CPU files/sec %CPU files/sec %CPU
dc2 GFS/DomU 401 9 441 1 286 2
Latency msec 1,262.000 167.000 189.000
dc2 ext3/DomU 22,212 88 223,847 92 39,049 81
Latency msec 0.648 0.403 0.479
fs1 ext3/Dom0 16,482 73 155,919 98 26,283 84
Latency msec 6.643 0.805 0.387


解説: その1その2その3
kernel-xenにバグか?
その4・CentOS 5.1での注意点
その5・GNBDの設定
その6・CLVMの設定
その7・GFS2の設定
その8・Congaからの設定
その9・ベンチマーク
その10・考察と予告

2008/03/05

Red Hat Cluster: GNBD, CLVM and GFS・その8・Congaからの設定

前回『Red Hat Cluster: GNBD, CLVM and GFS・その7・GFS2の設定』までで、一通りの手順を説明したが、これはコマンドラインからの設定だった。これをConga (Luci & Ricci)から設定する。

まず、CongaはGNBDを理解しないことに注意しよう。例えば、あるマシンをGNBDサーバ・クライアントを設定できない。従って、GNBDサーバ・クライアントの設定は、『Red Hat Cluster: GNBD, CLVM and GFS・その5・GNBDの設定』の通り行う必要がある。
また、GNBDクライアントにインポートされているGNBDデバイスをディスクとして認識しない(少なくともCentOS 5.1の現バージョンでは)。従って、CongaからGNBDによりインポートしたブロックデバイスを物理ボリューム(physical volume, PV)として設定できない。Conga上での作業を始める前に、『Red Hat Cluster: GNBD, CLVM and GFS・その6・CLVMの設定』に従って、当該ブロックデバイスをPVとして設定する必要がある。

では、実際に作業してみよう。既に、fs1をGNBDサーバ、dc[123]をGNBDクライアントとして設定済みとする。『Red Hat Cluster: CentOS 5.1上でRHCSを使ってみる・その6・クラスタcDom0sの生成』に従い、Luci管理画面にログインした後、[storage」タブを選択する。
GNBDクライアントdc1.xenclusterを選択する。
GNBDでインポートされたデバイス、/dev/gnbd0が認識されていないことに注意。念のため、[Reprobe Storage]を押下し、再確認させる。「Probing Storage」画面が表示された後、元の画面に戻る。
再確認させても/dev/gnbd0が認識されていない。
ここで、/dev/gnbd0をコマンドラインからPVとして設定する。この作業は、dc[123]の内のいずれから行う。
[root@dc1 ~]# pvcreate /dev/gnbd0
Physical volume "/dev/gnbd0" successfully created
[root@dc1 ~]#
再びLicciの画面に戻り、[storage]タブ→[dc1.xencluster]→[Volume Groups]→[New Volume Group]を選択する。[Select 1 Physical Volume]の欄に、/dev/gnbd0が現れているのが解る。
この画面に対して、[Volume Group Name]にVGcDomUs00を入力、[Extent Size]に32MB、[Clustered]にtrueを選択し、[Select 1 Physical Volume]の欄で/dev/gnbd0をチェックした後、[Create]ボタンを押下する。確認のダイアログが表示される。[OK]ボタンを押下する。進行状況を表示する画面の後、VGcDomUs00の画面が表示される。この画面の下の[New Volume Group]ボタンを押下し、新規ボリュームグループLVGFS00を作成する。この画面に対して、[Logical Volume Name]にLVGFS00を入力、[Conent]にGlobal FS v.2を選択、[Unique GFS Name]にGFS00、[Mountpoint]に/mnt/gfs00を入力、[Mount]および[List in /etc/fstab]を共にtrueを選択、[Number Of Journals]に3を入力後、[Create]ボタンを押下する。確認のダイアログが表示される。[OK]ボタンを押下すると、進行状況表示に続き、元の画面が表示される。この途中で、dc1のコンソールには、次のようなエラーが表示される。
Traceback (most recent call last):
File "/usr/lib/python2.4/site-packages/setroubleshoot/analyze.py", line 370, in auto_save_callback
self.save()
File "/usr/lib/python2.4/site-packages/setroubleshoot/analyze.py", line 351, in save
self.sigs.write_xml('sigs', self.filepath)
File "/usr/lib/python2.4/site-packages/setroubleshoot/signature.py", line 570, in write_xml
f.write(self.get_xml_text_doc(obj_name))
File "/usr/lib/python2.4/site-packages/setroubleshoot/signature.py", line 529, in get_xml_text_doc
doc = self.get_xml_doc(obj_name)
File "/usr/lib/python2.4/site-packages/setroubleshoot/signature.py", line 524, in get_xml_doc
root = self.get_xml_nodes(doc, obj_name)
File "/usr/lib/python2.4/site-packages/setroubleshoot/signature.py", line 599, in get_xml_nodes
list.addChild(item.get_xml_nodes(doc, item_name))
File "/usr/lib/python2.4/site-packages/setroubleshoot/signature.py", line 625, in get_xml_nodes
root.newChild(None, name, value)
File "/usr/lib/python2.4/site-packages/libxml2.py", line 3217, in newChild
ret = libxml2mod.xmlNewChild(self._o, ns__o, name, content)
TypeError: xmlNewChild() argument 4 must be string without null bytes or None, not str
設定は正しく行われているようだ。
[root@dc1 ~]# lvs
LV       VG         Attr   LSize   Origin Snap%  Move Log Copy%
LVGFS00  VGcDomUs00 -wi-ao   3.94G             
LogVol00 VolGroup00 -wi-ao   3.34G             
LogVol01 VolGroup00 -wi-ao 544.00M             
[root@dc1 ~]# vgs
VG         #PV #LV #SN Attr   VSize VFree
VGcDomUs00   1   1   0 wz--nc 3.97G 32.00M
VolGroup00   1   2   0 wz--n- 3.88G     0
[root@dc1 ~]# pvs
PV         VG         Fmt  Attr PSize PFree
/dev/gnbd0 VGcDomUs00 lvm2 a-   3.97G 32.00M
/dev/xvda2 VolGroup00 lvm2 a-   3.88G     0
[root@dc1 ~]# mount
/dev/mapper/VolGroup00-LogVol00 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/xvda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
none on /sys/kernel/config type configfs (rw)
/dev/mapper/VGcDomUs00-LVGFS00 on /mnt/gfs00 type gfs2 (rw,hostdata=jid=0:id=196611:first=1)
[root@dc1 ~]# cat /etc/fstab
/dev/VolGroup00/LogVol00 /                       ext3    defaults        1 1
LABEL=/boot             /boot                   ext3    defaults        1 2
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
/dev/VolGroup00/LogVol01 swap                    swap    defaults        0 0
/dev/VGcDomUs00/LVGFS00 /mnt/gfs00 gfs2 defaults 0 0
[root@dc1 ~]#
このとき、他のノード上からも、LVGFS00やVGcDomUs00を確認できる。
[root@dc2 ~]# lvs
LV       VG         Attr   LSize   Origin Snap%  Move Log Copy%
LVGFS00  VGcDomUs00 -wi-a-   3.94G              
LogVol00 VolGroup00 -wi-ao   3.34G              
LogVol01 VolGroup00 -wi-ao 544.00M              
[root@dc2 ~]# vgs
VG         #PV #LV #SN Attr   VSize VFree
VGcDomUs00   1   1   0 wz--nc 3.97G 32.00M
VolGroup00   1   2   0 wz--n- 3.88G     0
[root@dc2 ~]# pvs
PV         VG         Fmt  Attr PSize PFree
/dev/gnbd0 VGcDomUs00 lvm2 a-   3.97G 32.00M
/dev/xvda2 VolGroup00 lvm2 a-   3.88G     0
[root@dc2 ~]# 
ただし、マウントされていないので、LVGFS00のoフラグが立っていないことに注意。
続いて、残りのノードdc[23]に対して、LVGFS00をマウントするよう設定する。Luci管理画面から、[storage]タブを選び、残りのノードを選択する。このとき、上の様にVGcDomUs00が表示されない場合があるかもしれない。その場合は、[Reprobe Storage]ボタンを押下して、認識させる。
[VGcDomUs00]→[Logical Volumes]→[LVGFS00]を選択する。
[Mountpoint]および[/etcfstab Mountpoint]に共に/mnt/gfs00を入力し、[Apply]ボタンを押下する。確認のダイアログが表示される。[OK]ボタンを押下すると、進行状況が表示された後、VGcDomUs00の画面が表示される。このときも、dc1のときと同様の「Tracebak…」というメッセージが表示されるが、正しく設定されているようだ。
[root@dc2 ~]# lvs
LV       VG         Attr   LSize   Origin Snap%  Move Log Copy%
LVGFS00  VGcDomUs00 -wi-ao   3.94G                     
LogVol00 VolGroup00 -wi-ao   3.34G                     
LogVol01 VolGroup00 -wi-ao 544.00M                     
[root@dc2 ~]# vgs
VG         #PV #LV #SN Attr   VSize VFree
VGcDomUs00   1   1   0 wz--nc 3.97G 32.00M
VolGroup00   1   2   0 wz--n- 3.88G     0
[root@dc2 ~]# pvs
PV         VG         Fmt  Attr PSize PFree
/dev/gnbd0 VGcDomUs00 lvm2 a-   3.97G 32.00M
/dev/xvda2 VolGroup00 lvm2 a-   3.88G     0
[root@dc2 ~]# mount
/dev/mapper/VolGroup00-LogVol00 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/xvda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
none on /sys/kernel/config type configfs (rw)
/dev/mapper/VGcDomUs00-LVGFS00 on /mnt/gfs00 type gfs2 (rw,hostdata=jid=1:id=196611:first=0)
[root@dc2 ~]# 
マウントされたため、LVGFS00のoフラグが立ったことに注意。

解説: その1その2その3
kernel-xenにバグか?
その4・CentOS 5.1での注意点
その5・GNBDの設定
その6・CLVMの設定
その7・GFS2の設定
その8・Congaからの設定
その9・ベンチマーク
その10・考察と予告

2008/03/03

Red Hat Cluster: GNBD, CLVM and GFS・その6・CLVMの設定・補足

Red Hat Cluster: GNBD, CLVM and GFS・その6・CLVMの設定』の補足。
GNBDクライアント側(今回の場合ではdc[123])で、エクスポートされたGNBD上に論理ボリューム(logical volume, LV)を作成すると、GNBDサーバ側(同fs1)でも同じ物理ボリューム(physical volume, PV)やボリュームグループ(volume group, VG)が認識される。
[root@fs1 ~]# lvs
LV            VG         Attr   LSize  Origin       Snap%  Move Log Copy%
LVGFS00       VGcDomUs00 -wi-a-  4.00G
LogVol00      VolGroupXX -wi-ao 10.00G
LogVol01      VolGroupXX -wi-ao  1.94G
LogVolDc0     VolGroupXX -wi-a-  4.00G
LogVolDc1     VolGroupXX swi-a-  1.00G LogVolDc1v00  14.99
LogVolDc1v00  VolGroupXX owi-a-  4.00G
LogVolDc2     VolGroupXX swi-a-  1.00G LogVolDc2v00   8.14
LogVolDc2v00  VolGroupXX owi-a-  4.00G
LogVolDc3     VolGroupXX swi-a-  1.00G LogVolDc3v00   8.16
LogVolDc3v00  VolGroupXX owi-a-  4.00G
LogVolGNBD01  VolGroupXX -wi-ao  4.00G
LogVoliSCSI01 VolGroupXX -wi-a-  1.00G
[root@fs1 ~]# vgs
VG         #PV #LV #SN Attr   VSize   VFree
VGcDomUs00   1   1   0 wz--nc   4.00G     0
VolGroupXX   1   8   3 wz--n- 135.47G 99.53G
[root@fs1 ~]# pvs
PV                           VG         Fmt  Attr PSize   PFree
/dev/VolGroupXX/LogVolGNBD01 VGcDomUs00 lvm2 a-     4.00G     0
/dev/sda2                    VolGroupXX lvm2 a-   135.47G 99.53G
[root@fs1 ~]#
このままでも、これらのデバイスをfs1上で使用しなければ問題ない。が、安全のためには、これらがfs1上で認識されないようにした方がよい。論理ボリュームマネージャ(logical volume manager, LVM)は、設定ファイル/etc/lvm/lvm.confの設定に従ってデバイスファイルを走査する。特定のブロックデバイスをこの走査から除外するには、フィルタの設定を変更する。GNBDでエクスポートするLVをLogVolNN(および、iSCSIでエクスポートするLVをLogVoliSCSINN)とする場合、以下の通り設定する。
[root@fs1 ~]# cd /etc/lvm
[root@fs1 lvm]# cp -p lvm.conf lvm.conf.orig
[root@fs1 lvm]# sed 's/\(^ *filter = \[ "\).*\(" \]\)/\1r!LogVol(GNBD|iSCSI)!\2/' < lvm.conf.orig > lvm.conf
[root@fs1 lvm]#
続いて、vgscanを実行し、VGcDomUs00が認識されないことを確認する。
[root@fs1 lvm]# vgscan
Reading all physical volumes.  This may take a while...
Found volume group "VolGroupXX" using metadata type lvm2
[root@fs1 lvm]# lvs
LV            VG         Attr   LSize  Origin       Snap%  Move Log Copy%
LogVol00      VolGroupXX -wi-ao 10.00G
LogVol01      VolGroupXX -wi-ao  1.94G
LogVolDc0     VolGroupXX -wi-a-  4.00G
LogVolDc1     VolGroupXX swi-a-  1.00G LogVolDc1v00  15.01
LogVolDc1v00  VolGroupXX owi-a-  4.00G
LogVolDc2     VolGroupXX swi-a-  1.00G LogVolDc2v00   8.15
LogVolDc2v00  VolGroupXX owi-a-  4.00G
LogVolDc3     VolGroupXX swi-a-  1.00G LogVolDc3v00   8.17
LogVolDc3v00  VolGroupXX owi-a-  4.00G
LogVolGNBD01  VolGroupXX -wi-ao  4.00G
LogVoliSCSI01 VolGroupXX -wi-a-  1.00G
[root@fs1 lvm]# vgs
VG         #PV #LV #SN Attr   VSize   VFree
VolGroupXX   1   8   3 wz--n- 135.47G 99.53G
[root@fs1 lvm]# pvs
PV         VG         Fmt  Attr PSize   PFree
/dev/sda2  VolGroupXX lvm2 a-   135.47G 99.53G
[root@fs1 lvm]#
OSを再起動しても認識されないことを確認する。
[root@fs1 lvm]# shutdown -r now
<<略>>
INIT: version 2.86 booting
Welcome to  CentOS release 5 (Final)
Press 'I' to enter interactive startup.
<<略>>
[root@fs1 ~]# lvs
LV            VG         Attr   LSize  Origin       Snap%  Move Log Copy%
LogVol00      VolGroupXX -wi-ao 10.00G
LogVol01      VolGroupXX -wi-ao  1.94G
LogVolDc0     VolGroupXX -wi-a-  4.00G
LogVolDc1     VolGroupXX swi-a-  1.00G LogVolDc1v00  15.01
LogVolDc1v00  VolGroupXX owi-a-  4.00G
LogVolDc2     VolGroupXX swi-a-  1.00G LogVolDc2v00   8.15
LogVolDc2v00  VolGroupXX owi-a-  4.00G
LogVolDc3     VolGroupXX swi-a-  1.00G LogVolDc3v00   8.17
LogVolDc3v00  VolGroupXX owi-a-  4.00G
LogVolGNBD01  VolGroupXX -wi-a-  4.00G
LogVoliSCSI01 VolGroupXX -wi-a-  1.00G
[root@fs1 ~]# vgs
VG         #PV #LV #SN Attr   VSize   VFree
VolGroupXX   1   8   3 wz--n- 135.47G 99.53G
[root@fs1 ~]# pvs
PV         VG         Fmt  Attr PSize   PFree
/dev/sda2  VolGroupXX lvm2 a-   135.47G 99.53G
[root@fs1 ~]#

解説: その1その2その3
kernel-xenにバグか?
その4・CentOS 5.1での注意点
その5・GNBDの設定
その6・CLVMの設定
その7・GFS2の設定
その8・Congaからの設定
その9・ベンチマーク
その10・考察と予告

Red Hat Cluster: GNBD, CLVM and GFS・その7・GFS2の設定

前の記事『Red Hat Cluster: GNBD, CLVM and GFS・その6・CLVMの設定』で作成したクラスタ対応論理ボリューム(logical volume, LV) /dev/VGcDomUs00/LVGFS00をGFSでフォーマット、マウントし、使用する。

CentOS 5.1では、GFSとGFS2がサポートされている。RHEL5.1のリリースノート(日本語版)では、以下の通り述べられている。
GFS2 is an incremental advancement of GFS. This update applies several significant improvements that require a change to the on-disk file system format. GFS file systems can be converted to GFS2 using the utility gfs2_convert, which updates the metadata of a GFS file system accordingly.

While much improved since its introduction in Red Hat Enterprise Linux 5, GFS2 remains a Technology Preview. The release notes included in the distribution incorrectly states that GFS2 is fully supported. Nevertheless, benchmark tests indicate faster performance on the following:
<<略>>
要するに、GFS2は速いけどまだ不安定ということだ。GFSファイルシステムは、GFS2に変換可能なので、実運用に供する場合は、GFSを選択すべきだが、今回はあえてGFS2を使う。
GFSおよびGFS2を使用する場合は、それぞれサービスgsfおよびgfs2を起動しておく必要があるが
CongaによってOS起動時から有効になっているはずだ。
[root@dc1 ~]# chkconfig --list | grep gfs
gfs             0:off   1:off   2:on    3:on    4:on    5:on    6:off
gfs2            0:off   1:off   2:on    3:on    4:on    5:on    6:off
[root@dc1 ~]#

フォーマットは、mkfsコマンドを使って行う。以下のオプションが必要(GFSの場合もほぼ同様)
  • -t gfs2 : GFS2形式を指定(GFSを使う場合は`-t gfs')
  • -j 4 : ジャーナル数を指定。ファイルシステムを共有するノード数以上でなければならない。
  • -p lock_dlm : ファイルロックプロトコルを指定。指定できるのは、lock_dlmの他にlock_nolockがあるが、これは複数ノードで共有する場合には使用できない。
  • -t cDomUs:GFS00 : ファイルロックテーブル名。形式は「クラスタ名:ファイルシステム名」。
以下の通り作業する。
[root@dc1 ~]# lvs
LV       VG         Attr   LSize   Origin Snap%  Move Log Copy%
LVGFS00  VGcDomUs00 -wi-a-   4.00G
LogVol00 VolGroup00 -wi-ao   3.34G
LogVol01 VolGroup00 -wi-ao 544.00M
[root@dc1 ~]# mkfs -t gfs2 -j 4 -p lock_dlm -t cDomUs:GFS00 /dev/VGcDomUs00/LVGFS00
This will destroy any data on /dev/VGcDomUs00/LVGFS00.

Are you sure you want to proceed? [y/n] y

Device:                    /dev/VGcDomUs00/LVGFS00
Blocksize:                 4096
Device Size                4.00 GB (1047552 blocks)
Filesystem Size:           4.00 GB (1047551 blocks)
Journals:                  4
Resource Groups:           16
Locking Protocol:          "lock_dlm"
Lock Table:                "cDomUs:GFS00"

[root@dc1 ~]#
容量にもよるが、フォーマットには数分かかる。
実際にマウントし、使用する。
[root@dc1 ~]# mkdir /mnt/gfs00
[root@dc1 ~]# mount /dev/VGcDomUs00/LVGFS00 /mnt/gfs00
[root@dc1 ~]#
<<略>>
[root@dc2 ~]# mkdir /mnt/gfs00
[root@dc2 ~]# mount /dev/VGcDomUs00/LVGFS00 /mnt/gfs00
[root@dc2 ~]#
<<略>>
[root@dc3 ~]# mkdir /mnt/gfs00
[root@dc3 ~]# mount /dev/VGcDomUs00/LVGFS00 /mnt/gfs00
[root@dc3 ~]#
状態を調べてみる。
[root@dc3 ~]# mount
/dev/mapper/VolGroup00-LogVol00 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/xvda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
none on /sys/kernel/config type configfs (rw)
/dev/mapper/VGcDomUs00-LVGFS00 on /mnt/gfs00 type gfs2 (rw,hostdata=jid=2:id=131075:first=0)
[root@dc3 ~]# cman_tool services
type             level name       id       state
fence            0     default    00010002 none
[1 2 3]
dlm              1     clvmd      00010003 none
[1 2 3]
dlm              1     rgmanager  00020002 none
[1 2 3]
dlm              1     GFS00      00030003 none
[1 2 3]
gfs              2     GFS00      00020003 none
[1 2 3]
[root@dc3 ~]#
使ってみる。
[root@dc1 ~]# cd /mnt/gfs00
[root@dc1 gfs00]# cat random-write.sh
#!/bin/sh
timestampfile=timestamp.txt
if [ -f $timestampfile ]; then
touch $timestampfile
fi
while /bin/true;
do
echo $HOSTNAME: `date +%H:%M:%S.%N` >> $timestampfile
sleep $(( $RANDOM % 5 ))s
done
[root@dc1 gfs00]# ./random-write.sh
<<略>>
[root@dc2 ~]# cd /mnt/gfs00
[root@dc2 gfs00]# ./random-write.sh
<<略>>
[root@dc3 ~]# cd /mnt/gfs00
[root@dc3 gfs00]# tail -f timestamp.txt
dc1.xencluster: 22:42:50.286516000
dc1.xencluster: 22:42:51.310380000
dc1.xencluster: 22:42:52.318362000
dc2.xencluster: 22:42:53.198976000
dc2.xencluster: 22:42:53.306651000
dc2.xencluster: 22:42:53.314427000
dc1.xencluster: 22:42:55.329328000
dc1.xencluster: 22:42:55.395768000
dc2.xencluster: 22:42:57.322259000
dc1.xencluster: 22:42:57.405674000
dc2.xencluster: 22:42:59.385915000
dc2.xencluster: 22:42:59.433670000
dc1.xencluster: 22:43:01.505484000
dc2.xencluster: 22:43:02.441643000
解説: その1その2その3
kernel-xenにバグか?
その4・CentOS 5.1での注意点
その5・GNBDの設定
その6・CLVMの設定
その7・GFS2の設定
その8・Congaからの設定
その9・ベンチマーク
その10・考察と予告

2008/03/02

Red Hat Cluster: GNBD, CLVM and GFS・その6・CLVMの設定

前回『Red Hat Cluster: GNBD, CLVM and GFS・その5・GNBDの設定』で各クラスタメンバ間で共有したブロックデバイス上にクラスタメンバ間で共有される論理ボリューム(logical volume, LV)を構築する。

Xen Dom0 fs1がエクスポートしたgnbdブロックデバイス、cdom0sv01は、各Xen DomU dc[123]上では、/dev/gnbd0という名前でアクセスできる。
[root@dc1 ~]# gnbd_import -l
Device name : cdom0sv01
----------------------
Minor # : 0
sysfs name : /block/gnbd0
Server : fs1.xencluster
Port : 14567
State : Close Connected Clear
Readonly : No
Sectors : 8388608

[root@dc1 ~]#
このブロックデバイス上に、物理ボリューム(physical volume, PV)を作成する。
[root@dc1 ~]# pvcreate /dev/gnbd0
Physical volume "/dev/gnbd0" successfully created
[root@dc1 ~]# pvdisplay /dev/gnbd0
--- NEW Physical volume ---
PV Name               /dev/gnbd0
VG Name
PV Size               4.00 GB
Allocatable           NO
PE Size (KByte)       0
Total PE              0
Free PE               0
Allocated PE          0
PV UUID               aW5HFa-hCqa-ln2R-O3nU-TT0p-b6nQ-jS8kQh

[root@dc1 ~]#
ここまでは、普通の(非クラスタ)PVの場合の操作と同じ。
続いて、このPVを使って、クラスタ対応ボリュームグループ(volume group, VG) VGcDomUs00を作成する。
[root@dc1 ~]# vgcreate --clustered y VGcDomUs00 /dev/gnbd0
Volume group "VGcDomUs00" successfully created
[root@dc1 ~]# vgdisplay VGcDomUs00
--- Volume group ---
VG Name               VGcDomUs00
System ID
Format                lvm2
Metadata Areas        1
Metadata Sequence No  1
VG Access             read/write
VG Status             resizable
Clustered             yes
Shared                no
MAX LV                0
Cur LV                0
Open LV               0
Max PV                0
Cur PV                1
Act PV                1
VG Size               4.00 GB
PE Size               4.00 MB
Total PE              1023
Alloc PE / Size       0 / 0
Free  PE / Size       1023 / 4.00 GB
VG UUID               EBMdIF-8261-p0Gp-olFY-ciAn-IfD1-x6Bnhk

[root@dc1 ~]#
他の資料では、ここで論理ボリュームマネージャにクラスタ対応を指示するため、lvmconf --enable-clusterを実行(あるいは、/etc/lvm/lvm.conf内でlocking_type = 3を指定)せよ、とある場合もあるが、これは既にCongaによって実行されているので不要。
ここで、VGcDomUs00を共有しているクラスタメンバdc[123]で、サービスclvmdを再起動(あるいは、OSごと再起動)する必要がある。
[root@dc1 ~]# service clvmd restart
Deactivating VG VGcDomUs00:   0 logical volume(s) in volume group "VGcDomUs00" now active
[  OK  ]
Stopping clvm:[  OK  ]
Starting clvmd: [  OK  ]
Activating VGs:   2 logical volume(s) in volume group "VolGroup00" now active
0 logical volume(s) in volume group "VGcDomUs00" now active
[  OK  ]
[root@dc1 ~]#
<<略>>
[root@dc2 ~]# service clvmd restart
Deactivating VG VGcDomUs00:   0 logical volume(s) in volume group "VGcDomUs00" now active
[  OK  ]
Stopping clvm:[  OK  ]
Starting clvmd: [  OK  ]
Activating VGs:   2 logical volume(s) in volume group "VolGroup00" now active
0 logical volume(s) in volume group "VGcDomUs00" now active
[  OK  ]
[root@dc2 ~]#
<<略>>
[root@dc3 ~]# service clvmd restart
Deactivating VG VGcDomUs00:   0 logical volume(s) in volume group "VGcDomUs00" now active
[  OK  ]
Stopping clvm:[  OK  ]
Starting clvmd: [  OK  ]
Activating VGs:   2 logical volume(s) in volume group "VolGroup00" now active
0 logical volume(s) in volume group "VGcDomUs00" now active
[  OK  ]
[root@dc3 ~]#
これで、各クラスタメンバdc[123]上でVGcDomUs00に対してロックが働き、正常に操作できるようになった。
あるノードで、VGcDomUs00上にLV LVGFS00を作成すると、他のノードからもそれを確認できる。正しく作成されていれば、LVGFS00の状態がactiveになる。
[root@dc3 ~]# lvcreate --extents=1023 --name=LVGFS00 VGcDomUs00
Logical volume "LVGFS00" created
[root@dc3 ~]# lvs
LV       VG         Attr   LSize   Origin Snap%  Move Log Copy%
LVGFS00  VGcDomUs00 -wi-a-   4.00G
LogVol00 VolGroup00 -wi-ao   3.34G
LogVol01 VolGroup00 -wi-ao 544.00M
[root@dc3 ~]# lvdisplay /dev/VGcDomUs00/LVGFS00
--- Logical volume ---
LV Name                /dev/VGcDomUs00/LVGFS00
VG Name                VGcDomUs00
LV UUID                yNHwzC-Z3o5-XrnK-BgdY-O1py-WdW1-FO2zr0
LV Write Access        read/write
LV Status              available
# open                 0
LV Size                4.00 GB
Current LE             1023
Segments               1
Allocation             inherit
Read ahead sectors     0
Block device           253:2

[root@dc3 ~]#
<<略>>
[root@dc2 ~]# lvs
LV       VG         Attr   LSize   Origin Snap%  Move Log Copy%
LVGFS00  VGcDomUs00 -wi-a-   4.00G
LogVol00 VolGroup00 -wi-ao   3.34G
LogVol01 VolGroup00 -wi-ao 544.00M
[root@dc2 ~]#
<<略>>
[root@dc1 ~]# lvs
LV       VG         Attr   LSize   Origin Snap%  Move Log Copy%
LVGFS00  VGcDomUs00 -wi-a-   4.00G
LogVol00 VolGroup00 -wi-ao   3.34G
LogVol01 VolGroup00 -wi-ao 544.00M
[root@dc1 ~]#
ただし、LVGFS00はマウントされていないので、オープン状態にはなっていない。
dc[123]を再起動すると、VGcDomUs00がclvmdによって認識されていることを確認できる。
[root@dc1 ~]# shutdown -r now
<<略>>
Deactivating VG VGcDomUs00:   0 logical volume(s) in volume group "VGcDomUs00" now active
[  OK  ]
Stopping clvm:[  OK  ]
Stopping cluster:
Stopping fencing... done
Stopping cman... failed
/usr/sbin/cman_tool: Error leaving cluster: Device or resource busy
[FAILED]
<<略>>
INIT: version 2.86 booting
Welcome to  CentOS release 5 (Final)
Press 'I' to enter interactive startup.
<<略>>
Starting cluster:
Loading modules... DLM (built Nov 12 2007 03:26:48) installed
GFS2 (built Nov 12 2007 03:27:12) installed
done
Mounting configfs... done
Starting ccsd... done
Starting cman... done
Starting daemons... done
Starting fencing... done
[  OK  ]
Starting GNBD Client: resending requests
[  OK  ]
Starting system message bus: [  OK  ]
Starting clvmd: dlm: Using TCP for communications
dlm: connecting to 1
dlm: got connection from 2
dlm: got connection from 1
[  OK  ]
Activating VGs:   2 logical volume(s) in volume group "VolGroup00" now active
1 logical volume(s) in volume group "VGcDomUs00" now active
[  OK  ]
Mounting other filesystems:  [  OK  ]
<<略>>
CentOS release 5 (Final)
Kernel 2.6.18-53.el5xen on an i686

dc1.xencluster login:


追記(2008/2/3):
GNBDサーバ上でGNBDクライアント側LVが認識されないようにするには、『CLVMの設定・補足』を参照。

解説: その1その2その3
kernel-xenにバグか?
その4・CentOS 5.1での注意点
その5・GNBDの設定
その6・CLVMの設定
その7・GFS2の設定
その8・Congaからの設定
その9・ベンチマーク
その10・考察と予告

2008/03/01

Red Hat Cluster: GNBD, CLVM and GFS・その5・GNBDの設定

Red Hat Cluster: CentOS 5.1上でRHCSを使ってみる』シリーズで構築したクラスタ上にGNBDサーバ・クライアントを構築する。ただし、最新のkernel-xenには問題があるので、クラスタメンバのXen DomUに関しては、前回『Red Hat Cluster: GNBD, CLVM and GFS・その4・CentOS 5.1での注意点』の注意に従ってインストールし直す。

GNBDサーバの設定
クラスタcDom0sのメンバかつXen Dom0であるfs1上にGNBDサーバを構築する。
GNBD init スクリプト』からダウンロードし、サービスとして登録する。
[root@fs1 ~]# cd /etc/init.d/
[root@fs1 init.d]# wget http://funmoco.up.seesaa.net/program/gnbd-srv
--19:12:39--  http://funmoco.up.seesaa.net/program/gnbd-srv
Resolving funmoco.up.seesaa.net... 59.106.28.132, 59.106.28.138, 59.106.28.139,
...
Connecting to funmoco.up.seesaa.net|59.106.28.132|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2164 (2.1K) [text/plain]
Saving to: `gnbd-srv'

100%[=======================================>] 2,164       --.-K/s   in 0.03s

19:12:40 (73.3 KB/s) - `gnbd-srv' saved [2164/2164]

[root@fs1 init.d]# chmod a+x gnbd-srv
[root@fs1 init.d]# ls -l gnbd-srv
-rwxr-xr-x 1 root root 2164 Jul 30  2007 gnbd-srv
[root@fs1 init.d]# chkconfig --add gnbd-srv
[root@fs1 init.d]#
続いて、エクスポートする論理ボリューム(logical volume, LV)を作成する。
[root@fs1 init.d]# lvcreate --name=LogVolGNBD01 --size=4G /dev/VolGroupXX
Logical volume "LogVolGNBD01" created
[root@fs1 ~]# 
このLVをcdom0sv01という名前でエクスポートするよう、/etc/gnbdtabを以下の通り作成する。
export  cdom0sv01       /dev/VolGroupXX/LogVolGNBD01
GNBDサーバデーモンgnbd_servおよびユーティリティgnbd_exportのオプションを指定する/etc/sysconfig/gnbdは以下の通り。
# gnbd_serv options
GNBD_SERV_OPTS=

# gnbd_export options
GNBD_EXPORT_OPTS=
この後、fs1を再起動し、サービスgnbd-srvが正常に起動されることを確認する。

GNBDクライアントの設定
クラスタcDomUsのメンバ・Xen DomUであるdc[123]をGNBDクライアントとして設定する。以下の作業を、dc[123]上で実施する。
サーバと同じく、『GNBD init スクリプト』からスクリプトをダウンロードする。
[root@dc1 ~]# cd /etc/init.d/
[root@dc1 init.d]# wget http://funmoco.up.seesaa.net/program/gnbd-client
--11:01:17--  http://funmoco.up.seesaa.net/program/gnbd-client
Resolving funmoco.up.seesaa.net... 59.106.28.132, 59.106.28.138, 59.106.28.139, ...
Connecting to funmoco.up.seesaa.net|59.106.28.132|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1494 (1.5K) [text/plain]
Saving to: `gnbd-client'

100%[=======================================>] 1,494       --.-K/s   in 0.03s

11:01:18 (56.9 KB/s) - `gnbd-client' saved [1494/1494]

[root@dc1 init.d]# chmod a+x gnbd-client
[root@dc1 init.d]#
続いて、このgnbd-clientをサービスとして登録するのだが、『Red Hat Cluster: GNBD, CLVM and GFS・その4・CentOS 5.1での注意点』で指摘した通り、サービスcmanの後、サービスclvmdの前に起動されるよう、修正する必要がある。調べてみよう。
[root@dc1 init.d]# egrep "^# *chkconfig" cman clvmd gnbd-client
cman:# chkconfig: - 21 79
clvmd:# chkconfig: - 24 76
gnbd-client:# chkconfig: 2345 95 04
[root@dc1 init.d]#
起動順は、cmanが21、clvmdが24。停止順は、clvmdが76、cmanが79。サービスgnbd-clientの起動順を22、停止順を78に修正する。
[root@dc1 init.d]# cp -p gnbd-client gnbd-client.orig
[root@dc1 init.d]# sed 's/^\(# *chkconfig: *[0-9]\+\) [0-9]\+ [0-9]\+/\1 22 78/' < gnbd-client.orig  > gnbd-client
[root@dc1 init.d]# chkconfig --add gnbd-client
[root@dc1 init.d]#
設定ファイル/etc/gnbdtabでは、fs1からインポートするよう設定する。
import  fs1.xencluster
設定ファイル/etc/sysconfig/gnbdでは、オプションを指定する(というか、何も設定しない)
# gnbd_import options
GNBD_IMPORT_OPTS=
再起動し、正しくインポートされることを確認する。
[root@dc1 ~]# shutdown -r now

Broadcast message from root (xvc0) (Sat Mar  1 11:24:04 2008):

The system is going down for reboot NOW!
<<略>>
INIT: version 2.86 booting
Welcome to  CentOS release 5 (Final)
Press 'I' to enter interactive startup.
Setting clock  (localtime): Sat Mar  1 11:24:58 JST 2008 [  OK  ]
<<略>>
Mounting local filesystems:  [  OK  ]
Enabling local filesystem quotas:  [  OK  ]
Enabling /etc/fstab swaps:  [  OK  ]
INIT: Entering runlevel: 3
Entering non-interactive startup
Starting monitoring for VG VolGroup00:   connect() failed on local socket: Connection refused
WARNING: Falling back to local file-based locking.
Volume Groups with the clustered attribute will be inaccessible.
2 logical volume(s) in volume group "VolGroup00" monitored
[  OK  ]
<<略>>
Starting cluster:
Loading modules... DLM (built Nov 12 2007 03:26:48) installed
GFS2 (built Nov 12 2007 03:27:12) installed
done
Mounting configfs... done
Starting ccsd... done
Starting cman... done
Starting daemons... done
Starting fencing... done
[  OK  ]
Starting GNBD Client: [  OK  ]
resending requests
Starting system message bus: [  OK  ]
Starting clvmd: dlm: Using TCP for communications
dlm: connecting to 1
dlm: got connection from 2
dlm: got connection from 1
[  OK  ]
Activating VGs:   2 logical volume(s) in volume group "VolGroup00" now active
[  OK  ]
<<略>>
CentOS release 5 (Final)
Kernel 2.6.18-53.el5xen on an i686

dc1.xencluster login: root
Password: パスワード
Last login: Sat Mar  1 11:02:09 on xvc0
[root@dc1 ~]# gnbd_import -l
Device name : cdom0sv01
----------------------
Minor # : 0
sysfs name : /block/gnbd0
Server : fs1.xencluster
Port : 14567
State : Open Connected Clear
Readonly : No
Sectors : 8388608

[root@dc1 ~]#
正しくブロックデバイスcdom0sv01がfs1からインポートされていることがわかる。

解説: その1その2その3
kernel-xenにバグか?
その4・CentOS 5.1での注意点
その5・GNBDの設定
その6・CLVMの設定
その7・GFS2の設定
その8・Congaからの設定
その9・ベンチマーク
その10・考察と予告

2008/02/28

Red Hat Cluster: GNBD, CLVM and GFS・その4・CentOS 5.1での注意点

Red Hat Cluster: GNBD, CLVM and GFS・その3』で、
これまで三回に渡り、GNBD、CLVMおよびGFSについて概説してきた。以上を元に、次のことを今後の目標とし、実際にシステムを組んでみたい。
  1. GNBDでディスクデバイスを共有する
  2. GNBDで共有されたブロックデバイスから、CLVMでクラスタ上で共有されるVGおよびLVを生成する。
  3. CLVMで生成したLV上にGFSを作成し、各クラスタメンバ上でマウントする。
と宣言したきり、ちっとも実践編へ進まなかったシリーズを再開。まずは、作業前の注意点。

Red Hat Cluster: CentOS 5.1上でRHCSを使ってみる』シリーズに従いクラスタを構成した後、GNBD、CLVMおよびGFSでファイル共有を実現する。以下の点に注意する。
  1. 現時点(2008/2/28)の最新版kernel-xen-2.6.18-53.1.13.el5およびkmod-gnbd-xen-0.1.4-12.el5をXen DomUで使うと、CPU負荷が異常に高くなるバグがある。追記(2008/3/11): この問題は解決された。『Red Hat Cluster: GNBD, CLVM and GFS・その4・CentOS 5.1での注意点・補足』参照
  2. GNBDにはinit scriptが準備されていない。
  3. GNBDクライアントサービスの起動順は、サービスcmanの後、サービスclvmdの前でないといけない。
使用するパッケージのバージョンについては、少なくともbaseレポジトリのkernel-xen-2.6.18-53.el5を使えば問題ない。
Red Hat Cluster: CentOS 5.1上でRHCSを使ってみる・その3・DomU dcXのインストール』では、OSインストール時にupdatesなどのレポジトリを参照し、最新版をインストールするようKickstart設定ファイルに指定していたが、この部分をコメントアウトする。
repo --name=base --baseurl=http://repository.xencluster/centos/5/os/i386/
#repo --name=updates --baseurl=http://repository.xencluster/centos/5/updates/i386/
#repo --name=addons --baseurl=http://repository.xencluster/centos/5/addons/i386/
#repo --name=extras --baseurl=http://repository.xencluster/centos/5/extras/i386/


CetnOS 5.1のパッケージgnbdおよびkmod-gnbdには、GNBDのinitスクリプトが付属していない(少なくとも現時点では)。このブログにリンクしてもらっている『funなJava、mocoなLinux』の記事『GNBD init スクリプト』を参考にする。

サービス起動順だが、gnbd_export(8)のman pageに次のような記述がある
-c Enable caching.
<<略>>
WARNING: You must NOT specify this option if you wish to use gnbd with dm multi-pathing, or run GFS on gnbd server machines.
Device mapper multi path(DMMP)を使う場合や、GFSをGNBDサーバ上で使うような場合は、GNBDのキャッシュ機能を有効にしてはいけない。
同じく-cオプションの項に次のような記述もある。
With the -c option, it is not necessary to have the gnbd server machine be part of the cluster. If -c option is not used, the server machine must already have a cluster manager running on it.
この-cオプションを使う場合は、GNBDサーバがクラスタメンバである必要はない(クラスタメンバであってもよい)。この-cオプションを使わない場合は、GNBDサーバ上でクラスタマネージャが既に動作していなければならない。
以上のことから考えると、DMMPを使う可能性を考慮した場合、-cを使えないし、gnbdより先にcmanが起動されている必要がある。GFSをGNBDサーバ上で使う場合も同様。
一方、clvmdが起動される前に、clvmdが認識する物理ボリューム(physical volume, PV)がOSに認識されている必要がある。そうでなければ、clvmdがクラスタ対応ボリュームグループ(volume group, VG)を正しく認識できない。この状態で、そのクラスタ対応VG上に論理ボリューム(logical volmume, LV)を作成すると、アクティブにできなくなったり、そのLVを削除できなくなったりする。例えば、
[root@dc3 ~]# service clvmd start
Starting clvmd: [  OK  ]
Activating VGs:   2 logical volume(s) in volume group "VolGroup00" now active
[  OK  ]
[root@dc3 ~]# service gnbd-client start
Starting GNBD Client: [  OK  ]
resending requests
[root@dc3 ~]# vgs
VG         #PV #LV #SN Attr   VSize VFree
VGcDomUs00   1   1   0 wz--nc 4.00G    0
VolGroup00   1   2   0 wz--n- 3.88G    0
[root@dc3 ~]# lvs
LV          VG         Attr   LSize   Origin Snap%  Move Log Copy%
LogVolGFS00 VGcDomUs00 -wi---   4.00G
LogVol00    VolGroup00 -wi-ao   3.34G
LogVol01    VolGroup00 -wi-ao 544.00M
[root@dc3 ~]# lvchange --available y  LogVolGFS00 VGcDomUs00
Volume group "LogVolGFS00" not found
Error locking on node dc2.xencluster: Volume group for uuid not found: 0rrqOzVArnLSIzM8nyTlj4nVONcbaO13QxVYIwLjU0SFe5FHRGDTnni7f9Lmu1Mp
Error locking on node dc3.xencluster: Volume group for uuid not found: 0rrqOzVArnLSIzM8nyTlj4nVONcbaO13QxVYIwLjU0SFe5FHRGDTnni7f9Lmu1Mp
[root@dc3 ~]# lvremove /dev/VGcDomUs00/LogVolGFS00
Error locking on node dc3.xencluster: Volume group for uuid not found: 0rrqOzVArnLSIzM8nyTlj4nVONcbaO13QxVYIwLjU0SFe5FHRGDTnni7f9Lmu1Mp
Can't get exclusive access to volume "LogVolGFS00"
[root@dc3 ~]#
正しい順番で起動されていれば、以下の様に操作できるはずだ。
[root@dc1 ~]# vgs
VG         #PV #LV #SN Attr   VSize VFree
VGcDomUs00   1   1   0 wz--nc 4.00G    0
VolGroup00   1   2   0 wz--n- 3.88G    0
[root@dc1 ~]# lvs
LV          VG         Attr   LSize   Origin Snap%  Move Log Copy%
LogVolGFS00 VGcDomUs00 -wi-a-   4.00G
LogVol00    VolGroup00 -wi-ao   3.34G
LogVol01    VolGroup00 -wi-ao 544.00M
[root@dc1 ~]# lvchange --available n /dev/VGcDomUs00/LogVolGFS00
[root@dc1 ~]# lvs
LV          VG         Attr   LSize   Origin Snap%  Move Log Copy%
LogVolGFS00 VGcDomUs00 -wi---   4.00G
LogVol00    VolGroup00 -wi-ao   3.34G
LogVol01    VolGroup00 -wi-ao 544.00M
[root@dc1 ~]# lvchange --available y /dev/VGcDomUs00/LogVolGFS00
[root@dc1 ~]# lvs
LV          VG         Attr   LSize   Origin Snap%  Move Log Copy%
LogVolGFS00 VGcDomUs00 -wi-a-   4.00G
LogVol00    VolGroup00 -wi-ao   3.34G
LogVol01    VolGroup00 -wi-ao 544.00M
[root@dc1 ~]#


[root@dc2 ~]# lvchange --available n /dev/VGcDomUs00/LogVolGFS00
[root@dc2 ~]#


[root@dc3 ~]# lvchange --available n /dev/VGcDomUs00/LogVolGFS00
[root@dc3 ~]#


[root@dc1 ~]# lvremove /dev/VGcDomUs00/LogVolGFS00
Logical volume "LogVolGFS00" successfully removed
[root@dc1 ~]#

以上の点に注意して、実際にGFSによるファイル共有環境を構築する。

解説: その1その2その3
kernel-xenにバグか?
その4・CentOS 5.1での注意点
その5・GNBDの設定
その6・CLVMの設定
その7・GFS2の設定
その8・Congaからの設定
その9・ベンチマーク
その10・考察と予告

2007/11/28

続々・Red Hat Cluster: kernel-xenにバグか?

Red Hat Cluster: kernel-xenにバグか?』および『続・Red Hat Cluster: kernel-xenにバグか?』で報告したバグだが、どうも修正されたようだ。
によると、kmod-gfsにバグがあり、新バージョンで解決されるらしい。
検証して報告したい。
#最近「~したい」「~したい」ばかりで全然進んでない。申し訳ない。

追記(2008/2/24):
CentOS 5.1ではこの問題は解決している。以下の記事を参照。
Red Hat Cluster: CentOS 5.1上でRHCSを使ってみる

2007/11/12

続・Red Hat Cluster: kernel-xenにバグか?

Red Hat Cluster: kernel-xenにバグか?』でクラスタ/DLM関連のバグを指摘した。これはどうも、CentOS Bug ID 0002416 と同じバグのようだ。#2416は、CentOS 4でのものだが、「kernel: Extra connection from node * attempted」というログが共通しているし、症状も似ているような気がする。

アカウントを取って報告してみるか…

追記(2008/2/24):
CentOS 5.1ではこの問題は解決している。以下の記事を参照。
Red Hat Cluster: CentOS 5.1上でRHCSを使ってみる

2007/11/07

Red Hat Cluster: kernel-xenにバグか?

Red Hat Cluster: GNBD, CLVM and GFS』シリーズが全然進んでいない。その言い訳。どうも、現時点で最新のカーネルkernel-xen-2.6.18-8.1.15.el5にはバグがあるようだ。一世代前のkernel-xen-2.6.18-8.1.14.el5ならば問題ない。
#Xen対応でないバニラカーネルでどうなのかは未確認。

シリーズの続きを書くべく、作業を進めていたのだが、クラスタの動作が安定しなかった。クラスタメンバを一斉に起動するような場合には問題なくクラスタが開始されるのだが、この後、各クラスタメンバの再起動を行うと、OS起動時にクラスタ関連のサービスが正常に起動されなかったり、最悪、OS起動時に停止してしまい、ログインプロンプトすら出ない、という現象に遭遇した。
クラスタメンバを一斉に起動し、クラスタが正常に起動した後、何度かクラスタメンバの再起動を繰り返していると、OS起動時に、
Welcome to  CentOS release 5 (Final)
Red Hat Enterprise Linux Server release 5 (Tikanga)
Press 'I' to enter interactive startup.
Setting clock  (localtime): Wed Nov  7 13:27:24 JST 2007 [  OK  ]
Starting udev: [  OK  ]
<<略>>
Starting RPC idmapd: [  OK  ]
Starting cluster:
Loading modules... DLM (built Oct 22 2007 09:34:27) installed
GFS2 (built Oct 22 2007 09:34:51) installed
done
Mounting configfs... done
Starting ccsd... done
Starting cman... done
Starting daemons... done
Starting fencing... done
[  OK  ]
Starting system message bus: [  OK  ]
Starting clvmd: dlm: got connection from 2
dlm: connecting to 1
dlm: got connection from 1
dlm: connecting to 1
[  OK  ]
の部分で停止してしまう。このとき、他のクラスタメンバ上では、
dlm: connecting to 3
dlm: got connection from 3
Extra connection from node 3 attempted
dlm: got connection from 3
の様なメッセージが表示される。
この状態から、停止しているノードをフェンスしたり、強制再起動したりすると、今度は、
Welcome to  CentOS release 5 (Final)
Red Hat Enterprise Linux Server release 5 (Tikanga)
Press 'I' to enter interactive startup.
Setting clock  (localtime): Wed Nov  7 13:37:28 JST 2007 [  OK  ]
Starting udev: [  OK  ]
<<略>>
Starting RPC idmapd: [  OK  ]
Starting cluster:
Loading modules... DLM (built Oct 22 2007 09:34:27) installed
GFS2 (built Oct 22 2007 09:34:51) installed
done
Mounting configfs... done
Starting ccsd... done
Starting cman... done
Starting daemons... done
Starting fencing...
ここで五分程停止する。おそらく、fencedの起動でタイムアウトまで待っているのだと思われる(/etc/init.d/cman中のFENCED_START_TIMEOUTの既定値は300[秒])
更にこの後、clvmdの起動に失敗する。
[  OK  ]
Starting system message bus: [  OK  ]
Starting clvmd: clvmd startup timed out
[FAILED]
Mounting other filesystems:  [  OK  ]
<<略>>
Starting Cluster Module - cluster monitor: Setting verbosity level to LogBasic
[  OK  ]
Starting Cluster Service Manager: [  OK  ]
Starting ricci: [  OK  ]

CentOS release 5 (Final)
Kernel 2.6.18-8.1.15.el5xen on an i686

ノード3 login:
このとき、別のクラスタメンバ上では、
[root@ノード2 ~]# cman_tool services
type             level name       id       state
fence            0     default    00010002 FAIL_ALL_STOPPED
[1 2 3]
dlm              1     clvmd      00010003 FAIL_STOP_WAIT
[1 2 3]
dlm              1     rgmanager  00020003 FAIL_STOP_WAIT
[1 2]
[root@ノード2 ~]#
の様になっている。正常ならば、
[root@ノード2 ~]# cman_tool services
type             level name       id       state
fence            0     default    00010002 none
[1 2 3]
dlm              1     clvmd      00010003 none
[1 2 3]
dlm              1     rgmanager  00020003 none
[1 2 3]
[root@ノード2 ~]#
のようになるはずだ。
ここから、クラスタメンバを停止しようとすると、正常に停止できない。
[root@ノード3 ~]# shutdown -h now

Broadcast message from root (xvc0) (Wed Nov  7 13:50:09 2007):

The system is going down for system halt NOW!
INIT: Switching to runlevel: 0
INIT: Sending processes the TERM signal
[root@dノード3 ~]# Shutting down Cluster Module - cluster monitor: [  OK  ]
Shutting down Cluster Service Manager...
Waiting for services to stop:
この部分で停止したままになってしまう。これは、すべてのクラスタメンバで共通の現象だ。こうなると、すべてのノードを一斉に停止・起動するしかない。
これは、サービスrgmanagerを停止中に、デーモンclurgmgrdが「Uninterruptible sleep」状態(ps(1)参照)になっていて、シグナルに応答しなくなることが原因。追求できたのはここまで。

カーネルのバージョン2.6.18-8.1.15.el5に関しては、RHSA-2007:0940-7に更新情報が記載されていて、Distributed Lock Manager(DLM)に関する修正がなされたことが解る。この修正で虫が憑いたのではないだろうか。
当面、2.6.18-8.1.14.el5で検証を行う。しかし、2.6.18-8.1.15.el5への修正は、深刻度「重要(Important)」に分類されているのが頭の痛いところだ。

2007/11/12追記:
続・Red Hat Cluster: kernel-xenにバグか?』に情報を追加した。

追記(2008/2/24):
CentOS 5.1ではこの問題は解決している。以下の記事を参照。
Red Hat Cluster: CentOS 5.1上でRHCSを使ってみる

2007/09/28

Red Hat Cluster: RHCSとXen

ちっとも実践編に進まないので気が引けるが、今回はクラスタと仮想化について考えてみたい。

クラスタと仮想化は、言わば正反対の技術だ。クラスタは複数のマシンを束ねて共通のサービスを提供する技術、仮想化は一台のマシンを複数に分割して仮想的に複数台のマシンに見せかける技術だ。この正反対の技術を組み合わせて使うこともなかろうに、という意見も当然あるだろう。しかし、クラスタと仮想化を組み合わせて使う理由はいくつかある。

まず、クラスタへのメンバの追加の手間が減ることがある。クラスタにメンバを追加する(あるいは、新規にクラスタを生成する)場合、通常であれば、
  1. 追加するメンバの数だけマシンを準備し、
  2. それらにそれぞれOSをインストールし、
  3. Congaなりのクラスタ管理ツールを利用してクラスタに追加する、
という手順をとる。このうち、最後のものは大した手間ではないが、前の二つは手間がかかる。企業であれば、見積もりを取り、マシン購入の稟議をまわし、購買部門に手続きを依頼し、…と言った手順が必要で、マシン到着までに一ヶ月以上待たされることも珍しくないだろう。OSのインストールに関しては、プレインストールを利用すればよいが、それにしても、実際の稼動環境に適合するように設定する手間は省けない。
一方、クラスタメンバをXenなどを使った仮想マシンで構成した場合を考えてみよう。マシンの購入の手続きは変わらないが、余裕を持った高性能機を買い足すことで、購入回数は減る(その分、稟議を通すのが難しくはなるが)。実ハードウェアに対するOSのインストール手順は変わらないが、仮想マシンへのインストールは、一回で済む。仮想マシンを増やす手間は、イメージファイルのコピーだけで済むからだ(正確には、設定ファイルのコピーや、DHCPサーバ・DNSサーバの設定変更などもあるが、これは事前にまとめて済ませておくことも可能。このあたりについては、その内解説する…多分)

また、ハードウェア台数が減ると、一般に処理能力は同じでも消費電力は少なくなる。消費電力が少なくなれば、サーバルームの冷却の点でも有利だ。電力や冷却の問題は、はクラスタを運用するようなデータセンターでは非常に重要になりつつある。

クラスタへの計算機資源管理の面でも仮想化との組み合わせは有効だ。ハードウェアを直接クラスタメンバにする場合、基本的にハードウェアの全資源をクラスタに投入する以外に選択はない。一方、仮想化機構を介してクラスタメンバとして仮想マシンを提供すると、仮想化機構のリソース管理機能を使って、割り当てるCPU使用率、CPU数およびメモリ等を細かく設定し、クラスタに投入することができる。
さらに、『VLANとXenを組合わせて使う』で紹介した方法を使えば、まったく違う複数のサービス領域に対して、一台のDom0からクラスタメンバとしてDomUを提供することもできる。クラスタをサービスとして複数の顧客に提供する場合、価格・納期・SLA等の点で利点となる。

逆に、仮想マシンの提供という観点から考えると、クラスタで構成された可用性の高いストレージ上に仮想マシンのイメージファイルを置けば、仮想マシンサービスの可用性も向上する。さらに、Xenで言うLive Migrationの類の技術も採用しやすくなる。Live Migrationとは、稼働中のDomUをあるDom0機から別のDom0機へほぼ無停止で移動する技術だが、Dom0機間でのイメージファイルの共有が必要だ。

最後に、フェンスデバイスの問題を採り上げたい。クラスタでは、サービス不能になったメンバを、クラスタサービスから取り除く操作が必要になる。これをフェンス(fencing)と言う。具体的には、そのメンバをシャットダウンしたり、サービスに必要なストレージから切り離したり、と言った操作を行う。RHCSでは、さまざまなフェンス手段が準備されているが、FCスイッチや、ネットワーク電源スイッチなど、それほど一般的でないハードウェアに特化したものが多く、これらは高価で採用しにくい(ハードウェアに特化したもので採用しやすいのには、APCの無停電電源装置を利用するものがあるが、データセンターでは、そもそも無停電電源装置は不要だ。IBMのRSA IIやDellのDRACなど、各サーバベンダーのサーバ管理モジュールに対応したものは、比較的安価で採用しやすいが、それでも只ではない)
RHCSには、virtual machine fencingというフェンス手段が準備されている。これは、Dom0に対してクラスタメンバに対応するDomUをシャットダウン(あるいは、再起動)するように指示するものだ。これは、ソフトウェアのみで実現できるため、採用しやすい(他にも、ソフトウェア的なフェンス手段として、にも述べたGNBD fencingもある)

追記(2008/2/24):
検証を再開した。
Red Hat Cluster: CentOS 5.1上でRHCSを使ってみる

2007/09/26

Red Hat Cluster: GNBD, CLVM and GFS・その3

GNBDでブロックデバイスをクラスタ上で共有できるので、ブロックデバイスが共有されていることを前提としているGFSと組合せて使うとよい。これが前回および前々回までの要点だ。

GNBDでブロックデバイスを共有すると、GNBDクライアント上に/dev/gnbd*というデバイスができる。これに対するアクセスは、GNBDサーバ上の対応するブロックデバイスへのアクセスと等価だ。当然これを直接GFS(GFS2)でフォーマットし、マウントして使うこともできる。
しかし、この方法は柔軟性に欠ける。例えば、GNBDサーバ上の対応するブロックデバイスが/dev/sda1の様な物理ディスクのパーティションだと、サイズを変更することができない。この問題は、LVMを使えば解決できる。GNBDサーバ側でLVMを用いてVGを組み、LVをGNBDでエクスポートすればよい。

しかし、これより更によい方法がある。それがCluster Logical Volume Manager(CLVM)だ。CLVMは、読んで字の如く、クラスタ上で共有されるLVMだ。CLVMを使えば、どのクラスタメンバ上でも同じ内容・同じ名前でVGやLVをアクセスできる。
これに加え、異なるGNBDサーバからエクスポートされた複数のブロックデバイスでVGを組むことも可能という利点もある。GNBDサーバ側でVLMを組む場合にはこのようなことはできない。
さらに、Device Mapper Multipath (DM-MP)と併用すれば、冗長構成を採ることにより、耐障害性を高めることもできる(その内詳しく解説します…多分)

CLVMは、LVM(LVM2)の自然な拡張になっており、クラスタを意識しない場合のLVMのCUIやGUIとほとんど同じ操作で管理できる。違いは、クラスタを構成した後、各クラスタメンバ上で
# lvmconf --enable-cluster
を実行することと、最初にVGを組む場合に、クラスタ対応VGだと指示することくらいだ。


これまで三回に渡り、GNBD、CLVMおよびGFSについて概説してきた。以上を元に、次のことを今後の目標とし、実際にシステムを組んでみたい。
  1. GNBDでディスクデバイスを共有する
  2. GNBDで共有されたブロックデバイスから、CLVMでクラスタ上で共有されるVGおよびLVを生成する。
  3. CLVMで生成したLV上にGFSを作成し、各クラスタメンバ上でマウントする。

解説: その1その2その3
kernel-xenにバグか?
その4・CentOS 5.1での注意点
その5・GNBDの設定
その6・CLVMの設定
その7・GFS2の設定
その8・Congaからの設定
その9・ベンチマーク


追記(2008/2/24):
検証を再開した。
Red Hat Cluster: CentOS 5.1上でRHCSを使ってみる

Red Hat Cluster: GNBD, CLVM and GFS・その2

前回、GFSを利用するには、クラスタメンバ間でブロックデバイスを予め共有しておく必要がある、と述べた。ここでは、GNBDを使うが、他の方法について概説する。

ブロックデバイスについては、ここに解説してある。
ブロックデバイスとは、ブロックサイズの倍数、典型的には 512 か 1024 バイトでのみ読み書きするデバイスである。ブロックデバイスはバッファキャッシュ経由でアクセスされ、ランダムなアクセス、すなわちデバイス上のどこにあるブロックでも読み書きできるアクセス方法が利用されることが多い。ブロックデバイスへのアクセスは、それぞれに対応したデバイススペシャルファイルを経由しても可能であるが、ファイルシステム経由でアクセスするほうがより一般的である。マウントされるファイルシステムをサポートできるのはブロックデバイスだけである。
つまり、ブロックデバイスは、主にディスク等の物理デバイスをデバイスドライバを通してアクセスする仕組みだ。GFSは、ネットワーク越しに共有された物理デバイスをブロックデバイススペシャルファイルを通じてアクセスする。つまり、ブロックデバイスの共有だ。

物理ディスクをブロックデバイスとして共有する方式はいくつかある。いわゆるStorage Area Network (SAN)と呼ばれるものが代表的だ。SANには、ファイバーチャネルを利用するFibre Channel SAN (FC-SAN)や、IPを利用するIP-SANなどがある。

FC-SANは、FCインターフェースを備えた専用ディスク装置、FCスイッチおよびFCインターフェースを備えたコンピュータで構成されるのが一般的だ(FC-SANはお金持ちの道具なので、私は使ったことがない)。FC装置に関する知識が必要で、対応できる技術者が少ないことが問題になる。

IP-SANの代表選手はiSCSIだ。これは、SCSIをIPでカプセル化してネットワーク越しにデバイスを共有する仕組みだ(これと似た仕組みにATA over Ethernet (AoE)というものがあるらしいが、詳しくは知らない)。IP-SANは、Ethernetポートを備えた専用のディスク装置、EthernetスイッチおよびEthernetポートを備えたコンピュータで構成されるのが一般的だ。後の二つは、ごく一般的な機器なので、特殊な知識を必要とせず、FC-SANに比べ導入のハードルが低い。特にiSCSIであれば、専用のディスク装置でなく、PC上でiSCSIサーバを走らせることで代用可能だ。CentOS 5には、Linux上のiSCSI実装の一種であるOpen-iSCSIがRPMで準備されている。パッケージ名はiscsi-initiator-utilsだ。

一方GNBDは、IPネットワーク上でブロックデバイスを共有する仕組みで、通常、クラスタ環境で使用される(が、クラスタ環境は必須ではない。後述)。GNBDは、クライアント=サーバ構成になっており、GNBDサーバ上のブロックデバイスを、複数のGNBDクライアントからアクセス可能にする。この意味では、PC上でiSCSIサーバを動作させる場合に非常によく似ている。ただ、GNBDは、RHCSのfence deviceとしても使えるので、クラスタとの親和性が高い。
なお、上図で、GNBDは、ローカルに接続されたディスクドライブに対するブロックデバイスを共有しているが、FCのポート単価はEthernetに比べて高いことに着目して、FCとGNBDの折衷案も考えられる。FCポート数を減らし、Ethernetポートで置き換えると、性能は多少落ちるが、全体のコストは下がる(これは、RHELのマニュアルでも触れられている)

GNBDは、基本的にクラスタ環境で使用するが、実はiSCSIの様にクラスタと無関係に使うこともできる。GNBDのサーバ側では、gnbd_servというサーバプロセスが動くのだが、起動時に-nというオプションを与えると、クラスタとは無関係に動作する。
ただし、GFSを使う場合は、このオプションを使うことはできないようだ。なぜなら、gnbd_servのマニュアルを見ると、このオプションを使うと、キャッシュ無しのデバイスをエクスポートすることはできない、と書いてあり、gnbd_exportのマニュアルを見ると、GNBD上でGFSを使う場合は、キャッシュを有効にしてはいけない、と書いてある。

さて、GNBDを使えば、クラスタ上でブロックデバイスを共有できることが判った。では、そのデバイスを直接使ってGFSを構成すべきだろうか?

解説: その1その2その3
kernel-xenにバグか?
その4・CentOS 5.1での注意点
その5・GNBDの設定
その6・CLVMの設定
その7・GFS2の設定
その8・Congaからの設定
その9・ベンチマーク


追記(2008/2/24):
検証を再開した。
Red Hat Cluster: CentOS 5.1上でRHCSを使ってみる

2007/09/25

Red Hat Cluster: GNBD, CLVM and GFS・その1

レッドハットクラスタ(RHCS)を使いこなすべく、調査中。そのメモを残す。

クラスタを構成するには、クラスタのメンバ(クラスタを構成するサーバマシン)が資源を共有する場合が多い。例えば、HTTPサービスをクラスタで提供する場合、少なくとも/var/www/htmlの様なコンテンツ領域を共有する必要があるだろう。ファイル共有であれば、NFSを使うという手もあるのだが、ここはクラスタらしく、GFS(GFS2)を使いたい。

GFS(Global File System)は、ネットワークファイルシステムである。ということは、前出のNFSやCIFS(Widowsのネットワーク共有、SAMBAなど)と同列だ。ただし、NFSやCIFSと決定的に違う点がある。実際にファイルやディレクトリを格納するブロックデバイスを、別途GFSを使うマシン群で共有しておかなければならない、という点だ。
例えばNFSでファイル共有を行う場合、通常NFSサーバ上にブロックデバイス(例えば/dev/sda)が存在し、NFSクライアントからこのブロックデバイスへのアクセスは、NFSプロトコルによってカプセル化される。このためNFSクライアント側では、このブロックデバイスを直接アクセスする必要はまったくない(というより、してはいけない)
一方GFSでは、ブロックデバイスは既にGFSを使うクラスタメンバ(GFSはクライアント=サーバシステムではないので、GFSクライアントと呼ぶのは正しくない)間で共有されていることを前提としている。つまり、クラスタメンバは、実際にファイルやディレクトリを格納するブロックデバイスへのアクセスが必要、ということだ。この意味では、ブロックデバイスの存在を前提としているext3等のローカルファイルシステムと同列と言える。GFSとこれらのローカルファイルシステムの違いは、当然ながら、ネットワーク共有可能か否かにある(この違いは、分散ロック機構と複数ジャーナル機構などから生まれるのだが、ここでは解説しない)
Linuxにおいて、ファイルシステムとは、VFSを通じて呼ぶことのできる記憶装置(/procファイルシステムの様に記憶装置でないファイルシステムもあるが)である。ファイルやディレクトリと言った概念を用いてアクセスできる記憶装置と言い換えることもできるだろう。図を見てもらうと解ると思うが、NFSは、ファイルシステムの上にファイルシステムを架した構成になっている(従って、VFSが二回介在する)ため、オーバヘッドが大きい。
一方、GFSは、ブロックデバイスをネットワーク共有した後でファイルシステムが存在しているだけなので、オーバーヘッドは少ない(ブロックデバイス共有機構の効率にもよるが、一般には、ファイルI/OよりもブロックデバイスI/Oの方が単純なので)

では、GFSの前提となるブロックデバイス共有機構は何を使えばいいのか?この解答の一つがGNBDである。

解説: その1その2その3
kernel-xenにバグか?
その4・CentOS 5.1での注意点
その5・GNBDの設定
その6・CLVMの設定
その7・GFS2の設定
その8・Congaからの設定
その9・ベンチマーク


追記(2008/2/24):
検証を再開した。
Red Hat Cluster: CentOS 5.1上でRHCSを使ってみる