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

[[252333]]

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

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

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

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

一、混合云彈性，高性能ECS應(yīng)運(yùn)而生

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

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

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

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

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

• 內(nèi)存的OOM時(shí)有發(fā)生
• 存在IO爭(zhēng)搶問(wèn)題
• 多租戶(hù)混部存在主機(jī)賬號(hào)等安全問(wèn)題
• 數(shù)據(jù)庫(kù)主備機(jī)型一致性

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

• 標(biāo)準(zhǔn)化規(guī)格，數(shù)據(jù)庫(kù)與機(jī)型解耦，主備不需要對(duì)稱(chēng)。這對(duì)規(guī)?；\(yùn)維帶來(lái)極大的效率。
• Namespace隔離帶來(lái)混部能力，資源池統(tǒng)一。
• 不同數(shù)據(jù)庫(kù)類(lèi)型，不同數(shù)據(jù)庫(kù)版本隨便混。
• 讓DB具備與其他應(yīng)用類(lèi)型混部的條件。

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

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

三、計(jì)算資源***彈性，存儲(chǔ)計(jì)算分離架構(gòu)升級(jí)

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

1. 數(shù)據(jù)庫(kù)彈性需要搬數(shù)據(jù)，把數(shù)據(jù)搬到ECS上是非常耗時(shí)的工作。
2. 彈性規(guī)模太大，如果超過(guò)公有云售賣(mài)周期，會(huì)增加持有成本。

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

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

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

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

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

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

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

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

四、全用戶(hù)態(tài)IO鏈路的存儲(chǔ)計(jì)算分離架構(gòu)落地

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

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

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

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

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

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

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

基于底層盤(pán)古分布式的共享存儲(chǔ)，彈性不需要遷移數(shù)據(jù)，只需要掛載磁盤(pán)，數(shù)據(jù)庫(kù)可以像應(yīng)用一樣快速?gòu)椥裕龅揭粋€(gè)集群10分鐘完成彈性擴(kuò)容。同時(shí)在全鏈路壓測(cè)過(guò)程中，對(duì)出現(xiàn)性能瓶頸的業(yè)務(wù)，我們可以邊壓邊彈，快速?gòu)椀礁蟮囊?guī)格上?；诳焖?gòu)椥缘哪芰?，今年DB所有站點(diǎn)的大促擴(kuò)容都在三天內(nèi)完成，這在以前是不可能實(shí)現(xiàn)的，這就是存計(jì)分離的架構(gòu)帶來(lái)的效率。

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

數(shù)據(jù)庫(kù)存儲(chǔ)計(jì)算分離的架構(gòu)升級(jí)，大大節(jié)約了大促資源成本。目前我們的彈性能力正在日?；ㄟ^(guò)數(shù)據(jù)預(yù)測(cè)，自動(dòng)觸發(fā)彈性擴(kuò)容，我們的目標(biāo)是讓單機(jī)容量問(wèn)題導(dǎo)致故障成為歷史。

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