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

tecnologias de software no projeto GradPAD

Andr´e Leon S. Gradvohl

Resumo

Ao observar as recentes evoluc¸˜oes nos softwares usados na implementac¸˜ao de grades compu-tacionais, percebeu-se a necessidade de uma discuss˜ao a respeito da atualizac¸˜ao e poss´ıvel adoc¸˜ao de novas vers˜oes desses softwares no projeto GradePAD. Desta forma, esse texto apresenta uma an´alise sobre o impacto que uma decis˜ao a favor das mudanc¸as pode causar no andamento do projeto e seus eventuais benef´ıcios.

1 Introduc¸˜ao

O objetivo do projeto GradPAD ´e 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´a uma ferra-menta importante para a execuc¸˜ao de programas que demandam um grande poder computacional.

O texto a seguir apresenta uma an´alise da viabilidade de se atualizar e possivelmente adotar algu-mas novas tecnologias de software na implementac¸˜ao da grade computacional prevista pelo projeto GradePAD. S˜ao cinco os softwares considerados neste estudo, agrupados em quatro categorias:

• Globus1_{, vers˜ao 4.0.4.}

• Sistema de filas Torque2_{, vers˜ao 2.18.}

1_{Site de referˆencia em http://www.globus.org.}

• Meta-escalonador Maui3_{, vers˜ao 3.2.}

• Portal GridSphere, vers˜ao 3.0.7 e GridPortlets4_{, vers˜ao 1.4.}

Cada uma dessas tecnologias tem um papel importante no sistema como um todo. Portanto, a inserc¸˜ao ou a adoc¸˜ao de novas vers˜oes desses programas pode causar impactos, principalmente nos prazos para a colocac¸˜ao do sistema em produc¸˜ao.

Deste modo, para mostrar os impactos e riscos que essa decis˜ao pode causar o texto est´a estrutu-rado da seguinte forma: a Sec¸˜ao 2 detalha a arquitetura geral do sistema; a an´alise comparativa dos softwares ´e mostrada na Sec¸˜ao 3; e, por fim, a Sec¸˜ao 4 apresenta as conclus˜oes do estudo.

2 Arquitetura do sistema

Nesta sec¸˜ao ser´a ilustrada a arquitetura geral do sistema GradePAD. Dessa forma, pode-se com-preender melhor qual a func¸˜ao de cada software envolvido no projeto. Conforme se observa na Figura 1, o sistema possui trˆes n´ıveis: inferior, intermedi´ario e superior, descritos a seguir.

uma ´unica unidade (e.g. uma m´aquina, ou conjunto de m´aquinas). Essas unidades podem, juntas, compor um cluster ou conjunto de clusters.

O n´ıvel intermedi´ario, nesse caso tamb´em chamado de front-end, ´e composto pelo sistema de filas, que despacha tarefas de processamento para as unidades do n´ıvel inferior, e um conjunto de servic¸os e bibliotecas (encapsulados no Globus) para seguranc¸a, monitoramento de recursos, comunicac¸˜ao, gerenciamento de dados e detecc¸˜ao de falhas, entre outros. A tarefa do front-end ´e gerenciar e fornecer um ponto ´unico de acesso `as unidades do n´ıvel inferior.

O n´ıvel superior, abrange o portal e o meta-escalonador. O principal objetivo do portal ´e servir como um ponto ´unico na world wide web (WWW) onde os usu´arios podem submeter suas tarefas para processamento nos diversos centros e coletar os resultados. Com isso, os usu´arios tˆem uma imagem ´unica do sistema, sem perceber sua complexidade. O meta-escalonador ser´a ´util nessa tarefa, pois ele interage diretamente com os diversos sistemas de filas administrado-os e recolhendo v´arias informac¸˜oes ´uteis para a definic¸˜ao e implementac¸˜ao de pol´ıticas de uso.

Originalmente, a presenc¸a do meta-escalonador n˜ao est´a definida no projeto original do Grade-PAD. No entanto, a inclus˜ao desse software no sistema geral se faz necess´aria para a simplificac¸˜ao das tarefas administrativas e a melhoria do servic¸o prestado pelo sistema.

3 An´alise dos softwares envolvidos no projeto

De acordo com o que foi proposto no projeto inicial, dois softwares foram escolhidos como pec¸as fundamentais no GradePAD: o Globus, vers˜ao 3.2, e o Sun Grid Engine, vers˜ao 6.0, como sistema de filas. No ponto atual do projeto verificou-se que talvez seja pertinente uma atualizac¸˜ao do Globus, uma reavaliac¸˜ao do sistema de filas escolhido, a adic¸˜ao de um meta-escalonador e a alterac¸˜ao do software para o portal.

A sec¸˜ao a seguir mostra um quadro comparativo entre as vers˜oes do Globus para fundamentar uma eventual decis˜ao de mudanc¸a de vers˜ao.

3.1 An´alise comparativa das vers˜oes do Globus

A grande diferenc¸a da vers˜ao 3 do Globus (GT3) para a vers˜ao 4 (GT4) ´e o foco em um conceito chamado Web Services[2], descrito posteriormente na p´agina 7. A mudanc¸a do OGSA (Open Grid

Services Architecture) para o chamado WSRF (Web Services Resource Framework) ´e uma mudanc¸a

significativa de paradigma, apesar desse conceito estar presente de forma superficial no GT3. Por´em, no GT4, h´a uma maior preocupac¸˜ao na utilizac¸˜ao de Web Services para a descoberta, descric¸˜ao e invocac¸˜ao dos servic¸os prestados pela infra-estrutura computacional que implementa o Globus. Por isso a mudanc¸a para o WSRF.

H´a ainda outros itens, descritos em [3], que apontam outras caracter´ısticas em favor do GT4. S˜ao elas:

• a documentac¸˜ao do GT4 ´e bem mais completa e precisa do que o GT3;

• a compilac¸˜ao e instalac¸˜ao do GT4 ´e menos propensa a erros;

• h´a necessidade de convers˜ao das interfaces dos servic¸os em uma eventual migrac¸˜ao entre vers˜oes, mas n˜ao ´e preciso muita alterac¸˜ao na implementac¸˜ao dos servic¸os;

• o desempenho, a estabilidade e a robustez dos servic¸os GT4 ´e superior aos do GT3.

Al´em dos itens enumerados, verificou-se que na vers˜ao 4.0.4 do Globus, considerada neste texto, h´a ainda a possibilidade de se compilar o software com a opc¸˜ao de integrac¸˜ao com alguns sistemas de filas, e.g. PBS5_{, LSF}6_{ou Condor}7_{. Essa ´e uma grande vantagem em relac¸˜ao `a GT3, pois permite}

