CycleCloud GridEngine クラスター

Open Grid Scheduler (Grid Engine) は、クラスター定義の "run_list" を変更することで、Azure CycleCloud クラスターで簡単に有効にすることができます。 グリッド エンジン クラスターの 2 つの基本的なコンポーネントは、グリッド エンジン ソフトウェアを実行する共有ファイルシステムを提供する "マスター" ノードと、共有ファイルシステムをマウントして送信されたジョブを実行するホストである "実行" ノードです。 たとえば、単純なグリッド エンジン クラスター テンプレート スニペットは次のようになります。

[cluster grid-engine]

[[node master]]
    ImageName = cycle.image.centos7
    MachineType = Standard_A4 # 8 cores

    [[[configuration]]]
    run_list = role[sge_master_role]

[[nodearray execute]]
    ImageName = cycle.image.centos7
    MachineType = Standard_A1  # 1 core

    [[[configuration]]]
    run_list = role[sge_execute_role]

CycleCloud で定義を使用してクラスターをインポートして開始すると、単一の "マスター" ノードが生成されます。 実行ノードは、 コマンドを使用してクラスターに cyclecloud add_node 追加できます。 たとえば、さらに 10 個の実行ノードを追加するには、次のようにします。

cyclecloud add_node grid-engine -t execute -c 10

グリッド エンジンの自動スケーリング

Azure CycleCloud では、Grid Engine の自動スケーリングがサポートされています。つまり、ソフトウェアはキューの状態を監視し、必要に応じてノードをオンまたはオフにして、最適な時間/コストで作業を完了します。 クラスター定義に を追加 Autoscale = true することで、グリッド エンジンの自動スケーリングを有効にすることができます。

[cluster grid-engine]
Autoscale = True

既定では、グリッド エンジン キューに送信されたすべてのジョブは型 'execute' のマシンで実行されます。これらは、'execute' という名前のノード配列によって定義されたマシンです。 "execute" という名前に限定されるものではなく、ジョブを実行して自動スケーリングする 1 種類のコンピューター構成に限定されるわけではありません。

たとえば、一般的なケースとして、2 つの異なるノード定義を持つクラスターがあり、1 つは標準 CPU を消費する "通常" ジョブを実行する場合と、別の種類のジョブで GPU マシンを使用する場合です。 この場合は、通常のジョブと GPU ジョブの両方によってキューを個別にスケーリングして、作業キューを使用する各マシンの適切な量があることを確認する必要があります。 定義の例を次に示します。

[cluster grid-engine]
Autoscale = True

[[node master]]
    ImageName = cycle.image.centos7
    MachineType = Standard_A3  # 4 cores

    [[[configuration]]]
    run_list = role[sge_master_role]

[[nodearray execute]]
    ImageName = cycle.image.centos7
    MachineType = Standard_A4  # 8 cores

    [[[configuration]]]
    run_list = role[sge_execute_role]

[[nodearray gpu]]
    MachineType = Standard_NV12 # 2 GPUs
    ImageName = cycle.image.centos7

    # Set the number of cores to the number of GPUs for autoscaling purposes
    CoreCount = 2  

    [[[configuration]]]
    run_list = role[sge_execute_role]
    gridengine.slot_type = gpu
    gridengine.slots = 2

上記の例では、2 つのノード配列が存在するようになりました。1 つは "standard" 実行ノード配列、2 つ目は "gpu" という名前で、2 つ目は 2 つの Nvidia GPU (Azure でStandard_NV12) を持つ MachineType を提供します。 また、構成セクションには、'csge:sgeexec' レシピ以外に 2 つの新しい項目があることにも注意してください。 を追加 gridengine.slot_type = gpu すると、グリッド エンジン スケジューラは、これらのノードの名前を "gpu" ノードにする必要があるため、"gpu" ジョブのみを実行する必要があることを示します。 名前 'gpu' は任意ですが、ノードを記述する名前が最も便利です。 を設定 gridengine.slots = 2します。これは、この種類のノードが一度に 2 つのジョブのみを実行できることをソフトウェアに指示します (Standard_NV12 GPU は 2 つだけです)。 既定では、グリッド エンジンのノードあたりのスロット数はシステム上の CPU の数になります。この場合、ノードで同時に実行するジョブが多すぎます。 上記の例では、 CoreCount=2 が MachineType で使用可能な GPU の数と一致するように nodearray に設定されているため、CycleCloud は GPU と CPU 数でその配列を正しくスケーリングできます。

