Azure CycleCloud で HPC クラスターを計画・サイズ化

Azure CycleCloudでクラスタを作成する前に、クラスタの構造やサイズを計画してください。 スケジューラ、仮想マシン(VM)の種類、クラスタのスケール、データの保存や移動方法など、事前に良い計画判断を下すことで、クラスタのパフォーマンスや運用コストを決定できます。

この記事では、CycleCloudでHPCクラスターを計画する際に行うべき主な意思決定について説明します。 これは CycleCloudのクラスタやノードを補完し、クラスタ、ノード、ノードアレイの説明や、テンプレートからクラスタを構築する方法を説明するCreate a New Clusterを補完します。

CycleCloudがあなたの業務量に合っているか確認してください

特定のHPCスケジューラを運用したり、クラスタのトポロジーやソフトウェアスタックをカスタマイズしたり、既存のオンプレミスのワークフローと密接に連携させる必要がある場合にCycleCloudを活用してください。 カスタムクラスターのサイズを決める前に、以下の代替案を検討してください:

• ネットワーク、ストレージ、アクセスコンポーネントがサブスクリプションにプロビジョニングされたすぐに展開可能なSlurm環境を望むなら、Azure CycleCloud Workspace for Slurmを選択してください。
• Azureでスケジューリング・アズ・ア・サービスを提供したい場合、Azure Batchを選択してください。アプリケーションはバッチプール、ジョブ、タスクを利用できます。

CycleCloudが適切な運用モデルであれば、以下のセクションを使って計画ベースラインを作成してください。 展開前にスケジューラー、VM、スケール、クォータ、リージョン、ストレージ、ネットワーク、コストの決定を記録し、代表的なワークロードで検証してください。

スケジューラーを選ぶ

CycleCloudはスケジューラーに依存しません。 ほとんどのHPCチームがすでに使っているスケジューラの組み込みサポートがあり、それぞれにオートスケーリング機能が追加されています:

• SLURM
• PBSプロフェッショナル
• IBM スペクトラム LSF
• アルタイル・グリッド・エンジン
• HTCondor

既存のワークフローやジョブスクリプトに合ったスケジューラを選び、最小限の変更でワークロードをAzureに移行できます。 もし組織が組み込みリストにないスケジューラを使っているなら、CycleCloudのオートスケーリングAPIと連携できます。 詳細は CycleCloudのスケジューリングをご覧ください。

VMファミリーとサイズを選択する

VMファミリーやコンピュートノードのサイズがパフォーマンスとコストに最も大きな影響を与えます。 VMをワークロードの特性に合わせてマッチングしてください:

• ノード間でデータを交換する密結合(MPI)ワークロードは、HPC VMサイズのような低遅延のInfiniBandインターコネクトを備えたHPC最適化VMの恩恵を受けます。
• AIトレーニングやレンダリングなどのGPUアクセラレーションワークロードは、GPU最適化されたVMサイズを使用します。
• 恥ずかしいほど並列型やスループット型ワークロードは、タスクが独立して動作し、汎用または計算最適化型のVMを使用でき、専用のインターコネクトを必要としません。

VMオプションの完全な比較については、「Azureの仮想マシンのサイズ」を参照してください。

ノードアレイは複数の仮想マシンスケールセットにまたがることができるため、同じ役割に対して異なるサイズやファミリーのVMを提供できます。 この柔軟性は、希望するVMサイズが地域内の容量に制限がある場合に役立ちます。 詳細については、 CycleCloudのクラスタとノードをご覧ください。

クラスタのサイズを決め、自動スケーリングの計画を立てます

CycleCloudはスケジューラにキューキューされた作業数に基づいて自動的に計算ノード数を拡大するため、固定されたクラスタサイズを推測する必要はありません。 代わりに、以下の境界線を計画してください。

• 最大サイズ。 クラスタ作成フォームは、クラスタが開始可能なノードやコアの総数に基づいて自動スケールの距離を制限します。 この制限は、予想される最大の作業量と地域で利用可能なノルマを反映するように設定してください。
• 専用ノードとスポットノードの違い。専用ノードは プール専用に予約され、予測可能な容量を提供します。 スポットノードは余剰のAzure容量を割引価格で使用しますが、Azureは容量を取り戻す必要があります。 時間に敏感なジョブや長時間実行されるジョブには専用ノードを使用し、保証された可用性よりもコストを重視するフォールトトレラントな処理や再開可能な処理にはスポットノードを使用します。
• 規模を縮小する行動。 オートスケーリングはアイドルノードを除去し、使っていない計算に支払う必要をなくなります。 ジョブが結果を永続ストレージに書き込むようになっていることを確認してください。ノードが割り当て解除されると、そのノード上のローカル データは失われるためです。

オートスケーリングの制限を理解する

