1. 程式人生 > >淺談群集與分布式基礎知識

淺談群集與分布式基礎知識

負載均衡 分布式 高可用 群集 高性能

長期以來對於做IT的人員來說可能會經常聽見一個名詞,群集,什麽負載均衡群集,高可用群集,雙活群集,這對於非相關人員來說根本不明白是什麽意思,好像群集很神秘,很高大上,其實群集的概念並沒有想象中那麽復雜,本文老王會試著用比較簡單的語言,來為大家分享我所學習了解的群集知識,盡量讓只有簡單服務器 網絡基礎的朋友也可以聽懂,如果有說的不對的地方歡迎指正


什麽是群集呢,簡單來說,群集就是把一堆計算機組合起來做一件事情,把一堆計算機組合起來一起幹活,它們就可以叫做群集,通常群集給人的感覺就好像是一個“整體計算機”在提供服務。

具體細化來講,群集又分為可以分為高可用群集,負載均衡群集,以及高性能計算群集,其中比較常見的是高可用性群集和負載均衡群集


什麽是高可用群集呢,所謂高可用群集,即是說該群集具備故障轉移切換機制,當其中一臺服務器宕機,其它服務器可以快速的接管宕機服務器提供的服務,確保業務的持續可用性,例如,某公司有一個網站平臺,提供網頁端查詢服務,有一個前端和兩個後端,當用戶在網頁查詢時,實際上前端會去把請求丟給後端去做查詢,如果我們做了高可用群集,這時候一旦一臺後端壞了,那麽前端還可以繼續使用另外一臺後端進行查詢,保證用戶可以正常查詢訪問。


這裏的關鍵點在於,高可用群集,通常是用於後端,例如數據庫群集,虛擬化群集,應用程序群集等有狀態運行的服務,當發生故障時,需要將宕機服務器上面運作的內容轉移至其它活著的服務器上繼續運行。既然要做這種轉移,那麽數據庫本身的實體,應該存在哪裏呢,通常情況下,高可用性群集裏面數據庫一般會存在於共享的存儲中,即所有群集內服務器都可以訪問到的存儲,這樣當切換時,就不需要實際上把數據庫拷貝轉移過去,真正轉移的,只是承擔數據庫查詢服務器的這個角色,從而大大減少了轉移所需要花費的時間,還有一種場景是所有群集內服務器數據庫內容都存放在節點本機,然後節點間相互做存儲的復制也是可以的。


還有個關鍵內容,剛才我們說過群集給人的感覺就好像是一個整體的計算機在提供服務,那麽用戶或者是前端程序是怎麽感應到後端的群集的呢,通常情況下,不論是高可用群集,負載均衡群集,還是高性能群集,都會提供一個群集化的管理名稱,例如,當我們從前端去查詢到後端服務器的時候,實際上我們是查的群集管理名稱,而不是去查單一的數據庫服務器名稱,群集會幫我們和其中的節點建立聯系,這樣連接到群集化的管理名稱後,當群集內的服務器出現故障,群集會自己去根據情況做出處理相應,重新挑選合適的節點提供服務,對於使用方來說是不會過多的感知的,前端或者用戶始終是訪問同一個群集名稱。


這裏我們說了高可用群集的幾個特征,希望大家記住


1.高可用群集通常用於後端程序,例如數據庫,虛擬化主機

2.高可用群集通常情況下所有群集內服務器都訪問了共享存儲,便於發生故障快速轉移

3.高可用群集提供統一對外的群集化管理名稱

4.高可用群集主要用於提供有狀態服務的持續運行,確保單臺後端節點宕機不會影響業務,可以提供故障轉移機制


除了以上四點,通常情況下高可用群集還應該具備以下幾個特點


1.高可用群集應該具備心跳檢測機制,即群集,群集節點間,應該可以通過某種機制,得知對方是否存活,通常情況下群集系統會將次實現為ping檢測,實際旳握手檢測,或基於給定的API檢測


2.高可用群集中各個節點通常可以感應到群集內各個節點當前承擔的群集角色,以便發生故障時可以進行轉移


3.高可用性群集中各個節點通常可以感應到群集內節點的新增,添加,刪除,上線,下線等狀態。


