Avaliação de Desempenho da Rede de Interconexão do Cluster HPC Netuno

Transcrição

1 Davi Vercillo Carneiro Garcia Marcelo Jochem da Silva Renan Iglesias Alves de Rezende Avaliação de Desempenho da Rede de Interconexão do Cluster HPC Netuno Rio de Janeiro, Brasil 24 de julho de 2013

2 Davi Vercillo Carneiro Garcia Marcelo Jochem da Silva Renan Iglesias Alves de Rezende Avaliação de Desempenho da Rede de Interconexão do Cluster HPC Netuno Monografia apresentada para obtenção do Grau de Bacharel em Ciência da Computação pela Universidade Federal do Rio de Janeiro. Orientador: Prof. D.Sc. Gabriel Pereira da Silva Curso de Bacharelado em Ciência da Computação Universidade Federal do Rio de Janeiro Rio de Janeiro, Brasil 24 de julho de 2013

3 Avaliação de Desempenho da Rede de Interconexão do Cluster HPC Netuno Davi Vercillo Carneiro Garcia Marcelo Jochem da Silva Renan Iglesias Alves de Rezende Projeto Final de Curso submetido ao Departamento de Ciência da Computação do Instituto de Matemática da Universidade Federal do Rio de Janeiro como parte dos requisitos necessários para obtenção do grau de Bacharel em Ciência da Computação. Apresentado por: Davi Vercillo Carneiro Garcia Marcelo Jochem da Silva Aprovado por: Renan Iglesias Alves de Rezende Prof. D.Sc. Gabriel Pereira da Silva Universidade Federal do Rio de Janeiro Orientador Prof. D.Sc. Silvana Rosseto Universidade Federal do Rio de Janeiro Prof. D.Sc. Juliana Vianna Valério Universidade Federal do Rio de Janeiro Rio de Janeiro, Brasil 10 de Junho de 2012

4 Resumo Avaliação de Desempenho da Rede de Interconexão do Cluster HPC Netuno Davi Vercillo Carneiro Garcia Marcelo Jochem da Silva Renan Iglesias Alves de Rezende Orientador: Prof. D.Sc. Gabriel Pereira da Silva Clusters de alto desempenho, também conhecidos como clusters HPC, são sistemas computacionais de grande porte, voltados para a resolução de problemas computacionais complexos. Eles tem sido cada vez mais utilizados por instituições de pesquisa e empresas de uma maneira geral. A análise de desempenho de clusters HPC é uma tarefa não-trivial, uma vez que o desempenho de um cluster depende de diversos fatores, tais como uma escolha balanceada das configurações de seus nós, de sua rede de interconexão de dados, de seu sistema de armazenamento e, não menos importante, dos softwares de gerenciamento e submissão de tarefas. O objetivo deste trabalho é analisar o desempenho do cluster Netuno, localizado na Universidade Federal do Rio de Janeiro (UFRJ), além de procurar possíveis gargalos em sua rede de interconexão. Para isto, primeiro foi levantado um panorama das características e configurações dos equipamentos, além das tecnologias utilizadas no Netuno. Após isso, testes foram realizados a fim de monitorar o tráfego na interfaces de rede dos nós e do sistema de armazenamento.

5 Abstract Performance Evaluation Of Netuno s HPC Cluster Interconnection Network Davi Vercillo Carneiro Garcia Marcelo Jochem da Silva Renan Iglesias Alves de Rezende Supervisor: Prof. D.Sc. Gabriel Pereira da Silva High-performance clusters, also called HPC clusters, are large computational systems used for solving complex computational problems. They have been increasingly used by research institutions and companies in general. Performance evaluation of HPC clusters isn t a trivial task, once the cluster s performance depends on several factors, such as a choice of well-balanced configurations of its nodes, its interconnection network, its storage system and its softwares for management and tasks submission. This project s aim is analyze the Netuno s cluster performance, located at Federal University of Rio de Janeiro (UFRJ), and also search possible bottlenecks in its interconnection network. So, first was raised equipment s features and configurations overview, and also the technologies used by Netuno. After that, benchmarking tests have been performed intending monitor the network traffic of nodes interfaces as well as its storage system.

6 Aos nossos pais e à todos aqueles que nos deram apoio sempre que necessário.

7 Agradecimentos Durante toda a nossa vida, devemos sempre agradecer primeiro a aquele que nos provê força e energia para superar todos os obstáculos que encontramos. Agradeço a Deus por isso. Em segundo lugar, mas não menos importante, devemos agradecer aqueles que nos trouxeram para a vida, nos dão amor e carinho e que sempre estão presentes nos momentos difíceis. Agradeço imensamente a minha mãe, Denise Cristina Vercillo Carneiro Garcia, ao meu pai, Sergio Monteiro Garcia, e ao resto da minha família. Gostaria de incluir nessa categoria também minha namorada, Juliana Trindade Ramos. Não posso esquecer dos amigos que fiz durante toda a vida acadêmica pois em eles tenho certeza que a minha trajetória teria sido bem mais difícil. Estivemos juntos na alegria e na tristeza, somando forças. Agradeço a todos da turma 2006/02, mas em especial aqueles que estiveram sempre juntos: Patrícia Zudio, Bianca Lima, Carolina Szkruc, Bruno Buss, Thiago Elias Gomes, Flávio França, Diogo Borges, Diego Xavier, Diego Cardoso, Vinícius Ribeiro e Pedro Alberto Gomes. Agradeço também a todos os professores e prestadores que dispuseram de tempo e paciência para me ensinar toda minha vida acadêmica. Reconheço que estes momentos são inestimáveis e foram essenciais para minha formação. Um agradecimento a todos que estiveram presentes e um agradecimento especial a Myrian Costa, Albino Aveleda, Gabriel P. Silva, Álvaro Coutinho e Orlando Caldas. Finalmente não posso esquecer daqueles que aceitaram essa última empreitada comigo. Sem estes, tenho certeza que não seria possível ter concluído este estudo. Agradeço imensamente ao Marcelo Jochem e ao Renan Iglesias. Davi Vercillo Carneiro Garcia

8 Agradeço acima de tudo Deus, pela força e saúde para conseguir terminar esse projeto, e, não menos importante, a meus pais, pelo exemplo de caráter, inteligência e honestidade, além dos ensinamentos e apoio incondicionais em todos os momentos. Nenhum ensinamento acadêmico supera os que meu pai, Leno, e minha mãe, Luciane, me transmitiram durante toda a vida. Agradeço a minha namorada, Amanda, pela paciência e compreensão ao longo dessa realização. Sem você para me dizer que tudo ia dar certo, não sei como iria ter forças para continuar. Agradeço a meu orientador, Gabriel Pereira da Silva, e a Sergio Guedes, pelas lições, experiências e ajuda fornecidas no decorrer do desenvolvimento desse projeto, além do Guilherme Alves, pela ajuda nos momentos finais da monografia. Agradeço ainda a todos os Professores que tive em minha vida, me ajudando a ser, a cada dia, uma pessoa melhor. Agradeço ainda a todos os amigos que fiz durante a vida, dentre eles Carlos Eduardo, Erich Oliveira, Felipe Pedrosa, Magno Ferreira, Thiago Elias, Francisco Vianna, Rafael Lopes, Bruno Buss, Diogo Borges, Yanko Gitahy, Letícia Brugger, Marco Antônio, Julio Reuther, Juliana Valério, Tarcisio Pelissari, além dos amigos do LIG-IQ e do laboratório LAND, por tudo que vivemos ao longo desses anos. Agradeço, em especial, a três grandes pessoas: Jonas Arêas, irmão que gostaria de ter, pelos conselhos e pela incondicional amizade ao longo desses anos de faculdade, Flávio Francisco, pela amizade, moradia, conversas e ensinamentos ao longo desses anos, e a Alejandra Klachquin, pela amizade, pelas inúmeras conversas discutindo problemas, acadêmicos ou não, e pela ajuda na correção desse trabalho. Sem essas pessoas, a conquista desse diploma teria sido muito mais difícil do que já foi. Como não poderia deixar de lembrar, agradeço ao Mangue e à EEFD, entre outros locais que me agraciaram com ótimas lembranças que levarei para o resto da vida. E, finalmente, agradeço a meus amigos, Renan Iglesias e Davi Vercillo, companheiros de Projeto Final, pelo entusiasmo e ajuda. Sem eles, esse trabalho não teria a mesma qualidade. Se não lembrei de alguém aqui, minhas sinceras desculpas, mas desejo a todos que estiveram de alguma forma comigo, um muito obrigado. Marcelo Jochem da Silva

9 Antes de mais nada, neste agradecimento eu decidi não citar o nome de ninguém, pois as folhas não comportariam o nome de todas as pessoas e não quero deixar de citar nenhum amigo, professor ou parente. Quero agradecer a meus pais, que sempre me mostraram o caminho certo a ser seguido na vida. Reconheço todo o esforço que eles fizeram para que eu tivesse uma boa educação e eu pudesse chegar aqui hoje em dia e me ensinaram muito sobre honestidade, amizade, compreensão, dentre outros, além de me servirem como fonte de inspiração. Gostaria de agradecer também a todos os meus familiares, tanto os recém-chegados quanto os patriarcas da família, que sempre foram minha fonte de forças nos momentos difíceis da minha vida, e a graduação com certeza foi um deles. Não posso deixar de citar meus avôs que, apesar do pouco contato que tive com eles, tenho certeza que eles estão lá de cima iluminando meu caminho. Agradeço a todos os professores que tive desde o primeiro momento em que eu pisei em uma escola até os dias de hoje. Todos eles sempre me transmitiram uma sabedoria imensa e se cheguei aqui hoje, é por causa das aulas (algumas delas bem entediantes) de todos eles. Um agradecimento em especial aos professores que tive como orientadores em meu estágio durante a graduação, que sempre aceitaram que eu desse mais atenção à minha vida acadêmica do que ao próprio estágio. Fui monitor de dois professores, aos quais agradeço imensamente pela experiência e conhecimento que adquiri com eles. E principalmente ao orientador deste projeto. Agora, sem dúvida, é o agradecimento mais divertido: a todos os meus amigos. Amigos que sempre me aturavam em grupos de estudo correndo atrás da matéria na véspera da prova, amigos que me pediam ajuda com coisas que eu sabia, me ajudando a reforçar meus conhecimentos, amigos que me empurravam nos momentos em que eu tive vontade de desistir de tudo. Agradeço ao bar do Mangue, nosso lugar sagrado de relaxar às sextas-feiras (e outros dias da semana), além de servir como lugar de estudo em vésperas de provas. Meus amigos que, juntamente com uma cerveja e uma mesa de bar, foram sempre meus melhores psicólogos Todas as amizades que fiz desde o momento em que eu nasci até hoje sempre foram importantes, umas mais e outras menos, mas considero todos os meus amigos e me dói muito não citar os nomes de vocês (principalmente dos que ameaçaram se jogar pela janela quando eu disse que não havia citado-os aqui), mas já expliquei anteriormente o motivo. E o agradecimento mais especial de todos é para uma pessoa que entrou em minha vida e mudou meu rumo dentro da universidade. Ela iluminou meu caminho quando eu

10 tive vontade de chutar o balde e com certeza me ajudou a superar as barreiras que eu tive durante a graduação com seu apoio, cobrança, carinho e principalmente pela confiança depositada em mim, que me servia como motivação para que eu fizesse de tudo para não decepcioná-la. Tenho certeza que sem ela, muitas destas barreiras seriam praticamente intransponíveis e dedico esta minha vitória a ela. Muito obrigado mesmo. Também não posso deixar de citar meus dois companheiros neste projeto final. Renan Iglesias Alves de Rezende

11 "Nunca deixe que lhe digam que não vale a pena acreditar nos sonhos que se têem ou que os seus planos nunca vão dar certo ou que você nunca vais ser alguém" Renato Russo

12 Lista de Figuras 1 Cluster Netuno Quadro Ethernet Camadas do modelo OSI Camadas do modelo TCP/IP Exemplo de interconexão de quatro recursos através da malha Busca de um arquivo seguindo a árvore de diretórios do sistema Linha do tempo das diferentes versões do NFS Arquitetura cliente/servidor do NFS Camadas onde se situa o NFS Pilha cliente/servidor do NFS Arquitetura do pnfs no NFSv Exemplo de rack do PanFS Exemplo de chassi do PanFS Visão externa e interna de uma Storage Blade do PanFS Visão externa e interna de uma Director Blade do PanFS Arquitetura básica do PanFS Protocolos suportados pelo PanFS Alguns nós computacionais do Netuno Switch CISCO SFS-7024X Switch CISCO GE Switch CISCO 6509E Diagrama parcial da rede Ethernet do cluster Netuno

13 23 Funcionamento SNMP Tela do Cacti mostrando os dispositivos da rede Tela do Cacti mostrando os gráficos de utilização da rede Acesso N: Acesso N:N Tráfego de uma interface de conexão do Netuno durante o período total de monitoramento do cluster Taxa de leitura variando a quantidade de processos por nó - BS 4 MB/TS 16 KB Taxa de escrita variando a quantidade de processos por nó - BS 4 MB/TS 16 KB Latência ao variar a quantidade de processos por nó - BS 4 MB/TS 16 KB Taxa de leitura variando a quantidade de processos por nó - BS 1 GB/TS 64 MB Taxa de escrita variando a quantidade de processos por nó - BS 1 GB/TS 64 MB Latência ao variar a quantidade de processos por nó - BS 1 GB/TS 64 MB Taxa de leitura variando o tamanho do bloco total (BSIZE) - TS 16 KB/1 PPN/8 Nós Taxa de escrita variando o tamanho do bloco total (BSIZE) - TS 16 KB/1 PPN/8 Nós Taxa de leitura variando o tamanho do bloco total (BSIZE) - TS 16 KB/1 PPN/16 Nós Taxa de escrita variando o tamanho do bloco total (BSIZE) - TS 16 KB/1 PPN/16 Nós Taxa de leitura variando o tamanho do bloco total (BSIZE) - TS 16 KB/1 PPN/32 Nós Taxa de escrita variando o tamanho do bloco total (BSIZE) - TS 16 KB/1 PPN/32 Nós

14 41 Taxa de leitura variando o tamanho do bloco total (BSIZE) - TS 64 MB/1 PPN/8 Nós Taxa de escrita variando o tamanho do bloco total (BSIZE) - TS 64 MB/1 PPN/8 Nós Taxa de leitura variando o tamanho do bloco total (BSIZE) - TS 64 MB/1 PPN/16 Nós Taxa de escrita variando o tamanho do bloco total (BSIZE) - TS 64 MB/1 PPN/16 Nós Taxa de leitura variando o tamanho do bloco total (BSIZE) - TS 64 MB/1 PPN/32 Nós Taxa de escrita variando o tamanho do bloco total (BSIZE) - TS 64 MB/1 PPN/32 Nós Taxa de leitura variando o tamanho do bloco de transferência (TSIZE) - BS 1 GB/1 PPN/8 Nós Taxa de escrita variando o tamanho do bloco de transferência (TSIZE) - BS 1 GB/1 PPN/8 Nós Latência ao variar o tamanho do bloco de transferência (TSIZE) - BS 1 GB/1 PPN/8 Nós Taxa de leitura variando o tamanho do bloco de transferência (TSIZE) - BS 1 GB/1 PPN/16 Nós Taxa de escrita variando o tamanho do bloco de transferência (TSIZE) - BS 1 GB/1 PPN/16 Nós Latência ao variar o tamanho do bloco de transferência (TSIZE) - BS 1 GB/1 PPN/16 Nós Taxa de leitura variando o tamanho do bloco de transferência (TSIZE) - BS 1 GB/1 PPN/32 Nós Taxa de escrita variando o tamanho do bloco de transferência (TSIZE) - BS 1 GB/1 PPN/32 Nós Latência ao variar o tamanho do bloco de transferência (TSIZE) - BS 1 GB/1 PPN/32 Nós

15 56 Taxa de leitura variando a quantidade de processos para determinada tarefa - BS 4MB/TS 16KB Taxa de escrita variando a quantidade de processos para determinada tarefa - BS 4MB/TS 16KB Latência ao variar a quantidade de processos para determinada tarefa - BS 4MB/TS 16KB Taxa de leitura variando a quantidade de processos para determinada tarefa - BS 32GB/TS 64MB Taxa de escrita variando a quantidade de processos para determinada tarefa - BS 32GB/TS 64MB Latência ao variar a quantidade de processos para determinada tarefa - BS 32GB/TS 64MB Interface Te Interface Te Interface Te Interface Te Interface Te Interface Te Interface Te Interface Te Interface Te Interface Te Interface Te Interface Te Interface Te Interface Te Interface Te Interface Te

16 78 Interface Gi Interface Gi Interface Gi Interface Gi Interface Gi Interface Gi Interface Gi Interface Gi Interface Gi Interface Gi Interface Gi Interface Gi

17 Lista de Tabelas 1 Taxa de dados do InfiniBand Vazão efetiva teórica dos enlaces InfiniBand Especificações do Panasas File System Variáveis do sistema de fila PBS/Torque Definição dos parâmetros utilizados no script de teste Taxa média de tráfego das interfaces de conexão do Switch Core aos Switches Topo de Rack do Netuno sob estado idle Taxa média de tráfego das interfaces de conexão do Netuno ao Panasas em período ocioso Taxa média de tráfego das interfaces de conexão do Switch Core aos Switches Topo de Rack do Netuno durante o teste com massa de dados de 1TB Taxa média de tráfego das interfaces de conexão do Netuno ao Panasas durante o teste com massa de dados de 1TB Taxa média de tráfego das interfaces de conexão do Switch Core aos Switches Topo de Rack do Netuno durante uma aplicação real Taxa média de tráfego das interfaces de conexão do Netuno ao Panasas durante a execução de uma aplicação real Taxa média nas interfaces de acesso ao sistema de arquivos remoto nos testes usando 32 e 64 processos Taxa média nas interfaces de acesso ao sistema de arquivos remoto nos testes usando 96 e 128 processos Taxa média nas interfaces de acesso ao sistema de arquivos remoto nos testes usando 192 e 256 processos

18 15 Mapa de conexões dos Switch Racks Mapa de conexões das lâminas do Panasas

19 Sumário 1 Introdução Motivação e problema abordado O Netuno Objetivos Objetivo geral da pesquisa Objetivos específicos da pesquisa Estrutura do trabalho Trabalhos correlatos 27 3 Fundamentação teórica Clusters computacionais Classificação Sistema operacional Redes de interconexão Ethernet InfiniBand Sistemas de armazenamento distribuído NFS CIFS PanFS Protocolo de gerência de redes

20 3.4.1 SNMP Biblioteca de comunicação MPI Arquitetura do cluster Netuno Nós computacionais Nós de acesso Nós de controle Rede de interconexão e de E/S de dados Sistemas de arquivo remoto e distribuído Softwares Sistema operacional Compiladores e implementações MPI Ferramentas adicionais Metodologia Estação de gerência Ferramentas utilizadas Implementação MPI Benchmarking Coleta de dados Funcionamento e parâmetros dos scripts de teste Apresentação e análise dos resultados Padrão de tráfego sob condição idle Padrão de tráfego durante benchmark Padrão de tráfego durante monitoramento de uma aplicação real Avaliação de desempenho

21 6.4.1 Variação da quantidade de tarefas executando em cada nó Variação no tamanho do bloco total (BSIZE) Variação no tamanho do bloco de transferência (TSIZE) Variação no número de processos Considerações finais e trabalhos futuros Problemas encontrados Detecção de possíveis gargalos Outras considerações Trabalhos futuros Referências 118 Apêndice A -- Modelo de script de teste 124 A.1 Script IOR Apêndice B -- Mapa de conexões de rede do Netuno 126 B.1 Switch Rack B.2 Panasas Apêndice C -- Gráficos do tráfego das interfaces durante a aplicação real monitorada 128 C.1 Tráfego nas interfaces da rede de interconexão C.2 Tráfego das interfaces do sistema de armazenamento Apêndice D -- Configuração dos switches 133 D.1 Switch Core D.2 Switch Rack

22 21 1 Introdução O avanço da pesquisa nas mais diversas áreas da ciência e o aumento significativo dos problemas enfrentados pelo homem demandam formas rápidas e eficazes para obtenção de resultados satisfatórios. E, dentre os diversos métodos de estudo, o uso da simulação sempre se destacou. A simulação consiste no emprego de modelos numéricos, muitas vezes baseados em cálculos complexos e extensos, que fornecem resultados que se aproximam bastante do caso real. O aumento de complexidade dos problemas a serem solucionados e a necessidade de aproximações cada vez melhores, determinou que sistemas computacionais de alto desempenho fossem empregados para obter os resultados em tempo viável. Esses sistemas computacionais de grande porte, por vezes chamados de supercomputadores, foram dominantes por muito tempo e forneciam o poder computacional requerido para resolver problemas grandes em pouco tempo. No entanto, o custo operacional de tais máquinas era um fator limitante para que fossem largamente empregadas. Essas máquinas eram compostas por tecnologias de hardware e software proprietárias e complexas, voltadas para alto desempenho. Esses ambientes muitas vezes eram compostos por processadores vetoriais com uso de memória compartilhada, onde poucos profissionais possuíam experiência na sua operação e no desenvolvimento de aplicativos adequados. Ao final do ano de 1993, Donald Becker e Thomas Sterling começaram a esboçar, como uma alternativa de baixo custo para grandes supercomputadores, um sistema computacional composto por diversos computadores convencionais e uma rede de interconexão acessível financeiramente. Durante o verão de 1994, o Projeto Beowulf foi iniciado no Centro de Excelência em Dados Espaciais e Ciências da Informação (CESDIS), uma parceira da Agência Espacial Americana (NASA)(BECKER et al., 1995). O primeiro supercomputador fruto do Projeto Beowulf foi composto por unidades de processamento Intel DX4, de apenas 75 MHz, interconectados por uma rede do tipo

23 1.1 Motivação e problema abordado 22 Ethernet 10BASE-T de 10 Mbps Half-Duplex em um modelo de processamento de memória distribuída. Para diminuir a sobrecarga na rede Ethernet, Donald Becker reescreveu os drivers Ethernet para o sistema operacional Linux, para que o tráfego fosse distribuído por adaptadores distintos. O avanço das tecnologias de processamento e de interconexão convencionais foi um fator decisivo para que o Projeto Beowulf se estabelecesse como uma alternativa tão bem sucedida aos supercomputadores. Além disso, o conjunto de software utilizado para compor o sistema de alto desempenho contribuiu para que os custos de desenvolvimento de aplicações fossem bastante reduzidos. A maturidade e robustez do Linux, dos softwares de sistema do Projeto GNU (General Public License) e do surgimento de padrões para os mecanismos de troca de mensagens, como PVM (Parallel Virtual Machine) e MPI (Message Passing Interface), possibilitaram que as aplicações continuassem compatíveis com o ambiente de execução mesmo após atualizações de hardware e software. Nos anos seguintes, o sucesso do Projeto Beowulf fez com que esse modelo se tornasse o modelo padrão para computadores de alto desempenho, também conhecidos como clusters HPC (High Performance Computing). Atualmente os clusters HPC são compostos por processadores convencionais multicore de altíssima velocidade, podendo uma configuração típica de cluster de alto desempenho facilmente atingir alguns milhares de núcleos. Eles são ainda interconectados por uma rede de alto desempenho e, por vezes, de baixa latência. O conjunto de software é baseado ainda em componentes do projeto GNU e do núcleo do Linux, munido de outros componentes que surgiram para complementar o funcionamento do sistema, como escalonadores de tarefas e sistemas de arquivos paralelos. 1.1 Motivação e problema abordado Como motivação para este trabalho, constatamos que, mesmo com todos os avanços ao longo das décadas, os problemas enfrentados no modelo de sistema computacional Beowulf (cluster HPC) ainda permanecem praticamente os mesmos. Com o aumento da complexidade dos problemas e dos modelos numéricos, a divisão das tarefas e a distribuição de carga entre todos os componentes computacionais dependem de como o modelo foi implementado. Além disso, com o aumento significativo do desempenho dos processadores convencionais e da necessidade de comunicação entre os componentes do cluster, a rede se tornou um gargalo para o sistema e topologias complexas são empregadas para tentar garantir o desempenho satisfatório dos mecanismos de troca de mensagem. E,

