Výhody používání služby Azure NetApp Files pro automatizaci elektronického návrhu (EDA)
Inovace jsou identifikací značky polovodičového průmyslu. Tyto inovace umožnily Gordon Mooreovi 1965 tenet známý jako Mooreův zákon držet true více než padesát let, a to, že jeden může očekávat rychlosti zpracování zdvojnásobit 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 S TTM také pomáhají snížit náklady na licencování EDA: 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, kterou úlohy EDA provádějí s vysoce výkonným a paralelizovaným řešením systému souborů: 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ě:
Jeden obor názvů s velkou kapacitou: Každý svazek nabízí až 500TiB využitelné kapacity v rámci jednoho přípojného bodu.
Vysoká míra vstupně-výstupních operací, nízká latence: Při testování pomocí srovnávacího testu simulace EDA je jeden velký objem doručovaný přes 650 tisíc IOPS úložiště s latencí aplikace menší než 2 milisekundy. V typické úloze EDA se vstupně-výstupní operace skládá ze směsi nebo souboru, čtení, zápisů 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é díky tomu, že velké svazky dokážou paralelně paralelizovat příchozí operace zápisu napříč prostředky úložiště 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ýkonová hrana jednoho velkého svazku – aplikační vrstva byla v našich testech ve špičce na 7 min. latence, což ukazuje, že v jednom velkém objemu je možné provádět více operací s mírnými náklady na latenci.
Testy prováděné interně pomocí srovnávacího testu EDA v roce 2020 zjistily, že u jednoho běžného svazku Azure NetApp Files je možné dosáhnout zatížení s maximálním počtem 40 000 IOPS na 2ms marku a 50 000 na hraničních zařízeních.
| Scénář | Latence vstupně-výstupních operací s latencí 2 min. | Rychlost vstupně-výstupních operací při hraničních zařízeních výkonu (~7 ms) | Latence MiB/s při 2 min. | Hraniční zařízení Výkon 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.
Interní testování z roku 2020 také prozkoumalo limity jednoho koncového bodu. Limity byly dosaženy se šesti svazky. Velký objem snižuje výkon scénáře se šesti běžnými svazky o 260 %.
| Scénář | Latence vstupně-výstupních operací s latencí 2 min. | Rychlost vstupně-výstupních operací při hraničních zařízeních výkonu (~7 min) | Latence MiB/s při 2 min. | Hraniční zařízení Výkon 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í jeden obor názvů nebo přípojný bod místo správy více svazků kvůli snadnému použití a správě 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á:
| Typ front-endu EDA OP | Procento z celkového součtu |
|---|---|
| State | 39% |
| Access | 15 % |
| Random_write | 15 % |
| Write_file | 10 % |
| Random_read | 8 % |
| Read_file | 7% |
| Vytvoření | 2 % |
| Chmod | 1 % |
| Mkdir | 1 % |
| Ulink | 1 % |
| Ulink2 | 1 % |
|
0 % |
| Typ op back-endu EDA | Procento z celkového součtu |
|---|---|
| Čteno | 50 % |
| Write | 50 % |
|
0 % |
Testovací konfigurace
Výsledky byly vytvořeny pomocí následujících podrobností konfigurace:
| Komponenta | Konfigurace |
|---|---|
| Operační systém | RHEL 9.3 / RHEL 8.7 |
| Typ instance | D16s_v5 |
| Počet instancí | 10 |
| Možnosti připojení | nocto,actimeo=600,hard,rsize=262144,wsize=262144,vers=3,tcp,noatime,nconnect=8 |
| Ladění klientů | # Parametry sítě. V jednotce bajtů |
noctoMožnosti připojení a noatimeactimeo=600 spolupráce na zmírnění vlivu některých operací metadat pro EDA úlohy přes protokol NFSv3. Tyto možnosti připojení 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 nabízet dál, než by jinak. 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.