HPCクラスターの操作

私の大学では、HPCコンピューティングクラスタを使用しています。クラスターを使用して分類子などをトレーニングします。そのため、通常、ジョブをクラスターに送信するには（たとえば、python scikit-learnスクリプト）、（他のものとともに）のようなコマンドを含むBashスクリプトを記述する必要がありqsub script.pyます。

ただし、このプロセスは非常にイライラします。通常、ラップトップでpythonスクリプトを作成し、サーバーにログインしてSVNリポジトリを更新するので、同じpythonスクリプトがそこにあります。次に、そのBashスクリプトを作成または編集して、bashスクリプトを実行できるようにします。

Pythonスクリプトの小さな更新ごとに、計算クラスターで実行するために多くの手順を実行する必要があるため、これは本当に苛立たしいことです。もちろん、サーバーにデータを配置してサーバー上のデータセットのパスを使用する必要がある場合、タスクはさらに複雑になります。

ここの多くの人がデータサイエンスタスクにコンピューティングクラスタを使用していると思います。クラスターへのジョブの送信を管理する方法を知りたいだけですか？

グリッド管理者にローカルマシンを「サブミットホスト」として追加するよう依頼し、SGEをインストールします（使用していると想定していますが、実際には言わないでください）。そうすればqsub、マシンからアクセスできます。

または...。

emacsを使用すると、emacsの「トランプ」ssh接続機能を介してHPCで編集し、別のemacsウィンドウでシェルを開いたままにできます。使用したいエディタ/オペレーティングシステムは何も言わない。emacsを構成してファイルを2か所に保存することもできるため、テストを実行する場合はローカルマシンに保存し、大きなジョブの場合はHPCファイルシステムに同時に保存できます。

ローカルマシンからクラスター内のコンピューティングノードにファイルをコピーする負担を軽減する多くのソリューションがあります。単純なアプローチは、clusterssh（cssh）のように、クラスター内のマシンへのマルチアクセスを許可するインターフェースを使用することです。端末画面のセット（クラスター内の別のマシンへのssh接続）を介して、一度に複数のマシンにコマンドを入力できます。

クラスターがqsubセットアップされているように見えるため、問題はマシンに沿ってデータを複製することに関連している可能性があります（各ノードでコマンドを実行するだけではありません）。したがって、この点に対処するには、scpスクリプトを作成するか、クラスター内の各ノードとの間で物事をコピーするか（SVNで対処する方が確実です）、またはNFSをセットアップします。これにより、データへのシンプルで透過的なアクセスが可能になり、不要なデータを複製する必要性も減少します。

たとえば、ノードにアクセスし、データをそのような場所にコピーして、ネットワーク通信を介してリモートでデータを使用することができます。NFSの設定方法については詳しくありませんが、すでにNFSにアクセスしています（ホームフォルダーがアクセスするマシン間で同じである場合）。次に、スクリプトとデータを1つの場所に送信し、後で他の場所からアクセスできます。これは、SVNアプローチに似ていますが、より透過的で簡単です。

ソースバージョンリポジトリを使用するアプローチは適切であり、実際にクラスタで作業してからすべてをコピーして戻すことができます。

ラップトップのPythonスクリプトを少し編集してから、クラスターのSVNディレクトリを更新する場合は、クラスターフロントエンドで直接作業せず、必要なすべてのマイナー編集を行ってから、1日の終わりにコミットしてください。そこにすべてあり、あなたのラップトップで更新しますか？

必要なのは、そこの環境（OS、エディターなど）に慣れるか、独自の環境をインストールすることです（通常、ホームディレクトリに最新バージョンのVimやTmuxなどを適切なドットファイルでインストールするので、そこに家。）

また、データ、およびサイズが許す場合は中間結果をバージョン管理することもできます。私のリポジトリは、多くの場合、コード、データ（元のバージョンとクリーンバージョン）、ドキュメント、および発行用の紙のソース（ラテックス）で構成されています

最後に、ジョブ送信をスクリプト化して、スクリプトを手動で変更しないようにすることができます。qsubstdinからのスクリプトを受け入れ、すべての#$コメントをコマンドライン引数として受け入れます。

あなたの質問の言い回しから、私はあなたが2つのファイルを更新するローカルマシンとリモートマシンを持っていると仮定します-PythonスクリプトとBashスクリプトです。どちらのファイルもSVNの制御下にあり、両方のマシンが同じSVNサーバーにアクセスできます。

グリッドシステムに固有のアドバイスはありませんが、導入に重要であるとわかった一般的なポイントをいくつか挙げさせてください。

本番環境の変更を構成の変更に限定します。「サーバー上のデータセットのパスを使用する」必要があると書いています。これは、Pythonスクリプトにパスがハードコードされているように聞こえます。スクリプトを移動する他のすべてのマシンでこれらのパスを変更する必要があるため、これは良いアイデアではありません。これらの変更をSVNにコミットすると、ローカルマシンにリモートパスがあり、オンとオンが繰り返されます（パスだけでなくパスワードもある場合はどうなりますか？SVNに本番パスワードを設定しないでください）サーバ。）

したがって、パスやその他のセットアップ情報を.iniファイルに保存し、ConfigParserを使用してそれを読み取るか、.jsonファイルを使用してjsonモジュールを使用します。ファイルのコピーをローカルとリモートの両方に同じパスで両方ともSVN制御なしで保持し、Pythonスクリプトでその構成ファイルへのパスを保持する（または両方を保持できない場合はコマンドラインから取得する）同じパスでの構成）。

構成はできるだけ小さくしてください。どの構成もアプリケーションの「可動部分」であり、どのシステムも可動部分が少ないほど堅牢です。構成に含まれるものの良い指標は、コードを移動するたびに編集する必要があるということです。編集を必要としないものは、定数としてコードに残すことができます。

導入を自動化します。ローカルマシンでBashスクリプトを使用して実行できます。を介してリモートマシン上で任意のコマンドを実行できることに注意してくださいssh。例えば：

svn export yourprojectpath /tmp/exportedproject
tar czf /tmp/yourproject.tgz /tmp/exportedproject
scp /tmp/myproject.tgz youruser@remotemachine:~/dev

## Remote commands are in the right hand side, between ''
ssh youruser@remotemachine 'tar xzf ~/dev/yourproject.tgz'
ssh youruser@remotemachine 'qsub ~/dev/yourproject/script.py'

これが機能するためには、もちろん、ローカルマシンとリモートマシンの間に設定された、公開鍵/秘密鍵に基づくパスワードなしのログインが必要です。

これ以上必要な場合は、Pythonのファブリックまたはより高度な料理を使用することを考えることができます。