uma maior integrac¸˜ao entre os componentes do sistema.

Outro detalhe que conv´em ressaltar ´e a compatibilidade do GT4 com a vers˜ao 1.6 do Java. O GT3 possu´ıa compatibilidade apenas com o Java 1.4 o que poderia significar um retrocesso na implementac¸˜ao do conceito de Web services. A vers˜ao 1.6 do Java, al´em de ser mais robusta, traz uma s´erie de novas estruturas de programac¸˜ao que torna mais r´apido e seguro o desenvolvimento de servic¸os.

MyProxy, um reposit´orio on-line de credenciais. Esse software elimina a necessidade de c´opia de arquivos de chave e certificados entre m´aquinas manualmente pelo usu´ario. ´E poss´ıvel tamb´em usar o MyProxy para autenticac¸˜ao de portais e renovac¸˜ao de credenciais pelos sistemas de filas.

Al´em do Globus, outro item que precisa ser analisado ´e o sistema de filas. A sec¸˜ao seguinte mostra as comparac¸˜oes entre o software atual e o proposto.

3.2 Comparac¸˜ao entre os sistemas de filas

O sistema de filas ´e o software respons´avel pelo gerenciamento das tarefas que ser˜ao submetidas para processamento. O sistema de filas escolhido inicialmente no projeto ´e o Sun Grid Engine (SGE), vers˜ao 6.0.

Apesar de ser um bom sistema de filas, n˜ao h´a compatibilidade direta desse software com o GT4 ou com qualquer outro meta-escalonador. Isso significa que, para obter a compatibilidade esperada, ´e preciso baixar de alguns sites alguns patches que fac¸am a integrac¸˜ao. Em relac¸˜ao ao portal, o SGE ´e compat´ıvel diretamente apenas com o SunONE Portal Server, uma ferramenta propriet´aria da SUN Microsystems para criac¸˜ao de portais.

