容器化RDS—— 計算儲存分離 or 本地儲存

沃趣科技  熊中哲

---

隨著交流機會的增多(集中在金融行業, 規模都在各自領域數一數二), 發現大家對 Docker + Kubernetes 的接受程度超乎想象, 並極有興趣將這套架構應用到 RDS 領域. 資料庫服務的需求可以簡化為:

實現資料零丟失的前提下,提供可接受的服務能力

因此儲存架構的選型至關重要. 到底是選擇計算儲存分離還是本地儲存?

本文就這個問題, 從以下幾點展開 :

●     回顧 : 計算儲存分離, 本地儲存優缺點

●     MySQL 基於本地儲存實現資料零丟失

●     效能對比

●     基於 Docker + Kubernetes 的實現

分享個人理解.

回顧 : 計算儲存分離, 本地儲存優缺點

還是從計算儲存分離說起,

計算儲存分離

先說優點 :

●     架構清晰

●     計算資源 / 儲存資源獨立擴充套件

●     提升例項密度, 優化硬體利用率

●     簡化例項切換流程 : 將有狀態的資料下沉到儲存層, Scheduler 排程時, 無需感知計算節點的儲存介質, 只需排程到滿足計算資源要求的 Node, 資料庫例項啟動時, 只需在分散式檔案系統掛載 mapping volume 即可. 可以顯著的提高資料庫例項的部署密度和計算資源利用率.

以 MySQL 為例

●     通用性更好, 同時適用於 Oracle , MySQL

       詳見 : <容器化RDS : 計算儲存分離架構下的"Split-Brain">

從部分使用者的上下文來看, 存在如下客觀缺點 :

●     引入分散式儲存, 架構複雜度加大. 一旦涉及到分散式儲存的問題, DBA 無法閉環解決.

●     分散式儲存選型,

○     選擇商用, 有 Storage Verdor Lock In 風險

○     選擇開源, 大多數使用者(包括沃趣)都測試過 GlusterFS 和 Ceph ,針對資料庫(Sensitive Lantency)場景, 效能完全無法接受.

本地儲存

如果在意計算儲存分離架構中提到的缺點, 本地儲存可以有效的打消類似顧慮,

無需引入分散式儲存, 避免Storage Verdor Lock In 風險, 所有問題都由DBA 閉環解決,.

但是, 需要依賴資料庫自有方案實現資料零丟失

以 MySQL 為例

還會引入類似問題,

●     物理容量受限於單機容量;

●     排程更復雜, 選定資料庫例項的儲存型別(比如 SSD )後, 一旦該例項發生”failover”, 只能排程到擁有 SSD 的物理節點, 這導致排程器需要對物理節點”Physical Topology Aware”;

●     密度難提升, 這是”Physical Topology Aware”的副作用;

●     因資料庫的不同方案差異性較大, 通用性無法保證.

接下來, 進入正題, 看一下 MySQL 基於本地儲存如何實現資料庫零丟失.

---

MySQL 基於本地儲存資料零丟失

最常用的是基於 Replication 模型將資料複製到 MySQL Cluster 中所有成員.

MySQL Master-Slave Replication (類似 Oracle DataGuard) 提供了基於 binlog 的資料庫層的複製模型, 在高併發壓力下節點間同步資料速率最快, 單位時間內的交易量受其他節點的影響極小, 該架構可通過 vip 漂移的方式實現 “failover”

MySQL Master-Slave Replication

但嚴格意義上來說, 這是基於 binlog 的 Asynchronous Replication 模型, 因此叢集中所有成員存在資料不一致的可能,在”failover”時無法保證資料零丟失.

可見如果基於 Replication 模型, Synchronous Replication 是實現資料零丟失的前提.

傳統的 Synchronous Replication 一般會採用兩階段提交或分散式鎖, 這會帶來如下幾個問題 :

●     單位時間內事務能力(TPS) 會跟叢集成員數量成反比

●     增加叢集成員會顯著且無法預期的增加事務響應時間

