diff --git a/_pages/hpc.md b/_pages/hpc.md index 3edd84b1c7..1370696e00 100644 --- a/_pages/hpc.md +++ b/_pages/hpc.md @@ -57,7 +57,7 @@ table, th, td { | | 利点 | 欠点 | 備考 | | -| ------------------- | -------------------------------------------------------------- | ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | --- | +| :-------------------: | -------------------------------------------------------------- | ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | --- | | 自動構築
（スタック） | ユーザの作業時間(\*1)が短い
GUIによる操作(\*2)が可能 | 構築手順のブラックボックス化
　・システム構成の変更が難しい
　・問題発生時原因究明難 | \*1) スタックメニュー選択の時間
\*2) OCIコンソール | | | 自動構築
（Terraform） | ユーザの作業時間(\*3)が短い
CLI/GUI(\*4)を選択可能 | Terraform実行環境(\*5)が必要 | \*3) スタックメニュー選択の時間
or
Terraformスクリプト内変数修正
に要する時間
\*4) Terraform CLI/OCIコンソール
\*5) Terraform CLIを選択した場合 | | | 手動構築
（OCIコンソール） | 構築手順が明確
　・システム構成の変更が容易
　・問題発生時原因究明容易
GUIによる操作(\*6)が可能 | ユーザの作業時間が長い | \*6) OCIコンソール操作 | | @@ -118,20 +118,20 @@ table, th, td { 本章は、異なるカテゴリのチュートリアルを組み合わせてより実践的なHPCシステムを構築する手法を紹介します。自身の要件に合わせてチュートリアルを選んだら、そのチュートリアル名をクリックします。 -| No. | チュートリアル名 | 組み合わせるチュートリアル | 構築するシステム概要 | -| --- | ------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------- | +| No. | チュートリアル名 | 組み合わせるチュートリアル | 構築するシステム概要 | +| :-: | ------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | | 1 | **[ブロック・ボリュームNFSサーバと
基礎インフラ編HPC/GPUクラスタを
組み合わせる](/ocitutorials/hpc/cluster-with-bv-base/)** | **[ブロック・ボリュームで
NFSサーバを構築する](/ocitutorials/hpc/spinup-nfs-server/)**

**[HPCクラスタを構築する
(基礎インフラ手動構築編)](/ocitutorials/hpc/spinup-cluster-network/)**
or
**[GPUクラスタを構築する
(基礎インフラ手動構築編)](/ocitutorials/hpc/spinup-gpu-cluster/)** | 基礎インフラ編のHPC/GPUクラスタの
ファイル共有ストレージを
**ブロック・ボリューム** NFSサーバで
サービス | | 2 | **[ブロック・ボリュームNFSサーバと
自動構築編HPC/GPUクラスタを
組み合わせる](/ocitutorials/hpc/cluster-with-bv-stack/)** | **[ブロック・ボリュームで
NFSサーバを構築する](/ocitutorials/hpc/spinup-nfs-server/)**

**[HPCクラスタを構築する
(スタティッククラスタ自動構築編)](/ocitutorials/hpc/spinup-hpc-cluster)**
or
**[HPCクラスタを構築する
(オンデマンドクラスタ自動構築編)](/ocitutorials/hpc/spinup-hpc-cluster-withautoscaling)**
or
**[GPUクラスタを構築する
(スタティッククラスタ自動構築編)](/ocitutorials/hpc/spinup-gpu-cluster-withstack/)**
or
**[GPUクラスタを構築する
(オンデマンドクラスタ自動構築編)](/ocitutorials/hpc/spinup-gpu-cluster-withautoscaling/)** | 自動構築編のHPC/GPUクラスタの
ファイル共有ストレージを
**ブロック・ボリューム** NFSサーバで
サービス | 下表は、各チュートリアルで構築するシステム仕様を示します。 -| No. | 構築手法 | クラスタ管理機能 | スタティック/オンデマンド | コンテナランタイム(\*9) | -| --- | ---- | -------- | ---------------------- | -------------- | -| 1 | 手動 | 無し(\*8) | スタティック | Docker CE | +| No. | 構築手法 | クラスタ管理機能 | スタティック/オンデマンド | コンテナランタイム（※9） | +| :-: | :--: | :------: | :--------------------: | :------------: | +| 1 | 手動 | 無し（※8） | スタティック | Docker CE | | 2 | 自動 | 有り | スタティック
or
オンデマンド | Enroot | -\*8) NFSユーザホームディレクトリ共有は、 **ブロック・ボリューム** NFSサーバが提供します。 -\*9) GPUクラスタが対象です。 +※8）NFSユーザホームディレクトリ共有は、 **ブロック・ボリューム** NFSサーバが提供します。 +※9）GPUクラスタが対象です。 *** # 2. OCI HPCパフォーマンス関連情報 @@ -154,7 +154,7 @@ table, th, td { 各ベンチマークの実行方法は、下表の対象シェイプ部分のリンクをクリックして参照ください。 | 名称 | ベンチマークサイトURL | 対象シェイプ | -| ----------------------- | ---------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | +| :---------------------: | :--------------------------------------------------------------------------------------------------------: | :-------------------------------------------------------------------------------------------------------------------------------------: | | **HPL** | **[Link](https://www.netlib.org/benchmark/hpl/)** | **[BM.Optimized3.36](/ocitutorials/hpc/benchmark/run-hpl/)**
**[BM.Standard.E5.192](/ocitutorials/hpc/benchmark/run-hpl-e5/)** | | **STREAM** | **[Link](https://www.cs.virginia.edu/stream/)** | **[BM.Optimized3.36](/ocitutorials/hpc/benchmark/run-stream/)**
**[BM.Standard.E5.192](/ocitutorials/hpc/benchmark/run-stream-e5/)** | | **Intel MPI Benchmark** | **[Link](https://www.intel.com/content/www/us/en/developer/articles/technical/intel-mpi-benchmarks.html)** | **[BM.Optimized3.36](/ocitutorials/hpc/benchmark/run-imb/)** | @@ -176,6 +176,12 @@ table, th, td { 特に高並列実行時は、HPCクラスタ内の1ノードでこのようなサービスが稼働していることで、そのスケーラビリティに影響を及ぼします。 本パフォーマンス関連Tipsは、OS標準で稼働している常駐サービスの中でリソースを多く消費しているものを特定しこれを停止することで、OSレベルのパフォーマンスチューニングを実施する方法を解説します。 +- **[クラスタ・ネットワークのトポロジーを考慮したノード間通信最適化方法](/ocitutorials/hpc/benchmark/topology-aware-cn-tuning/)** + + **[クラスタ・ネットワーク](/ocitutorials/hpc/#5-1-クラスタネットワーク)** は、業界標準のRoCEv2を採用する高帯域・低遅延のRDMA対応インターコネクトネットワークサービスで、そのトポロジーがFat treeのため同一リーフスイッチに接続するノード間とスパインスイッチを介して異なるリーフスイッチに接続するノード間で、ノード間通信のレイテンシが大きく異なります。このため、この特性を意識して適切な計算/GPUノードにジョブを配置することで、レイテンシに影響を受け易いワークロードの性能や高並列実行時のスケーラビリティを改善できる場合があります。 + 本パフォーマンス関連Tipsは、この **クラスタ・ネットワーク** のレイテンシ特性を生かしてマルチノードジョブをクラスタ内に配置することで、ノード間通信性性能を最適化する方法を解説します。 + + *** # 3. OCI HPCテクニカルTips集 @@ -279,6 +285,11 @@ table, th, td { オンデマンドクラスタの管理は、ソフトウェアにより自動化することが一般的ですが、HPC/GPUクラスタに必要なOCIリソースの作成・終了をこのアプリケーションに許可するための仕組みとして、 **[インスタンス・プリンシパル](/ocitutorials/hpc/#5-15-インスタンスプリンシパル)** 認証が用意されています。 本テクニカルTipsは、オンデマンドクラスタを念頭とした **インスタンス・プリンシパル** 認証の設定方法を解説します。 +- **[Slurmによるリソース管理・ジョブ管理システム構築方法](/ocitutorials/hpc/tech-knowhow/setup-slurm-cluster/)** + + HPC/GPUクラスタのリソース管理・ジョブ管理は、ジョブスケジューラを活用することでこれを効率的かつ柔軟に運用することが可能です。近年のHPC/機械学習ワークロードの大規模化は、MPI等を使ったノード間並列ジョブの重要性を増大させ、このような大規模ジョブを様々な運用ポリシーに沿って処理出来る機能をジョブスケジューラに求めています。オープンソースのジョブスケジューラ **[Slurm](https://slurm.schedmd.com/)** は、この要求を満足出来る代表的なジョブスケジューラとして現在人気を集めています。 + 本テクニカルTipsは、HPC/機械学習ワークロードの実行に最適なベアメタルインスタンスを高帯域・低遅延RDMAインターコネクトサービスの **[クラスタ・ネットワーク](/ocitutorials/hpc/#5-1-クラスタネットワーク)** で接続するHPC/GPUクラスタで、リソース管理・ジョブ管理システムを **Slurm** で構築する方法を解説します。 + ## 3-4. 機械学習 - **[UbuntuをOSとする機械学習ワークロード向けGPUノード構築方法](/ocitutorials/hpc/tech-knowhow/gpu-with-ubuntu/)** @@ -301,18 +312,18 @@ table, th, td { ## 5-1. クラスタ・ネットワーク -クラスタ・ネットワークは、ノード間を高帯域・低遅延に接続するインターコネクトネットワークで、以下の特徴を持ちます。 +**クラスタ・ネットワーク** は、ノード間を高帯域・低遅延に接続するインターコネクトネットワークサービスで、以下の特徴を持ちます。 - RoCEv2を採用するリンク当たり100 Gbpsの高帯域・低遅延RDMAインターコネクト -- オーバーサブスクリプションの無いフラットなトポロジーによる再現性の高いネットワーク特性 +- オーバーサブスクリプションの無いノンブロッキングトポロジーから来る高い性能再現性 -クラスタ・ネットワークは、OCIのリソースとして定義し、指定したノード数のインスタンスとともにデプロイされ、これらのインスタンスをクラスタ・ネットワークに接続します。 -クラスタ・ネットワークの作成は、 **[インスタンス構成](#5-7-インスタンス構成)** とインスタンス数を指定して行い、このインスタンス構成に紐づく **[インスタンス・プール](#5-8-インスタンスプール)** が自動的に作成され、このインスタンス・プールがクラスタ・ネットワークに接続するインスタンスをインスタンス構成に従ってデプロイします。 -なお、インスタンスがクラスタ・ネットワークに接続するためのIPアドレス設定等を含むネットワークインターフェースは、ユーザ自身で設定する必要があります。本ポータルサイトのチュートリアルは、cloud-initやAnsibleでこれらの設定を自動化しています。 +**クラスタ・ネットワーク** は、OCIのリソースとして定義し、指定したノード数のインスタンスとともにデプロイされ、これらのインスタンスを **クラスタ・ネットワーク** に接続します。 +**クラスタ・ネットワーク** の作成は、 **[インスタンス構成](#5-7-インスタンス構成)** とインスタンス数を指定して行い、このインスタンス構成に紐づく **[インスタンス・プール](#5-8-インスタンスプール)** が自動的に作成され、このインスタンス・プールが **クラスタ・ネットワーク** に接続するインスタンスをインスタンス構成に従ってデプロイします。 +なお、インスタンスが **クラスタ・ネットワーク** に接続するためのIPアドレス設定等を含むネットワークインターフェースは、ユーザ自身で設定する必要があります。本ポータルサイトのチュートリアルは、cloud-initやAnsibleでこれらの設定を自動化しています。 関連するOCI公式ドキュメントは、 **[ここ](https://docs.oracle.com/ja-jp/iaas/Content/Compute/Tasks/managingclusternetworks.htm)** を参照ください。 -OCIコンソールのクラスタ・ネットワークメニューは、 **[ここ](https://cloud.oracle.com/compute/cluster-networks)** をクリックしてアクセスします。OCIへのログインを要求された場合は、ログインを完了して下さい。 +OCIコンソールの **クラスタ・ネットワーク** メニューは、 **[ここ](https://cloud.oracle.com/compute/cluster-networks)** をクリックしてアクセスします。OCIへのログインを要求された場合は、ログインを完了して下さい。 ## 5-2. リソース・マネージャ @@ -436,7 +447,7 @@ HPCクラスタスタックは、CPUワークロード向けHPCクラスタや - /etc/hostsファイル生成 - NFSファイル共有環境構築 - LDAPユーザ統合環境構築 -- クラスタ・ネットワーク用ネットワークインターフェース構築 +- **クラスタ・ネットワーク** 用ネットワークインターフェース構築 - Slurm環境構築 - Enroot環境構築 @@ -462,7 +473,7 @@ runcmd: cloud-initによるOSカスタマイズは、基本的にインスタンスデプロイ後に一度だけ実施されるため、HPC向けベアメタルインスタンスをデプロイする際に必須となる、NVMeローカルディスク領域ファイルシステム作成や、 **[クラスタ・ネットワーク](#5-1-クラスタネットワーク)** 用ネットワークインターフェース設定を実施するのに最適です。 -cloud-initは、クラスタ・ネットワーク作成時に指定するインスタンス構成と紐づけることで、クラスタ・ネットワークに接続する全ての計算ノードやGPUノードに一斉にOSカスタマイズを適用することを可能にします。 +cloud-initは、 **クラスタ・ネットワーク** 作成時に指定するインスタンス構成と紐づけることで、 **クラスタ・ネットワーク** に接続する全ての計算ノードやGPUノードに一斉にOSカスタマイズを適用することを可能にします。 cloud-init公式ドキュメントは、 **[ここ](https://cloudinit.readthedocs.io/en/latest/)** を参照ください。 @@ -510,12 +521,12 @@ $ **クラスタネットワーキングイメージ** は、 **[クラスタ・ネットワーク](#5-1-クラスタネットワーク)** への接続に必要な以下ソフトウェアがインストールされた **Oracle Linux** をベースとするOSイメージで、 **[マーケットプレイス](#5-5-マーケットプレイス)** から **[カスタム・イメージ](#5-6-カスタムイメージ)** として提供されています。 - **Mellanox OFED** -- **wpa_supplicant** [^wpa_supplicant] -- **oci-cn-auth** [^oci-cn-auth] +- **wpa_supplicant** （※1） +- **oci-cn-auth** （※2） -[^wpa_supplicant]: wpa_supplicant：クラスタ・ネットワークは、インスタンスが接続する際802.1X認証を要求しますが、これらの処理を行うクライアントソフトウェアがwpa_supplicantです。802.1X認証の仕組みは、[ここ](https://www.infraexpert.com/study/wireless14.html)のサイトが参考になります。 +※1）**クラスタ・ネットワーク** は、インスタンスが接続する際802.1X認証を要求しますが、これらの処理を行うクライアントソフトウェアがwpa_supplicantです。802.1X認証の仕組みは、[ここ](https://www.infraexpert.com/study/wireless14.html)のサイトが参考になります。 -[^oci-cn-auth]: oci-cn-auth：クラスタ・ネットワークに接続する際の802.1X認証で必要な認証処理機能を提供するユーティリティーソフトウェアで、GitHubから公開されています。 +※2）**クラスタ・ネットワーク** に接続する際の802.1X認証で必要な認証処理機能を提供するユーティリティーソフトウェアで、GitHubから公開されています。 **クラスタネットワーキングイメージ** は、使用するシェイプがGPUを搭載するかどうかに応じて、HPC **クラスタネットワーキングイメージ** とGPU **クラスタネットワーキングイメージ** の2種類があり、それぞれで異なる **Oracle Linux** のバージョンをベースとするイメージが提供されています。 使用するシェイプに合わせて適切に **クラスタネットワーキングイメージ** を選択する方法は、 **[OCI HPCテクニカルTips集](#3-oci-hpcテクニカルtips集)** の **[クラスタネットワーキングイメージの選び方](/ocitutorials/hpc/tech-knowhow/osimage-for-cluster/)** を参照ください。 diff --git a/tutorials/_hpc/benchmark/stop-unused-service.md b/tutorials/_hpc/benchmark/stop-unused-service.md index 3c6ee46c6b..7e18af9155 100644 --- a/tutorials/_hpc/benchmark/stop-unused-service.md +++ b/tutorials/_hpc/benchmark/stop-unused-service.md @@ -1,7 +1,7 @@ --- title: "不要サービス停止によるパフォーマンスチューニング方法" excerpt: "計算リソースを極限まで使用するHPCワークロードの実行に於いては、些細な計算リソースを使用するOS常駐サービスがその性能に影響することがあります。特に高並列実行時は、HPCクラスタ内の1ノードでこのようなサービスが稼働していることで、そのスケーラビリティに影響を及ぼします。本パフォーマンス関連Tipsは、OS標準で稼働している常駐サービスの中でリソースを多く消費しているものを特定しこれを停止することで、OSレベルのパフォーマンスチューニングを実施する方法を解説します。" -order: "223" +order: "222" layout: single header: overlay_filter: rgba(34, 66, 55, 0.7) diff --git a/tutorials/_hpc/benchmark/topology-aware-cn-tuning.md b/tutorials/_hpc/benchmark/topology-aware-cn-tuning.md new file mode 100644 index 0000000000..709d2a9a86 --- /dev/null +++ b/tutorials/_hpc/benchmark/topology-aware-cn-tuning.md @@ -0,0 +1,266 @@ +--- +title: "クラスタ・ネットワークのトポロジーを考慮したノード間通信最適化方法" +excerpt: "クラスタ・ネットワークは、業界標準のRoCEv2を採用する高帯域・低遅延のRDMA対応インターコネクトネットワークサービスで、そのトポロジーがFat treeのため同一リーフスイッチに接続するノード間とスパインスイッチを介して異なるリーフスイッチに接続するノード間で、ノード間通信のレイテンシが大きく異なります。このため、この特性を意識して適切な計算/GPUノードにジョブを配置することで、レイテンシに影響を受け易いワークロードの性能や高並列実行時のスケーラビリティを改善できる場合があります。本パフォーマンス関連Tipsは、このクラスタ・ネットワークのレイテンシ特性を生かしてマルチノードジョブをクラスタ内に配置することで、ノード間通信性性能を最適化する方法を解説します。" +order: "223" +layout: single +header: + overlay_filter: rgba(34, 66, 55, 0.7) +#link: https://community.oracle.com/tech/welcome/discussion/4474261/ +--- + +**[クラスタ・ネットワーク](/ocitutorials/hpc/#5-1-クラスタネットワーク)** は、業界標準のRoCEv2を採用する高帯域・低遅延のRDMA対応インターコネクトネットワークサービスで、そのトポロジーがFat treeのため同一リーフスイッチに接続するノード間とスパインスイッチを介して異なるリーフスイッチに接続するノード間で、ノード間通信のレイテンシが大きく異なります。このため、この特性を意識して適切な計算/GPUノードにジョブを配置することで、レイテンシに影響を受け易いワークロードの性能や高並列実行時のスケーラビリティを改善できる場合があります。 +本パフォーマンス関連Tipsは、この **クラスタ・ネットワーク** のレイテンシ特性を生かしてマルチノードジョブをクラスタ内に配置することで、ノード間通信性性能を最適化する方法を解説します。 + +*** +# 0. 概要 + +**[クラスタ・ネットワーク](/ocitutorials/hpc/#5-1-クラスタネットワーク)** は、そのトポロジーにノンブロッキング構成のFat treeを採用し、複数のノードに跨るHPC/機械学習ワークロードを実行するHPC/GPUクラスタのノード間接続に最適なサービスです。 + +この **クラスタ・ネットワーク** は、下図のような2階層スパイン・リーフトポロジーを有し、デプロイ時点のデータセンターリソース状況に応じて何れかのリーフスイッチ配下にインスタンスを接続します。 + +![画面ショット](topology.png) + +このためノード間通信性能は、通信する2ノードがどのリーフスイッチ配下に接続されているかにより、特にレイテンシが大きく異なります。 +最もレイテンシ性能が良いノードの組合せは、同一リーフスイッチ配下に接続するノード同士で、異なるリーフスイッチ配下に接続するノード同士は、その間のホップ数増加により同一リーフスイッチ配下のノード間と比較してレイテンシが増大します。 + +このリーフスイッチは、ラック内に設置されているいわゆるTOR（Top of Rack）スイッチで、 **インスタンス・メタデータ** に格納されているラック識別IDを調べることで、デプロイしたインスタンスが **クラスタ・ネットワーク** のどのリーフスイッチに接続しているかを知ることが出来ます。 + +例えば、4ノードのインスタンスを **クラスタ・ネットワーク** と共にデプロイした際、以下のように2インスタンス毎に2ラックに配置されたとすると、 + +| ラック
（リーフスイッチ） | インスタンス | +| :--------------: | :----: | +| rack_1 | inst_1 | +| | inst_2 | +| rack_2 | inst_3 | +| | inst_4 | + +最もレイテンシー性能が良いノードの組み合わせは **inst_1 <---> inst_2** と **inst_3 <---> inst_4** で、その他の組み合わせはこれよりレイテンシが大きくなります。 +**クラスタ・ネットワーク** は、この点を考慮してデプロイ時に極力同一リーフスイッチ配下のインスタンスを選択するアルゴリズムが組み込まれていますが、同一ラックに収容できるインスタンス数の上限や他のユーザの利用状況で異なるリーフスイッチに跨ってインスタンスを配置することがあり、この観点で **クラスタ・ネットワーク** 内のインスタンス接続位置を意識することは意味を持ちます。 + +このようして取得した **クラスタ・ネットワーク** のトポロジー情報は、ジョブスケジューラ **[Slurm](https://slurm.schedmd.com/)** の持つ **[Topology-aware resource allocation](https://slurm.schedmd.com/topology.html)** に活用することが出来ます。 + +本テクニカルTipsは、HPCワークロード向けベアメタルシェイプ **[BM.Optimized3.36](https://docs.oracle.com/ja-jp/iaas/Content/Compute/References/computeshapes.htm#bm-hpc-optimized)** と **Oracle Linux** 8ベースの **HPC[クラスタネットワーキングイメージ](/ocitutorials/hpc/#5-13-クラスタネットワーキングイメージ)** を **クラスタ・ネットワーク** と共にデプロイするHPCクラスタを想定し、ノード間通信性能に最適なノード配置を自動的に行う **Slurm** クラスタの構築を、以下のステップに従い解説します。 + +- **クラスタ・ネットワーク** トポロジー特定 +- **Topology-aware resource allocation** セットアップ +- **Topology-aware resource allocation** 稼働確認 + +*** +# 1. クラスタ・ネットワークトポロジー特定 + +本章は、 **[クラスタ・ネットワーク](/ocitutorials/hpc/#5-1-クラスタネットワーク)** と共にデプロイした **BM.Optimized3.36** が配置されているラックIDを **インスタンス・メタデータ** から入手し、 **クラスタ・ネットワーク** 内のどのリーフスイッチに接続されているかを特定します。 + +以下コマンドを **pdsh** が利用可能なクラスタ管理ノードのopcユーザで実行し、各インスタンスを収容するラックIDを収集します。 +なお **pdsh** の詳細は、 **[OCI HPCテクニカルTips集](/ocitutorials/hpc/#3-oci-hpcテクニカルtips集)** の **[pdshで効率的にクラスタ管理オペレーションを実行](/ocitutorials/hpc/tech-knowhow/cluster-with-pdsh/)** を参照ください。 + +```sh +$ pdsh -g all 'sudo curl -sH "Authorization: Bearer Oracle" -L http://169.254.169.254/opc/v2/host 2> /dev/null | jq .rackId' | dshbak -c +---------------- +inst-0shbg-x9,inst-91oup-x9 +---------------- +"3eec77ea664b0599b20732536409a9f3893eef6a78e5da3539dd4bfb7918f88e" +---------------- +inst-el428-x9,inst-nzy6b-x9 +---------------- +"820b14c49603d2818dc431ef88fba33e205e10b0a1ec7e076cf1a021950aea28" +$ +``` + +この結果から、下表のネットワークトポロジーを得ます。 + +| ラックID | リーフスイッチ | インスタンス | +| :-----------: | :-----: | :-----------: | +| 3eec....8f88e | ls0 | inst-0shbg-x9 | +| | | inst-91oup-x9 | +| 820b....ea28 | ls1 | inst-el428-x9 | +| | | inst-nzy6b-x9 | + +*** +# 2. Topology-aware resource allocationセットアップ + +本章は、先に取得した **[クラスタ・ネットワーク](/ocitutorials/hpc/#5-1-クラスタネットワーク)** のトポロジー情報を元に、 **Slurm** の **Topology-aware resource allocation** をセットアップします。 + +取得したトポロジー情報から、 **Topology-aware resource allocation** の設定ファイル **topology.conf** を以下のように作成し、これを **slurm.conf** と同じディレクトリに配置します。 + +```sh +SwitchName=ls0 Nodes=inst-0shbg-x9,inst-91oup-x9 +SwitchName=ls1 Nodes=inst-el428-x9,inst-nzy6b-x9 +SwitchName=ss0 Switches=ls[0-1] +``` + +この設定ファイルは、自身の環境に合わせて以下の方針で修正します。 + +- 最後のスパインスイッチ定義行の **[]** 内を実際のリーフスイッチ数に修正 +- それ以外のリーフスイッチ定義行を実際のリーフスイッチ数分作成 +- リーフスイッチ定義行の **Nodes=** に実際のインスタンスの名前解決可能なホスト名を記載 + +次に、 **slurm.conf** に以下の記述を追加します。 + +``` +$ grep TopologyPlugin slurm.conf +TopologyPlugin=topology/tree +$ +``` + +次に、以下コマンドをslurmctldが動作するノードの **Slurm** 管理者権限を有するユーザで実行します。 + +``` +$ scontrol reconfigure +``` + +この設定が正しく行われると、sbatch・srun・sallocコマンドで以下のオプションが使用可能になります。 + +**- -switches=max_leaf[@max_wait]** + +このオプションは、ジョブに割当てるノード群の接続に使用するリーフスイッチ最大数を **max_leaf** に指定します。 +**クラスタ・ネットワーク** は、2階層のスパイン・リーフトポロジーのため、この値を1に指定すると割当てるノード群を同一リーフスイッチ接続のものに限定することになります。 + +また指定が任意な **max_wait** は、 **max_leaf** に指定したリソース条件が満たされない場合の最大待ち時間（分）を指定します。 +この機能により、指定したリーフスイッチ数以下のノード割り当てに長時間を要する場合、指定した時間後にこれをあきらめてジョブの実行開始を優先することが可能です。 +分以外の時間指定方法は、 **man sbatch** 等を参照ください。 + +*** +# 3. Topology-aware resource allocation稼働確認 + +## 3-0. 概要 + +本章は、先に設定した **Topology-aware resource allocation** が想定通りに動作するかを確認するとともに、 **[クラスタネットワーキングイメージ](/ocitutorials/hpc/#5-13-クラスタネットワーキングイメージ)** に含まれるOpenMPIと **[Intel MPI Benchmark](https://www.intel.com/content/www/us/en/developer/articles/technical/intel-mpi-benchmarks.html)** を使用したノード間通信のレイテンシ計測を実施します。 + +**Topology-aware resource allocation** の動作確認は、以下3タイプのテストケースを使用して行います。 + +1. ジョブが流れていない状態で、 **- -switches=1@1** オプションを指定した2ノードジョブを投入し、即座にジョブが実行を開始し、レイテンシが同一リーフスイッチ接続ノード間相当であることを確認する。 + +2. 同一リーフスイッチに接続される空きノードが最大1ノードの状態で、 **- -switches=1@1** オプションを指定した2ノードジョブを投入し、1分の待ち時間の後ジョブが実行を開始し、レイテンシがスパインスイッチ跨ぎ接続ノード間相当であることを確認する。 + +3. 同一リーフスイッチに接続される空きノードが最大1ノードの状態で、 **- -switches=1@3** オプションを指定した2ノードジョブを投入し、3分未満で他の実行中ジョブが終了して同一リーフスイッチに接続される空きノードが2ノード以上に増えた時点でジョブが実行を開始し、レイテンシが同一リーフスイッチ接続ノード間相当であることを確認する。 + +以降では、各テストケースの実行方法を **[1. クラスタ・ネットワークトポロジー特定](#1-クラスタネットワークトポロジー特定)** で示した4ノードクラスタ環境を例に解説します。 + +## 3-1. テストケース1 + +以下のジョブスクリプトを用意します。 + +[no_block.sh] +```sh +#!/bin/bash +#SBATCH -n 2 +#SBATCH -N 2 +#SBATCH --switches=1@1 +#SBATCH -o no_block.out +echo "Dispatched hosts are $SLURM_JOB_NODELIST" +echo +export UCX_NET_DEVICES=mlx5_2:1 +mpirun /usr/mpi/gcc/openmpi-4.1.2a1/tests/imb/IMB-MPI1 -msglog 0:1 PingPong | grep -A1 repetitions +``` + +ジョブが流れていない状態で以下コマンドを実行し、即座にジョブが実行を開始し、レイテンシが同一リーフスイッチ接続ノード間相当の1.6us程度であることを確認します。 + +```sh +$ sbatch no_block.sh +Submitted batch job 172 +$ cat no_block.out +Dispatched hosts are inst-el428-x9,inst-nzy6b-x9 + + #bytes #repetitions t[usec] Mbytes/sec + 0 1000 1.66 0.00 +$ +``` + +## 3-2. テストケース2 + +以下2種類のジョブスクリプトを用意します。 +なお、block_sub.shの **-n** ・ **-N** ・ **--nodelist** オプションは、同一リーフスイッチに接続する空きノードが最大1で総空きノード数が2以上となるよう、自身の環境に合わせて変更します。 + +[block_main_1min.sh] +```sh +#!/bin/bash +#SBATCH -n 2 +#SBATCH -N 2 +#SBATCH --switches=1@1 +#SBATCH -o block_1min.out +echo "Dispatched hosts are $SLURM_JOB_NODELIST" +echo +export UCX_NET_DEVICES=mlx5_2:1 +mpirun /usr/mpi/gcc/openmpi-4.1.2a1/tests/imb/IMB-MPI1 -msglog 0:1 PingPong | grep -A1 repetitions +``` + +[block_sub.sh] +```sh +#!/bin/bash +#SBATCH -n 2 +#SBATCH -N 2 +#SBATCH --nodelist=inst-el428-x9,inst-0shbg-x9 +echo "Dispatched hosts are $SLURM_JOB_NODELIST" +echo +sleep 120 +``` + +ジョブが流れていない状態で以下コマンドを実行し、1分の待ち時間の後block_main_1min.sh側のジョブが実行を開始し、レイテンシがスパインスイッチ跨ぎ接続ノード間相当の3.0us程度であることを確認します。 + +```sh +$ sbatch block_sub.sh; sleep 3; sbatch block_main_1min.sh +Submitted batch job 173 +Submitted batch job 174 +$ squeue + JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON) + 174 sltest block_ma miyat PD 0:00 2 (Resources) + 173 sltest block_su miyat R 1:39 2 inst-0shbg-x9,inst-el428-x9 +$ squeue + JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON) + 173 sltest block_su miyat R 1:40 2 inst-0shbg-x9,inst-el428-x9 +$ cat block_1min.out +Dispatched hosts are inst-91oup-x9,inst-nzy6b-x9 + + #bytes #repetitions t[usec] Mbytes/sec + 0 1000 3.03 0.00 +$ +``` + +## 3-2. テストケース3 + +以下2種類のジョブスクリプトを用意します。 +なお、block_sub.shの **-n** ・ **-N** ・ **--nodelist** オプションは、同一リーフスイッチに接続する空きノードが最大1で総空きノード数が2以上となるよう、自身の環境に合わせて変更します。 + +[block_main_3min.sh] +```sh +#!/bin/bash +#SBATCH -n 2 +#SBATCH -N 2 +#SBATCH --switches=1@3 +#SBATCH -o block_3min.out +echo "Dispatched hosts are $SLURM_JOB_NODELIST" +echo +export UCX_NET_DEVICES=mlx5_2:1 +mpirun /usr/mpi/gcc/openmpi-4.1.2a1/tests/imb/IMB-MPI1 -msglog 0:1 PingPong | grep -A1 repetitions +``` + +[block_sub.sh] +```sh +#!/bin/bash +#SBATCH -n 2 +#SBATCH -N 2 +#SBATCH --nodelist=inst-el428-x9,inst-0shbg-x9 +echo "Dispatched hosts are $SLURM_JOB_NODELIST" +echo +sleep 120 +``` + +ジョブが流れていない状態で以下コマンドを実行し、2分の待ち時間の後block_main_3min.sh側のジョブが実行を開始し、レイテンシが同一リーフスイッチ接続相当の1.6us程度であることを確認します。 + +```sh +$ sbatch block_sub.sh; sleep 3; sbatch block_main_3min.sh +Submitted batch job 178 +Submitted batch job 179 +$ squeue + JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON) + 179 sltest block_ma miyat PD 0:00 2 (Resources) + 178 sltest block_su miyat R 0:06 2 inst-0shbg-x9,inst-el428-x9 +$ squeue + JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON) +$ cat block_3min.out +Dispatched hosts are inst-el428-x9,inst-nzy6b-x9 + + #bytes #repetitions t[usec] Mbytes/sec + 0 1000 1.65 0.00 +$ +``` diff --git a/tutorials/_hpc/benchmark/topology-aware-cn-tuning/Topology.png b/tutorials/_hpc/benchmark/topology-aware-cn-tuning/Topology.png new file mode 100644 index 0000000000..9f308ec6a7 Binary files /dev/null and b/tutorials/_hpc/benchmark/topology-aware-cn-tuning/Topology.png differ diff --git a/tutorials/_hpc/spinup-gpu-cluster-withubuntu.md b/tutorials/_hpc/spinup-gpu-cluster-withubuntu.md index 9e5b55d47d..8be8843213 100644 --- a/tutorials/_hpc/spinup-gpu-cluster-withubuntu.md +++ b/tutorials/_hpc/spinup-gpu-cluster-withubuntu.md @@ -94,7 +94,7 @@ header: ```sh $ wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-keyring_1.0-1_all.deb $ sudo dpkg -i cuda-keyring_1.0-1_all.deb -$ sudo apt install libnccl2 libnccl-dev +$ sudo apt install libnccl2=2.15.5-1+cuda11.8 libnccl-dev=2.15.5-1+cuda11.8 ``` なお本章の作業は、2ノードに跨る **NCCL** 通信性能検証を行う必要から、2台のGPUノードの何れにも実施します。 @@ -136,7 +136,7 @@ $ cd nccl-tests; make MPI=1 MPI_HOME=/usr/mpi/gcc/openmpi-4.1.7a1 CUDA_HOME=/usr 本章は、 **NCCL Tests** プログラムを実行します。 -2ノードのGPUノードのうち1ノードのubuntuユーザで以下のコマンドを実行し、全16枚のGPUと全16ポートのRDMAインタフェースを使用した、2ノードのGPUノードに跨る **NCCL** のAll-Reduce通信性能を計測します。 +2ノードのGPUノードのうち1ノードのubuntuユーザで以下のコマンドを実行し、16枚のGPUと16個のRDMAネットワークポートを使用した、2ノードに跨る **NCCL** のAll-Reduce通信性能を計測します。 ```sh $ mpirun -n 16 -N 8 -hostfile ~/hostlist.txt --bind-to numa -x NCCL_IB_QPS_PER_CONNECTION=4 -x NCCL_IB_GID_INDEX=3 -x UCX_NET_DEVICES=enp45s0f0np0 -x NCCL_IB_HCA="mlx5_0,mlx5_1,mlx5_2,mlx5_3,mlx5_6,mlx5_7,mlx5_8,mlx5_9,mlx5_10,mlx5_11,mlx5_12,mlx5_13,mlx5_14,mlx5_15,mlx5_16,mlx5_17" ./build/all_reduce_perf -b 10G -e 10G -t 1 -g 1 diff --git a/tutorials/_hpc/tech-knowhow/cluster-with-pdsh.md b/tutorials/_hpc/tech-knowhow/cluster-with-pdsh.md index ade177bb01..0b42ae1d1f 100644 --- a/tutorials/_hpc/tech-knowhow/cluster-with-pdsh.md +++ b/tutorials/_hpc/tech-knowhow/cluster-with-pdsh.md @@ -42,10 +42,13 @@ $ for hname in `cat hostlist.txt`; do echo $hname; ssh $hname "sudo dnf list ope ただこの場合、全てのノードで指定したRPMが想定するバージョンになっているかを確認するため、ノード数分の出力を全て確認する必要が生じます。 +また、管理対象ノードが異なる構成を持つグループに変われていてコマンド実行対象ノードを特定のグループに限定する場合、これを意識してコマンドを打ちなおす必要があります。 + **pdsh** は、このような課題を解決する以下の機能を持っています。 - 管理対象ノードに並列にコマンドを実行 - 管理対象ノードからのコマンド出力が同一だった場合これをグルーピングして出力（ユーティリティーツール **dshbak** の機能） +- 管理対象ノードをグループ分けしグループ名で指定 - 管理対象ノードに並列にファイルを転送（ユーティリティーツール **pdcp** の機能） - 管理対象ノードから並列にファイルをクラスタ管理ノードに転送（ユーティリティーツール **rpdcp** の機能） @@ -53,8 +56,7 @@ $ for hname in `cat hostlist.txt`; do echo $hname; ssh $hname "sudo dnf list ope 本テクニカルTipsでは、クラスタ管理ノードと管理対象ノードのOSに **Oracle Linux** を使用し、クラスタ管理ノードから管理対象ノードにopcユーザ（sudoで管理者権限昇格が可能なユーザ）でパスフレーズ無しでSSHコマンドを実行できる環境を前提としています。 この環境は、 **[OCI HPCチュートリアル集](/ocitutorials/hpc/#1-oci-hpcチュートリアル集)** の **[HPCクラスタ](/ocitutorials/hpc/#1-1-hpcクラスタ)** カテゴリや **[機械学習環境](/ocitutorials/hpc/#1-2-機械学習環境)** カテゴリに含まれるチュートリアルを元に構築するHPC/GPUクラスタに於いては、クラスタ管理ノードに相当するBastionノードのopcユーザから管理対象ノードに相当する計算/GPUノードにパスフレーズ無しでSSHコマンドが実行できるよう構築されるため、改めて実施する必要はありません。 -また **pdsh** は、管理対象ノードを指定する際、これらノードの名前解決可能なホスト名を1行に1ノード含む、以下のようなホストリストファイルを使用することが出来、本テクニカルTipsでもこの管理対象ノード指定方法を使用します。 -このホストリストファイルは、 **[OCI HPCテクニカルTips集](/ocitutorials/hpc/#3-oci-hpcテクニカルtips集)** の **[計算/GPUノードのホスト名リスト作成方法](/ocitutorials/hpc/tech-knowhow/compute-host-list/)** を参照して作成し、これをクラスタ管理ノードのopcユーザのホームディレクトリにファイル名 **hostlist.txt** で配置します。 +また **pdsh** は、管理対象ノードを指定する際、これらノードの名前解決可能なホスト名を1行に1ノード含む、以下のようなホストリストファイルを使用することが出来、本テクニカルTipsでもこの管理対象ノード指定方法を使用するため、 **[OCI HPCテクニカルTips集](/ocitutorials/hpc/#3-oci-hpcテクニカルtips集)** の **[計算/GPUノードのホスト名リスト作成方法](/ocitutorials/hpc/tech-knowhow/compute-host-list/)** を参照してこれを作成し、クラスタ管理ノードのopcユーザのホームディレクトリにファイル名 **hostlist.txt** で配置します。 ```sh inst-f5fra-x9-ol8 @@ -76,7 +78,7 @@ inst-dixqy-x9-ol8 ```sh $ sudo yum-config-manager --enable ol8_developer_EPEL # If Oracle Linux 8 $ sudo yum-config-manager --enable ol7_developer_EPEL # If Oracle Linux 7.9 -$ sudo yum install -y pdsh +$ sudo yum install -y pdsh pdsh-mod-dshgroup $ sudo yum install -y pdsh-rcmd-ssh # If Oracle Linux 8 ``` @@ -90,7 +92,9 @@ $ for hname in `cat ~/hostlist.txt`; do echo $hname; ssh -oStrictHostKeyChecking 次に、以下コマンドをクラスタ管理ノードのopcユーザで実行し、 **pdsh** の動作を確認します。 ```sh -$ pdsh -R ssh -w ^/home/opc/hostlist.txt date +$ echo "export PDSH_RCMD_TYPE=ssh" | tee -a ~/.bash_profile +$ source ~/.bash_profile +$ pdsh -w ^/home/opc/hostlist.txt date inst-f5fra-x9-ol8: Fri Jul 28 16:04:47 JST 2023 inst-dixqy-x9-ol8: Fri Jul 28 16:04:47 JST 2023 inst-3ktpe-x9-ol8: Fri Jul 28 16:04:47 JST 2023 @@ -103,10 +107,39 @@ inst-6pvpq-x9-ol8: Fri Jul 28 16:04:47 JST 2023 この際、管理対象ノードの **Oracle Linux** バージョンに応じて実行するコマンドが異なる点に注意します。 ```sh -$ pdsh -R ssh -w ^/home/opc/hostlist.txt sudo yum-config-manager --enable ol8_developer_EPEL # If Oracle Linux 8 -$ pdsh -R ssh -w ^/home/opc/hostlist.txt sudo yum-config-manager --enable ol7_developer_EPEL # If Oracle Linux 7.9 -$ pdsh -R ssh -w ^/home/opc/hostlist.txt sudo yum install -y pdsh -$ pdsh -R ssh -w ^/home/opc/hostlist.txt sudo yum install -y pdsh-rcmd-ssh # If Oracle Linux 8 +$ pdsh -w ^/home/opc/hostlist.txt sudo yum-config-manager --enable ol8_developer_EPEL # If Oracle Linux 8 +$ pdsh -w ^/home/opc/hostlist.txt sudo yum-config-manager --enable ol7_developer_EPEL # If Oracle Linux 7.9 +$ pdsh -w ^/home/opc/hostlist.txt sudo yum install -y pdsh +$ pdsh -w ^/home/opc/hostlist.txt sudo yum install -y pdsh-rcmd-ssh # If Oracle Linux 8 +``` + +次に、 **pdsh** で利用するグループを登録するため、グループ設定ファイルを作成します。 +このグループ設定ファイルは、事前にクラスタ管理ノードのopcユーザのホームディレクトリにファイル名 **hostlist.txt** で作成したホストリストファイルを基作成する、 **.dsh/group** ディレクトリに配置されるグループ名をファイル名とするテキストファイルです。 + +例えば以下のファイルを配置すると、全てのノードを含むグループ **all** 、inst-f5fra-x9-ol8とinst-3ktpe-x9-ol8を含むグループ **comp1**、及びinst-6pvpq-x9-ol8とinst-dixqy-x9-ol8を含むグループ **comp2** を利用できるようになります。 + +```sh +$ ~/.dsh/group/all +inst-f5fra-x9-ol8 +inst-3ktpe-x9-ol8 +inst-6pvpq-x9-ol8 +inst-dixqy-x9-ol8 +$ ~/.dsh/group/comp1 +inst-f5fra-x9-ol8 +inst-3ktpe-x9-ol8 +$ ~/.dsh/group/comp2 +inst-6pvpq-x9-ol8 +inst-dixqy-x9-ol8 +``` + +これらのグループは、以下のように **-g** オプションと共に管理対象ノードを指定する際に利用することが出来ます。 + +```sh +$ pdsh -g all date +inst-f5fra-x9-ol8: Fri Jul 28 16:04:47 JST 2023 +inst-dixqy-x9-ol8: Fri Jul 28 16:04:47 JST 2023 +inst-3ktpe-x9-ol8: Fri Jul 28 16:04:47 JST 2023 +inst-6pvpq-x9-ol8: Fri Jul 28 16:04:47 JST 2023 ``` *** @@ -118,7 +151,7 @@ $ pdsh -R ssh -w ^/home/opc/hostlist.txt sudo yum install -y pdsh-rcmd-ssh # If 管理対象ノードに対して複数のコマンドを一度の **pdsh** で実行する場合、これらのコマンド群を以下のように **'** （シングルクォート）で囲みます。 ```sh - $ pdsh -R ssh -w ^/home/opc/hostlist.txt 'date; hostname' + $ pdsh -g all 'date; hostname' inst-f5fra-x9-ol8: Fri Jul 28 16:56:45 JST 2023 inst-f5fra-x9-ol8: inst-f5fra-x9-ol8 inst-3ktpe-x9-ol8: Fri Jul 28 16:56:45 JST 2023 @@ -134,7 +167,7 @@ $ pdsh -R ssh -w ^/home/opc/hostlist.txt sudo yum install -y pdsh-rcmd-ssh # If このため、コマンド出力が複数行に亘る場合、異なる管理対象ノードの出力が以下のように入り乱れる状況が発生します。 ```sh - $ pdsh -R ssh -w ^/home/opc/hostlist.txt 'hostname; sleep 1; hostname' + $ pdsh -g all 'hostname; sleep 1; hostname' inst-3ktpe-x9-ol8: inst-3ktpe-x9-ol8 inst-f5fra-x9-ol8: inst-f5fra-x9-ol8 inst-dixqy-x9-ol8: inst-dixqy-x9-ol8 @@ -150,7 +183,7 @@ $ pdsh -R ssh -w ^/home/opc/hostlist.txt sudo yum install -y pdsh-rcmd-ssh # If なおデフォルトの並列実行数は、 **32** です。 ```sh - $ pdsh -R ssh -w ^/home/opc/hostlist.txt -f 1 'hostname; sleep 1; hostname' + $ pdsh -g all -f 1 'hostname; sleep 1; hostname' inst-f5fra-x9-ol8: inst-f5fra-x9-ol8 inst-f5fra-x9-ol8: inst-f5fra-x9-ol8 inst-3ktpe-x9-ol8: inst-3ktpe-x9-ol8 @@ -169,7 +202,7 @@ $ pdsh -R ssh -w ^/home/opc/hostlist.txt sudo yum install -y pdsh-rcmd-ssh # If [一度だけ **Ctrl-C** を入力した場合] ```sh - $ pdsh -R ssh -w ^./hostlist.txt sleep 60 + $ pdsh -g all sleep 60 ^Cpdsh@bastion: interrupt (one more within 1 sec to abort) pdsh@bastion: (^Z within 1 sec to cancel pending threads) pdsh@bastion: inst-f5fra-x9-ol8: command in progress @@ -181,7 +214,7 @@ $ pdsh -R ssh -w ^/home/opc/hostlist.txt sudo yum install -y pdsh-rcmd-ssh # If [二度連続して1秒以内に **Ctrl-C** を入力した場合] ```sh - $ pdsh -R ssh -w ^./hostlist.txt sleep 60 + $ pdsh -g all sleep 60 ^Cpdsh@bastion: interrupt (one more within 1 sec to abort) pdsh@bastion: (^Z within 1 sec to cancel pending threads) pdsh@bastion: inst-f5fra-x9-ol8: command in progress @@ -206,13 +239,13 @@ $ pdsh -R ssh -w ^/home/opc/hostlist.txt sudo yum install -y pdsh-rcmd-ssh # If RPMパッケージをインストールするdnfコマンドは、このための **-y** オプションを用意しており、以下のようにこの問題を回避することが出来ます。 ```sh - $ pdsh -R ssh -w ^/home/opc/hostlist.txt 'sudo dnf install -y httpd' + $ pdsh -g all 'sudo dnf install -y httpd' ``` また、以下のようにパイプを介して当該コマンドの標準入力に指示を渡すことで、これを回避することも出来ます。 ```sh - $ pdsh -R ssh -w ^/home/opc/hostlist.txt 'echo yes | sudo dnf install httpd' + $ pdsh -g all 'echo yes | sudo dnf install httpd' ``` @@ -231,13 +264,13 @@ $ pdsh -R ssh -w ^/home/opc/hostlist.txt sudo yum install -y pdsh-rcmd-ssh # If この場合、以下コマンドをクラスタ管理ノードのopcユーザで実行します。 ```sh -$ pdsh -R ssh -w ^/home/opc/hostlist.txt sudo dnf upgrade --refresh +$ pdsh -g all sudo dnf upgrade --refresh ``` なお **pdsh** の並列実行数は、 **-f** オプションで変更することが出来、デフォルトの32より大きなサイズのクラスタで全管理対象ノードに一斉にアップデートを行う場合は、以下のように実行します。 ```sh -$ pdsh -R ssh -w ^/home/opc/hostlist.txt -f 128 sudo dnf upgrade --refresh +$ pdsh -g all -f 128 sudo dnf upgrade --refresh ``` 但しこのOSアップデートのように、実行するコマンドからの出力が多くなる場合は、全ての管理対象ノードでコマンドが正常に完了したかどうかの判断が難しくなるため、以降で説明するような別の工夫が必要です。 @@ -250,7 +283,7 @@ $ pdsh -R ssh -w ^/home/opc/hostlist.txt -f 128 sudo dnf upgrade --refresh この場合、以下コマンドをクラスタ管理ノードのopcユーザで実行します。 ```sh -$ pdsh -R ssh -w ^/home/opc/hostlist.txt grep PRETTY /etc/os-release | dshbak -c +$ pdsh -g all grep PRETTY /etc/os-release | dshbak -c ---------------- inst-1phjn-x9-ol8,inst-iwhce-x9-ol8,inst-ot9zd-x9-ol8 ---------------- @@ -266,7 +299,7 @@ PRETTY_NAME="Oracle Linux Server 7.9" また、標準エラー出力を含めて管理対象ノードのコマンド出力を判別する場合、以下コマンドをクラスタ管理ノードのopcユーザで実行します。 ```sh -$ pdsh -R ssh -w ^/home/opc/hostlist.txt 'ls /tmp/hosts 2>&1' | dshbak -c +$ pdsh -g all 'ls /tmp/hosts 2>&1' | dshbak -c pdsh@bastion: inst-odzeg-x9-ol8: ssh exited with exit code 2 ---------------- inst-cnspy-x9-ol8,inst-dw5fd-x9-ol8,inst-slz8n-x9-ol8 @@ -283,7 +316,7 @@ ls: cannot access '/tmp/hosts': No such file or directory また、OSアップデートが正常に完了したかどうかを確認する場合等、コマンド出力を無視してコマンドのリターンコードのみを確認する場合、以下コマンドをクラスタ管理ノードのopcユーザで実行します。 ```sh -$ pdsh -R ssh -w ^/home/opc/hostlist.txt 'sudo dnf upgrade --refresh > /dev/null 2>&1; echo $?' | dshbak -c +$ pdsh -g all 'sudo dnf upgrade --refresh > /dev/null 2>&1; echo $?' | dshbak -c ---------------- inst-slz8n-x9-ol8 ---------------- @@ -299,7 +332,7 @@ inst-cnspy-x9-ol8,inst-dw5fd-x9-ol8,inst-odzeg-x9-ol8 また **dshbak** は、クラスタ管理ノードの指定したディレクトリに、管理対象ノードからの出力をそのホスト名をファイル名として格納する機能があり、この場合以下のように実行します。 ```sh -$ pdsh -R ssh -w ^/home/opc/hostlist.txt 'sudo dnf install -y mysql' | dshbak -d . +$ pdsh -g all 'sudo dnf install -y mysql' | dshbak -d . $ ls -l total 16 -rw-rw-r--. 1 opc opc 2504 Aug 1 11:56 inst-cnspy-x9-ol8 @@ -318,21 +351,21 @@ total 16 クラスタ管理ノードのファイル/etc/hostsを全ての管理対象ノードの/tmpにコピーするには、以下コマンドをクラスタ管理ノードのopcユーザで実行します。 ```sh -$ pdcp -R ssh -w ^/home/opc/hostlist.txt /etc/hosts /tmp +$ pdcp -g all /etc/hosts /tmp ``` なお **pdcp** は、sudoによる権限昇格を適用することが出来ないため、上記例で直接管理対象ノードの/etc/hostsファイルを上書きすることが出来ません。 この場合、以下のように **pdsh** コマンドを併用してこれを実現することが可能です。 ```sh -$ pdcp -R ssh -w ^/home/opc/hostlist.txt /etc/hosts /tmp -$ pdsh -R ssh -w ^/home/opc/hostlist.txt sudo cp /tmp/hosts /etc/ +$ pdcp -g all /etc/hosts /tmp +$ pdsh -g all sudo cp /tmp/hosts /etc/ ``` また、全ての管理対象ノードのファイル/etc/hostsをクラスタ管理ノードのカレントディレクトリにコピーするには、以下コマンドをクラスタ管理ノードのopcユーザで実行します。 ```sh -$ rpdcp -R ssh -w ^/home/opc/hostlist.txt /etc/hosts . +$ rpdcp -g all /etc/hosts . $ ls -l total 16 -rw-r--r--. 1 opc opc 230 Aug 1 15:49 hosts.inst-cnspy-x9-ol8 @@ -347,8 +380,8 @@ total 16 この場合、以下のように **pdsh** コマンドを併用してこれを実現することが可能です。 ```sh -$ pdsh -R ssh -w ^/home/opc/hostlist.txt 'sudo cp /var/log/messages /tmp/; sudo chmod 644 /tmp/messages' -$ rpdcp -R ssh -w ^/home/opc/hostlist.txt /tmp/messages . +$ pdsh -g all 'sudo cp /var/log/messages /tmp/; sudo chmod 644 /tmp/messages' +$ rpdcp -g all /tmp/messages . $ ls -la total 1964 drwxrwxr-x. 2 opc opc 142 Aug 1 15:57 . diff --git a/tutorials/_hpc/tech-knowhow/gpu-with-ubuntu.md b/tutorials/_hpc/tech-knowhow/gpu-with-ubuntu.md index 1c4e2db9fd..130663b839 100644 --- a/tutorials/_hpc/tech-knowhow/gpu-with-ubuntu.md +++ b/tutorials/_hpc/tech-knowhow/gpu-with-ubuntu.md @@ -107,8 +107,8 @@ header: $ distribution=$(. /etc/os-release;echo $ID$VERSION_ID | sed -e 's/\.//g') $ wget https://developer.download.nvidia.com/compute/cuda/repos/$distribution/x86_64/cuda-keyring_1.0-1_all.deb $ sudo dpkg -i cuda-keyring_1.0-1_all.deb - $ sudo apt-get update - $ sudo apt-get -y install cuda-drivers --no-install-recommends + $ sudo apt update + $ sudo apt -y install cuda-drivers --no-install-recommends ``` 2. 以下コマンドをGPUインスタンスのubuntuユーザで実行し、OSを再起動します。 @@ -129,10 +129,10 @@ header: $ distribution=$(. /etc/os-release;echo $ID$VERSION_ID | sed -e 's/\.//g') $ wget https://developer.download.nvidia.com/compute/cuda/repos/$distribution/x86_64/cuda-keyring_1.1-1_all.deb $ sudo dpkg -i cuda-keyring_1.1-1_all.deb - $ sudo apt-get update - $ sudo apt-get install -y cuda - $ sudo apt-get install -y nvidia-gds - $ sudo apt-get install -y cuda-drivers-fabricmanager + $ sudo apt update + $ sudo apt install -y cuda-11-8 + $ sudo apt install -y nvidia-gds-11-8 + $ sudo apt install -y cuda-drivers-fabricmanager $ sudo systemctl enable --now nvidia-fabricmanager ``` @@ -148,17 +148,22 @@ header: 本章は、 **CUDA Samples** で先のGPU関連ソフトウェアのインストールが正しく行われたかを確認します。 -1. 以下コマンドをGPUインスタンスのubuntuユーザで実行し、 **CUDA Samples** をインストールします。 +1. 以下Webサイトにサクセスし、CUDA 11.8用のCUDA SamplesのソースコードをGPUインスタンスのubuntuユーザのホームディレクトリにダウンロードします。 + + [https://github.com/NVIDIA/cuda-samples/archive/refs/tags/v11.8.zip](https://github.com/NVIDIA/cuda-samples/archive/refs/tags/v11.8.zip) + + +2. 以下コマンドをGPUインスタンスのubuntuユーザで実行し、 **CUDA Samples** をビルドします。 ```sh - $ sudo apt-get install -y cmake - $ echo "export PATH=/usr/local/cuda-12.2/bin\${PATH:+:\${PATH}}" | tee -a ~/.bash_profile + $ sudo apt install -y cmake + $ echo "export PATH=/usr/local/cuda-11.8/bin\${PATH:+:\${PATH}}" | tee -a ~/.bash_profile $ source ~/.bash_profile - $ git clone https://github.com/nvidia/cuda-samples - $ cd cuda-samples; make + $ tar -xvf ~/cuda-samples-11.8.tar.gz + $ cd cuda-samples-11.8; make ``` -2. 以下コマンドをGPUインスタンスのubuntuユーザで実行し、 **CUDA Samples** が正しく動作するかを確認します。 +3. 以下コマンドをGPUインスタンスのubuntuユーザで実行し、 **CUDA Samples** が正しく動作するかを確認します。 この時、各サンプルプログラムの最後に出力される"Result"行が"PASS"となっていることで、正常動作を確認します。 ```sh diff --git a/tutorials/_hpc/tech-knowhow/howto-create-cnenabled-osimage.md b/tutorials/_hpc/tech-knowhow/howto-create-cnenabled-osimage.md index dae878091d..df437ded5b 100644 --- a/tutorials/_hpc/tech-knowhow/howto-create-cnenabled-osimage.md +++ b/tutorials/_hpc/tech-knowhow/howto-create-cnenabled-osimage.md @@ -624,7 +624,7 @@ $ for i in `seq 0 3; seq 6 17`; do echo $i; mpirun -n 2 -N 1 -hostfile ~/hostlis ## 4-2. カスタム・イメージ取得 -本章は、 **[カスタム・イメージ](/ocitutorials/hpc/#5-6-カスタムイメージ)** 取得用インスタンスでカスタム・イメージを取得します。 +本章は、 **[カスタム・イメージ](/ocitutorials/hpc/#5-6-カスタムイメージ)** 取得用インスタンスで **カスタム・イメージ** を取得します。 **カスタム・イメージ** の取得は、当該インスタンスの以下 **インスタンスの詳細** ページで **他のアクション** プルダウンメニューから **カスタム・イメージの作成** メニューを選択し、 diff --git a/tutorials/_hpc/tech-knowhow/setup-slurm-cluster.md b/tutorials/_hpc/tech-knowhow/setup-slurm-cluster.md new file mode 100644 index 0000000000..33c9a7a91e --- /dev/null +++ b/tutorials/_hpc/tech-knowhow/setup-slurm-cluster.md @@ -0,0 +1,467 @@ +--- +title: "Slurmによるリソース管理・ジョブ管理システム構築方法" +excerpt: "HPC/GPUクラスタのリソース管理・ジョブ管理は、ジョブスケジューラを活用することでこれを効率的かつ柔軟に運用することが可能です。近年のHPC/機械学習ワークロードの大規模化は、MPI等を使ったノード間並列ジョブの重要性を増大させ、このような大規模ジョブを様々な運用ポリシーに沿って処理出来る機能をジョブスケジューラに求めています。オープンソースのジョブスケジューラSlurmは、この要求を満足出来る代表的なジョブスケジューラとして現在人気を集めています。本テクニカルTipsは、HPC/機械学習ワークロードの実行に最適なベアメタルインスタンスを高帯域・低遅延RDMAインターコネクトサービスのクラスタ・ネットワークで接続するHPC/GPUクラスタで、リソース管理・ジョブ管理システムをSlurmで構築する方法を解説します。" +order: "337" +layout: single +header: + teaser: "/hpc/tech-knowhow/setup-slurm-cluster/architecture_diagram.png" + overlay_image: "/hpc/tech-knowhow/setup-slurm-cluster/architecture_diagram.png" + overlay_filter: rgba(34, 66, 55, 0.7) +#link: https://community.oracle.com/tech/welcome/discussion/4474261/ +--- + +HPC/GPUクラスタのリソース管理・ジョブ管理は、ジョブスケジューラを活用することでこれを効率的かつ柔軟に運用することが可能です。近年のHPC/機械学習ワークロードの大規模化は、MPI等を使ったノード間並列ジョブの重要性を増大させ、このような大規模ジョブを様々な運用ポリシーに沿って処理出来る機能をジョブスケジューラに求めています。オープンソースのジョブスケジューラ **[Slurm](https://slurm.schedmd.com/)** は、この要求を満足出来る代表的なジョブスケジューラとして現在人気を集めています。 +本テクニカルTipsは、HPC/機械学習ワークロードの実行に最適なベアメタルインスタンスを高帯域・低遅延RDMAインターコネクトサービスの **[クラスタ・ネットワーク](/ocitutorials/hpc/#5-1-クラスタネットワーク)** で接続するHPC/GPUクラスタで、リソース管理・ジョブ管理システムを **Slurm** で構築する手順を解説します。 + +本テクニカルTipsは、次章で説明する前提システムが予めデプロイされており、このシステム上に **Slurm** 環境を構築する手順にフォーカスします。 +また **Slurm** のバージョンは、 **23.11.0** を使用します。 + +*** +# 0. 前提システム + +本章は、本テクニカルTipsで解説する **Slurm** 環境構築手順の前提となるシステムを解説します。 + +## 0-1. サブシステム構成 + +本システムは、以下4種類のサブシステムから構成されます。 + +| サブシステム | 使用するシェイプ | OS | ノード数 | 接続
サブネット | 役割 | +| :-------------: | :--------------------------------------------------------------------------: | :------------: | :----: | :------------------------------------------------------------: | ----------------------------------------------------------- | +| Slurm
マネージャ | 任意の仮想マシン
（※1） | Oracle Linux 8 | 1 | プライベート | **slurmctld** と **slurmdbd** が稼働するSlurm管理ノード | +| Slurm
クライアント | 任意の仮想マシン
（※1） | Oracle Linux 8 | 1 | パブリック | インターネットからログインするBastionノード
**Slurm** にジョブを投入するジョブサブミッションクライアント | +| 計算ノード | **[クラスタ・ネットワーク](/ocitutorials/hpc/#5-1-クラスタネットワーク)**
対応ベアメタルシェイプ
（※2） | Oracle Linux 8 | 2ノード以上 | プライベート
**クラスタ・ネットワーク** | **slurmd** が稼働するジョブ実行ノード | +| NFSサーバ | -
（※3） | -| 1 | プライベート | ジョブ投入ユーザのホームディレクトリをNFSでサービス（※4） | + +![画面ショット](architecture_diagram.png) + +※1）本テクニカルTipsは、 **VM.Optimized3.Flex** を使用します。 +※2）本テクニカルTipsは、 **BM.Optimized3.36** を使用します。 +※3）**ファイル・ストレージ** や **ブロック・ボリューム** NFSサーバ等、任意の手法で構築されたNFSサーバです。NFSでサービスするファイル共有ストレージ構築方法は、 **[OCI HPCテクニカルTips集](/ocitutorials/hpc/#3-oci-hpcテクニカルtips集)** の **[コストパフォーマンスの良いファイル共有ストレージ構築方法](/ocitutorials/hpc/tech-knowhow/howto-configure-sharedstorage/)** を参照ください。 +※4）NFSサーバがサービスするジョブ投入ユーザのホームディレクトリは、Slurmクライアントと計算ノードがNFSクライアントとなり、 **/mnt/nfs/home/user_name** でマウントします。 + +また、本テクニカルTipsでの各サブシステムのホスト名は、以下とします。 +以降の章では、これらのホスト名を自身の環境に置き換えて使用して下さい。 + +| サブシステム | ホスト名 | +| :---------: | :---------: | +| Slurmマネージャ | slurm-srv | +| Slurmクライアント | slurm-cli | +| 計算ノード | inst-qiuim-x9
inst-wxedu-x9 | + +## 0-2. セキュリティーポリシー + +各サブシステムのセキュリティポリシーは、接続するサブネットに応じて以下のように設定します。 + +| 接続するサブネット | firewalld | SElinux | +| :-------: | :----------------------------: | :----------------------: | +| パブリック | 仮想クラウド・ネットワークの
CIDRからのアクセスを全て許可 | NFS領域をホームディレクトリとして許可（※5） | +| プライベート | 停止 | 無効化 | + +※5）以下コマンドを対象となるノードのopcユーザで実行する。 + +```sh +$ setsebool -P use_nfs_home_dirs on +``` + +また、接続するサブネットのセキュリティー・リストも上記セキュリティーポリシーに合わせて設定します。 + +*** +# 1. Slurm環境構築 + +## 1-0. 概要 +本章は、既にデプロイされている **[前提システム](#0-前提システム)** で解説したシステム上で、 **Slurm** 環境を構築する手順を解説します。 + +**Slurm** のインストールは、多数の計算ノードに効率よくインストールする必要から、rpmbuildで作成するrpmパッケージによるインストール方法を採用します。 +また、 **Slurm** のプロセス間通信の認証に **[munge](https://dun.github.io/munge/)** 、ジョブのアカウンティング情報格納用RDBMSに **[MariaDB](https://mariadb.org/)** を使用します。 + +以上より、本章で解説する **Slurm** 環境構築は、以下の手順に沿って行います。 + +1. **munge** インストール・セットアップ +2. **MariaDB** インストール・セットアップ +3. **Slurm** rpmパッケージ作成 +4. **Slurm** rpmパッケージインストール・セットアップ +5. **Slurm** 設定ファイル作成 +6. **Slurm** サービス起動 + +なお、 **munge** 、 **MariaDB** 及び各 **Slurm** サービスは、以下のサブシステムにインストールします。 + +| | Slurmマネージャ | Slurmクライアント | 計算ノード | +| :----------------------: | :--------: | :---------: | :---: | +| **munge** | 〇 | 〇 | 〇 | +| **MariaDB** | 〇 | - | - | +| **slurmctld** | 〇 | - | - | +| **slurmdbd** | 〇 | - | - | +| **slurmd** | - | - | 〇 | +| **Slurm**
クライアントパッケージ | 〇 | 〇 | 〇 | + +## 1-1. munge インストール・セットアップ + +本章は、Slurmマネージャ、Slurmクライアント、及び計算ノードに **muge** をインストール・セットアップします。 + +1. 以下コマンドを対象となる全ノードのopcユーザで実行し、 **munge** プロセス起動ユーザを作成します。 + + ``` + $ sudo useradd -m -d /var/lib/munge -s /sbin/nologin -u 5001 munge + ``` + +2. 以下コマンドを対象となる全ノードのopcユーザで実行し、 **munge** をインストールします。 + + ```sh + $ sudo dnf install -y munge munge-libs + $ cd ~; wget https://rpmfind.net/linux/centos/8-stream/PowerTools/x86_64/os/Packages/munge-devel-0.5.13-2.el8.x86_64.rpm + $ sudo rpm -ivh ./munge-devel-0.5.13-2.el8.x86_64.rpm + ``` + +3. 以下コマンドをSlurmマネージャのopcユーザで実行し、 **munge** キーファイル（munge.key）を作成します。 + + ```sh + $ sudo /usr/sbin/create-munge-key + Generating a pseudo-random key using /dev/urandom completed. + $ sudo ls -la /etc/munge + total 16 + drwx------. 2 munge munge 23 Nov 24 14:34 . + drwxr-xr-x. 115 root root 8192 Nov 24 14:33 .. + -r--------. 1 munge munge 1024 Nov 24 14:34 munge.key + $ + ``` + +4. 先にSlurmマネージャで作成した **munge** キーファイルを、Slurmクライアントと計算ノードに同一パス・ファイル名でコピーします。 +この際、ファイルのオーナーとパーミッションがSlurmマネージャのキーファイルと同じとなるよう配慮します。 + +5. 以下コマンドを対象となる全ノードのopcユーザで実行し、 **munge** サービスを起動します。 + + ```sh + $ sudo systemctl enable --now munge.service + ``` + +6. 以下コマンドを対象となる全ノードのopcユーザで実行し、 **munge** が全てのノードで正常に動作していることを確認します。 + + ```sh + $ munge -n | unmunge | grep STATUS + STATUS: Success (0) + $ + ``` + +## 1-2. MariaDB インストール・セットアップ + +本章は、Slurmマネージャに **MariaDB** をインストール・セットアップします。 + +1. 以下コマンドをSlurmマネージャのopcユーザで実行し、 **MariaDB** をインストールします。 + + ``` + $ sudo dnf install -y mariadb-server mariadb-devel + ``` + +2. **MariaDB** の設定ファイル（mariadb-server.cnf）の[mysqld]フィールドに以下の記述を追加します。 + + ```sh + $ sudo diff /etc/my.cnf.d/mariadb-server.cnf_org /etc/my.cnf.d/mariadb-server.cnf + 20a21,22 + > innodb_buffer_pool_size=4096M + > innodb_lock_wait_timeout=900 + $ + ``` + +3. 以下コマンドをSlurmマネージャのopcユーザで実行し、 **MariaDB** サービスを起動します。 + + ```sh + $ sudo systemctl enable --now mariadb + ``` + + +4. **MariaDB** のデータベースに以下の登録を行うため、 + + - データベース（slurm_acct_db） + - ユーザ（slurm） + - ユーザ（slurm）のパスワード + - ユーザ（slurm）に対するデータベース（slurm_acct_db）への全権限付与 + + 以下コマンドをSlurmマネージャのopcユーザで実行します。 + + ```sh + $ sudo mysql + MariaDB [(none)]> create database slurm_acct_db; + MariaDB [(none)]> create user 'slurm'@'localhost' identified by 'SLURM'; + MariaDB [(none)]> set password for slurm@localhost = password('passcord'); + MariaDB [(none)]> grant all on slurm_acct_db.* TO 'slurm'@'localhost'; + MariaDB [(none)]> FLUSH PRIVILEGES; + MariaDB [(none)]> Ctrl-c + $ + ``` + + なお、コマンド中の **passcord** は、自身の設定するパスワードに置き換えます。 + +5. 以下コマンドをSlurmマネージャのopcユーザで実行し、先に登録したデータベースとユーザが正しく登録されていることを確認します。 + + ```sh + $ mysql --user=slurm --password=passcord slurm_acct_db -e 'show databases;' + +--------------------+ + | Database | + +--------------------+ + | information_schema | + | slurm_acct_db | + +--------------------+ + $ + ``` + + なお、コマンド中の **passcord** は、自身の設定したパスワードに置き換えます。 + +## 1-3. Slurm rpmパッケージ作成 + +本章は、Slurmマネージャでrpmパッケージを作成します。 + +1. 以下コマンドをSlurmマネージャのopcユーザで実行し、 **Slurm** の前提ソフトウェアをインストールします。 + + ``` + $ sudo dnf install -y rpm-build pam-devel perl readline-devel + ``` + +2. rpmbuild設定ファイル（.rpmmacros）を以下の通り作成し、以下コマンドをSlurmマネージャのopcユーザで実行し、 **Slurm** rpmパッケージを作成します。 + + ``` + $ cd ~; cat ./.rpmmacros + %_prefix /opt/slurm + %_slurm_sysconfdir %{_prefix}/etc + $ wget https://download.schedmd.com/slurm/slurm-23.11.0-0rc1.tar.bz2 + $ rpmbuild -ta ./slurm-23.11.0-0rc1.tar.bz2 + ``` + + 作成されたパッケージは、以下のディレクトリに配置されるので、これらの全ファイルを他のサブシステムにコピーします。 + + ``` + $ ls -l rpmbuild/RPMS/x86_64/ + total 22308 + -rw-rw-r--. 1 opc opc 17898600 Nov 24 16:45 slurm-23.11.0-0rc1.el8.x86_64.rpm + -rw-rw-r--. 1 opc opc 21240 Nov 24 16:45 slurm-contribs-23.11.0-0rc1.el8.x86_64.rpm + -rw-rw-r--. 1 opc opc 86720 Nov 24 16:45 slurm-devel-23.11.0-0rc1.el8.x86_64.rpm + -rw-rw-r--. 1 opc opc 13456 Nov 24 16:45 slurm-example-configs-23.11.0-0rc1.el8.x86_64.rpm + -rw-rw-r--. 1 opc opc 166240 Nov 24 16:45 slurm-libpmi-23.11.0-0rc1.el8.x86_64.rpm + -rw-rw-r--. 1 opc opc 12968 Nov 24 16:45 slurm-openlava-23.11.0-0rc1.el8.x86_64.rpm + -rw-rw-r--. 1 opc opc 172948 Nov 24 16:45 slurm-pam_slurm-23.11.0-0rc1.el8.x86_64.rpm + -rw-rw-r--. 1 opc opc 813200 Nov 24 16:45 slurm-perlapi-23.11.0-0rc1.el8.x86_64.rpm + -rw-rw-r--. 1 opc opc 99480 Nov 24 16:45 slurm-sackd-23.11.0-0rc1.el8.x86_64.rpm + -rw-rw-r--. 1 opc opc 1657772 Nov 24 16:45 slurm-slurmctld-23.11.0-0rc1.el8.x86_64.rpm + -rw-rw-r--. 1 opc opc 821884 Nov 24 16:45 slurm-slurmd-23.11.0-0rc1.el8.x86_64.rpm + -rw-rw-r--. 1 opc opc 913224 Nov 24 16:45 slurm-slurmdbd-23.11.0-0rc1.el8.x86_64.rpm + -rw-rw-r--. 1 opc opc 136256 Nov 24 16:45 slurm-torque-23.11.0-0rc1.el8.x86_64.rpm + $ + ``` + +## 1-4. Slurm rpmパッケージインストール・セットアップ + + +本章は、先に作成した **Slurm** rpmパッケージを各サブシステムにインストールし、必要なセットアップ作業を実施します。 + +1. 以下コマンドをSlurmマネージャのopcユーザで実行し、Slurmマネージャに必要な **Slurm** rpmパッケージのインストール・セットアップを行います。 + + ``` + $ cd ~/rpmbuild/RPMS/x86_64 + $ sudo rpm -ivh ./slurm-23.11.0-0rc1.el8.x86_64.rpm ./slurm-slurmctld-23.11.0-0rc1.el8.x86_64.rpm ./slurm-slurmdbd-23.11.0-0rc1.el8.x86_64.rpm ./slurm-perlapi-23.11.0-0rc1.el8.x86_64.rpm + $ sudo useradd -m -d /var/lib/slurm -s /bin/bash -u 5000 slurm + $ sudo mkdir /var/spool/slurmctld; sudo chown slurm:slurm /var/spool/slurmctld + $ sudo mkdir /var/spool/slurmd; sudo chown slurm:slurm /var/spool/slurmd + $ sudo mkdir /var/log/slurm; sudo chown slurm:slurm /var/log/slurm + $ sudo mkdir /opt/slurm/etc; sudo chown slurm:slurm /opt/slurm/etc + $ sudo su - slurm + $ echo "export PATH=\$PATH:/opt/slurm/sbin:/opt/slurm/bin" | tee -a ~/.bash_profile + $ echo "export MANPATH=\$MANPATH:/opt/slurm/share/man" | tee -a ~/.bash_profile + $ source ~/.bash_profile + ``` + +2. 計算ノードの **Slurm** rpmパッケージをコピーしたディレクトリで以下コマンドをopcユーザで実行し、計算ノードに必要な **Slurm** rpmパッケージのインストール・セットアップを行います。 + + ``` + $ sudo dnf install -y mariadb-devel + $ sudo rpm -ivh ./slurm-23.11.0-0rc1.el8.x86_64.rpm ./slurm-slurmd-23.11.0-0rc1.el8.x86_64.rpm ./slurm-perlapi-23.11.0-0rc1.el8.x86_64.rpm + $ sudo useradd -m -d /var/lib/slurm -s /bin/bash -u 5000 slurm + $ sudo mkdir /var/spool/slurmd; sudo chown slurm:slurm /var/spool/slurmd + $ sudo mkdir /var/log/slurm; sudo chown slurm:slurm /var/log/slurm + $ sudo mkdir /opt/slurm/etc; sudo chown slurm:slurm /opt/slurm/etc + ``` + +3. Slurmクライアントの **Slurm** rpmパッケージをコピーしたディレクトリで以下コマンドをopcユーザで実行し、Slurmクライアントに必要な **Slurm** rpmパッケージのインストール・セットアップを行います。 + + ``` + $ sudo dnf install -y mariadb-devel + $ sudo rpm -ivh ./slurm-23.11.0-0rc1.el8.x86_64.rpm ./slurm-perlapi-23.11.0-0rc1.el8.x86_64.rpm + $ sudo useradd -m -d /var/lib/slurm -s /bin/bash -u 5000 slurm + $ sudo mkdir /opt/slurm/etc; sudo chown slurm:slurm /opt/slurm/etc + $ echo '* soft memlock unlimited' | sudo tee -a /etc/security/limits.conf + $ echo '* hard memlock unlimited' | sudo tee -a /etc/security/limits.conf + ``` + +## 1-5. Slurm設定ファイル作成 + +本章は、以下2種類の **Slurm** 設定ファイルを作成し、これらを各サブシステムの/opt/slurm/etcディレクトリに配布します。 +この際、これらファイルのオーナーユーザ・オーナーグループをslurmとします。 +また、slurmdbd.confのパーミッションを600に設定します。 + +- slurm.conf（全てのサブシステム） +- slurmdbd.conf（Slurmマネージャ） + +[slurm.conf] +```sh +ClusterName=sltest +SlurmctldHost=slurm-srv +AuthType=auth/munge +PluginDir=/opt/slurm/lib64/slurm +SchedulerType=sched/backfill +SelectType=select/linear +SlurmUser=slurm +SlurmctldPort=7002 +SlurmctldTimeout=300 +SlurmdPort=7003 +SlurmdSpoolDir=/var/spool/slurmd +SlurmdTimeout=300 +SlurmctldLogFile=/var/log/slurm/slurmctld.log +SlurmdLogFile=/var/log/slurm/slurmd.log +SlurmdDebug=3 +StateSaveLocation=/var/spool/slurmd +SwitchType=switch/none +AccountingStorageType=accounting_storage/slurmdbd +AccountingStorageHost=slurm-srv +AccountingStoragePort=7004 +NodeName=DEFAULT CPUs=72 Boards=1 SocketsPerBoard=2 CoresPerSocket=18 ThreadsPerCore=2 RealMemory=500000 TmpDisk=10000 State=UNKNOWN +NodeName=inst-qiuim-x9,inst-wxedu-x9 +PartitionName=sltest Nodes=ALL Default=YES MaxTime=INFINITE State=UP +``` + +なお、 **SlurmctldHost** 、 **AccountingStorageHost** 、及び **NodeName** の設定値は、自身の環境に合わせて修正します。 + +[slurmdbd.conf] +```sh +ArchiveEvents=yes +ArchiveJobs=yes +ArchiveResvs=yes +ArchiveSteps=no +ArchiveSuspend=no +ArchiveTXN=no +ArchiveUsage=no +AuthType=auth/munge +AuthInfo=/var/run/munge/munge.socket.2 +DbdHost=slurm-srv +DbdPort=7004 +DebugLevel=info +PurgeEventAfter=1month +PurgeJobAfter=12month +PurgeResvAfter=1month +PurgeStepAfter=1month +PurgeSuspendAfter=1month +PurgeTXNAfter=12month +PurgeUsageAfter=24month +LogFile=/var/log/slurm/slurmdbd.log +PidFile=/var/run/slurmdbd/slurmdbd.pid +SlurmUser=slurm +StorageType=accounting_storage/mysql +StorageUser=slurm +StoragePass=passcord +StorageLoc=slurm_acct_db +``` + +なお、 **DbdHost** と **StoragePass** の設定値は、自身の環境に合わせて修正します。 + +## 1-6. Slurmサービス起動 + +本章は、 **Slurm** の各systemdサービスを対象のサブシステムで起動します。 + +1. 以下コマンドを計算ノードのopcユーザで実行し、slurmdを起動します。 + + ``` + $ sudo systemctl enable --now slurmd + ``` + +2. 以下コマンドをSlurmマネージャのopcユーザで実行し、slurmdbdとslurmctldをこの順番で起動します。 + + ``` + $ sudo systemctl enable --now slurmdbd + $ sudo systemctl start slurmctld + ``` + slurmctldは、計算ノードのslurmd起動完了後に起動するため、手動起動を前提とします。 + +*** +# 2. Slurm稼働確認 + +本章は、構築した **Slurm** 環境を稼働確認するため、ホームディレクトリをNFSで共有するジョブ投入ユーザで計算ノードの **[クラスタネットワーキングイメージ](/ocitutorials/hpc/#5-13-クラスタネットワーキングイメージ)** に含まれるOpenMPIと **[Intel MPI Benchmark](https://www.intel.com/content/www/us/en/developer/articles/technical/intel-mpi-benchmarks.html)** を使用するバッチジョブを投入し、その結果を確認します。 + +1. 構築した **Slurm** 環境は、MPIジョブを投入する前提としてSlurmクライアントと全計算ノード間でパスフレーズ無しでSSHアクセス出来る必要があるため、以下コマンドをSlurmクライアントのジョブ投入ユーザで実行します。 +なお、計算ノードの全ホスト名を記載したホストリストファイルを、当該ユーザのホームディレクトリ直下にhostlist.txtとして予め作成しておきます。 + + ```sh + $ cd ~; mkdir .ssh; chmod 700 .ssh + $ ssh-keygen -t rsa -N "" -f .ssh/id_rsa + $ cd .ssh; cat ./id_rsa.pub >> ./authorized_keys; chmod 600 ./authorized_keys + $ for hname in `cat ~/hostlist.txt`; do echo $hname; ssh -oStrictHostKeyChecking=accept-new $hname :; done + ``` + +2. 以下コマンドをSlurmクライアントのジョブ投入ユーザで実行し、 **Slurm** 関連の環境変数を設定します。 + + ```sh + $ echo "export PATH=\$PATH:/opt/slurm/sbin:/opt/slurm/bin" | tee -a ~/.bash_profile + $ echo "export MANPATH=\$MANPATH:/opt/slurm/share/man" | tee -a ~/.bash_profile + $ source ~/.bash_profile + ``` + +3. **Intel MPI Benchmark** を実行する以下のジョブスクリプトをジョブ投入ユーザのホームディレクトリ直下にsubmit.shとして作成します。 + + ```sh + #!/bin/bash + #SBATCH -p sltest + #SBATCH -n 2 + #SBATCH -N 2 + #SBATCH -J ping_ping + #SBATCH -o stdout.%J + #SBATCH -e stderr.%J + source /usr/mpi/gcc/openmpi-4.1.2a1/bin/mpivars.sh + export UCX_NET_DEVICES=mlx5_2:1 + mpirun /usr/mpi/gcc/openmpi-4.1.2a1/tests/imb/IMB-MPI1 -msglog 27:28 PingPong + ``` + +4. 以下コマンドをSlurmクライアントのジョブ投入ユーザで実行し、バッチジョブの投入とその結果を確認します。 + + ```sh + $ cd ~; sbatch submit.sh + Submitted batch job 1 + $ cat stdout.1 + #------------------------------------------------------------ + # Intel (R) MPI Benchmarks 2018, MPI-1 part + #------------------------------------------------------------ + # Date : Tue Nov 28 04:29:57 2023 + # Machine : x86_64 + # System : Linux + # Release : 4.18.0-425.13.1.el8_7.x86_64 + # Version : #1 SMP Tue Feb 21 15:09:05 PST 2023 + # MPI Version : 3.1 + # MPI Thread Environment: + + + # Calling sequence was: + + # /usr/mpi/gcc/openmpi-4.1.2a1/tests/imb/IMB-MPI1 -msglog 27:28 PingPong + + # Minimum message length in bytes: 0 + # Maximum message length in bytes: 268435456 + # + # MPI_Datatype : MPI_BYTE + # MPI_Datatype for reductions : MPI_FLOAT + # MPI_Op : MPI_SUM + # + # + + # List of Benchmarks to run: + + # PingPong + + #--------------------------------------------------- + # Benchmarking PingPong + # #processes = 2 + #--------------------------------------------------- + #bytes #repetitions t[usec] Mbytes/sec + 0 1000 1.66 0.00 + 134217728 1 10973.06 12231.57 + 268435456 1 21934.76 12237.90 + + + # All processes entering MPI_Finalize + + $ + ``` diff --git a/tutorials/_hpc/tech-knowhow/setup-slurm-cluster/architecture_diagram.png b/tutorials/_hpc/tech-knowhow/setup-slurm-cluster/architecture_diagram.png new file mode 100644 index 0000000000..d04f95b25a Binary files /dev/null and b/tutorials/_hpc/tech-knowhow/setup-slurm-cluster/architecture_diagram.png differ diff --git a/tutorials/_opensearch/search-application-for-beginners.md b/tutorials/_opensearch/search-application-for-beginners.md index 171dc5b34c..b724023bfa 100644 --- a/tutorials/_opensearch/search-application-for-beginners.md +++ b/tutorials/_opensearch/search-application-for-beginners.md @@ -48,7 +48,14 @@ OpenSearch 一覧画面で「**クラスタの作成**」ボタンをクリッ クラスタの**名前**を指定し、**クラスタを作成するコンパートメント**を選択して、「**次**」をクリックします。 -![config cluster](1-3_config_cluster.png "config cluster") +![config cluster](1-3_cluster_config.png "cluster config") + +セキュリティの構成で、ユーザー名、パスワードを以下のように入力します。 + +1. ユーザー名: `guest` +2. パスワード: `Welcome#123` + +![cluster security config](1-3_cluster_security_config.png "cluster security config") ノード最適化オプションで「**開発**」オプションを選択します。「**次**」をクリックします。 @@ -156,7 +163,7 @@ OpenSearch 一覧画面で「**クラスタの作成**」ボタンをクリッ **ローカル・マシン**から**VM インスタンス**に接続したら、次のいずれかのコマンドを実行して接続をテストします。 ```bash -curl https://:9200 +curl -u guest:Wellcome#123 https://:9200 ``` エンドポイントへの接続が成功すると、次のようなレスポンスが返されます: @@ -191,13 +198,13 @@ ssh -C -v -t -L 127.0.0.1:5601::5601 -L 127.0. \を VM インスタンスのパブリック IP アドレスに置き換えます。\を、インスタンスへの接続に使用する秘密キーへのパスに置き換えます。これらの値とその検索方法の詳細は、インスタンスへの接続を参照してください。 - ローカル・マシンの Hosts ファイルに下記内容を追加します。 - + ```bash 127.0.0.1 ``` - ローカル・マシンが Mac の場合、Hosts ファイルの位置は`/etc/hosts`です。Hosts ファイルを更新した後は、下記のコマンドを実行してローカル DNS を更新します。 - + ```bash sudo killall -HUP mDNSResponder ``` @@ -206,6 +213,10 @@ ssh -C -v -t -L 127.0.0.1:5601::5601 -L 127.0. - ローカル・マシンのブラウザから、`https://:5601`を開いて OpenSearch ダッシュボードにアクセスします。 +作成したユーザー名、パスワードを入力します。 + +![open opensearch dashborad](2-3-3_username_password.png "open opensearch dashborad") + ![open opensearch dashborad](2-3-3_open_dashboard.png "open opensearch dashborad") ## 3. データセットのアップロード @@ -252,25 +263,31 @@ GET accounts/_search @RequestScoped public class AccountResource { private String openSearchEndpoint; + private final CredentialsProvider credentialsProvider; @Inject - public AccountResource(@ConfigProperty(name = "oci.opensearch.api.endpoint") String openSearchEndpoint) { - Object endpoint = System.getProperty("OPENSEARCH_ENDPOINT"); - if(endpoint != null){ - this.openSearchEndpoint = (String) endpoint; - }else{ - this.openSearchEndpoint = openSearchEndpoint; - } + public AccountResource(@ConfigProperty(name = "oci.opensearch.api.endpoint") String openSearchEndpoint, + @ConfigProperty(name = "oci.opensearch.credential.username") String username, + @ConfigProperty(name = "oci.opensearch.credential.password") String password) { + this.openSearchEndpoint = openSearchEndpoint; + credentialsProvider = new BasicCredentialsProvider(); + credentialsProvider.setCredentials(AuthScope.ANY, + new UsernamePasswordCredentials(username, password)); } @Path("/search/{inputTerm}") @GET @Produces(MediaType.APPLICATION_JSON) - public Response search(@PathParam("inputTerm") String inputTerm){ + public Response search(@PathParam("inputTerm") String inputTerm) { // Create a client. - RestClientBuilder builder = RestClient.builder(HttpHost.create(openSearchEndpoint)); - - try(RestHighLevelClient client = new RestHighLevelClient(builder)){ + RestClientBuilder builder = RestClient.builder(HttpHost.create(openSearchEndpoint)) + .setHttpClientConfigCallback(new HttpClientConfigCallback() { + @Override + public HttpAsyncClientBuilder customizeHttpClient(HttpAsyncClientBuilder httpClientBuilder) { + return httpClientBuilder.setDefaultCredentialsProvider(credentialsProvider); + } + }); + try (RestHighLevelClient client = new RestHighLevelClient(builder)) { // Build search request SearchRequest searchRequest = new SearchRequest("accounts"); @@ -315,42 +332,42 @@ public class AccountResource { 上記で作成したアプリケーションは[こちら](https://github.com/oracle-japan/OCI_OpenSearch_Handson_App)をご参照ください。 -**アプリケーションのデプロイメント** +**アプリケーションのデプロイメント** 1. ローカル・マシンから VM インスタンスに接続します。 2. 下記のコマンドを実行して、ファイアウォールにポート「8080」を追加します。 - ```bash - sudo firewall-cmd --zone=public --add-port=8080/tcp --permanent - sudo firewall-cmd --reload - ``` + ```bash + sudo firewall-cmd --zone=public --add-port=8080/tcp --permanent + sudo firewall-cmd --reload + ``` 3. 下記のコマンドを実行して、git と docker をインストールします。 - ```bash - sudo yum install git - sudo yum install docker - ``` + ```bash + sudo yum install git + sudo yum install docker + ``` 4. 下記のコマンドを実行して、作成したアプリケーションをクローンします。 - ```bash - git clone https://github.com/oracle-japan/OCI_OpenSearch_Handson_App.git - ``` + ```bash + git clone https://github.com/oracle-japan/OCI_OpenSearch_Handson_App.git + ``` 5. アプリケーションの Docker イメージを作成します。 - ```bash - cd OCI_OpenSearch_Handson_App - docker build . -t os_app - ``` + ```bash + cd OCI_OpenSearch_Handson_App + docker build . -t os_app + ``` 6. 下記のコマンドを実行して、アプリケーションをデプロイします。 - ```bash - nohup docker run -p 8080:8080 -e="OPENSEARCH_ENDPOINT=" localhost/os_app & - ``` + ```bash + nohup docker run -p 8080:8080 -e="OPENSEARCH_ENDPOINT=" localhost/os_app & + ``` \を、クラスタの OpenSearch ダッシュボードの API エンドポイントに置き換えます。 diff --git a/tutorials/_opensearch/search-application-for-beginners/1-3_cluster_config.png b/tutorials/_opensearch/search-application-for-beginners/1-3_cluster_config.png index 33ac7db84f..29df2e9499 100644 Binary files a/tutorials/_opensearch/search-application-for-beginners/1-3_cluster_config.png and b/tutorials/_opensearch/search-application-for-beginners/1-3_cluster_config.png differ diff --git a/tutorials/_opensearch/search-application-for-beginners/1-3_cluster_security_config.png b/tutorials/_opensearch/search-application-for-beginners/1-3_cluster_security_config.png new file mode 100644 index 0000000000..133923a924 Binary files /dev/null and b/tutorials/_opensearch/search-application-for-beginners/1-3_cluster_security_config.png differ diff --git a/tutorials/_opensearch/search-application-for-beginners/2-3-3_username_password.png b/tutorials/_opensearch/search-application-for-beginners/2-3-3_username_password.png new file mode 100644 index 0000000000..7d3a04aaa3 Binary files /dev/null and b/tutorials/_opensearch/search-application-for-beginners/2-3-3_username_password.png differ