防火墙——服务器负载均衡
服务器负载均衡技术将多个服务器组成服务器集群，对外体现为一台逻辑上的服务器，并保证了流量可以比较平均的分配到各个服务器上，避免出现一个服务器满负荷运行、另一个服务器却空闲的情况。
目录
基本概念
技术出现背景
目前随着日益增长的网络业务多服务器造成了巨大的压力，当单个服务器无法满足网络需求时，一般会增加服务器的数量来解决性能不足的问题。
此时就涉及到了如何分配流量、服务器间的协同机制等很多复杂的问题，服务器负载均衡（SLB）技术由此应运而生
技术简介
服务器负载均衡技术将多个服务器组成服务器集群，对外体现为一台逻辑上的服务器，并保证了流量可以比较平均的分配到各个服务器上，避免出现一个服务器满负荷运行、另一个服务器却空闲的情况。
相关术语
实服务器：处理业务流量的物理服务器（客户端发起的流量是由实服务器处理的）
实服务器组：多个实服务器组成的集群（一个实服务器组对外提供特定的一种服务）
虚拟服务器：实服务器对外呈现的逻辑形态（客户端实际访问的是虚拟服务器）
负载均衡算法：FW将业务分配给实服务器时依据的算法，不同的算法有不同的分配结果
会话保持：保证在一段时间内的业务流量分配给同一个实服务器
服务器健康检查：检查实服务器状态是否正常，使得对外提供的服务更加可靠
HTTP调度策略：FW将业务分配给实服务器时依据的规则（仅适用于HTTP和HTTPS协议）
负载均衡算法类型
负载均衡算法是服务器负载均衡的核心，依据服务器的性能和服务器的服务类型来选择不同的均衡算法
简单轮询算法——将客户端的业务流量依次分配给服务器，每个服务器都分到一条流后再重新依次分配。适用于服务器性能相近，服务类型简单的场景（RADIUS、DNS服务器等）
加权轮询算法——将客户端的业务流量按照一定的权重比依次分配给服务器。适用于服务器性能存在差异，服务器类型比较简单的场景（RADIUS、DNS服务器等）
最小连接算法——将客户端的业务流量分配到并发连接数最小（负载最小）的服务器上，解决了轮询算法没有考虑到每个服务器上实际负载量的问题。适用于服务器性能相近，每条流对服务器造成的业务负载大致相等，但是每条流的会话存活时间不同（例如Http服务器）
加权最小连接算法——为服务器分配权重，将业务流量分配到并发连接数/权重最小的服务器上。适用于服务器性能有差异，每条流对服务器造成的业务负载大致相等，但是每条流的会话存活时间不同（例如Http服务器）
源IP hash算法——将客户端的IP地址进行Hash运算，得到Hash Index值，根据Index值与Hash列表中服务器的对应关系，分配流量到服务器，可以将源IP相同的客户端负载到同一个服务器。适用于服务器性能差别不大的场景。
加权源IP hash算法——依据权重，根据Index值与Hash列表中服务器的对应关系，分配流量到服务器。适用于服务器性能有一定差差异的场景。
会话保持
根据负载分担算法分发首条连接到服务器，建立相应的会话保持表，依据此表项将同一客户端一定时间内的业务流量分配到同一台实服务器上（源IP Hash负载分担算法也可以达到此目的，即使用此负载分担算法时，可以不配置会话保持）。
当会话保持表老化时间到期或者实服务器故障，会话保持表会被删除，等客户端再次访问时重新建立会话保持表。
适用场景
- 客户端需要与服务器进行多次交互，才可以完成一次特定操作的场景。需要保证同一客户端的流量都被分配到同一个服务器上。
- 服务器上保存了用户的相关业务信息，为了方便用户本次或下次使用，可以令此服务器处理该用户的所有请求。需要保证同一客户端的流量都被分配到同一个服务器上。
会话保持方式
目前FW支持的会话保持方法有源IP会话保持、SSL会话ID会话保持、HTTP Cookie会话保持。不同的保持方式适用于不同的服务协议。
源IP会话保持—老化时间默认180s
根据客户端的源IP建立会话保持表项
根据负载分担算法分发首条连接到服务器，同时在源IP会话表中记录客户端源IP地址与服务器的对应关系。FW收到后续该客户端连接时会依据源IP会话表查找对应的服务器
SSL 会话ID会话保持—老化时间默认300s
只支持SLL协议。FW解析客户端发送的SSL报文来获取Session ID，建立相应的会话保持表项
会出现两种情况——客户端发来的Client Hello报文未携带Session ID、携带Session ID
- 当未携带ID时，根据负载均衡算法选择一个实服务器连接，实服务器生成一个Session ID并通过Server Hello报文发送给客户端，FW收到后解析出Session ID，新建Session ID表项。（客户端再次和服务器建立连接时，Client Hello会携带上一次连接所用的Session ID，依据会话表项分配到同一实服务器）
- 当携带ID时，根据负载均衡算法选择一个实服务器连接，同时新建Session ID表项，记录Session ID和实服务器的对应关系
HTTP Cookie会话保持—老化时间默认600s
根据HTTP/HTTPS会话中的Cookie所携带的实服务器IP地址来完成
HTTP Cookie会话保持又分为三种方式（Cookie插入、Cookie被动、Cookie重写），选择被动和重写方式时服务端需要将Cookie字段做相应配置，选择插入方式时无需配置。
Cookie插入——FW插入Cookie字段
FW解析客户端的HTTP请求报文，检查是否携带了客户端自己插入的Cookie
如未携带，FW根据负载均衡算法分发HTTP请求到服务器
FW在服务器的回应报文中插入自己的Cookie（包含分发实服务器的IP地址）。
客户端再次发送HTTP请求时携带FW插入的Cookie
FW根据此Cookie获得上次分发实服务器的IP地址，将本次请求也分发到同一个实服务器
如果携带了Cookie，FW根据负载均衡算法分发HTTP请求到服务器，并记录Cookie与实服务器的关系
Cookie被动——服务器插入Cookie字段
FW解析客户端的HTTP请求报文，检查是否携带了客户端自己插入的Cookie
如未携带，FW根据负载均衡算法分发HTTP请求到服务器
服务器在回应报文中插入自己的Coolie（包含分发实服务器的IP地址）
客户端再次发送HTTP请求时携带此Cookie
FW根据此Cookie获得上次分发实服务器的IP地址，将本次请求也分发到同一个实服务器
如果携带了Cookie，FW根据负载均衡算法分发HTTP请求到服务器，并记录Cookie与实服务器的关系
Cookie重写——服务器插入空白Cookie，FW再插入Cookie字段
FW解析客户端的HTTP请求报文，检查是否携带了客户端自己插入的Cookie
如未携带，FW根据负载均衡算法分发HTTP请求到服务器
服务器在回应报文中插入空白的Coolie
FW收到此回应报文，重写插入自己的Cookie（包含分发实服务器的IP地址）。
客户端再次发送HTTP请求时携带此Cookie
FW根据此Cookie获得上次分发实服务器的IP地址，将本次请求也分发到同一个实服务器
如果携带了Cookie，FW根据负载均衡算法分发HTTP请求到服务器，并记录Cookie与实服务器的关系
服务器健康检查（可选，一般配置）
检测服务器的工作状态，当某个服务器发生故障时，更改此服务器的状态。
负载均衡算法感知到服务器状态的变化后，保证用户请求不会被发送到故障服务器上
探测服务器工作状态的协议报文
TCP、ICMP、HTTP、HTTPS、DNS、RADIUS六种
如果服务器提供的服务类型不包含在这6种协议中，则建议使用ICMP协议报文检测
工作原理
每个探测报文都会返回一个检查结果，显示服务器是否处在正常的工作状态。
如果有一个检查结果显示服务器故障，则FW在继续发送探测报文的同时，开始统计连续故障的次数。
当连续次数达到预设值时，FW才认定此服务器真的发生了故障。
默认服务器健康检查的发送间隔为5s，最大的失败次数为3次
HTTP调度策略
决定了如何分配HTTP流量到服务器组上，选择合适的HTTP调度策略与负载均衡算法结合，才能获得理想的负载均衡效果。
工作原理
根据HTTP协议首部字段来制定调度策略（字段包括URL、Referer、Host、Cookie等），将特定的请求会话调度到指定的实服务器组
只有当协议类型是HTTP或者HTTPS是才可以配置HTTP调度策略
注意事项
虚拟IP地址注意事项
实服务器的IP地址注意事项
实服务器的IP地址不能和下列IP地址相同：
- 虚拟服务器的IP地址
- 网关的IP地址
- FW的接口IP地址
会话保持和健康检查配置注意事项
FTP服务器负载均衡实验配置_多谢思考的博客-CSDN博客
https://blog.csdn.net/m0_49864110/article/details/125124691HTTP服务器负载均衡实验配置——HTTP调度策略_多谢思考的博客-CSDN博客https://blog.csdn.net/m0_49864110/article/details/125126092
腾讯云面向开发者汇聚海量精品云计算使用和开发经验，营造开放的云计算技术生态圈。
更多推荐
0
0- 0
已为社区贡献3条内容
所有评论(0)