Linux-HA Japan

7月14日(金)と15日(土)に開催されたOSC2011 Kansai@Kyotoに行ってきました。
クリアフォルダ250枚と団扇300枚は2日目の
終了3時間前くらいになくなってしまいました。
次回のOSC＠名古屋でも配布する予定なので
ご希望の方はお早めにブースまでお越しください。

 

 

 

 

 

 

 

 

 

 

また、猛暑にもかかわらず、2日目11時からのセミナーには40名の方に参加していただきました。
講師は「あ、eject の方？」でお馴染みの、たなかさんでした。おつかれさまでした！
当日の資料はこちらからダウンロードすることができます。

今回は、ブースでお留守番をしていたときにいただいた質問と、
セミナーの最後にいただいた質問をおさらいしてみようと思います。

ブースでいただいた質問

(1) Pacemakerは仮想環境でも使用できるか？
(2) 必要なNICの本数は？
(3) 事例は公開されているか？
(4) 将来の目標は？
(5) 読み方はピースメーカー？ペースメーカー？
(6) BSDで使えるか？

(1) Pacemakerは仮想環境でも使用できるか？

使えます。
OSC関西＠京都のセミナーでは仮想環境でデモを行いました。
資料にも「本日のPacemakerデモ環境」として仮想環境でのクラスタ構成が紹介されています。
仮想環境の構成には

• ゲストOSにPacemakerをインストールするパターン
• ホストOSにPacemakerをインストールするパターン

の2パターンがあります。

ゲストOSにPacemakerをインストールするパターンは、ゲストOS≒物理サーバです。

ホストOSにPacemakerをインストールするパターンは、ゲストOSを「リソース」として
VirtualDomain RAで監視します。
ゲストOSのマイグレーションとかもできます。
このパターンでは、ゲストOS上で起動している特定のプロセスは監視できないので、
ホストOSにもゲストOSにもPacemakerをインストールする多層式の構成となる場合もあります。

(2) 必要なNICの本数は？

ノード間で生死を確認しあうためのインターコネクトLANは絶対に必要です。
なので、インターコネクトLAN用に最低でも1本は必要です。
ただし、インターコネクトLANは2本以上用意して冗長性を確保することが推奨されています。
その他にも、WebサーバやDBなど、外部からアクセスするための仮想IPアドレスが必要なサービスの場合は仮想IP用のサービスLANも必要となります。
サービスLANは2本以上用意して冗長性を確保することが推奨されています。
サービスLANを冗長化する場合はbondigを利用してください。

そういえば、インターコネクトLANはbondingしなくていいの？と思われるかもしれませんが、
メッセージングレイヤにHeartbeatを使用する場合は、bondingでもbondingでなくてもどっちでもいいです。
ただし、Corosyncを使用する場合はbondingを使用したほうがよいかもしれません。
Corosyncは複数のインターコネクトLAN構成で、接続が切れたり繋がったりしたときの
「表示系」がまだちょっと弱かったような気がする。。
動作は問題ないはず（たぶん）。
最近は直ってきたのかもしれません。v1.4でたし！？

一方、メッセージングレイヤにHeartbeatを使用する場合は、bondingを使わない場合が多いような気がします。
ha.cfにインターフェース名を複数書けばいいだけの話しなので、わざわざbondingにしなくてもいいよねえ、というかbondingドライバのバグにはまっちゃうとヤダとかそういうのもあったような気がする。

インターコネクトLAN、サービスLANの他に、管理者や運用担当者、もしくは運用管理ツールがPacemakerの実行状況などを確認するための管理LANも別系統であると便利かもしれません。
管理LANはそれほどがつがつ使うこともないはずなのでインターコネクトLANまたはサービスLANと兼用でも問題ありません。

DRBDも組み合わせて使用する場合は、DRBDの同期LANも必要となります。
DRBDは、一つの同期リソースにつき、1本の同期LANしか設定することができないので
bondingで冗長化することが推奨されています。
同期リソースが複数ある場合は、同期LANの本数を増やす、もしくは
1本の同期LANで複数のポートを使用することになります。

というわけで

