SmartX產(chǎn)品技術(shù)解析：SMTX分布式塊存儲(chǔ)--存儲(chǔ)引擎篇

云計(jì)算

注：本文內(nèi)容整理自 SmartX CTO 張凱在 SMTX OS 3.5 新品發(fā)布會(huì)上的演講。

創(chuàng)新互聯(lián)公司專注于崗巴網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗(yàn)。 熱誠(chéng)為您提供崗巴營(yíng)銷型網(wǎng)站建設(shè)，崗巴網(wǎng)站制作、崗巴網(wǎng)頁設(shè)計(jì)、崗巴網(wǎng)站官網(wǎng)定制、成都微信小程序服務(wù)，打造崗巴網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供崗巴網(wǎng)站排名全網(wǎng)營(yíng)銷落地服務(wù)。

我們還是先來看一下我們會(huì)對(duì)數(shù)據(jù)存儲(chǔ)引擎模塊有什么樣的需求。

首先，肯定是還是可靠。因?yàn)槲覀兛蛻舻膽?yīng)用場(chǎng)景都大部分是核心的應(yīng)用，數(shù)據(jù)可靠是要絕對(duì)保證的，沒有任何妥協(xié)的空間。

其次是性能，目前在萬兆網(wǎng)絡(luò)和 SSD，包括 NVMe SSD 都已經(jīng)非常普及。隨著硬件的速度越來越快，性能的瓶頸會(huì)從硬件轉(zhuǎn)移到軟件。尤其對(duì)于存儲(chǔ)引擎來說，性能至關(guān)重要。

除了追求絕對(duì)的性能以外，我們還希望能夠做到高效。我們希望每一個(gè) CPU 指令都不被浪費(fèi)。我們追求用最少的 CPU 指令完成一次 IO 操作。這背后的原因是，存儲(chǔ)硬件設(shè)備越來越快，目前最快的存儲(chǔ)已經(jīng)可以做到單次訪問只需要 10 納秒。而如果程序中加一次鎖，做一次上下文切換，可能幾百個(gè)納秒就過去了。如果不做到高效的話，目前的 CPU 可能完全無法發(fā)揮出 SSD 的性能。除了高效的使用 CPU 以外，我們也要高效的使用內(nèi)存資源，網(wǎng)絡(luò)帶寬資源。同時(shí)，由于目前相同容量的 SSD 的價(jià)格還高于 HDD 的價(jià)格，所以我們也盡可能的節(jié)省磁盤空間的占用，通過利用壓縮，去重等技術(shù)，提高 SSD 的空間使用效率。

最后，也是非常重要的一點(diǎn)，存儲(chǔ)引擎需要易于 Debug，而且要易于升級(jí)。對(duì)于軟件工程師來說，50% 以上的工作時(shí)間都是在做 Debug，而對(duì)存儲(chǔ)軟件工程師來說，這個(gè)比例可能更高。我們希望做一個(gè)非常易于 Debug 的軟件產(chǎn)品，如果發(fā)現(xiàn)問題，可以快速的定位并修復(fù)。升級(jí)也是一樣，現(xiàn)在軟件的迭代速度越來越快，我們希望軟件可以方便的易于升級(jí)，這樣我們可以讓用戶更快的使用上新版本的軟件，享受到新版本的功能，以及性能的優(yōu)化。

接下來，我們來看一下具體的實(shí)現(xiàn)。很多傳統(tǒng)的存儲(chǔ)廠商在實(shí)現(xiàn)存儲(chǔ)引擎的時(shí)候，往往會(huì)選擇把整個(gè) IO 路徑的實(shí)現(xiàn)放在 Kernel Space 里面。例如在上圖中，上層是一個(gè)核心的存儲(chǔ)引擎，下層是文件系統(tǒng)，塊設(shè)備，以及驅(qū)動(dòng)。由于網(wǎng)絡(luò)棧也是實(shí)現(xiàn)在內(nèi)核中的，把存儲(chǔ)引擎放在內(nèi)核里面就可以化性能，減少上下文切換（Context Switch）。但這種實(shí)現(xiàn)有很多非常嚴(yán)重的問題，首先就是難于 Debug。如果大家做過內(nèi)核開發(fā)，就會(huì)知道在內(nèi)核中 Debug 是一件非常麻煩的事情。而且開發(fā)語言也只能用 C，不能用其他語言。同時(shí)，在內(nèi)核里面開發(fā)，升級(jí)會(huì)非常困難。一次升級(jí)，不管是 Bugfix，還是增加新功能，都可能需要重啟整個(gè)服務(wù)器，這對(duì)于存儲(chǔ)系統(tǒng)來說代價(jià)是非常巨大的。還有一個(gè)很重要的因素就是故障域非常大。Kernel 里面的模塊如果出問題，可能導(dǎo)致整個(gè) Kernel 被污染，可能是死鎖，可能是 Kernel Panic。通常也是需要重啟服務(wù)器才能修復(fù)。

