이 질문에 단일 서버에서 40Gbps를 제공 할 수있는 최상의 구성 / 하드웨어를 찾고 싶습니다.

상태

우리는 느린 스토리지 서버에서 피크를 오프로드하는 비디오 공유 프록시 서버가 있습니다. 모든 트래픽은 HTTP 전용입니다. 서버는 리버스 프록시 (서버에 캐시되지 않은 파일) 및 웹 서버 (로컬 드라이브에 저장된 파일)의 역할을합니다.

현재 100TB의 파일과 같은 것이 백엔드 스토리지 서버에서 증가하고 있습니다.

캐싱 메커니즘은 독립적으로 구현되며이 질문은 캐싱 자체에 관한 것이 아닙니다. 현재 14Gbps를 제공하고 백엔드 서버로 2Gbps 만 전달하는 것이 매우 효과적입니다. 따라서 캐시 사용량이 좋습니다.

골

단일 머신에서 40Gbps 이상의 처리량을 달성하십시오.

하드웨어 1

HW : Supermicro SC825, X11SSL-F, Xeon E3-1230v5 (4C/8T@3.4GHz), 16GB DDR4 RAM, 2x Supermicro 10G STGN-i1S (LACP L3 + 4)

SSD : 1x 512GB Samsung, 2x 500GB Samsung, 2x480GB Intel 535, 1x 240GB Intel S3500

체계:

• irqbalancer가 중지되었습니다
• 각 인터페이스에 대한 set_irq_affinity (ixgbe 드라이버 tarball의 스크립트를 통해)
• ixgbe-4.3.15
• I / O 스케줄러 마감일
• iptables 비어 있음 (로드되지 않은 모듈)
• 파일 시스템 : XFS

Nginx :

• sendfile off
• 아이오 스레드
• directio 1M
• tcp_nopush 켜기
• tcp_nodelay 켜기

그래프에서 볼 수 있듯이 12.5Gbps를 푸시 할 수있었습니다. 불행히도 서버가 응답하지 않았습니다.

내가 주목 한 두 가지가 있습니다. 첫 번째는 많은 양의 IRQ입니다. 이 경우 불행히도 / proc / interrupts의 그래프는 없습니다. 두 번째는 시스템 부하가 높기 때문에 kswapd0이 16G RAM에서만 작동하는 데 문제가 있다고 생각합니다.

하드웨어 2

HW : Supermicro SC119TQ, X10DRW-i, 2x Xeon E5-2609v4 (8C/8T@1.70GHz), 128GB DDR4 RAM, 2x Supermicro 10G STGN-i1S

SSD, 시스템 구성은 하드웨어 1과 동일합니다. Nginx는 sendfile을 켭니다 (aio / sendfile과 비교).

이제는 더 나은 것 같습니다. 이제 서버가 정점에서 작동하므로 최적화를 시도 할 수 있습니다.

Sendfile과 AIO 스레드

sendfile을 비활성화하고 대신 aio 스레드를 사용하려고했습니다.

• sendfile off
• 아이오 스레드
• directio 1M (우리가 가진 모든 파일과 일치)

vs

• sendfile on

그런 다음 15:00에 sendfile로 다시 전환하고 nginx를 다시로드했습니다 (따라서 기존 연결을 완료하는 데 시간이 걸렸습니다). 드라이브 사용률 (iostat로 측정)이 다운 된 것이 좋습니다. 트래픽에 변화가 없었습니다 (불행히 zabbix는 bond0에서 데이터를 수집하지 않기로 결정했습니다).

sendfile 켜기 / 끄기

보내기 / 끄기를 전환하려고했습니다. 일정 변경 인터럽트를 제외하고는 아무것도 변경되지 않았습니다.

서버 / 크론 / 비활성화 된 irqbalancer

@lsd가 언급했듯이 irqbalancer가 cron을 통해 실행되도록 설정하려고했습니다.

*/5 * * * *   root    /usr/sbin/irqbalance --oneshot --debug 3 > /dev/null

불행히도 내 경우에는 도움이되지 않았습니다. 네트워크 카드 중 하나가 이상하게 동작하기 시작했습니다.

그래프에서 무엇이 잘못되었는지 찾을 수 없었고 다음 날 다시 발생했을 때 서버에 로그인하여 하나의 코어가 100 % (시스템 사용량)임을 알 수있었습니다.

irqbalance를 서비스로 시작하려고했지만 결과는 여전히 동일합니다.

그런 다음 set_irq_affinity 스크립트를 사용하기로 결정하고 문제를 즉시 해결하고 서버가 17Gbps를 다시 푸시했습니다.

하드웨어 3

