Slurm での アカウンティング AWS ParallelCluster - AWS ParallelCluster
v3.10.0 AWS ParallelCluster 以降Slurmdbdで外部 を使用してアSlurmカウンティングを操作するv3.3.0 AWS ParallelCluster 以降のヘッドノードを使用したアSlurmカウンティングSlurmdbdの操作Slurm のアカウンティングに関する考慮事項

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Slurm での アカウンティング AWS ParallelCluster

バージョン 3.3.0 以降、 はクラスター設定パラメータ SlurmSettings / Database によるSlurmアカウンティング AWS ParallelCluster をサポートしています。

バージョン 3.10.0 以降、 はクラスター設定パラメータ SlurmSettings / ExternalSlurmdbd ExternalSlurmdbd とのSlurmアカウンティング AWS ParallelCluster をサポートします。複数のクラスターが同じデータベースを共有する場合は、外部 Slurmdbd を使用することをお勧めします。

Slurm アカウンティングを使用すると、外部のアカウンティングデータベースを統合して次のことを行うことができます。

  • クラスターユーザーまたはユーザーのグループとその他のエンティティを管理する。この機能により、リソース制限の適用、Fairshare、QoS などの、より高度な Slurm の機能を使用できます。

  • ジョブを実行したユーザー、ジョブの期間、および使用するリソースなどのジョブデータを収集して保存する。保存したデータは sacct ユーティリティを使用して表示できます。

注記

AWS ParallelCluster は、Slurmサポートされている MySQL データベースサーバーのSlurmアカウンティングをサポートしています。

v3.10.0 AWS ParallelCluster 以降Slurmdbdで外部 を使用してアSlurmカウンティングを操作する

Slurm アカウンティングを設定する前に、既存の外部データベースサーバーに接続する既存の外部 Slurmdbd データベースサーバーが必要です。

これを設定するには、以下を定義します。

  • ExternalSlurmdbd/Host 内の外部 Slurmdbd サーバーのアドレス。このサーバーが存在していて、ヘッドノードからアクセスできることが必要です。

  • MungeKeySecretArn で外部 Slurmdbd サーバーと通信するための munge キー。

チュートリアルを完了するには、「外部 Slurmdbd アカウンティングによるクラスターの作成」を参照してください。

注記

Slurm データベースのアカウンティングエンティティを管理する責任はユーザーにあります。

AWS ParallelCluster 外部SlurmDBサポート機能のアーキテクチャにより、複数のクラスターが同じSlurmDBデータベースを共有できます。

A flowchart depicting the Database Stack, Slurmdbd stack, PC Cluster Stack 1, and PC Cluster Stack 2. Containing components such as Slurmdbd instance, RDS Aurora MySQL Database, and Login nodes.

警告

AWS ParallelCluster と外部との間のトラフィックSlurmDBは暗号化されません。クラスターと外部 SlurmDB は、信頼できるネットワークで実行することをお勧めします。

v3.3.0 AWS ParallelCluster 以降のヘッドノードを使用したアSlurmカウンティングSlurmdbdの操作

Slurm アカウンティングを設定する前に、既存の外部データベースサーバーと mysql プロトコルを使用するデータベースが必要です。

でSlurmアカウンティングを設定するには AWS ParallelCluster、以下を定義する必要があります。

  • Database/Uri の形式で表す外部データベースサーバーの URI。サーバーが存在し、ヘッドノードから到達できる必要があります。

  • Database / PasswordSecretArn および Database / UserName. で定義されている外部データベースにアクセスするための認証情報。この情報 AWS ParallelCluster を使用して、 Slurmレベルでアカウンティングを設定し、ヘッドノード上の slurmdbdサービスを設定します。 slurmdbdは、クラスターとデータベースサーバー間の通信を管理するデーモンです。

チュートリアルを完了するには、「Slurm アカウンティングによるクラスターの作成」を参照してください。

注記

AWS ParallelCluster は、デフォルトのクラスターユーザーをデータベースのデータベース管理者として設定することで、アSlurmカウンティングSlurmデータベースの基本的なブートストラップを実行します。 AWS ParallelCluster は、アカウンティングデータベースに他のユーザーを追加しません。Slurm データベースのアカウンティングエンティティを管理する責任はお客様にあります。

AWS ParallelCluster はslurmdbd、クラスターがSlurmデータベースサーバー上に独自のデータベースを持つように を設定します。複数のクラスターで同じデータベースサーバーを使用できますが、各クラスターには独自の個別のデータベースがあります。 はクラスター名 AWS ParallelCluster を使用して、slurmdbd設定ファイルStorageLocパラメータでデータベースの名前を定義します。次の状況を考えてみます。データベースサーバーに存在するデータベースに、アクティブなクラスター名にマッピングされていないクラスター名が含まれています。この場合、そのクラスター名を使用して新しいクラスターを作成し、そのデータベースにマッピングできます。Slurm は新しいクラスターにデータベースを再利用します。

