翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # を使用した SageMaker HyperPod の開始方法 AWS CLI 次のチュートリアルでは、SageMaker HyperPod [AWS CLI のコマンドを使用して Slurm で新しい SageMaker HyperPod](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-cli) クラスターを作成する方法を示します。このチュートリアルを終了すると、コントローラーノード、ログインノード、コンピューティングワーカーグループを備えた Slurm クラスターが稼働し、ML ワークロードをスケジュールして実行できるようになります。このチュートリアルでは、Slurm トポロジーのセットアップ、ノードライフサイクル設定オプション、オプションの FSx 共有ストレージ、クラスターへの接続方法について説明します。 開始する前に、 [SageMaker HyperPod を使用するための前提条件](sagemaker-hyperpod-prerequisites.md) (VPC、クォータ、FSx) と [AWS Identity and Access Management SageMaker HyperPod 用](sagemaker-hyperpod-prerequisites-iam.md) (IAM ロール、 の実行ロール) を完了していることを確認してください`AmazonSageMakerClusterInstanceRolePolicy`。 ## 主要なコンセプト このセクションでは、SageMaker HyperPod Slurm クラスターを作成するための主要な設定概念について説明します。これらの概念を理解することは、クラスターを設定するときに情報に基づいた選択を行うのに役立ちますが、すぐに使用を開始する場合は、 に直接ジャンプ[クラスターを作成する](#smcluster-getting-started-slurm-cli-create-cluster)し、必要に応じてここで参照できます。 Slurm オーケストレーションクラスターを作成するときは、2 つの独立した設定を選択します。 1. **Slurm トポロジ設定** – Slurm クラスタートポロジ (ノードロール、パーティション) はどのように定義されますか? 1. **ノードライフサイクル設定** – ノードのプロビジョニングとカスタマイズはどのように行われますか? Slurm トポロジの場合、このチュートリアルでは API 駆動型設定アプローチを使用します。このアプローチでは、`SlurmConfig`各インスタンスグループとクラスターレベルで を使用して`CreateCluster`、リクエストでノードロールとパーティションを直接定義`Orchestrator.Slurm`します。これは、新しいクラスターに推奨されるアプローチです。信頼できる単一のソース、組み込みの検証、パーティション設定ドリフト検出を提供し、追加のファイルを管理する必要はありません。または、Amazon S3 に保存されているレガシー`provisioning_parameters.json`ファイルを使用して、既存のクラスターとの下位互換性を保つこともできます。レガシーアプローチの詳細については、「」を参照してください[SageMaker HyperPod Slurm の設定](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-slurm-configuration)。 ノードライフサイクル設定では、SageMaker HyperPod は 3 つのオプションをサポートしています。最も単純なケースでは`LifeCycleConfig`、完全に省略すると、HyperPod は AMI ベースの設定を使用してノードを自動的に設定し、スクリプトや Amazon S3 バケットを必要とせずに、ML ワークロードを実行するために Slurm や Docker、Enroot、Pyxis などの必須パッケージを設定します。AMI ベースの設定に加えてカスタマイズが必要な場合は、設定の完了後に`OnInitComplete`実行される 拡張スクリプトを 経由で指定できます。プロビジョニングシーケンス全体を完全に制御するために、 `OnCreate`パスを使用すると、Slurm の起動時を含め、スクリプトがすべてを所有できます。 ML ワークロードの場合、通常、データ、チェックポイント、共有ライブラリをトレーニングするための共有高性能ファイルシステムも必要です。SageMaker HyperPod は、経由でインスタンスグループごとに設定された Amazon FSx for Lustre と FSx for OpenZFS をサポートしています`InstanceStorageConfigs`。FSx 設定はクラスター作成ではオプションですが、本番ワークロードでは推奨されます。 ### API を使用した Slurm トポロジの設定 このチュートリアルのすべての例では、API 駆動型の Slurm トポロジ設定を使用します。ここでは、個別の設定ファイルではなく、`CreateCluster`API リクエストで Slurm クラスター構造を直接定義します。 Slurm クラスターには、少なくともコントローラーノード (デーモンを実行し、ジョブのスケジュールを調整する) `slurmctld` と 1 つ以上のコンピューティングノード (ジョブを実行する) が必要です。必要に応じて、ログインノードを追加して、コントローラーに直接ログインせずにジョブを送信および管理するための専用のアクセスポイントをユーザーに提供できます。API リクエストでは、 を使用して各インスタンスグループに Slurm ロールを割り当て`SlurmConfig`、グループがコントローラー、ログイン、またはコンピューティングノードとして機能するかどうかを指定します。コンピューティンググループは、1 つ以上の Slurm パーティションにもマッピングされます。これは、異なるノードセット間でジョブをスケジュールする方法を整理する論理キューとして機能します。 クラスターレベルで、 は HyperPod が でパーティション設定を管理する方法`Orchestrator.Slurm`を制御します`slurm.conf`。HyperPod がパーティショントポロジーの唯一の信頼できるソースであるかどうか、手動の変更を上書きするかどうか、API 定義の設定を手動編集とマージするかどうかを決定する戦略を選択します。使用されるフィールドのリファレンスを次に示します。 **SlurmConfig** (インスタンスグループあたり): ``` "SlurmConfig": { "NodeType": "Controller | Login | Compute", "PartitionNames": ["partition-name"] } ``` | フィールド | 説明 | | --- | --- | | NodeType | 必須。このインスタンスグループの Slurm ロール。有効な値は、Controller、Login、Compute です。1 つのインスタンスグループは である必要がありますController。 | | PartitionNames | 条件付き。Slurm パーティション名。Compute ノードタイプに必須。 Controllerまたは では許可されませんLogin。 | **Orchestrator.Slurm** (クラスターレベル): ``` "Orchestrator": { "Slurm": { "SlurmConfigStrategy": "Managed | Overwrite | Merge" } } ``` `SlurmConfigStrategy` は、HyperPod がコントローラーノード`slurm.conf`上の partition-to-node間のマッピングを管理する方法を決定します。クラスターを作成または更新すると、HyperPod は各インスタンスグループで`SlurmConfig`定義した `slurm.conf` に基づいてパーティション設定を に書き込み、コンピューティングインスタンスグループを割り当てられたパーティションにマッピングし、コントローラーノードとログインノードを適切な Slurm ロールに登録します。 選択した戦略は、管理者がコントローラーノードでファイルを直接編集するなど、 のパーティション設定`slurm.conf`が API の外部で変更された場合の動作を制御します。では`Managed`、HyperPod は API を単一の信頼できるソースとして扱い、ディスク`slurm.conf`上の がドリフトした場合に更新を検出してブロックします。では`Overwrite`、HyperPod は API 定義の設定をコントローラーに強制的に適用し、 への手動編集はすべて破棄します`slurm.conf`。これは、意図しない変更からの復旧に役立ちます。では`Merge`、HyperPod は への手動編集を保持`slurm.conf`し、API 設定とマージします。これにより、高度なユーザーは API マネージドパーティションとともにカスタム`slurm.conf`設定を柔軟に維持できます。 | 方針 | パーティションドリフト検出 | 手動変更 | ユースケース | | --- | --- | --- | --- | | Managed (デフォルト) | 有効。ドリフトが見つかった場合、更新をブロックする | サポートされていません | 単一の情報源 | | Overwrite | Disabled | 更新時に上書き | ドリフトからの復旧 | | Merge | Disabled | 保存およびマージ済み | カスタムslurm.confニーズ | **重要** ドリフト検出は、 の Slurm パーティション設定 `slurm.conf` ( partition-to-nodeマッピング) にのみ適用されます。スケジュールパラメータ、リソース制限、アカウンティング`slurm.conf`設定などの他の設定の変更はモニタリングされず、HyperPod によって検出または報告されません。 **注記** API の代わりに `provisioning_parameters.json` ファイルを使用して Slurm トポロジを定義する場合は、`SlurmConfig`インスタンスグループとクラスターリクエスト`Orchestrator.Slurm`から を省略し、ノードライフサイクルスクリプトとともにファイルを Amazon S3 にアップロードします。詳細については、「[SageMaker HyperPod Slurm の設定](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-slurm-configuration)」を参照してください。 ### ノードライフサイクル設定オプション SageMaker HyperPod Slurm クラスターを作成するときは、`CreateCluster`リクエストで `LifeCycleConfig`ブロックを設定して、各インスタンスグループのノードのプロビジョニング方法を選択します。SageMaker HyperPod は 3 つのノードライフサイクル設定オプションをサポートし、それぞれがプロビジョニングプロセスに対して異なるレベルの制御を提供します。 **AMI ベースの設定**のみの場合は、 `LifeCycleConfig`を完全に省略します。HyperPod は、AMI ベースの設定、Slurm の設定、必須パッケージのインストール、必要なすべてのサービスの開始を使用してノードを自動的に設定します。これは最も簡単なパスであり、Amazon S3 バケットやスクリプトは必要ありません。 **拡張機能**オプションでは、Amazon S3 `OnInitComplete`の拡張機能スクリプト`SourceS3Uri`を指す`LifeCycleConfig`とともに で を指定します。HyperPod は、まず完全な AMI ベースの設定を実行し、次にスクリプトを実行します。これにより、ベースラインプロビジョニングを管理することなく、モニタリングエージェント、LDAP 統合、追加のストレージマウントなどのカスタマイズを追加できます。 Custom ****オプションでは、Amazon S3 で設定されたライフサイクルスクリプト`SourceS3Uri`全体を指す`LifeCycleConfig`とともに、 `OnCreate`で を指定します。 Amazon S3 HyperPod は AMI ベースの設定を実行せず、Slurm を起動しません。スクリプトはプロビジョニングシーケンス全体を所有します。これにより、インストールされるソフトウェア、設定方法、Slurm の起動時期を完全に制御できます。 | ノードライフサイクルオプション | Amazon S3 バケットが必要ですか? | アップロードするスクリプト | API の LifeCycleConfig? | | --- | --- | --- | --- | | AMI ベースの設定のみ (最もシンプル) | いいえ | いいえ | 完全に省略する | | 拡張機能 (OnInitComplete) | はい | 拡張機能スクリプトのみ | OnInitComplete \+ SourceS3Uri | | カスタム (OnCreate) | はい | フルライフサイクルスクリプトセット | OnCreate \+ SourceS3Uri | **注記** オプションのノードライフサイクル設定は、Slurm オーケストレーションされたクラスターでのみサポートされます。Continuous を使用する EKS オーケストレーションクラスターと Slurm クラスターでは、すべてのインスタンスグループ`LifeCycleConfig`で `OnCreate`と `SourceS3Uri` `NodeProvisioningMode`が引き続き必要です。 **注記** `OnCreate` と `OnInitComplete`は相互に排他的です。同じインスタンスグループで両方を指定すると、検証エラーが発生します。 ### FSx と VPC の設定 ML ワークロードの場合、クラスターノード間でトレーニングデータ、モデルチェックポイント、共有ライブラリを保存するには、共有の高性能ファイルシステムが不可欠です。SageMaker HyperPod は、経由でインスタンスグループごとに設定された Amazon FSx for Lustre と FSx for OpenZFS をサポートしています`InstanceStorageConfigs`。FSx ファイルシステムは VPC に存在するため、FSx を使用する場合はカスタム VPC 設定 (`VpcConfig`) が必要です。 FSx 設定は、3 つのノードライフサイクル設定オプションすべてで機能します。AMI ベースの設定または を使用する場合`OnInitComplete`、HyperPod は FSx マウントを自動的に処理します。を使用する場合`OnCreate`、ライフサイクルスクリプトがマウントを担当します。 **FSx for Lustre:** ``` "InstanceStorageConfigs": [ { "FsxLustreConfig": { "DnsName": "fs-0abc123def456789.fsx.us-west-2.amazonaws.com", "MountPath": "/fsx", "MountName": "abcdefgh" } } ] ``` | フィールド | 説明 | | --- | --- | | DnsName | 必須。FSx for Lustre ファイルシステムの DNS 名。 | | MountPath | オプション。インスタンスのローカルマウントパス。デフォルト: /fsx | | MountName | 必須。FSx for Lustre ファイルシステムのマウント名。これは、FSx for Lustre コンソールまたは で検索しますaws fsx describe-file-systems。 | **FSx for OpenZFS:** ``` "InstanceStorageConfigs": [ { "FsxOpenZfsConfig": { "DnsName": "fs-0xyz789abc123456.fsx.us-west-2.amazonaws.com", "MountPath": "/shared" } } ] ``` | フィールド | 説明 | | --- | --- | | DnsName | 必須。FSx for OpenZFS ファイルシステムの DNS 名。 | | MountPath | オプション。インスタンスのローカルマウントパス。デフォルト: /home | **注記** 各インスタンスグループは、最大 1 つの FSx for Lustre と FSx for OpenZFS 設定を持つことができます。異なるインスタンスグループは、異なるファイルシステムをマウントできます。 **VPC 設定** (FSx に必要): `CreateCluster` リクエスト`VpcConfig`のクラスターレベルで を追加します。 ``` "VpcConfig": { "SecurityGroupIds": ["sg-0abc123def456789a"], "Subnets": ["subnet-0abc123def456789a"] } ``` VPC のセットアップの詳細については、「」を参照してください[SageMaker HyperPod を使用するための前提条件](sagemaker-hyperpod-prerequisites.md)。FSx のセットアップの詳細については、「」を参照してください[SageMaker HyperPod を使用するための前提条件](sagemaker-hyperpod-prerequisites.md)。 ## クラスターを作成する このセクションでは、「」で説明されている 3 つのノードライフサイクル設定オプションのそれぞれを使用してクラスターを作成する方法について説明します[ノードライフサイクル設定オプション](#smcluster-getting-started-slurm-cli-lifecycle-options)。ほとんどのユーザーには、**オプション A** の AMI ベースの設定から開始することをお勧めします。スクリプトや Amazon S3 バケットは不要で、完全に機能するクラスターをすぐに提供します。AMI ベースの設定の上にカスタマイズを追加する必要がある場合はオプション B、プロビジョニングプロセスを完全に制御する必要がある場合はオプション C を選択します。 すべての例`ExecutionRole`で、 `AmazonSageMakerClusterInstanceRolePolicy`で管理されている で作成した IAM ロールの ARN を指定します[SageMaker HyperPod を使用するための前提条件](sagemaker-hyperpod-prerequisites.md)。 ### オプション A: AMI ベースの設定のみ (ライフサイクル設定なし) これは最も簡単なパスです。Amazon S3 バケット、スクリプト、または設定ファイルは必要ありません。SageMaker HyperPod は、AMI ベースの設定を使用してノードを自動的に設定し、重要なソフトウェアをインストールして設定を適用することで、クラスターがすぐに ML ワークロードを実行できるようにします。すべてのソフトウェアパッケージは AMI に埋め込まれているため、プロビジョニング中にインターネットアクセスは必要ありません。 次の表に、AMI ベースの設定に含まれる機能を示します。 | 機能 | 説明 | | --- | --- | | スラムデーモン | コントローラーデーモンとコンピューティングデーモンが自動的に開始されました | | Docker | ML コンテナを構築および実行するためのコンテナランタイム | | エンルート | Slurm ワークロードのルートレスコンテナ実行 | | プロキシ | コンテナ統合用の Slurm プラグイン | | Slurm アカウンティング | ジョブ履歴とリソース消費量を追跡するための Slurm ジョブアカウンティングを設定します | | MariaDB | Slurm アカウンティングのバッキングデータベースとしてコントローラーノードに MariaDB をデプロイします | | SSH キーの生成 | デフォルトの ubuntu ユーザー用に生成されたキーペア | | SSH 伝達 | マルチノードジョブのコンピューティングノード間で伝達されるユーザー認証情報 | | Slurm ログのローテーション | ログの肥大化とディスクいっぱいの問題を防止 | | ホームディレクトリのセットアップ | 共有ファイルシステムにマウントされた Ubuntu ユーザーホームディレクトリ | 1. 次のように として保存します`create_cluster.json`。 ``` { "ClusterName": "my-hyperpod-cluster", "InstanceGroups": [ { "InstanceGroupName": "my-controller-group", "InstanceType": "ml.c5.xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Controller" }, "ExecutionRole": "arn:aws:iam::{{111122223333}}:role/HyperPodExecutionRole", "InstanceStorageConfigs": [ { "EbsVolumeConfig": { "VolumeSizeInGB": 500 } } ] }, { "InstanceGroupName": "my-login-group", "InstanceType": "ml.m5.4xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Login" }, "ExecutionRole": "arn:aws:iam::{{111122223333}}:role/HyperPodExecutionRole" }, { "InstanceGroupName": "worker-group-1", "InstanceType": "ml.trn1.32xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Compute", "PartitionNames": ["partition-1"] }, "ExecutionRole": "arn:aws:iam::{{111122223333}}:role/HyperPodExecutionRole", "InstanceStorageConfigs": [ { "FsxLustreConfig": { "DnsName": "{{fs-0abc123def456789.fsx.us-west-2.amazonaws.com}}", "MountPath": "/fsx", "MountName": "{{abcdefgh}}" } } ] } ], "Orchestrator": { "Slurm": { "SlurmConfigStrategy": "Managed" } }, "VpcConfig": { "SecurityGroupIds": ["{{sg-0abc123def456789a}}"], "Subnets": ["{{subnet-0abc123def456789a}}"] } } ``` インスタンスグループには `LifeCycleConfig`が指定されていないことに注意してください。 Slurm トポロジは、各インスタンスグループ`SlurmConfig`で を介して定義されます。 `my-controller-group`には`Controller`ロールが割り当てられ ( を実行`slurmctld`)、ユーザーアクセスの`Login`ノード`my-login-group`として機能し、 はジョブスケジューリング`partition-1`の に割り当てられた`Compute`ノード`worker-group-1`です。クラスターレベルでは、 は HyperPod がパーティション設定の唯一の信頼できるソースであることを`SlurmConfigStrategy: "Managed"`保証します。ワーカーグループには、共有ストレージ`/fsx`用に にマウントされた FSx for Lustre ファイルシステムが含まれており、FSx の必要に応じてクラスターレベルで`VpcConfig`指定されます。 **ヒント** FSx なしでテストする場合は、リクエスト`FsxLustreConfig`から を省略`InstanceStorageConfigs`したり、リクエスト`VpcConfig`から削除したりできます。FSx はクラスターの作成には必要ありませんが、本番稼働用 ML ワークロードには推奨されます。 1. クラスターを作成します。 ``` aws sagemaker create-cluster \ --cli-input-json {{file://create_cluster.json}} ``` 1. ステータスを確認します。 ``` aws sagemaker describe-cluster --cluster-name {{my-hyperpod-cluster}} ``` AMI ベースの設定のみの場合、レスポンスのインスタンスグループには`LifeCycleConfig`ブロックは含まれません。以下は、コントローラーインスタンスグループを示す切り捨てられた例です。 ``` { "ClusterName": "my-hyperpod-cluster", "ClusterStatus": "InService", "InstanceGroups": [ { "InstanceGroupName": "my-controller-group", "SlurmConfig": { "NodeType": "Controller" } } ] } ``` ステータスが になったら**InService**、 に進みます[クラスターに接続する](#smcluster-getting-started-slurm-cli-connect)。 ### オプション B: OnInitComplete を使用して AMI ベースの設定を拡張する このオプションは、エージェントのモニタリング、LDAP/SSSD 統合、追加のストレージマウントなど、AMI ベースの設定に加えてカスタマイズが必要な場合に使用します。SageMaker HyperPod は最初に AMI ベースの設定を実行し、次に拡張機能スクリプトを実行します。 1. 拡張機能スクリプトを記述します。例`extend-defaults.sh`: ``` #!/bin/bash set -e echo "Running post-initialization customizations..." # Example: Install a monitoring agent # apt-get install -y my-monitoring-agent # Example: Configure LDAP integration # /opt/custom/setup-ldap.sh # Example: Mount an additional S3 bucket # mount-s3 my-data-bucket /mnt/s3-data echo "Custom extensions complete." ``` **Awsome Distributed Training リポジトリから拡張スクリプトを使用する** Awsome Distributed Training リポジトリの [Extensions フォルダ](https://github.com/awslabs/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/Extensions)にはready-to-use拡張スクリプトが用意されています。各機能は、スクリプトとして直接提供できる独自のエントリポイントスクリプトを使用して、独自のディレクトリに自己完結型です`OnInitComplete`。 複数の機能を必要とするクラスターの場合は、拡張機能フォルダの最上位にある`run_extensions.sh`スクリプトを使用することをお勧めします。このスクリプトは、使用可能なすべての拡張機能スクリプトをオーケストレーションし、各機能を有効または無効にするためのシンプルなブールトグルを提供します。これを使用するには、拡張機能フォルダ全体を Amazon S3 バケットにアップロードし、`OnInitComplete`スクリプト`run_extensions.sh`として を指定します。 ``` s3://// |-- run_extensions.sh (OnInitComplete target) |-- detect-node/ (node type detection utility) |-- add-users/ (user management scripts + config) |-- observability/ (observability scripts + config) ``` 内で`run_extensions.sh`、対応する フラグを設定して、各機能を有効または無効にします。 ``` ENABLE_ADD_USERS="true" ENABLE_OBSERVABILITY="true" ``` 有効な各機能の設定ファイルは、Amazon S3 にアップロードする前に入力する必要があります。設定の詳細については、各機能の ディレクトリの README を参照してください。 1. Amazon S3 にアップロードする (バケットパスは で始まる必要があります`s3://sagemaker-`)。 ``` aws s3 cp extend-defaults.sh \ s3://sagemaker-{{amzn-s3-demo-bucket}}/scripts/ ``` 1. 次のように として保存します`create_cluster.json`。 ``` { "ClusterName": "my-hyperpod-cluster", "InstanceGroups": [ { "InstanceGroupName": "my-controller-group", "InstanceType": "ml.c5.xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Controller" }, "LifeCycleConfig": { "OnInitComplete": "extend-defaults.sh", "SourceS3Uri": "s3://sagemaker-{{amzn-s3-demo-bucket}}/scripts/" }, "ExecutionRole": "arn:aws:iam::{{111122223333}}:role/HyperPodExecutionRole", "InstanceStorageConfigs": [ { "EbsVolumeConfig": { "VolumeSizeInGB": 500 } } ] }, { "InstanceGroupName": "my-login-group", "InstanceType": "ml.m5.4xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Login" }, "LifeCycleConfig": { "OnInitComplete": "extend-defaults.sh", "SourceS3Uri": "s3://sagemaker-{{amzn-s3-demo-bucket}}/scripts/" }, "ExecutionRole": "arn:aws:iam::{{111122223333}}:role/HyperPodExecutionRole" }, { "InstanceGroupName": "worker-group-1", "InstanceType": "ml.trn1.32xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Compute", "PartitionNames": ["partition-1"] }, "LifeCycleConfig": { "OnInitComplete": "extend-defaults.sh", "SourceS3Uri": "s3://sagemaker-{{amzn-s3-demo-bucket}}/scripts/" }, "ExecutionRole": "arn:aws:iam::{{111122223333}}:role/HyperPodExecutionRole" } ], "Orchestrator": { "Slurm": { "SlurmConfigStrategy": "Managed" } } } ``` **重要** `OnInitComplete` を指定すると、 `SourceS3Uri`は必須です。 `OnCreate`と `OnInitComplete` は同じインスタンスグループで一緒に使用することはできません。 **ヒント** クラスター内でオプションを混在させることができます。たとえば、AMI ベースの設定は、コントローラーと`OnInitComplete`ワーカーでのみ使用します。 Slurm トポロジはオプション A と同じです。各インスタンスグループにはノードロールとパーティション割り当て`SlurmConfig`を定義する があり、クラスターレベルで`SlurmConfigStrategy: "Managed"`設定されます。唯一の違いは、 `LifeCycleConfig`に を追加することです。これにより`OnInitComplete`、各ノードで AMI ベースの設定が完了した後に、拡張スクリプトを実行するように HyperPod に指示します。FSx を追加するには、関連するインスタンスグループに `FsxLustreConfig`または `FsxOpenZfsConfig`を `InstanceStorageConfigs` に含め、`VpcConfig`「」で説明されているようにクラスターレベルで を追加します[FSx と VPC の設定](#smcluster-getting-started-slurm-cli-fsx-vpc)。 1. クラスターを作成します。 ``` aws sagemaker create-cluster \ --cli-input-json {{file://create_cluster.json}} ``` 1. ステータスを確認します。 ``` aws sagemaker describe-cluster --cluster-name {{my-hyperpod-cluster}} ``` では`OnInitComplete`、レスポンスが `OnInitComplete`に表示されます`LifeCycleConfig`。以下は、コントローラーインスタンスグループを示す切り捨てられた例です。 ``` { "ClusterName": "my-hyperpod-cluster", "ClusterStatus": "InService", "InstanceGroups": [ { "InstanceGroupName": "my-controller-group", "SlurmConfig": { "NodeType": "Controller" }, "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-{{amzn-s3-demo-bucket}}/scripts/", "OnInitComplete": "extend-defaults.sh" } } ] } ``` ステータスが になったら**InService**、 に進みます[クラスターに接続する](#smcluster-getting-started-slurm-cli-connect)。 ### オプション C: OnCreate によるフルカスタムコントロール (アドバンスド) このオプションは、ソフトウェアのインストール、インフラストラクチャの変更、Slurm の起動時期の決定など、プロビジョニングを完全に制御する必要がある場合に使用します。では`OnCreate`、SageMaker HyperPod は AMI ベースの設定を実行**せず**、Slurm を自動的に起動**しません**。 **注記** SageMaker HyperPod を初めて使用し、特定のカスタマイズ要件がない場合は、オプション A またはオプション B から始めることをお勧めします。後でいつでもカスタムモードに移行できます。 1. ライフサイクルスクリプトを準備して Amazon S3 にアップロードします。最初から開始する場合は、[Awsome Distributed Training GitHub リポジトリ](https://github.com/aws-samples/awsome-distributed-training/)のサンプルスクリプトを使用します。 ``` git clone https://github.com/aws-samples/awsome-distributed-training/ cd awsome-distributed-training/1.architectures/5.sagemaker_hyperpods/LifecycleScripts/base-config ``` Amazon S3 にアップロードする (バケットパスは で始まる必要があります`s3://sagemaker-`)。 ``` aws s3 sync . \ s3://sagemaker-{{amzn-s3-demo-bucket}}/lifecycle/src ``` ライフサイクルスクリプトの詳細については、「[ライフサイクルスクリプトを使用して SageMaker HyperPod クラスターをカスタマイズする](sagemaker-hyperpod-lifecycle-best-practices-slurm.md)」を参照してください。 1. 次のように として保存します`create_cluster.json`。 ``` { "ClusterName": "my-hyperpod-cluster", "InstanceGroups": [ { "InstanceGroupName": "my-controller-group", "InstanceType": "ml.c5.xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Controller" }, "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-{{amzn-s3-demo-bucket}}/lifecycle/src", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::{{111122223333}}:role/HyperPodExecutionRole", "InstanceStorageConfigs": [ { "EbsVolumeConfig": { "VolumeSizeInGB": 500 } } ] }, { "InstanceGroupName": "my-login-group", "InstanceType": "ml.m5.4xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Login" }, "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-{{amzn-s3-demo-bucket}}/lifecycle/src", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::{{111122223333}}:role/HyperPodExecutionRole" }, { "InstanceGroupName": "worker-group-1", "InstanceType": "ml.trn1.32xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Compute", "PartitionNames": ["partition-1"] }, "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-{{amzn-s3-demo-bucket}}/lifecycle/src", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::{{111122223333}}:role/HyperPodExecutionRole" } ], "Orchestrator": { "Slurm": { "SlurmConfigStrategy": "Managed" } } } ``` Slurm トポロジは、他のオプションと同じ`SlurmConfig`パターンに従います。主な違いは `LifeCycleConfig`です`OnCreate`。これにより、HyperPod は AMI ベースの設定を完全にスキップし、代わりに`on_create.sh`スクリプトを実行するように指示されます。スクリプトは、ソフトウェアのインストール、Slurm の設定、Slurm デーモンの開始など、プロビジョニングシーケンス全体を担当します。FSx を追加するには、関連するインスタンスグループに `FsxLustreConfig`または `FsxOpenZfsConfig`を `InstanceStorageConfigs` に含め、`VpcConfig`「」で説明されているようにクラスターレベルで を追加します[FSx と VPC の設定](#smcluster-getting-started-slurm-cli-fsx-vpc)。 1. クラスターを作成します。 ``` aws sagemaker create-cluster \ --cli-input-json {{file://create_cluster.json}} ``` 1. ステータスを確認します。 ``` aws sagemaker describe-cluster --cluster-name {{my-hyperpod-cluster}} ``` では`OnCreate`、レスポンスが `OnCreate`に表示されます`LifeCycleConfig`。以下は、コントローラーインスタンスグループを示す切り捨てられた例です。 ``` { "ClusterName": "my-hyperpod-cluster", "ClusterStatus": "InService", "InstanceGroups": [ { "InstanceGroupName": "my-controller-group", "SlurmConfig": { "NodeType": "Controller" }, "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-{{amzn-s3-demo-bucket}}/lifecycle/src", "OnCreate": "on_create.sh" } } ] } ``` ステータスが になったら**InService**、 に進みます[クラスターに接続する](#smcluster-getting-started-slurm-cli-connect)。 ### 一般的な検証エラー | エラー | 解像度 | | --- | --- | | 「クラスターには Controller ノードタイプを持つ InstanceGroup が 1 つだけ必要です」 | 1 つのインスタンスグループに があることを確認しますSlurmConfig.NodeType。 "Controller" | | 「パーティションは Compute ノードタイプにのみ割り当てることができます」 | Controller またはLoginインスタンスグループPartitionNamesから削除する | | FSx 設定はカスタム VPC でのみサポートされています」 | FSx の使用時に VpcConfigをリクエストに追加する | | 「インスタンスグループにはLifeCycleConfig が必要です...」 | EKS クラスターまたは Slurm Continuous NodeProvisioningMode。オプションのノードライフサイクル設定はサポートされていません。 | | LifeCycleConfig の OnCreate と OnInitComplete は相互に排他的です...」 | OnCreate または を削除しますOnInitComplete。両方を指定することはできません。 | | 「インスタンスグループのLifeCycleConfig が不完全です...」 | OnCreate または OnInitCompleteを指定するSourceS3Uri場合は、 も指定する必要があります。 | | LifeCycleConfig はオプションですが、互換性のある AMI が必要です...」 | UpdateClusterSoftware を実行して、オプションのノードライフサイクル設定をサポートする AMI に更新します。 | | 「インスタンスグループのLifeCycleConfig は提供されていますが、設定は含まれていません...」 | OnCreate または SourceS3Uriで を指定するかOnInitComplete、 LifeCycleConfigを完全に省略します。 | ## クラスターに接続する クラスターのステータスが **InService** (通常は 10～15 分) になったら、接続して確認します。 1. インスタンス IDs。 ``` aws sagemaker list-cluster-nodes --cluster-name {{my-hyperpod-cluster}} ``` 1. AWS Systems Manager Session Manager を使用して接続します。 ``` aws ssm start-session \ --target sagemaker-cluster:{{my-hyperpod-cluster}}_{{my-login-group}}-{{i-0abc123def456789b}} \ --region {{us-west-2}} ``` 1. Slurm が正しく設定されていることを確認します。 ``` # Check Slurm nodes sinfo # Check Slurm partitions sinfo -p partition-1 # Submit a test job srun -p partition-1 --nodes=1 hostname ``` ML ワークロードの実行の詳細については、「」を参照してください[SageMaker HyperPod クラスター上のジョブ](sagemaker-hyperpod-run-jobs-slurm.md)。 ## クラスターを削除してリソースをクリーンアップする テスト後、継続的な料金が発生しないように、クラスターを削除します。 ``` aws sagemaker delete-cluster --cluster-name {{my-hyperpod-cluster}} ``` ノードライフサイクルスクリプト (オプション B またはオプション C) を使用した場合は、Amazon S3 バケットをクリーンアップします。 ``` aws s3 rm s3://sagemaker-{{amzn-s3-demo-bucket}}/{{lifecycle/src}} --recursive ``` AMI ベースの設定のみを使用した場合 (オプション A)、ノードライフサイクルスクリプトに Amazon S3 クリーンアップは必要ありません。 トレーニングワークロードを実行した場合は、Amazon S3、Amazon FSx for Lustre、または Amazon Elastic File System のデータまたはアーティファクトもチェックし、料金が発生しないように削除します。 ## 関連トピック + [SageMaker HyperPod Slurm の設定](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-slurm-configuration) + [ライフサイクルスクリプトを使用して SageMaker HyperPod クラスターをカスタマイズする](sagemaker-hyperpod-lifecycle-best-practices-slurm.md) + [InstanceStorageConfigs 経由の FSx 設定](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-slurm-fsx-config) + [SageMaker HyperPod Slurm クラスターオペレーション](sagemaker-hyperpod-operate-slurm.md) + [SageMaker HyperPod の拡張機能スクリプト](https://github.com/awslabs/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/Extensions) + [ライフサイクルスクリプトを使用して SageMaker HyperPod クラスターをカスタマイズする](sagemaker-hyperpod-lifecycle-best-practices-slurm.md)