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

云計算

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

我們還是先來(lái)看一下我們會(huì )對數據存儲引擎模塊有什么樣的需求。

首先，肯定是還是可靠。因為我們客戶(hù)的應用場(chǎng)景都大部分是核心的應用，數據可靠是要絕對保證的，沒(méi)有任何妥協(xié)的空間。

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

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

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

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

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

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

接下來(lái)，我們來(lái)說(shuō)一下 LSM Tree。LSM Tree 的數據結構以及實(shí)現我們在這里就做不詳細介紹了?？偟膩?lái)說(shuō)，LSM Tree 是很多存儲引擎的核心。

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

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

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

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

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

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

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

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

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

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

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

接下來(lái)，我們看一下 ZBS 的 User Space 存儲引擎具體的實(shí)現。

IO Scheduler 負責接收上層發(fā)下來(lái)的 IO 請求，構建成一個(gè) Transaction，并提交給指定的 IO Worker。IO Worker 負責執行這個(gè) Transaction。Journal 模塊負責將 Transaction 持久化到磁盤(pán)上，并負責 Journal 的回收。Performance Tier 和 Capacity Tire 分別負責管理磁盤(pán)上的空閑空間，以及把數據持久化到對應的磁盤(pán)上。

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

想了解更多信息，也可訪(fǎng)問(wèn) SmartX 官網(wǎng)：http://wap.friendlycc.com.cn/host/

更多關(guān)于云服務(wù)器，域名注冊，虛擬主機的問(wèn)題，請訪(fǎng)問(wèn)特網(wǎng)科技官網(wǎng)：wap.friendlycc.com.cn