Corosync+Pacemaker高可用集羣構建過程詳解
[日期：2016-11-15] 來源：Linux社區 作者：purify [字體：大 中 小]
一、簡介
高可用集羣，是指以減少服務中斷（如因服務器宕機等引起的服務中斷）時間爲目的的服務器集羣技術。簡單的說，集羣就是一組計算機，它們作爲一個整體向用戶提供一組網絡資源。這些單個的計算機系統就是集羣的節點。
高可用集羣的出現是爲了減少由計算機硬件和軟件易錯性所帶來的損失。它通過保護用戶的業務程序對外不間斷提供的服務，把因軟件/硬件/人爲造成的故障對業務的影響降低到最小程度。如果某個節點失效，它的備援節點將在幾秒鐘的時間內接管它的職責。因此，對於用戶而言，集羣永遠不會停機。高可用集羣軟件的主要作用就是實現故障檢查和業務切換的自動化。
高可用集羣框架圖：
架構整體說明：
隨着互聯網技術的迅速發展很多大中小型公司已經離不開互聯網辦公及其提供服務，例如淘寶、美團等網站宕機幾個小時損失是致命的，很多網站對其高可用性越來越強，這就意味着運維人員需做到從硬件和軟件兩方面保證服務器的平均無故障時間減小，才能提高其可用性。corosync是一個集羣管理套件的部分，它在傳遞信息的時候可以通過一個簡單的配置來定義信息傳遞的方式和協議等，能實現資源間的高可用。目前，corosync功能和特性已經非常完善了，所以pacmaker獨立出來之後通常都將pacmaker和corosync結合來使用，corosync並沒有通用的資源管理器，因此要藉助pacmaker來實現，pacemaker是作爲corosync的插件來使用的，所以只需要在corosync配置文件中啓動pacemaker插件即可;但是真正啓動corosync並且配置它需要命令行接口進行調用，沒配置pcs那麼這裏我們只能使用crm工具來對其進行資源的管理。
架構詳細說明圖：
corosync集羣常見的組合方式及配置接口：
heartbeat v1 + hasource
heartbeat v2 + crm
heartbeat v3 + pacemaker + crmsh(corosync v1版本時沒有投票系統，corosync v2有投票系統，當系統發生網絡分區、腦裂時則將會將所有的資源轉移至可用的其他主機之上)
corosync v1 + pacemaker corosync v2 + pacemaker
cman +rgmanager corosync v1 + cman + pacemaker
CRM：集羣資源管理
資源類型：
primitive:基本資源，主資源，僅能運行一個節點
group:組，將組成一個高可用服務所需要的所有資源集合在一起
clone:克隆，同一資源科出現多份，可運行在多個節點
multi-state(master/slave):多狀態類型，是克隆資源的特殊表現，副本間可存在主從的關係
RA：資源代理
資源代理類別:
LSB:位於/etc/rc.d/init.d/*,支持start，stop，restart，reload，status，force-reload
注意：使用LSB資源類型的不能開機自動運行
OCF(open cluster framework)：/usr/lib/ocf/resource.d/provider/,類似於LSB的腳本，但僅支持start，stop，status，monitor，meta-data
STONITH:調用stonith設備的功能，systemd:unite ifle,/usr/lib/systemd/system/
注意：必須設置enable，設置爲開機自動啓動
資源約束方式：
位置約束：定義資源對節點的傾向性
排序約束：定義資源彼此能否運行在同一個節點的傾向性
順序約束：多個資源啓動順序的依賴關係
HA集羣常用的工作模型：
A/P：兩節點，active/passive，工作於主備模型
A/A：兩節點，active/active，工作於主主模型
N-M：N>M，N個節點，M個服務，假設每個節點運行一個服務，活動節點數爲N，備用節點數爲N-M
在集羣分裂(split-brain)時需要使用到資源隔離，有兩種隔離級別：
STONITH：節點級別的隔離，通過斷開一個節點的電源或者重新啓動節點
fencing：資源級別的隔離，類似通過向交換機發出隔離信號，特意讓數據無法通過此接口
當集羣分裂，即分裂後的一個集羣的法定票數小於總票數一半時採取對資源的控制策略
二、corosync安裝及其配置
安裝：
要求：1.基於主機名之間進行相互解析 2.各個節點之間時間需同步
安裝：yum -y install pacemaker (CentOS7)
corosync配置詳解：corosync的主要配置分爲totem、logging、quorum、nodelist配置段
totem { #定義各個節點之間的通信方式、加密與否，
version: 2 #指明totem的版本信息
cluster_name:myclusters #定義集羣名稱
crypto_cipher: aes128 #定義加密算法
crypto_hash: sha1 #定義hash算法
interface { #心跳及其事務傳遞接口
ringnumber: 0 #環接口號
bindnetaddr: 10.1.0.0 #綁定的網段
mcastaddr: 239.25.102.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 #開啓投票機制
}
nodelist { #節點列表
node {
ring0_addr: 10.1.10.65 #節點IP地址
nodeid: 1 #節點編號
}
node {
ring0_addr: 10.1.10.66 #節點列表
nodeid: 2 #節點編號
}
}
完成上訴配合後需生成密碼：corosync-kegen -l
將上訴配置文件和祕鑰文件拷貝至另一臺cluster即可。
啓動服務：
systemctl start corosync
systemctl start pacemaker
安裝crmsh接口工具來管理集羣資源及其配置：yum -y install 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
三、corosync+pacemaker+nfs實現高可用案例
此實驗需將另一臺服務器啓動nfs服務並掛載至兩節點上配置同樣的頁面文件
node 167840321: node1.alren.com \ #默認設置，此在corosync配置文件中定義
attributes standby=on
node 167840322: node2.alren.com \
attributes standby=off
primitive webip IPaddr \ #定義webip
params ip=10.1.10.80 \
meta target-role=Started
primitive webserver systemd:httpd #定義webserver
primitive webstore Filesystem \ #定義webstore
params device=”10.1.10.67:/www/html” directory=”/var/www/html” fstype=nfs \
op start timeout=60s interval=0 \ #附加選項爲超時時間、時間間隔
op stop timeout=60s interval=0
group webservice webip webstore webserver #將webip、webserver、webstore加入到webservice組
location cli-prefer-webservice webservice role=Started inf: node1.alren.com
property cib-bootstrap-options: \
have-watchdog=false \
dc-version=1.1.13-10.el7-44eb2dd \
cluster-infrastructure=corosync \
cluster-name=myclusters \
stonith-enabled=false \
symmetric-cluster=true
vim: set filetype=pcmk:
實驗測試圖：
將節點一手動設置爲standby模式，則資源會自動轉移至節點二
上訴配置可用排列約束和順序約束實現並且能實現節點之間的粘性和啓動順序
crm(live)configure# show
node 167840321: node1.alren.com \
attributes standby=on
node 167840322: node2.alren.com \
attributes standby=off
primitive webip IPaddr \
params ip=10.1.10.80 \
meta target-role=Started
primitive webserver systemd:httpd
primitive webstore Filesystem \
params device=”10.1.10.67:/www/html” directory=”/var/www/html” fstype=nfs \
op start timeout=60s interval=0 \
op stop timeout=60s interval=0
colocation webip_webserver_with_webstore inf: webip webserver webstore #設定排列約束
order webip_before_webstore_before_webserver Mandatory: webip webstore webserver #設定順序約束，此時啓動順序爲：webip,webstore,webserver
property cib-bootstrap-options: \
have-watchdog=false \
dc-version=1.1.13-10.el7-44eb2dd \
cluster-infrastructure=corosync \
cluster-name=myclusters \
stonith-enabled=false \
symmetric-cluster=true \
default-resource-stickiness=200
定義資源監控配置如下：當httpd服務停止時，將自動重啓httpd,如重啓失敗則將資源轉移至可用的節點
crm(live)configure# show
node 167840321: node1.alren.com \
attributes standby=off
node 167840322: node2.alren.com \
attributes standby=on
primitive webip IPaddr \
params ip=10.1.10.80 \
meta target-role=Started
primitive webserver systemd:httpd \
op start timeout=15s interval=0 \ #定義資源啓動間隔及其超時時間
op stop timeout=15s interval=0 \ #定義資源停止時間間隔及其超時時間
op monitor interval=15s timeout=15s #定義資源監控的時間間隔及其超時時間
primitive webstore Filesystem \
params device=”10.1.10.67:/www/html” directory=”/var/www/html” fstype=nfs \
op start timeout=60s interval=0 \
op stop timeout=60s interval=0
colocation webip_webserver_with_webstore inf: webstore webip webserver
order webip_before_webstore_before_webserver Mandatory: webip webstore webserver
property cib-bootstrap-options: \
have-watchdog=false \
dc-version=1.1.13-10.el7-44eb2dd \
cluster-infrastructure=corosync \
cluster-name=myclusters \
stonith-enabled=false \
symmetric-cluster=true \
default-resource-stickiness=200 \
no-quorum-policy=ignore \
last-lrm-refresh=1479180221
總結：綜合上訴的配置總體感覺corosync+pacemaker的方式實現高可用比lvs略微複雜，corosync同樣可實現對RS的健康狀態檢測，可藉助ldirectory實現自動生成ipvs規則