Vantaggi dell'uso di Azure NetApp Files per l'automazione elettronica della progettazione (EDA)

L'innovazione è un segno distintivo dell'industria dei semiconduttori. Tale innovazione ha permesso al tenet di Gordon Moore del 1965 noto come Legge di Moore di tenere il vero per più di cinquanta anni, vale a dire che una velocità di elaborazione può raddoppiare circa ogni anno o due. Ad esempio, l'innovazione nel settore dei semiconduttori ha aiutato a evolvere la legge di Moore impilate in chip di forma più piccoli per ridimensionare le prestazioni a livelli inimmaginabili una volta attraverso il parallelismo.

Le aziende di semiconduttori (o Electronic Design Automation [EDA]) sono maggiormente interessate al time to market (TTM). TTM viene spesso predicato sul tempo necessario per i carichi di lavoro, ad esempio la convalida della progettazione del chip e il lavoro pre-trovatore come tape-out per il completamento. Le preoccupazioni TTM aiutano anche a ridurre i costi delle licenze EDA: meno tempo dedicato al lavoro significa più tempo disponibile per le licenze. Detto questo, maggiore è la larghezza di banda e la capacità disponibili per la server farm, meglio.

Azure NetApp Files consente di ridurre il tempo necessario per i processi EDA con una soluzione di file system parallelizzata ad alte prestazioni: volumi di grandi dimensioni di Azure NetApp Files. I test di benchmark EDA recenti mostrano che un singolo volume di grandi dimensioni è 20 volte più efficiente rispetto a quello precedentemente raggiungibile con un singolo volume regolare di Azure NetApp Files.

La funzionalità Volumi di grandi dimensioni di Azure NetApp Files è ideale per le esigenze di archiviazione di questo settore più esigente, vale a nome:

  • Spazio dei nomi singolo di capacità di grandi dimensioni: ogni volume offre fino a 500TiB di capacità utilizzabile in un singolo punto di montaggio.

  • Velocità di I/O elevata, bassa latenza: durante i test con un benchmark di simulazione EDA, un singolo volume di grandi dimensioni recapitato oltre 650.000 operazioni di I/O al secondo di archiviazione con meno di 2 millisecondi di latenza dell'applicazione. In un carico di lavoro EDA tipico, le operazioni di I/O al secondo sono costituite da una combinazione o da un file che crea, legge, scrive e una quantità significativa di altre operazioni di metadati. Questo risultato è considerato prestazioni di livello aziendale per molti clienti. Questo miglioramento delle prestazioni è reso possibile dal modo in cui grandi volumi sono in grado di parallelizzare le operazioni di scrittura in ingresso tra le risorse di archiviazione in Azure NetApp Files. Sebbene molte aziende richiedano 2 ms o tempi di risposta migliori, gli strumenti di progettazione chip possono tollerare una latenza superiore a questa senza alcun impatto sull'azienda.

  • A 826.000 operazioni al secondo: il bordo delle prestazioni di un singolo volume di grandi dimensioni, il livello dell'applicazione ha raggiunto il picco di 7 ms di latenza nei test, che mostra che più operazioni sono possibili in un singolo volume di grandi dimensioni a un costo leggero di latenza.

I test eseguiti internamente usando un benchmark EDA nel 2020 hanno rilevato che con un singolo volume regolare di Azure NetApp Files, un carico di lavoro massimo di 40.000 operazioni di I/O al secondo può essere raggiunto al contrassegno di 2 ms e 50.000 al perimetro.

Scenario Velocità di I/O a latenza di 2 ms Velocità di I/O al perimetro delle prestazioni (~7 ms) MiB/s a latenza di 2 ms Bordo prestazioni MiB/s (~7 ms)
Un volume regolare 39,601 49,502 692 866
volume di grandi dimensioni 652,260 826,379 10,030 12,610

Il grafico seguente illustra i risultati del test.

Grafico che confronta la latenza e velocità effettiva tra volumi di grandi dimensioni e normali.

I test interni del 2020 hanno anche esplorato i limiti dei singoli endpoint, i limiti sono stati raggiunti con sei volumi. Volume di grandi dimensioni supera lo scenario con sei volumi regolari del 260%.

