Heartbeat的切換策略-積分統計方法[轉]

火星人 @ 2014-03-04 , reply:0


Heartbeat的切換策略-積分統計方法[轉]

v1 style配置的heartbeat沒辦法做到對資源狀態的監控,主要職能通過監控與對方節點以及集群對外的網路狀況的監控,而v2 style的配置已經提控了對資源狀態的監控
一、heartbeat模塊:
    整個Heartbeat軟體的通信模塊,各個節點之間的任何通信都是通過這個模塊完成。這個模塊會根據不同類型的通信啟動不同的事件handler,當監聽到不同類型的通信請求後會分給不同的handler來處理。這個從整個Heartbeat的啟動日誌中看出來。
二、CRM:cluster resource manager
    從這個名字就可以看出這個模塊基本上就是v2的heartbeat的一個只會中心,整個系統的一個大腦了,他主要負責整個系統的各種資源的當前配置信息,以及各個資源的調度。也就是根據各資源的配置信息,以及當前的運行狀況來決定每一個資源(或者資源組)到底該在哪個節點運行。不過這些事情並不是他直接去做的,而是通過調度其他的一些模塊來進行。
    他通過heartbeat模塊來進行節點之間的通信,調度節點之間的工作協調。隨時將通過heartbeat模塊收集到的各個成員節點的基本信息轉交給CCM某塊來更新整個集群的membership信息。他指揮LRM(local resource manager)對當前節點的各資源執行各種相應的操作(如start、stop、restart和monitor等等),同時也接收LRM在進行各種操作的反饋信息並作出相應的決策再指揮後續工作。另外CRM模塊還負責將各個模塊反饋回來的各種信息通過調用設定的日誌記錄程序記錄到日誌文件中。
三、LRM:local resource manager
    LRM是整個Heartbeat系統中直接操作所管理的各個資源的一個模塊,負責對資源的監控,啟動,停止或者重啟等操作。這個模塊目前好像支持有四種類型的資源代理(resource agent):heartbeat自身的,ocf(open cluster framework),lsb(linux standard base,其實就是linux下標準的init腳本),還有一種就是stonith。stonith這種我還不是太清楚是一個什麼類型的。
    四種類型的resource agent中的前三種所調用的腳本分別存如下路徑:
        heartbeat:/etc/ha.d/resource.d/
        ocf:/usr/lib/resource.d/heartbeat/
        lsb:/etc/init.d/
    LRM就是通過調用以上路徑下面的各種腳本來實現對資源的各種操作。每一種類型的腳本都可以由用戶自定義,只要支持各類型的標準即可。實際上這裡的標準就是接受一個標準的調用命令和參數格式,同時返回符合標準的值即可。至於腳本中的各種操作時如何的LRM並不care。
四、PE:CRM Policy Engine
    他主要負責將CRM發過來的一些信息按照配置文件中的各種設置來進行計算,分析。然後將結果信息按照某種固定的格式通過CRM提交給TE(Transition engine)去分析出後續需要採取的相應的action。PE需要計算分析的信息主要是當前有哪些節點,各節點的狀況,當前管理有哪些資源,各資源當前在哪一個節點,在各個節點的狀態如何等等。
五、TE:Transition engine
    主要工作是分析PE的計算結果,然後根據配置信息轉換成後續所需的相應操作。個人感覺PE和TE組合成一個類似於規則引擎實現的功能,而且PE和TE這兩個模塊只有在處於active的節點被啟動。另外PE和TE並不直接通信,而都是通過Heartbeat的指揮中心CRM來傳達信息的。
六、CIB:cluster information base
    CIB在系統中充當的是當前集群中各資源原始配置以及之後動態變化了的狀態,統計信息收集分發中心,是一個不斷更新的信息庫。當他收集到任何資源的變化,以及節點統計信息的變化后,都會集成整合到一起組成當前集群最新的信息,並分發到集群各個節點。分發動作並不是自己和各個節點通信,同樣也是通過heartbeat模塊來做的。
    CIB收集整理並匯總出來的信息是以一個xml格式保存起來的。實際上Heartbeat v2的資源配置文件也就是從haresources遷移到了一個叫cib.xml文件裡面。該文件實際上就是CIB的信息庫文件。在運行過程中,CIB可能會常讀取並修改該文件的內容,以保證信息的更新。
七、CCM:consensus cluster membership
    CCM的最主要工作就是管理集群中各個節點的成員以及各成員之間的關係。他讓集群中各個節點有效的組織稱一個整體,保持著穩定的連接。heartbeat模塊所擔當的只是一個通信工具,而CCM是通過這個通信工具來將各個成員連接到一起成為一個整體。
八、LOGD:logging daemon(non-blocking)
    一個無阻塞的日誌記錄程序,主要負責接收CRM從各個其他模塊所收集的相關信息,然後記錄到指定額度日誌文件中。當logd接收到日誌信息後會立刻返回給CRM反饋。並不是一定要等到將所有信息記錄到文件后再返回,日誌信息的記錄實際上是一個非同步的操作。
