SQL Server底層架構技術對比

z_cloud_for_SQL發表於2023-04-24

背景

資料庫是資訊化的基石,支撐著整個業務系統,發揮著非常重要的作用,被喻為“IT的心臟”。因此,讓資料庫安全、穩定、高效地執行已經成為IT管理者必須要面對的問題。資料庫在底層架構層面需要滿足以下幾點建設要求:

安全和可靠不能因為伺服器的軟硬體故障導致資料丟失和業務中斷;

容災:多資料中心間的資料庫同步,某一個資料中心出現故障後,可以在另一個資料中心快速拉起業務;

讀寫分離(報表分離):把介面程式、報表程式、整合平臺資料抽取、大資料運算等高消耗的查詢語句分離到備機執行,從而避免對主伺服器的效能消耗以及造成的阻塞和死鎖;

負載均衡需要多臺伺服器同時負載併發請求,降低單臺伺服器的壓力,提升系統整體效能;

彈性擴充套件透過增加伺服器的方式應對資料量或者訪問量增加帶來的效能瓶頸。

 

基於共享儲存的雙機

兩臺資料庫伺服器上的SQL Server共享儲存裝置中的一份資料庫檔案,為了防止資料混亂,由主節點控制儲存裝置,備節點的SQL Server服務處於停止狀態。當主節點出現故障後,備節點接管儲存裝置、啟動SQL Server服務、初始化資料庫、接管虛擬IP等資源完成故障轉移,保障資料庫的可用性。SQL Server失敗轉移群集屬於這類技術。

 

 資料安全:只有一份資料,無法保障資料安全。
資料同步驗證:只有一份資料,無法驗證。可用性:滿足。故障轉移時間:在故障轉移過程中,備節點需要啟動SQL Server服務、初始化資料庫,當資料庫個數多尤其是日誌量大的時候,初始化資料庫的時間會變長,導致切換時間變長,一般的切換時間在20秒以上。讀寫分離只有一個節點執行,無法實現。負載均衡:只有一個節點執行,無法實現。

基於磁碟映象的雙機

兩臺伺服器中的SQL Server獨立安裝,使用各自磁碟中的資料庫檔案,利用磁碟映象技術,主節點磁碟上的資料變化實時同步到備節點的磁碟中。為了防止資料混亂,備節點的SQL Server服務處於停止狀態。當主節點出現故障後,備節點啟動SQL Server服務、初始化資料庫、接管虛擬IP等資源完成故障轉移,保障資料庫的可用性。

 

資料安全:SQL Server層面有兩份資料庫檔案,可以保障資料安全。在大資料量寫入時突然掉電關機的極端情況下,寫入磁碟的SQL Server資料格式不完整導致SQL Server出現邏輯錯誤,重啟後資料庫出現質疑,因為兩份資料一模一樣,因此備節點上也會出現相同的現象。
資料同步驗證:備節點上的SQL Server服務是不能啟動的,無法隨時進行資料驗證。要想驗證資料,需要對當前時間點做快照,然後啟動SQL Server服務,載入資料庫後進行驗證,驗證後停止SQL Server服務,移除快照,操作非常麻煩,否則就得進行節點切換來驗證,切換時對應用有影響。可用性:滿足。故障轉移時間:在故障轉移過程中,備節點需要啟動SQL Server服務、初始化資料庫,當資料庫個數多尤其是日誌量大的時候,初始化資料庫的時間會變長,導致切換時間變長,一般的切換時間在20秒以上。讀寫分離只有一個節點執行,無法實現。負載均衡:只有一個節點執行,無法實現。

容災

和基於磁碟映象的雙機一樣,容災軟體也是利用磁碟映象技術,主節點磁碟上的資料變化實時或者準實時同步到容災節點的磁碟中,不同的是基於容災場景下功能的增強,例如傳輸過程中的壓縮和加密,利用快照功能做CDP(資料保護),有的容災軟體也帶有可用性的功能。

儲存雙活

和主機高可用一樣,為了防止儲存裝置單點故障而出現的高可用技術,並演化為“雙活”,主要有透過儲存閘道器同時寫入兩個儲存裝置或者儲存裝置間資料複製兩種實現方式。和磁碟RAID一樣,儲存雙活對於上層應用來說是透明的,底層資料有兩份,但是對於SQL Server來說還是看到的是一份資料庫檔案。有人認為兩個SQL Server伺服器分別接到配置了雙活的兩個儲存裝置上就能實現兩個SQL Server資料庫間的同步,這是一個非常大的誤區。

 

