Freigeben über

Speicher für HPC-Umgebungen im Energiesektor

  • Artikel

Herkömmliche Clouddateisysteme sind den Anforderungen, die umfangreiche HPC-Workloads in puncto Datenspeicherung und -zugriff haben, nicht gewachsen.

Im Folgenden sind die Faktoren aufgeführt, die Sie berücksichtigen und in Ihren Anwendungsanforderungen identifizieren müssen, um zu entscheiden, welche Speicherlösung verwendet werden soll.

  • Wartezeit,
  • IOPS,
  • Durchsatz,
  • Dateigrößen und -anzahl,
  • Ausführungszeit des Auftrags
  • Einhergehende Kosten
  • Affinität zum Speicherort: lokal oder in Azure

Weitere Informationen zu den Faktoren, die den in Azure ausgewählten HPC-Speicher beeinflussen, finden Sie unter „Grundlegendes zu Faktoren, die die Auswahl von HPC-Speicher in Azure beeinflussen“.

Entscheidungsstruktur zur Auswahl spezifischer HPC-Speichersysteme.

Diagramm mit einer Entscheidungsstruktur mit Überlegungen für die Auswahl einer Speicherlösung.

Überlegungen für den HPC-Entwurf

Öl- und Gasunternehmen müssen in der Lage sein, Exabytes seismischer Daten, Bohrlochdaten, Karten, Pachtverträge und mehr effektiv zu verwalten und zu speichern. Um diese Daten zu nutzen, benötigen sie eine Hochleistungsinfrastruktur, die Echtzeitanalysen verarbeiten und liefern kann, um die Produktion zu optimieren, Umweltrisiken zu reduzieren und die Betriebssicherheit zu erhöhen.

Die Anforderungen an Datenspeicher und -zugriff sind je nach Umfang der Workload sehr unterschiedlich. Azure unterstützt mehrere Ansätze zur Verwaltung der Geschwindigkeit und Kapazität von HPC-Anwendungen.

Herkömmliche Clouddateisysteme sind den Anforderungen, die umfangreiche Batch- und HPC-Workloads in der Energiebranche in puncto Datenspeicherung und -zugriff haben, nicht gewachsen. Die E/A-Hochleistungsanforderungen und die massiven Skalierbarkeitsbedürfnisse des High Performance Computing (HPC, Hochleistungscomputing) stellen einzigartige Herausforderungen für Datenspeicherung und Datenzugriff dar.

HPC wird verwendet, um komplexe Probleme wie die Simulation und Modellierung von Seismik und Reservoirs zu lösen, die mit herkömmlichen Computingmethoden nicht praktikabel oder kostengünstig zu bewältigen sind. Dies geschieht durch eine Kombination aus paralleler Verarbeitung und massiver Skalierbarkeit, um große und komplizierte Computingaufgaben schnell, effizient und zuverlässig auszuführen.

Darüber hinaus sind Computeknoten in Azure-HPC-Clustern virtuelle Computer, die bei Bedarf hochgefahren werden können, um alle Aufträge auszuführen, die dem Cluster zugewiesen wurden. Diese Knoten verteilen Berechnungsaufgaben über den Cluster, um die parallele Hochleistungsverarbeitung zu erzielen, die zur Lösung der komplexen Probleme erforderlich ist, auf die HPC angewendet wird. Computeknoten müssen Lese-/Schreibvorgänge im freigegebenen Arbeitsspeicher ausführen, während Aufträge ausgeführt werden. Die Art und Weise, wie Knoten auf diesen Speicher zugreifen, bewegt sich in einem Kontinuum zwischen diesen beiden Szenarien:

  • Ein Satz von Daten für viele Computeknoten: In diesem Szenario gibt es eine einzelne Datenquelle im Netzwerk, auf die alle Computeknoten für Arbeitsdaten zugreifen. Obwohl strukturell einfach, werden alle E/A-Vorgänge durch die E/A-Kapazität des Speicherstandorts eingeschränkt.
  • Viele Sätze von Daten für viele Computeknoten: In diesem Szenario gibt es eine einzelne Datenquelle im Netzwerk, auf die alle Computeknoten für Arbeitsdaten zugreifen. Obwohl strukturell einfach, werden alle E/A-Vorgänge durch die E/A-Kapazität des Speicherorts eingeschränkt.

