Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. Linux-HA>
  3. Japanese
スプリットブレインの対処方法について
kozumi at repica
Jan 13, 2016, 7:42 PM
Post #1 of 2 (1442 views)
Permalink
MLの皆さん

古積と申します。
スプリットブレインの事象が発生しました。
対処方法についてご相談させて頂けないでしょうか。

■事象内容
1/7 18:12 稼働系(host1)にてCPU高負荷事象が発生
1/7 18:12:51 待機系(host2)で主系へ昇格する動作が起こりスプリットブレインとなった。

■ご相談内容
1) 事象の理解について
稼働系高負荷により待機系との間で実施していた UDP パケットの heartbeat 通信で
応答が無かったため、待機系が稼働系となり、スプリットブレインが発生したとの
理解で誤りはないでしょうか。他の解釈があればご指摘頂けると幸いです。

2) パラメータ調整について
稼働系高負荷となった場合でも、待機系が稼働系へ
昇格するまでの待ち時間を延長したいと考えています。

今回の事象も3分程度待てば稼働系の負荷も下がっている為、
今回の環境については5分程度 timeout を持たせたいと考えておりました。

下記マニュアルを読むと default-action-timeout のパラメータで
実現出来そうにも思えておりますが、その認識で誤りないでしょうか。
他のパラメータが関連しそうであればご指摘頂けますと嬉しいです。

https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/6/html/Configuring_the_Red_Hat_High_Availability_Add-On_with_Pacemaker/ch-clusteropts-HAAR.html


■環境
OS: CentOS6.5
corosync-1.4.1-17
pacemaker-1.1.10

■事象発生時の待機系(2号機)のログ抜粋
Jan 07 18:12:43 [9102] <host2> cib: info: crm_client_new:
Connecting 0x1007450 for uid=0 gid=0 pid=28534
id=bbc03f9e-ca10-4332-bca7-273466553815
Jan 07 18:12:43 [9102] <host2> cib: info: cib_process_request:
Completed cib_query operation for section nodes: OK (rc=0,
origin=local/crm_attribute/2, version=0.508.3)
Jan 07 18:12:43 [9102] <host2> cib: info: cib_process_request:
Completed cib_query operation for section
//cib/configuration/nodes//node[@id='<host2>']//instance_attributes//nvpair[@name='pgsql-nirc-d
ata-status']: OK (rc=0, origin=local/crm_attribute/3, version=0.508.3)
Jan 07 18:12:43 [9102] <host2> cib: info: crm_client_destroy:
Destroying 0 events
Jan 07 18:12:51 [9102] <host2> cib: notice:
plugin_handle_membership: Membership 8880: quorum lost
Jan 07 18:12:51 [9102] <host2> cib: info: crm_update_peer_proc:
plugin_handle_membership: Node <host1>[1191880896] - unknown is now lost
Jan 07 18:12:51 [9102] <host2> cib: notice: crm_update_peer_state:
plugin_handle_membership: Node <host1>[1191880896] - state is now lost
(was member)
Jan 07 18:12:51 [9107] <host2> crmd: notice:
plugin_handle_membership: Membership 8880: quorum lost
Jan 07 18:12:51 [9107] <host2> crmd: info: crm_update_peer_proc:
plugin_handle_membership: Node <host1>[1191880896] - unknown is now lost
Jan 07 18:12:51 [9107] <host2> crmd: info: peer_update_callback:
Client <host1>/peer now has status [offline] (DC=<host1>)
Jan 07 18:12:51 [9107] <host2> crmd: notice: crm_update_peer_state:
plugin_handle_membership: Node <host1>[1191880896] - state is now lost
(was member)
Jan 07 18:12:51 [9107] <host2> crmd: info: peer_update_callback:
<host1> is now lost (was member)
Jan 07 18:12:51 [9107] <host2> crmd: warning: reap_dead_nodes: Our
DC node (<host1>) left the cluster
Jan 07 18:12:51 [9107] <host2> crmd: notice: do_state_transition:
State transition S_NOT_DC -> S_ELECTION [ input=I_ELECTION
cause=C_FSA_INTERNAL origin=reap_dead_nodes ]
Jan 07 18:12:51 [9107] <host2> crmd: info: update_dc:
Unset DC. Was <host1>
Jan 07 18:12:51 [9107] <host2> crmd: info: do_log: FSA: Input
I_ELECTION_DC from do_election_check() received in state S_ELECTION
Jan 07 18:12:51 [9107] <host2> crmd: notice: do_state_transition:
State transition S_ELECTION -> S_INTEGRATION [ input=I_ELECTION_DC
cause=C_FSA_INTERNAL origin=do_election_check ]
Jan 07 18:12:51 [9107] <host2> crmd: info: do_te_control:
Registering TE UUID: f6fe7fd1-0859-4bb3-b98a-574f5be7b3f9
Jan 07 18:12:51 [9107] <host2> crmd: info: set_graph_functions:
Setting custom graph functions
Jan 07 18:12:51 [9106] <host2> pengine: info: crm_client_new:
Connecting 0xb3b490 for uid=189 gid=0 pid=9107
id=381681d3-4fc2-42a9-97f7-286c014297dd
Jan 07 18:12:51 [9107] <host2> crmd: info: do_dc_takeover:
Taking over DC status for this partition
Jan 07 18:12:51 [9102] <host2> cib: info: cib_process_readwrite:
We are now in R/W mode
Jan 07 18:12:51 [9102] <host2> cib: info: cib_process_request:
Completed cib_master operation for section 'all': OK (rc=0,
origin=local/crmd/13, version=0.508.3)
Jan 07 18:12:51 [9102] <host2> cib: info: cib_process_request:
Completed cib_modify operation for section cib: OK (rc=0,
origin=local/crmd/14, version=0.508.3)
Jan 07 18:12:51 [9102] <host2> cib: info: cib_process_request:
Completed cib_query operation for section
//cib/configuration/crm_config//cluster_property_set//nvpair[@name='dc-version']:
OK (rc=0, origin=local/crmd/15, version=0.508.3)
Jan 07 18:12:51 [9102] <host2> cib: info: cib_process_request:
Completed cib_modify operation for section crm_config: OK (rc=0,
origin=local/crmd/16, version=0.508.3)
Jan 07 18:12:51 [9102] <host2> cib: info: cib_process_request:
Completed cib_query operation for section
//cib/configuration/crm_config//cluster_property_set//nvpair[@name='cluster-infrastructure']:
OK (rc=0, origin=local/crmd/17, version=0.508.3)





