Linux高可用集群方案之heartbeat基礎原理及邏輯架構

 這篇文章我們主要學習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（心臟起搏器）中?；贑entOS6.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三個主要的配置文件。

ha.cf配置文件部分參數詳解：

autojoin    none

#集群中的節點不會自動加入

logfile /var/log/ha-log

#指名heartbaet的日志存放位置

keepalive 2

#指定心跳使用間隔時間為2秒（即每兩秒鐘在eth2上發送一次廣播）

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

 本文到此先告一段落，歡迎大家指出其中的問題，后續還會不斷的完善。