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가 포함되어야 함을 보여 줍니다.