資料安全:底層有兩份資料,可以保障資料安全。對於上層的SQL Server還是一份資料,因此儲存雙活也無法解決在大量資料寫入時突然掉電關機導致的資料庫質疑問題。
資料同步驗證:SQL Server層面還是一份資料,無法進行資料同步驗證。可用性:只能保障資料檔案層面的可用性,SQL Server層面的可用性還需要藉助其他技術實現。故障轉移時間:取決於SQL Server層面使用的高可用技術。讀寫分離無法實現。負載均衡:無法實現。

 

虛擬化\超融合

虛擬化技術是一種資源管理技術,可實現物理層與邏輯層的分離,提高IT基礎設施管理效率和資源利用率。從SQL Server層面來看依然只有一個節點。超融合是虛擬化技術的延伸,更多的體現在軟硬體一體化,不做過多的介紹,可以當作虛擬化來看待。
資料安全:儲存層面有兩份資料,可以保障資料安全。對於上層的SQL Server還是一份資料,因此也無法解決在大資料量寫入時突然掉電關機導致的資料庫質疑問題。
資料同步驗證:從SQL Server層面上看只有一個節點、一份資料庫檔案,無法在SQL Server層面進行資料驗證。可用性:虛擬化技術基本都有高可用功能,當物理伺服器發生故障的時候,受影響的虛擬機器將在叢集中留有備用容量的其它物理伺服器上自動啟動。故障轉移時間:搭配高階HA功能的可以做到狀態和資料在主備機間實時同步,故障時快速切換。讀寫分離SQL Server層面只有一個節點,不能實現。負載均衡:SQL Server層面只有一個節點,不能實現。

釋出訂閱

釋出訂閱是SQL Server提供的資料庫複製技術,可用作資料同步、冷備、讀寫分離等。分快照複製、事務複製、對等複製、合併複製幾種方式,這裡用經常使用的事務複製進行說明。事務複製是單向的主從複製,主要有以下特點:

    1. 資料同步是非同步的,變更的資料幾秒鐘後才能同步到訂閱伺服器;

    2. 不是整庫的同步,需要對同步的物件(表、檢視、儲存過程、函式等)進行配置;

    3. 參與複製的表要有主鍵,而且不能有TRUNCATE TABLE操作;

    4. 對物件進行DROP操作時,要先從釋出訂閱中移除;

    5. 部署比較麻煩,易出錯。

 

 

 

 資料安全:在SQL Server層面有兩份或者多份資料,但是資料同步是非同步的,有幾秒鐘的延遲,而且不是整庫的同步,丟失資料的風險很高。
資料同步驗證:訂閱伺服器上的資料庫是可以查詢的,可以隨時執行SQL語句進行驗證。可用性:沒有虛擬IP地址、自動故障切換等可用性的功能。讀寫分離&負載均衡訂閱伺服器上的資料庫是可以查詢的,可以把高消耗的報表類的查詢分離到訂閱伺服器中,但是需要修改應用程式實現“讀寫”和“只讀”兩種資料庫連線。負載均衡需要藉助負載均衡軟體或硬體。

AlwaysOn

AlwaysOn是SQL Server 從2012版本開始推出的多個例項間同步資料庫的技術,藉助Windows失敗轉群集實現高可用,主副本出現故障後,自動切換到輔助副本。輔助副本中資料庫都是可以查詢的,可用來實現讀寫分離、負載均衡等功能。

AlwaysOn中每個副本的SQL Server服務獨立安裝,使用每個副本自己儲存介質內的資料庫檔案。在主副本寫入資料時會產生日誌,AlwaysOn捕獲並傳輸日誌到其他副本,並透過REDO技術完成日誌到資料的轉換,從而實現各副本中資料的一致性。有同步提交和非同步提交兩種同步方式,不同的副本可以使用不同的同步方式。

 

 

 資料安全:在SQL Server層面有兩份或者多份資料,可以保障資料安全。AlwaysOn同步日誌資料時有資料格式的校驗,不會同步不完整的日誌,在大資料量寫入時突然掉電關機,主節點資料庫出現質疑時,輔助節點不會。
