雲の上はいつも青空 -28ページ目

雲の上はいつも青空

不思議な経歴をもつエンジニア!?の徒然なブログです。
お仕事関係の話が多いと思いますが、コメントとかもらえると中の人はとても喜びます(^O^)/

iSCSI環境ができあがっているところに、クラスタ+GFS2を構築します。
まずは、おさらいですがiSCSIは物理層に近いプロトコルをTCP/IPでラップする機能です。
つまり、サーバ筐体内にあるSCSIカードとHDDをつないでいるケーブルを、ネットワークにのせてう~んと伸ばしたイメージです。
ですから、iSCSIそのものとファイルシステムは直接関係はありません。

つまり、iSCSIで接続できた=OSから物理ボリュームとして見える…ということになります。
ここからは、通常のHDDと同じように操作できるのですが、1つの物理ボリュームを複数のマシンで操作しようとすると通常のファイルシステムではいろいろ問題が生じます。
前にも書きましたが、一番の問題がファイルにか書かれるデータ本体と、ファイルを管理するメタデータの排他制御です。排他制御が働かないと、各々自分の持っているキャッシュの内容で、ドスンとHDDを書き換えてしまうので、おかしな状態になってしまいます。
【参考】今までのiSCSI関連のまとめはこちら


GFS(Global File System)は、現在RedHat社の標準クラスタ用ファイルシステムですが、GPLライセンスのもとでオープンソースとして公開しています。
一つのストレージを複数のノードで共有する場合には、このGFSと分散ロックマネージャとしてcmanを一緒に使う事になります。ボリュームに格納されるデータの管理をGFSが行い、複数のマシンに分散して動いているGFSの排他制御をcmanが行うという感じです。

1.インストールは非常に簡単で、aptitude install gfs-tools cman clvm parted です。
※fdiskでパーティションを作ってもGFSでフォーマットできないので、今回はGNU partedでパーティションを作ります。
→どうもfdiskでは2T以上のパーティションは作成できないみたいですし、RedHatは64bitのFSはGFSしかサポートしないとか言っているので、そのうちpartedが標準のパーティション作成ツールになるかもしれません。
【注】クラスター関係のソフトは、kernelモジュールを含んでいますので、インストール後は一度再起動することを忘れないようにしてください!

2.以下の三台でクラスタを構築します。
〇iSCSI、ターゲット機:    マシン名:kitty     192.168.0.155
〇xen環境、Domain-0 :  マシン名:poporon 192.168.0.154
〇xen環境、Domain-0 :  マシン名:aster 192.168.0.5

cman用のコンフィグファイルを作り、/etc/cluster/cluster.conf として保存します。
<cluster name="cluster1" config_version="5">

<clusternodes>
 <clusternode name="kitty" votes="1" nodeid="1">
<fence>
<method name="single">
<device name="manual" ipaddr="192.168.0.155"/>
</method>
</fence>
 </clusternode>

 <clusternode name="aster" votes="1" nodeid="2">
<fence>
<method name="single">
<device name="manual" ipaddr="192.168.0.5"/>
</method>
</fence>
 </clusternode>

 <clusternode name="poporon" votes="1" nodeid="3">
<fence>
<method name="single">
<device name="manual" ipaddr="192.168.0.154"/>
</method>
</fence>
 </clusternode>
</clusternodes>

<fencedevices>
<fencedevice name="manual" agent="fence_manual"/>
</fencedevices>

</cluster>

※この設定ファイルは、一番最初だけ全部のマシンにコピーしなくてはいけません。
しかし、クラスターが稼働してしまえば、一台のマシンの設定を変更し、
ccs_tool update /etc/cluster/cluster.conf
のコマンドで、クラスター内のすべてのサーバの設定ファイルが自動的に更新されます。

【注意】<cluster name="cluster1" config_version="5">のversion番号が、bindのseqのような役割になっています。
つまり、なにか設定を変えたら、この番号を変更(現在より大きくする)しないと、設定が有効になりません。

もし、番号を変更しないで、ccs_tool update を実行すると、
Proposed updated config file does not have greater version number.
Current config_version :: 5
Proposed config_version:: 5
って、言われます。

次に、/etc/default/cman を変更します。

