4 / 512345

月刊あんどりゅーくん(10月号)

プラハで開催されるLinuxCon Europe 2011に間借りして
F2Fでミーティングしよう!と、らーすくんが言ってた例のやつですが
中止?と思いきや、やっぱり開催するようです。

CFP: HA Mini-Conference in Prague on Oct 25th

あんどりゅーくんも登場の予定

アジェンダは特に決まっていないので、集まってきた人たちから
質問や提案があればそれを話し合うという感じになりそうです。
10月25日、プラハに行かれる方はぜひ。
あんどりゅーくんとらーすくん、ちら見するだけでも。

では、今回もリリース情報と知恵袋です。

(1) リリース情報
Announce: Two project changes

あんどりゅーくんからのお知らせ。

  • でじゃんくんが開発しているcrmシェルは別プロジェクトになります。
  • IPC(inter-process communication)やスケジューリングのライブラリを変更します。

確かに、ツールは別プロジェクトとしてわけていたほうがわかりやすいのかも。
ただねえ、Pacemakerは関連するパッケージがたくさんあって、ただでさえ複雑なので、これ以上増やしてほしくないなあ。

一方、ライブラリの変更はかなりイタイ。

下手すると、メッセージングレイヤとしてHeartbeatが使えなくなる可能性があります。
Heartbeat 3系はDRBDを開発しているLINBITがメンテナンスしてるんですが
LINBITはこのへん、どう思っているんですかねえ。
DRBDの場合、Pacemaker+Heartbeatの組み合わせが鉄板なんですが…。
あんどりゅーくん曰く、「互換性残せるように頑張ってみる」とのことですが、ホントに?
なんかHeartbeatに依存したライブラリは排除したいっていう臭いがぷんぷんするんだけど。

ちなみに、上記2点の変更はPacemaker 1.1系に影響してきます。
Pacemaker 1.0系には変更が入らないので、Pacemaker 1.0 + Heartbeat 3系の組み合わせには影響ありません。
ああ、LINBITもPacemaker 1.1系ではCorosyncに乗り換えていくのかもしれないですねえ。
ころちゃん、最近はお腹が痛くなったりしていないのかねえ。

Pacemaker 1.1系にも魅力的な機能がいろいろ追加されているのですが
(フェイルカウントの自動削除とかリソース配置の優先度付けとか)

安定性を重視するのであれば、Pacemaker 1.0.x + Heartbeat 3.0.x がおすすめです。


さて、GUI関連でもプロジェクトの変更がアナウンスされました。

DRBD-MC 0.9.9のリリース
LCMC(Linux Cluster Management Console) 1.0.0のリリース

LCMCはDRBD-MCのfork、ということですが、実質的にDRBD-MCは開発停止とみていいと思います。
DRBD-MCを開発していたRastoさん(らすとさん?)がLCMCを引き継ぐので
今後はLCMCの動向をおっかけたいと思います。

ところで、LCMCのクライアント、スクリーンショットを見てみたんですけど、ちょ!ロ ゴ www

このロゴはLinux-HA Japanでつくったんですよ!
ロゴ、着々と世界制覇中!
あんどりゅーくんもロゴの色を青くしてたけど、こっちも色を青っぽくしちゃうのはなんで?
赤だと「危険!」っていうイメージがあるからでしょうか?
赤くてもこわくないよー。

月刊あんどりゅーくん(9月号)

あっという間に9月なわけですが
来月に予定されていたクラスタ集会@プラハは中止となりました。

あんどりゅーくんも、ふぁびおくんも、ふろーりあんくんも
主要な開発者が雁首そろえて「ごめーん、忙しーい」ということなので中止です。

F2Fのミーティングは無理だけど、webinarとか使ってオンラインでミーティングしようね!と、らーすくんが言っているので、興味のある方はこちらにご参加ください。
開催時間などが確定次第、メーリングリストなどでもご案内します。

というわけで今月も

(1) リリース情報
(2) 知恵袋

です。

(1) リリース情報
大きなリリースはありませんでしたが、あんどりゅーくんが着々とバージョンアップの準備を行っています。
先日、Pacemakerのリポジトリにversion 1.1.6のタグがつきました。

リリースの準備として、valgrindやcoverityを使用したコードチェックが実施されていますが、
valgrindで以下3点のメモリリークが検知されています。

High: PE: Fix memory leak for re-allocated resources reported by valgrind
Low: PE: Set the name of a xml node in the better way – Fix memory leak
High: PE: Resolve memory leak reported by valgrind

