Deployment di un cluster HPC a scalabilità automatica con Slurm

1. Panoramica

Ti diamo il benvenuto nel codelab di Google per l'esecuzione di un cluster Slurm sulla piattaforma Google Cloud. Al termine di questo codelab avrai una buona conoscenza della facilità di provisioning e di funzionamento di un cluster Slurm a scalabilità automatica.

c16fa310c142ac6f.png

Google Cloud ha collaborato con SchedMD per rilasciare una serie di strumenti che semplificano l'avvio di Slurm Workload Manager su Compute Engine, nonché per espandere il cluster esistente in modo dinamico quando hai bisogno di risorse aggiuntive. Questa integrazione è stata creata dagli esperti di SchedMD in conformità con le best practice di Slurm.

Se hai intenzione di utilizzare le integrazioni di Slurm su Google Cloud Platform o per qualsiasi domanda, puoi partecipare ai nostri Google Cloud e Gruppo di discussione della community di Slurm!

Informazioni su Slurm

a739730a41acff0a.png

Diagramma dell'architettura di base di un cluster Slurm autonomo in Google Cloud.

Slurm è uno dei principali gestori dei 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 dei cluster, Slurm ha tre funzioni chiave:

  1. Assegna agli utenti l'accesso esclusivo o non esclusivo alle risorse (nodi di computing) per un certo periodo di tempo, in modo che possano svolgere il lavoro.
  2. Fornisce un framework per l'avvio, l'esecuzione e il monitoraggio del lavoro (normalmente un job parallelo) sull'insieme di nodi allocati.
  3. Arbitra la contesa per le risorse gestendo una coda di lavori in sospeso.

Obiettivi didattici

  • 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 requisiti e parametri del job specifici
  • Dove trovare assistenza per Slurm

Prerequisiti

  • Account della piattaforma Google Cloud e un progetto con fatturazione
  • Esperienza Linux di base

2. Configurazione

Configurazione dell'ambiente da seguire in modo autonomo

Crea un progetto

Se non hai ancora un Account Google (Gmail o G Suite), devi crearne uno. Accedi alla console della piattaforma Google Cloud ( console.cloud.google.com) e apri la pagina Gestisci risorse:

359c06e07e6d699f.png

Fai clic su Crea progetto.

25c23d651abb837b.png

Inserisci un nome per il progetto. Ricorda l'ID progetto (evidenziato in rosso nello screenshot in alto). 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 in base al nome del progetto.

Successivamente, per utilizzare le risorse Google Cloud, dovrai abilitare la fatturazione in Developers Console.

L'esecuzione di questo codelab non dovrebbe costare più di pochi dollari, ma potrebbe esserlo di più se decidi di utilizzare più risorse o se le lasci in esecuzione (consulta la sezione "Conclusioni" alla fine di questo documento). Il Calcolatore prezzi di Google Cloud è disponibile qui.

I nuovi utenti della piattaforma Google Cloud hanno diritto a una prova senza costi di$300.

Google Cloud Shell

Anche se Google Cloud può essere utilizzato 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

Dalla console di Google Cloud, fai clic sull'icona di Cloud Shell nella barra degli strumenti in alto a destra:

dbad104cef962719.png

Quindi, fai clic su Avvia Cloud Shell:

4e50db320508ac88.png

Il provisioning e la connessione all'ambiente dovrebbero richiedere solo qualche istante:

20b0aa80492144d.png

Questa macchina virtuale viene caricata con tutti gli strumenti di sviluppo necessari. Offre una home directory permanente da 5 GB e viene eseguita su Google Cloud, migliorando notevolmente le prestazioni di rete e semplificando l'autenticazione. Gran parte, se non tutto, del lavoro in questo lab può essere svolto semplicemente con un browser web o con Google Chromebook.

Una volta stabilita la connessione a Cloud Shell, dovresti vedere che hai già eseguito l'autenticazione e che 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 di Terraform Slurm

Scarica la configurazione di Slurm Terraform

