Omitir para ir al contenido principal
  • Hacer pedidos rápida y fácilmente
  • Ver pedidos y realizar seguimiento al estado del envío
  • Cree y acceda a una lista de sus productos
  • Administre sus sitios, productos y contactos de nivel de producto de Dell EMC con Administración de la empresa.

Dell EMC Ready Solution for HPC PixStor Storage: expansão de capacidade

Resumen: Dell EMC Ready Solution for HPC PixStor Storage: expansão de capacidade

Es posible que este artículo se traduzca automáticamente. Si tiene comentarios sobre su calidad, háganoslo saber mediante el formulario en la parte inferior de esta página.

Contenido del artículo


Síntomas

De autoria de Mario Gallegos do LABORATÓRIO de inovação em HPC e IA em abril de 2020

Causa

Nenhuma

Resolución

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. Blocks pequenos aleatórios Desempenho de 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
  3. Conclusões e trabalho futuro


 


Introdução

Os atuais ambientes de HPC aumentaram as demandas por armazenamento de alta velocidade, que também exige frequentemente alta capacidade e acesso distribuído por meio de vários protocolos padrão, como NFS, SMB e outros. Esses requisitos de HPC de alta demanda geralmente são cobertos por file systems paralelos que fornecem acesso simultâneo a um único arquivo ou um conjunto de arquivos de vários nós, distribuindo dados de maneira muito eficiente e segura para várias LUNs entre vários servidores.

 

Arquitetura da solução

Este blog é uma solução PFS (Parallel File System) de continuação para ambientes de HPC, a DellEMC Ready Solution for HPC PixStor Storage, em que os arrays EBOD PowerVault ME484 são usados para aumentar a capacidade da solução. Figura 1 apresenta a arquitetura de referência que descreve as adições de SAS de expansão de capacidade aos storage arrays PowerVault ME4084 existentes.
A solução PixStor inclui o general Parallel File System, também conhecido como Spectrum Scale como o componente PFS, além de muitos outros componentes de software Arcastream, como lógica analítica avançada, administração e monitoramento simplificados, pesquisa eficiente de arquivos, recursos avançados de gateway e muitos outros.


SLN321192_en_US__1image001
Figura 1: Arquitetura de referência.

 

Componentes da solução

Essa solução está planejada para ser lançada com as mais recentes CPUs Dimensionáveis Intel Xeon Xeon de 2ª geração, também conhecidos como CPUs Cascade Lake, e alguns dos servidores usarão a RAM mais rápida disponível para eles (2933 MT/s). No entanto, devido ao hardware atual disponível para trabalhar no protótipo da solução para caracterizar o desempenho, os servidores com CPUs Xeon escaláveis Intel Xeon de 1ª geração, também conhecidos como Em alguns casos, processadores Skylake e RAM mais lenta foram usados para caracterizar esse sistema. Como o gargalo da solução está nas controladoras SAS dos arrays Dell EMC PowerVault ME40x4, nenhuma disparidade significativa de desempenho é esperada quando as CPUs e a RAM Skylake são substituídas por CPUs Cascade Lake previstas e RAM mais rápida. Além disso, a solução foi atualizada para a versão mais recente do PixStor (5.1.1.4) que oferece suporte a RHEL 7.7 e OFED 4.7 para a inicialização do sistema.

Devido à situação descrita anteriormente, a Tabela 1 tem a lista de componentes principais da solução, mas quando discrepâncias foram introduzidas, a primeira coluna de descrição tem componentes usados no momento da versão e, portanto, disponíveis para os clientes, e a última coluna são os componentes realmente usados para melhorar o desempenho da solução. As unidades listadas para dados (NLS de 12 TB) e metadados (SSD de 960 Gb) são as usadas para caracterização de desempenho, e unidades mais rápidas podem fornecer melhores IOPS aleatórios e melhorar as operações de criação/remoção de metadados.

Por fim, para fins de conclusão, a lista de possíveis HDDs de dados e SSDs de metadados foi incluída, que é baseada nas unidades compatíveis, conforme enumerado na matriz de suporte do DellEMC PowerVault ME4, disponível on-line.

Tabela 1 Componentes usados no momento da liberação e os usados no ambiente de teste

Componente da solução

Na versão

