云计算中的 NAS-InfoQ

（一）疑问：云时代为什么没有 NAS？

NAS 是传统存储行业重要的组成部分，基于 SMB、CIFS 提供支持 POSIX 协议的文件共享服务，是所有传统存储厂商都提供的产品，甚至是必须提供的产品。但似乎所有的云服务似乎都对这种共享存储的形式置若罔闻，AWS推出滞后，Azure没有，GAE没有，阿里云当然也没有。OpenStack有一个Manila，但是半死不活。是不是NAS在云时代，已经死了？

NAS on Cloud 究竟何去何从，我们分析分析看。

如果想知道一个事情为什么是现在这个样子，最好的办法就是看看他的历史。

云计算毫无疑问是来自于互联网领域，或者限制的更窄一点：电商领域。全球的云计算做的最大最好的 AWS，其实就是个电商。当年 Amazon 电子商业越做越大，对于 IT 系统的要求也越来越高，最终 IT 部门不负众望，搞出了一套足够靠谱的 IT 基础设施，这就是现在 AWS 的前身了。

而后，Amazon 做了一个英明神武的决定，将这套系统开放出去，商业化，收钱，所以就有了 AWS。当时 AWS 主要还是供 Amazon 自家使用，最多是 Amazon 周边的厂商使用。然后，各个行业的 IT 系统越来越大，要求越来越高，越做越复杂，大家发现原有的 IT 方式已经扛不住了，急切的需要一种新的 IT 运作方式。放眼望去，似乎 AWS 这种方式相当靠谱，于是先是眼前一亮，然后一拥而上，纷纷效仿，各种类 AWS 的系统如雨后春笋，粉墨登场。

玩家多了，就形成了一个领域，一个行业，这个领域，这个行业，就叫云计算。

反观国内，阿里也想走这条路，但是看似相同，实则大相径庭。阿里云最开始并不是从阿里的电商系统（也就是淘宝和天猫）演化或者开放而来的，而是完全按照云计算的想法从头开发的。阿里内部淘宝系和阿里云系是什么关系，谁也说不清楚，而淘宝、天猫用不用阿里云，都值得研究一番。所以阿里云和 AWS 的路看似相同，实际差别却很大。当然，未来整个大阿里是不是能够完全由阿里云提供基础设施服务，现在还不好说，不过从当前的趋势看，大阿里确实是这么设想的，这样也未尚不是一条曲线救国的好路，至少不需要背负电商业务的包袱。

扯了这么多，似乎扯远了，但是搞明白了历史之后，在看现今就已经很清楚了。回到我们的问题上，为什么云上没有NAS？很简单，因为电商不需要啊。

我们看看电商都需要什么：

运行Web服务：虚拟机（计算**+**块存储）
保存用户数据：数据库
保存静态内容：对象存储
分发静态内容：CDN
用户行为分析：数据分析

这些也就是云计算目前提供的功能。

再看看电商或者大的互联网公司对这些特性有什么要求：

横向扩展：支持业务平滑增长
快速高效：提高响应速度，避免错过商机
稳定运行：业务中断意味着经济损失
异地容灾：数据是最重要的资源，不容有失

以上这些也恰恰是云计算所关注的特性。

所以说，云计算蕴含着互联网甚至是电子商务的基因。

而现在，看一下我们的主角：NAS。不好意思，电子商务用不到，互联网也不关心，所以，云计算中没有 NAS。

（二）原因：这些因素阻碍了云 NAS 的发展

我们回顾了云计算诞生的历史，也就搞明白了为什么目前所有的云计算提供商都没有提供 NAS 服务，但是这个问题实际上还可以继续的追问下去：为什么互联网或者电商都都不使用文件系统？如果当初互联网的玩家们使用的都是文件系统构建他们的 IT 服务，那么毫无疑问，今天的云计算将是围绕 NAS 构建的。可是事实却是文件系统这个历史悠久的存储形式成为了互联网时代的弃儿，这是为什么？回答这个问题还要从文件系统本身找原因，最关键的因素是：文件系统本身就不具有互联网、或者说互联的基因。今天我们从技术的角度分析分析，文件系统为什么没有互联的基因。

文件系统的组织形式

文件系统的信息组织方式是大家最熟悉不过的了：树形结构。这种结构实际上非常符合人类的思维方式（仅次于图状结构），生活和生产中太多太多的东西可以用树形的方式恰当的描述和组织，这大概也是最初文件系统这么设计的原因了。

