Pacemakerを使いこなそう

Pacemakerを使いこなそう！
～HAクラスタで止まらないサービスを～

2010年9月10日 OSC2010 Tokyo/Fall

Linux-HA Japan プロジェクト
松尾隆利

本日の話
①
②
③
④
⑤
⑥

HAクラスタとPacemaker
スプリットブレイン
クォーラム
STONITH
仮想化(Xen) + STONITH
Linux-HA Japanプロジェクトについて

Linux-HA Japan project

①HAクラスタとPacemaker
(クラスタにはいろいろな意味があるのでまずは誤解がないように)


コンピュータの世界で

クラスタというと
複数のコンピュータを結合し、
果実・花などの房のように
果実・花などの房のように
ひとまとまりとしたシステムのこと
(Wikipediaより)
(Wikipediaより)

HAクラスタ
HPC並列クラスタ
負荷分散クラスタ

・・・・


HAクラスタ
HAクラスタというと
クラスタ
HA = High Availability = 高可用性
つまり
一台のコンピュータでは得られない
一台のコンピュータでは得られない
高い信頼性を狙うために、
高い信頼性を狙うために、


もちろん
は
このHAクラスタ
という部類のソフトウェアで、
実績のある「Heartbeat」と呼ばれてい
「Heartbeat」
たHAクラスタの後継ソフトウェアです

HAクラスタ基本構成例 (1+1構成)
Activeサーバでサービスを提供し、Activeサーバ
が故障した場合は、Standby側のサーバに
サービスを引き継ぐ(フェイルオーバ)させることに
よって高い信頼性を狙う
ユーザ

Active

ユーザ

Active

Standby

故障
故障発生

フェイル
オーバ

サービスを引き継ぐ為に、Pacemakerが起動・停止・監視する
ものを「リソース」と呼び、リソースを制御するプログラムをRA
(リソースエージェント)と呼びます。
Activeノード

起動・停止・監視

リソース例

Apache
PostgreSQL
192.168.
a1ffc44503288

DRBD
IPアドレス
アドレス
データ

RA (リソースエージェント)

Pacemaker

ここまで簡単にHAクラスタについて説明しましたが・・・

・Pacemkaerのインストール方法は？
・Pacemakerの基本的な設定方法は？
・そもそもHAクラスタってよくわからない
という疑問をもってしまった方に朗報
明日 9/11(土) OSC 2010 Tokyo/Fall
「挑戦！Pacemakerで自由自在にHAクラスタリング」
by Linux-HA Japan プロジェクト


HAクラスタの命綱 – インタコネクト
Pacemakerはインタコネクトと呼ばれる通信路を使用してお互いの死
活確認や情報交換を行っています。
この時、どれか一台のサーバが命令の指揮を統括しています。
これを DC(Designated Controller) と呼びます。
DC

Active

生きてる？

元気だよ

Standby

インタコネクト

サービス起動して

OK

※「インタコネクト」は
「クラスタインタコネクト」や、「ハートビート」などとも呼ばれます

インタコネクトの切断
全てのインタコネクトが切れてしまって、お互いの状況が
わからなくなることを、スプリットブレイン
スプリットブレインと呼びます。
この時各々のサーバがDCになり、各々が勝手に動き始
めます
Active

生きてる？

しーん

切断
切断

サービス起動しまーす

サービス起動しまーす

Standby

スプリットブレイン時の表示例

「pm1」

「pm2」

pacmekaerの状態確認コマンドである、crm_mon コマンドにて
確認することができます
============
サーバ
Last updated: Mon Aug 23 11:32:55 2010
Stack: Heartbeat
Current DC: pm1 (0c140f90-7de3-438f-b1b5-3b9722bbde21) - partition WITHOUT quorum
Version: 1.0.9-89bd754939df5150de7cd76835f98fe90851b677
2 Nodes configured, 2 expected votes
1 Resources configured.
============
Online: [ pm1 ]
OFFLINE: [ pm2 ]

← pm2 が停止していると判断

============
サーバ
Last updated: Mon Aug 23 11:32:33 2010
Stack: Heartbeat
Current DC: pm2 (62b25071-2d16-4e9e-a323-af21616d5269) - partition WITHOUT quorum
============
Online: [ pm2 ]
OFFLINE: [ pm1 ]

pm1上の表示

← pm1 が停止していると判断

pm2上の表示

両サーバが勝手に動き始めると
(例えば) データを共有していると → データ破壊発生
IPを共有していると
→ IP競合発生
IP競合発生
IP : 192.168.0.10

ネットワークスイッチ

IP : 192.168.0.10

