集羣概念介紹

集羣概念介紹

集羣術語須知

服務硬件：指提供計算服務的硬件，比如 PC 機、PC 服務器。

服務實體：服務實體通常指服務軟體和服務硬體。

節點（node）：運行 Heartbeat 進程的一個獨立主機稱爲節點，節點是 HA 的核心組成部分，每個節點上運行着操作系統和Heartbeat 軟件服務。

資源（resource）：資源是一個節點可以控制的實體，當節點發生故障時，這些資源能夠被其他節點接管。如： 磁盤分區、文件系統、IP 地址、應用程序服務、共享存儲

事件（event）：事件也就是集羣中可能發生的事情，例如節點系統故障、網絡連通故障、網卡故障和應用程序故障等。這些事件都會導致節點的資源發生轉移，HA 的測試也是基於這些事件進行的。

 

什麼是集羣

集羣（cluster）就是一組計算機，它們作爲一個整體向用戶提供一組網絡資源，這些單個的計算機系統就是集羣的節點（node）。集羣提供了以下關鍵的特性。

(一) 可擴展性。集羣的性能不限於單一的服務實體，新的服務實體可以動態的加入到集羣，從而增強集羣的性能。

(二) 高可用性。集羣通過服務實體冗餘使客戶端免於輕易遭遇到“out of service”警告。當一臺節點服務器發生故障的時候，這臺服務器上所運行的應用程序將在另一節點服務器上被自動接管。消除單點故障對於增強數據可用性、可達性和可靠性是非常重要的。

(三) 負載均衡。負載均衡能把任務比較均勻的分佈到集羣環境下的計算和網絡資源，以便提高數據吞吐量。

(四) 錯誤恢復。如果集羣中的某一臺服務器由於故障或者維護需要而無法使用，資源和應用程序將轉移到可用的集羣節點上。這種由於某個節點中的資源不能工作，另一個可用節點中的資源能夠透明的接管並繼續完成任務的過程叫做錯誤恢復。

分佈式與集羣的聯繫與區別如下：

(一) 分佈式是指將不同的業務分佈在不同的地方。

(二) 而集羣指的是將幾臺服務器集中在一起，實現同一業務。

(三) 分佈式的每一個節點，都可以做集羣，而集羣並不一定就是分佈式的。而分佈式，從狹義上理解，也與集羣差不多，但是它的組織比較鬆散，不像集羣，有一定組織性，一臺服務器宕了，其他的服務器可以頂上來。分佈式的每一個節點，都完成不同的業務，一個節點宕了，這個業務就不可訪問了。

集羣主要分成三大類：

HA：高可用集羣（High Availability Cluster）。

LBC：負載均衡集羣/負載均衡系統（Load Balance Cluster）

HPC：科學計算集羣（High Performance Computing Cluster）/高性能計算（High Performance Computing）集羣。

 

爲什麼搭建數據庫集羣

隨着經濟的高速發展，企業規模的迅猛擴張，企業用戶的數量、數據量的爆炸式增長，對數據庫提出了嚴峻的考驗。對於所有的數據庫而言，除了記錄正確的處理結果之外，還面臨着以下幾方面的挑戰。

• l  如何提高處理速度，實現數據庫的均衡負載。
• l  如何保證數據庫的可用性、數據安全性、以及如何實現數據集羣可擴性。
• l  怎麼綜合解決這些問題成爲衆多企業關注的焦點。

在數據庫上，組建集羣也是同樣的道理，主要有以下幾個原因：

(一) 伴隨着企業的成長，業務量提高，數據庫的訪問量和數據量快速增長，其處理能力和計算速度也相應增大，使得單一的設備根本無法承擔。

(二) 在以上情況下，若扔掉現有設備，做大量的硬件升級，勢必造成現有資源的浪費，而且下一次業務量提升時，又將面臨再一次硬件升級的高額投入。於是，人們希望通過幾箇中小型服務器組建集羣，實現數據庫的負載均衡及持續擴展；在需要更高數據庫處理速度時，只要簡單的增加數據庫服務器就可以得到擴展。