4.高可用群集通常群集自身,以及各節點應該具備自身健康監測,通常實現為一種類似於投票的機制,每個節點確保自己是健康的情況下可以發出一個聲明(投票),讓群集知道我當前是可以提供群集功能的節點,當整個群集內如果不健康,即未能投票的節點(也可能是節點+見證) 達到一定數量時,即會判定整個群集當前不健康,不能正常提供群集工作,會出現停止提供服務,或暫停等狀態


以上為關於高可用性群集的簡單介紹,及特征描述,在文章後面部分我會為大家進行多次舉例,幫助大家理解高可用群集的概念



高可用群集常見的名詞解釋:


節點:通常指群集內參與協作工作的單個服務器


群集應用:通常是指運行在一個已經實現了高可用性機制的群集上的應用,群集會通過相應的的檢測機制確保應用的健康狀態,通常群集應用會被托管運行在群集中的單個節點上,當該節點出現故障時,群集會將群集應用轉移至其它活著的節點上繼續運行,保證群集應用一直是可用的。


群集磁盤:通常是指高可用性群集內已經實現為可以被群集內服務器共同訪問的共享磁盤,通常情況下在某一時刻單塊群集磁盤會被掛載上線在群集中的單個節點上


故障轉移群集:通常描述為一種高可用性群集類型,通常故障轉移群集指同一時刻群集內只有一臺節點提供群集應用的訪問服務,當這臺服務器出現故障時,群集系統可以快速做出反應,將故障節點上面承載的群集應用轉移至其它活著的節點提供服務。


計劃內停機時間:已經可以被預見,被預料的正常停機時間,例如群集服務器進行計劃性的補丁修復,網絡切換,服務器升級等,通常計劃內停機時間對於業務來說是在可以被接受的範圍,可以在已知情況下利用實時遷移,在線轉移等技術完成轉移,最小化停機時間,順利完成計劃內的維護工作


計劃外停機時間:不可被預見的,忽然發生的災難性停機,例如在不知情的情況下服務器電源壞掉,硬盤不可訪問,造成業務層面不可訪問,是較為嚴重的,通常情況下企業會實現例如高可用性群集,或者災難備份來應對計劃外停機事件發生,通常情況下SLA的計算,真正會被承認宕機時間的也就是說的這段計劃外的停機事件


群集管理名稱:群集對外的一個集中的,邏輯的名稱,該名稱在域範圍,解析範圍內應該是唯一的,不可重復的,前端程序或者用戶訪問群集始終是訪問的群集管理名稱,也可以叫做群集對外名稱,通常情況下,如果在高可用性群集裏面實現基於群集的高可用的應用,也會有單獨的虛擬應用名稱,這個名稱應該是基於群集管理名稱創建出來的,或依附於群集管理名稱,群集管理名稱會提供的是一個邏輯的訪問域名,或一個群集的IP地址,群集管理名稱或群集IP地址通常會綁定在活著的一個群集節點上,對於用戶和前端實現了邏輯屏蔽機制,前端只知道我去連接到這樣一個域名,但並不會知道群集內有幾臺服務器在提供服務。


在高可用群集中通常又分為多種形態,以從運行模式和群集存儲模式為例


高可用群集的運作模式通常又分為主從模式,互備模式,雙主模式


主從模式:也叫做AP模式(active-passive)同一時刻一個群集應用只能在一個節點上運行提供服務,當前端或用戶通過群集管理名稱訪問時只會有一臺服務器提供服務,這臺服務器扮演主服務器角色,其它服務器扮演備服務器角色,當主服務器不可用時,群集會感知到主服務器壞了,然後切換至其它備服務器繼續提供服務。


互備模式:這種模式,有人也叫它是AA模式,對此嘛老王也是持有保留意見的,說它是雙活的,似乎也無可非議,但平常會需要浪費掉一半的群集計算資源這個。。。舉個例子,如果是一套數據庫群集,是可以做到多個實例,兩個節點的話,比如節點一是實例一的主節點,實例二的備節點,節點2是實例1的備節點,實例2的主節點,這樣以多花費一半的資源的代價下實現了兩個服務器都可以同時對外提供服務,但是,一旦節點1這時候出現故障,節點2就需要承載兩個實例,要實現這種模式的高可用性群集,需要做好服務器的規劃,確保每臺服務器都是可以承載兩個實例的配置才行。


