Cluster de GridEngine de cicloCloud

Esta página diz respeito às capacidades e configuração da utilização (Altair) GridEngine com CycleCloud.

Configurar recursos

A aplicação de motor de rede de ciclocloud combina recursos de sge para obter recursos em nuvem azul para fornecer ferramentas de autoscalagem e configuração de clusters ricas. A aplicação será implementada automaticamente para clusters criados através do CycleCloud UI ou pode ser instalada em qualquer anfitrião de administração de engenharia de grelhas num cluster existente.

Instalação ou modernização do ciclocloud-grideng

O pacote de motor de rede de ciclocloud está disponível no github como um artefacto de libertação. A instalação e a atualização serão o mesmo processo. A aplicação requer python3 com virtualenv.

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

Ficheiros Importantes

A aplicação analisa a configuração do sge cada vez que é chamada - empregos, filas, complexos. A informação é fornecida no stderr e no stdout do comando, bem como num ficheiro de registo, ambos a níveis configuráveis. Todos os comandos de gestão de motor de grelha com argumentos também são registados para arquivar.

Description	Localização
Config de autoescala	/opt/cycle/gridengine/autoscale.json
Registo de escala automática	/opt/cycle/jetpack/logs/autoscale.log
registo de vestígios qconf	/opt/cycle/jetpack/logs/qcmd.log

Filas SGE, grupos de anfitriões e ambientes paralelos

O utilitário de autoescalação de rede de ciclocloud, azgeirá adicionar hospedeiros ao cluster de acordo com a configuração do cluster. As operações de autoescalagem realizam as seguintes ações.

1. Leia o pedido de recursos de trabalho e encontre um VM apropriado para começar
2. Inicie o VM e espere que esteja pronto.
3. Leia a fila e o ambiente paralelo do trabalho
4. Com base na fila/pe atribua o anfitrião a um grupo de anfitriões apropriado
5. Adicione o anfitrião ao cluster, bem como a qualquer outra fila que contenha o grupo anfitrião

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]

A submissão de um trabalho começará por qsub -q short.q -pe mpi02 12 my-script.sh arrendar um VM, e quando for adicionado ao cluster, juntar-se-á ao grupo de anfitriões @mpihg02 porque esse é o grupo de anfitriões disponível tanto para a fila como para o ambiente paralelo. Será também adicionado à @allhosts, que é um grupo especial de anfitriões.

Sem especificar um pe, qsub -q short.q my-script.sh o VM resultante será adicionado a @allhosts e @lowpriority estes são os grupos anfitriões na fila que não são atribuídos pes.

Finalmente, um trabalho submetido resultará qsub -q short.q -pe mpi0* 12 my-script.sh num VM adicionado a @mpihg01 ou @mpihg02 dependendo das previsões de atribuição do CycleCloud.

Ambientes paralelos equivalem implicitamente ao grupo de colocação de nuvens de ciclo. Os VMs num PE estão limitados a estar dentro da mesma rede. Se desejar utilizar um PE que não mantenha um grupo de colocação, use o autoscale.json para excluir.

Aqui optamos por não fazer grupos de colocação para a make pe:

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

Grupos de colocação de CycleCloud

Os grupos de colocação CycleCloud mapeiam um a um para o Azure VMSS com singlePlacementGroup - VMs em um grupo de colocação compartilham um Tecido Infiniband e partilham apenas com VMs dentro do grupo de colocação. Para preservar intuitivamente estes silos, os grupos de colocação mapeiam 1:1 com ambiente paralelo de gridengine também.

Especificar um ambiente paralelo para um trabalho irá restringir o trabalho a funcionar em um grupo de colocação através de uma lógica de atribuição de grupos de anfitriões inteligentes. Pode optar por não fazer este comportamento com a configuração acima referida em autoscale.json : "required_placement_groups" : false.

Config de escala automática

Este plugin irá escalar automaticamente a grelha para satisfazer as exigências da carga de trabalho. O ficheiro autoscale.json config determina o comportamento do autoescalador do motor de grelha.

• Desaprovo os detalhes da ligação cyclecloud
• Desave o temporizador de terminação para os nosdes inativos
• Autoscalagem multidimensional é possível, definir quais atributos a usar na embalagem de trabalho, por exemplo, ranhuras, memória
• Registar as filas, ambientes paralelos e grupos de acolhimento a gerir

