Pacemake-1.0とは違うのだよ、1.0とは！ ～Pacemaker-1.1新機能のご紹介～

Pacemaker-1.0とは 違 うのだよ 1.0とは! ~Pacemaker-1.1 新 機 能 のご 紹 介 ~ 2015 年 2 月 28 日 OSC2015 Tokyo/Spring Linux-HA Japan 竹 下 雄 大 Linux-HA Japan Project 1

本 日 の 内 容 Pacemakerってなに? Pacemaker-1.1の 特 徴 Pacemaker-1.1の 性 能 最 大 ノード 数 最 大 リソース 数 スイッチオーバ 時 間 Pacemaker-1.1の 新 機 能 kdump 連 携 機 能 Pacemaker Remote リソース 配 置 戦 略 機 能 TIPS Linux-HA Japan Project 2

Pacemakerってなに? Pacemakerはオープンソースの HAクラスタソフトです 3

Pacemakerってなに? High Availability = 高 可 用 性 つまり 一 台 のコンピュータでは 得 られない 高 い 信 頼 性 を 狙 うために 複 数 のコンピュータを 結 合 (クラスタ 化 )し ひとまとまりとする ためのソフトウェアです サービス 継 続 性 4

Pacemakerってなに? HAクラスタを 導 入 すると 故 障 で 現 用 系 でサービスができなくなったときに 自 動 で 待 機 系 でサービスを 起 動 させます このことを フェイルオーバ と 言 います ( 以 降 F.Oと 表 記 ) サービス フェイルオーバ サービス 故 障 現 用 系 Linux-HA Japan Project 待 機 系 5

Pacemakerってなに? は このHAクラスタソフトとして 実 績 のある Heartbeat と 呼 ばれていたソフトの 後 継 です 6

Pacemakerってなに? Pacemakerで 監 視 できること 仮 想 IP アプリケーション 監 視 制 御 起 動 停 止 稼 働 監 視 自 己 監 視 プロセス 監 視 watchdog ネットワーク 監 視 制 御 ping 疎 通 確 認 仮 想 IP 制 御 ノード 監 視 ハートビート 通 信 STONITH( 強 制 電 源 断 ) ディスク 監 視 制 御 ファイルシステム 監 視 共 有 ディスク 排 他 制 御 サーバ#1 サーバ#2 7

Pacemakerってなに? Pacemakerが 起 動 / 停 止 / 監 視 を 制 御 する 対 象 をリソースと 呼 ぶ 例 :Apache PostgreSQL 共 有 ディスク 仮 想 IPアドレス リソースの 制 御 はリソースエージェント(RA)を 介 して 行 う RAが 各 リソースの 操 作 方 法 の 違 いをラップし Pacemakerで 制 御 できるようにして いる 多 くはシェルスクリプト PostgreSQL RA Apache RA リソース エージェント リソース 共 有 ディスク RA 8

ここまではPacemaker-1.0も Pacemaker-1.1も 同 じです 次 から 違 いをお 話 しします 9

Pacemaker-1.1の 特 徴 まず 最 初 に 重 要 なお 知 らせ Pacemaker-1.0は 今 後 本 家 コミュニティでの メンテナンス およびリリースがされません Andrew 氏 ( 1)の 発 言 (2014/05/15): Code for the older 1.0 series of Pacemaker After lingering on in a zombie like state for a number of years, this codebase is now officially retired. ( 略 ) It had a good run but like all good things must come to an end. 全 文 は 下 記 参 照 https://github.com/clusterlabs/pacemaker-1.0/blob/master/readme.md これから 新 規 導 入 を 検 討 されている 方 は Pacemaker-1.1 系 の 利 用 をお 勧 めします! MLでは1.0 系 の 話 題 も 歓 迎 です! ( 1) Pacemakerコミュニティを 立 ち 上 げた 偉 い 人 10

