1. 先把“许可合规性检查”这件事说清楚1.1 合规检查和“连不上许可服务器”根本不是一回事很多人把 ANSYS 许可问题笼统叫成“license 有问题”但在实际工作里这两类事情差异非常大处理思路也完全不同。第一类是可用性问题表现为客户端弹窗报connection timed out while reading data、failover feature ansys electronics_desktop is not available、求解器一启动就提示去看 Mechanical User Guide 的故障排除章节。这类问题的目标是“尽快让活干下去”。第二类才是合规性问题关心的是合同上买了多少个并发、license 文件里写的是不是这个数、实际跑起来有没有超过、谁在用、用在哪台机器上、有没有把授权范围之外的人拉进来。前者的判据是“能不能算”后者的判据是“该不该算”。我见过不少团队服务器一直跑得好好的直到厂商发来一份许可使用审计函才发现自家采购的 8 个 Fluent 并发日志里峰值到了 19 个而且一部分占用来自已经离职的员工账号。所以这篇内容讨论的是第二类工作以工程可用性为底的许可合规体检。它既是运维动作也是管理动作最终交付物应该是一份能拿给采购、法务、IT 三方看的报告而不是一句“服务器是好的”。1.2 四类必须提前分清的许可形态做检查之前如果连自己手上是哪种授权都没分清后面所有数字都是错的。ANSYS 的授权体系是以 FlexNet Publisher业内习惯叫 FlexLM为底层再叠加 ANSYS 自己的一层 Licensing Interconnect 互联层。落到你手上的形态大致能归成四类授权形态绑定方式典型特征合规检查重点独立式Standalone绑定客户端机器网卡 MAC本机一个 license 文件无服务器进程MAC 是否漂移、是否跨机复制网络并发式Network绑定许可服务器服务器发许可客户端按需占用并发峰值、拒绝率、闲置率弹性/令牌式Elastic、HPC 增量绑定服务器 计量按算力单元或核数计费核数是否超档、计量是否对账命名用户式Named User绑定账号身份一人一份绑定登录身份账号共享、离职未回收表格里最后一列才是合规检查真正要盯的东西。前面三列只是背景但缺了背景就没法判断“超用”这件事到底算不算超用。比如令牌式授权你超的是算力单元不是并发端口数用lmstat看一眼占用数是说明不了问题的。注意任何形态的授权范围都以合同和授权书原文为准。手册里写的默认值只是默认值不是你的授权边界。1.3 一次完整检查的骨架我把这件事拆成五步后面每个章节对应一步。第一步对文件把 license 文件和合同、授权书逐条对第二步对服务看许可服务器本身是否健康、配置是否与文件一致第三步对行为看客户端实际怎么占用的第四步对日志把数据落成证据第五步出报告形成整改清单。这五步里最容易跳过的是第一步和第四步。跳过第一步你可能拿一个已经过期或被改过的文件检查了半天跳过第四步你所有的结论都是“我感觉”一旦要跟厂商或内部审计对话拿不出东西。工程上有一句话我特别认同没有被记录下来的状态等于不存在。2. 许可文件与合同授权的一致性核对2.1 把 license 文件读成一张对照表license 文件本质是一个纯文本用SERVER行、VENDOR行、USE_SERVER行和一堆INCREMENT/FEATURE行描述授权。很多人拿到文件只会看开头和结尾中间那一大片INCREMENT直接跳过结果就是“买了什么”和“能跑什么”对不上。正确的读法是逐行抄成表。典型的一行长这样INCREMENT ansys ansyslmd 2025.1231 31-dec-2025 25 \ VENDOR_STRING... HOSTIDANY ISSUED... \ SN12345678 SIGN...拆解下来你要抄的核心字段就四个feature 名称、版本号、到期日期、数量。数量在行尾通常跟在签名字段前后是那个孤零零的数字。版本号决定了你只能用到哪个大版本到期日期决定了你什么时候会集体停摆。我一般会建议把INCREMENT行提取出来做个统计Linux 下一条命令就能出草稿grep -i ^INCREMENT license.dat | \ awk {print $2, $4, $5, $(NF-3)} | sort | uniq -c不同版本的文件字段位置会有差异awk里的$NF-3只是起手出结果后必须人工核对一遍。工具只是帮你少打几百次字判断还得靠眼睛。2.2 数量对不上是最常见的一类偏差数量对不上的情形主要有三种我按遇到的频率排序。第一种是升级换版时旧文件没清理服务器上同时存在两份 license客户端环境变量指向了旧的那份。表现是“明明加购了 10 个实际只能起 5 个”。这种问题查起来很快把文件里所有 feature 数量导出来跟最新的授权书逐条比一遍就露馅了。第二种是Feature 组合理解错误。ANSYS 的很多模块是捆绑的比如 Electronics Desktop 下面挂着 Maxwell、Icepak、Q3D Extractor 等一堆求解器但“能打开 Electronics Desktop”和“能跑某个具体求解器”经常是两件事。Speed 用户报ansys motor cad 线圈设计没有 license十有八九是买的是 Electronics Desktop 基础包而 Motor-CAD 是独立 feature压根不在授权列表里。检查时要把实际业务用到的模块名一个个拿去INCREMENT里搜搜不到就是真没有别指望重启服务器能变出来。第三种是借出许可Borrow没归还把并发池里的名额长期锁死在几台离线机器上。这个下一章会单独讲。2.3 独立许可绑定 MAC 时那个著名的 ffffff网络热词里有一条“ansys 安装 mac address 为 fffffff”这是独立式授权最典型的翻车现场。FlexLM 在独立式场景下要读客户机的网卡物理地址作为HOSTID如果它读到的是一串f说明它没有拿到有效网卡地址或者在多网卡机器上挑错了网卡。为什么会出现这种情况几个原因我都踩过。虚拟化环境里某些虚拟网卡会被过滤掉无线网卡在驱动没加载完全时读出来的就是全f笔记本插拔网线、切换 Wi-Fi 时网卡顺序变了FlexLM 挑到了另一块还有就是机器的休眠唤醒导致网卡驱动重载。处理思路倒不复杂先在命令行把机器所有网卡地址列出来找到那块稳定在用的有线网卡然后把它的地址填进 license 文件的SERVER行。Windows 下用getmac /v /fo listLinux 下用ip link。填进文件后注意地址格式要跟文件里其他位置的写法保持一致大小写和分隔符都别自作主张改。注意不要用虚拟网卡、蓝牙网卡、临时共享网卡的地址做绑定。这些地址在系统更新、驱动重装后极可能变化改一次就要重新申请一次授权非常折腾。更稳妥的做法是独立授权尽量集中在少数几台固定机器上别做成“谁需要谁装”的散装模式。散装模式下你连自己有几份授权在用都数不清。2.4 冗余服务器配置的三行 SERVER 必须严格对称网络授权的冗余三服务器容错配置license 文件开头会连着写三行SERVERSERVER lic01 001122334455 1055 SERVER lic02 001122334466 1055 SERVER lic03 001122334477 1055这三行的主机名、MAC、端口三者必须与三台服务器真实状态严格一致任何一个字符对不上就会出现failover feature ... is not available这种报错。原因在于 FLEXlm 的三机容错是靠投票机制维持的某台机器自认为的配置与另外两台不一致它就无法参与仲裁客户端在轮询到它的时候自然拿不到 failover 能力。检查时有几个硬规矩。三台服务器的时间必须同步到秒级时间漂移会让仲裁失败三台机器之间1055和2325两个方向都要通单向可达不算通SERVER行里的主机名必须在每台机器的 hosts 或 DNS 里能解析到另外两台。我处理过一次故障根源是其中一台机器的 hosts 文件里写的是旧主机名其他两台改了名它没改整整排查了两天才揪出来。3. 服务端配置与运行状态的健康检查3.1 双守护进程模型ansyslmd 和 ansysli_serverANSYS 的网络授权在服务端跑两层进程。底层是ansyslmd它是 FlexLM 框架里的厂商守护进程负责真正的许可发放和回收上层是ansysli_server它是 ANSYS Licensing Interconnect 的服务端负责聚合、排队、跨平台协调。客户端既要连ansyslmd的端口默认 1055也要连ansysli_server的端口默认 2325。理解这一点对排查很关键。客户端报“超时”的时候要分清楚是超时在 1055 还是 2325。我遇到过一批客户端报connection timed out while reading data. the application has stopped waiting for a reply. the license server may be experiencing a high demand or a temporary outage最后定位到是ansysli_server在高并发轮询下响应不过来而ansyslmd侧其实很闲。当时把客户端的环境变量精简成只指向必要的服务同时给许可服务器做了资源隔离超时就消失了。服务端的启停用官方脚本别手动kill# Linux 下典型路径 /ansys_inc/shared_files/licensing/ansyslmd start /ansys_inc/shared_files/licensing/ansyslmd stop /ansys_inc/shared_files/licensing/ansyslmd statusWindows 下走服务管理器服务名通常带ANSYS前缀或者在开始菜单里找 ANSYS Licensing 目录下的管理入口。管理界面默认在 1084 端口浏览器直接访问http://lic01:1084就能看到可视化的占用情况。这个界面是我最常用的第一手工具比敲命令直观。注意管理界面的端口和许可端口是两回事。放行防火墙的时候1055、2325、1084 这三个都要考虑少放一个都会出现“界面能打开但客户端连不上”的怪状态。3.2 lmstat 与 lmdiag 的实战用法命令行排查工具的核心就两个lmutil lmstat看状态lmutil lmdiag看链路。这两个工具在 ANSYS 安装目录的 licensing 子目录下都自带不用额外装。# 查看许可服务器整体状态 lmutil lmstat -a -c 1055lic01 # 只看某个特征的占用明细 lmutil lmstat -f ansys -c 1055lic01 # 诊断本机到服务器的链路 lmutil lmdiag -c 1055lic01lmstat -a的输出信息量很大我一般只盯三块Users of xxx那一段能看到谁占了哪个 featureup的时间判断服务是不是刚重启过以及末尾几行有没有Error。lmdiag用来判断“这台机器到底能不能连上服务器”它会依次尝试ansyslmd和ansysli的连通性哪个环节断了会明确报出来。再补一个 ANSYS 自带的工具ansysli_util看互联层状态很好用# Windows %AWP_ROOT242%\licensing\winx64\ansysli_util.exe -licstat # Linux ${AWP_ROOT242}/licensing/linx64/ansysli_util -licstat-licstat会把互联层当前连接的客户端、排队情况、可用槽位列出来。我在排查“明明池子空着却排队”的问题时全靠这个工具发现是某几个客户端反复重连把互联层的槽位占满了。3.3 端口、主机名和解析的三角关系许可服务器的故障里有一大类根因不在 ANSYS在基础网络和名字解析。三个要素必须同时正确客户端配置里的主机名、license 文件SERVER行里的主机名、DNS 或 hosts 里解析出的地址三者要指向同一台机器。我习惯在每台客户端上都做一次闭环验证先ping主机名再telnet两个端口最后跑一次lmdiag。三步都过了才认为这台机器的“通道”是干净的。任何一步不过先解决通道问题别去动 license 文件。IPv6 也是一个隐藏的坑。某些系统默认优先走 IPv6 解析而许可服务器只监听了 IPv4表现就是偶发性连接超时重试一次又好。处理办法是在客户端的 hosts 里把许可服务器主机名显式钉到 IPv4 地址上或者在客户端环境变量里强制 IPv4。3.4 服务自启与容错演练许可服务器最怕的不是慢是重启后没起来而没人知道。我建议至少做到两件事把许可服务配置成开机自启并设置失败自动重启每季度做一次容错演练手动停掉一台服务器看另外两台能不能正常接管。容错演练时要盯的是客户端表现而不是服务器进程状态。服务器进程活着不代表客户端拿得到许可。演练标准很简单三机全开时能算停掉一台还能算停掉两台还能算全部恢复后回到初始状态。这个演练我建议放在业务低峰期做并且提前通知用户不然很容易被投诉“你又把服务器搞挂了”。4. 客户端使用行为的合规审计4.1 并发占用的三个关键指标从合规角度看并发占用数字本身没意义有意义的是三个派生指标峰值并发、拒绝率、闲置率。峰值并发反映最坏情况下的占用压力如果它长期贴着授权上限说明要么买少了要么有人在不该用的时段占着。拒绝率是排队被拒的次数除以总请求次数这个指标超过一个很小的值就该警惕了说明用户体验已经受损。闲置率则反过来反映你买多了长期低于三成的利用率采购部门会问你要说法。这三个指标必须基于同一份日志、同一个时间窗计算不能一个从上月报表拿一个从这周的lmstat拿混着算出来的结论站不住脚。4.2 HPC 核数许可是最容易被忽略的合规红线ANSYS 的 HPC 授权按核数分档是增量的不是一次性买断全部核心。很多团队的认知停留在“我有 Fluent 许可那我就能并行算”这是错的。Fluent 的并行求解要额外消耗 HPC 授权核数超过授权档位时轻则求解器降级到串行重则直接报错中断。检查方法分两步。第一步从合同里确认买了多少核的 HPC 授权一般按 8 核一档递增具体以授权书为准。第二步抽样看实际提交的作业用了多少核。这一步要靠作业调度系统的记录或者从求解日志里读并行进程数。两边一比超出部分就是实打实的合规缺口。我见过最典型的场景是某个组为了赶项目把 32 核的作业直接扔进一个只买了 16 核授权的池子里结果求解器跑了一半报许可不足白算几个小时。这种事不只是合规问题还是实打实的算力浪费。注意不同版本对 HPC 核数的计数规则可能不同超线程、NUMA 节点这类因素会影响实际占用的档位。做审计时用同一版本、同一配置做基线别跨版本比数字。4.3 命名用户授权下的账号管理命名用户授权是按身份绑定的一个账号一份不允许共享。这类授权最容易出问题的不是技术是流程员工离职、转岗、外包人员进场账号没及时回收或开通就直接变成了合规缺口。检查动作要落到具体清单上导出当前所有能访问许可服务的账号跟人力资源的在职名单做交叉比对找出两边不一致的项。这里的关键是“能访问许可服务”这个名单怎么来——不是看谁装了软件而是看谁的身份在授权服务器上有记录。这一份名单通常要从授权平台的用户管理系统里导而不是从本地装机的清单里猜。账号共享的识别有一定难度但有一些间接信号可以参考同一账号在极短时间内在多台地理位置分散的机器上申请许可同一账号一天内的在线时长明显超出正常工作时长某个账号的许可占用模式与它所属岗位的业务特征完全不匹配。这些信号单独看都不足以定性但组合起来就很说明问题。4.4 借用许可与租期到期的临期管理部分 feature 支持借出让用户在离线状态下也能用一段时间。借用机制的合规风险在于“借出去容易还回来难”。借出的许可是从并发池里直接扣掉的如果用户把机器一关就是几个月这部分授权就相当于被永久占用了。检查借用状态用这条命令lmutil lmborrow -status -c 1055lic01 lmutil lmborrow -clear -c 1055lic01第一条查看当前借出列表和到期时间第二条用于强制回收慎用会中断离线用户的工作。我建议把借用做成有审批、有台账的动作借出时登记机器、人员、预计归还日期到期前一周自动提醒。跟借用同样需要临期管理的是 license 文件本身的到期日期。我建议在日历里给每个到期日提前 90 天、60 天、30 天各设一个提醒而不是等到某天早上所有人都打不开软件才想起来。续期流程要走采购、走审批、走厂商周期经常按月算留 90 天都不算宽裕。4.5 用 INCLUDE 和 EXCLUDE 做最小权限隔离license 文件里其实支持写约束行用来限定某些 feature 只能被哪些客户端使用或者禁止哪些客户端使用。这是做权限隔离最直接的手段比在每台机器上做环境变量控制可靠得多。INCLUDE ansys USER alice HOSTID001122334455 EXCLUDE ansys_electronics_desktop HOSTID001122334499上面两行的含义是ansys这个 feature 只允许 alice 在指定机器上使用ansys_electronics_desktop禁止在某台机器上使用。这类配置在需要把高价值模块限定在特定团队、或者把外包人员的机器排除在敏感模块之外时非常有用。注意约束行写错会导致整个文件解析失败服务直接起不来。改完文件后先在测试服务器上验证一遍再推到生产。另外约束行数量过多会影响服务器启动速度几百行以上就要评估一下了。5. 日志取证与审计报告输出5.1 打开 report log 并确认采集完整合规检查要拿得出证据证据的核心来源是 report log。它记录了每一次许可的申请、发放、拒绝、释放是唯一能支撑“峰值并发是多少”这类结论的原始数据。启用方式是在 license 文件里加一行REPORTLOG指向一个可写目录同时通过管理界面把报告日志打开REPORTLOG /var/log/ansys/report.rl前面的号表示追加模式不加就是覆盖这个细节很多人会漏导致日志只留了最后一段。目录权限要确保许可服务进程能写否则日志静默不生成你还以为一直在采。采集完整性的判断标准是连续一个月内每天都有数据没有大段缺口。典型缺口来自服务器重启后目录权限变了、磁盘写满、日志轮转配置把旧文件删了。做审计前先确认日志连续再开始分析不然算出来的指标全是错的。5.2 关键指标的计算方式有了原始日志指标怎么算就相对机械了。峰值并发是“同一时刻处于占用状态的许可数”的最大值注意是同一时刻不是同一分钟内累计的不同用户数这两个概念经常被混淆混用会把峰值算高不少。拒绝率用“因无可用许可而被拒绝的请求数”除以“总请求数”。这里的拒绝要排除那些因为客户端配置错误导致的假拒绝比如主机名解析失败也会在日志里留一条拒绝记录它并不代表并发不够。闲置率是“授权数减去平均并发数”再除以授权数。这个指标对不同模块的意义不一样核心求解模块闲置率低是正常的某些专用模块长期闲置就该考虑是否续订。我把这三个指标的计算逻辑整理成一张对照表方便现场直接套指标数据来源口径要点异常阈值参考峰值并发report log 时间戳同一时刻的占用数持续贴近授权上限拒绝率report log 拒绝记录排除配置类假拒绝任一持续出现即需关注闲置率授权数 - 平均并发按模块分别算长期低于三成需说明阈值这一列只是参考值具体定多少要看业务特征。研发团队的夜间批处理会让峰值出现在非工作时段这是正常现象不能简单按“工作时间以外的占用都是异常”来判断。5.3 一份能拿得出手的审计报告长什么样报告的目标读者通常不是工程师所以结论要前置证据要后置。我给的结构一般是四段现状概述、数据摘要、风险项、整改建议。现状概述一两段话讲清楚授权形态、服务器拓扑、覆盖的模块范围。数据摘要放指标表一张表把峰值、拒绝率、闲置率列出来。风险项按严重程度排序每条都要能对应到合同条款或授权文件行号。整改建议要落到动作和责任人别写成“建议加强管理”这种没法执行的句子。报告里我最看重的是可追溯性任何一个数字都能顺着报告找到日志的哪一段、哪个时间、哪个账号。厂商来审计的时候你能当场翻出来这和翻不出来是完全不同的处境。6. 常见报错速查与踩坑经验6.1 高频报错对照表把热词里出现频率最高的几个报错整理成一张速查表日常排查直接对号入座报错信息常见根因优先排查动作failover feature is not available冗余三机配置不对称、时间不同步核对三行 SERVER、校时、双向连通connection timed out while reading data互联层压力大、端口未放行、IPv6 优先查 2325 连通、精简客户端变量no valid flexlicense 文件损坏或字段不完整校验文件、对比备份版本线圈设计没有 license该模块独立授权缺失在 INCREMENT 里搜 feature 名MAC 显示为 fffffff网卡读取失败或挑错网卡列网卡、换有线网卡地址求解器启动即报错许可不足或环境变量指向错误先确认环境变量再看池子占用这张表不是万能钥匙但能覆盖八成以上的现场问题。剩下两成往往是复合原因需要一边看日志一边做排除法。6.2 卸载重装的正确顺序“如何彻底卸载 ANSYS”是个高频问题原因就是装乱了。顺序错了残留的注册表项、服务、环境变量会让新装的版本继续指向旧配置表现出各种诡异症状。我推荐的顺序是先停许可服务再卸载主程序然后清理许可服务组件最后清残留。Windows 下还要手动检查服务列表里有没有遗留的 ANSYS 相关服务环境变量里有没有ANSYSLMD_LICENSE_FILE、ANSYSLI_SERVERS这类项。Linux 下重点检查/ansys_inc和/usr/local下的残留目录以及用户 shell 配置文件里的环境变量。注意卸载前一定要把 license 文件、客户端配置文件、自定义的脚本单独备份出来。重装之后再把这些文件放回去比重新配一遍省事得多也避免配错。6.3 几条踩坑心得第一别在生产服务器上直接改 license 文件。改文件之前先复制一份带日期的备份改完用ansyslmd restart重启重启后立刻跑lmstat验证服务起来了、feature 数量对得上。我有一次改完忘了重启客户端连了半天连不上最后发现服务还在用内存里的旧配置。第二别在业务高峰期做许可审计。审计动作本身会增加服务器负载尤其是拉 report log 和跑全量统计的时候。放在夜间或周末既不影响业务数据也更干净。第三别把lmremove当常规手段。强制踢掉某个占用中的许可会让对应用户的求解直接失败只在确认某个许可被僵死占用时才用用完记一笔台账。第四别只检查一次。许可是活的东西人员流动、项目上马、软硬件升级都会改变占用结构。我现在固定的节奏是季度做一次轻量检查年度做一次完整审计中间遇到报错随时抽查。这个节奏坚持下来就再没被厂商的审计函打得措手不及。最后再补一句实在话许可合规这件事最难的不是技术是让业务方理解“你现在多占一个并发未来就要多买一份授权”。把审计报告里的数字翻译成钱和风险比讲一堆技术细节管用得多。