Nginx 부하 균형 설정 실례 상세 설명

[안내] 부하 균형 은 저희 빅 데이터 사이트 에서 해 야 할 일 입 니 다. 다음은 Nginx 서버 에서 부하 균형 설정 방법 을 소개 하 겠 습 니 다. 필요 한 학생 들 에 게 도움 이 되 었 으 면 좋 겠 습 니 다.부하 균형 은 먼저 부하 균형 이 무엇 인지 간단히 알 아 보고, 글자 그대로 이해 하면 풀 수 있다.
부하 균형

먼저 부하 균형 이 무엇 인지 간단히 알 아 보 겠 습 니 다. 말 그대로 N 대 서버 가 평균 적 으로 부 하 를 분담 하고 특정한 서버 부하 가 지연 되 어 특정한 서버 가 방치 되 지 않 는 상황 을 설명 할 수 있 습 니 다.그러면 부하 균형 의 전 제 는 여러 대의 서버 가 있어 야 이 루어 질 수 있다 는 것 이다. 즉, 두 대 이상 이면 된다.

부하 균형 은 기 존의 네트워크 구조 위 에 세 워 졌 고 저렴 하고 효과 적 이 며 투명 한 방법 으로 네트워크 설비 와 서버 의 대역 폭 을 확대 하고 스루풋 을 증가 하 며 네트워크 데이터 처리 능력 을 강화 하 며 네트워크 의 유연성 과 가용성 을 향상 시 켰 다.

프 록 시 서버 를 사 용 했 을 때 일반 프 록 시 서버 뒤 에는 원본 서버 한 대 만 있 는 것 이 아니 라 여러 대의 서버 가 사용자 가 보 낸 요청 을 함께 처리 하고 있 습 니 다. 이때 여러 대의 서버 가 어떻게 합작 하여 사용 자 를 공동으로 처리 하 는 지 조율 해 야 합 니 다

모든 원본 서버 설정 의 차이 가 크 지 않 을 경우 부하 균형 수단 은 일반적으로 폴 링 입 니 다. 즉, 모든 서버 가 사용자 의 요 구 를 평등 하 게 처리 하고 요청 이 올 때 현재 담당 업무 가 가장 적은 서버 에 자동 으로 전 달 됩 니 다.

원본 서버 의 설정 에 어느 정도 차이 가 있 을 경우 가중 폴 링 방식 으로 좋 은 서버 를 설정 하면 더 많은 요청 처 리 를 책임 지고 반대로 도 마찬가지 입 니 다.

폴 링 방식 을 사용 하면 session 공유 문 제 를 고려 해 야 합 니 다. 사용자 의 요청 이 서로 다른 서버 에 할당 되 어 session 공 유 를 실현 하지 못 하면 사용자 가 로그 인 작업 을 반복 해 야 합 니 다. 현재 session 공 유 를 실현 하 는 방식 은 데이터 베 이 스 를 기록 하거나 memcached 를 기록 하 는 것 입 니 다.

session 공 유 를 처리 하지 않 으 려 면 ip 해시 방식 으로 한 사용자 의 요청 을 특정한 서버 에 지정 하고 설정 에 ip 를 추가 합 니 다.hash 이 말 만 하면 됩 니 다.

다음은 내 가 다른 곳 에서 찾 은 부하 균형 상용 방식 이다.

무 작위: 부하 균형 방법 은 무 작위 로 각 사용 가능 한 서버 에 부 하 를 분배 하고 무 작위 생 성 알고리즘 을 통 해 서버 를 선택 한 다음 에 연결 을 보 냅 니 다.많은 균형 제품 들 이 이 알고리즘 을 지원 하지만 서버 의 실행 가능 시간 을 심각하게 보지 않 는 한 유효성 에 의문 을 받 고 있다.

폴 링: 폴 링 알고리즘 은 순서대로 모든 새로운 연결 요 구 를 다음 서버 에 배정 하고 최종 적 으로 모든 요 구 를 모든 서버 에 똑 같이 나 누 어 줍 니 다.폴 링 알고리즘 은 대부분 상황 에서 잘 작 동 하지만 부하 가 균형 잡 힌 장치 가 처리 속도, 연결 속도, 메모리 등에 서 완전히 균등 하지 않 으 면 효과 가 더욱 좋 을 것 이다.