Ambiente de teste

Conectividade interna

Dell Networking S3048-ON Gigabit Ethernet

Subsistema de armazenamento de dados

1 a 4 Dell EMC PowerVault ME4084

1 a 4 unidades de disco rígido Dell EMC PowerVault ME484 (uma por ME4084),
80 unidades de disco rígido NL SAS3
de 3,5" e 12 TB Opções de 900 GB @15K, 1,2 TB @10K, 1,8 TB @10K, @10K de 2,4 TB,
NLS de 4 TB, NLS de 8 TB, NLS de 10 TB, NLS de 12 TB.
    8 LUNs, RAID 6 linear 8+2, tamanho do fragmento 512KiB.
4 SSDs SAS3 de 1,92 TB para metadados – 2 RAID 1 (ou 4 – unidades de disco rígido globais sobressalentes, se o módulo de metadados opcional de alta demanda for usado)

Subsistema opcional de armazenamento de metadados de alta demanda

1 a 2 Dell EMC PowerVault ME4024 (4 ME4024, somente configuração grande)
24 unidades SSD SAS3 de 2,5" e 960 GB (opções de 480 GB, 960 GB, 1,92 TB)
12 LUNs, RAID linear 1.

Controladores de armazenamento RAID

SAS de 12 Gbps

Capacidade conforme configurado

Raw: 8064 TB (7334 TiB ou 7,16 PiB) formatados ~ 6.144 GB (5588 TiB ou 5,46 PiB)

Processador

Gateway

2 Intel Xeon Gold 6230 2,1 G, 20C/40T, 10,4 GT/s, cache de 27,5 M, Turbo, HT (125 W) DDR4-2933

N/D

Metadados de alta demanda

2 Intel Xeon Gold 6136 a 3,0 GHz, 12 núcleos

Nó de armazenamento

2 Intel Xeon Gold 6136 a 3,0 GHz, 12 núcleos

Nó de gerenciamento

2 Intel Xeon Gold 5220 2,2 G, 18C/36T, 10,4 GT/s, cache de 24,75 M, Turbo, HT (125 W) DDR4-2666

2x Intel Xeon Gold 5118 a 2,30 GHz, 12 núcleos

Memória

Gateway

12x RDIMMs de 16 GiB 2933 MT/s (192 GiB)

N/D

Metadados de alta demanda

24 RDIMMs de 16 GiB e 2.666 MT/s (384 GiB)

Nó de armazenamento

24 RDIMMs de 16 GiB e 2.666 MT/s (384 GiB)

Nó de gerenciamento

12 DIMMs de 16 GB, 2666 MT/s (192 GiB)

12 RDIMMs de 8 GiB e 2.666 MT/s (96 GiB)

Sistema operacional

Red Hat Enterprise Linux 7.6

Red Hat Enterprise Linux 7.7

Versão do kernel

3.10.0-957.12.2.el7.x86_64

3.10.0-1062.9.1.el7.x86_64

PixStor Software

5.1.0.0

5.1.1.4

Escala de espectro (GPFS)

5.0.3

5.0.4-2

Conectividade de rede de alto desempenho

Mellanox ConnectX-5 Dual-Port InfiniBand EDR/100 GbE e 10 GbE

Mellanox ConnectX-5 InfiniBand EDR

Switch de alto desempenho

2 Mellanox SB7800 (HA – redundante)

1 Mellanox SB7700

Versão do OFED

Mellanox OFED-4.6-1.0.1.0

Mellanox OFED-4.7-3.2.9

Discos locais (SO & análise/monitoramento)

Todos os servidores, exceto o nó de gerenciamento

3 SSD SAS3 de 480 GB (RAID1 + HS) para SO

Controlador RAID PERC H730P

Nó de gerenciamento

3 SSD SAS3 de 480 GB (RAID1 + HS) para SO

Controlador RAID PERC H740P

Todos os servidores, exceto o nó de gerenciamento

2 SAS3 de 300 GB e 15.000 RPM (RAID 1) para SO

Controlador RAID PERC H330

Nó de gerenciamento

5 SAS3 de 300 GB e 15.000 RPM (RAID 5) para SO e
análise/monitoramento

Controlador RAID PERC H740P

Gerenciamento de sistemas