(三) 數據庫作爲信息系統的核心，起着非常重要的作用，單一設備根本無法保證系統的下持續運行，若發生系統故障，將嚴重影響系統的正常運行，甚至帶來巨大的經濟損失。於是，人們希望通過組建數據庫集羣，實現數據庫的高可用，當某節點發生故障時，系統會自動檢測並轉移故障節點的應用，保證數據庫的持續工作。

(四) 企業的數據庫保存着企業的重要信息，一些核心數據甚至關係着企業的命脈，單一設備根本無法保證數據庫的安全性，一旦發生丟失，很難再找回來。於是，人們希望通過組建數據庫集羣，實現數據集的冗餘，通過備份數據來保證安全性。

 

數據庫集羣的分類

數據庫集羣技術是將多臺服務器聯合起來組成集羣來實現綜合性能優於單個大型服務器的技術，這種技術不但能滿足應用的需要，而且大幅度的節約了投資成本。數據庫集羣技術分屬兩類體系：基於數據庫引擎的集羣技術和基於數據庫網關（中間件）的集羣技術。在數據庫集羣產品方面，其中主要包括基於數據庫引擎的集羣技術的 Oracle RAC、Microsoft MSCS、IBM DB2UDB、Sybase ASE，以及基於數據庫網關（中間件）的集羣技術的 ICX-UDS 等產品。

一般來講，數據庫集羣軟件側重的方向和試圖解決的問題劃分爲三大類：

• l  負載均衡集羣（Load Balance Cluster，LBC）側重於數據庫的橫向擴展，提升數據庫的性能。
• l  高可用性集羣（High Availability Cluster，HAC）側重保證數據庫應用持續不斷。大部分的數據庫集羣側重與此。
• l  高安全性集羣（High Security Cluster，HSC）側重於容災。

只有 Oracle RAC 能實現以上三方面

 

可擴展的分佈式數據庫架構

(一) Oracle RAC：

其架構的最大特點是共享存儲架構（Shared-storage），整個 RAC 集羣是建立在一個共享的存儲設備之上的，節點之間採用高速網絡互聯。OracleRAC 提供了非常好的高可用特性，比如負載均衡和應用透明切塊（TAF），其最大的優勢在於對應用完全透明，應用無需修改便可切換到RAC 集羣。但是RAC 的可擴展能力有限，首先因爲整個集羣都依賴於底層的共享存儲，所以共享存儲的 I/O 能力和可用性決定了整個集羣的可以提供的能力，對於 I/O 密集型的應用，這樣的機制決定後續擴容只能是 Scale up（向上擴展）類型，對於硬件成本、開發人員的要求、維護成本都相對比較高。Oracle顯然也意識到了這個問題，在 Oracle 的 MAA（Maximum Availability Architecture）架構中，採用 ASM 來整合多個存儲設備的能力，使得 RAC 底層的共享存儲設備具備線性擴展的能力，整個集羣不再依賴於大型存儲的處理能力和可用性。

RAC 的另外一個問題是，隨着節點數的不斷增加，節點間通信的成本也會隨之增加，當到某個限度時，增加節點可能不會再帶來性能上的提高，甚至可能造成性能下降。這個問題的主要原因是 Oracle RAC 對應用透明，應用可以連接集羣中的任意節點進行處理，當不同節點上的應用爭用資源時，RAC 節點間的通信開銷會嚴重影響集羣的處理能力。所以對於使用 ORACLE RAC 有以下兩個建議：

• l  節點間通信使用高速互聯網絡；
• l  儘可能將不同的應用分佈在不同的節點上。

基於這個原因，Oracle RAC 通常在 DSS 環境（決策支持系統Decision Support System ，簡稱DSS)中可以做到很好的擴展性，因爲 DSS 環境很容易將不同的任務分佈在不同計算節點上，而對於 OLTP 應用（On-Line Transaction Processing聯機事務處理系統），Oracle RAC 更多情況下用來提高可用性，而不是爲了提高擴展性。

(二) MySQL Cluster

