4. 作业调度系统运维
在计算生物学平台中，作业调度系统是连接用户与计算资源的“中枢神经”。无论是基因组比对、分子动力学模拟，还是大规模序列聚类，都需要调度器把成百上千个作业合理地分配到有限的计算节点上。本节围绕 Slurm、PBS 与 LSF 三类主流调度系统，讲解其架构差异、队列与资源分配机制、作业生命周期，以及运维中最常见的故障排查方法。
一、三类调度系统的架构对比
Slurm、PBS 与 LSF 在功能上高度重叠，但架构设计差异明显。Slurm 采用集中式控制器 slurmctld 加节点守护进程 slurmd 的两层结构，配置以纯文本 slurm.conf 为核心，轻量且易于容器化部署。PBS 分为 OpenPBS 与 PBS Professional，核心是 pbs_server、pbs_mom 与 pbs_sched 三组件，调度策略通过外部调度器插件实现。LSF 则采用主控 mbatchd 与从属 sbatchd 的层次结构，配合 LIM 负载信息管理器，强调跨集群、跨数据中心的资源统一调度。
从运维视角看，Slurm 的日志集中在 slurmctld.log 与各节点 slurmd.log，排查路径清晰；PBS 的日志分散在 server_logs 与 mom_logs；LSF 则依赖 lsb.events、lsb.acct 等二进制事件文件，通常需要 badmin、bhist 等工具解析。理解这些差异，是选择排障入口的前提。
二、队列配置与资源分配
队列（Queue/Partition）是调度系统对资源进行逻辑分组的基本单位。以 Slurm 为例，slurm.conf 中通过 PartitionName 定义分区，可指定节点列表、最大作业时长、最大节点数、优先级等。例如定义一个面向短时基因组比对的队列：
PartitionName=short Nodes=node[01-08] MaxTime=04:00:00 MaxNodes=4 Default=YES PriorityTier=10
PartitionName=long Nodes=node[09-16] MaxTime=7-00:00:00 MaxNodes=8 PriorityTier=5资源分配的核心是“请求—匹配—授予”过程。用户通过 sbatch --cpus-per-task=8 --mem=32G --gres=gpu:1 声明需求，调度器根据节点当前空闲资源、队列限制与优先级策略决定是否分配。PBS 使用 #PBS -l nodes=2:ppn=16,mem=64gb，LSF 使用 bsub -n 16 -R "rusage[mem=64000]"，语法不同但语义一致。
运维中需要特别关注三类资源参数：CPU 核数、内存与GPU/加速卡。若用户申请的资源超过节点物理上限，作业会长期处于 PENDING 状态；若未设置内存上限，作业可能因 OOM 被内核杀死，表现为 OUT_OF_MEMORY 或节点掉线。建议在队列层面设置默认内存与最大内存，避免单个作业耗尽节点资源。
三、作业生命周期与状态流转
一个作业从提交到结束，通常经历 PENDING → RUNNING → COMPLETED（或 FAILED、CANCELLED、TIMEOUT）几个阶段。在 Slurm 中，PENDING 的原因可通过 squeue -j <jobid> -o "%.18i %.9P %.8j %.8u %.2t %.10M %.6D %R" 查看，其中 REASON 字段会显示 Resources、Priority、QOSMaxCpuPerUserLimit 等具体原因。
作业进入 RUNNING 后，运维人员应关注其实际资源使用是否与申请一致。Slurm 提供 sstat -j <jobid> --format=JobID,MaxRSS,MaxVMSize,AveCPU 查看运行中作业的内存与 CPU 峰值；PBS 使用 qstat -f <jobid> 查看 resources_used；LSF 使用 bjobs -l <jobid> 查看 MEM、CPU 等字段。若发现实际使用远低于申请值，说明资源申请策略需要优化，否则会造成资源碎片化。
四、常见故障与排查路径
调度系统故障大致可分为四类：作业无法提交、作业长期排队、作业运行异常、节点失联。排查时应遵循“先看调度器状态，再看节点状态，最后看作业日志”的顺序。
- 作业无法提交：检查
slurmctld是否存活（systemctl status slurmctld），确认用户是否在允许提交的队列中，检查slurm.conf中AllowGroups或DenyAccounts配置。 - 作业长期排队：使用
squeue -j <jobid> --start查看预计启动时间；检查队列是否达到MaxNodes或MaxJobs上限；确认是否有高优先级作业持续占用资源。 - 作业运行异常：查看作业输出文件中的错误信息；使用
dmesg或journalctl -u slurmd检查节点内核日志，确认是否发生 OOM 或 GPU 驱动错误。 - 节点失联：
sinfo -R可列出DOWN或DRAIN状态的节点及原因；常见原因包括slurmd进程崩溃、网络分区、磁盘满、GPU 掉卡。恢复后需用scontrol update NodeName=<node> State=RESUME重新纳入调度。
MaxTime 与 MaxNodes，并启用 AccountingStorage 记录作业历史。定期用 sacct -S <日期> --format=JobID,JobName,Elapsed,MaxRSS,State 分析资源利用率，识别长期低效作业与异常失败模式。
最后需要强调，调度系统的稳定性依赖于节点健康、网络连通与存储可用性三者的协同。任何一层出现异常，都会在调度层表现为作业排队或失败。因此，运维人员应建立从调度器到节点、从节点到存储的完整监控链路，才能在故障发生时快速定位根因，而不是停留在“重启调度器”的被动操作上。