摘要：今天，阿里資深技術(shù)專家天羽為我們講述阿里數(shù)據(jù)庫的極致彈性之路。二容器化彈性，提升資源效率隨著單機(jī)服務(wù)器的能力提升，阿里數(shù)據(jù)庫在年就開始使用單機(jī)多實(shí)例的方案，通過和文件系統(tǒng)目錄端口的部署隔離，支持單機(jī)多實(shí)例，把單機(jī)資源利用起來。

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

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

使用公共云標(biāo)準(zhǔn)資源彈性，直接用阿里云的標(biāo)準(zhǔn)資源支撐大促后歸還。這個是最直接的想法，但這里的難度是業(yè)務(wù)需求和云資源在性能、成本上的差距，不要定制化機(jī)器。

混部能力，存量業(yè)務(wù)的分類混部、分時混部。使用離線資源支撐大促，既是分類混部，雙11零點(diǎn)離線降級，高峰后在線歸還資源也是分時復(fù)用。

快上快下，在有能力使用云、離線資源后，盡量縮短占用周期。

碎片化資源，數(shù)據(jù)庫一直是塊石頭，是一個大塊完整的規(guī)格。如果把數(shù)據(jù)庫自己的大庫變成小庫，就可以使用其他業(yè)務(wù)的碎片化資源，包括公共云上的資源。

大促的成本=持有資源X持有周期，更通用的資源（云）、更快的部署（容器化）是縮短持有周期的關(guān)鍵，如何更少地使用資源（使用離線或只擴(kuò)計算資源），就依賴存儲計算分離架構(gòu)的實(shí)施。沿著極致彈性的目標(biāo)，數(shù)據(jù)庫經(jīng)歷了混合云彈性、容器化彈性、計算存儲分離彈性三個階段，基礎(chǔ)架構(gòu)從高性能ECS混合云、容器化混合云、存儲計算分離的公共云和離線混部一步步升級。

基本上架構(gòu)演進(jìn)就是每年驗(yàn)證一個單元，第二年全網(wǎng)鋪開，每年挖個坑然后和團(tuán)隊(duì)一起努力爬出來，每次演進(jìn)需要跨團(tuán)隊(duì)背靠背緊密合作，快速拿下目標(biāo)，這也是阿里最神奇的力量。借助于底層軟硬件技術(shù)發(fā)展，一步步的架構(gòu)升級使得彈性混部越來越靈活和快速。?

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

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

2016年在集團(tuán)通過了日常驗(yàn)證，2017年大促開始大規(guī)模用云資源直接彈性。這個項(xiàng)目除了打造高性能ECS產(chǎn)品，更重要的是沉淀了網(wǎng)絡(luò)和文件IO的純用戶態(tài)鏈路技術(shù)，這是一個技術(shù)拐點(diǎn)的產(chǎn)生，為阿里后續(xù)存儲計算分離相關(guān)產(chǎn)品的高性能突破打下了基礎(chǔ)。

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

內(nèi)存的OOM時有發(fā)生

存在IO爭搶問題

多租戶混部存在主機(jī)賬號等安全問題

數(shù)據(jù)庫主備機(jī)型一致性

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

標(biāo)準(zhǔn)化規(guī)格，數(shù)據(jù)庫與機(jī)型解耦，主備不需要對稱。這對規(guī)模化運(yùn)維帶來極大的效率。

Namespace隔離帶來混部能力，資源池統(tǒng)一。

不同數(shù)據(jù)庫類型，不同數(shù)據(jù)庫版本隨便混。

讓DB具備與其他應(yīng)用類型混部的條件。

2015年數(shù)據(jù)庫開始驗(yàn)證容器化技術(shù)，2016年在日常環(huán)境中大量使用。因此在集團(tuán)統(tǒng)一調(diào)度的項(xiàng)目啟動后，我們就定下了2016年電商一個交易單元全部容器化支撐大促的目標(biāo)，承載交易大盤約30%，并順利完成。2017年數(shù)據(jù)庫就是全網(wǎng)容器化的目標(biāo)，目前數(shù)據(jù)庫全網(wǎng)容器化比例已經(jīng)接近100%。

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

實(shí)現(xiàn)了容器化混合云，是不是每年大促使用高性能ECS，容器化部署就可以了呢？其實(shí)還是有不足的：

數(shù)據(jù)庫彈性需要搬數(shù)據(jù)，把數(shù)據(jù)搬到ECS上是非常耗時的工作。?

彈性規(guī)模太大，如果超過公有云售賣周期，會增加持有成本。

因此如何做到更快、更通用的彈性能力，是一個新的技術(shù)問題。隨著2016年調(diào)度的發(fā)展，大家考慮機(jī)器是不是應(yīng)該無盤化，是不是應(yīng)該存儲計算分離，從而加快調(diào)度效率，而數(shù)據(jù)庫的存儲計算分離更是爭議很大。

