Análise do impacto da atualização e adoção de novas tecnologias de software no projeto GradPAD

Transcrição

1 Análise do impacto da atualização e adoção de novas tecnologias de software no projeto GradPAD André Leon S. Gradvohl Resumo Ao observar as recentes evoluções nos softwares usados na implementação de grades computacionais, percebeu-se a necessidade de uma discussão a respeito da atualização e possível adoção de novas versões desses softwares no projeto GradePAD. Desta forma, esse texto apresenta uma análise sobre o impacto que uma decisão a favor das mudanças pode causar no andamento do projeto e seus eventuais benefícios. 1 Introdução O objetivo do projeto GradPAD é implementar uma grade computacional integrando os diversos centros de processamento de alto desempenho integrantes do Sistema Nacional de Processamento de Alto Desempenho (SINAPAD). Uma vez implementada, essa grade computacional será uma ferramenta importante para a execução de programas que demandam um grande poder computacional. O texto a seguir apresenta uma análise da viabilidade de se atualizar e possivelmente adotar algumas novas tecnologias de software na implementação da grade computacional prevista pelo projeto GradePAD. São cinco os softwares considerados neste estudo, agrupados em quatro categorias: Globus 1, versão Sistema de filas Torque 2, versão Site de referência em 2 Site de referência em 1

2 Meta-escalonador Maui 3, versão 3.2. Portal GridSphere, versão e GridPortlets 4, versão 1.4. Cada uma dessas tecnologias tem um papel importante no sistema como um todo. Portanto, a inserção ou a adoção de novas versões desses programas pode causar impactos, principalmente nos prazos para a colocação do sistema em produção. Deste modo, para mostrar os impactos e riscos que essa decisão pode causar o texto está estruturado da seguinte forma: a Seção 2 detalha a arquitetura geral do sistema; a análise comparativa dos softwares é mostrada na Seção 3; e, por fim, a Seção 4 apresenta as conclusões do estudo. 2 Arquitetura do sistema Nesta seção será ilustrada a arquitetura geral do sistema GradePAD. Dessa forma, pode-se compreender melhor qual a função de cada software envolvido no projeto. Conforme se observa na Figura 1, o sistema possui três níveis: inferior, intermediário e superior, descritos a seguir. Figura 1: Arquitetura do sistema GradePAD. 3 Site de referência em 4 Site de referência em 2

3 O nível inferior é composto pelo sistema operacional e recursos computacionais, instalados em uma única unidade (e.g. uma máquina, ou conjunto de máquinas). Essas unidades podem, juntas, compor um cluster ou conjunto de clusters. O nível intermediário, nesse caso também chamado de front-end, é composto pelo sistema de filas, que despacha tarefas de processamento para as unidades do nível inferior, e um conjunto de serviços e bibliotecas (encapsulados no Globus) para segurança, monitoramento de recursos, comunicação, gerenciamento de dados e detecção de falhas, entre outros. A tarefa do front-end é gerenciar e fornecer um ponto único de acesso às unidades do nível inferior. O nível superior, abrange o portal e o meta-escalonador. O principal objetivo do portal é servir como um ponto único na world wide web (WWW) onde os usuários podem submeter suas tarefas para processamento nos diversos centros e coletar os resultados. Com isso, os usuários têm uma imagem única do sistema, sem perceber sua complexidade. O meta-escalonador será útil nessa tarefa, pois ele interage diretamente com os diversos sistemas de filas administrado-os e recolhendo várias informações úteis para a definição e implementação de políticas de uso. Originalmente, a presença do meta-escalonador não está definida no projeto original do Grade- PAD. No entanto, a inclusão desse software no sistema geral se faz necessária para a simplificação das tarefas administrativas e a melhoria do serviço prestado pelo sistema. 3 Análise dos softwares envolvidos no projeto De acordo com o que foi proposto no projeto inicial, dois softwares foram escolhidos como peças fundamentais no GradePAD: o Globus, versão 3.2, e o Sun Grid Engine, versão 6.0, como sistema de filas. No ponto atual do projeto verificou-se que talvez seja pertinente uma atualização do Globus, uma reavaliação do sistema de filas escolhido, a adição de um meta-escalonador e a alteração do software para o portal. A seção a seguir mostra um quadro comparativo entre as versões do Globus para fundamentar uma eventual decisão de mudança de versão. 3

