HA cluster應用—CoroSync+Pacemaker

HA cluster應用——CoroSync v2 （quorum system）+Pacemaker （standalone daemon）+ crmsh/pcsh

corosync簡述：

Corosync是OpenAIS發展到Wilson版本后衍生出來的開放性集群引擎工程?？梢哉fCorosync是OpenAIS工程的一部分。OpenAIS從openais0.90開始獨立成兩部分，一個是Corosync；另一個是AIS標準接口Wilson。Corosync包含OpenAIS的核心框架用來對Wilson的標準接口的使用、管理。它為商用的或開源性的集群提供集群執行框架。Corosync執行高可用應用程序的通信組系統，它有以下特征：

（1）一個封閉的程序組（A closed process group communication model）通信模式，這個模式提供一種虛擬的同步方式來保證能夠復制服務器的狀態。

（2）一個簡單可用性管理組件（A simple availability manager），這個管理組件可以重新啟動應用程序的進程當它失敗后。

（3）一個配置和內存數據的統計（A configuration and statistics in-memory database），內存數據能夠被設置，回復，接受通知的更改信息。

（4）一個定額的系統（A quorum  system）,定額完成或者丟失時通知應用程序。

總結：Corosync是整合底層節點服務器，提供API個pacemaker的一個中間層

 pacemaker簡述：

pacemaker，是一個群集資源管理器。它實現最大可用性群集服務（亦稱資源管理）的節點和資源級故障檢測和恢復使用您的首選集群基礎設施（OpenAIS的或Heaerbeat）提供的消息和成員能力。
它可以做乎任何規模的集群，并配備了一個強大的依賴模型，使管理員能夠準確地表達群集資源之間的關系（包括順序和位置）。幾乎任何可以編寫腳本，可以管理作為心臟起搏器集群的一部分。

 pacemaker支持超過16個節點的控制

（1）時間同步；

        建議自建一個時間同步服務器，如果使用外網的時間同步服務器，會增加網絡報文，或多或少有誤差

（2）集群內所用主機都是基于主機名進行通信，建議使用hosts文件進行主機名解析

用DNS作為主機名解析，DNS服務器有可能會宕機，有可能會延遲，但是高可用集群就是為了出現故障的時候快速進行相應；有一些高可用集群會有嚴格要求，解析過來的主機名與對方使用真正使用的主機名必須保持一致，而DNS解析只需要名字與IP保持一致就行了，要求較低。

（3）使用獨立的多播地址，避免與其他集群使用相同的多播地址

由于集群服務的機器較多，建議配置ansible，所用ansible批量安裝和配置corosync與pacemaker：

安裝并修改ansible中的host文件，將添加集群的主機IP：

 

使用ssh-keygen生成私鑰以及公鑰：

 

使用ansible模塊將公鑰批量分發到個節點機（客戶端）：

ansible all -m authorized_key -a “user=root key='{{ lookup(‘file’, ‘/root/.ssh/id_rsa.pub’) }}’ path=/root/.ssh/authorized_keys manage_dir=no” –ask-pass -c paramiko

 

將hosts文件發送至個節點，以及使用ntpdate命令，進行各節點的時間同步：

 ~]# ansible cluster -m copy -a “src=/etc/hosts dest=/etc/hosts”

~]# ansible all -m shell -a “ntpdate“

安裝corosync，pacemaker

由于兩個包都在base倉庫，所以直接使用yum安裝

   ~]# yum install -y corosync pacemaker

            ——————————————————————————————–

corosync的程序環境

配置文件

文本格式的配置文件，建議使用：/etc/corosync/corosync.conf.example

使用UDP協議的精簡版corosync，建議不使用：/etc/corosync/corosync.conf.example.udpu

xml格式的配置文件，建議不使用：/etc/corosync/corosync.xml.example

密鑰文件，默認安裝是不會生成的，需要手動生成，而且該文件是一個二進制文件，目的是為了區分同一網絡內的節點有配有相同配置的服務器：/etc/corosync/authkey

