乾貨 | 阿里如何將“高峰前擴容、高峰後縮容”的夢想照進現實？

雙11已圓滿落幕，但技術的探索，仍未止步。

“阿里巴巴資料庫技術” 特此推出《贏戰2018雙11——阿里資料庫 & 儲存技術揭祕》系列乾貨文章，為你講述2135億這個超級數字背後的故事，敬請關注！

導讀：面對資料庫例項和儲存規模的不斷增長，大促成本、排程效率等難題，2017年阿里就開始小範圍應用新型技術架構——“儲存計算分離”，以更低成本支撐彈性大促。

2018年，我們實現了全單元規模化部署儲存計算分離。不過在此之前，各個業務都需要根據自身業務特性進行大量優化。資料庫領域更是如此，而且要求更加苛刻，難度更大。阿里巴巴儲存技術事業部高階技術專家呂健將詳細解讀在2018雙11大促中，阿里如何打破儲存與計算之間的技術壁壘，從而實現無需搬動資料即可靈活彈性擴容的技術突破。

一、2017年我們做了什麼？

記得早在2017年的時候，王堅博士就曾號召大家就關於“IDC As a Computer”是否能做到，進行過激烈的討論。而要做到此，必須要實現儲存計算分離，分離後由排程對計算和儲存資源進行獨立自由排程。而在實現儲存計算分離的所有業務中，資料庫是最難的。因為資料庫對I/O的時延和穩定性有著極高的要求。但是從業界來看，儲存計算分離又是一個未來的技術趨勢，因為像Google spanner以及Aurora都已經實現了。  

所以2017年，我們抱著堅定的信念，去實現資料庫的儲存計算分離。事實上，2017年我們做到了，基於盤古和AliDFS(ceph分支) ，在張北單元儲存計算分離承擔10%的交易量。2017年是資料庫實現儲存計算分離的元年，為2018年大規模實現儲存計算分離打下了堅實的基礎。

二、2018技術突破

如果說2017年是資料庫實現儲存計算分離的突破之年的話，那麼2018年就是追求極致效能的一年，也是由試驗走向大規模部署的一年，其技術的挑戰可想而知。在2017年的基礎上，2018年的挑戰更為巨大，需要讓儲存計算分離更加的高效能、普適、通用以及簡單。

2018年，為了使得在儲存計算分離下資料庫的I/O達到最高效能和吞吐，我們自研了使用者態叢集檔案系統DADI DBFS。我們通過將技術沉澱到DADI DBFS使用者態叢集檔案上，賦能集團資料庫交易全單元規模化儲存計算分離。那麼成為儲存中臺級產品，DBFS又做了那些技術上的創新呢？

2.1 使用者態技術

2.1.1 “ZERO” copy

我們直接通過使用者態，旁路kernel，實現I/O路徑的“Zero”copy。避免了核核心外的copy，使得吞吐和效能都有了非常大的提高。

過去使用kernel態時，會有兩次資料copy，一次由業務的使用者態程式copy資料到核內，一次由核內copy到使用者態網路轉發程式。這兩次copy會影響整體吞吐和時延。

切到純使用者態之後，我們使用polling模型進行I/O request請求的傳送。另外對於polling mode下CPU的消耗，我們使用了adaptive sleep技術，使得空閒時，不會浪費core資源。

2.1.2 RDMA

另外，DBFS結合RDMA技術與盤古儲存直接進行資料交換，達到接近於本地SSD的時延和更高的吞吐，從而使得今年跨網路的極低時延I/O成為可能，為大規模儲存計算分離打下了堅強的基礎。今年集團參加大促的RDMA叢集，可以說是在規模上為業界最大的一個叢集。

2.2 Page cache

為了實現buffer I/O的能力，我們單獨實現了page cache。Page cahce採用touch count based LRU演算法實現。引入touch count的意義是為了更好的與資料庫的I/O特性結合。因為資料庫中時常會有大表掃描等行為，我們不希望這種使用頻率低的資料頁沖刷掉LRU的效率。我們會基於touch count將page在hot端和cool端進行移動。

Page cache的頁大小可配置，與資料庫的頁大小進行結合時，會發揮更好的cache效率。總體上DBFS的page cache具備以下的能力：

• 基於touch count進行page的冷熱端遷移

• 冷熱端比例可配置，目前為熱冷比例為2:8

• page size可配置，結合資料庫頁進行最優化配置

