1. 程式人生 > >Linux 高可用(HA)叢集基本概念詳解

Linux 高可用(HA)叢集基本概念詳解

目錄

十二、總結

一、高可用叢集的定義

  高可用叢集,英文原文為High Availability Cluster,簡稱HACluster,簡單的說,叢集(cluster)就是一組計算機,它們作為一個整體向用戶提供一組網路資源。這些單個的計算機系統 就是叢集的節點(node)。   高可用叢集的出現是為了使叢集的整體服務儘可能可用,從而減少由計算機硬體和軟體易錯性所帶來的損失。如果某個節點失效,它的備援節點將在幾秒鐘的時間內接管它的職責。因此,對於使用者而言,叢集永遠不會停機。   高可用叢集軟體的主要作用就是實現故障檢查和業務切換的自動化。只有兩個節點的高可用叢集又稱為雙機熱備,即使用兩臺伺服器互相備份。當一臺伺服器出現故障時,可由另一臺伺服器承擔服務任務,從而在不需要人工干預的 情況下,自動保證系統能持續對外提供服務。雙機熱備只是高可用叢集的一種,高可用集群系統更可以支援兩個以上的節點,提供比雙機熱備更多、更高階的功能,更能滿足使用者不斷出現的需求變化。

二、高可用叢集的衡量標準 

  HA(High Available), 高可用性群集是通過系統的可靠性(reliability)和可維護性(maintainability)來度量的。工程上,通常用平均無故障時間(MTTF)來度量系統的可靠性,用平均維修時間(MTTR)來度量系統的可維護性。於是可用性被定義為:HA=MTTF/(MTTF+MTTR)*100%   具體HA衡量標準: 99% 一年宕機時間不超過4天

99.9% 一年宕機時間不超過10小時

99.99% 一年宕機時間不超過1小時

99.999% 一年宕機時間不超過6分鐘