「スプリットブレインシンドローム」
スプリットブレインシンドローム」
切断
ネットワークパーティション問題」
「ネットワークパーティション問題」
などと呼ぶ
切断
出来る限り回避するため、インターコネクトは本以上用意
出来る限り回避するため、インターコネクトは2本以上用意
回避するため、インターコネクトは
mount
mount
共有ディスク

ダブルマウント

スプリットブレインに遭遇した場合に
重要な概念として、

クォーラム
があります

②クォーラム


クォーラム(quorum)とは
日本語訳では

〔議決に必要な〕定足数 by アルク
(製品によっては考え方が少し異なりますが)
Pacemakerでは簡単に言ってしまうと

過半数と通信できるサーバが
HAクラスタとして動作できる権利
クラスタとして動作できる権利


例えば3台構成の場合
3台のサーバの過半数=2台なので、
2台と通信できるサーバがクォーラムを獲得でき
※紙面の都合上インタコネクトを
クラスタとして動作する。パーティションと呼ぶ
上部に一本で表現します

切断
1：2

× クォーラムなし
クラスタとしては動作できない

クォーラム獲得

コマンドによるクォーラムの確認
crm_mon コマンドで確認可能
============
Last updated: Wed Aug 25 10:21:58 2010
Stack: openais
Current DC: pm1 - partition with quorum
============
～省略～

×

============
クォーラムなし
Last updated: Wed Aug 25 10:21:58 2010
Stack: openais
Current DC: pm3 - partition WITHOUT quorum
============
～省略～

２台の場合
どうなるの？


2台の場合
2台の過半数 => 2 > 1

スプリットブレイン時に誰もクォーラムを獲得できない
＝誰もクラスタとして動作できない
?

?

× クォーラムなし ×クォーラムなし

Pacemakerでの選択肢
クォーラムなしの場合の動作を決定するオプション
no-quorum-policy
を使用し、
以下のパラメータを選択可能

① ignore ・・・無視する
② freeze ・・・何もしない
③ stop ・・・停止する (default)

オプション説明の前提条件
以下のActive-Standby 構成で
スプリットブレインが発生したとする
Standby

Active

A

A

サービスA提供中

サービスA待機中

クォーラムのオプション①ignore
クォーラムなしの状態を無視する
= クォーラム獲得として動作する

A

A

クォーラム獲得で
サービス継続


クォーラム獲得で
サービス起動

クォーラムのオプション②freeze
クォーラムなしになったら
何も行動をおこさない

A

×

A

動いているサービス
は動き続け

×


止まっているサービス
は止まり続ける

クォーラムのオプション③stop
クォーラムなしになったら
動いているサービスを停止させる

A

×

サービス停止

A

×


止まっているサービス
は止まり続ける

クォーラムのオプションまとめ (2台)
A
A
スプリットブレイン時にサービスを継続させたいならば、
前提
ignore か freeze を選択 ?
サービスA提供中
サービス停止(A待機中)

ignore
A

freeze
A

A

×
stop

×

×


×

freezeは、2代構成のスプリットブレイン時は安全だが、
サーバ異常停止時も
クォーラムが獲得できません。
そのため本来の目的である
フェイルオーバできない
異常停止

サービス停止のまま

×クォーラムなし
※STOPも同様の理由でフェイルオーバできない

よって2台構成では
no-quorum-policy

= ignore

必須です


3台の場合のクォーラムのオプション 1:2
A

前提

B

A B

サービスA提供中サービスB提供中サービス停止(AorBの待機中)

ignore
A

freeze
B

A B

A
×

stop

B

A B

×

B

A B

3台の場合のクォーラムのオプション 1:1:1
A

前提

B

A B


ignore
A

B

freeze

A B

A

B

×

×

stop
×

×

×

×

3台以上では
サービス継続を考えるなら
ignoreまたはfreezeがよさそう (?)


Linux-HA Japanでは
Pacemaker + Corosyncも
Pacemaker + Heartbeatも

「Pacemaker」と呼ぶ
」

※注意
2010年9月現在

リソース
制御部
[ Pacemaker ]
クラスタ
制御部
[ Corosync ]
or
[ Heartbeat3 ]

Pacemakerでは、クラスタ制御部に
Corosync か Heartbeat3 を選択できます
が、Heartbeat3 ではサーバダウン検知の
タイミングに不具合があり、クォーラムは
実質 ignore しか正常に動作しません。


クォーラムのオプション設定方法例
# crm configure
← 設定用インタフェース(crm)に入る
crm(live)configure# property $id="cib-bootstrap-options" ¥
no-quorum-policy=“ ignore“
crm(live)configure#

show

← 設定確認

