AWS ParallelCluster 3 に Slurm のジョブ実行履歴を保存する Aurora Serverless v1 を連携してみた

AWS ParallelCluster 3 に Slurm のジョブ実行履歴を保存する Aurora Serverless v1 を連携してみた

AWS ParallelCluster 3 ならどうするの?設定方法を紹介します。
Clock Icon2022.05.29

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

AWS ParallelCluster 3 に Slurm のジョブ実行履歴を保存するデータベースとして Aurora Serverless v1 を構築し、ParallelClusterからの接続・設定方法を紹介します。

AWS ParallelCluster 2 のときは以下のブログで紹介していました。

検証環境

項目
ParallelCluster 3.1.4
Slurm(sinfo -V) 21.08.8-2
OS Ubuntu 20.04 LTS
CPU Intel
DB Engine Aurora MySQL 5.7互換

Aurora Serverless v1 を採用

2022年4月に Aurora Serverless v2 がリリースされました。Slurm 用のデータベースとして処理性能を必要していないことと、クラウド HPC としては計算時のみしかデータベースは必要としないため、自動停止可能(0 ACU までの縮退)な v1 を引き続き採用しました。データベース停止からコールドスタートを許容してランニングコストと運用管理の手間を削減することを優先とします。

Aurora Serverless v1 の準備

Slurm用のデータベースは MySQLか、MariaDBが必要です。Aurora MySQL 5.7互換の Aurora Serverless v1 を以下のテンプレートから作成しました。

AWSTemplateFormatVersion: "2010-09-09"
Description: Aurora Serverless v1 MySQL

Metadata:
  AWS::CloudFormation::Interface:
    ParameterGroups:
      - Label:
          default: Common Settings
        Parameters:
          - ProjectName
          - Environment
      - Label:
          default: VPC Settings
        Parameters:
          - VpcId
          - VpcRdsSubnetId1
          - VpcRdsSubnetId2
          - VpcHeadNodeSubnet

Parameters:
  ProjectName:
    Description: Project Name
    Type: String
    Default: unnamed
  Environment:
    Description: Environment
    Type: String
    Default: dev
    AllowedValues:
      - prod
      - dev
      - stg
  VpcId:
    Description: VPC ID
    Type: AWS::EC2::VPC::Id
  VpcRdsSubnetId1:
    Description: RDS VPC subnet 1
    Type: AWS::EC2::Subnet::Id
  VpcRdsSubnetId2:
    Description: RDS VPC subnet 2
    Type: AWS::EC2::Subnet::Id
  VpcHeadNodeSubnet:
    Description: HeadNode VPC subnet
    Type: String
    Default: 10.0.0.0/16
  DBClusterIdentifier:
    Description: DBClusterIdentifier
    Type: String
    Default: slurmdb
    AllowedPattern: ^[a-zA-Z0-9]*$
    MinLength: 1
    MaxLength: 60
  DBMasterUsername:
    Description: DBMasterUsername
    Type: String
    Default: admin
  DBMasterUserPassword:
    Description: DBMasterUserPassword
    Type: String
    Default: password
    NoEcho: true