4 3.1 Análise comparativa das versões do Globus A grande diferença da versão 3 do Globus (GT3) para a versão 4 (GT4) é o foco em um conceito chamado Web Services[2], descrito posteriormente na página 7. A mudança do OGSA (Open Grid Services Architecture) para o chamado WSRF (Web Services Resource Framework) é uma mudança significativa de paradigma, apesar desse conceito estar presente de forma superficial no GT3. Porém, no GT4, há uma maior preocupação na utilização de Web Services para a descoberta, descrição e invocação dos serviços prestados pela infra-estrutura computacional que implementa o Globus. Por isso a mudança para o WSRF. elas: Há ainda outros itens, descritos em [3], que apontam outras características em favor do GT4. São a documentação do GT4 é bem mais completa e precisa do que o GT3; a compilação e instalação do GT4 é menos propensa a erros; há necessidade de conversão das interfaces dos serviços em uma eventual migração entre versões, mas não é preciso muita alteração na implementação dos serviços; o desempenho, a estabilidade e a robustez dos serviços GT4 é superior aos do GT3. Além dos itens enumerados, verificou-se que na versão do Globus, considerada neste texto, há ainda a possibilidade de se compilar o software com a opção de integração com alguns sistemas de filas, e.g. PBS 5, LSF 6 ou Condor 7. Essa é uma grande vantagem em relação à GT3, pois permite uma maior integração entre os componentes do sistema. Outro detalhe que convém ressaltar é a compatibilidade do GT4 com a versão 1.6 do Java. O GT3 possuía compatibilidade apenas com o Java 1.4 o que poderia significar um retrocesso na implementação do conceito de Web services. A versão 1.6 do Java, além de ser mais robusta, traz uma série de novas estruturas de programação que torna mais rápido e seguro o desenvolvimento de serviços. 5 Portable Batch System, um sistema de filas proprietário, cuja versão aberta chama-se Torque. 6 Load Sharing Facility 7 Condor é algo mais que um sistema de filas. Na verdade, esse software provê escalonamento de tarefas, políticas de escalonamento, esquema de prioridades, monitoramento e gerenciamento de recursos 4

5 Na questão da segurança, um detalhe importante é que o GT4 é a primeira versão a incluir o MyProxy, um repositório on-line de credenciais. Esse software elimina a necessidade de cópia de arquivos de chave e certificados entre máquinas manualmente pelo usuário. É possível também usar o MyProxy para autenticação de portais e renovação de credenciais pelos sistemas de filas. Além do Globus, outro item que precisa ser analisado é o sistema de filas. A seção seguinte mostra as comparações entre o software atual e o proposto. 3.2 Comparação entre os sistemas de filas O sistema de filas é o software responsável pelo gerenciamento das tarefas que serão submetidas para processamento. O sistema de filas escolhido inicialmente no projeto é o Sun Grid Engine (SGE), versão 6.0. Apesar de ser um bom sistema de filas, não há compatibilidade direta desse software com o GT4 ou com qualquer outro meta-escalonador. Isso significa que, para obter a compatibilidade esperada, é preciso baixar de alguns sites alguns patches que façam a integração. Em relação ao portal, o SGE é compatível diretamente apenas com o SunONE Portal Server, uma ferramenta proprietária da SUN Microsystems para criação de portais. Deve-se considerar também que não houve muitas mudanças de versões desde a escolha do SGE, versão 6.0, a não ser para correção de bugs. Por um lado isso é bom, porque assim garante-se que não há discrepâncias entre as versões instaladas nos centros. Por outro, isso pode indicar que há pouca manutenção para o SGE 6.0. Deste modo, a escolha do SGE implica em um acréscimo de complexidade na instalação do sistema de filas e na integração com os demais componentes do sistema. O sistema de filas Torque, por sua vez, é baseado no PBS. Por ser um software livre, a comunidade de usuários que o mantém e colabora para seu aperfeiçoamento é bem maior que o SGE. Além disso, o PBS é compatível diretamente com o GT4 e com o software para a implementação portal, o qual será discutido posteriormente na Seção

