Centro Nacional de Processamento de Alto Desempenho em São Paulo

Transcrição

1 Centro Nacional de Processamento de Alto Desempenho em São Paulo UNICAMP / MCT-FINEP Maio / 2016

2 2

3 3 Sumário Apresentação CENAPAD-SP Informações e Suporte aos Usuários Convenções adotadas Equipamentos disponíveis Ambiente SGI Softwares disponíveis(ambiente SGI) Ambiente IBM P Softwares disponíveis (Ambiente IBM P750) Ambiente IBM/GPU Softwares disponíveis (Ambiente IBM/GPU) Contas, projetos e contabilização de uso Acesso aos equipamentos Escolhendo o ambiente computacional e transferindo arquivos... 23

4 Como executar jobs batch (Ambiente SGI Altix 1350/450) Como executar jobs batch (Ambiente IBM P750) Como executar jobs batch (Ambiente IBM/GPU) Como executar jobs batch (Ambiente SGI Altix ICE 8400 LX) Treinamentos

5 5

6 Apresentação Senhor usuário, Este manual descreve sucintamente as características do ambiente CENAPAD-SP e registra algumas informações referentes à utilização do mesmo. Tutoriais que tratam mais detalhadamente os tópicos aqui abordados, bem como informações atualizadas sobre o ambiente de hardware e de software podem ser obtidas pelo nosso serviço on-line, no endereço: Dúvidas que não forem esclarecidas por nenhuma das vias indicadas, sugestões, comentários ou reclamações que contribuam para o aperfeiçoamento do nosso serviço devem ser encaminhadas para a equipe técnica do CENAPAD-SP, através do endereço eletrônico: consult@cenapad.unicamp.br Esperamos que este manual seja uma boa ferramenta de auxílio ao desenvolvimento de sua pesquisa. Atenciosamente, Suporte Técnico CENAPAD-SP 6

7 7 CENAPAD-SP O CENAPAD-SP é um dos Centros Nacionais de Processamento de Alto Desempenho que compõem o programa SINAPAD, implementado no Brasil pelo MCT através da FINEP. Foi instalado em junho de 1994, sendo hoje um Centro ligado à Pro- Reitoria de Pesquisa da UNICAMP. Sua missão é apoiar as atividades de P&D nas áreas de ciência e tecnologia do País, disponibilizando um ambiente de alto desempenho e afins, atuando como um centro de excelência em novas tendências computacionais e contribuindo para a formação da comunidade científica e empresarial. Para isso, disponibiliza aos seus usuários um poderoso ambiente para computação de alto desempenho, com recursos de hardware e software, bem com suporte técnico e operacional necessários. O CENAPAD-SP oferece ainda Treinamentos especializados na área de Computação de Alto Desempenho, abertos à comunidade científica e empresarial.

8 Informações e Suporte aos Usuários Todas as informações relativas ao CENAPAD-SP e ao Projeto SINAPAD estão disponíveis em: WWW: CENAPAD-SP Notícias: s: consult@cenapad.unicamp.br Devem ser encaminhadas para este endereço quaisquer dúvidas relativas ao uso do ambiente, de compiladores e aplicativos em geral. suporte@cenapad.unicamp.br Este endereço deve ser utilizado para a notificação de problemas no ambiente, tais como impossibilidade de acesso, falhas no sistema operacional, ou qualquer ocorrência que impeça a utilização de recursos computacionais oferecidos pelo CENAPAD-SP. cursos@cenapad.unicamp.br Informações acerca da programação e inscrição de cursos oferecidos pelo CENAPAD-SP devem ser solicitadas por este endereço. Telefone: (0xx19)

9 9 Convenções Adotadas Neste documento, foram adotadas as seguintes convenções: O comando digitado pelo usuário é representado por meio da fonte courier negrito e a saída gerada pelo sistema é representada pela fonte courier normal. A parte variável do comando (parâmetro) é representada em itálico. O caractere ^ indica que a tecla control deve ser pressionada simultaneamente com a tecla que o segue. Por exemplo, ^C. Os parâmetros opcionais de um comando são representados entre colchetes "[...]". O sinal de prompt é indicado pelo símbolo %. O nome das máquinas será representado em itálico negrito.

10 Equipamentos Disponíveis O CENAPAD-SP disponibiliza um ambiente computacional poderoso, baseado em máquinas RISC (IBM) e Intel (SGI), com sistema operacional baseado em Unix. A capacidade de processamento teórica desses ambientes totaliza em torno de 33 TFLOPS, além de 250 TB de disco externo. Seu uso é medido em Service Units, que são contabilizadas conforme os usuários executam comandos e processam jobs. Os ambientes computacionais disponíveis no CENAPAD-SP são: Ambiente IBM P750 (Sistema Operacional: Unix AIX) Ambiente IBM/GPU (Sistema Operacional: Linux SUSE) Ambiente SGI Altix 1350/450 (Sistema Operacional: Linux SUSE) Ambiente SGI Altix ICE 8400 LX (Sistema Operacional: Linux SUSE) Cada um desses ambientes tem seus recursos, suas ferramentas, suas limitações e especificidades. A seguir, serão relacionadas as principais características das máquinas de cada um desses ambientes. Maiores detalhes podem ser obtidos a partir de: 10

11 11 Ambiente SGI SGI Altix ICE 8400 LX O sistema Altix ICE 8400 LX instalado no CENAPAD-SP tem 32 nós, interconectados através de uma rede Infiniband de alto desempenho, dispostos em 2 individual Rack Unit (iru), cada um deles com desempenho teórico de 160 GFLOPs e com a seguinte configuração: 2 processadores Intel Xeon Six Core 5680 de 3.33GHz 36GB de memória RAM hostnames r1i0n0.ice.cenapad-sp.br.. r1i0n15.ice.cenapad-sp.br hostnames r1i1n0.ice.cenapad-sp.br.. r1i1n15.ice.cenapad-sp.br Nó de acesso O nó de acesso ao sistema SGI Altix ICE é ice.cenapad.unicamp.br ( ) que corresponde ao nó ice.ice.cenapad.sp.br ( ). Sistema Operacional SUSE LINUX Enterprise Server 11 SP1 (x86_64) kernel bits. SGI Altix 1350/450 O sistema Altix 1350 instalado no CENAPAD-SP tem 6 nós Intel Itanium2 com a seguinte configuração: 1 nó com 32 processadores Intel Itanium2, 1.5GHz e 96GB RAM 1 nó com 32 processadores Intel Itanium2, 1.5GHz e 86GB RAM 1 nó com 4 processadores Intel Itanium2, 1.5GHz e 24GB RAM 1 nó com 32 processadores Intel Itanium2, 1.5GHz e 53GB RAM 1 nó com 32 processadores Intel Itanium2, 1.5GHz e 60GB RAM 1 nó com 32 processadores Intel Itanium2, 1.5GHz e 32GB RAM

