このガイドでは、Gemini Enterprise Agent Platform で Slurm を使用して Flex Start VM を構成および使用する方法について説明します。この統合により、トレーニング ワークロードに柔軟な VM プロビジョニング モデルを使用できます。
構成とクラスタの作成
クラスタの構成を定義する前に、必要なサービス アカウントに Flex Start リソースを管理する権限が付与されていることを確認するため、次の前提条件の手順を 1 回だけ完了する必要があります。
Google API サービス エージェントの権限を確認する
- コンテキスト: Gemini Enterprise Agent Platform 上の Slurm は、マネージド インスタンス グループを使用して、Flex Start VM インスタンスを動的にプロビジョニングし、そのライフサイクルを管理します。Google API サービス エージェントは、マネージド インスタンス グループの基盤となる Compute Engine リソースを作成して管理します。マネージド インスタンス グループと IAM のドキュメントで説明されているように、このサービス アカウントには、VM インスタンスの作成、削除、一覧表示を行う権限と、サービス アカウント ID を VM インスタンスに関連付ける権限が必要です。
- 操作: Google API サービス エージェント
（
PROJECT_NUMBER@cloudservices.gserviceaccount.com）に 編集者ロール（roles/editor）がすでに付与されているかどうかを確認します。- 「はい」の場合: おそらく、これ以上の操作は必要ありません。通常、編集者ロールには必要な権限がすべて含まれています。
- 「いいえ」の場合: デフォルトの編集者ロールが付与されていない場合は、MIG が機能するように、次のロールを明示的に付与する必要があります。
- Compute インスタンス管理者（v1）（
roles/compute.instanceAdmin.v1）- VM インスタンスの作成、一覧表示、削除に必要です。 - サービス アカウント ユーザー（
roles/iam.serviceAccountUser）- サービス アカウントを新しい VM に関連付けるために必要です。
- Compute インスタンス管理者（v1）（
Flex Start プロビジョニング モデルを使用して Slurm クラスタを作成する
Flex Start プロビジョニング モデルを使用する Slurm クラスタを作成するには、API を使用してクラスタ作成リクエストを送信するときに、クラスタ仕様のノードプール構成内で provisioning_model を指定する必要があります。
構成スニペットの例: 次の JSON 構成を cluster_config.json という名前のファイルに保存します。この例では、slurm_spec を明示的に使用しています。
プレースホルダ（<project-id>, <region>, <zone>）
を実際の値に置き換えます。
{
"display_name": "flexvm",
"name": "projects/<project-id>/locations/<region>/modelDevelopmentClusters/",
"network": {
"network": "projects/<project-id>/global/networks/default",
"subnetwork": "projects/<project-id>/regions/<region>/subnetworks/default"
},
"node_pools": [
{
"id": "login",
"machine_spec": { "machine_type": "n2-standard-8" },
"scaling_spec": { "min_node_count": 1, "max_node_count": 1 },
"enable_public_ips": "true",
"zone": "<zone>",
"boot_disk": { "boot_disk_type": "pd-standard", "boot_disk_size_gb": 120 }
},
{
"id": "a3u",
"machine_spec": {
"machine_type": "a3-ultragpu-8g",
"accelerator_type": "NVIDIA_H200_141GB",
"accelerator_count": 8
},
"provisioning_model": "FLEX_START",
"flex_start_max_duration": "604800s",
"scaling_spec": { "min_node_count": 0, "max_node_count": 2 },
"zone": "<zone>",
"enable_public_ips": "true",
"boot_disk": { "boot_disk_type": "hyperdisk-balanced", "boot_disk_size_gb": 400 }
}
],
"orchestrator_spec": {
"slurm_spec": {
"home_directory_storage": "projects/<project-id>/locations/<zone>/instances/<filestore-id>",
"partitions": [ { "id": "a3u", "node_pool_ids": [ "a3u" ] } ],
"login_node_pool_id": "login"
}
}
}
Slurm クラスタを作成する の手順に沿って 、認証してリクエストを送信します。
Flex Start の最大期間: 必要に応じて、Flex Start インスタンスの最大実行時間を設定できます。ノードプール構成の flex_start_max_duration フィールドを使用して、値を秒単位の文字列で指定し、末尾に「s」を追加します（例: 2 日の場合は「172800s」）。省略すると、デフォルトで 7 日間に設定されます。
運用ライフサイクルと復元力
Gemini Enterprise Agent Platform 環境での Slurm の Flex Start ノードのライフサイクルを理解することは、ジョブの計画に不可欠です。
Flex Start の制約
すべての Flex Start VM には、flex_start_max_duration 設定で定義された固定の最大実行時間があります。
- 期間の制限: デフォルトでは、
flex_start_max_durationは 7 日間に設定されています。 この制限をオーバーライドするには、ノードプール構成で 30 秒から最大 7 日間（604,800 秒）のカスタムflex_start_max_durationを指定して、想定されるジョブの実行時間に合わせて調整します。 - 終了: この制限に達すると、Compute Engine はインスタンスを強制的に終了します。
ノードのスケーリング動作
以降のセクションでは、静的と動的の 2 つのスケーリング戦略について説明します。
静的ノード
静的ノードを使用すると、常に
使用可能なリソースの固定プールを維持できます（例: min_node_count > 0）。
- プロビジョニング: ノードは、クラスタの作成時またはサイズ変更時に、最小ノード数を満たすためにすぐにリクエストされます。
- 有効期限と復旧: 静的な Flex Start ノードが
flex_start_max_durationに達して Compute Engine によって終了すると、システムは自動的にノードの再作成を試み、定義されたクラスタ容量を復元します。このサイクルにより、Slurm ジョブがノードで待機しているかどうかに関係なく、静的プールが常に維持されます。
動的ノード
動的ノードを使用すると、必要な場合にのみクラスタをスケールアップできます。
- プロビジョニング: ジョブがキューに登録されると（
PENDING状態になると）、Slurm スケジューラはマネージド インスタンス グループを作成してサイズ変更リクエストを発行することで、リソースをリクエストします。 - 有効期限と復旧: 有効期限が切れると、Slurm ジョブがノードで保留中の場合にのみ、新しい Flex Start ノードがプロビジョニングされます。
クラスタの復元力と自動修復
Gemini Enterprise Agent Platform 上の Slurm は、ジョブのライフサイクルの重要な段階でノードのヘルスをモニタリングします。ジョブの安定性を維持するため、ジョブの開始前（プロローグ）と完了後（エピローグ）の両方でヘルスチェックが実行されます。
- ハードウェア エラー処理: サービスが重大なハードウェアの問題（GPU エラーなど）を検出した場合、異常な VM を自動的に修復するように設計されています。
- 自動置換: ジョブが PENDING 状態のままの場合（またはノード障害のために PENDING に再キューされた場合）、システムは異常な VM を置き換えるために新しい Flex Start インスタンスを自動的にプロビジョニングします。 これにより、手動で介入することなく、正常なハードウェアでワークロードを続行できます。