Slurm Federated Scheduling Guide
- Overview
- Configuration
- Federated Job IDs
- Job Submission
- Job Scheduling
- Job Requeue
- Interactive Jobs
- Canceling Jobs
- Job Modification
- Job Arrays
- Status Commands
- Glossary
- Limitations
Overview
Slurm version 17.11 includes support for creating a federation of clusters
and scheduling jobs in a peer-to-peer fashion between them.
Slurmバージョン17.11には、クラスターのフェデレーションを作成し、クラスター間でピアツーピア方式でジョブをスケジュールするためのサポートが含まれています。
Jobs submitted to a
federation receive a unique job ID that is unique among all clusters in the
federation.
フェデレーションにサブミットされたジョブは、フェデレーション内のすべてのクラスター間で一意の一意のジョブIDを受け取ります。
A job is submitted to the local cluster (the cluster defined in the
slurm.conf) and is then replicated across the clusters in the federation.
ジョブはローカルクラスター(slurm.confで定義されているクラスター)に送信され、フェデレーション内のクラスター間で複製されます。
Each
cluster then independently attempts to the schedule the job based off of its own
scheduling policies.
次に、各クラスターは、独自のスケジューリングポリシーに基づいて、独立してジョブのスケジューリングを試みます。
The clusters coordinate with the "origin" cluster (cluster
the job was submitted to) to schedule the job.
クラスターは、「元の」クラスター(ジョブが送信されたクラスター)と調整して、ジョブをスケジュールします。
NOTE: This is not intended as a high-throughput environment.
注:これは、高スループット環境を意図したものではありません。
If
scheduling more than 50,000 jobs a day, consider configuring fewer clusters that
the sibling jobs can be submitted to or directing load
to the local cluster only (e.g. --cluster-constraint= or -M submission options
could be used to do this).
1日に50,000を超えるジョブをスケジュールする場合は、兄弟ジョブを送信できるクラスターの数を少なくするか、ローカルクラスターのみに負荷を転送することを検討してください(たとえば、-cluster-constraint =または-M送信オプションを使用してこれを行うことができます)。
Configuration
A federation is created using the sacctmgr command to create a federation in the
database and by adding clusters to a federation.
フェデレーションは、sacctmgrコマンドを使用してデータベースにフェデレーションを作成し、クラスターをフェデレーションに追加することによって作成されます。
To create a federation use:
フェデレーションを作成するには、次のようにします。
sacctmgr add federation <federation_name> [clusters=<list_of_clusters>]Clusters can be added or removed from a federation using:
クラスターは、以下を使用してフェデレーションに追加またはフェデレーションから削除できます。
NOTE: A cluster can only be a member of one federation at a time.
注:クラスターは、一度に1つのフェデレーションのメンバーにしかなれません。
sacctmgr modify federation <federation_name> set clusters[+-]=<list_of_clusters> sacctmgr modify cluster <cluster_name> set federation=<federation_name> sacctmgr modify federation <federation_name> set clusters= sacctmgr modify cluster <cluster_name> set federation=NOTE: If a cluster is removed from a federation without first being drained, running jobs on the removed cluster, or that originated from the removed cluster, will continue to run as non-federated jobs.
注:クラスターが最初に排出されずにフェデレーションから削除された場合、削除されたクラスターで実行中のジョブ、または削除されたクラスターから発生したジョブは、引き続き非フェデレーションジョブとして実行されます。
If a job is pending on the origin cluster, the job will remain pending on the origin cluster as a non-federated job and the remaining sibling jobs will be removed.
ジョブがオリジンクラスターで保留中の場合、ジョブは非フェデレーションジョブとしてオリジンクラスターで保留のままになり、残りの兄弟ジョブは削除されます。
If the origin cluster is being removed and the job is pending and is only viable on one cluster then it it will remain pending on the viable cluster as a non-federated job.
オリジンクラスターが削除され、ジョブが保留中であり、1つのクラスターでのみ実行可能である場合、非フェデレーションジョブとして実行可能クラスターで保留状態のままになります。
If the origin cluster is being removed and the job is pending and viable on multiple clusters other than the origin cluster, then the remaining pending jobs will remain pending as a federated job and the remaining sibling clusters will schedule amongst themselves to start the job.
オリジンクラスターが削除され、ジョブが保留中であり、オリジンクラスター以外の複数のクラスターで実行可能である場合、残りの保留中のジョブはフェデレーションジョブとして保留のままになり、残りの兄弟クラスターはジョブを開始するようにスケジュールされます。
Federations can be deleted using:
フェデレーションは、次を使用して削除できます。
sacctmgr delete federation <federation_name>Generic features can be assigned to clusters and can be requested at submission using the --cluster-constraint=[!]<feature_list> option:
汎用機能はクラスターに割り当てることができ、送信時に--cluster-constraint = [!] <feature_list>オプションを使用して要求できます。
sacctmgr modify cluster <cluster_name> set features[+-]=<feature_list>A cluster's federated state can be set using:
クラスターのフェデレーション状態は、以下を使用して設定できます。
sacctmgr modify cluster <cluster_name> set fedstate=<state>where possible states are:
可能な状態は次のとおりです。
- ACTIVE: Cluster will actively accept and schedule federated
jobs
アクティブ:クラスターは、フェデレーションジョブをアクティブに受け入れてスケジュールします - INACTIVE: Cluster will not schedule or accept any jobs
非アクティブ:クラスターはジョブをスケジュールまたは受け入れません - DRAIN: Cluster will not accept any new jobs and will let
existing federated jobs complete
DRAIN:クラスターは新しいジョブを受け入れず、既存のフェデレーションジョブを完了させます - DRAIN+REMOVE: Cluster will not accept any new jobs and will
remove itself from the federation once all federated jobs have
completed.
DRAIN + REMOVE:クラスターは新しいジョブを受け入れず、すべてのフェデレーションジョブが完了すると、フェデレーションから自身を削除します。
When removed from the federation, the cluster will accept jobs as a non-federated cluster
フェデレーションから削除されると、クラスターは非フェデレーションクラスターとしてジョブを受け入れます
フェデレーション構成は、以下を使用して表示できます。
sacctmgr show federation [tree] sacctmgr show cluster withfedAfter clusters are added to a federation and the controllers are started their status can be viewed from the controller using:
クラスターがフェデレーションに追加され、コントローラーが開始された後、それらのステータスは、以下を使用してコントローラーから表示できます。
scontrol show federationBy default the status commands will show a local view.
デフォルトでは、ステータスコマンドはローカルビューを表示します。
A default federated view can be set by configuring the following parameter in the slurm.conf:
デフォルトのフェデレーションビューは、slurm.confで次のパラメーターを構成することで設定できます。
FederationParameters=fed_display
Federated Job IDs
When a job is submitted to a federation it gets a federated job id.ジョブがフェデレーションに送信されると、フェデレーションジョブIDが取得されます。
Job ids in the federation are unique across all clusters in the federation.
フェデレーション内のジョブIDは、フェデレーション内のすべてのクラスターで一意です。
A federated job ID is made by utilizing an unsigned 32 bit integer to assign the cluster's ID and the cluster's local ID.
フェデレーションジョブIDは、符号なし32ビット整数を使用してクラスターのIDとクラスターのローカルIDを割り当てることによって作成されます。
Bits 0-25: Local Job ID Bits 26-31: Cluster Origin IDFederated job IDs allow the controllers to know which cluster the job was submitted to by looking at the cluster origin id of the job.
フェデレーテッドジョブIDを使用すると、コントローラーは、ジョブのクラスター起点IDを確認することにより、ジョブが送信されたクラスターを知ることができます。
Job Submission
When a federated cluster receives a job submission, it will submit copies of the
job (sibling jobs) to each eligible cluster.
フェデレーションクラスターは、ジョブの送信を受信すると、対象となる各クラスターにジョブ(兄弟ジョブ)のコピーを送信します。
Each cluster will then
independently attempt to schedule the job.
その後、各クラスターは個別にジョブのスケジュールを試行します。
Jobs can be directed to specific clusters in the federation using the
-M,--clusters=<cluster_list> and the new
--cluster-constraint=[!]<constraint_list> options.
-M、-clusters = <cluster_list>および新しい--cluster-constraint = [!] <constraint_list>オプションを使用して、フェデレーション内の特定のクラスターにジョブを送信できます。
Using the -M,--clusters=<cluster_list> the submission command
(sbatch, salloc, srun) will pick one cluster from the list of clusters to submit
the job to and will also pass along the list of clusters with the job.
-M、-clusters = <cluster_list>を使用すると、送信コマンド(sbatch、salloc、srun)は、ジョブを送信するクラスターのリストから1つのクラスターを選択し、ジョブとともにクラスターのリストも渡します。
The
clusters in the list will be the only viable clusters that siblings jobs can be
submitted to.
リスト内のクラスターは、兄弟ジョブを送信できる唯一の実行可能なクラスターになります。
For example the submission:
例:提出:
cluster1$ sbatch -Mcluster2,cluster3 script.shwill submit the job to either cluster2 or cluster3 and will only submit sibling jobs to cluster2 and cluster3 even if there are more clusters in the federation.
フェデレーションにさらにクラスターがある場合でも、ジョブをcluster2またはcluster3のいずれかに送信し、兄弟ジョブのみをcluster2およびcluster3に送信します。
Using the --cluster-constraint=[!]<constraint_list> option will
submit sibling jobs to only the clusters that have the requested cluster
feature(s) -- or don't have the feature(s) if using !.
--cluster-constraint = [!] <constraint_list>オプションを使用すると、要求されたクラスター機能があるクラスターのみに兄弟ジョブが送信されます。!を使用している場合は、機能がありません。
Cluster features
are added using the sacctmgr modify cluster <cluster_name> set
features[+-]=<feature_list> option.
クラスター機能は、sacctmgr modify cluster <cluster_name> set features [+-] = <feature_list>オプションを使用して追加されます。
NOTE: When using the ! option, add quotes around the option to
prevent the shell from interpreting the ! (e.g
--cluster-constraint='!highmem').
注:!を使用する場合 オプションの場合、シェルが!を解釈しないように、オプションの前後に引用符を追加します。(例:-cluster-constraint = '!highmem')。
When using both the --cluster-constraint= and
--clusters= options together, the origin cluster will only submit
sibling jobs to clusters that meet both requirements.
--cluster-constraint =オプションと--clusters =オプションの両方を一緒に使用する場合、オリジンクラスターは、両方の要件を満たすクラスターにのみ兄弟ジョブを送信します。
Held or dependent jobs are kept on the origin cluster until they are released
or are no longer dependent, at which time they are submitted to other viable
clusters in the federation.
保持されているジョブまたは依存しているジョブは、解放されるか依存しなくなるまで元のクラスターに保持され、依存しなくなると、フェデレーション内の他の実行可能なクラスターに送信されます。
If a job becomes held or dependent
after being submitted, the job is removed from every cluster but the origin.
送信後にジョブが保留または依存するようになると、ジョブはオリジン以外のすべてのクラスターから削除されます。
Job Scheduling
Each cluster in the federation independently attempts to schedule each job with
the exception of coordinating with the origin cluster (cluster where the
job was submitted to) to allocate resources to a federated job.
フェデレーション内の各クラスターは、元のクラスター(ジョブが送信されたクラスター)と調整してリソースをフェデレーションジョブに割り当てることを除いて、各ジョブを個別にスケジュールしようとします。
When a cluster
determines it can attempt to allocate resources for a job it communicates with
the origin cluster to verify that no other cluster is attempting to allocate
resources at the same time.
クラスターは、ジョブにリソースを割り当てようとすると判断すると、元のクラスターと通信して、他のクラスターが同時にリソースを割り当てようとしていないことを確認します。
If no other cluster is attempting to allocate
resources the cluster will attempt to allocate resources for the job.
他のクラスターがリソースを割り当てようとしていない場合、クラスターはジョブにリソースを割り当てようとします。
If it
succeeds then it will notify the origin cluster that it started the job and the
origin cluster will notify the clusters with sibling jobs to remove the sibling
jobs and put them in a revoked state.
成功すると、元のクラスターにジョブを開始したことを通知し、元のクラスターは兄弟ジョブのあるクラスターに通知して、兄弟ジョブを削除し、取り消された状態にします。
If the cluster was unable to
allocate resources to the job then it lets the origin cluster know so that other
clusters can attempt to schedule the job.
クラスターがリソースをジョブに割り当てることができなかった場合は、元のクラスターに通知して、他のクラスターがジョブのスケジュールを試行できるようにします。
If it was the main scheduler
attempting to allocate resources then the main scheduler will stop looking at
further jobs in the job's partition.
リソースを割り当てようとしているのがメインスケジューラであった場合、メインスケジューラはジョブのパーティション内のそれ以上のジョブの検索を停止します。
If it was the backfill scheduler attempting
to allocate resources then the resources will be reserved for the job.
リソースを割り当てようとしたのがバックフィルスケジューラであった場合、リソースはジョブ用に予約されます。
If an origin cluster is down, then the remote siblings will cooridinate with a
job's viable siblings to schedule the job.
オリジンクラスターがダウンしている場合、リモート兄弟はジョブの実行可能な兄弟と調整してジョブをスケジュールします。
When the origin cluster comes back
up, it will sync with the other siblings.
オリジンクラスターが復旧すると、他の兄弟と同期します。
Job Requeue
When a federated job is requeued the origin cluster is notified and the origin
cluster will then submit new sibling jobs to viable clusters and the federated
job is eligible to start on a different cluster than the one it ran on.
フェデレーションジョブが再キューイングされると、オリジンクラスターに通知され、オリジンクラスターは新しい兄弟ジョブを実行可能なクラスターに送信します。フェデレーションジョブは、実行されたクラスターとは異なるクラスターで開始する資格があります。
slurm.conf options RequeueExit and RequeueExitHold are controlled
by the origin cluster.
slurm.confオプションRequeueExitおよびRequeueExitHoldは、オリジンクラスターによって制御されます。
Interactive Jobs
Interactive jobs -- jobs submitted with srun and salloc -- can be submitted to
the local cluster and get an allocation from a different cluster.
対話型ジョブ(srunおよびsallocで送信されたジョブ)は、ローカルクラスターに送信して、別のクラスターから割り当てを取得できます。
When an salloc
job allocation is granted by a cluster other than the local cluster, a new
environment variable, SLURM_WORKING_CLUSTER, will be set with the remote sibling
cluster's IP address, port and RPC version so that any sruns will know which
cluster to communicate with.
ローカルクラスター以外のクラスターによってsallocジョブの割り当てが許可されると、新しい環境変数SLURM_WORKING_CLUSTERがリモート兄弟クラスターのIPアドレス、ポート、およびRPCバージョンで設定され、すべてのsrunが通信するクラスターを認識できるようになります。
NOTE: It is required that all compute nodes must be accessible to all
submission hosts for this to work.
注:これを機能させるには、すべての送信ホストがすべての計算ノードにアクセスできる必要があります。
NOTE: The current implementation of the MPI interfaces in Slurm require
the SlurmdSpooldir to be the same on the host where the srun is being run as it
is on the compute nodes in the allocation.
注:SlurmでのMPIインターフェースの現在の実装では、SlurmdSpooldirが、srunが実行されているホスト上で、割り当て内の計算ノード上と同じである必要があります。
If they aren’t, a workaround is to
get an allocation that puts the user on the actual compute node.
それらが窶冲でない場合、回避策は、ユーザーを実際の計算ノードに配置する割り当てを取得することです。
Then the sruns
on the compute nodes will be using the slurm.conf that corresponds to the
correct cluster.
次に、計算ノードのsrunは、正しいクラスターに対応するslurm.confを使用します。
For example, putting SallocDefaultCommand="srun -n1 -N1
--mem-per-cpu=0 --pty --preserve-env --mpi=none $SHELL" in the
slurm.conf will put the user on an actual compute node when using salloc.
たとえば、SallocDefaultCommand = "srun -n1 -N1 --mem-per-cpu = 0 --pty --preserve-env --mpi = none $ SHELL"をslurm.confに配置すると、ユーザーは実際の計算に参加します。 sallocを使用する場合のノード。
Canceling Jobs
Cancel requests in the federation will cancel the running sibling job or all
pending sibling jobs.
フェデレーションでのキャンセル要求は、実行中の兄弟ジョブまたはすべての保留中の兄弟ジョブをキャンセルします。
Specific pending sibling jobs can be removed by using
scancel's --sibling=<cluster_name> option to remove the
sibling job from the job's active sibling list.
scancelの--sibling = <cluster_name>オプションを使用して、ジョブのアクティブな兄弟リストから兄弟ジョブを削除することにより、特定の保留中の兄弟ジョブを削除できます。
Job Modification
Job modifications are routed to the origin cluster where the origin cluster will push out the changes to each sibling job.ジョブの変更はオリジンクラスターにルーティングされ、オリジンクラスターは各兄弟ジョブに変更をプッシュします。
Job Arrays
Currently, job arrays only run on the origin cluster.現在、ジョブ配列はオリジンクラスターでのみ実行されます。
Status Commands
By default, status commands, such as: squeue, sinfo, sprio, sacct, sreport, will
show a view local to the local cluster.
デフォルトでは、squeue、sinfo、sprio、sacct、sreportなどのステータスコマンドは、ローカルクラスターに対してローカルなビューを表示します。
A unified view of the jobs in the
federation can be viewed using the --federation option to each status
command.
フェデレーション内のジョブの統合ビューは、各statusコマンドの--federationオプションを使用して表示できます。
The --federation command causes the status command to first
check if the local cluster is part of a federation.
--federationコマンドを使用すると、statusコマンドは最初にローカルクラスターがフェデレーションの一部であるかどうかを確認します。
If it is then the command
will query each cluster in parallel for job info and will combine the
information into one unified view.
その場合、コマンドは各クラスターにジョブ情報を並行して照会し、情報を1つの統合ビューに結合します。
A new FederationParameters=fed_display slurm.conf parameter has been
added so that all status commands will present a federated view by default --
equivalent to setting the --federation option for each status command.
新しいFederationParameters = fed_display slurm.confパラメーターが追加され、すべてのステータスコマンドがデフォルトでフェデレーションビューを表示するようになりました。これは、各ステータスコマンドに--federationオプションを設定するのと同じです。
The federated view can be overridden using the --local option.
フェデレーションビューは、-localオプションを使用してオーバーライドできます。
Using the
--clusters,-M option will also override the federated view and give a
local view for the given cluster(s).
--clusters、-Mオプションを使用すると、フェデレーションビューがオーバーライドされ、指定されたクラスターのローカルビューが提供されます。
Using the existing --clusters,-M option, the status commands will output
the information in the same format that exists today where each cluster’s
information is listed separately.
既存の--clusters、-Mオプションを使用すると、statusコマンドは、各クラスターの情報が個別にリストされている現在と同じ形式で情報を出力します。
squeue
squeue also has a new --sibling option that will show each sibling job
rather than than merge them into one.
squeueには、兄弟ジョブを1つにマージするのではなく、表示する新しい--siblingオプションもあります。
Several new long format options have been added to display the job's federated
information:
ジョブのフェデレーション情報を表示するために、いくつかの新しい長い形式のオプションが追加されました。
-
cluster: Name of the cluster that is running the job or
job step.
cluster:ジョブまたはジョブステップを実行しているクラスターの名前。
-
siblingsactive: Cluster names of where federated sibling
jobs exist.
siblingsactive:フェデレーション兄弟ジョブが存在する場所のクラスター名。
-
siblingsactiveraw: Cluster IDs of where federated
sibling jobs exist.
siblingsactiveraw:フェデレーション兄弟ジョブが存在する場所のクラスターID。
-
siblingsviable: Cluster names of where federated sibling
jobs are viable to run.
siblingsviable:フェデレーション兄弟ジョブを実行できる場所のクラスター名。
-
siblingsviableraw: Cluster names of where federated
sibling jobs are viable to run.
siblingsviableraw:フェデレーション兄弟ジョブを実行できる場所のクラスター名。
squeue output can be sorted using the -S cluster option.
squeue出力は、-Sクラスターオプションを使用してソートできます。
sinfo
sinfo will show the partitions from each cluster in one view.
sinfoは、各クラスターのパーティションを1つのビューに表示します。
In a federated
view, the cluster name is displayed with each partition.
フェデレーションビューでは、クラスター名が各パーティションとともに表示されます。
The cluster name can be
specified in the format options using the short format %V or the long
format cluster options.
クラスター名は、短い形式の%Vまたは長い形式のクラスターオプションを使用して、形式オプションで指定できます。
The output can be sorted by cluster names using
the -S %[+-]V option.
-S%[+-] Vオプションを使用して、クラスター名で出力を並べ替えることができます。
sprio
In a federated view, sprio displays the job information from the local cluster
or from the first cluster to report the job.
フェデレーションビューでは、sprioは、ローカルクラスターまたはジョブをレポートする最初のクラスターからのジョブ情報を表示します。
Since each sibling job could have a
different priority on each cluster it may be helpful to use the --sibling
option to show all records of a job to get a better picture of a job’s priority.
各兄弟ジョブはクラスターごとに異なる優先度を持つ可能性があるため、-siblingオプションを使用してジョブのすべてのレコードを表示し、ジョブの優先度をより正確に把握すると役立つ場合があります。
The name of the cluster reporting the job record can be displayed using the
%c format option.
ジョブレコードを報告するクラスターの名前は、%c形式オプションを使用して表示できます。
The cluster name is shown by default when using
--sibling option.
--siblingオプションを使用すると、デフォルトでクラスター名が表示されます。
sacct
By default, sacct will not display "revoked" jobs and will show the job from the
cluster that ran the job.
デフォルトでは、sacctは「取り消された」ジョブを表示せず、ジョブを実行したクラスターからのジョブを表示します。
However, "revoked" jobs can be viewed using the
--duplicate/-D option.
ただし、「取り消された」ジョブは、-duplicate / -Dオプションを使用して表示できます。
sreport
sreport will combine the reports from each cluster and display them as one.
sreportは、各クラスターからのレポートを結合し、それらを1つとして表示します。
scontrol
The following scontrol options will display a federated view:
次のscontrolオプションは、フェデレーションビューを表示します。
- show [--federation|--sibling] jobs
- show [--federation] steps
- completing
The following scontrol options are handled in a federation.
次の制御オプションはフェデレーションで処理されます。
If the command is
run from a cluster other than the federated cluster it will be routed to the
origin cluster.
コマンドがフェデレーションクラスター以外のクラスターから実行された場合、コマンドは元のクラスターにルーティングされます。
- hold
- uhold
- release
- requeue
- requeuehold
- suspend
- update job
All other scontrol options should be directed to the specific cluster either by
issuing the command on the cluster or using the --cluster/-M option.
他のすべてのscontrolオプションは、クラスターでコマンドを発行するか、-cluster / -Mオプションを使用して、特定のクラスターに送信する必要があります。
Glossary
-
Federated Job: A job that is submitted to the federated
cluster.
フェデレーションジョブ:フェデレーションクラスターに送信されるジョブ。
It has a unique job ID across all clusters (Origin Cluster ID + Local Job ID).
すべてのクラスターで一意のジョブID(オリジンクラスターID +ローカルジョブID)があります。
-
Sibling Job: A copy of the federated job that is
submitted to other federated clusters.
兄弟ジョブ:他のフェデレーションクラスターに送信されるフェデレーションジョブのコピー。
-
Local Cluster: The cluster found in the slurm.conf that
the commands will talk to by default.
ローカルクラスター:コマンドがデフォルトで通信するslurm.confにあるクラスター。
-
Origin Cluster: The cluster that the federated job was
originally submitted to.
オリジンクラスター:フェデレーションジョブが最初にサブミットされたクラスター。
The origin cluster submits sibling jobs to other clusters in the federation.
オリジンクラスターは、フェデレーション内の他のクラスターに兄弟ジョブを送信します。
The origin cluster determines whether a sibling job can run or not.
オリジンクラスターは、兄弟ジョブを実行できるかどうかを決定します。
Communications for the federated job are routed through the origin cluster.
フェデレーションジョブの通信は、オリジンクラスターを介してルーティングされます。
-
Sibling Cluster: The cluster that is associated with a
sibling job.
兄弟クラスター:兄弟ジョブに関連付けられているクラスター。
-
Origin Job: The federated job that resides on the cluster
that it was originally submitted to.
オリジンジョブ:最初にサブミットされたクラスターに存在するフェデレーションジョブ。
-
Revoked (RV) State: The state that the origin job is in
while the origin job is not actively being scheduled on the
origin cluster (e.g. not a viable sibling or one of the sibling
jobs is running on a remote cluster).
失効(RV)状態:オリジンジョブがオリジンクラスターでアクティブにスケジュールされていないときにオリジンジョブが存在する状態(たとえば、実行可能な兄弟ではない、または兄弟ジョブの1つがリモートクラスターで実行されている)。
Or the state that a remote sibling job is put in when another sibling is allocated nodes.
または、別の兄弟にノードが割り当てられたときに、リモート兄弟ジョブが配置された状態。
-
Viable Sibling: a cluster that is eligible to run a
sibling job based off of the requested clusters, cluster
features and state of the cluster (e.g. active, draining, etc.).
実行可能な兄弟:要求されたクラスター、クラスターの機能、およびクラスターの状態(アクティブ、ドレインなど)に基づいて兄弟ジョブを実行する資格のあるクラスター。
-
Active Sibling: a sibling job that that actively has a
sibling job and is able to schedule the job.
アクティブな兄弟:兄弟ジョブがアクティブにあり、ジョブをスケジュールできる兄弟ジョブ。
Limitations
- A federated job that fails due to resources (partition, node counts,
etc.) on the local cluster will be rejected and won't be
submitted to other sibling clusters even if it could run on
them.
ローカルクラスター上のリソース(パーティション、ノード数など)が原因で失敗したフェデレーションジョブは拒否され、他の兄弟クラスターで実行できたとしても送信されません。 - Job arrays only run on the cluster that they were submitted to.
ジョブ配列は、送信されたクラスターでのみ実行されます。 - Job modification must succeed on the origin cluster for the changes
to be pushed to the sibling jobs on remote clusters.
変更をリモートクラスターの兄弟ジョブにプッシュするには、元のクラスターでジョブの変更が成功する必要があります。 - Modifications to anything other than jobs are disabled in sview.
ジョブ以外の変更はsviewで無効になります。 - sview grid is disabled in a federated view.
フェデレーションビューでは、sviewグリッドが無効になっています。
Last modified 23 Jan 2020