Partilhar via

Benefícios do uso do Azure NetApp Files for Electronic Design Automation (EDA)

  • Artigo

A inovação é uma marca distintiva da indústria de semicondutores. Tal inovação permitiu que o princípio de Gordon Moore de 1965, conhecido como Lei de Moore, se mantivesse válido por mais de cinquenta anos, ou seja, que se pode esperar que as velocidades de processamento dupliquem aproximadamente a cada ano ou dois. Por exemplo, a inovação na indústria de semicondutores ajudou a evoluir a Lei de Moore, empilhando chips em formatos menores para escalar o desempenho para níveis antes inimagináveis por meio do paralelismo.

As empresas de semicondutores (ou Electronic Design Automation [EDA]) estão mais interessadas no time to market (TTM). O TTM geralmente se baseia no tempo que leva para cargas de trabalho, como validação de projeto de chip e trabalho de pré-fundição, como fita-out, para ser concluído. As preocupações com o TTM também ajudam a manter os custos de licenciamento da EDA baixos: menos tempo gasto no trabalho significa mais tempo disponível para as licenças. Dito isso, quanto mais largura de banda e capacidade disponível para o farm de servidores, melhor.

O Azure NetApp Files ajuda a reduzir o tempo que os trabalhos EDA levam com uma solução de sistema de arquivos paralelizada de alto desempenho: Arquivos NetApp do Azure grandes volumes. Testes de benchmark EDA recentes mostram que um único volume grande tem 20 vezes mais desempenho do que anteriormente possível com um único volume regular do Azure NetApp Files.

O recurso de grandes volumes do Azure NetApp Files é ideal para as necessidades de armazenamento desse setor mais exigente, a saber:

  • Namespace único de grande capacidade: cada volume oferece de até 500TiB de capacidade utilizável sob um único ponto de montagem.

  • Alta taxa de E/S, baixa latência: em testes usando um benchmark de simulação EDA, um único grande volume entregou mais de 650K IOPS de armazenamento com menos de 2 milissegundos de latência do aplicativo. Em uma carga de trabalho EDA típica, IOPS consiste em uma mistura ou arquivo cria, lê, grava e uma quantidade significativa de outras operações de metadados. Este resultado é considerado um desempenho de nível empresarial para muitos clientes. Essa melhoria de desempenho é possível pela maneira como grandes volumes são capazes de paralelizar operações de gravação de entrada entre recursos de armazenamento nos Arquivos NetApp do Azure. Embora muitas empresas exijam 2ms ou melhor tempo de resposta, as ferramentas de design de chips podem tolerar latência maior do que isso sem impacto nos negócios.

  • Com 826.000 operações por segundo: a borda de desempenho de um único grande volume - a camada de aplicação atingiu um pico de 7ms de latência em nossos testes, o que mostra que mais operações são possíveis em um único grande volume a um pequeno custo de latência.

Os testes realizados usando uma referência EDA descobriram que, com um único volume regular de Arquivos NetApp do Azure, a carga de trabalho de até 40.000 IOPS poderia ser alcançada na marca de 2ms e 50.000 na borda. Consulte a tabela e o gráfico abaixo para obter uma visão geral lado a lado de volumes regulares e grandes.

Cenário Taxa de E/S com latência de 2ms Taxa de E/S na borda de desempenho (~7 ms) MiB/s com latência de 2ms Vantagem de desempenho MiB/s (~7 ms)
Um volume normal 39,601 49,502 692 866
grande volume 652,260 826,379 10,030 12,610

O gráfico a seguir ilustra os resultados do teste.

Gráfico comparando latência e taxa de transferência entre volumes grandes e regulares.

O teste de volume regular também explorou limites de um único objetivo, os limites foram alcançados com seis volumes. Grande volume supera o cenário com seis volumes regulares em 260%. A tabela a seguir ilustra esses resultados.

Cenário Taxa de E/S com latência de 2ms Taxa de E/S na borda de desempenho (~7ms) MiB/s com latência de 2ms Vantagem de desempenho MiB/s (~7ms)
Seis volumes regulares 255,613 317,000 4,577 5,688
Um grande volume 652,260 826,379 10,030 12,610

Simplicidade em escala

