1. Panoramica
Ti diamo il benvenuto nel codelab di Google per l'esecuzione di un cluster Slurm su Google Cloud. Al termine di questo codelab, dovresti avere una solida comprensione della facilità di provisioning e di funzionamento di un cluster Slurm con scalabilità automatica.
Google Cloud ha collaborato con SchedMD per rilasciare un insieme di strumenti che semplificano l'avvio del gestore dei workload Slurm su Compute Engine e l'espansione dinamica del cluster esistente quando hai bisogno di risorse aggiuntive. Questa integrazione è stata creata dagli esperti di SchedMD in conformità con le best practice di Slurm.
Se prevedi di utilizzare le integrazioni di Slurm su Google Cloud Platform o se hai domande, ti consigliamo di unirti al nostro gruppo di discussione della community Google Cloud e Slurm.
Informazioni su Slurm
Diagramma architetturale di base di un cluster Slurm autonomo in Google Cloud.
Slurm è uno dei principali gestori di carichi di lavoro per i cluster HPC in tutto il mondo. Slurm fornisce un sistema di gestione dei carichi di lavoro e di pianificazione dei job open source, a tolleranza di errore e altamente scalabile per cluster Linux di piccole e grandi dimensioni. Slurm non richiede modifiche al kernel per il suo funzionamento ed è relativamente autonomo. In qualità di gestore dei carichi di lavoro del cluster, Slurm ha tre funzioni principali:
- Assegna agli utenti l'accesso esclusivo o non esclusivo alle risorse (nodi di calcolo) per un determinato periodo di tempo, in modo che possano svolgere il lavoro.
- Fornisce un framework per avviare, eseguire e monitorare il lavoro (in genere un job parallelo) sul set di nodi allocati.
- Gestisce la contesa per le risorse gestendo una coda di lavoro in attesa.
Obiettivi didattici
- Come configurare un cluster Slurm utilizzando Terraform
- Come eseguire un job utilizzando SLURM
- Come eseguire query sulle informazioni del cluster e monitorare i job in esecuzione in SLURM
- Come scalare automaticamente i nodi per soddisfare parametri e requisiti specifici del job
- Dove trovare assistenza per Slurm
Prerequisiti
- Account Google Cloud Platform e un progetto con fatturazione
- Esperienza di base con Linux
2. Configurazione
Configurazione dell'ambiente autonomo
Crea un progetto
Se non hai già un Account Google (Gmail o G Suite), devi crearne uno. Accedi alla console di Google Cloud ( console.cloud.google.com) e apri la pagina Gestisci risorse:
Fai clic su Crea progetto.
Inserisci un nome per il progetto. Ricorda l'ID progetto (evidenziato in rosso nello screenshot sopra). L'ID progetto deve essere un nome univoco tra tutti i progetti Google Cloud. Se il nome del progetto non è univoco, Google Cloud genererà un ID progetto casuale basato sul nome del progetto.
Successivamente, devi abilitare la fatturazione in Developers Console per utilizzare le risorse Google Cloud.
L'esecuzione di questo codelab non dovrebbe costarti più di qualche dollaro, ma potrebbe essere più cara se decidi di utilizzare più risorse o se le lasci in esecuzione (vedi la sezione "Conclusione" alla fine di questo documento). Il Calcolatore prezzi di Google Cloud Platform è disponibile qui.
I nuovi utenti di Google Cloud Platform possono beneficiare di una prova senza costi di 300$.
Google Cloud Shell
Sebbene Google Cloud possa essere gestito da remoto dal tuo laptop, in questo codelab utilizzeremo Google Cloud Shell, un ambiente a riga di comando in esecuzione nel cloud.
Avvia Google Cloud Shell
Nella console GCP, fai clic sull'icona di Cloud Shell nella barra degli strumenti in alto a destra:
Quindi, fai clic su Avvia Cloud Shell:
Bastano pochi istanti per eseguire il provisioning e connettersi all'ambiente:
Questa macchina virtuale è caricata con tutti gli strumenti per sviluppatori di cui avrai bisogno. Offre una home directory permanente da 5 GB e viene eseguita su Google Cloud, migliorando notevolmente le prestazioni della rete e semplificando l'autenticazione. Gran parte del lavoro per questo lab, se non tutto, può essere svolto semplicemente con un browser web o un Google Chromebook.
Una volta eseguita la connessione a Cloud Shell, dovresti vedere che il tuo account è già autenticato e il progetto è già impostato sul tuo PROJECT_ID:
$ gcloud auth list
Output comando:
Credentialed accounts:
- <myaccount>@<mydomain>.com (active)
$ gcloud config list project
Output comando:
[core]
project = <PROJECT_ID>
Se l'ID progetto non è impostato correttamente, puoi impostarlo con questo comando:
$ gcloud config set project <PROJECT_ID>
Output comando:
Updated property [core/project].
3. Prepara e rivedi la configurazione Terraform di Slurm
Scarica la configurazione Terraform di Slurm
Nella sessione di Cloud Shell, esegui questo comando per clonare (scaricare) il repository Git che contiene i file Terraform di Slurm per Google Cloud:
git clone https://github.com/SchedMD/slurm-gcp.git
Passa alla directory di configurazione del deployment di Slurm eseguendo il seguente comando:
cd slurm-gcp
Configura tfvars di Terraform per Slurm
Il file basic.tfvars.example descrive in dettaglio la configurazione del deployment, inclusi la rete, le istanze e lo spazio di archiviazione da eseguire. Copialo in un nuovo file, che chiameremo "file tfvars", poi modificalo in base alle tue esigenze.
cd tf/example/basic cp basic.tfvars.example basic.tfvars
Nella sessione di Cloud Shell, apri il file tfvars basic.tfvars. Puoi utilizzare l'editor della riga di comando che preferisci (vi, nano, emacs e così via) oppure l'editor di codice Cloud Console per visualizzare i contenuti del file:
Esamina i contenuti del file 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"
]
All'interno di questo file tfvars sono presenti diversi campi da configurare. L'unico campo da configurare è project. Tutte le altre configurazioni nell'esempio possono essere utilizzate così come sono, ma modificale in base alle tue esigenze. Per una descrizione più dettagliata delle opzioni di configurazione, consulta questa pagina.
- cluster_name: Nome del cluster Slurm
- project: ID progetto Google Cloud in cui verranno eseguito il deployment delle risorse
- zona:la zona Google Cloud che conterrà le istanze del controller e di accesso di questo cluster. Scopri di più
- network_name: rete Virtual Private Cloud in cui eseguire il deployment del cluster Slurm
- subnetwork_name: subnet Virtual Private Cloud in cui eseguire il deployment del cluster Slurm
- shared_vpc_host_project: Rete VPC condivisa in cui eseguire il deployment del cluster Slurm
- disable_controller_public_ips: assegna un IP esterno al controller Slurm?
- disable_login_public_ips: Assegnare l'IP esterno al nodo di accesso Slurm?
- disable_compute_login_ips: Assegnare l'IP esterno al nodo di accesso Slurm?
- suspend_time: tempo di attesa dopo l'inattività di un nodo prima di sospenderlo
- controller_machine_type: tipo di istanza del nodo controller
- controller_image: immagine GCP utilizzata per creare l'istanza del controller Slurm
- controller_disk_type: tipo di disco di avvio dell'istanza del controller
- controller_disk_size_gb: dimensione di un disco di avvio dell'istanza del controller
- controller_labels: Etichetta o etichette da allegare all'istanza del controller
- controller_service_account: Service account da utilizzare nell'istanza del controller
- controller_scopes: ambito di accesso dell'istanza del controller
- cloudsql: Google CloudSQL da utilizzare come database Slurm anziché ospitarne uno sull'istanza del controller
- server_ip: IP del server Cloud SQL
- user: Nome utente Cloud SQL
- password: password Cloud SQL
- db_name: nome del database Cloud SQL
- controller_secondary_disk: vuoi aggiungere un disco secondario per l'archiviazione del server NFS?
- controller_secondary_disk_type: tipo di disco secondario del controller
- controller_secondary_disk_size_gb: dimensioni del disco secondario del controller
- controller_instance_template: il template di istanza GCP da utilizzare per l'istanza del controller. Tutti i campi di calcolo specificati sostituiranno le proprietà del modello. Ad esempio, se viene specificata controller_image, questa sovrascriverà l'immagine nel template di istanza.
- login_machine_type: nodo di accesso (accessibile tramite SSH) tipo di istanza
- login_image: immagine GCP utilizzata per creare l'istanza di accesso Slurm
- login_disk_type: Tipo di disco di avvio dell'istanza di accesso
- login_disk_size_gb: dimensione del disco di avvio dell'istanza di accesso
- login_labels: etichetta/e da allegare all'istanza di accesso
- login_node_count: numero di nodi di accesso da creare
- login_node_service_account: service account da utilizzare nelle istanze di accesso
- login_node_scopes: ambito di accesso dell'istanza di accesso
- login_instance_template: il template di istanza GCP da utilizzare per l'istanza di accesso. Tutti i campi di calcolo specificati sostituiranno le proprietà del modello. Ad esempio, se viene specificata login_image, questa sovrascriverà l'immagine nel modello di istanza.
- network_storage::spazio di archiviazione di rete da montare su tutti i nodi. I campi verranno aggiunti direttamente a fstab. Può essere ripetuto per supporti aggiuntivi.
- server_ip: IP del server di archiviazione
- remote_mount: Nome del montaggio dello spazio di archiviazione (nome del file system)
- local_mount: directory di montaggio locale
- fs_type: Tipo di file system (NFS, CIFS, Lustre, GCSFuse installato automaticamente)
- mount_options: opzioni di montaggio (ad es. defaults,_netdev)
- login_network_storage: spazio di archiviazione di rete da montare sui nodi di accesso e del controller. NFS, CIFS, Lustre e GCSFuse verranno installati automaticamente. Può essere ripetuto per supporti aggiuntivi.
- server_ip: IP del server di archiviazione
- remote_mount: Nome del montaggio dello spazio di archiviazione (nome del file system)
- local_mount: directory di montaggio locale
- fs_type: Tipo di file system (NFS, CIFS, Lustre, GCSFuse installato automaticamente)
- mount_options: opzioni di montaggio (ad es. defaults,_netdev)
- compute_node_service_account: Service account da utilizzare sulle istanze di computing
- compute_node_scopes: ambito di accesso delle istanze di calcolo
- partitions: configurazione della partizione Slurm. Può essere ripetuto per partizioni aggiuntive.
- name: Nome della partizione
- machine_type: nodo o nodi di computing tipo di istanza
- static_node_count: numero di nodi di computing sempre attivi
- max_node_count::numero massimo di nodi di computing totali consentiti. Massimo 64.000.
- zona: la zona Google Cloud che conterrà le risorse di questa partizione. Scopri di più
- image: tipo di macchina del nodo di immagine di calcolo
- image_hyperthreads: attiva o disattiva l'hyperthreading sull'istanza
- compute_disk_type: tipo di disco di avvio di un'istanza di Compute (pd-standard, pd-ssd)
- compute_disk_size_gb: dimensione di un disco di avvio dell'istanza di computing
- compute_labels: etichetta o etichette da collegare all'istanza di computing
- cpu_platform: piattaforma CPU minima richiesta per tutti i nodi di computing
- gpu_count: numero di GPU da collegare a ogni istanza nella partizione
- gpu_type: Tipo di GPU da collegare alle istanze della partizione
- network_storage::archiviazione di rete da montare su tutti i nodi di computing nella partizione. I campi verranno aggiunti direttamente a fstab. Può essere ripetuto per supporti aggiuntivi.
- server_ip: IP del server di archiviazione
- remote_mount: Nome del montaggio dello spazio di archiviazione (nome del file system)
- local_mount: directory di montaggio locale
- fs_type: Tipo di file system (NFS, CIFS, Lustre, GCSFuse installato automaticamente)
- mount_options: Opzione di montaggio
- preemptible_bursting: le istanze saranno istanze preemptible?
- vpc_subnet: subnet Virtual Private Cloud in cui eseguire il deployment della partizione Slurm
- exclusive: consente a Slurm di allocare nodi interi ai job
- enable_placement: abilita le policy di posizionamento in cui le istanze si troveranno vicine tra loro per una bassa latenza di rete tra le istanze.
- regional_capacity::consente di posizionare un'istanza in qualsiasi zona della regione in base alla disponibilità
- regional_policy::se regional_capacity è true, questo criterio serve a determinare quale regione utilizzare e quali zone di quella regione non utilizzare
- Instance_template::il template di istanza GCP da utilizzare per le istanze di computing. Tutti i campi di calcolo specificati sostituiranno le proprietà del modello. Ad esempio, se viene specificata un'immagine, questa sovrascriverà l'immagine nel modello di istanza.
Configurazione avanzata
Se vuoi, puoi scegliere di installare pacchetti e software aggiuntivi nell'ambito della procedura di deployment del cluster. Puoi installare il software sul cluster Slurm in diversi modi descritti nella sezione "Installazione di app in un cluster Slurm su Compute Engine" o personalizzando l'immagine di cui è stato eseguito il deployment da Slurm. Attualmente Slurm esegue il deployment di un'immagine VM fornita da SchedMD basata sull'immagine VM HPC di Google Cloud, con Slurm installato sopra.
Per utilizzare la tua immagine, crea un'immagine con la tua configurazione basata sull'immagine VM SchedMD pubblica elencata nel file tfvars. Successivamente, sostituisci l'URI dell'immagine specificato nel file tfvars con la tua immagine e verifica la modifica.
Risoluzione dei problemi
Durante questo codelab, fai riferimento alla sezione Risoluzione dei problemi del file ReadMe del repository Slurm-GCP.
I problemi più comuni riscontrati sono errori nella configurazione del file tfvars e limitazioni della quota. Questo codelab è progettato per essere eseguito nell'ambito della quota standard di un nuovo utente e dei 300 $di credito senza costi che riceve. Se un tentativo di creare VM non va a buon fine, controlla il file /var/log/slurm/resume.log sul nodo controller per verificare la presenza di errori API.
4. Deployment e verifica della configurazione
Esegui il deployment della configurazione
Nella sessione di Cloud Shell, esegui questo comando dalla cartella slurm-gcp/tf/example:
terraform init terraform apply -var-file=basic.tfvars
Ti verrà chiesto di accettare le azioni descritte in base alle configurazioni impostate. Inserisci "yes" per iniziare il deployment. Puoi anche visualizzare la configurazione da implementare eseguendo "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
Il completamento dell'operazione può richiedere alcuni minuti, quindi abbi pazienza.
Una volta completato il deployment, vedrai un output simile al seguente:
Apply complete! Resources: 8 added, 0 changed, 0 destroyed.
Outputs:
controller_network_ips = [
[
"10.0.0.2",
],
]
login_network_ips = [
[
"10.0.0.3",
],
]
Verifica la creazione dell'istanza VM
Apri il menu di navigazione e seleziona Compute Engine > Istanze VM.
Dovresti vedere un controller e un'istanza VM di accesso elencati:
In Istanze VM, esamina le due istanze di macchine virtuali create da Terraform.
I nomi saranno diversi se hai modificato il campo cluster_name.
- g1-controller
- g1-login0
5. Accedi al cluster Slurm
Accedere al cluster Slurm
Torna alla scheda Editor di codice/Cloud Shell. Esegui questo comando per accedere alla tua istanza, sostituendo <ZONE> con la zona del nodo g1-login0 (deve essere us-central1-b):
gcloud compute ssh g1-login0 --zone=<ZONE>
Questo comando ti consentirà di accedere alla macchina virtuale g1-login0.
Un altro metodo per accedere facilmente al nodo di accesso è fare clic sul pulsante "SSH" accanto alla VM g1-login0 nella pagina Istanze VM per aprire una nuova scheda con una connessione SSH.
Se è la prima volta che utilizzi Cloud Shell, potresti visualizzare un messaggio come quello riportato di seguito che ti chiede di creare una chiave 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)?
In tal caso, inserisci Y. Se ti viene chiesto di selezionare una passphrase, lasciala vuota premendo Invio due volte.
Se al momento dell'accesso viene visualizzato il seguente messaggio:
*** Slurm is currently being configured in the background. *** A terminal broadcast will announce when installation and configuration is complete.
Attendi e non procedere con il lab finché non visualizzi questo messaggio (circa 5 minuti):
*** Slurm login setup complete ***
Una volta visualizzato il messaggio precedente, dovrai uscire e accedere di nuovo a g1-login0 per continuare il lab. Per farlo, premi Ctrl + C per terminare l'attività.
Quindi esegui questo comando per uscire dall'istanza:
exit
Ora, riconnettiti alla VM di accesso. Esegui questo comando per accedere alla tua istanza, sostituendo <ZONE> con la zona del nodo g1-login0:
gcloud compute ssh g1-login0 --zone=<ZONE>
Come sopra, potresti dover attendere un minuto o due prima di poterti connettere e completare tutti gli aspetti della configurazione.
Tour degli strumenti dell'interfaccia a riga di comando Slurm
Ora hai eseguito l'accesso al nodo di accesso Slurm del cluster. Questo è il nodo dedicato all'interazione utente/amministratore, alla pianificazione dei job Slurm e all'attività amministrativa.
Eseguiamo un paio di comandi per presentarti la riga di comando di Slurm.
Esegui il comando sinfo per visualizzare lo stato delle risorse del cluster:
sinfo
Di seguito è riportato un output di esempio di sinfo. sinfo segnala i nodi disponibili nel cluster, il loro stato e altre informazioni come la partizione, la disponibilità e qualsiasi limite di tempo imposto a questi nodi.
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST debug* up infinite 10 idle~ g1-compute-0-[0-9]
Puoi vedere che i nostri 10 nodi, dettati da "max_node_count" della partizione di debug pari a 10, sono contrassegnati come "idle~" (il nodo è in modalità inattiva e non allocata, pronto per essere avviato).
Successivamente, esegui il comando squeue per visualizzare lo stato della coda del cluster:
squeue
L'output previsto di squeue è riportato di seguito. squeue segnala lo stato della coda per un cluster. Sono inclusi l'ID job di ogni job pianificato sul cluster, la partizione a cui è assegnato il job, il nome del job, l'utente che ha avviato il job, lo stato del job, il tempo di esecuzione del job e i nodi a cui è allocato il job. Non sono in esecuzione job, quindi i contenuti di questo comando sono vuoti.
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
I comandi Slurm "srun" e "sbatch" vengono utilizzati per eseguire i job inseriti nella coda. "srun" esegue job paralleli e può essere utilizzato come wrapper per mpirun. "sbatch" viene utilizzato per inviare un job batch a slurm e può chiamare srun una o più volte in configurazioni diverse. "sbatch" può accettare script batch o può essere utilizzato con l'opzione –wrap per eseguire l'intero job dalla riga di comando.
Eseguiamo un job per vedere Slurm in azione e inserire un job nella nostra coda.
6. Esegui un job Slurm e scala il cluster
Esegui un job Slurm e scala il cluster
Ora che il cluster Slurm è in esecuzione, eseguiamo un job e scaliamo il cluster.
Il comando "sbatch" viene utilizzato per eseguire comandi e script batch Slurm. Eseguiamo un semplice script sbatch che esegue "hostname" sulle nostre VM con scalabilità automatica.
Dopo aver eseguito l'accesso a g1-login0, esegui questo comando:
sbatch -N2 --wrap="srun hostname"
Questo comando esegue il comando batch Slurm. Specifica che sbatch eseguirà 2 nodi con l'opzione "-N". Specifica inoltre che ciascuno di questi nodi eseguirà un comando "srun hostname" nell'opzione "–wrap".
Per impostazione predefinita, sbatch scrive l'output in "slurm-%j.out" nella directory di lavoro da cui viene eseguito il comando, dove %j viene sostituito dall'ID job in base ai pattern dei nomi file di Slurm. Nel nostro esempio, sbatch viene eseguito dalla cartella /home dell'utente, che per impostazione predefinita è un file system condiviso basato su NFS ospitato sul controller. Ciò consente ai nodi di calcolo di condividere i dati di input e output, se necessario. In un ambiente di produzione, lo spazio di archiviazione di lavoro deve essere separato dallo spazio di archiviazione /home per evitare impatti sulle prestazioni delle operazioni del cluster. È possibile specificare i montaggi di archiviazione separati nel file tfvars nelle opzioni "network_storage".
Dopo aver eseguito lo script sbatch utilizzando la riga di comando sbatch, verrà restituito un ID job per il job pianificato, ad esempio:
Submitted batch job 2
Possiamo utilizzare l'ID job restituito dal comando sbatch per monitorare e gestire l'esecuzione del job e le risorse. Esegui questo comando per visualizzare la coda dei job Slurm:
squeue
Probabilmente vedrai il job eseguito elencato come di seguito:
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]
Poiché non sono stati forniti nodi di calcolo, Slurm creerà automaticamente istanze di calcolo in base ai requisiti del job. La natura automatica di questo processo presenta due vantaggi. Innanzitutto, elimina il lavoro in genere richiesto in un cluster HPC di provisioning manuale dei nodi, configurazione del software, integrazione del nodo nel cluster e quindi deployment del job. In secondo luogo, consente agli utenti di risparmiare denaro perché i nodi inattivi e inutilizzati vengono ridimensionati fino a quando non è in esecuzione il numero minimo di nodi.
Puoi eseguire il comando sinfo per visualizzare l'avvio del cluster Slurm:
sinfo
Verranno visualizzati i nodi elencati in squeue nello stato "alloc#", il che significa che i nodi vengono allocati:
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]
Puoi anche controllare la sezione delle istanze VM nella console Google Cloud per visualizzare i nodi di cui è stato eseguito il provisioning. Prima che il job venga assegnato ai nodi appena allocati, saranno necessari alcuni minuti per avviare i nodi ed eseguire Slurm. L'elenco delle istanze VM sarà presto simile al seguente:
Una volta che i nodi eseguono il job, le istanze passeranno allo stato "alloc", il che significa che i job vengono assegnati a un job:
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]
Una volta completato un job, questo non verrà più elencato in squeue e i nodi "alloc" in sinfo torneranno allo stato "idle". Esegui "squeue" periodicamente fino al completamento del job, dopo un minuto o due.
Il file di output slurm-%j.out sarà stato scritto nella cartella /home condivisa tramite NFS e conterrà i nomi host. Apri o visualizza il file di output (in genere slurm-2.out). I contenuti del file di output conterranno:
g1-compute-0-0 g1-compute-0-1
Ottimo lavoro, hai eseguito un job e aumentato le dimensioni del cluster Slurm.
7. Esegui un job MPI
Ora eseguiamo un job MPI sui nostri nodi. Mentre hai eseguito l'accesso a g1-login0, utilizza wget per scaricare un programma MPI scritto nel linguaggio di programmazione C:
wget https://raw.githubusercontent.com/mpitutorial/mpitutorial/gh-pages/tutorials/mpi-hello-world/code/mpi_hello_world.c
Per utilizzare gli strumenti OpenMPI, devi caricare i moduli OpenMPI eseguendo questo comando:
module load openmpi
Utilizzeremo lo strumento "mpicc" per compilare il codice MPI C. Esegui questo comando:
mpicc mpi_hello_world.c -o mpi_hello_world
In questo modo il codice C viene compilato in codice macchina, in modo da poterlo eseguire nel cluster tramite Slurm.
Successivamente, utilizza l'editor di testo che preferisci per creare uno script sbatch chiamato "helloworld_batch":
vi helloworld_batch
Digita i per attivare la modalità di inserimento vi.
Copia e incolla il seguente testo nel file per creare un semplice script sbatch:
#!/bin/bash # #SBATCH --job-name=hello_world #SBATCH --output=hello_world-%j.out # #SBATCH --nodes=2 srun mpi_hello_world
Salva ed esci dall'editor di codice premendo Esc e digitando ":wq" senza virgolette.
Questo script definisce l'ambiente di esecuzione batch e le attività di Slurm. Innanzitutto, l'ambiente di esecuzione è definito come bash. Successivamente, lo script definisce prima le opzioni Slurm con le righe "#SBATCH". Il nome del job è definito come "hello_world".
Il file di output è impostato su "hello_world_%j.out", dove %j viene sostituito con l'ID job in base ai pattern di nome file Slurm. Questo file di output viene scritto nella directory da cui viene eseguito lo script sbatch. Nel nostro esempio, si tratta della cartella /home dell'utente, che è un file system condiviso basato su NFS. Ciò consente ai nodi di calcolo di condividere i dati di input e output, se necessario. In un ambiente di produzione, lo spazio di archiviazione di lavoro deve essere separato dallo spazio di archiviazione /home per evitare impatti sulle prestazioni delle operazioni del cluster.
Infine, il numero di nodi su cui deve essere eseguito questo script è definito come 2.
Una volta definite le opzioni, vengono forniti i comandi eseguibili. Questo script eseguirà il codice mpi_hello_world in parallelo utilizzando il comando srun, che sostituisce il comando mpirun.
Quindi esegui lo script sbatch utilizzando la riga di comando sbatch:
sbatch helloworld_batch
L'esecuzione di sbatch restituirà un ID job per il job programmato, ad esempio:
Submitted batch job 3
Verrà eseguito il comando hostname su due nodi, con un'attività per nodo, e l'output verrà stampato nel file hello_world-3.out.
Poiché sono già stati sottoposti a provisioning 2 nodi, questo job verrà eseguito rapidamente.
Monitora squeue finché il job non viene completato e non è più elencato:
squeue
Una volta completata l'operazione, apri o visualizza il file hello_world-3.out e verifica che sia stato eseguito su 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
Dopo 5 minuti di inattività (configurabili con il campo suspend_time del file YAML o il campo SuspendTime di slurm.conf), i nodi di calcolo di cui è stato eseguito il provisioning dinamico verranno deallocati per liberare risorse. Puoi verificarlo eseguendo periodicamente sinfo e osservando le dimensioni del cluster tornare a 0:
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST debug* up infinite 10 idle~ g1-compute-0-[0-9]
Prova ad avviare più istanze, fino alla quota consentita nella regione in cui hai eseguito il deployment del cluster, ed esegui applicazioni MPI diverse.
8. Conclusione
Congratulazioni, hai creato un cluster Slurm su Google Cloud Platform e hai utilizzato le sue funzionalità più recenti per scalare automaticamente il cluster in base alla domanda del carico di lavoro. Puoi utilizzare questo modello per eseguire qualsiasi tipo di job e si adatta a centinaia di istanze in pochi minuti semplicemente richiedendo i nodi in Slurm.
Se vuoi continuare a imparare a utilizzare Slurm su Google Cloud, assicurati di continuare con il codelab "Creare un cluster HPC federato con Slurm". Questo codelab ti guiderà nella configurazione di due cluster Slurm federati nel cloud, per rappresentare come potresti ottenere una federazione multi-cluster, on-premise o nel cloud.
Stai creando qualcosa di interessante utilizzando la nuova funzionalità nativa di GCP di Slurm? Domande? Hai un suggerimento per una funzionalità? Contatta oggi stesso il team Google Cloud tramite il sito web delle soluzioni di High Performance Computing di Google Cloud o chatta con noi nel gruppo di discussione Google Cloud e Slurm.
Pulisci il deployment Terraform
Esci dal nodo Slurm:
exit
Consenti ai nodi con scalabilità automatica di fare lo scale down prima di eliminare il deployment. Puoi anche eliminare questi nodi manualmente eseguendo "gcloud compute instances delete <Instance Name>" per ogni istanza oppure utilizzando la GUI della console per selezionare più nodi e fare clic su "Elimina".
Al termine, puoi liberare spazio facilmente nel deployment di Terraform eseguendo il seguente comando da Google Cloud Shell, dopo aver eseguito la disconnessione da g1-login0:
cd ~/slurm-gcp/tf/examples/basic terraform destroy -var-file=basic.tfvars
Quando richiesto, digita yes per continuare. Questa operazione può richiedere diversi minuti, quindi ti invitiamo ad attendere.
Elimina il progetto
Per la pulizia, eliminiamo semplicemente il progetto.
- Nel menu di navigazione, seleziona IAM e amministrazione.
- Poi fai clic su Impostazioni nel sottomenu.
- Fai clic sull'icona del cestino con il testo "Elimina progetto".
- Segui le istruzioni dei prompt.
Argomenti trattati
- Come eseguire il deployment di Slurm su GCP utilizzando Terraform.
- Come eseguire un job utilizzando Slurm su GCP.
- Come eseguire query sulle informazioni del cluster e monitorare i job in esecuzione in Slurm.
- Come scalare automaticamente i nodi con Slurm su GCP per soddisfare parametri e requisiti specifici del job.
- Come compilare ed eseguire applicazioni MPI su Slurm su GCP.
Trovare assistenza per Slurm
Se hai bisogno di assistenza per l'utilizzo di queste integrazioni in ambienti di test o di produzione, contatta direttamente SchedMD utilizzando la pagina di contatto disponibile qui: https://www.schedmd.com/contact.php
Puoi anche utilizzare le guide per la risoluzione dei problemi disponibili:
- Guida alla risoluzione dei problemi di Slurm su GCP: https://github.com/SchedMD/slurm-gcp#troubleshooting
- Guida alla risoluzione dei problemi di SchedMD: https://slurm.schedmd.com/troubleshoot.html
Infine, puoi anche pubblicare la tua domanda nel gruppo di discussione Google Cloud e Slurm disponibile qui: https://groups.google.com/g/google-cloud-slurm-discuss
Scopri di più
Feedback
Invia un feedback su questo codelab utilizzando questo link. La compilazione del feedback richiede meno di 5 minuti. Grazie.