转载 codeceo 原文连接:http://www.codeceo.com/article/linux-haproxy-http-balance.html

如今对基于互联网的应用和服务的要求越来越大,这给广大的IT管理员施加了越来越大的压力。面对突如其来的流量猛增、自生的流量增加或者是内部挑战(比如硬件故障和紧急维护),不管怎样,你的互联网应用都必须保持随时可用。连现代化的开发运营和持续交付做法也会危及互联网服务的可靠性和一贯表现。

无法预测或缺乏一贯的表现是你所无法承受的。那么,我们如何能消除这些缺点呢?在大多数情况下,一套合适的负载均衡解决方案有望满足这个要求。今天我将为各位介绍如何使用HAProxy搭建一套HTTP负载均衡系统。

HTTP负载均衡简介

HTTP负载均衡是一种网络解决方案,负责在托管相同应用内容的几台服务器之间分配进入的HTTP或HTTPS流量。由于在多台可用服务器之间均衡了应用请求,负载均衡系统就能防止任何应用服务器变成单一故障点,因而提高了整体的应用可用性和响应能力。它还让你可以随着不断变化的工作负载,轻松地缩小/扩大部署的应用系统的规模,只需添加或删除额外的应用服务器。

哪里使用负载均衡、何时使用?

由于负载均衡系统改进了服务器的利用率,最大限度地提高了可用性,只要你的服务器开始面临繁重负载,或者正为一个较庞大的项目规划架构,就应该使用它。事先规划好负载均衡系统的用途是个好习惯。那样,未来你需要扩展环境规模时,它会证明其用途。

HAProxy是什么东东?

HAProxy是一种流行的开源负载均衡和代理系统,面向GNU/Linux平台上的TCP/HTTP服务器。HAProxy采用了单一线程的事件驱动型架构而设计,它能够轻松地处理10G网卡线路速度,现广泛应用于许多生产环境中。其功能特性包括:自动检查健康状况、可定制的负载均衡算法、支持HTTPS/SSL以及会话速率限制等。

我们在本教程中要达到什么样的目的?

在本教程中,我们将逐步介绍为HTTP网站服务器配置基于HAProxy的负载均衡系统这个过程。

前提条件

你至少需要一台(最好是两台)网站服务器来证实所搭建负载均衡系统的功能。我们假设,后端HTTP网站服务器已经搭建并运行起来。

将HAProxy安装到Linux上

就大多数发行版而言,我们可以使用你所用发行版的软件包管理器来安装HAProxy。

将HAProxy安装到Debian上

在Debian中,我们需要为Wheezy添加向后移植功能。为此,请在/etc/apt/sources.list.d中创建一个名为“backports.list”的新文件,其内容如下:

deb http://cdn.debian.net/debian wheezy­backports main

更新你的软件库数据,并安装HAProxy。

# apt­ get update
# apt ­get install haproxy

将HAProxy安装到Ubuntu上

# apt ­get install haproxy

将HAProxy安装到CentOS和RHEL上

# yum install haproxy

配置HAProxy

在本教程中,我们假设有两台HTTP网站服务器已搭建并运行起来,其IP地址分别为192.168.100.2和192.168.100.3。我们还假设,负载均衡系统将在IP地址为192.168.100.4的那台服务器处进行配置。

为了让HAProxy发挥功用,你需要更改/etc/haproxy/haproxy.cfg中的几个项目。这些变更在本章节中予以描述。万一某个配置对不同的GNU/Linux发行版而言有所不同,会在相应段落中加以注明。

1. 配置日志功能

你首先要做的工作之一就是,为你的HAProxy建立合适的日志功能,这对将来进行调试大有用处。日志配置内容位于/etc/haproxy/haproxy.cfg的global部分。下面这些是针对特定发行版的指令,用于为HAProxy配置日志。

CentOS或RHEL:

要想在CentOS/RHEL上启用日志功能,把:

log 127.0.0.1 local2

换成:

log 127.0.0.1 local0

