Vantaggi dell'uso di Azure NetApp Files per l'automazione della progettazione elettronica (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 usando un benchmark EDA hanno rilevato che con un singolo volume regolare di Azure NetApp Files, un carico di lavoro con un massimo di 40.000 operazioni di I/O al secondo può essere ottenuto a 2 ms e 50.000 al perimetro. Vedere la tabella e il grafico seguenti per una panoramica affiancata di volumi regolari e di grandi dimensioni.
| 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.
Il test regolare del volume ha 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%. Nella tabella seguente vengono illustrati questi risultati.
| 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:
| 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 |
|
0% |
| Tipo OP back-end EDA | Percentuale del totale |
|---|---|
| Lettura | 50% |
| Scrittura | 50% |
|
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 |
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.