Arquitetura do Ambiente de Processamento do OncoGrid

Vamos descrever o funcionamento da arquitetura detalhando os componentes respon- s´aveis pelos processos de execu¸c˜ao de tarefas computacionais e apresentando os m´etodos

4.2 Proposta do Ambiente de Processamento Distribu´ıdo em Grade Aplicado ao OncoGrid 65

de distribui¸c˜ao de processos computacionais previstos.

Para suprir as necessidades requisitadas para o ambiente, devemos assumir que o ambiente possua as seguintes caracter´ısticas e componentes:

• Escalonamento e Distribui¸c˜ao: O escalonamento de tarefas poder´a ser realizado em dois n´ıveis: meta-escalonamento, que ´e a distribui¸c˜ao de tarefas em ambiente global e escalonamento local, que ´e a distribui¸c˜ao das tarefas internamente dentro das institui¸c˜oes participantes. Para a distribui¸c˜ao de tarefas globais ser´a utilizada a ferramenta GridWay. O escalonamento de tarefas nas redes locais das institui- ¸c˜oes participantes, pode ser realizado utilizando o pr´oprio gerenciador de tarefas dos sistemas operacionais das extra¸c˜oes, ou gerenciadores de aglomerados de com- putadores que possuem compatibilidade com ambientes baseados no Globus, como o Torque-PBS por exemplo;

• Submiss˜ao de Tarefas: A ferramenta GRAM fica respons´avel pelo gerenciamento das tarefas nos recursos de processamento, sendo a principal interface do meta- escalonador com os recursos. Todos os comandos direcionados aos processos com- putacionais executados nas esta¸c˜oes s˜ao enviados por meio deste componente; • Bibliotecas de Programa¸c˜ao: o ambiente deve possuir suporte a bibliotecas para

programa¸c˜ao paralela, como o MPICH-G2, que ´e a implementa¸c˜ao da especifica¸c˜ao da biblioteca MPI com suporte ao sistema de seguran¸ca empregado no Globus. As m´aquinas que participam do ambiente devem estar equipadas com o ambiente de execu¸c˜ao do JAVA o JRE (Java Runtime Environment), devido ao fato de ser uma plataforma de desenvolvimento utilizada para implementa¸c˜ao de sistema distribu´ıdo; • Localiza¸c˜ao de Recursos: O ambiente deve possuir um sistema de informa¸c˜oes que disponibilize os dados sobre o estado e localiza¸c˜ao de recursos e servi¸cos para o meta-escalonador. Optamos por empregar o MDS provido pelo Globus. Para com- plementar as suas funcionalidades, estabelecemos que o monitoramento das esta¸c˜oes ser´a realizado de forma dinˆamica, empregando componentes de monitoramento nos recursos que disponibilizar˜ao as informa¸c˜oes do estado das esta¸c˜oes da grade em tempo real. Para realizar esta fun¸c˜ao, empregamos o monitor Ganglia;

• Acesso a Dados: As opera¸c˜oes que realizam movimenta¸c˜ao de dados devem utilizar as ferramentas padr˜ao empregadas no Globus (GridFTP, OGSA-DAI). Adicional- mente a estas se faz necess´ario o emprego do sistema para transferˆencia de dados

confi´avel RFT, por ser requisitado nas fun¸c˜oes de gerenciamento de processos reali- zadas pelo GRAM.

Mediante as funcionalidades apresentadas, nos cabe esclarecer o motivo para a ado¸c˜ao das ferramentas para gerenciamento de execu¸c˜ao e de meta-escalonamento GridWay e Torque-PBS.

O Torque-PBS ´e uma vers˜ao do Portable Batch System. Esta ferramenta adere ao sistema proposto porque apresenta facilidades de gerenciamento e possui compatibilidade com o GRAM.

O GridWay ´e uma ferramenta desenvolvida pela Globus Aliance que ´e o mesmo con- s´orcio que desenvolve o Globus, assim possuindo forte integra¸c˜ao com os ambientes nela baseados. Outro fato favor´avel a esta ado¸c˜ao ´e a possibilidade de utilizar aplica¸c˜oes desen- volvidos em JAVA. Por ser uma ferramenta desenvolvida especialmente para o ambiente de grade computacional, apresenta pol´ıticas de escalonamento melhor adaptadas para este tipo de ambiente, quando relacionadas `as pol´ıticas utilizadas pelos escalonadores adapta- dos de ambientes de aglomerados de computadores para grades computacionais, como ´e o caso do Condor-G.

Existe a perspectiva da utiliza¸c˜ao de ferramentas como o Condor que permite explorar os recursos computacionais que se encontram ociosos nas organiza¸c˜oes que participam do OncoGrid de forma oportunista. Esta atividade ´e vista por muitas institui¸c˜oes como um fator negativo, por ser um modelo de computa¸c˜ao distribu´ıda extremamente pervasivo.

Para esclarecer a distribui¸c˜ao dos componente do ambiente de processamento aborda- mos a arquitetura OncoGrid novamente sob o modelo de camadas funcionais. Na figura 4.3 apresentamos a arquitetura do projeto OncoGrid, agora contemplando adicionalmente os componentes utilizados para o estabelecimento do ambiente de processamento distri- bu´ıdo. Os componentes que participam do processamento distribu´ıdo est˜ao destacados na cor cinza.

A disposi¸c˜ao das camadas indica a organiza¸c˜ao funcional, mas n˜ao implica que uma determinada camada somente se comunique com a imediatamente superior ou inferior, por exemplo; uma esta¸c˜ao de trabalho conectada ao ambiente pode submeter uma tarefa para processamento, assim acessando as camadas de seguran¸ca, acesso do usu´ario, servi¸cos de grade e de recursos.

Os blocos dispostos nas camadas indicam os componentes do ambiente. Na figura 4.3 ´e apresentado apenas um componente de cada, por´em estes podemos possuir N r´eplicas.

4.2 Proposta do Ambiente de Processamento Distribu´ıdo em Grade Aplicado ao OncoGrid 67

Figura 4.3: Arquitetura do ambiente de processamento do OncoGrid representada no modelo de camadas funcionais.

Por exemplo, cada institui¸c˜ao participante pode ter um contˆeiner de servi¸co, e um servi¸co que est´a no contˆeiner da institui¸c˜ao A pode requisitar um servi¸co que est´a no contˆeiner da institui¸c˜ao B para realizar suas tarefas, assim como o servi¸co de informa¸c˜ao da grade pode identificar os recursos que est˜ao em A e em B. Por sua vez, o gerenciador de recursos pode utilizar recursos f´ısicos para processamento das duas localidades para executar uma determinada tarefa.