下一步,在/var/log中为HAProxy创建单独的日志文件。为此,我们需要改动当前的rsyslog配置。为了让配置简单而清楚,我们将在/etc/rsyslog.d/中创建一个名为haproxy.conf的新文件,其内容如下。

$ModLoad imudp
$UDPServerRun 514
$template Haproxy,”%msg%\n”
local0.=info ­/var/log/haproxy.log;Haproxy
local0.notice ­/var/log/haproxy­status.log;Haproxy
local0.* ~

该配置将把基于$template的所有HAProxy消息隔离到/var/log中的日志文件。现在,重启rsyslog,让变更内容生效。

# service rsyslog restart

Debian或Ubuntu:

要想在Debian或Ubuntu上为HAProxy启用日志功能,把:

log /dev/log local0
log /dev/log local1 notice

换成:

log 127.0.0.1 local0

下一步,为HAProxy配置单独的日志文件,编辑/etc/rsyslog.d/中一个名为haproxy.conf的文件(或者Debian中的49-haproxy.conf),其内容如下。

$ModLoad imudp
$UDPServerRun 514
$template Haproxy,”%msg%\n”
local0.=info ­/var/log/haproxy.log;Haproxy
local0.notice ­/var/log/haproxy­status.log;Haproxy
local0.* ~

该配置将把基于$template的所有HAProxy消息隔离到/var/log中的日志文件。现在,重启rsyslog,让变更内容生效。

# service rsyslog restart

2. 设置默认值

下一步是为HAProxy设置默认变量。找到/etc/haproxy/haproxy.cfg中的defaults部分,把它换成下列配置。

log     global
mode    http
option  httplog
option  dontlognull
retries 3
option redispatch
maxconn 20000
contimeout      5000
clitimeout      50000
srvtimeout      50000

上述配置推荐HTTP负载均衡器使用,但可能不是最适合你环境的解决方案。如果那样,请参阅HAProxy参考手册页,进行适当的改动和调整。

3. 网站服务器集群的配置

网站服务器集群(Webfarm)的配置定义了可用的HTTP服务器集群。我们所建负载均衡系统的大部分设置都将放在这里。现在,我们将创建一些基本的配置,我们的节点将在这里加以定义。把从frontend部分到文件末尾的所有配置换成下列代码:

listen webfarm *:80
mode http
stats enable
stats uri /haproxy?stats
stats realm Haproxy\ Statistics
stats auth haproxy:stats
balance roundrobin
cookie LBN insert indirect nocache
option httpclose
option forwardfor
server web01 192.168.100.2:80 cookie node1 check
server web02 192.168.100.3:80 cookie node2 check

“listen webfarm *:80”这一行定义了我们的负载均衡系统将侦听哪些接口。出于本教程的需要,我将该值设为“*”,这让负载均衡系统侦听我们的所有接口。在实际场景下,这可能不合意,应该换成可从互联网来访问的某个接口。

stats enable
stats uri /haproxy?stats
stats realm Haproxy\ Statistics
stats auth haproxy:stats

上述设置声明,可以在http://<load-balancer-IP>/haproxy?stats处访问负载均衡系统的统计数字。这种访问由简单的HTTP验证以及登录名“haproxy”和密码“stats”来确保安全。这些设置应该换成你自己的登录信息。如果你不想让这些统计数字被人看到,那么可以完全禁用它们。

下面是HAProxy统计数字的一个例子。

 

“balance roundrobin”这一行定义了我们将使用哪种类型的负载均衡。在本教程中,我们将使用简单的轮叫调度算法,这对HTTP负载均衡来说完全绰绰有余。HAProxy还提供了其他类型的负载均衡:

•leastconn:连接数最少的服务器优先接收连接。

•source:对源IP地址进行哈希处理,用运行中服务器的总权重除以哈希值,即可决定哪台服务器将接收请求。

•uri:URI的左边部分(问号前面)经哈希处理,用运行中服务器的总权重除以哈希值。所得结果决定哪台服务器将接收请求。

•url_param:变量中指定的URL参数将在每个HTTP GET请求的查询串中进行查询。你基本上可以将使用蓄意制作的URL(crafted URL)的请求锁定于特定的负载均衡节点。