Com um grande volume, a performance não é toda a história. O desempenho simples é o objetivo final. Os clientes preferem um único namespace/ponto de montagem em vez de gerenciar vários volumes para facilitar o uso e o gerenciamento de aplicativos.

Ferramenta de teste

A carga de trabalho da EDA neste teste foi gerada usando uma ferramenta padrão de benchmark do setor. Ele simula uma mistura de aplicações EDA usadas para projetar chips semicondutores. A distribuição da carga de trabalho da AED é a seguinte:

Gráfico de pizza representando o tipo de OP frontend.

Tipo de OP Frontend EDA Percentagem do total
Estado 39%
Access 15%
Random_write 15%
Write_file 10%
Random_read 8%
Read_file 7%
Criar 2%
Chmod 1%
Mkdir 1%
Ulink 1%
Ulink2 1%
  • Acrescentar
  • Personalizado2
  • Bloquear
  • Mmap_read
  • Mmap_write
  • Neg_stat
  • Read_modify_write
    • Rmdir
  • Escrever
0%

Gráfico de pizza representando a distribuição do tipo OP de back-end.

Tipo de OP de back-end EDA Percentagem do total
Lida 50%
Escrita 50%
  • Personalizado2
  • Mmap_read
  • Random_read
  • Read_file
  • Read_modify_file
 0%

Configuração de teste

Os resultados foram produzidos usando os detalhes de configuração abaixo:

Componente Configuração
Sistema operativo RHEL 9,3 / RHEL 8,7
Tipo de Instância D16s_v5
Contagem de Instâncias 10
Opções de montagem nocto,actimeo=600,hard,rsize=262144,wsize=262144,vers=3,tcp,noatime,nconnect=8
Sintonizáveis para clientes # Parâmetros de rede. Em unidade de bytes
net.core.wmem_max = 16777216
net.core.wmem_default = 1048576
net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.ipv4.tcp_rmem = 1048576 8388608 16777216
net.ipv4.tcp_wmem = 1048576 8388608 16777216
net.core.optmem_max = 2048000
net.core.somaxconn = 65535

# Configurações em blocos de tamanho de 4 KiB, em bytes eles são
net.ipv4.tcp_mem = 4096 89600 4194304

# Várias opções de rede e sinalizadores
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 0
net.ipv4.
tcp_no_metrics_save = 1
net.ipv4.route.flush = 1
net.ipv4.tcp_low_latency = 1
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_slow_start_after_idle = 0
net.core.netdev_max_backlog = 300000
net.ipv4.tcp_sack = 0
net.ipv4.tcp_dsack = 0
net.ipv4.tcp_fack = 0

# Várias opções de sistema de arquivos / pagecache
vm.dirty_expire_centisecs = 100
vm.dirty_writeback_centisecs = 100
vm.dirty_ratio = 20
vm.dirty_background_ratio = 5

# Ajuste executivo de rede ONTAP para o cliente
sunrpc.tcp_max_slot_table_entries = 128
sunrpc.tcp_slot_table_entries = 128

Monte opções nocto, noatimee trabalhe actimeo=600 em conjunto para aliviar o efeito de algumas operações de metadados para uma carga de trabalho EDA sobre o protocolo NFSv3. Essas opções de montagem reduzem o número de operações de metadados que ocorrem e armazenam em cache alguns atributos de metadados no cliente, permitindo que as cargas de trabalho EDA sejam enviadas mais longe do que de outra forma. É essencial considerar os requisitos de carga de trabalho individuais, pois essas opções de montagem não são universalmente aplicáveis. Para obter mais informações, consulte Práticas recomendadas de opções de montagem do Linux NFS para o Arquivo NetApp do Azure.

Resumo

As cargas de trabalho EDA exigem armazenamento de arquivos que possa lidar com altas contagens de arquivos, grande capacidade e um grande número de operações paralelas em potencialmente milhares de estações de trabalho cliente. As cargas de trabalho EDA também precisam ser executadas em um nível que reduza o tempo necessário para que os testes e a validação sejam concluídos, de modo a economizar dinheiro em licenças e acelerar o tempo de comercialização dos melhores e mais recentes chipsets. Os grandes volumes dos Arquivos NetApp do Azure podem lidar com as demandas de uma carga de trabalho EDA com desempenho comparável ao que seria visto em implantações locais.

Próximos passos