Delen via

Voordelen van het gebruik van Azure NetApp Files voor Electronic Design Automation (EDA)

  • Artikel

Innovatie is een identificerend kenmerk van de halfgeleiderindustrie. Door dergelijke innovatie kon Gordon Moore's 1965-tenet dat bekend staat als Moore's Law meer dan vijftig jaar waar blijven, namelijk dat men kan verwachten dat verwerkingssnelheden ongeveer elk jaar of twee verdubbelen. Innovatie in de halfgeleiderindustrie heeft bijvoorbeeld geholpen bij het ontwikkelen van Moore's Law door chips te stapelen in kleinere vormfactoren om de prestaties te schalen naar één keer onvoorstelbare niveaus via parallelle uitvoering.

Halfgeleiderbedrijven (of Electronic Design Automation [EDA]) zijn het meest geïnteresseerd in de markt (TTM). TTM wordt vaak geprediceerd op de tijd die nodig is voor workloads, zoals chipontwerpvalidatie en pre-foundry werken zoals tape-out om te voltooien. TTM-problemen helpen ook om de EDA-licentiekosten te verlagen: minder tijd die aan het werk wordt besteed, betekent meer tijd beschikbaar voor de licenties. Dat gezegd hebbende, hoe meer bandbreedte en capaciteit beschikbaar zijn voor de serverfarm, hoe beter.

Azure NetApp Files helpt de tijd die EDA-taken in beslag nemen met een zeer presterende, geparallelliseerde bestandssysteemoplossing: Azure NetApp Files grote volumes. Recente EDA-benchmarktests tonen aan dat één groot volume 20 keer beter presteert dan voorheen mogelijk was met één normaal Volume van Azure NetApp Files.

De azure NetApp Files-functie voor grote volumes is ideaal voor de opslagbehoeften van deze meest veeleisende branche, namelijk:

  • Grote capaciteit enkelvoudige naamruimte: elk volume biedt van maximaal 500TiB van bruikbare capaciteit onder één koppelpunt.

  • Hoge I/O-snelheid, lage latentie: bij het testen met behulp van een EDA-simulatiebenchmark levert één groot volume meer dan 650K-opslag-IOPS met minder dan 2 milliseconden van toepassingslatentie. In een typische EDA-workload bestaat IOPS uit een combinatie of bestand dat wordt gemaakt, gelezen, geschreven en een aanzienlijke hoeveelheid andere metagegevensbewerkingen. Dit resultaat wordt beschouwd als hoogwaardige prestaties voor veel klanten. Deze prestatieverbetering wordt mogelijk gemaakt door de manier waarop grote volumes binnenkomende schrijfbewerkingen kunnen parallelliseren voor opslagresources in Azure NetApp Files. Hoewel veel bedrijven 2 ms of betere reactietijd vereisen, kunnen chipontwerphulpprogramma's hogere latentie tolereren dan dit zonder gevolgen voor het bedrijf.

  • Bij 826.000 bewerkingen per seconde: de prestatierand van één groot volume: de toepassingslaag piekte bij 7 ms latentie in onze tests, wat laat zien dat er meer bewerkingen mogelijk zijn in één groot volume tegen een lichte latentiekosten.

Tests die worden uitgevoerd met behulp van een EDA-benchmark, hebben vastgesteld dat met één normaal Azure NetApp Files-volume de workload zo hoog als 40.000 IOPS kan worden bereikt op de 2 ms-markering en 50.000 aan de rand. Zie de onderstaande tabel en grafiek voor een overzicht van het normale en grote volume naast elkaar.

Scenario I/O-snelheid met latentie van 2 ms I/O-snelheid bij prestatierand (~7 ms) MiB/s met latentie van 2 ms MiB/s-prestatierand (~7 ms)
Eén normaal volume 39,601 49,502 692 866
groot volume 652,260 826,379 10,030 12,610

In de volgende grafiek ziet u de testresultaten.

Grafiek met het vergelijken van latentie en doorvoer tussen grote en reguliere volumes.

De reguliere volumetests verkenden ook enkele eindpuntlimieten, de limieten werden bereikt met zes volumes. Groot volume presteert beter dan het scenario met zes reguliere volumes met 260%. In de volgende tabel ziet u deze resultaten.