集群信息庫，每節點都會自動的同步，除了authkey文件：/var/lib/corosync

       totem { } 節點間的通信協議，主要定義通信方式、通信協議版本、加密算法等 ；

             interface{}:定義集群心跳信息傳遞的接口，可以有多組；在Interface內，有四個必選參數，一個可選參數；多個網卡參與集群事務信息傳遞，則需要定義多個Interface，只是ringnumber，多播地址，網絡地址不能一樣

ringnumber      #用來標記當前Interface在當前totem上的環狀號碼，以避免出現環狀信息進入死循環，必須從0開始標記

bindnetaddr      #綁定的網絡地址或者主機IP地址，用于集群事務信息通信的網絡地址

mcastaddr         #多播地址，要避免使用224開頭的地址

mcastport         #多播地址，在實現多播發送信息時，所用的端口

ttl                        #一個報文能被中繼發送多少次，一般設置為1，不允許中繼

broadcast            #廣播地址，可選，如果使用的多播地址進行集群有關的信息傳遞，則無需使用廣播的方式了

                        version                  #指明配置文件的版本，目前取值僅有2一項可用；

               crypto_hash         #通訊加密hash算法的類型默認是sha1，支持md5,  sha1,  sha256,  sha384  和sha512

               crypto_cipher      #對稱加密算法類型，默認是aes256，支持aes256, aes192, aes128 and 3des，但是依賴于crypto_hash；但是越復雜的算法，越是消耗時鐘周期

               secauth                     #各節點彼此通信時是否需要驗證彼此身份，支持HMAC/SHA1兩種方法，默認是ON，但是crypto_hash和crypto_cipher設置好了，該項也無需顯式指明。

              

            —————————————–

       logging { } 定義日志信息

                to_stderr            #記錄到系統日志中

                to_logfile            #記錄到指定的日志文件中

                to_syslog         #記錄到syslog系統中         這三種方法只需要使用一種就行了，無需重復記錄

            —————————————–

       quorum { } 定義投票系統

                provider     #指明使用哪種算法進行投票系統，目前只支持corosync_votequorum

            —————————————–

       nodelist { } 節點列表，會自動生成，無需手動配置

                    nodeid     #指明節點id

            —————————————–

       qb { } 

               與libqb配置有關的配置項，一般無需配置

生成authkey：

         corosync-keygen [-k <filename>] [-l]

                -k 指明生成的密鑰文件存放的位置

                -l 指明隨機數生成器，默認使用熵池，熵池用緊，會使用偽隨機數生成器；使用偽隨機數生成器會阻塞，解決方法，下載文件，會有大量IO，也會填充到熵池中  

 

                     —————————————–

配置示例：

totem {

version: 2

crypto_cipher: aes256 

crypto_hash: sha1

interface {

ringnumber: 0

bindnetaddr: 10.1.35.1

mcastaddr: 239.255.35.1

mcastport: 5405

ttl: 1

}

}

logging {

fileline: off

to_stderr: no

to_logfile: yes

logfile: /var/log/cluster/corosync.log

to_syslog: no

debug: off

timestamp: on            #時間戳標簽，如果記錄到系統日志，則無需開啟

logger_subsys {        #是否記錄子系統日志

subsys: QUORUM        #記錄選舉系統日志

debug: off                    #關閉調試模式

}

}

quorum {

provider: corosync_votequorum

        #two_node: 1          #如果是兩節點集群，顯式定義

}

nodelist {

node {

ring0_addr: node1.hunter.com

nodeid: 1

}

node {

ring0_addr: node1.hunter.com

nodeid: 2

}

node {

ring0_addr: node1.hunter.com

nodeid: 3

}

}

~ ]# scp authkey corosync.conf 10.1.35.2:/etc/corosync/

~ ]# scp authkey corosync.conf 10.1.35.25:/etc/corosync/

                     —————————————–

            啟動服務：systemctl start corosync.service

                 udp的5404端口是用特殊用途：是完成選舉DC的重要通道

                 udp的5405是corosync正常工作監聽的端口

                 

                     —————————————–

驗正服務啟動：

(1) 查看日志；

(2) corosync-cmapctl  |    grep members 

        corosync-cmapctl 查看對象數據信息（CID）

(3) corosync-cfgtool：管理工具；

-s：顯示當前節點各ring相關的信息；

-R：控制所有節點重載配置；

pacemaker：

