師走も最終局面な今日この頃ですが、今月もリリース情報と知恵袋です。

リリース情報はDRBD 8.4.1とBOOTHがメインです。 知恵袋ではPacemaker Cloudを紹介します。

1. リリース情報

1.1 DRBD 8.4.1 1.2 BOOTH 1.3 Debianパッケージ 1.4 LCMCの新機能

1.1 DRBD 8.4.1

DRBD 8.4.1がリリースされました！

8.4.0のバグフィックスが含まれているので、

8.4.0を使用している場合は8.4.1へのアップデートをお勧めします。

8.4.1に取り込まれた新機能は下記二点です。

  • Read load balancing　　　diskセクションに「read-balancing」パラメータを追加
  • Works with Linux-3.2　　 Linux 3.2対応

その他のバグフィックス、機能追加情報はこちら。

  • Fixed a bug that might cause in kernel list corruption triggered by simultaneous IO on multiple volumes in a single resource 単一リソースに設定した複数のvolumesから同時にI/Oが発生するとカーネルのリストが 破壊されるというバグを修正しました。

  • Fixed a bug that might cause a kernel OOPS in the worker thread while the receiver tied to establish a connection (drbd-8.4.0 regression)

receiverが接続中にworker用のスレッドでkernel OOPSが発生するというバグを修正しました。 (DRBD 8.4.0にも含まれるバグです) 

  • Fixed an issue in the receiver that could cause connection triggered by simultaneous IO on multiple volumes in a single resource 単一リソースに設定した複数のvolumesから同時にI/Oが発生する条件でのreceiverの動作を修正しました。

  • Consider the discard-my-data flag for all volumes 全てのvolumesに対してdiscard-my-dataフラグを設定することができるようになりました。 8.4.0では、discard-my-dataフラグを設定しても最初のvolumeにしか効いてなかったようですね ^o^;

  • Fixed attaching to backing devices that do not support barriers/flushes, when barriers/flushes are not disabled by the configuration.(drbd-8.4.0 regression) バリア/フラッシュをサポートしていないデバイスへの接続処理を修正しました。 (DRBD 8.4.0にも含まれるバグです)

  • Fixed a rare compatibility issue with DRBD’s older than 8.3.7 when negotiating the bio_size DRBD 8.3.7以前とのバージョン互換性(bio_size関連)を修正しました。

  • Fixed a rare race condition where an empty resync could stall with if pause/unpause events happen in parallel 再同期処理実行中にpause/unpauseが同時に発生すると、再同期処理が競合状態に陥る可能性がありましたが、 修正されました。

  • Made the re-establishing of connections quicker, if it got a broken pipe once. Previously there was a bug in the code caused it to waste the first successful established connection after a broken pipe event. 再接続時の動作を改善しました。

  • crm-fence-peer.sh: Can now deal with multiple DRBD instances being in a master/slave group DRBDの複数リソースをPacemakerのgroupで管理する場合、フェンシングに使用する crm-fence-peer.shにリソースのIDを指定する必要がなくなりました。

参考：/wp/archives/2468

* Optional load balancing for read requests: new keyword “read-balance” diskセクションに「read-balancing」パラメータが追加されました。

「read-balancing」パラメータに設定可能な値(デフォルト値はprefer-local)

  • prefer-local(ローカルディスクからの読み込み優先)

  • prefer-remote(リモートディスクからの読み込み優先)

  • round-robin(ローカルおよびリモートディスクからラウンドロビンで読み込み)

  • least-pending(ローカルディスクでペンディングが発生していた場合リモートディスクから読み込み)

  • when-congested-remote(ローカルディスクで処理が混雑していた場合リモートディスクから読み込み)

ちょっと最後の二つ(least-pending, when-congested-remote)の違いがわかりません。

--- a/documentation/drbdsetup.xml
+++ b/documentation/drbdsetup.xml
@@ -481,6 +481,23 @@
</para>
</listitem>
</varlistentry>
+
+        <varlistentry>
+          <term>
+            <option>--read-balancing <replaceable>method</replaceable></option>
+          </term>
+          <listitem>
+           <para>
+             The supported <replaceable>methods</replaceable> for load balancing of
+             read requests are <option>prefer-local</option>, <option>prefer-remote</option>,
+             <option>round-robin</option>, <option>least-pending</option> and
+             <option>when-congested-remote</option>.</para>
+             <para> The default value of is <option>prefer-local</option>.
+             This option is available since 8.4.1.
+             </para>
+          </listitem>
+        </varlistentry>
+
--- a/drbd/linux/drbd.h
+++ b/drbd/linux/drbd.h
@@ -96,6 +96,14 @@ enum drbd_on_congestion {
OC_DISCONNECT,
}; 

