Dicas para armazenar eficientemente 25 TB + 1 milhão de arquivos no sistema de arquivos

11

Digamos que você enfrente 25 TB de arquivos de registro não compactados e tenha à sua disposição uma variedade de 20 caixas com capacidade de armazenamento coletivo de 25 TB.

Como você os armazenaria?

a) Qual sistema de arquivos distribuído usar?

b) Qual formato / algoritmo de compressão / descompressão?

c) O tamanho do arquivo de log é de 1 MB para no máximo 7 MB de todo o texto e muitos espaços em branco

d) O uso é    a) as pessoas querem os arquivos de log mais recentes que os anteriores, então, qual sistema de cache usar?    b) as pessoas só vão ler arquivos de log não excluí-los    c) as pessoas querem a listagem de arquivos de log em um intervalo de datas

e) O sistema operacional em execução nas caixas de mercadorias é Linux,

f) Quanto ao backup, temos uma matriz de armazenamento que cuida disso. Portanto, a capacidade de restaurar dados da matriz existe.

Eu não quero que eles acessem o sistema de arquivos diretamente. O que devo fazer ? Como faço para obter uma API baseada em REST para isso?

Por favor, poupe 2 centavos e o que você faria?

Ankur

    
por Ankur Gupta 11.10.2010 / 05:50

6 respostas

7

Eu não sou um ninja de sistema de arquivos distribuído, mas depois de consolidar o máximo de unidades possíveis, eu tentaria usar o iSCSI para conectar a maioria das máquinas a uma máquina principal. Lá eu poderia consolidar as coisas em esperançosamente um armazenamento tolerante a falhas. De preferência, tolerante a falhas dentro de uma máquina (se um inversor se apagar) e entre máquinas (se uma máquina inteira estiver desligada).

Pessoalmente, gosto do ZFS. Nesse caso, a compilação em compactação, desduplicação e tolerância a falhas seria útil. No entanto, tenho certeza de que há muitas outras maneiras de compactar os dados e, ao mesmo tempo, torná-los tolerantes a falhas.

Gostaria de ter uma solução real de arquivo distribuído pronta para uso, eu sei que isso é realmente confuso, mas espero que você esteja na direção certa.

Editar: ainda sou novo no ZFS e configuro o iSCSI, mas lembrei de ter visto um vídeo da Sun na Alemanha, onde eles mostravam a tolerância a falhas do ZFS. Eles conectaram três hubs USB a um computador e colocaram quatro pen drives em cada hub. Então, para evitar que qualquer hub baixasse o pool de armazenamento, eles criaram um volume RAIDz que consistia em uma unidade flash de cada hub. Em seguida, eles dividem os quatro volumes RAIDz do ZFS juntos. Dessa forma, apenas quatro pen drives foram usados para paridade. Em seguida, claro, o hub desconectado e que degradou todos os zpool, mas todos os dados estavam disponíveis. Nesta configuração, até quatro unidades podem ser perdidas, mas somente se duas unidades não estiverem no mesmo conjunto.

Se essa configuração foi usada com a unidade bruta de cada caixa, isso preservaria mais unidades para dados e não para paridade. Eu ouvi que o FreeNAS pode (ou poderia) compartilhar drives de uma maneira "bruta" via iSCSI, então presumo que o Linux possa fazer o mesmo. Como eu disse, ainda estou aprendendo, mas esse método alternativo seria menos dispendioso do que a minha sugestão anterior. É claro que dependeria do uso do ZFS, que não sei se seria aceitável. Eu sei que geralmente é melhor se ater ao que você sabe se você vai ter que construir / manter / consertar algo, a menos que isso seja uma experiência de aprendizado.

Espero que seja melhor.

Editar: fiz algumas pesquisas e encontrei o vídeo de que falei. A parte em que eles explicam a propagação da unidade flash USB sobre os hubs começa em 2m10s. O vídeo é para demonstrar o servidor de armazenamento "Thumper" (X4500) e como distribuir os discos pelos controladores, por isso, se você tiver uma falha no controlador de disco rígido, seus dados ainda serão bons. (Pessoalmente eu acho que isso é apenas um vídeo de geeks se divertindo. Eu gostaria de ter uma caixa de Thumper, mas minha esposa não gostaria que eu levasse um porta-paletes pela casa.: D Essa é uma grande caixa.)

