はじめに

Pacemakerというと、心臓ペースメーカーやマラソンペースメーカー、某DJガジェットという印象があるかもしれませんが、それだけではありません！

この連載ではオープンソースで作られているHAクラスタソフト「Pacemaker」を概要から構築、保守運用にいたるまでLinux-HA Japanのプロジェクトメンバーで紹介します。HAクラスタは敷居が高いと考える人は多いでしょうが、この連載で身近なソフトウェアと思っていただければ幸いです。記念すべき連載第1回目では、Pacemakerの概要、歴史を紹介します。

HAクラスタって？

まずクラスタとは何か説明しましょう。クラスタとはもともと果実や花の房という意味で、同じようにまとまっているものの事を言います。

複数のコンピュータをつなげ、全体で1つのコンピュータのように振る舞わせる技術で、大きく分けて信頼性向上を目的とした「高可用性（High Availability⁠）⁠」⁠、計算速度向上を目的とした「HPC（High Performance Computing⁠）⁠」⁠、処理の負荷分散を目的とした「ロードバランシング（Load Balancing⁠）⁠」の3種類ありますが、Pacemakerは高可用性クラスタ（HAクラスタ）のソフトになります。

そのHAクラスタソフトであるPacemakerは、故障を検知した場合、待機系へサービスを引き継がせること（フェイルオーバ）によってサービスのダウンタイムを最小限にする事が可能です。基本構成は運用系と待機系で構成する1＋1構成ですが、複数台（N）の運用系ノードに対し待機系ノードも複数台（M）にするN＋M構成を構築する事も可能です。

Pacemakerの基本機能って？

Pacemakerの2大基本機能を紹介しましょう。

クラスタ制御機能

「クラスタ状態を伝播する通信」「⁠クラスタへのノード参加判断」「⁠クラスタノード間における情報の同期」「⁠一定間隔で相手ノードと通信し生死を確認」などを行うのがクラスタ制御機能になります。生死確認の通信はインターコネクト通信（ハートビート通信）といいますが、これが途絶えたときは相手が故障したと判断し、フェイルオーバ処理を実施します。

いわばクラスタ制御機能とは、ノード間の通信・管理およびPacemaker全体処理に関連するHAクラスタの下回りのお仕事をする土台機能になります。

リソース制御機能

一定間隔でリソースを監視し、正常動作していないと判断した場合にリソースのフェイルオーバ処理を行うのがリソース制御機能になります。

前述したクラスタ制御機能という土台の上でリソース制御機能は動作します。

って、「⁠リソース」とは何よ？ と疑問に思う人がいるかと思うので、遅ればせながら簡単に説明しましょう。ここでのリソースとは、Pacemakerが制御対象とするアプリケーション、ネットワーク、ディスク等を示します。

たとえばPostgreSQLによるDBサーバのHAクラスタシステムを構築する場合には、PostgreSQLは「リソース」となります。Pacemakerは、PostgreSQLなどのリソースをリソースエージェントを介して起動（start⁠）⁠、停止（stop⁠）⁠、監視（monitor）を実行しリソース制御を行います。

って、「⁠リソースエージェント」というまたわかりにくい言葉が出てきましたね。リソースエージェントとは、リソースとPacemakerを仲介するプログラムで、主にシェルスクリプトで作成されています。

PostgreSQLの例で、リソースエージェントの監視（monitor）の概要を説明しましょう。リソースエージェントはPacemaker本体から“⁠monitor⁠”という命令を受けます。その命令からPostgreSQL本体に対し⁠”select now()⁠”のSQL文を実行し成功するかどうかでリソースの動作を監視しているのです。

リソースエージェントは自作も可能ですが、Web系、DB系、ネットワーク系、ファイルシステム系等多数のリソースエージェントがPacemakerには標準で用意され、様々な監視方法が実装されています。よくアプリケーションの監視スクリプトをゴリゴリ自作したという話を聞きますが、Pacemakerを使用すればそんな苦労をする必要はありません。

