What is the Linux High Availabi

What is the Linux High Availabi前端

   簡介:node

    高可用性羣集的出現是爲了使羣集的總體服務儘量可用,以便考慮計算硬件和軟件的易錯性。若是高可用性羣集中的主節點發生了故障,那麼這段時間內將由次節 點代替它。次節點一般是主節點的鏡像,因此當它代替主節點時,它能夠徹底接管其身份,而且所以使系統環境對於用戶是一致的。linux

wKiom1NPxuqzdRgeAAHtJv7-4y8681.jpg

什麼叫心跳:就是將多臺服務器用網絡鏈接起來,然後每一臺服務器都不停的將本身依然在線的信息很簡短很小的通告給同一個網絡中的備用服務器的主機,告訴其實主機本身依然在線,其它服務器收到這個心跳信息就認爲本機是在線的,尤爲是主服務器。

心跳信息怎麼發送,由誰來收,其實就是進程中的通訊兩臺主機是無法通訊的,只能利用網絡功能,經過進程監聽在某一套接字上,實現數據發送,數據請求,因此多臺服務器就得運行同 等的進程,這兩個進程不停的進行通訊,主節點(主服務器)不停的向對方同等的節點發送本身的心跳信息,那這個軟件就叫高可用的集羣的基準層次,也叫心跳信 息傳遞層以及事物信息的傳遞層,這是運行在集羣中的各節點上的進程,這個進程是個服務軟件,關機後須要將其啓動起來,主機間才能夠傳遞信息的,通常是主節 點傳給備節點。在每一個節點上,CRM維護羣集信息庫 (CIB),包含全部羣集選項、節點、資源及其關係和當前狀態的定義。若是選擇羣集中的CRM爲指定協調 程序(DC),則意味着它具備主CIB。羣集中的全部其餘CIB是此主CIB的 複本。對CIB的常規讀寫操做經過主CIB進行排序。DC是羣集中惟一能夠 決定須要在整個羣集執行更改(例如節點屏障或資源移動)的實體。
羣集信息庫(CIB)
羣集信息庫是整個羣集配置和當前狀態在內存中的XML表示。它包含全部 羣集選項、節點、資源、約束及其之間的關係的定義。CIB還將更新同步到 全部羣集節點。羣集中有一個主CIB,由DC維護。全部其餘節點包含一個CIB副本.web

 

策略引擎(PE)算法

每當指定協調程序需呀進行整個鮮集的更改(對新CIB作出反應),策略引擎就會根據羣集的當前狀態和配置計算集羣的下一個狀態,PE還生成個轉換圖,包含用於達到下一個羣集狀態的(資源)操做和依賴性的列表,PE在每一個節點上都運行以加速DC故障轉移。shell

 

本地資源管理器(LRM)vim

LRM 表明CRM調用本地資源代理.所以它能夠執行啓動/中止/監視操做並將結果報告給CRM。它還隱藏資源代理支持的腳本標準(OCF、LSB、Heartbeat VI)之間的區別。LRM是其本地節點上全部資源相關信息的權威來源.api

 

資源層安全

最高層是資源層。資源層包括一個或多個資源代理(RA)。資源代理是爲啓動、 中止和監視某種服務(資源) 而編寫的程序,一般是服務控制腳本。資源代理僅由LRM調用。第三方可將他們本身的代理放在文件系統中定義的位皆,這樣就爲各自的軟件提供了現成羣集集成.所謂的資源:以web爲例,vip是資源,web服務也是資源,還有網頁面也是資源,一個服務包括多個資源,而像web的共享存儲也是資源等等,不一樣的服務所須要的資源也是不一樣的,而共享存儲是高可用集羣中最難解決的問題。如是主節點掛了,多個備節點怎麼樣來選擇一個備節點來作爲提供服務的一個節點呢,而這種應該選擇哪一個備用節點來作爲提供服務的機制就叫作集羣事物決策的過程ha_aware:若是一個應用程序本身可以利用底層心跳信息傳遞層的功能完成集羣事物決策的過程的軟件就叫ha_aware。   DC:Designated Coordinator選定的協調員,當DC所在的主機掛了就會先選出一個DC,再由DC作出事物的決策。注意:在高可用集羣中最核心的、最底層的管理的單位叫資源,把資源組合在一塊兒來組合成一個服務。高可用集羣中任何資源都不該該自行啓動,而是由CRM管理啓動啓動的;CRM:Cluster Resources Manager集羣資源管理,真正作出決策的是CRM。bash

