고성능 Nginx + Keepalived 2019 버 전

본문의 목적
2019 년 주류 소프트웨어 기술 을 사용 해 신뢰성 높 은 고성능 의 Nginx 를 배치 했다.온라인 에서 작 동 하 는 8 핵 8G 의 단일 가상 머 신 은 200 Mb / s 의 지속 적 인 트 래 픽 을 안정 적 으로 지원 하 며 서비스 중단, CPU 폭주 상황 이 나타 나 지 않 았 다.본 고 는 커 널 을 재 컴 파일 하고 특정한 하드웨어 설비 에 의존 하지 않 으 며 특정한 네트워크 구조 에 의존 하지 않 으 며 물리 기 를 사용 할 필요 가 없다.
적용 범위
본 고 는 새로운 것 을 추구 하지 않 고 통용 되 고 효과 적 인 최적화 방법 을 사용 하여 주류 의 운영 체제 에 적용 한다.

CentOS 6.7 + (이미 테스트 및 검증)

CentOS 7.0 + (이미 테스트 및 검증)

Ubuntu 14.04 (지원, 미 테스트)

Ubuntu 16.04 (이미 테스트 및 검증)

Ubuntu 18.04 (이미 테스트 및 검증)

데 비 안 8, 9, 10 (지원, 미 테스트)

Nginx + Keepalived 한 마디 소개
흔히 볼 수 있 는 조합 으로 신뢰성 이 높 은 4 층 과 7 층 프 록 시 서버 를 실현 하 는 데 자주 사용 된다.
Nginx 버 전 추천

Tengine 3. x 는 nginx 1.17, 아 리 제품, 고성능 을 바탕 으로 내 장 된 공식 Stream 모듈 은 TCP 대 리 를 직접 지원 할 수 있 습 니 다.현재 stream 모듈 의 upstream 건강 검진 기능 이 부족 합 니 다.

OpenResty 최신 판 Nginx 의 '통합 패키지 판' 은 새로운 Nginx, luajit 생태 를 기반 으로 한 확장 판 입 니 다.추가 플러그 인 설치 권장 vts ngxhealthcheck_module

Nginx 최신 판 공식 오픈 소스 버 전.

상기 세 가지 버 전 은 각각 천추 가 있 는데 현재 우리 온라인 에서 사용 하 는 것 은 Tengine 이다.
최적화 요소 (위험 은 낮은 것 에서 높 은 것 으로)

운영 체제

ulimit 파라미터

ip_vs 매개 변수

네트워크 카드 파라미터

irq 소프트 인 터 럽 트

CPU 친연

nginx 매개 변수 최적화

커 널 시작 매개 변수

커 널 sysctl 파라미터

커 널 버 전

운영 체제
우 분투 18.04, 16.04 또는 CentOS 7.7 + 운영 체 제 를 추천 합 니 다.지금도 CentOS 6 을 꾸준히 사용 하려 면 언젠가는 커 널 버 전이 늙 고 소프트웨어 버 전이 늙 으 며 Docker 가 지원 되 지 않 으 며 Systemd 가 지원 되 지 않 는 등 주동 적 이거 나 수 동적 으로 업 그 레이 드 될 것 이다.더욱 승급 하여 일찍 즐 깁 니 다.irqbalance 서 비 스 는 cpu 부하 소프트 인 터 럽 트 를 자동 으로 연결 할 수 있 으 며, 커 널 이 2.4 이상 의 버 전이 필요 합 니 다.
ulimit 매개 변수
추천 설정 1048576
ip_vs 매개 변수
많은 글 에서 커 널 매개 변수 설정 을 수정 하여 커 널 을 재 컴 파일 하여 ipvs 모듈 의 매개 변수 최적화.사실 새로운 시스템 (CentOS 6.7 이상 포함) 은 커 널 을 다시 컴 파일 할 필요 가 없습니다. 로 딩 매개 변수 options ip 만 설정 해 야 합 니 다.vs conn_tab_bits = 20 이면 가능 합 니 다.
네트워크 카드 매개 변수
gso gro tso 닫 기
irq 소프트 인 터 럽 트
irqbalance 서 비 스 를 시작 하면 소프트 인 터 럽 트 ksoftirqd 로 인 한 cpu 부하 가 현저히 낮 아 집 니 다.(커 널 은 2.4 버 전 이상 이 어야 합 니 다) nginx 트 래 픽 이 300 Mb / s 보다 높 을 때 ksoftirqd 의 cpu 부하 가 높 고 네트워크 지연 이 커지 면 irqbalance 서비스 가 켜 졌 는 지 확인 할 수 있 습 니 다.
CPU 친연
nginx 설정 에서 다음 설정 을 진행 합 니 다: workerprocesses auto; worker_cpu_affinity auto;
nginx 매개 변수 최적화
http 매개 변 수 는 여러 가지 상용 설정 입 니 다.
커 널 시작 매개 변수
주로 nohz = off transparenthugepage=never numa=off
커 널 sysctl 파라미터

