多个客户端抢夺命名管道_Lustre客户端持久高速缓存设计与实现（一）

前言

近年来CPU与低速的机械磁盘性能差异越来越大，高速存储设备(如SSD，NVMe，SCM等)对减缓这种差距有一定帮助。但根据最新的HPC调查，出于存储容量和价格因素，很少有HPC数据中心将所有的生产数据全部保存于高速存储设备中，大量数据仍然存储在低速HDD类型磁盘中。

大多数HPC中心一般通过并行文件系统(如Lustre或GPFS)来提供一个全局的存储服务。计算节点一般作为并行文件系统客户端形式存在，并通常配置有内置的高速存储设备如SSDs/NVMe。研究者对如何将计算节点内置的快速存储设备整合到HPC存储层次栈有着浓厚的兴趣。Lustre的LOD(Lustre on Demand)提供了一种基于客户端内置存储设备构建的按需(on-demand)文件系统服务。这种解决方案的缺点是它作为一个独立的文件系统存在，与HPC数据中心全局并行文件系统没有关联，没有提供一个单一的命名空间，与共享并行文件系统相比，缺乏灵活性。

Lustre客户端持久高速缓存(PCC, Persistent Client Cache)技术整合了计算节点本地存储，在Lustre客户端提供了一个读写缓冲层，并保持维护了一个统一的全局命名空间。PCC在客户端节点为用户提供缓存服务，它有两种工作模式：

• RW-PCC读写模式：利用客户端本地存储设备，为单一客户端节点提供读写缓冲服务；

• RO-PCC只读模式：利用客户端本地存储设备，为多个客户端节点提供只读缓冲服务；

Lustre客户端持久高速缓存技术有如下优点：

• 对作为PCC后端存储的客户端内置设备无特殊要求。从高速的存储设备NVMe/SSD到低速HDD都可以使用。一般只需要将客户端内置设备格式化为一个本地文件系统(如Ext4或者xfs)，即可作为PCC后端使用。

• 简化了客户端I/O堆栈。在客户端就可以直接访问缓存在PCC中的数据，避免了从客户端到服务器冗长的数据IO路径。

• 不同客户端IO之间没有相互影响，更容易进行优化。

• 减轻了OST IO负载的压力。小的I/O和随机I/O可以规整为大的顺序I/O；零时文件可以直接在客户端删除，不需要刷新到OSTs。

• 降低了应用的I/O开销，大大减少了网络延迟和锁冲突。

Lustre 布局锁和分级存储机制

Lustre客户端一般不使用任何的本地存储，而PCC使得Lustre可以充分利用客户端本地存储，提供优化的IO缓存服务。PCC的核心实现依赖于Lustre客户端IO模型。它过滤Lustre数据I/O操作，将I/O重定向到客户单本地的PCC后端文件系统。PCC使用DLM布局锁(layout lock)来保护缓存的一致性和有效性。RW-PCC还是用分级存储(HSM)进行数据同步。下面将分别介绍Lustre布局锁和Lustre HSM体系结构。

Lustre布局锁

Lustre使用分布式锁管理器(DLM)来保护数据和元数据的一致性。Lustre文件对象的布局描述了如何在OST上分布文件数据。文件对象的布局属性以元数据对象的扩展属性形式保存在元数据服务器(MDT)上。在布局锁的保护下，可以将文件布局属性缓存到客户端上以加速后续的IO，而不需要每次IO都重新获取布局锁。缓存在客户端锁命名空间的布局锁在任何时候都可以撤销，其保护的文件布局属性可能在布局锁撤销的过程中被改变，即使此时文件被打开正在进行IO。当要改变文件布局时，Lustre元数据服务器(MDS)必须持有针对此文件的独占模式(EX)布局锁，并且必须通知所有持有并发读取模式(CR)布局锁的客户端，以使其缓存的布局无效。当发生这种情况，客户端必须重新获取布局锁配置布局，之后才能继续对文件执行I/O操作。当更改MDT上某个对象的布局属性时，布局属性数据结构L中的成员字段L.Gen将会增加。当客户端某个文件对象的布局锁由于某种原因被撤销时，需要将缓存布局属性的L.Gen字段设置为无效值，以表明该对象的缓存布局在客户端上是无效。在IO启动之前，客户端必须确保对象的布局是有效。它首先检查客户端内存中锁命名空间中是否缓存有相匹配的有效的布局锁；如果没有找到匹配的缓存的布局锁，它必须从MDT中获取CR模式布局锁并更新有效布局。此过程称为布局刷新。布局锁通常在open或getattr的RPC调用过程中捎带回客户端。通过这种优化，如果没有锁竞争，就不会为额外的专门获取布局锁而产生额外的RPC开销；否则的话，则需要MDT显式请求布局锁，并将对象的布局返回给客户端。