+enum drbd_read_balancing {
+       RB_PREFER_LOCAL,
+       RB_PREFER_REMOTE,
+       RB_ROUND_ROBIN,
+       RB_LEAST_PENDING,
+       RB_CONGESTED_REMOTE,
+};
+
/* KEEP the order, do not delete or insert. Only append. */
enum drbd_ret_code {
ERR_CODE_BASE           = 100,

1.2 BOOTH

「BOOTH」という新しいパッケージがリリースされました。

BOOTHとはなんぞや。

BOOTHとはマルチサイトクラスタ(Multi-site clusters)を管理するためのパッケージです。

マルチサイトクラスタとはなんぞや。

「クラスタ」という用語は、同一拠点内に複数のノードを配置した形態を 指すことが多いのですが、「クラスタ」が地理的に異なった拠点間に配置された形態を 「マルチサイトクラスタ」と言います。

例えば、東京に4ノードのクラスタ、沖縄に2ノードのクラスタを配置した場合

東京と沖縄のそれぞれの拠点はマルチサイトクラスタとして管理されます。

通常時は東京サイトがサービスを提供し、沖縄サイトは待機系として管理する運用が想定されます。

Pacemakerでも、東京に1ノード、沖縄に1ノードといった遠隔地構成は可能ですが

(たぶん誰もやったことないだろうけどできるはず)

それぞれのサイトが複数ノードを含むクラスタ構成となっている場合

東京から沖縄への「クラスタ間フェイルオーバ」っていうのはできないんですね。

つまり、東京の4ノードたちがなにごともなく仲間内できゃっきゃうふふと

フェイルオーバしあってる間は問題ないんですが

東京が全体的にぽぽぽぽーんなった場合

沖縄へは手動でフェイルオーバするしかないわけです。

で、BOOTH曰く「俺がやるぜ！」と、まあ、そういうこと。

そういうわけで、BOOTHはPacemakerの拡張機能として設計されています。 ソースコードのダウンロードはこちら。

BOOTHは開発真っ最中の段階なのでまだうまく動いていない部分もあるようです。 開発主体はSUSEなのですが、2012年2月～3月頃に商用化が予定されているという風の噂を聞きました。

ドラフト版ですがマニュアルも公開されています。

マニュアルでは、「SUSE Linux Enterprise High Availability Extensionの

オプションとして提供」と記述されていますが、他のディストリビューションでも動くはず。

ただし動作確認はちょっと遅れるかもしれないですねえ。

人柱絶賛大募集！

あと、前提条件としてPacemaker 1.1が必要となります。

Pacemaker 1.0を地道にメンテナンスしていく方針のLinux-HA Japan

(というか、Linux-HA Japanの中の人の勤務先のエライ人)としては

舵取りのタイミングに頭悩ましちゃう感じですよねー(ヒトゴト)。

マニュアルからキーワードを抜粋してBOOTHの概要を箇条書きしてみます。

  • 「チケット」という新しい概念が導入されました。

  • マルチサイトクラスタに含まれるそれぞれのサイトでboothdというデーモンがチケットを管理します。

  • チケットの状態を管理する「Arbitrator」という親分サイトが必要です。

  • チケットを保有するサイトがサービスを提供します。

  • 自動切り替えのためには3サイト以上必要です(Arbitrator x1, サービス提供サイト x1, 待機サイト x1)。

  • サービス提供サイト内でノードが故障した場合は同一サイト内でフェイルオーバを試みます。

  • サービス提供サイト全体が故障した場合、待機サイトへフェイルオーバを試みます。

「3サイト以上必要」ってとこ、Arbitratorが他のサイトと相乗りできれば嬉しいんですが 親分として起動する用のパラメータが用意されているので、今はちょっと無理っぽいですな。

** 1.3 Debianパッケージ **

Pacemaker 1.1.6がDebianのリポジトリ(squeeze-backports)に取り込まれました。

1.4 LCMCの新機能

毎回楽しいネタを提供してくれているLCMCですが、今月も新機能が追加されています。

LCMCからcrm shellを直接編集できるようになりました！

GUIのペインにcrm configure editの結果が表示されるので

そこでごにょごにょと設定を変更してcommitしてあげれば

クラスタに変更内容が反映されます。

生々しい設定ファイルを隠蔽してこそのGUIっていう考え方もあるとは思いますが

そういったシガラミ(？)を明後日方向に吹っ飛ばしたこの漢らしい実装。

すばらしい。ナイスガッツ。

crm configure edit、便利ですけどね

とりあえずいろいろぶっ壊れちゃう可能性も大だからね 使用および使用効果につきましては､お客様の責任とさせていただきます。

2. 知恵袋

リリース情報でご紹介したBOOTHはマルチサイトクラスタの管理を行うものですが クラウド環境におけるHAを実現するために「Pacemaker Cloud」というプロジェクトも存在します。 

こちらはled by Red Hat, というかコロちゃんの育ての親であるところの

スティーブンさんとその仲間たちが開発しています。

ソースコードのダウンロードはこちら。

最新版はv0.5ということで、BOOTHと同じくまだまだ動作は不安定です。

Pacemaker Cloudのキーワードはこんな感じ。

Assembly

