2012年10月15日に CRM shell v1.2.1 がリリースされました。

Hello, The CRM shell v1.2.1 is released. The highlights . . . → Read More: リリース情報 (CRM shell v1.2.1)

2012年10月15日に glue 1.0.11 がリリースされました。

Hello,

The current glue repository has been tagged as . . . → Read More: リリース情報 (glue 1.0.11)

10月19日に DRBD 8.3.14 がリリースされました！

Besides bug-fixes this release brings support for FLUSH/FUA . . . → Read More: リリース情報 (DRBD 8.3.14)

2012年10月23日に Heat API v7 がリリースされました！

Good news, everyone! The Heat developers are pleased . . . → Read More: リリース情報 (Heat API v7)

2012年11月22日に resource-agents 3.9.4 がリリースされました！

今回リリースされたバージョンの注目点、以前のバージョンからの変更点などをご紹介します。

• ocf-rarun: support for resource agents, reduces code complexity and number of software errors
• zabbixserver: new resource agent
• IPaddr2: partial rewrite and support for IPv6
• iscsi: support for auto recovery and performance improvements
• mysql-proxy: numerous improvements, features, and fixes
• Raid1: support for multiple arrays (configured in parameters)
• tools: replace the findif binary by findif.sh
• Raid1 ocft test case

• ocf-rarun: ocf-rarunという新しいスクリプトが追加されました。
• zabbixserver: zabbixserver用のRAが新規に追加されました。
• IPaddr2: LVSによる負荷分散構成でのIPv6に対応しました。
• iscsi: オートリカバリのサポートとパフォーマンスの改善が取り込まれました。
• mysql-proxy: 機能追加およびバグ修正が数多く取り込まれています。
• Raid1: 複数のアレイで構成された環境に対応しました(構成情報をパラメータとして設定することができます)。
• tools: findif.sh(スクリプト)から呼び出されている findif(バイナリ)を変更しました。
• Raid1 関連のテストケース(ocft)が追加されました。

ocf-rarunについては次のページで使い方をご紹介します。

リリースノートに記載されていた変更点以外にもちょっと気になったのが、こちらのチェンジセット。

• Medium: oracle: connect as a regular user in monitor

very connection as sysdba is logged in an audit log. This can result in a large number of new files created. A new user named OCFMON is created (if it doesn’t exist) in the start action and subsequently used in monitor. It has very limited rights.

• 3.9.3までの動作
  • sysユーザを使用し sysdba権限で接続および監視処理を実行します。

• 3.9.4以降の動作
  • 監視処理専用のOCFMONユーザで接続および監視処理を実行します。
  • OCFMONユーザが存在しない場合は、RAのstart処理実行時に自動的に作成されます。ただしstop処理時に削除はされません。

動作に変更はありませんが、監視処理を実行するユーザが変更となっています。OCFMONというユーザが勝手に作成されちゃいますがびっくりしないでください。oracle RAを実行中にOCFMONユーザを削除してしまうと、監視処理がエラーとなるので注意が必要です。