Configuração	Tipo	Description
url	String	CC URL
nome/senha de utilizador	String	Detalhes da conexão CC
cluster_name	String	Nome do cluster CC
default_resources	Mapa	Ligue um recurso de nó a um recurso de anfitrião do Motor grid para autoescalação
idle_timeout	int	Tempo de espera antes de terminar os nós ociosos (s)
boot_timeout	int	Tempo de espera antes de terminar os nomes durante as fases de configuração longa (s)
gridengine.relevant_complexes	Lista (Corda)	Complexos de motores de rede a ter em conta na autoscalagem, por exemplo, slots, mem_free
gridengine.logging	Ficheiro	Localização do ficheiro config de registo
gridengine.pes	Estrutura	Especificar o comportamento de PEs, por exemplo requires_placement_group = falso

O programa de autoscalagem só considerará o Recurso Relevante

Recurso de autoescalação adicional

Por defeito, o cluster com escala com base em quantas vagas são solicitadas pelos postos de trabalho. Podemos adicionar outra dimensão ao autoescaling.

Digamos que queremos fazer uma escala automática através do pedido de recursos de trabalho para m_mem_free.

1. Adicione m_mem_free ao gridengine.relevant_resources in autoscale.json
2. Ligação m_mem_free ao recurso de memória de nível de nó em autoscale.json

Estes atributos podem ser referências node.* com o valor em _default/recursos.

Nó	Tipo	Description
nodearray	String	Nome do nódedeso de ciclocloud
placement_group	String	Nome do grupo de colocação de ciclovias dentro de um nodearray
vm_size	String	Nome do produto VM, por exemplo , "Standard_F2s_v2"
vcpu_count	int	CPUs virtuais disponíveis no nó conforme indicado nas páginas individuais do produto
pcpu_count	int	CPUs físicos disponíveis no nó
Memória	String	Memória física aproximada disponível no VM com indicador de unidade, por exemplo " 8,0g"

Atributos adicionais estão no espaço de node.resources.* nome, por exemplo'node.resources.

Nó	Tipo	Description
ncpus	String	Número de CPUs disponíveis no VM
pcp	String	Número de CPUs físicos disponíveis no VM
ngpus	Número inteiro	Número de GPUs disponíveis no VM
memb	String	Memória física aproximada disponível no VM com indicador de unidade, por exemplo " 8.0b"
memkb	String	Memória física aproximada disponível no VM com indicador de unidade, por exemplo " 8.0k"
memmb	String	Memória física aproximada disponível no VM com indicador de unidade, por exemplo " 8,0m"
memgb	String	Memória física aproximada disponível no VM com indicador de unidade, por exemplo " 8,0g"
memtb	String	Memória física aproximada disponível no VM com indicador de unidade, por exemplo " 8.0t"
slots	Número inteiro	O mesmo que o ncpus
slot_type	String	Etiqueta de adição para extensões. Geralmente não é usado.
m_mem_free	String	Memória livre esperada no anfitrião da execução, por exemplo, "3.0g"
mfree	String	O mesmo que _m/_mem/grátis

Mapeamento de recursos

Existem também matemática disponíveis para o default_resources - reduza as ranhuras num conjunto de nó particulares por dois e adicione o recurso estivador 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 o complexo de ranhuras, e memmb para mem_free serem normalmente usados predefinições. A primeira associação é necessária.

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

Note que se um complexo tem um atalho não igual a todo o valor, então defina tanto 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 encomenda é importante quando se quer um comportamento específico para um atributo específico. Para atribuir uma única ranhura para um nódarray específico, mantendo a contagem de slots predefinidos para todos os outros nólarrays:

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

Grupos de anfitriões

O autoescala CycleCloud, na tentativa de satisfazer os requisitos de trabalho, mapeará os nós para o grupo de anfitriões apropriado. São consideradas filas, ambientes paralelos e complexos. Grande parte da lógica está a combinar o balde de nuvens de ciclo apropriado (e quantidade de nó) com o grupo de anfitriões de sge apropriado.

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

CycleCloud encontrará a intersecção de grupos de anfitriões 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. Dispor de recursos adequados e quota de subscrição para fornecer todos os recursos de trabalho.
3. Não são filtrados pela configuração de restrições do grupo anfitrião.

É possível que vários grupos de anfitriões cumpram estes requisitos, caso em que a lógica terá de escolher. Existem três formas de resolver ambiguidades na adesão ao grupo de acolhimento:

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

Restrições do grupo anfitrião

Quando vários grupos de anfitriões são definidos por uma fila ou xproject, todos estes grupos de anfitriões podem potencialmente ter os anfitriões adicionados a eles. Pode limitar que tipo de anfitriões podem ser adicionados às filas, definindo as restrições do grupo anfitrião. Desenteie 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 do nó disponível por azge buckets.