--

‐－－－―――――――――――――――――――――－－－‐
古積 広一（Kozumi Koichi）
E-Mail: kozumi@repica.co.jp
―――――――――――――――――――――
株式会社レピカ (repica inc.)
レピカ事業部 技術本部 運用部
〒107-0062 東京都港区南青山2-24-15
青山タワービル別館
TEL: 03-5414-3611 FAX: 03-5414-3622
URL: http://repica.jp/
‐－－－―――――――――――――――――――――－－－‐

━━━━━━━━━━━━━━━━━━━━━━━━
▼10年連続シェアNo.1 個人情報漏えい対策ソフト
【P-Pointer】http://ppointer.jp/ ★マイナンバー対応済み
「1分でわかる！P-Pointer」動画でご紹介中！
â””https://youtu.be/6uvuXlPAeHc
━━━━━━━━━━━━━━━━━━━━━━━━

▼国内初！立体物認識に対応したARアプリ
【ARAPPLI】http://www.arappli.com/service/arappli/

▼ITビジネスを創造しながら未来を創る
【VARCHAR】http://varchar.co.jp/
━━━━━━━━━━━━━━━━━━repica group━
Re: スプリットブレインの対処方法について [ In reply to ]
renayama19661014 at ybb
Jan 18, 2016, 2:07 PM
Post #2 of 2 (1392 views)
Permalink
古積さん

こんにちは、山内です。

>1) 事象の理解について
>稼働系高負荷により待機系との間で実施していた UDP パケットの heartbeat 通信で
>応答が無かったため、待機系が稼働系となり、スプリットブレインが発生したとの
>理解で誤りはないでしょうか。他の解釈があればご指摘頂けると幸いです。

ログを見る限り、負荷によりcorosync通信(heartbeat通信）が無かった為、発生した認識で問題ないと思います。


>2) パラメータ調整について
>稼働系高負荷となった場合でも、待機系が稼働系へ
>昇格するまでの待ち時間を延長したいと考えています。
>
>
>今回の事象も3分程度待てば稼働系の負荷も下がっている為、
>今回の環境については5分程度 timeout を持たせたいと考えておりました。
>
>
>下記マニュアルを読むと default-action-timeout のパラメータで
>実現出来そうにも思えておりますが、その認識で誤りないでしょうか。
>他のパラメータが関連しそうであればご指摘頂けますと嬉しいです。


