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

1. Wprowadzenie

Ostatnia aktualizacja: 5.05.2021

Co utworzysz

W ramach tego ćwiczenia w programie wdrożysz automatycznie skalowany klaster HPC (High Performance Computing) w Google Cloud przy użyciu algorytmu szeregowania zadań Slurm. Użyjesz przykładowego wdrożenia Terraform, które wdraża ten klaster z użyciem WRF® zainstalowanego za pomocą Spacka. Następnie za pomocą tej infrastruktury przeprowadzisz test porównawczy CONUS 2, 5 km lub test porównawczy CONUS 12 km.

Czego się nauczysz

• Jak skonfigurować zasady zarządzania tożsamościami i dostępem do obsługi klastra HPC w Google Cloud Platform
• Jak wdrożyć chmurowy klaster HPC z algorytmem szeregowania zadań Slurm
• Jak równolegle uruchamiać WRF® w Google Cloud przy użyciu zadania wsadowego Slurm

Co będzie potrzebne

• Konto Gmail z podłączonym kluczem SSH albo Google Workspace, Cloud Identity
• Projekt Google Cloud Platform z włączonymi płatnościami
• Rola właściciela projektu w projekcie GCP
• Wystarczający limit Compute Engine (480 procesorów wirtualnych c2 i 500 GB standardowego dysku PD)

2. Konfiguracja

Włącz interfejsy Google Cloud API

Aby można było tworzyć interfejsy API zasobów Google Cloud i z nich korzystać, muszą być one włączone.

gcloud services enable compute.googleapis.com 

Ustawianie uprawnień

W HPC występują wyraźne różnice między administratorami systemu a użytkownikami systemu. Administratorzy systemu zazwyczaj mają dostęp do roota co pozwala im zarządzać zasobami obliczeniowymi i je obsługiwać. Użytkownikami systemu są zwykle badacze, naukowcy i inżynierowie aplikacji, których zasoby potrzebują 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. Dodatkowo OS Login integruje się z systemem Identity and Access Management (IAM) GCP, aby określić, czy użytkownicy powinni mieć możliwość eskalacji uprawnień w systemach Linux.

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

• Tworzenie i usuwanie instancji maszyn wirtualnych Google Compute Engine (GCE)
• Łączenie się z maszynami wirtualnymi GCE przez SSH

Aby przypisać sobie role uprawnień niezbędne do ukończenia tego samouczka, w konsoli Google Cloud:

1. Otwórz kartę Administracja. Administracja > Uprawnienia w menu Produkty i usługi.
2. Kliknij „+Dodaj”. u góry strony.
3. W sekcji „Nowi użytkownicy” wpisz swoje konto Google Workspace, konto Cloud Identity lub Gmail.
4. Dodaj te role : Administrator Compute, Logowanie do systemu operacyjnego Compute i Użytkownik kont usługi
5. Kliknij Zapisz.

Opcja: jeśli interfejs konsoli nie jest zgodny z tym, co tu widać, podane niżej polecenia gcloud dają takie same wyniki, zastępując YOUR_PROJECT i EMAIL_ADDRESS Twoim projektem 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 następujące polecenie, zastępując YOUR_PROJECT i EMAIL_ADDRESS swoim projektem 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 zwróci dane wyjściowe:

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

Uwaga: jeśli planujesz łączyć się ze swoim klastrem przez SSH innej firmy (np. OpenSSH), musisz dołączyć klucz SSH do profilu Cloud Identity za pomocą OS Login. Więcej informacji o dodawaniu kluczy SSH do profilu Cloud Identity

3. Niski limit: wdróż autoskalowany klaster HPC za pomocą Terraform

W tej sekcji wdrożysz autoskalowany klaster HPC, w tym algorytm szeregowania zadań Slurm. Ta opcja działa tak samo jak opcja Wysoki limit z tą różnicą, że używany typ maszyny jest mniejszy i liczba używanych procesorów wirtualnych jest mniejsza.

Ważne: domyślny limit procesorów C2 w nowym projekcie to zwykle 24 procesory wirtualne. Jeśli masz większy limit i chcesz przeprowadzić test porównawczy CONUS 2,5 km, możesz pominąć tę i kolejną 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 przeprowadzić wdrożenie.

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

5. Przy pierwszym uruchomieniu Terraform musisz uruchomić polecenie init:

terraform init

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

make plan

Uwaga: aby uzyskać lepszą wydajność operacji wejścia-wyjścia plików w porównaniu z NFS, zwiększ rozmiar dysku kontrolera do 2,5 TB i zmień parametr level_disk_type na pd-ssd. Rozmiar dysku możesz zmienić, edytując plik Basic.tfvars.tmpl i dodając controller_disk_size_gb = 2500. Możesz też użyć systemu plików Lustre.

