1. Visão geral
Este é o codelab do Google para executar um cluster do Slurm no Google Cloud Platform. Ao final deste codelab, você terá uma compreensão sólida da facilidade de provisionar e da operação de um cluster do Slurm com escalonamento automático.
O Google Cloud fez uma parceria com a SchedMD para lançar um conjunto de ferramentas que facilitam a inicialização do gerenciador de carga de trabalho Slurm no Compute Engine e expansão do cluster existente dinamicamente quando você precisa de recursos extras. Essa integração foi criada pelos especialistas da SchedMD de acordo com as práticas recomendadas do Slurm.
Se você planeja usar as integrações do Slurm no Google Cloud Platform ou tem alguma dúvida, participe do curso Google Cloud & Grupo de discussão da comunidade do Slurm!
Sobre o Slurm
Diagrama arquitetônico básico de um cluster independente do Slurm no Google Cloud Platform.
A Slurm é um dos principais gerentes de carga de trabalho para clusters de HPC em todo o mundo. O Slurm oferece um sistema de gerenciamento de cargas de trabalho e programação de jobs de código aberto, tolerante a falhas e altamente escalonável para clusters grandes e pequenos do Linux. O Slurm não precisa de modificações do kernel para sua operação e é relativamente independente. Como gerenciador de carga de trabalho do cluster, o Slurm tem três funções principais:
- Ele aloca aos usuários acesso exclusivo ou não exclusivo a recursos (nós de computação) por um período para que eles possam realizar o trabalho.
- Ele fornece um framework para iniciar, executar e monitorar trabalhos (normalmente um job paralelo) no conjunto de nós alocados.
- Ele arbitra a contenção de recursos ao gerenciar uma fila de trabalho pendente.
O que você vai aprender
- Como configurar um cluster do Slurm usando o Terraform
- Como executar um job usando SLURM
- Como consultar informações do cluster e monitorar jobs em execução no SLURM
- Como fazer o escalonamento automático dos nós para acomodar parâmetros e requisitos específicos do job
- Onde encontrar ajuda com o Slurm
Pré-requisitos
- Conta do Google Cloud Platform e um projeto com faturamento
- Experiência básica com Linux
2. Configuração
Configuração de ambiente autoguiada
Criar um projeto
Se você ainda não tiver uma Conta do Google (Gmail ou G Suite), crie uma. Faça login no console do Google Cloud Platform ( console.cloud.google.com) e abra a página Gerenciar recursos:
Clique em Criar projeto.
Digite o nome do projeto. Lembre-se do ID do projeto, destacado em vermelho na captura de tela acima. O ID do projeto precisa ser um nome exclusivo em todos os projetos do Google Cloud. Se o nome do projeto não for exclusivo, o Google Cloud vai gerar um ID aleatório com base no nome dele.
Em seguida, você precisará ativar o faturamento no Developers Console para usar os recursos do Google Cloud.
A execução deste codelab não deve custar mais do que alguns dólares, mas pode ser mais se você decidir usar mais recursos ou se deixá-los em execução (consulte a seção "Conclusão" no final deste documento). A calculadora de preços do Google Cloud Platform está disponível aqui.
Novos usuários do Google Cloud Platform estão qualificados para um teste sem custo financeiro de US$300.
Google Cloud Shell
Embora o Google Cloud possa ser operado remotamente do seu laptop, neste codelab vamos usar o Google Cloud Shell, um ambiente de linha de comando executado no Cloud.
Inicie o Google Cloud Shell
No Console do GCP, clique no ícone do Cloud Shell na barra de ferramentas localizada no canto superior direito:
Depois clique em Iniciar o Cloud Shell:
O provisionamento e a conexão ao ambiente levarão apenas alguns instantes para serem concluídos:
Essa máquina virtual contém todas as ferramentas de desenvolvimento necessárias. Ela oferece um diretório principal permanente de 5 GB e é executada no Google Cloud, o que melhora muito o desempenho da rede e simplifica a autenticação. Grande parte do trabalho que você faz neste laboratório pode ser feito com um navegador da Web ou um Google Chromebook.
Depois de se conectar ao Cloud Shell, você já estará autenticado e o projeto estará configurado com seu PROJECT_ID:
$ gcloud auth list
Saída de comando:
Credentialed accounts:
- <myaccount>@<mydomain>.com (active)
$ gcloud config list project
Saída de comando:
[core]
project = <PROJECT_ID>
Se o ID do projeto não estiver definido corretamente, configure-o com este comando:
$ gcloud config set project <PROJECT_ID>
Saída de comando:
Updated property [core/project].
3. Preparar e revisar a configuração do Slurm no Terraform
Fazer o download da configuração do Slurm no Terraform
Na sessão do Cloud Shell, execute o seguinte comando para clonar (fazer o download) o repositório Git que contém o Slurm para os arquivos do Terraform do Google Cloud Platform:
git clone https://github.com/SchedMD/slurm-gcp.git
Alterne para o diretório de configuração de implantação do Slurm executando o seguinte comando:
cd slurm-gcp
Configurar os tfvars do Terraform do Slurm
O arquivobasic.tfvars.example detalha a configuração da implantação, incluindo a rede, as instâncias e o armazenamento a ser implantado. Copie para um novo arquivo, que vamos chamar de "arquivo tfvars", depois edite conforme necessário.
cd tf/example/basic cp basic.tfvars.example basic.tfvars
Na sessão do Cloud Shell, abra o arquivo tfvars basic.tfvars. Use o editor de linha de comando que preferir (vi, nano, emacs etc.) ou use o editor de código do console do Cloud para visualizar o conteúdo do arquivo:
Revise o conteúdo do arquivo tfvars.
cluster_name = "g1"
project = "<project>"
zone = "us-west1-b"
# network_name = "<existing network name>"
# subnetwork_name = "<existing subnetwork name>"
# shared_vpc_host_project = "<vpc host project>"
# disable_controller_public_ips = true
# disable_login_public_ips = true
# disable_compute_public_ips = true
# suspend_time = 300
controller_machine_type = "n1-standard-2"
controller_image = "projects/schedmd-slurm-public/global/images/family/schedmd-slurm-20-11-4-hpc-centos-7"
controller_disk_type = "pd-standard"
controller_disk_size_gb = 50
# controller_labels = {
# key1 = "val1"
# key2 = "val2"
# }
# controller_service_account = "default"
# controller_scopes = ["https://www.googleapis.com/auth/cloud-platform"]
# cloudsql = {
# server_ip = "<cloudsql ip>"
# user = "slurm"
# password = "verysecure"
# db_name = "slurm_accounting"
# }
# controller_secondary_disk = false
# controller_secondary_disk_size = 100
# controller_secondary_disk_type = "pd-ssd"
#
# When specifying an instance template, specified controller fields will
# override the template properites.
# controller_instance_template = null
login_machine_type = "n1-standard-2"
login_image = "projects/schedmd-slurm-public/global/images/family/schedmd-slurm-20-11-4-hpc-centos-7"
login_disk_type = "pd-standard"
login_disk_size_gb = 20
# login_labels = {
# key1 = "val1"
# key2 = "val2"
# }
# login_node_count = 1
# login_node_service_account = "default"
# login_node_scopes = [
# "https://www.googleapis.com/auth/monitoring.write",
# "https://www.googleapis.com/auth/logging.write"
# ]
#
# When specifying an instance template, specified login fields will
# override the template properties.
# login_instance_template = null
# Optional network storage fields
# network_storage is mounted on all instances
# login_network_storage is mounted on controller and login instances
# network_storage = [{
# server_ip = "<storage host>"
# remote_mount = "/home"
# local_mount = "/home"
# fs_type = "nfs"
# mount_options = null
# }]
#
# login_network_storage = [{
# server_ip = "<storage host>"
# remote_mount = "/net_storage"
# local_mount = "/shared"
# fs_type = "nfs"
# mount_options = null
# }]
# compute_node_service_account = "default"
# compute_node_scopes = [
# "https://www.googleapis.com/auth/monitoring.write",
# "https://www.googleapis.com/auth/logging.write"
# ]
partitions = [
{ name = "debug"
machine_type = "n1-standard-2"
static_node_count = 0
max_node_count = 10
zone = "us-west1-b"
image ="projects/schedmd-slurm-public/global/images/family/schedmd-slurm-20-11-4-hpc-centos-7"
image_hyperthreads = false
compute_disk_type = "pd-standard"
compute_disk_size_gb = 20
compute_labels = {}
cpu_platform = null
gpu_count = 0
gpu_type = null
network_storage = []
preemptible_bursting = false
vpc_subnet = null
exclusive = false
enable_placement = false
regional_capacity = false
regional_policy = {}
instance_template = null
},
# { name = "partition2"
# machine_type = "n1-standard-16"
# static_node_count = 0
# max_node_count = 20
# zone = "us-west1-b"
# image = "projects/schedmd-slurm-public/global/images/family/schedmd-slurm-20-11-4-hpc-centos-7"
# image_hyperthreads = false
#
# compute_disk_type = "pd-ssd"
# compute_disk_size_gb = 20
# compute_labels = {
# key1 = "val1"
# key2 = "val2"
# }
# cpu_platform = "Intel Skylake"
# gpu_count = 8
# gpu_type = "nvidia-tesla-v100"
# network_storage = [{
# server_ip = "none"
# remote_mount = "<gcs bucket name>"
# local_mount = "/data"
# fs_type = "gcsfuse"
# mount_options = "file_mode=664,dir_mode=775,allow_other"
# }]
# preemptible_bursting = true
# vpc_subnet = null
# exclusive = false
# enable_placement = false
#
# ### NOTE ####
# # regional_capacity is under development. You may see slowness in
# # deleting lots of instances.
# #
# # With regional_capacity : True, the region can be specified in the zone.
# # Otherwise the region will be inferred from the zone.
# zone = "us-west1"
# regional_capacity = True
# # Optional
# regional_policy = {
# locations = {
# "zones/us-west1-a" = {
# preference = "DENY"
# }
# }
# }
#
# When specifying an instance template, specified compute fields will
# override the template properties.
# instance_template = "my-template"
]
Dentro do arquivo tfvars, há vários campos a serem configurados. O único campo que precisa ser configurado é o projeto. Todas as outras configurações no exemplo podem ser usadas no estado em que se encontram, mas as modificam conforme necessário para sua situação. Para uma descrição mais detalhada das opções de configuração, clique aqui.
- cluster_name::nome do cluster do Slurm
- projeto: ID do projeto do Google Cloud em que os recursos serão implantados
- zone:a zona do Google Cloud que vai conter as instâncias de controlador e login deste cluster. Mais informações
- network_name: rede de nuvem privada virtual para implantar o cluster do Slurm
- subnetwork_name: sub-rede de nuvem privada virtual em que o cluster do Slurm será implantado
- shared_vpc_host_project: rede VPC compartilhada para implantar o cluster do Slurm em
- disable_controller_public_ips::será possível atribuir um IP externo ao controlador do Slurm?
- disable_login_public_ips::você quer atribuir um IP externo ao nó de login do Slurm?
- disable_compute_login_ips: atribui um IP externo ao nó de login do Slurm?
- suspend_time::tempo de espera depois que um nó fica ocioso antes de suspendê-lo.
- controller_machine_type::tipo de instância do nó do controlador
- controller_image::imagem do GCP usada para criar a instância do controlador do Slurm
- controller_disk_type::tipo do disco de inicialização da instância do controlador
- controller_disk_size_gb: o tamanho do disco de inicialização da instância do controlador
- controller_labels: rótulos a serem anexados à instância do controlador
- controller_service_account: : conta de serviço a ser usada na instância do controlador
- controller_scopes: : escopo de acesso da instância do controlador
- cloudsql: servidor do Google CloudSQL a ser usado como banco de dados Slurm em vez de hospedar um banco de dados na instância do controlador
- server_ip::IP do servidor do CloudSQL
- user: nome de usuário do Cloud SQL
- password:senha do Cloud SQL
- db_name::nome do banco de dados do Cloud SQL
- controller_secondary_disk::adicionar um disco secundário para armazenamento do servidor NFS?
- controller_secondary_disk_type::tipo do disco secundário do controlador
- controller_secondary_disk_size_gb::tamanho do disco secundário do controlador
- controller_instance_template: o modelo de instância do GCP a ser usado na instância do controlador. Os campos de computação especificados vão substituir as propriedades do modelo. Por exemplo: se o controlador_image for especificado, ele substituirá a imagem no modelo de instância.
- login_machine_type::tipo de instância do nó de login (acessível por SSH)
- login_image::imagem do GCP usada para criar a instância de login do Slurm.
- login_disk_type::tipo do disco de inicialização da instância de login
- login_disk_size_gb: tamanho do disco de inicialização da instância de login
- login_labels: rótulos a serem anexados à instância de login
- login_node_count::número de nós de login a serem criados
- login_node_service_account: conta de serviço a ser usada nas instâncias de login
- login_node_scopes: : escopo de acesso da instância de login
- login_instance_template: o modelo de instância do GCP a ser usado na instância de login. Os campos de computação especificados vão substituir as propriedades do modelo. Por exemplo: Se login_image for especificado, ele substituirá a imagem no modelo de instância.
- network_storage::armazenamento de rede para montagem em todos os nós. Os campos serão adicionados diretamente ao fstab. Pode ser repetido para outras montagens.
- server_ip::IP do servidor de armazenamento
- remote_mount::nome da montagem de armazenamento (nome do sistema de arquivos)
- local_mount::diretório de montagem local
- fs_type::tipo do sistema de arquivos (NFS, CIFS, Lustre, GCSFuse instalados automaticamente)
- mount_options: opções de montagem (por exemplo, padrões, _netdev)
- login_network_storage::armazenamento de rede para montar nos nós de login e controlador. O NFS, CIFS, Lustre e GCSFuse serão instalados automaticamente. Pode ser repetido para outras montagens.
- server_ip::IP do servidor de armazenamento
- remote_mount::nome da montagem de armazenamento (nome do sistema de arquivos)
- local_mount::diretório de montagem local
- fs_type::tipo do sistema de arquivos (NFS, CIFS, Lustre, GCSFuse instalados automaticamente)
- mount_options: opções de montagem (por exemplo, padrões, _netdev)
- compute_node_service_account: conta de serviço a ser usada nas instâncias de computação
- compute_node_scopes: escopo de acesso das instâncias de computação
- partitions:configuração de partição do Slurm. Pode ser repetido para outras partições.
- name: nome da partição
- machine_type::tipo de instância dos nós de computação
- static_node_count::número de nós de computação sempre ativados
- max_node_count: número máximo de nós de computação total permitido - máximo de 64 mil
- zone:a zona do Google Cloud que vai conter os recursos desta partição. Mais informações
- image: tipo de máquina do nó de imagem do Compute
- image_hyperthreads::ativa ou desativa a hyperthreading na instância.
- compute_disk_type: tipo de disco de inicialização da instância de computação (pd-standard, pd-ssd)
- compute_disk_size_gb: tamanho de um disco de inicialização da instância de computação
- compute_labels: rótulos a serem anexados à instância de computação
- cpu_platform::a plataforma mínima de CPU necessária para todos os nós de computação
- gpu_count: número de GPUs a serem anexadas a cada instância na partição
- gpu_type: tipo de GPU a ser anexado às instâncias da partição
- network_storage: armazenamento de rede para montagem em todos os nós de computação na partição. Os campos serão adicionados diretamente ao fstab. Pode ser repetido para outras montagens.
- server_ip::IP do servidor de armazenamento
- remote_mount::nome da montagem de armazenamento (nome do sistema de arquivos)
- local_mount::diretório de montagem local
- fs_type::tipo do sistema de arquivos (NFS, CIFS, Lustre, GCSFuse instalados automaticamente)
- mount_options::opção de montagem
- preemptible_bursting: as instâncias serão instâncias preemptivas?
- vpc_subnet: sub-rede da nuvem privada virtual para implantar a partição do Slurm na
- exclusivo: ativa o Slurm para alocar nós inteiros para jobs
- enable_placement::ativa as políticas de posicionamento em que as instâncias ficam localizadas próximas umas das outras para baixa latência de rede entre elas.
- regional_capacity::permite que uma instância seja colocada em qualquer zona na região com base na disponibilidade.
- regional_policy::se regional_capacity for verdadeiro, esta política determinará qual região usar e as zonas dessa região não devem ser usadas.
- Instance_template::o modelo de instância do GCP a ser usado nas instâncias do Compute. Os campos de computação especificados vão substituir as propriedades do modelo. Por exemplo: se a imagem for especificada, ela substituirá a imagem no modelo de instância.
Configuração avançada
Se quiser, você pode instalar outros pacotes e softwares como parte do processo de implantação do cluster. É possível instalar software no cluster do Slurm de várias maneiras descritas em "Como instalar apps em um cluster do Slurm no Compute Engine" ou personalizando a imagem implantada pelo Slurm. Atualmente, o Slurm implanta uma imagem de VM fornecida pelo SchedMD que é baseada na imagem de VM de HPC do Google Cloud, com o Slurm instalado.
Para usar sua própria imagem, crie uma com sua própria configuração baseada na imagem pública de VM SchedMD listada no arquivo tfvars. Em seguida, substitua o URI da imagem especificado no arquivo tfvars por sua própria imagem e teste a alteração.
Solução de problemas
Ao longo deste codelab, consulte a seção de solução de problemas do ReadMe do repositório Slurm-GCP.
Os problemas mais comuns são erros cometidos na configuração do arquivo tfvars e restrições de cota. Este codelab foi projetado para ser executado dentro da cota de cota padrão de um novo usuário e dentro do crédito sem custo financeiro de US $300 que um novo usuário recebe. Se uma tentativa de criar VMs falhar, verifique o arquivo /var/log/slurm/resume.log no nó do controlador para verificar se há erros de API.
4. Como implantar e verificar a configuração
Implantar a configuração
Na sessão do Cloud Shell, execute o comando a seguir na pasta slurm-gcp/tf/example:
terraform init terraform apply -var-file=basic.tfvars
Você será solicitado a aceitar as ações descritas, com base nas configurações definidas. Digite "yes" para iniciar a implantação. Para conferir a configuração que será implantada, execute o comando "terraform plan".
Do you want to perform these actions? Terraform will perform the actions described above. Only 'yes' will be accepted to approve. Enter a value: yes
A operação pode levar alguns minutos para ser concluída, seja paciente.
Quando a implantação terminar, uma resposta semelhante a esta vai aparecer:
Apply complete! Resources: 8 added, 0 changed, 0 destroyed.
Outputs:
controller_network_ips = [
[
"10.0.0.2",
],
]
login_network_ips = [
[
"10.0.0.3",
],
]
Verificar a criação da instância de VM
Abra o menu de navegação e selecione Compute Engine > Instâncias de VM.
Você vai encontrar um controlador e uma instância de VM de login listados:
Em Instâncias de VM, veja as duas instâncias de máquina virtual que foram criadas pelo Terraform.
Os nomes serão diferentes se você modificar o campo cluster_name.
- g1-controller (link em inglês)
- g1-login0 (link em inglês)
5. Faça login no cluster do Slurm
Acessar o cluster do Slurm
Volte para a guia do Cloud Shell ou do editor de código. Execute o comando a seguir para fazer login na instância, substituindo <ZONE> pela zona do nó g1-login0 (deve ser us-central1-b):
gcloud compute ssh g1-login0 --zone=<ZONE>
Esse comando vai fazer login na máquina virtual g1-login0.
Outro método para acessar facilmente o nó de login é clicando no botão "SSH" ao lado da VM g1-login0 na página "Instâncias de VM" para abrir uma nova guia com uma conexão SSH.
Se esta for a primeira vez que você usa o Cloud Shell, talvez apareça uma mensagem como a abaixo solicitando a criação de uma chave SSH:
WARNING: The public SSH key file for gcloud does not exist. WARNING: The private SSH key file for gcloud does not exist. WARNING: You do not have an SSH key for gcloud. WARNING: SSH keygen will be executed to generate a key. This tool needs to create the directory [/home/user/.ssh] before being able to generate SSH keys. Do you want to continue (Y/n)?
Se for o caso, digite Y. Se for necessário selecionar uma senha longa, deixe em branco pressionando Enter duas vezes.
Se a seguinte mensagem aparecer após o login:
*** Slurm is currently being configured in the background. *** A terminal broadcast will announce when installation and configuration is complete.
Aguarde e não continue o laboratório até ver esta mensagem (aproximadamente cinco minutos):
*** Slurm login setup complete ***
Quando a mensagem acima aparecer, saia e faça login novamente em g1-login0 para continuar o laboratório. Para fazer isso, pressione CTRL + C para encerrar a tarefa.
Em seguida, execute o seguinte comando de logout da instância:
exit
Agora, reconecte-se à VM de login. Execute o comando a seguir para fazer login na instância, substituindo <ZONE> pela zona do nó g1-login0:
gcloud compute ssh g1-login0 --zone=<ZONE>
Como mostrado acima, talvez seja necessário aguardar um ou dois minutos para se conectar e todos os aspectos da configuração estiverem concluídos.
Tour das ferramentas da CLI do Slurm
Você fez login no nó de login do Slurm do cluster. Este é o nó dedicado à interação entre usuário/administrador, agendamento de jobs do Slurm e atividade administrativa.
Vamos executar alguns comandos para apresentar a linha de comando do Slurm.
Execute o comando sinfo para ver o status dos recursos do cluster:
sinfo
Confira um exemplo de saída do sinfo abaixo. O sinfo reporta os nós disponíveis no cluster, o estado desses nós e outras informações como partição, disponibilidade e qualquer limitação de tempo imposta a esses nós.
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST debug* up infinite 10 idle~ g1-compute-0-[0-9]
É possível ver os 10 nós, ditados pelo "max_node_count" da partição de depuração de 10, são marcadas como "idle~" (o nó está em um modo ocioso e não alocado, pronto para ser ativado).
Em seguida, execute o comando squeue para ver o status da fila do cluster:
squeue
A saída esperada de squeue é mostrada abaixo. squeue relata o status da fila de um cluster. Isso inclui o ID de cada job programado no cluster, a partição a que o job foi atribuído, o nome do job, o usuário que o iniciou, o estado do job, o horário convencional dele em execução e os nós onde o job está alocado. Não temos jobs em execução, então o conteúdo desse comando está vazio.
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
Os comandos do Slurm "srun" e "sbatch" são usados para executar jobs colocados na fila. “srun” executa jobs paralelos e pode ser usado como um wrapper para mpirun. "sbatch" é usado para enviar um job em lote para o slurm e pode chamar o srun uma ou várias vezes em diferentes configurações. "sbatch" pode usar scripts em lote ou com a opção –wrap para executar todo o job na linha de comando.
Vamos executar um job para ver o Slurm em ação e colocar um job na fila.
6. Executar um job do Slurm e escalonar o cluster
Executar um job do Slurm e escalonar o cluster
Agora que o cluster do Slurm está em execução, vamos executar um job e escalonar verticalmente o cluster.
O "sbatch" é usado para executar scripts e comandos em lote do Slurm. Vamos executar um script de sbatch simples que vai executar "hostname" nas nossas VMs com escalonamento automático.
Após fazer login em g1-login0, execute o seguinte comando:
sbatch -N2 --wrap="srun hostname"
Esse comando executa o comando de lote do Slurm. Ele especifica que o sbatch executará dois nós com "-N" é a melhor opção. Também especifica que cada um desses nós executará um "nome do host srun" no bloco de anúncios "–wrap" é a melhor opção.
Por padrão, o sbatch grava a saída em "slurm-%j.out" No diretório de trabalho em que o comando é executado, %j é substituído pelo ID do job de acordo com os Padrões de nome de arquivo do Slurm. No nosso exemplo, o sbatch está sendo executado na pasta /home do usuário, que é um sistema de arquivos compartilhado baseado em NFS e hospedado no controlador por padrão. Isso permite que os nós de computação compartilhem dados de entrada e saída, se desejado. Em um ambiente de produção, o armazenamento em funcionamento precisa ser separado do armazenamento /home para evitar impactos no desempenho das operações do cluster. Montagens de armazenamento separadas podem ser especificadas no arquivo tfvars na pasta "network_storage" .
Depois de executar o script sbatch com a linha de comando sbatch, ele vai retornar um ID do job para o job programado. Por exemplo:
Submitted batch job 2
É possível usar o ID do job retornado pelo comando sbatch para rastrear e gerenciar a execução e os recursos do job. Execute o comando a seguir para ver a fila de jobs do Slurm:
squeue
O job executado provavelmente vai aparecer como este:
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
2 debug g1-compute-0-[0-1] username R 0:10 2 g1-compute-0-[0-1]
Como não tínhamos nenhum nó de computação provisionado, o Slurm cria automaticamente instâncias de computação de acordo com os requisitos do job. A natureza automática desse processo tem dois benefícios. Primeiro, ele elimina o trabalho normalmente exigido em um cluster de HPC de provisionamento manual de nós, configuração do software, integração do nó ao cluster e implantação do job. Segundo, ele permite que os usuários economizem dinheiro porque os nós inativos e não utilizados são reduzidos até que o número mínimo de nós esteja em execução.
Execute o comando sinfo para ver o cluster do Slurm sendo ativado:
sinfo
Isso mostrará os nós listados na fila na coluna "alloc#" o que significa que os nós estão sendo alocados:
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST debug* up infinite 8 idle~ g1-compute-0-[2-9] debug* up infinite 2 alloc# g1-compute-0-[0-1]
Também é possível verificar a seção de instâncias de VM no Console do Google Cloud para ver os nós recém-provisionados. Levará alguns minutos para ativar os nós e executar o Slurm antes que o job seja alocado para os nós recém-alocados. Em breve, sua lista de instâncias de VM será parecida com esta:
Assim que os nós estiverem executando o trabalho, as instâncias serão movidas para uma "alocação" estado, o que significa que os jobs estão alocados a um job:
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST debug* up infinite 8 idle~ g1-compute-0-[2-9] debug* up infinite 2 alloc g1-compute-0-[0-1]
Assim que um job for concluído, ele não será mais listado na fila, e a "alocação" nós no sinfo retornarão ao estado "inativo" estado. Executar "squeue" periodicamente até que o job seja concluído, depois de um ou dois minutos.
O arquivo de saída slurm-%j.out terá sido gravado na pasta /home compartilhada pelo NFS e conterá os nomes do host. Abra ou use o comando cat no arquivo de saída (normalmente slurm-2.out). O conteúdo do arquivo de saída terá:
g1-compute-0-0 g1-compute-0-1
Bom trabalho! Você executou um job e escalonou verticalmente seu cluster do Slurm.
7. Executar um job de MPI
Agora vamos executar um job MPI nos nós. Enquanto estiver conectado a g1-login0, use wget para baixar um programa MPI escrito na linguagem de programação C:
wget https://raw.githubusercontent.com/mpitutorial/mpitutorial/gh-pages/tutorials/mpi-hello-world/code/mpi_hello_world.c
Para usar as ferramentas OpenMPI, é preciso carregar os módulos OpenMPI executando este comando:
module load openmpi
Usaremos o "mpicc" para compilar o código MPI C. execute o seguinte comando:
mpicc mpi_hello_world.c -o mpi_hello_world
Isso compila nosso código C em código de máquina para que possamos executar o código em nosso cluster pelo Slurm.
Em seguida, use seu editor de texto preferido para criar um script sbatch chamado "helloworld_batch":
vi helloworld_batch
Digite i para entrar no modo de inserção "vi".
Copie e cole o texto abaixo no arquivo para criar um script sbatch simples:
#!/bin/bash # #SBATCH --job-name=hello_world #SBATCH --output=hello_world-%j.out # #SBATCH --nodes=2 srun mpi_hello_world
Salve e saia do editor de código pressionando Esc e digitando ":wq" sem aspas.
Esse script define as tarefas e o ambiente de execução em lote do Slurm. Primeiro, o ambiente de execução é definido como bash. Em seguida, o script define primeiro as opções do Slurm com a hashtag "#SBATCH". linhas O nome do job é definido como "hello_world".
O arquivo de saída está definido como "hello_world_%j.out" em que %j é substituído pelo ID do job de acordo com os Padrões de nome de arquivo do Slurm. Esse arquivo de saída é gravado no diretório em que o script em lote é executado. No nosso exemplo, é a pasta "/home" do usuário, que é um sistema de arquivos compartilhado baseado em NFS. Isso permite que os nós de computação compartilhem dados de entrada e saída, se desejado. Em um ambiente de produção, o armazenamento em funcionamento precisa ser separado do armazenamento /home para evitar impactos no desempenho das operações do cluster.
Por fim, o número de nós em que o script precisa ser executado é definido como 2.
Após a definição das opções, os comandos executáveis são fornecidos. Esse script vai executar o código mpi_hello_world em paralelo usando o comando srun, que é uma substituição simples para o comando mpirun.
Em seguida, execute o script sbatch usando a linha de comando sbatch:
sbatch helloworld_batch
A execução do sbatch retornará um ID do job para o job programado. Por exemplo:
Submitted batch job 3
Isso executará o comando hostname em dois nós, com uma tarefa por nó, além de imprimir a saída no arquivo hello_world-3.out.
Como já tínhamos dois nós provisionados, o job será executado rapidamente.
Monitore squeue até que o job seja concluído e não esteja mais listado:
squeue
Depois de concluir, abra ou use um comando cat no arquivo hello_world-3.out e confirme se ele foi executado em g1-compute-0-[0-1]:
Hello world from processor g1-compute-0-0, rank 0 out of 2 processors Hello world from processor g1-compute-0-1, rank 1 out of 2 processors
Após ficar ociosos por cinco minutos (configurável com o campo suspend_time do YAML ou com o campo SuspendTime do slurm.conf), os nós de computação provisionados dinamicamente serão desalocados para liberar recursos. Isso pode ser validado executando sinfo periodicamente e observando o tamanho do cluster voltar a 0:
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST debug* up infinite 10 idle~ g1-compute-0-[0-9]
Tente ativar mais instâncias até a cota permitida na região em que você implantou o cluster e executar diferentes aplicativos MPI.
8. Conclusão
Parabéns, você criou um cluster Slurm no Google Cloud Platform e usou os recursos mais recentes para escalonar automaticamente seu cluster e atender à demanda de carga de trabalho. Esse modelo pode ser usado para executar qualquer variedade de jobs. Ele é escalonado para centenas de instâncias em minutos, basta solicitar os nós no Slurm.
Se quiser continuar aprendendo a usar o Slurm no GCP, continue com o " Como criar clusters federados de HPC com o Slurm" o codelab. Este codelab vai orientar você na configuração de dois clusters federados do Slurm na nuvem, para representar como é possível alcançar uma federação de vários clusters, seja no local ou na nuvem.
Você está criando algo legal usando a nova funcionalidade nativa do GCP do Slurm? Dúvidas? Tem uma sugestão de recurso? Entre em contato com a equipe do Google Cloud hoje mesmo pelo site de soluções de computação de alto desempenho do Google Cloud ou fale conosco na Central de Ajuda do Grupo de discussão do Slurm!
Limpar a implantação do Terraform
Saia do nó do slurm:
exit
Permita que os nós com escalonamento automático sejam reduzidos antes de excluir a implantação. Também é possível excluir esses nós manualmente executando "gcloud compute instances delete <Nome da instância>" para cada instância ou usando a GUI do console para selecionar vários nós e clicar em "Excluir".
Para limpar facilmente a implantação do Terraform depois que terminarmos, execute o seguinte comando no Google Cloud Shell após sair de g1-login0:
cd ~/slurm-gcp/tf/examples/basic terraform destroy -var-file=basic.tfvars
Quando solicitado, digite yes para continuar. Essa operação pode levar alguns minutos.
Excluir o projeto
Para fazer a limpeza, basta excluir o projeto.
- No menu de navegação, selecione IAM & Administrador
- Em seguida, clique em "Configurações" no submenu.
- Clique no ícone de lixeira com o texto "Delete Project" (Excluir projeto).
- Siga as instruções dos comandos.
O que aprendemos
- Como implantar o Slurm no GCP com o Terraform.
- Como executar um job usando o Slurm no GCP.
- Como consultar informações do cluster e monitorar jobs em execução no Slurm.
- Como fazer o escalonamento automático de nós com o Slurm no GCP para acomodar requisitos e parâmetros de job específicos.
- Como compilar e executar aplicativos MPI no Slurm no GCP.
Encontrar suporte do Slurm
Se você precisar de suporte para usar essas integrações em ambientes de teste ou produção, entre em contato diretamente com a SchedMD pela página de contato: https://www.schedmd.com/contact.php
Você também pode usar os guias de solução de problemas disponíveis:
- Guia de solução de problemas do Slurm no GCP: https://github.com/SchedMD/slurm-gcp#troubleshooting
- Guia de solução de problemas da SchedMD: https://slurm.schedmd.com/troubleshoot.html
Por fim, também é possível publicar sua pergunta no Grupo de discussão do Slurm encontrado aqui: https://groups.google.com/g/google-cloud-slurm-discuss
Saiba mais
Feedback
Use este link para enviar feedback sobre este codelab. O feedback leva menos de cinco minutos. Obrigada!