3 / 612345...Last »

動かして理解するPacemaker ~CRM設定編~ その2

変更履歴

  • 2013.9.19 初版制定
  • 2016.3.23 Pacemaker-1.1に対応

■はじめに

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

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

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

 

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

  • 1. STONITHは無効です。(その1で読み解き済み)
  • 2. 1回のリソース故障でF/Oします。自動フェイルバックはしません。(その1で読み解き済み)
  • 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)は起動しません。

※2013.1.22 リソース名をCRM設定とは異なる「dummyN」などと記載していましたが、「resourceN」の誤りでした。修正しました。すみません。

今回は、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コマンドの概要と書式を以下に示します。

概要 リソースIDおよびリソースエージェント(RA)を指定し、クラスタ内で使用するリソースを定義します。
リソースの起動、監視、停止それぞれの制御時のタイムアウトおよびそれぞれの制御が失敗したときの挙動も指定します。
書式 primitive リソースID RA名
    [meta リソースの動作設定…]
    [params RAに渡すパラメータ…]
    [op start|stop|monitor オペレーション時の設定…]
設定項目 リソースID リソースの名前を任意の英数字で定義します。クラスタ内で一意でなければなりません。
CRMファイルの他の箇所でこのリソースを示す場合やcrm_monコマンドでの表示等にも使用します。
RA名 使用するRAの種類とファイル名を「:」で区切った記法で指定します。よく使用するパターンは以下です。

ocf:heartbeat:RAファイル名
/usr/lib/ocf/resource.d/heartbeat/RAファイル名※ に配置されたスクリプトをRAとして使用します。
ocf:pacemaker:RAファイル名
/usr/lib/ocf/resource.d/pacemaker/RAファイル名※ に配置されたスクリプトをRAとして使用します。
lsb:initスクリプト名
/etc/init.d/initスクリプト名 に配置されたスクリプトをRAとして使用します。
Linuxに付属のinitスクリプトをRAとして使用することができます。
ただし、initスクリプトがLSBと呼ばれる仕様に準拠している必要があります。
stonith:プラグインファイル名(パス)
STONITH機能を使用する場合、STONITHの方法に応じた専用のプラグインを指定します。
/usr/lib64/stonith/プラグイン名※ に配置されたプログラムを使用します。

ocf:~は「:」で区切られた3つの記述の1,2番目でRAの種別を、3番目がRAのファイル名を示します。
lsb:~およびstonith:~は、「:」で区切られた1番目でRAの種別を、2番目がスクリプト/プログラムのファイル名です。
※Pacemakerをインストールすると、このディレクトリに様々なRA、プラグインが配置されます。

リソースの動作設定 リソースの故障時等の動作を個別に設定します。
前回ご紹介したrsc_defaultsコマンドで指定できるresource-stickinessやmigration-thresholdパラメータを使用できます。
RAに渡すパラメータ RAがリソースの制御のためにパラメータを必要とする場合、「パラメータ名=”値”」の形式でここで指定します。
例えばファイルシステムをマウント・監視するリソース(ocf:heartbeat:Filesystem)の場合、ファイルシステムタイプ、マウントポイント、対象デバイスといったような情報をパラメータで与えます。
Dummy RAのように、動作にパラメータを必要としないRAの場合、記述は必要ありません。

crmコマンドに”ra info RA名”と引数を付与すると、当該RAのパラメータを含む、簡単なマニュアルが表示されます。この表示も参考にしてください。

 # crm ra info ocf:heartbeat:Filesystem
 RAの簡易説明...
オペレーション時の設定 リソースの起動(start)、停止(stop)、監視(monitor)の各オペレーション時のタイムアウト等を「設定=”値”」の形式で設定します。よく使用するのは以下の設定です。

interval
オペレーションの間隔を秒で指定します。開始、停止のように繰り返さないオペレーションの場合、0を指定します。
timeout
オペレーションが完了するのを待つ最大時間を秒で指定します。この時間を過ぎてもオペレーションが成功しない場合、失敗とみなします。
on-fail
オペレーションが失敗した場合の動作を指定します。
よく使用するのは以下の動作です。

  • block :それ以降のあらゆるクラスタ動作をそのままの状態で中止します。
  • restart:このリソースの再起動(停止→起動)を試みます。他のノードへ再配置される場合があります。再起動に失敗した場合、再起動を繰り返し試みます。
  • fence :STONITH機能を使用して、対象ノードの強制停止を試みます。当該リソースは他のノードへ再配置されます。STONITH機能が無効の場合、指定することはできません。
  • ignore :オペレーションの失敗を無視し、このリソースに対する動作以外のクラスタ動作を継続します。
  • stop :このリソースの停止を試みます。他のノードへの再配置はされません。停止に失敗した場合、停止を繰り返し試みます。


以下の部分は、リソース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コマンドの書式は以下です。

書式 group グループID リソースID
設定項目 グループID グループの名前を任意の英数字で定義します。クラスタ内で一意でなければなりません。
リソースID グループ化する対象リソースをprimitiveコマンドで定義したリソースIDで指定します。


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

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

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

■cloneで複数ノードへリソース複製

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

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

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

