CycleCloud GridEngine Cluster

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.

Descripción	Location
Configuración de escalado automático	/opt/cycle/gridengine/autoscale.json
Registro de escalado automático	/opt/cycle/jetpack/logs/autoscale.log
Registro de seguimiento de qconf	/opt/cycle/jetpack/logs/qcmd.log

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

Configuración	Tipo	Descripción
url	String	CC URL
nombre de usuario y contraseña	String	Detalles de conexión cc
cluster_name	String	Nombre del clúster cc
default_resources	Asignación	Vinculación de un recurso de nodo a un recurso host del motor de cuadrícula para el escalado automático
idle_timeout	Int	Tiempo de espera antes de terminar los nodos inactivos (s)
boot_timeout	Int	Tiempo de espera antes de terminar los nodos durante las fases de configuración largas (s)
gridengine.relevant_complexes	List (String)	Los complejos del motor de cuadrícula que se deben tener en cuenta en el escalado automático, por ejemplo, ranuras, mem_free
gridengine.logging	Archivo	Ubicación del archivo de configuración de registro
gridengine.pes	Estructura	Especificar el comportamiento de los IDE, por ejemplo , requires_placement_group = false

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.

Nodo	Tipo	Descripción
nodearray	String	Nombre de cyclecloud nodearray
placement_group	String	Nombre del grupo de selección de ubicación cyclecloud dentro de un elemento nodearray
vm_size	String	Nombre del producto de máquina virtual, por ejemplo, "Standard_F2s_v2"
vcpu_count	Int	CPU virtuales disponibles en el nodo, tal como se indica en páginas de productos individuales
pcpu_count	Int	CPU físicas disponibles en el nodo
memoria	String	Memoria física aproximada disponible en la máquina virtual con indicador de unidad, por ejemplo, "8,0g"

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

Nodo	Tipo	Descripción
ncpus	String	Número de CPU disponibles en la máquina virtual
pcpus	String	Número de CPU físicas disponibles en la máquina virtual
ngpus	Entero	Número de GPU disponibles en la máquina virtual
memb	String	Memoria física aproximada disponible en la máquina virtual con indicador de unidad, por ejemplo, "8,0b"
memkb	String	Memoria física aproximada disponible en la máquina virtual con indicador de unidad, por ejemplo, "8,0k"
memmb	String	Memoria física aproximada disponible en la máquina virtual con indicador de unidad, por ejemplo, "8,0m"
memgb	String	Memoria física aproximada disponible en la máquina virtual con indicador de unidad, por ejemplo, "8,0g"
memtb	String	Memoria física aproximada disponible en la máquina virtual con indicador de unidad, por ejemplo, "8.0t"
slots	Entero	Igual que ncpus
slot_type	String	Etiqueta de adición para extensiones. Por lo general, no se usa.
m_mem_free	String	Memoria libre esperada en el host de ejecución, por ejemplo, "3.0g"
mfree	String	Igual que _m/_mem/gratis

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.

comandos azge	Descripción
validate	Comprueba si hay errores de configuración conocidos en el escalador automático o gridengine.
jobs	Muestra todos los trabajos de la cola
cubos	Muestra los grupos de recursos disponibles para el escalado automático
nodes	Muestra las propiedades y los hosts del clúster
Demanda	Coincide con los requisitos de trabajo para los cubos cyclecloud y proporciona el resultado de escalado automático.
autoscale	Realiza el escalado automático completo, iniciando y quitando nodos según las configuraciones.

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.