Uwaga: wybierając strefę, wybierz strefę, w której są dostępne instancje C2. Więcej informacji o dostępnych regionach i strefach

Aby uzyskać więcej informacji o limitach w projekcie, wszystkie limity znajdziesz na stronie Limity w konsoli Google Cloud. Wyszukaj „Nazwa limitu: procesory C2”. Zostaną wyświetlone dostępne procesory C2 w wybranej strefie.

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

make apply

8. Połącz się z węzłem logowania utworzonym w poprzednim kroku przez SSH. Zobaczysz ten węzeł w poprzednim kroku (prawdopodobnie nosi on nazwę wrf-small-login0). Możesz to zrobić, klikając przycisk SSH obok listy maszyn wirtualnych w pozycji menu konsoli Compute Engine -> maszynie wirtualnej.

Opcja: ta para poleceń gcloud określi nazwę węzła logowania i nazwę SSH, aby uzyskać do niego dostęp:

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ź konfigurację klastra w celu sprawdzenia, czy moduł wrf jest dostępny.

$ 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 poniższą zawartość.

$  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 używa niestandardowego obrazu utworzonego przy użyciu obrazu maszyny wirtualnej schedmd-slurm-public/schedmd-slurm-20-11-4-centos-7. WRF dla innych systemów operacyjnych możesz utworzyć w repozytorium fluidnumerics/hpc-apps-gcp w GitHubie.

4. Przeprowadź test porównawczy CONUS na 12 km

Aby przeprowadzić test porównawczy CONUS na 12 km, prześlij zadanie zbiorcze Slurm. Karty wejściowe dla tego testu porównawczego są zawarte w obrazie maszyny wirtualnej wrf-gcp w katalogu /apps/share/benchmarks/conus-12km.

Na potrzeby tej sekcji musisz połączyć się przez SSH z węzłem login klastra

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

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

2. Otwórz plik wrf-conus.sh w edytorze tekstu, aby sprawdzić, czy --partition i --ntasks są prawidłowo skonfigurowane. Liczba zadań powinna być ustawiona na liczbę poziomów MPI, których chcesz użyć do uruchomienia zadania. W tej demonstracji liczba zadań jest zgodna z liczbą procesorów wirtualnych używanych przez zadanie i nie powinna przekraczać dostępnego limitu.

Uwaga: możesz wyświetlić listę dostępnych partycji w klastrze za pomocą narzędzia sinfo. Liczba zadań w tej demonstracji jest równoważna z liczbą rankingów 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ą programu sbatch.

sbatch wrf-conus12.sh

Uwaga: węzły obliczeniowe są tworzone w razie potrzeby podczas przesyłania zadań. Uruchomienie tego pierwszego zadania może zająć do 3 minut.

4. Poczekaj na zakończenie zadania. W przypadku tych testów porównawczych testy porównawcze mają obejmować 6 godzin, a uzyskanie 24 rankingów zajmuje około 3 godzin. Stan zadania możesz monitorować za pomocą usługi squeue.
5. Po zakończeniu zadania sprawdź zawartość pliku rsl.out.0000, aby upewnić się, że wyświetla się wyrażenie „wrf: success COMPLETE WRF”. Sufiks numeryczny będzie inny, jeśli zadanie zostało uruchomione więcej niż raz, np. jeśli ustawienie konfiguracji było nieprawidłowe i trzeba je było uruchomić ponownie.

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

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

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

Ważne: domyślny limit procesorów C2 w nowym projekcie to zwykle 24 procesory wirtualne. Nie wystarczą do przeprowadzenia testu porównawczego CONUS obejmującego 2,5 km. Jeśli masz duży limit dla 480 procesorów wirtualnych, możesz uruchomić tę część ćwiczenia w Codelabs.

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 przeprowadzić wdrożenie, maksymalną liczbę węzłów i typ maszyny. W przypadku testu porównawczego CONUS na poziomie 2, 5 km zalecamy użycie instancji c2-standard-60 z co najmniej 8 dostępnymi węzłami uruchamianymi zadaniami o poziomach MPI o wartości 480 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 wykonane powyżej, musisz uruchomić terraform init, aby uruchomić Terraform:

terraform init

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

make plan

Uwaga: aby uzyskać lepszą wydajność operacji wejścia-wyjścia plików w porównaniu z NFS, zwiększ rozmiar dysku kontrolera do 2,5 TB i zmień parametr level_disk_type na pd-ssd. Rozmiar dysku możesz zmienić, edytując plik Basic.tfvars.tmpl i dodając controller_disk_size_gb = 2500. Możesz też użyć systemu plików Lustre.

Uwaga: wybierając strefę, wybierz strefę, w której są dostępne instancje C2. Więcej informacji o dostępnych regionach i strefach

