Gostaria de descobrir a melhor configuração / hardware possível para fornecer 40Gbps a partir de um único servidor nesta questão.

Situação

Temos um servidor proxy de compartilhamento de vídeo que descarrega picos de servidores de armazenamento lento atrás dele. Todo o tráfego é apenas HTTP. O servidor atua como um proxy reverso (arquivos que não são armazenados em cache no servidor) e um servidor da web (arquivos armazenados em unidades locais).

Atualmente, existem algo como 100 TB de arquivos e crescendo nos servidores de armazenamento de back-end.

O mecanismo de armazenamento em cache é implementado de forma independente e esta questão não se refere ao armazenamento em cache, pois funciona muito bem - atualmente fornece 14 Gbps, passa para os servidores de back-end apenas 2 Gbps. Portanto, o uso do cache é bom.

Objetivo

Alcance 40Gbps ou mais com uma única máquina.

Hardware 1

HW: Supermicro SC825, X11SSL-F, Xeon E3-1230v5 (4C/[email protected]), 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

Sistema:

• irqbalancer parado
• set_irq_affinity para cada interface (via script no tarx do driver ixgbe)
• ixgbe-4.3.15
• Prazo do planejador de E / S
• iptables vazio (módulos descarregados)
• Sistema de arquivos: XFS

Nginx:

• sendfile off
• tópicos aio
• directio 1M
• tcp_nopush em
• tcp_nodelay on

Como visto nos gráficos, fomos capazes de fornecer 12,5 Gbps. Infelizmente, o servidor não respondeu.

Há duas coisas que chamaram minha atenção. O primeiro é uma quantidade alta de IRQ. Infelizmente, neste caso, não tenho gráficos de / proc / interrupts. A segunda coisa foi a alta carga do sistema, que eu acho que foi causada pelo kswapd0 tendo problemas para trabalhar apenas com 16G de RAM.

Hardware 2

HW: Supermicro SC119TQ, X10DRW-i, 2x Xeon E5-2609v4 (8C/[email protected]), 128 GB de RAM DDR4, 2x Supermicro 10G STGN-i1S

SSD, a configuração do sistema é igual ao hardware 1. O Nginx está com o sendfile ativado (aio / sendfile comparado com mais).

Isso parece melhor, então agora como temos um servidor, que funciona em picos, podemos tentar algumas otimizações.

Threads sendfile vs aio

Tentei desativar o sendfile e, em vez disso, use os threads do aio.

• sendfile off
• tópicos aio
• directio 1M (que corresponde a todos os arquivos que temos)

vs

• sendfile on

Às 15:00, voltei para sendfile e recarreguei o nginx (demorou um pouco para concluir as conexões existentes). É bom que a utilização da unidade (medida pelo iostat) tenha diminuído. Nada mudou no tráfego (infelizmente o zabbix decidiu não coletar os dados do bond0).

sendfile ativado / desativado

Apenas tentei ativar / desativar o envio. Nada mudou, exceto o reagendamento de interrupções.

irqbalancer como servidor / cron / desativado

Como o @lsd mencionou, tentei configurar o irqbalancer para ser executado via cron:

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

Infelizmente, não ajudou no meu caso. Uma das placas de rede começou a se comportar de maneira estranha:

Não consegui encontrar o que havia de errado nos gráficos e, como aconteceu no dia seguinte novamente, entrei no servidor e vi que um núcleo estava 100% (uso do sistema).

Tentei iniciar o irqbalance como um serviço, o resultado ainda era o mesmo.

Decidi usar o script set_irq_affinity e ele corrigiu o problema imediatamente e o servidor empurrou 17Gbps novamente.

Hardware 3

Atualizamos para o novo hardware: chassi de unidades 2U 24 (+2) (6xSFF), 2x Xeon E5-2620v4, RAM DDR4 de 64GB (módulos 4x16GB), SSD 13x, SSD 13x, placas de rede Supermicro (com chip Intel) 2x. Novas CPUs melhoraram muito o desempenho.

A configuração atual permanece - sendfile, etc. A única diferença é que deixamos apenas uma única CPU lidar com ambas as placas de rede (via script set_irq_affinity).

O limite de 20 Gbps foi atingido.

Próxima meta? 30Gbps.

Sinta-se livre para me dar idéias de como melhorar o desempenho. Ficarei feliz em testá-lo ao vivo e compartilhar alguns gráficos pesados ​​aqui.

Alguma idéia de como lidar com grande quantidade de SoftIRQs na CPU?

Esta não é uma pergunta sobre planejamento de capacidade - eu já tenho o hardware e o tráfego. Sempre posso dividir o tráfego em vários servidores (o que terei que fazer no futuro de qualquer maneira) e corrigir o problema com dinheiro. No entanto, essa é uma pergunta sobre otimização do sistema e ajuste de desempenho em um cenário real ao vivo.

Isenção de responsabilidade : o mesmo conselho se aplica a todos os serviços com mais de 10 Gbps. Incluído, mas não limitado a, balanceadores de carga, servidores de cache, servidores da Web (HAProxy, Varnish, nginx, tomcat, ...)