程序環境：

配置文件：/etc/sysconfig/pacemaker

主程序：/usr/sbin/pacemakerd

Unit File：pacemaker.service

啟動服務：

systemctl start pacemaker.service 

監控服務啟動是否正常：

# crm_mon 

pacemaker提供的工具

由于pacemaker提供的的工具都是一些底層工具，用起來過于麻煩，建議使用crmsh，只需要一個控制節點安裝即可   （也可以在多個節點上安裝進行控制）

                     ===================================================================

crmsh安裝

crmsh-2.1.4-1.1.x86_64.rpm

pssh-2.3.1-4.2.x86_64.rpm

python-pssh-2.3.1-4.2.x86_64.rpm

                     —————————————–

配置接口（crmsh/pcs）

crmsh：

運行方式：

交互式方式：

                              crm(live)#

命令方式：

crm COMMAND

獲取幫助：ls, help

   help [KEYWORD]

COMMAND：#凡是帶有/的都表示有子命令

cd             Navigate the level structure

help           Show help (help topics for list of topics)

ls             List levels and commands

quit           Exit the interactive shell

report         Create cluster status report

status         Cluster status

up             Go back to previous level

cib/           CIB shadow management

cibstatus/     CIB status management and editing

 cluster/       Cluster setup and management

 configure/     CIB configuration      主配置工具

 assist/        Configuration assistant   配置輔助工具，一般比較少用

 history/       Cluster history，顯示歷史狀態信息

 ra/            Resource Agents (RA) lists and documentation，顯示RA信息

 template/      Edit and import a configuration from a template，定制模板

 corosync/      Corosync management，corosync 管理器

 node/          Nodes management      節點狀態控制

 options/       User preferences，用戶配置

 resource/      Resource management（ra資源管理器）

 script/        Cluster script management         腳本管理

 site/          Site support，報告站點相關信息

configure命令：

Finally, there are the cluster properties, resource meta attributes defaults, and operations defaults. All are just a set of attributes. These attributes are managed by the following commands:

– property

– rsc_defaults

– op_defaults

Commands for resources are:

– primitive

– monitor

– group

– clone

– ms/master (master-slave)

There are three types of constraints:

– location

– colocation

– order   

設置集群的全局屬性：property 

stonith-enabled=true|false

定義一個primitive資源的方法：

primitive <rsc> {[<class>:[<provider>:]]<type>} [params attr_list] [op op_type [<attribute>=<value>…] …]

op_type :: start | stop | monitor

定義一個組資源的方法：

group <name> <rsc> [<rsc>…]

<rsc>：資源的ID，字符串；

[<class>:[<provider>:]]<type>

定義資源監控：

(1) monitor <rsc>[:<role>] <interval>[:<timeout>]

            使用monitor命令，指定要監控的資源<rsc>，指定監控的時間間隔<interval>，該資源的超時時間<timeout>

(2) primitive <rsc> {[<class>:[<provider>:]]<type>} [params attr_list] [op monitor interval=# timeout=#]

如果在使用primitive創建資源的時候，則無需指明監控的資源<rsc>

ra:

Commands:

cd             Navigate the level structure

classes        List classes and providers

help           Show help (help topics for list of topics)

info           Show meta data for a RA

list           List RA for a class (and provider)

ls             List levels and commands

providers      Show providers for a RA and a class

quit           Exit the interactive shell

up             Go back to previous level

                     —————————————–

常用命令：

classes：類別列表

list CLASSES [PROVIDER]：列出指定類型(及提供者)之下的所有可用RA；

info [<class>:[<provider>]:]]<type>：顯示指定的RA的詳細文檔；

                     —————————————–

資源約束關系的定義：

位置約束：

location <id> rsc  <score>:  <node>

<score>：

#, -#

inf, -inf 

property default-resource-stickiness

排列約束：

colocation <id> <score>:  <rsc>  <with-rsc>

順序約束：

order <id> [{kind|<score>}:] first then [symmetrical=<bool>]

kind :: Mandatory（強制） | Optional（可選） | Serialize（序列化，按順序停止啟動）

symmetrical（默認是對稱的，先啟動的最后停止）

resource：資源管理命令

migrate   遷移資源

