大家好啊我是 jianpeng。今天和大家聊一下 IT/CAD 芯片研发集群以及 LSF、OpenLava、Slurm 等常见调度系统。建设研发平台时服务器数量只是起点决定调度方式的首先是上面要运行什么任务。一批 RTL 回归可能包含许多互不依赖的 seed综合和布局布线更关心单机线程与大内存STA 多角、DRC/LVS 则需要结合工具的任务拆分和前后依赖来安排资源。这些任务放到同一个计算池里IT/CAD 要解决的就不只是“把命令送到另一台机器”还包括成批提交、筛选合适节点、项目间分配资源、跟踪作业以及在高峰期补充算力。AWS 的半导体集群技术文章也是从研发任务特征出发介绍 Slurm 集群的组织方式。从具体任务理解调度功能更容易判断各个产品的实际价值。[2]先看这张示意图。提交入口把研发参数转换成作业和资源要求调度层选择执行节点工具运行后再把日志与结果交给流程处理。日常所说的“LSF 集群”“Slurm 集群”通常是按调度软件给整套环境命名。以下依次介绍八类系统重点比较它们的功能、优势、商业或开源属性以及适用规模和研发场景。规模说明区分产品定位、公开案例和工程建议节点数只是判断依据之一。一、LSF成熟的商业调度体系IBM Spectrum LSF 是商业软件提供作业调度与资源管理。它值得关注的地方是能把作业组织、项目政策、多集群协同和商业支持放进同一套管理体系适合作为多团队研发平台的候选。[3]下面的架构示意图梳理了 LSF 的作业提交、调度管理和执行节点之间的关系。mbatchd管理队列、作业状态和派发mbschd负责调度决策执行节点负责运行任务并反馈作业状态与负载信息。[28]作业组织与项目调度LSF 的作业数组可以把同一脚本、不同输入的任务组织成一组同时限制并发数量也允许单独操作其中的任务。对于回归 seed、参数扫描、资源要求相近的 STA 分析角这比逐个提交和查询更方便。[4]作业依赖进一步处理执行顺序编译满足条件后启动回归再根据前序结果进入汇总。CAD 可以在bsub外封装工程参数工程师通过bjobs查看状态减少手工等待前一道命令完成的操作。多项目同时竞争资源时队列优先级、公平共享、抢占和回填可以组合使用。日常回归按照项目份额分享机器紧急签核提高优先级合适的小任务填补大作业等待期间的空档。它的优势是把团队协商好的规则落实为持续执行的资源政策。[5]多集群与弹性扩容LSF 还提供两种不同的扩展方式。MultiCluster 在集群之间转发作业适合多个机房或计算池协作Resource Connector 根据等待负载申请外部主机让它们加入集群并在空闲后释放适合阶段性扩容。[6]资源条件可以进一步区分普通 CPU 节点和大内存节点让回归、综合及布局布线使用合适的机器。需要把 EDA 许可证纳入资源政策时可另外评估配套 License Scheduler 的组件和版本。面向多团队的研发平台IBM 的 Cadence 案例采用 LSF Suites 协同本地与云端资源覆盖芯片设计、系统验证和 EDA 工具开发这为混合云研发提供了具体参照。[7]LSF 适合重点纳入中大型、多项目、多站点或混合云平台的候选。大批 RTL 回归、综合/PR、STA、DRC/LVS 和流片前扩容都能对应到它的作业与资源模型。小集群同样可以采用是否值得投入主要取决于已有脚本、管理复杂度和商业服务需求。二、OpenLava延续 LSF 风格的开源批处理OpenLava 是开源项目具有早期 LSF / Platform Lava 的技术背景保留了bsub、bjobs等使用习惯。它提供的是一套基础批处理模型适合从存量流程或小型计算池的需求来理解。[8]下面的架构示意图展示了 OpenLava 从提交作业到分配计算节点的基本过程。OpenLava 的主要调度逻辑与队列管理集中在mbatchd计算节点上的sbatchd负责本地作业LIM 提供主机负载信息。它与现代 LSF 的组件划分并不相同。[29]基础作业怎样组织队列与主机负载信息帮助系统把任务分发到符合要求的机器。资源表达式还能描述主机条件、预期消耗和任务放置方式CAD 可以据此统一“任务到哪里运行、需要多少资源”的规则。作业数组、数组并发限制和依赖条件则能组织一批相似任务。例如同一个脚本读取不同输入完成参数扫描编译作业满足条件后释放后续测试。交互式批处理与可重运行选项也为调试和特定恢复方式提供了入口。[8]从工程角度看这些基础能力已经能把“人工找机器执行命令”转换为“统一提交、排队和跟踪作业”。对任务结构清楚、调度政策相对简单的环境这是一种直接的组织方式。熟悉的入口与开放的源码OpenLava 的主要优势在于已有 LSF 风格封装的团队容易理解其操作模型同时能够阅读和修改源码围绕确定的需求维护批处理环境。这里的接口相近不意味着它包含现代商业 LSF 的所有能力。OpenLava 可在小型、任务稳定的计算集群或者已有 OpenLava 的存量环境中评估用于独立仿真、参数扫描、编译测试等这属于工程建议没有可靠的统一官方节点数可供套用。原项目公开入口和分支状态需要辨明长期采用时应明确具体源码来源与维护方。三、Slurm统一 Linux 与 HPC 计算资源的开源平台Slurm 是开源软件也可以采购 SchedMD 商业支持。它面向小型到大型 Linux 集群适合希望统一 EDA、工程仿真以及部分 GPU 计算资源的团队。[9]下面的架构示意图展示了 Slurm 的提交入口、控制服务与计算节点分工。slurmctld管理资源分配节点上的slurmd负责执行端管理可选的slurmdbd将记账信息写入数据库。srun还会与执行端交互不能将所有命令都理解成同一条通信路径。[30]一套资源模型承接多类任务Slurm 的作业数组可以批量提交同一结构、不同输入的任务并限制同时运行数量。依赖条件可以连接编译、回归与后处理。常见入口是sbatch提交、squeue查询队列以及在配置记账后通过sacct查询历史。[10]它能够明确分配 CPU、内存、GPU 等资源并结合主机特征组织资源池。普通回归可以使用一类节点大内存后端任务进入另一类节点MPI 或 GPU 工程计算也可以沿用同一套资源管理框架。这个统一模型的价值是让不同研发任务拥有共同的提交、排队和资源描述方式。工具是否支持多线程、跨节点或 GPU 加速仍由实际应用决定调度器负责满足相应资源请求。项目政策与历史记账账户、QOS、公平共享与资源限制可以将项目优先级、份额和使用规则接入平台。记账数据还能用于分析各类任务的实际消耗再调整资源申请和管理政策。[11]回填调度会利用大任务等待资源期间的空档安排合适的小作业。它依赖合理的资源需求和运行时限因此提交信息越接近真实任务调度器越容易安排这些空隙。从小型计算池到大型 HPCSlurm 的优势是资源模型清楚、开源生态成熟、能够承接多类计算负载。AWS 已有面向半导体设计的 Slurm 与 ParallelCluster 技术方案展示了 EDA 集群的集成路径云端扩缩容来自整套方案。[2]规模上它覆盖小型 Linux 计算池到大型 HPC。Frontier 用户指南提供了接近一万个计算节点的实际部署参照不过超算节点规模不能直接换算为 EDA 短作业吞吐量。[12]RTL 回归、PVT/参数扫描、大内存后端作业以及 EDA 与 CAE、MPI、GPU 计算混合的平台都是值得评估的方向。团队已有的 Linux 运维、工具封装和集成能力会影响采用成本。四、SGE / Grid Engine灵活组织工程计算集群Grid Engine 同时存在开源和商业发行版。SGE 通常指历史上的 Sun Grid Engine当前评估还要区分开源 Open Cluster SchedulerOCS以及商业 Gridware Cluster SchedulerGCS、Altair Grid Engine 等产品。[13]下面的架构示意图用于理解 Grid Engine 的作业提交、集中管理和节点执行流程。图中以现代 Grid Engine 发行版为例调度线程位于qmaster内作业下发到执行主机后由execd和作业对应的shepherd管理执行。逻辑上的“调度器”不一定是独立进程。[31]数组与资源属性Grid Engine 的典型入口是qsub提交、qstat查询。任务数组让同一个脚本处理不同输入依赖条件可以控制后续任务何时开始适合独立仿真、参数扫描和重复计算。[14]资源属性也就是 complex用来描述任务需求和主机能力。IT/CAD 可以定义内存、主机特征或站点资源把配置不同的服务器纳入同一个调度框架共享政策再根据项目份额和使用情况安排资源。这套模型的优势是直观先定义机器能提供什么再声明作业需要什么。对于已经积累qsub包装器和工程脚本的团队可以在原有使用方式上继续完善资源管理。并行环境与工具启动并行环境PE进一步定义执行槽位怎样分布。单台机器上的多线程任务与跨主机协同任务资源放置和启动方式并不一样。HPC-Gridware 的技术文章使用 VCS 编译等工作流说明了这一点分配到资源之后应用怎样启动进程仍需正确衔接。对 CAD 来说PE 和提交封装需要共同表达工具的实际并行方式。[15]部门级到大型计算集群Grid Engine 可列入部门级到大型工程计算集群的候选尤其适合已有 Grid Engine 流程的团队继续评估。维护方为当前产品描述了少量主机到数千节点的范围这应绑定具体发行版理解不能直接套到所有历史 SGE 分支。[13]仿真回归、参数扫描、编译和存量计算平台都是典型场景。选择开源还是商业发行版时可以结合扩展功能、运维工具和支持服务而不必只围绕共同的历史名称做判断。五、Volclava字节跳动的开源调度器Volclava 是字节跳动开源的项目基于 OpenLava 2.0。它延续传统批处理方式与后面的 Kubernetes 项目 Volcano 不同。官方推荐用于少于 100 个节点、调度性能要求不高的小规模集群。[16]下面的架构示意图展示了 Volclava 的作业提交、调度与状态查询流程。作业提交和派发仍由mbatchd主线处理。启用查询分流后部分查询可由查询子进程处理这条可选路径不会替代主服务的调度职责默认也不开启。[32]提交与查询的改进Volclava 2.2 的发布说明围绕日常使用提供了一些具体改进。bsub -pack对批量提交进行打包发送适合一次提交多条回归或参数扫描任务减少重复的提交交互。[17]查询分流可以让独立子进程处理查询请求缓解查询与派发在主处理路径上的相互影响它需要按配置启用。通信部分还采用 epoll 处理为并发请求提供新的实现方式。这些能力值得放在真实工作模式里理解平台上除了作业提交还有工程师查状态、监控程序轮询等请求。改进提交与查询的处理方式对日常使用有直接意义但不等于任何任务组合都会获得固定倍数的性能提升。资源申请和内存记录新版本整合队列级与作业级资源请求规则并展示合并后的要求帮助 CAD 看清最终生效的选机和资源条件。对于“为什么这个任务进入这类机器”的问题这些信息比只看原始提交参数更有用。[17]峰值和平均内存记录能够帮助团队回看历史作业调整后续资源申请esub 配置与提交扩展则可以接入站点自己的规则。它们分别服务于资源可解释性、使用记录和统一入口。小型计算池的选择Volclava 的优势在于保留熟悉的 LSF 风格操作并改进提交、查询和资源信息。在官方推荐范围内小型回归池、参数扫描、编译测试和 CAD 资源规范化都值得结合自身流程评估。少于 100 节点是项目推荐范围实际压力还取决于提交频率、任务周转和查询量。选型时应同时考虑这些负载特征与团队的开源维护能力。六、Volcano在 Kubernetes 上组织批量计算Volcano 是开源的 Kubernetes 批处理系统。对已有 Kubernetes 平台或已明确要容器化部分研发任务的团队它可以把批处理能力接到既有部署、监控与权限体系中。[18]下面的架构示意图梳理了 Volcano 在 Kubernetes 中组织批处理任务的组件关系。官方图展示了准入校验、控制器、调度器与 Kubernetes 资源之间的关系。控制器管理作业生命周期调度器选择执行节点实际容器运行由 Kubernetes 的节点机制承担。[33]多任务协同与队列共享VolcanoJob 可以描述一个作业中的多个任务角色、数量和生命周期策略。Gang 调度关注一组任务能否满足最低运行条件避免协同任务只启动部分进程其余成员长期等待资源。[19]这对分布式训练、MPI 等任务有意义相互独立的 RTL seed 则通常可以分别安排不需要人为增加同时启动的条件。任务之间的关系决定应该使用哪种表达方式。队列资源管理解决多个团队怎样共享 Kubernetes 集群包括资源保障、容量、借用与回收。调度框架还提供优先级、公平共享和回填等政策异构与拓扑能力进一步帮助安排不同计算资源。[18][19]与既有云原生平台衔接Volcano 的主要优势是让批量计算能够使用同一套 Kubernetes API、镜像交付和监控体系。已有 Ray、Spark、MPI、PyTorch 等工作负载的团队可以在这些框架与队列之间建立统一的管理关系。芯片研发中已容器化的回归、验证日志分析、数据处理和设计空间探索中的算法训练都是可以讨论的用途。商用 EDA 工具采用哪种容器运行方式则要与实际工具环境和支持条件衔接。规模建议是已有 Kubernetes 基础的共享计算池特别是多团队中大型批处理平台。官方锐天案例披露了 200 个计算节点可作为部署规模参照这是金融计算案例不是芯片研发性能测试。[20]七、OpenPBS / PBS Professional兼顾批处理与并行计算OpenPBS 是开源软件PBS Professional 是商业产品。两者有共同的技术基础交付功能和支持方式仍需按版本确认。对已有 PBS 经验或 EDA 与其他工程计算共用资源的团队它们是值得比较的路线。[21]下面的架构示意图梳理了 PBS 的作业提交、调度决策和节点执行流程。pbs_sched作出调度决策pbs_server协调作业下发执行主机上的pbs_mom管理任务。pbs_comm位于通信层负责消息路由并不承担额外的调度决策。[34]资源块与任务依赖PBS 的数组作业可以让一个脚本处理不同测试数据用户指南直接将 EDA 仿真列为适用场景。依赖关系再把前后步骤连接起来适合成组计算和多阶段任务。[22]select、place等资源请求描述需要什么资源块以及怎样放置。它既能表达单机大内存任务也能为真正支持跨节点的工程计算安排资源。队列、公平共享、回填与记账共同服务于多项目共享。这里的优势是批处理和并行任务可以使用一致的资源框架。研发平台既跑验证又跑电磁、热分析等 CAE 任务时有机会复用提交、资源政策和历史记录。把站点规则接到平台入口Hooks 允许管理员在提交、执行等生命周期节点加入逻辑。例如对资源请求做检查、补充必要设置或执行站点自己的规则。CAD 可以将常见要求放进统一入口减少用户反复填写和遗漏。[21]PBS 的站点扩展能力使既有业务规则可以接入基础调度模型。已有 hooks、提交脚本和运维经验都能在后续平台建设中继续发挥作用。从工程计算池到大型 HPCPBS 覆盖小型计算池到大型 HPC。Aurora 有 10,624 个计算节点并使用 PBS Professional 管理作业为商业产品提供了超万节点科研部署的参照这不能理解为任意 OpenPBS 配置都具备相同容量。[23]仿真回归、PVT/参数扫描、资源需求明确的实现任务以及 EDA/CAE 混合计算平台都是适合比较的场景。团队可以结合自维护能力与支持需求在开源和商业交付之间选择。八、Altair Accelerator面向 EDA 的高吞吐调度系统Altair Accelerator 是商业软件面向 EDA 与 HPC 工作负载。对于任务数量多、周转频繁、多项目竞争明显的芯片研发计算集群它值得作为独立方案比较。[24]下面的架构示意图展示了 Accelerator 怎样衔接作业提交、调度政策和执行资源。vovserver维护资源和作业状态并分派任务计算节点上的vovtasker启动、管理作业并回报状态。图中的任务分派方向与网络连接发起方向不同tasker 本身也是连接服务端的客户端。[35]面向大量作业的调度方式Accelerator 采用事件驱动调度作业提交、完成或资源变化触发相关处理调度条件相同的任务可以组织为 bucket。对重复任务这种组织方式有助于减少对相同条件的重复处理。[24]公平共享、优先级、抢占和预约则负责项目政策常规回归保持周转关键签核及时获得资源不同团队使用可解释的份额规则。其价值需要结合真实任务时长和提交量理解不能仅从“事件驱动”推导无条件的性能排名。将常用设置保存为作业类别资源请求涵盖 CPU、内存、主机条件并有 NUMA 相关控制。Jobclass 可以保存可复用的提交设置CAD 可以为常见任务准备类别使工程师提交时带入对应资源与运行参数。[25]这对作业类型比较明确的环境很实用普通回归、编译、大内存实现等任务可以复用各自的设置减少重复填写和不一致配置。优势体现在作业周转与平台规范能够一起管理。研发高峰与弹性计算Rapid Scaling 等能力用于衔接弹性资源。Altair 的 Annapurna Labs 案例涉及芯片前后端工作流和弹性 CI说明它也可以围绕研发峰值组织云端计算。[26]规模上Accelerator 适合纳入中大型 EDA 计算集群的候选。供应商半导体方案页面描述了 5 万以上计算核、50 万以上排队任务的规模这是资源量与等待作业量两个口径不能改写成节点数或同时运行数量。[27]大量 RTL 仿真、编译/CI、后端实现与签核以及高峰期扩容都是具体评估方向。商业交付、配套组件和已有工作流接入应与调度功能一起比较。九、八类系统对比从研发任务确定候选八类系统的适用性需要回到任务本身判断。下面这张图把五类常见负载放在一起回归重视批量组织与并发大内存任务重视单机资源签核任务关注拆分和依赖真正的分布式计算才需要多节点协同。因此同样数量的机器短作业密集的回归池与少量长任务的实现平台对调度器的要求会不同。下表中的规模是候选方向具体容量还要连同排队量、提交频率和运行时长一起理解。调度系统商业 / 开源核心功能主要优势适用规模与条件常见芯片研发场景LSF商业数组与依赖、公平共享、抢占与回填、跨集群、弹性资源将项目政策、多集群与商业支持纳入统一体系中大型、多团队、多站点或混合云RTL 回归、综合/PR、STA、DRC/LVS、峰值扩容OpenLava开源队列、负载选机、资源表达式、数组与依赖熟悉的 LSF 风格入口基础批处理与源码开放小型、任务稳定或存量环境明确维护来源独立仿真、参数扫描、编译测试Slurm开源商业支持可选数组、依赖、CPU/内存/GPU、QOS、公平共享、记账用统一资源模型承接多类计算负载小型到大型 Linux/HPC有万节点量级超算案例回归、PVT、大内存后端、EDA/CAE 混合计算SGE / Grid EngineOCS 开源GCS、Altair Grid Engine 商业数组、资源属性、共享策略、并行环境延续 qsub 工具链灵活描述主机与作业资源部门级到大型按具体发行版评估仿真回归、参数扫描、编译、存量计算集群Volclava字节跳动开源批量提交、可选查询分流、资源整合、内存记录、esub延续传统入口并改进日常提交与管理官方推荐少于 100 节点且调度性能要求不高小型回归池、参数扫描、编译测试、CAD 资源规范Volcano开源Gang、生命周期策略、队列共享、异构与拓扑、框架集成接入既有 Kubernetes 部署与监控体系已有 K8s 的共享计算池公开 200 节点非 EDA 案例容器化回归、日志分析、研发数据处理、算法训练OpenPBS / PBS ProfessionalOpenPBS 开源PBS Professional 商业数组与依赖、资源放置、公平共享、回填、hooks批处理与并行模型完整站点扩展与交付路线可选小型到大型 HPCPBSPro 有超万节点科研案例仿真、PVT/参数扫描、实现任务、EDA/CAE 混合计算Altair Accelerator商业事件驱动、任务分组、共享与抢占、Jobclass、云扩展围绕 EDA 作业周转与资源竞争组织调度中大型 EDA 计算集群供应商公开 5 万核、50 万排队任务大量回归、编译/CI、后端签核、峰值扩容多团队 EDA 平台可以优先比较 LSF 与 Accelerator需要统一 Linux/HPC 资源时可以重点看 Slurm 与 PBS已有 Grid Engine 工具链则从具体发行版继续评估。小型传统队列环境可以研究 OpenLava 与 Volclava已有 Kubernetes 的容器计算则单独评估 Volcano。下一步可以从日常作业中选出几类代表任务整理它们的 CPU/内存、运行时长、提交量和依赖关系。再结合团队已有的封装与运维能力选出两三个候选这样比较的每一项功能都能对应到实际研发工作。引用链接芯片研发计算集群选型LSF、Slurm 等八类调度系统详解AWS使用 Slurm 与 ParallelCluster 构建半导体设计集群IBMAbout IBM Spectrum LSFIBMLSF 作业数组控制作业依赖IBMLSF 队列与调度配置IBMMultiCluster 最佳实践Resource ConnectorIBMCadence Designs 客户案例OpenLava 原始项目说明的保留版本bsub 手册Slurm OverviewSlurm FAQSlurmJob Array SupportsbatchSlurmMultifactor Priority资源与回填配置OLCFFrontier User GuideHPC-GridwareGCS 与 OCS产品与规模定位Altair Grid EngineOracleGrid Engine 作业提交资源属性调度策略HPC-GridwareGCS 与 OCS 多节点任务ByteDance Volclava 项目Volclava 2.2.0 版本说明2.2.0-beta 版本说明Volcano 项目异构资源与框架集成VolcanoVolcanoJob队列资源管理调度框架Volcano锐天科技部署案例OpenPBS 项目PBS Professional 管理指南PBS Professional 用户指南作业数组ALCFAurora 系统概览Aurora 作业运行与 PBSAltair AcceleratorJob Scheduling产品功能导读Altair AcceleratorJobclasses硬件资源请求NUMA 控制AltairAnnapurna Labs 芯片设计云端案例AltairSemiconductor Design Workflow SolutionsIBMLSF 守护进程与组件分工OpenLava 原始 mbatchd / sbatchd 手册LIM 手册Slurm 官方架构作业启动机制Altair Grid Engine 组件与调度线程HPC-Gridware 架构说明Volclava 查询分流说明客户端请求处理代码Volcano 官方架构与原图官方图源与许可证Kubernetes 组件PBS Professional 安装指南服务与通信组件PBS 编程指南Altair Accelerator 运行原理Taskers