Pacemaker-1.1の 特 徴 Pacemaker-1.1では コンポーネントが 変 わりました!( 1) Pacemaker- 1.0.13 Pacemaker- 1.1.12 約 4 年 の 期 間 を 経 てメジャーバー ジョンアップとなります Linux-HA Japan 開 発 ツール pm_logconvなど pm_logconvなど Linux-HA Japanで 開 発 したツー ル 類 もPacemaker-1.1.12に 対 応 済 みです 運 用 管 理 機 能 crmsh-2.1 pcs 0.9.90 運 用 管 理 機 能 としてcrmshとpcs の2 種 類 が 選 択 できるようになり ました STONITHプラグイン cluster-glue- 1.0.12 fence-agents- 4.0.10 STONITHプラグインはclusterglueとfence-agentsの2 種 類 が 選 択 できるようになりました リソース 制 御 機 能 共 有 ライブラリ ノード 管 理 機 能 resource-agents- 3.9.5 pacemaker-1.0.13 cluster-glue- 1.0.11 heartbeat- 3.0.5 crmsh corosync- 1.4.6 resource-agents- 3.9.5 + 開 発 版 pacemaker-1.1.12 libqb-0.17.1 corosync- 2.3.4 ノード 管 理 機 能 はcorosyncを 使 用 するため 設 定 やクラスタの 起 動 停 止 方 法 が 変 わります リソースエージェントは Pacemaker-1.0.13と 同 じもの を 使 用 することができます 凡 例 新 規 更 新 ( 1) 図 はOSC 2014 Tokyo/Fallの 講 演 資 料 より 引 用 運 用 管 理 機 能 にはcrmshを 利 用 する 前 提 でお 話 しします 11

Pacemaker-1.1の 性 能 ノード 管 理 部 の 変 更 (Heartbeat Corosync) 等 により Pacemaker-1.1は 大 幅 な 性 能 向 上 を 果 たしました! ノード 間 通 信 方 式 の 変 更 クラスタ/リソース 構 成 情 報 に 関 する 処 理 の 高 速 化 throttle 機 能 ( 1) etc Pacemaker-1.0の 通 信 方 式 Pacemaker-1.1の 通 信 方 式 各 ノードがブロードキャストで 全 ノードと 通 信 各 ノードはユニキャストで 次 のノードと 通 信 ( 1) Pacemakerが30 秒 ごとにCPU 負 荷 などを 計 測 し 負 荷 状 況 に 応 じてジョブの 同 時 実 行 数 を 制 限 する 機 能 12

Pacemaker-1.1の 性 能 どのくらい 変 わったのか 下 記 の 環 境 で 測 定 しました 最 大 ノード 数 最 大 リソース 数 起 動 時 間 スイッチオーバ 時 間 少 し 古 いデータですが 1.0 1.1 共 に 性 能 面 で 大 きな 変 化 はないはず Pacemaker OS ハードウェア 仮 想 マシン Pacemakerリポジトリパッケー ジ 1.0.13-1.1 pacemaker.x86_64 1.1.12-0.1.7f96b00.git.el6 RHEL6.4(x86_64) CPU:Xeon E5-2603 1.80GHz 4 メモリ:16GB OS 同 梱 のKVMを 使 用 ノードあたりのHWリソースは 以 下 CPU:1コア メモリ:2GB 13

Pacemaker-1.1の 性 能 : 最 大 ノード 数 最 大 ノード 数 :クラスタ 起 動 開 始 からリソース 起 動 完 了 までの 時 間 を 計 測 1ノード15リソースを 稼 働 600 500 84% 短 縮 起 動 時 間 400 300 78% 短 縮 83% 短 縮 PM1.0 ( 秒 ) 200 71% 短 縮 72% 短 縮 PM1.1 100 0 1+1 3+1 5+1 7+1 9+1 11+1 13+1 15+1 ノード 数 起 動 時 間 ( 秒 ) 1+1 3+1 5+1 7+1 9+1 11+1 13+1 15+1 1.0 108 127 180 312 550 起 動 不 可 1.1 31 35 39 52 87 127 193 290 Pacemaker-1.1では 12ノード 以 上 でも 起 動 可 能 Pacemaker-1.1の 起 動 時 間 は Pacemaker-1.0より7~8 割 程 度 短 縮 14

