Dela via

Fördelar med att använda Azure NetApp Files for Electronic Design Automation (EDA)

  • Artikel

Innovation är ett kännetecken för halvledarbranschen. Sådan innovation tillät Gordon Moores 1965-grundsats känd som Moore's Law att gälla i mer än femtio år, nämligen att man kan förvänta sig att bearbetningshastigheterna fördubblas ungefär varje år eller två. Till exempel har innovation inom halvledarindustrin hjälpt till att utveckla Moores lag genom att stapla chips i mindre formfaktorer för att skala prestanda till en gång ofattbara nivåer genom parallellitet.

Halvledarföretag (eller Electronic Design Automation [EDA]) är mest intresserade av tid till marknad (TTM). TTM bygger ofta på den tid det tar för arbetsbelastningar, till exempel validering av chipdesign och gjuteriarbete som band ut att slutföra. TTM-problem hjälper också till att hålla EDA-licenskostnaderna nere: mindre tid på arbetet innebär mer tid för licenserna. Ju mer bandbredd och kapacitet som är tillgänglig för servergruppen, desto bättre.

Azure NetApp Files hjälper till att minska tiden som EDA-jobb tar med en mycket högpresterande, parallelliserad filsystemlösning: Stora volymer i Azure NetApp Files. De senaste EDA-benchmark-testerna visar att en enda stor volym är 20 gånger mer högpresterande än vad som tidigare kunde uppnås med en enda vanlig Azure NetApp Files-volym.

Funktionen stora volymer i Azure NetApp Files passar perfekt för lagringsbehoven i den här mest krävande branschen, nämligen:

  • Enkel namnrymd för stor kapacitet: Varje volym erbjuder upp till 500TiB användbar kapacitet under en enda monteringspunkt.

  • Hög I/O-hastighet, låg svarstid: Vid testning med ett EDA-simuleringsmått levereras en enda stor volym över 650 000 lagrings-IOPS med mindre än 2 millisekunder programfördröjning. I en typisk EDA-arbetsbelastning består IOPS av en blandning eller fil som skapar, läser, skriver och en betydande mängd andra metadataåtgärder. Det här resultatet anses vara prestanda i företagsklass för många kunder. Den här prestandaförbättringen möjliggörs genom att stora volymer kan parallellisera inkommande skrivåtgärder mellan lagringsresurser i Azure NetApp Files. Även om många företag kräver 2 ms eller bättre svarstid, kan chipdesignverktyg tolerera högre svarstid än detta utan påverkan på verksamheten.

  • Vid 826 000 åtgärder per sekund: prestandagränsen för en enda stor volym – programskiktet nådde en topp på 7 ms svarstid i våra tester, vilket visar att fler åtgärder är möjliga på en enda stor volym till en liten fördröjningskostnad.

Tester som utfördes med ett EDA-riktmärke visade att med en enda vanlig Azure NetApp Files-volym kunde arbetsbelastningen så hög som 40 000 IOPS uppnås vid 2ms-märket och 50 000 vid gränsen. Se tabellen och diagrammet nedan för regelbunden och stor volym sida vid sida- översikt.

Scenario I/O-hastighet med 2 ms svarstid I/O-hastighet vid prestandagränsen (~7 ms) MiB/s vid 2 ms svarstid Prestandagräns för MiB/s (~7 ms)
En vanlig volym 39,601 49,502 692 866
stor volym 652,260 826,379 10,030 12,610

Följande diagram illustrerar testresultaten.

Diagram som jämför svarstid och dataflöde mellan stora och vanliga volymer.

Den regelbundna volymtestningen utforskade även gränser för enskilda slutpunkter, gränserna nåddes med sex volymer. Stora volymer överträffar scenariot med sex vanliga volymer med 260 %. Följande tabell illustrerar dessa resultat.

