AWS ParallelCluster ヘッドノードのインスタンスタイプをマネジメントコンソールから変更した後に update-cluster を実行するとどうなるのか確認した

2022.05.20

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS ParallelCluster のヘッドノードのインスタンスタイプの変更は正規の更新方法(pcluster update-cluster)では許可されていません。とは言えどヘッドノードは EC2インスタンスですのでマネジメントコンソール、AWS CLI を利用して AWS ParallelCluster の管理(クラスターのコンフィグ)外から変更操作はできます。

仮にヘッドノードのインスタンスタイプをマネジメントコンソールから変更したあとに更新可能なパラメータを正規の方法で変更かけようすると、ヘッドノードのインスタンスタイプ変更による差分を検知して更新は失敗するのでしょうか?

素朴な疑問を解決するべく試してみました。

確認結果

  • ヘッドノードのインスタンスタイプを手動で変更してもpcluseter update-clusterコマンドで更新はできる
    • 変更するパラメータによっては更新に失敗する可能性はあります
  • アップデートポリシーで許可されていないパラメータを変更しているため、不具合があったり、サポートも受けられない可能性は高い

ヘッドノードのインスタンスタイプについて

AWS ParallelCluster のクラスターを作成後、大きく分けると変更できるパラメータと、変更できないパラメータが存在します。詳細なアップデートポリシーの定義は以下のリンクをご参照ください。

Using pcluster update-cluster - AWS ParallelCluster

HeadNodeセクションのInstanceTypeについては変更不可なアップデートポリシーと説明されています。

Update policy: If this setting is changed, the update is not allowed.

HeadNode section - AWS ParallelCluster

pcluster update-clusterコマンドではインスタンスタイプを変更できないことが確認できました。インスタンスタイプの変更により、intel から arm へ CPU アーキテクチャも変更できてしまうため、ヘッドノード単体の問題では済まなくなり影響が大きいことから許可されないのも納得できます。

ヘッドノードのインスタンスタイプ変更

マネジメントコンソールからヘッドノードのインスタンスタイプを変更します。

作成したクラスターのヘッドノードのインスタンスタイプは t3.micro です。

マネジメントコンソールからインスタンスタイプをc6i.largeへ変更しました。ぽちぽち押すだけでスペックを簡単に変更できるのは本当に便利ですよね。

クラスターコンフィグのInstanceTypeで指定した値と実際のリソースに差分が生まれました。

クラスターコンフィグ抜粋

HeadNode:
  InstanceType: t3.micro
  Networking:
    ElasticIp: false
    SubnetId: subnet-035be95eeaa091603

動作確認

コンピュートノードを制御しているのはヘッドノードですので機能するのかジョブを登録してみます。

テスト用のスクリプトを用意しました。

test.sh

#! /bin/bash

#SBATCH -p cpu-spot
#SBATCH -N 1

hostname

ジョブを投げてみました。このあとコンピュートノードを呼び出せるのかが問題です。

$ sbatch test.sh
Submitted batch job 9

$ squeue
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
                 9  cpu-spot  test.sh   ubuntu CF       0:05      1 cpu-spot-dy-large-1

コンピュートノードはいつもどおり起動してきました。

ヘッドノードのインスタンスタイプを変更しても動作しているように思えます。

コンフィグ変更

クラスターのコンフィグを変更してpclsuter update-clusterでクラスターに更新をかけてみます。

更新するパラメータはコンピュートノードの最大起動数を変更してみます。現在は 10台起動できる cpu-spot を 20台まで起動できるようにします。

$ sinfo
PARTITION     AVAIL  TIMELIMIT  NODES  STATE NODELIST
cpu-spot*        up   infinite     10  idle~ cpu-spot-dy-large-[1-10]
high-cpu-spot    up   infinite     10  idle~ high-cpu-spot-dy-large16x-[1-10]

MaxCountを20にしました。

クラスターコンフィグ抜粋

  SlurmQueues:
    # --- Queue 1 ---
    - Name: cpu-spot
      ComputeResources:
        - Name: large
          InstanceType: c6i.large
          MinCount: 0
          MaxCount: 20
          DisableSimultaneousMultithreading: true

クラスターの停止

クラスターの設定変更する前に一度クラスターの停止のステータスにする必要があります。ヘッドノードを停止すれば OK というわけではないです。

まず作成したクラスター名を確認しないとコマンド打てないため、pcluster list-clustersでサッと確認すると早いです。クラスターが複数台あるときは対象を誤らないように注意してください。

