简介：PowerChute Network Shutdown3.zip 是面向数据中心运维与服务器管理人员的 APC UPS 电源管理工具包，针对 Windows Server 2003 的 32 位与 64 位环境，用于在断电、电压异常等电力故障下监控 UPS 状态并按策略安全关闭服务器，降低数据丢失与硬件损坏风险。压缩包共 4 个文件，约 38.98MB，包含可执行安装程序、PDF 安装指南、HTM 发行说明以及 INI 静默安装配置，分别对应部署、配置参考、版本变更与无人值守安装等用途，结构精简，便于快速查阅和批量部署准备。目前已有 328 人学习，适合具备一定服务器运维基础、需要为机房断电保护补全方案的中级读者。读者可从中获取电源监控、预警通知、自动关机、负载管理与远程管理等核心功能的落地参考，并借助安装文档和发行说明梳理版本要点与配置注意事项，为实际环境中的 UPS 联动关机方案提供较完整的基础资料。

1. 一台 UPS 顶不了十分钟：这套 APC UPS PowerChute 到底解决什么

机房只配一台 APC UPS，市电一断，电池表就开始跳秒。真正要命的不是断电那一下，而是断电后那几分钟没人知道该先关哪台机器、谁先停服务、谁最后断电。PowerChute Network Shutdown（下面简称 PCNS）干的就是这件事：它装在被保护的主机上，通过网卡和 UPS 的网络管理卡（NMC）通信，在电池耗尽前按设定顺序把操作系统安全关掉。这个压缩包 PowerChute Network Shutdown3.zip 里就是这一代 PCNS 的安装介质，面向 Windows 和 Linux 被保护节点，不是给 UPS 刷的固件，也不是监控大屏。适合手上有 APC UPS 加网络管理卡、被保护主机超过三台、又不想每次停电靠人肉 SSH 挨个关机的运维；单机 USB 直连、一台机器关机就完事的场景，装它反而多一层故障点。

2. 先看清通信链路：PowerChute、NMC、UPS 三者谁跟谁说话

装之前如果不把这条链路捋清楚，后面所有“连不上”“不关机”的排查都是瞎猜。PCNS 不是万能的中间件，它唯一的信源就是 NMC，NMC 一挂或者网络一断，PCNS 对 UPS 的认知立刻退化成“未知”。这一章先把角色、端口和前置条件钉死，再动手解包。

2.1 三个角色和四条通路：6547、80/443、161 各管什么

UPS 本体只负责供电和上报电池容量、负载、剩余运行时间、输入电压这些物理量，它自己不会关机，也不会通知谁。NMC 是插在 UPS 智能插槽里的那张卡，有独立 IP，对外提供 Web、SNMP、SSH，PCNS 收到的市电中断、低电量、电池故障事件全部由它发出。PCNS 是被保护主机上的守护进程加一个 Web 控制台，负责“收到事件、判断要不要关、执行关机”这三步。

把这三者的关系想成一条链：UPS 把状态喂给 NMC，NMC 通过网络把事件推给 PCNS，PCNS 在本机执行关机命令。链上任何一环断了，结果都不是“不关机”，而是“按另一种逻辑关机”，这个区别很关键，后面避坑那章会展开。

选网络关机而不是 USB 直连的理由也在这张表里：一台 UPS 加一张 NMC 可以同时保护十几台跨系统的主机，Windows、Linux、虚拟化平台都能挂上去，而 USB 线只有一根，只能保护插着它的那台机器。代价是多了一个 NMC 单点和一层网络依赖，所以端口和防火墙必须提前规划，不能等装完再补。

2.2 装机前必须过的六项检查

这一步偷懒，后面八成要返工。下面这六项我每次上线前都会过一遍，缺一项就先解决再往下走。

第三条最容易被忽略。很多人习惯“反正同一个机柜，肯定通”，结果 NMC 在管理 VLAN、主机在业务 VLAN，中间还隔了防火墙，发现按钮转半天列表空白。规划阶段就把 6547 的入站规则写进变更单，比装完再排查省事得多。

