Uruchamianie modelu prognozowania pogody WRF z użyciem liczb płynnych. Slurm-GCP

1. Wprowadzenie

Ostatnia aktualizacja: 2021-05-05

Co utworzysz

W tym module dowiesz się, jak wdrożyć w Google Cloud autoskalujący klaster HPC z harmonogramem zadań Slurm. Użyjesz przykładowego wdrożenia Terraform, które wdraża ten klaster z zainstalowanym oprogramowaniem WRF® za pomocą Spack. Następnie użyjesz tej infrastruktury do uruchomienia testu porównawczego CONUS 2, 5 km lub testu porównawczego CONUS 12 km.

Czego się nauczysz

• Jak skonfigurować zasady Identity and Access Management (IAM) na potrzeby obsługi klastra HPC w Google Cloud Platform
• Jak wdrożyć natywny dla chmury klaster HPC z harmonogramem zadań Slurm
• Jak uruchamiać WRF® równolegle w Google Cloud za pomocą zadania wsadowego Slurm

Co będzie potrzebne

• konto Gmail z dołączonym kluczem SSH lub Google Workspace, Cloud Identity.
• Projekt Google Cloud Platform z włączonym rozliczeniem
• rola właściciela projektu w projekcie GCP,
• Odpowiedni limit Compute Engine (480 procesorów wirtualnych c2 i 500 GB dysku PD-Standard)

2. Konfiguracja

Włącz interfejsy Google Cloud API

Aby tworzyć zasoby Google Cloud i z nich korzystać, musisz włączyć interfejsy API.

gcloud services enable compute.googleapis.com 

Ustawianie uprawnień

W przypadku HPC wyraźnie rozróżnia się administratorów systemu i użytkowników systemu. Administratorzy systemu mają zwykle „dostęp do roota”, który umożliwia im zarządzanie zasobami obliczeniowymi i ich obsługę. Użytkownikami systemu są zazwyczaj badacze, naukowcy i inżynierowie aplikacji, którzy muszą korzystać z zasobów tylko do wykonywania zadań.

W Google Cloud interfejs OS Login API udostępnia informacje o użytkownikach POSIX z kont Google Workspace, Cloud Identity i Gmail. Usługa OS Login jest też zintegrowana z systemem zarządzania tożsamościami i dostępem (IAM) w GCP, aby określać, czy użytkownicy powinni mieć możliwość podnoszenia uprawnień w systemach Linux.

W tym samouczku zakładamy, że pełnisz rolę administratora systemu i administratora Compute Engine. Skonfigurujemy zasady uprawnień, aby przyznać Ci wystarczające uprawnienia do wykonywania tych zadań:

• Tworzenie i usuwanie instancji maszyn wirtualnych Google Compute Engine (GCE)
• Nawiązywanie połączenia z instancjami maszyn wirtualnych GCE przez SSH

Aby przyznać sobie role uprawnień wymagane do wykonania tego samouczka, w konsoli Google Cloud:

1. W menu Produkty i usługi kliknij Administracja > Uprawnienia.
2. U góry strony kliknij „+Dodaj”.
3. Wpisz konto Google Workspace, Cloud Identity lub Gmail w sekcji „Nowi członkowie”.
4. Dodaj te role : administrator Compute, OS Login w Compute i użytkownik konta usługi.
5. Kliknij Zapisz.

Opcja: jeśli interfejs konsoli nie jest zgodny z tym, co tu widzisz, te polecenia gcloud dadzą takie same wyniki. Zastąp YOUR_PROJECT i EMAIL_ADDRESS identyfikatorem projektu i adresem e-mail.

• 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"

Twój login ma teraz uprawnienia wymagane do rozpoczęcia tworzenia klastra HPC.

Aby sprawdzić, czy masz przypisane odpowiednie role, otwórz Cloud Shell i uruchom to polecenie, zastępując symbole YOUR_PROJECT i EMAIL_ADDRESS identyfikatorem projektu i adresem e-mail.

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

To polecenie wyświetli dane wyjściowe:

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

Ostrzeżenie: jeśli planujesz używać SSH innej firmy (np. OpenSSH) do łączenia się z klastrem, pamiętaj, aby dołączyć klucz SSH do profilu tożsamości w chmurze za pomocą OS Login. Więcej informacji o dodawaniu kluczy SSH do profilu tożsamości w chmurze

3. Niski limit: wdrażanie klastra HPC z autoskalowaniem za pomocą Terraform

