PowerEdge: Dell Ready Solutions for HPC BeeGFS — Armazenamento de alto desempenho

Artigo escrito por Nirmala Sundararajan, do Laboratório de inovação em IA e HPC da Dell, em novembro de 2019

Sumário

1. Introdução
2. Arquitetura de referência da solução
3. Configuração de hardware e software
4. Detalhes da configuração da solução
   • Serviço de gerenciamento
   • Serviço de metadados
   • Serviço de armazenamento
   • Client Services
5. R740xd, 24 unidades NVMe, detalhes sobre mapeamento de CPU
6. Caracterização de desempenho
   • Leituras e gravações sequenciais N-N
   • Leituras e gravações aleatórias N-N
7. Conclusão e trabalhos futuros
    

Introdução

A equipe de HPC da Dell orgulhosamente anuncia o lançamento das "Dell EMC Ready Solutions for HPC BeeGFS Storage", que é a mais recente adição ao portfólio de armazenamento de HPC. Esta solução usa servidores R740xd, cada um com 24 unidades NVMe Intel P4600 de 1,6 TB, de uso misto Express Flash e dois adaptadores Mellanox ConnectX-5 InfiniBand EDR. Nessa configuração de 24 unidades NVMe, 12 SSDs NVMe se conectam a um switch PCIe, e cada switch é conectado a uma CPU usando uma placa extensora PCIe x16. Além disso, cada interface IB está conectada a uma CPU. Essa configuração equilibrada com cada CPU conectada a um adaptador InfiniBand e lidando com 12 SSDs NVMe fornece desempenho máximo, garantindo que os processadores estejam igualmente ocupados em lidar com solicitações de E/S de e para as unidades NVMe.

O foco da solução é E/S de alto desempenho e foi projetada como uma solução scratch de alta velocidade. No centro da solução está o uso de SSDs NVMe de alta velocidade que oferecem grande largura de banda e baixa latência, removendo o agendador e os gargalos de enfileiramento da camada de bloco. O file system BeeGFS também é compatível com alto throughput de E/S agregado.

Arquitetura de referência da solução

A Figura 1 mostra a arquitetura de referência da solução. O servidor de gerenciamento só é conectado usando Ethernet aos servidores de metadados e armazenamento. Cada servidor de armazenamento e metadados tem dois links InfiniBand e está conectado à rede privada por Ethernet. Os clients têm um link InfiniBand e estão conectados à interface privada via Ethernet.

Figura 1:  Dell Ready Solutions for HPC BeeGFS Storage — arquitetura de referência

Configuração de hardware e software

As Tabelas 1 e 2 descrevem as especificações de hardware do servidor de gerenciamento e do servidor de metadados/armazenamento, respectivamente. A Tabela 3 descreve as versões de software usadas para a solução.

Detalhes da configuração da solução

A arquitetura BeeGFS consiste em quatro serviços principais:

• Serviço de gerenciamento
• Serviço de metadados
• Serviço de armazenamento
• Client Services

Com exceção do serviço do client, que é um módulo kernel, os serviços de gerenciamento, metadados e armazenamento são processos de espaço do usuário. A Figura 2 ilustra como a arquitetura de referência do Dell EMC Ready Solutions for HPC BeeGFS Storage mapeia a arquitetura geral do file system BeeGFS.

Figura 2:  File system BeeGFS no PowerEdge R740xd com SSDs NVMe

Serviço de gerenciamento

Cada file system ou namespace BeeGFS tem apenas um serviço de gerenciamento. O serviço de gerenciamento é o primeiro serviço que deve ser configurado, pois, quando configuramos todos os outros serviços, eles devem se registrar no serviço de gerenciamento. Um PowerEdge R640 é usado como servidor de gerenciamento. Além de hospedar o serviço de gerenciamento (beegfs-mgmtd.service), ele também hospeda o serviço de monitoramento (beegfs-mon.service), que coleta estatísticas do sistema e as fornece ao usuário, usando o banco de dados de série temporal InfluxDB. Para visualização de dados, o beegfs-mon fornece painéis predefinidos do Grafana que podem ser usados de forma integrada. O servidor de gerenciamento tem 6 discos rígidos de 300 GB configurados no RAID 10 para o sistema operacional e o InfluxDB.

Serviço de metadados

O serviço de metadados é um serviço de scale-out, o que significa que pode haver muitos serviços de metadados em um file system BeeGFS. No entanto, cada serviço de metadados tem exatamente um destino de metadados para armazenar metadados. No destino de metadados, o BeeGFS cria um arquivo de metadados por arquivo criado pelo usuário. Os metadados do BeeGFS são distribuídos por diretório. O serviço de metadados fornece as informações de fracionamento de dados aos clients e não está envolvido no acesso aos dados entre o arquivo aberto/fechado.

Um PowerEdge R740xd com 24 unidades NVMe Intel P4600 de 1,6 TB é usado para armazenamento de metadados. Como os requisitos de capacidade de armazenamento para metadados do BeeGFS são muito pequenos, em vez de usar um servidor de metadados dedicado, apenas as 12 unidades na zona NUMA 0 foram usadas para hospedar os metadadosTargets (MDTs), enquanto as 12 unidades restantes na zona NUMA armazenam Targets (STs).

A Figura 3 mostra o servidor de metadados. As 12 unidades contidas no retângulo amarelo são os MDTs na zona NUMA 0, enquanto as 12 unidades contidas no retângulo verde são os STs na zona NUMA 1. Essa configuração não só evita problemas de NUMA, mas também fornece armazenamento de metadados suficiente para facilitar o dimensionamento da capacidade e do desempenho conforme necessário.

Figura 3:  Servidor de metadados

A Figura 4 mostra a configuração de RAID do servidor de metadados. Ele destaca como, no servidor de metadados, as unidades na zona NUMA 0 hospedam os MDTs e as na zona NUMA 1 hospedam os dados de armazenamento, enquanto os servidores de armazenamento hospedam os STs nas duas zonas NUMA.

Figura 4:  Configuração de unidades no servidor

de metadados As 12 unidades usadas para metadados são configuradas como um grupo de discos RAID 1 6x de duas unidades, cada uma servindo como um MDT. Há seis serviços de metadados em execução, cada um dos quais lida com um MDT. As 12 unidades de armazenamento restantes são configuradas em 3x grupos de discos RAID 0 de quatro unidades cada. Há três serviços de armazenamento em execução na zona NUMA 1, um serviço para cada ST. O servidor que co-hospeda os metadados e os destinos de armazenamento têm 6 MDTs e 3 STs. Ele também executa seis serviços de metadados e três serviços de armazenamento. Cada MDT é um file system ext4 baseado em uma configuração de RAID 1. Os STs são baseados em um sistema de arquivos XFS configurado no RAID 0.
 

Serviço de armazenamento

Assim como o serviço de metadados, o serviço de armazenamento também é um serviço de scale-out. Pode haver muitas instâncias do serviço de armazenamento em um file system BeeGFS. No entanto, diferentemente do serviço de metadados, pode haver vários destinos de armazenamento por serviço de armazenamento. O serviço de armazenamento armazena o conteúdo do arquivo do usuário fracionado, também conhecido como arquivos de fragmento de dados.

A Figura 5 mostra os 5 servidores PowerEdge R740xd usados como servidores de armazenamento.

Figura 5:  Servidores

de armazenamento dedicados Cada servidor de armazenamento é configurado com 6 grupos de RAID 0, cada um com quatro unidades, hospedando, assim, 6 STs por servidor (3 por zona NUMA), conforme mostrado na Figura 6 abaixo:

Figura 6:  Configuração de unidades nos servidores

de armazenamento No total, a configuração básica da arquitetura de referência hospeda 6 MDTs e 33 STs. Ter cinco servidores de armazenamento dedicados oferece uma capacidade bruta de 211 TB e uma capacidade útil de 190 TiB. A capacidade útil estimada em TiB = número de unidades x capacidade por unidade em TB x 0,99 (sobrecarga do file system) x (10^12/2^40). Isso seria ideal como uma solução intermediária com armazenamento de metadados suficiente para facilitar a adição de mais servidores de armazenamento à medida que os requisitos de capacidade aumentam.

Em vista dos seguintes fatores, uma configuração de RAID 0 foi escolhida para destinos de armazenamento em relação à configuração RAID 10.

1. O desempenho de gravação foi medido usando o comando dd criando um arquivo de 10 GB de tamanho de bloco de 1 MB e E/S direta para dados. Para dispositivos RAID 0, a média foi de cerca de 5,1 GB/s para cada dispositivo, enquanto para dispositivos RAID 10 a média foi de 3,4 GB/s para cada dispositivo.
2. Os testes de referência de desempenho do StorageBench mostraram que o throughput máximo foi de 5,5 GB/s para a configuração RAID 0, enquanto é de 3,4 GB/s para uma configuração RAID 10. Esses resultados são semelhantes aos obtidos usando comandos dd.
3. O RAID 10 fornece 50% de utilização da capacidade do disco e uma redução semelhante de 50% no desempenho de gravação. O uso do RAID 10 é uma maneira dispendiosa de obter redundância de armazenamento.
4. As unidades NVMe são caras e oferecem acelerações que são mais bem utilizadas em uma configuração RAID 0

