Nginx 부하 균형 upstreamcheck_module 건강 검진

프론트 엔 드 nginx 가 역방향 프 록 시 를 하 는 것 을 잘 알 고 있 습 니 다. 백 엔 드 서버 가 지연 되면 nginx 는 이 real server 를 upstream 에서 쫓 아 낼 수 없 기 때문에 백 엔 드 에 있 는 이 real server 에 전송 해 달라 고 요청 할 수도 있 습 니 다. nginx 는 localtion 에서 proxy 를 사용 할 수 있 지만next_upstream 은 사용자 에 게 되 돌아 오 는 오류 페이지 를 해결 합 니 다. 그러나 이것 은 이 서버 에 요청 을 전달 한 다음 에 다른 서버 에 전송 합 니 다. 그러면 한 번 의 퍼 가기 가 낭비 되 었 습 니 다. 이번에 타 오 바 오 기술 팀 과 개발 한 nginx 모델 빠 른 nginxupstream_check_모듈 은 후방 realserver 의 건강 상 태 를 검사 합 니 다. 백 엔 드 서버 가 사용 되 지 않 으 면 요청 을 이 서버 에 전송 하지 않 습 니 다.
 
nginx_upstream_check_모듈 모듈
nginx_upstream_check_module 은 이퀄 라이저 내 노드 의 건강 검 사 를 전문 적 으로 제공 하 는 외부 모듈 로 타 오 바 오의 야 오 웨 이 빈 대신 이 개발 하여 백 엔 드 realserver 의 건강 상 태 를 검사 할 수 있 습 니 다.백 엔 드 realserver 가 사용 되 지 않 으 면 뒤의 요청 은 이 노드 에 전달 되 지 않 고 몇 가지 상 태 를 계속 검사 합 니 다.타 오 바 오 는 자신의 tengine 에 이 모듈 을 자체 적 으로 가지 고 있 습 니 다.항목 주소:https://github.com/yaoweibin/nginx_upstream_check_module 。  
타 오 바 오 는 자신의 tengine 에 이 모듈 을 가지 고 있 습 니 다. 타 오 바 오 tengine 홈 페이지 를 방문 하여 이 버 전의 nginx, 공식 주 소 를 얻 을 수 있 습 니 다.http://tengine.taobao.org/。
 
 
nginx_upstream_check_module 모듈 사용 (이 모듈 을 nginx 에 컴 파일 하 는 방법 은 소개 하지 않 고 사용 만 소개 합 니 다)
서비스 관리의 중요 한 임 무 는 서비스 노드 의 변경 을 감지 하고 완성 과 이다.이 는 서비스 관리 플랫폼 이 , 의 감지 서비스 노드 의 건강 상 태 를 필요 로 한다.
방안 개술
Nginx 는 사용자 가 선택 할 수 있 도록 세 가지 HTTP 서비스 건강 검진 방안 을 제공 합 니 다.

TCP 층 의 기본 검사 방안: 정시 에 백 엔 드 서비스 와 하나의 tcp 를 구축 하고 링크 구축 에 성공 하면 서비스 노드 가 건강 하 다 고 생각 합 니 다.

HTTP 계층 기본 검사 방안: TCP 계층 검 사 는 한계 가 있 습 니 다.

많은 HTTP 서 비 스 는 밴드 상태 이 고 포트 가 listen 상태 에 있다 고 해서 서비스 가 예열 되 었 다 는 것 을 대표 할 수 없습니다.

서비스 내부 처리 논리 가 정체 되 었 는 지 진실 하 게 반영 하지 못 한다.

이때 http 건강 검 사 를 선택 할 수 있 고 서비스 에 http 요청 GET / HTTP/1.0\r
\r
을 보 내 며 상태 가 2xx 또는 3xx 일 때 백 엔 드 서비스 가 정상 이 라 고 생각 합 니 다.

사용자 정의 방안: (nginx upstream check module 모듈) 다음 설명 에 따라 검사 방안 을 사용자 정의 할 수 있 습 니 다.

 
설정 매개 변수 상세 설명
자주 사용 하 는 건강 검진 설정 은 다음 과 같 습 니 다.

check fall=3 interval=3000 rise=2 timeout=2000 type=http;check_http_expect_alive http_2xx http_3xx ;check_http_send "GET /checkAlive HTTP/1.0\r
\r
" ;

다음은 각 설정 매개 변수 에 대해 상세 하 게 소개 합 니 다.
 
check：
check 필드 매개 변 수 는 다음 과 같 습 니 다.

Syntax: check interval=milliseconds [fall=count] [rise=count] [timeout=milliseconds] [default_down=true|false] [type=tcp|http|ssl_hello|mysql|ajp] [port=check_port]Default:         ，    ：interval=30000 fall=5 rise=2 timeout=1000 default_down=true type=tcp