W tej sekcji wdrożysz klaster HPC z autoskalowaniem, w tym harmonogram zadań Slurm. Jest to identyczne z opcją Wysoki limit, z tym że używany typ maszyny jest mniejszy, a liczba używanych procesorów wirtualnych jest mniejsza.

Ważne: domyślny limit procesorów C2 w przypadku nowego projektu to zwykle 24 procesory wirtualne. Jeśli masz większy limit i chcesz uruchomić test porównawczy CONUS o rozdzielczości 2,5 km, możesz pominąć tę i następną sekcję.

1. Otwórz Cloud Shell w GCP.
2. Klonowanie repozytorium FluidNumerics/slurm-gcp

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

3. Przejdź do katalogu WRF:

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

4. Utwórz i sprawdź plan Terraform. Ustaw zmienne środowiskowe WRF_NAME, WRF_PROJECT i WRF_ZONE, aby określić nazwę klastra, projekt GCP i strefę, w której chcesz wdrożyć klaster.

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

5. Przy pierwszym uruchomieniu narzędzia Terraform musisz wykonać to polecenie: init

terraform init

6. Utwórz plan za pomocą polecenia make, które uruchomi terraform

make plan

Uwaga: aby zwiększyć wydajność wejścia-wyjścia plików w NFS, zwiększ rozmiar dysku kontrolera do 2,5 TB i zmień typ dysku kontrolera na pd-ssd. Rozmiar dysku możesz zmienić, edytując plik basic.tfvars.tmpl i dodając controller_disk_size_gb = 2500. Zalecany jest też system plików Lustre.

Ostrzeżenie: wybierając strefę, upewnij się, że są w niej dostępne instancje C2. Więcej informacji o dostępnych regionach i strefach

Więcej informacji o ograniczeniach limitów w projekcie znajdziesz na stronie Limity w konsoli Google Cloud, na której są wymienione wszystkie limity. Wyszukaj „Limit Name: C2 CPUs”. Wyświetli to dostępne procesory C2 w wybranej strefie.

7. Wdróż klaster. Proces instalacji i konfiguracji może potrwać do 2 godzin. Podczas wdrażania zostanie zainstalowany interfejs WRF i wszystkie jego zależności.

make apply

8. Połącz się przez SSH z węzłem logowania utworzonym w poprzednim kroku. Ten węzeł możesz zobaczyć w poprzednim kroku (prawdopodobnie nazywa się wrf-small-login0). Aby to zrobić, kliknij przycisk SSH obok listy instancji maszyn wirtualnych w menu konsoli Compute Engine –> Instancja maszyny wirtualnej.

Opcja: ta para poleceń gcloud określi nazwę węzła logowania i połączy się z nim przez SSH:

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. Po połączeniu się z węzłem logowania sprawdź, czy moduł wrf jest dostępny, aby zweryfikować konfigurację klastra.

$ 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. Sprawdź, czy /apps/share/conus-12km zawiera wymienione poniżej elementy.

$  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

Uwaga: to wdrożenie korzysta z obrazu niestandardowego utworzonego na podstawie obrazu maszyny wirtualnej schedmd-slurm-public/schedmd-slurm-20-11-4-centos-7. WRF możesz utworzyć dla innych systemów operacyjnych, korzystając z repozytorium fluidnumerics/hpc-apps-gcp w GitHubie.

4. Uruchamianie testu porównawczego CONUS 12 km

Aby uruchomić test porównawczy CONUS 12 km, prześlij zadanie wsadowe Slurm. Dane wejściowe dla tego testu porównawczego są zawarte w obrazie maszyny wirtualnej wrf-gcp w ścieżce /apps/share/benchmarks/conus-12km.

W tej sekcji musisz mieć połączenie SSH z węzłem logowania klastra.

1. Skopiuj przykładowy plik wsadowy wrf-conus.sh z katalogu /apps/share.

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

2. Otwórz plik wrf-conus.sh w edytorze tekstu, aby sprawdzić, czy wartości --partition i --ntasks są prawidłowe. Liczba zadań powinna być równa liczbie rang MPI, których chcesz użyć do uruchomienia zadania. Na potrzeby tej demonstracji liczba zadań jest równa liczbie procesorów wirtualnych używanych w zadaniu i nie powinna przekraczać dostępnego limitu.

Uwaga: dostępne partycje w klastrze możesz wyświetlić za pomocą polecenia sinfo. Liczba zadań w tym przykładzie jest równa liczbie rang MPI.