資料同步驗證:每個節點上的SQL Server服務都是開啟的,資料都是可供使用的,可以隨時執行SQL語句進行驗證。可用性:AlwaysOn不支援對例項級別的物件同步,例如登入賬號、作業、連結伺服器、系統資料庫物件,需要人工維護,靠人工的方式保障每個副本的一致性是很困難的。在實踐過程中發現,輔助副本切換成主副本時,因為賬號不對、密碼不對、許可權不對、資料庫對映關係不對、作業不對、系統物件不對等各種原因導致業務系統無法正常使用的情況非常普遍。故障轉移時間:副本轉移時不需要經過資料庫初始化的過程,切換速度快,少於10秒。讀寫分離輔助副本的資料庫是可以查詢的,可以把高消耗的報表類的查詢分離到輔助副本中。在AlwaysOn下實現讀寫分離,應用程式建立資料庫連線時使用的資料庫連線字串中加上“ApplicationIntent=ReadOnly”關鍵詞,AlwaysOn把該連線建立到輔助副本。重要的前提是該連線裡面所有的SQL語句都必須是隻讀的,如果有更新的SQL語句,就會報錯。也就是說AlwaysOn的讀寫分離是連線級的,不是語句級的。很多人認為只要在資料庫連線串中加好這個關鍵詞,不需要改動應用程式就能實現讀寫分離,這是個非常大的誤區。要修改應用程式實現“讀寫”和“只讀”兩種資料庫連線。這個改造過程對於自己研發的產品來說是容易的,如果是購買的第三方產品,難度就可想而知了。負載均衡SQL Server 從2016版本開始實現了負載均衡,前提是應用程式先實現讀寫分離。AlwaysOn的負載均衡策略是靜態的輪詢機制,不管副本壓力如何,都按照順序輪詢在每個副本中建連線。AlwaysOn的排程是連線級的,不是語句級的,連線建立後,不管該副本壓力如何,連線內的語句都要在該副本中執行。

Moebius

Moebius採用“share nothing”架構,每個節點的SQL Server服務獨立安裝,使用每個伺服器自己儲存介質內的資料庫檔案。不基於共享儲存裝置,也不基於磁碟映象等功能,透過SQL Server的日誌同步技術實現各節點中資料的一致性。在主節點寫入資料時會產生日誌,Moebius捕獲並傳輸日誌到其他節點,並透過REDO技術完成日誌到資料的轉換。因此每個節點的SQL Server服務都是啟動的,資料都是“活”的。

       Moebius的排程引擎支援連線級和SQL語句級兩種排程方式,透過規則的配置,在不改動或者少改動應用程式的前提下,透明的完成讀寫分離、負載均衡。

 

 資料安全:在SQL Server層面有兩份或者多份資料,可以保障資料安全。Moebius同步日誌資料時有資料格式的校驗,不會同步不完整的日誌,在大資料量寫入時突然掉電關機,主節點資料庫出現質疑時,輔助節點不會。
資料同步驗證:每個節點上的SQL Server服務都是開啟的,資料都是可供使用的,可以隨時執行SQL語句進行驗證。可用性:支援資料庫和例項級物件(登入賬號、作業、連結伺服器、系統庫物件等)的同步,滿足真正的高可用。故障轉移時間:節點轉移時不需要經過資料庫初始化的過程,切換速度快,少於10秒。讀寫分離每個節點上的SQL Server服務都是開啟的,資料都是可供使用的。Moebius的排程引擎支援語句級的解析,只需要修改應用程式的資料庫連線串讓應用程式連線到Moebius叢集的埠,在Moebius中配置基於語句特徵的相關規則就可以在不修改或者少修改應用程式的前提下實現讀寫分離。Moebius支援SQL語句、登入名、客戶端主機名、應用程式名等多個維度進行規則的配置。負載均衡:Moebius是基於節點壓力狀況的動態負載均衡策略,排程引擎定期快取每個節點的負載情況(CPU利用率、IO效能指標、請求數等),應用程式執行查詢語句時,排程引擎選擇到壓力較小的節點執行。

總結

從根本上說是通用技術和SQL Server專用技術的比較,如果要實現資料安全和可用性等基本需求,通用技術就能可以做到,如果要實現讀寫分離、負載均衡等高階別的需求,就需要充分利用SQL Server特性而開發的專用技術。並不是說通用技術不好,只是滿足的場景不同而已,我們要根據實際的場景選擇合適的方案。

 

相關文章