O que você quer fazer é errado, não faça

Use uma CDN

As CDN destinam-se a fornecer conteúdo estático atualizável. Use a ferramenta certa para o trabalho (akamai, MaxCDN, cloudflare, cloudfront, ...)

Qualquer CDN, mesmo gratuita, terá um desempenho melhor do que o que você pode conseguir por conta própria.

Escale horizontalmente

Eu espero que um único servidor lide de 1 a 5 Gbps imediatamente, sem muitos ajustes (observação: servir apenas arquivos estáticos). Os 8-10Gbps geralmente estão ao alcance com o ajuste avançado.

No entanto, existem muitos limites rígidos para o que uma única caixa pode suportar. Você deve preferir escalar horizontalmente.

Execute uma única caixa, tente as coisas, meça, avalie, otimize ... até que a caixa seja confiável e confiável e seus recursos sejam bem determinados, depois coloque mais caixas como essa com um balanceador de carga global à frente.

Existem algumas opções globais de balanceamento de carga: a maioria das CDN pode fazer isso, DNS roundrobin, ELB / Google load balancers ...

Vamos ignorar as boas práticas e fazê-lo de qualquer maneira

Compreendendo o padrão de tráfego

            WITHOUT REVERSE PROXY

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

Há duas coisas a considerar: a largura de banda e a direção (emissão ou recepção).

Os arquivos pequenos são 50/50 tx / rx porque os cabeçalhos HTTP e a sobrecarga do TCP são maiores que o conteúdo do arquivo.

Arquivos grandes têm 90/10 tx / rx porque o tamanho da solicitação é insignificante comparado ao tamanho da resposta.

            WITH REVERSE PROXY

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

O proxy reverso está retransmitindo todas as mensagens nas duas direções. A carga é sempre 50/50 e o tráfego total é dobrado.

Torna-se mais complexo com o cache ativado. Os pedidos podem ser desviados para o disco rígido, cujos dados podem ser armazenados em cache na memória.

Nota : Ignorarei o aspecto de armazenamento em cache nesta postagem. Vamos nos concentrar em obter 10-40 Gbps na rede. Saber se os dados vêm do cache e otimizar esse cache é outro tópico, eles são enviados de qualquer maneira.

Limitações de monocore

O balanceamento de carga é monocore (especialmente balanceamento de TCP). A adição de núcleos não o torna mais rápido, mas pode ser mais lento.

O mesmo para o balanceamento HTTP com modos simples (por exemplo, IP, URL, com base em cookies. O proxy reverso lê cabeçalhos em tempo real, não analisa nem processa solicitações HTTP em sentido estrito).

No modo HTTPS, a descriptografia / criptografia SSL é mais intensa do que tudo o mais necessário para o proxy. O tráfego SSL pode e deve ser dividido em vários núcleos.

SSL

Dado que você faz tudo sobre SSL. Você deseja otimizar essa parte.

Criptografar e descriptografar 40 Gbps em tempo real é uma conquista.

Pegue um processador de última geração com as instruções AES-NI (usadas para operações SSL).

Ajuste o algoritmo usado pelos certificados. Existem muitos algoritmos. Você deseja o que é mais eficaz em sua CPU (faça benchmarking), ao mesmo tempo em que é suportado pelos clientes E é seguro o suficiente (sem necessidade de criptografia excessiva).

IRQ e fixação do núcleo

A placa de rede está gerando interrupções (IRQ) quando há novos dados para ler e a CPU é antecipada para processar imediatamente a fila. É uma operação em execução no kernel e / ou nos drivers de dispositivo e é estritamente monocore.

Pode ser o maior consumidor de CPU, com bilhões de pacotes saindo em todas as direções.

Atribua à placa de rede um número IRQ exclusivo e fixe-o em um núcleo específico (consulte as configurações de Linux ou BIOS).

Pin o proxy reverso para outros núcleos. Não queremos que essas duas coisas interfiram.

Adaptador Ethernet

A placa de rede está fazendo muito trabalho pesado. Todos os dispositivos e fabricantes não são iguais quando se trata de performances.

Esqueça o adaptador integrado nas placas-mãe (não importa se a placa-mãe é servidor ou consumidor), elas são uma droga.

Transferência de TCP

O TCP é um protocolo muito intensivo em termos de processamento (somas de verificação, ACK, retransmissão, remontagem de pacotes, ...) O kernel está lidando com a maior parte do trabalho, mas algumas operações podem ser transferidas para a placa de rede, se suportadas.

Não queremos apenas uma carta relativamente rápida , queremos uma com todos os sinos e assobios.

Esqueça a Intel, Mellanox, Dell, HP, qualquer que seja. Eles não suportam tudo isso.

Há apenas uma opção na mesa: SolarFlare - A arma secreta das empresas de HFT e CDN.

O mundo está dividido em dois tipos de pessoas: " Quem conhece o SolarFlare " e " quem não conhece ". (o primeiro conjunto é estritamente equivalente a " pessoas que fazem redes de 10 Gbps e se preocupam com tudo "). Mas discordo, vamos nos concentrar: D

