Squid ou outros caches HTTP com armazenamento em cache SSD?

Question

Estou pensando em configurar um cache de lula (ou possivelmente verniz) em um sistema com unidades SSD.

O benefício óbvio é que esses sistemas têm grandes velocidades de leitura e espero que minhas taxas de acertos sejam bastante altas.

Vamos supor que posso colocar 7 SSDs em uma configuração RAID. (há alguns casos que me permitirão incluir muito mais)

Questões de implementação:

• Devo usar o RAID0? (Espero que um disco falhe eventualmente, então isso parece perigoso.)

• Devo usar o RAID10? (Isso diminui meu espaço em disco, o que é caro.)

• Devo usar o RAID5? (SSDs são conhecidos por terem desempenho de gravação "ruim" e limites de gravação, e todas as gravações de paridade extras podem diminuir consideravelmente a velocidade.)

• Devo tratar cada disco como se fosse um armazenamento de dados do próprio squid? (como o squid lida com vários armazenamentos de dados? e o que acontece se / quando um falhar?)

• Devo ignorar os datastores e apenas fazer os SSDs em grandes partições SWAP e deixar que a VM linux faça isso? (parece desleixado)

Qualquer conselho de pessoas usando SSDs em ambientes de produção seria muito apreciado. (esp, se você estiver usando-os para caches HTTP)

    

Answer 1

Estamos usando verniz nas unidades ssd nos últimos 9 meses, e tem funcionado muito bem para nós. Anteriormente usamos um cache de memória do squid apenas com uma camada de carpas. Funcionou, mas a fragmentação da memória era um problema real que exigia reinícios frequentes. O Squid 2.x também usará apenas um núcleo, o que o torna ineficiente no hardware atual.

Para o nosso site, que é muito amigável ao cache, vemos cerca de 10% de uso da CPU em uma máquina de 8 núcleos que atende 100Mbit / s de tráfego. Em nossos testes, ficamos sem largura de banda antes de atingirmos os limites da cpu com 2 portas de 1 Gb.

Eu tenho alguns conselhos para executar o verniz com um cache de ssd.

• Desempenho de gravação aleatória realmente importa. Nós tentamos vários fornecedores para unidades ssd antes de decidir sobre o intel x-25m. Nós vimos alguns postar tão pouco quanto .1MB / s para 4k gravações aleatórias, temos 24MB / s 4k gravações aleatórias com o x-25m.

• Raid0. O cache no 2.0 não é persistente, então não precisa se preocupar com redundância. Isso faz os reinícios doerem, mas esses são raros. Você pode fazer coisas como carregar uma nova configuração e limpar objetos sem reiniciar.

• modo mmap. O cache de verniz pode ser mmap'd para um arquivo ou usar o espaço de troca. Usando o swap não funcionou bem para nós, ele tende a usar mais largura de banda de E / S para atender a mesma quantidade de tráfego. Há um readahead de 4 setores no código de troca do Linux, nós escrevemos um patch para remover isso, mas não o tentamos em produção.

• Agendador de prazo. Com o 2.6.28+, este é o ssd ciente e funciona bem. Tentamos noop, mas descobrimos que o prazo final era mais justo, já que a largura de banda de E / S fica limitada.

• Desative a leitura antecipada. Como não há atraso rotacional, não adianta ler dados extras só porque você pode precisar deles. A largura de banda de E / S é preciosa nessas coisas.

• Execute o 2.6.28+. Um mmap de muito espaço no linux dá ao gerenciador de memória um bom exercício, mas os patches lru divididos ajudam bastante. O uso da CPU do kswapd caiu muito quando atualizamos.

Publicamos nosso arquivo vcl, bem como várias ferramentas que usamos com verniz em texto do link . O vcl também inclui um hack simples que implementa um servidor geoiplookup muito rápido baseado no banco de dados maxmind.

    

Answer 2

Eu não estou usando SSDs como caches HTTP, mas posso fazer estas observações:

Nem todos os SSDs são iguais, então você precisa ter muito cuidado ao escolher os decentes. O FusionIO faz SSDs com suporte a PCIe, que são realmente de alto desempenho (com capacidade relativamente baixa), mas caros. Os SSDs X25-E SLC da Intel funcionam muito bem e são mais acessíveis, mas ainda com baixa capacidade. Faça sua pesquisa! Eu definitivamente posso recomendar as variantes do X25-E SLC, já que estou usando isso em sistemas de produção.

