※ただのメモ PaceMaker,DRBDについて話をきけばわかる状況にしたい。

まずインストールイメージを確認

下記が無難そう。

ダウンロード&インストール « Linux-HA Japan

Pacemaker-1.1.17-1.1 リポジトリパッケージ « Linux-HA Japan

なぜかCentOS上での説明
なぜか１台
他のノードとの接続は頑張ってくださいという記載である。

Pacemaker-1.1.17-1.1 の概要
ダウンロード
インストール前の準備
インストール
設定例
5.1. corosync設定ファイルの設定
5.2. corosync認証鍵ファイルの設定
5.3. pacemaker設定ファイルの設定
5.4. クラスタ起動スクリプトの設定
起動・終了
?Upstart経由(RHEL 6の場合) または systemd経由(RHEL 7の場合)で起動する手順が推奨です。
?いったいどういうことか調査要
アンインストール
応用事例
あまりこの項目は意味がないように思われる。
8.1. 基本構成例
8.2. PG-REX
いきなり出てきている感が否めない。
Ansible Playbook 例
リリースノート
この区分いまいちわからない。

次に概要確認

Pacemakerの概要 « Linux-HA Japan

Pacemakerの機能と対応可能な故障

・アプリケーション監視・制御機能
・ネットワーク監視・制御機能
・ノード監視機能
・自己監視機能
・ディスク監視・制御機能

典型的なクラスタ構成

・データの引継ぎ方法による分類

シェアード構成
シェアード・ナッシング構成（PG-REX／DRBD利用）
共有ディスクは使用せず、ソフトウェアによるデータレプリケーション機能を使用し、データを引き継ぐ構成です。PacemakerではPostgreSQLのストリーミングレプリケーション機能によるPG-REX構成、および、DRBDを用いた構成に対応しています。高価な共有ディスクが不要なため、安価にシステムを構築できます。 →PaceMakerとDRBDのつながりはここで出てくる。
以後のPaceMakerの調査はノードの台数になる。

・ノード台数による分類
なんかよくわからん。 1+1構成
N+1構成
N+M構成

Pacemakerバージョンの選び方

リソース制御機能

Pacemaker 1.0系
Pacemaker 1.1系 (最新)
クラスタ制御機能

Heartbeat 3系
Corosync 1系
Corosync 2系(最新)

リソースとリソースエージェント

リソース :
PackMakerでは制御する対象のことをリソースと呼ぶ。
リソースエージェント(RA) :
各リソースの起動/監視/停止といった制御は、リソースエージェント(RA)と呼ばれるリソース専用モジュールを介して行われる。
専用モジュールを介することで、アプリケーション毎の制御方法の違いをラップし、PaceMakerで統一的に扱えるようにする。

Pacemakerには、Apache, PostgreSQL, Oracle, MySQL, Tomcat, 仮想IPアドレス, ファイルシステムなどなど、多くのリソースエージェントが初めから同梱されている。

リソースエージェントは多くはシェルスクリプトで作成されており、Open Cluster Framework(OCF)という仕様に従えば、独自のものを作成し、使用することもできる。
OCFでは、定義すべきメソッド(start/monitor等)、および、返すべき返り値等の規定がされています。メソッドや返り値等の規定に従っていれば、実装するプログラム言語を問わない。ただし、ディストリビューションに依存しないよう、例えばbashではなくshで記述するなどの配慮が必要である。
linux-ha.osdn.jp

スプリットブレイン、リソース監視停止と排他制御

下記が参考になる。セミナー資料：試して覚えるPacemaker入門排他制御機能編
http://linux-ha.osdn.jp/wp/wp-content/uploads/076783ca53a363270d253bbb98b59e83.pdf

二重マウントの危険性につなげたい

まずは障害発生時の対処方法のイメージを掴む。

障害が発生すると検知し、自動的にサービスをフェイルオーバすることでシステムの可用性を高める。
1.PaceMakerがリソースを監視している。
2.障害が発生すると、フェイルオーバしてノードを切り替える。

下記が発生した場合間違った動きをすることがある。
・スプリットブレイン
・リソースの停止故障

