HAProxy balance

server-side/haproxy

HAProxy balance

C/H 2017. 7. 4. 11:27

https://www.haproxy.org/download/1.7/doc/configuration.txt

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 :
<algorithm>은 로드를 수행 할 때 서버를 선택하는 데 사용되는 알고리즘.
지속성 정보를 사용할 수 없거나 연결이 다른 서버에 다시 전달되는 경우에만 적용.
<algorithm>은 다음 중 하나 일 수 있다.

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 4095 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.
각 서버는 가중치에 따라 순서대로 사용된다.
이것은 서버의 처리 시간이 균등하게 분산되어있을 때 가장 부드럽고 가장 공정한 알고리즘이다.
이 알고리즘은 동적이다. 즉, 에로 느린 시작을 위해 서버 가중치를 즉시 조정할 수 있습니다.
백엔드 당 4095 개의 활성 서버로 디자인에 의해 제한된다.
일부 대형 팜에서는 매우 짧은 시간 동안 서버가 다운 된 후 서버가 가동되는 경우 팜이 서버에 다시 통합되어 트래픽 수신을 시작해야하는 경우가 종종 있다.
매우 드물지만 이것은 정상입니다.
관찰 할 기회가 있기 때문에 여기에 표시되어 있으므로 걱정할 필요가 없습니다.

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%).
각 서버는 가중치에 따라 순서대로 사용된다.
이 알고리즘은 정적이라는 점을 제외하고는 roundrobin과 유사하다. 즉, 서버의 가중치를 변경하면 효과가 없다.
반면에 서버 수에 대한 설계 제한이 없으며 서버가 가동되면 전체 맵을 다시 계산하면 항상 팜에 즉시 다시 도입됩니다.
또한 CPU 사용량도 약간 적습니다 (약 -1 %).

leastconn The server with the lowest number of connections receives the
connection. Round-robin is performed within groups of servers
of the same load to ensure that all servers will be used. Use
of this algorithm is recommended where very long sessions are
expected, such as LDAP, SQL, TSE, etc... but is not very well
suited for protocols using short sessions such as HTTP. This
algorithm is dynamic, which means that server weights may be
adjusted on the fly for slow starts for instance.
연결 수가 가장 적은 서버가 연결을 수신합니다.
라운드 로빈은 모든 서버가 사용되도록 동일한로드의 서버 그룹 내에서 수행됩니다.
LDAP, SQL, TSE 등과 같이 매우 긴 세션이 예상되는 곳에서는이 알고리즘을 사용하는 것이 좋지만 HTTP와 같은 짧은 세션을 사용하는 프로토콜에는 적합하지 않습니다.
이 알고리즘은 동적입니다. 즉, 예를 들어 느린 시작을 위해 서버 가중치를 즉시 조정할 수 있습니다.

first The first server with available connection slots receives the
connection. The servers are chosen from the lowest numeric
identifier to the highest (see server parameter "id"), which
defaults to the server's position in the farm. Once a server
reaches its maxconn value, the next server is used. It does
not make sense to use this algorithm without setting maxconn.
The purpose of this algorithm is to always use the smallest
number of servers so that extra servers can be powered off
during non-intensive hours. This algorithm ignores the server
weight, and brings more benefit to long session such as RDP
or IMAP than HTTP, though it can be useful there too. In
order to use this algorithm efficiently, it is recommended
that a cloud controller regularly checks server usage to turn
them off when unused, and regularly checks backend queue to
turn new servers on when the queue inflates. Alternatively,
using "http-check send-state" may inform servers on the load.
사용 가능한 연결 슬롯이있는 첫번째 서버에 연결을 수신합니다.
서버는 가장 낮은 숫자 식별자에서 가장 높은 값으로 선택됩니다 (서버 매개 변수 "id"참조). 기본값은 팜의 서버 위치입니다.
서버가 maxconn 값에 도달하면 다음 서버가 사용됩니다.
maxconn을 설정하지 않고이 알고리즘을 사용하는 것은 이치에 맞지 않습니다.
이 알고리즘의 목적은 항상 가장 적은 수의 서버를 사용하여 비 집중식 시간 동안 추가 서버의 전원을 끌 수있게하는 것입니다.
이 알고리즘은 서버 가중치를 무시하고 HTTP보다 RDP 또는 IMAP와 같은 긴 세션에 더 많은 이점을 제공하지만 유용 할 수도 있습니다.
이 알고리즘을 효율적으로 사용하려면 클라우드 컨트롤러가 서버 사용을 정기적으로 검사하여 사용하지 않을 때 서버의 사용을 중지하고 백엔드 대기열을 정기적으로 확인하여 대기열이 부풀려 질 때 새 서버를 켜도록하는 것이 좋습니다.
또는 "http-check send-state"를 사용하여 부하가 발생한 서버에 알릴 수 있습니다

