存储,是各大电子设备不可缺少的组成之一。缺少存储,数据将无法得以保存。上篇文章中,小编对块存储以及文件存储做过初步介绍。本文中,将继续对两种存储方式予以介绍。


一、GlusterFS 和对象存储

GlusterFS 是目前做得最好的分布式存储系统之一,而且已经开始商业化运行。但是,目前 GlusterFS3.2.5 版本还不支持对象存储。如果要实现海量存储,那么 GlusterFS 需要用对象存储。值得高兴的是,GlusterFS 最近宣布要支持对象存储。它使用 openstack 的对象存储系统 swift 的上层 PUT、GET 等接口,支持对象存储。

 

20 世纪电子与信息技术迅速发展,机器计算迅速普及,冯·诺依曼在 1945 年 6 月 30 日,提出了存储程序逻辑架构,即现有的计算机都遵循的“冯·诺依曼体系架构。

 

冯诺依曼体系结构与人脑(生物)计算模型匹配度相当准确。我们通常把运算器和控制器合并成中央处理器(CPU),内部小容量的存储提供快速的访问,外部存储器提供大容量的存储空间。在不同的计算机时代,我们可以按照不同的角度来理解冯诺依曼体系结构。在单机计算时代(包括大型机、小型机、微机)内部存储器可理解为内存(即 Memory),外部存储器可理解为物理硬盘(包括本地硬盘和通过网络映射的逻辑卷)。在本地硬盘空间不足,可靠性无法满足业务需求的情况下,SAN 存储出现了,通过网络映射的逻辑卷(即 SAN 存储提供的 LUN)成为增强版的硬盘。为了解决数据共享的问题,NAS 存储随之诞生。

 


但冯诺依曼体系架构没有考虑并行计算和数据共享情形,在如今的网络时代,大量计算设备通过网络形成一个庞大、相互独立但又逻辑统一的计算系统,因此我们可以总结出一个数据存储的通用模型,这个模型包括两级存储,其存储容量差距约 1000 倍:

 

如果将上图中每一个计算模块理解为一个计算内核,那么高速存储单元则是 CPU 内的缓存(单位为 KB~MB),海量存储单元则是内存(单位为 GB);如果把每一个计算模块理解为一个 CPU,那么高速存储单元则是内存(单位为 GB~TB),海量存储是物理硬盘或通过网络映射给服务器的逻辑卷(或网络文件系统,单位为 TB~PB);如果把计算模块理解为针对某一项任务或某一组任务提供计算能力的服务器集群,把 SAN 或 NAS 等拥有 TB~PB 级存储规模的网络存储设备理解为高速存储单元,那么具备 PB~EB 级存储容量的海量存储单元将基于什么技术和产品构建呢?

 

SAN 和 NAS 技术已经出现了数十年,目前单台 SAN 或 NAS 设备最大容量已经达到 PB 级别,但在应对 EB 级数据挑战时,还是显得有些力不从心。这主要由于其架构和服务接口决定的。

 

SAN 使用 SCSI 协议作为底层协议,SCSI 协议管理的粒度非常小,通常以字节(byte)或千字节(KB)为单位;同时 SCSI 协议没有提供读写锁机制以确保不同应用并发读写时的数据一致性,因此难以实现 EB 级存储资源管理和多个服务器 / 服务器集群之间数据共享。

 

NAS 使用文件协议访问数据,通过文件协议存储设备能够准确识别数据内容,并提供了非常丰富的文件访问接口,包括复杂的目录 / 文件的读写锁。文件和目录采用树形结构管理,每个节点使用一种叫做 inode 的结构进行管理,每一个目录和文件都对应一个 iNode。目录深度或同一目录下的子节点数随着整体文件数量的增加而快速增加,通常文件数量超过亿级时,文件系统复杂的锁机制及频繁的元数据访问将极大降低系统的整体性能。

 

传统的 RAID 技术和 Scale-up 架构也阻止了传统的 SAN 和 NAS 成为 EB 级高可用,高性能的海量存储单元。传统的 RAID 基于硬盘,通常一个 RAID 组最多包含 20+块硬盘,即使 PB 级规模的 SAN 或 NAS 也将被分割成多个存储孤岛,增加了 EB 级规模应用场景下的管理复杂度;同时 Scale-up 架构决定了即使 SAN 和 NAS 存储容量达到 EB 级,性能也将成为木桶的短板。

 

