
TCP Health Check
Upstream 그룹에서 주기적인 Health Check를 전송하여 Upstream 그룹 내 TCP 서버의 상태를 모니터링하고, NGINX Plus 에서 사용자 정의 가능한 Active Health Check를 포함하세요.
목차
1. 소개
2. 전제 조건
3. Passive TCP Health Check
3-1. 서버 Slow Start
4. Active TCP Health Check
4-1. TCP Health Check 미세 조정
4-2. “match { }” 구성 블록
1. 소개
NGINX와 NGINX Plus 는 TCP Upstream서버를 지속적으로 테스트하여 장애가 발생한 서버를 피하고 복구된 서버를 Load Balancing 그룹에 정상적으로 추가할 수 있습니다.
2. 전제 조건
- 예를 들어
stream
컨텍스트에서 TCP 서버의 Upstream 그룹을 구성했습니다.
stream {
#...
upstream stream_backend {
server backend1.example.com:12345;
server backend2.example.com:12345;
server backend3.example.com:12345;
}
#...
}
- server 그룹에 TCP 연결을 전달하는 서버를 구성했습니다.
stream {
#...
server {
listen 12345;
proxy_pass stream_backend;
}
#...
}
3. Passive TCP Health Check
Upstream 서버에 연결하려는 시도가 시간 초과되거나 오류가 발생하면 NGINX Open Source 또는 NGINX Plus 는 서버를 사용할 수 없는 것으로 표시하고 정의된 시간 동안 해당 서버에 대한 요청 전송을 중지할 수 있습니다. NGINX가 Upstream 서버를 사용할 수 없는 것으로 간주하는 조건을 정의하려면 server
지시문에 다음 매개변수를 포함하세요.
fail_timeout
– 서버를 사용할 수 없는 것으로 간주하기 위해 지정된 횟수만큼의 연결 시도가 실패해야 하는 제한 시간입니다. 또한 서버를 사용 불가능으로 표시한 후 NGINX가 서버를 사용할 수 없는 것으로 간주하는 시간입니다.max_fails
– 서버를 사용할 수 없는 것으로 간주하는 지정된 시간 동안 발생한 실패 시도 횟수입니다.
기본값은 10
초와 1
회 시도입니다. 따라서 10초 동안 한 번 이상 연결 시도가 시간 초과되거나 실패하면 NGINX는 10초 동안 서버를 사용할 수 없는 상태로 표시합니다. 이 예는 이러한 매개 변수를 30초 이내에 2번 실패로 구성하는 방법을 보여줍니다.
upstream stream_backend {
server backend1.example.com:12345 weight=5;
server backend2.example.com:12345 max_fails=2 fail_timeout=30s;
server backend3.example.com:12346 max_conns=3;
}
3-1. 서버 Slow Start
최근에 복구된 Upstream 서버는 연결에 쉽게 부하가 걸릴 수 있으며, 이로 인해 서버가 다시 사용 불가능으로 표시될 수 있습니다. Slow start를 사용하면 Upstream 서버가 복구되거나 사용 가능하게 된 후 가중치를 0에서 정상 값으로 점진적으로 복구할 수 있습니다. 이 작업은 Upstream server
지시문의 slow_start
매개변수를 사용하여 수행할 수 있습니다.
upstream backend {
server backend1.example.com:12345 slow_start=30s;
server backend2.example.com;
server 192.0.0.1 backup;
}
Note: 그룹에 서버가 하나만 있는 경우 slow_start
매개변수는 무시되며 서버가 사용 불가능으로 표시되지 않습니다. Slow Start는 NGINX Plus 전용입니다.
4. Active TCP Health Check
다양한 장애 유형을 테스트하도록 Health Check를 구성할 수 있습니다. 예를 들어, NGINX Plus 는 Upstream 서버의 응답 성능을 지속적으로 테스트하고 장애가 발생한 서버를 회피할 수 있습니다.
NGINX Plus 는 각 Upstream 서버에 특수 Health Check 요청을 보내고 특정 조건을 충족하는 응답이 있는지 확인합니다. 서버에 연결할 수 없으면 Health Check가 실패하고 서버가 정상적이지 않은 것으로 간주됩니다. NGINX Plus는 건강하지 않은 서버에 대한 클라이언트 연결을 Proxy하지 않습니다. Upstream 그룹에 대해 여러 Health Check가 구성된 경우, 검사 중 하나라도 실패하면 해당 서버가 정상적이지 않은 것으로 간주합니다.
Active Health Check를 활성화하려면.
1. 공유 메모리 Zone 지정 – NGINX Plus Worker Processes에서 카운터 및 연결에 대한 상태 정보를 공유하는 특수 Zone입니다. zone
지시문을 Upstream 서버 그룹에 추가하고 Zone 이름(여기서는 stream_backend
)과 메모리 용량(64KB)을 지정합니다.
stream {
#...
upstream stream_backend {
zone stream_backend 64k;
server backend1.example.com:12345;
server backend2.example.com:12345;
server backend3.example.com:12345;
}
#...
}
2. health_check
지시문을 사용하여 Upstream 그룹에 대한 Active Health Check를 사용하도록 설정합니다.
stream {
#...
server {
listen 12345;
proxy_pass stream_backend;
health_check;
#...
}
}
3. 필요한 경우 health_check_timeout
지시문을 사용하여 두 개의 연속된 Health Check 사이의 시간 차이를 줄입니다. 이 지시문은 Health Check의 경우 이 시간 제한을 훨씬 더 짧게 설정해야 하므로 Health Check에 대한 proxy_timeout
값을 재정의합니다.
stream {
#...
server {
listen 12345;
proxy_pass stream_backend;
health_check;
health_check_timeout 5s;
}
}
4. 기본적으로 NGINX Plus 는 upstream
블록의 server
지시문으로 지정한 포트로 Health Check 메시지를 보냅니다. Health Check를 위해 다른 포트를 지정할 수 있으며, 이는 동일한 호스트에 있는 많은 서비스의 상태를 모니터링할 때 특히 유용합니다. 포트를 재정의하려면 health_check
지시문의 port
매개변수를 지정하세요.
stream {
#...
server {
listen 12345;
proxy_pass stream_backend;
health_check port=12346;
health_check_timeout 5s;
}
}
4-1. TCP Health Check 미세 조정
기본적으로 NGINX Plus는 5
초마다 Upstream 서버 그룹의 각 서버에 연결을 시도합니다. 연결에 성공하지 못하면 NGINX Plus는 Health Check에 실패한 것으로 간주하고 서버를 비정상 상태로 표시한 다음 서버에 대한 클라이언트 연결 포워딩을 중지합니다.
기본 동작을 변경하려면 health_check
지시문에 매개 변수를 포함하세요.
interval
– NGINX Plus가 Health Check 요청을 보내는 빈도(초)(기본값은5
초)passes
– 서버가 정상으로 간주되기 위해 응답해야 하는 연속 Health Check 횟수(기본값은1
)fails
– 서버가 비정상 상태로 간주되기 위해 서버가 응답하지 않아야 하는 연속 Health Check 횟수(기본값은1
)
stream {
#...
server {
listen 12345;
proxy_pass stream_backend;
health_check interval=10 passes=2 fails=3;
}
#...
}
이 예에서는 TCP Health Check 간격이 10
초로 늘어나고, 3
번 연속 Health Check에 실패하면 서버가 정상적이지 않은 것으로 간주되며, 서버가 다시 정상으로 간주되려면 2
번 연속 검사를 통과해야 합니다.
4-2. “match { }” 구성 블록
자체 테스트를 만들어 Health Check에 대한 서버 응답을 확인할 수 있습니다. 이러한 테스트는 stream { }
컨텍스트에 배치된 match { }
구성 블록으로 정의됩니다.
1. stream { }
수준에서 match { }
블록을 정의하고 이름(예: tcp_test)을 지정합니다.
stream {
#...
match tcp_test {
#...
}
}
이 블록에는 3단계에 따라 설명된 테스트가 포함됩니다.
2. match
매개변수와 match
블록의 이름을 지정하여 health_check
지시문의 해당 블록을 참조합니다.
stream {
#...
server {
listen 12345;
health_check match=tcp_test;
proxy_pass stream_backend;
}
#...
}
3. match
블록에서 Health Check이 성공할 조건 또는 테스트를 지정합니다. 이 블록에는 다음 매개 변수를 사용할 수 있습니다.
send
– 서버로 전송할 텍스트 문자열 또는 16진수 Literal(“\x” 뒤에 두 개의 16진수 숫자)입니다.expect
– 서버에서 반환된 데이터가 일치해야 하는 Literal 문자열 또는 정규식
이러한 매개변수는 다양한 조합으로 사용할 수 있지만 한 번에 하나의 send 및 expect 매개변수만 지정할 수 있습니다.
send
또는expect
매개변수가 지정되지 않은 경우 서버에 연결할 수 있는지 테스트합니다.expect
매개변수를 지정하면 서버가 무조건 먼저 데이터를 전송할 것으로 간주됩니다.
match pop3 {
expect ~* "\+OK";
}
send
매개변수를 지정하면 연결이 성공적으로 설정되고 지정된 문자열이 서버로 전송될 것으로 간주됩니다.
match pop_quit {
send QUIT;
}
send
매개 변수와expect
매개 변수를 모두 지정한 경우send
매개 변수의 문자열은expect
매개 변수의 정규식과 일치해야 합니다.
stream {
#...
upstream stream_backend {
zone upstream_backend 64k;
server backend1.example.com:12345;
}
match http {
send "GET / HTTP/1.0\r\nHost: localhost\r\n\r\n";
expect ~* "200 OK";
}
server {
listen 12345;
health_check match=http;
proxy_pass stream_backend;
}
}
이 예에서는 Health Check를 통과하려면 HTTP 요청을 서버로 보내야 하며, 서버의 예상 결과에는 성공적인 HTTP 응답을 나타내는 200 ok
가 포함되어야 함을 보여 줍니다.