Ajuste de TCP do Kernel

Existem opções sysctl.confpara buffers de rede do kernel. O que essas configurações fazem ou não. Eu realmente não sei.

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

Brincar com essas configurações é o sinal definitivo de super otimização (ou seja, geralmente inútil ou contraproducente).

Excepcionalmente, isso pode fazer sentido, dadas as exigências extremas.

(Nota: 40Gbps em uma única caixa é super otimizada. A rota razoável é escalar horizontalmente.)

Alguns limites físicos

Largura de banda de memória

Alguns números sobre a largura de banda da memória (principalmente em GB / s): http://www.tweaktown.com/articles/6619/crucial-ddr4-memory-performance-overview-early-look-vs-ddr2-ddr3/index.html

Digamos que o intervalo seja de 150 a 300 Gbps para largura de banda de memória (limite máximo em condições ideais).

Todos os pacotes precisam estar na memória em algum momento. A ingestão de dados a uma taxa de linha de 40 Gbps é uma carga pesada no sistema.

Restará alguma energia para processar os dados? Bem, não vamos deixar nossas expectativas muito altas nisso. Apenas dizendo ^^

Barramento PCI-Express

O PCIe 2.0 é de 4 Gb / s por faixa. O PCIe 3.0 tem 8 Gbps por pista (nem todos estão disponíveis para a placa PCI).

Uma NIC de 40 Gbps com uma única porta Ethernet promete mais que o barramento PCIe se o conector tiver menos de 16x de comprimento nas especificações da v3.0.

De outros

Nós poderíamos ir além de outros limites. O ponto é que o hardware tem limitações rígidas inerentes à lei da física.

O software não pode fazer melhor do que o hardware em que está sendo executado.

O backbone da rede

Todos esses pacotes precisam ir a algum lugar, eventualmente, atravessando switches e roteadores. Os switches e roteadores de 10 Gbps são quase uma mercadoria. Os 40 Gbps definitivamente não são.

Além disso, a largura de banda precisa ser de ponta a ponta; portanto, que tipo de links você tem até o usuário?

Da última vez que verifiquei com meu pessoal do datacenter um pequeno projeto paralelo de 10 milhões de usuários, ele ficou bem claro que haveria apenas 2x 2x Gbits de links para a Internet, no máximo.

Discos rígidos

iostat -xtc 3

As métricas são divididas por leitura e gravação. Verifique se há fila (<1 é bom), latência (<1 ms é bom) e velocidade de transferência (quanto maior, melhor).

Se o disco estiver lento, a solução é colocar um SSD maior E maior no RAID 10. (observe que a largura de banda do SSD aumenta linearmente com o tamanho do SSD).

Escolha da CPU

O IRQ e outros gargalos são executados apenas em um núcleo; portanto, aponte para a CPU com os mais altos desempenhos de núcleo único (ou seja, frequência mais alta).

A criptografia / descriptografia SSL precisa das instruções da AES-NI, para ter como objetivo apenas a revisão mais recente da CPU.

O SSL se beneficia de vários núcleos, portanto, procure vários núcleos.

Resumindo: o CPU ideal é o mais novo com a maior frequência disponível e muitos núcleos. Basta escolher o mais caro e provavelmente é isso: D

Enviar arquivo()

Sendfile ON

Simplesmente o maior progresso dos kernels modernos para servidores da web de alto desempenho.

Nota final

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
...

Uma coisa fixada em uma CPU. Esse é o caminho a percorrer.

Uma placa de rede que leva ao mundo externo. Uma placa de rede que leva à rede interna. A divisão de responsabilidades é sempre boa (embora a NIC dupla de 40 Gbps possa ser um exagero).

Há muitas coisas a serem ajustadas, algumas das quais podem ser o assunto de um pequeno livro. Divirta-se comparando tudo isso. Volte para publicar os resultados.

Ainda não posso comentar devido à reputação, portanto, é necessário adicionar uma resposta ...

No primeiro exemplo, você disse:

Há duas coisas que chamaram minha atenção. O primeiro é uma quantidade alta de IRQ. Infelizmente, neste caso, não tenho gráficos de / proc / interrupts. A segunda coisa foi a alta carga do sistema, que eu acho que foi causada pelo kswapd0 tendo problemas para trabalhar apenas com 16G de RAM.

Concordo absolutamente que estes são pontos importantes.

1. Tente usar o agente collectd, que pode coletar IRQs e armazenar usando RRD.

2. Você tem um gráfico de uso de memória?

   Enquanto estiver na superfície, isso parece um problema de CPU, o alto% softirq% pode apontar o dedo para a memória, se houver muitas falhas de página rígidas ou flexíveis acontecendo. Eu acho que a distribuição é a repentina escalada nos IRQs, às custas da CPU do sistema por volta das 19:00.

Pelo que posso ver nas especificações, tudo parece o mesmo, além de:

• a memória
• os modelos de CPU - a menos que eu esteja enganado, os benchmarks indicariam que eles deveriam ser semelhantes e, nesses tipos de casos, eu preferiria a caixa com menos núcleos mais rápidos.