4 / 6« First...23456

別冊あんどりゅーくん(第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セクションを設定してください。

Linux-HAユーザーズガイド

序文

本書は、Heartbeatクラスタメッセージングレイヤ、Linux-HAクラスタリソースエージェント、Linux-HAが維持する他のクラスタ構成品を記述するリファレンスガイドです。

本書に関して皆さまのご意見をお寄せください。コメント、訂正、提案などを linux-ha@lists.linux-ha.org メーリングリストに投稿してください。

Heartbeat

クラスタメッセージングレイヤとしてのHeartbeat

Heartbeat はクラスタ基盤サービス(通信とメンバシップ管理)を提供するデーモンです。これによってクライアントプロセスは、他ノードで動作している通信相手プロセスの存在(と消失!)を知ることができ、メッセージの交換が簡単にできるようになります。

利用者にとって意味のある使い方にするには、Heartbeat デーモンとクラスタリソース制御部(CRM)を組み合わせて利用する必要があります。CRMはサービス(仮想IPアドレス、ウェブサーバ等)の起動や終了をつかさどるもので、これによってサービスの高可用化が実現できるようになります。

Heartbeatデーモンは、ユーザが使えるようにするためにクラスタリソースマネージャ(CRM)と組み合わせる必要があります。CRMは、クラスタが提供する高可用サービス(IPアドレス、webサーバなど)を起動・停止します。Heartbeatと連携する標準クラスタリソースマネージャはPacemakerです。Pacemakerは高い拡張性と多機能性を誇り、HeartbeatとCorosyncの両方のクラスタメッセージングレイヤをサポートします。

Note

Heartbeatリリース 2.1.4まで、Pacemakerは、Linux-HAプロジェクトの一環としてHeartbeatと共同開発されていました。しかし、当リリース後、Pacemakerプロジェクトは独立プロジェクトとして分割され、Heartbeatクラスタメッセージングを完全サポートしながら開発が進められました。

コンポーネント構成

Heartbeatメッセージングレイヤは、連動するいくつかのコンポーネントから構成されています。

通信モジュール

Heartbeat通信モジュールは、高度な認証機能を持ち、ローカルで順序化されたマルチキャストメッセージングを、基本的にはいかなるメディアででも(IPベースであってもそうでなくても)提供します。Heartbeatは、以下のネットワークリンクタイプでのクラスタ通信をサポートします。

IPv4ユニキャストUDP
IPv4ブロードキャストUDP
IPv4マルチキャストUDP . . . → Read More: Linux-HAユーザーズガイド

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

別冊あんどりゅーくん(第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年生)

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

4 / 6« First...23456