九、APPHBD:application heartbeat daemon
    apphbd模塊實際上是給各個模塊中可能需要用到的計時用的服務,是通過watchdog來實現的。這個模塊具體的細節我還不是太清楚。
十、RMD:recovery manager daemon
    主要功能是進程恢復管理,接受從apphbd所通知的某個(或者某些)進程異常退出或者失敗或者hang住后的恢復請求。RMD在接受到請求後會作出restart(如果需要可能會有kill)操作。
在V2的Heartbeat中,為了將資源的監控和切換結合起來,同時支持多節點集群,Heartbeat提供了一種積分策略來控制各個資源在集群中各節點之間的切換策略。通過該積分機制,計算出各節點的的總分數,得分最高者將成為active狀態來管理某個(或某組)資源。
如果在CIB的配置文件中不做出任何配置的話,那麼每一個資源的初始分數(resource-stickiness)都會是默認的0,而且每一個資源在每次失敗之後所減掉的分數(resource-failure-stickiness)也是0。如此的話,一個資源不論他失敗多少次,heartbeat都只是執行restart操作,不會進行節點切換。一般來說,resource-stickiness的值都是正數,resource-failure-stickiness的值都是負數。另外還有一個特殊值那就是正無窮大(INFINITY)和負無窮大(-INFINITY)。如果節點的分數為負分,那麼不管什麼情況發生,該節點都不會接管資源(冷備節點)。隨著資源的各種狀態的發生,在各節點上面的分數就會發生變化,隨著分數的變化,一旦某節點的分數大於當前運行該資源的節點的分數之後,heartbeat就會做出切換動作,現在運行該資源的節點將釋放資源,分數高出的節點將接管該資源。
在CIB的配置中,可以給每個資源定義一個分數,通過resource-stickiness來設置,同樣也可以設置一個失敗后丟失的分數,通過resource-failure-stickiness來設置。如下:
<primitive id=」mysql_db」 class=」ocf」 type=」mysql」 provider=」heartbeat」>
<meta_attributes id=」mysql_db_meta_attr」>
<attributes>
<nvpair name=」resource_stickiness」 id=」mysql_db_meta_attr_1″ value=」100″/>
<nvpair name=」resource_failure_stickiness」 id=」mysql_db_meta_attr_2″ value=」-100″/>
</attributes>
</meta_attributes>

<primitive />
上面的配置就是給mysql_db這個resource配置了兩個分數,成功運行的時候所得到的分數(resource_stickiness)和運行失敗會丟失的分數(resource_failure_stickiness),兩項分數值一樣多,成功則得100分,失敗則-100分。
除了可以通過給每個資源單獨設置兩項的分數之外,也可以將所有的resource設置成相同的分數,如下:
<configuration>
<crm_config>
<cluster_property_set id=」cib-bootstrap-options」>
<attributes>

<nvpair id=」default-resource-failure-stickiness」 name=」default-resource-failure-stickiness」 value=」-100″/>
<nvpair id=」default-resource-stickiness」 name=」default-resource-stickiness」 value=」100″/>

</attributes>
</cluster_property_set>
</crm_config>

在這個配置中,就是給所有資源設置了兩個默認的分數,省去單獨每個資源都設置的麻煩。當然,如果在設置了這個default分數之後,同時也給部分或者全部資源也設置了這兩個分數的話,將取單獨設置的各個資源設置的分數而不取默認分數。
除了資源的分數之外,節點自身同樣也有分數。節點分數可以如下設置:

<constraints>
<rsc_location id=」rsc_location_group_mysql」 rsc=」group_mysql」>
<rule id=」mysql1_group_mysql」 score=」200″>
<expression id=」mysql1_group_mysql_expr」 attribute=」#uname」 operation=」eq」 value=」mysql1″/>
</rule>
<rule id=」mysql2_group_mysql」 score=」150″>
<expression id=」mysql2_group_mysql_expr」 attribute=」#uname」 operation=」eq」 value=」mysql2″/>
</rule>
</rsc_location>
</constraints>