CLUSTERNAME="cluster1"
NODENAME="poporon"   ←ここは各々のマシン名
USE_CCS="yes"
CLUSTER_JOIN_TIMEOUT=300
CLUSTER_JOIN_OPTIONS=""
CLUSTER_SHUTDOWN_TIMEOUT=6

ここまで準備できたら、手動でクラスタを起動します。
それぞれ、クラスターを組むサーバへ接続し、まずは3つの独立した接続ウィンドーを開いておきます。
次に、上記設定ファイルがちゃんと用意されているかどうか確認した後、/etc/init.d/cman start というコマンドをエンターを入力する寸前で止めます。
三つの画面で確認とコマンドの用意できたら、右手でマウス、左手をエンターキーに添えて、マウスで画面をクリックし切り替えながら、エンターキーを押していきます。つまり、ほぼ同時にコマンドを入力するという意味です。
※もちろん、きちんと設定できれば再起動するだけでクラスターは動き出しますが、まだもう少し設定が残っているので、まずは手動でクラスターを立ち上げます。

Starting cluster manager:
Loading kernel modules: done
Mounting config filesystem: done
Starting cluster configuration system: done
Joining cluster:cman_tool: Node is already active done
Starting daemons: groupd fenced dlm_controld gfs_controld
Joining fence domain: done
Starting Quorum Disk daemon: done

3台のマシンで上記のように表示されると、正常にクラスターが動いています。
もし、Waitingと表示がえんえん続く場合でもtime outが5分なので、ほっておけば止まります。

3.iSCSIで接続されているボリュームに対して、GFSで使えるようにパーティションを作り、初期化を行います。
※以下のマシンでは、GFS用のiSCSIボリュームは/dev/sddでした。
poporon:~# parted /dev/sdd
GNU Parted 1.8.8
Using /dev/sdd
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mklabel
Warning: The existing disk label on /dev/sdd will be destroyed and all data on this disk
will be lost. Do you want to continue?
Yes/No? y
New disk label type? gpt
(parted) mkpart
Partition name? []? xen_home
File system type? [ext2]? ext3
Start? 0
End? 10G
(parted) p
Model: IET VIRTUAL-DISK (scsi)
Disk /dev/sdd: 10.5GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number Start End Size File system Name Flags
1 17.4kB 10.5GB 10.5GB xen_home

(parted) q
Information: You may need to update /etc/fstab.

次に、gfs2でフォーマットします。
poporon:~# mkfs.gfs2 -p lock_dlm -t cluster1:gfs2 -j 4 /dev/sdd1
This will destroy any data on /dev/sdd1.
It appears to contain a gfs2 filesystem.

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

Device: /dev/sdd1
Blocksize: 4096
Device Size 9.77 GB (2559991 blocks)
Filesystem Size: 9.77 GB (2559988 blocks)
Journals: 4
Resource Groups: 40
Locking Protocol: "lock_dlm"
Lock Table: "cluster1:gfs2"

ボリュームは10Gありますので、ちょっと時間がかかります。
-jは同時接続するノード数です。 今回は2台なので -j 2 で良いのですが、後で拡張することを考えて4にしました。
-tのパラーメータは、クラスター名とファイルシステムの名前(これはテーブルで使う識別名なので、任意=なんでも良い)です。
-pは排他制御で使うロックシステムで、今回はclvmを使っているのでこのlock_dlmを指定します。

4.VM(仮想サーバ)を動かす準備をします。
これまで順に作業を行っていると、/home/xen はiSCSIボリュームになっているはずです。
この/home/xenに格納されている、VM(仮想サーバ)のイメージを、新しく作ったgfs2でフォーマットしたボリュームへコピーします。
【参考】今までのiSCSI関連のまとめはこちら

4-1. poporonとasterへログインし、xm listを発行し、動作しているVMがないかどうか確認する。
4-2. もし動いているVMがあれば、xm shutdown で、動作を停止する。

--- ここからは、Domain0どちらかのマシンで行う(つまり、poporonかasterのどちらかという意味)
4-3. /home/xen にmoutしているiSCSIボリュームをいったんumountし、別のディレクトリー(たとえば/mnt/iscsiとか作る)へmountしなおす。
4-4. 新たに作ったgfs2ボリュームを、/home/xenにmountする。
4-5. /mnt/iscsiの中身を、新しい/home/xenへすべてコピーする。

