別冊あんどりゅーくん(第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が効いてませんでした。
これはまだちょっとお披露目程度の機能だと思っていたほうがよいですね。

リリース情報 (Pacemaker 1.1.7)

2012年3月29日にPacemaker 1.1.7 リリースされました!

ということで、“The Cluster Guy”に掲載されたリリースノートに注釈を加えながら翻訳してみました。

After much hard work, the latest installment of the Pacemaker 1.1 release series is now ready for general consumption.

いろいろと大変なこともありましたが、ついにPacemaker 1.1.7をリリースします。

後述の「変更点」にも挙げられていますが、Corosync 2.0への対応が大変だったようです。
なお、2012年4月6日の時点ではCorosyncはv1.99.9がリリースされています。
3月中に2.0がリリースされる予定でしたが、ちょっと遅れているみたいですね。

Changesets 513
Diff

1171 files changed,
90472 insertions,
19368 deletions

チェンジセット合計数 513
変更されたファイル数 1171
追加行数 90472
削除行数 19368

As well as the usual round of bug fixes, see the full changelog,

バグフィックスも含めた全てのチェンジログはGitHubで参照することができます。

this new release brings:

今回のリリースに含まれる大きな変更点をいくつか紹介します。

  1. Support for Corosync 2.0
  2. Logging optimisations (less of it and less work performed for logs that wont be printed)
  3. The ability to specify that A starts after ( B or C or D )
  4. Support for advanced fencing topologies: eg. kdump || (network && disk) || power
  5. Resource templates and tickets have been promoted to the stable schema
  6. Support for gracefully giving up resources depending on a ticket



1. Support for Corosync 2.0

メッセージングレイヤとして Corosync 2.0 にも対応しました。

・現在サポートされているメッセージングレイヤとクラスタマネージャの組み合わせ

メッセージングレイヤ クラスタマネージャ
Heartbeat 3.0.5 Pacemaker 1.0系
Corosync 1.4系 Pacemaker 1.0系
Heartbeat 3.0.5 Pacemaker 1.1.6
Corosync 1.4系 Pacemaker 1.1.6
Corosync 2.0 Pacemaker 1.1.7

なお、ここでPacemaker 1.0系と表記しているバージョンは
Linux-HA Japanのリポジトリからダウンロード可能な1.0.11
および、ClusterLabからダウンロード可能な1.0.12を指します。

これより古いバージョンを使用されている場合は、バージョンアップをお勧めします。
Linux-HA JapanでもPacemaker 1.0.12のパッケージを準備中です!
もうすぐダウンロードできるようになるらしいです。|_・)チラッ

しかし、Corosync-1.99.9(= 2.0) と Pacemaker-1.1.7 の組み合わせでは
リソースのモニター故障時にフェイルカウントがあがらないという症状(fail-count is not updated)、
が報告されています。
Corosync 2.0に対応したよ!といいつつもCorosync 2.0 + Pacemaker 1.1.7 の組み合わせは
まだちょっと微妙ですね…。
また、Heartbeat-3.0.5とPacemaker-1.1.7の組み合わせでも
on-failの設定が無効となる(デフォルト値のrestartが採用されてしまう)という症状(on-fail is not effective)
が報告されています。
近いうちに Pacemaker 1.1.7-1 とか -2 とかがリリースされそうな気がします。

ちなみに、Pacemaker 1.1系とCorosync 1.4系以上(2.0系を含む)を組み合わせて動作させる場合は、CorosyncとPacemaker、それぞれのinitスクリプトを実行する必要があります。

参考情報

起動手順


# service corosync start
# service pacemaker start

停止手順


# service pacemaker stop
# service corosync stop

また、Heartbeat 3.0.5とPacemaker 1.1.7を組み合わせて動作させる場合は、ha.cfに下記の設定を追加してください。


compression bz2
compression_threshold 30 
traditional_compression yes

compression_thresholdの設定値は各環境で調整する必要があります。

参考情報
compression with heartbeat doesn’t seem to work
traditional_compression – controls compression mode


2. Logging optimisations (less of it and less work performed for logs that wont be printed)

ロギング処理の見直しを行いました。