2.3 解包与安装：Windows 和 Linux 两条路

压缩包到手先别急着解，先看结构。安装介质里通常会把两个平台的目录分开，Windows 是 setup.exe 加依赖，Linux 是自解压安装器。下面这套动作我在测试机上跑过很多次，顺序别换。

# 1) 只列不解，先看清压缩包里的目录结构 unzip -l PowerChuteNetworkShutdown3.zip # 2) 解到独立目录，避免污染家目录 mkdir -p ~/pcns && unzip -o PowerChuteNetworkShutdown3.zip -d ~/pcns # 3) 按平台挑安装器：Linux 常见 .run/.bin 自解压，Windows 是 setup.exe find ~/pcns -maxdepth 3 -type f \( -name '*.run' -o -name '*.bin' -o -name '*.exe' -o -name '*.sh' \) -ls

unzip -l只读目录不解压，-o表示覆盖同名文件，-d指定落地目录；find里的-maxdepth 3是为了不让它钻进深层依赖目录刷屏，\( ... \)那一组是“或”条件，一次把所有可能的安装器捞出来。看清楚哪个是主安装器，再动手。

Linux 侧最关键的一步是执行权限，自解压安装器从压缩包里解出来默认没有 x 位。

# 自解压安装器必须先加执行权限 chmod +x ~/pcns/Linux/*.run # 交互项：安装路径、控制台端口、运行账号，端口默认 6547 不要改 sudo ~/pcns/Linux/*.run # 装完别硬背服务名，不同版本叫法不一样，先查再操作 systemctl list-unit-files | grep -i -E 'powerchute|pcns' systemctl status <上一步查到的服务名> --no-pager

chmod +x解决的是“装到一半提示权限不足”这类看似玄学的问题；sudo是必须的，服务要注册成系统级；list-unit-files加 grep 是为了拿到真实服务名，后面对日志、开机自启的操作全依赖它。

Windows 侧换个思路，关键是提权安装。

# 必须以管理员身份启动，普通双击会把服务注册到当前用户上下文 Start-Process -FilePath "C:\temp\pcns\Windows\setup.exe" -Verb RunAs # 装完确认服务和控制台端口 Get-Service | Where-Object {$_.Name -like '*PowerChute*'} Get-NetTCPConnection -State Listen | Where-Object {$_.LocalPort -eq 6547}

Start-Process -Verb RunAs等价于右键“以管理员身份运行”，避免权限不足导致服务注册失败；Get-NetTCPConnection过滤 6547，能立刻确认控制台端口有没有起来，比打开浏览器试地址快。

3. 把主机挂上 UPS：设备发现、认证短语与控制台登录

装完只是把软件放上去，真正的活是让它和 NMC 建立信任关系。这一步失败率最高，而且报错信息通常很含糊，所以顺序上先验连通、再做发现、最后对短语，一层一层往上叠。

3.1 第一步永远是端口通不通

不要先去点控制台里的“发现”，先用命令行确认基础网络。四组命令分别对应四种失败：HTTP 不通、6547 不通、本机没监听、包过不去。

# 1) NMC 的 Web 是否可达，-k 跳过自签证书校验，-I 只看响应头 curl -k -I --connect-timeout 3 https://192.0.2.10/ # 2) NMC 与本机之间的 6547 通道 nc -zv 192.0.2.10 6547 # 3) 本机 PCNS 侧是否真的在监听 ss -lntp | grep -E '6547|443' # 4) 抓包确认事件通道有没有握手成功的迹象 tcpdump -ni any host 192.0.2.10 and port 6547 -c 20

--connect-timeout 3把超时压到 3 秒，避免卡在不可达地址上等半天；nc -zv只探端口不传数据，做连通性初筛最省事；ss -lntp的-l是监听态、-n不做域名解析、-t只看 TCP；tcpdump的-c 20抓满 20 个包就停，防止在流控终端里刷屏。四条里前三条都正常、第四条抓不到任何包，基本可以断定中间有设备在静默丢包，去查安全组和 ACL。

