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

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

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

因此，這里會以 OpenStack 作為共享文件服務的控制層，以 Ceph 作為數據平面講講具體如何在云基礎架構中提供 NAS 服務。

OpenStack Manila & CephFS

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

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

1. Default Driver: 使用 RBD 作為 Manila Service VM 的后端，在 VM 上啟動 NFS 實例提供服務
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，從理論上來將可以一定程度提供更好的性能。而第三種是最直接的方式，但是在云環境下實際上是不太會允許 VM 業務網絡 能夠直接訪問后端的存儲網絡的，而在 VM 上直接提供對于 CephFS 的訪問也暴露了 CephFS 目前簡陋的安全隔離性，因此大概也只能在內部小規模私有云中被接受。而第四種在理論上提供了***的使用模型，完全如果 virtio-block 的模型將文件系統從 Host 上暴露給 Guest VM，利用高效的 virtio 框架作為 guest <-> host 數據傳輸支撐，Host 直接訪問 CephFS 集群來在 Host 端通過聚集效應獲得更好的性能支持。

VirtFS & 9p

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

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

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

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