openstack controller ha測試環境搭建記錄（二）——配置corosync和pacemaker

corosync.conf請備份再編輯：
# vi /etc/corosync/corosync.conf

totem {
        version: 2

        token: 10000
        token_retransmits_before_loss_const: 10
        secauth: off
        rrp_mode: active

        interface {
                ringnumber: 0
                bindnetaddr: 10.0.0.0
                broadcast: yes
                mcastport: 5405
                ttl: 1
        }
        transport: udpu
}

nodelist {
        node {
                ring0_addr: 10.0.0.12
        }
        node {
                ring0_addr: 10.0.0.13
        }
}

logging {
        fileline: off
        to_stderr: no
        to_logfile: yes
        logfile: /var/log/cluster/corosync.log
        to_syslog: yes
        debug: off
        timestamp: on
        logger_subsys {
                subsys: QUORUM
                debug: off
        }
}

quorum {
        provider: corosync_votequorum
        two_node: 1
        wait_for_all: 1
        last_man_standing: 1
        last_man_standing_window: 10000
}

每一個節點都要編輯corosync.conf。
在兩個節點上都啓動corosync服務：
# systemctl enable corosync.service
# systemctl start corosync.service


在任一節點查看corosync服務的狀態：
# corosync-cmapctl runtime.totem.pg.mrp.srp.members
runtime.totem.pg.mrp.srp.members.167772172.config_version (u64) = 0
runtime.totem.pg.mrp.srp.members.167772172.ip (str) = r(0) ip(10.0.0.12)
runtime.totem.pg.mrp.srp.members.167772172.join_count (u32) = 1
runtime.totem.pg.mrp.srp.members.167772172.status (str) = joined
runtime.totem.pg.mrp.srp.members.167772173.config_version (u64) = 0
runtime.totem.pg.mrp.srp.members.167772173.ip (str) = r(0) ip(10.0.0.13)
runtime.totem.pg.mrp.srp.members.167772173.join_count (u32) = 2
runtime.totem.pg.mrp.srp.members.167772173.status (str) = joined
167772172是member id，其IP是10.0.0.12，狀態是joined；
167772173是member id，其IP是10.0.0.13，狀態是joined；
corosync服務狀態正確。


在兩個節點上都啓動pacemaker服務：
# systemctl enable pacemaker.service
# systemctl start pacemaker.service


查看服務啓動狀態：
# crm_mon
Last updated: Tue Dec  8 03:58:37 2015
Last change: Tue Dec  8 03:58:27 2015
Stack: corosync
Current DC: controller3 (167772173) - partition with quorum
Version: 1.1.12-a14efad
2 Nodes configured
0 Resources configured


Online: [ controller2 controller3 ]
pacemaker服務狀態很好。若是狀態很差，會出現「腦裂」現象。即在controller2和controller3分別運行crm_mon，看到的Current DC不是統一的，而是各自自己。出現此問題其中一種可能的緣由是開啓了防火牆。


在任一節點執行「crm configure」命令：
# crm configure property no-quorum-policy="ignore" pe-warn-series-max="1000" pe-input-series-max="1000" pe-error-series-max="1000" cluster-recheck-interval="5min"
默認的表決規則建議集羣中的節點個數爲奇數且不低於3。當集羣只有2個節點，其中1個節點崩壞，因爲不符合默認的表決規則，集羣資源不發生轉移，集羣總體仍不可用。no-quorum-policy="ignore"能夠解決此雙節點的問題，但不要用於生產環境。換句話說，生產環境仍是至少要3節點。
pe-warn-series-max、pe-input-series-max、pe-error-series-max表明日誌深度。
cluster-recheck-interval是節點從新檢查的頻率。

禁用stonith：
# crm configure property stonith-enabled=false
stonith是一種可以接受指令斷電的物理設備，測試環境無此設備，若是不關閉該選項，執行crm命令老是含其報錯信息。

查看配置：
# crm configure show


corosync和pacemaker狀態無誤，就能建立VIP資源了。個人VIP是「10.0.0.10」：
# crm configure primitive myvip ocf:heartbeat:IPaddr2 params ip="10.0.0.10" cidr_netmask="24" op monitor interval="30s"

------------------------------------------------------------------------------------------------------
/etc/corosync/corosync.conf
文件中的token含義是：
The token value specifies the time, in milliseconds, during which the Corosync token is expected to be transmitted around the ring. When this timeout expires, the token is declared lost, and after token_retransmits_before_loss_const lost tokens, the non-responding processor (cluster node) is declared dead. In other words, token × token_retransmits_before_loss_const is the maximum time a node is allowed to not respond to cluster messages before being considered dead. The default for token is 1000 milliseconds (1 second), with 4 allowed retransmits. These defaults are intended to minimize failover times, but can cause frequent 「false alarms」 and unintended failovers in case of short network interruptions. The values used here are safer, albeit with slightly extended failover times.

