阿里數據庫的極致彈性之路

阿里妹導讀：數據庫從IOE（IBM小機、Oracle商業DB、EMC存儲）一路走來，你們都知道數據庫是資源重依賴的軟件，對服務器的三大件CPU、內存、磁盤幾乎都有要求。數據庫做爲普遍使用的數據存儲系統，其SQL請求背後涉及的物理讀、邏輯讀、排序過濾等消耗了IO和CPU資源，業務SQL不一樣，執行計劃不一樣，資源消耗就不一樣，於是不一樣業務對資源規格的需求也不同。正因如此，咱們更須要抽象規格，更好地讓不一樣資源訴求的數據庫實例混跑在相同的物理機上，提高總體利用率。今天，阿里資深技術專家天羽爲咱們講述阿里數據庫的極致彈性之路。

除了平常業務需求，阿里的雙11場景，讓咱們持續思考如何低成本高效率地支持峯值流量，把這些思考變成現實，變成技術競爭力。在大促資源彈性上有這麼幾個思路：

• 使用公共雲標準資源彈性，直接用阿里雲的標準資源支撐大促後歸還。這個是最直接的想法，但這裏的難度是業務需求和雲資源在性能、成本上的差距，不要定製化機器。

• 混部能力，存量業務的分類混部、分時混部。使用離線資源支撐大促，既是分類混部，雙11零點離線降級，高峯後在線歸還資源也是分時複用。

• 快上快下，在有能力使用雲、離線資源後，儘可能縮短佔用週期。

• 碎片化資源，數據庫一直是塊石頭，是一個大塊完整的規格。若是把數據庫本身的大庫變成小庫，就可使用其餘業務的碎片化資源，包括公共雲上的資源。

大促的成本=持有資源X持有周期，更通用的資源（雲）、更快的部署（容器化）是縮短持有周期的關鍵，如何更少地使用資源（使用離線或只擴計算資源），就依賴存儲計算分離架構的實施。沿着極致彈性的目標，數據庫經歷了混合雲彈性、容器化彈性、計算存儲分離彈性三個階段，基礎架構從高性能ECS混合雲、容器化混合雲、存儲計算分離的公共雲和離線混部一步步升級。

基本上架構演進就是每一年驗證一個單元，第二年全網鋪開，每一年挖個坑而後和團隊一塊兒努力爬出來，每次演進須要跨團隊背靠背緊密合做，快速拿下目標，這也是阿里最神奇的力量。藉助於底層軟硬件技術發展，一步步的架構升級使得彈性混部愈來愈靈活和快速。 

1、混合雲彈性，高性能ECS應運而生

2015年以前，咱們的大促彈性叫人肉彈性，也就是大促要搬機器，好比集團用雲的機型支撐大促，大促結束後搬機器歸還給雲。但就在2015年末的一次會議上，李津問可否把數據庫跑到ECS上，若是能夠，就真正幫助了雲產品成熟，當時張瑞和我討論了一下，在會議上就答覆了：咱們決定試一下。這個合做很是契合會議主題「挑戰不可能——集團技術雲計算戰區12月月會召集令」。

對於數據庫跑在虛擬機上，咱們判斷最大的消耗在IO和網絡的虛擬化上，所以如何作到接近本機性能，怎麼穿透虛擬化就是一個問題。網絡的用戶態技術DPDK已經比較成熟，但如何作到足夠高的效率，是否offload到硬件來作計算是個問題。文件系統IO的用戶態鏈路有個Intel的SPDK方案，Intel推出後各大廠商還在驗證中，尚未規模的應用。咱們就在這個時候啓動的這個項目，叫高性能ECS。經過和ECS團隊緊密合做，最終咱們作到了最差場景高性能ECS相比本地盤性能損耗低於10%。

2016年在集團經過了平常驗證，2017年大促開始大規模用雲資源直接彈性。這個項目除了打造高性能ECS產品，更重要的是沉澱了網絡和文件IO的純用戶態鏈路技術，這是一個技術拐點的產生，爲阿里後續存儲計算分離相關產品的高性能突破打下了基礎。

2、容器化彈性，提高資源效率

隨着單機服務器的能力提高，阿里數據庫在2011年就開始使用單機多實例的方案，經過Cgroup和文件系統目錄、端口的部署隔離，支持單機多實例，把單機資源利用起來。但依然存在以下問題：

• 內存的OOM時有發生

• 存在IO爭搶問題

• 多租戶混部存在主機帳號等安全問題

• 數據庫主備機型一致性

隨着單機部署密度愈來愈高，社區Docker也開始發展起來，儘管還不成熟，Docker自己依賴Cgroup作資源隔離，解決不了Cgroup的IO爭搶或OOM問題，但它經過資源隔離和namespace隔離的結合，嘗試對資源規格以及部署作新的定義，所以咱們看到了容器化更多的優點：