node $id="0c140f90-7de3-438f-b1b5-3b9722bbde21" pm1
node $id="62b25071-2d16-4e9e-a323-af21616d5269" pm2
～省略～
property $id="cib-bootstrap-options" ¥
expected-quorum-votes="2" ¥
no-quorum-policy="ignore" ¥
dc-version="1.0.9-89bd754939df5150de7cd76835f98fe90851b677" ¥
cluster-infrastructure="Heartbeat" ¥
～省略～

crm(live)configure#

commit

← 反映


あれ？
結局サービス二重起動発生するのでは？


③STONITH


STONITHとは
Shoot-The-Other-Node-In-The-Headの略で
サービス継続を邪魔するサーバや制御が
利かないサーバをHAクラスタから
「強制的に離脱」させる機能
フェンシング
製品によっては、
「強制停止機能」とか「シャットダウン機構」といった
名称で呼ばれている


フェンシング？
Pacemakerからサーバを強制停止させること
・サーバ搭載のHW制御ボードを操作
・リモート管理対応のUPSを操作
・リモートパワースイッチ(RPS)を操作
・poweroffコマンド実行
・人間がPacemakerを監視し手で電源を引っこ抜く (?)

実現方法やデバイスによって、
様々なSTONITH用プラグインが用意されている


使えるSTONITHプラグイン一覧の表示

# stonith -L
※プラグイン格納場所 [ /usr/lib64/stonith/plugins/ ]

(64bitの場合)

STONITHプラグインの説明の表示
(xmlで出力される)
# lrmadmin -M stonith プラグイン名 pacemaker


STONITH構成例
STONITH
STONITH

STONITH
STONITH

HW制御ボード
制御ボード
HW制御ボード
制御ボード
UPS 等
UPS 等

HW制御ボード
制御ボード
HW制御ボード
制御ボード
UPS 等
UPS 等

インターコネクトとは別の通信経路を使用する
サーバの電源と連動しないデバイスを使用

フェンシングの契機
・対向サーバの応答がない
・対向サーバがサービス停止を
失敗した場合
※自分がクォーラムを持っていることが前提


STONITH構成でのスプリットブレイン発生時(2台)
(no-quorum-policy=ignore)
相手が故障！

相手が故障！

切断

HW制御ボード
制御ボード
HW制御ボード
制御ボード
UPS 等
UPS 等

HW制御ボード
制御ボード
HW制御ボード
制御ボード
UPS 等
UPS 等


切断

フェン
シング

フェン
シング

HW制御ボード
制御ボード
HW制御ボード
制御ボード
UPS 等
UPS 等

HW制御ボード
制御ボード
HW制御ボード
制御ボード
UPS 等
UPS 等



You win !

HW制御ボード
制御ボード
HW制御ボード
制御ボード
UPS 等
UPS 等

HW制御ボード
制御ボード
HW制御ボード
制御ボード
UPS 等
UPS 等

電源リセット

タイミングによっては、相打ちの可能性あり
→ Linux-HA Japan 提供のstonith-helperで、
なんらかの条件を指定しフェンシングを遅らせることが可能

(no-quorum-policy=freeze)

HW制御ボード
制御ボード
HW制御ボード
制御ボード
UPS 等
UPS 等

HW制御ボード
制御ボード
HW制御ボード
制御ボード
UPS 等
UPS 等


HW制御ボード
制御ボード
HW制御ボード
制御ボード
UPS 等
UPS 等

切断

フェン
シング

HW制御ボード
制御ボード
HW制御ボード
制御ボード
UPS 等
UPS 等

× クォーラムなし(1台)

HW制御ボード
制御ボード
HW制御ボード
制御ボード
UPS 等
UPS 等

HW制御ボード
制御ボード
HW制御ボード
制御ボード
UPS 等
UPS 等

クォーラム獲得(2台)

切断

HW制御ボード
制御ボード
HW制御ボード
制御ボード
UPS 等
UPS 等

電源リセット

HW制御ボード
制御ボード
HW制御ボード
制御ボード
UPS 等
UPS 等

完了後

HW制御ボード
制御ボード
HW制御ボード
制御ボード
UPS 等
UPS 等

サービス起動

3台構成の場合のSTONITHとクォーラムの動作まとめ 1:2

A

前提

B

A B


ignore

※どちらかのパーティションが生き残る
最悪タイミングによっては相打ち
タイミングによっては相打ち

B

A B

freeze
B

または

A

stop

×
B

A

×

A

3台構成の場合のSTONITHとクォーラムの動作まとめ1:1:1

A

前提

B

A B


ignore

freeze
A

※どこかのパーティションが生き残る