Windows 侧对应的是这一组，思路一致。

# 测 6547 是否可达，比 telnet 客户端更可靠 Test-NetConnection -ComputerName 192.0.2.10 -Port 6547 # 查本机是否在监听控制台端口 Get-NetTCPConnection -State Listen -LocalPort 6547

Test-NetConnection的输出里TcpTestSucceeded为 True 才算通，False 时看PingSucceeded是否也为 False，能区分是主机不通还是端口被挡。

3.2 设备发现：广播只在二层，跨网段只能手填

PCNS 控制台里的“发现”按的是广播/组播逻辑，它发出去的探测包不会被三层设备转发。同 VLAN 里秒出结果，跨 VLAN 就永远是空列表，这不是软件坏了，是协议本身的设计边界。跨网段的正确姿势是手动填 NMC 的 IP，一个字符都不要省。

同一个网段里如果也发现不了，先回 3.1 的第四步抓包，看探测器有没有发出、有没有回应。有些交换机开了广播风暴抑制，会把这种低速率广播直接吞掉。另一边检查 PCNS 主机的防火墙，6547 的入站一定要放，NMC 要能主动连回来。

# firewalld：只放通管理网段，不要开成 0.0.0.0/0 sudo firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=192.0.2.0/24 port port=6547 protocol=tcp accept' sudo firewall-cmd --reload # ufw 环境等价写法 sudo ufw allow from 192.0.2.0/24 to any port 6547 proto tcp

source address限定来源网段是重点，6547 一旦对全网开放，等于把一个能触发关机的接口挂到公网上。--reload让永久规则立即生效，ufw 那条是对等写法，两种环境各取其一即可。

3.3 认证短语：两边必须逐字符一致的那串东西

NMC 侧有一个认证短语配置，作用是让“只有知道这串字符的客户端才能控制我”。PCNS 添加设备时要把同一串填进去，此外 NMC 上还要把 PCNS 主机的 IP 加进允许列表。三个条件缺一个，设备列表里就会一直显示未连接。

短语不一致是最常见的坑：大小写不同、尾部多一个空格、全角半角混用，肉眼几乎看不出来。核对办法是把它复制到一个十六进制查看器里对齐，别靠肉眼。还有双网卡主机，NMC 看到的源 IP 可能不是你预期的那个，这时候用路由查询确认出口。

# 确认本机到 NMC 走哪张网卡、源 IP 是哪个 ip route get 192.0.2.10 # 输出里的 src 字段就是 NMC 看到的来源 IP，NMC 白名单要写这个

ip route get会打印实际选路和src，这一步能省掉大量“我明明加白了却还是连不上”的争论。虚拟化环境里尤其常见：宿主机多网卡、虚机桥接选错，源地址跑到另一个网段去了。

4. 关机参数：三个时间量决定你会不会丢数据

链路通了以后，真正决定成败的是参数。PCNS 里跟关机相关的量看着多，核心就三个：剩余运行时间阈值、低电量时长、系统关机耗时。这三个数不是独立配置项，它们是一条时间轴上的三段，配错任何一段，结果要么是该关不关，要么是没关完就断电。

4.1 剩余运行时间、低电量时长与关机耗时的换算关系

剩余运行时间由 UPS 实时计算，随负载变化，满电时可能是 25 分钟，负载翻倍后可能只剩 9 分钟，它不是常数。低电量时长配置在 NMC 侧，表示“剩余运行时间低于这个值时宣布进入低电量状态”，典型值 2 到 3 分钟。系统关机耗时是你这台机器从执行关机到真正停机的真实秒数，必须实测，不能拍脑袋。

安全窗口可以按这个式子估：事件触发时剩余运行时间 − 低电量时长 − 实测关机耗时 − 60 秒网络与脚本开销。算出来如果是负数，说明阈值设得太晚，电池撑不到你关完。

这张表建议抄进变更单，每次改参数都对照一遍。特别是最后一行，它跟电池没关系，却最容易造成批量事故。

4.2 事件动作：哪些该关机，哪些只该告警

