SummitですがHAな人々もこれにあわせて25日に大集合ということになりました。思ったら、あんどりゅーくん、不参加やけどな。あんどりゅーくんはいないけれども、興味のある方はぜひぜひご参加ください。1.4.1と1.3.3のリリース今回のリリースでは、クラスタ再構成時の検知、例えば冗長構成で死活監視をしているインターコネクトLANのかたっぽが切れちゃった後ちゃんとネットワークがつなぎなおしたはずなのに「まだつながってなくね?」と誤検知しちゃう問題が修正されています。リリースノートらしきものが見つけられなかったので、TODOの比較してみたのですがv1.3.3とv1.4.1ではSNMP関連で差分がありました。v1.4系からははSNMPがサポートされています。どんなトラップが飛んでくるかとかそのへんはまだよくわからないのでなにかわかったらまた別冊でご紹介しようと思います。Corosync.ちなみにリリースのアナウンスは7月26日だったのですが、その前の週(7月18日)に1.4.0のリリースがアナウンスされてるんですよね。しても週刊コロシンクがはじまっちゃうか!?と某所では戦々恐々となったらしいですが、そうでもなかった。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個でもいいんじゃね?ってちょっとだけ思ったけど、まあ、ね...。