사용은 정적 및 동적로드 밸런싱 클러스터의 분리를 달성 Nginx에
Nginx의 공식 웹 사이트 소스 패키지 다운로드 링크 : HTTP : //nginx.org/en/download.html
Nginx에 소개;
개요 : Nginx와는 러시아에서 개발 한 오픈 소스, 고성능 HTTP 서버 인 프록시 서버를 역으로 상당한 성능 이점을 것입니다 지원의 IMAP / POP3 / SMTP 프록시 서비스는 공식 웹 사이트는 말했다 : nginx를 단일 서버는 50000를 처리 할 수 동시;
기능 : 고성능 안정 소비 적은 하드웨어 자원, 주로 정적 확인에 사용되는 많은 동시를 처리 할 수있는 페이지의 분리 이동;
장점 :
웹 서버, nginx를 정적 파일, 인덱스 파일, 자동 색인의 효율성 1. 매우 높다.
프록시 서버로서 2. Nginx에 가속 및 사이트 속도를 개선하기 위해 리버스 프록시 캐싱없이 달성 될 수있다.
3. 부하 분산 서버로, Nginx와는 직접 외국 서비스, 프록시 서버를 HTTP 지원, 내부 레일 및 PHP를 지원합니다. 간단한 내결함성과로드 밸런싱 알고리즘의 사용을 지원하는 동안.
성능의 측면에서, Nginx에 달성 매우 효율성에 초점을 맞추었다. 그것은 동시 연결 수에 대한 응답으로 50 000를 지원할 수 있습니다 더 많은 동시 연결을 지원할 수있는 커널 설문 조사 모델을 사용하지만 또한 매우 낮은 메모리 리소스를합니다.
안정성의 측면에서의 Nginx는 CPU의 점유율을, 단계적 자원 할당 기술을 촬영하고 메모리는 매우 낮다. Nginx에 Nginx에 공식 10 개 000 연결을위한 활동이 없다고 말했다 메모리의 2.5M 이러한 연결은, 그러므로, Nginx에 대한이 같은 DOS 공격은 기본적으로 아무런 영향이 없습니다.
당신이 할 수있는, 또는 서비스의 중단없이 소프트웨어 버전 업그레이드를 구성 할 수 있도록 고 가용성의 관점에서, Nginx에 너무 다시 시작하지 않고 개월의 실행은 거의 24 시간을 할 수있는 경우에도 신속하게 뜨거운 배포, 특히 시작 속도를 지원 중단없는 작업.
Nginx의 구현 원리;
Nginx의 핵심 구성 요소 :
코어 모듈 : HTTP 모듈, EVENT 이벤트 모듈, MAIL 모듈.
기본 모듈 : HTTP 액세스 모듈, HTTP FastCGI를 모듈, HTTP 프록시 모듈, HTTP 재 작성 모듈
타사 모듈 : HTTP 상류 요청 해시 모듈, 공지 사항 모듈, HTTP 액세스 키 모듈.
(작용에 기초하여)의 Nginx 모듈 구분 :
핸들러 : 프로세서 모듈, 예컨대 모듈 직접 요청을 처리하고, 콘텐츠 정보와 헤더 및 수정 작업 등을 출력한다. 처리기 프로세서 모듈은 일반적으로 단지 하나있다.
필터 : 필터 모듈 같은 다른 프로세서의 내용의 주요 모듈은 출력 모듈의 Nginx의 최종 출력에서의 동작을 수정하기 위해.
프록시 : 프록시 클래스 모듈은 이러한 모듈은 모듈과 같은 Nginx에 HTTP 상류, 등 상호 작용 FastCGI를, 같은 주 및 백엔드 서비스 중 일부는 서비스 프록시 및로드 밸런싱 기능을 달성 할 수 있습니다.
Nginx의 프로세스 모델 :
단일 작업자 프로세스 모드 : 주 과정뿐만 아니라, 작업 과정이 작업 과정이 단일 스레드입니다,이,이 모드로 기본;
작품의 멀티 프로세스 모드 : 각 작업 프로세스는 여러 개의 스레드를 포함
Nginx에 마스터 과정 :
1. 상태 신호가 수신 Nginx의 외부에 송신하고, 그 다음 관리 서비스와 같은;
2. 관리 작업자 프로세스, 각 작업자 프로세스는 특별한 상황에서 작업자 프로세스가 종료, 자동으로 새 작업자 프로세스를 다시 시작할 때, 작업자 프로세스의 작동 상태를 점검, 신호를 보냅니다;
3.master 전체 프로세스 동안 가디언 프로세스에서 사용자 인터페이스 프로세스 그룹 상호 작용의 역할. 그것은 단지, 업그레이드를 부드럽게, 서비스를 다시 시작 즉각적인 효과와 함께 로그 파일, 구성 파일 및 기타 기능을 대체하는 작업자 프로세스를 관리함으로써 달성 될 것이며, 사업의 이행에 대한 책임을지지 않습니다, 네트워크 이벤트를 처리하지 않습니다.
작업자 프로세스 :
여러 작업자 프로세스에서 네트워크 이벤트의 기본 과정은 동일 1. 그들은 클라이언트의 요청에서 같은 경쟁하며, 프로세스는 사이에 서로 독립적입니다. 요청만을 처리 작업자 작업자 프로세스에서 처리 될 수있는 다른 방법은 요청을 처리 할 수있다. 설정할 수있는 작업자 프로세스의 수는 일반적으로 우리는 ♥ CPU 코어의 동일한 번호로 기계를 설정합니다;
이유 높은 동시 Nginx의 지원;
I / 선택의 O 모델 :
각각의 연결에 대한 설명 1.. FD_SETSIZE은 선택 시스템의 설계에서, 그러나, 각각의 프로세스는 리눅스 디지털 숫자 전용 메모리 크기로 제한된다 기재된 열 수 사실 모델 (즉, 프로세스의 최대 수는 오픈라는 표현) linux2.6.35 1024, 선택 한정 전화 할 때,하지만 참조 FD_SETSIZE의 값입니다. 그것은 프로세스의 수에 상응하는 증가가 여전히 불충분 한 것 같다 경우에도 백만 사용자 연결 요청에 대해, 커널이 값을 재 컴파일에 의해 변경 될 수 있지만,이 문제를 치료할 수 없습니다
2 SELECT는 파일 기술자 모음 요청이 컬렉션을 할 때마다 검색 크기는 값을 선택하는 첫 번째 인수로 전달됩니다. 오픈 파일 디스크립터는, 주사 효율이 감소 될 경우에는, 각 공정이 증가 될 수 있으며,
3, 커널 공간을 사용자에게 불필요한 지연 복제의 증가, 전송 모드 정보를 메모리에 복사를 사용하여,
상기 I / O 모델 epoll 파일 모델 :
1. 없음 요청 디스크립터 파일 크기 제한 만 해당 메모리 크기;
2.epoll 이미 반환 소켓이 일어났다 이벤트로 하나 개의 이미지보다 더 할을 전략 중 정확히 알고 선택;
3. 커널 사용자 공간, 메시지가 공유 메모리를 사용하여 전송되며, 커널과 사용자 공간을 사용하여 전송 메시지의 mmap 가속도;
아파치 : 아파치가 선택 모델을 지원하는 2.2.9 전에, epoll에 모델 후 2.2.9 지원,
Nginx의 : 지원 epoll에 모델;
LB로드 밸런싱 클러스터는 두 가지 범주로 나누어 : LVS (4 개)과의 nginx 또는 haproxy (7 개)
클라이언트는 VIP 액세스 디스펜서를 통해 사이트에 액세스하기
|이제 웹 페이지와 같은 더 복잡한 응용 프로그램은, 지금이 있습니다 .PHP .html 중에서 .PNG .JPEG .jsp로 및 기타 동적 페이지의 정적 페이지를. 정적 페이지는 일반적으로 동일하고, 빠르고, 이전 연구 SQUID에 접근하고 싶습니다.
|그러나, 상기 LVS는 4 개 개의 계층이다. IP 기반. 이제 우리는 응용 프로그램 계층에서 서로 다른 응용 프로그램에 따라 배포해야합니다.
|세븐 LB는 Nginx에 / Haproxy는 레이어 7 LB를 지원할 수
원하는 효과를 본 것이다 :
정적 파일 처리 : 당신의 nginx 또는 아파치를 사용할 수 있습니다
동적 파일 처리 아파치 톰캣
이미지 파일 처리 : 오징어
사용은 정적 및 동적로드 밸런싱 클러스터의 분리를 달성 Nginx에
Nginx의로드 밸런싱 기초
가장 일반적으로 3 가지 방법 이전에 사용 5 가지의 상류로드 Nginx와,
1), 폴링 (기본값)
백 엔드 서버가 다운되면 각각 다른 시간 순서 백 엔드 서버에 할당 된 각 요청은 자동으로 제거 할 수 있습니다.
2) 중량
폴링의 경우 불균일 백엔드 서버 성능에 대한 중량 비율과 액세스 확률에 비례.
3) ip_hash
각 요청은 접근 각 방문자 고정 된 백 엔드 서버, 세션의 문제를 해결할 수 그래서, 방문의 IP 해시 결과에 따라 할당됩니다.
4) 공정 (제 3 자)
백엔드 서버, 짧은 응답 시간을 우선 순위 할당에 할당 요구의 응답 시간으로.
- 5), url_hash (제 3 자) 탈라 URL
보다 효과적인 언론 해시 액세스 요청 URL의 결과는 백엔드 서버 캐시에 대해 동일한 백엔드 서버로 동일한 URL을 할당 할 때
앞으로 프록시 및 역방향 프록시
리버스 프록시 , 액세스 게이트웨이 뒤에 게이트웨이 서버에있는 콘텐츠를 통해 외부 장치는 게이트웨이는 역방향 프록시 기능은, 우리가 일반적으로 대부분 구현되는 브라우저 웹 서버를 통해 원격으로 액세스한다.
앞으로 프록시는 , 차례로, 우리는 일반적으로 프록시가 외부 에이전트의 LAN 사용자가 게이트웨이를 통해 네트워크에 액세스하는 말, 위의 과정이다.
사용의 nginx로드 밸런싱 및 정적 및 동적 분리
- 소스 컴파일 및 nginx를 설치
첫째, 먼저 적절한 컴파일러를 설치해야합니다 및 관련 도구 설치의 nginx에 따라 달라집니다
[root@harry63 ~]# yum -y install gcc gcc-c++ autoconf automake
[root@harry63 ~]# yum -y install zlib zlib-devel openssl openssl-devel pcre pcre-develZLIB : gzip을 모듈 제공 nginx를하는 것은 ZLIB 라이브러리 지원이 필요
하려면 openssl을 : SSL 기능 제공 Nginx에
PCRE를 : 주소 재 작성 재 작성 기능을 지원합니다
- nginx를 설치합니다 :
[root@harry63 ~]# ll nginx-1.8.0.tar.gz -h #整个nginx文件不到只813K，很小
-rw-r--r-- 1 root root 813K Jul 14 20:17 nginx-1.8.0.tar.gz
[root@harry63 ~]# tar -zxvf nginx-1.8.0.tar.gz -C /usr/local/src/
[root@harry63 ~]# cd /usr/local/src/nginx-1.8.0/
[root@harry63 ~]# ./configure --prefix=/usr/local/nginx --with-http_dav_module --with-http_stub_status_module --with-http_addition_module --with-http_sub_module --with-http_flv_module --with-http_mp4_module
##查看参数：
[root@harry63 nginx-1.8.0]# ./configure --help | grep mp4
- 매개 변수 :
--with-http_dav_module ngx_http_dav_module 지원 활성화 (MKCOL 삭제, 증가 PUT을 : 컬렉션을 만들고, COPY 및 MOVE 방법) 필요가 열려 컴파일 기본적으로 꺼져
--with-http_stub_status_module ngx_http_stub_status_module 지원을 활성화 (마지막 시작 이후의 nginx 이후 근무 조건받을)
--with-http_addition_module (출력 필터로서, 상기 버퍼는 완전히 부 응답 요구에서 지원되지 않음) ngx_http_addition_module 지원 활성화
--with-http_sub_module이 ngx_http_sub_module 지원을 활성화 (텍스트는 다른 텍스트의 nginx 응답을 대체 할 수 있습니다)
--with-http_flv_module은 (메모리 기반 파일 오프셋 시간을 제공하고자하는) ngx_http_flv_module 지원 가능
--with-http_mp4_module은 MP4 파일 지원을 활성화 (메모리 기반 파일 오프셋 시간을 제공하고자)
- 컴파일 및 설치 (CPU 논리를 고양이의 수를 볼은 / proc / cpuinfo의 | 그렙 프로세서 | 화장실 -l)
[root@harry63 ~]#make -j 4
[root@harry63 ~]#make install- 사용자의 세대 nginx를 실행합니다 :
[root@harry63 nginx-1.8.0]# useradd -u 8000 -s /sbin/nologin nginx
[root@harry63 nginx-1.8.0]# id !$
id nginx
uid=8000(nginx) gid=8000(nginx) groups=8000(nginx)
- Nginx의 주요 디렉토리 구조 :
[루트 @ harry63 /] # LS /server/nginx-1.8.0/
conf의 HTML 로그 sbin에
conf의 # 프로필
conf의 # 프로필
HTML # 웹 사이트 루트
로그 로그 #
sbin에 #nginx 시작 스크립트
- 주요 구성 파일 :
[root@harry63 /]# ls /server/nginx-1.8.0/conf/nginx.conf- 시작의 nginx :
[root@harry63 /]# /server/nginx-1.8.0/sbin/nginx
[root@harry63 /]# netstat -antup | grep :80
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 5281/httpd
[root@harry63 /]# netstat -antup | grep :80
- 부팅 :
[루트 @ harry63의 nginx-1.8.0] # 에코 '/server/nginx-1.8.0/sbin/nginx 및'>> /etc/rc.local에
당신의 브라우저를 테스트 :
http://192.168.1.63/
nginx를 서비스 일상 업무 :
- 구성 파일 구문을 테스트 :
[root@harry63 nginx-1.8.0]# /server/nginx-1.8.0/sbin/nginx -t
nginx: the configuration file /server/nginx-1.8.0/conf/nginx.confsyntax is ok
nginx: configuration file /server/nginx-1.8.0/conf/nginx.conf test is successful- 구성 파일을 다시로드
[root@harry63 nginx-1.8.0]# /server/nginx-1.8.0/sbin/nginx -s reload- 닫기의 nginx
[root@harry63 /]# /server/nginx-1.8.0/sbin/nginx -s stop
[root@harry63 /]# /server/nginx-1.8.0/sbin/nginx -s start #没有start参数
nginx: invalid option: "-s start", 유통 될 nginx를 구성 정적 및 동적 분리를 달성하기 위해
[root@harry63 conf]# cd /server/nginx-1.8.0/conf #配置文件目录
[root@harry63 conf]# cp nginx.conf nginx.conf.back #备份一下配置文件
[root@harry63 conf]# vim nginx.conf
[root@harry63 nginx-1.8.0]# vim /server/nginx-1.8.0/conf/nginx.conf #指定启动nginx用户
改：# user nobody;
为：user nginx nginx;
변경 :
location / {
root html;
index index.html index.htm; #在location / { 。。。} 中添加以下内容 #定义分发策略
location / {
root html;
index index.html index.htm;
if ($request_uri ~* \.html$){
proxy_pass http://htmlservers;
}
if ($request_uri ~* \.php$){
proxy_pass http://phpservers;
}
proxy_pass http://picservers;
}서버, 백 엔드 서버에 더 이상 확인에 직접 해결 다음 정보 또는 파일 PHP의 nginx을 주석 :
location ~ .php$ {
73 # root html;
74 # fastcgi_pass 127.0.0.1:9000;
75 # fastcgi_index index.php;
76 # fastcgi_param SCRIPT_FILENAME /server/nginx-1.8.0/html$fastcgi_script_name;
77 # include fastcgi_params;
78 # }- 로드 밸런싱 장비를 정의 IP
nginx.conf 전에 구성 파일의 마지막 줄에 다음을 추가합니다 :
upstream htmlservers { #定义负载均衡服务器组名称
server 192.168.1.62:80;
server 192.168.1.64:80;
}
upstream phpservers{
server 192.168.1.62:80;
server 192.168.1.64:80;
}
upstream picservers {
server 192.168.1.62:80;
server 192.168.1.64:80;
}특정 사업 구성의 IP 주소로 후자 월의 필요성
저장하고 종료 WQ.
- Nginx에 서버 구성 파일을 다시로드 :
[root@harry63 conf]# /server/nginx-1.8.0/sbin/nginx -t
nginx: the configuration file /server/nginx-1.8.0/conf/nginx.conf syntax is ok
nginx: configuration file /server/nginx-1.8.0/conf/nginx.conf test is successful
[root@harry63 conf]# /server/nginx-1.8.0/sbin/nginx -s reload- 웹 서버를 구성합니다 :
[root@harry62 html]# yum install httpd php -y- 정적 테스트 파일을 생성합니다 :
[root@harry62 html]#echo 192.168.1.62 > /var/www/html/index.html- 동적 테스트 파일을 생성합니다 :
[root@harry62 html]#vim /var/www/html/test.php #写如以下内容：
192.168.1.62-php
<?php
phpinfo();
?>- 이미지 파일을 생성합니다 :
다음 "리치 치 창 (62 개) 사이트의 / var / www / html / 디렉토리에 다음과 같은 사진을 업로드 :
- 아파치 서버를 시작합니다 :
[루트 @ harry62 HTML] # 서비스 아파치를 다시 시작
- 백 엔드 서버 구성 : 리치 Qige (64)
IP : 192.168.1.64
- 웹 서버를 구성합니다 :
[루트 @ harry64 HTML] # 냠 설치 아파치 PHP -y
- 정적 테스트 파일을 생성합니다 :
에코 192.168.1.64> /var/www/html/index.html
- 동적 테스트 파일을 생성합니다 :
vim /var/www/html/test.php #写如以下内容：
192.168.1.64-php
<?php
phpinfo();
?>이미지 파일을 생성합니다 :
의 / var / www / html / 디렉토리 "리치 치 창 (64) 사이트에 사진을 업로드 :
[루트 @ harry64 HTML] # 서비스 아파치를 다시 시작
이러한 목적을 달성하기 위해 균형 Nginx의 부하.
#### 테스트로드 균형 조정
테스트 정적 페이지를 전달 :
http://192.168.1.63/
http://192.168.1.63/
동적 테스트 페이지를 전달 :
http://192.168.1.63/test.php
http://192.168.1.63/test.php
사진의 테스트 전달 :
http://192.168.1.63/pic.jpg
http://192.168.1.63/pic.jpg
테스트는 자동 나쁜 노드를 제거 :
[루트 @ harry64 HTML] # 서비스 아파치 정지
중지 아파치 [OK]
액세스 :
http://192.168.1.63/pic.jpg
http://192.168.1.63/pic.jpg
에 액세스 할 수 있습니다
시험 성능 :
확장 : 열려있는 파일의 개수가 많음
[루트 @ harry64 HTML] # AB -c 1,000 1,000 http://192.168.1.62/index.html # 정상 동작 -n
[루트 @ harry64 HTML] # AB 2000 -c 2000 http://192.168.1.62/index.html # 오류 -n
이 ApacheBench이며, 버전 2.3 <$ 수정 : 655,654 $>
저작권 1996 아담 Twiss, 제우스 테크놀로지 (주), http://www.zeustech.net/
아파치 소프트웨어 재단에 라이센스, http://www.apache.org/
벤치마킹 192.168.1.62 (환자 수)
소켓 : 열려있는 파일 (24) # 시험, 한 번에 너무 많은 개방 소켓 파일이 너무 많음.
ulimit를 -a #보기
ulimit를 -n
1,024
기본값은 1024 파일을 열어 프로세스를 허용하면서
해결 방법 :
ulimit를는 10240 # 오류 용액 -n
정책 설정 방법 Nginx의 부하 5 종류 (의 nginx 구성 파일을 추가)
1, 폴링 (기본값)
백 엔드 서버가 다운되면 각각 다른 시간 순서 백 엔드 서버에 할당 된 각 요청은 자동으로 제거 할 수 있습니다.
upstream backserver {
server 192.168.1.62;
server 192.168.1.64;
}
2, 무게를 지정
폴링의 경우 불균일 백엔드 서버 성능에 대한 중량 비율과 액세스 확률에 비례.
upstream backserver {
server 192.168.1.62 weight=1;
server 192.168.1.64 weight=2;
}3, IP는 ip_hash 바인딩
각 요청은 접근 각 방문자 고정 된 백 엔드 서버, 세션의 문제를 해결할 수 그래서, 방문의 IP 해시 결과에 따라 할당됩니다.
upstream backserver {
ip_hash;
server 192.168.1.62:80;
server 192.168.1.64:80;
}4 공정 (제 3 자)
백엔드 서버, 짧은 응답 시간을 우선 순위 할당에 할당 요구의 응답 시간으로.
upstream backserver {
server server1;
server server2;
fair;
}5, url_hash (제 3 자)
할당 요청을 눌러 액세스 URL 해시 결과는 같은 백엔드 서버로 각 URL은 백 엔드 서버 때 캐시 효과적입니다.
upstream backserver {
server squid1:3128;
server squid2:3128;
hash $request_uri;
hash_method crc32;
}
요약, 확장 :
바람둥이, 아파치 경우 다음과 같이 구성 오징어 :
[root@harry63 conf]# vim nginx.conf # 在最后添加以下内容。 定义Rich七哥服务器组
upstream tomcat_servers {
server 192.168.1.2:8080;
server 192.168.1.1:8080;
server 192.168.1.11:8080;
}
upstream apache_servers {
server 192.168.1.5:80;
server 192.168.1.177:80;
server 192.168.1.15:80;
}
upstream squid_servers {
server 192.168.1.26:3128;
server 192.168.1.55:3128;
server 192.168.1.18:3128;
}