注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

itoedr的it学苑

记录从IT文盲学到专家的历程

 
 
 

日志

 
 

haproxy最新(2013)配置参考手册(201306)  

2013-06-22 10:35:20|  分类: 负载均衡haproxy |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
 ----------------------
                                 HAProxy
                          Configuration Manual
                         ----------------------
                             version 1.4.24
                             willy tarreau
                               2013/06/17


This document covers the configuration language as implemented in the version
specified above. It does not provide any hint, example or advice. For such
documentation, please refer to the Reference Manual or the Architecture Manual.
The summary below is meant to help you search sections by name and navigate
through the document.

Note to documentation contributors :
    This document is formated with 80 columns per line, with even number of
    spaces for indentation and without tabs. Please follow these rules strictly
    so that it remains easily printable everywhere. If a line needs to be
    printed verbatim and does not fit, please end each line with a backslash
    ('\') and continue on next line. If you add sections, please update the
    summary below for easier searching.


Summary
-------

1.    Quick reminder about HTTP
1.1.      The HTTP transaction model
1.2.      HTTP request
1.2.1.        The Request line
1.2.2.        The request headers
1.3.      HTTP response
1.3.1.        The Response line
1.3.2.        The response headers

2.    Configuring HAProxy
2.1.      Configuration file format
2.2.      Time format
2.3.      Examples

3.    Global parameters
3.1.      Process management and security
3.2.      Performance tuning
3.3.      Debugging
3.4.      Userlists

4.    Proxies
4.1.      Proxy keywords matrix
4.2.      Alphabetically sorted keywords reference

5.    Server and default-server options

6.    HTTP header manipulation

7.    Using ACLs and pattern extraction
7.1.      Matching integers
7.2.      Matching strings
7.3.      Matching regular expressions (regexes)
7.4.      Matching IPv4 addresses
7.5.      Available matching criteria
7.5.1.        Matching at Layer 4 and below
7.5.2.        Matching contents at Layer 4
7.5.3.        Matching at Layer 7
7.6.      Pre-defined ACLs
7.7.      Using ACLs to form conditions
7.8.      Pattern extraction

8.    Logging
8.1.      Log levels
8.2.      Log formats
8.2.1.        Default log format
8.2.2.        TCP log format
8.2.3.        HTTP log format
8.3.      Advanced logging options
8.3.1.        Disabling logging of external tests
8.3.2.        Logging before waiting for the session to terminate
8.3.3.        Raising log level upon errors
8.3.4.        Disabling logging of successful connections
8.4.      Timing events
8.5.      Session state at disconnection
8.6.      Non-printable characters
8.7.      Capturing HTTP cookies
8.8.      Capturing HTTP headers
8.9.      Examples of logs

9.    Statistics and monitoring
9.1.      CSV format
9.2.      Unix Socket commands


1. Quick reminder about HTTP
----------------------------

When haproxy is running in HTTP mode, both the request and the response are
fully analyzed and indexed, thus it becomes possible to build matching criteria
on almost anything found in the contents.

However, it is important to understand how HTTP requests and responses are
formed, and how HAProxy decomposes them. It will then become easier to write
correct rules and to debug existing configurations.


1.1. The HTTP transaction model
-------------------------------

The HTTP protocol is transaction-driven. This means that each request will lead
to one and only one response. Traditionally, a TCP connection is established
from the client to the server, a request is sent by the client on the
connection, the server responds and the connection is closed. A new request
will involve a new connection :

  [CON1] [REQ1] ... [RESP1] [CLO1] [CON2] [REQ2] ... [RESP2] [CLO2] ...

In this mode, called the "HTTP close" mode, there are as many connection
establishments as there are HTTP transactions. Since the connection is closed
by the server after the response, the client does not need to know the content
length.

Due to the transactional nature of the protocol, it was possible to improve it
to avoid closing a connection between two subsequent transactions. In this mode
however, it is mandatory that the server indicates the content length for each
response so that the client does not wait indefinitely. For this, a special
header is used: "Content-length". This mode is called the "keep-alive" mode :

  [CON] [REQ1] ... [RESP1] [REQ2] ... [RESP2] [CLO] ...

Its advantages are a reduced latency between transactions, and less processing
power required on the server side. It is generally better than the close mode,
but not always because the clients often limit their concurrent connections to
a smaller value.

A last improvement in the communications is the pipelining mode. It still uses
keep-alive, but the client does not wait for the first response to send the
second request. This is useful for fetching large number of images composing a
page :

  [CON] [REQ1] [REQ2] ... [RESP1] [RESP2] [CLO] ...

This can obviously have a tremendous benefit on performance because the network
latency is eliminated between subsequent requests. Many HTTP agents do not
correctly support pipelining since there is no way to associate a response with
the corresponding request in HTTP. For this reason, it is mandatory for the
server to reply in the exact same order as the requests were received.

By default HAProxy operates in a tunnel-like mode with regards to persistent
connections: for each connection it processes the first request and forwards
everything else (including additional requests) to selected server. Once
established, the connection is persisted both on the client and server
sides. Use "option http-server-close" to preserve client persistent connections
while handling every incoming request individually, dispatching them one after
another to servers, in HTTP close mode. Use "option httpclose" to switch both
sides to HTTP close mode. "option forceclose" and "option
http-pretend-keepalive" help working around servers misbehaving in HTTP close
mode.


1.2. HTTP request
-----------------

First, let's consider this HTTP request :

  Line     Contents
  number
     1     GET /serv/login.php?lang=en&profile=2 HTTP/1.1
     2     Host: www.mydomain.com
     3     User-agent: my small browser
     4     Accept: image/jpeg, image/gif
     5     Accept: image/png


1.2.1. The Request line
-----------------------

Line 1 is the "request line". It is always composed of 3 fields :

  - a METHOD      : GET
  - a URI         : /serv/login.php?lang=en&profile=2
  - a version tag : HTTP/1.1

All of them are delimited by what the standard calls LWS (linear white spaces),
which are commonly spaces, but can also be tabs or line feeds/carriage returns
followed by spaces/tabs. The method itself cannot contain any colon (':') and
is limited to alphabetic letters. All those various combinations make it
desirable that HAProxy performs the splitting itself rather than leaving it to
the user to write a complex or inaccurate regular expression.

The URI itself can have several forms :

  - A "relative URI" :

      /serv/login.php?lang=en&profile=2

    It is a complete URL without the host part. This is generally what is
    received by servers, reverse proxies and transparent proxies.

  - An "absolute URI", also called a "URL" :

      http://192.168.0.12:8080/serv/login.php?lang=en&profile=2

    It is composed of a "scheme" (the protocol name followed by '://'), a host
    name or address, optionally a colon (':') followed by a port number, then
    a relative URI beginning at the first slash ('/') after the address part.
    This is generally what proxies receive, but a server supporting HTTP/1.1
    must accept this form too.

  - a star ('*') : this form is only accepted in association with the OPTIONS
    method and is not relayable. It is used to inquiry a next hop's
    capabilities.

  - an address:port combination : 192.168.0.12:80
    This is used with the CONNECT method, which is used to establish TCP
    tunnels through HTTP proxies, generally for HTTPS, but sometimes for
    other protocols too.

In a relative URI, two sub-parts are identified. The part before the question
mark is called the "path". It is typically the relative path to static objects
on the server. The part after the question mark is called the "query string".
It is mostly used with GET requests sent to dynamic scripts and is very
specific to the language, framework or application in use.


1.2.2. The request headers
--------------------------

The headers start at the second line. They are composed of a name at the
beginning of the line, immediately followed by a colon (':'). Traditionally,
an LWS is added after the colon but that's not required. Then come the values.
Multiple identical headers may be folded into one single line, delimiting the
values with commas, provided that their order is respected. This is commonly
encountered in the "Cookie:" field. A header may span over multiple lines if
the subsequent lines begin with an LWS. In the example in 1.2, lines 4 and 5
define a total of 3 values for the "Accept:" header.

Contrary to a common mis-conception, header names are not case-sensitive, and
their values are not either if they refer to other header names (such as the
"Connection:" header).

The end of the headers is indicated by the first empty line. People often say
that it's a double line feed, which is not exact, even if a double line feed
is one valid form of empty line.

Fortunately, HAProxy takes care of all these complex combinations when indexing
headers, checking values and counting them, so there is no reason to worry
about the way they could be written, but it is important not to accuse an
application of being buggy if it does unusual, valid things.

Important note:
   As suggested by RFC2616, HAProxy normalizes headers by replacing line breaks
   in the middle of headers by LWS in order to join multi-line headers. This
   is necessary for proper analysis and helps less capable HTTP parsers to work
   correctly and not to be fooled by such complex constructs.


1.3. HTTP response
------------------

An HTTP response looks very much like an HTTP request. Both are called HTTP
messages. Let's consider this HTTP response :

  Line     Contents
  number
     1     HTTP/1.1 200 OK
     2     Content-length: 350
     3     Content-Type: text/html

As a special case, HTTP supports so called "Informational responses" as status
codes 1xx. These messages are special in that they don't convey any part of the
response, they're just used as sort of a signaling message to ask a client to
continue to post its request for instance. In the case of a status 100 response
the requested information will be carried by the next non-100 response message
following the informational one. This implies that multiple responses may be
sent to a single request, and that this only works when keep-alive is enabled
(1xx messages are HTTP/1.1 only). HAProxy handles these messages and is able to
correctly forward and skip them, and only process the next non-100 response. As
such, these messages are neither logged nor transformed, unless explicitly
state otherwise. Status 101 messages indicate that the protocol is changing
over the same connection and that haproxy must switch to tunnel mode, just as
if a CONNECT had occurred. Then the Upgrade header would contain additional
information about the type of protocol the connection is switching to.


1.3.1. The Response line
------------------------

Line 1 is the "response line". It is always composed of 3 fields :

  - a version tag : HTTP/1.1
  - a status code : 200
  - a reason      : OK

The status code is always 3-digit. The first digit indicates a general status :
 - 1xx = informational message to be skipped (eg: 100, 101)
 - 2xx = OK, content is following   (eg: 200, 206)
 - 3xx = OK, no content following   (eg: 302, 304)
 - 4xx = error caused by the client (eg: 401, 403, 404)
 - 5xx = error caused by the server (eg: 500, 502, 503)

Please refer to RFC2616 for the detailed meaning of all such codes. The
"reason" field is just a hint, but is not parsed by clients. Anything can be
found there, but it's a common practice to respect the well-established
messages. It can be composed of one or multiple words, such as "OK", "Found",
or "Authentication Required".

Haproxy may emit the following status codes by itself :

  Code  When / reason
   200  access to stats page, and when replying to monitoring requests
   301  when performing a redirection, depending on the configured code
   302  when performing a redirection, depending on the configured code
   303  when performing a redirection, depending on the configured code
   307  when performing a redirection, depending on the configured code
   308  when performing a redirection, depending on the configured code
   400  for an invalid or too large request
   401  when an authentication is required to perform the action (when
        accessing the stats page)
   403  when a request is forbidden by a "block" ACL or "reqdeny" filter
   408  when the request timeout strikes before the request is complete
   500  when haproxy encounters an unrecoverable internal error, such as a
        memory allocation failure, which should never happen
   502  when the server returns an empty, invalid or incomplete response, or
        when an "rspdeny" filter blocks the response.
   503  when no server was available to handle the request, or in response to
        monitoring requests which match the "monitor fail" condition
   504  when the response timeout strikes before the server responds

The error 4xx and 5xx codes above may be customized (see "errorloc" in section
4.2).


1.3.2. The response headers
---------------------------

Response headers work exactly like request headers, and as such, HAProxy uses
the same parsing function for both. Please refer to paragraph 1.2.2 for more
details.


2. Configuring HAProxy
----------------------

2.1. Configuration file format
------------------------------

HAProxy's configuration process involves 3 major sources of parameters :

  - the arguments from the command-line, which always take precedence
  - the "global" section, which sets process-wide parameters
  - the proxies sections which can take form of "defaults", "listen",
    "frontend" and "backend".

The configuration file syntax consists in lines beginning with a keyword
referenced in this manual, optionally followed by one or several parameters
delimited by spaces. If spaces have to be entered in strings, then they must be
preceded by a backslash ('\') to be escaped. Backslashes also have to be
escaped by doubling them.


2.2. Time format
----------------

Some parameters involve values representing time, such as timeouts. These
values are generally expressed in milliseconds (unless explicitly stated
otherwise) but may be expressed in any other unit by suffixing the unit to the
numeric value. It is important to consider this because it will not be repeated
for every keyword. Supported units are :

  - us : microseconds. 1 microsecond = 1/1000000 second
  - ms : milliseconds. 1 millisecond = 1/1000 second. This is the default.
  - s  : seconds. 1s = 1000ms
  - m  : minutes. 1m = 60s = 60000ms
  - h  : hours.   1h = 60m = 3600s = 3600000ms
  - d  : days.    1d = 24h = 1440m = 86400s = 86400000ms


2.3. Examples
-------------

    # Simple configuration for an HTTP proxy listening on port 80 on all
    # interfaces and forwarding requests to a single backend "servers" with a
    # single server "server1" listening on 127.0.0.1:8000
    global
        daemon
        maxconn 256

    defaults
        mode http
        timeout connect 5000ms
        timeout client 50000ms
        timeout server 50000ms

    frontend http-in
        bind *:80
        default_backend servers

    backend servers
        server server1 127.0.0.1:8000 maxconn 32


    # The same configuration defined with a single listen block. Shorter but
    # less expressive, especially in HTTP mode.
    global
        daemon
        maxconn 256

    defaults
        mode http
        timeout connect 5000ms
        timeout client 50000ms
        timeout server 50000ms

    listen http-in
        bind *:80
        server server1 127.0.0.1:8000 maxconn 32


Assuming haproxy is in $PATH, test these configurations in a shell with:

    $ sudo haproxy -f configuration.conf -c


3. Global parameters
--------------------

Parameters in the "global" section are process-wide and often OS-specific. They
are generally set once for all and do not need being changed once correct. Some
of them have command-line equivalents.

The following keywords are supported in the "global" section :

 * Process management and security
   - chroot
   - daemon
   - gid
   - group
   - log
   - log-send-hostname
   - nbproc
   - pidfile
   - uid
   - ulimit-n
   - user
   - stats
   - node
   - description

 * Performance tuning
   - maxconn
   - maxpipes
   - noepoll
   - nokqueue
   - nopoll
   - nosepoll
   - nosplice
   - spread-checks
   - tune.bufsize
   - tune.chksize
   - tune.maxaccept
   - tune.maxpollevents
   - tune.maxrewrite
   - tune.rcvbuf.client
   - tune.rcvbuf.server
   - tune.sndbuf.client
   - tune.sndbuf.server

 * Debugging
   - debug
   - quiet


3.1. Process management and security
------------------------------------

chroot <jail dir>
  Changes current directory to <jail dir> and performs a chroot() there before
  dropping privileges. This increases the security level in case an unknown
  vulnerability would be exploited, since it would make it very hard for the
  attacker to exploit the system. This only works when the process is started
  with superuser privileges. It is important to ensure that <jail_dir> is both
  empty and unwritable to anyone.

daemon
  Makes the process fork into background. This is the recommended mode of
  operation. It is equivalent to the command line "-D" argument. It can be
  disabled by the command line "-db" argument.

gid <number>
  Changes the process' group ID to <number>. It is recommended that the group
  ID is dedicated to HAProxy or to a small set of similar daemons. HAProxy must
  be started with a user belonging to this group, or with superuser privileges.
  Note that if haproxy is started from a user having supplementary groups, it
  will only be able to drop these groups if started with superuser privileges.
  See also "group" and "uid".

group <group name>
  Similar to "gid" but uses the GID of group name <group name> from /etc/group.
  See also "gid" and "user".

log <address> <facility> [max level [min level]]
  Adds a global syslog server. Up to two global servers can be defined. They
  will receive logs for startups and exits, as well as all logs from proxies
  configured with "log global".

  <address> can be one of:

        - An IPv4 address optionally followed by a colon and a UDP port. If
          no port is specified, 514 is used by default (the standard syslog
          port).

        - A filesystem path to a UNIX domain socket, keeping in mind
          considerations for chroot (be sure the path is accessible inside
          the chroot) and uid/gid (be sure the path is appropriately
          writeable).

  <facility> must be one of the 24 standard syslog facilities :

          kern   user   mail   daemon auth   syslog lpr    news
          uucp   cron   auth2  ftp    ntp    audit  alert  cron2
          local0 local1 local2 local3 local4 local5 local6 local7

  An optional level can be specified to filter outgoing messages. By default,
  all messages are sent. If a maximum level is specified, only messages with a
  severity at least as important as this level will be sent. An optional minimum
  level can be specified. If it is set, logs emitted with a more severe level
  than this one will be capped to this level. This is used to avoid sending
  "emerg" messages on all terminals on some default syslog configurations.
  Eight levels are known :

          emerg  alert  crit   err    warning notice info  debug

log-send-hostname [<string>]
  Sets the hostname field in the syslog header. If optional "string" parameter
  is set the header is set to the string contents, otherwise uses the hostname
  of the system. Generally used if one is not relaying logs through an
  intermediate syslog server or for simply customizing the hostname printed in
  the logs.

log-tag <string>
  Sets the tag field in the syslog header to this string. It defaults to the
  program name as launched from the command line, which usually is "haproxy".
  Sometimes it can be useful to differentiate between multiple processes
  running on the same host.

nbproc <number>
  Creates <number> processes when going daemon. This requires the "daemon"
  mode. By default, only one process is created, which is the recommended mode
  of operation. For systems limited to small sets of file descriptors per
  process, it may be needed to fork multiple daemons. USING MULTIPLE PROCESSES
  IS HARDER TO DEBUG AND IS REALLY DISCOURAGED. See also "daemon".

pidfile <pidfile>
  Writes pids of all daemons into file <pidfile>. This option is equivalent to
  the "-p" command line argument. The file must be accessible to the user
  starting the process. See also "daemon".

stats socket <path> [{uid | user} <uid>] [{gid | group} <gid>] [mode <mode>]
             [level <level>]

  Creates a UNIX socket in stream mode at location <path>. Any previously
  existing socket will be backed up then replaced. Connections to this socket
  will return various statistics outputs and even allow some commands to be
  issued. Please consult section 9.2 "Unix Socket commands" for more details.

  An optional "level" parameter can be specified to restrict the nature of
  the commands that can be issued on the socket :
    - "user" is the least privileged level ; only non-sensitive stats can be
      read, and no change is allowed. It would make sense on systems where it
      is not easy to restrict access to the socket.

    - "operator" is the default level and fits most common uses. All data can
      be read, and only non-sensitive changes are permitted (eg: clear max
      counters).

    - "admin" should be used with care, as everything is permitted (eg: clear
      all counters).

  On platforms which support it, it is possible to restrict access to this
  socket by specifying numerical IDs after "uid" and "gid", or valid user and
  group names after the "user" and "group" keywords. It is also possible to
  restrict permissions on the socket by passing an octal value after the "mode"
  keyword (same syntax as chmod). Depending on the platform, the permissions on
  the socket will be inherited from the directory which hosts it, or from the
  user the process is started with.

stats timeout <timeout, in milliseconds>
  The default timeout on the stats socket is set to 10 seconds. It is possible
  to change this value with "stats timeout". The value must be passed in
  milliseconds, or be suffixed by a time unit among { us, ms, s, m, h, d }.

stats maxconn <connections>
  By default, the stats socket is limited to 10 concurrent connections. It is
  possible to change this value with "stats maxconn".

uid <number>
  Changes the process' user ID to <number>. It is recommended that the user ID
  is dedicated to HAProxy or to a small set of similar daemons. HAProxy must
  be started with superuser privileges in order to be able to switch to another
  one. See also "gid" and "user".

ulimit-n <number>
  Sets the maximum number of per-process file-descriptors to <number>. By
  default, it is automatically computed, so it is recommended not to use this
  option.

user <user name>
  Similar to "uid" but uses the UID of user name <user name> from /etc/passwd.
  See also "uid" and "group".

node <name>
  Only letters, digits, hyphen and underscore are allowed, like in DNS names.

  This statement is useful in HA configurations where two or more processes or
  servers share the same IP address. By setting a different node-name on all
  nodes, it becomes easy to immediately spot what server is handling the
  traffic.

description <text>
  Add a text that describes the instance.

  Please note that it is required to escape certain characters (# for example)
  and this text is inserted into a html page so you should avoid using
  "<" and ">" characters.


3.2. Performance tuning
-----------------------

maxconn <number>
  Sets the maximum per-process number of concurrent connections to <number>. It
  is equivalent to the command-line argument "-n". Proxies will stop accepting
  connections when this limit is reached. The "ulimit-n" parameter is
  automatically adjusted according to this value. See also "ulimit-n".

maxpipes <number>
  Sets the maximum per-process number of pipes to <number>. Currently, pipes
  are only used by kernel-based tcp splicing. Since a pipe contains two file
  descriptors, the "ulimit-n" value will be increased accordingly. The default
  value is maxconn/4, which seems to be more than enough for most heavy usages.
  The splice code dynamically allocates and releases pipes, and can fall back
  to standard copy, so setting this value too low may only impact performance.

noepoll
  Disables the use of the "epoll" event polling system on Linux. It is
  equivalent to the command-line argument "-de". The next polling system
  used will generally be "poll". See also "nosepoll", and "nopoll".

nokqueue
  Disables the use of the "kqueue" event polling system on BSD. It is
  equivalent to the command-line argument "-dk". The next polling system
  used will generally be "poll". See also "nopoll".

nopoll
  Disables the use of the "poll" event polling system. It is equivalent to the
  command-line argument "-dp". The next polling system used will be "select".
  It should never be needed to disable "poll" since it's available on all
  platforms supported by HAProxy. See also "nosepoll", and "nopoll" and
  "nokqueue".

nosepoll
  Disables the use of the "speculative epoll" event polling system on Linux. It
  is equivalent to the command-line argument "-ds". The next polling system
  used will generally be "epoll". See also "nosepoll", and "nopoll".

nosplice
  Disables the use of kernel tcp splicing between sockets on Linux. It is
  equivalent to the command line argument "-dS".  Data will then be copied
  using conventional and more portable recv/send calls. Kernel tcp splicing is
  limited to some very recent instances of kernel 2.6. Most versions between
  2.6.25 and 2.6.28 are buggy and will forward corrupted data, so they must not
  be used. This option makes it easier to globally disable kernel splicing in
  case of doubt. See also "option splice-auto", "option splice-request" and
  "option splice-response".

spread-checks <0..50, in percent>
  Sometimes it is desirable to avoid sending health checks to servers at exact
  intervals, for instance when many logical servers are located on the same
  physical server. With the help of this parameter, it becomes possible to add
  some randomness in the check interval between 0 and +/- 50%. A value between
  2 and 5 seems to show good results. The default value remains at 0.

tune.bufsize <number>
  Sets the buffer size to this size (in bytes). Lower values allow more
  sessions to coexist in the same amount of RAM, and higher values allow some
  applications with very large cookies to work. The default value is 16384 and
  can be changed at build time. It is strongly recommended not to change this
  from the default value, as very low values will break some services such as
  statistics, and values larger than default size will increase memory usage,
  possibly causing the system to run out of memory. At least the global maxconn
  parameter should be decreased by the same factor as this one is increased.

tune.chksize <number>
  Sets the check buffer size to this size (in bytes). Higher values may help
  find string or regex patterns in very large pages, though doing so may imply
  more memory and CPU usage. The default value is 16384 and can be changed at
  build time. It is not recommended to change this value, but to use better
  checks whenever possible.

tune.maxaccept <number>
  Sets the maximum number of consecutive accepts that a process may perform on
  a single wake up. High values give higher priority to high connection rates,
  while lower values give higher priority to already established connections.
  This value is limited to 100 by default in single process mode. However, in
  multi-process mode (nbproc > 1), it defaults to 8 so that when one process
  wakes up, it does not take all incoming connections for itself and leaves a
  part of them to other processes. Setting this value to -1 completely disables
  the limitation. It should normally not be needed to tweak this value.

tune.maxpollevents <number>
  Sets the maximum amount of events that can be processed at once in a call to
  the polling system. The default value is adapted to the operating system. It
  has been noticed that reducing it below 200 tends to slightly decrease
  latency at the expense of network bandwidth, and increasing it above 200
  tends to trade latency for slightly increased bandwidth.

tune.maxrewrite <number>
  Sets the reserved buffer space to this size in bytes. The reserved space is
  used for header rewriting or appending. The first reads on sockets will never
  fill more than bufsize-maxrewrite. Historically it has defaulted to half of
  bufsize, though that does not make much sense since there are rarely large
  numbers of headers to add. Setting it too high prevents processing of large
  requests or responses. Setting it too low prevents addition of new headers
  to already large requests or to POST requests. It is generally wise to set it
  to about 1024. It is automatically readjusted to half of bufsize if it is
  larger than that. This means you don't have to worry about it when changing
  bufsize.

tune.rcvbuf.client <number>
tune.rcvbuf.server <number>
  Forces the kernel socket receive buffer size on the client or the server side
  to the specified value in bytes. This value applies to all TCP/HTTP frontends
  and backends. It should normally never be set, and the default size (0) lets
  the kernel autotune this value depending on the amount of available memory.
  However it can sometimes help to set it to very low values (eg: 4096) in
  order to save kernel memory by preventing it from buffering too large amounts
  of received data. Lower values will significantly increase CPU usage though.

tune.sndbuf.client <number>
tune.sndbuf.server <number>
  Forces the kernel socket send buffer size on the client or the server side to
  the specified value in bytes. This value applies to all TCP/HTTP frontends
  and backends. It should normally never be set, and the default size (0) lets
  the kernel autotune this value depending on the amount of available memory.
  However it can sometimes help to set it to very low values (eg: 4096) in
  order to save kernel memory by preventing it from buffering too large amounts
  of received data. Lower values will significantly increase CPU usage though.
  Another use case is to prevent write timeouts with extremely slow clients due
  to the kernel waiting for a large part of the buffer to be read before
  notifying haproxy again.


3.3. Debugging
--------------

debug
  Enables debug mode which dumps to stdout all exchanges, and disables forking
  into background. It is the equivalent of the command-line argument "-d". It
  should never be used in a production configuration since it may prevent full
  system startup.

quiet
  Do not display any message during startup. It is equivalent to the command-
  line argument "-q".

3.4. Userlists
--------------
It is possible to control access to frontend/backend/listen sections or to
http stats by allowing only authenticated and authorized users. To do this,
it is required to create at least one userlist and to define users.

userlist <listname>
  Creates new userlist with name <listname>. Many independent userlists can be
  used to store authentication & authorization data for independent customers.

group <groupname> [users <user>,<user>,(...)]
  Adds group <groupname> to the current userlist. It is also possible to
  attach users to this group by using a comma separated list of names
  proceeded by "users" keyword.

user <username> [password|insecure-password <password>]
                [groups <group>,<group>,(...)]
  Adds user <username> to the current userlist. Both secure (encrypted) and
  insecure (unencrypted) passwords can be used. Encrypted passwords are
  evaluated using the crypt(3) function so depending of the system's
  capabilities, different algorithms are supported. For example modern Glibc
  based Linux system supports MD5, SHA-256, SHA-512 and of course classic,
  DES-based method of crypting passwords.


  Example:
        userlist L1
          group G1 users tiger,scott
          group G2 users xdb,scott

          user tiger password $6$k6y3o.eP$JlKBx9za9667qe4(...)xHSwRv6J.C0/D7cV91
          user scott insecure-password elgato
          user xdb insecure-password hello

        userlist L2
          group G1
          group G2

          user tiger password $6$k6y3o.eP$JlKBx(...)xHSwRv6J.C0/D7cV91 groups G1
          user scott insecure-password elgato groups G1,G2
          user xdb insecure-password hello groups G2

  Please note that both lists are functionally identical.

4. Proxies
----------

Proxy configuration can be located in a set of sections :
 - defaults <name>
 - frontend <name>
 - backend  <name>
 - listen   <name>

A "defaults" section sets default parameters for all other sections following
its declaration. Those default parameters are reset by the next "defaults"
section. See below for the list of parameters which can be set in a "defaults"
section. The name is optional but its use is encouraged for better readability.

A "frontend" section describes a set of listening sockets accepting client
connections.

A "backend" section describes a set of servers to which the proxy will connect
to forward incoming connections.

A "listen" section defines a complete proxy with its frontend and backend
parts combined in one section. It is generally useful for TCP-only traffic.

All proxy names must be formed from upper and lower case letters, digits,
'-' (dash), '_' (underscore) , '.' (dot) and ':' (colon). ACL names are
case-sensitive, which means that "www" and "WWW" are two different proxies.

Historically, all proxy names could overlap, it just caused troubles in the
logs. Since the introduction of content switching, it is mandatory that two
proxies with overlapping capabilities (frontend/backend) have different names.
However, it is still permitted that a frontend and a backend share the same
name, as this configuration seems to be commonly encountered.

Right now, two major proxy modes are supported : "tcp", also known as layer 4,
and "http", also known as layer 7. In layer 4 mode, HAProxy simply forwards
bidirectional traffic between two sides. In layer 7 mode, HAProxy analyzes the
protocol, and can interact with it by allowing, blocking, switching, adding,
modifying, or removing arbitrary contents in requests or responses, based on
arbitrary criteria.


4.1. Proxy keywords matrix
--------------------------

The following list of keywords is supported. Most of them may only be used in a
limited set of section types. Some of them are marked as "deprecated" because
they are inherited from an old syntax which may be confusing or functionally
limited, and there are new recommended keywords to replace them. Keywords
marked with "(*)" can be optionally inverted using the "no" prefix, eg. "no
option contstats". This makes sense when the option has been enabled by default
and must be disabled for a specific instance. Such options may also be prefixed
with "default" in order to restore default settings regardless of what has been
specified in a previous "defaults" section.


 keyword                              defaults   frontend   listen    backend
------------------------------------+----------+----------+---------+---------
acl                                       -          X         X         X
appsession                                -          -         X         X
backlog                                   X          X         X         -
balance                                   X          -         X         X
bind                                      -          X         X         -
bind-process                              X          X         X         X
block                                     -          X         X         X
capture cookie                            -          X         X         -
capture request header                    -          X         X         -
capture response header                   -          X         X         -
clitimeout                  (deprecated)  X          X         X         -
contimeout                  (deprecated)  X          -         X         X
cookie                                    X          -         X         X
default-server                            X          -         X         X
default_backend                           X          X         X         -
description                               -          X         X         X
disabled                                  X          X         X         X
dispatch                                  -          -         X         X
enabled                                   X          X         X         X
errorfile                                 X          X         X         X
errorloc                                  X          X         X         X
errorloc302                               X          X         X         X
-- keyword -------------------------- defaults - frontend - listen -- backend -
errorloc303                               X          X         X         X
force-persist                             -          X         X         X
fullconn                                  X          -         X         X
grace                                     X          X         X         X
hash-type                                 X          -         X         X
http-check disable-on-404                 X          -         X         X
http-check expect                         -          -         X         X
http-check send-state                     X          -         X         X
http-request                              -          X         X         X
id                                        -          X         X         X
ignore-persist                            -          X         X         X
log                                       X          X         X         X
maxconn                                   X          X         X         -
mode                                      X          X         X         X
monitor fail                              -          X         X         -
monitor-net                               X          X         X         -
monitor-uri                               X          X         X         -
option abortonclose                  (*)  X          -         X         X
option accept-invalid-http-request   (*)  X          X         X         -
option accept-invalid-http-response  (*)  X          -         X         X
option allbackups                    (*)  X          -         X         X
option checkcache                    (*)  X          -         X         X
option clitcpka                      (*)  X          X         X         -
option contstats                     (*)  X          X         X         -
option dontlog-normal                (*)  X          X         X         -
option dontlognull                   (*)  X          X         X         -
option forceclose                    (*)  X          X         X         X
-- keyword -------------------------- defaults - frontend - listen -- backend -
option forwardfor                         X          X         X         X
option http-no-delay                 (*)  X          X         X         X
option http-pretend-keepalive        (*)  X          X         X         X
option http-server-close             (*)  X          X         X         X
option http-use-proxy-header         (*)  X          X         X         -
option httpchk                            X          -         X         X
option httpclose                     (*)  X          X         X         X
option httplog                            X          X         X         X
option http_proxy                    (*)  X          X         X         X
option independant-streams           (*)  X          X         X         X
option ldap-check                         X          -         X         X
option log-health-checks             (*)  X          -         X         X
option log-separate-errors           (*)  X          X         X         -
option logasap                       (*)  X          X         X         -
option mysql-check                        X          -         X         X
option nolinger                      (*)  X          X         X         X
option originalto                         X          X         X         X
option persist                       (*)  X          -         X         X
option redispatch                    (*)  X          -         X         X
option smtpchk                            X          -         X         X
option socket-stats                  (*)  X          X         X         -
option splice-auto                   (*)  X          X         X         X
option splice-request                (*)  X          X         X         X
option splice-response               (*)  X          X         X         X
option srvtcpka                      (*)  X          -         X         X
option ssl-hello-chk                      X          -         X         X
-- keyword -------------------------- defaults - frontend - listen -- backend -
option tcp-smart-accept              (*)  X          X         X         -
option tcp-smart-connect             (*)  X          -         X         X
option tcpka                              X          X         X         X
option tcplog                             X          X         X         X
option transparent                   (*)  X          -         X         X
persist rdp-cookie                        X          -         X         X
rate-limit sessions                       X          X         X         -
redirect                                  -          X         X         X
redisp                      (deprecated)  X          -         X         X
redispatch                  (deprecated)  X          -         X         X
reqadd                                    -          X         X         X
reqallow                                  -          X         X         X
reqdel                                    -          X         X         X
reqdeny                                   -          X         X         X
reqiallow                                 -          X         X         X
reqidel                                   -          X         X         X
reqideny                                  -          X         X         X
reqipass                                  -          X         X         X
reqirep                                   -          X         X         X
reqisetbe                                 -          X         X         X
reqitarpit                                -          X         X         X
reqpass                                   -          X         X         X
reqrep                                    -          X         X         X
-- keyword -------------------------- defaults - frontend - listen -- backend -
reqsetbe                                  -          X         X         X
reqtarpit                                 -          X         X         X
retries                                   X          -         X         X
rspadd                                    -          X         X         X
rspdel                                    -          X         X         X
rspdeny                                   -          X         X         X
rspidel                                   -          X         X         X
rspideny                                  -          X         X         X
rspirep                                   -          X         X         X
rsprep                                    -          X         X         X
server                                    -          -         X         X
source                                    X          -         X         X
srvtimeout                  (deprecated)  X          -         X         X
stats admin                               -          -         X         X
stats auth                                X          -         X         X
stats enable                              X          -         X         X
stats hide-version                        X          -         X         X
stats http-request                        -          -         X         X
stats realm                               X          -         X         X
stats refresh                             X          -         X         X
stats scope                               X          -         X         X
stats show-desc                           X          -         X         X
stats show-legends                        X          -         X         X
stats show-node                           X          -         X         X
stats uri                                 X          -         X         X
-- keyword -------------------------- defaults - frontend - listen -- backend -
stick match                               -          -         X         X
stick on                                  -          -         X         X
stick store-request                       -          -         X         X
stick-table                               -          -         X         X
tcp-request content accept                -          X         X         -
tcp-request content reject                -          X         X         -
tcp-request inspect-delay                 -          X         X         -
timeout check                             X          -         X         X
timeout client                            X          X         X         -
timeout clitimeout          (deprecated)  X          X         X         -
timeout connect                           X          -         X         X
timeout contimeout          (deprecated)  X          -         X         X
timeout http-keep-alive                   X          X         X         X
timeout http-request                      X          X         X         X
timeout queue                             X          -         X         X
timeout server                            X          -         X         X
timeout srvtimeout          (deprecated)  X          -         X         X
timeout tarpit                            X          X         X         X
transparent                 (deprecated)  X          -         X         X
use_backend                               -          X         X         -
------------------------------------+----------+----------+---------+---------
 keyword                              defaults   frontend   listen    backend


4.2. Alphabetically sorted keywords reference
---------------------------------------------

This section provides a description of each keyword and its usage.


acl <aclname> <criterion> [flags] [operator] <value> ...
  Declare or complete an access list.
  May be used in sections :   defaults | frontend | listen | backend
                                 no    |    yes   |   yes  |   yes
  Example:
        acl invalid_src  src          0.0.0.0/7 224.0.0.0/3
        acl invalid_src  src_port     0:1023
        acl local_dst    hdr(host) -i localhost

  See section 7 about ACL usage.


appsession <cookie> len <length> timeout <holdtime>
           [request-learn] [prefix] [mode <path-parameters|query-string>]
  Define session stickiness on an existing application cookie.
  May be used in sections :   defaults | frontend | listen | backend
                                 no    |    no    |   yes  |   yes
  Arguments :
    <cookie>   this is the name of the cookie used by the application and which
               HAProxy will have to learn for each new session.

    <length>   this is the max number of characters that will be memorized and
               checked in each cookie value.

    <holdtime> this is the time after which the cookie will be removed from
               memory if unused. If no unit is specified, this time is in
               milliseconds.

    request-learn
               If this option is specified, then haproxy will be able to learn
               the cookie found in the request in case the server does not
               specify any in response. This is typically what happens with
               PHPSESSID cookies, or when haproxy's session expires before
               the application's session and the correct server is selected.
               It is recommended to specify this option to improve reliability.

    prefix     When this option is specified, haproxy will match on the cookie
               prefix (or URL parameter prefix). The appsession value is the
               data following this prefix.

               Example :
               appsession ASPSESSIONID len 64 timeout 3h prefix

               This will match the cookie ASPSESSIONIDXXXX=XXXXX,
               the appsession value will be XXXX=XXXXX.

    mode       This option allows to change the URL parser mode.
               2 modes are currently supported :
               - path-parameters :
                 The parser looks for the appsession in the path parameters
                 part (each parameter is separated by a semi-colon), which is
                 convenient for JSESSIONID for example.
                 This is the default mode if the option is not set.
               - query-string :
                 In this mode, the parser will look for the appsession in the
                 query string.

  When an application cookie is defined in a backend, HAProxy will check when
  the server sets such a cookie, and will store its value in a table, and
  associate it with the server's identifier. Up to <length> characters from
  the value will be retained. On each connection, haproxy will look for this
  cookie both in the "Cookie:" headers, and as a URL parameter (depending on
  the mode used). If a known value is found, the client will be directed to the
  server associated with this value. Otherwise, the load balancing algorithm is
  applied. Cookies are automatically removed from memory when they have been
  unused for a duration longer than <holdtime>.

  The definition of an application cookie is limited to one per backend.

  Note : Consider not using this feature in multi-process mode (nbproc > 1)
         unless you know what you do : memory is not shared between the
         processes, which can result in random behaviours.

  Example :
        appsession JSESSIONID len 52 timeout 3h

  See also : "cookie", "capture cookie", "balance", "stick", "stick-table",
             "ignore-persist", "nbproc" and "bind-process".


backlog <conns>
  Give hints to the system about the approximate listen backlog desired size
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   no
  Arguments :
    <conns>   is the number of pending connections. Depending on the operating
              system, it may represent the number of already acknowledged
              connections, of non-acknowledged ones, or both.

  In order to protect against SYN flood attacks, one solution is to increase
  the system's SYN backlog size. Depending on the system, sometimes it is just
  tunable via a system parameter, sometimes it is not adjustable at all, and
  sometimes the system relies on hints given by the application at the time of
  the listen() syscall. By default, HAProxy passes the frontend's maxconn value
  to the listen() syscall. On systems which can make use of this value, it can
  sometimes be useful to be able to specify a different value, hence this
  backlog parameter.

  On Linux 2.4, the parameter is ignored by the system. On Linux 2.6, it is
  used as a hint and the system accepts up to the smallest greater power of
  two, and never more than some limits (usually 32768).

  See also : "maxconn" and the target operating system's tuning guide.


balance <algorithm> [ <arguments> ]
balance url_param <param> [check_post [<max_wait>]]
  Define the load balancing algorithm to be used in a backend.
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments :
    <algorithm> is the algorithm used to select a server when doing load
                balancing. This only applies when no persistence information
                is available, or when a connection is redispatched to another
                server. <algorithm> may be one of the following :

      roundrobin  Each server is used in turns, according to their weights.
                  This is the smoothest and fairest algorithm when the server's
                  processing time remains equally distributed. This algorithm
                  is dynamic, which means that server weights may be adjusted
                  on the fly for slow starts for instance. It is limited by
                  design to 4128 active servers per backend. Note that in some
                  large farms, when a server becomes up after having been down
                  for a very short time, it may sometimes take a few hundreds
                  requests for it to be re-integrated into the farm and start
                  receiving traffic. This is normal, though very rare. It is
                  indicated here in case you would have the chance to observe
                  it, so that you don't worry.

      static-rr   Each server is used in turns, according to their weights.
                  This algorithm is as similar to roundrobin except that it is
                  static, which means that changing a server's weight on the
                  fly will have no effect. On the other hand, it has no design
                  limitation on the number of servers, and when a server goes
                  up, it is always immediately reintroduced into the farm, once
                  the full map is recomputed. It also uses slightly less CPU to
                  run (around -1%).



阅读全文>>>
  评论这张
 
阅读(913)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017