Tengine 신규 nginx upstream 모듈 사용

텐 진 은 타 오 바 오의 Nginx 기반 2 차 개발 판 으로 텐 진 은 Nginx 를 완전히 호 환 하기 때문에 Nginx 방식 을 참조 해 텐 진 을 설정 할 수 있다.그러나 텐 진 은 비교적 실 용적 인 특성 과 성능 의 최 적 화 를 많이 제공 했다.예 를 들 어 upstream 모듈, Tengine 이 다시 개발 한 작은 모듈 에 대해 다음 과 같이 설명 합 니 다.백 엔 드 장 접속 시간 초과 기능 ngxhttp_upstream_keepalive_module 모듈 nginx 백 엔 드 긴 연결 시간 초과 지원 증가:
upstream backend {server 127.0.0.1: 8080; keepalive 32; keepalive timeout 30s; \ # 백 엔 드 연결 의 최대 idle 시간 은 30s} 1) keepalivetimeout
Syntax: keepalive_timeout timeDefault: - context: upstream 이 명령 은 백 엔 드 의 긴 연결 의 최대 시간 초과 시간 을 설정 합 니 다. 매개 변수의 시간 단 위 는 s (초), ms (밀리초), m (분) 일 수 있 습 니 다.기본 시간 단 위 는 초 입 니 다.
건강 검진 모듈 기능 ngxhttp_upstream_check_module, 이 모듈 은 Tengine 에 능 동적 백 엔 드 서버 건강 검진 기능 을 제공 합 니 다.이 모듈 은 Tengine - 1.4.0 버 전에 서 기본 으로 열 리 지 않 았 습 니 다. 컴 파일 옵션 을 설정 할 때 열 수 있 습 니 다:. / configure – with - httpupstream_check_module。
1）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=tcpContext: upstream
이 명령 은 백 엔 드 서버 의 건강 검진 기능 을 열 수 있 습 니 다. 명령 뒤의 매개 변 수 는 다음 과 같 습 니 다.
interval: 백 엔 드 에 보 내 는 건강 검진 가방 의 간격.
fall (fall count): 연속 실패 횟수 가 fall 에 도달 하면count, 서버 는 다운 으로 여 겨 집 니 다.
rise (rise count): 연속 성공 횟수 가 rise 에 도달 하면count, 서버 는 up 으로 여 겨 집 니 다.
timeout: 백 엔 드 건강 요청 시간 초과.
default_down: 초기 서버 의 상 태 를 설정 합 니 다. true 라면 기본 값 은 다운 입 니 다. false 라면 up 입 니 다.기본 값 은 true 입 니 다. 즉, 처음에 서버 가 사용 할 수 없다 고 생각 했 기 때문에 건강 검진 가방 이 일정한 성공 횟수 에 이 르 러 야 건강 하 다 고 여 겨 집 니 다.
type: 건강 검진 패키지 의 유형, 현재 다음 과 같은 다양한 유형 을 지원 합 니 다.
tcp: 간단 한 tcp 연결, 연결 이 성공 하면 백 엔 드 가 정상 임 을 설명 합 니 다.
ssl_hello: 초기 SSL hello 패 키 지 를 보 내 고 서버 의 SSL hello 패 키 지 를 받 습 니 다.
http: HTTP 요청 을 보 내 고 백 엔 드 리 셋 패키지 의 상 태 를 통 해 백 엔 드 의 생존 여 부 를 판단 합 니 다.
my sql: my sql 서버 에 연결 하여 서버 의 greeting 패 키 지 를 받 아 백 엔 드 가 생존 하 는 지 여 부 를 판단 합 니 다.
ajp: 백 엔 드 에 AJP 프로 토 콜 의 Cping 패 키 지 를 보 내 고 Cpong 패 키 지 를 받 아 백 엔 드 의 생존 여 부 를 판단 합 니 다.
port: 백 엔 드 서버 의 검사 포트 를 지정 합 니 다.실제 서비스 와 다른 백 엔 드 서버 의 포트 를 지정 할 수 있 습 니 다. 예 를 들 어 백 엔 드 가 제공 하 는 443 포트 의 응용 은 80 포트 의 상 태 를 검사 하여 백 엔 드 의 건강 상 태 를 판단 할 수 있 습 니 다.기본 값 은 0 입 니 다. 백 엔 드 서버 가 실제 서 비 스 를 제공 하 는 포트 와 같 습 니 다.이 옵션 은 Tengine - 1.4.0 에 나타 납 니 다.2）check_keepalive_requests
Syntax: check_keepalive_requests request_numDefault: 1Context: upstream 이 명령 은 연결 이 보 내 는 요청 수 를 설정 할 수 있 습 니 다. 기본 값 은 1 입 니 다. Tengine 이 1 번 요청 을 완료 하면 연결 을 닫 습 니 다.
3）check_http_send
Syntax: check_http_send http_packetDefault: "GET / HTTP / 1.0" Context: upstream 이 명령 은 http 건강 검진 패키지 가 보 낸 요청 내용 을 설정 할 수 있 습 니 다.전송 데 이 터 량 을 줄 이기 위해 서 는 'HEAD' 방법 을 추천 합 니 다.긴 연결 로 건강 검진 을 할 때 이 명령 에 keep - alive 요청 헤드 를 추가 해 야 합 니 다. 예 를 들 어 "HEAD / HTTP / 1.1 \ \ rConnection: keep - alive \ r \ r".또한 'GET' 방법 을 사용 한 경우 uri 의 size 를 요청 하 는 것 은 1 개의 interval 에서 전송 이 완료 되 지 않도록 해 야 합 니 다. 그렇지 않 으 면 건강 검진 모듈 에 의 해 백 엔 드 서버 나 네트워크 이상 으로 간 주 될 수 있 습 니 다.
4）check_http_expect_alive
Syntax: check_http_expect_alive [ http_2xx | http_3xx | http_4xx | http_5xx ]Default: http_2xx | http_3xx Context: upstream 이 명령 은 HTTP 회복 의 성공 상 태 를 지정 합 니 다. 기본적으로 2XX 와 3XX 의 상 태 는 건강 하 다 고 생각 합 니 다.
5）check_shm_size
Syntax: check_shm_size size Default: 1Mcontext: http 모든 백 엔 드 서버 건강 검사 상 태 는 공유 메모리 에 저 장 됩 니 다. 이 명령 은 공유 메모리 의 크기 를 설정 할 수 있 습 니 다.기본 값 은 1M 입 니 다. 1 천 대 이상 의 서버 가 있 고 설정 중 오류 가 발생 하면 메모리 크기 를 늘 려 야 할 수도 있 습 니 다.
6）check_status
Syntax: check_status [html|csv|json]Default: check_status html Context: location 은 서버 의 건강 상태 페이지 를 표시 합 니 다.이 명령 은 http 블록 에 설정 해 야 합 니 다.Tengine - 1.4.0 이후 페이지 를 표시 하 는 형식 을 설정 할 수 있 습 니 다.지원 하 는 형식 은 html, csv, json 입 니 다.기본 형식 은 html 입 니 다.요청 한 매개 변 수 를 통 해 형식 을 지정 할 수 있 습 니 다. '/ status' 가 상태 페이지 의 URL 이 라 고 가정 하고 format 매개 변 수 는 페이지 의 형식 을 바 꿀 수 있 습 니 다. 예 를 들 어:
/ status? format = html / status? format = csv / status? format = json 은 status 매개 변 수 를 통 해 같은 서버 상태의 목록 을 가 져 올 수 있 습 니 다. 예 를 들 어:
/ status? format = html & status = down / status? format = csv & status = up 다음은 HTML 상태 페이지 의 예 입 니 다.(server number 는 백 엔 드 서버 의 개수 입 니 다. generation 은 Nginx reload 의 횟수 입 니 다. Index 는 서버 의 색인 입 니 다. Upstream 은 설정 에 있 는 upstream 의 이름 입 니 다. Name 은 서버 IP 이 고 Status 는 서버 의 상태 입 니 다. Rise 는 서버 의 연속 검사 성공 횟수 입 니 다. Fall 은 연속 검사 실패 횟수 이 고 Check type 은 검사 방식 입 니 다. Check port 는 백 엔 드 전문 입 니 다.건강 검진 설정 포트): Tengine 에서 nginx upstream 모듈 을 새로 추 가 했 습 니 다. Tengine 에서 nginx upstream 모듈 을 새로 추 가 했 습 니 다.
다음은 csv 형식 페이지 의 예 입 니 다:
0, backend, 106.187.48.116: 80, up, 46, 0, http, 80 다음은 json 형식 페이지 의 예 입 니 다.
{"server": {"total": 1, "generation": 3, "server": [{"index": 0, "upstream": "backend", "name": "106.187.48.4116: 80", "status": "up", "rise": 58, "fall": 0, "type": "http", "port": 80}} 증강 판 upstream 사용 예시:
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";
    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 Connection: keep-alive";
    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;
    }
}

} Upstream 도 메 인 이름 분석 모듈 기능 ngx http upstream dynamic module. 이 모듈 은 upstream 에서 server 도 메 인 이름 을 동적 으로 분석 하 는 기능 을 제공 합 니 다. 많이 사용 되 지 않 습 니 다.
dynamic_resolve
Syntax: dynamic resolve [fallback = stale | next | shutdown] [fail timeout = time] Default: - context: upstream. 특정한 upstream 에서 동적 도 메 인 이름 해석 기능 을 사용 하도록 지정 합 니 다. fallback 매개 변 수 는 도 메 인 이름 을 해석 할 수 없 을 때 취 할 동작 을 지정 합 니 다.
stale, tengine 을 시작 할 때 가 져 온 오래된 주소 next 를 사용 하여 upstream 의 다음 server shutdown 을 선택 하 십시오. 현재 요청 fail timeout 인 자 를 끝내 고 DNS 서 비 스 를 사용 할 수 없 는 시간 으로 지정 하 였 습 니 다. 즉, 어떤 DNS 요청 이 실패 한 후에 도 DNS 서 비 스 를 사용 할 수 없다 고 가정 하여 잘못된 DNS 에 대한 조 회 를 줄 입 니 다. upstream backend{dynamic resolve fallback = stale fail timeout = 30s; server a. com; server b. com;} limit upstream tries 기능 limit upstream retries 는 백 엔 드 서버 에 대한 접근 을 요청 하 는 모든 최대 시도 횟수 를 제한 하고 proxy, memcached, fastcgi, scgi 와 uwsgi 모듈 을 지원 합 니 다. 아래 명령 을 사용 하여 접근 횟수 를 제한 할 수 있 습 니 다.
fastcgi 에이전트 의 백 엔 드 시도 횟수 제한
fastcgi_upstream_tries num
프 록 시 에이전트 의 백 엔 드 시도 횟수 제한
proxy_upstream_tries num
memcached 에이전트 의 백 엔 드 시도 횟수 제한
memcached_upstream_tries num
scgi 에이전트 의 백 엔 드 시도 횟수 제한
scgi_upstream_tries num
uwsgi 에이전트 의 백 엔 드 시도 횟수 제한
uwsgi_upstream_tries num
다음으로 전송:https://blog.51cto.com/14164498/2341396