The full list of changes for the linux-ha RA set is available in ChangeLog
(https://github.com/ClusterLabs/resource-agents/blob/master/ChangeLog)

今回のリリースに含まれるすべてのチェンジログはこちらを参照してください。

The rgmanager resource agents set received mainly bug fixes.
Please upgrade at the earliest opportunity.

resource-agentsのパッケージには、Pacemaker/Heartbeat用のリソースエージェント(Resource Agent:RA)だけではなく、Red Hat Cluster Suiteに含まれるrgmanager用のRAも含まれています。
rgmanager RAにもいくつか修正が取り込まれていますので、できるだけ早くアップグレードすることをおすすめします。

では次のページでocf-rarunスクリプトの使い方をご紹介します。

オープンソースカンファレンス 2013 Tokyo/Spring では多くの方にご来場頂きありがとうございました。

本日の講演資料を以下に公開いたしました。

http://www.slideshare.net/takmatsuo/osc-tokyospring2013-16694861

なお、講演中のデモで使用した設定ファイルは以下になります。

先日リリースされたFedora 19には、Linux-HA Japanで開発したPostgreSQLのストリーミングレプリケーションのクラスタリング機能がついに同梱されました。

Pacemaker のバージョンも開発版で比較的新しい 1.1.9 が同梱されているので、これを使ってPostgreSQLストリーミングレプリケーションのクラスタリングに挑戦してみたいと思います。

環境

今回、Fedoraのインストール手順方法は割愛しますが、以下の環境を用意してください。
※ 超スモール構成のため、商用での利用は推奨しません。信頼性を確保するには、Pacemaker用やレプリケーション用の専用LANを準備し、STONITHの導入を検討してください。

• ホスト名は、52-fe19 と 53-fe19 とします。 (単に私の手元の環境で使っているホスト名で、深い意味はありません。。。)
• 皆大好きなSELinuxやファイアウォールは無効にしておきます。
• 設定が複雑になるので、ネットワーク監視やディスク監視は行いません。
• 超スモール環境のためネットワークは2本で挑戦します。なお、よく悪者扱いされるNetworkManagerは停止し、IPは手動で設定してください。また、/etc/hostsにホスト名を定義するとトラブル可能性があるので定義しないでください。
  • 1本目用途 : PostgreSQLへのアクセス用+Pacemaker通信用
    • 52-fe19のIP 192.168.0.152
    • 53-fe19のIP 192.168.0.153
    • PostgreSQLアクセス用の仮想IP(vip-master) 192.168.0.252
  • 2本目用途 : レプリケーション用 + Pacemaker通信用
    • 52-fe19のIP 192.168.1.152
    • 53-fe19のIP 192.168.1 .153
    • レプリケーション用仮想IP(vip-rep) 192.168.1.252

インストール

両ノードに、yumを使って必要なパッケージを一気にインストールし、PostgreSQLのアーカイブディレクトリを作成しておきます。(両ノードで実行)

# yum install postgresql-server pacemaker corosync pcs
読み込んだプラグイン:langpacks, refresh-packagekit
(省略)
完了しました!
# su - postgres
$ mkdir /var/lib/pgsql/pg_archive

PostgreSQLの設定

PostgreSQLのデータベースクラスタを作成します。(52-fe19上で実行)

$ cd /var/lib/pgsql/data
$ initdb
データベースシステム内のファイルの所有者は"postgres"ユーザでした。
このユーザがサーバプロセスを所有しなければなりません。
(省略)
成功しました。以下を使用してデータベースサーバを起動することができます。

    postmaster -D /var/lib/pgsql/data
または
    pg_ctl -D /var/lib/pgsql/data -l logfile start

postgresql.conf ファイルに以下を設定します。その他の設定はデフォルトのままで構いません。なお、synchronous_standby_names パラメータが設定されている場合は、必ずコメントアウトして無効にしておいてください。(52-fe19上で設定)

listen_addresses = '*'
wal_level = hot_standby
synchronous_commit = on
archive_mode = on
archive_command = 'cp %p /var/lib/pgsql/pg_archive/%f'
max_wal_senders=5
wal_keep_segments = 32
hot_standby = on
restart_after_crash = off
replication_timeout = 5000
wal_receiver_status_interval = 2
max_standby_streaming_delay = -1
max_standby_archive_delay = -1
synchronous_commit = on
restart_after_crash = off
hot_standby_feedback = on

pg_hba.conf ファイルを設定します。(セキュリティは全く考慮していません) (52-fe19上で設定)

host    all             all     127.0.0.1/32        trust
host    all             all     192.168.0.0/16      trust
host    replication     all     192.168.0.0/16      trust

PostgreSQLを起動します。(52-fe19上で実行)

$ pg_ctl -D . start
サーバは起動中です。

53-fe19 にデータをコピーします。(53-fe19上で実行)

# su - postgres
$ pg_basebackup -h 192.168.0.152 -U postgres -D /var/lib/pgsql/data -X stream -P

手動でレプリケーション接続できるか試します。53-fe19に/var/lib/pgsql/data/recovery.confを作成します。

standby_mode = 'on'
primary_conninfo = 'host=192.168.1.152 port=5432 user=postgres'
restore_command = 'cp /var/lib/pgsql/pg_archive/%f %p'
recovery_target_timeline = 'latest'

53-fe19のPostgreSQLを起動します。(53-fe19上で実行)

$ pg_ctl -D /var/lib/pgsql/data/ start

52-fe19上で以下のSQLを使ってレプリケーションの状態を確認します。

$ psql -c "select client_addr,sync_state from pg_stat_replication;"
  client_addr  | sync_state 
---------------+------------
 192.168.1.153 | async
(1 行)

無事レプリケーション接続できました。では、一旦両ノードのPostgreSQLを停止します。(両ノードで実行)

$ pg_ctl -D /var/lib/pgsql/data stop
$ exit

Corosyncの設定

corosyncの設定ファイル/etc/corosync/corosync.confを用意します。(両ノードで作成)

quorum {
           provider: corosync_votequorum
           expected_votes: 2
}
aisexec {
    user: root
    group: root
}
service {
    name: pacemaker
    ver: 0
    use_mgmtd: yes 
}
totem {
    version: 2
    secauth: off 
    threads: 0
    rrp_mode: active
    clear_node_high_bit: yes 
    token: 4000
    consensus: 10000
    rrp_problem_count_timeout: 3000
    interface {
        ringnumber: 0
        bindnetaddr: 192.168.0.0
        mcastaddr: 226.94.1.1
        mcastport: 5405
    }   
    interface {
        ringnumber: 1
        bindnetaddr: 192.168.1.0
        mcastaddr: 226.94.1.1
        mcastport: 5405
    }   
}
logging {
    fileline: on
    to_syslog: yes 
    syslog_facility: local1
    syslog_priority: info
    debug: off 
    timestamp: on
}

Corosyncを起動します。(両ノードで実行)

# systemctl start corosync.service

/var/log/messages に以下のようなメッセージが出ればcorosyncの起動成功です。

[MAIN  ] main.c:275 Completed service synchronization, ready to provide service.

ちなみに私の環境では、52-fe19でこのログが出続けていますが、原因はよくわかりません。。。とりあえず動いているようなのでこのまま先に進みます。(おぃ! )

Incrementing problem counter for seqid 2087 iface 192.168.0.152 to [1 of 10]

次はPacemkaerの起動・設定に入っていきます。

Pacemaker本家コミュニティにて、開発最新版のPacemaker 1.1.10 がリリースされました。本バージョンに大きな問題がなければ、Pacemakerはメジャーバージョンアップするとの予告が出ており、1.1.10 は重要なバージョンと言えそうです。

これを記念して、Linux-HA Japanでは、いち早く最新のパッケージを使ってみたいという方のために、RHEL6(x86_64)および互換OS向けのNightlyビルドを公開したいと思います。

http://linux-ha.sourceforge.jp/nightly/

ビルド対象のパッケージは、Pacemaker 1.0系(安定版)、1.1系(開発版)、および周辺コンポーネントです。

Nightlyビルドには、Pacemaker 1.0系と1.1系両方のコンポーネントが混在しているため、どのコンポーネントを組み合わせればよいかわからない人は以下を組み合わせてみてください。

■はじめに

Linux-HA Japanをご覧の皆さんこんにちは。Linux-HA Japanの中の人、ひがしと申しますm(_ _)m

みなさん、Pacemaker触っていますか？

OSCなどのブースや講演で中の人がPacmakerをデモしているのを見かけると思いますが、ああいう構成って一から自分で作ろうとするとまぁ大変ですよね。

個人的に最初につまづくのが”CRM設定ファイル“だと思います。

例えば、2011年福岡で開催されたOSCで講演したデモ環境のCRM設定ファイル（これに含まれるdemo4.crmファイル）を見てみてください。

長い・・しかも設定ファイルなのに￥記号たくさんww

やばい・・ゲシュタルト崩壊して￥がVサインに見えてきた(注1)。。だからみんなPacemakerのことピースメーカーって呼んじゃうんだな(注2)・・そのせいで呼び名が変更されるって記事もあったし・・・

注1:＼に見えてる人はごめんなさい

注2：本当はペースメーカーです

でもしかし！このCRM設定ファイルの攻略なしにPacemakerでHA環境は作れないのです。

というわけで本記事ではこのCRM設定ファイルを読める/書けるようになることを目標に、いろいろ書いていこうと思います。

■CRM設定ファイルとは

CRM設定ファイルは、Pacemakerに、「どのようなリソース（※1）をどこで稼働させるか？」「いつフェイルオーバ(※2)するのか？」というようなことを教えるための設定ファイルです。

賢明な読者の中には、「その設定ってコマンドラインからやるんじゃなかったっけ？」とお思いの方もいるかもしれません。

その通り！

過去に掲載された記事の中でも、crmコマンドというPacemaker付属のコマンドラインで行っています。

CRM設定ファイルはこのcrmコマンドに流し込むコマンドを列挙したものです。

小規模な設定であればコマンドを直接打ってもいいですが、大規模になるとファイルに書いておいた方が保存、配布などが楽になります。Windowsでいうバッチファイル、Linuxでいうシェルスクリプトみたいなものですね。

これで、一つ謎が解けました。そうですCRM設定ファイルに「\」が多かったのはその箇所が本来1行で書くコマンドラインだからです。

ちなみにcrmコマンドは、設定のみならず、クラスタの状態確認、操作等、様々な機能を持っています。まさにクラスタのシェルですね。

さぁ以上を踏まえて、早速、CRM設定ファイルを読んでいきましょう。

※1 リソースって何だっけ、という人は、この記事の「リソース制御機能」を参照してください。
※2 以後フェイルオーバを「F/O」と略記します。

■CRM設定ファイルの構成

前述の2011年福岡で開催されたOSCで講演したデモ環境のCRM設定ファイルをもう一度見てみてください。

心の眼でよーく見ると、行の始めは以下の８種類のコマンドのどれかであることがわかります。

ちなみに行頭が「#」はコメントアウト、「\」は行が続くことを表します。

• property
• rsc_defaults
• group
• clone
• primitive
• location
• colocation
• order

次回以降で紹介しますが、Master-Slave構成を使う場合、

• ms

というコマンドも使用します。

上記９コマンドあれば、たいがいのHA構成は定義できちゃいます。

早速、９コマンドの解説を、、と言いたいところですが、ここで１つCRM設定ファイルの例を示します。

### Cluster Option ###
property no-quorum-policy="ignore" \
    stonith-enabled="false" \
    crmd-transition-delay="2s"

### Resource Defaults ###
rsc_defaults resource-stickiness="INFINITY" \
    migration-threshold="1"

### Group Configuration ###
group grp \
    resource1 \
    resource2

### Clone Configuration ###
clone clnResource \
    resource3

### Primitive Configuration ###
primitive resource1 ocf:heartbeat:Dummy \
    op start interval="0s" timeout="300s" on-fail="restart" \
    op monitor interval="10s" timeout="60s" on-fail="restart" \
    op stop interval="0s" timeout="300s" on-fail="block"

primitive resource2 ocf:heartbeat:Dummy \
    op start interval="0s" timeout="300s" on-fail="restart" \
    op monitor interval="10s" timeout="60s" on-fail="restart" \
    op stop interval="0s" timeout="300s" on-fail="block"

primitive resource3 ocf:heartbeat:Dummy \
    op start interval="0s" timeout="300s" on-fail="restart" \
    op monitor interval="10s" timeout="60s" on-fail="restart" \
    op stop interval="0s" timeout="300s" on-fail="block"

### Resource Location ###
location rsc_location-1 grp \
    rule 200: #uname eq pm01 \
    rule 100: #uname eq pm02

### Resource Colocation ###
colocation rsc_colocation-1 INFINITY: grp clnResource

### Resource Order ###
order rsc_order-1 0: clnResource grp symmetrical=false

この例は比較的単純ですが、msを除く８のコマンドを全て含んでおり、Active-Standby構成の基本がつまっています。しかもDummyという特殊なリソースのみを使用しているため、Pacemaker以外、Apacheや共有ディスク等のリソースは不要です。

以降、しばらくはこのCRM設定ファイルを題材に解説をしていきます。

次のページで早速このCRM設定でPacemakerを動かしてみましょう。

■はじめに
Linux-HA Japanをご覧の皆さんこんにちは。Linux-HA Japanの中の人、ひがしと申しますm(_ _)m

「動かして理解するPacemaker ～CRM設定編～ その２」ということで、前回の「その１」の続きです。

早速、前回記事に引き続き、CRM設定ファイルを解読していきましょう。

前回は、例の設定ファイルが制御している以下7項目のうち、上から2項目のからくりを読み解きました。

• 1. STONITHは無効です。(その１で読み解き済み)
• 2. 1回のリソース故障でF/Oします。自動フェイルバックはしません。(その１で読み解き済み)
• 3. dummy1, dummy2という名前のリソースをgrpという名前のgroup(グループ)にします。
• 4. dummy3という名前のリソースをclnDummyという名前のclone(クローン)リソースとし、両マシンで起動します。
• 5. dummy1,2,3のリソースは、必ずdummy3(clnDummy)→dummy1→dummy2の順で起動します。
• 6. grpはどちらか片方のマシンで起動します。両マシンが稼働可能な状態の場合、pm01を優先します。
• 7. dummy3(clnDummy)が起動していないノードではdummy1およびdummy2(grp)は起動しません。

今回は、3,4番目および5番目の一部(下線部)を読み解きます。

今回注目するのは以下の部分です。

### Group Configuration ###
group grp \
    resource1 \
    resource2

### Clone Configuration ###
clone clnResource \
    resource3

### Primitive Configuration ###
primitive resource1 ocf:heartbeat:Dummy \
    op start interval="0s" timeout="300s" on-fail="restart" \
    op monitor interval="10s" timeout="60s" on-fail="restart" \
    op stop interval="0s" timeout="300s" on-fail="block"

primitive resource2 ocf:heartbeat:Dummy \
    op start interval="0s" timeout="300s" on-fail="restart" \
    op monitor interval="10s" timeout="60s" on-fail="restart" \
    op stop interval="0s" timeout="300s" on-fail="block"

primitive resource3 ocf:heartbeat:Dummy \
    op start interval="0s" timeout="300s" on-fail="restart" \
    op monitor interval="10s" timeout="60s" on-fail="restart" \
    op stop interval="0s" timeout="300s" on-fail="block"

この箇所ではgroup, clone, primitiveの3コマンドを使用し、どんなリソースを使用するかを定義しています。

■primitiveでリソースを定義
primitiveコマンドはクラスタ内で使用したい個々のリソースの定義を行います。

primitiveコマンドの概要と書式を以下に示します。

 # crm ra info ocf:heartbeat:Filesystem
 RAの簡易説明...

以下の部分は、リソースIDがresource1で、/usr/lib/ocf/resource.d/heartbeat/Dummy をRAとするリソースを定義していることになります。
開始・停止のタイムアウトは300秒、監視のタイムアウトは60秒です。
開始および監視に失敗したときはリソース再起動、停止に失敗したときはクラスタのそれ以後の動作を中止します。

primitive resource1 ocf:heartbeat:Dummy \
    op start interval="0s" timeout="300s" on-fail="restart" \
    op monitor interval="10s" timeout="60s" on-fail="restart" \
    op stop interval="0s" timeout="300s" on-fail="block"

resource2, 3 についても同様です。

■groupでリソースをひとまとめに
groupは、primitiveで定義した個々のリソースをグループ化します。
グループ化したリソースに対しては、以下の制御が行われます。

• 常に同一サーバで起動する。
• groupコマンドに指定した順にリソースを起動する。またその逆順に停止する。

グループ化は、あるサービスを提供するのに、複数のリソースを同時に使用しなければならない場合に使用します。
例えば、データベースをクラスタ化する場合、データベースそのものの他に、共有ディスクや、アクティブ側のデータベースへアクセスするためのIPアドレスなどを同時に起動しなければなりません。
しかも、共有ディスクはデータベースより先に起動(マウント)しなければなりません(さもないとデータファイルがなくデータベースを起動できないでしょう)。

groupコマンドの書式は以下です。

以下部分は、リソースID resource1およびresource2をグループ化しています。グループIDはgrpです。

### Group Configuration ###
group grp \
    resource1 \
    resource2

これにより、resource1とresource2は常に同じノードで起動し、resource1 → resource2 の順で起動し、その逆順で停止します。

■cloneで複数ノードへリソース複製
cloneは、primitiveで定義した個々のリソースをクローン化します。
クローン化したリソースは、通常のリソースと異なり、複数のノード上で同時に起動します。リソースが複製（クローン）され、複数ノードへ配置されるイメージです。

例えば、ノードのネットワーク疎通を確認するリソース(ocf:pacemaker:pingd)を使用する場合、アクティブ側ノードはもちろん、スタンバイ側ノードでもいつでもサービスが提供できるよう、常にアクティブ側と同じようにネットワーク疎通を確認しておく必要があります。
このようなときのためにcloneは用意されています。

cloneコマンドの書式は以下です。

以下の部分は、リソースID resource3をクローン化しています。クローンリソースIDはclnResourceです。
clone-max, clone-node-maxは指定していないため、全ノード(pm01,pm02)で1つずつresource3リソースが起動します。

### Clone Configuration ###
clone clnResource \
    resource3

さぁ、以上で、3,4番目および5番目の一部の制御が理解できました。

• 3. dummy1, dummy2という名前のリソースをgrpという名前のgroup(グループ)にします。
• →primitiveでdummy1, dummy2を定義し、groupでグループ化しています。
• 4. dummy3という名前のリソースをclnDummyという名前のclone(クローン)リソースとし、両マシンで起動します。
• →cloneコマンドでクローンリソースを定義しています。clone-maxを指定していないので両(全)ノードで起動します(デフォルト)。
• 5. dummy1,2,3のリソースは、必ずdummy3(clnDummy)→dummy1→dummy2の順で起動します。
• →dummy1→dummy2の順はこれらがgroupのためです。(dummy3の起動順のからくりは次回説明します。)

次ページでこれらの動作を実験で確認します。

コラム LSBって？
LSBはLinux Standard Baseと呼ばれる、Linuxの内部構造の仕様です。
PacemakerがinitスクリプトをRAとする場合、このLSBに準拠していることを前提に制御をおこないます。
具体的には以下を前提としています。

■はじめに
Linux-HA Japanをご覧の皆さんこんにちは。Linux-HA Japanの中の人、ひがしと申しますm(_ _)m

「動かして理解するPacemaker ～CRM設定編～ その３」ということで、前々回、前回の続きです。

今回で、例の設定ファイルが制御している以下7項目をすべて読み解くことになります。3回に渡ったCRM設定編は今回で最後となります。

• 1. STONITHは無効です。(その１で読み解き済み)
• 2. 1回のリソース故障でF/Oします。自動フェイルバックはしません。(その１で読み解き済み)
• 3. resource1, resource2という名前のリソースをgrpという名前のgroup(グループ)にします。(その２で読み解き済み)
• 4. resource3という名前のリソースをclnResourceという名前のclone(クローン)リソースとし、両マシンで起動します。(その２で読み解き済み)
• 5. resource1,2,3のリソースは、必ずresource3(clnResource)→resource1→resource2の順で起動します。(一部その２で読み解き済み)
• 6. grpはどちらか片方のマシンで起動します。両マシンが稼働可能な状態の場合、pm01を優先します。
• 7. resource3(clnResource)が起動していないノードではresource1およびresource2(grp)は起動しません。

※前回、前々回の記事でリソース名をCRM設定とは異なる「dummy1」などと記載していましたが、「resource1」の誤りでした。すみません。

今回注目するのは以下の部分です。

### Resource Location ###
location rsc_location-1 grp \
    rule 200: #uname eq pm01 \
    rule 100: #uname eq pm02

### Resource Colocation ###
colocation rsc_colocation-1 INFINITY: grp clnResource

### Resource Order ###
order rsc_order-1 0: clnResource grp symmetrical=false

この箇所ではlocation, colocation, orderの３つのコマンドを使用しています。

この３つはいずれもリソースに対し「制約」を設定するためのコマンドです。

「制約」を使用すると、リソースが起動する際の以下３つの条件を設定することができ、それぞれがコマンドに対応しています。

• location　→場所：どのノードで起動するか？
• colocation→同居：どのリソースと一緒に起動するか？
• order　　 →順序：どのリソースの前/後に起動するか？

早速、この３コマンドの説明を、と言いたいところですが、その前に制約を理解するのに重要な概念があります。
それは「スコア値」です。

詳細は後ほど説明しますが、制約の３コマンドはいずれもあるルールに対しスコア値を設定するものです。
なので、まずはスコア値の説明からしたいと思います。

■スコア値の大きいノードでリソースは起動する
スコア値は、リソースをどのノードで起動するかの優先度を示す値です。
ノードを起動したり、リソースを追加したり、故障が発生したり、とクラスタの状態に変化があった場合にPacemakerが自動的に(再)計算します。

Pacemakerは算出したスコア値を比較し、最も大きな値のノードでリソースを起動します。
算出したスコア値が負の値場合、そのノードでそのリソースを起動することはできません。

スコア値は以下の範囲のいずれかになります。

「-INFINITY(マイナス無限大)」と「INFINITY(無限大)」は特殊な値で、前者は「禁止」、後者は「強制」を示します。
それぞれ他の値との演算結果は以下のように定義されています。

• 他の値 + INFINITY = INFINITY
• 他の値 – INFINITY = -INFINITY
• INFINITY – INFINITY = -INFINITY

1,2番目の演算結果はなんとなくわかりますが、3番目の演算結果はちょっと不思議な気がします。
数学的に言えば∞-∞は不定です。が、クラスタのリソースが起動するかどうかが不定となっては不便です。
-INIFNITYは典型的には故障が発生したノードに付与されます。もしINIFINITY – INFINITYが不定だと、後述の制約コマンドでINFINITYを付与したノードで故障が発生した場合、リソースが起動するかどうかが不定になってしまいます。
これを避け、故障したノードでは起動しない、と判断するため-INFINITYを優先しているのです。

スコア値は基本的にはPacemakerがクラスタの状況に応じ自動的に算出しますが、後述の「制約」により特定に場合のスコア値をユーザが決める(Pacemakerに与える)ことができます。
「制約」を上手に活用しスコア値を操作することで、リソースの起動をユーザの意のままに操ることができるのです。

■locationで起動するノードを制約
locationは起動するノードを制約するコマンドです。
そのノードの状態を評価し、それにマッチした場合のスコア値を定義することで設定します。

locationの概要と代表的な書式は以下のようになります。

評価式の中で登場する属性値とは、Pacemakerが保持している値で、ノード毎にリソースの状態や、クラスタの状態を表します。
状況に応じて値が変化することで、そのノードの状態を知ることができます。
典型的にはリソースエージェントがリソースの状態をリアルタイムに示すために使用します。
例えばネットワーク疎通を確認するリソース(ocf:pacemaker:pingd)は、ネットワークが疎通している場合、指定した属性値に値を加算し、疎通していないと値を減算します。属性値は監視の度にリアルタイムに変化するため、この属性値を見ることで、今現在ネットワークが疎通しているのかを確認できるようになっています。

なお、crm_monコマンドに-Aオプションをつけると、属性値を表示させることができます。

以下の部分は、グループgrpに対し、ノードpm01での起動にはスコア200を、ノードpm02での起動にはスコア100を指定しています。
つまり、grpの起動ノードとしてpm01を優先するよう制約しています。

location rsc_location-1 grp \
    rule 200: #uname eq pm01 \
    rule 100: #uname eq pm02

これで、以下の項目が読み解けました。

• 6. grpはどちらか片方のマシンで起動します。両マシンが稼働可能な状態の場合、pm01を優先します。

■colocationで同居するリソースを制約
colocationは指定した(複数の)リソースが同一ノードで起動することに対しスコア値を設定します。

colocationの概要と代表的な書式は以下のようになります。

以下の部分は、グループgrpの起動時に、clnResourceが同じノードで起動する(している)ことを強制しています。

colocation rsc_colocation-1 INFINITY: grp clnResource

これで、以下の項目が読み解けました。

• 7. resource3(clnResource)が起動していないノードではresource1およびresource2(grp)は起動しません。

■orderで順序を制約
orderは指定した(複数の)リソースのアクションを行う順序に対しスコア値を設定します。

orderの概要と代表的な書式は以下のようになります。

以下の部分は、clnResource→grpの順に起動することを示しています。
スコア値は0のため、起動後のclnResourceの状態変化はgrpに影響しません。
symmetricalをfalseにしているため停止順は不定です。

### Resource Order ###
order rsc_order-1 0: clnResource grp symmetrical=false

これで以下の項目が読み解けました。

• 5. resource1,2,3のリソースは、必ずresource3(clnResource)→resource1→resource2の順で起動します。

お気づきの方もいるかもしれませんが、前回ご紹介したgroupコマンドも、同居と順序を指定するものでした。
例えば、「group grp1 resource1 resource2」は「resource1と2は必ず同居し」、「resource1→resource2の順序で起動」を定義します。

groupは、colocationとorderを組み合わせて再現することができます。

次頁で、今回わかったことを応用した実験をしてみましょう。

しばらくさぼっていましたが9月分のリリース情報をまとめて投稿します！

2012年9月3日にMatahari Projectから悲しいお知らせが（ＴДＴ）

As will be evident to those of you who have . . . → Read More: Matahari Project の現状について

CentOS5.5 x86_64 にPacemakerをインストールする方法は、主に以下の4つがあります。

ここでは、下記の1, 2 の方法について記述します。

Pacemaker で制御するリソースを設定するには、crm コマンドを使用します。以下にcrmコマンドの基本的な使い方を記述します。前提として、CentOS 5上にPacemakerのインストールが完了し、Pacemakerが起動しているとします。クラスタ制御部は、Corosync、Heartbeat どちらでも構いません。

まず、crm コマンドを起動します。(以下太字が実際に入力する部分です)

リソースの設定モードに入ります。

現在の設定をshowコマンドで確認します。何も設定をしていないので、表示されるのはノード名（サーバ名)と、バージョン、使用しているクラスタ制御部名(以下の例ではHeartbeat3を使用)だけです。