Pacemaker-1.1の 性 能 : 最 大 リソース 数 最 大 リソース 数 :クラスタ 起 動 からリソース 起 動 完 了 までの 時 間 を 計 測 1+1 構 成 700 600 9% 短 縮 起 動 時 間 ( 秒 ) 500 400 300 200 60% 短 縮 80% 短 縮 86% 短 縮 68% 短 縮 PM1.0 PM1.1 100 0 32リソース 64リソース 128リソース 256リソース 512リソース 起 動 時 間 ( 秒 ) 32リソース 64リソース 128リソース 256リソース 512リソース PM 1.0 70 154 285 312 636 PM 1.1 28 31 42 101 580 Pacemaker-1.1では 256リソースでも 現 実 的 な 時 間 で 起 動 Pacemaker-1.1のリソース 起 動 時 間 は 1.0より6~8 割 程 度 短 縮 512リソースでは 差 がほぼない throttle 機 能 の 影 響 15

Pacemaker-1.1の 性 能 :リソース 数 とスイッチオーバ 時 間 スイッチオーバ 時 間 :スイッチオーバ 開 始 からスイッチオーバ 完 了 までの 時 間 を 計 測 1+1 構 成 250 70% 短 縮 切 り 替 え 時 間 ( 秒 ) 200 150 100 50 75% 短 縮 71% 短 縮 72% 短 縮 PM1.0 PM1.1 0 32リソース 64リソース 128リソース 256リソース リソース 数 切 り 替 え 時 間 ( 秒 ) 32リソース 64リソース 128リソース 256リソース PM1.0 14 21 50 201 PM1.1 3 6 14 60 Pacemaker-1.1では 256リソースでも1 分 でスイッチオーバ 完 了 Pacemaker-1.0と 比 較 して 約 7 割 ほどの 短 縮 16

以 上 性 能 向 上 のお 話 しでした 次 から 利 便 性 向 上 に 大 きく 貢 献 する(と 思 われる) 新 機 能 についてお 話 しします! 17

新 機 能 その1 ~kdump 連 携 ~ 18

Pacemaker-1.1の 新 機 能 :kdump 連 携 機 能 kdump 連 携 機 能 故 障 ノードでkdump 実 行 中 の 場 合 STONITH( )を 実 行 したものとみなしてF.O 処 理 を 行 う 機 能 これにより 故 障 ノードでkdumpを 取 得 しつつ 速 やかなサービス 継 続 が 可 能 STONITHによりkdump 処 理 が 失 敗 する 課 題 を 解 決! Pacemaker-1.0では 故 障 ノードでkdump 実 行 中 でも 容 赦 なくSTONITHされる F.Oは 速 やかに 完 了 するが kdumpは 取 得 失 敗 kdumpを 取 得 するために kdumpの 完 了 までSTONITHおよびF.Oを 遅 延 させる stonith-helperプラグインのstandby_wait_timeを 十 分 長 く 設 定 する(=サービス 停 止 時 間 が 延 伸 ) STONITH 発 動 時 kdump 処 理 の 実 行 有 無 に 関 わらず standby_wait_time 分 F.Oは 遅 延 する それでも 確 実 ではない サービス 停 止 した 上 にkdumpも 失 敗 するという 目 も 当 てられない 状 態 kdumpは 失 敗 した!なぜだ!? STONITHされたからさ ( )STONITHとは 対 向 ノードの 状 態 が 分 からなくなった(スプリットブレイン) リソース 停 止 処 理 の 失 敗 等 クラスタにとって 致 命 的 な 状 態 が 発 生 した 場 合 に 安 全 のため に 対 向 ノードを 強 制 電 源 断 すること 19

Pacemaker-1.1の 新 機 能 :kdump 連 携 機 能 Pacemaker-1.0の 場 合 サーバ#1 カーネル クラッシュ サーバ 故 障 検 知 サーバ#2 2ndカーネル 起 動 フェイルオーバ 処 理 開 始 kdump 処 理 実 行 (クラッシュ ダンプ 取 得 ) 強 制 電 源 断 STONITHプラグイン ipmi kdump 失 敗! フェイルオーバ 処 理 継 続 20

