XX运营商web网关扩容及负载均衡项目

　　1. 项目背景

　　随着终端能力的提升，用户接入点的调整往往导致用户无法使用自营业务，影响XX业务的推广,XX客户提出要求用户号码标识系统支持NET流量管理和控制，为精细化运营及能力开发提供系统支持。

　　2. 方案概述

　　XX运营商的uninet/3gnet 接入点的业务均从GGSN直接访问互联网的，这部分用户的用户标识业务系统不能获取，而据统计目前有88%的流量来自于net接入点，但目前基于net接入点的访问未启用Radius计费鉴权流程，导致各类增值业务应用无法获取移动用户的手机号码，无法计费，也无法为用户提供个性化的服务。目前只能通过注册方式获取用户手机号码，增加用户使用门槛，影响iPhone及部分智能终端用户的使用体验。对此XX运营商新建web网关项目,对特定网站的手机用户实现号码前传功能，不需要注册即可获得手机用户的号码信息，方便业务的推广。

　　3. 网络拓扑

　　4. 方案说明

　　4.1业务处理：

　　H3C 负载均衡设备在项目有两个作用：

　　第一：radius信息：由GGSN将radius信息发送至10.0.0.XXX/32,该地址

　　为H3C负载均衡器虚服务地址,通过命中该虚服务,使用轮询机制将radius信息分发至对应服务器,回程路径不需要负载均衡处理;

　　第二：透明代理业务流量(http proxy)：手机用户访问http业务时，H3C负载均衡需对出方向及入方向流量进行两次负载，且两次处理时需要将流量发送到拥有不同IP的同一台服务器上。

　　4.2实现方式：

　　第一：对于radius鉴权流程，H3C负载均衡支持此路径转发需求;

　　第二：由于透明代理数据走向特殊，F5可通过irule定义同一台服务器的不同IP来保证数据分发到同一台服务器，目前H3C暂未提供外挂脚本功能，可以通过定义两组同一IP的实服务，这样在两个方向的流量经由hash能够负载至同一服务器，然后使用VRP实例隔离路由表，再经由明细路由将数据送往同一服务器的不同接口(IP)处理，以实现需求。

　　5. http proxy流量分析

　　5.1流量拓扑

　　5.2流量分析

　　5.2.1出方向：

　　GGSN侧手机终端用户发起访问internet的http流量，流量经过防火墙由vlan101转发至核心交换机，经过策略路由处理，进入H3C负载均衡，H3C LB卡经过源地址散列运算后将数据转发至vlan4001段服务器，服务器经过单板处理，由本台服务器的vlan4002段接口将数据交给核心交换机，同时从vlan102经过虚拟防火墙到公网SP。

　　5.2.2返回方向：

　　公网SP返回流量由vlan102经过虚拟防火墙转发至核心交换机，经过策略路由处理，进入H3C LB卡，H3C LB卡经过目的地址散列运算后将数据转发至4002段服务器，服务器经过单板处理，由本台服务器的vlan4001段接口将数据数据交给核心交换，并返回给手机用户。

　　1. 实现方式分析

　　H3C LB卡定义了两组同一IP的、均为vlan4001段的实服务组及实服务，出方向算法使用源地址散列，入方向算法使用目的地址散列，虚服务均为全零的防火墙转发，区别在于入方向虚服务绑定了VPN实例(102和4002在此VPN实例内)，这样保证了两次散列运算能够将流量转发至同一台服务器，并且由于使用了VPN隔离，在VPN实例内使用明细路由将去往4001段的数据交给4002段的接口处理，这样就实现了将流量负载到拥有不同IP的同一台服务器上的需求。

2016年01月