sid.inpe.br/mtc-m21c/2018/08.29.16.54-MAN
INSTALAÇÃO E CONFIGURAÇÃO DO SISTEMA DE GERENCIAMENTO DE RECURSOS SLURM EM UM CLUSTER
Fernando Emilio Puntel Adriano Petry Andrea Schwertner Charão
URL do documento original:
INPE São José dos Campos 2018 PUBLICADO POR:
Instituto Nacional de Pesquisas Espaciais - INPE Gabinete do Diretor (GBDIR) Serviço de Informação e Documentação (SESID) CEP 12.227-010 São José dos Campos - SP - Brasil Tel.:(012) 3208-6923/7348 E-mail: [email protected]
COMISSÃO DO CONSELHO DE EDITORAÇÃO E PRESERVAÇÃO DA PRODUÇÃO INTELECTUAL DO INPE (DE/DIR-544): Presidente: Dr. Marley Cavalcante de Lima Moscati - Centro de Previsão de Tempo e Estudos Climáticos (CGCPT) Membros: Dra. Carina Barros Mello - Coordenação de Laboratórios Associados (COCTE) Dr. Alisson Dal Lago - Coordenação-Geral de Ciências Espaciais e Atmosféricas (CGCEA) Dr. Evandro Albiach Branco - Centro de Ciência do Sistema Terrestre (COCST) Dr. Evandro Marconi Rocco - Coordenação-Geral de Engenharia e Tecnologia Espacial (CGETE) Dr. Hermann Johann Heinrich Kux - Coordenação-Geral de Observação da Terra (CGOBT) Dra. Ieda Del Arco Sanches - Conselho de Pós-Graduação - (CPG) Silvia Castro Marcelino - Serviço de Informação e Documentação (SESID) BIBLIOTECA DIGITAL: Dr. Gerald Jean Francis Banon Clayton Martins Pereira - Serviço de Informação e Documentação (SESID) REVISÃO E NORMALIZAÇÃO DOCUMENTÁRIA: Simone Angélica Del Ducca Barbedo - Serviço de Informação e Documentação (SESID) André Luis Dias Fernandes - Serviço de Informação e Documentação (SESID) EDITORAÇÃO ELETRÔNICA: Marcelo de Castro Pazos - Serviço de Informação e Documentação (SESID) Murilo Luiz Silva Gino - Serviço de Informação e Documentação (SESID) sid.inpe.br/mtc-m21c/2018/08.29.16.54-MAN
INSTALAÇÃO E CONFIGURAÇÃO DO SISTEMA DE GERENCIAMENTO DE RECURSOS SLURM EM UM CLUSTER
Fernando Emilio Puntel Adriano Petry Andrea Schwertner Charão
URL do documento original:
INPE São José dos Campos 2018 Esta obra foi licenciada sob uma Licença Creative Commons Atribuição-NãoComercial 3.0 Não Adaptada.
This work is licensed under a Creative Commons Attribution-NonCommercial 3.0 Unported Li- cense.
ii iii
LISTA DE ABREVIATURAS E SIGLAS
CentOS – Community ENTerprise Operating System CRS – Centro Regional Sul de Pesquisas Espaciais EPEL – Extra Packages for Enterprise Linux GID – Group IDentifier INPE – Instituto Nacional de Pesquisas Espaciais IP – Internet Protocol MUNGE – MUNGE Uid ’N’ Gid Emporium NFS – Network File System SLURM – Simple Linux Utility for Resource Management SSH – Secure SHell UID – User IDentifier
v
SUMÁRIO
Pág.
1 INTRODUÇÃO...... 1
2 INSTALAÇÃO E CONFIGURAÇÃO DO SLURM...... 3 2.1 Pré-instalação do SLURM...... 3 2.1.1 Configuração primárias...... 3 2.1.2 Configuração NFS ...... 4 2.1.3 Configuração dos Hosts ...... 5 2.2 Instalação dos componentes necessários e do SLURM...... 6 2.2.1 Criação dos usuários necessários...... 6 2.2.2 Instalação do EPEL ...... 6 2.2.3 Instalação e configuração do MUNGE ...... 7 2.2.4 Instalação de componentes para o funcionamento do SLURM..... 8 2.3 Criação do arquivo de configuração para o SLURM...... 9 2.4 Instalação do SLURM ...... 12 2.4.1 Configuração dos nós Slave ...... 13 2.4.2 Configuração do nó Master ...... 14 2.4.3 Configuração do Firewall...... 16
3 COMANDOS BÁSICOS E POSSÍVEIS ERROS ...... 17 3.1 Comandos Básicos ...... 17 3.2 Possíveis Erros ...... 18 3.2.1 Problemas com o status do nó...... 18 3.2.1.1 Status do nó com *...... 18 3.2.1.2 Verificação da chave munge...... 18 3.2.1.3 Permissões nas pastas...... 19
4 CONCLUSÕES ...... 21
REFERÊNCIAS BIBLIOGRÁFICAS...... 23
vii
1 INTRODUÇÃO
Este manual foi desenvolvido com a intenção de facilitar a instalação e configuração do SLURM (Simple Linux Utility for Resource Management) e seus componentes. A instalação e configuração do SLURM foi realizada em um cluster de processadores no Centro Regional Sul (CRS) no Instituto Nacional de Pesquisas Espaciais (INPE) na cidade de Santa Maria - RS. O cluster é dotado de 8 nós de processamento e um nó de controle. Cada nó possuí 8 CPU’s de processamento (Intel Xeon 2.40GHz), 74 GB de memória e possuem CentOS 6 como sistema operacional.
Na primeira parte do manual é documentada toda a pré-configuração dos nós de um cluster, instalação dos componentes necessários para o funcionamento do SLURM, incluindo o MUNGE, a criação do arquivo de configuração e a instalação e confi- guração do SLURM. Na última parte são explicados alguns comandos básicos, bem como alguns possíveis erros que podem acontecer durante a instalação, configuração e manutenção dos nós.
O SLURM é um gerenciador de carga de trabalho para clusters de computadores homogêneos e heterogêneos. No caso de cluster heterogêneo é possível realizar a divisão dos nós em grupos (chamados de partition pelo SLURM), conforme seu poder de processamento ou configuração escolhida pelo programador. Para ambos os tipos de clusters é preciso selecionar um dos nós para que seja o master, que irá gerenciar os jobs para os demais nós, chamados de slaves.
MUNGE é um serviço de autenticação criado para validação de credenciais entre máquinas. Este serviço é projetado para trabalhar com alta escalabilidade e a per- mite autenticar com UID (user identifier) e GID (group identifier) com outros locais ou processos remotos. Esses hosts se comunicam através de uma chave criptografada compartilhada. O SLURM permite que sejam utilizados outros serviços de autenti- cação, porém o recomendado é a utilização do MUNGE (MUNGE, 2017).
1
2 INSTALAÇÃO E CONFIGURAÇÃO DO SLURM
Este capítulo é dividido em 4 subseções: na subseção 2.1 é realizado uma pré- configuração dos nós do cluster; na subseção 2.2 é realizado a instalação e configura- ção de componentes importantes para o funcionamento do SLURM; na subseção 2.3 é detalhado como é feito o arquivo de configuração do SLURM, necessário para o funcionamento do gerenciador de recursos; e na subseção 2.4 é realizado a instalação e configuração do SLURM.
2.1 Pré-instalação do SLURM
Nesta subseção são relizadas configurações primárias nos nós do cluster, para facilitar o uso do SLURM. Essas configurações devem ser realizadas em todos os nós.
2.1.1 Configuração primárias
Uma das primeiras configurações para realizar no cluster é a sincronização dos ho- rários (horário de software e de hardware) nos nós. Isto é de extrema importância para o funcionamento do MUNGE, caso contrário, o sistema de autenticação pode simplesmente não funcionar ou reconhecer algum dos nós. Para isso é preciso testar se ambos os horários estão compatíveis: $ hwclock $ date
Caso em alguma máquina o horário não esteja de acordo com as demais, o primeiro passo é alterar a hora e data do sistema, após isso, é preciso deixar a hora do sistema e do hardware iguais (hwclock -w). Este procedimento deve ser realizado em todas as máquinas que houverem este problema, incluindo o nó master e os nós slaves: $ date -s mm/dd/aaaa $ date -s hh:mm $ hwclock -w
Para o funcionamento do SLURM e do munge necessita-se que a interface de rede esteja funcionando em todas as máquinas e que elas estejam conseguindo se co- municar através da rede. Caso alguma máquina apresente problema e possuua o CentOS 7 ou superior, é preciso ativar a placa de rede e habilitar que ela se conecte automaticamente: $ nmtui
3 Será apresentado uma interface para editar as interfaces de rede, selecione a interface de rede que o cabo está conectado e ative a conexão. Após isso, é preciso marcar a opção "conectar automaticamente". Para verificar se os nós estão conseguindo se comunicar basta dar um ping para os demais nós.
2.1.2 Configuração NFS
O Network File System (NFS) é um sitema de arquivos usado para compartilhar arquivos e diretórios entre computadores de uma rede, possibilitando assim que os arquivos estejam em uma única máquina e nas demais seja criada um endereço virtual do diretório, fazendo com que todas as máquinas tenham os mesmos dados simultaneamente. A instalação do NFS deve ser realizada em todos os nós do cluster:
$ yum install nfs4-acl-tools.x86_64 nfs-utils-lib.x86_64 nfs-utils.x86_64 -y
Agora a configuração será diferente para os nós. Primeiro é preciso configurar so- mente o nó que irá exportar o diretório para as demais nó:
$ vi /etc/exports
Neste arquivo, o próximo passo é definir o diretório e o IP (Internet Protocol) ou clase de IP que poderá importa-la. O primeiro item é a pasta que será clonada, seguido da classe de ip que terão essa permissão, como mostra o exemplo:
/home 192.168.100.0/24(rw,root_squash,sync) /home 192.168.10.125(rw,root_squash,sync)
No primeiro exemplo acima, foi utilizado uma faixa de IP (192.168.100.0/24), repre- sentando que toda a faixa de IP’s de 192.168.100.0 a 192.168.100.255 com máscara de sub-rede 255.255.255.0 terão a permissão de acesso. No segundo exemplo, foi defi- nido que somente o ip pré-definido (192.168.10.125) poderá importar este diretório.
Agora é preciso fazer a configuração em cada nó que deseja importar o diretório. Para isso, é preciso editar o seguinte arquivo:
$ vi /etc/fstab
Neste arquivo deve ser colocado o endereço de IP e o diretório da pasta que será importado e para que local da máquina local será importado:
192.168.100.10:/home /home nfs defaults 0 0
4 É importante perceber que primeiro é colocado o endereço de IP que será importado junto com o diretório (192.168.100.10:/home) e o segundo parâmetro é colocado onde esta pasta será clonada (/home). Após concluído é preciso dar o comando de montagem, para importar a pasta: mount -a
2.1.3 Configuração dos Hosts
Para facilitar a comunicação entre os nós, é recomendado que se associar o endereço IP de cada host com um hostname. Assim, sempre que um nó necessitar realizar uma comunicação com qualquer outro nó é utilizado somente o hostname ao invés do endereço de IP. Para isso, a configuração deve ser feita no seguinte arquivo:
$ vi /etc/hosts
Neste arquivo é preciso adicionar os endereços IP com seu hostname respectivamente, como mostra o exemplo abaixo:
192.168.100.254 nogw 192.168.100.250 no00 192.168.100.251 no01
É importante cadastrar todos os nós do cluster, inclusive o nó que está sendo feita a configuração. Entretanto, mesmo que essa configuração seja feita, ainda assim o nó master precisa utilizar senha para conectar-se via ssh com outro nó, por este motivo é preciso criar chave pública e privada no nó master e configurar nos demais nós. Para isso, é preciso ficar com o usuário que se deseja utilizar o ssh sem senha (neste caso utilizei o usuário supim-davs) e seguir os seguintes passos:
$ su supim-davs $ cd ~ $ cd .ssh/ $ ssh-keygen
Após ssh-keygen é preciso aceitar as 4 opções iniciais sem alterações e não adicionar passphrase. Agora é preciso copiar a chave pública para o arquivo authorized_keys, e depois copiar este arquivo para todos os nós slaves:
$ cat .ssh/id_rsa.pub > .ssh/authorized_keys $ chmod 600 .ssh/authorized_keys
5 $ scp authorized_keys supim-davs@no00:~/.ssh $ scp authorized_keys supim-davs@no01:~/.ssh
A partir de agora, sempre que solicitado um ssh para um outro nó a senha não será solicitada. Recomenda-se que faça o mesmo procedimento com o usuário que irá gerenciar o SLURM.
2.2 Instalação dos componentes necessários e do SLURM
Após configurado os nós do cluster, é preciso instalar e configurar alguns componen- tes para o funcionamento do SLURM.
2.2.1 Criação dos usuários necessários
O próximo passo é criar usuários do MUNGE e do SLURM. É importante ressaltar que estes procedimentos devem ser repetido igualmente em todos os nós do cluster, pois os usuários devem ter o mesmo UID e GID em todos os nós.
$ export MUNGEUSER=991 $ groupadd -g $MUNGEUSER munge $ useradd -m -c "MUNGE Uid ’N’ Gid Emporium" -d /var/lib/munge -u $MUNGEUSER -g munge -s /sbin/nologin munge $ export SLURMUSER=992 $ groupadd -g $SLURMUSER slurm $ useradd -m -c "SLURM workload manager" -d /var/lib/slurm -u $SLURMUSER -g slurm -s /bin/bash slurm
2.2.2 Instalação do EPEL
Para instalação dos demais pacotes é preciso instalar Extra Packages for Enterprise Linux (EPEL). A instalação do epel irá depender da versão do sistema que está sendo utilizado, caso os nós possuem CentOS 7:
$ yum install https://dl.fedoraproject.org/pub/epel/ epel-release-latest-7.noarch.rpm -y
Caso os nós estejam utilizando um sistema operacional diferente ou outra versão e dê erro na instalação, é preciso verificar a versão do sistema:
$ cat /etc/redhat-release
6 Com essa informação é preciso acessar o diretório do EPEL: https://dl.fedoraproject.org/pub/epel/ e baixar uma versão que funcione no seu sistema operacional. Inicialmente certifique-se que o EPEL não está instalado ou parcialmente instalado e realize o download e a instalação do pacote baixado:
$ yum remove epel-release $ rm /etc/yum.repos.d/epel* $ wget https://dl.fedoraproject.org/pub/epel/ epel-release-latest-6.noarch.rpm $ sudo rpm -Uvh epel-release-6*.rpm
2.2.3 Instalação e configuração do MUNGE
Após realizaAo a instalação do EPEL em todos os nós, o próximo passo é realizar a instalação do MUNGE:
$ yum install munge munge-libs munge-devel -y
Em alguns casos pode acontecer algum erro durante a instalação do MUNGE. Para resolver isso certifique-se que o EPEL foi instalado corretamente em todos os nós e caso seja necessário refaça a instalação prestando atenção a sua versão do sistema operacional.
Após instalado o MUNGE, é preciso configurar a chave MUNGE. Para isso, é criado a chave em somente um nó e repassado para os demais, certificando-se que todos os nós do cluster irão possuir a chave idêntica (DUNLAP, 2017).
$ dd if=/dev/urandom bs=1 count=1024 > /etc/munge/munge.key $ chown munge: /etc/munge/munge.key $ chmod 400 /etc/munge/munge.key
Com a chave criada, é preciso copia-la para todos os outros nós e também certificar- se que o dono da chave é o usuário MUNGE e tenha permissão sobre o arquivo:
$ scp /etc/munge/munge.key root@no01:/etc/munge/munge.key $ ssh no01 $ chown munge: /etc/munge/munge.key $ chmod 400 /etc/munge/munge.key
Agora é necessario configurar os endereços dos logs, este procedimento deve ser realizado em todos os nós:
7 $ chown -R munge: /etc/munge/ /var/log/munge/ $ chmod 0700 /etc/munge/ /var/log/munge/
Depois de configuradA as chaves e os arquivos logs é possível iniciar o processo MUNGE em todos os nós, caso esteja utilizando CentOS 7:
$ systemctl enable munge $ systemctl start munge $ systemctl status munge
Caso seja o CentOS 6 ou inferior, o processo já está ativo e é preciso apenas iniciar o munge:
$ service munge start
InicIado o processo em todos os nós, é possível realizado uma verificação das chaves MUNGE:
$ munge -n | ssh no01 unmunge
O resultado deve ser parecido com o seguinte:
STATUS: Success (0) ENCODE_HOST: no03 (10.10.6.17) ENCODE_TIME: 2016-05-24 10:23:32 -0300 (1464096212) DECODE_TIME: 2016-05-24 10:24:05 -0300 (1464096245) TTL: 300 CIPHER: aes128(4) MAC: sha1(3) ZIP: none(0) UID: root(0) GID: root(0) LENGTH : 0
Lembrando que o STATUS deve estar Success. Caso seja outra saída é preciso veri- ficar na documentação do MUNGE e resolver o problema.
2.2.4 Instalação de componentes para o funcionamento do SLURM
Antes de realizar a instalação do SLURM é preciso instalar pacotes que são pré- requisitos e alguns opcionais para o funcionamento do SLURM:
8 $ yum install openssl openssl-devel pam-devel numactl numactl-devel hwloc hwloc-devel lua lua-devel gcc g++ readline-devel rrdtool-devel ncurses-devel man2html libibmad libibumad perl-ExtUtils-MakeMaker perl-Switch -y
O SLURM também necessita de um banco de dados. Em sua documentação recomenda-se que use o MariaDB (MARIADB, 2017). Porém, caso já tenha outro ge- renciador de banco de dados no cluster, como o MySQL (MYSQL, 2017), o SLURM também funciona perfeitamente. Nesta instalação obtamos por utilizar o MySQL. O passo a passo para instalação do MariaDB:
$ yum install mariadb-server mariadb-devel -y
Caso dê erro na instalação via terminal, é possível realizar o download manualmente do banco de dados no site oficial:
$ wget http://yum.mariadb.org/5.5/rhel6-x86/rpms/
2.3 Criação do arquivo de configuração para o SLURM
O arquivo de configuração do SLURM (slurm.conf) é um arquivo que descreve as informações de configurações sobre os nós e suas partições, e vários outras informações importantes para o funcionamento do SLURM. Após feito o down- load do SLURM, é possível encontrar um exemplo de arquivo de configuração em slurm/etc/slurm.conf.example. O SLURM também oferece uma página HTML para fazer gerar um arquivo de configuração, que pode ser encontrado em: slurm/- doc/html/configurator.html.in.
O local do arquivo de configuração pode ser alterado na variável DEFAULT_- SLURM_CONF, no caso desta instalação o arquivo será mantido nos diretórios padrões (SCHEDMD, 2017)
$ cp slurm.conf /etc/slurm $ cp slurm.conf /usr/local/etc/
Umas das variáveis mais importantes do arquivo de configuração são as informações relacionadas a máquina que será o nó slave. A primeira variável é o nome do nó, que está configurado no arquivo /etc/hosts mostrado na primeiro capítulo deste manual. A seguinda variável (ClusterName), é o nome do cluster que poderá ser reconhecido
9 pelo banco de dados e a última variável é o endereço de IP na rede do nó master, um exemplo de configuração destas variáveis: ControlMachine=nogw.localdomain ClusterName=cluster ControlAddr=10.10.6.15
A variáveis A SEGUIR representam configurações básicas de usuários, tipo de sis- tema de autenticação utilizado, localização de logs e backup e endereços dos arquivos que salvam o número do processo, tanto no nó master como no slave. MailProg=/bin/mail ReturnToService=0 SlurmctldPort=6817 SlurmdPort=6818 SlurmUser=slurm AuthType=auth/munge StateSaveLocation=/var/spool SwitchType=switch/none TaskPlugin=task/none MpiDefault=none SlurmctldPidFile=/var/run/slurmctld.pid SlurmdPidFile=/var/run/slurmd.pid ProctrackType=proctrack/pgid
A SlurmdSpoolDir é uma das variável mais importantes dos nós slaves. Este endereço representa onde estará o que o job está executando. Assim que o job terminar a execução, este diretório é excluído. SlurmdSpoolDir=/var/spool/slurmd
A variável SlurmctldTimeout representa quanto tempo LEVA, após o nó master não responder para acionar o backup. Já o SlurmdTimeout representa quanto tempo o master irá aguardar pela resposta do slave para coloca-lo como down. SlurmctldTimeout=300 SlurmdTimeout=300 InactiveLimit=0 MinJobAge=300 KillWait=30 Waittime =0
10 O SLURM possui alguns tipos de escalonadores de tarefas. O que é utilizado neste trabalho chama-se backfill, que é baseado no modelo First-in First-out (FIFO) e começa com prioridades mais baixas. SchedulerType=sched/backfill SelectType=select/linear FastSchedule=1
Na opção SelectType é possível configurar como será feita as submissões. No caso de linear cada nó irá receber somente um job ou um grupo de job, caso a variável seja configurada como select/cons res, será permitido que mais jobs sejam submetidos no nó, caso essa opção seja selecionada, é preciso adicionar mais um campo, informando qual recurso será solicitado na submissão, SelectTypeParameters=CR CPU Memory, neste caso por CPU e/ou Memória.
O SLURM também armazena logs de execução em todos os nós, facilitando caso necessário realizar alguma consulta. As variáveis a seguir representam o local de cada log bem como suas configurações. AccountingStorageType=accounting_storage/none #JobAcctGatherFrequency=30 JobAcctGatherType=jobacct_gather/none SlurmctldDebug=3 SlurmctldLogFile=/var/log/slurmctld.log SlurmdDebug=3 SlurmdLogFile=/var/log/slurmd.log
A configuração dos nós deve ser feita individualmente. O NodeName é o nome como o nó master irá identificar os nós master. Neste caso não foi utilizado NodeHostname. Caso seja necessário deve conter o nome configurado no próprio nó. É possível obter o nome através do comando: /bin/hostname -s.O NodeAddr indica o endereço IP do nó cadastrado, CPU, RealMemory, Sockets, CoresPerSocket e ThreadsPerCore indicam as configurações do nó, é importante que essas informações estejam corretas. A opção State representa o estado inicial do nó.
A seguir são mostrados dois exemplos de declarações do nós. Na primeira é declarado somente um nó, com suas configurações. Já na segunda são configurados 8 nós com seus respectivos endereços IP’s. É importante perceber que é possível configurar vários nós na mesma linha, mesmo que os NodeName e seus respectivos endereços IP’s não sejam sequencias, bastando somente que tenham as mesmas configurações.
11 #COMPUTENODES NodeName=no00 NodeAddr=192.168.100.250 CPUs=8 RealMemory=72466 Sockets=2 CoresPerSocket=4 ThreadsPerCore=1 State=UNKNOWN NodeName=no[01-05, 07-09] NodeAddr=192.168.100.[240-244, 246-248] CPUs=8 RealMemory=72466 Sockets=2 CoresPerSocket=4 ThreadsPerCore=1 State=UNKNOWN
Após a configuração dos nós de processamento, é preciso criar as partitions, onde é possível agrupar nós com configurações semelhantes. No exemplo também é adici- onado a variável (OverSubscribe), permitindo que seja possível submeter mais jobs do que o total de CPUs disponíveis no nó. #PARTITION PartitionName=desenvolvimento Nodes=no0[0-7] Default=YES MaxTime=INFINITE State=UP OverSubscribe=FORCE
2.4 Instalação do SLURM
A primeira parte da instalação do SLURM deve ser realizada em todos os nós, incluindo o nó master e os nós slaves. Somente algumas configurações posteriores serão diferentes. O download do SLURM deve ser feito de maneira manual do site do desenvolvedor (SLURM, 2017a). Recomenda-se baixar a última versão estável do SLURM. $ wget www.schedmd.com/download/latest/slurm-15.08.11.tar .bz2
A instalação do SLURM é realizada utilizando o rpmbuild. Para isso, caso não tenha instalado no nó, é preciso instalar: $ yum install rpm-build
Após instalado, vá a pasta onde foi feito o donwload do SLURM e execute os se- guintes comandos para a instalação: $ rpmbuild -ta slurm-x.y.z.tar.bz2 $ tar -jxvf slurm-x.y.z.tar.bz2 $ cd slurm-x.y.z.tar.bz2 $./configure $ make $ make check
12 $ make install $ make installcheck
Como no SLURM um dos nós é utilizado como master, responsável por delegar jobs, e os demais nós serão slave, a instalação e configuração dos arquivos rpm são diferentes.
2.4.1 Configuração dos nós Slave
Após realizados os comandos utilizando o rpmbuild, agora é preciso instalar alguns pacotes rpm manualmente (NIFLHEIM, 2017)
$ cd /root/rpmbuild/RPMS/x86_64 $ rpm --install slurm-plugins* $ rpm --install slurm-* $ rpm --install slurm-devel* $ rpm --install slurm-munge* $ rpm --install slurm-sql* $ rpm --install slurm-slurmdbd*
O próximo passo é criar os arquivos de log e alterar suas permissões para o usuário SLURM:
$ mkdir /var/spool/slurmd $ chown slurm: /var/spool/slurmd $ chmod 755 /var/spool/slurmd $ touch /var/log/slurmd.log $ chown slurm: /var/log/slurmd.log
Como já foi feito o arquivo de configuração do SLURM na seção 2.3 é preciso copiá-lo para as seguintes diretórios:
$ cp slurm.conf /etc/slurm $ cp slurm.conf /usr/local/etc/
Para ver a configuração da máquina que está sendo configurada é preciso digitar o seguinte comando:
$ slurmd -C
É muito importante que a configuração que apareça neste comando seja a mesma
13 adicionada ao arquivo de configuração, caso contrário, o SLURM pode colocar esta máquina para "DRAIN"somente pelo fato das configurações não estarem coerentes.
Após instalado e configurado, o próximo passo é ativar o serviço SLURM e colocá-lo para executar (esta configuração é válida caso esteja utilizando o CentOS 7):
$ su slurm $ systemctl enable slurmd.service $ systemctl start slurmd.service $ systemctl status slurmd.service
Caso esteja utilizando o CentOS 6, é preciso somente colocar rodar o serviço:
$ service slurmd start
Para verificar se o serviço foi ativado, é possível verificar no log do próprio SLURM:
$ slurmd -DDD
O último passo é fazer com que o SLURM e o MUNGE sejam inicializados junto ao sistema:
$ vi /etc/rc.d/rc.local
Neste arquivo é preciso colocar os seguintes comandos: service slurm start service munge start
Lembrando que é necessário configurar o Firewall após a instalação e configuração em todos os nós slaves e no master, como é mostrado na seção 2.4.3.
2.4.2 Configuração do nó Master
Igualmente como nos nós slaves, no nó master também é preciso instalar alguns pacotes rpm manualmente. É importante que estes sejam instalados nesta ordem, devido alguns terem depedências:
$ cd /root/rpmbuild/RPMS/x86_64 $ rpm --install slurm-plugins* $ rpm --install slurm* $ rpm --install slurm-devel* $ rpm --install slurm-munge*
14 $ rpm --install slurm-perlapi* $ rpm --install slurm-sjobexit* $ rpm --install slurm-sjstat* $ rpm --install slurm-torque*
Depois de instalado é preciso criar alguns diretórios e arquivos de log, também alterar suas permissões e dono dos arquivos: $ mkdir /var/spool/slurmctld $ chown slurm: /var/spool/slurmctld $ chmod 755 /var/spool/slurmctld $ touch /var/log/slurmctld.log $ chown slurm: /var/log/slurmctld.log $ touch /var/log/slurm_jobacct.log $ touch /var/log/slurm_jobcomp.log $ chown slurm: /var/log/slurm_jobacct.log $ chown slurm: /var/log/slurm_jobcomp.log $ chown -R slurm: /var/spool/
Assim como os nós slaves, também é preciso ter o arquivo de configuração e copiá-los para dois diretórios: $ cp slurm.conf /etc/slurm $ cp slurm.conf /usr/local/etc/
Diferente dos nós slaves, que o nome do processo é slurmd, no nó master o nome do processo é slurmctld e é preciso ativá-lo e coloca-lo em execução, de preferência com o usuário slurm: $ su slurm $ systemctl enable slurmctld.service $ systemctl start slurmctld.service $ systemctl status slurmctld.service
Caso esteja utilizando o CentOS 6 é preciso somente iniciar o processo: $ su slurm $ service slurmd start
Após tudo configurado, é possível colocar todos os nós slaves como IDLE, onde o nó slave está pronto para ser usado:
15 $ scontrol update NodeName=no01 State=IDLE $ scontrol update NodeName=no02 State=IDLE $ scontrol update NodeName=no03 State=IDLE $ scontrol update NodeName=no04 State=IDLE {..}
Para verificar se os nós ficaram ativos é preciso digitar o seguinte comando:
$ sinfo
Caso algum nó esteja com um ’*’, é um sinal que está com algum problema e é preciso verificar. Primeiramente verifique se o MUNGE está executando corretamente. Após isso, verifique as configurações do slurm. Caso o problema persistir, verifique a seção 3.2 onde consta a resolução de alguns erros que podem ocorrer.
2.4.3 Configuração do Firewall
A configuração do firewall é de suma importante. Caso não configurado, um nó não conseguirá se comunicar com os demais na rede. Para que o nós consigam se comu- nicar, existem duas maneiras. Na primeira é preciso instalar o firewall e configurar a classe de IP’s que terá permissão para se comunicar:
$ yum install firewalld firewall-config $ firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT_direct 0 -s 10.10.0.0/16 -j ACCEPT
Outra maneira é desativar o firewall da máquina, possibilitando assim que o nó se comunique com qualquer outro nó da rede:
$ systemctl stop firewalld $ systemctl disable firewalld
Caso esteja utilizando o CentOS 6, é preciso somente desativar o iptables:
$ chkconfig iptables off
16 3 COMANDOS BÁSICOS E POSSÍVEIS ERROS
Neste capítulo serão mostrados os comandos básicos para manutenção dos nós e também algum dos possíveis erros e soluções que podem ocorrer nos nós.
3.1 Comandos Básicos
Os comandos básicos foram divididos em alguns tópicos, para facilitar na hora da procura. Lembrando que os comandos possuem vários parâmetros que alteram o resultado, aqui será mostrado somente os comandos básicos e os comandos com alguns parâmetros que foram julgados importantes.
Os primeiros comandos são para obter informações a respeito dos nós e das partition. Os demais parâmetros podem ser vistos em (SLURM, 2017c):
• sinfo : informação geral do estado de cada partition;
• sinfo -N -l : informações detalhadas de cada nó slave;
• sinfo -R : informações referente a todos os nós que estiverem com problema;
• scontrol show partitions : resulta nas informações completas de cada partition;
Para controlar os nós, é utilizado o comando scontrol (SLURM, 2017b):
• scontrol : Os principais estados dos nós são ALLOCATED (quando o nó está alocado para algum job), DOWN (nó está desligado ou com problema), IDLE (nó está pronto para ser usado) e DRAIN (o nó está realizando um job, mas não pode ser alocado para outro job) exemplo de comando: scontrol update NodeName=no00 State=idle.
Outro tópico é para fazer a verificação das configurações do SLURM e do munge.
• munge -n | ssh no* unmunge : assim é realizado uma conexão ssh com munge para verificar se o funcionamento do munge;
• scontrol show config : mostra a configuração do SLURM, informações esta pre- sente no arquivo de configuração.
Por último temos os comandos para gerenciar os jobs:
17 • sbatch script.sh : submete o arquivo "script.sh"no primeiro nó disponível;
• squeue : lista informações dos jobs que estão em execução ou na fila de execução;
• scancel 10 : força o job parar de execução, neste caso, está sendo forçado o job com id 10 parar;
• scontrol show jobs : mostra informações mais detalhadas dos jobs em execução;
• sbatch –partition=desenvolvimento script.sh : força o job executar em uma partition específica. Neste caso o job irá rodar na partition desenvolvi- mento;
• sbatch -o slurmOUT.out -e slurm*.err script.sh : neste exemplo força que a saída da execução e erro sejam para arquivos específicos.
3.2 Possíveis Erros
Nesta subseção são mostrados alguns possíveis erros e possívels correções na comu- nicação e funcionando do SLURM e do MUNGE.
3.2.1 Problemas com o status do nó
3.2.1.1 Status do nó com *
Quando for verificar o status dos nós slaves e algum deles estiver com um ’*’, é provável que o nó slave esteja com algum problema. O mais provável é que o SLURM ou o MUNGE não estejam executando. O ’*’ significa que o nó master irá tentar se comunicar até dar timeout.
Para verificar o nó slave é preciso executar os seguintes comandos: $ service munge status $ service munge start
Caso os dois serviços estejam executando, é possível verificar a possível causa direto no nó master, executando o seguinte comando: $ sinfo -R
3.2.1.2 Verificação da chave munge
No nó master é possível verificar se a chave munge está correta em todos os outros nós. Para isso é preciso executar o seguinte comando:
18 $ munge -n | ssh no* unmunge
O resultado deve ser parecido com este:
STATUS: Success (0) ENCODE_HOST: nogw.localdomain (10.10.6.15) ENCODE_TIME: 2017-01-13 11:09:09 (1484312949) DECODE_TIME: 2017-01-13 11:12:34 (1484313154) TTL: 300 CIPHER: aes128(4) MAC: sha1(3) ZIP: none(0) UID: root(0) GID: root(0) LENGTH : 0
É importante que na campo STATUS o resultado seja Success. Caso não esteja funcionando a comunicação, um dos motivos pode ser que as máquinas não estejam com os relógios sincronizados.
3.2.1.3 Permissões nas pastas
Caso esteja tudo rodando e mesmo assim não seja. possível submeter jobs nos demais nós, verifique a permissão deste diretório.
$ ls -lart /var/spool/slurmd/
Caso estejam incorretas, verifique a configuração de todos os diretórios e arquivos :
$ chown slurm: /var/spool/slurmctld $ chmod 755 /var/spool/slurmctld $ chown slurm: /var/log/slurmctld.log $ chown slurm: /var/log/slurm_jobacct.log /var/log/slurm_jobcomp.log $ chown -R slurm: /var/spool/
19
4 CONCLUSÕES
Este manual documentou a instalação e funcionamento de um sistema usado para simular e prever o comportamento da ionosfera terrestre, chamado como SUPIM- DAVS (PUNTEL et al., 2015). Esta atividade é desenvolvida dentro do Programa de Clima Espacial do INPE. Inicialmente foi apresentada a estrutura com seus diretó- rios, bem como a funcionalidade de cada um. Após isso todo o funcionamento do código, desde o arquivo de configuração até a geração de imagens e finalização da simulação.
Espera-se que este manual sirva como guia para a equipe responsável pela manu- tenção e operação diária nas previsões ionosféricas da América do Sul e do Globo. O código pode ser alterado, bem como alguns diretórios adicionados, porém acredi- tamos que a estrutura principal do Sistema deve ser mantida.
21
REFERÊNCIAS BIBLIOGRÁFICAS
DUNLAP, C. Installation Guide. 01 2017. Disponível em:
MARIADB. The MariaDB Foundation. 1 2017. Disponível em:
MUNGE. MUNGE Uid ’N’ Gid Emporium. 01 2017. Disponível em:
MYSQL. MySQL. 01 2017. Disponível em:
NIFLHEIM. Slurm Installation. 01 2017. Disponível em:
PUNTEL, F. E.; PETRY, A.; SOUZA, J. R. d.; VELHO, H. F. d. C. Sistema para previsão operacional da dinâmica da ionosfera baseado no Modelo SUPIM v2. São José dos Campos: Instituto Nacional de Pesquisas Espaciais, 2015. 34 p. Disponível em:
SCHEDMD. Slurm.conf. 01 2017. Disponível em:
SLURM. Download Slurm. 01 2017. Disponível em:
. Scontrol. 02 2017. Disponível em:
. SINFO. 02 2017. Disponível em:
23