資料庫叢集技術漫談

宋沄劍發表於2016-01-29

簡介

當今世界是一個資訊化的世界,我們的生活中無論是生活、工作、學習都離不開資訊系統的支撐。而資訊系統的背後用於儲存和處理最終結果的地方就是資料庫。因此資料庫系統就變得尤為重要,這意味著如果資料庫如果面臨問題,則意味著整個應用系統也會面臨挑戰,從而帶來嚴重的損失和後果。

如今“大資料”這個詞已經變得非常流行,雖然這個概念如何落地不得而知。但可以確定的是,隨著物聯網、移動應用的興起,資料量相比過去會有幾何級的提升,因此資料庫所需要解決的問題不再僅僅是記錄程式正確的處理結果,還需要解決如下挑戰:

  • 當資料庫效能遇到問題時,是否能夠橫向擴充套件,通過新增伺服器的方式達到更高的吞吐量,從而充分利用現有的硬體實現更好的投資回報率。
  • 是否擁有實時同步的副本,當資料庫面臨災難時,可以短時間內通過故障轉移的方式保證資料庫的可用性。此外,當資料丟失或損壞時,能否通過所謂的實時副本(熱備)實現資料的零損失。
  • 資料庫的橫向擴充套件是否對應用程式透明,如果資料庫的橫向擴充套件需要應用程式端進行大量修改,則所帶來的後果不僅僅是高昂的開發成本,同時也會帶來很多潛在和非潛在的風險。

面對上述挑戰一個顯而易見的辦法是將多個伺服器組成一組叢集,這樣一來就可以充分利用每一臺伺服器的資源並將客戶端負載分發到不同伺服器上,隨著應用程式負載的增加,只需要將新的伺服器新增到叢集即可。

本篇文章將對叢集的概念、形式以及目前主流的資料庫叢集技術進行探討。

資料庫叢集的形式

資料庫的叢集和擴充套件不像應用程式擴充套件那樣容易,因為從資料庫端來說,一旦涉及到了叢集,往往會涉及到資料庫層面的同步,因此從是否存在資料冗餘這個角度來講,我們可以從大面上把資料庫叢集分為以下兩種形式:

Share-Disk架構

Share-Disk架構是通過多個伺服器節點共享一個儲存來實現資料庫叢集,兩臺機器最簡單的Share-Disk架構如圖1所示。

1

    圖1.簡單的Share-Disk架構

在此基礎之上,Share-Disk架構又分為單活和雙活,雙活即為叢集中的每一個節點都可以同時對外提供服務,而單活為叢集中只有一個節點可對外提供服務,叢集中的其他伺服器作為冗餘在“活”的節點出現故障時接替該伺服器成為對外提供服務的節點。該類架構最典型的產品就是SQL Server Failover Cluster(SQL Server故障轉移叢集)、NEC的EXPRESSCLUSTER、ROSE的ROSE HA。這種方式的弊端也是顯而易見的,如下:

  • 硬體資源的嚴重浪費,同一時間叢集中只有一臺伺服器活著,其他伺服器只能作為冗餘伺服器。
  • 叢集無法提升效能,因為只有一臺伺服器可用
  • 儲存方面存在單點故障,除非在儲存層級保證高可用,通常需要昂貴的SAN儲存。

因此該類方案僅僅可以做到伺服器層面的高可用,無法帶來效能的提升,也無法解決儲存單點故障的問題。因此如果不搭配其他高可用或負載均衡的技術,存在的意義並不是很大。

另一類技術是Share-Disk中的雙活的技術,與單活技術不同的是,雙活的技術雖然也是共享磁碟,但叢集中的所有節點都可以對外提供服務,典型的產品就是Oracle的RAC。RAC的技術性非常的高,因此需要水平比較高的人來運維繫統。RAC設計的初衷並不是為了效能,而是為了高可用和可擴充套件性,如果應用程式不是針對RAC架構設計和開發的,則將應用程式遷移到RAC上由於block contention (block busy waits)可能會導致效能的急劇下降,並且節點越多效能下降越明顯。

Share-Nothing架構

Share-Nothing架構又分為兩種,首先是分散式架構。將資料庫中的資料按照某一標準分佈到多臺機器中,查詢或插入時按照條件查詢或插入對應的分割槽。