既然有這么多問題，那我們?cè)谠O(shè)計(jì)的時(shí)候肯定不會(huì)選擇用 Kernel Space 的方式。我們選擇在 Userspace，也就是用戶態(tài)實(shí)現(xiàn)我們的存儲(chǔ)引擎。

在 User Space 實(shí)現(xiàn)，很多項(xiàng)目會(huì)選擇把存儲(chǔ)引擎構(gòu)建在 LSM Tree 的數(shù)據(jù)結(jié)構(gòu)上。LSM Tree 運(yùn)行在文件系統(tǒng)之上。User Space 和 Kernel 比起來更靈活，可以用各種語言；升級(jí)也很方便，只需要重啟一下進(jìn)程就可以，不需要重啟服務(wù)器；User Space 的故障只會(huì)影響到服務(wù)進(jìn)程本身，并不會(huì)影響到 Kernel 的運(yùn)行。但這種方式的問題就是性能不夠好，由于 IO 還是需要經(jīng)過 Kernel，所以會(huì)產(chǎn)生上下文切換，這個(gè)切換就會(huì)引入性能的開銷。

接下來，我們來說一下 LSM Tree。LSM Tree 的數(shù)據(jù)結(jié)構(gòu)以及實(shí)現(xiàn)我們?cè)谶@里就做不詳細(xì)介紹了。總的來說，LSM Tree 是很多存儲(chǔ)引擎的核心。

LSM Tree 的好處就是實(shí)現(xiàn)起來是相對(duì)簡(jiǎn)單的，有很多開源的實(shí)現(xiàn)可以參考，而且它對(duì)小塊數(shù)據(jù)寫入優(yōu)化做的非常好，會(huì)將小塊數(shù)據(jù)合并，并批量寫入。

然而 LSM Tree 并不是銀彈，它的問題由于他的數(shù)據(jù)結(jié)構(gòu)而導(dǎo)致的『讀放大』和『寫放大』。這個(gè)問題會(huì)有多嚴(yán)重呢。我們可以來看一下這個(gè)圖，這是一個(gè)對(duì)『讀寫放大』的測(cè)試結(jié)果。從圖中可以看到，如果寫入 1GB 的數(shù)據(jù)，最終會(huì)產(chǎn)生 3 倍的數(shù)據(jù)寫入量，也就是 3 倍的『寫放大』。如果寫入 100G 的話，則會(huì)被放大到 14 倍，也就是說如果寫 100G 的數(shù)據(jù)，實(shí)際上在磁盤上會(huì)產(chǎn)生 1.4TB 的寫流量。而『讀放大』會(huì)更加嚴(yán)重，在這個(gè)場(chǎng)景下會(huì)放大到 300 多倍。這就違背了我們最開始提到了我們希望提高硬件效率的訴求。

LSM Tree 雖然有各種各樣的好處，但是由于存在嚴(yán)重的『讀寫放大』問題，所以我們并不會(huì)采用LSM Tree 來做數(shù)據(jù)存儲(chǔ)引擎。我們可以借鑒 LSM Tree 中優(yōu)秀的思想，結(jié)合我們自己的需求，實(shí)現(xiàn)一套存儲(chǔ)引擎。這個(gè)包含了數(shù)據(jù)分配，空間管理，IO 等邏輯。

接下來，我們看到這個(gè)這個(gè)圖中還有一個(gè)文件系統(tǒng)。這個(gè)文件系統(tǒng)是實(shí)現(xiàn)在內(nèi)核中的，在塊設(shè)備之上。大家比較常見的文件系統(tǒng)包括 ext4，xfs，btrfs 等，很多存儲(chǔ)引擎也是實(shí)現(xiàn)在文件系統(tǒng)之上的。然而我們需要思考一下我們是否真的需要一個(gè)文件系統(tǒng)。

