Nginx 의 TCP 실행 시 건강 검진
7697 단어 Nginx
이 장 에 서 는 TCP 의 운행 상황 검 사 를 어떻게 설정 하 는 지 소개 합 니 다.
소개
소개 하 다.
NGINX 와 NGINX Plus 는 TCP 상류 서버 를 지속 적 으로 테스트 하여 고장 난 서버 를 피 할 수 있 으 며, 복 구 된 서버 를 부하 밸 런 스 그룹 에 정상적으로 추가 할 수 있 습 니 다.
선 결 조건
stream {
#...
upstream stream_backend {
server backend1.example.com:12345;
server backend2.example.com:12345;
server backend3.example.com:12345;
}
#...
}
stream {
#...
server {
listen 12345;
proxy_pass stream_backend;
}
#...
}
수 동 TCP 운행 상황 검사
상위 서버 에 연결 하려 는 시도 가 시간 을 초과 하거나 오류 가 발생 하면 NGINX Open Source 나 NGINX Plus 는 서버 를 사용 할 수 없 음 으로 표시 하고 지 정 된 시간 내 에 요청 을 보 내 는 것 을 중단 할 수 있 습 니 다.NGINX 가 상위 서버 가 사용 할 수 없다 고 생각 하 는 조건 을 정의 하려 면
stream
명령 에 다음 과 같은 인 자 를 포함 하 십시오.server
–지정 한 연결 시도 횟수 내 에 실패 해 야 하 는 시간 에 서버 를 사용 할 수 없습니다.또 NGINX 는 서버 를 사용 할 수 없다 고 판단 한 후 서버 가 사용 할 수 없다 고 생각 하 는 시간 으로 표시 했다.fail_timeout
–지 정 된 시간 동안 NGINX 는 서버 가 사용 할 수 없다 고 생각 하 는 실패 시도 횟수 입 니 다.기본 값 은
max_fails
초 와 10
시도 횟수 입 니 다.따라서 연결 시도 시간 이 초과 되 거나 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;
}
서버 천천히 시작
최근 복 구 된 상류 서버 는 연결 에 쉽게 잠 겨 서버 가 다시 사용 할 수 없 는 것 으로 표 시 될 수 있 습 니 다.느 린 속도 로 시작 하면 상류 서버 가 복구 되 거나 사용 가능 한 후에 가중치 를 0 에서 표시 값 으로 점차 회복 할 수 있 습 니 다.이것 은
1
상류 slow_start
명령 의 매개 변 수 를 통 해 완성 할 수 있 습 니 다.upstream backend {
server backend1.example.com:12345 slow_start=30s;
server backend2.example.com;
server 192.0.0.1 backup;
}
그룹 에 서버 가 한 대 밖 에 없다 면
server
은 이 인 자 를 무시 하고 서버 를 사용 할 수 없 는 것 으로 표시 하지 않 습 니 다.느 린 속도 로 작 동 하 는 것 은 NGINX Plus 만 의 것 이다.활동 TCP 실행 상태 검사
운행 상황 검 사 를 각종 고장 유형 을 테스트 하 는 것 으로 설정 할 수 있 습 니 다.예 를 들 어 NGINX Plus 는 상위 서버 의 응답 능력 을 연속 테스트 하고 고장 난 서버 를 피 할 수 있다.
NGINX Plus 는 상위 서버 마다 특별한 운행 상황 점검 요청 을 보 내 고 특정 조건 을 충족 하 는 지 확인한다.서버 와 의 연결 이 되 지 않 으 면 실행 상황 검사 가 실 패 했 고 서버 는 실행 상황 이 좋 지 않 은 것 으로 간 주 됩 니 다.NGINX Plus 는 실행 상태 가 좋 지 않 은 서버 에 클 라 이언 트 를 연결 하지 않 습 니 다.상위 그룹 에 여러 개의 운행 상황 검 사 를 설정 하면 모든 검사 가 실패 하면 해당 서버 가 정상 적 이지 않 을 수 있 습 니 다.
능 동적 건강 검진 사용 하기:
slow_start
명령 을 추가 하고 영역 이름 (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;
}
#...
}
zone
명령 을 사용 하여 상위 그룹 에 주동 적 인 운행 상황 검 사 를 사용 합 니 다.stream {
#...
server {
listen 12345;
proxy_pass stream_backend;
health_check;
#...
}
}
health_check
명령 을 사용 하여 두 번 의 연속 운행 상황 검사 간 의 시간 초 과 를 줄인다.이 명령 은 health_check_timeout
운행 상황 검사 의 값 을 덮어 씁 니 다. 운행 상황 검사 에 있어 서 시간 초과 가 크게 단축 되 어야 하기 때 문 입 니 다.stream {
#...
server {
listen 12345;
proxy_pass stream_backend;
health_check;
health_check_timeout 5s;
}
}
proxy_timeout
명령 이 지정 한 포트 server
으로 보 냅 니 다.다른 포트 를 지정 하여 운행 상황 을 검사 할 수 있 습 니 다. 이것 은 같은 호스트 의 많은 서비스의 운행 상황 을 감시 할 때 특히 유용 합 니 다.포트 를 덮어 쓰 려 면 의사 명령 의 upstream
매개 변수 port
을 지정 하 십시오.stream {
#...
server {
listen 12345;
proxy_pass stream_backend;
health_check port=12346;
health_check_timeout 5s;
}
}
TCP 작 동 상태 검사
기본적으로 NGINX Plus 는 상위 서버 그룹 에 1 초 에
health_check
씩 연결 하려 고 시도 합 니 다. 。연결 을 만 들 수 없 으 면 NGINX Plus 는 실행 상황 검사 에 실패 했다 고 보고 서버 를 비정 상 으로 표시 한 후 클 라 이언 트 연결 을 서버 로 전송 하 는 것 을 중단 합 니 다.기본 행동 을 변경 하려 면
5
의사 명령 에 인 자 를 포함 하 십시오:health_check
– NGINX Plus 건강 검진 요청 빈도 (초 당 interval
) 단위) (기본 초) 5
– 서버 가 응답 해 야 건강 한 연속 건강 검진 횟수 로 볼 수 있 습 니 다. passes
) 1
– 서버 가 응답 하지 않 아야 건강 하지 않 은 연속 건강 검진 횟수 로 볼 수 있 습 니 다. fails
) stream {
#...
server {
listen 12345;
proxy_pass stream_backend;
health_check interval=10 passes=2 fails=3;
}
#...
}
이 예시 에서 두 차례 의 TCP 건강 검진 사이 의 시간 은
1
여 초 로 늘 었 고, 서버 는 10
연속 실패 한 건강 검진 후 불 건전 한 것 으로 간주 되 며, 서버 는 3
연속 검진 을 통과 해 야 다시 건강 한 것 으로 간주 된다."match {}" 설정 블록
서버 가 실행 상황 검사 에 대한 응답 을 검증 하기 위해 테스트 를 만 들 수 있 습 니 다.이 테스트 들 은 상하 문 에 설 치 된 설정 블록 을 통 해 정 의 됩 니 다.
2
match {}
stream {}
stream {}
match {}
stream {
#...
match tcp_test {
#...
}
}
이 블록 은 3 단계 에서 설명 한 테스트 를 포함 할 것 입 니 다.
tcp_test
은 health_check
매개 변수 와 match
개의 이름 을 지정 하여 명령 에서 이 블록 을 참조 합 니 다.stream {
#...
server {
listen 12345;
health_check match=tcp_test;
proxy_pass stream_backend;
}
#...
}
match
개 에서 운행 상황 검사 성공 조건 이나 테스트 를 지정 합 니 다.이 블록 은 다음 매개 변 수 를 받 아들 일 수 있 습 니 다:match
–서버 에 보 내 는 텍스트 문자열 이나 16 진수 텍스트 ("/ x" 뒤 꿈 치 16 진수) send
–서버 가 되 돌려 주 는 데 이 터 는 일치 하 는 문자열 이나 정규 표현 식 이 매개 변 수 는 서로 다른 조합 으로 사용 할 수 있 지만
expect
번 send
은 최대 하나의 매개 변수 만 지정 할 수 있 습 니 다.expect
또는 send
지정 매개 변 수 를 지정 하지 않 으 면 서버 에 연결 하 는 능력 을 테스트 합 니 다.expect
이 매개 변 수 를 지정 하면 서버 가 먼저 무조건 데 이 터 를 보 내 기 를 기대 합 니 다: match pop3 {
expect ~* "\+OK";
}
expect
이 인 자 를 지정 하면 연결 을 성공 적 으로 만 들 고 지정 한 문자열 을 서버 에 보 낼 것 으로 예상 합 니 다: match pop_quit {
send QUIT;
}
send
과 send
인 자 를 동시에 지정 하면 매개 변수 중의 문자열 expect
은 매개 변수 중의 정규 표현 식 과 일치 해 야 합 니 다 send
: stream {
#...
upstream stream_backend {
zone upstream_backend 64k;
server backend1.example.com:12345;
}
match http {
send "GET / HTTP/1.0\r
Host: localhost\r
\r
";
expect ~* "200 OK";
}
server {
listen 12345;
health_check match=http;
proxy_pass stream_backend;
}
}
이 예제 에 따 르 면 실행 상황 검 사 를 통과 시 키 려 면 HTTP 요청 을 서버 에 보 내야 하고 서버 의 예상 결과 에는
expect
이 포함 되 어 있 습 니 다. 200
성공 한 HTTP 응답 을 표시 하 는 정보 입 니 다.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
linux2에 nginx 설치설치 가능한 nginx를 확인하고, 해당 nginx를 설치한다. localhost 혹은 해당 ip로 접속을 하면 nginx 화면을 볼 수 있다....
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.