最小構成(合計1本)

• インターコネクトLAN    1本

冗長構成(合計7本)

• インターコネクトLAN    2本
• サービスLAN               2本(bondingで1本に集約)
• 管理LAN                     1本
• DRBDの同期LAN          2本(bondingで1本に集約)

となります。

(3) 事例は公開されているか？

Linux-HA Japanの公式サイトで事例の公開は行っていません。
お隣にブースを出していただいた株式会社サードウェアさんのWebサイト「Linux-HA (DRBD) ユーザ事例」からDRBD関連の事例をダウンロードすることができます。
Linux-HA Japanの公式サイトにも事例を公開していきたいのですが、いろいろと大人の事情で難しいようですね…。
「公開しても問題ありません」という案件や実際に稼動しているシステムがあれば、ぜひメーリングリストまでご連絡ください。

 

(4) 将来の目標は？

ちょっとのけぞりましたが、これって今後のロードマップってことですね。
一瞬、小学校の卒業文集的なナニカかと思いましたよ…。
ちなみに、あんどりゅーくんのつくったロードマップはこちら。
ロードマップというより、これから実装していきたい機能の落書き帳的なものなので、実装予定期日は決まっていません。
他にも

• 仮想環境対応(キーワード：Matahari)
• 大規模クラスタ対応

などがメーリングリストで話題になっています。

 

(5) 読み方はピースメーカー？ペースメーカー？

ペースメーカーです。
ピースメーカーだと Peacemakerになっちゃう気がします。Pacemakerです。

(6) BSDで使えるか？
残念ながらBSDは未踏領域です。人柱大募集です。
Linux-HA Japan では、RedHat, CentOS用のRPMを作成していますが、
あんどりゅーくんの管理している clusterlabs からはFedora, openSUSE, EPEL用のRPMがダウンロードできます。

Debianは「はらくん」がパッケージングしてくれるらしいよ。

はらくん(高校2年生)

めっさいじられてますけど。

今月も、先月にひきつづきリリースてんこもり月間でした。
というわけで、まずは各製品のリリース情報を簡単にご紹介します。
知恵袋では、crm シェルを使ってリソースの故障情報を削除する手順を解説します。

1. リリース情報
2. 知恵袋

 

1. リリース情報

1.1 Linux-HA Japan Pacemakerリポジトリパッケージ 1.0.10-1.4.2 のリリース(2011/06/06)

以下の拡張パッケージが更新されています。

• crmファイル編集ツール(pm_crmgen)
• 拡張リソースエージェント・プラグイン(pm_extras)
• ログメッセージ制御機能(pm_logconv-hb)

詳細はこちらを参照してください。

1.2 rerource agents 3.9.1 のリリース(2011/06/16)

今回のリリースの特徴は、Linux-HAで開発してきたRAと
Red Hat Cluster Suiteに含まれるrgmanager用のRAが統合された点です。
Linux-HAのRAは前回のリリースが 1.0.4 だったのですが
rgmanager側が 3.1系のブランチを持っていたため
数字の大きなrgmanagerにあわせて、3.9.1 からのリリースとなりました。

rgmanagerは使わないから、Linux-HA用のRAだけインストールしたいなあ
という場合は、ビルド時に –with-ras-set オプションを指定する必要があります。
（with の前のハイフンは2個です）
デフォルトは –with-ras-set=all なので
Linux-HA も rgmanager もインストールされちゃいますが
–with-ras-set=linux-ha　　  とすると、Linux-HAだけ
–with-ras-set=rgmanager　とすると、rgmanagerだけインストールすることができます。

RHEL6.1での操作例

# git clone http://github.com/ClusterLabs/resource-agents/ # cd resource-agents/ # git checkout v3.9.1 # ./autogen.sh # ./configure –with-ras-set=linux-ha # make   # make install または # make rpm

Linux-HA用のRAには次の修正が取り込まれています。

Highlights for the LHA resource agents set:

– lxc, symlink: new resource agents
– db2: major rewrite and support for master/slave mode of operation
– exportfs: backup/restore of rmtab is back
– mysql: multiple improvements for master/slave and replication
– ocft: new tests for pgsql, postfix, and iscsi
– CTDB: minor bug fixes
– pgsql: improve configuration check and probe handling