CycleCloudクラスターでは、複数の独立した制限によってCycleCloudが起動できるノード数が決まります。 最も低い実効限度額が勝ちます:

制約を特定するには、クラスタのCycleCloudクラスタページにアクセスしてください。 ノードテーブルで「Actions>Add」を選択します。 ノード 追加 ダイアログでは、選択したノード配列に適用される制約が説明されています。

例えば、ノードアレイが現行世代の Standard_HB368rs_v5 VMを使用しており、それぞれ368個のvCPUを消費し、以下の制限があるとします。

HBv5のVMファミリーのクォータが最低限度であるため、設定された上限は6ノードですが、 MaxCount は8ノードを許可しています。 リクエストが実行された時点でAzureの容量が5台のVMしかない場合、CycleCloudは5つのノードをプロビジョニングし、残りのリクエストは容量が出るまで制約されたままです。 MaxCountを増やすだけでは、ノルマの上限や利用可能な容量は上がりません。

テンプレートが MaxCoreCountを使う場合は、その値をVMのvCPU数で割り、ノード上限を切り上げます。 CycleCloudの設定の定義については、 Nodeおよびnode配列オブジェクトをご覧ください。

ノルマ、収容能力、地域を確認してください

使用する予定のVMは、展開する地域で利用可能なもので、かつクォータ内に存在しなければなりません。

• 地域。 必要なワークロードをVMファミリーに提供し、データやユーザーに近いリージョンを選びましょう。 すべてのVMファミリーがすべての地域で利用可能というわけではありません。
• クォータ。 コア(vCPU)のクォータはリージョンごと、VMファミリーごとに設定されます。 計画した最大クラスターサイズに見合う割当量が十分に多いか確認し、必要に応じて 割当量の増額を申請 してください。
• 容量。 クォータ内であっても、HPCのVMサイズは特定の時点でリージョン内で制約可能です。 大規模または時間的に重要な実行のために、バックアップVMサイズや追加のリージョンを検討してください。

ストレージとネットワークを計画する

HPCジョブは、計算だけでなく、データの読み書き速度に制限されることが多いです。

• 共有ファイルシステム。 ほとんどのHPCクラスターは、すべてのノードがマウント可能な共有ファイルシステムを必要とします。 CycleCloudはNFSサーバーや並列ファイルシステム(例:BeeGFS)をクラスターの一部として展開でき、Azure NetApp FilesやAzure Managed Lustreなどのマネージドサービスに接続できます。
• 相互接続。 密結合MPIジョブには、HPC最適化VMで利用可能なInfiniBandインターコネクトが必要です。 VMのサイズと地域が対応しているか確認してください。
• ネットワーキング。 クラスタをホストする仮想ネットワークとサブネットを計画し、CycleCloudアプリケーションサーバーがノード管理に必要なアウトバウンドアクセス権を持っていることを確認してください。 本番環境向けのガイダンスについては、本番環境のデプロイを計画するを参照してください。

クラスタデータパスを選択する

データをコンピュートノードに届ける方法は、スループットとコストに大きな影響を与えます。 仕事がデータの読み書きをどのようにするかに基づいて選択します:

目安としては、データがすでにBlobに存在しジョブが主に読み取っている場合は BlobFuse2 ストリーミングを使うのが良いでしょう。 ジョブがノード間調整、POSIXセマンティクス、または大量の共有書き込みを必要とする場合は、 共有または並列ファイルシステム (マネージドLustreやNetAppファイル)を使用します。 既存のバックエンドへのアクセスを加速したいときはキャッシュ層(HPC Cache)を使いましょう。

費用計画

計算コストは通常、HPC環境で最も大きな支出となります。 これらのコストを抑えるために、以下の方法で計画を立てましょう:

• 自動スケーリングとスポットノードを使って、アイドル容量の支払いを避けましょう。
• 最大サイズのオプションをデフォルトで使うのではなく、ワークロードに合わせてVMのサイズを適正化すること。
• Microsoft Cost Managementとの組み込み統合を通じて支出を追跡します。 詳細については、 コストと使用量の追跡をご覧ください。

本番環境の前にクラスタの検証を行います

代表的なジョブ、予想されるデータ量、本番スケジューラとクラスタ構成を組み合わせた概念実証を実行します。 すべての基準で証拠を記録できるまでは、設計を承認して生産を進めないでください:

基準が失敗した場合は、VM、ノードアレイ制限、ストレージパス、自動スケーリング設定、またはリージョンフォールバックを修正し、同じ作業を繰り返します。 小規模な機能テストでは、スケジューラの互換性やピークスケール、データの移動を行使しないため、本番環境の準備状況を確立できません。

次のステップ

• CycleCloudクラスタとノード
• CycleCloudでのスケジューリング
• 新しいクラスタを作成する
• クラスター ノードに Azure Blob Storage をマウントする
• 本番展開の計画を立てましょう