6 3.3 Adoção de um meta-escalonador Um meta-escalonador é um software responsável por definir quando e onde certas tarefas de processamento (jobs) serão executados. Para tanto, são usados três conjuntos de dados: informação de job, informação de recursos e políticas de escalonamento. O escalonador é fundamental para a otimização dos recursos computacionais e balanceamento de carga entre as unidades de processamento. É importante ressaltar a diferença entre um sistema de filas e um meta-escalonador. O primeiro gerencia a fila de jobs e os nós de processamento. O segundo informa o que o sistema de filas deve fazer, quando e onde deve executar os jobs. Por causa desse controle, meta-escalonador pode fornecer mais informações para gerenciamento e, se bem configurado, pode até tomar decisões mais inteligentes facilitando o balanceamento de carga entre as unidades de processamento. Para o projeto GradPAD não havia sido definido nenhum meta-escalonador. As informações eram simplesmente coletadas e apresentadas no portal, deixando as decisões sobre a submissão de jobs a cargo do usuário. Assim, o meta-escalonador sugerido para o projeto é o Maui cujas características são as seguintes: pode ser utilizado em conjunto com os sistemas de gerenciamento de filas tais como Torque (PBS) e SGE. é baseado no conceito de reserva de recursos; atribuição de prioridades baseada em características do job (tamanho, tempo de processamento, usuário ou grupo de usuários donos do job, entre outros); jobs que estão no começo da fila, mas que não podem começar imediatamente por causa da falta de recursos, têm garantidas as reservas; prioriza as filas com conceitos como utilização justa, tamanho do job, número de nós necessários e tempo na fila, entre outros. No artigo [1], há um breve estudo sobre as vantagens de uma integração do Maui com o PBS, que pode justificar a escolha dessa combinação. 6

7 3.4 Análise para adoção de ferramentas para a construção do portal O portal, implementado na WWW, é a interface dos vários usuários com todo o sistema. Entre esses usuários estão, por exemplo, os pesquisadores que utilizarão a grade e os administradores do sistema. Cada grupo de usuários tem uma visão diferente do sistema, por isso é importante que o portal implemente perfis diferentes para cada grupo. No caso do portal do projeto GradePAD, para por em prática as funcionalidades requeridas é importante que alguns conceitos sejam considerados na escolha do software escolhido, e.g. web services, servlets e portlets[4]. Os web services são aplicações para a WWW modulares, distribuídas, dinâmicas, baseadas em padrões abertos (XML, SOAP, HTTP) e que são descritas, publicadas, localizadas e invocadas pela Internet. Por ser baseados nos padrões abertos, os web services fornecem grande interoperabilidade entre várias aplicações. Os servlets são programas modulares em Java para desempenhar uma função específica e criar uma saída em HTML (HyperText Markup Language). Por fim, os portlets são servlets especiais que produzem fragmentos de HTML que podem ser agregados dinamicamente em uma página do portal. Há dois padrões de portlets: Java Specification Request (JSR) 168, lançado em outubro de 2003 e o JSR 286, sem previsão para a versão final. A aderência aos padrões é necessária para garantir a portabilidade com aplicações futuras. A combinação desses três conceitos facilita a criação de portais dinâmicos, mais interativos e mais personalizados, tornando a interface com o sistema mais amigável. Atualmente, o projeto GradePAD é baseado no GridPort toolkit 8, cuja última versão (4.0.1) é de dezembro de Esse software é uma coleção de portlets que provêem as seguintes funcionalidades: submissão de jobs com Globus Resource Allocation Manager (GRAM) ou com Condor; manipulação de arquivos e diretórios (cópia, remoção, renomeação, upload e download); visualização de conteúdo de arquivos. No entanto, sugere-se uma mudança de software em favor da combinação dos softwares Grid- Sphere e GridPortlets. O primeiro, na versão 3.0.7, é um software para criação de portais, baseado no 8 Site de referência em 7

