メインコンテンツまでスキップ

SSHホストとSlurmセットアップ

:::info[ジョブを提出する前に] SSHホストを設定し、リモートジョブを送信する前にDirect SSHまたはSlurmを選択します。 保存されたホストプロファイルは、認証または実行の成功を確立しません。 :::

Settings → Compute を使用して、サーバーまたはクラスターを登録します。 ホストを登録し、会話に利用できるようになり、ジョブの完了は別のマイルストーンです。 サイトのログインノードのルールとスケジューラの要件をホストノートで保持します。

ジョブが実行する場所を選択

実行モードジョブの実行コマンドコール適切な環境
Direct SSHSSHログインホストに直接SSHログインホストで直接ワークロードが許される機械
SlurmSlurmによる提出と管理SSHのログインホストにはまだスケジュールされた割り当てを必要とするクラスター

Slurm を選択すると、すべてのコマンドを計算ノードに移動しません。 将来のSlurmジョブに割り当てられたリソースとして、ログインホストCPU、RAM、GPU情報を解釈しないでください。 結果を解釈する前に、実際の位置を調べます。

接続を追加します。

Add SSH host を選択します。 既存のエイリアスを選択するか、ホスト識別子を入力します。 SSH 設定認証と Direct SSH 実行へのフォームデフォルト。

フィールドまたは制御入力および効果
From ~/.ssh/config発見されたエイリアスを選択します。 エイリアスが利用できない場合、無効
Or type a host alias必要なホスト/エイリアス、トリミング後の1-255文字。 NULまたはラインブレイクなし
オプションのホストノートスケジューラルール、パーティション/アカウント、モジュール、パッケージインストールポリシーおよび環境の場所。 最大 32,768 文字
Execution modeDirect SSHかSlurm; ホストごとに保存
SSH configuration接続設定を解決する ssh -G; 既存の SSH 構成、キーまたは ssh-agent を使用します。
Advanced settings → Userオプションのオーバーライド; blankはSSHの決断を維持します
PortSSH の構成のために任意; 供給される場合、整数 1-65535
Identity fileオプションのキーファイルオーバーライド。 blank は、設定/エージェントの動作を使用します。
Username and passwordユーザー、ポート、パスワードが必要です。 キーやssh-agentは使用しません
Cancelフォームを登録せずに退去
Add有効な接続を送信して下さい; パスワード認証は、ホストが追加される前に接続テストを渡す必要があります

英語 SSH の設定オーバーライド

パスワード認証と実際のフォームで選択したSlurm

パスワードモードは、アプリケーションのパスワード認証と安全なストレージ機能に依存します。 利用できない場合は、フォームに表示されている理由を調べてください。 ホストノートやエージェントリクエストではなく、そのフィールドに資格情報を入力します。

SSH-configuration ホストの場合、アプリはレコードを作成し、詳細ビューを開き、バックグラウンドプローブを開始します。 したがって、追加の行は認証や計算の可読性を証明しません。 タスクが使用できるようにする前のプローブ結果を読みます。

パスワード保護された研究サーバーを接続して下さい

  1. Settings → Compute → Add SSH host を開きます。 サーバーアドレスまたはエイリアスを入力します。
  2. Username and passwordを選択し、UserPortPasswordを入力し、Addを選択します。 管理者が指定したポートを使用する。 サーバはポート22を使用します。
  3. アプリケーションが The SSH host key is unknown. Verify it in a terminal before connecting. を報告したら、ホストの信頼を最初に確立して下さい。 同じホストに接続し、システムSSHクライアントとポートを接続し、表示された指紋を管理者の指紋と比較し、一致したときにのみ受け入れます。 アプリに戻り、Addを再試行します。 ホストキーのチェックを無効にして、メッセージを解除しないでください。
  4. Last probe succeededを待ちます。 Configuration では、認証方法と最終検証時間 Credential configured を確認します。 保存されたパスワードは、Configured · cannot be viewed マークされています。
  5. 既存の接続の確認や変更を行うには、Configuration → Edit を開き、Test and save を使用します。 認証を変更する前に通知を読みます。セッションの有効化と権限付与は、新しい設定がコミットしたときに消去されます。 意図したセッションのホストを再有効化します。