數(shù)據(jù)庫的Share Nothing分布式擴(kuò)展已經(jīng)深入人心，存儲計算分離會不會回到IOE狀態(tài)？如果IDC是一個數(shù)據(jù)中心，應(yīng)用就是計算，DB就是存儲，DB自己再做存儲計算分離有意義嗎？數(shù)據(jù)是主備雙副本的，存儲計算分離后變成三副本，存儲集群的容量池化能balance掉額外副本的成本嗎？

為此我開始測算存儲計算分離架構(gòu)在大促場景下的投入產(chǎn)出，我們來看下大促場景，彈性大促時，業(yè)務(wù)需求計算能力數(shù)倍甚至10倍以上擴(kuò)容，承擔(dān)大促峰值壓力，而磁盤因?yàn)榇鎯﹂L期數(shù)據(jù)，峰值的數(shù)據(jù)量在整體占比不高，因此磁盤容量基本不需要擴(kuò)容。

在以前本地磁盤跑主備的架構(gòu)，無法計算、存儲分開擴(kuò)容，大促指標(biāo)越高，添加標(biāo)準(zhǔn)機(jī)器越多，成本浪費(fèi)越大，因?yàn)榇疟P是標(biāo)準(zhǔn)數(shù)據(jù)庫機(jī)器的主要成本。而存儲計算分離的情況下，測算下來，我們看到在較低日常壓力下存儲計算分離成本是比本地盤高的，但再往上，存儲計算分離只需要增加計算，存儲集群因?yàn)槌鼗螅恢蝗萘砍鼗耍阅芤渤鼗耍魏胃哓?fù)載實(shí)例的IO都是打散到整個集群分擔(dān)的，磁盤吞吐和IOPS復(fù)用，不需擴(kuò)性能，成本優(yōu)勢非常明顯。

磁盤不擴(kuò)容，只擴(kuò)計算自然成本低很多。傳統(tǒng)的思考是存儲集群容量池化的優(yōu)勢，但在大促場景我們更多用到的是性能的池化，突破單機(jī)瓶頸，因此我們提出了電商異地多活所有單元存儲計算分離，其余業(yè)務(wù)繼續(xù)使用本地磁盤進(jìn)行同城容災(zāi)的目標(biāo)架構(gòu)。

提出這個設(shè)想，而這個架構(gòu)的可行性如何判斷？基于一些數(shù)字就可以推斷，大家知道SSD磁盤的讀寫響應(yīng)時間在100-200微秒，而16k的網(wǎng)絡(luò)傳輸在10微秒內(nèi)，因此盡管存儲計算分離增加兩到三次的網(wǎng)絡(luò)交互，加上存儲軟件本身的消耗，整體有機(jī)會做到讀寫延時在 500微秒的范圍內(nèi)。在數(shù)據(jù)庫實(shí)例壓測中我們發(fā)現(xiàn)，隨著并發(fā)增加，存儲集群具備更大的QPS水位上線，這印證了性能池化突破單機(jī)瓶頸帶來的吞吐提升。

數(shù)據(jù)庫團(tuán)隊(duì)在2017年開始驗(yàn)證存儲計算分離，基于25G的TCP網(wǎng)絡(luò)實(shí)現(xiàn)存儲計算分離部署，當(dāng)年就承擔(dān)了10%大促流量。我們基于分布式存儲做到了700微秒的響應(yīng)時間，這里內(nèi)核態(tài)和軟件棧的消耗較大，為此X-DB也針對性地做了慢IO優(yōu)化，特別是日志刷盤的優(yōu)化，開啟原子寫去掉了double write buffer提升吞吐能力。

這個過程中，我們沉淀了存儲的資源調(diào)度系統(tǒng)，目前已經(jīng)作為統(tǒng)一調(diào)度的組件服務(wù)集團(tuán)業(yè)務(wù)。我們對當(dāng)前架構(gòu)性能不太滿意，有了X-DB的慢IO優(yōu)化、存儲計算分離跨網(wǎng)絡(luò)的IO路徑、存儲資源調(diào)度等技術(shù)沉淀，加上阿里巴巴RDMA網(wǎng)絡(luò)架構(gòu)的發(fā)展，2017下半年數(shù)據(jù)庫開始和盤古團(tuán)隊(duì)一起，做端到端全用戶態(tài)的存儲計算分離方案。

從數(shù)據(jù)庫軟件X-DB的IO調(diào)用開始，就走我們自己研發(fā)的用戶態(tài)文件系統(tǒng)DBFS，DBFS使用盤古的用戶態(tài)客戶端，直接通過RDMA網(wǎng)絡(luò)訪問后端盤古分布式文件系統(tǒng)，整個IO鏈路完全繞過了內(nèi)核棧。這里DBFS繞過了內(nèi)核文件系統(tǒng)，自然也繞過了pagecache，為此DBFS針對數(shù)據(jù)庫場景，實(shí)現(xiàn)了更簡潔高效的BufferIO機(jī)制。

因?yàn)镮O都是跨網(wǎng)絡(luò)遠(yuǎn)程訪問，因此RDMA起到了重要作用，以下是RDMA與TCP網(wǎng)絡(luò)在不同包大小下的延時對比，除了延時優(yōu)勢外，RDMA對長尾IO的tail latency能夠有效控制，對一個數(shù)據(jù)庫請求涉及多次IO來說，對用戶請求的響應(yīng)時間能夠更有效保證。RDMA技術(shù)的應(yīng)用是DB大規(guī)模存儲計算分離的前提條件，通過我們的數(shù)據(jù)實(shí)測，DBFS+RDMA鏈路的延時已經(jīng)和Ext4+本地盤達(dá)到相同水平。

