Os clusters de treinamento da Gemini Enterprise Agent Platform usam o Simple Linux Utility for Resource Management (Slurm) como o orquestrador para gerenciar e programar jobs no cluster.
O Slurm é um sistema de gerenciamento de clusters e programação 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 lidar com jobs paralelos que são executados em um conjunto de nós alocados.
- O Slurm mantém uma fila de jobs pendentes, usando um mecanismo de priorização sofisticado 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 uma utilização justa 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. Nesta seção, detalhamos 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 os 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áquina ou níveis de acesso. Elas são definidas como uma lista no campo de partições 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 com 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 no 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.
É preciso 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
Os clusters de treinamento da Gemini Enterprise Agent Platform permitem definir parâmetros slurm.conf e alterá-los
em um cluster em execução. Consulte
Mapas de configuração do Slurm.
Contabilização, preempção e prioridade
A contabilização do Slurm está ativada em todos os clusters, para que você possa monitorar o uso de recursos por job, como Tempo de CPU e memória. Também é possível aplicar limites de contabilidade,
ponderar a prioridade do job e ativar a preempção usando config, como no
exemplo de especificação de cluster. Para saber como eles funcionam, consulte a
documentação do Slurm sobre contabilização,
o plug-in de prioridade multifator
e preempção.
Scripts de prólogo e epílogo
É possível configurar scripts Bash personalizados para serem executados automaticamente no início (prolog) e no fim (epilog) 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. É possível 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
Como gerenciar um cluster em execução
Depois que o cluster for criado com as configurações de contabilização e preempção escolhidas, use as ferramentas de linha de comando do Slurm para gerenciar contas de usuário e monitorar a programação 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 a ele 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 contabilização do Slurm.
Como verificar a 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 estão programados para
serem executados antes de outros.
Consulte a documentação do utilitário sprio
para saber mais sobre o uso.
Exemplos de preempção
A documentação oficial do Slurm fornece vários exemplos de diferentes estratégias de preempção. Elas podem ser encontradas na página Preempção do Slurm.
A seguir
O foco a seguir está nas etapas finais do ciclo de vida do machine learning: gerenciamento, implantação e monitoramento dos modelos treinados.
- Implantar o modelo para inferência: implante o modelo treinado em um endpoint da Gemini Enterprise Agent Platform para atender a 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 controlar 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 do pipeline e o desempenho do modelo:
- Monitoramento de pipelines: acompanhe o gráfico de execução, os artefatos e o desempenho das execuções de pipeline para depurar problemas e otimizar a orquestração.
- Monitoramento de modelos da Gemini Enterprise Agent Platform: após a implantação, configure o monitoramento para detectar desvios e anomalias no desempenho de previsão do modelo, o que ajuda a manter a acurácia do modelo 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.