Auf dieser Seite werden Architekturmuster für EDA-Arbeitslasten (Electronic Design Automation) in Google Cloud NetApp Volumes beschrieben.
NetApp Volumes bietet hochgradig skalierbaren gemeinsam genutzten NFS-Speicher zur Unterstützung von EDA-Arbeitslasten. Diese Arbeitslasten verarbeiten Datasets im Petabyte-Bereich mit Millionen kleiner Dateien, führen metadatenintensive Verzeichnisvorgänge aus und verursachen burstartige parallele E/A-Vorgänge auf Tausenden von Rechenkernen. NetApp Volumes sorgt dafür, dass Designbibliotheken, Toolchains und Scratch Daten zugänglich bleiben, indem es von Volumes in Projektgröße auf Volumes mit großer Kapazität skaliert wird . Optional ist FlexCache für Hybrid- und Fan-Out-Designs verfügbar. Die folgenden Muster ordnen gängige EDA-Bereitstellungsmodelle diesen Funktionen zu.
GitHub-Referenzimplementierungen wie eda-all-on-cloud und
eda-hybrid-cloud finden Sie unter Cluster Toolkit EDA examples.
Architekturmuster
In der folgenden Tabelle sind gängige Muster für EDA-Arbeitslasten zusammengefasst. Das beste Muster für Ihren Anwendungsfall hängt davon ab, wo sich Ihre primären Daten befinden und wie Sie die Leseleistung und die Rechenleistung skalieren möchten.
| Muster | Anwendungsfall | Wichtigste NetApp Volumes-Funktionen |
|---|---|---|
| Volumes mit großer Kapazität für Rechencluster | Designdaten und Toolchains befinden sich in Google Cloud und erfordern einen einzelnen gemeinsam genutzten Namespace im großen Maßstab | Pools und Volumes mit großer Kapazität, Layout mit mehreren Volumes und Lebenszyklus der Bereitstellungsgruppe |
| Burst in die Cloud | Primäre Datasets befinden sich lokal oder in einer anderen Region und Sie benötigen Cloud-Computing für Spitzenlasten | FlexCache aus dem lokalen ONTAP-Ursprung, Vorabfüllung und bereits vorhandene Volumes |
| Leistungsskalierung durch Fan-Out-Caches | Für leseintensive Phasen ist mehr aggregierter Durchsatz oder mehr Lokalität erforderlich, als ein einzelner Export bieten kann | Mehrere FlexCache-Volumes oder mehrere Speicherendpunkte pro großem Volume |
Volumes mit großer Kapazität als Dateispeicher für Rechencluster verwenden
Verwenden Sie dieses Muster, wenn sowohl die Rechenleistung als auch die nichtflüchtigen Daten in Google Cloudausgeführt werden, z. B. in neuen EDA-Farmen, migrierten Designzentren oder dedizierten Cloud-Burst Partitionen, die ihre eigenen Datasets besitzen.
Herausforderungen, die durch Volumes mit großer Kapazität gelöst werden
Volumes mit großer Kapazität erfüllen die hohen Anforderungen an Kapazität, Leistung und Parallelität von EDA-Arbeitslasten im großen Maßstab. Diese Konfiguration löst die folgenden Herausforderungen:
Kapazitätsbeschränkungen: Bietet Platz für große Arbeitsmengen wie Bibliotheken, IP-Blöcke und Scratch-Daten für die Regression.
Hohe Metadaten- und E/A-Last: Verarbeitet intensive Metadatenpfade (einschließlich
readdirundstatVorgängen), kleine zufällige E/A-Vorgänge und hohe sequenzielle Bandbreite.
Empfohlenes Layout
Anstatt alle Daten in einem einzigen großen Volume zu speichern, sollten Sie sie basierend auf ihrem Lebenszyklus und den Zugriffsmustern auf mehrere Volumes aufteilen.
In der folgenden Tabelle ist das empfohlene Layout für die Aufteilung Ihrer Daten beschrieben:
| Volumerolle | Gängige Datentypen | Zugriffsmuster und Lebenszyklus |
|---|---|---|
| Tools | Binärdateien von Anbietern und lizenzierte EDA-Installationen | Meist gelesen, lange Aufbewahrungsdauer und stabile Exporte |
| Bibliotheken | PDKs, Standardzellen und Referenzdesigns | Meist gelesen, große Anzahl von Dateien und Vorteile durch die Optimierung des Attribut-Caches auf Clients |
| Startseite | Punktdateien von Nutzern und kleiner Projektstatus | Gemischte Lese-/Schreibvorgänge und moderate Metadatenraten |
| Scratch | Ausführungsverzeichnisse und Zwischenergebnisse | Hohe Fluktuation, größte Kapazität und höchste IOPS-Anforderungen |
Der Cluster Toolkit-Blueprint eda-all-on-cloud stellt dieses Layout mit von Slurm verwalteten Compute Engine-Partitionen bereit, die NetApp Volumes über NFS bereitstellen.
Wann sollten Volumes mit großer Kapazität verwendet werden?
Erstellen Sie Volumes mit großer Kapazität für Volumes, die größer als 4,8 TiB (Flex Unified) oder 15 TiB (Premium und Extreme) sind.Erstellen Sie Volumes mit großer Kapazität. Diese Volumes lassen sich auf sehr große Kapazitäten skalieren und bieten höhere Durchsatz- und IOPS-Obergrenzen. Scratch- und Bibliotheks-Volumes, die die Grenzwerte für einzelne Endpunkte überschreiten, eignen sich für diese Konfiguration.
Clientverteilung auf großen Volumes
Ein Volume mit großer Kapazität stellt mehrere Speicherendpunkte (IP-Adressen) für denselben Export bereit. Verteilen Sie NFS-Clients auf mehrere Endpunkte, um den aggregierten Durchsatz zu skalieren und zu verhindern, dass eine einzelne IP-Adresse zum Engpass wird. Sie haben folgende Möglichkeiten:
Round-Robin-DNS (empfohlen im großen Maßstab): Erstellen Sie einen Cloud DNS-A-Eintrag mit mehreren IP-Adressen. Stellen Sie die Bereitstellung mit dem FQDN vor, damit jeder Client zur Bereitstellungszeit in eine Adresse aufgelöst wird. Stellen Sie die Bereitstellung neu vor, wenn Sie DNS-Einträge ändern.
Statische Fragmentierung: Teilen Sie Clients in mehrere Gruppen auf und stellen Sie die Bereitstellung für jede Gruppe an einem ausgewählten Endpunkt vor, um die Last deterministisch zu verteilen.
In einer reinen Cloud-Architektur stellen Sie separate
NetApp Volumes-Exporte in einer Google Cloud Region für Tools,
Bibliotheken und Scratch bereit. Tools und Bibliotheken enthalten meist gelesene Referenzdaten. Scratch enthält Ausführungsverzeichnisse und Checkpoints und ist oft ein Volume mit großer Kapazität. Von Slurm verwaltete Compute Engine-Knoten in derselben VPC stellen die Bereitstellung für jeden Export mit NFS vor. Der Speicher wird in einer base-Bereitstellungsgruppe und die Rechenleistung in einer cluster-Gruppe bereitgestellt, damit Sie den Cluster skalieren oder löschen können, ohne die Volumes zu löschen.
Burst in die Cloud
Verwenden Sie dieses Muster, wenn sich maßgebliche Designdaten lokal oder in einem Remote-ONTAP-System befinden und Sie Regression-, Charakterisierungs- oder Spitzenlast-Jobs auf Google Cloud ausführen möchten, ohne zuerst ganze Bibliotheken zu kopieren.
Herausforderungen bei der Speicherung in Hybrid-Clouds mit FlexCache lösen
FlexCache-Volumes lösen häufige Herausforderungen bei der Speicherung in Hybrid-Clouds für EDA-Umgebungen, indem sie die folgenden Vorteile bieten:
Zugriffsleistung wie im LAN: Die WAN-Latenz und -Bandbreite begrenzen, wie schnell Cloud-Rechenkerne lokale Datasets lesen können. FlexCache verarbeitet leseintensive Phasen und Metadatenvorgänge lokal, nachdem Arbeitsmengen im Cache gespeichert wurden, um dieses Problem zu beheben.
On-Demand-Caching auf Blockebene: Das Kopieren vollständiger Bibliotheken in die Cloud vor jedem Job führt zu Startverzögerungen und doppelter Speicherung. FlexCache speichert nur die aufgerufenen Datenblöcke im Cache, wodurch die Startzeiten minimiert und die Gesamtnutzung des Cloud-Speichers reduziert werden.
Einheitliche Quelle: Anstatt nicht verbundene Kopien Ihrer Daten zu verwalten, können Sie einen lokalen NFS-Export in der Cloud verwenden und trotzdem eine einzelne, konsistente Kopie auf dem lokalen Ursprungs-Volume beibehalten.
Verhalten und Merkmale von FlexCache
Sie erstellen ein FlexCache-Volume in NetApp Volumes, das auf ein vorhandenes ONTAP-Ursprungs-Volume verweist. Lesevorgänge von Daten im Cache werden vonverarbeitet Google Cloud. Bei kalten Lesevorgängen werden Blöcke einmal vom ONTAP-Ursprungs-Volume abgerufen und dann lokal bereitgestellt. Standardmäßig wird bei Schreib vorgängen ein Write-Around verwendet: Der Cache leitet Schreibvorgänge an den Ursprung weiter und macht die betroffenen Daten im Cache ungültig. So wird die Kohärenz zwischen den Caches gewahrt.
Im Folgenden sind die wichtigsten FlexCache-Merkmale für EDA-Umgebungen aufgeführt:
Caching auf Blockebene, nur Pull: Nur aufgerufene Daten belegen Cache kapazität. Sparse-Volumes sind effizient für große Bibliotheken, auf die pro Ausführung nur teilweise zugegriffen wird.
Kohärente, aktuelle Lesevorgänge: Die aus dem Cache oder Ursprung gelesenen Daten sind konsistent. Dieser Ansatz eignet sich für gemeinsam genutzte Referenzbibliotheken, wenn die Schreibmuster den FlexCache-Richtlinien entsprechen.
LAN-ähnliche Leselatenz nach dem Warm-up: Metadatenintensive und durchsatzintensive Lesevorgänge wie die Durchsuchung von Bibliotheken und wiederholte Referenzdateien profitieren, sobald Arbeitsmengen im Cache gespeichert wurden.
Vorabfüllung: Um eine Strafe für kalte Lesevorgänge beim ersten Zugriff zu vermeiden, füllen Sie Verzeichnisse für bekannte Ausführungslisten vorab, bevor Sie einen Job starten.
Hybrid-Referenz-Blueprint
eda-hybrid-cloud
stellt die Bereitstellung für bereits vorhandene Volumes wie Tools, Bibliotheken, Startseite und Scratch mit
pre-existing-network-storage vor. Volumes können Standard-NetApp Volumes-Exporte, Volumes mit großer Kapazität oder FlexCache-Volumes sein. Wenn Sie Speicher außerhalb des Cluster-Blueprints bereitstellen, wird ein versehentliches Löschen vermieden, wenn Sie die Rechenleistung herunterfahren. Außerdem werden FlexCache-Ursprünge unterstützt, die Sie in ONTAP verwalten.
Beachten Sie die folgenden Betriebsrichtlinien:
Dimensionieren Sie die Cache-Volumes für die Arbeitsmenge, nicht für die volle Kapazität des Ursprungs-Volumes.
Deaktivieren oder begrenzen Sie die Aktualisierungen der Zugriffszeit auf dem Ursprungs-Volume (
-atime-updatein ONTAP), um unnötige Cache-Invalidierungen zu vermeiden. Weitere Informationen finden Sie unter FlexCache – Übersicht.Aktivieren Sie die globale Dateisperrung nur, wenn Ihr Ablauf eine strenge semantische Ablehnung des Lesens zwischen Caches erfordert. Dieser Ansatz erhöht die Latenz und koppelt die Verfügbarkeit an den Ursprungslink.
Planen Sie die Netzwerkverbindung und -bandbreite zwischen dem Ursprung und Google Cloud. Schreibintensive Phasen sind weiterhin an den Ursprung oder den Netzwerk link gebunden, wenn Sie Write-Around verwenden.
In der Hybridarchitektur mit Leseburst befinden sich maßgebliche Tools und Bibliotheksdaten auf einem lokalen ONTAP-System. NetApp Volumes hostet FlexCache-Volumes in Google Cloud die über ein WAN oder einen privaten Link auf diese Ursprünge verweisen. Slurm-Knoten in Google Cloud stellen die Bereitstellung für die FlexCache-Exporte vor. Lesevorgänge werden aus dem Cache verarbeitet, wenn die Daten warm sind. Bei kalten Lesevorgängen werden Blöcke vom lokalen Ursprung abgerufen. Erstellen Sie für Scratch und Checkpoints, die viel Schreibtraffic von Cloud-Computing erhalten, ein separates Cloud-natives Scratch-Volume in derselben Region wie der Cluster, um Schreibvorgänge lokal zu halten, anstatt dauerhaften Schreibtraffic über einen FlexCache mit einem lokalen Ursprung weiterzuleiten.
Leistungsskalierung durch Fan-Out-Caches
Verwenden Sie dieses Muster, wenn ein einzelner Export, auch ein Volume mit großer Kapazität, nicht genügend aggregierten Lesedurchsatz oder Client-Fan-Out für eine Phase des Ablaufs bietet.
Sie können Fan-Out auf zwei Arten implementieren:
Fan-Out-FlexCache-Volumes
Erstellen Sie mehrere FlexCache-Volumes, die vom selben Ursprungs-Volume unterstützt werden, und stellen Sie die Bereitstellung für verschiedene Rechenpools (oder Jobtypen) auf verschiedenen Caches vor. Jeder Cache wird unabhängig aufgewärmt, skaliert die Lese-E/A-Vorgänge auf separate NetApp Volumes-Endpunkte und isoliert Thrashing zwischen Arbeitslasten, z. B. die Vorverarbeitung von Bibliotheken im Vergleich zur langen Regression.
In der folgenden Tabelle werden die Ansätze für die Bereitstellung mit einem und mehreren FlexCache-Volumes verglichen.
| Ansatz | Waagen | Kompromiss |
|---|---|---|
| Einzelner FlexCache | Einfachheit, ein Bereitstellungspfad | Eine Cachekapazität und eine Durchsatzobergrenze |
| Mehrere FlexCaches (Fan-Out) | Aggregierter Lesedurchsatz im Cache, Isolierung pro Pool | Mehr zu verwaltende Volumes, Arbeitsmenge auf mehrere Caches aufgeteilt |
| Nur Ursprung (kein Cache) | Stärkste Schreibkohärenz für einen einzelnen Standort | WAN-Latenz für Cloud-Computing |
Wenn Sie die Jobeingaben im Voraus kennen, verwenden Sie die Vorabfüllung für jeden Fan-Out-Cache.
Fan-Out auf Volumes mit großer Kapazität mit mehreren Endpunkten
Volumes mit großer Kapazität und FlexCache-Volumes im großen Maßstab stellen mehrere IP-Adressen pro Volume bereit. Behandeln Sie jede IP-Adresse als Speicherendpunkt mit einem eigenen Budget für Verbindungs-Slots.
Wenn Sie Hunderte oder Tausende von NFS-Clients haben, beachten Sie Folgendes:
Weniger RPC-Slot-Tabelleneinträge pro Client: Zum Beispiel 8 Slots pro Client unter NFSv3, damit die Gesamtzahl der ausstehenden Vorgänge pro Endpunkt innerhalb der empfohlenen Grenzwerte bleibt (ca. 10.000 Slots pro Endpunkt in der gesamten Farm). Weitere Informationen finden Sie unter Linux NFS concurrency.
Bereitstellungen auf mehrere Endpunkte verteilen: Verwenden Sie Cloud DNS-Round-Robin oder statische Fragmentierung.
Um FlexCache-Fan-Out zu implementieren, verwenden Sie ein Ursprungs-Volume (lokales ONTAP oder ein Cloud-ONTAP-Modus-Volume), um mehrere FlexCache-Volumes in NetApp Volumes zu unterstützen. Stellen Sie die Bereitstellung für jeden Cache mit verschiedenen Nutzern vor, z. B. einer Slurm-Partition oder einer Jobklasse, um Arbeitsmengen und Leselasten zwischen den Exporten zu isolieren.
Um Fan-Out mit mehreren Endpunkten zu implementieren, verwenden Sie ein Volume mit großer Kapazität, das denselben NFS-Export auf mehreren IP-Adressen bereitstellt. Verteilen Sie Clients auf diese Endpunkte, indem Sie jeder IP-Adresse feste Clientgruppen zuweisen oder einen DNS-Namen bereitstellen, der pro Bereitstellung in eine Adresse aufgelöst wird. Jeder Endpunkt hat ein eigenes Verbindungsbudget. Durch die Verteilung der Clients wird vermieden, dass die E/A-Vorgänge der gesamten Farm auf eine einzelne IP-Adresse konzentriert werden.
Muster kombinieren
Für EDA-Produktionsumgebungen können Sie diese Architekturmuster kombinieren, um die Leistung zu optimieren:
Reine Cloud-Architektur: Verwenden Sie Scratch-Volumes mit großer Kapazität sowie kleinere Standard Volumes für Tools und Startseite.
Hybrid: Verwenden Sie FlexCache für Bibliotheken und Tools mit einem in der Cloud bereitgestellten Scratch-Volume für die Jobausgabe.
Fan-Out: Verwenden Sie FlexCache pro Standort oder pro Scheduler-Warteschlange sowie DNS mit mehreren Endpunkten für ein Cloud-natives Scratch-Volume mit großer Kapazität.
Passen Sie die Dienstebene des Volumes und den Pooltyp (Flex Unified regulär im Vergleich zu großer Kapazität) an die Kapazitäts- und Leistungsanforderungen der einzelnen Ebenen an. Weitere Informationen finden Sie unter Dienstebenen.