heartbeat v1版時就有了資源管理的概念,而v1版的資源就是heartbeat自帶的,叫haresources,這個文件是個配置文件;而這個配置文件接口就叫haresources;

heartbeat v2第二版的時候,heartbeat被作了很大的改進,本身能夠作爲一個獨立進程來運行,並而能夠經過它接收用戶請求,它就叫crm,在運行時它須要在各節點上運行 一個叫crmd的進程,這個進程一般要監聽在一個套接字上,端口就是5560,因此服務器端叫crmd,而客戶端叫crm(能夠稱爲crm shell),是個命令行接口,經過這個命令行接口就能夠跟服務器端的crm通訊了,heartbeat也有它的圖形化界面工具,就叫 heartbeat-GUI工具,經過這個界面就能夠配置進行。

第三版heartbeat v3,被獨立成三個項目heartbeat、pacemaker(心臟起博器)、cluster-glue(集羣的貼合器),架構分離開來了,能夠結合其它的組件工做了。

RA:resource agent資源代理,其 實就是可以接收CRM的調度用於實如今節點上對某一個資源完成管理的工具,這個管理的工具一般是腳本,因此咱們一般稱爲資源代理。任何資源代理都要使用同 一種風格,接收四個參數:{start|stop|restart|status},包括配置IP地址的也是。每一個種資源的代理都要完成這四個參數據的輸 出。
   當某一個節點出現故障時,其上面的資源被自動轉移到其它正常的備用節點上並啓動的這個過程叫故障轉移,也稱爲失效轉移(failover)
   若是出現故障的節點又回來的,那咱們就要把這個節點添加回來,那這個添加回來的過程咱們就叫失效轉回,也稱故障轉回(failback)

資源爭用、資源隔離:
   萬一集羣發生分裂時,爲了不再也不成爲集羣上的節點繼續使用資源而發生資源爭用狀況,致使有掛載文件系統的系統文件發生崩潰,成爲新的集羣的就會給再也不成爲集羣的節點補一槍,讓不是集羣節點的服務死透,再也不接收請求,這就叫stonith(shoot the other node in the head),而這種功能就叫資源隔離。爭用共享存儲的後果是很是嚴重的,輕則共享存儲崩潰,重則整個文件系統都崩潰,數據所有丟失。


資源隔離有兩種級別:
   節點級別:這種就叫STONITH,這種就是無論怎麼樣直接把對方的電源給切斷,通常這種主機都是鏈接到電源交換機上的。
   資源級別:這種須要依賴一些硬件設備來完成,好比鏈接到共享存儲的光纖交換機,把須要踢除出去的節點的光纖接口屏蔽了,這種就叫資源級別的隔離。
   對於服務器左右分隔的這種狀況一般稱爲腦裂(brain-split),左右不協調了,在高能夠用集羣中避免資源爭用完成資源隔離是咱們在設計高可用集羣中必需要考濾的問題。

   兩個節點的模式下,一旦發生集羣分隔之後,其中一個節點發生故障,在咱們沒法斷定哪一個節點不正常的時候,而正常的節點必定是能夠連到互聯網上去的,這樣的話就說明正常的節點是能夠跟前端路由通訊的,因此咱們就把前端路由當成第三個節點,這裏咱們稱爲ping節點,當每一個節點聯繫到對方以後先去ping前端的節點,若是能夠ping通,那就說明本身是正常的,就說明該節點是有多票法定票數的節點,而前端的ping節點就叫仲裁設備,幫助節點判斷哪一個節點是優勝一方的,偶數節點數時就會藉助於仲裁設備。
   RHCS不是使用ping節點來判斷的,他是使用了一個共享存儲的設備,偶數個節點處於活動的節點不斷的往磁盤中寫數據,按照心跳信息頻率每隔一個信息頻率就往磁盤裏寫一個數據位,只要這個設備每隔一個心跳時間間隔就更新一次數據位,就說明這個設備處於活動狀態的,若是發現節點屢次沒有寫數據位了就認爲節點掛了,這種也叫仲裁設備(qdisk)。仲裁設備又有兩種:分別爲ping node和qdisk;

那心跳是怎麼傳遞的呢,在多臺主機之機又是怎麼互相工做良好呢,如圖:高可用主從的兩個節點;

