シリーズは続く: クラスタのライフサイクル管理を考える

Deepak Khosla

最初のクラスタ管理のコラムでは、最初のHPCクラスタをユーザの要求を満たし最終的には企業にプラスのROIをもたらすシステムを設計するように組織が動くように保証するために、ニーズ調査の実施の重要性について議論した。心に留めておく事が重要なのだが、HPCの実装において万能のソリューションはどこにもない。ノード、インターコネクトやオペレーティングシステムの選択のような重要な要素を含め、あなたのクラスタ設計は特定のニーズに基づいたユニークなものとなるだろう。

最初のコラムで説明したように、ニーズ調査の多くはクラスタで実行する予定のソフトウェア・アプリケーションにフォーカスしなければならない。
その動作パラメータは、リストの最初となる演算ノードなどの多くの重要なシステムコンポーネントの選択を指し示している。各アプリケーションは、毎秒ギガビット(Gpbs)で表現される最適なメモリ帯域幅を持っており、ノード内の各CPUを効率的に実行する必要がある。鍵は、ノード内にあるCPUに渡ってアプリケーションのGbpsレートを最も効率的にサポートできるノードを選択または設計することだ。

典型的な組織においては、小規模のHPCクラスタを実装しており、複数のアプリケーションがそのシステムで実行されることが多い。この場合、もっともメモリ帯域幅主導型アプリケーションのGbpsレートが演算ノード選択時に考慮されるべきである。そのため、もし最も要求が多いアプリケーションがメモリ帯域幅を64 Gbps必要とするならば、そのスループットを持つノードであれば、ひとつのアプリケーションだけでなく、あまりメモリ帯域幅を必要としないすべてのアプリケーションを許容できるのだ。ノードのメモリ容量はもう一つの重要な要素だ。各アプリケーションのCPU毎もしくは全体で必要なメモリは、ノード毎に設計される必要のあるメモリ容量を示している。

しかし他のすべてを合わせたものと比べて、著しくメモリを使うアプリケーションが存在することがある。この場合、特定アプリケーション用に1台以上の大容量メモリノード(「fatノード」と呼ばれている)をインストールし、「thinノード」はメモリ容量をあまり必要としないアプリケーションを処理させた方が安くすむことが多い。

クラスタにインストールするノード数は多くの変数に依存するが、最も重要なことの一つはビジネスの考慮である。複数ノードは、クラスタが処理を行い、組織が望む答えを産み出すスピードを加速する。ビジネス要件に牽引されることにより、ある組織は答えを2時間以内に出すアプリケーションを必要とするかもしれないし、他の組織は8時間でもいいかもしれない。複数ノードは結果を速く出し、ある組織にとってはこの余計な投資に価値があるかもしれない。

クラスタ設計におけるもう一つの重要要素はノード上のローカルディスク容量の必要性だ。これはシステムで実行する予定のアプリケーションのデータ入出力(I/O)要件に左右される。各アプリケーションは特定の周期とデータの読み書きの量で評価される。あるアプリケーションは処理中に発生するデータを保持する一時的な「スクラッチ」スペースを提供するローカルディスクを必要とするだろう。スクラッチが必要なら、アプリケーションのI/O帯域幅は、ローカルノードに何台のドライブが必要かを示す事になる。

ローカルディスクへのデータの読み書きは時間が掛る。あるアプリケーションにとっては、データを読み書きできるスピードは関連するデータ量よりも重要となる。これらのアプリケーションはディスクI/Oに関して、「遅延の影響を受けやすい」(低遅延を必要とする)と看做される。

帯域幅と遅延はどちらもノードのディスクドライブの選択において役割を持っており、実装における全体のコストにかなりの影響を与えることができる。一般的に言えば、高速I/Oと低遅延率が必要なアプリケーションにはSSDドライブが必要であり、最も高価だ。高速I/Oと中規模の遅延が必要なアプリケーションはSASドライブを持ってくる事ができ、価格的には中間だ。もし遅延がアプリケーションにとって問題で無ければ、SATAドライブで十分であり、またコスト的に一番安い。

ローカルディスクに加えて、全ノードもしくは外部ユーザと共有する必要のあるデータを入力データとして読み込んだり、出力データとして保管するために、クラスタは集中されたストレージ上のデータにアクセスする必要がある場合がある。これらの外部ストレージ機器はI/Oインターコネクトを介してノードとデータ転送を行う。一般的にはノード毎に1Gもしくは10Gの接続があれば共有ストレージにアクセスするのに十分だ。その理由はこれが共有ストレージへのアクセスであるためで、ネットワークもしくはストレージ自体のスループットが大抵は制限要因となるからだ。高速スループット、低遅延のI/Oが必要な場合には、ローカルストレージを使うのが最適だ。

アプリケーションにより決定されるもう一つの鍵となる実装は、ノードが相互に通信を行うことができるようにするアプリケーション・インターコネクトの必要性が。いくつかのアプリケーションはクラスタのノードにおいて低遅延通信を必要とするものもあるし、必要のないものもある。例えば、1桁マイクロ秒の遅延もしくは10Gbps以上のスループットを必要とするものはInfiniBand(IB)が現時点では最適だ。

他方、ジョブの最初と最後だけ大量のデータ転送を必要としノード間通信はほとんど無い場合には、単一の1Gもしくは10GのインターコネクトがI/Oとアプリケーション・トラフィックの両方を扱うことができる。イーサネットで十分だと判断された場合には、現時点では1Gしか必要でなくても、将来の拡張に対応するため、そろそろデフォルトの構成となりつつある10Gのビルトインポートを持ったシステムを指定するようにお勧めする。

クラスタ設計における最後の決定事項は運用環境である。繰り返すが、アプリケーションがこの選択を取る。あるアプリケーションは特定の運用環境で最も効率的に実行するし、この要件は各アプリケーション毎に非常に良く文書化されている。クラスタで複数のアプリケーションを実行する組織においては、すべてのアプリケーションの要件を満足する運用環境を探し出すのが課題となる。通常は最も安いオプションとなる。

しかし、しばしば複数のアプリケーションは1つ以上の運用環境を必要とする場合がある。今の時点での一つのオプションは別個のノード設定をインストールして、各々必要なオペレテーティングシステムを実行させる。しかし、もう一つオプションがある。特定のアプリケーションが実行する際に動的に環境をスイッチするプロビジョニング・システムを確立させることで、複数の運用環境が実行できるようにノードをセットアップすることだ。複雑だが、これはワークロードに対するリソース適合の柔軟性を提供することになる。

次のコラムでは、適したシステムを提供できるベンダーを見つけるためのクラスタ設計のステップについて説明する。