CycleCloud GridEngine Cluster

O Open Grid Scheduler (Grid Engine) pode ser facilmente habilitado em um cluster do Azure CycleCloud modificando o "run_list" na definição de cluster. Um cluster do Grid Engine consiste em dois componentes principais. O primeiro é o nó 'master', que fornece um sistema de ficheiros partilhado onde o software Grid Engine é executado. O segundo é o conjunto de nós 'execute', que são os hosts que montam o sistema de arquivos compartilhado e executam os trabalhos enviados. Por exemplo, um simples trecho de modelo de cluster do Grid Engine pode ter a seguinte aparência:

[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]

Importar e iniciar um cluster com uma definição no CycleCloud resulta em um único nó 'mestre'. Os nós 'execute' podem ser adicionados ao cluster através do cyclecloud add_node comando. Por exemplo, para adicionar mais 10 nós de execução:

cyclecloud add_node grid-engine -t execute -c 10

Dimensionamento automático do sistema de grelha

O Azure CycleCloud dá suporte ao dimensionamento automático para o Grid Engine. Esse comportamento significa que o software monitora continuamente o status da fila e ativa ou desliga automaticamente os nós conforme necessário para concluir a carga de trabalho de forma eficiente em termos de tempo e custo. Você pode habilitar o dimensionamento automático para o Grid Engine adicionando Autoscale = true à sua definição de cluster:

[cluster grid-engine]
Autoscale = True

Por padrão, todos os trabalhos enviados para a fila do Grid Engine são executados em máquinas do tipo 'execute'. Essas máquinas são definidas pela matriz de nós chamada 'execute'. Você não está limitado ao nome 'executar', nem a um único tipo de configuração de máquina para executar trabalhos e escalar automaticamente.

Por exemplo, um cenário comum envolve um cluster com duas definições de nó diferentes. Um é projetado para executar trabalhos "normais" que usam CPUs padrão. O outro destina-se a trabalhos que exigem máquinas habilitadas para GPU. Neste caso, deverá dimensionar a fila de forma independente para trabalhos normais e trabalhos de GPU, a fim de garantir que tem um número apropriado de cada máquina para processar a fila de trabalho. Um exemplo de definição seria algo como:

