AWS ParallelCluster 既存クラスターの設定を変更する手順 – fish シェル編

私が「本当に必要だったもの」はfishユーザーがコピペ済むチートシートです。

大村保貴

2024.02.11

AWS ParallelCluster で作成済みのクラスターに対して、クラスターのコンフィグを変更して設定反映させるための作業手順を紹介します。

以前 bash 向けの手順を作成したものを fish ユーザー向けにブラッシュアップしました。

既存クラスターの設定反映手順まとめ

変更対象の既存のクラスター名を確認します。

pcluster list-clusters | jq -r '.clusters[] | [.clusterName,.version,.region] | @tsv'

確認したクラスター名と、設定変更したコンフィグファイルを変数に入れます。

set CLUSTER_NAME [Target Cluster name]
set CONFIG_NAME [Your config file]

コンピュートフリートを停止します。STOPPEDの表示を確認できれば正常です。

pcluster update-compute-fleet --cluster-name $CLUSTER_NAME --status STOP_REQUESTED
while true
    pcluster describe-cluster --cluster-name $CLUSTER_NAME | jq -r .computeFleetStatus
    sleep 3
end

既存クラスターへ設定を反映する前にドライランを実行してコンフィグをチェックします。Request would have succeeded, but DryRun flag is set.確認できれば正常です。

pcluster update-cluster --cluster-name $CLUSTER_NAME \
                        --cluster-configuration $CONFIG_NAME \
                        --dryrun true

既存クラスターに設定を反映させます。UPDATE_COMPLETEの表示を確認できれば正常です。

pcluster update-cluster --cluster-name $CLUSTER_NAME \
                        --cluster-configuration $CONFIG_NAME
while true
    pcluster describe-cluster --cluster-name $CLUSTER_NAME | jq -r .clusterStatus
    sleep 3
end

コンピュートフリートを開始します。RUNNINGの表示を確認できれば正常です。

pcluster update-compute-fleet --cluster-name $CLUSTER_NAME --status START_REQUESTED
while true
    pcluster describe-cluster --cluster-name $CLUSTER_NAME | jq -r .computeFleetStatus
    sleep 3
end

以上で作業完了です。

実際に試したときの作業記録

実際に既存クラスターの設定を変更したときのコマンドの実行ログを参考までに紹介します。

実行環境

pclsuterコマンドの実行環境は Docker コンテナで用意したものを利用しています。

変更内容

コンピュートノードのパーティションqueue1の最大起動ノード数を 20 台から 50 台へ変更します。

    # ------ Compute 1 ------
    - Name: queue1
      ComputeResources:
        - Name: queue1
          Instances:
            - InstanceType: m7i.8xlarge
            - InstanceType: m7a.4xlarge
          MinCount: 0
          MaxCount: 50

重要なこと

既存クラスターの設定値は変更可能なものと、変更不可なものがあります。また変更可能あっても変更には条件があるものもあります。事前に対象の設定綱目のUpdate policyを確認しましょう。

今回変更するMaxCountはコンピュートフリートが停止状態であれば変更可能と記載があります。

Scheduling section - AWS ParallelCluster

クラスター名確認

クラスター名の一覧を出力しました。v380の名前で作成されている既存のクラスターの設定を変更します。

# pcluster list-clusters | jq -r '.clusters[] | [.clusterName,.version,.region] | @tsv'
v380    3.8.0   ap-northeast-1

環境変数に登録

確認したクラスター名と、クラスターのコンフィグファイル名を環境変数に入れます。

# set CLUSTER_NAME v380
# set CONFIG_NAME v380released.yaml

コンピュートフリートの停止

停止コマンドを実行して約 40 秒後にコンピュートフリートはSTOPPEDの状態になりました。

# pcluster update-compute-fleet --cluster-name $CLUSTER_NAME --status STOP_REQUESTED
    while true
        pcluster describe-cluster --cluster-name $CLUSTER_NAME | jq -r .computeFleetStatus
        sleep 3
    end
{
  "status": "STOP_REQUESTED",
  "lastStatusUpdatedTime": "2024-02-11T03:13:53.844Z"
}
STOP_REQUESTED
STOP_REQUESTED
STOP_REQUESTED
STOP_REQUESTED
STOP_REQUESTED
STOP_REQUESTED
STOP_REQUESTED
STOP_REQUESTED
STOP_REQUESTED
STOP_REQUESTED
STOP_REQUESTED
STOPPING
STOPPING
STOPPED
STOPPED