Empfehlungen für den Entwurf von HPC

Wählen Sie die Lösung, die sich am besten für Ihre individuellen E/A- und Kapazitätsanforderungen eignet.

Network File System (NFS)

NFS wird häufig verwendet, um den Zugriff auf freigegebene Speicherorte zu ermöglichen. Bei NFS gibt eine Server-VM ihr lokales Dateisystem frei, das im Fall von Azure auf einer oder mehreren virtuellen Festplatten (VHD) gespeichert ist, die in Azure Storage gehostet werden. Clients können dann die freigegebenen Dateien des Servers einbinden und direkt auf den freigegebenen Speicherort zugreifen.

Das Netzwerkdateisystem (Network File System, NFS) wird häufig für Startverzeichnisse und Projektraum verwendet, die auf allen Knoten eingebunden werden. Es kann auch häufig einen Raum für Forschungsgruppen bieten, die Daten gemeinsam nutzen. Generell sind die Durchsatzworkloads horizontal skalierbar, wobei die Abhängigkeit zwischen einzelnen Aufgaben gering ist. Auftragsplaner verteilen die Arbeit knotenübergreifend und koordinieren die Aktivität. NFS ist der typische, knotenübergreifend freigegebene Speicher, auf den über TCP/IP-Netzwerke zugegriffen wird.

NFS hat den Vorteil, sich einfach einrichten und warten zu lassen, und wird sowohl unter Linux- als auch unter Windows-Betriebssystemen unterstützt. Mehrere NFS-Server können verwendet werden, um Speicher in einem Netzwerk zu verteilen, doch auf einzelne Dateien kann nur über einen einzelnen Server zugegriffen werden.

Erwägen Sie für Workloads mit geringem Umfang die Ausführung des NFS auf dem Hauptknoten, und verwenden Sie dabei in Abhängigkeit von Ihren Anforderungen eine datenspeicheroptimierte VM mit großen kurzlebigen Datenträgern oder VMs der D-Serie mit Azure Storage Premium. Diese Lösung eignet sich für Workloads mit höchstens 500 Kernen.

In HPC-Szenarien kann sich der Dateiserver häufig als Engpass herausstellen, der die Gesamtleistung drosselt. Versuche, auf nicht zwischengespeicherte Daten von einem einzelnen NFS-Server aus mit Raten zuzugreifen, die höher sind als die dokumentierten maximalen IOPS und Durchsätze pro VM, führen zu einer Drosselung.

In einem Szenario, in dem Dutzende von Clients versuchen, mit Daten zu arbeiten, die auf einem einzigen NFS-Server gespeichert sind, können diese Grenzwerte ganz leicht erreicht werden, wodurch die Leistung Ihrer gesamten Anwendung beeinträchtigt wird. Je näher die Verwendung Ihrer HPC-Anwendung einem reinen 1:n-Szenario kommt, desto früher werden Sie mit diesen Einschränkungen konfrontiert.

Parallele Dateisysteme in Azure

Parallele Dateisysteme verteilen den Speicher auf Blockebene auf mehrere vernetzte Speicherknoten. Die Dateidaten sind auf diese Knoten verteilt, was bedeutet, dass die Dateidaten auf mehrere Speichergeräte verteilt sind. Hierdurch werden alle individuellen Speicher-E/A-Anfragen über mehrere Speicherknoten gebündelt, die über einen gemeinsamen Namespace zugänglich sind.

Mehrere Speichergeräte und mehrere Pfade zu den Daten werden verwendet, um ein hohes Maß an Parallelität zu erreichen und Engpässe zu vermeiden, die durch den gleichzeitigen Zugriff auf nur einen einzigen Knoten entstehen. Parallele E/A-Vorgänge lassen sich jedoch möglicherweise schwierig koordinieren und optimieren, wenn direkt auf API-Ebene oder der Ebene der POSIX-E/A-Schnittstelle gearbeitet wird. Durch die Einführung von Datenzugriffs- und Koordinierungszwischenebenen bieten parallele Dateisysteme Anwendungsentwicklern eine allgemeine Schnittstelle zwischen der Anwendungsschicht und der E/A-Schicht.

