Das WRF-Wettervorhersage-Modell mit Fluid Numerics ausführen' Slurm-GCP

1. Einführung

Zuletzt aktualisiert:05.05.2021

Überblick

In diesem Codelab stellen Sie mit dem Slurm-Jobplaner einen automatisch skalierenden HPC-Cluster (High Performance Computing) in Google Cloud bereit. Sie verwenden eine Terraform-Beispielbereitstellung, bei der dieser Cluster mit WRF® über Spack bereitgestellt wird. Anschließend verwenden Sie diese Infrastruktur, um die Benchmark 2,5 km von CONUS oder die Benchmark 12 km von CONUS auszuführen.

Lerninhalte

• IAM-Richtlinien (Identity and Access Management) für den Betrieb eines HPC-Clusters auf der Google Cloud Platform konfigurieren
• Cloudnativen HPC-Cluster mit dem Slurm-Jobplaner bereitstellen
• WRF® mit einem Slurm-Batchjob parallel in Google Cloud ausführen

Voraussetzungen

• Gmail-Konto mit einem angehängten SSH-Schlüssel oder Google Workspace, Cloud Identity
• Google Cloud Platform-Projekt mit aktivierter Abrechnung
• Rolle „Projektinhaber“ in Ihrem GCP-Projekt
• Ausreichendes Compute Engine-Kontingent (480 c2-vCPUs und 500 GB PD-Standard Disk)

2. Konfiguration

Google Cloud APIs aktivieren

Zum Erstellen und Verwenden von Google Cloud-Ressourcen müssen APIs aktiviert sein.

gcloud services enable compute.googleapis.com 

IAM-Richtlinien festlegen

Im HPC gibt es klare Unterschiede zwischen Systemadministratoren und Systemnutzern. Systemadministratoren haben in der Regel „Root-Zugriff“ sodass sie Rechenressourcen verwalten und betreiben können. Systemnutzer sind in der Regel Forscher, Wissenschaftler und Anwendungsentwickler, die die Ressourcen nur zum Ausführen von Jobs benötigen.

In Google Cloud werden über die OS Login API POSIX-Nutzerinformationen aus Google Workspace-, Cloud Identity- und Gmail-Konten bereitgestellt. Darüber hinaus ist OS Login in das IAM-System (Identity and Access Management) der GCP eingebunden. So lässt sich feststellen, ob Nutzer Berechtigungen auf Linux-Systemen ausweiten dürfen.

In dieser Anleitung gehen wir davon aus, dass Sie die Rollen „Systemadministrator“ und „Compute Engine-Administrator“ haben. Wir konfigurieren IAM-Richtlinien, um Ihnen ausreichende Berechtigungen zum Ausführen der folgenden Aufgaben zu gewähren

• Google Compute Engine-VM-Instanzen (GCE) erstellen/löschen
• SSH-Verbindung zu GCE-VM-Instanzen herstellen

So weisen Sie sich in der Google Cloud Console die erforderlichen IAM-Rollen für diese Anleitung zu:

1. Zu IAM und Verwaltung > IAM im Menü „Produkte und Dienste“.
2. Klicken Sie auf „+ Hinzufügen“. oben auf der Seite.
3. Geben Sie unter „Neue Mitglieder“ Ihr Google Workspace-, Cloud Identity- oder Gmail-Konto ein.
4. Fügen Sie die folgenden Rollen hinzu : Compute Admin, Compute OS Login und Service Account User
5. Klicken Sie auf „Speichern“.

Option:Wenn die Benutzeroberfläche der Console nicht zu dem hier gezeigten passt, geben die folgenden gcloud-Befehle dieselben Ergebnisse zurück. Dabei werden YOUR_PROJECT und EMAIL_ADDRESS durch Ihr Projekt und Ihre E-Mail-Adresse ersetzt.

