Megosztás a következőn keresztül:

Az Azure NetApp Files for Electronic Design Automation (EDA) használatának előnyei

  • Cikk

Az innováció a félvezetőipar egyik fontos jellemzője. Az ilyen innovációk lehetővé tették Gordon Moore 1965-ös, Moore-törvényként ismert 1965-ös évét, hogy több mint ötven évig igaz legyen, nevezetesen, hogy a feldolgozási sebesség várhatóan évente körülbelül megduplázódik. Például a félvezetőipar innovációja segített a Moore törvényének továbbfejlesztésében azáltal, hogy a chipeket kisebb méretű tényezőkre halmozza, hogy a teljesítmény párhuzamosság révén egyszer elképzelhetetlen szintre skálázható legyen.

A félvezető (vagy Electronic Design Automation [EDA]) cégek leginkább a piacra kerülési idő (TTM) iránt érdeklődnek. A TTM-et gyakran a számítási feladatokhoz szükséges idő alapján állítják elő, például a chipek tervezésének ellenőrzése és az öntödei munkák elvégzése, például a szalagkiemelés. A TTM-aggodalmak az EDA licencelési költségeinek csökkentésében is segítenek: a kevesebb munkaidő több időt jelent a licencek számára. Ez azt mondta, minél több sávszélesség és kapacitás áll rendelkezésre a kiszolgálófarm számára, annál jobb.

Az Azure NetApp Files egy nagy teljesítményű, párhuzamos fájlrendszer-megoldással csökkenti az EDA-feladatokhoz szükséges időt: az Azure NetApp Files nagy köteteit. A legutóbbi EDA-teljesítménytesztek azt mutatják, hogy egyetlen nagy kötet 20-szor nagyobb teljesítményű, mint egy normál Azure NetApp Files-kötet esetében.

Az Azure NetApp Files nagyméretű kötetek funkciója ideális a legigényesebb iparág tárolási igényeihez, nevezetesen:

  • Nagy kapacitású egyetlen névtér: Minden kötet legfeljebb 500TiB használható kapacitást kínál egyetlen csatlakoztatási pont alatt.

  • Magas I/O-sebesség, alacsony késés: Az EDA-szimulációs teljesítményteszt használatával végzett tesztelés során egyetlen nagy mennyiség 650 000 tárterületen keresztüli IOPS-t biztosít, kevesebb mint 2 ezredmásodpercnyi alkalmazáskésés mellett. Egy tipikus EDA-számítási feladatban az IOPS egy keverékből vagy fájlból áll, amely létrehoz, olvas, ír és jelentős mennyiségű más metaadat-műveletet. Ezt az eredményt sok ügyfél nagyvállalati szintű teljesítményének tekintik. Ezt a teljesítménybeli javulást az teszi lehetővé, hogy a nagy kötetek képesek párhuzamossá tenni a bejövő írási műveleteket az Azure NetApp Files tárerőforrásaiban. Bár sok cég 2ms-et vagy jobb válaszidőt igényel, a chiptervező eszközök ennél nagyobb késést képesek elviselni anélkül, hogy ez hatással lenne az üzletre.

  • Másodpercenként 826 000 művelet: egyetlen nagy kötet teljesítményszéle – az alkalmazásréteg 7 m késéssel tetőzött a tesztjeinkben, ami azt mutatja, hogy több művelet lehetséges egyetlen nagy kötetben, enyhe késéssel.

Az EDA-teljesítményteszt használatával végzett tesztek azt találták, hogy egyetlen normál Azure NetApp Files-kötettel 40 000 IOPS-os számítási feladat érhető el a 2ms jelnél, és 50 000 a peremhálózaton. A normál és nagy kötetek egymás melletti áttekintéséhez tekintse meg az alábbi táblázatot és diagramot.

Eset I/O-sebesség 2 ms késéssel I/O sebesség a teljesítmény szélén (~7 ms) MiB/s 2 ms késéssel MiB/s teljesítményél (~7 ms)
Egy normál kötet 39,601 49,502 692 866
nagy kötet 652,260 826,379 10,030 12,610

Az alábbi diagram a teszteredményeket szemlélteti.

A nagy és a normál kötetek közötti késést és átviteli sebességet összehasonlító diagram.

A rendszeres kötettesztelés egyetlen végpontkorlátot is feltárt, a korlátokat hat kötettel érték el. A nagy kötet hat normál kötettel 260%-kal felülmúlja a forgatókönyvet. Az alábbi táblázat ezeket az eredményeket szemlélteti.

