CycleCloud Slurm 3.0
O suporte do Slurm Scheduler foi reescrito como parte do lançamento do CycleCloud 8.4.0. As principais funcionalidades incluem:
- Suporte para nós dinâmicos e partições dinâmicas através de nodearays dinâmicos, suportando tamanhos de VM única e múltipla
- Novas versões do slurm 23.02 e 22.05.8
- Relatório de custos através da
azslurm
CLI -
azslurm
Dimensionador automático baseado na CLI - Suporte do Ubuntu 20
- Foi removida a necessidade do plug-in de topologia e, portanto, também de qualquer plug-in de submissão
Clusters Slurm nas versões < 8.4.0 do CycleCloud
Para obter mais informações, consulte Transição da versão 2.7 para a 3.0 .
Fazer Alterações ao Cluster
O cluster Slurm implementado no CycleCloud contém uma cli chamada azslurm
para facilitar as alterações ao cluster. Depois de efetuar alterações ao cluster, execute o seguinte comando como raiz no nó Slurm scheduler para reconstruir o azure.conf
e atualizar os nós no cluster:
$ sudo -i
# azslurm scale
Esta ação deve criar as partições com o número correto de nós, o correto gres.conf
e reiniciar o slurmctld
.
Deixar de criar previamente nós de execução
A partir da versão 3.0.0 do projeto CycleCloud Slurm, já não estamos a pré-criar os nós no CycleCloud. Os nós são criados quando azslurm resume
são invocados ou criando-os manualmente no CycleCloud através da CLI.
Criar partições adicionais
O modelo predefinido que é fornecido com o Azure CycleCloud tem três partições (hpc
htc
e dynamic
), e pode definir nós personalizados que mapeiam diretamente para partições Slurm. Por exemplo, para criar uma partição de GPU, adicione a secção seguinte ao modelo de cluster:
[[nodearray gpu]]
MachineType = $GPUMachineType
ImageName = $GPUImageName
MaxCoreCount = $MaxGPUExecuteCoreCount
Interruptible = $GPUUseLowPrio
AdditionalClusterInitSpecs = $ExecuteClusterInitSpecs
[[[configuration]]]
slurm.autoscale = true
# Set to true if nodes are used for tightly-coupled multi-node jobs
slurm.hpc = false
[[[cluster-init cyclecloud/slurm:execute:3.0.1]]]
[[[network-interface eth0]]]
AssociatePublicIpAddress = $ExecuteNodesPublic
Partições Dinâmicas
A partir de 3.0.1
, suportamos partições dinâmicas. Pode criar um nodearray
mapa para uma partição dinâmica ao adicionar o seguinte.
Tenha em atenção que myfeature
pode ser qualquer descrição da Funcionalidade pretendida. Também pode ser mais do que uma funcionalidade, separada por uma vírgula.
[[[configuration]]]
slurm.autoscale = true
# Set to true if nodes are used for tightly-coupled multi-node jobs
slurm.hpc = false
# This is the minimum, but see slurmd --help and [slurm.conf](https://slurm.schedmd.com/slurm.conf.html) for more information.
slurm.dynamic_config := "-Z --conf \"Feature=myfeature\""
Esta ação irá gerar uma partição dinâmica como a seguinte
# Creating dynamic nodeset and partition using slurm.dynamic_config=-Z --conf "Feature=myfeature"
Nodeset=mydynamicns Feature=myfeature
PartitionName=mydynamicpart Nodes=mydynamicns
Utilizar Partições Dinâmicas para Dimensionamento Automático
Por predefinição, não definimos nós na partição dinâmica. Em vez disso, pode iniciar nós através do CycleCloud ou ao invocar manualmente e estes irão associar azslurm resume
o cluster com o nome que escolheu. No entanto, o Slurm não sabe destes nós, pelo que não pode dimensioná-los automaticamente.
Em vez disso, também pode pré-criar registos de nós desta forma, o que permite ao Slurm dimensioná-los automaticamente.
scontrol create nodename=f4-[1-10] Feature=myfeature State=CLOUD
Uma outra vantagem das partições dinâmicas é que pode suportar vários tamanhos de VM na mesma partição.
Basta adicionar o nome do Tamanho da VM como uma funcionalidade e, em seguida azslurm
, pode distinguir o tamanho da VM que pretende utilizar.
Nota O Tamanho da VM é adicionado implicitamente. Não precisa de adicioná-la a slurm.dynamic_config
scontrol create nodename=f4-[1-10] Feature=myfeature,Standard_F4 State=CLOUD
scontrol create nodename=f8-[1-10] Feature=myfeature,Standard_F8 State=CLOUD
De qualquer forma, depois de criar estes nós num State=Cloud
, estes estão agora disponíveis para dimensionamento automático, como outros nós.
Para suportar vários tamanhos de VM numa nodearray cycleCloud, pode alterar o modelo para permitir vários tamanhos de VM ao adicionar Config.Mutiselect = true
.
[[[parameter DynamicMachineType]]]
Label = Dyn VM Type
Description = The VM type for Dynamic nodes
ParameterType = Cloud.MachineType
DefaultValue = Standard_F2s_v2
Config.Multiselect = true
Redução vertical dinâmica
Por predefinição, todos os nós na partição dinâmica reduzirão verticalmente, tal como as outras partições. Para desativar esta opção, veja SuspendExcParts.
Dimensionamento manual
Se cyclecloud_slurm detetar que o dimensionamento automático está desativado (SuspendTime=-1), utilizará o estado FUTURO para denotar nós desligados em vez de depender do estado de energia no Slurm. Ou seja, quando o dimensionamento automático está ativado, os nós desligados são indicados como idle~
em sinfo. Quando o dimensionamento automático estiver desativado, os nós desligados não aparecerão em sinfo. Ainda pode ver a respetiva definição com scontrol show nodes --future
.
Para começar novos nós, execute /opt/azurehpc/slurm/resume_program.sh node_list
(por exemplo, htc-[1-10]).
Para encerrar nós, execute /opt/azurehpc/slurm/suspend_program.sh node_list
(por exemplo, htc-[1-10]).
Para iniciar um cluster neste modo, basta adicionar SuspendTime=-1
à configuração de slurm adicional no modelo.
Para mudar um cluster para este modo, adicione SuspendTime=-1
ao slurm.conf e execute scontrol reconfigure
. Em seguida, execute o azslurm remove_nodes && azslurm scale
.
Resolução de problemas
Transição da 2.7 para a 3.0
A pasta de instalação foi alterada
/opt/cycle/slurm
->/opt/azurehpc/slurm
Os registos de dimensionamento automático estão agora em
/opt/azurehpc/slurm/logs
vez de/var/log/slurmctld
. Tenha em atençãoslurmctld.log
que ainda estará nesta pasta.cyclecloud_slurm.sh
já não existe. Em vez disso, existe uma novaazslurm
cli, que pode ser executada como raiz.azslurm
suporta a conclusão automática.[root@scheduler ~]# azslurm usage: accounting_info - buckets - Prints out autoscale bucket information, like limits etc config - Writes the effective autoscale config, after any preprocessing, to stdout connect - Tests connection to CycleCloud cost - Cost analysis and reporting tool that maps Azure costs to Slurm Job Accounting data. This is an experimental feature. default_output_columns - Output what are the default output columns for an optional command. generate_topology - Generates topology plugin configuration initconfig - Creates an initial autoscale config. Writes to stdout keep_alive - Add, remove or set which nodes should be prevented from being shutdown. limits - nodes - Query nodes partitions - Generates partition configuration refresh_autocomplete - Refreshes local autocomplete information for cluster specific resources and nodes. remove_nodes - Removes the node from the scheduler without terminating the actual instance. resume - Equivalent to ResumeProgram, starts and waits for a set of nodes. resume_fail - Equivalent to SuspendFailProgram, shuts down nodes retry_failed_nodes - Retries all nodes in a failed state. scale - shell - Interactive python shell with relevant objects in local scope. Use --script to run python scripts suspend - Equivalent to SuspendProgram, shuts down nodes wait_for_resume - Wait for a set of nodes to converge.
Os nós já não estão pré-preenchidos no CycleCloud. Só são criadas quando necessário.
Todos os binários slurm estão dentro do
azure-slurm-install-pkg*.tar.gz
ficheiro, emslurm-pkgs
. São retirados de uma versão binária específica. As repetições binárias atuais são 2023-03-13Para tarefas de MPI, o único limite de rede que existe por predefinição é a partição. Não existem vários "grupos de colocação" por partição, como 2.x. Portanto, só tem um VMSS colocalizado por partição. Também não há utilização do plug-in de topologia, o que exigiu a utilização de um plug-in de submissão de tarefas que também já não é necessário. Em vez disso, submeter para várias partições é agora a opção recomendada para casos de utilização que requerem a submissão de tarefas para vários grupos de colocação.
O CycleCloud suporta um conjunto padrão de atributos de paragens automáticas entre agendadores:
Atributo | Descrição |
---|---|
cyclecloud.cluster.autoscale.stop_enabled | O parante automático está ativado neste nó? [true/false] |
cyclecloud.cluster.autoscale.idle_time_after_jobs | A quantidade de tempo (em segundos) para um nó ficar inativo depois de concluir as tarefas antes de ser reduzido verticalmente. |
cyclecloud.cluster.autoscale.idle_time_before_jobs | A quantidade de tempo (em segundos) para um nó ficar inativo antes de concluir as tarefas antes de ser reduzido verticalmente. |