Vorteile der Verwendung von Azure NetApp Files für Electronic Design Automation (EDA)
Innovation ist ein kennzeichnendes Merkmal für die Halbleiterindustrie. Dank dieser Innovation konnte Gordon Moores im Jahr 1965 formuliertes Gesetz, das als Mooresches Gesetz bekannt ist, eine Gültigkeit von mehr als fünfzig Jahre aufrechterhalten, nämlich dass man erwarten kann, dass sich die Verarbeitungsgeschwindigkeiten ungefähr jedes Jahr oder alle zwei Jahre verdoppeln. Beispielsweise hat die Innovation in der Halbleiterindustrie dazu beigetragen, das Mooresche Gesetz zu entwickeln, indem Chips in kleinere Formfaktoren gestapelt werden, um die Leistung durch Parallelität auf einst unvorstellbare Niveaus zu skalieren.
Halbleiterunternehmen (oder Electronic Design Automation [EDA]) interessieren sich am meisten für den Markt (TTM). TTM wird häufig auf die Zeit festgelegt, die es für Workloads benötigt, z. B. Chipdesign-Validierung und Vorgießereiarbeiten, wie etwa Tape-Out bis zum Abschluss. TTM-Bedenken helfen auch, EDA-Lizenzierungskosten niedrig zu halten: Weniger Zeit für die Arbeit bedeutet, dass mehr Zeit für die Lizenzen verfügbar ist. Das heißt, je mehr Bandbreite und Kapazität für die Serverfarm verfügbar sind, desto besser.
Azure NetApp Files hilft, die Zeit für EDA-Aufträge mit einer hochleistungsfähigen, parallelisierten Dateisystemlösung zu reduzieren: Große Azure NetApp Files-Volumes. Aktuelle EDA-Benchmark-Tests zeigen, dass ein einzelnes großes Volume 20-mal leistungsstärker ist als das, was bisher mit einem einzigen normalen Azure NetApp Files-Volume erreicht werden konnte.
Das Feature „Großes Azure NetApp Files-Volume“ eignet sich ideal für die Speicheranforderungen dieser anspruchsvollsten Branche, nämlich:
Einzelner Namespace für große Kapazität: Jedes Volume bietet bis zu 500 TiB verwendbare Kapazität unter einem einzelnen Bereitstellungspunkt.
Hohe E/A-Rate, niedrige Latenz: Bei Tests mit einer EDA-Simulations-Benchmark lieferte ein einzelnes großes Volume über 650K-Speicher-IOPS mit weniger als 2 Millisekunden Anwendungslatenz. In einer typischen EDA-Workload besteht IOPS aus einer Mischung oder Datei-Erstellungsvorgängen, -Lesevorgängen, -Schreibvorgängen und einer erheblichen Menge anderer Metadatenvorgänge. Dieses Ergebnis gilt als Leistung auf Unternehmensniveau für viele Kund*innen. Diese Leistungsverbesserung wird durch die Art und Weise ermöglicht, wie große Volumes eingehende Schreibvorgänge über Speicherressourcen hinweg in Azure NetApp Files parallelisieren können. Obwohl viele Unternehmen 2 ms oder eine bessere Reaktionszeit erfordern, können Chipdesigntools eine höhere Latenz als diese ohne Auswirkungen auf das Unternehmen tolerieren.
Bei 826.000 Vorgängen pro Sekunde: der Leistungsrand eines einzelnen großen Volumes – die Anwendungsschicht hat in unseren Tests bei 7 ms Latenz den Höchstwert erreicht, was zeigt, dass mehr Vorgänge in einem einzigen großen Volume mit geringen Latenzkosten möglich sind.
Tests, die mit einer EDA-Benchmark durchgeführt wurden, stellten fest, dass mit einem einzigen normalen Azure NetApp Files-Volume eine Workload von bis zu 40 000 IOPS bei der 2 ms-Marke und bis zu 50 000 am Edge erreicht werden konnte. Sehen Sie sich die Tabelle und das Diagramm unten an für eine Übersicht über das normale und große Volume im Vergleich zueinander.
| Szenario | E/A-Rate bei 2 ms Latenz | E/A-Rate am Leistungsrand (~7 ms) | MiB/s bei 2 ms Latenz | MiB/s Leistungsrand (~7 ms) |
|---|---|---|---|---|
| Ein normales Volume | 39.601 | 49.502 | 692 | 866 |
| Großes Volume | 652.260 | 826.379 | 10.030 | 12.610 |
Das folgende Diagramm veranschaulicht die Testergebnisse.
Bei Tests des normalen Volumes wurden auch Grenzwerte für einen einzelnen Endpunkt untersucht, die Grenzwerte wurden mit sechs Volumes erreicht. Großes Volume übertrifft das Szenario mit sechs normalen Volumes um 260 %. Die folgende Tabelle zeigt diese Ergebnisse.
| Szenario | E/A-Rate bei 2 ms Latenz | E/A-Rate am Leistungsrand (~7 ms) | MiB/s bei 2 ms Latenz | MiB/s Leistungsrand (~7 ms) |
|---|---|---|---|---|
| Sechs normale Volumes | 255.613 | 317.000 | 4.577 | 5.688 |
| Ein großes Volume | 652.260 | 826.379 | 10.030 | 12.610 |
Einfachheit im großen Stil
Bei einem großen Volume ist die Leistung nicht die gesamte Geschichte. Die Leistung ist einfach das Endziel. Kund*innen bevorzugen einen einzelnen Namespace/Bereitstellungspunkt im Gegensatz zum Verwalten mehrerer Volumes für eine einfache Verwendung und zur Anwendungsverwaltung.
Testtool
Die EDA-Workload in diesem Test wurde mit einem Standard-Branchen-Benchmark-Tool generiert. Es simuliert eine Mischung aus EDA-Anwendungen, die zum Entwerfen von Halbleiterchips verwendet werden. Die Verteilung der EDA-Workload lautet wie folgt:
| EDA-Front-End-OP-Typ | Prozentsatz des Gesamtwerts |
|---|---|
| Stat | 39 % |
| Access | 15 % |
| Random_write | 15 % |
| Write_file | 10 % |
| Random_read | 8 % |
| Read_file | %7 |
| Erstellen | 2 % |
| Chmod | %1 |
| mkdir | %1 |
| Ulink | %1 |
| Ulink2 | %1 |
|
0 % |
| EDA-Back-End-OP-Typ | Prozentsatz des Gesamtwerts |
|---|---|
| Lesen Sie | 50 % |
| Schreiben | 50 % |
|
0 % |
Testkonfiguration
Die Ergebnisse wurden mit den folgenden Konfigurationsdetails erstellt:
| Komponente | Konfiguration |
|---|---|
| Betriebssystem | RHEL 9.3/RHEL 8.7 |
| Instanztyp | D16s_v5 |
| Anzahl der Instanzen | 10 |
| Bereitstellungsoptionen | nocto,actimeo=600,hard,rsize=262144,wsize=262144,vers=3,tcp,noatime,nconnect=8 |
| Abstimmbare Client-Werte | # Netzwerk-Parameter. In Einheit von Bytes |
Die Bereitstellungsoptionen nocto, noatime und actimeo=600 arbeiten zusammen, um die Auswirkungen einiger Metadatenvorgänge für eine EDA-Workload über das NFSv3-Protokoll zu verringern. Diese Bereitstellungsoptionen reduzieren zum einen die Anzahl der Metadatenvorgänge, die ausgeführt werden, und speichern zum anderen einige Metadatenattribute auf dem Client zwischen, sodass EDA-Workloads weiter pushen können, als es sonst der Fall wäre. Es ist wichtig, einzelne Workloadanforderungen zu berücksichtigen, da diese Bereitstellungsoptionen nicht universell anwendbar sind. Weitere Informationen finden Sie unter Bereitstellungsoptionen für NFS unter Linux: bewährte Methoden für Azure NetApp File.
Zusammenfassung
EDA-Workloads erfordern Dateispeicher, die eine hohe Dateianzahl, eine große Kapazität und eine große Anzahl paralleler Vorgänge über potenziell Tausende von Clientarbeitsstationen hinweg verarbeiten können. EDA-Workloads müssen auch auf einer Ebene ausgeführt werden, die die Zeit zum Abschließen von Tests und Validierungen reduziert, um Geld für Lizenzen zu sparen und um die Markteinführung der neuesten und größten Chipsätze zu beschleunigen. Große Azure NetApp Files-Volumes können die Anforderungen einer EDA-Workload verarbeiten, was mit der Leistung vergleichbar ist, die bei lokalen Bereitstellungen zu sehen ist.