• 標準化規格，數據庫與機型解耦，主備不須要對稱。這對規模化運維帶來極大的效率。

• Namespace隔離帶來混部能力，資源池統一。

• 不一樣數據庫類型，不一樣數據庫版本隨便混。

• 讓DB具有與其餘應用類型混部的條件。

2015年數據庫開始驗證容器化技術，2016年在平常環境中大量使用。所以在集團統一調度的項目啓動後，咱們就定下了2016年電商一個交易單元所有容器化支撐大促的目標，承載交易大盤約30%，並順利完成。2017年數據庫就是全網容器化的目標，目前數據庫全網容器化比例已經接近100%。

容器化除了提高部署彈性效率，更重要的是透明底層資源差別，在沒有啓動智能調度（經過自動遷移提高利用率）前，僅僅從容器化帶來的機器複用和多版本混部，就提高了10個點的利用率，資源池的統一和標準部署模板也加快了資源交付效率。容器化完成了底層各類資源的抽象，標準化了規格，而鏡像部署帶來了部署上的便利，基於數據庫PaaS和統一調度層的通力合做，數據庫的彈性變得更加快速靈活，哪裏有資源，哪裏就能跑起數據庫。

 3、計算資源極致彈性，存儲計算分離架構升級

實現了容器化混合雲，是否是每一年大促使用高性能ECS，容器化部署就能夠了呢？其實仍是有不足的：

1. 數據庫彈性須要搬數據，把數據搬到ECS上是很是耗時的工做。 

2. 彈性規模太大，若是超過公有云售賣週期，會增長持有成本。

所以如何作到更快、更通用的彈性能力，是一個新的技術問題。隨着2016年調度的發展，你們考慮機器是否是應該無盤化，是否是應該存儲計算分離，從而加快調度效率，而數據庫的存儲計算分離更是爭議很大。

數據庫的Share Nothing分佈式擴展已經深刻人心，存儲計算分離會不會回到IOE狀態？若是IDC是一個數據中心，應用就是計算，DB就是存儲，DB本身再作存儲計算分離有意義嗎？數據是主備雙副本的，存儲計算分離後變成三副本，存儲集羣的容量池化能balance掉額外副本的成本嗎？

爲此我開始測算存儲計算分離架構在大促場景下的投入產出，咱們來看下大促場景，彈性大促時，業務需求計算能力數倍甚至10倍以上擴容，承擔大促峯值壓力，而磁盤由於存儲長期數據，峯值的數據量在總體佔比不高，所以磁盤容量基本不須要擴容。

在之前本地磁盤跑主備的架構，沒法計算、存儲分開擴容，大促指標越高，添加標準機器越多，成本浪費越大，由於磁盤是標準數據庫機器的主要成本。而存儲計算分離的狀況下，測算下來，咱們看到在較低平常壓力下存儲計算分離成本是比本地盤高的，但再往上，存儲計算分離只須要增長計算，存儲集羣由於池化後，不僅容量池化了，性能也池化了，任何高負載實例的IO都是打散到整個集羣分擔的，磁盤吞吐和IOPS複用，不需擴性能，成本優點很是明顯。

磁盤不擴容，只擴計算天然成本低不少。傳統的思考是存儲集羣容量池化的優點，但在大促場景咱們更多用到的是性能的池化，突破單機瓶頸，所以咱們提出了電商異地多活全部單元存儲計算分離，其他業務繼續使用本地磁盤進行同城容災的目標架構。

提出這個設想，而這個架構的可行性如何判斷？基於一些數字就能夠推斷，你們知道SSD磁盤的讀寫響應時間在100-200微秒，而16k的網絡傳輸在10微秒內，所以儘管存儲計算分離增長兩到三次的網絡交互，加上存儲軟件自己的消耗，總體有機會作到讀寫延時在 500微秒的範圍內。在數據庫實例壓測中咱們發現，隨着併發增長，存儲集羣具有更大的QPS水位上線，這印證了性能池化突破單機瓶頸帶來的吞吐提高。

數據庫團隊在2017年開始驗證存儲計算分離，基於25G的TCP網絡實現存儲計算分離部署，當年就承擔了10%大促流量。咱們基於分佈式存儲作到了700微秒的響應時間，這裏內核態和軟件棧的消耗較大，爲此X-DB也針對性地作了慢IO優化，特別是日誌刷盤的優化，開啓原子寫去掉了double write buffer提高吞吐能力。