default-action-timeoutは異なるパラメータになります。
上記、corosync通信は/etc/corosync.confのtokenパラメータで伸長出来ますが、
このパラメータを5分に伸長することは、ちょっと現実的ではなく、通常のノードダウン時など動作へも影響が
考えれます。

一度、実際に発生している負荷の状況を見極めて、仮想環境であれば、CPU、メモリなどのリソース割り当てを増やすなどの方法が良いかと
思います。（実機であれば、構成マシンのアップグレードリプレースやメモリ追加など）

以上です。

----- Original Message -----
>From: 古積広一 <kozumi@repica.co.jp>
>To: linux-ha-japan@lists.osdn.me
>Date: 2016/1/14, Thu 12:42
>Subject: [Linux-ha-jp] スプリットブレインの対処方法について
>
>
>MLの皆さん
>
>
>古積と申します。
>スプリットブレインの事象が発生しました。
>対処方法についてご相談させて頂けないでしょうか。
>
>
>■事象内容
>1/7 18:12 稼働系(host1)にてCPU高負荷事象が発生
>1/7 18:12:51 待機系(host2)で主系へ昇格する動作が起こりスプリットブレインとなった。
>
>
>■ご相談内容
>1) 事象の理解について
>稼働系高負荷により待機系との間で実施していた UDP パケットの heartbeat 通信で
>応答が無かったため、待機系が稼働系となり、スプリットブレインが発生したとの
>理解で誤りはないでしょうか。他の解釈があればご指摘頂けると幸いです。
>
>
>2) パラメータ調整について
>稼働系高負荷となった場合でも、待機系が稼働系へ
>昇格するまでの待ち時間を延長したいと考えています。
>
>
>今回の事象も3分程度待てば稼働系の負荷も下がっている為、
>今回の環境については5分程度 timeout を持たせたいと考えておりました。
>
>
>下記マニュアルを読むと default-action-timeout のパラメータで
>実現出来そうにも思えておりますが、その認識で誤りないでしょうか。
>他のパラメータが関連しそうであればご指摘頂けますと嬉しいです。
>
>
>https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/6/html/Configuring_the_Red_Hat_High_Availability_Add-On_with_Pacemaker/ch-clusteropts-HAAR.html
>
>
>
>
>■環境
>OS: CentOS6.5
>corosync-1.4.1-17
>
>pacemaker-1.1.10
>
>
>
>■事象発生時の待機系(2号機)のログ抜粋
>Jan 07 18:12:43 [9102] <host2>        cib:     info: crm_client_new:   Connecting 0x1007450 for uid=0 gid=0 pid=28534 id=bbc03f9e-ca10-4332-bca7-273466553815
>Jan 07 18:12:43 [9102] <host2>        cib:     info: cib_process_request:      Completed cib_query operation for section nodes: OK (rc=0, origin=local/crm_attribute/2, version=0.508.3)
>Jan 07 18:12:43 [9102] <host2>        cib:     info: cib_process_request:      Completed cib_query operation for section //cib/configuration/nodes//node[@id='<host2>']//instance_attributes//nvpair[@name='pgsql-nirc-d
>ata-status']: OK (rc=0, origin=local/crm_attribute/3, version=0.508.3)
>Jan 07 18:12:43 [9102] <host2>        cib:     info: crm_client_destroy:       Destroying 0 events
>Jan 07 18:12:51 [9102] <host2>        cib:   notice: plugin_handle_membership:         Membership 8880: quorum lost
>Jan 07 18:12:51 [9102] <host2>        cib:     info: crm_update_peer_proc:     plugin_handle_membership: Node <host1>[1191880896] - unknown is now lost
>Jan 07 18:12:51 [9102] <host2>        cib:   notice: crm_update_peer_state:    plugin_handle_membership: Node <host1>[1191880896] - state is now lost (was member)
>Jan 07 18:12:51 [9107] <host2>       crmd:   notice: plugin_handle_membership:         Membership 8880: quorum lost
>Jan 07 18:12:51 [9107] <host2>       crmd:     info: crm_update_peer_proc:     plugin_handle_membership: Node <host1>[1191880896] - unknown is now lost
>Jan 07 18:12:51 [9107] <host2>       crmd:     info: peer_update_callback:     Client <host1>/peer now has status [offline] (DC=<host1>)
>Jan 07 18:12:51 [9107] <host2>       crmd:   notice: crm_update_peer_state:    plugin_handle_membership: Node <host1>[1191880896] - state is now lost (was member)
>Jan 07 18:12:51 [9107] <host2>       crmd:     info: peer_update_callback:     <host1> is now lost (was member)
>Jan 07 18:12:51 [9107] <host2>       crmd:  warning: reap_dead_nodes:  Our DC node (<host1>) left the cluster
>Jan 07 18:12:51 [9107] <host2>       crmd:   notice: do_state_transition:      State transition S_NOT_DC -> S_ELECTION [ input=I_ELECTION cause=C_FSA_INTERNAL origin=reap_dead_nodes ]
>Jan 07 18:12:51 [9107] <host2>       crmd:     info: update_dc:        Unset DC. Was <host1>
>Jan 07 18:12:51 [9107] <host2>       crmd:     info: do_log:   FSA: Input I_ELECTION_DC from do_election_check() received in state S_ELECTION
>Jan 07 18:12:51 [9107] <host2>       crmd:   notice: do_state_transition:      State transition S_ELECTION -> S_INTEGRATION [ input=I_ELECTION_DC cause=C_FSA_INTERNAL origin=do_election_check ]
>Jan 07 18:12:51 [9107] <host2>       crmd:     info: do_te_control:    Registering TE UUID: f6fe7fd1-0859-4bb3-b98a-574f5be7b3f9
>Jan 07 18:12:51 [9107] <host2>       crmd:     info: set_graph_functions:      Setting custom graph functions
>Jan 07 18:12:51 [9106] <host2>    pengine:     info: crm_client_new:   Connecting 0xb3b490 for uid=189 gid=0 pid=9107 id=381681d3-4fc2-42a9-97f7-286c014297dd
>Jan 07 18:12:51 [9107] <host2>       crmd:     info: do_dc_takeover:   Taking over DC status for this partition
>Jan 07 18:12:51 [9102] <host2>        cib:     info: cib_process_readwrite:    We are now in R/W mode
>Jan 07 18:12:51 [9102] <host2>        cib:     info: cib_process_request:      Completed cib_master operation for section 'all': OK (rc=0, origin=local/crmd/13, version=0.508.3)
>Jan 07 18:12:51 [9102] <host2>        cib:     info: cib_process_request:      Completed cib_modify operation for section cib: OK (rc=0, origin=local/crmd/14, version=0.508.3)
>Jan 07 18:12:51 [9102] <host2>        cib:     info: cib_process_request:      Completed cib_query operation for section //cib/configuration/crm_config//cluster_property_set//nvpair[@name='dc-version']: OK (rc=0, origin=local/crmd/15, version=0.508.3)
>Jan 07 18:12:51 [9102] <host2>        cib:     info: cib_process_request:      Completed cib_modify operation for section crm_config: OK (rc=0, origin=local/crmd/16, version=0.508.3)
>Jan 07 18:12:51 [9102] <host2>        cib:     info: cib_process_request:      Completed cib_query operation for section //cib/configuration/crm_config//cluster_property_set//nvpair[@name='cluster-infrastructure']: OK (rc=0, origin=local/crmd/17, version=0.508.3)
>
>
>
>
>
>
>
>
>
>--
>
>
>
>‐－－－―――――――――――――――――――――－－－‐
>               古積 広一（Kozumi Koichi）
>               E-Mail: kozumi@repica.co.jp
>          ―――――――――――――――――――――
>          株式会社レピカ (repica inc.)
>              レピカ事業部 技術本部 運用部
>          〒107-0062　東京都港区南青山2-24-15
>                      青山タワービル別館
>          TEL: 03-5414-3611 FAX: 03-5414-3622
>          URL: http://repica.jp/
>‐－－－―――――――――――――――――――――－－－‐
>
>
>
>━━━━━━━━━━━━━━━━━━━━━━━━
>▼10年連続シェアNo.1 個人情報漏えい対策ソフト
>【P-Pointer】http://ppointer.jp/ ★マイナンバー対応済み
>「1分でわかる！P-Pointer」動画でご紹介中！
>â””https://youtu.be/6uvuXlPAeHc
>━━━━━━━━━━━━━━━━━━━━━━━━
>
>▼国内初！立体物認識に対応したARアプリ
>【ARAPPLI】http://www.arappli.com/service/arappli/
>
>▼ITビジネスを創造しながら未来を創る
>【VARCHAR】http://varchar.co.jp/
>━━━━━━━━━━━━━━━━━━repica group━
>
>
>
>_______________________________________________
>Linux-ha-japan mailing list
>Linux-ha-japan@lists.osdn.me
>http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>
>
>

_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal