クラスタを利用して大規模なテクニカル コンピューティングをクラウドで実行する

Last reviewed 2022-12-20 UTC

このドキュメントでは、Google Cloud で大規模なテクニカル コンピューティングを実行する方法について説明します。多くのテクニカル コンピューティング アプリケーションでは、クラスタに接続された大量のコンピューティング ノードを必要とします。これらのアプリケーションは、ノード間でのコンピューティングとデータアクセスを調整しています。Google Cloud のハイ パフォーマンス コンピューティング(HPC)は、こうした要求の厳しいワークロードを処理するために構築された、柔軟でスケーラブルなリソースを提供しています。

クラスタ コンピューティングの基になるコンセプトと技術が生まれたのは数十年前のことです。その後、これらの技術は進化を続け、現在ではコンピューティングの主流となっています。ソフトウェア スタックを Google Cloud に移行することで、今日の HPC 環境におけるコストを削減し、ボトルネックを軽減する多くの機会が提供されます。このガイドでは、Google Cloud で HPC クラスタを実行するためのテクノロジー、課題、現在のソリューションの概要について説明します。

クラスタ コンピューティングは、タスクを実行するために複数の仮想マシン(VM)を集約して調整を行います。クラスタは通常、1 つのヘッドノード(コントローラ ノードともいいます)と複数のコンピューティング ノードから構成されます。この他に特別なノードが存在する場合もあります。ヘッドノードは、次のようなタスクを管理します。

  • コンピューティング ノードのシステムへの登録
  • 特定のノードへのジョブの割り当て
  • ノードとそこで実行されているジョブのモニタリング。

次の図は、単純なクラスタのアーキテクチャを示しています。

クラスタは、ヘッドノードと複数のコンピューティング ノードから構成されています。

この図は、ヘッドノードとコンピューティング ノードのセットで構成されるクラスタを示しています。ユーザーはヘッドノードにアクセスし、ヘッドノードがコンピューティング ノードの作業を調整します。

ユーザーが送信するジョブは、多くのタスクで構成されていることがあります。タスクとは基本的な作業単位です。ジョブ内のタスクの一般的な構造は次のとおりです。

  • タスクの同時実行が必要で、並列アルゴリズムを使用してタスク間でデータを共有しているジョブ。
  • 複雑なタスクセットで構成され、一部のタスクを他のタスクより先に実行しなければならないような依存関係が存在するジョブ。
  • アプリケーションのニーズを満たすためにハードウェア構成(追加メモリ、GPU、その他の特定の構成など)を必要とするタスク。

最も基本的な意味では、タスクとは、ストレージから入力データを読み取り、データを処理して結果を生成し、最終結果をストレージに書き戻す実行可能ファイルのことです。

HPC クラスタでは、主に次のような種類のワークロードが実行されます。

  • 密結合ワークロード - これらのワークロードは、連動する多くのコンピューティング ノードを使用します。それぞれが同じ実行可能ファイルを実行し、ノード間でデータを共有します。密結合ワークロード用に設計された HPC クラスタでは、高速なノード間通信を可能にするために低レイテンシのネットワークが必要です。低レイテンシ ネットワーキングにより、プロセス間通信とデータ共有の遅延によるパフォーマンス低下を防ぐことができます。密結合ワークロードの例としては、気象モデリング、計算流体力学(CFD)、構造モデリングなどがあります。
  • 疎結合ワークロード - 驚異的並列ワークロードと呼ばれることもあります。疎結合ワークロードは、コンピューティング ノード間でほとんど、またはまったく同期通信を行わずに互いに独立して実行される多くのタスクを実行します。疎結合ワークロードには、連続した依存関係が関係し、あるクラスのタスクが別のクラスのタスクからの入力を待機しなければならない場合があります。この種類としては、メディア レンダリング、財務分析、ゲノミクス、素粒子物理学イベントのシミュレーションと処理があります。

クラウドでクラスタ コンピューティングを行うメリット

クラウドでコンピューティング クラスタを実行する理由はさまざまです。

  • ソリューションまでの時間: クラウドで本番環境と同品質のクラスタを数分で起動できます。数百のコアを使用した 10 ノードのクラスタから、10 万個以上のコアを使用した大規模なクラスタまで、用途に合ったクラスタを構築できます。オンプレミスで新しいクラスタを構築する場合、運用開始までに数か月かかることもあります。オンプレミスのクラスタが利用できる場合でも、クラスタの使用率が高く、キューの待機時間が長くなるため、ジョブが実行されるまでに数時間あるいは数日かかる場合があります。クラウドの場合、独自のクラスタを構築してワークロードで使用し、解析が完了したらクラスタを終了できます。
  • 総所有コストの低減: Google Cloud で削減できるのは解決までに要する時間だけではありません。Spot VM、長期使用割引、動的スケーリングにより、実行あたりの総費用を削減できます。ジョブに必要なリソースを正確に追加し、不要なリソースを削除できます。
  • タスクごとに調整可能なリソース: ジョブのコストはインスタンスの数ではなく、コア時間の合計によって変わります。クラウドでクラスタを実行することで、チームまたはグループごとに専用のクラスタを所有できます。これにより、複数のグループで使用するポリシーを開発する場合の問題を解消できます。また、専用のクラウド クラスタをアプリケーションに合わせてカスタマイズすることもできます。オンプレミスのクラスタは、複数のグループやアプリケーションで画一的なリソースを共有する傾向があります。このような環境の場合、グループ間で共有するポリシーの設定と維持は複雑になります。
  • コラボレーションのサポート: 多くの場合、アプリケーションの開発には複数の組織のさまざまな担当者が関係しています。Google Cloud の Identity and Access Management(IAM)を使用すると、データや解析ツールに対するアクセスを制御できます。許可されたユーザーは同じアプリケーション、データ、クラスタにアクセスできるので、データのコピー、バージョン管理、クラスタ構成の同期を行う必要はありません。
  • 統合: 大規模なコンピューティング ジョブを実行する前に、調査者はデータセットを準備しなければなりません。しかし、その作業量は膨大なものになります。ジョブの実行後、その出力の分析には、かなりの時間がかかります。ジョブをクラウドに移行すると、Google Cloud の BigQueryVertex AI Workbench などのビッグデータ ツールを利用して、オンプレミス システムよりも効率的に作業を行うことができます。

クラスタ コンピューティングのソフトウェア スタック

クラスタ コンピューティングのソフトウェア スタックは、次のものから構成されています。

  • ジョブの実行をオーケストレートするワークロード マネージャーまたはスケジューラ(Slurm、PBS、IBM の LSF など)。
  • クラスタ構成ツール:
    • コンピューティング ノードをオーケストレートするクラスタ管理ツール(マネージド インスタンス グループや Kubernetes など)。
    • クラスタのプロビジョニングと構築を行うための DevOps ツール(Terraform など)。
  • コンピューティングを実行し、出力を表示して分析するエンドユーザー アプリケーション(OpenFOAM、GROMACS、WRF、Jupyter Notebooks など)。

以下のセクションでは、システム管理ソフトウェアとスケジューラについて説明します。

クラスタ構成ツール

クラスタ構成へのアプローチにはさまざまな方法があります。通常、一般的に使用されている HPC ツールは、あまり変更せずに Google Cloud で使用できます。Chef、Puppet、Terraform などの構成管理システムで HPC クラスタを管理している場合には、Google Cloud への移行時にツールやプラグインを使用して、これらのシステムを引き続き利用することもできます。

Cloud HPC Toolkit

Cloud HPC Toolkit は、実証済みのベスト プラクティスに基づいて、再現可能なターンキー HPC クラスタを作成できるオープンソース ツールです。Cloud HPC Toolkit では、すぐに使用できる HPC クラスタを数分以内に作成できるので、HPC がより簡単になります。

Cloud HPC Toolkit は組み立て可能な HPC 環境を実現できるモジュール デザインを備えています。この設計により、ツールキットでシンプルな HPC 環境と高度な HPC 環境の両方を簡単に定義してデプロイできます。HPC のブループリントは HPC 環境のインフラストラクチャとソフトウェア構成を定義する際に、Terraform モジュール、Packer テンプレート、Ansible のハンドブックを構成している高度な YAML 形式のファイルを使います。既存のブループリントでクラスタを作成するか、ニーズに合うようにブループリントを修正することもできます。ブループリントの数テキスト行の構成を簡単に修正することで、必要なインフラストラクチャとジョブに必要な各業界に特化したツールをプロビジョニングすることができます。

ジョブ スケジューラ

クラスタの稼働後は、ジョブ スケジューラがタスクの実行とノードの割り振りを管理します(このスケジューラは、ワークロード マネージャー、キュー マネージャーともいいます)。多くの場合、ジョブ スケジューラにはクラスタ マネージャーが組み込まれています。ジョブ スケジューラは、ジョブとタスクの管理に役立つ次のような機能を提供します。

  • ユーザーとグループ間でのジョブの優先度のサポート。これにより、ポリシーベースのジョブ スケジューリングを行います。
  • タスクの依存関係とタスクの割り振りに必要なリソースの判別。
  • キュー内のジョブ数に応じたクラスタサイズのスケーリング。
  • 失敗したタスクを検出して処理するためのサポート(タスクの自動再スケジュールやその他の手動構成)。

Google Cloud は、一般的な商用およびオープンソースのワークロード マネージャーをサポートしています。たとえば、SchedMD の Slurm、Google Cloud の Batch、ウィスコンシン大学の HTCondorPBS ProIBM Spectrum LSF などです。それぞれのワークロード マネージャーには強みがあり、Cloud HPC Toolkit はそれらのすべてに対してブループリントを提供します。

  • Slurm は、より従来型の HPC クラスタ環境を提供し、高スループットまたは高性能の両方の並列アプリケーションに対応しています。Slurm オープンソース プロジェクトの商用バックアップと保守を行う SchedMD が開発を主導しています。Slurm は、ストレージ アクセスをシンプルにするため、クラスタ全体の共有ファイル システムをサポートしています。数百ノードのクラスタであれば、Slurm 用に NFS にマウントされたファイル システムで十分ですが、クラスタサイズが大きくなると、ファイル サーバーの負荷がパフォーマンスに悪影響を及ぼす可能性があります。I/O 集約型のワークロードを実行する場合や大規模なクラスタを使用する場合、このドキュメントの「ストレージ」セクションで説明する並列ファイル システムや分散ファイル システムがこの問題への対処に役立ちます。低レイテンシのファイル アクセスが不要な場合は、Cloud Storage の使用を検討してください。Google Cloud で Slurm を使用する方法については、Slurm を利用した HPC クラスタをデプロイするをご覧ください。
  • Google Cloud の Batch は、Compute Engine VM インスタンスでバッチ処理ワークロードのスケジューリング、キューイング、実行が可能になるフルマネージド サービスです。Batch がお客様に代わってリソースをプロビジョニングし、容量を管理することで、バッチ ワークロードを大規模に実行できます。Batch を使用する場合、サードパーティ ジョブ スケジューラを構成して管理したり、リソースをプロビジョニングしてプロビジョニングを解除したり、一度に 1 つのゾーンでリソースをリクエストしたりする必要はありません。ジョブを実行するには、ワークロードに必要なリソースのパラメータを指定すると、Batch がリソースを取得して実行キューに入れます。Batch には、他の Google Cloud サービスとのインテグレーションが組み込まれています、バッチジョブのスケジューリング、実行、保存、分析に役立つため、ジョブの送信と結果の使用に集中できます。詳細については、Batch のドキュメントWorkflows を使用して Batch ジョブを実行する方法をご覧ください。Cloud HPC Toolkit はバッチ ブループリントも提供しています。

  • HTCondor は共有リソース全体にわたって使用され、状況依存的にアイドル状態のリソースにジョブをスケジューリングします。独自のデータ移動機能を用意しているので、共有ファイル システムは必要ありません。したがって、HTCondor は数十万のコアにスケーリングし、複数の Google Cloud ゾーンとリージョンに分散できます。HTCondor は、オンプレミスとクラウドで作業を共有または分割するハイブリッドなワークロードに利用されてきましたが、その名前のとおり、高スループットのジョブで、密結合でない並列ジョブを対象にしています。Google Cloud で HTCondor を使用する場合は、Google Cloud の HTCondor の統合をご覧ください。

ストレージ

ほとんどの HPC アプリケーションには、POSIX API をサポートするファイル ストレージ ソリューションが必要です。Google Cloud は、オブジェクト、ブロック、ファイルのストレージ全体に及ぶあらゆるストレージ ニーズに対応する、組み込みサードパーティのストレージ ソリューションを備えています。

低レイテンシのファイル アクセスが不要な場合は、Cloud Storage をおすすめします。Cloud Storage では API を介して、または POSIX API 互換性が必要な場合は gcsfuse を介して並列オブジェクト アクセスを提供します。

中小規模のアプリケーションのファイル ストレージには、Filestore、NetApp、Dell PowerScale などの NFS ベースまたは SMB ベースのソリューションをおすすめします。さらに高いパフォーマンスを必要とするアプリケーションには、DAOS、Lustre、IBM Spectrum Scale、Weka などの並列ファイル システムを検討することをおすすめします。

  • Filestore は、低~中程度のパフォーマンスが重視されるワークロードを対象とした、Google のフルマネージド NFS ベースのファイル ストレージ サービスです。Filestore Basic は、ストレージ容量に関係なく一定のパフォーマンスを提供します。Filestore High Scale ではパフォーマンスが強化され、ストレージが数百 TB、スループットが数十 GBps にそれぞれスケーリングされます。Filestore は Google Cloud サービスとして、Terraform でデプロイするか、Google Cloud API、Google Cloud CLI、Google Cloud コンソールを使用してデプロイできます。
  • NetApp Cloud Volumes は、クラウドにおけるエンタープライズ ワークロードの移行と実行を簡素化する、高度なハイブリッド クラウド データサービスを提供します。NetApp では、オンプレミス データのプライマリ ストレージ、データ マネジメント、FlexCache を使用したクラウド内キャッシュなどの、さまざまなソリューションを提供します。Cloud Volumes ONTAP は、NFS、SMB、SnapMirror のほか、ONTAP のすべての機能セットを Google Cloud で提供しています。Cloud Volumes ONTAP は、Terraform と Google Cloud コンソールを使用してデプロイできます。
  • Dell PowerScale for Google Cloud は、Dell PowerScale を利用した Google Cloud ユーザー向けの統合ファイル サービスです。Dell Technologies Services が管理するこのサービスはすぐに使用でき、PowerScale OneFS のスケールに応じたパフォーマンスや容量と Google Cloud の柔軟性や経済性を兼ね備えています。Dell PowerScale は Google Cloud コンソールからデプロイできます。
  • DAOS は、高 IOP とメタデータ オペレーションや高帯域幅向けに最適化された、オープンソースかつソフトウェア定義のスケールアウト HPC ストレージ システムです。DAOS は、ゼロから立ち上げる HPC ストレージ ケースに焦点を当てており、ユーザーは各データセットの耐久性レベルを動的に調整できます。POSIX インターフェースと、MPI-IO、HDF5、TensorFlow などのいくつかの HPC と AI/ML インターフェースをサポートしています。詳細については、Terraform と Cloud HPC Toolkit を使用した DAOS のソリューションをご覧ください。
  • Lustre 並列ファイル システムはオープンソースとして提供されています。Google パートナーの DDN Storage から完全なエンタープライズ サポートが提供されています。Lustre のエンタープライズ バージョンである DDN EXAScaler は、2021 年の IO500 エントリで Google Cloud 上で 10 Tbps 以上を実証しました。EXAScaler は Terraform を使用してデプロイできます。詳細については、Google Cloud Marketplace で EXAScaler Cloud をご覧ください。
  • IBM Spectrum Scale(旧称 GPFS)は Cloud Marketplace で提供されています。Google パートナーの Sycomp からのフルサポートを利用できます。完全な Spectrum Scale 機能セットを利用できるので、永続的なユースケースと一時的なユースケースの両方で優れたパフォーマンスを実現できます。また、IBM Spectrum Scale では、既存の Cloud Storage バケットとの間でデータを動的に階層化し、Cloud Storage データへのアクセスを高速化する、費用対効果に優れたキャッシュ階層を実現できます。IBM Spectrum Scale は Terraform を使用してデプロイできます。
  • WEKA は、高パフォーマンスのファイルベースのストレージ ソリューションです。WEKA は、Google Cloud の NVMe 対応コンピューティング インスタンスのパフォーマンス階層と Cloud Storage の容量階層を単一の Namespace で組み合わせます。Weka は Terraform を使用してデプロイできます。

アーキテクチャに関する注意事項

標準的なオンプレミス クラスタは、ユーザーとグループ間で共有され、複数のアプリケーションの異なる要件を処理しています。一方、Google Cloud に移行すると、アプリケーションの要件に合わせてクラスタのプロパティをカスタマイズできるので、コストを削減し、パフォーマンスを向上させることができます。次の図に、これらのアーキテクチャ上の違いを示します。

オンプレミスのデータセンター クラスタとクラウド クラスタの比較。

この図は、オンプレミス クラスタとクラウド クラスタの違いを示しています。オンプレミス システムの場合、すべてのインフラストラクチャが共有されます。クラウドでは、ユーザー グループごとにニーズに合ったクラスタを作成できます。

次のリストは、HPC 移行プロジェクトの妨げになる可能性がある技術的な課題を示しています。ベスト プラクティスについては、Google Cloud への移行シリーズをご覧ください。

  • データの移動。クラスタのコンピューティング ノードで処理されるデータセットは、ジョブの実行前にクラウドにステージングする必要があります。データの量や管理方法によっては、データ移動の管理が複雑になる場合もあります。
  • データアクセス。多くの HPC アプリケーションは、ファイルとディレクトリに対する共有アクセスを必要とします。アクセスの制御方法によっては、アプリケーションのパフォーマンスが著しく低下する可能性があります。Cloud Storage や NFS サーバー(Filestore など)に格納された共有データを使用したり、「ストレージ」セクションで説明した並列ファイル システムを使用したりできます。
  • セキュリティ。機密データの場合は、アクセスするときに常に認証が行われ、データの保存中や転送中に適切に暗号化されるようにする必要があります。Cloud Storage は保存時と送信時にデータを暗号化しますが、さらにアクセス制御を追加したり、Cloud Key Management Service や独自のサービスで鍵を管理したりできます。鍵は、ジョブの実行前にコンピューティング ノードで取得またはインストールしておく必要があります。
  • ノード間のレイテンシ。密結合の HPC アプリケーションの場合、クラスタでのレイテンシによってパフォーマンスが影響を受ける場合があります。Google Cloud では、ノードで 416 コアまで使用できるため、ノード間を移動せずに高度な並列ジョブを実行できます。通常、1,000 コア以下のジョブであれば、特殊でないネットワーク ハードウェアでも十分な速度で処理されます。
  • ソフトウェアのライセンス管理。市販の多くのアプリケーションは、ライセンス サーバー(キーサーバー)を使用しています。アプリケーションによっては、ライセンス サーバーが組み込まれていたり、推奨のライセンス サーバーが同梱されていたりします。また、既存のライセンス サーバーと互換性がある場合もあります。ライセンス管理に対応しているジョブ スケジューラもあります。このようなスケジューラでは、ライセンスが使用可能になるまでジョブを停止します。

テクニカル コンピューティングでは、状況に応じてさまざまなツールとアプローチが利用されています。選択肢が多いため、どれから始めればよいのかわからなくなりますが、クラスタ管理ソフトウェアやスケジューラの選択にかかわらず、Google Cloud での実行時にはさまざまなおすすめの方法を使用できます。

  • 可能な限り Spot VM を利用する。Spot VM は Compute Engine の通常の VM と同じですが、料金は通常の VM と比べて最大 80% 安くなります。リスクは、ほとんど予告なしに Spot VM がプリエンプトされることです。高スループットのワークロードの場合、ジョブ スケジューラが再利用されるノードの損失を検出し、ノードの障害として処理します。通常、スケジューラはプリエンプトされたノードで実行されているタスクを別のリソースに再スケジュールします。再利用されたノードに対して行われた作業が失われる可能性がありますが、低料金のメリットを上回るほどノード損失の可能性は高くありません。予想される損失率は 5% から 15% です。プリエンプティブル VM は 24 時間を超えると再利用されますが、Spot VM にそのような制限はありません。
  • 独自の並列ファイル システムではなく、Cloud Storage のコストと帯域幅を利用する。Cloud Storage では、強整合性とスケーラビリティに優れた並列処理を低コストで利用できます。通常、最初のバイトまでの時間は数十ミリ秒ですが、Compute Engine で並列ファイル サーバーを実行する代わりに Cloud Storage を利用できるアプリケーションは費用対効果に優れています。多くのアプリケーションは、Cloud Storage とコンピューティング ノードの間で十分な帯域幅を利用できます。23 GBps を超える集約帯域幅が持続したという報告もあります。
  • 1 つのアプリケーションまたは 1 つのグループにクラスタを作成する。従来型のクラスタは、複数のユーザー、グループ、アプリケーション間で共有されるため、リソースの競合の発生や、アプリケーションでリソースの使用効率が低下する可能性があります。Google Cloud では、グループまたはプロジェクトごとにクラスタを作成し、特定のアプリケーション用に最適化したクラスタを使用することを検討してください。1 つのクラスタを 2 時間実行しても、2 つのクラスタをそれぞれ 1 時間実行しても、全体のコストは変わりません。ただし、後者の方がキューでの待機時間が短くなり、アプリケーションのパフォーマンスが向上します。

実際の状況はそれぞれ異なりますが、ここでは 3 つの一般的なケースを採り上げ、全般的な推奨事項を説明します。

個人の研究者がデータを処理する場合

研究者は通常、データに対してアプリケーションを実行し、できるだけ速く結果を得たいと考えています。自分の研究領域でないクラスタ管理について詳しく知りたいとは考えていません。

高スループットのワークロードを実行している場合は、Batch API の使用を検討してください。これは次のコンポーネントで構成されています。

  • ジョブ: ユーザーによる操作なしで一連のタスクを実行するスケジューリングされたプログラム。通常はコンピューティング ワークロードに使用されます。ジョブは単一のシェル スクリプトの場合もあれば、複雑なマルチパート計算である場合もあります。各 Batch ジョブは、同じ実行可能ファイルを実行する 1 つ以上のタスクの配列で構成されます。
  • タスク: ジョブの一部として定義され、ジョブの実行時に実行されるプログラムによるアクション。各タスクは、ジョブのタスクグループの一部です。ジョブのタスクは、ジョブのリソースで並列または順番に実行されます。
  • リソース: ジョブの実行に必要なインフラストラクチャ各 Batch ジョブは、ジョブの要件とロケーションに基づいて、Compute Engine VM のリージョン マネージド インスタンス グループ(MIG)で実行されます。追加のコンピューティング リソースが指定されている場合、ジョブは GPU などのリソースや、ローカル SSD、Cloud Storage バケットなどの追加の読み取り / 書き込みストレージ リソースも使用することがあります。ジョブにプロビジョニングされる VM の数を決定する要素には、各タスクに必要なコンピューティング リソース、ジョブ並列処理の方法(タスクを 1 つの VM で順次実行するか、同時に実行するか)が含まれます。

Google Cloud の Batch を使用すると、作成したジョブはそれぞれ自動的にプロビジョニングされ、そのタスクの実行に必要なリソースが使用されます。クラスタのプロビジョニングも管理も必要ありません。タスクは、Batch がプロビジョニングして管理している VM で完了するまで実行されます。Compute Engine では 1 秒あたりの使用量で課金されるため、これはコスト効率の良い方法です。

1 つのプロジェクト / チームで小規模または中規模のクラスタを使用している場合

一般的なチームでは、メンバーは中央グループが管理するクラスタにアクセスして、会社全体で使用します。また、オフサイトの HPC センターにある大規模なリソースにアクセスすることもあります。いずれの場合も、クラスタは専門の部署で管理され、標準のツールでアクセスされています。たとえば、ヘッドノードへの接続には SSH を使用し、実行ジョブの送信には Slurm 送信ジョブ スクリプトを使用します。

いずれの場合も、クラウドに実装する際は Cloud HPC Toolkit を使用してオンプレミス システムまたはオフサイト システムに類似したクラスタ環境を定義することをおすすめします。アプリケーションに最適な Compute Engine マシンタイプを選択してクラスタをカスタマイズし、アプリケーションのソフトウェアの依存関係をインストールするように起動スクリプトを変更します。入力データは Cloud Storage にステージングでき、チームはコンピューティング ノードに gcsfuse をインストールして入力データをマウントできます。

次の図は、Cloud HPC Toolkit を使用した一般的な構成フローを示しています。

Cloud HPC Toolkit を使用した HPC 環境の構成。

この図は、Cloud HPC Toolkit を使用して、YAML ブループリントからデプロイされたクラスタに移行する方法を示しています。まず、ブループリントを作成するか、サンプルから選択します。Cloud HPC Toolkit によってデプロイ フォルダが生成されます。このフォルダには、要件を満たす HPC クラスタの構築に必要な Terraform スクリプトとイメージビルド ツールがすべて含まれています。

HPC センターで既存のクラスタにバースト機能を追加する場合

中央の HPC センターでは、さまざまなコンピューティング機能が実行されていますが、このセンターは会社や部門の多くのグループが利用しています。このため、HPC センターの使用率は常に高く、キューの待機時間も長くなっています。通常、一定の本番環境での容量を想定して設備投資が行われていますが、予期しないワークロードにより、処理能力が著しく低下することもあります。

このような状況では、コンピューティング ノードを一時的にクラスタに追加することで、Google Cloud 環境にバーストできます。クラスタはハイブリッド(ヘッドノードと一部のコンピューティング ノードがオンプレミスで実行され、他のコンピューティング ノードが Google Cloud で実行される)になります。ジョブキューがドレインされると、追加ノードは解放されます。

クラウドのバーストには次のようなメリットがあります。

  • ジョブ送信と管理で一貫したユーザー環境を維持できます。ノードが追加されても、ユーザーがそれを意識することはありません。
  • IT 管理者は、バースト時間をポリシーで定義し、コストを管理できます。

オンプレミスと Google Cloud のノードでユーザージョブを処理する場合の最大の課題は、データとファイルの名前空間の整合性を維持することです。Google Cloud のノードが、オンプレミス ノードと同じ内部ファイル システムにアクセスできない場合があります。この場合、これらのファイルを参照するジョブは失敗します。

Google Cloud ノードに内部ファイルへのアクセス権限が構成されている場合はジョブが実行されますが、その場合はネットワーク帯域幅と下り(外向き)料金が加算される可能性があります。また、アプリケーションの部分間で追加のレイテンシが発生し、オンプレミス ノードとクラウドノードで分割した並列ジョブがうまく実行されない可能性もあります。

次のステップ

Google Cloud でのクラスタ コンピューティングのその他のユースケースについて、以下をご覧ください。

HPC インフラストラクチャの詳細については、以下をご覧ください。

クラスタのスタートガイド:

リファレンス アーキテクチャ、図、ベスト プラクティスについては、Cloud アーキテクチャ センターをご確認ください。