IBM Spectrum LSFとIBM Cloudを使用したEDAワークロードのクラウドバースト

記事をシェアする:

 

この投稿は、2020年8月3日に、米国 Cloud Blog に掲載されたブログの抄訳です。

 

EDAのような計算集中型ワークロードのリソース計画は、常に妥協を必要とする課題でした。

計算リソースのコストと決定時間にかかるコストの中間点を見つけるのは困難です。クラウドバーストの出現により、このスタンドオフを打破するための新しい柔軟性が到来しました。これで、データセンター（英語）の容量に負担がかかった場合、既存のIBM Spectrum LSF（英語）クラスターをIBM Cloudに拡張できます。ここでは、事実上無制限のリソースを利用でき、使用した分に対してのみ支払います。

LSFクラスターにクラウドバーストを追加することで、ビジネスニーズに合わせて採用する容量を選択できます。時が金なりなら、クラウドは準備ができています。需要が低い場合、メーターは停止し、クラウドは待機します。

このブログ投稿では、既存のオンプレミスデータセンターで実行されているIBM Spectrum LSFクラスター、IBM提供の自動化スクリプトおよびドキュメント（英語）を使用して、EDAワークロードにおけるクラウドバーストのPoC環境を構築する方法について説明します。最も重要なのは、IBM Cloudです。

既存オンプレミスのクラスターから開始する

私たちが使用するクラスターは、ニューヨーク州ヨークタウンの研究所にあります。このクラスターは最小限であり、マスターとワーカーの2つのノードで構成されています。本番クラスターまたは次のステージのPoCには、数百のノードと数千のコアが含まれる場合があります。この入門的なPoCの目的では、オンプレミスのクラスターのサイズは重要ではありません。私たちの主な関心は、作業をクラウドリソースにシフトする方法を確認することです。

既存の自動化を使用してクラウドクラスターを構築する

オンプレミス・クラスターは、既存のテスト・クラスター、本番クラスター、またはクラウドバーストを調査するためにまとめた最小限のクラスターのいずれかです。次のステップは、マルチ・クラスターのクラウド部分を構築することです。繰り返しになりますが、この時点ではほとんどサイズは重要ではないため、最小限のクラスターから始めるのが適切です。私たちのリファレンス・クラウド・クラスターには、マスターが1つとワーカーが2つの3つのノードがあります。

クラウド・クラスター（マルチ・クラスターのクラウドの半分）を最初から構築しようとすると、プロビジョニングおよび構成タスクの長いリストがあり、以下（おそらくそれ以上）が含まれます。

• デプロイに必要なソフトウェア・パッケージをインストールする
• VPCのプロビジョニング
• 仮想インスタンス（マスターとワーカー）のプロビジョニング
• DNSサービスのプロビジョニング
• オンプレミス・クラスターをクラウドに接続するVPNの構成と接続
• IBM Spectrum LSFのインストールと構成

幸いにも、IBMは、現代のクラウドの主力であるAnsibleとTerraform（英語）に基づいて構築された包括的な自動化を作成し、提供しています。この自動化により、PoCクラスターの初期設定が簡単になるだけでなく、クラウドバーストを定義するリソースの迅速なプロビジョニングと破棄を実現する基本的なツールセットになります。

さらに、自動化（英語）を使用してクラスターを作成する手順をステップごとに説明するチュートリアル（英語）が作成されました。

次の図は、IBM Spectrum LSFオンプレミス・クラスターをクラウドで拡張する方法を示しています。

マルチ・クラスターを構築する

まだ行っていない場合は、この時点で、チュートリアルと自動化を使用して、IBM Cloud上にクラスターを構築できます。このクラウドクラスターを構築すると、マルチ・クラスター環境が機能するようになります。次のステップは、クラスター全体にEDAワークロードを拡張することです。

ワークロードを取り込む

PoCとして、マルチ・クラスターで実行するために、光近接効果補正（OPC）とデザイン・ルール・チェック（DRC）の2つの一般的なEDAパッケージを選択しました。EDAベンダーと実行するパッケージによっては、このブログ・エントリの範囲を超える、マルチクラスターでワークロードを起動する際に特定の課題が発生する可能性があります。うまくいけば、ワークロードの実行方法に関するこの一般的な議論と、克服したいくつかの課題が、クラウドバーストするPoCの構築に役立つことを願っています。