wKiom1NXJgWSL8J2AALpfiAJ3U8039.jpg

   信息層(Messaging Layer):主從兩個節點的心跳信息都要基於信息層來實現,也叫底層基礎架構層,用於傳遞心跳信息的,而可以實現這種功能的有Corosync和heartbeat,corosync是openAIS的一個組件,
   資源分配層(Resource Allocation):也叫資源管理器層,這層的核心組件叫CRM(Cluster Resourcce Manager集羣資源管理器),CRM上必須有一個資源被推舉成爲管理者的,叫Leader,它的工做是決策集羣中的全部事物的,這裏稱爲DC(Designated Coordinator指定協調員),任何DC上會額外運行兩個進程,一個叫PE(Policy Engine策略引擎),所謂策略引擎就是將底層信息層收集整個集羣中全部節點上的信息在本地生成一個大圖big pic來策略節點運行在哪一個節點上,並通知其實節點上的資源管理器來實現資源的啓動和關閉等操做;一個叫TE(Transition Engine 傳輸引擎),它主要是把PE作出的決策通告給對應節點的CRM;
   集羣資源管理器必須藉助於Messageing Layer通告給每個節點,自動的廣播或組播給每個節點,這樣就保證了每個節點上的信息都是同樣的,而這些數據在計算機中又怎麼樣來交互數據的呢,這裏就要基於擴展標記語言來實現數據的格式傳遞的,這種叫半結構化數據基於XML的,因此在各節點之間實現配置信息保存都是經過XML文件保存的,而要可以理解這個XML文件保存的信息使用到一個工具叫CIB(Cluster Information Base集羣信息庫);只要能鏈接到CRM上均可以去配置這個XML文件,首先它會先保存到DC的XML中,而後再由DC同步支每一個節點上的XML文件中去的;
   Resources層:而 PE(策略引擎)就是根據XML這個庫來獲取資源的配置信息的,並經過Messaging Layer不獲取當前節點的活動信息,然後作出決策,一旦作得決策就要啓動資源了;因此PE藉助於本地的Messaging Layer通知給其實節點的集羣信息庫來實現對某些資源信息的傳遞,好比說通告其它CRM要啓動某一資源了,收到信息後CRM並不負責啓動,轉由 LRM(Local Resource Manager本地資源管理)啓動,每一個節點上都運行在這個LRM,而併發資源又藉助於RA(Resource Agent資源代理)實現資源管理,這就是它的工做原理;CRM負責收集信息,推舉爲DC的由PE運行,PE負責整合整個集羣中的全部資源,並確保某些資 源在合適的節點上運行起來,一旦作出決策就會通告給其它節點上的CRM,對應節點上的CRM收到通告之後會調用本身的LRM,由LRM指揮RA完成相關的操做;

處理流程:

    linux 高可用 使用 Pacemaker做爲CRM, CRM做爲守護程序執行(crmd),它在每一個集羣節點上都有一個實例。Pacemaker 經過將某個crmd實例選爲主實例,從而集中了全部的羣集決策制定。若是選定的crmd進程(或它所在的節點)出現故障,則將創建一個新的進程。

在每一個節點上保留了一個CIB,它反映了羣集的配置和羣集中全部資源的當前狀態。CIB的內容會在整個羣集的同步過程當中自動保留下來。
羣集中執行的許多操做都將致使整個羣集的更改。這些操做包括添加或刪除羣集資源、更改資源約束等。瞭解執行這樣的操做時羣集中會發生的情況是很重要。
例如,假設您要添加一個羣集IP地址資源。爲此,您可使用一種命令行工具, 或GUI修改CIB您沒必要在DC上執行此操做,可使用羣集中任何節點上的任何工具,此操做會被傳送到DC上。而後DC將把此CIB更改複製到全部羣集節點。

根據CIB中的信息,PE便計算羣集的理想狀態及如何達到此狀態,並將指令列表傳遞給DC.DC經過消息交換/基礎結構層發出命令,其餘節點上的crmd同 級將收到此命令《每一個lrmd使用它的LRM (做爲Irmd實觀)執行資源修改.lrmd不是羣集感知的,它直接與資源代理(腳本)交互
全部同級節點將操做的結果報告給DC。一旦DC作出全部必需操做已在羣集中成功執行的結論,羣集將返回至空閒狀態並等待進一步亊件。若是有操做末按計劃執行,則會再次調用PE,CIB中將記錄新信息。