目新しいところでは、Linux Containers用のRA(lxc)とsymlink用のRA(symlink)が新しく追加されています。
リリースノートの全文はこちらを参照してください。

で。
3.9.1 がリリースされてはみたんですが、
iscsi RA と pgsql RA に問題発生！と若干祭りになりまして
（まあこのRA使ってるユーザが局所的に盛り上がってしまっただけですが）
でやんくんが「ちょっともう3.9.2にしちゃおっか」と決心しました。

Linux-HA Japan も6月末にパッケージ群の更新を予定していたので
どうせなら 3.9.2 を待とうということになったのですが、3.9.2、実はまだでていない。
「6月24日にだしたいねー」とでやんくんが言っていたのですが
その後、どみにくさんが「VirtualDomain RA もちょっと修正したい」と
いろいろ揉めてまして、そんなこんなで本日(6月30日)に至っております。
つーか、たぶんあとはタグをふるだけだと思うんですよねー。
今日中にでそうな気がするんだけどなー。

2011年6月30日19時追記
3.9.2 でました！日本時間16時45分にアナウンスがありました。

1.3 Heartbeat 3.0.5 のリリース(2011/06/16)

約半年ぶりに Heartbaet 3系のリリースが行われました。

Changelog:
– do not request retransmission of lost messages from dead members
– fix segfault due to recursion in api_remove_client_pid
– properly cleanup pending delayed rexmit requests before reset of seqtrack
– create HA_RSCTMP on start, if necessary
– improve detection of pacemaker clusters in init script

最初の3つは、発生条件が限られているので、よっぽどのことがない限り
この修正の恩恵にはあずからないかもしれません。
残り2つは、一時ディレクトリの作成や起動スクリプトの改善なので
実行時の動作に大きな影響を与える修正ではありません。

で。
こちらもリリースの翌日にこんな修正がとりこまれています。

コメントをぱっと見た感じ、32ビットだとなにか恐ろしげなことがおこるとか？
実は64ビットのほうがやばいんじゃね？という噂もありますが
どっちにしろ気になる修正です。

Linux-HA Japan のパッケージに含まれる Heartbeat 3.0.5 は
上記の修正も取り込んだ状態でビルドしています。

今回はリリースの直後にばたばた修正が入るパターンが多くて、やれやれでしたわ…。

ここ最近、あんどりゅーくんよりふぃりっぷくんが荒ぶってましたなあ。
ということで、今月はDRBDのリリースノートを一生懸命読んでみました。
リリースといってもまだ rc なので、正式版が出た段階で改めてご紹介したいと思います。

今月のお題はこちらのお二つ。

1. リリース情報
2. 知恵袋

 

1.リリース情報

drbd-8.4.0rc1のリリース

DRBD 8.4.0rc1がリリースされました。
8.3系からの大きな変更点は、こちら。

The most noticeable change is the support for multiple replicated volumes in a single DRBD connection.

8.3系では、一本の同期LANで複数のリソース（ブロックデバイス）を同期させたい場合
リソースごとに同期用のポート番号を変える必要があったのですが
8.4系では「volumes」というパラメータを使って、同一の同期LANかつ同一のポート番号で
複数のリソースを同期することができるようになりました。
「プロトコルAを使用して遠隔地への同期処理を実行しているユーザにとってもこの機能は重要である（直訳）」
とも書いてありました。

volumesの設定方法はこんな感じ。
drbd.confを見慣れてる人は「なるほど！」ですね。

 

drbd-8.4.0rc2のリリース

間をおかず、rc2もリリースされました。
rc2のアナウンスではサポートするカーネルのバージョンが2.6.18となっています。

With this rc we have the compatibility code in place.
It is expected to work on kernels 2.6.18 and newer. I.e. RHEL5.
* Compatibility code down to at least kernel 2.6.18

私が検証用OSとしてRHELしか使っていないので、RHELのバージョンに限って話をさせていただくと
RHEL5 → OK、RHEL6 → NGということになります。
なんでRHEL6がだめかっていうバックグラウンドはこちら。

