防火墙负载均衡解决方案

近期项目当中遇到了防火墙负载均衡的需求,拿出来和大家探讨一下。

用户在项目中采购了4台国内某知名品牌的高端防火墙,原本打算通过防火墙自身集群的方式实现防火墙的负载分担和冗余部署,可惜防火墙厂商的答复是如果采用集群的方式,4台防火墙的整体性能只能达到相当于1.5台防火墙的处理能力!也就是说有2.5台防火墙的性能被集群所制约和消耗掉了,不能完全实现线性的性能递增。那怎么办?防火墙厂商提出的建议是,4台防火墙两两组成一对,每对防火墙采用主备方式部署,实现会话同步和冗余切换,这样两对防火墙可以提供2倍于单台防火墙的处理能力。这个方案似乎比之前集群的解决方案要更好些!起码4台防火墙的承载能力有所提高了。看到这里,可能已经有人想到了另外一个问题,这两对防火墙之间如何分配流量呢?有人提出采用动态路由协议分配流量;有人提出采用策略路由,根据不同的源地址或者目的地址分配流量;也有人提出采用负载均衡设备分配流量等等。

对于动态路由协议和策略路由方式来分配防火墙的流量,其缺点类似与我们在讨论链路负载均衡时到底采用动态路由协议还是策略路由分配链路流量提出的一些观点和看法,这里就不再啰嗦一遍了。由于防火墙设备的特殊性,我们还必须考虑如何保证相同用户的进出流量都通过相同的防火墙,也就是内外网之间相互访问时原路径返回的问题。那么这两种解决办法的优势在于不需要额外增加设备。

采用负载均衡设备来对防火墙实现负载分担其劣势在于需要在防火墙内外两端都部署负载均衡设备,也就是我们常说的”三明治“方式部署,额外部署负载均衡设备会增加用户的投资,这是这种解决方案的劣势。那么我们来看看如何能够将劣势的影响减少到最小呢?我们先从提高防火墙的使用效率来入手,首先,采用了防火墙负载均衡的解决方案,我们可以打破防火墙两两冗余的部署方式,将4台防火墙当作独立的设备来使用,每台防火墙都能承载业务流量,这样就可以真正发挥4台防火墙的处理能力,使其处理能力可以实现线性的增加!不会像防火墙集群或者两两冗余HA部署那样,损失掉防火墙的性能。也就是说在不增加防火墙设备的情况下,采用这种方案使的现有防火墙的业务承载能力可以提高1倍!节省了未来防火墙扩容的投资。增加了负载均衡设备的投资,减少了未来防火墙设备的投资,一进一出相抵,从投资角度来说,也并不是不划算的一个方案。

除了投资方面的考虑,我们再看看采用防火墙负载均衡方案能带来哪些好处:

提高防火墙设备的利用率,简化了防火墙设备的管理和配置,能够发挥每台设备的最大性能;

提高了防火墙的扩展能力,现有防火墙组群承载能力不够时,只需要在组群中增加防火墙即可,不用局限于原有防火墙的品牌、型号、处理能力;

返回栏目页:http://www.bianceng.cnhttp://www.bianceng.cn/Network/Firewall/

对每台防火墙可以提供多种健康检测机制,及时发现和规避不可用的防火墙设备,实现防火墙之间的冗余部署;

通过负载均衡设备的原路径返回”auto-last-hop“功能,能够很容易的实现进出防火墙采用相同路径的需求;

通过负载均衡设备的会话保持功能,保证关联交易和信息都通过相同的防火墙,保障业务的完整性;

利于外侧负载均衡设备抵御来自外部的DDoS攻击,卸载防火墙的压力;

典型拓扑如下图所示:

外部一对AX设备采用主备冗余部署,对入向的流量进行防火墙负载分担,并对出向流量的应答数据流实现原路径(防火墙)返回;

内部一对AX设备采用主备冗余部署,对出向的流量进行防火墙负载分担,并对入向流量的应答数据流实现原路径(防火墙)返回;

后期结合此项目,再给大家介绍一些具体的防火墙负载均衡配置示例。

S.G

本文出自 “ADC技术博客” 博客,请务必保留此出处http://virtualadc.blog.51cto.com/3027116/1094209

时间: 2024-11-08 18:19:07

防火墙负载均衡解决方案的相关文章

华泽奥迅服务器负载均衡解决方案

企业网络http://www.aliyun.com/zixun/aggregation/15818.html">应用服务器存在的问题: 1.网络应用服务器的可靠性较差: 应用服务器由于服务器硬件的稳定性.流量压力超载.网络攻击等情况经常会出现意外宕机的情况,从而无法保证网络 应用的7x24 小时的持续性服务. 2.网络应用的性能瓶颈: 在网络应用系统中,通常会采用多台服务器同时提供服务的方式.但是由于网络中的流量并不均衡,因此经常会出现某台服务器由于访问量过大而宕机,造成网络应用性能的不稳

多台Web服务器做负载均衡解决方案