Pacemakerでは現在、Primitive, Clone, Master/Slave という大きく分けて3つの種類のリソース、および、PrimitiveをまとめたGroupというリソースを定義することができます。これらのリソースの違いについて簡単に説明します。

これらの概念は、Pacemaker-1.0系およびPacemaker-1.1系で共通です。

まず、一番よく使われるのがこの Primitive リソースです。これは全てのリソース定義の基礎になります。

これは、通常のAct-Standby構成で用いるリソースで、どこか一カ所のノードで動くことができます。よって、クラスタ全体のある1ノードだけで動いていればよいリソースに使用し、リソースが故障すれば、他のノードにフェールオーバーさせることができます。データベースやメールサーバのようなものをHAクラスタリングする場合は通常このリソースを定義することになります。

Cloneリソース は、Primitive リソースを複数のノードで動作させたい場合に使用します。そのため定義方法は、まずPrimitive を定義し、それをClone化するという流れになります。

あるアプリケーションを複数のノードで動かしたい場合、Primitiveだけで実現しようとすると、動かしたいノード数分だけ定義する必要がありますが、Cloneの場合は1つのCloneリソースを定義するだけで動かすことができます。

代表的な使用例として、ネットワークの疎通監視に使用するpingd リソースエージェント(以下RA) があります。ネットワーク越しにサービスを提供するAct-Standby . . . → Read More: Pacemaker で扱えるリソースの種類 (Primitive, Clone, Master/Slave, Group)

