Clúster de CycleCloud GridEngine

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. Un clúster de Grid Engine consta de dos componentes principales. La primera es el nodo "master", que proporciona un sistema de archivos compartido donde se ejecuta el software Grid Engine. El segundo es el conjunto de nodos "execute", que son los hosts que montan el sistema de archivos compartidos y ejecutan los trabajos que se envían. Por ejemplo, un fragmento de código de plantilla de clúster simple de Grid Engine 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]

Importar e iniciar un clúster con una definición en CycleCloud da como resultado un único nodo "maestro". Los nodos "execute" se pueden agregar al clúster mediante el cyclecloud add_node comando . Por ejemplo, para agregar 10 nodos "ejecute" más:

cyclecloud add_node grid-engine -t execute -c 10

Escalado automático de Grid Engine

Azure CycleCloud admite el escalado automático para Grid Engine. Este comportamiento significa que el software supervisa continuamente el estado de la cola y activa o desactiva automáticamente los nodos según sea necesario para completar la carga de trabajo de forma eficaz en términos 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 de Grid Engine se ejecutan en máquinas de tipo "execute". Estas máquinas están 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 realizar escalado automático.

Por ejemplo, un escenario común implica un clúster con dos definiciones de nodo diferentes. Uno está diseñado para ejecutar trabajos "normales" que usan CPU estándar. El otro está pensado para trabajos que requieren máquinas habilitadas para 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 que se muestra, ahora hay dos matrices de nodos: una es una matriz de nodos 'execute' estándar, la segunda se denomina 'gpu' que proporciona un tipo de máquina con dos GPU 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". La adición 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, Grid Engine asigna el número de ranuras por nodo en función del número de CPU del sistema. En este caso, ese comportamiento predeterminado podría dar lugar a demasiados trabajos que se ejecutan simultáneamente en un solo nodo. En el ejemplo que se muestra, 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 verificar el número de ranuras y el tipo de ranura de sus máquinas 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" especificada "execute" y "gpu". Los slot_types se configuran individualmente, y el número de ranuras para la ranura "execute" es 4, que es el número de CPUs en la máquina. El número de ranuras para el tipo de ranura "gpu" es 2, que se especificó en la plantilla de configuración del clúster. La tercera máquina es el nodo maestro que no ejecuta trabajos.

Uso avanzado de Grid Engine

Estas opciones de configuración 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 "ejecutar" que inicie máquinas con 60 GB de memoria, 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 tenga 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, CycleCloud utiliza el comportamiento de escalado automático predeterminado para tratar cada trabajo de MPI como una solicitud agrupada de nodos. Los nodos agrupados están estrechamente acoplados e idealmente adecuados para los 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 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 solicita automáticamente nodos agrupados y los asigna a grupos de afinidad disponibles cuando se encuentran trabajos paralelos.

Envío de trabajos al sistema de gestión de cuadrículas

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

qsub my_job.sh

Este comando envía un trabajo que se ejecuta en un nodo de tipo "execute", que es un nodo definido por nodearray "execute". Para que un trabajo se ejecute en un conjunto de nodos (nodearray) de un tipo diferente, por ejemplo, el tipo de nodo "gpu" como se muestra, modificamos nuestra configuración.

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 se omite slot_type, "execute" se asigna 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 única función "sge_job_handler". Esta función recibe una representación en forma de diccionario del trabajo, similar a la salida de un comando qstat -j JOB_ID y debe devolver un diccionario de recursos esenciales que deben actualizarse para el trabajo.

Por ejemplo, el siguiente script asigna un trabajo al slot_type "gpu" si el nombre de los trabajos incluye las letras "gpu". Los usuarios pueden enviar sus trabajos automáticamente sin cambiar los parámetros del trabajo, a la vez que garantizan que los trabajos se ejecutan y escalan 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 llamada 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'
    }
}

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

Supongamos que envía 5 trabajos para cada "slot_type":

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

