全负载均衡方案.doc

文档编号:


升级设计方案

作者: 史亚洲
完成日期: 2008-07-18
修改记录:
版本号
修改人
修改日期
审核人
批准人
备注

史亚洲
2008-7-18
创建
评审记录:
评审编号
评审组长
评审日期
结论
评审形式
评审报告
目录
升级设计方案 1
1 方案设计CEF容量为12万 1
2 方案网络拓扑示意图: 1
连接过程说明: 1
3 对应关系示意图: 3
4 方案说明: 4
方案采用三层结构,分别由: 5
第一层负载均衡功能介绍: 6
第二层功能介绍: 9
第三层功能介绍: 10
5 现网硬件基础下理论最大稳定CEF容量: 11
6 程序模块功能介绍: 12
madmin工程: 12
对路由机群组的web管理功能 12
路由机的新的iptables规则; 12
部署通讯机:d 12
mApp工程: 12
F5上添加规则: 12
初始化通讯机: 13
修改tunmgt工程: 13
调用VpnSyncMain类的内存数据库数据: 13
对F5的Addresslist动态更新;(需要读业务数据库还是内存数据库现在不能确定); 13
添加routeapp工程: 13
数据库: 14
数据库添加路由机对应的表,添加路由机和虚拟服务器对应关系; 14
通讯机openvpn改造 16

方案概要
当前负载均衡策略:实现群内的负载均衡。
现方案的负载均衡策略:实现全系统的负载均衡。
方案约束
加入路由服务器,提供IPTABLES 路由能力。
方案设计CEF容量为12万
虽然设计容量为12万,但是本方案在全负载均衡的框架下,对平滑扩容以及资源合理利用有很好的支持。从下面的网络拓扑示意图上就有很好的体现。
方案网络拓扑示意图:
连接过程说明:
1、cef连接过程——由cef以公网IP:443 发起连接请求(黑1);经防火墙转换为内网IP到达F5设备(黑2);F5设备通过负载均衡算法把请求发往某台通讯机(黑3);通讯机调用plugin程序修改数据库tunnel表对应的记录的状态,同时通管机的定时轮询程序会数据库数据同步到F5设备(黑4)。至此cef和gegw系统连接建立。
2、手机连接过程——用户手机终端以公网IP:30000-59999 发起连接请求(红1);经防火墙转换为内网IP到达F5设备(红2);F5通过Irules规则和负载均衡算法将请求发往某台物理路由机(红3);物理路由机根据本机的iptables规则进行端口到地址的转换,得到此手机所属cef的TIP,请求被路由会F5设备(红4);F5根据Addresslist得到此TIP所属的物理通讯机IP,并将请求路由到此物理通讯机(红5)。至此,手机连接到了cef,可以收发邮件。
对应关系示意图:
对应关系说明:
如上图,F5设备共有12个虚拟服务器(每个虚拟服务器最大支持9999个cef连接),ccd1-12代表1-12组虚拟服务器,d文件。
这12个虚拟服务器和通讯机的openvpn进程的对应关系是——
每两个虚拟服务器对应一个openpn进程:
因为我们开启了6个openvpn进程(开启的进程数是可配置的,d是可变),所以每两个虚拟服务器对应一个openvpn进程,d文件(d文件代表一个cef的172类型的TIP);
和路由机的对应关系是——
每4个虚拟服务器对应一个物理路由机:
每个物理路由机最多可以容纳8万条iptables规则,每两条iptables规则确定一个cef也就是4万个CEF,而每个虚拟服务器最多可以连接9999个cef,所以,一台物理路由机对应4个虚拟服务器。
路由机和通讯机之间没有直接的对应关系。
方案说明 :
有了前面的介绍作为基础,下面将以一张每层只包含具体一台机器流程图的作为详细的方案说明:
方案采用三层结构,分别由:
第一层——F5四层负载均衡机
第二层——虚拟路由机集群
第三层——通讯机集群
层次结构如下图:
层次间逻辑如下图:

第一层负载均衡功能介绍:
F5设备在GEGW系统中完成三个主要功能:
接收CEF连接请求,根据CEF 发起的要连接的虚拟服务器的地址加端口(如: :443 ),irules规则判断确定某条vs_pool,在这个pool里面,从每