Scenario Velocità di I/O a latenza di 2 ms Velocità di I/O al perimetro delle prestazioni (~7 ms) MiB/s a latenza di 2 ms Bordo prestazioni MiB/s (~7 ms)
Sei volumi regolari 255,613 317,000 4,577 5,688
Un volume di grandi dimensioni 652,260 826,379 10,030 12,610

Semplicità su larga scala

Con un volume elevato, le prestazioni non sono l'intera storia. Le prestazioni semplici sono l'obiettivo finale. I clienti preferiscono un singolo spazio dei nomi/punto di montaggio anziché gestire più volumi per semplificare l'uso e la gestione delle applicazioni.

Strumento di test

Il carico di lavoro EDA in questo test è stato generato usando uno strumento standard di benchmark del settore. Simula una combinazione di applicazioni EDA usate per progettare chip a semiconduttori. La distribuzione del carico di lavoro EDA è simile alla seguente:

Grafico a torta che illustra il tipo op front-end.

Tipo OP front-end EDA Percentuale del totale
Stat 39%
Accesso 15%
Random_write 15%
Write_file 10%
Random_read %8
Read_file 7%
Creazione 2%
Chmod %1
Mkdir %1
Ulink %1
Ulink2 %1
  • Aggiunta
  • Custom2
  • Blocca
  • Mmap_read
  • Mmap_write
  • Neg_stat
  • Read_modify_write
  • Rmdir
  • Scrivere
0%

Grafico a torta che illustra la distribuzione del tipo op back-end.

Tipo OP back-end EDA Percentuale del totale
Lettura 50%
Scrittura 50%
  • Custom2
  • Mmap_read
  • Random_read
  • Read_file
  • Read_modify_file
0%

configurazione di test

I risultati sono stati generati usando i dettagli di configurazione seguenti:

Componente Impostazione
Sistema operativo RHEL 9.3 / RHEL 8.7
Tipo di istanza D16s_v5
Numero di istanze 10
Opzioni di montaggio nocto,actimeo=600,hard,rsize=262144,wsize=262144,vers=3,tcp,noatime,nconnect=8
Ottimizzazioni dei clienti # Parametri di rete. In unità di byte
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

# Impostazioni in blocchi di dimensioni 4 KiB, in byte sono
net.ipv4.tcp_mem = 4096 89600 4194304

# Opzioni e flag di rete misc
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

# Varie opzioni di file system/pagecache
vm.dirty_expire_centisecs = 100
vm.dirty_writeback_centisecs = 100
vm.dirty_ratio = 20
vm.dirty_background_ratio = 5

Ottimizzazione dell'esecuzione della rete ONTAP per il client
sunrpc.tcp_max_slot_table_entries = 128
sunrpc.tcp_slot_table_entries = 128

Le opzioni noctodi montaggio , noatimee actimeo=600 interagiscono per alleviare l'effetto di alcune operazioni di metadati per un carico di lavoro EDA sul protocollo NFSv3. Queste opzioni di montaggio riducono il numero di operazioni di metadati eseguite e memorizzano nella cache alcuni attributi di metadati nel client consentendo ai carichi di lavoro EDA di eseguire il push oltre il contrario. È essenziale considerare i singoli requisiti del carico di lavoro perché queste opzioni di montaggio non sono applicabili universalmente. Per altre informazioni, vedere Procedure consigliate per le opzioni di montaggio NFS linux per Azure NetApp File.

Riepilogo

I carichi di lavoro EDA richiedono l'archiviazione file che può gestire conteggi di file elevati, capacità elevata e un numero elevato di operazioni parallele in migliaia di workstation client. Anche i carichi di lavoro EDA devono eseguire a un livello che riduce il tempo necessario per il completamento dei test e della convalida in modo da risparmiare denaro sulle licenze e accelerare il time-to-market per i chipset più recenti e più grandi. I volumi di grandi dimensioni di Azure NetApp Files possono gestire le richieste di un carico di lavoro EDA con prestazioni simili a quelle visualizzate nelle distribuzioni locali.

Passaggi successivi