LINUX 集群學習一
服務器中的集群與網絡中的集群雖然都是為了提供冗余的服務能力，但是在實現上有一定的差異，主要原因為網絡冗余只需要實現流量有冗余路徑，當主的鏈路故障後，流量可以通過備的鏈路通行即可。對於有狀態的如TCP協議，某些設備如防火墻需要對其進行狀態檢測，那麽只需要在主備設備之間開啟會話同步功能即可。但是對於服務器而言較為復雜，主要原因是因為服務器作為流量的終結點，是需要直接對外提供服務的，其上存儲的數據則需要被服務訪問，不再是流量穿越就可以。本人一起從事網絡相關的工作，在第一次接觸服務器集群時，對其實現原理機制完全不了解，在反復學習後才有一些粗淺的認識，本篇先簡單的介紹一下服務器集群原理，後續慢慢對學習中的實驗進行總結。
服務器集群主要實現服務的冗余能力以及高性能，從目前我所了解到的來看，主要有兩種類型：- 通過類似負載均衡設備將服務請求向後續的多個真實服務器轉發，可以實現多臺服務器對外提供服務，以達到服務的高並發能力；
- 多臺服務器自身冗余對外提供服務，這多臺服務器之間構成一個高可靠集群，正常情況下只有主節點響應請求，當主節點設備故障後，服務需要立即由備份的節點進行接管，並且對外提供服務。
如下圖所示，這兩種類型可以共同組合起來，前面多臺設備由第2種情況組成集群對外提供服務，這裏是master以及backup，兩臺設備組成一個虛擬節點VS，由該虛擬VS節點對外提供服務，實際承擔VS功能的節點作為master。正常情況下由master將外面進來的響應接收下來，然後再將請求向後端轉發。當前端接收服務的主節點master故障後，由備份節點backup繼續接收請求向後端轉發，這樣可以實現前端高可靠接受請求以及後端的高並發服務響應能力。
這裏我們著重講第二種情況，即多臺設備對外提供冗余能力的集群。通俗來講，這種服務器集群實際上就是要實現當主節點在提供服務時啟用服務相關的資源，而備節點停用相關的資源；當主節點故障後，備節點啟用服務相關的資源對外提供服務，而主節點停止相關的服務。
在集群系統中，這些相關的資源不再由服務器自身管理，而由一個統一的軟件來管理，這裏我們稱為CRM（cluster resource manager），其主要作用是用於對每個成員節點的信息進行收集，並且計算出來哪一個節點應當對外提供服務，而後由節點上的LRM（local resource manager）進行資源的具體處理。這些具體的服務我們稱為RA(resource agent)CRM計算所依賴的資源如何而來呢？這裏引入集群事務信息層message layer，主要用於各節點之間相互通信以及收集集群的相關信息。所以，集群的結構我們可以粗略的表示為如下圖所示：
這些資源如何組合在一起運行呢？是否可以放一起呢？是否必須放在一起運行呢？這裏就講到資源的粘性。同時資源粘性也是為了解決某些情況下，主備節點性能不一樣，資源應該運行在性能較優的節點上，應該讓資源對性能高的設備更具有粘性。
資源粘性：資源對某節點的依賴程度，通過score進行定義。
資源組：resource group，將各種資源歸為一組，實現資源的同時轉移。
資源約束：除了資源組以外，可以使用資源間的約束關系進行定義。
排列約束：資源間的依賴性，定義資源是否能夠放在一起使用，是否可以運行於同一個節點，score
正值：資源可以放在一起
負值：資源不可以放在一起
位置約束：location，score得分衡量：資源對節點的依賴傾向程度
正值：傾向於運行於此節點
負值：傾向於逃離此節點
順序約束：order，定義資源啟動或者關閉時的次序
Core都是正整數或者負整數形式，也可以是如下的形式：
-INF：負無窮
INF：正無窮
當主備切換後，防止故障設備在正常、不正常之間來回切換，需要進行資源隔離。
資源隔離：
節點級別：STONITH
資源級別：
例如：FC SAN switch可以實現在存儲資源級別拒絕某節點的訪問
Split brain：集群節點無法有效獲取其他節點的狀態信息時，產生腦裂，出現資源搶占情況。這種情況在網絡中我們稱其為雙主狀態。
腦裂最嚴重的後果是搶占共享存儲導致數據損壞。
當集群主出現故障時，備設備需要取代主設備的功能，但是如何確認是對端故障，而不是自身故障呢？
- 兩個節點：借助第三方，如網關
- 借助仲裁磁盤，主節點往磁盤上寫數據，其他節點監控是否有主節點往該磁盤上寫數據
- 奇數個節點：引入法定票數quorum的概念，可以是每個節點1票，當集群分裂後，票數多的勝出，也可以是每個節點的票數不相等，如高性能的節點可以占多票。
具體實現：
Massage Layer：
Heartbeat：v1（古老版本）,v2（成熟版本）,v3 ，監聽UDP協議的694號端口
Heartbeat v3分裂為多個獨立項目：
Heartbeat v3：MessageLayer層
Pacemaker：
cluster-glue
Corosync：Redhat6.0以後默認使用的軟件：corosync，性能比heartbeat優越，但是不具有pacemaker的功能，需要配合使用，組合後相當於heartbeat v3
Cman：redhat5.0，cluster manager：紅帽上有專門的RHCS套件，cman是RHCS的核心組件
Keepalived：本身為了LVS的DC高可用而設計
Ultramonkey：
CRM：
Heartbeat v1自帶管理器功能，haresources，為heartbeat v1提供CRM；
Heartbeat v2 自帶的資源管理器，為heartbeat v2提供CRM；
Haresources:兼容V1版本
Crm：需要監聽在某個接口，可以通過圖形界面管理
Heartbeat v3：
Pacemaker：Heartbeat v3 中CRM 發展為獨立的項目。為heartbeatv3或者corosync提供CRM功能。
Rgmanager:資源組管理器，cman專門提供的CRM
Resource Type：資源類別
Primitive:主資源，某一個時刻只能運行在一個節點上，比如說對外提供服務的虛擬IP地址；
Clone:將主資源克隆一份，資源必須同時運行在多個節點上，比如STONITH管理的RA；
Group:多個資源歸為一類，當作一個容器，同進同退；
Master/save:一種特殊的clone資源，只能運行在兩個節點上，資源具有主從關系。
RA 類別：接收LRM傳遞過來的指令，完成對資源的控制
Legacy heartbeat v1 RA：專用於heartbeat v1
LSB:(/etc/rc.d/init.d/)遵循linux SHELL編程風格，可以接收四種參數：start|stop|restart|status.
OCF：open cluster framework，除了上述四種參數，還可以接受類似monitor等參數，可能由不同的vendor提供
Pacemaker
Linbit(drbd)
STONITH:專門管理硬件 STONITH設備。
LINUX 集群學習一