MANUAL RÁPIDO DE ACESSO E USO AO

CLUSTER COARACI
Sumário
-----------------------------------------------------------------------------------------------------------------------------------
Hardware: 1
Headnode 1
Login Node 1
Nós Computacionais 2
Transferência de arquivos: 3
Via SCP - usando o putty 3
Via WinSCP 5
Gerenciamento do cluster: 7
Submetendo seu job 7
Acompanhamento de job 8
-----------------------------------------------------------------------------------------------------------------------------------

Hardware:

Headnode
1 (um) servidor Dell EMC PowerEdge R6525 configurado com:
· 2 (dois) processadores AMD EPYC 7282;
· 256GB de memória DDR4;
· 2 (dois) SSDs de 480GB em RAID1;
· 2 (duas) portas Gigabit Ethernet;
· 2 (duas) portas Mellanox InfiniBand ConnectX.

Login Node
1 (um) servidor Dell EMC PowerEdge R6525 configurado com:
· 2 (dois) processadores AMD EPYC 7282;
· 64GB de memória DDR4;
· 2 (dois) SSDs de 480GB em RAID1;
· 2 (duas) portas Gigabit Ethernet;
· 2 (duas) portas Mellanox InfiniBand ConnectX.

Estrutura Computacional
PARALELA, SERIAL e PAR48
Tipo A) 256 (duzentos e cinquenta e seis) servidores Dell EMC PowerEdge C6525 configurados com:
· 2 (dois) processadores AMD EPYC 7402;
· 128GB de memória DDR4;
· 1 (um) SSD M.2 de 480GB;
· 1 (uma) porta Gigabit Ethernet;
· 1 (uma) porta Mellanox InfiniBand ConnectX.

GPU
Tipo B) 14 (quatorze) servidores Dell EMC PowerEdge R7525 configurados com:
· 2 (dois) processadores AMD EPYC 7402;
· 128GB de memória DDR4;
· 1 (um) SSD SATA de 480GB;
· 3 (três) GPUs NVIDIA A30;
· 2 (duas) portas Gigabit Ethernet;
· 1 (uma) porta Mellanox InfiniBand ConnectX.

FAT
Tipo C) 1 (um) servidor Dell EMC PowerEdge R6525 configurado com:
· 2 (dois) processadores AMD EPYC 7402;
- Nº de núcleos de CPU: 24 (cada processador)
- Nº de threads: 48 (cada processador)
· 2TB de memória DDR4;
· 4 (um) HDDs SATA de 12TB;
· 2 (duas) portas Gigabit Ethernet;
· 1 (uma) porta Mellanox InfiniBand ConnectX.

Tipo D) 1 (um) servidor Dell EMC PowerEdge R7525 configurado com:

· 1 (um) processador AMD EPYC 7282;
· 64GB de memória DDR4;
· 2 (dois) SSDs SATA de 480GB em RAID1;
· 1 (uma) GPU NVIDIA Tesla T4;
· 4 (quatro) portas Gigabit Ethernet;

Storage
2 (dois) servidores Dell EMC PowerEdge R7525 configurados com:
· 2 (dois) processadores AMD EPYC 7402;
· 256GB de memória DDR4;
· 2 (dois) SSDs de 480GB em RAID1;
· 4 (quatro) portas Gigabit Ethernet;
· 2 (duas) portas Mellanox InfiniBand ConnectX.
1 (um) Dell EMC PowerVault ME5084 configurado com:
· 80 (oitenta) HDDs NLSAS de 16TB;
· 4 (quatro) SSDs SAS de 3.84TB.
Nós Computacionais
Os nós deste cluster estão nomeados no formato “rXnXX”, onde rX corresponde ao rack que o nó se
encontra e o nXX seu número. Ex: “r1n01”
O cluster Coaraci possui 4 (quatro) tipos de nós listados abaixo (ver Nós Computacionais):

Transferência de arquivos:
Via SCP - usando o putty
Primeiramente temos que configurar o putty para fazer o scp via túnel.
● No menu do PuTTY, vá para Connection -> SSH -> Tunnels.
● Em "Source port", digite 50022 (ou qualquer porta não utilizada de sua escolha).
● Em "Destination", digite thiagorb@coaraci.ifi.unicamp.br:22 (substitua pelo seu nome de
usuário).
● Certifique-se de que a opção "Local" esteja selecionada e clique no botão "Add".