Background: the bio->bi_rw flags have been changed a few times
in the upstream kernel, and RHEL 6.1 changed it again in yet some
different way, so the compat wrappers and ifdefs in DRBD don’t get it
right yet, leading to a compile error.

RHEL 6.1ではbio->bi_rwフラグの取り扱いが変更されており、DRBDはそれに対応できていないとのこと。
（8.3系も8.4系もどっちも未対応です）
なんでRHEL 6.1からそんなん変わるの！というのは
なんかいろいろ大人の事情があるんでしょうねー。もうしらーん。
ちなみに今回の人柱は @bellche さんでした！
さらにちなみにですが、RHEL 6.0+DRBD 8.3.10は動いたので、これはこれで紛らわしい。
あ、この組み合わせはたぶん偶然うまくいったパターンなのでお勧めはしないですよ。
RHEL 6.0はこんなとこではみだしてて大丈夫なのか。
8.4.0の正式リリースでRHEL 6.1も対応してくれるのかなあ。
でも、がっつり修正が入っちゃうようだと、.0はちょっと人柱すぎるという気がしないでもない。

drbd-8.3.11rc1のリリース

こちらは、8.3系のバグフィックスです。
大きな変更点は、こちら。

The most subtlety bug fixed with this release is in the area of the max_bio_size negotiation:

DRBDがローカルのブロックデバイスをプライマリ化して対向ノードと接続した後に
ローカルのディスクを「attach」すると、プライマリのmax_bio_sizeがちっさくなっちゃってたらしいです。
想像するに、絶好調で同期処理をしてる最中に、プライマリで

# drbdadm attach all

を実行したというような状況なんですかね。
で、タイミングによってはmax_bio_sizeがちっさくなる前のブロックI/Oと
ちっさくなっちゃったブロックI/Oがまざっちゃって困ったことが起こる
という意味だと思うんですが、実際どんな困ったことがおこるっていうのがたぶんこれ？
リブートしちゃったりとかではなく、ログに「ASSERT」ってでちゃうだけなのかな？
という気もしますが、8.3.11ではこのへんも修正されているようです。
あとちょっと気になったのはこの一行。

* Fixed the behaviour in case ping-timeout and ping-int are set to the same value

ping-timeoutとping-intの値を同じに設定していると、何がおこるんだ…。
それぞれのデフォルト値は

• ping-timeout 10秒
• ping-int 500ミリ秒

なので、drbd.confでこれらのパラメータを「設定していない」場合は問題ありません。

 

Hawk (HA Web Konsole) 0.4.1のリリース

Hawk、地味に（失礼）進化を続けています。
が、まだ0.4。
1.0になるのはいつのことやら。

今、Hawkにできることはこちら。

• クラスタの状態監視
• クラスタの操作（オンライン化/スタンバイ化/停止）
• リソースの開始/停止/移動
• リソースの作成/変更/削除
• クラスタプロパティの変更
• location(配置制約),colocation(同居制約),order(順序制約)の作成/変更/削除 ← 0.4.1からの新機能！

先月のあんどりゅーくんからはや一ヶ月。
第二回にしてすでにいっぱいいっぱいですが
今回は、4月のメーリングリストから下記の情報を抜粋してご紹介します。

1. リリース情報
2. 知恵袋

 

1. リリース情報

4月は下記のリリースが行われました。

• Hawk 0.4.0 のリリース（2011年4月19日）
• Corosync 1.3.1 のリリース（2011年4月25日）
• Pacemaker 1.2 のリリース予定発表（2012月8月22日）

 

1-1. Hawk 0.4.0

Hawk (HA Web Konsole) は Tim Serong@Novell が開発を担当しているGUIです。
てぃむが頑張って Wiki に書き込んでくれているので、このページを見ると大体どんなもんかわかります。

そもそも、Pacemakerで構築されたクラスタを管理するためのツールは、Hawk以外にも

• コマンドラインツール
• Python GUI
• DRBD MC

などがあります。

