Em todas as referências de desempenho listadas acima, o ambiente de teste tinha os clients conforme descrito na Tabela 2 abaixo. Como o número de nós de computação disponíveis para testes era de apenas 16, quando um número maior de threads era necessário, esses threads eram distribuídos igualmente nos nós de computação (ou seja, 32 threads = 2 threads por nó, 64 threads = 4 threads por nó, 128 threads = 8 threads por nó, 256 threads = 16 threads por nó, 512 threads = 32 threads por nó, 1.024 threads = 64 threads por nó). A intenção era simular um número maior de clients simultâneos com o número limitado de nós de computação disponíveis. Como algumas referências de desempenho oferecem suporte a muitos threads, utilizou-se um valor máximo de até 1.024 (especificado para cada teste), evitando a alternância excessiva de contexto e outros efeitos colaterais relacionados que afetam os resultados de desempenho.

Tabela 2 Ambiente de teste de clients

Desempenho sequencial do IOzone N clients para N arquivos

O desempenho sequencial de N clients para N arquivos foi medido com o IOzone versão 3.487. Os testes executados variaram de thread único até 1.024 threads em incrementos de potências de dois.

Os efeitos do armazenamento em cache sobre os servidores foram minimizados pela configuração do pool de páginas do GPFS ajustável para 16 GiB e pelo uso de arquivos com mais do que o dobro desse tamanho. É importante observar que, para o GPFS, essa opção define a quantidade máxima de memória usada para armazenamento em cache de dados, independentemente da quantidade de RAM instalada e livre. Além disso, é importante observar que, embora nas soluções anteriores de HPC da Dell EMC, o tamanho do bloco para grandes transferências sequenciais seja de 1 MiB, o GPFS foi formatado com 8 blocos MiB e, portanto, esse valor é usado na referência de desempenho para obter o desempenho ideal. Isso pode parecer muito grande e, aparentemente, desperdiçar muito espaço, mas o GPFS usa a alocação de sub-bloco para evitar essa situação. Na configuração atual, cada bloco foi subdividido em 256 sub-blocos de 32 KiB cada.

Os seguintes comandos foram usados para executar a referência de desempenho para leituras e gravações, em que $Threads era a variável com o número de threads usados (1 a 1.024 incrementados em potências de dois), e threadlist era o arquivo que alocou cada thread em um nó diferente, fazendo rodízio para distribuí-los de modo homogêneo entre os 16 nós de computação.

Para evitar possíveis efeitos do cache de dados com base nos clients, o tamanho total de dados dos arquivos foi o dobro da quantidade total de RAM dos clients utilizados. Ou seja, como cada client tem 128 GiB de RAM, para contagens de threads iguais ou superiores a 16 threads, o tamanho do arquivo foi de 4.096 GiB dividido pelo número de threads (a variável $Size abaixo foi usada para gerenciar esse valor). Para os casos com menos de 16 threads (o que significa que cada thread estava em execução em um client diferente), o tamanho do arquivo foi fixado como o dobro da quantidade de memória por client, ou 256 GiB.

iozone -i0 -c -e -w -r 8M -s $ G -t $Threads -+n -+m ./threadlist
iozone -i1 -c -e -w -r 8M -s $ G -t $Threads -+n -+m ./threadlist

Figura 2  Desempenho sequencial de N para N

Com base nos resultados, nós podemos observar que o desempenho de gravação aumenta conforme o número de threads usados e, em seguida, atinge um platô de cerca de 64 threads para gravações e 128 threads para leituras. O desempenho de leitura também aumenta rapidamente de acordo com o número de threads e, depois, fica estável até que o número máximo de threads que o IOzone permite seja atingido e, portanto, o desempenho sequencial de arquivos grandes é estável mesmo para 1.024 clients simultâneos. O desempenho de gravação cai cerca de 10% quando o número de threads atinge 1.024. No entanto, como o cluster de client tem menos do que esse número de núcleos, não se sabe se a queda no desempenho se deve à troca e à sobrecarga semelhante não observada na mídia rotacional (pois a latência de NVMe é muito baixa em comparação com a mídia rotacional) ou se a sincronização de dados do RAID 10 está se tornando um gargalo. Mais clients são necessários para esclarecer esse ponto. Observou-se uma anomalia nas leituras com 64 threads, em que o desempenho não foi dimensionado na taxa observada para os pontos de dados anteriores e, no próximo ponto de dados, avança para um valor muito próximo ao do desempenho sustentado. Mais testes são necessários para encontrar o motivo dessa anomalia, mas isso está fora do escopo desta publicação.

O desempenho máximo de leitura foi inferior ao desempenho teórico dos dispositivos NVMe (cerca de 102 GB/s) ou ao desempenho dos links EDR, mesmo supondo-se que um link tenha sido usado principalmente para o tráfego de NVMe over Fabrics (4 EDR com BW de cerca de 96 GB/s).
No entanto, isso não é uma surpresa, pois a configuração de hardware não é equilibrada em relação aos dispositivos NVMe e aos HCAs IB de cada soquete de CPU. Um adaptador CX6 está na CPU1, enquanto a CPU2 tem todos os dispositivos NVMe e o segundo adaptador CX6. Qualquer tráfego de armazenamento que use o primeiro HCA deve usar as UPIs para acessar os dispositivos NVMe. Além disso, qualquer núcleo usado na CPU1 precisa acessar os dispositivos ou a memória atribuída à CPU2 para que a localidade dos dados seja afetada e os links de UPI sejam usados. Isso pode explicar a redução do desempenho máximo, em comparação com o desempenho máximo dos dispositivos NVMe ou com a velocidade de linha dos HCAs CX6. A alternativa para corrigir essa limitação é ter uma configuração de hardware equilibrada, o que implica reduzir a densidade pela metade usando um R740 com quatro slots x16 e empregar dois expansores PCIe x16 para distribuir igualmente os dispositivos NVMe em duas CPUs e ter um HCA CX6 em cada CPU.

Desempenho sequencial de IOR N clients para 1 arquivo

O desempenho sequencial dos N clients em um único arquivo compartilhado foi medido com a versão IOR 3.3.0, auxiliada pelo OpenMPI v4.0.1 para executar a referência de desempenho nos 16 nós de computação. Os testes executados variaram de thread único até 512 threads, pois não havia núcleos suficientes para 1.024 threads ou mais. Esses testes de referência de desempenho usaram 8 blocos MiB para obter o desempenho ideal. A seção anterior de teste de desempenho apresenta uma explicação mais completa sobre porque isso é importante.

Os efeitos do cache de dados foram minimizados ao definir o pool de páginas do GPFS como ajustável para 16 GiB e ao configurar o tamanho total do arquivo para o dobro da quantidade total de RAM dos clients usados. Ou seja, como cada client tem 128 GiB de RAM, para contagens de threads iguais ou superiores a 16 threads, o tamanho do arquivo foi de 4.096 GiB, e uma quantidade igual desse total foi dividida pelo número de threads (a variável $Size abaixo foi usada para gerenciar esse valor). Para os casos com menos de 16 threads (o que implica que cada thread estava em execução em um client diferente), o tamanho do arquivo foi o dobro da quantidade de memória por client usado, multiplicado pelo número de threads. Em outras palavras, cada thread precisou usar 256 GiB.

Os seguintes comandos foram usados para executar a referência de desempenho para leituras e gravações, em que $Threads foi a variável com o número de threads usados (1 a 1.024 incrementados em potências de dois), e my_hosts.$Threads é o arquivo correspondente que alocou cada thread em um nó diferente, fazendo rodízio para distribuí-los de modo homogêneo entre os 16 nós de computação.

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --mca btl_openib_allow_ib 1 --mca pml ^ucx --oversubscribe --prefix /mmfs1/perftest/ompi /mmfs1/perftest/lanl_ior/bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/tst.file -w -s 1 -t 8m -b $ G

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --mca btl_openib_allow_ib 1 --mca pml ^ucx --oversubscribe --prefix /mmfs1/perftest/ompi /mmfs1/perftest/lanl_ior/bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/tst.file -r -s 1 -t 8m -b $ G

Figura 3  Desempenho sequencial de N para 1

Com base nos resultados, nós podemos observar que o desempenho de leitura e gravação é alto, independentemente da necessidade implícita de mecanismos de bloqueio, pois todos os threads acessam o mesmo arquivo. O desempenho aumenta muito rapidamente conforme o número de threads usados e, em seguida, atinge um platô relativamente estável para leituras e gravações até o número máximo de threads usados nesse teste. Observe que o desempenho máximo de leitura foi de 51,6 GB/s com 512 threads, mas o desempenho atingiu o platô com cerca de 64 threads. Da mesma forma, observe que o desempenho máximo de gravação de 34,5 GB/s foi alcançado com 16 threads e atingiu um platô que pode ser observado até o número máximo de threads usados.

Desempenho de blocos pequenos aleatórios do IOzone N clients para N arquivos

O desempenho aleatório de N clients para N arquivos foi medido com o IOzone versão 3.487. Os testes executados variaram de thread único até 1.024 threads em incrementos de potências de dois.