## NAT,GATEWAY:1
## net.ipv4.ip_forward = 0
## net.ipv4.ip_forward = 1
## NAT,GATEWAY:0 
## net.ipv4.tcp_tw_recycle = 0
## net.ipv4.tcp_tw_recycle = 1

fs.aio-max-nr = 16777216
fs.file-max   = 16777216
fs.nr_open    = 16777216
kernel.core_pipe_limit = 0
kernel.core_uses_pid = 1
kernel.exec-shield = 1
kernel.randomize_va_space = 1
kernel.msgmax = 65536
kernel.msgmnb = 65536
kernel.sem = 250 32000 100 128
kernel.shmall = 4294967296
kernel.shmmax = 68719476736
kernel.sysrq = 0
kernel.pid_max = 4194303
net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.core.netdev_max_backlog = 524288
net.core.rmem_default = 8388608
net.core.rmem_max = 16777216
net.core.somaxconn=65535
net.core.wmem_default = 8388608
net.core.wmem_max = 16777216
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.all.arp_notify = 1
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.default.arp_announce = 2
net.ipv4.conf.eth0.accept_source_route = 0
net.ipv4.conf.lo.accept_source_route = 0
net.ipv4.conf.lo.arp_announce = 2
net.ipv4.neigh.default.gc_stale_time = 120
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_keepalive_time = 30
net.ipv4.tcp_max_orphans = 3276800
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_max_tw_buckets = 16777216
net.ipv4.tcp_mem = 94500000 915000000 927000000
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_rmem = 4096 87380 4194304
net.ipv4.tcp_sack = 1
net.ipv4.tcp_slow_start_after_idle = 1
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 2
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_wmem = 4096 65536 4194304
net.nf_conntrack_max = 25000000
net.netfilter.nf_conntrack_max=25000000
net.netfilter.nf_conntrack_generic_timeout = 120
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_established = 180
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
vm.overcommit_memory=1
vm.swappiness = 0
###vm.min_free_kbytes=65536
net.ipv4.tcp_fastopen = 3
net.ipv4.ip_local_port_range = 10000 65535
net.ipv4.ip_local_reserved_ports =10050,11215,18000-18099,27017,60000-60099
kernel.printk_ratelimit = 30
kernel.printk_ratelimit_burst = 200
vm.max_map_count=262144
# recommended for hosts with jumbo frames enabled
#net.ipv4.tcp_mtu_probing=1
fs.inotify.max_user_watches = 30000000
#bbr
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr

커 널 버 전
커 널 의 버 전 은 성능 과 기능 에 현저 한 영향 을 미 치고 4.9 버 전 은 BBR 기능 을 추가 하여 성능 에 현저 한 향상 을 가 집 니 다. * *커 널 버 전 업그레이드 위험 이 높 으 므 로 신중 해 야 합 니 다. * *CentOS 7 커 널 버 전 은 3.10 으로 centos - relase - xen 창 고 를 사용 하여 4.9 커 널 을 설치 할 수 있 습 니 다.
우 분투 16.04.3 HWE 커 널 버 전 은 4.13 이다.커 널 이 기본 4.4.0 이 라면 Liux - image - generic - hwe - 16.04 를 설치 하여 4.13 버 전 으로 업그레이드 할 수 있 습 니 다.
우 분투 18.04 는 4.15 버 전의 커 널 을 사용한다.커 널 4.9 과 4.14 는 LTS 버 전 으로 유지 기간 은 보통 최소 2 ∼ 3 년 이다.우 분투 LTS 지원 기간 은 보통 5 년 으로, 큰 버 전 간 부 드 럽 게 업 그 레이 드 될 수 있다.
커 널 버 전 업그레이드 작업 추가
Ubuntu ：

apt-get update
apt-get dist-upgrade -y

#          
apt-get install linux-image-4.13.0-32-generic

#            
apt-get install -y linux-image-generic-hwe

CentOS 7 방법 1:

yum install -y centos-release-xen && yum install -y kernel  

CentOS 7 방법 2: ELRepo 를 설치 하면 kernel 버 전 을 업그레이드 하고 최신 버 전 을 스크롤 하여 업그레이드 할 수 있 습 니 다. 나중에 커 널 보안 패 치 가 업그레이드 되면 안정 적 인 버 전 을 사용 하면 안전 위험 이 존재 합 니 다.
새 커 널 사용

test -f /usr/sbin/update-grub && sudo update-grub
test -f /usr/sbin/grub2-mkconfig && sudo grub2-mkconfig -o /boot/grub2/grub.cfg

