Benefícios de usar o Azure NetApp Files para Automação de Design Eletrônico (EDA)

  • Artigo

A inovação é uma marca de identificação da indústria de semicondutores. Essa inovação permitiu que o princípio de 1965 de Gordon Moore, conhecido como Lei de Moore, se mantivesse verdadeiro por mais de cinquenta anos, ou seja, que se pode esperar que as velocidades de processamento dobrem 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 fatores forma menores para dimensionar o desempenho para níveis outrora inimagináveis através do paralelismo.

As empresas de semicondutores (ou Design Eletrônico Automatizado [EDA]) estão mais interessadas no tempo para o mercado (TTM). O TTM muitas vezes é baseado no tempo que leva para as cargas de trabalho, como validação de design de chip e trabalhos pré-fabricação, como a finalização, serem concluídas. As preocupações com TTM também ajudam a manter os custos de licenciamento do EDA baixos: menos tempo gasto no trabalho significa mais tempo disponível para as licenças. Dito isto, quanto mais largura de banda e capacidade disponíveis para o farm de servidores, melhor.

O Azure NetApp Files ajuda a reduzir o tempo que os trabalhos do EDA levam com uma solução de sistema de arquivos paralelizada de alto desempenho: Grandes volumes do Azure NetApp Files. Testes recentes de referência de EDA mostram que um único volume grande tem um desempenho 20 vezes maior do que o 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 deste setor mais exigente, ou seja:

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

  • Alta taxa de E/S, baixa latência: em testes usando um parâmetro de comparação de simulação de EDA, um único volume grande entregou mais de 650 mil IOPS de armazenamento com menos de 2 milissegundos de latência do aplicativo. Em uma carga de trabalho típica de EDA, as IOPS consistem em uma mistura de criações, leituras e gravações de arquivos, além de uma quantidade significativa de outras operações de metadados. Esse 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 em recursos de armazenamento no Azure NetApp Files. Embora muitas empresas exijam um tempo de resposta de 2ms ou melhor, as ferramentas de design de chip podem tolerar latência mais alta do que isso sem impacto nos negócios.

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

Testes realizados internamente usando um parâmetro de comparação de EDA em 2020 descobriram que, com um único volume regular do Azure NetApp Files, uma carga de trabalho de até 40.000 IOPS poderia ser alcançada na marca de 2ms e 50.000 na borda.

Cenário Taxa de E/S em latência de 2 ms Taxa de E/S na borda de desempenho (~7 ms) MiB/s com latência de 2 ms MiB/s na borda de desempenho (~7 ms)
Um volume regular 39.601 49.502 692 866
volume grande 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.

Os testes internos de 2020 também exploraram os limites de um único ponto de extremidade, e os limites foram alcançados com seis volumes. O volume grande supera o cenário com seis volumes regulares em 260%.

Cenário Taxa de E/S em latência de 2 ms Taxa de E/S na borda de desempenho (~7ms) MiB/s com latência de 2 ms MiB/s na borda de desempenho (~7ms)
Seis volumes regulares 255.613 317.000 4.577 5.688
Um volume grande 652.260 826.379 10.030 12.610

Simplicidade em escala

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

Ferramenta de testes

A carga de trabalho de EDA neste teste foi gerada usando uma ferramenta de parâmetro de comparação padrão do setor. Ela simula uma mistura de aplicativos EDA usados para projetar chips semicondutores. A distribuição da carga de trabalho de EDA é assim:

Gráfico de pizza que ilustra o tipo de OP do front-end.

Tipo de OP do front-end do EDA Porcentagem do Total
Stat 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
  • Custom2
  • Lock
  • Mmap_read
  • Mmap_write
  • Neg_stat
  • Read_modify_write
    • Rmdir
  • Gravar
0%

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

Tipo de OP do back-end do EDA Porcentagem do Total
Ler 50%
Gravar 50%
  • Custom2
  • 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 operacional 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
Ajustáveis do cliente # Parâmetros de rede. Na 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 partes de tamanho de 4 KiB, em bytes
net.ipv4.tcp_mem = 4096 89600 4194304

# Opções e sinalizadores de rede diversos
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

# Diversas opções de sistema de arquivos / cache de página
vm.dirty_expire_centisecs = 100
vm.dirty_writeback_centisecs = 100
vm.dirty_ratio = 20
vm.dirty_background_ratio = 5

# Ajustes de execução de rede ONTAP para cliente
sunrpc.tcp_max_slot_table_entries = 128
sunrpc.tcp_slot_table_entries = 128

As opções de montagem nocto, noatime e actimeo=600 trabalham em conjunto para aliviar o efeito de algumas operações de metadados para uma carga de trabalho de EDA sobre o protocolo NFSv3. Essas opções de montagem reduzem tanto o número de operações de metadados em andamento quanto armazenam em cache alguns atributos de metadados no cliente, permitindo que as cargas de trabalho de EDA avancem mais do que o normal. É 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 as melhores práticas de opções de montagem do Linux NFS para o Azure NetApp Files.

Resumo

As cargas de trabalho de EDA requerem armazenamento de arquivos que possa lidar com uma grande quantidade de arquivos, capacidade ampla e um grande número de operações paralelas em potencial em milhares de estações de trabalho cliente. As cargas de trabalho de EDA também precisam operar em um nível que reduza o tempo necessário para testes e validação serem concluídos, economizando assim dinheiro em licenças e acelerando o tempo de lançamento para os conjuntos de chips mais recentes e avançados. Os grandes volumes do Azure NetApp Files podem lidar com as demandas de uma carga de trabalho de EDA com desempenho comparável ao que seria visto em implantações locais.

Próximas etapas