Linux-HA Japan

2020年10月23日(金)、24日(土)にオンラインにて開催されたオープンソースカンファレンス2020 Online/Fallにおいてセミナーで参加させていただきました。 たくさんの方にお越しいただきありがとうございました。当日のセミナー資料を以下で公開いたします。

セミナープログラム:

2020-10-23(金) . . . → Read More: OSC2020 Online/Fall セミナー資料公開

Pacemaker-1.0.13-1.1リポジトリパッケージ(2013/04/11リリース)を RHEL 5.9 以前またはそのRHELクローンOS(CentOS等)上で利用した場合、 IPaddr2 が誤動作しサービス停止になる可能性があります。

全てのユーザに影響があるわけではありませんが、 OSC 2013 Tokyo/Fall での展示ブースなどでも同様の報告を頂いているので、 . . . → Read More: Pacemaker-1.0.13-1.1 + RHEL5 における IPaddr2 の不具合について

みなさま。　新年あけましておめでとうございます。
本年もLinux-HA Japan Projectをよろしくお願いいたします。

さて、本来は昨年出るはずだと思われていた、Corosync-2.0もまだ出ず。
1,4,2のリリースからすでに半年経過OTL
Pacemakerも、今年は1.2のリリース予定が・・・・・。　さてどうなるでしょうか？

Pacemaker 1.1の現在のコミュニティによるサポート期限は2012年8月。
Pacemaker 1.0はもう少し長い予定というか、1.2が出ないとどうなることやらw
http://www.clusterlabs.org/wiki/FAQ

Linux-HA Japan的には、月刊あんどりゅー君でも書いている通り、
Pacemaker1.0系+Heartbeat3.0系がまだお勧めなんですが・・・・。

周辺でいろいろと新しいプロジェクトも動き始めている模様です。
引き続き、WorldWideのMLをウォッチしながら、日本のインフラに合った情報を中心に
共有などしていければと考えております。

なにか、不明な点、バグっぽいよ、みたいな話は、英語で書くのはちょっとと言うあなたも
是非、Linux-HA . . . → Read More: 本年もLinux-HA Japan Projectをよろしくお願いいたします。

10月22日(土)に開催されたqpstudy08に参加された皆様、大変お疲れ様でございました。
開始早々に試験問題を配布されるというその恐怖、心中お察しいたします。

試験問題および解答の公開から間が空いてしまったためかなりイマサラ感が漂ってますが
Linux-HA Japanから出題させていただいた問題の解説を掲載いたします。
問題と解答はこちら。
togetterはこちら。

では、早速…

(24) Pacemakerクラスタの説明で誤っているものはどれか

(あ) 複数リソースの起動停止順序を制御する場合はgroupを使用する。
(い) リソース間の依存関係を設定する場合はcolocationを使用する。
(う) cloneに設定されたリソースが起動停止するタイミングは故障発生時も全ノードで常に同時である。
(え) 初期起動時のリソースの配置先はlocationで指定する。
(お) リソースの起動順序を指定する場合はorderを使用する。

正解(う)

えーっと、しょっぱなからアレですが、これはなんともいえないイジワル問題で、まじすまんかった。
Pacemakerうんぬんよりも国語の問題でした。

というわけで、cloneの動作を簡単な例で確認してみましょう。
次の設定は2ノード構成のクラスタにcloneを配置しています。
各ノードで1つずつcloneが起動します。

clone.crm

property \
 no-quorum-policy="ignore" \
 stonith-enabled="false" \
 startup-fencing="false" \
 crmd-transition-delay="2s"

rsc_defaults \
 resource-stickiness="INFINITY" \
 migration-threshold="1"

clone clone01 \
 dummy01 \
 meta \
 clone-max="2" \
 clone-node-max="1"

primitive dummy01 ocf:pacemaker:Dummy \
 op start interval="0s" timeout="120s" on-fail="restart" \
 op monitor interval="10s" timeout="120s" on-fail="restart" \
 op stop interval="0s" timeout="120s" on-fail="block"

crm_monコマンドでリソースの起動状態を確認してみましょう。

