(一)
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。
#p#
(二)
我们回顾了云计算诞生的历史，也就搞明白了为什么目前所有的云计算提供商都没有提供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
云计算最终的目的或者出发点，是将计算、存储、网络都变成服务，变成类似水、电一样的基础设施，而不仅仅是为互联网和电商提供服务。实际上，现在大部分企业在规划其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，或许有机会呢。