Pacemaker-1.1の 新 機 能 :kdump 連 携 機 能 Pacemaker-1.1の 場 合 サーバ#1 カーネル クラッシュ サーバ 故 障 検 知 サーバ#2 2ndカーネル 起 動 フェイルオーバ 処 理 開 始 kdump 処 理 実 行 (クラッシュ ダンプ 取 得 ) kdump 実 行 通 知 STONITHプラグイン1 fence_kdump kdump 実 行 中? 強 制 電 源 断 STONITHプラグイン2 ipmi kdump 処 理 を 中 断 せず 安 全 にフェイルオーバ させることが 可 能 フェイルオーバ 処 理 継 続 21

使 い 方 前 提 条 件 kdump 機 能 が 有 効 になっていること セカンドカーネルと 対 向 ノード 間 で 通 信 が 可 能 であること ifconfigコマンドの 先 頭 インタフェースと 対 向 ノードが 通 信 可 能 なこと インストール 各 ノードにfence-agentsを 追 加 インストール fence-agentsはリポジトリパッケージとosメディアの 両 方 に 含 まれる ため 注 意 # yum y install fence-agents fence_kdump_sendの 配 置 先 を 確 認 /usr/sbin 配 下 にない 場 合 はシンボリックリンクを 作 成 # ln s /usr/libexec/fence_kdump_send /usr/sbin 22

使 い 方 セカンドカーネルへの 組 み 込 み(kexec-tools-2.0.0-280 未 満 ) セカンドカーネルからfence_kdump_sendを 起 動 させる 設 定 を 行 う /etc/cluster/cluster.confを 編 集 or 新 規 作 成 Kexec-tools-2.0.0-280 以 降 は/etc/kdump.confを 編 集 <cluster name="mycluster" config_version="1"> <clusternodes> <clusternode name="vm01" nodeid="1"/> <clusternode name="vm02" nodeid="2"/> </clusternodes> <fencedevices> <fencedevice name="kdump" agent="fence_kdump"/> </fencedevices> </cluster> <clusternode name>には セカンドカーネルが 利 用 するインタフェース と 通 信 可 能 なホスト 名 (またはIPアドレス)を 指 定 ホスト 名 の 場 合 は 名 前 解 決 できること <fencedevice>のagentにはfence_kdumpを 指 定 fence_kdump_sendでないことに 注 意 この 設 定 により initrdの 再 作 成 が 行 われる 23

使 い 方 セカンドカーネルへの 組 み 込 み( 続 き) kdumpサービスの 再 起 動 initrdの 再 作 成 kdumpサービスの 起 動 時 に initrdとcluster.confを 比 較 initrdよりcluster.confの 方 が 新 しい 場 合 に initrdを 再 作 成 する # service kdump restart initrdにfence_kdump_sendが 組 み 込 まれ セカンドカーネル 起 動 時 に fence_kdump_sendが 実 行 される initrdにfence_kdump_sendが 組 み 込 まれていることを 確 認 # lsinitrd /boot/initrd-2.6.32-431.el6.x86_64kdump.img grep fence_kdump_send -rwxr-xr-x 1 root root 10896 Feb 5 18:30 usr/sbin/fence_kdump_send 24

使 い 方 Pacemakerリソース 設 定 primitive prmfencekdump1 stonith:fence_kdump params pcmk_reboot_retries=1 pcmk_reboot_timeout=60s pcmk_reboot_action=off pcmk_monitor_action=metadata pcmk_host_list=vm01 op start interval=0s timeout=60s op stop interval=0s timeout=60s ( 中 略 ) fencing_topology vm01: prmstonithhelper1 prmfencekdump1 prmipmi1 vm02: prmstonithhelper2 prmfencekdump2 prmipmi2 pcmk_monitor_action=metadataは 必 須 op monitorの 実 装 がないため fencing_topology( 1)はstonith-helperと 実 プラグイン(ipmi 等 )の 間 に 指 定 ( 1)ノードに 対 して 複 数 のSTONITHリソースを 利 用 する 場 合 に そのノードに 対 して 実 行 するSTONITHリソースの 実 行 順 序 を 定 義 する また 実 行 順 序 はノード 毎 に 定 義 する 25

