クラウドでの大規模な技術計算のためのクラスターの使用

このソリューションは、Google Cloudで大規模な技術計算を実行するためのガイダンスを提供します。 多くの技術的なコンピューティングアプリは、クラスタに一緒に接続され、ノード間で計算とデータアクセスを調整する、個々の計算ノードの大規模な数を必

クラスタコンピューティングの基礎となる概念と技術は、過去数十年にわたって開発されており、現在は成熟して主流です。 SoftwarestackをGoogle Cloudに移行すると、いくつかのしわが追加されるだけでなく、コストを削減し、今日の高性能コンピューティング環境の既存のボトルネックを軽減するための多くの機会を提供することができます。 このガイドでは、技術の概要、課題、およびGoogle Cloud上で計算クラスターを実行するためのソリューションの現在の作物について説明します。

クラスタコンピューティングは、タスクを解決するために一緒に動作するマシンのコレクションを集約し、調整します。 クラスターには、通常、単一のヘッドノード（マスターノードと呼ばれることもあります）、いくつかの計算ノード、および可能な限り少数の他の特殊ノードがあります。 ヘッドノードはシステムのブレーンであり、以下のために責任があります:

• 計算ノードをシステムに登録します。
• ノードの監視。
• 特定のノードにジョブを割り当てる。

ユーザーは、タスクが基本的な作業単位である多くのタスクで構成されるジョブを送信します。 一部のジョブには、特定のタスクが他のタスクよりも前に実行されるような複雑なタスク依存関係があり、一部のタスクには、メモリ、Cpu、または実行される他の特定のハードウェアの点で特定のnodeconfigurationsが必要な場合があります。 タスクは、ストレージから入力データを読み取り、データを処理して結果を生成し、最終結果をストレージに書き戻す実行可能ファイルです。

クラスタコンピューティングワークロードには、主に二つのタイプがあります:

• High-performance computing(HPC)—ataskを達成するために多くのworkerノードを使用し、密に結合され、同時に実行されるコンピューティングの一種です。 これらのマシンは、通常、効率的に通信するために低いネットワーク遅延を必要とする。 この分野のアプリケーションの例には、天気モデリング、計算流体力学（CFD）、工学における応力モデリング、および電子設計が含まれます。

• High-throughput computing(HTC)—個々のコンピューティングノードが通信する必要がなく、互いに独立して処理される複数のタスクをappshaveコンピューティングの一種です。 これらのワークロードは、並列ワークロードまたはバッチワークロードと呼ばれることがあります。 典型的な例としては、メディアレンダリング、トランスコーディング、ゲノミクス、パーティクル物理学、イベントシミュレーションと処理があります。 あなたが個々のファイルの多くを処理する必要がある場合、それはおそらくHTCのワークロードです。

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

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

• クラスタを準備および構築するシステム管理ソフトウェア。
• ジョブの実行を調整するスケジューラ。
• エンドユーザーアプリ。

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

システム管理ソフトウェア

クラスタリングソフトウェアは、ベアメタルハードウェア、オンプレミスクラスタ、またはcloudenvironmentと同様に仮想化環境で直接 クラスター内の複数のノードを手作業で調整することは、タイムコンシューティングであり、エラーが発生しやすいです。 専用のクラスター管理ソフトウェアを使用して、複数のノードとリソースをプロビジョニングおよび構成することができます。

チューリッヒ大学のopen sourceElastiClusterソフトウェアは、compute Engineを使用したノードのプロビジョニング、Ansibleplaybookのセットを使用したノードの構成をサポートするクラウドネイティブ ElastiClusterはノードをプロビジョニングし、ファイル提供のためのNFS、NISユーザーアカウント管理、ユーザーアプリを実行するためのajobスケジューラなどの基本softwarestackをインス ElastiClusterはさまざまなschedulersをサポートしており、箱から出して使用したり、小規模から中規模のチームのニーズに合わせてカスタマイズすることができます。

Chef、Puppet、Terraformなどの他の構成管理システムを使用してhpcクラスターを管理する場合は、利用可能なツールとプラグインを使用してGoogle Cloudに移行するときにこれらの

Google Cloudは、マルチノードソフトウェアシステムのプロビジョニングと展開のためのネイティブサービスを提供します。 Cloud Deployment Managerを使用すると、Compute Engine、Compute Enginemanagedインスタンスグループ、Cloud Storageなどのクラウドリソースのセットをプロビジョニングできます。 Cloud Deployment Managerとマネージインスタンスグループを使用してクラスターを設定する方法について説明します。

ジョブ-スケジューラ

クラスターが動作した後、タスクの実行とノードの割り当てを管理するソフトウェアはジョブ-スケジューラ(workloadmanagerまたはキュー-マネージャーと呼ばれることもある)と呼ばれます。 多くの場合、クラスターマネージャにはabuilt-in job schedulerが付属しています。 ジョブスケジューラには、次のようなジョブやタスクの管理に役立つさまざまな機能が用意されています:

• ユーザーとグループ間のジョブの優先順位のサポート。
• タスクのキューイングと再スケジュールによる失敗したタスクのサポート。
• タスクの依存性とタスク割り当てのためのリソースニーズの考慮。
• キュー内のジョブの数に応じてクラスターサイズをスケーリングします。

人気のある商用およびオープンソースのワークロードマネージャの様々ながあります。例としては、ウィスコンシン大学のhtcondor、SchedMDのSlurm、UNIVA Grid Engine、IBMのLSF Symphonyなどがある。 それぞれに強みがあります。

HTCondorはshared-nothingの哲学で構築されており、それ以外のidleresourcesでジョブを日和見的にスケジュールするために共有リソース全体で使用されます。 これは、独自のデータ移動を提供するため、sharedfileシステムを必要としません。 その結果、HTCondorは数十万のコアに拡張され、複数のゾーンと地域で使用できます。 HTCondorは、オンプレミスのandcloudベースのシステム間で作業が共有または分割されるhybridワークロードに使用されています。 しかし、その名前が示すように、高スループットのジョブであり、密結合の並列ジョブではありません。

SlurmとUniva Grid Engineは、より伝統的なHPCクラスター環境を提供し、高スループットと高パフォーマンスの並列アプリケーションの両方をサポートします。 Theybothは、ノード間で共有ファイルシステムを想定しているため、データを移動する必要がなくなります。 どちらも、多くの場合、オンプレミスで使用されるのと同じツールであるため、アプリの開発に便利で使い慣れたユーザー環境を提供します。これらの従来のジョブスケジューラは、小規模から中規模のクラスターには十分ですが、クラスターのサイズが大きくなると、ファイルサーバーの負荷がパフォーマ 並列および分散ファイルシステム(次のセクションを参照)は、大規模な場合にこの問題を解決できます。 または、低遅延のfileaccessが不要な場合は、Apiを使用して並列オブジェクトアクセスを提供するCloud Storageを利用するか、GoSix互換性が必要なgcsfuseを使用して、Cloud Storageを利

最後に、Google Cloudには、ハイスループットワークロードのためのCompute Engine上のaDockerベースのタスクをスケジュールするための簡単なサービスが含まれています：theCloud Life SciencesPipelines API。このサービスでは、ジョブをタスクに分解し、タスク間の依存関係を管理し、タスクのライフサイクルを管理する必要があります。 Thedsubオープンソースプロジェクトは、バッチジョブを起動するためのコマンドラインツールを提供し、Cloud Life Sciences Pipelines APIをサポートします。

Storage

ほとんどのHPCアプリケーションでは、POSIX APIをサポートするafileストレージソリューションが必要です。 小規模なクラスターの場合、FileStoreはGoogleが管理するNFSベースのファイルストレージサービスを提供します。 ただし、大規模なクラスターでは、アプリケーションI/Oがパフォーマンスのボトルネックになスケールアウトおよび並列ファイルシステム、asElastifile（Googleが買収）、Lustre、orQuobyteは、大規模なクラスター（またはI/O重い小さなクラスター）へのスケーリングに役立ちます。

または、低遅延のfileaccessが必要ない場合は、APIを使用するか、POSIX互換性が必要な場合はgcsfuseを使用して並列オブジェクトアクセスを提供するCloud Storageを利用できます。

クラウドでクラスタコンピューティングを実行する機会

クラウドでコンピューティングクラスターを実行するには、多くの理由があります:

• 解決までの時間。 クラウドで本番品質のクラスターを起動すると、数百の利用可能なコアを持つ小さな10ノードのクラスターから、数十万以上のコアを持つ大規模なクラスターまで、わずか数分で起動できます。 これとは対照的に、オンプレミスで新しいクラスターを構築するには、運用の準備が整うまでに数ヶ月かかる場合があります。 オンプレミスクラスターが利用可能な場合でも、通常、ジョブの実行がスケジュールされるまでの使用率が高く、キューの待機時間が長いことがあります。 代わりに、クラウドに独自のクラスターを構築し、ワークロードに使用して、分析が完了したらクラスターを終了することができます。

• 総所有コストの削減。 Google Cloudは、ソリューションの時間を短縮するだけでなく、premptible Vm、長期使用割引、動的スケーリングを活用することで、実行あたりの総コストを削減することもで Jobsareがキューに入れられたときにノードを追加し、必要でないときにノードを削除できます。

• 協力のためのサポート。 多くの状況では、計算分析は、複数の組織間で異なる人々と共同で開発されています。 Google Cloudには、プロジェクトレベルのidentityとアクセス管理ツールが用意されており、データや分析ツールへのアクセスを制御できます。 承認されたユーザーは、同じアプリ、データ、およびクラスターにアクセスして、データのコピー、バージョンの管理、またはsynccluster構成を行うことなく、すべてのユーザーが同じペー

• タスクに合わせたリソース。 ジョブのコストは、インスタンス数ではなくコア時間の合計にのみ依存するため、クラウドでクラスターを実行すると、各チームまたはグループが独自の このアプローチは、複数のグループの使用に関するポリシーを開発する別の主要な痛みのポイントを軽減することができます。 その後、各専用クラウドクラスターをカスタマイズして、ターゲットアプリ用に調整できます。 オンプレミスクラスターは、さまざまなグループやアプリで共有されるフリーサイズのリソースで構成される傾向があります。 このような環境では、グループ間で共有するためのポリシーは、設定と維持が複雑になる傾向があります。

• 統合。 大規模な計算ジョブを実行する前に、研究者はデータセットを準備するために重要な作業を行います。 クラウドに移行した後、これらの検索者はクラウドで利用可能なビッグデータツールを活用することができます。 計算システムの出力も分析する必要があります。 BigqueryやDatalabなどのツールは、オンプレミスシステムで利用可能なものよりも大きな利点を提供することができます。

建築上の考慮事項

これまでに説明した利点は説得力がありますが、移行プロジェクトを妨げることが多い技術的な課題は決してありません。

• データ移動。 クラスターのcomputenodesによって処理されるデータセットは、通常、ジョブを実行する前にクラウドにステージングする必要があります。データ移動の管理は、データの量とその管理方法に応じて複雑になる可能性があります。 などのツールは、必要に応じて自動的にデータを移動するクラウドキャッシュレイヤーを提供することで役立ちますが、多くのアプリではデータセットを手動でステージングする必要があります。

• データアクセス。 多くのHPCアプリは、セットオフファイルとディレクトリへの共有アクセスを必要とします。 このアクセスがどのように提供されるかは、アプリケーションのパフォーマ ストレージのセクションで説明されているように、filestoreなどのNFSサーバーに格納されている共有データを利用するか、並列ファイルシステムを使用できます。

• セキュリティ。 機密性の高いデータの場合は、アクセスが常に許可され、データが保存時および転送中に適切に暗号化されるように注意する必要があります。 Cloud Storageは保存中および転送中のデータを暗号化しますが、追加の制御層を適用して、キー管理サービスを含むか、独自のキーを管理することができます。 ジョブを実行する前に、キーを取得するか、computenodesにインストールする必要があります。

• ノード間レイテンシ。 密に結合されたHPCアプリの場合、performancemightはクラスター内のノード間のノード間の遅延に敏感です。Google Cloudには最大64コアのノードサイズが用意されているため、ノードを横断することなく64方向の並列ジョブを実行できます。 ほとんどの場合、1000コア以下のジョブは、専門化されていないネットワークハードウェアで合理的にうまく機能します。

• ソフトウェアライセンス管理。 多くの商用アプリでは、キーサーバーとも呼ばれるalicense serverが必要です。 いくつかのアプリは、組み込みまたは推奨されるライセンスサーバーでcomewith、他の人は、既存のライセンスサーバーの製品と互換性があるかもしれません。 一部のジョブスケジューラは、ライセンス管理を支援し、ライセンスが利用可能になるまでジョブの実行を停止することができます。

