Tutorial: gerenciar contas e programação de jobs em um cluster

Se você tiver interesse nos clusters de treinamento da Vertex AI, entre em contato com seu representante de vendas para ter acesso.

Este guia demonstra como usar os recursos de contabilidade e qualidade de serviço (QoS) do Slurm para gerenciar com eficiência um único cluster de treinamento compartilhado por várias equipes com diferentes prioridades e necessidades de recursos.

A meta

Ao final deste tutorial, você terá uma estrutura para gerenciar recursos de cluster que podem:

Aplicar limites de recursos por equipe.
Priorize e interrompa jobs com base na urgência.
Fornecer uma contabilidade clara do consumo de recursos.
Maximize a utilização do cluster e mantenha a justiça.

Pré-requisitos

Um cluster de treinamento em execução com contabilidade, substituição e prioridade configuradas para gerenciar contas, programar e priorizar jobs.
Orquestrar
Configurações avançadas do Slurm
Acesso sudo no nó de login do cluster para executar comandos de administrador.

Conceitos principais: os elementos básicos da contabilidade do Slurm

O Slurm usa uma hierarquia clara e flexível para gerenciar recursos. É fundamental entender esses quatro elementos básicos.

Componente	Exemplo	Finalidade
Conta	Uma equipe ou um projeto	A unidade principal para agrupar usuários e definir limites gerais de recursos (por exemplo, `team_ace` pode usar um máximo de 10 nós).
User	Um pesquisador individual	A pessoa que envia um job. Cada usuário precisa pertencer a uma conta padrão.
Partição	Uma fila de hardware	Um agrupamento lógico de nós. Para ter mais flexibilidade, recomendamos uma única partição com todos os nós.
QOS	Um livro de regras	Um conjunto nomeado de regras que define limites de jobs (por exemplo, "jobs nesta QOS só podem usar dois nós") e prioridade de programação.

Com esse modelo, é possível definir uma cota de alto nível para uma conta inteira e aplicar um limite mais granular, por job, usando uma QOS.

As personas: administrador x pesquisador

Dois papéis distintos interagem com esse sistema: o administrador do cluster e o pesquisador.

Administrador do cluster

Ferramenta principal: sacctmgr (gerenciador de contas do Slurm)
Sua tarefa é criar o "esqueleto" de contas, usuários e regras de QOS. Normalmente, essa é uma tarefa de "configurar uma vez, atualizar conforme necessário".
Principais tarefas: criar contas, atribuir usuários a contas, definir manuais de regras de QOS e vinculá-los.

Pesquisador

Ferramentas principais: sbatch, squeue, sinfo
O trabalho deles: enviar e monitorar jobs de pesquisa.
A mágica: quando um pesquisador envia um job, o Slurm verifica automaticamente as regras associadas à conta e à qualidade de serviço (QoS). Se o job violar algum limite, o Slurm vai rejeitá-lo com uma mensagem de erro clara.

O tutorial: um tutorial progressivo

O tutorial a seguir coloca esses conceitos em prática com uma série de cenários progressivos. Neste tutorial, vamos assumir a função de administrador do cluster. Sua tarefa é configurar uma conta, team_ace, e um usuário, user_alice. Os cenários começam sem limites e adicionam progressivamente camadas de controle.

Parte 1: configuração inicial (sem limites)

Crie a conta e associe o usuário.

O objetivo é criar a hierarquia básica para team_ace e user_alice.
O método: use sacctmgr para adicionar uma conta e um usuário associado a ela.

# --- (Run as Admin) ---

# 1. Create the 'team_ace' account
sudo sacctmgr add account team_ace Description="The Ace Team"

# 2. Create the 'user_alice' user and map them to their default account
# (Note: 'user_alice' must already exist as a Linux user on the node)
sudo sacctmgr add user user_alice Account=team_ace

# 3. Show the hierarchy we just built to confirm
sacctmgr show associations where account=team_ace

Resultado: como usuário user_alice, agora você pode enviar um job grande. Como não há limites, um job de sete nós é aceito e executado imediatamente (supondo que sete nós estejam inativos).

Parte 2: adicionar limites no nível do grupo a uma conta

Em seguida, aplique um limite de recursos à conta team_ace, limitando toda a equipe a um máximo de 6 nós e 4 jobs totais.

A meta: definir um limite total de recursos para uma equipe inteira.
O método: aplicamos esse limite à conta team_ace usando GrpJobs (trabalhos em grupo) e GrpTRES (recursos rastreáveis em grupo, neste caso, node=6).

# --- (Run as Admin) ---

# 1. Add group-level job and node limits to the 'team_ace' account
sudo sacctmgr modify account where name=team_ace set GrpJobs=4 GrpTRES=node=6

# 2. View the limits to confirm the change
sacctmgr show association where account=team_ace

Resultados: para verificar se os novos limites estão funcionando, faça os seguintes testes como user_alice:

Limite de nós: o envio de um job de sete nós agora falha. O job é colocado em um estado pendente (PD) com o motivo (AssocGrpNodeLimit).
Limite de jobs: o envio de cinco jobs de nó único resulta em quatro jobs em execução (R) e o quinto job pendente (PD) com o motivo (AssocGrpJobsLimit).

Os limites no nível da conta estão funcionando perfeitamente.