Nella sessione di Cloud Shell, esegui questo comando per clonare (scaricare) il repository Git che contiene i file Terraform Slurm per Google Cloud Platform:

git clone https://github.com/SchedMD/slurm-gcp.git

Passa alla directory di configurazione del deployment di Slurm eseguendo questo comando:

cd slurm-gcp

Configura tfvars 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 di cui eseguire il deployment. Copialo in un nuovo file, che chiameremo "il file tfvars", quindi modificalo in base alle esigenze.

cd tf/example/basic
cp basic.tfvars.example basic.tfvars

Nella sessione di Cloud Shell, apri il file tfvars basic.tfvars. Puoi utilizzare il tuo editor di riga di comando preferito (vi, nano, emacs e così via) oppure utilizzare l'editor di codice della console Cloud per visualizzare i contenuti del file:

214f43bba6c917aa.png

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 ci sono diversi campi da configurare. L'unico campo che deve essere configurato è project. Tutte le altre configurazioni dell'esempio possono essere utilizzate così come sono, ma puoi modificarle in base alle tue esigenze. Per una descrizione più dettagliata delle opzioni di configurazione, vedi qui.

  • cluster_name: nome del cluster Slurm
  • project: ID progetto Google Cloud di cui verrà eseguito il deployment delle risorse
  • zone: la zona Google Cloud che conterrà il controller e le istanze 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::assegnare un IP esterno al controller Slurm?
  • disable_login_public_ips::assegnare l'IP esterno al nodo di accesso a Slurm?
  • disable_compute_login_ips: assegnare un IP esterno al nodo di accesso a Slurm?
  • suspend_time: tempo di attesa dopo che un nodo è inattivo prima di sospenderlo
  • controller_machine_type: nodo controller tipo di istanza
  • controller_image: immagine Google Cloud utilizzata per creare l'istanza del controller Slurm
  • controller_disk_type: tipo del disco di avvio dell'istanza del controller
  • controller_disk_size_gb: dimensione del disco di avvio di un'istanza controller
  • controller_labels: etichette da associare all'istanza del controller
  • controller_service_account: account di servizio da utilizzare sull'istanza del controller
  • controller_scopes: ambito di accesso dell'istanza del controller
  • cloudsql: server Google CloudSQL da utilizzare come database Slurm anziché ospitare un database sull'istanza del controller
  • server_ip: IP server Cloud SQL
  • user: nome utente Cloud SQL
  • password: password di Cloud SQL
  • db_name: nome del database Cloud SQL
  • controller_secondary_disk: 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: dimensione del disco secondario del controller
  • controller_instance_template: il modello di istanza Google Cloud da utilizzare per l'istanza del controller. Tutti i campi di computing specificati sostituiranno le proprietà del modello. Ad es. Se viene specificato controller_image, l'immagine verrà sovrascritta nel modello di istanza.
  • login_machine_type: nodo di accesso (accessibile tramite SSH) tipo di istanza
  • login_image: immagine Google Cloud utilizzata per creare l'istanza di accesso a Slurm
  • login_disk_type: tipo del disco di avvio dell'istanza di accesso
  • login_disk_size_gb: dimensione del disco di avvio dell'istanza di accesso
  • login_labels: etichette da collegare all'istanza di accesso
  • login_node_count: numero di nodi di accesso da creare
  • login_node_service_account: account di servizio da utilizzare nelle istanze di accesso
  • login_node_scopes: ambito dell'accesso dell'istanza di accesso
  • login_instance_template: il modello di istanza Google Cloud da utilizzare per l'istanza di accesso. Tutti i campi di computing specificati sostituiranno le proprietà del modello. Ad es. Se viene specificato login_image, l'immagine nel modello di istanza verrà sovrascritta.
  • network_storage: spazio di archiviazione di rete da montare su tutti i nodi. I campi verranno aggiunti direttamente a fstab. Questa operazione può essere ripetuta per altri supporti.
  • server_ip: IP server di archiviazione
  • remote_mount: nome montaggio archiviazione (nome file system)
  • local_mount: directory di montaggio locale
  • fs_type: tipo di file system (NFS, CIFS, Lustre, GCSFuse installati automaticamente)
  • mount_options::opzioni di montaggio (ad esempio default,_netdev)
  • login_network_storage: spazio di archiviazione di rete da montare sui nodi di accesso e controller. NFS, CIFS, Lustre e GCSFuse verranno installati automaticamente. Questa operazione può essere ripetuta per altri supporti.
  • server_ip: IP server di archiviazione
  • remote_mount: nome montaggio archiviazione (nome file system)
  • local_mount: directory di montaggio locale
  • fs_type: tipo di file system (NFS, CIFS, Lustre, GCSFuse installati automaticamente)
  • mount_options::opzioni di montaggio (ad es. default,_netdev)
  • compute_node_service_account: account di servizio da utilizzare nelle 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 partizione
  • machine_type: nodi di calcolo 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
  • zone: la zona Google Cloud che conterrà le risorse di questa partizione - Scopri di più
  • image: tipo di macchina del nodo immagine Compute
  • image_hyperthreads: attiva o disattiva l'hyperthreading sull'istanza
  • compute_disk_type: tipo di disco di avvio di un'istanza Compute (pd-standard, pd-ssd)
  • compute_disk_size_gb: dimensione del disco di avvio di un'istanza di computing
  • compute_labels: 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: spazio di archiviazione di rete da montare su tutti i nodi di computing nella partizione. I campi verranno aggiunti direttamente a fstab. Questa operazione può essere ripetuta per altri supporti.
  • server_ip: IP server di archiviazione
  • remote_mount: nome montaggio archiviazione (nome file system)
  • local_mount: directory di montaggio locale
  • fs_type: tipo di file system (NFS, CIFS, Lustre, GCSFuse installati automaticamente)
  • mount_options::opzione di montaggio
  • preemptible_bursting: le istanze saranno istanze prerilasciabili?
  • vpc_subnet: subnet Virtual Private Cloud in cui eseguire il deployment della partizione Slurm
  • esclusivo: abilita Slurm per allocare interi nodi ai job
  • enable_placement: abilita i criteri di posizionamento in cui le istanze si troveranno vicine l'una all'altra per una bassa latenza di rete tra le istanze.
  • regional_capacity: consente il posizionamento di un'istanza in qualsiasi zona della regione in base alla disponibilità
  • regional_policy: se è true, questo criterio consente di determinare la regione da utilizzare e le zone da non utilizzare in quella regione.
  • Instance_template: il modello di istanza Google Cloud da utilizzare per le istanze di calcolo. Tutti i campi di computing specificati sostituiranno le proprietà del modello. Ad es. Se viene specificata, l'immagine verrà sovrascritta nel modello di istanza.