今年我們首次大規(guī)模部署RDMA，如履薄冰。經(jīng)過多次壓測、演練， RDMA配套監(jiān)控和運(yùn)維體系建設(shè)已經(jīng)完善起來，我們能夠在1分鐘內(nèi)識別服務(wù)器網(wǎng)卡或交換機(jī)的網(wǎng)絡(luò)端口故障觸發(fā)告警，能夠故障快速隔離，支持業(yè)務(wù)流量快速切走，支持集群或單機(jī)的網(wǎng)絡(luò)RDMA向TCP降級切換等等。在我們的切流演練中，從DBFS看到RDMA鏈路的寫延時比TCP降低了一倍。我們在全鏈路壓測中，基于RDMA技術(shù)保障了在單個數(shù)據(jù)庫實(shí)例接近2GB吞吐下磁盤響應(yīng)時間穩(wěn)定在500微秒左右，沒有毛刺。

盤古分布式存儲為了同時支持RDMA、EC壓縮、快照等功能，做了大量的設(shè)計優(yōu)化，尤其對寫IO做了大量優(yōu)化，當(dāng)然也包括RDMA/TCP切流，故障隔離等穩(wěn)定性方面的工作。作為阿里的存儲底盤，其在線服務(wù)規(guī)模已經(jīng)非常龐大。

整個技術(shù)鏈路講清楚之后，說一下我們在規(guī)模應(yīng)用中遇到的難題，首先，容器的網(wǎng)絡(luò)虛擬化Bridge和RDMA天然不兼容，由于容器走Bridge網(wǎng)絡(luò)模式分配IP，而這個是走內(nèi)核的。為了應(yīng)用RDMA，我們必須使用Host網(wǎng)絡(luò)模式進(jìn)行容器化，走Host + X-DB + DBFS + RDMA +盤古存儲這樣的全用戶態(tài)鏈路。

其次，對于公有云環(huán)境，我們通過VPC打通形成混合云環(huán)境，因此應(yīng)用通過VPC訪問數(shù)據(jù)庫，而數(shù)據(jù)庫使用物理IP用于RDMA訪問盤古以及X-DB內(nèi)部X-Paxos。這個方案復(fù)雜而有效，得益于DBPaaS管控的快速迭代和容器化資源調(diào)度的靈活性，這些新技術(shù)能夠快速落地，在變化中穩(wěn)步推進(jìn)。

今年年初，我們定下了2018大促的支撐形態(tài)，即異地多活的中心機(jī)房將計算彈性到大數(shù)據(jù)的離線資源，單元機(jī)房將計算彈性到公共云資源，不搬數(shù)據(jù)直接彈性擴(kuò)容，快上快下的大促目標(biāo)。今年DB全局一盤棋，完成了資源調(diào)整，實(shí)現(xiàn)了電商各站點(diǎn)的存儲計算分離架構(gòu)升級，并通過X-DB異地多副本架構(gòu)靈活部署，實(shí)現(xiàn)了彈性大促目標(biāo)。

基于底層盤古分布式的共享存儲，彈性不需要遷移數(shù)據(jù)，只需要掛載磁盤，數(shù)據(jù)庫可以像應(yīng)用一樣快速彈性，做到一個集群10分鐘完成彈性擴(kuò)容。同時在全鏈路壓測過程中，對出現(xiàn)性能瓶頸的業(yè)務(wù)，我們可以邊壓邊彈，快速彈到更大的規(guī)格上。基于快速彈性的能力，今年DB所有站點(diǎn)的大促擴(kuò)容都在三天內(nèi)完成，這在以前是不可能實(shí)現(xiàn)的，這就是存計分離的架構(gòu)帶來的效率。

最后，感謝阿里內(nèi)部通力合作的盤古、網(wǎng)絡(luò)、調(diào)度、IDC等團(tuán)隊(duì)，正是大家的支持讓阿里數(shù)據(jù)庫的基礎(chǔ)架構(gòu)才能不斷升級，不斷提升效率和成本的競爭力。

數(shù)據(jù)庫存儲計算分離的架構(gòu)升級，大大節(jié)約了大促資源成本。目前我們的彈性能力正在日常化，通過數(shù)據(jù)預(yù)測，自動觸發(fā)彈性擴(kuò)容，我們的目標(biāo)是讓單機(jī)容量問題導(dǎo)致故障成為歷史。?

接下來我們平臺將向智能化發(fā)展，對于數(shù)據(jù)庫來說，只有基礎(chǔ)架構(gòu)足夠強(qiáng)大，足夠快速，靈活，彈性，智能化才能有效發(fā)揮。

閱讀原文

本文來自云棲社區(qū)合作伙伴“阿里技術(shù)”，如需轉(zhuǎn)載請聯(lián)系原作者。