View a markdown version of this page

Slurm を使用した拡張クラスターオペレーションの継続的なプロビジョニング - Amazon SageMaker AI

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Slurm を使用した拡張クラスターオペレーションの継続的なプロビジョニング

Slurm オーケストレーションを使用して作成された Amazon SageMaker HyperPod クラスターは、継続的なプロビジョニングをサポートするようになりました。これは、大規模な AI/ML ワークロードを実行する際の柔軟性と効率を高める機能です。継続的プロビジョニングにより、トレーニングを迅速に開始し、シームレスにスケールして、オペレーションを中断することなくメンテナンスを実行し、クラスターオペレーションをきめ細かく可視化できます。

注記

継続的プロビジョニングは、Slurm オーケストレーションで作成された新しい HyperPod クラスターのオプション設定として使用できます。以前のスケーリングモデルを使用している既存のクラスターは、現時点では継続的プロビジョニングに移行できません。

仕組み

継続的プロビジョニングシステムは、従来のall-or-nothingスケーリングモデルを置き換える、望ましい状態のアーキテクチャを導入します。前のモデルでは、インスタンスグループを完全にプロビジョニングできなかった場合、クラスターの作成または更新オペレーション全体が失敗し、ロールバックされました。継続的プロビジョニングでは、システムは部分容量を受け入れ、残りのインスタンスを非同期的にプロビジョニングし続けます。

継続的プロビジョニングシステム:

  • リクエストを受け入れます: 各インスタンスグループのターゲットインスタンス数を記録します。

  • プロビジョニングの開始: すべてのインスタンスグループのインスタンスの起動を並行して開始します。

  • 優先度ノードを最初にプロビジョニングする: クラスターは、少なくとも 1 つのコントローラーノード (ログインインスタンスグループが指定されている場合は 1 つのログインノード) が正常にプロビジョニングされたInService後に に移行します。

  • 進行状況を追跡: 各インスタンスの起動試行をモニタリングし、ステータスを記録します。

  • 失敗に対処: ワーカーノードの失敗した起動を非同期的に自動的に再試行します。

継続的プロビジョニングはデフォルトで無効になっています。この機能を使用するには、CreateClusterリクエストContinuousNodeProvisioningModeを に設定します。

継続的プロビジョニングを有効にすると、以前のオペレーションが完了するのを待つ必要なく、複数のスケーリングオペレーションを同時に開始できます。これにより、同じクラスター内の異なるインスタンスグループを同時にスケールし、同じインスタンスグループに複数のスケーリングリクエストを送信できます。

優先度ベースのプロビジョニング

Slurm クラスターでは、ワーカーノードがジョブを登録して受け入れる前に、コントローラーノードを動作させる必要があります。継続的プロビジョニングは、優先度ベースのプロビジョニングを通じてこれを自動的に処理します。

  1. コントローラーインスタンスグループが最初にプロビジョニングされます。

  2. 1 つのコントローラーノードが正常になると、ログインノードとワーカーノードは並行してプロビジョニングを開始します。

  3. 1 つのコントローラーノードが稼働していて、1 つのログインノードが稼働InServiceしている場合 (ログインインスタンスグループが指定されている場合)、クラスターは に移行します。ログインインスタンスグループが指定されていない場合、クラスターはコントローラーノードがプロビジョニングされるとInServiceすぐに に移行します。

  4. キャパシティの制約によりすぐにプロビジョニングできないワーカーノードは、非同期再試行ループに入り、使用可能になると自動的に Slurm クラスターに追加されます。

コントローラーの障害処理

クラスターの作成中にコントローラーノードのプロビジョニングに失敗した場合の動作は、エラーが再試行可能か再試行不可能かによって異なります。

再試行可能なエラー (異常なインスタンスや一時的な障害など)。

  • HyperPod はインスタンスを継続的に置き換え、コントローラーが起動するまでプロビジョニングを再試行します。

  • プロビジョニング済みのワーカーノードとログインノードは引き続き使用できますが、コントローラーが正常InServiceになるまでクラスターは に移行されません。

再試行不可能なエラー (コントローラーインスタンスタイプに使用可能な容量がない、ライフサイクルスクリプトの障害など)。

  • クラスターは とマークされますFailed

  • 失敗の理由が通知され、別のインスタンスタイプの選択、ライフサイクルスクリプトの修正、別のアベイラビリティーゾーンでの再試行などの修正措置を講じる必要があります。

前提条件

継続的プロビジョニングでは、各インスタンスグループの SlurmConfigフィールドの API ペイロードを介して Slurm プロビジョニングパラメータ (ノードタイプ、パーティション名) を指定する必要があります。Amazon S3 のレガシーprovisioning_parameters.jsonファイルに依存するクラスターは、継続的プロビジョニングと互換性がありません。

