最大化的利用 HAProxy

shenzhang

HAProxy是一个我们在Twilio上广泛使用的神奇软件。今天我们回过头看一下我们的HAProxy配置并解释其中的一些设置。但首先，是我们使用HAProxy历史的一个小故事。

最开始的时候，我们的创始人创建了一个HAProxy的配置。这个配置让集群中的一台主机与其他主机进行通信，并承载各种形式的流量。这个配置在那时是可接受的，它使得创始人开始首轮筹资。

然后创始人说，“我要做一个SMS服务，这个服务可以发送短信。API也可以调用SMS服务来发送消息，这样会很好的。” 不过他们需要一个可以调用SMS服务API的配置。他们将语音服务的配置复制过来，还有它调用SMS的API，很简单。但这个配置不适合SMS请求的要求。

这个配置通吃，它被应用到了Twilio的很多服务。但没有人真正了解这个配置或它的选项。所以当他们需要一个新的配置时，他们就从老配置复制一个。在这种情况下，问题蔓延到了整个集群。

这就是我们过去在Twilio使用HAProxy设置的状态。我们所有的HAProxy配置都是相互拷贝，只更改一些超时值。在我们5个9的可靠性追求下，我们对我们的HAProxy配置进行了增强，以确保它们能稳定地提供服务和承载流量。让我们来看一个示例配置。

# Twilio HTTP HAProxy Configuration# Version: 0.1

这行让我们一看就知道配置在近期由公司的谁重置或更新过，一目了然。

mode    http
option  httplog
log 127.0.0.1 local0 info

这两个选项打开了HAProxy的大多数功能，如果你让HAProxy承载HTTP流量的话你一定也有这个设置。mode http表示HAProxy将检查传入的HTTP请求，如果请求无效便拒绝它。





这个模式允许你记录HTTP请求，生成的日志格式形式如下：


1
Oct
9 15:32:25 127.0.0.1 haproxy[32156]: 127.0.0.1:34677


2
    [09/Oct/2013:15:32:25.744]
twilio-frontend twilio-backends/10.10.10.10


3
    0/0/0/38/71
200 944419 - - ---- 94/0/0/ 0/0 0/0


4
    "GET
http://example.com/ACaaaa?Signature=signature HTTP/1.1"


这些日志给我们展示了请求的丰富细节——从请求的URL到连接花费的时间、下载耗时、应答流的并发连接总数等许多信息。要了解这些日志信息的详细解释的话，看一下HAProxy文档的日志部分。

由于我们将越来越多的Twilio工具转换成了面向服务的架构，这些日志在调试错误时非常有用。举个例子，一个顾客反馈她的录音下载时会偶尔失败。虽然录音使用多个不同的服务，但日志中记录了网络组件间协作的时序，这样它就帮助我们定位到了故障的单台主机。





第三行

log 127.0.0.1 local0 info

开启haproxy记录日志到syslog。local0有一个指定的守护进程监听请求，并将收到的haproxy日志记录到一个日志文件中。

注意，启用info级的日志级别意味着HAProxy将记录每一个传入的请求。对于长时间运行的服务器来说，这意味着日志文件早晚会占满硬盘。有一个数据整理策略很重要——每晚使用logrotate等工具截断压缩前一天的日志，删除两周前的日志等。

option http-server-close

假设你有一台HAProxy前端与十个不同的后端通信，且这十个后端不支持HTTP keep-alive。这个设置让HAProxy在客户端和前端之间保持一个持久的连接，并在所有后端服务器之间轮询HTTP请求。当然，要发挥这个设置的功效的话需要客户端同样启用keep-alive。




timeout client 30s
timeout server 30s
这两个设置一起用来设置 HAProxy发送请求的超时时长。实际上，HAProxy等待服务器返回信息给客户端需要多久呢？大多数应用都有某种最大延迟时间，因此你需要添加超时时长。对我们来说，API等待响应的最长时间是30秒，所以每个内部服务根据自身的服务级等级协议（SLA）都应该设置低于30秒的超时时长。注意：如果服务器缓慢地以流的方式传输一个字节，也就是每29秒传输一个字节的话，你将不能触发读超时，所以你可能需要有一个单独的线程监控这样的请求，以保证在适当的时间内完成传输。你还应当把客户端和服务端的超时时长设置为相同的值-即套接口上所期望的读超时时长。
timeout connect 3100
这是一个不同于客户端和服务端超时时长的超时时长！它是HAProxy应当用来试图连接主机所花费的时长。在RWilio以前的日子里，它设置为与服务器超时时长30秒相同的值，因此如果主机宕机的话，HAProxy将试图连接同一个主机30秒。当服务器和客户端主机位于同一个机器上或者在同一个局域网内（或者AZ主机的附近）的时候，这样的连接通常发生在毫秒级。我们允许在进一步处理默认的重传窗口时等待3秒，并且允许有小量的缓冲。



不像服务器超时时长，连接超时时长隐含着客户端的重新连接请求是安全的这层意思。

retries 2
option redispatch

当我说30秒的连接超时时长意味着HAProxy将在30秒内试图进行一次未连接上的连接的时候，我撒谎了。实践证明： 默认情况下,HAProxy将试图进行3次连接请求。因此30秒的连接超时实际上是120秒的连接超时，这违反了服务级别协议，而且意味着我们给客户兑现的是空头支票。

如果第一台主机关机了，那么通常假设HAProxy自动给第二台主机发送请求。不过这仅仅在HAProxy对这个主机进行健康检查后并标记这台主机已经关机的情况下才是这样的。如果一台主机关机了而且对它的健康检查花费了20秒，那么这时你正在对这台主机进行可能的20秒的无效请求。重新分发选项让最终的连接请求发送给另一台下游主机上，因此不同主机发送各自的请求在某种程度上保护了已经不健康的主机。





这两个设置混合在一起缩减重试次数到2，并且这也意味着在放弃这个连接并对另一台主机进行连接之前，我们试图对这台主机进行连接的最大超时时长只有8秒。

option httpchk GET /healthcheck
默认情况下，HAProxy只是对主机打开了一个TCP连接来检查这台主机是否启动。这种ping只能检测这台主机是否关机，不过不能确定它是不健康的（磁盘损坏，网络连接不正常）。httpchk选项将给位于后端的终端节点发送HTTP请求。后端可以进行自检，并回答自身是否健康。注意健康检查应当是相当保守的一种做法，而且通常还扩大了单台主机健康的范围。健康检查未通过将使HAProxy给这台主机不发送任何包，而且如果所有的主机同时都“不健康”，那么你将没有任何后端可依赖了。 我希望这篇文章对你有帮助-我已经在 这儿发布了HAProxy配置的所有更新版本。至于其他问题，
可以阅读手册，这样可以让服务器在性能、可靠性、可用性和稳定性方面得到很大的提高。希望这篇概览能够节省你的时间。