次のコマンドを実行して、マシンのスロット数とslot_typeを確認できます。

    -bash-4.1# qstat -F slot_type
    queuename                      qtype resv/used/tot. load_avg arch          states
    ---------------------------------------------------------------------------------
    all.q@ip-0A000404              BIP   0/0/4          0.17     linux-x64
        hf:slot_type=execute
    ---------------------------------------------------------------------------------
    all.q@ip-0A000405              BIP   0/0/2          2.18     linux-x64
        hf:slot_type=gpu
    ---------------------------------------------------------------------------------
    all.q@ip-0A000406              BIP   0/0/4          0.25     linux-x64

指定した各 'slot_type' の 1 つ (execute と gpu) があり、"execute" スロットのスロット数は 4 (マシン上の CPU の数) であることに注意してください。 "gpu" スロットの種類のスロット数は 2 で、クラスター構成テンプレートで指定しました。 3 番目のマシンは、ジョブを実行しないマスター ノードです。

グリッド エンジンの高度な使用法

上記の構成設定では、ノードとノード配列を高度にカスタマイズできます。 たとえば、ジョブに特定の量 (それぞれ 10 GB) のメモリが必要な場合は、60 GB のメモリを持つマシンを起動する実行ノードアレイを定義し、構成オプション gridengine.slots = 6 を追加して、この種類のノードで同時に実行できるジョブが 6 個だけになるようにします (各ジョブで動作するメモリが少なくとも 10 GB になるようにします)。

グリッド エンジンのグループ化されたノード

並列ジョブがグリッド エンジンに送信されると、CycleCloud で使用される既定の自動スケーリング動作は、各 MPI ジョブをグループ化されたノード要求として扱うことです。 グループ化されたノードは密結合されており、MPI ワークフローに最適です。

グループ化されたノードのセットがグリッド エンジン クラスターに参加すると、各ノードのグループ ID が複合値 の値 affinity_groupとして使用されます。 ジョブに を指定する必要 affinity_group があるため、グリッド エンジン スケジューラは、ジョブが同じグループ内のマシンにのみ配置されるようにすることができます。

CycleCloud の自動化では、並列ジョブが発生したときに、グループ化されたノードが自動的に要求され、使用可能なアフィニティ グループに割り当てられます。

グリッド エンジンへのジョブの送信

グリッド エンジン スケジューラにジョブを送信する最も一般的な方法は、次のコマンドです。

qsub my_job.sh

このコマンドは、nodearray 'execute' によって定義されたノードである型 'execute' のノードで実行されるジョブを送信します。 上記の "gpu" ノードの種類など、別の種類の nodearray でジョブを実行するには、送信を変更します。

qsub -l slot_type=gpu my_gpu_job.sh

このコマンドを実行すると、ジョブは 'gpu' の 'slot_type' でのみ実行されます。

slot_typeを省略すると、'execute' がジョブに自動的に割り当てられます。 ジョブにslot_typeを自動的に割り当てるメカニズムは、ユーザーが変更できます。 /opt/cycle/jetpack/config/autoscale.py にある Python スクリプトを作成できます。これは、単一の関数 "sge_job_handler" を定義する必要があります。 この関数は、コマンドの出力と同様にジョブの qstat -j JOB_ID ディクショナリ表現を受け取り、ジョブの更新が必要なハード リソースのディクショナリを返す必要があります。 例として、ジョブ名に "gpu" という文字が含まれている場合に、ジョブを "gpu" slot_typeに割り当てるスクリプトを次に示します。 これにより、ユーザーは、ジョブ パラメーターを変更せずに自動化されたシステムからジョブを送信し、ジョブを引き続き正しいノードで実行して自動スケーリングできます。

#!/usr/env python
#
# File: /opt/cycle/jetpack/config/autoscale.py
#
def sge_job_handler(job):
  # The 'job' parameter is a dictionary containing the data present in a 'qstat -j JOB_ID':
    hard_resources = {'slot_type': 'execute', 'affinity_group' : 'default' }

  # Don't modify anything if the job already has a slot type
  # You could modify the slot type at runtime by not checking this
  if 'hard_resources' in job and 'slot_type' in job['hard_resources']:
      return hard_resources

  # If the job's script name contains the string 'gpu' then it's assumed to be a GPU job.
  # Return a dictionary containing the new job_slot requirement to be updated.
  # For example: 'big_data_gpu.sh' would be run on a 'gpu' node.
  if job['job_name'].find('gpu') != -1:
      hard_resources {'slot_type': 'gpu'}
  else:
      return hard_resources

