服务器负载均衡就是将本应由一个服务器处理的业务分发给多个服务器来处理,以此提高处理业务的效率和能力。处理业务的服务器组成服务器集群,对外体现为一台逻辑上的服务器,由FW决定如何分配流量给各个服务器
- 实服务器:处理业务流量的实体服务器,客户端发送的服务请求最终是由实服务器处理的
- 实服务器组:由多个实服务器组成的集群,对外提供特定的一种服务
- 虚拟服务器:实服务器组对外呈现的逻辑形态,客户端实际访问的是虚拟服务器
负载均衡转发流程
客户端访问虚拟服务器vserver 1时,FW通过负载均衡功能选择实服务器vserver 1来处理业务流量,并转换报文的目的IP地址和端口号。当实服务器的响应报文到达FW时,FW会再次转换报文的源IP地址和端口号
负载均衡算法是服务器负载均衡功能的核心,通过负载均衡算法即可得到由哪台实服务器来处理业务流量
简单轮询算法,
加权轮询算法
最小连接算法
加权最小连接算法
源IP hash算法
加权源IP hash算法
简单轮询算法
简单轮询算法是将客户端的业务流量依次分配到各个服务器上。如图1所示,FW将客户端的业务流量依次分配给4个服务器,当每个服务器都分配到一条流后,再从服务器S1开始重新依次分配。当业务流量较大时,经过一段时间后,各服务器的累积连接数大致相等。
简单轮询算法的优点是实现简单,效率较高。但是简单轮询算法不会考虑每个服务器上的实际负载:例如新增服务器上的负载量要小于运行一段时间的服务器,而FW仍然依次分配流量给各个服务器,导致新增服务器没有被充分利用。所以,简单轮询算法是一个静态算法,它的适用场景为服务器的性能相近,服务类型比较简单,且每条流对服务器造成的业务负载大致相等。例如,外部用户访问企业内部网络的DNS或RADIUS服务器
加权轮询算法
加权轮询算法是将客户端的业务流量按照一定权重比依次分配到各个服务器上。如图2所示,服务器S1、S2、S3、S4的权重依次为2、1、1、1,此时服务器S1将被视为两台权重为1的服务器,所以FW连续分配两条流给S1,然后再分配接下来的三条流给服务器S2、S3、S4。当业务流量比较大时,经过一段时间后,各服务器的累积连接数比例约为2:1:1:1。
加权轮询算法的适用场景为服务器的性能不同,服务类型比较简单,且每条流对服务器造成的业务负载大致相等。例如,外部用户访问企业内部网络的DNS或RADIUS服务器,各服务器的性能存在差异
最小连接算法
最小连接算法是将客户端的业务流量分配到并发连接数最小的服务器上。并发连接数即服务器对应的实时连接数,会话新建或老化都会影响并发连接数的大小。如图3所示,客户端发出的请求到达FW后,FW会统计4个服务器上的并发连接数。因为服务器S1上的并发连接数最小,所以连续几条流都被分配给服务器S1。
最小连接算法解决了轮询算法存在的问题,即轮询算法在分配业务流量时并不考虑每个服务器上的实际负载量,而最小连接算法会统计各个服务器上的并发连接数,保证业务流量分配到负载最小的服务器上。所以,最小连接算法是动态算法,它的适用场景为服务器的性能相近,每条流对服务器造成的业务负载大致相等,但是每条流的会话存活时间不同。例如,外部用户访问企业内部网络的HTTP服务器
加权最小连接算法
加权最小连接算法是将客户端的业务流量分配到加权并发连接数最小的服务器上。并发连接数即服务器对应的实时连接数,会话新建或老化都会影响并发连接数的大小,而加权并发连接数是考虑服务器权重后得到的实时连接数。如图4所示,服务器S1、S2、S3、S4的权重依次为2、1、1、1,此时服务器S1需要将并发连接数除以2,然后和其他权重为1的服务器进行比较。因为服务器S1的加权并发连接数最小(等于18.5),所以FW将接下来的几条流都分配给服务器S1。当业务流量比较大时,经过一段时间后,各服务器的并发连接数比例约为2:1:1:1。
加权最小连接算法的适用场景为服务器的性能不同,每一条流对服务器造成的业务负载大致相等,但是每一条流的会话存活时间不同。例如,外部用户访问企业内部网络的HTTP服务器,各服务器的性能存在差异
源Ip Hash算法
源IP Hash算法是将客户端的IP地址进行Hash运算,得到Hash Index值。FW根据Hash Index值与Hash列表中服务器的对应关系,分配流量至服务器
加权源IP Hash算法
加权源IP Hash算法是将客户端的IP地址进行Hash运算,得到Hash Index值,而后通过FW调整各个服务器的权重得到Hash表中服务器新的权重值。如果服务器S1、S2、S3、S4的权重依次为2、1、1、1,则Hash表中S1、S2、S3、S4权重为2、1、1、1,最后根据Hash Index值与Hash列表中服务器的对应关系,分配流量至服务器
- 多个服务器中的一个服务器发生故障时,FW如何感知到这个变化,并作出流量分配上的调整
- FW收到信息显示服务器故障时,如何确保消息的可信性,即是否有一定的机制保证不会发生误判
- FW收到信息显示服务器故障时,如何确保消息的可信性,即是否有一定的机制保证不会发生误判
解决办法,服务健康检查管理
- FW通过向服务器定期发送探测报文来及时了解服务器的状态,根据服务类型的不同,使用不同协议类型的探测报文。FW支持的探测报文协议类型包括TCP、ICMP、HTTP、DNS和RADIUS
- 如果服务器提供的服务类型不包含在这5种协议中,建议使用ICMP协议报文检查服务器的可达性
- 每个探测报文都会返回一个检查结果,显示服务器是否处在正常的工作状态,FW提供了结果确认机制来保证不会发生误判。如果有一个检查结果显示服务器故障,则FW在继续发送探测报文的同时,开始统计连续故障的次数。当连续次数达到预设值时,FW才认定此服务器真的发生了故障。检查结果反馈给负载均衡算法后,改变了负载均衡的结果,该服务器不再参与流量分配
- 管理员可以选择是否继续对故障服务器进行健康检查,如果指定故障服务器为非激活状态,则FW不会再向服务器发送探测报文,否则FW会继续向故障服务器发送探测报文
- 如图2所示,当服务器S2发生故障时,FW会立即停止向其分配流量,而只分配给其他健康的服务器。但是FW仍然会向服务器S2发送探测报文,监控其健康状况
- 如图3所示,当服务器S2恢复正常状态时,FW将立即修改其健康状态,这样S2就会重新参与到流量分配中
拓补图
需求:使用负载均衡的算法实现度服务器的负载均衡
配置
1.ip地址的配置略
2.安全的策略的配置
security-policy
rule name untrust-trust
source-zone untrust
destination-zone trust
action permit3.防火墙区域的划分
firewall zone trust
add interface GigabitEthernet1/0/0
firewall zone untrust
add interface GigabitEthernet1/0/1
4. 负载均衡的配置
slb enable
slb
group 0 grp1 //创建一个真实服务器组
metric roundrobin //设置服务器负载均衡算法,默认为简单轮询
rserver 1 rip 10.1.1.1 //真实的服务器地址
rserver 2 rip 10.1.1.2 //真实的服务器地址
rserver 3 rip 10.1.1.3 //真实的服务器地址vserver 1 grp //虚拟服务器组
vip 0 200.1.1.1 //虚拟服务器组的ip地址
protocol tcp //协议类型TCP
vport 80 // 虚拟服务器的组80
group grp1 //加入grp1的真实服务器的组
测试:使用客户机连续访问服务器的80端口三下,产生三条数据流,然后给服务器依次分配,这个就是简单轮询算法,还有其他的负载均衡算法你们可以去试试,这里就不在做演示了