Deve-se considerar tamb´em que n˜ao houve muitas mudanc¸as de vers˜oes desde a escolha do SGE, vers˜ao 6.0, a n˜ao ser para correc¸˜ao de bugs. Por um lado isso ´e bom, porque assim garante-se que n˜ao h´a discrepˆancias entre as vers˜oes instaladas nos centros. Por outro, isso pode indicar que h´a pouca manutenc¸˜ao para o SGE 6.0.

Deste modo, a escolha do SGE implica em um acr´escimo de complexidade na instalac¸˜ao do sistema de filas e na integrac¸˜ao com os demais componentes do sistema.

O sistema de filas Torque, por sua vez, ´e baseado no PBS. Por ser um software livre, a comunidade de usu´arios que o mant´em e colabora para seu aperfeic¸oamento ´e bem maior que o SGE. Al´em disso, o PBS ´e compat´ıvel diretamente com o GT4 e com o software para a implementac¸˜ao portal, o qual ser´a discutido posteriormente na Sec¸˜ao 3.4.

3.3 Adoc¸˜ao de um meta-escalonador

Um meta-escalonador ´e um software respons´avel por definir quando e onde certas tarefas de pro-cessamento (jobs) ser˜ao executados. Para tanto, s˜ao usados trˆes conjuntos de dados: informac¸˜ao de job, informac¸˜ao de recursos e pol´ıticas de escalonamento. O escalonador ´e fundamental para a otimizac¸˜ao dos recursos computacionais e balanceamento de carga entre as unidades de processa-mento.

´E importante ressaltar a diferenc¸a entre um sistema de filas e um meta-escalonador. O primeiro gerencia a fila de jobs e os n´os 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 informac¸˜oes para gerenciamento e, se bem configurado, pode at´e tomar decis˜oes mais “inteligentes” facilitando o balanceamento de carga entre as unidades de processamento.

Para o projeto GradPAD n˜ao havia sido definido nenhum meta-escalonador. As informac¸˜oes eram simplesmente coletadas e apresentadas no portal, deixando as decis˜oes sobre a submiss˜ao de jobs a cargo do usu´ario.

Assim, o meta-escalonador sugerido para o projeto ´e o Maui cujas caracter´ısticas s˜ao as seguintes:

• pode ser utilizado em conjunto com os sistemas de gerenciamento de filas tais como Torque (PBS) e SGE.

• ´e baseado no conceito de reserva de recursos;

• atribuic¸˜ao de prioridades baseada em caracter´ısticas do job (tamanho, tempo de processamento, usu´ario ou grupo de usu´arios donos do job, entre outros);

• jobs que est˜ao no comec¸o da fila, mas que n˜ao podem comec¸ar imediatamente por causa da

falta de recursos, tˆem garantidas as reservas;

• prioriza as filas com conceitos como utilizac¸˜ao justa, tamanho do job, n´umero de n´os ne-cess´arios e tempo na fila, entre outros.

O portal, implementado na WWW, ´e a interface dos v´arios usu´arios com todo o sistema. Entre esses usu´arios est˜ao, por exemplo, os pesquisadores que utilizar˜ao a grade e os administradores do sistema. Cada grupo de usu´arios tem uma vis˜ao diferente do sistema, por isso ´e importante que o portal implemente perfis diferentes para cada grupo.

No caso do portal do projeto GradePAD, para por em pr´atica as funcionalidades requeridas ´e importante que alguns conceitos sejam considerados na escolha do software escolhido, e.g. web

services, servlets e portlets[4].

Os web services s˜ao aplicac¸˜oes para a WWW modulares, distribu´ıdas, dinˆamicas, baseadas em padr˜oes abertos (XML, SOAP, HTTP) e que s˜ao descritas, publicadas, localizadas e invocadas pela Internet. Por ser baseados nos padr˜oes abertos, os web services fornecem grande interoperabilidade entre v´arias aplicac¸˜oes.

Os servlets s˜ao programas modulares em Java para desempenhar uma func¸˜ao espec´ıfica e criar uma sa´ıda em HTML (HyperText Markup Language). Por fim, os portlets s˜ao servlets especiais que produzem fragmentos de HTML que podem ser agregados dinamicamente em uma p´agina do portal. H´a dois padr˜oes de portlets: Java Specification Request (JSR) 168, lanc¸ado em outubro de 2003 e o JSR 286, sem previs˜ao para a vers˜ao final. A aderˆencia aos padr˜oes ´e necess´aria para garantir a portabilidade com aplicac¸˜oes futuras.