• gcloud projects add-iam-policy-binding YOUR_PROJECT –role roles/iam.serviceAccountUser –member="user:EMAIL_ADDRESS"
• gcloud projects add-iam-policy-binding YOUR_PROJECT –role roles/compute.osLogin –member="user:EMAIL_ADDRESS"
• gcloud projects add-iam-policy-binding YOUR_PROJECT –role roles/compute.admin –member="user:EMAIL_ADDRESS"

Ihre Anmeldung verfügt jetzt über die erforderlichen Berechtigungen, um die Erstellung des HPC-Clusters zu starten.

Um zu prüfen, ob Sie die richtigen Rollen zugewiesen haben, öffnen Sie Cloud Shell und führen Sie den folgenden Befehl aus. Ersetzen Sie dabei YOUR_PROJECT und EMAIL_ADDRESS durch Ihr Projekt und Ihre E-Mail-Adresse.

$ gcloud projects get-iam-policy YOUR_PROJECT --flatten="bindings[].members" --format='table(bindings.role)' --filter="bindings.members=user:EMAIL_ADDRESS"

Dieser Befehl liefert die folgende Ausgabe:

ROLE
roles/compute.osLogin
roles/iam.serviceAccountUser
roles/compute.admin

Achtung:Wenn Sie die SSH-Verbindung eines Drittanbieters (z.B. OpenSSH) verwenden möchten, um eine Verbindung zum Cluster herzustellen, müssen Sie mit OS Login einen SSH-Schlüssel an Ihr Cloud Identity-Profil anhängen. Weitere Informationen zum Hinzufügen von SSH-Schlüsseln zu Ihrem Cloud Identity-Profil

3. Niedriges Kontingent: Automatisch skalierenden HPC-Cluster mit Terraform bereitstellen

In diesem Abschnitt stellen Sie einen automatisch skalierenden HPC-Cluster einschließlich des Slurm-Jobplaners bereit. Dies ist identisch mit der Option "Hohes Kontingent", mit der Ausnahme, dass der verwendete Maschinentyp kleiner und die Anzahl der verwendeten vCPUs kleiner ist.

Wichtig: Das Standardkontingent für C2-CPUs für ein neues Projekt beträgt normalerweise 24 vCPUs. Wenn Sie ein größeres Kontingent haben und die CONUS-2,5 km-Benchmark ausführen möchten, können Sie diesen Abschnitt und den nächsten Abschnitt überspringen.

1. Öffnen Sie Cloud Shell auf der GCP.
2. Repository „FluidNumerics/slurm-gcp“ klonen

cd ~
git clone https://github.com/FluidNumerics/slurm-gcp.git

3. Wechseln Sie in das WRF-Verzeichnis:

cd  ~/slurm-gcp/tf/examples/wrf

4. Erstellen und überprüfen Sie einen Terraform-Plan. Legen Sie die Umgebungsvariablen WRF_NAME, WRF_PROJECT und WRF_ZONE fest, um den Namen Ihres Clusters, Ihr GCP-Projekt und die Zone für die Bereitstellung anzugeben.

export WRF_PROJECT=<PROJECT ID>
export WRF_ZONE=<ZONE>
export WRF_NAME="wrf-small"

5. Wenn Sie „terraform“ zum ersten Mal ausführen, müssen Sie den Befehl init ausführen:

terraform init

6. Erstellen Sie den Plan mit dem Befehl „make“, der terraform ausführt.

make plan

Hinweis:Erhöhen Sie die Größe des Controller-Laufwerks auf 2,5 TB und ändern Sie den „controller_disk_type“ zu „pd-ssd“, um eine bessere E/A-Leistung für Dateien über NFS zu erzielen. Sie können die Laufwerkgröße ändern, indem Sie „basic.tfvars.tmpl“ bearbeiten und controller_disk_size_gb = 2500 hinzufügen. Alternativ wird ein Lustre-Dateisystem empfohlen.

Achtung:Achten Sie bei der Auswahl einer Zone darauf, dass Sie eine Zone auswählen, in der C2-Instanzen verfügbar sind. Weitere Informationen zu verfügbaren Regionen und Zonen