コマンドラインツールの代表的なものとして、crm_standby, crm_resource, cibadmin などがあるわけですが
如何せんこの方々はオプションの指定が複雑で、かなり一見さんお断りな雰囲気を醸し出しておるわけですな。
で、もう少しなんとかしましょうというわけで Dejan Muhamedagic@Novell がもりもりつくっている
crm というコマンドラインツールもあるんですが、こちらはタブキー補完が使えるので、オプション名を忘れがちなお年寄りにも
優しい仕様となっております。
crm はかなりいい。お勧めです。
とは言っても、やっぱりGUIのほうがいいんだよねーというか、他の商用製品と比較したとき「GUIないの？」って
聞かれちゃうことも多いんですよね。
そこで、Python GUI、DRBD MC、Hawkの出番です。

・Python GUI
Pythonでできてます。
クラスタとクライアントの両方にPython GUIをインストールする必要があります。
Hawk視点でいうと「インストールが難しい！（by てぃむ）」というのが欠点なわけですが
最近インストールしてないからなあ、どうなんだろう。
結構昔からあるツールなので機能的にはそこそこてんこ盛りです。
日本語対応しています。

・DRBD MC
Javaでできてます。
クラスタに ssh サーバ、クライアントに DRBD MC をインストールする必要があります。
クラスタとクライアントは ssh で通信します。
どんなツールかっていうとこれはもう、「DRBD-MCを使って10分でクラスタを組もう(動画デモ)」を見ていただくしかないかと。
日本語対応しています。

・Hawk
Rubyでできてます。
クラスタにHawkをインストールし、クライアントはWebブラウザからクラスタに接続します。
クラスタとクライアントは http で通信します。
0.3系ではクラスタの状態表示やノードのスタンバイ/オンライン化、リソースの移動など
設定済みのクラスタに対する操作を実行することができていましたが
先日リリースされた0.4系ではクラスタの設定変更も可能となりました。
今後は、実際のクラスタには影響を与えずに擬似故障を再現する機能（シャドーCIB）も追加されるらしいです。
この機能って運用フェーズでは必要ないだろうけど、故障試験とか障害解析とかやってる人にとってはありがたいっすねー。
てぃむ曰く「インストール簡単！」とのことですが、rubygemsの依存関係がいっぱいあって結構うざいと思うけど。。。
SUSE用にはRPMが用意されていますが、他のディストリビューションはソースからビルドする必要があります。
Hawkはまだまだ発展途上なので、機能的には Python GUI、DRBD MCに負けていますが、
今後の開発で徐々に追いついていくと思われます。

どれがお勧めかというと、今の時点ではやはり DRBD MC がお勧め。
クライアントに余計なソフトウェアをインストールしたくないんだよねえ、とか
ssh 禁止されててさ、とかいう場合であれば、Hawk ですね。
ただし、Hawk はまだユーザ数が少ないので人柱的な香りがします。

というわけで「月刊あんどりゅーくん」に引き続き「別冊あんどりゅーくん」もはじめました。

前月分のメーリングリストから抜粋したおもしろ情報を
「月刊あんどりゅーくん」として発行していく予定ですが
月刊からもれたおもしろネタ、もしくは月刊のボリュームがあふれてきちゃったときは
暫定対処として「別冊あんどりゅーくん」を発行します。
月刊のほうは「ほぼ」月刊を目指しますが、別冊のほうが気が向いたときに発行します。
もう一生気が向かないかもしれません。

では、今回は下記2項目をご紹介します。
(1) バグ情報
(2) 知恵袋

(1) バグ情報

■ cloneの動作

Master/Slave、cloneについては、まだまだ動作がビミョーな部分もあるのですが、
Pacemaker 1.1 ではかなり動作が改善されています。
Pacemaker 1.0 へもできる限りバックポートしていますが、うまくバックポートできない場合もありますのでご了承ください。
3月分のメーリングリストでは次の事例が報告されていました。

例1) Pacemaker 1.1 で改善済み、そしてPacemaker 1.0 へのバックポート済みのパターン

crm サンプル