今まで info で出力されていたメッセージのレベルが debug へ変更されています。
Pacemaker はちょっとアレなくらいログを吐くので、出力量が減ってきているのはありがたいのですが、リソースの実行状況を追跡するときに頼りにしていたあんなメッセージやこんなメッセージも debug に変更されてました T^T
これって1.1.6で変更されてたのかなあ…気づかなかったよ…。

以前にご紹介したこともありますが、プロセスにシグナルを送ることによって、そのプロセスだけデバッグレベルを変更することができます。

デバッグレベルをあげる


# pkill -SIGUSR1 <プロセス名>

デバッグレベルをさげる


# pkill -SIGUSR2 <プロセス名> 

なお、ロギング処理にはlibqbが採用されていますが、Pacemaker 1.1.7のビルド時にlibqpは必須ではありません。
Pacemaker 1.1.8以降はIPC(プロセス間通信)にもlibqpを採用しており、ビルド時の前提条件にも追加されるようです。
参考情報


3. The ability to specify that A starts after ( B or C or D )

リソースB または C または D のいずれかが起動した後に、リソースA を起動させるという複雑な順序制約の設定が可能となりました。
参考情報

実際に試してみて、またご報告します。
ふと思ったんですが、これってcrm shellとかLCMCとかでも設定できるようになってるのかな…。