那么如何才能应对信息爆炸时代的数据洪流呢?我们设想能否有一种“超级数据图书馆”,它提供海量的、可共享的存储空间给很多用户(服务器 / 服务器集群)使用,提供超大的存储容量,其存储容量规模千倍于当前的高速存储单元(SAN 和 NAS),用户或应用访问数据时无需知道图书馆对这些书如何摆放和管理(布局管理),只需要提供唯一编号(ID)就可以获取到这本书的内容(数据)。如果某一本书变得老旧残破,系统自动地将即将失效或已经失效的书页(存储介质)上的数据抄写(恢复 / 重构)到新的纸张(存储介质)上,并重新装订这本书,数据使用者无需关注这一过程,只是根据需要去获取数据资源。这种“超级数据图书馆”是否真的存在呢?

 


二、分布式对象存储的诞生

对象存储技术的出现和大量自动化管理技术的产生,使得“超级数据图书馆”不再是人类遥不可及的梦想。对象存储系统(Object-Based Storage System)改进了 SAN 和 NAS 存储的劣势,保留了 NAS 的数据共享等优势,通过高级的抽象接口替代了 SCSI 存储块和文件访问接口(不同地区的用户访问不同的 POSIX 文件系统,不仅浪费时间,而且让运维管理变的更复杂。相对而言,分布式存储系统的优势明显。在分布式存储系统上做应用开发更便利,易维护和扩容,自动负载平衡。以 RESTful HTTP 接口代替了 POSIX 接口和 QEMU Driver 接口),屏蔽了存储底层的实现细节,将 NAS 垂直的树形结构改变成平等的扁平结构,从而提高了扩展性、增强了可靠性、具备了平台无关性等重要存储特性。(Erasure Code: 是将文件转换成一个碎片集合,每一个碎片很小,碎片被打散分布到一组服务器资源池里。只要存留的碎片数量足够,就可以合成为原本的文件。这可以在保持原本的数据健壮性的基础上大大减少需要的存储空间。不过 Erasure Code 并非适应所有的场景,尤其不适合网络延迟敏感的业务( 不过 Erasure Code 并非适应所有的场景,尤其不适合网络延迟敏感的业务))

 

SNIA(网络存储工业协会)定义的对象存储设备是这样的:

对象是自完备的,包含元数据、数据和属性

存储设备可以自行决定对象的具体存储位置和数据的分布

存储设备可以对不同的对象提供不同的 QoS

对象存储设备相对于块设备有更高的“智能”,上层通过对象 ID 来访问对象,而无需了解对象的具体空间分布情况

换句话说对象存储是智能化、封装得更好的块,是“文件”或其他应用级逻辑结构的组成部分,文件与对象的对应关系由上层直接控制,对象存储设备本身也可能是个分布式的系统——这就是分布式对象存储系统了。

 

用对象替代传统的块的好处在于对象的内容本身来自应用,其具有内在的联系,具有“原子性”,因此可以做到:

在存储层进行更智能的空间管理

内容相关的数据预取和缓存

可靠的多用户共享访问

对象级别的安全性

 

同时,对象存储架构还具有更好的可伸缩性。一个对象除了 ID 和用户数据外,还包含了属主、时间、大小、位置等源数据信息,权限等预定义属性,乃至很多自定义属性。

 

具备 EB 级规模扩展性的分布式对象存储,通过对应用提供统一的命名空间,构建 EB 级统一、可共享数据的存储资源池,有效地填补上述通用计算模型中“网络计算”场景海量存储单元空白,通过高层次的数据模型抽象,可以简化应用对数据访问,同时使得海量存储更加智能。

 

对象是数据和自描述信息的集合,是在磁盘上存储的基本单元。对象存储通过简化数据的组织形式(如将树形的“目录”和“文件”替换为扁平化的“ID”与“对象”)、降低协议与接口的复杂度(如简化复杂的锁机制,确保最终一致性),从而提高系统的扩展性以应对信息爆炸时代海量数据的挑战。同时对象的智能自管理功能也能有效降低系统维护复杂度,帮助用户降低整体拥有成本(TCO)。