property stonith-enabled=”false”
primitive DummyVM1 ocf:pacemaker:Dummy \
op monitor interval=”60s” timeout=”60s” \
op start on-fail=”restart” interval=”0″ \
op stop on-fail=”ignore” interval=”0″ \
meta is-managed=”true” resource-stickiness=”1000″ migration-threshold=”2″
primitive DummyVM2 ocf:pacemaker:Dummy \
op monitor interval=”60s” timeout=”60s” \
op start on-fail=”restart” interval=”0″ \
op stop on-fail=”ignore” interval=”0″ \
meta is-managed=”true” resource-stickiness=”1000″ migration-threshold=”2″
primitive StorGr1 ocf:heartbeat:Dummy \
op monitor on-fail=”restart” interval=”60s” \
op start on-fail=”restart” interval=”0″ \
op stop on-fail=”ignore” interval=”0″ \
meta is-managed=”true” resource-stickiness=”1000″ migration-threshold=”2″
clone StorGr1-clone StorGr1 \
meta target-role=”Started” interleave=”true” ordered=”true”
location score-DummyVM1 DummyVM1 400: dl380g5c
location score-DummyVM2 DummyVM2 400: dl380g5d
order start-DummyVM1-after-StorGr1-clone inf: StorGr1-clone DummyVM1
order start-DummyVM2-after-StorGr1-clone inf: StorGr1-clone DummyVM2

なんか resource-stickiness とか migration-threshold とかの設定がこだわってんなあという感じですが
メーリングリストからほぼコピペです。
STONITH設定してねぇぞごるぁと怒られるのがめんどかったので「property stonith-enabled=”false”」は
追加で設定しています。でもやっぱりタイムアウト短ぇぞごるぁとは怒られるけどね。

というわけで、リソースを起動させます。
# crm configure load update sample.crm

# crm_mon -i1
============
Last updated: Tue Mar 29 17:06:14 2011
Stack: Heartbeat
Current DC: dl380g5d (498d1812-c867-4534-a5aa-85aff30c8eff) – partition with quorum
Version: 1.0.10-47037ab663d7 stable-1.0 tip
2 Nodes configured, unknown expected votes
3 Resources configured.
============
Online: [ dl380g5c dl380g5d ]
DummyVM1 (ocf::pacemaker:Dummy): Started dl380g5c
DummyVM2 (ocf::pacemaker:Dummy): Started dl380g5d
Clone Set: StorGr1-clone
Started: [ dl380g5c dl380g5d ]

メーリングリストへの投稿者曰く
DummyVM1 and DummyVM2 were both started on node goat1.（ goat1 は dl380g5c に読み替え）
ということなんですが、そうかあ？という気が。たぶん上記の配置で正しいと思うんですよね。

次にdl380g5d で Pacemaker を停止しました。

# service heartbeat stop

# crm_mon -i1
============
Last updated: Tue Mar 29 17:06:48 2011
Stack: Heartbeat
Current DC: dl380g5d (498d1812-c867-4534-a5aa-85aff30c8eff) – partition with quorum
Version: 1.0.10-47037ab663d7 stable-1.0 tip
2 Nodes configured, unknown expected votes
3 Resources configured.
============
Online: [ dl380g5c dl380g5d ]
DummyVM1 (ocf::pacemaker:Dummy): Started dl380g5c
DummyVM2 (ocf::pacemaker:Dummy): Started dl380g5c ← ★ フェイルオーバ
Clone Set: StorGr1-clone
Started: [ dl380g5c ]
Stopped: [ StorGr1:1 ]

投稿者によると、DummyVM2 がフェイルオーバできなかったらしいんですが
あんどりゅーくん曰く、1.1.5 だとフェイルオーバできるはずとのこと。（投稿者の環境は 1.1.2）
1.0.11でも無事フェイルオーバできていることを確認しましたので、今回はめでたしめでたし。

例2) Pacemaker 1.1 で改善済み、だけどPacemaker 1.0 へのバックポートが厳しいパターン