這個過程當中，咱們沉澱了存儲的資源調度系統，目前已經做爲統一調度的組件服務集團業務。咱們對當前架構性能不太滿意，有了X-DB的慢IO優化、存儲計算分離跨網絡的IO路徑、存儲資源調度等技術沉澱，加上阿里巴巴RDMA網絡架構的發展，2017下半年數據庫開始和盤古團隊一塊兒，作端到端全用戶態的存儲計算分離方案。

4、全用戶態IO鏈路的存儲計算分離架構落地 

 

從數據庫軟件X-DB的IO調用開始，就走咱們本身研發的用戶態文件系統DBFS，DBFS使用盤古的用戶態客戶端，直接經過RDMA網絡訪問後端盤古分佈式文件系統，整個IO鏈路徹底繞過了內核棧。這裏DBFS繞過了內核文件系統，天然也繞過了pagecache，爲此DBFS針對數據庫場景，實現了更簡潔高效的BufferIO機制。

由於IO都是跨網絡遠程訪問，所以RDMA起到了重要做用，如下是RDMA與TCP網絡在不一樣包大小下的延時對比，除了延時優點外，RDMA對長尾IO的tail latency可以有效控制，對一個數據庫請求涉及屢次IO來講，對用戶請求的響應時間可以更有效保證。RDMA技術的應用是DB大規模存儲計算分離的前提條件，經過咱們的數據實測，DBFS+RDMA鏈路的延時已經和Ext4+本地盤達到相同水平。

今年咱們首次大規模部署RDMA，如履薄冰。通過屢次壓測、演練， RDMA配套監控和運維體系建設已經完善起來，咱們可以在1分鐘內識別服務器網卡或交換機的網絡端口故障觸發告警，可以故障快速隔離，支持業務流量快速切走，支持集羣或單機的網絡RDMA向TCP降級切換等等。在咱們的切流演練中，從DBFS看到RDMA鏈路的寫延時比TCP下降了一倍。咱們在全鏈路壓測中，基於RDMA技術保障了在單個數據庫實例接近2GB吞吐下磁盤響應時間穩定在500微秒左右，沒有毛刺。

盤古分佈式存儲爲了同時支持RDMA、EC壓縮、快照等功能，作了大量的設計優化，尤爲對寫IO作了大量優化，固然也包括RDMA/TCP切流，故障隔離等穩定性方面的工做。做爲阿里的存儲底盤，其在線服務規模已經很是龐大。

整個技術鏈路講清楚以後，說一下咱們在規模應用中遇到的難題，首先，容器的網絡虛擬化Bridge和RDMA自然不兼容，因爲容器走Bridge網絡模式分配IP，而這個是走內核的。爲了應用RDMA，咱們必須使用Host網絡模式進行容器化，走Host + X-DB + DBFS + RDMA +盤古存儲這樣的全用戶態鏈路。

其次，對於公有云環境，咱們經過VPC打通造成混合雲環境，所以應用經過VPC訪問數據庫，而數據庫使用物理IP用於RDMA訪問盤古以及X-DB內部X-Paxos。這個方案複雜而有效，得益於DBPaaS管控的快速迭代和容器化資源調度的靈活性，這些新技術可以快速落地，在變化中穩步推動。

今年年初，咱們定下了2018大促的支撐形態，即異地多活的中心機房將計算彈性到大數據的離線資源，單元機房將計算彈性到公共雲資源，不搬數據直接彈性擴容，快上快下的大促目標。今年DB全局一盤棋，完成了資源調整，實現了電商各站點的存儲計算分離架構升級，並經過X-DB異地多副本架構靈活部署，實現了彈性大促目標。

基於底層盤古分佈式的共享存儲，彈性不須要遷移數據，只須要掛載磁盤，數據庫能夠像應用同樣快速彈性，作到一個集羣10分鐘完成彈性擴容。同時在全鏈路壓測過程當中，對出現性能瓶頸的業務，咱們能夠邊壓邊彈，快速彈到更大的規格上。基於快速彈性的能力，今年DB全部站點的大促擴容都在三天內完成，這在之前是不可能實現的，這就是存計分離的架構帶來的效率。

最後，感謝阿里內部通力合做的盤古、網絡、調度、IDC等團隊，正是你們的支持讓阿里數據庫的基礎架構才能不斷升級，不斷提高效率和成本的競爭力。

數據庫存儲計算分離的架構升級，大大節約了大促資源成本。目前咱們的彈性能力正在平常化，經過數據預測，自動觸發彈性擴容，咱們的目標是讓單機容量問題致使故障成爲歷史。 

接下來咱們平臺將向智能化發展，對於數據庫來講，只有基礎架構足夠強大，足夠快速，靈活，彈性，智能化纔能有效發揮。

原文連接