Nginx 서버에서 TCP에 대한 로드 밸런싱을 구성하는 방법-엔진스-php.cn

1. nginx를 설치하세요
1. nginx를 다운로드하세요

# wget http://nginx.org/download/nginx-1.2.4.tar.gz

로그인 후 복사

2. tcp 모듈 패치를 다운로드하세요

# wget https://github.com/yaoweibin/nginx_tcp_proxy_module/tarball/master

로그인 후 복사

소스 코드 홈페이지: https://github.com/yaoweibin/nginx_tcp_proxy_module

# tar xvf nginx-1.2.4.tar.gz
# tar xvf yaoweibin-nginx_tcp_proxy_module-v0.4-45-ga40c99a.tar.gz
# cd nginx-1.2.4
# patch -p1 < ../yaoweibin-nginx_tcp_proxy_module-a40c99a/tcp.patch
#./configure --prefix=/usr/local/nginx --with-pcre=../pcre-8.30 --add-module=../yaoweibin-nginx_tcp_proxy_module-ae321fd/
# make
# make install

로그인 후 복사

2. 구성 파일 수정

nginx.conf 구성 파일 수정

# cd /usr/local/nginx/conf
# vim nginx.conf

로그인 후 복사

worker_processes 1;
events {
worker_connections 1024;
}

tcp {
upstream mssql {
server 10.0.1.201:1433;
server 10.0.1.202:1433;
check interval=3000 rise=2 fall=5 timeout=1000;
}
server {
listen 1433;
server_name 10.0.1.212;
proxy_pass mssql;
}
}

로그인 후 복사

3. nginx를 시작하세요

# cd /usr/local/nginx/sbin/
# ./nginx

로그인 후 복사

1433 포트 보기:

#lsof :1433

로그인 후 복사

# telnet 10.0.1.201 1433

로그인 후 복사

5. SQL Server 클라이언트 도구 테스트 사용

6. TCP 로드 밸런싱의 실행 원리
nginx는 수신 포트에서 새 클라이언트 링크를 수신하면 즉시 라우팅 스케줄링 알고리즘을 실행하고 지정된 값을 얻습니다. 연결해야 하는 서비스 IP를 지정한 다음 지정된 서버에 대한 새 업스트림 연결을 만듭니다.

tcp 로드 밸런싱은 라운드 로빈(기본값, 폴링 스케줄링), 해시(일관성 선택) 등을 포함한 nginx의 원래 스케줄링 알고리즘을 지원합니다. 동시에 일정 정보 데이터는 견고성 감지 모듈과 함께 작동하여 각 연결에 대해 적절한 대상 업스트림 서버를 선택합니다. 해시 로드 밸런싱 스케줄링 방법을 사용하는 경우 $remote_addr(클라이언트 IP)을 사용하여 간단한 영구 세션을 달성할 수 있습니다(동일한 클라이언트 IP를 사용한 연결은 항상 동일한 서비스 서버에 속함).

다른 업스트림 모듈과 마찬가지로 tcp 스트림 모듈은 사용자 정의 로드 밸런싱 전달 가중치(구성 "weight=2")는 물론 실패한 업스트림 서버를 쫓아내는 데 사용되는 백업 및 다운 매개변수도 지원합니다. max_conns 매개변수는 서버의 TCP 연결 수를 제한하고 서버 용량에 따라 적절한 구성 값을 설정할 수 있습니다. 특히 동시성이 높은 시나리오에서는 과부하 보호 목적을 달성할 수 있습니다.

nginx는 클라이언트 연결과 업스트림 연결을 모니터링합니다. 데이터가 수신되면 nginx는 tcp 연결에서 데이터 감지를 수행하지 않고 즉시 이를 읽고 업스트림 연결로 푸시합니다. nginx는 클라이언트 및 업스트림 데이터 쓰기를 위한 메모리 버퍼를 유지합니다. 클라이언트나 서버가 많은 양의 데이터를 전송하는 경우 버퍼는 메모리 크기를 적절하게 늘립니다.

nginx가 어떤 당사자로부터든 연결 종료 알림을 받거나 tcp 연결이 설정된 Proxy_timeout 시간보다 오랫동안 유휴 상태이면 연결이 닫힙니다. TCP 긴 연결의 경우 적절한 Proxy_timeout 시간을 선택해야 하며 동시에 조기 연결 끊김을 방지하기 위해 모니터링 소켓의 so_keepalive 매개변수에 주의해야 합니다.

ps: 서비스 견고성 모니터링
tcp 로드 밸런싱 모듈은 내장된 견고성 감지를 지원합니다. 업스트림 서버가 Proxy_connect_timeout 구성 시간 이상 TCP 연결을 거부하면 실패한 것으로 간주됩니다. 이 경우 nginx는 즉시 업스트림 그룹의 다른 일반 서버에 연결을 시도합니다. 연결 실패 정보는 nginx 오류 로그에 기록됩니다.