新 機 能 その2 ~Pacemaker Remote~ 26

Pacemaker-1.1の 新 機 能 :Pacemaker Remote Pacemaker Remote 仮 想 マシン コンテナ 物 理 サーバ 内 のサービスを 遠 隔 監 視 する 機 能 従 来 の 監 視 方 式 の 課 題 を 解 決! 仮 想 マシン 上 のサービスを 監 視 / 管 理 できない ノード 毎 に 複 雑 なPacemakerのインストール 設 定 作 業 が 必 要 Pacemaker Remoteを 導 入 すると 仮 想 マシン 自 体 の 監 視 だけでなく 仮 想 マシン 上 のサービスも 監 視 可 能 物 理 サーバも 監 視 可 能 監 視 対 象 ノードへのPacemaker 導 入 なしにノード 監 視 サービス 監 視 が 可 能 より 大 規 模 な 構 成 に 対 応 可 能 見 えるぞ! 私 にもサービスが 見 える! 27

Pacemaker-1.1の 新 機 能 :Pacemaker Remote 従 来 監 視 対 象 アプリケーション 監 視 対 象 アプリケーション 仮 想 マシン ノード 監 視 サービス 監 視 不 可 ノード 監 視 サービス 監 視 不 可 物 理 サーバ 物 理 サーバ Pacemaker Remote 監 視 対 象 アプリケーショ ン サービス 監 視 Pacemaker Remote 監 視 対 象 アプリケーショ ン Pacemaker Remote 監 視 対 象 アプリケーショ ン Pacemaker Remote 監 視 対 象 アプリケーショ ン サービス 監 視 Pacemaker Remote 仮 想 マシン 仮 想 コンテナ 物 理 サーバ ノード 監 視 ノード 監 視 物 理 サーバ 物 理 サーバ 28

使 い 方 前 提 条 件 [ホストノード] [リモートノード] 間 の 通 信 が 可 能 なこと IPアドレス/ホスト 名 ポート インストール リモートノードに pacemaker-remote resource-agents をインストール Pacemaker-1.1.12 リポジトリパッケージに 同 梱 Pacemaker 本 体 のインストールは 不 要 依 存 関 係 解 消 のため OSメディアおよびyumリポジトリを 準 備 リモートノード # yum y install pacemaker-remote resource-agents 29

使 い 方 認 証 ファイルの 作 成 ホストノードで 認 証 ファイルを 作 成 /etc/pacemaker 配 下 に 作 成 作 成 後 リモートノードにも 配 布 ホストノード # mkdir /etc/pacemaker # dd if=/dev/urandom of=/etc/pacemaker/authkey bs=4096 count=1 # scp pr /etc/pacemaker REMOTE_NODE:/etc Pacemaker Remoteの 起 動 リモートノードでPacemaker Remoteを 起 動 する リモートノード # service pacemaker_remote start Starting Pacemaker Remote Agent: [ OK ] 30

使 い 方 Pacemakerリソースの 設 定 ホストノードのPacemakerに リモードノードを 通 知 する remote RA (VirtualDomain RA( 1)を 利 用 しない 場 合 ) or VirtualDomain RAのmeta remote-nodeオプション IPアドレスまたはノード 名 で 通 知 primitive vm02-remote ocf:pacemaker:remote params server="vm02" op monitor interval=3 timeout=15 primitive Host-rsc1 Dummy op start interval=0s timeout=60s op monitor interval=30s timeout=60s op stop interval=0s timeout=60s primitive Remote-rsc1 Dummy op start interval=0s timeout=60s op monitor interval=30s timeout=60s op stop interval=0s timeout=60s remote RAでvm02がリモートノード であることを 通 知 監 視 対 象 リソースは 通 常 通 り 定 義 location loc1 Remote-rsc1 rule 200: #uname eq vm02-remote location loc2 Host-rsc1 rule 200: #uname eq vm01 ( 1) libvirt 準 拠 の 仮 想 マシンを 制 御 するRA 定 義 したリソースは 配 置 制 約 によっ て 監 視 対 象 ノードに 配 置 リモートノード or ホストノード? 31

