翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # ライフサイクルスクリプトを使用して SageMaker HyperPod クラスターをカスタマイズする SageMaker HyperPod は、常に稼働を続けるコンピューティングクラスターを提供します。これは、クラスターリソースのセットアップ方法を SageMaker HyperPod に指示するライフサイクルスクリプトを記述できるため、高度にカスタマイズ可能です。以下のトピックは、オープンソースのワークロードマネージャーツールで SageMaker HyperPod クラスターを設定するライフサイクルスクリプトを準備するためのベストプラクティスです。 以下のトピックでは、SageMaker HyperPod で Slurm 設定をセットアップするライフサイクルスクリプトを準備するための詳細なベストプラクティスについて説明します。 ## 概要 次の手順は、HyperPod クラスターをプロビジョニングし、Slurm で設定する主なフローです。ステップは、***ボトムアップ***アプローチの順番で並べられています。 1. HyperPod クラスターに Slurm ノードを作成する方法を計画します。例えば、2 つの Slurm ノードを設定する場合、HyperPod クラスターに 2 つのインスタンスグループを設定する必要があります。 1. Slurm 設定を準備します。次のいずれかのアプローチを選択します。 + **オプション A: API 駆動型設定 (推奨)** – 各インスタンスグループ`SlurmConfig`内で を使用して`CreateCluster`、API ペイロードで Slurm ノードタイプとパーティションを直接定義します。このアプローチでは、次のようになります。 + `provisioning_parameters.json` ファイルは必要ありません + Slurm トポロジは、インスタンスグループ定義とともに API ペイロードで定義されます。 + FSx ファイルシステムは、 per-instance-group設定されます。 `InstanceStorageConfigs` + 設定戦略は によって制御されます。 `Orchestrator.Slurm.SlurmConfigStrategy` `SlurmConfig` インスタンスグループの例: ``` { "InstanceGroupName": "gpu-compute", "InstanceType": "ml.p4d.24xlarge", "InstanceCount": 8, "SlurmConfig": { "NodeType": "Compute", "PartitionNames": ["gpu-training"] } } ``` + **オプション B: レガシー設定** – `provisioning_parameters.json` ファイルを準備します。これは です[provisioning\$1parameters.json の設定フォーム](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-provisioning-forms-slurm)。 には、HyperPod クラスターでプロビジョニングする Slurm ノード設定情報が含まれている`provisioning_parameters.json`必要があります。これは、ステップ 1 の Slurm ノードの設計を反映している必要があります。 1. 一連のライフサイクルスクリプトを準備して、ソフトウェアパッケージをインストールし、ユースケース用にクラスターに環境をセットアップするよう HyperPod で Slurm を設定します。ライフサイクルスクリプトを中央の Python スクリプト (`lifecycle_script.py`) でまとめて実行されるように構成し、エントリポイントシェルスクリプト (`on_create.sh`) を記述して Python スクリプトを実行する必要があります。エントリポイントシェルスクリプトは、ステップ 5 の後半で HyperPod クラスター作成リクエストに提供する必要があります。 さらに、クラスターの作成時に HyperPod によって生成される `resource_config.json` を期待するスクリプトも記述する必要がある点に注意してください。`resource_config.json` には、IP アドレス、インスタンスタイプ、ARN などの HyperPod クラスターリソース情報が含まれており、Slurm の設定に使用する必要があります。 1. 前のステップのすべてのファイルをフォルダに集めます。フォルダ構造は、ステップ 2 で選択した設定アプローチによって異なります。 オプション A (API 駆動型設定) を選択した場合: フォルダに必要なのは、カスタムセットアップタスクのライフサイクルスクリプトのみです。Slurm 設定と FSx マウントは、API ペイロードに基づいて HyperPod によって自動的に処理されます。 ``` └── lifecycle_files // your local folder ├── on_create.sh ├── lifecycle_script.py └── ... // more setup scripts to be fed into lifecycle_script.py ``` **注記** API 駆動型設定を使用する場合、 `provisioning_parameters.json` ファイルは必須ではありません。 オプション B (レガシー設定) を選択した場合: フォルダには、 `provisioning_parameters.json`とライフサイクルスクリプトの完全なセットが含まれている必要があります。 ``` └── lifecycle_files // your local folder ├── provisioning_parameters.json ├── on_create.sh ├── lifecycle_script.py └── ... // more setup scrips to be fed into lifecycle_script.py ``` 1. すべてのファイルを S3 バケットにアップロードします。S3 バケットパスをコピーして保持します。`sagemaker-` で始まる S3 バケットパスを作成する必要がある点に注意してください。プレフィックス `sagemaker-` で始まる S3 バケットパスのみを許可する、[`AmazonSageMakerClusterInstanceRolePolicy`](security-iam-awsmanpol-AmazonSageMakerClusterInstanceRolePolicy.md) でアタッチされた [SageMaker HyperPod の IAM ロール](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod) を選択する必要があります。次のコマンドは、すべてのファイルを S3 バケットにアップロードするコマンドの例です。 ``` aws s3 cp --recursive ./lifecycle_files s3://sagemaker-hyperpod-lifecycle/src ``` 1. HyperPod クラスター作成リクエストを準備します。 + オプション 1: を使用する場合は AWS CLI、「」の手順に従って、クラスター作成リクエストを JSON 形式 (`create_cluster.json`) で書き込みます[新しいクラスターを作成する](sagemaker-hyperpod-operate-slurm-cli-command.md#sagemaker-hyperpod-operate-slurm-cli-command-create-cluster)。 + オプション 2: SageMaker AI コンソール UI を使用する場合、「[SageMaker HyperPod クラスターを作成する](sagemaker-hyperpod-operate-slurm-console-ui.md#sagemaker-hyperpod-operate-slurm-console-ui-create-cluster)」の手順に従って、HyperPod コンソール UI で **[クラスターを作成]** リクエストフォームに入力します。 この段階では、ステップ 1 と 2 で計画したのと同じ構造でインスタンスグループを作成してください。さらに、リクエストフォームでステップ 5 の S3 バケットを指定していることも確認してください。 1. クラスター作成リクエストを送信します。HyperPod はリクエストに基づいてクラスターをプロビジョニングした後、HyperPod クラスターインスタンスで `resource_config.json` ファイルを作成し、ライフサイクルスクリプトを実行しているクラスターで Slurm を設定します。 以下のトピックでは、HyperPod クラスターの作成時に適切に整理するよう設定ファイルとライフサイクルスクリプトを整理する方法について詳しく説明します。 **Topics** + [概要](#sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-highlevel-overview) + [HyperPod が提供する基本ライフサイクルスクリプト](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) + [Slurm 設定ファイルで HyperPod が管理する特定の設定](sagemaker-hyperpod-lifecycle-best-practices-slurm-what-hyperpod-overrides-in-slurm-conf.md) + [Slurm ログのローテーション](sagemaker-hyperpod-slurm-log-rotation.md) + [Amazon FSx for Lustre および Amazon FSx for OpenZFS を HyperPod クラスターにマウントする](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-setup-with-fsx.md) + [HyperPod での Slurm クラスター作成前の JSON 設定ファイルの検証](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-validate-json-files.md) + [HyperPod Slurm クラスターでの本番稼働ワークロード実行前のランタイム検証](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-validate-runtime.md) + [HyperPod クラスターノードでのライフサイクルスクリプトのインタラクティブ開発](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-develop-lifecycle-scripts.md) # HyperPod が提供する基本ライフサイクルスクリプト このセクションでは、***トップダウン***アプローチを使用して HyperPod で Slurm を設定する基本的なフローのすべてのコンポーネントについて説明します。これは、`CreateCluster` API を実行する HyperPod クラスター作成リクエストの準備から始まり、階層構造をライフサイクルスクリプトにまで掘り下げます。[Awsome Distributed Training GitHub リポジトリ](https://github.com/aws-samples/awsome-distributed-training/)で提供されているサンプルライフサイクルスクリプトを使用します。次のコマンドを実行して、リポジトリのクローンを作成します。 ``` git clone https://github.com/aws-samples/awsome-distributed-training/ ``` SageMaker HyperPod で Slurm クラスターを設定するための基本ライフサイクルスクリプトは、[https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config) で入手できます。 ``` cd awsome-distributed-training/1.architectures/5.sagemaker_hyperpods/LifecycleScripts/base-config ``` 次のフローチャートは、基本ライフサイクルスクリプトの設計方法の詳細な概要を示しています。以下の図と手順ガイドでは、HyperPod `CreateCluster` API コール時の動作について説明しています。 ![\[HyperPod クラスター作成とライフサイクルスクリプトの構造の詳細なフローチャート。\]](http://docs.aws.amazon.com/ja_jp/sagemaker/latest/dg/images/hyperpod-lifecycle-structure.png) ***図:** HyperPod クラスター作成とライフサイクルスクリプトの構造の詳細なフローチャート。(1) 破線の矢印はボックスが「呼び出される」場所を指しており、設定ファイルとライフサイクル スクリプトの準備の流れを示しています。`provisioning_parameters.json` とライフサイクルスクリプトの準備から始まります。その後、これらは `lifecycle_script.py` でコード化され、集合実行が順番に行われます。また、`lifecycle_script.py` スクリプトの実行は、HyperPod インスタンスターミナルで実行される `on_create.sh` シェルスクリプトによって行われます。(2) 実線の矢印は、HyperPod クラスターの主な作成フローと、ボックスがどのように「呼び出される」か、または「送信される」かを示しています。`on_create.sh` は、`create_cluster.json` またはコンソール UI の **[クラスターを作成]** リクエストフォームのいずれかで、クラスター作成リクエストに必要となります。リクエストを送信すると、HyperPod はリクエストとライフサイクルスクリプトの指定された設定情報に基づいて `CreateCluster` API を実行します。(3) 点線の矢印は、クラスターリソースのプロビジョニング時に HyperPod プラットフォームがクラスターインスタンスに `resource_config.json` を作成することを示しています。`resource_config.json` には、クラスター ARN、インスタンスタイプ、IP アドレスなどの HyperPod クラスターリソース情報が含まれています。クラスターの作成時に `resource_config.json` ファイルを期待するようライフサイクルスクリプトを準備する必要がある点に注意してください。詳細については、以下の手順ガイドを参照してください。* 以下の手順ガイドでは、HyperPod クラスターの作成中に何が起こるか、および基本ライフサイクルスクリプトの設計方法について説明しています。 1. `create_cluster.json` – HyperPod クラスター作成リクエストを送信するには、JSON 形式の `CreateCluster` リクエストファイルを準備します。このベストプラクティス例では、リクエストファイルの名前が `create_cluster.json` であると想定しています。インスタンスグループを使用して HyperPod クラスターをプロビジョニングするには、`create_cluster.json` を書き込みます。ベストプラクティスとして、HyperPod クラスターで設定する予定の Slurm ノードの数と同じ数のインスタンスグループを追加することをお勧めします。設定する予定の Slurm ノードに割り当てるインスタンスグループに、固有の名前を付けてください。 さらに、S3 バケットパスを指定して、設定ファイルとライフサイクルスクリプトのセット全体を `CreateCluster` リクエストフォームのフィールド名 `InstanceGroups.LifeCycleConfig.SourceS3Uri` に保存し、エントリポイントシェルスクリプトのファイル名 (`on_create.sh` という名前であると想定します) を `InstanceGroups.LifeCycleConfig.OnCreate` に指定する必要があります。 **注記** HyperPod コンソール UI で **[クラスターを作成]** 送信フォームを使用する場合、コンソールはユーザーに代わって `CreateCluster` リクエストの入力と送信を管理し、`CreateCluster` API をバックエンドで実行します。この場合、`create_cluster.json` を作成する必要はありません。代わりに、**[クラスターを作成]** 送信フォームに正しいクラスター設定情報を指定してください。 1. `on_create.sh` – インスタンスグループごとに、コマンドを実行するエントリポイントシェルスクリプト `on_create.sh` を提供して、ソフトウェアパッケージをインストールするスクリプトを実行し、Slurm のある HyperPod クラスター環境を設定する必要があります。Slurm を設定するために HyperPod が必要とする `provisioning_parameters.json` と、ソフトウェアパッケージをインストールするための一連のライフサイクルスクリプトの 2 つを準備する必要があります。このスクリプトは、[https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/on_create.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/on_create.sh) のサンプルスクリプトに示すように、以下のファイルを検索して実行するよう記述する必要があります。 **注記** ライフサイクルスクリプトのセット全体を、`create_cluster.json` で指定した S3 の場所にアップロードしてください。さらに、`provisioning_parameters.json` を同じ場所に配置する必要もあります。 1. `provisioning_parameters.json` – これは [provisioning\$1parameters.json の設定フォーム](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-provisioning-forms-slurm) です。`on_create.sh` スクリプトはこの JSON ファイルを見つけ、そのパスを識別するための環境変数を定義します。この JSON ファイルを使用して、通信する Slurm 用 Amazon FSx for Lustre などの Slurm ノードとストレージオプションを設定できます。`provisioning_parameters.json` では、`create_cluster.json` で指定した名前を使用して HyperPod クラスターインスタンスグループを、設定方法に基づいて Slurm ノードに適切に割り当ててください。 次の図は、HyperPod インスタンスグループが Slurm ノードに割り当てられるよう 2 つの JSON 設定ファイル `create_cluster.json` および `provisioning_parameters.json` を記述する方法の例を示しています。この例では、コントローラー (管理) ノード、ログインノード (オプション)、コンピューティング (ワーカー) ノードの 3 つの Slurm ノードを設定するケースを想定しています。 **ヒント** これらの 2 つの JSON ファイルを検証するため、HyperPod サービスチームは検証スクリプト [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/validate-config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/validate-config.py) を用意しています。詳細については[HyperPod での Slurm クラスター作成前の JSON 設定ファイルの検証](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-validate-json-files.md)を参照してください。 ![\[.json ファイル間の直接比較。\]](http://docs.aws.amazon.com/ja_jp/sagemaker/latest/dg/images/hyperpod-lifecycle-slurm-config.png) ***図:** HyperPod クラスター作成用の `create_cluster.json` と Slurm 設定用の `provisiong_params.json` の直接比較。`create_cluster.json` のインスタンスグループの数は、Slurm ノードとして設定するノードの数と一致する必要があります。図の例のケースでは、3 つのインスタンスグループの HyperPod クラスターに 3 つの Slurm ノードが設定されます。HyperPod クラスターインスタンスグループは、インスタンスグループ名を適切に指定して Slurm ノードに割り当てる必要があります。* 1. `resource_config.json` – クラスターの作成時、`lifecycle_script.py` スクリプトは HyperPod からの `resource_config.json` ファイルを期待するよう記述されます。このファイルには、インスタンスタイプや IP アドレスなど、クラスターに関する情報が含まれています。 `CreateCluster` API を実行すると、HyperPod は `create_cluster.json` ファイルに基づいて `/opt/ml/config/resource_config.json` にリソース設定ファイルを作成します。ファイルパスは、`SAGEMAKER_RESOURCE_CONFIG_PATH` という名前の環境変数に保存されます。 **重要** `resource_config.json` ファイルは、HyperPod プラットフォームによって自動生成されるため、作成する必要はありません。次のコードは、前のステップで `create_cluster.json` に基づいてクラスターの作成から作成される `resource_config.json` の例を示しており、バックエンドで何が行われ、自動生成された `resource_config.json` がどのようになるかを理解するのに役立ちます。 ``` { "ClusterConfig": { "ClusterArn": "arn:aws:sagemaker:us-west-2:111122223333:cluster/abcde01234yz", "ClusterName": "your-hyperpod-cluster" }, "InstanceGroups": [ { "Name": "controller-machine", "InstanceType": "ml.c5.xlarge", "Instances": [ { "InstanceName": "controller-machine-1", "AgentIpAddress": "111.222.333.444", "CustomerIpAddress": "111.222.333.444", "InstanceId": "i-12345abcedfg67890" } ] }, { "Name": "login-group", "InstanceType": "ml.m5.xlarge", "Instances": [ { "InstanceName": "login-group-1", "AgentIpAddress": "111.222.333.444", "CustomerIpAddress": "111.222.333.444", "InstanceId": "i-12345abcedfg67890" } ] }, { "Name": "compute-nodes", "InstanceType": "ml.trn1.32xlarge", "Instances": [ { "InstanceName": "compute-nodes-1", "AgentIpAddress": "111.222.333.444", "CustomerIpAddress": "111.222.333.444", "InstanceId": "i-12345abcedfg67890" }, { "InstanceName": "compute-nodes-2", "AgentIpAddress": "111.222.333.444", "CustomerIpAddress": "111.222.333.444", "InstanceId": "i-12345abcedfg67890" }, { "InstanceName": "compute-nodes-3", "AgentIpAddress": "111.222.333.444", "CustomerIpAddress": "111.222.333.444", "InstanceId": "i-12345abcedfg67890" }, { "InstanceName": "compute-nodes-4", "AgentIpAddress": "111.222.333.444", "CustomerIpAddress": "111.222.333.444", "InstanceId": "i-12345abcedfg67890" } ] } ] } ``` 1. `lifecycle_script.py` – これは、プロビジョニング中に HyperPod クラスターで Slurm を設定するライフサイクルスクリプトをまとめて実行するメイン Python スクリプトです。このスクリプトは、`on_create.sh` で指定または識別されたパスから `provisioning_parameters.json` および `resource_config.json` を読み取り、関連情報を各ライフサイクルスクリプトに渡してから、ライフサイクルスクリプトを順番に実行します。 ライフサイクルスクリプトは、Slurm の設定、ユーザーの作成、Conda または Docker のインストールなど、クラスターの作成中にソフトウェアパッケージをインストールしたり、必要な設定やカスタム設定をセットアップしたりするためにカスタマイズできる高い柔軟性を持つスクリプトのセットです。サンプル [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/lifecycle_script.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/lifecycle_script.py) スクリプトは、Slurm デーモン ([https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/start_slurm.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/start_slurm.sh)) の起動、Amazon FSx for Lustre ([https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/mount_fsx.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/mount_fsx.sh)) のマウント、MariaDB アカウンティング ([https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/setup_mariadb_accounting.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/setup_mariadb_accounting.sh)) と RDS アカウンティング ([https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/setup_rds_accounting.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/setup_rds_accounting.sh)) の設定など、リポジトリで他の基本ライフサイクルスクリプトを実行する準備ができています。さらに、スクリプトを追加して、同じディレクトリにパッケージ化し、コード行を `lifecycle_script.py` に追加して、HyperPod がスクリプトを実行可能にすることもできます。基本ライフサイクルスクリプトの詳細については、*Awsome Distributed Training GitHub リポジトリ* の「[3.1 Lifecycle scripts](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod#31-lifecycle-scripts)」も参照してください。 **注記** HyperPod はクラスターの各インスタンスで [SageMaker HyperPod DLAMI](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-hyperpod-ami) を実行します。AMI には、AMI と HyperPod の機能の互換性に準拠したソフトウェアパッケージがプリインストールされています。プリインストールされたパッケージのいずれかを再インストールする場合、互換性のあるパッケージをインストールしなければならず、一部の HyperPod 機能が正常に動作しない場合がある点に注意してください。 デフォルトのセットアップに加えて、以下のソフトウェアをインストールするための他のスクリプトが [https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils) フォルダに用意されています。`lifecycle_script.py` ファイルは、インストールスクリプトを実行するためのコード行を含める準備が既に整っているため、以下の項目を参照して行を検索し、コメントを解除してアクティブ化してください。 1. 次のコード行は、[Docker](https://www.docker.com/)、[Enroot](https://github.com/NVIDIA/enroot)、および [Pyxis](https://github.com/NVIDIA/pyxis) をインストールするためのものです。これらのパッケージは、Slurm クラスターで Docker コンテナを実行するために必要です。 このインストールステップを有効にするには、[https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py) ファイルで `enable_docker_enroot_pyxis` パラメータを `True` に設定します。 ``` # Install Docker/Enroot/Pyxis if Config.enable_docker_enroot_pyxis: ExecuteBashScript("./utils/install_docker.sh").run() ExecuteBashScript("./utils/install_enroot_pyxis.sh").run(node_type) ``` 1. HyperPod クラスターを [Amazon Managed Service for Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html) および [Amazon Managed Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html) と統合して、HyperPod クラスターとクラスターノードに関するメトリクスを Amazon Managed Grafana ダッシュボードにエクスポートできます。メトリクスをエクスポートし、Amazon Managed Grafana で [Slurm ダッシュボード](https://grafana.com/grafana/dashboards/4323-slurm-dashboard/)、[NVIDIA DCGM Exporter ダッシュボード](https://grafana.com/grafana/dashboards/12239-nvidia-dcgm-exporter-dashboard/)、および [EFA Metrics ダッシュボード](https://grafana.com/grafana/dashboards/20579-efa-metrics-dev/)を使用するには、[Prometheus の Slurm エクスポーター](https://github.com/vpenso/prometheus-slurm-exporter)、[NVIDIA DCGM エクスポーター](https://github.com/NVIDIA/dcgm-exporter)、および [EFA ノードエクスポーター](https://github.com/aws-samples/awsome-distributed-training/blob/main/4.validation_and_observability/3.efa-node-exporter/README.md)をインストールする必要があります。エクスポーターパッケージのインストールと Amazon Managed Grafana ワークスペースでの Grafana ダッシュボードの使用の詳細については、「[SageMaker HyperPod クラスターリソースのモニタリング](sagemaker-hyperpod-cluster-observability-slurm.md)」を参照してください。 このインストールステップを有効にするには、[https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py) ファイルで `enable_observability` パラメータを `True` に設定します。 ``` # Install metric exporting software and Prometheus for observability if Config.enable_observability: if node_type == SlurmNodeType.COMPUTE_NODE: ExecuteBashScript("./utils/install_docker.sh").run() ExecuteBashScript("./utils/install_dcgm_exporter.sh").run() ExecuteBashScript("./utils/install_efa_node_exporter.sh").run() if node_type == SlurmNodeType.HEAD_NODE: wait_for_scontrol() ExecuteBashScript("./utils/install_docker.sh").run() ExecuteBashScript("./utils/install_slurm_exporter.sh").run() ExecuteBashScript("./utils/install_prometheus.sh").run() ``` 1. **ステップ 2** のすべての設定ファイルとセットアップスクリプトを、**ステップ 1** の `CreateCluster` リクエストで指定した S3 バケットにアップロードしてください。例えば、`create_cluster.json` に以下のものがあるとします。 ``` "LifeCycleConfig": { "SourceS3URI": "s3://sagemaker-hyperpod-lifecycle/src", "OnCreate": "on_create.sh" } ``` その場合、`"s3://sagemaker-hyperpod-lifecycle/src"` には、`on_create.sh`、`lifecycle_script.py`、`provisioning_parameters.json`、および他のすべてのセットアップスクリプトが含まれています。次のように、ローカルフォルダにファイルを準備したとします。 ``` └── lifecycle_files // your local folder ├── provisioning_parameters.json ├── on_create.sh ├── lifecycle_script.py └── ... // more setup scrips to be fed into lifecycle_script.py ``` ファイルをアップロードするには、次のように S3 コマンドを使用します。 ``` aws s3 cp --recursive ./lifecycle_scripts s3://sagemaker-hyperpod-lifecycle/src ``` # Slurm 設定ファイルで HyperPod が管理する特定の設定 HyperPod で Slurm クラスターを作成すると、HyperPod エージェントは `/opt/slurm/etc/` で [https://slurm.schedmd.com/slurm.conf.html](https://slurm.schedmd.com/slurm.conf.html) ファイルと [https://slurm.schedmd.com/gres.conf.html](https://slurm.schedmd.com/gres.conf.html) ファイルをセットアップし、HyperPod クラスターの作成リクエストとライフサイクルスクリプトに基づいて Slum クラスターを管理します。次のリストは、HyperPod エージェントが処理および上書きする特定のパラメータを示しています。 **重要** HyperPod によって管理されるこれらのパラメータを変更**しない**ことを強くお勧めします。 + [https://slurm.schedmd.com/slurm.conf.html](https://slurm.schedmd.com/slurm.conf.html) では、HyperPod は基本パラメータ (`ClusterName`、`SlurmctldHost`、`PartitionName`、`NodeName`) を設定します。 さらに、[自動ノード復旧と自動再開](sagemaker-hyperpod-resiliency-slurm-auto-resume.md) 機能を有効にするには、次のように設定された `TaskPlugin` パラメータと `SchedulerParameters`パラメータが HyperPod に必要です。HyperPod エージェントは、これらの 2 つのパラメータをデフォルトで必要な値を使用して設定します。 ``` TaskPlugin=task/none SchedulerParameters=permit_job_expansion ``` + [https://slurm.schedmd.com/gres.conf.html](https://slurm.schedmd.com/gres.conf.html) では、HyperPod は `NodeName` GPU ノードを管理します。 # Slurm ログのローテーション SageMaker HyperPod は、Slurm デーモンログの自動ログローテーションを提供し、ディスク容量の使用状況を管理し、システムパフォーマンスを維持します。ログのローテーションは、ログが過剰なディスク容量を消費するのを防ぎ、最新のログ情報を維持しながら古いログファイルを自動的にアーカイブおよび削除することで、最適なシステムオペレーションを確保するために不可欠です。Slurm ログのローテーションは、クラスターの作成時にデフォルトで有効になっています。 ## ログローテーションの仕組み 有効にすると、ログローテーション設定は次のようになります。 + コントローラー、ログインノード、コンピューティングノードの `/var/log/slurm/`フォルダ`.log`にある 拡張子を持つすべての Slurm ログファイルをモニタリングします。 + 50 MB のサイズに達したときにログをローテーションします。 + 削除する前に、最大 2 つのローテーションされたログファイルを維持します。 + ローテーション`slurmdbd`後に Slurm デーモン (`slurmctld`、`slurmd`、) に SIGUSR2 シグナルを送信します。 ## ローテーションされたログファイルのリスト Slurm ログは `/var/log/slurm/` ディレクトリにあります。ログローテーションは、 に一致するすべてのファイルに対して有効になります`/var/log/slurm/*.log`。ローテーションが発生すると、ローテーションされたファイルには数値サフィックス ( など`slurmd.log.1`) があります。次のリストはすべてを網羅しているわけではありませんが、自動的にローテーションする重要なログファイルの一部を示しています。 + `/var/log/slurm/slurmctld.log` + `/var/log/slurm/slurmd.log` + `/var/log/slurm/slurmdb.log` + `/var/log/slurm/slurmrestd.log` ## ログローテーションを有効または無効にする 次の例に示すように、クラスターのライフサイクル`config.py`スクリプトのスクリプトで `enable_slurm_log_rotation`パラメータを使用してログローテーション機能を制御できます。 ``` class Config: # Set false if you want to disable log rotation of Slurm daemon logs enable_slurm_log_rotation = True # Default value ``` ログのローテーションを無効にするには、次の例に示すように`False`、 パラメータを に設定します。 ``` enable_slurm_log_rotation = False ``` **注記** ライフサイクルスクリプトは、クラスターの作成中にすべての Slurm ノード (コントローラー、ログイン、コンピューティングノード) で実行されます。また、クラスターに追加されると、新しいノードでも実行されます。ログローテーション設定の更新は、クラスターの作成後に手動で行う必要があります。ログローテーション設定は に保存されます`/etc/logrotate.d/sagemaker-hyperpod-slurm`。ログファイルが過剰なディスク容量を消費しないように、ログローテーションを有効にしておくことをお勧めします。ログのローテーションを無効にするには、`sagemaker-hyperpod-slurm`ファイルを削除するか、`sagemaker-hyperpod-slurm`ファイル内の各行の先頭`#`に を追加してその内容をコメントアウトします。 ## デフォルトのログローテーション設定 次の設定は、ローテーションされるログファイルごとに自動的に設定されます。 | 設定 | 値 | 説明 | | --- | --- | --- | | rotate | 2 | 保持するローテーションされたログファイルの数 | | size | 50MB | ローテーション前の最大サイズ | | copytruncate | 有効 | 元のログファイルをコピーして切り捨てます。 | | compress | 無効 | ローテーションされたログは圧縮されません | | missingok | 有効 | ログファイルがない場合、エラーは発生しません | | notifempty | 有効 | 空のファイルはローテーションしません | | noolddir | 有効 | ローテーションされたファイルは同じディレクトリに保持されます | # Amazon FSx for Lustre および Amazon FSx for OpenZFS を HyperPod クラスターにマウントする Amazon FSx for Lustre 共有ファイルシステムを HyperPod クラスターにマウントするには、以下を設定します。 1. Amazon VPC を使用します。 1. HyperPod クラスターインスタンスが VPC 内で通信可能にするため、必ず [カスタム Amazon VPC で SageMaker HyperPod を設定する](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-optional-vpc) を SageMaker HyperPod の IAM ロールにアタッチしてください。 1. `create_cluster.json` に、以下の VPC 情報を含めます。 ``` "VpcConfig": { "SecurityGroupIds": [ "string" ], "Subnets": [ "string" ] } ``` Amazon VPC の設定に関するその他のヒントについては、「[SageMaker HyperPod を使用するための前提条件](sagemaker-hyperpod-prerequisites.md)」を参照してください。 1. Amazon FSx for Lustre で Slurm の設定を完了するには、次のいずれかの方法を使用できます。Amazon FSx 情報は、アカウントの Amazon FSx for Lustre コンソールから、または次の AWS CLI コマンド を実行して確認できます`aws fsx describe-file-systems`。 **オプション A: API 駆動型設定 (推奨)** 各インスタンスグループ`InstanceStorageConfigs`内で を使用して、CreateCluster API ペイロードで Amazon FSx 設定を直接指定します。 CreateCluster このアプローチは、FSx for Lustre と FSx for OpenZFS の両方をサポートし、per-instance-group FSx 設定を許可します。 ``` "InstanceStorageConfigs": [ { "FsxLustreConfig": { "DnsName": "fs-12345678a90b01cde.fsx.us-west-2.amazonaws.com", "MountPath": "/fsx", "MountName": "1abcdefg" } } ] ``` FSx for OpenZFS の場合は、`FsxOpenZfsConfig`代わりに を使用します。 ``` "InstanceStorageConfigs": [ { "FsxOpenZfsConfig": { "DnsName": "fs-12345678a90b01cde.fsx.us-west-2.amazonaws.com", "MountPath": "/fsx-openzfs" } } ] ``` 詳細については、「 [CLI を使用した SageMaker HyperPod AWS の開始方法](sagemaker-hyperpod-quickstart.md)」を参照してください。 **オプション B: レガシー設定** [HyperPod が提供する基本ライフサイクルスクリプト](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) セクションの図`provisioning_parameters.json`に示すように、 で Amazon FSx DNS 名と Amazon FSx マウント名を指定します。 ``` "fsx_dns_name": "fs-12345678a90b01cde.fsx.us-west-2.amazonaws.com", "fsx_mountname": "1abcdefg" ``` # HyperPod での Slurm クラスター作成前の JSON 設定ファイルの検証 クラスター作成リクエストを送信する前に JSON 設定ファイルを検証するには、設定検証スクリプト [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/validate-config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/validate-config.py) を使用します。このスクリプトは、HyperPod クラスター設定 JSON ファイルと Slurm 設定 JSON ファイルを解析して比較し、2 つのファイル間、および Amazon EC2、Amazon VPC、Amazon FSx リソース間でリソースの設定ミスがあるかどうかを特定します。例えば、「[HyperPod が提供する基本ライフサイクルスクリプト](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md)」セクションから `create_cluster.json`および `provisioning_parameters.json` ファイルを検証するには、次のように検証スクリプトを実行します。 ``` python3 validate-config.py --cluster-config create_cluster.json --provisioning-parameters provisioning_parameters.json ``` 以下に、検証に成功した出力の例を示します。 ``` ✔️ Validated instance group name worker-group-1 is correct ... ✔️ Validated subnet subnet-012345abcdef67890 ... ✔️ Validated security group sg-012345abcdef67890 ingress rules ... ✔️ Validated security group sg-012345abcdef67890 egress rules ... ✔️ Validated FSx Lustre DNS name fs-012345abcdef67890.fsx.us-east-1.amazonaws.com ✔️ Validated FSx Lustre mount name abcdefgh ✅ Cluster Validation succeeded ``` # HyperPod Slurm クラスターでの本番稼働ワークロード実行前のランタイム検証 HyperPod 上の Slurm クラスターで本番稼働用ワークロードを実行する前にランタイムを確認するには、ランタイム検証スクリプト [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/hyperpod-precheck.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/hyperpod-precheck.py) を使用します。このスクリプトは、Slurm クラスターに Docker を実行するためのすべてのパッケージがインストールされているかどうか、適切にマウントされた FSx for Lustre ファイルシステムと、ファイルシステムを共有するユーザーディレクトリがクラスターにあるかどうか、および Slurm デーモンがすべてのコンピューティングノードで実行されているかどうかを確認します。 スクリプトを複数のノードで一度に実行するには、次の 8 つのノードの Slurm クラスターでスクリプトを実行するコマンド例に示すように `srun` を使用します。 ``` # The following command runs on 8 nodes srun -N 8 python3 hyperpod-precheck.py ``` **注記** スクリプトが提供するランタイム検証関数や、検証に合格しない問題を解決するためのガイドラインなど、検証スクリプトの詳細については、*Awsome Distributed Training GitHub リポジトリ*の「[Runtime validation before running workloads](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod#35-runtime-validation-before-running-workloads)」を参照してください。 # HyperPod クラスターノードでのライフサイクルスクリプトのインタラクティブ開発 このセクションでは、HyperPod クラスターを繰り返し作成および削除することなく、ライフサイクルスクリプトをインタラクティブに開発する方法について説明します。 1. 基本ライフサイクルスクリプトを使用して HyperPod クラスターを作成します。 1. クラスターノードにログインします。 1. ノードでスクリプト (`configure_xyz.sh`) を編集して繰り返し実行し、スクリプトを開発します。 1. HyperPod はライフサイクルスクリプトをルートユーザーとして実行するため、開発中は `configure_xyz.sh` をルートユーザーとして実行し、HyperPod により実行されている間にスクリプトが同じ条件でテストされることを確認することをお勧めします。 1. 次のようなコード行を追加して、スクリプトを `lifecycle_script.py` に統合します。 ``` ExecuteBashScript("./utils/configure_xyz.sh").run() ``` 1. 更新されたライフサイクルスクリプトを、基本ライフサイクルスクリプトのアップロードに最初に使用した S3 バケットにアップロードします。 1. 新しい HyperPod クラスターを作成して、`lifecycle_script.py` の統合バージョンをテストします。手動インスタンス置換を使用して、新しいインスタンスを作成することで、更新されたライフサイクルスクリプトをテストすることもできます。詳細な手順については、[「ノードを手動で置き換える](https://docs.aws.amazon.com//sagemaker/latest/dg/sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance.html#sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance-replace)」を参照してください。ワーカーノードのみが置き換え可能であることに注意してください。