MPI-Workloads im Energiesektor haben einzigartige Anforderungen mit der Notwendigkeit einer Kommunikation mit geringen Wartezeiten zwischen Knoten. Die Knoten sind über eine Hochgeschwindigkeitsverbindung verbunden und lassen sich nicht problemlos mit anderen Workloads teilen. MPI-Anwendungen nutzen die gesamten Hochleistungsverbindungen mithilfe des Passthrough-Modus in virtualisierten Umgebungen. Speicher für MPI-Knoten ist in der Regel ein paralleles Dateisystem wie Lustre, auf das auch über die Hochgeschwindigkeitsverbindung zugegriffen wird. Lustre/BeeGFS wird in der Regel verwendet, um die hohen Durchsatzanforderungen der hauptsächlich seismischen Verarbeitung (aber auch der Reservoirsimulation) zu bewältigen.

Parallele Dateisysteme wie Lustre werden für HPC-Workloads im Energiesektor verwendet, die Zugriff auf große Dateien, gleichzeitigen Zugriff von mehreren Computeknoten aus sowie riesige Datenmengen erfordern. Die Implementierung paralleler Dateisysteme vereinfacht die Skalierung in Bezug auf Funktionalität und Leistung. Solche Dateisysteme nutzen RDMA-Übertragungen mit großer Bandbreite und geringerer CPU-Auslastung. Das parallele Dateisystem wird in der Regel als temporärer Speicherbereich verwendet und ist für Arbeiten vorgesehen, die optimierte E/A-Vorgänge erfordern. Beispiele hierfür sind Workloadeinrichtung, Vorverarbeitung, Ausführung und Nachverarbeitung.

Wenn Sie einen orchestrierten parallelen Dateidienst wie Azure Managed Lustre verwenden, können Sie bis zu 50.000 Kerne mit Lese-/Schreibraten von bis zu 500 GiB/s und 2,5 PB Speicher verwenden.

Weitere Informationen zu parallelen virtuellen Dateisystemen in Azure finden Sie unter Parallele virtuelle Dateisysteme in Microsoft Azure – Teil 1: Übersicht – Microsoft Tech Community.

  • Azure NetApp Files und lokale Datenträger werden in der Regel verwendet, um die stärker wartezeit-/IOPS-sensiblen Workloads wie seismische Interpretation, Modellvorbereitung und Visualisierung zu verarbeiten. Erwägen Sie die Verwendung für Workloads mit bis zu 4.000 Kernen mit einem Durchsatz von bis zu 6,5 GiB/s sowie für Workloads, die von unserem geforderten NFS/SMB-Multiprotokollzugriff auf dasselbe Dataset profitieren.
  • Azure Managed Lustre bietet schnelleren und höheren Kapazitätsspeicher für HPC-Workloads. Diese Lösung funktioniert für mittlere bis sehr große Workloads und kann 50.000 oder mehr Kerne unterstützen, mit Durchsatz bis zu 500 GB/s und Speicherplatz bis zu 2,5 PiB.
  • Standard- oder Premium-Blob ist ein kostengünstiges Cloudangebot mit den niedrigsten Kosten. Dieser Service bietet Exabyte-Zugriff mit hohen Durchsatz, niedrigen Wartezeiten, wenn erforderlich, ein vertrautes Dateisystem sowie Multiprotokollzugriff (REST, HDFS, NFS). Sie können NFS v3.0 am Blobdienst-Endpunkt für Workloads mit hohem Durchsatz und leseintensive Workloads verwenden. Zum Optimieren der Kosten können Sie zu kühleren Zugriffsebenen wechseln, mit der Möglichkeit zur Durchführung der Lebenszyklusverwaltung mit Zeit der letzten Aktualisierung bzw. des letzten Zugriffs sowie intelligentem Tiering mit anpassbaren Richtlinien.
  • Die Workloads im Öl- und Gas-Energiesektor können auch einen Mechanismus für die Übertragung großer Daten und hoher Datenvolumen von lokalen Standorten in die Cloud und umgekehrt erfordern, der wie folgt erreicht werden kann:
    • Offline: gerätebasierte Migration (DataBox)
    • Online: Migration über das Netzwerk (ExpressRoute)

Nächste Schritte

In der folgenden Liste finden Sie Artikel mit Leitfäden zu bestimmten Aspekten in der Cloudeinführungsjourney, die Ihnen dabei helfen sollen, verschiedene Cloudeinführungsszenarien für HPC-Umgebungen im Energiesektor erfolgreich abzuschließen.