새로운 하드웨어로 업그레이드했습니다 : 2U 24 (+2) 드라이브 섀시 (6xSFF), 2x Xeon E5-2620v4, 64GB DDR4 RAM (4x16GB 모듈), 13x SSD, 2x Supermicro (Intel 칩 포함) 네트워크 카드. 새로운 CPU는 성능을 크게 향상 시켰습니다.

현재 설정은 sendfile 등으로 유지됩니다. 단 하나의 CPU 만 set_irq_affinity 스크립트를 통해 두 네트워크 카드를 모두 처리 할 수 ​​있습니다.

20Gbps 한도에 도달했습니다.

다음 목표? 30Gbps.

성능을 향상시키는 방법에 대한 아이디어를 자유롭게 촬영하십시오. 나는 그것을 라이브 테스트하고 여기에 무거운 그래프를 공유하게되어 기쁩니다.

CPU에서 많은 양의 SoftIRQ를 처리하는 방법에 대한 아이디어가 있습니까?

용량 계획에 관한 질문은 아닙니다. 하드웨어와 트래픽이 이미 있습니다. 나는 항상 트래픽을 여러 서버로 나눌 수 있으며 (어쨌든 나중에해야 할) 돈으로 문제를 해결할 수 있습니다. 그러나 이것은 실제 라이브 시나리오에서 시스템 최적화 및 성능 조정에 관한 질문입니다.

면책 조항 : 동일한 조언이 10Gbps 이상을 추진하는 모든 서비스에 적용됩니다. 로드 밸런서, 캐싱 서버, 웹 서버 (HAProxy, Varnish, nginx, tomcat 등)를 포함하지만 이에 국한되지는 않습니다.

당신이하고 싶은 것은 잘못입니다,하지 마십시오

대신 CDN을 사용하십시오.

CDN은 캐시 가능한 정적 컨텐츠를 제공하기위한 것입니다. 작업에 적합한 도구를 사용하십시오 (akamai, MaxCDN, cloudflare, cloudfront 등).

모든 CDN, 심지어 무료 CDN은 당신이 스스로 달성 할 수있는 것보다 낫습니다.

대신 수평으로 스케일링

단일 서버가 많은 조정없이 즉시 1-5Gbps를 처리 할 것으로 예상합니다 (참고 : 정적 파일 만 제공). 8-10Gbps는 일반적으로 고급 튜닝을 통해 도달 할 수 있습니다.

그럼에도 불구하고 단일 박스가 취할 수있는 것에는 많은 한계가 있습니다. 수평으로 스케일링하는 것을 선호해야합니다.

하나의 박스를 실행하고, 시도하고, 측정하고, 벤치 마크하고, 최적화하십시오 ... 그 박스가 신뢰할 수 있고 신뢰할 수 있고 그 기능이 잘 결정될 때까지, 글로벌로드 밸런서가있는 박스를 더 넣으십시오.

몇 가지 글로벌로드 밸런싱 옵션이 있습니다 : 대부분의 CDN은 DNS 라운드 로빈, ELB / Google로드 밸런서 ...

좋은 관행을 무시하고 어쨌든하자

교통 패턴 이해

            WITHOUT REVERSE PROXY

[request ]  user ===(rx)==> backend application
[response]  user <==(tx)===     [processing...]

고려해야 할 사항은 대역폭과 방향 (방출 또는 수신)입니다.

HTTP 헤더와 TCP 오버 헤드가 파일 내용보다 크기 때문에 작은 파일은 50/50 tx / rx입니다.

요청 크기는 응답 크기와 비교하여 무시할 수 있기 때문에 큰 파일은 90/10 tx / rx입니다.

            WITH REVERSE PROXY

[request ]  user ===(rx)==> nginx ===(tx)==> backend application
[response]  user <==(tx)=== nginx <==(rx)===     [processing...]

리버스 프록시는 모든 메시지를 양방향으로 중계합니다. 로드는 항상 50/50이며 총 트래픽은 두 배입니다.

캐싱을 사용하면 더욱 복잡해집니다. 데이터는 메모리에 캐시 될 수있는 요청을 하드 드라이브로 전환 할 수 있습니다.

참고 :이 게시물의 캐싱 측면을 무시합니다. 네트워크에서 10-40Gbps를 얻는 데 중점을 둘 것입니다. 캐시에서 데이터를 가져 왔는지 여부를 알고 캐시를 최적화하는 것이 또 다른 주제입니다.

모노 코어 제한

로드 밸런싱은 모노 코어 (특히 TCP 밸런싱)입니다. 코어를 추가해도 속도는 빨라지지 않지만 속도가 느려질 수 있습니다.

