Ben*_*Ben 17 mpi openmpi kubernetes
我想在我的Kubernetes集群上运行MPI作业.上下文是我实际上运行的是一个现代的,包装良好的容器化应用程序,但部分工作量是一个传统的MPI工作,不会很快重写,我想把它变成一个kubernetes"世界观"尽可能地.
最初的一个问题:是否有人在kube集群上运行MPI作业有任何成功?我见过Christian Kniep的工作是让MPI工作在Docker容器中运行,但是他正在沿着docker swarm路径(使用每个容器中运行的consul发现同行)并且我想坚持kubernetes(已经知道了所有同行)并从外部将此信息注入容器中.我完全可以控制应用程序的所有部分,例如,我可以选择使用哪个MPI实现.
关于如何继续,我有几个想法:
包含slurm和应用程序代码的胖容器 - >在容器启动时使用适当的信息填充slurm.conf - >使用srun作为容器入口点来启动作业
仅使用OpenMPI(无淤泥)的更轻薄的容器 - >使用外部信息(由kubernetes提供)在容器中填充rankfile - >使用mpirun作为容器入口点
更简洁的方法,我基本上通过设置一些环境变量(例如OpenMPI ORTE)来"伪造"MPI运行时 - >直接运行mpicc'd二进制文件(通过env vars可以找到它的同行) )
一些其他选择
绝望地放弃
我知道尝试将"已建立"的工作流程(如MPI)与kubernetes和容器的"新热点"混合起来有点阻抗不匹配,但我只是在寻找指针/陷阱之前我走得太远了.如果什么都不存在,我很乐意破解一些东西并将其推回上游.
假设您不想使用特定于硬件的 MPI 库(例如任何使用直接访问通信结构的库),我会选择选项 2。
首先,为 mpirun 实现一个包装器,它使用 kubernetes API 填充必要的数据,特别是在使用服务时使用端点(可能是个好主意),也可以直接抓取 pod 的公开端口。
在开始实际运行代码之前添加某种形式的检查点程序,可用于“会合”同步(我不知道 MPI 处理临时节点的效果如何)。这是为了确保当 mpirun 启动时它有一组稳定的 pod 可供使用
最后,实际构建一个包含必要代码和 SSH 服务的容器,用于mpirun启动其他 Pod 中的进程。
另一个有趣的选择是使用 Stateful Sets,甚至可能与内部的 SLURM 一起运行,它实现了在 kubernetes 上运行的 MPI 机器的“虚拟”集群。
这为每个节点提供了稳定的主机名,这将减少发现和跟踪状态的问题。您还可以对容器的本地工作文件系统使用有状态分配的存储(通过一些工作,可以使其始终引用相同的本地 SSD)。
另一个好处是它对实际应用的影响可能最小。
| 归档时间: |
|
| 查看次数: |
3430 次 |
| 最近记录: |