推奨アーキテクチャとベストプラクティス

テクニカルコンピューティングは、さまざまな状況に対応する多くのツールとアプローチを提供します。 非常に多くのオプションを使用すると、始めるのが難しいかもしれません。クラスター管理ソフトウェアとスケジューラの選択に関係なく、Googleクラウド上で実行するときに従うことができるベストプラクティスの領域数。

• 可能な限りプリエンプティブルVmを活用します。 プリエンプティブルVmはCompute Engine上の通常のVmに似ていますが、価格は通常のVmよりも最大80％低く、ほとんど通知せずに再利用できるという注意点があハイスループットワークロードの場合、ジョブスケジューラはノードの損失を検出し、ノード障害として扱い、別のリソース上のノードで実行されているタスクを再スケジュー 失われたノードで行われた作業は失われますが、ノード損失の確率は十分に低く、lowerpriceはチャンスの価値があります。 予想される損失率は5％から15％です。 Preemptiblevmは、再利用される前に最大24時間の使用に制限されています。
• 独自の並列ファイルシステムを実行するのではなく、クラウドストレージのコストと帯域幅を活用します。 クラウドストレージは、一貫性とスケーラブルな並列パフォーマンスを提供し、全体的なコストを削減します。最初のバイトのレイテンシは約100ミリ秒で高いが、並列ファイルサーバー onComputeエンジンを実行する代わりにクラウドストレージを平均化できるアプリの方が費用対効果が高い。 クラウドストレージとコンピューティングノードの間の利用可能な帯域幅は、manyappsにとって十分であり、一部の顧客は23GB/s以上の持続的な総帯域幅を報告しています。
• 単一のアプリまたは単一のグループのクラスターを構築します。 従来のクラスターは、複数のユーザー、グループ、アプリ間で共有されているため、ジョブのキュー時間が長くなり、アプリによるリソース使用量が非効率にな Google Cloudでは、グループまたはプロジェクトごとに複数のクラスターを作成し、それらを実行する特定のアプリ用に最適化されたクラスターを使用することを検討してください。 1つのクラスターを2時間実行しても、1時間ごとに2つのクラスターを実行しても、全体的なコストは同じですが、後者のパターンではキューの待機時間を短縮し、アプリのパフォーマンスを向上させることができます。

すべての実装は一意ですが、以下のセクションでは、三つの一般的なケースについていくつかの一般的な推奨事項を提供します。

データを処理しようとしている独立した研究者

個々の研究者は、通常、データ全体でアプリを実行し、できるだけ早く完了しようとします。 彼らはtheerappの専門家かもしれませんが、クラスター管理や管理の専門家にはなりたくありません。

ハイスループットワークロードを実行している場合は、theCloud Life SciencesPipelines APIの使用を検討できます。Pipelines APIでは、アプリをDockerコンテナに入れ、入力ファイルをCloud Storageバケットに配置する必要があります。 その後、gcloudコマンドラインツールを使用して、クラウドストレージバケット内のファイルのそれぞれに対してアプリを起動できます。 他のクラウドストレージバケットにその結果を配置することができます。

入力BAMファイルからBAMインデックスファイルを生成するためにusesSAMtoolsを使用するタスクを実行するコマンドの例を次に示します:

gcloud alpha genomics pipelines run --pipeline_id \--logging gs:///logs \--inputs inputFile=gs://genomics-public-data/gatk-examples/example1/NA12878_chr22.bam \--outputs outputFile=gs:////output/NA12878_chr22.bam.bai

どこで

• Pipelines APIのアプリのIDを表します。
• は、クラウドストレージバケット名を表します。
• はディレクトリの名前を表します。

プロビジョニングまたは管理するクラスターはありません。 タスクは、パイプラインAPIによってプロビジョニングおよび管理されるVMでuntilcompletionを実行するだけです。 これは、Compute Engineが毎秒の使用量を請求するため、コスト効率が高くなります。

単一のプロジェクトまたはチームの中小規模クラスター

プロジェクトまたはチームでは、メンバーは会社全体のユーザーのためにacentral teamが実行するクラスター どちらの状況でも、theclustersは専門的に管理され、標準的なツールを使用してアクセスされます。 たとえば、ユーザーはsshを使用してヘッドノードに接続し、Grid Enginesubmitスクリプトを使用してジョブを送信して実行することができます。

