Zu den Hauptinhalten
  • Bestellungen schnell und einfach aufgeben
  • Bestellungen anzeigen und den Versandstatus verfolgen
  • Profitieren Sie von exklusiven Prämien und Rabatten für Mitglieder
  • Erstellen Sie eine Liste Ihrer Produkte, auf die Sie jederzeit zugreifen können.

Dell EMC Ready Solution for HPC PixStor Storage

Zusammenfassung: Arquitetura de referência para a solução, juntamente com a avaliação de performance inicial.

Dieser Artikel gilt für Dieser Artikel gilt nicht für Dieser Artikel ist nicht an ein bestimmtes Produkt gebunden. In diesem Artikel werden nicht alle Produktversionen aufgeführt.

Symptome

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

Ursache

.

Lösung

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

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

Neste blog, apresentamos a mais recente adição da Dell EMC às soluções de sistema de arquivos paralelos (PFS) para ambientes de HPC, a Dell EMC Ready Solution for HPC PixStor Storage. A Figura 1 apresenta a arquitetura de referência, que utiliza os servidores Dell EMC PowerEdge R740 e os storage arrays PowerVault ME4084 e ME4024, com o software PixStor da nossa empresa parceira Arcastream.
O PixStor inclui o generalizado General Parallel File System, também conhecido como Spectrum Scale, como o componente PFS, além de componentes de software Arcastream, como análise avançada, administração e monitoramento simplificados, pesquisa eficiente de arquivos, recursos avançados de gateway e muitos outros.

SLN318841_en_US__1image (11979)
Figura 1: Arquitetura de referência.

 

Componentes da solução

Essa solução foi planejada para ser lançada com as CPUs escaláveis Intel Xeon de 2ª geração mais recentes, também conhecidas como CPUs Cascade Lake, e alguns dos servidores usarão a RAM mais rápida disponível para elas (2933 MT/s). No entanto, devido ao hardware disponível para prototipar a solução e caracterizar seu desempenho, os servidores com CPUs Xeon escaláveis Intel Xeon de 1ª geração, também conhecidos como Processadores Skylake e RAM mais lenta foram usados. Como o gargalo da solução está nos controladores SAS dos arrays Dell EMC PowerVault ME40x4, não se espera disparidade significativa de desempenho depois que as CPUs e a RAM Skylake forem substituídas pelas CPUs Cascade Lake previstas e RAM mais rápida. Além disso, mesmo que a versão mais recente do PixStor que suportava RHEL 7.6 estivesse disponível no momento da configuração do sistema, foi decidido continuar o processo de controle de qualidade e usar o Red Hat® Enterprise Linux® 7.5 e a versão secundária anterior do PixStor para caracterizar o sistema. Depois que o sistema for atualizado para CPUs Cascade Lake, o software PixStor também será atualizado para a versão mais recente e algumas verificações pontuais de desempenho serão feitas para verificar se o desempenho permaneceu fechado para os números relatados neste documento.

Devido à situação descrita anteriormente, a Tabela 1 tem a lista de componentes principais para a solução. A coluna do meio tem os componentes planejados para serem usados no momento do lançamento e, portanto, disponíveis para os clientes, e a última coluna é a lista de componentes realmente usada para caracterizar o desempenho da solução. As unidades listadas ou de dados (NLS de 12 TB) e metadados (SSD de 960 GB) são 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.

Finalmente, para completar, foi incluída a lista de possíveis HDDs de dados e SSDs de metadados, que é baseada nas unidades suportadas, conforme especificado na matriz de suporte do Dell EMC PowerVault ME4, disponível on-line.

Quadro 1 Componentes a utilizar no momento da libertação e componentes utilizados no banco de ensaio

SLN318841_en_US__2image(12041)
 

Caracterização de desempenho

Para caracterizar essa nova Ready Solution, usamos o hardware especificado na última coluna da Tabela 1, incluindo 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 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

    SLN318841_en_US__3image (11984)
    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

    SLN318841_en_US__4image (11985)

    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

    SLN318841_en_US__5image (11987)
    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




    SLN318841_en_US__6image (11988)
    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

    SLN318841_en_US__7image (11989)
    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

     

    SLN318841_en_US__8image (11990)
    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.

    SLN318841_en_US__9image (11993)
    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.

    SLN318841_en_US__10image (11994)
    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.


     

Betroffene Produkte

High Performance Computing Solution Resources, Dell EMC PowerVault ME4012, Dell EMC PowerVault ME4024, Dell EMC PowerVault ME4084
Artikeleigenschaften
Artikelnummer: 000130962
Artikeltyp: Solution
Zuletzt geändert: 23 Sept. 2024
Version:  6
Antworten auf Ihre Fragen erhalten Sie von anderen Dell NutzerInnen
Support Services
Prüfen Sie, ob Ihr Gerät durch Support Services abgedeckt ist.