ls /home/xen/domains で、仮想サーバ用のディレクトリーが見えていることを確認し、xm create でVMを起動します。
※起動したVMにsshもしくは、xm consoleで接続し、正常に動作しているかチェックして下さい。

2台のDomain0(poporon and aster)で、gfs2ボリュームを/home/xenにmountした状態であればライブマイグレーションが実行できます。

poporonに接続し、VMを一台立ち上げます。
xm create /etc/xen/zaku.cfg

次に、以下のコマンドでasterへVMイメージを転送します。
xm migrate --live zaku aster

これで、動作が停止せず(コネクションも切れない)に、poporonからasterへVMが移動します。


最後に、再起動したときに自動的にmountするようにfstabを修正します。
gfs2でフォーマットしたボリュームにはUUIDがつかないので、論理ドライブ名で記述しますので、後でiSCSIや物理ドライブを追加・削除したりすると、論理ボリューム名が変わってしまうので注意が必要です。
/dev/sdd1       /home/xen       gfs2            _netdev         0       0

※これは、poporonのfstabです。 ポイントはファイルシステムの指定と、_netdevの指定(ネットワーク関連がすべて立ち上がってからmountするという意味)になります。

また、モジュールの起動順もデフォルトの状態だとうまくないので、変更します。
# update-rc.d -f open-iscsi remove
Removing any system startup links for /etc/init.d/open-iscsi ...
/etc/rc0.d/K81open-iscsi
/etc/rc6.d/K81open-iscsi
/etc/rcS.d/S45open-iscsi
# update-rc.d open-iscsi start 66 S . stop 81 0 6 . ←最後のピリオドを忘れずに!
Adding system startup for /etc/init.d/open-iscsi ...
/etc/rc0.d/K81open-iscsi -> ../init.d/open-iscsi
/etc/rc6.d/K81open-iscsi -> ../init.d/open-iscsi
/etc/rcS.d/S66open-iscsi -> ../init.d/open-iscsi


駆け足で書きましたが、クラスターシステムは止めずに運用するというのが前提なので、運用には癖があります。是非、検証用のシステムを作り、いろいろと操作してみて勘所をつかんでください。
※個人的には、今ひとつ動きがよくわからないところが多いです(たぶん、フェンス処理のあたりだと思っていますが…)。

次回は、クラスターが動いているシステムの運用Tipsやコマンド関連について書いてみます。
$雲の上はいつも青空-stopちょっと間が空いてしまいましたが、久しぶりに更新です。
クラスタ+GFSの構築と検証に、ずいぶん時間がかかってしまいました。

再度、与件と環境を整理しておきます。

【目的】
xen環境における仮想化において、複数の物理的に異なるサーバ間でライブマイグレーションを実現する。
この際、stableなDebianパッケージだけで環境を構築し、動作検証を行う。

【環境】
物理的に異なる3台のマシンで検証環境を構築する。
1.すべてのサーバは、Debian GNU 5.0 lenny + 標準Debianパッケージで構築する。
2.仮想サーバが利用するストレージは共有ストレージとし、iSCSIでDomain0と接続する。
3.iSCSIのターゲットとして1台、イニシエーターとしてDomain0を2台構築する。
4.ファイルシステムはGFS2を利用し、cmanでクラスタ化及び排他制御を行う。
※GFS2は以前は評価レベルでしたが、最新版のRed Hat Enterprise Linux 5.3から正式サポートになったようです。
http://ftp.wustl.edu/pub/centos5/NOTES/RELEASE-NOTES-U3-ja.html

【結果】
1.仮想サーバの起動、及びライブマイグレーションは完動。
2.クラスターを安定して構成・維持が難しい(一度動いてしまえば安定)。
3.スループットについては注意が必要(後述)。

クラスタ+GFSが思ったより癖があるので、ストレージ用に1台、Domain0で2台構成の場合、iSCSIだけを使った構成の方が運用は楽かもしれません。
この場合は、Domain0の一方がマスター(すべての仮想サーバを起動)として、残りはホットスタンバイとして待機し、マスター機に障害が発生した場合や、メンテナンス時だけにライブマイグレーションですべての仮想サーバを移動させるという運用になります。