• 多shard，提高併發；總體容量可配置

2.3 非同步I/O

為了提高資料庫的I/O吞吐能力，大部分資料庫都使用了非同步I/O。我們為了相容上層資料庫的I/O特性，實現了非同步I/O。非同步I/O特性：

• 無鎖佇列實現

• 可配置的I/O depth，能夠使得針對資料庫不同的I/O型別進行精確時延控制

• polling adaptive，減少CPU消耗

2.4 原子寫

為了保證資料庫頁寫出的時候不出現partial write，DBFS實現了原子寫功能。基於DBFS的Innodb，可以安全的將double write buffer關掉，從而使得在存計分離下資料庫頻寬節省100%。

另外，如PostgreSQL使用的是buffer I/O，也避免了PG在dirty page flush時偶發性遇到的缺頁問題。

2.5 Online Resize

為了避免擴容而帶來的資料遷移，DBFS結合底層盤古實現volume的線上resize。DBFS有自己的bitmap allocator，用於實現底層儲存空間的管理。我們對bitmap allocator進行了優化，在檔案系統層級做到了lock free的resize，使得上層業務可以在任何時候進行對業務無損的高效擴容，完全優於傳統的ext4檔案系統。

Online Resize的支援，避免了儲存空間的浪費，因為不用reserve如20%的儲存空間了，可以做到隨擴隨寫。

以下為擴容時的bitmap變化過程：

2.6 TCP與RDMA互切

RDMA在集團資料庫大規模的引入使用也是一個非常大的風險點，DBFS與盤古一起實現了RDMA與TCP互切的功能，並在全鏈路過程中進行了互換演練，使得RDMA的風險在可控的範圍內，穩定性保障更加完善。

另外，DBFS，盤古以及網路團隊，針對RDMA進行了非常多的容量水位壓測，故障演練等工作，為業界最大規模RDMA上線做了非常充足的準備。

2.7 2018年大促部署

在做到了技術上的突破和攻關後，DBFS最終完成艱鉅的任務通過大促全鏈路的考驗以及雙“十一”大考，再次驗證了儲存計算分離的可行性和整體技術趨勢。

三、儲存中臺利器DBFS

除了以上做為檔案系統必須實現的功能以外，DBFS還實現了諸多的特性，使得業務使用DBFS更加的通用化，更加易用性，更加穩定以及安全。

3.1 技術沉澱與賦能

我們將所有的技術創新和功能以產品的形式沉澱在DBFS中，使得DBFS能夠賦能更多的業務實現以使用者態的形式訪問不同的底層儲存介質，賦能更多資料庫實現儲存計算分離。

3.1.1 POSIX相容

目前為了支撐資料庫業務，我們相容了大多數常用的POSIX檔案介面，以方便上層資料庫業務的對接。另外也實現了page cache，非同步I/O以及原子寫等，為資料庫業務提供豐富的I/O能力。另外，我們也實現了glibc的介面，用於支援檔案流的操作和處理。這兩種介面的支援，大大簡化了資料庫接入的複雜度，增加了DBFS易用性，使得DBFS可以支撐更多的資料庫業務。

posix部分大家比較熟悉就不再列出，以下僅為部分glibc介面供參考：

// glibc interface

FILE *fopen(constchar*path,constchar*mode);

FILE *fdopen(int fildes,constchar*mode);

size_t fread(void*ptr, size_t size, size_t nmemb, FILE *stream);

size_t fwrite(constvoid*ptr, size_t size, size_t nmemb, FILE *stream);

intfflush(FILE *stream);

intfclose(FILE *stream);

intfileno(FILE *stream);

intfeof(FILE *stream);

intferror(FILE *stream);

voidclearerr(FILE *stream);

intfseeko(FILE *stream, off_t offset,int whence);

intfseek(FILE *stream,long offset,int whence);

off_t ftello(FILE *stream);

longftell(FILE *stream);

voidrewind(FILE *stream);

3.1.2 Fuse實現

另外，為了相容Linux生態我們實現了fuse，打通VFS的互動。Fuse的引入使得使用者在不考慮極致效能的情況下，可以不需要任何程式碼改動而接入DBFS，大大提高產品的易用性。另外，也大大方便了傳統的運維操作。

3.1.3 服務化能力

DBFS自研了shmQ元件，基於內享記憶體的IPC通訊，從而拉通了對於PostgreSQL基於程式架構和MySQL基於執行緒架構的支援，使得DBFS更加的通用化和安全，為以後線上升級提供堅實的基礎。