書式 clone クローンリソースID リソースID
    [meta クローンリソース動作設定…]
設定項目 クローンリソースID クローンリソースの名前を任意の英数字で定義します。クラスタ内で一意でなければなりません。
リソースID クローン化する対象リソースをprimitiveコマンドで定義したリソースIDで指定します。
クローンリソース動作設定 クローンリソースの動作に関する設定を「設定名=”値”」という書式で記述します。
以下のような設定が可能です。

  • clone-max :クラスタ全体で、いくつリソースを起動するかを指定します。デフォルトはクラスタに含まれるノード数です(つまり全ノードで当該リソースが起動します)。
  • clone-node-max:1ノードで当該リソースがいくつ起動するかを指定します。デフォルトは1です。


以下の部分は、リソース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に準拠していることを前提に制御をおこないます。 具体的には以下を前提としています。
  • 「start」「stop」「status」の3つのメソッドが定義されていること。
  • 「start」メソッドはサービス(リソース)の状態に応じ以下の動作および返り値を返すこと。
    • サービスが停止している場合:サービスを起動し0を返す。
    • サービスが(すでに)起動している場合:0を返す。
  • 「stop」メソッドはサービス(リソース)の状態に応じ以下の動作および返り値を返すこと。
    • サービスが(すでに)停止している場合:0を返す。
    • サービスが起動している場合:サービスを停止し、0を返す。
  • 「status」メソッドはサービス(リソース)の状態に応じ以下の動作および返り値を返すこと。
    • サービスが停止している場合:3を返す。
    • サービスが起動している場合:0を返す。
  • それぞれ失敗した場合は、0および3以外のエラーコードを返すこと。
独自のRAを作成する場合も、この仕様に準拠する必要があります。詳細は公式マニュアルを参照してください。

動かして理解するPacemaker ~CRM設定編~ その1

変更履歴

  • 2013.9.19 初版制定
  • 2016.3.23 Pacemaker-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設定ファイルを読める/書けるようになることを目標に、全3回の連載形式でいろいろ書いていこうと思います。

動かして理解するPacemaker ~CRM設定編~ 連載一覧(全3回)

■CRM設定ファイルとは

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

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

その通り!

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

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

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

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

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

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

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

■CRM設定ファイルの構成

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

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

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

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

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

  • ms

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

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

Pacemaker-1.1系の場合、上記に加え fencing_topology というコマンドも使用します。詳細はOSCデモ機の設定を公開しますをご覧ください。

早速、9コマンドの解説を、、と言いたいところですが、ここで1つ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を除く8のコマンドを全て含んでおり、Active-Standby構成の基本がつまっています。しかもDummyという特殊なリソースのみを使用しているため、Pacemaker以外、Apacheや共有ディスク等のリソースは不要です。

なお、Pacemaker-1.1系の場合、「crmd-transition-delay=”2s”」の設定は不要です。Pacemaker-1.1系で試す方は当該行を削除してください。

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

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

Nightlyビルド公開します

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系両方のコンポーネントが混在しているため、どのコンポーネントを組み合わせればよいかわからない人は以下を組み合わせてみてください。

Pacemaker 1.0系 (安定版)

cluster-glue . . . → Read More: Nightlyビルド公開します

Fedora 19 上でPostgreSQL ストリーミングレプリケーションのクラスタリング

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

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

環境

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

fe19-sr

  • ホスト名は、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の起動・設定に入っていきます。

crmコマンドを用いたPacemaker のリソース設定方法

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

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

[root@pm01 ~]# crm
crm(live)#

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

crm(live)# configure
crm(live)configure#

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

crm(live)configure# show
node $id=”0c140f90-7de3-438f-b1b5-3b9722bbde21″ . . . → Read More: crmコマンドを用いたPacemaker のリソース設定方法

Pacemaker-1.0 インストール方法 CentOS 5編

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

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

yum を使ってネットワークインストール

Pacemaker本家(clusterlabs) の yumのリポジトリを使用

インターネット接続必須
最新の安定バージョンをいち早く使ってみたい人向け (?)

Linux-HA Japan 提供のローカルリポジトリ . . . → Read More: Pacemaker-1.0 インストール方法 CentOS 5編

Matahari Project の現状について

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

2012年9月3日にMatahari Projectから悲しいお知らせが(TДT)

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

JPUG 第24回しくみ+アプリケーション勉強会 セミナー資料公開

2012/9/29 開催の第24回PostgreSQLのしくみ分科会、アプリケーション分科会への参加ありがとうございました。
当日の発表資料、”HAクラスタでPostgreSQLを高可用化(後編) 〜レプリケーション編〜”を公開します。

PostgreSQLを高可用化(後編) 〜レプリケーション編〜(PDF)

発表内容転記 : 『オープンソースのHAクラスタソフトPacemakerに、PostgreSQLのストリーミングレプリケーション構成をクラスタリングする機能がマージされました。この新機能の概要、および動作について解説いたします。』

前編の資料はこちらです。

 

English version . . . → Read More: JPUG 第24回しくみ+アプリケーション勉強会 セミナー資料公開

別冊あんどりゅーくん(第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 / 612345...Last »