1. 概要
Google Cloud Platform で Slurm クラスタを実行するための Google Codelab へようこそ。この Codelab を修了すると、自動スケーリングの Slurm クラスタのプロビジョニングと運用の容易さについてしっかりと理解できるようになります。
Google Cloud は SchedMD と提携し、Compute Engine 上で Slurm ワークロード マネージャーを簡単に起動したり、追加のリソースが必要になったときに既存のクラスタを動的に拡張したりできるようにする一連のツールをリリースしました。この統合は、SchedMD の専門家が Slurm のベスト プラクティスに従って構築したものです。
Slurm on Google Cloud Platform 統合のご利用を予定している場合、またはご質問がある場合は、Google Cloud &Slurm コミュニティ ディスカッション グループ！
Slurm について
Google Cloud Platform のスタンドアロン Slurm クラスタの基本的なアーキテクチャ図。
Slurm は、世界中の HPC クラスタの主要ワークロード マネージャーです。Slurm は、オープンソースでフォールト トレラントでスケーラビリティに優れたワークロード管理とジョブ スケジューリングのシステムを、小規模および大規模な Linux クラスタ向けに提供します。Slurm は動作のためにカーネルの変更を必要とせず、比較的自己完結しています。クラスタ ワークロード マネージャーである Slurm には、次の 3 つの重要な機能があります。
- ユーザーが作業を実行できるように、一定期間、リソース（コンピューティング ノード）への排他的または非排他的なアクセス権をユーザーに割り当てます。
- 割り当てられたノードの集合に対する作業（通常は並列ジョブ）を開始、実行、監視するためのフレームワークを提供します。
- 保留中の作業のキューを管理することで、リソースの競合を仲裁します。
学習内容
- Terraform を使用して Slurm クラスタを設定する方法
- SLURM を使用してジョブを実行する方法
- クラスタ情報をクエリし、SLURM で実行中のジョブをモニタリングする方法
- 特定のジョブ パラメータと要件に対応するためにノードを自動スケーリングする方法
- Slurm のヘルプの参照先
前提条件
- Google Cloud Platform アカウントと請求先プロジェクト
- Linux の基本経験
2. セットアップ
セルフペース型の環境設定
プロジェクトを作成
Google アカウント（Gmail または G Suite）をまだお持ちでない場合は、アカウントを作成してください。Google Cloud Platform コンソール（console.cloud.google.com）にログインし、[リソースの管理] ページを開きます。
[プロジェクトを作成] をクリックします。
プロジェクトの名前を入力します。プロジェクト ID（上のスクリーンショットで赤色でハイライト表示）を覚えてください。プロジェクト ID は、すべての Google Cloud プロジェクトで一意の名前にする必要があります。プロジェクト名が一意でない場合、Google Cloud はプロジェクト名に基づいてランダムなプロジェクト ID を生成します。
次に、Google Cloud リソースを使用するために、Developers Console で課金を有効化する必要があります。
この Codelab をすべて実行しても費用はかかりませんが、より多くのリソースを使用する場合や実行したままにする場合は、コストが高くなる可能性があります（このドキュメントの最後にある「まとめ」セクションをご覧ください）。Google Cloud Platform 料金計算ツールは、こちらからご利用いただけます。
Google Cloud Platform の新規ユーザーは、$300 分の無料トライアルをご利用いただけます。
Google Cloud Shell
Google Cloud はノートパソコンからリモートで操作できますが、この Codelab では Cloud 上で動作するコマンドライン環境である Google Cloud Shell を使用します。
Google Cloud Shell を起動する
GCP Console で右上のツールバーにある Cloud Shell アイコンをクリックします。
[Cloud Shell の起動] をクリックします。
プロビジョニングと環境への接続にはそれほど時間はかかりません。
この仮想マシンには、必要な開発ツールがすべて用意されています。永続的なホーム ディレクトリが 5 GB 用意されており、Google Cloud で稼働します。ネットワーク パフォーマンスが大幅に向上し、認証が簡素化されます。このラボでの作業のほとんどは、ウェブブラウザまたは Google Chromebook を使用して行うことができます。
Cloud Shell に接続すると、すでに認証が完了しており、プロジェクトに各自の PROJECT_ID が設定されていることがわかります。
$ gcloud auth list
コマンド出力:
Credentialed accounts:
- <myaccount>@<mydomain>.com (active)
$ gcloud config list project
コマンド出力:
[core]
project = <PROJECT_ID>
プロジェクト ID が正しく設定されていない場合は、次のコマンドで設定できます。
$ gcloud config set project <PROJECT_ID>
コマンド出力:
Updated property [core/project].
3. Slurm Terraform 構成を準備して確認する
Slurm Terraform 構成をダウンロードする
Cloud Shell セッションで次のコマンドを実行して、Slurm for Google Cloud Platform の Terraform ファイルを含む Git リポジトリのクローンを作成（ダウンロード）します。
git clone https://github.com/SchedMD/slurm-gcp.git
次のコマンドを実行して、Slurm のデプロイ構成ディレクトリに切り替えます。
cd slurm-gcp
Slurm Terraform tfvars を構成する
basic.tfvars.example ファイルには、デプロイするネットワーク、インスタンス、ストレージなど、デプロイの構成が詳しく記述されています。これを新しいファイル（ここでは「tfvars ファイル」と呼びます）にコピーし、必要に応じて編集します。
cd tf/example/basic cp basic.tfvars.example basic.tfvars
Cloud Shell セッションで、tfvars ファイル basic.tfvars を開きます。お好みのコマンドライン エディタ（vi、nano、emacs など）を使用するか、Cloud コンソールのコードエディタを使用してファイルの内容を表示できます。
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"
]
この tfvars ファイルには、構成するフィールドがいくつかあります。構成が必要なフィールドはプロジェクトのみです。この例の他の構成はすべてそのまま使用できますが、状況に応じて変更してください。構成オプションの詳細については、こちらをご覧ください。
- cluster_name: Slurm クラスタの名前
- project: リソースがデプロイされる Google Cloud プロジェクト ID
- ゾーン: このクラスタのコントローラ インスタンスとログイン インスタンスを含む Google Cloud ゾーン - 詳細
- network_name: Slurm クラスタをデプロイする Virtual Private Cloud ネットワーク。
- subnetwork_name: Slurm クラスタをデプロイする Virtual Private Cloud サブネットワークです。
- shared_vpc_host_project: Slurm クラスタをデプロイする共有 VPC ネットワーク
- disable_controller_public_ips: Slurm コントローラに外部 IP を割り当てますか？
- disable_login_public_ips: Slurm ログインノードに外部 IP を割り当てますか？
- disable_compute_login_ips: Slurm ログインノードに外部 IP を割り当てますか？
- suspend_time: ノードがアイドル状態になってからノードを一時停止するまでの時間
- controller_machine_type: コントローラ ノードのインスタンス タイプ
- controller_image: Slurm コントローラ インスタンスの作成に使用される GCP イメージ
- controller_disk_type: コントローラ インスタンスのブートディスクのタイプ
- controller_disk_size_gb: コントローラ インスタンスのブートディスクのサイズ
- controller_labels: コントローラ インスタンスに付加するラベル
- controller_service_account: コントローラ インスタンスで使用されるサービス アカウント
- controller_scopes: コントローラ インスタンスのアクセス スコープ
- cloudsql: コントローラ インスタンスでデータベースをホストする代わりに、Slurm データベースとして使用する Google Cloud SQL サーバー
- server_ip: Cloud SQL サーバーの IP
- user: Cloud SQL のユーザー名
- password: CloudSQL パスワード
- db_name: Cloud SQL データベース名
- controller_secondary_disk: NFS サーバー ストレージ用のセカンダリ ディスクを追加しますか？
- controller_secondary_disk_type: コントローラ セカンダリ ディスクのタイプ
- controller_secondary_disk_size_gb: コントローラ セカンダリ ディスクのサイズ
- controller_instance_template: コントローラ インスタンスに使用する GCP インスタンス テンプレート。指定したコンピューティング フィールドはすべて、テンプレートのプロパティをオーバーライドします。例:controller_image を指定すると、インスタンス テンプレート内のイメージが上書きされます。
- login_machine_type: ログイン（SSH でアクセス可能な）ノードのインスタンス タイプ
- login_image: Slurm ログイン インスタンスの作成に使用される GCP イメージ
- login_disk_type: ログイン インスタンスのブートディスクのタイプ
- login_disk_size_gb: ログイン インスタンスのブートディスクのサイズ
- login_labels: ログイン インスタンスに付加するラベル
- login_node_count: 作成するログインノードの数
- login_node_service_account: ログイン インスタンスで使用されるサービス アカウント
- login_node_scopes: ログイン インスタンスのアクセス スコープ
- login_instance_template: ログイン インスタンスに使用する GCP インスタンス テンプレート。指定したコンピューティング フィールドはすべて、テンプレートのプロパティをオーバーライドします。例:login_image を指定すると、インスタンス テンプレート内のイメージが上書きされます。
- network_storage: すべてのノードにマウントするネットワーク ストレージ。フィールドは fstab に直接追加されます。追加のマウントに対して繰り返すことができます。
- server_ip: ストレージ サーバーの IP
- remote_mount: ストレージ マウント名（ファイル システム名）
- local_mount: ローカル マウント ディレクトリ
- fs_type: ファイルシステムの種類（NFS、CIFS、Lustre、GCSFuse が自動的にインストールされる）
- mount_options: マウント オプション（例: default、_netdev）
- login_network_storage: ログインノードとコントローラ ノードにマウントするネットワーク ストレージ。NFS、CIFS、Lustre、GCSFuse は自動的にインストールされます。追加のマウントに対して繰り返すことができます。
- server_ip: ストレージ サーバーの IP
- remote_mount: ストレージ マウント名（ファイル システム名）
- local_mount: ローカル マウント ディレクトリ
- fs_type: ファイルシステムの種類（NFS、CIFS、Lustre、GCSFuse が自動的にインストールされる）
- mount_options: マウント オプション（例: default、_netdev）
- compute_node_service_account: コンピューティング インスタンスで使用されるサービス アカウント
- compute_node_scopes: コンピューティング インスタンスのアクセス スコープ
- partitions: Slurm パーティション構成。追加のパーティションに対して繰り返すことができます。
- name: パーティション名
- machine_type: コンピューティング ノードのインスタンス タイプ
- static_node_count: 常時稼働コンピューティング ノードの数
- max_node_count: 許可されるコンピューティング ノードの合計数 - 最大 64,000
- zone: このパーティションのリソースが含まれる Google Cloud ゾーン - 詳細
- image: Compute イメージノードのマシンタイプ
- image_hyperthreads: インスタンスでハイパースレッディングをオンまたはオフにする
- compute_disk_type: Compute インスタンスのブートディスクのタイプ（pd-standard、pd-ssd）
- compute_disk_size_gb: Compute インスタンスのブートディスクのサイズ
- compute_labels: Compute インスタンスに付加するラベル
- cpu_platform: すべてのコンピューティング ノードに必要な最小 CPU プラットフォーム
- gpu_count: パーティション内の各インスタンスに接続する GPU の数
- gpu_type: パーティションのインスタンスに接続する GPU のタイプ。
- network_storage: パーティション内のすべてのコンピューティング ノードにマウントするネットワーク ストレージ。フィールドは fstab に直接追加されます。追加のマウントに対して繰り返すことができます。
- server_ip: ストレージ サーバーの IP
- remote_mount: ストレージ マウント名（ファイル システム名）
- local_mount: ローカル マウント ディレクトリ
- fs_type: ファイルシステムの種類（NFS、CIFS、Lustre、GCSFuse が自動的にインストールされる）
- mount_options: マウント オプション
- preemptible_bursting: インスタンスをプリエンプティブル インスタンスとして使用しますか。
- vpc_subnet: Slurm パーティションをデプロイする Virtual Private Cloud サブネットワーク
- 排他的: Slurm を有効にしてノード全体をジョブに割り当てる
- enable_placement: インスタンス間のネットワーク レイテンシを低くするために、インスタンスを互いに近くに配置するプレースメント ポリシーを有効にします。
- regional_capacity: 可用性に基づいて、リージョン内の任意のゾーンにインスタンスを配置できるようにします
- regional_policy::region_capacity が true の場合、このポリシーを使用して、使用するリージョンと使用しないそのリージョン内のすべてのゾーンを決定します
- Instance_template: コンピューティング インスタンスに使用する GCP インスタンス テンプレート。指定したコンピューティング フィールドはすべて、テンプレートのプロパティをオーバーライドします。例:イメージを指定すると、インスタンス テンプレート内のイメージが上書きされます。
詳細設定
必要に応じて、クラスタ デプロイ プロセスの一環として追加のパッケージやソフトウェアをインストールすることもできます。Slurm クラスタにソフトウェアをインストールするには、「Compute Engine の Slurm クラスタにアプリをインストールする」で説明されている複数の方法を使用するか、Slurm によってデプロイされるイメージをカスタマイズします。現在、Slurm は、Google Cloud HPC VM イメージをベースにした SchedMD が提供する VM イメージをデプロイしており、その上に Slurm がインストールされています。
独自のイメージを使用するには、tfvars ファイルにリストされている公開 SchedMD VM Image に基づいて、独自の構成でイメージをビルドします。次に、tfvars ファイルで指定されているイメージ URI を独自のイメージに置き換えて、変更をテストします。
トラブルシューティング
この Codelab 全体を通して、Slurm-GCP リポジトリの ReadMe にあるトラブルシューティングのセクションをご覧ください。
最もよくある問題は、tfvars ファイルの構成ミスと割り当て制限です。この Codelab は、新規ユーザーの標準割り当ての範囲内と、新規ユーザーに適用される $300 分の無料クレジットの範囲内で実行されるように設計されています。VM の作成に失敗した場合は、コントローラ ノードの /var/log/slurm/resume.log ファイルをチェックして API エラーを確認します。
4. 構成のデプロイと検証
構成をデプロイする
Cloud Shell セッションで、slurm-gcp/tf/example フォルダから次のコマンドを実行します。
terraform init terraform apply -var-file=basic.tfvars
設定内容に基づいて、記述された操作を承認するよう求めるメッセージが表示されます。「yes」と入力します。デプロイを開始します。「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
オペレーションが完了するまで数分かかることがありますので、しばらくお待ちください。
デプロイが完了すると、次のような出力が表示されます。
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 インスタンスの作成を確認する
ナビゲーション メニューを開き、[Compute Engine] >VM インスタンス。
コントローラとログイン VM インスタンスが一覧表示されます。
[VM インスタンス] で、Terraform によって作成された 2 つの仮想マシン インスタンスを確認します。
cluster_name フィールドを変更した場合は、名前が異なります。
- g1-controller
- g1-login0
5. Slurm クラスタにログインする
Slurm クラスタにアクセスする
コードエディタ/Cloud Shell のタブに戻ります。次のコマンドを実行して、インスタンスにログインします。<ZONE> は g1-login0 ノードのゾーン（us-central1-b）に置き換えます。
gcloud compute ssh g1-login0 --zone=<ZONE>
このコマンドを実行すると、g1-login0 仮想マシンにログインします。
[SSH] をクリックしても、ログインノードに簡単にアクセスできます。[VM インスタンス] ページの g1-login0 VM の横にあるボタンをクリックし、SSH 接続の新しいタブを開きます。
Cloud Shell を初めて使用する場合は、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)?
「Y」と入力します。パスフレーズを選択するように求められたら、Enter 2 回押して空白のままにします。
ログイン時に次のメッセージが表示された場合:
*** Slurm is currently being configured in the background. *** A terminal broadcast will announce when installation and configuration is complete.
次のメッセージが表示されるまで待ち、ラボに進まないでください（約 5 分）。
*** Slurm login setup complete ***
上記のメッセージが表示されたら、いったんログアウトして g1-login0 に再度ログインして、ラボを続行する必要があります。終了するには、Ctrl+C キーを押してタスクを終了します。
次のコマンドを実行して、インスタンスからログアウトします。
exit
次に、ログイン VM に再接続します。次のコマンドを実行して、g1-login0 ノードのゾーンを <ZONE> に置き換えてインスタンスにログインします。
gcloud compute ssh g1-login0 --zone=<ZONE>
上記のように、接続してすべての設定が完了するまでに 1 ～ 2 分かかる場合があります。
Slurm CLI ツールのツアー
これで、クラスタの Slurm ログインノードにログインできました。これは、ユーザー/管理者とのやり取り、Slurm ジョブのスケジューリング、管理アクティビティ専用のノードです。
いくつかのコマンドを実行して、Slurm コマンドラインを紹介します。
sinfo コマンドを実行して、クラスタのリソースのステータスを表示します。
sinfo
sinfo の出力例を以下に示します。sinfo は、クラスタで使用可能なノード、それらのノードの状態、その他の情報（パーティション、可用性、ノードに課せられた時間制限など）を報告します。
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST debug* up infinite 10 idle~ g1-compute-0-[0-9]
デバッグ パーティションの max_node_count で指定した 10 個のノードが表示されます。「idle~」とマークされます。（ノードはアイドル状態で未割り当てモードにあり、スピンアップできる状態です）。
次に、squeue コマンドを実行して、クラスタのキューのステータスを表示します。
squeue
squeue の想定される出力を以下に示します。squeue は、クラスタのキューのステータスを報告します。これには、クラスタでスケジュールされている各ジョブのジョブ ID、ジョブが割り当てられたパーティション、ジョブの名前、ジョブを起動したユーザー、ジョブの状態、ジョブが実行されている実時間、ジョブが割り当てられたノードが含まれます。実行中のジョブがないため、このコマンドの内容は空です。
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
Slurm コマンド「srun」および「sbatch」キューに入れられるジョブの実行に使用されます「srun」並列ジョブを実行し、mpirun のラッパーとして使用できます。「sbatch」slurm にバッチジョブを送信するために使用され、異なる構成で srun を 1 回または複数回呼び出すことができます。「sbatch」バッチ スクリプトを使用するか、–wrap オプションを使用してコマンドラインからジョブ全体を実行します。
ジョブを実行して Slurm が実際に動作していることを確認し、キューにジョブを取得しましょう。
6. Slurm ジョブの実行とクラスタのスケーリング
Slurm ジョブの実行とクラスタのスケーリング
Slurm クラスタが稼働したので、ジョブを実行してクラスタをスケールアップします。
「sbatch」コマンドを使用すると、Slurm のバッチコマンドとスクリプトを実行できます。「hostname」を実行する簡単な sbatch スクリプトを自動スケーリングされます
g1-login0 にログインした状態で、次のコマンドを実行します。
sbatch -N2 --wrap="srun hostname"
このコマンドは、Slurm バッチコマンドを実行します。sbatch が "-N" で 2 つのノードを実行するように指定している選択します。また、これらの各ノードで「srun ホスト名」を実行することも指定されています。コマンドを選択します。
デフォルトでは、sbatch はその出力を「slurm-%j.out」に書き込みます。コマンドが実行される作業ディレクトリ。ここで、%j は Slurm ファイル名パターンに従ってジョブ ID に置き換えます。この例では、sbatch はユーザーの /home フォルダから実行されています。/home フォルダは、デフォルトでコントローラでホストされる NFS ベースの共有ファイル システムです。これにより、必要に応じてコンピューティング ノードで入出力データを共有できます。本番環境では、クラスタの操作に対するパフォーマンスへの影響を避けるため、稼働中のストレージを /home ストレージから分離する必要があります。個別のストレージ マウントは、tfvars ファイルの「network_storage」ファイルで指定できます。。
sbatch コマンドラインを使用して sbatch スクリプトを実行すると、スケジュールされたジョブのジョブ ID が返されます。次に例を示します。
Submitted batch job 2
sbatch コマンドによって返されたジョブ ID を使用して、ジョブの実行とリソースを追跡および管理できます。次のコマンドを実行して、Slurm ジョブキューを表示します。
squeue
実行したジョブは、次のように表示されます。
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]
コンピューティング ノードがプロビジョニングされていなかったので、Slurm はジョブの要件に応じてコンピューティング インスタンスを自動的に作成します。このプロセスが自動で行われることには、2 つのメリットがあります。まず、HPC クラスタで通常必要とされる、ノードの手動プロビジョニング、ソフトウェアの構成、クラスタへのノードの統合、ジョブのデプロイといった作業が不要になります。2 つ目に、アイドル状態で未使用のノードが最小ノード数の実行までスケールダウンされるため、費用を節約できます。
sinfo コマンドを実行すると、Slurm クラスタがスピンアップしていることを確認できます。
sinfo
これにより、squeue 内のノードが alloc#ノードが割り当てられていることを意味します。
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]
Google Cloud コンソールの [VM インスタンス] セクションで、新しくプロビジョニングされたノードを確認することもできます。新しく割り当てられたノードにジョブが割り当てられる前に、ノードをスピンアップして Slurm が稼働するまでに数分かかります。まもなく、VM インスタンスの一覧は次のようになります。
ノードでジョブが実行されると、インスタンスは「割り当て」モードに移行します。つまり、ジョブがジョブに割り当てられます。
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]
ジョブが完了すると、そのジョブはスキューのリストには表示されなくなり、「alloc」のsinfo 内のノードがアイドル状態に戻るあります。「squeue」を実行ジョブが完了するまで 1 ～ 2 分経過するまで定期的に実行します。
出力ファイル slurm-%j.out は、NFS 共有の /home フォルダに書き込まれ、ホスト名が含まれます。出力ファイル（通常は slurm-2.out）を開くか cat を指定すると、出力ファイルの内容は次のようになります。
g1-compute-0-0 g1-compute-0-1
お疲れさまでした。ジョブを実行して Slurm クラスタをスケールアップしました。
7. MPI ジョブを実行する
次に、すべてのノードで MPI ジョブを実行しましょう。g1-login0 にログインした状態で wget を使用して、次のように C プログラミング言語で記述された MPI プログラムをダウンロードします。
wget https://raw.githubusercontent.com/mpitutorial/mpitutorial/gh-pages/tutorials/mpi-hello-world/code/mpi_hello_world.c
OpenMPI ツールを使用するには、次のコマンドを実行して OpenMPI モジュールを読み込む必要があります。
module load openmpi
ここでは "mpicc"をMPI C コードをコンパイルします。次のコマンドを実行します。
mpicc mpi_hello_world.c -o mpi_hello_world
これにより、C コードがマシンコードにコンパイルされ、Slurm を介してクラスタ全体でコードを実行できるようになります。
次に、任意のテキスト エディタを使用して、「helloworld_batch」という sbatch スクリプトを作成します。
vi helloworld_batch
「i」と入力して vi 挿入モードを開始します。
次のテキストをファイルにコピーして貼り付け、簡単な sbatch スクリプトを作成します。
#!/bin/bash # #SBATCH --job-name=hello_world #SBATCH --output=hello_world-%j.out # #SBATCH --nodes=2 srun mpi_hello_world
Esc キーを押して「:wq」と入力してコードエディタを終了します。引用符は付けません。
このスクリプトは、Slurm バッチ実行環境とタスクを定義します。まず、実行環境を bash として定義します。次に、スクリプトはまず「#SBATCH」という文字列で Slurm オプションを定義します。作成します。ジョブ名は「hello_world」として定義されています。
出力ファイルは「hello_world_%j.out」と設定されます。ここで、Slurm Filename Patterns に従って、%j がジョブ ID に置き換えられます。この出力ファイルは、sbatch スクリプトの実行元ディレクトリに書き込まれます。この例では、ユーザーの /home フォルダです。これは、NFS ベースの共有ファイル システムです。これにより、必要に応じてコンピューティング ノードで入出力データを共有できます。本番環境では、クラスタの操作に対するパフォーマンスへの影響を避けるため、稼働中のストレージを /home ストレージから分離する必要があります。
最後に、このスクリプトを実行するノードの数は 2 として定義します。
オプションを定義した後、実行可能コマンドが提供されます。このスクリプトは、srun コマンドを使用して mpi_hello_world コードを並列に実行します。これは mpirun コマンドの代わりに使用できます。
次に、sbatch コマンドラインを使用して sbatch スクリプトを実行します。
sbatch helloworld_batch
sbatch を実行すると、スケジュールされたジョブのジョブ ID が返されます。次に例を示します。
Submitted batch job 3
これにより、2 つのノードで hostname コマンド（ノードごとに 1 つのタスク）が実行され、出力が hello_world-3.out ファイルに出力されます。
すでに 2 つのノードがプロビジョニングされているため、このジョブはすぐに実行されます。
ジョブが完了してリストに表示されなくなるまで、squeue をモニタリングします。
squeue
完了したら、hello_world-3.out ファイルを開くか cat を指定して、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
5 分間アイドル状態になると（YAML の suspend_time フィールドまたは slurm.conf の SuspendTime フィールドで構成可能）、動的にプロビジョニングされたコンピューティング ノードの割り当てが解除され、リソースが解放されます。これを確認するには、sinfo を定期的に実行して、クラスタサイズが 0 にフォールバックすることを確認します。
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST debug* up infinite 10 idle~ g1-compute-0-[0-9]
クラスタをデプロイしたリージョンで許可されている割り当てまで、さらにインスタンスを起動し、さまざまな MPI アプリケーションを実行してみてください。
8. まとめ
これで、Slurm クラスタが Google Cloud Platform に作成され、その最新機能を使用してワークロードの需要を満たすためにクラスタを自動スケーリングできました。このモデルを使用すると、さまざまなジョブを実行できます。Slurm でノードをリクエストするだけで、数分で数百のインスタンスまでスケーリングできます。
Slurm on GCP の使い方をさらに詳しく学びたい場合は、「Slurm を使用した連携 HPC クラスタの構築」説明しますこの Codelab では、クラウド内に 2 つの連携 Slurm クラスタをセットアップし、オンプレミスとクラウドのどちらでマルチクラスタ フェデレーションを実現するかを説明します。
Slurm の新しい GCP ネイティブ機能を使用して、優れた機能を構築していますか？ご不明な点がございましたら、機能のご提案がある場合は、Google Cloud のハイ パフォーマンス コンピューティング ソリューションのウェブサイトから Google Cloud チームにお問い合わせいただくか、Slurm ヘルプグループ！
Terraform Deployment をクリーンアップする
Slurm ノードからログアウトします。
exit
Deployment を削除する前に、自動スケーリングされたノードをスケールダウンします。「gcloud compute instances delete <インスタンス名>」を実行して、これらのノードを手動で削除することもできます。または、コンソール GUI を使用して複数のノードを選択して [削除] をクリックします。
g1-login0 からログアウトした後、Google Cloud Shell で次のコマンドを実行すると、Terraform のデプロイを簡単にクリーンアップできます。
cd ~/slurm-gcp/tf/examples/basic terraform destroy -var-file=basic.tfvars
プロンプトが表示されたら、「yes」と入力して続行します。この処理には数分かかることがあります。
プロジェクトを削除する
クリーンアップするにはプロジェクトを削除します。
- ナビゲーション メニューで [IAM と管理者
- サブメニューの [Settings] をクリックします。
- 「プロジェクトの削除」というテキストが付いたゴミ箱アイコンをクリックします。
- 画面の指示に沿って操作する
学習した内容
- Terraform を使用して GCP に Slurm をデプロイする方法
- GCP で Slurm を使用してジョブを実行する方法。
- Slurm でクラスタ情報をクエリし、実行中のジョブをモニタリングする方法。
- 特定のジョブ パラメータと要件に対応するために、GCP で Slurm を使用してノードを自動スケーリングする方法。
- GCP 上の Slurm で MPI アプリケーションをコンパイルして実行する方法。
Slurm のサポートを利用する
テスト環境や本番環境でこれらの統合を使用する際のサポートが必要な場合は、SchedMD のお問い合わせページ（https://www.schedmd.com/contact.php）から直接お問い合わせください。
以下のトラブルシューティング ガイドを利用することもできます。
- Slurm on GCP のトラブルシューティング ガイド: https://github.com/SchedMD/slurm-gcp#troubleshooting
- SchedMD のトラブルシューティング ガイド: https://slurm.schedmd.com/troubleshoot.html
最後に、Google Cloud に質問を投稿し、Slurm ディスカッション グループ: https://groups.google.com/g/google-cloud-slurm-discuss
詳細
フィードバック
この Codelab に関するフィードバックは、こちらのリンクからお送りください。フィードバックは 5 分以内に完了します。ありがとうございました