클러스터링과 부하 분산 nginx의 차이점
Nginx는 무료 오픈 소스 고성능 서버이자 역방향 프록시 서버 소프트웨어로, 고성능, 안정성 및 풍부한 기능을 갖추고 있어 IMAP 및 POP3 서버의 프록시 역할도 할 수 있습니다. 대부분의 운영자는 간단한 구조와 낮은 자원 소비를 선호합니다.
Nginx는 기존 서버와 달리 요청을 처리하기 위해 스레드에 의존하지 않습니다. 대신, 더 확장 가능한 이벤트 중심 아키텍처(비동기)를 사용합니다. 이 구조는 리소스를 덜 소비하지만 더 중요한 것은 더 큰 요청 로드를 견딜 수 있다는 것입니다. 수천 개의 요청을 처리할 것으로 예상하지 않더라도 Nginx의 고성능, 작은 메모리 공간 및 풍부한 기능의 이점을 누릴 수 있습니다.
Nginx 리버스 프록시:
리버스 프록시는 프록시 서버를 사용하여 인터넷상의 연결 요청을 수락한 다음 해당 요청을 내부 네트워크의 서버로 전달하고, request from the server 획득된 결과는 클라이언트에 대한 연결을 요청하기 위해 인터넷으로 반환됩니다. 이때 프록시 서버는 외부 세계에 서버로 나타나며 이 작업 모드는 LVS-NET 모델과 유사합니다.
리버스 프록시는 웹 서버 가속이라고도 이해할 수 있습니다. 실제 웹 서버의 부하를 줄이기 위해 바쁜 웹 서버와 외부 네트워크 사이에 추가되는 고속 웹 버퍼 서버입니다. 역방향 프록시는 웹 서버의 가속 기능을 향상시키기 위한 것입니다. 서버에 액세스하기 위한 모든 외부 네트워크의 모든 요청은 이를 통과해야 합니다. 이러한 방식으로 역방향 프록시 서버는 클라이언트의 요청을 수신한 다음 그로부터 콘텐츠를 가져오는 역할을 담당합니다. 원본 서버에서 콘텐츠를 사용자에게 반환하고 콘텐츠를 로컬에 저장하므로 나중에 동일한 정보 요청을 받을 때 로컬 캐시에 있는 콘텐츠를 사용자에게 직접 보낼 수 있습니다. 백엔드 웹 서버에 대한 부담을 줄이고 응답 속도를 향상시켰습니다. 따라서 Nginx에는 캐싱 기능도 있습니다.
역방향 프록시의 작업 흐름:
1) 사용자는 도메인 이름을 통해 액세스 요청을 발행하고 도메인 이름은 역방향 프록시 서버의 IP 주소로 확인됩니다.
2) 역방향 프록시 서버는 사용자의 요청을 받습니다;
3) 역방향 프록시 서버는 로컬 캐시를 검색하여 현재 사용자가 요청한 콘텐츠가 존재하는지 확인하고, 발견되면, 콘텐츠를 사용자에게 직접 반환합니다.
4) 사용자가 요청한 콘텐츠를 로컬에서 사용할 수 없는 경우 역방향 프록시 서버는 자체 ID를 사용하여 백엔드 서버에 동일한 정보 콘텐츠를 요청합니다. 정보 콘텐츠를 사용자에게 보냅니다. 정보 콘텐츠를 캐시할 수 있으면 콘텐츠가 프록시 서버의 로컬 캐시에 캐시됩니다.
역방향 프록시의 장점:
1) 웹사이트 서버가 외부에 공개되는 문제를 해결하고 웹사이트 서버의 보안을 강화합니다.
2) 비용 절감 제한된 IP 주소 자원으로 백엔드 서버는 개인 IP 주소를 사용하여 프록시 서버와 통신할 수 있습니다.
3) 웹사이트의 액세스 속도를 높이고 실제 웹 서버의 부하를 줄입니다. .
(1) 스케줄링 알고리즘
Nginx의 업스트림 명령어는 Proxy_pass와 fastcgi_pass가 사용하는 백엔드 서버, 즉 nginx의 역방향 프록시 기능을 지정하는 데 사용되므로 두 가지를 조합하여 로드 밸런싱을 달성할 수 있으며 Nginx는 다양한 스케줄링 알고리즘도 지원합니다.
1. 폴링(기본값)
각 요청은 서로 다른 서버에 할당됩니다. 백엔드 서버가 다운되면 해당 서버는 건너뛰고 다음 모니터링 서버에 할당됩니다. 그리고 현재의 모든 연결 상태를 기록할 필요가 없으므로 상태 비저장 스케줄링입니다.
2. 가중치
폴링을 기준으로 가중치를 추가하도록 지정합니다. 가중치는 백엔드 서버의 성능을 나타내는 데 사용되는 비율에 비례합니다. 백엔드 서버 성능이 좋으면 대부분의 요청을 서버에 할당하여 할 수 있는 일을 달성할 수 있습니다.
예:
내 백엔드 서버 172.23.136.148 구성: E5520*2 CPU, 8G 메모리
백엔드 서버 172.23.136.148 구성: Xeon(TM ) 2.80GHz * 2, 4G 메모리
프런트 엔드에 30개의 요청이 도착하면 그 중 20개는 처리를 위해 172.23.136.148로 넘겨지고 나머지 10개의 요청은 로 넘겨지길 바랍니다. 처리를 위해 172.23.136.149를 다음과 같이 구성합니다.
upstream web_poll {
server 172.23.136.148 Weight=10;
server 172.23.136.149 Weight=5;
}
3. ip_hash
각 요청은 액세스 IP의 해시 결과에 따라 할당됩니다. 새로운 요청이 도착하면 클라이언트 IP가 먼저 할당됩니다. 해시 알고리즘을 통해 해시된 값은 후속 요청의 클라이언트 IP 해시 값이 동일하면 동일한 백엔드 서버에 할당됩니다. 이 스케줄링 알고리즘은 세션 문제를 해결할 수 있지만 때로는 이로 인해 발생합니다. 고르지 못한 분포로 인해 로드 밸런스를 보장할 수 없습니다.
예:
업스트림 web_pool {
ip_hash;
서버 172.23.136.148:80;
server 172.23.136.149: 80;
}
4. 공정(타사)
백엔드 서버의 응답 시간에 따라 요청을 할당합니다. 응답 시간이 짧습니다. 우선순위 할당.
업스트림 web_pool {
서버 172.23.136.148
서버 172.23.136.149
공정; }
5. url_hash(타사)
접근한 URL의 해시 결과에 따라 요청을 배포하여 각 URL이 동일한 백엔드 서버로 연결되도록 합니다. 백엔드 서버가 캐시되어 더 효과적입니다.
예: 업스트림에 해시 문을 추가합니다. 가중치와 같은 다른 매개변수는 서버 문에 쓸 수 없습니다. hash_method는 사용되는 해시 알고리즘입니다.
upstream web_pool {
서버 오징어1: 3128;
서버 오징어2:
hash $request_uri;
hash_method crc32; p >
각 장치의 상태는 다음과 같이 설정됩니다.
1.down은 현재 서버가 로드에 참여하지 않고 ip_hash에서 사용됨을 의미합니다.
2.weight 기본값은 1입니다. 무게가 초과됩니다. 크기가 클수록 하중의 무게도 커집니다.
3.max_fails 허용되는 요청 실패의 기본 횟수는 1입니다. 0으로 설정하면 이 기능이 꺼지는 것을 의미합니다. 최대 횟수를 초과하면 Proxy_next_upstream 모듈에서 정의한 오류가 반환됩니다.
4.fail_timeout은 max_fails에 정의된 실패 횟수 이후에 일시 중지되는 시간입니다.
5. 백업은 백업이 아닌 다른 모든 시스템이 작동 중지되거나 사용 중일 때 백업 시스템에 할당됩니다. 따라서 이 기계의 압력은 가장 낮습니다.
nginx는 사용되지 않는 서버에서 사용할 수 있도록 여러 그룹의 로드 밸런싱을 동시에 설정하는 것을 지원합니다.
(2) 지침 사용
1. 업스트림
proxy_pass 및 fastcgi_pass에서 참조할 수 있는 서버 그룹을 선언합니다. , Unix 소켓을 사용할 수도 있습니다. 서버에 대해 다른 가중치를 지정할 수도 있습니다. 예:
upstream web_pool {
server coolinuz.9966.org Weight=5;
server 172.23.136.148: 8080 max_fails=3 fall_timeout=30s;
서버 unix:/tmp/backend3;
}
2. 서버
구문: 서버 이름 [매개변수]
이름은 FQDN, 호스트 주소, 포트 또는 Unix 소켓일 수 있습니다. FQDN 확인 결과가 여러 주소인 경우 각 주소가 사용됩니다.
3. Proxy_pass
구문: Proxy_pass URL;
이 지시어는 프록시 서버의 주소와 URL이 연결될 URL 또는 주소와 포트를 지정하는 데 사용됩니다. 매핑됩니다. 즉, 백엔드 서버의 주소나 URL[포트]를 지정하는 데 사용됩니다.
4.proxy_set_header
구문: Proxy_set_header 헤더 값;
이 지시문을 사용하면 프록시 서버로 전송될 일부 요청 헤더 정보를 재정의하고 추가할 수 있습니다.
예:
proxy_set_header 호스트 $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded- $proxy_add_x_forwarded_for;
참고: $proxy_add_x_forwarded_for에는 클라이언트 요청 헤더에 "X-Forwarded-For"가 포함되어 있으며 "X-Forwarded-For" 요청이 없는 경우 $remote_addr에서 쉼표로 구분됩니다. 헤더이면 $ Proxy_add_x_forwarded_for는 $remote_addr과 같습니다.
그런데 Nginx의 내장 변수를 추가하세요:
$args, 요청의 매개변수;
$is_args, $args가 설정된 경우 이 변수의 값은 "?"이고, 그렇지 않으면 ""입니다.
$content_length, HTTP 요청 헤더의 "Content-Length";
$content_type, 요청 헤더의 "Content-Type";
$document_root , 현재 요청이 속한 루트 지시문에 대해 설정된 루트 디렉터리 경로;
$document_uri, $uri와 동일;
$host, 요청의 "호스트" 정보, 요청에 Host 라인이 없는 경우 설정된 서버 이름과 같습니다.
$limit_rate, 연결 속도 제한;
$request_method, "GET", "POST" "등과 같은 요청 메소드;
$remote_addr, 클라이언트 주소;
$remote_port, 클라이언트 포트 번호;
$remote_user, 인증에 사용되는 클라이언트 사용자 이름
$request_filename, 현재 요청의 파일 경로 이름
$request_body_file, 클라이언트 요청 본문의 임시 파일 이름.
$request_uri, 매개변수 포함
$query_string, $args와 동일
$scheme, $1 리다이렉트;
$server_protocol, 요청된 프로토콜 버전, "HTTP/1.0" 또는 "HTTP/1.1"
$server_addr, 서버 주소가 지정되지 않은 경우; 수신 대기와 함께 다음을 사용하십시오. 이 변수는 주소를 얻기 위해 시스템 호출을 시작합니다(결과적으로 리소스 낭비 발생).
$server_name, 요청이 도착하는 서버의 이름;
$server_port는 요청이 도착하는 서버의 포트 번호입니다.
p>
요청된 URI인 $uri는 리디렉션 이후와 같이 원래 값과 다를 수 있습니다.
5.proxy_read_timeout
구문: Proxy_read_timeout time;
이 명령은 백엔드 서버와 연결을 설정한 후 Nginx를 설정합니다. 백엔드 서버의 응답 시간을 기다립니다.
6.proxy_send_timeout
구문: Proxy_send_timeout time;
이 명령은 요청을 백엔드로 전송하는 데 걸리는 시간 제한을 지정합니다. 섬기는 사람. 전체 전송에는 제한 시간 이상이 필요하지 않지만 두 쓰기 작업 사이에만 필요합니다. 이 시간 이후에 백엔드 서버가 새 데이터를 가져오지 않으면 nginx는 연결을 닫습니다.
7.proxy_connect_timeout
구문: Proxy_connect_timeout time;
이 명령은 백엔드 서버에 할당된 연결 시간 제한을 설정하는 데 사용됩니다.
8.proxy_buffers
구문: Proxy_buffers the_number is_size;
이 명령은 버퍼 수와 크기를 설정합니다. 기본적으로 버퍼 하나의 크기는 다음과 같습니다. 페이지 크기.
9.proxy_buffer_size
구문: Proxy_buffer_size buffer_size;
프록시 버퍼, 이 명령은 사용자의 헤더 정보를 저장하는 데 사용됩니다.
10.proxy_busy_buffers_size
구문: Proxy_busy_buffers_size;
시스템 부하가 심하고 버퍼가 충분하지 않을 때 사용되며 더 큰 Proxy_buffers를 신청할 수 있습니다.
p>11.proxy_temp_file_write_size
구문: Proxy_temp_file_write_size size;
캐시된 임시 파일의 크기를 지정하는 데 사용됩니다.
(3), 전체 기능
p>
업스트림에서 백엔드 웹 서버의 상태 감지를 구현하기 위해 타사 모듈을 설치 및 구성합니다.
모듈 다운로드 주소: /cep21/ healthcheck_nginx_upstreams; 모듈 이름: ngx_http_healthcheck_module
설치 및 구성 방법:
1. 먼저 특정 경로에 healthcheck 모듈의 압축을 풉니다. 여기서는 /tmp/healthcheck_nginx_upstreams로 가정합니다.
#tar -xvf cep21-healthcheck_nginx_upstreams-16d6ae7.tar.gz -C /tmp/healthcheck_nginx_upstreams
2. nginx를 패치합니다.
먼저 nginx의 압축을 풀고 nginx 소스 코드 디렉터리를 입력합니다.
# tar xf nginx-1.3.4.tar.gz
# cd nginx-1.0.11
# patch -p1 lt /tmp/healthcheck_nginx_upstreams /nginx.patch
그런 다음 nginx를 컴파일하고 구성을 실행할 때 다음과 유사한 옵션을 추가합니다:
--add-module=/tmp/healthcheck_nginx_upstreams
그래서 , 여기에서 다음 명령을 사용하십시오:
# ./configure \
--prefix=/usr/local/nginx \
--sbin-path= /usr/sbin/nginx \
--conf-path=/etc/nginx/nginx.conf \
--lock-path=/var/lock/nginx.lock \
--user=nginx \
--group=nginx \
--with-http_ssl_module \
--with -http_flv_module \
--with- http_stub_status_module \
--with-http_gzip_static_module \
--http-proxy-temp-path=/var/tmp /nginx/proxy/ \
- -http-fastcgi-temp-path=/var/tmp/nginx/fcgi/ \
--with-pcre \
--add-module=/tmp/healthcheck_nginx_upstreams
# make amp;
ngx_http_healthcheck_module 모듈 사용 방법:
1. 이 모듈에서 지원되는 명령은 다음과 같습니다:
healthcheck_enabled
##이를 활성화합니다. 모듈
healthcheck_delay
##동일한 백엔드 서버에서 두 확인 사이의 시간 간격(밀리초), 기본값은 1000입니다.
healthcheck_timeout
##상태 확인 시간 초과(밀리초), 기본값은 2000입니다.
healthcheck_failcount
##백엔드 서버가 성공하거나 실패한 횟수 테스트를 거쳐야 성공/실패 여부를 확인할 수 있으며, 서버를 활성화 또는 비활성화할 수 있습니다.
healthcheck_send
##의 상태를 감지하기 위해 감지 요청이 전송됩니다. 백엔드 서버, 예: healthcheck_send "GET /health HTTP/1.0" 'Host: coolinuz.9966.org';
healthcheck_expected
##에서 수신된 예상 응답 콘텐츠 백엔드 서버; 설정되지 않은 경우 백엔드 서버로부터 수신된 200 상태 코드가 올바른 것입니다.
healthcheck_buffer
##사용되는 버퍼 공간의 크기 health status check;
healthcheck_status
stub_status와 유사한 방식으로 탐지 정보를 출력합니다. 사용 방법은 다음과 같습니다.
location /stat {
healthcheck_status;
}
(4), 구성 및 구현
구성 코드는 다음과 같습니다.
http {
업스트림 web_pool {
서버 172.23.136.148: 80 가중치=10;
서버 172.23.136.149: 80 가중치=5; p> healthcheck_enabled;
healthcheck_delay 1000;
healthcheck_timeout 1000
healthcheck_failcount 2
healthcheck_send "GET /.health HTTP/1.0 ";
}
서버 {
수신 80;
위치 / {
Proxy_set_header 호스트 $http_host ;
Proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
Proxy_pass http://web_pool;
proxy_connect_timeout 3;
}
위치 /
stat {
healthcheck_status;
}
}
}
여기서 "proxy_set_header" 매개변수를 설정하세요. 왜냐하면 Nginx가 역방향 프록시를 수행할 때 클라이언트를 대신하여 서버에 접속해야 하기 때문입니다. 따라서 요청 패킷이 역방향 프록시를 통과하면 IP 패킷의 IP 헤더가 프록시 서버에서 수정되고, 마지막으로 백엔드 웹 서버 획득한 데이터 패킷의 헤더에 있는 소스 IP 주소는 프록시 서버의 IP 주소입니다. 이 경우 백엔드 서버 프로그램에서 제공하는 IP의 통계 기능은 의미가 없습니다. 백엔드 웹 서버 호스트에 도메인 이름을 기반으로 하는 가상 IP 주소가 여러 개 있는 경우, 백엔드 웹 서버가 어떤 가상 IP 주소를 식별할 수 있도록 헤더 헤더 정보 호스트를 추가하여 요청의 도메인 이름을 지정해야 합니다. 호스트는 역방향 프록시 액세스 요청을 처리합니다.
(5) 요약
위를 통해 Nginx의 구성은 실제로 다른 웹 서버 소프트웨어에 비해 상대적으로 간단하지만 구현되는 기능은 실제로 상당히 강력하고 풍부하다. Nginx의 역방향 프록시는 이미 유연한 정규식 일치를 지원하여 동적 웹사이트와 정적 웹사이트의 분리를 실현하고 동적 PHP 및 기타 프로그램 웹페이지가 PHP 웹 서버에 액세스할 수 있도록 하며 캐시된 페이지, 그림, 자바스크립트, CSS 및 기타 프로그램을 허용합니다. 플래시를 사용하여 캐시 서버나 Squid 등의 파일 서버에 액세스할 수 있습니다. Nginx의 고성능 및 정적 콘텐츠에 대한 높은 동시성과 결합하여 프런트 엔드 프록시 로드 밸런싱으로서의 Nginx는 점점 더 많은 설계자를 위한 첫 번째 솔루션이 되었습니다.