Os testes executados variaram de thread único até 512 threads, pois não havia núcleos de client suficientes para 1.024 threads. Cada thread estava usando um arquivo diferente e os threads foram atribuídos fazendo rodízio nos nós do client. Esses testes de referência de desempenho usaram blocos de 4 KiB para emular o tráfego de blocos pequenos e usar um tamanho da fila de 16. Os resultados da solução de grande porte e da expansão de capacidade foram comparados.

Novamente, os efeitos do armazenamento em cache foram minimizados ao definir o pool de páginas do GPFS como ajustável para 16 GiB e, para evitar quaisquer efeitos possíveis do cache de dados com base nos clients, o tamanho total de dados dos arquivos foi o dobro da quantidade total de RAM dos clients usados. Ou seja, como cada client tem 128 GiB de RAM, para contagens de threads iguais ou superiores a 16 threads, o tamanho do arquivo foi de 4.096 GiB dividido pelo número de threads (a variável $Size abaixo foi usada para gerenciar esse valor). Para os casos com menos de 16 threads (o que significa que cada thread estava em execução em um client diferente), o tamanho do arquivo foi fixado como o dobro da quantidade de memória por client, ou 256 GiB.

iozone -i0 -I -c -e -w -r 8M -s $ G -t $Threads -+n -+m ./nvme_threadlist                                     <= Criar os arquivos sequencialmente
iozone -i2 -I -c -O -w -r 4k -s $ G -t $Threads -+n -+m ./nvme_threadlist                                      <= Realizar as leituras e gravações aleatórias.

Figura 4  Desempenho aleatório de N para N

Com base nos resultados, nós podemos observar que o desempenho de gravação começa com um valor alto de 6 mil IOPS e aumenta constantemente até 1.024 threads, quando parece alcançar um platô com mais de 5 milhões de IOPS, se for possível usar mais threads. Por outro lado, o desempenho de leitura começa com um valor de 5 mil IOPS, aumenta estavelmente conforme o número de threads usados (lembre-se de que o número de threads é duplicado para cada ponto de dados) e atinge o desempenho máximo de 7,3 milhões de IOPS com 1.024 threads, sem sinal de atingir um platô. O uso de mais threads exigirá mais do que os 16 nós de computação para evitar a falta de recursos e trocas excessivas, que podem reduzir o desempenho aparente. Já os nós NVMe poderiam, de fato, manter o desempenho.

Desempenho de metadados com MDtest usando arquivos de 4 KiB

O desempenho dos metadados foi medido com o MDtest versão 3.3.0, auxiliado pelo OpenMPI v4.0.1 para executar a referência de desempenho nos 16 nós de computação. Os testes executados variaram de thread único para 512 threads. A referência de desempenho foi usada apenas para arquivos (sem metadados de diretórios), obtendo o número de criações, estatísticas, leituras e remoções que a solução pode processar, e os resultados foram comparados com a solução de grande porte.

O módulo opcional de metadados de alta demanda foi usado, mas com um só array ME4024, embora a configuração ampliada e testada neste trabalho tenha sido projetada para ter dois ME4024s. O motivo para usar esse módulo de metadados é que, atualmente, esses nós NVMe são usados como destinos de armazenamento apenas para dados. No entanto, é possível usar os nós para armazenar dados e metadados ou, até mesmo, como uma alternativa flash ao módulo de metadados de alta demanda, caso demandas extremas de metadados exijam isso. Essas configurações não foram testadas como parte deste trabalho.

Como o mesmo módulo de metadados de alta demanda foi usado na referência de desempenho anterior da solução DellEMC Ready Solution for HPC PixStor Storage, os resultados dos metadados serão muito semelhantes aos resultados da publicação anterior do blog. Por esse motivo, o estudo com arquivos vazios não foi realizado e, em vez disso, foram utilizados arquivos de 4 KiB. Como os arquivos de 4 KiB não cabem em um inode junto com as informações de metadados, os nós NVMe serão usados para armazenar dados de cada arquivo. Portanto, o MDtest pode dar uma ideia aproximada do desempenho de arquivos pequenos para leituras e o restante das operações de metadados.

O comando abaixo foi usado para executar a referência de desempenho, em que $Threads foi a variável com o número de threads usados (1 a 512 incrementados em potências de dois), e my_hosts.$Threads é o arquivo correspondente que alocou cada thread em um nó diferente, fazendo rodízio para distribuí-los de modo homogêneo entre os 16 nós de computação. Semelhante à referência de desempenho de E/S aleatória, o número máximo de threads foi limitado a 512, já que não há núcleos suficientes para 1.024 threads e a alternância do contexto afetaria os resultados, relatando um número menor do que o desempenho real da solução.

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --prefix /mmfs1/perftest/ompi --mca btl_openib_allow_ib 1 /mmfs1/perftest/lanl_ior/bin/mdtest -v -d /mmfs1/perftest/ -i 1 -b $Directories -z 1 -L -I 1024 -y -u -t -F -w 4K -e 4K

