1 / 212

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

先日、Pacemaker 1.1.7のリリースノートを紹介させていただきましたが
そのなかで気になっていた項目を調べてみました。

  • 順序制約の新機能について
  • 複数STONITHの設定について
  • 故障時にフェイルカウントがインクリメントされない
  • on-failの設定が反映されない



順序制約の新機能について
順序制約にrequire-allを設定すると、次のような動作が可能となります。
例) リソースAもしくはリソースBのいずれかが起動していればリソースCは起動することができる。

今回は、A,Bという2個のリソースに対してrequire-allを設定しましたが、3個以上のリソースに対しても同様の条件を設定することができます。


設定例)

<resources>
 <primitive class="ocf" id="A" provider="pacemaker" type="Dummy"/>
 <primitive class="ocf" id="B" provider="pacemaker" type="Dummy">
 <primitive class="ocf" id="C" provider="pacemaker" type="Dummy"/>
</resources>

<constraints>
 <rsc_order id="order01">
   <resource_set id="require-all-set-1" sequential="false" require-all="false">
     <resource_ref id="A"/>
     <resource_ref id="B"/>
   </resource_set>
   <resource_set id="require-all-set-2">
     <resource_ref id="C"/>
   </resource_set>
  </rsc_order>
</constraints>

えーっと、いつもの便利なcrm shellさんは、まだrequire-allに対応していません!
というわけで久しぶりにXMLでごりごり設定してみましたが、require-allはまだちょっと微妙だなーということがわかりました。
上記の設定を使用して、1ノードで動作を確認してみると確かに期待通りに動いています。
でも、2ノードで試してみると、colocationとかlocationを設定していないのでAとBが別のノードで起動しちゃうんですよね。
AとBとCは同じノードで起動させたい場合が多いんじゃないかなと思うんですがcolocationを設定するとrequire-allが効いてませんでした。
これはまだちょっとお披露目程度の機能だと思っていたほうがよいですね。

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

今年は閏年だから一日得したーと思っていましたが
やっぱ二月は逃げ足はえーなおいまてこら
ということで、今月もリリース情報と知恵袋です。

リリース情報

  1. Corosync 1.99.x
  2. LCMC 1.3.0
  3. libqb version 0.10.x
  4. fence-virt 0.3.0

1. Corosync 1.99.x

Corosync v2に向けたベータ版がほぼスケジュール通りにリリースされています。

The schedule:
Alpha January 17, 2012 version 1.99.0
Beta January 31, 2012 version 1.99.1
RC1 February 7, 2012 version 1.99.2
RC2 February 14, 2012 version 1.99.3
RC3 February 20, 2012 version 1.99.4
RC4 February 27, 2012 version 1.99.5
RC5 March 6, 2012 version 1.99.6
Release 2.0.0 March 13, 2012 version 2.0.0

アルファリリース(1月24日)
Corosync 1.99.0 (Alpha release of Needle 2.0) available at ftp.corosync.org!