가중 폴 링: 이 알고리즘 에서 모든 기계 가 받 아들 이 는 연결 수량 은 가중치 비례 에 따라 분배 된다.이것 은 일반 폴 링 알고리즘 에 대한 개선 이다. 예 를 들 어 세 번 째 기계 의 처리 능력 은 첫 번 째 기계 의 두 배 이 고 부하 이퀄 라이저 는 두 배의 연결 수량 을 세 번 째 기계 에 배분 할 것 이다.

동적 폴 링: 가중 폴 링 과 유사 하지만 가중치 는 각 서버 에 대한 지속 적 인 감 시 를 바탕 으로 계속 업데이트 된다.이것 은 동적 부하 균형 알고리즘 으로 서버 의 실시 간 성능 분석 을 바탕 으로 연결 을 분배 한다. 예 를 들 어 각 노드 의 현재 연결 수 나 노드 의 가장 빠 른 응답 시간 등 이다.

가장 빠 른 알고리즘: 가장 빠 른 알고리즘 은 모든 서버 에서 가장 빠 른 응답 시간 을 바탕 으로 연결 을 분배 합 니 다.이 알고리즘 은 서버 가 서로 다른 네트워크 를 뛰 어 넘 는 환경 에서 특히 유용 하 다.

최소 연결: 시스템 은 현재 연결 수가 가장 적은 서버 에 새 연결 을 분배 합 니 다.이 알고리즘 은 각 서버 의 연산 능력 이 기본적으로 비슷 한 환경 에서 매우 효과적이다.

관찰 알고리즘: 이 알고리즘 은 최소 연결 알고리즘 과 가장 빠 른 알고리즘 을 동시에 이용 하여 부하 균형 을 실시한다.서버 는 현재 연결 수 와 응답 시간 에 따라 점 수 를 받 습 니 다. 점수 가 높 으 면 성능 이 좋 고 더 많은 연결 을 얻 을 수 있 습 니 다.

예 판 알고리즘: 이 알고리즘 은 관찰 알고리즘 을 사용 하여 점 수 를 계산 하지만 예 판 알고리즘 은 점수의 변화 추 세 를 분석 하여 모 서버 의 성능 이 개선 되 고 있 는 지 낮 아 지고 있 는 지 판단 한다.개선 추 세 를 보 이 는 서버 는 더 많은 연결 을 받 을 수 있다.이 알고리즘 은 대부분의 환경 에 적용 된다.

테스트 환경:
서버 가 없 기 때문에 이번 테스트 는 도 메 인 이름 을 host 에서 직접 지정 한 다음 에 VMware 에 CentOS 세 대 를 설치 했다.
테스트 도 메 인 이름: a. com
A 서버 IP: 192.168.5.149 (주)
B 서버 IP: 192.168.5.27
C 서버 IP: 192.168.5.126
배포 방향:
A 서버 는 주 서버 로 도 메 인 이름 은 A 서버 (192.168.5.149) 에 직접 분석 되 고 A 서버 부하 에서 B 서버 (192.168.5.27) 와 C 서버 (192.168.5.126) 에 균형 을 맞춘다.
도 메 인 이름 분석:
실제 환경 이 아니 기 때문에 도 메 인 이름 은 a. com 을 테스트 용 으로 마음대로 사용 하기 때문에 a. com 의 분석 은 hosts 파일 에서 만 설정 할 수 있 습 니 다.
열기: C: Windows System 32 driversetchosts
끝 에 추가:

192.168.5.149    a.com

종료 저장 하고 명령 모드 ping 을 시작 하여 설정 이 완료 되 었 는 지 확인 하 십시오.
캡 처 에서 a. com 을 192.168.5.149IP 로 성공 적 으로 분 석 했 습 니 다.
A 서버 nginx. conf 설정 은 nginx. conf 를 엽 니 다. 파일 위 치 는 nginx 설치 디 렉 터 리 의 conf 디 렉 터 리 에 있 습 니 다.
http 세그먼트 에 다음 코드 를 추가 합 니 다:

