這篇文章我們主要學習heartbeat高可用集羣的基礎原理及邏輯架構
ll 本文導航
· heartbeat之基本原理
· heartbeat之版本介紹
· heartbeat之相關術語
· heartbeat之集羣組件
· heartbeat之心跳連接
· heartbeat之配置文件
ll 要求
掌握heartbeat高可用集羣的相關組件及簡單配置
heartbeat之基本原理
heartbeat是一個集羣軟件，它主要由心跳信息檢測和資源管理兩大核心部分組成。
heartbeat構建的集羣中，各服務器會向其他集羣節點發送心跳信息（報文）並予以收集、分析，以判斷該節點的狀態，從而認爲節點是否有效。當服務器在指定的時長內檢測不到其他節點的心跳信息或無法通過網絡等方式連接時，會認爲對方節點失效，此時，服務器需要啓動資源接管模塊來接管失效節點上的服務和資源。
heartbeat僅能完成心跳信息檢測和資源監管，不會監視其他資源和應用服務。若要監控其他資源和應用服務是否可用，需要安裝第三方插件；如ipfail, ldirectord等。
同樣，對於操作系統自身的問題heartbeat同樣無法監控。若主節點因操作系統問題無法向備節點發送心跳信息，則備節點無法接收主節點的信息，從而認爲主節點已經失效，此時會啓動資源接管模塊來接管主節點的服務和資源。而主節點資源和服務並沒有釋放，此時主備節點會發生資源爭用的情況，嚴重時可能會導致共享資源的數據損壞或者文件系統的崩潰。對於linux系統而言，要解決這個問題，需要在內核中開啓watchdog模塊，開啓此模塊後，watchdog會定時向/dev/watchdog設備文件執行寫操作，從而確定系統是否正常運行。如果watchdog認爲內核掛起，就會自動重新啓動系統，從而釋放節點的服務和資源。
heartbeat之版本介紹
heartbeat分爲v1.x和v2.x兩個版本，最新的版本爲v3.x。
v2.x的版本是兼容v1.x的配置文件的，從功能的角度來看，v2.x要比v1.x強大很多。而v3.x則是v2.x的修訂版本，主要是修復v2.x中的一些bug，最重要的區別是將CRM資源管理器更改pacemaker，並將一些的模塊集成到了pacemaker（心臟起搏器）中。基於CentOS6.5，從安裝的角度來說，heartbeat-pils包與cluster-glue包衝突，如果使用yum安裝，則不會安裝安裝heartbeat-pils包的，默認是安裝cluster-glue包，但是heartbeat v2.x無法調用版本過高的cluster-glue包的。所以在安裝的時候，需要手動解決依賴關係。
1、heartbeat v1.x
v1.x的資源文件爲haresources，配置接口也較haresources。
heartbeat v1.x允許集羣和節點資源通過/etc/ha.d下的兩個文件進行配置。
ha.cf：定義集羣節點、失效檢測和切換的時間間隔，集羣日誌機制和Fence方法。
haresources：定義集羣資源組，每行可以定義失效切換的集羣節點和一組資源，資源包括IP地址、文
件系統、應用程序服務和存儲等。
2、heartbeat v2.x
heartbeat v2.x相較於v1.x做了很大的改動，引進了集羣資源管理器CRM，並且2.x基於CRM管理的
資源文件變更爲cib.xml。由於引進了CRM，在運行的heartbeat服務節點上，會獨立運行一個進程
crm，用戶可以同過此進程發送請求。而在server端，需要運行crmd進程，它監聽在一個套接字上，
端口是5560。用戶可以通過客戶端crm向server端發送請求，crm實際上是一個crm shell(crmsh)命
令行接口，用戶可以通過這個接口配置集羣服務；另外，heartbeat v2.x還增加了GUI圖形配置工具，
此模塊名稱就叫heartbeat-gui，用戶可以通過此工具在圖形化場景中配置集羣服務。
v2.x支持LSB、OCF、STONITH等形式的Resource Agent（資源代理）。
v2.x支持GUI圖形界面的配置和管理工具。
v2.x對多資源組進行獨立監控，不在需要mom或ldirctored等第三方腳本。
v1.x只支持雙節點，而v2.x基於CRM（Cluster Resource Manager）資源管理器模式最多支持16
個節點。該模式使用基於XML的CIB（Cluster Infomation Base）資源信息的配置。cib文件會在各節
點間自動複製，可以實現以下操作：
集羣節點的配置、監控；
集羣資源的粘性、約束、組和依賴性的配置；
日誌、監控、仲裁和Fence標準管理；
當服務失敗或設定的標準滿足時，需要執行某些動作；
3、heartbeat v3.x
在v3.x版本之後，heartbeat在功能上進行了拆分，每個功能模塊獨立開發爲不同的組件。在配置上，
與v2.x版本基本相同。其架構拆分爲heartbeat、pacemaker(心臟起搏器)、cluster-glue(集羣黏合
器)，它們可以結合其他的模塊工作。
heartbeat：負責維護集羣節點間的通信以及信息傳遞。
pacemaker：也就是CRM，它是管理HA的控制中心，客戶端通過它配置和監控整個集羣。
cluster-glue：相當於一箇中間件，它將heartbeat和pacmaker關聯起來，主要包含LRM和STONITH
resource agent：用於控制服務的啓動和停止，監控腳本服務的腳本集合；LRM調用這些腳本從而
實現資源的啓動、停止和重啓等。
heartbeat之相關術語
節點（node）
運行heartbeat進程的一個獨立主機，成爲節點；node是HA的核心組成部分,每個node上都運行各自獨立的操作系統和heartbeat服務。在heartbeat集羣軟件中，節點分爲主節點、備用/備份節點，主、備節點都有各自的hostname，並且擁有各自的一組資源。比如：文件系統、磁盤、ip地址和應用程序服務等。主節點一般運行的一個或多個服務，而備節點則屬於監控狀態。
資源（resource）
資源是節點中可控制的實體，當主節點發生故障時，備用節點將接管主節點上的資源。heartbeat服務中可以當作資源的實體有：
1、文件系統、磁盤分區；
2、NFS網絡存儲系統；
3、IP地址；
4、應用程序服務；如：httpd、mysqld等
事件（event）
事件是指集羣中可能發生的事情。比如：節點系統故障、網絡通信故障、網卡故障、應用程序故障等等，這些事件都可能會導致節點中的資源發生轉移。HA的測試也是基於這些事件來進行的。
動作（action）
動作是指事件發生時HA的響應方式，它是由shell腳本控制的。比如，當主節點發生故障後，備份節點將通過實現設定好的腳本來進行服務的關閉或啓動，從而接管故障節點的資源。
heartbeat之集羣組件
heartbeat：heartbeat軟件的整個通信模塊，所有節點之間的通信都是靠此模塊來完成。這個模塊會根據不同類型的通信啓動不同的事件handler，當監聽到不同的通信請求後會交給不同的handler處理。這一點從這個heartbeat日誌中可以看出來。
CCM（cluster consensus menbership）：集羣共識成員；它起到承上啓下的作用。監聽底層的心跳信息，當監聽不到心跳信息時，將重新計算這個集羣的票數和收斂狀態信息，並將結果發送給上層處理，上層將通過此結果採取何種決策。ccm還能生成一個集羣節點的拓撲概覽圖，以本節點爲參照，保證該節點在特殊情況下能夠採取相應的動作。
CRM（cluster resource manager）：集羣資源管理器，也就是pacemaker。它主要管理集羣節點服務的資源配置信息，實現對資源的分配與調度。根據資源的配置信息以及運行狀態，CRM決定資源該在哪個節點運行，但是，CRM並不直接參與動作，而是交給其他組件完成。CRM通過heartbeat組件收集到的各個成員節點的基本信息轉交給CCM來更新整個集羣的membership信息。指揮LRM對當前節點的各資源執行 start|stop|restart|status|monitor 等操作，同時接收LRM執行操作後的反饋信息並作出相應的決策進行後續工作。CRM還負責將各個組件反饋回來的信息通過調用設定的日誌記錄程序記錄進日誌文件中。
LRM（local resource manager）: 本地資源管理器；它是heartbeat中一個直接操作集羣管理中各個資源的模塊；負責對資源的啓動、停止、重啓或監控等；這個模塊目前支持4種resource agent，分別是：heartbeat自身、LSB、OCF、STONITH；四種類型調用的腳本位置如下：
heartbeat：/etc/ha.d/resource.d/
LSB：/etc/rc.d/init.d/
OCF：/usr/lib/resource.d/heartbeat/
STONITH（Shot The Other Node In The heat）：俗稱“爆頭”；這種方式是直接通過控制電源
開關執行關閉或重新啓動節點的方式。在heartbeat高可用集羣中，如果主節點因爲特殊原因無法與備節點響應心跳信息時，此時備節點會認爲主節點已經失效，會立即啓動資源接管模塊接管主節點上的資源，導致集羣中主備節點產生資源爭用的情況。爲了避免因資源爭用導致的文件損壞或文系統奔潰，此時，備節點接管資源後，就會通過網絡發送關機或重啓的命令給主節點，從而讓主節點釋放資源，這就是我們所說的“爆頭”。需要注意的是，STONITH機制需要硬件的支持。
LRM就是通過調用以上路徑下的各個腳本實現對資源的控制，腳本可以自行定義，只需要遵循特定的參數：start|stop|restart|status
PE（policy engine）: 策略引擎；主要負責將CRM發送過來的信息對比配置文件中的參數配置進行計算、分析，並將計算、分析出來的結果通過CRM發送給TE去分析後續需要執行的動作。PE需要計算、分析的信息主要是有哪些節點，各節點的狀態，當前管理了哪些資源，各資源當前運行在哪個節點，及資源在各個節點的狀態。
TE（translation engine）：主要分析PE的計算結果，然後根據配置信息轉換成後續所需的相應操作。
PE和TE並不直接通信，它們都是通過CRM來傳遞信息的，且PE和TE只有處在active的節點被啓動。
CIB（cluster infomation base）：集羣信息庫；CIB是集羣中的各資源配置、節點信息的初始狀態及變化後的蒐集中心，是一個不斷變化的信息庫。當集羣中資源、節點信息發生變化並被CIB收集到時，CIB會立即更新集羣信息庫並分發給其他節點，但是，分發動作並不是由CIB本身完成，而是有heartbeat組件完成的。CIB的配置文件名稱爲cib.xml，CIB在運行時，cib.xml中的配置信息常駐於DC（desginnated coordinator，主節點）的內存中，且只有DC纔會經常讀取並修改此文件的內容，以保證每個節點的各資源、節點信息的更新至最新狀態，其他節點上的cib.xml配置文件都是通過heartbeat組件從DC上覆制的。
heartbeat之心跳連接
heartbeat部署至少需要兩臺服務器完成。這兩臺服務器的心跳信息傳遞通過何種物理鏈路來進行連接呢？
1、串行線纜（首選，缺點是距離不能太長）
2、將一條以太網線連接兩臺服務器的網卡（推薦）
3、兩臺服務器連到同一交換機（次選，增加了交換機設備的故障率；同時，線路不是專用心跳線，容易受其他數據傳輸的影響）
heartbeat之配置文件
heartbeat的默認配置文件目錄爲/etc/ha.d/，此目錄下包含authkey、ha.cf、haresources三個主要的配置文件。
| 配置文件 | 作用 | 描述 |
| /etc/ha.d/authkey | heartbeat認證文件 | 高可用服務器對之間根據此文件對對端進行認證 |
| /etc/ha.d/ha.cf | heartbeat的基本參數配置文件 | 配置heartbeat的基本參數 |
| /etc/ha.d/haresources | heartbeat的資源配置文件 | 配置IP資源及腳本等 |
ha.cf配置文件部分參數詳解：
autojoin none
#集羣中的節點不會自動加入
logfile /var/log/ha-log
#指名heartbaet的日誌存放位置
keepalive 2
#指定心跳使用間隔時間爲2秒（即每兩秒鐘在eth1上發送一次廣播）
deadtime 30
#指定備用節點在30秒內沒有收到主節點的心跳信號後，則立即接管主節點的服務資源
warntime 10
#指定心跳延遲的時間爲十秒。當10秒鐘內備份節點不能接收到主節點的心跳信號時，就會往日誌中寫入一個警告日誌，但此時不會切換服務
initdead 120
#在某些系統上，系統啓動或重啓之後需要經過一段時間網絡才能正常工作，該選項用於解決這種情況產生的時間間隔。取值至少爲deadtime的兩倍。
udpport 694
#設置廣播通信使用的端口，694爲默認使用的端口號。
baud 19200
#設置串行通信的波特率
bcast eth0
# Linux 指明心跳使用以太網廣播方式，並且是在eth0接口上進行廣播。
#mcast eth0 225.0.0.1 694 1 0
#採用網卡eth0的Udp多播來組織心跳，一般在備用節點不止一臺時使用。Bcast、ucast和mcast分別代表廣播、單播和多播，是組織心跳的三種方式，任選其一即可。
#ucast eth0 192.168.1.2
#採用網卡eth0的udp單播來組織心跳，後面跟的IP地址應爲雙機對方的IP地址
auto_failback on
#用來定義當主節點恢復後，是否將服務自動切回，heartbeat的兩臺主機分別爲主節點和備份節點。主節點在正常情況下佔用資源並運行所有的服務，遇到故障時把資源交給備份節點並由備份節點運行服務。在該選項設爲on的情況下，一旦主節點恢復運行，則自動獲取資源並取代備份節點，如果該選項設置爲off，那麼當主節點恢復後，將變爲備份節點，而原來的備份節點成爲主節點
#stonith baytech /etc/ha.d/conf/stonith.baytech
# stonith的主要作用是使出現問題的節點從集羣環境中脫離，進而釋放集羣資源，避免兩個節點爭用一個資源的情形發生。保證共享數據的安全性和完整性。
#watchdog /dev/watchdog
#該選項是可選配置，是通過Heartbeat來監控系統的運行狀態。使用該特性，需要在內核中載入"softdog"內核模塊，用來生成實際的設備文件，如果系統中沒有這個內核模塊，就需要指定此模塊，重新編譯內核。編譯完成輸入"insmod softdog"加載該模塊。然後輸入"grep misc /proc/devices"(應爲10)，輸入"cat /proc/misc |grep watchdog"(應爲130)。最後，生成設備文件："mknod /dev/watchdog c 10 130" 。即可使用此功能
node node1.magedu.com
#主節點主機名，可以通過命令“uanme –n”查看。
node node2.magedu.com
#備用節點主機名
ping 192.168.12.237
#選擇ping的節點，ping 節點選擇的越好，HA集羣就越強壯，可以選擇固定的路由器作爲ping節點，但是最好不要選擇集羣中的成員作爲ping節點，ping節點僅僅用來測試網絡連接
ping_group group1 192.168.12.120 192.168.12.237
#類似於ping ping一組ip地址
apiauth pingd gid=haclient uid=hacluster
respawn hacluster /usr/local/ha/lib/heartbeat/pingd -m 100 -d 5s
#該選項是可選配置，列出與heartbeat一起啓動和關閉的進程，該進程一般是和heartbeat集成的插件，這些進程遇到故障可以自動重新啓動。最常用的進程是pingd，此進程用於檢測和監控網卡狀態，需要配合ping語句指定的ping node來檢測網絡的連通性。其中hacluster表示啓動pingd進程的身份。
#下面的配置是關鍵，也就是激活crm管理，開始使用v2 style格式
crm respawn
#注意，還可以使用crm yes的寫法，但這樣寫的話，如果後面的cib.xml配置有問題
#會導致heartbeat直接重啓該服務器，所以，測試時建議使用respawn的寫法
#下面是對傳輸的數據進行壓縮，是可選項
compression bz2
compression_threshold 2
本文到此先告一段落，歡迎大家指出其中的問題，後續還會不斷的完善。