iDRAC 9 Enterprise + DellEMC OpenManage

iDRAC 9 Enterprise + DellEMC OpenManage

 

Caracterização de desempenho

Para caracterizar essa nova Ready Solution, usamos o hardware especificado na última coluna da Tabela 1, inclusive o módulo opcional de metadados de alta demanda. Para avaliar o desempenho da solução, foram usadas as seguintes referências de desempenho:
  • IOzone N to N sequencial
  • IOR N a 1 sequencial
  • IOzone aleatório
  • Teste de MD
 Para todos os benchmarks listados 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ó, 1024 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 as referências de desempenho dão suporte a um alto número de threads, um valor máximo de até 1.024 foi usado (especificado para cada teste), ao mesmo tempo que evita a alternância excessiva de contexto e outros efeitos laterais relacionados que afetam os resultados de desempenho.

Tabela 2 Ambiente de teste do cliente

Número de nós do client

16

Nó do client

C6320

Processadores por nó do client

2 x Intel(R) Xeon(R) Gold E5-2697v4 18 núcleos a 2,30 GHz

Memória por nó do client

12 x RDIMMs de 16 GiB 2400 MT/s

BIOS

2.8.0

Kernel do SO

3.10.0-957.10.1

Versão do GPFS

5.0.3

 

Desempenho sequencial do IOzone N clients para N arquivos

O desempenho dos N clients sequenciais para N files foi medido com o IOzone versão 3.487. Os testes executados variaram de thread único até 1.024 threads, e os resultados da solução expandida de capacidade (4 ME4084s + 4 ME484s) são contrastados com a solução de grande porte (4 ME4084s). 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 maiores que duas vezes esse 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 block para grandes transferências sequenciais seja de 1 MiB, o GPFS foi formatado com 8 blocos miB e, portanto, esse valor é usado no benchmark 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 subblock para evitar essa situação. Na configuração atual, cada block foi subdividido em 256 subblocks de 32 KiB cada.

Os comandos a seguir foram usados para executar o benchmark de gravações e leituras, em que Threads era a variável com o número de threads usados (1 a 1024 incrementado em potências de dois), e threadlist era o arquivo que aloca cada thread em um nó diferente, usando round robin para distribuí-los homogêneo 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

SLN321192_en_US__2image003
Figura 2:  Desempenho sequencial N a N


A partir dos resultados, podemos observar que o desempenho aumenta muito rapidamente com o número de clients usados e, em seguida, atinge um estalamento 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. Observe que o desempenho de leitura e gravação se beneficiou da duplicação do número de unidades. O desempenho máximo de leitura foi limitado pela largura de banda dos dois links EDR IB usados nos nós de armazenamento a partir de 8 threads, e os arrays ME4 podem ter um desempenho extra disponível. Da mesma forma, observe que o desempenho máximo de gravação aumentou de um máximo de 16,7 para 20,4 GB/s a 64 e 128 threads e está mais próximo das especificações máximas dos arrays ME4 (22 GB/s).

Aqui, é importante lembrar que o modo de operação preferencial do GPFS está disperso e que a solução foi formatada para usar esse modo. Nesse modo, os blocos são alocados desde o início da operação de forma pseudoconvergente, distribuindo 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 revolução de disco e, portanto, têm o mais alto desempenho possível que os HDDs 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 dos N clients sequenciais em um único arquivo compartilhado foi medido com a versão IOR 3.3.0, auxiliada pelo OpenMPI v4.0.1 para executar o benchmark nos 16 nós de computação. Os testes executados variaram de um thread até 512 threads (já que não havia núcleos suficientes para 1024 threads), e os resultados são contrastados com a solução sem a expansão da capacidade.
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 maiores que duas vezes esse tamanho. Esses testes de referência de desempenho usaram 8 blocos MiB para obter o desempenho ideal. A seção anterior de teste de desempenho tem uma explicação mais completa para essas questões.

Os comandos a seguir foram usados para executar o benchmark de 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 my_hosts.$Threads é o arquivo correspondente que aloca cada thread em um nó diferente, usando round robin para distribuí-los 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 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

SLN321192_en_US__3image005

Figura 3: Desempenho sequencial N a 1 Com

