高可用集羣

時間 2020-09-06

原文原文鏈接

LinuxHA Clusterhtml

高可用集羣，英文原文爲High Availability Cluster，簡稱HACluster，簡單的說，集羣（cluster）就是一組計算機，它們做爲一個總體向用戶提供一組網絡資源。這些單個的計算機系統就是集羣的節點（node）。node

高可用集羣的出現是爲了使集羣的總體服務儘量可用，從而減小由計算機硬件和軟件易錯性所帶來的損失。若是某個節點失效，它的備援節點將在幾秒鐘的時間內接管它的職責。所以，對於用戶而言，集羣永遠不會停機。web

高可用集羣軟件的主要做用就是實現故障檢查和業務切換的自動化。只有兩個節點的高可用集羣又稱爲雙機熱備，即便用兩臺服務器互相備份。當一臺服務器出現故障時，可由另外一臺服務器承擔服務任務，從而在不須要人工干預的狀況下，自動保證系統能持續對外提供服務。雙機熱備只是高可用集羣的一種，高可用集羣系統更能夠支持兩個以上的節點，提供比雙機熱備更多、更高級的功能，更能知足用戶不斷出現的需求變化。服務器

HACluster特性：網絡

1.提供冗餘系統：架構

HACluster：爲提高系統調用性，組合多臺主機構建成爲的集羣；ide

2.vote system：投票系統工具

HA中的各節點沒法探測彼此的心跳信息時，必須沒法協調工做；此種狀態即爲partitioned cluster；這個時候就須要一些機制來斷定：ui

（a）少數服從多數的原則，仲裁quorum：spa

withquorum > total/2

即HA奇數的時候，能夠實現投票仲裁，少數服從多數

withoutquorum <= total/2

即HA偶數的時候，兩方人數相等，只能依靠第三方仲裁設備

在沒有仲裁的狀況下，原有資源按如下設定運行：

stopped默認

ignore 繼續運行，有可能形成資源爭用

freeze原有正在訪問的用戶能夠繼續訪問，直到退出爲止。但新的鏈

接不被接受

suicide 自殺

（b）仲裁設備：

quorumdisk = qdisk

即HA同時往一個磁盤寫數據，表示本身的存在，沒法正常寫入時即表明有問題

pingnode

同時ping某個網關或設備，沒法正常ping通時即表明有問題

3.failover: 失效轉移，故障轉移

failback：失效轉回，故障轉回。

例如ha.cf中有一項auto_failback on 表示修復上線後自動轉回以前正常工做狀態

4.心跳信息傳遞機制

HA之間經過多種檢測機制和方式保持聯繫和判斷是否可用

(a).serail cable：串口，做用範圍有限，不建議使用；

(b).ethernet cable：網線，經過交換機來通訊，還能夠在每臺HA上多加一個

網卡，直接鏈接起來，和交換機那個鏈接作主從備用

(c).UDP Unicast 單播，使用UDP協議，速度快

(d).UDP Multicast 多播

(e).UDP Broadcast 組播

組播地址：用於標識一個IP組播域；

IANA(Internet Assigned number authority)把D類地址空間分配給IP組播使用；

其範圍是：224.0.0.0-239.255.255.255; 網卡要啓動組播地址功能才能使用。

永久組播地址：224.0.0.0-224.0.0.255;

臨時組播地址：224.0.1.0-238.255.255.255;

本地組播地址：239.0.0.0-239.255.255.255, 僅在特定本地範圍內有效；

HACluster的工做模型：

A/P：兩節點集羣，active, passive；工做於主備模型；HA Service一般只有一個：HAresources可能會有

多個；

A/A：兩節點集羣，active/active，工做於雙主模型；

一般這個模型，兩節點所提供的服務不同，不過也能夠同樣！例如2個節點運行的都是http 80端口的

服務，當其中一個節點離線，能夠將它的IP轉到另外一臺節點，由於服務內容是同樣的，不轉移服務也可