[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

No exemplo mostrado, existem agora duas matrizes de nós: uma é uma matriz de nós 'execute' 'padrão', e a segunda é chamada 'gpu', a qual fornece um tipo de máquina que tem duas GPUs NVIDIA (Standard_NV12 no Azure). Observe também que agora há dois novos itens na seção de configuração, além da receita 'csge:sgeexec'. Adicionar gridengine.slot_type = gpu informa ao agendador do Grid Engine que esses nós devem ser chamados de nós 'gpu' e, portanto, só devem executar trabalhos 'gpu'. O nome 'gpu' é arbitrário, mas um nome que descreva o nó pode ser mais útil. Set gridengine.slots = 2, que diz ao software para se certificar de que este tipo de nó só pode executar dois trabalhos ao mesmo tempo (Standard_NV12 só tem 2 GPUs).

Por predefinição, o Grid Engine determina o número de slots atribuídos por nó com base na contagem de CPUs do sistema. Nesse caso, esse comportamento padrão pode resultar em muitas tarefas a serem executadas simultaneamente num único nó. No exemplo mostrado, CoreCount=2 é definido no nodearray para corresponder ao número de GPUs disponíveis no MachineType, permitindo que o CycleCloud dimensione corretamente esse array na contagem de GPU vs CPU.

Você pode verificar o número de slots e slot_type suas máquinas têm executando o comando:

    -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

Repare que foi especificado um de cada 'slot_type': 'execute' e 'gpu'. Os slot_types são configurados individualmente e o número de slots para o slot 'execute' é 4, que é o número de CPUs na máquina. O número de slots para o tipo de slot 'gpu' é 2, que especificamos em nosso modelo de configuração de cluster. A terceira máquina é o nó mestre que não processa tarefas.

Uso avançado do Grid Engine

Essas definições de configuração permitem a personalização avançada de nós e matrizes de nós. Por exemplo, se os trabalhos exigirem uma quantidade específica de memória, digamos 10 GB cada, você pode definir um nodearray 'executar' que inicia máquinas com 60 GB de memória e, em seguida, adicionar as opções gridengine.slots = 6 de configuração para garantir que apenas 6 trabalhos possam ser executados simultaneamente nesse tipo de nó (garantindo que cada trabalho tenha pelo menos 10 GB de memória para trabalhar).

Nós agrupados no sistema de grelha

Quando um trabalho paralelo é enviado ao mecanismo de grade, o comportamento padrão de dimensionamento automático que o CycleCloud utiliza é tratar cada trabalho MPI como um pedido de nós agrupados. Os nós agrupados são fortemente acoplados e ideais para fluxos de trabalho MPI.

Quando um conjunto de nós agrupados entra num cluster do Grid Engine, o ID de grupo de cada nó é utilizado como valor do complexo affinity_group. Ao exigir que um affinity_group seja especificado para trabalhos, ele permite que o agendador do Grid Engine garanta que os trabalhos só aterrissem em máquinas que estão no mesmo grupo.

A automação do CycleCloud solicita automaticamente nós agrupados e os atribui a grupos de afinidade disponíveis quando trabalhos paralelos são encontrados.

Enviando trabalhos para o Grid Engine

A maneira mais genérica de enviar trabalhos para um agendador do Grid Engine é o comando:

qsub my_job.sh

Este comando envia um trabalho que é executado em um nó do tipo 'execute', que é um nó definido pelo nodearray 'execute'. Para fazer com que um trabalho seja executado em uma matriz de nós de um tipo diferente, por exemplo, o tipo de nó 'gpu' mostrado, modificamos nosso envio:

qsub -l slot_type=gpu my_gpu_job.sh

Este comando garante que o trabalho seja executado apenas em um 'slot_type' de 'gpu'.

Se o slot_type for omitido, 'executar' atribui-se automaticamente ao trabalho. O usuário pode modificar o mecanismo que atribui automaticamente slot_type a trabalhos. Um script python localizado em /opt/cycle/jetpack/config/autoscale.py pode ser criado que deve definir uma única função "sge_job_handler". Esta função recebe uma representação de dicionário da tarefa, semelhante à saída de um qstat -j JOB_ID comando e deve retornar um dicionário de recursos de hardware que precisam ser atualizados para a tarefa.

Como exemplo, o script a seguir atribui um trabalho ao slot_type 'gpu' se o nome do trabalho incluir as letras 'gpu'. Os utilizadores têm permissão para enviar automaticamente os seus trabalhos sem alterar os parâmetros da tarefa, enquanto asseguram que as tarefas sejam executadas e dimensionadas automaticamente nos nós corretos.

#!/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

O parâmetro 'job' passado é um dicionário que contém os dados em uma qstat -j JOB_ID chamada:

{
    "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'
    }
}

Você pode usar essa funcionalidade de script para atribuir slot_type automaticamente com base em qualquer parâmetro de trabalho definido, como argumentos, requisitos de recursos como memória ou o usuário que envia.

Suponha que você envie 5 trabalhos para cada 'slot_type':

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

Haveria agora 10 empregos na fila. Devido ao script definido, os cinco trabalhos com 'gpu' no nome seriam automaticamente configurados para serem executados apenas em nós de 'slot_type=gpu'. O mecanismo de dimensionamento automático do CycleCloud detetaria 5 trabalhos 'gpu' e 5 'de cálculo'. Como o nodearray 'gpu' é configurado para ter 2 slots por nodo, o CycleCloud iniciaria 3 desses nodos (5/2=2,5 arredondado para cima para 3).

Existem 5 trabalhos normais, uma vez que o tipo de máquina para o nodearray 'execute' tem 4 CPUs cada, o CycleCloud iniciaria 2 desses nós para lidar com os trabalhos (5/4=1,25 arredondado para cima para 2). Após um breve período de inicialização, os nós recém-lançados inicializam e se configuram. Uma vez prontos, todos os 10 trabalhos são executados até a conclusão. Os 5 nós são desligados automaticamente antes que outro ciclo de faturamento comece com o provedor de nuvem.

