Haproxy Keyword
1、关键词 balance
balance 用于定义负载均衡的算法，可用于 defaults、listen 和 backend 中。
balance 使用方法如下：
balance balance url_param [check_post [ balance 支持的算法有： roundrobin：基于权重进行轮询，在服务器的处理时间保持均匀分布时，这是最平衡、最公平的算法。此算法是动态的，这表示其权重可以在运行时进行调整。不过在设计上，每个后端服务器仅能最多接受 4128 个连接。 source：将请求的源地址进行 hash 运算，并由后端服务器的权重总数相除后派发至某匹配的服务器。这可以使得同一个客户端 IP 的请求始终被派发至某特定的服务器；不过，当服务器权重总数发生变化时，如某服务器宕机或添加了新的服务器，许多客户端的请求可能会被派发至与此前请求不同的服务器；常用于负载均衡无 cookie 功能的基于 TCP 的协议；其默认为静态，不过也可以使用 hash-type 修改此特性。 static-rr：基于权重进行轮询，与 roundrobin 类似，但是为静态方法，在运行时调整其服务器权重不会生效；不过，其在后端服务器连接数上没有限制。 leastconn：新的连接请求被派发至具有最少连接数目的后端服务器；在有着较长时间会话的场景中推荐使用此算法，如 LDAP、SQL 等，其并不太适用于较短会话的应用层协议，如 HTTP；此算法是动态的，可以在运行时调整其权重。 uri：对 URI 的左半部分 (“问题” 标记之前的部分) 或整个 URI 进行 hash 运算，并由服务器的总权重相除后派发至某匹配的服务器；这可以使得对同一个 URI 的请求总是被派发至某特定的服务器，除非服务器的权重总数发生了变化；此算法常用于代理缓存或反病毒代理以提高缓存的命中率；需要注意的是，此算法仅应用于 HTTP 后端服务器场景；其默认为静态算法，不过也可以使用 hash-type 修改此特性。 url_param：通过 < argument > 为 URL 指定的参数在每个 HTTP GET 请求中将会被检索；如果找到了指定的参数且其通过等于号 “=” 被赋予了一个值，那么此值将被执行 hash 运算并被服务器的总权重相除后派发至某匹配的服务器；此算法可以通过追踪请求中的用户标识进而确保同一个用户 ID 的请求将被送往同一个特定的服务器，除非服务器的总权重发生了变化；如果某请求中没有出现指定的参数或其没有有效值，则使用轮叫算法对相应请求进行调度；此算法默认为静态的，不过其也可以使用 hash-type 修改此特性。 hdr( bind 仅能用于 frontend 和 listen 区段，用于定义一个或几个监听的套接词。 bind 使用方法如下： bind [ bind [ 需要注意的是，每组监听的套接词 < address:port > 在同一个实例上只能使用一次，而且小于 1024 的端口需要有特定权限的用户才能使用，这可能需要通过 uid 参数来定义。 mode 用于设定实例的运行模式或协议。当实现内容交换时，前端和后端必须工作于同一种模式 (一般说来都是 HTTP 模式)，否则将无法启动实例。 mode 可被用与 listen、defaults、frontend、backend 区段。 mode 使用方法如下： mode { tcp|http|health } tcp：实例运行于纯 TCP 模式（即 4 层），在客户端和服务器端之间将建立一个全双工的连接，且不会对 7 层报文做任何类型的检查；此为默认模式，通常用于 SSL、SSH、SMTP 等应用。 http：实例运行于 HTTP 模式（即 7 层），客户端请求在转发至后端服务器之前将被深度分析，所有不与 RFC 格式兼容的请求都会被拒绝。 health：实例工作于 health 模式，其对入站请求仅响应 “OK” 信息并关闭连接，且不会记录任何日志信息；此模式将用于响应外部组件的健康状态检查请求；目前此模式已经废弃，因为 tcp 或 http 模式中的 monitor 关键词可完成类似功能； hash-type 定义用于将 hash 码映射至后端服务器的方法；其不能用于 frontend 区段；可用方法有 map-based 和 consistent，在大多数场景下推荐使用默认的 map-based 方法。 hash-type 使用方法如下： hash-type map-based：hash 表是一个包含了所有在线服务器的静态数组。其 hash 值将会非常平滑，会将权重考虑在列，但其为静态方法，对在线服务器的权重进行调整将不会生效，这意味着其不支持慢速启动。此外，挑选服务器是根据其在数组中的位置进行的，因此，当一台服务器宕机或添加了一台新的服务器时，大多数连接将会被重新派发至一个与此前不同的服务器上，对于缓存服务器的工作场景来说，此方法不甚适用。 consistent：hash 表是一个由各服务器填充而成的树状结构；基于 hash 键在 hash 树中查找相应的服务器时，最近的服务器将被选中。此方法是动态的，支持在运行时修改服务器权重，因此兼容慢速启动的特性。添加一个新的服务器时，仅会对一小部分请求产生影响，因此，尤其适用于后端服务器为 cache 的场景。不过，此算法不甚平滑，派发至各服务器的请求未必能达到理想的均衡效果，因此，可能需要不时的调整服务器的权重以获得更好的均衡性。 log 为每个实例启用事件和流量日志，因此可用于所有区段。每个实例最多可以指定两个 log 参数，不过，如果使用了 “log global” 且”global” 段已经定了两个 log 参数时，多余了 log 参数将被忽略。 log global log global：当前实例的日志系统参数同”global” 段中的定义时，将使用此格式；每个实例仅能定义一次 “log global” 语句，且其没有任何额外参数。 maxconn 设定一个前端的最大并发连接数，因此，其不能用于 backend 区段。 maxconn 使用方法如下： maxconn 对于大型站点来说，可以尽可能提高此值以便让 haproxy 管理连接队列，从而避免无法应答用户请求。当然，此最大值不能超出 “global” 段中的定义。此外，需要留心的是，haproxy 会为每个连接维持两个缓冲，每个缓冲的大小为 8KB，再加上其它的数据，每个连接将大约占用 17KB 的 RAM 空间。这意味着经过适当优化后，有着 1GB 的可用 RAM 空间时将能维护 40000-50000 并发连接。 如果为 < conns > 指定了一个过大值，极端场景下，其最终占据的空间可能会超出当前主机的可用内存，这可能会带来意想不到的结果；因此，将其设定了一个可接受值方为明智决定。其默认为 2000。 default_backend 定义在没有匹配的 use_backend 规则时为实例指定使用的默认后端服务器，因此，其不可应用于 backend 区段。在 frontend 和 backend 之间进行内容交换时，通常使用 use-backend 定义其匹配规则；而没有被规则匹配到的请求将由此参数指定的后端服务器接收。 default_backend 使用方法如下： default_backend 使用案例： use_backend dynamic if url_dyn use_backend static if url_css url_img default_backend dynamic server 为后端声明一个 server，因此，不能用于 defaults 和 frontend 区段。 server 使用方法如下： server [:port]：指定将连接请求所发往的此服务器时的目标端口，其为可选项；未设定时，将使用客户端请求时的同一相端口。 [param*]：为此服务器设定的一系参数；其可用的参数非常多，具体请参考官方文档中的说明，下面仅说明几个常用的参数； 服务器或默认服务器参数： backup：设定为备用服务器，仅在负载均衡场景中的其它 server 均不可用于启用此 server。 check：启动对此 server 执行健康状态检查，其可以借助于额外的其它参数完成更精细的设定，如： inter rise fall cookie maxconn maxqueue observe 一个标准的使用案例，如下： server web1 192.168.5.171:8080 maxconn 1024 weight 3 check inter 2000 rise 2 fall 3 以上就是 [param*] 中比较经常使用的参数。 redir server srv1 192.168.5.174:80 redir http://imags.ilanni.com check weight 检查方法： option httpchk option httpchk option httpchk option httpchk 例如： backend https_relay mode tcp option httpchk OPTIONS * HTTP/1.1\r\nHost:\ www.ilanni.com server apache1 192.168.1.1:443 check port 80 stats enable 启用基于程序编译时默认设置的统计报告，stats enable 不能用于 frontend 区段。只要没有另外的其它设定，它们就会使用如下的配置： stats uri : /stats stats realm : “HAProxy Statistics” stats auth : no authentication stats scope : no restriction 尽管 stats enable 一条就能够启用统计报告，但还是建议设定其它所有的参数，以免其依赖于默认设定而带来非期望的后果。下面是一个配置案例。 backend public_www server websrv1 192.168.5.171:80 stats enable stats hide-version stats scope stats uri /stats stats realm Haproxy\ Statistics stats auth admin:password stats auth admin:password stats hide-version 隐藏统计报告中 haproxy 版本号，不能用于 frontend 区段。默认情况下，统计页面会显示一些有用信息，包括 haproxy 的版本号。 然而，向所有人公开 haproxy 的精确版本号是非常有风险的，因为它能帮助恶意用户快速定位版本的缺陷和漏洞。 stats realm 启用统计报告并高精认证领域，不能用于 “frontend” 区段。 stats realm haproxy 在读取 realm 时会将其视作一个单词，因此，中间的任何空白词符都必须使用反斜线进行转义。此参数仅在与 “stats auth” 配置使用时有意义。 stats scope 启用统计报告并限定报告的区段，不能用于 frontend 区段。 当指定此语句时，统计报告将仅显示其列举出区段的报告信息，所有其它区段的信息将被隐藏。如果需要显示多个区段的统计报告，此语句可以定义多次。需要注意的是，区段名称检测仅仅是以词符串比较的方式进行，它不会真检测指定的区段是否真正存在。 stats scope { stats auth 启用带认证的统计报告功能并授权一个用户帐号，其不能用于 frontend 区段。 stats auth 此语句将基于默认设定启用统计报告功能，并仅允许其定义的用户访问，其也可以定义多次以授权多个用户帐号。可以结合 “stats realm” 参数在提示用户认证时给出一个领域说明信息。在使用非法用户访问统计功能时，其将会响应一个 “401 Forbidden” 页面。其认证方式为 HTTP Basic 认证，密码传输会以明文方式进行，因此，配置文件中也使用明文方式存储以说明其非保密信息故此不能相同于其它关键性帐号的密码。 stats admin 在指定的条件满足时启用统计报告页面的管理级别功能，它允许通过 web 接口启用或禁用服务器，不过，基于安全的角度考虑，统计报告页面应该尽可能为只读的。此外，如果启用了 HAProxy 的多进程模式，启用此管理级别将有可能导致异常行为。 stats admin { if | unless } 目前来说，POST 请求方法被限制于仅能使用缓冲区减去保留部分之外的空间，因此，服务器列表不能过长，否则，此请求将无法正常工作。因此，建议一次仅调整少数几个服务器。下面是两个案例，第一个限制了仅能在本机打开报告页面时启用管理级别功能，第二个定义了仅允许通过认证的用户使用管理级别功能。 backend stats_localhost stats enable stats admin if LOCALHOST backend stats_auth stats enable stats auth admin:password stats admin if TRUE option httplog 启用记录 HTTP 请求、会话状态和计时器的功能。 option httplog [ clf ] clf：使用 CLF 格式来代替 HAProxy 默认的 HTTP 格式，通常在使用仅支持 CLF 格式的特定日志分析器时才需要使用此格式。 默认情况下，日志输入格式非常简陋，因为其仅包括源地址、目标地址和实例名称，而 “option httplog” 参数将会使得日志格式变得丰富许多，其通常包括但不限于 HTTP 请求、连接计时器、会话状态、连接数、捕获的首部及 cookie、“frontend”、“backend” 及服务器名称，当然也包括源地址和端口号等。 option logasap 启用提前将 HTTP 请求记入日志，不能用于 backend 区段。 默认情况下，HTTP 请求是在请求结束时进行记录以便能将其整体传输时长和词节数记入日志，由此，传较大的对象时，其记入日志的时长可能会略有延迟。option logasap 参数能够在服务器发送 complete 首部时即时记录日志，只不过，此时将不记录整体传输时长和词节数。此情形下，捕获 Content-Length 响应首部来记录传输的词节数是一个较好选择。下面是一个例子。 listen http_proxy 0.0.0.0:80 mode http option httplog option logasap log 172.16.100.9 local2 option forwardfor 允许在发往服务器的请求首部中插入 “X-Forwarded-For” 首部。即启用获取客户端真实 IP 功能。 option forwardfor [ except if-none：仅在此首部不存在时才将其添加至请求报文问道中。 haproxy 工作于反向代理模式，其发往服务器的请求中的客户端 IP 均为 haproxy 主机的地址而非真正客户端的地址，这会使得服务器端的日志信息记录不了真正的请求来源，“X-Forwarded-For” 首部则可用于解决此问题。haproxy 可以向每个发往服务器的请求上添加此首部，并以客户端 IP 为其 value。 需要注意的是，haproxy 工作于隧道模式，其仅检查每一个连接的第一个请求，因此，仅第一个请求报文被附加此首部。如果想为每一个请求都附加此首部，请确保同时使用了 “option httpclose”、“option forceclose” 和 “option http-server-close” 几个 option。 下面是一个例子。 frontend www mode http option forwardfor except 127.0.0.1 errorfile 在用户请求不存在的页面时，返回一个页面文件给客户端而非由 haproxy 生成的错误代码；可用于所有段中。 errorfile 例如： errorfile 400 /etc/haproxy/errorpages/400badreq.http errorfile 403 /etc/haproxy/errorpages/403forbid.http errorfile 503 /etc/haproxy/errorpages/503sorry.http errorloc errorloc302 请求错误时，返回一个 HTTP 重定向至某 URL 的信息；可用于所有配置段中。 需要留意的是，这两个关键词都会返回 302 状态吗，这将使得客户端使用同样的 HTTP 方法获取指定的 URL，对于非 GET 法的场景 (如 POST) 来说会产生问题，因为返回客户的 URL 是不允许使用 GET 以外的其它方法的。如果的确有这种问题，可以使用 errorloc303 来返回 303 状态码给客户端。 errorloc303 请求错误时，返回一个 HTTP 重定向至某 URL 的信息给客户端，可用于所有配置段中。 例如： backend webserver server 172.16.100.6 172.16.100.6:80 check maxconn 3000 cookie srv01 server 172.16.100.7 172.16.100.7:80 check maxconn 3000 cookie srv02 errorloc 403 /etc/haproxy/errorpages/sorry.htm errorloc 503 /etc/haproxy/errorpages/sorry.htm
2、关键词 bind
3、关键词 mode
4、关键词 hash-type
5、关键词 log
6、关键词 maxconn
7、关键词 default_backend
8、关键词 server
9、关键词 stats enable
10、关键词 stats hide-version
11、关键词 stats realm
12、关键词 stats scope
13、关键词 stats auth
14、关键词 stats admin
15、关键词 option httplog
16、关键词 option logasap
17、关键词 option forwardfor
18、关键词 errorfile：指定对 HTTP 的哪些状态码返回指定的页面；这里可用的状态码有 200、400、403、408、500、502、503 和 504。
19、关键词 errorloc 和 errorloc302：指定对 HTTP 的哪些状态码返回指定的页面；这里可用的状态码有 200、400、403、408、500、502、503 和 504；
20、关键词 errorloc303：指定对 HTTP 的哪些状态码返回指定的页面；这里可用的状态码有 400、403、408、500、502、503 和 504；