Configurazione avanzata

Se vuoi, puoi scegliere di installare pacchetti e software aggiuntivi come parte del processo di deployment del cluster. Puoi installare software sul tuo cluster Slurm in diversi modi descritti nella pagina "Installazione di app in un cluster Slurm su Compute Engine" oppure personalizzando l'immagine di cui è stato eseguito il deployment da Slurm. Attualmente Slurm esegue il deployment di un'immagine VM fornita da SchedMD che si basa su Google Cloud HPC VM Image, su cui è installato Slurm.

Per utilizzare un'immagine personalizzata, creane una con una configurazione personalizzata in base all'immagine della VM SchedMD pubblica elencata nel file tfvars. Quindi, sostituisci l'URI dell'immagine specificato nel file tfvars con la tua immagine e testa la modifica.

Risoluzione dei problemi

Durante questo codelab, fai riferimento alla sezione relativa alla risoluzione dei problemi del file ReadMe del repository Slurm-Google Cloud.

I problemi più comuni riscontrati sono gli errori commessi durante la configurazione del file tfvars e le restrizioni di quota. Questo codelab è progettato per essere eseguito nell'ambito dell'allocazione della quota standard di un nuovo utente e dei 300 $di credito senza costi ricevuto da un nuovo utente. Se un tentativo di creare VM ha esito negativo, controlla il file /var/log/slurm/resume.log sul nodo controller per verificare la presenza di errori dell'API.

