说起F5,可能有些小伙伴比较陌生,先简单介绍下F5。由于网络各个核心部分随着业务量提高,访问量和数据流量快速增长,其处理能力和计算强度也相应的增大,使得单一的服务器设备根本无法承担。针对此情况衍生出来的一种廉价透明有效的方法,以此扩展现有网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性的技术就是负载均衡(LoadBalance),也称之为F5。
F5部署模式
路由模式:
旁挂模式:
F5实现过程举例说明
F5负载均衡器应用交换机后面的一组服务器10.1.1.4:80、10.1.1.5:80、10.1.1.6:80对外构成一台虚拟的服务器(VirtualServer)192.168.101.1:80,对外提供服务。当一个访问虚拟服务器192.168.101.1:80的请求到达负载均衡器后,负载均衡器根据预先设定的负载均衡算法从服务器pool(WEB_POOL)中挑选一台服务器来服务该请求,例如选定的是10.1.1.4:80;然后通过网络地址转换(NAT)将访问请求包的目的地址与端口转换成10.1.1.4:80,并将数据包发给10.1.1.4。服务器10.1.1.4处理访问请求,并作出回应。回应的包必须返回到负载均衡器上,由负载均衡器将回应包的源地址与端口转换回虚拟服务器的地址与端口,并返回给客户。这样完成一次访问过程。
会话保持方法
在大多数WEB应用系统或者需要进行用户身份认证的在线系统中,一个客户与服务器经常经过三次以上交互过程才能完成一笔交易或一个请求。交互过程是密切相关的,服务器进行交互过程的下一个交互步骤,需要了解上一交互过程的处理结果,或者上几步的交互过程结果,服务器进行下一步操作时就要求所有这些相关的交互过程都由一台服务器完成,而不能被负载均衡器分散到不同的服务器上。这就涉及到会话保持,常见会话保持如下。
简单会话保持:
简单会话保持也被称为基于源地址的会话保持,是指负载均衡器在作负载均衡时是根据访问请求的源地址作为判断关联会话的依据。对来自同一IP地址的所有访问,请求在作负载均时都会被保持到一台服务器上去。
基于源地址的会话保持实现起来简单,效率也比较高。存在的问题就在于当多个客户是通过代理或地址转换的方式来访问服务器时,由于都分配到同一台服务器上,会导致服务器之间的负载严重失衡。
基于Cookie的会话保持:
在Cookie插入模式下,Big-IP将负责插入cookie,后端服务器无需作出任何修改。当客户进行第一次请求时,客户HTTP请求(不带cookie)进入BIG-IP,BIG-IP根据负载平衡算法策略选择后端一台服务器,并将请求发送至该服务器,后端服务器进行HTTP回复(不带cookie)被发回BIGIP,然后BIG-IP插入cookie,将HTTP回复返回到客户端。当客户请求再次发生时,客户HTTP请求(带有上次BIGIP插入的cookie)进入BIGIP,然后BIGIP读出cookie里的会话保持数值,将HTTP请求(带有与上面同样的cookie)发到指定的服务器,然后后端服务器进行请求回复,由于服务器并不写入cookie,HTTP回复将不带有cookie,恢复流量再次经过进入BIG-IP时,BIG-IP再次写入更新后的会话保持cookie。
常用负载均衡算法
轮询(RoundRobin):顺序循环将请求一次顺序循环地连接每个服务器。当其中某个服务器发生故障,BIG/IP就把其从顺序循环队列中拿出,不参加下一次的轮询,直到其恢复正常。
比率(Ratio):给每个服务器分配一个加权值为比例,根椐这个比例,把用户的请求分配到每个服务器。当其中某个服务器发生故障,BIG/IP就把其从服务器队列中拿出,不参加下一次的用户请求的分配,直到其恢复正常。
优先权(Priority):给所有服务器分组,给每个组定义优先权,BIG/IP用户的请求,分配给优先级最高的服务器组(在同一组内,采用轮询或比率算法,分配用户的请求);当最高优先级中所有服务器出现故障,BIG/IP才将请求送给次优先级的服务器组。这种方式,实际为用户提供一种备份的方式。
最小的连接数(LeastConnection):传递新的连接给那些进行最少连接处理的服务器。当其中某个服务器发生故障,BIG/IP就把其从服务器队列中拿出,不参加下一次的用户请求的分配,直到其恢复正常。
常用检查方式
ICMP Monitor
利用互联网控制信息协议(ICMP)检查节点的状态。
TCP Monitor
通过尝试从节点接收特定内容来验证TCP服务。
HTTPMonitor
通过尝试从网页接收特定内容来验证HTTP服务。
案列解析
以某业务为例进行F5配置解析,首先创建http健康性检测规则,首先进入负载均衡的健康性检测功能模块,点击create创建健康性检测规则,如下图所示:
然后开始配置健康性检测检测路径及返回值,协议为http协议,检测路径需要由项目相关开发人员提供,HTTP/1.1表示业务所使用的http版本号,200表示检测路径信息接收成功(也可根据业务curl返回值中特定字段进行设置,当然也可以采用tcp端口检测以及icmp检测等F5自带检测功能进行配置,此案例以http检测为例)
对健康检测路径进行验证,可使用curl以及wget命令对健康性检测路径进行验证,确认路径是否正确,可根据curl以及wget返回值来判断业务是否正常。
pool配置,首先创建pool,并配置名称、健康性检测规则、负载方式相关信息,然后添加相应的后台服务器节点,status为绿色表示节点健康性检测通过,负载方式本案例默认采用轮询方式,也可根据具体需求进行调整,配置如下所示:
创建VS,配置虚服务名字、ip、端口、协议、源地址等相关信息,本案例采用由于对外网开放,没有限定源地址,协议为http协议,配置如下所示:
配置完成后业务获取的为F5浮动ip,如业务想获取用户源ip,将httpprofile配置为X-Forwarded-For,然后在后台节点抓包XFF报头即可看到用户真实ip,开发侧可根据代码配置获取xff携带真实ip
至此F5配置完成,可在NetWorkMap中查看虚服务状态,状态为绿色表示成功,具体如下图所示:
如果虚服务已经映射外网,也可登录后台查看虚ip的用户访问情况,或者在管理界面查看虚服务当前用户连接状态来判断是否建立成功,方法如下所示: