Como devo organizar partições / LVs para um servidor espelho de 30TB?

1

Estou planejando atualizar um servidor espelho de software gratuito e gostaria de receber conselhos sobre a configuração dos novos discos primários.

Meu uso atual:

  • software de sistema, configuração e área de trabalho < 30 GB - permanece na matriz RAID-1
  • coisas que estão em uma única partição de 900 GB (quatro discos RAID-5)
    • 2-3 pequenos espelhos < 1G
    • um espelho de 600 MB com muitos arquivos pequenos (portage)
    • dois ~ 5GB espelhos
    • cinco espelhos de 20 a 40 GB
    • dois espelhos de 100 GB
    • três espelhos de 150 GB

Provavelmente terei 44TB de discos, distribuídos em três arrays RAID-5 de hardware para um total de 34 TB (mais peças de reposição).

Eu pensei em fazer os arrays em PVs do LVM2 e construir um VG de 34 TB, o qual eu de alguma forma dividiria, criando um LV para cada espelho. Então eu teria um volume extN ou XFS para cada uma das distribuições.

Um problema é que não posso prever o crescimento de nenhum dos espelhos. Eu posso ter que criar muita sobrecarga em cada LV ou aumentar os LVs frequentemente. O encolhimento do espelho principal não é realmente uma preocupação; eles continuam ficando maiores e maiores. Existe alguma perda real de desempenho devido ao aumento da fragmentação se alguém redimensiona um VE muitas vezes?

Eu posso querer otimizar alguns dos sistemas de arquivos para cargas de trabalho específicas, como pequenos arquivos de texto ou imagens de CD, o que é uma greve contra o uso de um único FS. A abordagem multi-FS me permitiria rastrear padrões de uso de disco por distribuição mais facilmente. Uma possível desvantagem final de manter o one-big-FS é a latência quando o sistema operacional pesquisa a árvore. Quanta preocupação é essa?

Eu tenho 24 ou 48GB de RAM, e pretendo servir 30-50TB por mês, com vários arquivos grandes (instaladores, imagens de CD) atingindo o cache e muitos arquivos de 2-20MB faltando.

    
por user75636 24.03.2011 / 06:40

2 respostas

1

Primeiro, fique longe do RAID. Não vale a pena. Com uma reconstrução de 14TB, a matriz vai demorar dias. Você não quer que seus discos fiquem agitados por dias, então é melhor perder uma parte do espelho e buscar os dados novamente quando o disco for substituído.

O LVM é bom e, certamente, algo a ser usado em seus espelhos menores, mas não tenho certeza se é muito útil para o armazenamento principal. O problema com o LVM é que uma falha de qualquer coisa tira todo o PV, então você não quer enormes PVs.

Você pode se deparar com problemas de balanceamento de carga do IO, o que o forçará a balancear o IO entre os discos (por exemplo, seu espelho do Ubuntu provavelmente será atingido com força). Portanto, eu recomendo que você use algum tipo de camada que permita redistribuir a carga de IO entre os discos.

Uma solução típica ao lidar com armazenamento espelhado grande e crescente é criar uma camada de abstração que controla onde os arquivos estão localizados no disco (geralmente usando um banco de dados) e distribuir os arquivos por vários discos físicos sem redundância . Isso está embutido em muitas soluções NAS.

Você pode encontrar mais algumas informações em uma resposta anterior aqui .

    
por 24.03.2011 / 10:12
1

Considerando o tamanho do array e o fato de que você irá expandi-lo em breve, eu recomendaria usar o RAID-6 em vez do RAID-5 + spares para o array. Na minha reconstrução de hardware de matriz de 20 TB leva cerca de 2-3 semanas, por isso, se você usar RAID-5 e uma unidade falhar, você estará em risco por longo período de tempo durante a reconstrução. Também é bem documentado o fato de que muitas falhas ocorrem durante a reconstrução, o que é fatal para o array RAID-5.

Não posso comentar sobre o particionamento. Eu pessoalmente evito ter muitas partições e eu prefiro ter uma grande partição para tudo (bem, talvez duas :-), às vezes trocando ganhos potenciais de desempenho em favor da facilidade de gerenciamento e conveniência.

Eu também estava praticando um pequeno SSD para partição do sistema ultimamente, principalmente por causa da confiabilidade das unidades SSD. Essa prática ainda é considerada questionável por muitos.

    
por 24.03.2011 / 07:10

Tags