在繁忙的构建节点上通过 NFS 托管 Yocto SSTATE_MIRROR - 一个坏主意？

如何解决在繁忙的构建节点上通过 NFS 托管 Yocto SSTATE_MIRROR - 一个坏主意？

在分布式 yocto 构建环境中，通过 NFS 在繁忙的构建节点上托管全局状态缓存（通过 SSTATE_MIRRORS）是一个坏主意吗？

我最近在我们的 yocto 构建配置中引入了 SSTATE_MIRRORS，以尝试进一步减少我们的“构建节点”（vSphere 中的 Jenkins 代理和开发人员工作站）上的 yocto 构建时间。根据 the manual，如果在本地 sstate 缓存 (SSTATE_DIR) 中找不到已构建的工件，yocto 将在 SSTATE_MIRRORS 中搜索它们。

所有构建节点都有一个本地 SSTATE_DIR，它们在其中缓存构建结果。其中一个构建节点（第一个 Jenkins 代理）被指定为“全局缓存的守护者”，并将其本地 SSTATE_DIR 作为 r/o NFS 共享导出。其他构建节点安装它，并在它们的构建配置中通过 SSTATE_MIRRORS 引用它。我以为我在这里有了一个很好的主意，于是拍拍自己的后背。

唉，我看到在进行更改后构建时间显着增加。

当然，在得出任何结论之前，我有很多故障排除和测量工作要做。我们正在使用 NFS v4，并且肯定会在那里进行调整。此外，我怀疑托管 NFS 共享的构建节点间歇性地非常忙于执行 yocto 构建本身（填充其混合本地/全局缓存），留给内核管理 NFS 请求的 CPU 周期很少。

我想知道其他人是否可以根据他们实施共享 yocto 状态缓存的经验提供建议。

解决方法

很难确切地说出您在使用某些分析数据时发现了什么问题，但我有一些观察和建议。

您使用 NFS 作为 CI 节点之间的 sstate 缓存是正​​确的，但我建议更进一步。与其让一个节点成为 sstate 缓存的“守护者”并将所有其他节点用作镜像，我建议让每个节点直接将公共 NFS 共享挂载为 SSTATE_DIR。这允许所有节点在它们的构建期间读取和写入缓存，并且在保持它与所需的 sstate 对象保持同步方面做得更好。如果您只有一个节点填充缓存，则它不太可能包含其他构建所需的所有对象。

此外，我建议 NFS 服务器是一个持久服务器，而不是绑定到 Jenkins 代理。这会让您受益匪浅：

1. 这意味着您可以将硬件资源专用于缓存，而不会让它们与正在进行的 Jenkins 构建竞争
2. 您可以放置​​一个简单的 HTTP 服务器前端来提供缓存文件。这样做允许您的开发人员工作站将该 HTTP 服务器设置为其 SSTATE_MIRROR，从而直接受益于您的 Jenkins 节点生成的缓存。如果您正确地完成了此操作，开发人员应该能够完全从 sstate 复制以前由 Jenkins 构建的构建，这可以节省吨的本地构建时间。即使您没有完全复制 Jenkins 之前完成的构建，您通常仍然可以从 sstate 中提取大量数据。

最后要检查的是您是否启用了哈希等效。哈希等效是一种构建加速技术，它允许 bitbake 检测元数据何时更改到通常会导致它重建的配方将导致与先前构建的 sstate 对象相同的输出，而不是构建它从 sstate 恢复它。从 Yocto 3.0（代号 zeus）开始，此功能默认启用。如果您的基础架构中没有运行哈希等效服务器，bitbake 将在您的构建期间启动本地服务器。但是，在像 Jenkins 节点这样的分布式环境中工作时，这可能会导致一些问题，因为哈希等效性高度依赖于 sstate 缓存的内容。如果每个节点都在本地运行它自己的哈希等效服务器，它们可能会获得不同的 sstate 哈希（特别是当 CI 节点是瞬态的并且本地哈希等效数据库丢失时），这可能导致更多的 sstate 未命中，这是必要的。对此的解决方案是运行一个哈希等效服务器（bitbake 附带一个）并将所有 CI 节点指向它，或者通过设置完全禁用哈希等效：BB_SIGNATURE_HANDLER = "OEBasicHash"。