CycleCloud GridEngine Cluster

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

Configurando recursos

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

Instalando ou atualizando cyclecloud-gridengine

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

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

Arquivos importantes

O aplicativo analisa a configuração de sge sempre que é chamado – trabalhos, filas, complexos. As informações são fornecidas no stderr e stdout do comando, bem como em um arquivo de log, ambos em níveis configuráveis. Todos os comandos de gerenciamento de gridengine com argumentos também são registrados no arquivo.

Descrição	Location
Configuração de dimensionamento automático	/opt/cycle/gridengine/autoscale.json
Log de dimensionamento automático	/opt/cycle/jetpack/logs/autoscale.log
log de rastreamento qconf	/opt/cycle/jetpack/logs/qcmd.log

Filas SGE, grupos de host e ambientes paralelos

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

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

Considere a definição de fila a seguir 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]

O envio de um trabalho por qsub -q short.q -pe mpi02 12 my-script.sh começará na concessão de uma VM e, quando ele for adicionado ao cluster, ele ingressará no grupo de hosts @mpihg02 porque esse é o grupo de hosts disponível para a fila e para o ambiente paralelo. Ele também será adicionado ao @allhosts, que é um grupo de host especial.

Sem especificar um pe, qsub -q short.q my-script.sh a VM resultante será adicionada a @allhosts e @lowpriority esses são os grupos de host na fila que não são atribuídos pes.

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

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

Aqui, recusamos os grupos de posicionamento para o make pe:

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

Grupos de posicionamento do CycleCloud

Os grupos de posicionamento do CycleCloud mapeiam um para um para o VMSS do Azure com SinglePlacementGroup – as VMs em um grupo de posicionamento compartilham uma Malha Infiniband e compartilham apenas com VMs dentro do grupo de posicionamento. Para preservar intuitivamente esses silos, os grupos de posicionamento também mapeiam 1:1 com o ambiente paralelo gridengine.

Especificar um ambiente paralelo para um trabalho restringirá o trabalho a ser executado em um grupo de posicionamento por meio da lógica de atribuição de grupo de host inteligente. Você pode recusar esse comportamento com a configuração mencionada anteriormente em autoscale.json : "required_placement_groups" : false.

Configuração de dimensionamento automático

Esse plug-in dimensionará automaticamente a grade para atender às demandas da carga de trabalho. O arquivo de configuração autoscale.json determina o comportamento do dimensionador automático do Mecanismo de Grade.

• Definir os detalhes da conexão do cyclecloud
• Definir o temporizador de término para nós ociosos
• O dimensionamento automático multidimensional é possível, defina quais atributos usar no empacotamento de trabalho, por exemplo, slots, memória
• Registrar as filas, os ambientes paralelos e os grupos de host a serem gerenciados

Configuração	Tipo	Descrição
url	String	CC URL
nome de usuário/senha	String	Detalhes da conexão CC
cluster_name	String	Nome do cluster CC
default_resources	Mapeamento	Vincular um recurso de nó a um recurso de host do Mecanismo de Grade para dimensionamento automático
idle_timeout	int	Tempo de espera antes de encerrar nós ociosos (s)
boot_timeout	int	Tempo de espera antes de encerrar nós durante longas fases de configuração (s)
gridengine.relevant_complexes	Lista (cadeia de caracteres)	Complexos do mecanismo de grade a serem considerados no dimensionamento automático, por exemplo, slots mem_free
gridengine.logging	Arquivo	Local do arquivo de configuração de log
gridengine.pes	Estrutura	Especificar o comportamento de PEs, por exemplo , requires_placement_group = false

O programa de dimensionamento automático considerará apenas o Recurso Relevante

Recurso de dimensionamento automático adicional

Por padrão, o cluster com escala com base em quantos slots são solicitados pelos trabalhos. Podemos adicionar outra dimensão ao dimensionamento automático.

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

