简介Citrix ADCNSVPX-HyperV-13.0-47.24是面向在 Microsoft Hyper-V 上部署应用交付控制器的虚拟设备安装包适合需要实践负载均衡、SSL 卸载、应用防火墙与多云接入的网络工程师及运维学习者。压缩包共 6 个文件约 510.17MB包含 vhd 虚拟磁盘、vmcx/vmrs 虚拟机配置与状态文件、exp 导出文件及 xml 配置文件基本覆盖 Hyper-V 导入与初始化所需组件便于快速搭建实验环境并对照官方部署流程验证网络接口、VIP 与策略配置。已有 442 人学习说明该版本在同类实验资料中具备一定参考度。读者可据此熟悉 NSVPX 虚拟机的导入、资源分配与基础配置理解版本匹配对兼容性和性能的影响并围绕负载均衡、内容优化、多租户管理等知识点开展验证减少因环境不符造成的部署阻碍。1. 从一台卡在启动控制台的虚机说起NSVPX 在 Hyper-V 上要解决什么把 Citrix ADC 的虚拟化镜像 NSVPX 部署到 Hyper-V版本停在 13.0-47.24这件事表面上只是点几下鼠标的活。真正动手的人会发现问题不在策略写得对不对而在导入之后控制台黑屏、网卡认不出来、管理地址敲完重启就没了。这个组合要解决的是把四层到七层的流量调度能力从专用硬件搬进虚拟化资源池SSL 卸载、会话保持、健康检查、内容交换全都跑在一台虚机里按需扩缩不用等采购流程。适合自建机房和私有云里同时管网络与应用的那批人尤其是预算批不下来、但业务确实需要一台正经负载均衡器的时候。接下来按版本约束、虚机落地、配置闭环、排查、验证五段讲能抄的部分我尽量给全。2. 版本号拆开看13.0-47.24 在 Hyper-V 上能干什么、干不了什么选型阶段最容易犯的错是拿硬件设备的规格表去套虚拟化版本。硬件机器上有专门的加密协处理器和网络处理单元包转发和 TLS 握手不占主 CPUNSVPX 全部压在 vCPU 和内存带宽上中间还要穿过 Hyper-V 的虚拟交换机每个包都得走一遍分类器和扩展层。同一份配置脚本在物理机和虚机上跑出来的性能曲线完全不是一回事所以第一件事不是装是算账。2.1 虚拟化形态牺牲掉的那部分能力以及怎么提前算清楚硬件平台省下来的那部分开销虚机里必须自己补。具体补在两处一是加解密TLS 握手、批量加密全部吃 CPU 周期二是转发虚拟交换机没有专用转发芯片全靠宿主机的软件队列。所以规划时我一般不看厂商给的峰值宣传数只做两件事先用一颗 vCPU 压出这台宿主机上的实际包处理基准再拿业务峰值包量去除最后乘 1.5 倍余量。这个 1.5 不是拍脑袋是留给突发流量和宿主机上其它虚机争抢的时间片。TLS 要单独算一笔。握手是纯 CPU 操作跟吞吐不是同一个维度一个页面站点可能 QPS 高但流量小握手压力反而比大文件下载大得多。做法是把新建连接比例估出来用压测工具单独打一轮只握手不传数据的负载看 CPU 什么时候跑满。跑满的那个连接数才是这台虚机真实能承载的并发上限比任何规格表都准。功能层面绝大部分七层能力在虚机上是齐的真正受影响的是依赖硬件的那些大流量压缩、某些链路层特性、以及需要专用加速卡的场景。这些在虚拟化环境里要么禁用要么改用软件实现后性能掉一大截。判断标准很简单看某个特性的说明书里有没有需要特定硬件这类限定语有就别指望在 NSVPX 上开出来。还有一条容易被忽略许可。许可按吞吐分档装完不导入的话跑在一个很低的上限上表现出来的现象是配置全对、压不上去而不是报错。这一条坑过不少人排查时先看许可状态再看别的。2.2 三个前置条件虚拟机代次、磁盘类型、网卡型号Hyper-V 这边有三个参数在创建虚机那一刻就定死了事后改要重建。列成表格更清楚。项目建议取值原因虚拟机代次第 1 代镜像通常是 VHD 格式第 2 代要求 VHDX UEFI 引导直接挂不上磁盘类型固定大小动态扩展盘在扩容瞬间有明显 IO 停顿表现为周期性延迟抖动网卡合成网卡优先识别不到换旧版网卡合成网卡依赖集成服务旧版网卡是模拟设备兼容性好但吞吐打折动态内存关闭宿主机回收内存会让进程被换出表现为偶发无响应集成服务除时间同步外按需开启时间同步会和设备自身的 NTP 抢时钟源代次这一条是最容易翻车的。第 2 代虚机只支持 VHDX 和 UEFI而拿到的镜像多半是 VHD 加传统 BIOS 引导直接挂载的结果就是启动后停在一行提示上不动。别指望转换格式能救转换出来的 VHDX 依然是 BIOS 引导结构第 2 代虚机照样不认。老老实实用第 1 代磁盘挂 IDE 控制器。磁盘用固定大小这一点短期看不出差别跑上两周监控就能看到。动态扩展盘在写入量增长时需要先在宿主机上分配空间这个瞬间的 IO 延迟会直接传导到连接建立耗时上表现出来就是 p95 曲线每隔一段时间冒一个尖。系统盘所在的存储也尽量单独放别和日志量大的虚机挤一个卷。网卡要分两种情况说。合成网卡性能好走的是虚拟交换机的快速路径但要求镜像里有对应的集成服务驱动老版本镜像可能只带旧版网卡的驱动启动后进控制台敲命令只能看到一个 lo物理网卡根本没被枚举。这种时候把网卡型号换成旧版网卡Legacy Network Adapter一般就能认出来代价是走模拟路径吞吐会低一截。先跑通再优化顺序别反。2.3 构建号不是装饰配置语法与 NITRO 版本对齐13.0 是主版本决定 CLI 语法结构和 NITRO 的资源模型47.24 是构建号决定这一版修了什么、有没有引入新的默认行为。运维上要对齐三件事。第一台账里必须记构建号不能只写13.0。变更单上贴show ns version的原始输出出问题时能第一时间判断是不是构建差异导致的行为变化。第二配置文件不要跨构建号恢复。用show ns runningConfig导出的文本在低构建号上恢复可能报语法错误在高构建号上恢复可能静默丢掉新增字段。稳妥做法是恢复后逐条比对或者干脆只恢复业务对象系统级参数手工核对。第三NITRO 脚本里登录之后先读一次版本做兼容分支。同一套脚本在不同构建号上跑个别字段名或枚举值会变硬编码的结果就是批量任务跑一半红一片。# 登录后先核对版本、硬件抽象层与已启用特性避免脚本在错误的目标上执行 show ns version # 输出主版本与构建号确认是 13.0-47.24 show ns hardware # 查看 vCPU 数、内存、网卡枚举情况 show ns feature # 列出已开特性确认 LB / SSL 是否已启用 show ns license # 确认许可带宽档位排除能配但跑不动这四条命令建议做成一个检查脚本每次变更前先跑。show ns hardware在虚机上尤其有用能直接看到网卡认出来几张、vCPU 给了几颗比在 Hyper-V 管理器里猜要快。show ns feature里如果 LB 是关闭状态后面配的虚拟服务器全部不生效这个坑新手经常踩。3. 从 VHD 到能登录在 Hyper-V 上把 NSVPX 跑通的最小步骤前面算完账接下来是纯落地。这一段的目标很明确虚机能启动、控制台能进、管理地址能通、能打开图形界面。四步走完再谈业务配置跳步的结果往往是后面排查时分不清是网络问题还是配置问题。3.1 虚拟机规格怎么定一张参数表说清规格没有标准答案但有下限。低于下限的表现是配置能配、压不上去高于下限的代价是浪费宿主机资源。给一版常用的起步配置。参数起步值调整依据vCPU4按 2.1 的压测基准反推TLS 握手重的场景优先加核内存8 GB连接表、SSL 会话缓存都吃内存连接数上十万后要往上加系统盘按镜像给定大小固定大小 VHD不要小于镜像本身扩容涉及分区不推荐在虚机里做数据盘可选只在需要本地留存日志或缓存时加网卡3 块管理 1、数据 2双臂部署的最低配单臂可减到 2 块虚拟机代次第 1 代见 2.2虚拟交换机外部交换机内部交换机无法对外提供服务只适合做实验系统盘这块要多说一句。虚机里扩容系统盘不是把 VHD 调大就完事涉及分区表和挂载点直接在 Hyper-V 里改大小然后重启大概率得到一台起不来的机器。真需要更大空间常见做法是加一块数据盘挂到指定挂载点而不是动系统盘。网卡数量也要提前想。管理口和数据口分开是后续排查的基础管理面出问题时数据面还在转发业务不中断数据面出问题时还能从管理口进去看。挤在一块的省事做法在第一次故障时就会让你后悔。3.2 PowerShell 导入 VHD 并挂载管理网卡图形界面点也行但参数化之后可以复用重建虚机不用重新记一遍选项。下面这段在宿主机上以管理员身份跑。$vmName ADC-VPX-01 $vhd D:\vhd\NSVPX-HyperV-13.0-47.24.vhd # 镜像解压后的 VHD 绝对路径 $mgmtSw vSwitch-Mgmt # 已创建的外部虚拟交换机 # 1) 建一台第 1 代虚机先不挂盘 New-VM -Name $vmName -Generation 1 -MemoryStartupBytes 8GB -SwitchName $mgmtSw # 2) 固定 vCPU 与内存关闭动态内存避免被宿主机回收 Set-VMProcessor -VMName $vmName -Count 4 Set-VMMemory -VMName $vmName -DynamicMemoryEnabled $false -StartupBytes 8GB # 3) 把镜像盘挂到 IDE 控制器 0 号位置作为启动盘 Add-VMHardDiskDrive -VMName $vmName -ControllerType IDE -ControllerNumber 0 -ControllerLocation 0 -Path $vhd # 4) 管理网卡固定 MAC 并开启 MAC 欺骗原因见 3.4 Set-VMNetworkAdapter -VMName $vmName -Name Network Adapter -StaticMacAddress 00155D0A1B01 -MacAddressSpoofing On Start-VM -Name $vmName几点说明。第一步不挂盘、第二步单独挂盘比New-VM -VHDPath一步到位更可控因为可以显式指定 IDE 控制器和位置避免镜像被挂到 SCSI 上导致引导失败。-ControllerType必须是 IDE第 1 代虚机的 SCSI 控制器不能作为引导设备。Set-VMMemory里关掉DynamicMemoryEnabled是关键。开着动态内存宿主机在内存压力下会把虚机的内存页换出对一台要做实时转发的设备来说这个换出动作会直接表现为几秒钟的假死。监控上看到的是周期性无响应然后自己恢复很难往内存上想。MAC 地址用00155D开头是 Hyper-V 的习惯前缀后面自己编号。固定 MAC 的好处是后续做 DHCP 保留、ARP 绑定、上游交换机的端口安全策略时不用改配置。坏处是克隆虚机时容易连 MAC 一起复制这条留到第 5 章细说。3.3 控制台首配管理地址、默认路由、DNS虚机起来后通过 Hyper-V 管理器连控制台默认口令登录进的是命令行界面。第一次配管理地址必须在控制台做因为一执行完原来的访问方式就断了。# 在控制台 CLI 中执行先设配置层地址再声明 NSIP顺序不要反 set ns config -IPAddress 192.168.10.10 -netmask 255.255.255.0 add ns ip 192.168.10.10 255.255.255.0 -type NSIP # 默认路由只能有一条指向上游网关 add route 0.0.0.0 0.0.0.0 192.168.10.1 # 只允许通过 HTTPS 访问管理界面避免明文口令在网络上传输 set ns ip 192.168.10.10 -gui SECUREONLY # 配置落盘否则重启后全部回退 save ns configset ns config和add ns ip分开写是因为前者改的是管理配置层的地址后者是把地址声明成 NSIP 类型参与转发。两条命令的效果看起来一样实际作用范围不同只做前者的话图形界面能开但部分功能会提示地址未就绪。save ns config这条最容易忘。命令行里改的全部是运行配置落在内存里重启就没了。养成变更脚本末尾统一加这一句的习惯比任何流程规范都管用。配完之后用浏览器访问https://192.168.10.10能出登录框就说明管理面通了。这一步过了再去动数据面顺序反了的话一旦数据面配错导致整个虚机失联只能回控制台重来。3.4 加数据面网卡VLAN 标记与 MAC 欺骗开关管理面通了之后再加数据面。两块数据网卡分别对应入口和出口加到同一个或不同的虚拟交换机上取决于网络规划。# 追加两块数据网卡挂到业务交换机上 Add-VMNetworkAdapter -VMName ADC-VPX-01 -Name Data-In -SwitchName vSwitch-Data Add-VMNetworkAdapter -VMName ADC-VPX-01 -Name Data-Out -SwitchName vSwitch-Data # 数据面同样要开 MAC 欺骗否则虚拟交换机会丢弃源 MAC 不匹配的帧 Set-VMNetworkAdapter -VMName ADC-VPX-01 -Name Data-In -MacAddressSpoofing On Set-VMNetworkAdapter -VMName ADC-VPX-01 -Name Data-Out -MacAddressSpoofing On # 若采用虚拟交换机侧打 VLAN用访问模式指定 Set-VMNetworkAdapterVlan -VMName ADC-VPX-01 -VMNetworkAdapterName Data-In -Access -VlanId 100MAC 欺骗这一项必须讲清楚。Hyper-V 的虚拟交换机默认做源 MAC 校验只允许虚机发出的帧携带分配给它的那个 MAC。负载均衡设备做转发时要改写源 MAC不关掉这个校验帧会被直接丢弃表现出来就是配置全对、抓包能看到请求出去、回包永远不来非常像玄学问题查半天网络策略也查不出来。VLAN 打标只能在一处做。要么在虚拟交换机端口上做访问模式打标虚机里看到的是无标记帧要么在设备内部做 802.1Q 子接口。两头都打结果就是双重标签上游交换机看不懂直接丢弃。规划时先定死在哪一侧做写进文档后面加网卡时照着来。4. 让它真正干活虚拟服务器、服务组、监视器的最小闭环到这一步虚机已经能登录了但还只是个空壳。真正开始转发流量需要三个对象串起来虚拟服务器承接外部请求服务组管理后端成员监视器判断成员是否健康。三者缺一个流量都不会按预期走。4.1 单臂还是双臂虚拟交换机上先想清楚流量路径单臂的做法是进出都走同一块网卡靠 VLAN 子接口区分内外。省网卡但流量翻倍——同样一个请求进来一份出去一份都压在同一块虚拟网卡上虚拟交换机同一端口的双向大流量处理效率不如物理交换机容易在压测时先撞到虚拟交换机的瓶颈而不是设备本身。双臂是入口一块、出口一块路径清晰压测时能明确知道瓶颈在哪一侧。代价是多占一块网卡和一个交换机端口。除非宿主机网卡资源确实紧张我一般直接上双臂。不管单臂双臂后端服务器回包的处理都要提前想。默认情况下设备会做源地址转换后端看到的源 IP 是设备的 SNAT 地址回程只要路由能回到设备就行。如果业务需要后端看到真实客户端 IP就得关掉转换并把设备设为网关这时候网络拓扑要求更严格不是所有环境都能做。# 启用 USNIP让设备对后端做源地址转换后端无需把设备设为网关 enable ns mode USNIP # 若需要指定转换后的源地址用 netprofile 固定避免走后端回程路由异常 add netprofile np_snat -srcIP 10.10.20.10USNIP是使用子网 IP 做转换的开关属于全局模式开了之后所有走虚拟服务器的流量默认走转换。netprofile用在多出口场景把转换源地址固定成某个可达地址避免后端回程路由选错。这两个东西看着不起眼但一旦后端是多网卡多网段的环境不配的话回包永远回不来。4.2 用 NITRO API 一次下发整套配置图形界面配一遍能跑但要复制到第二套环境就得重来。NITRO 是设备提供的 REST 接口把配置写成脚本重建环境时一条命令跑完比手工点快得多也不容易漏。import requests, urllib3 urllib3.disable_warnings() # 实验环境自签证书生产建议导入 CA BASE https://192.168.10.10/nitro/v1/config sess requests.Session() sess.verify False # 1) 登录换 token后续请求靠 Cookie 认证 r sess.post(f{BASE}/login, json{login: {username: nsroot, password: CHANGE_ME}}, timeout10) sid r.json()[sessionid] sess.headers.update({Cookie: NITRO_AUTH_TOKEN sid, Content-Type: application/json}) def push(kind, body): 统一的下发入口200/201 成功409 视为已存在跳过其余打印原文 resp sess.post(f{BASE}/{kind}, jsonbody, timeout15) if resp.status_code in (200, 201): print(OK , kind) elif resp.status_code 409: print(SKIP, kind, already exists) else: print(FAIL, kind, resp.status_code, resp.text[:200]) # 2) 服务组并绑定健康检查监视器 push(servicegroup, {servicegroup: { servicegroupname: sg_web, servicetype: HTTP, lbmonitor: mon_http}}) push(servicegroup_servicegroupmember_binding, {servicegroup_servicegroupmember_binding: { servicegroupname: sg_web, ip: 10.10.20.11, port: 8080}}) # 3) 虚拟服务器最少连接算法绑服务组 push(lbvserver, {lbvserver: { name: vs_web, servicetype: HTTP, ipv46: 10.10.10.100, port: 80, lbmethod: LEASTCONNECTION}}) push(lbvserver_servicegroup_binding, {lbvserver_servicegroup_binding: { name: vs_web, servicegroupname: sg_web}})URL 命名规则要记牢/nitro/v1/config/资源名POST 新增、PUT 修改、DELETE 删除。带下划线的资源是绑定关系比如servicegroup_servicegroupmember_binding命名格式是父资源_子资源_binding写错一个字母就是 404。409 要单独处理。批量脚本跑第二遍时已经存在的对象会返回 409如果当成失败处理整个任务的退出码就是非零CI 里直接红灯。把 409 归到 SKIP脚本才能幂等。lbmethod的取值里ROUNDROBIN适合后端性能一致且请求耗时接近的场景LEASTCONNECTION适合请求耗时差异大的场景RESPONSETIME会按响应时间动态加权但需要监视器提供足够准确的耗时数据。默认我给LEASTCONNECTION绝大多数业务都能吃到好处。4.3 监视器三个参数怎么调才不误判监视器决定后端什么时候被摘掉。参数调得太激进后端一次 GC 停顿就被摘流量打到剩余节点造成雪崩调得太保守后端已经挂了还在接流量用户侧直接报错。# HTTP 监视器每 5 秒探测一次单次 3 秒超时连续 3 次失败判死 add lb monitor mon_http HTTP -interval 5 -resptimeout 3 -retries 3 -downTime 30 bind servicegroup sg_web -monitorName mon_http # 后端健康检查接口只认 GET 时用 ECV 显式指定方法与匹配串 add lb monitor mon_ecv HTTP-ECV -send GET /healthz\r\n -recv OK -interval 10 -retries 2判定时间 interval × retries resptimeout上面这组是 5×33最坏 18 秒摘除。downTime是延迟标记时间成员恢复后要等 30 秒才重新纳入防止抖动型故障导致流量反复切换。HTTP类型的监视器默认发的是HEAD /后端如果只对GET返回 200就会被误判成下线。这个现象很迷惑手工 curl 是通的设备上却显示 DOWN。改用HTTP-ECV显式指定方法就能解决。-send里的\r\n不能省少了它请求行不完整后端直接返回 400。探测频率也别一味调快。几十个后端成员、1 秒探测一次光是健康检查的流量就够后端喝一壶。一般 5 到 10 秒足够业务对故障切换极敏感的再压到 3 秒但要同步评估后端承接能力。4.4 SSL 卸载证书链、密钥与绑定顺序卸载的意义是把加解密集中到设备上后端只处理明文省掉每台服务器各自维护证书的麻烦。配的时候顺序有讲究。# 1) 证书与私钥先传到 /nsconfig/ssl 目录 shell ls -l /nsconfig/ssl # 2) 建立证书对象私钥不能带口令 add ssl certKey cert_wild -cert server.crt -key server.key # 3) 建前端 SSL 配置按需启停协议版本 add ssl profile ssl_front -sslProfileType FrontEnd -tls1 DISABLED -tls11 DISABLED -tls12 ENABLED -tls13 ENABLED # 4) 挂到虚拟服务器上再绑定证书 set ssl vserver vs_web -sslProfile ssl_front bind ssl vserver vs_web -certkeyName cert_wild顺序反了会报没有可用证书之类的错误因为set ssl vserver在部分构建上会校验当前是否有已绑定的证书。稳妥做法就是先建对象、再设配置、最后绑定。证书链是最常见的翻车点。server.crt里必须包含服务器证书和全部中间证书顺序是从服务器证书开始逐级往上根证书不要放——根证书在客户端本地就有放进去反而会增大握手包体积。链不全的表现是浏览器能打开、但部分安卓客户端和命令行工具报证书验证失败排查时容易误判成设备问题。私钥不能带口令。带口令的私钥导入时会提示输入但有些自动化流程没法交互最后得到的是一个空对象绑定成功但握手失败。上传前先转成无口令格式省事。5. 避坑与排查Hyper-V 上跑 NSVPX 的 5 个翻车现场这些坑的共同点是配置看着全对现象却完全不讲道理。下面每条都按现象、原因、解决写方便对着排查。5.1 控制台停在一行启动提示不动反复重启现象虚机加电后控制台只显示一两行引导信息然后长时间无输出或者进入重启循环。原因虚拟机代次选成了第 2 代。第 2 代只支持 UEFI 引导和 VHDX而镜像盘是 BIOS 引导结构的 VHD两者对不上引导程序找不到入口就停在那里。解决删掉重建-Generation 1磁盘挂 IDE 控制器 0 号位置。已经转成 VHDX 的也别指望救回来格式转换不改引导结构重建最快。5.2 控制台里地址正确ping 不通网关现象控制台里show interface看到地址和掩码都对ping网关全是超时ARP 表里网关那条记录一直是未完成状态。原因虚拟交换机的源 MAC 校验把帧丢了。设备转发时要改写源 MAC虚拟交换机发现不是分配的那个 MAC直接丢弃。另一种可能是 VLAN 在虚拟交换机端口和设备内部各打了一次双重标记被上游丢弃。解决Set-VMNetworkAdapter -MacAddressSpoofing On打开VLAN 只在一侧配置要么虚拟交换机访问模式要么设备内部子接口二选一。改完重启网卡或者重启虚机生效。5.3 克隆出来的第二台管理地址互相打架现象两台设备同时在线管理地址的 ARP 记录在两个 MAC 之间来回跳登录时有时连到这台有时连到那台。原因克隆虚机时把静态 MAC 一起复制了。两台虚机在同一个虚拟交换机上用了同一个 MAC交换机学习到的端口不断切换。解决克隆后立刻改 MACSet-VMNetworkAdapter -VMName 新虚机名 -DynamicMacAddress让它自动分配或者手工指定一个不冲突的静态值。台账里给每台虚机记一个 MAC编号用完再回收。5.4 两台设备时间越跑越偏同步状态时好时坏现象双机部署下两台设备的日志时间差几十秒同步状态间歇性断开又恢复日志里能看到心跳超时的记录。原因Hyper-V 集成服务里的时间同步开着会和设备自身的 NTP 客户端抢时钟源。两个源给的偏差不一样时钟就被来回拉扯。解决关掉虚机的时间同步集成服务只保留设备内部的 NTP 配置。两台设备的 NTP 都指向同一个上游源偏差控制在秒级以内。5.5 改完配置直接重启配置回到出厂状态现象命令行里改了一堆show ns runningConfig能看到重启之后全没了恢复成刚导入时的样子。原因改的是运行配置没写进持久化存储。也有情况是脚本执行到一半中断前面的命令生效了最后的保存语句没跑到。解决变更脚本末尾统一加save ns config并且把这一条做成幂等操作——重复执行不影响结果。变更单里单独列一行已保存比事后回忆可靠得多。6. 上线前的验证清单和一个压测小技巧配置跑通不等于可以上线。上线前那半天我一般按一张固定清单过一遍每次都过不因为这次改动很小就跳。跳过的次数多了总有一次会还回来。验证项命令通过标准版本与构建号show ns version与台账一致无意外升级许可带宽show ns license覆盖业务峰值不是默认档位特性开关show ns featureLB、SSL、监控相关特性已启用虚拟服务器状态stat lb vserver vs_web状态 UP命中数随压测上升后端成员状态show servicegroup sg_web全部 UP无一处于过渡态证书有效期show ssl certKey剩余有效期大于一个变更周期时间偏差show ntp status与上游源偏差在秒级以内配置备份show ns runningConfig已导出并归档到变更记录压测阶段有个小技巧别只看压测工具那头的成功率同时开着设备侧的计数看。两个数对不上问题就在中间环节。# 压测期间每 2 秒采样一次虚拟服务器命中速率与丢包计数 # 字段位置随构建号略有差异先完整输出一次 stat 确认结构再调 awk while true; do printf %s $(date %T) stat lb vserver vs p a hrefhttps://download.csdn.net/download/weixin_43304263/88112869 stylecolor:#ec7500;font-size:14px; 本文还有配套的精品资源点击获取 /a img altmenu-r.4af5f7ec.gif srchttps://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif stylewidth:16px;margin-left:4px;vertical-align:text-bottom;cursor:text; /p