4. Deployment e verifica della configurazione

Esegui il deployment della configurazione

Nella sessione di Cloud Shell, esegui il comando seguente 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 di cui eseguire il deployment 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 ti chiediamo di avere 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.

d5832bdd527794ed.png

Dovresti vedere un controller e un'istanza VM di accesso elencati:

7a1fc9603758d58d.png

In Istanze VM, esamina le due istanze di macchine virtuali create da Terraform.

I nomi saranno diversi se hai modificato il campo cluster_name.

  • controller-g1
  • g1-login0

5. Accedi al cluster Slurm

Accedere al cluster Slurm

Torna alla scheda Editor di codice/Cloud Shell. Esegui questo comando per accedere all'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 sull'SSH accanto alla VM g1-login0 nella pagina Istanze VM per aprire una nuova scheda con una connessione SSH.

8c373a87d13620f7.png

Se è la prima volta che utilizzi Cloud Shell, potresti visualizzare un messaggio come quello riportato di seguito in cui ti viene chiesto 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 questo caso, inserisci Y. Se ti viene richiesto di selezionare una passphrase, lascia il campo vuoto 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 proseguire con il lab finché non viene visualizzato questo messaggio (circa 5 minuti):

*** Slurm login setup complete ***

Una volta visualizzato il messaggio riportato sopra, dovrai uscire e accedere nuovamente a g1-login0 per continuare il lab. Premi Ctrl + C per terminare l'attività.

Quindi esegui la seguente disconnessione dal comando della tua istanza:

exit

Ora, esegui di nuovo la connessione 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 nell'esempio precedente, potresti dover attendere un minuto o due prima di poterti connettere e che tutti gli aspetti della configurazione siano completati.

Tour degli strumenti dell'interfaccia a riga di comando di Slurm

Hai eseguito l'accesso al nodo di accesso a Slurm del tuo cluster. Questo è il nodo dedicato all'interazione tra utente e amministratore, alla pianificazione dei job Slurm e alle attività amministrative.

Eseguiamo un paio di comandi per introdurre la riga di comando di Slurm.

Esegui il comando sinfo per visualizzare lo stato delle risorse del nostro cluster:

sinfo

Di seguito è riportato un esempio di output di sinfo. Sinfo riporta i nodi disponibili nel cluster, lo stato di quei nodi e altre informazioni come la partizione, la disponibilità ed eventuali limiti di tempo imposti ai nodi.

PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
debug*       up   infinite     10  idle~ g1-compute-0-[0-9]

Puoi vedere i nostri 10 nodi, dettati dal valore "max_node_count" della partizione di debug di 10, sono contrassegnati come "inattivo~" (il nodo è in modalità inattivo e non allocata, pronto per essere avviato).

A questo punto, esegui il comando squeue per visualizzare lo stato della coda del cluster:

squeue

Di seguito è riportato l'output previsto della stringa. Squeue riporta lo stato della coda per un cluster. Questi dati comprendono l'ID di ogni job pianificato sul cluster, la partizione a cui è assegnato il job, il nome del job, l'utente che lo ha avviato, lo stato del job, le ore effettive di esecuzione del job e i nodi a cui è assegnato il job. Non esistono job in esecuzione, quindi il contenuto di questo comando è vuoto.

JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)

Il comando Slurm "srun" e "sbatch" vengono utilizzati per eseguire job messi in coda. "srun" esegue job paralleli e può essere utilizzato come wrapper per mpirun. "sbatch" viene utilizzato per inviare un job batch da slurm e può richiamare l'esecuzione una o più volte in configurazioni diverse. "sbatch" possono accettare script batch o possono essere utilizzate con l'opzione –wrap per eseguire l'intero job dalla riga di comando.

Eseguiamo un job per vedere Slurm in azione e ottenere 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 fai lo scale up del cluster.