Aby uzyskać więcej informacji o limitach w projekcie, wszystkie limity znajdziesz na stronie Limity w konsoli Google Cloud. Wyszukaj „Nazwa limitu: procesory C2”. Zostaną wyświetlone dostępne procesory C2 w wybranej strefie.

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

make apply

8. Połącz się z węzłem logowania utworzonym w poprzednim kroku przez SSH. Zobaczysz ten węzeł w poprzednim kroku (prawdopodobnie nosi on nazwę wrf-large-login0). Możesz to zrobić, klikając przycisk SSH obok listy maszyn wirtualnych w pozycji menu konsoli Compute Engine -> maszynie wirtualnej.

Opcja: ta para poleceń gcloud określi nazwę węzła logowania i nazwę SSH, aby uzyskać do niego dostęp:

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}

Po drugim poleceniu możesz połączyć się z węzłem logowania Slurm.

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

$ 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 poniższą zawartość.

$ 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 używa niestandardowego obrazu utworzonego przy użyciu obrazu maszyny wirtualnej schedmd-slurm-public/schedmd-slurm-20-11-4-centos-7. WRF dla innych systemów operacyjnych możesz utworzyć w repozytorium fluidnumerics/hpc-apps-gcp w GitHubie.

6. Przeprowadź test porównawczy CONUS 2,5 km

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

Na potrzeby tej sekcji musisz połączyć się przez SSH z węzłem login klastra

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

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

7. Otwórz plik wrf-conus.sh w edytorze tekstu, aby sprawdzić, czy --partition i --ntasks są prawidłowo skonfigurowane. Partycja powinna być ustawiona na wartość c2-60. Liczba zadań powinna być ustawiona na liczbę poziomów MPI, których chcesz użyć do uruchomienia zadania. W tej demonstracji liczba zadań jest zgodna z liczbą procesorów wirtualnych używanych przez zadanie i nie powinna przekraczać dostępnego limitu.

Uwaga: możesz wyświetlić listę dostępnych partycji w klastrze za pomocą narzędzia sinfo. Liczba zadań w tej demonstracji jest równoważna z liczbą rankingów 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ą programu sbatch.

sbatch wrf-conus2p5.sh

Uwaga: węzły obliczeniowe są tworzone w razie potrzeby podczas przesyłania zadań. Uruchomienie tego pierwszego zadania może zająć do 3 minut.

9. Poczekaj na zakończenie zadania. W przypadku tych testów porównawczych testy porównawcze mają obejmować 6 godzin, a uzyskanie 480 pozycji zajmuje około godziny. Stan zadania możesz monitorować za pomocą usługi squeue.
10. Po zakończeniu zadania sprawdź zawartość pliku rsl.out.0000, aby upewnić się, że wyświetla się wyrażenie „wrf: success COMPLETE WRF”. Sufiks numeryczny będzie inny, jeśli zadanie zostało uruchomione więcej niż raz, np. jeśli ustawienie konfiguracji było nieprawidłowe i trzeba je było uruchomić ponownie.

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

7. Gratulacje

W ramach tego ćwiczenia w programie udało Ci się utworzyć autoskalowany, chmurowy klaster HPC oraz przeprowadzić równoległą symulację WRF® w Google Cloud Platform.

Czyszczenie

Aby uniknąć obciążenia konta Google Cloud Platform opłatami za zasoby zużyte podczas tego ćwiczenia z programowania:

Usuwanie projektu

Najprostszym sposobem na uniknięcie płatności jest usunięcie projektu utworzonego na potrzeby ćwiczeń z programowania.

Uwaga: usunięcie projektu spowoduje, że:

• Wszystkie dane projektu zostaną usunięte. Jeśli w ramach ćwiczenia z programowania był używany istniejący projekt, usunięcie go spowoduje również usunięcie wszystkich innych zadań wykonanych w tym projekcie.
• Niestandardowe identyfikatory projektu zostaną utracone. Być może w trakcie tworzenia tego projektu został utworzony niestandardowy identyfikator projektu, którego chcesz używać w przyszłości. Aby zachować adresy URL, które używają identyfikatora projektu, na przykład adres URL appspot.com, usuń wybrane zasoby w projekcie, zamiast usuwać cały projekt.

Jeśli planujesz skorzystać z wielu ćwiczeń z programowania i krótkich wprowadzeń, ponowne wykorzystanie projektów może pomóc Ci uniknąć przekroczenia limitów projektów.

1. W konsoli Cloud otwórz stronę Zarządzanie zasobami. Otwórz stronę Zarządzanie zasobami
2. Na liście projektów wybierz projekt do usunięcia, a następnie kliknij Usuń .
3. W oknie wpisz identyfikator projektu i kliknij Wyłącz, aby usunąć projekt.

Usuń poszczególne zasoby

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

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

2. Uruchomić polecenie zniszcz, aby usunąć wszystkie zasoby.

make destroy