简介Citrix ADC原NetScaler ADC是一款应用交付控制器该资源是针对Microsoft Hyper-V平台的虚拟设备NSVPX特定构建版本号为13.0-47.24适合需要在超融合或虚拟化环境中部署负载均衡、安全防护与流量优化功能的企业运维、网络工程师及架构师。压缩包共6个文件包括XML配置文件、EXP虚拟机导出、VHD虚拟磁盘以及VMCX/VMRS虚拟机状态文件总体积约510MB可直接在Hyper-V管理器导入使用免去自行搭建镜像的麻烦。通过加载VHD磁盘并关联配置用户可以快速启动完整的ADC虚拟实例实践负载均衡、SSL卸载、内容缓存与压缩、应用防火墙、多租户管理以及AWS、Azure等公有云集成等企业级能力。该版本强调与不同虚拟化平台的版本匹配部署时需确认宿主系统的兼容性。已有440人学习下载适合作为功能验证、认证备考或生产环境预研的参考能够以较低的硬件成本获得接近物理设备的完整功能。1. 先别急着点亮浏览器这份 Hyper-V 版 NSVPX 到底装的是什么东西做接入层和负载均衡这块的同行对 Citrix ADC 这个名字应该不陌生也就是早年常说的 NetScaler。而当你拿到手的是 NSVPX-HyperV-13.0-47.24 这个包时第一反应别急着解压先搞清楚一件事这不是一个安装程序而是一个虚拟磁盘镜像里面跑着一整套完整的 ADC 操作系统。它跟你在 VMware 上用的 NSVPX-ESXi 是同源的只是交付格式和硬件适配层不一样。这个包解决的是在 Windows Hyper-V 环境里交付 Citrix ADC这件事。如果你所在的公司机房里没有单独的 ESXi 资源池只有 Hyper-V 集群又需要负载均衡、SSL 卸载、内容交换这些能力这个镜像就是最直接的落地方案。13.0-47.24 是 13.0 生命周期里一个偏中期的 build功能覆盖已经很全稳定性也经过了大量现网验证。适合的人群是虚拟化运维、网络工程师、做接入网关交付的集成商以及所有不想被硬件设备绑死、又必须在 Windows 虚拟化平台上跑 ADC 的从业者。2. 把 vhdx 抬进 Hyper-V镜像导入、网卡拓扑与三项基础资源约束2.1 从 zip 到 vhdx先分辨清楚交付物长什么样NSVPX-HyperV-13.0-47.24 下载下来通常是一个 zip 压缩包解压之后里面不是 ISO也不是 OVF而是 .vhdx 虚拟磁盘文件外加一两份 XML 或配置元数据。这个 vhdx 就是 ADC 的系统盘里面已经装好了完整的 FreeBSD 内核和 ns 核心进程。你不需要做任何安装操作系统的动作只需要把它挂到一台新建虚拟机上让虚拟机从这块磁盘启动即可。我一般会在解压后先做一次文件校验特别是从网盘或者中转站拿到的包谁也不敢保证传输过程没丢字节。Windows 下用 PowerShell 一行命令就能搞定Get-FileHash -Path .\NSVPX-HyperV-13.0-47.24.vhdx -Algorithm SHA256拿到哈希值和发布方提供的对照一下一致再往下走。这一步能帮你筛掉一大批启动到一半卡住的玄学问题。顺便说一句如果你拿到的是老版本的 .vhd 文件Hyper-V 也支持直接挂载但我建议用 Convert-VHD 把它转成 vhdx 再用性能和新特性支持都更好。Convert-VHD -Path .\NSVPX-HyperV-13.0-47.24.vhd -DestinationPath .\NSVPX-HyperV-13.0-47.24.vhdx -VHDType Dynamic注意 Convert-VHD 的 -VHDType 参数我习惯转成 Dynamic因为 ADC 系统盘实际用到的空间远小于磁盘标称值动态扩展能省不少宿主存储。转完之后记得看一眼目标文件大小确认转换没有中途报错。2.2 新建虚拟机的关键参数为什么 Gen1 而不是 Gen2、为什么关动态内存在 Hyper-V 里新建虚拟机时第一道选择题就是代数。NSVPX 这个系统引导方式对 Gen2 的 Secure Boot 支持得不好实测中经常出现引导中断或者直接掉到维护 shell 的情况。所以我的固定做法是 Generation 1别犹豫这是坑最少的路。内存这块是重灾区。Citrix ADC 的包处理引擎对内存极度敏感虚拟机的动态内存功能在 ADC 上会引发转发面随机重启的怪毛病网上搜一下就能看到大量类似案例。官方支持矩阵里也明确要求关闭动态内存。我一般会固定分配 4GB低于这个数跑全功能会紧张高于这个数在大多数场景下没必要。New-VM -Name NSVPX-13-0-47-24 -MemoryStartupBytes 4GB -BootDevice VHD -VHDPath D:\NSVPX\NSVPX-HyperV-13.0-47.24.vhdx -Generation 1 -Switch External-vSwitch Set-VMMemory -VMName NSVPX-13-0-47-24 -DynamicMemoryEnabled $false Set-VMProcessor -VMName NSVPX-13-0-47-24 -Count 4这里是几个关键参数-Switch 指定的是虚拟机要连接的外部虚拟交换机我通常提前建好一个专用的 Hyper-V 虚拟交换机再关联-BootDevice VHD 明确从磁盘引导Set-VMMemory 关掉动态内存并让启动内存保持固定不变。CPU 核数给 4 核这是折中方案核数太少 SSL 卸载和高并发新建连接会吃力太多又白白占宿主资源。磁盘控制器建议用默认的 IDE。如果你非要用 SCSI也不是不行但 13.0 某些 build 下 SCSI 控制器在启动阶段比 IDE 更容易出现磁盘识别延迟没必要为了这一点性能收益去冒启动风险。2.3 两张网卡的拓扑约定与 IP 规划前的物理准备虚拟机建好后网络拓扑是关键。Hyper-V 默认会给第一张网卡但 NSVPX 在 Hyper-V 上我建议至少挂两张网卡第一张作 Management 网卡第二张作 Client/Server 数据网卡。管理流量和数据流量混在一张网卡上短期看能跑一旦你配置了内容交换或者大规模负载均衡策略管理面会被数据面拖垮具体症状是后台登录奇慢、CLI 敲命令卡顿。Add-VMNetworkAdapter -VMName NSVPX-13-0-47-24 -Name DataPort0添加完第二张网卡后在 Hyper-V 管理器里确认两张网卡分别连接到正确的虚拟交换机。如果 Management 和数据面要走不同 VLAN交换机侧要配好 trunkVPX 内部再用 VLAN 标签区分。这里有一个隐藏坑如果后续你要做 HA 主备切换必须在虚拟交换机的高级功能里勾选启用 MAC 地址欺骗否则主备切换时 VIP 对应的 MAC 地址漂移会被 Hyper-V 直接拦掉表现为两台设备状态都 UP 但业务不通。提示MAC 地址欺骗这个选项不是默认开启的很多人做完 HA 之后发现切换不生效八成是忘了这一步。3. NSIP 上车首次启动、CLI 向导与地址规划的三类地址3.1 第一次开机从串口 console 看到什么把虚拟机启动起来通过 Hyper-V 的虚拟机连接窗口打开控制台你会看到标准的 FreeBSD 引导日志然后是 Citrix ADC 的欢迎界面。第一次启动时如果没有 DHCP 服务器系统会走一套交互式向导让你输入 NSIP、网络掩码、默认网关。整个过程跟在物理设备上第一次开机一模一样没有图形界面全靠键盘操作。NetScaler Version: 13.0-47.24 Copyright (C) 1999-2021 Citrix Systems, Inc. Please enter NSIP [0.0.0.0]: 10.10.10.2 Please enter Netmask [255.255.255.0]: 255.255.255.0 Please enter Default Gateway [0.0.0.0]: 10.10.10.1 Please enter DNS Domain Name []: adc.local Please enter DNS Name Server(s) []: 10.10.10.10这段交互里每个字段都有含义NSIP 是 ADC 自己的管理地址必须是一个静态 IP不能和后续要添加的业务 IP 冲突Default Gateway 指向你的核心交换机或路由器接口如果网关填错后面所有外部访问都会断掉DNS 一般建议填内部 DNS因为后续做 SSL 证书验证或者 NTP 解析时要用。如果你不想走交互向导也可以在系统提示前直接跳过然后进入 shell 手动配置。但我建议第一次部署让向导走完它可以帮你自动生成一份最小可用的 ns.conf 配置文件省掉不少手工拼配置的时间。3.2 NSIP、SNIP、VIP三张IP 表各司其职Citrix ADC 里的 IP 地址不是随便填的每个角色有严格分工。NSIP 是带外管理地址不参与业务转发SNIP 是子网 IP用来和后端服务器通信相当于数据面出发的源地址VIP 是虚拟服务地址客户端访问的就是它。三者不能在同一个网段里互相占用其中 SNIP 和 NSIP 尤其要分开这是新手最容易犯的错。地址类型作用域是否参与数据转发典型用途NSIP管理面否SSH/HTTPS 登录、CLI 管理SNIP数据面是和后端服务器通信的源地址VIP数据面是发布负载均衡或接入服务在 Hyper-V 部署场景里我见过有人为了省 IP 把 NSIP 和 SNIP 放同一个网段结果后端服务器回包时路由错乱业务时通时断。这个问题的根源在于 ADC 的转发逻辑会对源地址做严格校验属于设计层面的保护机制不是 bug所以别想着绕过它。3.3 用命令把初始网络固化下来set ns config 与 save ns config向导走完之后进入完整的 CLI 界面你会看到 ns 提示符。这时候第一件事不是急着配负载均衡而是把网络参数固化保存。后续任何配置改动只有执行了 save ns config重启之后才会保留下来。set ns config -ip 10.10.10.2 -netmask 255.255.255.0 -gw 10.10.10.1 add ns ip 10.10.20.2 255.255.255.0 -type SNIP save ns configset ns config 负责管理地址和网关参数add ns ip 是添加一条额外的 IP 地址记录-type SNIP 明确告诉系统这条 IP 用作数据面源地址。save ns config 把当前运行配置写入磁盘持久化。如果你的环境有 DNS 和 NTP 需求顺手一起配上set dns nameserver 10.10.10.10 set ntp server 10.10.10.11配置完成后用 ping 验证连通性。注意 ping 的源地址会因为目的地址不同而变化如果想强制从某个 IP 发起可以在 ping 命令里指定 -srcIP 参数。第一次部署时把网络层彻底验证通了再往上层走否则后面排查问题时会怀疑人生。4. 13.0-47.24 的落地配置启用功能、证书装载与 License 激活4.1 13.0 的版本特征和当前 build 的使用边界13.0 这个版本相比 12.1 有几个明显变化首先是命令行的命名规范更统一其次是对 TLS 1.3 的支持更完整。47.24 这个 build 属于 13.0 的中前期版本稳定性口碑不错但它毕竟不是最新 build如果你要上一些特别新的硬件特性或协议特性建议先查一下 Citrix 官方发布说明里的 Known Issues 列表。我的习惯是每拿到一个新环境的 NSVPX 版本登录后先执行 show ns version把 build 号和平台信息记下来再动手。show ns version这条命令的输出会包含完整的版本字符串、build 序号和平台类型。做版本确认的意义在于后续所有配置命令的语法兼容性和 license 适用性都跟 build 强相关。比如某些 13.0 早期 build 对 SSL 证书格式的支持范围就不如后期 build 全你从 CA 拿到的证书如果解析报错先检查 build 再检查证书本身。4.2 enable feature 到 SSL 证书装载的完整命令链Citrix ADC 的功能是按模块授权的。默认情况下负载均衡和 SSL 这两个核心功能都是关闭状态必须手动启用。启用之后系统会提示重启重启完成后功能模块才会真正加载。enable ns feature LB SSL reboot这里 LB 是 Load Balancing 的缩写SSL 对应 SSL 卸载功能。如果你后面还要做内容交换或者接入网关把 CS、Rewrite、Responder 一起开掉也行但我倾向于按需启用功能开得越多系统启动时的资源占用越重攻击面也更大。重启回来之后用 show ns feature 确认功能状态show ns feature确认 SSL 功能已启用后把 SSL 证书上传到 VPX。在 Hyper-V 场景下我最常用的上传方式是 SCP直接把证书文件推到 /nsconfig/ssl/ 目录下。这个目录是持久化存储重启不会被清空。scp server.crt server.key root10.10.10.2:/nsconfig/ssl/然后登录 VPX执行证书装载命令add ssl certKey cert1 -cert /nsconfig/ssl/server.crt -key /nsconfig/ssl/server.keyadd ssl certKey 的参数里cert1 是你给这个证书起的内部名称后面绑定 vserver 的时候要用-cert 和 -key 分别指定证书文件和私钥文件的路径。装载成功后会输出证书的基本信息包括有效期和签发者。这一步做完SSL 卸载功能才有实际的支撑材料。4.3 License 文件部署与 show license 确认License 是最容易让人翻车的一环。VPX 在没有合法 License 的情况下会以评估模式运行功能受限且吞吐量被压到一个很低的值。把 license 文件放到指定目录后重启或执行 add license 命令激活。scp nslic.lic root10.10.10.2:/nsconfig/license/license 文件命名无所谓只要扩展名是 .lic 就行。放进去之后执行add license /nsconfig/license/nslic.lic reboot重启之后用 show license 验证如果输出里显示的容量和型号跟你预期的一致说明激活成功。这里有个细节license 文件是绑定平台类型的VPX 的 license 不能用在物理机 NetScaler 上反之亦然。如果你在 Hyper-V 上装了 NSVPX却拿了一台 MPX 的 license 文件去激活系统会直接拒绝。5. 排错与避坑从平台版本检查到 HA 不同步的五条血泪记录5.1 报错 this product may not be installed on a computer that has microsoft hyperv in现象安装或启动过程中直接弹出一段英文提示大意是此产品可能无法安装在带有 Microsoft Hyper-V 的计算机上安装流程中止。原因Citrix ADC 的安装程序在启动阶段会对宿主 Hyper-V 平台做版本检查。如果宿主机的 Windows Server 版本过老、Hyper-V 角色不是标准安装或者你是在一台已经虚拟化的机器里再开嵌套虚拟化跑 Hyper-V检查就会判定平台不受支持直接中止。另一个常见诱因是虚拟机代数不对Gen2 的 Secure Boot 环境也会触发类似的检查失败。解决先把宿主系统补丁打全Windows Server 2016 或 2019 的 Hyper-V 是目前兼容性最好的然后在 Hyper-V 管理器里确认虚拟机是 Gen1最后关掉嵌套虚拟化用 PowerShell 的 Get-VMHost 查看当前 Hyper-V 版本信息确认版本号大于 6.2 再继续。这个报错不是你拿到手的镜像有问题而是宿主环境不满足 NSVPX 的支持矩阵。5.2 内存配置不当导致启动后随机重启现象VPX 正常运行几小时后突然掉线控制台里看到系统自动重启重启完又能用一阵子然后循环往复。原因虚拟机启用了动态内存。ADC 的包处理引擎和内存管理系统是深度耦合的Hyper-V 的动态内存回收会对 ns 内核的内存分配行为产生不可预知的干扰随机触发内核 panic。解决关闭动态内存固定分配 4GB同时检查宿主机的可用物理内存是否充足避免其他虚拟机抢占导致实际分配不足。用 Set-VMMemory 强制固定内存后观察 24 小时这个坑基本不会再犯。5.3 流量黑洞多网卡与巨型帧引发的问题现象负载均衡服务配置完成后客户端访问 VIP 时通时不通后端服务器能收到请求但回包丢失抓包看到大量 TCP 重传。原因Hyper-V 外部虚拟交换机默认 MTU 是 1514而物理交换机如果开启了巨型帧两边 MTU 不一致会导致分片和重组异常。另一个原因是给 VPX 配了多张数据网卡但没有正确配置 VLAN 或路由导致回包从错误的网卡发出。解决先统一 MTU把物理网卡和虚拟交换机的 MTU 改成一致VPX 侧用 set interface 命令把对应网卡的 MTU 也改掉。然后检查数据网卡的 VLAN 设置和静态路由表。至于多网卡选路问题我的做法是只保留一张数据网卡承担转发另一张只作为备用通道降低排查复杂度。5.4 License 装载后仍显示 evaluation 状态现象明明已经把 .lic 文件放到了 /nsconfig/license/ 目录重启之后 show license 显示的仍然是 evaluation mode。原因最常见的是文件权限错误。SCP 传输时如果用的是 root 账户问题不大但如果 tar 解压或者从 Windows 复制时保留了错误权限ns 进程读取不了文件。另外license 文件的平台类型与当前 VPX 平台不匹配也会导致读取失败。解决登录进 shell执行 ls -la /nsconfig/license/ 查看文件权限确认为可读状态。然后核对 license 文件内容里的平台字段确认是 VPX 平台。如果都没问题手动执行 add license 命令并观察输出报错信息根据报错字段逐一排除。5.5 HA 心跳不同步主备状态一直显示 NOT UP现象两台 VPX 配置完 HA 后show ha status 显示对端节点始终是 NOT UPHA 组无法建立。原因心跳网卡的流量没有走对虚拟交换机或者 Hyper-V 的端口安全策略拦掉了心跳包。另一个隐蔽原因是两台机器的 NSIP 被放在了同一个网段导致 HA 消息被自身路由逻辑干扰。解决在 Hyper-V 管理器里确认两台 VPX 的心跳网卡连接在同一台虚拟交换机上VLAN 设置一致。然后在 CLI 里用 ping 测试对端 NSIP通则继续排查 HA 配置不通则先修网络。最后检查两台设备的 NSIP 是否在同一网段是则改掉一台。6. 从单机到 HA在 Hyper-V 上把两台 VPX 做进同一个主备组6.1 为什么我在 13.0 上仍坚持用 L2 HA 而不是 Cluster13.0 已经把集群Cluster支持做得很完善理论上三台 VPX 可以组成集群实现真正的横向扩展。但在 Hyper-V 平台上我更推荐用传统的 L2 HA 主备模式。理由很简单集群需要共享存储来同步配置和会话信息而 Hyper-V 的共享存储方案往往依赖 SMB 3.0 或 iSCSI这些基础设施本身就有一堆可故障的点。L2 HA 只需要两台 VPX 之间有一条二层可达的心跳链路组网简单切换逻辑成熟对于绝大多数企业接入和负载均衡场景完全够用。6.2 配 HA 的完整命令序列下面是一套我在生产环境里验证过的 HA 配置命令假设两台 VPX 的 NSIP 分别是 10.10.10.2 和 10.10.10.3# 第一台主节点 enable ha node -haPeers 10.10.10.3 set ha node -id 1 -ip 10.10.10.3 -state ENABLED save ns config# 第二台备节点 enable ha node -haPeers 10.10.10.2 set ha node -id 1 -ip 10.10.10.2 -state ENABLED save ns configenable ha node 声明了对端地址set ha node 里的 -id 1 表示对端节点的编号-state ENABLED 让节点参与 HA 协商。配完之后在任意一端执行 show ha status如果输出显示 STANDBY 和 PRIMARY说明 HA 组已经建立。为了降低心跳被业务流量干扰的概率可以在两台设备间加一条独立网段专门跑 HA 心跳。这就用到前面提到的第二张网卡用 add ns ip 添加一个专门的心跳 IPadd ns ip 192.168.99.1 255.255.255.0 -type HA然后重新指定 HA 心跳通信地址这一步不是必须的默认会用 NSIP 通信但独立心跳网段能显著提升 HA 的稳定性。6.3 验证命令show ha status 与 nsconmsg 的判读配完 HA 不是终点验证切换才见真章。先执行 show ha status确认两台设备的状态和优先级。然后做一次主动切换测试force ha failover这条命令会让主节点主动让位触发主备切换。切换完成后原备节点应变为 PRIMARY原主节点变为 STANDBY。这时候去访问 VIP业务应该几乎无感知地继续运行。这个过程中重点关注 Hyper-V 端 MAC 地址欺骗是否生效如果业务断了优先去虚拟交换机的高级功能里确认那个选项。最后用 nsconmsg 看一眼 HA 相关的内核计数器nsconmsg -g ha_ -d stats输出里会显示 HA 消息收发次数、切换次数、心跳延迟等关键指标。心跳延迟如果稳定在个位数毫秒说明 HA 链路健康如果数值忽大忽小先怀疑虚拟交换机上有没有其他大流量虚拟机在抢占带宽。我在一次夜里变更中因为漏掉了 MAC 地址欺骗这个开关整个接入链路在主备切换后瘫痪了二十分钟现场客户盯着我蹲在机房里改虚拟交换机配置。从那以后我每次在 Hyper-V 上交付 NSVPX都会把先开 MAC 欺骗、再配 HA这条写进部署清单强制走一遍才做业务配置。这套东西说到底不难难的是把琐碎的坑一个个提前踩平。希望帮到你。本文还有配套的精品资源点击获取