Resources:
  # --------------------------------------------------------
  # DB Subnet Group
  # --------------------------------------------------------
  DBSubnetGroup:
    Type: AWS::RDS::DBSubnetGroup
    Properties:
      DBSubnetGroupDescription: Database subnets for SlurmDB
      SubnetIds:
        - !Ref "VpcRdsSubnetId1"
        - !Ref "VpcRdsSubnetId2"
      Tags:
        - Key: Name
          Value: !Sub ${ProjectName}-${Environment}-db-subnet-group
        - Key: Env
          Value: !Ref Environment

  # --------------------------------------------------------
  # DB Cluster Parameter Group
  # --------------------------------------------------------
  DBClusterParameterGroup:
    Type: AWS::RDS::DBClusterParameterGroup
    Properties:
      Description: Aurora Serverless v1 Cluster Parameter Group
      Family: aurora-mysql5.7
      Parameters:
        time_zone: UTC
      Tags:
        - Key: Name
          Value: !Sub ${ProjectName}-${Environment}-db-cluster-param-group
        - Key: Env
          Value: !Ref Environment

  # --------------------------------------------------------
  # Aurora Serverless v1 Cluster
  # --------------------------------------------------------
  DBCluster:
    Type: AWS::RDS::DBCluster
    Properties:
      BackupRetentionPeriod: 7
      DBClusterIdentifier: !Ref "DBClusterIdentifier"
      DBClusterParameterGroupName: !Ref "DBClusterParameterGroup"
      DBSubnetGroupName: !Ref "DBSubnetGroup"
      DeletionProtection: false
      Engine: aurora-mysql
      EngineMode: serverless
      EngineVersion: "5.7.mysql_aurora.2.07.1"
      MasterUsername: !Ref "DBMasterUsername"
      MasterUserPassword: !Ref "DBMasterUserPassword"
      Port: 3306
      PreferredBackupWindow: 18:00-19:00
      PreferredMaintenanceWindow: Sat:16:00-Sat:17:00
      ScalingConfiguration:
        MinCapacity: 1
        AutoPause: true
        MaxCapacity: 2
        SecondsUntilAutoPause: 300
      StorageEncrypted: true
      Tags:
        - Key: Env
          Value: !Ref Environment
      VpcSecurityGroupIds:
        - !Ref "SecurityGroup1"

  # --------------------------------------------------------
  # Security Group
  # --------------------------------------------------------
  SecurityGroup1:
    Type: AWS::EC2::SecurityGroup
    Properties:
      VpcId: !Ref "VpcId"
      GroupDescription: Allow MySQL (TCP3306)
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 3306
          ToPort: 3306
          CidrIp: !Ref "VpcHeadNodeSubnet"
      Tags:
        - Key: Env
          Value: !Ref Environment

Outputs:
  RdsSecurityGroup:
    Value: !Ref "SecurityGroup1"
  DBClusterEndpoint:
    Value: !GetAtt "DBCluster.Endpoint.Address"

ParallelCluster の設定

以下のリンクを参考に設定をすすめます。

ヘッドノードの MySQL 設定

MySQLクライアントをインストールします。

sudo apt update
sudo apt install mysql-client -y

DB のホスト名(-h)・ユーザー名(-u admin)は環境に合わせて書き換えてください。

mysql -h slurmdb.cluster-cja2kmww8voi.ap-northeast-1.rds.amazonaws.com  -u admin -p

DB へ接続後、必要な権限を付与します。

mysql> GRANT ALL ON `%`.* TO admin@`%`;
Query OK, 0 rows affected (0.01 sec)
mysql> quit

ヘッドノードの Slurm 設定

Slurm の設定は新規作成する設定ファイルと、既存の設定ファイルの変更を行います。

slurmdbd.conf 新規作成

slurmdbd.serviceから起動する実行ファイルを作成します。冒頭の変数は環境に合わせてパラメータをセットしてください。作成したファイルのパーミッションと、オーナーを変更する必要があります。詳細はトラブルシュートの項を参照。

SLURMDB_USER="admin"
SLURMDB_PASS="password"
SLURMDB_ENDPOINT="slurmdb.cluster-cja2kmww8voi.ap-northeast-1.rds.amazonaws.com"

sudo tee /opt/slurm/etc/slurmdbd.conf << EOF
ArchiveEvents=no
ArchiveJobs=no
ArchiveResvs=no
ArchiveSteps=no
ArchiveSuspend=no
ArchiveTXN=no
ArchiveUsage=no
AuthType=auth/munge
DbdHost=localhost
DbdPort=6819
DebugLevel=info
SlurmUser=slurm
LogFile=/var/log/slurmdbd.log
PidFile=/var/run/slurmdbd.pid
StorageType=accounting_storage/mysql
StorageUser=$SLURMDB_USER
StoragePass=$SLURMDB_PASS
StorageHost=$SLURMDB_ENDPOINT
StoragePort=3306
EOF
sudo chmod 600 /opt/slurm/etc/slurmdbd.conf
sudo chown slurm. /opt/slurm/etc/slurmdbd.conf

