Cluster de GridEngine de cicloCloud

O Programador de Grelhas Aberta (Motor de Grelha) pode ser facilmente ativado num cluster Azure CycleCloud modificando o "run_list" na definição de cluster. Os dois componentes básicos de um cluster grid engine são o nó 'master' que fornece um sistema de ficheiros partilhado no qual o software grid engine funciona, e os nós 'executar' que são os anfitriões que montam o sistema de ficheiros partilhado e executam os trabalhos submetidos. Por exemplo, um simples corte de modelo de cluster do motor de grelha pode parecer:

[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 definição no CycleCloud produzirá um único nó 'master'. Os nós de execução podem ser adicionados ao cluster através do cyclecloud add_node comando. Por exemplo, para adicionar mais 10 nóns de execução:

cyclecloud add_node grid-engine -t execute -c 10

Autoscaling do motor da grelha

O Azure CycleCloud suporta a autoscalagem para o motor de grelha, o que significa que o software monitorizará o estado da sua fila e ligará e desligará os nós conforme necessário para completar o trabalho numa quantidade/custo ideal. Pode ativar a autoscalagem para o motor de grelha, adicionando Autoscale = true à definição de cluster:

[cluster grid-engine]
Autoscale = True

Por predefinição, todos os trabalhos submetidos na fila do Motor de Grelha serão executados em máquinas do tipo 'executar', tratando-se de máquinas definidas pela matriz de nó denominado 'executar'. Não se limita ao nome 'executar', nem se limita a um único tipo de configuração de máquina para executar trabalhos e autoescalar.

Como exemplo, um caso comum pode ser que você tem um cluster com duas definições diferentes de nó um é para executar trabalhos 'normais' que consomem CPU padrão enquanto outro tipo de trabalho pode usar máquinas gpu. Neste caso, você gostaria de escalar a sua fila de forma independente tanto por trabalhos normais como por trabalhos de GPU para se certificar de que tem uma quantidade adequada de cada máquina para consumir a fila de trabalho. Uma definição de exemplo 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 acima, existem agora dois conjuntos de nós: Um é um conjunto de nó de execução 'standard', o segundo é chamado 'gpu' fornecendo um MachineType que tem dois GPU's Nvidia (Standard_NV12 em Azure). Note também que existem agora dois novos itens na secção de configuração além da receita 'csge:sgeexec'. A adição gridengine.slot_type = gpu diz ao programador grid engine que estes 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 descreve o nó é mais útil. Set gridengine.slots = 2, que diz ao software para se certificar de que este tipo de nó só pode executar dois empregos ao mesmo tempo (Standard_NV12 só tem 2 GPUs). Por predefinição, o número de faixas horárias por nó no motor de grelha será o número de CPUs no sistema que, neste caso, levaria a que demasiados postos de trabalho fossem executados simultaneamente no nó. No exemplo acima, CoreCount=2 é definido no nodearray para corresponder ao número de GPUs disponíveis no MachineType, permitindo que o CycleCloud escasseia corretamente essa matriz na contagem de GPU vs CPU.

Pode verificar o número de ranhuras e slot_type as 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

Note que há um de cada 'slot_type' que especificamos (executar e gpu) e o número de slots para a ranhura 'executar' é 4, que é o número de CPUs na máquina. O número de slots para o tipo de slot 'gpu' é 2, que especificamos no nosso modelo de configuração de cluster. A terceira máquina é o nó mestre que não gere empregos.

Utilização avançada do motor de grelha

As definições de configuração acima permitem uma personalização avançada dos nós e dos nós. Por exemplo, se os trabalhos requerem uma quantidade específica de memória, digamos 10GB cada, pode definir um nodearray de execução que inicia máquinas com 60GB de memória, em seguida, adicionar nas opções gridengine.slots = 6 de configuração para garantir que apenas 6 postos de trabalho podem simultaneamente funcionar neste tipo de nó (garantindo que cada trabalho terá pelo menos 10GB de memória para trabalhar).

Nómadas agrupados no motor da grelha

Quando um trabalho paralelo é submetido ao motor da rede, o comportamento de autoescala padrão que o CycleCloud usará é tratar cada trabalho de MPI como um pedido de nó agrupado. Os nós agrupados são bem acoplados e idealmente adequados para fluxos de trabalho de MPI.

Quando um conjunto de nós agrupados se junta a um cluster grid engine, o id de grupo de cada nó é usado como o valor do valor affinity_groupcomplexo . Ao exigir uma especificação affinity_group para trabalhos, permite que o programador do Motor de Grelha garanta que os postos de trabalho só aterram em máquinas que estão no mesmo grupo.

A automatização do CycleCloud solicitará automaticamente os nós agrupados e atribui-os aos grupos de afinidade disponíveis quando forem encontrados trabalhos paralelos.

Submeter postos de trabalho ao motor de grelha

A forma mais genérica de submeter empregos a um programador de motores de grelha é o comando:

qsub my_job.sh

Este comando submeterá um trabalho que será executado num nó de tipo 'executar', que é um nó definido pelo nó 'executar'. Para fazer um trabalho funcionar num nó de um tipo diferente, por exemplo o tipo de nó 'gpu' acima, modificamos a nossa submissão:

qsub -l slot_type=gpu my_gpu_job.sh

Este comando garantirá que o trabalho só funciona numa "slot_type" de 'gpu'.

Se slot_type for omitida, a 'execução' será automaticamente atribuída ao trabalho. O mecanismo que atribui automaticamente slot_type a empregos pode ser modificado pelo utilizador. Pode ser criada uma script python localizada em /opt/cycle/jetpack/config/autoscale.py que deve definir uma única função "sge_job_handler". Esta função recebe uma representação do trabalho no dicionário, semelhante à saída de um qstat -j JOB_ID comando e deve devolver um dicionário de recursos duros que precisam de ser atualizados para o trabalho. Como exemplo, abaixo está um guião que atribuirá um trabalho à slot_type 'gpu' se o nome do trabalho contiver as letras 'gpu'. Isto permitiria que um utilizador apresentasse os seus trabalhos a partir de um sistema automatizado sem ter de modificar os parâmetros de trabalho e ainda ter os postos de trabalho executados e autoescalar os nójoos 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 'trabalho' passado é um dicionário que contém os dados numa 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'
    }
}

Pode utilizar esta funcionalidade de script para atribuir automaticamente slot_type com base em qualquer parâmetro definido no trabalho, tais como argumentos, outros requisitos de recursos como memória, submissão do utilizador, etc.

Se apresentasse 5 postos de trabalho de cada "slot_type":

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

Haveria agora 10 postos de trabalho na fila. Devido ao guião acima definido, os cinco postos de trabalho com 'gpu' no nome seriam automaticamente configurados para funcionar apenas em nós de 'slot_type=gpu'. O mecanismo de autoescala CycleCloud detetaria que existem 5 postos de trabalho 'gpu' e 5 empregos de "execução". Uma vez que o nodearray 'gpu' é definido como tendo 2 ranhuras por nó, CycleCloud iniciaria 3 destes nós (5/2=2,5 arredondados até 3). Existem 5 trabalhos normais, uma vez que o tipo de máquina para o nó 'executar' tem 4 CPU's cada, CycleCloud iniciaria 2 destes nós para lidar com os trabalhos (5/4=1,25 arredondado até 2). Após um curto período de tempo para os novos nós começarem a arrancar e configurar, todos os 10 postos de trabalho seriam concluídos e, em seguida, os 5 nós seriam automaticamente desligados antes de ser cobrado novamente pelo Cloud Provider.

Presume-se que os empregos têm uma duração de uma hora. Se o tempo de execução do trabalho for conhecido, o algoritmo de escala automática pode beneficiar desta informação. Informe a autoescala do tempo de funcionamento do trabalho esperado adicionando-o ao contexto de trabalho. O exemplo a seguir indica que o tempo de funcionação do trabalho é, em média, de 10 minutos:

qsub -ac average_runtime=10 job_with_duration_of_10m.sh

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

Seguem-se as opções de configuração específicas do Motor de Grelha que pode alternar para personalizar a funcionalidade:

CycleCloud suporta um conjunto padrão de atributos de autostop em todos os agendadores:

Problemas Conhecidos

• qsh comando para sessão interativa não funciona. Use qrsh como alternativa.
• O exclusive=1 complexo não é respeitado por autoescala. Menos nós do que o esperado podem começar como resultado.

Esta página diz respeito às capacidades e configuração da utilização (Altair) GridEngine com CycleCloud.

Configurar recursos

A aplicação de motor de rede de ciclocloud combina recursos de sge para obter recursos em nuvem azul para fornecer ferramentas de autoscalagem e configuração de clusters ricas. A aplicação será implementada automaticamente para clusters criados através do CycleCloud UI ou pode ser instalada em qualquer anfitrião de administração de engenharia de grelhas num cluster existente.

Instalação ou modernização do ciclocloud-grideng

O pacote de motor de rede de ciclocloud está disponível no github como um artefacto de libertação. A instalação e a atualização serão o mesmo processo. A aplicação requer python3 com virtualenv.

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

Ficheiros Importantes

A aplicação analisa a configuração do sge cada vez que é chamada - empregos, filas, complexos. A informação é fornecida no stderr e no stdout do comando, bem como num ficheiro de registo, ambos a níveis configuráveis. Todos os comandos de gestão de motor de grelha com argumentos também são registados para arquivar.

Filas SGE, grupos de anfitriões e ambientes paralelos

O utilitário de autoescalação de rede de ciclocloud, azgeirá adicionar hospedeiros ao cluster de acordo com a configuração do cluster. As operações de autoescalagem realizam as seguintes ações.

1. Leia o pedido de recursos de trabalho e encontre um VM apropriado para começar
2. Inicie o VM e espere que esteja pronto.
3. Leia a fila e o ambiente paralelo do trabalho
4. Com base na fila/pe atribua o anfitrião a um grupo de anfitriões apropriado
5. Adicione o anfitrião ao cluster, bem como a qualquer outra fila que contenha o grupo anfitrião

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]

A submissão de um trabalho começará por qsub -q short.q -pe mpi02 12 my-script.sh arrendar um VM, e quando for adicionado ao cluster, juntar-se-á ao grupo de anfitriões @mpihg02 porque esse é o grupo de anfitriões disponível tanto para a fila como para o ambiente paralelo. Será também adicionado à @allhosts, que é um grupo especial de anfitriões.

Sem especificar um pe, qsub -q short.q my-script.sh o VM resultante será adicionado a @allhosts e @lowpriority estes são os grupos anfitriões na fila que não são atribuídos pes.

Finalmente, um trabalho submetido resultará qsub -q short.q -pe mpi0* 12 my-script.sh num VM adicionado a @mpihg01 ou @mpihg02 dependendo das previsões de atribuição do CycleCloud.

Ambientes paralelos equivalem implicitamente ao grupo de colocação de nuvens de ciclo. Os VMs num PE estão limitados a estar dentro da mesma rede. Se desejar utilizar um PE que não mantenha um grupo de colocação, use o autoscale.json para excluir.

Aqui optamos por não fazer grupos de colocação para a make pe:

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

Grupos de colocação de CycleCloud

Os grupos de colocação CycleCloud mapeiam um a um para o Azure VMSS com singlePlacementGroup - VMs em um grupo de colocação compartilham um Tecido Infiniband e partilham apenas com VMs dentro do grupo de colocação. Para preservar intuitivamente estes silos, os grupos de colocação mapeiam 1:1 com ambiente paralelo de gridengine também.