Eset I/O-sebesség 2 ms késéssel I/O-sebesség a teljesítményélen (~7 ms) MiB/s 2 ms késéssel MiB/s teljesítményél (~7 ms)
Hat normál kötet 255,613 317,000 4,577 5,688
Egy nagy kötet 652,260 826,379 10,030 12,610

Egyszerűség nagy méretekben

Nagy kötet esetén a teljesítmény nem a teljes történet. Az egyszerű teljesítmény a cél. Az ügyfelek inkább egyetlen névteret/csatlakoztatási pontot használnak, nem pedig több kötetet kezelnek a könnyű használat és az alkalmazáskezelés érdekében.

Tesztelési eszköz

A tesztben szereplő EDA-számítási feladat egy szabványos iparági teljesítményteszt-eszköz használatával jött létre. A félvezető chipek tervezéséhez használt EDA-alkalmazások keverékét szimulálja. Az EDA számítási feladatok eloszlása a következő:

Előtér OP-típust ábrázoló kördiagram.

EDA előtérbeli OP-típus Az összeg százalékos aránya
Állam 39%
Access 15%
Random_write 15%
Write_file 10%
Random_read 8%
Read_file %7
Létrehozás 2%
Chmod 1%
Mkdir 1%
Ulink 1%
Ulink2 1%
  • Hozzáfűzés
  • Egyéni2
  • Zárolás
  • Mmap_read
  • Mmap_write
  • Neg_stat
  • Read_modify_write
    • Rmdir
  • Ír
0%

Háttér OP-típuseloszlást ábrázoló kördiagram.

EDA háttérrendszer OP típusa Az összeg százalékos aránya
Olvasás 50%
Írás 50%
  • Egyéni2
  • Mmap_read
  • Random_read
  • Read_file
  • Read_modify_file
 0%

Konfiguráció tesztelése

Az eredmények az alábbi konfigurációs adatokkal lettek létrehozva:

Összetevő Konfiguráció
Operációs rendszer RHEL 9.3/RHEL 8.7
Példány típusa D16s_v5
Példányszám 10
Csatlakoztatási beállítások nocto,actimeo=600,hard,rsize=262144,wsize=262144,vers=3,tcp,noatime,nconnect=8
Ügyfélhalászati hibák # Hálózati paraméterek. Bájtok egységében
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

# Beállítások 4 KiB méretű adattömbben, bájtban
net.ipv4.tcp_mem = 4096 89600 4194304

# Egyéb hálózati beállítások és jelzők
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

# Különböző fájlrendszerek / pagecache beállítások
vm.dirty_expire_centisecs = 100
vm.dirty_writeback_centisecs = 100
vm.dirty_ratio = 20
vm.dirty_background_ratio = 5

# ONTAP hálózati exec tuning az ügyfélhez
sunrpc.tcp_max_slot_table_entries = 128
sunrpc.tcp_slot_table_entries = 128

Csatlakoztatási lehetőségek nocto, noatimeés actimeo=600 együttműködve enyhítheti az EDA-számítási feladatok egyes metaadat-műveleteinek hatását az NFSv3 protokollon keresztül. Ezek a csatlakoztatási lehetőségek csökkentik a metaadat-műveletek számát, és gyorsítótáraznak néhány metaadat-attribútumot az ügyfélen, így az EDA számítási feladatai tovább tolhatók, mint egyébként. Fontos figyelembe venni az egyes számítási feladatokra vonatkozó követelményeket, mivel ezek a csatlakoztatási lehetőségek nem általánosan alkalmazhatók. További információkért tekintse meg a Linux NFS csatlakoztatási beállításainak ajánlott eljárásait az Azure NetApp-fájlhoz.

Összegzés

Az EDA számítási feladatokhoz olyan fájltárolásra van szükség, amely képes kezelni a nagy fájlszámokat, a nagy kapacitást és a sok párhuzamos műveletet több ezer ügyfél-munkaállomáson. Az EDA számítási feladatainak olyan szinten kell teljesíteniük, amely csökkenti a teszteléshez és az ellenőrzéshez szükséges időt, hogy pénzt takarítson meg a licenceken, és felgyorsítsa a legújabb és legnagyobb lapkakészletek piacra kerüléséhez szükséges időt. Az Azure NetApp Files nagy kötetei képesek kezelni az EDA-számítási feladatok követelményeit, és a helyszíni üzemelő példányok teljesítményéhez hasonló teljesítménnyel bírnak.

Következő lépések