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. Jobs submitted to a federation receive a unique job ID that is unique among all clusters in the federation. 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. 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.
Slurmバージョン17.11には、クラスターのフェデレーションを作成し、クラスター間のピアツーピア方式でジョブをスケジュールするためのサポートが含まれています。連携に送信されたジョブは、連携内のすべてのクラスター間で一意の一意のジョブIDを受け取ります。ジョブはローカルクラスター（slurm.confで定義されているクラスター）に送信され、フェデレーション内のクラスター間で複製されます。次に、各クラスターは、独自のスケジューリングポリシーに基づいて、ジョブを個別にスケジュールしようとします。クラスターは、「元の」クラスター（ジョブが送信されたクラスター）と連携して、ジョブをスケジュールします。

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. 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.
注記：最初にドレインされずにクラスターがフェデレーションから削除された場合、削除されたクラスターで実行中のジョブ、または削除されたクラスターから発生したジョブは、非フェデレーションジョブとして実行され続けます。起点クラスターでジョブが保留中の場合、ジョブは非フェデレーテッドジョブとして起点クラスターで保留のままになり、残りの兄弟ジョブは削除されます。起点クラスターが削除されており、ジョブが保留中であり、1つのクラスターでのみ実行可能である場合、ジョブは非フェデレーテッドジョブとして実行可能なクラスターで保留のままになります。元のクラスターが削除され、ジョブが保留中であり、元のクラスター以外の複数のクラスターで実行可能な場合、残りの保留中のジョブはフェデレーションジョブとして保留されたままになり、残りの兄弟クラスター間でジョブを開始するようにスケジュールされます。


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 = [！]を使用してリクエストできます オプション：

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
  INACTIVE：クラスターはジョブをスケジュールまたは受け入れません
  
• 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. When removed from the federation, the cluster will accept jobs as a non-federated cluster
  DRAIN + REMOVE：クラスタは新しいジョブを受け入れず、すべてのフェデレーションジョブが完了すると、それ自体をフェデレーションから削除します。連携から削除されると、クラスターは非連携クラスターとしてジョブを受け入れます
  

Federation configuration can be viewed used using:
フェデレーション構成は、次を使用して表示できます。

sacctmgr show federation [tree]
sacctmgr show cluster withfed

After clusters are added to a federation and the controllers are started their status can be viewed from the controller using:
クラスターがフェデレーションに追加され、コントローラーが起動した後、次のコマンドを使用してコントローラーからそれらのステータスを表示できます。

scontrol show federation

By 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. Job ids in the federation are unique across all clusters in the federation. 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が取得されます。連携内のジョブIDは、連携内のすべてのクラスターで一意です。連合ジョブIDは、符号なし32ビット整数を使用してクラスターのIDとクラスターのローカルIDを割り当てることによって作成されます。

Bits 0-25:  Local Job ID
Bits 26-31: Cluster Origin ID

Federated 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-constraint = [！] オプション。

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. The clusters in the list will be the only viable clusters that siblings jobs can be submitted to. For example the submission:
-M、-clusters =の使用送信コマンド（sbatch、salloc、srun）は、クラスターのリストから1つのクラスターを選択してジョブを送信し、ジョブと共にクラスターのリストを渡します。リスト内のクラスターは、兄弟ジョブを送信できる唯一の実行可能なクラスターになります。たとえば、提出：

cluster1$ sbatch -Mcluster2,cluster3 script.sh