source The source IP address is hashed and divided by the total
weight of the running servers to designate which server will
receive the request. This ensures that the same client IP
address will always reach the same server as long as no
server goes down or up. If the hash result changes due to the
number of running servers changing, many clients will be
directed to a different server. This algorithm is generally
used in TCP mode where no cookie may be inserted. It may also
be used on the Internet to provide a best-effort stickiness
to clients which refuse session cookies. This algorithm is
static by default, which means that changing a server's
weight on the fly will have no effect, but this can be
changed using "hash-type".
소스 IP 주소는 해싱되어 실행중인 서버의 총 가중치로 나뉘어 요청을받을 서버를 지정합니다.
이렇게하면 서버가 다운되거나 가동되지 않는 한 동일한 클라이언트 IP 주소가 항상 같은 서버에 도달하게됩니다.
실행중인 서버 수가 변경되어 해시 결과가 변경되면 많은 클라이언트가 다른 서버로 이동합니다.
이 알고리즘은 일반적으로 쿠키를 삽입 할 수없는 TCP 모드에서 사용됩니다.
세션 쿠키를 거부하는 고객에게 최선의 노력을 기울일 수 있도록 인터넷에서 사용할 수도 있습니다.
이 알고리즘은 기본적으로 정적입니다. 즉, 서버의 가중치를 변경하는 것은 아무 효과가 없지만 "해시 유형"을 사용하여 변경할 수 있습니다.

uri This algorithm hashes either the left part of the URI (before
the question mark) or the whole URI (if the "whole" parameter
is present) and divides the hash value by the total weight of
the running servers. The result designates which server will
receive the request. This ensures that the same URI will
always be directed to the same server as long as no server
goes up or down. This is used with proxy caches and
anti-virus proxies in order to maximize the cache hit rate.
Note that this algorithm may only be used in an HTTP backend.
This algorithm is static by default, which means that
changing a server's weight on the fly will have no effect,
but this can be changed using "hash-type".
이 알고리즘은 URI의 왼쪽 부분 (물음표 앞에) 또는 전체 URI ( "전체"매개 변수가있는 경우)를 해시하고 실행중인 서버의 총 무게로 해시 값을 나눕니다.
결과는 요청을받을 서버를 지정합니다.
이렇게하면 서버가 위 또는 아래로 이동하지 않는 한 동일한 URI가 항상 동일한 서버로 전달됩니다.
이것은 캐시 적중률을 최대화하기 위해 프록시 캐시 및 안티 바이러스 프록시와 함께 사용됩니다.
이 알고리즘은 HTTP 백엔드에서만 사용할 수 있습니다.
이 알고리즘은 기본적으로 정적입니다. 즉, 서버의 가중치를 변경하는 것은 아무 효과가 없지만 "해시 유형"을 사용하여 변경할 수 있습니다.

