二、數(shù)據(jù)庫分布式改造面臨三大挑戰(zhàn)
借鑒互聯(lián)網(wǎng)優(yōu)秀實(shí)踐，我司采用基于開源MySQL的分布式數(shù)據(jù)庫和分庫分表的方式替代核心業(yè)務(wù)的Oracle數(shù)據(jù)庫，可靠性方面采用一主兩從，增強(qiáng)型半同步復(fù)制的方式，來保障主從節(jié)點(diǎn)的強(qiáng)一致性。
一開始我們采用物理服務(wù)器的方式部署MySQL。為保證核心業(yè)務(wù)的穩(wěn)定性，采用了NVMe Flash卡作為存儲(chǔ)，配置兩路CPU。然而，在實(shí)踐過程中，我們發(fā)現(xiàn)這種服務(wù)器本地盤的部署方式帶來了難以解決的問題：
1.可靠性
因?yàn)槌休d的是核心業(yè)務(wù)，直接關(guān)系客戶體驗(yàn)，因此我們對(duì)可靠性的要求非常高。而服務(wù)器的可靠性比較低，同時(shí)為了保證性能大量使用NVMe Flash卡，但服務(wù)器對(duì)它的使用沒有優(yōu)化，會(huì)因?yàn)轭l繁寫入導(dǎo)致故障，使用年限越長(zhǎng)同時(shí)出現(xiàn)大批量的故障增加，即使有多副本也無法保證不丟數(shù)據(jù)。
使用NVMe Flash卡是為了保證系統(tǒng)性能，但它不能做RAID，導(dǎo)致卡壞了或者服務(wù)器故障時(shí)間長(zhǎng)一點(diǎn)，就需要全量恢復(fù)數(shù)據(jù)來重建副本。這需要備份恢復(fù)全量的數(shù)據(jù)，再用Binlog追日志，雖然一個(gè)實(shí)例只有500G到1T的數(shù)據(jù)，但因?yàn)镸ySQL的日志同步很慢，500G的數(shù)據(jù)經(jīng)常要恢復(fù)3個(gè)小時(shí)，當(dāng)業(yè)務(wù)壓力大時(shí)，會(huì)導(dǎo)致很長(zhǎng)時(shí)間都追不上。
還有MySQL的增強(qiáng)型半同步在業(yè)務(wù)壓力比較大時(shí)，比如做批量開戶時(shí)有可能因?yàn)樾阅軉栴}退化成異步同步，這時(shí)如果發(fā)生切換會(huì)導(dǎo)致數(shù)據(jù)丟失，對(duì)我們的運(yùn)維是很大的挑戰(zhàn)。
2.資源分配
為了應(yīng)對(duì)業(yè)務(wù)互聯(lián)網(wǎng)化的挑戰(zhàn)，我們借鑒互聯(lián)網(wǎng)架構(gòu)改造業(yè)務(wù)，期望能實(shí)現(xiàn)資源的快速發(fā)放和按需擴(kuò)容。但我們發(fā)現(xiàn)使用服務(wù)器本地盤的方式，當(dāng)計(jì)算或者存儲(chǔ)單一資源耗盡需要擴(kuò)容時(shí)，只能計(jì)算、存儲(chǔ)綁定擴(kuò)容，導(dǎo)致資源的浪費(fèi)， CPU資源利用率不到15%，如果無法實(shí)現(xiàn)彈性伸縮，按需擴(kuò)容，那么花這么大代價(jià)做分布式化改造就沒意義了。
3.成本
我們發(fā)現(xiàn)替換Oracle后硬件投入不降反增，這由幾方面原因造成：
首先為了保證性能，數(shù)據(jù)庫分庫分表后每個(gè)MySQL實(shí)例限制在500G-1T規(guī)模，這樣一個(gè)Oracle數(shù)據(jù)庫要拆分成幾個(gè)甚至十幾個(gè)數(shù)據(jù)庫實(shí)例。
其次因?yàn)榛謴?fù)從節(jié)點(diǎn)的時(shí)間太長(zhǎng)，需要通過一主兩從的方式保證可靠性，然而不管是主還是從節(jié)點(diǎn)，為了保證服務(wù)器的可靠性，要求一臺(tái)服務(wù)器上最多部署3個(gè)實(shí)例。
同時(shí)由于無法按需擴(kuò)容，要預(yù)留相對(duì)多的資源，以防業(yè)務(wù)高峰的帶來突然增加的數(shù)據(jù)量，因?yàn)閿U(kuò)容不及時(shí)而導(dǎo)致系統(tǒng)奔潰。
在服務(wù)器本地盤存算一體的架構(gòu)下，要保證系統(tǒng)的可靠性，一臺(tái)服務(wù)器上部署實(shí)例比較少，CPU利用率很低。利用率低也意味著更多的服務(wù)器投入，甚至機(jī)房供電都變得緊張。
因此我們決定探索從部署架構(gòu)等方面進(jìn)行優(yōu)化的可能性。
三、選擇計(jì)算存儲(chǔ)分離架構(gòu)的主要考慮因素
1.本地盤云架構(gòu)部署能解決與不能解決的問題
我們首先想到的是用云的模式，對(duì)數(shù)據(jù)庫，可以采用的方式是虛擬化和容器化。虛擬化技術(shù)成熟，可以作為當(dāng)前選擇，容器化性能損耗小，靈活度高，可作為未來方向進(jìn)行評(píng)估。采用云架構(gòu)部署和配置資源能解決快速部署，資源隔離，資源的按需發(fā)放等問題，業(yè)界也有很多用容器化來部署MySQL的實(shí)踐。
但研究了一些企業(yè)使用容器化方案后發(fā)現(xiàn)，如果仍使用本地盤，僅做容器化并不能解決根本問題。
首先，可靠性依然由服務(wù)器和本地盤決定，沒有本質(zhì)提升，更重要的是數(shù)據(jù)在本地盤上無法實(shí)現(xiàn)跨服務(wù)器的漂移，這使故障切換后恢復(fù)時(shí)間長(zhǎng)的問題無法解決，我們還是不能放手增加服務(wù)器上的實(shí)例數(shù)量。
再有同樣因?yàn)闊o法實(shí)現(xiàn)漂移，就無法實(shí)現(xiàn)資源的彈性擴(kuò)縮容，這樣在資源彈性分配和節(jié)省成本的優(yōu)勢(shì)就大打折扣。
2.計(jì)算和存儲(chǔ)分離的價(jià)值
我們的架構(gòu)是借鑒互聯(lián)網(wǎng)的，我們發(fā)現(xiàn)去IOE的阿里，以及京東也遇到了同樣的問題，阿里在雙11遇到了MySQL部署在本地盤無法彈性擴(kuò)容的問題，京東則把可靠性、運(yùn)維、擴(kuò)容等問題總結(jié)為存儲(chǔ)之殤。最終他們的解決方案都是采用計(jì)算、存儲(chǔ)分離。
阿里方案可以和分庫分表結(jié)合，但封閉架構(gòu)無法集成我們基于MySQL的開源數(shù)據(jù)庫。
京東的方案不需要改造數(shù)據(jù)庫就可以實(shí)現(xiàn)，對(duì)我們來說，更具有參考性，通過Kubernetes實(shí)現(xiàn)了CSI插件對(duì)存儲(chǔ)的調(diào)用，目前有狀態(tài)的容器技術(shù)已經(jīng)成熟，問題能很好解決：
首先，可靠性上，存儲(chǔ)是有冗余保護(hù)的，可靠性高于服務(wù)器；其次，容器與外置存儲(chǔ)結(jié)合能實(shí)現(xiàn)跨物理機(jī)的漂移，故障恢復(fù)不需要全量恢復(fù)數(shù)據(jù)，故障降級(jí)時(shí)間大幅度縮減；同時(shí)，計(jì)算、存儲(chǔ)解耦實(shí)現(xiàn)按需擴(kuò)容，資源利用效率提升，整體成本下降50%。
3.為什么選擇全閃存存儲(chǔ)
接下來就是存儲(chǔ)分離后選擇什么樣的存儲(chǔ)？存儲(chǔ)的選型主要考慮幾個(gè)方面：
第一、綜合性能上不能比原有方案差，存儲(chǔ)不能成為性能瓶頸。由于我們之前用的是NVMe Flash本地盤，因此在性能上考慮時(shí)延要小于0.5ms，同時(shí)峰值性能要求達(dá)到不低于8000IOPS/TB的性能密度。基于此考慮，企業(yè)級(jí)全閃存存儲(chǔ)的低時(shí)延高性能密度的特性比較適合。
第二、可靠性。以我們的使用經(jīng)驗(yàn)，核心業(yè)務(wù)數(shù)據(jù)庫中選擇有良好使用記錄和服務(wù)支持能力的廠商的全閃存是更好的選擇。全閃存的磨損均衡，反磨損均衡，全互連架構(gòu)正好是解決SSD可靠性的關(guān)鍵能力。
第三、擴(kuò)展性。在使用場(chǎng)景中考慮，因?yàn)榻灰仔蛿?shù)據(jù)庫為了保證核心數(shù)據(jù)庫的可靠性和維護(hù)性，要?jiǎng)澐指〉墓收嫌?，不管是?jì)算、還是存儲(chǔ)資源都可以按需分配，滿足業(yè)務(wù)擴(kuò)展需求，不會(huì)配置很大的資源池，但要有“適度”的靈活擴(kuò)展能力。
四、基于華為OceanData MySQL存算分離方案的實(shí)踐
從上面的分析可以看出，沒有最優(yōu)的架構(gòu)，只有更適合的架構(gòu)，在核心業(yè)務(wù)數(shù)據(jù)庫中，全閃存是更好的選擇，當(dāng)然前提是這個(gè)全閃存存儲(chǔ)具有足夠的可靠性，并融合了分布式的部分特征。最終我們選擇華為OceanData MySQL存算分離方案展開方案驗(yàn)證工作。
1.要重點(diǎn)驗(yàn)證解決哪些問題
配置方案：存儲(chǔ)采用了華為OceanStor Dorado18500，網(wǎng)絡(luò)采用了25GE以太網(wǎng)，確保性能。同時(shí)這個(gè)組網(wǎng)同時(shí)支持ISCSI和NOF組網(wǎng)，方便未來升級(jí)到性能和穩(wěn)定性更好的NOF組網(wǎng)。
前面已經(jīng)提到，我們認(rèn)為容器化是未來的方向，因此對(duì)容器化部署方案驗(yàn)證進(jìn)行了詳細(xì)設(shè)計(jì)和充分驗(yàn)證，以保障核心業(yè)務(wù)數(shù)據(jù)庫的正常、穩(wěn)定運(yùn)行。容器場(chǎng)景下存儲(chǔ)資源的編排發(fā)放，擴(kuò)容等功能性驗(yàn)證；云虛擬機(jī)、本地虛擬機(jī)和容器的基準(zhǔn)測(cè)試、性能、可靠性測(cè)試以及數(shù)據(jù)庫部署實(shí)例密度測(cè)試。
關(guān)于性能，通過測(cè)試我們得出兩條結(jié)論：
1、同等CPU和內(nèi)存資源消耗下，當(dāng)配置相同數(shù)量的MySQL主從集群時(shí)，ISCSI容器化部署的性能是本地虛擬機(jī)的1.5倍。
2、相同MySQL參數(shù)下，NOF容器化部署是ISCSI容器化部署的1.5倍，同時(shí)CPU使用率也提高了1.5倍，這也符合測(cè)試結(jié)果中體現(xiàn)的TPMC值與CPU使用率成正相關(guān)的關(guān)系。這個(gè)結(jié)果也反映出NOF組網(wǎng)相比于ISCSI組網(wǎng)，可以達(dá)到更高的性能上限。
這些結(jié)論加深我我們向容器化演進(jìn)的信心。
可靠性方面，我們考慮的是綜合的可靠性，一方面容器提供了額外的可靠性保障，比如反親和，另一方面我們重點(diǎn)測(cè)試了容器的漂移，對(duì)業(yè)務(wù)的感知和數(shù)據(jù)庫實(shí)例重啟是差不多的。這樣在這個(gè)相當(dāng)于重啟的實(shí)例上做增量數(shù)據(jù)補(bǔ)從可以幾分鐘完成。原來一臺(tái)服務(wù)器壞了，不管是在一臺(tái)新的服務(wù)器上恢復(fù)，還是更換部件，再進(jìn)行全量數(shù)據(jù)恢復(fù)和同步，都要半天甚至更長(zhǎng)時(shí)間，現(xiàn)在幾分鐘就完成了，而且過程可以做到自動(dòng)化。
2.實(shí)踐結(jié)果
從整體的效果來看是達(dá)到甚至超出預(yù)期的。各部件可靠性，尤其是存儲(chǔ)可靠性有了比較大的提升，解決了NVMe盤RAID問題，還額外提供了亞健康監(jiān)測(cè)，數(shù)據(jù)校驗(yàn)和SSD磨損均衡和反磨損均衡這些服務(wù)器上不太可能實(shí)現(xiàn)的能力。同時(shí)整體方案上我們看到故障恢復(fù)、降級(jí)時(shí)間，維護(hù)復(fù)雜度都有很大降低。也就是整體可靠性是遠(yuǎn)高于原有方案的。
存算分離后，所有的資源分配都可以是按量的，不會(huì)有CPU不夠存儲(chǔ)用不了或者反過來的情況，同時(shí)因?yàn)榭梢詫?shí)現(xiàn)彈性擴(kuò)容，一方面業(yè)務(wù)支撐能力增強(qiáng)了，另一方面也不用預(yù)留太多資源應(yīng)付突發(fā)擴(kuò)容的問題。在可靠性和運(yùn)維能力提升的基礎(chǔ)上，可以大膽地把每臺(tái)服務(wù)器的實(shí)例數(shù)增加2-3倍。
同時(shí)因?yàn)槲覀兊臉I(yè)務(wù)讀寫比比較低，所以在可靠性得到保障的情況下，可以從一主兩從變?yōu)橐恢饕粡模?/strong>一方面進(jìn)一步節(jié)省資源，另一方面實(shí)例減少對(duì)運(yùn)維也是有好處的，因?yàn)槿嫔显坪笪覀兊膶?shí)例數(shù)會(huì)輕松達(dá)到上千個(gè)。
還有一個(gè)現(xiàn)在比較熱的話題是碳排放。首先華為OceanStor Dorado全閃存存儲(chǔ)的耗電本身就比較低，再加上節(jié)省了大量服務(wù)器，因此機(jī)房占地和耗電可以節(jié)省50%以上，不但保護(hù)了環(huán)境，還為以后的業(yè)務(wù)擴(kuò)展增強(qiáng)了彈性。
3.未來展望
我從事IT工作十幾年，對(duì)于數(shù)據(jù)庫，一直是兩個(gè)思路來提升能力，一條是基于專業(yè)強(qiáng)大的基礎(chǔ)設(shè)施的能力提升整體能力，另一條是通過對(duì)數(shù)據(jù)庫和應(yīng)用的架構(gòu)改造和優(yōu)化來支撐業(yè)務(wù)。隨著網(wǎng)絡(luò)技術(shù)和存儲(chǔ)能力不斷增強(qiáng)，我們基于網(wǎng)絡(luò)和全閃存存儲(chǔ)，通過存算分離架構(gòu)，讓基礎(chǔ)設(shè)施來解決問題，后續(xù)仍然會(huì)考慮沿著這個(gè)思路進(jìn)一步提升方案的能力，尤其是在成熟平臺(tái)基礎(chǔ)上做一些優(yōu)化和集成，達(dá)到事半功倍的效果。對(duì)于存算分離后，對(duì)存儲(chǔ)我們考慮的優(yōu)化方向有：
在故障切換監(jiān)測(cè)半同步狀態(tài)，如果降級(jí)到異步了，就不做主從切換，等容器漂移完成后恢復(fù)服務(wù)，保證不丟數(shù)據(jù)。
進(jìn)一步縮減數(shù)據(jù)副本，節(jié)省成本，因?yàn)閿?shù)據(jù)庫做了副本而存儲(chǔ)再做冗余使冗余超過了可靠性的需要。目前AWS，阿里的云原生數(shù)據(jù)庫都是共享一份存儲(chǔ)的。
容器化的備份方案優(yōu)化，比如使用存儲(chǔ)快照等。
五、總結(jié)
在MySQL分布式改造的探索和實(shí)踐中，我們通過計(jì)算、存儲(chǔ)分離架構(gòu)，借助華為存儲(chǔ)最終實(shí)現(xiàn)了計(jì)算、存儲(chǔ)按需配置，CPU利用率從10%提升至30%，存儲(chǔ)利用率從40%提升至70%；主節(jié)點(diǎn)故障，業(yè)務(wù)重構(gòu)時(shí)間從小時(shí)級(jí)縮短至分鐘級(jí)；存算分離后，IO路徑變長(zhǎng)，但新方案采用RDMA協(xié)議，遠(yuǎn)程內(nèi)存訪問，時(shí)延接近本地盤。
未來，我們也會(huì)在現(xiàn)有架構(gòu)中繼續(xù)探索，進(jìn)一步提升IT基礎(chǔ)設(shè)施的整體能力。