Client Services

O módulo client BeeGFS deve ser carregado em todos os hosts que devem acessar o sistema de arquivos BeeGFSs. Quando o beegfs-client é carregado, ele monta os file systems definidos no arquivo/etc/beegfs/beegfs-mounts.conf em vez da abordagem usual baseada em /etc/fstab. A adoção dessa abordagem inicia o client BeeGFS como qualquer outro serviço Linux usando o script de inicialização do serviço. Ele também permite a recompilação automática do módulo client BeeGFS após as atualizações do sistema. 

Quando o módulo client é carregado, ele monta os file systems definidos no beegfs-mounts.conf. É possível montar várias instâncias BeeGFS no mesmo client, conforme mostrado abaixo:

$ cat /etc/beegfs/beegfs-mounts.conf
/mnt/beegfs-medium /etc/beegfs/beegfs-client-medium.conf
/mnt/beegfs-small /etc/beegfs/beegfs-client-small.conf

O exemplo acima mostra dois file systems diferentes montados no mesmo client. Para a finalidade deste teste, 32 nós C6420 foram usados como clients.

R740xd, 24 unidades NVMe, detalhes sobre mapeamento de CPU

Na configuração 24x NVMe do servidor PowerEdge R740xd, há duas placas bridge NVMe x16 alimentando o switch PCIe no backplane que executa fan-out e alimenta as unidades (as unidades são x4) na parte frontal, conforme mostrado na Figura 7 abaixo:


Figura 7:  R740xd, 24x unidades NVMe, detalhes sobre mapeamento de CPU

No acesso não uniforme à memória (NUMA), a memória do sistema é dividida em zonas chamadas nós, que são alocadas para CPUs ou soquetes. O acesso à memória local de uma CPU é mais rápido do que a memória conectada a CPUs remotas no sistema. Um aplicativo com thread normalmente funciona melhor quando os threads estão acessando a memória no mesmo nó com NUMA. O impacto sobre o desempenho das falhas de NUMA é significativo, geralmente começando com um impacto de desempenho de 10% ou mais. Para melhorar o desempenho, os serviços são configurados para usar zonas NUMA específicas a fim de evitar o uso desnecessário de links entre soquetes UPI, reduzindo assim a latência. Cada zona NUMA gerencia 12 unidades e usa uma das duas interfaces InfiniBand EDR nos servidores. Essa separação de NUMA é alcançada configurando manualmente o balanceamento de NUMA criando arquivos de unidade do sistema personalizados e configurando o multihoming. Portanto, o balanceamento automático de NUMA é desativado, conforme mostrado abaixo:

# cat /proc/sys/kernel/numa_balancing
0

A Figura 8 mostra o testbed onde as conexões InfiniBand com a zona NUMA são realçadas. Cada servidor tem dois links IP, e o tráfego pela zona NUMA 0 é entregue pela interface IB0, enquanto o tráfego pela zona NUMA 1 é manipulado pela interface IB1.

Figura 8:  Configuração do ambiente de teste
 

Caracterização de desempenho

Esta seção apresenta a avaliação de desempenho que caracteriza a Dell EMC Ready Solution for HPC BeeGFS High-Performance Storage Solution. Para obter mais detalhes e atualizações, procure um white paper oficial que será publicado mais tarde. O desempenho do sistema foi avaliado usando a referência de desempenho IOzone. A solução foi testada para verificar o throughput sequencial de leitura e gravação e a IOPS de leitura e gravação aleatórias. A Tabela 4 descreve a configuração dos servidores C6420 que foram usados como clientes BeeGFS para os estudos de desempenho neste blog.
 

Leituras e gravações sequenciais N-N

