Nginx 메 인 부하 균형 구조
23122 단어 부하 균형직장레저서버 부하 와 클 러 스 터
이 방법 은 장면 적용: 중 소형 사이트 응용 장면 에 적합 하 다.
일반적으로 편리 함 을 유지 하기 위해 기업 사이트 의 서버 는 모두 자신의 내부 기계실 에 있 고 Keepalived 의 VIP 주소 의 두 포트 80, 443 만 개방 하고 Juniper SSG 550 방화벽 을 통 해 매 핑 되 며 외부 네트워크 DNS 는 매 핑 된 공공 네트워크 IP 에 대응 합 니 다.이 구조의 방화벽 과 네트워크 안전 설명 은 다음 과 같다.
이 시스템 구 조 는 내부 네트워크 VIP 의 80 과 443 포트 만 외부 네트워크 의 Juniper SSG 550 방화벽 에 투사 하고 다른 포트 는 모두 닫 히 며 내부 네트워크 의 모든 기 계 는 iptables 방화벽 을 닫 습 니 다.외부 네트워크 DNS 는 Juniper SSG 550 을 통 해 매 핑 된 외부 네트워크 주 소 를 가리킨다.
Nginx 부하 균형 작 서버 가 발생 하 는 고장 은 일반적으로 서버 네트워크 가 느슨 해 지 는 등 네트워크 고장 이 있다.서버 하드웨어 고장 으로 손상 현상 이 발생 하여 크 래 시;
Nginx 서비스 프로 세 스 가 죽 었 습 니 다.
테스트 실험 환경:
주 Nginx 중 하나: 192.168.1.5
주 Nginx 의 2: 192.168.1.6
웹 서버 1: 192.168.17
웹 서버 2: 192.168.18
VIP 주소 1: 192.168.1.8
VIP 주소 2: 192.168.1.9
하나 Nginx 와 Keepalived 의 설 치 는 비교적 간단 합 니 다. 저 는 중복 되 지 않 습 니 다. 여러분 은 제 주제 시리즈 의 글 을 참고 하 실 수 있 습 니 다. 다음 과 같은 주소 입 니 다.http://network.51cto.com/art/201007/209823.htmNginx. conf 프로필 을 동봉 합 니 다. 다음 과 같 습 니 다.
- user www www;
- worker_processes 8;
- pid /usr/local/nginx/logs/nginx.pid;
- worker_rlimit_nofile 51200;
- events
- {
- use epoll;
- worker_connections 51200;
- }
- http{
- include mime.types;
- default_type application/octet-stream;
- server_names_hash_bucket_size 128;
- client_header_buffer_size 32k;
- large_client_header_buffers 4 32k;
- client_max_body_size 8m;
- sendfile on;
- tcp_nopush on;
- keepalive_timeout 60;
- tcp_nodelay on;
- fastcgi_connect_timeout 300;
- fastcgi_send_timeout 300;
- fastcgi_read_timeout 300;
- fastcgi_buffer_size 64k;
- fastcgi_buffers 4 64k;
- fastcgi_busy_buffers_size 128k;
- fastcgi_temp_file_write_size 128k;
- gzip on;
- gzip_min_length 1k;
- gzip_buffers 4 16k;
- gzip_http_version 1.0;
- gzip_comp_level 2;
- gzip_types text/plain application/x-javascript text/css application/xml;
- gzip_vary on;
-
- upstream backend
- {
- ip_hash;
- server 192.168.1.17:80;
- server 192.168.1.18:80;
- }
- server {
- listen 80;
- server_name www.1paituan.com;
- location / {
- root /var/www/html ;
- index index.php index.htm index.html;
- proxy_redirect off;
- 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_pass http://backend;
- }
-
- location /nginx {
- access_log off;
- auth_basic "NginxStatus";
- #auth_basic_user_file /usr/local/nginx/htpasswd;
- }
-
- log_format access '$remote_addr - $remote_user [$time_local] "$request" '
- '$status $body_bytes_sent "$http_referer" '
- '"$http_user_agent" $http_x_forwarded_for';
- access_log /data/logs/access.log access;
- }
- }
-
둘째, Keepalived 파일 을 설정 합 니 다.
저 는 간단하게 원 리 를 말씀 드 리 겠 습 니 다. 사실은 Keepalived 를 통 해 두 개의 인 스 턴 스 를 생 성 하 는 것 입 니 다. 두 대의 Nginx 는 서로 백업 합 니 다. 즉, 첫 번 째 기 계 는 두 번 째 기계 의 준비 기 이 고 두 번 째 기 계 는 첫 번 째 기계 이기 도 합 니 다. 생 성 된 두 개의 VIP 주 소 는 각각 저희 사이트 에 대응 합 니 다.http://www.1paituan.com이렇게 하면 여러분 들 은 인터넷 에서 DNS 폴 링 을 통 해 저희 사 이 트 를 방문 할 수 있 습 니 다.Nginx 기기 가 하드웨어 손상 이 발생 하면 Keepalived 는 자동 으로 VIP 주 소 를 다른 기기 로 전환 하여 클 라 이언 트 의 방문 에 영향 을 주지 않 습 니 다. 이것 은 우리 의 이전 LVS + Keepalived 다 중 인 스 턴 스 원리 와 같 습 니 다. 여러분 도 알 수 있 을 것 이 라 고 믿 습 니 다.
주 Nginx 기기 중 하나 인 Keepalived. conf 설정 파일 은 다음 과 같 습 니 다.
-
- ! Configuration File for keepalived
- global_defs {
- notification_email {
- [email protected]
- }
- notification_email_from [email protected]
- smtp_server 127.0.0.1
- smtp_connect_timeout 30
- router_id LVS_DEVEL
- }
-
- vrrp_instance VI_1 {
- state MASTER
- interface eth0
- virtual_router_id 51
- priority 100
- advert_int 1
- authentication {
- auth_type PASS
- auth_pass 1paituan.com
- }
- virtual_ipaddress {
- 192.168.1.8
- }
- }
-
-
- vrrp_instance VI_2 {
- state BACKUP
- interface eth0
- virtual_router_id 52
- priority 99
- advert_int 1
- authentication {
- auth_type PASS
- auth_pass 1paituan.com
- }
- virtual_ipaddress {
- 192.168.1.9
- }
- }
-
주 Nginx 2 의 keepalivd. conf 설정 파일 은 다음 과 같 습 니 다.
- ! Configuration File for keepalived
- global_defs {
- notification_email {
- [email protected]
- }
- notification_email_from [email protected]
- smtp_server 127.0.0.1
- smtp_connect_timeout 30
- router_id LVS_DEVEL
- }
-
- vrrp_instance VI_1 {
- state BACKUP
- interface eth0
- virtual_router_id 51
- priority 99
- advert_int 1
- authentication {
- auth_type PASS
- auth_pass 1paituan
- }
- virtual_ipaddress {
- 192.168.1.8
- }
- }
-
-
- vrrp_instance VI_2 {
- state MASTER
- interface eth0
- virtual_router_id 52
- priority 100
- advert_int 1
- authentication {
- auth_type PASS
- auth_pass 1paituan
- }
- virtual_ipaddress {
- 192.168.1.9
- }
- }
-
3. Keepalived 는 프로그램 등급 의 높 은 사용 을 실현 할 수 없다 는 것 을 잘 알 고 있 기 때문에 우 리 는 SHELL 스 크 립 트 를 써 서 Nginx 의 높 은 사용 을 실현 해 야 합 니 다. 스 크 립 트 / root / nginxpid. sh 내용 은 다음 과 같 습 니 다.
- #!/bin/bash
- while :
- do
- nginxpid=`ps -C nginx --no-header | wc -l`
- if [ $nginxpid -eq 0 ];then
- /usr/local/nginx/sbin/nginx
- sleep 5
- if [ $nginxpid -eq 0 ];then
- /etc/init.d/keepalived stop
- fi
- fi
- sleep 5
- done
-
우 리 는 각각 두 대의 메 인 Nginx 에서 실행 합 니 다. 명령 은 다음 과 같 습 니 다.
- nohup sh /root/nginxpid.sh &
이 스 크 립 트 는 제 가 직접 생산 서버 에서 다운로드 한 것 입 니 다. 이것 은 사 순환 과 유효성 문 제 를 일 으 킬 것 이 라 고 의심 하지 마 십시오. 이것 은 무한 순환 스 크 립 트 입 니 다. 메 인 Nginx 기기 에 놓 습 니 다. (현 재 는 주로 서 비 스 를 제공 하기 때 문 입 니 다) 5 초 에 한 번 씩 실 행 됩 니 다. ps - C 명령 으로 nginx 의 PID 값 이 0 인지 아 닌 지 를 수집 합 니 다. 0 이 라면.(즉, Nginx 프로 세 스 가 죽 었 습 니 다) nginx 프로 세 스 를 시작 하려 고 합 니 다. 0, 즉 nginx 가 시작 되 지 않 으 면 이 컴퓨터 의 Keeplaived 프로 세 스 를 닫 고 VIP 주 소 는 준비 장치 가 연결 합 니 다. 물론 전체 사 이 트 는 준비 장치 의 Nginx 가 서 비 스 를 제공 하여 Nginx 프로 세 스 의 높 은 사용 을 보장 합 니 다.
4. 메 인 Nginx 의 Nginx 와 Keealived 프로그램 을 정상적으로 시작 한 후 두 기계 의 정상 IP 디 스 플레이 는 다음 과 같 아야 합 니 다.
이것 은 IP 가 192.168.1.5 인 기계 의 ip addr 명령 표시 결과 입 니 다.
- 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
- link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
- inet 127.0.0.1/8 scope host lo
- 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
- link/ether 00:0c:29:99:fb:32 brd ff:ff:ff:ff:ff:ff
- inet 192.168.1.5/24 brd 192.168.1.255 scope global eth0
- inet 192.168.1.8/32 scope global eth0
이것 은 IP 가 192.168.1.6 인 기계 의 ip addr 명령 표시 결과 입 니 다.
- 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
- link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
- inet 127.0.0.1/8 scope host lo
- inet6 ::1/128 scope host
- valid_lft forever preferred_lft forever
- 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
- link/ether 00:0c:29:7d:58:5e brd ff:ff:ff:ff:ff:ff
- inet 192.168.1.6/24 brd 192.168.1.255 scope global eth0
- inet 192.168.1.9/32 scope global eth0
- inet6 fe80::20c:29ff:fe7d:585e/64 scope link
- valid_lft forever preferred_lft forever
- 3: sit0: <NOARP> mtu 1480 qdisc noop
- link/sit 0.0.0.0 brd 0.0.0.0
5. 테스트 과정 은 다음 과 같다.
첫째, 우 리 는 각각 두 대의 메 인 Nginx 에서 killall 로 Nginx 프로 세 스 를 죽 인 다음 에 클 라 이언 트 에서 각각 192.168.1.8 과 192.168.1.9 이 두 IP (아 날로 그 DNS 폴 링) 를 방문 하여 웹 서버 에 정상적으로 접근 할 수 있 는 지 확인 해 야 한다.
2. 192.168.1.5 의 메 인 Nginx 부하 이퀄 라이저 를 다시 시작 하려 고 시도 합 니 다. 테스트 과정 은 위 와 같 습 니 다.
3. 192.168.1.6 의 메 인 Nginx 부하 이퀄 라이저 를 다시 시작 하려 고 시도 합 니 다. 테스트 과정 은 다음 과 같 습 니 다.
4. 192.168.1.5 와 192.168.1.6 의 기 계 를 각각 닫 으 려 고 시도 합 니 다. 테스트 과정 은 위 와 같 습 니 다. 사이트 의 정상 적 인 방문 에 영향 을 주 는 지 보 시 겠 습 니까?
6. 현재 생산 에 투입 하여 해결 해 야 할 문제:
1. Cacti 와 Nagios 등 모니터링 서 비 스 를 재배 치 해 야 합 니 다. 현재 클 라 이언 트 는 각각 두 대의 부하 이퀄 라이저 를 방문 하기 때 문 입 니 다.
2. 로그 수집 은 재배 치 해 야 합 니 다. 현재 방문 로 그 는 두 대의 부하 이퀄 라이저 에 분포 되 어 있 습 니 다.
3. 구 글 에 수 록 된 문 제 를 고려 해 야 합 니 다.
4. 인증서 의 문제, 두 대의 기계 가 모두 필요 합 니 다.
5. 다른 문 제 는 잠시 생각 하지 못 했 으 니 보충 해 야 합 니 다.
작자: 피아노 연주
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
Haproxy 웹 클러스터 구축실험 준비: Haproxy 서버 1대, Nginx 서버 2대, 클라이언트 1대(로컬 컴퓨터 사용) Nginx 서버: ### 참고: 둘 다 비슷한 작업을 수행해야 합니다. Haproxy 서비스: 테스트: 클라이언트가 ...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.
좋은 웹페이지 즐겨찾기
