保姆级教程：给Slurm 20.02.3集群添加GTX1080Ti GPU节点（含防火墙和SELinux配置）
零基础实战：将GTX1080Ti无缝整合至Slurm 20.02.3计算集群
在高校实验室和中小型研究团队中，Slurm作为开源的集群管理工具，因其轻量化和高可靠性成为HPC环境的标配。但当传统CPU集群需要扩展GPU算力时，从硬件识别到资源调度的完整链路往往让新手运维人员手足无措。本文将以GTX1080Ti为例，演示如何将已配置好驱动的GPU服务器转化为Slurm集群的可调度资源节点，重点解决防火墙策略冲突、SELinux权限拦截、GRES资源配置三大核心痛点。
1. 环境预检与拓扑规划
在开始修改配置文件前，需要明确集群的基础架构。假设现有环境包含：
- 管理节点：IP 192.168.1.100，已部署Slurm 20.02.3控制服务
- GPU计算节点：IP 192.168.1.101，配备GTX1080Ti显卡，已完成以下准备：
- NVIDIA驱动版本450.80.02
- CUDA Toolkit 11.0
- cuDNN 8.0.5
关键检查项：在GPU节点执行
nvidia-smi应显示显卡状态，ls /dev/nvidia*应返回至少包含/dev/nvidia0的设备列表
硬件资源对应关系表：
| 节点类型 | CPU核心数 | 内存(GB) | GPU数量 | 显存(GB) |
|---|---|---|---|---|
| 管理节点 | 16 | 64 | 0 | 0 |
| GPU节点 | 24 | 128 | 1 | 11 |
2. 管理节点关键配置调整
2.1 slurm.conf深度定制
在管理节点的/etc/slurm/slurm.conf中需要新增两类参数：
# 添加通用资源类型声明 GresTypes=gpu # 定义GPU节点资源（追加到原有Node定义部分） NodeName=gpu01 NodeAddr=192.168.1.101 \ Gres=gpu:1 CPUs=24 RealMemory=128000 \ Sockets=1 CoresPerSocket=12 ThreadsPerCore=2 \ State=UNKNOWN参数解析：
Gres=gpu:1声明该节点提供1个GPU资源CPUs和RealMemory需与节点实际配置严格一致（单位MB）State=UNKNOWN确保节点添加后处于待激活状态
2.2 集群重载技巧
修改配置后，避免直接重启服务导致运行任务中断，推荐使用增量加载：
# 仅重新加载配置变更 scontrol reconfig # 验证节点识别状态 sinfo -N -o "%15N %8c %8m %12G"预期输出应包含类似内容：
NODELIST CPUS MEMORY GRES gpu01 24 128000 gpu:13. 计算节点精细配置
3.1 GRES设备映射配置
在GPU节点的/etc/slurm/gres.conf中建立设备映射：
# 定义GPU设备与物理硬件的对应关系 NodeName=gpu01 Name=gpu Type=gtx1080ti File=/dev/nvidia0注意：当存在多卡时需为每个物理设备创建条目，例如
File=/dev/nvidia[0-3]对应四卡机型
3.2 系统级权限处理
防火墙彻底禁用方案
对于仍在使用firewalld的系统：
# 停止并禁用firewalld systemctl stop firewalld systemctl mask firewalld # 清理遗留iptables规则（双保险） iptables -F iptables -t nat -F iptables -t mangle -F iptables -X验证命令：
iptables -L | grep -v "Chain INPUT (policy ACCEPT)" && echo "FAIL" || echo "CLEAN"SELinux永久关闭流程
- 临时设置宽容模式：
setenforce 0 - 修改
/etc/selinux/config永久生效：SELINUX=disabled - 重启后验证状态：
sestatus | grep "SELinux status" | grep disabled
4. 实战验证与排错指南
4.1 TensorFlow GPU测试脚本
创建gpu_test.py验证资源调度：
import tensorflow as tf physical_devices = tf.config.list_physical_devices('GPU') assert len(physical_devices) > 0, "No GPU detected" with tf.device('/GPU:0'): v1 = tf.constant([1.0, 2.0, 3.0]) v2 = tf.constant([4.0, 5.0, 6.0]) print("GPU计算结果:", (v1 + v2).numpy())通过Slurm提交任务：
srun --gres=gpu:1 --nodes=1 python gpu_test.py4.2 常见故障排查表
| 现象 | 可能原因 | 解决方案 |
|---|---|---|
| 节点状态显示IDLE但无法调度 | GRES配置未同步 | 在计算节点执行slurmd -C检查 |
| 任务报错"GPU not found" | /dev/nvidia*权限不足 | 确保slurm用户有设备读写权限 |
| 任务卡在PENDING状态 | 资源超配或参数不匹配 | 检查squeue --gres输出 |
5. 生产环境优化建议
对于需要长期稳定运行的场景，建议：
- 资源预留策略：在
slurm.conf中配置OverSubscribe=NO防止GPU超卖 - 混合调度方案：通过
--gres和--constraint实现CPU/GPU混合调度# 示例：优先调度带V100的节点 sbatch --gres=gpu:1 --constraint="v100" job.sh - GPU拓扑感知：对于多卡机型，使用
Gres=gpu:4配合gres.conf的多个File定义
在实验室环境中，我们曾遇到因未彻底禁用SELinux导致GPU设备访问被拒绝的情况。后来通过在内核启动参数添加enforcing=0才最终解决，这也提醒我们关键服务部署时需要多层次的权限检查。