nginx 역방향 에이전트, 부하 균형 및 동정 분리

리버스 에이전트

정방향 에이전트와 역방향 에이전트

정방향 프록시는 클라이언트와 대상 서버 사이에 있는 프록시 서버 (중간 서버) 입니다.원본 서버에서 내용을 얻기 위해 클라이언트는 프록시 서버에 요청을 보내고 대상 서버를 지정한 후에 프록시가 대상 서버에 전달하고 얻은 내용을 클라이언트에게 되돌려줍니다.역방향 프록시 실제 실행 방식은 프록시 서버로 인터넷의 연결 요청을 받아들인 다음에 요청을 내부 네트워크의 서버에 전송하고 서버에서 얻은 결과를 인터넷에서 연결을 요청한 클라이언트에게 되돌려주는 것을 말한다. 이때 프록시 서버는 외부에 하나의 서버로 나타난다.역방향 프록시 작업은 서비스 기간의 전단에서 프록시 서버로서 프록시 작업은 클라이언트의 전단에서 클라이언트를 위해 프록시를 하고 있다.

리버스 에이전트 역할

내망의 안전을 확보하고 대형 사이트는 보통 역방향 에이전트를 공망 방문 주소로 하고 웹 서버는 내망이다

역방향 에이전트를 통해 부하 균형을 실현하고 역방향 에이전트 서버를 통해 사이트의 부하를 최적화할 수 있다

리버스 프록시 예

환경

192.168.0.168   (nginx)
192.168.0.52    (httpd)  

nginx 프록시 설정 수정

location /wanger {
            proxy_pass http://192.168.0.52;
            proxy_set_header   Host             $host;
            proxy_set_header   X-Real-IP        $remote_addr;
            proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
        }

백엔드 192.168.0.52/wanger 첫 페이지 추가

mkdir /var/www/html/wanger
echo 192.168.0.52 > /var/www/html/wanger/index.html

프런트엔드 서버에서 액세스 테스트 수행

클라이언트가 192.168.0.168/wanger/에 접근하면 요청을 백엔드 192.168.0.52/wanger/index에 전달합니다.html

[[email protected]]# curl 127.0.0.1/wanger/
192.168.0.52

역방향 프록시 테스트 성공 보실 수 있습니다.

proxy_set_헤더 명령 해석

proxy_set_header 명령은 nginx를 백엔드 서버의 헤더에 보내는 상술한 설정에서 헤더를 요청하는 Host 필드를 $host 변수로 설정합니다.X-Real-IP 필드를 $remote_로 설정adde 변수, 즉 클라이언트의 실제 ip는 X-Forwarded-For 필드를 $proxy_add_x_forwarded_for 변수, $proxy_add_x_forwarded_for는 ngx_http_proxy_모듈 내장 변수

proxy_add_x_forwarded_for 변수

proxy_add_x_forwarded_for 변수에는 X-Forward-For 필드와 remote_adr 변수, 그리고 쉼표로 구분합니다. X-Forwarded-For 필드가 존재하지 않을 때 $proxy_add_x_forwarded_for 변수 $remote_addr 변수, 한 웹 응용 프로그램이 두 개의 nginx 프록시 서버에 전송될 때, 첫 번째 nginx 프록시의 X-Forwarded-For 필드는 실제 클라이언트 IP이고, 두 번째 nginx 프록시의 X-Forwarded-For 필드는 클라이언트 IP이며, 첫 번째 프록시의 IP 주소입니다. 즉, 프록시 서버의 수가 1보다 많을 때만proxy_add_x_forwarded_for 가 효과가 있어요.

백엔드 웹 로그 형식 수정

우선 백엔드에 접근하는 로그를 보십시오. IP에 접근하는 것이nginx 에이전트의 IP인지 볼 수 있습니다.
httpd 로그 형식을 수정하고 로그의 ip를 클라이언트 ip로 수정합니다

vim /etc/httpd/conf/httpd.conf
LogFormat "%{X-Real-IP}i %{Host}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined

수정된 로그 형식은 다음과 같습니다.
그러면 백엔드 서버에 실제 클라이언트 IP가 표시됩니다.

proxy_pass 더하기/의 차이

