R&D向け異機種クラスタソリューション

R&D向け異機種クラスタソリューション

私は、仕様の異なる複数の物理マシンを備えた研究室で働いています。マシンにはさまざまな CPU (一部は Intel、一部は AMD) とさまざまな RAM サイズがあり、一部のマシンには個別の GPU があり、一部のマシンにはそれがありません。

現在のソリューションは SSSD と Kerberos に基づいており、ユーザーはどの端末からでも自分のアカウントにログインしてファイルにアクセスできます。問題は、この方法ではユーザーが作業中に 1 台のマシンに「縛られ」、リソースの割り当てが最適ではないことです。

そのため、私たちはクラスターの代替ソリューションを探しています。私たちの主な目標は、すべてのマシンを完全に統合することです。つまり、ユーザーの観点から見ると、クラスターは 1 台のマシンで構成されます。ただし、私たちが収集した情報によると、Slurm などのソリューションは、ジョブ スケジューラに依存したくないため、理想的ではありません。私たちが思い描いているソリューションは、次のようなものです。ユーザーがログインすると、必要な仕様 (RAM、CPU の数、個別の GPU など) を指定でき、必要な仕様の仮想化環境 (たとえば、Docker イメージまたは仮想マシン) が作成されます。その後、ユーザーはその環境を通常の「コンピューター」として使用できます。ただし、この仮想環境のリソースは、単一のマシンからではなく、クラスターから取得する必要があります。また、すべての「仮想環境」からアクセスできる大規模なデータセットを共有できるようにする必要があります。クラスターには、認証および許可システムも必要です。

私たちは目標を達成できるクラスタリング ツールを探していましたが、どれを選べばよいかわかりません。Mesos、OS/DB、Docker Swarm、Kubernetes、oVirt を検討しましたが、これらのツールで目的を達成できるかどうか、また達成できる場合、どれが最適なのかわかりません。コンテナは本番環境には適しているかもしれませんが、R&D にはおそらく最適な選択肢ではないと思います。皆さん、私たちに何をすべきか、どこから始めるべきかについて、いくつかのポイントを教えていただけますか?

よろしくお願いいたします、pinxau1000

答え1

複数のシステムのリソースを 1 つのイメージに結合することはできないという @NikitaKipriyanov の意見に同意します。ただし、過去にはこれを実現した商用製品があり、レイテンシを抑えるために InfiniBand に依存していました (私見では、うまく機能しませんでした)。Slurm はスケジューラとして使用できますが、インタラクティブなジョブに使用することもでき、リソース マネージャとしてより機能させることができます。

各ジョブでは、CPU コアの数、GPU の数と種類、メモリの量などを指定できます。スケジューラは適切な未使用のシステムを選択し、シェル プロンプトを表示します。必要に応じて、X11 転送を利用できます。

また、コンテナは研究開発環境では非常に役立ちます。有用性がわからないからといってコンテナを捨てるべきではありませんが、コンテナはこの問題の解決策ではありません。

答え2

不可能です。

  1. CPU が異なると、命令も異なる可能性があります。CPU 間でコードを移行する場合、これは悪夢です。
  2. メモリのレイテンシはナノ秒単位、ネットワークのレイテンシは数十マイクロ秒単位です。

ワークロードによっては、ワークロードを複数のコンピューターで実行し、それらの間でデータを通信できるように変換できる場合があります。一部の問題ではこれは簡単で、データセットを小さなパーティションに分割して、それらを並行して処理できます。他のワークロードではこれは困難です。ただし、これにはオペレーティング システムではなく、ワークロードの変更が必要です。

関連情報