出向链路负载均衡两台设备双活(Active-Active)解决方案

简介:

最近遇到一个出向链路负载均衡的case,原本计划采用两台AX链路负载均衡设备做HA双机冗余,部署的网络拓扑示意图如下:

image

        通常链路负载均衡设备部署为双机主备模式也是类似的拓扑,只是两台主备AX链路负载均衡(LLB)设备之间会有直连的HA心跳线,同时,对内部网络(LAN)启用VRRP,配置一个浮动IP地址,作为整个内部网络的出口网关地址。另外,需要两台内部网络边界路由器(ASBR)或核心交换机也启用VRRP,配置一个浮动IP地址,作为LLB设备的回程路由网关地址。既然要启用VRRP,那么两台LLB设备与两台ASBR设备直连的端口就需要共处于一个L2层广播域内,这是采用主备VRRP工作模式的一个限制条件。假如两台ASBR或核心交换机不在一个L2层环境时,无法启用VRRP协议怎么办呢?

        我想有两种解决办法,第一个解决办法是在内网(LAN)启用策略路由,把来自不同的用户网段流量分别牵引到两台ASBR设备上,这种方法我们可以简单理解为两台主备链路负载均衡LLB设备同时对应两个独立的内部网络(LAN),两台LLB设备启用VRRP协议,与两台ASBR设备物理连接方式需要改成全连接,就不能是示意图这样的“口字型”连接了,同时还要做好内网策略路由的备份机制,保障其中某个ASBR设备故障时,内网用户依然能够访问互联网。

        第二个解决办法,也是目前我们在这个case当中采用的方法是在两台LLB设备与两台ASBR设备之间启用BGP动态路由(注:启用OSPF路由也可以),两台LLB设备之间也不启用VRRP协议,完全当作两台独立的LLB设备。那如何避免LLB设备或者ASBR设备的单点故障呢?我们利用动态路由策略来解决,并控制内网流量的走向。

        大致思路是这样:

1、四台设备共处于一个BGP域内,AX-LLB-1设备与ASBR-1设备建立邻居(Neighbor)关系;AX-LLB-2设备与ASBR-2设备建立邻居(Neighbor)关系。

2、两台AX-LLB设备分别在BGP域内宣告network 0.0.0.0/0的缺省路由,两台ASBR设备能够分别从不同的路径学到两条cost不同的缺省路由,正常情况下,对于ASBR-1生效的缺省路由下一跳是AX-LLB-1;对于ASBR-2生效的缺省路由下一跳是AX-LLB-2。

3、两台AX-LLB设备分别通过两条ISP的线路,对链路实现透明的健康检查,当直连某台AX-LLB设备的两条链路都中断时,在AX-LLB设备上通过Shell脚本将与ASBR直连的端口down掉,以使直连的ASBR设备更新BGP域内的缺省路由,将缺省路由指向对端的ASBR设备。这样就可以保障任何一台AX-LLB设备出现故障或链路全部中断时,与其直连的ASBR可以将内网访问Internet的流量牵引到对端的ASBR设备,对端ASBR设备再将这部分访问流量通过与其直连的AX-LLB设备出去。

4、将两个运营商ISP1和ISP2公网IP地址段一分为二,在两个ISP的网关互联设备上分别配置前后两段公网IP地址段的回程静态路由,指向两台AX-LLB设备,例如:

      ISP1-Router# ip route 1.1.1.0 /25 192.168.1.1(AX-LLB-1接口地址)

      ISP1-Router# ip route 1.1.1.128 /25 192.168.1.2(AX-LLB-2接口地址)

      ISP2-Router# ip route 2.2.2.0 /25 192.168.2.1(AX-LLB-1接口地址)

      ISP2-Router# ip route 2.2.2.128 /25 192.168.2.2(AX-LLB-2接口地址)

        这种解决方案的好处在于可以通过动态路由的学习过程,实现设备和链路的备份,但由于两台AX-LLB设备所使用的公网NAT地址不同,因此当发生故障切换时,切换的流量需要重新建会话。

 

S.G


本文转自 virtualadc 51CTO博客,原文链接:

http://blog.51cto.com/virtualadc/1285770
相关实践学习
部署高可用架构
本场景主要介绍如何使用云服务器ECS、负载均衡SLB、云数据库RDS和数据传输服务产品来部署多可用区高可用架构。
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
相关文章
|
负载均衡 Linux 网络协议
面向C10M时代的MiddleBox之 - 高性能四层负载均衡设备AGW
面对需求的不断提高,几年前我们还在为解决C10K 问题而努力,现在已经开始面临C10M 问题的挑战。
1650 0
|
运维 负载均衡 调度
F5公司的负载均衡解决方案在银行中起什么作用?
  F5公司的负载均衡解决方案在银行中起什么作用?今天我们就来探讨一下这个问题。   我是民生银行的,我所在银行采用负载均衡解决方案实现了同城双活数据中心的业务部署和数据中心之间的业务快速切换,除此之外,在多个数据中心向两个新建数据中心整合的迁移、IP地址改造和日常业务上线的测试、验证、发布及维护过程中也起到了非常大的作用。
3579 0
|
负载均衡 算法 网络安全
|
监控 负载均衡 网络协议
|
负载均衡 算法 Shell
|
负载均衡 调度 缓存