Que tipo de hardware de servidor web você usa para lidar com 100 Mbps + de arquivos estáticos?

Question

Atualmente, uso o Amazon S3 para grande parte das minhas necessidades de exibição de arquivos estáticos, mas minha fatura mensal está ficando muito cara. Eu fiz alguns cálculos aproximados usando os logs e nos horários de pico, meu bucket Amazon mais caro está lidando com cerca de 100 180 Mbps de tráfego. Principalmente imagens abaixo dos 50K.

O S3 é extremamente útil quando se trata de armazenamento e redundância, mas eu realmente não preciso pagar por largura de banda e solicitações GET, se puder ajudar. Eu tenho muita largura de banda barata no meu próprio datacenter, então eu configurei um servidor nginx como um proxy de cache e, em seguida, preparei o cache com a maior parte dos meus arquivos (cerca de 240 GB) para que meu disco não estivesse escrevendo como louco em um cache vazio.

Tentei cortar e meu meu servidor bloqueou .

Parece que meus discos foram o problema - esta máquina tem 4 discos SATA de 1 TB (Barracuda XT) configurados no RAID 10. É a única coisa que eu tinha disponível com espaço de armazenamento suficiente para ser usado para isso. Tenho certeza que o nginx foi configurado corretamente, pois eu já o estava usando como um proxy de armazenamento em cache para outro bucket menor da Amazon. Supondo que esta é uma quantidade razoável de tráfego para uma única máquina, talvez valesse a pena experimentar um SSD.

Se você lida com grandes quantidades de exibição de arquivos estáticos, qual hardware você usa?

informações adicionais

Sistema de arquivos: ext4, montado noatime, barreira = 0, dados = writeback, nobh (tenho backup de bateria no controlador) Nginx: worker_connections = 4096, worker_rlimit_nofile 16384, worker_processes 8, open_file_cache max = 100000 inativo = 60m

    

Answer 1

Eu não acho que o seu disco é o problema. Primeiro ncache do nginx usa um armazenamento de disco para cache. Assim, a velocidade do disco será uma causa potencial de problemas, dependendo de quão quente / frio seu conjunto de dados é, no entanto, não vejo razão para você não poder servir 100mb / seg com o hardware que você mencionou - especialmente se você está usando o nginx.

A primeira coisa que eu acho é que seu número de processos de trabalho foi baixo, suas conexões de trabalho foram provavelmente muito baixas, e você provavelmente não teve seu conjunto open_file_cache alto o suficiente. No entanto, nenhuma dessas configurações causaria um alto IO Wait nem um pico como esse. Você diz que está atendendo a < 50k imagens e parece que 1/4 do seu conjunto pode ser facilmente armazenado em buffer pelo sistema operacional. O Nginx certamente não está configurado de maneira ideal.

O Varnish trata o problema de uma maneira um pouco diferente usando RAM em vez de disco para seu cache.

Depende muito do seu conjunto de dados, mas, com base nos dados que você forneceu, não vejo nenhum motivo para o IO do disco ter se espalhado dessa forma. Você verificou o dmesg e os logs para ver se uma de suas unidades encontrou alguns erros de E / S no momento? A única outra coisa que eu posso pensar que poderia ter causado esse pico foi exceder o cache de arquivos do nginx, o que teria feito com que ele tivesse que entrar em um modo FIFO abrindo novos arquivos.

Certifique-se de que seu sistema de arquivos esteja montado com o noatime, o que deve reduzir uma quantidade considerável de writeops da sua carga de trabalho.

Como exemplo de uma máquina que lida regularmente com 800mb / s:

# uptime
 11:32:27 up 11 days, 16:31,  1 user,  load average: 0.43, 0.85, 0.82

# free
             total       used       free     shared    buffers     cached
Mem:       8180796    7127000    1053796          0       1152    2397336
-/+ buffers/cache:    4728512    3452284
Swap:      8297568     237940    8059628

Quadcore Xeon:
    Intel(R) Xeon(R) CPU           X3430  @ 2.40GHz

$ ./bw.pl xxx.xxx 2010-09-01 2010-09-30
bw: 174042.60gb

average 543mb/sec, peaks at 810mb/sec

=== START OF INFORMATION SECTION === Model Family:     Seagate Barracuda
7200.12 family Device Model:     ST3500418AS Serial Number:    6VM89L1N
Firmware Version: CC38 User Capacity: 
500,107,862,016 bytes

Linux 2.6.36-rc5 (xxxxxx)   10/04/2010  _x86_64_    (4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4.33    0.00    2.40    5.94    0.00   87.33

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             109.61     19020.67       337.28 19047438731  337754190

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.09    0.00    3.40   10.26    0.00   78.25

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             138.52     21199.60       490.02     106210       2455

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.74    0.00    3.25    9.01    0.00   84.00

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             125.00     21691.20       139.20     108456        696

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4.75    0.00    3.12   14.02    0.00   78.11

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             154.69     19532.14       261.28      97856       1309

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.81    0.00    3.36    9.48    0.00   80.36

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             112.80     17635.20       309.00      88176       1545

MRTG:

link

Conjunto de dados:

# du -sh ads
211.0G  ads

# ls|wc -l
679075

    

Answer 2

Seu. Discos Sugue. Ponto.

• Tente obter discos muito mais rápidos e mais rápidos. SAS vem bem aqui, como os Velociraptors.

• Dito isto, o melhor seria conseguir ... um SSD.

Seus discos provavelmente geram cerca de 200 IOPS cada. Com SAS você pode chegar a cerca de 450, com Velocidaptors para cerca de 300. Um SSD high-end pode levá-lo ... 50.000 (sem piada - eu realmente quero dizer 5 0 0 0 0 0 0) IOPS.

Faça as contas;) Um único SSD, sem RAID, seria cerca de 62 vezes mais rápido que o Raid 10;)

    

Answer 3

Estamos atendendo a cerca de 600 Mbps de um servidor com SSDs no back-end e nginx + verniz na frente. O processador real é um pequeno processador Intel Atom; nós temos quatro deles atrás de um LB fazendo 600 Mbits / seg cada (usando DSR). Talvez não seja apropriado para todas as situações, mas foi perfeito para nosso caso de uso.

    

Answer 4

A máquina que você está usando tem memória RAM suficiente para ter o conjunto de arquivos em cache na RAM?

Além disso - você já viu algo como o Varnish? O Nginx é ótimo para lidar com toneladas de conexões - mas não é o máximo em termos de armazenamento em cache e desempenho de sistemas.

    

Answer 5

Adicione muito mais discos. Você pode trocar a velocidade do disco com o número de discos (até um certo ponto): talvez você consiga obter o mesmo desempenho com discos caros X SAS 15kRPM ou com (supondo, valores não significativos) discos SATA 7k2RPM baratos. Você tem que fazer a sua matemática e ver o que é melhor para você - e isso também depende de quanto você paga pelo espaço do rack e energia no seu datacenter.

O SSD oferece todas as IOPS necessárias, mas elas não são baratas para armazenamento em massa (é por isso que o caso de uso principal delas é o banco de dados, como cargas de trabalho).