容器化 RDS｜計算存儲分離架構下的 IO 優化

導語：在基於 Kubernetes 和 Docker 構建的私有 RDS 中，普遍採用了計算存儲分離架構。該架構優勢明顯，但對於資料庫類 Latency Sensitive 應用而言， IO 性能問題無法迴避，下面分享一下我們針對 MySQL 做的優化以及優化后的收益。

計算機存儲分離架構

架構示意圖如下：

存儲層由分散式文件系統組成， 以 Provisoner 的方式集成到 Kubernetes。

在我們看來, 計算存儲分離的最大優勢在於：

  • 將有狀態的數據下沉到存儲層，這使得 RDS 在調度時, 無需感知計算節點的存儲介質；

  • 只需調度到滿足計算資源要求的 Node；

  • 資料庫實例啟動時，只需在分散式文件系統掛載 mapping 的 volume 即可；

    Advertisements

  • 可以顯著地提高資料庫實例的部署密度和計算資源利用率。

其他的好處還有很多，譬如架構更清晰、擴展更方便、問題定位更簡單等，這裡不贅述。

計算機存儲分離架構的缺點

俗話說的好：「上帝為你關上一扇窗的同時，再關上一扇門。」

相較本地存儲, 網路開銷會成為 IO 開銷的一部分。我們認為會帶來兩個很明顯的問題：

  • 資料庫是 Latency Sensitive 型應用，網路延時會極大影響資料庫能力 (QPS,TPS)；

  • 在高密度部署的場景，網路帶寬會成為瓶頸，可能導致計算 & 存儲資源利用不充分。

其實還有一個極其重要的問題：由於 Kubernetes 本身沒有提供 Voting 服務和類似 Oracle Rac 的 Fence 機制。在計算存儲分離架構下，當集群發生腦裂，並觸發 Node Controller 和 Kubelet 的驅逐機制時，可能會出現多個資料庫實例同時訪問一份數據文件導致 Data Corruption 的情況。數據的損失對用戶而言是不可估量也不可忍受的。

Advertisements

我們在 Kubernetes 1.7.8 下使用 Oracle , MySQL 都可以 100% 復現這個場景，通過在 Kubernetes 上添加 Fence 機制，我們已解決該問題。如果大家有興趣，會再做專門的分享。

MySQL-IO 優化

1.DoubleWrite

在 MySQL 中，我們首先想到了 DoubleWrite。首先看下官方解釋，它是幹什麼的 ：

簡單說 DoubleWrite 的實現，是防止數據頁寫入時發生故障導致頁損壞 (partialwrite)，所以每次寫數據文件時，都要將一份數據寫到共享表空間中。當啟動時發現數據頁 Checkum 校驗不正確時，會使用共享表空間中副本進行恢復，從 DoubleWrite 實現來看這部分會產生一定量的 IO。所以，最好的優化就是減少 IO，在底層存儲介質或文件系統支持 Atomic Write 的前提下，可以關閉 MySQL 的 DoubleWrite 以減少 IO。

2.單機架構：關閉 DoubleWrite

MariaDB 已支持該功能(底層存儲介質需支持 Atomic Write )，並在單機環境做了相關測試。數據如下 :

結論就是：單機環境下，啟用 Atomic Write (關閉 DoubleWrite )能立即帶來 30% 左右的寫性能改善。

原文地址 : http://blog.mariadb.org/mariadb-introduces-atomic-writes/

3.計算機存儲分離架構：關閉 DoubleWrite

所以，重點是我們需要測試一下在計算存儲分離架構下(分散式存儲必須支持 Atomic Write )，關閉 DoubleWrite Buffer 的收益。

測試場景

  • 採用 Sysbench 模擬 OLTP 負載模型 (跟 MariaDB 相同)

  • 資料庫版本選擇了更流行的 MySQL 5.7.19 (測試時的最新版本)

  • 由本地存儲改為分散式文件系統

  • 測試數據量,數據文件大寫

  • 10GB

  • 100GB

測試結果：10GB 數據量

Sysbench 指標

分散式文件系統指標

在計算存儲分離架構下，啟用 Atomic Write (關閉 DoubleWrite ) 10GB 數據量，因為大部分數據已經緩存到資料庫 buffer cache 中，所以在 IO 不是瓶頸的情況下:

  • Sysbench 指標，提升不明顯

  • TPS ↑0.2656%，

  • QPS ↑0.2797%，

  • RST ↑14.9651%

  • 分散式文件系統指標

  • Throughput 下降 53%, 顯著優化了網路帶寬

測試結果：100GB 數據量

Sysbench 指標

分散式文件系統指標：

在計算存儲分離架構下，啟用 Atomic Write (關閉 DoubleWrite ) 100GB 數據量，因為大部分數據無法緩存到資料庫 buffer cache 中， 所以在 IO 是瓶頸的情況下:

  • Sysbench指標，提升明顯

  • TPS↑28.0892%，

  • QPS ↑28.0893%，

  • RST↓169.2033%

  • 分散式文件系統指標

  • IOPS 提升 22.3%

  • Latency 下降 39%

  • 在 IOPS 提升 22.3% 的情況下，Throughput 僅多消耗 3.6%

總結

想讓資料庫安全，高效的運行到 Kubernetes 和 Docker 的架構下並不容易。本文分享的只是眾多問題之一，任重而道遠……想在上面持續發力的同學，自求多福吧。

END

Advertisements

你可能會喜歡

Advertisements