月刊あんどりゅーくん(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から利用可能な機能です。

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

7月14日(金)と15日(土)に開催されたOSC2011 Kansai@Kyotoに行ってきました。
クリアフォルダ250枚と団扇300枚は2日目の
終了3時間前くらいになくなってしまいました。

次回のOSC@名古屋でも配布する予定なので
ご希望の方はお早めにブースまでお越しください。

 

 

 

 

 

 

 

 

 


 

また、猛暑にもかかわらず、2日目11時からのセミナーには40名の方に参加していただきました。
講師は「あ、eject の方?」でお馴染みの、たなかさんでした。おつかれさまでした!
当日の資料はこちらからダウンロードすることができます。

今回は、ブースでお留守番をしていたときにいただいた質問と、
セミナーの最後にいただいた質問をおさらいしてみようと思います。


ブースでいただいた質問

(1) Pacemakerは仮想環境でも使用できるか?
(2) 必要なNICの本数は?
(3) 事例は公開されているか?
(4) 将来の目標は?
(5) 読み方はピースメーカー?ペースメーカー?
(6) BSDで使えるか?


(1) Pacemakerは仮想環境でも使用できるか?


使えます。

OSC関西@京都のセミナーでは仮想環境でデモを行いました。
資料にも「本日のPacemakerデモ環境」として仮想環境でのクラスタ構成が紹介されています。
仮想環境の構成には

  • ゲストOSにPacemakerをインストールするパターン
  • ホストOSにPacemakerをインストールするパターン

の2パターンがあります。

ゲストOSにPacemakerをインストールするパターンは、ゲストOS≒物理サーバです。

ホストOSにPacemakerをインストールするパターンは、ゲストOSを「リソース」として
VirtualDomain RAで監視します。
ゲストOSのマイグレーションとかもできます。
このパターンでは、ゲストOS上で起動している特定のプロセスは監視できないので、
ホストOSにもゲストOSにもPacemakerをインストールする多層式の構成となる場合もあります。


(2) 必要なNICの本数は?

ノード間で生死を確認しあうためのインターコネクトLANは絶対に必要です。
なので、インターコネクトLAN用に最低でも1本は必要です。
ただし、インターコネクトLANは2本以上用意して冗長性を確保することが推奨されています。
その他にも、WebサーバやDBなど、外部からアクセスするための仮想IPアドレスが必要なサービスの場合は仮想IP用のサービスLANも必要となります。

サービスLANは2本以上用意して冗長性を確保することが推奨されています。
サービスLANを冗長化する場合はbondigを利用してください。

そういえば、インターコネクトLANはbondingしなくていいの?と思われるかもしれませんが、
メッセージングレイヤにHeartbeatを使用する場合は、bondingでもbondingでなくてもどっちでもいいです。

ただし、Corosyncを使用する場合はbondingを使用したほうがよいかもしれません。
Corosyncは複数のインターコネクトLAN構成で、接続が切れたり繋がったりしたときの
「表示系」がまだちょっと弱かったような気がする。。

動作は問題ないはず(たぶん)。
最近は直ってきたのかもしれません。v1.4でたし!?

一方、メッセージングレイヤにHeartbeatを使用する場合は、bondingを使わない場合が多いような気がします。
ha.cfにインターフェース名を複数書けばいいだけの話しなので、わざわざbondingにしなくてもいいよねえ、というかbondingドライバのバグにはまっちゃうとヤダとかそういうのもあったような気がする。

インターコネクトLAN、サービスLANの他に、管理者や運用担当者、もしくは運用管理ツールがPacemakerの実行状況などを確認するための管理LANも別系統であると便利かもしれません。
管理LANはそれほどがつがつ使うこともないはずなのでインターコネクトLANまたはサービスLANと兼用でも問題ありません。

DRBDも組み合わせて使用する場合は、DRBDの同期LANも必要となります。
DRBDは、一つの同期リソースにつき、1本の同期LANしか設定することができないので
bondingで冗長化することが推奨されています。
同期リソースが複数ある場合は、同期LANの本数を増やす、もしくは
1本の同期LANで複数のポートを使用することになります。

というわけで

最小構成(合計1本)

  • インターコネクトLAN    1本

冗長構成(合計7本)

  • インターコネクトLAN    2本
  • サービスLAN               2本(bondingで1本に集約)
  • 管理LAN                     1本
  • DRBDの同期LAN          2本(bondingで1本に集約)

となります。


(3) 事例は公開されているか?

Linux-HA Japanの公式サイトで事例の公開は行っていません。
お隣にブースを出していただいた株式会社サードウェアさんのWebサイト「Linux-HA (DRBD) ユーザ事例」からDRBD関連の事例をダウンロードすることができます。
Linux-HA Japanの公式サイトにも事例を公開していきたいのですが、いろいろと大人の事情で難しいようですね…。
「公開しても問題ありません」という案件や実際に稼動しているシステムがあれば、ぜひメーリングリストまでご連絡ください。

 

(4) 将来の目標は?

ちょっとのけぞりましたが、これって今後のロードマップってことですね。

一瞬、小学校の卒業文集的なナニカかと思いましたよ…。
ちなみに、あんどりゅーくんのつくったロードマップはこちら。

ロードマップというより、これから実装していきたい機能の落書き帳的なものなので、実装予定期日は決まっていません。
他にも

  • 仮想環境対応(キーワード:Matahari)
  • 大規模クラスタ対応

などがメーリングリストで話題になっています。

 

(5) 読み方はピースメーカー?ペースメーカー?

ペースメーカーです。
ピースメーカーだと Peacemakerになっちゃう気がします。Pacemakerです。


(6) BSDで使えるか?

残念ながらBSDは未踏領域です。人柱大募集です。
Linux-HA Japan では、RedHat, CentOS用のRPMを作成していますが、
あんどりゅーくんの管理している clusterlabs からは
Fedora, openSUSE, EPEL用のRPMがダウンロードできます。

Debianは「はらくん」がパッケージングしてくれるらしいよ。

はらくん(高校2年生)

めっさいじられてますけど。

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

というわけで「月刊あんどりゅーくん」に引き続き「別冊あんどりゅーくん」もはじめました。


前月分のメーリングリストから抜粋したおもしろ情報を
「月刊あんどりゅーくん」として発行していく予定ですが
月刊からもれたおもしろネタ、もしくは月刊のボリュームがあふれてきちゃったときは
暫定対処として「別冊あんどりゅーくん」を発行します。
月刊のほうは「ほぼ」月刊を目指しますが、別冊のほうが気が向いたときに発行します。
もう一生気が向かないかもしれません。


では、今回は下記2項目をご紹介します。
(1) バグ情報
(2) 知恵袋


(1) バグ情報

■ cloneの動作

Master/Slave、cloneについては、まだまだ動作がビミョーな部分もあるのですが、
Pacemaker 1.1 ではかなり動作が改善されています。
Pacemaker 1.0 へもできる限りバックポートしていますが、うまくバックポートできない場合もありますのでご了承ください。
3月分のメーリングリストでは次の事例が報告されていました。


例1) Pacemaker 1.1 で改善済み、そしてPacemaker 1.0 へのバックポート済みのパターン