文件系统的结构虽然非常符合使用习惯，为数据的整理提供了很多的方便，但是却给系统实现上带来了很多的挑战。比如 POSIX 规定文件系统要实现文件的移动（move/mv）操作，由于源地址和目标地址可能是树上的任意两个节点，而这两个节点之间可能是父子关系、兄弟关系、同父关系等各种关系，因此在设计和实现上就引入了很多复杂性。而且 POSIX 还定义了软连接和硬链接这两种有用但是进一步增加了设计复杂程度的语义，导致现有的文件系统元数据的管理大多涉及到引用计数机制和同步锁机制。

到了云时代，文件系统这种方式对于一个云系统来说，似乎又过于复杂了。想象一下，如果成千上万人向一个文件系统中塞东西，是一件多么混乱而可怕地事情，信息几乎不可能以有效、统一的方式组织起来，更不用说快速检索了。在网络还不是很普及、带宽有限、费用高昂的十几年前，如果是那时候上大学的人，一定用过校园的 FTP 服务来共享文件，相信对这种场景多少有些感触。实际上，现在很多个人的电脑硬盘的文件夹已经和乱麻一样了，更不用说成成千上万人共用一个文件系统。

问题的根源在于树形结构这种组织形式在提供了足够的灵活性和复杂的功能的同时，对使用者限制太少，在超大规模的数据的组织过程中，弊大于利。

文件系统的共享方式

在计算机可以联网之后，共享信息就成了刚需，除了专门设计用来共享信息的 HTTP 等各类协议外，直接将整个文件系统共享出去的协议也不少见，比如我们常用的 FTP、SMB、CIFS 等。这些协议的用法大同小异，基本上都是为了将一个本地的文件系统通过网络共享给很多人同时使用。

人多了，麻烦就来了。首当其冲的就是权限问题。如何合理的为多用户系统设计权限一直是没有彻底解决的大问题，原因也很简单：需求太复杂，而且例外也太多。

虽然问题很困难，但是解决方案还是要有的，于是 ACL 应运而生，尝试在文件系统共享服务中实现基于用户的权限管理系统。不得不说，ACL 还是解决了大部分问题的，但仅限于系统规模较小、用户不多的情况。对于云计算这种超大规模的系统，ACL似乎就无能为力了。

文件系统的可扩展性

我们都知道，在云计算时代，任何不能 Sacle-Out 的方案无疑都是行不通的。因此，针对大规模文件系统应用，出现了分布式文件系统。这种分布式架构的文件系统确实可以解决现在的很多问题，例如通过三方分离架构，实现了数据流和元数据流的分离，能够做到吞吐量的 Scale-Out。但是，文件系统的组织形式最终限制了它的可扩展性，本质上很难实现彻底的 Scale-Out。

在前面“组织形式”一节中，我们已经分析过：由于文件系统是树形结构，所以工程实现中基本无可避免的使用了引用计数和锁机制或这类的机制，而且锁的颗粒度在很多时候可能是从根节点到当前操作路劲的所有节点，这对于可扩展性的来说，几乎是致命的。最初的文件系统都是基于本地磁盘构建的，所有文件系统的操作都是在一台机器上进行，实现引用计数和同步锁还是可以接受的。因为所有的计算和 IO 都发生在一台机器上，由内存完成数据的交换，性能是可以保证的。但是在分布式系统中，要想实现引用计数和同步锁的话，就让人头皮发麻。因为这通常意味着分布式锁和分布式事务，这两种东西对于性能来说，简直就是杀手般的存在，更别说还需要考虑容灾和故障恢复的问题……我相信任何分布式系统的设计人员遇到这样棘手的东西，都难免要叹一口气。

文件系统的共享方式也通常成为扩展的扩展的瓶颈，因为 SMB、CIFS、FTP 这样的协议通常需要 Proxy 或者 GateWay 的存在，而该模块也可能成为瓶颈，必须再引入 LVS 等负载集群技术解决这一问题，进一步加剧了系统的复杂性。

归根结底，由于文件系统采用了树形的数据组织形式，而这种形式难以很好实现横向拆分，导致文件系统无法具备良好的横向扩展性。在数据汹涌而来的互联网、云计算、大数据时代，没有什么是比这更加致命的问题了。

难道文件系统真的大势已去？

（三）复苏：NAS 在云时代何去何从