Lo "sbatch" per eseguire i comandi batch e gli script di Slurm. Eseguiamo un semplice script sbatch che eseguirà "nome host" sulle nostre VM a 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 il carattere "-N" . Indica inoltre che ciascuno di questi nodi eseguirà un "nome host srun" nel comando "–wrap" .

Per impostazione predefinita, sbatch scriverà il proprio output in "slurm-%j.out" nella directory di lavoro da cui viene eseguito il comando, dove %j viene sostituito per l'ID job in base ai Pattern 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 e ospitato sul controller. In questo modo, i nodi di computing possono condividere i dati di input e di output, se lo desiderano. In un ambiente di produzione, l'archiviazione di lavoro deve essere separata dall'archiviazione /home per evitare conseguenze sulle prestazioni delle operazioni del cluster. È possibile specificare montaggi separati dell'archiviazione nel file tfvars nella sezione "network_storage" le opzioni di CPU e memoria disponibili.

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 tracciare e gestire l'esecuzione del job e le risorse. Esegui il seguente comando per visualizzare la coda dei job Slurm:

squeue

Probabilmente il job eseguito verrà visualizzato come segue:

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 è stato eseguito il provisioning di alcun nodo di computing, Slurm creerà automaticamente istanze di calcolo in base ai requisiti del job. La natura automatica di questo processo presenta due vantaggi. In primo luogo, elimina il lavoro solitamente richiesto in un cluster HPC, ovvero il provisioning manuale dei nodi, la configurazione del software, l'integrazione del nodo nel cluster e infine il deployment del job. In secondo luogo, permette agli utenti di risparmiare denaro perché viene fatto lo scale down dei nodi inattivi e inutilizzati 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 mostrati i nodi elencati in "stringa" nella colonna "alloc#" , ovvero 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 Istanze VM nella console Google Cloud per visualizzare i nodi di cui è stato appena eseguito il provisioning. Sono necessari alcuni minuti per avviare i nodi e l'esecuzione di Slurm prima che il job venga allocato ai nodi appena allocati. L'elenco delle tue istanze VM sarà presto simile al seguente:

9997efff595f1e.png

Quando i nodi eseguono il job, le istanze vengono spostate in un "alloc" , nel senso 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, il job non viene più elencato in stringa e "alloc" nodi in sinfo torneranno allo stato "inattivo" stato. Esegui "squeue" periodicamente fino al completamento del job, dopo uno o due minuti.

Il file di output slurm-%j.out sarà stato scritto nella cartella /home NFS-shared e conterrà i nomi host. Apri o contrassegna il file di output (in genere slurm-2.out), il cui contenuto conterrà:

g1-compute-0-0
g1-compute-0-1

Ottimo lavoro, hai eseguito un job e hai fatto lo scale up del tuo cluster Slurm!

7. Esegui un job MPI

Ora eseguiamo un job MPI tra i nodi. Una volta effettuato l'accesso a g1-login0, usa 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

Useremo l'espressione "mpicc" per compilare il codice MPI C. Esegui questo comando:

mpicc mpi_hello_world.c -o mpi_hello_world

Questo compila il nostro codice C in codice della macchina in modo da poter eseguire il codice nel nostro cluster tramite Slurm.

Dopodiché, utilizza il tuo editor di testo preferito per creare uno script batch chiamato "helloworld_batch":

vi helloworld_batch

Digita i per attivare la modalità di inserimento di vi.

Copia e incolla il testo seguente 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. Quindi, lo script definisce prima le opzioni di Slurm con "#SBATCH" linee. Il nome del job è definito come "hello_world".

Il file di output è impostato come "hello_world_%j.out" dove %j viene sostituito per l'ID job in base ai pattern dei nomi file di Slurm. Questo file di output viene scritto nella directory da cui viene eseguito lo script sbatch. Nel nostro esempio questa è la cartella /home dell'utente, che è un file system condiviso basato su NFS. In questo modo, i nodi di computing possono condividere i dati di input e di output, se lo desiderano. In un ambiente di produzione, l'archiviazione di lavoro deve essere separata dall'archiviazione /home per evitare conseguenze 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 modo 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 pianificato, ad esempio:

Submitted batch job 3

Il comando hostname verrà eseguito su due nodi, con un'attività per nodo, e verrà stampato l'output nel file hello_world-3.out.

Poiché abbiamo già eseguito il provisioning di due nodi, questo job verrà eseguito rapidamente.

Monitora la coda finché il job non viene completato e non è più in elenco:

squeue

Dopo aver completato o creato un gatto il file hello_world-3.out, conferma 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 essere stati inattivi per 5 minuti (configurabile con il campo suspended_time di YAML o con il campo SospendiTime di slurm.conf), i nodi di computing di cui è stato eseguito il provisioning dinamico verranno allocati per rilasciare risorse. Puoi verificarlo eseguendo periodicamente sinfo e osservando che la dimensione del cluster torna a 0:

PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
debug*       up   infinite     10  idle~ g1-compute-0-[0-9]

Prova ad avviare più istanze, fino al limite consentito nella regione in cui hai eseguito il deployment del cluster, ed esegui diverse applicazioni MPI.

8. Conclusione

Complimenti, hai creato un cluster Slurm sulla piattaforma Google Cloud e utilizzato le sue ultime funzionalità per scalare automaticamente il cluster in modo da soddisfare la domanda dei carichi di lavoro. Puoi utilizzare questo modello per eseguire qualsiasi varietà di job e scala fino a centinaia di istanze in pochi minuti richiedendo semplicemente i nodi in Slurm.

Se vuoi continuare a imparare a utilizzare Slurm su Google Cloud, assicurati di continuare con il " Building Federated HPC Clusters with Slurm" (Creazione di cluster HPC federati con Slurm) codelab. Questo codelab ti guiderà nella configurazione di due cluster Slurm federati nel cloud, per rappresentare una federazione multi-cluster, on-premise o nel cloud.

Stai creando qualcosa di interessante utilizzando le nuove funzionalità native di Google Cloud di Slurm? Domande? Hai un suggerimento per una funzione? Contatta oggi stesso il team di Google Cloud tramite il sito web delle soluzioni di computing ad alte prestazioni di Google Cloud o chatta con noi nel sito web di Google Cloud e Gruppo di discussione Slurm!

Esegui la pulizia del deployment Terraform

Disconnessione dal nodo slurm:

exit

Consenti lo scale down dei nodi con scalabilità automatica prima di eliminare il deployment. Puoi anche eliminare questi nodi manualmente eseguendo "gcloud compute instances delete <Instance Name>" per ogni istanza oppure usando la GUI della console per selezionare più nodi e facendo clic su "Elimina".

Al termine, puoi eseguire facilmente la pulizia del deployment Terraform eseguendo il comando seguente 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 ti viene richiesto, digita yes per continuare. Questa operazione può richiedere diversi minuti, ti chiediamo di avere pazienza.

Elimina il progetto

Per fare la pulizia, basta eliminare il nostro progetto.

  • Nel menu di navigazione, seleziona IAM e. Amministratore
  • 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 Google Cloud con Terraform.
  • Come eseguire un job utilizzando Slurm su Google Cloud.
  • Come eseguire query sulle informazioni del cluster e monitorare i job in esecuzione in Slurm.
  • Come scalare automaticamente i nodi con Slurm su Google Cloud per soddisfare parametri e requisiti specifici del job.
  • Come compilare ed eseguire applicazioni MPI su Slurm in Google Cloud.

Trova supporto Slurm

Se hai bisogno di assistenza per l'utilizzo di queste integrazioni in ambienti di test o di produzione, contatta direttamente SchedMD utilizzando la relativa pagina di contatto qui: https://www.schedmd.com/contact.php

Puoi anche utilizzare le guide alla risoluzione dei problemi disponibili:

Infine, puoi anche pubblicare la tua domanda nel team Gruppo di discussione su 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. Il completamento del feedback richiede meno di 5 minuti. Grazie.