8 servidor WWW Apache e no servidor de aplicações Tomcat. O GridPortlets, por sua vez, fornece um conjunto de portlets para utilização dos serviços de grade computacional. Por serem desenvolvidos conjuntamente, a combinação desses programas pode fornecer uma solução completa para o portal. Entre as funcionalidades do GridSphere estão portlets para login, logout, personalização de perfis e de layout, criação de usuários e grupos, além de ser compatível com a JSR 168. Em relação ao GridPortlets, a versão 1.4 já é compatível com o GT4 e provê as seguintes funcionalidades: submissão de jobs com Globus Resource Allocation Manager (GRAM) e compatibilidade com PBS, LSF e Condor; gerenciamento de jobs; gerenciamento de arquivos com GridFTP e GASS (Globus Access to Secondary Storage); gerenciamento de credenciais com o MyProxy; Além dessas funcionalidades, os softwares GridSphere e GridPortlets são abertos à comunidade e muito bem documentados o que facilita a sua adoção, implementação e manutenção. 4 Conclusão A atualização de um sistema que ainda não foi colocado em produção em geral é benéfica, pois incorpora as últimas correções e adiciona novas funcionalidades. No entanto, deve-se considerar o quanto esse processo atrasará o início do funcionamento do sistema. O ideal é que, mesmo adiando o início das atividades, a atualização ainda esteja dentro da previsão do cronograma. Com base em alguns testes feitos no âmbito do CENAPAD-SP e considerando o conhecimento prévio obtido no decorrer da execução do projeto GradePAD, prevê-se o cronograma apresentado na Tabela 1 a seguir para a instalação dos softwares listados neste texto. Portanto, considerando cerca de uma semana, em média, para a instalação, configuração e testes de integração de cada um dos softwares sugeridos, prevê-se um mês para atualização completa do sistema GradePAD. Deve-se observar, no entanto, que nem todos os centros devem instalar todos 8

9 Software Sistema de Filas (Torque) Globus Meta-escalonador (Maui) Portal (GridSphere + GridPortlets) Semanas 1a. 2a. 3a. 4a. x x x x Tabela 1: Cronograma de instalação dos softwares sugeridos. os sistemas. Os softwares do meta-escalonador e do portal somente serão instalados no centro que hospedará o portal. Assim, boa parte do sistema estará apto para testes finais entre 15 e 20 dias, após o início dos trabalhos. Apesar de ser um tempo razoavelmente grande, ao se atualizar e adotar os softwares sugeridos, espera-se os seguintes ganhos: ter as últimas correções de falhas já implementadas; facilidade de manutenção; melhor documentação; maior estabilidade do sistema; Portanto, conclui-se que as adoções e atualizações sugeridas são bem-vindas e que o impacto dessa decisão será minimizado a curto prazo. Referências [1] Brett Bode, David M. Halstead, Ricky Kendall, and Zhou Lei. The portable batch scheduler and the maui scheduler on linux clusters. In Proceedings of the 4th Annual Linux Showcase and Conference, [2] Ian Foster. Globus toolkit 4: Software for service-oriented systems. IFIP International Conference on Network and Parallel Computing, 21(4):2 13, Maio [3] Terry Harmer, Anthony Stell, and David McBride. Globus toolkit version 4 middleware evaluation. Relatório Técnico 1.0, UK Engineering Task Force, Julho [4] Anurag Shankar. A general (gentle?) introduction to (grid) portals/gateways. Relatório Técnico, TeraGrid Gateways Team, Indiana University, Novembro