簡單的說,集羣(cluster)就是一組計算機,它們做爲一個總體向用戶提供一組網絡資源。這些單個的計算機系統就是集羣的節點(node)。一個理想的集羣是,用戶歷來不會意識到集羣系統底層的節點,在他/她們看來,集羣是一個系統,而非多個計算機系統。而且集羣系統的管理員能夠隨意增長和刪改集羣系統的節點。javascript
更詳細的說,集羣(一組協同工做的計算機)是充分利用計算資源的一個重要概念,由於它可以將工做負載從一個超載的系統(或節點)遷移到集羣中的另外一個系統上。其處理能力是與專用計算機(小型機,大型機)可相比,但其性價比高於專用計算機.常見的硬件有:結點,網絡,存儲.軟件有:機羣系統,節點系統,應用支撐軟件。 html
Cluster集羣技術可以下定義:一組相互獨立的服務器在網絡中表現爲單一的系統,並以單一系統的模式加以管理。此單一系統爲客戶工做站提供高可靠性的服務。大多數模式下,集羣中全部的計算機擁有一個共同的名稱,集羣內任一系統上運行的服務可被全部的網絡客戶所使用。Cluster必須能夠協調管理各分離的組件的錯誤和失敗,並可透明地向Cluster中加入組件。一個Cluster包含多臺(至少二臺)擁有共享數據存儲空間的服務器。任何一臺服務器運行一個應用時,應用數據被存儲在共享的數據空間內。每臺服務器的操做系統和應用程序文件存儲在其各自的本地儲存空間上。Cluster內各節點服務器經過一內部局域網相互通信。當一臺節點服務器發生故障時,這臺服務器上所運行的應用程序將在另外一節點服務器上被自動接管。當一個應用服務發生故障時,應用服務將被從新啓動或被另外一臺服務器接管。當以上的任一故障發生時,客戶都將能很快鏈接到新的應用服務上。前端
(1)高可擴展性: java
(2)高可用性HA:集羣中的一個節點失效,它的任務可傳遞給其餘節點。能夠有效防止單點失效。 node
(3)高性能:負載平衡集羣容許系統同時接入更多的用戶。 mysql
(4)高性價比:能夠採用廉價的符合工業標準的硬件構造高性能的系統。linux
1、集羣定義
集羣(cluster)技術是一種較新的技術,經過集羣技術,能夠在付出較低成本的狀況下得到在性能、可靠性、靈活性方面的相對較高的收益,其任務調度則是集羣系統中的核心技術。集羣是一組相互獨立的、經過高速網絡互聯的計算機,它們構成了一個組,並以單一系統的模式加以管理。一個客戶與集羣相互做用時,集羣像是一個獨立的服務器。集羣配置是用於提升可用性和可縮放性。集羣系統的主要優勢:高可擴展性、高可用性、高性能、高性價比。nginx
2、集羣類型
1.scale on:向上擴展
將服務器的內存容量調大和cpu數量增長些(簡單說升級服務器硬件)
缺點:在必定的範圍以內它的性能是上升的趨勢,可是超出範圍以後就是降低的趨勢。由於隨着它的cpu的個數增長咱們須要給咱們的cpu仲裁,並且隨着cpu個數的增長資源競爭性越大。sql
2.scale out:向外擴展
一臺服務器應付不過來,咱們就再增長一臺服務器。
優勢:增減服務器很方便,並且沒有向上擴展隨着增長性能降低。
向外擴張的工做模式:當客戶端向服務器端發送請求,服務器端只拿出來一臺服務器來相應咱們的客戶端的請求。數據庫
(1).LB:Load Balancing:負載均衡集羣
負載均衡集羣中有一個分發器或者叫調度器,咱們將其稱之爲Director,它處在多臺服務器的上面,分發器根據內部鎖定義的規則或調度方式從下面的服務器羣中選擇一個以此來響應客戶端發送的請求。
(2).HA:High Availability 高可用集羣
高可用集羣是服務的可用性比較高,當咱們某臺服務器死機後不會形成咱們的服務不可用。其工做模式則是將一個具備故障的服務轉交給一個正常工做的服務器,從而達到服務不會中斷。通常來講咱們集羣中工做在前端(分發器)的服務器都會對咱們的後端服務器作一個健康檢查,若是發現咱們服務器當機就不會對其在作轉發。
衡量標準:可用性=在線時間/(在線時間+故障處理時間)
99%、99.9%、99.99%、99.999%
(3).HP:Hight Performance 高性能
高性能的集羣是當某一個任務量很是大的時候,咱們作一個集羣共同來完成這一個任務。這種處理方式咱們稱爲並行處理集羣,並行處理集羣是將大任務劃分爲小任務,分別進行處理的機制。通常這樣的集羣用來科學研究與大數據運算等方面的工做。如今比較火的Hadoop就是使用的並行處理集羣。
說明:三種集羣之間的區別
負載均衡着重在於提供服務併發處理能力的集羣,高可用以提高服務在線的能力的集羣。高性能着重用於處理一個海量任務。
雖然,根據集羣系統的不一樣特徵能夠有多種分類方法,可是通常把集羣系統分爲兩類:
(1)、高可用(High Availability)集羣,簡稱HA集羣。
這類集羣致力於提供高度可靠的服務。就是利用集羣系統的容錯性對外提供7*24小時不間斷的服務,如高可用的文件服務器、數據庫服務等關鍵應用。
負載均衡集羣:使任務能夠在集羣中儘量平均地分攤不一樣的計算機進行處理,充分利用集羣的處理能力,提升對任務的處理效率。
在實際應用中這幾種集羣類型可能會混合使用,以提供更加高效穩定的服務。如在一個使用的網絡流量負載均衡集羣中,就會包含高可用的網絡文件系統、高可用的網絡服務。
(2)、性能計算(High Perfermance Computing)集羣,簡稱HPC集羣,也稱爲科學計算集羣。
在這種集羣上運行的是專門開發的並行應用程序,它能夠把一個問題的數據分佈到多臺的計算機上,利用這些計算機的共同資源來完成計算任務,從而能夠解決單機不能勝任的工做(如問題規模太大,單機計算速度太慢)。
這類集羣致力於提供單個計算機所不能提供的強大的計算能力。如天氣預報、石油勘探與油藏模擬、分子模擬、生物計算等。
3.1 什麼是高可用性 (HA)
計算機系統的可用性(availability)是經過系統的可靠性(reliability)和可維護性(maintainability)來度量的。工程上一般用平均無端障時間(MTTF)來度量系統的可靠性,用平均維修時間(MTTR)來度量系統的可維護性。因而可用性被定義爲:MTTF/(MTTF+MTTR)*100%
負載均衡服務器的高可用性 爲了屏蔽負載均衡服務器的失效,須要創建一個備份機。主服務器和備份機上都運行High Availability監控程序,經過傳送諸如「I am alive」這樣的信息來監控對方的運行情況。當備份機不能在必定的時間內收到這樣的信息時,它就接管主服務器的服務IP並繼續提供服務;當備份管理器又從主管理器收到「I am alive」這樣的信息是,它就釋放服務IP地址,這樣的主管理器就開開始再次進行集羣管理的工做了。爲在主服務器失效的狀況下系統能正常工做,咱們在主、備份機之間實現負載集羣系統配置信息的同步與備份,保持兩者系統的基本一致。
HA的容錯備援運做過程
自動偵測(Auto-Detect)階段 由主機上的軟件經過冗餘偵測線,經由複雜的監聽程序。邏輯判斷,來相互偵測對方運行的狀況,所檢查的項目有:主機硬件(CPU和周邊)、主機網絡、主機操做系統、數據庫引擎及其它應用程序、主機與磁盤陣列連線。爲確保偵測的正確性,而防止錯誤的判斷,可設定安全偵測時間,包括偵測時間間隔,偵測次數以調整安全係數,而且由主機的冗餘通訊連線,將所聚集的訊息記錄下來,以供維護參考。
自動切換(Auto-Switch)階段 某一主機若是確認對方故障,則正常主機除繼續進行原來的任務,還將依據各類容錯備援模式接管預先設定的備援做業程序,並進行後續的程序及服務。
自動恢復(Auto-Recovery)階段 在正常主機代替故障主機工做後,故障主機可離線進行修復工做。在故障主機修復後,透過冗餘通信線與原正常主機連線,自動切換回修復完成的主機上。整個回覆過程完成由EDI-HA自動完成,亦可依據預先配置,選擇回覆動做爲半自動或不回覆。
3.二、HA三種工做方式:
(1)、主從方式 (非對稱方式)
工做原理:主機工做,備機處於監控準備情況;當主機宕機時,備機接管主機的一切工做,待主機恢復正常後,按使用者的設定以自動或手動方式將服務切換到主機上運行,數據的一致性經過共享存儲系統解決。
(2)、雙機雙工方式(互備互援)
工做原理:兩臺主機同時運行各自的服務工做且相互監測狀況,當任一臺主機宕機時,另外一臺主機當即接管它的一切工做,保證工做實時,應用服務系統的關鍵數據存放在共享存儲系統中。
(3)、集羣工做方式(多服務器互備方式)
工做原理:多臺主機一塊兒工做,各自運行一個或幾個服務,各爲服務定義一個或多個備用主機,當某個主機故障時,運行在其上的服務就能夠被其它主機接管。
keepalived vrrp協議的實現
heartbeat
corosync+pacemaker
cman+rgmanager
cman+pacemaker
ais:完備HA集羣
硬件:(最少倆臺)
F5 BIG-IP
Citrix Netscaler
A10 A10
Array RedWare 硬件
軟件:
lvs:Linux Virtual Server 最強大的軟件調度工具,沒有之一
haproxy
nginx
ats(apache traffice server)
perlbal
向量機
並行處理集羣
解決方案:Hadoop
高能能計算集羣應用主要按應用類型分爲科學計算型集羣、負載均衡型集羣、高可用型集羣、並行數據庫型集羣四類;按照應用需求對應的應用領域分爲:
計算密集型應用(Computing-intensive): 大型科學工程計算,數值模擬等。其應用領域爲石油、氣象、CAE、核能、製藥、環境監測分析、系統仿真等。
數據密集型應用(Data-intensive): 數字圖書館,數據倉庫,數據挖掘,計算可視化等;其應用領域:圖書館、銀行、證券、稅務、決策支持系統等。
通訊密集型應用(Network-intensive): 協同工做,網格計算,遙控和遠程診斷等;其應用領域:網站、信息中心、搜索引擎、電信、流媒體等。
HPC 高能能計算經常使用種應用領域主要分爲: CAE 仿真、動漫渲染、物理化學、石油勘探、生命科學、氣象環境。
摘自:https://www.linuxidc.com/Linux/2013-08/88522.htm
1、高可用集羣的定義
高可用集羣,英文原文爲High Availability Cluster,簡稱HACluster,簡單的說,集羣(cluster)就是一組計算機,它們做爲一個總體向用戶提供一組網絡資源。這些單個的計算機系統 就是集羣的節點(node)。
高可用集羣的出現是爲了使集羣的總體服務儘量可用,從而減小由計算機硬件和軟件易錯性所帶來的損失。若是某個節點失效,它的備援節點將在幾秒鐘的時間內接管它的職責。所以,對於用戶而言,集羣永遠不會停機。
高可用集羣軟件的主要做用就是實現故障檢查和業務切換的自動化。只有兩個節點的高可用集羣又稱爲雙機熱備,即便用兩臺服務器互相備份。當一臺服務器出現故障時,可由另外一臺服務器承擔服務任務,從而在不須要人工干預的 狀況下,自動保證系統能持續對外提供服務。雙機熱備只是高可用集羣的一種,高可用集羣系統更能夠支持兩個以上的節點,提供比雙機熱備更多、更高級的功能,更能知足用戶不斷出現的需求變化。
2、高可用集羣的衡量標準
HA(High Available), 高可用性羣集是經過系統的可靠性(reliability)和可維護性(maintainability)來度量的。工程上,一般用平均無端障時間(MTTF)來度量系統的可靠性,用平均維修時間(MTTR)來度量系統的可維護性。因而可用性被定義爲:HA=MTTF/(MTTF+MTTR)*100%
https://www.top500.org
具體HA衡量標準:
99% 一年宕機時間不超過4天
99.9% 一年宕機時間不超過10小時
99.99% 一年宕機時間不超過1小時
99.999% 一年宕機時間不超過6分鐘
3、高可用集羣的層次結構
說明:高可用集羣可分爲三個層次結構,分別由紅色部分的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,就是咱們常說的」爆頭 」。
4、高可用集羣的分類
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.
5、高可用集羣軟件
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高可用等,有的博友會問了,咱們到底用什麼好呢?通過上面的說明你們應該有所瞭解!
6、共享存儲
說到集羣, 咱們不得不說到,共享存儲,由於無論理是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)存取快,塊級別,廉價
7、集羣文件系統與集羣LVM(集羣邏輯卷管理cLVM)
集羣文件系統:gfs二、ocfs2
集羣LVM:cLVM
注:通常用於高可用雙主模型中(以下圖)
8、高可用集羣的工做原理
說明:這裏主要以主/從節點的高可用來講明工做原理。
主服務器和從服務器創建雙機熱備,基本上都是共享一個存儲,以mysql爲例。一般狀況下,數據庫文件掛載在主數據庫服務器上,用戶鏈接到主服務器上進行數據庫操做。當主服務器出現故障時,從服務器就會自動掛載數據庫文件,並接替主服務器的工做。用戶在未通知的狀況下,經過從數據庫鏈接到數據庫文件進行操做。等主服務器的故障修復以後,又能夠從新提供服務;
那麼,從服務器是如何知道主服務器掛掉了呢,這就要使用必定的檢測機制,如心跳檢測,也就是說每個節點都會按期向其餘節點通知本身的心跳信息,尤爲是主服務器,若是從服務器在幾個心跳週期內(可自行設置心跳週期)尚未檢測到的話,就認爲主服務器宕掉了,而這期間在通告心跳信息固然不能使用tcp傳輸的,若是使用tcp檢測,還要通過三次握手,等手握完了,不定通過幾個心跳週期了,因此在檢測心跳信息的時候採用的是udp的端口694來進行傳遞信息的,若是主服務器在某一端時間因爲服務繁忙,沒時間響應心跳信息,這個時候從服務器要是把主服務資源搶過去(共享數據文件),可是這個時候主服務器尚未宕掉,這樣就會致使資源搶佔,就這樣用戶在主從上都能訪問,若是僅僅是讀操做還沒事,要是有寫的操做,那就會致使文件系統崩潰,這樣一切都玩了,因此在資源搶佔的時候,能夠採用必定的隔離方法來實現,就是從服務器搶佔資源的時候,直接把主服務器給「STONITH」,就是咱們常說的「爆頭」;
那麼,咱們又用什麼方式來檢測心跳信息呢?就是經過心跳線來檢測。運行在從服務器上的Heartbeat能夠經過以太網鏈接檢測主服務器的運行狀態,一旦其沒法檢測到主服務器的「心跳」則自動接管主服務器的資源。一般狀況下,主、從服務器間的心跳鏈接是一個獨立的物理鏈接,這個鏈接能夠是串行線纜、一個由「交叉線」實現的以太網鏈接。Heartbeat甚至可同時經過多個物理鏈接檢測主服務器的工做狀態,而其只要能經過其中一個鏈接收到主服務器處於活動狀態的信息,就會認爲主服務器處於正常狀態。從實踐經驗的角度來講,建議爲Heartbeat配置多條獨立的物理連,以免Heartbeat通訊線路自己存在單點故障。
上面的原理中咱們提到了「隔離方法」,下面咱們來講一說,隔離方法有兩種,一種是節點隔離,另外一種是資源隔離。節點隔離就是咱們常說的STONITH(Shoot The Other Node In the Head ,俗稱「爆頭」),意思就是直接切斷電源;經常使用的方法是全部節點都接在一個電源交換機上,若是有故障,就直接致使該節點的電壓不穩定,或斷電,讓有故障的節點重啓或關閉。(以下圖),而資源隔離,就是 fencing 直接把某種資源截獲過來。
下面咱們再來講一說「心路線」的類型,一種是串行電纜,另外一種就是咱們常看到的以太網線(交叉的雙絞線),它們各有優缺點,串行電纜,被認爲是比以太網鏈接安全性稍好些的鏈接方式,由於hacker沒法經過串行鏈接運行諸如telnet、ssh或rsh類的程序,從而能夠下降其經過已劫持的服務器再次侵入備份服務器的概率。但串行線纜受限於可用長度,所以主、備服務器的距離必須很是短。以太網線鏈接,使用此方式能夠消除串行線纜的在長度方面限制,而且能夠經過此鏈接在主從服務器之間同步文件系統,從而減小了對正常通訊鏈接帶寬的佔用。(以下圖)
參考文檔:http://www.linux-ha.org/wiki/Main_Pagehttp://clusterlabs.org/wiki/Main_Pagehttp://opencf.org/home.html