cyclecloud-slurm

Azure HPC入門：Azure CycleCloud + Slurm + Azure NetApp Filesで作るセキュアなHPCクラスタ環境 !Azure CycleCloud と Slurm、Azure NetApp Files を組み合わせた閉域 HPC/GPU クラスタの全体構成図 Azure CycleCloud 8 と Slurm、Azure NetApp Files（ANF）を組み合わせ、バッチ処理・対話型 JupyterLab・複数ユーザー QoS・ストレージ容量クォータ・オートスケール/常時起動の切り替えをプライベート VNet 内で統合制御する共用クラスタ構成。 なぜこの検証を実施したのか 大学の研究室や企業の R&D 部門で HPC / GPU クラスタをクラウド上に整備する際、「単発の VM を立てて SSH する」だけでは運用が回りません。複数の研究者や学生が同じ環境を共用しようとすると、次のような 7 つの運用上の疑問が挙がります。 1. バッチ処理（Slurm 等）でジョブ投入・キューイング・順次実行ができるか（Q1） 2. JupyterLab 等の対話型（インタラクティブ）操作を同じ Slurm 管理下で両立できるか（Q2） 3. 複数の教員・学生で同一クラスタとホーム領域を安全に共用できるか（Q3） 4. 特定のユーザーが計算資源を長時間独占しないよう、利用時間の上限やジョブ優先順位（QoS）を制御できるか（Q4） 5. 共有ホームディレクトリの容量を特定のユーザーが使い切らないよう、利用者単位でストレージ容量を制限できるか（Q5） 6. ジョブ実行時だけ計算ノードを自動起動・停止（オートスケール）してコンピュート課金を抑えつつ、必要な期間は常時起動（占有）に切り替えられるか（Q6） 7. 将来 H100 や A100 など別世代の GPU VM へ置き換える際、どのように設定変更・パーティション分割を行うか（Q7） これら 7 つの問いに対して、Azure CycleCloud 8 + Slurm + Azure NetApp Files（ANF） の組み合わせでどこまで標準機能として答えられるかを実機構成で検証しました。 > 重要: 本記事の情報は 2026年10月時点の Microsoft Learn 公開情報および Azure CycleCloud 8（Slurm 26.05.4 / cyclecloud-slurm テンプレート）に基づきます。今回の実機検証（TC-01〜TC-07）ではサブスクリプションの GPU クォータ制約を回避してオートスケール・QoS・JupyterLab・ANF クォータの一連の制御を実証するため、計算ノード（hpc パーティション）に Standard_D4s_v6 を割り当てて実測し、GPU VM SKU（Standard_NC24ads_A100_v4 等）の割り当ては CycleCloud GUI の設定画面（TC-08）で確認しています。 --- TL;DR（先に結論） - バッチと対話型（JupyterLab）の両立: Slurm の sbatch でバッチジョブを順次実行できるだけでなく、srun --pty bash で確保した計算ノード上で JupyterLab を起動することで、対話型セッションも同じ Slurm のキュー・時間制限管理下に統合できる。 - 0 台からの自動起動・自動停止と常時起動の切り替え: 通常時は計算ノードを 0 台（計算ノードの VM コンピュート課金停止） にしておき、ジョブ投入をトリガーに自動起動、アイドル時間経過後に自動削除できる。一方で、年間予約や集中利用期間などノードを落としたくない場面では azslurm keep_alive コマンド 1 つで 特定ノードを常時起動（自動停止除外） に切り替えられる。 - 利用時間と優先度は Slurm、容量制限は ANF で役割分担: ジョブの最大実行時間（MaxWall）や優先度（Priority）は Slurm アカウンティング（sacctmgr の QoS）で制御し、/shared/home/$USER のディスク容量上限は Azure NetApp Files の個人ユーザークォータ で制御するのがシンプルで堅牢な設計になる。 - GPU SKU の置き換え: 計算ノードの VM サイズ（SKU）は CycleCloud のパーティション設定で管理されており、OS イメージに NVIDIA GPU ドライバー同梱の AlmaLinux 8.10 HPC（almalinux:almalinux-hpc:8_10-hpc-gen2:latest） 等を採用することで、クラスタ設定の VM サイズ変更またはパーティション追加によって GPU SKU を切り替えられる（ただし GPU 世代を変更する際は CUDA バージョンやコンテナイメージの互換性確認を推奨）。 --- 1. 検証の背景・要件マッピング 共用クラスタに求められる 7 つの要件と、本検証における Azure / Slurm 側の実現方式・検証区分を以下の表に整理します。 | # | 共用環境の要件 | 実現コンポーネント | 制御・設定のポイント | 対応する検証項目・確認方法 | | --- | --- | --- | --- | --- | | Q1 | バッチ処理（ジョブ投入・キューイング・順次実行） | Slurm (sbatch / squeue) | sbatch で計算リソースを要求し、空き枠に応じて順次スケジューリング（GPU 利用時は --gres=gpu:N を指定） | 4-1 (TC-01: 実機検証) | | Q2 | JupyterLab 等の対話型（インタラクティブ）操作 | Slurm (srun) + Windows VDI | srun --pty bash で計算ノードを確保して JupyterLab を起動、Bastion 経由の VDI ブラウザから接続 | 4-4 (TC-04: 実機検証) | | Q3 | 複数の教員・学生・メンバーでのクラスタ共用 | Slurm + ANF (/shared/home) | 複数 OS ユーザー（全ノード共通 UID）でホーム領域を NFS 共有し、ジョブをユーザー別に識別 | 4-5 (TC-05: 実機検証) | | Q4 | 利用時間の上限・ジョブ優先順位の制御 | Slurm Accounting (sacctmgr) | normal（学生想定：上限 1 時間）と high（優先研究想定：上限 24 時間・高優先度）の 2 段階 QoS | 4-6 (TC-06: 実機検証) | | Q5 | 利用者ごとのストレージ容量制限 | Azure NetApp Files (User Quota) | ANF ボリュームの個人ユーザークォータ（UID 単位）で容量上限を設定し quota -s で監視 | 4-7 (TC-07: 実機検証) | | Q6 | 従量課金の自動起動/停止と、占有（常時起動）の併用 | CycleCloud Autoscale (azslurm) | ジョブ連動の 0 台↔N 台オートスケールと、azslurm keep_alive による常時起動ノードの固定 | 4-2, 4-3 (TC-02, TC-03: 実機検証) | | Q7 | H100 / A100 等、別 GPU SKU への置き換え・混在 | CycleCloud クラスタテンプレート | Node Array の VM サイズ変更、または hpc / gpu パーティションの分割 | 4-8 (TC-08: GUI 設定画面確認) | > 出典: Azure CycleCloud の概要 / Azure CycleCloud での Slurm の使用 --- 2. アーキテクチャと設計のポイント 2-1. 全体アーキテクチャ図 本検証で構築する環境の全体アーキテクチャを下図に示します。すべてのクラスタ VM からパブリック IP を排除し、Azure Bastion を唯一の入り口とする閉域ネットワーク構成としています。 !Azure CycleCloud + Slurm + Azure NetApp Files による閉域 GPU HPC クラスタ構成図 構成図内の主要コンポーネント、起動形態（常時起動かオートスケールか）、および役割は以下のとおりです。 | レイヤー / 境界 | コンポーネント | 構成・サイズ例 | 起動形態 | 役割と設計上の意図 | | --- | --- | --- | --- | --- | | アクセス経路 (AzureBastionSubnet) | Azure Bastion (bastion-hpc01) | Standard SKU | 常時稼働（PaaS） | クラスタ VM にパブリック IP を持たせず、ポータルや CLI 経由で安全に RDP / SSH 接続を提供する踏み台サービス。 | | クラスタサブネット (subnet-cluster01 10.0.1.0/24) | Azure NAT Gateway (natgw-hpc01) | Standard SKU | 常時稼働（PaaS） | 2026年3月末以降のプライベートサブネット既定化（defaultOutboundAccess: false）に対応し、閉域 VM から Azure Resource Manager（management.azure.com）やパッケージリポジトリへの送信通信を提供する。 | | クラスタサブネット (subnet-cluster01 10.0.1.0/24) | Windows VDI Node (vdi-win01) | Standard_D4s_v6 (Windows Server) | 利用時のみ起動（手動停止可） | 閉域 VNet 内の CycleCloud Web UI（HTTPS）および計算ノード上の JupyterLab（HTTP 8888）へブラウザアクセスするための作業用端末。 | | クラスタサブネット (subnet-cluster01 10.0.1.0/24) | CycleCloud Server (cc-server01) | Standard_D4s_v6 (AlmaLinux / RHEL) | クラスタ稼働中は常時起動（1台） | クラスタのテンプレート管理・VM プロビジョニング・オートスケールを司るオーケストレーター（インフラ管理サーバー）。Slurm のジョブスケジューラそのものではなく、裏方で Azure VM/VMSS を作成・削除する。 | | クラスタサブネット (subnet-cluster01 10.0.1.0/24) | Slurm Head Node (scheduler) | Standard_D4s_v6 (AlmaLinux 8.10 HPC) | クラスタ稼働中は常時起動（1台） | Slurm のスケジューラーノード兼ログインノード。slurmctld（ジョブスケジューラ）および slurmdbd（アカウンティング）を実行し、学生・研究者が SSH ログインして sbatch / srun を投入する窓口となる。ジョブが入ると azslurm 経由で CycleCloud Server の API を呼び出して計算ノードの起動を要求する。 | | クラスタサブネット (subnet-cluster01 10.0.1.0/24) | Compute Nodes (hpc / gpu / htc) | GPU / 汎用 VM SKU（初期 0 台、ジョブ連動） | オートスケール（0台↔N台）<br>※keep_alive で常時起動化も可 | AlmaLinux 8.10 HPC イメージで起動する計算ノード群。ジョブがない時は 0 台（VM コンピュート課金ゼロ） で待機し、ジョブ投入時に自動起動、アイドル時に自動削除される。 | | ANF 委任サブネット (subnet-anf01 10.0.253.0/28) | Azure NetApp Files (anf-stg / vol01) | Standard サービスレベル / 4 TiB プール | 常時稼働（PaaS） | /shared/home/$USER 等の共有 NFS ボリュームを提供し、UID 単位のユーザークォータで容量上限を強制する。 | | 認証・保管 (Identity & Storage) | User Assigned Managed Identity (mngdid-rg-hpc01) | RG Contributor + Storage Blob Data Contributor + Sub Reader | — | CycleCloud サーバーおよびクラスタに割り当て、シークレット管理なしに VM 作成・Locker 読み書き・SKU カタログ取得を行う。 | | 認証・保管 (Identity & Storage) | CycleCloud Locker (stgacctcc01) + Private Endpoint | StorageV2 + privatelink.blob.core.windows.net | 常時稼働（PaaS） | CycleCloud が cluster-init スクリプトや Slurm パッケージを配置する Blob ストレージ。Private Endpoint 経由で閉域アクセスする。 | > 補足（CycleCloud Server と Slurm Head Node の違い・常時起動の範囲）: > - CycleCloud Server はスケジューラーノードではありません。CycleCloud Server（cc-server01）は Azure リソースを管理するオーケストレーターであり、Slurm のスケジューラー（兼ユーザーのログインノード）は CycleCloud が起動する Slurm Head Node（scheduler） です。 > - ジョブをいつでも受け付けられるようにするため、クラスタ稼働中は CycleCloud Server と Slurm Head Node (scheduler) の 2 台（安価な汎用 VM）は常時起動させておき、高価な Compute Nodes（GPU 計算ノード）だけを 0 台↔N 台でオートスケールさせるのが基本運用です（長期休暇等でクラスタ自体を使わない期間は、CycleCloud 上でクラスタを Terminate して scheduler も削除し、cc-server01 自体も VM 停止できます）。 2-2. なぜこの構成なのか（3 つの設計判断） 1. すべての計算・管理 VM からパブリック IP を排除（Bastion + Windows VDI + NAT Gateway 方式） 大学・研究機関のセキュリティポリシーでは、計算ノードや管理サーバーへインターネットから直接インバウンド接続させない構成が強く求められます。各 VM にはパブリック IP を付与せず、インバウンドは Azure Bastion 経由のみとし、アウトバウンド通信（ARM API やパッケージ取得）はサブネットに紐付けた Azure NAT Gateway で明示的に制御します。CycleCloud の Web UI や計算ノード上で起動する JupyterLab（ポート 8888）へは、同一 VNet 内に配置した Windows VDI ノードのブラウザからプライベート IP でアクセスすることで、SSH ポートフォワーディングなしに直感的な GUI 操作を実現できます。 2. HPC / GPU ドライバー導入済みの AlmaLinux 8.10 HPC イメージ オートスケールで計算ノードが動的に起動・破棄される環境では、起動のたびにドライバーやライブラリをビルドしているとジョブ開始までの待ち時間が増加します。Azure Marketplace で提供されている almalinux:almalinux-hpc:8_10-hpc-gen2:latest（または microsoft-dsvm:ubuntu-hpc:2404:latest）は、NVIDIA GPU ドライバー・Mellanox OFED（InfiniBand ドライバー）・主要な HPC ライブラリがあらかじめ組み込まれているため、GPU SKU を選択した際もプロビジョニング完了後すぐにジョブを実行できます。 3. 「計算リソース制御（Slurm）」と「ストレージ容量制御（ANF）」の分離 Slurm は CPU / メモリ / GPU（GRES）の割り当て時間や優先度を制御するのには優れていますが、NFS 上のホームディレクトリ容量の制限はファイルシステム側の責務です。Azure NetApp Files（ANF）のユーザークォータ機能を組み合わせることで、Linux 標準の UID に基づいてストレージ側で確実な容量上限をかけられます。 > 出典: Azure HPC/AI VM イメージ / Azure NetApp Files の既定および個別のユーザーとグループのクォータについて 2-3. 利用者（学生・研究者）と管理者のアカウント設計・アクセス導線 「学生が使う場合、どこにアカウントを作り、どのように環境へ入っていくのか（CycleCloud に入るのか？ VDI 経由なのか？）」という運用イメージを整理します。 結論として、学生は「CycleCloud の管理画面」には一切入りません。学生が使うのは 「Slurm ヘッドノード（scheduler）への SSH」 と、JupyterLab を使う場合の 「VDI のブラウザ」 だけです。 | 誰が（ロール） | 何をするか | どこに入るか（接続経路） | どこにアカウントを作るか | | --- | --- | --- | --- | | 管理者<br>（教職員・インフラ担当） | クラスタ起動/停止・GPU SKU 変更・クォータ設定 | Bastion → VDI（RDP）→ ブラウザで CycleCloud 管理画面（cc-server01） | CycleCloud 管理画面 ＋ Azure RBAC | | 学生・研究者<br>（バッチジョブ実行） | sbatch でジョブ投入・結果確認 | Bastion（または学内 VPN）→ Slurm ヘッドノード（scheduler）へ直接 SSH<br>※VDI や CycleCloud は使わない | Linux OS ユーザー（共通 UID）＋ Slurm DB（sacctmgr） | | 学生・研究者<br>（JupyterLab 対話利用） | ブラウザで Notebook を対話実行 | Bastion → VDI（RDP） → scheduler へ SSH して srun で Jupyter 起動 → VDI 内ブラウザで接続 | Linux OS ユーザー ＋ Slurm DB ＋ VDI ログイン用アカウント | > ポイント（Linux アカウントの一元管理）: > オートスケールで動的に起動する計算ノードでも同じ UID / ホーム（/shared/home/$USER）でジョブが動くよう、実運用では CycleCloud 8 の組み込みユーザー管理や Active Directory / Microsoft Entra Domain Services / LDAP 連携で全ノード共通の UID を一元管理します。 学生が Bastion 経由で入る場合、Azure の RBAC 付与は必要か？ Azure Bastion を入り口にする場合、接続方式によって学生への Azure RBAC 付与が「必要なケース」と「不要にできるケース」に分かれます。 | 接続方式 | 学生への Azure RBAC | 必要な権限・運用の特徴 | | --- | --- | --- | | A. Azure Portal / Azure CLI から Bastion 接続<br>（標準の Bastion SSH / RDP / az network bastion tunnel） | 必要 | 学生の Entra ID に対し、①対象 VM（scheduler / vdi-win01）、②対象 VM の NIC、③Azure Bastion リソースの 3 点に対する Reader（閲覧者）ロールが必要。 | | B. Bastion の「共有可能リンク（Shareable Link）」を利用<br>（Bastion Standard SKU 以上の機能） | 不要 | 管理者が発行した専用 URL を学生に配布する方式。学生は Azure Portal 権限（RBAC）や Entra ID なしで、ブラウザから URL を開いて Linux の SSH 秘密鍵（または RDP 資格情報）だけでログイン可能。 | | C. 学内 VPN / ExpressRoute 経由で直接接続<br>（大学キャンパス網と Azure VNet を接続する場合） | 不要 | Bastion を介さず手元 PC からプライベート IP（10.0.1.7）へ直接 SSH できるため、Azure RBAC は一切不要（Linux アカウントと SSH 鍵のみで完結）。 | > 出典: Azure Bastion FAQ - 仮想マシンにアクセスするために必要なロールはありますか? / Bastion の共有可能リンクを作成する --- 3. 環境構築手順（ハンズオン準拠） ここからは、実際に Azure CLI で基盤リソースを展開し、CycleCloud 上で Slurm クラスタを構築する手順を示します。 > 注意: CycleCloud クラスタを展開する際、VNet・ANF・CycleCloud サーバー・計算ノードは同一リージョンに配置します（本検証では変数 $LOCATION="southeastasia" で統一しています）。 3-1. 事前準備（RG・マネージド ID・VNet・NAT Gateway・閉域 Storage・Bastion） まず、リソースグループ、CycleCloud サーバーに付与するユーザー割り当てマネージド ID、仮想ネットワーク（3 つのサブネット＋NAT Gateway）、および Private Endpoint 付きの CycleCloud Locker 用ストレージアカウントを作成します。 > 重要（2026年3月31日以降の仕様変更）: Azure では 2026年3月31日以降の API バージョンで新規作成されるサブネットが既定でプライベート サブネット（defaultOutboundAccess: false）になりました。パブリック IP を持たない cc-server01 や scheduler から Azure Resource Manager（management.azure.com）や GitHub へアクセスするため、subnet-cluster01 には Azure NAT Gateway を必ず関連付けます。 <details><summary>01-infra-prereq.sh: RG・マネージドID・VNet・NAT Gateway・閉域Storage・Bastionの作成（クリックで展開）</summary> # 01-infra-prereq.sh # リージョンとリソース名の定義（全リソースを同一リージョンに統一する） RG="rg-hpc01-sea" LOCATION="southeastasia" VNET="vnet-hpc01" MNGD_ID="mngdid-rg-hpc01" STG_ACCT="stgacctcc01$(openssl rand -hex 2)" # 1. リソースグループの作成 az group create -n "$RG" -l "$LOCATION" # 2. CycleCloud 用ユーザー割り当てマネージド ID の作成と RBAC ロール付与 az identity create -n "$MNGD_ID" -g "$RG" -l "$LOCATION" PRINCIPAL_ID=$(az identity show -n "$MNGD_ID" -g "$RG" --query principalId -o tsv) RG_ID=$(az group show -n "$RG" --query id -o tsv) SUB_ID=$(az account show --query id -o tsv) az role assignment create --assignee-object-id "$PRINCIPAL_ID" --assignee-principal-type ServicePrincipal --role "Contributor" --scope "$RG_ID" az role assignment create --assignee-object-id "$PRINCIPAL_ID" --assignee-principal-type ServicePrincipal --role "Storage Blob Data Contributor" --scope "$RG_ID" az role assignment create --assignee-object-id "$PRINCIPAL_ID" --assignee-principal-type ServicePrincipal --role "Reader" --scope "/subscriptions/$SUB_ID" # 3. 仮想ネットワークと 3 つのサブネット（cluster + NAT Gateway / anf委任 / Bastion）の作成 az network nsg create -g "$RG" -n "nsg-cluster01" -l "$LOCATION" az network public-ip create -g "$RG" -n "pip-natgw-hpc01" -l "$LOCATION" --sku Standard az network nat gateway create -g "$RG" -n "natgw-hpc01" -l "$LOCATION" --public-ip-addresses "pip-natgw-hpc01" --idle-timeout 10 az network vnet create -g "$RG" -n "$VNET" -l "$LOCATION" \ --address-prefixes 10.0.0.0/16 \ --subnet-name "subnet-cluster01" --subnet-prefixes 10.0.1.0/24 \ --network-security-group "nsg-cluster01" --nat-gateway "natgw-hpc01" # ANF 用サブネット（Microsoft.NetApp/volumes へ委任） az network vnet subnet create -g "$RG" --vnet-name "$VNET" -n "subnet-anf01" \ --address-prefixes 10.0.253.0/28 --delegations "Microsoft.NetApp/volumes" # Azure Bastion 用サブネット az network vnet subnet create -g "$RG" --vnet-name "$VNET" -n "AzureBastionSubnet" \ --address-prefixes 10.0.254.0/26 # 4. CycleCloud Locker 用ストレージアカウントと Private Endpoint の作成 az storage account create -n "$STG_ACCT" -g "$RG" -l "$LOCATION" --sku Standard_LRS --kind StorageV2 --allow-blob-public-access false STG_ID=$(az storage account show -n "$STG_ACCT" -g "$RG" --query id -o tsv) az network private-dns zone create -g "$RG" -n "privatelink.blob.core.windows.net" az network private-dns link vnet create -g "$RG" -z "privatelink.blob.core.windows.net" -n "link-$VNET" -v "$VNET" -e false az network private-endpoint create -g "$RG" -n "pe-$STG_ACCT-blob" -l "$LOCATION" \ --vnet-name "$VNET" --subnet "subnet-cluster01" \ --private-connection-resource-id "$STG_ID" --group-id "blob" --connection-name "conn-blob" az network private-endpoint dns-zone-group create -g "$RG" --endpoint-name "pe-$STG_ACCT-blob" \ -n "default" --private-dns-zone "privatelink.blob.core.windows.net" --zone-name "blob" # 5. Azure Bastion の展開 az network public-ip create -g "$RG" -n "pip-bastion-hpc01" -l "$LOCATION" --sku Standard az network bastion create -g "$RG" -n "bastion-hpc01" -l "$LOCATION" \ --public-ip-address "pip-bastion-hpc01" --vnet-name "$VNET" --sku Standard --enable-tunneling true </details> 作成後の検証コマンド: az network private-endpoint show -g "$RG" -n "pe-$STG_ACCT-blob" --query "provisioningState" -o tsv # Succeeded が返ることを確認 3-2. Azure NetApp Files（ANF）の展開と共有ボリューム作成 続いて、/shared/home/$USER としてマウントする Azure NetApp Files のアカウント、容量プール（4 TiB / Standard）、および NFSv3 ボリューム（vol01）を作成します。 <details><summary>02-create-anf.sh: ANFアカウント・容量プール・NFSボリュームの作成（クリックで展開）</summary> # 02-create-anf.sh ANF_ACCT="anf-stg" ANF_POOL="anf-stg-pool01" ANF_VOL="vol01" # 1. NetApp アカウントと容量プール（4 TiB, Standard）の作成 az netappfiles account create -g "$RG" -n "$ANF_ACCT" -l "$LOCATION" az netappfiles pool create -g "$RG" --account-name "$ANF_ACCT" -n "$ANF_POOL" -l "$LOCATION" \ --size 4 --service-level Standard # 2. NFSv3 ボリューム（100 GiB、subnet-anf01 に配置）の作成 az netappfiles volume create -g "$RG" --account-name "$ANF_ACCT" --pool-name "$ANF_POOL" -n "$ANF_VOL" -l "$LOCATION" \ --service-level Standard --usage-threshold 100 --file-path "vol01" \ --vnet "$VNET" --subnet "subnet-anf01" --protocol-types NFSv3 \ --rule-index 1 --allowed-clients "10.0.0.0/16" --unix-read-write true --has-root-access true </details> 作成後、Slurm テンプレートに設定する ANF のマウント先 IP アドレスを確認します。 az netappfiles volume show -g "$RG" --account-name "$ANF_ACCT" --pool-name "$ANF_POOL" -n "$ANF_VOL" --query "mountTargets[0].ipAddress" -o tsv # 例: 10.0.253.4 が返ることを確認 3-3. CycleCloud サーバーと Windows VDI ノードの展開 CycleCloud サーバー VM（パブリック IP なし・ユーザー割り当てマネージド ID アタッチ）と、ブラウザ操作用の Windows VDI ノードを subnet-cluster01 に作成します。 <details><summary>03-create-cyclecloud-and-vdi.sh: CycleCloudサーバーとWindows VDIの展開（クリックで展開）</summary> # 03-create-cyclecloud-and-vdi.sh ID_RES_ID=$(az identity show -n "$MNGD_ID" -g "$RG" --query id -o tsv) # Marketplace の CycleCloud イメージ規約に同意 az vm image terms accept --urn "azurecyclecloud:azure-cyclecloud:cyclecloud8-gen2:latest" # 1. CycleCloud サーバー VM の作成（パブリック IP なし、マネージド ID 付与） az vm create -g "$RG" -n "cc-server01" -l "$LOCATION" \ --image "azurecyclecloud:azure-cyclecloud:cyclecloud8-gen2:latest" \ --size "Standard_D4s_v6" \ --vnet-name "$VNET" --subnet "subnet-cluster01" --public-ip-address "" \ --private-ip-address "10.0.1.6" --nsg "" \ --assign-identity "$ID_RES_ID" \ --admin-username "azureuser" --ssh-key-values "@ssh_keys/id_rsa.pub" # 2. Windows VDI ノードの作成（CycleCloud Web UI / JupyterLab アクセス用） az vm create -g "$RG" -n "vdi-win01" -l "$LOCATION" \ --image "MicrosoftWindowsServer:WindowsServer:2022-datacenter-g2:latest" \ --size "Standard_D4s_v6" \ --vnet-name "$VNET" --subnet "subnet-cluster01" --public-ip-address "" --nsg "" \ --admin-username "azureuser" --admin-password "<StrongPassword123!>" </details> 3-4. Slurm クラスタテンプレート（cyclecloud-slurm）の導入と GPU 設定 Azure Bastion 経由で vdi-win01 に RDP 接続し、ブラウザから CycleCloud Web UI へアクセスして初期セットアップ（Site Name、Managed Identity 認証、Storage Locker stgacctcc01 の選択、管理者 SSH 公開鍵の登録）を完了します。 !CycleCloud の Subscriptions 設定画面における Managed Identity 認証と Storage Locker の登録 CycleCloud の Subscriptions 設定画面。Orchestrator Configuration と Locker Configuration の双方でユーザー割り当てマネージド ID（mngdid-rg-hpc01）を指定し、閉域 Storage Account（stgacctcc011402）を Locker として紐付けます。 その後、CycleCloud サーバーへ SSH ログインし、GitHub から cyclecloud-slurm テンプレートを取得してインポートします（CycleCloud 8 標準搭載の Slurm テンプレートをそのまま利用することも可能です）。 <details><summary>04-import-slurm-template.sh: cyclecloud-slurm 3.0.10 の取得とインポート（クリックで展開）</summary> # 04-import-slurm-template.sh（cc-server01 上で実行） mkdir -p ~/cyclecloud_projects && cd ~/cyclecloud_projects wget https://github.com/Azure/cyclecloud-slurm/archive/refs/tags/3.0.10.zip unzip 3.0.10.zip ln -s cyclecloud-slurm-3.0.10 cyclecloud-slurm cd cyclecloud-slurm/templates # テンプレート名を Slurm-poc01 としてインポート cp -p slurm.txt slurm.txt.org sed -i 's/\[cluster Slurm\]/[cluster Slurm-poc01]/' slurm.txt cyclecloud import_template -f slurm.txt </details> CycleCloud GUI で新規 Slurm クラスタ（Slurm-poc01）を作成する際、以下の 4 点を設定します。 | 設定タブ | パラメータ | 設定値 | 理由 | | --- | --- | --- | --- | | Required Settings | Scheduler VM Type / HPC VM Type / GPU VM Type | Scheduler: Standard_D4s_v6 / HPC: Standard_D4s_v6 / GPU: Standard_NC24ads_A100_v4 等 | 計算ノード（hpc / gpu パーティション）に用途別の VM サイズを割り当てるため | | Required Settings | Autoscale / Max Nodes | Start and stop execute instances automatically を ON（初期起動台数は 0） | ジョブがない時は 0 台に保ち、投入時のみスケールアウトさせるため | | Network Attached Storage | File-system Mount for /shared | Use Builtin NFS を OFF → External NFS / IP 10.0.253.4 / Export Path /vol01 | ANF ボリュームを全ノード共通の /shared（/shared/home/$USER）としてマウントするため | | Advanced Settings | Managed Id / OS (Alma Linux 8) | Managed Id: mngdid-rg-hpc01 / OS: Alma Linux 8 (almalinux:almalinux-hpc:8_10-hpc-gen2:latest) | Locker アクセス用マネージド ID と NVIDIA GPU ドライバー同梱の HPC イメージを指定し、完全閉域（Return Proxy・Public Head Node オフ）で起動するため | !CycleCloud の Required Settings タブにおける Scheduler / HPC / GPU VM Type と Autoscale の設定 Required Settings タブの設定画面。Scheduler VM Type・HPC VM Type・GPU VM Type をそれぞれ指定し、Autoscale を有効化します。 !CycleCloud の Network Attached Storage タブにおける External NFS（Azure NetApp Files）の設定 Network Attached Storage タブの設定画面。/shared の Use Builtin NFS のチェックを外して External NFS を選択し、ANF ボリュームのマウント IP（10.0.253.4）と Export Path（/vol01）を指定します（下部の Additional Filesystem Mount で二重に /shared を指定しないよう注意します）。 !CycleCloud の Advanced Settings タブにおける Managed Identity と AlmaLinux 8 HPC イメージの設定 Advanced Settings タブの設定画面。Managed Id に rg-hpc01-sea/mngdid-rg-hpc01 を選択し、OS に Alma Linux 8（almalinux:almalinux-hpc:8_10-hpc-gen2:latest）を指定します。 > 出典: GitHub - Azure/cyclecloud-slurm --- 4. 7つの運用シナリオ実機検証（TC-01〜TC-08） クラスタを開始（Start）すると、約 6 分で Slurm ヘッドノード（scheduler）が Ready（緑色）となり、計算ノードは 0 台 の状態で待機します。ここから冒頭の 7 つの質問（Q1〜Q7）に対応する 8 つのテストケースを順に検証します。 !Slurm クラスタ起動直後の CycleCloud 画面（scheduler のみ稼働、計算ノードは 0 台） クラスタ起動完了直後の状態。scheduler ノード（1 台・4 コア）のみが稼働（緑色）しており、計算ノードは 0 台で課金が発生していないことが確認できます。 4-1. バッチ処理とジョブの順次実行（TC-01 / Q1） Slurm ヘッドノード（10.0.1.7）へ SSH ログインし、バッチジョブスクリプトを作成して sbatch で 3 本連続投入します。 <details><summary>gpu-job01.sh: Slurmバッチジョブスクリプト（クリックで展開）</summary> #!/bin/bash #SBATCH --partition=hpc #SBATCH --job-name=gpu-job01 #SBATCH --nodes=1 #SBATCH --ntasks=1 #SBATCH --cpus-per-task=4 #SBATCH --time=00:10:00 #SBATCH --output=slurm-%x-%j.out # 1. ジョブ開始時刻と、割り当てられた計算ノードのホスト名（例: slurm-poc01-hpc-1）を出力 echo "=== Job Start: $(date) on $(hostname) ===" # 2. GPU 搭載ノードなら nvidia-smi を出力し、GPU 非搭載の汎用 VM なら代わりに lscpu で CPU 情報を出力 nvidia-smi 2>/dev/null || lscpu | grep -E "Model name|Socket|Thread|NUMA|CPU\(s\):" # 3. squeue で実行中（R）状態や複数ジョブの挙動を観察できるよう、模擬処理として 120 秒間維持 sleep 120 # 4. ジョブ終了時刻を出力 echo "=== Job End: $(date) ===" </details> スクリプト後半の 4 行は以下の意味を持っています。 - echo "=== Job Start: $(date) on $(hostname) ===": ジョブの開始日時と、実際に処理が走っているホスト名（ヘッドノードではなく計算ノード slurm-poc01-hpc-1 等であることの証跡）を出力します。 - nvidia-smi 2>/dev/null || lscpu | grep -E ...: まず nvidia-smi で GPU の認識状態を表示し、もし GPU 非搭載の汎用 VM（今回の Standard_D4s_v6 代替検証環境など）で nvidia-smi が失敗した場合（||）は、代わりに lscpu で CPU のモデル名・コア数・NUMA 構成を抜粋して出力します。GPU ノード・CPU ノードのどちらでも同じスクリプトのまま動作確認できる書き方です。 - sleep 120: 本来の機械学習や数値計算の代わりに 120 秒間待機します。処理が一瞬で終わると squeue 上の R（Running）状態や複数ジョブのキューイングを確認できないために入れています。 - echo "=== Job End: $(date) ===": 120 秒経過後のジョブ終了日時を記録します。 <details><summary>ジョブの3本連続投入とキュー確認コマンド（クリックで展開）</summary> sbatch ~/gpu-job01.sh sbatch ~/gpu-job01.sh sbatch ~/gpu-job01.sh squeue </details> これにより、計算資源の空き枠に応じてジョブが割り当てられ、完了後に結果ログを取得できます。空きノードが複数あれば 3 本は並行実行されます。順次実行を確認する場合は、利用可能な計算資源を制限した条件で、先行ジョブの終了後に後続ジョブが開始することを確認します。 実行結果はどこで確認するか 結果を確認するのは CycleCloud 管理画面ではなく、ジョブを投入したユーザーで SSH 接続した scheduler 上です。 上のスクリプトでは #SBATCH --output=slurm-%x-%j.out を指定しているため、%x がジョブ名、%j がジョブ ID に置き換わり、例えばジョブ ID 12 の出力ファイルは slurm-gpu-job01-12.out になります。標準エラーも、別途 --error を指定しなければ同じファイルへ出力されます。 相対パスの出力先は、通常 sbatch を実行したときの作業ディレクトリ です。sbatch ~/gpu-job01.sh と指定しても、スクリプトの保存場所が出力先になるわけではありません。/shared/home/$USER に移動して投入した場合に、その共有ホームへ保存されます。--chdir を指定した場合は、そのディレクトリが基準です。 <details><summary>ログの場所・実行中ジョブ・終了状態を確認するコマンド（クリックで展開）</summary> # ジョブを投入したディレクトリで実行。12 は実際のジョブ ID に置換 pwd ls -lt slurm-gpu-job01-*.out cat slurm-gpu-job01-12.out # 自分の待機中・実行中ジョブ（終了したジョブは通常表示されない） squeue -u "$USER" # 今日のジョブ履歴と、特定ジョブの終了状態・時刻・実行ノード sacct -S today -u "$USER" -X --format=JobID,JobName,State,ExitCode,Start,End,NodeList sacct -j 12 --format=JobID,State,ExitCode,NodeList,Elapsed,ReqTRES,AllocTRES # コントローラーに記録が残っていれば WorkDir・StdOut・StdErr を確認できる scontrol show job 12 </details> scontrol show job は古い終了ジョブでは記録が消えていることがあります。その場合は sacct で履歴を確認し、投入時の作業ディレクトリからログを探します。共有領域に保存されたログは、計算ノードが自動削除された後も scheduler から確認できます。 | 確認対象 | 見る場所・項目 | 判定のポイント | | --- | --- | --- | | 待機・実行状況 | squeue の ST と NODELIST(REASON) | PD は待機、CF は起動・構成中、R は実行中 | | 終了状態 | sacct の State / ExitCode | COMPLETED / 0:0 はスクリプトの正常終了。ただし内部の全コマンド成功を保証しない | | アプリケーションの出力 | slurm-gpu-job01-<JOBID>.out | 開始・終了時刻、実行ホスト名、計算結果、エラーを読む | | 順次実行 | 3 本それぞれの Start / End | 同じ制約資源を使う先行ジョブの終了後に、後続ジョブが開始しているか確認 | D4s_v6 で NVIDIA-SMI のエラーが出る場合 2026年11月4日の再実行では、Standard_D4s_v6 の計算ノード上で次の出力を確認しました。 === Job Start: Wed Nov 4 07:30:05 UTC 2026 on slurm-poc01-hpc-1 === NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running. Standard_D4s_v6 は GPU 非搭載の VM です。 この構成では GPU 動作確認はできませんが、CPU 情報の出力と 120 秒後の終了により、計算ノード上でバッチが動いたことは確認できます。上のスクリプトは nvidia-smi 失敗時に CPU 情報へ切り替えるため、Slurm 上で COMPLETED になっていても、GPU 利用に成功したことにはなりません。GPU 搭載 VM でもドライバー障害時には同様の切り替えが起きるため、このスクリプトはバッチの動作確認用であり、GPU の合否判定用ではありません。 GPU の検証では、GPU 搭載 VM と適切な NVIDIA ドライバーを用意し、#SBATCH --gres=gpu:1 を追加して GPU を要求したうえで、nvidia-smi の成功を別途確認してください。 > 出典: Slurm sbatch（出力先・ファイル名の指定） / Slurm sacct（実行履歴） / Azure Dsv6 シリーズの仕様 4-2. 計算ノードの自動起動・自動停止（TC-02 / Q6） CycleCloud + Slurm の大きなメリットが、「ジョブがない時は計算ノード 0 台、ジョブが入ると自動起動、終われば自動削除」 というオートスケール動作です。 1. ジョブ投入前: CycleCloud GUI 上で計算ノードが 0 台（sinfo の STATE が idle~：未起動待機）であることを確認します。 2. ジョブ投入時: sbatch ~/gpu-job01.sh を 3 本実行すると、sinfo の STATE が alloc#（プロビジョニング中）、squeue の STATE が CF（Configuring）になり、CycleCloud 側で計算ノード VMSS（Slurm-poc01-hpc-[1-3]）の作成が自動的に開始されます。 !sbatch 投入により CycleCloud 上で計算ノード 3 台が自動起動し squeue が CF 状態になっている画面 ジョブ投入直後の画面（左：CycleCloud Web UI、右：ヘッドノード SSH ターミナル）。sbatch をトリガーに hpc ノード 3 台のプロビジョニングが自動開始され、squeue 上で CF（Configuring）として表示されています。 3. ノード起動完了とジョブ実行: 約 7〜8 分で VM が起動して Slurm クラスタに参加すると、STATE が R（Running）へ遷移してジョブが実行され、slurm-gpu-job01-1.out に計算ノード（slurm-poc01-hpc-1）の実行結果が出力されます。 !計算ノードの起動完了後にジョブが実行完了し sacct と結果ログが出力された画面 計算ノード起動完了後の実行結果。sacct でジョブが COMPLETED となり、slurm-gpu-job01-1.out に計算ノード slurm-poc01-hpc-1 上での出力が記録されています。 4. ジョブ終了後の自動停止: ジョブ完了後、Slurm の SuspendTime（既定 300 秒）が経過すると、計算ノード VM は自動的に Deallocate（削除）され、再び 0 台（課金ゼロ） に戻ります。 > ポイント: GPU VM の GPU 枚数が Slurm の GRES に正しく認識されない場合（Requested node configuration is not available となる場合）は、ヘッドノードの /opt/azurehpc/slurm/autoscale.json に slurm_gpus を明示定義して azslurm scale と azslurm buckets を実行することで即時反映できます（詳細は「5. ハマったポイント」参照）。 4-3. azslurm keep_alive による計算ノードの常時起動（TC-03 / Q6） 「通常はオートスケールで節約したいが、特定の研究期間や年間予約枠のノードは毎回数分の起動待ちをせずに常時起動（占有）させておきたい」という要件（Q6）に対しては、クラスタを作り直すことなく azslurm keep_alive コマンドでノード単位に制御できます。 <details><summary>05-keep-alive.sh: 特定ノードを自動停止対象から除外して常時起動化する手順（クリックで展開）</summary> # 1. 対象の計算ノードが起動している状態で、ヘッドノードにて keep_alive を設定 sudo azslurm keep_alive --set --node-list Slurm-poc01-hpc-1 # 2. slurmctld を再起動し、azslurm scale で反映 sudo systemctl restart slurmctld sudo azslurm scale cat /etc/slurm/keep_alive.conf # （常時起動を解除して再びオートスケールに戻す場合） sudo azslurm keep_alive --remove --node-list Slurm-poc01-hpc-1 sudo systemctl restart slurmctld sudo azslurm scale </details> !azslurm keep_alive コマンドにより Slurm-poc01-hpc-1 を自動停止対象から除外（SuspendExcNodes）した画面 azslurm keep_alive --set の実行画面。CycleCloud GUI 側の Status Message が KeepAlive に変わり、/etc/slurm/keep_alive.conf の SuspendExcNodes=Slurm-poc01-hpc-1 によってアイドル時も自動停止されなくなります。 これにより、同じ 1 つの Slurm クラスタの中で「必要なときだけ起動する従量ノード」と「常時起動しておく固定ノード」を柔軟に使い分けられることが確認できます。 > 出典: Azure CycleCloud Slurm - パーティションやノードをオートスケールから除外する (keep_alive) 4-4. Slurm 管理下での対話型利用（JupyterLab）（TC-04 / Q2） 「バッチだけでなく JupyterLab で対話的に試行錯誤したい」という要件（Q2）に対し、計算ノードへ直接勝手に入るのではなく、Slurm のインタラクティブジョブ（srun）として計算リソースと利用時間を確保した上で JupyterLab を起動します。 <details><summary>srunによる対話ジョブ取得とJupyterLab起動コマンド（クリックで展開）</summary> # 1. ヘッドノードから最大 1 時間を指定して計算ノードの対話シェルを取得 srun --partition=hpc --time=01:00:00 --pty bash # 2. 割り当てられた計算ノード（slurm-poc01-hpc-1）上で IP を確認し、JupyterLab を起動 hostname -I ~/.local/bin/jupyter lab --no-browser --ip=0.0.0.0 --port=8888 </details> 起動時に出力される URL（http://10.0.1.8:8888/lab）を、Azure Bastion 経由で接続している Windows VDI ノード（vdi-win01）のブラウザ で開きます。 !srun で確保した計算ノード上で JupyterLab を起動し Windows VDI のブラウザから接続して実行している画面 Windows VDI 内のブラウザから計算ノード（10.0.1.8:8888）の JupyterLab に接続し、Notebook セル上で !hostname（slurm-poc01-hpc-1）と !lscpu を対話実行している様子。右側のターミナルでは srun によってセッションが Slurm ジョブとして管理されています。 この方式のメリットは以下の 2 点です。 - Notebook セルから対話的にコードを実行でき、ファイルは /shared/home/$USER（ANF）に直接保存される。 - 対話型で利用中のノードも squeue 上に 1 ジョブとして可視化され、指定した --time（または QoS の上限時間）が来れば自動的に解放されるため、「誰かが Jupyter を開いたまま放置して計算ノードがずっと空かない」という共用クラスタ特有の課題を防げる。 4-5. 複数ユーザーでのクラスタ共用（TC-05 / Q3） 共用環境（Q3）の検証として、全ノード共通の UID を持つ 2 名のユーザー（user01：学生想定、user02：教員想定）を作成し、ホームディレクトリを ANF 上の /shared/home/$USER に配置します。 # 共通 UID で user01 / user02 を作成し、ホームを /shared/home 配下に配置 sudo useradd -u 20003 -d /shared/home/user01 -m user01 sudo useradd -u 20002 -d /shared/home/user02 -m user02 両ユーザーから同時にジョブを投入すると、squeue 上で USER 列によって誰のジョブかが明確に識別され、計算ノード側でも同じ UID で /shared/home/user01・/shared/home/user02 にアクセスできることを確認できます。 !user01 と user02 の複数ユーザーからジョブを投入し squeue でユーザー別に管理されている画面 user01（JOBID 4）と user02（JOBID 5）の双方からジョブを投入した状態。squeue の USER 列でユーザーごとにジョブが識別され、CycleCloud 側で 2 台の計算ノードが並行して自動起動しています。 4-6. Slurm QoS による利用時間・優先順位の制御（TC-06 / Q4） 「学生と教員で最大実行時間やキューの優先順位を分けたい」という要件（Q4）は、Slurm アカウンティング（slurmdbd / sacctmgr）の QoS（Quality of Service） で制御します。本検証では以下の 2 つの QoS を定義します。 | QoS 名 | 想定ロール | 最大実行時間 (MaxWall) | ジョブ優先度 (Priority) | リソース上限 (MaxTRESPerUser) | | --- | --- | --- | --- | --- | | normal | 一般・学生 (user01) | 01:00:00（1 時間） | 10 | cpu=4（または gres/gpu=1） | | high | 教員・優先研究 (user02) | 24:00:00（24 時間） | 1000 | cpu=16（または gres/gpu=4） | <details><summary>06-configure-slurm-qos.sh: slurmdbd（MariaDB）の有効化と sacctmgr による QoS 作成（クリックで展開）</summary> # 06-configure-slurm-qos.sh（ヘッドノードの root で実行） # 0. MariaDB と slurmdbd の構成・起動（Job Accounting 未有効時） dnf install -y mariadb-server && systemctl enable --now mariadb mysql -e "CREATE DATABASE IF NOT EXISTS slurm_acct_db; CREATE USER IF NOT EXISTS 'slurm'@'localhost' IDENTIFIED BY 'slurm123'; GRANT ALL ON slurm_acct_db.* TO 'slurm'@'localhost'; FLUSH PRIVILEGES;" cat << 'EOF' > /sched/slurm-poc01/slurmdbd.conf AuthType=auth/munge DbdHost=localhost StorageType=accounting_storage/mysql StorageHost=localhost StorageUser=slurm StoragePass=slurm123 StorageLoc=slurm_acct_db LogFile=/var/log/slurm/slurmdbd.log PidFile=/var/run/slurmdbd.pid SlurmUser=slurm EOF chown slurm:slurm /sched/slurm-poc01/slurmdbd.conf && chmod 600 /sched/slurm-poc01/slurmdbd.conf systemctl enable --now slurmdbd cat << 'EOF' > /sched/slurm-poc01/accounting.conf AccountingStorageType=accounting_storage/slurmdbd AccountingStorageHost=localhost AccountingStorageEnforce=associations,limits,qos EOF systemctl restart slurmctld # 1. normal と high の 2 つの QoS を作成 sacctmgr -i add qos normal set MaxWall=01:00:00 Priority=10 MaxTRESPerUser=cpu=4 sacctmgr -i add qos high set MaxWall=24:00:00 Priority=1000 MaxTRESPerUser=cpu=16 # 2. クラスターアカウントにユーザーを登録し、既定 QoS を割り当て sacctmgr -i add user user01 Account=root DefaultQOS=normal QOS=normal sacctmgr -i add user user02 Account=root DefaultQOS=high QOS=high # 3. PriorityWeightQOS を有効化して設定反映 echo -e "\nPriorityType=priority/multifactor\nPriorityWeightQOS=10000" >> /sched/slurm-poc01/site_specific.conf scontrol reconfigure sacctmgr show qos format=Name,Priority,MaxWall,MaxTRESPerUser </details> 現在のユーザーと QoS の割り当てを確認する Linux に存在するユーザー、Slurm 管理 DB に登録されたユーザー、個々のジョブが使う QoS は、それぞれ分けて確認します。 以下は scheduler 上で実行する参照専用のコマンドです。全ユーザーの設定・履歴を見るため、管理者として sudo を使用しています。 <details><summary>ユーザー一覧・QoS 割り当て・ジョブで使用した QoS を確認するコマンド（クリックで展開）</summary> # Linux ユーザー：ユーザー名、UID、ホーム、ログインシェル（システム用も含む） getent passwd | cut -d: -f1,3,6,7 # Slurm 管理 DB に登録されたユーザー sudo sacctmgr show user format=User,DefaultAccount,AdminLevel # クラスタ・アカウント・パーティションごとの利用可能 QoS と既定 QoS sudo sacctmgr show assoc format=Cluster,Account,Partition,User,QOS%40,DefaultQOS # 各 QoS の具体的な制限・優先度 sudo sacctmgr show qos format=Name,Priority,MaxWall,MaxTRESPerUser # 今日の全ユーザーのジョブで実際に使われた QoS（実行中・終了済み） sudo sacct -a -S today -X --format=JobID,User,JobName,QOS,State,Elapsed </details> | 表示項目 | 意味 | | --- | --- | | QOS | そのユーザーの関連付け（association）で利用できる QoS | | DefaultQOS | ジョブ投入時に --qos を指定しなかった場合の既定 QoS | | sacct の QOS | 個々のジョブが実際に使用した QoS | | AdminLevel | Slurm アカウンティングの管理権限。high / normal の区分とは別 | この記事の設定手順では、user01 は利用可能・既定ともに normal、user02 は利用可能・既定ともに high です。azureuser の QoS は上のユーザー追加コマンドでは指定していないため、実際の関連付けを確認してください。show assoc で User が空欄の行はアカウント単位の設定で、別のユーザーを表しているわけではありません。 Linux にユーザーが存在していても Slurm 管理 DB に登録されているとは限りません。また、同一ユーザーでもクラスタ・アカウント・パーティションによって関連付けが異なる場合があります。設定例ではなく、現在のコマンド出力を実設定として確認してください。 > 出典: Slurm sacctmgr（ユーザー・関連付け・QoS の管理） / Slurm sacct（ジョブ履歴） !sacctmgr での QoS 設定と user01 の上限時間超過ジョブが QOSMaxWallDurationPerJobLimit でブロックされる画面 QoS の検証結果。normal QoS（上限 1 時間）が割り当てられた user01 が --time=02:00:00（2 時間）のジョブ（JOBID 6）を投入すると、REASON が (QOSMaxWallDurationPerJobLimit) となって実行前にブロックされます。 設定後の検証動作: 1. 上限時間を超えるジョブのブロック（保留）と対処法: user01（normal QoS：上限 1 時間）が sbatch --time=02:00:00 gpu-job01.sh を投入すると、REASON が (QOSMaxWallDurationPerJobLimit) となって実行前にブロックされます。 - ブロックされたジョブはどうなるか: 自動的には削除（キャンセル）されず、キュー内で PD（Pending：保留）状態のままホールドされます。この状態では計算ノードの自動起動（オートスケール）も一切トリガーされないため、無駄な VM 課金が発生することはありません。 - 解除・対処する方法: - 利用者本人が scancel <JOBID> で一度取り消し、--time=01:00:00 以下に修正して再投入する（または scontrol update JobId=<JOBID> TimeLimit=01:00:00 で要求時間を短縮するとそのまま実行待ちに進む）。 - 管理者が特例として長時間実行を許可する場合は、sudo scontrol update JobId=<JOBID> QOS=high でジョブの QoS を変更するとブロックが解除される。 - ※もしキューに PD で残すのではなく、sbatch を叩いた瞬間にエラーで弾きたい（投入自体を拒否したい）場合は、パーティション設定や slurm.conf の EnforcePartLimits=ALL を組み合わせる運用も可能です。 2. 待機ジョブの優先順位制御: PriorityWeightQOS=10000 により、sprio で normal QoS と high QoS の優先度スコアに明確な差がつき、空きノードが high QoS のジョブへ優先割り当てされます。 3. ユーザー別の利用実績集計: sudo sacct -a -X --format=JobID,User,Partition,QOS,Elapsed,State を実行することで、誰がどの QoS で何時間クラスタを使用したかを後から正確に集計できます。 4-7. Azure NetApp Files のユーザークォータによる容量制限（TC-07 / Q5） 「特定のユーザーが巨大なデータセットやチェックポイントを置いて共有ストレージをパンクさせるのを防ぎたい」という要件（Q5）は、Azure NetApp Files（ANF）の個人ユーザークォータ（Individual User Quota） で制御します。 <details><summary>07-set-anf-user-quota.sh: ANF ボリュームに対する UID 単位の容量クォータ設定（クリックで展開）</summary> # 07-set-anf-user-quota.sh # user01 (UID: 20003) に対して 1 GiB (1048576 KiB) のユーザークォータを設定 az netappfiles volume quota-rule create \ -g "$RG" --account-name "$ANF_ACCT" --pool-name "$ANF_POOL" --volume-name "$ANF_VOL" \ -n "quota-user01" -l "$LOCATION" \ --quota-type IndividualUserQuota --quota-target "20003" --quota-size 1048576 </details> !Azure Portal の Azure NetApp Files ボリューム（vol01）における個人ユーザークォータルール（1 GiB）の設定画面 Azure Portal 上の vol01 > [クォータ ルール] 画面。UID 20003（user01）に対して 1 GiB (1,048,576 KiB) の個別ユーザークォータ（IndividualUserQuota）が適用されています。 クォータ反映後、Linux クライアント（scheduler）上で quota -s コマンドを実行すると、ANF ボリューム（10.0.253.4:/vol01）側の rquotad から user01 の上限（1024M）と現在の消費量がリアルタイムに取得できることを確認できます。 <details><summary>quota -s によるユーザークォータ上限と消費量追跡の確認コマンド（クリックで展開）</summary> # user01 (UID: 20003) のクォータ上限（1024M）と 800MB ファイル作成時の消費量追跡を確認 sudo -u user01 quota -s sudo -u user01 dd if=/dev/zero of=/shared/home/user01/test_800m.bin bs=1M count=800 sudo -u user01 quota -s </details> !Linux クライアント上で quota -s コマンドにより ANF の 1024M ユーザークォータ上限を確認し dd で書き込みテストを実行している画面 sudo -u user01 quota -s の実行画面。10.0.253.4:/vol01 の quota / limit が 1024M（1 GiB）として認識されており、800 MB ファイル書き込み（dd）後の再実行では space が 16K から 801M へ増加して ANF 側で UID 単位の消費量が追跡されます。 このように、「計算リソース・ジョブ実行時間のガバナンスは Slurm の QoS」「ホーム領域の容量ガバナンスは ANF のユーザークォータ」 と役割分担することで、OS 側の複雑なクォータ設定を自前で管理することなく安全に共用環境を運用できます。 > 出典: Azure NetApp Files ボリュームの既定および個別のユーザーとグループのクォータを管理する 4-8. GPU SKU の置き換え・複数世代 GPU の混在運用（TC-08 / Q7） 「当初は入手しやすい GPU SKU で始め、後から H100（Standard_NC40ads_H100_v5 / Standard_ND96isr_H100_v5）や A100（Standard_NC24ads_A100_v4）に変更・追加したい」という要件（Q7）に対しては、CycleCloud のクラスタ設定で以下の 2 通りのアプローチが取れます。 !CycleCloud の VM サイズ選択画面（Compute Type: GPU）における各種 GPU SKU と単価・クォータ・RDMA 対応の一覧 CycleCloud の Select a machine type ダイアログで Compute Type: GPU を選択した画面。A100（Standard_NC24ads_A100_v4）や RTX PRO 6000、NVv4 などの各 GPU SKU について、コア数・メモリ・時間単価・クォータ状況・SR-IOV / RDMA 対応可否を一覧比較して選択できます。 1. 既存パーティションの VM SKU 差し替え: CycleCloud GUI のクラスタ編集画面（Required Settings → HPC VM Type または GPU VM Type）で VM サイズを変更して Save し、ヘッドノードで sudo azslurm scale を実行するだけで、次回起動する計算ノードから新しい GPU SKU に切り替わります。 2. GPU 種類ごとのパーティション分割（推奨）: CycleCloud 8 の Slurm テンプレートには最初から hpc・gpu・htc・dynamic の複数パーティションが用意されています。日常のコードデバッグ・前処理用には汎用 VM や低価格 GPU パーティションを割り当て、本番の大規模学習用には A100 / H100 パーティションを割り当てることで、ユーザーは sbatch の --partition 指定を変えるだけで同じ /shared/home/$USER 環境のまま複数の GPU 世代を使い分けられます。 --- 5. ハマったポイント・運用上の注意点 今回の実機構築・検証を通じて実際に遭遇したハマりどころと解決策をまとめます。 | # | ハマりどころ・事象 | 原因 | 対処法 | | --- | --- | --- | --- | | 1 | CycleCloud GUI の Subscriptions > Create が Loading... のまま進まない | 2026年3月31日以降、新規サブネットが既定でプライベートサブネット（defaultOutboundAccess: false）になり、パブリック IP なしの cc-server01 から management.azure.com へ通信できなくなったため | クラスタ用サブネット（subnet-cluster01）に Azure NAT Gateway をアタッチして ARM API 等へのアウトバウンド通信を明示的に許可する | | 2 | サブスクリプション登録直後に VM サイズ選択（Choose）を開くと No rows in the current filter で空になる | サブスクリプション追加直後の約 1〜2 分間は、CycleCloud がバックグラウンドで Azure の全 VM SKU（約 7 万件）と価格情報を DB に同期しているため | cycle_server.log に Stored 71,431 records of type Azure.MachineType が出力されるまで 1〜2 分待ってからダイアログを開き直す（クォータ 0 の SKU も見たい場合は Hide Unavailable のチェックを外す） | | 3 | Network Attached Storage タブで /shared に ANF を設定する際、内蔵 NFS と競合する・またはマウントに失敗する | ① File-system Mount for /shared の Use Builtin NFS にチェックが残っていると内蔵ディスクと競合する<br>② /shared 専用欄の 3 行目は Mount Point ではなく Export Path、4 行目は Mount Options になっている | File-system Mount for /shared の Use Builtin NFS のチェックを外し、IP Address: 10.0.253.4、Export Path: /vol01、Mount Options: 空欄 に設定する（下部の Additional Filesystem Mount は使わない） | | 4 | useradd -u 20001 user01 を実行すると UID 20001 is not unique エラーになる | CycleCloud が作成するクラスタ管理者ユーザー（azureuser）に最初から UID 20001 が割り当てられているため | 追加の一般ユーザーは 20002 以降の UID を割り当てる（ANF ユーザークォータの --quota-target も実際の UID に合わせる） | | 5 | sacctmgr で QoS を設定しても実行時間制限や sprio の優先度差が効かない | 既定では accounting.conf が accounting_storage/none になっており、また site_specific.conf に PriorityWeightQOS が設定されていないため | slurmdbd（MariaDB）を構成して AccountingStorageEnforce=associations,limits,qos を有効化し、site_specific.conf（末尾改行に注意）へ PriorityType=priority/multifactor と PriorityWeightQOS=10000 を追記して scontrol reconfigure を実行する | | 6 | NFSv3（hard マウント）上の ANF でバッファード dd によりクォータ上限を超過させるとプロセスが D 状態でハングする | AlmaLinux 8.10 カーネルのページキャッシュ書き戻し（nfs_file_flush）で NFS3ERR_DQUOT が返った際、hard マウントのリトライ待ちに入り /shared/home 全体の I/O が詰まることがある | クォータの動作確認には quota -s コマンドを使用する。書き込み上限テストを行う場合は oflag=direct や小さいブロックサイズを使い、万一 .nfs* ロックが残った場合は一時的にクォータ上限を広げて削除する | | 7 | GPU ジョブ（--gres=gpu:1）投入時に Requested node configuration is not available となる | CycleCloud の autoscale.json が対象 GPU VM SKU の GPU 枚数（slurm_gpus）を自動解決できていないケースがある | ヘッドノードの /opt/azurehpc/slurm/autoscale.json の default_resources に対象 VM サイズと slurm_gpus 枚数を明記し、azslurm scale と azslurm buckets で反映を確認する | | 8 | 検証終了後に課金が継続してしまう | 計算ノードが 0 台でも、CycleCloud サーバー・Slurm ヘッドノード・Windows VDI・Azure Bastion・NAT Gateway・ANF プール（4 TiB）は起動中課金が発生する | デモ・検証期間外は azslurm keep_alive --remove で常時起動を解除し、VM 停止（Deallocate）、および長期中断時は Bastion と ANF ボリューム/プールの削除を実施する | <details><summary>参考: GPU枚数がSlurmに反映されない場合の autoscale.json 修正手順（クリックで展開）</summary> # Slurm ヘッドノードで root になり autoscale.json をバックアップ・編集 sudo -i cd /opt/azurehpc/slurm cp -p autoscale.json autoscale.json.org # default_resources セクションに使用する GPU VM SKU と GPU 枚数を追記した上でスケール設定を再生成 azslurm scale azslurm buckets </details> > 出典: GitHub - Azure/cyclecloud-slurm: Incorrect number of GPUs --- まとめ - Azure CycleCloud 8 + Slurm + Azure NetApp Files を組み合わせることで、大学・研究機関で求められる「バッチ処理」「JupyterLab による対話操作」「複数ユーザー共用」「QoS による時間・優先度制限」「ANF ユーザークォータによる容量制限」「0 台からのオートスケールと常時起動の併用」を 1 つの閉域クラスタで実現できる。 - Azure Bastion + Windows VDI を組み合わせることで、クラスタ内の全 VM からパブリック IP を排除しつつ、CycleCloud 管理画面や計算ノード上の JupyterLab へ安全にブラウザアクセスできる。 - AlmaLinux 8.10 HPC イメージを採用することで GPU ドライバー導入のオーバーヘッドをなくし、将来の GPU SKU 変更や複数世代 GPU パーティションの混在にも柔軟に対応できる。 参考リンク - Azure CycleCloud のドキュメント (CycleCloud 8) - Azure CycleCloud での Slurm の使用 - クラスタの自動スケーリングを構成する (Azure CycleCloud) - Azure HPC/AI VM イメージ - Azure での既定のアウトバウンド アクセス (プライベート サブネット既定化) - Azure NetApp Files の既定および個別のユーザーとグループのクォータについて - Azure NetApp Files ボリュームの既定および個別のユーザーとグループのクォータを管理する - GitHub - Azure/cyclecloud-slurm > 本記事は GitHub Copilot および Microsoft Foundry を活用して作成されています。内容の正確性については各公式ドキュメントをご確認ください。