1. Przegląd
Witamy w ćwiczeniu Google dotyczącym uruchamiania klastra Slurm w Google Cloud Platform. Po ukończeniu tego ćwiczenia będziesz mieć solidną wiedzę na temat łatwości obsługi administracyjnej i działania klastra Slurm z autoskalowaniem.
Google Cloud nawiązał współpracę z SchedMD, aby udostępnić zestaw narzędzi, które ułatwiają uruchamianie menedżera zadań Slurm w Compute Engine i dynamiczne rozszerzanie istniejącego klastra, gdy potrzebujesz dodatkowych zasobów. Ta integracja została opracowana przez ekspertów z firmy SchedMD zgodnie ze sprawdzonymi metodami Slurm.
Jeśli planujesz korzystać z integracji Slurm w Google Cloud Platform lub masz pytania, dołącz do naszej grupy dyskusyjnej społeczności Google Cloud i Slurm.
Informacje o Slurm
Podstawowy schemat architektury samodzielnego klastra Slurm w Google Cloud Platform.
Slurm to jeden z najpopularniejszych na świecie menedżerów zbiorów zadań w klastrach HPC. Slurm to system open source do zarządzania zadaniami i planowania zadań, który jest odporny na awarie i wysoce skalowalny. Można go używać w małych i dużych klastrach Linux. Slurm nie wymaga modyfikacji jądra do działania i jest stosunkowo samodzielny. Jako menedżer zbiorów zadań klastra Slurm ma 3 kluczowe funkcje:
- Przyznaje użytkownikom wyłączny lub niewyłączny dostęp do zasobów (węzłów obliczeniowych) na określony czas, aby mogli wykonywać pracę.
- Zapewnia on strukturę do rozpoczynania, wykonywania i monitorowania pracy (zwykle zadania równoległego) na zbiorze przydzielonych węzłów.
- Rozstrzyga konflikty o zasoby, zarządzając kolejką oczekujących zadań.
Czego się nauczysz
- Jak skonfigurować klaster Slurm za pomocą Terraform
- Jak uruchomić zadanie za pomocą SLURM
- Jak wysyłać zapytania o informacje o klastrze i monitorować uruchomione zadania w SLURM
- Jak automatycznie skalować węzły, aby dostosować je do określonych parametrów i wymagań zadań
- Gdzie uzyskać pomoc dotyczącą Slurm
Wymagania wstępne
- Konto Google Cloud Platform i projekt z rozliczeniami
- Podstawowa znajomość Linuksa
2. Konfiguracja
Samodzielne konfigurowanie środowiska
Utwórz projekt
Jeśli nie masz jeszcze konta Google (Gmail lub G Suite), musisz je utworzyć. Zaloguj się w konsoli Google Cloud Platform ( console.cloud.google.com) i otwórz stronę Zarządzanie zasobami:
Kliknij Utwórz projekt.
Wpisz nazwę projektu. Zapamiętaj identyfikator projektu (na zrzucie ekranu powyżej jest on zaznaczony na czerwono). Identyfikator projektu musi być unikalną nazwą we wszystkich projektach Google Cloud. Jeśli nazwa projektu nie jest unikalna, Google Cloud wygeneruje losowy identyfikator projektu na podstawie nazwy projektu.
Następnie musisz włączyć płatności w Developers Console, aby korzystać z zasobów Google Cloud.
Wykonanie tego ćwiczenia w Codelabs nie powinno kosztować więcej niż kilka dolarów, ale może okazać się droższe, jeśli zdecydujesz się wykorzystać więcej zasobów lub pozostawisz je uruchomione (patrz sekcja „Podsumowanie” na końcu tego dokumentu). Kalkulator cen Google Cloud Platform jest dostępny tutaj.
Nowi użytkownicy Google Cloud Platform mogą skorzystać z bezpłatnego okresu próbnego, w którym mają do dyspozycji środki w wysokości 300 USD.
Google Cloud Shell
Z Google Cloud można korzystać zdalnie na laptopie, ale w tym ćwiczeniu użyjemy Google Cloud Shell, czyli środowiska wiersza poleceń działającego w chmurze.
Uruchamianie Google Cloud Shell
W konsoli GCP kliknij ikonę Cloud Shell na pasku narzędzi w prawym górnym rogu:
Następnie kliknij Uruchom Cloud Shell:
Udostępnienie środowiska i połączenie się z nim powinno zająć tylko kilka chwil:
Ta maszyna wirtualna zawiera wszystkie potrzebne narzędzia dla programistów. Zawiera również stały katalog domowy o pojemności 5 GB i działa w Google Cloud, co znacznie zwiększa wydajność sieci i upraszcza proces uwierzytelniania. Większość zadań w tym module, a być może wszystkie, możesz wykonać w przeglądarce internetowej lub na Chromebooku.
Po połączeniu z Cloud Shell zobaczysz, że uwierzytelnianie zostało już przeprowadzone, a projekt jest już ustawiony na Twój PROJECT_ID:
$ gcloud auth list
Wynik polecenia:
Credentialed accounts:
- <myaccount>@<mydomain>.com (active)
$ gcloud config list project
Wynik polecenia:
[core]
project = <PROJECT_ID>
Jeśli identyfikator projektu nie jest ustawiony prawidłowo, możesz go ustawić za pomocą tego polecenia:
$ gcloud config set project <PROJECT_ID>
Wynik polecenia:
Updated property [core/project].
3. Przygotowywanie i sprawdzanie konfiguracji Terraform dla Slurm
Pobieranie konfiguracji Terraform dla Slurm
W sesji Cloud Shell wykonaj to polecenie, aby sklonować (pobrać) repozytorium Git zawierające pliki Terraform dla Slurm na Google Cloud Platform:
git clone https://github.com/SchedMD/slurm-gcp.git
Przejdź do katalogu konfiguracji wdrożenia Slurm, wykonując to polecenie:
cd slurm-gcp
Konfigurowanie plików tfvars Terraform Slurm
Plik basic.tfvars.example zawiera szczegóły konfiguracji wdrożenia, w tym sieć, instancje i pamięć masową do wdrożenia. Skopiuj go do nowego pliku, który nazwiemy „plikiem tfvars”, a następnie w razie potrzeby go zmodyfikuj.
cd tf/example/basic cp basic.tfvars.example basic.tfvars
W sesji Cloud Shell otwórz plik tfvars basic.tfvars. Aby wyświetlić zawartość pliku, możesz użyć preferowanego edytora wiersza poleceń (vi, nano, emacs itp.) lub edytora kodu w konsoli Cloud:
Sprawdź zawartość pliku tfvars.
cluster_name = "g1"
project = "<project>"
zone = "us-west1-b"
# network_name = "<existing network name>"
# subnetwork_name = "<existing subnetwork name>"
# shared_vpc_host_project = "<vpc host project>"
# disable_controller_public_ips = true
# disable_login_public_ips = true
# disable_compute_public_ips = true
# suspend_time = 300
controller_machine_type = "n1-standard-2"
controller_image = "projects/schedmd-slurm-public/global/images/family/schedmd-slurm-20-11-4-hpc-centos-7"
controller_disk_type = "pd-standard"
controller_disk_size_gb = 50
# controller_labels = {
# key1 = "val1"
# key2 = "val2"
# }
# controller_service_account = "default"
# controller_scopes = ["https://www.googleapis.com/auth/cloud-platform"]
# cloudsql = {
# server_ip = "<cloudsql ip>"
# user = "slurm"
# password = "verysecure"
# db_name = "slurm_accounting"
# }
# controller_secondary_disk = false
# controller_secondary_disk_size = 100
# controller_secondary_disk_type = "pd-ssd"
#
# When specifying an instance template, specified controller fields will
# override the template properites.
# controller_instance_template = null
login_machine_type = "n1-standard-2"
login_image = "projects/schedmd-slurm-public/global/images/family/schedmd-slurm-20-11-4-hpc-centos-7"
login_disk_type = "pd-standard"
login_disk_size_gb = 20
# login_labels = {
# key1 = "val1"
# key2 = "val2"
# }
# login_node_count = 1
# login_node_service_account = "default"
# login_node_scopes = [
# "https://www.googleapis.com/auth/monitoring.write",
# "https://www.googleapis.com/auth/logging.write"
# ]
#
# When specifying an instance template, specified login fields will
# override the template properties.
# login_instance_template = null
# Optional network storage fields
# network_storage is mounted on all instances
# login_network_storage is mounted on controller and login instances
# network_storage = [{
# server_ip = "<storage host>"
# remote_mount = "/home"
# local_mount = "/home"
# fs_type = "nfs"
# mount_options = null
# }]
#
# login_network_storage = [{
# server_ip = "<storage host>"
# remote_mount = "/net_storage"
# local_mount = "/shared"
# fs_type = "nfs"
# mount_options = null
# }]
# compute_node_service_account = "default"
# compute_node_scopes = [
# "https://www.googleapis.com/auth/monitoring.write",
# "https://www.googleapis.com/auth/logging.write"
# ]
partitions = [
{ name = "debug"
machine_type = "n1-standard-2"
static_node_count = 0
max_node_count = 10
zone = "us-west1-b"
image ="projects/schedmd-slurm-public/global/images/family/schedmd-slurm-20-11-4-hpc-centos-7"
image_hyperthreads = false
compute_disk_type = "pd-standard"
compute_disk_size_gb = 20
compute_labels = {}
cpu_platform = null
gpu_count = 0
gpu_type = null
network_storage = []
preemptible_bursting = false
vpc_subnet = null
exclusive = false
enable_placement = false
regional_capacity = false
regional_policy = {}
instance_template = null
},
# { name = "partition2"
# machine_type = "n1-standard-16"
# static_node_count = 0
# max_node_count = 20
# zone = "us-west1-b"
# image = "projects/schedmd-slurm-public/global/images/family/schedmd-slurm-20-11-4-hpc-centos-7"
# image_hyperthreads = false
#
# compute_disk_type = "pd-ssd"
# compute_disk_size_gb = 20
# compute_labels = {
# key1 = "val1"
# key2 = "val2"
# }
# cpu_platform = "Intel Skylake"
# gpu_count = 8
# gpu_type = "nvidia-tesla-v100"
# network_storage = [{
# server_ip = "none"
# remote_mount = "<gcs bucket name>"
# local_mount = "/data"
# fs_type = "gcsfuse"
# mount_options = "file_mode=664,dir_mode=775,allow_other"
# }]
# preemptible_bursting = true
# vpc_subnet = null
# exclusive = false
# enable_placement = false
#
# ### NOTE ####
# # regional_capacity is under development. You may see slowness in
# # deleting lots of instances.
# #
# # With regional_capacity : True, the region can be specified in the zone.
# # Otherwise the region will be inferred from the zone.
# zone = "us-west1"
# regional_capacity = True
# # Optional
# regional_policy = {
# locations = {
# "zones/us-west1-a" = {
# preference = "DENY"
# }
# }
# }
#
# When specifying an instance template, specified compute fields will
# override the template properties.
# instance_template = "my-template"
]
W tym pliku tfvars jest kilka pól do skonfigurowania. Jedynym polem, które należy skonfigurować, jest project. Wszystkie pozostałe konfiguracje w przykładzie możesz wykorzystać w niezmienionej postaci, ale w razie potrzeby dostosuj je do swojej sytuacji. Szczegółowy opis opcji konfiguracji znajdziesz tutaj.
- cluster_name: nazwa klastra Slurm.
- project: identyfikator projektu Google Cloud, w którym zostaną wdrożone zasoby.
- zone: strefa Google Cloud, w której będą się znajdować instancje kontrolera i logowania tego klastra – więcej informacji.
- network_name: sieć prywatnego środowiska wirtualnego w chmurze, w której ma zostać wdrożony klaster Slurm.
- subnetwork_name: podsieć prywatnego środowiska wirtualnego w chmurze, w której ma zostać wdrożony klaster Slurm.
- shared_vpc_host_project: współdzielone środowisko VPC, w którym ma zostać wdrożony klaster Slurm.
- disable_controller_public_ips: czy przypisać zewnętrzny adres IP do kontrolera Slurm?
- disable_login_public_ips: czy przypisać zewnętrzny adres IP do węzła logowania Slurm?
- disable_compute_login_ips: Czy przypisać zewnętrzny adres IP do węzła logowania Slurm?
- suspend_time: czas oczekiwania po tym, jak węzeł stanie się bezczynny, zanim zostanie zawieszony.
- controller_machine_type: węzeł kontrolera typ instancji
- controller_image: obraz GCP używany do tworzenia instancji kontrolera Slurm
- controller_disk_type: typ dysku rozruchowego instancji kontrolera
- controller_disk_size_gb: rozmiar dysku rozruchowego instancji kontrolera.
- controller_labels: etykiety dołączenia do instancji kontrolera;
- controller_service_account: konto usługi, które ma być używane na instancji kontrolera.
- controller_scopes: zakres dostępu instancji kontrolera.
- cloudsql: serwer Google CloudSQL, który ma być używany jako baza danych Slurm zamiast hostowania bazy danych na instancji kontrolera.
- server_ip: adres IP serwera Cloud SQL
- user: nazwa użytkownika CloudSQL
- password: hasło CloudSQL
- db_name: nazwa bazy danych CloudSQL
- controller_secondary_disk: Czy dodać dodatkowy dysk do pamięci serwera NFS?
- controller_secondary_disk_type: typ dodatkowego dysku kontrolera
- controller_secondary_disk_size_gb: rozmiar dodatkowego dysku kontrolera.
- controller_instance_template: Szablon instancji GCP do użycia w przypadku instancji kontrolera. Wszystkie określone pola obliczeniowe zastąpią właściwości szablonu. Jeśli np. określono parametr controller_image, zastąpi on obraz w szablonie instancji.
- login_machine_type: węzeł logowania (dostępny przez SSH) typ instancji
- login_image: obraz GCP używany do tworzenia instancji logowania Slurm
- login_disk_type: typ dysku rozruchowego instancji logowania.
- login_disk_size_gb: rozmiar dysku rozruchowego instancji logowania.
- login_labels: etykiety dołączenia do instancji logowania;
- login_node_count: liczba węzłów logowania do utworzenia
- login_node_service_account: konto usługi, które ma być używane na instancjach logowania.
- login_node_scopes: zakres dostępu instancji logowania.
- login_instance_template: Szablon instancji GCP, który ma być używany w przypadku instancji logowania. Wszystkie określone pola obliczeniowe zastąpią właściwości szablonu. Jeśli np. określono login_image, zastąpi on obraz w szablonie instancji.
- network_storage: sieciowa pamięć masowa do zamontowania na wszystkich węzłach. Pola zostaną dodane bezpośrednio do pliku fstab. Można powtórzyć w przypadku dodatkowych punktów montażu.
- server_ip: adres IP serwera pamięci masowej
- remote_mount: nazwa podłączenia miejsca na dane (nazwa systemu plików);
- local_mount: lokalny katalog podłączenia.
- fs_type: typ systemu plików (NFS, CIFS, Lustre, GCSFuse zainstalowany automatycznie)
- mount_options: opcje montowania (np. defaults,_netdev);
- login_network_storage: pamięć sieciowa do zamontowania na węzłach logowania i kontrolera. NFS, CIFS, Lustre i GCSFuse zostaną zainstalowane automatycznie. Można powtórzyć w przypadku dodatkowych punktów montażu.
- server_ip: adres IP serwera pamięci masowej
- remote_mount: nazwa podłączenia miejsca na dane (nazwa systemu plików);
- local_mount: lokalny katalog podłączenia.
- fs_type: typ systemu plików (NFS, CIFS, Lustre, GCSFuse zainstalowany automatycznie)
- mount_options: opcje montowania (np. defaults,_netdev);
- compute_node_service_account: konto usługi, które ma być używane na instancjach obliczeniowych.
- compute_node_scopes: zakres dostępu instancji obliczeniowych.
- partitions: konfiguracja partycji Slurm. Można powtórzyć w przypadku dodatkowych partycji.
- name: nazwa partycji;
- machine_type: węzły obliczeniowe typ instancji
- static_node_count: liczba zawsze włączonych węzłów obliczeniowych.
- max_node_count: maksymalna łączna liczba dozwolonych węzłów obliczeniowych – maksymalnie 64 tys.
- zone: strefa Google Cloud, która będzie zawierać zasoby tej partycji – więcej informacji.
- image: typ maszyny węzła obrazu obliczeniowego
- image_hyperthreads: włączanie i wyłączanie hyperthreadingu na instancji.
- compute_disk_type: typ dysku rozruchowego instancji obliczeniowej (pd-standard, pd-ssd);
- compute_disk_size_gb: rozmiar dysku rozruchowego instancji obliczeniowej.
- compute_labels: etykiety dołączenia do instancji obliczeniowej;
- cpu_platform: minimalna platforma CPU wymagana dla wszystkich węzłów obliczeniowych
- gpu_count: liczba procesorów graficznych dołączenia do każdej instancji w partycji.
- gpu_type: typ procesora graficznego do podłączenia do instancji partycji.
- network_storage: pamięć sieciowa do zamontowania we wszystkich węzłach obliczeniowych w partycji. Pola zostaną dodane bezpośrednio do pliku fstab. Można powtórzyć w przypadku dodatkowych punktów montażu.
- server_ip: adres IP serwera pamięci masowej
- remote_mount: nazwa podłączenia miejsca na dane (nazwa systemu plików);
- local_mount: lokalny katalog podłączenia.
- fs_type: typ systemu plików (NFS, CIFS, Lustre, GCSFuse zainstalowany automatycznie)
- mount_options: opcja montowania
- preemptible_bursting: czy instancje będą instancjami z możliwością wywłaszczania?
- vpc_subnet: podsieć prywatnego środowiska wirtualnego w chmurze, w której ma zostać wdrożona partycja Slurm.
- exclusive: włącz Slurm, aby przydzielać całe węzły do zadań.
- enable_placement: włącz zasady rozmieszczenia, w których instancje będą znajdować się blisko siebie, co pozwoli zminimalizować opóźnienia sieciowe między nimi.
- regional_capacity::umożliwia umieszczenie instancji w dowolnej strefie w regionie na podstawie dostępności.
- regional_policy: jeśli regional_capacity ma wartość „prawda”, ta zasada określa, którego regionu używać i których stref w tym regionie nie używać.
- Instance_template: Szablon instancji GCP, który ma być używany w instancjach obliczeniowych. Wszystkie określone pola obliczeniowe zastąpią właściwości szablonu. Jeśli np. podasz obraz, zastąpi on obraz w szablonie instancji.
Konfiguracja zaawansowana
W ramach procesu wdrażania klastra możesz zainstalować dodatkowe pakiety i oprogramowanie. Oprogramowanie w klastrze Slurm możesz zainstalować na kilka sposobów opisanych w artykule „Instalowanie aplikacji w klastrze Slurm w Compute Engine” lub dostosowując obraz wdrożony przez Slurm. Obecnie Slurm wdraża obraz maszyny wirtualnej dostarczony przez SchedMD, który jest oparty na obrazie maszyny wirtualnej HPC w Google Cloud z zainstalowanym na nim systemem Slurm.
Aby użyć własnego obrazu, utwórz obraz z własną konfiguracją na podstawie publicznego obrazu maszyny wirtualnej SchedMD wymienionego w pliku tfvars. Następnie zastąp identyfikator URI obrazu określony w pliku tfvars własnym obrazem i przetestuj zmianę.
Rozwiązywanie problemów
W trakcie przechodzenia tego laboratorium zapoznaj się z sekcją Rozwiązywanie problemów w pliku ReadMe repozytorium Slurm-GCP.
Najczęstsze problemy to błędy w konfiguracji pliku tfvars i ograniczenia dotyczące limitów. Te ćwiczenia w Codelabs zostały zaprojektowane tak, aby można było je przeprowadzić w ramach standardowego limitu przydziału przydzielonego nowemu użytkownikowi oraz w ramach bezpłatnych środków w wysokości 300 USD, które otrzymuje nowy użytkownik. Jeśli próba utworzenia maszyn wirtualnych nie powiedzie się, sprawdź plik /var/log/slurm/resume.log na węźle kontrolera, aby wyszukać błędy interfejsu API.
4. Wdrażanie i weryfikowanie konfiguracji
Wdrażanie konfiguracji
W sesji Cloud Shell wykonaj to polecenie z folderu slurm-gcp/tf/example:
terraform init terraform apply -var-file=basic.tfvars
Zostanie wyświetlona prośba o zaakceptowanie opisanych działań na podstawie skonfigurowanych ustawień. Aby rozpocząć wdrażanie, wpisz „yes”. Możesz też wyświetlić konfigurację do wdrożenia, uruchamiając polecenie „terraform plan”.
Do you want to perform these actions? Terraform will perform the actions described above. Only 'yes' will be accepted to approve. Enter a value: yes
Wykonanie tej operacji może potrwać kilka minut, więc zachowaj cierpliwość.
Po zakończeniu wdrażania zobaczysz dane wyjściowe podobne do tych:
Apply complete! Resources: 8 added, 0 changed, 0 destroyed.
Outputs:
controller_network_ips = [
[
"10.0.0.2",
],
]
login_network_ips = [
[
"10.0.0.3",
],
]
Sprawdzanie tworzenia instancji maszyny wirtualnej
Otwórz menu nawigacyjne i wybierz Compute Engine > Instancje maszyn wirtualnych.
Powinny pojawić się kontroler i instancja maszyny wirtualnej logowania:
W sekcji Instancje maszyn wirtualnych sprawdź 2 instancje maszyn wirtualnych utworzone przez Terraform.
Nazwy będą inne, jeśli zmodyfikujesz pole cluster_name.
- g1-controller
- g1-login0
5. Logowanie do klastra Slurm
Dostęp do klastra Slurm
Wróć na kartę edytora kodu lub Cloud Shell. Aby zalogować się w instancji, uruchom to polecenie, zastępując <ZONE> strefą węzła g1-login0 (powinna to być strefa us-central1-b):
gcloud compute ssh g1-login0 --zone=<ZONE>
To polecenie zaloguje Cię w maszynie wirtualnej g1-login0.
Inną metodą łatwego uzyskania dostępu do węzła logowania jest kliknięcie przycisku „SSH” obok maszyny wirtualnej g1-login0 na stronie Instancje maszyn wirtualnych. Spowoduje to otwarcie nowej karty z połączeniem SSH.
Jeśli po raz pierwszy używasz Cloud Shell, może pojawić się komunikat podobny do tego poniżej z prośbą o utworzenie klucza SSH:
WARNING: The public SSH key file for gcloud does not exist. WARNING: The private SSH key file for gcloud does not exist. WARNING: You do not have an SSH key for gcloud. WARNING: SSH keygen will be executed to generate a key. This tool needs to create the directory [/home/user/.ssh] before being able to generate SSH keys. Do you want to continue (Y/n)?
Jeśli tak, wpisz Y. Jeśli pojawi się prośba o wybranie hasła, pozostaw je puste, dwukrotnie naciskając Enter.
Jeśli po zalogowaniu pojawi się ten komunikat:
*** Slurm is currently being configured in the background. *** A terminal broadcast will announce when installation and configuration is complete.
Poczekaj, aż pojawi się ten komunikat, i dopiero wtedy kontynuuj pracę w laboratorium (ok. 5 min):
*** Slurm login setup complete ***
Gdy zobaczysz powyższy komunikat, musisz się wylogować i ponownie zalogować w g1-login0, aby kontynuować moduł. Aby to zrobić, naciśnij CTRL+C, aby zakończyć zadanie.
Następnie uruchom to polecenie, aby wylogować się z instancji:
exit
Teraz połącz się ponownie z maszyną wirtualną logowania. Aby zalogować się w instancji, uruchom to polecenie, zastępując <ZONE> strefą węzła g1-login0:
gcloud compute ssh g1-login0 --zone=<ZONE>
Podobnie jak w przypadku powyższych czynności, może minąć minuta lub dwie, zanim uda Ci się połączyć i zakończyć wszystkie etapy konfiguracji.
Przewodnik po narzędziach interfejsu wiersza poleceń Slurm
Udało Ci się zalogować w węźle logowania Slurm klastra. Jest to węzeł przeznaczony do interakcji użytkownika lub administratora, planowania zadań Slurm i działań administracyjnych.
Uruchommy kilka poleceń, aby zapoznać Cię z wierszem poleceń Slurm.
Aby wyświetlić stan zasobów klastra, wykonaj polecenie sinfo:
sinfo
Przykładowe dane wyjściowe polecenia sinfo są widoczne poniżej. Polecenie sinfo podaje informacje o węzłach dostępnych w klastrze, ich stanie i inne informacje, takie jak partycja, dostępność i wszelkie ograniczenia czasowe nałożone na te węzły.
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST debug* up infinite 10 idle~ g1-compute-0-[0-9]
Widać, że 10 węzłów, których liczbę określa wartość „max_node_count” w partycji debugowania (10), jest oznaczonych jako „idle~” (węzeł jest w stanie bezczynności i nie jest przydzielony, gotowy do uruchomienia).
Następnie wykonaj polecenie squeue, aby wyświetlić stan kolejki klastra:
squeue
Spodziewane dane wyjściowe polecenia squeue są widoczne poniżej. Polecenie squeue raportuje stan kolejki klastra. Obejmuje to identyfikator każdego zadania zaplanowanego w klastrze, partycję, do której jest przypisane zadanie, nazwę zadania, użytkownika, który je uruchomił, stan zadania, czas działania zadania i węzły, do których jest ono przypisane. Nie mamy żadnych uruchomionych zadań, więc zawartość tego polecenia jest pusta.
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
Polecenia Slurm „srun” i „sbatch” służą do uruchamiania zadań, które są umieszczane w kolejce. Polecenie „srun” uruchamia zadania równoległe i może być używane jako otoka dla polecenia mpirun. Polecenie „sbatch” służy do przesyłania zadania wsadowego do slurm i może wywoływać polecenie srun raz lub wiele razy w różnych konfiguracjach. Polecenie „sbatch” może przyjmować skrypty wsadowe lub może być używane z opcją –wrap, aby uruchomić całe zadanie z poziomu wiersza poleceń.
Uruchommy zadanie, aby zobaczyć Slurm w działaniu i dodać zadanie do kolejki.
6. Uruchamianie zadania Slurm i skalowanie klastra
Uruchamianie zadania Slurm i skalowanie klastra
Klaster Slurm jest już uruchomiony, więc teraz uruchomimy zadanie i skalujemy klaster w górę.
Polecenie „sbatch” służy do uruchamiania poleceń i skryptów wsadowych Slurm. Uruchommy prosty skrypt sbatch, który uruchomi polecenie „hostname” na automatycznie skalowanych maszynach wirtualnych.
Po zalogowaniu się na g1-login0 uruchom to polecenie:
sbatch -N2 --wrap="srun hostname"
To polecenie uruchamia polecenie wsadowe Slurm. Określa, że sbatch uruchomi 2 węzły za pomocą opcji „-N”. Określa też, że każdy z tych węzłów wykona polecenie „srun hostname” w opcji „–wrap”.
Domyślnie polecenie sbatch zapisuje dane wyjściowe w pliku „slurm-%j.out” w katalogu roboczym, z którego jest uruchamiane. Znak %j jest zastępowany identyfikatorem zadania zgodnie z wzorcami nazw plików Slurm. W naszym przykładzie polecenie sbatch jest uruchamiane z folderu /home użytkownika, który jest domyślnie systemem plików współdzielonych opartym na NFS i hostowanym na kontrolerze. Umożliwia to węzłom obliczeniowym udostępnianie danych wejściowych i wyjściowych, jeśli jest to potrzebne. W środowisku produkcyjnym pamięć robocza powinna być oddzielona od pamięci /home, aby uniknąć negatywnego wpływu na wydajność operacji klastra. Oddzielne punkty montowania pamięci masowej można określić w pliku tfvars w opcjach „network_storage”.
Po wykonaniu skryptu sbatch za pomocą wiersza poleceń sbatch zwróci on identyfikator zadania zaplanowanego zadania, np.:
Submitted batch job 2
Identyfikator zadania zwrócony przez polecenie sbatch możemy wykorzystać do śledzenia i zarządzania wykonaniem zadania oraz zasobami. Uruchom to polecenie, aby wyświetlić kolejkę zadań Slurm:
squeue
Wykonane zadanie prawdopodobnie pojawi się na liście w ten sposób:
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
2 debug g1-compute-0-[0-1] username R 0:10 2 g1-compute-0-[0-1]
Nie mamy żadnych węzłów obliczeniowych, więc Slurm automatycznie utworzy instancje obliczeniowe zgodnie z wymaganiami zadania. Automatyczny charakter tego procesu ma 2 zalety. Po pierwsze, eliminuje pracę zwykle wymaganą w klastrze HPC, czyli ręczne udostępnianie węzłów, konfigurowanie oprogramowania, integrowanie węzła z klastrem, a następnie wdrażanie zadania. Po drugie, pozwala użytkownikom zaoszczędzić pieniądze, ponieważ nieużywane, bezczynne węzły są skalowane w dół, aż do osiągnięcia minimalnej liczby węzłów.
Aby wyświetlić uruchamianie klastra Slurm, możesz wykonać polecenie sinfo:
sinfo
Wyświetli to węzły wymienione w squeue w stanie „alloc#”, co oznacza, że węzły są przydzielane:
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST debug* up infinite 8 idle~ g1-compute-0-[2-9] debug* up infinite 2 alloc# g1-compute-0-[0-1]
Możesz też sprawdzić sekcję Instancje maszyn wirtualnych w konsoli Google Cloud, aby wyświetlić nowo udostępnione węzły. Uruchomienie węzłów i uruchomienie Slurm zajmie kilka minut, zanim zadanie zostanie przydzielone do nowo przydzielonych węzłów. Lista instancji maszyn wirtualnych będzie wkrótce wyglądać tak:
Gdy węzły uruchomią zadanie, instancje przejdą w stan „alloc”, co oznacza, że zadania są przypisane do zadania:
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST debug* up infinite 8 idle~ g1-compute-0-[2-9] debug* up infinite 2 alloc g1-compute-0-[0-1]
Po zakończeniu zadania nie będzie ono już widoczne w squeue, a węzły „alloc” w sinfo wrócą do stanu „idle”. Okresowo uruchamiaj polecenie „squeue”, aż zadanie zostanie ukończone (po minucie lub dwóch).
Plik wyjściowy slurm-%j.out zostanie zapisany w folderze /home udostępnionym przez NFS i będzie zawierać nazwy hostów. Otwórz lub wyświetl plik wyjściowy (zwykle slurm-2.out). Jego zawartość będzie zawierać:
g1-compute-0-0 g1-compute-0-1
Świetna robota! Udało Ci się uruchomić zadanie i skalować klaster Slurm.
7. Uruchamianie zadania MPI
Uruchommy teraz zadanie MPI na naszych węzłach. Po zalogowaniu się na g1-login0 użyj polecenia wget, aby pobrać program MPI napisany w języku programowania C:
wget https://raw.githubusercontent.com/mpitutorial/mpitutorial/gh-pages/tutorials/mpi-hello-world/code/mpi_hello_world.c
Aby używać narzędzi OpenMPI, musisz wczytać moduły OpenMPI, uruchamiając to polecenie:
module load openmpi
Do skompilowania kodu MPI C użyjemy narzędzia „mpicc”. Uruchom to polecenie:
mpicc mpi_hello_world.c -o mpi_hello_world
Spowoduje to skompilowanie kodu C do kodu maszynowego, dzięki czemu będziemy mogli uruchamiać go w całym klastrze za pomocą Slurm.
Następnie w wybranym edytorze tekstu utwórz skrypt sbatch o nazwie „helloworld_batch”:
vi helloworld_batch
Wpisz i, aby przejść do trybu wstawiania vi.
Skopiuj i wklej ten tekst do pliku, aby utworzyć prosty skrypt sbatch:
#!/bin/bash # #SBATCH --job-name=hello_world #SBATCH --output=hello_world-%j.out # #SBATCH --nodes=2 srun mpi_hello_world
Zapisz zmiany i zamknij edytor kodu, naciskając klawisz Escape i wpisując „:wq” bez cudzysłowu.
Ten skrypt definiuje środowisko wykonawcze i zadania wsadowe Slurm. Po pierwsze, środowisko wykonawcze jest zdefiniowane jako bash. Następnie skrypt definiuje opcje Slurm, zaczynając od wierszy „#SBATCH”. Nazwa zadania to „hello_world”.
Plik wyjściowy jest ustawiony jako „hello_world_%j.out”, gdzie %j jest zastępowany identyfikatorem zadania zgodnie z wzorcami nazw plików Slurm. Ten plik wyjściowy jest zapisywany w katalogu, z którego uruchamiany jest skrypt sbatch. W naszym przykładzie jest to folder /home użytkownika, który jest systemem plików współdzielonych opartym na NFS. Umożliwia to węzłom obliczeniowym udostępnianie danych wejściowych i wyjściowych, jeśli jest to potrzebne. W środowisku produkcyjnym pamięć robocza powinna być oddzielona od pamięci /home, aby uniknąć negatywnego wpływu na wydajność operacji klastra.
Na koniec liczba węzłów, w których ma być uruchomiony ten skrypt, jest określona jako 2.
Po zdefiniowaniu opcji podawane są polecenia wykonywalne. Ten skrypt uruchomi kod mpi_hello_world równolegle za pomocą polecenia srun, które jest zamiennikiem polecenia mpirun.
Następnie wykonaj skrypt sbatch za pomocą wiersza poleceń sbatch:
sbatch helloworld_batch
Uruchomienie polecenia sbatch zwróci identyfikator zadania zaplanowanego zadania, np.:
Submitted batch job 3
Spowoduje to uruchomienie polecenia hostname na 2 węzłach, z 1 zadaniem na węzeł, a także wydrukowanie danych wyjściowych w pliku hello_world-3.out.
Ponieważ mamy już 2 węzły, to zadanie zostanie wykonane szybko.
Monitoruj squeue, dopóki zadanie nie zostanie ukończone i nie będzie już widoczne:
squeue
Po zakończeniu otwórz lub wyświetl plik hello_world-3.out i sprawdź, czy został uruchomiony na g1-compute-0-[0-1]:
Hello world from processor g1-compute-0-0, rank 0 out of 2 processors Hello world from processor g1-compute-0-1, rank 1 out of 2 processors
Po 5 minutach bezczynności (czas ten można skonfigurować za pomocą pola suspend_time w pliku YAML lub pola SuspendTime w pliku slurm.conf) dynamicznie udostępnione węzły obliczeniowe zostaną zwolnione, aby udostępnić zasoby. Możesz to sprawdzić, okresowo uruchamiając polecenie sinfo i obserwując, jak rozmiar klastra wraca do 0:
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST debug* up infinite 10 idle~ g1-compute-0-[0-9]
Spróbuj uruchomić więcej instancji (do limitu dozwolonego w regionie, w którym wdrożono klaster) i uruchomić różne aplikacje MPI.
8. Podsumowanie
Gratulacje! Utworzyliśmy klaster Slurm na Google Cloud Platform i użyliśmy jego najnowszych funkcji do automatycznego skalowania klastra w celu zaspokojenia zapotrzebowania na moc obliczeniową. Możesz używać tego modelu do uruchamiania różnych zadań. Skaluje się on do setek instancji w ciągu kilku minut, wystarczy poprosić o węzły w Slurm.
Jeśli chcesz dowiedzieć się więcej o korzystaniu z Slurm w GCP, zapoznaj się z codelabem „ Tworzenie sfederowanych klastrów HPC za pomocą Slurm”. Te ćwiczenia poprowadzą Cię przez proces konfigurowania w chmurze 2 sklastrowanych systemów Slurm, aby pokazać, jak można utworzyć federację wieloklastrową, niezależnie od tego, czy jest ona lokalna, czy w chmurze.
Tworzysz coś ciekawego przy użyciu nowych funkcji Slurm natywnych dla GCP? Masz pytania? Masz propozycję dotyczącą funkcji? Skontaktuj się z zespołem Google Cloud już dziś na stronie internetowej Google Cloud poświęconej rozwiązaniom do komputery o dużej mocy obliczeniowej lub porozmawiaj z nami w grupie dyskusyjnej Google Cloud i Slurm.
Czyszczenie wdrożenia Terraform
Wyloguj się z węzła Slurm:
exit
Przed usunięciem wdrożenia poczekaj, aż wszystkie automatycznie skalowane węzły zostaną przeskalowane w dół. Możesz też usunąć te węzły ręcznie, uruchamiając polecenie „gcloud compute instances delete <Instance Name>” dla każdej instancji lub używając graficznego interfejsu konsoli, aby wybrać wiele węzłów i kliknąć „Usuń”.
Po zakończeniu pracy możesz łatwo wyczyścić wdrożenie Terraform, wykonując to polecenie w Google Cloud Shell po wylogowaniu się z g1-login0:
cd ~/slurm-gcp/tf/examples/basic terraform destroy -var-file=basic.tfvars
Gdy pojawi się prośba, wpisz yes, aby przejść dalej. Ta operacja może potrwać kilka minut. Prosimy o cierpliwość.
Usuwanie projektu
Aby posprzątać, po prostu usuwamy projekt.
- W menu nawigacyjnym wybierz Uprawnienia i Administracja.
- Następnie w menu kliknij ustawienia.
- Kliknij ikonę kosza z tekstem „Usuń projekt”.
- Postępuj zgodnie z instrukcjami wyświetlanymi w promptach.
Omówione zagadnienia
- Jak wdrożyć Slurm w GCP za pomocą Terraform.
- Jak uruchomić zadanie za pomocą Slurm w GCP.
- Jak wysyłać zapytania o informacje o klastrze i monitorować uruchomione zadania w Slurm.
- Jak automatycznie skalować węzły za pomocą Slurm w GCP, aby dostosować je do konkretnych parametrów i wymagań zadań.
- Jak kompilować i uruchamiać aplikacje MPI w Slurm w GCP.
Pomoc dotycząca Slurm
Jeśli potrzebujesz pomocy w korzystaniu z tych integracji w środowiskach testowych lub produkcyjnych, skontaktuj się bezpośrednio z firmą SchedMD na stronie kontaktowej: https://www.schedmd.com/contact.php.
Możesz też skorzystać z dostępnych przewodników rozwiązywania problemów:
- Przewodnik rozwiązywania problemów z Slurm w GCP: https://github.com/SchedMD/slurm-gcp#troubleshooting
- Przewodnik rozwiązywania problemów SchedMD: https://slurm.schedmd.com/troubleshoot.html
Możesz też zadać pytanie w Grupie dyskusyjnej Google Cloud i Slurm: https://groups.google.com/g/google-cloud-slurm-discuss
Więcej informacji
Prześlij opinię
Prześlij opinię o tym ćwiczeniu za pomocą tego linku. Przesłanie opinii zajmuje mniej niż 5 minut. Dziękujemy!