Migrate to libqb (https://github.com/asalkeld/libqb/wiki)
———————————————————
- Common features like IPC is now shared between Corosync and other
projects, so it’s probably better tested.
- Corosync is now single threaded (with exception of logging), so no
longer problems with deadlock, race conditions, … Also IPC speed
should be better

  • IPC(プロセス間通信)のライブラリとしてlibqbを採用しました。
  • ログ出力以外の処理はシングルスレッドで実行します。
    このためデッドロックや競合は発生しません。IPCの速度も向上しているはずです。


OBJDB/CONFDB replaced by ICMAP/CMAP
———————————–
- Significantly simplified API

  • OBJDB/CONFDBはICMAP/CMAPへ変更されました。
    なんかよくわかんないですけど、「simplified」って書いてあるからまあいいかな…?


Plugins are gone
—————-
- For creators of plugins it means, that code need to be built on top of CPG.

  • CPG(Closed Process Group) APIを使用して、プロセスグループの単位でメンバシップを管理します。
    なお、現在のプラグインインタフェースは廃止されます。


Votequorum improved
——————-
- Votequorum now contains almost all functionality of CMAN quorum
- Many new features implemented (auto_tie_breaker, wait_for_all, …)

  • クォーラム機能のアレコレが取り込まれています。
    2.0.0がリリースされたら動作検証してみないと!

    この後も続々とベータ版がリリースされていますが、やはりクォーラム関連の機能追加は
    今回のリリースにおける大きな目玉の一つです。

あれ?
1.99.3がどっかいったような気がするけどそれはきっと気のせいだ。

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

Pacemaker Cloud v0.5.0の動作確認をしてみた \(^o^)/

Pacemaker Cloud Projectは、クラウド環境におけるHA機能の実装を目的としたプロジェクトです。

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とは別のプロジェクトです。
ソースコードはこちらで公開されています。

  • Pacemaker Cloudのざっくりしたイメージ

正常起動時 → Assemblyがサービスを提供
Assemblyが提供しているサービスが故障 → DPEがサービスを再起動
Assembly(=仮想マシン)故障 → DPEが仮想マシンを再起動
サービスや仮想マシンの再起動が指定回数以上失敗 → DPEが別のAssemblyを起動
DPEが故障 → CPEがDPEを再起動(このときAssemblyは再起動しないはず)


んー、まだちょっとふらふらしたイメージなので、実際に環境構築をして動作を確認してみることにしました。

環境構築の手順は以下のサイトを参考にしました。
http://ahsalkeld.wordpress.com/a-mash-up-of-openstack-and-pacemaker-cloud/ http://ahsalkeld.wordpress.com/better-integration-of-openstack-and-pacemaker-cloud/
http://www.pixelbeat.org/docs/pacemaker-cloud/

Fedoraにはもう取り込まれているので、今回はFedora 16で動作を確認することにします。

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

「一月は往ぬる、二月は逃げる、三月は去る」というわけで一月はいぬってしまいました。
いぬるってなんとなく意味わかるけどなんでしたっけこれ。

【往ぬる/去ぬる(いぬる)】
(元のいたところへ)帰る、(本来の場所へ)戻っていく、過ぎ去る、去る
【いぬ】のナ行変格活用連体形

ナ変!

【ナ行変格活用】
未然形-な
連用形-に
終止形-ぬ
連体形-ぬる
已然形-ぬれ
命令形-ね

この活用をするのは「死ぬ」「往ぬ(去ぬ)」の二語のみだそうです。
ナ変、積極的に活用していきましょう!
というわけで、今月もリリース情報と知恵袋です。

リリース情報

  • 1. LCMC 1.1.2
  • 2. Pacemaker Cloud 0.6.0
  • 3. libqb 0.9.0
  • 4. Corosync 2.0.0(リリース予定)
  • 5. DRBDのバージョンについて
  • 6. LCA 2012のレポート


1. Announce: LCMC 1.1.2 / Pacemaker, DRBD, KVM GUI

LCMCのversion 1.1.2が1月4日にリリースされました。

LCMCは、クラスタの状態を表示するためにPacemakerのptestコマンドを使用していたのですが
Pacemaker 1.1系ではptestコマンドが廃止され、crm_siumulateコマンドが導入されました。
crm_simulateコマンドは開発途中であるため、glibのバージョンによっては
コマンドの実行中に突然クラッシュしてしまうこともあるようです。
ただし、ptestとcrm_simulateが共存しない環境
つまりPacemaker 1.0系もしくはPacemaker 1.1系の単一環境においては
crm_simulateのクラッシュは報告されていないようです。
ptestの機能はcrm_simulateに引き継がれているので
機能的なデグレードは発生していません。

また、現段階ではあくまで「実験的な実装」なのですが、リモートホストに対してcrm shellを実行できるようになったようです。
実際に試したわけではないので、たんなる想像なのですが
ホストのアイコンをクリックするとcrm shellのポップアップが表示されたり
ペインが切り替わったりするとかそういう感じなんですかね?
Rastoさん曰く、「機能が安定するまでは、デフォルトでdisabled(使用不可)にしようと思ってたけど
experimental(実験的)って但し書きをつけとけば
びびって誰も使わないかなと思って、デフォルトで使えるようにしてみた」
ということなので、勇気のあるかたはクリッククリック!

 

2. [ANNOUNCE] Release of Pacemaker Cloud 0.6.0

Pacemaker Cloudのversion 0.6.0が1月25日にリリースされました。

追加された機能の一覧

  • OpenStackとの連携機能を追加しました。
  • パッケージを分割しました(詳細は後述)。
  • assemblyにUbuntuのサポートを追加しました

現在サポートされているOSはFedora 14, 15, 16, RHEL 6.1, Ubuntu 10.03です。
現在サポートされているアーキテクチャはx86_64のみです。

  • WordPressとMySQLのデモンストレーションを追加しました。
  • イベント実行時に出力されるメッセージを改善しました。
  • assemblyの生成時にsshのキーを追加しました。
  • 故障回復からのエスカレーション機能を実装しました。
  • いくつかのバグを修正しました。
  • パフォーマンスの改善をおこないました。

パッケージの分割について
メーリングリストにこのような提案がポストされたことがありました。
Pacemaker Cloudはaeolus, libvirt, openstack, ovirtとの連携を目指しているのですが

ぞれぞれのパッケージに依存するコンポーネントは別々にインストールできるようにしたいというのが提案の主旨です。
上記の提案がいよいよv0.6.0に取り込まれたようなので、Fedora 16でRPMをつくってみました。

# cat /etc/fedora-release
Fedora release 16 (Verne)
# uname -a
Linux fedora16 3.1.9-1.fc16.x86_64 #1 SMP Fri Jan 13 16:37:42 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
# yum-builddep pacemaker-cloud
# git clone http://github.com/pacemaker-cloud/pacemaker-cloud
# git checkout v0.6.0
# ./autogen.sh
# ./configure --prefix=/usr --localstatedir=/var --sysconfdir=/etc
# make rpm

Wrote: /home/ikedaj/pacemaker-cloud/pacemaker-cloud-0.6.0-1.fc16.src.rpm
Wrote: /home/ikedaj/pacemaker-cloud/x86_64/pacemaker-cloud-0.6.0-1.fc16.x86_64.rpm
Wrote: /home/ikedaj/pacemaker-cloud/x86_64/pacemaker-cloud-debuginfo-0.6.0-1.fc16.x86_64.rpm
Wrote: /home/ikedaj/pacemaker-cloud/x86_64/pacemaker-cloud-core-0.6.0-1.fc16.x86_64.rpm
Wrote: /home/ikedaj/pacemaker-cloud/x86_64/pacemaker-cloud-libvirt-0.6.0-1.fc16.x86_64.rpm
Wrote: /home/ikedaj/pacemaker-cloud/x86_64/pacemaker-cloud-openstack-0.6.0-1.fc16.x86_64.rpm

あ、ほんとだ。なんか増えてる。
ちなみにv0.5.0はこんな感じです。

# git checkout v0.5.0
# ./autogen.sh
# ./configure --prefix=/usr --localstatedir=/var --sysconfdir=/etc
# make rpm

Wrote: /home/ikedaj/pacemaker-cloud/pacemaker-cloud-0.5.0-1.fc16.src.rpm
Wrote: /home/ikedaj/pacemaker-cloud/x86_64/pacemaker-cloud-0.5.0-1.fc16.x86_64.rpm
Wrote: /home/ikedaj/pacemaker-cloud/x86_64/pacemaker-cloud-debuginfo-0.5.0-1.fc16.x86_64.rpm

せっかくRPMをつくったのでv0.6.0をインストールしてみました。

# cd /home/ikedaj/pacemaker-cloud/x86_64
# rpm -ihv pacemaker-cloud-0.6.0-1.fc16.x86_64.rpm
error: Failed dependencies:
 pacemaker-cloud-core = 0.6.0-1.fc16 is needed by pacemaker-cloud-0.6.0-1.fc16.x86_64
 pacemaker-cloud-libvirt = 0.6.0-1.fc16 is needed by pacemaker-cloud-0.6.0-1.fc16.x86_64
 pacemaker-cloud-openstack = 0.6.0-1.fc16 is needed by pacemaker-cloud-0.6.0-1.fc16.x86_64

おい。結局、openstackとの依存関係はあるんかい。
そういやaeolusとかovirtはどこいったんだ。
依存関係、えらいっこちゃです。

# grep Requires pacemaker-cloud-0.6.0/pacemaker-cloud.spec.in
Requires: %{name}-core = %{version}-%{release}
Requires: %{name}-libvirt = %{version}-%{release}
Requires: %{name}-openstack = %{version}-%{release}
BuildRequires: autoconf
BuildRequires: automake
BuildRequires: glib2-devel
BuildRequires: dbus-glib-devel
BuildRequires: libxml2-devel
BuildRequires: libqb-devel
BuildRequires: pacemaker-libs-devel
BuildRequires: libtool-ltdl-devel
BuildRequires: qmf-devel
BuildRequires: libxslt-devel
BuildRequires: libmicrohttpd-devel
BuildRequires: systemd-units
BuildRequires: libcurl-devel
BuildRequires: python-nova
BuildRequires: python-glance
Requires: python-daemon
Requires: python-qmf
Requires: qpid-cpp-server
Requires: oz > 0.5.0-1
Requires: %{name}-core = %{version}-%{release}
Requires: %{name}-core = %{version}-%{release}
Requires: openstack-nova
Requires: python-nova
Requires: openstack-glance
Requires: python-glance

しょうがないのでopenstackナントカたちもインストールしました。

# yum install openstack-glance
# yum install openstack-nova

めんどくさくなってきたので、とりあえず全部インストールしました。

# rpm -ihv pacemaker-cloud-*
Preparing...                ########################################### [100%]
 1:pacemaker-cloud-core   ########################################### [ 20%]
 2:pacemaker-cloud-libvirt########################################### [ 40%]
 3:pacemaker-cloud-opensta########################################### [ 60%]
 4:pacemaker-cloud        ########################################### [ 80%]
 5:pacemaker-cloud-debugin########################################### [100%]

ブローカーを起動させます。

# systemctl start pcloud-cped.service

v0.5.0でつくったデモが動くかなー。

# pcloudsh deployable_start dep01

ゲストの起動は成功しましたが、ゲストに定義したリソースが起動しませんでした。
ノード故障を発生させても無反応でした。
(´・ω・`)
まだ設定が甘いんだな…。

v0.5.0のデモは「別冊あんどりゅーくん」でご紹介する予定です。
試してみたことは、このリンクとほとんど同じことなのでこちらも参考にしてください。
「クラウド」とか偉そうなこといってるけど、まだv0.5.0だからたいしたことはできませんよーだ。

ところで、Pacemaker Cloudの環境構築を行う際は
ホストに pacemaker-cloud、ゲストに matahari, resource-agentsをインストールします。
ホストの pcloud-qpidd.service をブローカ、
ゲストの matahari-host.service, matahari-service.service をエージェントとして
Qpid Management Framework(QMF)に準拠したメッセージが
Advanced Message Queuing Protocol (AMQP) を使用してやり取りされます。
そして!我らがStevenくん曰く!
「MQじゃなくて!sshでノードとかリソースとかの状態を監視するっていうのもアリじゃね!」
というわけで、こちら。
Adding second monitoring method to Pacemaker Cloud – sshd

ノードの生死確認はuptimeを使ったりしています。
v0.7.0から利用可能な機能です。

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


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

リリース情報は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を指定する必要がなくなりました。

参考:http://linux-ha.sourceforge.jp/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,

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

いつのまにか師走インしていますが、今月もリリース情報と知恵袋です。

リリース情報の大きな目玉は下記2点です。

  • Pacemaker 1.0.12のリリース
  • Cluster-glue 1.0.9のリリース

知恵袋ではIPaddr2 RAの裏技(?)をご紹介します。

1. リリース情報


1-1. Pacemaker 1.0.12

Pacemaker 1.0系の最新版がリリースされました!
後述のCluster-glueとあわせて、Linux-HA Japanではrpmパッケージの公開準備を行っています。
もうしばらくお待ちください。

主な変更点

cib: Call gnutls_bye() and shutdown() when disconnecting from remote TLS connections
cib: Remove disconnected remote connections from mainloop
対向ノードが停止した場合、そのノードからの接続を完全に切断します。

crmd: Cancel timers for actions that were pending on dead nodes
crmd: Do not wait for actions that were pending on dead nodes
対向ノードが停止した場合、そのノードで実行されていたactionがペンディング状態となる場合あります。

ノードが停止している場合は、ペンディング状態となったactionのタイムアウトを待たずに即時に次のactionを実行します。

crmd: Ensure we do not attempt to perform action on failed nodes
故障ノードでのactionの実行を抑止します。

PE: Correctly recognise which recurring operations are currently active
故障発生時にoperationが何度も呼び出されることがありますが
どのoperationがactiveであるのかを正確に判定できるよう修正されました。

PE: Demote from Master does not clear previous errors
Masterリソースがdemoteする際、もしかして故障履歴が削除されてしまっていた?(気づかなかったな…)
demote実行後も故障履歴が保存されるよう修正されました。

PE: Ensure restarts due to definition changes cause the start action to be re-issued not probes
start処理関連の定義が変更された際に、リソースを強制的に再起動するように変更されました。

PE: Ensure role is preserved for unmanaged resources
PE: Ensure unmanaged resources have the correct role set so the correct monitor operation is chosen

リソースのroleを保持することによってunmanaged状態でも正しい動作が得られるようになりました。

PE: Move master based on failure of colocated group
Master/Slaveとgroupに制約が設定されている場合、
groupの故障に伴ってMasterも移動することができるようになりました。

このチェンジセットで月刊あんどりゅーくん(11月号)で紹介したコノ動作が改善されています!

pengine: Correctly determine the state of multi-state resources with a partial operation history
故障によりoperationの履歴が保存されていないMaster/Slaveリソースの動作が改善されました。

PE: Only allocate master/slave resources once
Master/Slaveリソースの配置動作がループしないように修正されました。

Shell: implement -w,—wait option to wait for the transition to finish
crm shellにwaitオプションが追加されました。crm shellから実行されたコマンドが終了するまで待機します。

Shell: repair template list command
crm shellのtemplate listコマンドの動作が改善されました。

すべてのチェンジログはこちらから参照できます。

また、Pacmaker 1.0系がgithubのリポジトリへお引っ越ししました。
なお、最新版(Pacemaker 1.1系)のリポジトリはこちら


1-2. Reusable Cluster Components (“glue”) 1.0.9

Cluster-glue 1.0.9がリリースされました!

主な変更点

stonith: external/ipmi: add missing double quote
ipmiプラグインが実行できない症状を改善しました。

stonith: external/ipmi: add the priv parameter (ipmitool -L)
ipmiプラグインからipmitoolコマンドの-Lオプションが実行できるようになりました。

LRM: lrmd: set op status to cancelled for running monitor operations
リソースの移動を実行した後に、monitor処理が停止する症状が改善されました。
※ この症状は毎回発生するものではありませんがタイミングによっては
どのリソースでも発生する可能性があります。

ha_log: increase MAXENTITY size to accommodate long stonith strings
ログメッセージのヘッダーに含まれる文字数制限が拡張されました。

hb_report: improve destination directory handling (bnc#727295)
hb_reportコマンドのdestオプションにフルパスを指定する必要がなくなりました。
パスを指定しない場合は、hb_reportコマンドを実行したディレクトリにレポートが出力されます。

チェンジログはこちらからも参照できます。

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

ふりかえってみれば10月後半は結構リリースラッシュでした。

10月19日 Cluster-glue 1.0.8
10月23日 LCMC 1.0.2
10月24日 Ubuntu 10.04
10月28日 DRBD 8.3.12

リリース情報では、それぞれのリリースノートを簡単にご紹介します。

知恵袋は、Pacemaker 1.0.11 で Master/Slaveリソースを使用する場合の注意点および
遷移グラフを使用した解析方法をご紹介します。

(1) リリース情報

Cluster-glue 1.0.8のリリース

Clustre-glueは、lrmdやSTONITH、その他各種ライブラリを含むコンポーネントです。

The highlights: 

新しい STONITH プラグイン(libvirt, vcenter, hetzner)が追加されました。
- new external/libvirt stonith plugin (thanks to Holger Teutsch)
- new external/vcenter stonith plugin (thanks to Nhan Ngo Dinh)
- new external/hetzner stonith plugin (thanks to RaSca) 

sbd(storage-based death) が複数デバイスにも対応しました。
- support for multiple devices in sbd 

lrmd(local resource management datemon)がCIB(Cluster Information Base)からだけではなく、
ローカルの設定ファイルからもパラメータを取得することができるようになりました。
- lrmd can read parameters from local files, not only from CIB
 (important for configurations with sensitive data) 

重複するログの出力を制御することができるようになりました。
- log spamming control
 (allows controling number of similar messages logged)


LCMC 1.0.2のリリース

今回のリリースはバグフィックスがメインなので大きな機能追加はありません。
ちなみにロゴはむりやりピンクになってます。

The most important changes:

Mavenのpom.xmlを追加しました。 
* add maven pom.xml file 

CentOS 5でDRBDをインストールする際の問題を解決しました。
* fix installation of DRBD on centos5 

サードパーティのライブラリで発生する警告を抑止しました。
* @SuppressWarnings in the 3rd party libs 

ディレクトリ構造を変更しました。
* change directory structure to the latest standard 

仮想環境用のオプションを追加しました。
* add options in VM wizard for XEN 

brctlコマンドの検索パスを追加しました。
* search for brctl in /usr/sbin /sbin and /usr/local/sbin dirs 

旧パッケージ(DRBD-MC)で使用していた名称をLCMCに置き換えました。
* change some old names to LCMC 

Java 7でコンパイルしました。
* make it compile with Java 7 

左クリックでポップアップが起動しないようにしました。
* don't let the left click to show a popup 

DRBD 関連の修正
* fix the "after" DRBD option in DRBD < 8.4
* use units for all DRBD numeric fields 

アイコンを変更しました。
* change application icon 

startupスクリプトを追加しました。
* add LCMC startup script


Ubuntu 10.04向けパッケージのリリース

Ubuntu 10.04向けに下記のパッケージがアップデートされました(参考情報)。
どのパッケージも現行の最新版ですね。
ところで、Ubuntu 11.10向けは一体…?

This update includes:
» Corosync 1.4.2
» Heartbeat 3.0.5
» cluster-glue 1.0.8
» resource-agents 3.9.2
» Pacemaker 1.1.6


DRBD 8.3.12のリリース

今回のリリースはバグフィックスがメインなので、大きな機能追加はありませんでした。
ただし、PacemakerからDRBDを制御する際に利用する drbd RAに修正が入っているため、この点は別途ご紹介したいと思います。

8.3.12 (api:88/proto:86-96)
--------
DRBD 8.3.7以前のバージョンとの互換性に関する修正
 * Fixed a rare compatibility issue with DRBD's older than 8.3.7
 when negotiating the bio_size 

pause/unpauseが並行して実行された場合に発生する競合条件での不具合を修正
 * Fixed a rare race condition where an empty resync could stall with
 if pause/unpause events happen in parallel 

再接続処理を高速化
 * 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. 

DRBDの複数リソースをPacemakerのgroupで管理する場合の不具合修正(後述)
 * crm-fence-peer.sh: Can now deal with multiple DRBD instances being in
 a master/slave group 

故障デバイスを強制的に切り離すための--forceオプションを追加。
disk-timeoutオプションでタイムアウトも設定できるようになりました。
 * Allow detach from frozen backing devices with the new --force option;
 configurable timeout for backing devices by the new disk-timeout option


「DRBDの複数リソースをPacemakerのgroupで管理する場合の不具合修正」について
DRBDに複数のリソースを設定する場合、drbd.confに複数のresourceセクションを作成します。

resource r0 {
        device        minor 0;
        meta-disk    internal;
        disk            /dev/cciss/c0d1p1;

        on node01{
                address 192.168.200.101:7790;
        }
        on node02{
                address 192.168.200.102:7790;
        }
}

resource r1 {
        device        minor 1;
        meta-disk    internal;
        disk            /dev/cciss/c0d1p2;

        on node01{
                address 192.168.200.101:7791;
        }
        on node02{
                address 192.168.200.102:7791;
        }
}

さて、いきなりちょっと話がかわりますが、handlersセクションとdiskセクションの設定について。
DRBDの同期ネットワークが切断された場合、セカンダリノードを「Outdated」状態、
つまり、プライマリノードと同期がとれていない状態とみなす必要があります。
DRBDに同梱されている crm-fence-peer.sh というシェルスクリプトを使用すると
同期ネットワーク切断時にセカンダリノードを「Outdated」とマーキングし、再同期が完了するまでは
セカンダリノードがプライマリ状態へプロモートすることを抑止することができます。
内部ではPacemakerの配置スコアを「-INFINITY」へ変更することによって、プロモート動作を抑止しています。
スコア値の変更はPacemakerのインターコネクト経由で実行されるため、crm-fence-peer.sh を使用する場合は
DRBDの同期ネットワークと、Pacemakerのインターコネクト用ネットワークは、別系統にしなければなりません。

設定例
handersセクションとdiskセクションに以下の行を追加して、設定を反映させてください。
drbd.confの変更を反映するためには、「# drbdadm adjust all」コマンドを実行します。

設定例(drbd.conf 一部抜粋)

 handlers {
 fence-peer                "/usr/lib/drbd/crm-fence-peer.sh";
 after-resync-target     "/usr/lib/drbd/crm-unfence-peer.sh";
 ...
 }

disk {
 fencing         resource-only;
}

※ 詳細は「The DRBD User’s Guide 8.3.2. Resource-level fencing using the Cluster Information Base (CIB)」を参照

リソース数が1つの場合は、上記の設定で問題ないのですが
リソース数が2つ以上の場合、各リソースのresourceセクションにhandlersセクションを設定する必要があります。
この場合、もともとのhandlersセクションの設定ではなく、resourceセクションの設定が優先して使用されます。
また、crm-fence-peer.sh および crm-unfence-peer.sh には、–id-prefixを指定します。

--id-prefix=drbd-fence-by-handler-<リソース名>

設定例(drbd.conf 一部抜粋)

 handlers {
 fence-peer                "/usr/lib/drbd/crm-fence-peer.sh";
 after-resync-target     "/usr/lib/drbd/crm-unfence-peer.sh";
 ...
 }

disk {
 on-io-error     detach;
 fencing         resource-only;
}

resource r0 {
 ...
 handlers {
 fence-peer               "/usr/lib/drbd/crm-fence-peer.sh --id-prefix=drbd-fence-by-handler-r0";
 after-resync-target    "/usr/lib/drbd/crm-unfence-peer.sh --id-prefix=drbd-fence-by-handler-r0";
 }
 ...
}

resource r1 {
 ...
 handlers {
 fence-peer              "/usr/lib/drbd/crm-fence-peer.sh --id-prefix=drbd-fence-by-handler-r1";
 after-resync-target    "/usr/lib/drbd/crm-unfence-peer.sh --id-prefix=drbd-fence-by-handler-r1"; 
 }
 ...
}

なんでこんなめんどくさいことになっていたかというと、まあぶっちゃけ、DRBDに同梱されたdrbd RAが
複数リソースのhandlers設定に対応してなかったっていう話でして。
DRBD 8.3.12のdrbd RAは複数リソースのhandlers設定にも対応しています。
DRBD 8.3.11以前のバージョンでこの構成を使用する場合は、上記の例を参考にresourceセクションの
入れ子としてhandlersセクションを設定してください。

月刊あんどりゅーくん(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個でもいいんじゃね?ってちょっとだけ思ったけど、まあ、ね…。

1 / 212