Pacemaker クラスタースタック¶

マルチキャストを使う場合の Corosync の設定¶

ほとんどのディストリビューションは、Corosync パッケージに同梱されているドキュメントの一部として、サンプル設定ファイル (corosync.conf.example) を同梱しています。

マルチキャスト用の Corosync 設定ファイル例 (``corosync.conf``)

totem {
      version: 2

      # Time (in ms) to wait for a token (1)
      token: 10000

     # How many token retransmits before forming a new
     # configuration
     token_retransmits_before_loss_const: 10

     # Turn off the virtual synchrony filter
     vsftype: none

     # Enable encryption (2)
     secauth: on

     # How many threads to use for encryption/decryption
     threads: 0

     # This specifies the redundant ring protocol, which may be
     # none, active, or passive. (3)
     rrp_mode: active

     # The following is a two-ring multicast configuration. (4)
     interface {
             ringnumber: 0
             bindnetaddr: 10.0.0.0
             mcastaddr: 239.255.42.1
             mcastport: 5405
     }
     interface {
             ringnumber: 1
             bindnetaddr: 10.0.42.0
             mcastaddr: 239.255.42.2
             mcastport: 5405
     }
}

amf {
     mode: disabled
}

service {
        # Load the Pacemaker Cluster Resource Manager (5)
        ver:       1
        name:      pacemaker
}

aisexec {
        user:   root
        group:  root
}

logging {
        fileline: off
        to_stderr: yes
        to_logfile: no
        to_syslog: yes
        syslog_facility: daemon
        debug: off
        timestamp: on
        logger_subsys {
                subsys: AMF
                debug: off
                tags: enter|leave|trace1|trace2|trace3|trace4|trace6
        }}

以下に注意してください。

• token の値は、Corosync トークンがリング内を転送されることが予想される時間をミリ秒単位で指定します。このタイムアウトを過ぎると、トークンが失われます。 token_retransmits_before_loss_const lost トークンの後、応答しないプロセッサー (クラスターノード) が停止していると宣言されます。 token × token_retransmits_before_loss_const は、ノードが停止とみなされるまでに、クラスターメッセージに応答しないことが許される最大時間です。トークン向けのデフォルトは、1000 ミリ秒 (1 秒)、4 回の再送許可です。これらのデフォルト値は、フェイルオーバー時間を最小化することを意図していますが、頻繁な誤検知と短いネットワーク中断による意図しないフェイルオーバーを引き起こす可能性があります。ここで使用される値は、フェイルオーバー時間がわずかに長くなりますが、より安全です。

• secauth を有効化すると、Corosync ノードが /etc/corosync/authkey に保存された 128 バイトの共有シークレットを使用して相互に認証されます。これは、 corosync-keygen ユーティリティーを使用して生成できます。 secauth を使用するとき、クラスター通信は暗号化されます。

• Corosync において、設定は (複数のインターフェースを用いた) 冗長ネットワークを使用します。これは none ではなく、Redundant Ring Protocol (RRP) を選択する必要があることを意味します。active が RRP の推奨モードです。

  インターフェースの推奨設定に関する注意事項がいくつかあります。

  • 設定済みの各インターフェースは、0 から始まる一意な ringnumber を持つ必要があります。
  • bindnetaddr は、バインドするインターフェースのネットワークアドレスです。この例は、2 つの /24 IPv4 サブネットを使用します。
  • マルチキャストグループ (mcastaddr) は、クラスターの境界を越えて再利用できません。2 つの独立したクラスターは、同じマルチキャストグループを使用すべきではありません。選択したマルチキャストアドレス をきちんと`RFC 2365, "Administratively Scoped IP Multicast" <http://www.ietf.org/rfc/rfc2365.txt>`_ に準拠させてください。
  • ファイアウォール設定に向け、Corosync は UDP のみで通信して、 mcastport (受信用) と mcastport - 1 (送信用) を使用します。

• Pacemaker サービスに関するサービス定義は、直接 corosync.conf ファイルにあるか、単独ファイル /etc/corosync/service.d/pacemaker にある可能性があります。

  注釈

  Ubuntu 14.04 において Corosync バージョン 2 を使用している場合、サービスの節の下にある行を削除するかコメントアウトします。これらの節により、Pacemaker が起動できます。別の潜在的な問題は、Corosync と Pacemaker の起動と停止の順番です。必ず Pacemaker が Corosync の後に起動して、Corosync の前に停止させるために、start と kill のシンボリックリンクを手動で修正します。

  # update-rc.d pacemaker start 20 2 3 4 5 . stop 00 0 1 6 .
  

  Pacemaker サービスは、以下の内容で作成された、追加の設定ファイル /etc/corosync/uidgid.d/pacemaker も必要とします。

  uidgid {
    uid: hacluster
    gid: haclient
  }
  