以！

N-M： N個節點，M個服務；一般N>M；例若有3個節點提供服務，還有1個只作備用

N-N：N個節點，N個服務；N個節點同時提供服務，當其中一個出現故障，資源

會轉移到其餘節點上一併運行

HACluster的資源：

在HA中，各類服務、IP、文件系統都統稱爲資源

資源類型：

兩大類：

(1) HA-aware：資源自身可直接調用HA集羣底層(message layer)的HA功能；

(2) 非HA-aware：必須藉助於CRM完成在HA集羣上實現HA功能；

具體分類：

(a)primitive：主資源，只能運行於集羣內的某單個節點；(也稱做native)；

(b) group：組資源，容器，包含一個或多個資源，這些資源可經過「組」這個資源統一進行調度；

(c)clone：克隆資源，能夠在同一個集羣內的多個節點運行多份克隆；

(d) master/slave：主從資源，在同一個集羣內部於兩個節點運行兩份資源，其中一個主，一個爲從；

資源的約束關係：

(a).location：位置約束，定義資源對節點的傾向性；用數值來表示，-oo, +oo；

例如某IP資源，對node1定義了100，node2定義了200，那麼當node一、node2都正常工做時，該IP會選擇在

node2上工做

(b).colocation：排列約束，定義資源彼此間「在一塊兒」傾向性；-oo, +oo

分組：亦能實現將多個資源綁定在一塊兒；

(c).order：順序約束，定義資源在同一個節點上啓動時的前後順序；

有次序地啓動資源；關閉的順序正好與啓動相反

例如haresource中某一條資源的定義：

(ha1)(192.168.61.100/24/eth0/192.168.61.255)(Filesystem::192.168.61.33:/tmp/webfile::/var/www/html::nfs) (httpd)

上面語句用括號劃分（原語句沒有）爲4部分：主服務主機名資源1 資源2 資源3

實驗中能夠查看log文件，啓動時順序是：資源1 -> 資源2 -> 資源3,切換關閉時順序是：資源3 -> 資源2 -> 資源1

注意：heartbeat v1 不支持資源約束！

資源隔離：

級別

1.節點級別：STONITH(shooting the other node in the head)

關閉整個節點，一般用電源交換機

2.資源級別：fencing 只要隔離這個節點的資源訪問就能夠了，不必關閉節點

(例如2個HA節點，經過交換機FC SAN同時鏈接一個存儲，當其中一個節點出問題，只要控制交換機斷掉出問題節點就能夠）

HACluster架構

模型分層

1. messagelayer基礎架構層；（主要負責心跳、事物信息的傳遞）

2. CRM集羣資源管理器；（負責非ha aware服務的管理、調度，至關於一個管理中心，

可理解爲，戰略制定，或董事長。經過調用下層的API,並向上提供API接口。還提供一個管理員接口。提供資源的順序、位置、排列機制）

3. LRM本地資源管理器；（可理解爲，戰略執行，CEO。爲本地資源提供管理功能)

