1. Visão geral
Bem-vindo ao codelab do Google para executar um cluster Slurm no Google Cloud Platform. Ao final deste codelab, você vai entender bem como é fácil provisionar e operar 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 o lançamento do gerenciador de carga de trabalho Slurm no Compute Engine e a expansão dinâmica do cluster atual 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 tiver dúvidas, participe do grupo de discussão da comunidade do Google Cloud e do Slurm.
Sobre o Slurm
Diagrama arquitetônico básico de um cluster do Slurm independente no Google Cloud Platform.
O Slurm é um dos principais gerenciadores de carga de trabalho para clusters de HPC em todo o mundo. O Slurm oferece um sistema de gerenciamento de cargas de trabalho e agendamento de jobs de código aberto, tolerante a falhas e altamente escalonável para clusters Linux de pequeno e grande porte. O Slurm não exige modificações no kernel para funcionar e é relativamente independente. Como gerenciador de carga de trabalho do cluster, o Slurm tem três funções principais:
- Ele aloca acesso exclusivo ou não exclusivo a recursos (nós de computação) para os usuários por um período de tempo para que eles possam trabalhar.
- Ele fornece uma estrutura para iniciar, executar e monitorar o trabalho (normalmente um job paralelo) no conjunto de nós alocados.
- Ele arbitra a disputa por recursos gerenciando uma fila de trabalho pendente.
O que você vai aprender
- Como configurar um cluster do Slurm usando o Terraform
- Como executar um job usando o SLURM
- Como consultar informações do cluster e monitorar jobs em execução no SLURM
- Como escalonar automaticamente os nós para acomodar parâmetros e requisitos específicos do job
- Onde encontrar ajuda com o Slurm
Pré-requisitos
- Conta e projeto do Google Cloud Platform com faturamento
- Experiência básica com Linux
2. Configuração
Configuração de ambiente autoguiada
Criar um projeto
Se você ainda não tem 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 um nome de projeto. Guarde o 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 do projeto aleatório com base no nome do projeto.
Em seguida, será necessário 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 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 neste link.
Novos usuários do Google Cloud Platform estão qualificados para uma avaliação sem custo financeiro de US$300.
Google Cloud Shell
Embora o Google Cloud possa ser operado remotamente em seu laptop, neste codelab vamos usar o Google Cloud Shell, um ambiente de linha de comando executado no Cloud.
Iniciar o Google Cloud Shell
No Console do GCP, clique no ícone do Cloud Shell na barra de ferramentas localizada no canto superior direito:
Em seguida, 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 persistente de 5 GB, além de ser executada no Google Cloud. Isso aprimora o desempenho da rede e simplifica a autenticação. Praticamente todo o trabalho neste laboratório pode ser feito em um navegador da Web ou em um Google Chromebook.
Depois de se conectar ao Cloud Shell, você vai ver que sua conta já está autenticada e que o projeto está 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, use este comando:
$ gcloud config set project <PROJECT_ID>
Saída de comando:
Updated property [core/project].
3. Preparar e revisar a configuração do Terraform do Slurm
Fazer o download da configuração do Terraform do Slurm
Na sessão do Cloud Shell, execute o comando a seguir para clonar (fazer o download) o repositório Git que contém os arquivos do Terraform do Slurm para o Google Cloud Platform:
git clone https://github.com/SchedMD/slurm-gcp.git
Mude para o diretório de configuração de implantação do Slurm executando o seguinte comando:
cd slurm-gcp
Configurar tfvars do Terraform do Slurm
O arquivo basic.tfvars.example detalha a configuração da implantação, incluindo a rede, as instâncias e o armazenamento a serem implantados. Copie para um novo arquivo, que vamos chamar de "arquivo tfvars", e 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. É possível usar o editor de linha de comando que preferir (vi, nano, emacs etc.) ou o editor de código do console do Cloud para ver o conteúdo do arquivo:
Analise 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"
]
Nesse arquivo tfvars, há vários campos para configurar. O único campo que precisa ser configurado é o project. Todas as outras configurações no exemplo podem ser usadas no estado em que se encontram, mas modifique-as conforme necessário para sua situação. Para uma descrição mais detalhada das opções de configuração, consulte este link.
- cluster_name::nome do cluster do Slurm
- project: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 em que o cluster do Slurm será implantado
- subnetwork_name: Sub-rede de nuvem privada virtual para implantar o cluster do Slurm.
- shared_vpc_host_project: : rede VPC compartilhada para implantar o cluster do Slurm.
- disable_controller_public_ips::atribuir IP externo ao controlador do Slurm?
- disable_login_public_ips::atribuir IP externo ao nó de login do Slurm?
- disable_compute_login_ips::atribuir IP externo ao nó de login do Slurm?
- suspend_time::tempo de espera após um nó ficar inativo antes de ser suspenso.
- 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::tamanho do disco de inicialização de uma instância de 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 Google CloudSQL a ser usado como banco de dados do Slurm em vez de hospedar um banco de dados na instância do controlador.
- server_ip::IP do servidor do Cloud SQL
- user:nome de usuário do CloudSQL
- password:senha do CloudSQL
- db_name::nome do banco de dados do CloudSQL
- controller_secondary_disk::quer 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 para a instância do controlador. Todos os campos de computação especificados vão substituir as propriedades do modelo. Por exemplo, se controller_image for especificado, ele vai 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 para a instância de login. Todos os campos de computação especificados vão substituir as propriedades do modelo. Por exemplo, se login_image for especificado, ele vai substituir a imagem no modelo de instância.
- network_storage::armazenamento de rede a ser montado 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 de sistema de arquivos (NFS, CIFS, Lustre, GCSFuse instalado automaticamente)
- mount_options::opções de ativação (por exemplo, defaults,_netdev)
- login_network_storage::armazenamento de rede para montagem em nós de login e controlador. O NFS, o CIFS, o Lustre e o 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 de sistema de arquivos (NFS, CIFS, Lustre, GCSFuse instalado automaticamente)
- mount_options::opções de ativação (por exemplo, defaults,_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 da 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 ativos.
- max_node_count::número máximo de nós de computação totais permitidos (máximo de 64 mil)
- zone:zona do Google Cloud que vai conter os recursos dessa partição. Mais informações
- image:tipo de máquina do nó de imagem do Compute
- image_hyperthreads::ativa ou desativa o hyperthreading na instância.
- compute_disk_type: tipo de um disco de inicialização de instância de computação (pd-standard, pd-ssd)
- compute_disk_size_gb::tamanho de um disco de inicialização de instância de computação
- compute_labels::rótulos a serem anexados à instância de computação.
- cpu_platform::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 de sistema de arquivos (NFS, CIFS, Lustre, GCSFuse instalado automaticamente)
- mount_options::opção de montagem
- preemptible_bursting::as instâncias serão preemptivas?
- vpc_subnet: : sub-rede de nuvem privada virtual para implantar a partição do Slurm.
- exclusive:permite que o Slurm aloque nós inteiros para jobs.
- enable_placement::ativa as políticas de posicionamento em que as instâncias ficam próximas umas das outras para reduzir a latência de rede entre elas.
- regional_capacity::permite que uma instância seja colocada em qualquer zona da região com base na disponibilidade.
- regional_policy::se regional_capacity for verdadeiro, essa política vai determinar qual região usar e quais zonas dessa região não usar.
- Instance_template::o modelo de instância do GCP a ser usado para instâncias de computação. Todos os campos de computação especificados vão substituir as propriedades do modelo. Por exemplo, se a imagem for especificada, ela vai 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, conforme descrito em "Como instalar apps em um cluster do Slurm no Compute Engine" ou personalizando a imagem implantada pelo Slurm. No momento, o Slurm implanta uma imagem de VM fornecida pela SchedMD baseada na imagem de VM de HPC do Google Cloud, com o Slurm instalado nela.
Para usar sua própria imagem, crie uma com sua configuração com base na imagem pública da VM SchedMD listada no arquivo tfvars. Em seguida, substitua o URI da imagem especificado no arquivo tfvars pela sua própria imagem e teste a mudança.
Solução de problemas
Durante este codelab, consulte a seção de solução de problemas do LEIAME do repositório Slurm-GCP.
Os problemas mais comuns são erros na configuração do arquivo tfvars e restrições de cota. Este codelab foi projetado para ser executado na cota padrão de um novo usuário e no crédito sem custo financeiro de US $300 que ele 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 seguinte comando na pasta slurm-gcp/tf/example:
terraform init terraform apply -var-file=basic.tfvars
Você vai precisar aceitar as ações descritas com base nas configurações definidas. Digite yes para iniciar a implantação. Você também pode conferir a configuração a ser implantada executando "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. Aguarde.
Quando a implantação for concluída, você verá uma saída semelhante a esta:
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.
Um controlador e uma instância de VM de login vão aparecer:
Em Instâncias de VM, revise as duas instâncias de máquina virtual criadas pelo Terraform.
Os nomes serão diferentes se você tiver modificado o campo cluster_name.
- g1-controller
- g1-login0
5. Fazer login no cluster do Slurm
Acessar o cluster do Slurm
Volte para a guia do editor de código/Cloud Shell. 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 é clicar 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 for a primeira vez que você usa o Cloud Shell, talvez apareça uma mensagem como a abaixo pedindo para criar 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 solicitado a selecionar uma senha longa, deixe em branco pressionando Enter duas vezes.
Se a seguinte mensagem aparecer ao fazer 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 5 minutos):
*** Slurm login setup complete ***
Depois que a mensagem acima aparecer, saia e faça login novamente no g1-login0 para continuar o laboratório. Para isso, pressione CTRL + C para encerrar a tarefa.
Em seguida, execute o comando a seguir para sair 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 acima, talvez seja necessário aguardar um ou dois minutos antes de se conectar e concluir todos os aspectos da configuração.
Tour pelas ferramentas da CLI do Slurm
Agora você fez login no nó de login do Slurm do cluster. É o nó dedicado à interação do usuário/administrador, ao 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 conferir o status dos recursos do cluster:
sinfo
Confira abaixo um exemplo de saída do sinfo. Ele informa os nós disponíveis no cluster, o estado deles e outras informações, como a partição, a 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]
Os 10 nós, determinados pelo "max_node_count" de 10 da partição de depuração, estão marcados como "idle~" (o nó está em um modo ocioso e não alocado, pronto para ser ativado).
Em seguida, execute o comando squeue para conferir o status da fila do cluster:
squeue
A saída esperada do squeue aparece abaixo. O squeue informa o status da fila de um cluster. Isso inclui o ID de cada job programado no cluster, a partição a que o job está atribuído, o nome do job, o usuário que iniciou o job, o estado do job, o tempo de execução do job e os nós a que 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 "srun" e "sbatch" do Slurm são usados para executar jobs que são colocados na fila. O "srun" executa jobs paralelos e pode ser usado como um wrapper para o mpirun. "sbatch" é usado para enviar um job em lote ao slurm e pode chamar srun uma ou várias vezes em diferentes configurações. O "sbatch" pode usar scripts em lote ou ser usado 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 nossa fila.
6. Executar um job do Slurm e escalonar o cluster
Executar um job do Slurm e escalonar o cluster
Agora que o cluster Slurm está em execução, vamos executar um job e escalonar o cluster.
O comando "sbatch" é usado para executar comandos e scripts em lote do Slurm. Vamos executar um script sbatch simples que vai executar "hostname" nas nossas VMs com escalonamento automático.
Enquanto estiver conectado ao g1-login0, execute o seguinte comando:
sbatch -N2 --wrap="srun hostname"
Esse comando executa o comando em lote do Slurm. Ele especifica que o sbatch vai executar dois nós com a opção "-N". Ele também especifica que cada um desses nós vai executar um comando "srun hostname" na opção "–wrap".
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 código da tarefa 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 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 de trabalho 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 nas opções "network_storage".
Depois de executar o script sbatch usando a linha de comando sbatch, ele vai retornar um código da tarefa para o job programado. Por exemplo:
Submitted batch job 2
Podemos usar o código da tarefa retornado pelo comando sbatch para rastrear e gerenciar a execução da tarefa e os recursos. Execute o comando a seguir para conferir a fila de jobs do Slurm:
squeue
O job executado vai aparecer na lista, como abaixo:
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 nós de computação provisionados, 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 necessário 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. Em segundo lugar, ele permite que os usuários economizem dinheiro porque os nós ociosos 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 Slurm sendo iniciado:
sinfo
Isso vai mostrar os nós listados em squeue no estado "alloc#", ou seja, 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]
Você também pode 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 aos nós recém-alocados. Em breve, a lista de instâncias de VM será semelhante a esta:
Quando os nós estiverem executando o job, as instâncias vão mudar para o estado "alloc", 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]
Quando um job é concluído, ele não aparece mais no squeue, e os nós "alloc" no sinfo voltam ao estado "inativo". Execute "squeue" periodicamente até que o job seja concluído, após um ou dois minutos.
O arquivo de saída slurm-%j.out terá sido gravado na pasta /home compartilhada por NFS e vai conter os nomes de host. Abra ou use o comando "cat" no arquivo de saída (normalmente slurm-2.out). O conteúdo dele vai incluir:
g1-compute-0-0 g1-compute-0-1
Excelente trabalho! Você executou um job e escalonou seu cluster do Slurm.
7. Executar um job do MPI
Agora vamos executar um trabalho MPI nos nossos nós. Enquanto estiver conectado ao g1-login0, use o 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 do OpenMPI, carregue os módulos executando este comando:
module load openmpi
Vamos usar a ferramenta "mpicc" para compilar o código C do MPI. 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 todo o cluster usando o Slurm.
Em seguida, use o editor de texto de sua preferência para criar um script sbatch chamado helloworld_batch:
vi helloworld_batch
Digite i para entrar no modo de inserção do vi.
Copie e cole o texto a seguir 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 o ambiente e as tarefas de execução em lote do Slurm. Primeiro, o ambiente de execução é definido como bash. Em seguida, o script define as opções do Slurm primeiro com as linhas "#SBATCH". O nome do job é definido como "hello_world".
O arquivo de saída é definido como "hello_world_%j.out", em que %j é substituído pelo código da tarefa 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 sbatch é executado. No nosso exemplo, essa é 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 de trabalho 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 esse script será executado é definido como 2.
Depois que as opções são definidas, os comandos executáveis são fornecidos. Esse script vai executar o código mpi_hello_world de maneira paralela usando o comando srun, que é uma substituição direta do comando mpirun.
Em seguida, execute o script sbatch usando a linha de comando sbatch:
sbatch helloworld_batch
A execução de sbatch vai retornar um código da tarefa para o job programado, por exemplo:
Submitted batch job 3
Isso vai 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, esse job será executado rapidamente.
Monitore squeue até que o job seja concluído e não esteja mais listado:
squeue
Depois de concluído, abra ou mostre o arquivo hello_world-3.out e confirme que 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
Depois de ficarem inativos por cinco minutos (configuráveis com o campo "suspend_time" do YAML ou o campo "SuspendTime" do slurm.conf), os nós de computação provisionados dinamicamente serão desalocados para liberar recursos. Para validar isso, execute sinfo periodicamente e observe o tamanho do cluster voltar a 0:
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST debug* up infinite 10 idle~ g1-compute-0-[0-9]
Tente criar mais instâncias, até a cota permitida na região em que você implantou o cluster, e execute diferentes aplicativos MPI.
8. Conclusão
Parabéns! Você criou um cluster do Slurm no Google Cloud Platform e usou os recursos mais recentes dele para fazer o escalonamento automático do cluster e atender à demanda de carga de trabalho. É possível usar esse modelo para executar qualquer tipo de job, e ele é escalonado para centenas de instâncias em minutos apenas solicitando os nós no Slurm.
Se quiser continuar aprendendo a usar o Slurm no GCP, faça o codelab Como criar clusters federados de HPC com o Slurm. Neste codelab, vamos mostrar como configurar dois clusters federados do Slurm na nuvem para representar como você pode 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 converse com a gente no grupo de discussão do Google Cloud e do Slurm.
Limpar a implantação do Terraform
Faça logout do nó do Slurm:
exit
Permita que todos os nós com escalonamento automático reduzam escala vertical 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".
É fácil limpar a implantação do Terraform depois que terminarmos. Para isso, execute o seguinte comando no Google Cloud Shell depois de sair do 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 vários minutos. Aguarde.
Excluir o projeto
Para limpar, basta excluir o projeto.
- No menu de navegação, selecione "IAM e administrador".
- Em seguida, clique em "Configurações" no submenu.
- Clique no ícone da lixeira com o texto "Excluir projeto".
- Siga as instruções
O que aprendemos
- Como implantar o Slurm no GCP usando o Terraform.
- Como executar um job usando o Slurm no GCP.
- Como consultar informações de cluster e monitorar jobs em execução no Slurm.
- Como escalonar automaticamente nós com o Slurm no GCP para acomodar parâmetros e requisitos específicos do job.
- 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 na 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, você também pode postar sua dúvida no grupo de discussão do Google Cloud e do Slurm, disponível aqui: https://groups.google.com/g/google-cloud-slurm-discuss
Saiba mais
Feedback
Envie feedback sobre este codelab usando este link. O feedback leva menos de 5 minutos para ser concluído. Agradecemos pela atenção!