12 O sistema Altix 450 instalado no CENAPAD-SP tem 3 nós Intel Itanium2 Dual Core com a seguinte configuração: 1 nó com 34 processadores (68 cores) Intel Itanium2 Dual-core série GHz e 195GB RAM 1 nó com 38 processadores (76 cores) Intel Itanium2 Dual-core série GHz e 195GB RAM 1 nó com 24 processadores (48 cores) Intel Itanium2 Dual-core série GHz e 120GB RAM Nós Os nós estão dispostos em 4 frames: Frame 01 2 nós com 32 processadores Intel Itanium2, 1.5GHz o Desempenho teórico de 96 GFLOPs por nó o 96 e 86 GB de memória RAM o 220 GB de espaço em disco por nó o Hostname sg1no1.cenapad.unicamp.br, sg1no2.cenapad.unicamp.br Frame 02 1 nó com 4 processadores Intel Itanium2, 1.5GHz o Desempenho teórico de 24 GFLOPs o 24 GB de memória RAM o 15 TB de espaço em disco, sendo 1,6 TB reservado para /work o Hostname: sg2gq1.cenapad.unicamp.br (athenas.cenapad.unicamp.br) 2 nós com 16 processadores Intel Itanium2, 1.5GHz o Desempenho teórico de 96 GFLOPs por nó o 53 e 60 GB de memória RAM o 200 GB de espaço em disco por nó o Hostnames: sg2no1.cenapad.unicamp.br, sg2no2.cenapad.unicamp.br Frame 03 1 nó com 34 processadores (68 cores) Intel Itanium2 Dual-core série 9000, 1.6GHz o Desempenho teórico de 435 GFLOPs o 195 GB de memória RAM o 300 GB de espaço em disco o Hostnames: sg3no1.cenapad.unicamp.br 12

13 13 1 nó com 38 processadores (76 cores) Intel Itanium2 Dual-core série 9000, 1.6GHz o Desempenho teórico de 486 GFLOPs o 195 GB de memória RAM no nó o 300 GB de espaço em disco o Hostname: sg3no2.cenapad.unicamp.br Frame 04 1 nó com 16 processadores Intel Itanium2, 1.5GHz o Desempenho teórico de 96 GFLOPs o 32 GB de memória RAM o 200 GB de espaço em disco o Hostnames: sg4no1.cenapad.unicamp.br 1 nó com 24 processadores (48 cores) Intel Itanium2 Dual-core série9000, 1.6GHz o Desempenho teórico de 307 GFLOPs o 120 GB de memória RAM o 350 GB de espaço em disco o Hostname: sg4no2.cenapad.unicamp.br Nó de acesso O nó de acesso ao sistema SGI é athenas.cenapad.unicamp.br ( ) que corresponde ao nó: sg2gq1.cenapad-sp.br. Este nó também é o servidor de arquivos (36 TB) e de controle do sistema SGI. Sistema Operacional SUSE LINUX Enterprise Server 10 (ia64) kernel bits

14 Linguagens de programação, editores e bibliotecas - Ambiente SGI Linguagens de programação Intel Fortran Intel C GNU C e GNU C++ (gcc/g++) Bibliotecas Científicas Intel MKL (Math Kernel Library) Bibliotecas para Processamento Paralelo MPI (Message Passing Interface) SGI MPT (Message Passing Toolkit) Editores de Texto vi emacs Software Uma lista completa dos recursos de software disponíveis no ambiente está disponível a partir de: 14

15 15 Ambiente IBM P750 IBM Power 750 Express server O equipamento IBM do CENAPAD-SP é composto por 40 nós computacionais SMP modelo IBM P750, que utilizam processadores Power7 de 3.55GHz. São 32 cores (núcleos de processamento), 128GB de memória RAM e 908,8 GFlops de desempenho teórico em cada nó computacional, totalizando 1280 cores, 5TB de memória RAM e capacidade teórica de processamento de aproximadamente 37 TFLOPs. Conta também com sistema de armazenamento IBM System Storage DS5020 com 224TB e três unidades Tape Library IBM TS3200 para backup. Nós O sistema é composto por 43 nós dispostos em 5 frames: 40 nós IBM P750 (Hostnames: tyrno01.cenapadsp.br.. tyrno40.cenapadsp.br), cada um com: o 4 processadores IBM Power7 8Cores, 3.55GHz; o 128GB de memória RAM; o 2 discos SAS 300GB 10K; 1 nó IBM P520 (Hostname: tyr.cenapad.unicamp.br), para acesso ao sistema, com: o 2 processadores IBM Power6 + 2Cores, 4.7GHz; o 16 GB de memória RAM; o 4 discos SAS 300GB 15K; 1 nó IBM P550 (Hostname: tsm.cenapadsp.br), para controle de storage e backup de dados, com: o 2 processadores IBM Power6+ 2Cores, 5GHz; o 32GB de memória RAM; o 4 discos SAS 300GB 15K;

16 Nó de acesso Os nós são interconectados por meio de uma rede Infiniband de alto desempenho. O nó de controle e de acesso ao sistema IBM é tyr.cenapad.unicamp.br ( ), que corresponde ao nó tyr.cenapadsp.br. Sistema Operacional Nós P750, P550 e P520 (processadores IBM Power): o AIX