base nos resultados, podemos observar novamente que as unidades extras beneficiam o desempenho de leitura e gravação. O desempenho aumenta muito rapidamente com o número de clients usados e, em seguida, atinge um estalamento que é bastante estável para leituras e gravações até o número máximo de threads usados neste teste. Observe que o desempenho máximo de leitura foi de 24,8 GB/s a 16 threads e o gargalo era a interface InfiniBand EDR, com arrays ME4 ainda com um desempenho extra disponível. A partir desse ponto, o desempenho de leitura diminuiu desse valor até atingir o estaldo em torno de 23,8 GB/s. Da mesma forma, observe que o desempenho máximo de gravação de 19,3 foi atingido em 8 threads e atinge um estaldo.
 

Blocks pequenos aleatórios Desempenho de IOzone N clients para N arquivos

O desempenho de N clients aleatórios para N files foi medido com FIO versão 3.7 em vez do Iozone tradicional. A intenção, conforme listado no blog anterior, era aproveitar uma profundidade de fila maior para investigar o desempenho máximo possível que os arrays ME4084 podem oferecer (testes anteriores para diferentes soluções ME4 mostraram que os arrays ME4084 precisam de mais pressão de E/S que a Iozone pode oferecer para atingir seus limites aleatórios de E/S).

Os testes executados variaram de thread único até 512 threads, pois não havia núcleos de client suficientes para 1024 threads. Cada thread estava usando um arquivo diferente e os threads eram atribuídos round-robin nos nós do client. Esses testes de benchmark usaram 4 blocks de KiB para emular o tráfego de blocks pequenos e usar uma profundidade de fila de 16. Os resultados da solução de grande porte e da expansão da capacidade são comparados.

Os efeitos de armazenamento em cache foram minimizados novamente definindo o pool de páginas do GPFS ajustável para 16 GiB e usando arquivos duas vezes esse tamanho. A primeira seção de teste de desempenho tem uma explicação mais completa sobre por que isso é eficaz no GPFS.

  SLN321192_en_US__4image007
Figura 4:  Desempenho aleatório N para N

Com base nos resultados, podemos observar que o desempenho de gravação começa com um alto valor de 29,1 mil IOps e aumenta constantemente até 64 threads, onde parece alcançar um estaldo a cerca de 40 mil IOps. O desempenho de leitura, por outro lado, começa em 1,4 mil IOps e 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 25,6 mil IOPS em 64 threads, onde parece estar próximo de atingir um estaldo. O uso de mais threads exigirá mais do que os 16 nós de computação para evitar a falta de recursos e um desempenho aparente mais baixo, em que os arrays poderiam, de fato, manter o desempenho.

 

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 o benchmark nos 16 nós de computação. Os testes executados variaram de thread único até 512 threads. O benchmark foi usado somente para arquivos (sem metadados de diretórios), obtendo o número de criações, estatísticas, leituras e remoção que a solução pode lidar, e os resultados foram contrastados com a solução de tamanho grande.