Scenario I/O-hastighet med 2 ms svarstid I/O-hastighet vid prestandagränsen (~7 ms) MiB/s vid 2 ms svarstid Prestandagräns för MiB/s (~7 ms)
Sex vanliga volymer 255,613 317,000 4,577 5,688
En stor volym 652,260 826,379 10,030 12,610

Enkelhet i stor skala

Med en stor volym är prestanda inte hela berättelsen. Enkel prestanda är slutmålet. Kunder föredrar en enda namnrymd/monteringspunkt i stället för att hantera flera volymer för enkel användning och programhantering.

Testverktyg

EDA-arbetsbelastningen i det här testet genererades med ett standardverktyg för branschriktmärken. Den simulerar en blandning av EDA-program som används för att utforma halvledarchips. EDA-arbetsbelastningsdistributionen är så här:

Cirkeldiagram som visar OP-typen i klientdelen.

Op-typ för EDA-klientdel Procentandel av totalt
Delstat 39%
Access 15 %
Random_write 15 %
Write_file 10 %
Random_read %8
Read_file %7
Skapa %2
Chmod 1 %
Mkdir 1 %
Ulink 1 %
Ulink2 1 %
  • Lägga till
  • Anpassad 2
  • Lås
  • Mmap_read
  • Mmap_write
  • Neg_stat
  • Read_modify_write
    • Rmdir
  • Skriva
0 %

Cirkeldiagram som visar distribution av OP-typ i serverdelen.

Op-typ för EDA-serverdel Procentandel av totalt
Lästa 50 %
Skriva 50 %
  • Anpassad 2
  • Mmap_read
  • Random_read
  • Read_file
  • Read_modify_file
 0 %

Testkonfiguration

Resultatet producerades med hjälp av konfigurationsinformationen nedan:

Komponent Konfiguration
Operativsystem RHEL 9.3 / RHEL 8.7
Instanstyp D16s_v5
Antal instanser 10
Monteringsalternativ nocto,actimeo=600,hard,rsize=262144,wsize=262144,vers=3,tcp,noatime,nconnect=8
Klient tunables # Nätverksparametrar. I byteenhet
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

# Inställningar i 4 KiB-storlekssegment, i byte är de
net.ipv4.tcp_mem = 4096 89600 4194304

# Alternativ och flaggor för felnätverk
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

# Olika alternativ för filsystem/sidcache
vm.dirty_expire_centisecs = 100
vm.dirty_writeback_centisecs = 100
vm.dirty_ratio = 20
vm.dirty_background_ratio = 5

# Utökningsjustering av ONTAP-nätverk för klienten
sunrpc.tcp_max_slot_table_entries = 128
sunrpc.tcp_slot_table_entries = 128

Monteringsalternativ nocto, noatimeoch actimeo=600 arbeta tillsammans för att lindra effekten av vissa metadataåtgärder för en EDA-arbetsbelastning via NFSv3-protokollet. Dessa monteringsalternativ minskar både antalet metadataåtgärder som äger rum och cachelagrar vissa metadataattribut på klienten så att EDA-arbetsbelastningar kan push-överföras ytterligare än annars. Det är viktigt att överväga enskilda arbetsbelastningskrav eftersom dessa monteringsalternativ inte är universellt tillämpliga. Mer information finns i Metodtips för Linux NFS-monteringsalternativ för Azure NetApp File.

Sammanfattning

EDA-arbetsbelastningar kräver fillagring som kan hantera höga filantal, stor kapacitet och ett stort antal parallella åtgärder över potentiellt tusentals klientarbetsstationer. EDA-arbetsbelastningar måste också utföras på en nivå som minskar den tid det tar för testning och validering att slutföras så att du sparar pengar på licenser och påskyndar tiden till marknaden för de senaste och största chipsetarna. Stora volymer i Azure NetApp Files kan hantera kraven för en EDA-arbetsbelastning med prestanda som är jämförbara med vad som skulle visas i lokala distributioner.

Nästa steg