• 作成され同期された後、 corosync.conf ファイル (および、secauth オプションが有効化されている場合、 authkey ファイル) が、すべてのクラスターノードにわたり同期されます。

ユニキャストを使う場合の Corosync の設定¶

マルチキャストをサポートしていない場合、Corosync はユニキャストで設定すべきです。ユニキャスト向け corosync.conf ファイルの設定例を以下に示します。

ユニキャスト向け Corosync 設定ファイルの断片 (``corosync.conf``)

totem {
        #...
        interface {
                ringnumber: 0
                bindnetaddr: 10.0.0.0
                broadcast: yes (1)
                mcastport: 5405
        }
        interface {
                ringnumber: 1
                bindnetaddr: 10.0.42.0
                broadcast: yes
                mcastport: 5405
        }
        transport: udpu (2)
}

nodelist { (3)
        node {
                ring0_addr: 10.0.0.12
                ring1_addr: 10.0.42.12
                nodeid: 1
        }
        node {
                ring0_addr: 10.0.0.13
                ring1_addr: 10.0.42.13
                nodeid: 2
        }
        node {
                ring0_addr: 10.0.0.14
                ring1_addr: 10.0.42.14
                nodeid: 3
        }
}
#...

以下に注意してください。

• broadcast パラメーターが yes に設定されている場合、ブロードキャストアドレスが通信に使用されます。このオプションが設定されている場合、mcastaddr パラメーターは設定すべきではありません。

• transport ディレクティブは使用するトランスポートメカニズムを制御します。 マルチキャストを完全に無効にするためには、udpu ユニキャストトランスポートパラメーターを指定します。nodelist ディレクティブにメンバー一覧を指定する必要があります。展開する前にメンバーシップを構成することができます。デフォルトは udp です。トランスポート形式は udpu や iba に設定することもできます。

• nodelist ディレクティブに、クラスター内のノードに関する具体的な情報を指定できます。このディレクティブは、node サブディレクティブのみを含められます。これは、メンバーシップのすべてのメンバーを指定し、デフォルト以外に必要となるオプションを指定します。すべてのノードは、少なくとも ring0_addr の項目を入力する必要があります。

  注釈

  UDPUでは、全てのノードがメンバーシップメンバーを指定しなければなりません。

  利用できるオプションは次のとおりです。

  • ring{X}_addr は、1 つのノードの IP アドレスを指定します。 {X} はリングの番号です。
  • nodeid は、IPv4 を使用するときにオプション、IPv6 を使用するときに必須です。クラスターメンバーシップサービスに配信される、ノード識別子を指定する 32 ビットの値です。IPv4 で指定されていない場合、ノード ID は、システムがリング識別子 0 に割り当てた 32 ビットの IP アドレスになります。ノード識別子の値 0 は、予約済みであり、使用してはいけません。

votequorum ライブラリーを使う場合の Corosync の設定¶

votequorum ライブラリーは Corosync プロジェクトの一部です。投票ベースのクォーラムサービスへのインターフェースを提供し、Corosync 設定ファイルにおいて明示的に有効化する必要があります。votequorum ライブラリーのおもな役割は、スプリットブレイン状態を避けるためですが、以下の機能も提供します。

• クォーラム状態を問い合わせます
• クォーラムサービスが把握しているノードの一覧表示
• クォーラムの状態変更の通知を受け付けます
• ノードに割り当てられたボート数を変更します
• クラスターが定数になるために期待されるボート数を変更します
• 追加のクォーラムデバイスを接続して、小規模なクラスターがノード障害時にクォーラムを取得できるようにします。

votequorum ライブラリーは、高度なクラスター設定により、 qdisk 、CMAN 向けディスクベースのクォーラムデーモンを置き換えて除去するために作成されます。

corosync.conf ファイルの votequorum サービス設定例:

quorum {
        provider: corosync_votequorum (1)
        expected_votes: 7 (2)
        wait_for_all: 1 (3)
        last_man_standing: 1 (4)
        last_man_standing_window: 10000 (5)
       }

以下に注意してください。