24 1.2 O Netuno 23 não menos importante, o desempenho do sistema de armazenamento e a capacidade de permitir acessos simultâneos de leitura e escrita se tornaram fatores importantes. A partir dessa motivação, como o desempenho é uma das principais preocupações em um cluster HPC, iremos estudar o cluster de alto desempenho Netuno, instalado no Instituto Tércio Pacitti de Aplicações e Pesquisas Computacionais (NCE), localizado na Universidade Federal do Rio de Janeiro (UFRJ), Rio de Janeiro, Brasil. Abordaremos desde os principais tópicos teóricos acerca de sua complexa arquitetura, além de avaliar como sua estrutura está interconectada. Por fim, testes de benchmark serão realizados a fim de comparar desempenho utilizando diferentes métricas, além de detectar possíveis gargalos em sua rede de interconexão responsável pelo acesso aos sistemas de armazenamento. 1.2 O Netuno Antes de falarmos o que é o Netuno, primeiramente vamos definir o que é um cluster. Esse é, em suma, um sistema de processamento paralelo, consistindo de vários computadores independentes, o qual damos o nome a cada um de nó. Os nós são interconectados por uma rede, e trabalham de forma paralela e cooperativa para realizar tarefas de alto poder de processamento. A ideia geral do cluster é que os usuários tenham acesso a todos esses nós da forma mais transparente possível e com isso possam extrair o máximo de desempenho dos mesmos. Assim, em operação desde março de 2008, o Netuno é um cluster de pesquisa concebido para atender demandas computacionais de larga escala, sendo responsável pela realização dos cálculos de aplicações de diversas instituições de ensino e pesquisa do Brasil. A maioria destas aplicações são voltadas para pesquisas de geofísica aplicada, incluindo exploração de petróleo e gás, assim como a simulação de correntes oceânicas e modelagem climática. O Projeto Netuno foi financiado pela Agência Nacional do Petróleo, Gás Natural e Biocombustíveis (ANP) e está localizado na Universidade Federal do Rio de Janeiro, mais precisamente no Instituto Tércio Pacitti de Aplicações e Pesquisas Computacionais. Na Figura 1 temos uma fotografia do cluster que é tema de nosso estudo.

25 1.3 Objetivos Objetivos Figura 1: Cluster Netuno Objetivo geral da pesquisa O objetivo deste trabalho é realizar uma avaliação de desempenho do cluster, abordando também a performance da rede de interconexão responsável pelo acesso aos sistemas de armazenamento em massa do cluster de alto desempenho Netuno, tendo como justifica para esse estudo a importância que a rede de interconexão possui no desempenho final do cluster e pela ausência de estudos similares na literatura. Por fim, ele irá compor outros estudos que serão utilizados futuramente como parâmetros para expansão e aperfeiçoamento do cluster em questão, além de prover experiência para novas aquisições Objetivos específicos da pesquisa Esta pesquisa tem como objetivo específico avaliar a infraestrutura de rede que compõe o cluster Netuno, buscando possíveis gargalos no acesso aos dispositivos de armazenamento em massa. A hipótese da existência de gargalos foi levantada inicialmente pelo trabalho realizado pela aluna de iniciação científica Juliana Correa, orientada pelo professor Gabriel P. Silva, apresentado em 2009 no Workshop de Iniciação Científica (CORREA; SILVA, 2009). Nesse trabalho, a partir de testes de entrada e saída (E/S) sobre o sistema de armazenamento Panasas R, foram detectados problemas de desempenho na escrita paralela de arquivos, sendo um possível efeito colateral de possíveis congestionamentos na rede de acesso.

26 1.4 Estrutura do trabalho 25 Além do objetivo principal, este trabalho também tem como objetivo secundário, mas não menos importante, fornecer experiência aos autores sobre mecanismos e plataformas de monitoramento de rede utilizadas no mercado, arquiteturas de comunicação digital e plataformas de armazenamento em massa. 1.4 Estrutura do trabalho Este trabalho está dividido em partes contendo os principais conteúdos relacionados ao tema proposto. São eles: Capítulo 2 - Trabalhos correlatos: Nesse capítulo é feita uma análise dos trabalhos correlatos existentes na literatura a respeito do cluster Netuno, além de abordar alguns trabalhos envolvendo benchmark de clusters HPC. Capítulo 3 - Fundamentação teórica: O objetivo deste capítulo é descrever conceitos que serão explorados ao longo do presente trabalho. Primeiramente, serão explicados os conceitos e a nomenclatura utilizada na infraestrutura de um cluster de alto desempenho. Em seguida, teremos uma descrição das redes de interconexão que compõem o Netuno, além dos sistemas de armazenamento distribuído por ele suportado. Por fim, é apresentada uma introdução sobre o protocolo de gerência de redes e das bibliotecas de comunicação utilizadas nesse estudo. Capítulo 4 - Arquitetura do cluster Netuno: Complementando a fundamentação iniciada no capítulo anterior, nesse capítulo a arquitetura geral do cluster Netuno é esmiuçada, apresentando suas principais características, tais como configurações dos nós, infra-estrutura de rede, sistemas de armazenamento, sistema operacional e softwares em geral, fornecendo uma melhor compreensão do estudo desenvolvido. Capítulo 5 - Metodologia: Nesse capítulo são apresentados o método adotado e o ferramental utilizado para o desenvolvimento deste trabalho, bem como os parâmetros empregados nos testes realizados. Capítulo 6 - Apresentação e análise dos resultados: A apresentação e análise dos resultados para padrões de tráfego em estado ocioso, para os nossos testes e para aplicações

27 1.4 Estrutura do trabalho 26 reais, além de comparações utilizando diferentes métricas será feita nesse capítulo. Capítulo 7 - Considerações finais e trabalhos futuros: As considerações finais obtidas sobre nosso estudo serão encontradas nesse capítulo, juntamente com os trabalhos futuros planejados que não puderam ser completados nesta monografia. Apêndices: Por fim, na parte de apêndices, é encontrado no Apêndice A um modelo do script de teste usado para realizar parte do benchmark nos sistemas de armazenamento, no Apêndice B, os mapas de conexão de rede do Netuno, no Apêndice C, os gráficos do tráfego nas interfaces do switch principal do cluster na aplicação real monitorada, e no Apêndice D, a configuração do Switch Core e de um Switch Rack do Netuno.

28 27 2 Trabalhos correlatos Na literatura encontramos inúmeros trabalhos descrevendo tanto a especificação e importância de clusters de alto desempenho (HPC) quanto avaliações de desempenho referentes a suas redes de interconexão e sistemas de arquivo. Nos trabalhos envolvendo especificação e avaliação de clusters, podemos citar o de Alam et al. (2007), que aborda o cluster Cray XT4 através de micro benchmarks e o de Worley, Kuehn e Barrett (2009), que aborda o Cray XT5, avaliando seu desempenho e comparando-o com o XT4. Já a arquitetura do Blue Gene R /L é avaliada nos trabalhos de Gara et al. (2005), e de Kerbyson e Hoisie (2006). No primeiro, uma descrição do projeto é feita, focada em uma abordagem baseada em aplicações. Já no segundo artigo, o desempenho do Blue Gene é avaliado através de um modelo detalhado utilizando a aplicação Sweep3D, além de analisar possíveis melhorias na arquitetura do cluster. Um estudo do software e do hardware do Projeto RoadRunner é feita em Komornicki, Mullen-Schulz e Landon (2009) e uma avaliação de sua arquitetura e desempenho através de micro benchmarks e da aplicação Sweep3D é mostrada no trabalho de Barker et al. (2008). Como exemplo de instalações de clusters HPC em Universidades, temos o trabalho de Ginty, Tindle e Tindle (2009), que descreve o cluster localizado na Universidade de Sunderland, Inglaterra. Na parte da aplicações de clusters HPC, o trabalho de Fujisawa et al. (2004) mostra a importância dos clusters de alto desempenho, no que diz respeito ao alto poder de processamento para métodos otimização, abordando alguns problemas de otimização com resultado numéricos; em Sepehrnoori et al. (2001) é descrita a simulação paralela de reservas de petróleo usando clusters de alto desempenho. Na parte de avaliação de servidores de arquivos, temos o estudo de Lauria, Bell e Chien (2002) descrevendo o servidor de armazenamento de alto desempenho do Storage Resource Broker, um sistema de gerenciamento de arquivos presente em muitos projetos de pesquisa internacionais. Nele são incorporadas otimizações que forneceram alto alcance na vazão