stop
×

×

×

B

×

A

×

×

全体が偶数の台数で、
半分に分かれた場合は？
2台構成の場合と同様の考えで、
ignoreが有利だが、
台数が増えれば増える程きれいに二つに分か
れる確立は低くなるし、クォーラムにより、freeze
の方がサービスを救える確立が高くなる

よって3台以上の構成では、
no-quorum-policy

= freeze

+
STONITH
を推奨


STONITH機能有効化の方法
※デフォルト有効 (pacemaker 1.0.9)
# crm configure
← 設定用インタフェース(crm)に入る
crm(live)configure# property $id="cib-bootstrap-options" ¥
stonith-enabled=“true“
crm(live)configure# show
← 設定確認
node $id="0c140f90-7de3-438f-b1b5-3b9722bbde21" pm1
node $id="62b25071-2d16-4e9e-a323-af21616d5269" pm2
～省略～
property $id="cib-bootstrap-options" ¥
expected-quorum-votes="2" ¥
no-quorum-policy="ignore" ¥
stonith-enabled=“true" ¥
dc-version="1.0.9-89bd754939df5150de7cd76835f98fe90851b677" ¥
cluster-infrastructure="Heartbeat" ¥
～省略～

crm(live)configure#

commit

← 反映

STONITHプラグインの設定例
HP社のHW制御ボード iLO使用の場合
「pm1」

# crm configure
crm(live)configure# primitive Stonith1 stonith:external/riloe ¥
params ¥
プラグイン名
priority=“1" ¥
stonith-timeout="300s" ¥
hostlist=“pm1" ¥
HW制御ボードへ
ilo_hostname="192.168.105.1" ¥
ilo_user="heartbeat" ¥
ログインするための
ilo_password=“aaaabbbbcccc" ¥
設定
ilo_can_reset="1" ¥
ilo_protocol="1.2" ¥
ilo_powerdown_method="power" ¥
op start interval="0s" timeout="60s" ¥
op monitor interval="3600s" timeout="60s" ¥
op stop interval="0s" timeout="60s“
crm(live)configure# primitive Stonith2 stonith:external/riloe ¥
params ¥
プラグイン名
priority=“1" ¥
stonith-timeout="300s" ¥
hostlist=“pm2" ¥
HW制御ボードへ
ilo_hostname="192.168.105.2" ¥
ログインするための
ilo_user="heartbeat" ¥
ilo_password=" aaaabbbbcccc" ¥
設定
ilo_can_reset="1" ¥
ilo_protocol="1.2" ¥
ilo_powerdown_method="power" ¥
op start interval="0s" timeout="60s" ¥
op monitor interval="3600s" timeout="60s" ¥
op stop interval="0s" timeout="60s“
crm(live)configure# location rsc_location-Stonith1 Stonith1 ¥
rule -INFINITY: #uname eq pm1
crm(live)configure# location rsc_location-Stonith2 Stonith2 ¥
rule -INFINITY: #uname eq pm2
crm(live)configure# commit


STONITH
STONITH
プラグイン
プラグイン
[[ riloe ]]
riloe

STONITH
STONITH
プラグイン
プラグイン
[riloe]
[riloe]

HW制御
制御
HW制御
制御
ボード
ボード

HW制御
制御
HW制御
制御
ボード
ボード

192.168.105.1
192.168.105.1

192.168.105.2
192.168.105.2

pm1をフェンシングするための設定

pm2をフェンシングするための設定

pm1をフェンシングするSTONITHが
pm1上で動作しないようにする設定
pm2をフェンシングするSTONITHが
pm2上で動作しないようにする設定

「pm2」

⑤仮想化 + STONITH


Xenについて
Domain-0
(ホストOS)

Domain-U
(ゲストOS)

Domain-U
(ゲストOS)

Linux

Domain-0 (Dom0)
≒ ホストOS

停止
停止
停止
停止

起動
起動
起動
起動

Domain-U (DomU)
≒ ゲストOS

サーバ

Dom0上からDomUを
起動・停止することができる
# xm create DomU名
# xm destoroy DomU名

Xen上でのSTONITHの使用
Xen の DomU上だけでPacemakerを使用する場合は、
Xen0 プラグインを使用し、SSHでDom0にログインしDomUを停止させることが可能

Dom0 DomU
[ D0A ]

制御
不能

Dom0
[ D0B ]

[pm1]

DomU
[pm2]

フェン
シング

STONITH
プラグイン(Xen0)
プラグイン
プラグイン

SSH

pm1の動いているDom0 にsshログインし
pm1の動いているDom0 にsshログインし
##xm destroy pm1
xm destroy pm1
を実行することでフェンシング成功
を実行することでフェンシング成功