#!/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. Prześlij zadanie wsadowe za pomocą polecenia sbatch.

sbatch wrf-conus12.sh

Uwaga: węzły obliczeniowe są tworzone w razie potrzeby podczas przesyłania zadań. W przypadku pierwszego przesłania zadania jego rozpoczęcie może potrwać do 3 minut.

4. Poczekaj na zakończenie zadania. Ten test porównawczy jest skonfigurowany tak, aby przeprowadzać 6-godzinną prognozę, która przy 24 rangach zajmuje około 3 godzin. Stan zadania możesz sprawdzać w squeue.
5. Po zakończeniu zadania sprawdź zawartość pliku rsl.out.0000, aby upewnić się, że zawiera on komunikat „wrf: SUCCESS COMPLETE WRF”. Sufiks numeryczny będzie inny, jeśli zadanie zostało uruchomione więcej niż raz, np. jeśli ustawienia konfiguracji były nieprawidłowe i trzeba było ponownie uruchomić zadanie.

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

5. Wysoki limit: wdrażanie klastra HPC z autoskalowaniem za pomocą Terraform

W tej sekcji wdrożysz w GCP klaster HPC z autoskalowaniem, w tym harmonogram zadań Slurm.

Ważne: domyślny limit procesorów C2 w przypadku nowego projektu to zwykle 24 procesory wirtualne. Nie wystarczy to do uruchomienia większego testu porównawczego CONUS 2,5 km. Jeśli masz duży limit do 480 wirtualnych procesorów, możesz wykonać tę część ćwiczenia.

1. Otwórz Cloud Shell w GCP.
2. Klonowanie repozytorium FluidNumerics/slurm-gcp

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

3. Przejdź do katalogu WRF:

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

4. Utwórz i sprawdź plan Terraform. Ustaw zmienne środowiskowe WRF_NAME, WRF_PROJECT, WRF_ZONE, WRF_MAX_NODE i WRF_MACHINE_TYPE, aby określić nazwę klastra, projekt GCP, strefę, w której chcesz wdrożyć klaster, maksymalną liczbę węzłów i typ maszyny. W przypadku testu porównawczego CONUS 2, 5 km zalecamy używanie instancji c2-standard-60 z co najmniej 8 węzłami dostępnymi do uruchamiania zadań z 480 rangami MPI.

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. Jeśli nie zostało to zrobione powyżej, musisz uruchomić Terraform, wpisując terraform init:

terraform init

6. Utwórz plan za pomocą polecenia make.

make plan

Uwaga: aby zwiększyć wydajność wejścia-wyjścia plików w NFS, zwiększ rozmiar dysku kontrolera do 2,5 TB i zmień typ dysku kontrolera na pd-ssd. Rozmiar dysku możesz zmienić, edytując plik basic.tfvars.tmpl i dodając controller_disk_size_gb = 2500. Zalecany jest też system plików Lustre.

Ostrzeżenie: wybierając strefę, upewnij się, że są w niej dostępne instancje C2. Więcej informacji o dostępnych regionach i strefach

Więcej informacji o ograniczeniach limitów w projekcie znajdziesz na stronie Limity w konsoli Google Cloud, na której są wymienione wszystkie limity. Wyszukaj „Limit Name: C2 CPUs”. Wyświetli to dostępne procesory C2 w wybranej strefie.

7. Wdróż klaster. Proces instalacji i konfiguracji może potrwać do 2 godzin. Podczas wdrażania zostanie zainstalowany interfejs WRF i wszystkie jego zależności.

make apply

8. Połącz się przez SSH z węzłem logowania utworzonym w poprzednim kroku. Ten węzeł możesz zobaczyć w poprzednim kroku (prawdopodobnie nazywa się wrf-large-login0). Aby to zrobić, kliknij przycisk SSH obok listy instancji maszyn wirtualnych w menu konsoli Compute Engine –> Instancja maszyny wirtualnej.

Opcja: ta para poleceń gcloud określi nazwę węzła logowania i połączy się z nim przez SSH:

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}

Drugie polecenie powinno spowodować połączenie z węzłem logowania Slurm.

9. Po połączeniu się z węzłem logowania sprawdź, czy moduł wrf jest dostępny, aby zweryfikować konfigurację klastra.

$ 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. Sprawdź, czy /apps/share/conus-2.5km zawiera wymienione poniżej elementy.

$ 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