This algorithm supports two optional parameters "len" and
"depth", both followed by a positive integer number. These
options may be helpful when it is needed to balance servers
based on the beginning of the URI only. The "len" parameter
indicates that the algorithm should only consider that many
characters at the beginning of the URI to compute the hash.
Note that having "len" set to 1 rarely makes sense since most
URIs start with a leading "/".
이 알고리즘은 두 개의 선택적 매개 변수 "len"과 "depth"를 지원하며 그 뒤에 양의 정수가 옵니다.
이러한 옵션은 URI 시작 부분을 기준으로 서버의 균형을 유지해야하는 경우에 유용합니다.
"len"매개 변수는 알고리즘이 해시를 계산하기 위해 URI의 시작 부분에있는 많은 문자만 고려해야한다는 것을 나타냅니다.
"len"을 1로 설정하면 대부분의 URI가 선행 "/"로 시작하는 의미다.

The "depth" parameter indicates the maximum directory depth
to be used to compute the hash. One level is counted for each
slash in the request. If both parameters are specified, the
evaluation stops when either is reached.
"depth"매개 변수는 해시를 계산하는 데 사용되는 최대 디렉토리 깊이를 나타냅니다.
하나의 레벨은 요청의 각 슬래시에 대해 계산됩니다.
두 매개 변수가 모두 지정되면 둘 중 하나에 도달하면 평가가 중지됩니다.

url_param The URL parameter specified in argument will be looked up in
the query string of each HTTP GET request.
인수에 지정된 URL 매개 변수는 각 HTTP GET 요청의 쿼리 문자열에서 조회됩니다.

If the modifier "check_post" is used, then an HTTP POST
request entity will be searched for the parameter argument,
when it is not found in a query string after a question mark
('?') in the URL. Optionally, specify a number of octets to
wait for before attempting to search the message body. If the
entity can not be searched, then round robin is used for each
request. For instance, if your clients always send the LB
parameter in the first 128 bytes, then specify that. The
default is 48. The entity data will not be scanned until the
required number of octets have arrived at the gateway, this
is the minimum of: (default/max_wait, Content-Length or first
chunk length). If Content-Length is missing or zero, it does
not need to wait for more data than the client promised to
send. When Content-Length is present and larger than
<max_wait>, then waiting is limited to <max_wait> and it is
assumed that this will be enough data to search for the
presence of the parameter. In the unlikely event that
Transfer-Encoding: chunked is used, only the first chunk is
scanned. Parameter values separated by a chunk boundary, may
be randomly balanced if at all.
수식어 "check_post"가 사용되면 URL에 물음표 ( '?')가있는 쿼리 문자열에서 HTTP POST 요청 엔티티가 매개 변수 인수를 검색합니다.
선택적으로 메시지 본문 검색을 시도하기 전에 대기 할 8 진수 수를 지정하십시오.
엔터티를 검색 할 수없는 경우 라운드 로빈이 각 요청에 사용됩니다.
예를 들어 클라이언트가 항상 첫 번째 128 바이트의 LB 매개 변수를 보내는 경우이를 지정하십시오.
기본값은 48입니다.
엔터티 데이터는 게이트 웨이에 필요한 수의 8 진수가 도착할 때까지 검색되지 않습니다.이 값은 최소값 (기본 / 최대 값, 내용 길이 또는 첫 번째 청크 길이)입니다.
Content-Length가 없거나 0이면 클라이언트가 약속 한 것보다 많은 데이터를 기다릴 필요가 없습니다.
콘텐츠 - 길이가 존재하고 <max_wait>보다 크면, 대기는 <max_wait> 이것이 매개 변수의 존재를 검색하기에 충분한 데이터라고 가정합니다.
드문 경우로 Transfer-Encoding : chunked가 사용되면 첫 번째 청크 만 스캔됩니다.
청크 경계로 분리 된 매개 변수 값은 무작위로 균형을 잡을 수 있습니다.

If the parameter is found followed by an equal sign ('=') and
a value, then the value is hashed and divided by the total
weight of the running servers. The result designates which
server will receive the request.
매개 변수 뒤에 등호 ( '=')와 값이있는 경우이 값은 해시되고 실행중인 서버의 총 가중치로 나누어집니다.
결과는 요청을받을 서버를 지정합니다.

