Temos um servidor de armazenamento central (PowerEdge R720) que atende arquivos compartilhados para um cluster HPC e possui dois controladores RAID de hardware conectados (PERC H810, cada um acionando 2 gabinetes MD1200 preenchidos com discos de 4 TB de 7.200 rpm). Tal 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 proporcionaria melhor rendimento total, mas a ideia do RAID 0 de software sobre o RAID de hardware parece uma loucura para mim.
Eu vim com duas opções:
- NFS em XFS em software RAID 0 em hardware RAID 6
- brilho em cada hardware RAID 6
Prós do XFS: cota do projeto.
Contras do XFS: O NFS no XFS mostrou um desempenho de metadados muito ruim (seria degradado para quase inutilizável quando houvesse uma grande taxa de transferência, eu ajustei errado?).
prós do brilho: desempenho de metadados significativamente melhor.
brilho contras (?): não temos nenhum dispositivo de metadados dedicado, precisamos particionar um array. Parece não ser uma prática recomendada.
Consideramos o desempenho dos metadados porque, embora R/W sequencial seja a carga de trabalho principal, temos alguns programas trabalhando com algo em torno de 40 mil arquivos de 1 GB. O gerenciamento interativo desses arquivos requer um desempenho aceitável de metadados.
E finalmente uma pergunta: quais tamanhos de stripe usar no hardware e no software?
Responder1
Decidimos esta configuração:
- Hardware RAID-6 em cada gabinete MD1200
- Dois LVs LVM nos quatro arrays de hardware, cada um combinando os dois arrays nas duas placas, sem striping
- XFS nos dois LVs, opções de distribuição iguais às dos arrays de hardware simples
- Um volume brilhante nos dois tijolos, sem listras
Investigamos todos os aplicativos de nossos usuários e descobrimos que todos eles operam em muitos arquivos. Portanto, não é a situação em que muitos clientes acessam um único arquivo grande, onde a distribuição no nível de brilho é desejada; em vez disso, apenas distribuir arquivos aleatoriamente entre os blocos é capaz de fornecer rendimento total suficiente.
Embora o desempenho dos metadados desta configuração seja pior do que o do brilho (cerca de metade), ele não se degrada quando há uma grande taxa de transferência em andamento. Acabou sendo aceitável.
O Gluster configura cotas em diretórios, além de ser muito mais fácil de configurar do que o lustre, portanto, requer significativamente menos esforços de administração do que o lustre. Em meus testes (aproximados), o rendimento sequencial dessa configuração está no mesmo nível do brilho, então decidimos trocar essa parte no desempenho dos metadados para facilitar a administração.