Existem outros SSDS disponíveis que podem oferecer uma grande velocidade sequencial de leitura / gravação, mas o importante para algo como um cache é o IO aleatório, e muitos SSDs proporcionarão aproximadamente o mesmo desempenho aleatório dos discos giratórios. Devido a escrever efeitos de amplificação em SSDs, os discos giratórios geralmente terão melhor desempenho. Muitos SSDs possuem controladores de baixa qualidade (por exemplo, controladores JMicron mais antigos), que podem sofrer um desempenho significativamente degradado em algumas situações. Anandtech e outros sites fazem boas comparações com ferramentas como iometer, confira.

E, claro, os SSDs são pequenos. O Intel X25-E, que eu diria que é o melhor SSD SATA que já vi, só vem em variantes de 32 e 64 GB.

Para os níveis de RAID, as notas de desempenho RAID padrão ainda se aplicam. Uma gravação em um RAID 5 baicamente envolve a leitura do bloco de dados que você irá modificar, lendo o bloco de paridade, atualizando a paridade, escrevendo o bloco de dados e escrevendo a paridade, para que ele ainda tenha um pior desempenho que outros RAID níveis, mesmo com SSDs. No entanto, com drives como o X25-E tendo um desempenho IO aleatório tão alto, isso provavelmente importa menos - já que ele ainda superará o IO aleatório em discos giratórios para um array de tamanho similar.

Pelo que vi, a largura de banda do controlador RAID é saturada muito cedo para obter o máximo benefício de um conjunto RAID de 7 discos, pelo menos no que se refere ao desempenho sequencial. Você não pode obter mais de 800MB / s dos modelos atuais de controladores SATA (3ware, areca etc). Ter matrizes mais pequenas, através de vários controladores (por exemplo, vários RAID1s em vez de um único RAID10) irá melhorar isto, embora o desempenho individual de cada array seja afectado.

Em relação a um cache HTTP, acho que você seria melhor servido com uma variedade decente de discos giratórios e bastante memória RAM. Objetos acessados com freqüência ficarão no cache de memória - no cache interno do squid ou no cache fs do seu sistema operacional. Simplesmente dando uma máquina mais ram pode reduzir significativamente o carregamento do disco devido a isso. Se você estiver executando um grande cache de squid, provavelmente precisará de muito espaço em disco, e os SSDs de alto desempenho ainda terão capacidade relativamente baixa.

    

Answer 3

Não estou muito familiarizado com as unidades SSD, mas posso falar sobre o tipo de arquitetura que usei, que pode ajudar a resolver alguns dos seus problemas.

Irmãos

No meu caso, eu construí quatro servidores com 16 GB de RAM cada. Eu defino 9 GB como o cache de memória para uso do Squid. Eu os configurei como um conjunto de irmãos para que uma consulta a um servidor consultasse os outros antes de procurar pelos dados. Ao todo, eu tinha 36 GB de cache de memória. Eu não teria mais de quatro irmãos como a comunicação entre eles começa a atolar.

VIPs

Eu configurei um VIP para os quatro servidores para o cliente conversar. Isso resolveu o que acontece quando um servidor fica inativo.

Crianças

Eu configurei meu aplicativo da web para consultar um servidor Squid local em execução no 127.0.0.1. Em seguida, configurei o pai desta instância do Squid para ser o VIP. Isso permite um failover muito rápido no caso de todo o VIP cair. Se os pais não responderem, a criança consultará os serviços diretamente. Também é útil se você estiver usando um único servidor Squid e não tiver um VIP. É claro que se a instância local do Squid no seu servidor web cair, tudo vai parar.

Lula em si

Eu não olhei realmente para o 3.0, mas o 2.x ainda está com um único thread. Em algum momento você vai ficar sem CPU ou buffers TCP. Eu espalhei o cache em 2-3 caixas a menos, se possível. Além disso, você pode querer fazer planos para particionar suas fazendas do Squid no futuro, caso veja o sistema crescendo.

De qualquer forma, boa sorte com o seu SSD. Estou interessado em saber como é que provavelmente vou seguir esse caminho no futuro.

    

Answer 4

Por que você está considerando a invasão 10 ou 5. Você quer desempenho aqui. Você não se importa se as unidades simplesmente caírem, já que é apenas um cache.

Use apenas o raid 0 ou mantenha-os separados. Acho que separar seria melhor, já que uma falha na unidade não derrubaria todo o cache.

    

Answer 5

A documentação do Squid recomenda não usar o RAID, mas configurar diretórios de cache extras em discos adicionais.