This is used to track user identifiers in requests and ensure
that a same user ID will always be sent to the same server as
long as no server goes up or down. If no value is found or if
the parameter is not found, then a round robin algorithm is
applied. Note that this algorithm may only be used in an HTTP
backend. This algorithm is static by default, which means
that changing a server's weight on the fly will have no
effect, but this can be changed using "hash-type".
이것은 요청의 사용자 ID를 추적하고 서버가 위 또는 아래로 이동하지 않는 한 동일한 사용자 ID가 항상 동일한 서버로 보내지는 데 사용됩니다.
값이 없거나 매개 변수가 없으면 라운드 로빈 알고리즘이 적용됩니다.
이 알고리즘은 HTTP 백엔드에서만 사용할 수 있습니다.
이 알고리즘은 기본적으로 정적입니다. 즉, 서버의 가중치를 변경하는 것은 아무 효과가 없지만 "해시 유형"을 사용하여 변경할 수 있습니다.

hdr(<name>) The HTTP header <name> will be looked up in each HTTP request.
Just as with the equivalent ACL 'hdr()' function, the header
name in parenthesis is not case sensitive. If the header is
absent or if it does not contain any value, the roundrobin
algorithm is applied instead.
HTTP 헤더 <name> 각 HTTP 요청에서 조회됩니다.
동등한 ACL 'hdr ()'함수와 마찬가지로 괄호 안의 머리글 이름은 대 / 소문자를 구분하지 않습니다.
헤더가 없거나 값이없는 경우 라운드 로빈 알고리즘이 대신 적용됩니다.

An optional 'use_domain_only' parameter is available, for
reducing the hash algorithm to the main domain part with some
specific headers such as 'Host'. For instance, in the Host
value "haproxy.1wt.eu", only "1wt" will be considered.
선택적 'use_domain_only'매개 변수를 사용할 수 있습니다. 해시 알고리즘을 'Host'와 같은 특정 헤더가있는 기본 도메인 부분으로 줄이기 위해 사용할 수 있습니다.
예를 들어 호스트 값 "haproxy.1wt.eu"에서는 "1wt"만 고려됩니다.

This algorithm is static by default, which means that
changing a server's weight on the fly will have no effect,
but this can be changed using "hash-type".
이 알고리즘은 기본적으로 정적입니다. 즉, 서버의 가중치를 변경하는 것은 아무 효과가 없지만 "해시 유형"을 사용하여 변경할 수 있습니다.

rdp-cookie
rdp-cookie(name)
The RDP cookie <name> (or "mstshash" if omitted) will be
looked up and hashed for each incoming TCP request. Just as
with the equivalent ACL 'req_rdp_cookie()' function, the name
is not case-sensitive. This mechanism is useful as a degraded
persistence mode, as it makes it possible to always send the
same user (or the same session ID) to the same server. If the
cookie is not found, the normal roundrobin algorithm is
used instead.
RDP 쿠키 <이름> (생략하면 "mstshash")는 들어오는 TCP 요청마다 해시되고 해시됩니다.
동일한 ACL 'req_rdp_cookie ()'함수와 마찬가지로 이름은 대소 문자를 구분하지 않습니다.
이 메커니즘은 동일한 사용자 (또는 동일한 세션 ID)를 항상 동일한 서버로 보낼 수 있으므로 저하 된 지속성 모드로 유용합니다.
쿠키가 발견되지 않으면, 대신에 일반적인 라운드 로빈 알고리즘이 사용됩니다.

Note that for this to work, the frontend must ensure that an
RDP cookie is already present in the request buffer. For this
you must use 'tcp-request content accept' rule combined with
a 'req_rdp_cookie_cnt' ACL.
이 기능을 사용하려면 프론트 엔드가 RDP 쿠키가 요청 버퍼에 이미 있는지 확인해야합니다.
이를 위해서는 'req_rdp_cookie_cnt'ACL과 결합 된 'tcp-request content accept'규칙을 사용해야합니다.

