Beispiel-Workflow: MPI-Jobs zur EO-Verarbeitung auf einem SLURM-Cluster in der CODE-DE-Lab Cloud ausführen
Bei der Verarbeitung von Satellitenbildern werden häufig dieselben Schritte für jedes Produkt wiederholt. Nutzen Sie Ihren SLURM-Cluster für diese wiederkehrenden Aufgaben: Reichen Sie einen Job ein, verarbeiten Sie unterschiedliche Produkte parallel auf den Workern und sammeln Sie die Ergebnisse in einem gemeinsam genutzten Verzeichnis. Sie führen diesen Workflow mit Sentinel-2-Daten aus und erzeugen GeoTIFF-Dateien zur Anzeige und weiteren Analyse.
Dieser Workflow verwendet zwei SLURM-Worker, um Sentinel-2-Level-1C-Produkte aus EODATA herunterzuladen und zu verarbeiten. MPI verteilt die Produkte auf die Worker. Jeder Worker führt ESA SNAP aus, um seine Produkte auf eine Auflösung von 20 Metern umzurechnen, die Bänder B2, B3 und B4 auszuwählen und GeoTIFF-Dateien in das gemeinsam genutzte Home-Verzeichnis zu schreiben.
Das Python-Skript verwendet mpi4py für die MPI-Kommunikation und boto3 für Downloads. Die SNAP-Verarbeitung erfolgt über das Kommandozeilenwerkzeug gpt.
Voraussetzungen
Nr. 1 Laufender, mit Terraform erstellter SLURM-Cluster
Erstellen Sie myslurmcluster anhand von Einen SLURM-Cluster mit Terraform erstellen und führen Sie die dort beschriebenen Prüfungen der Worker und des gemeinsam genutzten Speichers durch. Verwenden Sie die beiden standardmäßig vorgesehenen Worker mit dem Flavor eo2a.large. Jeder Worker hat 2 vCPUs und stellt 6 GiB RAM für SLURM-Jobs bereit. Auf dem Cluster sind Open MPI, mpi4py und boto3 sowie das Konto hpc unter Ubuntu 24.04 LTS bereits eingerichtet.
Bewahren Sie das lokale Verzeichnis slurm-terraform und die darin erzeugte Datei ssh_config auf. Die folgenden Befehle verwenden sie, um eine Verbindung zum Controller herzustellen und Dateien zu übertragen.
Nr. 2 EODATA-Endpunkt und Netzwerk
Den S3-Endpunkt für Ihre Cloud finden Sie in Wie man mit boto3 auf EODATA zugreift auf CODE-DE-Lab. Wenn Sie ein privates EODATA-Netzwerk verwenden, tragen Sie dessen UUID vor der Bereitstellung als eodata_network_id in die Terraform-Konfiguration des Clusters ein.
Der Terraform-Cluster erreicht öffentliche EODATA-Endpunkte über seinen Router. Für einen privaten Endpunkt verbindet Terraform das ausgewählte vorhandene EODATA-Netzwerk mit dem Controller und beiden Workern. Dieser Workflow verwendet den Bucket eodata und das Präfix Sentinel-2/MSI/L1C_N0500/2022/10/01/.
Nr. 3 SNAP-Installationsprogramm und Speicherplatz
Verwenden Sie das Linux-64-Bit-Installationsprogramm der Sentinel Toolboxes von der ESA-SNAP-Downloadseite. Die folgenden Befehle installieren SNAP 14.0.0 im gemeinsam genutzten Home-Verzeichnis. Stellen Sie dort mindestens 20 GiB freien Speicherplatz für die Installation, zwei Eingabeprodukte und deren Ausgabedateien bereit.
Schritt 1: Workflow auf den Controller kopieren
Beginnen Sie auf Ihrem lokalen Computer. Wenn Ihre Eingabeaufforderung nach Abschluss des Cluster-Artikels hpc@controller001:~$ lautet, beenden Sie die SSH-Sitzung:
exit
Wechseln Sie in Ihrem lokalen Terminal in das Verzeichnis slurm-terraform, das Sie im Cluster-Artikel verwendet haben. Dieses Verzeichnis enthält die erzeugte Datei ssh_config. Laden Sie eo-workflow-codede.zip in Ihrem Browser herunter und speichern Sie das Archiv in demselben Verzeichnis. Speichern Sie die Datei unter dem Namen eo-workflow.zip.
Prüfen Sie, ob beide Dateien lokal vorhanden sind:
ls ssh_config eo-workflow.zip
Der Befehl muss beide Dateinamen auflisten. Kopieren Sie das ZIP-Archiv aus diesem lokalen Verzeichnis auf den Controller und melden Sie sich an:
scp -F ./ssh_config eo-workflow.zip myslurmcluster:
ssh -F ./ssh_config myslurmcluster
Ihre Eingabeaufforderung lautet jetzt hpc@controller001:~$. Entpacken Sie das übertragene ZIP-Archiv und führen Sie die restlichen Einrichtungs- und Job-Befehle als hpc auf dem Controller aus:
unzip eo-workflow.zip
cd ~/eo-workflow
df -h /home/hpc
Das entpackte Verzeichnis ist über das gemeinsam eingebundene Verzeichnis /home auf jedem Worker verfügbar. Es enthält:
Datei |
Zweck |
|---|---|
|
Prüft, ob zwei MPI-Ranks auf zwei unterschiedlichen Workern laufen. |
|
Listet Produkte auf, verteilt Downloads und führt SNAP aus. |
|
Definiert die SNAP-Verarbeitungsschritte. |
|
Fordert die beiden Worker an und startet den MPI-Job. |
|
Enthält die Einstellungen für Endpunkt, Bucket und Produktauswahl. |
Schritt 2: SNAP im gemeinsam genutzten Home-Verzeichnis installieren
Laden Sie das Installationsprogramm herunter und installieren Sie SNAP als hpc:
mkdir -p ~/apps ~/installers
cd ~/installers
curl --fail --location --output esa-snap_sentinel_linux-14.0.0.sh \
https://download.esa.int/step/snap/14.0/installers/esa-snap_sentinel_linux-14.0.0.sh
bash esa-snap_sentinel_linux-14.0.0.sh -q -dir "$HOME/apps/esa-snap"
Setzen Sie den maximalen Java-Heap in gpt.vmoptions auf 4 GiB:
sed -i '/^-Xmx/d' ~/apps/esa-snap/bin/gpt.vmoptions
printf '\n-Xmx4G\n' >> ~/apps/esa-snap/bin/gpt.vmoptions
Prüfen Sie SNAP auf beiden Workern. Geben Sie dabei jedem Prozess ein eigenes beschreibbares Verzeichnis unter /tmp für Einstellungen, native Bibliotheken und temporäre Dateien:
srun --nodes=2 --ntasks=2 --ntasks-per-node=1 \
--cpus-per-task=2 --mem=6G --label bash -c '
snap_work=$(mktemp -d /tmp/snap-diag.XXXXXX) || exit 1
exec /home/hpc/apps/esa-snap/bin/gpt \
-J-Dsnap.userdir="$snap_work" \
-J-Djava.io.tmpdir="$snap_work" --diag
'
cd ~/eo-workflow
Jeder Worker muss SNAP 14.0.0 melden, ohne Fehler beim Entpacken nativer Bibliotheken. Die Optionen -J-D legen die Verzeichnispfade fest, bevor SNAP startet. Das Verarbeitungsskript erstellt ebenfalls ein separates temporäres Verzeichnis für jeden SNAP-Prozess. Die Installation und die Ausgabedateien verbleiben im gemeinsam genutzten Home-Verzeichnis.
Die Prüfung und der Batch-Job reservieren 2 CPUs und 6 GiB RAM pro Worker. SNAP verwendet einen Java-Heap von 4 GiB und darin einen Kachel-Cache von 512 MiB. Das Verarbeitungsskript leert den Kachel-Cache nach jeder ausgegebenen Kachelzeile.
Schritt 3: EODATA-Zugriff konfigurieren
Konfigurieren Sie auf controller001 das Konto hpc mit Ihren persönlichen EODATA-Schlüsseln aus Tenant Manager > Configuration > EODATA Access.
Erstellen Sie das Verzeichnis für die AWS-Zugangsdaten und öffnen Sie die Zugangsdaten-Datei:
mkdir -p ~/.aws
chmod 700 ~/.aws
touch ~/.aws/credentials
chmod 600 ~/.aws/credentials
nano ~/.aws/credentials
Fügen Sie mit Ihrem EODATA-Zugriffsschlüssel und geheimen Schlüssel ein Profil namens eodata hinzu. Behalten Sie vorhandene Profile bei:
[eodata]
aws_access_key_id = YOUR_EODATA_ACCESS_KEY
aws_secret_access_key = YOUR_EODATA_SECRET_KEY
Kopieren und bearbeiten Sie die Workflow-Einstellungen:
cp eodata.env.example eodata.env
nano eodata.env
Das CODE-DE-Lab-Archiv setzt EODATA_ENDPOINT bereits auf https://eodata.code-de.org und AWS_DEFAULT_REGION auf s3.fra1-3.cloudferro.com. Es verwendet das Profil eodata und zwei Sentinel-2-Level-1C-Produkte vom 1. Oktober 2022. Behalten Sie diese Werte beim Kopieren der Beispieldatei nach eodata.env bei.
# EODATA-Endpunkt und Profil mit Zugangsdaten aus Schritt 3.
export AWS_PROFILE=eodata
export AWS_DEFAULT_REGION=s3.fra1-3.cloudferro.com
export EODATA_ENDPOINT="https://eodata.code-de.org"
export EODATA_BUCKET=eodata
export EODATA_PREFIX=Sentinel-2/MSI/L1C_N0500/2022/10/01/
export MAX_PRODUCTS=2
# Das von Terraform erstellte private Subnetz für den MPI-Datenverkehr verwenden.
export OMPI_MCA_btl_tcp_if_include=192.168.50.0/24
export OMPI_MCA_oob_tcp_if_include=192.168.50.0/24
Die beiden Einstellungen OMPI_MCA halten den MPI-Daten- und Steuerverkehr im privaten Clusternetzwerk 192.168.50.0/24. Beide Werte müssen mit subnet_cidr in der Datei terraform.tfvars des Clusters übereinstimmen. EODATA-Downloads verwenden weiterhin den konfigurierten S3-Endpunkt.
Laden Sie die Einstellungen und prüfen Sie den EODATA-Zugriff von jedem Worker aus:
source eodata.env
printf 'EODATA endpoint: %s\n' "$EODATA_ENDPOINT"
srun --nodes=2 --ntasks=2 --ntasks-per-node=1 \
/usr/bin/python3 image_processing.py --list-only
Jeder Worker gibt seinen Hostnamen und die Anzahl der verfügbaren SAFE-Produkte aus, höchstens zwei. Die Zugangsdaten-Datei wird über /home/hpc mit den Workern geteilt.
Schritt 4: MPI zwischen den Workern prüfen
Laden Sie die Einstellungen und führen Sie die mitgelieferte MPI-Prüfung innerhalb einer SLURM-Ressourcenzuweisung aus:
source eodata.env
salloc --nodes=2 --ntasks=2 --ntasks-per-node=1 --time=00:05:00 \
mpirun -np 2 --map-by ppr:1:node /usr/bin/python3 mpi_hello.py
Die Ausgabe muss die Ranks 0 und 1 auf worker001 und worker002 enthalten, jeweils mit der Meldung MPI exchange passed. Diese Meldungen erscheinen, nachdem die Worker Daten ausgetauscht haben. Der Befehl muss beendet sein und die Eingabeaufforderung des Controllers wieder erscheinen, bevor Sie den Verarbeitungsjob einreichen.
Schritt 5: Verarbeitungsjob einreichen
Das Workflow-Archiv enthält bereits process.sbatch. Reichen Sie diese Datei mit sbatch bei SLURM ein; fügen Sie ihren Inhalt nicht in das Terminal ein. Die Datei fordert einen MPI-Rank pro Worker mit zwei CPUs und 6 GiB RAM pro Rank an. Ihr Inhalt ist hier zur Orientierung dargestellt:
#!/usr/bin/env bash
#SBATCH --job-name=sentinel2-mpi
#SBATCH --partition=compute
#SBATCH --nodes=2
#SBATCH --ntasks-per-node=1
#SBATCH --cpus-per-task=2
#SBATCH --mem=6G
#SBATCH --time=02:00:00
#SBATCH --output=slurm-%j.out
set -euo pipefail
cd "$SLURM_SUBMIT_DIR"
: "${EODATA_ENDPOINT:?Source eodata.env before submitting this job}"
export OMP_NUM_THREADS="$SLURM_CPUS_PER_TASK"
export OPENBLAS_NUM_THREADS=1
# Open MPI launches one rank per worker inside this SLURM allocation.
printf 'Checking MPI communication between workers...\n'
mpirun -np "$SLURM_NTASKS" --map-by "ppr:1:node:PE=$SLURM_CPUS_PER_TASK" \
/usr/bin/python3 mpi_hello.py
printf 'MPI check finished. Starting Sentinel-2 download and processing...\n'
mpirun -np "$SLURM_NTASKS" --map-by "ppr:1:node:PE=$SLURM_CPUS_PER_TASK" \
/usr/bin/python3 image_processing.py --workdir "$PWD/runs/$SLURM_JOB_ID"
Führen Sie diese Befehle auf controller001 als hpc aus, um den Job einzureichen. SLURM setzt SLURM_SUBMIT_DIR und die übrigen Job-Variablen beim Ausführen des Batch-Skripts:
cd /home/hpc/eo-workflow
source eodata.env
sbatch process.sbatch
squeue -u hpc
sbatch gibt eine Job-ID zurück. Ersetzen Sie unten JOB_ID durch diesen Wert, um das Protokoll zu verfolgen:
tail -F slurm-JOB_ID.out
Das Protokoll enthält Meldungen zur MPI-Prüfung, zur Produktauswahl, zum Download-Fortschritt und zum Start der SNAP-Verarbeitung. Jeder Worker gibt den Pfad zu seinem detaillierten SNAP-Protokoll unter runs/JOB_ID/logs aus. Der Job führt folgende Schritte aus:
Rank 0 listet bis zu zwei SAFE-Produkte auf und verteilt die Liste auf die beiden Ranks.
Jeder Rank lädt die ihm zugewiesenen Produkte mit boto3 herunter.
SNAP liest jedes Produkt, rechnet es auf eine Auflösung von 20 Metern um und behält die Bänder B2, B3 und B4 bei.
Jeder Rank schreibt die GeoTIFF-Ergebnisse nach
runs/JOB_ID/resultsim gemeinsam genutzten Workflow-Verzeichnis.
Bei zwei Eingabeprodukten verarbeitet jeder Worker ein Produkt. Die abschließende Protokollmeldung nennt die Anzahl der fertig verarbeiteten Produkte, beispielsweise Processed 2/2 products. Drücken Sie Ctrl+C, um das Verfolgen des Protokolls zu beenden. Der eingereichte Job läuft dabei weiter.
Schritt 6: Ergebnisse prüfen und herunterladen
Prüfen Sie nach der Abschlussmeldung die Ausgabedateien und die Verarbeitungsübersicht auf dem Controller:
ls -lh runs/JOB_ID/results/
cat runs/JOB_ID/summary.json
Für jedes erfolgreich verarbeitete Produkt gibt es eine GeoTIFF-Datei. Die Übersicht hält für jede Eingabe den Worker, den Ausgabepfad und den Erfolg oder Fehlschlag fest. Die SNAP-Protokolle der einzelnen Produkte liegen unter runs/JOB_ID/logs.
Kehren Sie zu Ihrem lokalen Terminal im Verzeichnis slurm-terraform zurück und laden Sie die Ergebnisse herunter:
exit
scp -F ./ssh_config -r \
myslurmcluster:/home/hpc/eo-workflow/runs/JOB_ID/results ./sentinel2-results
Öffnen Sie eine GeoTIFF-Datei in SNAP Desktop und erstellen Sie eine RGB-Ansicht mit B4 für Rot, B3 für Grün und B2 für Blau.
Hinweise zum Betrieb
Die Worker verarbeiten voneinander unabhängige Sentinel-2-Produkte. MPI verteilt die Aufgaben und sammelt die Ergebnisse. SNAP verwendet die jedem Rank zugewiesenen CPUs, um jeweils ein Produkt zu verarbeiten. Das gemeinsam genutzte Home-Verzeichnis enthält die heruntergeladenen Produkte und die Ergebnisse.
Wenn ein Download oder ein SNAP-Prozess fehlschlägt, schlägt der Batch-Job fehl und der Produktfehler wird in der Übersicht vermerkt. Prüfen Sie slurm-JOB_ID.out und die Protokolle der einzelnen Produkte, bevor Sie einen weiteren Job einreichen. Jeder eingereichte Job verwendet ein separates Verzeichnis, das nach seiner Job-ID benannt ist.
Nächste Schritte
Entfernen Sie den Cluster nach dem Herunterladen der Ergebnisse mit dem Bereinigungsverfahren aus Einen SLURM-Cluster mit Terraform erstellen.