Especificar um ambiente paralelo para um trabalho irá restringir o trabalho a funcionar em um grupo de colocação através de uma lógica de atribuição de grupos de anfitriões inteligentes. Pode optar por não fazer este comportamento com a configuração acima referida em autoscale.json : "required_placement_groups" : false.

Config de escala automática

Este plugin irá escalar automaticamente a grelha para satisfazer as exigências da carga de trabalho. O ficheiro autoscale.json config determina o comportamento do autoescalador do motor de grelha.

• Desaprovo os detalhes da ligação cyclecloud
• Desave o temporizador de terminação para os nosdes inativos
• Autoscalagem multidimensional é possível, definir quais atributos a usar na embalagem de trabalho, por exemplo, ranhuras, memória
• Registar as filas, ambientes paralelos e grupos de acolhimento a gerir

O programa de autoscalagem só considerará o Recurso Relevante

Recurso de autoescalação adicional

Por defeito, o cluster com escala com base em quantas vagas são solicitadas pelos postos de trabalho. Podemos adicionar outra dimensão ao autoescaling.

Digamos que queremos fazer uma escala automática através do pedido de recursos de trabalho para m_mem_free.

1. Adicione m_mem_free ao gridengine.relevant_resources in autoscale.json
2. Ligação m_mem_free ao recurso de memória de nível de nó em autoscale.json

Estes atributos podem ser referências node.* com o valor em _default/recursos.

Atributos adicionais estão no espaço de node.resources.* nome, por exemplo'node.resources.

Mapeamento de recursos

Existem também matemática disponíveis para o default_resources - reduza as ranhuras num conjunto de nó particulares por dois e adicione o recurso estivador a todos os nós:

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

Mapear os vCPUs do nó para o complexo de ranhuras, e memmb para mem_free serem normalmente usados predefinições. A primeira associação é necessária.

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

Note que se um complexo tem um atalho não igual a todo o valor, então defina tanto em default_resources onde physical_cpu está o nome complexo:

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

A encomenda é importante quando se quer um comportamento específico para um atributo específico. Para atribuir uma única ranhura para um nódarray específico, mantendo a contagem de slots predefinidos para todos os outros nólarrays:

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

Grupos de anfitriões

O autoescala CycleCloud, na tentativa de satisfazer os requisitos de trabalho, mapeará os nós para o grupo de anfitriões apropriado. São consideradas filas, ambientes paralelos e complexos. Grande parte da lógica está a combinar o balde de nuvens de ciclo apropriado (e quantidade de nó) com o grupo de anfitriões de sge apropriado.

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

CycleCloud encontrará a intersecção de grupos de anfitriões 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. Dispor de recursos adequados e quota de subscrição para fornecer todos os recursos de trabalho.
3. Não são filtrados pela configuração de restrições do grupo anfitrião.

É possível que vários grupos de anfitriões cumpram estes requisitos, caso em que a lógica terá de escolher. Existem três formas de resolver ambiguidades na adesão ao grupo de acolhimento:

1. Configure as filas para que não haja ambiguidades.
2. Adicione restrições a autoscale.json.
3. Deixe o CycleCloud escolher os grupos anfitriões correspondentes de forma ordenada pelo nome, ajustando-se weight_queue_host_sort < weight_queue_seqno na configuração do programador.
4. Desapeda fique seq_no 10000,[@hostgroup1=100],[@hostgroup2=200] na configuração da fila para indicar uma preferência do grupo de anfitriões.

Restrições do grupo anfitrião

Quando vários grupos de anfitriões são definidos por uma fila ou xproject, todos estes grupos de anfitriões podem potencialmente ter os anfitriões adicionados a eles. Pode limitar que tipo de anfitriões podem ser adicionados às filas, definindo as restrições do grupo anfitrião. Desenteie uma restrição 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 do nó disponível por azge buckets.

azge