こんにちは、Linux-HA Japanのひがしです。

Linux-HA Japanは、オープンソースカンファレンス(OSC)に出展させていただき、講演やデモ機展示などを行っています。(過去の出展報告はこちら)

このデモ機について、展示を見に来ていただいた方から、「参考にしたいので設定を教えてほしい」といったご意見をいただくことがありますので、構成および設定内容について公開します。

以下、2016/03/11 記事作成時点の情報です。

まずは、デモ機の構成全体の概要をご説明します。

デモ機は以下のような構成になっています。

物理的には、以下のような構成です。

この構成のポイントは以下です。

HP社のMicroserver Gen8 という機種を使用しています。 この機種は、数万円程度と比較的安価、且つコンパクトですが、iLO(integrated Lights-Out)がオプションとして搭載可能なため、STONITHを有効にしたPacemakerクラスタを組むことができます。

ただし、NICの搭載枚数は、最大4ポートとなります。なので、本デモ構成では、インターコネクトLAN以外のNICが故障した場合、直ちにフェイルオーバが発生します。 商用環境での構成時は、必要に応じ、NICの故障を想定し、bonding等で1ネットワークに複数NICを割り当てることも検討してください。

内蔵ディスクについては、2台搭載し、RAID1でミラーリングしています。PostgreSQLのストリーミングレプリケーション機能およびDRBDを用いて、サーバ間の内蔵ディスクをLAN経由でレプリケーションしているので、共有ディスクは使用していません（コスト低減！）。

