Um eine optimale End-to-End-Leistung einer Anwendung oder eines Workflows zu erreichen, muss bei vielen HPC-Workloads die richtige Technologie zum Hosten der Dateien bei der Verarbeitung gewählt werden bzw. der Netzwerk-Stack so konfiguriert werden, das er für MPI oder andere Kommunikationsprotokolle optimal funktioniert. In diesem Modul wird erläutert, welche Optionen AWS in diesen Bereichen anbietet, und was in puncto Preis und Leistung zu beachten ist, damit Sie für jede Workload die richtige Lösung wählen.
Behandelte Themen:
- Speicher auf AWS für HPC
- Netzwerkskalierbarkeit für HPC-Workloads
Überblick über Speicheroptionen auf AWS: AWS bietet viele Optionen zur Speicherung – von Hochleistungsobjektspeicher bis zu vielen Arten von Dateisystemen, die einer EC2-Instance zugeordnet werden können. Diese Speichertypen unterscheiden sich nicht nur durch die Leistung an sich, sondern auch durch weitere Faktoren wie Kosten und Skalierbarkeit. Die nachfolgende Tabelle liefert einige Anhaltspunkte, wie Sie jeweils den richtigen Speichertyp für Ihre verschiedenen HPC-Daten finden:
Gemeinsame Dateisysteme für HPC: Gemeinsamer Speicher lässt sich auf verschiedene Weise erreichen, z. B. mit einer einfachen NFS-Bereitstellung eines EBS-Volume, mit Intel Lustre aus EBS-Volumes und mit dem verwalteten AWS-Service EFS. Wie beim Instance-Typ ist es einfach, Speicheroptionen zu testen, um so den leistungsfähigsten Dateisystemtyp zu finden.
Instances zugeordneter Speicher: EBS-Volumes sind in verschiedenen Optionen verfügbar, von Volumes mit hohen IOPS über allgemeine Optionen bis zu Optionen für Festplatten. Viele HPC-Anwendungen laufen auf den erschwinglicheren EBS-Speichertypen für allgemeine Zwecke und Festplatten sehr gut. Wie bei der Instance-Auswahl lässt sich auch das EBS-Volume einfach testen, um sicherzustellen, dass die optimale Lösung gewählt wird.
Übungsspeicherkonfiguration: Bei der Standard-EnginFrame-Automatisierung werden folgende Speicherkonfigurationsoptionen verwendet:
- Die Integrationsskripte stellen ein EFS-Volume unter /efs auf den Master- und Rechenknoten bereit. Dieses Dateisystem enthält ein Verzeichnis für Anwendungen und ein Spooler-Verzeichnis, das standardmäßig ein separates Einreichungsverzeichnis für jede Ihrer Aufgaben umfasst.
- AWS ParallelCluster stellt auch ein EBS-gp2-Volume bereit, das dem Master zugeordnet ist und über NFS-Mount Rechenknoten als /shared bereitgestellt wird.
- Das Verzeichnis /home der Master-Instance wird den Rechenknoten ebenfalls per NFS-Mount bereitgestellt. Da es auf demselben Dateisystem des Betriebssystems installiert ist, sollte es nicht für persistenten Speicher verwendet werden.
Die Leistung der gemeinsamen Dateisysteme kann von Workload zu Workload stark variieren. Um zu ermitteln, welches für Ihre Zwecke am geeignetsten ist, sollten Sie denselben Fall sowohl auf /efs (das als Standardspeicherort in EnginFrame konfiguriert ist ) als auch auf /shared benchmarken.
Aktuelles AWS-Netzwerk: AWS unterstützt derzeit Enhanced Networking-Funktionen mithilfe von SR-IOV (Single Root I/O Virtualization). SR-IOV ist eine Methode der Gerätevirtualisierung, die im Vergleich zu herkömmlichen Implementierungen eine höhere E/A-Leistung und niedrigere CPU-Auslastung bietet. Für unterstützte Amazon EC2-Instances liefert diese Funktion eine höhere PPS-Leistung (Pakete pro Sekunde), niedrigere Latenzen zwischen Instances und sehr geringen Netzwerk-Jitter bereit. Bei Tests hat sie sowohl für High Throughput Computing (HTC), „offensichtlich parallele“ Anwendungen, „eng gekoppelte“ sowie MPI- und OpenMP-basierte HPC-Anwendungen gute Leistung unter Beweis gestellt.
Die Netzwerkgeschwindigkeit hängt von der Art und Größe der Instance ab. So stellt beispielsweise r4.16xlarge eine 20-Gigabit-Verbindung zwischen Instances bereit, wenn dieselbe Placement-Gruppe (eine logische Gruppierung von Instances) und Enhanced Networking verwendet werden.
Übungsnetzwerkkonfiguration: Standardmäßig erstellt die Übung eine neue Placement-Gruppe und erfordert, dass alle Rechenknoten des Clusters darin gestartet werden. Dadurch erhalten Sie eine sehr geringe Latenz und eine sehr hohe Bandbreite zwischen den Knoten, was besonders bei der Ausführung von MPI-Anwendungen relevant ist. Wenn Sie ein HTC-Problem haben, das sich horizontal auf Zehntausende Kerne oder mehr skaliert (was über den Umfang dieser Übung hinausgeht), sollten Sie in Betracht ziehen, sie in mehreren Placement-Gruppen auszuführen. Dadurch erhält EC2 mehr Flexibilität bei der Zuweisung dieser großen Zahl von Knoten. Sie können die Verwendung einer fixen Placement-Gruppe deaktivieren, indem Sie in der AWS ParallelCluster-Konfiguration den folgenden Parameter festlegen:
placement_group = NONE
Tipp: Wenn Sie Ihr Cluster auf eine sehr große Zahl von Knoten skalieren müssen oder sehr leistungsstarken Speicher benötigen, sollten Sie mit Ihrem Technical Account Manager oder einem HPC Solution Architect sprechen. Dieser kann Ihre Zielarchitektur prüfen, potenzielle Engpässe ermitteln und die geeignetsten Technologien für Ihre Ziele wählen.