また、cmanを使ってクラスタを組む場合には、本来、障害発生機をクラスタから切り離すための仕組み(フェンスデバイス)を持つ必要がありませす。
例えば、UPSに指示して電源を強制的に落とすとか、スイッチに指示してネットワークから切り離すとか…
しかし、今回は検証用なのでフェンスデバイスは手動となっています。
本格的にクラスタを業務用に使うには、なんらかのフェンスデバイスと仮想サーバを移動、もしくは再立ち上げを自動で行うシステムが必要です。
このような自動的なHA構成は商業用の仮想化システム(VMware、CiTRIX等)ではサポートされています。

つまり、今回実験したような構成は、あくまで手動で管理・運用していて、複数のDomain0を動かしているときに、ライブマイグレーションを使いたい場合にのみ適用という事になります。
自動的に障害対応をするわけではないので、HA構成とは違います。
あくまで、運用が快適・迅速になる事を期待するシステムです。

〇Domain0で障害が発生しても、仮想サーバのイメージは別のストレージにあるので再立ち上げが早い。
〇仮想サーバのイメージはハードウェアから独立しているので、Domain0のサーバはすべて同じである必要はない。
〇ライブマイグレーションが可能なので、Domain0の機器交換・再起動等でサービスを停止しなくて良い。
〇仮想サーバの負荷に応じて、ライブマイグレーションを使いDomain0間を無停止で移動できる。

【IOのスループット】
LinuxのHDDベンチマークの定番であるbonnie++を使い、IOとしてのスループットを計測しました。
※キャッシュの影響をなくすため、約5GB(5528MB)のファイルを読み書きしています。
※単位はMB/secです。
※キャラクター:1バイトづつ処理、ブロック:一番効率の良いブロック単位で処理
          シーケンシャル 5532MB
write キャラクター  % ブロック % read キャラクター % ブロック %
local 53060 55058         40772 69871
iSCSI 24483 46.1 20497 37.2 45914 112.6  50451 72.2
iSCSI+GFS 17874 33.7 23600 42.9 28471 69.8  38011 54.4
このデータを見る限り、スループットの低下は思ったよりはげしいものです。
おおざっぱに見ても、iSCSI+GFSではlocalのHDDに比べて、スループットが半分以下になることが解ります。
※iSCSIとSANの比較については、オラクルの中嶋さんのブログが詳しいです。
 とても参考になります。

5GBのファイルを扱うというのは、純粋にIOのスループットを見るには良いのですが、もうすこし現実的なデータでスループットを見てみると、ちょっと感じが変わってきます。
以下のデータはVM(仮想サーバ)上でのスループットです。
                        write                   read
ファイルサイズ キャラクター ブロック キャラクター ブロック
VM local 512M 63627 193607 75285 441319
VM iSCSI+GFS 512M 63350 257508 76071 365103
VM iSCSI+GFS 1024M 62207 234266 77055 395390

このデータを見る限り、実用域にあるように思えます。
※実際に触ってみても体感的に遅い感じはしません。
※特にキャッシュが効いているようでwriteが早い!

あとは一番大切な信頼性ですが、これはベンチマークでは解りませんのでしばらくテスト運用してみるつもりです。

■検証結果の考察が長くなったので、具体的な設定方法等は別に書くことにします。
最近話題の必殺仕分け屋さんですが、とんでもない話がたくさんあるようです。
私は、ブログには政治の話は原則書かない主義なのですが、これは『ちょっと!』と思いました。

--- 引用はじめ ---
去る11月11日(水)の行政刷新会議の事業仕分け作業で、医療用漢方製剤(漢方エキス製剤・煎じ薬)を健康保険から除外する、という案が出されました。
--- 引用おわり ---

眼が点になりました。
漢方薬は保険適用外? はぁ~?

漢方薬は、『副作用もないかわりに効果も低い(おだやかともいう)』と思っている方が多いようですが、しっかりとした漢方医が処方した漢方薬は、びしっと効きますし、それなりに副作用もあります。

また、漢方薬は長期にわたって飲み続けることも多いので、これはちょっとまずいな…と思います。
※保険適用外になると値段が跳ね上がります。たぶん、3~5倍!

もし、リンク先の内容を読んでいただいて、賛同していただけるのであれば、是非署名をお願いします。

最近の政治家は、何を考えているのか、さっぱりわかりません…

※どうも本件は、マスコミ誘導のガセっぽいようです。
(どうも、仕分け人を叩きたい人が沢山いるようで…)