3. 集群操作系统与基础环境

计算生物学平台的稳定性，往往不取决于上层流程写得多漂亮，而取决于底层操作系统这一层是否“可预期”。同一套比对、组装或单细胞分析流程，在不同发行版、不同内核参数、不同文件系统上，可能表现出完全不同的吞吐与失败模式。本节围绕五个相互咬合的层面展开：发行版选型、内核参数、文件系统、用户与权限、环境模块管理。

发行版选型：先看生命周期，再看生态

集群节点通常分为登录节点、计算节点、存储节点和调度节点。选型时最该关注的不是“新不新”，而是三件事：支持周期是否覆盖硬件寿命、驱动与调度器是否随内核同步更新、以及生物信息软件仓库是否成熟。实践中常见两类选择：一类是 RHEL 系（Rocky Linux、AlmaLinux），生命周期长、企业级驱动与 InfiniBand/RDMA 支持稳定，适合作为长期生产底座；另一类是 Ubuntu LTS，软件包较新、社区文档丰富，适合需要较新编译器与容器工具链的场景。若集群使用 NVIDIA GPU 做 GPU 加速的比对或深度学习，应优先选择厂商明确认证的发行版与内核组合，避免自行升级内核后驱动失配。

一个可参考的示例判断：若集群计划服役 5 年、以 CPU 队列为主、使用 Slurm + 共享 Lustre，则 Rocky Linux 9 是稳妥选择；若团队大量使用 Conda 与较新 Python 生态、GPU 节点占比高，Ubuntu 22.04/24.04 LTS 更省心。选型一旦确定，应统一到所有节点，避免登录节点与计算节点 glibc 版本不一致导致二进制无法运行。

内核参数：为高并发与大数据流调优

默认内核参数面向通用桌面，直接用于集群会出现文件句柄耗尽、网络连接排队、内存回收抖动等问题。以下是一组常见调优方向，示例值需按实际内存与并发量评估，不可照搬：

# /etc/sysctl.d/99-hpc.conf 示例
fs.file-max = 2097152          # 系统级最大文件句柄
fs.inotify.max_user_watches = 524288
net.core.somaxconn = 4096      # 监听队列上限
net.ipv4.tcp_max_syn_backlog = 8192
net.core.rmem_max = 134217728  # 大带宽 RDMA/万兆场景
net.core.wmem_max = 134217728
vm.swappiness = 10             # 降低换页倾向
vm.dirty_ratio = 20
vm.dirty_background_ratio = 5
vm.max_map_count = 262144      # 大量 mmap 的比对工具需要

其中 vm.swappiness 对计算节点尤其关键：内存吃紧时若频繁换页，比对任务会从“慢”变成“卡死”。vm.max_map_count 则影响 BWA、STAR 等大量使用内存映射的工具。修改后可用 sysctl -p 生效，并用 sysctl vm.swappiness 验证。注意：内核参数是节点级配置，必须通过配置管理工具统一分发，否则会出现“同一队列不同节点行为不一致”的隐蔽故障。

文件系统：按数据温度分层

集群存储通常不是单一文件系统，而是按访问模式分层。下面的关系图展示了典型布局与数据流向：

文件系统选择还要考虑小文件问题。测序数据常被拆成大量小文件，若直接放在 Lustre 上，元数据服务器会成为瓶颈。常见做法是先用 tar 打包或转为 .bam/.cram 等紧凑格式再传输。挂载参数上，NFS 建议使用 hard,intr,rsize=1048576,wsize=1048576，Lustre 则关注 stripe_count 与 stripe_size 是否匹配大文件顺序读。

用户与权限：最小权限 + 项目组隔离

集群用户管理不应依赖手工 useradd，而应接入统一身份源（LDAP 或 FreeIPA），保证所有节点 UID/GID 一致。权限模型推荐“项目组”方式：每个课题组一个组，共享目录设为 2770（setgid 保证新文件继承组），例如：

groupadd -g 2001 lab_genomics
mkdir -p /share/lab_genomics
chown root:lab_genomics /share/lab_genomics
chmod 2770 /share/lab_genomics
# 新用户加入
usermod -aG lab_genomics alice

计算节点上应限制普通用户使用 sudo，仅允许通过 Slurm 提交作业。对于需要 GPU 的场景，可用 cgroup 限制单用户显存与 CPU 配额，防止一个失控作业拖垮整台节点。

环境模块管理：让软件版本可切换、可复现

生物信息工具版本碎片化严重，同一工具不同版本结果可能不同。Environment Modules（module 命令）或 Lmod 是集群标准做法。核心思路是：每个工具版本独立安装到 /opt/apps/<name>/<version>，再写一个 modulefile 描述环境变量。示例 modulefile：

#%Module1.0
proc ModulesHelp { } { puts stderr "BWA 0.7.17" }
module-whatis "BWA 0.7.17 aligner"
set root /opt/apps/bwa/0.7.17
prepend-path PATH $root/bin
prepend-path LD_LIBRARY_PATH $root/lib

用户通过 module load bwa/0.7.17 切换版本，module avail 查看可用模块，module list 确认当前加载。对于 Python/R 生态，建议用 Conda 环境配合 module 封装，把环境路径写入 modulefile，避免用户自行 pip install 污染系统 Python。作业脚本中显式写出 module load 行，是保证结果可复现的最低要求。

把以上五层串起来看：发行版决定底座寿命，内核参数决定高负载下的稳定性，文件系统决定数据吞吐与元数据效率，用户权限决定多租户安全边界，环境模块决定结果可复现性。任何一层被忽略，都会在某个深夜的作业失败日志里以难以定位的方式暴露出来。建议在集群交付前，用一份最小检查清单逐项验证：节点间 UID 一致、sysctl 配置已分发、共享目录权限正确、module avail 能列出关键工具、以及一个端到端测试作业能在任意计算节点成功运行。