Presume-se que os trabalhos tenham uma duração de uma hora. Se o tempo de execução do trabalho for conhecido, o algoritmo de dimensionamento automático poderá se beneficiar dessas informações. Informe o autoscale do tempo de execução esperado do trabalho, adicionando-o ao contexto do trabalho. O exemplo a seguir define o tempo de execução do trabalho para dimensionamento automático para 10 minutos:

qsub -ac average_runtime=10 job_with_duration_of_10m.sh

Referência de configuração do motor de grade

A seguir estão as opções de configuração específicas do Grid Engine que você pode alternar para personalizar a funcionalidade:

O CycleCloud suporta um conjunto padrão de atributos de parada automática entre agendadores:

Problemas conhecidos

• qsh comando para sessão interativa não funciona. Use qrsh como alternativa.
• A escala automática não respeita o exclusive=1 complexo, o que pode fazer com que menos nós do que o esperado iniciem.

Esta página diz respeito aos recursos e configuração do uso do (Altair) GridEngine com o CycleCloud.

Configurando recursos

O aplicativo cyclecloud-gridengine combina recursos sge com recursos de nuvem do Azure para fornecer ferramentas avançadas de dimensionamento automático e configuração de cluster. O aplicativo é implantado automaticamente para clusters criados por meio da interface do usuário do CycleCloud ou pode ser instalado em qualquer host de administração do GridEngine em um cluster existente.

Instalação ou Atualização do cyclecloud-gridengine

O pacote cyclecloud-gridengine está disponível no GitHub como um artefato de lançamento. A instalação e a atualização seguem o mesmo processo. O aplicativo requer python3 com virtualenv.

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

Arquivos importantes

A aplicação analisa a configuração do SGE cada vez que é executada - trabalhos, filas, complexos. As informações são fornecidas no stderr e stdout do comando e em um arquivo de log, ambos em níveis configuráveis. Todos os comandos de gerenciamento do GridEngine com argumentos também são registrados no arquivo.

Filas SGE, grupos de hosts e ambientes paralelos

O utilitário cyclecloud-gridengine autoscale, azge, adiciona hosts ao cluster de acordo com a configuração do cluster. As operações de dimensionamento automático executam as seguintes ações.

1. Leia a solicitação de recurso de trabalho e encontre uma VM apropriada para iniciar
2. Inicie a VM e aguarde que ela esteja pronta
3. Leia a fila e o ambiente paralelo da tarefa
4. Com base na fila/pe, atribua o host a um grupo de hosts apropriado
5. Adicionar o host ao cluster e a qualquer outra fila que contenha o grupo de hosts

Considere a seguinte definição de fila para uma fila chamada short.q

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

Enviar um trabalho por qsub -q short.q -pe mpi02 12 my-script.sh inicia pelo menos uma VM. Quando o cluster é adicionado, ele se junta ao grupo de hosts @mpihg02 porque esse é o grupo de hosts disponível para a fila e para o ambiente paralelo. Também se junta a @allhosts, um grupo especial de anfitriões.

Se você enviar um trabalho com qsub -q short.q my-script.sh e não especificar um ambiente paralelo 'pe', a VM resultante ingressará nos grupos de hosts @allhosts e @lowpriority vinculados à fila à qual não é atribuído nenhum 'pe'.

Finalmente, um trabalho enviado com qsub -q short.q -pe mpi0* 12 my-script.sh resulta numa VM adicionada a @mpihg01 ou @mpihg02, dependendo das previsões de alocação do CycleCloud.

Ambientes paralelos equivalem implicitamente ao grupo de posicionamento cyclecloud. As VMs em um PE são restritas a estar dentro da mesma rede. Se você deseja usar uma PE que não mantém um grupo de posicionamento, use o autoscale.json para desativar.

Aqui optamos por não utilizar grupos de alocação para o make pe:

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

Grupos de posicionamento do CycleCloud

