摘要:離在線混布計(jì)算存儲(chǔ)分離后,離在線混布成為可能今年完成數(shù)據(jù)庫(kù)離在線混布,為年大促節(jié)省了計(jì)算資源成本。展望目前我們正在進(jìn)行軟硬件結(jié)合,以及上層數(shù)據(jù)庫(kù)引擎與分布式存儲(chǔ)融合優(yōu)化,性能將會(huì)超出傳統(tǒng)本地盤(pán)的性能。
摘要: 隨著阿里集團(tuán)電商、物流、大文娛等業(yè)務(wù)的蓬勃發(fā)展,數(shù)據(jù)庫(kù)實(shí)例以及數(shù)據(jù)存儲(chǔ)規(guī)模不斷增長(zhǎng),在傳統(tǒng)基于單機(jī)的運(yùn)維以及管理模式下,遇到諸多如成本,調(diào)度效率等問(wèn)題,因此,2017年首次對(duì)數(shù)據(jù)庫(kù)實(shí)現(xiàn)計(jì)算存儲(chǔ)分離,計(jì)算存儲(chǔ)分離后,再將計(jì)算節(jié)點(diǎn)與離線資源混布,達(dá)到節(jié)省大促成本的目的。
作者:呂建樞(呂健)
背景
隨著阿里集團(tuán)電商、物流、大文娛等業(yè)務(wù)的蓬勃發(fā)展,數(shù)據(jù)庫(kù)實(shí)例以及數(shù)據(jù)存儲(chǔ)規(guī)模不斷增長(zhǎng),在傳統(tǒng)基于單機(jī)的運(yùn)維以及管理模式下,遇到非常多的困難與挑戰(zhàn),主要?dú)w結(jié)為:
機(jī)型采購(gòu)與預(yù)算問(wèn)題
在單機(jī)模式下計(jì)算資源(CPU和內(nèi)存)與存儲(chǔ)資源(主要為磁盤(pán)或者SSD)存在著不可調(diào)和的沖突;計(jì)算與存儲(chǔ)資源綁定緊密,無(wú)法進(jìn)行多帶帶預(yù)算。數(shù)據(jù)庫(kù)存儲(chǔ)時(shí),要么計(jì)算資源達(dá)到瓶頸,要么是存儲(chǔ)單機(jī)存儲(chǔ)容量不足。這種綁定模式下,注定了有一種資源必須是浪費(fèi)的。
調(diào)度效率問(wèn)題
在計(jì)算與存儲(chǔ)綁定的情況下,計(jì)算資源無(wú)法做無(wú)狀態(tài)調(diào)度,導(dǎo)致無(wú)法實(shí)現(xiàn)大規(guī)模低成本調(diào)度,也就無(wú)法與在大促與離線資源進(jìn)行混布。
大促成本問(wèn)題
在計(jì)算資源無(wú)法做到調(diào)度后,離線混布就不再可能;為了大促需要采購(gòu)更多的機(jī)器,大促成本上漲嚴(yán)重。
因此,為了解決諸多如成本,調(diào)度效率等問(wèn)題,2017年首次對(duì)數(shù)據(jù)庫(kù)實(shí)現(xiàn)計(jì)算存儲(chǔ)分離;計(jì)算存儲(chǔ)分離后,再將計(jì)算節(jié)點(diǎn)與離線資源混布,達(dá)到節(jié)省大促成本的目的。
2017年數(shù)據(jù)庫(kù)計(jì)算存儲(chǔ)分離,
使得數(shù)據(jù)庫(kù)進(jìn)行大規(guī)模無(wú)狀態(tài)化容器調(diào)度成為可能!
使得數(shù)據(jù)庫(kù)與離線業(yè)務(wù)混布成為可能!
使得低成本支持大促?gòu)椥猿蔀榭赡埽?/strong>
在高吞吐下,總存儲(chǔ)集群整體RT表現(xiàn)平穩(wěn),與離線資源聯(lián)合首次發(fā)力,完成2017年“11.11”大促的交易支撐。
計(jì)算存儲(chǔ)分離
在所有業(yè)務(wù)中,數(shù)據(jù)庫(kù)的計(jì)算存儲(chǔ)分離最難,這是大家公認(rèn)的。因?yàn)閿?shù)據(jù)庫(kù)對(duì)于存儲(chǔ)的穩(wěn)定性以及單路端到端的時(shí)延有著極致的要求:
存儲(chǔ)穩(wěn)定性
在分布式存儲(chǔ)的穩(wěn)定性方面,我們做了非常多的有意探索,并且逐一落地。這些新技術(shù)的落地,使得數(shù)據(jù)庫(kù)計(jì)算存儲(chǔ)分離成為可能:
單機(jī)failover
單機(jī)failover我們做到業(yè)界的極致,5s內(nèi)完成fo,對(duì)整體集群的影響在4%以內(nèi)(以集群規(guī)模24臺(tái)為例,集群機(jī)器越多,影響越小)。另外,我們對(duì)分布式存儲(chǔ)的狀態(tài)機(jī)進(jìn)行加速優(yōu)化,使得基于paxos的選舉在秒級(jí)內(nèi)進(jìn)行集群視圖更新推送。
長(zhǎng)尾時(shí)延優(yōu)化
計(jì)算存儲(chǔ)分離后,所有的IO都變成了網(wǎng)絡(luò)IO,因此對(duì)于單路IO時(shí)延影響的因素非常多,如網(wǎng)絡(luò)抖動(dòng),慢盤(pán),負(fù)載等,而這些因素也是不可避免的。我們?cè)O(shè)計(jì)了“副本達(dá)成多數(shù)寫(xiě)入即返回的策略(commit majority feature)”,能夠有效地使長(zhǎng)尾時(shí)延抖動(dòng)做到合理的控制,以滿足業(yè)務(wù)的需求。
以下是commit majority feature開(kāi)起前后的效果對(duì)比。其中“藍(lán)色”為優(yōu)化后的長(zhǎng)尾時(shí)延,“紅色”為優(yōu)化前長(zhǎng)尾時(shí)延,效果非常顯著。
流控
我們實(shí)現(xiàn)了基于滑動(dòng)窗口的流控功能,使得集群后臺(tái)活動(dòng)(如backfill和recovery)能根據(jù)當(dāng)前的業(yè)務(wù)流量進(jìn)行自適配的調(diào)整,在業(yè)務(wù)與后臺(tái)數(shù)據(jù)恢復(fù)之間做到最佳平衡。
一般如果集群后端活動(dòng)太低,會(huì)影響數(shù)據(jù)恢復(fù),這會(huì)提高多盤(pán)故障的概率,降低了數(shù)據(jù)的可靠性。我們經(jīng)過(guò)優(yōu)化后,通過(guò)滑動(dòng)窗口機(jī)制,做到了前后端數(shù)據(jù)寫(xiě)入的速動(dòng),在不影響業(yè)務(wù)寫(xiě)入的情況下,盡最大可能提高數(shù)據(jù)恢復(fù)速度,保證多副本數(shù)據(jù)的完整性。
提高數(shù)據(jù)重平衡的速度,也是為了保證整個(gè)集群的性能。因?yàn)橐怀霈F(xiàn)數(shù)據(jù)傾斜時(shí),部分盤(pán)的負(fù)載將變大,從而會(huì)影響整個(gè)集群的時(shí)延和吞吐。
流控效果如下:
高可用部署
在高可用部署上,我們引入的故障域的概念。多個(gè)數(shù)據(jù)副本存儲(chǔ)在多個(gè)故障域,分布到至少4個(gè)RACK以上的機(jī)架上,用于保障底層機(jī)柜電源以及網(wǎng)絡(luò)交換設(shè)備引起的故障等。
為了能夠更好的理解數(shù)據(jù)副本存儲(chǔ)位置(data locality),需要知道數(shù)據(jù)散射度(scatter width)的概念。怎么來(lái)理解數(shù)據(jù)散射度?
舉個(gè)例子:我們定義三個(gè)copy set(存放的都是不同的數(shù)據(jù)):{1,2,3},{4,5,6},{7,8,9}。任意一組copy set中存放的數(shù)據(jù)沒(méi)有重復(fù),也就是說(shuō)一份數(shù)據(jù)的三個(gè)副本分別放置在:{1,4,7}或者{2,5,8}或者{3,6,9}。那么這個(gè)時(shí)候,其數(shù)據(jù)散射度遠(yuǎn)小于隨機(jī)組合的C(9,3)。
隨機(jī)組合時(shí),任意3臺(tái)機(jī)器Down機(jī)都會(huì)存在數(shù)據(jù)丟失。而采用此方案后,只有當(dāng){1,4,7}或者{2,5,8}或者{3,6,9}其中的任意一個(gè)組合不可用時(shí),才會(huì)影響高可用性,才會(huì)有數(shù)據(jù)丟失。
綜上可知,我們引入copy set的目標(biāo)就是盡量的降低數(shù)據(jù)散射度“S”。下圖中兩組replica set,其中每一組的三個(gè)副本分別放置到不同的RACK中。
我們的優(yōu)化還有很多,這里不再一一列舉。
數(shù)據(jù)庫(kù)吞吐優(yōu)化
當(dāng)所有的IO都變成網(wǎng)絡(luò)IO后,我們要做的就是如何減少單路IO的延遲,當(dāng)然這個(gè)是分布式存儲(chǔ)以及網(wǎng)絡(luò)要解的問(wèn)題。
分布式存儲(chǔ)需要優(yōu)化自身的軟件stack以及底層SPDK的結(jié)合等。
而網(wǎng)絡(luò)層則需要更高帶寬以及低時(shí)延技術(shù),如25G TCP或者25G RDMA,或者100G等更高帶寬的網(wǎng)絡(luò)等。
但是我們可以從另外一個(gè)角度來(lái)考慮問(wèn)題,如何在時(shí)延一定的情況下,提高并發(fā)量,從而來(lái)提高吞吐。或者說(shuō)在關(guān)鍵路徑上減少I(mǎi)O調(diào)用的次數(shù),從而從某種程度上提高系統(tǒng)的吞吐。
大家知道,影響數(shù)據(jù)庫(kù)事務(wù)數(shù)的最關(guān)鍵因素就是事務(wù)commit的速度,commit的速度依賴于寫(xiě)REDO時(shí)的IO吞吐。所謂的REDO也就是大家熟知的WAL(Write Ahead Log)日志。
在臟數(shù)據(jù)flush回存儲(chǔ)時(shí),日志必須先落地,這是因?yàn)閿?shù)據(jù)庫(kù)的Crash Recovery是重度以來(lái)于此的。在recovery階段,數(shù)據(jù)庫(kù)先利用redo進(jìn)行roll forward,再利用undo進(jìn)行roll backward,最后再撤銷(xiāo)用戶未提交的事務(wù)。
因此,存儲(chǔ)計(jì)算分離下,要想在單路IO時(shí)延一定時(shí)提高吞吐,就必須要優(yōu)化commit提交時(shí)的效率。我們通過(guò)優(yōu)化redo的寫(xiě)入方式,讓整個(gè)提高吞吐100%左右。另外,也可以優(yōu)化redo group commit的大小,結(jié)合底層存儲(chǔ)stripe能力,做并發(fā)與吞吐優(yōu)化。
數(shù)據(jù)庫(kù)原子寫(xiě)
在數(shù)據(jù)庫(kù)內(nèi)存模型中,數(shù)據(jù)頁(yè)通常是以16K做為一個(gè)bufferpage來(lái)管理的。當(dāng)內(nèi)核修改完數(shù)據(jù)之后,會(huì)有專(zhuān)門(mén)的“checkpoint”線程按一定的頻率將Dirty Page flush到磁盤(pán)上。我們知道,通常os的page cache是4K,而一般的文件系統(tǒng)block size也是4K。所以一個(gè)16k和page會(huì)被分成4個(gè)4k的os filesystem block size來(lái)存儲(chǔ),物理上不能保證連續(xù)性。
那么會(huì)帶來(lái)一個(gè)嚴(yán)重的問(wèn)題,就是當(dāng)fsync語(yǔ)義發(fā)出時(shí),一個(gè)16k的pageflush,只完成其中的8k,而這個(gè)時(shí)候client端crash,不再會(huì)有重試;那么整個(gè)fsync就只寫(xiě)了一半,fsync語(yǔ)義被破壞,數(shù)據(jù)不完整。上面的這個(gè)場(chǎng)景,我們稱之為“partial write”。
對(duì)于MySQL而言,在本地存儲(chǔ)時(shí),使用Double Write Buffer問(wèn)題不大。但是如果底層變成網(wǎng)絡(luò)IO,IO時(shí)延變高時(shí),會(huì)使MySQL的整體吞吐下降,而Double Write Buffer會(huì)加重這個(gè)影響。
我們實(shí)現(xiàn)了原子寫(xiě),關(guān)閉掉Double Write Buffer,從而在高并發(fā)壓力及高網(wǎng)絡(luò)IO時(shí)延下,讓吞吐至少提高50%以上。
網(wǎng)絡(luò)架構(gòu)升級(jí)
分布式存儲(chǔ),對(duì)于網(wǎng)絡(luò)的帶寬要求極高,我們引入了25G網(wǎng)絡(luò)。高帶寬能更好的支持阿里集團(tuán)的大促業(yè)務(wù)。另外,對(duì)于存儲(chǔ)集群后臺(tái)的活動(dòng),如數(shù)據(jù)重平衡以及恢復(fù)都提供了有力的保障。
離在線混布
計(jì)算存儲(chǔ)分離后,離在線混布成為可能;今年完成數(shù)據(jù)庫(kù)離在線混布,為2017年大促節(jié)省了計(jì)算資源成本。
在與離線混布的方案中,我們對(duì)數(shù)據(jù)庫(kù)與離線任務(wù)混跑的場(chǎng)景進(jìn)行了大量的測(cè)試。
實(shí)踐證明,數(shù)據(jù)庫(kù)對(duì)時(shí)延極度敏感,所以為了達(dá)到數(shù)據(jù)庫(kù)混布的目的,我們采用了以下的隔離方案:
CPU與內(nèi)存隔離技術(shù)
CPU的L3是被各個(gè)核共享的,如果在一個(gè)socket內(nèi)部進(jìn)行調(diào)度,會(huì)對(duì)數(shù)據(jù)庫(kù)業(yè)務(wù)有抖動(dòng)。因此,在大促場(chǎng)景下,我們會(huì)對(duì)CPU進(jìn)行獨(dú)立socket 綁定,避免L3 cache干擾;另外,內(nèi)存不超賣(mài)。當(dāng)然,大促結(jié)束后,在業(yè)務(wù)平峰時(shí),可以擇機(jī)進(jìn)行調(diào)度和超賣(mài)。
網(wǎng)絡(luò)QOS
我們對(duì)數(shù)據(jù)庫(kù)在線業(yè)務(wù)進(jìn)行網(wǎng)絡(luò)打標(biāo),NetQoS中將數(shù)據(jù)庫(kù)計(jì)算節(jié)點(diǎn)的所有通信組件加入到高優(yōu)先級(jí)group中。
基于分布式存儲(chǔ)的彈性效率
基于分布式存儲(chǔ),底層分布式存儲(chǔ)支持多點(diǎn)mount,用于將計(jì)算節(jié)點(diǎn)快速?gòu)椥缘诫x線機(jī)器。
另外,數(shù)據(jù)庫(kù)Buffer Pool可以進(jìn)行動(dòng)態(tài)擴(kuò)容。大促ODPS任務(wù)撤離,DB實(shí)例Buffer Pool擴(kuò)容;大促結(jié)束后,Buffer Pool回縮到平峰業(yè)務(wù)時(shí)的大小。
雙11大促求證
大促期間,其中一個(gè)庫(kù)吞吐達(dá)到將近3w tps,RT在1ms以內(nèi),基本上與本地相當(dāng),很好的支撐了2017年大促。這就是我們今年所做的諸多技術(shù)創(chuàng)新的結(jié)果。
展望
目前我們正在進(jìn)行軟硬件結(jié)合(RDMA,SPDK)以及上層數(shù)據(jù)庫(kù)引擎與分布式存儲(chǔ)融合優(yōu)化,性能將會(huì)超出傳統(tǒng)SATA SSD本地盤(pán)的性能。
RDMA和SPDK的特點(diǎn)就是kernel pass-by。未來(lái),我們數(shù)據(jù)庫(kù)將引入全用戶態(tài)IO Stack,從計(jì)算節(jié)點(diǎn)到存儲(chǔ)節(jié)點(diǎn)使用用戶態(tài)技術(shù),更能充分滿足集團(tuán)電商業(yè)務(wù)對(duì)高吞吐低時(shí)延的極致要求。
這些網(wǎng)絡(luò)和硬件技術(shù)的發(fā)展,將會(huì)給“云計(jì)算”帶來(lái)更多的可能性,也會(huì)給真正的“云計(jì)算”新的商業(yè)模式帶來(lái)更多憧憬,而我們已經(jīng)在這條陽(yáng)光的大道上。
歡迎有更多的存儲(chǔ)及數(shù)據(jù)庫(kù)內(nèi)核專(zhuān)家一起參與進(jìn)來(lái),一起攜手邁進(jìn)未來(lái)。
【引用】
[1] Copysets:Reducing the Frequency of Data Loss in Cloud Storage
[2] CRUSH: Controlled,Scalable, Decentralized Placement of Replicated Data
點(diǎn)擊查看原文
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://www.ezyhdfw.cn/yun/17649.html
摘要:阿里巴巴資深技術(shù)專(zhuān)家毗盧毗盧,阿里巴巴資深技術(shù)專(zhuān)家,主導(dǎo)設(shè)計(jì)了框架,并基于該框架完成交易平臺(tái)架構(gòu)升級(jí)改造,目前負(fù)責(zé)商品中心,專(zhuān)注電商領(lǐng)域業(yè)務(wù)建模與工程交付相結(jié)合的研究與平臺(tái)推廣。 摘要: 本文是《2017雙11交易系統(tǒng)TMF2.0技術(shù)揭秘》演講整理,主要講解了基于TMF2.0框架改造的交易平臺(tái),通過(guò)業(yè)務(wù)管理域與運(yùn)行域分離、業(yè)務(wù)與業(yè)務(wù)的隔離架構(gòu),大幅度提高了業(yè)務(wù)在可擴(kuò)展性、研發(fā)效率以及可...
摘要:每秒實(shí)時(shí)處理超過(guò)萬(wàn)項(xiàng)監(jiān)控指標(biāo),讓異常無(wú)所遁形。此外,對(duì)于復(fù)雜數(shù)據(jù)庫(kù)故障事后排查故障根源現(xiàn)場(chǎng)還原歷史事件追蹤也迫使我們建設(shè)一個(gè)覆蓋線上所有環(huán)境數(shù)據(jù)庫(kù)實(shí)例事件的監(jiān)控系統(tǒng),做到覆蓋阿里全球子公司所有機(jī)房。所有性能指標(biāo)做到秒級(jí)連續(xù)不間斷監(jiān)控。 摘要: 2017雙11再次創(chuàng)下了32.5萬(wàn)筆/秒交易創(chuàng)建的紀(jì)錄,在這個(gè)數(shù)字后面,更是每秒多達(dá)幾千萬(wàn)次的數(shù)據(jù)庫(kù)寫(xiě)入,如何大規(guī)模進(jìn)行自動(dòng)化操作、保證數(shù)據(jù)庫(kù)的...
閱讀 3144·2021-09-28 09:43
閱讀 976·2021-09-08 09:35
閱讀 1501·2019-08-30 15:56
閱讀 1248·2019-08-30 13:00
閱讀 2790·2019-08-29 18:35
閱讀 1892·2019-08-29 14:07
閱讀 3531·2019-08-29 13:13
閱讀 1398·2019-08-29 12:40