注記

現在、Slurm クラスターでの継続的なプロビジョニングでは、既存のクラスターの移行、API ベースの Slurm トポロジを介したマルチヘッドノード設定、および の機能はサポートされていませんSlurmConfigStrategy。継続的プロビジョニングは、slurm.conf管理のためにマージモードでのみ動作します。

使用状況の計測

継続的プロビジョニングを有効にした HyperPod クラスターは、インスタンスレベルの計測を使用して、実際のリソース使用量を反映する正確な請求情報を提供できます。この計測アプローチは、各インスタンスを個別に追跡する点で、従来のクラスターレベルの請求とは異なります。

インスタンスレベルの請求

継続的プロビジョニングでは、請求はクラスターレベルの状態の変化を待つのではなく、個々のインスタンスレベルで開始され、停止します。これには次の利点があります。

  • 正確な請求精度: ライフサイクルスクリプトの実行が開始されると請求が開始されます。ライフサイクルスクリプトが失敗すると、インスタンスのプロビジョニングが再試行され、ライフサイクルスクリプトのランタイム中に課金されます。

  • 独立した計測: 各インスタンスの請求ライフサイクルは個別に管理されるため、請求エラーのカスケードを防ぐことができます。

  • リアルタイムの請求更新: 請求は、インスタンスがライフサイクル設定スクリプトの実行を開始したときに開始され、インスタンスが終了状態になると停止します。

請求ライフサイクル

HyperPod クラスター内の各インスタンスは、この請求ライフサイクルに従います。

  • 請求開始: インスタンスが正常に起動し、ライフサイクル設定スクリプトの実行を開始するとき。

  • 請求は継続: インスタンスの運用期間中。

  • 請求停止: 終了の理由に関係なく、インスタンスが終了状態になった場合。

注記

起動に失敗したインスタンスの請求は開始されません。キャパシティ不足やその他の問題が原因でインスタンスの起動に失敗した場合、その失敗した試行に対して課金されることはありません。請求はインスタンスレベルで計算され、コストはクラスターの Amazon リソースネーム (ARN) で集計されて報告されます。

継続的プロビジョニングを有効にしてクラスターを作成する

注記

ライフサイクル設定スクリプトを準備し、実行ロールがアクセスできる Amazon S3 バケットにアップロードします。詳細については、「SageMaker HyperPod Slurm クラスターオペレーション」を参照してください。

API CreateClusterリクエストファイルを JSON 形式で準備します。NodeProvisioningMode を に設定Continuousし、各インスタンスグループの SlurmConfigフィールドに Slurm トポロジ情報を指定します。

// create_cluster.json { "ClusterName": "my-training-cluster", "NodeProvisioningMode": "Continuous", "Orchestrator": { "Slurm": {} }, "InstanceGroups": [ { "InstanceGroupName": "controller-group", "InstanceType": "ml.m5.xlarge", "InstanceCount": 1, "LifeCycleConfig": { "SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster", "SlurmConfig": { "NodeType": "Controller" } }, { "InstanceGroupName": "login-group", "InstanceType": "ml.m5.xlarge", "InstanceCount": 1, "LifeCycleConfig": { "SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster", "SlurmConfig": { "NodeType": "Login" } }, { "InstanceGroupName": "worker-gpu-a", "InstanceType": "ml.p5.48xlarge", "InstanceCount": 16, "LifeCycleConfig": { "SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster", "SlurmConfig": { "NodeType": "Compute", "PartitionNames": ["gpu-training"] } } ], "VpcConfig": { "SecurityGroupIds": ["sg-12345678"], "Subnets": ["subnet-12345678"] } }

create-cluster コマンドを実行してリクエストを送信します。

aws sagemaker create-cluster \ --cli-input-json file://complete/path/to/create_cluster.json

これにより、新しいクラスターの ARN が返されます。

{ "ClusterArn": "arn:aws:sagemaker:us-west-2:111122223333:cluster/abcde12345" }

Slurm 設定管理

継続的プロビジョニングは、slurm.confパーティション管理のためにマージモードでのみ動作します。マージモードでは、HyperPod はパーティション設定の変更を、 で変更したものに加えて追加で適用しますslurm.conf。HyperPod は のパーティション関連のセクション slurm.conf (パーティション名やノード名エントリなど) のみを更新します。他の Slurm 設定パラメータは変更されません。つまり、次のようになります。

  • への手動編集slurm.confは保持されます。

  • 変更と HyperPod の想定状態の間に、自動ドリフト検出や競合の解決はありません。

SlurmConfigStrategy パラメータ (ManagedMergeOverwrite) は、継続的プロビジョニングではサポートされていません。SlurmConfigStrategy 値を渡すと、API エラーが発生します。