Dela via

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

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 arbetsuppgifter, som validering av chipdesign och gjuteriarbete som tape-out, att slutföras. 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 19 gånger mer högpresterande än vad som tidigare kunde uppnås med en enda vanlig Azure NetApp Files-volym. När flera stora volymer läggs till och det finns tillräckligt med beräknings- och lagringsresurser i samlokal konfiguration kan arkitekturen skalas sömlöst.

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

  • En enda namnrymd med stor kapacitet: Varje volym erbjuder upp till 1 PiB användbar kapacitet under en enda monteringspunkt. Du kan begära en volym på 2 PiB.

  • Hög I/O-hastighet, låg svarstid: Vid testning med ett EDA-simuleringsmått levereras en enda stor volym över 740 000 lagrings-IOPS med mindre än 2 millisekunder programfördröjning. I en typisk EDA-arbetsbelastning består IOPS av en blandning av filskapande, läsningar, skrivningar och en avsevärd mängd andra metadataoperationer. 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 att påverka verksamheten.

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

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 följande tabell och diagram för en regelbunden och en stor volymkonfiguration, jämförelse sida vid sida.

Scenario I/O-hastighet med 2 ms svarstid I/O-hastighet vid prestandagränsen (~3 ms) MiB/s vid 2 ms svarstid Prestandagräns för MiB/s (~7 ms)
En vanlig volym 39,601 49,502 692 866
En stor volym 742,541 742,541 11,699 12,480

Följande diagram illustrerar testresultaten.

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

En enda stor volym överträffar scenariot med sex vanliga volymer med 249%. Med sex stora volymer var prestandaskalningen linjär jämfört med en enda stor volym. I följande tabell och diagram visas resultatet för sex vanliga volymer, en stor volym och sex stora volymer:

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 742,541 742,541 11,699 12,480
Sex stora volymer 4,435,382 4,745,453 69,892 74,694

Diagram som jämför svarstid och dataflöde mellan en stor, en vanlig och sex stora volymer.

Enkelhet i stor skala

Med en stor volym är prestanda inte hela bilden. Enkel prestanda är slutmålet.

Sömlös skalning

Resultaten visar att Azure NetApp Files levererade horisontell skalbarhet för både dataflöde och åtgärder/sekund. Varje stor volym distribuerar en dedikerad lagringsslutpunkt som gör att prestanda kan skalas linjärt utan att offra svarstiden.

Mätvärde Stor volym Stor volymskala Faktor
Dataflöde (MB/s) 12,780 76 487 5.98
Åtgärder/sekund 792,046 4,745,453 5.99

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.

EDA-gränssnitt OP-typ Procentandel av totalt
Delstat 39%
Åtkomst 15 %
Random_write 15 %
Write_file 10 %
Slumpmässig_läsning %8
Läs_fil %7
Skapa 2%
Chmod 1 %
Mkdir 1 %
Ulink 1 %
Ulink2 1 %
  • Lägga till
  • Anpassad 2
  • Lås
  • Mmap_read
  • Mmap_write
  • Neg_stat
  • Läsa_ändra_skriva
    • Rmdir
  • Skriva
0 %

Cirkeldiagram som visar fördelningen av OP-typer i backend-delen.

Op-typ för EDA-serverdel Procentandel av totalt
Läs 50 %
Skriva 50 %
  • Anpassad 2
  • Mmap_read
  • Slumpmässig_läsning
  • Läs_fil
  • Läs_ändra_fil
 0 %

Testkonfiguration

Resultaten producerades med hjälp av följande konfigurationsinformation:

Arkitekturdiagram för en enda stor volym.

Komponent Konfiguration
Operativsystem Red Hat Enterprise Linux
Instanstyp D16s_v5/D32s_v5
Antal instanser 10
Monteringsalternativ nocto,actimeo=600, hard, rsize=262144, wsize=262144, vers=3, tcp, noatime, nconnect=8
Klientinställningar # 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 = 4194304
net.core.somaxconn = 65535

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

# Diverse nätverksalternativ och flaggor
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 = 30000
vm.dirty_writeback_centisecs = 30000

Monteringsalternativen nocto, noatime och actimeo=600 arbetar tillsammans för att lindra effekten av vissa metadataåtgärder för en EDA-arbetsbelastning via NFSv3-protokoll. Dessa monteringsalternativ minskar både antalet metadataåtgärder som äger rum och cachelagrar vissa metadataattribut på klienten, vilket möjliggör att EDA-arbetsbelastningar kan utnyttjas mer effektivt ä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.

För de sex stora volymtesterna replikerades samma konfiguration i sex Azure-tillgänglighetszoner, spridda över fyra Azure-regioner. Varje zon har konfigurerats identiskt med tio virtuella datorer och en stor volym som var och en finns i en tillgänglighetszon. Azures peering för virtuella nätverk anslöt de virtuella nätverken mellan regioner/zoner så att vi kunde köra en enda benchmark-körning som sträckte sig över alla klienter samtidigt.

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, vilket leder till att du sparar pengar på licenser och påskyndar tiden för att marknadsföra de senaste och största kretsuppsättningarna. 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