[アップデート] Amazon SageMaker Hyperpod の Slurm オーケストレータがマルチヘッドノードをサポートしたため概要をまとめてみた
こんにちは!クラウド事業本部コンサルティング部のたかくに(@takakuni_)です。
Amazon SageMaker Hyperpod の Slurm オーケストレータがマルチヘッドノードをサポートしました。
Slurm
まず初めに Slurm はLinux OS 向けのオープンソースのジョブ管理システムです。
クラスター内に、 Controller daemon, Compute node daemon といった役割のノードを構え、ジョブ管理を行います。
SageMaker HyperPod の世界では、 Controller daemon を起動するノードをヘッドノード(やコントローラーノード)、Compute node daemon を起動するノードをワーカーノード(やコンピュートノード)と言い分けています。
ヘッドノードの冗長化
ヘッドノードは、ワーカーノードにジョブを割り当てるジョブ管理や、slurm コマンドの受け口などを担当し、クラスター全体の管理と制御を行っています
SageMaker HyperPod Workshop より引用
ご覧の通り、ヘッドノードはクラスター内において重要な役割であることがわかります。そのため、以下の図のように冗長化構成を Slurm ではサポートしています。
アップデート内容
Amazon SageMaker HyperPod の Slurm オーケストレータでは、今回のアップデートまでヘッドノードの冗長化をサポートしていませんでした。
今回のアップデートは「マルチヘッドノードをサポートし冗長化可能になりました」というものです。非常に素晴らしいですね。
この課題のみを焦点とした解決方法は、以前までだと AWS Parallel Computing Service の利用が考えられました。
構成図
マルチヘッドノードのための構成を見てみましょう。
ポイントは冗長化に必要なリソースをユーザー側で管理する必要があります。
ちなみに、各リソースは以下を担当するようです。
- Amazon RDS for MariaDB
- Slurm のアカウンティングデータ(実行履歴)を保管
- AWS Secrets Manager
- MariaDB へアクセスするためのクレデンシャルを保管
- Amazon FSx for Lustre
- Slurm の設定ファイルと現在の状態を保存
- Amazon SNS
- プライマリコントローラ(ヘッド)ノードに関連するステータスの変更があった場合の通知
デプロイ方法
冗長化に必要なデプロイを確認してみます。
基本的には以下の CloudFormation を利用しデプロイします。この CloudFormation を見ると、 Amazon FSx for Lustre に関しては、データセットで利用するものと共用して良いようです。
注意事項
最後に注意事項を確認します。
とくに以下の内容が重要で、 ヘッドノードの更新を行う場合は、controller_group で利用していたグループを worker_groups に移動し、新たに controller_group を立て直す必要があります。
Follow the instructions in Preparing and uploading lifecycle scripts to upload the updated lifecycle scripts. When updating the provisioning_parameters.json file, move your existing controller group to the worker_groups section, and add a new controller group name in the controller_group section.
先日のアップデートでインスタンスグループを削除できるようになったため、不要になった旧ヘッドノードは削除で良さそうです。
まとめ
以上、「Amazon SageMaker Hyperpod の Slurm オーケストレータがマルチヘッドノードをサポートしたため概要をまとめてみた」でした。
冗長構成もサポートされたことで、Slurm オーケストレータとして、必要な機能はかなり揃ってきた印象を受けました。
機会があれば実際にデプロイを試してみたいと思いました。
このブログがどなたかの参考になれば幸いです。クラウド事業本部コンサルティング部のたかくに(@takakuni_)でした!