三、高可用叢集的層次結構

  說明:高可用叢集可分為三個層次結構,分別由紅色部分的Messaging與Membership層,藍色部分的Cluster Resource Manager(CRM)層,綠色部分的Local Resource Manager(LRM)與Resource Agent(RA)組成,下面我們就來具體說明(如上圖), 1.位於最底層的是資訊和成員關係層(Messaging and Membership),Messaging主要用於節點之間傳遞心跳資訊,也稱為心跳層。節點之間傳遞心跳資訊可以通過廣播,組播,單播等方式。成員關係(Membership)層,這層最重要的作用是主節點(DC)通過Cluster Consensus Menbership Service(CCM或者CCS)這種服務由Messaging層提供的資訊,來產生一個完整的成員關係。這層主要實現承上啟下的作用,承上,將下層產生的資訊生產成員關係圖傳遞給上層以通知各個節點的工作狀態;啟下,將上層對於隔離某一裝置予以具體實施。 2.叢集資源管理層(Cluster Resource Manager),真正實現叢集服務的層。在該層中每個節點都執行一個叢集資源管理器(CRM,cluster Resource Manager),它能為實現高可用提供核心元件,包括資源定義,屬性等。在每一個節點上CRM都維護有一個CIB(叢集資訊庫 XML文件)和LRM(本地資源管理器)元件。對於CIB,只有工作在DC(主節點)上的文件是可以修改的,其他CIB都是複製DC上的那個文件而來的。對於LRM,是執行CRM傳遞過來的在本地執行某個資源的執行和停止的具體執行人。當某個節點發生故障之後,是由DC通過PE(策略引擎)和TE(實施引擎)來決定是否搶奪資源。 3.資源代理層(Resource Agents),叢集資源代理(能夠管理本節點上的屬於叢集資源的某一資源的啟動,停止和狀態資訊的指令碼),資源代理分為:LSB(/etc/init.d/*),OCF(比LSB更專業,更加通用),Legacy heartbeat(v1版本的資源管理)。

核心元件的具體說明(如上圖): 1.ccm元件(Cluster Consensus Menbership Service):作用,承上啟下,監聽底層接受的心跳資訊,當監聽不到心跳資訊的時候就重新計算整個叢集的票數和收斂狀態資訊,並將結果轉遞給上層,讓上層做出決定採取怎樣的措施,ccm還能夠生成一個各節點狀態的拓撲結構概覽圖,以本節點做為視角,保證該節點在特殊情況下能夠採取對應的動作。 2.crmd元件(Cluster Resource Manager,叢集資源管理器,也就是pacemaker):實現資源的分配,資源分配的每個動作都要通過crm來實現,是核心組建,每個節點上的crm都維護一個cib用來定義資源特定的屬性,哪些資源定義在同一個節點上。 3.cib元件(叢集資訊基庫,Cluster Infonation Base):是XML格式的配置檔案,在記憶體中的一個XML格式的叢集資源的配置檔案,主要儲存在檔案中,工作的時候常駐在記憶體中並且需要通知給其它節點,只有DC上的cib才能進行修改,其他節點上的cib都是拷貝DC上。配置cib檔案的方法有,基於命令列配置和基於前臺的圖形介面配置。 4.lrmd元件(Local Resource Manager,本地資源管理器):用來獲取本地某個資源的狀態,並且實現本地資源的管理,如當檢測到對方沒有心跳資訊時,來啟動本地的服務程序等。 5.pengine元件: PE(Policy Engine):策略引擎,來定義資源轉移的一整套轉移方式,但只是做策略者,並不親自來參加資源轉移的過程,而是讓TE來執行自己的策略。TE(Transition Engine): 就是來執行PE做出的策略的並且只有DC上才執行PE和TE。

6.stonithd元件   STONITH(Shoot The Other Node in the Head,”爆頭“), 這種方式直接操作電源開關,當一個節點發生故障時,另 一個節點如果能偵測到,就會通過網路發出命令,控制故障節點的電源開關,通過暫時斷電,而又上電的方式使故障節點被重啟動, 這種方式需要硬體支援。   STONITH應用案例(主從伺服器),主伺服器在某一端時間由於服務繁忙,沒時間響應心跳資訊,如果這個時候備用伺服器一下子把服務資源搶過去,但是這個時候主伺服器還沒有宕掉,這樣就會導致資源搶佔,就這樣使用者在主從伺服器上都能訪問,如果僅僅是讀操作還沒事,要是有寫的操作,那就會導致檔案系統崩潰,這樣一切都玩了,所以在資源搶佔的時候,可以採用一定的隔離方法來實現,就是備用伺服器搶佔資源的時候,直接把主伺服器給STONITH,就是我們常說的”爆頭 ”。

四、高可用叢集的分類   

1.雙機熱備(Active/Passive) 官方說明:Two-node Active/Passive clusters using Pacemaker and DRBD are a cost-effective solution for many High Availability situations.

2.多節點熱備(N+1) 官方說明:By supporting many nodes, Pacemaker can dramatically reduce hardware costs by allowing several active/passive clusters to be combined and share a common backup node.

3.多節點共享儲存(N-TO-N) 官方說明:When shared storage is available, every node can potentially be used for failover. Pacemaker can even run multiple copies of services to spread out the workload.

4.共享儲存熱備 (Split Site) 官方說明:Pacemaker 1.2 will include enhancements to simplify the creation of split-site clusters.

五、高可用叢集軟體

Messaging and Membership Layer(資訊與關係層): heartbeat (v1,v2,v3),heartbeat v3 分拆  heartbeat pacemaker cluster-glue

corosync

cman

keepalived

ultramokey

Cluster Resource Manager Layer(資源管理層,簡稱:CRM): haresource,crm (heartbeat v1/v2)

pacemaker (heartbeat v3/corosync)

rgmanager (cman)

常用組合: heartbeat v2+haresource(或crm) (說明:一般常用於CentOS 5.X)

heartbeat v3+pacemaker (說明:一般常用於CentOS 6.X)

corosync+pacemaker (說明:現在最常用的組合)

cman + rgmanager (說明:紅帽叢集套件中的元件,還包括gfs2,clvm)

keepalived+lvs (說明:常用於lvs的高可用)

總結:我們經常在技術部落格中看到,heartbeat+pacemaker實現mysql高可用,或corosync+pacemaker實現mysql高可用等,有的博友會問了,我們到底用什麼好呢?經過上面的說明大家應該有所瞭解!

六、共享儲存

  說到叢集, 我們不得不說到,共享儲存,因為不管理是Web高可用也,Mysql高可用也好,他們的資料都是共享的就一份,所有必須放在共享儲存中,主節點能訪問,從節點也能訪問。下面我們就簡單說一下共享儲存。 1.DAS:(Direct attached storage)直接附加儲存 說明:裝置直接連線到主機總線上的,距離有限,而且還要重新掛載,之間有資料傳輸有延時 RAID 陣列

SCSI 陣列

2.NAS:(network attached storage)網路附加儲存  說明:檔案級別的共享 NFS

FTP

CIFS

3.SAN:(storage area network)儲存區域網路  說明:塊級別的,模擬的scsi協議 FC光網路(交換機的光介面超貴,一個差不多2萬,如果使用這個,代價太高)

IPSAN(iscsi)存取快,塊級別,廉價

七、叢集檔案系統與叢集LVM(叢集邏輯卷管理cLVM)

叢集檔案系統:gfs2、ocfs2 叢集LVM:cLVM 注:一般用於高可用雙主模型中(如下圖)

八、高可用叢集的工作原理

說明:這裡主要以主/從節點的高可用來說明工作原理。   主伺服器和從伺服器建立雙機熱備,基本上都是共享一個儲存,以mysql為例。通常情況下,資料庫檔案掛載在主資料庫伺服器上,使用者連線到主伺服器上進行資料庫操作。當主伺服器出現故障時,從伺服器就會自動掛載資料庫檔案,並接替主伺服器的工作。使用者在未通知的情況下,通過從資料庫連線到資料庫檔案進行操作。等主伺服器的故障修復之後,又可以重新提供服務;   那麼,從伺服器是如何知道主伺服器掛掉了呢,這就要使用一定的檢測機制,如心跳檢測,也就是說每一個節點都會定期向其他節點通知自己的心跳資訊,尤其是主伺服器,如果從伺服器在幾個心跳週期內(可自行設定心跳週期)還沒有檢測到的話,就認為主伺服器宕掉了,而這期間在通告心跳資訊當然不能使用tcp傳輸的,如果使用tcp檢測,還要經過三次握手,等手握完了,不定經過幾個心跳週期了,所以在檢測心跳資訊的時候採用的是udp的埠694來進行傳遞資訊的,如果主伺服器在某一端時間由於服務繁忙,沒時間響應心跳資訊,這個時候從伺服器要是把主服務資源搶過去(共享資料檔案),但是這個時候主伺服器還沒有宕掉,這樣就會導致資源搶佔,就這樣使用者在主從上都能訪問,如果僅僅是讀操作還沒事,要是有寫的操作,那就會導致檔案系統崩潰,這樣一切都玩了,所以在資源搶佔的時候,可以採用一定的隔離方法來實現,就是從伺服器搶佔資源的時候,直接把主伺服器給“STONITH”,就是我們常說的“爆頭”;   那麼,我們又用什麼方式來檢測心跳資訊呢?就是通過心跳線來檢測。執行在從伺服器上的Heartbeat可以通過乙太網連線檢測主伺服器的執行狀態,一旦其無法檢測到主伺服器的“心跳”則自動接管主伺服器的資源。通常情況下,主、從伺服器間的心跳連線是一個獨立的物理連線,這個連線可以是序列線纜、一個由“交叉線”實現的乙太網連線。Heartbeat甚至可同時通過多個物理連線檢測主伺服器的工作狀態,而其只要能通過其中一個連線收到主伺服器處於活動狀態的資訊,就會認為主伺服器處於正常狀態。從實踐經驗的角度來說,建議為Heartbeat配置多條獨立的物理連,以避免Heartbeat通訊線路本身存在單點故障。   上面的原理中我們提到了“隔離方法”,下面我們來說一說,隔離方法有兩種,一種是節點隔離,另一種是資源隔離。節點隔離就是我們常說的STONITH(Shoot The Other Node In the Head ,俗稱“爆頭”),意思就是直接切斷電源;常用的方法是所有節點都接在一個電源交換機上,如果有故障,就直接導致該節點的電壓不穩定,或斷電,讓有故障的節點重啟或關閉。(如下圖),而資源隔離,就是 fencing 直接把某種資源截獲過來。

  下面我們再來說一說“心路線”的型別,一種是序列電纜,另一種就是我們常看到的乙太網線(交叉的雙絞線),它們各有優缺點,序列電纜,被認為是比乙太網連線安全性稍好些的連線方式,因為hacker無法通過序列連線執行諸如telnet、ssh或rsh類的程式,從而可以降低其通過已劫持的伺服器再次侵入備份伺服器的機率。但序列線纜受限於可用長度,因此主、備伺服器的距離必須非常短。乙太網線連線,使用此方式可以消除序列線纜的在長度方面限制,並且可以通過此連線在主從伺服器之間同步檔案系統,從而減少了對正常通訊連線頻寬的佔用。(如下圖)

九、如何保障系統的高可用

我們都知道,單點是系統高可用的大敵,單點往往是系統高可用最大的風險和敵人,應該儘量在系統設計的過程中避免單點。方法論上,高可用保證的原則是“叢集化”,或者叫“冗餘”:只有一個單點,掛了服務會受影響;如果有冗餘備份,掛了還有其他backup能夠頂上。

保證系統高可用,架構設計的核心準則是:冗餘。

有了冗餘之後,還不夠,每次出現故障需要人工介入恢復勢必會增加系統的不可服務實踐。所以,又往往是通過“自動故障轉移”來實現系統的高可用。

接下來我們看下典型網際網路架構中,如何通過冗餘+自動故障轉移來保證系統的高可用特性。

十、常見的網際網路分層架構

常見網際網路分散式架構分為:

(1)客戶端層:典型呼叫方是瀏覽器browser或者手機應用APP

(2)反向代理層:系統入口,反向代理

(3)站點應用層:實現核心應用邏輯,返回html或者json

(4)服務層:如果實現了服務化,就有這一層

(5)資料-快取層:快取加速訪問儲存

(6)資料-資料庫層:資料庫固化資料儲存

整個系統的高可用,又是通過每一層的冗餘+自動故障轉移來綜合實現的。

十一、分層高可用架構實踐

【客戶端層->反向代理層】的高可用 【客戶端層】到【反向代理層】的高可用,是通過反向代理層的冗餘來實現的。以nginx為例:有兩臺nginx,一臺對線上提供服務,另一臺冗餘以保證高可用,常見的實踐是keepalived存活探測,相同virtual IP提供服務。 自動故障轉移:當nginx掛了的時候,keepalived能夠探測到,會自動的進行故障轉移,將流量自動遷移到shadow-nginx,由於使用的是相同的virtual IP,這個切換過程對呼叫方是透明的

【反向代理層->站點層】的高可用 【反向代理層】到【站點層】的高可用,是通過站點層的冗餘來實現的。假設反向代理層是nginx,nginx.conf裡能夠配置多個web後端,並且nginx能夠探測到多個後端的存活性。 自動故障轉移:當web-server掛了的時候,nginx能夠探測到,會自動的進行故障轉移,將流量自動遷移到其他的web-server,整個過程由nginx自動完成,對呼叫方是透明的。

【站點層->服務層】的高可用 【站點層】到【服務層】的高可用,是通過服務層的冗餘來實現的。“服務連線池”會建立與下游服務多個連線,每次請求會“隨機”選取連線來訪問下游服務。 自動故障轉移:當service掛了的時候,service-connection-pool能夠探測到,會自動的進行故障轉移,將流量自動遷移到其他的service,整個過程由連線池自動完成,對呼叫方是透明的(所以說RPC-client中的服務連線池是很重要的基礎元件)。

【服務層>快取層】的高可用 【服務層】到【快取層】的高可用,是通過快取資料的冗餘來實現的。

快取層的資料冗餘又有幾種方式:第一種是利用客戶端的封裝,service對cache進行雙讀或者雙寫。 快取層也可以通過支援主從同步的快取叢集來解決快取層的高可用問題。

以redis為例,redis天然支援主從同步,redis官方也有sentinel哨兵機制,來做redis的存活性檢測。 自動故障轉移:當redis主掛了的時候,sentinel能夠探測到,會通知呼叫方訪問新的redis,整個過程由sentinel和redis叢集配合完成,對呼叫方是透明的。

說完快取的高可用,這裡要多說一句,業務對快取並不一定有“高可用”要求,更多的對快取的使用場景,是用來“加速資料訪問”:把一部分資料放到快取裡,如果快取掛了或者快取沒有命中,是可以去後端的資料庫中再取資料的。

這類允許“cache miss”的業務場景,快取架構的建議是: 將kv快取封裝成服務叢集,上游設定一個代理(代理可以用叢集冗餘的方式保證高可用),代理的後端根據快取訪問的key水平切分成若干個例項,每個例項的訪問並不做高可用。 快取例項掛了遮蔽:當有水平切分的例項掛掉時,代理層直接返回cache miss,此時快取掛掉對呼叫方也是透明的。key水平切分例項減少,不建議做re-hash,這樣容易引發快取資料的不一致。

【服務層>資料庫層】的高可用

大部分網際網路技術,資料庫層都用了“主從同步,讀寫分離”架構,所以資料庫層的高可用,又分為“讀庫高可用”與“寫庫高可用”兩類。

【服務層>資料庫層“讀”】的高可用 【服務層】到【資料庫讀】的高可用,是通過讀庫的冗餘來實現的。

既然冗餘了讀庫,一般來說就至少有2個從庫,“資料庫連線池”會建立與讀庫多個連線,每次請求會路由到這些讀庫。 自動故障轉移:當讀庫掛了的時候,db-connection-pool能夠探測到,會自動的進行故障轉移,將流量自動遷移到其他的讀庫,整個過程由連線池自動完成,對呼叫方是透明的(所以說DAO中的資料庫連線池是很重要的基礎元件)。

【服務層>資料庫層“寫”】的高可用 【服務層】到【資料庫寫】的高可用,是通過寫庫的冗餘來實現的。

以mysql為例,可以設定兩個mysql雙主同步,一臺對線上提供服務,另一臺冗餘以保證高可用,常見的實踐是keepalived存活探測,相同virtual IP提供服務。 自動故障轉移:當寫庫掛了的時候,keepalived能夠探測到,會自動的進行故障轉移,將流量自動遷移到shadow-db-master,由於使用的是相同的virtual IP,這個切換過程對呼叫方是透明的。

十二、總結

高可用HA(High Availability)是分散式系統架構設計中必須考慮的因素之一,它通常是指,通過設計減少系統不能提供服務的時間。

方法論上,高可用是通過冗餘+自動故障轉移來實現的。

整個網際網路分層系統架構的高可用,又是通過每一層的冗餘+自動故障轉移來綜合實現的,具體的:

(1)【客戶端層】到【反向代理層】的高可用,是通過反向代理層的冗餘實現的,常見實踐是keepalived + virtual IP自動故障轉移

(2)【反向代理層】到【站點層】的高可用,是通過站點層的冗餘實現的,常見實踐是nginx與web-server之間的存活性探測與自動故障轉移

(3)【站點層】到【服務層】的高可用,是通過服務層的冗餘實現的,常見實踐是通過service-connection-pool來保證自動故障轉移

(4)【服務層】到【快取層】的高可用,是通過快取資料的冗餘實現的,常見實踐是快取客戶端雙讀雙寫,或者利用快取叢集的主從資料同步與sentinel保活與自動故障轉移;更多的業務場景,對快取沒有高可用要求,可以使用快取服務化來對呼叫方遮蔽底層複雜性

(5)【服務層】到【資料庫“讀”】的高可用,是通過讀庫的冗餘實現的,常見實踐是通過db-connection-pool來保證自動故障轉移

(6)【服務層】到【資料庫“寫”】的高可用,是通過寫庫的冗餘實現的,常見實踐是keepalived + virtual IP自動故障轉移