프록시_pass는 뒤에 있는 URL에/를 추가했습니다. 절대 루트 경로에 해당하면nginx는location에서 일치하는 경로 부분을 에이전트하지 않습니다.만약/이 없다면, 일치하는 경로 부분도 에이전트에게 줄 것이다

예제

location /wanger {
            proxy_pass http://192.168.0.52;
        }

이 때 백엔드의 URL은 192.168.0.52/wanger/index입니다.html

location /wanger {
            proxy_pass http://192.168.0.52;
        }

이 때 백엔드의 URL은 192.168.0.52/index입니다.html

부하 균형

부하 균형은 요청 전단의 요청을 백엔드의 여러 노드에 분담하여 시스템의 응답과 처리 능력을 향상시킬 수 있다.

환경

192.168.0.168    
192.168.0.52   1
192.168.0.84    2  

부하 균형 스케줄링 정책

weight 폴링 (기본값)

요청을 시간 순서에 따라 백엔드 서버에 분배합니다. weight를 통해 윤문권의 무게를 정의할 수 있습니다. 권중이 높을수록 접근 확률이 높습니다.

upstream read{
        server 192.168.0.52 weight=2 max_fails=3 fail_timeout=20s;
        server 192.168.0.84:8080 weight=1 max_fails=3 fail_timeout=20s;
        server 192.168.0.96 down;
        server 192.168.0.168  backup;
}

max_fails, fail_ 허용timeout 시간 내에 요청이 실패한 최대 횟수입니다. 그렇지 않으면 백엔드 서버가 사용할 수 없음으로 표시됩니다

fail_timeout, 오류 횟수의 시간 초과 표시;사용할 수 없음으로 표시된 후 서비스를 일시 중지하는 시간..

down, 현재 서버를 사용할 수 없음, 즉 부하 균형에 참여하지 않음으로 표시합니다..

백업은 예비 서버로 표시되며, 모든 비백업 서버를 사용할 수 없거나 바쁠 때 요청합니다..

요청 결과는 다음과 같습니다.

ip_hash

요청을 IP에 접근하는hash 결과에 따라 백엔드 서버에 분배합니다. 이렇게 하면 같은 IP가 요청할 때마다 같은 백엔드 서버에 접근할 수 있고 동적 웹 페이지의session 문제를 해결할 수 있습니다.

upstream read{
        ip_hash
        server 192.168.0.52;
        server 192.168.0.84:8080;
}

요청 결과는 다음과 같습니다.

최소 연결(least_conn)

백엔드 서버의 현재 연결 상황에 따라 현재 연결 수가 가장 적은 백엔드 서버에 요청을 할당합니다

upstream read{
        least_conn;
        server 192.168.0.52;
        server 192.168.0.84:8080;
}  

요청 결과는 다음과 같습니다.

fair

응답 시간이 짧은 백엔드 서버에 요청 할당

upstream read{
        fair;
        server 192.168.0.52;
        server 192.168.0.84:8080;
}

url_hash

URL에 접근하는hash 결과에 따라 요청을 분배하여 모든 URL을 같은 백엔드 서버로 지정하면 백엔드 캐시 서버의 효율을 더욱 높일 수 있다

upstream read{
        hash $request_uri;
        server 192.168.0.52;
        server 192.168.0.84:8080;
}

동정 분리

왜 동정 분리를 해요?

Nginx의 정적 처리 능력은 매우 강하지만 동적 처리 능력이 부족하고 동정이 분리된 후에 정적 자원에 대한 캐시 조작이 편리하며 사이트의 응답 속도를 높인다

동적 분리 구성

upstream static{
        server 192.168.0.52 weight=2 max_fails=3 fail_timeout=20s;     
}
upstream dynamic{
        server 192.168.0.168:9200  weight=2 max_fails=3 fail_timeout=20s;
}
server {
     listen 80;
     server_name localhost;
    location ~* \.php$ {              
                fastcgi_pass http://dynamic;
                fastcgi_index index.php;  
                fastcgi_param  SCRIPT_FILENAME  /usr/share/nginx/html$fastcgi_script_name;
                include fastcgi_params;
        }
    location ~* \.(jpg|gif|png|css|html|htm|js)$ {  
                proxy_pass http://static; 
                expires 12h;   
}   

개인 위챗 공중번호'이야기 없는 진사부'에 관심을 가지신 것을 환영합니다.