使 い 方 ホストノードでPacemaker 起 動 ホストノード # initctl start pacemaker.combined # crm configure load update remote.crm crm_mon Online: [ vm01 ] RemoteOnline: [ vm02-remote ] リソースがリモートノードで 稼 働 Full list of resources: Host-rsc (ocf::heartbeat:dummy): Started vm01 Remote-rsc1 (ocf::heartbeat:dummy): Started vm02-remote vm02-remote (ocf::pacemaker:remote): Started vm01 Migration summary: * Node vm01: * Node vm02-remote: 32

デモ Pacemaker Remoteのデモ 仮 想 マシン 上 のリモートノードでリソースが 稼 働 していることを 確 認 リモートノード 上 のリソースがフェイルオーバすることを 確 認 Remote-rsc1 Remote-rsc2 vm02 pacemaker_remote vm03 pacemaker_remote Host-rsc1 vm01 33

デモ Pacemaker Remoteのデモ 仮 想 マシン 上 のリモートノードでリソースが 稼 働 していることを 確 認 リモートノード 上 のリソースがフェイルオーバすることを 確 認 故 障 F.O Remote-rsc1 Remote-rsc1 Remote-rsc2 vm02 pacemaker_remote vm03 pacemaker_remote Host-rsc1 vm01 34

新 機 能 その3 ~リソース 配 置 戦 略 機 能 ~ 35

Pacemaker-1.1の 新 機 能 :リソース 配 置 戦 略 機 能 リソース 配 置 戦 略 機 能 ノードとリソースに 容 量 という 概 念 を 導 入 し ノードの 空 き 容 量 リソースの 使 用 容 量 に 応 じてリソースの 配 置 先 を 決 定 する 機 能 リソースの 使 用 容 量 > ノードの 空 き 容 量 となったノードでは 当 該 リソース 配 置 不 可 従 来 のリソース 配 置 より 柔 軟 な 配 置 が 可 能 従 来 のリソース 配 置 方 式 の 課 題 を 解 決! リソース 配 置 先 の 偏 り( 1) マシン 性 能 以 上 のリソース 稼 働 による 性 能 劣 化 注 意 点 リソースの 容 量 はprimitiveリソースのみ 設 定 可 能 group clone msリソースには 設 定 不 可 ただし groupの 場 合 は 先 頭 のprimitiveリソースに 設 定 すればOK primitive clone groupについては 下 記 参 照 http://linux-ha.sourceforge.jp/wp/wp-content/uploads/osc2013tokyofall.pdf ( 1) リソース 名 や 故 障 順 序 などに 依 存 します 36

Pacemaker-1.1の 新 機 能 :リソース 配 置 戦 略 機 能 1. フェイルオーバ 先 ノードが 偏 る 従 来 の 動 作 イメージ ACT1 ACT2 SBY1 AP1 AP2 2 台 目 故 障 AP2 AP1 SBY2 フェイルオーバ 先 が 偏 る 問 題 があった 1 台 目 故 障 Pacemaker Pacemaker Pacemaker Pacemaker リソース 配 置 戦 略 機 能 の 動 作 イメージ ACT1 ACT2 SBY1 AP1 memory=512 2 台 目 故 障 AP2 memory=512 AP1 memory=512 SBY2 AP2 memory=512 リソース 使 用 量 のより 少 ない ノードにフェイル オーバされる 1 台 目 故 障 memory=2048 memory=2048 memory=2048 memory=2048 Pacemaker Pacemaker Pacemaker Pacemaker 37