雙主模式:也叫做AA(active-active)模式,在老王看來,真正的雙主,或者說雙活AA模式群集,應該是這樣的,例如在群集系統基礎上實現負載均衡器機制,或者在群集系統前面再擺一個負載均衡器,真正的雙活模式,應該是用戶訪問時會通過負載均衡機制把用戶請求丟給群集裏面一個節點,下一個用戶訪問又是另外一個節點,這樣真正的節點同時對外提供服務,老王認為才是真正的AA模式,目前看起來MySQL上的Amoeba是這樣,微軟的SOFS也是這樣。


從群集存儲模式區分


通常情況下分為


共享磁盤模式


即所有群集節點都訪問共享的群集磁盤,群集應用數據也寫入到共享磁盤中,通常情況下此架構下實現為AP模式較多,缺點就是會對群集資源進行浪費,同一時間只有一臺節點提供服務,存儲是單一故障點,需要考慮存儲的高可用,少數群集應用可以實現共享磁盤模式下的雙活,例如oracle rac,可以在使用共享磁盤的情況下,負載均衡各個節點負載,讓多個節點同時對外提供服務。


無共享磁盤模式


即所有每個群集節點都在節點本身寫入數據磁盤,不使用共享磁盤,但各節點之間可以進行數據磁盤數據的同步,通常實現為主服務器和輔助服務器,主服務器提供讀寫服務,輔助服務器從主服務器復制數據庫,當故障發生時,通常可以執行手動故障轉移,或配合見證機制實現自動故障切換,一些群集應用也會提供輔助服務器的可讀功能,通常數據庫應用中使用。


有朋友看到這裏可能會問,有必要嗎,企業有必要做這種高可用性群集嗎,這東西涉及到這麽多概念,其實真的很有必要,設想一下,一個雲盤網站,或者一個購物網站,肯定是希望24小時能夠正常提供服務的,一旦沒有實現高可用群集,那網站後臺只有一臺服務器,這臺服務器壞了,所有客戶都將無法訪問購物網站或者雲盤網站,這對於運營商來說是災難性的,會導致業務損失,喪失用戶對你網站的信心,因此,老王認為凡是成熟的商業網站,都應該實施高可用群集,來保證可以持續提供服務,即使沒有條件實施高可用群集,也應該實施備份恢復等機制。



接下來負載均衡群集


這類群集很好理解,我們上面講了高可用群集,或者說是故障轉移群集,主要強調的是,群集應用同一時間只在一個節點上運行,同時會讀取寫入內容到共享磁盤,檢測到一臺節點宕機,群集會把角色服務等有狀態的內容轉移至另外一個節點上繼續運行。負載均衡群集主要倡導的概念和故障轉移群集有所不同,在負載均衡群集中,通常各節點間都是無狀態的,也並沒有共享磁盤,發生故障時候也不用把自身承載的內容轉移給其它節點,因為在負載均衡群集中,每個節點的內容都是一致的,冗余的,負載均衡群集只是提供一個均衡機制,可以確保用戶的訪問請求,會在不同的,具備相同冗余內容的節點上進行負載均衡,當其中一個節點不可用,負載均衡群集直接自動路由到其它可用的節點上繼續為用戶提供服務。


負載均衡群集,通常也叫做前端群集,它與故障轉移群集的相同點是他們都提供一個對外的群集訪問名稱,當用戶訪問一個負載均衡群集時,感覺上就好像是在訪問一臺服務器一樣,但其實負載均衡會根據算法去負載均衡,讓不同用戶訪問到不同的服務器上。不同點在於,故障轉移群集需要進行故障轉移,當檢測到一個節點宕機,其它節點會檢查群集數據庫,查詢宕機節點承載服務,然後進行上線。負載均衡群集則不會發生這種故障轉移過程,因為負載均衡群集提倡的是無狀態的,每個節點上的資源都是一樣的,一個節點宕機,直接負載均衡至其它節點上,並不會產生離線上線角色轉移等事情。


因此負載均衡群集特別適合於像是Web前端這樣的應用,通過負載均衡讓每個節點都提供服務,最大化利用群集資源,在某些程度上也可以提供Web前端的處理能力


負載均衡群集系統通常具備以下特點


1.負載均衡群集系統通常可以設定基於IP、端口等進行負載調度分發