• corosync_votequorum を指定することにより、votequorum ライブラリーを有効化します。これは唯一の必須オプションです。
• このクラスターは、7 ノード (各ノードが 1 つの投票権を持つ)、クォーラム 4 つに設定した expected_votes で完全に動作します。ノードの一覧は nodelist に指定された場合、 expected_votes の値は無視されます。
• クラスター (全ノードダウン) を起動して、 wait_for_all を 1 に設定するとき、クラスターのクォーラムはすべてのノードがオンラインになり、まずクラスターに参加するまで保持されることを意味します。このパラメーターは Corosync 2.0 の新機能です。
• last_man_standing を 1 に設定することにより、Last Man Standing (LMS) 機能を有効化できます。デフォルトで、無効化されています (0 に設定)。クラスターが、last_man_standing_window パラメーターに指定した時間より長く、クォーラムエッジ (expected_votes: が 7 に設定、 online nodes: が 4 に設定) にある場合、クラスターはクォーラムを再計算して、次のノードが失われても動作を継続します。この論理は、クラスターのオンラインノードが 2 になるまで繰り返されます。クラスターが 2 つのメンバーから 1 つだけに減ることを許可するために、 auto_tie_breaker パラメーターを設定する必要があります。これは本番環境では推奨されません。
• last_man_standing_window は、1 つ以上のホストがクラスターから失われた後、クォーラムを再計算するために必要となる時間をミリ秒単位で指定します。新しくクォーラムを再計算するために、クラスターは少なくとも last_man_standing_window に指定された間隔はクォーラムを保持する必要があります。デフォルトは 10000ms です。

Corosync の開始¶

Corosync は通常のシステムサービスとして起動します。お使いのディストリビューションに応じて、LSB init スクリプト、upstart ジョブ、systemd ユニットファイルを同梱しているかもしれません。

• LSBinit スクリプトを用いた corosync の起動:

  # /etc/init.d/corosync start
  

  他の

  # service corosync start
  

• upstart を用いた corosync の起動:

  # start corosync
  

• systemd ユニットファイルを用いた corosync の起動:

  # systemctl start corosync
  

corosyncの接続性をそれらのツールの一つで確認することができます。

corosync-cfgtool ユーティリティーに -s オプションを付けて実行して、コミュニケーションリングの稼働状態の概要を取得します。

# corosync-cfgtool -s
Printing ring status.
Local node ID 435324542
RING ID 0
        id      = 10.0.0.82
        status  = ring 0 active with no faults
RING ID 1
        id      = 10.0.42.100
        status  = ring 1 active with no faults

corosync-objctl ユーティリティーを使用して、Corosync クラスターのメンバー一覧を出力します。

# corosync-objctl runtime.totem.pg.mrp.srp.members
runtime.totem.pg.mrp.srp.435324542.ip=r(0) ip(10.0.0.82) r(1) ip(10.0.42.100)
runtime.totem.pg.mrp.srp.435324542.join_count=1
runtime.totem.pg.mrp.srp.435324542.status=joined
runtime.totem.pg.mrp.srp.983895584.ip=r(0) ip(10.0.0.87) r(1) ip(10.0.42.254)
runtime.totem.pg.mrp.srp.983895584.join_count=1
runtime.totem.pg.mrp.srp.983895584.status=joined

構成している各クラスターノードが status=joined になっているはずです。

Pacemaker の開始¶

corosync サービスが起動して、クラスターが正常に通信していることを確認した後、Pacemaker のマスター制御プロセス pacemakerd を起動できます。以下の 4 通りの方法からどれかを選択してください。

1. LSBinit スクリプトを用いた pacemaker の起動:

   # /etc/init.d/pacemaker start
   

   他の

   # service pacemaker start
   

2. upstart を用いた pacemaker の起動:

   # start pacemaker
   

3. systemd ユニットファイルを用いた pacemaker の起動:

   # systemctl start pacemaker
   

pacemaker サービスの起動後、Pacemaker がリソースを持たないデフォルトの空クラスターを作成します。 crm_mon ユーティリティーを使用して、pacemaker の状態を確認します。

# crm_mon -1
Last updated: Sun Oct  7 21:07:52 2012
Last change: Sun Oct  7 20:46:00 2012 via cibadmin on controller2
Stack: openais
Current DC: controller2 - partition with quorum
Version: 1.1.6-9971ebba4494012a93c03b40a2c58ec0eb60f50c
3 Nodes configured, 3 expected votes
0 Resources configured.


Online: [ controller3 controller2 controller1 ]
...