Ahora, habría 10 trabajos en la cola. Debido al script definido, 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 'execute'. 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 de nodearray "execute" tiene 4 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 inicio, los nodos recién iniciados arrancan y se configuran a sí mismos. Una vez listo, los 10 trabajos se ejecutan hasta su finalización. A continuación, los 5 nodos se apagan automáticamente antes de que comience otro ciclo de facturación con el proveedor de nube.

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

qsub -ac average_runtime=10 job_with_duration_of_10m.sh

Referencia de configuración del gestor de cuadrícula

A continuación se muestran las opciones de configuración específicas de Grid Engine que puede ajustar para personalizar la funcionalidad:

CycleCloud admite un conjunto estándar de atributos de detención automática en los planificadores.

Problemas conocidos

• qsh el comando para la sesión interactiva no funciona. Use qrsh como alternativa.
• El escalado automático no respeta el exclusive=1 complejo, lo que puede provocar que se inicien menos nodos de los esperados.

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 los recursos de sge con los de la nube de Azure para proporcionar herramientas de escalado automático y configuración de clústeres enriquecidas. La aplicación se implementa 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 conjunto cyclecloud-gridengine está disponible en GitHub como artefacto de lanzamiento. La instalación y actualización siguen 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 ejecuta: 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 de escalado automático cyclecloud-gridengine, 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 recursos 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 entorno paralelo (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

Considere 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 mediante qsub -q short.q -pe mpi02 12 my-script.sh inicia al menos una máquina virtual. Cuando se agrega el clúster, se une al grupo host de @mpihg02 porque ese es el grupo host disponible para la cola y al entorno paralelo. También se une a @allhosts, un grupo de hosts especial.

Si envía un trabajo con qsub -q short.q my-script.sh y no especifica un entorno paralelo (pe), la máquina virtual resultante combina los grupos host @allhosts y @lowpriority vinculados a la cola que no tiene asignada ningún pe.

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

Los entornos paralelos equivalen implícitamente al grupo de colocación de CycleCloud. Las máquinas virtuales de un PE están restringidas a estar dentro de la misma red. Si desea utilizar un PE que no mantenga un grupo de colocación, use el autoscale.json para excluirse.

Aquí, optamos por no participar en grupos de colocación para el pe make:

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

Grupos de colocación de CycleCloud

Los grupos de colocación de CycleCloud asignan uno a uno a VMSS de Azure con SinglePlacementGroup: las máquinas virtuales de un grupo de colocación comparten Infiniband Fabric y comparten solo con máquinas virtuales dentro del grupo de colocación. Para preservar intuitivamente estos silos, los grupos de colocación también se 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 colocación a través de la lógica de asignación de grupos host inteligentes. Puede deshabilitar este comportamiento a través de la configuración correspondiente en autoscale.json: "required_placement_groups" : false.

Configuración de escalado automático

Este complemento escala 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 de Grid Engine.

• Establecimiento de los detalles de la conexión cyclecloud
• Establecer el temporizador de terminación para los nodos inactivos
• Se admite el escalado automático multidimensional. Puede configurar los atributos que se usarán en el empaquetado del trabajo, por ejemplo, ranuras o memoria.
• Registrar las colas, los entornos paralelos y los grupos host que se van a administrar

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

Otro recurso de escalado automático

De forma predeterminada, los trabajos solicitan muchas ranuras y el clúster se escala en función de esas solicitudes.

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

1. Agregar m_mem_free al elemento gridengine.relevant_resources en autoscale.json
2. Vincular m_mem_free al recurso de memoria a nivel de nodo en autoscale.json

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

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

Mapeo 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
    },

Asignación de las vCPU de nodo al complejo de ranuras, y memmb a mem_free como valores predeterminados comúnmente utilizados. Se requiere la primera asociación.

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