PCNS 的事件配置页一般会列出市电中断、低电量、电池故障、通信丢失、过载、温度异常这几类。默认动作未必适合你，逐条过一遍比全盘接受默认值靠谱。

市电中断不关机这条，很多默认模板是反的，或者模板里给了个很短的延时。我见过一次交换机堆叠切换，UPS 毫发无损，三台机器同时自己关了，事后查就是通信丢失被配成了立即动作。这个坑放到第 5 章细说。

4.3 多机顺序：用递增延时，别指望“同时触发”

一个 NMC 保护多台主机时，正确的顺序是数据库最后关、应用中间关、前端最先关。实现方式不是让它们同时收到事件再各自判断，而是给每台主机的关机动作设递增延时。数据库 0 秒、应用 60 秒、前端 120 秒，这样事件来的时候前端先走，应用还有时间把连接排空，数据库最后落盘。

如果 PCNS 支持在关机流程里挂自定义脚本，这段可以做得更细。下面是个钩子脚本的模板，思路是“短、幂等、绝不阻塞关机”。

#!/usr/bin/env bash # 关机前钩子：只做三件事，且必须在 10 秒内返回 set -euo pipefail LOG=/var/log/pcns-hook.log echo "$(date -Is) pre-shutdown triggered" >> "$LOG" # 1) 从负载均衡摘掉本机，避免请求继续打进来 curl -fsS -m 3 -X POST "http://192.0.2.50/api/drain" \ -d "{\"host\":\"$(hostname -s)\"}" >> "$LOG" 2>&1 || true # 2) 停有状态服务，给落盘留时间 systemctl stop app-server.service >> "$LOG" 2>&1 || true # 3) 刷盘，别让 page cache 背锅 sync

set -euo pipefail保证脚本出错就退出，不会带着半截状态往下走；-m 3把外部调用超时压到 3 秒，避免负载均衡接口挂了把整个关机流程卡死；每条命令后面的|| true是有意为之，钩子失败不能阻止系统关机，否则就成了“为了优雅而拒绝断电”。这个脚本的路径要在控制台里填对，填错等于没挂。

4.4 不进 Web 也能核对：配置文件与关键字段

控制台能用，但排障和批量核对时命令行更快。不同版本、不同系统的配置路径不完全一样，别猜，先定位再读。

# 先定位安装目录，别硬编码路径 sudo find /opt /usr/local -maxdepth 5 \( -iname '*powerchute*' -o -iname '*pcns*' \) 2>/dev/null # 找到配置目录后，核对四类关键字段 sudo grep -rniE 'ups|phrase|shutdown|delay|runtime' /opt/PowerChute/config 2>/dev/null | head -40

-maxdepth 5控制搜索深度，-iname忽略大小写，2>/dev/null把无权限目录的报错吞掉；grep 的-rniE是递归、显示行号、忽略大小写、扩展正则四合一，head -40防止输出过长。注意配置里的短语通常不会明文展示，能看到的更多是地址、阈值和延时，核对短语还是得回控制台。

5. 避坑与排查：五个真会翻车的点

下面五条都按“现象、原因、解决”写，每一条背后都是能让人半夜爬起来的那种问题。排障顺序建议从上往下，先排除通信，再看时间，最后看误动作，因为后两类问题经常是前一类伪装出来的。

5.1 通信类：发现不到、加进去又连不上

坑一：同网段能发现，跨网段永远空列表。现象是点了发现按钮转圈，列表空白，但手动填 NMC 地址却能连上。原因是发现走广播，三层设备不转发。解决是跨网段一律手动添加，同时确认 PCNS 主机 6547 入站放通，再用抓包确认探测包到底有没有到对端。不要在这上面反复点按钮，点一百次也不会通。

坑二：设备加进去了，状态一直是未连接。现象是控制台里 UPS 状态灰着，NMC 侧日志能看到认证相关报错。原因多半是认证短语不一致、NMC 白名单没写对，或者双网卡主机源 IP 跑偏。解决是两边逐字符核对短语，白名单按ip route get输出的 src 填，别按你记忆里的网卡地址填。

