AWS 于4月發(fā)布了其 EFSElastic File System 產(chǎn)品，旨在云環(huán)境中提供 NAS 服務(wù)，終于填補(bǔ)上了公有云領(lǐng)域***一塊傳統(tǒng)存儲(chǔ)領(lǐng)地。其主要提供 NFS V4 版本協(xié)議，單純只支持 NFS V4 這個(gè) NFS 中唯一帶狀態(tài)的協(xié)議然后考慮到 AWS 目前基礎(chǔ)軟件現(xiàn)狀這點(diǎn)不得不讓我思考 Amazon 在云存儲(chǔ)上的深厚功底了。

眾所周知，DAS、SAN 和 NAS 是傳統(tǒng)企業(yè)存儲(chǔ)對(duì)使用方式類(lèi)型的三種區(qū)分，其中 DAS 對(duì)應(yīng)于 EBS(Elastic Block System) 服務(wù)，這里的 EBS 虛指所有云廠(chǎng)商的塊存儲(chǔ)系統(tǒng)，SAN 作為 DAS 的增強(qiáng)在傳統(tǒng)企業(yè)存儲(chǔ)占據(jù)主導(dǎo)地位，但是在云環(huán)境中的作用并不是這么明顯，因?yàn)?SAN 相對(duì)于 DAS 更多的提供了數(shù)據(jù)保護(hù)、功能增強(qiáng)、更強(qiáng)性能的作用，在云環(huán)境下這些特性往往是底層存儲(chǔ)系統(tǒng)所提供并附加到虛擬卷上。因此 SAN 只剩下的集中控制器提供的共享存儲(chǔ)功能是需要提供的。因此，在云環(huán)境下的少部分 EBS 實(shí)現(xiàn)會(huì)增加多 VM 掛載能力，使得 EBS 同時(shí)覆蓋了 DAS 和 SAN 的使用場(chǎng)景。當(dāng)然不同云廠(chǎng)商提供的 EBS 在實(shí)現(xiàn)和產(chǎn)品提供上有著巨大差異，因此在云端由 EBS 提供的虛擬卷往往需要根據(jù)云廠(chǎng)商本身的 EBS 實(shí)現(xiàn)而提供傳統(tǒng) SAN 所具備的能力。

那么，剩下的 NAS 作為傳統(tǒng)企業(yè)存儲(chǔ)的另一支柱在云環(huán)境下的展現(xiàn)是不可或缺的，NAS 通常以標(biāo)準(zhǔn)的文件系統(tǒng)協(xié)議如 NFS、CIFS 被用戶(hù)訪(fǎng)問(wèn)，傳統(tǒng)企業(yè) NAS 如 EMC 的 Isilon, NetApp 的 FAS。在傳統(tǒng)企業(yè)存儲(chǔ)中 NAS 跟 SAN 同樣是主要的數(shù)據(jù)存儲(chǔ)方式，在傳統(tǒng) IT 遷移到云基礎(chǔ)架構(gòu)的階段中，提供 NAS 服務(wù)是不可或缺的遷移基礎(chǔ)之一。即使在在面向云基礎(chǔ)架構(gòu)(IAAS, PAAS)的新業(yè)務(wù)、架構(gòu)下 NAS 依然有其發(fā)揮之處，通過(guò)共享目錄來(lái)解決業(yè)務(wù)的并發(fā)或者控制面的數(shù)據(jù)存儲(chǔ)，大數(shù)據(jù)場(chǎng)景更是云 NAS 的重要用武之處。

因此，這里會(huì)以 OpenStack 作為共享文件服務(wù)的控制層，以 Ceph 作為數(shù)據(jù)平面講講具體如何在云基礎(chǔ)架構(gòu)中提供 NAS 服務(wù)。

OpenStack Manila & CephFS