在某系狀況下,可能須要關閉節點以保護共享數據或完成資源恢復。爲此,pacemaker附帶了一個屏障子系統,stonithd。STONITH 是"shoot the other node in the head"(關閉其餘節點)"的首字母縮寫,一般經過一個遠程電源開關實施。在pacemaker中將STONITH設備構形成資源(並在CIB中配置) 以便它們監視故障;然而,stonithd負責瞭解STONITH拓撲,這樣它的客戶端只需請求屏障節點,餘下的工做由它來完成。

 

 

Linux High Availabi  資源類型:

original

原始資源是最基本的資源類型。

group

組包含一系列須要放置在一塊兒的資源、按順序啓動和以反序中止的資源。

組具備如下屬性:
啓動和中止資源
資源以顯示順序啓動,以相反順序中止。
相關性
若是組中某個資源在某處沒法運行,則該組中位於其以後的任何資源都不允 許運行。
組內容
組可能僅包含一些原始羣集資源。要引用組資源的子代,請使用子代的ID 代替組的ID。
限制
儘管在約束中能夠引用組的子代,但一般傾向於使用組的名稱。
黏性
黏性在組中能夠累加。每一個活動的組成員能夠將其黏性值累加到組的總分 中。所以,若是默認的resource-stickiness值爲100,而組中有七個 成員,其中五個成員是活動的,則組總分爲500,更喜歡其當前位置。

資源監控

要爲組啓用資源監視,必須爲組中每一個要監視的資源分配監視。

注意: 組必須包含至少一個資源,不然無效.

Web 服務器的資源組

資源組示例是須要IP地址和文件系統的Web服務器。在這種狀況下,每一個組件 都是一個會合併到羣集資源組中的獨立羣集資源。資源組在一臺或多臺服務器 上運行,若是軟件或硬件有故障,故障轉移至羣集中的另外一臺服務器上,這與 單個羣集資源相同。

以下圖所示:

wKioL1NP3ALyRnNiAADukhAQGRo449.jpg

 

clone

   克隆是能夠在多個主機上處於活動狀態的資源。若是各個資源代理支持,則任何資源都可克隆。(集羣文件系統,文件共享服務器)

您可能但願某些資源在羣集的多個節點上同時運行。爲此,必須將資源配置爲 克隆資源。能夠配置爲克隆資源的資源示例包括STOMTH和羣集文件系統(如 0CFS2)。若是受資源的資源代理支持,則能夠克隆任何資源。克隆資源的配 置甚至也有不一樣,具體取決於資源駐留的節點。
資源克隆有三種類型:
匿名克隆
這是最簡單的克隆類型。這種克隆類型在全部位置上的運行方式都相同。因 此,每臺計算機上只能有一個匿名克隆實例是活動的。
全局惟一克隆
這些資源各不相同。一個節點上運行的克隆實例與另外一個節點上運行的實例 不一樣,同一個節點上運行的任何兩個實例也不一樣。
狀態克隆
這些資源的活動實例分爲兩種狀態:主動和被動。有時也稱爲主要和輔助, 或主和從。狀態克隆能夠是匿名克隆也能夠是全局惟一克隆。

master

主資源是一種特殊的克隆資源,主資源能夠具備多種模式。主資源必須只能包含一個組或一個常規資源。

master/slave

主從資源主的能讀能寫,從的不能讀也不能寫

 

Linux High Availabi   配置資源約束

配置好全部資源只是完成了該做業的一部分。即使羣集熟悉全部必需資源,它 可能還沒法進行正確處理。資源約束容許您指定在哪些羣集節點上運行資源、 以何種順序裝載資源,以及特定資源依賴於哪些其餘資源。
提供三種不一樣的約束:

Resource Location (資源位置)
位置約束定義資源能夠、不能夠或首選在哪些節點上運行。 優先級(inf:無窮大、- inf: 負無窮大  n:指定優先級大小  -n :負優先級大小)

Resource Collocation (資源排列)
排列約束告訴羣集資源能夠或不能夠在某個節點上一塊兒運行。 inf:排列約束:資源不管如何都要在一塊兒  -inf: 資源老死不相往來 (在某臺服務器上)

Resource Order (資源順序)
排序約束定義操做的順序。 資源啓動次序及關閉次序(好比 在啓動web服務器的時候是先啓動IP,仍是先啓動web服務進程呀!)

