タグ: ハイパフォーマンスコンピューティング

Nvidiaで生まれた怪獣HGX-2はHPCやAIのサーバーを単一アーキテクチャでまかなう

Nvidiaが昨日（米国時間5/29）発表したモンスターHGX-2は、ギークの夢の実現だ。それはクラウドサーバー専用機と称され、しかもハイパフォーマンスコンピューティングと人工知能の要件をひとつの強力なパッケージで満足させている。

まず、誰もが気になる仕様から。プロセッサーは16x NVIDIA Tesla V100 GPUsで、処理能力は低精度のAIで2ペタFLOPS、中精度なら250テラFLOPS、最高の精度では125テラFLOPSだ。標準メモリは1/2テラバイトで、12のNvidia NVSwitchesにより300GB/secのGPU間通信をサポートする。これらにより、総合性能は昨年リリースされたHGX-1のほぼ倍になる。

図提供: Nvidia

NvidiaのTeslaデータセンタープロダクトを担当するマーケティングマネージャーParesh Kharyaによると、これだけの通信スピードがあれば、複数のGPUを一つの巨大なGPUのように扱うことができる。“それによって得られるのは、膨大な処理能力だけでなく、1/2テラバイトのGPUメモリを単一のメモリブロックのようにアクセスできる能力だ”、と彼は説明する。

図提供: Nvidia

残念ながらこのボックスをエンドユーザーが直接買うことはできない。売り先はもっぱら、ハイパースケールなデータセンターやクラウド環境をエンドユーザーに提供する、インフラのプロバイダー、いわゆるリセラーたちだ。これによりリセラーは、ワンボックスでさまざまなレンジ（幅）の精度を実現/提供できる。

Kharyaはこう説明する: “プラットホームが統一されるので、企業やクラウドプロバイダーなどがインフラを構築するとき単一のアーキテクチャだけを相手にすればよく、しかもその単機がハイパフォーマンスワークロードの全レンジをサポートする。AIやハイパフォーマンスなシミュレーションなどで、各ワークロードが必要とするさまざまなレンジを単一のプラットホームで提供できる”。

彼によると、このことがとくに重要なのが大規模なデータセンターだ。“ハイパースケールな企業やクラウドプロバイダーでは、スケールメリットを確実に提供できることがきわめて重要だ。そのためにも、アーキテクチャがバラバラでないことが有利であり、アーキテクチャが統一されていればオペレーションの効率も最大化できる。HGXを使えば、そのような単一の統一的プラットホームへ標準化することが可能だ”、と彼は述べる。

そしてデベロッパーは、そういう低レベルの技術を有効利用するプログラムを書くことができ、必要とする高い精度を一つのボックスから得ることができる。

HGX-2が動くサーバーは、今年後半にLenovo, QCT, Supermicro, Wiwynnなどのリセラーパートナーから提供されるだろう。

画像クレジット: Nvidia

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

Googleのクラウドプラットホームではハイパフォーマンスなワークロードを容易に動かせる

AmazonやMicrosoft、Googleなどが提供している非常に大きなクラウドプラットホームは、大学や企業の科学者たちがシミュレーションや分析のために必要とするハイパフォーマンスコンピューティング(high-performance computing, HPC)のプロジェクトを十分に動かせる。なにしろ彼らに課せられる大きなワークロードも、何百何千というマシンで並列処理されるから楽勝だ。しかし、往々にしてチャレンジは、それだけ大量のクラスターをどうやって作り、それらを動かすワークロードをどうやって管理するかだ。

HPCのコミュニティがこのチャレンジを比較的楽にこなせるために、Googleは今日（米国時間3/23）、同社のクラウドプラットホームでオープンソースのHPCワークロードマネージャーSlurmをサポートする、と発表した（このSlurmではない）。それは、上位500のリストに載ってるようなスーパーコンピューターのユーザーの多くが使ってるのと同じようなソフトウェアだ。ちなみに現在最大最速のクラスターは、1000万あまりのコンピューターコアから成るSunway TaihuLightだ。