Scenario I/O-snelheid met latentie van 2 ms I/O-snelheid bij prestatierand (~7 ms) MiB/s met latentie van 2 ms MiB/s-prestatierand (~7 ms)
Zes reguliere volumes 255,613 317,000 4,577 5,688
Eén groot volume 652,260 826,379 10,030 12,610

Eenvoud op schaal

Met een groot volume is de prestaties niet het hele verhaal. Eenvoudige prestaties zijn het einddoel. Klanten geven de voorkeur aan één naamruimte/koppelpunt in plaats van meerdere volumes te beheren voor gebruiksgemak en toepassingsbeheer.

Testprogramma

De EDA-workload in deze test is gegenereerd met behulp van een standaardhulpprogramma voor industriebenchmarks. Het simuleert een combinatie van EDA-toepassingen die worden gebruikt om halfgeleiderchips te ontwerpen. De distributie van de EDA-werkbelasting is als volgt:

Cirkeldiagram met front-end-OP-type.

EDA Front-end OP-type Percentage van totaal
Stat 39%
Access 15%
Random_write 15%
Write_file 10%
Random_read %8
Read_file %7
Maken %2
Chmod %1
Mkdir %1
Ulink %1
Ulink2 %1
  • Toevoegen
  • Aangepast2
  • Vergrendelen
  • Mmap_read
  • Mmap_write
  • Neg_stat
  • Read_modify_write
    • Rmdir
  • Schrijven
0%

Cirkeldiagram met distributie van back-end-OP-type.

Op-type EDA-back-end Percentage van totaal
Read 50%
Schrijven 50%
  • Aangepast2
  • Mmap_read
  • Random_read
  • Read_file
  • Read_modify_file
 0%

Testconfiguratie

De resultaten zijn geproduceerd met behulp van de onderstaande configuratiedetails:

Onderdeel Configuratie
Besturingssysteem RHEL 9.3 / RHEL 8.7
Type van exemplaar D16s_v5
Aantal instanties 10
Opties voor koppelen nocto,actimeo=600,hard,rsize=262144,wsize=262144,vers=3,tcp,noatime,nconnect=8
Client kan niet worden ondersteund # Netwerkparameters. In eenheid van 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

# Instellingen in segmenten van 4 KiB-grootte, in bytes
net.ipv4.tcp_mem = 4096 89600 4194304

# Misc-netwerkopties en -vlaggen
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

# Diverse opties voor bestandssysteem/pagecache
vm.dirty_expire_centisecs = 100
vm.dirty_writeback_centisecs = 100
vm.dirty_ratio = 20
vm.dirty_background_ratio = 5

# ONTAP-netwerkexec tuning voor client
sunrpc.tcp_max_slot_table_entries = 128
sunrpc.tcp_slot_table_entries = 128

Koppelopties noctoen noatimeactimeo=600 werk samen om het effect van sommige metagegevensbewerkingen voor een EDA-workload te verlichten via het NFSv3-protocol. Deze koppelingsopties verminderen zowel het aantal metagegevensbewerkingen dat wordt uitgevoerd als cache sommige metagegevenskenmerken op de client, zodat EDA-workloads verder kunnen pushen dan anders. Het is essentieel om rekening te houden met afzonderlijke workloadvereisten, omdat deze koppelingsopties niet universeel van toepassing zijn. Zie de aanbevolen procedures voor koppelen van Linux NFS voor Azure NetApp File voor meer informatie.

Samenvatting

Voor EDA-workloads is bestandsopslag vereist die veel bestandsaantallen, grote capaciteit en een groot aantal parallelle bewerkingen op mogelijk duizenden clientwerkstations kan verwerken. EDA-workloads moeten ook op een niveau worden uitgevoerd dat de tijd die nodig is voor het testen en valideren vermindert, zodat u geld bespaart op licenties en de tijd die nodig is om de markt te versnellen voor de nieuwste en beste chipsets. Grote volumes van Azure NetApp Files kunnen voldoen aan de vereisten van een EDA-workload met prestaties die vergelijkbaar zijn met wat er in on-premises implementaties zou worden gezien.

Volgende stappen