2.負載均衡群集系統通常可以設定群集各節點負載均衡的比例,例如可以指定節點1承載60%的請求,節點20承載40%的請求

3.負載均衡群集系統通常可以設定優先級,可以根據優先等級進行調度,排隊,丟棄,分配。

4.負載均衡群集系統通常可以基於上下文感知,例如根據不同的請求內容,分配到不同的節點服務器。

5.負載均衡群集系統通常也需要心跳檢測機制,確保每次挑選出來提供負載均衡服務的機器都是健康可用的,負載均衡系統需要知道群集內節點的存活狀態,當其中一個節點不可用時,下次群集將不會將負載均衡請求丟至該節點,通常實現為ping檢測,或實際的路徑網頁訪問檢測。


通常情況常見負載均衡群集有微軟的NLB,ARR,linux下面的LVS、HAProxy、Nginx等解決方案


還有一種最簡單的負載均衡群集實現方式,DNS輪詢,其實嚴格來講老王認為這只是種簡單的輪詢技術,並不能稱得上是負載均衡或者群集


DNS輪詢做的,只是將同一個域名的訪問解析到不同的服務器上,但是解析負載並不是均衡的,也並不是可控的

當其中一個節點宕機,但DNS輪詢還會繼續輪詢到該地址,並不具備檢測機制,而且DNS通常還具備緩存機制,例如當前域名解析到的服務器出現故障,你重新分配至其它服務器,但客戶端也並不會立刻可用,除非等到DNS緩存超時


因此DNS輪詢系統通常用於最簡單,對於負載均衡,故障轉移沒有過多要求的Web前端服務器,通常情況下使用DNS輪詢系統並不會單獨使用它,而是會配合nginx,arr,LVS等負載均衡群集技術一起實現。


當我們實現了負載均衡之後,假設現在是三個節點的一個負載均衡群集,提供一個群集訪問名稱進行訪問,每次用戶發起訪問,負載均衡群集會根據綜合調度策略,優先級,上下文等算法選出一臺合適的節點來提供服務,這時候如果當這臺節點壞掉,或者用戶被負載均衡到了其它節點上,那麽用戶session如何處理是個問題,例如當前負載均衡群集是個購物網站,用戶正在購買東西添加至購物車,這時候忽然節點1出現故障,負載均衡會自動切換到節點2提供服務,但是,之前用戶已經與節點1建立了session狀態鏈接,即用戶的登陸信息,會話信息,雖然說負載均衡群集可以切換到其它節點繼續提供服務,但是之前在節點1建立的session則會丟失,即是說,這時候一旦節點1壞了,切換到節點2,需要用戶重新登錄才可以,頻繁需要重新登錄這對於用戶來說是不可接受的,特別是對於一些嚴重依賴於session的網站


因此實現了負載均衡群集之後,session存在哪裏是個問題,是使用session保持技術,還是將session存在數據庫,或單獨實現session server是值得思考的問題。


簡單總結下,高可用群集通常指的是後端群集,當發生故障時,會發生實際的故障轉移,將被宕機節點上已有的群集應用,群集資源等有狀態性的資源服務,轉移至其它活著的節點上繼續運行。

負載均衡群集通常是值得前端群集,部署多個內容一致的無狀態服務器,負載均衡群集根據綜合算法,將每次用戶的請求轉發至不同的合適的節點上進行工作,並不會發生有狀態的故障轉移,單臺節點下線,負載均衡只是自動轉發請求到其它節點上。


在講高性能計算群集之前,老王想先和大家談談分布式,以及分布式和群集的區別


在老王看來,分布式主要強調的更多的是一種對於應用處理實現的一種思維,算法的實現方式,分布式更多的時候指的是把一項工作,分攤成多個小任務,交給不同的節點去處理,然後把多個節點處理的結果最終匯集出成果,分布式中的節點不同於群集,一個分布式節點可以是群集,也可以是單機,分布式的核心思維是利用多個節點分攤來完成工作,每個節點完成的任務都是不一樣的,以眾人合力來達成同一個目標,老王認為這就是分布式的思想。


而群集的概念相對來說,主要是指將一組服務器結合在一起共同協作,群集主要強調的是,我們來共同維護這一件工作,保證這項工作始終是可以正常對外提供服務的,強調的是集中維護一件事,確保單一工作的持續可用或均衡負載。