Weitere Informationen zu den Kontingentbeschränkungen Ihres Projekts finden Sie in der Google Cloud Console auf der Seite Kontingente. Suchen Sie nach „Limit Name: C2 CPUs“. Dadurch werden die verfügbaren C2-CPUs in der ausgewählten Zone angezeigt.

7. Stellen Sie den Cluster bereit. Die Installation und Einrichtung kann bis zu zwei Stunden dauern. Während der Bereitstellung werden WRF und alle zugehörigen Abhängigkeiten installiert.

make apply

8. Stellen Sie eine SSH-Verbindung zum Knoten login her, der im vorherigen Schritt erstellt wurde. Sie können diesen Knoten im vorherigen Schritt sehen (wahrscheinlich wrf-small-login0 genannt). Klicken Sie dazu im Menüpunkt Compute Engine -> in der Konsole neben der Liste der VM-Instanzen auf die Schaltfläche "SSH". VM-Instanz

Option:Mit diesem gcloud-Befehl wird der Name des Anmeldeknotens ermittelt und eine SSH-Verbindung zu diesem hergestellt:

export CLUSTER_LOGIN_NODE=$(gcloud compute instances list --zones ${WRF_ZONE} --filter="name ~ .*login" --format="value(name)" | head -n1)

gcloud compute ssh ${CLUSTER_LOGIN_NODE} --zone ${WRF_ZONE}

9. Sobald Sie mit dem Anmeldeknoten verbunden sind, prüfen Sie zum Prüfen der Clustereinrichtung, ob das wrf-Modul verfügbar ist.

$ module load gcc && module load openmpi && module avail
-------------------------------------- /apps/spack/share/spack/lmod/linux-centos7-x86_64/openmpi/4.0.5-eagetxh/gcc/9.2.0 --------------------------------------
   hdf5/1.10.7    netcdf-c/4.7.4    netcdf-fortran/4.5.3    parallel-netcdf/1.12.1    wrf/4.2

------------------------------------------------- /apps/spack/share/spack/lmod/linux-centos7-x86_64/gcc/9.2.0 -------------------------------------------------
   hwloc/2.2.0      libiconv/1.16          libpng/1.6.37     nasm/2.15.05            openmpi/4.0.5 (L,D)    time/1.9              zlib/1.2.11
   jasper/2.0.16    libjpeg-turbo/2.0.4    libtirpc/1.2.6    ncurses/5.9.20130511    perl/5.16.3            util-macros/1.19.1
   krb5/1.15.1      libpciaccess/0.16      libxml2/2.9.10    numactl/2.0.14          tcsh/6.22.02           xz/5.2.2

--------------------------------------------------- /apps/spack/share/spack/lmod/linux-centos7-x86_64/Core ----------------------------------------------------
   gcc/9.2.0 (L)

---------------------------------------------------------------------- /apps/modulefiles ----------------------------------------------------------------------
   openmpi/v4.1.x

10. /apps/share/conus-12km muss den unten aufgeführten Inhalt haben.

$  ls -1 /apps/share/conus-12km/
FILE:2018-06-17_00
FILE:2018-06-17_03
FILE:2018-06-17_06
FILE:2018-06-17_09
FILE:2018-06-17_12
geo_em.d01.nc
geogrid.log
met_em.d01.2018-06-17_00:00:00.nc
met_em.d01.2018-06-17_03:00:00.nc
met_em.d01.2018-06-17_06:00:00.nc
met_em.d01.2018-06-17_09:00:00.nc
met_em.d01.2018-06-17_12:00:00.nc
metgrid.log
namelist.input
namelist.wps
ungrib.log
wrfbdy_d01
wrfinput_d01

Hinweis: Diese Bereitstellung verwendet ein benutzerdefiniertes Image, das mit dem VM-Image schedmd-slurm-public/schedmd-slurm-20-11-4-centos-7 erstellt wurde. Sie können WRF für andere Betriebssysteme mit dem Repository fluidnumerics/hpc-apps-gcp auf GitHub erstellen.