shmQ基於無鎖實現，效能和吞吐表現優異，從目前測試來看，在16K等資料庫大頁下能控制在幾個us以內的訪問時延。服務化以及多程式架構的支援，目前效能與穩定性符合預期。

3.1.4 叢集檔案系統

叢集功能是DBFS的又一大明顯特性，賦能資料庫基於shared-disk模式，實現計算資源的線性擴充套件，為業務節省儲存成本。另外，shared-disk的模式也為資料庫提供了快速的彈效能力，也大大提高了主備快速切換的SLA。叢集檔案系統提供一寫多讀以及多點寫入的能力，為資料庫shared-disk和shared nothing架構打下堅實的基礎。與傳統的OCFS相比，我們在使用者態實現，效能更好，更加自主可控。OCFS嚴重依賴於Linux的VFS，如沒有獨立的page cache等。

DBFS 支援一寫多讀模式時，提供多種角色可選(M/S)，可以存在一個M節點多個S節點使用共享資料，M 節點和S節點共同訪問盤古資料。上層資料庫對M／S節點進行了限制，M節點的資料訪問是可讀可寫的，S節點的資料訪問是隻讀的。如果主庫發生故障，就會進行切換。主從切換步驟：

• 業務監控指標探測發現M 節點出現無法訪問或者異常的時候，進行決策，是否要進行切換。

• 如果發生切換，由管控平臺發起切換命令，切換命令完成，代表DBFS和上層資料庫都已經完成角色切換。

• 在DBFS 切換的過程中，最主要的動作就是IO fence，禁止掉原本的M節點IO能力，防止雙寫情況。

DBFS在多點寫入時，對所有節點進行全域性的metalock控制，blockgroup allocation優化等。另外也會涉及到基於disk的quorum演算法等，內容比較複雜，暫不做詳細陳述。

3.2 軟硬體結合

隨著新儲存介質的出現，資料庫勢必需要借其發揮更好的效能或者更低成本優化，並且做到對底層儲存介質的自主可控。

從Intel對儲存介質的規劃來看，從效能到容量，會形成AEP,Optane和SSD這三種產品，而在向大容量方向上，又會有QLC的出現。所以綜合效能和成本來看，我們覺得Optane是一個比較不錯的cache產品。我們選擇它作為DBFS 機頭持久化filecache的實現。

3.2.1 持久化file cache

DBFS實現了基於Optane的local持久化cache功能，使得在存計分離下更近一步提升資料庫的讀寫效能。File cache為了達到生產可用性，做了非常多的工作，如：

• 穩定可靠的故障處理

• 支援動態enable和disable

• 支援負載均衡

• 支援效能指標採集和展示

• 支援資料正確性scrub

這些功能的支撐，為線上穩定性打下堅實的基礎。其中，針對Optane的I/O為SPDK的純使用者態技術，DBFS結合Fusion Engine的vhost實現。File Cache的頁大小可以根據上層資料庫的block大小進行最佳配置，以達到最好的效果。

以下為file cache的架構圖：

以下是測試所得讀寫效能收益資料：

其中帶有“cache”的為基於filecache所得。整體表現隨著命中率提高，讀時延開始下降。另外，我們針對file cache，進行了諸多效能指標的監控。

3.2.2 Open Channel SSD

X-Engine和DBFS以及Fusion Engine團隊展開合作，基於object SSD進一步打造儲存自主可控的系統。在降低SSD磨損，提高SSD吞吐，降低讀寫相互干擾等領域，進行了深度探索與實踐，都取得了非常不錯的效果。目前已經結合X-Engine的分層儲存策略，打通了讀寫路徑，我們期待下一步更加深入的智慧化儲存研發。

四、總結與展望

2018年DBFS已經大規模支援了X-DB以儲存計算分離形態支援“11.11”大促；與此同時也賦能ADS實現一寫多讀能力以及Tair等。

在支援業務的同時，DBFS本身已經拉通了PG程式與MySQL執行緒架構的支援，打通了VFS介面，做到了與Linux生態的相容，成為真正意義上的儲存中臺級產品——叢集使用者態檔案系統。未來結合更多的軟硬體結合、分層儲存、NVMeoF等技術賦能更多的資料庫，實現其更大的價值。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31562044/viewspace-2286249/，如需轉載，請註明出處，否則將追究法律責任。