Verificação de sanidade na configuração do servidor de 40 TB

Question

Eu tenho 40 anos em computação, mas eu nunca tive que construir um servidor como este, então isso pode ser uma questão n00b.

Eu tenho um cliente que vai oferecer arquivos de música de alta definição para download. Neste caso, significa 24 / 192Khz comprimido com FLAC = ~ 10GB / álbum. (Não, eu não quero discusir a conveniência do produto, apenas a configuração do servidor.) O catálogo terá cerca de 3.000 álbuns, com ambas as versões ultra-high e low def (para seus iPods, eu acho), dando sobre 35-40TB ou mais de dados primários.

Como esse é um produto muito especializado, o tamanho do mercado é relativamente pequeno (pense: pessoas que gastam US $ 20.000 + em seus sistemas de áudio), o que significa que na maioria das vezes o servidor estará 100% ocioso (ou próximo a isto). Eu tenho o que parece ser uma boa oferta de colocation da ColocationAmerica com uma conexão de 1Gbps e largura de banda de cerca de US $ 20 / TB, então agora eu só tenho que construir uma caixa para entregar as mercadorias.

O caso de uso de acesso a dados é write-once / read-many, então estou pensando em usar apenas o software RAID 1 para pares de unidades. Isso me permitiria (eu acho ) reconfigurar unidades sobressalentes para falhas na hora, sendo assim capaz de iniciar a reconstrução da segunda unidade antes que algum sysadmin perceba a luz vermelha no sistema ( eles trocam de graça). Seria ótimo se eu conseguisse fazer com que a maioria das unidades durasse / parasse de rodar se elas não fossem necessárias, o que será a maior parte do tempo para a maioria das unidades.

Eu não preciso de muito em termos de poder de computação - isso é apenas empurrar objetos gordos pelo cano - e assim o processador / placa-mãe pode ser bem modesto, desde que possa suportar esse número de unidades. / p>

Atualmente, estou considerando a seguinte configuração:

Chasis: Supermicro CSE-847E26-RJBOD1
Drives: 30 4TB SAS drives (Seagate ST4000NM0023 ?)
MB: SUPERMICRO MBD-X10SAE-O w/ 8GB
CPU: Xeon E3-1220V3 3.1GHz LGA 1150 80W Quad-Core Server

Então, eu estou indo na direção certa, ou isso é uma maneira completamente n00b / dinossauro de abordar o problema?

Atualização para esclarecer alguns pontos:

1. Não tenho experiência com o ZFS, pois o último produto Sun que possuía estava de volta no final dos anos 80. Vou fazer um pouco de RTFMing para ver se parece certo.
2. Eu realmente não preciso do sistema de arquivos para fazer algo espetacular, já que os nomes dos arquivos serão simples UUIDs, e os objetos serão equilibrados entre as unidades (como um grande sistema de cache). Então, eu realmente estava pensando neles como 40 sistemas de arquivos separados, e isso fazia o RAID 1 soar certo (mas eu admito a ignorância aqui).
3. Como nossas expectativas atuais são de que provavelmente não faremos o download de mais de uma dúzia de arquivos ao mesmo tempo e, na maioria dos casos, haverá exatamente uma pessoa fazendo o download de um determinado arquivo, não sei se precisamos toneladas de memória para buffers. Talvez 8GB seja um pouco leve, mas eu não acho que 128GB farão mais do que consumir energia.
4. Existem 2 máquinas separadas não mencionadas aqui: sua loja virtual atual e um Download Master quase completamente dissociado que lida com toda autenticação, gerenciamento de ingestos de novos produtos, imposição de políticas (afinal, este é o Playground da RIAA), criação de URL efêmera (e, possivelmente, transferência de downloads para mais de uma dessas feras, se o tráfego exceder as nossas expectativas), rastreamento de uso e geração de relatórios. Isso significa que esta máquina poderia quase ser construída usando gerbils em Quaaludes.

ZFS? Onde está o benefício?

OK, estou passando por vários guias do ZFS, FAQs, etc. Perdoe-me por parecer estúpido, mas estou realmente tentando entender o benefício de usar o ZFS sobre minha noção antediluviana de N pares de RAID1. Nesta página Práticas recomendadas (de 2006), elas até sugerem que não faça um dispositivo de 48 ZFS, mas 24 espelhos de 2 dispositivos - parece um pouco com o que eu estava falando. Outras páginas mencionam o número de dispositivos que devem ser acessados para entregar 1 (um) bloco ZFS. Além disso, lembre-se, a 10GB por objeto, e com 80% de utilização de disco, estou armazenando um total de 320 arquivos por unidade de 4TB . Meu tempo de reconstrução com o N RAID 1s, para qualquer falha de unidade, é uma gravação de 4 TB de um dispositivo para outro. Como o ZFS melhora isso?

Admito ser um dinossauro, mas disco é barato, RAID 1 Eu entendo, minhas necessidades de gerenciamento de arquivos são triviais, e o ZFS no Linux (meu sistema operacional preferido) ainda é um pouco jovem. Talvez eu seja muito conservador, mas quando estou olhando para um sistema de produção, é assim que eu rolo.