will 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 features are added using the sacctmgr modify cluster <cluster_name> set features[+-]=<feature_list> option.
--cluster-constraint = [！]を使用するオプションは、要求されたクラスター機能を持つクラスターのみに兄弟ジョブを送信します。または、！を使用している場合、機能はありません。クラスター機能はsacctmgr変更クラスターを使用して追加されます セット機能[+-] = オプション。

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.

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. 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.
対話型ジョブ（srunおよびsallocを使用して送信されたジョブ）をローカルクラスターに送信して、別のクラスターから割り当てを取得できます。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. 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. 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.
注：SlurmでのMPIインターフェースの現在の実装では、slurmdSpooldirが、srunが実行されているホストと、割り当ての計算ノードで同じである必要があります。そうでない場合の回避策は、ユーザーを実際の計算ノードに配置する割り当てを取得することです。次に、計算ノードのsrunは、正しいクラスターに対応するslurm.confを使用します。たとえば、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 =を使用すると、特定の保留中の兄弟ジョブを削除できます ジョブのアクティブな兄弟リストから兄弟ジョブを削除するオプション。

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. A unified view of the jobs in the federation can be viewed using the --federation option to each status command. The --federation command causes the status command to first check if the local cluster is part of a federation. If it is then the command will query each cluster in parallel for job info and will combine the information into one unified view.
デフォルトでは、squeue、sinfo、sprio、sacct、sreportなどのステータスコマンドは、ローカルクラスタのローカルビューを表示します。フェデレーション内のジョブの統合ビューは、各ステータスコマンドの--federationオプションを使用して表示できます。--federationコマンドを使用すると、ステータスコマンドはまずローカルクラスターがフェデレーションの一部であるかどうかを確認します。そうである場合、コマンドは各クラスターにジョブ情報を並行して照会し、情報を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. The federated view can be overridden using the --local option. Using the --clusters,-M option will also override the federated view and give a local view for the given cluster(s).
新しいFederationParameters = fed_display slurm.confパラメータが追加され、すべてのステータスコマンドがデフォルトで統合ビューを表示するようになりました。各ステータスコマンドの--federationオプションを設定するのと同じです。統合ビューは、-localオプションを使用してオーバーライドできます。--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オプションを使用すると、ステータスコマンドは、各クラスターの情報が個別にリストされている現在の形式と同じ形式で情報を出力します。

squeue

squeue also has a new --sibling option that will show each sibling job rather than than merge them into one.
また、squeueには新しい--siblingオプションがあり、それらを1つにマージするのではなく、各兄弟ジョブを表示します。

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. 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. The output can be sorted by cluster names using the -S %[+-]V option.
sinfoは、各クラスターのパーティションを1つのビューで表示します。統合ビューでは、クラスター名が各パーティションとともに表示されます。クラスター名は、短い形式の％Vまたは長い形式のクラスターオプションを使用して、形式オプションで指定できます。-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. 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. The name of the cluster reporting the job record can be displayed using the %c format option. The cluster name is shown by default when using --sibling option.
統合ビューでは、sprioはローカルクラスターまたは最初のクラスターからのジョブ情報を表示して、ジョブを報告します。各兄弟ジョブは各クラスターで異なる優先度を持つ可能性があるため、ジョブのすべてのレコードを表示してジョブの優先度をより詳しく把握するには、-siblingオプションを使用すると役立つ場合があります。ジョブレコードを報告するクラスターの名前は、％c形式オプションを使用して表示できます。--siblingオプションを使用すると、クラスター名がデフォルトで表示されます。

sacct

By default, sacct will not display "revoked" jobs and will show the job from the cluster that ran the job. However, "revoked" jobs can be viewed using the --duplicate/-D option.
デフォルトでは、sacctは「取り消された」ジョブを表示せず、ジョブを実行したクラスターからのジョブを表示します。ただし、「取り消された」ジョブは--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.
以下のscontrolオプションは、連携で処理されます。フェデレーテッドクラスター以外のクラスターからコマンドを実行すると、元のクラスターにルーティングされます。

• 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). Or the state that a remote sibling job is put in when another sibling is allocated nodes.
  取り消された（RV）状態：元のジョブが元のクラスターでアクティブにスケジュールされていない（たとえば、実行可能な兄弟ではない、または兄弟ジョブの1つがリモートクラスターで実行されている）間の元のジョブの状態。または、別の兄弟にノードが割り当てられたときにリモート兄弟ジョブが配置される状態。
  
• 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