英語の例では、成功したパスワード認証プローブ:256 CPU、504 GB RAM、1 NVIDIA A100 80GB PCIeと検出されたSlurmスケジューラを示しています。 設定されたモードは、明示的に変更するまでDirect SSHのままです。 これらは、最小限の要件やスケジュールされた割り当てではなく、このサーバーのログインホストリソースです。 ホストとアカウントの識別子はスクリーンショットで隠されています。

パスワード認証とホストリソースプローブの成功

ホストの詳細を調べて維持する

セクションまたはボタン確認する
Probe / Retry probe接続/リソースの検出をリフレッシュ。 プローブ、プローブ、最終プローブが成功し、プローブが失敗しない
Resources / Login host resourcesCPU、メモリ、GPUおよびスケジューラ情報を検出しました; スケジューラ割り当ては別々の容量を持っています
Configuration → Edit認証設定と現在の認証状態を調べる
Test and save保存する前に、候補認証設定をテストします。 変更された構成は、セッションの有効化と許可の付与をクリアします。 変更されていない設定は、設定が既に最新であるというレポートです。
Execution mode → Edit → Save設定されたモードを変更します。 検出されたスケジューラとそれを比較して下さい
Details → Editホスト固有の指示を更新します。 コミットを保存します。, ディスクをキャンセルします。
もっと表示/非表示表示長いメモを拡張または崩壊
Scratch root → Editリモートの一時的な作業パスをピン留めされた値として保存する
Restore auto-detectionピン留めされた傷をオーバーライドし、将来のプロービングはそれを供給することができます削除します
Concurrent job limit → Edit1から500に整数を設定。 表示されるデフォルトは 10 です
ホストの取り外しアプリケーションの削除ダイアログと有効ジョブの制限を確認する前に、

スクラッチルートは、リモートホストのパスです。 ノートパソコンのアーティファクトディレクトリではありません。 アカウントがそこに書き込むことができることを確認し、サイトのクリーンアップポリシーは結果を収集するのに十分な時間を与えます。 同時ジョブの制限は、スケジューラのクォータやリソースの制限を置き換えません。

ジョブスクラッチディレクトリを選択します。

Scratch root → Edit を開き、サーバーに承認された書き込み可能な絶対パスを入力し、Save を実行します。 PINNED は、後で Probe が選択を保存します。 最初のジョブの作業ディレクトリと出力を調べて、書き込みアクセスを確認します。

Concurrent job limit → Edit を起動し、1 を入力し、Save を選択します。 これは、このホスト上のアプリ管理ジョブを一度に制限します。 CPU を留保せず、メモリ制限を強制したり、他のユーザが実行中の作業を阻止したりしません。 制限を下げると、既存のジョブを停止しません。 その後のプローブがスクラッチパスを再度供給したい場合にのみ、Restore auto-detectionを使用してください。

検出されたリソースからホストの指示を別々に保つ

保存されたホストの指示はResourcesの独立しています。 成功したプローブは、セットアップの指示を作成しず、空の指示は、プロービングが失敗したという意味ではありません。 Detailsのスケジューラポリシー、環境の活発化および再現可能なセットアップのステップを保って下さい; リソース内の CPU/RAM/GPU 検出を読み込みます。

エージェントが指示を更新するときは、保存された文書を最初に読み、その正確な現在のコンテンツを置き換える必要があります。 別の編集が変更された場合、再試行の前に再読し、比較して下さい。 プローブの要約を置換するドキュメントとして使用しないでください。 ホストの指示の契約.

タスクに利用可能なホストを作る

会話のAgent controlsでは、コンピュートホストの可用性と選択を調べます。 選択したホストも有効にする必要があります。 意図したホストと実行モードをローカルで実行できるタスクに名前を付けます。 科学的なワークロードを提出する前に、レシート、ログ、出力を検査するのに十分な最初のリモートリクエストを小さくしてください。

Slurmでは、クラスターの所有者から正しいアカウント/パーティション、リソース要求、壁時間、モジュール/環境設定およびスクラッチポリシーを取得します。 sbatchsqueuesacctscancelの可用性は、スケジューラ操作をサポートしています。 単独でプレゼンスは、投稿権限を確立しません。

研究のワークロードの前にホストをチェックする

ステージ移動前のチェック
コネクション成功したプローブと認証された接続。
ダイレクトジョブ小さい承認された仕事、出口の状態、読みやすいログおよび取られた出力。
Slurm ジョブスケジューラレシート/ジョブID、実際の割り当て、最終状態および取得された出力。
再接続後の回復アプリは、同じリモートジョブを再構成します。 重複を提出していない。
キャンセルスケジューラ/プロセスは、停止していることを確認します。 クリーンアップ前に保持された出力を点検して下さい。
GPUのワークロードSSHアクセスに加えて、必要な環境、重量、メモリ、および科学的な出力チェック。

ソースレビュー: add-host フォーム認証フィールドホストの詳細接続検証およびセッションホストの選択

リモートRNA-seq品質チェックを実行します

リモートRNA-seq品質チェックを実行します

実践例 RNA-seq品質チェックをDirect SSHで実行する

ノートパソコンから解析をサーバーに移動するときに同じパブリックGSE60450カウントマトリクスを使用します。 既知の結果を比較すると、科学的方法の変化からコンピュート構成の問題を区別するのに役立ちます。

  1. 研究プロジェクトで会話を作成し、元のカウントマトリクスを添付します。
  2. Agent controls → Compute を開きます。 ホストを有効にすると、ターゲットの実行 にそれを追加します。 在庫および選択は別の制御です; 単にSettings でホストを登録することは、この会話では選択しません。
  3. Direct SSH ジョブを要求し、入力と必要な出力を名前付け、制限を指定してください。 この例では、1つのCPUスレッド、1 GiBメモリの天井と120秒のランタイムを使用します。 サーバのデフォルト Python は十分です。 パッケージのインストールは必要ありません。
  4. Allow remote job submission? が現れたら、HostIntentInputsExecution modeTimeoutRemote workdir を点検して下さい。 Show full command を拡張し、スクリプト全体を検査します。 Onceはこの投稿を承認しました。 スコープは、その後の操作に適用される。 スコープを意図的に選択します。
  5. 返されたJob IDを保って下さい。 ジョブチップまたはBackground tasksを開き、そのジョブを検査します。 実行中に会話を残すことができます。 応答が終了したため、別のコピーを提出しないでください。
  6. 完了後、Remote job details を開きます。 StatusRuntimeJob IDRemote workdirをチェックしてください。 Refresh は、現在のビューで、stdout または stderr を使用して、各ログを検査します。 リモートワークダーボタンは、ジョブのリモートディレクトリを開きます。
  7. 結果の収集とフォローアップの応答を待ってから、公開されたCSVとレポートを開きます。 巧妙な計算、ファイル収集およびアーティファクトの出版物は別の段階です。 完了したジョブは、予想されるファイルの両方が公開されたこと自体が確立されていない。

例: リクエスト

選択したDirect SSHホストを使用して、付属のGSE60450カウントマトリクスで記述QCを実行します。 入力を保存します。 各サンプルでは、合計カウント数、ゼロカウント遺伝子、検出遺伝子、および中央正数を計算します。 CSV を保存し、寸法と前後の SHA-256 で短いメソッドレポートを作成します。 1つのCPUの糸、パッケージのインストールおよび120秒のランタイムの限界を使用して下さい。 提出後、ジョブ ID を返します。 終了すると出力を収集し、公開します。 カウントを正規化したり、生物学的な結論をしたりしないでください。

成功事例 と終了コード 0 の後、アプリが出力と保存されたテーブルとレポートのリオープンを収集することを確認します。 フルサンプル識別子とメトリックを共有ベースラインと比較し、リモート計算前後の入力ハッシュを確認します。 このDirect SSHの例は、これらのチェックを渡しました。

Direct SSH ジョブを ID と作業ディレクトリで完了

すべての12のサンプルが付いているReopenedリモートRNA-seq QCのテーブル