● Agora, clique em "Session" no menu à esquerda para voltar à tela principal do PuTTY.
● No campo "Host Name (or IP address)", digite thiagorb@gate.ifi.unicamp.br (substitua
thiagorb pelo seu nome de usuário no servidor gate).
● Certifique-se de que a porta SSH padrão 22 esteja configurada.
● `Preencha o campo Saved Sessions para salvar essa configuração para uso futuro
● Clique em Save; selecione o nome da sessão que você salvou (teste, nesse caso).
 ● Clique em "Open" para iniciar a conexão SSH com o servidor gate.

Digite a sua senha para entrar no gate do IFGW

Faça ssh para o cluster e digite a sua senha:

Uma vez dentro do seu diretório no COARACI já é possível fazer scp puxando arquivos de outros
lugares.

Abaixo temos um exemplo de transferência de dados via scp de dados que estão localizados em
um diretório do cluster KAHUNA que serão transferidos para o cluster COARACI. No caso, a
transferência é de um diretório inteiro com arquivos dentro. No terminal do COARACI, já no
diretório em que se deseja transferir os arquivos usar o seguinte comando:

Exemplo puxando um diretório inteiro:

scp -r tribas@kahuna.iqm.unicamp.br:~/meu/diretorio .

Exemplo puxando um arquivo do KAHUNA para o diretório do COARACI em que estou:

scp tribas@kahuna.iqm.unicamp.br:~/biogas_warmup/fastp_biogas.log .

Para fazer o mesmo comando, entretanto em background:

nohup scp -r tribas@kahuna.iqm.unicamp.br:~/meu/diretorio . > nohup.out 2>&1
O servidor pedirá a senha do servidor que você está tentando puxar o arquivo (nesse caso a senha do
KAHUNA). Insira a senha, aperte enter, e depois aperte ctrl+z. Por fim, insira o comando bg e aperte enter. É
possível visualizar que o arquivo está sendo baixado pelo comando du -h, que a cada vez que você insere
mostra o tamanho em disco no diretório.

Via WinSCP
Também é possível fazer a transferência via WinSCP mesmo:

● Abra o WinSCP após a instalação.

● No campo protocolo de arquivo selecione SFTP.
● Na janela do WinSCP, você verá duas caixas de texto na parte superior. No campo "Host", digite o
endereço do servidor. No campo usuário digite seu nome de usuário.
● No campo "porta", digite a 22.
● Clique em avançado.

● A esquerda selecione a opção Conexão → Túnel. Selecione “Conectar através de túnel SSH”
● No Nome do Host preencha com o servidor do gate do IFGW, selecione a porta 22 e preencha o seu
usuário. Depois clique em OK.
● Depois clique em Salvar e defina um nome para uso futuro

.
 ● Depois é só selecionar o nome salvo no meu à esquerda, clicar em Login, digitar a senha duas vezes
(uma para o gate e outra para o cluster) e a conexão já está estabelecida.

Gerenciamento do cluster:
Submetendo seu job
O software que gerencia as máquinas e os Jobs no cluster Coaraci se chama SLURM. É através
dele que iremos submeter os Jobs através dos scripts para máquinas específicas dependendo da
necessidade computacional.

Os comandos básicos estão disponíveis em: https://hpc.nmsu.edu/discovery/slurm/commands/

Também temos a documentação do próprio SLURM:

https://slurm.schedmd.com/man_index.html

Abaixo está um exemplo prático de como rodar um job no cluster.

O script em questão que irá rodar no cluster será em python, chamado python_script.py.

python_script.py.
-------------------------------------
print(‘Hello world’)
-------------------------------------
Uma vez com o script pronto, preparamos o script em bash que vai rodar o nosso script principal.
Esse é o script que o SLURM irá reconhecer e encaminhar para uma máquina no cluster. Esse
script irá se chamar roda_script.sh. Nele, iremos conter as diretivas que contém informações
para o SLURM gerenciar, como nome do job, quantidade de threads, tempo de uso, etc.

roda_script.sh.
------------------------------
#!/bin/bash

#SBATCH --partition=paralela
#SBATCH --job-name=teste
#SBATCH --output=sys-output.txt
#SBATCH --time=24:00:00
#SBATCH --cpus-per-task=70
## Nome da fila que você vai submeter o job (ver nós computacionais)
## Nome que você vai dar para o job
## Arquivo de output
## Duração do job
## Número de threads que deseja utilizar

srun python script_bracken.py

-------------------------------------
Depois que os dois scripts estiverem prontos, o próximo passo é submeter o job no terminal. Para
isso, use o comando:

sbatch roda_script.sh

Acompanhamento de job
Para acompanhar os jobs submetidos use o comando:

squeue -u <seu_usuario>

Para acompanhar com mais detalhes um job em específico. A melhor forma de visualizar os stats
é jogando a saída do comando para um txt através do sinal “>”, pois no terminal a tabela fica
desconfigurada → comando > my_stat.txt

sstat -j <seu_job_id> > my_stat.txt

Output do comando:

● JobID: The unique identifier for the job step.

● MaxVMSize: The maximum virtual memory size used by the job step. It indicates
the highest amount of virtual memory utilized.
● MaxVMSizeNode: The node where the maximum virtual memory was used.
● MaxVMSizeTask: Information related to the task with the maximum virtual memory
usage. In this case, it's "0," indicating the job step as a whole.
● AveVMSize: The average virtual memory size across all tasks in the job step.
● MaxRSS: The maximum resident set size (physical memory) used by the job step.
● MaxRSSNode: The node where the maximum resident set size was used.
● MaxRSSTask: Information related to the task with the maximum resident set size
usage. In this case, it's "0," indicating the job step as a whole.
● AveRSS: The average resident set size (physical memory) across all tasks in the job
step.
● MaxPages: The maximum number of pages used by the job step.
● MaxPagesNode: The node where the maximum number of pages was used.
● MaxPagesTask: Information related to the task with the maximum page usage. In
this case, it's "0," indicating the job step as a whole.
● AvePages: The average number of pages used by all tasks in the job step.
 ● MinCPU: The minimum CPU time used by the job step.
● MinCPUNode: The node where the minimum CPU time was used.
● MinCPUTask: Information related to the task with the minimum CPU time usage. In
this case, it's "0," indicating the job step as a whole.
● AveCPU: The average CPU time used by all tasks in the job step.
● NTasks: The number of tasks in the job step.
● AveCPUFreq: Average CPU frequency information for tasks (e.g., "2.79M" indicates
2.79 million cycles).
● ReqCPUFreqMin, ReqCPUFreqMax: Minimum and maximum required CPU
frequencies for tasks (e.g., "Unknown" means no specific requirement).
● ReqCPUFreqGov: The governor used for CPU frequency control.
● ConsumedEnergy: Energy consumption information (e.g., "energy=0,fs/di+"
represents energy consumption details).
● MaxDiskRead: Maximum disk read activity during the job step.
● MaxDiskReadNode: The node where the maximum disk read activity occurred.
● MaxDiskReadTask: Information related to the task with the maximum disk read
activity. In this case, it's "0," indicating the job step as a whole.
● AveDiskRead: The average disk read activity across all tasks in the job step.
● MaxDiskWrite: Maximum disk write activity during the job step.
● MaxDiskWriteNode: The node where the maximum disk write activity occurred.
● MaxDiskWriteTask: Information related to the task with the maximum disk write
activity. In this case, it's "0," indicating the job step as a whole.
● AveDiskWrite: The average disk write activity across all tasks in the job step.
● TRESUsageInAve, TRESUsageInMax, TRESUsageInMaxNode,
TRESUsageInMaxTask: Information related to resource consumption on the input
side (e.g., CPU time, energy, disk activity).
● TRESUsageInMin, TRESUsageInMinNode, TRESUsageInMinTask: Minimum
resource consumption on the input side.
● TRESUsageInTot: Total resource consumption on the input side.
● TRESUsageOutAve, TRESUsageOutMax, TRESUsageOutMaxNode,
TRESUsageOutMaxTask: Information related to resource consumption on the
output side (e.g., CPU time, energy, disk activity).
● TRESUsageOutMin, TRESUsageOutMinNode, TRESUsageOutMinTask: Minimum
resource consumption on the output side.
● TRESUsageOutTot: Total resource consumption on the output side.

Para matar um processo use:

skill <seu_job_id>
ou

scancel <seu_job_id>