1. Übersicht
Willkommen beim Google-Codelab zum Ausführen eines Slurm-Clusters in der Google Cloud Platform. Am Ende dieses Codelabs sollten Sie fundierte Kenntnisse über die einfache Bereitstellung und Ausführung eines automatisch skalierenden Slurm-Clusters haben.
Google Cloud hat sich mit SchedMD zusammengetan, um eine Reihe von Tools zu veröffentlichen, die das Starten des Slurm-Arbeitslastmanagers in Compute Engine erleichtern und es ermöglichen, Ihren vorhandenen Cluster dynamisch zu erweitern, wenn Sie zusätzliche Ressourcen benötigen. Diese Integration wurde von den Experten von SchedMD gemäß den Slurm-Best Practices entwickelt.
Wenn Sie die Integrationen von Slurm in Google Cloud verwenden möchten oder Fragen haben, sollten Sie unserer Google Cloud & Slurm-Community-Diskussionsgruppe beitreten.
Informationen zu Slurm
Einfaches Architekturdiagramm eines eigenständigen Slurm-Clusters in Google Cloud.
Slurm ist einer der führenden Arbeitslastmanager für HPC-Cluster weltweit. Slurm ist ein Open-Source-, fehlertolerantes und hoch skalierbares System für die Arbeitslastverwaltung und Jobplanung für kleine und große Linux-Cluster. Für den Betrieb von Slurm sind keine Kerneländerungen erforderlich und es ist relativ in sich geschlossen. Als Cluster-Arbeitslastmanager hat Slurm drei Hauptfunktionen:
- Nutzern wird für einen bestimmten Zeitraum exklusiver oder nicht exklusiver Zugriff auf Ressourcen (Rechenknoten) gewährt, damit sie Aufgaben ausführen können.
- Sie bietet ein Framework zum Starten, Ausführen und Überwachen von Aufgaben (normalerweise ein paralleler Job) auf den zugewiesenen Knoten.
- Sie schlichtet Konflikte um Ressourcen, indem sie eine Warteschlange mit ausstehenden Aufgaben verwaltet.
Lerninhalte
- Slurm-Cluster mit Terraform einrichten
- Job mit SLURM ausführen
- Clusterinformationen abfragen und ausgeführte Jobs in SLURM überwachen
- Knoten entsprechend den Jobparametern und Anforderungen automatisch skalieren
- Wo Sie Hilfe zu Slurm erhalten
Vorbereitung
- Google Cloud Platform-Konto und ein Projekt mit Abrechnung
- Grundlegende Linux-Kenntnisse
2. Einrichtung
Umgebung zum selbstbestimmten Lernen einrichten
Projekt erstellen
Wenn Sie noch kein Google-Konto (Gmail oder G Suite) haben, müssen Sie eines erstellen. Melden Sie sich in der Google Cloud Console ( console.cloud.google.com) an und öffnen Sie die Seite „Ressourcen verwalten“:
Klicken Sie auf Projekt erstellen.
Geben Sie einen Projektnamen ein. Merken Sie sich die Projekt-ID (im Screenshot oben rot hervorgehoben). Die Projekt-ID muss für alle Google Cloud-Projekte ein eindeutiger Name sein. Wenn Ihr Projektname nicht eindeutig ist, wird in Google Cloud eine zufällige Projekt-ID auf Grundlage des Projektnamens generiert.
Als Nächstes müssen Sie in der Developers Console die Abrechnung aktivieren, um Google Cloud-Ressourcen nutzen zu können.
Dieses Codelab sollte Sie nicht mehr als ein paar Dollar kosten, aber es könnte mehr sein, wenn Sie sich für mehr Ressourcen entscheiden oder wenn Sie sie laufen lassen (siehe Abschnitt „Zusammenfassung“ am Ende dieses Dokuments). Den Google Cloud Platform-Preisrechner finden Sie hier.
Neuen Nutzern der Google Cloud Platform steht eine kostenlose Testversion mit einem Guthaben von 300$ zur Verfügung.
Google Cloud Shell
Während Sie Google Cloud von Ihrem Laptop aus per Fernzugriff nutzen können, wird in diesem Codelab Google Cloud Shell verwendet, eine Befehlszeilenumgebung, die in der Cloud ausgeführt wird.
Google Cloud Shell starten
Klicken Sie in der GCP Console oben rechts in der Symbolleiste auf das Cloud Shell-Symbol:
Klicken Sie dann auf Cloud Shell starten:
Die Bereitstellung und Verbindung mit der Umgebung dauert nur einen Moment:
Diese virtuelle Maschine verfügt über sämtliche Entwicklertools, die Sie benötigen. Sie bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und läuft auf Google Cloud, was die Netzwerkleistung erheblich verbessert und die Authentifizierung vereinfacht. Die meisten, wenn nicht sogar alle Aufgaben in diesem Lab können mit einem Webbrowser oder einem Google Chromebook erledigt werden.
Sobald die Verbindung mit der Cloud Shell hergestellt ist, sehen Sie, dass Sie bereits authentifiziert sind und für das Projekt schon Ihre PROJECT_ID eingestellt ist:
$ gcloud auth list
Befehlsausgabe:
Credentialed accounts:
- <myaccount>@<mydomain>.com (active)
$ gcloud config list project
Befehlsausgabe:
[core]
project = <PROJECT_ID>
Wenn die Projekt-ID nicht richtig festgelegt ist, können Sie sie mit diesem Befehl festlegen:
$ gcloud config set project <PROJECT_ID>
Befehlsausgabe:
Updated property [core/project].
3. Slurm-Terraform-Konfiguration vorbereiten und prüfen
Slurm-Terraform-Konfiguration herunterladen
Führen Sie in der Cloud Shell-Sitzung den folgenden Befehl aus, um das Git-Repository zu klonen (herunterzuladen), das die Terraform-Dateien für Slurm für Google Cloud enthält:
git clone https://github.com/SchedMD/slurm-gcp.git
Wechseln Sie mit dem folgenden Befehl in das Verzeichnis mit der Slurm-Bereitstellungskonfiguration:
cd slurm-gcp
Slurm-Terraform-tfvars konfigurieren
Die Datei „basic.tfvars.example“ enthält Details zur Konfiguration des Deployments, einschließlich des Netzwerks, der Instanzen und des zu bereitstellenden Speichers. Kopieren Sie sie in eine neue Datei, die wir als „tfvars-Datei“ bezeichnen, und bearbeiten Sie sie nach Bedarf.
cd tf/example/basic cp basic.tfvars.example basic.tfvars
Öffnen Sie in der Cloud Shell-Sitzung die tfvars-Datei basic.tfvars. Sie können entweder Ihren bevorzugten Befehlszeileneditor (vi, nano, emacs usw.) oder den Code-Editor der Cloud Console verwenden, um den Dateiinhalt aufzurufen:
Sehen Sie sich den Inhalt der TFVARS-Datei an.
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"
]
Diese tfvars-Datei enthält mehrere Felder, die konfiguriert werden müssen. Das einzige Feld, das konfiguriert werden muss, ist project. Alle anderen Konfigurationen im Beispiel können unverändert verwendet werden. Sie sollten sie jedoch bei Bedarf an Ihre Situation anpassen. Eine detailliertere Beschreibung der Konfigurationsoptionen finden Sie hier.
- cluster_name::Name des Slurm-Clusters
- project:Google Cloud-Projekt-ID für den Bereitstellungsort der Ressourcen
- zone:Google Cloud-Zone, die die Controller- und Anmeldeinstanzen dieses Clusters enthält – Weitere Informationen
- network_name: : Das Virtual Private Cloud-Netzwerk, in dem der Slurm-Cluster bereitgestellt werden soll
- subnetwork_name: : Virtual Private Cloud-Subnetzwerk, in dem das Slurm-Cluster bereitgestellt werden soll
- shared_vpc_host_project: Freigegebenes VPC-Netzwerk, in dem der Slurm-Cluster bereitgestellt werden soll
- disable_controller_public_ips::Soll dem Slurm-Controller eine externe IP-Adresse zugewiesen werden?
- disable_login_public_ips::Externe IP-Adresse dem Slurm-Anmeldeknoten zuweisen?
- disable_compute_login_ips::Externe IP-Adresse dem Slurm-Anmeldeknoten zuweisen?
- suspend_time::Wartezeit nach Inaktivität eines Knotens, bevor der Knoten ausgesetzt wird
- controller_machine_type::Instanztyp des Controller-Knotens
- controller_image::GCP-Image, das zum Erstellen der Slurm-Controller-Instanz verwendet wird
- controller_disk_type::Typ des Bootlaufwerks der Controller-Instanz
- controller_disk_size_gb::Größe des Bootlaufwerks einer Controller-Instanz
- controller_labels::Label(s), die an die Controller-Instanz angehängt werden sollen
- controller_service_account: : Dienstkonto, das auf der Controller-Instanz verwendet werden soll
- controller_scopes: : Zugriffsbereich der Controller-Instanz
- cloudsql : Google Cloud SQL-Server, der anstelle einer Datenbank auf der Controller-Instanz als Slurm-Datenbank verwendet werden soll
- server_ip::Cloud SQL-Server-IP-Adresse
- user:Cloud SQL-Nutzername
- password:Cloud SQL-Passwort
- db_name::CloudSQL-Datenbankname
- controller_secondary_disk::Soll ein sekundäres Laufwerk für den NFS-Serverspeicher hinzugefügt werden?
- controller_secondary_disk_type::Typ des sekundären Controller-Laufwerks
- controller_secondary_disk_size_gb::Größe des sekundären Controllerlaufwerks
- controller_instance_template::Die GCP-Instanzvorlage, die für die Controller-Instanz verwendet werden soll. Alle angegebenen Berechnungsfelder überschreiben die Vorlageneigenschaften. Wenn beispielsweise „controller_image“ angegeben ist, wird das Image in der Instanzvorlage überschrieben.
- login_machine_type::Instanztyp des Login-Knotens (per SSH zugänglich)
- login_image::GCP-Image, das zum Erstellen der Slurm-Anmeldeinstanz verwendet wird
- login_disk_type::Typ des Bootlaufwerks der Anmeldeinstanz
- login_disk_size_gb::Größe des Bootlaufwerks der Anmeldeinstanz
- login_labels: Label, die an die Anmeldeinstanz angehängt werden sollen
- login_node_count::Anzahl der zu erstellenden Log‑in-Knoten
- login_node_service_account: : Dienstkonto, das auf den Anmeldeinstanzen verwendet werden soll.
- login_node_scopes: : Zugriffsbereich der Log-in-Instanz
- login_instance_template::Die GCP-Instanzvorlage, die für die Anmeldeinstanz verwendet werden soll. Alle angegebenen Berechnungsfelder überschreiben die Vorlageneigenschaften. Wenn beispielsweise „login_image“ angegeben ist, wird das Image in der Instanzvorlage überschrieben.
- network_storage::Netzwerkspeicher, der auf allen Knoten bereitgestellt werden soll. Felder werden direkt zu fstab hinzugefügt. Kann für zusätzliche Bereitstellungen wiederholt werden.
- server_ip::IP-Adresse des Speicherservers
- remote_mount::Name des Speichermounts (Dateisystemname)
- local_mount::Lokales Bereitstellungsverzeichnis
- fs_type::Dateisystemtyp (NFS, CIFS, Lustre, GCSFuse wird automatisch installiert)
- mount_options::Bereitstellungsoptionen (z.B. defaults,_netdev)
- login_network_storage::Netzwerkspeicher, der beim Anmelden auf Login- und Controllerknoten bereitgestellt werden soll. NFS, CIFS, Lustre und GCSFuse werden automatisch installiert. Kann für zusätzliche Bereitstellungen wiederholt werden.
- server_ip::IP-Adresse des Speicherservers
- remote_mount::Name des Speichermounts (Dateisystemname)
- local_mount::Lokales Bereitstellungsverzeichnis
- fs_type::Dateisystemtyp (NFS, CIFS, Lustre, GCSFuse wird automatisch installiert)
- mount_options::Bereitstellungsoptionen (z.B. defaults,_netdev)
- compute_node_service_account: : Dienstkonto, das auf den Compute-Instanzen verwendet werden soll
- compute_node_scopes: : Zugriffsbereich der Compute-Instanzen
- partitions:Slurm-Partitionskonfiguration. Kann für zusätzliche Partitionen wiederholt werden.
- name:Partitionsname
- machine_type::Instanztyp des/der Rechenknoten
- static_node_count::Anzahl der ständig aktiven Rechenknoten
- max_node_count::Maximale Anzahl der zulässigen Rechenknoten insgesamt – maximal 64.000
- zone:Google Cloud-Zone, die die Ressourcen dieser Partition enthält – Weitere Informationen
- image:Compute-Image-Knotenmaschinentyp
- image_hyperthreads::Hyperthreading auf der Instanz aktivieren oder deaktivieren
- compute_disk_type: Typ des Bootlaufwerks einer Compute-Instanz (pd-standard, pd-ssd)
- compute_disk_size_gb::Größe des Bootlaufwerks einer Compute-Instanz
- compute_labels::Label(s), die an die Compute-Instanz angehängt werden sollen
- cpu_platform::Mindest-CPU-Plattform, die für alle Rechenknoten erforderlich ist
- gpu_count::Anzahl der GPUs, die an jede Instanz in der Partition angehängt werden sollen
- gpu_type: GPU-Typ, der an die Instanzen der Partition angehängt werden soll
- network_storage::Netzwerkspeicher, der auf allen Rechenknoten in der Partition bereitgestellt werden soll. Felder werden direkt zu fstab hinzugefügt. Kann für zusätzliche Bereitstellungen wiederholt werden.
- server_ip::IP-Adresse des Speicherservers
- remote_mount::Name des Speichermounts (Dateisystemname)
- local_mount::Lokales Bereitstellungsverzeichnis
- fs_type::Dateisystemtyp (NFS, CIFS, Lustre, GCSFuse wird automatisch installiert)
- mount_options::Bereitstellungsoption
- preemptible_bursting::Sollen die Instanzen Instanzen auf Abruf sein?
- vpc_subnet: : VPC-Subnetz (Virtual Private Cloud), in dem die Slurm-Partition bereitgestellt werden soll
- exclusive:Slurm kann ganze Knoten für Jobs zuweisen.
- enable_placement::Aktivieren Sie Platzierungsrichtlinien, bei denen sich Instanzen nahe beieinander befinden, um eine niedrige Netzwerklatenz zwischen den Instanzen zu erreichen.
- regional_capacity::Ermöglicht, dass eine Instanz je nach Verfügbarkeit in einer beliebigen Zone in der Region platziert wird.
- regional_policy::Wenn „regional_capacity“ auf „true“ gesetzt ist, wird mit dieser Richtlinie festgelegt, welche Region verwendet werden soll und welche Zonen in dieser Region nicht verwendet werden sollen.
- Instance_template::Die GCP-Instanzvorlage, die für Compute-Instanzen verwendet werden soll. Alle angegebenen Berechnungsfelder überschreiben die Vorlageneigenschaften. Wenn beispielsweise ein Image angegeben ist, wird das Image in der Instanzvorlage überschrieben.
Erweiterte Konfiguration
Bei Bedarf können Sie im Rahmen der Clusterbereitstellung zusätzliche Pakete und Software installieren. Sie können Software auf Ihrem Slurm-Cluster installieren. Dazu haben Sie mehrere Möglichkeiten, die in unserem Artikel „Anwendungen in einem Slurm-Cluster in Compute Engine installieren“ beschrieben werden. Alternativ können Sie das von Slurm bereitgestellte Image anpassen. Derzeit wird von Slurm ein von SchedMD bereitgestelltes VM-Image bereitgestellt, das auf dem Google Cloud-HPC-VM-Image basiert und auf dem Slurm installiert ist.
Wenn Sie Ihr eigenes Image verwenden möchten, erstellen Sie ein Image mit Ihrer eigenen Konfiguration basierend auf dem öffentlichen SchedMD-VM-Image, das in der tfvars-Datei aufgeführt ist. Ersetzen Sie als Nächstes den in der tfvars-Datei angegebenen Bild-URI durch Ihr eigenes Bild und testen Sie die Änderung.
Fehlerbehebung
In diesem Codelab finden Sie im README-Dokument des Slurm-GCP-Repositorys einen Abschnitt zur Fehlerbehebung.
Die häufigsten Probleme sind Fehler bei der Konfiguration der TFVARS-Datei und Kontingentbeschränkungen. Dieses Codelab ist so konzipiert, dass es innerhalb des Standardkontingents eines neuen Nutzers und innerhalb des Startguthabens von 300 $, das ein neuer Nutzer erhält, ausgeführt werden kann. Wenn der Versuch, VMs zu erstellen, fehlschlägt, prüfen Sie auf dem Controllerknoten die Datei „/var/log/slurm/resume.log“ auf API-Fehler.
4. Konfiguration bereitstellen und prüfen
Konfiguration bereitstellen
Führen Sie in der Cloud Shell-Sitzung den folgenden Befehl im Ordner slurm-gcp/tf/example aus:
terraform init terraform apply -var-file=basic.tfvars
Sie werden aufgefordert, die beschriebenen Aktionen zu akzeptieren, basierend auf den festgelegten Konfigurationen. Geben Sie yes ein, um mit der Bereitstellung zu beginnen. Sie können die bereitzustellende Konfiguration auch mit dem Befehl „terraform plan“ aufrufen.
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
Der Vorgang kann einige Minuten dauern. Bitte haben Sie etwas Geduld.
Nach Abschluss der Bereitstellung sehen Sie eine Ausgabe ähnlich der folgenden:
Apply complete! Resources: 8 added, 0 changed, 0 destroyed.
Outputs:
controller_network_ips = [
[
"10.0.0.2",
],
]
login_network_ips = [
[
"10.0.0.3",
],
]
Erstellung von VM-Instanzen prüfen
Öffnen Sie das Navigationsmenü und wählen Sie Compute Engine > VM-Instanzen aus.
Sie sollten einen Controller und eine Anmelde-VM-Instanz sehen:
Sehen Sie sich unter VM-Instanzen die beiden VM-Instanzen an, die von Terraform erstellt wurden.
Die Namen sind unterschiedlich, wenn Sie das Feld cluster_name geändert haben.
- g1-controller
- g1-login0
5. Beim Slurm-Cluster anmelden
Auf den Slurm-Cluster zugreifen
Kehren Sie zum Tab mit dem Code-Editor/Cloud Shell zurück. Führen Sie den folgenden Befehl aus, um sich in Ihrer Instanz anzumelden. Ersetzen Sie dabei <ZONE> durch die Zone des Knotens „g1-login0“ (sollte us-central1-b sein):
gcloud compute ssh g1-login0 --zone=<ZONE>
Mit diesem Befehl werden Sie bei der virtuellen Maschine g1-login0 angemeldet.
Eine weitere Methode, um einfach auf den Anmeldeknoten zuzugreifen, besteht darin, auf der Seite „VM-Instanzen“ neben der VM „g1-login0“ auf die Schaltfläche „SSH“ zu klicken, um einen neuen Tab mit einer SSH-Verbindung zu öffnen.
Wenn Sie Cloud Shell zum ersten Mal verwenden, wird möglicherweise eine Meldung wie die folgende angezeigt, in der Sie aufgefordert werden, einen SSH-Schlüssel zu erstellen:
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)?
Wenn ja, geben Sie Y ein. Wenn Sie aufgefordert werden, eine Passphrase auszuwählen, lassen Sie das Feld leer, indem Sie zweimal die Eingabetaste drücken.
Wenn bei der Anmeldung die folgende Meldung angezeigt wird:
*** Slurm is currently being configured in the background. *** A terminal broadcast will announce when installation and configuration is complete.
Warten Sie, bis diese Meldung angezeigt wird, bevor Sie mit dem Lab fortfahren (ca. 5 Minuten):
*** Slurm login setup complete ***
Wenn Sie die oben genannte Meldung sehen, müssen Sie sich ab- und wieder bei g1-login0 anmelden, um mit dem Lab fortzufahren. Drücken Sie dazu STRG + C, um den Vorgang zu beenden.
Führen Sie dann den folgenden Befehl aus, um sich von Ihrer Instanz abzumelden:
exit
Stellen Sie jetzt die Verbindung zu Ihrer Anmelde-VM wieder her. Führen Sie den folgenden Befehl aus, um sich in Ihrer Instanz anzumelden. Ersetzen Sie <ZONE> durch die Zone des Knotens „g1-login0“:
gcloud compute ssh g1-login0 --zone=<ZONE>
Wie oben beschrieben kann es ein bis zwei Minuten dauern, bis Sie eine Verbindung herstellen können und die Einrichtung abgeschlossen ist.
Übersicht über die Slurm-Befehlszeilentools
Sie sind jetzt im Slurm-Anmeldeknoten Ihres Clusters angemeldet. Dieser Knoten ist für die Interaktion zwischen Nutzern und Administratoren, die Planung von Slurm-Jobs und administrative Aktivitäten vorgesehen.
Wir führen einige Befehle aus, um Ihnen die Slurm-Befehlszeile vorzustellen.
Führen Sie den Befehl sinfo aus, um den Status der Ressourcen unseres Clusters aufzurufen:
sinfo
Unten sehen Sie eine Beispielausgabe von sinfo. sinfo meldet die im Cluster verfügbaren Knoten, den Status dieser Knoten und andere Informationen wie die Partition, die Verfügbarkeit und alle Zeitbeschränkungen, die für diese Knoten gelten.
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST debug* up infinite 10 idle~ g1-compute-0-[0-9]
Die 10 Knoten, die durch den „max_node_count“-Wert von 10 der Debug-Partition vorgegeben sind, sind als „idle~“ markiert. Das bedeutet, dass sich der Knoten im Leerlauf und nicht zugewiesenen Modus befindet und bereit ist, hochgefahren zu werden.
Führen Sie als Nächstes den Befehl squeue aus, um den Status der Warteschlange unseres Clusters aufzurufen:
squeue
Die erwartete Ausgabe von squeue wird unten angezeigt. squeue gibt den Status der Warteschlange für einen Cluster aus. Dazu gehören die Job-ID jedes im Cluster geplanten Jobs, die Partition, der der Job zugewiesen ist, der Name des Jobs, der Nutzer, der den Job gestartet hat, der Status des Jobs, die Wanduhrzeit, die der Job ausgeführt wurde, und die Knoten, die dem Job zugewiesen sind. Es werden keine Jobs ausgeführt, daher ist der Inhalt dieses Befehls leer.
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
Die Slurm-Befehle „srun“ und „sbatch“ werden verwendet, um Jobs auszuführen, die in die Warteschlange gestellt werden. Mit „srun“ werden parallele Jobs ausgeführt. Es kann als Wrapper für „mpirun“ verwendet werden. Mit „sbatch“ wird ein Batchjob an Slurm gesendet. „srun“ kann einmal oder mehrmals in verschiedenen Konfigurationen aufgerufen werden. „sbatch“ kann Batchskripts verwenden oder mit der Option „–wrap“ verwendet werden, um den gesamten Job über die Befehlszeile auszuführen.
Wir führen jetzt einen Job aus, damit wir Slurm in Aktion sehen und einen Job in unsere Warteschlange aufnehmen können.
6. Slurm-Job ausführen und Cluster skalieren
Slurm-Job ausführen und Cluster skalieren
Nachdem unser Slurm-Cluster nun ausgeführt wird, führen wir einen Job aus und skalieren den Cluster hoch.
Mit dem Befehl „sbatch“ werden Slurm-Batchbefehle und ‑Skripts ausgeführt. Wir führen ein einfaches sbatch-Skript aus, mit dem „hostname“ auf unseren automatisch skalierten VMs ausgeführt wird.
Führen Sie den folgenden Befehl aus, während Sie in g1-login0 angemeldet sind:
sbatch -N2 --wrap="srun hostname"
Mit diesem Befehl wird der Slurm-Batchbefehl ausgeführt. Sie gibt an, dass sbatch mit der Option „-N“ zwei Knoten ausführt. Außerdem wird angegeben, dass auf jedem dieser Knoten der Befehl „srun hostname“ in der Option „–wrap“ ausgeführt wird.
Standardmäßig schreibt „sbatch“ die Ausgabe in „slurm-%j.out“ im Arbeitsverzeichnis, in dem der Befehl ausgeführt wird. Dabei wird %j gemäß den Slurm-Dateinamensmustern durch die Job-ID ersetzt. In unserem Beispiel wird „sbatch“ über den Ordner „/home“ des Nutzers ausgeführt. Das ist standardmäßig ein NFS-basiertes freigegebenes Dateisystem, das auf dem Controller gehostet wird. Dadurch können Rechenknoten bei Bedarf Ein- und Ausgabedaten gemeinsam nutzen. In einer Produktionsumgebung sollte der Arbeitsspeicher vom /home-Speicher getrennt sein, um Leistungseinbußen bei den Clusteroperationen zu vermeiden. Separate Speichereinbindungen können in der tfvars-Datei in den Optionen „network_storage“ angegeben werden.
Nachdem Sie das sbatch-Skript über die sbatch-Befehlszeile ausgeführt haben, wird eine Job-ID für den geplanten Job zurückgegeben, z. B.:
Submitted batch job 2
Mit der vom sbatch-Befehl zurückgegebenen Job-ID können wir die Jobausführung und die Ressourcen verfolgen und verwalten. Führen Sie den folgenden Befehl aus, um die Slurm-Jobwarteschlange aufzurufen:
squeue
Der ausgeführte Job wird wahrscheinlich wie unten aufgeführt:
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]
Da keine Rechenknoten bereitgestellt wurden, erstellt Slurm automatisch Recheninstanzen entsprechend den Jobanforderungen. Die Automatisierung dieses Prozesses hat zwei Vorteile. Erstens entfällt die Arbeit, die normalerweise in einem HPC-Cluster erforderlich ist, um Knoten manuell bereitzustellen, die Software zu konfigurieren, den Knoten in den Cluster zu integrieren und dann den Job bereitzustellen. Zweitens können Nutzer dadurch Geld sparen, da inaktive, nicht verwendete Knoten herunterskaliert werden, bis die Mindestanzahl von Knoten ausgeführt wird.
Sie können den Befehl sinfo ausführen, um den Slurm-Cluster zu sehen, der hochgefahren wird:
sinfo
Dadurch werden die in squeue aufgeführten Knoten im Status „alloc#“ angezeigt. Das bedeutet, dass die Knoten zugewiesen werden:
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]
Sie können auch den Bereich „VM-Instanzen“ in der Google Cloud Console aufrufen, um die neu bereitgestellten Knoten anzusehen. Es dauert einige Minuten, bis die Knoten hochgefahren und Slurm ausgeführt werden, bevor der Job den neu zugewiesenen Knoten zugewiesen wird. Ihre Liste der VM-Instanzen sieht dann in etwa so aus:
Sobald die Knoten den Job ausführen, wechseln die Instanzen in den Status „alloc“ (zugewiesen). Das bedeutet, dass die Jobs einem Job zugewiesen sind:
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]
Wenn ein Job abgeschlossen ist, wird er nicht mehr in squeue aufgeführt und die „alloc“-Knoten in sinfo kehren in den Status „idle“ zurück. Führen Sie „squeue“ regelmäßig aus, bis der Job nach ein bis zwei Minuten abgeschlossen ist.
Die Ausgabedatei „slurm-%j.out“ wurde in Ihren NFS-freigegebenen /home-Ordner geschrieben und enthält die Hostnamen. Öffnen Sie die Ausgabedatei (in der Regel „slurm-2.out“) oder geben Sie ihren Inhalt aus. Sie enthält Folgendes:
g1-compute-0-0 g1-compute-0-1
Gut gemacht! Sie haben einen Job ausgeführt und Ihren Slurm-Cluster skaliert.
7. MPI-Job ausführen
Führen wir nun einen MPI-Job auf unseren Knoten aus. Laden Sie mit wget ein MPI-Programm herunter, das in der Programmiersprache C geschrieben wurde, während Sie in g1-login0 angemeldet sind:
wget https://raw.githubusercontent.com/mpitutorial/mpitutorial/gh-pages/tutorials/mpi-hello-world/code/mpi_hello_world.c
Wenn Sie OpenMPI-Tools verwenden möchten, müssen Sie die OpenMPI-Module mit dem folgenden Befehl laden:
module load openmpi
Wir verwenden das Tool „mpicc“, um den MPI-C-Code zu kompilieren. Führen Sie folgenden Befehl aus:
mpicc mpi_hello_world.c -o mpi_hello_world
Dadurch wird unser C-Code in Maschinencode kompiliert, sodass wir den Code über Slurm in unserem Cluster ausführen können.
Erstellen Sie als Nächstes mit Ihrem bevorzugten Texteditor ein sbatch-Skript mit dem Namen helloworld_batch:
vi helloworld_batch
Geben Sie i ein, um den vi-Einfügemodus zu aktivieren.
Kopieren Sie den folgenden Text und fügen Sie ihn in die Datei ein, um ein einfaches sbatch-Skript zu erstellen:
#!/bin/bash # #SBATCH --job-name=hello_world #SBATCH --output=hello_world-%j.out # #SBATCH --nodes=2 srun mpi_hello_world
Speichern Sie den Code und beenden Sie den Editor, indem Sie die Esc-Taste drücken und „:wq“ ohne Anführungszeichen eingeben.
In diesem Skript werden die Slurm-Batchausführungsumgebung und die Aufgaben definiert. Zuerst wird die Ausführungsumgebung als „bash“ definiert. Als Nächstes werden die Slurm-Optionen mit den Zeilen „#SBATCH“ definiert. Der Jobname ist „hello_world“.
Die Ausgabedatei wird als „hello_world_%j.out“ festgelegt, wobei %j gemäß den Slurm-Dateinamenmustern durch die Job-ID ersetzt wird. Diese Ausgabedatei wird in das Verzeichnis geschrieben, in dem das sbatch-Skript ausgeführt wird. In unserem Beispiel ist das der Ordner „/home“ des Nutzers, der ein NFS-basiertes freigegebenes Dateisystem ist. Dadurch können Rechenknoten bei Bedarf Ein- und Ausgabedaten gemeinsam nutzen. In einer Produktionsumgebung sollte der Arbeitsspeicher vom /home-Speicher getrennt sein, um Leistungseinbußen bei den Clusteroperationen zu vermeiden.
Schließlich wird die Anzahl der Knoten, auf denen dieses Skript ausgeführt werden soll, als „2“ definiert.
Nachdem die Optionen definiert wurden, werden die ausführbaren Befehle bereitgestellt. Mit diesem Skript wird der Code „mpi_hello_world“ parallel mit dem Befehl „srun“ ausgeführt, der ein direkter Ersatz für den Befehl „mpirun“ ist.
Führen Sie das sbatch-Skript dann mit der sbatch-Befehlszeile aus:
sbatch helloworld_batch
Wenn Sie „sbatch“ ausführen, wird eine Job-ID für den geplanten Job zurückgegeben, z. B.:
Submitted batch job 3
Dadurch wird der Befehl hostname auf zwei Knoten mit einer Aufgabe pro Knoten ausgeführt und die Ausgabe in der Datei hello_world-3.out ausgegeben.
Da wir bereits zwei Knoten bereitgestellt haben, wird dieser Job schnell ausgeführt.
Behalten Sie squeue im Blick, bis der Job abgeschlossen ist und nicht mehr aufgeführt wird:
squeue
Öffnen Sie nach Abschluss die Datei hello_world-3.out oder geben Sie ihren Inhalt aus und bestätigen Sie, dass sie auf g1-compute-0-[0-1] ausgeführt wurde:
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
Nach 5 Minuten Inaktivität (konfigurierbar mit dem Feld „suspend_time“ in der YAML-Datei oder dem Feld „SuspendTime“ in „slurm.conf“) werden die dynamisch bereitgestellten Rechenknoten freigegeben, um Ressourcen freizugeben. Sie können dies überprüfen, indem Sie „sinfo“ regelmäßig ausführen und beobachten, wie die Clustergröße auf 0 zurückfällt:
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST debug* up infinite 10 idle~ g1-compute-0-[0-9]
Versuchen Sie, mehr Instanzen zu starten, bis zu Ihrem Kontingent in der Region, in der Sie den Cluster bereitgestellt haben, und führen Sie verschiedene MPI-Anwendungen aus.
8. Fazit
Herzlichen Glückwunsch! Sie haben einen Slurm-Cluster in der Google Cloud Platform erstellt und die neuesten Funktionen verwendet, um den Cluster automatisch an die Arbeitslastanforderungen anzupassen. Sie können mit diesem Modell eine Vielzahl von Jobs ausführen. Es lässt sich innerhalb von Minuten auf Hunderte von Instanzen skalieren, indem Sie die Knoten einfach in Slurm anfordern.
Wenn Sie mehr über die Verwendung von Slurm in GCP erfahren möchten, sollten Sie das Codelab Mit Slurm föderierte HPC-Cluster erstellen durcharbeiten. In diesem Codelab wird beschrieben, wie Sie zwei föderierte Slurm-Cluster in der Cloud einrichten, um zu veranschaulichen, wie Sie eine Multi-Cluster-Föderation erreichen können, unabhängig davon, ob sie lokal oder in der Cloud erfolgt.
Entwickeln Sie etwas Cooles mit der neuen GCP-nativen Funktionalität von Slurm? Hast du Fragen? Haben Sie einen Vorschlag für eine Funktion? Wenden Sie sich noch heute über die Website für High Performance Computing-Lösungen von Google Cloud an das Google Cloud-Team oder chatten Sie mit uns in der Google Cloud & Slurm Discussion Group.
Terraform-Bereitstellung bereinigen
Melden Sie sich vom Slurm-Knoten ab:
exit
Warten Sie, bis alle automatisch skalierten Knoten herunterskaliert wurden, bevor Sie die Bereitstellung löschen. Sie können diese Knoten auch manuell löschen, indem Sie für jede Instanz „gcloud compute instances delete <Instance Name>“ ausführen oder in der Console-GUI mehrere Knoten auswählen und auf „Löschen“ klicken.
Sie können die Terraform-Bereitstellung nach Abschluss der Einrichtung ganz einfach bereinigen, indem Sie den folgenden Befehl in Ihrer Google Cloud Shell ausführen, nachdem Sie sich von g1-login0 abgemeldet haben:
cd ~/slurm-gcp/tf/examples/basic terraform destroy -var-file=basic.tfvars
Geben Sie zum Fortfahren yes ein, wenn Sie dazu aufgefordert werden. Dieser Vorgang kann einige Minuten dauern.
Projekt löschen
Zum Bereinigen löschen wir einfach unser Projekt.
- Wählen Sie im Navigationsmenü „IAM & Verwaltung“ aus.
- Klicken Sie dann im Untermenü auf „Einstellungen“.
- Klicken Sie auf das Papierkorbsymbol mit dem Text „Projekt löschen“.
- Anleitung in den Prompts befolgen
Behandelte Themen
- Slurm mit Terraform in der GCP bereitstellen
- So führen Sie einen Job mit Slurm in der GCP aus.
- Clusterinformationen abfragen und ausgeführte Jobs in Slurm überwachen
- So skalieren Sie Knoten mit Slurm in der GCP automatisch, um bestimmten Jobparametern und Anforderungen gerecht zu werden.
- MPI-Anwendungen in Slurm auf der GCP kompilieren und ausführen
Slurm-Support finden
Wenn Sie Unterstützung bei der Verwendung dieser Integrationen in Test- oder Produktionsumgebungen benötigen, wenden Sie sich bitte direkt über die Kontaktseite an SchedMD: https://www.schedmd.com/contact.php.
Sie können auch die verfügbaren Anleitungen zur Fehlerbehebung verwenden:
- Leitfaden zur Fehlerbehebung für Slurm auf der GCP: https://github.com/SchedMD/slurm-gcp#troubleshooting
- SchedMD-Anleitung zur Fehlerbehebung: https://slurm.schedmd.com/troubleshoot.html
Sie können Ihre Frage auch in der Google Cloud & Slurm-Diskussionsgruppe posten, die Sie unter https://groups.google.com/g/google-cloud-slurm-discuss finden.
Weitere Informationen
Feedback
Über diesen Link können Sie Feedback zu diesem Codelab geben. Das Feedback dauert weniger als 5 Minuten. Vielen Dank!