我们从技术的角度分析了 NAS 或者说文件系统这种存储形式为什么不适合云计算。但是进入了云计算时代，是不是就不会再有 NAS 生存的空间了？未必。实际上我们上面已经分析过了，决定一个系统有什么或者没有什么，主要取决于需求。那么，云计算时代有没有NAS的需求，答案是肯定的。

云计算需要 NAS

云计算最终的目的或者出发点，是将计算、存储、网络都变成服务，变成类似水、电一样的基础设施，而不仅仅是为互联网和电商提供服务。实际上，现在大部分企业在规划其 IT 设施时，已经将云计算的方式作为重要的选型之一。

传统企业对于云计算的需求和互联网企业有很大不同的，除了云计算目前已经具备的各类优势，例如可扩展，低成本，易维护等，还有一项最核心最基本、甚至大家都不会特意提到的需求：能够满足他们的业务。

传统企业存在大量系统支持他们的业务，在迁移到云计算的过程中，重建所有的业务系统显然是不现实的。所以传统企业愿意迁移到云计算环境的一个前提是云计算的环境必须能够满足他们对业务的支持，也就是能够良好的运行现有的业务支持系统。

不幸的是，这些支持系统，很大一部采用NAS构建，对于文件系统有很强的依赖性，而这些系统已经足够老旧，老旧到只有人用，没有人维护。要运行这些系统，就必须提供NAS。

云计算中的 NAS

实际上，云计算已经在考虑 NAS 了，就像前面提到的，作为开源云计算龙头老大 OpenStack，已经包含了用于提供文件系统共享存储的 Manlia 了，只是这个项目目前还不够成熟，也没有见到应用案例。

Manlia 实际是一个 PaaS 服务，它组合使用了 OpenStack 的 Nova、Cinder、Neutron 等多项服务，通过虚拟机 + 挂载卷 +NFS/CIFS 共享的方式为租户提供文件系统的共享挂载点。同一个网络下的其它虚拟机可以通过该挂载点共享同一个文件系统。

Manlia 的这种实现方式，实际上是一种半 Sacle-Out 的方案，即对于单个命名空间，其容量受限于 Cinder 提供单个共享卷的容量，而性能则受限于单个共享卷的性能、挂载该共享卷的虚拟的性能以及该虚机所在网络的性能。一言以蔽之，即单个命名空间是无法 Sacle-Out，只能 Scale-Up 的。但是 Manlia 提供了一种方便的途径可以快速的创建一个全新的文件系统共享，也就是说，用户可以在单个文件系统不足以支撑其应用的时候，快速的创建新的文件系统。这在一定程度上解决了用户的问题。

但是 ** 要想彻底解决云计算中使用NAS的问题，大概还要从文件系统本身做起。云计算中的NAS要符合云计算的定义和特征，要可扩展、高性能、高可靠，要支持超大规模的应用，要满足多租户、数据隔离、跨地域访问等各种要求，还要做到安全、好用、容易运维，委实是一项不容易的事情。** 目前似乎还没有一个文件系统是真正为云计算量身打造，满足以上这些所有的要求。

Ceph，或许有机会呢。

关于作者

_袁冬博士，__UnitedStack__ 产品副总裁，负责 __UnitedStack__ 产品、售前和对外合作工作；云计算专家，在云计算、虚拟化、分布式系统和企业级应用等方面有丰富的经验；对分布式存储、非结构数据存储和存储虚拟化有深刻地理解，在云存储和企业级存储领域有丰富的研发与实践经验；_Ceph__ 等开源存储项目的核心代码贡献者。

编者按：_ 这一系列文章是袁冬博士于去年 __12__ 月完成的随笔。两个月后，__UnitedStack__ 推出自己的共享文件服务，成为第一家支持云计算 __NAS__ 的厂商。四个月后，_AWS__ 推出其 __Elastic File System 产品，在云计算业内引起关注。

关于UnitedStack的文件共享服务：针对传统企业级信息共享场景，满足企业内部文件共享需求，让用户在云上同样拥有强大、可靠、稳定的 __NAS__ 系统。支持多种标准协议，通过 __NFS_、CIFS__ 等多种标准协议支持所有主流的操作系统，包括 __Linux、__Windows__ 和 __MacOS__ 等。并且具有安全可靠的特征，通过网络层面的隔离，_UOS__ 共享文件服务确保信息的安全，共享信息对于未授权的环境完全不可见。未来将会增加 __ACL__ 权限支持特性。