Os clusters de treinamento da Gemini Enterprise Agent Platform usam o Simple Linux Utility for Resource Management (Slurm) como orquestrador para gerenciar e programar jobs no cluster.
O Slurm é um sistema de gerenciamento de clusters e agendamento de jobs de código aberto amplamente usado, conhecido pela escalonabilidade e tolerância a falhas.
Principais recursos do Slurm
- O Slurm aloca um conjunto de nós de computação para uso exclusivo de um job específico por um período definido. Isso garante que um job tenha acesso dedicado aos recursos necessários para ser executado sem interferência.
- O Slurm oferece um framework para gerenciar todo o ciclo de vida de um job, desde o envio e a execução até o monitoramento e a conclusão. Esse sistema foi projetado especificamente para processar jobs paralelos executados em um conjunto de nós alocados.
- O Slurm mantém uma fila de jobs pendentes usando um sofisticado mecanismo de priorização para arbitrar o acesso aos recursos de computação. Ao considerar fatores como tamanho do job, prioridade do usuário e tempo de espera, esse sistema garante o uso justo e eficiente dos recursos em todo o cluster.
Configuração básica do cluster
Antes de executar jobs, é preciso definir a estrutura fundamental do cluster do Slurm. Esta seção detalha as configurações essenciais, incluindo como organizar nós de computação em partições, especificar um pool de nós de login dedicado e configurar um diretório inicial compartilhado para seus usuários.
Partições
As partições agrupam nós em conjuntos lógicos, o que pode ser útil para gerenciar diferentes tipos de máquinas ou níveis de acesso. Eles são definidos como uma lista no campo "partitions" do slurm_spec.
Cada objeto de partição tem os seguintes campos obrigatórios:
id: um identificador exclusivo da partição.node_pool_ids: uma lista que contém os IDs de um ou mais pools de nós que pertencem a essa partição.
Exemplo:
"partitions": [
{
"id": "a4",
"node_pool_ids": [ "a4" ]
}
]
Os jobs enviados sem --partition são executados na partição padrão. Para especificar
a partição padrão, defina default_partition_id em slurm_spec como o
id de uma das suas partições. Se você não definir, a primeira partição na lista será a padrão.
Nós de login
O pool de nós de login fornece nós dedicados que servem como o principal ponto de
entrada para os usuários interagirem com o cluster. O campo login_node_pool_id especifica o identificador exclusivo desse pool.
Exemplo:
"login_node_pool_id": "login"
Armazenamento do diretório principal
O campo home_directory_storage especifica a instância do Filestore a ser
montada como o diretório /home em todos os nós do cluster. Isso fornece
um diretório inicial compartilhado e permanente para todos os usuários.
É necessário fornecer o nome completo do recurso da instância do Filestore para esse valor.
Exemplo:
"home_directory_storage": "projects/PROJECT_ID/locations/REGION-ZONE/instances/FILESTORE_INSTANCE_NAME"
Configuração avançada do Slurm
Com os clusters de treinamento da Gemini Enterprise Agent Platform, é possível definir e mudar parâmetros slurm.conf em um cluster em execução. Consulte
Mapas de configuração do Slurm.
Contabilização, substituição e prioridade
A contabilidade do Slurm é ativada em todos os clusters. Assim, é possível acompanhar o uso de recursos por tarefa, como tempo de CPU e memória. Você também pode aplicar limites de contabilidade, ponderar a prioridade do job e ativar a preempção usando config, como na especificação de cluster de exemplo. Para saber como eles funcionam, consulte a documentação do Slurm sobre contabilidade, o plug-in de prioridade multifatorial e preempção.
Scripts de prólogo e epílogo
É possível configurar scripts Bash personalizados para serem executados automaticamente no início (prólogo) e no fim (epílogo) de cada job usando os seguintes campos:
prolog_bash_scripts: uma lista de strings, em que cada string contém o conteúdo completo de um script Bash a ser executado antes do início do job.epilog_bash_scripts: uma lista de strings, em que cada string contém o conteúdo completo de um script Bash a ser executado após a conclusão do job.
Isso é útil para configurar um ambiente de job exclusivo ou realizar tarefas de limpeza automatizadas.
Exemplo de especificação de cluster
O exemplo a seguir mostra uma configuração JSON para criar um cluster de treinamento. Você pode adaptar essa especificação às suas necessidades.
{ // ... other cluster configurations ... "orchestratorSpec": { "slurmSpec": { "partitions": [ { "id": "a4", "node_pool_ids": ["a4"] } ], "login_node_pool_id": "login", "home_directory_storage": "projects/PROJECT_ID/locations/REGION-ZONE/instances/FILESTORE_INSTANCE_ID", "config": { "AccountingStorageEnforce": "associations,limits,qos", "PriorityType": "priority/multifactor", "PriorityWeightAge": "1000", "PriorityWeightFairshare": "10000", "PreemptType": "preempt/partition_prio", "PreemptMode": "REQUEUE", "PreemptExemptTime": "00:10:00" }, "prolog_bash_scripts": [ "#!/bin/bash\necho 'First prolog script running'", "#!/bin/bash\necho 'Second prolog script running'" ], "epilog_bash_scripts": [ "#!/bin/bash\necho 'Epilog script running'" ] // ... other Slurm settings ... } } }
Gerenciamento e operações de clusters
Gerenciar um cluster em execução
Depois que o cluster for criado com as configurações de contabilidade e substituição escolhidas, use as ferramentas de linha de comando do Slurm para gerenciar contas de usuário e monitorar o agendamento de jobs.
Gerenciamento de contas com o sacctmgr
O comando sacctmgr é a principal ferramenta para gerenciar informações de usuários e contas no banco de dados do Slurm. Por exemplo, para adicionar um novo usuário a uma conta
e conceder acesso a uma partição, execute o seguinte comando:
sudo sacctmgr add User Accounts=<account> Partition=<partition> <user>
Para uma lista completa de todas as opções de sacctmgr, consulte a
documentação oficial de contabilidade do Slurm.
Verificação da prioridade do job
Para verificar os componentes de prioridade de cada job na fila, use o utilitário sprio. Isso é útil para entender por que determinados jobs são programados para
serem executados antes de outros.
Consulte a documentação do utilitário sprio para saber mais sobre o uso.
Exemplos de remoção
A documentação oficial do Slurm oferece vários exemplos funcionais de diferentes estratégias de preempção. Você pode encontrar essas informações na página Preempção do Slurm.
A seguir
A seguir, vamos abordar as etapas finais do ciclo de vida de machine learning: gerenciamento, implantação e monitoramento dos modelos treinados.
- Implante seu modelo para inferência: implante o modelo treinado em um endpoint da Gemini Enterprise Agent Platform para disponibilizar solicitações de inferência on-line em grande escala.
- Gerencie o ciclo de vida do seu modelo: use o Model Registry da Gemini Enterprise Agent Platform para criar versões, comparar e gerenciar seus modelos. Um pipeline pode ser configurado para registrar automaticamente um novo modelo após o treinamento.
- Monitore as execuções de pipeline e a performance do modelo:
- Monitoramento de pipeline: acompanhe o gráfico de execução, os artefatos e a performance das execuções de pipeline para depurar problemas e otimizar a orquestração.
- Monitoramento de modelos: após a implantação, configure o monitoramento para detectar desvios e anomalias na performance de previsão do modelo, o que ajuda a manter a acurácia dele ao longo do tempo.
- Otimize os custos e gerencie o ciclo de vida do cluster: ao usar pipelines automatizados, gerencie o ciclo de vida do cluster considerando a frequência de execução.
- Para execuções pouco frequentes, adicione uma etapa final do pipeline para excluir o cluster e economizar custos. Isso geralmente envolve a criação de um componente de pipeline personalizado que chama a função de exclusão.
- Para execuções frequentes, deixe o cluster ativo para reduzir o tempo de inicialização do job.