Dell EMC Ready Solution for HPC PixStor Storage

Artigo escrito por Mario Gallegos do HPC and AI Innovation Lab em outubro de 2019

Sumário

1. Introdução
   1. Arquitetura da solução
   2. Componentes da solução
2. Caracterização de desempenho
   1. Desempenho sequencial do IOzone N clients para N arquivos
   2. Desempenho sequencial de IOR N clients para 1 arquivo
   3. Desempenho de blocos pequenos aleatórios do IOzone N clients para N arquivos
   4. Desempenho de metadados com MDtest usando arquivos vazios
   5. Desempenho de metadados com MDtest usando arquivos de 4 KiB
   6. Desempenho de metadados usando o MDtest com arquivos 3K
3. Lógica analítica avançada
4. Conclusões e trabalho futuro

Introdução

Arquitetura da solução

Componentes da solução

Caracterização de desempenho

•     IOzone sequencial N para N
•     IOR sequencial N para 1
•     IOzone aleatório
•     MDtest
  
  Para todos os benchmarks listados acima, a plataforma de teste tinha os clientes conforme descrito na Tabela 2 abaixo. Como o número de nós de computação disponíveis para teste era de 16, quando um número maior de threads era necessário, esses threads eram igualmente distribuídos 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. Como os benchmarks suportam um alto número de threads, um valor máximo de até 1024 foi usado (especificado para cada teste), evitando que a alternância excessiva de contexto e outros efeitos colaterais relacionados afetem os resultados de desempenho.
  
  Tabela 2 Banco de testes do cliente

  Número de nós de client	16
  Nó de client	C6320
  Processadores por nó de client	2x Intel(R) Xeon(R) Gold E5-2697v4 18 núcleos a 2,30 GHz
  Memória por nó de client	12 RDIMMs de 16 GiB, 2400 MT/s
  BIOS	2.8.0
  Kernel do SO	3.10.0-957.10.1
  Versão de GPFS	5.0.3

   

  ---

  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 um único thread até 1024 threads. 
  Os efeitos de armazenamento em cache foram minimizados pela configuração do pool de páginas do GPFS ajustável para 16 GiB e pelo uso de arquivos com o dobro desse tamanho. É importante observar que, para GPFS, esse ajustável define a quantidade máxima de memória usada para armazenar dados em cache, independentemente da quantidade de RAM instalada e livre. Também é importante notar que, enquanto nas soluções anteriores de HPC da Dell EMC o tamanho do bloco para grandes transferências sequenciais é de 1 MiB, o GPFS foi formatado com blocos de 8 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 subblocos de 32 KiB cada. 
  Os comandos a seguir foram usados para executar o benchmark para gravações e leituras, onde Threads era a variável com o número de threads usados (1 a 1024 incrementados em potências de dois) e threadlist era o arquivo que alocava cada thread em um nó diferente, usando round robin para distribuí-los homogeneamente entre os 16 nós de computação.

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

  
  Figura 2:  Desempenho
  
  
  sequencial de N a N A partir dos resultados, podemos observar que o desempenho aumenta muito rapidamente com o número de clientes usados e, em seguida, atinge um platô estável até que o número máximo de threads que o IOzone permite é atingido e, portanto, o desempenho sequencial de arquivos grandes é estável mesmo para 1024 clientes simultâneos. Observe que o desempenho máximo de leitura era de 23 GB/s em 32 threads e, muito provavelmente, o gargalo era a interface InfiniBand EDR, enquanto os arrays ME4 ainda tinham algum desempenho extra disponível. Observe da mesma forma que o desempenho máximo de gravação de 16,7 foi alcançado um pouco mais cedo em 16 threads e é aparentemente baixo em comparação com as especificações de arrays ME4.
  Aqui é importante lembrar que o modo de operação preferido do GPFS é espalhado, e a solução foi formatada para usá-lo. Nesse modo, os blocos são alocados desde o início de forma pseudo-aleatória, espalhando dados por toda a superfície de cada HDD. Embora a desvantagem óbvia seja um desempenho máximo inicial menor, esse desempenho é mantido bastante constante, independentemente de quanto espaço é usado no file system. Isso, em contraste com outros file systems paralelos que inicialmente usam as trilhas externas que podem conter mais dados (setores) por rotação de disco e, portanto, têm o mais alto desempenho possível que os discos rígidos podem oferecer, mas, à medida que o sistema usa mais espaço, trilhas internas com menos dados por revolução são usadas, com a consequente redução do desempenho. 
  
   

  ---

  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 um único thread até 1024 threads.
  Os efeitos de armazenamento em cache foram minimizados pela configuração do pool de páginas do GPFS ajustável para 16 GiB e pelo uso de arquivos com o dobro desse tamanho. Esses testes de referência de desempenho usaram 8 blocos MiB para obter o desempenho ideal. A seção anterior do teste de desempenho tem uma explicação mais completa para esses problemas. 
  Os comandos a seguir foram usados para executar o benchmark para gravações e leituras, onde Threads é a variável com o número de threads usados (1 a 1024 incrementado em potências de dois) e my_hosts.$Threads é o arquivo correspondente que alocou cada thread em um nó diferente, usando round robin para distribuí-los homogeneamente 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 128G 

  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 128G

  
  
  Figura 3: N a 1 Desempenho
  
  sequencial A partir dos resultados, podemos observar que o desempenho aumenta novamente muito rapidamente com o número de clients usados e, em seguida, atinge um platô que é semi-estável para leituras e muito estável para gravações até o número máximo de threads usados neste teste. Portanto, o desempenho sequencial de arquivo único grande compartilhado é estável mesmo para 1.024 clientes simultâneos. Observe que o desempenho máximo de leitura era de 23,7 GB/s em 16 threads e, muito provavelmente, o gargalo era a interface InfiniBand EDR, enquanto os arrays ME4 ainda tinham algum desempenho extra disponível. Além disso, o desempenho de leitura diminuiu a partir desse valor até atingir o platô em torno de 20,5 GB/s, com uma diminuição momentânea para 18,5 GB/s em 128 threads. Da mesma forma, observe que o desempenho máximo de gravação de 16,5 foi alcançado em 16 threads e é aparentemente baixo em comparação com as especificações de arrays ME4.
   

  ---

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

  O desempenho de clientes N aleatórios para arquivos N foi medido com IOzone versão 3.487. Os testes executados variaram de um único thread até 1024 threads. Esses testes de benchmark usaram blocos de 4 KiB para emular o tráfego de blocos pequenos.
  Os efeitos de armazenamento em cache foram minimizados definindo o pool de páginas GPFS ajustável para 16 GiB e usando arquivos com o dobro desse tamanho. A primeira seção de teste de desempenho tem uma explicação mais completa sobre por que isso é eficaz no GPFS. 
  O comando a seguir foi usado para executar o benchmark no modo de E/S aleatório para gravações e leituras, em que Threads era a variável com o número de threads usados (1 a 1024 incrementados em potências de dois) e threadlist era o arquivo que alocava cada thread em um nó diferente, usando round robin para distribuí-los homogeneamente entre os 16 nós de computação.

  ./iozone -i2 -c -O -w -r 4K -s 32G -t $Threads -+n -+m ./threadlist

  
  Figura 4:  Desempenho
  
  aleatório de N a N Com base nos resultados, podemos observar que o desempenho de gravação começa com um valor alto de quase 8,2 mil IOPS e aumenta de forma constante até 128 threads, atingindo um platô e permanecendo próximo ao valor máximo de 16,2 mil IOPS. Por outro lado, o desempenho de leitura começa muito pequeno, com mais de 200 IOPS, aumenta o desempenho quase linearmente com o número de clients usados (lembre-se de que o número de threads é duplicado para cada ponto de dados) e atinge o desempenho máximo de 20,4 mil IOPS em 512 threads sem sinais de atingir o máximo. No entanto, o uso de mais threads nos atuais 16 nós de computação com duas CPUs cada e onde cada CPU tem 18 núcleos tem a limitação de que não há núcleos suficientes para executar o número máximo de threads da zona de E/S (1024) sem incorrer em comutação de contexto (16 x 2 x 18 = 576 núcleos), o que limita consideravelmente o desempenho. Um teste futuro com mais nós de computação poderia verificar qual desempenho de leitura aleatória pode ser alcançado com 1024 threads com IOzone ou IOR poderia ser usado para investigar o comportamento com mais de 1024 threads.
  
   

  ---

  Desempenho de metadados com MDtest usando arquivos vazios

  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.
  Para avaliar adequadamente a solução em comparação com outras soluções de armazenamento de HPC da Dell EMC, foi usado o módulo opcional de metadados de alta demanda, mas com um único array ME4024, mesmo que a configuração grande e testada neste trabalho foi designada para ter dois ME4024s. 
  Este módulo de metadados de alta demanda pode dar suporte a até quatro arrays ME4024, e é recomendável aumentar o número de arrays ME4024 para 4, antes de adicionar outro módulo de metadados. Espera-se que os arrays ME4024 adicionais aumentem o desempenho dos metadados linearmente com cada array adicional, exceto, talvez, para operações Stat (e leituras para arquivos vazios), já que os números são muito altos. Em algum momento, as CPUs se tornarão um gargalo e o desempenho não continuará a aumentar linearmente.
  O seguinte comando foi usado para executar a referência de desempenho, em que Threads era 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 aloca 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

  
  Como os resultados de desempenho podem ser afetados pelo número total de IOPS, o número de arquivos por diretório e o número de threads, foi decidido manter fixo o número total de arquivos para 2 arquivos MiB (2^21 = 2097152), o número de arquivos por diretório fixado em 1024 e o número de diretórios variou conforme o número de threads mudou, conforme mostrado na Tabela 3.
  
  Tabela 3:  MDtest distribuição de arquivos em diretórios

  Número de threads	Número de diretórios por thread	Número total de arquivos
  1	2048	2.097.152
  2	1024	2.097.152
  4	512	2.097.152
  8	256	2.097.152
  16	128	2.097.152
  32	64	2.097.152
  64	32	2.097.152
  128	16	2.097.152
  256	8	2.097.152
  512	4	2.097.152
  1024	2	2.097.152

  
  
  
  
  Figura 5: Desempenho de metadados — Arquivos
  
  vazios Primeiramente, observe que a escala escolhida foi logarítmica com base 10, para permitir comparar operações que apresentam diferenças de várias ordens de magnitude; caso contrário, algumas das operações pareceriam uma linha plana próxima de 0 em um gráfico normal. Um gráfico de log com base 2 poderia ser mais apropriado, já que o número de threads é aumentado em poderes de 2, mas o gráfico seria bastante semelhante, e as pessoas tendem a lidar e lembrar de números melhores com base em poderes de 10.
  
  
  O sistema obtém resultados muito bons com operações Stat e Read atingindo seu valor máximo em 64 threads com 11,2M op/s e 4,8M op/s respectivamente. As operações de remoção atingiram o máximo de 169,4 K op/s em 16 threads e as operações Create atingiram seu pico em 512 threads com 194,2 K op/s. As operações de estatísticas e leitura têm mais variabilidade, mas, depois que atingem o valor máximo, o desempenho não cai abaixo de 3M de op/s para estatísticas e 2M de op/s para leituras. A criação e a remoção são mais estáveis quando atingem um platô e permanecem acima de 140 mil op/s para remoção e 120 mil op/s para criação.
   

  ---

  Desempenho de metadados com MDtest usando arquivos de 4 KiB

  Esse teste é quase idêntico ao anterior, exceto pelo fato de que, em vez de arquivos vazios, pequenos arquivos de 4 KiB foram usados. 
  O seguinte comando foi usado para executar a referência de desempenho, em que Threads era 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 aloca 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 --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

  
  Figura 6:  Desempenho de metadados - Arquivos pequenos (4K)
  
  O sistema obtém resultados muito bons para operações de estatística e remoção, atingindo seu valor máximo em 128 threads com 7,7 milhões de op/s e 1 milhão de op/s, respectivamente. As operações de remoção atingiram o máximo de 37,3 mil op/s e as operações Create atingiram seu pico com 55,5 mil op/s, ambas em 512 threads. As operações de estatística e remoção têm mais variabilidade, mas quando atingem seu valor máximo, o desempenho não cai abaixo de 4 milhões de operações/s para estatísticas e 200 mil operações por segundo para remoção. A criação e a leitura têm menos variabilidade e continua aumentando à medida que o número de threads aumenta.
  Como esses números são para um módulo de metadados com um único ME4024, o desempenho aumentará para cada array ME4024 adicional, no entanto, não podemos supor um aumento linear para cada operação. A menos que o arquivo inteiro se encaixe dentro do inode desse arquivo, os destinos de dados no ME4084s serão usados para armazenar os arquivos 4K, limitando o desempenho a algum grau. Como o tamanho do inode é de 4 KiB e ainda precisa armazenar metadados, cabem somente os arquivos de 3 KiB e qualquer arquivo maior que esse usará destinos de dados.
   

  ---

  Desempenho de metadados usando o MDtest com arquivos 3K

  Este teste é quase exatamente idêntico aos anteriores, exceto que pequenos arquivos de 3KiB foram usados. A principal diferença é que esses arquivos cabem completamente dentro do inode. Portanto, os nós de armazenamento e seus ME4084s não são usados, melhorando a velocidade geral usando apenas mídia SSD para armazenamento e menos acessos à rede. 
  O seguinte comando foi usado para executar a referência de desempenho, em que Threads era 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 aloca 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 --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 3K -e 3K

   

  
  Figura 7: Desempenho de metadados - Arquivos pequenos (3K) O sistema obtém resultados muito bons para operações Stat e Read,
  
  atingindo seu valor máximo em 256 threads com 8,29 milhões de op/s e 5,06 milhões de op/s, respectivamente. As operações de remoção atingiram o máximo de 609 mil op/s em 128 threads e as operações Create atingiram seu pico com 78 mil op/s em 512 threads. As operações Stat e Read têm mais variabilidade do que Create e Removal. A remoção tem uma pequena queda no desempenho para os dois pontos de threads mais altos, sugerindo que o desempenho sustentado após 128 threads será de pouco mais de 400 mil op/s. A criação continua aumentando até 512 threads, mas parece que está atingindo um platô, então o desempenho máximo ainda pode estar abaixo de 100K op/s.
  Como arquivos pequenos como esses são armazenados completamente no módulo de metadados baseado em SSD, os aplicativos que exigem desempenho superior de arquivos pequenos podem usar um ou mais módulos opcionais de metadados de alta demanda para aumentar o desempenho de arquivos pequenos. No entanto, os arquivos que se encaixam no inode são pequenos para os padrões atuais. Além disso, como os destinos de metadados usam RAID1s com SSDs relativamente pequenos (o tamanho máximo é de 19,2 TB), a capacidade será limitada em comparação com os nós de armazenamento. Portanto, deve-se ter cuidado para evitar o preenchimento de destinos de Metadados, que podem causar falhas desnecessárias e outros problemas.
   

  ---

  Lógica analítica avançada

  Entre os recursos do PixStor, o monitoramento do sistema de arquivos por meio de análises avançadas pode ser essencial para simplificar muito a administração, ajudando a encontrar proativamente ou reativamente problemas ou possíveis problemas. A seguir, analisaremos brevemente alguns desses recursos.
  A Figura 8 mostra informações úteis com base na capacidade do sistema de arquivos. No lado esquerdo, o espaço total usado do file system e os dez principais usuários com base na capacidade do file system usada. No lado direito, uma visualização histórica com capacidade usada ao longo de muitos anos, em seguida, os dez principais tipos de arquivo usados e os dez principais conjuntos de arquivos, ambos com base na capacidade usada, em um formato semelhante aos gráficos de pareto (sem as linhas para totais cumulativos). Com essas informações, pode ser fácil encontrar usuários obtendo mais do que sua parcela justa do sistema de arquivos, tendências de uso da capacidade para auxiliar decisões sobre o crescimento futuro da capacidade, quais arquivos estão usando a maior parte do espaço ou quais projetos estão ocupando a maior parte da capacidade.
  
  
  Figura 8:  PixStor Analytics - Visualização de
  
  capacidade A Figura 9 fornece uma exibição de contagem de arquivos com duas maneiras muito úteis de encontrar problemas. A primeira metade da tela tem os dez principais usuários em um gráfico de pizza e os dez principais tipos de arquivo e os dez principais conjuntos de arquivos (pense em projetos) em um formato semelhante aos gráficos de pareto (sem as linhas para totais cumulativos), tudo baseado no número de arquivos. Essas informações podem ser usadas para responder a algumas perguntas importantes. Por exemplo, quais usuários estão monopolizando o sistema de arquivos criando muitos arquivos, que tipo de arquivo está criando um pesadelo de metadados ou quais projetos estão usando a maioria dos recursos.
  A metade inferior tem um histograma com o número de arquivos (frequência) para tamanhos de arquivo usando 5 categorias para diferentes tamanhos de arquivo. Isso pode ser usado para ter uma ideia dos tamanhos de arquivo usados em todo o sistema de arquivos, que coordenado com tipos de arquivo pode ser usado para decidir se a compactação será benéfica.
  
  
  Figura 9:  PixStor Analytics - Visualização de contagem de arquivos

  
  
   

  ---

  Conclusões e trabalho futuro

  A solução atual foi capaz de entregar um desempenho bastante bom, que deve ser estável independentemente do espaço utilizado (já que o sistema foi formatado em modo disperso), como pode ser visto na Tabela 4. Além disso, a solução dimensiona a capacidade e o desempenho linearmente à medida que mais módulos de nós de armazenamento são adicionados, e um aumento de desempenho semelhante pode ser esperado a partir do módulo opcional de metadados de alta demanda. 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, ele fornece recursos excepcionais de pesquisa, monitoramento e gerenciamento avançados, e a adição de gateways opcionais permite o compartilhamento de arquivos por meio de protocolos padrão onipresentes, como NFS, SMB e outros, para quantos clientes forem necessários.
  
  Tabela 4  Desempenho de pico & sustentado
  
   

  	Desempenho de pico		Desempenho sustentado
  	Gravação	Read	Gravação	Read
  N clients sequenciais grandes para arquivos N	16,7 GB/s	23 GB/s	16,5 GB/s	20,5 GB/s
  N clients sequenciais grandes para um único arquivo compartilhado	16,5 GB/s	23,8 GB/s	16,2 GB/s	20,5 GB/s
  Blocos pequenos aleatórios de N clients para N arquivos	15,8 KIOps	20,4 KIOps	15,7 KIOps	20,4 KIOps
  Metadados — criação — arquivos vazios	169,4K IOps		127,2 mil IOps
  Metadados — estatísticas — arquivos vazios	11,2 milhões de IOps		3,3 milhões de IOps
  Metadados — leitura — arquivos vazios	4,8 milhões de IOps		2,4M de IOps
  Metadados — remoção — arquivos vazios	194,2 mil IOps		144,8 mil IOps
  Metadados — criação — arquivos de 4KiB	55,4 mil IOps		55,4 mil IOps
  Metadados — estatística — arquivos de 4KiB	6,4 milhões de IOps		4 milhões de IOps
  Metadados — leitura — arquivos de 4KiB	37,3 mil IOps		37,3 mil IOps
  Metadados — Remoção — arquivos de 4KiB	1 milhão de IOps		219,5 mil IOps

  
  
  Como a solução deve ser lançada com CPUs Cascade Lake e RAM mais rápida, depois que o sistema tiver a configuração final, serão feitas algumas verificações pontuais de desempenho. E teste o módulo opcional de metadados de alta demanda com pelo menos 2 arquivos ME4024s e 4KiB necessários para documentar melhor como o desempenho dos metadados é dimensionado quando os destinos de dados estão envolvidos. Além disso, o desempenho dos nós de gateway será medido e relatado juntamente com quaisquer resultados relevantes das verificações pontuais em um novo blog ou white paper. Por fim, está previsto que mais componentes da solução sejam testados e lançados para fornecer ainda mais recursos.

  ---