upstream a.com { 
      server  192.168.5.126:80; 
      server  192.168.5.27:80; 
} 

server{ 
    listen 80; 
    server_name a.com; 
    location / { 
        proxy_pass         http://a.com; 
        proxy_set_header   Host             $host; 
        proxy_set_header   X-Real-IP        $remote_addr; 
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for; 
    } 
}

다시 시작 nginx 저장
B. C 서버 nginx. conf 설정:
nginx. confi 를 열 고 http 세그먼트 에 다음 코드 를 추가 합 니 다.

server{ 
    listen 80; 
    server_name a.com; 
    index index.html; 
    root /data0/htdocs/www; 
}

    nginx

테스트
a. com 을 방문 할 때 어느 서버 로 전환 하 는 지 구분 하기 위해 저 는 각각 B, C 서버 에 서로 다른 내용 의 index. html 파일 을 써 서 구분 합 니 다.
브 라 우 저 를 열 어 a. com 을 방문 한 결과 새로 고침 하면 모든 요청 이 주 서버 (192.168.5.149) 에 B 서버 (192.168.5.27) 와 C 서버 (192.168.5.126) 에 각각 할당 되 어 부하 균형 효 과 를 실현 한 것 을 발견 할 수 있 습 니 다.
B 서버 처리 페이지
C 서버 처리 페이지
만약 그 중 한 대의 서버 가 다운 되면 어떻게 됩 니까?
어떤 서버 가 다운 되 었 을 때 방문 에 영향 을 줄 수 있 습 니까?
우 리 는 먼저 실례 를 살 펴 보 겠 습 니 다. 상기 예 에 따라 C 서버 192.168.5.126 이 컴퓨터 가 다운 되 었 다 고 가정 한 다음 에 다시 방문 해 보 겠 습 니 다.
접근 결과:
우 리 는 C 서버 (192.168.5.126) 가 다운 되 었 지만 사이트 방문 에 영향 을 주지 않 는 다 는 것 을 발견 했다.이렇게 되면 부하 균형 모드 에서 어떤 기계 가 다운 되 어 역 전 체 를 끌 까 봐 걱정 하지 않 을 것 이다.
만약 b. com 도 부하 균형 을 설정 하려 면 어떻게 합 니까?
아주 간단 합 니 다. a. com 설정 과 같 습 니 다.다음 과 같다.
b. com 의 메 인 서버 IP 가 192.168.5.149 라 고 가정 하면 부하 균형 은 192.168.5.150 과 192.168.5.151 기계 에 있다.
현재 도 메 인 이름 b. com 을 192.168.5.149IP 로 분석 합 니 다.
홈 서버 (192.168.5.149) 의 ngix. conf 에 다음 코드 를 추가 합 니 다:

upstream b.com { 
      server  192.168.5.150:80; 
      server  192.168.5.151:80; 
} 

server{ 
    listen 80; 
    server_name b.com; 
    location / { 
        proxy_pass         http://b.com; 
        proxy_set_header   Host             $host; 
        proxy_set_header   X-Real-IP        $remote_addr; 
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for; 
    } 
}

다시 시작 nginx 저장
192.168.5.150 과 192.168.5.151 기계 에 nginx 를 설치 하고 nginx. conf 를 열 어 끝 에 다음 과 같은 코드 를 추가 합 니 다.

server{ 
    listen 80; 
    server_name b.com; 
    index index.html; 
    root /data0/htdocs/www; 
}