A combinac¸˜ao desses trˆes conceitos facilita a criac¸˜ao de portais dinˆamicos, mais interativos e mais personalizados, tornando a interface com o sistema mais amig´avel. Atualmente, o projeto GradePAD ´e baseado no GridPort toolkit8_{, cuja ´ultima vers˜ao (4.0.1) ´e de dezembro de 2006. Esse software ´e}

uma colec¸˜ao de portlets que provˆeem as seguintes funcionalidades:

• submiss˜ao de jobs com Globus Resource Allocation Manager (GRAM) ou com Condor;

• manipulac¸˜ao de arquivos e diret´orios (c´opia, remoc¸˜ao, renomeac¸˜ao, upload e download);

• visualizac¸˜ao de conte´udo de arquivos.

No entanto, sugere-se uma mudanc¸a de software em favor da combinac¸˜ao dos softwares Grid-Sphere e GridPortlets. O primeiro, na vers˜ao 3.0.7, ´e um software para criac¸˜ao de portais, baseado no

servidor WWW Apache e no servidor de aplicac¸˜oes Tomcat. O GridPortlets, por sua vez, fornece um conjunto de portlets para utilizac¸˜ao dos servic¸os de grade computacional. Por serem desenvolvidos conjuntamente, a combinac¸˜ao desses programas pode fornecer uma soluc¸˜ao completa para o portal.

Entre as funcionalidades do GridSphere est˜ao portlets para login, logout, personalizac¸˜ao de perfis e de layout, criac¸˜ao de usu´arios e grupos, al´em de ser compat´ıvel com a JSR 168.

Em relac¸˜ao ao GridPortlets, a vers˜ao 1.4 j´a ´e compat´ıvel com o GT4 e provˆe as seguintes funcio-nalidades:

• submiss˜ao 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´em dessas funcionalidades, os softwares GridSphere e GridPortlets s˜ao abertos `a comunidade e muito bem documentados o que facilita a sua adoc¸˜ao, implementac¸˜ao e manutenc¸˜ao.

4 Conclus˜ao

A atualizac¸˜ao de um sistema que ainda n˜ao foi colocado em produc¸˜ao em geral ´e ben´efica, pois incorpora as ´ultimas correc¸˜oes e adiciona novas funcionalidades. No entanto, deve-se considerar o quanto esse processo atrasar´a o in´ıcio do funcionamento do sistema. O ideal ´e que, mesmo adiando o in´ıcio das atividades, a atualizac¸˜ao ainda esteja dentro da previs˜ao do cronograma.

Com base em alguns testes feitos no ˆambito do CENAPAD-SP e considerando o conhecimento pr´evio obtido no decorrer da execuc¸˜ao do projeto GradePAD, prevˆe-se o cronograma apresentado na Tabela 1 a seguir para a instalac¸˜ao dos softwares listados neste texto.

1a. 2a. 3a. 4a. Sistema de Filas (Torque) x

Globus x

Meta-escalonador (Maui) x

Portal (GridSphere + GridPortlets) x

Tabela 1: Cronograma de instalac¸˜ao dos softwares sugeridos.

os sistemas. Os softwares do meta-escalonador e do portal somente ser˜ao instalados no centro que hospedar´a o portal. Assim, boa parte do sistema estar´a apto para testes finais entre 15 e 20 dias, ap´os 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 ´ultimas correc¸˜oes de falhas j´a implementadas; facilidade de manutenc¸˜ao; melhor documentac¸˜ao; maior estabilidade do sistema;

Portanto, conclui-se que as adoc¸˜oes e atualizac¸˜oes sugeridas s˜ao bem-vindas e que o impacto dessa decis˜ao ser´a minimizado a curto prazo.

Referˆencias

[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, 2000.

[2] Ian Foster. Globus toolkit 4: Software for service-oriented systems. IFIP International

Confe-rence on Network and Parallel Computing, 21(4):2–13, Maio 2006.

[3] Terry Harmer, Anthony Stell, and David McBride. Globus toolkit version 4 middleware evalua-tion. Relat´orio T´ecnico 1.0, UK Engineering Task Force, Julho 2005.

[4] Anurag Shankar. A general (gentle?) introduction to (grid) portals/gateways. Relat´orio T´ecnico, TeraGrid Gateways Team, Indiana University, Novembro 2006.