STONITH
プラグイン(Xen0)
プラグイン
プラグイン

[ 問題点 ]
1. Xen0 STONITH プラグインでは、
Dom0 にログインできる必要あり
2. Dom0 と DomU の関係は
固定であることが前提
→ Dom0上でDomUをクラスタリングしている場合に
使えない

STONITH 仮想化連携機能 (for Xen)
Dom0(ホストOS)上のPacemakerとDomU(ゲストOS)上のPacemakerが連携し
てSTONITHを処理する機能およびプラグイン
Dom0
[ D0A ]

DomU
[pm1]

Dom0
[ D0B ]

DomU
[pm2]

STONITH
STONITH
プラグイン
プラグイン

故障

[ D0C ]

STONITH
STONITH
プラグイン
プラグイン

[[ ノード名 :: pm2 ]]
ノード名 pm2
[[ リソース
リソースID
リソースID
リソース
:: id-pm2 ]]
id-pm2

Dom0

[[ ノード名 :: pm1 ]]
ノード名 pm1
[[ リソース
リソースID
リソースID
リソース
:: id-pm1 ]]
id-pm1

id-pm1 というIDで管理

id-pm2 というIDで管理

Dom0 上のPacemakerで管理しているリソースID を設定
Dom0 上のPacemakerで管理しているリソースID を設定

STONITH 仮想化連携機能 (for Xen)
フェイルオーバ
Dom0

Dom0

[ D0A ]

[ D0B ]

DomU
[pm2]

Dom0 DomU
[ D0C ]

[pm1]

制御
不能

STONITH
STONITH
プラグイン
プラグイン

故障

リソースID : :id-pm1 の
リソースID id-pm1 の
DomU を落として！！
DomU を落として！！

STONITH
STONITH
プラグイン
プラグイン

[[ ノード名 :: pm1 ]]
ノード名 pm1
[[ リソース
リソースID
リソースID
リソース
:: id-pm1 ]]
id-pm1

[[ ノード名 :: pm2 ]]
ノード名 pm2
[[ リソース
リソースID
リソースID
リソース
:: pm2rid ]]
pm2rid

Id-pm1というIDで管理

##xm destroy pm1
xm destroy pm1
を実行しフェンシング成功
を実行しフェンシング成功

STONITH 仮想化連携機能特徴
・Dom0とDomU 間の通信には、
Xenの機能である Xenstore を使用
・複数ユーザのDomUが乗り入れている場合、他の
ユーザがDomUを勝手にフェンシング
できないように、リソースIDの暗号化をサポート
・KVM 版も開発予定

Linux-HA-Japanプロジェクトより
Linux-HA-Japanプロジェクトより
来年度以降公開予定！！
来年度以降公開予定！！

⑥Linux-HA Japan
プロジェクトについて


Linux-HA Japan プロジェクトの経緯
『Heartbeat(ハートビート)』の日本における更なる
普及展開を目的として、2007年10月5日「Linux-HA
(Heartbeat) 日本語サイト」を設立しました。
その後、日本でのLinux-HAコミュニティ活動として、
Heartbeat-2.x のrpmバイナリと、Heartbeat機能追
加パッケージを提供しています。


Linux-HA JapanプロジェクトURL
http://linux-ha.sourceforge.jp/
(一般向け)
http://sourceforge.jp/projects/linux-ha/ (開発者向け)
Pacemaker関連情報の
公開用として SourceForge.jp に新しい
一般向けウェブサイトが 6/25にオープン
しました。随時情報を更新しています！
開発者向けサイトでは、
RHEL/CentOS用 Heartbeat-2.ｘ
rpmバイナリの提供や、機能追加パッケー
ジ類を、GPLライセンスにて公開しています。


Linux-HA Japanメーリングリスト
日本におけるHAクラスタについての活発な意見交換の場として
「Linux-HA Japan日本語メーリングリスト」も開設しています。
Linux-HA-Japan MLでは、Pacemaker、Heartbeat3、Corosync
DRBDなど、HAクラスタに関連する話題は全て歓迎します！

• ML登録用URL
http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan

• MLアドレス
linux-ha- apan@lis s.sourceforge.jp
linux-ha-japan@lists.sourceforge.jp
ource
.j

ぜひメーリングリストに登録して
HAクラスタの
活発な意見交換を
交わしましょう！


ご清聴ありがとうございました。

Linux-HA Japan

検索

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

Pacemakerを使いこなそう

More Related Content

What's hot

Similar to Pacemakerを使いこなそう

Pacemakerを使いこなそう