RDMA網路下重思資料庫高可用
RDMA 網路下重思資料庫高可用
摘要
高可用資料庫系統常常使用用資料複製來達到容錯的目的。Active-passive 和 active-active 複製演算法都是嚴重依賴於時延,網路常常成為效能的主要瓶頸。從某種意義上說,這些技術旨在最小化副本之間的網路通訊。然而,下一代網路的出現,以期高吞吐低延遲的特性,使得需要重視這些假設。
首先提出,現代RDMA 網路使得瓶頸轉向 CPU ,因此現代網路最佳化的複製技術不再是最優選擇。提出了一個新高可用機制 active-memory 複製,充分利用 RDMA 達到消除在複製中處理多餘工作的目的。使用 active-memory ,所有 replica 都將 CPU 能力專用於執行新事物,而不是複製的冗餘計算。當出現故障時, active-memory 透過基於 RDMA 的 undo 機制,維護高可用和資料正確性。實驗表明, active-memory 比第二種協議在 RDMA 網路上快 2 倍。
引言
任何傳統資料庫系統都有一個關鍵功能:高可用。單機情況下,故障會導致資料庫服務不可用並且會造成資料丟失。高可用通常透過分散式資料複製來完成。主機上update 會複製到備機從而當主機故障時可以被備機替代。
傳統分散式系統設計時針對的是:網路是服務效能的瓶頸。在同一個資料中心內透過傳統的10- 千兆乙太網傳送訊息,例如,與訪問本地記憶體相比,網路傳輸在高延遲和低頻寬上會差上 2-3 個數量級。高可用方法主要有 active-passive 和 active-active ,這兩種方法都是為了最佳化網路負載。
隨著下一代網路的出現,傳統的高可用協議不再適用,尤其是在區域網環境中。基於RDMA 的網路,具有和主存相近的頻寬,只有其 10 倍的高延遲。我們對 active-passive 和 active-active 機制實驗表明,現代 RDMA 網路下,效能瓶頸轉向 CPU 的計算負載。因此傳統網路最佳化高可用機制不再是最優的方案。需要設計新的協議全力釋放 RDMA 硬體的紅利。
為此,我們提出active-memory 複製協議適配 RDMA 硬體。在執行資料複製時, active-memory 最佳化目標在於最小化 CPU 負載而不是最小化網路負載。該機制核心思想:使用 RDMA 單邊特性,直接在遠方備機上直接 update 記錄,而不需要遠端 CPU 的參與。這種設計的挑戰在於,備機 CPU 不參與複製協議下如何達到故障容錯。為解決這個問題,我們設計了意向新型的 undo-logging based replication protocol ,所有邏輯都由主機單方面執行。每個事務經歷兩個階段:( 1 ) undo logging 和本地 update ( 2 )日誌空間回收,其中每個 update 都由單獨的 RDMA 寫來執行。我們證明了在不同故障場景下該機制的正確性。和 active-passive 、 active-active 相比, active-memory 快兩倍。
本文貢獻如下:
重視下一代網路上傳統高可用協議,證明最佳化網路負載不再是最合適的設計目標。
提出active-memory 協議,部署在 RDMA 高速網路上。
關係型關聯式資料庫中的高可用
因各種不同原因,資料庫系統會發生故障:硬體故障、網路通訊故障、軟體bugs 、人為故障等。高可用系統可以保證資料庫系統發生這樣故障時仍提供服務達到零當機時間。
高可用通常透過複製來完成:資料庫每個記錄都會複製到一個或多個機器。為了達到容忍k 個機器故障的目的,需要將事務的資料複製到至少 k+1 節點。例如,當 k 等於 1 時,每個記錄儲存在兩個不同的及其上,這樣不論哪個機器故障都不會阻塞系統服務的持續性。
Gray 對複製進行了分類: eager 或 lazy 複製。強一致性要求不高的場景下常常應用 lazy 複製,能夠接受丟失資料的可能,例如 Amazon Dynamo 和 Facebook Cassandra 。
本文我們關注eager 複製,即以 share-nothing 架構下的強一致性複製。資料庫必須保證事務的 update 需要倒到 replica 後才能提交。強一致性處理機器故障變得簡單,因為所有副本在同一個時間內都是相同的。
強一致性複製可分為兩類:active-passive 和 active-active 。講解了這兩類複製的有點和缺點並討論他們耗費和限制。
active-passive複製
一個主,接受寫操作;主將其資料複製到一個或多個從。一旦主故障,則選擇一個從提升為主。學術型或者商業資料庫的active-passive 複製實現有多種方式,通常透過日誌複製,備機進行回放從而獲得主機上的寫資料。
圖1 顯示了 active-passive 機制下日誌如何傳輸。假設資料庫有 2 個分割槽( P1 和 P2 ),每個分割槽都有一個備份( B1 和 B2 )。實際上 B2 和 P1 可能在同一臺機器上,而另外兩個在同一臺機器上。藍色, T1 是一個單分割槽事務,資料只在 P1 上。因此 P1 執行事務,提交前將日誌發向所有備份。當接收到備份的 ack 後, P1 才能提交。同樣事務也可以擴充套件到多分割槽,正如 T2 ,複製協議一樣,只是兩階段提交。
該模式的複製因其簡單性和通用性而被廣泛使用。然而有2 個缺點。事務日誌包含所有改動,造成日誌很大。由於通用網路的頻寬限制,造成嚴重瓶頸。主備間的通訊延遲可能成為瓶頸。
active-active複製
第二類複製時eager 複製,無論哪個節點都可以更新。系統允許多節點更新並將其改動傳播到各個副本。由於可能事務衝突,所以需要節點進行更多協作。這樣的資料庫系統主要透過副本上的執行順序解決這個問題。 active-active 複製為了減少網路通訊需要傳輸日誌並且和其他副本以 active-passive 機制進行協作。尤其是,事務分組成批,副本上按同樣的順序執行這批事務,這樣所有的節點最終資料都是一樣的。副本只需要將事務分批,之後不會再進行通訊協作,減少了網路通訊。 H-store 和 Calvin 使用 active-active 複製機制。
圖2 是 H-store 的複製協議。 H-store 中所有事務會提前註冊成儲存過程。 H-store 中事務不會獲取記錄鎖,只鎖需要的分割槽。事務按分割槽順序執行。單分割槽事務 T1 , primary 將儲存過程的 ID 複製到所有 replica ,所有的備份包括 primary 並行執行事務。和日誌傳輸不同,副本不需要協作,因為他們執行相同的事務序列。對於多分割槽事務, primaries 的一個作為事務協調者,傳送儲存過程及其引數到其他分割槽。每個分割槽需要加排它鎖,並將儲存過程傳送到其備節點,從而所有節點執行相同事務構建寫集合。最終,協調者發起兩階段提交確保其他 primary 也可以提交。單分割槽事務 TPS 很高,多分割槽事務效能指數級下降。由於多分割槽事務會對分割槽加鎖。
如圖3 所示, Calvin 是一個和 H-store 不同方法的 active-active 系統。所有事務首先進入 sequencer ,進行排序。事務的輸入被記錄下來併傳送到所有副本。每個分割槽的鎖管理執行緒遍歷該歷史連結串列並獲取每個事務的鎖。如果鎖被佔用,這個事務就需要等待。因此, Calvin 需要提前知道事務的讀寫集合,這樣鎖管理器才能知道加什麼鎖。所有事務加鎖後,副本上的 worker 執行緒無需協作執行事務。對於多分割槽事務,參與的分割槽透過推送結果的方式進行互相通訊。
H- store 對單分割槽事務消耗較小, Calvin 在多分割槽事務上有較好效能。
基於RDMA 網路的複製
隨著網路技術的快速發展,傳統日誌傳輸和active-active 複製機制不再是最優方案。本節介紹傳統複製機制的設計方案和為什麼下一代網路上需要新的高可用機制,然後介紹 RDMA 的一些背景。
瓶頸分析
上文介紹的複製機制針對網路通訊時延為瓶頸來設計的。因此減少訪問網路是高效複製演算法的設計原則。這兩類技術透過交換網路請求和更多冗餘處理來實現這個原則。圖4 說明該思想。日誌傳輸到 replica 後,需要回放。 Active-active 技術減少了網路通訊,當網路是瓶頸時,能夠提高效能。
複製中網路通訊非常昂貴的因素:網路頻寬的限制;作業系統處理資訊的成本;網路通訊高延遲。隨著下一代RDMA 網路的出現,這些因素需要重新評估是否是瓶頸。網路頻寬大大提高。 RDMA 為新演算法的設計提供了可能。 RDMA 低延遲,零複製、 CPU 旁路特性。 RDMA 網路的出現,瓶頸轉向 CPU 而不是玩過,如圖 4b 。
RDMA背景
RDMA 特性可以使機器無需遠端機器作業系統進行操作而直接訪問其記憶體,即 zero-copy 資料。由於支援 RDMA 的網路技術在乙太網上變得更具成本競爭力,所以資料庫中使用 RDMA 釋放其硬體紅利也更具吸引力。 RDMA 實現技術的三種方式: InfiniBand 、 RoCE 和 iWarp 。透過繞過作業系統、完全解除安裝網路協議棧,在網路卡上允許 RMDA 具高吞吐量、低延遲和低 CPU 使用率。例如, Mellanox ConnectX-6 RNICs 能夠每秒傳輸 200GB 的資料,延遲不到 1us ,每秒能夠處理 200million 資訊。
RDMA 介面提供兩種操作型別:單邊( read , write 和原子操作)和雙邊( send 、 receive )。單邊操作,不用遠端機器 CPU 參與,提供使用者級別的記憶體訪問介面直接訪問遠端記憶體進行讀寫。雙邊操作,提供兩邊使用者級別的資訊傳出介面用於交換 RPC 資訊。和單邊操作不同,雙邊操作需要兩邊的 CPU 參與。
兩種處理方式透過queue pairs 進行彼此通訊。 Reliable Connected pairs 下,包順序傳輸並且不會丟失。這兩種特性是我們複製和故障容錯協議的關鍵。
active-memory :基於 RDMA 的複製
這一部分首先介紹active-memory 複製,然後介紹基於 RDMA 的高可用解決方案,最後提出詳細的複製演算法。
併發控制和複製假設
本文針對分散式shared-nothing 資料庫提出 active-memory 複製機制。 Master 節點上有記錄的主副本,其他 backup 節點上都有一個備份副本。事務只訪問 primary 的副本,而其他節點值被複制更新。這是避免有事務在備機上讀取到未提交的資料。
本文,關注兩階段NO_WAIT 加鎖策略。但是我們要求,事務內對資料結構的修改都是原子的,如果沒有這要求,那麼透過 RDMA 進行記憶體複製就會複製到未提交的修改。透過在共享資料結構上使用排他 latch 來確保這個前提。當然還有其他方法確保。最後假設每個節點部署在 NVM 上。
概述
active-memory 在 RDMA-enabled 網路上採用主備複製機制。協作者透過 RDMA 的單邊寫操作直接將事務的資料寫到備機的記憶體,而不是將日誌複製到備機。因此備機的 CPU 不再摻和到資料複製的邏輯中,而全心的投入到處理新事務上。準確的說,對於每個事務,複製協議涉及兩個階段: 1 ) undo log 傳輸及本地更新; 2 )日誌空間回收。
active-memory 突出的特點:
強一致性 :active-memory 提供強一致性。備節點資料總是顯示最近提交的事務,並且不會落後主。新備支援快速、直接故障切換。
零處理冗餘 :和日誌傳輸和active-active 不同, active-memory 全面消除了複製協議中的冗餘處理。邏輯上事務只執行一次。備節點不需執行事務程式碼並不需回放日誌。備機的 CPU 用來處理新事務。
訊息處理零開銷 :依賴RDMA 單邊操作, active-memory 能夠避免 send 、 receive RPC 訊息造成的開銷,包括 TCP/IP 開銷,以及在每個資料庫節點分發機制的訊息帶來的開銷。
簡單快速容錯 :無論普通執行模式下複製協議執行的有多高效,從故障中恢復必須是可靠並一致的,當然更要快。本文充分利用RDMA ,提供一種故障容錯的快速簡單的機制。
active-memory 中 CPU 消耗的減少,帶來的是網路流量的增加。然而,在新一代的 RDMA 網路中以其高頻寬的特性使得這不是問題。
設計挑戰
active-memory 機制非常簡單,但也有設計挑戰:支援故障容錯及非阻塞快速恢復。為了確保正確性,協調者必須保證他的修改要麼全部複製到所有備節點,要麼都沒有複製到。和日誌傳輸協議不同,備節點不參與複製協議。因此協調者必須單方面保證故障容錯,這使得設計更具挑戰性。
為達到這個目標,active-memory 依賴 undo 日誌機制,而不是傳統的 redo 日誌機制。協調者在直接更新備節點記憶體狀態前,將 undo 日誌寫到備節點。
另一個挑戰是無阻塞恢復,當一個或多個協調者或者備節點故障後,要求系統快速恢復到一致性狀態。active-memory 確保至少有一個節點總是有足夠的資訊,從而能夠恢復到一致性狀態。
undo log buffer
active-memory 使用基於 RDMA 的 undo 日誌機制確保故障原子性。每個 server 節點都會有一個預分配的 RDMA buffer 。這個 buffer 維護一系列固定大小的日誌記錄,並以環形的方式部署。每個 buffer 僅能被一個遠端 server 節點更改。因此不會有併發訪問問題。
每個節點維護一個連結串列,該連結串列是其他對應機器的可用undo log 記錄。也就是說,每個機器指定遠端 log buffer 的連結串列頭和尾指標。透過發起一個 RDMA 寫操作,將一個日誌記錄放到遠端 buffer 。 Buffer 以環形的方式意味著:不再使用的日誌記錄空間可以被重複使用。
日誌記錄的結構如圖5 所示。每個日誌條目儲存該事務修改前的內容。例如修改 3 個記錄的 2 個欄位的一個事務將會擁有 6 個改動欄位( ChangesCnt=6 ),對於每個改動欄位,每個條目包含自己的 HostID 以及在其機器上的欄位記憶體偏移,長度( Len ), Payload 中的未更改前內容。只儲存更改欄位的值,而不是整個記錄的內容,大大減小了日誌大小,從而也減小了每個事務需要傳送的日誌量。每個日誌條目都有一個唯一符 LogID 。如果日誌超出了條目固定大小,會在後面緊接著一條日誌條目儲存剩餘內容,該日誌條目和上個 LogID 相同。 IsLast 為 false 的日誌條目表示後續還有日誌。協調者會在每條日誌後面設定和 LogID 相同值的 LogID_Check 。只有 LogID 和 LogID_Check 相同,才認為該日誌是有效的。由於 receiver 端, NICs 確保 RDMA 的寫以地址增長的方式進行,也就是說 LogID_Check 不會再 LogID 之前。因此這樣的機制保證記錄自己能夠校驗正確性。最後 ISCommitted 表示事物的提交狀態。
對於一些負載場景,undo log buffer 不能夠放下所有的 write-sets 。這樣的場景能夠依賴 RPC-based 日誌傳輸,協調者傳送給每個備 RPC 訊息。備進行回放並向主傳送 ack 。通常情況下,系統必須滿足給定的負載,需要的話,就需要擴大 log buffer 大小。
複製演算法
下面詳述active-memory 複製協議。主一旦構建了讀寫集合,就啟動這個複製。 active-memory 假設,針對每個事務,主包含一個本地的 write-set (包含一系列唯一鍵以及即將更改的新值)。執行結束時,事務準備提交併將這些 write-set 集合內容合併到資料庫。當協調者啟動複製階段時,進行本地更新並將日誌提交(複製階段有兩步)。
第一步:undo log 及本地更新
這一步的目標:1 )複製 undo log ; 2 )直接更改 write-set 裡的記錄。這兩步在事務涉及到的分割槽上及其副本上必須執行,此後稱為活動節點。該演算法必須保證每個活動節點,記錄 undo log 後才會進行本地更新。
Listing 1 為這一步的演算法虛擬碼。概括起來說,協調者掃描他的 write-set 並形成每個活動節點 RDMA 操作的連結串列。連結串列的第一條資訊是 undo log RDMA 寫操作,剩下的是:針對分割槽上記錄本地更新的 RDMA 寫。可靠連線佇列對兒的有序訊息傳輸的保證,遠端 NIC 在本地更新訊息前,接收到的日誌資訊。這樣的保證傳輸順序是故障容錯機制的關鍵。
協調者針對事務中每個活躍節點p 執行下面流程:
1) 檢索並更新節點P 上的 undo log buffer 的尾指標
2) 初始化一個日誌條目(後續會在P 上覆制到 replicas ; IsCommitted 設定為 false )
3) 檢索並獲取p 上 write-set 的記錄(第 6 行)
4) 將更改的欄位值新增到日誌條目(8-13 行)
5) 透過新增一個undo log 條目( 16-18 )和資料更新( 20-25 ),構建 RDMA 資訊連結串列。如圖 6 所示。
6) 發啟將這個連結串列傳輸到p 及其所有 replicas ( 27-30 )。
將這個連結串列一次釋出,而不是單獨釋出。這樣允許底層驅動進行最佳化,在傳送端使用更少的CPU ,從而提升效能。
未簡潔起見,假設所有的更改都能夠放到一條日誌資訊裡。多條目日誌資訊處理方式相同。IsLast 只有在最後一條日誌設定 TRUE 。
一旦傳送了日誌和更改資訊,事務等待遠端傳送接收到日誌反饋的ACK 。表示事務日誌和更改資料已經複製到所有活躍節點,協調者可以進入下一步操作。
第二步:提交日誌
這一步的目的:完成k-safe 特性。協調者首先透過 RDMA 寫將每個活躍節點的 IsCommitted 設定為 TRUE ,如圖 7 所示。協調者的 NIC 將 RDMA 寫訊息傳送後,本地將對應 undo log buffer 的頭指標加 1 ,表示這個條目可以被後續事務重用了。同時將日誌放到 NVM ,釋放鎖並返回使用者。
active-memory 充分利用 RDMA 中可靠連線佇列對兒的有序訊息傳輸。使用這樣的連線型別,接收端 NIC 接收的訊息順序和傳送順序相同。即使協調者在複製中途出錯,本地更新的 RDMA 訊息不會影響接收端。
故障容錯
這一部分介紹如何在不犧牲正確性和高效下,在各種故障場景下保證故障容錯。先介紹單分割槽事務的恢復機制,然後擴充套件到多分割槽事務。
備故障恢復
備機故障恢復比較簡單明瞭。不需要執行任何複製流程,而且由協調節點(S )維護複製狀態。我們複製協議中,只有所有更新都複製到備後才會返回使用者。因此, S 成功完成複製過程的第二步前備機故障, S 不會返回客戶端,而是等叢集管理者廣播新配置,一旦接收到, S 就知道是否提交或者需要複製到更多機器。在步驟二中間或者結束時故障,協調者不會回滾一個事務。
主機故障恢復
主機故障恢復具有挑戰性。透過這些日誌,備份為了維護系統事務一致性,可以知道是否重建、提交或放棄該事務。P 機器故障, S 可以執行下面過程:
1、 S 關閉到 P 的 RDMA 佇列對兒,一旦 S 開啟恢復,即使 P 從故障中返回併發起新的 RDMA 操作也不會成功。
2、 S 檢查 S 本地記憶體中 P 的 log buffer ,標記 buffer 中是萬物是否提交即 T P 。
3、 針對T P 中的每個事務t , S 檢測 t 的 undo log 的 change 部分是否有對應資料記錄
4、 S 重組狀態資訊,並廣播到所有存活節點。狀態資訊包含 P 和 S 的 ID , T P 中t 的兩個條目:( t 的 ID 和 t 的狀態),分別為事務的 ID 和 S 上事務的當前狀態。 t 的狀態可能四種的一種: 1 )損壞日誌: t 的日誌至少有一個 LogID_check 和 LogID 不匹配,或者最後一個日誌的 IsLast=true 。這種情形下,資料記錄保持不變,因為在更新前傳輸 undo 日誌。 2 ) Logged ,日誌條目正確,但是 CommitBit 是 0 。資料可能保持不變(比如 update 訊息沒有接收到),資料損壞(直接收到部分 update 訊息),或者 fully update (接收到所有 update 訊息)。 3 ) commit-ready : CommitBit 為 1. 接收到所有 undo log 和資料記錄必須更新。
5、 S 將他的狀態資訊廣播到所有存活節點,並接收存活節點的狀態資訊。
6、 一旦接收到狀態資訊,如果所有相關節點的事務是Commit-ready 狀態,那麼 S 提交事務。否則放棄該事務,透過 undo 日誌回滾並釋放本地的 log buffer 。
一旦所有備份節點恢復並提交了正在執行的事務,通知叢集管理選新主並繼續常規處理。
多分割槽事務恢復
多分割槽事務處理多主的資料,其中一個分割槽作為協調者。在複製階段,協調者負責構造日誌條目和本地更新。所有節點都反饋給協調者ack 後,多分割槽事務才提交。
恢復過程和單分割槽事務類似。如果故障節點不是活躍事務的協調者,協調者在叢集重配後決定是否複製更多機器。如果協調者故障,所有其他節點本地構造並廣播事務狀態。唯一不同的是所有涉及到的分割槽上的節點都是Commit-ready 狀態才會提交。
總結
本文提出了active-memory 一個基於 RDMA 的機制,提供高可用功能並具備強一致性。透過使用新型的 RDMA 相容的 undo log 機制;透過 RDMA 單邊寫操作直接更改資料記錄,從而減少 CPU 使用率。
原文
Rethinking Database High Availability with RDMA Networks
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31493717/viewspace-2668646/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- MySQL資料庫高可用方案MySql資料庫
- ES資料庫高可用配置資料庫
- posgresql資料庫高可用方案-patroniSQL資料庫
- Centos 7 搭建MariaDB 資料庫高可用CentOS資料庫
- 資料庫高可用性簡史資料庫
- async-rdma:編寫高吞吐量、低延遲網路應用的Rust庫Rust
- 郭憶:網易資料庫高可用架構最新進展!資料庫架構
- MySQL資料庫架構——高可用演進MySql資料庫架構
- 5、pgpool-II高可用性(一)資料庫的高可用性資料庫
- RDMA:遠端直接存取資料,國產網路卡
- 資料庫管理-第221期 Oracle的高可用-04(20240717)資料庫Oracle
- 阿里雲Polardb國產資料庫高可用部署實踐阿里資料庫
- 基於 Apache ShardingSphere 構建高可用分散式資料庫Apache分散式資料庫
- SQL server資料庫高可用日誌傳送的方法SQLServer資料庫
- 海量資料架構下如何保證Mycat的高可用?架構
- LightDB-高可用主庫常規維護重啟操作
- 乾貨|上雲了,如何保障雲資料庫的高可用?資料庫
- 乾貨 | 京東雲資料庫RDS SQL Server高可用概述資料庫SQLServer
- 高併發下如何避免產生重複資料?
- 使用 MaxScale 實現資料庫的高可用性和彈性資料庫
- 巨杉Tech|SequoiaDB 巨杉資料庫高可用容災測試資料庫
- MySQL資料庫實現高可用架構之MHA的實戰MySql資料庫架構
- MySQL資料庫各場景主從高可用架構實戰MySql資料庫架構
- 資料庫高可用面臨的挑戰與解決之道|OceanBaseDev資料庫dev
- 大型網際網路高可用架構設計實踐2019架構
- GaussDB跨雲容災:實現跨地域的資料庫高可用能力資料庫
- SQLServer2012高可用映象資料庫 實施方案(非域環境)SQLServer資料庫
- 網際網路資料庫架構設計資料庫架構
- 資料庫系列:高併發下的資料欄位變更資料庫
- 超大規模資料庫叢集保穩系列之一:高可用系統資料庫
- 確保Oracle 11g R2資料庫高可用性WQOracle資料庫
- 資料庫系列:InnoDB下實現高併發控制資料庫
- MySQL 資料庫之網際網路常用分庫分表方案MySql資料庫
- Android連線網路資料庫的方式Android資料庫
- 3.2 改變資料庫可用性資料庫
- [重慶思莊每日技術分享]-ORACLE DG物理備庫使用別名資料檔案改變路徑到OMF路徑Oracle
- 如何構建高可用、高併發、高效能的雲原生容器網路?
- 【OB小藍科創館】3分鐘揭祕 OceanBase 資料庫特性——高可用!資料庫