使用HAProxy进行第7层负载平衡

时间:2020-01-09 10:41:10  来源:igfitidea点击:

说明

第7层负载平衡使我们可以根据网站所请求的内容将流量分离到不同的服务器上。例如,我们可以将对静态内容html,jpg,gif,css等的所有请求转发到一个服务器集群,而将所有剩余的请求转发到另一服务器集群。另一个示例是将主站点与论坛置于不同的服务器上,这会使流量增加。

请求通过网站域名进入负载平衡器,然后被转发到其他群集,以查找与/ blog,/或者/ forums匹配的任何内容。所有三个集群都连接到相同的数据库后端。

为了确定将请求转发到哪个服务器组,负载均衡器必须分析每个数据包的HTTP请求,以使其与规则进行匹配。与第4层平衡相比,这需要更多的CPU时间,因此我们将无法获得相同的容量或者速度。但是,对于访问量较大的大型网站或者有复杂需求的网站而言,优点要远远超过缺点。

创建浮动IP地址

浮动IP地址是大多数负载平衡器使用的术语。它实际上是添加到物理网络接口的添加IP地址。这不是绝对必要的,因为我们可以使用负载平衡器的IP地址。但是,当我们平衡多个不同的应用程序时,这成为必需。

  • 通过复制现有接口并在文件名的末尾添加冒号(:)和0值来创建新的网络接口。我们将在本教程的第一个界面中添加浮动IP。
cp /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-eth0:0
  • 在文本编辑器中打开新文件。
  • 修改接口名称,将其从eth0更改为eth0:0,如下例所示。当然,如果要将浮动IP添加到第二个网络接口eth1,则名称将改为eth1:0。如果要添加第二个浮动IP地址,则将最后一个值加1,使其为eth1:1.
DEVICE=eth0:0
TYPE=Ethernet
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=none
IPADDR=172.30.0.30
PREFIX=24
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
NAME="System eth0:0"
  • 保存更改并退出文本编辑器。
  • 重新启动网络服务以初始化浮动IP。
services network restart
  • 或者,我们可以先关闭物理接口,然后再重新启动。
ifdown eth0
ifup eth0
  • 使用ifconfig命令验证新接口是否处于联机状态并分配了浮动IP。输出应类似于以下示例。
eth0      Link encap:Ethernet  HWaddr 00:0C:29:E9:C0:05
          inet addr:172.30.0.25  Bcast:172.30.0.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fee9:c005/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:27 errors:0 dropped:0 overruns:0 frame:0
          TX packets:32 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2316 (2.2 KiB)  TX bytes:3244 (3.1 KiB)

eth0:0    Link encap:Ethernet  HWaddr 00:0C:29:E9:C0:05
          inet addr:172.30.0.30  Bcast:172.30.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

创建前端服务器

前端服务器用于侦听特定负载均衡器服务器组在特定IP地址上的传入连接。对于第7层平衡,我们将配置多个服务器组,并且这是在前端服务器的配置中放置逻辑以确定连接转发位置的位置。

  • 在文本编辑器中打开HAProxy配置。
  • 在配置文件的global和defaults部分之后,创建一个新的前端并为其命名。我们将其称为前端webapp1.
frontend webapp1
  • 现在,将浮动IP地址绑定到端口80上的webapp1前端。
frontend webapp1
        bind 172.30.0.30:80
  • 将协议模式设置为http,这是第7层平衡分析传入的HTTP请求所必需的。
frontend webapp1
        bind 172.30.0.30:80
        mode http
  • 创建一个默认的后端服务器组。当请求与我们将要创建的策略不匹配时,用户将登陆此处。
frontend webapp1
        bind 172.30.0.30:80
        mode http
        default_backend webapp1-main
  • 让我们创建第一个名为url_forum的acl。此ACL将用于将对我们论坛的所有请求转发到单独的服务器组。
frontend webapp1
        bind 172.30.0.30:80
        mode http
        acl url_forum      path_beg     /forum
        default_backend webapp1-main
  • 接下来,我们需要创建一条规则以将与url_forumacl匹配的所有请求转发到论坛的后端服务器。我们将我们的论坛后端服务器组称为webapp1_forum。
frontend webapp1
        bind 172.30.0.30:80
        mode http
        acl url_forum      path_beg     /forum
        use_backend webapp1_forum if url_forum
        default_backend webapp1-main