crm サンプル
primitive ClusterIP ocf:heartbeat:IPaddr2 \
params ip=”192.168.101.121″ nic=”bond0″ cidr_netmask=”24″ clusterip_hash=”sourceip” \
op monitor interval=”30s”
primitive HttpProxy ocf:pacemaker:Dummy \
op monitor interval=”60s” timeout=”60s” \
op start on-fail=”restart” interval=”0″ \
op stop on-fail=”ignore” interval=”0″ \
clone HttpProxyClone HttpProxy
clone ProxyIP ClusterIP \
meta globally-unique=”true” clone-max=”2″ clone-node-max=”2″
colocation HttpProxy-with-ClusterIP inf: HttpProxy ProxyIP
order HttpProxyClone-after-ProxyIP inf: ProxyIP HttpProxy
property $id=”cib-bootstrap-options” \
cluster-infrastructure=”openais” \
expected-quorum-votes=”2″ \
stonith-enabled=”false” \
no-quorum-policy=”ignore”

HttpProxy に設定されたリソースは メーリングリストの構成では apache だったんですけどDummy に差し替えました。

リソースを起動させます。
# crm configure load update sample.crm

# crm_mon -i1
============
Last updated: Tue Mar 29 17:34:52 2011
Stack: Heartbeat
Current DC: dl380g5d (498d1812-c867-4534-a5aa-85aff30c8eff) – partition with quorum
Version: 1.0.10-47037ab663d7 stable-1.0 tip
2 Nodes configured, 2 expected votes
2 Resources configured.
============
Online: [ dl380g5c dl380g5d ]
HttpProxy (ocf::pacemaker:Dummy): Started dl380g5c
Clone Set: ProxyIP (unique)
ClusterIP:0 (ocf::heartbeat:IPaddr2): Started dl380g5c　← ★　それぞれのノードに
ClusterIP:1 (ocf::heartbeat:IPaddr2): Started dl380g5d　← ★　分散してます

片方のノードをスタンバイ化します。
# crm node standby dl380g5d

# crm_mon -i1
============
Last updated: Tue Mar 29 17:38:13 2011
Stack: Heartbeat
Current DC: dl380g5d (498d1812-c867-4534-a5aa-85aff30c8eff) – partition with quorum
Version: 1.0.10-47037ab663d7 stable-1.0 tip
2 Nodes configured, 2 expected votes
2 Resources configured.
============
Node dl380g5d (498d1812-c867-4534-a5aa-85aff30c8eff): standby
Online: [ dl380g5c ]
HttpProxy (ocf::pacemaker:Dummy): Started dl380g5c
Clone Set: ProxyIP (unique)
ClusterIP:0 (ocf::heartbeat:IPaddr2): Started dl380g5c
ClusterIP:1 (ocf::heartbeat:IPaddr2): Started dl380g5c　← ★ フェイルオーバ

スタンバイ化したノードをオンラインに戻します。
# crm node online dl380g5d

# crm_mon -i1
============
Last updated: Tue Mar 29 17:38:45 2011
Stack: Heartbeat
Current DC: dl380g5d (498d1812-c867-4534-a5aa-85aff30c8eff) – partition with quorum
Version: 1.0.10-47037ab663d7 stable-1.0 tip
2 Nodes configured, 2 expected votes
2 Resources configured.
============
Online: [ dl380g5c dl380g5d ]
HttpProxy (ocf::pacemaker:Dummy): Started dl380g5c
Clone Set: ProxyIP (unique)
ClusterIP:0 (ocf::heartbeat:IPaddr2): Started dl380g5c
ClusterIP:1 (ocf::heartbeat:IPaddr2): Started dl380g5c ← ★ 居座り。フェイルバックしない。

Pacemaker 1.1.5 だと居座り動作は発生せず、ちゃんともとのノードにフェイルバックできるようです。
しかし、このパッチはPacemaker 1.0.11 にはバックポートできませんでした。

メーリングリストでは居座りリソースをもとのノードの戻す裏技が紹介されていたのでどうしても困ったときは、参考にしてください。

裏技：clone-node-max を一時的に 1 に変更する（初期設定は 2）

# crm resource meta ProxyIP set clone-node-max 1