スプリットブレイン
・クラスタ間をつなぐインターコネクト通信が全て切断されてお互いの状態が把握できなくなったPaceMakerが、
それぞれのノードでリソースを起動し始めてしまう状態のこと。
・それぞれのノードで起動したリソースが二重で書き込みを行うことで、データが破壊されてしまいサービスが復旧不可能な状態になる。

リソースの停止故障
・リソースの停止故障ができないと、フェイルオーバができなくなる(Stanbyで側でリソースを起動することができなくなる)。

スプリットブレインとリソース停止故障の回避策排他制御機能が必要
対応方法として3つある
1.STONISH
2.SFEX
3.VIPcheck

1.STONITH
STONITHプラグインが標準で様々な装備されている
STONITHとは制御が利かなくなったノードの電源を強制的に停止してクラスタから強制的に離脱させる機能
以下の目的で色々なプラグインがある。
・フェンシング(電源断)制御　: KVMの場合libvirt
・サーバ生死確認、相打ち防止 :stonith-helper

1.1 STONITHの相打ち問題
スリットブレインになった時、お互いのノードをSTONITHを実行しあい「相撃ち」になる。
stonith-helperでStanby系のSTONITHを遅らせる。

上記資料の後半具体的な設定方法があり理解の架け橋になる。
STONITHの設定方法
・STONITH機能の有効化設定
・STONITHプラグインの設定
・STONITHプラグインの実行順序設定
・リソース停止故障時にSTONITHを発動させる設定

・リソース停止故障時にSTONITHを発動させる設定
設定箇所にon-failが登場
→stonishの機能だった。

PaceMakerを動かす具体的な設定

以下を読んでいけばいいと思う。
動かして理解するPacemaker ～CRM設定編～その１
動かして理解するPacemaker ～CRM設定編～その１ « Linux-HA Japan

前述のCRM設定ファイルは、Pacemakerがインストールされていて、同一LANに接続されているマシンが2台あればすぐに動作する。
仮想マシンでも可。

■CRM設定ファイルとは
上記より抜粋
CRM設定ファイルは、Pacemakerに、「どのようなリソース（※1）をどこで稼働させるか？」「いつフェイルオーバ(※2)するのか？」というようなことを記載する設定ファイル。
CRM設定ファイルはこのcrmコマンドに流し込むコマンドを列挙したもの。
ちなみにcrmコマンドは、設定のみならず、クラスタの状態確認、操作等、様々な機能を持っている。クラスタのシェルのようなもの。

■CRM設定ファイルの構成行の始めは以下の８種類のコマンドのどれかである。行頭が「#」はコメントアウト、「\」は行が続くことを表す。
・property
・rsc_defaults
・group
・clone
・primitive
・location
・colocation
・order
上記コマンドあれば、たいがいのHA構成は定義できるとのこと。

■CRM設定を動かす
手順1)
インストール
Pacemaker-1.0系の場合 Pacemaker-1.1系の場合手順2)
以前に設定したCRM設定ファイルの情報をクリア
Pacemaker-1.1系の場合
・# rm -f /var/lib/pacemaker/cib/*
手順3)
以下のコマンドをrootユーザで実行し、PaceMakerを起動
Pacemaker-1.1系,RHEL6の場合
・# initctl start pacemaker.combined
crm_mon -rfA コマンドで、正常に起動したことを確認。
手順4)
以下のコマンドをrootユーザで実行し、CRM設定ファイルをPaceMakerに反映する。
どちらのノードで実行しても構わない。
(例のCRM設定ファイルをexample01.crmという名前のファイルにコピペ・保存したと仮定。）

・# crm configure load update example01.crm
crm_mon -rfA コマンドで、CRM設定ファイルが正常に反映されたことを確認。
手順5)
停止する場合
Pacemaker-1.1系,RHEL6の場合
・# initctl stop pacemaker.combined

■CRM設定ファイルの内容を読む
■propertyとrsc_defaultsは全体の設定
resource-stickiness登場 !!
1. STONITHは無効。
→stonith-enabled=”false”のため。
2. 1回のリソース故障でF/Oする。自動フェイルバックはしない。
→migration-threshold=”1″およびresource-stickiness=”INFINITY”のため。

