NGINX Plus

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