Os grupos de posicionamento do CycleCloud mapeiam um a um para o Azure VMSS com SinglePlacementGroup - VMs num grupo de posicionamento partilham uma rede Infiniband e apenas partilham com VMs dentro do grupo de posicionamento. Para preservar intuitivamente esses silos, os grupos de posicionamento correspondem diretamente ao ambiente paralelo do GridEngine.

A especificação de um ambiente paralelo para um trabalho restringe a execução do trabalho em um grupo de colocação por meio da lógica de atribuição de grupo host inteligente. Você pode desativar esse comportamento através da configuração correspondente em autoscale.json: "required_placement_groups" : false.

Configuração de dimensionamento automático

Este plugin dimensiona automaticamente a grade para atender às demandas da carga de trabalho. O arquivo de configuração autoscale.json determina o comportamento do autoscaler do Grid Engine.

• Definir os detalhes da conexão cyclecloud
• Definir o temporizador de terminação nos nós inativos
• O dimensionamento automático multidimensional é suportado. Você pode configurar quais atributos usar no empacotamento de tarefas, por exemplo, slots ou memória
• Registrar as filas, ambientes paralelos e grupos de hosts a serem gerenciados

O programa de dimensionamento automático considera apenas o recurso relevante

Outro recurso de dimensionamento automático

Por padrão, os trabalhos solicitam muitos slots e o cluster é dimensionado com base nessas solicitações.

Digamos que queremos dimensionar automaticamente pela solicitação de recurso de trabalho para m_mem_free.

1. Adicionar m_mem_free à gridengine.relevant_resourcesautoscale.json
2. Vincular m_mem_free ao recurso de memória de nível de nó em autoscale.json

Esses atributos podem ser referenciados como o node.* em _default/resources.

Outros atributos estão no node.resources.* namespace, por exemplo, 'node.resources.

Mapeamento de recursos

Há também operações matemáticas disponíveis para o default_resources - reduza os slots numa matriz de nós específica em dois e adicione o recurso docker a todos os nós.

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

Mapeamento dos vCPUs do nó para o complexo de slots e memmb para mem_free são padrões comumente usados. A primeira associação é obrigatória.

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

Se um complexo tiver um atalho não igual ao valor inteiro, defina ambos em default_resources onde physical_cpu é o nome do complexo:

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

A ordenação é importante quando você deseja um comportamento específico para um atributo específico. Para alocar um único slot para um nodearray específico, mantendo a contagem de slots padrão para todos os outros nodearrays:

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

Grupos de anfitriões

O autoscaler do CycleCloud, na tentativa de satisfazer os requisitos do trabalho, mapeia os nós para o grupo de hosts apropriado. Filas, ambientes paralelos e complexos são considerados. Grande parte da lógica consiste em combinar o bucket cyclecloud apropriado e a quantidade de nós com o grupo de hosts sge apropriado.

Para um trabalho enviado como: qsub -q "cloud.q" -l "m_mem_free=4g" -pe "mpi*" 48 ./myjob.sh

O CycleCloud encontra a interseção de grupos de hosts que:

1. Estão incluídos no pe_list para cloud.q e correspondem ao nome pe, por exemplo, pe_list [@allhosts=mpislots],[@hpc1=mpi].
2. Devem ter recursos adequados e quota de subscrição para todos os recursos de trabalho.
3. A configuração de restrições do grupo de hosts não as filtra.

Vários grupos de hosts podem atender a esses requisitos. Quando isso acontece, o sistema deve decidir qual usar. Há três maneiras de resolver conflitos de associação ao grupo host:

1. Configure as filas para evitar ambiguidades.
2. Adicione restrições a autoscale.json.
3. Permita que o CycleCloud escolha os grupos de hosts correspondentes de forma ordenada por nomes, ajustando weight_queue_host_sort < weight_queue_seqno na configuração do agendador.
4. Defina seq_no 10000,[@hostgroup1=100],[@hostgroup2=200] na configuração da fila para indicar uma preferência de grupo de hosts.

Restrições do grupo de hosts

Quando uma fila ou xproject defina vários grupos de anfitriões, qualquer um desses grupos pode potencialmente receber novos anfitriões. Para controlar quais os hosts que são elegíveis para determinadas filas, pode aplicar restrições de grupo de hosts com base nas propriedades do nó.

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