ただし、これらのコードはPacemaker 1.1.5のリリース後に混入しているので
Pacemaker 1.1.5もしくは、Pacemaker 1.0.10, 1.0.11を使用している場合は影響ありません。
Pacemaker 1.1.6のリリースに向けて、Pacemaker 1.0.12へのバックポートも開始されています。

あ、そういえば、リリースといえば、こんなのもありました。

Announcing – the Assimilation monitoring system – a sub-project of Linux-HA

こんなのとかって言っちゃ悪いか…。
これ作ってる、あらんって、Heartbeat本体をつくったエライ人なんですけどね…。
どーも、あんどりゅーくんと相性が悪いというかなんというか(棒

ちなみに、この「the Assimilation monitoring system」ですが、中身的には
matahariとかpacemaker-cloudとだいぶかぶってるよね?という指摘もされており
うーむ、あらんはこれからどこへ行こうとしているのか…。

月刊あんどりゅーくん(8月号)

10月にプラハで開催予定のLinuxCon/Kernel Summitですが
HAな人々もこれにあわせて25日に大集合ということになりました。
と思ったら、あんどりゅーくん、不参加やけどな。
あんどりゅーくんはいないけれども、興味のある方はぜひぜひご参加ください。

というわけで今月も

(1) リリース情報
(2) 知恵袋

です。


(1) リリース情報


・Corosync 1.4.1と1.3.3のリリース
今回のリリースでは、クラスタ再構成時の検知、例えば
冗長構成で死活監視をしているインターコネクトLANのかたっぽが切れちゃった後
ちゃんとネットワークがつなぎなおしたはずなのに
「まだつながってなくね?」と誤検知しちゃう問題が修正されています。

リリースノートらしきものが見つけられなかったので、TODOの比較してみたのですが
v1.3.3とv1.4.1ではSNMP関連で差分がありました。
v1.4系からははSNMPがサポートされています。
どんなトラップが飛んでくるかとかそのへんはまだよくわからないので
なにかわかったらまた別冊でご紹介しようと思います。


v1.3.3のTODO

——————————————————————————
topic-snmp
——————————————————————————
Main Developer: Steven Dake
Started: Not Started
Finished: 0%
target: needle
Description:
This topic involves investigation of adding SNMP support into Corosync.

v1.4.1のTODO
——————————————————————————
topic-snmp
——————————————————————————
Main Developer: Angus Salkeld
Started: Not Started ← あれ?未着手なのに
Finished: 100% ← 進捗が100%になってる!
target: needle
Description:
This topic involves investigation of adding SNMP support into Corosync.

ちなみにリリースのアナウンスは7月26日だったのですが、

その前の週(7月18日)に1.4.0のリリースがアナウンスされてるんですよね。
またしても週刊コロシンクがはじまっちゃうか!?
と某所では戦々恐々となったらしいですが、そうでもなかった。やれやれ。


・DRBD 8.4.0のリリース
いよいよ、8.4の正式版がリリースされました!
RHEL6.1にも対応しています。

8.4系では複数リソースの同期処理に大きな変更が入りました。

8.3系までは、複数リソースを同期する場合は同期LANを複数準備する、
または同期ポートを複数準備する必要がありました。
例えば、同期LANが1本の構成でリソースAとリソースBを同期したい場合は
それぞれの同期ポートを別の番号で設定することになります。
この場合、なんらかの不具合でリソースAの同期処理は停止してしまったけれど
リソースBは正常に同期処理を続行中という状態もあり得るわけです。
で、このタイミングでプライマリノードが故障してしまうと
セカンダリノードのリソースAとリソースBは同期状態がびみょーに違う可能性も
「あるかもしれない」。
fence-peerハンドラを設定していれば、リソースAが「Outdated」状態になっているはずなので
そもそも起動できないんですが、タイミングによっては起動しちゃう場合もあるかもしれない。
そのへんは保証されないわけです。
リソースAとリソースBが依存関係のないデータであれば問題ないのですが
データベースのテーブル領域とログ領域みたいになんらかの依存関係がある場合は
同期状態がずれると危険なので、複数リソースの設定は推奨されていません。

ただし、既存の環境にDRBDを追加する場合だと、
パーティションをがっつり切られてたりすることもあるでしょうし

バックアップの関係でパーティションわけときたいんだわとか
そういうのもあるかもしれない。

こういう場合は複数リソース構成をとるしかない。
8.4系では同一の同期LANで複数リソースを同期することができるので
同期がとまるときは全リソースが一斉にとまりますし
再同期がかかるときは全リソースが一斉に再同期しにいきます。
なので、依存関係のあるデータを複数リソースとして設定しても
同期状態は常に保証されます。


複数リソースにはvolumesパラメータを使用しますが

8.4向けに変更が反映されたユーザガイドをみてみると、volumesの設定方法はこんな感じです。
onセクションの中でvolume{}をもりもり増やしていけばよいわけですな。


ちなみに、deviceに設定するminor番号、これって8.3系では最大255までだったのですが
8.4系では最大1048576(2の20乗)まで設定可能となりました。
つまり1048576リソースまで同期可能ということですね。
いやー、255個でもいいんじゃね?ってちょっとだけ思ったけど、まあ、ね…。

別冊あんどりゅーくん(第2号)

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年生)

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