서버가 반복적으로 실패하면(max_fails 또는 failure_timeout으로 구성된 매개변수 초과) nginx도 서버를 추방합니다. 서버가 시작된 후 60초가 지나면 nginx는 서버가 정상으로 돌아왔는지 확인하기 위해 때때로 서버에 다시 연결을 시도합니다. 서버가 정상으로 돌아오면 nginx는 이를 업스트림 그룹에 다시 추가하고 연결 요청 비율을 천천히 늘립니다.

"천천히 증가"하는 이유는 일반적으로 서비스에 "핫 데이터"가 있기 때문입니다. 즉, 요청의 80% 이상이 실제로 "핫 데이터 캐시"에서 차단되고 실제 처리가 수행되지 않습니다. 요청이 몇 개만 있습니다. 머신이 막 시작되면 실제로 "핫 데이터 캐시"가 설정되지 않았습니다. 이때 많은 양의 요청이 폭발적으로 전달되어 머신이 "견딜" 수 없어 다시 끊길 수 있습니다. . mysql을 예로 들면, mysql 쿼리의 95% 이상이 일반적으로 메모리 캐시에 들어가고 실제로 실행되는 쿼리는 많지 않습니다.

실제로 단일 머신이든 클러스터이든 동시 요청이 많은 시나리오에서 다시 시작하거나 전환하면 이러한 위험이 발생할 수 있습니다. 이를 해결하는 두 가지 주요 방법이 있습니다.

(1) 점차적으로 요청 수를 늘리십시오. 더 적은 것부터 더 많은 것까지 점차적으로 핫스팟 데이터를 축적하고 최종적으로 정상적인 서비스 상태에 도달합니다.
(2) "공통적으로 사용되는" 데이터를 미리 준비하고, 서비스를 적극적으로 "예열"한 후, 예열이 완료된 후 서버에 접근을 오픈합니다.

tcp 로드 밸런싱의 원리는 lvs 등과 동일합니다. 낮은 수준에서 작동하며 성능은 원래 http 로드 밸런싱보다 훨씬 높습니다. 그러나 lvs보다 낫지는 않습니다. lvs는 커널 모듈에 배치되는 반면 nginx는 사용자 모드에서 작동하며 nginx는 상대적으로 무겁습니다. 또 매우 아쉬운 점은 이 모듈이 유료 기능이라는 점입니다.

TCP 로드 밸런싱 모듈은 내장된 견고성 감지 기능을 지원합니다. 업스트림 서버가 Proxy_connect_timeout 구성 시간 이상 TCP 연결을 거부하면 실패한 것으로 간주됩니다. 이 경우 nginx는 즉시 업스트림 그룹의 다른 일반 서버에 연결을 시도합니다. 연결 실패 정보는 nginx 오류 로그에 기록됩니다.

서버가 반복적으로 실패하는 경우(max_fails 또는 failure_timeout으로 구성된 매개변수 초과) nginx도 서버를 추방합니다. 서버가 시작된 후 60초가 지나면 nginx는 서버가 정상으로 돌아왔는지 확인하기 위해 때때로 서버에 다시 연결을 시도합니다. 서버가 정상으로 돌아오면 nginx는 이를 업스트림 그룹에 다시 추가하고 연결 요청 비율을 천천히 늘립니다.

"천천히 증가"하는 이유는 일반적으로 서비스에 "핫 데이터"가 있기 때문입니다. 즉, 실제 처리 전에 요청의 80% 이상이 실제로 "핫 데이터 캐시"에서 차단됩니다. 몇 가지 요청만 수행됩니다. 머신이 막 시작되면 실제로 "핫 데이터 캐시"가 설정되지 않았습니다. 이때 많은 양의 요청이 폭발적으로 전달되어 머신이 "견딜" 수 없어 다시 끊길 수 있습니다. . mysql을 예로 들면, mysql 쿼리의 95% 이상이 일반적으로 메모리 캐시에 들어가고 실제로 실행되는 쿼리는 많지 않습니다.

실제로 단일 머신이든 클러스터이든 동시 요청이 많은 시나리오에서 다시 시작하거나 전환하면 이러한 위험이 발생할 수 있습니다. 이를 해결하는 두 가지 주요 방법이 있습니다.

(1) 점차적으로 요청 수를 늘리십시오. 더 적은 것부터 더 많은 것까지 점차적으로 핫스팟 데이터를 축적하고 최종적으로 정상적인 서비스 상태에 도달합니다.
(2) "공통적으로 사용되는" 데이터를 미리 준비하고, 서비스를 적극적으로 "예열"한 후, 예열이 완료된 후 서버에 접근을 오픈합니다.

tcp 로드 밸런싱의 원리는 lvs 등과 동일합니다. 낮은 수준에서 작동하며 성능은 원래 http 로드 밸런싱보다 훨씬 높습니다. 그러나 lvs보다 낫지는 않습니다. lvs는 커널 모듈에 배치되는 반면 nginx는 사용자 모드에서 작동하며 nginx는 상대적으로 무겁습니다. 또 매우 아쉬운 점은 이 모듈이 유료 기능이라는 점입니다.
위 내용은 Nginx 서버에서 TCP에 대한 로드 밸런싱을 구성하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!