容器化RDS：計算儲存分離還是本地儲存？-知識星球

隨著交流機會的增多（集中在金融行業，規模都在各自領域數一數二），發現大家對 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（簡稱 MGR）[1]，類似 Galera Cluster：

基於Corosync實現（Totem協議），外掛式安裝，MySQL 官方原生外掛。
叢集架構，支援多寫（建議單寫）
允許少數節點故障，同步延遲較小，保證強一致，資料零丟失
單位時間的交易量受 flow control 影響。

這裡還需要提一下 Vitess：

該專案由 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 官方[2]

測試結果：

在設定 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 複製層效能[3]。
負載模型：依然使用 OLTP Read/Write (RW)
durability：sync_binlog=1
non-durability：sync_binlog=0

測試資料：

設定 durability，資料來自於 Percona[3]

設定 non-durability，資料來自於 Percona[3]

測試結果：

在負載模型相同的情況下（durability 和 non-durability）PXC 5.7.17-29.20 效能與 MGR 5.7.17 不分伯仲。如果使用 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[4]。需要說明的是，這僅僅是個玩具，離部署到生產環境還有極大差距。

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

Docker + Kubernetes + PXC
Docker + Kubernetes + MGC
Docker + Kubernetes + MGR

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

目前原型驗證階段已透過，預計2018年Q2釋出。

Docker + Kubernetes + Vitess

在 GitHub 上，同樣可以看到基於 Docker + Kubernetes 的 demo[5]，有興趣的同學可以玩一下。

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

運維：部署、備份
彈性：計算儲存擴容，叢集擴容
高可用：比如 “failover” 的細微差別對業務的影響
容錯：比如網路對叢集的影響，尤其是在網路抖動或有明顯延時的情況下
社群活躍度
……

以現有軟硬體的開放程度，各種架構或者產品狹義上的“黑科技”並不多，常常看到的：『xxx 比 xxx 快 xxx 倍』嚴格來說應該是『xxx 比 xxx 在特定場景 xxx 下快 xxx 倍』。

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

《人月神話》中提到“No Silver Bullet”，原意是用來論述軟體工程領域的生產力問題。

由於軟體的複雜性本質，使得真正的銀彈並不存在，沒有任何一項技術或方法可使軟體工程的生產力在十年內提高十倍。

相關連結：

https://dev.mysql.com/doc/refman/5.7/en/group-replication-background.html
http://mysqlhighavailability.com/performance-evaluation-mysql-5-7-group-replication/
https://www.percona.com/blog/2017/04/19/performance-improvements-percona-xtradb-cluster-5-7-17/
https://github.com/kubernetes/kubernetes/tree/master/examples/storage/mysql-galera
https://github.com/kubernetes/kubernetes/tree/master/examples/storage/vitess

Kubernetes 實戰培訓

本次培訓內容包括：Docker容器的原理與基本操作；容器網路與儲存解析；Kubernetes的架構與設計理念詳解；Kubernetes的資源物件使用說明；Kubernetes 中的開放介面CRI、CNI、CSI解析；Kubernetes監控、網路、日誌管理；容器應用的開發流程詳解等，點選識別下方二維碼加微信好友瞭解具體培訓內容。

3月23日開始上課，點選閱讀原文連結即可報名。

容器化RDS：計算儲存分離還是本地儲存？

相關推薦

熱門標籤

熱門文章

分享創造快樂