OpenStack的架构详解(10)

5.2 Object Storage如何工作

a) Ring

Ring 代表磁盘上存储的实体的名称和它们的物理位置的映射。accounts, containers, and objects都有单独的Ring。其他组件要在这三者之一进行任何操作，他们都需要合相应的Ring进行交互以确定它在集群中的位置。

Ring用zones，devices，partitions，和replicas来维护映射，在Ring中的每个分区都会在集群中默认有三个副本。分区的位置存储在Ring维护的映射中。Ring也负责确定失败场景中接替的设备。(这点类似HDFS副本的复制)。分区的副本要保证存储在不同的zone。Ring的分区分布在OpenStack Object Storage installation所有设备中。分区需要移动的时候，Ring确保一次移动最少的分区，一次仅有一个分区的副本被移动。

权重能用来平衡分区在磁盘驱动上的分布。Ring在代理服务器和一些背景进程中使用。

b) Proxy Server

代理服务器负责将OpenStack Object Storage架构中其他部分结合在一起。对于每次请求，它都查询在Ring中查询account, container, or object的位置，并以此转发请求。公有APIs也是通过代理服务器来暴露的。

大量的失败也是由代理服务器来进行处理。比如一个服务器不可用，它就会要求Ring来为它找下一个接替的服务器，并把请求转发到那里。

当对象流进或流出object server时，它们都通过代理服务器来流给用户，或者通过它从用户获取。代理服务器不会缓冲它们。

Proxy服务器的功能可以总结为：查询位置，处理失败，中转对象。

c) Object Server

Object Server，是非常简单的blob存储服务器，能存储、检索和删除本地磁盘上的对象，它以二进制文件形式存放在文件系统中，元数据以文件的扩展属性存放。

对象以源于对象名的hash和操作的时间戳的路径来存放。上一次写总会成功，确保最新的版本将被使用。删除也视作文件的一个版本：这确保删除的文件也被正确复制，更旧的把本不会因为失败情形离奇消失。

d) Container Server

其主要工作是处理对象列表，它不知道对象在哪里，只是知道哪些对象在一个特定的container。列表被存储为sqlite 数据库文件，类似对象的方式在集群中复制。也进行了跟踪统计，包括对象的总数，以及container中使用的总存储量。

e) Account Server

它是类似于Container Server，除了它是负责containers的列表而非对象。

f) Replication

设计副本的目的是，在面临网络中断或驱动失败等临时错误条件时，保持系统在一致的状态。

副本进程会比较本地的数据和每个远处的副本，以确保他们所有都包含最新的版本。对象副本用一个Hash列表来快速比较每个分区的片段，而containe和 account replication 用的是Hash和共享的高水印结合的方法。

副本的更新，是基于推送的。对于对象副本，更新是远程同步文件到Peer。Account和container replication通过HTTP or rsync把整个数据库文件推送遗失的记录。

副本也通过tombstone设置最新版本的方式，确保数据从系统中清除。

g) 更新器(Updaters)

有时，container 或 account数据不能被立即更新，这通常是发生在失败的情形或高负载时期。如果一个更新失败，该更新会在文件系统上本地排队，更新器将处理这些失败的更新。事件一致性窗口(eventual consistency window)最可能来起作用。比如，假设一个container服务器正处于载入之中，一个新对象正被放进系统，代理服务器一响应客户端成功，该对象就立即可读了。然而，container服务器没有更新Object列表，所以更新就进入队列，以等待稍后的更新。Container列表，因此可能还不会立即包含这个对象。

实际上，一致性窗口只是与updater运行的频率一样大，当代理服务器将转发清单请求到响应的第一个container服务器中，也许甚至还不会被注意。在载入之下的服务器可能还不是服务后续清单请求的那个。另外两个副本中的一个可能处理这个清单。

h) Auditors

Auditors会检查objects, containers, 和 accounts的完整性。如果发先损坏的文件，它将被隔离，好的副本将会取代这个坏的文件。如果发现其他的错误，它们会记入到日志中。