Lustre分级存储机制

Lustre为HSM分层存储提供了一套框架。在Lustre分级存储解决方案中，文件数据保存于HSM后端存储中，但仍在Lustre中保留一个元数据存根项。对数据的任何访问如读取/写入/截断操作都会触发将文件数据从HSM后端存储设备恢复到Lustre文件系统中。

Lustre HSM体系结构如上图所示。将文件数据复制到HSM存储中的过程称为归档(archive)；归档步骤完成后，可以删除位于Lustre OSTs的文件数据，即释放(release)过程；将数据从HSM存储返回Lustre文件系统OSTs的过程称为恢复(restore)。

归档和恢复操作需要一个称为代理(agent)的Lustre文件系统组件，它本身是一个Lustre客户端节点。在代理节点上运行着一个称为copytool的用户态守护程序，通过它来协调Lustre文件系统和HSM后端存储之间的归档和恢复操作。元数据服务器运行着一个名为HSM协调器(coordinator)的附加进程。协调器负责接收，排队和分派HSM请求。HSM请求是由Lustre客户端提交的，提交方式可以是通过执行相应的命令行命令，也可以通过称为策略引擎的专用的第三方应用程序。策略引擎使用Lustre HSM API与HSM协调者进行交互。

Lustre的HSM功能通常用于在可用容量不足的情况下从OST释放较旧、使用频率较低的文件。应用程序不知道文件数据的具体位置：到底是位于HSM归档并已释放，还是位于Lustre OSTs。从应用程序的角度来看，它使用相同的系统调用访问文件，应用程序不需要重新编写，就可以处理位于HSM系统中存储的数据。当应用程序通过文件相关的系统调用打开并读写归档于HSM并已释放的文件，Lustre HSM机制会自动触发恢复过程，将该文件的数据从归档还原到Lustre文件系统。虽然它会增加文件访问的延迟，但在其他方面对应用程序是透明的。

Lustre读写模式客户端持久缓存

在Lustre HSM分级存储解决方案中，在相对较慢的HSM存储面前，Lustre通常充当高速存储层次。与之相反的是，RW-PCC实际上是一个HSM后端存储系统，它在Lustre客户端上提供一套相对高速本地缓存机制。上图显示了RW-PCC体系结构。每个客户端有自己的本地存储设备，一般为SSD或NVMe设备，格式化为本地文件系统作为PCC分级存储后端。在RW-PCC中，已缓存文件的I/O定向到本地的PCC后端文件系统，而正常的I/O定向到Lustre OSTs。

RW-PCC使用Lustre的HSM机制进行数据同步。每个PCC节点实际上都是一个HSM代理(agent)，并在其上运行一个copytool实例。Lustre HSM copytool用于将文件从本地PCC缓存副本还原(restore)到Lustre OSTs。任何远程客户端对本地PCC缓存文件的访问都会触发此类数据同步。如果配置有PCC持久缓存的客户端脱机，其他客户端可能暂时无法访问缓存的数据。但是当PCC客户端重启以及copytool重新启动后，位于PCC中的数据将再次变得可访问。上图就展示了一个配备有PCC客户端持久缓存的Lustre集群配置实例。目前，在Lustre HSM机制中数据归档时必须归档整个文件范围的数据，不能仅归档文件部分范围的数据。因此，PCC客户端在预取数据到PCC中时也必须缓存整个文件。这为客户提供了一定程度的弹性。一旦文件被缓存并打开，理论上它就不会受到服务器和网络故障的影响。因此，理论上PCC可以支持类似于Coda文件系统的断连操作(disconnect operations)。

RW-PCC文件预取(attach)

在缓冲文件之前，首先必须先将文件预取(attach)到PCC中，之后文件后续的I/O将定向到客户端持久缓存。PCC通过Lustre布局锁特性确保缓存服务与全局文件系统状态一致。上图显示了RW-PCC的attach流程。在文件预取到PCC之前，通常已经在MDT上创建了一个要预取的常规文件的元数据对象。首先客户端尝试使用租约锁(lease lock)以独占方式打开文件。如果文件的打开计数大于1，则调用将返回-EBUSY，而成功的租约打开将确保当前attach进程是文件的唯一打开进程。获取租约后，将使用文件的唯一标志符FID按照Lustre HSM命名规则在本地LPCC缓存上创建一个空镜像文件，然后将文件数据从OSTs复制到PCC。之后，客户端使用PCC attach意图关闭文件。MDS接收到带有意图的关闭请求时，它将获取EX模式的布局锁，然后释放Lustre OST上的文件数据对象。同时，将MDT上Lustre文件置为HSM存档(archive)已释放(released)状态。同时，在布局属性中一个名为L.released的标志字段置为1，指示文件对象是处于HSM released状态(即文件位于Lustre OSTs的数据被删除)，并增加L.Gen字段以反映布局更改。MDS随后将释放布局锁，并在关闭请求的回复中捎带L.Gen值返回给客户端。客户端缓存文件的索引节点的扩展私有数据结构有一个名为PCCI.LayoutGen的结构成员用于保存返回的L.Gen。其值受缓存于客户端锁命名空间的文件的布局锁保护。在文件预取(attach)成功之后，可以将文件数据直接写入/读取到本地PCC缓存。如果预取不成功，客户机将返回到正常的I/O路径，并将I/O定向到OSTs。