このようなチームのアプローチの1つは、ElastiClusterを使用して、オンプレミスシステムに似たclusterenvironmentを定義することです。 アプリに最適なCompute Engineマシンの種類を選択してクラスターをカスタマイズし、アプリにsoftwaredependenciesをインストールするようにスタートアップスクリプトをカスタマ また、計算ノードにgcsfuseをインストールして入力データをマウントすることもできます。

これらの詳細はElastiCluster構成ファイルに記録され、computationが必要な場合は、コマンドラインツールを使用してクラスタが起動されます。:

% elasticluster start astrocluster1

構成ファイルでastrocluster1という名前のクラスターは、指定されたとおりにプロビジョニングされ、構成されます。 構成ファイル内の定義は柔軟性があり、ヘッドノードとコンピューティングノードの異なるノードタイプ、スクラッチ領域のCompute Engineersistentディスク、高スループットのワークロー CentOSベースの32コア仮想マシンを使用する10個の計算ノードと1個のヘッドノードを持つSlurmベースのクラスターのbasicconfigurationの例は、次のようになります:

 cloud=google login=google setup=ansible-slurm security_group=default image_id=centos-7-v20170327 flavor=n1-standard-32 frontend_nodes=1 compute_nodes=10 ssh_to=frontend boot_disk_size=50 

最後に、システムでこれ以上ジョブが実行されていない場合は、クラスターを停止できます:

% elasticluster stop astrocluster1

大規模なワークロードの場合は、次のことができます:

• クラスターマシンの種類をカスタマイズして、コストをさらに削減します。
• 大規模なパフォーマンスを向上させるために、外部並列ファイラを追加します。
• キューの深さに基づいて追加のノードを追加および削除するauto scaling機能を追加します。

hpc center既存のクラスターにバースト容量を追加

中央のHPCセンターは計算能力が非常に高いですが、会社や組織全体の多くのグループで使用されているため、hpc 彼らは通常、特定の生産能力を念頭に置いて購入され、予期せぬ作業負荷がミックスに提出されると、進行が大幅に遅くなる可能性があります。

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

クラウドへの破裂はいくつかの理由で便利です:

• ジョブの送信と管理のための一貫したユーザー環境を維持します。 ユーザーは、追加のノードが追加されているかどうかを知らず、気にしません。
• it管理者は、コストを制御するために、いつバーストするかのポリシーを定義することができます。

最大の課題は、オンプレミスとGoogleクラウドノード間でユーザージョブに一貫したデータとファイルの名前空間を提供することです。 Google Cloudノードは、オンプレミスノードと同じinternalfileシステムにアクセスできない場合があります。 このような状況では、これらのファイルを参照するジョブは実行に失敗します。

Google Cloudノードが内部file-accesspermissionsで設定されている場合、ジョブは実行されますが、同じ方法では実行されず、追加のネットワーク帯域幅と出力料金が発生する可能性が さらに、オンプレミスノードとクラウドノード間で分割された並列ジョブも、アプリのさまざまな部分間で遅延が追加されてもうまく機能しない場合があ

ハイスループットジョブの場合、HTCondorを使用してクラウドリソースにバーストすることは、これらの課題の多くを回避します。 HTCondorは、glideinwmsを使用した動的プロビジョニングをサポートしています。ジョブがジョブキューに送信されると、プロビジョニングされてクラスターに追加されるノードをトリガーできます。 それらが追加されると、condor schedulerは入力ファイルを指定されたノードに転送し、それらの追加のノードを使用してタスクを実行し、キューを排出します。

Google Cloudでのクラスタコンピューティングユースケースの詳細を読む:

• Googleクラウド、HEPCloud、および自然の性質を探る
• 220,000コアとカウント：MIT数学教授はlargestever Compute Engineジョブの記録を破る

続きを読む:

• Compute Engine上のファイルサーバー
• Cloud Deployment Managerドキュメント

クラスターの使用を開始します:

• Compute Engine Autoscalerを使用したバッチ処理
• Cloud Deployment Managerテンプレートを使用したHTCondorクラスターの作成

GitHub上のプロジェクト例:

• dsub 例:Dockerを使用した単純なバッチジョブ
• ElastiClusterの例

• Pipelines APIの例

• あなた自身のための他のGoogleクラウド機能を試してみてくださ Ourtutorialsを見てみましょう。