특수 업무 에서 haproxy 부하 균형 용 착 과 nginx 부하 균형 용 착 대비

전자상거래 와 포 털 사이트 의 가장 중요 한 요 구 는 안정 적 이 고 백 엔 드 서버 의 건강 모니터링 을 자동 으로 실현 할 수 있 으 며 백 엔 드 서버 가 고장 이 났 을 때 건강 한 서버 로 자동 으로 전환 할 수 있다 는 것 이다.전단 대리 의 우수한 제품 으로서 nginx 는 높 은 안정 과 높 은 가용성 으로 많은 운영 자 들 의 사랑 을 받 았 다. 이 를 이용 하여 자신의 전단 대리 로 사용 하고 nginx 의 대리 설정 을 먼저 설명 한다.
        pcre 플러그 인 을 설치 합 니 다. pcre 는 perl 라 이브 러 리 입 니 다. nginx 는 설정 의 정규 표현 식 을 잘 지원 하기 위해 설치 해 야 합 니 다.
         wget  http://sourceforge.net/projects/pcre/files/pcre/8.32/pcre-8.32.tar.gz/download
         tar zxvfpcre-8.32.tar.gz &&  cd  pcre-8.32
         ./configure   &&    make    &&   make install
        nginx 버 전 을 다운로드 합 니 다. 현재 안정 버 전의 최신 버 전 은 1.2.6. wget 입 니 다.  http://nginx.org/download/nginx-1.2.6.tar.gz 
        압축 풀기, 컴 파일, 설치:
        tar zxvf nginx-1.2.6.tar.gz   
        cd    nginx-1.2.6
        ./configure  --user=www --group=www --prefix=/opt/soft/nginx  --with-http_stub_status_module --with-http_ssl_module --with-pcre=../pcre-8.32 --with-pcre-jit
        nginx 컴 파일 시 nginx 1.2.1 버 전 이상 은 pcre - 8.30 이하 버 전 을 지원 하지 않 으 므 로 컴 파일 할 때 pcre 의 위 치 를 지정 해 야 합 니 다. 그렇지 않 으 면 이러한 오 류 를 보고 할 수 있 습 니 다: ngxregex.c:307: undefined reference to `pcre_free_study'
        컴 파일 완료 후 make   &&  make install  설치
         nginx.conf  파일 설정 은 다음 과 같 습 니 다:  

user  www www;  
    worker_processes 8;  
    error_log  logs/error.log crit;  
      
    pid        logs/nginx.pid;  
      
    worker_rlimit_nofile 51200;  
      
    events   
    {  
            use epoll;  
            worker_connections 51200;  
    }  
      
    http   
    {  
            include       mime.types;  
            default_type  application/octet-stream;  
            
            gzip on;  
            gzip_proxied any;  
            gzip_min_length  1024;  
            gzip_buffers     4 8k;     
            gzip_http_version 1.1;   
            gzip_types       text/plain text/css application/x-javascript application/javascript application/xml;  
      
            keepalive_timeout 120;  
            server_tokens off;  
            tcp_nodelay on;  
      
            client_header_buffer_size 4k;  
            open_file_cache max=51200 inactive=20s;  
            open_file_cache_valid 30s;  
            open_file_cache_min_uses 1;  
      
    upstream  web_test  {  
                  server 192.168.10.2:80;  
                  server 192.168.10.3:80;  
          }  
   log_format  main  '$remote_addr - $remote_user [$time_local] $request '  
                                    '"$status" $body_bytes_sent "$http_referer" '  
                                    '"$http_user_agent" "$http_x_forwarded_for" "$request_time" "$upstream_addr" ';  
                  access_log  /var/log/nginx/master.log main;  
      
          server  
          {  
                  listen  80;  
                  server_name  test.com;  
                  location / {  
                            proxy_next_upstream error timeout invalid_header http_404 http_502 http_503 http_504 http_500;  
                            proxy_pass        http://web_test;  
                            proxy_set_header   Host             $host;  
                            proxy_set_header   X-Real-IP        $remote_addr;  
                            proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;  
                            proxy_connect_timeout 200s;  
                            proxy_read_timeout 200s;  
                            proxy_send_timeout 200s;  
                  }

이렇게 백 엔 드 의 한 server 가 고장 이 났 을 때 404 500 을 보고 합 니 다.  502 503 등 오류 가 발생 하면 자동 용 오 를 실현 하고 두 번 째 server 로 전환 하여 응답 할 수 있 습 니 다.
이것 은 일반적인 상황 에서 부하 균형 이 잘못 되 었 습 니 다. 그 는 백 엔 드 서버 가 사용자 의 요청 에 더 이상 응답 하지 못 하 는 상황 에서 전환 되 었 습 니 다. 우 리 는 일상적인 업무 에서 이러한 상황 을 만 났 습 니 다.
평소에 제3자 의 한 server 에서 데 이 터 를 받 아야 합 니 다. 받 아 온 데 이 터 를 링크 된 형식 으로 사용자 에 게 피드백 하여 사용 해 야 합 니 다. 문 제 는 제3자 의 수신 에 문제 가 있 을 때 데 이 터 를 받 아들 일 수 없 지만 저 희 는 server 에 이상 이 없습니다. 사용자 의 요청 에 평소 대로 응답 합 니 다. 데 이 터 를 받 아들 이지 않 았 기 때문에 사용자 가 본 피드백 결 과 는 비어 있 습 니 다.이렇게 하면 사용자 체험 에 심각 한 영향 을 미 쳤 기 때문에 다음 과 같은 방법 으로 먼저 check 하나의 url 을 사용 하여 제3자 와 의 통신 상황 을 판단 하고 정상 적 이면 두 번 째 피드백 은 사용자 의 데이터 링크 에 정상 적 으로 호출 된다.이상 하면 모든 사용자 요청 을 다음 server 에 전송 합 니 다. 저 는 nginx 를 이용 하여 이 루어 지 려 고 합 니 다. 어 쩔 수 없 이 조작 에 성공 하지 못 했 기 때문에 haproxy 를 사용 하여 이 루어 집 니 다.
wget http://haproxy.1wt.eu/download/1.4/src/haproxy-1.4.8.tar.gz
tar zxvf haproxy-1.4.8.tar.gz   &&    cd haproxy-1.4.8
make TARGET=linux26 PREFIX=/opt/soft/haproxy
make install PREFIX=/opt/soft/haproxy
haproxy 계 정 및 계 정 그룹 을 만 들 고 haproxy 프로 세 스 를 시작 하 는 데 사용 합 니 다.
groupadd haproxy
useradd -g haproxy haproxy
haproxy 설정 은 다음 과 같 습 니 다:

global  
        log 127.0.0.1  local1 notice 
        maxconn 4096  
        chroot /opt/soft/haproxy  
        uid 504 
        gid 504 
        daemon  
        quiet  
        nbproc  2  
        pidfile /opt/soft/haproxy/haproxy.pid  
defaults  
        log     127.0.0.1 local0 err  
        mode    http  
        option  redispatch  
        option  dontlognull
	option  httplog
	timeout connect 10000ms
	timeout client 30000ms
	timeout server 300ms  
        retries 1
	maxconn 20000
listen  test.com.cn     0.0.0.0:8020
        mode    http
        option  forwardfor
        balance source
        cookie  SERVERID
        option  httpchk HEAD /quotedata/cachealert.aspx
        server  server_A 192.168.10.2:80 check inter 1500  weight 10 cookie A
        server  server_B 192.168.10.3:80 check inter 1500  weight 10 cookie B

이렇게 서버A 디 렉 터 리 에 있 는 cachealert. aspx 이 링크 에 문제 가 생 겼 을 때 제3자 의 데 이 터 를 받 을 수 없 음 을 표시 하기 때문에 모든 방문 링크 를 server 로 이동 합 니 다.B 상