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