다시 시작 nginx 저장
이후 절 차 를 마 친 후 b. com 의 부하 균형 설정 을 실현 할 수 있 습 니 다.
홈 서버 는 서 비 스 를 제공 할 수 없 습 니까?
상기 예 에서 우 리 는 모두 메 인 서버 부하 가 다른 서버 에 균형 을 이 루 도록 응용 되 었 다. 그러면 메 인 서버 자체 도 서버 목록 에 추가 할 수 있 습 니까? 그러면 서버 한 대 를 퍼 가기 기능 으로 만 낭비 하지 않 고 서비스 제공 에 도 참여 할 수 있 습 니 다.
상기 사례 와 같이 세 대의 서버:
A 서버 IP: 192.168.5.149 (주)
B 서버 IP: 192.168.5.27
C 서버 IP: 192.168.5.126
우 리 는 도 메 인 이름 을 A 서버 로 분석 한 후에 A 서버 에서 B 서버 와 C 서버 로 전송 합 니 다. 그러면 A 서버 는 하나의 퍼 가기 기능 만 합 니 다. 지금 은 A 서버 에 도 사이트 서 비 스 를 제공 하도록 합 니 다.
upstream 에 메 인 서버 를 추가 하면 다음 과 같은 두 가지 상황 이 발생 할 수 있 습 니 다.
1. 메 인 서버 가 다른 IP 에 전송 되 었 고 다른 IP 서버 는 정상적으로 처리 되 었 습 니 다.
2. 메 인 서버 는 자신의 IP 에 전송 한 다음 에 메 인 서버 에 들 어가 IP 를 분배 합 니 다. 만약 에 이 컴퓨터 에 계속 분배 하면 순환 이 생 길 수 있 습 니 다.
이 문 제 를 어떻게 해결 합 니까?80 포트 는 부하 균형 처 리 를 감청 하 는 데 사용 되 었 기 때문에 이 서버 에 서 는 a. com 의 방문 요청 을 80 포트 로 처리 할 수 없습니다. 새로운 것 을 사용 해 야 합 니 다.그래서 우 리 는 메 인 서버 의 ngix. conf 를 다음 코드 에 추가 합 니 다.

server{ 
    listen 8080; 
    server_name a.com; 
    index index.html; 
    root /data0/htdocs/www; 
}

nginx 를 다시 시작 하고 브 라 우 저 에 a. com: 8080 을 입력 하여 접근 할 수 있 는 지 확인 하 십시오.결 과 는 정상적으로 접근 할 수 있다.
정상적으로 접근 할 수 있 는 이상, 우 리 는 홈 서버 를 upstream 에 추가 할 수 있 습 니 다. 그러나 포트 는 다음 코드 를 바 꿔 야 합 니 다.

upstream a.com { 
      server  192.168.5.126:80; 
      server  192.168.5.27:80; 
      server  127.0.0.1:8080; 
}

여기에 메 인 서버 IP 192.168.5.149 또는 127.0.0.1 을 추가 할 수 있 기 때문에 모두 자신 을 방문 하 는 것 을 나타 낸다.
Nginx 를 다시 시작 하고 a. com 에 방문 해서 메 인 서버 에 할당 되 는 지 확인 하 세 요.
메 인 서버 도 정상적으로 서비스 에 가입 할 수 있 게 되 었 다.
마지막 논술:
1. 부하 균형 은 nginx 만 있 는 것 이 아니 라 유명한 apache 도 있 지만 성능 은 nginx 보다 못 할 수 있 습 니 다.
2. 여러 대의 서버 가 서 비 스 를 제공 하지만 도 메 인 이름 은 메 인 서버 에 만 해석 되 고 진정한 서버 IP 는 ping 에 의 해 얻 을 수 없 으 며 일정한 안전성 을 증가 합 니 다.
3. upstream 의 IP 는 반드시 내부 네트워크 가 아니 라 외부 네트워크 IP 도 가능 합 니 다.그러나 전형 적 인 사례 는 랜 의 한 IP 가 외부 네트워크 에 노출 되 고 도 메 인 이름 은 이 IP 를 직접 분석 하 는 것 이다.그리고 이 메 인 서버 는 내 망 서버 IP 에 전송 된다.
4. 특정한 서버 가 다운 되 고 사이트 의 정상 적 인 운행 에 영향 을 주지 않 습 니 다. Nginx 는 다운 된 IP 에 요청 을 전달 하지 않 습 니 다.