前言：这篇文章解决什么问题
前面几篇文章讲了 lsb.queues、lsb.hosts、lsb.users、lsb.params、lsb.applications、lsb.resources、lsb.modules——这些都是「批处理层」（LSF Batch，简称 LSB）的配置文件，管的是作业怎么排、怎么调度。但在这些文件生效之前，LSF 还有一层更底层的「集群层」（LSF Base）配置，负责回答几个更基础的问题：这个集群到底由哪些机器组成？谁有权限管理整个集群，而不只是某个队列？每台机器的型号、架构、静态资源标签怎么定义？
这一层的核心文件就是 lsf.cluster.cluster_name（其中 cluster_name 是你的集群名，比如安装时集群名叫 fasteda_farm，文件名就是 lsf.cluster.fasteda_farm），配合 lsf.shared 一起工作。这篇文章是「lsf.cluster 系列」的第一篇，专门讲清楚它的文件结构、Host 段怎么写、ClusterAdmins 怎么配，后面两篇再讲自定义资源阈值和用户/资源限额实战。
为什么要单独讲这一层
很多 CAD Farm 管理员日常只跟 lsb.queues / lsb.users 打交道，几乎不碰 lsf.cluster.cluster_name，因为装机的时候已经由安装脚本生成好了。但下面这几类需求，绕不开这个文件：
• 新增/下线计算节点：在传统静态 Host 配置模式下（本文讨论的场景），新机器要加入集群通常需要先在 lsf.cluster.cluster_name 的 Host 段登记；如果 lsb.hosts 中还针对具体主机、HostModel 或 HostType 配置了作业数限制、负载阈值、运行窗口等策略（若 lsb.hosts 未定义 Host 段，LSF 默认直接使用 lsf.cluster.cluster_name 中的 server hosts），则还需要根据新主机的属性检查并补充相应配置。如果集群启用了 Dynamic Host Configuration（动态主机），流程会不同，属于进阶话题，本系列不展开。
• 授予「集群管理员」权限：需要区分「能管理某个队列的作业」和「能改所有配置文件、重启守护进程」这两种完全不同量级的权限，后者就在 lsf.cluster.cluster_name 里配置。
• 给主机打静态标签：比如标记哪些主机是 GUI 工作站、哪些是大内存节点、哪些主机装了某个授权软件，这些静态 Boolean/String 资源要在 Host 段的 RESOURCES 列里声明。
• 控制谁能做 master 候选：多台管理节点做高可用时，master 候选的顺序就是由 Host 段里主机的排列顺序决定的。
一、lsf.cluster 与 lsf.shared 的关系
要理解 lsf.cluster.cluster_name，得先弄清楚它和 lsf.shared 的分工。这两个文件都属于「LSF Base」层（区别于 lsb.* 的「LSF Batch」层），但职责不同：lsf.shared 定义的是所有集群「共用」的字典——有哪些集群、有哪些主机型号（HostModel）、有哪些主机架构（HostType）、有哪些自定义资源名字；而 lsf.cluster.cluster_name 则是「某一个具体集群」引用这本字典、把字典里的条目实际分配给自己集群内的主机。
打个比方：lsf.shared 相当于「全公司统一的物料编码表」，定义了“什么型号叫 IntelXeon_Gold”“什么资源叫 vcs_license”；而 lsf.cluster.fasteda_farm 则相当于「某个仓库的实际库存清单」，写明“这个仓库里，1号货架放的是 IntelXeon_Gold 型号的机器，3号机器上有 5 个 vcs_license”。多个集群可以共用同一份 lsf.shared，但各自有独立的 lsf.cluster.cluster_name。需要说明的是，“字典”这个比喻主要针对本文要讲的 Cluster/HostType/HostModel/Resource 这几个段——lsf.shared 实际定位是“所有集群共用的定义文件”，除了这几个段之外还涉及 external load index（外部负载指标）、MultiCluster 环境下的集群互联定义等内容，本系列会按用到的部分逐步展开，不要把它简单理解成只有这四类信息。
1.1 lsf.shared 中和 lsf.cluster 相关的关键段
段名 | 作用 |
Cluster | 登记集群名称，必须包含集群名，MultiCluster 场景下还要写 Servers |
HostType | 定义合法的主机架构类型（如 LINUX64），Host 段的 type 列要引用这里定义好的类型 |
HostModel | 定义主机型号及其 CPU 相对速度因子（CPU Factor），Host 段的 model 列要引用这里的型号 |
Resource | 定义自定义资源的名字、类型（Boolean/Numeric/String）等元数据，供 lsf.cluster.cluster_name 的 Host 段 RESOURCES 列和 ResourceMap 段引用（下一篇详细展开） |
***这篇先聚焦 lsf.cluster.cluster_name 本身的结构；lsf.shared 里 Resource 段的详细写法、静态/动态资源的区别，放在系列第二篇专门讲解，这里只需要知道两者是「字典」和「引用字典」的关系。
1.2 lsf.cluster.cluster_name 的文件位置与整体结构
这个文件通常安装在 LSF_ENVDIR 定义的目录下（一般是 /opt/lsf/conf），文件名格式固定为 lsf.cluster.<集群名>。它包含以下几个配置段，除 Host 段外全部可选：
配置段 | 是否必需 | 作用 |
Parameters | 可选 | LIM（Load Information Manager）的策略参数，比如探活间隔、主从心跳超时时间 |
ClusterAdmins | 可选（强烈建议配置） | 定义集群管理员，不配置则默认只有 root 有权限，风险很高 |
Host | 必需，唯一必需段 | 列出集群内所有主机及其型号、架构、是否为 server、静态资源标签 |
ResourceMap | 可选 | 定义跨主机共享的资源（比如 license、共享存储空间），下一篇详细讲解 |
RemoteClusters | 可选 | 仅 MultiCluster 多集群环境需要，定义与哪些远程集群互联 |
1.3 修改后如何生效
和 lsb.* 文件用 badmin reconfig 不同，lsf.cluster.cluster_name 属于「LSF Base」层，官方给出的标准生效流程是三步，改之前再加一步语法预检查会更稳妥：
# 0.（强烈建议）改完文件先做语法检查，而不是直接 reconfig lsadmin ckconfig -v
# 1. 让 LIM 重新加载 lsf.cluster / lsf.shared 配置 lsadmin reconfig
# 2. 让 mbatchd 感知到集群主机列表的变化（新增/删除主机后必做） badmin mbdrestart
# 3. 对发生变化的、非 Management Host 的服务器重启 LIM，注意不是所有主机 lsadmin limrestart <发生变化的主机名 ...> |
⚠️ 注意：第 3 步官方原文是“restart LIM on all changed non-management hosts”，也就是只重启配置真正发生变化的那些非管理主机，而不是无条件执行 lsadmin limrestart all。如果把 limrestart all 当成每次改动 lsf.cluster 后的固定套路，很容易变成“改一个资源标签就把全集群所有 LIM 重启一遍”，这在大规模集群上是不必要的抖动，应该按实际改动范围精确重启。
***lsadmin ckconfig -v 是排查 lsf.cluster/lsf.shared 配置问题的第一工具，它会把语法错误、未定义资源引用等问题直接打印到终端；lsadmin reconfig 本身在执行前也会先做一次检查，如果发现致命错误会中止并提示，这时候要先看清楚报错内容再决定是否继续，而不是习惯性地确认下去。
二、Host 段：集群里唯一必须配置的部分
Host 段是 lsf.cluster.cluster_name 里唯一必需的段，作用很直接：告诉 LSF「这个集群里有哪些机器、每台机器是什么型号架构、是不是能接活的 server、身上贴了哪些静态标签」。它必须写在 ResourceMap 段之前。
2.1 基本语法
Begin Host HOSTNAME model type server RESOURCES cadmgr01 IntelXeon LINUX64 1 (mg) cadsim01 IntelXeon LINUX64 1 (verilog) cadsim02 IntelXeon LINUX64 1 (verilog) cadbig01 AMDEpyc LINUX64 1 (bigmem) cadgui01 IntelXeon LINUX64 1 (gui) cadclient01 ! ! 0 () End Host |
这是一个典型的中小规模 CAD Farm 主机清单雏形：一台管理节点（cadmgr01，打了 mg 标签表示 management），两台仿真节点（打了 verilog 标签），一台大内存节点（bigmem），一台图形工作站（gui），还有一台只提交作业、不接活的客户端（server 列写 0）。
2.2 各列参数详解
列名 | 说明 |
HOSTNAME | 主机的官方名称（hostname 命令的输出），必须能被 DNS/hosts 解析，是 Host 行中必须提供的核心字段；其他字段可以根据集群配置和默认行为省略或使用特殊值 |
model | 主机型号，必须是 lsf.shared 的 HostModel 段中已定义的型号名；填 ! 表示由 LIM 自动探测 |
type | 主机架构类型，必须是 lsf.shared 的 HostType 段中已定义的类型名；填 ! 表示自动探测 |
server | 1 表示该主机是 LSF server（可以接收并执行作业），0 表示只是 client（只能提交作业，不接受远程作业），不填默认视为 server |
RESOURCES | 该主机拥有的静态 Boolean/String/Numeric 资源标签列表，用括号包住、空格分隔，資源名必须先在 lsf.shared 的 Resource 段定义过 |
RUNWINDOW | 可选列，定义 LIM 向非批处理工具（如 lsrun/lsgrun 这类直接走 LIM 简单调度的交互任务）推荐该主机的时间窗口，格式如 (20:00-08:30)，窗口外主机状态显示为 lockW；注意这与 lsb.queues/lsb.hosts 里控制 batch 作业的 dispatch window 是两套完全独立的机制，不要混为一谈——batch 作业有自己单独的运行时间窗口配置 |
REXPRI | 可选列，remote execution priority，调整远程执行进程在该主机上的 nice 值优先级，很少需要手动改 |
2.3 model / type 用 “!” 自动探测的取舍
刚装好集群、还不熟悉环境时，model 和 type 两列填 ! 让 LIM 自己探测是最省心的做法，LSF 会根据 uname 等系统信息自动匹配 lsf.shared 里最接近的型号。但生产环境建议尽快把关键节点（尤其是异构集群里 CPU 型号、代际差异较大的机器）显式指定型号，原因是：model 决定了这台主机的 CPU Factor（相对速度因子），直接影响作业调度里“哪台机器更快、CPULIMIT 换算成实际时间是多少”的计算，自动探测在虚拟化、容器化环境下有时会探测不准。
2.4 server 列：区分「干活的」和「只提交的」
server 列是很多人容易忽略、但对权限控制很关键的一列。LSF 里“提交作业的主机”（submission host）和“执行作业的主机”（execution host）是两个独立的角色：server=1 的主机（server host）可以同时承担这两个角色，而 server=0 的主机是纯粹的 client-only host，只能提交作业。举例来说，工程师自己的笔记本电脑或者某台只用来提交作业的堡垒机，装了 LSF 客户端可以执行 bsub，但这台机器本身性能一般、也不希望被派发作业去跑仿真——这时候把它配置成 server=0（client）就很合适：这台机器能正常提交作业，但不会作为 LSF batch 的执行节点接收作业。
Begin Host HOSTNAME model type server RESOURCES bastion01 ! ! 0 () # 堡垒机，仅用于提交作业 engineer_laptop_pool ! ! 0 () # 工程师本地环境，仅提交 cadsim01 IntelXeon LINUX64 1 (verilog) End Host |
✅ 最佳实践：把所有「非计算资源」的接入点（堡垒机、工程师工作站、CI/CD 触发机）都配置成 server=0，既能让这些机器正常提交作业，又杜绝了它们意外成为作业执行节点、抢占计算资源或者因为配置和真正的计算节点不一致而导致作业运行异常的风险。
2.5 RESOURCES 列：给主机打静态标签
RESOURCES 列是控制「哪些作业只能去哪些机器」最直接的手段之一，本质是把 lsf.shared 里定义好的资源实际赋值到某台主机上，然后在 bsub -R 或者队列的 RES_REQ 里通过 select 语句引用这些资源来筛选主机。这里容易产生的一个误解是把 RESOURCES 简单理解成“标签”——实际上它是 LSF 资源模型的一部分，同一个括号里的写法根据资源类型不同，含义也不同，具体写法可以对照下表：
写法示例 | 资源类型 | 含义 |
(verilog) | Boolean | 该主机具备 verilog 这个特征，等价于 verilog=1 |
(rack=A03) | String | 该主机的 rack 资源取值为字符串 A03 |
(license=10) | Numeric | 该主机上有 10 个静态数量的 license 资源 |
(bigmem) | Boolean | 该主机具备 bigmem 这个特征，等价于 bigmem=1 |
*** RESOURCES 里还有一种写法是在资源名前加 !（如 (!license)）表示 Exclusive Resource（独占资源），语义比普通 Boolean/Numeric 更复杂，需要结合 lsf.shared 里该资源的定义和资源请求语法一起理解。这个概念本篇先不展开，留到下一篇专门讲自定义资源类型时再详细说明，这里只需要知道 RESOURCES 列的基础写法是“资源名”或“资源名=值”就够用了。
# lsf.shared 中先定义资源类型（下一篇详细展开） Begin Resource RESOURCENAME TYPE INTERVAL INCREASING DESCRIPTION bigmem Boolean () () (大内存节点) gui Boolean () () (图形工作站) verilog Boolean () () (装有Verilog仿真环境) rack String () () (机柜编号) End Resource
# lsf.cluster.fasteda_farm 中把标签打到具体主机上 Begin Host HOSTNAME model type server RESOURCES cadbig01 AMDEpyc LINUX64 1 (bigmem rack=B12) cadgui01 IntelXeon LINUX64 1 (gui rack=A03) cadsim01 IntelXeon LINUX64 1 (verilog rack=A03) End Host |
配置好之后，用户提交作业时就可以直接用 bsub -R "select[bigmem]" 强制要求作业只跑在贴了 bigmem 标签的主机上，或者用 bsub -R "select[rack==A03]" 要求作业跑在特定机柜（比如为了网络延迟或散热分区的考虑）。这一层的筛选发生在「选哪台机器」阶段，比 lsb.queues 里 HOSTS 参数按队列圈定主机组更细粒度、更灵活，两者通常搭配使用：队列先圈定一个大致的主机池，再用 -R select 在池子里精确筛选。
2.6 Management Host 与 master 候选顺序
LSF 集群必须有一个 Management Host（早期文档也称 master host），负责集群级的调度协调，mbatchd、mbschd 等核心守护进程都跑在它上面。这里有一个非常容易讲错、也经常被过时资料误导的点，需要说清楚：
• 如果集群没有配置 LSF_MASTER_LIST，那么 Management Host 默认是 lsf.cluster.cluster_name 里 Host 段排列顺序的第一台主机——这也是很多老版本教程里“Host 段第一行就是 master”这个说法的来源。
• 但生产环境的高可用部署，标准做法是在 lsf.conf 中显式配置 LSF_MASTER_LIST，一旦配置了它，Management Host 的候选范围和优先顺序就以 LSF_MASTER_LIST 为准，不再是简单地看 Host 段第一行；执行 lsadmin reconfig 时，只有 LSF_MASTER_LIST 中列出的 Management Host candidates 上的 LIM 会直接重新读取 lsf.shared 和 lsf.cluster.cluster_name，选举出的 Management Host 再把配置信息传递给普通 Server Host 的 LIM。
# lsf.conf 中显式指定 Management Host 候选及优先级 LSF_MASTER_LIST="lsfmaster01 lsfmaster02" # lsfmaster01 是第一优先候选，lsfmaster02 次之； # 当前 Management Host 不可用时，LSF 会按这个顺序考虑候选主机接管。 |
⚠️ 注意：所以准确的说法应该是：未配置 LSF_MASTER_LIST 时，Host 段第一台主机是默认的 Management Host；生产环境一旦配置了 LSF_MASTER_LIST，就必须以它为准，不能再简单地认为“Host 段第一行=Master候选”。
✅ 最佳实践：生产环境的高可用部署，建议显式配置 LSF_MASTER_LIST 而不是依赖 Host 段顺序的隐式行为——这样候选主机范围和优先级一目了然，排查故障切换问题时也更容易定位。候选主机之间要保证 LSF 配置和二进制文件一致（Windows 环境下二进制可以不同，但配置文件必须一致），并尽量放在同一网络子网内，避免跨子网通信抖动导致误判切换。CAD Farm 里通常不会用计算节点做候选，而是专门留一到两台轻量级的管理节点。
三、ClusterAdmins 段：谁能管理整个集群
这是这篇文章里最值得所有 CAD Farm 管理员认真对待的一节。ClusterAdmins 段定义的是 LSF 应用层面的「集群管理员」身份——拥有这个身份的人，可以对整个集群做 cluster-wide 的管理操作：管理任意用户提交的作业和队列、创建主机组、执行大量 badmin/lsadmin 管理命令。这跟 lsb.queues 里 ADMINISTRATORS 参数定义的「队列管理员」完全不是一个量级——队列管理员只能管自己那个队列里的作业，集群管理员的权限覆盖整个集群的作业和队列。
⚠️ 注意：这里必须先拆开两个经常被混为一谈的概念：ClusterAdmins 定义的是 LSF 应用层面的管理权限，不等于 Linux 文件系统权限。列表里除第一个用户外的其余管理员，即使能执行绝大多数集群管理命令，默认也不拥有修改 lsf.cluster.*、lsf.shared、lsb.* 等配置文件的权限——能不能直接编辑这些文件，最终取决于 Linux 文件系统的 owner/group/权限位（以及 sudo 等），这是两套完全独立的权限体系，下面 3.1~3.3 会具体拆开讲。
3.1 基本语法
Begin ClusterAdmins ADMINISTRATORS = lsfadmin cad_ops_lead End ClusterAdmins |
ADMINISTRATORS 是这个段唯一的关键字，可以填多个 UNIX 用户名或用户组名，用空格分隔。列表里第一个用户是「主管理员」（Primary LSF Administrator），其余用户是「集群管理员」（Cluster Administrator）——这两者的权限并不相同，是下一节要讲的重点。
3.2 主管理员与集群管理员：权限并不对等
IBM 官方文档对这两个角色的定义非常明确，而且是本文最需要精确转述的地方：
• 主管理员（Primary LSF Administrator）：安装时指定的第一个管理员账号（一般叫 lsfadmin），拥有全部 LSF 配置文件和日志文件的属主权限，可以执行 cluster-wide 操作、修改配置文件、reconfigure 集群、管理所有用户的作业。
• 集群管理员（Cluster Administrator）：ClusterAdmins 列表中除第一个之外的其余用户，拥有和主管理员相同的集群级操作权限（管理所有作业和队列），但默认不拥有修改 LSF 配置文件的权限。
***换句话说：LSF 管理权限 ≠ Linux 文件写权限。一个人是不是集群管理员（能不能 badmin/lsadmin 管作业），和他能不能直接 vi 修改 lsf.cluster.cluster_name，是两件不一定相关的事——后者最终要看这个账号在操作系统层面对配置文件目录有没有写权限。给团队分配“集群管理员”身份时，务必想清楚你要给的是“管作业的权限”还是“改配置的权限”，不要默认两者等价。
3.3 不配置会怎样
⚠️ 注意：如果完全不写 ClusterAdmins 段，具体表现和 LSF 版本、安装方式有关，不同资料上的说法不完全一致（有的环境表现为默认落到 root，有的表现为安装时指定的默认账号）。与其纠结默认值到底是什么，不如直接把这件事变成“不需要关心默认值”——生产环境应该在安装后第一时间显式配置 ClusterAdmins，用专门的服务账号（如上面例子里的 lsfadmin）做主管理员，不要依赖任何隐式默认行为，也不建议日常使用 root 身份做集群管理操作。
3.4 主管理员 vs 集群管理员 vs 队列管理员 vs 组管理员
CAD Farm 里的运维团队通常有好几个人，权限颗粒度建议按下表分层设计，而不是所有人共用一个账号或者所有人都给集群管理员权限：
角色 | 配置位置 | 权限范围 |
主管理员 (Primary LSF Administrator) | ClusterAdmins 第一个用户 | 拥有配置文件与日志文件的属主权限，可执行全部集群级操作、修改配置文件，建议专人专号，不日常使用 |
集群管理员 (Cluster Administrator) | ClusterAdmins 列表中其余用户 | 拥有集群级作业和队列管理权限（开关队列、管理任意用户的作业）；在不涉及配置文件写权限的前提下可执行相应的集群管理操作，但不拥有修改 LSF 配置文件的权限 |
队列管理员 (Queue Administrator) | lsb.queues 中该队列的 ADMINISTRATORS | 只能管理指定队列内的作业（挂起/恢复/切换队列/终止），不能修改 LSF 配置，也管不了其他队列 |
用户组管理员 (Group Administrator) | lsb.users 中 UserGroup 的 GROUP_ADMIN | 只能对本用户组成员的作业做有限操作（如切换队列），权限范围最窄 |
✅ 最佳实践：按「四级授权」模型来设计：主管理员专号、不日常使用，只在需要改配置文件时才登录；CAD Farm 的核心运维日常用集群管理员身份处理跨项目组的作业/队列问题；各项目组 Team Lead 作为自己项目专属队列的 ADMINISTRATORS；组内资深工程师担任 GROUP_ADMIN。这样即使某个集群管理员账号被误用，影响范围也止步于“作业和队列管理”，不会波及配置文件本身。
3.5 用 Windows 域账号 / 用户组做管理员（跨平台集群）
如果 CAD Farm 里混合了 Windows 主机（比如某些前端设计工具只有 Windows 版本），ClusterAdmins 也支持填 Windows 域账号或域用户组，需要用大写域名加反斜杠的格式：
Begin ClusterAdmins ADMINISTRATORS = lsfadmin DOMAIN01\\cad_admins End ClusterAdmins |
3.6 ClusterAdmins 变更后的生效与验证
这里有一个容易被忽略的细节：ClusterAdmins 变更的生效范围和普通 Host 配置变更略有不同，不能简单理解为“lsadmin reconfig + badmin mbdrestart 就一定完成”。IBM 官方对新增/修改集群管理员的步骤明确要求，要让各 Server Host 的 LIM 重新读取管理员信息，也就是需要多做一步 limrestart，具体顺序如下：
# 改完 lsf.cluster.cluster_name 的 ClusterAdmins 段后执行
# 1. 先做语法检查 lsadmin ckconfig -v
# 2. LIM 重新读取 lsf.cluster.cluster_name lsadmin reconfig
# 3. 让各 Server Host 的 LIM 重新读取新的管理员信息 lsadmin limrestart <server_host1> <server_host2> ...
# 4. mbatchd 重新加载配置 badmin mbdrestart
# 5. 验证当前生效的集群信息（含管理员账号） lsclusters |
⚠️ 注意：ClusterAdmins 变更后，管理员列表需要被各 Server Host 的 LIM 重新读取才能真正生效，因此第 3 步的 limrestart 不能省略——如果只做了 reconfig + mbdrestart 就认为改完了，新加的管理员账号在部分主机上可能暂时不能正常执行管理操作。
***lsclusters 的输出里会有一列 ADMIN，显示当前生效的管理员账号，可以用它做一次基本核实；更完整的验证建议按顺序来：先用 lsadmin ckconfig -v / badmin ckconfig -v 确认配置语法本身没问题，再用 lsid 确认当前 Management Host 和集群名，最后用 lsclusters / lshosts / bhosts 分别核对集群、主机层面的信息，而不是仅凭 reconfig 没报错就当作配置成功——具体每条命令输出的字段名以你实际安装的 LSF 版本为准。
四、生产环境值得配置的主机准入参数
上面几节讲的都是“集群内部已登记的主机该怎么配置”，还有一类问题在生产环境同样重要：怎么防止未登记、身份不明的主机随意向 Management Host 发请求、冒充集群成员。这类风险在开放网络环境的 CAD Farm 里并非纸上谈兵，值得在 lsf.conf / lsf.cluster.cluster_name 里配置以下几个参数做准入限制。
参数 | 配置位置 | 作用 |
LSF_MASTER_LIST | lsf.conf | 显式限定 Management Host 候选范围，前面 2.6 节已详细介绍，从 LSF 7 开始这是配置高可用集群的推荐做法 |
LSF_HOST_ADDR_RANGE | lsf.cluster.cluster_name | 限制允许加入集群的主机 IP 地址范围，主要用于启用了 Dynamic Host Configuration 的环境；如果安装时开启了动态主机功能，安装程序默认会给出一个“允许任意主机加入”的宽松值，生产环境务必收紧 |
LSF_REJECT_NONLSFHOST | lsf.conf | 设为 Y 时，拒绝来自未登记为 LSF 主机的请求，降低伪造/未授权请求进入集群的风险 |
***这几个参数属于集群安全加固范畴，本篇作为基础配置系列先提一下它们的作用和配置位置，帮助你知道“要收紧准入控制该往哪个方向找参数”；具体每个参数的取值语法、和 Dynamic Host Configuration 的联动细节，建议在真正需要开启动态主机管理时，结合官方文档针对自己的网络环境专门配置和测试，本文不展开完整示例。
⚠️ 注意：LSF_HOST_ADDR_RANGE 主要用于允许 Dynamic Host 加入的环境，是配合动态主机功能收紧准入范围的参数。如果你的集群明确不使用 Dynamic Host（本系列到目前为止讲的都是传统静态 Host 配置模式），按官方安全建议应该直接不配置这个参数，而不是配置一个看似安全实则宽松的地址范围——静态集群的主机准入本身就通过 Host 段显式登记来控制，不需要再叠加这个参数。
五、常见问题与下篇预告
5.1 常见问题
• 新加了一台主机，为什么 bhosts 里还是看不到？—— 检查是否只改了 lsf.cluster.cluster_name 却忘了执行 lsadmin reconfig + badmin mbdrestart；另外确认新主机上的 LSF 服务（lim/res/sbatchd）是否已经启动。
• model/type 填 ! 之后，探测出来的型号跟预期不一样怎么办？—— 用 lshosts 命令查看 LIM 实际识别的 model/type，如果不满意可以在 Host 段显式指定成 lsf.shared 中已定义的具体型号，不再依赖自动探测。
• 给一个已经在跑作业的主机改 server 从 1 改成 0，正在跑的作业会怎样？—— 不会被强制杀死，但该主机之后不会再接收新作业；建议低峰期操作，并用 badmin hclose/hopen 先手动关闭该主机接受新作业，等作业跑完再改配置。
• RESOURCES 列写的资源名跟 lsf.shared 没对上，会报错吗？—— 具体表现（是致命错误阻断 reconfig，还是仅记录 warning）和资源类型、配置位置、LSF 版本都有关系，不要预设“LSF 会自动忽略”。稳妥的做法是改完先用 lsadmin ckconfig -v 看检查结果，reconfig 之后再用 lshosts -l <主机名> 核实 RESOURCES 是否真的按预期生效，一切以实际检查和验证结果为准。
5.2 本篇小结
这篇讲清楚了 lsf.cluster.cluster_name 的整体结构、唯一必需的 Host 段怎么写（主机型号、架构、server/client 区分、静态资源标签、master 候选顺序），以及最值得重视的 ClusterAdmins 集群管理员权限该怎么分层设计。这些内容是整个 LSF 配置体系的地基——lsb.queues/lsb.hosts/lsb.users 里的一切策略，都建立在“这个集群到底有哪些机器、谁有权限管它们”这个前提之上。
下篇预告：自定义资源与阈值控制
下一篇《lsf.shared 自定义资源与 ResourceMap：精确控制资源的最小/最大用量》，会接着这篇里提到的 RESOURCES 列继续往下讲：怎么在 lsf.shared 里定义 Boolean/Numeric/String 三种资源类型、动态资源和静态资源的区别、ResourceMap 段怎么把 license、共享存储这类跨主机资源精确分配给指定机器，以及怎么给资源配置最小/最大使用量和各种负载阈值——这是把 EDA license、GPU、大内存这些稀缺资源真正管精细的关键一步。
网友留言：