check  필드 각 매개 변수의 의 미 는 다음 과 같다.

interval: 백 엔 드 에 보 내 는 건강 검진 가방 의 간격.

fall(fall_count): 연속 실패 횟수 가 fall 에 도달 하면count, 서버 는 다운 으로 여 겨 집 니 다.

rise(rise_count): 연속 성공 횟수 가 ise 에 도달 하면count, 서버 는 up 으로 여 겨 집 니 다.

timeout: 백 엔 드 건강 요청 시간 초과.

default_down: 초기 서버 의 상 태 를 설정 합 니 다. true 라면 기본 값 은 다운 이 고 false 라면 up 입 니 다.기본 값 은 true 입 니 다. 즉, 처음에 서버 가 사용 할 수 없다 고 생각 했 기 때문에 건강 검진 가방 이 일정한 성공 횟수 에 이 르 러 야 건강 하 다 고 여 겨 집 니 다.

type: 건강 검진 가방 의 유형 은 현재 다음 과 같은 다양한 유형 을 지원 합 니 다.   

tcp: 간단 한 tcp 연결, 연결 에 성공 하면 백 엔 드 가 정상 이라는 뜻 입 니 다.

ssl_hello: 초기 SSL hello 패 키 지 를 보 내 고 서버 의 SSL hello 패 키 지 를 받 습 니 다.

http: HTTP 요청 을 보 내 고 백 엔 드 의 리 셋 패 킷 상 태 를 통 해 백 엔 드 의 생존 여 부 를 판단 합 니 다.

mysql: my sql 서버 에 연결 하여 서버 의 greeting 패 키 지 를 받 아 백 엔 드 의 생존 여 부 를 판단 합 니 다.

ajp: 백 엔 드 에 AJP 프로 토 콜 의 Cping 패 키 지 를 보 내 고 Cpong 패 키 지 를 받 아 백 엔 드 의 생존 여 부 를 판단 합 니 다.

port: 백 엔 드 서버 의 검사 포트 를 지정 합 니 다.실제 서비스 와 다른 백 엔 드 서버 의 포트 를 지정 할 수 있 습 니 다. 예 를 들 어 백 엔 드 가 제공 하 는 443 포트 의 응용 은 80 포트 의 상 태 를 검사 하여 백 엔 드 의 건강 상 태 를 판단 할 수 있 습 니 다.기본 값 은 0 입 니 다. 백 엔 드 서버 가 실제 서 비 스 를 제공 하 는 포트 와 같 습 니 다.

 
check_http_expect_alive： check_http_expect_alive  활성 건강 검진 시 HTTP 회복 성공 상 태 를 지정 합 니 다:

Syntax: check_http_expect_alive [ http_2xx | http_3xx | http_4xx | http_5xx ]Default: http_2xx | http_3xx

 
check_http_send： check_http_send  http 건강 검진 패키지 에서 보 내 는 요청 내용 설정
전송 데 이 터 량 을 줄 이기 위해 서 는 'HEAD' 방법 을 추천 합 니 다.긴 연결 로 건강 검진 을 할 때 이 명령 에 keep - alive 요청 헤드 를 추가 해 야 합 니 다. 예 를 들 어 "HEAD / HTTP / 1.1 \ \ rConnection: keep - alive \ r \ r".또한 'GET' 방법 을 사용 한 경우 uri 의 size 를 요청 하 는 것 은 1 개의 interval 에서 전송 이 완료 되 지 않도록 해 야 합 니 다. 그렇지 않 으 면 건강 검진 모듈 에 의 해 백 엔 드 서버 나 네트워크 이상 으로 간 주 될 수 있 습 니 다.​​​​​​​

Syntax: check_http_send http_packetDefault: "GET / HTTP/1.0\r
\r
"

 
전체 예시
전체 예 는 다음 과 같다.

http {    upstream cluster1 {        # simple round-robin        server 192.168.0.1:80;        server 192.168.0.2:80;        check interval=3000 rise=2 fall=5 timeout=1000 type=http;        check_http_send "HEAD / HTTP/1.0\r
\r
";        check_http_expect_alive http_2xx http_3xx;    }    upstream cluster2 {        # simple round-robin        server 192.168.0.3:80;        server 192.168.0.4:80;        check interval=3000 rise=2 fall=5 timeout=1000 type=http;        check_keepalive_requests 100;        check_http_send "HEAD / HTTP/1.1\r
Connection: keep-alive\r
\r
";        check_http_expect_alive http_2xx http_3xx;    }    server {        listen 80;        location /1 {            proxy_pass http://cluster1;        }        location /2 {            proxy_pass http://cluster2;        }        location /status {            check_status;            access_log   off;            allow SOME.IP.ADD.RESS;            deny all;        }    }}