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


  1. 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を採用しており、ビルド時の前提条件にも追加されるようです。 参考情報


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

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

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

  1. Support for advanced fencing topologies: eg. kdump   (network && disk)   power

fencing-topology という設定が追加されています。

High: Fencing: Implement support for advanced fencing topologies: eg. kdump || (network && disk) || power
High: fencing: Add the fencing topology section to the 1.1 configuration schema

リリースノートとChangesetの文面をみた感じだと、kdump、ネットワーク系STONITHとディスク系SOTNITH、電源系STONITH を複数組み合わせて設定できそうですね。 OR条件で設定したSTONITHのどれかは必ず成功させてみる!といった感じなんでしょうか。

Pacemaker 1.0系ではSTONITHにpriorityを設定して 1番目のSTONITHが失敗したら、2番目のSTONITHに挑戦、 2番目のSTONITHも失敗したら、3番目のSTONITHに挑戦 といった風に複数のSTONITHを順番に呼び出すことができたのですが Pacemaker 1.1ではpriorityの設定ができなくなっていました。 fencing-topologyはそれにかわるものなのか!? こちらも実際に動作を確認して、別冊あんどりゅーくんでご報告したいと思います。

新しく追加されたスキーマを見てみると、indexに順番が指定できそうな予感。


# vim xml/fencing.rng

<?xml version="1.0" encoding="utf-8"?>
<grammar xmlns="http://relaxng.org/ns/structure/1.0"
         datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
  <start>
      <ref name="element-stonith"/>
  </start>
  <define name="element-stonith">
    <element name="fencing-topology">
      <zeroOrMore>
        <ref name="element-level"/>
      </zeroOrMore>
    </element>
  </define>
  <define name="element-level">
    <element name="fencing-level">
      <attribute name="id"><data type="ID"/></attribute>
      <attribute name="target"><text/></attribute>
      <attribute name="index"><data type="positiveInteger"/></attribute>
      <attribute name="devices">
        <data type="string">
          <param name="pattern">([a-zA-Z0-9_.-]+)(,[a-zA-Z0-9_.-]+)*</param>
        </data>
      </attribute>
    </element>
  </define>
</grammar>

  1. Resource templates and tickets have been promoted to the stable schema
  2. Support for gracefully giving up resources depending on a ticket

この二項目はちょっとまとめちゃいます。 マルチサイトクラスタで使用する「チケット」の設定が導入されました。

High: PE: Support to make tickets standby for relinquishing tickets gracefully
High: Tools: crm_mon - Support to display tickets (based on Yuusuke Iida's work)
High: Tools: crm_simulate - Support to grant/revoke/standby/activate tickets from the new ticket state section

マルチサイトクラスタとは、通常のクラスタ、例えばActive/Standby構成の二台のノードを含むクラスタが遠隔地(サイト)に複数設置されている環境のことです。 クラスタ内のノードはPacemakerで管理することができますが、遠隔地に設置されたサイト間は、クラスタチケットマネージャ、「booth」が管理します。 boothは「チケット」と呼ばれる属性をサイトに発行します。 チケットを持っているサイトだけがサービスを起動することができるので、遠隔地間でサービスが二重起動しないように制御することができます。 なお、自動切り替えのためには3サイト以上必要です。 2サイトの場合は手動での切り替えとなります。

また、crm_monコマンドでチケットの情報が表示されるようになっています。 crm_simulateコマンドもチケットに対応したようです。

booth のソースコードはこちらからダウンロードできます。


  1. その他
As per our release calendar, the next 1.1 release is planned for mid-July.
今後の計画としては、Pacemaker 1.1.8 を7月中旬にリリースする予定です。
Packages for all current editions of Fedora have been built and will be appearing shortly in the update channels.
Other distributions will follow when their schedules allow it.
Fedora用のRPMパッケージはまもなく開発用のリポジトリからダウンロードすることができるようになるはずです。
その他のディストリビューションに関しては、それぞれのリリーススケジュールに従って配布されます。
The source tarball (tar.gz) is also available directly from GitHub.
ソースコードのtarボールはGitHubからダウンロードすることができます。
General installation instructions are available at from the ClusterLabs wiki.
インストール手順などはClusterLabsのWikiページを参照してください。