阿里如何將「高峯前擴容、高峯後縮容」的夢想照進現實？

1、2017年咱們作了什麼？

記得早在2017年的時候，王堅博士就曾召你們就關於「IDC As a Computer」是否能作到，進行過激烈的討論。而要作到此，必需要實現存儲計算分離，分離後由調度對計算和存儲資源進行獨立自由調度。而在實現存儲計算分離的全部業務中，數據庫是最難的。由於數據庫對I/O的時延和穩定性有着極高的要求。可是從業界來看，存儲計算分離又是一個將來的技術趨勢，由於像Google spanner以及Aurora都已經實現了。

因此2017年，咱們抱着堅決的信念，去實現數據庫的存儲計算分離。事實上，2017年咱們作到了，基於盤古和AliDFS(ceph分支) ，在張北單元存儲計算分離承擔10%的交易量。2017年是數據庫實現存儲計算分離的元年，爲2018年大規模實現存儲計算分離打下了堅實的基礎。

2、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最終完成艱鉅的任務經過大促全鏈路的考驗以及雙「十一」大考，再次驗證了存儲計算分離的可行性和總體技術趨勢。

3、存儲中臺利器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(constcharpath,constchar*mode);

FILE fdopen(int fildes,constcharmode);

size_t fread(voidptr, size_t size, size_t nmemb, FILE stream);

size_t fwrite(constvoidptr, 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的分層存儲策略，打通了讀寫路徑，咱們期待下一步更加深刻的智能化存儲研發。

4、總結與展望

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

在支持業務的同時，DBFS自己已經拉通了PG進程與MySQL線程架構的支持，打通了VFS接口，作到了與Linux生態的兼容，成爲真正意義上的存儲中臺級產品——集羣用戶態文件系統。將來結合更多的軟硬件結合、分層存儲、NVMeoF等技術賦能更多的數據庫，實現其更大的價值。