●     增加了叢集成員資料複製的衝突和死鎖的可能性

針對以上問題 Galera Cluster 提出 Certification-based Replication 來解決傳統 Synchronous Replication 中遇到的問題, 實現如下 :

Deferred Update Replication 延遲更新複製

這個流程圖中, 有幾個細節需要分享,

●     將基於 binlog 改為基於 write-set. write-set 中包含修改的資料, Global Transaction ID (後面簡稱 GTID)和 Primary Key.

○     GTID 類似 45eec521-2f34-11e0-0800-2a36050b826b:94530586304

○     94530586304 為64-bit 有符號整型, 用來表示事務在序列中的位置

●     將傳統的 Synchronous Replication 改為 Deferred Update Replication, 並將整個過程大致分解成四個階段, 本地階段, 傳送階段, 驗證階段和應用階段, 其中 :

○     本地階段 : 樂觀執行, 在事務 Commit 前, 假設該 Transcation 在叢集中複製時不會產生衝突

○     傳送階段 : 優化同步時間視窗, 除去全域性排序並獲取 GTID 為同步操作, 衝突驗證和事務應用都為非同步, 極大的優化了複製效率.

○     驗證階段 : 只有收到該事務的所有前置事務後(不能有 “hole”), 該事務和所有未執行的前置事務才能併發驗證, 不然不能保證 Global Ordering, 因此這裡需要犧牲效率, 引入一定的序列化.

      

需要等待事務3

於是就有了 Galera Cluster 在 MySQL 分支中的實現 MariaDB Galera Cluster (簡稱 MGC) 和 Percona Xtradb Cluster (簡稱 PXC)

為避免”split-brain”問題, 需要至少三節點組成叢集, 對計算資源和儲存資源的容量要求至少增加2倍, 會進一步降低資源的部署密度

越來越多的使用者也期望通過該方案實現 跨 IDC 多活, 那麼需要在規劃階段想清楚 :

     IDC 和 資料庫節點的拓撲架構, 以保證在1個 IDC 出問題的情況, 叢集可以持續提供服務

首先IDC (物理或邏輯) 最少需要3個, 再看看資料庫節點數量分別為3, 4, 5, 6, 7的拓撲關係 :

●     3 資料庫節點 :

●     4 資料庫節點 :設定權重避免”split-brain” (? + ? ) + ? + ?

                         

●     5 資料庫節點

●     6 資料庫節點

●     7 資料庫節點 : 可支援兩種拓撲關係

同時, 還有 MySQL Group Replication^[1] (簡稱 MGR), 類似 Galera Cluster :

●     基於Corosync實現(Totem協議), 外掛式安裝, MySQL 官方原生外掛.

●     叢集架構, 支援多寫(建議單寫)

●     允許少數節點故障, 同步延遲較小, 保證強一致, 資料零丟失

●     單位時間的交易量受 flow control 影響.

這裡還需要提一下 Vitess^[2]

●     該專案由 youtube 開源, 從文件看功能極為強大, 高度產品化.

●     作為第二個儲存類專案(第一個是 Rook, 有意思是儲存類而不是資料庫類)加入 CNCF, 目前還處於孵化階段(incubation-level).

●     筆者沒有使用經驗, 也不知道國內有哪些使用者, 不做評論.

關於 MGR 和 Vitess 網上已有大量介紹, 這裡不再贅述.

效能對比

在資料零丟失的前提下,  看看這幾種架構在效能上的對比:

●     MGR 5.7.17 / PXC 5.7.14-26.17

●     MGR 5.7.17 / PXC 5.7.17-29.20 /  MariaDB 10.2.5 RC

●     本地儲存 / 計算儲存分離

效能對比1 : MGR 5.7.17 / PXC 5.7.14-26.17

測試背景描述:

●     MGR 5.7.17  對比 PXC 5.7.14-26.17 (基於 Galera 3實現)

●     負載模型 : OLTP Read/Write (RW)