ドライラン実行

クラスターのコンフィグチェックのために一度ドライランを実行します。Request would have succeeded, but DryRun flag is set.確認できれば基本問題ありません。

バリデーションのメッセージでマルチ AZ 起動時は AZ 跨ぎのデータ転送料に留意しなさいとご丁寧に教えてくれました。また、設定変更箇所であるqueue1のMaxCount数の変更前と、変更後の値が表示されています。

# pcluster update-cluster --cluster-name $CLUSTER_NAME \
                          --cluster-configuration $CONFIG_NAME \
                          --dryrun true

{
  "validationMessages": [
    {
      "level": "INFO",
      "type": "MultiAzRootVolumeValidator",
      "message": "Your configuration for Queues 'queue1, test1' includes multiple subnets different from where HeadNode is located. Accessing a shared storage from different AZs can lead to increased storage network latency and inter-AZ data transfer costs."
    }
  ],
  "message": "Request would have succeeded, but DryRun flag is set.",
  "changeSet": [
    {
      "parameter": "Scheduling.SlurmQueues[queue1].ComputeResources[queue1].MaxCount",
      "requestedValue": 50,
      "currentValue": 20
    }
  ]
}`

既存クラスターへコンフィグを反映

クラスターのコンフィグを既存クラスターへ反映させます。アップデートコマンドを実行して約 50 秒後にクラスターの CloudFormation スタックはUPDATE_COMPLETEの状態になりました。

# pcluster update-cluster --cluster-name $CLUSTER_NAME \
                          --cluster-configuration $CONFIG_NAME
    while true
        pcluster describe-cluster --cluster-name $CLUSTER_NAME | jq -r .clusterStatus
        sleep 3
    end

{
  "cluster": {
    "clusterName": "v380",
    "cloudformationStackStatus": "UPDATE_IN_PROGRESS",
    "cloudformationStackArn": "arn:aws:cloudformation:ap-northeast-1:123456789012:stack/v380/eaecf760-a463-11ee-bfc6-06ad6f88204d",
    "region": "ap-northeast-1",
    "version": "3.8.0",
    "clusterStatus": "UPDATE_IN_PROGRESS",
    "scheduler": {
      "type": "slurm"
    }
  },
  "validationMessages": [
    {
      "level": "INFO",
      "type": "MultiAzRootVolumeValidator",
      "message": "Your configuration for Queues 'queue1, test1' includes multiple subnets different from where HeadNode is located. Accessing a shared storage from different AZs can lead to increased storage network latency and inter-AZ data transfer costs."
    }
  ],
  "changeSet": [
    {
      "parameter": "Scheduling.SlurmQueues[queue1].ComputeResources[queue1].MaxCount",
      "requestedValue": 50,
      "currentValue": 20
    }
  ]
}
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_COMPLETE
UPDATE_COMPLETE

コンピュートフリートの開始（再開）

開始コマンドを実行して約 15 秒後にコンピュートフリートはRUNNINGの状態になりました。

# pcluster update-compute-fleet --cluster-name $CLUSTER_NAME --status START_REQUESTED
    while true
        pcluster describe-cluster --cluster-name $CLUSTER_NAME | jq -r .computeFleetStatus
        sleep 3
    end
{
  "status": "START_REQUESTED",
  "lastStatusUpdatedTime": "2024-02-11T03:24:44.683Z"
}
START_REQUESTED
START_REQUESTED
STARTING
STARTING
RUNNING
RUNNING

変更変更箇所の確認

ヘッドノードにログインしてパーティションの設定を確認しました。

設定を変更前に確認したパーティションの様子です。queue1は 20 ノードまでと表示されています。

# Before
$ sinfo
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
test1*    inact   infinite     10  idle~ test1-dy-test1-[1-10]
queue1    inact   infinite     20  idle~ queue1-dy-queue1-[1-20]

設定変更後に確認したパーティションの様子です。50 ノードと表示されています。

# After
$ sinfo
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
test1*       up   infinite     10  idle~ test1-dy-test1-[1-10]
queue1       up   infinite     50  idle~ queue1-dy-queue1-[1-50]

queue1パーティションの最大起動台数の変更に成功しました。

おわりに

最近クラスターの設定変更する機会が多く、fish ユーザーの身としては以前作成した手順が使いづらかったこともあり、fish 向けに書き直しました。以前作成した bash での変更手順の方をお客様へ案内する機会は多いと思うのですが、fish 使ってるお客様がいたら同様にプログを案内して済む様に作成しました。

また、実際に私が運用していると--dryrun trueのオプションを頻繁に--dry-run trueと誤った書き方してエラーになることが多かったのでドライランコマンドも手順に盛り込みました。多少改善が図られています。

参考

AWS ParallelCluster クラスター作成時のトラブルシューティング基礎知識 | DevelopersIO

AWS ParallelCluster 既存クラスターの設定を変更する手順 – fish シェル編

既存クラスターの設定反映手順まとめ

実際に試したときの作業記録

実行環境

変更内容

重要なこと

クラスター名確認

環境変数に登録

コンピュートフリートの停止

ドライラン実行

既存クラスターへコンフィグを反映

コンピュートフリートの開始（再開）

変更変更箇所の確認

おわりに

参考

イベント

EVENT【6/5（水）】QuickSightとTableauのデモで営業分析を解説！アクションに繋げるダッシュボード設計

EVENT【5/29（水）大阪】Alteryxの使い方から導入メリットまですべてがわかるセミナー＆ワークショップ

EVENT【5/15（水）リモート】クラスメソッドの会社説明会を開催します

EVENT【5/8リモート】クラスメソッドのフリーランスエンジニア会社説明会〜フィンテック / リテール業界案件特集〜を開催します

EVENT【5/28（火）】AWSを最大活用するための1dayカンファレンス

EVENT【5/17（金）】認証機能の開発工数削減をデモで体験！次世代認証基盤サービス『Auth0 by Okta』導入実践ウェビナー

EVENT【5/14（火）】アノテーションの中途向けオンライン会社説明会を開催します

EVENT【5/23（木）】ユースケースに学ぶAWS運用のノウハウ～可視化から統制まで～

EVENT【5/16（木）】Snowflakeを触ってみよう！初めての方向けハンズオンセミナー

EVENT【5/10（金）名古屋】クラスメソッドグループの会社説明会を開催します！

AWS ParallelCluster 既存クラスターの設定を変更する手順 – fish シェル編

既存クラスターの設定反映手順まとめ

実際に試したときの作業記録

実行環境

変更内容

重要なこと

クラスター名確認

環境変数に登録

コンピュートフリートの停止

ドライラン実行

既存クラスターへコンフィグを反映

コンピュートフリートの開始（再開）

変更変更箇所の確認

おわりに

参考

イベント

EVENT【6/5（水）】QuickSightとTableauのデモで営業分析を解説！アクションに繋げるダッシュボード設計

EVENT【5/29（水）大阪】Alteryxの使い方から導入メリットまですべてがわかるセミナー＆ワークショップ

EVENT【5/15（水）リモート】クラスメソッドの会社説明会を開催します

EVENT【5/8リモート】クラスメソッドのフリーランスエンジニア会社説明会 〜フィンテック / リテール 業界案件特集〜 を開催します

EVENT【5/28（火）】AWSを最大活用するための1dayカンファレンス

EVENT【5/17（金）】認証機能の開発工数削減をデモで体験！次世代認証基盤サービス『Auth0 by Okta』導入実践ウェビナー

EVENT【5/14（火）】アノテーションの中途向けオンライン会社説明会を開催します

EVENT【5/23（木）】ユースケースに学ぶAWS運用のノウハウ～可視化から統制まで～

EVENT【5/16（木）】Snowflakeを触ってみよう！初めての方向けハンズオンセミナー

EVENT【5/10（金） 名古屋】クラスメソッドグループの会社説明会を開催します！

関連記事

AWS ParallelCluster Ubuntu 22.04 で Mountpoint for Amazon S3 を使ってヘッドノードとコンピュートノードに S3 バケットを自動マウントする方法

AWS ParallelCluster OnNodeConfigured セクションの Args を変更してもクラスターの更新をかけられないときに検討したこと

AWS ParallelCluster で Apptainer と Mountpoint for Amazon S3 の組み合わせて Trinity を実行してみた

AWS ParallelCluster で Apptainer を利用して Trinity を実行してみた

EVENT【5/8リモート】クラスメソッドのフリーランスエンジニア会社説明会〜フィンテック / リテール業界案件特集〜を開催します

EVENT【5/10（金）名古屋】クラスメソッドグループの会社説明会を開催します！