例如一家蛋糕店,要賣蛋糕,群集是為了確保賣蛋糕這件事始終是可以正常運行的,例如如果是群集的思維,可能是正常情況下一個服務員賣蛋糕,這個服務員生病了,其它服務員立刻接受她的工作繼續賣蛋糕,這裏我們把服務員形成了一個群集,賣蛋糕就是個群集對外訪問名稱,他們共同完成賣蛋糕這一件事,群集還可能是開了多個窗口,有兩個服務員一起買蛋糕,這就是群集中所說的雙活模式。


不論是負載均衡群集和高可用群集,它們強調的概念都是利用多臺計算機做好同樣的一件事,這裏關鍵的點在於,群集的概念中比較看重一致性,例如負載均衡群集,集中對外提供訪問,但每臺機器必須內容是一致的,故障轉移集群,必須確保每臺機器都能知道對方正在運行的負載,發生故障時必須一致的把原節點承載的應用進行上線。

分布式這個詞通常用於,分布式算法,分布式計算等詞語,通常它們指的都是通過一種,將一項工作,分解成多個小任務同時執行,然後利用多個節點的能力,匯集起來完成整體的目標,例如賣蛋糕這個例子,分布式的思維,強調的就是把賣蛋糕分解成多個步驟,例如1個服務員負責給客戶裝袋子,一個服務員負責給客戶取蛋糕,兩個服務員共同完成了賣蛋糕這件事。


所謂的分布式群集,在老王看來,也是一種分布式技術和群集技術的整合,能夠實現這種技術,前提要求群集必須要能夠支持識別這種分布式技術,然後分布式技術利用多個服務器組合起來形成的群集技術來完成分布式的計算。

通過上述解釋相信大家可以看懂,群集主要強調的是把一組計算機組合起來協作工作,共同對外提供服務的能力,大家共同確保一件事的正常運行,或多個節點每個節點都運行同一件事的能力。


分布式主要強調的是將一件事分攤成多個不同的小事,利用多個節點處理的能力來有效率的共同完成大目標,實務應用中,通常情況下,分布式多用於像是科研探索,工業計算,大數據等領域,將真正復雜的事情,單臺服務器上執行效率低的事情,分攤到多臺服務器,利用多臺服務器的計算能力來共同完成這一件事。


分布式計算技術也經常被一些國際科研組織使用,通過我們每個人共享自己電腦閑時的運算能力,進行分布式運算,完成後再把計算結果通過網絡發送回服務器,這樣的計算方式可以幫助一些進行大型計算研究的機構加速進步的速度。


說到分布式計算,不得不提並行計算和串行計算,通常情況下在並行計算和串行計算都是指應用程序運行執行的一種形態,例如,並行則是說單個應用可以同時在單機多個CPU下面執行,或者是指同一時間,多個節點同時處理運算負載的能力。相對來說,串行計算則是指運算過程必須按照順序執行,只有運行完整個job才可執行下一個。並行計算則是多個節點同時運行多個job,不需要等待前一個完成再進行計算


如果一個計算是串行工作的,即使它是在群集上跑的,也不是並行計算


相對來說,老王認為分布式計算與並行計算差不太多,首先它們都對計算節點沒有過多的要求,節點服務器不必一定要使用專用的高級服務器,正常的商用服務器或者工作站都可以完成分布式計算,大體強調的都是將一項復雜的工作,分成多個子任務,然後節點執行完成後匯集起來形成結果。


通常情況下,分布式計算更加適用於在計算尋找模式的東西,分析計算,相加計算等。分布式的計算被分解後的小任務互相之間有獨立性,節點之間的結果幾乎不互相影響,實時性要求不高,比較松散化。


並行計算則比較傾向於一些海量數據進行分析處理的場合,每個節點的每一個任務塊都是必要的,計算的結果相互影響,要求每個節點的計算結果要絕對正確,並且在時間上做到同步



解釋完了分布式之後,我們回過頭來看下高性能計算集群,也可以說是高性能計算

我們先來看看群集的關註點


高可用群集更關註的是我這個群集對外提供的正常可用時間有沒有達到幾個九


負載均衡群集群集更關註的是我這個負載均衡群集可以同時支持的訪問數量,以及節點的負載情況是否符合預期