안전 관련
1.1 점프 사용 설정 $request_uri 사용자 의 요청 경 로 를 가 져 옵 니 다 $uri 또는 $document_uri

location / {
    return 302 https://$host$request_uri;
}

1.2 location 와 alias 가 설정 되 었 을 때 끝 에 평행봉 이 일치 하 는 지 여부 입 니 다.

location /files/ {
    alias /home/;
}

1.3 서브 모듈 에 add 를 설정 하면 주의header, 상위 모듈 의 모든 add 를 덮어 씁 니 다.header 설정 정보
자동 재 시도
자동 재 시도 체 제 는 가능 한 한 요청 이 실 행 될 수 있 도록 보장 할 수 있 지만그러나 병발 압력 이 큰 상황 에서 백 엔 드 서 비 스 는 압력 을 견 디 지 못 하 는 데다 가 자동 재 시도 하면 시스템 부하 가 더욱 높 아 눈사태 효 과 를 일 으 킬 수 있다.자동 재 시도 메커니즘 을 닫 는 것 을 권장 합 니 다.

프 록 시 자동 재 시도 닫 기next_upstream off;

프 록 시 다시 시도 허용next_upstream_tries 1;

cms 시스템 큰 글 저장, 파일 업로드, 오류 502 또는 408
http 필드, 증가client_body_buffer_size 8192k; __ 만약 해결 되 지 않 았 다 면, 이 값 을 다시 적당히 증가 시 킬 수 있다.
브 라 우 저 오류 ERRINCOMPLETE_CHUNKED_ENCODING
원인: 백 엔 드 서비스 (예 를 들 어 netty) 는 http 1.1 만 지원 하고 nginx 는 기본적으로 http 1.0 을 사용 하여 백 엔 드 서 비 스 를 요청 합 니 다.해결 방법, location 은 다음 과 같은 설정 을 추가 하여 nginx 가 http 1.1 프로 토 콜 을 사용 하여 백 엔 드 서 비 스 를 요청 하도록 합 니 다.또한, 이 두 개의 인 자 를 사용 하면 keepalived 등 기능 을 사용 하여 백 엔 드 tcp 의 동시 연결 수 를 줄 일 수 있 습 니 다. 우리 온라인 에 서 는 이 두 개의 인 자 를 기본적으로 사용 합 니 다.

proxy_http_version 1.1;
proxy_set_header Connection "";

Chacha20 - Poly 1305 + X25519, openssl 1.1.0 + nginx - 1.12.1 + / 1.13.3 + 필요

ssl_ciphers EECDH+AES:EECDH+CHACHA20:!SHA;
ssl_prefer_server_ciphers on;
ssl_ecdh_curve X25519;

읽 기 위해 남 아 있 는 바이트 와 역방향 프 록 시 다운로드 오류 전송 closed

proxy_buffering off;

로그
서로 다른 용도 의 로그 형식 이 일치 합 니 다. 일부 변 수 를 인쇄 하지 않 으 면 - 로 대체 합 니 다.예 를 들 어 main 형식 에 인쇄 되 지 않 음 $request_body, spider 형식 은 인쇄 되 지 않 음 $upstream_addr.

log_format  main  '[$time_iso8601] $http_x_forwarded_for $remote_addr '
    '$request_method $status $server_protocol '
    '$scheme://$http_host$request_uri '
    '"$http_referer" "$http_user_agent" - $request_time '  
    '$body_bytes_sent $upstream_addr $upstream_response_time ';

log_format  debug  '[$time_iso8601] $http_x_forwarded_for $remote_addr '
    '$request_method $status $server_protocol '
    '$scheme://$http_host$request_uri '
    '"$http_referer" "$http_user_agent" $request_body $request_time ' 
    '$body_bytes_sent $upstream_addr $upstream_response_time ';

log_format  spider '[$time_iso8601] $http_x_forwarded_for $remote_addr '
    '$request_method $status $server_protocol '
    '$scheme://$http_host$request_uri '
    '"$http_referer" "$http_user_agent" $request_body $request_time ' 
    '$body_bytes_sent - $upstream_response_time ';

decode $request_body

python2>
line = '{\x22id\x22:\x22user id\x22}'
line.decode('unicode_escape')
>> u'{"id":"user id"}'

python3>
line='{\x22....}'
bytes(line, 'utf-8').decode('unicode_escape')

ruby irb>
require 'yaml'
line = '{\x22id\x22:\x22user id\x22}'
YAML.load(%Q(---
"#{line}"
))
=> "{\"id\":\"user id\"}"

참조 원본:https://www.leavesongs.com/PENETRATION/nginx-insecure-configuration.html https://stackoverflow.com/questions/30361486/nginx-logging-request-body-as-hexadecimal