首先，文件系統(tǒng)所提供的功能遠(yuǎn)遠(yuǎn)多于存儲(chǔ)引擎的需求。例如文件系統(tǒng)提供的 ACL 功能，Attribute 功能，多級(jí)目錄樹功能，這些功能對(duì)于一個(gè)專用的存儲(chǔ)引擎來說，都是不需要的。這些額外的功能經(jīng)常會(huì)產(chǎn)生一些 Performance Overhead，尤其是一些全局鎖，對(duì)性能影響非常嚴(yán)重。

其次，大部分文件系統(tǒng)在設(shè)計(jì)的時(shí)候，都是面向單一磁盤的設(shè)計(jì)方式，而不是面向多塊磁盤的。而一般存儲(chǔ)服務(wù)器上都會(huì)部署 10 塊，甚至更多的磁盤，而且有可能是 SSD，有可能是 HDD，也可能是混合部署。

第三，很多文件系統(tǒng)在異步 IO 上支持的并不好，盡管支持異步 IO 的接口，但實(shí)際使用過程中，偶爾還是會(huì)有阻塞的情況發(fā)生，這也是文件系統(tǒng)里一個(gè)非常不好的地方。

最后一個(gè)問題，文件系統(tǒng)為了保證數(shù)據(jù)和元數(shù)據(jù)的一致性，也會(huì)有 Journaling 的設(shè)計(jì)。但這些 Journaling 也會(huì)引入寫放大的問題。如果服務(wù)器上掛載了多個(gè)文件系統(tǒng)，單個(gè)文件系統(tǒng)的 Journaling 也無法做到跨文件系統(tǒng)的原子性。

最終我們?cè)谠O(shè)計(jì)存儲(chǔ)引擎的時(shí)候，我們選擇了拋棄文件系統(tǒng)，拋棄 LSM Tree，自己在做一個(gè)理想中的存儲(chǔ)引擎，去掉不必要的功能，盡可能的避免寫放大。把我們想要的功能直接實(shí)現(xiàn)在塊設(shè)備上。

我們并沒有想要自己實(shí)現(xiàn) Block Layer 這一層，這是因?yàn)?Linux Kernel 中，Block Layer 是非常薄的一層，里面實(shí)現(xiàn)的算法也非常簡(jiǎn)單，這些算法也都有參數(shù)可調(diào)，也都有辦法關(guān)閉掉，所以不會(huì)有太多額外的性能開銷。

左邊這個(gè)圖就是 ZBS 目前的實(shí)現(xiàn)方式。但這種方式的問題還是性能，Block Layer 和 Driver 都運(yùn)行在 Kernel Space，User Space 的存儲(chǔ)引擎的 IO 都會(huì)經(jīng)過 Kernel Space，會(huì)產(chǎn)生 Context Switch。未來我們會(huì)轉(zhuǎn)向右邊這個(gè)圖的方式，通過 SSD 廠家提供的 User Space 驅(qū)動(dòng)，結(jié)合 PMD（Poll Mode Driver）引擎，以提供更好的性能。

接下來，我們看一下 ZBS 的 User Space 存儲(chǔ)引擎具體的實(shí)現(xiàn)。

IO Scheduler 負(fù)責(zé)接收上層發(fā)下來的 IO 請(qǐng)求，構(gòu)建成一個(gè) Transaction，并提交給指定的 IO Worker。IO Worker 負(fù)責(zé)執(zhí)行這個(gè) Transaction。Journal 模塊負(fù)責(zé)將 Transaction 持久化到磁盤上，并負(fù)責(zé) Journal 的回收。Performance Tier 和 Capacity Tire 分別負(fù)責(zé)管理磁盤上的空閑空間，以及把數(shù)據(jù)持久化到對(duì)應(yīng)的磁盤上。

目前 SmartX 研發(fā)團(tuán)隊(duì)正在開發(fā)下一代 User Space 存儲(chǔ)引擎，感興趣的同學(xué)可以通過評(píng)論區(qū)進(jìn)行交流，也歡迎大家投遞簡(jiǎn)歷到 jobs@smartx.com

想了解更多信息，也可訪問 SmartX 官網(wǎng)：https://www.smartx.com

文章標(biāo)題：SmartX產(chǎn)品技術(shù)解析：SMTX分布式塊存儲(chǔ)--存儲(chǔ)引擎篇
轉(zhuǎn)載來源：http://www.muchs.cn/article40/cjjpho.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供虛擬主機(jī)、品牌網(wǎng)站設(shè)計(jì)、外貿(mào)建站、靜態(tài)網(wǎng)站、網(wǎng)站收錄、定制開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)