azge

Este pacote vem com uma linha de comando, azge. Este programa deve ser utilizado para realizar autoscaling e descodificou todos os subprocessos em autoescalação. Estes comandos dependem das variáveis do ambiente de motor de grelha a definir - você deve ser capaz de ligar qconf e qsub do mesmo perfil onde azge é chamado.

comandos azge	Description
validar	Verificações de erros de configuração conhecidos no autoescalador ou no motor de grelha
empregos	Mostra todos os empregos na fila
baldes	Mostra piscinas de recursos disponíveis para autoscaling
osdes	Mostra anfitriões e propriedades de cluster
procura	Corresponde aos requisitos de trabalho para baldes de ciclocloud e fornece resultados de autoescala
dimensionamento automático	Faz autoescalação completa, iniciando e removendo os nódes de acordo com as configurações

Ao modificar configurações de programadores (qconf) ou configurações de autoescala (autoscale.json), ou mesmo a configuração pela primeira vez, o azge pode ser usado para verificar se o comportamento de autoescalação corresponde às expectões correspondentes. Como raiz, pode executar as seguintes operações. É aconselhável familiarizarmo-nos com isto para compreender o comportamento da autoescala.

1. Corra azge validate para verificar configurações para problemas conhecidos.
2. Corra azge buckets para examinar os recursos que o seu cluster CycleCloud está a oferecer.
3. Corra azge jobs para inspecionar os detalhes do trabalho em fila.
4. Executar azge demand o trabalho para combinar balde, examinar quais os trabalhos que são combinados com os baldes e grupos de anfitriões.
5. Corra azge autoscale para iniciar o processo de atribuição do nó, ou adicione nós prontos para aderir.

Em seguida, quando estes comandos se comportarem como esperado, ative a autoescala contínua adicionando o azge autoscale comando ao crontab raiz. (Souce as variáveis do ambiente do motor da grelha)

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

Criar um cluster híbrido

O CycleCloud irá suportar o cenário de explosão na nuvem. A configuração base pressupõe que o $SGE_ROOT diretório está disponível para os nós de nuvem. Esta suposição pode ser descontraída definindo gridengine.shared.spool = false, gridengine.shared.bin = false e instalando gridengine localmente. Para um caso simples, deve fornecer um sistema de ficheiros que pode ser montado pelos nós de execução que contém o $SGE_ROOT diretório e configuração que montam nas definições opcionais. Quando a dependência dos diretórios sched e partilhados for lançada, pode desligar o nó do programador que faz parte do cluster por padrão e utilizar as configurações do sistema de ficheiros externo.

1. Criar um novo cluster de motor de grelha.
2. Desative o representante de devolução.
3. Substitua/sched e/partilhado por sistemas de ficheiros externos.
4. Salve o aglomerado.
5. Remova o nó do agendador como uma ação na UI.
6. Inicie o cluster, nenhum nós começará inicialmente.
7. Configure cyclecloud-gridengine com autoscale.json para usar o novo cluster

Usando o motor da grelha Univa em CycleCloud

O projeto CycleCloud para GridEngine utiliza sge-2011.11 por predefinição. Pode utilizar os seus próprios instaladores Altair GridEngine de acordo com o seu contrato de licença Altair.
Esta secção documenta como utilizar o Altair GridEngine com o projeto CycleCloud GridEngine.

Pré-requisitos

Este exemplo irá utilizar a versão 8.6.1-demo, mas todas as versões > ge 8.4.0 são suportadas.

1. Os utilizadores devem fornecer binários UGE

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

2. O CicloCloud CLI deve estar configurado. A documentação está disponível aqui

Copie os binários para o armário da nuvem

Uma versão complementar da AGE (8.6.7-demo) é distribuída com CycleCloud. Para utilizar outra versão, faça o upload dos binários para a conta de armazenamento que o CycleCloud utiliza.

$ 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/

Modificar configs para o modelo de cluster

Faça uma cópia local do modelo de motor de grelha e modifique-o para utilizar os instaladores UGE em vez do padrão.

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

No ficheiro gridengine.txt , localize a primeira ocorrência e insira o texto de [[[configuration]]] modo a corresponder ao corte abaixo. Este ficheiro não é sensível ao entalhe.

NOTA: Os detalhes na configuração, particularmente a versão, devem coincidir com o nome do ficheiro 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"

Estes configs irão sobrepor-se à versão padrão do motor de grelha e à localização de instalação quando o cluster começar. Não é seguro sair do /sched agrupamento, uma vez que é uma localização de nfs especificamente partilhada no aglomerado.