4. CONUS-12km-Benchmark durchführen

Senden Sie einen Slurm-Batchjob, um die CONUS-12 km-Benchmark auszuführen. Die Eingabepräsentationen für diese Benchmark sind im VM-Image „wrf-gcp“ unter /apps/share/Benchmarks/conus-12km enthalten.

Für diesen Abschnitt muss über SSH eine Verbindung zum Knoten login des Clusters hergestellt werden.

1. Kopiere das Beispiel für eine wrf-conus.sh-Batchdatei aus /apps/share

cp /apps/share/wrf-conus12.sh ~/

2. Öffnen Sie wrf-conus.sh in einem Texteditor, um zu prüfen, ob --partition und --ntasks richtig festgelegt sind. Die Anzahl der Aufgaben sollte auf die Anzahl der MPI-Rangs festgelegt sein, die Sie zum Starten des Jobs verwenden möchten. Bei dieser Demonstration entspricht die Anzahl der Aufgaben der Anzahl der vCPUs, die für den Job verwendet wurden und sollte Ihr verfügbares Kontingent nicht überschreiten.

Hinweis: Sie können die verfügbaren Partitionen in Ihrem Cluster mit sinfo auflisten. Die Anzahl der Aufgaben in dieser Demonstration entspricht der Anzahl der MPI-Rangs.

#!/bin/bash
#SBATCH --partition=wrf
#SBATCH --ntasks=24
#SBATCH --ntasks-per-node=8
#SBATCH --mem-per-cpu=2g
#SBATCH --cpus-per-task=1
#SBATCH --account=default
#
# /////////////////////////////////////////////// #

WORK_PATH=${HOME}/wrf-benchmark/
SRUN_FLAGS="-n $SLURM_NTASKS --cpu-bind=threads"

. /apps/share/spack.sh
module load gcc/9.2.0
module load openmpi
module load hdf5 netcdf-c netcdf-fortran wrf