crm サンプル

property stonith-enabled=”false”
primitive DummyVM1 ocf:pacemaker:Dummy \
op monitor interval=”60s” timeout=”60s” \
op start on-fail=”restart” interval=”0″ \
op stop on-fail=”ignore” interval=”0″ \
meta is-managed=”true” resource-stickiness=”1000″ migration-threshold=”2″
primitive DummyVM2 ocf:pacemaker:Dummy \
op monitor interval=”60s” timeout=”60s” \
op start on-fail=”restart” interval=”0″ \
op stop on-fail=”ignore” interval=”0″ \
meta is-managed=”true” resource-stickiness=”1000″ migration-threshold=”2″
primitive StorGr1 ocf:heartbeat:Dummy \
op monitor on-fail=”restart” interval=”60s” \
op start on-fail=”restart” interval=”0″ \
op stop on-fail=”ignore” interval=”0″ \
meta is-managed=”true” resource-stickiness=”1000″ migration-threshold=”2″
clone StorGr1-clone StorGr1 \
meta target-role=”Started” interleave=”true” ordered=”true”
location score-DummyVM1 DummyVM1 400: dl380g5c
location score-DummyVM2 DummyVM2 400: dl380g5d
order start-DummyVM1-after-StorGr1-clone inf: StorGr1-clone DummyVM1
order start-DummyVM2-after-StorGr1-clone inf: StorGr1-clone DummyVM2

なんか resource-stickiness とか migration-threshold とかの設定がこだわってんなあという感じですが
メーリングリストからほぼコピペです。
STONITH設定してねぇぞごるぁと怒られるのがめんどかったので「property stonith-enabled=”false”」は
追加で設定しています。でもやっぱりタイムアウト短ぇぞごるぁとは怒られるけどね。


というわけで、リソースを起動させます。
# crm configure load update sample.crm

# crm_mon -i1
============
Last updated: Tue Mar 29 17:06:14 2011
Stack: Heartbeat
Current DC: dl380g5d (498d1812-c867-4534-a5aa-85aff30c8eff) – partition with quorum
Version: 1.0.10-47037ab663d7 stable-1.0 tip
2 Nodes configured, unknown expected votes
3 Resources configured.
============
Online: [ dl380g5c dl380g5d ]
DummyVM1 (ocf::pacemaker:Dummy): Started dl380g5c
DummyVM2 (ocf::pacemaker:Dummy): Started dl380g5d
Clone Set: StorGr1-clone
Started: [ dl380g5c dl380g5d ]


メーリングリストへの投稿者曰く
DummyVM1 and DummyVM2 were both started on node goat1.( goat1 は dl380g5c に読み替え)
ということなんですが、そうかあ?という気が。たぶん上記の配置で正しいと思うんですよね。

次にdl380g5d で Pacemaker を停止しました。

# service heartbeat stop

# crm_mon -i1
============
Last updated: Tue Mar 29 17:06:48 2011
Stack: Heartbeat
Current DC: dl380g5d (498d1812-c867-4534-a5aa-85aff30c8eff) – partition with quorum
Version: 1.0.10-47037ab663d7 stable-1.0 tip
2 Nodes configured, unknown expected votes
3 Resources configured.
============
Online: [ dl380g5c dl380g5d ]
DummyVM1 (ocf::pacemaker:Dummy): Started dl380g5c
DummyVM2 (ocf::pacemaker:Dummy): Started dl380g5c ← ★ フェイルオーバ
Clone Set: StorGr1-clone
Started: [ dl380g5c ]
Stopped: [ StorGr1:1 ]

投稿者によると、DummyVM2 がフェイルオーバできなかったらしいんですが
あんどりゅーくん曰く、1.1.5 だとフェイルオーバできるはずとのこと。(投稿者の環境は 1.1.2)
1.0.11でも無事フェイルオーバできていることを確認しましたので、今回はめでたしめでたし。


例2) Pacemaker 1.1 で改善済み、だけどPacemaker 1.0 へのバックポートが厳しいパターン