Para avaliar as leituras e gravações sequenciais, a referência de desempenho IOzone foi usada no modo de leitura e gravação sequenciais. Esses testes foram realizados em várias contagens de threads, começando em um thread e aumentando em potências de 2, até 1024 threads. A cada contagem de thread foi gerado um número idêntico de arquivos, pois esse teste funciona em um arquivo por thread ou caso de N clients para N arquivo (N-N). Os processos foram distribuídos em 32 nós de client físicos em um rodízio ou modo cíclico para que as solicitações sejam distribuídas igualmente e haja balanceamento de carga. O tamanho do arquivo agregado de 8 TB foi selecionado, que foi dividido igualmente entre o número de threads dentro de qualquer teste determinado. O tamanho do arquivo agregado foi escolhido grande o suficiente para minimizar os efeitos do armazenamento em cache dos servidores e dos clientes BeeGFS. O IOzone foi executado em um modo combinado de gravação e leitura (-i 0, -i 1) para permitir a coordenação dos limites entre as operações. Para esses testes e resultados, usamos um tamanho de registro de 1MB para cada corrida. Os comandos usados para testes sequenciais N-N são fornecidos abaixo:

Gravações e leituras sequenciais: iozone -i 0 -i 1 -c -e -w -r 1m -I -s $Size -t $Thread -+n -+m /path/to/threadlist

Os caches do sistema operacional também foram descartados ou limpos nos nós do client entre as iterações e entre os testes de gravação e leitura executando o comando:

# sync && echo 3 > /proc/sys/vm/drop_caches

A contagem padrão de faixas para BeeGFS é 4. No entanto, o tamanho do fragmento e o número de destinos por arquivo podem ser configurados por diretório. Para todos esses testes, o tamanho da fração do BeeGFS foi escolhido para 2 MB e a contagem de faixas foi escolhida para ser 3, pois temos três alvos por zona NUMA, conforme mostrado abaixo:

$ beegfs-ctl --getentryinfo --mount=/mnt/beegfs /mnt/beegfs/benchmark --verbose
EntryID: 0-5D9BA1BC-1
ParentID: root
Metadata node: node001-numa0-4 [ID: 4]
Stripe pattern details:
+ Type: RAID0
+ Chunksize: 2M
+ Number of storage targets: desired: 3
+ Storage Pool: 1 (Default)
Inode hash path: 7/5E/0-5D9BA1BC-1

As páginas enormes transparentes foram desativadas e as seguintes opções de ajuste estão em vigor nos servidores de armazenamento e metadados:

vm.dirty_background_ratio = 5 
vm.dirty_ratio = 20 
vm.min_free_kbytes = 262144 
vm.vfs_cache_pressure = 50
vm.zone_reclaim_mode = 2 
kernel.numa_balancing = 0

Além das opções acima, foram usadas as seguintes opções de ajuste do BeeGFS: 

• tuneTargetChooser parâmetro foi definido como "roundrobin" no arquivo de configuração de metadados 
• tuneNumWorkers parâmetro foi definido como 24 para metadados e 32 para armazenamento 
• connMaxInternodeNum parâmetro foi definido como 32 para metadados, 12 para armazenamento e 24 para clients

Figura 9:  Tamanho agregado de arquivo de 8 TB da zona de E/S sequencial.

Na Figura 9, vemos que o pico de desempenho de leitura é de 132 GB/s a 1.024 threads e o pico de gravação é de 121 GB/s a 256 threads. Cada unidade pode fornecer desempenho de leitura de pico de 3,2 GB/s e desempenho de gravação de pico de 1,3 GB/s, o que permite um pico teórico de 422 GB/s para leituras e 172 GB/s para gravações. No entanto, aqui a rede é o fator limitante. Temos um total de 11 links InfiniBand EDR para os servidores de armazenamento na configuração. Cada link pode fornecer um desempenho de pico teórico de 12,4 GB/s, o que permite um desempenho de pico teórico de 136,4 GB/s. O pico de desempenho de leitura e gravação alcançado é de 97% e 89%, respectivamente, do desempenho de pico teórico.

O desempenho de thread único observado é de cerca de 3 GB/s para gravação e cerca de 3 GB/s para leitura. Observamos que o desempenho de gravação é dimensionado linearmente, atinge picos de 256 threads e, em seguida, começa a diminuir. Em contagens de threads inferiores, o desempenho de leitura e gravação é o mesmo. Porque até oito threads, temos oito clients gravando oito arquivos em 24 destinos, o que significa que nem todos os destinos de armazenamento estão sendo totalmente usados. Temos 33 destinos de armazenamento no sistema e, portanto, pelo menos 11 threads são necessários para usar totalmente todos os servidores. O desempenho de leitura registra um aumento linear constante com o aumento no número de threads simultâneos, e observamos desempenho quase semelhante em 512 e 1024 threads.