MySQL cluster 和 Oracle RAC 完全不同，它採用 無共享架構Shared nothing（shared nothing architecture）。整個集羣由管理節點(ndb_mgmd)，處理節點(mysqld)和存儲節點(ndbd)組 成，不存在一個共享的存儲設備。MySQL cluster 主要利用了 NDB 存儲引擎來實現，NDB 存儲引擎是一個內存式存儲引擎，要求數據必須全部加載到內存之中。數據被自動分佈在集羣中的不同存 儲節點上，每個存儲節點只保存完整數據的一個分片(fragment)。同時，用戶可以設置同一份數據保存在多個不同的存儲節點上，以保證單點故障不會造 成數據丟失。MySQL cluster 主要由 3 各部分組成：

• l  SQL 服務器節點
• l  NDB 數據存儲節點
• l  監控和管理節點

這樣的分層也是與 MySQL 本身把 SQL 處理和存儲分開的架構相關係的。MySQL cluster 的優點在於其是一個分佈式的數據庫集羣，處理節點和存儲節點都可以線性增加，整個集羣沒有單點故障，可用性和擴展性都可以做到很高，更適合 OLTP 應用。但是它的問題在於：

• l   NDB（“NDB” 是一種“內存中”的存儲引擎，它具有可用性高和數據一致性好的特點。） 存儲引擎必須要求數據全部加載到內存之中，限制比較大，但是目前 NDB 新版本對此做了改進，允許只在內存中加 載索引數據，數據可以保存在磁盤上。
• l  目前的 MySQL cluster 的性能還不理想，因爲數據是按照主鍵 hash 分佈到不同的存儲節點上，如果應用不是通過主鍵去獲取數據的話，必須在所有的存儲節點上掃描， 返回結果到處理節點上去處理。而且，寫操作需要同時寫多份數據到不同的存儲節點上，對節點間的網絡要求很高。

雖然 MySQL cluster 目前性能還不理想，但是 share nothing 的架構一定是未來的趨勢，Oracle 接手 MySQL之後，也在大力發展 MySQL cluster，我對 MySQL cluster 的前景抱有很大的期待。

(三) 分佈式數據庫架構

MySQL 5 之後纔有了數據表分區功能（Sharding）， Sharding 不是一個某個特定數據庫軟件附屬的功能，而是在具體技術細節之上的抽象處理，是水平擴展(Scale Out，亦或橫向擴展、向外擴展)的解決方案，其主要目的是爲突破單節點數據庫服務器的 I/O 能力限制，解決數據庫擴展性問題。比如 Oracle 的 RAC 是採用共享存儲機制，對於 I/O 密集型的應用，瓶頸很容易落在存儲上，這樣的機制決定後續擴容只能是 Scale Up（向上擴展） 類型，對於硬件成本、開發人員的要求、維護成本都相對比較高。Sharding 基本上是針對開源數據庫的擴展性解決方案，很少有聽說商業數據庫進行 Sharding 的。目前業界的趨勢基本上是擁抱 Scale Out，逐漸從 Scale Up 中解放出來。

Sharding 架構的優勢在於，集羣擴展能力很強，幾乎可以做到線性擴展，而且整個集羣的可用性也很高，部分節點故障，不會影響其他節點提供服務。Sharding 原理簡單，容易實現，是一種非常好的解決數據庫擴展性的方案。Sharding 並不是數據庫擴展方案的銀彈，也有其不適合的場景，比如處理事務型的應用它可能會造成應用架構複雜或者限制系統的功能，這也是它的缺陷所在。讀寫分離是架構分佈式系統的一個重要思想。不少系統整體處理能力並不能同業務的增長保持同步，因此勢必會帶來瓶頸，單純的升級硬件並不能一勞永逸。針對業務類型特點，需要從架構模式進行一系列的調整，比如業務模塊的分割，數據庫的拆分等等。集中式和分佈式是兩個對立的模式，不同行業的應用特點也決定了架構的思路。如互聯網行業中一些門戶站點，出於技術和成本等方面考慮，更多的採用開源的數據庫產品(如 MYSQL)，由於大部分是典型的讀多寫少的請求，因此爲 MYSQL 及其複製技術大行其道提供了條件。而相對一些傳統密集交易型的行業，比如電信業、金融業等，考慮到單點處理能力和可靠性、穩定性等問題，可能更多的採用商用數據庫，比如 DB2、Oracle 等。就數據庫層面來講，大部分傳統行業核心庫採用集中式的架構思路，採用高配的小型機做主機載體，因爲數據庫本身和主機強大的處理能力，數據庫端一般能支撐業務的運轉，因此，Oracle 讀寫分離式的架構相對MYSQL 來講，相對會少。讀寫分離架構利用了數據庫的複製技術，將讀和 寫分佈在不同的處理節點上，從而達到提高可用性和擴展性的目的。最通常的做法是利用 MySQL Replication 技術，Master DB 承擔寫操作，將數據變化複製到多臺 Slave DB上，並承擔讀的操作。這種架構適合 read-intensive 類型的應用，通過增加 Slave DB 的數量，讀的性能可以線性增長。爲了避免 Master DB 的單點故障，集羣一般都會採用兩臺 Master DB 做雙機熱備，所以整個集羣的讀和寫的可用性都非常高。除了 MySQL，Oracle 從 11g 開始提供 Active Standby 的功能，也具備了實現讀寫分離架構的基礎。讀寫分離架構的缺陷在於，不管是 Master 還是 Slave，每個節點都必須保存完整的數據，如 果在數據量很大的情況下，集羣的擴展能力還是受限於單個節點的存儲能力，而且對於 Write-intensive 類型的應用，讀寫分離架構並不適合。

