云存储架构于集群NAS关联非常紧密，云和集群NAS已经变成了同义词了。但是云的性能却经常被人们忽略掉。毕竟，人们是通过一个相对较慢的因特网连接来访问数据的。处理器这些数据——尤其是在云存储架构中——是通过访问用户或者应用来完成的。
现今云计算的热潮铺天盖地席卷而来，在存储方面，云服务对存储的需求往往可以分成两方面。一方面，性能是一项关键要求，尤其是对于云计算架构来说。另一方面，具有成本效益的存储也很关键，这通常是云存储架构所要求的。这两个方面都需要能够扩展支持上千个用户和PB级存储。因为集群能够满足这种扩展需求，现在集群NAS架构和云几乎已经变成了同义词。目前有两种集群方法，紧密结合型和松散结合型，而且这两种方法在云存储中都扮演着不同的角色。
松散结合型集群通常可以满足以云存储为主导的环境需求。在这些集群中，每个节点是一个独立的实体，很多卷被分配到节点中，而集群中的其他节点是无法访问这些卷的。在这里，最小的单位是文件，归属于节点。当一份文件被保存在集群中的时候，它的数据就会被完整地保存在集群中某个特定节点中。虽然这个文件的多个副本会被重新定位到其他节点来提供冗余性，但是多个节点无法提供这个文件的单实例。这对于很多云存储架构应用来说是可以接受的。
紧密结合型集群的最小单位是数据块。随着文件被保存到集群中，它们被分成了很多个数据块，而且这些数据块对于集群中的其他任何节点来说都是可访问的。当有文件请求的时候，每个节点会访问这个文件的不同数据块以处理应用或者用户的请求。响应请求的可用节点越多，性能就越高。
在这两种集群方法中，从表面上看应用或者用户面对的都是一个实体。他们不需要识别在多个点之下的多个节点。然而对于存储管理员来说，松散结合型集群存在着某种附在性，因为他们需要管理分布数据和确保不同节点的访问是相对均衡的策略。在紧密结合型集群中只有一个访问点，因为参与文件访问的所有节点都是对等的。
云的性能往往被人们忽略掉。毕竟，人们是通过一个相对较慢的因特网连接来访问数据的。处理器这些数据——尤其是在云存储中——是通过访问用户或者应用来完成的。虽然可能会有上千用户访问数据所带来的性能需求，但是单个节点的性能通常是可接受的。在两种情况下存储性能对于云基础架构来说是非常重要的。
首先是云计算或者应用即服务环境。在云计算环境中，上千个用户往往使用的是一个应用的web前端。所有请求都是在云计算提供商的数据中心内接收和处理的。这大致相当于上千个内部用户访问和请求应用。
第二个使用例子就是那些希望利用云存储架构内部部署可扩展性的数据中心。正如上面所提到的那个例子，潜在的上千个用户同时访问存储集群，所有这些都是在内部进行的，如果需要高性能NAS服务的话，存储的性能就变得十分重要。
挑战是，当提供一个非传统的环境时，计算提供商不能使用传统方法来管理存储性能和可扩展性。在传统方法中，所有组件都是预付费或者前端采购的，然后接下来的五年中资本开支逐渐贬值。
云提供了一种付费即用型的模式。大多数云计算环境并不是从上千个已经预付费使用某项服务的用户开始起步的。用户通常是每个月、每个季度甚至是每年付一次费。因此，云提供商无法承担租赁一个大型前端存储基础架构的成本和期望用户订购并立即付费。他们还意识到了另一个问题，那就是他们的应用或者服务是非常成功的，使得需求很快就超过了最初采购的容量，然后就需要升级到一个更快更昂贵的系统。
云提供商需要一种既能匹配他们的业务模式、又能根据服务进行扩展的模式。云存储市场已经开始快速采用松散结合型存储集群——通过内部开发的技术或者现成的软件——来获得这种灵活性。相比之下，云计算和应用服务提供商则迁移到了紧密结合型云存储架构集群中，提供性能和容量方面的可扩展性。