DICA: Inspecione todas as propriedades de nó disponíveis por azge buckets.

Azge

Este pacote vem com uma linha de comando, azge. Este programa é usado para executar o dimensionamento automático e quebra todos os subprocessos sob dimensionamento automático em componentes separados. Esses comandos dependem das variáveis de ambiente GridEngine a serem definidas - você deve ser capaz de chamar qconf e qsub do mesmo perfil onde azge é chamado.

Ao modificar configurações do agendador (qconf) ou configurações de escala automática (autoscale.json), ou até mesmo configurar pela primeira vez, azge pode ser usado para verificar se o comportamento da escala automática está correspondendo às expectativas. Como root, você pode executar as seguintes operações. Para entender como funciona o dimensionamento automático, é importante se familiarizar com esses conceitos.

1. Execute azge validate para verificar as configurações em busca de problemas conhecidos.
2. Execute azge buckets para verificar os recursos oferecidos pelo cluster CycleCloud.
3. Execute azge jobs para inspecionar os detalhes da tarefa em fila.
4. Execute azge demand a tarefa de correspondência com o bucket. Em seguida, examine quais trabalhos são correspondentes a quais buckets e hostgroups.
5. Execute azge autoscale para iniciar o processo de alocação de nós ou adicionar nós que estejam prontos para se juntar.

Quando os comandos estiverem funcionando conforme o esperado, habilite o dimensionamento automático contínuo adicionando o azge autoscale comando ao crontab raiz. Certifique-se de originar as variáveis de ambiente do GridEngine com antecedência.

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

Criando um cluster híbrido

O CycleCloud suporta o cenário de explosão de nuvem. A configuração base pressupõe que o $SGE_ROOT diretório esteja disponível para os nós da nuvem. Essa suposição pode ser relaxada definindo gridengine.shared.spool = false, gridengine.shared.bin = falsee instalando o GridEngine localmente.

Para um caso simples, você deve fornecer um sistema de arquivos que os nós 'execute' possam montar. Este sistema de arquivos deve incluir o ... e você configura a montagem nas configurações opcionais. Quando as dependências dos diretórios agendados e compartilhados são liberadas, você pode desligar o nó do agendador que faz parte do cluster por padrão e usar as configurações do sistema de arquivos externo.

1. Crie um novo cluster GridEngine.
2. Desative o proxy de retorno.
3. Substitua /sched e /shared com sistemas de arquivos externos.
4. Salve o cluster.
5. Remova o nó do agendador como uma ação na interface de utilizador.
6. Inicie o cluster, nenhum nó começará a funcionar inicialmente.
7. Configurar cyclecloud-gridengine com autoscale.json para usar o novo cluster

Usando o Univa Grid Engine no CycleCloud

O projeto CycleCloud para GridEngine usa sge-2011.11 por padrão. Você pode usar seus próprios instaladores Altair GridEngine de acordo com seu contrato de licença Altair. Esta seção documenta como usar o Altair GridEngine com o projeto CycleCloud GridEngine.

Pré-requisitos

Este exemplo usa a versão 8.6.1-demo, mas todas as versões GE maiores que 8.4.0 são suportadas.

1. Os utilizadores devem fornecer binários UGE

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

2. A CLI do CycleCloud deve ser configurada. A documentação está disponível aqui

Copie os binários para o armário na nuvem

Uma versão complementar do AGE (8.6.7-demo) é distribuída com o CycleCloud. Para usar outra versão, carregue os binários para a conta de armazenamento usada pelo 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/

Modificando configurações do modelo de cluster

Faça uma cópia local do modelo GridEngine e modifique-o para usar os instaladores UGE em vez do padrão.

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

No arquivo gridengine.txt, localize a primeira ocorrência de [[[configuration]]] e insira o texto para corresponder ao trecho a seguir. O arquivo não é sensível à indentação.

[[[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"

Essas configurações do GridEngine substituem a versão padrão do GridEngine e o local de instalação quando o cluster é iniciado. Não é seguro sair do /sched, pois se trata de um local NFS partilhado no cluster.