29 2 Trabalhos correlatos 28 dos discos através de conexões remotas. No trabalho de Oriani (2010) é encontrada a avaliação de outro sistema de arquivos distribuído, o Hadoop Distributed File System 1 da Apache Software Foundation; em Carns et al. (2000), uma avaliação do PVFS (Parallel Virtual File System) e em Ou e He (2005), é proposto um sistema de arquivo paralelo de alto desempenho baseado no ipvfs. No caso do PanFS, sistema de arquivos distribuído do Netuno, no trabalho de Welch et al. (2008) são apresentadas medidas de desempenho de E/S, metadados e operações de armazenamento para clusters de armazenamento contendo de 10 a 120 nós. Por fim, existem alguns artigos que tratam especificamente do Netuno. Em Silva et al. (2009) é apresentado o projeto de especificação do Netuno, desde detalhes de sua arquitetura, até os softwares básicos utilizados na sua construção. Neste artigo também é mostrada a avaliação de desempenho do cluster Netuno para o benchmark HPL (High Performance Linpack, obtendo naquela época desempenho de 16,2 TFlops. O HPL é a principal avaliação para a lista do Top500 2, com o Netuno atingindo a 138 a posição na lista de junho de Maiores informações sobre o HPL podem ser encontradas nesse mesmo artigo ou em Petitet et al. (2008). No trabalho de Silva et al. (2011) é continuado o trabalho de descrição e avaliação do Netuno, com resultados de testes das bibliotecas de MPI existentes no Netuno, além de avaliações utilizando duas aplicações reais: o HYCOM 3, um simulador numérico de processos oceânicos e o uso do mpiblast 4 para alinhamento de sequências genéticas. Por último, temos o artigo de Correa e Silva (2009), o qual motivou nosso trabalho, em que é feita uma avaliação do sistema de arquivos paralelo do Netuno (PanFS). Nesse artigo, são apresentados os princípios gerais de sistemas de arquivos baseados em objetos, além de testes de eficiência do PanFS. Esses resultados serão revistos e analisados no Cap Informações disponíveis em 2 Informações disponíveis em 3 Informações disponíveis em 4 Informações disponíveis em

30 29 3 Fundamentação teórica 3.1 Clusters computacionais Existem diversas formas de se definir o termo cluster. No entanto, a definição mais simples e usual é do nome dado a um conjunto de computadores capazes de funcionar de forma cooperativa para prover uma determinada funcionalidade ou solucionar um determinado problema, como se fossem um único e integrado recurso computacional. A configuração de um cluster inclui opções para cada máquina individualmente. Essas opções vão desde a quantidade de memória, do tipo e número de processadores, do tipo de rede que os interligam, do sistema de armazenamento de arquivos empregado e do sistema operacional utilizado Classificação Quanto a funcionalidade: A forma mais usual de classificação é dada pela sua função básica. Dentre as diversas aplicações de cluster, podemos explicitar três grupos básicos: Balanceamento de carga: nesse grupo, as máquinas que compõem o cluster processam tarefas individuais simultaneamente, com as tarefas sendo escalonadas de forma a manter a carga igual sobre as máquinas. Na maior parte das vezes não existe interação direta entre as diversas máquinas do cluster. Assim, tomando como exemplo um cluster que provê a hospedagem de uma página na Web, temos que, quando a página é acessada, o responsável pelo balanceamento de carga determina qual máquina deverá responder a esta requisição, evitando assim a sobrecarga em alguma outra máquina da rede; Alta disponibilidade: uma máquina, ou um subgrupo de máquinas, processa

31 3.1 Clusters computacionais 30 tarefas individuais e reportam o seu estado atual de disponibilidade às máquinas restantes através de um mecanismo conhecido como keep alive ou heart beat. Dada uma falha, as máquinas restantes assumem as funções da máquina que falhou, provendo redundância ao sistema de forma transparente ao usuário final. Esse grupo de clusters é útil para aplicações críticas, como servidores de s e de arquivos. Um cluster de balanceamento de carga muitas vezes também é considerado como um cluster de alta disponibilidade; Alto desempenho: uma tarefa computacionalmente complexa é dividida em pequenas sub-tarefas e escalonada através das máquinas que compõem o cluster, permitindo que elas sejam executadas de forma paralela. Essas, por sua vez, recebem e reportam os respectivos resultados através de mecanismos de troca de mensagem ou de memória compartilhada. Ao final, a união dos resultados parciais fornece o resultado final, com um tempo de execução menor devido à divisão das tarefas. Esse grupo de clusters é muito usado para execução de programas que necessitam de alto poder de processamento, como computação científica e análises financeiras. Quanto a sua composição: Além da classificação baseada na funcionalidade desempenhada, os clusters também podem ser classificados quanto à composição de seus componentes computacionais, também chamados de nós: Homogêneo: as máquinas, ou nós, que compõem o cluster possuem a mesma configuração de hardware, ou seja, são idênticas; Heterogêneo: as máquinas, ou nós, que compõem o cluster podem utilizar processadores da mesma arquitetura, contudo diferem na composição do seu hardware local, como, por exemplo, a quantidade de memória principal ou a velocidade do processador. Quanto aos nós: Para que os clusters possam trabalhar de forma cooperativa, é necessário que algum mecanismo de controle e gerência seja empregado. Esse mecanismo de controle muitas vezes é realizado por nós específicos dentro do grupo de nós que compõe o cluster. No caso dos clusters de alto desempenho, os nós podem ser de três tipos:

32 3.2 Redes de interconexão 31 Nós de acesso: utilizados para o acesso dos usuários aos ambientes onde podem compilar as suas aplicações e requisitar que as mesmas sejam executadas; Nós de gerência ou controle: nó, ou conjunto de nós, onde todas as aplicações que compõem a parte operacional do cluster residem. Tais nós são responsáveis por distribuir as tarefas dos usuários no cluster, sendo o acesso a esses nós restrito aos administradores do cluster; Nós de processamento ou computacionais: nós responsáveis por processar as tarefas distribuídas pelos nós de gerência de forma paralela. Esses nós usualmente não são acessados diretamente pelo usuário, mas apenas através do software de distribuição de tarefas do cluster Sistema operacional O sistema operacional do cluster é o responsável pela execução dos programas (processos) e gerenciamento dos recursos de hardware em cada um dos nós. Para que a execução paralela desses processos seja possível, é necessário que o programa a ser executado seja escrito utilizando bibliotecas de programação paralela. Como exemplo de tais bibliotecas, podemos citar o MPI, uma biblioteca de troca de mensagens entre os nós do cluster através da rede, ou ainda API s (Application Programming Interface), como o OpenMP, que utiliza o paradigma de memória compartilhada, onde os vários processadores em um mesmo nó trocam informações através da sua memória principal. 3.2 Redes de interconexão A rede de interconexão de um cluster de alto desempenho é uma peça fundamental, com suas características influenciando diretamente no desempenho do sistema como um todo. Um cluster de alto desempenho geralmente pode ter mais de uma rede de interconexão entre seus nós, com propósitos distintos. Essa diferenciação permite que o tráfego de dados, ou seja, o tráfego relacionado aos acessos de leitura e escrita nos sistemas de arquivos compartilhados, e o tráfego de troca de mensagens, ou seja, o tráfego relacionado ao mecanismo de comunicação entre os nós de processamento, sejam tratados de forma independente. Esta segregação das redes tem como objetivo evitar que a utilização de uma implique em problemas de desempenho em outra.

33 3.2 Redes de interconexão 32 Dentre os modelos atuais de interconexão, duas tecnologias são as mais comuns neste tipo de sistemas: a Ethernet e o InfiniBand Ethernet A Ethernet é uma tecnologia de rede local (LAN - Local Area Network) que permite interligar vários computadores e outros dispositivos, com baixo custo de implantação e flexibilidade extensa. Hoje em dia é a tecnologia mais utilizada em redes locais no mundo inteiro, com equipamentos de vários tipos sendo vendidos em larga escala. Na década de 1970, Robert Meltcafe entendeu que havia uma necessidade de realizar, de um modo pouco dispendioso, a interconexão entre estações de trabalho, além de impressoras, na empresa onde trabalhava, a Xerox, para que elas pudessem trocar informações entre si. Munido de seus conhecimentos sobre ARPAnet e o ALOHAnet (padrões com os quais ele já tinha trabalhado anteriormente), além de protocolos de acesso aleatório ao meio, ele e seu amigo David Boggs inventaram a rede Ethernet. Originalmente ela era capaz de interligar até 256 nós, suportando distâncias de até 1,5 km, sendo implantada com sucesso na Xerox. Dado o sucesso da implantação, Metcalfe então tentou convencer outras empresas a trabalharem juntas para que eles pudessem implantar a rede Ethernet como um padrão, ideia esta não muito aceita pela Xerox, o que fez com que Metcalfe se desligasse da mesma e fundasse sua própria empresa, a 3Com, a fim de desenvolver e comercializar tecnologias de rede. A Ethernet competia com um mercado com redes como a Token Ring e o Token Bus, mas devido a sua fácil adaptação às realidades do mercado e seu baixo custo de implantação, ganhou território rapidamente. A primeira variação do padrão Ethernet a ser comercializada era conhecida como 10Base5. Um cabo coaxial era utilizado para interligar as estações de uma mesma rede, suportando velocidades de até 10 Mbps, com uma distância máxima alcançada de 500 metros sem o uso de repetidores de sinal. Ao longo do tempo a Ethernet foi evoluindo para suportar maiores velocidades de transferência, tipos de mídia diferentes e maiores distâncias. Atualmente os cabos coaxiais foram substituídos por cabos de par trançado (UTP Unshielded Twisted Pair) e pela fibra ótica. Com estes recursos, as redes Ethernet atualmente suportam velocidades de até 10 Gbps.

34 3.2 Redes de interconexão Arquitetura O Ethernet é um protocolo das camadas física e de enlace. Com relação à camada física, é especificado um meio físico para a propagação do sinal de uma rede (cabo coaxial, cabo de par trançado e fibra ótica). Atualmente o cabo coaxial caiu em desuso, substituído pelos cabos de par trançado, que permitem uma velocidade de transmissão maior. Enquanto os obsoletos cabos coaxiais eram capazes de transmitir 10 Mbps, os cabos UTP podem atingir velocidades de até 1 Gbps. A fibra ótica é utilizada em redes de grande porte e suas vantagens são a velocidade, que chega a 10 Gbps, e as longas distâncias, cerca de centenas de quilômetros, que podem ser alcançadas devido à sua baixa atenuação, contra apenas 100 metros dos cabos UTP. Com a evolução do Ethernet, foi criado o Fast Ethernet, um conjunto de padrões onde o mais utilizado era o 100Base-TX, que utilizava cabos UTP e tinha taxa de transferência de 100 Mbps. As principais diferenças deste padrão eram o aumento da velocidade e o modo de transmissão, que podia ser em Half-Duplex ou Full-Duplex. Ao contrário do Half-Duplex, em Full-Duplex uma estação pode transmitir e receber dados simultaneamente. A partir deste, foram criados então o Gigabit Ethernet, onde as velocidades chegam a 1 Gbps com os padrões 1000Base-T (cabo UTP) e 1000Base-SX (fibra ótica) e posteriormente o 10-Gigabit Ethernet, com velocidades de 10 Gbps utilizando fibra ótica e apenas transmissões em Full-Duplex. Para permitir uma entrega local de quadros na Ethernet, foi criado um sistema de endereçamento, consistindo em uma maneira exclusiva de identificação de computadores e interfaces. A Ethernet usa uma subcamada de endereços chamada de MAC (Media Access Control), responsável por controlar o acesso ao meio físico, que têm 48 bits de comprimento e são expressos como doze dígitos hexadecimais. Este endereço é utilizado para que dentro de uma rede local, o dispositivo remetente e o destinatário se identifiquem e possam transmitir dados entre si. Um quadro Ethernet, visto na Figura 2, é dividido em campos, sendo os mais importantes (SPURGEON, 2000): Figura 2: Quadro Ethernet Preâmbulo: é um campo de 8 bytes que serve para sinalizar e dar início à transmissão entre dois dispositivos;

35 3.2 Redes de interconexão 34 Endereço de destino: contém o endereço MAC do adaptador destino. Ao receber algum dado, este campo é verificado e caso o endereço dele seja igual ao do receptor, o dado é repassado à camada de cima; Endereço de origem: contém o endereço MAC do remetente; Tamanho: indica o tamanho em bytes do campo de dados; Dados: estão contidos os dados que deverão ser passados à camada superior, tendo um tamanho mínimo de 46 bytes e máximo de 1500 bytes; CRC (Cyclic Redundancy Check): permite ao adaptador receptor detectar se houve algum erro durante a transmissão que alterasse os dados. Todas as tecnologias Ethernet fornecem um serviço não orientado para conexão à camada de rede, o que significa que quando um adaptador quer enviar dados a outro, não é necessário que se estabeleça uma conexão entre ambos. Além disso, elas fornecem também um serviço não confiável à camada de rede. Quando um adaptador recebe algum dado, ele realiza a verificação cíclica de redundância (CRC), mas caso seja detectado algum erro, este dado simplesmente é descartado. Sendo assim, o remetente não tem nenhuma informação sobre o recebimento do dado que enviou e essa confiabilidade deve ser implementada pelas camadas superiores (TANENBAUM, 2003). A interligação de dispositivos de uma rede local deve ser feita através de comutadores de camada de enlace (switches), onde todos os adaptadores devem se conectar diretamente. O comutador é então o responsável por determinar se deve ou não repassar algum pacote que recebeu e para qual interface ele deve redirecioná-lo. Para os nós, ele atua de forma transparente, uma vez que cada dado é endereçado ao nó destino e não ao comutador Protocolo Redes de computadores são extremamente complicadas e possuem muitos componentes, como as inúmeras aplicações que rodam nos hospedeiros, protocolos, vários tipos de sistemas finais e conexões, além dos meios físicos. Devido a essa grande variedade, para tentar tornar menos complexo um projeto de rede, foi apresentado pela International Organization for Standardization (ISO) um modelo de referência de camadas de rede, o Open Systems Interconnection Model, ou simplesmente, Modelo OSI (PETERSON; DAVIE, 2007), mostrado na Figura 3.

36 3.2 Redes de interconexão 35 Esse modelo era um modo de padronizar a comunicação entre sistemas diferentes, utilizando um modelo de camadas, em que cada camada é responsável por algum tipo de processamento e se comunica apenas com a camada imediatamente superior ou inferior. Quando um computador está transmitindo um dado pela rede, uma camada recebe os dados da camada superior, adiciona seus dados e repassa esta informação para a camada inferior, e assim sucessivamente, até o dado chegar no outro hospedeiro, aonde o processo se dá de forma inversa: a camada recebe o dado da camada inferior, acessa os dados pertinentes a ela e repassa a informação para a camada de cima. Cabe ressaltar que este modelo apenas especifica as funções de cada camada, deixando a parte da implementação a cargo da própria empresa desenvolvedora da tecnologia. Figura 3: Camadas do modelo OSI Baseado no modelo OSI foi criado o modelo TCP/IP (Transmission Control Protocol/Internet Protocol), mostrado na Figura 4. Esse modelo é o padrão mais utilizado atualmente, sendo ele dividido nas seguintes camadas (de cima para baixo): Aplicação, Transporte, Rede, Enlace e Física (KUROSE; ROSS, 2008) InfiniBand O barramento PCI (Peripheral Component Interconnect), introduzido pela primeira vez no início dos anos 90, foi até pouco tempo atrás o tipo de barramento dominante do mercado, usado tanto em máquinas desktop quanto em servidores, para interconectar sistemas periféricos de E/S aos complexos conjuntos de CPU e memórias. A configuração mais comum do barramento PCI é uma versão 32-bit 33 MHz que fornece uma largura de banda de 133 MB/s, embora a versão 2.2 da especificação permita uma versão de 64-bits

37 3.2 Redes de interconexão 36 Figura 4: Camadas do modelo TCP/IP a 33 MHz para uma largura de banda de 266 MB/s, e até mesmo uma versão 64-bit de 66 MHz para uma largura de banda de 533 MB/s. Até hoje máquinas desktop típicas usufruem da capacidade do barramento PCI em sua configuração típica (PFISTER, 2001). No entanto, os servidores já atingiram os limites da arquitetura deste barramento. Para resolver a limitação de largura de banda do barramento PCI, uma série de soluções baseadas nesse barramento se tornaram disponíveis no mercado, tais como o PCI-X (PCI extended) e o PCIe (PCI Express). Diante desse panorama, a alguns anos atrás, quando o gargalo iminente no subsistema de E/S se tornou uma variável clara no futuro, alguns líderes da indústria decidiram tomar uma atitude e projetar um novo subsistema que resolvesse a limitação corrente. Como é comum na indústria de informática, dois esforços foram iniciados concorrentes, um chamado de Future I/O, incluindo Compaq, IBM e Hewlett-Packard, e outro chamado de Next-Generation I/O, que incluía a Dell, Hitachi, Intel, NEC, Siemens e Sun Microsystems. Assim que as primeiras versões desses projetos começaram a se tornar disponíveis, ambos os grupos perceberam o quão prejudicial ao mercado seria manter a disputa entre dois subsistemas, decidindo então unificarem seus esforços, unindo as melhores ideias de cada grupo. Em agosto de 1999, os líderes da Compaq, Dell, Hewlett-Packard, IBM, Intel, Microsoft e Sun Microsystems formaram a InfiniBand Trade Association (ITA) (PENTAKALOS, 2002). Além desses sete membros do comitê de direção, o ITA é constituído por 11 membros patrocinadores, incluindo entre eles a 3Com, Cisco e EMC, e mais de 200 outras empresas. Ao concordar em unir seus esforços, o ITA foi ao mesmo tempo capaz de eliminar a

38 3.2 Redes de interconexão 37 confusão no mercado que teria resultado da coexistência de dois padrões concorrentes e de liberar uma primeira versão da especificação muito rapidamente. A versão 1.0 da especificação da arquitetura InfiniBand foi lançada em outubro de 2000 e a versão 1.0a, que consiste principalmente de pequenas alterações na versão 1.0, foi lançada em junho de A especificação é aberta e está disponível para download no site do ITA 1 de forma gratuita, mesmo para os não-membros. Diferentemente do PCI, a tecnologia InfiniBand, por sua vez, resolve as limitações de largura de banda e fanout 2 do barramento PCI, migrando de um arquitetura baseada em barramento compartilhado para uma arquitetura baseada em malha (ou fabric em inglês). A Figura 5 exibe um exemplo em que dois ou mais recursos são conectados entre si. A malha pode ser interconectada a outras malhas, provendo assim maior flexibilidade e segmentação. Cada conexão entre os recursos e a malha são ponto-a-ponto e seriais. Figura 5: Exemplo de interconexão de quatro recursos através da malha Essa abordagem diferenciada de barramento proveu algumas vantagens significativas: Por ser uma conexão serial, ele requer apenas um barramento com 4 fios, ao invés das múltiplas conexões requeridas pelo PCI; A natureza ponto-a-ponto da conexão elimina as contenções de acesso ao barramento, bem como os atrasos resultantes que poderiam surgir em condições de carga, os quais estão presentes nas arquiteturas de barramento compartilhado; Devido ao fato de o InfiniBand ter sido projetado para interligar recursos fisicamente próximos, o comprimento relativamente curto das conexões permite maior largura de banda Número máximo de dispositivos eletrônicos que podem ser alimentados de uma só vez por um outro dispositivo eletrônico

39 3.2 Redes de interconexão 38 Taxas alcançadas pelo InfiniBand Um link InfiniBand é um enlace serial que utiliza uma das seguintes tecnologias de modulação: Single Data Rate (SDR), Double Data Rate (DDR), Quad Data Rate (QDR), Fourteen Data Rate (FDR) ou Enhanced Data Rated (EDR). As taxas de transmissão (por direção) e de codificação do InfiniBand podem ser vistas na Tabela 1. SDR DDR QDR FDR EDR Taxa de transmissão 2,5 Gbps 5 Gbps 10 Gbps 14,0625 Gbps 25,78125 Gbps Codificação (Dados) 8 bits 8 bits 8 bits 64 bits 64 bits Codificação (Sinalização) 2 bits 2 bits 2 bits 2 bits 2 bits Tabela 1: Taxa de dados do InfiniBand Além das diferentes tecnologias de modulação, cada enlace pode ser composto por 4 (4x) ou 12 (12x) canais seriais. Assim a velocidade final é dado pela forma de modulação multiplicado pela número de canais (ANSARI et al., 2007). Na Tabela 2 podemos ver a vazão teórica dos enlaces InfiniBand. SDR DDR QDR FDR-10 FDR EDR 1x 2 Gbps 4 Gbps 8 Gbps 10,3 Gbps 13,64 Gbps 25 Gbps 4x 8 Gbps 16 Gbps 32 Gbps 41,2 Gbps 54,54 Gbps 100 Gbps 12x 24 Gbps 48 Gbps 96 Gbps 123,6 Gbps 163,64 Gbps 300 Gbps Tabela 2: Vazão efetiva teórica dos enlaces InfiniBand Para que os sistemas acessem o barramento InfiniBand, é necessário o uso de adaptadores de canais especiais. A especificação InfiniBand classifica os adaptadores de canal em duas categorias: Host Channel Adapters (HCA) e Target Channel Adapters (TCA): HCA: Os HCA estão presentes em servidores, ou até mesmo máquinas de desktop, e fornecem uma interface utilizada para integrar o InfiniBand com o sistema operacional; TCA: Os TCA estão presentes em dispositivos dedicados de E/S, tais como um subsistema RAID(Redundant Array of Independent Disks) ou um subsistema JBOD (Just a Bunch Of Drives). Cada adaptador de canal pode ter uma ou mais portas, permitindo a redundância de caminhos entre uma origem e um destino, resultando em benefícios de desempenho e confiabilidade. Apesar do InfiniBand ter surgido como um barramento de acesso a periféricos de E/S, a comunicação não é necessariamente feita entre um HCA e um TCA, podendo

40 3.3 Sistemas de armazenamento distribuído 39 ter comunicação entre HCA s distintas através da malha. Atualmente a tecnologia InfiniBand é utilizada tanto para rede local de armazenamento quanto para tecnologia de intercomunicação de dados entre máquinas. Mensagem InfiniBand O InfiniBand transmite dados em pacotes de até 4 KB que são tomadas em conjunto para formar uma mensagem. Uma mensagem pode ser: Acesso direto à memória, ler ou gravar em um dispositivo remoto (RDMA - Remote Direct Memory Access); Canal para enviar ou receber dados; Operação baseada em transações reversíveis, tais como armazenamento; Transmissão em multicast, ou seja, mais de um destino simultaneamente; Operação atômica, ou seja, que não pode ser dividida ou pausada. Essa mensagem por sua vez pode ser transmitida de formas diferentes dentro da malha InfiniBand. De maneira similar ao TCP/UDP (Transmission Control Protocol/User Datagram Protocol), esses tipos distintos de transporte podem ser voltados à conexão ou não, confiáveis ou não. Além da forma original, atualmente podemos executar a pilha TCP/IP, sem suporte a RDMA, utilizando o InfiniBand somente como tecnologia de enlace a fim de manter compatibilidade com sistemas mais tradicionais. A implementação da pilha de rede para InfiniBand não é provida automaticamente pelos sistemas operacionais modernos. Diversas implementações estão disponíveis no mercado, sendo maior parte delas implementações proprietárias voltadas a sistemas computacionais específicos. Dentre as implementações abertas, a OFED (OpenFabrics Enterprise Distribution) foi a escolhida como padrão de mercado. 3.3 Sistemas de armazenamento distribuído Em sistemas computacionais, para que arquivos sejam criados, acessados e modificados se faz necessário uma estrutura ou repositório de dados, a fim de permitir tais operações. Tal estrutura é conhecida como sistema de arquivos, ou, de maneira simples,

41 3.3 Sistemas de armazenamento distribuído 40 a forma que os dados são organizados e transmitidos. Para muitos usuários, esse é o aspecto mais visível de um sistema operacional. O sistema de arquivos fornece uma visão abstrata dos dados persistentes, além de ser responsável pelo serviço de nomes, o acesso aos arquivos bem como a organização dos mesmos de uma forma geral. Outra forma de pensar sobre sistema de arquivos é como um protocolo. Assim como protocolos de rede (como o IP) representam o fluxo de dados percorrendo a Internet, sistema de arquivos representam os dados em um meio de armazenamento particular. Para clusters de alto desempenho, tal como o Netuno, ainda se faz necessário que o sistema de arquivos seja distribuído, no qual os arquivos armazenados estão dispersos em hardwares diferentes. Esses arquivos podem ser acessados remotamente, interconectados através de vários servidores responsáveis por oferecer um conjunto de facilidades aos nós da rede para os diversos clientes, podendo ser pessoas ou aplicações, que fazem uso dos arquivos armazenados. Antes de entrar nos sistemas de armazenamento suportados pelo Netuno, vamos expor alguns conceitos e serviços fornecidos pelos sistemas de arquivos distribuídos (TANEN- BAUM, 2007; KON, 1996): Nomes, Localização e Transparência Grande parte dos arquivos armazenados em um sistema de arquivos possui um nome e um caminho, o identificando unicamente no sistema. Enquanto usuários lidam com objetos lógicos de dados representados por nomes de arquivos, o sistema manipula blocos físicos de dados, armazenados em trilhas de discos. Tal tipo de mapeamento lógico-físico dos dados fornece aos usuários uma abstração que oculta os detalhes de como e onde no disco o arquivo está de fato armazenado. Nesse sentido, o caminho representa um nó de uma estrutura de diretórios, sendo representado possivelmente como uma árvore. Assim, para localizar um arquivo em uma árvore de diretórios, basta seguir o caminho do arquivo e, ao atingir o diretório final, procurar pelo nome do arquivo. Um exemplo desse procedimento pode ser visto na Figura 6. Em um sistema de arquivos distribuído transparente, uma nova dimensão é adicionada à abstração, ocultando o local na rede onde o arquivo se encontra. Em um sistema de arquivos convencional, o intervalo de mapeamento de nomeação é um endereço em um disco. Nos sistemas distribuídos, esse intervalo é aumentado, a fim de incluir a máquina específica em cujo disco o arquivo está armazenado.

42 3.3 Sistemas de armazenamento distribuído 41 Figura 6: Busca de um arquivo seguindo a árvore de diretórios do sistema Também existe a possibilidade de replicação de arquivos. Dado um nome de arquivo, o mapeamento retorna um conjunto das posições das réplicas desse arquivo. Nessa abstração, a existência de várias cópias e suas posições também fica oculta para os usuários. Cache Os dados podem ser armazenados em quatro locais, sendo eles a memória ou disco do servidor e a memória ou o disco do cliente. Ao usar somente o disco do servidor poderá ocorrer perda de desempenho. Com isso, buscando melhorar o desempenho no acesso aos arquivos de um sistema, convém guardar as informações mais acessadas na memória do servidor, para evitar sobrecarga do meio físico onde elas estão armazenadas. Tal funcionalidade ajuda na economia de tempo de processamento, uma vez que, ao acessar dados remotos, o sistema está limitado à velocidade da rede, que por sua vez está limitada à velocidade do meio físico de armazenamento do servidor remoto, que precisaria procurar os dados, carregá-los na memória e enviá-los para o cliente. O uso de cache no servidor é transparente aos usuários, porém ainda é sempre necessário atualizar o cache para não haver problemas de coerência em caches desatualizados. O principal algoritmo de substituição dos arquivos quando a memória está cheia é o LRU (Least Recent Used). Em sistemas de arquivos distribuídos, pode-se ter caches tanto no lado do servidor, como no lado do cliente, evitando que o cliente acesse muito a rede para obter os dados do servidor, enquanto que o servidor diminui o acesso ao meio físico de armazenamento dos dados para enviá-los ao cliente.

43 3.3 Sistemas de armazenamento distribuído 42 Serviços Oferecidos Serviço de Nomes Distribuídos: tal serviço se preocupa em indicar a localização de um determinado arquivo, a partir de seu nome ou caminho. Para prover transparência para o usuário, o nome ou caminho de um arquivo não deve conter indícios de sua localização física; Serviço de Arquivos Distribuídos: serviço responsável por fornecer operações e propriedades, conhecidas como metadados, dos arquivos que compõem o sistema. Tal serviço é útil também no acesso concorrente de arquivos, lidando com a replicação dos mesmos, ajudando a manter os arquivos disponíveis mesmo caso algum servidor fique fora do ar; Serviço de Diretórios Distribuídos: serviço responsável por manter a organização hierárquica dos arquivos armazenados no sistema, estruturada em diretórios e subdiretórios. Algumas das operações oferecidas por esse serviço são criação, alteração, listagem, remoção e alteração de permissões. Características Dentre as características desejáveis em um sistema de arquivos distribuídos (GALLI, 2000), podemos citar, por exemplo: Disponibilidade: manter cópias atualizadas dos arquivos em diferentes locais, trazendo como benefício o balanceamento de carga; Escalabilidade: o serviço pode ser expandido por crescimento horizontal, de modo a se ajustar a demanda de carga e as capacidades da rede disponível; Heterogeneidade: adaptação a diferentes plataformas, que podem ser usadas tanto do lado dos servidores como dos clientes; Segurança: prover preocupação com a permissão, autenticação, privacidade e integridade dos dados; Tolerância à falhas: o acesso aos arquivos deve ser ininterrupto, mesmo com falhas parciais;

44 3.3 Sistemas de armazenamento distribuído 43 Acesso concorrente: vários usuários podem acessar o mesmo arquivo ao mesmo tempo, porém isso não sendo perceptível a esses usuários NFS A Sun Microsystems foi uma das pioneiras no desenvolvimento do sistema UNIX e de redes TCP/IP. Com a evolução dessas redes, ferramentas como o Telnet e o FTP (File Transfer Protocol) foram criadas para permitir aos usuários acessar uma outra máquina através da rede. Contudo, nenhuma dessas soluções permitia que o usuário acessasse o arquivo de uma máquina remota da mesma maneira como um arquivo local é utilizado. Para satisfazer esta necessidade, a Sun criou, em meados dos anos 1980, o Network File System (NFS) (LINUX..., 2011; KIRCH, 2006; CALLAGHAN, 2000), primeiro sistema de arquivos moderno projetado com suporte a estações diskless, construído sobre o protocolo IP. O NFS foi especificamente desenhado com o objetivo de eliminar a distinção entre um arquivo local e um remoto. Para o usuário, um arquivo de um computador remoto pode ser usado como se ele estivesse no disco rígido do computador local do usuário. A Sun também projetou o NFS para ser independente de hardware, podendo operar em conjunto com equipamentos de outras empresas. Com o sucesso da primeira versão, o protocolo do NFS foi documentado como uma Especificação de Pedido de Comentário (SUN MICROSYSTEMS INC., 1989), evoluindo para o NFSv2. Tal protocolo cresceu rapidamente devido à sua capacidade de interoperar com outros clientes e servidores. O padrão continuou a evoluir para o NFSv3 (CALLAGHAN; PAWLOWSKI; STAUBACH, 1995), sendo esta versão muito mais escalável que as versões anteriores, dando suporte a arquivos maiores que 2 GB, gravações assíncronas, além de introduzir o TCP como protocolo de transporte, abrindo caminho para os sistemas de arquivos de rede de longa distância. Em 2000, o NFS entrou no ambiente corporativo, com o NFSv4 (SHEPLER et al., 2000, 2003), com melhorias na segurança, junto com um protocolo stateful, diminuindo a carga de trabalho no servidor, ao contrário das versões anteriores, que eram stateless. Atualmente o NFS está na versão 4.1 (SHEPLER et al., 2010). Essa nova versão adicionou suporte para acesso paralelo por servidores distribuídos (pnfs) e representa um sistema de arquivos em rede extremamente estável, móvel, escalável, com um alto desempenho e qualidade corporativa, suportando os modelos computacionais mais recentes para otimizar as infraestruturas virtualizadas. Na Figura 7, é mostrada a evolução do

45 3.3 Sistemas de armazenamento distribuído 44 protocolo, junto com suas respectivas RFCs (Request For Comment). Figura 7: Linha do tempo das diferentes versões do NFS Arquitetura Um dos objetivos do NFS é suportar sistemas heterogêneos, onde clientes e servidores possam rodar sistemas operacionais diferentes. Para resolver essa meta, o NFS segue o modelo cliente/servidor do TCP/IP, mostrado na Figura 8. Um disco rígido ou um diretório em um dispositivo de armazenamento de um computador particular pode ser configurado por um administrador como um recurso compartilhado. Este recurso pode então ser acessado por computadores clientes, fazendo que este pareça ser um diretório local na máquina cliente. Alguns computadores podem agir exclusivamente como servidores ou como clientes, enquanto outros podem ser ambos: compartilhando alguns de seus próprios recursos e acessando recursos providos por outros. Figura 8: Arquitetura cliente/servidor do NFS Considerando o conjunto do protocolo TCP/IP como um todo, o NFS reside na camada de Aplicação do modelo TCP/IP. Esta camada TCP/IP inclui as camadas de Sessão, Apresentação e Aplicação do Modelo de Referência OSI.

46 3.3 Sistemas de armazenamento distribuído 45 A operação do NFS é definida na forma de três componentes principais que podem ser vistos logicamente situados em cada uma das três camadas do modelo OSI, correspondendo à camada de Aplicação TCP/IP (Figura 9). Esses componentes são: Remote Procedure Call (RPC): serviço genérico da camada de Sessão usado para implementar a funcionalidade cliente/servidor na rede, permitindo chamar processos em máquinas remotas e serializando a solicitação do NFS, ao mesmo tempo em que gerencia o envio da resposta aos solicitantes apropriados; External Data Representation (XDR): linguagem descritiva que permite tipos de dados serem definidos de uma maneira consistente. A XDR conceitualmente reside na camada de Apresentação e assegura que todos os participantes do sistema de arquivo se comuniquem com facilidade ao tratarem diferentes tipos de dado. Em outros termos, quando uma dada arquitetura realiza uma solicitação, a representação do tipo de dado pode ser diferente no cliente de destino que atende à solicitação, e com isso cabe à XDR cuidar de converter os tipos para uma representação comum, permitindo que todas as arquiteturas interoperem e compartilhem o sistema de arquivo. Quando a XDR tiver convertido os dados para a representação comum, a solicitação é então transferida pela rede. Embora a XDR seja mais conhecida por seu uso no NFS, ela é uma especificação útil sempre que várias arquiteturas estiverem lidando com um ambiente de aplicativo comum; Processos e Operações: processos e operações que conceitualmente agem na camada de Aplicação do modelo OSI. Esses processos especificam tarefas particulares a serem realizadas em arquivos pela rede, usando a XDR para representar os dados e o RPC para transmitir os comandos através da rede. As versões mais antigas do NFS usavam o protocolo UDP, enquanto atualmente o TCP é mais usado por possuir maior confiabilidade. Quando o sistema opera com um sistema de arquivo virtual (VFS - Virtual File System), são fornecidos meios para suportar vários sistemas de arquivo simultaneamente. O VFS determina para qual armazenamento a solicitação é destinada e qual sistema de arquivos deve ser usado para satisfazê-la. Quando a solicitação é para o NFS, o VFS passa para a instância do NFS no kernel, que interpreta a solicitação de E/S e a converte para um procedimento do NFS (OPEN, ACCESS, CREATE, READ, CLOSE, REMOVE etc.), especificando os comportamentos no protocolo do sistema de arquivo. Quando um procedimento é selecionado, ele é então realizado na camada de RPC.

47 3.3 Sistemas de armazenamento distribuído 46 Figura 9: Camadas onde se situa o NFS. No servidor, o NFS opera de forma semelhante, com a solicitação fluindo pela pilha de rede, através de RPC/XDR para o servidor do NFS, sendo este responsável por atender à solicitação. A solicitação é então passada pelo daemon do NFS, que identifica a árvore do sistema de arquivos de destino necessária, e o VFS é usado novamente para obter o sistema de arquivos no armazenamento local. Na Figura 10 o processo descrito é mostrado. Para redes de maior latência, o NFSv4 implementa um procedimento composto, que permite essencialmente que várias chamadas RPC sejam incorporadas a uma solicitação única para minimizar a taxa de transferência de solicitação pela rede. Com isso, o NFS é um sistema de arquivos conectável como qualquer outro, possuindo como única diferença as solicitações de E/S, que não são atendidas localmente, sendo necessário percorrer a rede para sua conclusão. Outro ponto a se destacar é que o NFS não é um sistema de arquivos no sentido tradicional, mas um protocolo para acessar sistemas de arquivo remotamente Protocolo A partir da visão do cliente, a montagem é a primeira operação que ocorre no NFS, a partir do protocolo mount. Esse protocolo representa a montagem de um sistema de arquivos remoto em um espaço de sistema de arquivos local. A chamada de montagem é encaminhada através do VFS para o componente do NFS. Ao estabelecer o número

48 3.3 Sistemas de armazenamento distribuído 47 Figura 10: Pilha cliente/servidor do NFS da porta para a montagem, o cliente realiza uma chamada RPC de montagem. Tal solicitação ocorre entre o próprio cliente e um daemon especial. Esse daemon verifica a solicitação do cliente em relação à lista do servidor de sistemas de arquivos atual; se tal sistema de arquivo existir, e o cliente tiver acesso ao mesmo, uma resposta de montagem estabelece o identificador de arquivos para a montagem do sistema. Ainda do lado do cliente, informações remotas de montagem são armazenadas, como o ponto de montagem local e a capacidade de realizar solicitações de E/S. Para a leitura de um arquivo, esse primeiro deve ser aberto. Não existe um procedimento OPEN na RPC; ao invés disso, o cliente verifica se o diretório e o arquivo existem no sistema de arquivos montado. A solicitação GETATTR para o diretório resulta em uma resposta com os atributos do diretório ou uma indicação que o mesmo não existe; em seguida, a solicitação LOOKUP verifica se o arquivo solicitado existe. Caso positivo, a solicitação GETATTR retorna os atributos do arquivo. Com base nestas chamadas RPCs bem-sucedidas, o cliente cria um identificador de arquivos que é fornecido ao usuário para solicitações futuras. Com o arquivo identificado no sistema de arquivos remoto, o cliente pode emitir solicitações READ. Tal solicitação contém um identificador de arquivo, o estado, a distância e a contagem para o leitor. O estado é utilizado para determinar se a operação pode ser realizada, a distância indica onde começa o ponto de leitura, e por fim a contagem identifica o número de bytes a serem lidos.

49 3.3 Sistemas de armazenamento distribuído 48 NFSv3 Como dito no início desta seção, os servidores nas versões 2 e 3 do NFS não guardam o estado das transações realizadas, ou seja, são stateless. Essa característica agiliza a recuperação das informações em caso de queda, uma vez que basta os clientes pedirem os dados novamente para o servidor, até que ele responda. Contudo, servidores sem estado não conseguem controlar o acesso concorrente aos seus arquivos e nem garantir a consistência dos mesmos. No NFSv3, o mecanismo de cache do servidor foi alterado para poder possuir tamanho variável, ao contrário do tamanho constante nos protocolos anteriores. Sua política de escrita também mudou de write-on-close, ou seja, ao se fechar um arquivo, esse é gravado em disco, para a política delayed-write, na qual o arquivo é gravado em disco após ficar algum tempo sem ser alterado pelo cliente. Outro ponto modificado, foi que, enquanto a versão 2 do protocolo limitava o tráfego de dados dos blocos dos arquivos em 8 KB, a versão 3 permite enviar dados entre cliente e servidor em blocos de até 56 KB via UDP. Além disso, no NFSv2, o servidor só retorna o resultado da gravação após os dados estarem fisicamente no disco. No NFSv3, o disco gravava uma quantidade maior de dados simultaneamente, pois é possível o uso de escrita assíncrona, em que o servidor retorna um pedido de escrita ao cliente antes de realmente gravar os dados no disco, acumulando-os para escrever de uma só vez. O suporte a arquivos de 64 bits também foi implementado na versão 3, desde que tanto o cliente, como o servidor e o sistema operacional suportem arquivos com esse tamanho. No aspecto de segurança, a versão 3 do NFS passou a validar junto ao servidor se o usuário solicitante possui as permissões do arquivo requesitado, com o servidor decidindo se libera o acesso ou não ao cliente. Há também a possibilidade de autenticação mútua entre cliente e servidor, devido a possível fragilidade que o método anterior pode apresentar com a falsificação de permissões. NFSv4 Antes do NFSv4, existiam protocolos auxiliares, como por exemplo, de montagem, bloqueio, entre outros, para o gerenciamento de arquivos. Após a nova versão, esse processo foi simplificado, além de ocorrer a remoção do suporte ao UDP como protocolo de transporte. Outra melhoria nessa versão é a substituição do protocolo mount com cha-

50 3.3 Sistemas de armazenamento distribuído 49 madas RPC internas para gerenciar o ponto de montagem, uma vez que este protocolo apresentava problemas de segurança em potencial. O aspecto de segurança é um ponto muito importante na versão 4 do NFS. As opções de segurança disponíveis para as implementações do NFS foram bastante aumentadas, incluindo opções de autenticação múltipla e algoritmos de encriptação, além de mudanças no protocolo em geral para torná-lo mais seguro. Na versão NFSv4.1, o conceito de paralelismo (pnfs) é apresentado, permitindo maior escalabilidade e desempenho. Sua nova arquitetura implementa os dados e metadados divididos em segmentos consecutivos escritos de forma sequencial, técnica conhecida como striping. Conforme mostrado na Figura 11, o pnfs é dividido em três partes: cliente, servidor e armazenamento, havendo dois caminhos, um para os dados e outro para o controle. Figura 11: Arquitetura do pnfs no NFSv4.1 Tanto os dados quanto os metadados são armazenados na área de armazenamento. O cliente pode realizar E/S direta, e o servidor do NFSv4.1 trata do gerenciamento e armazenamento dos metadados. Além disso, o pnfs adiciona a capacidade de suporte de vários métodos de acesso ao armazenamento, suportando o uso de protocolos baseados em bloco (Fibre Channel), protocolos baseados em objetos e o próprio NFS em sua versão não-paralela.

51 3.3 Sistemas de armazenamento distribuído 50 Os requisitos para o NFSv4.2 foram publicados em setembro de 2010 (EISLER; NE- TAPP, 2010), com sua publicação oficial prevista para março deste ano. Alguns dos novos avanços abordam o armazenamento em ambientes de virtualização CIFS O Common Internet File System (CIFS) é um protocolo de compartilhamento de arquivos remoto que opera na camada de Aplicação da rede, usado de várias formas para comunicação entre nós (HERTEL, 2003). Ele é compatível com a maneira como os aplicativos já compartilham dados em discos locais e servidores de arquivos de rede. Baseado no protocolo SMB (Server Message Block) da Microsoft, foi originalmente desenvolvido pela IBM para rodar sobre o NetBIOS, sendo posteriormente reescrito, desde 1996, pela Microsoft, IBM, Intel, 3Com, entre outras. Esse protocolo é usado tanto por computadores pessoais quanto por workstations, independente de plataforma (STORAGE NETWORKING INDUSTRY ASSOCIATION, 2002). Uma descrição sobre o protocolo SMB, cobrindo os antecedentes do CIFS pode ser encontrada em X/Open Company Ltd (1992) Protocolo O CIFS é um protocolo de rede stateful de alto nível, impondo estados para manter conexões seguras e criptografia, permitindo que vários clientes manipulem arquivos em rede, como se o estivessem utilizando-o localmente. Qualquer ação é permitida (READ, WRITE, DELETE), contudo a única diferença é que o arquivo não está na máquina local, mas sim em um servidor. No modelo OSI, é melhor descrito na camada de Aplicação/Apresentação, dependendo de outros protocolos para o transporte. Tirando algumas exceções, o CIFS é um protocolo dirigido ao cliente, em que o cliente faz a requisição, a qual o servidor responde. Funciona enviando pacotes do cliente para o servidor, em que cada pacote é tipicamente baseado em uma requisição, como por exemplo, abertura ou leitura de um arquivo. O servidor então recebe esse pacote e checa-o para ver se a requisição é válida; caso afirmativo, o mesmo executa a requisição e retorna um pacote de resposta ao cliente. Além da sua função primária como protocolo de compartilhamento de arquivos, o CIFS assume ainda mais importância devido ao seu uso indireto como protocolo de transporte para protocolos de comunicação no Microsoft Windows, impressão em rede, localização de recursos, administração e gerenciamento remoto (RAP - Remote Administration

52 3.3 Sistemas de armazenamento distribuído 51 Protocol), autenticação por rede e RPCs. Dentre as principais características que o CIFS suporta, podemos citar: Transporte independente: o protocolo CIFS por si só não coloca nenhum requerimento sobre o protocolo de transporte usado para passar mensagens SMB entre o cliente e o servidor. O CIFS é normalmente realizado através de um protocolo orientado a conexão; Conectividade flexível: um único cliente pode se conectar a múltiplos servidores, fazendo uma ou mais conexões para cada servidor. A atividade de múltiplos processos pode ser multiplexada em uma única conexão; Negociação de recursos: o conjunto de recursos suportado pelo protocolo são negociados na base da conexão; Acesso aos recursos: um cliente pode acessar múltiplos recursos compartilhados, como por exemplo arquivos ou filas de impressão; Segurança: servidores CIFS suportam tanto transferências anônimas quanto acesso seguro e autenticado para arquivos; Acesso aos arquivos: um cliente pode abrir, ler, escrever, modificar ou deletar vários arquivos no servidor de destino. O compartilhamento de arquivos é gerenciado pelo servidor, de modo que vários clientes podem ter o mesmo arquivo aberto ao mesmo tempo; Comunicação FIFO entre processos: um cliente pode abrir, ler, escrever e fechar pipes nomeados no servidor de destino. Pipes nomeados fornecem um caminho de comunicação entre os processos cliente e servidor. Bloqueio de arquivos e registros, e armazenamento em cache seguro: o CIFS suporta bloqueio de arquivos e registros, bem como bloqueio oportunista de arquivos para permitir aos clientes armazenarem dados na cache para melhor desempenho; Notificação de mudança de arquivo e diretório: clientes CIFS podem requisitar serem notificados quando uma mudança é feita em um arquivo dentro de um diretório ou em uma árvore de diretórios no servidor;

53 3.3 Sistemas de armazenamento distribuído 52 Transporte de RPCs: o CIFS provêm transporte autenticado para protocolos de chamada de procedimento remoto tais como RPC e RAP; Verificação de mensagens: o CIFS suporta assinatura de mensagens, usado para assegurar que as mensagens não sejam modificadas em trânsito; Desempenho e escalabilidade: servidores CIFS são altamente integrados com o sistema operacional, suportando todas as plataformas Microsoft depois do Windows 95, além de suportar outros sistemas operacionais populares, como o Unix, Mac OS, etc; Complemento ao HTTP: o CIFS complementa o HTTP (Hypertext Transfer Protocol), proporcionando compartilhamento e transferência de arquivos mais sofisticado que protocolos mais antigos, como o FTP; Suporte a Unicode: o CIFS suporta tanto o conjunto de caracteres ASCII (American Standard Code for Information Interchange) como nome de arquivos Unicode PanFS O PanFS TM (Panasas File System) (PANASAS..., 2012), também conhecido como Panasas ActivStor TM, é um sistema de arquivo proprietário, baseado em dispositivos de armazenamento de objetos (OSD - Object Storage Device), tendo como características ser paralelo, distribuído e tolerante à falhas, além de possuir alta velocidade, globalidade e escalabilidade (PANASAS, 2003). O PanFS é desenvolvido pela empresa americana Panasas R desde 2003, sendo projetado especialmente para computação de alto desempenho, estando atualmente em sua versão 12 (4 a geração). O armazenamento disponibilizado como foi dito é paralelo e escalável, no qual ocorre a separação do gerenciamento dos metadados das operações de armazenamento de dados. Tentativas anteriores de sistemas de arquivo escaláveis envolvendo domínios na casa de terabytes usando o NFS tradicional, ou seja, com um servidor interposto entre os clientes e os dispositivos de armazenamento, produziram gargalos nas operações de metadados (BIARDZKI; LUDWIG, 2009); com isso, o PanFS foi desenvolvido para prover acesso paralelo de alta capacidade aos clientes, enquanto ainda mantêm os benefícios de uma solução usando um protocolo padrão similar ao pnfs (NFSv4.1). Ainda com relação ao armazenamento de dados no PanFS, esses são escritos de forma redundante utilizando algoritmos de RAID, permitindo ao sistema tolerar a perda de um

54 3.3 Sistemas de armazenamento distribuído 53 ou mais dispositivos de armazenamento. O protocolo de transferência de dados usados pelo PanFS é conhecido como DirectFLOW. Tais pontos serão mais bem abordados a frente Arquitetura Em sistemas de arquivo tradicionais, o gerenciamento dos blocos dos objetos é realizado pelo servidor de arquivos; essa restrição implica que todas as operações de armazenamento passem pelo servidor de arquivos, criando assim tanto um gargalo quanto um ponto de falha. O PanFS contorna esse problema delegando o gerenciamento dos blocos aos dispositivos de armazenamento. Isso permite aos clientes ignorarem o servidor de arquivos e escreverem os dados diretamente nos dispositivos. Com isso, essa arquitetura possibilita alto desempenho no acesso aos dados além de permitir que o PanFS evite e se recupere de falhas no hardware de forma transparente (OLDFIELD R. A.; WIDENER, 2010). Os arquivos armazenados pelo sistema de arquivos são distribuídos através de múltiplos objetos em diferentes OSDs, não sendo necessário um servidor de arquivos para intermediar cada transação. Convém destacar que os dispositivos OSD representam um alto nível de abstração em relação aos dispositivos de armazenamento em massa tradicionais: enquanto eles representam o disco como um grande vetor de blocos e confiam no sistema de arquivos para mapeá-los em entidades lógicas, os dispositivos OSD cuidam desse mapeamento. Usando essa flexibilidade proporcionada pelos OSDs, o sistema de arquivos Panasas implementa uma detecção de possíveis gargalos de E/S quando um servidor de armazenamento está servindo mais requisições do que os outros, realocando, ou até mesmo replicando objetos para servidores de armazenamento menos utilizados (RIEDEL, 2007). Estrutura A implantação do sistema de arquivos Panasas é feita combinando uma solução tanto de software quanto de hardware dedicado baseado em lâminas. Sua unidade básica é uma plataforma de altura 4U para montagem em gabinete, em que cada chassi acomoda até onze lâminas, como pode ser visto nas Figuras 12 e 13. A estrutura dos chassis em si é composta de dois componentes básicos: Storage Blade: as Storage Blades (lâminas de armazenamento), mostradas na Figura 14, são a base do sistema. Nelas são armazenadas efetivamente todos os

55 3.3 Sistemas de armazenamento distribuído 54 Figura 12: Exemplo de rack do PanFS Figura 13: Exemplo de chassi do PanFS dados dos clientes. Elas são construídas com inteligência para trabalhar com recursos básicos de gerenciamento de dados e acabam lidando com cerca de 80% da carga de trabalho. Cada Storage Blade é um sistema completo, com placa-mãe, processador, memória, duas interfaces Gigabit Ethernet e dois discos rígidos (HD) SATA cada, totalizando 20 HDs por chassi. A memória é utilizada também como cache para os dados armazenados nos discos. As lâminas são alimentadas por suprimentos de energia, além de uma bateria de backup redundante, garantindo energia para a alimentação do sistema em caso de falha da fonte principal. Director Blade: a Director Blade (lâmina diretora), mostrada na Figura 15, é obrigatória. Ela desempenha o papel de servidor de metadados, propiciando o ba-

56 3.3 Sistemas de armazenamento distribuído 55 lanceamento de carga e gerenciando a atividade do sistema de arquivos, permitindo leituras e escritas em paralelo entre os clientes e as lâminas de armazenamento. Essa paralelização ocasiona além do aumento de velocidades, uma escalabilidade muito maior ao sistema. Figura 14: Visão externa e interna de uma Storage Blade do PanFS Figura 15: Visão externa e interna de uma Director Blade do PanFS As especificações completas do chassi do Panasas existente atualmente no Netuno (versão 3000), bem como da versão mais atual são mostradas na Tabela 3. Especificação/Modelo ActiveStor 3000 ActiveStor 12 Geração do Sistema Terceira Quarta Config. de Lâmina Suportadas 1+10, 2+9, ou ,2+9, ou 3+8 (Director + Storage) Capacidade Total (TB) ou 60 Discos Rígidos (SATA) Vazão Máxima (Escrita) 350 MB/s 1600 MB/s Vazão Máxima (Leitura) 500 MB/s 1500 MB/s Switches Um (segundo opcional) Dois Compatibilidade com Roteador Sim Sim Infiniband QDR Suprimento de Energia 950W mais fonte redundante 950W mais fonte redun- de 240V-CA dante de 240V-CA Temperatura Operacional Peso Máximo 68 kg 68 kg Dimensões (Cada Gaveta) - AxLxP 17,78 cm x cm x cm 17,78 cm x cm x cm Tabela 3: Especificações do Panasas File System Acesso aos arquivos

57 3.3 Sistemas de armazenamento distribuído 56 A movimentação de dados usada pelo Panasas é uma especialização do NFS versão 4, conhecida como pnfs (Parallel Network File System), introduzida inicialmente na seção anterior quando abordamos o NFS em si. No sistema de arquivo Panasas, o cliente contata o servidor de metadados para realizar acesso aos arquivos. A Director Blade por sua vez envia um mapa contendo a localização dos dados para o cliente. Uma vez que o cliente conhece esse mapeamento, o servidor de metadados não se faz mais necessário, podendo o cliente ser capaz de acessar direto e paralelamente os blocos de arquivos no PanFS. Quando o processo de leitura/escrita pelo cliente termina, as mudanças são então enviadas para o servidor de metadados e o acesso ao cliente então é revogado. Essa abordagem elimina o gargalo provocado por múltiplas requisições no servidor de metadados, uma vez que o cliente pode acessar os arquivos diretamente nas Storage Blades, após receber o mapeamento dos dados da Director Blade. Um esquema dessa movimentação de dados é mostrado na Figura 16. Figura 16: Arquitetura básica do PanFS Múltiplos caches O sistema de arquivo provém além do cache no OSD, um cache nos nós computacionais para a entrada de dados. Há também um cache para escrita de dados que agrega múltiplas escritas para uma transmissão eficiente aos OSDs. Por último, um quarto cache

58 3.3 Sistemas de armazenamento distribuído 57 para metadados e tokens de segurança, permitindo aos clientes gerar comandos seguros para acessar os dados aos quais eles obtiveram permissão prévia. Divisão e proteção dos dados Para os arquivos serem armazenados, o PanFS os divide em múltiplos objetos, sendo um por OSD. Ao contrário do padrão, o PanFS pode aplicar diferentes níveis de RAID a cada arquivo. O sistema de arquivos pega um arquivo e o divide em unidades, que correspondem a maior região contígua de um arquivo que é atribuído a um OSD. O tamanho de cada unidade é especificado como um atributo, sendo o tamanho padrão 64 KB, junto com o nível de RAID (0 3, 1 4 ou 5 5 ) e o número de OSDs em que o objeto é distribuído. Esses atributos, mais um identificador e outros metadados são adicionados para formar um objeto. Por padrão, se o objeto tiver tamanho superior a 64 KB, é usado RAID-5, ou então RAID-1 para arquivos com até 64 KB (LAYTON, 2007 apud CORREA; SILVA, 2009). Ao utilizar uma arquitetura RAID baseada em objetos, o PanFS elimina as limitações de desempenho do RAID implementado via hardware. Os arquivos são então escritos como objetos diretamente nos servidores de armazenamento sem o primeiro funil de E/S, que seria através do servidor de arquivos. De forma semelhante, os clientes buscam os arquivos diretamente dos cartões de armazenamento que contêm os objetos aos quais eles se referem. Por último, o PanFS, ao fazer o RAID com base nos arquivos e não nos blocos físicos do disco, pode atingir um alto grau de paralelismo, melhorando seu desempenho. O número de OSDs no qual o arquivo é dividido determina a largura máxima de banda de um arquivo. Logo, o PanFS distribui os dados de arquivos grandes em todos os OSDs disponíveis (NAGLE; SERENYI; MATTHEWS, 2004). Escalabilidade O menor sistema é composto por um chassi, contendo 11 lâminas no total (1 Director Blade e 10 Storage Blades; sendo necessárias 3 Director Blades para um sistema total- 3 No RAID 0 os dados são subdivididos em segmentos consecutivos que são escritos sequencialmente através de cada um dos discos. 4 No RAID 1 um dos discos serve de espelho para o outro. Tudo que é gravado em um dos discos é gravado no outro. 5 No RAID 5 são necessários no mínimo três discos, com as informações de paridade sendo gravadas em cada disco de tal forma que se um dos discos falhar, as informações nele contidas podem ser reconstruídas.

59 3.3 Sistemas de armazenamento distribuído 58 mente tolerante à falhas. Contudo, novos hardwares podem ser adicionados de forma simples, chegando a conjuntos com cerca de 100 chassis, como, por exemplo, o cluster do projeto Road Runner, instalado no Laboratório Nacional de Los Alamos (LOS ALAMOS LAB, 2012a) Protocolo A interface OSD usada pelo PanFS é um conjunto de extensões para o conjunto de comandos SCSI (Small Computer System Interface) muito parecido com o protocolo padrão ANSI T10 (NAGLE et al., 2008). O PanFS usa uma emulação desse protocolo chamada iscsi (Internet Small Computer System Interface) para emitir comandos SCSI para os dispositivos em uma rede TCP/IP. O hardware de rede que manipula as operações de comunicação TCP é ligado aos servidores de armazenamento do PanFS, permitindo que clientes remotos usem a infraestrutura de interligação padrão enquanto se comportam como se os dispositivos de armazenamento estivessem realmente conectados localmente. Sistema operacional O sistema operacional do PanFS possui grande flexibilidade e pode ser gerenciado tanto por linha de comando quanto por uma interface visual, na qual é mostrada, por exemplo, usuários, cotas de grupos, etc. Ele oferece suporte a múltiplos protocolos de acesso de dados, se encaixando a necessidade de cada cliente e aplicação. São suportados três protocolos que podem ser usados simultaneamente: DirectFLOW: protocolo principal do PanFS, possui alto desempenho, necessitando do uso de um módulo com kernel Linux no cliente. De forma resumida, ele implementa o modelo baseado em objetos na qual a Director Blade envia ao nó o mapa de localização dos objetos nas Storage Blades e depois cria fluxos de dados para que o nó se comunique diretamente com os servidores de armazenamento. Esse número de fluxos de dados é somente limitado pelo número de servidores de armazenamento e o número de nós; NFS: visando a interoperabilidade, o PanFS suporta o padrão NFSv3 sobre o protocolo TCP para acessar dados, sendo para clientes Linux e Unix;

60 3.4 Protocolo de gerência de redes 59 CIFS: o PanFS também oferece suporte a clientes com o sistema operacional Microsoft Windows via o protocolo CIFS (MICROSOFT CORPORATION, 2009), usando NetBIOS (Network Basic Input/Output System) sobre o protocolo TCP/IP. O Panasas oferece bom desempenho com os três protocolos mencionados, contudo o DirectFLOW merece atenção especial, pois consegue em alguns casos um desempenho trinta vezes maior que os outros protocolos de acesso de dados. Outro ponto a se destacar é que o DirectFLOW elimina gargalos de E/S ao permitir que os nós acessem os cartões de armazenamento de forma direta e paralela. Um esquema do funcionamento do DirectFLOW e dos outros dois procolos é mostrado na Figura 17. Figura 17: Protocolos suportados pelo PanFS 3.4 Protocolo de gerência de redes Dada a importância das redes de interconexão, é extremamente necessário que as mesmas sejam monitoradas constantemente. Esse monitoramento busca detectar problemas e possíveis gargalos durante a execução das aplicações dos usuários finais no cluster de alto desempenho. A maior parte desses protocolos funciona como mecanismos de interação entre as estações de gerência, onde residem os programas de monitoramento e coleta de dados, e os equipamentos de rede. Após a coleta, essas informações podem então ser indexadas em gráficos de forma a facilitar sua interpretação.

61 3.4 Protocolo de gerência de redes 60 A partir disso, escolhemos para utilizar neste trabalho o protocolo padrão do mercado para gerência de rede: o SNMP (Simple Network Management Protocol) SNMP Desde a sua criação em 1988, como uma solução temporária para gerenciar elementos de redes e componentes fundamentais da Internet, o SNMP alcançou larga aceitação. Esse protocolo foi derivado de seu predecessor conhecido por SGMP (Simple Gateway Monitoring Protocol). O SNMP esperava ser substituído por uma solução definitiva baseada nas arquiteturas CMIS/CMIP (Common Management Information Service/Common Management Information Protocol), contudo essa arquitetura não teve a aceitação como a do SNMP, que continua como o protocolo padrão de mercado. A arquitetura do SNMP é bem simples e baseada no modelo gerente/agente, consistindo de um gerente (NMS - Network Management System), um agente, uma base de dados de gerência (MIB - Management Information Base), os objetos gerenciados e o protocolo de rede. O gerente fornece a interface entre o administrador de rede e o sistema de gerência. O agente fornece a interface entre o gerente e o dispositivo físico a ser gerido. Tanto o gerente quanto o agente usam uma base de dados de gerência e um conjunto relativamente pequeno de comandos para troca de informações. As MIB s são conjuntos dos objetos gerenciados que procuram abranger todas as informações necessárias para a gerência de um determinado equipamento ou funcionalidade, possibilitando assim a automatização de grande parte das tarefas de gerência. Elas são organizadas em um formato de árvore, onde as variáveis ou objetos são representadas como folhas. Um identificador ou objeto numérico (OID - Object Identifier) é usado para identificar cada variável de maneira única na MIB e nas mensagens SNMP. Mensagens SNMP O SNMP utiliza apenas cinco tipos de mensagens básicas para comunicação entre o gerente e o agente: GET/GET-NEXT: esse tipo de mensagem permitem que o gerente solicite ao agente informações sobre uma variável específica. O agente, ao receber uma mensagem de GET ou GET-NEXT, irá enviar uma mensagem de resposta para o gerente

62 3.5 Biblioteca de comunicação 61 com a informação solicitada ou com uma indicação de erro; SET: esse tipo de mensagem permite que o gerente solicite que seja feita uma alteração no valor de uma variável específica. O agente irá então responder com uma mensagem indicando se a mudança foi feita ou com uma indicação de erro; GET-RESPONSE: tipo de mensagem utilizado para responder a requisições dos dois tipos anteriores com resultados ou com indicações de erro, contendo detalhes sobre o problema; TRAP: esse tipo de mensagem permite que o agente, espontaneamente, informe o gerente a respeito de algum evento importante. O gerente, no entanto, não envia nenhuma resposta ao agente. As mensagens dos tipos GET, GET-NEXT e SET são enviadas a partir do gerente ao agente, e as informações providas através do GET-RESPONSE são usadas de maneira reativa pelo administrador da rede. No entanto, a mensagem de TRAP é a única iniciada no agente e, por esse motivo, ela é usada por unidades de telemetria remota para relatar alarmes, notificando o gerente logo que uma condição adversa ocorra, ao invés de esperar pelo gerente SNMP realizar a consulta da respectiva variável. Apesar da mensagem do tipo SET parecer bastante atraente para atividades de gerência remota, ela normalmente é mantida desativada nos equipamentos pois oferece grandes riscos à segurança do sistema, pois um usuário pode utilizar tal mecanismo para alterar configurações e comprometer o funcionamento da infraestrutura da rede. Para garantir que somente usuários ou ferramentas autorizadas serão capazes de interagir com os equipamentos geridos a partir do uso do SNMP, é definida uma senha simétrica a ser utilizada nas comunicações entre os componentes agente e gerente, chamada de community (MAURO; SCHMIDT, 2005). 3.5 Biblioteca de comunicação MPI Com o advento dos clusters computacionais de alto desempenho e sua utilização em larga escala, tornou-se necessário que fosse criado um método para facilitar o desenvolvimento de programas para serem rodados paralelamente nos nós computacionais desses clusters.

63 3.5 Biblioteca de comunicação 62 Diante dessa necessidade, surgiram os paradigmas para a paralelização dos programas, podem ser de dois tipos: Memória compartilhada: nesse paradigma, todos os processos compartilham de uma mesma área de memória, e para que eles se comuniquem, devem alterar e acessar variáveis nesta memória. Um dos desafios deste método é manter a sincronização entre os processos para que haja exclusão mútua e sincronização no acesso aos dados. Um exemplo de padrão que utilize memória compartilhada é o OpenMP; Troca de mensagens: Nesse método, um mesmo programa é rodado em vários nós, e cada processo em execução tem sua área de memória inacessível pelos demais. Para que a saída do programa seja gerada, cada nó envia uma mensagem com o resultado final de sua própria execução. Para que uma determinada entrada seja dividida entre os nós, cada um possui um identificador único dentro do cluster e o programador ao escrever o programa, indica que parte da entrada caberá a qual processo. Em alguns casos, é necessário também que haja uma sincronização entre os nós, que pode ser feita com mensagens de sinalização entre eles ou com operações coletivas de sinalização pré-definidas na biblioteca utilizada, que são chamadas de barreiras. Para a programação orientada a troca de mensagens entre os nós, foram desenvolvidos várias ferramentas, como compiladores paralelos (Cray), linguagens paralelas (HPF, Occam) e bibliotecas de troca de mensagens (PVM, MPI). No Netuno, em específico, é usada a biblioteca de programação paralela MPI, baseada no paradigma de troca de mensagens, desenvolvida para aplicações escritas nas linguagens de programação C, C++ e Fortran. Nos anos 80, foram criados diversos ambientes para a criação de programas paralelos para os diferentes supercomputadores existentes. O início do MPI se deu a partir dos anos 90, quando, em um encontro do congresso "Supercomputing 92", se chegou à conclusão que a criação destas bibliotecas foi um esforço em vão, já que cada um inventava algo diferente para o mesmo fim. A partir disto, resolveram trabalhar em conjunto e concentrar seus esforços para fazer um único padrão, o MPI. A primeira versão do MPI, chamada de MPI-1, foi terminada em maio de Já sua segunda versão, MPI-2, em 1998, porém, uma versão mais avançada e robusta, em novembro de 2002.

64 3.5 Biblioteca de comunicação 63 Funcionalidade A interface MPI tem como objetivo fornecer uma topologia para comunicação entre um conjunto de processos mapeados nos nós do cluster de forma independente. Um programador ao escrever um programa para ser executado paralelamente utilizando a biblioteca MPI, deve se preocupar em fazer a distribuição das tarefas entre os processos. Para isto, ao disparar um processo, o ambiente MPI atribui a ele um identificador único, contíguo e que começa do zero, chamado de Rank que geralmente é utilizado pelo programador para a divisão dos dados de entrada e para o envio de informações de um processo aos outros. Para o máximo de desempenho, a cada núcleo de cada nó é atribuído apenas um único processo. Essa atribuição acontece em tempo de execução, através do agente que inicia o MPI, o mpirun ou o mpiexec. Embora o MPI pertença a camada 5 do modelo OSI, sua especificação pode cobrir outras camadas, como por exemplo, o uso do protocolo TCP na camada de transporte. Dentre as inúmeras funções MPI, as fundamentais são: MPI_init: inicializa o processo MPI; MPI_Comm_size: informa a quantidade de processos no comunicador MPI; MPI_Comm_rank: informa o rank de um processos dentre o conjunto de processos do comunicador MPI; MPI_Send: envia uma mensagem; MPI_Recv: recebe uma mensagem; MPI_Finalize: encerra todos os processos, terminando o ambiente de execução do MPI MPI I/O A medida que os computadores e aplicações paralelas foram se tornando mais rápidas, o desempenho da entrada e saída de dados dos mesmos foi se tornando um gargalo para a sua eficiência. Ainda faltava ao MPI o suporte à operações paralelas de E/S. Esse suporte veio com um pacote que permitia tais operações, desenvolvido, em 1994, em um laboratório da IBM. Surgia assim o MPI I/O, um conjunto de rotinas criado com o propósito de

65 3.5 Biblioteca de comunicação 64 prover uma transferência de dados de e para meios externos de armazenamento de forma paralela com um alto desempenho. Tal pacote fez tanto sucesso, que em 1996 foi adotado pela NASA, e logo depois foi incorporado ao novo padrão MPI da época, o MPI-2. Vantagens do MPI I/O Flexibilidade: o MPI I/O fornece mecanismos para acesso coletivo, em que muitos processos podem ler e escrever em um único arquivo; Portabilidade: os arquivos escritos são portáveis entre as muitas plataformas que suportam a interface MPI I/O;

66 65 4 Arquitetura do cluster Netuno 4.1 Nós computacionais Como especificado na seção 3.1, os nós chamados de computacionais de um cluster de alto desempenho são os responsáveis pela execução do processamento das aplicações que rodam paralelamente. O cluster Netuno possui 256 desses nós físicos para o processamento das tarefas, divididos em 8 racks com 32 computadores cada. Na Figura 18 temos uma visão de alguns racks do Netuno com seus respectivos nós. Figura 18: Alguns nós computacionais do Netuno Cada nó possui dois processadores Intel Xeon E-5430, cada um com 4 núcleos de 64 bits, com uma frequência de operação de 2,66 GHz. Esses processadores foram construídos com uma tecnologia de integração de 45 nm, possuindo frequência de barramento de 1,3 GHz e memória cache L2 de 12 MB. O desempenho máximo deste processador em operações de ponto flutuante é estimado em cerca de 10,6 GFlops para cada núcleo, o que significa aproximadamente 85,1 GFlops de pico por cada nó do Netuno. Cada núcleo do nó computacional deve ter uma quantidade de memória suficiente

67 4.1 Nós computacionais 66 para executar suas aplicações, assim, como cada nó do Netuno possui oito núcleos de processamento, foi especificado um total de 16 GB de memória RAM por nó, com correção de erros, característica que é altamente indicada em equipamentos deste porte. A frequência e o padrão dessa memória é de acordo com o barramento do processador, neste caso, memórias FB-DIMM 667, do tipo dual rank. Valores menores de memória poderiam resultar em excessivas operações de swap de memória virtual, resultando em uma possível degradação de desempenho do cluster. Cada nó possui um HD com capacidade de 160 GB do tipo SATA, adequado para ser usado pelas aplicações em execução. Seu espaço também é suficiente pra armazenar uma cópia do sistema operacional e ser usado como memória virtual. Em um cluster, os arquivos de configuração e as aplicações de cada usuário ficam localizadas em um sistema de arquivos remoto, que deve estar acessível a todos os nós. Além disso, os processos paralelos que rodam em cada nó devem se comunicar via troca de mensagens. Tais operações são feitas pela(s) interface(s) de rede dos nós, que pode ser de diversos tipos, sendo que no Netuno essa conexão se dá de duas formas: Para acesso ao sistema de arquivos remoto, o qual contem os dados da aplicação, é usada uma interface de rede Ethernet de 1 Gbps em cada nó, compartilhada entre todos os processadores. Como o sistema operacional é o responsável por estes acessos, cada nó executa apenas uma cópia do mesmo, e com isso o número de núcleos de processamento não tem grande impacto na quantidade de acessos realizados. Logo não é necessária uma rede de alto desempenho, como a InfiniBand, por exemplo. Para comunicação entre os processos executados nos nós é usada a rede de alto desempenho InfiniBand. Nesse caso, a quantidade de processos rodando em cada nó é influenciada pela quantidade de núcleos que ele possui, o que significa que quanto maior o número de núcleos, maior deve ser a largura de banda disponível para comunicação entre os nós. Em cada nó do Netuno há uma interface HCA para a rede InfiniBand, com taxa máximo de transferência de 20 Gbps que se interconecta a um switch central único com 264 portas. É importante frisar que este modelo de rede foi adotado para que estes dois tipos de tráfego passem por vias diferentes, fazendo com que um não influencie no outro.

68 4.2 Nós de acesso Nós de acesso Estes nós são os responsáveis pelo acesso externo dos usuários e possuem as mesmas configurações dos nós computacionais. O Netuno disponibiliza acesso via protocolo SSH (Secure Shell) e HTTP, sendo quatro nós de acesso no total, todos instalados em um rack separado dos nós de computação. 4.3 Nós de controle O Netuno possui dois nós de controle que estão localizados no mesmo rack dos nós de acesso. Cada um deles possui um processador AMD Dual-Core com 2.0 GHz de frequência de operação. Neles está instalado o software de gerenciamento que permite o envio simultâneo de comandos para todos os nós, além de possuir uma base de dados com as configurações de cada um dos nós do cluster, o que torna mais prático o gerenciamento dos mesmos. 4.4 Rede de interconexão e de E/S de dados Como explicitado anteriormente, os nós do Netuno estão fisicamente agrupados em racks e possuem tanto uma rede para acesso ao sistema de arquivos remoto e distribuído quanto uma outra para troca de informações entre si. No total são: oito racks onde estão os nós de computação, sendo cada um deles com 32 máquinas; um rack central aonde estão os nós de controle, de acesso e o núcleo da rede Infini- Band; um rack para o armazenamento remoto. Para a troca de mensagens entre os nós é utilizada uma rede com alta taxa de transferência máxima por canal e baixa latência, pois este tipo de utilização gera um tráfego relativamente grande na rede. Estas características são úteis para um bom desempenho das aplicações paralelas que são executadas no cluster e por isso no momento da especificação do Netuno, foi decidido que seria utilizada a rede InfiniBand. O padrão InfiniBand utiliza uma conexão serial padrão, chamada SDR, com 2,5 Gbps em cada sentido da transmissão e suporta velocidades de 5 Gbps (DDR) e 10 Gbps

69 4.4 Rede de interconexão e de E/S de dados 68 (QDR). A codificação utilizada nos canais é 8B/10B, o que significa que a cada 10 bits transmitidos, 8 bits são de informações úteis à aplicação e 2 bits são de sobrecarga. Outra característica interessante da rede InfiniBand é a possibilidade de um nó acessar diretamente a memória de outro através da tecnologia RDMA. Esta tecnologia é importante pois diminui a sobrecarga do processador dos nós computacionais, uma vez que eles não tem mais que fazer o gerenciamento dos dados da interface de rede para a memória. No rack dos nós de controle do Netuno é utilizado um switch fabric InfiniBand CISCO SFS-7024-X. Esse switch, mostrado na Figura 19, possui 264 portas DDR 4X, o que é suficiente para interligar todos os nós computacionais com uma latência final (de espaço de usuário para espaço de usuário) menor do que 4 microssegundos. Figura 19: Switch CISCO SFS-7024X Para a rede de E/S de dados, cada um dos racks que abriga os nós de computação está equipado com um switch de distribuição de alto desempenho CISCO GE. Esse switch, mostrado na Fig. 20, possui 48 portas Ethernet com taxa de transferência de 1 Gbps cada, além e mais duas portas com conexão de fibra ótica de 10 Gbps. Figura 20: Switch CISCO GE

70 4.5 Sistemas de arquivo remoto e distribuído 69 As conexões de todos os nós desses racks convergem para esse switch de alto desempenho nas suas portas Ethernet, enquanto ambas as portas de fibra ótica são utilizadas como uplink 1 e estão ligadas a um switch central CISCO 6509E, também de alto desempenho, que possui 16 interfaces de fibra ótica, localizadas no rack central. Este switch é mostrado na Figura 21. Devido a uma configuração de agregação de links, estes uplinks estão agregados e funcionam de forma transparente como apenas uma conexão de 20 Gbps. O sistema de arquivos remoto se conecta a este switch central através de 12 portas Ethernet de 1 Gbps, totalizando uma taxa máxima de transferência de 1,2 GB por segundo. Figura 21: Switch CISCO 6509E 4.5 Sistemas de arquivo remoto e distribuído Tendo em vista que o perfil da computação de alto desempenho é, em geral, o uso intensivo de processador, há uma noção equivocada que a demanda dos nós computacionais sobre o sistema não seja significativa. Contudo, ao considerarmos o cluster Netuno como um todo, uma quantidade expressiva de dados é produzida e consumida em um curto espaço de tempo. Baseado nisso, os profissionais responsáveis por especificar o cluster inicialmente tinham a ideia de usar um sistema de arquivos distribuído do tipo NAS (Network Attached Storage), que seria acessível remotamente via o protocolo NFS. Como explicado na seção 3.3, nesse modelo em que um servidor de arquivos é acessado via protocolo NFS, todas as requisições de E/S passam por um único servidor, este responsável pelo gerenciamento, 1 Conexão feita de um dispositivo ou uma rede pequena para uma rede maior.

71 4.6 Softwares 70 localização e encaminhamento dos dados para os dispositivos de armazenamento. Devido à baixa escalabilidade de armazenamento e de desempenho dos sistemas NAS, além das fragilidades e limitações do NFS, esta ideia foi logo descartada. Para que o sistema de arquivos pudesse alcançar a escalabilidade desejada, optou-se pelo uso de um sistema de arquivos paralelo e orientado a objetos, em que os acessos devem poder ocorrer paralelamente aos servidores de dados sem a interferência de servidores centrais. Nesses sistema há a separação dos canais de dados e metadados, podendo os clientes transmitirem diretamente para os dispositivos de armazenamento. Assim, dentre as opções disponíveis na época, o PanFS ganhou a preferência. O sistema da Panasas adquirido para o Netuno possui atualmente três gavetas operacionais, cada uma contendo 10 Storage Blades com dois HDs de 500 GB cada, totalizando 30 TB de capacidade de armazenamento, sendo 27 TB úteis, devido ao espaço perdido na configuração de RAID. O Netuno ainda conta com 9 gavetas com 15 discos SATA de 1 TB cada, totalizando 135 TB de armazenagem bruta, para armazenamento NFS. Um servidor é responsável pelo acesso aos discos, contando com 4 interfaces de rede de 1 Gbps, dois processadores AMD Quad-Core e 8 GB de memória RAM. 4.6 Softwares Dentre os softwares que compõem o cluster Netuno, encontramos a necessidade de definição do sistema operacional, compiladores e middleware Sistema operacional No caso do Netuno, foi escolhido para utilização em todos os nós do cluster a distribuição CentOS do Linux, versão 5. Esse sistema suporta tanto ambientes de servidores quanto ambientes de estações de trabalho. O CentOS é uma distribuição gratuita do Linux de classe Enterprise, derivada da distribuição licenciada do Red Hat Enterprise Linux (RHEL) e mantida pelo CentOS Project (THE CENTOS PROJECT, 2012). Essa distribuição tem como objetivo fornecer um sistema compatível com o RHEL, utilizando os códigos fontes disponibilizados publicamente pela Red Hat e reconstruindo o sistema a partir desses. Dessa forma o CentOS consegue ter compatibilidade binária

72 4.6 Softwares 71 com as aplicações homologadas no RHEL. Basicamente a diferença entre o CentOS e o RHEL é o fornecimento de suporte pago na aquisição do segundo. Funcionalmente, podese considerar que ambos são iguais, ou seja, o CentOS possui segurança, maturidade e estabilidade suficientes para garantir um funcionamento adequado do cluster tanto quanto outras soluções Linux Enterprise, porém sem custo. Outro ponto relacionado ao sistema operacional é o driver utilizado para interface com a rede InfiniBand. O driver utilizado no Netuno é o fornecido pela OpenFabrics Alliance, conhecido como OFED (OpenFabrics Enterprise Distribution) (OPENFABRICS ALLIANCE, 2012). Esse driver realiza a conexão entre os componentes do cluster, sejam eles servidores ou sistemas de armazenamento, otimizados para desempenho utilizando RDMA e outras tecnologias disponíveis no adaptador HCA. A distribuição OFED ainda conta com um gerenciador de rede InfiniBand, o OpenSM, além de ferramentas de diagnóstico, testes de avaliação de desempenho e suporte para uso de bibliotecas MPI com a interface InfiniBand Compiladores e implementações MPI Em termos de compiladores, o Netuno conta com compiladores para as linguagens C e Fortran de uso público, como o GNU, além de versões proprietárias, como o Intel e o Portland Group. Na parte de bibliotecas de comunicação para o padrão MPI, estão disponíveis no Netuno versões públicas, como o OpenMPI (GABRIEL et al., 2004) e o MVAPICH2 (HUANG et al., 2006), além da solução proprietária Intel MPI (INTEL, 2012). Na parte referente a depuradores paralelos, o Netuno conta o depurador proprietário TotalView (ROGUE WAVE, 2012) Ferramentas adicionais Tendo em vista os diversos tipos de programas e privilégios que rodam no Netuno, além da demanda de gerenciamento de centenas de nós, ferramentas adicionais são necessárias para melhor utilização dos nós. Assim, o Netuno conta com o gerenciador de carga Moab Cluster (ADAPTIVE COM- PUTING, 2012a), responsável por permitir acesso remoto aos recursos computacionais do cluster, além de coordenar ações para prevenir conflitos entre usuários e gerenciar nós

73 4.6 Softwares 72 com defeito. Em conjunto a esse gerenciador de carga, o Netuno possui o escalonador Torque (ADAPTIVE COMPUTING, 2012b), um sistema para submissão de tarefas de domínio público, em que o usuário pode submeter novas requisições e monitorar e controlar as existentes sem a necessidade de instalar nenhum programa em seu próprio computador ou receber intervenção do gerente do sistema. O Torque é responsável por alocar os recursos necessários para cada programa a ser executado no Netuno, principalmente a quantidade de processadores usados e o tempo máximo de execução do programa. O Torque também cria uma fila de prioridades, a fim de determinar a ordem de execução dos mesmos. Por último, existem ferramentas nos nós de controle para gerenciar a infraestrutura básica do cluster, garantindo, por exemplo, que os nós computacionais estejam consistentes entre si. Para isso, é usada a ferramenta proprietária Scali Manager (PLATFORM COMPUTING, 2012). No que se refere ao escopo do nosso trabalho, a Figura 22 mostra um diagrama parcial da rede Ethernet do cluster Netuno. Para maiores informações sobre como foi a escolha e configuração do cluster Netuno, acerca de seus dilemas e prioridades, veja Silva et al. (2009). Figura 22: Diagrama parcial da rede Ethernet do cluster Netuno

74 73 5 Metodologia Este trabalho se resume na coleta e interpretação de informações de desempenho da infraestrutura de interconexão de um cluster de alto desempenho específico. Seu desenvolvimento fez uso de aplicações que visam simular e mensurar a performance dos sistemas de armazenamento e intercomunicação, tendo tais aplicações, conhecidas como benchmark, o objetivo de simular cenários específicos de utilização dos recursos físicos que serão retratados no capítulo 6. Por fim, em nossa abordagem, que pode ser considerada puramente quantitativa, após o uso das aplicações, procedeu-se a coleta dos dados, feita em um ambiente controlado por softwares de gerência específicos. 5.1 Estação de gerência Para realização deste projeto foi necessário a instalação e configuração de uma estação de gerência diretamente conectada a infraestrutura de rede do cluster Netuno, onde os dados relevantes foram coletados e armazenados para análise. Essa estação é composta por dois processadores Intel Xeon E5430 (4 núcleos, 12 MB cache, 2.66 GHz, 1333 MHz FSB), munidos de 16 GB de memória principal do tipo DDR2, 160 GB de memória secundária do tipo SATA, e duas interfaces de rede do tipo Ethernet 10/100/1000 Mbps, a mesma dos nós computacionais do cluster Netuno. As interfaces de redes estão ligadas de forma a garantir acesso simultâneo tanto à infraestrutura de rede interna do cluster quanto à rede da Universidade, por onde o acesso à Internet é realizado. Desta forma garantimos que seria possível o acesso remoto sem que o seu tráfego interferisse nos testes, além de eliminar equipamentos intermediários entre a rede analisada e a estação de gerência. O sistema operacional na estação de gerência é o mesmo do cluster Netuno, ou seja, a distribuição GNU/Linux denominada CentOS. A estação de gerência possui o CentOS

75 5.2 Ferramentas utilizadas 74 5, kernel versão 2.6 na arquitetura x86_64. A instalação do sistema foi feita seguindo o modelo mínimo, afim de evitar que outras aplicações pudessem interferir no processo de coletas das informações. 5.2 Ferramentas utilizadas Implementação MPI Intel MPI Para efetuar a comunicação entre os nós do Netuno, várias bibliotecas estavam disponíveis, conforme citado na Subseção Após identificarmos alguns problemas com o OpenMPI, em que a maioria dos testes submetidos eram encerrados devido a erros diversos, escolhemos a biblioteca Intel MPI, pois devido a mudanças no ambiente do Netuno, era a única biblioteca plenamente confiável para uso. A Intel MPI é uma biblioteca para transferência de mensagens multi-camada, que implementa a especificação MPI-2, sendo compatível com todas as plataformas Intel que adotam esse padrão. Um manual de referência para esta biblioteca pode ser encontrado em INTEL (2011) Benchmarking Neste trabalho utilizaremos uma ferramenta que busca gerar tráfego simulado para avaliar o sistema de armazenamento paralelo do cluster estudado. Ferramentas de benchmarking populares para avaliação de desempenho de sistemas de E/S são o MPI I/O Test, o IOzone e o IOR MPI-IO Test Embora tenhamos encontrado vários programas para benchmark de sistemas de arquivo, a maioria não foi designada para E/S paralela. Como o intuito de nosso trabalho envolve diferentes avaliações, inclusive com operações paralelas, tais programas acabaram não sendo úteis. Para contornar esse problema, nossa escolha inicial foi o MPI I/O Test, ferramenta desenvolvida pelo Laboratório de Los Alamos (LOS ALAMOS LAB, 2012b), usada para

76 5.2 Ferramentas utilizadas 75 testes de desempenho na busca de possíveis problemas com no sistema de arquivos ou redes de interconexão. O MPI I/O Test, construído sobre as chamadas da biblioteca padrão MPI I/O, descrita na Seção 3.5, permite coletar informações temporais para leitura e escrita de arquivos usando diferentes padrões de acesso, como, por exemplo: N processos escrevendo em N arquivos; N processos escrevendo em um arquivo; N processos enviando dados para M processos, que escrevem em M arquivos; N processos enviando dados para M processos, que escrevem em um arquivo. Contudo, o desenvolvimento do MPI I/O Test foi descontinuado em 2008, e ocorreram problemas de incompatibilidade com seu uso no Netuno juntamente com a implementação Intel MPI disponível IOzone Outra ferramenta cogitada, o IOzone (IOZONE, 2012) é uma ferramenta de benchmark de código aberto, originalmente desenvolvido por William Norcott, e posteriormente melhorado por Don Capps. Ela possui inúmeras funcionalidades, como, por exemplo, o uso de chamadas mmap() e o uso de threads POSIX (MARTIN, 2012). Esta ferramenta é capaz de simular diversos padrões de carga e acesso, assim como executar testes complexos utilizando arquivos especiais, onde são listadas as pré-definições. Ela pode ser usada no modo cluster, com vários clientes, contudo ela é extremamente lenta nesse modo, pois é necessário utilizar ferramentas como RSH/SSH para sincronização entre os processos (OLKER, 2003). Esse mecanismo também introduz erros nas medições. Assim, apesar do IOzone ter sido escolhido a princípio como ferramenta de benchmark que seria usada neste estudo, ela demonstrou-se melhor opção para avaliações que envolvam experimentos com um único cliente (mesmo multi-core), fato não aplicado ao Netuno IOR Na busca por uma nova ferramenta, foi descoberto o IOR (Interleaved or Random), uma ferramenta desenvolvida por Christopher J. Morrone, pesquisador do Laboratório

77 5.2 Ferramentas utilizadas 76 Nacional de Lawrence Livermore (IOR..., 2012; LLNL, 2012). Esta ferramenta aproveita a escalabilidade do MPI para facilmente calcular com precisão a largura de banda agregada de um número (quase) ilimitado de máquinas clientes. Tal como o MPI I/O Test, o IOR também suporta o a biblioteca MPI I/O e possui flexibilidade para utilizar diversos padrões de acessos aos arquivos. O IOR resolveu também outro problema encontrado, o da interferência das memórias caches na medição de performance, fazendo que clientes que realizem escrita sejam distintos dos que realizam leitura. Assim, para avaliações em sistemas distribuídos que envolvam cálculos de vazão agregada, o IOR se tornou muito mais conveniente do que IOzone. A única desvantagem do IOR em relação ao IOzone foi em relação à flexibilidade dos testes, uma vez que no IOR só podem envolver E/S sequencial ou strided 1. Além dessas vantagens, outro fator que pesou na escolha do IOR como ferramenta a ser usada foi a possibilidade de realizar testes utilizando o MPI como mecanismo de sincronismo, além de simular benchmarks de aplicações reais de forma efetiva (SHAN; SHALF; ANTYPAS, 2008). Informações sobre outras ferramentas de benchmark para clusters envolvendo E/S paralela podem ser encontrados em Thakur (2012) Coleta de dados Cacti O Cacti (URBAN, 2011) é uma ferramenta sob a licença GNU administrativa de rede, que permite o monitoramento do estado de elementos de redes e programas, tais como largura de banda utilizada e uso de CPU, gerenciando desde redes simples até redes complexas com vários dispositivos, situação na qual este trabalho se encaixa. Neste estudo, a ferramenta será utilizada como componente de gerência da infraestrutura SNMP. Um esquema da troca de mensagens SNMP entre os dispositivos que compõem o nosso estudo pode ser visto na Figura 23. Essa ferramenta tem como objetivo não só realizar a coleta das informações dos objetos de diversos agentes, mas também de organizar as mesmas em gráficos, facilitando o processo de revisão por parte dos administradores de rede. A ferramenta foi desenvolvida 1 Lista com deslocamentos de tamanho fixo.

78 5.2 Ferramentas utilizadas 77 Figura 23: Funcionamento SNMP para ser flexível de modo a se adaptar facilmente a diversas necessidades, bem como ser robusto, adicionando a isto uma interface Web intuitiva e fácil de usar, bem como pode ser visto nas Figuras 24 e 25. Trata-se de uma interface completamente orientada ao PHP e uma infraestrutura para o RRDTool (Round Robin Database Tool), padrão aberto criado por Tobias Oetiker (OETIKER, 2012) e ainda ativamente desenvolvido pela comunidade. Ele é utilizado no mercado para coleta e organização de informações de sistemas de alto desempenho, responsável por armazenar os dados recolhidos e por gerar gráficos em um banco de dados MySQL. As informações são repassadas para a ferramenta através de scripts ou outros programas escolhidos pelo usuário, os quais devem se encarregar de obter os dados. Há também o suporte ao protocolo SNMP para consulta das informações, como mencionado anteriormente. A ferramenta funciona basicamente unindo três processos distintos, onde apresentam o resultado ao usuário através de uma interface desenvolvida em PHP. Esses processos podem ser divididos em três grupos distintos: Recuperação de dados: a primeira tarefa é reunir as informações relevantes das máquinas gerenciadas. A ferramenta irá fazê-lo usando seu poller, um script que executa a coleta de informações em cada agente, executado a partir dos agendadores de tarefas do sistema operacional onde o Cacti foi instalado;

79 5.2 Ferramentas utilizadas 78 Figura 24: Tela do Cacti mostrando os dispositivos da rede Armazenamento de dados: em seguida, a informação coletada é armazenada para uso posterior, a partir do uso de RRDTool. O RRD é um sistema para armazenar e exibir informações temporais. Ele armazena os dados de uma forma muito compacta com o intuito de garantir que o tamanho dos arquivos expanda ao longo do tempo e, ao mesmo tempo, possa criar gráficos elaborados; Apresentação de dados: assim como a etapa anterior, o Cacti utiliza o RRDTool. Além do método de armazenamento de informações, o RRDTool fornece uma função integrada de geração de gráficos, podendo os mesmos salvos em formatos de imagem. Instalação do Cacti O processo de instalação da ferramenta Cacti ocorreu na estação de gerência, descrita na Seção 5.1. Neste processo também foram instaladas algumas ferramentas auxiliares necessárias para o funcionamento correto do Cacti. A fim de documentar o procedimento como um todo, a seguir, todo esse trabalho será descrito. Como descrito anteriormente, o Cacti é um ferramental composto por diversos subsistemas. Estes dependem de componentes específicos para o seu correto funcionamento, tais como um banco de dados para armazenamento das informações, um agente SNMP para a estação de gerência, um ambiente PHP com módulo de interface com NET-SNMP e por fim, um servidor Web para exibição da ferramenta e dos gráficos criados a partir do RRDTool.

80 5.2 Ferramentas utilizadas 79 Figura 25: Tela do Cacti mostrando os gráficos de utilização da rede Para instalação desses componentes, nos sistema compatíveis com o RHEL, os principais pacotes requeridos são: mysql: pacote referente ao MySQL, banco de dados; mysql-server: pacote referente ao MySQL, servidor de banco de dados; net-snmp: ambiente completo para suporte e execução de SNMP. php: pacote referente ao ambiente PHP; php-mysql: extensão do PHP para suporte a MySQL; php-snmp: extensão do PHP para suporte a NET-SNMP; httpd: pacote referente ao Apache, o servidor Web; Estas dependências podem ser instaladas através do YUM, gerenciador de pacote da distribuição GNU/Linux utilizada na estação de gerência. Este procedimento deve ser realizado via usuário root: # yum install mysql mysql - server php - mysql php - pear php - common php - gd php - devel php php - mbstring php - cli php - snmp php -pear -Net - SMTP php - mysql httpd net -snmp - utils php - snmp net -snmp - libs Além de instalar, é necessário inicializar os serviços básicos, como o MySQL e HTTPd (Apache):

81 5.2 Ferramentas utilizadas 80 # service httpd start # chkconfig httpd on # service mysqld start # chkconfig mysqld on Depois de instaladas as dependências e inicializado os serviços, deve-se configurar o servidor de banco de dados para o Cacti. Esta configuração é composta pela criação de um usuário, este utilizado pela ferramenta para acessar seu banco de dados, e um banco de dados, local onde as informações do Cacti serão armazenadas. Para criar o banco de dados do Cacti no MySQL, usa-se o comando abaixo, onde cactidb é o nome do banco criado: # mysql - u root - p - e create database cactidb Para criar o usuário cactiuser com os privilégios necessários no banco recém-configurado, deve-se entrar no MySQL e executar a seguinte configuração, substituindo senha por uma senha adequada: # mysql -u root -p # mysql > GRANT ALL ON cactidb.* TO cactiuser localhost IDENTIFIED BY senha ; # mysql > FLUSH privileges ; # mysql > exit Além disso, o usuário deve ser criado no Linux também: # useradd cactiuser Depois de configurado o banco de dados, deve-se configurar o Cacti em si. Para tal, deve-se obtê-lo no site oficial (THE CACTI GROUP, INC., 2012) e descompacta-lo em um local adequado. No nosso caso, optamos por descompacta-lo em /var/www/html/cacti/ : # cd / var / www / html # tar xzvf cacti. tar.gz # cd / var / www / html / cacti Em seguida devem-se importar as tabelas iniciais do Cacti para o seu respectivo banco de dados, cactidb. Esse processo é crucial para o funcionamento do Cacti: # mysql - u root - p cactidb < cacti. sql Depois da importação, deve-se configurar o Cacti com as informações de acesso ao seu banco de dados, cactidb. Essa configuração deve ser feita no arquivo include/config.php, especificando tipo, nome do banco, endereço, usuário e senha. Por exemplo:

82 5.3 Funcionamento e parâmetros dos scripts de teste 81 $database_ type = " mysql "; $database_ default = " cactidb "; $database_ hostname = " localhost "; $database_ username = " cactiuser "; $database_ password = " senha "; Depois a linha abaixo deve ser adicionada no arquivo /etc/crontab. Esta configuração fará com que o Cacti execute o poller com cinco minutos de intervalo, contudo, não refletindo no intervalo dos gráficos exibidos pelo Cacti. */5 * * * * cactiuser php / var / www / html / cacti / poller. php > / dev / null 2 >&1 Por fim, depois dessa configuração, o Cacti já poderá ser acessado a partir do da URL Funcionamento e parâmetros dos scripts de teste Conforme explicado anteriormente na seção 5.2, utilizamos a ferramenta de benchmark IOR para executar as rodadas de testes controlados no ambiente estudado e a biblioteca de comunicação MPI para a troca de mensagens entre os nós, uma vez que um nó do Netuno não tem acesso direto à memória do outro. Nos testes utilizamos os mesmos parâmetros definidos pela avaliação do sistema de armazenamento feita pela aluna Juliana Correia em (CORREA; SILVA, 2009). Apesar de nosso objetivo inicial de buscar gargalos no sistema de rede do Netuno, também optamos por avaliar arquivos pequenos, visando fazer uma avaliação de desempenho mais abrangente do cluster. Antes do programa (script) de teste ser executado, é necessário que o mesmo seja colocado em uma fila de execução do Netuno. Como vários programas podem estar sendo executados ao mesmo tempo, é necessário o uso do gerenciador TORQUE, que fica responsável por alocar os recursos de forma eficiente para todos os programas. Após isso, cada programa executado passa a constituir uma tarefa, chamada de job e recebendo um novo Job ID. Script PBS Para o Torque poder executar a tarefa, é necessário definir os valores da variáveis de execução, como, por exemplo, a quantidade de nós que serão utilizados e quantos proces-

83 5.3 Funcionamento e parâmetros dos scripts de teste 82 sos serão disparados, além das variáveis do sistema de fila. Essas variáveis são definidas como comentários com a palavra "PBS"no início, e recebem o nome de script PBS. As variáveis do sistema de fila utilizadas podem ser encontradas na Tabela 4. Parâmetro Valor Descrição -l <valor> Define parâmetros gerais como numero de nós necessários (nodes) e quantidade de processos por nó (ppn), assim como o tempo máximo que a tarefa pode consumir (walltime) -j oe Define que a saída STDOUT e a STDERR serão consolidadas no mesmo arquivo de saída. Do contrário, arquivos separados seriam criados a cada execução -q <valor> Determina o nome da fila de execução que será usada para a tarefa em questão -N <valor> Determina o nome dado a tarefa. Se não definido, o nome do script é utilizado -V - Habilita o modo verborrágico para o PBS/Torque Tabela 4: Variáveis do sistema de fila PBS/Torque Assim, o IOR é executado a partir do sistema de escalonamento PBS/Torque utilizado no cluster Netuno e, após essa parte inicial, os scripts de teste propriamente ditos ficam responsáveis pela criação do job e a execução das rodadas do IOR. Um modelo de script utilizado em nosso trabalho pode ser encontrado no Apêndice A. Os testes foram realizados utilizando o método MPI-IO para E/S nos dispositivos de armazenamento, com tamanho e blocos de arquivos variáveis, com processos escrevendo tanto no mesmo arquivo compartilhado (N:1), esquema mostrado na Figura 26, quanto em arquivos independentes (N:N), mostrado na Figura 27. Na Tabela 5 encontra-se a definição dos parâmetros utilizados no script do IOR. Figura 26: Acesso N:1

84 5.3 Funcionamento e parâmetros dos scripts de teste 83 Figura 27: Acesso N:N Parâmetro Valor Descrição -perhost <# processos> Número de processos MPI consecutivos em cada nó -n <# processos> Número total de processos que serão iniciados -a MPIIO Método utilizado para E/S nos dispositivos de armazenamento -t <TSIZE> Tamanho da transferência em bytes -b <BSIZE> Tamanho do bloco escrito por tarefa em bytes -i <NUMITER> Número de repetições por teste -F - Define se cada processo terá o seu arquivo para E/S (N:N); sua ausência define uma operação N:1 -o <WORKDIR> Define o nome e a localização de onde o(s) arquivo(s) de teste serão criados Tabela 5: Definição dos parâmetros utilizados no script de teste Para arquivos pequenos, utilizamos tamanho da transferência (TSIZE) de 256 KB, tamanho pequeno para avaliarmos como o Panasas lida com tal situação. Trabalhamos ainda com tamanhos variáveis de blocos (BSIZE), quantidade de processos por nó e por tarefa. O número de repetições para cada teste (NUMITER) foi de 5 rodadas, e por fim, como WORKDIR, utilizamos o diretório scratch/projetos/ufrj/dcc/davivcgarcia, mapeado no PanFS. Já para arquivos grandes, o TSIZE escolhido foi de 64 MB, valor alto para tentar atenuar possíveis efeitos de buffer. Seguimos o mesmo raciocínio empregado na avaliação de arquivos pequenos, utilizando diferentes BSIZE, processos por nó e por tarefas. O número de repetições foi mantido em 5 rodadas, utilizando também o mesmo WORKDIR. Por fim, também escolhemos variar o TS para arquivos grandes, a fim de avaliar se ocorreria algum impacto no sistema.

85 5.3 Funcionamento e parâmetros dos scripts de teste 84 Depois dessas definições, foram executados primeiro o teste de leitura e escrita para N-1 e depois para N-N, ambos utilizando o mesmo subconjunto de nós e definições de tamanho de bloco e tamanho da transferência.

86 85 6 Apresentação e análise dos resultados Todas as medições utilizadas neste trabalho foram monitoradas através da ferramenta de coleta Cacti, versão 0.8.8, que monitorou o tráfego dos switches do cluster Netuno no período de 17 de janeiro de 2012 até 25 de maio do mesmo ano. Os testes de benchmark foram gerados a partir da ferramenta IOR, versão Dentro deste intervalo de tempo, foram selecionados alguns períodos menores, onde o cluster estava ocioso, ou executando nossos testes de benchmark, ou executando aplicações de terceiros. As informações coletadas estão dispostas em tabelas para melhor visualização dos resultados. Para exemplificar como as informações foram apresentadas pelo Cacti, na Figura 28 temos o gráfico do tráfego em uma das interfaces de conexão do Switch Core aos Switches Topo de Rack do Netuno durante todo o período de monitoramento. Figura 28: Tráfego de uma interface de conexão do Netuno durante o período total de monitoramento do cluster Por fim, fizemos uma avaliação de desempenho da rede do Netuno, a fim de monitorar o comportamento do mesmo de acordo com os diferentes parâmetros utilizados. Tais

87 6.1 Padrão de tráfego sob condição idle 86 resultados estão dispostos em gráficos, buscando dar maior clareza ao leitor com relação aos resultados obtidos. 6.1 Padrão de tráfego sob condição idle Como esperado, as medições em períodos ociosos no cluster Netuno mostraram um tráfego muito baixo, o qual se refere à somente as mensagens de controle dos dispositivos do cluster. O período avaliado foi de aproximadamente 15 horas, no dia 27 de fevereiro de 2012, uma vez que nenhuma aplicação e nenhum teste estavam sendo executados no cluster. A título de comparação, a média das taxas médias de tráfego de entrada nas interfaces durante o intervalo de tempo de medição foi de 630 B/s e de saída, de 4 KB/s. As taxas individuais de cada interface são mostradas na Tabela 6. Taxa Média (Em Kbps) Interface Entrada Saída Te1/1 5,2 39,7 Te1/2 11,2 75,6 Te1/3 6,4 52,5 Te1/4 9,0 70,8 Te2/1 5,4 35,4 Te2/2 - - Te2/3 6,3 43,2 Te2/4 9,0 67,0 Te3/1 10,9 9,1 Te3/2 0,4 5,6 Te3/3 0,2 5,3 Te3/4 0,3 6,3 Te4/1 - - Te4/2 0,6 1,1 Te4/3 0,4 1,2 Te4/4 - - Média 5,0 31,8 Tabela 6: Taxa média de tráfego das interfaces de conexão do Switch Core aos Switches Topo de Rack do Netuno sob estado idle Podemos constatar que o tráfego de saída foi maior devido as trocas de mensagens do protocolo de controle, além do envio de estatísticas para o programa de coleta de dados. As interfaces Te2/2, Te4/1 e Te4/4 não estavam ativas no momento desta avaliação e não foram contabilizadas no cálculo das taxas.

88 6.2 Padrão de tráfego durante benchmark 87 De maneira semelhante, na Tabela 7 temos as taxas médias de tráfego individuais das interfaces de conexão do cluster ao seu sistema de armazenamento remoto (PanFS). Taxa Média (Em Kbps) Interface Entrada Saída Gi7/25 8,3 17,8 Gi7/26 6,5 7,5 Gi7/27 22,7 9,0 Gi7/28 9,0 19,2 Gi7/29 4,5 4,0 Gi7/30 4,3 4,2 Gi7/31 22,7 12,1 Gi7/32 5,0 19,6 Gi7/33 6,9 12,2 Gi7/34 4,5 4,8 Gi7/35 18,5 2,7 Gi7/36 7,4 9,6 Média 10,0 10,2 Tabela 7: Taxa média de tráfego das interfaces de conexão do Netuno ao Panasas em período ocioso 6.2 Padrão de tráfego durante benchmark Nesta avaliação buscamos avaliar o comportamento da rede ao operar com uma alta quantidade de dados, com o intuito de encontrar algum possível gargalo em sua rede. Para isto, utilizamos escrita N:N, com blocos de transferência de tamanho (TSIZE) de 64 MB, em um bloco com tamanho total (BSIZE) de 32 GB por nó. Foram usados no teste 32 nós, totalizando uma transferência agregada de 1 TB de dados. As taxas médias obtidas nesse teste foram de 222,5 MB/s para leitura e 156,6 MB/s para escrita, em um período de aproximadamente 3 horas e 20 minutos. Essas taxas, de uma forma geral, representaram um uso de apenas 15% da vazão teórica máxima para leitura e 10% para escrita. As taxas individuais de tráfego obtidas na rede são mostradas nas Tabelas 8 e 9. Como a escolha dos nós pelo Torque é feita de forma aleatória e o teste foi configurado para usar 32 nós, nem todos os racks foram utilizados. Isso explica o tráfego mínimo em algumas interfaces durante o teste.

89 6.2 Padrão de tráfego durante benchmark 88 Taxa Média (Em Mbps) Interface Entrada Saída Te1/1 23,6 7,8 Te1/2 103,8 43,6 Te1/3 102,6 48,3 Te1/4 20,6 4,2 Te2/1 38,5 7,7 Te2/2 - - Te2/3 87,2 50,3 Te2/4 19,2 3,7 Te3/1 56,0 33,8 Te3/2 0,1 0,1 Te3/3 0,0 0,0 Te3/4 0,0 0,1 Te4/1 - - Te4/2 0,0 0,1 Te4/3 0,0 0,1 Te4/4 - - Média 34,7 15,4 Tabela 8: Taxa média de tráfego das interfaces de conexão do Switch Core aos Switches Topo de Rack do Netuno durante o teste com massa de dados de 1TB. Taxa Média (Em Mbps) Interface Entrada Saída Gi7/25 40,3 89,7 Gi7/26 44,2 101,2 Gi7/27 40,4 108,5 Gi7/28 36,1 112,3 Gi7/29 42,2 105,6 Gi7/30 43,6 108,7 Gi7/31 45,4 88,9 Gi7/32 43,5 101,7 Gi7/33 37,9 93,8 Gi7/34 45,7 95,4 Gi7/35 42,7 109,0 Gi7/36 34,1 89,5 Média 41,4 100,3 Tabela 9: Taxa média de tráfego das interfaces de conexão do Netuno ao Panasas durante o teste com massa de dados de 1TB

90 6.3 Padrão de tráfego durante monitoramento de uma aplicação real Padrão de tráfego durante monitoramento de uma aplicação real Nas medições de execução de aplicações reais no Netuno, uma aplicação foi avaliada durante um intervalo de aproximadamente 4 horas e 30 minutos, no dia 18 de abril de Uma vez que o cluster não é de uso exclusivo, não é possível prever qual a origem da aplicação monitorada. Tal acompanhamento foi realizado com intuito de avaliar um possível comportamento do cluster em uso cotidiano. Ao compararmos com as taxas médias de utilização do cluster em períodos ociosos, vimos que existe uma grande diferença no tráfego das interfaces de interconexão dos nós. Isto significa que a aplicação envolvia muitas trocas de dados entre os mesmos. apresentou também acesso médio de 2 Mbps nas interfaces de entrada do sistema de arquivos remoto, valores razoáveis considerando o período avaliado. Nas Tabelas 10 e 11 são apresentados os valores encontrados durante a execução da aplicação randômica. Taxa Média (Em Mbps) Interface Entrada Saída Te1/1 11,2 9,9 Te1/2 11,9 11,6 Te1/3 11,8 8,3 Te1/4 10,2 10,8 Te2/1 11,6 11,0 Te2/2 - - Te2/3 10,2 8,9 Te2/4 12,5 8,4 Te3/1 0,3 0,5 Te3/2 6,9 6,7 Te3/3 0,1 0,1 Te3/4 0,0 0,0 Te4/1 - - Te4/2 0,2 0,2 Te4/3 0,1 0,1 Te4/4 - - Média 6,7 5,9 Tabela 10: Taxa média de tráfego das interfaces de conexão do Switch Core aos Switches Topo de Rack do Netuno durante uma aplicação real Ela No Apêndice C são encontrados os gráficos dos tráfegos das interfaces do Switch Core coletados a partir do Cacti no momento da monitoração dessa aplicação real.

91 6.4 Avaliação de desempenho 90 Taxa Média (Em Mbps) Interface Entrada Saída Gi7/25 1,7 4,3 Gi7/26 1,2 1,9 Gi7/27 4,5 2,3 Gi7/28 1,8 4,3 Gi7/29 1,1 0,7 Gi7/30 1,1 0,7 Gi7/31 4,1 2,2 Gi7/32 1,1 3,1 Gi7/33 1,5 2,6 Gi7/34 0,7 1,1 Gi7/35 3,5 0,5 Gi7/36 1,6 1,2 Média 2,0 2,1 Tabela 11: Taxa média de tráfego das interfaces de conexão do Netuno ao Panasas durante a execução de uma aplicação real 6.4 Avaliação de desempenho Aqui apresentamos a avaliação da rede do cluster, utilizando diferentes métricas, a partir de testes realizados utilizando a ferramenta IOR. Essa ferramenta forneceu em seus resultados todos os dados referentes a taxas médias de acesso, variância e latência das amostras. Na avaliação de desempenho nos testes envolvendo variação na quantidade de processos, a ferramenta Cacti foi usada para monitorar o tráfego nas interfaces dos switches e do sistema de arquivos, na busca de possíveis limitações nos mesmos. Esse estudo tem como intuito estimar conjuntos de parâmetros razoáveis para utilização do Netuno por aplicações reais. As avaliações apresentadas mediram as taxas de leitura e escrita dos arquivos, além da latência, em que foi medido o tempo médio para leitura/escrita referente ao BSIZE, ou seja, o tamanho do bloco total. Os testes foram feitos tanto para N:1 quanto para N:N, em dois grupos: para arquivos pequenos (Grupo 1), da ordem de 4 MB, e para arquivos grandes (Grupo 2), da ordem de 1 ou 32 GB. Essa escolha foi feita para analisar como o PanFS trabalha com esses diferentes grupos. Convém destacar que alguns gráficos estão em escala logarítmica, devido a enorme diferença entre as taxas apresentadas.

92 6.4 Avaliação de desempenho Variação da quantidade de tarefas executando em cada nó Neste teste foram avaliados o desempenho utilizando 8 nós, tendo estes rodado com 1, 4 ou 8 tarefas executando em cada nó, de forma a avaliar o compartilhamento da interface de rede Grupo 1 Para o teste utilizando arquivos pequenos, utilizamos 4 MB para o tamanho do bloco (BSIZE) e 16 KB para o bloco de transferência (TSIZE), com os resultados mostrados nas Figuras 29, 30 e 31. Figura 29: Taxa de leitura variando a quantidade de processos por nó - BS 4 MB/TS 16 KB Figura 30: Taxa de escrita variando a quantidade de processos por nó - BS 4 MB/TS 16 KB

93 6.4 Avaliação de desempenho 92 Figura 31: Latência ao variar a quantidade de processos por nó - BS 4 MB/TS 16 KB Grupo 2 Para arquivos maiores, foi utilizado 1 GB para o tamanho do bloco (BSIZE) e 64 MB para o bloco de transferência (TSIZE), com os resultados mostrados nas Figuras 32, 33 e 34. Figura 32: Taxa de leitura variando a quantidade de processos por nó - BS 1 GB/TS 64 MB

94 6.4 Avaliação de desempenho 93 Figura 33: Taxa de escrita variando a quantidade de processos por nó - BS 1 GB/TS 64 MB Figura 34: Latência ao variar a quantidade de processos por nó - BS 1 GB/TS 64 MB Análise A partir dos gráficos é possível identificar que o aumento do número de processos por nó não é sempre uma opção garantida para aumento de performance das atividades de E/S. Os testes executados, tanto no Grupo 1 quanto no Grupo 2, mostraram que o aumento do número de processos por nó aumenta a performance somente para atividades de leitura. Em relação as atividades de escrita, a sua interferência sobre a performance é negativa, fazendo com que a maior taxa de escrita seja com somente um processo executando em cada nó. Uma explicação para esse comportamento se deve a forma em que o acesso ao sistema de armazenamento é realizado. O sistema de arquivos utilizado no dispositivo de

95 6.4 Avaliação de desempenho 94 armazenamento, o PanFS, foi desenvolvido para ser aderente ao padrão POSIX (Portable Operating System Interface), sendo completamente compatível com o kernel Linux e dessa forma facilitar a sua implementação (WELCH et al., 2008). Por essa abordagem, o PanFS possui mecanismos de sincronização, dentre ele o mecanismo conhecido como shared-exclusive, em que é possível se ter múltiplos leitores simultaneamente, mas somente um escritor por vez. Esse mecanismo evita que diversos escritores tentem acessar ao mesmo tempo o mesmo arquivo, fazendo com que o mesmo fosse corrompido. Neste caso, quando temos mais de um processo por nó escrevendo no PanFS, na verdade temos escritas serializadas localmente, devido ao mecanismo de sincronismo. Fato contrário ocorre na leitura, em que temos realmente acesso paralelo ao PanFS. Outro ponto observável são as baixas taxas apresentadas pela escrita no teste envolvendo arquivos pequenos. O principal fator responsável por isso é o excessivo overhead causado no sistema, uma vez que o IOR não opera de forma satisfatória em operações de escrita com valores na ordem de grandeza abaixo de 100 KB para o parâmetro transfersize (SHAN; SHALF, 2007). Lembrando que o valor usando em nossos testes envolvendo arquivos pequenos foi de 16 KB, outro ponto que também influenciou as taxas de escrita para arquivos pequenos de forma negativa foi política de armazenamento do PanFS, descrita na Seção Essa, ao aplicar RAID 1 (mirror) à arquivos menores que 64 KB, provoca, devido ao espelhamento dos arquivos, uma queda na performance de escrita e uma aceleração na leitura, pois os dados se encontram dispostos em mais de um local. Também referente às taxas de transferência, devido ao RAID 5 aplicado pelo PanFS em arquivos com tamanhos iguais ou maiores que 64 KB, temos uma contribuição para as taxas serem superiores tanto na leitura como na escrita para arquivos grandes em relação aos arquivos dito aqui pequenos. Em relação as taxas de transferência de leitura serem maiores que de escrita, o principal foco está relacionado ao sistema operacional, pois nas operações de leitura, os dados são trazidos do disco diretamente para a cache, não tendo motivos para o SO acessar o disco novamente para buscar o mesmo dado. Outro fator que contribui é a forma de implementação do PanFS, que como devemos lembrar, o cliente, após efetuar o mapa de localizações dos arquivos do servidor de metadados, comunica-se diretamente com o Sistema de Arquivos. Tal efeito contudo não se realiza nas operações de escrita, pois o SO não tem como saber o que vai ser escrito, tendo que repetir a consulta ao disco tantas vezes quanto forem necessárias. Novamente em relação a leitura no acesso N:N, temos severos efeitos de bufferização,

96 6.4 Avaliação de desempenho 95 também sentidos na avaliação de Correa e Silva (2009), que, como podemos notar, fazem as taxas ultrapassarem o limite teórico de transferência da rede, na faixa de 12 Gbps. Por fim, em relação as taxas N:1 serem menores que as taxas N:N, temos que, no acesso N:1, todos os processos estão acessando o mesmo arquivo ao mesmo tempo, o que acaba criando contenções devido a concorrência no acesso ao arquivo no sistema de arquivos (GRIDER et al., 2006). Um motivo que poderia diminuir os valores de transferência no acesso N:N seriam as requisições ao servidor de metadados para cada arquivo, mas, como dito anteriormente em relação ao Panasas, o cliente, após receber do servidor de metadados o mapa de localização, passa a se comunicar diretamente com o sistema de arquivos, também propiciando ganho de desempenho nas requisições N:N Variação no tamanho do bloco total (BSIZE) Neste teste foram avaliados o desempenho ao variarmos o tamanho total do arquivo (BSIZE), a partir de um bloco de transferência fixo (TSIZE). Para o teste utilizando arquivos pequenos, o TSIZE escolhido foi de 16 KB. Para arquivos grandes, 64 MB. Em ambos os casos foi avaliado o comportamento com 8, 16 e 32 nós Grupo 1 8 nós 36. O resultado para arquivos pequenos, utilizando 8 nós, são mostrados nas Figuras 35 e

97 6.4 Avaliação de desempenho 96 Figura 35: Taxa de leitura variando o tamanho do bloco total (BSIZE) - TS 16 KB/1 PPN/8 Nós Figura 36: Taxa de escrita variando o tamanho do bloco total (BSIZE) - TS 16 KB/1 PPN/8 Nós 16 nós 38. O resultado para arquivos pequenos, utilizando 16 nós, são mostrados nas Figuras 37 e

98 6.4 Avaliação de desempenho 97 Figura 37: Taxa de leitura variando o tamanho do bloco total (BSIZE) - TS 16 KB/1 PPN/16 Nós Figura 38: Taxa de escrita variando o tamanho do bloco total (BSIZE) - TS 16 KB/1 PPN/16 Nós 32 nós O resultado para arquivos pequenos, utilizando 32 Nós, são mostrados nas Figuras 39 e 40.

99 6.4 Avaliação de desempenho 98 Figura 39: Taxa de leitura variando o tamanho do bloco total (BSIZE) - TS 16 KB/1 PPN/32 Nós Figura 40: Taxa de escrita variando o tamanho do bloco total (BSIZE) - TS 16 KB/1 PPN/32 Nós Grupo 2 8 nós Para arquivos grandes usando 8 nós, o resultados são apresentados nas Figuras 41 e 42.

100 6.4 Avaliação de desempenho 99 Figura 41: Taxa de leitura variando o tamanho do bloco total (BSIZE) - TS 64 MB/1 PPN/8 Nós Figura 42: Taxa de escrita variando o tamanho do bloco total (BSIZE) - TS 64 MB/1 PPN/8 Nós 16 nós Para arquivos grandes usando 16 nós, temos os resultados nas Figuras 43 e 44.

101 6.4 Avaliação de desempenho 100 Figura 43: Taxa de leitura variando o tamanho do bloco total (BSIZE) - TS 64 MB/1 PPN/16 Nós Figura 44: Taxa de escrita variando o tamanho do bloco total (BSIZE) - TS 64 MB/1 PPN/16 Nós 32 nós 46. Para arquivos grandes usando 32 nós, os resultados são mostrados nas Figuras 45 e

102 6.4 Avaliação de desempenho 101 Figura 45: Taxa de leitura variando o tamanho do bloco total (BSIZE) - TS 64 MB/1 PPN/32 Nós Figura 46: Taxa de escrita variando o tamanho do bloco total (BSIZE) - TS 64 MB/1 PPN/32 Nós Análise Esperávamos que não houvesse variação qualitativa nas taxas apresentadas dentro de cada subgrupo (8 nós, 16 nós ou 32 nós), uma vez que o único parâmetro avaliado não fixo foi o do tamanho do bloco total (BSIZE) (SHAN; SHALF, 2007). Conforme apresentado nos gráficos, essa expectativa se concretizou, tanto na leitura, como na escrita, em acessos N:1 e N:N. Convém ressaltar que a diferença apresentada dentro de cada subgrupo é explicada devido a possíveis interferências na rede durante os testes de benchmark. Podemos notar que o mecanismo de sincronia descrito no teste analisado na Seção só possui importância local, visto que no sistema de arquivos a performance

103 6.4 Avaliação de desempenho 102 agregada aumentou, tanto na leitura quanto na escrita quando trabalhamos com arquivos grandes (Grupo 2) conforme houve aumento no número de nós usados, caracterizando de fato acesso paralelo ao PanFS. Para arquivos pequenos (Grupo 1), tal aumento só foi observado na leitura, tendo novamente a escrita apresentado taxas pequenas e decrescentes. Esse fato é devido as regras de RAID implementadas pelo PanFS, mencionadas no teste em que ocorre a variação de tarefas executando em cada nó, além da maior frequência de colisões causadas pelas requisições chegando aos switches de forma simultânea. De forma similar a outros testes, tivemos taxas de acesso N:N maiores que nos acessos N:1, pelos mesmos motivos já citados em outros testes, além de efeitos de buffers, notados nas taxas de leitura obtidas acima do limite teórico da rede. Também foram detectadas taxas de escrita modestas nos testes envolvendo arquivos pequenos, além das taxas de leitura superiores às de escrita em todos os casos Variação no tamanho do bloco de transferência (TSIZE) Seguindo o mesmo princípio do teste descrito na Seção 6.4.2, procuramos analisar o comportamento do sistema de arquivos do cluster Netuno ao trabalharmos com diferentes valores os blocos de transferência (TSIZE). Para essa avaliação somente iremos apresentar os testes envolvendo arquivos grandes (BS 1 GB), uma vez que o comportamento para arquivos de menor porte foi análogo. Novamente iremos avaliar o desempenho usando 8, 16 e 32 nós. 8 nós Usando 8 nós, o resultados são apresentados nas Figuras 47, 48 e 49.

104 6.4 Avaliação de desempenho 103 Figura 47: Taxa de leitura variando o tamanho do bloco de transferência (TSIZE) - BS 1 GB/1 PPN/8 Nós Figura 48: Taxa de escrita variando o tamanho do bloco de transferência (TSIZE) - BS 1 GB/1 PPN/8 Nós 16 nós Agora usando 16 nós, temos os resultados nas Figuras 50, 51 e 52.

105 6.4 Avaliação de desempenho 104 Figura 49: Latência ao variar o tamanho do bloco de transferência (TSIZE) - BS 1 GB/1 PPN/8 Nós Figura 50: Taxa de leitura variando o tamanho do bloco de transferência (TSIZE) - BS 1 GB/1 PPN/16 Nós

106 6.4 Avaliação de desempenho 105 Figura 51: Taxa de escrita variando o tamanho do bloco de transferência (TSIZE) - BS 1 GB/1 PPN/16 Nós Figura 52: Latência ao variar o tamanho do bloco de transferência (TSIZE) - BS 1 GB/1 PPN/16 Nós 32 nós Por último, usando 32 nós, os resultados são mostrados nas Figuras 53, 54 e 55.

107 6.4 Avaliação de desempenho 106 Figura 53: Taxa de leitura variando o tamanho do bloco de transferência (TSIZE) - BS 1 GB/1 PPN/32 Nós Figura 54: Taxa de escrita variando o tamanho do bloco de transferência (TSIZE) - BS 1 GB/1 PPN/32 Nós Análise É possível constatar que as taxas de transferência vão aumentando ligeiramente dentro de cada subconjunto. Esse resultado é explicado pelo fato de que arquivos com blocos de transferência grandes (TSIZE) implicam em um menor número de transações a serem efetuadas, reduzindo o custo para a transmissão dos pacotes (GRIDER et al., 2006). Atentamos também outra descoberta interessante: o não decrescimento das taxas de transferência a medida que aumentamos gradualmente o tamanho do bloco de transferência. Essa performance consistente apresentada pelo sistema de arquivos da Panasas não é comumente encontrada em muitos sistemas de arquivos, como podemos ver, por exemplo,

108 6.4 Avaliação de desempenho 107 Figura 55: Latência ao variar o tamanho do bloco de transferência (TSIZE) - BS 1 GB/1 PPN/32 Nós em Ohta et al. (2010). Novamente, as mesmas variações nas taxas de acesso N:1 e N:N já descritos, além dos efeitos de bufferização foram encontrados nos testes Variação no número de processos Para este último teste foram avaliados o desempenho ao variarmos a quantidade de processos envolvidos em determinada tarefa. Tanto para arquivos pequenos quanto para arquivos grandes, o comportamento foi avaliado para 32, 64, 96, 128, 192 e 256 processos Grupo 1 No teste envolvendo arquivos pequenos, foram utilizados novamente 4 MB para o tamanho do bloco (BSIZE) e 16 KB para o bloco de transferência (TSIZE), com os resultados mostrados nas Figuras 56, 57 e 58.

109 6.4 Avaliação de desempenho 108 Figura 56: Taxa de leitura variando a quantidade de processos para determinada tarefa - BS 4MB/TS 16KB Figura 57: Taxa de escrita variando a quantidade de processos para determinada tarefa - BS 4MB/TS 16KB Grupo 2 Com arquivos maiores, foram utilizados 32 GB para o tamanho do bloco (BSIZE) e 64 MB para o bloco de transferência (TSIZE), com os resultados sendo mostrados nas Figuras 59, 60 e 61.

110 6.4 Avaliação de desempenho 109 Figura 58: Latência ao variar a quantidade de processos para determinada tarefa - BS 4MB/TS 16KB Figura 59: Taxa de leitura variando a quantidade de processos para determinada tarefa - BS 32GB/TS 64MB Tráfego nas interfaces Constatamos que o Cacti, apesar de ser uma ótima ferramenta para monitoramento de redes, não foi uma boa escolha como ferramenta para a avaliação de desempenho proposta neste trabalho, devido a problemas de amortização e da própria natureza da ferramenta. Tomando os dados contidos nas Tabelas 12, 13 e 14, podemos ver que a distribuição dos tráfegos nas interfaces de acesso ao sistema de arquivos PanFS está de certa forma bem balanceado, com throughput médio para as interfaces, independente dos casos, oscilando em torno de 50 Mbps. Agregando o duplex, temos em média taxas de 100 Mbps

111 6.4 Avaliação de desempenho 110 Figura 60: Taxa de escrita variando a quantidade de processos para determinada tarefa - BS 32GB/TS 64MB Figura 61: Latência ao variar a quantidade de processos para determinada tarefa - BS 32GB/TS 64MB por interface. Tal valor, considerando que estamos operando em uma interface Gigabit Ethernet, significa apenas 10% da sua capacidade máxima teórica. Tomando as estatísticas das interfaces dos equipamentos intermediários de rede envolvidos nos testes, não encontramos nenhum erro ou descarte a nível de enlace (camada 2 do protocolo OSI - Ethernet) ou a nível de rede (camada 3 do protocolo OSI - IP). Também não encontramos nenhum tipo de gargalo interno nos equipamentos que explicasse o baixo consumo da rede. Uma explicação para esse resultado é a rede do Netuno estar corretamente dimensionada, e, portanto, não oferecer nenhum tipo de interferência nos resultados dos testes.

112 6.4 Avaliação de desempenho 111 Taxa Média (Em Mbps) 32 Processos 64 Processos N:1 N:N N:1 N:N Interface Entrada Saída Entrada Saída Entrada Saída Entrada Saída Gi7/25 44,8 61,5 60,6 72,5 46,1 46, ,4 Gi7/26 48,5 52,5 55,6 39,1 44,3 44,8 49,3 47,7 Gi7/27 47,5 50,2 65,4 46,1 51,5 45,8 48,8 47,7 Gi7/28 49,1 58,3 52,3 57,9 46,3 48, Gi7/29 41,6 53,7 62,9 42, ,4 59,5 48,6 Gi7/30 37,9 41,1 68,3 56,9 47,1 46,4 46,7 43,7 Gi7/31 52,3 38,4 63, ,4 59, ,9 Gi7/32 39,4 48, ,9 48,3 57,5 54,4 59,5 Gi7/33 56,2 54,7 54,6 51,1 45,5 49,2 57,5 55,6 Gi7/34 41,3 51,5 52,7 59,2 41,5 55,2 47,6 51,6 Gi7/35 38,3 57,0 56,7 32,8 49,3 42,2 48,9 51,4 Gi7/36 29,6 49,7 52,5 75,9 43,2 39,7 50,7 52 Total 526,5 617,0 696,5 654,6 564,5 574,8 602,4 630,1 Tabela 12: Taxa média nas interfaces de acesso ao sistema de arquivos remoto nos testes usando 32 e 64 processos Taxa Média (Em Mbps) 96 Processos 128 Processos N:1 N:N N:1 N:N Interface Entrada Saída Entrada Saída Entrada Saída Entrada Saída Gi7/25 35,1 53,9 63,2 67,3 44, ,7 54,2 Gi7/26 41,4 43,8 57,8 52,6 48,4 46,7 52,1 43,3 Gi7/27 44,6 45,1 64,6 50,9 46,7 43,4 58,3 47 Gi7/ ,8 56,9 54,5 51,8 48,2 50,6 49 Gi7/29 61,5 49,7 65,8 50, ,4 68,2 47,3 Gi7/ ,3 53,7 53,7 43,6 43,7 52,7 46,4 Gi7/31 44,7 47,5 57, ,6 52,4 52,7 59 Gi7/32 44,8 59,9 59, ,8 48,5 52,5 63,1 Gi7/33 53,4 55,5 50,5 58,7 51,4 49,4 54,9 51,3 Gi7/34 47,1 57, ,3 46,9 47,8 49,1 52,9 Gi7/35 56, , , ,8 47,5 Gi7/36 43,9 53,4 54, ,4 52,5 51,5 Total 569,0 607,2 688,5 671,9 570,9 544,9 652,1 612,5 Tabela 13: Taxa média nas interfaces de acesso ao sistema de arquivos remoto nos testes usando 96 e 128 processos

113 6.4 Avaliação de desempenho 112 Taxa Média (Em Mbps) 192 Processos 256 Processos N:1 N:N N:1 N:N Interface Entrada Saída Entrada Saída Entrada Saída Entrada Saída Gi7/25 45,7 40,8 58,3 62,8 47,7 41,3 47,2 59,4 Gi7/26 51,7 42,3 47,1 54,3 54,6 43,4 47,8 50,8 Gi7/27 48,9 47,5 49,6 46,6 50,4 49,2 50,2 42,7 Gi7/28 55,4 47,9 46, ,4 49,1 46,1 46,8 Gi7/29 44,7 37,3 58,1 55,6 43,1 38,5 57,3 52,9 Gi7/30 41,1 45,8 47,8 53,2 41,4 46,1 47,6 51 Gi7/31 51,9 56,6 53,3 65,1 53, ,1 61,3 Gi7/32 51,1 57,8 58, ,1 58,6 58,1 51,8 Gi7/33 52,1 42,2 58, ,7 43,7 58,4 56,1 Gi7/34 52,4 52,1 45,3 51,9 52,6 54,1 45,9 47 Gi7/35 37,1 42, ,7 42,7 48,1 38,4 Gi7/36 50,8 38,6 50, ,7 38,4 52,4 44,1 Total 582,9 551,4 632,0 641,5 593,0 563,1 603,2 602,3 Tabela 14: Taxa média nas interfaces de acesso ao sistema de arquivos remoto nos testes usando 192 e 256 processos Análise Novamente podemos notar que a performance agregada teve uma melhora ao aumentarmos a quantidade de processos envolvidos na tarefa, seguindo uma tendência encontrada na literatura, como, por exemplo, podemos citar a avaliação de Yu e Vetter (2008). Em relação a leitura no teste envolvendo arquivos pequenos, as mesmas considerações feitas na Seção se mostraram válidas. Outro ponto observado foi que, ao atingirmos 64 processos, ocorre uma desaceleração do aumento de desempenho, atingindo seu topo entre 128 e 192 processos. Acreditamos que tal fato ocorra em virtude de uma saturação do sistema de arquivos à medida que o número de nós envolvidos no acesso ao arquivos aumenta. Ainda, de forma similar aos outros testes, as taxas de acesso N:N foram maiores que nos acessos N:1, além das taxas de escrita pequenas nos testes envolvendo arquivos pequenos. Um ponto interessante noticiado nos testes envolvendo arquivos grandes foi que ao usarmos 32 GB como tamanho do bloco, houve uma diminuição nos efeitos de buffers presentes nas outras avaliações.

114 113 7 Considerações finais e trabalhos futuros 7.1 Problemas encontrados Durante a execução do nosso estudo, enfrentamos diversos problemas relacionado a operação do cluster Netuno. Estes problemas nos ajudaram a entender a distinção entre um ambiente de testes acadêmicos e um ambiente real de produção. Além disso, ganhamos experiência em operação e gerência de clusters de alto desempenho de grande porte. O primeiro problema encontrado foi durante as medições a partir do programa de benchmark IOR. Durante essa etapa detectamos que diversos nós estavam defeituosos devido aos problemas operacionais, o que dificultou o escalonamento das tarefas. Os nós problemáticos não foram removidos do sistema de escalonamento, fazendo com que o escalonador enviasse tarefas para os mesmos. Como os nós não estavam operacionais, as tarefas falhavam. As falhas na sua maior parte estavam relacionados a problemas nas bibliotecas das implementações de MPI disponíveis no ambiente. Essa situação foi resolvida identificando os nós operacionais e definindo o grupo de execução manualmente. O segundo problema foi relacionado como a nossa ferramenta de gerência coleta e armazena as informações. Como o Cacti foi desenvolvido para ambientes de produção, a coleta de informações é realizada em intervalos de 5 minutos. Esse intervalo garante que a rede não será inundada com requisições. Como consequência, temos os gráficos discretos. Essa discretização nos trouxe o problema de amortização de valores de picos, gerando gráficos na qual o valor médio de tráfego é exibido, e não taxas instantâneas. Para contornar esse problema, analisamos além do gráfico, as informações de erros e carga nas interfaces dos diversos switches.

115 7.2 Detecção de possíveis gargalos Detecção de possíveis gargalos A partir das diversas informações coletadas durante o nosso trabalho nenhum gargalo ou congestionamento foi evidenciada nos dispositivos de interconexão do cluster Netuno. As taxas médias de transferência nos diversos enlaces, que interligam os nós computacionais e o sistema de armazenamento em massa, se mostraram dentro dos valores aceitáveis, conforme vimos no Capítulo 6 e nos gráficos do Apêndice C. Da mesma forma não detectamos nenhum incremento nos contadores de descartes ou erros nas interfaces físicas dos diversos switches envolvidos nos estudo. Estes contadores indicariam gargalos baseados nas estatísticas das filas internas de transmissão e recepção de quadros dos switches. Podemos tomar como exemplo, as estatísticas dos enlaces Portchannel 1, ligação entre nós e o switch principal, e do Port-channel 101, ligação entre o switch principal e o sistema de armazenamento: SwitchCore01 # show interface Port - channel 1 Port - channel1 is up, line protocol is up ( connected ) Hardware is EtherChannel, address is 001 a. a2a2. f5dc ( bia 001 a. a2a2. f5dc ) MTU 1500 bytes, BW Kbit, DLY 10 usec, reliability 255/ 255, txload 1/255, rxload 1/ 255 Encapsulation ARPA, loopback not set Keepalive set (10 sec ) Full - duplex, 10 Gb/s input flow - control is off, output flow - control is off Members in this channel : Te1 /1 Te2 /1 ARP type : ARPA, ARP Timeout 04: 00: 00 Last input never, output never, output hang never Last clearing of " show interface " counters never Input queue : 0/2000/0/0 ( size / max / drops / flushes ); Total output drops : 0 Queueing strategy : fifo Output queue : 0/40 ( size / max ) 5 minute input rate 0 bits / sec, 0 packets / sec 5 minute output rate 2000 bits / sec, 4 packets / sec packets input, bytes, 0 no buffer Received broadcasts ( multicasts ) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 0 multicast, 0 pause input 0 input packets with dribble condition detected packets output, bytes, 0 underruns

116 7.2 Detecção de possíveis gargalos output errors, 0 collisions, 2 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 PAUSE output 0 output buffer failures, 0 output buffers swapped out SwitchCore01 # show interface Port - channel 101 Port - channel101 is up, line protocol is up ( connected ) Hardware is EtherChannel, address is 001 c.58 e0.6 baf ( bia 001 c.58 e0.6 bad ) MTU 1500 bytes, BW Kbit, DLY 10 usec, reliability 255/ 255, txload 1/255, rxload 1/ 255 Encapsulation ARPA, loopback not set Keepalive set (10 sec ) Full - duplex, 1000 Mb/s input flow - control is on, output flow - control is on Members in this channel : Gi7 /25 Gi7 /26 Gi7 /27 Gi7 /28 ARP type : ARPA, ARP Timeout 04: 00: 00 Last input never, output never, output hang never Last clearing of " show interface " counters never Input queue : 0/2000/0/0 ( size / max / drops / flushes ); Total output drops : 0 Queueing strategy : fifo Output queue : 0/40 ( size / max ) 5 minute input rate bits / sec, 14 packets / sec 5 minute output rate bits / sec, 21 packets / sec packets input, bytes, 0 no buffer Received broadcasts ( 146 multicasts ) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 0 multicast, 0 pause input 0 input packets with dribble condition detected packets output, bytes, 0 underruns 0 output errors, 0 collisions, 2 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 PAUSE output 0 output buffer failures, 0 output buffers swapped out Portanto a hipótese de que a performance das atividades de E/S no cluster Netuno estavam sendo limitadas por um gargalo na rede de acesso, levantada por Correa e Silva (2009), se mostrou inválida.

117 7.3 Outras considerações Outras considerações Nós mostramos que o desempenho de E/S do cluster HPC Netuno é altamente afetado pelo tipo de acesso aos arquivos, pelo tamanho do arquivo, pelo tamanho do bloco de transferência (TSIZE) e pela concorrência. No Netuno, a fim de obtermos bom desempenho arquivos grandes, acesso a múltiplo arquivos e blocos de transferência altos são altamente recomendados. Caso a aplicação priorize a leitura, o ideal é usar oito processos por nó. Caso a escrita seja altamente requerida, a melhor escolha será usar apenas um processo por nó. Em relação a quantidade de nós a serem usados, os testes mostraram que a melhor performance ocorreu com o uso entre 16 e 24 nós. A partir disso obtivemos uma queda na performance geral do cluster. Em algumas medições os resultados extrapolavam os valores máximos teóricos das transferências de leitura. Tal fato é relacionado à política do sistema operacional buscar somente uma vez os dados no disco, uma vez que existe uma única cópia compartilhada pelos 8 núcleos de cada nó. com isso, o sistema operacional faz apenas um acesso aos dados, armazenando os mesmos para posterior leitura. No caso da escrita, o mesmo não tem como prever os dados que serão escritos, o que demonstram as baixas taxas de transferência obtidas para escrita quando comparadas com as de leitura. Outros pontos relevante, foi, ao comparar as taxas de N:1 e N:N, os resultados para o acesso de N processos em um único arquivo são sempre menores dos que N processos em N arquivos, uma vez que existe concorrência entre os processos para acessar o arquivo único. E, ao trabalharmos tanto com arquivos pequenos quanto com arquivos grandes, vemos um aumento nos valores das taxas, constatando que o sistema de arquivos Panasas implementa diferentes formas de acesso aos arquivos, de acordo com seu tamanho. Finalmente, ao compararmos e analisarmos os padrões obtidos a partir dos testes com o IOR com o padrão de aplicações reais, podemos afirmar que, escolhendo de uma forma planejada o parâmetros usados no IOR, é possível não só reproduzir o padrão de acesso de aplicações reais, quanto é possível prever a performance para essas aplicações. 7.4 Trabalhos futuros Temos como primeira intenção, refinar a coleta de dados, a fim de diminuir a amortização dos resultados. Dessa forma esperamos coletar taxas mais próximas dos valores

118 7.4 Trabalhos futuros 117 instantâneos. Para isso, outras ferramentas de monitoramento de rede deverá ser usada, já que a escolhida, o Cacti, não oferece tal flexibilidade. Também é de interesse fazer uma análise de desempenho da rede Infiniband existente no cluster Netuno. Outro ponto levantado seria comparar o sistema de arquivos orientado a objetos PanFS com o NFS tradicional.

119 118 Referências ADAPTIVE COMPUTING. Moab TM HPC Suite Último acesso em Disponível em: < ADAPTIVE COMPUTING. TORQUE Open-Source Resource Manager Último acesso em Disponível em: < ALAM, S. R. et al. Cray XT4: an early evaluation for petascale scientific simulation. In: VERASTEGUI, B. (Ed.). Proceedings of the ACM/IEEE Conference on High Performance Networking and Computing, SC Reno, Nevada, USA: ACM Press, p. 39. ANSARI, K. M. et al. Implementing Cisco InfiniBand on IBM BladeCenter. [S.l.], Redpaper. BARKER, K. J. et al. Entering the petaflop era: The architecture and performance of roadrunner. In: Proceedings of the ACM/IEEE Conference on High Performance Networking and Computing, SC 08. Austin, TX: ACM/IEEE, BECKER, D. J. et al. Beowulf: A parallel workstation for scientific computation. Proceedings of the International Conference on Parallel Processing, BIARDZKI, C.; LUDWIG, T. Analyzing metadata performance in distributed file systems. In: MALYSHKIN, V. (Ed.). Parallel Computing Technologies. Heidelberg, Germany: Springer Berlin / Heidelberg, 2009, (Lecture Notes in Computer Science, v. 5698). p CALLAGHAN, B. NFS Illustrated. 1. ed. Reading, MA, USA: Addison-Wesley, CALLAGHAN, B.; PAWLOWSKI, B.; STAUBACH, P. RFC 1813: NFS Version 3 Protocol Specification. jun Acesso em Disponível em: < CARNS, P. H. et al. PVFS: A parallel file system for linux clusters. In: Proceedings of the 4th Annual Linux Showcase and Conference. Atlanta, GA: USENIX Association, p CORREA, J.; SILVA, G. P. Avaliação do sistema de arquivos paralelo do cluster Netuno. In: X Simpósio em Sistemas Computacionais - Workshop de Iniciação Científica (WSCAD-WIC). São Paulo, Brasil: [s.n.], p EISLER, M.; NETAPP. Internet Draft: Requirements for NFSv4.2. set Acesso em Disponível em: < requirements-00>.

120 Referências 119 FUJISAWA, K. et al. High performance grid and cluster computing for some optimization problems. In: Symposium on Aplications and the Internet-Workshops (SAINT Workshops). Tokyo, Japan: IEEE Computer Society, p GABRIEL, E. et al. Open MPI: Goals, concept, and design of a next generation MPI implementation. In: KRANZLMüLLER, D.; KACSUK, P.; DONGARRA, J. (Ed.). PVM/MPI - Recent Advances in Parallel Virtual Machine and Message Passing Interface. Budapest, Hungary: Springer, (Lecture Notes in Computer Science, v. 3241), p GALLI, D. L. Distributed Operating Systems. Upper Saddle River, NJ 07458, USA: Prentice-Hall, GARA, A. et al. Overview of the blue gene/l system architecture. IBM Journal of Research and Development, v. 49, p , mar GINTY, K.; TINDLE, J.; TINDLE, S. Cluster systems - an open access design solution. In: 20th International Conference on Systems Engineering: ICSE Coventry, UK: [s.n.], GRIDER, G. et al. Pascal - a new parallel and scalable server IO networking infrastructure for supporting global storage/file systems in large-size linux clusters. In: IPCCC. [S.l.]: IEEE, HERTEL, C. Implementing CIFS - The Common Internet File system. 1. ed. Upper Saddle River, NJ 07458, USA: Prentice-Hall, HUANG, W. et al. Design of high performance MVAPICH2: MPI2 over InfiniBand. In: Proc. Sixth IEEE International Symposium on Cluster Computing and the Grid (CCGRID). Singapore: IEEE Computer Society, p INTEL. Intel R MPI Library for Linux OS ed. [S.l.], Acesso em Disponível em: < INTEL. MPI Library from Intel Último acesso em Disponível em: < IOR HPC Benchmark Acesso em Disponível em: < IOZONE. IOzone Filesystem Benchmark Último acesso em Disponível em: < KERBYSON, D. J.; HOISIE, A. Performance modeling of the blue gene architecture. International Symposium on John Vincent Atanasoff Modern Computing, IEEE Computer Society, Los Alamitos, CA, USA, p , KIRCH, O. Why NFS sucks. In: Linux Symposium. Ottawa, Canada: [s.n.], KOMORNICKI, A.; Mullen-Schulz, G.; LANDON, D. Roadrunner: Harware and Software Overview. [S.l.], Redpaper.

121 Referências 120 KON, F. Distributed File Systems Past, Present and Future KUROSE, J. F.; ROSS, K. W. Computer Networking: A Top-Down Approach Featuring the Internet. 4. ed. [S.l.]: Addison Wesley, LAURIA, M.; BELL, K.; CHIEN, A. A high-performance cluster storage server. In: Proceedings of the Eleventh IEEE International Symposium on High Performance Distributed Computing. Edinburgh, Scotland: IEEE Computer Society Press, p LAYTON, J. B. Parallel platters: File systems for hpc clusters. Linux Magazine, nov LINUX NFS FAQ Última visita em Disponível em: < LLNL. IOR: I/O Performance Benchmark. [S.l.], Acesso em Disponível em: < LOS ALAMOS LAB. High-Performance Computing: Roadrunner Acesso em Disponível em: < LOS ALAMOS LAB. MPI-IO Test Acesso em Disponível em: < MARTIN, B. IOzone for filesystem performance benchmarking Último acesso em Disponível em: < MAURO, D. R.; SCHMIDT, K. J. Essential SNMP. 2. ed. [S.l.]: O Reilly, MICROSOFT CORPORATION. Common Internet File System (CIFS) Protocol Specification. [S.l.], NAGLE, D. et al. The ANSI T10 object-based storage standard and current implementations. IBM Journal of Research and Development, v. 52, n. 4-5, p , NAGLE, D.; SERENYI, D.; MATTHEWS, A. The Panasas ActiveScale Storage Cluster - Delivering Scalable High Bandwidth Storage. Fremont, CA, USA, OETIKER, T. About RRDTool Último acesso em Disponível em: < OHTA, K. et al. Scalable parallel i/o systems by client-side optimizations. In: International Workshop on Peta-Scale Computing Programming Environment, Languages and Tools (WPSE 2010). Kyoto, Japan: [s.n.], OLDFIELD R. A., K. T.; WIDENER, P. Data-movement approaches for hpc storage systems. In: GAVRILOVSKA, A. (Ed.). Attaining High Performance Communications: A Vertical Approach. 600 Broken Sound Parkway N.W., Suite 300, Boca Raton, FL , USA: CRC Press, cap. 14, p

122 Referências 121 OLKER, D. Local filesystem considerations: IOzone. In: Optimizing NFS performance: tuning and troubleshooting NFS on HP-UX systems. Upper Saddle River, NJ 07458, USA: Prentice-Hall, p OPENFABRICS ALLIANCE. OFED Overview Último acesso em Disponível em: < ORIANI, A. Uma Solução de Alta Disponibilidade para o Sistema de Arquivos Distribuído Hadoop. Dissertação (Mestrado) Unicamp, OU, L.; HE, X. B. Design and evaluation of a high performance parallel file system. In: Local Computer Networks (LCN). Sydney Australia: IEEE Computer Society, p PANASAS. Object-based Storage Architecture: Defining a New Generation of Storage Systems Built on Distributed, Intelligent Storage Devices. out White Paper, Panasas Inc. PANASAS High Performance Parallel Storage for Big Data Applications Última visita em Disponível em: < PENTAKALOS, O. I. An introduction to the infiniband architecture. In: Int. CMG Conference. [S.l.]: Computer Measurement Group, p PETERSON, L. L.; DAVIE, B. S. Computer networks: a systems approach. 4. ed. Los Altos, CA 94022, USA: Morgan Kaufmann Publishers, PETITET, A. et al. HPL - A Portable Implementation of the High-Performance Linpack Benchmark for Distributed-Memory Computers ed. [S.l.], set Disponível em: < PFISTER, G. F. An introduction to the infiniband architecture. In: JIN, H.; CORTES, T.; BUYYA, R. (Ed.). High Performance Mass Storage and Parallel I/O: Technologies and Applications. New York, USA: IEEE/Wiley Press, cap. 42. PLATFORM COMPUTING. Scali Manager R - Cluster Management and Monitoring System Último acesso em Disponível em: < RIEDEL, E. Object-based Storage (OSD) Architecture and Systems. abr SNIA Education. ROGUE WAVE. TotalView TM Dynamic source code and memory debugging for C, C++ and Fortran applications on UNIX, LINUX and MAC OS X Último acesso em Disponível em: < SEPEHRNOORI, K. et al. Parallel Simulation of Petroleum Reservoirs on High- Performance Clusters. Texas, Austin, USA, SHAN, H.; SHALF, J. Using IOR to analyze the I/O performance for HPC platforms. In: Cray Users Group Meeting (CUG) Seattle, Washington, USA: [s.n.], 2007.

123 Referências 122 SHAN, H.; SHALF, J.; ANTYPAS, K. Characterizing and predicting the I/O performance of HPC applications using a parameterized synthetic benchmark. In: SC 08 USB Key. Austin, TX, USA: ACM/IEEE, SHEPLER, S. et al. RFC 3010: NFS version 4 Protocol. dez Acesso em Disponível em: < SHEPLER, S. et al. RFC 3530: Network File System (NFS) version 4 Protocol. abr Acesso em Disponível em: < SHEPLER, S. et al. RFC 5661: Network File System (NFS) Version 4 Minor Version 1 Protocol. jan Acesso em Disponível em: < SILVA, G. P. et al. The experience in designing and building the high performance cluster netuno rd International Symposium on Computer Architecture and High Performance Computing, Ieee, Vitória, ES, Brasil, p , oct SILVA, V. et al. Arquitetura e avaliação do cluster de alto desempenho Netuno. In: WSCAD-SSC - X Simpósio em Sistemas Computacionais, em conjunto com o Simpósio Brasileiro de Arquiteturas Computacionais e Processamento de Alto Desempenho. São Paulo, Brasil: [s.n.], SPURGEON, C. E. Ethernet - the definitive guide: designing and managing local area networks. [S.l.]: O Reilly, STORAGE NETWORKING INDUSTRY ASSOCIATION. Common Internet File System (CIFS) Technical Reference ed. [S.l.], SUN MICROSYSTEMS INC. RFC 1094: NFS: Network File System Protocol Specification. mar Acesso em Disponível em: < TANENBAUM, A. S. Computer Networks. 4. ed. Upper Saddle River, NJ 07458, USA: Prentice-Hall International, TANENBAUM, A. S. Modern operating systems. 3. ed. Upper Saddle River, NJ 07458, USA: Prentice Hall, THAKUR, R. Parallel I/O Benchmarks Último acesso em Disponível em: < thakur/pio-benchmarks.html>. THE CACTI GROUP, INC. Cacti - The complete RRDTool-based graphing solution Último acesso em Disponível em: < THE CENTOS PROJECT. The Community Enterprise Operating System Último acesso em Disponível em: < URBAN, T. Cacti 0.8 Beginner s Guide. [S.l.]: Packt Publishing, Limited, WELCH, B. et al. Scalable Performance of the Panasas Parallel File System. In: FAST 08: Proceeding of the 6th USENIX Conference on File and Storage Technologies. Berkeley, CA, USA: [s.n.], p

124 Referências 123 WORLEY, P. H.; KUEHN, J. A.; BARRETT, R. F. Early evaluation of the cray XT5. In: Proceedings of the Cray Users Group Conference, CUG 09. Atlanta, Georgia, USA: [s.n.], p X/OPEN COMPANY LTD. X/Open CAE Specification. Protocols for X/Open PC Interworking: SMB, Version 2. [S.l.], YU, W.; VETTER, J. S. Xen-based HPC: A parallel I/O perspective. In: CCGRID. [S.l.]: IEEE Computer Society, p

125 124 APÊNDICE A -- Modelo de script de teste A.1 Script IOR #/ bin / bash # PBS -l nodes = node064 + node065 + node066 + node067 + node068 + node069 + node070 + node071 # PBS -l walltime =36:00:00 # PBS -j oe # PBS -q projetos # PBS - N IOR_ 8N1PPN_ BSIZE # PBS -V EXECDIR =/ home / projetos / ufrj / dcc / davivcgarcia WORKDIR =/ scratch / projetos / ufrj / dcc / davivcgarcia NUMITER =5 N=8 BSIZE =(1 G 2G 4G 8G) TSIZE =64 M cd $WORKDIR echo Current working directory is pwd echo " Node file : $PBS_ NODEFILE :" echo " " cat $PBS_ NODEFILE echo " " echo " Starting MPD... " mpdboot - r ssh - n $N -- files = $PBS_ NODEFILE for BS in ${ BSIZE [@ ]}; do echo " Starting N:1 run at date... " mpiexec - perhost 1 - n $N $EXECDIR / IOR. bin - a MPIIO - t $TSIZE - b $BS - i $NUMITER -o $WORKDIR /IOR1 - testfile. $PBS_JOBID -v

126 A.1 Script IOR 125 echo " Job finished at date... " echo " Starting N:N run at date... " mpiexec - perhost 1 - n $N $EXECDIR / IOR. bin - a MPIIO - t $TSIZE - b $BS - i $NUMITER -F -o $WORKDIR /IOR2 - testfile. $PBS_JOBID -v echo " Job finished at date... " done echo " Stopping MPD... " mpdallexit mpdcleanup

127 126 APÊNDICE B -- Mapa de conexões de rede do Netuno B.1 Switch Rack Equipamento Interface Interface Equipamento Obs. SwitchCore01 Ten1/1 Ten1/50 SwitchRack01 Po01 SwitchCore01 Ten2/1 Ten1/49 SwitchRack01 Po01 SwitchCore01 Ten1/2 Ten1/49 SwitchRack02 Po02 SwitchCore01 Ten2/2 Ten1/50 SwitchRack02 Po02 SwitchCore01 Ten1/3 Ten1/50 SwitchRack03 Po03 SwitchCore01 Ten2/3 Ten1/49 SwitchRack03 Po03 SwitchCore01 Ten1/4 Ten1/50 SwitchRack04 Po04 SwitchCore01 Ten2/4 Ten1/49 SwitchRack04 Po04 SwitchCore01 Ten3/1 Ten1/49 SwitchRack09 Po05 SwitchCore01 Ten4/1 Ten1/50 SwitchRack09 Po05 SwitchCore01 Ten3/2 Ten1/50 SwitchRack08 Po06 SwitchCore01 Ten4/2 Ten1/49 SwitchRack08 Po06 SwitchCore01 Ten3/3 Ten1/50 SwitchRack07 Po07 SwitchCore01 Ten4/3 Ten1/49 SwitchRack07 Po07 SwitchCore01 Ten3/4 Ten1/49 SwitchRack06 Po08 SwitchCore01 Ten4/4 Ten1/50 SwitchRack06 Po08 Tabela 15: Mapa de conexões dos Switch Racks Em verde estão as interfaces operacionais e em vermelho, as interfaces não operacionais. B.2 Panasas Em verde estão as interfaces operacionais e em vermelho, as interfaces não operacionais.

128 B.2 Panasas 127 Equipamento Interface Equipamento Obs. SwitchCore01 Gi7/25 Panasas Blade 01 Po101 SwitchCore01 Gi7/26 Panasas Blade 01 Po101 SwitchCore01 Gi7/27 Panasas Blade 01 Po101 SwitchCore01 Gi7/28 Panasas Blade 01 Po101 SwitchCore01 Gi7/29 Panasas Blade 02 Po102 SwitchCore01 Gi7/30 Panasas Blade 02 Po102 SwitchCore01 Gi7/31 Panasas Blade 02 Po102 SwitchCore01 Gi7/32 Panasas Blade 02 Po102 SwitchCore01 Gi7/33 Panasas Blade 03 Po103 SwitchCore01 Gi7/34 Panasas Blade 03 Po103 SwitchCore01 Gi7/35 Panasas Blade 03 Po103 SwitchCore01 Gi7/36 Panasas Blade 03 Po103 SwitchCore01 Gi7/09 Panasas Blade 04 Po104 SwitchCore01 Gi7/10 Panasas Blade 04 Po104 SwitchCore01 Gi7/11 Panasas Blade 04 Po104 SwitchCore01 Gi7/12 Panasas Blade 04 Po104 Tabela 16: Mapa de conexões das lâminas do Panasas

129 128 APÊNDICE C -- Gráficos do tráfego das interfaces durante a aplicação real monitorada C.1 Tráfego nas interfaces da rede de interconexão Figura 62: Interface Te1-1 Figura 63: Interface Te1-2 Figura 64: Interface Te1-3 Figura 65: Interface Te1-4

130 C.1 Tráfego nas interfaces da rede de interconexão 129 Figura 66: Interface Te2-1 Figura 67: Interface Te2-2 Figura 68: Interface Te2-3 Figura 69: Interface Te2-4 Figura 70: Interface Te3-1 Figura 71: Interface Te3-2 Figura 72: Interface Te3-3 Figura 73: Interface Te3-4