Sdílet prostřednictvím

Výhody použití Azure NetApp Files pro elektronickou automatizaci návrhu (EDA)

Inovace jsou identifikací značky polovodičového průmyslu. Takové inovace umožnily, aby úhelný kámen z roku 1965, známý jako Mooreův zákon, platil více než padesát let, totiž že se dá očekávat zdvojnásobení rychlostí zpracování přibližně každý rok nebo dva. Inovace v polovodičovém průmyslu například pomohla rozvíjet Mooreův zákon tím, že skládaly čipy do menších formových faktorů pro škálování výkonu na jednorázově nepředstavitelné úrovně prostřednictvím paralelismu.

Polovodičové firmy (neboli automatizace elektronického návrhu [EDA]) se nejvíce zajímají o čas uvedení na trh (TTM). TTM se často predikuje na dobu potřebnou pro úlohy, jako je ověřování návrhu čipu a předběžné slévárství, jako je například páskování. Problémy se SPD také pomáhají snížit náklady na licencování EDA, neboť kratší doba strávená prací znamená, že pro licence je k dispozici více času. To znamená, že čím větší šířka pásma a kapacita jsou pro serverové farmy k dispozici, tím lépe.

Azure NetApp Files pomáhá zkrátit dobu zpracování úloh EDA díky vysoce výkonnému a paralelnímu řešení souborového systému: velké svazky Azure NetApp Files. Nedávné srovnávací testy EDA ukazují, že jeden velký svazek je 20krát výkonnější než dříve dosažitelný pomocí jednoho běžného svazku Azure NetApp Files.

Funkce velkých svazků Azure NetApp Files je ideální pro potřeby úložiště tohoto nejnáročnějšího odvětví, konkrétně:

  • Velkokapacitní jednotný jmenný prostor: Každý svazek nabízí až 1 PiB využitelné kapacity pod jedním přípojným bodem. Můžete požádat o velký objem 2 PiB.

  • Vysoká míra vstupně-výstupních operací, nízká latence: Při testování pomocí srovnávacího testu simulace EDA dosáhl jediný velký datový objem přes 650 tisíc IOPS úložiště s latencí aplikace menší než 2 milisekundy. V typické zátěži EDA se IOPS skládá ze směsi operací vytváření, čtení a zápisu souborů a významného množství dalších operací metadat. Tento výsledek se pro mnoho zákazníků považuje za výkon na podnikové úrovni. Toto zlepšení výkonu je možné, protože velké svazky dokážou paralelně zpracovávat příchozí operace zápisu napříč úložnými prostředky ve službě Azure NetApp Files. I když mnoho firem vyžaduje 2ms nebo lepší dobu odezvy, nástroje pro návrh čipů můžou tolerovat vyšší latenci, než je to, aniž by to mělo dopad na firmu.

  • Při 826 000 operacích za sekundu: výkonnostní výhoda jednoho velkého objemu – aplikační vrstva byla v našich testech ve špičce na 7 ms latence, což ukazuje, že v jednom velkém objemu je možné provádět více operací s mírnou cenou v podobě latence.

Testy prováděné pomocí srovnávacího testu EDA zjistily, že při použití jednoho běžného svazku Azure NetApp Files je možné dosáhnout zatížení až 40 000 IOPS při 2ms odezvě a 50 000 na hranici. Přehled běžných a velkých objemů najdete v následující tabulce a grafu.

Scénář Rychlost I/O při latenci 2 ms Rychlost I/O na hranici výkonu (~7 ms) MiB/s při latenci 2 ms Výkonová výhoda MiB/s (~7 ms)
Jeden běžný svazek 39 601 49,502 692 866
velký objem 652,260 826,379 10,030 12,610

Následující graf znázorňuje výsledky testu.

Graf porovnání latence a propustnosti mezi velkými a pravidelnými svazky

Běžné testování svazků také prozkoumalo limity jednoho koncového bodu, k dosažení limitů došlo u šesti svazků. Velký svazek překonává scénář se šesti pravidelnými svazky o 260%. Tyto výsledky jsou znázorněny v následující tabulce.