Pacemakerってどうやって生まれてきたの？

ここでPacemakerの歴史を紹介しましょう。

Pacemakerは、同じくオープンソースであるHeartbeatの後継ソフトウェアです。1999年に最初のHeartbeatがリリースされ、Heartbeatバージョン1.0は2003年にリリースされました。この時点では、相手ノードを監視するなどのクラスタ制御機能しかありませんでしたが、リソース制御機能をもったHeartbeatバージョン2が2005年にリリースされたのです。

このままバージョン3が開発されるのかと思いきや、Heartbeatのリソース制御機能（CRM：Cluster Resource Manager）のメンテナであった Andrew Beekhof（アンドリュー・ビーコフ）氏は、2007年にリソース監視機能を「Pacemaker」という新プロダクトとしてHeartbeatから独立させることを宣言しました。そして2008年にPacemakerバージョン1.0がリリースされたのです。

これってコミュニティの喧嘩別れ？と後ろ向きに思ってしまうかもしれませんが、そうではありません。コンポーネントの共通化を行い、このリソース制御機能を他のクラスタ制御機能のソフトウェアでも利用できるように選択肢を増やそうという前向きな考え方なのです！

"Heartbeat"が心拍・鼓動を意味する言葉に対し、この新プロダクトを脈拍調整器の意味である"Pacemaker"とネーミングしたのは、センスとしてまずまずですね。

そのPacemakerですが、前述のとおりリソース制御機能のみなので、単独ではHAクラスタとして動作しません。他のクラスタ制御機能を持つソフトウェアと組み合わせる必要があり、現在は選択肢が2つあります。

1つは、Heartbeatバージョン2からリソース制御機能が削られたHeartbeatバージョン3です。面白いことにバージョン3と番号は上がったのに単独機能は縮小してしまいましたが、クラスタ制御機能としてこれからもメンテナンスされていきます。

もう1つは、OpenAISコミュニティで開発されているCorosyncです。Pacemaker はこの「Heartbeatバージョン3」と「Corosync」のクラスタ制御機能が選択可能です。

Pacemakerはこのように単独で動作させるのではなく、複数のコンポーネントの組み合わせとして提供されるため、プロダクト名は「Pacemaker ぷらす……」って呼ぶの？という疑問が起こるかもしれません。これについては、プロモーション的にもなんて呼ぶことにするか相当悩まされました。

悩みに悩んだあげく、「⁠Pacemaker+Heartbeatバージョン3」も「Pacemaker+Corosync」もLinux-HA Japanプロジェクトでは、「⁠Pacemaker」と呼ぶことにしています。「⁠Heartbeat⁠」⁠→「⁠Heartbeatバージョン2⁠」⁠→「⁠Pacemaker」と進化したと考えてください。

Linux-HA Japanプロジェクトって？

第1回目の連載最後として、Linux-HA Japanプロジェクトを紹介します。

Linux-HA Japanプロジェクトは、Pacemakerの前身であるHeartbeatの日本における更なる普及展開を目的として、2007年に「Linux-HA（Heartbeat）日本語サイト」の設立からコミュニティ活動が旗揚げされました。Pacemaker移行にあたり、プロジェクトではPacemaker情報の公開用として新しいウェブサイトを2010年にオープンし、勉強会、イベント情報など随時サイトを更新しています。

Linux-HA Japanプロジェクト

URL：http://linux-ha.sourceforge.jp/

メーリングリストではPacemaker、Heartbeatバージョン3、Corosync、DRBDなど、HAクラスタに関連する話題は何でも歓迎です。マニアックなクラスタ構成をしてみた話などぜひぜひ投稿してほしいですね！

ということで、Pacemakerの概要と歴史を紹介しましたが、いかがでしたでしょうか？次回は、実際にPacemakerのインストールといくつかの設定を行い、その手順を解説する構築基本編を紹介したいと思います。