Uwaga: to wdrożenie korzysta z obrazu niestandardowego utworzonego na podstawie obrazu maszyny wirtualnej schedmd-slurm-public/schedmd-slurm-20-11-4-centos-7. WRF możesz utworzyć dla innych systemów operacyjnych, korzystając z repozytorium fluidnumerics/hpc-apps-gcp w GitHubie.

6. Uruchamianie testu porównawczego CONUS 2,5 km

Aby uruchomić test porównawczy CONUS 2,5 km, prześlij zadanie wsadowe Slurm. Pliki wejściowe dla tego testu porównawczego są zawarte w obrazie maszyny wirtualnej wrf-gcp w katalogu /apps/share/benchmarks/conus-2.5km.

W tej sekcji musisz mieć połączenie SSH z węzłem logowania klastra.

6. Skopiuj przykładowy plik wsadowy wrf-conus.sh z katalogu /apps/share.

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

7. Otwórz plik wrf-conus.sh w edytorze tekstu, aby sprawdzić, czy wartości --partition i --ntasks są prawidłowe. Partycja powinna być ustawiona na c2-60. Liczba zadań powinna być równa liczbie rang MPI, których chcesz użyć do uruchomienia zadania. W tym przykładzie liczba zadań jest równa liczbie procesorów wirtualnych używanych w zadaniu i nie powinna przekraczać dostępnego limitu.

Uwaga: dostępne partycje w klastrze możesz wyświetlić za pomocą polecenia sinfo. Liczba zadań w tym przykładzie jest równa liczbie rang MPI.

#!/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. Prześlij zadanie wsadowe za pomocą polecenia sbatch.

sbatch wrf-conus2p5.sh

Uwaga: węzły obliczeniowe są tworzone w razie potrzeby podczas przesyłania zadań. W przypadku pierwszego przesłania zadania jego rozpoczęcie może potrwać do 3 minut.

9. Poczekaj na zakończenie zadania. Ten test porównawczy jest skonfigurowany tak, aby przeprowadzać 6-godzinną prognozę, która przy 480 rangach zajmuje około 1 godziny. Stan zadania możesz sprawdzać w squeue.
10. Po zakończeniu zadania sprawdź zawartość pliku rsl.out.0000, aby upewnić się, że zawiera on komunikat „wrf: SUCCESS COMPLETE WRF”. Sufiks numeryczny będzie inny, jeśli zadanie zostało uruchomione więcej niż raz, np. jeśli konfiguracja była nieprawidłowa i trzeba było uruchomić zadanie ponownie.

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

7. Gratulacje

W tym module udało Ci się utworzyć klaster HPC z autoskalowaniem, natywny dla chmury, i przeprowadzić w nim symulację WRF® w Google Cloud Platform.

Czyszczę dane

Aby uniknąć obciążenia konta Google Cloud Platform opłatami za zasoby użyte w tym ćwiczeniu:

Usuwanie projektu

Najprostszym sposobem na uniknięcie płatności jest usunięcie projektu utworzonego na potrzeby tego laboratorium.

Ostrzeżenie: usunięcie projektu spowoduje, że:

• Wszystkie dane projektu zostaną usunięte. Jeśli w tym samouczku używasz istniejącego projektu, po jego usunięciu usuniesz też wszystkie inne wykonane w nim zadania.
• Niestandardowe identyfikatory projektu zostaną utracone. Podczas tworzenia tego projektu możesz utworzyć niestandardowy identyfikator projektu, którego chcesz używać w przyszłości. Aby zachować adresy URL, które używają identyfikatora projektu, np. adres URL appspot.com, usuń wybrane zasoby w projekcie zamiast usuwać cały projekt.

Jeśli zamierzasz skorzystać z innych ćwiczeń z programowania i krótkich wprowadzeń, ponowne wykorzystanie tych samych projektów może pomóc Ci uniknąć przekroczenia Iimitów związanych z projektami.

1. W Cloud Console otwórz stronę Zarządzanie zasobami. Otwórz stronę Zarządzanie zasobami
2. Z listy projektów wybierz projekt do usunięcia, a potem kliknij Usuń .
3. W oknie wpisz identyfikator projektu i kliknij Wyłącz, aby usunąć projekt.

Usuwanie poszczególnych zasobów

1. Otwórz Cloud Shell i przejdź do katalogu z przykładem wrf.

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

2. Uruchom polecenie make destroy, aby usunąć wszystkie zasoby.

make destroy