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

Question

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

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

所有构建节点都有一个本地 SSATE_DIR，它们在其中缓存构建结果。其中一个构建节点（第一个 Jenkins 代理）被指定为“全局缓存的守护者”，并将其本地 SSTATE_DIR 导出为 ar/o NFS 共享。其他构建节点安装它，并在其构建配置中通过 SSATE_MIRRORS 引用它。我想我有一个非常好的主意，并拍拍自己的背。

唉，我发现进行更改后构建时间显着增加。

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

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

Answer 1

很难准确地说出您在某些分析数据中看到了什么问题，但我有一些观察和建议。

使用 NFS 作为 CI 节点之间的状态缓存是正确的做法，但我建议更进一步。我建议每个节点直接将一个公共 NFS 共享挂载为SSTATE_DIR. 这允许所有节点在构建期间读取和写入缓存，并更好地使其与所需的状态对象保持同步。如果只有一个节点填充缓存，则它不太可能包含其他构建所需的所有对象。

此外，我建议 NFS 服务器成为持久服务器，而不是绑定到 Jenkins 代理。这会给你带来一些好处：

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

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