Si un complejo tiene un acceso directo no igual al valor completo, defina ambos en default_resources donde physical_cpu es 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 un nodearray específico mientras conserva el número de ranuras predeterminado para todas las demás nodearrays:

    "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, asigna nodos al grupo host adecuado. Se tienen en cuenta colas, entornos paralelos y complejos. Gran parte de la lógica está en emparejar el contenedor cyclecloud adecuado (y la cantidad de nodos) con el grupo de hosts de 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. Tener suficientes recursos y cuota de suscripción para proporcionar todos los recursos necesarios para el trabajo.
3. La configuración de restricciones de grupo de hosts no las filtra.

Es posible que varios grupos host cumplan estos requisitos. Cuando esto sucede, el sistema debe decidir cuál usar. Hay tres maneras de resolver conflictos de pertenencia a grupos de hosts:

1. Configure las colas para evitar ambigüedades.
2. Agregue restricciones a autoscale.json.
3. Deje que CycleCloud elija 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 cola para indicar una preferencia de grupo host.

Restricciones de grupos de anfitriones

Cuando una cola o un proyecto x definen varios grupos host, cualesquiera de esos grupos puede potencialmente recibir nuevos hosts. Para controlar qué hosts son aptos para las colas, puede aplicar restricciones de grupo de hosts en función de 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 se usa para realizar el escalado automático y dividir todos los subprocesos en escalabilidad automática en componentes independientes. Estos comandos se basan en las variables de entorno GridEngine que se deben establecer: debe poder llamar a qconf y a qsub desde el mismo perfil donde se llama a azge.

Al modificar las configuraciones del programador (qconf) o las configuraciones de escalado automático (autoscale.json), o incluso configurar por primera vez, se puede usar azge para comprobar que el comportamiento de escalabilidad automática coincide con las expectativas. Como raíz, puede ejecutar las siguientes operaciones. Para comprender cómo funciona el escalado automático, es importante familiarizarse con estos conceptos.

1. Ejecute azge validate para comprobar las configuraciones de los problemas conocidos.
2. Ejecute azge buckets para comprobar los recursos que ofrece el clúster de CycleCloud.
3. Ejecute azge jobs para inspeccionar los detalles del trabajo en cola.
4. Ejecutar azge demand realiza el trabajo de emparejar cubos. A continuación, examine qué trabajos coinciden con cuáles cubos y grupos host.
5. Ejecute azge autoscale para iniciar el proceso de asignación de nodos o agregar nodos que estén listos para unirse.

Una vez que los comandos funcionen según lo previsto, habilite el escalado automático en curso agregando el azge autoscale comando a la tabla crontab raíz. Asegúrese de obtener de antemano 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 admite el escenario de expansión de 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 = false, gridengine.shared.bin = falsee instalando GridEngine localmente.

Para un caso sencillo, debe proporcionar un sistema de archivos que los nodos ejecutores puedan montar. Este sistema de archivos debe incluir ... directorio y se configura el montaje en las opciones opcionales. Cuando se liberan las dependencias de los directorios sched y compartidos, puede apagar el nodo del planificador que forma parte del clúster por defecto y usar las configuraciones del sistema de archivos externo.

1. Cree un nuevo clúster Grid Engine.
2. Desactiva el proxy de retorno.
3. Reemplace /sched y /shared por sistemas de archivos externos.
4. Salve el clúster.
5. Quite el nodo del programador como una acción en la interfaz de usuario.
6. Inicie el clúster; inicialmente no se inicia ningún nodo.
7. Configura 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 usa la versión 8.6.1-demo, pero se admiten todas las versiones de GE superiores a la 8.4.0.

1. Los usuarios deben proporcionar archivos binarios de UGE

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

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

Copia de los archivos binarios en el almacén de 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 las 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 [[[configuration]]] e inserte texto para que coincida con el siguiente fragmento de código. El archivo no es sensible a la sangría.

[[[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 de GridEngine invalidan la versión predeterminada de GridEngine y la ubicación de instalación cuando se inicia el clúster. No es seguro cambiar de /sched, ya que es una ubicación NFS compartida en el clúster.