OpenStack Manila 項(xiàng)目從 13 年 8 月份開(kāi)始進(jìn)入社區(qū)視野，主要由 EMC、NetApp 和 IBM 的開(kāi)發(fā)者驅(qū)動(dòng)，是一個(gè)提供共享文件系統(tǒng) API 并封裝不同后端存儲(chǔ)驅(qū)動(dòng)的孵化項(xiàng)目。目前主要的驅(qū)動(dòng)有 EMC VNX、GlusterFS、IBM GPFS、華為、NetApp 等。而 Ceph 作為目前 Cinder 項(xiàng)目最活躍的開(kāi)源后端實(shí)現(xiàn)，自然希望在 Manila 上仍然提供強(qiáng)有力的支持，何況 CephFS 本就是 Ceph 社區(qū)寄以厚望的組件。而從共享文件服務(wù)本身考慮，一個(gè)能橫向擴(kuò)展的分布式存儲(chǔ)支持是其服務(wù)本身最重要的支撐，從目前的整個(gè)分布式文件存儲(chǔ)方案(狹義的 POSIX 兼容)上來(lái)看，CephFS 也是佼佼者之一。

在 14 年初的一次 Ceph Core Standup IRC 會(huì)議上，Sage 提到在目前 RadosGW, Ceph RBD 都成功作為 OpenStack 后端存儲(chǔ)項(xiàng)目支持后蒸蒸日上的情況，那么 CephFS 是不是也可以考慮進(jìn)入 OpenStack 存儲(chǔ)選項(xiàng)之列。當(dāng)時(shí)的 Manila 已經(jīng)有所耳聞，社區(qū)決定將一些目光投入 Manila。但是隨著后來(lái) Redhat 收購(gòu) Inktank 的計(jì)劃，大量精力仍被放在已有成熟體系的完善上，因此暫時(shí)沒(méi)有對(duì) CephFS 與 Manila 整合的動(dòng)作。從 14 年的下半年開(kāi)始，本人以及另一位同事開(kāi)始考慮并設(shè)計(jì)實(shí)現(xiàn)將 CephFS 與 Manila 整合并納入現(xiàn)有云體系中。在 Redhat 收購(gòu) Ceph 后，CephFS 是***的受益者，更多的開(kāi)發(fā)者和資源投入其中。15年 2 月，Sage 重新在 Maillist 中號(hào)召 CephFS 對(duì) Manila 的支持上，大致總結(jié)出目前潛在的四種思路:

1. Default Driver: 使用 RBD 作為 Manila Service VM 的后端，在 VM 上啟動(dòng) NFS 實(shí)例提供服務(wù)
2. Ganesha Driver: 使用 Ganesha 將 CephFS 重新 Reexport 出去
3. Native CephFS Driver: 在 Guest VM 上直接使用原生 CephFS Module 訪(fǎng)問(wèn)
4. VirtFS Driver: 將 CephFS 掛載在 Host 端，VM 通過(guò) VirtFS 訪(fǎng)問(wèn)

在 Ceph I 版的 CDS 上討論這些思路的利弊o(hù)penstack manila and ceph，毫無(wú)疑問(wèn)***種是最簡(jiǎn)單也是性能***的思路，而第二種僅僅是將 RBD 變成 CephFS，從理論上來(lái)將可以一定程度提供更好的性能。而第三種是最直接的方式，但是在云環(huán)境下實(shí)際上是不太會(huì)允許 VM 業(yè)務(wù)網(wǎng)絡(luò) 能夠直接訪(fǎng)問(wèn)后端的存儲(chǔ)網(wǎng)絡(luò)的，而在 VM 上直接提供對(duì)于 CephFS 的訪(fǎng)問(wèn)也暴露了 CephFS 目前簡(jiǎn)陋的安全隔離性，因此大概也只能在內(nèi)部小規(guī)模私有云中被接受。而第四種在理論上提供了***的使用模型，完全如果 virtio-block 的模型將文件系統(tǒng)從 Host 上暴露給 Guest VM，利用高效的 virtio 框架作為 guest <-> host 數(shù)據(jù)傳輸支撐，Host 直接訪(fǎng)問(wèn) CephFS 集群來(lái)在 Host 端通過(guò)聚集效應(yīng)獲得更好的性能支持。