定義約束時,還須要指定分數。各類分數是羣集工做方式的重要組成部分。其 實,從遷移資源到決定在已降級羣集中中止哪些資源的整個過程是經過以某種 方式操縱分數來實現的。分數按每一個資源來計算,資源分數爲負的任何節點都 沒法運行該資源。在計算出資源分數後,羣集選擇分數最高的節點。INFINITY (無窮大)目前定義爲1, 000, 000。加減無窮大遵循如下3個基本規則:

◆任何值+無窮大=無窮大

◆任何值-無窮大=-無窮大

◆無窮大-無窮大=-無窮大

   定義資源約束時,也能夠指定每一個約束的分數。分數表示您指派給此資源約束 的值。分數較高的約束先應用,分數較低的約束後應用。經過使用不一樣的分數 爲既定資源建立更多位置約束,能夠指定資源要故障轉移至的目標節點的順序

 

指定資源故障回覆節點(資源黏性)

當原始節點恢復聯機並位於羣集中時,資源可能會故障回覆到該節點。若是但願阻止資源故障回覆到故障轉移前運行的節點上,或若是但願指定其餘的節點讓資源進行故障回覆,則必須更改資源黏性值。在建立資源時或在建立資源後, 均可以指定指定資源黏性。
在指定資源黏性值時,請考慮如下狀況:
值爲0:
這是默認選項。資源放置在系統中的最適合位置。這意味着當負載能力「較好」或較差的節點變得可用時才轉移資源。此選項的做用幾乎等同於自動故障回覆,只是資源可能會轉移到非以前活動的節點上。
值大於0:
資源更願意留在當前位置,可是若是有更合適的節點可用時會移動。值越高表示資源越願意留在當前位置。
值小於0:
資源更願意移離當前位置。絕對值越高表示資源越願意離開當前位置。
值爲 INFINITY:
若是不是因節點不適合運行資源(節點關機、節點待機、達到migration-threshold或配置更改)而強制資源轉移資源轉移,資源老是留在當前位置。此選項的做用幾乎等同於徹底禁用自動故障回覆.
值爲-INFINITY:
資源老是移離當前位置。

 

那下面咱們來實現heartbeat v1版本的工做過程:
安裝配置高可用集羣:實現heartbeat v1版的過程
   一、節點名稱很關鍵,集羣每一個節的名稱都得能互相解析;
   用hosts文件,/etc/hosts:hosts中主機名的正反解析結果必須跟」uname -n」的結果保持一致;
   二、時間必須得同步,使用網絡時間服務器同步時間;
   三、各節點間能基於ssh密鑰互相認證通訊;    

   1)配置主機名、
   第一臺節點的主機名爲node1.tanxw.com,第二臺節點的主機名爲node2.tanxw.com    

# vim /etc/hosts  改主機名,注意,兩個節點都要添加,我幾個節點就加幾條解析
172.16.249.61 node1.tanxw.com
172.16.249.62 node2.tanxw.com
# uname -n
# hostname node1.tanxw.com
# hostname node2.tanxw.com
# cat /etc/sysconfig/network 若是這個與node1或2不一致就改一下,這個改配置文件保證下次系統重啓時主機名依然有效,
# 若是改好了沒有生效就ctrl+d註銷一下再登陸就OK了。

   wKiom1NXNAHh7o3rAAF40k7SSIw972.jpgwKiom1NXNA_jgZgkAADC01OsoPE292.jpg    

   2)兩臺主機或多臺主機基於ssh無密鑰通訊    

# ssh-keygen -t rsa -P ‘’   這個生成一個密碼爲空的公鑰和一個密鑰,把公鑰複製到對方節點上便可
# ssh-copy-id -i .ssh/id_rsa.pub root@node2.tanxw.com 對方主機名用登陸用戶名
兩臺主機都要互相能夠通訊,因此兩臺主機都得互相生成密鑰和複製公鑰,相互的節點上的hosts文件是都要解析對方的主機名,172.16.249.61 node1.tanxw.com
172.16.249.62 node2.tanxw.com
# ssh node2.tanxw.com ‘date’;date  測試一下是否已經互信

   3)安裝heartbeat v1版本的程序,兩個節點都要安裝上heartbeat的相關程序包  

