Radware（Redware）负载均衡怎么用？功能解析、配置指南与常见误区一次讲清

一组后端节点明明在线，用户却仍被分配到故障服务器，这种情况多数不是硬件问题，而是负载均衡器的健康检查没有真正反映业务可用性。Radware（也常被写作Redware）的负载均衡产品线主要覆盖Alteon和AppDirector等应用交付控制器，核心能力是在L4到L7之间做流量分发、健康检查、SSL卸载和会话保持。使用之前先理解这些对象之间的关系，后续配置与排障会顺畅很多。

一、Radware负载均衡解决什么问题

传统单台服务器直接暴露公网或内网入口，一旦出现资源耗尽、进程崩溃或计划维护，所有请求都会中断。负载均衡器在前端接收客户端连接，再根据预设算法把流量转发给后端真实服务器组。Radware设备在这个基础上增加了应用层判断能力，例如可以根据URL路径、Cookie、HTTP头或响应内容做更精细的转发，而不只是看IP和端口。

核心价值体现在三个方面。第一是可用性，通过持续探测后端节点，自动摘除异常成员，避免用户感知到单点故障。第二是性能，SSL卸载能把加解密开销从前端真实服务器转移到专用硬件处理，后端只处理明文HTTP，吞吐能力通常明显提升。第三是可维护性，管理员可以对真实服务器分组做上下线操作，发布或回滚时不影响整体服务入口。

Radware平台中常提到的概念包括VIP、Real Server、Group和Health Check。VIP是客户端访问的虚拟IP，通常绑定在负载均衡器上；Real Server是实际处理业务的服务器；Group把多台Real Server组织成一个逻辑池；Health Check则决定一台Real Server是否继续留在池中。理解这些概念后，配置步骤基本固定。

二、配置前必须理解的关键对象与基本流程

先梳理典型配置流程：创建真实服务器对象，定义IP和端口；创建服务器组，把真实服务器加入组内并设置调度算法；创建健康检查，指定探测方式与判定条件；最后创建虚拟服务，把VIP和组、健康检查绑定并启用。以Alteon命令行风格为例，下面这段配置展示了创建两台真实服务器、一个HTTP组和一个VIP的简化过程。

/c/slb/real 1
        ip 192.168.10.11
        name web-node-01
        ena
/c/slb/real 2
        ip 192.168.10.12
        name web-node-02
        ena
/c/slb/group 10
        metric roundrobin
        health tcp
        add 1
        add 2
/c/slb/virt 100
        vip 10.0.0.100
        service http
        group 10
        ena

上面示例中的health tcp只做端口级探测，能发现端口不通或主机不可达，但无法判断应用是否真的正常返回。对于HTTP接口，建议把健康检查改为HTTP类型，并配置具体路径和期望状态码。比如健康检查URL设置为/health，期望响应200 OK，这样能识别到端口通但应用卡死的情况。

真实服务器组里的调度算法也值得说明。roundrobin适合后端配置相近的场景；leastconn会把新连接分给当前活动连接最少的节点，适合长连接业务；hash算法通常配合源IP或Cookie使用，能把同一客户端固定到同一节点，但扩缩容时会影响会话分布。选择算法时要结合业务是否有状态、后端性能是否一致来评估，而不是只追求均匀分配。

三、常见配置误区与排障思路

第一个误区是健康检查路径选得太浅。比如只检查首页/或静态文件，后端依赖的数据库、缓存已经异常时，首页可能仍然返回200，导致故障节点继续接收流量。更可靠的做法是让健康检查路径经过核心业务链路，例如检查/api/status，该接口内部再验证数据库连接、缓存读写等关键依赖。部分团队还会为健康检查单独设计返回体，避免与正常业务请求混淆。

第二个误区是会话保持与健康检查互相干扰。开启源IP会话保持后，一台客户端会持续命中某个节点，但如果该节点健康检查失败被摘除，新的客户端可能被分配到其他节点，而旧客户端仍按会话表继续发往原有节点。此时若健康检查状态更新后立即恢复节点，可能出现状态不一致。排障时要同时查看健康检查日志和会话保持表，确认节点摘除与恢复的时间线，并根据业务特点调整会话保持超时时间，避免过长或过短。

第三个误区是只做L4转发，错过应用层策略。很多请求在TCP层是正常的，但到了HTTP层可能带有异常方法、恶意路径或超大数据包。如果只是按端口转发，等于把风险直接透传给后端。建议在Radware设备上启用必要的L7策略，例如限制请求方法、校验Host头、过滤特定URI或限制请求体大小。即使暂时不需要复杂WAF规则，至少也要开启HTTP健康检查和应用层日志，便于定位异常流量来源。

另外还有一个容易被忽略的问题：后端真实服务器的默认网关配置。当负载均衡器与真实服务器不在同一网段，或者返回流量需要经过其他路由时，如果真实服务器默认网关没有指向负载均衡器或对应交换机，会出现客户端能建立连接但响应无法返回的现象。排查时可以抓取真实服务器网卡流量，确认请求是否到达、响应是否发出、目标MAC是否正确。

四、高可用与日常维护建议

生产环境不建议只部署单台Radware设备。主流做法是两台设备组成主备或主主集群，通过VRRP或厂商私有协议同步会话信息和配置。主备模式配置简单，主设备故障时备机接管VIP，适合大多数业务；主主模式可以同时分担流量，但配置复杂度更高，需要更谨慎地设计会话同步和监控策略。无论选择哪种模式，都要定期测试故障切换，确认切换时间、会话保持和日志完整性。

日常维护中建议把配置变更纳入版本管理，Radware设备的配置文件可以定期导出，变更前保留备份，变更后验证关键VIP和真实服务器状态。监控方面至少关注三类指标：VIP的连接数、吞吐和响应时间；真实服务器的健康检查成功率与摘除次数；设备自身的CPU、内存和SSL处理能力。这些指标出现异常时，往往能提前暴露后端抖动或配置错误，而不是等到用户投诉。

最后要注意升级与补丁策略。Radware设备也会发布固件更新，修复安全漏洞或改进性能。升级前应确认当前版本与目标版本的兼容性，阅读发布说明中与健康检查、会话保持、SSL算法相关的变更。升级窗口内先切换备机、验证配置、再升级主机，并准备回退配置。负载均衡器在架构中处于关键路径，任何变更都需要有明确的验证步骤和回退方案。

Radware负载均衡应用交付健康检查修改时间：2026-09-29 13:59:51