QCのテーブル方法報告 の例をダウンロードします。 これらの生計チェックは、正規化、実験的設計検討、差圧解析を置き換えません。 正反対のメディアンはゼロを除外します。

アプリを再起動した後にジョブに戻る

同じプロジェクトと会話を開き、Compute またはジョブの Background tasks エントリを使用します。 Job IDを元のレシートと比較し、アクションを取る前に。 復元された仕事は既存のリモート・ワークロードです; 新しい会話を始めるか、またはプロンプトを再送信することは回復ステップではありません。

ローカルアプリが再起動したときに、以下に示す別の準備チェックポイントが実行されました。 アプリは同じジョブ ID を回復し、完了ログを収集しました。 待ち時間は正常に終了します。 このスクリーンショットは、キャンセルや科学的な計算ではなく、回復を実証します。

アプリケーションを再起動した後、同じ準備ジョブが回復しました

1つのリモートジョブをキャンセルする

Background tasks を開き、意図したジョブを選択し、その Job ID をレシートで比較します。 Back は、セッションのジョブリストに戻ります。 Cancel は、そのジョブの詳細ビューで、ボタンが Cancelling を表示している間待ちます。その後、Refresh を使用して Cancelled を確認します。 詳細なダイアログを閉じたり、会話の応答を終了しても、リモートワークロードをキャンセルしません。

以下の準備チェックポイントは、この制御でキャンセルされました。 リモート・プロセスは独立して前方に不在確認されました。 既存のログは読みやすくなります。 これは、キャンセルされた生成された分析が完全な結果に及ぼすことを意味するものではありません。 保存したファイルを使用する前に検査します。

選択された準備の仕事のために確認されるキャンセル

Slurmで送信し、割り当てをチェックする

  1. Settings → Compute でホストを開き、Execution mode → Edit → Slurm → Save を選択し、設定を再開して確認します。 Detected scheduler単独ではモードを選択していません。
  2. 意図した会話でホストを有効にして選択します。 サイトのパーティション/アカウントと読み取り可能なスケジューラの経理を長い分析を実行する前に確認します。
  3. ラインごとの1つの#SBATCH --option=value命令を使用してリソースを要求して下さい。 この例は使われます:
#SBATCH --partition=local
#SBATCH --cpus-per-task=1
#SBATCH --mem=1G
#SBATCH --time=00:03:00

localを無条件にコピーするのではなく、サイトのパーティションを使用します。 ジョブの120秒のワークロードのタイムアウトは、スケジューラの3分の割り当ての制限から分離されます。 キューされたジョブが起動するのをすぐに判断することができません。 アプリケーションは、ジョブ名、作業ディレクトリ、stdout/stderr パスを管理します。

  1. Job IDscheduler_job_id の両方を保存します。 スケジューラIDは、初期の提出受領後に到着することができます。 保存したジョブのステータスを読み取り、エージェントに問い合わせてください。 最初のレシートがスケジューラIDを欠いているため、再び提出しないでください。
  2. 要求されたリソースを実際の割り当てと比較します。 例では、タスクごとに1 CPU と 1 GiB を要求しました。 Slurmは1つのタスクと2つの割り当てられた論理CPUを記録しました。 リソース使用を説明する際にスケジューラの割り当てレコードを使用します。
  3. 確認された端末の状態を待ってから、結果を公開する前にファイルを収集します。 サーバ側の出力ファイルは、アプリケーションがそれを収穫したことを確立しません。

Slurm は、ホストの実行モードで明示的に選択した

サーバが完了したが、アプリが待ち続けるとき

アプリのスナップショットが last_poll_error を報告する場合、既存のジョブ ID を保持し、正確なエラーを要求します。 観察された経理の失敗は:

slurm_poll_failed: Slurm accounting storage is disabled

スケジューラが完了 / 終了コード 0:0を示しているが、アプリは提出書類result_final 偽物、または収集されていないファイルが表示された場合は、ジョブIDの両方を保ち、ポーリングエラーを検査します。 スケジューラの完成と適用結果のコレクションを別々の段階として扱います。

アプリケーションはまだ完了したSlurmのワークロードのための末端の状態を待っています