  • 仮想マシンや監視エージェント、アプリケーションなどの集合体。

  • VM(Virtual Machine)と、ほぼ同義です。

  • 監視エージェントは後述のMatahariを想定しています。

  • アプリケーションは、Pacemakerでいうところのリソースですね。 DBとかWebサーバとかファイルシステムとかサービスを提供するためのアプリケーションです。

Deployable

  • Assembliesの集合体です。

  • 異なる物理マシンで起動するVM(=Assmbly)も同じDeployableに含めることができます。

Deployable Policy Engine(DPE)

  • Deployableを制御するコンポーネントです。

Cloud Policy Engine(CPE)

  • クラウド上で実行される仮想環境間の依存関係や可用性を保証するコンポーネントです。

  • Deployableの起動 停止処理を実行します。

Matahari

  • システムを管理・監視するためのAPIの集合です。

  • Pacemakerのlrmdに似ています。

  • ノードおよびリソースの起動停止、監視処理を実行します。

さて、目新しい用語がいろいろでてきましたが、Pacemaker Cloudの動作概要はこんな感じ。

  • CPEを起動

  • CPEがDPEを起動

  • DPEがDeployableに含まれるAssemblyを起動

  • Assembly起動時に、VM上でMatahariとアプリケーションも起動

  • Matahariがノードの状態とアプリケーションの状態をDPEに通知

  • アプリケーションに異常が発生した場合は、Matahariが故障を検知しアプリケーションを再起動

  • アプリケーションの再起動が設定回数以上失敗した場合は、DPEが別のAssemblyを起動しサービス再開

  • ノードに異常が発生した場合は、DPEが別のAssemblyを起動しサービス再開

  • DPEに異常が発生した場合は、CPEがDPEを再起動

  • DPEの再起動が設定回数以上失敗した場合は、CPEが別のDPEを起動(この時Assemblyの再起動はなし)

  • コンポーネント間の通信にはAMQPを使用

そして、PacemakerとPacemaker Cloudはどう違うのか。

  • 他ノードを新規に起動することによってサービスを継続

Pacemakerのアクティブ/スタンバイ構成では、スタンバイノードも起動した状態、 いわゆるホットスタンバイなのですが、クラウド環境では、コールドスタンバイとなります。

サービスのフェイルオーバというより、ノードの起動を含めてイチからやり直し、といった感じです。 まずは自ノードでの再起動を試みて、設定回数以上失敗した後、他ノードを起動することも可能です。

  • エスカレーション機能の実装

アプリケーションの故障、Assemblyの故障、DPEの故障をエスカレーションすることができます。

アプリケーション故障の根本原因が実は物理ノードにあった場合

アプリケーションを何回再起動してもやっぱ無理、ということで

Assemblyの再起動に挑戦、でもやっぱ無理、

じゃ、DPEも再起動してみた、でもやっぱ無理

ということで、別の物理ノードでDPE再起動

という流れが自動的に行われるわけですな。

てか、物理ノードが壊れたらまず真っ先にDPEが検知するかもしれんけどな。

そして！最大の特徴は！

Pacemaker Cloudという名前であるにもかかわらず

仮想マシンでも物理マシンでもPacemakerは動いていない！

Pacemakerのライブラリ(pengine)は呼んでますけどね。

Pacemaker的な役割(ノード監視、リソース監視)はMahahariが担っています。

で、このMatahariも最新版がv0.6っていう開発途中段階なので

なんかもう人柱臭しかしない。

Matahariのソースコードはこちら。

あ、そうそう、あんどりゅーくんもMatahariの開発メンバーです。

実際にクラウド環境を構築する場合は、PacemakerとMatahariに加えて

OpenStack, Aeolus, oVirtといったクラウドプロジェクトのパッケージ群と連携します。

BOOTHもPacemaker CloudもMatahariもロードマップに日付が入っていないので

安定版がいつ頃でてくるのかそのへん興味しんしんですね。

ちなみに、Fedora16で、Pacemaker Cloud + Matahariのインストールは

yum installでさくっと成功したので、環境構築はそんなに難しくない。

繰り返します！ ひ　と　ば　し　ら　だ　い　ぼ　し　ゅ　う　で　す　よ　！

では、今月はこれにてどろん！εεεεεヾ(*´ー`)ﾉ

よいお年を〜