Os clusters de treinamento da Gemini Enterprise Agent Platform usam 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 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 uma estrutura para gerenciar o ciclo de vida completo 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 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 a utilização justa e eficiente de recursos no cluster.
Configuração básica do cluster
Antes de executar jobs, é necessário 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 principal 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áquinas 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 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" ]
}
]
Nós de login
O pool de nós de login oferece 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 principal compartilhado e persistente 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
Os clusters de treinamento da plataforma de agentes do Gemini Enterprise permitem personalizar um conjunto selecionado de parâmetros slurm.conf, mas essas configurações só podem ser definidas durante a criação inicial do cluster e não podem ser alteradas depois.
Contabilização
Os clusters de treinamento da Gemini Enterprise Agent Platform permitem usar recursos de contabilização integrados para acompanhar o uso de recursos no cluster. Para um guia completo sobre como monitorar métricas como Tempo de CPU específico do job e uso da memória, consulte a documentação oficial de contabilização do Slurm.
| Parâmetro | Valor | Exemplo |
|---|---|---|
| AccountingStorageEnforce | Strings separadas por vírgulas | associations,limits,qos |
Preempção e prioridade
Para gerenciar como os jobs são programados e priorizados, os clusters de treinamento da plataforma de agentes do Gemini Enterprise permitem configurar a preempção de jobs do Slurm. A preempção funciona com o plug-in de prioridade multifatorial para determinar se os jobs em execução precisam ser pausados para dar lugar a trabalhos de maior prioridade.
Para uma visão geral conceitual completa, consulte a documentação oficial do Slurm sobre o plug-in de prioridade multifatorial e preempção.
Parâmetros de preempção
| Parâmetro | Valor | Exemplo |
|---|---|---|
| PREEMPT_TYPE | String | preempt/partition_prio |
| PREEMPT_MODE | Strings separadas por vírgulas | SUSPEND,GANG |
| PREEMPT_EXEMPT_TIME | String | 00:00:00 |
Parâmetros de prioridade
| Parâmetro | Valor | Exemplo |
|---|---|---|
| PRIORITY_TYPE | String | priority/multifactor |
| PRIORITY_WEIGHT_AGE | Número inteiro | 0 |
| PRIORITY_WEIGHT_ASSOC | Número inteiro | 0 |
| PRIORITY_WEIGHT_FAIRSHARE | Número inteiro | 0 |
| PRIORITY_WEIGHT_JOB_SIZE | Número inteiro | 0 |
| PRIORITY_WEIGHT_PARTITION | Número inteiro | 0 |
| PRIORITY_WEIGHT_QOS | Número inteiro | 0 |
| PRIORITY_WEIGHT_TRES | Strings separadas por vírgulas | cpu=100,mem=150 |
Scripts de prólogo e epílogo
É possível configurar scripts Bash personalizados para serem executados automaticamente no início (prólogo) e no final (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 completa 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", "accounting": { "accounting_storage_enforce": "ACCOUNTING_STORAGE_ENFORCE" }, "scheduling": { "priority_type": "PRIORITY_TYPE", "priority_weight_age": PRIORITY_WEIGHT_AGE, "priority_weight_assoc": PRIORITY_WEIGHT_ASSOC, "priority_weight_fairshare": PRIORITY_WEIGHT_FAIRSHARE, "priority_weight_job_size": PRIORITY_WEIGHT_JOB_SIZE, "priority_weight_partition": PRIORITY_WEIGHT_PARTITION, "priority_weight_qos": PRIORITY_WEIGHT_QOS, "priority_weight_tres": "PRIORITY_WEIGHT_TRES", "preempt_type": "PREEMPT_TYPE", "preempt_mode": "PREEMPT_MODE", "preempt_exempt_time": "PREEMPT_EXEMPT_TIME" }, "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 cluster
Como gerenciar um cluster em execução
Depois que o cluster for criado com as configurações de contabilização e preempção escolhidas, você poderá usar 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 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 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 são programados para serem executados antes de outros.
Consulte a sprio documentação do utilitário
para uso detalhado.
Exemplos de preempção
A documentação oficial do Slurm oferece vários exemplos práticos de diferentes estratégias de preempção. É possível encontrá-los na página de preempção do Slurm.
A seguir
O conteúdo a seguir se concentra nas etapas finais do ciclo de vida de machine learning: gerenciamento, implantação e monitoramento dos modelos treinados.
- Implantar o modelo para inferência: implante o modelo treinado em um endpoint da Vertex AI para atender solicitações de inferência on-line em escala.
- Gerenciar o ciclo de vida do modelo: use o Model Registry da plataforma de agentes do Gemini Enterprise para versionar, comparar e gerenciar seus modelos. Um pipeline pode ser configurado para registrar automaticamente um novo modelo após o treinamento.
- Monitorar as execuções de pipeline e o desempenho do modelo:
- Monitoramento de pipeline: 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: após a implantação, configure o monitoramento para detectar degradação e anomalias no desempenho de previsão do modelo, o que ajuda a manter a acurácia do modelo ao longo do tempo.
- Otimizar custos e gerenciar 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 infrequentes, 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.