クラウド・クラスターでワークロードを実行する

ワークロードを実行する前に、EDAワークロード用のソフトウェアをインストールしてクラウドクラスターを準備するか、データの依存関係を使用して、プロセスにおけるbstageの一部として必要なソフトウェアを引き継ぐ必要があります（または、場合によっては、 2つの組み合わせ）。

クラスターにライセンスサービスへのアクセス権を付与する必要があります。 詳細については、「証明書とライセンス管理」セクションを参照してください。

ワークロードの特性によっては、ジョブが特定のノードに送信されて処理されるようにする必要がある場合があります。 これは、bsub -Rコマンドで実行できます。 作業は最初にタイル（サブタスク）に分割されてからワーカーに分散されるため、ジョブの初期展開はリソースを大量に消費するため、これはワークロードに役立ちました。

 

データ管理

EDAタスクをクラウドに移動するには、いくつかの理由でデータ管理に注意を払う必要があります。

1. 2つのクラスターが単一のファイルシステムを共有しない可能性があります。
2. オンプレミスとクラウド・クラスター間の接続は、程度の差はありますが、帯域幅が制限されます。
3. 利用規約によっては、クラウド内外でのデータ移動を最小限に抑えることで、コストを削減できます。

Spectrum LSFデータマネージャーは、自動セットアッププロセスの展開ステップの一部として、オンプレミス・クラスターとクラウド・クラスターの両方にインストールおよび構成されている必要があります。以下は、ワークロードのデータ管理を構成する際の重要なポイントの一部です。

• セキュリティ上の理由から、手動による介入が必要な追加のセットアップ手順があります。各ユーザーはクラウドマスターにログインし、ssh公開鍵を取得して、その鍵をオンプレミスマスターの承認済み鍵に追加する必要があります。
• ジョブが送信されるとき、ユーザーはLSF bsub コマンドに-dataオプションを使用してデータの依存関係を指摘する必要があります 。
• ユーザーのLSFジョブは、bstage inコマンドを使用して入力データを処理できるようにし、bstage outコマンドを使用してジョブ出力を後処理できるようにする必要があります。 これは、既存の実行スクリプトをbstage in / outコマンドでラップして、必要なすべてのデータを転送するのと同じくらい簡単です。 これには、bstage inの後に実行される限り、バイナリまたはスクリプトも含まれます。

証明書とライセンス管理

オンプレミスドメインとクラウドドメインにまたがるマルチクラスターのEDAワークロードのライセンスは、ライセンス管理のためのかなり新しく開発中のドメインです。PoCのワークロードでは、IBM Cloud ロンドンのデータセンターのクラウド・サーバーに関連付けられたFlexLMフローティングライセンスを使用しました。アベイラビリティーゾーンにまたがるようにトランジットゲートウェイを構成することで、ロンドンのデータセンターのライセンスサーバーによって提供されるライセンスで、ダラスのデータセンター（マルチクラスターのクラウド部分が存在する場所）でワークロードを実行できました。もちろん、このシナリオはワークロード・ベンダーとライセンス条件に固有のものですが、IBM Cloud VPC（英語）の機能を使用してライセンス管理を支援する方法を説明するためにのみ使用されます。

ジョブを監視する

マルチ・クラスターは2つの連携クラスターで構成されているため、ジョブがクラウド・クラスターに送信されると、それが完了するまで、オンプレミス・クラスターのジョブとキューのモニタリング・コマンドは、ジョブのステータスに関する情報が制限されます。ジョブの進行中に詳細なステータス情報を確認したい場合があります。これは、クラウド・クラスターのコンソールにログインし、そこで監視コマンドを実行することで実現できます。

ハッピー・クラウドバースト！

このブログで提供したEDAワークロードのための環境セットアップ手順に加えて、ワークロードをバーストするための手順のほとんどが自動化スクリプトによって実現されます。自動化スクリプトを活用することで、IBM Cloud上のPoC向けのEDA環境を簡単にセットアップすることができます。ぜひお試しください！

• IBM Virtual Private Cloud（VPC）の概要
• IBM Spectrum LSF
• 既存のIBM Spectrum LSFクラスターをIBM Cloud VPCに拡張する
• IBM Spectrum LSFクラウドバーストオートメーションのGitHubリポジトリ

 

---

翻訳：IBM Cloud Blog Japan 編集部