採用 Oracle 讀寫分離的思路，Writer DB 和 Reader DB 採用日誌複製軟件實現實時同步； Writer DB 負責交易相關的實時查詢和事務處理，Reader DB 負責只讀接入，處理一些非實時的交易明細,報表類的彙總查詢等。同時，爲了滿足高可用性和擴展性等要求，對讀寫端適當做外延，比如 Writer DB 採用 HA 或者 RAC 的架構模式，目前，除了數據庫廠商的 集羣產品以外，解決數據庫擴展能力的方法主要有兩個：數據分片和讀寫分離。數據分片(Sharding)的原理就是將數據做水平切分，類似於 hash 分區 的原理，通過應用架構解決訪問路由和Reader DB 可以採用多套，通過負載均衡或者業務分離的方式，有效分擔讀庫的壓力。

對於 Shared-nothing 的數據庫架構模式，核心的一個問題就是讀寫庫的實時同步；另外，雖然 Reader DB只負責業務查詢，但並不代表數據庫在功能上是隻讀的。只讀是從應用角度出發，爲了保證數據一致和衝突考慮，因爲查詢業務模塊可能需要涉及一些中間處理，如果需要在數據庫裏面處理(取決與應用需求和設計)，所以Reader DB 在功能上仍然需要可寫。下面談一下數據同步的技術選型問題：

能實現數據實時同步的技術很多，基於 OS 層(例如 VERITAS VVR)，基於存儲複製(中高端存儲大多都支持)，基於應用分發或者基於數據庫層的技術。因爲數據同步可能並不是單一的 DB 整庫同步，會涉及到業務數據選擇以及多源整合等問題，因此 OS 複製和存儲複製多數情況並不適合做讀寫分離的技術首選。基於日誌的 Oracle 複製技術，Oracle 自身組件可以實現，同時也有成熟的商業軟件。選商業的獨立產品還是 Oracle 自身的組件功能，這取決於多方面的因素。比如團隊的相應技術運維能力、項目投入成本、業務系統的負載程度等。

採用 Oracle 自身組件功能，無外乎 Logical Standby、Stream 以及 11g 的 Physical Standby(Active Data Guard)，對比來說，Stream 最靈活，但最不穩定，11g Physical Standby 支持恢復與只讀並行，但由於並不是日誌的邏輯應用機制，在讀寫分離的場景中最爲侷限。如果技術團隊對相關技術掌握足夠充分，而選型方案的處理能力又能支撐數據同步的要求，採用 Oracle 自身的組件完全可行。選擇商業化的產品，更多出於穩定性、處理能力等考慮。市面上成熟的 Oracle 複製軟件也無外乎幾種，無論是老牌的 Shareplex，還是本土 DSG 公司的 RealSync 和九橋公司的 DDS，或是 Oracle 新貴 Goldengate，都是可供選擇的目標。隨着 GoldenGate 被 Oracle 收購和推廣，個人認爲 GoldenGate 在容災、數據分發和同步方面將大行其道。當然，架構好一個可靠的分佈式讀寫分離的系統，還需要應用上做大量設計，不在本文討論範圍內。