간단한 모드 (예 : IP, URL, 쿠키 기반)를 사용한 HTTP 밸런싱의 경우와 동일합니다. 리버스 프록시는 헤더를 즉석에서 읽으며 엄격한 의미에서 HTTP 요청을 구문 분석하거나 처리하지 않습니다.

HTTPS 모드에서 SSL 해독 / 암호화는 프록시에 필요한 다른 것보다 더 집중적입니다. SSL 트래픽은 여러 코어로 분할 될 수 있으며 분할되어야합니다.

SSL

SSL을 통해 모든 것을 수행한다고 가정합니다. 해당 부분을 최적화하고 싶을 것입니다.

40Gbps를 즉시 암호화 및 해독하는 것은 큰 성과입니다.

SSL 작업에 사용되는 AES-NI 명령으로 최신 프로세서를 사용하십시오.

인증서가 사용하는 알고리즘을 조정하십시오. 많은 알고리즘이 있습니다. 클라이언트가 지원하고 충분한 보안을 유지하면서 (필요한 오버 암호화없이) CPU에서 가장 효과적인 (벤치마킹 수행) 것을 원합니다.

IRQ 및 코어 피닝

읽을 새 데이터가있을 때 네트워크 카드가 인터럽트 (IRQ)를 생성하고 CPU가 즉시 큐를 처리하도록 선점됩니다. 커널 및 / 또는 장치 드라이버에서 실행되는 작업이며 엄격하게 모노 코어입니다.

그것은 모든 방향으로 수십억 개의 패킷이 나가는 가장 큰 CPU 소비자 일 수 있습니다.

네트워크 카드에 고유 한 IRQ 번호를 지정하고 특정 코어에 고정하십시오 (리눅스 또는 BIOS 설정 참조).

리버스 프록시를 다른 코어에 고정하십시오. 우리는이 두 가지가 방해되는 것을 원하지 않습니다.

이더넷 어댑터

네트워크 카드는 많은 노력을 기울이고 있습니다. 모든 장치와 제조업체는 성능면에서 동등하지 않습니다.

마더 보드의 통합 어댑터는 잊어 버리십시오 (서버 또는 소비자 마더 보드는 중요하지 않음).

TCP 오프 로딩

TCP는 처리 (체크섬, ACK, 재전송, 패킷 재 조립 등) 측면에서 매우 집중적 인 프로토콜입니다. 커널은 대부분의 작업을 처리하고 있지만 일부 작업은 네트워크 카드를 지원하는 경우 오프로드 될 수 있습니다.

우리는 비교적 빠른 카드를 원하지 않고 모든 종소리와 호루라기를 가진 카드 를 원합니다.

Intel, Mellanox, Dell, HP 등은 잊어 버리십시오. 그들은 모든 것을 지원하지 않습니다.

테이블에는 단 하나의 옵션이 있습니다 : SolarFlare - HFT 회사와 CDN의 비밀 무기.

세계는 사람의 두 종류의 분할이다 " 솔라 플레어을 알 것 "과 " 하지 않는 사람 ". (첫 번째 세트는 " 10Gbps 네트워킹을 수행하고 모든 비트를 관리하는 사람들 "과 엄격히 동일합니다 ). 그러나 나는 벗어나서 집중하자. : D

커널 TCP 튜닝

sysctl.conf커널 네트워크 버퍼 에 대한 옵션이 있습니다 . 이러한 설정의 기능 나는 정말로 모른다.

net.core.wmem_max
net.core.rmem_max
net.core.wmem_default
net.core.rmem_default

net.ipv4.tcp_mem
net.ipv4.tcp_wmem
net.ipv4.tcp_rmem

이러한 설정을 사용하는 것은 과잉 최적화의 최종 징후입니다 (즉, 일반적으로 쓸모 없거나 역효과를 낳습니다).

예외적으로, 이는 극한의 요구 사항을 감안할 때 의미가있을 수 있습니다.

(참고 : 단일 박스에서 40Gbps는 과도하게 최적화되어 있습니다. 합리적인 경로는 수평으로 확장하는 것입니다.)

일부 물리적 한계

메모리 대역폭

메모리 대역폭에 대한 일부 숫자 (대부분 GB / s) : http://www.tweaktown.com/articles/6619/crucial-ddr4-memory-performance-overview-early-look-vs-ddr2-ddr3/index.html

메모리 대역폭에 대한 범위가 150-300Gbps라고 가정합니다 (이상적인 조건에서 최대 제한).

모든 패킷은 어느 시점에서 메모리에 있어야합니다. 40Gbps 회선 속도로 데이터를 수집하는 것만으로도 시스템에 큰 부담이됩니다.

데이터 처리 능력이 남아 있습니까? 글쎄요, 기대치가 너무 높아지지 않도록합시다. 그냥 ^^