1. Adicionar m_mem_free ao gridengine.relevant_resources em autoscale.json
2. Link m_mem_free para o recurso de memória no nível do nó em autoscale.json

Esses atributos podem ser referências com node.* como o valor em _default/resources.

Nó	Tipo	Descrição
nodearray	String	Nome da nodearray cyclecloud
placement_group	String	Nome do grupo de posicionamento cyclecloud em uma nodearray
vm_size	String	Nome do produto da VM, por exemplo, "Standard_F2s_v2"
vcpu_count	int	CPUs virtuais disponíveis no nó, conforme indicado em páginas de produtos individuais
pcpu_count	int	CPUs físicas disponíveis no nó
memória	String	Memória física aproximada disponível na VM com indicador de unidade, por exemplo, "8,0g"

Atributos adicionais estão no node.resources.* namespace, por exemplo, 'node.resources.

Nó	Tipo	Descrição
ncpus	String	Número de CPUs disponíveis na VM
pcpus	String	Número de CPUs físicas disponíveis na VM
ngpus	Integer	Número de GPUs disponíveis na VM
memb	String	Memória física aproximada disponível na VM com indicador de unidade, por exemplo, "8,0b"
memkb	String	Memória física aproximada disponível na VM com indicador de unidade, por exemplo, "8,0k"
memmb	String	Memória física aproximada disponível na VM com indicador de unidade, por exemplo, "8,0m"
memgb	String	Memória física aproximada disponível na VM com indicador de unidade, por exemplo, "8,0g"
memtb	String	Memória física aproximada disponível na VM com indicador de unidade, por exemplo, "8,0t"
slots	Integer	O mesmo que ncpus
slot_type	String	Rótulo de adição para extensões. Geralmente não usado.
m_mem_free	String	Memória livre esperada no host de execução, por exemplo, "3,0g"
mfree	String	O mesmo que _m/_mem/free

Mapeamento de recursos

Também há matemática disponível para o default_resources – reduza os slots em uma matriz de nós específica em dois e adicione o recurso docker a todos os nós:

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

Mapear os vCPUs do nó para os slots complexos e memmb para mem_free são padrões comumente usados. A primeira associação é necessária.

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

Observe que, se um complexo tiver um atalho não igual ao valor inteiro, defina ambos em default_resources em que physical_cpu é o nome complexo:

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

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

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

Grupos de host

O dimensionador automático do CycleCloud, ao tentar atender aos requisitos de trabalho, mapeará nós para o grupo de host apropriado. Filas, ambientes paralelos e complexos são considerados. Grande parte da lógica corresponde ao bucket de nuvem de ciclo apropriado (e à quantidade de nós) com o grupo de host sge apropriado.

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

O CycleCloud encontrará a interseção de grupos de host 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. Tenha recursos adequados e cota de assinatura para fornecer todos os recursos de trabalho.
3. Não são filtrados pela configuração de restrições do grupo de host.

É possível que vários grupos de host atendam a esses requisitos, nesse caso, a lógica precisará escolher. Há três maneiras de resolver ambiguidades na associação do grupo de host:

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

Restrições do grupo de host

Quando vários grupos de host são definidos por uma fila ou xproject, todos esses grupos de host podem potencialmente ter os hosts adicionados a eles. Você pode limitar quais tipos de hosts podem ser adicionados a quais filas definindo restrições de grupo de host. Defina 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 de nó disponíveis por azge buckets.

azge

Esse pacote vem com uma linha de comando, azge. Esse programa deve ser usado para executar o dimensionamento automático e desfou todos os subprocessos em dimensionamento automático. Esses comandos dependem das variáveis de ambiente gridengine a serem definidas– você deve ser capaz de chamar qconf e qsub do mesmo perfil em que azge é chamado.