mkdir -p ${WORK_PATH}
cd ${WORK_PATH}
ln -s ${INSTALL_ROOT}/share/conus-12km/* .
ln -s $(spack location -i wrf)/run/* .

srun $MPI_FLAGS ./wrf.exe

3. Senden Sie den Batchjob mit „sbatch“.

sbatch wrf-conus12.sh

Hinweis: Rechenknoten werden beim Senden von Jobs nach Bedarf erstellt. Bei dieser ersten Jobübermittlung kann es bis zu 3 Minuten dauern, bis der Job gestartet wird.

4. Warten Sie, bis der Job abgeschlossen ist. Diese Benchmark ist für eine 6-Stunden-Prognose konfiguriert, die mit 24 Rangs etwa 3 Stunden dauert. Sie können den Status Ihres Jobs mit squeue überwachen.
5. Prüfen Sie nach Abschluss des Jobs den Inhalt von rsl.out.0000, um sicherzustellen, dass die Anweisung „wrf: SUCCESS COMPLETE WRF“ angezeigt wird. Das numerische Suffix ist anders, wenn Sie den Job mehrmals ausgeführt haben, z.B. wenn eine Konfigurationseinstellung falsch war und Sie ihn noch einmal ausführen mussten.

$ tail -n1 ${HOME}/wrf-benchmark/rsl.out.0000
d01 2018-06-17_06:00:00 wrf: SUCCESS COMPLETE WRF

5. Hohes Kontingent: Automatisch skalierenden HPC-Cluster mit Terraform bereitstellen

In diesem Abschnitt stellen Sie einen automatisch skalierenden HPC-Cluster einschließlich des Slurm-Jobplaners in der GCP bereit.

Wichtig: Das Standardkontingent für C2-CPUs für ein neues Projekt beträgt normalerweise 24 vCPUs. Dies reicht nicht aus, um die größere CONUS-2,5 km-Benchmark auszuführen. Wenn Sie ein großes Kontingent für bis zu 480 vCPUs haben, können Sie diesen Teil des Codelabs ausführen.

1. Öffnen Sie Cloud Shell auf der GCP.
2. Repository „FluidNumerics/slurm-gcp“ klonen

cd ~
git clone https://github.com/FluidNumerics/slurm-gcp.git

3. Wechseln Sie in das WRF-Verzeichnis:

cd  ~/slurm-gcp/tf/examples/wrf

4. Erstellen und überprüfen Sie einen Terraform-Plan. Legen Sie die Umgebungsvariablen WRF_NAME, WRF_PROJECT, WRF_ZONE, WRF_MAX_NODE und WRF_MACHINE_TYPE fest, um den Namen Ihres Clusters, Ihr GCP-Projekt, die Zone für die Bereitstellung, die maximale Anzahl von Knoten und den Maschinentyp anzugeben. Für die CONUS-Benchmark 2, 5 km empfehlen wir die Verwendung von c2-standard-60-Instanzen mit mindestens 8 verfügbaren Knotenausführungsjobs mit 480 MPI-Rangs.

export WRF_PROJECT=<PROJECT ID>
export WRF_ZONE=<ZONE>
export WRF_NAME=wrf-large
export WRF_MAX_NODE=5
export WRF_MACHINE_TYPE="c2-standard-60"

5. Falls Sie dies oben nicht getan haben, müssen Sie terraform init ausführen, um Terraform zu starten:

terraform init

6. Erstellen Sie den Plan mit dem Befehl „make“.

make plan

Hinweis:Erhöhen Sie die Größe des Controller-Laufwerks auf 2,5 TB und ändern Sie den „controller_disk_type“ zu „pd-ssd“, um eine bessere E/A-Leistung für Dateien über NFS zu erzielen. Sie können die Laufwerkgröße ändern, indem Sie „basic.tfvars.tmpl“ bearbeiten und controller_disk_size_gb = 2500 hinzufügen. Alternativ wird ein Lustre-Dateisystem empfohlen.

Achtung:Achten Sie bei der Auswahl einer Zone darauf, dass Sie eine Zone auswählen, in der C2-Instanzen verfügbar sind. Weitere Informationen zu verfügbaren Regionen und Zonen

Weitere Informationen zu den Kontingentbeschränkungen Ihres Projekts finden Sie in der Google Cloud Console auf der Seite Kontingente. Suchen Sie nach „Limit Name: C2 CPUs“. Dadurch werden die verfügbaren C2-CPUs in der ausgewählten Zone angezeigt.

7. Stellen Sie den Cluster bereit. Die Installation und Einrichtung kann bis zu zwei Stunden dauern. Während der Bereitstellung werden WRF und alle zugehörigen Abhängigkeiten installiert.

make apply

8. Stellen Sie eine SSH-Verbindung zum Knoten login her, der im vorherigen Schritt erstellt wurde. Sie können diesen Knoten im vorherigen Schritt sehen (wahrscheinlich wrf-large-login0). Klicken Sie dazu im Menüpunkt Compute Engine -> in der Konsole neben der Liste der VM-Instanzen auf die Schaltfläche "SSH". VM-Instanz

Option:Mit diesem gcloud-Befehl wird der Name des Anmeldeknotens ermittelt und eine SSH-Verbindung zu diesem hergestellt:

export CLUSTER_LOGIN_NODE=$(gcloud compute instances list --zones ${WRF_ZONE} --filter="name ~ .*login" --format="value(name)" | head -n1)

gcloud compute ssh ${CLUSTER_LOGIN_NODE} --zone ${WRF_ZONE}

Der zweite Befehl sollte dazu führen, dass Sie mit dem Slurm-Anmeldeknoten verbunden sind.

9. Sobald Sie mit dem Anmeldeknoten verbunden sind, prüfen Sie zum Prüfen der Clustereinrichtung, ob das wrf-Modul verfügbar ist.

$ module load gcc && module load openmpi && module avail
-------------------------------------- /apps/spack/share/spack/lmod/linux-centos7-x86_64/openmpi/4.0.5-eagetxh/gcc/9.2.0 --------------------------------------
   hdf5/1.10.7    netcdf-c/4.7.4    netcdf-fortran/4.5.3    parallel-netcdf/1.12.1    wrf/4.2

------------------------------------------------- /apps/spack/share/spack/lmod/linux-centos7-x86_64/gcc/9.2.0 -------------------------------------------------
   hwloc/2.2.0      libiconv/1.16          libpng/1.6.37     nasm/2.15.05            openmpi/4.0.5 (L,D)    time/1.9              zlib/1.2.11
   jasper/2.0.16    libjpeg-turbo/2.0.4    libtirpc/1.2.6    ncurses/5.9.20130511    perl/5.16.3            util-macros/1.19.1
   krb5/1.15.1      libpciaccess/0.16      libxml2/2.9.10    numactl/2.0.14          tcsh/6.22.02           xz/5.2.2

--------------------------------------------------- /apps/spack/share/spack/lmod/linux-centos7-x86_64/Core ----------------------------------------------------
   gcc/9.2.0 (L)

---------------------------------------------------------------------- /apps/modulefiles ----------------------------------------------------------------------
   openmpi/v4.1.x

10. /apps/share/conus-2.5km muss den unten aufgeführten Inhalt haben.

$ ls -1 /apps/share/conus-2.5km
FILE:2018-06-17_00
FILE:2018-06-17_03
FILE:2018-06-17_06
FILE:2018-06-17_09
FILE:2018-06-17_12
geo_em.d01.nc
geogrid.log
gfs.0p25.2018061700.f000.grib2
gfs.0p25.2018061700.f003.grib2
gfs.0p25.2018061700.f006.grib2
gfs.0p25.2018061700.f009.grib2
gfs.0p25.2018061700.f012.grib2
met_em.d01.2018-06-17_00:00:00.nc
met_em.d01.2018-06-17_03:00:00.nc
met_em.d01.2018-06-17_06:00:00.nc
met_em.d01.2018-06-17_09:00:00.nc
met_em.d01.2018-06-17_12:00:00.nc
metgrid.log
namelist.input
namelist.wps
ungrib.log
wrfbdy_d01
wrfinput_d01

Hinweis: Diese Bereitstellung verwendet ein benutzerdefiniertes Image, das mit dem VM-Image schedmd-slurm-public/schedmd-slurm-20-11-4-centos-7 erstellt wurde. Sie können WRF für andere Betriebssysteme mit dem Repository fluidnumerics/hpc-apps-gcp auf GitHub erstellen.

6. CONUS-2,5 km-Benchmark ausführen

Senden Sie einen Slurm-Batchjob, um die CONUS-Benchmark 2,5 km auszuführen. Die Eingabepräsentationen für diese Benchmark sind im VM-Image wrf-gcp unter /apps/share/Benchmarks/conus-2.5km enthalten.

Für diesen Abschnitt muss über SSH eine Verbindung zum Knoten login des Clusters hergestellt werden.

6. Kopiere das Beispiel für eine wrf-conus.sh-Batchdatei aus /apps/share

cp /apps/share/wrf-conus2p5.sh ~/

7. Öffnen Sie wrf-conus.sh in einem Texteditor, um zu prüfen, ob --partition und --ntasks richtig festgelegt sind. Die Partition sollte auf c2-60 festgelegt sein. Die Anzahl der Aufgaben sollte auf die Anzahl der MPI-Rangs festgelegt sein, die Sie zum Starten des Jobs verwenden möchten. Bei dieser Demonstration entspricht die Anzahl der Aufgaben der Anzahl der vCPUs, die für den Job verwendet wurden und sollte Ihr verfügbares Kontingent nicht überschreiten.

Hinweis: Sie können die verfügbaren Partitionen in Ihrem Cluster mit sinfo auflisten. Die Anzahl der Aufgaben in dieser Demonstration entspricht der Anzahl der MPI-Rangs.

#!/bin/bash
#SBATCH --partition=c2-60
#SBATCH --ntasks=480
#SBATCH --ntasks-per-node=60
#SBATCH --mem-per-cpu=2g
#SBATCH --cpus-per-task=1
#SBATCH --account=default
#
# /////////////////////////////////////////////// #

WORK_PATH=${HOME}/wrf-benchmark/
SRUN_FLAGS="-n $SLURM_NTASKS --cpu-bind=threads"

. /apps/share/spack.sh
module load gcc/9.2.0
module load openmpi
module load hdf5 netcdf-c netcdf-fortran wrf

mkdir -p ${WORK_PATH}
cd ${WORK_PATH}
ln -s ${INSTALL_ROOT}/share/conus-2.5km/* .
ln -s $(spack location -i wrf)/run/* .

srun $MPI_FLAGS ./wrf.exe

8. Senden Sie den Batchjob mit „sbatch“.

sbatch wrf-conus2p5.sh

Hinweis: Rechenknoten werden beim Senden von Jobs nach Bedarf erstellt. Bei dieser ersten Jobübermittlung kann es bis zu 3 Minuten dauern, bis der Job gestartet wird.

9. Warten Sie, bis der Job abgeschlossen ist. Diese Benchmark ist für eine 6-Stunden-Prognose konfiguriert, die mit 480 Rangs etwa 1 Stunde dauert. Sie können den Status Ihres Jobs mit squeue überwachen.
10. Prüfen Sie nach Abschluss des Jobs den Inhalt von rsl.out.0000, um sicherzustellen, dass die Anweisung „wrf: SUCCESS COMPLETE WRF“ angezeigt wird. Das numerische Suffix ist anders, wenn Sie den Job mehrmals ausgeführt haben, z.B. wenn eine Konfigurationseinstellung falsch war und Sie ihn noch einmal ausführen mussten.

$ tail -n1 ${HOME}/wrf-benchmark/rsl.out.0000
d01 2018-06-17_06:00:00 wrf: SUCCESS COMPLETE WRF

7. Glückwunsch

In diesem Codelab haben Sie einen cloudnativen HPC-Cluster mit automatischer Skalierung erstellt und eine parallele WRF®-Simulation auf der Google Cloud Platform ausgeführt.

Bereinigen

So vermeiden Sie, dass Ihrem Google Cloud Platform-Konto die in diesem Codelab verwendeten Ressourcen in Rechnung gestellt werden:

Projekt löschen

Am einfachsten vermeiden Sie weitere Kosten, wenn Sie das Projekt löschen, das Sie für das Codelab erstellt haben.

Achtung: Das Löschen von Projekten hat folgende Auswirkungen:

• Alle Inhalte des Projekts werden gelöscht. Wenn Sie für dieses Codelab ein vorhandenes Projekt verwendet haben, werden beim Löschen auch alle anderen in dem Projekt erstellten Projekte gelöscht.
• Benutzerdefinierte Projekt-IDs gehen verloren. Beim Erstellen dieses Projekts haben Sie möglicherweise eine benutzerdefinierte Projekt-ID erstellt, die Sie weiterhin verwenden möchten. Damit die URLs, die die Projekt-ID verwenden, z. B. eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, anstatt das gesamte Projekt zu löschen.

Wenn Sie mehrere Codelabs und Kurzanleitungen ausprobieren möchten, können Sie die Überschreitung von Projektkontingenten verhindern, indem Sie Projekte wiederverwenden.

1. Wechseln Sie in der Cloud Console zur Seite Ressourcen verwalten. Zur Seite „Ressourcen verwalten“
2. Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen .
3. Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Beenden, um das Projekt zu löschen.

Einzelne Ressourcen löschen

1. Öffnen Sie Cloud Shell und rufen Sie das Wrf-Beispielverzeichnis auf.

cd  ~/slurm-gcp/tf/examples/wrf

2. Führen Sie „Make Deletion“ aus, um alle Ressourcen zu löschen.

make destroy