高性能群集,則更加關註群集整體的計算性能,群集到底每秒能處理多少數據,群集處理數據的速度可以達到多塊,老王認為高性能群集是個大的概念,它的目的是要群集獲取最快最高的計算能力,因此,一個高性能計算,可以能會包括分布式的job調度,並行運行的能力,也可能會結合負載均衡,故障轉移等機制,確保計算能力的持續可用


和我們前面說的不同,高性能群集通常會采用專用的操作系統,專用的高端服務器,和我們平時用的普通商用服務器不同,高性能服務器通常會具備很多顆CPU,巨大的內存,高性能服務器之間通常會使用最新最快最可靠的網絡技術,例如InfiniBand的網絡互連,單個高性能服務器硬件的處理性能在高性能計算中很重要,除了硬件外,通常高性能計算會通過專用的系統進行管理控制,在管理過程中,可以把整個高性能群集的計算能力集中進行分配處理,最終提供整個高性能群集計算能力。


通常情況下高性能計算群集更多的會被應用於數學,工業,科研領域等,需要在短時間內處理多維度的計算,這時候可以利用高性能計算群集的能力,來完成復雜的科學計算。


像是這些年除了高性能計算群集,也聽到有人提過超算,我們國家的神威,天河1號,天河2號等等,實際上老王老王認為高性能計算和超算差不多,都是為了提供最高的性能和最快的處理能力,最早期的超算,通常指的是單一的大型機器,高速度,大容量,具備特殊的CPU內存,當時最早有美國ILLIAC-IV,歐洲尤金,中國銀河等等,最早的超級計算機只能用於政府,能源軍方,航天等,只有很少數的人可以用到,後來隨著信息化的逐漸發展,一些企業也有了需要用到超算能力的需求,怎麽辦,於是後來開始提出做群集把,我們通過把一些高性能服務器通過高速網絡鏈接起來形成群集,然後群集利用每個節點的能力綜合起來提供整體運算能力吧,於是後來開始有很多廠商推出這種高性能群集,將原來超級計算機一個龐然大物的運算能力,由多個節點結合起來實現。


甚至老王認為我國的天河2號等超算,背後也是基於這種高性能群集技術實現的,將多臺配置性能極高的節點盡可能的靠近,綜合利用他們的運算能力一起完成並行的運算,如果說差異的話,老王認為能夠稱得上是超算的,通常規模會比普通的高性能計算大一些,定制化的硬件會更多,更加特定化,例如天河2號可能會使用特定的CPU,特定的內存,以及特定的服務器架構,提供也運算能力也更加強大。


案例總結


一個虛擬化群集,由多臺物理機組成,在群集中創建了虛擬機,存放在共享磁盤中,當檢測到一臺物理機宕機,虛擬機會轉移到其它節點繼續運行。這是高可用群集



一個數據庫群集,由多臺服務器組成,基於群集創建了數據庫的實例,數據庫內容存放在共享磁盤中,當檢測到一臺數據庫服務器宕機,數據庫服務器角色會轉移到其他節點繼續運行。這是高可用群集


由多臺相同網站內容的無狀態Web服務器組成,通過統一的域名訪問,所有節點輪詢對外提供訪問服務,一臺Web服務器下線,用戶自動訪問其他節點,這是負載均衡群集。


國際某組織,要探索外星文明,發起活動組織每個人可以將電腦空閑的運算能力集中起來,把探索任務細分到每個願意提供運算能力的電腦上面,將運算結果執行後返回給中央服務器,這是種分布式計算


某組織需要進行每秒100萬的運算,需要並行處理多個維度的公式,將運算程序丟給群集,群集快速完成返回運算結果。這是種高性能計算。



以上為老王群集系列的開篇,雖然沒有像想象中那樣寫的盡善盡美,不過已經用心了就好,希望會有朋友看到老王的這篇文章之後,能夠對於以前不理解的內容多一點認識,那怕多理解了一點點,老王也會很高興,嘛,就這樣,後續文章會都是偏技術,實踐性的,下篇開始講為大家講解微軟高可用群集的仲裁模式,以及在2008R2 2012R2 2016不同版本中的運作形態實踐。


本文出自 “一個倔強的孤島” 博客,請務必保留此出處http://wzde2012.blog.51cto.com/6474289/1949622

淺談群集與分布式基礎知識