DAOS系统架构-Container

1. 概述

一个DAOS容器表示存储池中的一个对象地址空间，并且由UUID标识。为了访问一个DAOS容器，一个应用程序必须首先要和存储池建立连接，然后创建或者打开DAOS容器。如果这个应用程序被授权可以访问该DAOS容器以及其内容，它将会获取到一个DAOS容器句柄。DAOS容器句柄可以允许应用程序中任何一个进程访问该容器以及其内容。任何打开了DAOS容器的进程都可以与其他对等（peering）的进程共享此容器句柄,当关闭DAOS容器句柄时，这种共享能力都会被取消。

 

2. 元数据布局

DAOS容器服务（cont_svc）负责存储容器的元数据，并提供API来查询和更新状态以及管理容器的生命周期。DAOS容器的元数据被组织成key-value的存储结构（KVS），然后在某些服务器上做副本。其中某些服务器是由Raft共识算法选举出的。客户端请求只能由leader服务处理，所以非leader服务需要将客户端请求重定向给leader服务。cont_svc是从rsvc模块中派生出来的。

从上图可以看到，在最顶层KVS设计（root）中包含2个子KVS设计：DAOS容器KVS和DAOS容器句柄KVS。

• DAOS容器KVS：用于存储容器的元数据，该元数据由许多可变和不可变标量以及其他KVS组成。这些属性是由用户在创建一个容器时提供的。
• DAOS容器句柄KVS：用于存储由各种应用程序打开的DAOS容器句柄相关的元数据。DAOS容器句柄由UUID进行索引，UUID是由客户端在打开容器时生成的。与容器句柄相关联的元数据包括容器句柄的能力（比如：只读或者读写）以及每个容器句柄的epoch状态。当关闭某个容器时，该容器句柄相关的元数据条目也从KVS中删除。

另外，用户可以创建创建、删除和检索一个持久化快照列表，这些快照的本质实际上是一些epochs，并且这些epochs是不会被聚合的。一个快照在被显示的销毁之前仍然保留可读的。DAOS容器也可以回滚到特定的快照。

用户还可以为DAOS容器定义自定义属性，这些属性本质上是name-value键值对。其中name是一个字符串，value是一个任意字节序列。DAOS容器服务允许客户端一次检索和更新多个属性，以及列出属性的名字。

 

3. Target服务

上文提到，DOAS容器代表存储池中的一个对象地址空间，而这个对象地址空间是全局的。Target服务会将这个全局的对象地址空间映射到本地的对象地址空间（本地的对象存储空间是target的VOS存储池中的，代表一个VOS容器）。然后，Target服务会代表DAOS容器服务来调用VOS方法。Target服务会将关于每个线程的信息（包含所有的容器对象以及所有打开的句柄）缓存在内存中以供访问。

3.1. Target故障

假设集群中有成千上万的target的，当某个或者某些target发生故障时，必须允许epoch协议依然能够进行。由于存储池服务和容器服务都是高可用的，所以问题主要与target服务有关。基于以下假设提供一个解决方案：丢失一些targets不会引起应用程序丢失，因为DAOS-SR层可能会创建足够的冗余来向应用程序隐藏故障。此外，应用程序甚至可能想要忽略特定的数据丢失（DAOS-SR层无法隐藏），因为它有足够的应用程序级冗余来应对，或者它根本不在乎。

当出现当写入、刷新或丢弃操作失败时，DAOS-SR层会计算是否有足够的冗余来继续执行epoch。如果这个失败可以被隐藏，并且假设与此操作相关的target在存储池中没有被禁用，那么DAOS-SR层会在提交epoch之前禁用该target。对于epoch协议而言，由此产生的存储池map更新实际上记录了这样一个事实，即target可能在某个时期存储一组未定义的写入操作，而这种情况应该被避免。这也适应于那些希望忽略类似DAOS-SR层无法隐藏的故障的应用程序。

3.2. Object ID分配器