<arguments> is an optional list of arguments which may be needed by some
algorithms. Right now, only "url_param" and "uri" support an
optional argument.
<인수> 일부 알고리즘에서 필요할 수있는 선택적 인수 목록입니다.
현재 "url_param"및 "uri"만 선택적 인수를 지원합니다.

balance uri [len <len>] [depth <depth>]
balance url_param <param> [check_post [<max_wait>]]

The load balancing algorithm of a backend is set to roundrobin when no other
algorithm, mode nor option have been set. The algorithm may only be set once
for each backend.
백엔드의 로드 밸런싱 알고리즘은 다른 알고리즘, 모드 또는 옵션이 설정되지 않은 경우 라운드로빈으로 설정됩니다.
알고리즘은 백엔드 마다 한 번만 설정할 수 있습니다.

Examples :
balance roundrobin
balance url_param userid
balance url_param session_id check_post 64
balance hdr(User-Agent)
balance hdr(host)
balance hdr(Host) use_domain_only

Note: the following caveats and limitations on using the "check_post"
extension with "url_param" must be considered :
참고 : "url_param"과 함께 "check_post"확장 프로그램 사용시 다음주의 사항 및 제한 사항을 고려해야합니다.

- all POST requests are eligible for consideration, because there is no way
to determine if the parameters will be found in the body or entity which
may contain binary data. Therefore another method may be required to
restrict consideration of POST requests that have no URL parameters in
the body. (see acl reqideny http_end)
바이너리 데이터를 포함 할 수있는 본문이나 엔티티에 매개 변수가 있는지 확인할 방법이 없으므로 모든 POST 요청은 고려 대상입니다.
따라서 본문에 URL 매개 변수가없는 POST 요청을 고려하지 않으려면 다른 방법이 필요할 수 있습니다. (acl reqideny http_end 참조)

- using a <max_wait> value larger than the request buffer size does not
make sense and is useless. The buffer size is set at build time, and
defaults to 16 kB.
<max_wait> 요청 버퍼 크기보다 큰 값은 의미가 없으며 쓸모가 없습니다.
버퍼 크기는 빌드시 설정되며 기본값은 16kB입니다.

- Content-Encoding is not supported, the parameter search will probably
fail; and load balancing will fall back to Round Robin.
Content-Encoding은 지원되지 않습니다. 매개 변수 검색이 실패합니다. 로드 밸런싱은 라운드 로빈으로 돌아갑니다.

- Expect: 100-continue is not supported, load balancing will fall back to
Round Robin.
Expect : 100-continue는 지원되지 않습니다.로드 균형 조정은 Round Robin으로 되돌아갑니다.

- Transfer-Encoding (RFC2616 3.6.1) is only supported in the first chunk.
If the entire parameter value is not present in the first chunk, the
selection of server is undefined (actually, defined by how little
actually appeared in the first chunk).
Transfer-Encoding (RFC2616 3.6.1)은 첫 번째 청크에서만 지원됩니다.
전체 매개 변수 값이 첫 번째 청크에 없으면 서버 선택은 정의되지 않습니다 (실제로 첫 번째 청크에 실제로 표시되는 빈도로 정의됩니다).

- This feature does not support generation of a 100, 411 or 501 response.
이 기능은 100, 411 또는 501 응답 생성을 지원하지 않습니다.

- In some cases, requesting "check_post" MAY attempt to scan the entire
contents of a message body. Scanning normally terminates when linear
white space or control characters are found, indicating the end of what
might be a URL parameter list. This is probably not a concern with SGML
type message bodies.
경우에 따라 "check_post"를 요청하면 메시지 본문의 전체 내용을 검사 할 수 있습니다.
선형 공백이나 제어 문자가 발견되면 정상적으로 스캔이 종료되고 URL 매개 변수 목록의 끝을 나타냅니다.
이것은 아마도 SGML 유형 메시지 본문과 관련이 없습니다.

See also : "dispatch", "cookie", "appsession", "transparent", "hash-type" and
"http_proxy".