4.RA 代理； (可理解爲：真正作事情的人。由於CEO不可能本身去作吧。）

架構各層次解決方案

message layer層：

1.heartbeat有v1,v2,v3版本，區別很大。早期流行，配置複雜，資源管理器很好用。

它除了message layer ,還提供其餘各層，如CRM,LRM,RA

2.corosync僅提供message layer

3.cman紅帽的，很強大，發展快

4.keepalived(工做方式徹底不一樣於上述3種）

CRM層：

1.heartbeatv1版 haresources (配置接口就一個配置文件：haresources)

2.heartbeatv2 crm (在各節點運行一個crmd進程，配置接口：命令行客戶端程序crmsh,gui客戶端：hb_gui)

3.heartbeatv3 pacemaker (能夠以插件或獨立方式運行,配置接口：命令行接口：crmsh

（不是紅帽本身的）,pcs(紅帽本身的，難用，6.4後只提供這個。GUI接口：hawk,lcmc,pacemaker-mgmt)

4.rgmanager

注意：上述CRM已經自帶了LRM

LRM層:由CRM經過子程序提供

RA層:

(a) heartbeatlegacy：heartbeat傳統類型的RA，一般位於/etc/ha.d/haresources.d/目錄下；

(b) LSB：Linux Standard Base, /etc/rc.d/init.d目錄下的腳本，至少接受4個參數：

{start|stop|restart|status}；cenost7後沒這些腳本，systemd管理

子類別：provider

STONITH：專用於實現調用STONITH設備功能的資源；一般爲clone類型；

上述各層能夠組合使用，組合方式：

heartbeatv1 能夠單獨使用，包含了各層（4層）功能

heartbeatv2 能夠單獨使用，包含了各層（4層）功能

heartbeatv3 + pacemaker 這個版本分層設計了，分拆爲heartbeat pacemaker

cluster-glue，須要搭配其餘層使用

corosync+ pacemaker

cman+ rgmanager (RHCS)

cman+ pacemaker

HACluster軟件簡介

Corosync：它屬於OpenAIS(開放式應用接口規範)中的一個項目corosync一版本中自己不具備投票功能，到了corosync 2.0以後引入了votequorum子系統也具有了投票功能了，若是咱們用的是1版本的，又須要用到票數作決策時那該如何是好呢；固然，在紅帽上把 cman + corosync結合起來用，可是早期cman跟pacemaker無法結合起來，若是想用pacemaker又想用投票功能的話，那就把cman當成 corosync的插件來用，把cman當成corodync的投票功能，固然，這裏結合了兩個了Messaging Lader；Corosync目前有兩個主流的版本：一個是2系列的，另外一個是1系列的穩定版；2版本和1版本差異很大，1版本不具備投票功能，2版本以後引入了votequorum後支持投票功能了；OpenAIS自從誕生以後，紅帽就基於這個規範研發了一個高可用集羣的解決方案叫cman，併爲cman提供了rgmangaer做爲資源管理器，而且容合conga全生命週期的管理接口造成了RHCS；

Conrosync是從OpenAIS這個大項目中分支出來的一個項目，而Pacemaker是heartbeat v3版本中分裂出來專門用於提供高可用集羣CRM的組件，功能十分強大， Coreosync在傳遞信息的時候能夠經過一個簡單的配置文件來定義信息傳遞的方式和協議等，Corosync能夠提供一個完整的HA功能，Corosync是將來的發展方向，在之後的新項目裏，通常採用Corosync，而heartbeat_gui能夠提供很好的HA管理功能，能夠實現圖形化的管理。

Pacemaker是一個集羣管理器。它利用首選集羣基礎設施（OpenAIS 或heartbeat）提供的消息和成員能力，由輔助節點和系統進行故障檢測和回收，實現性羣集服務（亦稱資源）的高可用性。

Heartbeat3與 2.x的最大差異在於，3 按模塊把的原來2.x 拆分爲多個子項目，而且提供了一個cluster-glue的組件，專用於Local ResourceManager 的管理。即heartbeat +cluster-glue + resouce-agent 三部分：

（1）hearbeat自己是整個集羣的基礎（cluster messaging layer），負責維護集羣各節點的

信息以及它們以前通訊；

（2）cluster-glue至關於一箇中間層，能夠將heartbeat和crm（pacemaker）聯繫起來，

主要包含2個部分，LRM和STONITH；

（3）resource-agent，就是各類的資源的ocf腳本，這些腳本將被LRM調用從而實現各

種資源啓動、中止、監控等等。

經過這三部分已可構成一套完整的HA集羣系統。可是，這還不夠，由於沒有管理工具。

而原GUI 工具Cluster Resource Manager （簡稱CRM）也被拆分由另外一獨立項目Pacemaker 負責。Pacemaker 提供了多種用戶接口：