Microserver Gen8の上部にちょうど設置できる機種です。L2スイッチにはPacemakerとしての要件は特にありません。(もちろん、ハートビート通信のパケットが滞りなく届くことが前提です。ハートビート通信のパケットは大きくないので、GbEが主流の現在、ハートビート通信による輻輳が問題になることはほとんど無いでしょう。)

ただし、デモ構成のため、L2スイッチ自体の故障・冗長化までは考慮しておらず、各ネットワークごとに1台ずつ設置しています。 商用環境での構成時は、スイッチ類の故障も想定し、冗長化等の対策を別途行ってください。

CentOS 7.1.1503 です。 Linux-HA Japanで提供のPacemakerリポジトリパッケージはRHELおよびCentOS向けのみとなります。

Pacemaker . . . → Read More: OSCデモ機の設定を公開します

2017年3月10日(金)、11日(土)に明星大学にて開催されたオープンソースカンファレンス2017 Tokyo/Springにおいてブース展示及びセミナーで参加させていただきました。

当日のセミナー資料を以下で公開いたします。

セミナープログラム:

セミナー資料:

なお、セミナおよび資料でDocker RAのイメージ名処理のバグについて言及しましたが、本バグの修正パッチが取り込まれました。 以下のRAを利用する事で、バグを回避することが可能です。

2017年8月4日(金)、5日(土)に京都にて開催されたオープンソースカンファレンス2017 Kyotoにおいてブース展示及びセミナーで参加させていただきました。

当日のセミナー資料を以下で公開いたします。

セミナープログラム:

セミナー資料:

2017年9月9日(土)、10日(日)に明星大学にて開催されたオープンソースカンファレンス2017 Tokyo/Fallへ、ブース展示及びセミナーで参加させていただきました。

当日のセミナー資料を以下で公開いたします。

セミナープログラム:

2018年1月26日(金)、27日(土)に大阪産業創造館にて開催されたオープンソースカンファレンス2018 Osakaへ、ブース展示及びセミナーで参加させていただきました。

当日のセミナー資料を以下で公開いたします。

セミナープログラム:

セミナー資料: