自分的にキた部分を書いていきます。以下の3つです。
- pacemakerはHeartbeat脳でも使える
- STONITHを使おう
- OCFは使う前にちゃんと読もう
１．pacemakerはHeartbeat脳でも使える
Heartbeatを使ってきた人はpacemakerだからって意識することは無く今まで通りでいいみたい。
- インストールはyumで今まで通りと変わらない。
- 起動も/etc/init.d/heartbeat startでOK。
- リソース監視の書き方も今まで通りcib.xmlでOK。（ただし、Excel形式のファイルを読み込ませたりしてもっと簡単に設定できるようにしてくれてる）
なんかこれを知れただけでもう勉強会に参加して良かったなーもう帰ってもいいなーって思った。怖かったからね、pacemaker。
僕に混乱と恐怖を与え、Heartbeat 2.1.3を使い続けることを決心させたのは以下の記述だったのです。
Heartbeatは基盤レイヤのみであるので、その上に必ずPacemakerというクラスタリソース制御機能(CRM)を合わせてインストールして使用します。Heartbeat2.1.4までは、クラスタリソース制御機能はHeartbeatの一部に含まれていましたが、現在のバージョン(Heartbeat 3.*以降)にはもはや含まれません。この理由については「なぜPacemakerプロジェクトが作成されたのか?」を参照してください。
もう全然別モンなんだろうなーって思ってた。
もちろん細かいところは動作検証が必要でしょうけどね。
２．STONITHを使おう
死活監視用のネットワークが切れた場合にスプリットブレインが発生する。
それを防ぐためにノードの電源を落としたりするのに利用できる。
相討ちにならないように最後にDCとして動いていたほうが先にフェンシングするっていう設定ができるらしいですよ。
STONITHの良さは第1部のスライドがとても分かりやすい。
STONITHとかってググっても直感的に分かるものが出てこないので資料が公開されるのを期待。
３．OCFは使う前にちゃんと読もう
OCFはpacemakerがリソースの起動・停止・監視を行うときに叩くスクリプト。
とくに監視の部分をちゃんと確認したほうがいい。MySQLの監視はちゃんと設定しないとプロセスの監視だけだったりする。（Nagiosの監視スクリプトとかも結構単純なのあるもんね。）
SELECT文を発行して正常にテーブルの中身見られるかとかまで確認したければちゃんとそれ用に設定しないとだめ。
面白かったのはoracleのOCFがあったことだなぁ。
pacemakerでocacleをクラスタリングするっていう事例あんのかね？
そうそう、LSB準拠じゃないスクリプトをheartbeatで使うと悲しいことになったことがあります。
返すステータスコードがLSBに準拠してなかったためにheartbeatのノードが順番にリブートし続けるという地獄を味わったことがあるので、LSBスクリプト使う方はご注意を。
LSB互換チェックとかあるらしい。（目チェックだった気がするけど）
http://sourceforge.jp/projects/linux-ha/lists/archive/japan/2008-March/000057.html
余談
なぜキャンセル者があんなに少なかったのか！？
それはカレンダーだけじゃなかったってことが判明した時に分かった気がしたよ。
いろんな意味で会場はアツかった！
 |
| ノベルティのカレンダー |
その他情報
ATND
http://atnd.org/events/11593
Togetter
http://togetter.com/li/91606
0 件のコメント:
コメントを投稿