2.4 块存储、文件存储与对象存储

前面讲述了SDS为何能够成为下一代的主流存储机制，现在看看SDS可以实现出哪几类存储系统。

传统的SAN（存储区域网络）与NAS解决方案在实现存储服务时，一般通过iSCSI（Internet Small Computer Systems Interface，Internet小型计算机系统接口）、FC（Fibre Channel，光纤信道）、FCoE（Fibre Channel Over Ethernet，以太网光纤信道）、NFS（Network File System，网络文件系统）与SMB（Server Message Block，服务器消息块）/CIFS（Common Internet File System，网络文件共享系统）等协议提供。但是在转向云端后，需要用其他办法提供存储能力，对象存储正是这样一种办法。接下来看看对象存储与块存储、文件存储之间的异同。GlusterFS是一种文件存储式的解决方案，不过可以按照类似的方式进行配置，以发挥块存储及对象存储能力。

图2-3用3种图形来比拟这3种存储方式。

当客户端在存储系统中保存数据时，块存储、文件存储与对象存储所用的保存方式区别很大，导致三者的用途完全不同。

2.4.1 块存储

SAN（存储区域网络）是一种块存储，主要利用FC或iSCSI等协议实现，这两种协议分别在光纤与TCP/IP上进行SCSI（小型计算机系统接口）映射。

图2-4是一个通过FC协议构建的SAN。

图2-5是一个通过iSCSI协议构建的SAN。

数据存放在逻辑块地址上面。应用程序获取数据的时候，通常说“我要从XXYYZZZZ这个地址读取X个块”，这个过程极快（不到1毫秒）。因此这种类型的存储延迟相当低，是一种面向事务（transactional-oriented）的存储形式，很适合做随机访问。如果要在多个系统之间共用这种类型的存储，那么它的缺点就会暴露出来；因为块存储通常是以原始形式出现的，必须在它上面搭建一层文件系统，才能让多个客户端同时对该存储进行写入，否则这些写入操作就有可能卡住。换句话说，这是一种集群式的文件系统。

块存储在可用性与灾难恢复上也有缺点。由于它是以原始形式呈现数据的，存储控制器与存储管理器并不清楚其中的数据是怎样使用的。当把这些数据复制到恢复点的时候，只能从块的角度处理数据，而无法根据数据的实际使用情况做出变通。有些文件系统无法对数据块合理地进行回收或清零，会把根本没有用到的数据块也给复制过去，从而导致存储空间得不到高效利用。

块存储所具备的优势及较低的延迟时间，很适合用来存放结构化的数据库，并对随机的读/写操作进行处理。此外，由于VM镜像需要极其频繁地发出I/O请求，因此也适合用块存储来保存。总之，这种集群式的文件系统擅长给来自多台主机的多项读取及写入操作提供支持。

块存储除了上面这些优点与缺点外，还需要注意在使用过程中仔细配置，因为在块设备上面搭建文件系统及分区时，需要让这些文件系统与分区能够跟块存储机制相协调。此外还须保证文件系统本身是一致且安全的，其权限也设置得正确无误；否则，多个系统在同时访问该文件系统时，就有可能把其中的数据破坏掉。VM还会将另一些文件系统融入它们的虚拟磁盘，这就引入了一项复杂的因素，因为数据既有可能写入VM本身的文件系统，也有可能写入监视VM的hypervisor（虚拟机监视器）所在的文件系统。这两种文件系统中的文件都会频繁变更，因此在以随需分配方式实现复制的情境中，必须将它们正确地清零，才能让相关的数据块得以回收，因为大多数存储阵列不会注意写入其中的是何种数据。

2.4.2 文件存储

与块存储相比，文件存储或NAS所用的方式更为直接。你不需要担心如何分区，也不需要考虑怎样选择适合多主机环境的文件系统，并对其进行格式化。

NAS通常采用NFS或SMB/CIFS运作。这些协议主要用来把数据以不带结构的形式保存到共享文件夹里，它们并不擅长扩展，也不能很好地满足多媒体方面的严格要求。例如，在云端搭建社交媒体服务，让用户能够全天候地创建或上传图像及视频，NAS显得比较吃力，而这正是对象存储派上用场的地方。本章稍后再来讲解对象存储系统。

文件存储是运作在文件级别的。当向NAS发出请求的时候，你所请求的是一份文件或其中的某一部分，而不是像访问块存储那样请求一系列逻辑地址。NAS会把这个过程从宿主机器中抽象出来（宿主机器指的是挂载文件存储的电脑），并把具体的文件请求交给存储阵列或SDS处理，让它们在后端通过访问磁盘来满足这一请求。文件存储也会提供一些原生的特性，如文件锁定、用户与组的集成（本文在这里谈论开源文件系统时，主要讲NFS）、安全以及加密等等。

NAS可以通过抽象机制简化客户端的访问工作，与此同时也有一些缺点，因为它必须重度地、甚至是完全地依赖网络而运作。此外，由于它多包含了一层文件系统，延迟远高于块存储。有许多因素都会导致NAS的延迟或RTT（Round-Trip Time，往返时间/来回通信时间）变长，因此必须考虑到NAS与客户端之间经过了多少跳（hop）以及TCP窗口缩放等问题，或者确保访问文件共享系统的设备不启用巨型帧。这些因素影响的不仅是延迟时间，还有整套NAS解决方案的吞吐量，这正是文件存储发挥其优势的地方。

图2-6演示了文件存储机制在共享文件时的灵活一面。

2.4.3 对象存储

对象存储与文件存储（以NAS为代表）、块存储（以SAN为代表）完全不同。虽然通过网络来访问数据，但是获取数据的方式却很独特：不是通过文件系统访问，而是通过HTTP方法及RESTful API来访问。

对象保存在平面的名称空间中，名称空间能够保存上百万乃至上亿个对象，从而很有助于实现高可用性。因为这种做法不像XFS与EXT4等常规的文件系统那样，受制于节点的数量。名称空间也会有分区（一般称为bucket），然而这些分区并不能像常规的文件夹那样嵌套，因为名称空间是平面化的，而不是层次化的。

传统存储与对象存储之间的区别可以比作自助停车（self-parking）与请人代为停车（valet-parking）。因为在使用传统的文件系统时，必须自己来决定文件需要存放在哪个文件夹或目录中，还得把这个位置记住，正如停车的时候需要把停车位记住一样。在使用对象存储时，只需要把数据上传或放到某个bucket里面，它会给你一个独特的标识符（ID），以后可以凭标识符获取这份数据。正如请人代为停车时不用记住停车位一样，只需要把对方停完车后给你的凭证交还给他，他就会把车开回来。

在请别人停车的时候，你通常要把与车有关的一些信息告诉那个人，他可以根据这些信息更准确地判断出是哪一辆车。颜色、车牌号、车型都是很有帮助的信息。对象存储也是如此，每个对象都有自己的元数据（metadata）以及一个独特的ID，该系统所保存的就是对象的这些信息及其中的文件。

图2-8演示了对象存储中的单个对象。

前面提到对象存储要通过RESTful API访问，从理论上说凡是支持HTTP协议的设备，都可以通过PUT或GET等HTTP方法访问对象存储中的bucket。这似乎不太安全，然而由软件定义的对象存储基本上都会采用某种认证方法，要求在获取或上传文件时提供认证标记。在Linux系统下，可以用curl工具执行如下一条简单的请求：

我们可以像图2-9演示的这样，通过HTTP协议把各种设备连接到位于云端的对象（存储bucket）上面。