Archiveの項目でジョブ履歴関係の保持期限を設定できます。すべて no を指定し一定期間後に履歴を自動的に破棄しない設定としました。

slurm.conf 追記

既存のslurm.confファイルに設定を追記します。

sudo tee -a /opt/slurm/etc/slurm.conf << EOF
# ACCOUNTING
JobAcctGatherType=jobacct_gather/linux
JobAcctGatherFrequency=30
AccountingStorageType=accounting_storage/slurmdbd
AccountingStorageHost=localhost
AccountingStorageUser=$SLURMDB_USER
AccountingStoragePort=6819
EOF

slurmdbd.service 新規作成

/opt/slurm/sbin/slurmdbdを実行しないと Aurora Serverless v1 と接続できないのですが、ヘッドノード停止/開始はめんどくさいのでサービス化します。

sudo tee /etc/systemd/system/slurmdbd.service << EOF
[Unit]
Description=slurmdbd
After=network.target
[Service]
Type=forking
User=root
ExecStart=/opt/slurm/sbin/slurmdbd
Restart = always
[Install]
WantedBy=multi-user.target
EOF

slumdbd.serviceを自動起動設定します。

sudo systemctl daemon-reload
sudo systemctl enable slurmdbd
sudo systemctl start slurmdbd
sudo systemctl status slurmdbd

slurmdbd.serviceが起動してはじめて Aurora Serverless v1 とコネクションがはられます。Aurora Serverless v1 が停止状態(0 ACU)ですと接続までに1分程度の時間がかかります。ここがコールドスタートを許容できるかの話になります。

クラスター名を DB へ登録

sacctmgrコマンドでクラスター名を DB に登録しましす。引数のadd cluster parallelclusterparallelclusterは、/opt/slurm/etc/slurm.confファイル内のClusterNameで指定されている名前に合わせる必要があります。ParallelCluster 構築時のデフォルト値はparallelclusterです。

sudo /opt/slurm/bin/sacctmgr add cluster parallelcluster
# CLUSTER SETTINGS
ClusterName=parallelcluster
SlurmUser=slurm
SlurmctldPort=6820-6829

ClusterNameを変更している場合や、複数のクラスターを同じ DB に接続する場合は、事前にClusterNameを修正し、sudo /opt/slurm/bin/sacctmgr add cluster hogeと入力してください。

クラスターの登録が完了するとparallelc+の表示を確認できます。10文字以降は見切れていますがクラスター名を確認できれば問題ありません。

/opt/slurm/bin/sacctmgr list cluster
   Cluster     ControlHost  ControlPort   RPC     Share GrpJobs       GrpTRES GrpSubmit MaxJobs       MaxTRES MaxSubmit     MaxWall                  QOS   Def QOS
---------- --------------- ------------ ----- --------- ------- ------------- --------- ------- ------------- --------- ----------- -------------------- ---------
parallelc+                            0     0         1                                                                                           normal

クラスター名を完全に確認したいときは以下のコマンドを入力してください。

/opt/slurm/bin/sacctmgr list cluster format=cluster%30
                       Cluster
------------------------------
               parallelcluster

slurmctld サービスの再起動

最後にslurmctldサービスを再起動して設定作業は完了です。このサービスを再起動し忘れるとジョブを登録して DB に記録されないです。「sacctコマンド打ってもジョブの履歴に追加されていかない、なせ?」となったらここを疑ってみてください。

sudo systemctl restart slurmctld

ジョブの登録と履歴表示

テストジョブを投げてsacctコマンドでジョブの実行履歴を確認できるか試します。今回のジョブIDは9です。

$ sbatch test.sh
Submitted batch job 9

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

$ sacct
JobID           JobName  Partition    Account  AllocCPUS      State ExitCode
------------ ---------- ---------- ---------- ---------- ---------- --------
9               test.sh      large                     1    RUNNING      0:0

しばらくすると状態がCOMPLETEDになりました。