渡されるパラメーター 'job' は、呼び出しの qstat -j JOB_ID データを含むディクショナリです。

{
    "job_number": 5,
    "job_name": "test.sh",
    "script_file": "test.sh",
    "account": "sge",
    "owner": "cluster.user",
    "uid": 100,
    "group": "cluster.user",
    "gid": 200,
    "submission_time": "2013-10-09T09:09:09",
    "job_args": ['arg1', 'arg2', 'arg3'],
    "hard_resources": {
       'mem_free': '15G',
       'slot_type': 'execute'
    }
}

このスクリプト機能を使用すると、引数、メモリ、送信ユーザーなどの他のリソース要件など、ジョブで定義されているパラメーターに基づいて、slot_typeの を自動的に割り当てることができます。

各 'slot_type' の 5 つのジョブを送信する場合:

qsub -t 1:5 gpu_job.sh
qsub -t 1:5 normal_job.sh

キューには 10 個のジョブが存在します。 上記のスクリプトが定義されているため、名前に "gpu" を持つ 5 つのジョブは、'slot_type=gpu' のノードでのみ実行されるように自動的に構成されます。 CycleCloud 自動スケーリング メカニズムでは、5 個の "gpu" ジョブと 5 個の "実行" ジョブがあることを検出します。 "gpu" nodearray はノードあたり 2 つのスロットを持つものとして定義されているため、CycleCloud はこれらのノードのうち 3 つを開始します (5/2=2.5 は 3 に切り上げられます)。 "execute" nodearray のマシンの種類にはそれぞれ 4 つの CPU があるため、5 つの通常のジョブがあります。CycleCloud はジョブを処理するためにこれらのノードの 2 つを開始します (5/4=1.25 は 2 に切り上げられます)。 新しく開始されたノードが起動して構成されるまでの短い時間が経過すると、10 個のジョブがすべて完了するまで実行され、クラウド プロバイダーから再び課金される前に 5 つのノードが自動的にシャットダウンされます。

ジョブの期間は 1 時間と見なされます。 ジョブ ランタイムが既知の場合、自動スケーリング アルゴリズムはこの情報の恩恵を受けることができます。 ジョブ コンテキストに追加して、予想されるジョブの実行時間を自動スケーリングに通知します。 次の例では、ジョブ ランタイムが平均 10 分であることを自動スケーリングに指示します。

qsub -ac average_runtime=10 job_with_duration_of_10m.sh

グリッド エンジン構成リファレンス

次に、機能をカスタマイズするために切り替えることができるグリッド エンジン固有の構成オプションを示します。

CycleCloud では、スケジューラ間で自動停止属性の標準セットがサポートされています。

の既知の問題

• qsh 対話型セッションのコマンドが機能しません。 代替手段として を使用 qrsh します。
• exclusive=1この複雑さは自動スケーリングでは考慮されません。 結果として起動するノードが予想よりも少なくなる可能性があります。

このページでは、CycleCloud で (Altair) GridEngine を使用する機能と構成について説明します。

リソースの構成

cyclecloud-gridengine アプリケーションは、リソースを azure クラウド リソースと照合して、豊富な自動スケーリングとクラスター構成ツールを提供します。 アプリケーションは、CycleCloud UI を介して作成されたクラスターに対して自動的にデプロイされるか、既存のクラスター上の任意の gridengine 管理ホストにインストールできます。

cyclecloud-gridengine のインストールまたはアップグレード

cyclecloud-gridengine バンドルは、リリース成果物として github で入手できます。 インストールとアップグレードは同じプロセスになります。 アプリケーションには、virtualenv を含む python3 が必要です。

tar xzf cyclecloud-gridengine-pkg-*.tar.gz
cd cyclecloud-gridengine
./install.sh

重要なファイル

アプリケーションは、呼び出されるたびに sge 構成 (ジョブ、キュー、複合) を解析します。 情報は、コマンドの stderr と stdout、およびログ ファイルで提供されます。どちらも構成可能なレベルで提供されます。 引数を含むすべての gridengine 管理コマンドもファイルに記録されます。

SGE キュー、ホスト グループ、および並列環境

cyclecloud-gridengine 自動スケーリング ユーティリティ は、 azgeクラスター構成に従ってクラスターにホストを追加します。 自動スケーリング操作では、次のアクションが実行されます。