Como os resultados de desempenho podem ser afetados pelo número total de IOPS, pelo número de arquivos por diretório e pelo número de threads, decidiu-se manter fixo o número total de arquivos em 2 MiB (2^21 = 2.097.152), o número de arquivos por diretório em 1.024 e o número de diretórios variável de acordo com o número de threads alterados, conforme exibido na Tabela 3.

Tabela 3 Distribuição de arquivos em diretórios do MDtest

Figura 5  Desempenho dos metadados — arquivos de 4 KiB

Primeiro, observe que a escala escolhida foi logarítmica com base 10 para permitir operações de comparação que têm diferenças exponenciais; caso contrário, algumas das operações seriam semelhantes a uma linha plana próxima a 0 em uma escala linear. Um gráfico de logs com base 2 pode ser mais apropriado, já que o número de threads aumenta em potências de 2, mas o gráfico seria muito semelhante, e as pessoas tendem a lidar melhor com números com base em potências de 10 e a se lembrar deles.

O sistema obtém resultados muito bons, conforme relatado anteriormente, com operações de estatísticas atingindo o valor máximo em 64 threads com quase 6,9 milhões de operações por segundo (op/s) e, depois, sendo reduzidas com contagens maiores de threads, até atingir um platô. As operações de criação atingem o máximo de 113K op/s em 512 threads; portanto, espera-se que continuem aumentando se mais nós (e núcleos) de client forem usados. As operações de leitura e remoção atingiram o máximo em 128 threads, alcançando o pico em quase 705 mil op/s para leituras e 370 mil para remoções e, em seguida, atingiram um platô. As operações de estatísticas têm mais variabilidade mas, depois que atingem o valor máximo, o desempenho dessas operações não cai abaixo de 3,2 milhões op/s. A criação e a remoção ficam mais estáveis quando atingem um patamar e permanecem acima de 265K op/s para remoção e 113K op/s para criação. Por fim, as leituras atingem um platô com desempenho acima de 265 mil op/s.

Conclusões e trabalho futuro

Os nós NVMe são uma adição importante à solução de armazenamento para HPC, pois oferecem um nível de desempenho elevado com boa densidade, desempenho de acesso aleatório muito alto e desempenho sequencial superior. Além disso, é possível fazer scale-out linear da capacidade e do desempenho da solução, à medida que mais módulos de nós NVMe vão sendo adicionados. A Tabela 4 apresenta uma visão geral do desempenho dos nós NVMe. Espera-se que ele seja estável e que esses valores possam ser usados para estimar o desempenho para um número diferente de nós NVMe.
No entanto, lembre-se de que cada par de nós NVMe oferecerá metade de qualquer número exibido na Tabela 4.
Essa solução oferece aos clientes de HPC um file system paralelo muito confiável usado por muitos dos 500 principais clusters de HPC. Além disso, ela proporciona recursos excepcionais de pesquisa, monitoramento e gerenciamento avançados e gateways opcionais adicionais, que permitem o compartilhamento de arquivos por meio de protocolos padrão universais, como NFS, SMB, entre outros, para o máximo de clients necessários.

Tabela 4  Desempenho sustentado e máximo para dois pares de nós NVMe

Como os nós NVMe foram usados apenas para dados, possíveis trabalhos futuros podem incluir o uso deles para dados e metadados e ter um nível autossuficiente baseado em flash com melhor desempenho de metadados, devido à maior largura de banda e à menor latência dos dispositivos NVMe em comparação com as SSDs SAS3 conectadas aos controladores RAID. Como alternativa, se um cliente tiver demandas de metadados extremamente altas e precisar de uma solução mais densa do que a solução que o módulo de metadados de alta demanda pode oferecer, será possível usar alguns ou todos os dispositivos RAID 10 distribuídos para metadados da mesma forma que os dispositivos RAID 1 no ME4024s são usados atualmente.
Outra publicação que será feita no blog em breve caracterizará os nós do PixStor Gateway, que permitem conectar a solução PixStor a outras redes usando protocolos NFS ou SMB e fazer scale-out do desempenho. A solução também será atualizada para o HDR100 muito em breve, e outra publicação do blog deverá falar sobre esse assunto.