不改软件不碰服务器，三种回收路子我们都走通了

整理旧服务器硬盘，翻出2019年许可服务器第一次彻底崩溃时的系统日志，现在看还能想起当时全公司停摆的恐慌。

那是我来这家公司第二年发生的事。当时用得还是FlexNet 11.10，服务器是一台老旧的Dell塔式机，系统盘就一块单机械盘，连RAID都没做。那天下午两点多，CAD设计组突然在群里炸了，所有人弹窗报错“无法获取许可证”。我远程连过去一看lmstat敲了没反应，服务进程直接卡死了。我试着重启服务，结果服务起不来，报“license file invalid”。打开license.dat文件一看，里面大部分内容变成了乱码——硬盘正好在那一瞬间坏了一个扇区，写到了授权文件所在的位置。我那时候急得满头汗，翻遍了共享盘没找到备份，找采购要原始的激活邮件，人家休假了电话打不通。一直到晚上七点多才通过供应商的紧急渠道重新生成了一份授权文件，恢复完服务全公司已经停摆了五个小时。那年头我根本不知道什么叫热备、什么叫自动备份，出事就只能干瞪眼，现在回想起来那天的处理过程简直惨不忍睹。

经历过那次之后我才开始琢磨，除了做好备份，怎么从根子上把许可的利用率提起来，别再让同样的事因为管理混乱再来一次。后来我折腾出三条完全不改软件也不碰服务器的回收路子，三条都跑通了。

第一条是用命令行方式手工强制回收闲置会话。FlexNet自带的lmremove命令可以直接干掉指定会话，不需要改任何配置文件，也不需要重启服务。我平时写了个小脚本，把lmstat输出的会话列表解析一下，按空闲时间排序，超过阈值就自动敲lmremove踢掉。这个脚本完全跑在服务器外面，不动FlexNet的任何文件。2019年那次事故之后我学到一个当时根本想不到的技巧——出事的时候如果服务崩了起不来，可以先手工把占用端口的进程杀掉，然后重新启动服务，而不是傻等着服务自己恢复。那次我等了快二十分钟一直在那边反复点重启，后来才发现是端口被僵尸进程占着没释放，杀了之后秒起。

第二条是用操作系统的计划任务做定时巡检，发现异常会话就自动发警告邮件给当事人，连续两次不改就直接通知组长。这套脚本只读服务器的输出，不改任何配置，原理跟探针一样。我当时的做法是在另一台机器上每天跑定时任务远程连上服务器执行lmstat，然后把结果解析成可读的表格发到管理员邮箱。2019年那次如果我提前有这套东西，出事前硬盘的SMART报警其实已经在系统日志里出现了很多次，我根本不知道去看。出了事之后我才发现那个硬盘早就在日志里报过好几次I/O错误了，我但凡每周扫一眼系统事件日志都能提前换掉那块盘。

第三条是把多个厂商的授权统一接到一个第三方管理平台上，在一个界面上控制所有许可的回收和调度。这个平台只跟License Server做协议层面的通信，不往服务器装任何东西，也不改授权文件。三家不同的软件厂商各有各的授权管理工具，我现在一个面板全管了。当年有个我根本想不到的应急技巧——如果主服务器挂了但硬件没坏，把授权文件拷到一台临时机器上改个IP，把原来的主机名配上，FlexNet照样认，十几分钟就能恢复服务，不用等到原服务器修好。这事2019年的时候我跟本不知道，当时还在那边等供应商重新发文件，一等就是五个小时。

最后说两个现在我认为绝对不能省略的容灾设置，少一个我都不敢睡安稳觉。第一个是每天凌晨定时把license.dat、option文件、还有整个FlexNet安装目录打包同步到一台独立的备用服务器上，同时备份到异地NAS，至少保留三份。2019年那次就是吃了单点存储的亏，一块硬盘坏了全玩完。第二个是准备一台低配的备用License Server，硬件不用太好，系统预先装好FlexNet，平时不开服务，但所有配置跟主服务器保持一致，授权文件也是同份。一旦主服务器硬件出问题，把备用机IP改一下、主机名改一下、服务一启，十分钟之内切过去。我当时哪有这个意识，这种事真再来一次我肯定扛不住。

现在这块旧硬盘里的日志我单独存了个档，不删，留着提醒自己别再犯同样的傻。亲测好使，这周已经帮3个同事解决了同款问题。