Linux-HA Japan勉強会 heartbeat v3とPacemaker

linux

先週末の1/21に秋葉原UDXで開催されたLinux-HA Japan勉強会に行ってきました。
いきなり、結構な有名声優のアナウンスからスタートし、
イベント会場間違えたかと思いましたが、
中身は、ちゃんとlinuxでクラスタを組むためのPacemakerについての勉強会でした。
しかし、声優さんのギャラが気になるな・・・。
声優やってる友人に聞いたところ、有名どころはそれなりにかかるらしいがw


ちなみに、Pacemakerはクラスタリングウェアの中の、リソースマネージメントを担当するもので、
共有IPアドレスの割り振りや、共有ディスクのマウント制御、DBの立ち上げなどをやってくれるもの。
単体で起動するものではなく、クラスタノードの死活、同期状態を監視する
heartbeatやcorosyncと組み合わせて使うものと理解しています。
以下、Pacemakerの動作と機能について、現在の私の理解をまとめておきます。
間違ってたら、突っ込んでください・・・。

Pacemakerのインストール

Linux-HA Japanのサイトからリポジトリパッケージが入手できる。
ローカルリポジトリに展開し、yumでインストール可能。

Pacemakerの起動

実際に起動するのはheartbeatかcorosync。
クラスタ構成の設定をしheartbeatから起動すると、一緒に動作してリソースの管理をやってくれる。

Pacemakerの動作について

リソースの監視、起動、停止については、OCFと呼ばれるフレームワークに準拠したシェルスクリプトか、
LSB規約に準拠したシェルスクリプトで行われる。
シェルスクリプトの中で、プロセスの存在を確認する、ディスクに書き込みができるか確認する、
DBサーバープロセスを立ち上げる等の操作を行う。
片側の特定のサービスに異常が発生した時は、OCFスクリプトのチェック動作で障害を検知し、
stopでリソースを順次停止、待機系でstartを呼んで順次起動を行う。
OCFの中身は対象となるリソースによって、全然違う。
勉強会で紹介されていたmysqlのOCFスクリプト等は、
監視項目が色々とあるようで、結構複雑なスクリプトに見えた。
まずはdummyというOCFを読むと構造が分かりやすいらしい。


基本的な動作はこんな感じだろうか。



勉強会で気になった機能・動作について

スプリットブレイン対策
  • STONITH = ハードウェア制御ボードを利用した強制電源停止
  • SFEX = 共有ディスク排他領域による制御

インターコネクトLANが切れて、各ノードの死活状態が監視出来なくなったときに、
共有ディスクの二重マウントは避けないとやばい。最悪データが飛ぶ。
そのため、IPMI等を利用して、ハードウェアレベルで直接制御を行い、電源を強制的に落とす。
また、ディスクリソースをどちらが掴んでいるかを、ディスク経由での判別できるように、
共有ディスクに排他領域を作成し、RAWで定期的に書き込むことで、ノードが生きているかどうかを判別する。


エンタープライズ系のDBクラスタを組む時などには、必須とも言える機能。
昔のheartbeatではこのへんは用意されていなかったと思う。
以前、会社でクラスタウェアの検証をやったことがあるが、
この二つの機能は、結構重要視されていて、選定のキモとなるポイントだった。
この辺が実装されているなら、高い信頼性要るような業務サーバーでも使えるんじゃないのかなーと思った。
ちなみに、普通に使うと落とし合いになって、両方の電源が落ちる可能性があるらしいが、
STONITH Helperというものを利用して、STONITHのタイミングを遅らせることで、
稼動系の停止を防ぐことができる。



Excelシートからの設定生成

Linux-HA Japanが作成したツールとExcelシートを利用することで、
Excelシートからcsvを生成、linux側でcsvをインポートすることで、
クラスタの設定ができる。
日本のSI文化を意識している感じが、涙ぐましいような気もするが、
どうせドキュメント作れとか言われるんだから、この方が賢いかな・・・。 orz
文字コードSJISだったりで、そんな仕様で大丈夫か？と思いつつ、
おっさんを納得させるにはこれがいいんだろう。



OCF_CHECK_LEVELとOCFのバージョンによる差異

公式で用意されてるOCFの中には、OCF_CHECK_LEVELを設定しないと、
思っているような監視をしてくれないことがある。
(mysqlでsqlを発行し、実際に動作していることを確認する等)
監視の負荷と信頼性要件を調整可能になっているようだが、
ドキュメントに記述が無いらしい。
ちゃんとOCFの中身見ないと分からない点が注意。
また、バージョンごとにOCFは結構中身が変わるらしいので、
用意されてるからといって、確認せずに使っちゃ駄目だとのこと。
信頼性高めるために使うんだから、適当に済ませちゃいかんよね。


OCFの中にPacemakerでリソース登録する際の設定項目が、xmlヒアドキュメントで定義されているのは、
ちょっと気持ち悪い。というかめんどくさそう。
あんまり自分じゃ書きたくないかもw



その他細かい機能・動作についてのメモ
  • リソースのグルーピング。特定リソースの障害でグループ全体をフェイルオーバーさせる。
  • score値によるリソース配置の優先順位設定。稼動系の固定や、3台以上のクラスタ構成時の配置設定等。
  • Quorumポリシーの設定。3台以上構成になった時の、稼動状態監視ポリシー。
  • Migrationの閾値。failcountが閾値を越えるまでは再起動をリトライする。
  • フェイルバック時の動作。デフォルトではfailcountが残っているとリソースは起動しない。

感想まとめ

デモを交えての講演形式で、実際にクラスタが動いている様を見つつ話を聞くことが出来、
動作イメージが分かりやすかったですね。
かなりデモが多かったため、やる側は大変だろうと思いましたが。
後、会場が狭かったので暑かった+肩がこった。
せめて机は欲しい。
今回、エンタープライズ領域でも使えそうな機能がちゃんとあるってことが分かったので、
どっか仕事で使えないかなーと思ったり。
R&Dとかやらせてくれんかなー。



入場時に貰ったカレンダーは会社に置いていたら、めでたくアニソンのCDと間違われました。
狙い通り。