# 安裝這幾個包,可是存在依賴關係,須要解決:
heartbeat-2.1.4-12.el6.x86_64.rpm、heartbeat-pils-2.1.4-12.el6.x86_64.rpm、
heartbeat-stonith-2.1.4-12.el6.x86_64.rpm
# 解決依賴關係:
# yum -y install perl-TimeDate net-snmp-libs libnet PyXML
# rpm -ivh heartbeat-pils-2.1.4-12.el6.x86_64.rpm heartbeat-stonith-2.1.4-12.el6.x86_64.rpm  heartbeat-2.1.4-12.el6.x86_64.rpm

   一個高可用集羣得依賴:一、信息層; 二、資源管理器;三、資源代理
   咱們配置的過程就按這種層次去配置就能夠了;
   這裏要注意的是:如 何在網絡中咱們指望的節點集羣成爲咱們所須要的節點,在集羣中信息不能隨便傳遞,而心跳節點是基於組播地址傳遞的,若是別人也裝了heartbeat也連 接到這個組播地址上來,這都不安全,基於這種狀況,咱們各節點這間信息傳遞是須要認證的,這種認證基於HMAC(消息認證碼),消息認證碼是使用單向加密 算動法來實現的,而單向加密通常有三類:crc(循環冗餘校驗碼)、md5(信息摘要算法)、sha1。heartbeat基於udp協議,監聽在694 端口上;

   4)配置heartbeat,它的配置文件在/etc/ha.d/的目錄下,可是安裝完程序以後這個目錄下沒有這個配置文件,只有/usr/share /doc/heartbeat-2.1.4/目錄下有ha.cf的主配置文件樣本,複製到/etc下修改配置文件便可使用;還有一個authkeys的認 證文件,這個文件就是咱們各節點認證時所保存的認證密碼和認證機制,因此這個文件的權限相當重要,必須是600,不然啓動不了服務;第三個 haresources,定義資源時須要資源管理器來讀取這個文件,因此這個也得有;  

# cp /usr/share/doc/heartbeat-2.1.4/{ha.cf,authkeys,haresources} /etc/ha.d/
# cd /etc/ha.d/
# openssl rand -hex 8   生成16位隨機數
ee869d3d86e1556f
# vim /etc/ha.d/authkeys
auth 2   這裏的2與下面選項的數只要一致就能夠了,沒有什麼限定
2 sha1 ee869d3d86e1556f
# chmod 600 authkeys
# vim /etc/ha.d/ha.cf    啓用如下參數及功能
logfile /var/log/ha-log  #日誌文件,正常日誌信息記錄到哪去的
keepalive 1000ms   #每隔多長時間發送一次心跳信息的,單位是秒,毫秒用ms
deadtime 8    #隔多長時間探測到對方不在線就kill掉的時間間隔
warntime 10   #警告時間
udpport 694
mcast eth0 225.0.0.1 694 1 0   #定義組播地址
auto_failback on    #開啓故障轉回功能
node    node2.tanxw.com   #定義兩個節點
node    node1.tanxw.com
crm on      #啓用crm功能
ping 172.16.0.1   #ping節點
compression     bz2    #壓縮格式
compression_threshold 2    #表示小於2K時不壓縮傳輸

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進程的身份。

 

 定義資源:在資源管理器的配置文件中定義;/etc/ha.d/haresources,在/etc/ha.d/resource.d下有各類資源類型,當在資源配置文件中定義時就會調用這裏的資源類型來運行相應的程序;

# vim /etc/ha.d/haresources
node1.tanxw.com 172.16.249.66 httpd   # 172.16.249.66這個是浮動地址
注:node1.tanxw.com:說明哪臺主機是主節點,更傾向於誰上面
[node1.tanxw.com 172.16.249.61/16/eth0/172.16.255.255 httpd 也能夠這樣定義
node2.tanxw.com 172.16.249.62 httpd  httpd是怎麼被調用的呢:首先會找/etc/ha.d/resource.d目錄下,若是沒有就去/etc/init.d/目錄下找httpd,找到就start。]
# scp -p authkeys haresources ha.cf node1.tanxw.com:/etc/ha.d/
# service heartbeat start

   wKiom1NXRlmxEq7jAAGESzZ-U_g798.jpg

在主節點上使用下面的命令僅僅中止 heartbeat 來模擬故障轉移(failover):

/etc/rc.d/init.d/heartbeat stop

您應該會看到,在一分鐘以內,第二個節點上的全部 Web 服務器進程都會啓動。若是不是那樣,那麼去查看 /var/log/messages 來肯定問題所在並改正它。

相關文章
相關標籤/搜索