Parte 3: adicionar um limite por job com QoS

O limite de grupo no nível da conta é eficaz para limitar o uso total de recursos de uma equipe. No entanto, isso não impede que um usuário envie um único job que consuma toda a cota da equipe. Para controlar o tamanho dos jobs individuais, a próxima etapa é usar uma qualidade de serviço (QoS).

O objetivo: restringir o tamanho máximo de qualquer job individual enviado pela equipe.
O método: vamos criar uma Qualidade de Serviço (QoS) chamada qos1 com uma regra MaxTRESPerJob=node=2. Em seguida, vamos definir essa como a QOS padrão para toda a conta team_ace.

# --- (Run as Admin) ---

# 1. Create a QOS with a per-job limit of 2 nodes
sudo sacctmgr add qos qos1 MaxTRESPerJob=node=2

# 2. Allow the 'team_ace' account to use this QOS
sudo sacctmgr modify account where account=team_ace set QOS=qos1

# 3. Set 'qos1' as the DEFAULT QOS for all users in this account
sudo sacctmgr modify account where account=team_ace set DefaultQOS=qos1

Resultado: agora, se user_alice enviar um job de três nós, ele será colocado em um estado pendente com o motivo (QOSMaxNodePerJobLimit). O usuário ainda está dentro da cota total da conta (seis nós), mas violou a regra de QoS por job.

Parte 4: adicionar uma substituição específica do usuário

E se user_alice for um estagiário e precisar ser restrito a trabalhos ainda menores, sem afetar o restante da equipe?

Objetivo: aplicar um limite mais restritivo a um único usuário.
O método: vamos criar um novo QOS (qos_intern) mais restritivo e aplicá-lo como padrão especificamente para user_alice. Isso substitui o QOS padrão da conta.


# --- (Run as Admin) ---

# 1. Create a more restrictive QOS with a 1-node limit
sudo sacctmgr add qos qos_intern MaxTRESPerJob=node=1

# 2. Allow the account to use this new QOS
sudo sacctmgr modify account where account=team_ace set QOS+=qos_intern

# 3. Apply 'qos_intern' as the default QOS for the specific user association
sudo sacctmgr modify user where name=user_alice account=team_ace set DefaultQOS=qos_intern

Resultado: se user_alice tentar enviar o job de dois nós que antes era permitido em qos1, a ação vai falhar com (QOSMaxNodePerJobLimit). A regra mais específica no nível do usuário substituiu com sucesso a regra geral no nível da conta.

Parte 5: configurar a prioridade e a substituição

Por fim, configure a prioridade e a substituição do job para garantir que os jobs críticos possam ser executados imediatamente, mesmo que o cluster esteja cheio.

O objetivo é criar um QOS "urgente" de alta prioridade que possa pausar ou cancelar um job de prioridade mais baixa para liberar recursos.
O método:
1. Crie um novo qos_urgent com um valor Priority alto.
2. Diga ao qos_urgent que ele pode Preempt jobs em execução no qos1.
3. Configure o qos1 para REQUEUE os jobs quando eles forem desalojados.


# --- (Run as Admin) ---

# 1. Create a new 'qos_urgent' with a high priority that can preempt 'qos1'
sudo sacctmgr add qos qos_urgent Priority=1000 Preempt=qos1

# 2. Configure 'qos1' to requeue preempted jobs after a 10-second grace period
sudo sacctmgr modify qos where name=qos1 set PreemptMode=REQUEUE GraceTime=10

# 3. Allow the 'team_ace' account and 'user_alice' to use this new QOS
sudo sacctmgr modify account where account=team_ace set QOS+=qos_urgent
sudo sacctmgr modify user where name=user_alice account=team_ace set QOS+=qos_urgent

# 4. For this scenario, remove the group limits so preemption is easier to trigger
sudo sacctmgr modify account where name=team_ace set GrpJobs=-1 GrpTRES=node=-1

Resultado:

Em um terminal, user_alice envia um job de longa duração com o qos1 padrão. Ele começa a ser executado (R).
Em um segundo terminal, user_alice envia um job grande usando o QOS urgente (sbatch --qos=qos_urgent ...).
Em segundos, o estado do primeiro job muda de em execução (R) para pendente (PD) com o motivo (Preempted). O job urgente começa a ser executado.

Pronto. Você configurou um sistema em que o trabalho de alta prioridade substitui automaticamente o trabalho de baixa prioridade.

Resumo e próximas etapas

Ao seguir este tutorial, você aprendeu a usar os recursos de contabilidade hierárquica do Slurm para ter controle granular sobre um cluster compartilhado. Agora você pode:

Definir limites globais: use contas para definir cotas totais de recursos para equipes inteiras.
Aplicar regras por job: use o QOS para controlar o tamanho e a prioridade de jobs individuais.
Crie substituições específicas: aplique uma QOS diferente a um usuário para ter controle refinado.
Garantir a prioridade: configure a remoção para garantir que as cargas de trabalho críticas sempre possam ser executadas.

Esse modelo em camadas oferece uma maneira flexível e eficiente de gerenciar os recursos do cluster de forma justa. Para configurações ainda mais avançadas, consulte a documentação oficial do Slurm (em inglês).

Tutorial: gerenciar contas e programação de jobs em um cluster Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.