# crm_mon -1
============
Last updated: Mon Nov  7 15:32:19 2011
Stack: Heartbeat
Current DC: node02 (22222222-2222-2222-2222-222222222222) - partition with quorum
Version: 1.0.11-1554a83db0d3c3e546cfd3aaff6af1184f79ee87
2 Nodes configured, unknown expected votes
1 Resources configured.
============

Online: [ node01 node02 ]

 Clone Set: clone01
 Started: [ node01 node02 ]

crm_monコマンドに-nオプションをつけてみます。
node01でdummy01:0、node02でdummy01:1が起動していることがわかりますね。

# crm_mon -1 -n
============
Last updated: Mon Nov  7 15:32:37 2011
Stack: Heartbeat
Current DC: node02 (22222222-2222-2222-2222-222222222222) - partition with quorum
Version: 1.0.11-1554a83db0d3c3e546cfd3aaff6af1184f79ee87
2 Nodes configured, unknown expected votes
1 Resources configured.
============

Node node01 (11111111-1111-1111-1111-111111111111): online
 dummy01:0       (ocf::pacemaker:Dummy) Started
Node node02 (22222222-2222-2222-2222-222222222222): online
 dummy01:1       (ocf::pacemaker:Dummy) Started

cloneは<リソース名>:(コロン)<インスタンス番号>で区別されます。
インスタンス番号はPacemakerが自動的に割り振ります。ユーザが指定することはできません。
インスタンス番号によって、動作が異なるようなことはありません。

DCノードでha-logを検索すると、次の順序でdummy01:1、dummy01:0が起動したことがわかります。
※ match_graph_event関数のログはDCノードにしか出力されません。

# grep -R match_graph_event /var/log/ha-log
Nov  7 15:32:15 node02 crmd: [15471]: info: match_graph_event: Action dummy01:1_monitor_0 (6) confirmed on node02 (rc=0)
Nov  7 15:32:16 node02 crmd: [15471]: info: match_graph_event: Action dummy01:0_monitor_0 (4) confirmed on node01 (rc=0)
Nov  7 15:32:16 node02 crmd: [15471]: info: match_graph_event: Action dummy01:1_start_0 (9) confirmed on node02 (rc=0)
Nov  7 15:32:16 node02 crmd: [15471]: info: match_graph_event: Action dummy01:1_monitor_10000 (10) confirmed on node02 (rc=0)
Nov  7 15:32:17 node02 crmd: [15471]: info: match_graph_event: Action dummy01:0_start_0 (7) confirmed on node01 (rc=0)
Nov  7 15:32:18 node02 crmd: [15471]: info: match_graph_event: Action dummy01:0_monitor_10000 (8) confirmed on node01 (rc=0)

node01のclone(dummy01:0)を故障させます。

# crm resource failcount dummy01:0 set node01 1

node01のclone(dummy01:0)が停止したことを確認します。

# crm_mon -1 -n -f
============
Last updated: Mon Nov  7 15:36:38 2011
Stack: Heartbeat
Current DC: node02 (22222222-2222-2222-2222-222222222222) - partition with quorum
Version: 1.0.11-1554a83db0d3c3e546cfd3aaff6af1184f79ee87
2 Nodes configured, unknown expected votes
1 Resources configured.
============

Node node01 (11111111-1111-1111-1111-111111111111): online
Node node02 (22222222-2222-2222-2222-222222222222): online
 dummy01:1       (ocf::pacemaker:Dummy) Started

Migration summary:
* Node node02:
* Node node01:
 dummy01:0: migration-threshold=1 fail-count=1

DCノードでha-logを検索すると、dummy01:0が停止したことがわかります。

# grep -R match_graph_event /var/log/ha-log
Nov  7 15:36:19 node02 crmd: [15471]: info: match_graph_event: Action dummy01:0_stop_0 (7) confirmed on node01 (rc=0)

ここで、node02で起動していたdummy01:1は停止しません。

「(う) cloneに設定されたリソースが起動停止するタイミングは故障発生時も全ノードで常に同時である。」
という文章は、node01でdummy01:0が故障したら、node02でdummy01:1も停止するよね！？
という内容(のつもり)なので「誤り」。
「誤っているものはどれか」という質問なので、正解は「う」です。
ちょっと問題の意味がわかりづらかったかもしれませんが、他の4項目が「正しい」とわかれば、消去法で(う)が選べます。