RW-PCC文件数据恢复(restore)

当其他客户端上的进程试图读取或修改RW-PCC缓存文件时，数据还原过程会通过HSM机制自动触发，它将恢复文件数据到Lustre OSTs中去。此时，远程客户端访问的I/O将阻止直到被HSM释放的文件数据被还原。这整个过程是对应用都是透明的。上图显示了RW-PCC的数据恢复流程。

当I/O启动时，客户端先要检查文件是否被HSM释放(released)。如果是，它需要先还原文件然后重新启动I/O。首先，客户端会向MDT协调器(coordinator)发送一个HSM还原请求。然后，协调器获取EX 模式的布局锁，并通知已获取CR模式布局锁并缓存布局的所有客户端将其缓存的布局置为无效。对于缓存于PCC中的文件，在锁撤销期间客户端还需要将PCCI.LayoutGen置为无效置，并等待PCC上此文件的所有活跃I/O的完成。协调器在获取EX布局锁后，将创建并保存一个HSM restore请求记录，之后便向客户端发送回复。HSM请求记录由协调守护线程处理。HSM还原本身的工作方式如下：协调器将还原请求发送到PCC客户端上的相应代理(agent)。然后，代理上的copytool将创建一个零时的Lustre文件，并将数据从PCC文件副本复制到Lustre零时文件中。然后，它将零时的Lustre文件的FID发送给MDT协调器。协调者在收到回复后，将零时Lustre文件和被还原文件之间进行布局交互，之后删除零时文件，增加原文件的L.Gen，最后释放先前获得的布局锁以完成数据还原过程。最初访问文件的客户端在收到MDT的回复消息后将重新启动I/O。在此过程中，它必须先重新获取布局锁(CR模式)并刷新布局，然后才能进行后续的I/O操作。在MDT协调器完成文件恢复过程释放EX布局锁之前，刷新布局过程将将一直被阻塞。当客户端成功刷新并重新配置布局后，将按照正常I/O路径重新执行I/O，将I/O定向到Lustre OSTs。

RW-PCC容错处理

RW-PCC是无阻塞。布局锁的撤销会自动将文件从PCC缓存中分离(detach)。RW-PCC缓存文件也可以通过detach命令手动分离，该命令只需使缓存的文件对象的PCCI.LayoutGen置为无效值即可。当缓存文件从PCC分离并还原到Lustre OSTs后，可以从PCC中安全的将它删除。

失败的RW-PCC I/O访问操作通常会返回相应的错误代码。但是有一种特殊的情况，当文件写入操作超过本地PCC文件系统的容量(-ENOSPC)或配额限制(-EDUOT)时，由于全局Lustre文件系统的容量远远大于PCC后端设备的容量，RW-PCC可以返回到正常的I/O路径，将数据还原到Lustre OSTs，然后进行I/O重试重新执行I/O。此时，I/O一般按照正常的Lustre OSTs I/O路径执行。当客户端出现故障，存储在客户端上的数据变得(暂时)不可用。在这种情况下，PCC给出了两个互补的解决方案建议。简单的解决方案是等到暂时无法访问的客户端重启，HSM copytool重新启动。如果PCC上的数据没有因为硬件故障而丢失，那么就可以立即进行数据访问。当文件预取到PCC时，用户还可以选择不释放位于Lustre OSTs上文件数据对象。此时，当客户端发生永久性故障时，可以简单地将存储在Lustre OSTs上的数据作为丢失文件的备份来使用。另外，可以通过类似于FLR (File Level Redundance)的机制在PCC的文件副本和存储在Lustre OST上的文件数据备份之间定期进行同步数据来减少发生故障时数据的损失，但此功能还未实现。

总结

本文首先对Lustre布局锁和分级存储机制原理进行了分析。然后对基于这两个特性实现的RW-PCC的设计和实现进行详细的介绍，使大家对Lustre客户端持久缓存机制有了一个初步的了解。后续系列文章将继续介绍只读模式RO-PCC的设计原理和实现以及缓存机制必须解决的一个问题即缓存的预取和淘汰策略。敬请大家关注。