常见的负载均衡

文章常见的负载均衡分享给大家，欢迎收藏Python资料网，专注分享技术知识

1.常见的负载均衡服务

负载均衡服务是分布式系统中用于分配网络流量和请求的关键组件，它可以帮助提高应用程序的可用性、可扩展性和响应速度。以下是一些常用的负载均衡服务：

1. Nginx：一个高性能的Web服务器和反向代理，广泛用于实现HTTP和HTTPS负载均衡。

2. HAProxy：一个专注于提供高可用性和负载均衡的开源软件，特别擅长处理高并发的TCP和HTTP请求。

3. LVS (Linux Virtual Server)：一个基于Linux内核的负载均衡解决方案，工作在网络的第四层，提供高性能和高可用性。

4. F5 BIG-IP：一款市场占有率较高的硬件负载均衡器，提供SSL加速、TCP优化、HTTP压缩、防火墙等特性。

5. A10 Networks：提供一系列硬件负载均衡器，支持多种负载均衡算法，具有SSL加速、TCP优化、HTTP压缩等功能。

6. Radware Alteon：一款硬件负载均衡器，提供SSL加速、TCP优化、HTTP压缩、防火墙等特性。

7. MetalLB：专为裸机Kubernetes集群设计的负载均衡器，支持BGP和ARP协议。

8. Traefik：一个现代化的HTTP反向代理和负载均衡器，支持动态配置，与Docker、Kubernetes等容器平台集成良好。

9. DNS负载均衡：通过DNS服务器将域名解析为多个IP地址，将请求分发到不同的服务器上，实现负载均衡。

10. 云服务商提供的负载均衡服务：如AWS Elastic Load Balancing、Azure Load Balancer、Google Cloud Load Balancing等，它们提供了易于使用和管理的负载均衡解决方案。

2.Nginx

2.1.Nginx负载均衡概述

Nginx 通过反向代理的方式实现负载均衡。反向代理是指客户端不直接访问后端服务器，而是通过代理服务器来转发请求。Nginx 作为代理服务器，根据配置文件中定义的规则，将客户端的请求分发到不同的后端服务器上，再将处理结果返回给客户端。

Nginx 的核心在于其高效的请求处理能力和灵活的配置方式。它采用了多进程+异步非阻塞IO事件模型，能够同时处理成千上万个请求。此外，Nginx 还支持多种负载均衡策略，以满足不同场景下的需求。

2.2.Nginx 负载均衡策略

Nginx 支持多种负载均衡策略，以下是一些常用的策略：

轮询（Round Robin）

默认策略：按照服务器列表的顺序依次分发请求，如果后端服务器宕机，则自动剔除该服务器。适用于后端服务器性能相近的情况。

特点：简单、易用，但负载分配可能不均衡。

权重（Weight）

自定义策略：根据服务器的权重值来分配请求的比例，权重越高，处理的请求越多。适用于后端服务器性能不均衡的情况。

配置示例：

upstream backend { server backend1.example.com weight=1; server backend2.example.com weight=2; }

IP 哈希（IP Hash）

会话保持策略：根据客户端的IP地址进行哈希计算，将同一个客户端的请求分发到同一个后端服务器上。适用于需要维持会话的场景，如基于session的Web应用。

配置示例：

upstream backend { ip_hash; server 192.168.1.100; server 192.168.1.200; }

最少连接数（Least Connections）

智能分配策略：将请求分配给当前连接数最少的服务器。这种策略可以进一步提高系统的负载均衡能力，减少服务器的过载情况。但Nginx本身不直接支持此策略，通常需要借助第三方模块或自定义脚本实现。

第三方策略

Fair：根据后端服务器的响应时间来分配请求，响应时间短的优先分配。Nginx本身不支持此策略，需要安装第三方模块（如nginx-module-vts）。

URL 哈希（URL Hash）：按访问URL的hash结果进行分配请求，使每个URL定向到同一个后端服务器。这种策略适用于缓存服务器集群，可以提高缓存的命中率。Nginx本身不支持此策略，需要安装相应的hash软件包。

3.HAProxy

3.1.ha-proxy概述

ha-proxy是一款高性能的负载均衡软件。因为其专注于负载均衡这一件事情，因此与nginx比起来在负载均衡这件事情上做更好，更专业。

软件：haproxy---主要是做负载均衡的7层，也可以做4层负载均衡