警告

  • 一度に同じデータベースを使用するように複数のクラスターを設定することはお勧めしません。これにより、パフォーマンスの問題またはデータベースのデッドロック状態が発生する可能性があります。

  • クラスターのヘッドノードで Slurm アカウンティングが有効になっている場合、強力な CPU、より多くのメモリ、およびより高いネットワーク帯域幅を使用するインスタンスタイプを使用することをお勧めします。Slurm アカウンティングによりクラスターのヘッドノードに負担が加わる可能性があります。

アカウンティング機能の現在のアーキテクチャ AWS ParallelCluster Slurmでは、次の図の設定例に示すように、各クラスターにはslurmdbdデーモンの独自のインスタンスがあります。

A configuration with two clusters that are connected to a MySQL server. Each cluster has their own slurmdbd daemon instance. Moreover, each cluster is connected to its own database through the server. Another configuration with a single cluster that has its own slurmdbd daemon instance. This configuration is connected to a MySQL server and is also connected to its own database through the server.

クラスター環境に Slurm カスタムマルチクラスター機能またはフェデレーション機能を追加する場合、すべてのクラスターが同じ slurmdbd インスタンスを参照する必要があります。この代替方法として、1 つのクラスターでアカウンティングを有効に AWS ParallelCluster Slurmし、最初のクラスターでホストslurmdbdされている に接続するように他のクラスターを手動で設定することをお勧めします。

AWS ParallelCluster バージョン 3.3.0 より前のバージョンを使用している場合は、この HPC ブログ投稿で説明されているアSlurmカウンティングを実装する別の方法を参照してください。

Slurm のアカウンティングに関する考慮事項

異なる VPC のデータベースとクラスター

Slurm のアカウンティングを有効にするには、slurmdbd デーモンが実行する読み取り操作と書き込み操作のバックエンドとして機能するデータベースサーバーが必要です。クラスターを作成または更新して Slurm アカウンティングを有効にする前に、ヘッドノードがデータベースサーバーに到達できる必要があります。

クラスターが使用していない VPC にデータベースサーバーをデプロイする必要がある場合は、次の点を考慮します。

  • クラスター側の slurmdbd とデータベースサーバー間の通信を有効にするには、2 つの VPC 間の接続を設定する必要があります。詳細については、「Amazon Virtual Private Cloud ユーザーガイド」の「VPC ピア機能とは」を参照してください。

  • クラスターの VPC のヘッドノードにアタッチするセキュリティグループを作成する必要があります。2 つの VPC がピアリング接続されると、データベース側とクラスター側のセキュリティグループ間のクロスリンクが使用可能になります。詳細については、「Amazon Virtual Private Cloud ユーザーガイド」の「セキュリティグループのルール」を参照してください。

slurmdbd とデータベースサーバー間の TLS 暗号化を設定する

AWS ParallelCluster が提供するデフォルトのSlurmアカウンティング設定では、サーバーが Amazon RDS などの TLS encryption. AWS database サービスをサポートし、 がデフォルトで TLS 暗号化 Amazon Aurora をサポートしている場合、 はデータベースサーバーへの TLS 暗号化接続slurmdbdを確立します。

データベースサーバーで require_secure_transport パラメータを設定することにより、サーバー側の安全な接続を要求できます。これは、提供されている CloudFormation テンプレートで設定されます。

セキュリティのベストプラクティスに従って、slurmdbd クライアントのサーバー ID 検証も有効にすることをお勧めします。これを行うには、slurmdbd.conf で StorageParameters を設定します。サーバー CA 証明書をクラスターのヘッドノードにアップロードします。次に、slurmdbd.conf の StorageParameters の SSL_CA オプションをヘッドノードのサーバー CA 証明書のパスに設定します。これにより、slurmdbd 側でのサーバー ID 検証が有効になります。これらの変更を行った後、slurmdbd サービスを再起動して ID 検証が有効になっているデータベースサーバーへの接続を再確立します。

データベース認証情報を更新する

Database/UserName または PasswordSecretArn の値を更新するには、まずコンピューティングフリートを停止する必要があります。シークレットに保存されている AWS Secrets Manager シークレット値が変更され、その ARN が変更されないとします。この状況では、クラスターは自動的にデータベースのパスワードを新しい値に更新しません。新しいシークレット値のクラスターを更新するには、ヘッドノードから次のコマンドを実行します。

$ sudo /opt/parallelcluster/scripts/slurm/update_slurm_database_password.sh
警告

財務データが失われないように、コンピューティングフリートが停止している場合にのみデータベースパスワードを変更することをお勧めします。

データベースのモニタリング

AWS データベースサービスのモニタリング機能を有効にすることをお勧めします。詳細については、「Amazon RDS のモニタリング」または「Amazon Aurora のモニタリング」のドキュメントを参照してください。