OID分配器是一个个常规的helper服务，它允许用户在容器中分配一组唯一的64位无符号整数。这对于那些无法以可扩展方式轻松的分配一个DAOS对象ID的应用程序或者中间件而言是非常有用的。在DAOS容器的属性KVS中会跟踪可分配的最大的ID，目的是为了将来可以访问该容器。该helper服务不保证分配的ID是连续的，并且某些ID范围可能在容器关闭时被丢弃。

分配器是使用服务器端的Incast Variable实现的，该变量会跟踪一个容器中已经使用的最高（相对IV树而言）的object ID。一个客户端可以从任何一个运行Target服务的服务器上请求一个新的分配。当新请求到达时，服务器会检查本地是否还有可用的object ID。如果没有，他会将请求转发给父级（在这种情况下，会请求更大范围的OID）。父级执行相同的检查并继续转发到其父级，直到满足请求或者达到IV树的顶端，此时IV树的根节点会更新Incast Variable的值，也就是最大的OID。在IV树的每一层，所申请的OID数量都会增加，以便能够更快地满足未来OID分配请求。

 

4. DAOS容器操作

为了创建一个新的DAOS容器，客户端需要向DAOS容器服务发送一个带有存储池句柄和一个UUID的CONT_CREATE请求。客户端必须首先与存储池建立连接才能获取到存储池句柄。另外，请求中也可以包含一个关于创建容器相关的属性列表，用来设置新建的容器。作为响应，DAOS容器服务会创建一个对应的容器属性KVS，并以UUID作为KVS的建。创建容器的过程不需要Target服务的参与。

客户端现在可以通过提供一些必要的条件（比如：已经打开的存储池的句柄、容器的UUID以及某些标志（比如read-only或者read-write））来打开一个DAOS容器。客户端库会使用本地生生成的UUID向DAOS容器服务发送一个CONT_OPEN请求，然后使用IV（Incast Variable）将容器句柄异步地广播到存储池中所有已启用地targets。成功完成之后，它会在容器句柄KVS中创建一个新的条目。

客户端可以通过DAOS容器服务发送CONT_CLOSE请求来关闭不再需要的容器句柄，然后，DAOS容器服务会向到存储池中所有已启用地targets发送一个广播地CONT_TGT_CLOSE请求，目的是为了关闭DAOS容器句柄。最后，会从容器句柄KVS中删除相关地条目，并丢弃在该容器句柄上执行地未提交地更新。

当客户端向DAOS容器服务发送一个CONT_DESTROY请求时，容器会被销毁，进而会导致清除该容器相关地所有地元数据。同样，所有的target会接收到来自DAOS容器服务的CONT_TGT_DESTROY请求，并删除与该容器相关联的所有数据，包括该容器中所有的对象。客户端可以选择轻质销毁容器，以防止该容器具有已经打开的句柄。

4.1. Epoch 协议

epoch协议实现了事务模型中描述的epoch模型。容器的epochs由DAOS容器服务管理，epoch的状态也是由DAOS容器维护。epoch的状态会作为容器元数据的一部分。然而，target服务对全局的epoch状态是知之甚少。因此，epoch commit、discard 和 aggregate 过程都由容器服务驱动。

在每个target上，target服务会急切地将传入的写入作存储到匹配的VOS容器中。如果容器句柄丢弃一个epoch，则 VOS会帮助丢弃与该容器句柄关联的所有写入作。当写入操作成功后，他会立即对相等或者更高的epoch中的冲突操作可见。具有相同epoch的冲突写入作将被VOS拒绝，除非它与相同的容器句柄关联并且与已执行的写入作具有相同的内容。

在提交epoch之前，应用程序必须确保该epoch的写入操作集合被持久化在target服务上。应用程序可能会决定丢弃一些写入作，这是可以接受的，具体取决于它们各自采用的冗余方案。提交一个容器句柄的epoch会触发向相应的容器服务发送一个CONT_EPOCH_COMMIT请求，该服务会简单的更新元数据。当更新变为持久化时，容器服务会使用新的 epoch 状态回复客户端。