apache也可以做7层负载均衡，但是很麻烦。实际工作中没有人用。

负载均衡是通过OSI协议对应的

7层负载均衡：用的7层http协议，

4层负载均衡：用的是tcp协议加端口号做的负载均衡

3.2.ha-proxy的特点

ha-proxy 作为目前流行的负载均衡软件，必须有其出色的一面。下面介绍一下ha-proxy相对LVS，Nginx等负载均衡软件的优点。

• 支持tcp/http两种协议层的负载均衡，使得其负载均衡功能非常丰富。

• 支持8种左右的负载均衡算法，尤其是在http模式时，有许多非常实在的负载均衡算法，适用各种需求。

• 性能非常优秀，基于单进程处理模式（和Nginx类似）让其性能卓越。

• 拥有一个功能出色的监控页面，实时了解系统的当前状况。

• 功能强大的ACL支持，给用户极大的方便。

3.3.haproxy算法：

1.roundrobin

轮询,在服务器的处理时间保持均匀分布时,这是最平衡,最公平的算法.此算法是动态的,这表示其权重可以在运行时进行调整.

2.static-rr

基于权重进行轮询,与roundrobin类似,但是为静态方法,在运行时调整其服务器权重不会生效.不过,其在后端服务器连接数上没有限制

3.leastconn

新的连接请求被派发至具有最少连接数目的后端服务器。

4.LVS

4.1.LVS负载均衡四种工作模式

• LVS/NAT：网络地址转换模式，进站/出站的数据流量经过分发器/负载均衡器(IP负载均衡，他修改的是IP地址) --利用三层功能

• LVS/DR：直接路由模式，只有进站的数据流量经过分发器/负载均衡器(数据链路层负载均衡，因为他修改的是目的mac地址)--利用二层功能mac地址

• LVS/TUN： 隧道模式，只有进站的数据流量经过分发器/负载均衡器

• LVS/full-nat:双向转换，通过请求报文的源地址为DIP，目标为RIP来实现转发：对于响应报文而言，修改源地址为VIP，目标地址为CIP来实现转发

4.2.LVS四种工作模式原理,以及优缺点比较

4.2.1、NAT模式（LVS-NAT）

原理：就是把客户端发来的数据包的IP头的目的地址，在负载均衡器上换成其中一台RS的IP地址，转发至此RS来处理,RS处理完成后把数据交给经过负载均衡器,负载均衡器再把数据包的源IP地址改为自己的VIP，将目的地址改为客户端IP地址即可｡期间,无论是进来的流量,还是出去的流量,都必须经过负载均衡器｡

优点：集群中的物理服务器可以使用任何支持TCP/IP操作系统，只有负载均衡器需要一个合法的IP地址。

缺点：扩展性有限。当服务器节点（普通PC服务器）增长过多时,负载均衡器将成为整个系统的瓶颈，因为所有的请求包和应答包的流向都经过负载均衡器。当服务器节点过多时，大量的数据包都交汇在负载均衡器那，速度就会变慢！

4.2.2、直接路由(Direct Routing)模式（LVS-DR）

原理：负载均衡器和RS都使用同一个IP对外服务｡但只有DB对ARP请求进行响应,所有RS对本身这个IP的ARP请求保持静默｡也就是说,网关会把对这个服务IP的请求全部定向给DB,而DB收到数据包后根据调度算法,找出对应的RS,把目的MAC地址改为RS的MAC（因为IP一致）并将请求分发给这台RS｡这时RS收到这个数据包,处理完成之后，由于IP一致，可以直接将数据返给客户，则等于直接从客户端收到这个数据包无异,处理后直接返回给客户端｡

优点：和TUN（隧道模式）一样，负载均衡器也只是分发请求，应答包通过单独的路由方法返回给客户端。与LVS-TUN相比，LVS-DR这种实现方式不需要隧道结构，因此可以使用大多数操作系统做为物理服务器。

缺点：（不能说缺点，只能说是不足）要求负载均衡器的网卡必须与物理网卡在一个物理段上。

4.2.3、IP隧道(Tunnel)模式（LVS-TUN）

