Armazenamento de dados científicos: muitos arquivos pequenos, um volume ou vários?

1

Tenho cerca de 8 TB de dados de "amostra" com as seguintes características:

cada amostra: 5-15 GB em uma pasta contendo ~ 20k arquivos e ~ 10k subpastas (2000 de nível superior, 5 subníveis contendo arquivos de dados de ~ .5-2MB e pequenos arquivos de configurações).

Estou configurando um servidor Dell T710 executando o Windows Server 2008 R2 com espaço efetivo de 19 TB (RAID5) para consolidar os dados. Já vi desacelerações significativas ao abrir / navegar / copiar em um computador com cerca de 1,5 TB desse tipo de dados em uma unidade interna dedicada (NTFS).

Cada amostra será copiada para este servidor para armazenamento, mas a análise ocorrerá em outro lugar (dados copiados do servidor). Portanto, nenhuma alteração diária nos dados existentes, apenas novos dados.

Qual é a melhor configuração de unidade para lidar com esse tipo de dados? O drive é GPT e atualmente possui partição do sistema EFI, MSR, 70 GB e partição de dados vazia de 19 TB.

  • um grande volume de 19 TB
  • vários volumes menores (menos fragmentação?)

seria aconselhável criar um arquivo zip por amostra e armazená-lo? Eu hesitaria sobre isso porque os usuários entendem as pastas intuitivamente, e a corrupção tem efeitos piores nos arquivos - poderíamos ter algumas subpastas corrompidas (sample 'pixels', mais ou menos) no caso extremo, mas corrompendo um arquivo de amostra inteiro seria ruim.

    
por Isaiah 05.01.2012 / 21:11

2 respostas

4

19 TB em um único volume RAID-5 é muito grande. Você não menciona quantos discos tem nesse volume, mas, estando em um Dell T710, é altamente provável que você tenha mais de 1 TB por disco. Eu fico ansioso com os membros do RAID-5 sendo tão grandes. Se é um único período RAID-5, isso é ainda mais assustador para mim. (Eu não gosto de um intervalo maior que 5 ou 6 discos, especialmente com discos grandes).

A sua escolha de RAID-5 de lado, na minha experiência, é um número bastante grande de arquivos a serem solicitados pelo NTFS. Qualquer coisa que você possa fazer para reduzir o número de arquivos armazenados ajudará no desempenho. Compactar a "amostra", conforme descrito, reduziria radicalmente o número de arquivos que você está solicitando para o NTFS manipular. Dependendo de quão bem seus dados são comprimidos, você também poderá ver um aumento significativo no desempenho na transferência de arquivos pela rede.

Na minha opinião, você não deve se preocupar com a "corrupção" dos dados. Se você não tem fé suficiente para que seu sistema de backup e armazenamento primário funcionem sem corromper os arquivos, concentre-se em reforçar esses componentes de "fundação". RAID-10 ou RAID-50 seria um bom primeiro passo para reforçar o armazenamento primário. Desde que você não fala sobre como você está fazendo backup eu realmente não posso falar sobre isso.

Editar:

Desconfio do RAID-5 pela disponibilidade. O artigo original sobre isso é Por que o RAID 5 para de funcionar em 2009 . A essência é que as taxas de erro de bits em discos maiores tornam as reconstruções de grandes volumes RAID-5 estatisticamente improváveis.

Se você tiver outra cópia dos dados fora do site, provavelmente será uma preocupação menor. Você deve pensar em qual seria a ramificação de uma perda completa do volume RAID-5. Você conseguirá criar um novo volume e continuar trabalhando enquanto copia os dados da cópia fora do site? Você precisará aguardar a cópia de alguns dados antes que o trabalho possa começar de novo? Se houver tempo ocioso, qual será o custo?

    
por 05.01.2012 / 21:31
0

Você perdeu espaço em disco se tiver muitos arquivos pequenos. O motivo é o tamanho do bloco do seu sistema de arquivos. Minha primeira sugestão é usar um sistema Linux para suporte a longo prazo. E minha segunda sugestão é salvar os arquivos sem zipar no sistema de arquivos porque entender o sistema é muito mais importante se perder alguns bytes. Eu tive o mesmo problema com dados genômicos (analisador de espingarda). Minha terceira sugestão é usar um RAID10 ou RAID50.

    
por 05.01.2012 / 23:39