クラスター管理者にアカウントとジョブの sacct の会計機能を提供するように依頼してください。 squeue は、もはや仕事のリストを主張することは、成功の不十分な証拠ではありません。 会計が修理される間、既存の仕事のディレクトリおよび仕事 ID を保って下さい、そして同じ仕事を再度点検して下さい。 監視エラーをクリアするために、完了した解析を再サブミットしないでください。 Slurmのキャンセル、回復および適用収穫はこの環境の条件が解決されるまで保留します。

GPUで小さなタンパク質シーケンスデザインを実行

GPUで小さなタンパク質シーケンスデザインを実行

実践例 GPU で ProteinMPNN で 1 個のユビキチンシーケンスを設計

パブリック 1UBQウビキチン構造 を使用して、1 つのチェーン A 候補を ProteinMPNN で生成します。 これは、リモートGPU実行と出力検査をチェックします。 新しい構造を予測したり、ubiquitin 関数を確立したりすることはできません。

  1. Computeで接続されたホストを選択します。 無料のGPUメモリと現在のロードを確認し、小さなタスクの直接実行が許可されていることを確認します。 スケジュール管理クラスターでは、許可されたパーティションとアカウントを使用します。
  2. 分離された環境を準備し、Python、PyTorch/CUDAおよび依存性の目録を維持するために代理店に尋ねて下さい。 Python 3.10、PyTorch 2.5.1+cu124、NumPy 1.26.4 を使用した例です。 ホストの元のPythonはCPUだけPyTorchを持っていました; GPU単独で検出するのは不十分でした。
  3. 公式プロテインMPNNチェックアウトv_48_020 の重みをピンで止めます。 ダウンロードした1UBQ構造と重量のSHA-256を記録します。
  4. チェーンとりあえず1 つ 1 つ候補、バッチサイズ1、温度0.1、シード42180-秒実行限界を指定します。 その操作を承認する前に、アプリによって示されているリモートコマンドを調べます。
  5. stdout/stderr、終了ステータス、モデルのパラメータデバイスが必要です。 CUDA available=True単独では、GPUを使用した推論は証明しません。 parameter_device=cuda:0parameter_is_cuda=True を収録しました。
  6. 生成されたFASTAを調べます。 独立して長さ、アミノ酸のアルファベットを調べ、ネイティブチェーンとfiniteスコアにマッチし、入力ハッシュを再度確認します。
チェックインこの例の結果
デバイスNVIDIA A100 80GB PCIe; 実際にCUDAのモデル変数
入力/出力長さネイティブチェーンAと76残留物の両方の候補
アルファベットとスコア標準的な20-amino-acidのアルファベット; 0.8568の有限スコア/グローバルスコア
ネイティブマッチ42/76; 独立して評判の回復0.5526316
導入事例モデルおよび独立した検証は0を終了しました; モデル報告された世代の時間 0.1949秒はセットアップおよび完全な仕事を除いてします
入力整合性前後のIdentical構造SHA-256

GPU認証レコードをダウンロード. デバイスの80 GB容量は、この小さなタスクの最小要件ではありません。 ピークメモリは測定されません。 リモート・ログおよびファイルは自動的に完全なローカルNotebookの証明を提供しません。

この例では、承認された直接SSHコマンドを使用します。 以前のSlurm投稿はInvalidアカウントを返すので、この結果はSlurm GPUジョブを検証しません。 そのエラーが発生したときにパーティション/アカウントの承認を確認してください。 スケジューラサービスを変更したり、必要なキューをバイパスしたりしないでください。

SSHとジョブエラーの解決

コードとメッセージの両方を読みます。 接続エラー、スケジューラ拒否、失敗したプログラムには異なる修正が必要です。 下の識別子は、接続とジョブの状態を計算します。 インターフェイスは、生のコードの代わりに記述的なメッセージを表示することができます。

接続とリモートファイル

