1. Übersicht
Willkommen beim Google Codelab zum Ausführen eines Slurm-Clusters auf der Google Cloud Platform! Am Ende dieses Codelabs sollten Sie mit der einfachen Bereitstellung und dem Betrieb eines automatisch skalierenden Slurm-Clusters vertraut sein.
Google Cloud hat in Zusammenarbeit mit SchedMD eine Reihe von Tools veröffentlicht, mit denen der Slurm-Arbeitslastmanager in Compute Engine einfacher gestartet und der vorhandene Cluster dynamisch erweitert werden kann, wenn Sie zusätzliche Ressourcen benötigen. Diese Integration wurde von den Experten bei SchedMD in Übereinstimmung mit den Best Practices von Slurm entwickelt.
Wenn Sie die Integrationen von Slurm auf der Google Cloud Platform verwenden möchten oder Fragen haben, besuchen Sie unser Google Cloud-Team Diskussionsgruppe der Slurm-Community!
Über Slurm
Grundlegendes Architekturdiagramm eines eigenständigen Slurm-Clusters in der Google Cloud Platform.
Slurm ist einer der weltweit führenden Arbeitslastmanager für HPC-Cluster. Slurm bietet ein fehlertolerantes und hoch skalierbares Open-Source-Verwaltungs- und Jobplanungssystem für kleine und große Linux-Cluster. Für den Betrieb von Slurm sind keine Kernel-Änderungen erforderlich und es ist relativ eigenständig. Als Clusterarbeitslastmanager hat Slurm drei Hauptfunktionen:
- Sie weist Nutzern für einen bestimmten Zeitraum exklusiven oder nicht exklusiven Zugriff auf Ressourcen (Rechenknoten) zu, damit diese ihre Arbeit ausführen können.
- Er bietet ein Framework zum Starten, Ausführen und Überwachen der Arbeit (normalerweise ein paralleler Job) auf der Gruppe von zugewiesenen Knoten.
- Es ordnet Ressourcenkonflikte, indem es eine Warteschlange mit ausstehenden Arbeiten verwaltet.
Lerninhalte
- Slurm-Cluster mit Terraform einrichten
- Job mit SLURM ausführen
- Clusterinformationen abfragen und laufende Jobs in SLURM überwachen
- Knoten automatisch skalieren, um bestimmte Jobparameter und Anforderungen zu erfüllen
- Wo Sie Hilfe zu Slurm erhalten
Vorbereitung
- Google Cloud Platform-Konto und ein Projekt mit Abrechnung
- Linux-Basis
2. Einrichtung
Umgebung für das selbstbestimmte 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 Platform Console an ( console.cloud.google.com) 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 in allen Google Cloud-Projekten eindeutig sein. Wenn Ihr Projektname nicht eindeutig ist, generiert Google Cloud eine zufällige Projekt-ID auf Basis des Projektnamens.
Als Nächstes müssen Sie in der Developers Console die Abrechnung aktivieren, um Google Cloud-Ressourcen nutzen zu können.
Dieses Codelab sollte nicht mehr als ein paar Euro kosten. Wenn Sie sich jedoch dazu entschließen, mehr Ressourcen zu verwenden oder diese weiter auszuführen (siehe Abschnitt „Fazit“ am Ende dieses Dokuments), Den Google Cloud Platform-Preisrechner finden Sie hier.
Neue Nutzer der Google Cloud Platform haben Anspruch auf eine kostenlose Testversion mit 300$Guthaben.
Google Cloud Shell
Sie können Google Cloud zwar von Ihrem Laptop aus aus der Ferne bedienen, in diesem Codelab verwenden wir jedoch Google Cloud Shell, 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. Es bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und wird in Google Cloud ausgeführt. Dadurch wird die Netzwerkleistung erheblich verbessert und die Authentifizierung vereinfacht. Sie können die meisten, wenn nicht sogar alle Arbeiten in diesem Lab ganz einfach mit einem Webbrowser oder einem Google Chromebook erledigen.
Sobald Sie mit Cloud Shell verbunden sind, sollten Sie sehen, dass Sie bereits authentifiziert sind und dass das Projekt bereits auf 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 dem folgenden Befehl festlegen:
$ gcloud config set project <PROJECT_ID>
Befehlsausgabe:
Updated property [core/project].
3. Slurm-Terraform-Konfiguration vorbereiten und überprü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 von Slurm für Google Cloud Platform enthält:
git clone https://github.com/SchedMD/slurm-gcp.git
Wechseln Sie mit dem folgenden Befehl zum Konfigurationsverzeichnis für die Slurm-Bereitstellung:
cd slurm-gcp
Slurm-Terraform-TFvars konfigurieren
Die Datei „basic.tfvars.example“ enthält die Konfiguration der Bereitstellung, einschließlich des Netzwerks, der Instanzen und des Speichers, der bereitgestellt werden soll. Kopieren Sie sie in eine neue Datei, die wir „the tfvars file“ nennen, 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 verwenden (Vi, Nano, Emacs usw.) oder den Cloud Console-Codeeditor verwenden, um sich den Dateiinhalt anzusehen:
Überprüfen Sie den Inhalt der tfvars-Datei.
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"
]
In dieser tfvars-Datei gibt es 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, aber ändern Sie sie nach Bedarf. Eine ausführlichere Beschreibung der Konfigurationsoptionen finden Sie hier.
- cluster_name::Name des Slurm-Clusters
- project:ID des Google Cloud-Projekts, in dem Ressourcen bereitgestellt werden
- zone: Google Cloud-Zone, die die Controller- und Anmeldeinstanzen dieses Clusters enthält – Weitere Informationen
- network_name: Virtual Private Cloud-Netzwerk, in dem der Slurm-Cluster bereitgestellt wird
- subnetwork_name: Virtual Private Cloud-Subnetzwerk, in dem der Slurm-Cluster bereitgestellt wird
- shared_vpc_host_project: : Freigegebenes VPC-Netzwerk zum Bereitstellen des Slurm-Clusters in
- disable_controller_public_ips::Dem Slurm-Controller externe IP-Adressen zuweisen?
- disable_login_public_ips: Dem Slurm-Anmeldeknoten externe IP-Adresse zuweisen?
- disable_compute_login_ips: Dem Slurm-Anmeldeknoten externe IP-Adresse zuweisen?
- suspend_time::Zeit, die gewartet wird, wenn ein Knoten inaktiv ist, bevor der Knoten angehalten wird
- controller_machine_type::Instanztyp des Controllerknotens
- controller_image::zum Erstellen der Slurm-Controller-Instanz verwendete GCP-Image
- controller_disk_type::Typ des Bootlaufwerks der Controller-Instanz
- controller_disk_size_gb: Größe des Bootlaufwerks einer Controller-Instanz
- controller_labels::Das Label bzw. die Labels, die der Controller-Instanz hinzugefügt werden sollen
- controller_service_account: Dienstkonto, das auf der Controller-Instanz verwendet werden soll
- controller_scopes: : Zugriffsbereich der Controller-Instanz
- cloudsql: Google CloudSQL-Server, der als Slurm-Datenbank verwendet wird, anstatt eine Datenbank auf der Controller-Instanz zu hosten
- server_ip::IP-Adresse des CloudSQL-Servers
- user:CloudSQL-Nutzername
- password:Cloud SQL-Passwort
- db_name::CloudSQL-Datenbankname
- controller_secondary_disk::Sekundäres Laufwerk für NFS-Serverspeicher hinzufügen?
- controller_secondary_disk_type::Typ des sekundären Laufwerks des Controllers
- controller_secondary_disk_size_gb::Größe des sekundären Laufwerks des Controllers
- controller_instance_template: Die GCP-Instanzvorlage, die für die Controller-Instanz verwendet werden soll. Alle angegebenen Rechenfelder überschreiben die Vorlageneigenschaften. Beispiel: Wenn „controller_image“ angegeben ist, wird das Image in der Instanzvorlage überschrieben.
- login_machine_type::Instanztyp des Knotens für die Anmeldung (über SSH zugänglich)
- login_image: zum Erstellen der Slurm-Anmeldeinstanz verwendete GCP-Image
- login_disk_type: Typ des Bootlaufwerks der Anmeldeinstanz
- login_disk_size_gb: Größe des Bootlaufwerks der Anmeldeinstanz
- login_labels: Labels, die der Anmeldeinstanz hinzugefügt werden sollen
- login_node_count: Anzahl der zu erstellenden Anmeldeknoten
- login_node_service_account: Dienstkonto, das für die Anmeldeinstanz(en) verwendet werden soll
- login_node_scopes: Zugriffsbereich der Anmeldeinstanz
- login_instance_template: Die GCP-Instanzvorlage, die für die Anmeldeinstanz verwendet werden soll. Alle angegebenen Rechenfelder überschreiben die Vorlageneigenschaften. Beispiel: Wenn „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 weitere Bereitstellungen wiederholt werden.
- server_ip::IP-Adresse des Speicherservers
- remote_mount::Name der Speicherbereitstellung (Dateisystemname)
- local_mount: Lokales Bereitstellungsverzeichnis
- fs_type:: Dateisystemtyp (automatisch installiert: NFS, CIFS, Lustre oder GCSFuse)
- mount_options::Bereitstellungsoptionen (z.B. „default“, „_netdev“)
- login_network_storage: Netzwerkspeicher, der auf Anmelde- und Controllerknoten bereitgestellt werden soll. NFS, CIFS, Lustre und GCSFuse werden automatisch installiert. Kann für weitere Bereitstellungen wiederholt werden.
- server_ip::IP-Adresse des Speicherservers
- remote_mount::Name der Speicherbereitstellung (Dateisystemname)
- local_mount: Lokales Bereitstellungsverzeichnis
- fs_type:: Dateisystemtyp (automatisch installiert: NFS, CIFS, Lustre oder GCSFuse)
- mount_options::Bereitstellungsoptionen (z.B. „default“, „_netdev“)
- compute_node_service_account: Dienstkonto, das für die Compute-Instanz(en) verwendet werden soll
- compute_node_scopes: Zugriffsbereich der Compute-Instanzen
- partitions:Slurm-Partitionskonfiguration. Kann für weitere Partitionen wiederholt werden.
- name:Partitionsname
- machine_type::Instanztyp von Rechenknoten
- static_node_count::Anzahl der immer aktiven Compute-Knoten
- max_node_count::Maximal zulässige Gesamtzahl von Rechenknoten, maximal 64.000
- zone: Google Cloud-Zone, die die Ressourcen dieser Partition enthält – Weitere Informationen
- Image: Maschinentyp des Compute-Image-Knotens
- image_hyperthreads::Hyperthreading für die Instanz aktivieren oder deaktivieren
- compute_disk_type: Typ des Bootlaufwerks einer Compute-Instanz (pd-standard, pd-ssd)
- compute_disk_size_gb: Größe eines Bootlaufwerks einer Compute-Instanz
- compute_labels: Label(s), die der Compute-Instanz hinzugefügt werden sollen
- cpu_platform::Für alle Rechenknoten erforderliche Mindest-CPU-Plattform
- gpu_count::Anzahl der GPUs, die mit jeder Instanz in der Partition verknüpft werden sollen
- gpu_type: GPU-Typ, der an die Instanzen der Partition angehängt werden soll
- network_storage: Netzwerkspeicher, der auf allen Compute-Knoten in der Partition bereitgestellt werden soll. Felder werden direkt zu fstab hinzugefügt. Kann für weitere Bereitstellungen wiederholt werden.
- server_ip::IP-Adresse des Speicherservers
- remote_mount::Name der Speicherbereitstellung (Dateisystemname)
- local_mount: Lokales Bereitstellungsverzeichnis
- fs_type:: Dateisystemtyp (automatisch installiert: NFS, CIFS, Lustre oder GCSFuse)
- mount_options::Bereitstellungsoption
- preemptible_bursting: Werden die Instanzen präemptive Instanzen sein?
- vpc_subnet: Virtual Private Cloud-Subnetzwerk zum Bereitstellen der Slurm-Partition
- Exklusiv:Slurm aktivieren, um Jobs ganze Knoten zuzuweisen
- enable_placement::Aktivieren Sie Platzierungsrichtlinien, bei denen sich Instanzen nahe beieinander befinden, um eine niedrige Netzwerklatenz zwischen den Instanzen zu erreichen.
- regional_capacity::Hiermit kann eine Instanz je nach Verfügbarkeit in einer beliebigen Zone der Region platziert werden.
- regional_policy::Wenn „regional_capacity“ auf „true“ gesetzt ist, bestimmt diese Richtlinie, welche Region verwendet werden soll und welche Zonen in dieser Region nicht verwendet werden.
- Instance_template: Die GCP-Instanzvorlage, die für Compute-Instanzen verwendet werden soll. Alle angegebenen Rechenfelder überschreiben die Vorlageneigenschaften. Beispiel: Wenn 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. Für die Installation von Software in Ihrem Slurm-Cluster gibt es mehrere Möglichkeiten, wie unter „Anwendungen in einem Slurm-Cluster auf Compute Engine installieren beschrieben“ beschrieben wird, oder indem Sie das von Slurm bereitgestellte Image anpassen. Derzeit stellt Slurm ein von SchedMD bereitgestelltes VM-Image bereit, das auf dem Google Cloud HPC-VM-Image basiert, auf dem Slurm installiert ist.
Wenn Sie ein 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 Image-URI durch Ihr eigenes Image und testen Sie die Änderung.
Fehlerbehebung
In diesem Codelab lesen Sie den Abschnitt zur Fehlerbehebung in der ReadMe-Datei des Slurm-GCP-Repositorys.
Am häufigsten treten Fehler bei der Konfiguration der tfvars-Datei und Kontingentbeschränkungen auf. Dieses Codelab ist so konzipiert, dass er im Rahmen des standardmäßigen Kontingentkontingents eines neuen Nutzers und innerhalb des Guthabens von 300 $, das ein neuer Nutzer erhält, ausgeführt werden kann. Wenn ein Versuch zum Erstellen von VMs fehlschlägt, prüfen Sie die Datei /var/log/slurm/resume.log auf dem Controller-Knoten auf API-Fehler.
4. Konfiguration bereitstellen und prüfen
Konfiguration bereitstellen
Führen Sie in der Cloud Shell-Sitzung im Ordner slurm-gcp/tf/example den folgenden Befehl aus:
terraform init terraform apply -var-file=basic.tfvars
Sie werden aufgefordert, die beschriebenen Aktionen auf Grundlage der festgelegten Konfigurationen zu akzeptieren. Geben Sie yes ein. um mit der Bereitstellung zu beginnen. Sie können sich die bereitzustellende Konfiguration auch ansehen, indem Sie „terraform plan“ ausführen.
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. Wir bitten Sie daher um etwas Geduld.
Sobald die Bereitstellung abgeschlossen ist, sieht die Ausgabe in etwa so aus:
Apply complete! Resources: 8 added, 0 changed, 0 destroyed.
Outputs:
controller_network_ips = [
[
"10.0.0.2",
],
]
login_network_ips = [
[
"10.0.0.3",
],
]
VM-Instanzerstellung prüfen
Öffnen Sie das Navigationsmenü und wählen Sie Compute Engine > VM-Instanzen:
Sie sollten einen Controller und eine Log-in-VM-Instanz sehen:
Überprüfen Sie unter VM-Instanzen die beiden VM-Instanzen, die von Terraform erstellt wurden.
Die Namen werden anders sein, wenn Sie das Feld cluster_name geändert haben.
- g1-controller
- g1-login0
5. Im Slurm-Cluster anmelden
Auf den Slurm-Cluster zugreifen
Kehren Sie zum Tab „Code-Editor“ bzw. „Cloud Shell“ zurück. Führen Sie den folgenden Befehl aus, um sich bei der Instanz anzumelden, wobei Sie <ZONE> durch die Zone des Knotens g1-login0 ersetzen (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 für den einfachen Zugriff auf den Anmeldeknoten ist das Klicken auf den auf der Seite „VM-Instanzen“ neben der VM „g1-login0“, 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 zur Auswahl einer Passphrase aufgefordert werden, lassen Sie sie 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 und fahren Sie erst mit dem Lab fort, wenn diese Meldung angezeigt wird (ca. 5 Minuten):
*** Slurm login setup complete ***
Wenn die Meldung oben angezeigt wird, müssen Sie sich abmelden und bei g1-login0 wieder anmelden, um mit dem Lab fortzufahren. Drücken Sie dazu Strg + C, um die Aufgabe zu beenden.
Führen Sie dann den folgenden Befehl aus, um sich von der Instanz abzumelden:
exit
Stellen Sie nun wieder eine Verbindung zur Log-in-VM her. Führen Sie den folgenden Befehl aus, um sich bei der Instanz anzumelden. Ersetzen Sie dabei <ZONE> durch die Zone des Knotens g1-login0:
gcloud compute ssh g1-login0 --zone=<ZONE>
Wie oben beschrieben, müssen Sie möglicherweise ein bis zwei Minuten warten, bevor Sie eine Verbindung herstellen können, und alle Schritte der Einrichtung sind abgeschlossen.
Einführung in die Slurm CLI-Tools
Sie sind jetzt beim Slurm-Anmeldeknoten Ihres Clusters angemeldet. Dies ist der Knoten für die Nutzer/Administrator-Interaktion, die Planung von Slurm-Jobs und Administratoraktivitäten.
Lassen Sie uns ein paar Befehle ausführen, um Sie in die Slurm-Befehlszeile einzuführen.
Führen Sie den Befehl sinfo aus, um den Status der Clusterressourcen aufzurufen:
sinfo
Eine Beispielausgabe von Sinfo wird unten angezeigt. sinfo meldet die im Cluster verfügbaren Knoten, den Status dieser Knoten und andere Informationen wie die Partition, die Verfügbarkeit und etwaige Zeitbeschränkungen dieser Knoten.
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST debug* up infinite 10 idle~ g1-compute-0-[0-9]
Sie sehen die 10 Knoten, die durch den Wert „max_node_count“ der Debug-Partition festgelegt wird. von 10 werden als "idle~" gekennzeichnet. Der Knoten befindet sich im inaktiven und nicht zugewiesenen Modus und kann hochgefahren werden.
Führen Sie als Nächstes den Befehl squeue aus, um den Status der Warteschlange des Clusters anzeigen zu lassen:
squeue
Die erwartete Ausgabe von squeue wird unten angezeigt. squeue meldet den Status der Warteschlange für einen Cluster. Dazu gehören jede 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, den Status des Jobs, die tatsächlich verstrichene Zeit, in der der Job ausgeführt wurde, und die Knoten, denen dieser Job zugewiesen ist. Es werden keine Jobs ausgeführt, daher ist der Inhalt dieses Befehls leer.
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
Der Slurm-Befehl „srun“ und „sbatch“ werden verwendet, um Jobs auszuführen, die in die Warteschlange gestellt werden. "geschrumpft" führt parallele Jobs aus und kann als Wrapper für mpirun verwendet werden. „sbatch“ wird verwendet, um einen Batch-Job an Slurm zu senden und Srun einmal- oder mehrmals in verschiedenen Konfigurationen aufzurufen. „sbatch“ können Batch-Skripte verwenden oder mit der Option –wrap verwendet werden, um den gesamten Job über die Befehlszeile auszuführen.
Lassen Sie uns einen Job ausführen, damit wir Slurm in Aktion sehen und einen Job in unsere Warteschlange bekommen!
6. Slurm-Job ausführen und Cluster skalieren
Slurm-Job ausführen und Cluster skalieren
Der Slurm-Cluster läuft nun. Lassen Sie uns nun einen Job ausführen und den Cluster hochskalieren.
Der „Sbatch“ wird verwendet, um Slurm-Batchbefehle und -Scripts auszuführen. Führen Sie nun ein einfaches Sbatch-Skript aus, das „hostname“ ausführt. auf unseren automatisch skalierten VMs.
Melden Sie sich in g1-login0 an und führen Sie den folgenden Befehl aus:
sbatch -N2 --wrap="srun hostname"
Dieser Befehl führt den Slurm-Batchbefehl aus. Es gibt an, dass der Sbatch 2 Knoten mit dem „-N“ ausführt Option. Außerdem wird angegeben, dass jeder dieser Knoten einen „Srun-Hostnamen“ ausführt. im "-wrap" Option.
Standardmäßig schreibt sbatch seine Ausgabe in „slurm-%j.out“ Im Arbeitsverzeichnis, in dem der Befehl ausgeführt wird, wird %j durch die Job-ID gemäß den Slurm-Dateinamenmustern ersetzt. In unserem Beispiel wird ein Sbatch im Ordner „/home“ des Nutzers ausgeführt. Dabei handelt es sich um ein NFS-basiertes freigegebenes Dateisystem, das standardmäßig auf dem Controller gehostet wird. Dadurch können Rechenknoten bei Bedarf Eingabe- und Ausgabedaten gemeinsam nutzen. In einer Produktionsumgebung sollte der Arbeitsspeicher vom /home-Speicher getrennt sein, um Leistungsbeeinträchtigungen auf den Clusterbetrieb zu vermeiden. Separate Speicherbereitstellungen können in der tfvars-Datei im Netzwerk „network_storage“ Optionen.
Nach dem Ausführen des sbatch-Skripts über die sbatch-Befehlszeile wird eine Job-ID für den geplanten Job zurückgegeben, zum Beispiel:
Submitted batch job 2
Mit der vom Befehl sbatch 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 anzusehen:
squeue
Der von Ihnen ausgeführte Job wird wahrscheinlich so 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 Compute-Instanzen entsprechend den Jobanforderungen. Dieser Vorgang ist automatisch und hat zwei Vorteile. Zunächst entfällt die in einem HPC-Cluster üblicherweise erforderliche Arbeit, um Knoten manuell bereitzustellen, Software zu konfigurieren, den Knoten in den Cluster zu integrieren und dann den Job bereitzustellen. Zweitens können Nutzer Geld sparen, da inaktive, nicht verwendete Knoten so lange herunterskaliert werden, bis die Mindestanzahl von Knoten ausgeführt wird.
Mit dem Befehl sinfo können Sie sehen, wie der Slurm-Cluster gestartet wird:
sinfo
Dadurch werden die Knoten angezeigt, die in der Warteschlange unter „alloc#“ aufgeführt sind. Status, d. h., die Knoten werden zugewiesen:
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 die neu bereitgestellten Knoten auch im Bereich „VM-Instanzen“ in der Google Cloud Console ansehen. Es dauert einige Minuten, die Knoten hochzufahren und Slurm auszuführen, bevor der Job den neu zugewiesenen Knoten zugewiesen wird. Die Liste Ihrer VM-Instanzen sollte bald so aussehen:
Sobald die Knoten den Job ausführen, werden die Instanzen auf ein „alloc“ verschoben , d. h., die Jobs sind einem Job zugewiesen:
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]
Sobald ein Job abgeschlossen ist, wird er nicht mehr in der Warteschlange aufgeführt. Das Feld "alloc" Knoten in Sinfo kehren zu „inaktiv“ zurück Bundesstaat. Führen Sie „squeue“ aus In regelmäßigen Abständen, bis der Job abgeschlossen ist, nach ein bis zwei Minuten.
Die Ausgabedatei slurm-%j.out wurde in den NFS-freigegebenen Ordner /home geschrieben und enthält die Hostnamen. Öffnen oder durchsuchen Sie die Ausgabedatei (normalerweise slurm-2.out). Der Inhalt der Ausgabedatei enthält Folgendes:
g1-compute-0-0 g1-compute-0-1
Gut gemacht! Sie haben einen Job ausgeführt und Ihren Slurm-Cluster hochskaliert!
7. MPI-Job ausführen
Führen wir nun einen MPI-Job auf allen Knoten aus. Während Sie bei g1-login0 angemeldet sind, verwenden Sie wget, um ein in der Programmiersprache C geschriebenes MPI-Programm herunterzuladen:
wget https://raw.githubusercontent.com/mpitutorial/mpitutorial/gh-pages/tutorials/mpi-hello-world/code/mpi_hello_world.c
Um OpenMPI-Tools zu verwenden, müssen Sie die OpenMPI-Module mit folgendem Befehl laden:
module load openmpi
Wir verwenden „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 einem Texteditor Ihrer Wahl das Sbatch-Skript "helloworld_batch":
vi helloworld_batch
Geben Sie i ein, um den VI-Einfügemodus aufzurufen.
Kopieren Sie den folgenden Text und fügen Sie ihn in die Datei ein, um ein einfaches Sbatch-Script zu erstellen:
#!/bin/bash # #SBATCH --job-name=hello_world #SBATCH --output=hello_world-%j.out # #SBATCH --nodes=2 srun mpi_hello_world
Speichern und schließen Sie den Code-Editor, indem Sie die Esc-Taste drücken und ":wq" eingeben. ohne Anführungszeichen.
Dieses Skript definiert die Slurm-Batchausführungsumgebung und -Aufgaben. Zuerst wird die Ausführungsumgebung als bash definiert. Als Nächstes definiert das Skript zuerst die Slurm-Optionen mit „#SBATCH“ Linien. Als Jobname ist „hello_world“ definiert.
Die Ausgabedatei ist als "hello_world_%j.out" festgelegt. Dabei wird %j durch die Job-ID gemäß den Slurm-Dateinamenmustern ersetzt. Diese Ausgabedatei wird in das Verzeichnis geschrieben, aus dem das sbatch-Skript ausgeführt wird. In unserem Beispiel ist dies der Ordner „/home“ des Nutzers, der ein NFS-basiertes freigegebenes Dateisystem ist. Dadurch können Rechenknoten bei Bedarf Eingabe- und Ausgabedaten gemeinsam nutzen. In einer Produktionsumgebung sollte der Arbeitsspeicher vom /home-Speicher getrennt sein, um Leistungsbeeinträchtigungen auf den Clusterbetrieb zu vermeiden.
Schließlich wird als Anzahl der Knoten, auf denen dieses Skript ausgeführt werden soll, 2 definiert.
Nachdem die Optionen definiert wurden, werden die ausführbaren Befehle bereitgestellt. Dieses Skript führt den Code mpi_hello_world parallel mit dem Befehl srun aus, der ein Drop-in-Ersatz für den Befehl mpirun ist.
Führen Sie dann das sbatch-Skript mithilfe der sbatch-Befehlszeile aus:
sbatch helloworld_batch
Beim Ausführen eines Sbatches wird eine Job-ID für den geplanten Job zurückgegeben. Beispiel:
Submitted batch job 3
Dadurch wird der Befehl hostname auf zwei Knoten mit einer Aufgabe pro Knoten ausgeführt. Die Ausgabe wird in der Datei hello_world-3.out ausgegeben.
Da bereits 2 Knoten bereitgestellt wurden, wird dieser Job schnell ausgeführt.
Beobachten Sie squeue, bis der Job abgeschlossen und nicht mehr aufgeführt ist:
squeue
Wenn Sie fertig sind, öffnen oder durchsuchen Sie die Datei hello_world-3.out und prüfen Sie, ob 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 wird die Zuweisung der dynamisch bereitgestellten Compute-Knoten zur Freigabe von Ressourcen aufgehoben. Dies lässt sich mit dem Feld „sperr_time“ der YAML-Datei oder über das Feld „AnhaltenTime“ von slurm.conf konfigurieren. Sie können dies validieren, indem Sie regelmäßig sinfo ausführen und beobachten, wie die Clustergröße auf 0 zurückgeht:
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST debug* up infinite 10 idle~ g1-compute-0-[0-9]
Versuchen Sie, mehr Instanzen bis zu dem Kontingent einzurichten, das in der Region zulässig ist, in der Sie den Cluster bereitgestellt haben, und verschiedene MPI-Anwendungen auszuführen.
8. Fazit
Herzlichen Glückwunsch. Sie haben einen Slurm-Cluster auf der Google Cloud Platform erstellt und seine neuesten Features verwendet, um Ihren Cluster automatisch zu skalieren, damit er die Arbeitslastanforderungen erfüllt. Mit diesem Modell können Sie eine Vielzahl von Jobs ausführen. Es skaliert in Minuten auf Hunderte von Instanzen, indem es einfach die Knoten in Slurm anfordert.
Wenn Sie die Verwendung von Slurm auf der GCP weiter vertiefen möchten, fahren Sie mit der Building Federated HPC Clusters with Slurm Codelab. In diesem Codelab werden Sie durch die Einrichtung von zwei föderierten Slurm-Clustern in der Cloud geführt, um darzustellen, wie Sie eine Multi-Cluster-Föderation lokal oder in der Cloud erstellen könnten.
Entwickeln Sie mit den neuen GCP-nativen Funktionen von Slurm etwas Cooles? Hast du Fragen? Haben Sie einen Vorschlag für eine Funktion? Kontaktieren Sie das Google Cloud-Team noch heute über die Website von Google Cloud für Hochleistungs-Computing oder chatten Sie mit uns über die Slurm-Diskussionsgruppe
Terraform-Deployment bereinigen
Melden Sie sich vom Slurm-Knoten ab:
exit
Lassen Sie alle automatisch skalierten Knoten herunterskalieren, bevor Sie die Bereitstellung löschen. Sie können diese Knoten auch manuell löschen, indem Sie „gcloud compute instances delete <Instance Name>“ ausführen. oder indem Sie über die Benutzeroberfläche der Console mehrere Knoten auswählen und auf „Löschen“ klicken.
Sie können die Terraform-Bereitstellung anschließend ganz einfach bereinigen. Führen Sie dazu den folgenden Befehl in Google Cloud Shell aus, 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. Bitte haben Sie etwas Geduld.
Projekt löschen
Zur Bereinigung löschen wir unser Projekt einfach.
- Wählen Sie im Navigationsmenü die Option „IAM & Verwaltung
- Klicken Sie dann im Untermenü auf „Settings“ (Einstellungen)
- Klicken Sie auf das Papierkorbsymbol mit dem Text „Projekt löschen“.
- Folge der Anleitung
Behandelte Themen
- Slurm-Bereitstellung mit Terraform auf der GCP verwenden
- Job mit Slurm auf der GCP ausführen
- Anleitung zum Abfragen von Clusterinformationen und zum Überwachen laufender Jobs in Slurm.
- So skalieren Sie Knoten mit Slurm auf der GCP automatisch, um bestimmte Jobparameter und -anforderungen zu erfüllen.
- Kompilieren und Ausführen von MPI-Anwendungen in Slurm auf der GCP
Slurm-Support
Wenn Sie Unterstützung bei der Verwendung dieser Integrationen in Test- oder Produktionsumgebungen benötigen, wenden Sie sich bitte direkt an SchedMD über die Kontaktseite: https://www.schedmd.com/contact.php
Sie können auch die verfügbaren Anleitungen zur Fehlerbehebung verwenden:
- Anleitung zur Fehlerbehebung für Slurm auf der GCP: https://github.com/SchedMD/slurm-gcp#troubleshooting
- SchedMD-Leitfaden zur Fehlerbehebung: https://slurm.schedmd.com/troubleshoot.html
Schließlich können Sie Ihre Frage auch im Google Cloud- und Hier finden Sie die Slurm-Diskussionsgruppe: https://groups.google.com/g/google-cloud-slurm-discuss
Weitere Informationen
Feedback
Du kannst über diesen Link Feedback zu diesem Codelab senden. Das Feedback dauert weniger als 5 Minuten. Vielen Dank!