17 17 Linguagens de programação, editores e bibliotecas Ambiente IBM P750 Linguagens de Programação C/C++ Compilador GNU de C e C++ (gcc/g++) Compilador AIX de C e C++ (xlc/xlc) FORTRAN Compilador IBM de FORTRAN (xlf e f77) Compilador IBM de FORTRAN90 (xlf90) Bibliotecas Científicas ESSL (Engineering and Scientific Subroutine Library, que inclui LAPACK, SCALAPACK, BLAS, BLACS, etc) Bibliotecas para Processamento Paralelo MPI (Message Passing Interface) Editores de texto emacs vi Software Uma lista completa dos recursos de software disponíveis no ambiente está disponível a partir de:

18 Ambiente IBM/GPU IBM idataplex/gpu O sistema IBM GPU instalado no CENAPAD-SP é composto por 6 nodes. Cada node possui 2 CPU s (8 cores e 16 Threads) Intel Xeon X5570 de 2,93GHz, 24 GB de memória RAM e 2 placas Nvidia Tesla M2050 (cada placa possui 448 núcleos CUDA e 3 GB de memória RAM). A capacidade de processamento teórica de cada placa Nvidia Tesla M2050 é de 515 Gflops em dupla precisão e de 1.03 Tflops em precisão simples no formato de ponto flutuante. No total são 48 cores / 96 threads, 144 GB de memória RAM e 12 placas Nvidia Tesla M2050. Nós O sistema IBM GPU instalado no CENAPAD-SP tem 6 nós, cada um com a seguinte configuração: 2 processadores Intel Xeon Processor X5570 de 2.93 GHz - 8 cores / 16 threads 24GB de memória RAM 2 placas gráficas Nvidia Tesla M2050 hostnames gpuno01.cenapadsp.br.. gpuno06.cenapadsp.br Nó de acesso O nó de acesso ao sistema IBM GPU é gpu.cenapad.unicamp.br ( ). Sistema Operacional SUSE LINUX Enterprise Server 11 SP3 (x86_64) 18

19 19 Linguagens de programação, editores e bibliotecas Ambiente IBM/GPU Linguagens de Programação Intel Fortran Intel C GNU C e GNU C++ (gcc/g++) Bibliotecas Científicas Intel MKL (Math Kernel Library) Bibliotecas para Processamento Paralelo OpenMPI (1.8.6 e 1.8.7) CUDA 5.5 Editores de texto emacs vi Software Uma lista completa dos recursos de software disponíveis no ambiente está disponível a partir de:

20 Contas, Projetos e Contabilização de Uso O CENAPAD-SP estabelece dois tipos de contas de usuários: contas experimentais temporárias e contas-projeto. Contas experimentais temporárias: têm por objetivo dar ao usuário a oportunidade de avaliar o CENAPAD-SP no que diz respeito aos equipamentos, ambientes computacionais e softwares disponíveis. Essas contas têm validade máxima de três meses, e serão expiradas antes desse prazo caso sejam utilizadas mais de 10 Service Units (o equivalente a 40 horas de CPU em uma das servidoras IBM-P750). Contas-projeto: são contas permanentes, criadas a partir de encaminhamento de um projeto de pesquisa. A contabilização do uso é feita através de Service Units, segundo a tabela : Modelo Horas de CPU equivalentes a uma Service Unit Número de máquinas no ambiente IBM-P750 4,0 h 40 IBM/GPU 6,0 h 6 SGI-ICE 6,0 h 32 SGI-Itanium2 20,0 h 11 Às contas-projeto são alocadas inicialmente Service Units, que podem ser aumentadas conforme a necessidade. No primeiro ano de vigência de sua conta-projeto, o usuário deve encaminhar ao CENAPAD-SP, semestralmente, um relatório de acompanhamento, descrevendo a utilização que foi feita do ambiente. A partir do segundo ano de vigência de sua conta permanente, esse relatório passa a ser anual. Em ambos os casos, o usuário recebe por e- mail, com um mês de antecedência, o modelo do relatório periódico. Este deve ser preenchido e enviado por para o endereço eletrônico: suporte@cenapad.unicamp.br Maiores informações sobre procedimentos de abertura de contas, encaminhamento de projetos e relatórios de acompanhamento podem ser obtidas no site: 20

21 21 Acesso aos Equipamentos Para acessar remotamente o ambiente CENAPAD-SP, é preciso que o usuário possua o software SSH instalado em sua máquina. O programa telnet, que oferecia o mesmo serviço, não pode ser utilizado para conexão ao CENAPAD-SP, pois com ele a senha do usuário trafega pela Internet sem encriptação. Há versões do SSH para as plataformas mais comuns, incluindo Windows e Unix, disponíveis no FTP anônimo da UNICAMP (ftp.unicamp.br). O acesso remoto ao CENAPAD-SP pode ser feito segundo os procedimentos a seguir, que direcionarão o usuário para a máquina servidora de conexões. Em ambiente Unix, executar o comando: % ssh cenapad.unicamp.br [-l username] fornecendo, quando solicitado, a identificação da conta (username) e a senha de acesso. O SSH assume como username o login da conta por onde o usuário tenta acessar a sua conta do CENAPAD-SP, vetando seu acesso à mesma, caso as duas não tenham logins similares. Apenas neste caso, é preciso utilizar o termo entre colchetes, colocando no lugar de username o login da sua conta no CENAPAD-SP. Em ambiente Windows, executar o programa ssh, indicando como hostname a máquina cenapad.unicamp.br e fornecendo, quando solicitado, a identificação da conta (username) e a senha de acesso. Vale ainda mencionar que, sempre que o SSH solicitar uma resposta do tipo yes or no, a mesma deve ser escrita com todas as letras escritas em minúsculo. Respostas escritas em letras maiúsculas, ou abreviações do tipo y ou n, não são aceitas. Na transferência de arquivos (FTP) de/para sua conta no CENAPAD-SP, o usuário deve utilizar o SCP, um dos componentes do SSH. O SCP utiliza criptografia, impedindo que terceiros tenham acesso às informações transmitidas. Todas as transferências de arquivos feitas para o ambiente CENAPAD-SP devem necessariamente ser feitas utilizando-se como destino a máquina: cenapad.unicamp.br