Scénář Rychlost I/O při latenci 2 ms Rychlost I/O operací na výkonové hranici (~7 ms) MiB/s při latenci 2 ms Výkonnostní náskok MiB/s (~7 ms)
Šest běžných svazků 255,613 317 000 4,577 5,688
Jeden velký svazek 652,260 826,379 10,030 12,610

Jednoduchost ve velkém měřítku

S velkým objemem výkon není celý příběh. Jednoduchý výkon je konečným cílem. Zákazníci preferují jednotný obor názvů nebo přípojný bod místo správy více svazků pro snadnější použití a správu aplikací.

Testovací nástroj

Úloha EDA v tomto testu se vygenerovala pomocí standardního nástroje pro srovnávací testy odvětví. Simuluje kombinaci aplikací EDA používaných k návrhu polovodičových čipů. Distribuce úloh EDA je taková:

Výsečový graf znázorňující typ front-endového operačního postupu

Typ front-endu EDA OP Procento z celkového součtu
Statistika 39%
Přístup 15 %
Náhodný_zápis 15 %
Zapsat_soubor 10 %
Náhodné čtení 8 %
Přečíst_soubor 7%
Vytvářet 2 %
Chmod 1 %
Mkdir 1 %
Ulink 1 %
Ulink2 1 %
  • Připojit
  • Vlastní2
  • Zamknout
  • Mmap_read
  • Mmap_write
  • Negativní stav
  • Čtení_upravit_zapsat
    • Rmdir
  • Psát
0 %

Výsečový graf znázorňující distribuci back-endového typu OP

Typ operace back-endu EDA Procento z celkového součtu
Čti 50 %
Napiš 50 %
  • Vlastní2
  • Mmap_read
  • Náhodné čtení
  • Přečíst_soubor
  • Číst_upravit_soubor
 0 %

Testovací konfigurace

Výsledky byly vytvořeny pomocí následujících podrobností konfigurace:

Součást Konfigurace
Operační systém RHEL 9.3 / RHEL 8.7
Typ instance<|vq_15660|> D16s_v5
Počet instancí 10
Možnosti připojení nocto,actimeo=600,hard,rsize=262144,wsize=262144,vers=3,tcp,noatime,nconnect=8
Laditelné parametry pro klienta # Parametry sítě. V jednotce bajtů
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

# Nastavení v blocích velikosti 4 KiB, což v bajtech je
net.ipv4.tcp_mem = 4096 89600 4194304

# Různé možnosti sítě a příznaky
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

# Různé možnosti systému souborů / pagecache
vm.dirty_expire_centisecs = 100
vm.dirty_writeback_centisecs = 100
vm.dirty_ratio = 20
vm.dirty_background_ratio = 5

# Ladění síťových parametrů ONTAP pro klienta
sunrpc.tcp_max_slot_table_entries = 128
sunrpc.tcp_slot_table_entries = 128

Možnosti připojení nocto, noatime a actimeo=600 spolupracují na zmírnění vlivu některých operací metadat pro pracovní zátěž EDA pomocí protokolu NFSv3. Tyto možnosti připojení úložiště snižují počet probíhajících operací metadat a ukládají do mezipaměti některé atributy metadat na klientovi, což umožňuje úlohám EDA dosáhnout většího výkonu, než by jinak bylo možné. Je důležité vzít v úvahu jednotlivé požadavky na úlohy, protože tyto možnosti připojení nejsou všeobecně použitelné. Další informace najdete v tématu Osvědčené postupy pro možnosti připojení systému souborů NFS pro Linux pro Azure NetApp File.

Shrnutí

Úlohy EDA vyžadují úložiště souborů, které dokáže zpracovávat vysoký počet souborů, velkou kapacitu a velký počet paralelních operací napříč potenciálně tisíci klientských pracovních stanic. Úlohy EDA musí také provádět na úrovni, která zkracuje dobu potřebnou k dokončení testování a ověřování, aby se ušetřily peníze na licence a urychlily uvedení na trh pro nejnovější a největší čipové sady. Velké svazky Azure NetApp Files můžou zpracovávat požadavky úlohy EDA s výkonem srovnatelným s tím, co by bylo vidět v místních nasazeních.

Další kroky