阿里資料庫的極致彈性之路

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

除了日常業務需求，阿里的雙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等團隊，正是大家的支援讓阿里資料庫的基礎架構才能不斷升級，不斷提升效率和成本的競爭力。

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

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

原文釋出時間為：2018-12-07
本文作者： 天羽
本文來自雲棲社群合作伙伴“ 4GwFU7W4A" target="_blank" rel="nofollow,noindex">阿里技術 ”，瞭解相關資訊可以關注“ 阿里技術 ”。