1. ジョブ リソース要求を読み取り、開始する適切な VM を見つける
2. VM を起動し、準備が整うのを待ちます
3. ジョブからキューと並列環境を読み取る
4. キュー/pe に基づいて、適切なホスト グループにホストを割り当てます
5. ホストをクラスターに追加し、ホスト グループを含む他のキューに追加します

short.q という名前のキューに対して、次のキュー定義を検討してください。

hostlist              @allhosts @mpihg01 @mpihg02 @lowprio 
...
seq_no                10000,[@lowprio=10],[@mpihg01=100],[@mpihg02=200]
pe_list               NONE,[@mpihg01=mpi01], \
                      [@mpihg02=mpi02]

によってジョブ qsub -q short.q -pe mpi02 12 my-script.sh を送信すると、1 つの VM のリース時に開始され、クラスターに追加されると、ホスト グループ @mpihg02 に参加します。これは、キューと並列環境の両方で使用できるホスト グループであるためです。 また、特別なホスト グループである @allhosts にも追加されます。

pe を指定しないと、 qsub -q short.q my-script.sh 結果の VM が @allhosts に追加され、キュー内のホスト グループが pes に割り当てられない @lowpriority されます。

最後に、 で qsub -q short.q -pe mpi0* 12 my-script.sh 送信されたジョブでは、CycleCloud 割り当ての予測に応じて、 @mpihg01 または @mpihg02 に VM が追加されます。

並列環境は、暗黙的に cyclecloud 配置グループに相当します。 PE 内の VM は、同じネットワーク内に存在するように制限されます。 配置グループを保持しない PE を使用する場合は、 autoscale.json を使用してオプトアウトします。

ここでは、 make pe の配置グループをオプトアウトします。