●     durability          : sync_binlog=1, innodb_flush_log_at_trx_commit=1

●     non-durability  : sync_binlog=0, innodb_flush_log_at_trx_commit=2

測試資料 : 

                            來自於 MySQL 官方^[3]

測試結果:

在設定 durability 的情況下,  MGR 最大吞吐約是PXC 5.7.14-26.17 (基於 Galera 3 實現) 的3倍, 優勢明顯.

以上資料來自於MySQL 官方, 公平起見, 再來看看 Percona 在相同負載模型下的測試資料.

效能對比2 : MGR 5.7.17 / PXC 5.7.17-29.20 /  MariaDB 10.2.5 RC

測試背景描述:

●     增加了 MariaDB 參與對比

●     PXC 升級到 5.7.17-29.20, 該版本改進了MySQL write-set 複製層效能^[4].

●     負載模型 : 依然使用 OLTP Read/Write (RW)

●     durability          : sync_binlog=1

●     non-durability  : sync_binlog=0

測試資料 :

設定 durability , 資料來自於 Percona^[5]                

      

設定 non-durability , 資料來自於 Percona^[6]  

測試結果:

在負載模型相同的情況下(durability 和 non-durability) PXC 5.7.17-29.20 效能與 MGR 5.7.17 不分伯仲^[7]. 如果使用 PXC, 推薦使用 5.7.17-29.20 或以上版本.

效能對比3 : 本地儲存 / 計算儲存分離

為了對比本地儲存和計算儲存分離, 專門使用 MGR + 本地儲存架構 和 基於分散式儲存的計算儲存分離架構做效能對比.

測試結果:

       在負載模型相同的情況下, 前者比後者 OLTP 下降32.12%, Select下降5.44%, Update下降24.18%, Insert 下降58.18%, Delete下降11.44%;

詳細內容可留意 @波多野 同學 和 @韓傑 同學的測試報告, 這裡不再贅述.

基於 Docker + Kubernetes 的實現

Docker + Kubernetes + MGR / Galera Cluster

在 github 上,可以看到基於 Docker + Kuberetes + PXC 的 demo^[8]. 需要說明的是, 這僅僅是個玩具, 離部署到生產環境還有極大差距.

我們已有計劃實現滿足生產環境的

 

●     Docker + Kubernetes + PXC

●     Docker + Kubernetes + MGC

●     Docker + Kubernetes + MGR

並整合到 QFusion 來支援計算儲存分離架構和本地儲存架構混合部署, 架構示意圖如下 :

 目前原型驗證階段已通過, 預計2018年Q2釋出.

Docker + Kubernetes + Vitess

在 github 上,同樣可以看到基於 Docker + Kubernetes 的 demo^[9]. 有興趣的同學可以玩一下.

效能只是選型需要考量的一部分, 要使用到生產環境或者產品化, 實際要考量的因素更多 :

●     運維 : 部署, 備份

●     彈性 : 計算儲存擴容, 叢集擴容

●     高可用 : 比如 “failover” 的細微差別對業務的影響

●     容錯 : 比如網路對叢集的影響, 尤其是在網路抖動或有明顯延時的情況下

●     社群活躍度

●     …...

以現有軟硬體的開放程度, 各種架構或者產品狹義上的”黑科技”並不多, 常常看到的

xxx 比 xxx 快 xxx 倍

嚴格來說應該是

xxx 比 xxx 在特定場景 xxx 下快 xxx 倍.

並不存在”一槍斃命”的”Silver Bullet”, 只是 Docker + Kubernetes 為混合部署帶來可能. 哪種更受青睞, 拭目以待, 使用者會是最好的老師.

<人月神話>中提到”No Silver Bullet.”, 原意是用來論述軟體工程領域的生產力問題 由於軟體的複雜性本質, 使得真正的銀彈並不存在, 沒有任何一項技術或方法可使軟體工程的生產力在十年內提高十倍.

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/28218939/viewspace-2151448/，如需轉載，請註明出處，否則將追究法律責任。