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

Nenhuma

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.


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

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

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.

 
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

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

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.