■実験
故障の実験
手順1)故障発生
Dummyリソースは/var/run/resource-agents/に空のファイルを作成し、それが存在するかどうかでリソースの稼働をmonitorしている。
手順2)F/O完了確認
上記ファイルを空にしただけでフェイルオーバされた！
手順3)migration-threshold変更
migration-threshold回に達するまではリソース故障はリソース再起動で対処されるため。

動かして理解するPacemaker ～CRM設定編～その２

動かして理解するPacemaker ～CRM設定編～その２ « Linux-HA Japan 例の設定ファイル
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)は起動しません。

■primitiveでリソースを定義
リソースIDおよびリソースエージェント(RA)を指定し、クラスタ内で使用するリソースを定義する。
primitive リソースID RA名
(リソースID)
リソースの名前を任意の英文字で定義。
(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/プラグイン名※　に配置されたプログラムを使用する。

・リソースエージェント(RA)の作り方
ソースへのリンクあり
linux-ha.osdn.jp

作成例
http://www.kurobuti.com/blog/?p=4667

■groupでリソースをひとまとめに
groupは、primitiveで定義した個々のリソースをグループ化する。
グループ化したリソースに対しては、以下の制御が行われる。
・常に同一サーバで起動する。
・groupコマンドに指定した順にリソースを起動する。またその逆順に停止する。
グループ化は、あるサービスを提供するのに、複数のリソースを同時に使用しなければならない場合に使用する。

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

ようやくPaceMakerの今までの諸々の暗号が解けた。

■実験1 グループにリソースを追加してみる
■実験２グループのうち１つを故障させてみる
■実験３ op要素のmonitorのintervalを0にし故障させてみる
op要素のmonitorの動きが見える。

linux-ha.osdn.jp
前に記載した6.7の解説
→まだ理解が追いつかない。とりあえず流す。

■スコア値の大きいノードでリソースは起動する

■locationで起動するノードを制約

■colocationで同居するリソースを制約

■orderで順序を制約

■実験1 colocationのスコア値を-INFINITYにしてみる

■実験2 orderのスコア値をINFINITYにしてみる

■実験3 属性値を評価する

PaceMakerのまとめ

PaceMakerをユーザとして取り組む土台はできたのではないだろうか。
いつの日かソースを理解していきたいがそれはまだ先かそこまで見る時間はないと思う。
あとDRBDはいっさい見れていない。
別に確認していく。

PaceMakerの運用

gihyo.jp
(crm_mon)
crm_monはPacemakerが制御しているリソース状態や，インターコネクトLAN，ネットワークの状態を確認できるツール。
Pacemakerが稼動しているサーバでcrm_monコマンドに -f と -A のオプションをつけて実行。
-fオプションは、リソースの故障状態の表示
-AオプションはインターコネクトLANの状態やネットワーク監視の状態？
→ネットワーク監視の状態って・・・

-1について下記に記載がある。
Novell Doc: High Availability ガイド - crm_mon (8)

そもそもcrm-monは、クラスタのステータスを監視する。

そもそもクラスタの意味は？
クラスタ構成とは | DRBD IT用語における「クラスタ構成」は、複数のサーバを連携させて利用者や他のサーバから、全体で1台のサーバであるかのように動作させる技術。

もし-1をつけないと、
クラスタのステータスを15秒ごとに更新済みのリストを表示する。
-1をつけると、
クラスタのステータスを一度だけコンソールに表示する。

(pm_logconv)

(crm-resource)
Novell Doc: High Availability ガイド - crm_resource (8)

crm-resource：クラスタリソースに関連するタスクを実行する。

クラスタリソースのマイグレーション
リソースは、ハードウェアまたはソフトウェアに障害が発生した時、クラスタ内の他のノードに自動的にフェールオーバ(移行)するように設定されている
PaceMakerGUIもしくはコマンドラインを使用して、手動でリソースをクラスタ内の別のノードに移動することができる。

crm resource
migrate ipaddress1 bob

間にーがない？