Pacemaker-1.1の 新 機 能 :リソース 配 置 戦 略 機 能 2. 複 数 APが1ノード 上 で 稼 働 従 来 の 動 作 イメージ ACT1 ACT2 SBY AP1 1 台 目 故 障 AP2 2 台 目 故 障 AP2 AP1 Pacemaker Pacemaker Pacemaker 1ノード 上 で 複 数 APが 稼 働 し 性 能 が 問 題 とな る 場 合 がある リソース 配 置 戦 略 機 能 の 動 作 イメージ ACT1 ACT2 SBY AP1 capacity=1 1 台 目 故 障 AP2 capacity=1 2 台 目 故 障 AP1 capacity=1 capacity=1 capacity=1 capacity=1 Pacemaker Pacemaker Pacemaker AP2は 停 止 AP2 capacity=1 サーバ 容 量 リ ソースの 消 費 容 量 が 設 定 可 能 値 は 任 意 38

使 い 方 crmファイルに 下 記 を 定 義 する 1. ノードの 容 量 2. 配 置 戦 略 3. リソースの 容 量 ノードの 容 量 を 定 義 node XXX utilization capacity="1" node YYY utilization capacity="1" 配 置 戦 略 を 定 義 property placement-strategy="balanced" 任 意 の 名 前 でOK ただし リソース 容 量 も 同 じ 名 前 で 定 義 すること リソース 容 量 を 定 義 primitive rscdummy ocf:heartbeat:dummy utilization capacity="1" ノードの 容 量 と 同 一 の 名 前 で 定 義 する 39

Pacemaker-1.1の 情 報 が 少 ないので お 勧 めの 設 定 MLで 話 題 になったことを ピックアップしてご 紹 介 します! 40

TIPS:Pacemakerのログをまとめよう Pacemakerはコンポーネント 群 なので ログ 出 力 先 がバラバラ messages corosync.log pacemaker.log 大 量 のログを 見 比 べて 突 き 合 わせるのは 大 変 ( 例 ) ログを/var/log/ha-logにまとめて 出 力 する ファイル 名 facility priority 等 は 適 宜 修 正 してください /etc/corosync/corosync.conf logging { syslog_facility: local1 debug: off } /etc/sysconfig/pacemaker rsyslogでログをまとめよう! # corosyncのログ facilityをloca1に 設 定 export PCMK_logfile=none # pacemaker.logは 出 力 しない export PCMK_logfacility=local1 # pacemakerのログ facilityをlocal1に 設 定 export PCMK_logpriority=info # pacemakerのログレベルをinfo export HA_LOGFACILITY=local1 # stonithdのメッセージをlocal1に 出 力 する 設 定 /etc/rsyslog.conf *.info;mail.none;authpriv.none;cron.none;local1.none local1.info /var/log/messages /var/log/ha-log 41

TIPS:tokenの 推 奨 値 ってありますか? Token(corosync.conf)とは corosync 間 の 通 信 (token)の 受 信 タイムアウト ノードの 故 障 検 知 時 間 に 影 響 故 障 検 知 時 間 = token + consensus consensusは 新 たなリングを 形 成 するまでのタイムアウト 時 間 デフォルトはtoken * 1.2 1+1 構 成 の 場 合 の 推 奨 値 デフォルトの1000msです 高 負 荷 時 などにタイムアウトが 発 生 した 場 合 は 要 調 整 N+M 構 成 の 場 合 の 推 奨 値 Linux-HA Japanでの 実 績 のある 値 はありません tokenはリング 状 に 巡 回 するため ノード 数 が 増 えるほど 受 信 までの 必 要 時 間 が 伸 びる 必 要 に 応 じて 値 を 調 整 してください nodelistを 定 義 している 場 合 は 1ノード 増 加 するごとに 自 動 的 に +650msされる 詳 しくはman corosync.confの token_coefficient 項 参 照 42

Linux-HA Japan URL http://linux-ha.sourceforge.jp/ http://sourceforge.jp/projects/linux-ha/ Pacemaker 関 連 の 最 新 情 報 を 日 本 語 で 発 信 Pacemakerのダウンロードもこ ちらからどうぞ (インストールが 楽 なリポジトリパッケージ を 公 開 しています ) 43