22 A máquina cenapad.unicamp.br é um servidor de conexão, e a partir dela deve ser feito o acesso ao ambiente computacional desejado. Para detalhes sobre a escolha do ambiente, bem como informações sobre transferência de arquivos para o mesmo, veja nesse Guia o item "Escolhendo o ambiente computacional e transferindo arquivos". 22

23 23 Escolhendo o ambiente computacional e transferindo arquivos O CENAPAD-SP dispõe de quatro ambientes computacionais distintos, a saber: Ambiente SGI Altix 1350/450 Ambiente IBM P750 Ambiente IBM/GPU Ambiente SGI Altix ICE Ao conectar-se ao CENAPAD-SP, o usuário estará por default conectado ao servidor de conexões (máquina frontend.cenapad.unicamp.br). Se desejar se conectar a algum dos outros ambientes, o usuário deve fazê-lo através de um dos comandos abaixo: % ssh athenas - para direcionar sua sessão para o front-end do ambiente SGI Altix % ssh tyr - para direcionar sua sessão para o front-end do ambiente IBM P750 % ssh gpu - para direcionar sua sessão para o front-end do ambiente IBM/GPU % ssh ice - para direcionar sua sessão para o front-end do ambiente ICE O login e a senha do usuário no CENAPAD-SP são sempre os mesmos, independente do ambiente computacional utilizado. Transferindo arquivos para os diferentes ambientes computacionais Estão disponíveis, a partir da sessão no servidor de conexões, os diretórios home do usuário em cada um dos ambientes computacionais: Ambiente SGI-Altix - diretório homealtix Ambiente IBM P750 - diretório homeibm Ambiente IBM/GPU - diretório homegpu Ambiente SGI-ICE - diretório homeice A transferência de arquivos para o CENAPAD deve sempre ser feita para o servidor de conexões (cenapad.unicamp.br), indicando-se o ambiente destino através dos diretórios acima.

24 Exemplo: - Para transferir um arquivo de sua máquina local para o ambiente IBM o usuário deve usar, em sua máquina local, o comando: scp nome_do_arquivo login@cenapad.unicamp.br:~/homeibm Do mesmo modo, a transferência de arquivos do CENAPAD para a máquina local do usuário deve indicar o ambiente correspondente. Exemplo: - Para transferir um arquivo de sua conta CENAPAD no ambiente SGI-ICE para sua máquina local, o usuário deve usar (também em sua máquina local) o comando: scp login@cenapad.unicamp.br:~/homeice/nome_do_arquivo. IMPORTANTE: O comando acima assume que o arquivo se encontra no "diretório raiz" da conta do usuário no ambiente. Caso o arquivo a ser transferido esteja dentro de algum subdiretório, o "caminho" completo deve ser especificado. Exemplo: - Se o arquivo encontra-se na conta do usuário no ambiente SGI-Altix sob o diretório "resultados" o comando deve ser: scp login@cenapad.unicamp.br:~/homealtix/resultados/nome_do_arquivo. O caracter "." (ponto final) é mandatório nos comandos acima, e pode opcionalmente ser substituído por um subdiretório da conta do usuário em sua máquina local. IMPORTANTE - Caso o arquivo de origem tenha sido criado em uma máquina Windows, é preciso convertê-lo para o formato Linux antes de usá-lo no ambiente CENAPAD. Para fazer essa conversão, o usuário deve usar o seguinte comando (no ambiente CENAPAD): dos2unix <nome_do_arquivo> 24

25 25 Em todos os ambientes, as máquinas podem ser usadas de duas maneiras: 1) Modo Interativo - usado para compilação de programas, criação e edição de inputs, verificação de outputs e submissão de jobs a serem executados. 2) Modo Batch - usado para o processamento propriamente dito. Nesse modo, o job é submetido a um Sistema de Filas, para ser executado quando houver máquina/recursos disponíveis. Podem ser executados em batch programas seriais ou paralelos. É necessário que se utilize as ferramentas adequadas em cada um dos ambientes computacionais do CENAPAD-SP, dada a sua heterogeneidade. Algumas são comuns aos quatro ambientes (a maioria dos comandos UNIX, por exemplo). Mas há muitas diferenças nas ferramentas disponíveis em cada ambiente no que diz respeito às compilações de programas e às submissões de jobs para processamento. Nos próximos capítulos deste Guia serão descritos os procedimentos básicos para submissão de tarefas computacionais (jobs batch) em cada um dos diferentes ambientes computacionais disponíveis no CENAPAD-SP.

26 Como executar jobs batch (ambiente SGI Altix 1350/450) Submissão de jobs Para submeter um job para execução no ambiente SGI Altix do CENAPAD-SP o usuário deve: 1. Logar no CENAPAD-SP 2. Logar na máquina interativa deste ambiente por meio do comando: % ssh athenas (utilizando o mesmo usuário e a mesma senha do CENAPAD-SP) 3. Criar um arquivo com diretivas sobre o job a ser executado 4. Submeter o job a ser executado para o sistema de filas (PBS), através do comando: % qsub <nome_do_script> Para verificar o status das filas nesse ambiente deve ser usado o comando: % qstat -a Para verificar o status dos jobs de um determinado usuário nesse ambiente deve ser usado o comando: % qstat au login_do_usuario 26

27 27 As filas e restrições definidas no PBSPro são: Num Max Num Max Tempo Max Tempo Max Num Max Filas Seriais Jobs exec cpus/jobs uso / cpu (elapsed) Jobs/user pequena hs - - media hs - - grande hs - - Filas Num Max Num Max Tempo Max Tempo Max Num Max Paralelas Jobs exec cpus/jobs uso / cpu (elapsed) Jobs/user paralela hs 31 dias - par (fixo) 8064 hs 7 dias 1 exp (fixo) 1632 hs 24 hs 1 Área scratch A área scratch disponível, para gravação de arquivos temporários durante o processamento dos jobs é: Filesystem Tamanho Uso /work 1,7 TB compartilhada por todos os nós No ambiente SGI-Altix 1350/450 estão definidos os seguintes limites para cada usuário: O número máximo de jobs em execução simultânea para um mesmo usuário é 4. O número máximo de jobs aguardando execução (estados Queued ou Hold) é 10. O número máximo de jobs na fila paralela para um mesmo usuário é 4. O número máximo de jobs na fila par48 para um mesmo usuário é 1. O número máximo de jobs na fila exp68 para um mesmo usuário é 1. O tempo de processamento na fila paralela é contabilizado pela soma do uso de todos os processadores.

