Pacemaker でらくらく簡易クラスタ-1
お久しぶりです。ニックネーム たいちょう です。
暑い夏が続きますが、いかがお過ごしですか？
熱はサーバにとって大敵です。私も、暑さのためにマシンが壊れてしまった経験があります。部屋そのものが停電してしまって、それに気づかず、職場に来てみたら蒸し風呂のようになっていた経験も。そんなときは、外気を利用して冷やしたりしました。窓を開けたんです。その時はもちろん1台マシンが壊れました。あまり思い出したくないので、この辺で。。
さて、このように、マシンというのは脆弱です。私の経験は極端ですけど、熱に限らずその他の要因でマシンが立ち上がらなくなることも多々あります。とにかく、大切なデータを守りながらサービスを続ける必要があるでしょう。可用性に関する数学的理論や概念およびその計算方法は教科書に譲るとして、実際のサーバ管理者の立場に立って現実と向き合ってみたいと思います。
ということで、このセッションは、クラスタとその実践についてのお話です。
クラスタにも色々あるようですけど、ここでは、オープンソースのクラスタである、Pacemaker についてご紹介します。
ちなみに、当社では、NEC社の CLUSTERPRO を再販しています。このセッションに興味を持たれたら、是非、当社にご相談下さい。私がサポートしますので。
このセッションは、以下のインターネット上の記事を参考に進めます、というか、ほとんどがその翻訳です。この記事を翻訳することは、原作者の許可をとっています。また、このセッションは、原作と同様のライセンスとします。
翻訳は私1人が行っておりとりあえず推敲していないですし、誤りがあるかもしれません。また、翻訳しないところも一部あります（「xx、省略」と記述します）。また、途中で私の感想が入っていることがあるので、注意してください。その時は、区切りを入れる等わかるようにします。
また、このセッションの中で実際にCentOS7.1相当で Pacemakerを動かしていきますが、実際に私が実行した結果を添付しますので、原作とは異なることも予想されます。また、実際の運用でも使用できるように、SELinuxを有効にして動かす等、努めてセキュリティにも考慮していきたいと考えています。
では、
http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/index.html
の、1.3 までを第1日目として書いていきます。
作者は、Andrew Beekhof さんです。
この資料の日本語の翻訳はありません。今回、日本語への翻訳とBLOGでの投稿への許可を求めたところ、"Of course." と一言で快く承諾していただきました。ありがとうございます。
また、日本のグループに連絡をとってごらん、と言われました。合わせて、こちら（ http://linux-ha.osdn.jp/wp/ ）も参考にすると、理解が深まると思います。
オープンソースのクラスタソフトウェア Pacemakerについて
http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/ch01.html
1.1. この文書が取り扱う範囲について
コンピュータ・クラスタは、高可用性サービスやリソースを提供するために用いられる。複数のマシンの冗長性は、あらゆる種類の不具合から守るために用いられる。
この文書は、簡易クラスターについて、インストール及びセットアップを CentOS7.1 上でやってみる。
ここでのクラスタは、リソース管理とメッセージングを提供するために、Pacemaker と Corosync を活用する。
クラスタを制御するために必要なパッケージとその設定の変更方法は、使用される XMLを生成するための Pacemakerのコマンドラインツールとともに記述される。
Pacemaker は、これらのシステムにおいて中心的なコンポーネントであり、必要となるリソース管理を提供するものである。
この管理は、それの管理下にある、あらゆるノード、リソースおよびサービスの不具合からの修復の検出を含んでいる。
実際の運用に必要となるもっと深い情報については、Pacemakerの説明マニュアルを読んでもらいたい。
http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/_what_is_emphasis_pacemaker_emphasis.html
1.2. Pacemaker ってなに?
Pacemakerは、クラスタ・リソース・マネージャである、というのは、ソフトウェアの運用ライフサイクル（直接繋がってはいないがおそらくシステムの全体あるいはその相互接続）に責任を持ち、ノードとして知られるいくつかのコンピュータの塊をその管理下に置き、それらをあらかじめ決められた規則により動かすロジックである、ということである。
これは、Corosync や Heartbeat のどちらかあなたの好むクラスタのインフラストラクチャにより、メッセージングとメンバーシップのケーパビリティを提供することによるノードおよびリソース・レベルの不具合の検出と復旧、そしておそらく全クラスタ・スタックのその他の部分を有効活用することによっても、クラスタ・サービス（リソースとして知られるが、）に最大限の可用性を実現する。
（Note 省略）
Pacemakerの主要な特徴は以下を含む:
- ノードおよびサービス・レベルの不具合の検出と復旧
- ストレージに依存しない（共有ストレージが不要）
- リソースに依存しない（スクリプト化できるものなら何でもクラスタ化可能）
- データの完全性のためにフェンシングをサポートする（STONITH という略語をもつ。これについては後に記述する）
- 大小のクラスタをサポート
- quorate とリソース・ドリブンなクラスタをサポート
- 冗長性のある設定を実質的にサポート
- どのノードからでも変更できる、設定の自動レプリケート機能
- コロケーションと非コロケーションである、クラスタ全般にわたるサービスの受付を特定できる機能
- 上級のサービス種別をサポート
- クローン：複数のノードにおいてアクティブである必要があるサービス
- マルチステート：多数のノードによるサービス（例として、マスター/スレーブ、プライマリ/セカンダリ）
- 統一された、スクリプト化可能な管理ツール集
http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/_pacemaker_architecture.html
1.3. Pacemaker のアーキテクチャ
もっとも上のレベルにおいては、クラスタはこれら3つのピースからなっている。
非クラスタ的なコンポーネント
これらのピースは、リソース自身と、スタート・ストップおよびモニターを実行するスクリプト、そして、これらスクリプトが内包する異なる基準の差をマスクするローカル・デーモン、を含む。（以下、このパラグラフ省略）
リソース・マネージメント
Pacemaker はプロセスを起動し、クラスタに関するイベントに反応するための頭脳を提供する。これらのイベントは以下の事を含む。ノードのクラスタへの加入と離脱、不具合によって引き起こされるリソース・イベント、メンテナンスと計画された活動、そしてその他の管理者の行為、であり、この行為は、リソースの移動、ノードの停止とリモート・パワー・スイッチによる強制的オフライン化も含むだろう。
低レベルなインフラストラクチャ
Corosync、CMAN および Heartbeat はクラスタに関する、信頼できるメッセージング、メンバーシップおよび quorum インフォメーションを提供する。
Corosync と結びついた時、Pacemaker は人気のあるクラスターファイルシステムをサポートもする。
過去のクラスタ・ファイルシステム・コミュニティの標準化により、クラスタ・ファイルシステムは、そのメッセージングおよびメンバーシップのケーパビリティ（ノードのup/down）に Corosync を、そしてフェンシングに Pacemaker を利用するようになった。
図 1.1. Pacemaker スタック
1.3.1. 内部コンポーネント
ペースメーカーそれ自体は 5つの主要コンポーネントからなっている。
- クラスタ・インフォメーション・ベース Cluster Information Base(CIB)
- クラスタ・リソース・マネジメント・デーモン Cluster Resource Management daemon (CRMd)
- ローカル・リソース・マネジメント・デーモン Local Resource Management daemon (LRMd)
- ポリシ・エンジン Policy Engine (PEngine or PE)
- フェンシング・デーモン Fencing daemon (STONITHd)
Pacemaker クラスタのサブシステム
図 1.2. 内部コンポーネント
クラスタ・インフォメーション・ベース(CIB)は、クラスタ設定とクラスタ中の全てのリソースの現在の状態を表現するために XML を使用する。CIB の内容は、自動的に全てのクラスタに伝搬し同期して、理想的な状態の計算とその実現のためにポリシ・エンジン(PEngine)によって使用される。
この命令のリストは Designated Controller (DC) に与えられる。Pacemaker はクラスタ・リソース・マネジメント・デーモン(CRMd)インスタンスのひとつからマスターとして動作するインスタンスを選ぶことにより、全てのクラスタの決断を取り仕切る。万が一選ばれたクラスタ・リソース・マネジメント・デーモン(CRMd)に不具合が生じると、新しいクラスタ・リソース・マネジメント・デーモンが速やかに確立される。
DC(Designated Controller)は、ポリシ・エンジン(PEngine)の命令を、ローカル・リソース・マネジメント・デーモン(LRMd)経由で、あるいは、クラスタ・メッセージング・インフラストラクチャを通じて他のノードのクラスタ・リソース・マネジメント・デーモン(CRMd)に（そしてそれは彼らのローカル・リソース・マネジメント・デーモン(LRMd)のプロセスに伝達されるのであるが）、必要な順番どおりに実行する。
ピアノードは、彼等の全てのオペレーションの結果を DC(Designated Controller)に報告し、期待される実際の結果にもとづき、それまでのノードが完了するのを待つのに必要なアクションを実行するかまたは、プロセスを破棄して期待しない結果に基く理想的なクラスタの状態をポリシ・エンジン(PEngine)に再計算することを依頼する。
ある場合においては、共有データを守るためあるいはリソースの復旧を完了するために、ノードをパワーオフすることが必要である。これについては、Pacemaker は フェンシング・デーモン(STONITHd)と手を携える。
注：
STONITH は、Shoot-The-Other-Node-In-The-Head の略語であり、動作に誤りがあるノードが直ちに遮られる(共有リソースから閉じられるまたは切り離される、そうでなければ固定化される)という推奨される動作であり、通常リモート・パワー・スイッチにより実行される。
（以下、このパラグラフ省略）
==========
どうですか？なんだか専門用語がいっぱい出てきましたね。
最初は概念の説明が続きますけど、我慢していきましょう。
これも、高可用性のためです。
実際に動かしてみると面白いはずなので。
それでは、今日はこの辺で。第1日目の終了です。
次回をお楽しみに。ニックネーム たいちょう でした。
