share facebook facebook2 twitter menu hatena pocket slack

2014.07.30 WED

超私的 Undocumented Pacemaker and Corosync Vol.1

川原 洋平

WRITTEN BY川原 洋平

cloudpack の 自称 Sensu芸人 の かっぱこと 川原 洋平@inokara)です。

タイトルは大袈裟でちゃんとドキュメント読めば書いてあることばかりかと。

はじめに

個人的に Corosync と Pacemaker を調べる機会が多いので、タイトルには Undocumented って書いてありますが、ドキュメントに書いてあること、書いてあるかもしれないこと等をまとめてみました。間違いもあるかもしれないのでご参考まで。


ハートビート

Pacemaker(Corosync) 間で行われているハートビート通信の中身についてちょっと調べてみました。

基本的なこと

  • ハートビート通信は UDP の 5404 ポートを使って行われている
  • マルチキャストとユニキャストを指定可能(デフォルトはマルチキャスト)
  • transport : udpu と設定することでユニキャストを利用可能

tcpdump して気付いたこと

  • ハートビート通信は UDP の 5404 ポート同士で行っている
  • CIB の情報も UDP を通してやりとりされるが送信ポートは 5404 ポートに限定されていない
稼働中

01

  • ハートビート通信は 2 秒毎に行っている(変更可能?)
起動、停止

02

  • corosync の起動と停止の際には CIB 情報も流れる

スプリットブレイン

Pacemaker 間で行っているハートビート通信が切れてしまい相手の死活が監視出来なくなってしまった場合に両方のノードがマスターノードとして働こうとする現象が発生します。この現象のことをスプリットプレインと呼びます。以下のようなイメージです。

03

死活監視が切れてしまったことで双方のノードでクォーラムを取得し自身がマスターノードとして稼働しようとします。

用語

スプリットブレイン
  • 両方のノードがマスターノードとして働こうとする現象
クォーラム
  • クラスタ内で HA クラスタとして動作出来る権利
  • クラスタが 3 台のノードで構成されいる場合に 1 台のノードに障害発生すると残り 2 台がクォーラムの権利を得ることが出来る

以下のようなイメージ。

04

三台目の J Soul Brothers は本記事内容とは関係ありません。

対策

対策としては下記を行います。

  • stonith-enabled=”true” を設定する
  • stonith-enabled を true にすることで STONITH 機能が有効になる

STONITH 機能とは

  • スプリットブレインが発生した場合に制御不能となっているノードを強制的に再起動、停止してクラスタから離脱させる機能
  • 強制的に離脱=フェンシング
  • STONITH を実行するプラグインが提供されているおり以下のようなコマンドにて確認可能
stonith -L

Amazon EC2 での対応

Amazon EC2 上で Pacemaker を運用する場合でもスプリットブレインの対策には頭を悩ますことがあるかもしれませんが、対策をまとめると以下のような方法が考えられます。

  • no-quorum-policy=”ignore” としてクォーラム機能を無効

上記は Amazon EC2 上での運用に限らず、クラスタのノードが 2 台構成の場合には迷わず ignore にしておきます。そして、勝手にフェールバックをさせないようにする為に以下を設定しておきます。

  • resource-stickiness=”INFINITY”

上記の設定はではリソースのノードに対する粘着度を「無限大」と設定することを意味します。

これだけではスプリットブレインの対策には不十分ですので以下の何れかを設定、又は対応を検討しましょう。

  • stonith-enabled=”false” として STONITH を無効として Resouce Agent の monitor を利用する
  • stonith-enabled=”true” として上記で紹介させて頂いているプラグインを利用する

参考


うおお!

元記事は、こちら