CycleCloud GridEngine Cluster

Open Grid Scheduler (Grid Engine) se puede habilitar fácilmente en un clúster de Azure CycleCloud modificando la "run_list" en la definición del clúster. Los dos componentes básicos de un clúster de Grid Engine son el nodo "maestro", que proporciona un sistema de archivos compartido en el que se ejecuta el software grid Engine y los nodos "execute" que son los hosts que montan el sistema de archivos compartidos y ejecutan los trabajos enviados. Por ejemplo, un fragmento de código de plantilla de clúster de Grid Engine simple puede tener el siguiente aspecto:

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

La importación e inicio de un clúster con la definición en CycleCloud producirá un único nodo "maestro". Los nodos de ejecución se pueden agregar al clúster mediante el cyclecloud add_node comando . Por ejemplo, para agregar 10 nodos de ejecución más:

cyclecloud add_node grid-engine -t execute -c 10

Escalado automático del motor de cuadrícula

Azure CycleCloud admite el escalado automático para Grid Engine, lo que significa que el software supervisará el estado de la cola y activará y desactivará los nodos según sea necesario para completar el trabajo en una cantidad óptima de tiempo y costo. Puede habilitar el escalado automático para Grid Engine agregando Autoscale = true a la definición del clúster:

[cluster grid-engine]
Autoscale = True

De forma predeterminada, todos los trabajos enviados a la cola del motor de cuadrícula se ejecutarán en máquinas de tipo "execute", estas son máquinas definidas por la matriz de nodos denominada "execute". No está limitado al nombre "execute", ni está limitado a un único tipo de configuración de máquina para ejecutar trabajos y escalado automático.

Por ejemplo, un caso común puede ser que tenga un clúster con dos definiciones de nodo diferentes uno para ejecutar trabajos "normales" que consumen CPU estándar, mientras que otro tipo de trabajo puede usar máquinas gpu. En este caso, querrá escalar de forma independiente la cola tanto por trabajos normales como por trabajos de GPU para asegurarse de que tiene una cantidad adecuada de cada máquina para consumir la cola de trabajo. Una definición de ejemplo sería similar a la siguiente:

[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

En el ejemplo anterior, ahora hay dos matrices de nodos: una es una matriz de nodos de ejecución "estándar", la segunda se denomina "gpu" que proporciona un MachineType que tiene dos GPU de Nvidia (Standard_NV12 en Azure). Tenga en cuenta también que ahora hay dos nuevos elementos en la sección de configuración además de la receta "csge:sgeexec". Agregar gridengine.slot_type = gpu indica al programador del motor de cuadrícula que estos nodos deben denominarse nodos "gpu" y, por tanto, solo deben ejecutar trabajos de "gpu". El nombre "gpu" es arbitrario, pero un nombre que describe el nodo es más útil. Establezca gridengine.slots = 2, que indica al software que asegúrese de que este tipo de nodo solo puede ejecutar dos trabajos a la vez (Standard_NV12 solo tiene 2 GPU). De forma predeterminada, el número de ranuras por nodo en el motor de cuadrícula será el número de CPU en el sistema que, en este caso, haría que se ejecutaran demasiados trabajos simultáneamente en el nodo. En el ejemplo anterior, CoreCount=2 se establece en nodearray para que coincida con el número de GPU disponibles en MachineType, lo que permite a CycleCloud escalar correctamente esa matriz en GPU frente al número de CPU.

Puede comprobar el número de ranuras y slot_type las máquinas tienen ejecutando el 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

Observe que hay una de cada "slot_type" que especificó (ejecutar y gpu) y el número de ranuras para la ranura "execute" es 4, que es el número de CPU en el equipo. El número de ranuras para el tipo de ranura "gpu" es 2, que especificamos en nuestra plantilla de configuración de clúster. La tercera máquina es el nodo maestro que no ejecuta trabajos.

Uso avanzado del motor de cuadrícula

Las opciones de configuración anteriores permiten la personalización avanzada de nodos y matrices de nodos. Por ejemplo, si los trabajos requieren una cantidad específica de memoria, por ejemplo, 10 GB cada uno, puede definir una matriz de nodos de ejecución que inicie las máquinas con 60 GB de memoria, a continuación, agregue las opciones gridengine.slots = 6 de configuración para asegurarse de que solo se pueden ejecutar 6 trabajos simultáneamente en este tipo de nodo (asegurándose de que cada trabajo tendrá al menos 10 GB de memoria con la que trabajar).

Nodos agrupados en el motor de cuadrícula

Cuando se envía un trabajo paralelo al motor de cuadrícula, el comportamiento predeterminado de escalado automático que CycleCloud usará es tratar cada trabajo de MPI como una solicitud de nodo agrupado. Los nodos agrupados están estrechamente acoplados e idealmente adecuados para flujos de trabajo de MPI.

Cuando un conjunto de nodos agrupados se une a un clúster de Grid Engine, el identificador de grupo de cada nodo se usa como valor del valor affinity_groupcomplejo . Al requerir que se especifique un affinity_group elemento para los trabajos, permite al programador del motor de cuadrícula asegurarse de que los trabajos solo llegan a las máquinas que están en el mismo grupo.

La automatización de CycleCloud solicitará automáticamente nodos agrupados y los asignará a grupos de afinidad disponibles cuando se encuentren trabajos paralelos.

Envío de trabajos al motor de cuadrícula

La manera más genérica de enviar trabajos a un programador de grid Engine es el comando :

qsub my_job.sh

Este comando enviará un trabajo que se ejecutará en un nodo de tipo "execute", que es un nodo definido por nodearray "execute". Para que un trabajo se ejecute en un elemento nodearray de otro tipo, por ejemplo, el tipo de nodo "gpu" anterior, modificamos nuestro envío:

qsub -l slot_type=gpu my_gpu_job.sh

Este comando garantizará que el trabajo solo se ejecute en un "slot_type" de "gpu".

Si slot_type se omite, "execute" se asignará automáticamente al trabajo. El usuario puede modificar el mecanismo que asigna automáticamente slot_type a los trabajos. Se puede crear un script de Python ubicado en /opt/cycle/jetpack/config/autoscale.py , que debe definir una sola función "sge_job_handler". Esta función recibe una representación de diccionario del trabajo, similar a la salida de un qstat -j JOB_ID comando y debe devolver un diccionario de recursos duros que deben actualizarse para el trabajo. Por ejemplo, a continuación se muestra un script que asignará un trabajo a la "gpu" slot_type si el nombre de los trabajos contiene las letras "gpu". Esto permitiría a un usuario enviar sus trabajos desde un sistema automatizado sin tener que modificar los parámetros de trabajo y seguir ejecutando los trabajos y escalar automáticamente los nodos correctos:

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

El parámetro 'job' pasado es un diccionario que contiene los datos de una qstat -j JOB_ID llamada:

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

Puede usar esta funcionalidad de scripting para asignar automáticamente slot_type en función de cualquier parámetro definido en el trabajo, como argumentos, otros requisitos de recursos como la memoria, el envío de usuarios, etc.

Si fuera a enviar 5 trabajos de cada "slot_type":

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

Ahora habrá 10 trabajos en la cola. Debido al script definido anteriormente, los cinco trabajos con "gpu" en el nombre se configurarían automáticamente para que solo se ejecuten en nodos de "slot_type=gpu". El mecanismo de escalado automático de CycleCloud detectaría que hay 5 trabajos "gpu" y 5 trabajos "ejecutar". Dado que la matriz de nodos "gpu" se define como tener 2 ranuras por nodo, CycleCloud iniciaría 3 de estos nodos (5/2=2,5 redondeado hasta 3). Hay 5 trabajos normales, ya que el tipo de máquina para la matriz de nodos "execute" tiene cuatro CPU cada uno, CycleCloud iniciaría 2 de estos nodos para controlar los trabajos (5/4=1,25 redondeado hasta 2). Después de un breve período de tiempo para que los nodos recién iniciados arranquen y configuren, los 10 trabajos se ejecutarían hasta su finalización y, a continuación, los 5 nodos se apagarían automáticamente antes de que el proveedor de nube le facturase de nuevo.

Se supone que los trabajos tienen una duración de una hora. Si el tiempo de ejecución del trabajo se conoce, el algoritmo de escalado automático puede beneficiarse de esta información. Informe al escalado automático del tiempo de ejecución del trabajo esperado agregándolo al contexto del trabajo. En el ejemplo siguiente se indica al escalado automático que el tiempo de ejecución del trabajo tiene un promedio de 10 minutos:

qsub -ac average_runtime=10 job_with_duration_of_10m.sh

Referencia de configuración del motor de cuadrícula

A continuación se muestran las opciones de configuración específicas del motor de cuadrícula que puede alternar para personalizar la funcionalidad:

CycleCloud admite un conjunto estándar de atributos de escalado automático entre programadores:

Problemas conocidos

• qsh el comando para la sesión interactiva no funciona. Use qrsh como alternativa.
• La escalabilidad automática no respeta el exclusive=1 complejo. Es posible que se inicien menos nodos de los esperados como resultado.

Esta página se refiere a las funcionalidades y la configuración del uso de GridEngine (Altair) con CycleCloud.

Configuración de recursos

La aplicación cyclecloud-gridengine coincide con los recursos sge de los recursos en la nube de Azure para proporcionar herramientas enriquecidas de configuración de clústeres y escalado automático. La aplicación se implementará automáticamente para los clústeres creados a través de la interfaz de usuario de CycleCloud o se puede instalar en cualquier host de administrador de gridengine en un clúster existente.

Instalación o actualización de cyclecloud-gridengine

El paquete cyclecloud-gridengine está disponible en GitHub como artefacto de versión. La instalación y actualización serán el mismo proceso. La aplicación requiere python3 con virtualenv.

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

Archivos importantes

La aplicación analiza la configuración de sge cada vez que se denomina : trabajos, colas y complejos. La información se proporciona en stderr y stdout del comando, así como en un archivo de registro, ambos en niveles configurables. Todos los comandos de administración de gridengine con argumentos también se registran en el archivo.

Colas de SGE, grupos host y entornos paralelos

La utilidad cyclecloud-gridengine autoscale, azge, agregará hosts al clúster según la configuración del clúster. Las operaciones de escalado automático realizan las siguientes acciones.

1. Lea la solicitud de recurso de trabajo y busque una máquina virtual adecuada para iniciarse.
2. Inicie la máquina virtual y espere a que esté lista.
3. Leer la cola y el entorno paralelo del trabajo
4. En función de la cola o pe, asigne el host a un grupo host adecuado
5. Agregue el host al clúster, así como a cualquier otra cola que contenga el grupo host.

Tenga en cuenta la siguiente definición de cola para una cola denominada short.q

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

El envío de un trabajo qsub -q short.q -pe mpi02 12 my-script.sh se iniciará en la concesión de una máquina virtual y, cuando se agregue al clúster, se unirá al grupo de hosts @mpihg02 porque ese es el grupo host disponible para la cola y para el entorno paralelo. También se agregará a @allhosts, que es un grupo host especial.

Sin especificar pe, qsub -q short.q my-script.sh la máquina virtual resultante se agregará a @allhosts y @lowpriority son los grupos host de la cola que no están asignadas pes.

Por último, un trabajo enviado con qsub -q short.q -pe mpi0* 12 my-script.sh dará como resultado una máquina virtual agregada a @mpihg01 o @mpihg02 en función de las predicciones de asignación de CycleCloud.

Los entornos paralelos equivalen implícitamente al grupo de selección de ubicación cyclecloud. Las máquinas virtuales de un PE están restringidas a estar dentro de la misma red. Si desea usar un PE que no mantenga un grupo de selección de ubicación, use el archivo autoscale.json para rechazarlo.

Aquí optamos por no participar en grupos de selección de ubicación para la marca pe:

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

Grupos de selección de ubicación de CycleCloud

Los grupos de selección de ubicación de CycleCloud asignan uno a uno a VMSS de Azure con SinglePlacementGroup: las máquinas virtuales de un grupo de selección de ubicación comparten un tejido de Infiniband y comparten solo con máquinas virtuales dentro del grupo de selección de ubicación. Para conservar intuitivamente estos silos, los grupos de selección de ubicación también asignan 1:1 con el entorno paralelo gridengine.

Al especificar un entorno paralelo para un trabajo, se restringirá la ejecución del trabajo en un grupo de selección de ubicación a través de la lógica de asignación de grupos host inteligentes. Puede optar por no participar en este comportamiento con la configuración mencionada anteriormente en autoscale.json : "required_placement_groups" : false.

Configuración de escalado automático

Este complemento escalará automáticamente la cuadrícula para satisfacer las demandas de la carga de trabajo. El archivo de configuración autoscale.json determina el comportamiento del escalador automático del motor de cuadrícula.

• Establecimiento de los detalles de la conexión cyclecloud
• Establecer el temporizador de finalización para los nodos inactivos
• El escalado automático multidimensional es posible, establezca los atributos que se usarán en el empaquetado del trabajo, por ejemplo, ranuras, memoria.
• Registro de las colas, entornos paralelos y grupos host que se van a administrar

El programa de escalado automático solo tendrá en cuenta los recursos pertinentes.

Recurso de escalado automático adicional

De forma predeterminada, el clúster con escala en función de cuántas ranuras solicitan los trabajos. Podemos agregar otra dimensión al escalado automático.

Supongamos que queremos escalar automáticamente mediante la solicitud de recurso de trabajo para m_mem_free.

1. Agregar m_mem_free a gridengine.relevant_resources en autoscale.json
2. Vínculo m_mem_free al recurso de memoria de nivel de nodo en autoscale.json

Estos atributos pueden ser referencias con node.* como valor en _default/resources.

Los atributos adicionales están en el node.resources.* espacio de nombres, por ejemplo, "node.resources".

Asignación de recursos

También hay matemáticas disponibles para el default_resources: reduzca las ranuras de una matriz de nodos determinada en dos y agregue el recurso de Docker a todos los nodos:

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

Asigne las vCPU del nodo a las ranuras complejas y memmb a mem_free los valores predeterminados que se usan habitualmente. Se requiere la primera asociación.

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

Tenga en cuenta que si un complejo tiene un acceso directo no igual a todo el valor, defina ambos en default_resources donde physical_cpu sea el nombre complejo:

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

El orden es importante cuando se desea un comportamiento determinado para un atributo específico. Para asignar una sola ranura para una matriz de nodos específica mientras conserva el recuento de ranuras predeterminados para todas las demás nodoarrays:

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

Grupos host

CycleCloud autoscaler, al intentar satisfacer los requisitos de trabajo, asignará nodos al grupo host adecuado. Se tienen en cuenta todas las colas, entornos paralelos y complejos. Gran parte de la lógica coincide con el cubo cyclecloud adecuado (y la cantidad de nodos) con el grupo host sge adecuado.

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

CycleCloud encontrará la intersección de grupos host que:

1. Se incluyen en el pe_list de cloud.q y coinciden con el nombre pe, por ejemplo, pe_list [@allhosts=mpislots],[@hpc1=mpi].
2. Disponer de recursos adecuados y cuota de suscripción para proporcionar todos los recursos de trabajo.
3. No se filtran por la configuración de restricciones del grupo host.

Es posible que varios grupos host cumplan estos requisitos, en cuyo caso la lógica tendrá que elegir. Hay tres maneras de resolver ambigüedades en la pertenencia a grupos host:

1. Configure las colas para que no haya ambigüedades.
2. Agregue restricciones a autoscale.json.
3. Deje que CycleCloud elija amoungst los grupos host coincidentes de forma ordenada por nombres ajustando weight_queue_host_sort < weight_queue_seqno en la configuración del programador.
4. Establezca seq_no 10000,[@hostgroup1=100],[@hostgroup2=200] en la configuración de la cola para indicar una preferencia de grupo host.

Restricciones de grupo de hosts

Cuando se definen varios grupos de hosts mediante una cola o xproject, todos estos grupos host pueden tener potencialmente los hosts agregados. Puede limitar los tipos de hosts que se pueden agregar a las colas estableciendo restricciones de grupo de hosts. Establezca una restricción basada en las propiedades del nodo.

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

SUGERENCIA: Inspeccione todas las propiedades de nodo disponibles por azge buckets.

azge

Este paquete incluye una línea de comandos, azge. Este programa debe usarse para realizar el escalado automático y ha desglosado todos los subprocesos en escalabilidad automática. Estos comandos dependen de las variables de entorno gridengine que se van a establecer: debe poder llamar qconf a y qsub desde el mismo perfil en azge el que se llama.

Al modificar las configuraciones del programador (qconf) o las configuraciones de escalado automático (autoscale.json), o incluso la configuración por primera vez, se puede usar azge para comprobar que el comportamiento de escalado automático coincide con las expectativas. Como raíz, puede ejecutar las siguientes operaciones. Es aconsejable familiarizarse con estos para comprender el comportamiento de la escalabilidad automática.

1. Ejecute azge validate para comprobar las configuraciones de los problemas conocidos.
2. Ejecute azge buckets para examinar qué recursos ofrece el clúster de CycleCloud.
3. Ejecute azge jobs para inspeccionar los detalles del trabajo en cola.
4. Ejecute azge demand el trabajo para buscar coincidencias de cubos, examine qué trabajos se comparan con los cubos y grupos host.
5. Ejecute azge autoscale para iniciar el proceso de asignación de nodos o agregue nodos que estén listos para unirse.

A continuación, cuando estos comandos se comportan según lo previsto, habilite el escalado automático continuo agregando el azge autoscale comando a la tabla crontab raíz. (Siga las variables de entorno gridengine)

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

Creación de un clúster híbrido

CycleCloud admitirá el escenario de expansión a la nube. La configuración base supone que el $SGE_ROOT directorio está disponible para los nodos en la nube. Esta suposición se puede relajar estableciendo gridengine.shared.spool = falsee gridengine.shared.bin = false instalando GridEngine localmente. Para un caso sencillo, debe proporcionar un sistema de archivos que los nodos $SGE_ROOT de ejecución puedan montar y configurar ese montaje en las opciones opcionales. Cuando se libera la dependencia de los directorios compartidos y sched, puede apagar el nodo del programador que forma parte del clúster de forma predeterminada y usar las configuraciones del sistema de archivos externo.

1. Cree un nuevo clúster gridengine.
2. Deshabilite el proxy de devolución.
3. Reemplace /sched y /shared por sistemas de archivos externos.
4. Guarde el clúster.
5. Quite el nodo del programador como una acción en la interfaz de usuario.
6. Inicie el clúster, no se iniciará inicialmente ningún nodo.
7. Configuración cyclecloud-gridengine con autoscale.json para usar el nuevo clúster

Uso de Univa Grid Engine en CycleCloud

El proyecto CycleCloud para GridEngine usa sge-2011.11 de forma predeterminada. Puede usar sus propios instaladores de Altair GridEngine según su contrato de licencia de Altair.
En esta sección se documenta cómo usar Altair GridEngine con el proyecto CycleCloud GridEngine.

Prerrequisitos

En este ejemplo se usará la versión 8.6.1-demo, pero se admiten todas las versiones > de ge 8.4.0.

1. Los usuarios deben proporcionar archivos binarios UGE.

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

2. La CLI de CycleCloud debe estar configurada. La documentación está disponible aquí.

Copia de los archivos binarios en la caja de seguridad en la nube

Una versión complementaria de AGE (8.6.7-demo) se distribuye con CycleCloud. Para usar otra versión, cargue los archivos binarios en la cuenta de almacenamiento que usa 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/

Modificación de configuraciones en la plantilla de clúster

Realice una copia local de la plantilla gridengine y modifíquela para usar los instaladores de UGE en lugar del valor predeterminado.

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

En el archivo gridengine.txt , busque la primera aparición de e inserte texto de forma que coincida con el fragmento de [[[configuration]]] código siguiente. Este archivo no distingue la sangría.

NOTA: Los detalles de la configuración, especialmente la versión, deben coincidir con el nombre del archivo del 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"

Estas configuraciones invalidarán la versión predeterminada de gridengine y la ubicación de instalación cuando se inicie el clúster. No es seguro salir de , /sched ya que es una ubicación nfs compartida específicamente en el clúster.