28 Criando um Arquivo de Comandos Para executar um processamento, é preciso criar um arquivo de comandos que descreve o job a ser executado. Exemplos de arquivos de comandos (scripts) de submissão para as diferentes classes (filas) 1) Jobs Seriais Para submissão de jobs para as classes que processam programas seriais, deve-se usar um script como esse do exemplo a seguir: PBS -q pequena PBS -N testjob PBS -V!/bin/sh cd $PBS_O_WORKDIR echo " " echo "Inicio do job:" `date` echo "Hostname: " `hostname` <chamada do executável do programa com seus parâmetros> echo "Final do job:" `date` echo " " A classe escolhida no exemplo anterior é a classe pequena; há também as classes média e grande que podem ser usadas, dependendo do tempo estimado de execução do processamento (ver tabela na página 24). 28

29 29 2) Jobs Paralelos A execução de programas paralelos que necessitam mais de um processador em qualquer nó, é feita através do comando mpirun, que administra o ambiente paralelo, e por sua vez, a comunicação entre os processadores. A execução de jobs paralelos, deve ser feita através da submissão de um script. Por exemplo, o script jobpar.sh pode conter: PBS -q paralela PBS -N testjob PBS -V PBS -l ncpus=4!/bin/sh cd $PBS_O_WORKDIR echo " " echo "Inicio do job:" `date` echo "Hostname: " `hostname` echo "PWD: " $PWD echo "Arquivos:" mpirun -np 4 <chamada do executável do programa com seus parâmetros> echo "Final do job:" `date` echo " " Neste caso, acrescenta-se a diretiva PBS -l que especifica os recursos necessários para a execução do job. Para uma execução em paralelo, o principal recurso é o número de processadores que serão utilizados. PBS -l ncpus=<n> Número n de processadores. O comando mpirun ainda pode especificar o número de processos que serão inicializados para execução, através da opção -np. Se o número de processos for igual ao número de processadores, o mpirun iniciará um processo por processador. Se o número de processos for maior que o número de processadores, o mpirun iniciará mais de um processo por processador.

30 3) Jobs Gamess A execução de jobs Gamess pode ser feita através da submissão de um script como o exemplo abaixo. Neste exemplo, devem ser alterados: número_de_cpus - número de cpus a serem utilizadas nomejob - identificação do job nomejob_out - nome do arquivo stdout a ser gravado nomejob_err - nome do arquivo stderr a ser gravado input_gms - nome do arquivo de input para o Gamess (se não estiver no mesmo diretório do script deve ser especificado todo o path) log_gms - nome do arquivo de saída do Gamess (se não estiver no mesmo diretório do script deve ser especificado todo o path) Exemplo de script:!/bin/sh PBS -q paralela PBS -l ncpus=numero_de_cpus PBS -N nomejob PBS -o nomejob_out PBS -e nomejob_err echo " " echo "Inicio do job:" `date` echo "Nodes utilizados para execucao:" cat $PBS_NODEFILE echo " " cd $PBS_O_WORKDIR dirgms=/usr/local/gamess_12_jan_2009_r3 NCPUS=numero_cpus $dirgms/rungms input_gms 00 $NCPUS >& log_gms echo " " echo "Final do job:" `date` echo " " 30

31 31 Como executar jobs batch (ambiente IBM P750) Submissão de jobs Para submeter um job para execução no ambiente IBM P750 do CENAPAD-SP o usuário deve: 1. Logar no CENAPAD-SP 2. Logar na máquina interativa deste ambiente por meio do comando: % ssh tyr (utilizando o mesmo usuário e a mesma senha do CENAPAD-SP) 3. Criar um arquivo com diretivas sobre o job a ser executado 4. Submeter o job a ser executado para o sistema de filas (LoadLeveler), através do comando: % llsubmit <script> Para verificar o status das filas nesse ambiente deve ser usado o comando: % llq Para verificar o status dos jobs de um determinado usuário nesse ambiente deve ser usado o comando: % llq u login_do_usuario

32 Configuração do sistema de filas - LoadLeveler Classes O ambiente de processamento de jobs do CENAPAD-SP está dividido em dois grandes grupos: processamento serial processamento paralelo Para atender as necessidades de cada um destes dois grupos existem seis tipos de classes, que foram definidas com o objetivo de distribuir da melhor forma possível os recursos do ambiente entre os usuários e, principalmente, otimizar o tempo de processamento e o tempo de espera na fila. As classes diferenciam-se por: quantidade de processadores utilizados; limite de uso de CPU (tempo total de CPU utilizado); limite de tempo de execução (tempo que o job pode permanecer em execução); quantidade máxima de jobs. As classes disponíveis possuem a seguinte configuração: Tipo Número de nós Classe Limite de uso de CPU Limite de tempo processamento Num. Máx. de cores Num. Máx. de threads Serial 20 pequena 2 horas 2:30 horas 1 1 media 5 dias 5 dias e 12 horas 1 1 grande 30 dias 31 dias 1 1 Paralela 21 paralela 256 dias 30 dias e 4 horas exp dias 1 dia e 30 minutos par dias 7 dias e 2 horas gaussian 256 dias 30 dias e 4 horas