メッセージまたは識別子意味する次のアクションと成功チェック
The SSH host key is unknown. Verify it in a terminal before connecting.システム SSH クライアントは、このホストとポートの信頼されるキーを持っていません。管理者と指紋を検証し、ホストの信頼をシステムSSHクライアントに確立し、再試行します。 Add または Test and save. ホストキーチェックを無効にしないでください。
Permission denied (publickey)SSHキー認証が失敗しました。 リモート・ファイル分類器はこれをように扱います connection.ユーザ、IDファイル、ホストエイリアス、ssh-agentをチェックします。 管理者がそのキーを承認することを確認します。 利用条件 Test and save, それから Retry probe.
Connection refused / No route to host / 接続 timeoutSSHの輸送は、接続の到達または確立はできません。ホスト、ポート、ネットワーク/ VPN およびサーバーの可用性を確認します。 原因を修正した後、接続を再試行します。
ENOENT / not_foundリクエストされたリモートパスは存在しません。ノートパソコンではなく、リモートホストのパスを確認してください。 正しいディレクトリまたはファイルを開きます。
EACCES / EPERM / permission接続されたアカウントは、そのファイルシステム動作を実行できません。ホスト管理者に連絡して、アクセスの確認や、承認されたスクラッチディレクトリの選定を行ってください。 同じ操作を繰り返します。
outside_rootsリモートファイルパス検証は、非絶対パスまたは制御文字を拒否しました。ラインブレーク/制御文字なしで絶対リモートパスを供給します。 別のレイヤーがパスを拒否した場合、全エラーを確認します。

ジョブレコード

エラーコード意味する次のアクション
approval_denied要求された操作は承認を受けませんでした。意図したコマンドとスコープを確認します。 その作業を承認したい場合は、新しいリクエストを提出してください。
host_unreachableアプリは、ホスト操作にアクセスしたり、確認したりできません。接続を復元し、ホストをプローブします。 提出が発生した場合、再試行する前に、既存のリモートジョブをチェックしてください。
invalid_resourcesリソース引数または Slurm ディレクティブは検証に失敗しました。名前付きフィールド/ディレクティブを読んでください。 受け入れられたリソースフォーマット、クラスター制限、および任意のアプリ管理ディレクティブ制限に従ってください。 そのフィールドを修正した後のリトリート。
dispatch_failed起動またはスケジューラ投稿が失敗しました。stderr と任意の読み込み sbatch メッセージ。 パーティション/アカウント、環境、コマンドを確認します。 提出前にスケジューラの領収書を確認してください。
job_failed仕事は失敗しました。出口コードおよびstdout/stderrを読んで下さい、プログラムか環境を修理して下さい、そして小さいテストを実行して下さい。
timeout接続、コマンド、またはジョブが制限を超えた場合 このコードは無効なコードです。 timeout_seconds.同行メッセージを使用して、経過した時刻から無効な入力を区別します。 制限または再実行を変更する前に、既存のジョブの状態を確認してください。
process_vanished追跡または回復はもはや予想されるプロセスを見つけることができませんでした。リモートワークディレクトリ、ログ、スケジューラ履歴を調べます。 交換ジョブを作成する前に、作業が停止または完了したかどうかを確立します。

ジョブの最終ステータスではなく、last_poll_error 監視エラーです。。 同様に、harvest_errorは結果のコレクションが注目を必要としていることを意味します。 計算は既に終了している可能性があります。 ジョブ ID を保存し、コネクティビティを復元し、別のコピーを開始する前に既存のジョブを検査します。

成功した回復は、意図したジョブの最終状態、解釈可能な出口の状態およびアクセス可能な出力を示す必要があります。 Slurmの場合、スケジューラジョブIDとアプリジョブIDを確認してください。 エラーが疑われる場合は、バグを報告するか、コミュニティに尋ねるに従ってください。 実行モード、利用可能なID、フルエラー、およびサニタイズされたログ出力の両方を含みます。

SSHキー/コンフィグ認証は、使用可能なキーまたはホストエイリアスを供給し、送信前に接続を検証します。 Slurm結果の収集は、選択したアカウントの作業会計を必要とします。 アプリがジョブを解決できない場合は、上記のチェックに従ってください。

ソース: ジョブコードとレコードフィールドを計算するSSH/file エラー分類Slurm 投稿検証