VirtFS & 9p

我們知道 Virtio 提供了一種 Host 與 Guest 交互的 IO 框架，而目前 KVM 的塊存儲(chǔ)主要使用的就是 virtblk 進(jìn)行塊設(shè)備指令交互，那么 VirtFS 作為文件系統(tǒng)指令的交互后端是如何作為呢?

VirtFS 是 IBM 于 2010 年提交的 PaperVirtFS—A virtualization aware File System pass-through的主要成果，其主要利用 9P 作為 virtfs 的協(xié)議指令在 Host 與 VM 中交互，9p協(xié)議并不是一種面向普通文件系統(tǒng)場(chǎng)景更不是面向虛擬化設(shè)計(jì)的文件系統(tǒng)協(xié)議，主要以簡(jiǎn)單和面向?qū)ο鬄樘攸c(diǎn)，而 9p 在 Linux 內(nèi)核中早有相應(yīng)的驅(qū)動(dòng)從而可以減少客戶(hù)端內(nèi)核工作量，而為了支持現(xiàn)有 Unix/Linux 下 VFS 復(fù)雜的文件指令語(yǔ)意，VirtFS 專(zhuān)門(mén)擴(kuò)展了 9p 協(xié)議使得支持?jǐn)U展屬性和 Linux 文件權(quán)限體系命名為 9P2000.L。而 VirtFS 目前在 Host 上的后端主要是 Local FileSystem，這時(shí)候我們既可以通過(guò) Mount CephFS 目錄到 Host 系統(tǒng)或者直接通過(guò) libcephfs userspace library 來(lái)直接通過(guò) QEMU 訪(fǎng)問(wèn)來(lái)繞過(guò) Host Kernel。雖然目前 libcephfs 在 IO 帶寬上內(nèi)媲美內(nèi)核實(shí)現(xiàn)，但是在多文件壓測(cè)上仍然遜色于內(nèi)核模塊，而 libcephfs 理論上是能提供更***的 IO 路徑。

因此，在基于 OpenStack 的云平臺(tái)下，使用 CephFS 作為共享文件服務(wù)的存儲(chǔ)后端，利用 VirtFS 作為 Guest 到 Host 的管道我們可以擁有一個(gè)理想的 IO 路徑，提供高效的性能、充分的隔離性和客戶(hù)端支持。***一步實(shí)際上是 9p 協(xié)議在 VirtFS 實(shí)現(xiàn)上的低效性，通過(guò)簡(jiǎn)單閱讀 9p 協(xié)議和其實(shí)現(xiàn)，我們可以了解到 9p 作為簡(jiǎn)單文件系統(tǒng)協(xié)議，在 Linux 典型的 IO 場(chǎng)景下缺乏控制流緩存這一本質(zhì)缺陷，完全不在客戶(hù)端實(shí)現(xiàn)任何結(jié)構(gòu)緩存或者類(lèi)似優(yōu)化機(jī)制，而 QEMU 端雖然存在一定的結(jié)構(gòu)緩存，但是因?yàn)槠鋵?duì)后端共享文件系統(tǒng)的未知性，依然不會(huì)緩存。因此，VirtFS 已然可以提供超過(guò)本地塊設(shè)備的單文件 IO 讀寫(xiě)性能，但在大量文件控制加數(shù)據(jù)流這一典型場(chǎng)景下仍存在大量問(wèn)題，解決好從 Guest 到 QEMU 的 9p 協(xié)議性能問(wèn)題是這一方案目前***的一公里。

***，雖然上述主要講述 Ceph 在文件共享服務(wù)中的情況，但是應(yīng)用到其他存儲(chǔ)后端甚至是其他 Hypervisor 依然有可參考性，比如目前火熱的 Docker(這個(gè)方向是 Sage 和作者本人在今年的合作點(diǎn)之一)!