Linuxでクラスタ～heartbeatを試す（そして苦しむ）～その１ [Linux(CentOS/VineLinux)]
確か、このblogが個人的に（ｒｙ
で、以下本編。
むか～しむかし（でもないけど）、あるところに（具体的にはｈｐ）、「Service Guard for Linux」（以下「SGLX」と記述）というクラスタソフトがあったそうな。
お爺さんは山へ（ｒｙ
じゃない。そのSGLXが2009年に…
「あんまり売れないから、もう開発や～めた！サポートもそのうち終了するよ～ん！」
ということになったそうな。
お爺さんとお婆さんは大層、困ったそうな。
あるとき、お婆さんが川に洗濯にいくと、川の上流から、陽気なホモが(ﾏﾃ
じゃない、大桃美代子が(ｺﾗ
じゃない、大きな桃が どんぶらこ～どんぶらこ～と流れてきたそうな。
お婆さんは桃を持ち帰ると、中から「Heartbeat」という、クラスタソフトが出てきたそうな…
というわけで、会社でｈｐ製のサーバにｈｐ製のクラスタソフトを導入していたんだけども、ｈｐがかくのごとく通知をしてきたので、
選択肢その１：最後まで使い切る
選択肢その２：乗り換える。（ClusterProとか？）
と、悩んでいたですよ。
で、「Heartbeat」があるって事がわかったので、いっちょコイツを試してみようか！ということに。（笑）
ちょうどいま、そのクラスタ構成のサーバが開店休業中で好き勝手にできるという幸運（？）が重なったため、好き勝手することにした。
だがしかし。道のりはつらく苦しいものとなったのであった。（血涙）
そしてその現在コレを書いている時点でもまだ道のりは半ばなのであってまだ完成を見ていないのであった。（滝涙）
敢えて拾わん！火中の栗を！！
をテーマに、元気良くがんばって逝きたいとおもいます。（笑）
さて、今回ここで私が「好き勝手」する環境を以下に示そう。
てな具合。豪華すぎるシステムだ！（笑）
サーバは大量のデータを格納するためのNFSサーバって感じで、ファイバーチャネル接続されたディスクの塊がある。FCのカードも経路もストレージサーバ側のコントローラも全て二重化されており（もちろんサーバも！）、サーバから見るとストレージサーバ上にあるディスクは同じものが都合4個見えるという寸法だ。（笑）これはmultipathdを使用してdevice mapper multipathの機能により1個のディスクに見えるように仕立てる必要がある。
一方、サーバのクラスタ動作についてはHeartbeatを使用し、
１：VIPの管理
２：共有ディスクの管理
３：NFSデーモンの管理
を担当させることとなる。
それでは、さっそく両サーバのセットアップから。
① とにかくＯＳのインストールから。ここではCentOS 5.5 x86_64を使用した。
② パッケージのアップデート、必要なパッケージ類のインストール
③ （ｈｐ製サーバなので…）ｈｐ製のドライバやらサポートユーティリティ類のインストール
④ 共有ディスクの作成
⑤ device mapper multipath の設定
⑥ いよいよHeartbeatのインストール
⑦ Heartbeatの初期設定（～VIPの設定まで）
この辺から手をつけよう。
① とにかくＯＳのインストール
ＯＳをインストールする。「クラスタシステム」ということもあり、サーバのハードウェア構成はもちろんのこと、ディスクの切り方等も同一にしておこう。まあ、Heartbeat的には、厳密に一緒じゃなくても問題なく動く。
ＯＳのインストールで他に気をつけるべきことは無いし、常識的なセットアップならまあ大丈夫だろうと思うので、ここでは具体的手順は省略する。
なお、インストールパッケージはBaseのみを選択したことを付け加えておく。
② パッケージのアップデート、必要なパッケージ類のインストール
サーバが起動したら、IPv6の無効化とか（必要なら）言語設定とかそういうのを実施。
続いて yum -y update でパッケージ類のアップデートを実行。
クラスタシステムを構築する以上、両サーバの時計の一致が非常に重要になってくる。よって、
yum -y install ntp
として、ntpを忘れずにインストールする。
追加でインストールするパッケージだが、ｈｐ製のドライバとかサポートユーティリティをインストールするため
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ならそちらで必要なパッケージをインストールすることになろう。
③ （ｈｐ製サーバなので…）ｈｐ製のドライバやらサポートユーティリティ類のインストール
ここは省略。IBMのサーバならIBMの、DELLのサーバならDELLの、NECのサーバならNECの、富士通のサーバなら富士通の、あとなんだっけｗ
④ 共有ディスクの作成
ここも省略する。ストレージサーバ側で共有ディスクを作成する。
まあ、ケースによってはWWNをメモしとけとかLUNをメモしとけとかあるかもしれないね。
⑤ device mapper multipath の設定
multipathdの設定を行う。
まずサーバ側のFCインタフェースからストレージ側のWWNが見えないことにはどうしようもないので、FCインタフェースに付属のツールを使うなりして、WWNの再取得を行う。…か、サーバを再起動してしまう。（笑）
編集するのは /etc/multipath.conf で、デフォルトのままだと全てのパスをマルチパス設定しないことになっている。
極論すると、
だけ記述されていればだいたい問題になることはない。（笑）
心配性な人は
みたいに書いておく。
「blacklist」のブロックは、multipathdによる管理の対象から外したいデバイスについて記述する。ここではｈｐ製サーバなので、「/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を起動する設定を導入する際、３２ビット版ＯＳの場合は/usr/lib/heartbeat/pingdになるが、６４ビット版ＯＳの場合は/usr/lib64/heartbeat/pingdになるので要注意。よくあるサンプルをコピペするだけだとここで最初に躓く。（笑）
続いて /etc/ha.d/authkeys を作成する。ぶっちゃけ
とかやっとけばおｋ。パスフレーズは何でも構わない。
続いて、Heartbeat最大の難物、 /var/lib/heartbeat/crm/cib.xml だ。（笑）ちなみにこのファイルは３２ビット版だろうと６４ビット版だろうと「lib」の部分は変わらないので念のため。
cib.xmlは、クラスタ・リソース・マネージャに関する設定を事細かに記述するファイルであるが、最初の「雛形」は自動生成することができるので、まずはその機能を利用しよう。
heartbeatを起動すればよい。
service heartbeat start
ha.cfとかが問題なく用意されていればこれで起動出来る。
cib.xmlには大きく分けて４つのカテゴリが用意されており、
crm_config
nodes
resources
constraints
のうち、上の二つ「crm_config」と「nodes」について必要最低限の情報が自動作成される。
あとはresourcesとconstraintsに情報を追加すれば終了ということになる。
まずは、クラスタシステムが使うVIPを設定してみる。
最低限必要な情報は次の３つ。
・IPアドレス
・IPアドレスを割り付けるNICのインタフェース名
・ネットマスク
すぐに用意できる情報だろう。
それでは、この情報をcib.xmlに記述する。まったくクールでない、手書きの方法で紹介するのでお付き合いいただきたい。（大笑）
あ、まずheartbeatを停止しておくように。
service heartbeat stop だ。
なお、停止する際ものすご─────────く時間がかかることがある。あわててCtrl+Cしてしまわないように。（笑）気長に待つべし。
⑦-1：「<resource />」タグを書き換える
<resource />タグが1個だけ記述されているので、これを
<resource>
</resource>
という具合に書き換える。以降の追記はこの２つのタグの間に挟みこむように行う。
⑦-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>タグで記述したフレームワークなりコマンドなりによって必要とされるパラメータが異なるが、ひとまずここでは以下の３つを使用して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以外のファイルが作成されることもある。
この場合、heartbeatの停止を確認してから、cib.xml以外のファイルは削除すること。（cib.xmlまで消さないように！ｗ）
では、heartbeatを起動してみよう！！両サーバ共に起動すると…
ｷﾀｰ！！！！
で、以下本編。
むか～しむかし（でもないけど）、あるところに（具体的にはｈｐ）、「Service Guard for Linux」（以下「SGLX」と記述）というクラスタソフトがあったそうな。
お爺さんは山へ（ｒｙ
じゃない。そのSGLXが2009年に…
「あんまり売れないから、もう開発や～めた！サポートもそのうち終了するよ～ん！」
ということになったそうな。
お爺さんとお婆さんは大層、困ったそうな。
あるとき、お婆さんが川に洗濯にいくと、川の上流から、陽気なホモが(ﾏﾃ
じゃない、大桃美代子が(ｺﾗ
じゃない、大きな桃が どんぶらこ～どんぶらこ～と流れてきたそうな。
お婆さんは桃を持ち帰ると、中から「Heartbeat」という、クラスタソフトが出てきたそうな…
というわけで、会社でｈｐ製のサーバにｈｐ製のクラスタソフトを導入していたんだけども、ｈｐがかくのごとく通知をしてきたので、
選択肢その１：最後まで使い切る
選択肢その２：乗り換える。（ClusterProとか？）
と、悩んでいたですよ。
で、「Heartbeat」があるって事がわかったので、いっちょコイツを試してみようか！ということに。（笑）
ちょうどいま、そのクラスタ構成のサーバが開店休業中で好き勝手にできるという幸運（？）が重なったため、好き勝手することにした。
だがしかし。道のりはつらく苦しいものとなったのであった。（血涙）
そしてその現在コレを書いている時点でもまだ道のりは半ばなのであってまだ完成を見ていないのであった。（滝涙）
敢えて拾わん！火中の栗を！！
をテーマに、元気良くがんばって逝きたいとおもいます。（笑）
さて、今回ここで私が「好き勝手」する環境を以下に示そう。
てな具合。豪華すぎるシステムだ！（笑）
サーバは大量のデータを格納するためのNFSサーバって感じで、ファイバーチャネル接続されたディスクの塊がある。FCのカードも経路もストレージサーバ側のコントローラも全て二重化されており（もちろんサーバも！）、サーバから見るとストレージサーバ上にあるディスクは同じものが都合4個見えるという寸法だ。（笑）これはmultipathdを使用してdevice mapper multipathの機能により1個のディスクに見えるように仕立てる必要がある。
一方、サーバのクラスタ動作についてはHeartbeatを使用し、
１：VIPの管理
２：共有ディスクの管理
３：NFSデーモンの管理
を担当させることとなる。
それでは、さっそく両サーバのセットアップから。
① とにかくＯＳのインストールから。ここではCentOS 5.5 x86_64を使用した。
② パッケージのアップデート、必要なパッケージ類のインストール
③ （ｈｐ製サーバなので…）ｈｐ製のドライバやらサポートユーティリティ類のインストール
④ 共有ディスクの作成
⑤ device mapper multipath の設定
⑥ いよいよHeartbeatのインストール
⑦ Heartbeatの初期設定（～VIPの設定まで）
この辺から手をつけよう。
① とにかくＯＳのインストール
ＯＳをインストールする。「クラスタシステム」ということもあり、サーバのハードウェア構成はもちろんのこと、ディスクの切り方等も同一にしておこう。まあ、Heartbeat的には、厳密に一緒じゃなくても問題なく動く。
ＯＳのインストールで他に気をつけるべきことは無いし、常識的なセットアップならまあ大丈夫だろうと思うので、ここでは具体的手順は省略する。
なお、インストールパッケージはBaseのみを選択したことを付け加えておく。
② パッケージのアップデート、必要なパッケージ類のインストール
サーバが起動したら、IPv6の無効化とか（必要なら）言語設定とかそういうのを実施。
続いて yum -y update でパッケージ類のアップデートを実行。
クラスタシステムを構築する以上、両サーバの時計の一致が非常に重要になってくる。よって、
yum -y install ntp
として、ntpを忘れずにインストールする。
追加でインストールするパッケージだが、ｈｐ製のドライバとかサポートユーティリティをインストールするため
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ならそちらで必要なパッケージをインストールすることになろう。
③ （ｈｐ製サーバなので…）ｈｐ製のドライバやらサポートユーティリティ類のインストール
ここは省略。IBMのサーバならIBMの、DELLのサーバならDELLの、NECのサーバならNECの、富士通のサーバなら富士通の、あとなんだっけｗ
④ 共有ディスクの作成
ここも省略する。ストレージサーバ側で共有ディスクを作成する。
まあ、ケースによっては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による管理の対象から外したいデバイスについて記述する。ここではｈｐ製サーバなので、「/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を起動する設定を導入する際、３２ビット版ＯＳの場合は/usr/lib/heartbeat/pingdになるが、６４ビット版ＯＳの場合は/usr/lib64/heartbeat/pingdになるので要注意。よくあるサンプルをコピペするだけだとここで最初に躓く。（笑）
続いて /etc/ha.d/authkeys を作成する。ぶっちゃけ
auth 1 1 sha1 password_hogehoge
とかやっとけばおｋ。パスフレーズは何でも構わない。
続いて、Heartbeat最大の難物、 /var/lib/heartbeat/crm/cib.xml だ。（笑）ちなみにこのファイルは３２ビット版だろうと６４ビット版だろうと「lib」の部分は変わらないので念のため。
cib.xmlは、クラスタ・リソース・マネージャに関する設定を事細かに記述するファイルであるが、最初の「雛形」は自動生成することができるので、まずはその機能を利用しよう。
heartbeatを起動すればよい。
service heartbeat start
ha.cfとかが問題なく用意されていればこれで起動出来る。
cib.xmlには大きく分けて４つのカテゴリが用意されており、
crm_config
nodes
resources
constraints
のうち、上の二つ「crm_config」と「nodes」について必要最低限の情報が自動作成される。
あとはresourcesとconstraintsに情報を追加すれば終了ということになる。
まずは、クラスタシステムが使うVIPを設定してみる。
最低限必要な情報は次の３つ。
・IPアドレス
・IPアドレスを割り付けるNICのインタフェース名
・ネットマスク
すぐに用意できる情報だろう。
それでは、この情報をcib.xmlに記述する。まったくクールでない、手書きの方法で紹介するのでお付き合いいただきたい。（大笑）
あ、まずheartbeatを停止しておくように。
service heartbeat stop だ。
なお、停止する際ものすご─────────く時間がかかることがある。あわててCtrl+Cしてしまわないように。（笑）気長に待つべし。
⑦-1：「<resource />」タグを書き換える
<resource />タグが1個だけ記述されているので、これを
<resource>
</resource>
という具合に書き換える。以降の追記はこの２つのタグの間に挟みこむように行う。
⑦-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>タグで記述したフレームワークなりコマンドなりによって必要とされるパラメータが異なるが、ひとまずここでは以下の３つを使用して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まで消さないように！ｗ）
では、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
ｷﾀｰ！！！！
ぴろりん さん
-
nice! 18
記事 143
テーマ パソコン・インターネット
プロフィール
ブログを紹介する
コメント 0