Para avaliar adequadamente a solução em comparação com outras soluções de armazenamento de HPC da Dell EMC e os resultados anteriores do blog, o módulo opcional de metadados de alta demanda foi usado, mas com um único array ME4024, mesmo que a configuração grande e testada neste trabalho tenha sido 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 arrays adicionais do ME4024 aumentem o desempenho de metadados linearmente com cada array adicional, exceto talvez para operações de estatísticas (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 o benchmark, 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, usando round robin para distribuí-los homogêneo entre os 16 nós de computação. Semelhante ao benchmark 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 1024 threads e a comutação de 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, pelo número de arquivos por diretório e pelo número de threads, decidiu-se manter fixo o número total de arquivos para 2 arquivos MiB (2^21 = 2097152), o número de arquivos por diretório corrigido em 1024 e o número de diretórios variava conforme o número de threads alterados, conforme mostrado na Tabela 3.

Tabela 3:  Distribuição MDtest 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



SLN321192_en_US__5image009

Figura 5: Desempenho de metadados — arquivos vazios

Primeiro, observe que a escala escolhida foi logarítmica com base 10, para permitir operações de comparação que têm diferenças de várias ordens de magnitude; caso contrário, algumas das operações seriam semelhantes a uma linha plana próxima a 0 em um gráfico normal. Um gráfico de registro 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 e se lembrar de números melhores com base em potências de 10.
O sistema obtém resultados muito bons com operações de estatísticas e leitura atingindo seu valor máximo em 64 threads com quase 11 milhões de op/s e 4,7 milhões de op/s, respectivamente. As operações de remoção atingiram o máximo de 170,6 mil op/s em 16 threads e as operações de criação atingiram seu pico em 32 threads com op/s de 222,1 K. 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 3 milhões de op/s para estatísticas e 2 milhões de op/s para leituras. A criação e a remoção ficam mais estáveis quando atingem um status estável e permanecem acima de 140 mil op/s para remoção e 120 mil op/s para criação. Observe que as unidades extras não afetam a maioria das operações de metadados em arquivos vazios, conforme esperado.
 

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 KB foram usados. 
O seguinte comando foi usado para executar o benchmark, 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, usando round robin para distribuí-los 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

SLN321192_en_US__6image011
Figura 6:  Desempenho de metadados - arquivos pequenos (4K)

O sistema obtém resultados muito bons para operações de estatísticas e remoção, atingindo seu valor de pico em 256 threads com op/s de 8,2 milhões e 400 mil op/s, respectivamente. As operações de leitura atingiram o máximo de 44,8 mil op/s e as operações de criação atingiram seu pico com op/s de 68,1 K, ambos a 512 threads. As operações de estatísticas e remoção têm mais variabilidade, mas depois que atingem o valor de pico, o desempenho não cai abaixo de 3 milhões de op/s para estatísticas e 280 mil op/s para remoção. Criar e ler tem menos variabilidade e continua aumentando à medida que o número de threads aumenta. Como pode ser observado, as unidades extras das expansões de capacidade só fornecem alterações marginais no desempenho dos metadados.
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 simplesmente assumir um aumento linear para cada operação. A menos que o arquivo inteiro se encaixe dentro do inode para esse 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 KB e ainda precisa armazenar metadados, somente os arquivos de 3 KiB se encaixam no interior e qualquer arquivo maior que esse usará destinos de dados.
 


Conclusões e trabalho futuro

A solução com capacidade expandida conseguiu melhorar o desempenho, não apenas para acessos aleatórios, mas até mesmo para desempenho sequencial. Isso era esperado, pois o modo disperso se comporta como acessos aleatórios e ter mais discos permite a melhoria. Espera-se que esse desempenho, que pode ser visão geral na Tabela 4, seja estável a partir de um file system vazio até que esteja quase cheio. 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 oferece 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 o máximo de clients necessário..

Tabela 4  Desempenho de pico e sustentado

 

Desempenho de pico

Desempenho sustentado

Escrever

Read

Escrever

Read

N clients sequenciais grandes para arquivos N

20,4 GB/s

24,2 GB/s

20,3 GB/s

24 GB/s

N clients sequenciais grandes para um único arquivo compartilhado

19,3 GB/s

24,8 GB/s

19,3 GB/s

23,8 GB/s

Blocks pequenos aleatórios N clients para arquivos N

40KIOps

25,6KIOps

40,0KIOps

19,3KIOps

Metadados Criar arquivos vazios

169,4 mil IOps

123,5 mil IOps

Arquivos vazios de estatísticas de metadados

11 milhões de IOps

3,2 milhões de IOps

Leitura de metadados Arquivos vazios

4,7 milhões de IOps

2,4 milhões de IOps

Metadados Remover arquivos vazios

170,6 mil IOps

156,5 mil IOps

Metadados Criar arquivos de 4 KB

68.100 IOps

68.100 IOps

Arquivos stat de metadados 4KiB

8,2 milhões de IOps

3 milhões de IOps

Arquivos 4KiB de leitura de metadados

44,8 mil IOps

44,8 mil IOps

Remover arquivos de 4 KB de metadados

400 mil IOps

280 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, algumas verificações de desempenho no local serão feitas. 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 de pontos em um novo blog ou white paper. Por fim, é planejado que mais componentes da solução sejam testados e lançados para fornecer ainda mais recursos.

 

Propiedades del artículo


Producto comprometido

Dell EMC Ready Solution Resources

Fecha de la última publicación

26 sept 2023

Versión

5

Tipo de artículo

Solution