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 relaciona os recursos do SGE aos recursos de nuvem do Azure para fornecer ferramentas avançadas de configuração de cluster e dimensionamento automático. O aplicativo é implantado automaticamente para clusters criados por meio da interface do usuário do CycleCloud ou pode ser instalado em qualquer host de administrador de 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 seguem 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 é executado – trabalhos, filas, complexos. As informações são fornecidas no stderr e stdout do comando e 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	Localização
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, azge, cyclecloud-gridengine adiciona 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. Ler a solicitação de recurso de trabalho e encontrar 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 e a qualquer outra fila que contenha o grupo de host

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]

O envio de um trabalho por qsub -q short.q -pe mpi02 12 my-script.sh inicia pelo menos uma VM. Quando o cluster é adicionado, ele se une ao grupo de anfitriões @mpihg02, pois esse é o grupo de anfitriões disponível tanto para a fila quanto para o ambiente paralelo. Ele também une @allhosts, um grupo de host especial.

Se você enviar um trabalho com qsub -q short.q my-script.sh e não especificar um ambiente paralelo pe, a VM resultante ingressará no @allhosts e @lowpriority grupos de host vinculados à fila que não está atribuída a nenhum pes.

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

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

Aqui, recusamos 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 um Infiniband Fabric 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 de gridengine.

Especificar um ambiente paralelo para um trabalho restringe a execução do trabalho em um grupo de posicionamento por meio da lógica de atribuição de grupo de host inteligente. Você pode desabilitar esse comportamento por meio da configuração correspondente em autoscale.json: "required_placement_groups" : false.

Configuração de dimensionamento automático

Esse plug-in dimensiona automaticamente a grade para atender às demandas da carga de trabalho. O arquivo de configuração autoscale.json determina o comportamento do autoscaler do Grid Engine.

• Definir os detalhes da conexão do cyclecloud
• Definir o temporizador de terminação 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	fio	CC URL
nome de usuário/senha	fio	Detalhes da conexão CC
nome_do_cluster	fio	Nome do cluster CC
recursos_padrão	Mapa	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 fases de configuração longas (s)
gridengine.relevant_complexes	Lista (Cadeia)	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 considera apenas o Recurso Relevante

Outro recurso de dimensionamento automático

Por padrão, os trabalhos solicitam muitos slots e o cluster é dimensionado com base nessas solicitações.

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

1. Adicionar m_mem_free ao gridengine.relevant_resourcesautoscale.json
2. Vincular m_mem_free ao recurso de memória no nível do nó no autoscale.json

Esses atributos podem ser referenciados com node.* como o valor em _default/recursos.

Nó	Tipo	Descrição
nodearray	fio	Nome da nodearray do cyclecloud
placement_group	fio	Nome do grupo de posicionamento do cyclecloud em um nodearray
vm_size	fio	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	fio	Memória física aproximada disponível na VM com indicador de unidade, por exemplo, "8,0g"

Outros atributos estão no node.resources.* namespace, por exemplo, 'node.resources.

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

Mapeamento de recursos

Também há matemática disponível para o default_resources – reduza os slots em uma matriz de nó específica em dois e adicione o recurso do 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
    },

O mapeamento das vCPUs do nó para os slots é complexo, e memmb a mem_free são padrões comumente usados. A primeira associação é obrigatória.

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

Se um complexo tiver um atalho que não seja igual ao valor inteiro, defina ambos 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 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 os requisitos de trabalho, mapeia os nós para o grupo de hospedagem apropriado. Filas, ambientes paralelos e complexos são considerados. Grande parte da lógica está correspondendo ao bucket de nuvem de ciclo apropriado (e quantidade de nó) 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 localiza obter a interseção de grupos de host que:

1. Sã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. A configuração de restrições do grupo de host não as filtra.

Vários grupos de host podem atender a esses requisitos. Quando isso acontece, o sistema deve decidir qual deles usar. Há três maneiras de resolver conflitos de associação do grupo de host:

1. Configure as filas para evitar ambiguidades.
2. Adicionar restrições a autoscale.json.
3. Permita que o CycleCloud escolha os grupos de host correspondentes de forma ordenada por nome ajustando 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 de grupo de host

Quando uma fila ou xproject define vários grupos de host, qualquer um desses grupos pode receber novos hosts. Para controlar quais hosts são qualificados para quais filas, você pode aplicar restrições de grupo de host 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. Este programa é usado para executar o dimensionamento automático e interrompe todos os subprocessos em dimensionamento automático em componentes separados. Esses comandos dependem das variáveis de ambiente de gridengine a serem definidas– você deve ser capaz de chamar qconf e qsub do mesmo perfil em que azge é chamado.

comandos azge	Descrição
validar	Verifica se há erros de configuração conhecidos no escalador automático ou no GridEngine
Empregos	Mostra todos os trabalhos na fila
Baldes	Mostra os pools de recursos disponíveis para dimensionamento automático
Nós	Mostra os hosts e propriedades do cluster
demanda	Alinha os requisitos de trabalho aos buckets do CycleCloud e fornece o resultado do dimensionamento automático
escalonamento 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 usuário root, você pode executar as seguintes operações. Para entender como o dimensionamento automático funciona, é importante se familiarizar com esses conceitos.

1. Execute azge validate para verificar as configurações de problemas conhecidos.
2. Execute azge buckets para verificar os recursos oferecidos pelo cluster CycleCloud.
3. Execute azge jobs para inspecionar os detalhes do trabalho na fila.
4. Execute azge demand o trabalho para correspondência de bucket. Em seguida, 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.

Depois que os comandos estiverem funcionando conforme o esperado, habilite o dimensionamento automático contínuo adicionando o azge autoscale comando ao crontab raiz. Certifique-se de obter as variáveis de ambiente de gridengine com antecedência.

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

Criando um cluster híbrido

O CycleCloud dá suporte ao cenário de intermitência de nuvem. A configuração base pressupõe que o $SGE_ROOT diretório está disponível para os nós de nuvem. Essa suposição pode ser relaxada definindo gridengine.shared.spool = falsegridengine.shared.bin = falsee instalando o GridEngine localmente.

Para um caso simples, você deve fornecer um sistema de arquivos que os nós de execução possam montar. Esse sistema de arquivos deve incluir o... e você configura a montagem nas configurações opcionais. Quando as dependências dos diretórios sched e compartilhado são liberadas, você pode 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 de gridengine.
2. Desabilite 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. Inicialmente, inicie o cluster, sem nós.
7. Configurar cyclecloud-gridengine com autoscale.json para usar o novo cluster

Usando o Univa Grid Engine no CycleCloud

O projeto CycleCloud para GridEngine usa sge-2011.11 por padrão. Você pode usar seus próprios instaladores do 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 usa 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 os binários do 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 do 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 no modelo de cluster

Faça uma cópia local do modelo de 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 [[[configuration]]] e insira um texto que corresponda ao trecho a seguir. O arquivo não é sensível à indentação.

Observação

Os detalhes na configuração, particularmente 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 de gridengine substituem a versão padrão do gridengine e o local de instalação quando o cluster é iniciado. Não é seguro sair de /sched, pois ele é um local nfs compartilhado no cluster.