Linux高可用性方案之Heartbeat的CRM节点得分计算(原创)
crm資源得分概述?
在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就是一個節點的分數。
節點分數計算規則
在CRM的配置當中,節點通過如下規則計算得分
Score=?node+resource+failcount*failure
當HB發現NODE資源無法獲取或發生切換時,會減去之前賦給該NODE的"成功分:default-resource-stickiness"
當HB發生NODE資源失敗時,會給該NODE加上"失敗分:default-resource-failure-stickiness"
當HB的資源成功在NODE上START,那么會給該NODE加上"成功分:default-resource-stickiness"?
單資源組單資源的得分計算?
通過上面的配置,我們可以作出如下計算:
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-?resource?=200+100+(2*(-100))-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節點分數,再加上資源運行分數后得到的總分數,除以資源失敗分數的絕對值。
多資源組單資源的得分計算
上述的積分計算只適用域資源組內只有一個資源且只有一個資源組的情況下面的表格列舉了,每個資源組里存在一個資源的積分計算過程
default-resource-stickiness=100 default-resource-failure-stickiness=-101
mysql4.ipaddr.score=350 mysql3.ipaddr.score=400
mysql4.mysql.score=350 mysql3.mysql.score=400
可以看出,資源組內的資源得分計算是相對獨立的,但是資源是否切換依舊依據資源組與資源組之間的分數總和進行判斷。
多資源組多資源的得分計算
資源要切換不再以單個資源的分數來比較. 而是以該資源組的N個資源SCORE之和,我們下面稱它為
NodeX.all.score=mysqlX.resource1.score+ .... + mysqlX.resourceN.score
1.當HB發現NodeX上的資源失敗或發生切換時,會減去之前賦給該NODE的"成功分:N*default-resource-stickiness",
NodeX.resourceY.score -= N * default-resource-stickiness
NodeX.all.score = NodeX.resource1.score + ...... + NodeX.resource2.score
2.當HB發生NodeX資源失敗時,會給該NODE加上"失敗分:default-resource-failure-stickiness"
NodeX.resourceY.score += default-resource-failure-stickiness
NodeX.all.score = NodeX.resource1.score + ...... + NodeX.resource2.score
3.當HB的資源成功在NODE上START,那么會給該NodeX加上"成功分:N*default-resource-stickiness"
NodeX.resourceY.score += N * default-resource-stickiness
NodeX.all.score = NodeX.resource1.score + ...... + NodeX.resource2.score
例1
default-resource-stickiness=100 default-resource-failure-stickiness=-100
mysql4.ipaddr.score=150 mysql3.ipaddr.score=200
mysql4.mysql.score=350 mysql3.mysql.score=400
例2
default-resource-stickiness=0?default-resource-failure-stickiness=-100
mysql4.ipaddr.score=375?mysql3.ipaddr.score=400
mysql4.mysql.score=775?mysql3.mysql.score=800
這樣配,只要任何一個資源DOWN,那么資源就往對方切換。可以一直回來切換.直到分數為負數。但是,如果一臺機器重啟了,那么重啟后會接管資源,因為他的SCORE比較高。
例3
default-resource-stickiness=5?default-resource-failure-stickiness=-23
mysql4.ipaddr.score=99?mysql3.ipaddr.score=100
mysql4.mysql.score=99?mysql3.mysql.score=100
這樣的配置,如果每次在切換后,把失敗NODE的HB重啟,或者分數置到CIB.SET. 那么,可以一直來回切換.不然: 第一次,只要有任何一個資源失敗,就發生切換.?第二次,需要有兩次資源失敗,才會發生切換.
配置了colocation的資源得分?
在cib.xml文件中進行如下配置
<configuration>
...
<constraints>
...
<rsc_colocation id="colocation1" to="IPaddr_10_2_225_225" from="mysql" score="INFINITY" symmetrical="true">
</rsc_colocation> </constraints>
</configuration>
資源要切換不再以單個資源的分數來比較. 而是以該NODE的N個資源SCORE之和,再乘N,我們下面稱它為
NodeX.all.score= (mysqlX.resource1.score+ .... + mysqlX.resourceN.score) *N
1)當HB發生NodeX資源失敗時,會給該NODE
NodeX.resourceN.score += default-resource-failure-stickiness
NodeX.resourceN.score -= default-resource-stickiness
NodeX.resourceN.score += default-resource-stickiness
NodeX.all.score = (NodeX.resource1.score + ...... + NodeX.resourceN.score)* N
然后多個NODE之間比較NodeX.all.score
2)當HB發現NodeX上資源發生切換到"NodeY" 時,會減去之前賦給該NODE的"成功分:default-resource-stickiness",
NodeX.resource[1..N].score -= default-resource-stickiness
NodeY.resource[1..N].score += default-resource-stickiness
NodeX.all.score = NodeX.resource1.score + ...... + NodeX.resourceN.score
NodeY.all.score = NodeY.resource1.score + ...... + NodeY.resourceN.score
例:
<rsc_colocation id="colocation1" from="IPaddr_10_2_225_225" to="mysql" score="INFINITY" symmetrical="true">
default-resource-stickiness=5?default-resource-failure-stickiness=-1?5?
mysql4.ipaddr.score=100?mysql3.ipaddr.score=100
mysql4.mysql.score=100?mysql3.mysql.score=10?1
參考至:http://www.alidba.net/index.PHP/archives/67
??????????? http://steven1981.itpub.net/post/7967/494028
????????????http://steven1981.itpub.net/post/7967/494034
????????????http://steven1981.itpub.net/post/7967/494118
本文原創,轉載請注明出處、作者
如有錯誤,歡迎指正
郵箱:czmcj@163.com
總結
以上是生活随笔為你收集整理的Linux高可用性方案之Heartbeat的CRM节点得分计算(原创)的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: WordPress博客后台不能显示所有主
- 下一篇: 逻辑备库的Swichover和Failo