Parque Computacional de Alto Desempenho (PCAD)

Índice

Índice

1. Apresentação

O Parque Computacional de Alto Desempenho (PCAD) é uma infraestrutura computacional utilizada por diferentes grupos de pesquisa em computação e áreas correlatadas. Ele consiste em um conjunto de nós computacionais (servidores) interligados e que podem ser utilizados conjuntamente para a execução de aplicações paralelas de maior porte. Os recursos são acessados via acesso remoto por um portal que ordena os pedidos de utilização. Nenhum usuário tem acesso físico a sala onde os recursos se encontram.

2. Características técnicas

O PCAD possui um nó computacional físico que serve como portal, que pode ser visto como o front-end que centraliza os logins de usuários e permite a alocação de recursos. No front-end estão centralizados também o /home de cada usuário. Os recursos que podem ser alocados a partir do front-end são representados por um conjunto de nós computacionais para execução de aplicações paralelas. Cada nó computacional possui armazenamento local temporário. Estas características são detalhadas a seguir.

2.1. Detalhamento técnico

O PCAD possui mais de 1.000 núcleos de CPU e 100.000 de GPU (CUDA threads), distribuídos em 40 nós computacionais. Pode-se compreender um nó como sendo um conjunto de processamento com configurações específicas. Por exemplo, cada nó possui uma determinada quantidade de um processador específico, uma quantidade específica de memória RAM por processador, uma GPU específica, agrupados no que chamamos de rack. Desse modo, temos diferentes nós de computação que apresentam diferentes características e configurações. O usuário pode escolher entre os diversos nós de acordo com sua necessidade específica. Por exemplo, para executar uma aplicação de IA, o usuário escolheria o nó hype, devido à presença de uma GPU NVIDIA Tesla K80, enquanto que para uma aplicação que execute exclusivamente em CPU, pode-se fazer uso de um nó sem GPU.

Já partições representam a forma como esses nós estão organizados. Como pode-se ter mais de um nó com as mesmas características, dizemos que os nós que possuem as mesmas características fazem parte de uma partição. Como exemplo temos os 7 nós draco, que são 7 máquinas com as mesmas características agrupados sob a partição draco.

Os nós existentes no PCAD são detalhados a seguir:

Nome Partição CPU Memória RAM Disco Acelerador
gppd-hpc - 2 x Intel Xeon E5-2630 Sandy Bridge (Q1'12), 2.3 GHz, 24 threads, 12 núcleos 16 GB DDR3 2 TB HDD RAID 1 (/ sistema) -
gppd-hpc2 - 2 x Intel Xeon E5-2630 Sandy Bridge (Q1'12), 2.3 GHz, 24 threads, 12 núcleos 32 GB DDR3 480 GB SSD RAID 1 (/sistema)
73 TB HDD NFS (/home de todos nós)
-
draco[1-6] draco 2 x Intel Xeon E5-2640 v2 Ivy Bridge (Q3'13), 2.0 GHz, 32 threads, 16 núcleos 64 GB DDR3 TODO 1 x NVIDIA Tesla K20m, Kepler, 2496 CUDA cores
draco7 draco 2 x Intel Xeon E5-2640 v2 Ivy Bridge (Q3'13), 2.0 GHz, 32 threads, 16 núcleos 128 GB DDR3 TODO 2 x NVIDIA Tesla K20m, Kepler, 2 x 2496 CUDA cores
hype[1-3] hype 2 x Intel Xeon E5-2650 v3 Haswell (Q3'14), 2.3 GHz, 40 threads, 20 núcleos 128 GB DDR4 TODO -
hype[4-5] hype 2 x Intel Xeon E5-2650 v3 Haswell (Q3'14), 2.3 GHz, 40 threads, 20 núcleos 128 GB DDR4 TODO 2 x NVIDIA Tesla K80, Kepler, 2x 4992 CUDA Thread
sirius sirius 1 x AMD Ryzen 9 3950X Zen2 (Q3'19), 3.5 GHz, 32 threads, 16 núcleos 64 GB DDR4 TODO TODO:Intel
apolo apolo * 1 x AMD RYZEN 5 3400G Zen+ (Q2'19), 3.7 GHz, 8 threads, 4 núcleos 64 GB DDR4 TODO 1 X AMD Radeon Vega 11, GCN 5th gen, 11 cores
tsubasa tsubasa * 2 x Intel Xeon Gold 6226 Cascade Lake (Q2'19), 2.7 GHz, 48 threads, 24 núcleos 192 GB DDR4 TODO 4 x NEC TSUBASA Vector Engine Type 10BE, SX-Aurora
cidia cidia * 2 x Intel Xeon Silver 4208 Cascade Lake (Q2'19), 2.1 GHz, 32 threads, 16 núcleos 320 GB DDR4 TODO 2 x NVIDIA GeForce RTX 2080Ti, 2 x 4352 CUDA cores
cei[1-2] cei 2 x Intel Xeon Silver 4116 Skylake (Q3'17), 2.1 GHz, 48 threads, 24 núcleos 6 GB DDR4 TODO -
knl[1-4] knl Intel Xeon Phi 7250 Knights Landing (Q2'16), 1.4 GHz, 68 threads, 68 núcleos1 96 GB DDR4 RAM
16 GB HBM MCDRAM
TODO -
blaise blaise * 2 x Intel Xeon E5-2699 v4 Broadwell (Q1'16), 2.2 GHz, 88 threads, 44 núcleos 256 GB DDR4 TODO 4 x NVIDIA Tesla P100, Pascal, 4 x 3584 CUDA cores
tupi1 tupi Intel Xeon E5-2620 v4 Broadwell (Q1'16), 2.1 GHz, 16 threads, 8 núcleos 64 GB DDR4 RAM TODO 1 x NVIDIA RTX 4090, Ada, 16384 CUDA cores
tupi2 tupi Intel Xeon E5-2620 v4 Broadwell (Q1'16), 2.1 GHz, 16 threads, 8 núcleos 80 GB DDR4 RAM TODO 1 x NVIDIA RTX 4090, Ada, 16384 CUDA cores
tupi[3-4] tupi Intel i9-14900KF (Q4'23), 3.2 GHz, 32 threads, 16 núcleos + 8 núcleos 64 GB DDR4 RAM TODO 1 x NVIDIA RTX 4090, Ada, 16384 CUDA cores
saude saude * Intel Xeon E5-2620 v4 Broadwell (Q1'16), 2.1 GHz, 16 threads, 8 núcleos 128 GB DDR4 TODO 4 x NVIDIA GeForce GTX 1080Ti, 4 x 3584 CUDA cores
orion2 orion 2 x Intel Xeon E5-2630 Sandy Bridge (Q1'12), 2.3 GHz, 48 threads, 24 núcleos 48 GB DDR3 RAM TODO 1 x NVIDIA Tesla K20m, Kepler, 2496 CUDA cores
bali1 bali 2 x Intel Xeon E5-2650 Sandy Bridge (Q1'12), 2.0 GHz, 64 threads, 32 núcleos 32 GB DDR3 TODO 3 x NVIDIA Tesla K20m, Kepler, 3 x 2496 CUDA cores
bali2 bali 2 x Intel Xeon E5-2650 Sandy Bridge (Q1'12), 2.0 GHz, 64 threads, 32 núcleos 32 GB DDR3 TODO -
beagle beagle 2 x Intel Xeon E5-2650 Sandy Bridge (Q1'12), 2.0 GHz, 32 threads, 16 núcleos 32 GB DDR3 TODO 2 x NVIDIA GeForce GTX 1080Ti, 2 x 3584 CUDA cores
turing turing 4 x Intel Xeon X7550 Nehalem (Q1'10), 2.0 GHz, 64 threads, 32 núcleos 128 GB DDR3 TODO -
phoenix phoenix 2 × Intel(R) Xeon(R) Gold 5317 (Q2'21), 3.00 GHz, 48 threads, 24 núcleos 128 GB DDR4 SSD 256 GB -
marcs marcs * 1 × Intel Core i7-10700F 2.90 GHz (Q2'20), 2.90 GHz, 16 threads, 8 núcleos 64 GB DDR4 SSD/M2 Kingston 250GB, HDD 2TB 1 × GeForce RTX 3090 Ti Gamerock 24GB GDDR6X
viking1 viking 2 x Intel Xeon E5530 Nehalem (Q1'09), 2.4 GHz, 80 threads, 40 núcleos 24 GB DDR3 RAM TODO -
  • * Partições com máquinas de projetos que requerem permissão do coordenador do projeto

2.2. Armazenamento

Os arquivos de cada usuário estão armazenados no front-end e são acessados pelos nós de computação através de Network File System (NFS). De maneira transparente, o NFS monta os dados do usuário na partição que foi alocada e o usuário acessa os dados como se eles estivessem armazenados localmente. Assim, o /home de cada usuário é acessível a partir de cada nó de computação.

Usuários podem executar aplicações que leem e escrevem dados diretamente na sua /home física, ou seja, no front-end. No entanto, essas operações serão feitas pela rede, o que as torna lentas. O ideal, portanto, é utilizar o scratch, que está localizado no o disco local fisicamente ligado ao nó computacional.

O scratch é um diretório temporário presente em cada nó de computação e montado no sistema de arquivos próprio do nó. Cada usuário possui um diretório dentro do scratch (/scratch/USERNAME). A variável de ambiente $SCRATCH é configurada automaticamente no momento do login. Desse modo, para acessar seu diretório scratch, basta acessar $SCRATCH:

cd $SCRATCH

Antes da execução da aplicação, o usuário pode copiar os dados do seu /home no NFS para o seu scratch, acessando as variáveis $HOME e $SCRATCH:

cp $HOME/<diretório_origem> $SCRATCH/<diretório_destino>

No entanto, os dados são mantidos temporariamente no scratch do nó e não podem ser acessados diretamente por outros nós de computação. Desse modo, o usuário precisa copiar os dados para o seu home ao final da execução do job:

cp $SCRATCH/<diretório_origem> $HOME/<diretório_destino>

IMPORTANTE: os arquivos presentes no scratch são temporários e podem ser removidos a qualquer momento sem aviso prévio aos usuários. Por isso se sugere que, assim que um job termine sua execução, os dados relevantes sejam transferidos para a área de armazenamento do /home.

SUPER IMPORTANTE: os dados na home e no scratch não possuem backup sendo o usuário o responsável por manter seus backups. Usuários podem copiar seus arquivos de e para o PCAD usando o "scp" do ssh.

Da máquina pessoal para o PCAD (a partir da máquina pessoal):

scp <diretório_origem> <usuario_no_pcad>@gppd-hpc.inf.ufrgs.br:~/<diretório_destino>

Do PCAD para a máquina pessoal (a partir do PCAD):

scp <diretório_origem> <usuario_na_sua_maquina>@<maquina_pessoal>:~/<diretório_destino>

3. Acesso e submissão

  • O Sistema Operacional do PCAD é o Ubuntu 18.04.4 LTS
  • O acesso ao PCAD deve ser feito por meio de SSH através do host gppd-hpc.inf.ufrgs.br
ssh <usuario_no_pcad>@gppd-hpc.inf.ufrgs.br
  • A submissão dos jobs deve ser feita através do gerenciador de recursos e filas Slurm

4. Gerenciador de filas

O gerenciador de filas utilizado é o Slurm v20.02. Todos os jobs devem ser submetidos através do Slurm. Utilize os comandos sinfo e sin para listar informações sobre as filas, partições e nós. Utilize o comando squeue para listar informações sobre os jobs e o escalonamento.

  • As filas de execução (partições) do Slurm são:
    • shared: beagle, bali1, orion[1-2], draco[1-7]
    • apolo: apolo
    • beagle: beagle
    • blaise: blaise
    • cei: cei[1-2]
    • cidia: cidia
    • draco: draco[1-7]
    • greencloud: bali2
    • hype: hype[1-5]
    • knl: knl[1-4]
    • orion: orion[1-2]
    • saude: saude
    • sirius: sirius
    • tsubasa: tsubasa
    • tupi: tupi[1-2]
    • turing: turing
  • O tempo máximo de alocação é de 24h.
  • A fila shared permite o uso parcial do nó, compartilhando o uso com outros usuários.
  • As filas cei, cidia, greencloud, saude e tsubasa são exclusivas de projetos.
  • Deve-se ter o cuidado para ajustar corretamente o tempo de duração do job de acordo com as necessidades, para que o nó não fique alocado sem uso ou seja cancelado por ultrapassar o limite de tempo de execução.

5. Submeter Jobs

5.1. Jobs Interativos (salloc)

Para submeter jobs interativos, é necessário utilizar o comando salloc, solicitando os recursos a serem utilizados. Quando o salloc consegue alocar os recursos solicitados para o job, ele informa ao usuário, o qual pode acessar o nó (via ssh), realizar as suas tarefas localmente e executar a aplicação.

  • Exemplo 1

Solicita a alocação de qualquer nó da partição draco por 5h.

salloc -p draco -J NOME-JOB-EX1 -t 05:00:00
  • Exemplo 2

Solicita a alocação da draco6 por 36h.

salloc -p draco -w draco6 -J NOME-JOB-EX2 -t 36:00:00
  • Exemplo 3

Solicita a alocação de dois nós da partição hype por 24h.

salloc -p hype -N 2 -J NOME-JOB-EX3 -t 24:00:00
  • Exemplo 4

Solicita a alocação de 6 núcleos da partição shared por 1h. O uso do nó é compartilhado com outros usuários, entretanto, os núcleos solicitados são dedicados.

salloc -p shared -c 6 -J NOME-JOB-EX4 -t 1:00:00

5.2. Jobs Não-Interativos (sbatch)

Jobs não interativos são aqueles onde o usuário submete um script que realiza o experimento nas máquinas. O slurm permite esse tipo de script utilizando diretivas em linhas que começam com #SBATCH. Todas as linhas que começam com esta diretiva terão seu conteúdo passado diretamente para o slurm no momento da alocação. O exemplo 1 abaixo aloca um nó (--nodes=1) para 16 tarefas (--ntasks=16) na partição draco (--partition=draco) por 2 horas (--time=02:00:00). Recomenda-se o uso de parâmetros --output e --error de forma que a saída padrão e de erro sejam direcionadas para arquivos, permitindo o debug do job. No caso de exemplo, esses arquivos serão o nome do job (%x, no caso o nome do arquivo que contém o script) e o seu ID (%j). As linhas que não contém a diretiva do sbatch serão executadas normalmente.

  • Exemplo 1

No exemplo abaixo, o comando hostname é executado.

#!/bin/bash
#SBATCH --job-name=exemplo1
#SBATCH --partition=draco
#SBATCH --nodes=1
#SBATCH --ntasks=16
#SBATCH --time=02:00:00
#SBATCH --output=%x_%j.out
#SBATCH --error=%x_%j.err

hostname

Assumindo que o conteúdo acima está em um arquivo draco.slurm, basta submeter o job da seguinte maneira na portal:

sbatch draco.slurm
  • Exemplo 2

No exemplo abaixo, um aplicação é executada em 7 nós da partição draco.

#!/bin/bash
#SBATCH --job-name=exemplo2
#SBATCH --partition=draco
#SBATCH --nodes=7
#SBATCH --ntasks=224
#SBATCH --time=6:00:00
#SBATCH --output=%x_%j.out
#SBATCH --error=%x_%j.err

mpicc exemplo2.c

MACHINEFILE="nodes.$SLURM_JOB_ID"
srun -l hostname | sort -n | awk '{print $2}' > $MACHINEFILE

mpirun --mca btl ^openib --mca btl_tcp_if_include eno1 --bind-to none -np $SLURM_NTASKS -machinefile $MACHINEFILE ./a.out

Assumindo que o conteúdo acima está em um arquivo draco_multi.slurm, basta submeter o job da seguinte maneira na portal:

sbatch draco_multi.slurm
  • Exemplo 3

No exemplo abaixo, um aplicação é executada em 2 nós da partição hype.

#!/bin/bash
#SBATCH --job-name=exemplo3
#SBATCH --partition=hype
#SBATCH --nodes=2
#SBATCH --ntasks=80
#SBATCH --time=2:00:00
#SBATCH --output=%x_%j.out
#SBATCH --error=%x_%j.err

mpicc exemplo3.c

MACHINEFILE="nodes.$SLURM_JOB_ID"
srun -l hostname | sort -n | awk '{print $2}' > $MACHINEFILE

mpirun --mca oob_tcp_if_include 192.168.30.0/24 --mca btl_tcp_if_include 192.168.30.0/24 --mca btl_base_warn_component_unused 0 --bind-to none -np $SLURM_NTASKS -machinefile $MACHINEFILE ./a.out

Assumindo que o conteúdo acima está em um arquivo hype.slurm, basta submeter o job da seguinte maneira na portal:

sbatch hype.slurm

5.3. Jobs com múltiplos nós não-interativos (sbatch)

Uma forma muito frequente de uso de um cluster de computadores é o emprego de múltiplas máquinas (nós) para executar a mesma aplicação com emprego de MPI. Assumindo um programa MPI simples do tipo "Olá Mundo" com o seguinte conteúdo no arquivo olamundo.c:

#include <mpi.h>
#include <stdio.h>
#include <unistd.h>
int main(int argc, char **argv)
{
  int rank;
  char hostname[256];
  MPI_Init(&argc,&argv);
  MPI_Comm_rank(MPI_COMM_WORLD, &rank);
  gethostname(hostname,255);
  printf("Olá Mundo!  Eu sou [%d] executando em [%s].\n", rank, hostname);
  MPI_Finalize();
  return 0;
}

Compile-o com mpicc:

mpicc olamundo.c -o olamundo

Construa um script slurm chamado multi-no.slurm com o conteúdo abaixo. Serão alocados 5 nós com 80 tarefas na partição draco por 2 horas. O primeiro comando srun criará um arquivo de máquinas para a execução do programa MPI. Cada linha desta arquivo conterá o nome do nó onde será executada a aplicação MPI; como existem múltiplos cores, o nome do nó será repetido várias vezes.

#!/bin/bash
#SBATCH --job-name=exemplo
#SBATCH --partition=draco
#SBATCH --nodes=5
#SBATCH --ntasks=80
#SBATCH --time=2:00:00
#SBATCH --output=%x_%j.out
#SBATCH --error=%x_%j.err

MACHINEFILE="nodes.$SLURM_JOB_ID"
srun -l hostname | sort -n | awk '{print $2}' > $MACHINEFILE

mpirun -np $SLURM_NTASKS \
       -machinefile $MACHINEFILE \
       --mca btl ^openib \
       --mca btl_tcp_if_include eno2 \
       --bind-to none -np $SLURM_NTASKS \
       ./olamundo

Assumindo que o programa olamundo foi compilado na $HOME do usuário e que o script abaixo se encontra no mesmo local, basta submeter o job da maneira habitual:

sbatch multi-no.slurm

5.4. Jobs multi-partição não-interativo (sbatch)

O slurm permite a criação de jobs multi-partição, para o caso onde o usuário deseja usar nós heterogêneos de partições diferentes. A documentação do slurm sobre jobs heterogêneos apresenta um detalhamento bastante rico sobre o assunto. Abaixo apresentamos um exemplo simples para a aplicação do tipo "Olá Mundo!", compilada no binário olamundo.

Crie um arquivo multi-particao.slurm com o conteúdo abaixo. Solicitaremos nós de três partições (5 nós da hype, cada um com 20 tarefas; 5 nós da draco, cada um com 16 tarefas, e o único nó da partição turing, com 32 tarefas). A diretiva packjob deve ser obrigatoriamente empregada para separar os comandos de alocação para cada partição. Como o programa MPI precisa de um arquivo de máquinas de todo o conjunto, incluímos a função shell gen_machinefile que imprime as nós alocados de uma partição de acordo com a quantidade de tarefas alocadas naquele nó. Essa função é chamada para cada uma das partições que foram alocadas, e toda a saída é direcionada para o arquivo de máquinas (variável MACHINEFILE)

#SBATCH --time=02:00:00
#SBATCH --output=%x_%j.out
#SBATCH --error=%x_%j.err
#SBATCH --nodes=5 --partition=hype --ntasks=20
#SBATCH packjob
#SBATCH --nodes=5 --partition=draco --ntasks=16
#SBATCH packjob
#SBATCH --nodes=1 --partition=turing --ntasks=32

# Função para gerar um arquivo de máquina para uma partição
function gen_machinefile {
        SLM_NODES=$1
        SLM_TASKS=$2

        if [ -z "$SLM_NODES" ]; then
                return
        fi

        for host in $(scontrol show hostname $SLM_NODES); do
                for machine in $(seq 1 $SLM_TASKS); do
                        echo $host
                done
        done
}
# Três partições foram alocadas, portanto três chamadas a gen_machinefile
MACHINEFILE="nodes.$SLURM_JOB_ID"
gen_machinefile $SLURM_JOB_NODELIST_PACK_GROUP_0 $SLURM_NPROCS_PACK_GROUP_0 > $MACHINEFILE
gen_machinefile $SLURM_JOB_NODELIST_PACK_GROUP_1 $SLURM_NPROCS_PACK_GROUP_1 >> $MACHINEFILE
gen_machinefile $SLURM_JOB_NODELIST_PACK_GROUP_2 $SLURM_NPROCS_PACK_GROUP_2 >> $MACHINEFILE

# Definir a quantidade de máquinas baseado no arquivo
SLM_NTASKS=$(wc -l $MACHINEFILE | awk '{ print $1 }')

# Executar a aplicação
mpirun -np $SLM_NTASKS \
       -machinefile $MACHINEFILE \
       --mca oob_tcp_if_include 192.168.30.0/24 \
       --mca btl_tcp_if_include 192.168.30.0/24 \
       --mca btl_base_warn_component_unused 0 \
       --bind-to none \
       ./olamundo

5.5. Remover jobs da fila ou em execução

Pelo número do job

scancel NUMERO-DO-JOB

Todos jobs do usuário

scancel -u NOME-DO-USUARIO

6. Comandos especiais e administrativos

Algumas propriedades das máquinas podem ser alteradas pelo usuário sem permissões administrativas, e são resetadas no inicio de cada alocação.

6.1. Controle de CPU

A frequência e governor podem ser alterados por qualquer usuário utilizando o comando cpu-freq.

O turbobost pode ser alterado editando diretamente o arquivo: /sys/devices/system/cpu/cpufreq/boost.

6.2. Configurações do Kernel

O Numa balancing pode ser ativado ou desativado utilizando os comandos (com sudo):

sudo /sbin/sysctl kernel.numa_balancing=1
sudo /sbin/sysctl kernel.numa_balancing=0

6.3. Frequência GPU

A frequência da GPU (MEM, GRAPHICS) pode ser configurada utilizando o comando:

gpu_control 715 1480

Esta é a saída do comando acima na máquina blaise.

Executing command [nvidia-smi -ac 715,1480]
Applications clocks set to "(MEM 715, SM 1480)" for GPU 00000000:05:00.0
Applications clocks set to "(MEM 715, SM 1480)" for GPU 00000000:06:00.0
Applications clocks set to "(MEM 715, SM 1480)" for GPU 00000000:84:00.0
Applications clocks set to "(MEM 715, SM 1480)" for GPU 00000000:85:00.0
All done.

7. Referenciando o PCAD

Todos os trabalhos que apresentarem resultados no qual utilizarem recursos do PCAD, devem fazer menção aos projetos individuais das máquinas ou referenciar o PCAD. Sugerimos a seguinte mensagem:

Alguns experimentos deste trabalho utilizaram os recursos da infraestrutura PCAD, http://gppd-hpc.inf.ufrgs.br, no INF/UFRGS.

Em inglês:

Some experiments in this work used the PCAD infrastructure, http://gppd-hpc.inf.ufrgs.br, at INF/UFRGS.

8. Equipe e Contato

Coordenador do PCAD: Prof. Lucas Mello Schnorr.

Os membros atuantes com contribuições extremamente importantes:

Ex-membros atuantes com contribuições extremamente importantes:

Os usuários podem solicitar ajuda para problemas ou apresentar demandas de instalação/configuração através da lista de difusão (lembrando que o cadastro do e-mail do usuário ocorre no momento da criação da sua conta):

hpc-users-l@inf.ufrgs.br

Notas de Rodapé:

1

Arquitetura especial e descontinuada da Intel, requer considerações especiais.

Author: Administração do PCAD (schnorr@inf.ufrgs.br)

Date: Janeiro 2024

Emacs 28.2 (Org mode 9.6.21)

Validate