本文是 Rafael Keller Tesser 发表在 The Journal of Supercomputing 2023 上的综述。

Abstract: OS-level virtualization (containers) has become a popular alternative to hypervisor-based virtualization. From a system-administration point-of-view, containers enable support for user-defined software stacks, thus freeing users of restrictions imposed by the host’s pre-configured software environment. In high performance computing (HPC), containers inspire special interest due to their potentially low overheads on performance. Moreover, they also bring benefits in portability and scientific reproducibility. Despite the potential advantages, the adoption of containers in HPC has been relatively slow, mainly due to specific requirements of the field. These requirements gave rise to various HPC-focused container implementations. Besides unprivileged container execution, they offer different degrees of automation of system-specific optimizations, which are necessary for optimal performance. When we looked into the scientific literature on containers applied to HPC, we were unable to find an up-to-date overview of the state-of-the-art. For this reason, we developed this extensive survey, including 93 carefully selected works. Overall, based on our survey, we argue that issues related to performance overhead are mostly solved. There is, however, a clear trade-off between performance and portability, since optimal performance often depends on host-specific optimizations. A few works propose solutions to mitigate this issue, but there is still room for improvement. Besides, we found surprisingly few works that deal with portability between dedicated HPC systems and public cloud platforms.

Entry：Zotero link URL link

1. HPC应用有更高的依赖需求
   1. 应用本身变化大，需要依赖不同
   2. 大数据和AI领域的发展带来了更多依赖
   3. 因此容易出现依赖冲突、依赖安装复杂的困难
2. Docker并没有在HPC中广泛出现，因为
   1. Docker是为微服务设计的，过多关注环境隔离
   2. 容器执行是通过有管理员权限的守护进程实现的，有被提权的可能性
3. 应该具有以下性质：
   1. Secure implementation：容器不具备管理员权限，无法被提权
   2. Low performance overhead：高效运行
   3. Access to specialized hardware：与加速器和高速网络交互
   4. Access to specialized software：具备访问重用依赖的能力

Container for HPC：

1. Shifter：
   1. 容器非特权执行
   2. 提供docker image的转换
   3. 依靠MPI ABI兼容性将容器的MPI与主机的MPI连接起来，从而利用特定于主机的优化和高性能互连
   4. 集成Slurm
   5. 高效执行
   6. 可以自己配置，使用GPU
2. Singularity：
   1. 容器非特权执行
   2. 提供docker image的转换
   3. 原生支持高速网络互联
   4. 可以自己配置，使用GPU
   5. 通过挂载的形式，提供供应商优化软件
3. Charliecloud：
   1. 提供User Defined Software Stack  (UDSS)
   2. 依靠Linux的User Namespace来提供容器非特权执行
   3. 塞入自定义组件来提供加速器和网络、供应商优化软件的支持

Sections:

1. Communication overhead 容器能够提供接近本机的网络通信性能。但是，为此目的，必须将它们配置为提供从容器内部对网络硬件的直接访问。上面讨论的工作演示和评估了实现这一目标的各种解决方案。在大多数情况下，牺牲网络隔离来换取性能。这应该不是问题，因为这不是HPC的要求。事实上，专用的HPC系统通常允许应用程序在没有任何网络隔离的情况下运行。然而，需要注意的一个方面是，某些解决方案需要在容器内拥有系统特定库的副本。因此，在选择是否采用这种方法时，必须考虑可移植性的后果。

2. Storage overhead 容器技术可以实现与本机相当的存储(IO)性能。此外，与基于管理程序的虚拟机相比，它们具有显著的改进。然而，为了达到最佳性能，需要注意一些方面。其中之一是避免在Docker的覆盖文件系统(AUFS)上进行IO密集型操作。最好将主机目录挂载到容器中，可以作为卷挂载，也可以通过绑定挂载。另一个需要考虑的方面是映射到每个物理主机的容器数量。正如多次工作发现的那样，随着这个数字的增加，IO性能往往会下降，特别是对于小文件。

3. CPU overhead 容器能够执行基于cpu的应用程序，其计算性能与本机环境相似或相等。因此，它们对计算密集型应用程序的性能影响应该可以忽略不计。此外，不需要特殊的配置来达到最佳效果。因此，从CPU计算的角度来看，容器非常适合HPC。

4. GPU overhead 容器技术能够提供与本机环境相似的GPU计算性能。此外，在少数例外中，至少有一个是由于与容器(网络文件系统)无关的问题造成的。因此，我们可以得出结论，容器是执行依赖GPU加速器的应用程序的合适环境。

5. Memory Overhead 容器可以为封装的应用程序提供接近本机内存(RAM)的性能。尽管没有明确的原因说明容器会导致这种类型的开销，但是有一些实验测量了显著的开销。其中一个结果是由于增加STREAM线程数时L3缓存中的争用造成的。然而，目前尚不清楚，在容器内，什么会导致这个问题更加恶化。另一个工作遇到了LXC和Docker容器的重大开销，但Singularity没有。在这种情况下，Singularity的优势可能是由于其更宽松的默认配置。如果是这样，可以通过配置LXC和Docker的行为更类似于Singularity来提高它们的性能。

6. Overall application overhead

7. Other Overhead

8. Portability/Migration

9. Reproducibility

10. Unprivileged container execution

11. Survey or summary.

Last modified on 2023-11-16