# 双网卡/虚拟化环境最容易出问题的一步 ip route get 192.0.2.10 # 用输出里的 src 去 NMC 白名单里核对，不要用 ifconfig 里的第一个地址

5.2 时间与顺序类：事件错序、没关完就断电

坑三：三台机器顺序乱套，数据库比应用先停。现象是恢复后应用日志里一片连接错误。原因是各主机与 NMC 时间不同步，所谓“同一时刻触发”实际差了几十秒；也可能三台的关机延时被设成了同一个值。解决是把所有主机和 NMC 指向同一 NTP 源，顺序用递增延时实现，而不是靠同时触发再各自判断。

# 确认时间同步状态，偏移超过 1 秒就要处理 timedatectl status chronyc tracking 2>/dev/null || ntpq -p

timedatectl看的是系统时钟与 NTP 是否同步，chronyc tracking或ntpq -p能给出具体偏移量。偏移几百毫秒看着不多，放到多机顺序场景里足够让事件错位。

坑四：系统还没关完，UPS 就切了输出。现象是下次开机 fsck 报错、数据库要做 journal 回放。原因是系统关机耗时被低估，或者某个服务卡住拖了九十秒。解决是实测一次完整关机耗时，把配置改成实测值加 60 秒余量，同时把低电量时长往上调一档。

# 找出拖慢关机的服务 systemd-analyze blame | head -10 # 回看上一次关机的日志尾部，确认卡在哪个单元 journalctl -b -1 -n 50 --no-pager | tail -20

systemd-analyze blame按耗时排序启动单元，虽说是启动视角，但拖慢启动的服务往往也拖慢关机；journalctl -b -1看的是上一次启动周期，也就是上次关机前后的日志，--no-pager防止输出被分页器截断。

5.3 误动作类：一次抖动关掉半个机房

坑五：UPS 一点事没有，几台机器集体自己关了。现象是交换机做了一次堆叠切换或者 NMC 重启，几台机器同时进入关机流程。原因是通信丢失事件被配成了立即关机，或者延时设得极短。解决是把通信丢失的动作改成不关机或仅告警，实在要动就延时拉到大于一次网络维护窗口；NMC 升级前先把这条事件临时禁用。

这个坑的隐蔽之处在于，事后看 UPS 日志干干净净，你会以为是主机自己抽风，其实是软件忠实地执行了你配的规则。

6. 上线前的拔电演练：把阈值拉高，看它到底会不会关

参数配完不代表能用，得让它真跑一次关机流程。真拔市电风险太大，我一般用“拉高阈值”的办法：先在一台非核心测试机上装好 PCNS，记下 NMC 页面上的满电预估续航，比如 25 分钟，然后把“剩余运行时间低于 X 分钟触发关机”里的 X 设成 30。市电正常、电池满电的情况下，剩余运行时间永远低于 30 分钟，事件会立刻被触发，整条链路从 NMC 到 PCNS 到钩子脚本到系统关机全部跑一遍。

这个办法的好处是不用碰配电，坏处是它会真的关机，所以只能拿测试机做，而且做完立刻把 X 改回去。演练时重点看四件事：钩子脚本日志有没有写、应用服务是不是按预期先停、系统从收到事件到完全断电用了多少秒、UPS 侧有没有记录到对应事件。四项里任何一项和预期不符，都别急着上生产。

演练完记得恢复三样东西：剩余运行时间阈值、低电量时长、通信丢失事件的动作。我吃过一次亏，测试时把阈值拉到 30 分钟忘了改回来，第二天早上负载一高，续航掉到 28 分钟，生产机直接进了关机流程，人还在路上。从那以后我每次动完阈值，都会在变更单上单独列一行“恢复项”，演练结束当着第二个人复核一遍才关单。

如果你手上正好有这套包和一张 NMC，建议先把第 2 章那六项前置检查过一遍，再拿一台闲置机器把第 6 章的演练跑通，剩下的就是照着表填参数。希望帮到你。

本文还有配套的精品资源，点击获取