33 33 Áreas scratch As áreas scratch disponíveis, para gravação de arquivos temporários durante o processamento dos jobs são: Filesystem Tamanho Uso /work 200 GB local em cada um dos nós /workpar 32 TB compartilhado pelos nós que executam jobs da fila paralela /work TB compartilhado pelos nós que executam jobs da fila par128 /work TB compartilhado pelos nós que executam jobs da fila exp512 /workgau 32 TB disponível no nó que executa jobs da fila gaussian No ambiente IBM P750 estão definidos os seguintes limites para cada usuário: máximo de 2 jobs em execução na fila gaussian. máximo de 1 job em execução na fila exp512. máximo de 2 jobs em execução na fila par128. máximo de 6 jobs em execução simultânea (jobs no estado Running) nas filas; máximo de 10 jobs aguardando recursos para execução (jobs no estado Idle). O tempo de processamento na fila paralela é contabilizado pela soma do uso de todos os processadores. Criando um Arquivo de Comandos Antes de submeter um job para execução, é necessária a criação de um arquivo de comandos, que descreve o job que deverá ser executado. Ou seja, todo job deve ser submetido através de um arquivo de comandos, pois o LoadLeveler não submete arquivos executáveis. Este arquivo de comandos assemelha-se a um shell script, que contém comandos dados por palavras-chaves do LoadLeveler (diretivas) que descrevem o job a ser executado. Pode também conter linhas de comentários (não executáveis).

34 Exemplos de arquivos de comandos (scripts) de submissão para as diferentes classes (filas) 1) Jobs Seriais Para submissão de jobs para as classes que processam programas seriais, deve-se usar um script como o exemplo a seguir: Job class = job_name = output = error = notification = queue exibe no arquivo de saida o nome do host onde job fois executado e data/hora echo ============================================= echo "`/bin/hostname` - `/bin/date`" echo ============================================= execucao do programa./programa < /dev/null > output.$$ 2>&1 A classe escolhida no exemplo acima é a classe pequena; há também as classes média e grande que podem ser usadas, dependendo do tempo estimado de execução do processamento (ver tabela na página 29). 34

35 35 2) Jobs Paralelos Jobs paralelos são processados por meio da submissão para as classes paralela, par128 ou exp512. Cada uma destas classes tem características diferenciadas, como por exemplo: tempo de cpu, tempo máximo (wall_clock) de execução e número de processadores alocados. Para a submissão de jobs para uma destas classes deve ser utilizado um script como um dos exemplos a seguir. Classe node = total_tasks = node_usage = job_name = input = output = error = notification = environment = job_type = class = queue./programa < /dev/null > output.$$ 2>&1 No exemplo acima foi solicitado para o job 1 node e 4 tasks (CPUs/cores). Pode-se solicitar no máximo 8 nodes e 64 tasks (CPUs/cores) por job. Caso o número de nodes (ou seja, a diretiva "@ node") não seja especificado no script de submissão, será assumido que o número de nodes desejado é 1 (um). Nesse caso, o valor máximo permitido para a diretiva "@ total_tasks" é de 32 (que é o número de CPUs em cada node desse ambiente).

36 Classe Par128!/bin/sh Exemplo job classe node = total_tasks = node_usage = job_name = input = output = error = notification = environment = job_type = class = core_limit = queue export OMP_NUM_THREADS=4 export MP_TASK_AFFINITY=cpu:4./programa < /dev/null > output.$$ 2>&1 No exemplo acima, foi solicitado para o job 1 node e 32 tasks (CPUs/cores). As diretivas que indicam o número de nodes node = 1), o número de CPUs/cores total_tasks = 32) e o modo de compartilhamento do node node_usage = not_shared) não devem ser modificadas nos scripts de submissão para a fila par128. Caso alguma dessas diretivas seja modificada, a submissão não será feita (o job não será incluído na fila correspondente). 36

37 37 Classe exp512!/bin/sh Exemplo job classe node = total_tasks = node_usage = job_name = input = output = error = notification = environment = job_type = class = network.mpi = bulkxfer = queue export OMP_NUM_THREADS=4 export MP_TASK_AFFINITY=cpu:4./programa < /dev/null > output.$$ 2>&1 No exemplo acima, foram solicitados para o job 4 nodes e 32 tasks (CPUs/cores). As diretivas que indicam o número de nodes node = 4), o número de CPUs/cores total_tasks = 32) e o modo de compartilhamento dos nodes node_usage = not_shared) não devem ser modificadas nos scripts de submissão para a fila exp512. Caso alguma dessas diretivas seja modificada, a submissão não será feita (o job não será incluído na fila correspondente). Para todos os exemplos acima, assumimos que o programa sendo executado (./programa) está no mesmo diretório em que está o script de submissão. O usuário pode especificar o caminho completo (PATH) do programa a ser executado, caso necessário.

38 3) Jobs Gaussian Exemplo de script utilizando 4 CPUs:!/usr/bin/csh Script para submissao de jobs Gaussian (G09) no ambiente IBM/Loadleveler usando 4 Processadores IMPORTANTE : Deve ser especificado no arquivo de input a diretiva indicando execucao em 4 CPUs node = total_tasks = node_usage = job_name = input = output = error = notification = notify_user = environment = job_type = class = queue Setar vars de ambiente necessarias para o G09 setenv g09root /g09root setenv GAUSS_SCRDIR /workgau/g09/$user/$loadl_pid source $g09root/g09/bsd/g09.login Cria diretorio de scratch a ser usado na execucao mkdir -p /workgau/g09/$user/$loadl_pid Indica execucao no diretorio de scratch cd $GAUSS_SCRDIR 38

39 39 Execucao em paralelo / multithread setenv OMP_NUM_THREADS 4 setenv MP_TASK_AFFINITY cpu:4 Chamada do executavel ATENCAO : deve ser indicado o caminho completo (PATH) de onde esta' o arquivo de input (extensao.com) e o caminho completo (PATH) de onde deve ser gravado o arquivo de output (extensao.log) g09 < caminho_completo/input.com > caminho_completo/output.log Copia arquivo chk para destino (na conta do usuario) ATENCAO : deve ser indicado o caminho completo (PATH) de onde deve ser gravado o arquivo de chk gerado cp Gau*chk caminho_completo Removendo arquivos temporarios gerados na area de scratch cd rm rf $GAUSS_SCRDIR