crm サンプル
primitive ClusterIP ocf:heartbeat:IPaddr2 \
params ip=”192.168.101.121″ nic=”bond0″ cidr_netmask=”24″ clusterip_hash=”sourceip” \
op monitor interval=”30s”
primitive HttpProxy ocf:pacemaker:Dummy \
op monitor interval=”60s” timeout=”60s” \
op start on-fail=”restart” interval=”0″ \
op stop on-fail=”ignore” interval=”0″ \
clone HttpProxyClone HttpProxy
clone ProxyIP ClusterIP \
meta globally-unique=”true” clone-max=”2″ clone-node-max=”2″
colocation HttpProxy-with-ClusterIP inf: HttpProxy ProxyIP
order HttpProxyClone-after-ProxyIP inf: ProxyIP HttpProxy
property $id=”cib-bootstrap-options” \
cluster-infrastructure=”openais” \
expected-quorum-votes=”2″ \
stonith-enabled=”false” \
no-quorum-policy=”ignore”

HttpProxy に設定されたリソースは メーリングリストの構成では apache だったんですけどDummy に差し替えました。


リソースを起動させます。
# crm configure load update sample.crm

# crm_mon -i1
============
Last updated: Tue Mar 29 17:34:52 2011
Stack: Heartbeat
Current DC: dl380g5d (498d1812-c867-4534-a5aa-85aff30c8eff) – partition with quorum
Version: 1.0.10-47037ab663d7 stable-1.0 tip
2 Nodes configured, 2 expected votes
2 Resources configured.
============
Online: [ dl380g5c dl380g5d ]
HttpProxy (ocf::pacemaker:Dummy): Started dl380g5c
Clone Set: ProxyIP (unique)
ClusterIP:0 (ocf::heartbeat:IPaddr2): Started dl380g5c ← ★ それぞれのノードに
ClusterIP:1 (ocf::heartbeat:IPaddr2): Started dl380g5d ← ★ 分散してます


片方のノードをスタンバイ化します。
# crm node standby dl380g5d

# crm_mon -i1
============
Last updated: Tue Mar 29 17:38:13 2011
Stack: Heartbeat
Current DC: dl380g5d (498d1812-c867-4534-a5aa-85aff30c8eff) – partition with quorum
Version: 1.0.10-47037ab663d7 stable-1.0 tip
2 Nodes configured, 2 expected votes
2 Resources configured.
============
Node dl380g5d (498d1812-c867-4534-a5aa-85aff30c8eff): standby
Online: [ dl380g5c ]
HttpProxy (ocf::pacemaker:Dummy): Started dl380g5c
Clone Set: ProxyIP (unique)
ClusterIP:0 (ocf::heartbeat:IPaddr2): Started dl380g5c
ClusterIP:1 (ocf::heartbeat:IPaddr2): Started dl380g5c ← ★ フェイルオーバ


スタンバイ化したノードをオンラインに戻します。
# crm node online dl380g5d

# crm_mon -i1
============
Last updated: Tue Mar 29 17:38:45 2011
Stack: Heartbeat
Current DC: dl380g5d (498d1812-c867-4534-a5aa-85aff30c8eff) – partition with quorum
Version: 1.0.10-47037ab663d7 stable-1.0 tip
2 Nodes configured, 2 expected votes
2 Resources configured.
============
Online: [ dl380g5c dl380g5d ]
HttpProxy (ocf::pacemaker:Dummy): Started dl380g5c
Clone Set: ProxyIP (unique)
ClusterIP:0 (ocf::heartbeat:IPaddr2): Started dl380g5c
ClusterIP:1 (ocf::heartbeat:IPaddr2): Started dl380g5c ← ★ 居座り。フェイルバックしない。

Pacemaker 1.1.5 だと居座り動作は発生せず、ちゃんともとのノードにフェイルバックできるようです。
しかし、このパッチはPacemaker 1.0.11 にはバックポートできませんでした。

メーリングリストでは居座りリソースをもとのノードの戻す裏技が紹介されていたのでどうしても困ったときは、参考にしてください。


裏技:clone-node-max を一時的に 1 に変更する(初期設定は 2)

# crm resource meta ProxyIP set clone-node-max 1

