Canonicalによるハイパフォーマンスコンピューティングのレシピ

by Canonical on 14 March 2024

ハイパフォーマンスコンピューティング（HPC）とは、簡単に言えば速度と規模です。しかし実際には非常に複雑で、簡単には実現しません。普通の自動車からスーパーカーやハイパーカーに乗り換えるのと少し似ています。時速300kmのときに遭遇する困難や問題は、時速100kmのときと大きく異なります。まったく新しい制約が出現するのです。

さらに、HPCに同じ構成は2つとありません。どの組織も、それぞれのワークロードと要件に合わせて独自にカスタマイズされた方法でHPCを実行します。とはいえ、基本的なコンポーネントと機能は、この分野で使用されるツールやテクノロジー全般に共通です。今回は、これらの「材料」を最適にブレンドし、Canonical風味のHPC構成を作るレシピをご紹介したいと思います。これが絶対的な真実あるいは唯一の優れた方法だとは考えていませんが、実用的で実際的、かつ効率的な方法であると確信しています。

HPCをHPCたらしめるもの

ハードウェアレベルで言えば、HPCの能力は通常、比較的安価な複数の市販マシン上で別々のデータチャンクを並列実行することで得られます。安価というのは、同水準のパフォーマンスを提供する単一のシステム（あれば）のコストと比べての話です。GPUモジュールを使用すると従来のCPUよりデータクランチングを大幅に高速化できるため、HPCの構成には処理用のグラフィックスカードがよく使用されます。

並列実行には、HPC構成内のいずれかのポイントでリソース不足に陥ることがないよう、高速処理と十分なオーケストレーションが必要です。そのために、HPCの構成では高速ネットワークと高速ストレージも組み込み、従来の高速要素（CPU/GPU、メモリ）と低速要素（I/Oバス）によってもたらされるデータ伝送速度と処理速度のギャップを最小限に抑える（または解消する）ことになります。

ソフトウェアレベルでは、オーケストレーションのために、HPCの構成（コンピュートノードのクラスター）全体にわたってデータを処理、ディスパッチ、および管理できるインテリジェントなスケジューラーが必要です。通常、データを扱うエンジニアや科学者には、ワークロードをHPC環境へ送り込むためのプログラムも必要です。そのために、ジョブをディスパッチするためのコンソールと、ジョブを準備するツールやユーティリティが必要になります。パッケージマネージャーによって一元管理できれば理想的でしょう。

レシピの形でHPCを要約すれば、CPU/GPU、高速ストレージ、高速ネットワーク、スケジューラー、パッケージマネージャー、および管理コンソールを備えた一連のマシンということになります。次に、HPCの分野でCanonicalに何ができるかを説明しましょう。

Jujuによるハードウェアのデプロイ

Jujuについて聞いたことがない人のために簡単に説明すると、Jujuは、ソフトウェアオペレーター用のオープンソースのオーケストレーションエンジンであり、あらゆるインフラストラクチャ上で、任意の規模でアプリケーションのデプロイ、統合、ライフサイクル管理を可能にします。

データセンター、クラウド、HPCセットアップのトポロジー構築に長い時間を費やすのではなく、Jujuに環境を構築させ、開発者は実行したいワークロードそのものに時間をかけるというアイデアです。もちろん近道はなく、Jujuは「ITレスのIT」を実現する魔法のソリューションでもありません。しかし、場合によっては、企業や組織が環境のセットアップという当初のハードルを乗り越えるのに役立ちます。

Jujuのデプロイと運用動作の組み合わせはcharmという形を取ります。これは、アプリケーションのライフサイクルのあらゆる側面を自動化するオペレーター、つまり再使用可能なソフトウェアパッケージにカプセル化されたビジネスロジックです。言い換えればcharmとは、設定とアプリケーションのビジネスロジック（デプロイ後の動作の仕方）の両方をバンドルしたパッケージです。したがってHPCの場合、Charmed HPCソリューションもありえます。このソリューションには、デプロイ用のコンポーネントと、完全に自己完結型の独立したHPC構成を実行するために必要なソフトウェア材料が含まれます。

charmとsnapのセット

ハードウェアのハードルを乗り越えたら、ソフトウェア部分が楽になるはずです。Jujuは、HPCワークロードの実行に必要なものをすべて備えたUbuntuシステムをプロビジョニングします。

Spackはパッケージマネージャーとなります（年末向けの記事で説明したとおり）。これにより、HPCのユーザーは約7,000の学術用プログラムやユーティリティを簡単に検索してインストールできます。次に、エンジニアや科学者がワークロードをディスパッチする準備ができたら、Open OnDemandユーティリティでHPCクラスターに接続します。

その後、SLURMがタスクを処理し、クラスター全体でタスクのスケジューリングを行います。Canonicalは、すべての接点でソフトウェアとハードウェアの最適化を目指しています。このためHPCクラスター上でさまざまなプロセスを実行しても、エンドユーザーはパフォーマンス、電力利用、セキュリティと安定性の向上を得られます。いずれ、Canonicalがこれをどのように達成しようとしているかを詳しく説明するとともに、ベンチマークや調整の最新情報を提供する予定です。

環境のモニタリングに役立つ可観測性コンポーネントも提供されますが、まだ名前はありません。このような構成が機能するには、LDAPおよびNFSとの強固な統合が必須だと考えているため、それらにも時間をかけます。Cephの統合は、Canonicalのレシピにおけるもう1つのコンポーネントです。

規則ではなく推奨事項

全体として、これはCanonicalの「料理」です。しかし、あらゆる料理と同様、味付けが多いに越したことはありません。徐々に詳細をご説明しますが、ここで言及していない追加ソフトウェアコンポーネントが含まれる可能性もあります。とはいえCanonicalはHPCソリューションを柔軟なモジュール型にしたいと考えており、ユーザーに具体的な要件がある場合でも閉め出すことはありません。

ソリューションの構想と構築は始まったばかりです。最新情報に引き続きご注目ください。とりあえずニュースレターを購読していただければ幸いです。ご不明な点は直接お問い合わせください。

ではまた。次回の記事をお楽しみに。