•hdr(name):HTTP头<name> 将在每个HTTP请求中进行查询,被定向到特定节点。

“cookie LBN insert indirect nocache”这一行让我们的负载均衡系统存储持久性cookie,这让我们得以准确查明集群中的哪个节点用于某一个会话。这些节点cookie将与指定的名称一并存储起来。在我们这个例子中,我使用了“LBN”,但你可以指定自己喜欢的任意名称。节点将为该cookie把字符串作为一个值而存储起来。

server web01 192.168.100.2:80 cookie node1 check
server web02 192.168.100.3:80 cookie node2 check

上述部分对网站服务器节点集群进行了定义。每台服务器都用内部名称(比如web01和web02)、IP地址和独特的cookie串来表示。cookie串可以定义为你需要的任何名称。我使用了简单的node1、node2 … node(n)。

启动HAProxy

你完成了配置工作后,可以启动HAProxy,验证一切按预期运行。

在Centos/RHEL上启动HAProxy

使用下列指令,让HAProxy能够在系统启动后启动,并打开它:

# chkconfig haproxy on
# service haproxy start

当然,别忘了启用防火墙中的端口80,如下所示。

CentOS/RHEL 7上的防火墙:

# firewall­cmd ­­permanent ­­zone=public ­­add­port=80/tcp
# firewall­cmd ­­reload

CentOS/RHEL 6上的防火墙:

把下面这一行添加到/etc/sysconfig/iptables中的这部分“:OUTPUT ACCEPT”:

A INPUT ­m state ­­state NEW ­m tcp ­p tcp ­­dport 80 ­j ACCEPT

然后重启iptables:

# service iptables restart

在Debian上启动HAProxy

使用下列指令启动HAProxy:

# service haproxy start

别忘了启用防火墙中的端口80,为此把下面这一行添加到/etc/iptables.up.rules:

A INPUT ­p tcp ­­dport 80 ­j ACCEPT

在Ubuntu上启动HAProxy

让HAProxy能够在系统启动后启动,只要在/etc/default/haproxy中将“ENABLED”选项设为“1”:

ENABLED=1

启动HAProxy:

# service haproxy start

然后启用防火墙中的端口80:

# ufw allow 80

测试HAProxy

为了检查HAproxy是否在正常工作,我们可以执行下列步骤:

首先,用下列内容准备好test.php文件:

<?php
header(‘Content-Type: text/plain’);
echo ”Server IP: ”.$_SERVER['SERVER_ADDR'];
echo ”\nX-Forwarded-for: ”.$_SERVER['HTTP_X_FORWARDED_FOR'];
?>

该PHP文件将告诉我们哪台服务器(即负载均衡系统)转发请求,哪台后端网站服务器实际处理请求。

把该PHP文件放到这两台后端网站服务器的根目录下。现在,使用curl命令,从负载均衡系统(192.168.100.4)提取这个PHP文件。

$ curl http://192.168.100.4/test.php

我们多次运行这个命令时,应该会看到下面两个输出交替出现(由于轮叫调度算法)。

Server IP: 192.168.100.2

X-Forwarded-for: 192.168.100.4

Server IP: 192.168.100.3

X-Forwarded-for: 192.168.100.4

如果我们停止这两台后端网站服务器中的其中一台,curl命令应该仍会执行,将请求定向到另一台可用的网站服务器。

结束语

至此,你应该有了一套完全实用的负载均衡系统,能够在轮叫循环模式下为你的网站节点提供请求。与往常一样,你可以随意更改配置,让它更适合自己的基础设施。希望本教程帮助你让自己的网站项目具有更强的抗压力和更高的可用性。

正如大家已经注意到的那样,本教程所含的设置适用于仅仅一套负载均衡系统。这意味着,我们把一个单一故障点换成了另一个单一故障点。在实际场景下,你应该部署至少两套或三套负载均衡系统,以防范可能出现的任何故障,但这不在本教程的讨论范围之内。

要是你有什么问题或建议,欢迎留言。