Auf dieser Seite wird beschrieben, wie Sie den Linux-NFS-Clientzugriff für EDA-Arbeitslasten (Electronic Design Automation) optimieren. Dieses Dokument richtet sich an Speicher administratoren, Cloud-Architekten und Systemingenieure, die für die Konfiguration von Linux-Compute-Knoten und die Verwaltung von leistungsstarken EDA-Umgebungen auf Google Cloudverantwortlich sind.
Best Practices für Clients
Linux-Knoten und interaktive VMs stellen NetApp Volumes über NFS bereit. Durch die Clientoptimierung werden die Durchsatzlimits für Volumes nicht erhöht, aber sie trägt dazu bei, Metadatenstürme, eine Überlastung von Slots an einem einzelnen Speicherendpunkt und ein schlechtes sequenzielles Leseverhalten bei großen Bibliotheken zu verhindern.
Konfigurieren Sie Clients in der folgenden Reihenfolge:
Kernel-Nebenläufigkeit (vor der Bereitstellung): Linux-NFS-Nebenläufigkeit
Fügen Sie für Cluster Toolkit- und Slurm-Compute-Images die Einstellungen für die Slot-Tabelle in die Compute-Image- oder Startskripts ein, bevor Sie die erste Bereitstellung vornehmen.
Bereitstellungsoptionen (bei der Bereitstellung): Linux-NFS-Bereitstellungsoptionen
Read-Ahead (nach der Bereitstellung, optional): Linux-NFS-Read-Ahead
Weitere Informationen zur NFS-Clientoptimierung finden Sie unter Linux-NFS-Clients für NetApp Volumes optimieren.
Informationen zu Bereitstellungsbefehlen und Exportrichtlinien finden Sie unter NFS-Clients verbinden. Informationen zum Verteilen von Clients auf große Volumes finden Sie unter Volumes mit großer Kapazität mit mehreren Speicherendpunkten verbinden und EDA-Architekturmuster.
EDA-Farmen mit vielen Clients optimieren
Verwenden Sie die folgenden Einstellungen für groß angelegte Bereitstellungen mit Hunderten oder Tausenden von Compute-Knoten, die dieselben Exporte verwenden. Diese Konfigurationen stimmen nicht mit Benchmark-Setups für einzelne VMs überein, bei denen in der Regel die Bereitstellungsoption nconnect=16 auf einem einzelnen Host verwendet wird.
| Gebiet | Empfohlener Startpunkt |
|---|---|
| Protokoll | NFSv3 (vers=3), es sei denn, Sie benötigen NFSv4.1-Funktionen |
| Nebenläufigkeit (NFSv3) | Niedrige RPC-Slot-Tabelle pro Client, z. B. 8 Einträge in /etc/modprobe.d/sunrpc.conf |
| Verbindungen | Eine TCP-Verbindung pro Client und Speicherendpunkt; verwenden Sie nicht nconnect |
| Volumen mit großer Kapazität | Über DNS oder statische Gruppen bereitstellen, um Knoten auf mehrere Speicherendpunkte zu verteilen |
| Übertragungsgröße | rsize=262144 und wsize=262144 festlegen |
| Zuverlässigkeit | hard, tcp, timeo=600 oder Google Cloud Standardeinstellungen der Console verwenden |
| Metadatenlast | noatime für Bibliotheken und Scratch verwenden, wenn die Anwendung dies zulässt |
| Sperren (NFSv3) | nolock verwenden, wenn Sie keine beratenden Sperren verwenden und Network Status Monitor (NSM) nicht konfiguriert ist |
| Read-Ahead | Nach der Bereitstellung für Bibliotheken mit hauptsächlich Lesezugriff erhöhen, wenn sequenzielle Lesevorgänge langsam sind |
Validieren Sie Ihre Einrichtung mit dem nfsiostat Befehl und den Messwerten, die
unter Leistung überwachen
beschrieben werden. Dieser Test stellt Ihre typische Produktions
arbeitslast dar.
Clients nach Datenebene optimieren
In der folgenden Tabelle sind die Schwerpunkte der Clients und die typischen Bereitstellungsoptionen nach Datenebene aufgeführt:
| Stufe | Clientfokus | Typische Optionen für die Bereitstellung |
|---|---|---|
| Bibliotheken | GETATTR- und Metadaten-Roundtrips reduzieren; sequenzielles Lesen großer Dateien |
vers=3, hard, tcp, noatime, rsize und wsize; actimeo=600 und nocto nur verwenden, wenn Daten hauptsächlich gelesen werden und die Regeln zur Kohärenz dies zulassen |
| Scratch | Viele Autoren; Kohärenz ist wichtig | vers=3, hard, tcp und noatime; kein aggressives Attribut-Caching verwenden; Slot-Anzahl pro Knoten niedrig halten |
| Tools | Hauptsächlich Lesezugriff, ähnlich wie bei den Bibliotheken | vers=3, hard, tcp, noatime, rsize=262144 und wsize=262144; actimeo=600 und nocto nur verwenden, wenn Daten hauptsächlich gelesen werden und die Regeln zur Kohärenz dies zulassen; stabile Bereitstellungsoptionen im gesamten Cluster-Image beibehalten |
| Startseite | Gemischte kleine E/A | Google Cloud Standardeinstellungen der Console reichen in der Regel aus; niedrige Slots verwenden, wenn die Startseite einen Endpunkt mit Scratch gemeinsam nutzt |
Verwenden Sie Kerberos (sec=krb5, krb5i oder krb5p) nur, wenn dies durch die Richtlinie erforderlich ist.
Kombinieren Sie Kerberos nicht mit nconnect. Weitere Informationen finden Sie unter
Linux-NFS-Bereitstellungsoptionen.
Nächste Schritte
- Benchmark-Ergebnisse finden Sie unter Benchmarks für EDA-Arbeitslasten.