40 Importante: No script acima, é preciso colocar o "caminho" dos arquivos de input e output desejados na linha de comando em que se faz a chamada do G09. Se esses arquivos estiverem no diretório raiz de sua conta, basta especificar para o exemplo acima ~/input.com e ~/output.log Para processamentos do G09 utilizando mais do que uma CPU, é preciso que o arquivo de input correspondente seja configurado de maneira consistente com o número de CPUs solicitado. Para o exemplo acima (4 CPUs) o arquivo de input correspondente deve indicar também 4 CPUs, na diretiva nprocshared : %NProcShared=4 Para uma melhor performance, o script acima faz a execução do G09 a partir de um diretório de scratch local da máquina (/work), e não a partir de áreas de scratch global. Recomendamos que esse procedimento não seja modificado. Mas a área /work é limitada em 200 GB. Caso haja a necessidade de gerar grandes arquivos temporários, o /work no exemplo acima deve ser substituido pela área de scratch global /workgau (que tem 32 TB). 40

41 41 Como executar jobs batch (ambiente IBM/GPU) Submissão de jobs Para submeter um job para execução no ambiente IBM/GPU do CENAPAD-SP o usuário deve: 1. Logar no CENAPAD-SP 2. Logar na máquina interativa deste ambiente por meio do comando: % ssh gpu (utilizando o mesmo usuário e a mesma senha do CENAPAD-SP) 3. Criar um arquivo com diretivas sobre o job a ser executado 4. Submeter o job a ser executado para o sistema de filas (TORQUE), através do comando: % qsub <nome_do_script> Para verificar o status das filas nesse ambiente deve ser usado o comando: % showq Para verificar o status dos jobs de um determinado usuário nesse ambiente deve ser usado o comando: % qstat

42 As filas e restrições definidas no TORQUE são: Fila Num Max Num Max Num Max cpus Tempo Max Num Max jobs nodes por job jobs exec por job (elapsed) / user gpu hs 2 matlab hs 1 O número máximo de jobs em execução simultânea na fila gpu para um mesmo usuário é 2. O número máximo de jobs aguardando execução na fila gpu para um mesmo usuário (estados Queued ou Hold) é 6. O número máximo de jobs em execução simultânea na fila matlab para um mesmo usuário é 1. O número máximo de jobs aguardando execução na fila matlab para um mesmo usuário (estados Queued ou Hold) é 3. Área de Scratch Não existe área de scratch para esse ambiente. Execução de jobs Os nós gpuno01.. gpuno06 não permitem acesso interativo, pois são reservados para o processamento batch. O sistema gerenciador de filas, responsável pela execução de jobs, é o TORQUE Resource Manager (Versão ). Exemplos de arquivos de comandos (scripts) de submissão para as diferentes classes (filas) Para submeter jobs nas filas é necessário criar um script de submissão que pode ser ligeiramente diferente dependendo do software que estiver utilizando. 42

43 43 1) Jobs paralelos fila gpu!/bin/bash Nome da fila de execucao PBS -q gpu Nome do job PBS -N testegpu Nome do arquivo de saida PBS -o OUTPUT Nome do arquivo de erros PBS -e ERRO NAO ALTERE A LINHA ABAIXO, pois o scheduler nao deixara seu job ser enfileirado PBS -l nodes=1:ppn=16 cd $PBS_O_WORKDIR echo " " echo "Inicio do job:" `date` Variaveis de ambiente necessarias Veja opções em: Compiladores e Bibliotecas Programa programa_executavel

44 2) Jobs paralelos fila matlab!/bin/bash Nome da fila de execucao PBS -q matlab Nome do job PBS -N testematlab Nome do arquivo de saida PBS -o NOME_DO_ARQUIVO_DE_OUTPUT_DESEJADO Nome do arquivo de erros PBS -e NOME_DO_ARQUIVO_DE_ERRO_DESEJADO Recursos necessarios para execucao:(nao ALTERE A LINHA ABAIXO) PBS -l nodes=1:ppn=12 cd $PBS_O_WORKDIR Variaveis de ambiente necessarias export PATH=/usr/local/MATLAB/R2013a/bin:$PATH:. echo " " echo "Inicio do job:" `date` ESCOLHA ABAIXO, UMA DAS POSSIVEIS CHAMADAS DO MATLAB, RETIRANDO O CARACTER "" DO INICIO DA LINHA. Chamada do programa (assumindo que nao ha' parametros) matlab -nosplash -nodisplay -nodesktop -r "simulacao" Chamada do programa (assumindo que ha' parametros numericos) matlab -nosplash -nodisplay -nodesktop -r "simulacao(30,1.e-4)" Chamada do programa (assumindo que ha' parametros alfanumericos) matlab -nosplash -nodisplay -nodesktop -r "simulacao('string1','string2')" 44

45 45 echo "Final do job:" `date` echo " " Como executar jobs batch (ambiente SGI Altix ICE 8400 LX) Submissão de jobs Para submeter um job para execução no ambiente SGI Altix ICE do CENAPAD-SP o usuário deve: 1. Logar no CENAPAD-SP 2. Logar na máquina interativa deste ambiente por meio do comando: % ssh ice (utilizando o mesmo usuário e a mesma senha do CENAPAD-SP) 3. Criar um arquivo com diretivas sobre o job a ser executado 4. Submeter o job a ser executado para o sistema de filas (PBS), através do comando: % qsub <nome_do_script> Para verificar o status das filas nesse ambiente deve ser usado o comando: % qstat -a Para verificar o status dos jobs de um determinado usuário nesse ambiente deve ser usado o comando: % qstat au login_do_usuario

46 As filas e restrições definidas no PBSPro são: Fila Num Max Num Max Tempo Max Tempo Max Num Max jobs jobs exec cpus / job uso cpu (elapsed) / user parice hs 720 hs - par (fixo) 8064 hs 168 hs 2 exp (fixo) 2304 hs 24 hs 2 O número máximo de jobs em execução simultânea para um mesmo usuário é 4. O número máximo de jobs aguardando execução (estados Queued ou Hold) é 10. O número máximo de processadores sendo utilizados simultaneamente por um mesmo usuário é 96. O número máximo de jobs na fila exp96 para um mesmo usuário é 2 (os jobs excedentes serão automaticamente cancelados). O número máximo de jobs nas filas par48 para um mesmo usuário é 2 (os jobs excedentes serão automaticamente cancelados). O tempo de processamento nestas fila paralelas é contabilizado pela soma do uso de todos os processadores. Área de Scratch Existe nesse ambiente uma área scratch para gravação dos arquivos temporários gerados durante o processamento dos jobs. Essa área tem 23 TB, e deve ser referenciada como: /workice Criando um Arquivo de Comandos Também no ambiente SGI Altix ICE é preciso criar um arquivo de comandos que descreve o job a ser executado. Nesse ambiente os jobs devem obrigatoriamente ser paralelos (não há filas seriais definidas). Para execução de processamentos paralelos, recomenda-se o uso do mpiexec_mpt 46

47 47 (que é otimizado para esse ambiente). Exemplos de arquivos de comandos (scripts) de submissão para as diferentes classes (filas) 1) Jobs Paralelos fila parice A execução de jobs paralelos, pode ser feita através da submissão de um script ou de um arquivo binário. Por exemplo, o arquivo jobpar.sh pode conter: PBS -q parice PBS -N testjob PBS -V PBS -l nodes=1:ppn=4!/bin/sh cd $PBS_O_WORKDIR echo " " echo "Inicio do job:" `date` echo "Hostname: " `hostname` echo "PWD: " $PWD Define PATH e LD_LIBRARY_PATH para uso do mpiexec_mpt export PATH=/opt/sgi/mpt/mpt-2.03/bin:$PATH export LD_LIBRARY_PATH=/opt/sgi/mpt/mpt-2.03/lib:$LD_LIBRARY_PATH Definir variavel para desligar o mapeamento de memoria feito pelo MPI export MPI_MEMMAP_OFF=1 Chamada do executavel A execucao deve ser feita atraves do script mpiexec_mpt /opt/sgi/mpt/mpt-2.03/bin/mpiexec_mpt -np 4 <executável> echo "Final do job:" `date` echo " "