Este pacote vem com uma linha de comando, azge. Este programa deve ser utilizado para realizar autoscaling e descodificou todos os subprocessos em autoescalação. Estes comandos dependem das variáveis do ambiente de motor de grelha a definir - você deve ser capaz de ligar qconf e qsub do mesmo perfil onde azge é chamado.

Ao modificar configurações de programadores (qconf) ou configurações de autoescala (autoscale.json), ou mesmo a configuração pela primeira vez, o azge pode ser usado para verificar se o comportamento de autoescalação corresponde às expectões correspondentes. Como raiz, pode executar as seguintes operações. É aconselhável familiarizarmo-nos com isto para compreender o comportamento da autoescala.

1. Corra azge validate para verificar configurações para problemas conhecidos.
2. Corra azge buckets para examinar os recursos que o seu cluster CycleCloud está a oferecer.
3. Corra azge jobs para inspecionar os detalhes do trabalho em fila.
4. Executar azge demand o trabalho para combinar balde, examinar quais os trabalhos que são combinados com os baldes e grupos de anfitriões.
5. Corra azge autoscale para iniciar o processo de atribuição do nó, ou adicione nós prontos para aderir.

Em seguida, quando estes comandos se comportarem como esperado, ative a autoescala contínua adicionando o azge autoscale comando ao crontab raiz. (Souce as variáveis do ambiente do motor da grelha)

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

Criar um cluster híbrido

O CycleCloud irá suportar o cenário de explosão na nuvem. A configuração base pressupõe que o $SGE_ROOT diretório está disponível para os nós de nuvem. Esta suposição pode ser descontraída definindo gridengine.shared.spool = false, gridengine.shared.bin = false e instalando gridengine localmente. Para um caso simples, deve fornecer um sistema de ficheiros que pode ser montado pelos nós de execução que contém o $SGE_ROOT diretório e configuração que montam nas definições opcionais. Quando a dependência dos diretórios sched e partilhados for lançada, pode desligar o nó do programador que faz parte do cluster por padrão e utilizar as configurações do sistema de ficheiros externo.

1. Criar um novo cluster de motor de grelha.
2. Desative o representante de devolução.
3. Substitua/sched e/partilhado por sistemas de ficheiros externos.
4. Salve o aglomerado.
5. Remova o nó do agendador como uma ação na UI.
6. Inicie o cluster, nenhum nós começará inicialmente.
7. Configure cyclecloud-gridengine com autoscale.json para usar o novo cluster

Usando o motor da grelha Univa em CycleCloud

O projeto CycleCloud para GridEngine utiliza sge-2011.11 por predefinição. Pode utilizar os seus próprios instaladores Altair GridEngine de acordo com o seu contrato de licença Altair.
Esta secção documenta como utilizar o Altair GridEngine com o projeto CycleCloud GridEngine.

Pré-requisitos

Este exemplo irá utilizar a versão 8.6.1-demo, mas todas as versões > ge 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-comum.tar.gz

2. O CicloCloud CLI deve estar configurado. A documentação está disponível aqui

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

Uma versão complementar da AGE (8.6.7-demo) é distribuída com CycleCloud. Para utilizar outra versão, faça o upload dos binários para a conta de armazenamento que o CycleCloud utiliza.

$ 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/

Modificar configs para o modelo de cluster

Faça uma cópia local do modelo de motor de grelha e modifique-o para utilizar os instaladores UGE em vez do padrão.

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

No ficheiro gridengine.txt , localize a primeira ocorrência e insira o texto de [[[configuration]]] modo a corresponder ao corte abaixo. Este ficheiro não é sensível ao entalhe.

NOTA: Os detalhes na configuração, particularmente a versão, devem coincidir com o nome do ficheiro do instalador.

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

Estes configs irão sobrepor-se à versão padrão do motor de grelha e à localização de instalação quando o cluster começar. Não é seguro sair do /sched agrupamento, uma vez que é uma localização de nfs especificamente partilhada no aglomerado.