注意這裡節點分數的設置是放在configuration配置項裡面的constraints配置項下的,通過rule來設置。這裡是通過節點主機名來匹配的(實際上heartbeat的很多配置中對主機名都是很敏感的)。這裡的value值就是節點的主機名,rule裡面的score就是一個節點的分數。
通過上面的配置,我們可以作出如下計算:
a、在最開始,兩邊同時啟動heartbeat的話,兩邊都沒有開始運行這個resource,resource本身沒有分數,那麼僅僅計算節點的分數:
mysql1的分數:node+resource+failcount*failure=200+0+(0*(-100))=200
mysql2的分數:node+resource+failcount*failure=150+0+(0*(-100))=150
heartbeat會做出選擇在mysql1上面運行mysql_db這個資源,然後mysql1的分數發生變化了,因為有資源自身的分數加入了:
mysql1的分數:node+resource+failcount*failure=200+100+(0*(-100))=300
mysql2的分數:node+resource+failcount*failure=150+0+(0*(-100))=150
b、過了一段時間,heartbeat的monitor發現mysql_db這個資源crash(或者其他問題)了,分數馬上會發生變化,如下:
mysql1的分數:node+resource+failcount*failure=200+100+(1*(-100))=200
mysql2的分數:node+resource+failcount*failure=150+0+(0*(-100))=150
heartbeat發現mysql1節點的分數還是比mysql2的高,那麼資源不發生遷移,將執行restart類操作。
c、繼續運行一段時間發現又有問題(或者是b後面restart沒有起來)了,分數又發生變化了:
mysql1的分數:node+resource+failcount*failure=200+100+(2*(-100))=100
mysql2的分數:node+resource+failcount*failure=150+0+(0*(-100))=150
這時候heartbeat發現mysql2節點比mysql1節點的分數高了,資源將發生遷移切換,mysql1釋mysql_db相關資源,mysql2接管相關資源,並在mysql2上運行mysql_db這個資源。這時候,節點的分數又會發生變化如下:
mysql1的分數:node+resource+failcount*failure=200+0+(2*(-100))=0
mysql2的分數:node+resource+failcount*failure=150+100+(0*(-100))=250
這時候如果在mysql2上面三次出現問題,那麼mysql2的分數將變成-50,又比mysql1少了,資源將遷移回mysql1,mysql1的分數將變成100,而mysql2的分數將變成-150,因為又少了資源所有者的那100分。到這裡,mysql2節點的分數已經是負數了。heartbeat還有一個規則,就是資源永遠都不會遷移到一個分數分數是負數的節點上面去。也就是說從這以後,mysql1節點上面不管mysql_db這個資源失敗多少次,不管這個資源出現什麼問題,都不會遷移回mysql2節點了。一個節點的分數會在該節點的heartbeat重啟之後被重置為初始狀態。或者通過相關命令來對集群中某個節點的某個資源或者資源組來重置或者查看其failcount,如下:
crm_failcount -G -U mysql1 -r mysql_db        #將查看mysql1節點上面的mysql_db這個資源的failcount
crm_failcount -D -U mysql1 -r mysql_db        #將重置mysql1節點上面的mysql_db這個資源的failcount
當然,在實際應用中,我們一般都是將某一些互相關聯的資源放到一起組成一個資源組,一旦資源組中某資源有問題的時候,需要遷移整個資源組的資源。這個和上面針對單個資源的情況實際上沒有太多區別,只需要將上面mysql_db的設置換到資源組即可,如下:

<group id=」group-mysql」>
<meta_attributes id=」group-mysql_meta_attr」>
<attributes>
<nvpair id=」group-mysql_meta_attr-1″ name=」resource_stickiness」 value=」100″/>
<nvpair id=」group-mysql_meta_attr-1″ name=」resource_failure_stickiness」 value=」-100″/>
</attributes>
</meta_attributes>
<primitive>

</primitive>

</group>

這樣,在該資源組中任何一個資源出現問題之後,都會被認為該資源組有問題,當分數低於其他節點出現切換的時候就是整個資源組的切換。
另外,對於INFINITY和-INFINITY這兩個值,實際上主要用途就是為了控制永遠不切換和只要失敗必須切換用的。因為代表的意思就是擁有正無窮大的分數和失敗就到負無窮大,主要用來滿足極端規則的簡單配置項。
總的來說,一項資源(或者資源組)在一個節點運行遷移到另一個節點之前,可以失敗的次數的計算公式可以如下表示:
(nodeA score - nodeB score + stickiness)/abs(failure stickiness),即為A節點分數減去B節點分數,再加上資源運行分數后得到的總分數,除以資源失敗分數的絕對值。
原文首發: Sky.Jian 朝陽的天空
原文鏈接:Heartbeat的切換策略-積分統計方法
cib.xml行9及行10

<nvpair id="cib-bootstrap-options-default-resource-stickiness" name="default-resource-stickiness" value="INFINITY"/>
<nvpair id="cib-bootstrap-options-default-resource-failure-stickiness" name="default-resource-failure-stickiness" value="INFINITY"/>

<nvpair id="cib-bootstrap-options-default-resource-stickiness" name="default-resource-stickiness" value="INFINITY"/>
<nvpair id="cib-bootstrap-options-default-resource-failure-stickiness" name="default-resource-failure-stickiness" value="INFINITY"/>

http://www.linux-ha.org/v2/faq

[ 本帖最後由 kns1024wh 於 2009-1-22 15:55 編輯 ]
《解決方案》

good,好文,學習先~
《解決方案》

好文,收藏先.謝謝版主
《解決方案》

V2和V1的主要差別之一就在這裡,可能是為了支持多節點的原因吧,其實對於2節點的系統,可以配置的十分簡單就可以了。



[火星人 via ] Heartbeat的切換策略-積分統計方法[轉]已經有98次圍觀

http://www.coctec.com/docs/service/show-post-6676.html