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

[[252333]]

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

• 使用公共云標準資源彈性，直接用阿里云的標準資源支撐大促后歸還。這個是最直接的想法，但這里的難度是業務需求和云資源在性能、成本上的差距，不要定制化機器。
• 混部能力，存量業務的分類混部、分時混部。使用離線資源支撐大促，既是分類混部，雙11零點離線降級，高峰后在線歸還資源也是分時復用。
• 快上快下，在有能力使用云、離線資源后，盡量縮短占用周期。
• 碎片化資源，數據庫一直是塊石頭，是一個大塊完整的規格。如果把數據庫自己的大庫變成小庫，就可以使用其他業務的碎片化資源，包括公共云上的資源。

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

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

一、混合云彈性，高性能ECS應運而生

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

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

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

二、容器化彈性，提升資源效率

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

• 內存的OOM時有發生
• 存在IO爭搶問題
• 多租戶混部存在主機賬號等安全問題
• 數據庫主備機型一致性

隨著單機部署密度越來越高，社區Docker也開始發展起來，盡管還不成熟，Docker本身依賴Cgroup做資源隔離，解決不了Cgroup的IO爭搶或OOM問題，但它通過資源隔離和namespace隔離的結合，嘗試對資源規格以及部署做新的定義，因此我們看到了容器化更多的優勢：

• 標準化規格，數據庫與機型解耦，主備不需要對稱。這對規模化運維帶來極大的效率。
• Namespace隔離帶來混部能力，資源池統一。
• 不同數據庫類型，不同數據庫版本隨便混。
• 讓DB具備與其他應用類型混部的條件。

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

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

三、計算資源***彈性，存儲計算分離架構升級

實現了容器化混合云，是不是每年大促使用高性能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下半年數據庫開始和盤古團隊一起，做端到端全用戶態的存儲計算分離方案。

四、全用戶態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等團隊，正是大家的支持讓阿里數據庫的基礎架構才能不斷升級，不斷提升效率和成本的競爭力。

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

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