(四)  CAP 和 BASE 理論

分佈式領域 CAP 理論：

• l  Consistency(一致性), 數據一致更新，所有數據變動都是同步的
• l  Availability(可用性), 好的響應性能
• l  Partition tolerance(分區容錯性) 可靠性

定理：任何分佈式系統只可同時滿足二點，沒法三者兼顧。

忠告：架構師不要將精力浪費在如何設計能滿足三者的完美分佈式系統，而是應該進行取捨。

關係數據庫的 ACID 模型擁有 高一致性 + 可用性 很難進行分區：

• l  Atomicity 原子性：一個事務中所有操作都必須全部完成，要麼全部不完成。
• l  Consistency 一致性. 在事務開始或結束時，數據庫應該在一致狀態。
• l  Isolation 隔離層. 事務將假定只有它自己在操作數據庫，彼此不知曉。
• l  Durability. 一旦事務完成，就不能返回。

(五)  跨數據庫事務

2PC (two-phase commit)， 2PC is the anti-scalability pattern (Pat Helland) 是反可伸縮模式的，也就是說傳統關係型數據庫要想實現一個分佈式數據庫集羣非常困難，關係型數據庫的擴展能力十分有限。而近年來不斷髮展壯大的 NoSQL（非關係型的數據庫）運動，就是通過犧牲強一致性，採用 BASE 模型，用最終一致性的思想來設計分佈式系統，從而使得系統可以達到很高的可用性和擴展性。那麼，有沒有可能實現一套分佈式數據庫集羣，既保證可用性和一致性，又可以提供很好的擴展能力呢？

BASE 思想的主要實現有按功能劃分數據庫 sharding 碎片BASE 思想主要強調基本的可用性，如果你需要 High 可用性，也就是純粹的高性能，那麼就要以一致性或容錯性爲犧牲，BASE 思想的方案在性能上還是有潛力可挖的。

• l  共同點：都是關係數據庫 SQL 以外的可選方案，邏輯隨着數據分佈，任何模型都可以自己持久化，將數據處理和數據存儲分離，將讀和寫分離，存儲可以是異步或同步，取決於對一致性的要求程度。
• l  不同點：NOSQL 之類的 Key-Value 存儲產品是和關係數據庫頭碰頭的產品 BOX，可以適合非 Java 如 PHP RUBY等領域，是一種可以拿來就用的產品，而領域模型 + 分佈式緩存 + 存儲是一種複雜的架構解決方案，不是產品，但這種方式更靈活，更應該是架構師必須掌握的。

目前，已經有很多分佈式數據庫的產品，但是絕大部分是面向 DSS 類型的應用，因爲相比較 OLTP 應用，DSS 應用更容易做到分佈式擴展，比如基於 PostgreSQL 發展的 Greenplum，就很好的解決了可用性和擴展性的問題，並且提供了很強大的並行計算能力。對於 OLTP 應用，業務特點決定其要求：高可用性，一致性， 響應時間短，支持事務和 join 等等。數據庫和 NoSQL當越來越多的 NoSQL 產品涌現出來，它們具備很多關係型數據庫所不具備的特性，在可用性和擴展性方面都可以做到很好。

第一，NoSQL 的應用場景非常侷限，某個類型的 NoSQL 僅僅針對特定類型的應用場景而設計。而關係型數據庫則要通用的多，使用 NoSQL 必須搞清楚自己的應用場景是否適合。

第二，利用關係型數據庫配合應用架構， 比如 Sharding 和讀寫分離技術，同樣可以搭建出具備高可用和擴展性的分佈式數據庫集羣。

第三，關係型數據庫廠商依然很強大，全世界有大量的 用戶，需求必然會推動新的產品問世。

第四，硬件的發展日新月異，比如閃存的技術的不斷成熟，未來閃存可以作爲磁盤與內存之間的 cache，或者完 全替代磁盤。而內存價格越來越低，容量越來越大，In-memory cache 或 database 的應用越來越廣泛，可以給應用帶來數量級的性能提升。數據庫面臨的 IO 問題將被極大改善。