# crm_mon -i1
============
Last updated: Tue Mar 29 17:47:41 2011
Stack: Heartbeat
Current DC: dl380g5d (498d1812-c867-4534-a5aa-85aff30c8eff) – partition with quorum
Version: 1.0.10-47037ab663d7 stable-1.0 tip
2 Nodes configured, 2 expected votes
2 Resources configured.
============
Online: [ dl380g5c dl380g5d ]
HttpProxy (ocf::pacemaker:Dummy): Started dl380g5c
Clone Set: ProxyIP (unique)
ClusterIP:0 (ocf::heartbeat:IPaddr2): Started dl380g5c
ClusterIP:1 (ocf::heartbeat:IPaddr2): Started dl380g5d ← ★ お!戻った!

設定は元に戻しておいたほうがよいです。
# crm resource meta ProxyIP set clone-node-max 2


では、お次は知恵袋。

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

暖かくなってきたので「月刊あんどりゅーくん」はじめました。


Linux-HA 関連のメーリングリスト、リポジトリの更新情報を日々ストーキングしつつ
これは!というおもしろネタをご紹介いたします。
まずは、ほぼ月一更新を目指します。
寒くなったら冬眠します。
ちなみに中の人は絶賛募集中です。
現在、ボットが某情報収集コードに従って作戦実行中であります。


で、そもそも、「あんどりゅーくん」とはなんぞや?
「あんどりゅーくん」とは、Pacemaker の開発者 Andrew Beekhof(Red Hat) のことです。
Heartbeat から Pacemaker が飛び出しちゃったよわっしょい!の火の元だったりとか
メーリングリストの回答があまりにもそっけないとかで
ちょっと付き合いづらい人なのかなあと思っていましたが
実際お会いしてみると意外にお茶目な方でした(右斜め上参照)。


なお、PacemakerでHA環境を構築するためには、他にも必要なコンポーネントがいくつかありますが
それぞれの主要メンバはこちら。

  • Clueter Resource Agents/Reusable Cluster Components

Dejan Muhamedagic(Novell) … メーリングリストの回答が超やさしい。唯一の癒し系。
Florian Haas(Linbit) … たまに日本に来てる。すごい親切なんやけどマシンガントークは勘弁な。
Lars Ellenberg(Linbit)

  • Heartbeat

上に同じ。一応、Linbitメインな感じ。

  • Corosync

Steven Dake(Red Hat) … 声ちっさい。

  • Python GUI

Yan Gao(Novell)

  • Hawk(HA Web Konsole)

Tim Serong(Novell) … 会ったことはあるというか見たことある。けどどんな人かよく覚えていない。。。

  • DRBD MC

Philipp Reisner(Linbit)

  • 上記の荒ぶるメンバをたばねつつ、HAの未来を占う人。

Lars Marowsky-Bree(Novell) … LMB。キホン黒づくめ。


LMBとFlorianの議論が熱くなりすぎて周りがドン引き、そこにAndrewが「もういいじゃーん」てな感じで
仲介に入るイメージで大体あってます。

Lars,Yan,Philippはお会いしたことないのでノーコメント。
あれ?Dejanも会ったことないけど。。。まあよかたい。


以上がいわゆる本家な方々です。
日本サイドでは、ksk_haさんがPacemakerのバックポートなどを担当しています。

あとですね、セミナーや勉強会でたまにご質問をいただくのですが
Pacemakerの応援キャラクター、かなちゃん、かよちゃん、ぺーちゃん、ころちゃんは本家公認です!
2010年11月にボストンで開催された「Linux Plumber Conference」で
minky0さんから上記主要メンバにクリアファイルをお渡ししていただいています。

最近、デビューしたドロシーちゃんとビアンカちゃんはDRBDの応援キャラですが
こちらはLinbit公認なのかどうかボットにはよくわかりません。

DRBDのおもしろネタについては、ttkzwさんが「月刊ふろーりあんくんはやりたいなぁといつも思いつつ。」
とつぶやいていらっしゃるので、もう少し暖かくなったら「月刊ふろーりあんくん」もはじまるのではないかと思われます。


では、いよいよ本題です。


今回は下記2項目をご紹介します。
(1) リリース/アナウンス関連
(2) バージョン互換情報