原理：互联网上的大多Internet服务的请求包很短小，而应答包通常很大。那么隧道模式就是，把客户端发来的数据包，封装一个新的IP头标记(仅目的IP)发给RS,RS收到后,先把数据包的头解开,还原数据包,处理后,直接返回给客户端,不需要再经过负载均衡器｡注意,由于RS需要对负载均衡器发过来的数据包进行还原,所以说必须支持IPTUNNEL协议｡所以,在RS的内核中,必须编译支持IPTUNNEL这个选项

优点：负载均衡器只负责将请求包分发给后端节点服务器，而RS将应答包直接发给用户。所以，减少了负载均衡器的大量数据流动，负载均衡器不再是系统的瓶颈，就能处理海量的请求量，这种方式，一台负载均衡器能够为很多RS进行分发。而且跑在公网上就能进行不同地域的分发。

缺点：隧道模式的RS节点需要合法IP，这种方式需要所有的服务器支持”IP Tunneling”(IP Encapsulation)协议，服务器可能只局限在部分Linux系统上。

4.2.4、FULL-NAT模式（双向转换模式）

原理:客户端对VIP发起请求，Director接过请求发现是请求后端服务。Direcrot对请求报文做full-nat，把源ip改为Dip，把目标ip转换为任意后端RS的rip，然后发往后端，rs接到请求后，进行响应，相应源ip为Rip目标ip还是DIP，又内部路由路由到Director,Director接到响应报文，进行full-nat。将源地址为VIP，目标地址改为CIP

请求使用DNAT，响应使用SNAT

lvs-fullnat（双向转换）

通过请求报文的源地址为DIP，目标为RIP来实现转发：对于响应报文而言，修改源地址为VIP，目标地址为CIP来实现转发：

5.haproxy负载均衡搭建流程

在Ubuntu上部署HAProxy，你可以按照以下步骤进行操作：

5.1.安装HAProxy

打开终端，运行以下命令来安装HAProxy：

sudo apt update sudo apt install haproxy

5.2.配置HAProxy

HAProxy的主要配置文件是 /etc/haproxy/haproxy.cfg。你可以使用文本编辑器打开并编辑此文件：

vim /etc/haproxy/haproxy.cfg

在配置文件中，你需要定义后端服务器和监听器。以下是一个简单的示例配置，将HAProxy配置为负载均衡HTTP请求到两个后端Web服务器：

global log /dev/log local0 # 设置日志记录，使用本地 syslog 的 local0 设施 log /dev/log local1 notice # 设置另一个日志记录级别为 notice，使用 local1 设施 maxconn 4096 # 定义最大并发连接数为 4096 user haproxy # 设置 HAProxy 运行的用户为 haproxy group haproxy # 设置 HAProxy 运行的组为 haproxy defaults log global # 应用全局日志设置 mode http # 设置工作模式为 HTTP option httplog # 启用 HTTP 日志格式 option dontlognull # 不记录空的请求 timeout connect 5000 # 连接超时设置为 5 秒 timeout client 50000 # 客户端超时设置为 50 秒 timeout server 50000 # 服务器超时设置为 50 秒 frontend http-in bind *:80 # 监听所有接口的 80 端口进行 HTTP 请求 default_backend servers # 将请求转发到名为 'servers' 的后端 backend servers balance roundrobin # 采用轮询方式对后端服务器进行负载均衡 server web1 192.168.5.101:80 check # 定义第一个后端服务器，启用健康检查 server web2 192.168.5.102:80 check # 定义第二个后端服务器，启用健康检查

在这个示例中，我们定义了两个后端服务器（web1和 web2），它们的IP地址和端口是示例值，你需要替换为实际的后端服务器信息。

检查配置

在编辑完成配置文件后，运行以下命令检查配置文件是否有语法错误：

sudo haproxy -c -f /etc/haproxy/haproxy.cfg

如果没有出现错误消息，说明配置文件有效。

重启HAProxy：

重新启动HAProxy以使配置生效：

sudo systemctl restart haproxy

启用自动启动（可选）：

如果你希望HAProxy在系统启动时自动启动，可以运行以下命令：

sudo systemctl enable haproxy

5.3.测试

这里我们用两台虚拟机分别部署nginx web页面

分别是192.168.5.101和192.168.5.102

我们访问haproxy的web页面 端口默认80

点击刷新 我们设置的策略是轮循

可以看见页面在111和222中切换

haproxy配置文件详解更新在配置文件模版

版权声明：本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：jacktools123@163.com进行投诉反馈，一经查实，立即删除！