Também observamos que o desempenho de leitura é menor do que as gravações para contagens de threads de 16 a 128 e, em seguida, o desempenho de leitura começa a ser dimensionado. Isso ocorre porque, embora uma operação de leitura PCIe seja uma operação não publicada, exigindo uma solicitação e uma conclusão, uma operação de gravação PCIe é uma operação do tipo disparar e esquecer. Depois que o pacote de camada de transação é entregue à camada de link de dados, a operação é concluída. Uma operação de gravação é uma operação "publicada" que consiste apenas em uma solicitação.

O throughput de leitura geralmente é menor do que o throughput de gravação, pois as leituras exigem duas transações em vez de uma única gravação para o mesmo volume de dados. O PCI Express usa um modelo de transação dividida para leituras. A transação de leitura inclui as seguintes etapas:

• O solicitante envia uma solicitação de leitura de memória (MRR).
• O preenchedor envia a confirmação ao MRR.
• O concluinte retorna uma conclusão com dados.

O throughput de leitura depende do atraso entre o tempo em que a solicitação de leitura é emitida e o tempo que o preenchedor leva para retornar os dados. No entanto, quando o aplicativo emite um número suficiente de solicitações de leitura para cobrir esse atraso, o throughput é maximizado. Esse é o motivo pelo qual, embora o desempenho de leitura seja menor que o das gravações de 16 threads para 128 threads, medimos um maior throughput quando o número de solicitações aumenta. Um throughput menor é medido quando o solicitante aguarda a conclusão antes da emissão de solicitações subsequentes. Um throughput maior é registrado quando várias solicitações são emitidas para amortizar o atraso após a devolução dos primeiros dados.

Leituras e gravações aleatórias N-N

Para avaliar o desempenho de E/S aleatório, o IOzone foi usado no modo aleatório. Foram realizados testes com contagens de threads a partir de 4 até 1.024 threads. A opção de E/S direta (-I) foi usada para executar o IOzone para que todas as operações ignorem o cache do buffer e acessem diretamente o disco. A contagem de faixa do BeeGFS de 3 e o tamanho de faixa de 2 MB foram usados. Um tamanho de solicitação de 4 KiB foi usado no IOzone. A performance é avaliada em operações de E/S por segundo (IOPS). Os caches do sistema operacional foram descartados entre as execuções nos servidores BeeGFS e nos clientes BeeGFS. O comando usado para executar as leituras e gravações aleatórias é fornecido abaixo:

Leituras e gravações aleatórias: iozone -i 2 -w -c -O -I -r 4K -s $Size -t $Thread -+n -+m /path/to/threadlist

Figura 10:  Desempenho de leitura e gravação aleatórias usando a zona de E/S com tamanho agregado de arquivo de 8 TB.

As gravações aleatórias atingem um pico de ~3,6 milhões de IOPS em 512 threads e as leituras aleatórias atingem um pico de ~3,5 milhões de IOPS em 1024 threads, conforme mostrado na Figura 10. O desempenho de leitura e gravação mostra um desempenho mais alto quando há um número maior de solicitações de E/S. Isso ocorre porque o padrão NVMe suporta até 64 mil filas de E/S e até 64 mil comandos por fila. Esse grande pool de filas de NVMe fornece níveis mais altos de paralelismo de E/S e, portanto, observamos IOPS superior a 3 milhões.

Conclusão e trabalhos futuros

Este blog anuncia o lançamento da solução de armazenamento BeeGFS de alto desempenho da Dell EMC e destaca suas características de desempenho. A solução tem um pico de desempenho sequencial de leitura e gravação de cerca de 132 GB/s e cerca de 121 GB/s, respectivamente, e o pico de gravações aleatórias é de cerca de 3,6 milhões de IOPS e leituras aleatórias cerca de 3,5 milhões de IOPS.

Este blog faz parte da "Solução de armazenamento BeeGFS", que foi projetada com foco no espaço transitório com alto desempenho. Fique ligado na Parte 2 da série de blogs que descreverá como a solução pode ser dimensionada aumentando o número de servidores para aumentar o desempenho e a capacidade. A parte 3 da série de blogs discutirá os recursos adicionais do BeeGFS e destacará o uso do "StorageBench", a referência de desempenho de destinos de armazenamento integrado do BeeGFS.

Como parte das próximas etapas, publicaremos posteriormente um white paper com o desempenho dos metadados e os threads N para um arquivo de desempenho de IOR e com detalhes adicionais sobre considerações de projeto, ajuste e configuração.

Referências

[1] Documentação do BeeGFS:  https://www.beegfs.io/wiki/
[2] Como conectar duas interfaces na mesma sub-rede:  https://access.redhat.com/solutions/30564