"gridengine": {
    "pes": {
      "make": {
        "requires_placement_groups": false
      }
    },

CycleCloud 配置グループ

CycleCloud 配置グループは、SinglePlacementGroup を使用して Azure VMSS に 1 対 1 でマップします。配置グループ内の VM は Infiniband Fabric を共有し、配置グループ内の VM とのみ共有します。 これらのサイロを直感的に保持するために、配置グループは 1 対 1 と gridengine 並列環境をマップします。

ジョブの並列環境を指定すると、スマート ホスト グループ割り当てロジックを使用して配置グループで実行するジョブが制限されます。 autoscale.json : "required_placement_groups" : falseの前述の構成を使用して、この動作をオプトアウトできます。

自動スケーリング構成

このプラグインは、ワークロードの要求に合わせてグリッドを自動的にスケーリングします。 autoscale.json 構成ファイルは、グリッド エンジン オートスケーラーの動作を決定します。

• cyclecloud 接続の詳細を設定する
• アイドル 状態のノードの終了タイマーを設定する
• スロット、メモリなど、ジョブ パッキングで使用する属性を設定して、多次元自動スケーリングを実行できます。
• 管理するキュー、並列環境、ホスト グループを登録する

自動スケーリング プログラムでは、関連リソースのみが考慮されます

その他の自動スケーリング リソース

既定では、ジョブによって要求されるスロットの数に基づくスケールを持つクラスター。 自動スケーリングに別のディメンションを追加できます。

たとえば、 のジョブ リソース要求 m_mem_freeによって自動スケーリングを行うとします。

1. autoscale.json 内の gridengine.relevant_resources にを追加m_mem_freeする
2. autoscale.json のノード レベルのメモリ リソースへのリンクm_mem_free

これらの属性は、_default/リソースの値として を使用した参照node.*にすることができます。

名前空間には node.resources.* 、'node.resources など、追加の属性があります。

リソース マッピング

また、default_resourcesで使用できる数学もあります。特定のノード配列のスロットを 2 つ減らし、docker リソースをすべてのノードに追加します。

    "default_resources": [
    {
      "select": {"node.nodearray": "beegfs"},
      "name": "slots",
      "value": "node.vcpu_count",
      "subtract": 2
    },
    {
      "select": {},
      "name": "docker",
      "value": true
    },

ノード vCPU をスロット複合にマッピングし memmb 、 を に mem_free マッピングすると、一般的に既定で使用されます。 最初の関連付けが必要です。

    "default_resources": [
    {
      "select": {},
      "name": "slots",
      "value": "node.vcpu_count"
    },
    {
      "select": {},
      "name": "mem_free",
      "value": "node.resources.memmb"
    }
 ],

複合に値全体と等しくないショートカットがある場合は、 default_resourcesで両方 を定義します。ここで physical_cpu 、 は複合名です。

"default_resources": [
    {
      "select": {},
      "name": "physical_cpu",
      "value": "node.pcpu_count"
    },
    {
      "select": {},
      "name": "pcpu",
      "value": "node.resources.physical_cpu"
    }
]

順序付けは、特定の属性に対して特定の動作が必要な場合に重要です。 他のすべての nodearray の既定のスロット数を保持しながら、特定の nodearray に 1 つのスロットを割り当てるには:

    "default_resources": [
    {
      "select": {"node.nodearray": "FPGA"},
      "name": "slots",
      "value": "1",
    },
    {
      "select": {},
      "name": "slots",
      "value": "node.vcpu_count"
    },
]

ホスト グループ

CycleCloud 自動スケーラーは、ジョブ要件を満たすために、ノードを適切なホスト グループにマップします。 キュー、並列環境、および複合はすべて考慮されます。 ロジックの多くは、適切な cyclecloud バケット (およびノード数量) と適切な sge ホスト グループを照合しています。

次のように送信されたジョブの場合: qsub -q "cloud.q" -l "m_mem_free=4g" -pe "mpi*" 48 ./myjob.sh

CycleCloud は、次のホスト グループの共通部分を取得します。

1. cloud.q のpe_listに含まれ、pe 名 (例: ) と一致します。 pe_list [@allhosts=mpislots],[@hpc1=mpi]
2. すべてのジョブ リソースを提供するための十分なリソースとサブスクリプション クォータを用意します。
3. ホスト グループ制約の構成ではフィルター処理されません。

複数のホスト グループがこれらの要件を満たしている可能性があります。その場合、ロジックを選択する必要があります。 ホスト グループ メンバーシップのあいまいさを解決するには、次の 3 つの方法があります。

1. あいまいさがないようにキューを構成します。
2. autoscale.json に制約を追加します。
3. スケジューラ構成で を調整して、CycleCloud で一致するホスト グループを weight_queue_host_sort < weight_queue_seqno 名前順に選択できるようにします。
4. ホスト グループの基本設定を示すように、キュー構成で を設定 seq_no 10000,[@hostgroup1=100],[@hostgroup2=200] します。

Hostgroup 制約

キューまたは xproject によって複数のホスト グループが定義されている場合、これらのすべてのホスト グループにホストが追加される可能性があります。 hostgroup 制約を設定することで、どの種類のホストをどのキューに追加できるかを制限できます。 ノードのプロパティに基づいて制約を設定します。

"gridengine": {
    "hostgroups": {
      "@mpi": {
        "constraints": {
          "node.vm_size": "Standard_H44rs"
        }
      },
      "@amd-mem": {
        "constraints" : { 
            "node.vm_size": "Standard_D2_v3",
            "node.nodearray": "hpc" 
            }
        },
    }
  }

ヒント: で使用可能なすべてのノード プロパティを azge buckets調べます。

azge

このパッケージには、コマンドライン azge が付属しています。 このプログラムは、自動スケーリングを実行するために使用する必要があり、自動スケーリング下のすべてのサブプロセスを分割しています。 これらのコマンドは、設定する gridengine 環境変数に依存します。が呼び出されたのと同じプロファイルazgeから と qsub を呼び出qconfすことができる必要があります。

スケジューラ構成 (qconf) または自動スケーリング構成 (autoscale.json) を変更する場合、または初めて設定する場合でも、 azge を 使用して自動スケーリングの動作が期待値と一致することを確認できます。 ルートとして、次の操作を実行できます。 自動スケーリングの動作を理解するには、これらを理解することをお勧めします。

1. を実行 azge validate して、既知の問題の構成を確認します。
2. を実行 azge buckets して、CycleCloud クラスターが提供しているリソースを調べます。
3. を実行 azge jobs して、キューに登録されたジョブの詳細を調べます。
4. を実行 azge demand して、バケットマッチングにジョブを実行し、どのジョブがどのバケットとホストグループに一致するかを調べます。
5. を実行 azge autoscale してノード割り当てプロセスを開始するか、参加する準備ができているノードを追加します。

次に、これらのコマンドが期待どおりに動作している場合は、ルート crontab に コマンドを azge autoscale 追加して、継続的な自動スケーリングを有効にします。 (グリッドエンジン環境変数のリソース)

* * * * * . $SGE_ROOT/common/settings.sh && /usr/local/bin/azge autoscale -c /opt/cycle/gridengine/autoscale.json

ハイブリッド クラスターの作成

CycleCloud では、クラウドへのバーストのシナリオがサポートされます。 基本構成では、ディレクトリが $SGE_ROOT クラウド ノードで使用できるものとします。 この想定は、 を設定gridengine.shared.spool = falsegridengine.shared.bin = falseし、GridEngine をローカルにインストールすることで緩和できます。 簡単なケースでは、ディレクトリを含む $SGE_ROOT 実行ノードによってマウントできるファイルシステムを提供し、オプションの設定でそのマウントを構成する必要があります。 sched ディレクトリと共有ディレクトリの依存関係が解放されたら、クラスターの一部であるスケジューラ ノードを既定でシャットダウンし、外部ファイルシステムの構成を使用できます。

1. 新しい gridengine クラスターを作成します。
2. リターン プロキシを無効にします。
3. /sched と /shared を外部ファイルシステムに置き換えます。
4. クラスターを保存します。
5. UI のアクションとしてスケジューラ ノードを削除します。
6. クラスターを起動します。ノードは最初に開始されません。
7. 新しいクラスターを使用するように autoscale.json を使用して構成cyclecloud-gridengineする

CycleCloud での Univa グリッド エンジンの使用

GridEngine 用 CycleCloud プロジェクトでは、既定で sge-2011.11 が 使用されます。 Altair ライセンス契約に従って、独自の Altair GridEngine インストーラーを使用できます。
このセクションでは、CycleCloud GridEngine プロジェクトで Altair GridEngine を使用する方法について説明します。

前提条件

この例では 8.6.1-demo バージョンを使用しますが、すべての ge バージョン > 8.4.0 がサポートされています。

1. ユーザーは UGE バイナリを提供する必要があります

• ge-8.6.x-bin-lx-amd64.tar.gz
• ge-8.6.x-common.tar.gz

2. CycleCloud CLI を構成する必要があります。 ドキュメントについては、こちらを参照してください。

バイナリをクラウド ロッカーにコピーする

Age の補完的なバージョン (8.6.7-demo) は CycleCloud と共に配布されます。 別のバージョンを使用するには、CycleCloud が使用するストレージ アカウントにバイナリをアップロードします。

$ azcopy cp ge-8.6.12-bin-lx-amd64.tar.gz https://<storage-account-name>.blob.core.windows.net/cyclecloud/gridengine/blobs/
$ azcopy cp ge-8.6.12-common.tar.gz https://<storage-account-name>.blob.core.windows.net/cyclecloud/gridengine/blobs/

クラスター テンプレートへの構成の変更

gridengine テンプレートのローカル コピーを作成し、既定値ではなく UGE インストーラーを使用するように変更します。

wget https://raw.githubusercontent.com/Azure/cyclecloud-gridengine/master/templates/gridengine.txt

gridengine.txt ファイルで、 の最初の出現箇所を見つけて、次の[[[configuration]]]スニペットと一致するテキストを挿入します。 このファイルはインデントの影響を受けません。

注: 構成の詳細 (特にバージョン) は、インストーラー ファイル名と一致している必要があります。

[[[configuration gridengine]]]
    make = ge
    version = 8.6.12-demo
    root = /sched/ge/ge-8.6.12-demo
    cell = "default"
    sge_qmaster_port = "537"
    sge_execd_port = "538"
    sge_cluster_name = "grid1"
    gid_range = "20000-20100"
    qmaster_spool_dir = "/sched/ge/ge-8.6.12-demo/default/spool/qmaster" 
    execd_spool_dir = "/sched/ge/ge-8.6.12-demo/default/spool"
    spooling_method = "berkeleydb"
    shadow_host = ""
    admin_mail = ""
    idle_timeout = 300

    managed_fs = true
    shared.bin = true

    ignore_fqdn = true
    group.name = "sgeadmin"
    group.gid = 536
    user.name = "sgeadmin"
    user.uid = 536
    user.gid = 536
    user.description = "SGE admin user"
    user.home = "/shared/home/sgeadmin"
    user.shell = "/bin/bash"

これらの構成は、クラスターの起動時に既定の gridengine のバージョンとインストール場所をオーバーライドします。 クラスター内の /sched 特に共有された nfs の場所であるため、 から移動しても安全ではありません。