另一種是每一個節點完全獨立,節點之間通過網路連線,通常是通過光釺等專用網路。如圖2所示。

2

圖2.Share-Nothing冗餘架構

在Share-Nothing架構中,每一個節點都擁有自己的記憶體和儲存,都保留資料的完整副本。通常來說,又可以分為兩種,可以負載均衡和不可以負載均衡。

首先談談不可負載均衡的叢集,在不可負載均衡的技術中,叢集中的節點會被分為主節點和輔助節點,主節點向外提供服務,輔助節點作為熱備(二階段事務提交)或暖備(不需要保證事務同步),同時有可能使得輔助節點提供只讀的服務。使用這個架構的技術包括:SQL Server AlwaysOn,SQL Server Mirror,Oracle Data Guard這種架構帶來的好處包括:

  • 輔助節點資料和主節點保持同步或準同步,當搭配第三方仲裁後,可以實現自動的故障轉移,從而實現了高可用
  • 輔助節點由於和主節點完全獨立且資料同步或準同步,因此主節點出現資料損壞後,可以從輔助節點恢復資料(自動或手動)
  • 由於Share-Nothing架構使用了本地儲存(或SAN),相較於Share-Disk架構在慢速網路時有非常大的效能優勢

當然,弊端也顯而易見,因為輔助節點無法對外提供服務或只能提供只讀服務,因此該類叢集的弊端包括:

  • 擴充套件能力非常有限
  • 對效能沒有提升,因為涉及到各節點的資料同步,甚至帶來效能的下降
  • 輔助節點如果可讀,雖然提升效能,但需要修改前端應用程式,對應用程式不透明

另一類Share-Nothing架構中,是允許負載均衡的。所謂負載均衡就是就是將對資料庫的負載分佈到叢集中的多個節點上,在叢集中的每一個節點都可以對外提供服務,從而達到更高的吞吐量,更好的資源利用率和更低的響應時間。前端通過代理進行排程。使用該類架構的技術包括:MySQL上的Amoeba(架構如圖3,摘自MySQL大師陳暢亮的部落格:http://www.cnblogs.com/gaizai/archive/2012/06/12/2546755.html),MySQL上的HA Proxy(如圖4所示),格瑞趨勢(www.grqsh.com)在SQL Server上的Moebius叢集(如圖5所示)。

3

圖3.Amoeba

5

圖4.HA Proxy

4

圖5.Moebius叢集

可負載均衡的Share-Nothing架構的好處是每臺伺服器都能提供服務,能充分利用現有資源,達到更高的吞吐量。其中Amoeba中可能會涉及到資料分片,資料分片的好處是對於海量資料的處理更加高效,但同時也引入了其他問題,比如說需要應用程式端對應資料分片進行調整、跨分片節點查詢的處理問題、每一個資料分片節點是否能夠承受各自業務負載的高峰問題等。該類架構需要實施的人員水平比較高,且需要應用層面做調整,因此更適合於網際網路企業。

另一類不涉及到資料分片的架構,比如一類可以使用組合方案,比如說Oracle RAC+F5。另一類是使用單個廠商提供的方案,比如說SQL Server上的Moebius。這類方案叢集中的每個節點都會對外提供服務,因此有如下好處:

  • 由於每一個節點都可以對外提供服務,因此可以提升效能
  • 擴充套件性得到提升,可以通過向叢集新增節點直接進行Scale-Out擴充
  • 由於前端應用通過代理連線到叢集,而叢集中的每一個節點都保持完整的資料集,因此不存在分片不到位反而造成效能下降的問題,因此對應用程式端完全透明

但相比較於MySQL的資料分片,該類方案的弊端也顯而易見,因為每一個節點都需要完整的資料集,因此需要佔用更多的儲存空間。

小結

本文從一個比較高的層面談到了資料庫叢集技術。從資料庫應用層面的Share-Disk叢集直到叢集的最高形式-能夠提供負載均衡的叢集,並列舉了一些主流的商用產品。叢集的存在意義是為了保證高可用、資料安全、擴充套件性以及負載均衡。如果現在的叢集產品不能包含這幾個特性,而業務場景也需要,也可以將和一些現有的技術結合來實現,但畢竟不是每一個人都是資料庫專家,即使給你一堆工具和材料你也做不出來iPhone,因此在系統設計之初就對資料庫方面的方案有所考慮會免去很多麻煩。

相關文章