月刊あんどりゅーくん(7月号)

今月も、先月にひきつづきリリースてんこもり月間でした。
というわけで、まずは各製品のリリース情報を簡単にご紹介します。
知恵袋では、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 は
上記の修正も取り込んだ状態でビルドしています。

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

月刊あんどりゅーくん(6月号)

ここ最近、あんどりゅーくんよりふぃりっぷくんが荒ぶってましたなあ。
ということで、今月は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からの新機能!

月刊あんどりゅーくん(5月号)

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

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

 

1. リリース情報

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

 

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回やってみようLinux-HA「HAの基本構成」

みなさんおはようございます。こんにちは。こんばんは。前回からまさに半年かかってますが遅ればせながら第2回です。前回はHAクラスタを組む上で必要な知識として、HA環境について考えてみましたが、今回はこれから初めてLinux-HA環境の構築に挑戦しようとしている読者の方に向けて、具体的に最も基本的なHA環境の構築方法を紹介したいと思います。

基本的なHA環境

Linux-HAを学習する上で基本となる構成は、サービスを提供する「アクティブサーバ」と、いざという時のために予備機として待機している「スタンバイサーバ」の2台で構成される「アクティブ/スタンバイ」型のHA環境です。基本的なサーバといっても考えることはたくさんあるので、ちょっとここに列挙してみます。

ハードウェア障害を何処まで想定するか
制御するソフトウェアは何が必要か(適用範囲)
監視するソフトウェアの監視項目
データの共有はどうするか
障害発生から、サービス切り替えまでの所要時間(希望時間)
予期せぬ障害により系が切り替わらなかったときの対処

最低でも以上の事は考慮した上で、HA環境を設計しなくてはなりません。上の項目について考慮した上で基本的なHA環境を設計するとなんとなく次のような感じになります。

電源落ちたらフェイルオーバーしよう
カーネルパニックとかマシンがおかしくなったらフェイルオーバーしよう
ソフトウェアはとりあえずPIDのチェックだけにしてPIDが認識できなかったら再起動しよう
ソフトウェアの再起動が不可能な状態だったらフェイルオーバーしよう
データの共有はDRBDを使ってネットワークミラーリングでやろう
障害発生からサービス切り替え実行までの時間は、5分くらいがいいな
とりあえず今回はサービスが切り替わらない程の問題が発生したら手動で対応しなくちゃいけないな

構成図としては…

こんな感じが基本的な所でしょうか。深く追求していくと、結構きりがないので、有る程度の所で落としどころを見つけて設計しないと…

障害に対して敏感すぎる構成

監視することがサーバに負荷をかけて障害を起こす

という、「健康のためなら死んでも良い」的な構成になってしまいます。よくあるのが、サーバ障害発生時のダウン時間を短くしようとしすぎて、少しでも負荷がかかるとそれに反応してフェイルオーバーしてしまう環境です。くれぐれも、Linux-HA自体が「障害点」になってしまわないように考慮して設計するようにしましょう。

とりあえず設定してみよう

前置きが長くなりましたが、具体的な設定をしてみましょう。今回の環境は前回の予告にも有るとおり以下の環境で構成します。リソースはUnboundだとデータを持たないのでApacheに変更します。

OS
CentOS5.5 x86_84

クラスタソフト
Heartbeat 3.0.4 / Pacemaker 1.0.10

データ同期
DRBD8.3.10

制御対象
仮想IP / Apache

監視用インターフェース
eth1 / . . . → Read More: 第2回やってみようLinux-HA「HAの基本構成」

別冊あんどりゅーくん(第1号)

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


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


では、今回は下記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


では、お次は知恵袋。

STONITH plugin “eject” is out now!

Split Brain is the most awful situation in the cluster world,
. . . → Read More: STONITH plugin “eject” is out now!

4 / 512345