start         啟動資源

stop         停止資源

status      資源狀態查看

cleanup   清理資源中間狀態（中間狀態可以有助于對故障的判斷，但是有時候需要清理完之后才能重啟資源）

        首先，由于沒有stonith設備（軟硬件設備均沒有），所有使用verify查看配置文件是否正確時，會報錯，所以，先將stonith關閉

配置虛擬地址-VIP   

    crm(live)configure# primitive webip ocf:heartbeat:IPaddr params ip=”10.1.35.99″ nic=”eno16777736″ cidr_netmask=”16″ broadcast=”10.1.255.255″

 在命令行模式，使用命令ip a l   可以查看，此時VIP以復制地址的形式配置在指定的網卡上了

 

添加httpd服務：

crm(live)configure# primitive webserver systemd:httpd

crm(live)configure#commit

默認情況下，集群運行資源是以盡量平均分配資源到各節點為目的的，但是高可用服務需要這兩個資源要在一起才有意義，可以使用排列約束或者位置約束

定義組，使用排列約束：

crm(live)configure# group webgroup webserver webip

 

crm(live)# status

 使用命令status，此時webip與webserver已經運行在同一個ra上了

此時使用命令請求頁面，是在node25上

 然后standby node25.hunter.com后再次請求頁面：

 資源已經遷移到node1上；

                     —————————————–

刪除資源：

刪除資源需要先停止資源；可以進入resoource；

resource  –>  stop webserver   –>  cd –>  configure  –>  delete webserver –> show 

檢查是否已經成功刪除

 

定義共享文件系統：

primitive webstore ocf:heartbeat:Filesystem params device=”10.1.35.25:/data/web” directory=”/var/www/html” fstype=”nfs” op start timeout=60s op stop timeout=60s

由于默認的超時時間是20秒，所以還需要op超時，重新指點超時時間 

 

 按正常順序進行排列（先掛載文件系統，然后啟動httpd服務，最后設定VIP）

添加資源監控：

由于此時已經創建了資源，則直接使用monitor添加監控規則：

 定義完之后需要verify檢查是否符合標準，如果不符合，此時可以直接使用edit直接修改，沒有問題則可以提交

當使用命令killall httpd，監控程序會在指定的時間（60秒檢查一個，超時時間為30秒）監測，如果資源不在線，默認會重啟服務，如果重啟不成功，則會將資源遷移到其他節點上

位置約束：（資源與節點的關系）

location <id> rsc  <score>:  <node>

使用location定義一個<id>，指明資源 rsc 對節點<node>的<score>依賴程度

<score>：

#, -#

inf, -inf 

property default-resource-stickiness=<score>                #資源默認對當前的黏性程度為score

即：如果資源的傾向性無法大于資源對節點的黏性的話，資源還是會停留在當前節點之上

例子：

使用location定義webstore對節點1的傾向性為正無窮：

crm(live)configure# location webstore_perfer webstore inf: node1.hunter.com

 

如果再定義webserver對node1的傾向性對node1服務的傾向性為負無窮，且將這兩個服務定義在一個組，會有什么現象？

 將webstore定義在node1節點為負無窮，webserver定義在node1節點為正無窮，且將兩個資源定義在同一個組內

 將出節點1之外的全部節點都standby，那么，該組的資源是不會啟動的，及將一個正無窮資源與一個負無窮資源放一起是沒有辦法啟動的

排列約束（資源與資源的傾向性的關系）：

colocation <id> <score>:  <rsc>  <with-rsc>…..     #使用命令colocation，定義一個約束名稱<id>，指明資源1<rsc>與資源2<with-rsc>….在一起的傾向性<score>；注意<with-rsc>可以有多個

順序約束（資源啟動的先后順序）：

order <id> [{kind|<score>}:] first then [symmetrical=<bool>]

kind :: Mandatory（強制） | Optional（可選） | Serialize（序列化，按順序停止啟動）

symmetrical（默認是對稱的，先啟動的最后停止）

        使用命令order，定義一個順序約束的名字<id>，指明kind的類型（是強制的，還是可選的，還是序列化），最后列出資源的啟動順序

crm(live)configure# order weboeder Mandatory webstore webserver webip