Editar: Lembrei-me de vir através de um sistema de arquivos distribuídos chamado OpenAFS . Eu não tinha tentado, eu só tinha lido sobre isso. Talvez outros saibam como isso funciona no mundo real.

    
por 11.10.2010 / 07:44
4

Primeiro, os arquivos de log podem ser compactados em proporções muito altas. Eu acho meus arquivos de log compactar em uma proporção de 10: 1. Se eles compactarem até uma proporção de 5: 1, isso significa apenas 5 GB ou 20% da capacidade de armazenamento.

Dado que você tem armazenamento mais que suficiente, o algoritmo de compactação específico não é muito importante. Você poderia ...

  • Use arquivos zip se os usuários do Windows acessarem os arquivos diretamente.
  • Use o gzip se eles forem acessados pelo Linux e a descompactação rápida for importante.
  • Use o bzip2 se eles forem acessados pelo Linux e for importante ter o menor número possível de arquivos.

A grande questão é: como você fornecerá aos usuários acesso fácil a esses arquivos? Parte disso depende de como suas máquinas estão configuradas.

Se você puder colocar armazenamento suficiente em uma única máquina, poderá fazer algo extremamente simples, como um compartilhamento de arquivos do Windows somente leitura. Apenas organize os arquivos em subdiretórios e você estará pronto para usar.

Se você não puder criar um único servidor de arquivos para esses arquivos, poderá achar que precisa de um sistema de arquivos distribuído. O Windows possui um sistema de arquivos distribuídos (DFS) que pode atender às suas necessidades.

Se as suas necessidades forem mais avançadas, talvez você queira um aplicativo da Web como um front-end no qual os usuários possam procurar e baixar arquivos de log. Nesse caso, recomendo usar o MogileFS, que é um sistema de arquivos distribuídos projetado para ser usado com um servidor de aplicativos front-end. É muito fácil de integrar com a maioria das linguagens de programação web. Você não pode montá-lo como uma unidade compartilhada no seu computador, mas é de primeira linha como um armazenamento de dados para um aplicativo da Web.

    
por 11.10.2010 / 09:49
2
O

lessfs é um sistema de arquivos de compactação com desduplicação. Embora não resolva todo o problema, talvez valha a pena dar uma olhada como um back-end.

    
por 12.10.2010 / 01:48
2

exporte essas pastas via NFS

monte-os em uma única máquina com o apache em execução (sob a raiz do documento) como uma árvore

use o zip para compactá-los - boa taxa de compactação, o zip pode ser aberto em todos os sistemas operacionais

listar arquivos no Apache - então você está dando aos usuários acesso somente leitura (arquivos de log não devem ser editados, certo)

    
por 12.10.2010 / 03:47
0

Você já pensou em compactar os arquivos de log? Em seguida, faça algo no frontend para descompactá-los antes de servi-los ao usuário final. Talvez um script de CGI.

    
por 11.10.2010 / 08:27
0

@Ankur e @Porch. Eu concordo strongmente com a necessidade de comprimir esses logs.

@jet Eu acho que o esquema mais simples é melhor - assim, o httpd para o usuário final está próximo do ideal. E o backend poderia ser qualquer um.

Minha opinião - divida os registros em dois grupos - pastas "antigas" e "novas".

Mesclá-los na raiz do documento do httpd. Use compressão strong para arquivos antigos (arquivos xz ou 7z, populares para todos os sistemas operacionais) com grandes tamanhos de dicionários e blocos, e até arquivos sólidos.

Use a compactação fs para métodos novos: lessfs (rw, desduplicação + métodos de compactação leve), fusecompress 0.9.x (rw, métodos de compactação leve a strong), btrfs / zfs, squashfs (ro, métodos de compactação leve a strong, alguns dedup, use para logs recém-girados).

Você pode até mesmo transparentemente gravar logs em fs compactados (fusecompress, lessfs, btrfs / zfs). Fornece acesso R / o pelo httpd aos logs que estão sendo gravados. Eles serão transparentes para os usuários e transparentemente descompactados para eles.

Avisos sobre o fusecompress: 1) use somente 0.9.x - é estável. Clone daqui link

As versões posteriores não suportam bem o lzma ou perdem dados.

2) usa apenas 1 cpu para compactar um arquivo, portanto pode ser lento.

Recompile cada registro na pasta 'new', mais do que algum tempo (vários meses) e passar para 'velho'.

    
por 21.04.2017 / 15:17