$ sacct
JobID           JobName  Partition    Account  AllocCPUS      State ExitCode
------------ ---------- ---------- ---------- ---------- ---------- --------
9               test.sh      large                     1  COMPLETED      0:0
9.batch           batch                                1  COMPLETED      0:0

$ squeue
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)

ジョブを登録した時刻や、ジョブの実行時間など確認できます。ジョブの実行履歴として Aurora Serverless v1 が機能していることを確認できました。

$ sacct -o User,JobID,Partition,NNodes,Submit,Start,End,Elapsed,State -X
     User JobID         Partition   NNodes              Submit               Start                 End    Elapsed      State
--------- ------------ ---------- -------- ------------------- ------------------- ------------------- ---------- ----------
   ubuntu 9                 large        1 2022-05-29T03:40:51 2022-05-29T03:46:10 2022-05-29T03:49:11   00:03:01  COMPLETED

トラブルシュート

TIPS として検証中に遭遇したエラーと解決方法の記載します。

slurmdbd.conf のパーミッション

slurmdbd.serviceサービス化する前にコマンド単体のテストをしていました。

sudo /opt/slurm/sbin/slurmdbd

実行するとslurmdbd.confのパーミッションを指摘されました。AWS ParallelCluster 2 は問題なかったはずです。Slurm のバージョンも上がっていることからバージョンによるものかと思います。

slurmdbd: fatal: slurmdbd.conf file /opt/slurm/etc/slurmdbd.conf should be 600 is 644 accessible for group or others

パーミッションを修正した後にはオーナーがrootだと指摘されました。

slurmdbd: fatal: slurmdbd.conf not owned by SlurmUser root!=slurm

最終的にはslurmdbd.conf作成後に以下のコマンドを発行する手順としました。

sudo chmod 600 /opt/slurm/etc/slurmdbd.conf
sudo chown slurm. /opt/slurm/etc/slurmdbd.conf

DB初期接続でサービス起動失敗

/opt/slurm/etc/slurm.confClusterNameの指定した名前と、sacctmgr add clusterで指定したクラスター名が違うと、slurmctld起動時に以下のエラーで起動に失敗します。双方のクラスター名の指定に誤りがないか見直してください。

$ sudo systemctl status slurmctld
● slurmctld.service - Slurm controller daemon
     Loaded: loaded (/etc/systemd/system/slurmctld.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Sun 2022-05-29 01:53:36 UTC; 6s ago
    Process: 2106 ExecStart=/opt/slurm/sbin/slurmctld -D $SLURMCTLD_OPTIONS (code=exited, status=1/FAILURE)
   Main PID: 2106 (code=exited, status=1/FAILURE)

May 29 01:53:35 ip-10-0-1-136 systemd[1]: Started Slurm controller daemon.
May 29 01:53:36 ip-10-0-1-136 slurmctld[2106]: slurmctld: fatal: CLUSTER NAME MISMATCH.
May 29 01:53:36 ip-10-0-1-136 slurmctld[2106]: slurmctld has been started with "ClusterName=test-cluster", but read "parallelcl>
May 29 01:53:36 ip-10-0-1-136 slurmctld[2106]: Running multiple clusters from a shared StateSaveLocation WILL CAUSE CORRUPTION.
May 29 01:53:36 ip-10-0-1-136 slurmctld[2106]: Remove /var/spool/slurm.state/clustername to override this safety check if this >
May 29 01:53:36 ip-10-0-1-136 systemd[1]: slurmctld.service: Main process exited, code=exited, status=1/FAILURE
May 29 01:53:36 ip-10-0-1-136 systemd[1]: slurmctld.service: Failed with result 'exit-code'.

DB に登録したクラスター名を削除するにはdeleteオプションに引数でクラスター名を指定して削除できます。

sudo /opt/slurm/bin/sacctmgr delete cluster hoge

おわりに

AWS ParallelCluster 3 になってから一度も検証していなかったため、改めて検証し記事を書きました。また Aurora Serverless v2 より v1 の方がクラウド HPC 環境には適しているケースが多いのではないかと思い触れました。

参考

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.