Dell EMC Ready Solutions for HPC BeeGFS Storage: armazenamento de alto desempenho

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

Dell EMC Ready Solutions for HPC BeeGFS Storage: armazenamento de alto desempenho

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

Arquitetura de referência da solução

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 armazenamento/metadados, respectivamente. A Tabela 3 descreve as versões de software usadas para a solução.

Detalhes da configuração da solução

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

Serviço de gerenciamento

Serviço de metadados

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.

Serviço de armazenamento

1. O desempenho de gravação foi medido usando o comando dd criando um arquivo de 10 GiB com tamanho de bloco de 1 MiB 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 de RAID 0, enquanto que é 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 aumentos de velocidade que são mais utilizadas em uma configuração RAID 0

Client Services

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

R740xd, 24 unidades NVMe, detalhes sobre mapeamento de CPU

# cat /proc/sys/kernel/numa_balancing
0

Caracterização de desempenho

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 com várias contagens de threads, começando por 1 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 de caching de servidores, bem como nos clients 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 1 MiB para cada execução. Os comandos usados para testes sequenciais N-N são fornecidos abaixo:

Leituras e gravações 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 iterações, bem como entre testes de leitura e gravação 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. Em todos esses testes, o tamanho da fração BeeGFS foi escolhido para ser de 2 MB e a contagem de faixas foi escolhida para ser 3, pois temos três destinos 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: 

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

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é 8 threads, temos 8 clients gravando 8 arquivos em 24 destinos, o que significa que nem todos os destinos de armazenamento estão sendo totalmente utilizados. Temos 33 destinos de armazenamento no sistema e, portanto, pelo menos 11 threads são necessários para utilizar 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 um 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 concluinte 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 concluinte leva para devolver 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 ignorados entre as execuções nos servidores BeeGFS, assim como os clients BeeGFS. O comando usado para executar as gravações e leituras 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 IOzone com tamanho de arquivo agregado de 8 TB

O pico de gravações aleatórias é de cerca de 3,6 milhões de IOPS a 512 threads e o pico de leituras aleatórias cerca de 3,5 milhões de IOPS a 1.024 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 NVMe oferece 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á 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 um white paper posteriormente com o desempenho dos metadados e o desempenho de IOR de N threads para 1 arquivo e com detalhes adicionais sobre considerações de design, ajuste e configuração.

Referências