如何实现对象存储?

随着计算机和通信技术的发展，人类产生和共享数据的速率呈指数级增长。如何有效的保存和管理这些数据是计算机存储技术首先要解决的问题。

很多人都听过对象存储这种说法，但是究竟什么是对象存储？对象存储如何实现呢？

除了对象存储，你可能还听说过文件存储(File Storage)和块存储(Block Storage)，我们把三者放在一起比较：

1. 文件存储 - 数据保存在文件中，按目录（文件夹）进行组织，当需要访问文件时，用户需要知道它完整的路径；

2. 块存储 - 块存储提供了文件存储的替代方案，它将文件分成大小相等的数据块，然后将数据块存储在唯一的地址。块存储可以提供比文件存储更好的性能；

3. 对象存储 - 对象存储不使用文件夹、目录或更复杂的层次结构，每个文件作为一个对象保存在扁平的命名空间中。

本质上，文件存储、块存储和对象存储是不同的数据访问形式，它们分别适合于不同类型的数据：

• 文件存储和块存储非常适合处理结构化数据；
  

• 对象存储适用于处理大量非结构化数据的数据。
  

今天的互联网通信数据很大程度上是非结构化的，包括电子邮件、视频、照片、网页、音频文件以及其他类型的媒体和Web内容。这些内容从社交媒体、搜索引擎、移动设备和“智能”设备源源不断地流出。

市场研究公司IDC估计，到2025年，非结构化数据可能占全球所有数据的80%。

基于对象的存储已成为数据归档和备份的首选方法，它可以提供传统基于文件或基于块的存储无法提供的可扩展性。

对象数据分为数据(data)和元数据(metadata)两部分，每个对象都有唯一的标识符(ID)，用于定位和访问对象。

对象存储系统提供基于HTTP的RESTful服务，用户通过HTTP命令访问对象存储，例如PUT或POST上传对象，GET检索对象，DELETE删除对象。

此外，还有其他RESTful API标准，允许用户管理对象存储、帐户、多租户、安全性、计费等。

基于对象的存储天然契合当前云原生领域蓬勃发展的趋势，是存储、归档、备份和管理大量静态或非结构化数据的理想解决方案。

一个功能完备的存储系统需要考虑数据的可用性、一致性和持久性，需要具备灾备和恢复能力，并且运维友好。

要把这些说清楚，大概需要“一千零一夜”，好在业界有不少成熟的方案，下面我们通过分析一些开源项目的架构来了解对象存储系统是如何实现的。

这些项目在其功能上不尽相同，但是都有相同的设计目标——实现非结构化数据的大规模存储。

如今作为对象存储协议，Swift很少被提及，而Amazon的S3已经成为业界的事实标准，每个对象存储系统都会提供与Amazon S3 RESTful API兼容的服务。

例如，OpenStack Swift除了提供自己的Swift Open API和一些独特的功能，还支持Amazon的S3 API；Ceph对象存储和Openio.io与S3兼容。

 >>> Ceph RADOS存储集 

OSD和Monitor之间互相传递节点的状态信息，共同得出系统的总体运行状态。

而根据集群总体运行状态，基于CRUSH算法，用户上传的数据经过层层映射，最终会送到不同的OSD上面：

• 用户上传的数据被切割为固定大小的分片；
  

• 根据规则，每个数据分片都有其唯一的ID，每个数据分片独立的映射到不同的逻辑归置组(PG)；

• 基于CRUSH算法，确定逻辑归置组锁对应的 OSD。

 >>> Ceph ObjectStore 

ObjectStore由不同的实现方式，有FileStore、BlueStore、MemStore等等。

其中MemStore主要用于测试目的。

FileStore基于Linux现有的文件系统，利用传统的文件系统操作实现ObjectStore API：每个Object被FileStore看做是一个文件，Object的属性会作为文件的属性(xattr)存取，而超出文件系统限制的属性会作为omap存储。

BlueStore去掉了journal，通过直接管理裸设备的方式来减少文件系统的部分开销。

和传统的文件系统一样，BlueStore由3个部分组成：数据管理、元数据管理、空间管理(Allocator)。

BlueStore不再基于本地文件系统，而是直接管理裸设备，为此在用户态实现了BlockDevice，使用Linux AIO直接对裸设备进行I/O操作，并实现了Allocator对裸设备进行空间管理。

BlueStore的元数据则以Key/Value的形式保存在KV数据库中，默认RocksDB。但RocksDB并不是基于裸设备进行操作的，而是基于文件系统进行操作的，为此BlueStore还实现了一个小的文件系 BlueFS。

* Ceph 的强一致性实现依赖于 RocksDB 提供的事务特性。

访问层的功能类似于网络设备中的 Hub，主要负责 RESTful 请求的处理与用户身份的认证。

存储层由一系列的物理存储节点组成，负责对象数据的存储。

为了对应这3个层次，每个Storage Node上运行了3种服务：

• Account Server - 提供Account相关服务，包括Container列表以及Account的元数据等。Account的信息被存储在一个SQLite数据库中；

• Container Server - 提供Container相关服务，包括Object列表以及Container的元数据。Conainer的信息也被存储在一个SQListe数据库中；

• Object Server - 提供Object的存取和元数据服务。对象的内容以二进制文件的形式存储在文件系统中，元数据作为文件的扩展属性来存储。

为了保证数据在某个存储硬件损坏的情况下也不会丢失，Swift为每个对象建立了一定数量的副本，默认为3，并将每个副本放在不同的逻辑区域中。

Swift通过3种服务来解决数据一致性问题：

• Auditor - 持续扫描磁盘检查Account、Container和Object的完整性，如果发现数据有损坏的情况，就会对文件进行隔离，然后通过Replicator从其他节点上获取对应的副本以恢复本地数据；
  

• Updater - 创建一个Container或者Object时，更新SQLite中相应的信息。更新并不总是成功，对于那些没有成功更新的操作Swift会通过Updater服务继续处理；

• Replicator - 负责检测各个节点上的数据及其副本是否一致，当发现不一致时会将过时的副本更新为最新版本，并负责将标记为删除的数据真正从物理介质上删除。

Swift 通过 Consistent Hash Ring 来实现对集群中物理节点的管理。

由于没有条带化，Swift处理几个G的大文件时性能会比较差，不过作为对象存储，Swift的优势在于它能与OpenStack社区的其他项目无缝结合。

但是本质上，所有的存储系统都在解决“数据如何保存”和“数据如何访问”的问题。尽管Ceph和OpenStack Swift出现已久，但是它们的设计仍值得借鉴。本文仅分析了Ceph和OpenStack Swift的宏观架构，感兴趣的朋友可以从文章末尾给出的参考链接中获取更多细节。

* Object Storage: Everything You Need to Know [https://lakefs.io/object-storage/]

* Amazon S3 REST API Introduction [https://docs.aws.amazon.com/AmazonS3/latest/API/Welcome.html]

* Linux 开源存储全栈详解 [https://book.douban.com/subject/34815557/]