PCI-Express 버스

PCIe 2.0은 레인 당 4Gb / s입니다. PCIe 3.0은 레인 당 8Gbps입니다 (PCI 카드에 모두 사용할 수있는 것은 아님).

커넥터가 v3.0 사양에서 길이가 16 배 미만인 경우 단일 이더넷 포트가있는 40Gbps NIC가 PCIe 버스 이상을 약속합니다.

다른

우리는 다른 한계를 넘어 설 수 있습니다. 요점은 하드웨어에는 물리 법칙에 내재 된 어려운 한계가 있다는 것입니다.

소프트웨어는 실행중인 하드웨어보다 더 나을 수 없습니다.

네트워크 백본

이 모든 패킷은 결국 스위치와 라우터를 통과하면서 어딘가로 이동해야합니다. 10 Gbps 스위치와 라우터는 [거의] 필수품입니다. 40Gbps는 그렇지 않습니다.

또한 대역폭은 종단 간이어야하므로 사용자에게 어떤 종류의 링크가 있습니까?

지난 10 만 명의 사용자 측 프로젝트에 대해 데이터 센터 담당자와 확인했을 때 그는 인터넷에 최대 2x 10 Gbits 링크 만 있다는 것이 분명했습니다.

하드 드라이브

iostat -xtc 3

메트릭은 읽기 및 쓰기로 나뉩니다. 대기열 (<1이 좋음), 대기 시간 (<1ms가 좋음) 및 전송 속도 (높을수록 좋음)를 확인하십시오.

디스크 속도가 느리면 RAID 10에 더 많은 SSD를 배치하는 것이 해결책입니다. SSD 대역폭은 SSD 크기에 따라 선형으로 증가합니다.

CPU 선택

IRQ 및 기타 병목 현상은 하나의 코어에서만 실행되므로 단일 코어 성능이 가장 높은 CPU (예 : 최고 주파수)를 목표로합니다.

SSL 암호화 / 암호 해독에는 AES-NI 명령이 필요하므로 최신 CPU 개정만을 목표로합니다.

SSL은 여러 코어의 이점을 활용하므로 많은 코어를 목표로합니다.

짧은 이야기 : 이상적인 CPU는 사용 가능한 최고 주파수와 많은 코어를 가진 최신 CPU입니다. 가장 비싼 것을 고르면 아마 그럴 것입니다 : D

sendfile ()

Sendfile ON

고성능 웹 서버를위한 현대 커널의 가장 큰 발전.

최종 노트

1 SolarFlare NIC 40 Gbps (pin IRQ and core)
2 SolarFlare NIC 40 Gbps (pin IRQ and core)
3 nginx master process
4 nginx worker
5 nginx worker
6 nginx worker
7 nginx worker
8 nginx worker
...

한 가지는 하나의 CPU에 고정되었습니다. 갈 길이야

외부 세계로 이끄는 하나의 NIC. 내부 네트워크로 연결되는 하나의 NIC. 분할 책임은 항상 훌륭합니다 (듀얼 40Gbps NIC가 과도 할 수 있지만).

미세 조정해야 할 것들이 많으며 그 중 일부는 작은 책의 주제가 될 수 있습니다. 이 모든 것을 벤치마킹하는 재미가 있습니다. 결과를 게시하기 위해 다시 오십시오.

평판으로 인해 아직 댓글을 달 수 없으므로 대신 답변을 추가해야합니다 ...

첫 번째 예에서는 다음과 같이 말했습니다.

내가 주목 한 두 가지가 있습니다. 첫 번째는 많은 양의 IRQ입니다. 이 경우 불행히도 / proc / interrupts의 그래프는 없습니다. 두 번째는 시스템 부하가 높기 때문에 kswapd0이 16G RAM에서만 작동하는 데 문제가 있다고 생각합니다.

이것들이 중요한 요점임을 절대적으로 동의하십시오.

1. IRQ를 수집하고 RRD를 사용하여 저장할 수있는 수집 된 에이전트를 사용해보십시오.

2. 메모리 사용량 차트가 있습니까?

   표면에있는 동안 이것은 CPU 문제처럼 보이며, 많은 hardir 또는 soft 페이지 오류가 발생하는 경우 높은 softirq %가 손가락을 메모리로 가리킬 수 있습니다. 약 19:00에 시스템 CPU를 희생시키면서 IRQ가 급격히 증가하는 것 같습니다.

내가 스펙에서 볼 수있는 것에서 모든 것이 똑같습니다.

• 기억
• CPU 모델-내가 틀리지 않으면 벤치 마크는 비슷해야한다는 것을 나타낼 것입니다. 이러한 경우에는 코어가 더 적은 상자를 선호합니다.