环境说明: 开发平台是DO.NET B/S .NET Framework 1.1 正式WEB服务器和测试机,均为win2003 原有一个主网站,在六台WEB服务器做负载均衡.运行比较稳定. 现新开发一个子站,将布署在另三台WEB服务器上做负载均衡.这个负载均衡设置类似主网站的设置. 解决步骤: 1)子站在测试机测试通过,运行正常.准备布署到正式环境下(三台WEB服务器) 2)将子站程序拷贝到那三台WEB服务器上,配置好子站相关配置,开放站点与负载均衡开始测试. 3)测试时,页面显示正常,但在触发

【转载】四层和七层负载均衡的区别

简单理解四层和七层负载均衡:①所谓四层就是基于IP+端口的负载均衡:七层就是基于URL等应用层信息的负载均衡:同理,还有基于MAC地址的二层负载均衡和基于IP地址的三层负载均衡. 换句换说,二层负载均衡会通过一个虚拟MAC地址接收请求,然后再分配到真实的MAC地址:三层负载均衡会通过一个虚拟IP地址接收请求,然后再分配到真实的IP地址:四层通过虚拟IP+端口接收请求,然后再分配到真实的服务器:七层通过虚拟的URL或主机名接收请求,然后再分配到真实的服务器. ②所谓的四到七层负载均衡,就是在对后台

四层和七层负载均衡的区别

  (一) 简单理解四层和七层负载均衡: ① 所谓四层就是基于IP+端口的负载均衡;七层就是基于URL等应用层信息的负载均衡;同理,还有基于MAC地址的二层负载均衡和基于IP地址的三层负载均衡. 换句换说,二层负载均衡会通过一个虚拟MAC地址接收请求,然后再分配到真实的MAC地址;三层负载均衡会通过一个虚拟IP地址接收请求,然后再分配到真实的IP地址;四层通过虚拟IP+端口接收请求,然后再分配到真实的服务器;七层通过虚拟的URL或主机名接收请求,然后再分配到真实的服务器. ② 所谓的四到七层负载

服务器集群负载均衡(F5,LVS,DNS,CDN)区别以及选型

  ======================================= F5全称: F5-BIG-IP-GTM 全球流量管理器. 是一家叫F5 Networks的公司开发的四~七层交换机,软硬件捆绑. 据说最初用BSD系统,现在是LINUX;硬件是Intel的PC架构,再加周边的网络和专用加速设备. 当然要提提售价, 都是几十万RMB的身价. 这宝贝是用于对流量和内容进行管理分配的设备,也就是负载均衡. 从名字就能看出来:BIG-IP. 外部看来是一个IP,内部可却是几十台应用服务器

使用NGINX Plus负载均衡Kubernetes服务

本文讲的是使用NGINX Plus负载均衡Kubernetes服务,[编者的话]此篇文章是Nginx的Michael Pleshakov发表在Nginx官方博客的一篇博文,通过这篇文章概括回顾了Kubernetes暴露服务相关的解决方案,并对最新的Ingreess API进行了说明,最后给出了Kubernetes通过集成NGINX Plus来暴露服务到互联网的解决方案.这个方案解决了目前Kubernetes暴露服务的短板,整个实现过程也比较简单,步骤清晰,具有很强的参考性.我们华三目前也在调研这

借助LVS+Keepalived实现负载均衡

原文地址:http://www.cnblogs.com/edisonchou/p/4281978.html 一.负载均衡:必不可少的基础手段 1.1 找更多的牛来拉车吧 当前大多数的互联网系统都使用了服务器集群技术,集群即将相同服务部署在多台服务器上构成一个集群整体对外提供服务,这些集群可以是Web应用服务器集群,也可以是数据库服务器集群,还可以是分布式缓存服务器集群等等. 古人有云:当一头牛拉不动车的时候,不要去寻找一头更强壮的牛,而是用两头牛来拉车. 在实际应用中,在Web服务器集群之前总会

网络负载均衡详解

一.四层和七层负载均衡简介 1. 常见的负载均衡类型 ① 二层负载均衡 基于MAC地址,它会通过一个虚拟MAC地址接收请求,然后再分配到真实的MAC地址. ② 三层负载均衡 基于IP地址,它会通过一个虚拟IP地址接收请求,然后再分配到真实的IP地址. ③ 四层负载均衡 基于IP地址和端口号,它会通过一个虚拟IP和端口号接收请求,然后再分配到真实的服务器. ④ 七层负载均衡 基于URL等应用层信息,它会通过虚拟的URL或主机名接收请求,然后再分配到真实的服务器. 2. 四层和七层负载均衡 所谓的四

构建百万访问量电子商务网站:LVS负载均衡(前端四层负载均衡器)

访问量超过100万的电子商务网站技术架构 本连载首篇介绍到电子商务网站高性能.高可用解决方案.从架构图上的方案,应用的是LVS+keepalived负载均衡.实现高性能.高可用解决方案(服务器组成集群,达到负载均衡,高性能.高可用.高可伸缩性的服务器集群)互联网->LVS负载均衡(前端四层负载均衡器). 访问量超过100万的电子商务网站技术架构.PNG图,电子商务网站要承受高访问量,硬件设备的支撑是整个系统的基础.系统软件的支撑也是必不可少的重要组成部分. 本文详细介绍传统WEB前段负载均衡层,