创建后端服务器

后端用于定义不同的服务器组或者集群。我们将创建两个名为webapp1_main和webapp1_forum的后端服务器组。第一个是默认情况下将到达所有请求的位置,第二个是将域名之后URL中以/ forum开头的任何请求都放置的位置。

后端Webapp1_main

  • 在HAProxy配置文件的前端部分下,启动一个名为webapp1_main的新后端。
backend webapp1_main
  • 设置协议模式以匹配前端。
backend webapp1_main
        mode http
  • 设置后端服务器的负载平衡算法。我们将使用轮询。
backend webapp1_main
        mode http
        balance roundrobin
  • 让我们通过添加其IP地址和其Web服务器侦听的端口号,将第一个服务器webserver1添加到后端集群。
backend webapp1_main
        mode http
        balance roundrobin
        server webserver1 172.30.0.27:80
  • 现在,我们向该后端添加第二个服务器。
backend webapp1_main
        mode http
        balance roundrobin
        server webserver1 172.30.0.27:80
        server webserver2 172.30.0.28:80
  • 创建第一个后端。现在创建第二个。

后端Webapp1_main

  • 我们将使用与第一个后端群集相同的配置来创建第二个后端群集,称为webapp1_forum。唯一不同的是我们在集群中使用的服务器。
backend webapp1_forum
        mode http
        balance roundrobin
        server webserver3 172.30.0.50:80
        server webserver4 172.30.0.51:80
  • 将更改保存到配置文件,然后退出文本编辑器。
  • 重新加载HAProxy配置文件。
service haproxy reload

负载均衡算法

轮循roundrobin

每个服务器根据其权重依次使用。当服务器的处理时间保持均匀分布时,这是最流畅,最公平的算法。该算法是动态的,这意味着可以为例如慢速启动动态调整服务器权重。

最小连接leastconn

连接数最少的服务器接收该连接。循环在具有相同负载的服务器组内执行,以确保将使用所有服务器。建议在预计会话时间很长的地方(例如LDAP,SQL,TSE等)使用此算法,但不适用于使用短会话的协议(例如HTTP)。该算法是动态的,这意味着可以为例如慢速启动动态调整服务器权重。

来源source

源IP地址经过哈希处理,然后除以运行中服务器的总权重,以指定将接收请求的服务器。这样可以确保相同的客户端IP地址将始终与同一服务器连接,只要没有服务器出现故障即可。如果哈希结果由于正在运行的服务器数量发生更改而发生变化,则许多客户端将被定向到其他服务器。此算法通常在TCP模式下使用,该模式下不能插入cookie。它也可以在Internet上用于为拒绝会话cookie的客户端提供最大努力的粘性。该算法是静态的,这意味着动态更改服务器的权重将无效。

uri

URI的左侧部分(问号之前)被散列并除以正在运行的服务器的总权重。结果指定哪个服务器将接收请求。这样可以确保只要没有服务器出现故障,相同的URI将始终定向到同一服务器。它与代理缓存和防病毒代理一起使用,以最大程度地提高缓存命中率。请注意,此算法只能在HTTP后端中使用。该算法是静态的,这意味着动态更改服务器的权重将无效。

url_param

与uri相似,只是在哈希中使用了URL参数。这是WordPress和其他内容管理系统使用的永久链接类型URL的理想选择。

健康检查

当负载平衡群集中的服务器不可用时,我们不希望将流量转发到该服务器。运行状况检查是一种自动发现停止响应的服务器的方法。通过在后端的服务器中添加check选项来启用运行状况检查,如以下示例所示。

backend webapp1-servers
        balance roundrobin
        mode tcp
        server webserver1 192.168.1.200:80 check
        server webserver2 192.168.1.201:80 check
        server webserver3 192.168.1.202:80 check

服务器维护

每台服务器在生命周期的某个时刻都需要某种形式的维护。为了使服务器脱机以进行维护并防止流量在脱机时转发到该服务器,我们可以使用禁用选项。

backend webapp1-servers
        balance roundrobin
        mode tcp
        server webserver1 192.168.1.200:80 check
        server webserver2 192.168.1.201:80 check
        server webserver3 192.168.1.202:80 check disabled