48 No exemplo anterior, são solicitados 1 node e 4 processadores nesse node, através das diretivas: PBS -l nodes=1:ppn=4 Para uso de 4 a 12 processadores: deve ser especificado o número N de Nós com o valor fixo 1 (um), e o número n de processadores a serem usados nesse Nó. PBS -l nodes=1:ppn=<n> Para uso de mais de 12 (e até 48) processadores: deve ser especificado o número N de Nós, e o número n de processadores em cada Nó. PBS -l nodes=<n>:ppn=<n> 48

49 49 2) Jobs paralelos - fila par48 Exemplo do arquivo jobpar.sh (script de submissão) : PBS -q par48 PBS -N testjob PBS -o jobout PBS -e joberr PBS -V PBS -l nodes=4:ppn=12!/bin/sh cd $PBS_O_WORKDIR echo " " echo "Inicio do job:" `date` echo "Hostname: " `hostname` Para algumas aplicacoes MPI que efetuam muita comunicacao entre processos entre nos, e necessario reduzir o tamanho do buffer Infiniband: Minimo=8192; Maximo= (default) export MPI_IB_BUFFER_SIZE=8192 Em aplicacoes que utilizam apenas um no (nodes=1), e aconselhavel definir um valor para o buffer de memoria compartilhada. Recomendavel valor em torno de 2048 bytes export MPI_BUFFER_MAX=2048 echo "PWD: " $PWD Define PATH e LD_LIBRARY_PATH para uso do mpiexec_mpt export PATH=/opt/sgi/mpt/mpt-2.03/bin:$PATH export LD_LIBRARY_PATH=/opt/sgi/mpt/mpt-2.03/lib:$LD_LIBRARY_PATH Definir variavel para desligar o mapeamento de memoria feito pelo MPI export MPI_MEMMAP_OFF=1 Chamada do executável A execucao deve ser feita atraves do script mpiexec_mpt /opt/sgi/mpt/mpt-2.03/bin/mpiexec_mpt -np 48 <executável> echo "Final do job:" `date` echo " "

50 3) Jobs paralelos - fila exp96 Exemplo do arquivo jobpar.sh (script de submissão) : PBS -q exp96 PBS -N testjob PBS -o jobout PBS -e joberr PBS -V PBS -l nodes=8:ppn=12!/bin/sh cd $PBS_O_WORKDIR echo " " echo "Inicio do job:" `date` echo "Hostname: " `hostname` Para algumas aplicacoes MPI que efetuam muita comunicacao entre processos entre nos, e necessario reduzir o tamanho do buffer Infiniband: Minimo=8192; Maximo= (default) export MPI_IB_BUFFER_SIZE=8192 Em aplicacoes que utilizam apenas um no (nodes=1), e aconselhavel definir um valor para o buffer de memoria compartilhada. Recomendavel valor em torno de 2048 bytes export MPI_BUFFER_MAX=2048 echo "PWD: " $PW Define PATH e LD_LIBRARY_PATH para uso do mpiexec_mpt export PATH=/opt/sgi/mpt/mpt-2.03/bin:$PATH export LD_LIBRARY_PATH=/opt/sgi/mpt/mpt-2.03/lib:$LD_LIBRARY_PATH Definir variavel para desligar o mapeamento de memoria feito pelo MPI export MPI_MEMMAP_OFF=1 Chamada do executável A execucao deve ser feita atraves do script mpiexec_mpt /opt/sgi/mpt/mpt-2.03/bin/mpiexec_mpt -np 48 <executável> echo "Final do job:" `date` echo " " Em todos os exemplos de script acima foi usado o mpiexec_mpt (que é o MPI otimizado pela SGI para execução de programas paralelos nesse ambiente). É possível utilizar outros comandos, tais como mpirun (mpich2) e mpiexec (Intel MPI). 50

51 51 Para mais informações, consulte Treinamentos O CENAPAD-SP oferece os seguintes treinamentos: Introdução ao MPI Introdução ao FORTRAN 90 Introdução ao SAS Introdução à Linguagem C Introdução ao OpenMP Introdução ao GNU/Linux A divulgação destes cursos é feita via Internet, pelo endereço (na seção Serviços, subseção Treinamentos ), onde são divulgados a data, o local e horário em que estes treinamentos ocorrerão. Funcionários e alunos de pós-graduação da UNICAMP são isentos do pagamento de taxas. Dúvidas referentes a treinamentos devem ser encaminhadas para: cursos@cenapad.unicamp.br

52 52