Nginx 의 부하 균형 원리
18087 단어 Geek
기본 소개
부하 균형 은 다음 과 같은 기초 지식 과 관련된다.(1) 부하 균형 알고리즘 a. Round Robin: 모든 백 엔 드 훈련 에 대한 요청 은 가장 간단 한 방식 이자 기본 적 인 분배 방식 이다.b. Least Connections (least conn): 현재 활성 화 된 연결 수 를 추적 하고 백 엔 드 의 활성 화 된 연결 수 를 설명 합 니 다. 가장 적은 연결 수 는 이 백 엔 드 부하 가 가장 가 벼 운 것 을 설명 합 니 다. 이 방식 은 설정 에서 모든 upstream 에 할당 하 는 weight 가중치 정 보 를 고려 합 니 다.c. Least Time (least time): 응답 이 가장 빠 르 고 활성 화 된 연결 수가 가장 적은 backend 에 요청 합 니 다.d. IP Hash (ip hash): 요청 소스 IP 주소 에 대해 hash 값 을 계산 합 니 다. IPv 4 는 앞의 3 개의 octet 를 고려 합 니 다. IPv 6 는 모든 주소 위 치 를 고려 한 다음 에 얻 은 hash 값 에 따라 특정한 맵 을 통 해 backend 에 분 배 됩 니 다.e. Generic Hash (hash): 사용자 정의 자원 (예 를 들 어 URL) 방식 으로 hash 값 을 계산 하여 분 배 를 완료 합 니 다. consistent 키 워드 를 선택 하여 일치 성 hash 특성 을 지원 합 니 다.(2) 세 션 일치 성 사용자 (브 라 우 저) 는 서버 와 상호작용 을 할 때 보통 로 컬 에 정 보 를 저장 하 는데 전체 과정 을 세 션 (Session) 이 라 고 부 르 고 유일한 Session ID 로 표 시 를 한다.세 션 의 개념 은 카 트 와 같은 흔 한 상황 에 만 사용 되 는 것 이 아 닙 니 다. HTTP 프로 토 콜 은 상태 가 없 기 때문에 논리 적 인 컨 텍스트 가 필요 한 모든 상황 은 세 션 체 제 를 사용 해 야 합 니 다. 또한 HTTP 클 라 이언 트 도 일부 데 이 터 를 로 컬 에 추가 로 캐 시 하면 요청 의 고성능 을 줄 일 수 있 습 니 다.부하 균형 이 이 세 션 의 요청 을 서로 다른 백 엔 드 서버 에 할당 할 수 있다 면 적절 하지 않 을 것 입 니 다. 여러 백 엔 드 를 통 해 이 데 이 터 를 공유 해 야 합 니 다. 효율 이 떨 어 질 것 입 니 다. 가장 간단 한 경 우 는 세 션 의 일치 성 을 확보 하 는 것 입 니 다. 같은 세 션 은 매번 같은 백 엔 드 에 배 치 됩 니 다.(3) 백 엔 드 서버 의 동적 설정 에 문제 가 생 긴 백 엔 드 는 분배 군 을 제때에 탐지 하고 제거 할 수 있어 야 하 며, 업무 가 증가 할 때 백 엔 드 수 를 유연 하 게 추가 할 수 있다.또한 현재 유행 하고 있 는 Elastic Compute 클 라 우 드 컴 퓨 팅 서 비 스 는 서비스 업 체 도 현재 부하 에 따라 backend 호스트 를 자동 으로 추가 하고 감소 해 야 합 니 다.(4) DNS 의 부하 균형 을 바탕 으로 현대 의 네트워크 서비스 자 는 한 도 메 인 이름 이 여러 호스트 에 연결 되 어 DNS 조 회 를 할 때 기본 적 인 상황 에서 DNS 서버 는 round - robin 형식 으로 서로 다른 순서 로 IP 주소 목록 을 되 돌려 주기 때문에 자 연 스 럽 게 고객 의 요 구 를 서로 다른 호스트 에 배정 합 니 다.그러나 이러한 방식 에는 고유 한 결함 이 있 습 니 다. DNS 는 호스트 와 IP 주소 의 접근 성 을 검사 하지 않 기 때문에 클 라 이언 트 에 배 정 된 IP 가 사용 가능 한 지 확인 하지 못 합 니 다 (Google 404).DNS 의 분석 결 과 는 클 라 이언 트, 여러 개의 중간 DNS 서버 에 끊임없이 캐 시 되 기 때문에 백 엔 드 의 분 배 는 그리 이상 적 이지 않 습 니 다.
2. Nginx 의 부하 균형
Nginx 의 부하 균형 설정 은 매 뉴 얼 에서 매우 세밀 하 게 설명 되 어 있 으 며, 여 기 는 흐 르 지 않 습 니 다.자주 사용 하 는 HTTP 부하 균형 에 대해 서 는 upstream 을 backend group 으로 정의 한 다음 proxy 를 통 해pass/fastcgi_pass 등 방식 으로 퍼 가기 작업 을 진행 합 니 다. 그 중에서 fastcgi패스 는 거의 Nginx + PHP 사이트 의 레이 블 이 라 고 할 수 있 습 니 다.
2.1 회화 일치 성
Nginx 의 세 션 일치 성 은 sticky 를 통 해 열 립 니 다. 세 션 일치 성과 이전의 부하 균형 알고리즘 사이 에는 충돌 하지 않 습 니 다. 다만 첫 번 째 할당 후 이 세 션 의 모든 요청 이 같은 백 엔 드 에 할당 되 어야 합 니 다.현재 세 가지 모드 의 세 션 일치 성 을 지원 합 니 다. (1) Cookie Insertion 은 백 엔 드 의 첫 번 째 response 이후 에 머리 에 session cookie 를 추가 합 니 다. 그 후에 클 라 이언 트 의 다음 요청 은 이 쿠키 값 을 가지 고 있 습 니 다. Nginx 는 이 쿠키 에 따라 어느 백 엔 드 에 전달 해 야 하 는 지 판단 할 수 있 습 니 다.
1
sticky cookie srv_id expires=1h domain=.example.com path=/;
위의 srvid 는 쿠키 의 이름 을 대표 하 며, 뒤의 인자 expires, domain, path 는 모두 선택 할 수 있 습 니 다.(2). Sticky Routes 도 백 엔 드 의 첫 번 째 response 이후 에 route 정 보 를 생 성 합 니 다. route 정 보 는 보통 쿠키 / URI 정보 에서 추출 합 니 다.
1
sticky route$route_cookie$route_uri;
그러면 Nginx 는 순서대로 $route 를 검색 합 니 다.cookie、$route_uri 매개 변 수 를 선택 하고 첫 번 째 비 어 있 는 매개 변 수 를 route 로 사용 합 니 다. 모든 매개 변수 가 비어 있 으 면 위의 기본 부하 균형 알고리즘 을 사용 하여 어느 backend 에 배포 할 지 결정 합 니 다.(3). Learn 은 비교적 복잡 하고 스마트 하 다. Nginx 는 request 와 response 의 session 정 보 를 자동 으로 모니터링 하고 답장 의 일치 성 이 필요 한 요청, 응답 에 session 정 보 를 포함 하 는데 이것 은 첫 번 째 방식 에 비해 쿠키 를 추가 하지 않 고 기 존의 session 을 동적 으로 학습 하 는 것 이다.이 방식 은 zone 구 조 를 사용 해 야 합 니 다. Nginx 에 서 는 zone 이 공유 메모리 로 여러 worker process 에서 데 이 터 를 공유 할 수 있 습 니 다.(그런데 다른 세 션 의 일치 성 은 왜 공유 메모리 영역 을 사용 하지 않 았 습 니까?)
1
2
3
4
5
sticky learn
create=$upstream_cookie_examplecookie
lookup=$cookie_examplecookie
zone=client_sessions:1m
timeout=1h;
2.2 Session Draining
유지 하거나 업그레이드 할 수 있 도록 일부 백 엔 드 를 닫 아야 합 니 다. 이러한 관건 적 인 서 비 스 는 gracefully 처 리 를 추구 합 니 다. 새로운 요청 은 이 백 엔 드 에 보 내지 않 고 이 백 엔 드 에 배 치 된 세 션 의 후속 요청 은 이 세 션 이 끝 날 때 까지 계속 보 냅 니 다.어떤 backend 를 draining 상태 로 들 어가 게 합 니 다. 설정 파일 을 직접 수정 한 다음 에 이전 방식 으로 master process 에 신 호 를 보 내 설정 을 다시 불 러 올 수도 있 고 Nginx 의 on - the - fly 설정 방식 도 사용 할 수 있 습 니 다.
1
2
$ curl http://localhost/upstream_conf?upstream=backend
$ curl http://localhost/upstream_conf?upstream=backend\&id=1\&drain=1
위의 방식 을 통 해 각 bacnkend 의 ID 번 호 를 먼저 표시 한 다음 drain 에서 ID 의 backend 를 지정 합 니 다.온라인 으로 백 엔 드 를 관측 하 는 모든 세 션 이 완료 되면 이 백 엔 드 는 오프라인 이 된다.
2.3 백 엔 드 건강 모니터링
backend 오류 가 발생 하면 두 개의 인자, maxfails=1 fail_timeout=10s;Nginx 가 backend 에 요청 을 보 내 는 데 실 패 했 거나 응답 을 받 지 못 하면 이 backend 는 다음 10s 에서 사용 할 수 없 는 상태 라 고 생각 합 니 다.주기 적 으로 백 엔 드 에 특별한 요청 을 보 내 고 특별한 응답 을 받 기 를 바 라 며 백 엔 드 가 건강 하고 사용 가능 한 상태 임 을 확인 할 수 있 습 니 다.헬 스 로check 에서 이 설정 을 만 들 수 있 습 니 다.
1
2
3
4
5
6
7
8
9
10
11
match server_ok {
status 200-399;
header Content-Type = text/html;
body !~"maintenance mode";
}
server {
location / {
proxy_pass http://backend;
health_check interval=10 fails=3 passes=2 match=server_ok;
}
}
위의 헬 스check 은 필수 입 니 다. 뒤의 매개 변 수 는 모두 선택 할 수 있 습 니 다.특히 뒤의 match 매개 변 수 는 서버 의 건강 한 조건 을 사용자 정의 할 수 있 습 니 다. 상태 코드, 머리 정보, body 로 돌아 가 는 등 조건 은 & & 관계 입 니 다.기본적으로 Nginx 는 간격 을 두 고 backend group 에 보 냅 니 다. "/"의 요청 은 시간 이 초과 되 거나 2xx / 3xx 가 아 닌 응답 코드 로 되 돌아 오 면 백 엔 드 가 건강 하지 않다 고 생각 되 며, 다음 백 엔 드 가 다시 검 사 를 통과 할 때 까지 요청 을 보 내 는 것 을 중단 합 니 다. health) check 기능 을 사용 할 때 백 엔 드 그룹 에 zone 을 열 어야 합 니 다. 백 엔 드 그룹 설정 을 공유 하 는 동시에 모든 백 엔 드 의 모양 이 필요 합 니 다.태 도 는 모든 worker process 에서 공유 할 수 있 습 니 다. 그렇지 않 으 면 모든 worker process 는 자신의 상태 검사 계수 와 결 과 를 독립 적 으로 저장 합 니 다. 두 가지 상황 은 큰 차이 가 있 을 수 있 습 니 다.
2.4 DNS 를 통 해 HTTP 부하 균형 설정
Nginx 의 backend group 의 호스트 는 도 메 인 이름 형식 으로 설정 할 수 있 습 니 다. 도 메 인 이름 뒤에 resolve 인 자 를 추가 하면 Nginx 는 도 메 인 이름 을 주기 적 으로 해석 합 니 다. 도 메 인 이름 분석 결과 가 바 뀌 었 을 때 다시 시작 하지 않 고 자동 으로 적 용 됩 니 다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
如果域名解析的结果含有多个IP地址，这些IP地址都会保存到配置文件中去，并且这些IP都参与到自动负载均衡。
2.5 TCP/UDP流量的负载均衡
除了专长的HTTP负载均衡，Nginx还支持TCP和UDP流量的负载均衡，适用于LDAP/MySQL/RTMP和DNS/syslog/RADIUS各种应用场景。这类情况的负载均衡使用stream来配置，Nginx编译的时候需要支持–with-stream选项。查看 手册，其配置原理和参数和HTTP负载均衡差不多。
因为TCP、UDP的负载均衡都是针对通用程序的，所以之前HTTP协议支持的match条件(status、header、body)是没法使用的。TCP和UDP的程序可以根据特定的程序，采用send、expect的方式来进行动态健康检测。
2.6 기타 특성 slow start = 30s: 새로 추가 / 복구 한 호스트 가 갑자기 증가 하 는 요청 에 무 너 지 는 것 을 방지 합 니 다. 이 매개 변 수 를 통 해 호스트 의 weight 를 0 부터 설정 값 으로 천천히 증가 시 키 고 부하 가 천천히 증가 하 는 과정 을 방지 할 수 있 습 니 다. max conns = 30: 백 엔 드 의 최 대련 연결 수 를 설정 할 수 있 습 니 다. 이 수 를 초과 할 때 quue 대기 열 에 넣 을 수 있 습 니 다.대기 열의 크기 와 시간 초과 인 자 를 설정 할 수 있 습 니 다. 대기 열의 요청 수가 설정 값 보다 많 거나 timeout 을 초과 하 였 으 나 백 엔 드 가 요청 을 처리 하지 못 하면 클 라 이언 트 는 오 류 를 되 돌려 받 습 니 다. 일반적으로 이것 은 비교적 중요 한 매개 변수 입 니 다. Nginx 가 역방향 에이전트 일 때 는 보통 병발 량 을 막 는 데 사 용 됩 니 다. 백 엔 드 에 너무 많은 것 을 주면의 동시 다발 요청 은 백 엔 드 의 너무 많은 자원 (예 를 들 어 스 레 드, 프로 세 스 비 이벤트 구동) 을 차지 할 수 있 고 결국은 백 엔 드 의 처리 능력 에 영향 을 줄 수 있 습 니 다. 본문 끝! 레 퍼 런 스 부하 균형 |
좋은 웹페이지 즐겨찾기