> pcluster list-clusters
{
  "clusters": [
    {
      "clusterName": "DockerOnParallelcluster",
      "cloudformationStackStatus": "UPDATE_COMPLETE",
      "cloudformationStackArn": "arn:aws:cloudformation:ap-northeast-1:123456789012:stack/DockerOnParallelcluster/59b85490-c3a7-11ec-b7c8-0e8a0cc9f27b",
      "region": "ap-northeast-1",
      "version": "3.1.3",
      "clusterStatus": "UPDATE_COMPLETE"
    }
  ]
}

この先、クラスター名は頻出するため変数に入れておきます。

CLUSTER_NAME=DockerOnParallelcluster

クラスター停止コマンドを打ちます。

pcluster update-compute-fleet --cluster-name ${CLUSTER_NAME} \
                              --status STOP_REQUESTED

実行結果

{
  "status": "STOP_REQUESTED",
  "lastStatusUpdatedTime": "2022-05-20T08:55:13.516Z"
}

クラスターのアップデート

最大起動数を20台に変更したコンフィグを引数にpclsuter update-clusterコマンドを実行します。

pcluster update-cluster --cluster-name ${CLUSTER_NAME} \
                        --cluster-configuration sample-docker-on-parallelcluster.yml

ParallelCluster のクラスターは CDK で管理されています。チェンジセットの結果が返ってきました。

【アップデート】CloudFormationに事前にリソースがどう変更されるのかを確認できる「Change Sets」が追加されました! | DevelopersIO

実行結果

{
  "cluster": {
    "clusterName": "DockerOnParallelcluster",
    "cloudformationStackStatus": "UPDATE_IN_PROGRESS",
    "cloudformationStackArn": "arn:aws:cloudformation:ap-northeast-1:123456789012:stack/DockerOnParallelcluster/59b85490-c3a7-11ec-b7c8-0e8a0cc9f27b",
    "region": "ap-northeast-1",
    "version": "3.1.3",
    "clusterStatus": "UPDATE_IN_PROGRESS"
  },
  "changeSet": [
    {
      "parameter": "Scheduling.SlurmQueues[cpu-spot].ComputeResources[large].MaxCount",
      "requestedValue": 20,
      "currentValue": 10
    }
  ]
}

ドリフトがあり、ヘッドノードのインスタンスタイプに差分がありますという結果を期待してのですがUPDATE_IN_PROGRESSということで更新がかかっています。

CloudFormation のスタックを直接確認してみると更新中ですね。そもそものお話だったのですが差分があるのかのチェックは走っていませんでした。

そして、正常に更新が終わりました。

クラスターの開始

最大起動台数は20台になったのか確認するためクラスターを再開させます。

pcluster update-compute-fleet --cluster-name ${CLUSTER_NAME} \
                              --status START_REQUESTED

実行結果

{
  "status": "START_REQUESTED",
  "lastStatusUpdatedTime": "2022-05-20T09:11:12.321Z"
}

ヘッドノードから状態確認

cpu-spotの最大起動台数が20台になっていますね。更新成功です。

$ sinfo
PARTITION     AVAIL  TIMELIMIT  NODES  STATE NODELIST
cpu-spot*        up   infinite     20  idle~ cpu-spot-dy-large-[1-20]
high-cpu-spot    up   infinite     10  idle~ high-cpu-spot-dy-large16x-[1-10]

意外と成功しました。

ドリフトは検出されるのか?

ヘッドノードのドリフトは検出されるのか確認してみます。

ちゃんと検出されました。

と思ったのですが、インスタンスタイプのではなくタグが違うという差分でした。となると、インスタンスタイプを変更しなくても差分は検出されるのではないかという新しい疑問が生まれました。 今回はヘッドノードのインスタンスタイプを外部から変更したあとにpcluster update-clusterを実行したらどうなるのかという疑問を解消するための検証でしたので、別の機会に確認したいと思います。

まとめ

ヘッドノードのインスタンスタイプをマネジメントコンソールから変更した状態で、pcluster update-clusterを実行しても差分を検知せず更新可能であった。

  • クラスターの更新時にドリフトのチェックは走らない
  • pcluster update-clusterで更新した箇所が手動変更している部分だと当然エラーになり更新失敗する可能性がある

おわりに

ヘッドノードのインスタンスタイプは一体どこで管理されているのか謎が深まってしまいました。CloudFormation のテンプレート内にはt3.microの記述はあるため、時間あるときに ParallelClusetr の裏側を探ってみます。