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

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

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

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

OpenStack Manila & CephFS

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

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

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

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

VirtFS & 9p

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

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

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

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