Agradeço a todos vocês por seus comentários que me fizeram pensar sobre isso. Ainda não estou completamente decidido e talvez tenha que voltar e fazer mais algumas perguntas sobre o assunto.

    

Answer 1

Com base na descrição do seu problema, o problema não é tanto o servidor quanto o armazenamento.
Você quer um sistema de arquivos confiável e robusto como o ZFS que foi projetado para lidar bem com grande capacidade de armazenamento e possui recursos de gerenciamento integrados para tornar esse fim do sistema mais fácil de gerenciar.

Como foi mencionado nos comentários, eu iria com o ZFS para o storage pool (provavelmente no FreeBSD porque eu estou mais familiarizado com esse sistema operacional e porque ele tem um longo e comprovado histórico de desempenho sólido com o ZFS - Meu sistema operacional de segunda escolha seria o Illumos , novamente por causa do suporte bem testado do ZFS).

No que diz respeito a servir os arquivos, eu concordo - você não precisa de muito em termos de hardware para simplesmente enviar dados pela porta de rede. Seu driver primário para CPU / RAM vai ser as necessidades do sistema de arquivos (ZFS). A regra geral é que o ZFS precisa de 1GB de RAM, mais 1GB para cada 10TB de espaço em disco que gerencia (portanto, para 40TB você precisaria de 5GB de RAM para ZFS) - o relacionamento não é bem linear (há muitos bons livros / tutoriais / docs no ZFS que podem ajudá-lo a criar uma estimativa para o seu ambiente). Observe que adicionar soquetes e assobios do ZFS como deduplicação exigirá mais RAM.

Obviamente, os requisitos de memória RAM aumentam em vez de diminuir e não são mesquinhos: se sua matemática diz que você precisa de 5 GB de RAM, não carregue o servidor com 8 GB - aumente para 16 GB.

Você pode executar seu servidor diretamente na caixa de armazenamento (o que significa que precisará de ainda mais RAM nessa caixa para suportar os processos do servidor) ou pode montar o armazenamento remotamente para "front-end". "servidores para realmente atender solicitações de clientes.
(A primeira é mais barata inicialmente, esta última melhor a longo prazo).

Além deste conselho, as melhores sugestões que eu posso lhe dar já estão bem cobertas em nossa série de perguntas do Capacity Planning - basicamente" Teste de carga, Teste de carga , Teste de carga ".

    

Answer 2

Eu uso o ZFS para um servidor multi-TB e tem sido sólido. Eu usei o OpenIndiana para começar e agora mudei para o FreeNAS, pois ele faz o que eu preciso fazer.

Eu recomendaria o uso de uma placa HBA LSI (9211-8i é uma boa placa base) com expansores SAS (os casos SuperMicro podem ser solicitados com expansores SAS integrais baseados em chipsets LSI). O firmware LSI é suportado no FreeNAS e no FreeBSD. Verifique as versões apropriadas (o V16 é bom no FreeBSD V9.x).

Dada a natureza de leitura e gravação do seu sistema, eu usaria uma topologia do ZFS Z2 (evite RAID-5 e Z1 com unidades deste tamanho). Considerando que você está usando discos de 4 TB, o tempo de reconstrução (resilver) para um grande array de vDev seria longo se o pool estivesse cheio. Para evitar longos tempos de reconstrução, organize os vDevs em grupos de 6 ou 10 para criar o pool (recomendações da documentação do FreeNAS). Um conjunto de três vDevs de 6 drives (unidades de 4TB supostamente) teria uma capacidade útil de ~ 48TB e oferece um bom nível de tolerância a falhas (lembre-se de que você ainda precisa fazer backup, pois o RAID não substitui os backups :)).

Para acelerar as coisas para arquivos comumente acessados, você pode adicionar alguns SSDs para L2ARC (provavelmente não necessários para o seu aplicativo, mas eles são muito baratos para SSDs de 120GB).

E como indicado, use muita memória RAM. 64GB não é excessivamente caro, dado o outro hardware no sistema. Infelizmente, o XEON menor não pode usar mais de 32 GB. Você poderia experimentá-lo, mas mais memória RAM seria melhor de acordo com a literatura do ZFS (eu uso o XEON que você menciona com 32GB de RAM e uma matriz Z2 com capacidade de 24TB e funciona bem).

Outra vantagem do ZFS é que você pode configurar instantâneos periódicos. Dessa forma, você pode restaurar facilmente as versões anteriores e os snapshots são muito eficientes em termos de espaço. Além disso, você pode replicar qualquer instantâneo para outro conjunto de dados (local ou remoto) e isso pode ser feito por SSH para segurança.

Eu realmente gosto da confiabilidade do sistema ZFS. Eu também gosto do fato de que é hardware INDEPENDENTE !! Qualquer sistema que possa ver as unidades pode importar o pool. Não há dependências de firmware, etc., que podem acontecer com a invasão de hardware (não é um problema com placas melhores, mas elas são mais caras do que as placas HBA e precisam de drivers, etc. - isso foi prejudicado no passado).

Como esse post é mais antigo, você provavelmente tem uma solução. Em caso afirmativo, conte-nos o que você construiu?

Felicidades,