GoogleはSlurmを作っているSchedMDとチームを組んで、SlurmをGoogleのCompute Engineで簡単に動かせるようにした。この統合努力によりデベロッパーは、自分たちの仕様に基づいて動くCompute Engineで、スケーリングを自動的に行うSlurmを容易にローンチできる。ここでの興味深い機能のひとつは、もうちょっと計算力が欲しいようなときに、ユーザーがオンプレミスのクラスターのジョブをクラウドと連合できることだ。

GoogleのCompute Engineは現在、最大96コア、メモリ624GBまでのマシンを提供しているので、GCP(Google Cloud Platform)の上で必要に応じて大規模な計算力クラスターを構築することも、十分に可能だ。

なお、Microsoft Azureもその上にSlurmをデプロイするためのテンプレートを提供しており、またこのツールはかなり前からAWSをサポートしている。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

ハイパフォーマンスコンピューティングのためのコンテナプラットホームSingularity ProをSylabsがローンチ

オープンソースのコンテナエンジンSingularityを抱える商用企業Sylabsが、最初の商用製品Singularity Proを今日（米国時間2/8）発表した。

Sylabsがローンチしたのは2015年で、同社は科学計算やハイパフォーマンスなコンピューティングに特化したコンテナプラットホーム作ることを志向した。この二つの分野は同社のファウンダーでCEOのGregory Kurtzerによると、これまでコンテナ化の動きから置き去りにされてきた（本誌TechCrunchのコンテナ入門記事がここにある）。

Dockerが、多くのデベロッパーが選ぶコンテナエンジンとして台頭してきたが、しかしKurtzerによると、コンテナを使用するソリューションの初期のものは、マイクロサービスにフォーカスしていた。それは必ずしも間違いではないが、それにより、サービスではなくジョブに依存するタイプのコンピューティング、とりわけハイパフォーマンスコンピューティングが取り残された。

Kurtzerは、オープンソースの落ちこぼれでは決してないが、これまで20年あまり、アメリカのエネルギー省の研究所で、ハイパフォーマンスコンピューティング(HPC)のアーキテクトとして仕事をしてきた。そしてそこで彼は、オープンソースのエンタープライズLinuxプロジェクトCentOSと、Warewulfに出会った。後者は、彼によると、もっとも多く利用されるステートレスなHPCクラスターのプロヴィジョナーになっている。

彼が視点をコンテナに向ける決心をしたのは、Sylabsを創業して2016年の4月にSingularityの最初のバージョンをローンチしたときだ。そのときすでに、それの商用バージョンを作る気でいた。彼はSingularityをHPC環境のためのDockerと見なし、自分の会社もDockerみたいに経営して、オープンソースのプロジェクトをリードし、さらにその上に商用ビジネスを築きたい、と考えた。Dockerがまさにそうしているように。

今ではKurtzerは、SingularityをHPCの商用市場だけでなく、エンタープライズにも持ち込み、人工知能や機械学習、ディープラーニング、高度なアナリティクスなど、そのほかのハイパフォーマンスコンピューティング的ワークロードにもフォーカスしていきたい、と考えている。

“これらのアプリケーションはデータ集約的なワークロードを背負っているから、HPC的なリソースを要求し、今後ますます多くの企業がデータ指向の経営をするようになると、そういうワークフローを適正にコンテナ化してサポートするニーズが大きく成長する”、と同社のエンタープライズプロダクトを発表するブログ記事でKurtzerは述べている。

Singularityは、得意とするワークロードのタイプは違っても、KubernetesやMesosのようなコンテナオーケストレーションツールを有効に利用でき、また、MicrosoftのAzure Batchツールなどのクラウドツールとの互換性もある。

Kurtzerによると、現在のSylabsの社員は12名で、金額は非公開だがすでにシード資金を得ている。その投資家のRStorも、まだステルス状態のスタートアップだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）