日 本 におけるHAクラスタについての 活 発 な 意 見 交 換 の 場 として Linux-HA Japan 日 本 語 メーリングリスト も 開 設 しています Linux-HA-Japan MLでは Pacemaker Heartbeat3 Corosync DRBDなど HAクラスタに 関 連 する 話 題 は 歓 迎! ML 登 録 用 URL http://linux-ha.sourceforge.jp/ の メーリングリスト をクリック MLアドレス linux-ha-japan@lists.sourceforge.jp スパム 防 止 のために 登 録 者 以 外 の 投 稿 は 許 可 制 です 44

ご 清 聴 ありがとうございました Linux-HA Japan 検 索 45

HA Cluster Summit 2015 参 加 報 告 Linux-HA Japanのメンバ3 名 が チェコ ブルーノで 世 界 中 のLinux-HA 界 隈 の 方 々と 熱 い 議 論 をしてきました! 46

HA Cluster Summit 2015 概 要 日 時 場 所 Pacemaker, corosync などの HAクラスタに 関 連 する 開 発 者 が 一 同 に 会 するF2Fミーティング http://plan.alteeve.ca/index.php/main_page 開 催 は 不 定 期 前 回 は 2011 年 開 催 (プラハ) Red Hat, SUSEのメンバが 持 ち 回 りで 主 催 2015 年 2 月 4 日 ( 水 )~2015 年 2 月 5 日 ( 木 ) Red Hat 社 チェコオフィス(Brno) 参 加 者 合 計 26 名 程 度 大 部 分 は Red Hat 開 発 者 SUSE(4 名 ), LINBIT(3 名 ), SAP(1 名 ) その 他 個 人 会 社 など 日 本 からは3 名

参 加 者

トピック1: 今 後 のHAコミュニティ 全 体 の 方 針 について 現 状 の 課 題 HAクラスタに 関 するWebサイト ML 等 が 多 数 分 散 しており 情 報 源 や 問 い 合 わせ 先 がわ かりづらい 過 去 の 経 緯 (Red Hatクラスタ 機 能 とのマージ 等 )により 開 発 者 コンポーネントが 細 分 化 さ れているため 主 な 議 論 内 容 初 めて 参 加 する 人 への 入 口 となるポータルのようなものが 欲 しい 理 想 は OpenStack コミュニティのように 全 体 の 統 括 とサブプロジェクトに 分 かれているよう な 体 制 が 望 ましいが 現 時 点 ではそこまでのリソースはない まずは 全 体 の 入 口 となる 名 前 を 決 定 し 既 存 の 情 報 源 へのリンクを 設 けるところから 始 めた い 決 定 事 項 clusterlabs の 名 前 を 全 体 の 名 前 とする wiki (clusterlabs.org), github, メーリングリスト IRC を 全 て clusterlabs の 名 前 で 統 一 次 回 開 催 予 定 時 期 : 2016 年 夏 頃 目 途 場 所 : プラハ SUSEオフィスが 候 補 ( 詳 細 未 定 )

トピック2: HAクラスタ 新 機 能 について 最 近 開 発 された 機 能 および 今 後 に 向 けた 新 機 能 の 要 望 と 議 論 UIのエラーチェック 改 善 ライブマイグレーションの 動 作 改 善 など 比 較 的 細 かい 改 善 についての 議 論 がほとんど docker リソースエージェントの 紹 介 dockerコンテナを 管 理 するためのRA コミュニティ 最 新 版 で 公 開 済 み Linux-HA Japanリポジトリパッケージ 版 にはまだ 含 まれていません(1.1.12-1.1 時 点 ) コンテナ 内 サービスの 監 視 と 構 築 の 容 易 化 が 可 能 例 : Webサーバのグループリソース(RA ミドルウェア)をコンテナ 内 に 予 め 構 築 docker RAの 引 数 として IP ポート 番 号 等 を 指 定 してサービスインスタンス を 作 成 可 能 サービス 監 視 は pacemaker_remoted 経 由