節點通信有兩種方式，一種是多播，一種是單播。我在測試中採用的是單播，即指定了nodelist。


多播方式配置：
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: 192.168.42.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和token_retransmits_before_loss_const相乘的結果決定了集羣的故障轉移時間。token的單位是毫秒。若是某個節點超過$(token*token_retransmits_before_loss_const)未響應，則被認爲節點死亡。
二、若是啓用了secauth選項，則節點間的通信使用128位密鑰加密，密鑰存儲在/etc/corosync/authkey，可使用corosync-keygen生成。
三、Corosync配置須要冗餘網絡（用到不僅一個網絡接口），必須採用RRR模式，
注意下述推薦的接口配置：
    3.一、每一個接口的配置必須有一個惟一的ringnumber，且起始數值爲0。
    3.二、bindnetaddr是你想要綁定的IP地址網段，
    3.三、多組播地址mcastaddr不能在跨越集羣的邊界重用，即歷來沒有兩個獨立的集羣使用了相同的多播組地址。多播組的地址必須遵循RFC 2365, 「Administratively Scoped IP Multicast」
    3.四、防火牆配置方面，Corosync僅須要UDP通訊，使用mcastport（接收）和mcastport - 1（發送）。
四、pacemaker服務能夠在corosync.conf中聲明，也能夠在/etc/corosync/service.d/pacemaker中聲明。
    注意：若是是在Ubuntu 14.04下的Corosync（version 2），須要註釋服務stanza中啓動pacemaker的命令。此外，要須要注意Corosync和Pacemaker的啓動順序，須要手動指定：
          # update-rc.d pacemaker start 20 2 3 4 5 . stop 00 0 1 6 .
          /etc/corosync/uidgid.d/pacemaker必須增長：
          uidgid {
              uid: hacluster
              gid: haclient
          }
五、注意全部節點上的corosync.conf和authkey都要保持同步。

六、service節點中，ver: 1表示corosync不自動啓動pacemaker。若是要corosync自動啓動pacemaker，設置ver爲0。因爲centos7沒有/etc/rc.d/init.d/pacemaker腳本（pacemaker服務在centos7中能夠用systemctl命令設置），故個人配置中沒有這個小節。可手動建立/etc/rc.d/init.d/pacemaker，與下一篇關於haproxy的文章中建立/etc/rc.d/init.d/haproxy腳本的方法相同。


單播方式配置：
totem {
        #...
        interface {
                ringnumber: 0
                bindnetaddr: 192.168.42.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: 192.168.42.1
                ring1_addr: 10.0.42.1
                nodeid: 1
        }
        node {
                ring0_addr: 192.168.42.2
                ring1_addr: 10.0.42.2
                nodeid: 2
        }
}

一、若是broadcast參數被設置成yes，廣播地址被用於通訊。若是使用了broadcast參數，就不要使用mcastaddr參數。
二、transport指令控制傳輸的方法。若是要徹底消除多播，指定udpu單播傳輸參數。這須要用nodelist指定成員列表。transport默認是udp，也能夠設置成updu或iba。
三、nodelist中的每一個節點，必須至少有一個ring0_addr字段，其它可能的選項有ring{X}_addr和nodeid，{X}是ring的序號，ring{X}_addr指定節點IP，nodeid是須要同時使用IPv4和IPv6時才指定。


votequorum方式配置
votequorum庫是Corosync項目中的一部分。採用votequorum是爲了不腦裂發生，以及：
    一、查詢quorum狀態；
    二、得到quorum服務所知道的節點列表；
    三、接收quorum狀態改變的通知；
    四、改變votes的數量，並分配域一個節點（Change the number of votes assigned to a node）
    五、Change the number of expected votes for a cluster to be quorate
    六、Connect an additional quorum device to allow small clusters remain quorate during node outages
votequorum庫被建立於用來替換和取代qdisk（表決盤）。
採用了votequorum配置的corosync.com以下：
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。
    expected_votes爲7表示，7個節點，quorum爲4。若是設置了nodelist參數，expected_votes無效。
    wait_for_all值爲1表示，當集羣啓動，集羣quorum被掛起，直到全部節點在線並加入集羣，這個參數是Corosync 2.0新增的。
    last_man_standing爲1表示，啓用LMS特性。默認這個特性是關閉的，即值爲0。這個參數開啓後，當集羣的處於表決邊緣（如expected_votes=7，而當前online nodes=4），處於表決邊緣狀態超過last_man_standing_window參數指定的時間，則從新計算quorum，直到online nodes=2。若是想讓online nodes可以等於1,必須啓用auto_tie_breaker選項，生產環境不推薦。
    last_man_standing_window單位爲毫秒。在一個或多個主機從集羣中丟失後，從新計算quorum。