load balancing em vários arrays de raids de hardware - soft raid 0 aceitável?

3

Temos um servidor de armazenamento central (PowerEdge R720) servindo arquivos compartilhados para um cluster HPC, e ele tem dois controladores RAID de hardware conectados (PERC H810, cada um dirigindo 2 compartimentos MD1200 preenchidos com discos 7200rpm 4TB). Como acontece com a carga de trabalho típica de HPC, espera-se que o padrão de acesso seja leituras / gravações sequenciais altamente paralelas. Suponho que distribuir arquivos para os dois arrays daria uma taxa de transferência total melhor, mas a idéia do software RAID 0 no topo do hardware RAID parece loucura para mim.

Eu criei duas opções:

  1. NFS no XFS no software RAID 0 no hardware RAID 6
  2. brilho em cada hardware RAID 6

Profissionais do XFS: cota do projeto.

XFS contras: NFS no XFS mostrou desempenho de metadados muito ruim (degradaria quase inutilizável quando há um grande throughput nele, eu o ajustei errado?).

profissionais de brilho: desempenho de metadados significativamente melhor.

lustre cons (?): não temos dispositivos de metadados dedicados, temos que particionar um array. Parece não ser uma prática recomendada.

Nós consideramos o desempenho de metadados, porque enquanto a R / W sequencial é a principal carga de trabalho, temos alguns programas trabalhando com algo como ~ 40k arquivos de 1GB. Gerenciar esses arquivos interativamente requer um desempenho de metadados aceitável.

E, finalmente, uma pergunta: que tamanhos de faixa usar no hardware e no software?

    
por Carl Lei 17.06.2015 / 06:29

1 resposta

1

Nos estabelecemos nesta configuração:

  • Hardware RAID-6 em cada gabinete MD1200
  • Dois LVs LVM nos quatro arrays de hardware, cada um combinando os dois arrays nos dois cartões, sem separar
  • XFS nos dois LVs, opções de distribuição iguais às de matrizes de hardware nuas
  • Um volume brilhante nos dois tijolos, sem separar

Investigamos todos os aplicativos de nossos usuários e descobrimos que todos eles operam em vários arquivos. Assim, não é a situação em que muitos clientes estão acessando um único arquivo grande, onde a distribuição no nível de brilho é desejada; em vez disso, apenas distribuir arquivos aleatoriamente para os tijolos é capaz de fornecer um throughput total suficiente.

Embora o desempenho de metadados dessa configuração seja pior do que o de brilho (aproximadamente a metade), ele não se degrada quando há uma grande taxa de transferência acontecendo. Acabou sendo aceitável.

O Gluster configura cota em diretórios, além de ser muito mais fácil de configurar do que o brilho, portanto, requer menos esforços de administração do que brilho. Nos meus (ásperos) testes, a taxa de transferência seqüencial dessa configuração está no mesmo nível do brilho, então decidimos trocar essa parte no desempenho de metadados para facilitar a administração.

    
por 03.09.2015 / 06:10