comandos azge	Descrição
validade	Verifica se há erros de configuração conhecidos no dimensionador automático ou gridengine
jobs	Mostra todos os trabalhos na fila
buckets	Mostra os pools de recursos disponíveis para dimensionamento automático
nós	Mostra hosts e propriedades do cluster
demanda	Corresponde aos requisitos de trabalho para buckets de nuvem de ciclo e fornece o resultado do dimensionamento automático
dimensionamento automático	Faz dimensionamento automático completo, iniciando e removendo nós de acordo com as configurações

Ao modificar configurações do agendador (qconf) ou configurações de dimensionamento automático (autoscale.json) ou até mesmo configurar pela primeira vez, o azge pode ser usado para verificar se o comportamento de dimensionamento automático corresponde às expectativas. Como raiz, você pode executar as operações a seguir. É aconselhável familiarizá-los para entender o comportamento de dimensionamento automático.

1. Execute azge validate para verificar as configurações de problemas conhecidos.
2. Execute azge buckets para examinar quais recursos seu cluster CycleCloud está oferecendo.
3. Execute azge jobs para inspecionar os detalhes do trabalho na fila.
4. Execute azge demand executar o trabalho para correspondência de bucket, examine quais trabalhos são correspondidos a quais buckets e grupos de host.
5. Execute azge autoscale para iniciar o processo de alocação de nó ou adicione nós que estão prontos para ingressar.

Em seguida, quando esses comandos estiverem se comportando conforme o esperado, habilite o dimensionamento automático contínuo adicionando o azge autoscale comando ao crontab raiz. (Souce as variáveis de ambiente gridengine)

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

Criando um cluster híbrido

O CycleCloud dará suporte ao cenário de intermitência na nuvem. A configuração base pressupõe que o $SGE_ROOT diretório esteja disponível para os nós de nuvem. Essa suposição pode ser relaxada definindo gridengine.shared.spool = falsee gridengine.shared.bin = false instalando GridEngine localmente. Para um caso simples, você deve fornecer um sistema de arquivos que pode ser montado pelos nós de execução que contém o $SGE_ROOT diretório e configurar essa montagem nas configurações opcionais. Quando a dependência dos diretórios sched e shared for lançada, você poderá desligar o nó do agendador que faz parte do cluster por padrão e usar as configurações do sistema de arquivos externo.

1. Crie um novo cluster gridengine.
2. Desabilitar o proxy de retorno.
3. Substitua /sched e /shared por sistemas de arquivos externos.
4. Salve o cluster.
5. Remova o nó do agendador como uma ação na interface do usuário.
6. Inicie o cluster, os nós serão iniciados inicialmente.
7. cyclecloud-gridengine Configurar com autoscale.json para usar o novo cluster

Usando o Mecanismo de Grade univa no CycleCloud

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

Pré-requisitos

Este exemplo usará a versão de demonstração 8.6.1, mas todas as versões > ge 8.4.0 têm suporte.

1. Os usuários devem fornecer binários UGE

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

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

Copiar os binários para o cofre de nuvem

Uma versão complementar da AGE (8.6.7-demo) é distribuída com o CycleCloud. Para usar outra versão, carregue os binários na conta de armazenamento que o CycleCloud usa.

$ azcopy cp ge-8.6.12-bin-lx-amd64.tar.gz https://<storage-account-name>.blob.core.windows.net/cyclecloud/gridengine/blobs/
$ azcopy cp ge-8.6.12-common.tar.gz https://<storage-account-name>.blob.core.windows.net/cyclecloud/gridengine/blobs/

Modificando configurações para o modelo de cluster

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

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

No arquivo gridengine.txt , localize a primeira ocorrência de e insira texto de [[[configuration]]] modo que corresponda ao snippet abaixo. Esse arquivo não é sensível ao recuo.

OBSERVAÇÃO: os detalhes na configuração, especialmente a versão, devem corresponder ao nome do arquivo 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"

Essas configurações substituirão a versão padrão do gridengine e o local de instalação quando o cluster for iniciado. Não é seguro sair do /sched , pois é um local nfs compartilhado especificamente no cluster.