# crm_mon -i1
============
Last updated: Tue Mar 29 17:47:41 2011
Stack: Heartbeat
Current DC: dl380g5d (498d1812-c867-4534-a5aa-85aff30c8eff) – partition with quorum
Version: 1.0.10-47037ab663d7 stable-1.0 tip
2 Nodes configured, 2 expected votes
2 Resources configured.
============
Online: [ dl380g5c dl380g5d ]
HttpProxy (ocf::pacemaker:Dummy): Started dl380g5c
Clone Set: ProxyIP (unique)
ClusterIP:0 (ocf::heartbeat:IPaddr2): Started dl380g5c
ClusterIP:1 (ocf::heartbeat:IPaddr2): Started dl380g5d ← ★ お！戻った！

設定は元に戻しておいたほうがよいです。
# crm resource meta ProxyIP set clone-node-max 2

では、お次は知恵袋。

暖かくなってきたので「月刊あんどりゅーくん」はじめました。

Linux-HA 関連のメーリングリスト、リポジトリの更新情報を日々ストーキングしつつ
これは！というおもしろネタをご紹介いたします。
まずは、ほぼ月一更新を目指します。
寒くなったら冬眠します。
ちなみに中の人は絶賛募集中です。
現在、ボットが某情報収集コードに従って作戦実行中であります。

で、そもそも、「あんどりゅーくん」とはなんぞや？
「あんどりゅーくん」とは、Pacemaker の開発者 Andrew Beekhof(Red Hat) のことです。
Heartbeat から Pacemaker が飛び出しちゃったよわっしょい！の火の元だったりとか
メーリングリストの回答があまりにもそっけないとかで
ちょっと付き合いづらい人なのかなあと思っていましたが
実際お会いしてみると意外にお茶目な方でした（右斜め上参照）。

なお、PacemakerでHA環境を構築するためには、他にも必要なコンポーネントがいくつかありますが
それぞれの主要メンバはこちら。

• Clueter Resource Agents/Reusable Cluster Components

Dejan Muhamedagic(Novell) … メーリングリストの回答が超やさしい。唯一の癒し系。
Florian Haas(Linbit) … たまに日本に来てる。すごい親切なんやけどマシンガントークは勘弁な。
Lars Ellenberg(Linbit)

• Heartbeat

上に同じ。一応、Linbitメインな感じ。

• Corosync

Steven Dake(Red Hat) … 声ちっさい。

• Python GUI

Yan Gao(Novell)

• Hawk(HA Web Konsole)

Tim Serong(Novell) … 会ったことはあるというか見たことある。けどどんな人かよく覚えていない。。。

• DRBD MC

Philipp Reisner(Linbit)

• 上記の荒ぶるメンバをたばねつつ、HAの未来を占う人。

Lars Marowsky-Bree(Novell) … LMB。キホン黒づくめ。

LMBとFlorianの議論が熱くなりすぎて周りがドン引き、そこにAndrewが「もういいじゃーん」てな感じで
仲介に入るイメージで大体あってます。

Lars,Yan,Philippはお会いしたことないのでノーコメント。
あれ？Dejanも会ったことないけど。。。まあよかたい。

以上がいわゆる本家な方々です。
日本サイドでは、ksk_haさんがPacemakerのバックポートなどを担当しています。

あとですね、セミナーや勉強会でたまにご質問をいただくのですが
Pacemakerの応援キャラクター、かなちゃん、かよちゃん、ぺーちゃん、ころちゃんは本家公認です！
2010年11月にボストンで開催された「Linux Plumber Conference」で
minky0さんから上記主要メンバにクリアファイルをお渡ししていただいています。

最近、デビューしたドロシーちゃんとビアンカちゃんはDRBDの応援キャラですが
こちらはLinbit公認なのかどうかボットにはよくわかりません。

DRBDのおもしろネタについては、ttkzwさんが「月刊ふろーりあんくんはやりたいなぁといつも思いつつ。」
とつぶやいていらっしゃるので、もう少し暖かくなったら「月刊ふろーりあんくん」もはじまるのではないかと思われます。

では、いよいよ本題です。

今回は下記2項目をご紹介します。
(1) リリース/アナウンス関連
(2) バージョン互換情報