CAPTURA DE DADOS DE PROVENIÊNCIA DE WORKFLOWS CIENTÍFICOS EM NUVENS COMPUTACIONAIS
Carlos Eduardo Paulino Silva
Dissertação de Mestrado apresentada ao Programa de Pós-graduação em Engenharia de Sistemas e Computação, COPPE, da Universidade Federal do Rio de Janeiro, como parte dos requisitos necessários à obtenção do título de Mestre em Engenharia de Sistemas e Computação.
Orientadora: Marta Lima de Queirós Mattoso
Rio de Janeiro Setembro de 2011
CAPTURA DE DADOS DE PROVENIÊNCIA DE WORKFLOWS CIENTÍFICOS EM NUVENS COMPUTACIONAIS
Carlos Eduardo Paulino Silva
DISSERTAÇÃO SUBMETIDA AO CORPO DOCENTE DO INSTITUTO ALBERTO LUIZ COIMBRA DE PÓS-GRADUAÇÃO E PESQUISA DE ENGENHARIA (COPPE) DA UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO PARTE DOS REQUISITOS NECESSÁRIOS PARA A OBTENÇÃO DO GRAU DE MESTRE EM CIÊNCIAS EM ENGENHARIA DE SISTEMAS E COMPUTAÇÃO.
Examinada por:
________________________________________________ Profª. Marta Lima de Queirós Mattoso, D.Sc.
________________________________________________ Prof. Alexandre de Assis Bento Lima, D.Sc.
________________________________________________ Prof. Fabio Andre Machado Porto, D.Sc.
RIO DE JANEIRO, RJ - BRASIL SETEMBRO DE 2011
iii
Silva, Carlos Eduardo Paulino
Captura de Dados de Proveniência de Workflows Científicos em Nuvens Computacionais / Carlos Eduardo Paulino Silva. – Rio de Janeiro: UFRJ/COPPE, 2011.
IX,47p.: il.; 29,7 cm.
Orientadora: Marta Lima de Queirós Mattoso
Dissertação (mestrado) – UFRJ/ COPPE/ Programa de Engenharia de Sistemas e Computação, 2011.
Referências Bibliográficas: p. 44-47.
1. Proveniência. 2. Workflows científicos. 3. Computação em nuvem. I. Mattoso, Marta Lima de Queirós. II. Universidade Federal do Rio de Janeiro, COPPE, Programa de Engenharia de Sistemas e Computação. III. Título.
iv
Resumo da Dissertação apresentada à COPPE/UFRJ como parte dos requisitos necessários para a obtenção do grau de Mestre em Ciências (M.Sc.)
CAPTURA DE DADOS DE PROVENIÊNCIA DE WORKFLOWS CIENTÍFICOS EM NUVENS COMPUTACIONAIS
Carlos Eduardo Paulino Silva
Setembro/2011
Orientadora: Marta Lima de Queirós Mattoso Programa: Engenharia de Sistemas e Computação
Workflows científicos são abstrações utilizadas na modelagem de experimentos científicos in silico. Alguns desses experimentos demandam recursos de alto desempenho como clusters e grades computacionais. O modelo computacional chamado de computação em nuvem vem sendo adotado pela comunidade científica. Para que um experimento possa ser considerado válido perante esta mesma comunidade ele precisa ser passível de reprodução, o que só é possível através do registro de metadados de proveniência. No entanto, as nuvens computacionais ainda são incipientes no que se refere à captura e armazenamento destes metadados. Essa dissertação apresenta uma arquitetura que apóia a captura e o armazenamento de metadados de proveniência de workflows científicos executados nos ambientes de nuvens computacionais. Ela é baseada na evolução da arquitetura Matrioshka.
v
Abstract of Dissertation presented to COPPE/UFRJ as a partial fulfillment of the requirements for the degree of Master of Science (M.Sc.)
CAPTURING PROVENANCE METADATA FROM CLOUD-BASED SCIENTIFIC WORKFLOWS
Carlos Eduardo Paulino Silva
September/2011
Advisor: Marta Lima de Queirós Mattoso Department: Computer Science Engineering
Scientific workflow is an abstraction used to model in silico experiments. Some of these experiments demands high performance computing environments such as clusters and grids. A new computing model called cloud computing is being adopted by the scientific community to execute their scientific experiments. In addition, in order to consider a scientific experiment as scientific, it has to be reproducible, by querying provenance metadata. However, cloud environments are still incipient when we are capturing and storing provenance metadata. This dissertation proposes an approach to support capturing and storing provenance metadata from cloud-based scientific workflows. This approach is coupled to the Matrioshka architecture.
vi ÍNDICE Capítulo 1 - Introdução ... 1 1.1 Contexto e motivação... 1 1.2 Definição do problema ... 3 1.3 Objetivo ... 4 1.4 Metodologia ... 5 1.5 Estrutura da dissertação... 5
Capítulo 2 - Workflows Científicos e Computação em nuvem ... 6
2.1 Proveniência... 6
2.2 Experimentos in silico ... 7
2.3 Workflows científicos ... 8
2.4 Sistemas de Gerência de Workflows Científicos... 9
2.5 Computação em nuvem ... 10
2.6 Proveniência de Experimentos Científicos em Nuvens Computacionais... 11
2.7 Trabalhos relacionados... 12
2.8 Considerações finais... 14
Capítulo 3 - Captura de Dados de Proveniência de Workflows Científicos em Nuvens Computacionais ... 16 3.1 Histórico ... 16 3.2 Arquitetura ... 17 3.2.1 Manifestos... 18 3.2.2 Dispatcher... 22 3.2.3 Execution Broker... 23 3.2.4 Provenance Broker... 24 3.2.5 Provenance Eavesdrop... 24
3.2.6 Repositório de Proveniência da Nuvem ... 25
3.3 Bibliotecas utilizadas na implementação... 27
3.4 Considerações finais... 28
Capítulo 4 - Avaliação da arquitetura proposta... 29
4.1 OrthoSearch ... 29
4.2 Configuração do ambiente... 31
vii 4.4 Consultas à proveniência ... 35 Capítulo 5 - Conclusão... 41 5.1 Contribuições ... 41 5.2 Limitações do trabalho ... 42 5.3 Trabalhos futuros ... 42 Referências Bibliográficas ... 44
viii
LISTA DE FIGURAS
Figura 1. Arquitetura Matrioshka adaptada para a captura de proveniência de workflows científicos executados no ambiente de nuvens (PAULINO et al., 2009, 2010, 2011)
... 18
Figura 2. Estrutura do arquivo de manifesto de configuração da nuvem. SetupManifest.xml... 19
Figura 3. Estrutura do arquivo de manifesto com a especificação dos dados do experimento. ExperimentManifest.xml... 20
Figura 4. Estrutura do arquivo de manifesto com a especificação dos dados da atividade a ser executada no ambiente de nuvem. ActivityManifest.xml... 21
Figura 5. Substituição da atividade executada localmente pelo Dispatcher no VisTrails ... 23
Figura 6. Modelo de dados de proveniência para o ambiente de nuvens... 26
Figura 7. Workflow OrthoSearch (CRUZ et al., 2008b) ... 30
ix
LISTA DE QUADROS
Quadro 1. Configuração de hardware e preços de utilização dos tipos de instâncias
disponíveis ... 32
Quadro 2. Resultado da consulta de proveniência (i) ... 36
Quadro 3. Resultado da consulta de proveniência (ii) ... 36
Quadro 4. Resultado da consulta de proveniência (iii) ... 37
Quadro 5. Resultado da consulta de proveniência (iv) ... 38
Quadro 6. Resultado da consulta de proveniência (v) ... 39
1
Capítulo 1 - Introdução
Este capítulo tem como objetivo apresentar a contextualização e motivação para criação de uma arquitetura para a captura de metadados de proveniência dos workflows científicos executados em nuvens computacionais, além de delimitar qual é o escopo do problema tratado pela arquitetura proposta e definir o objetivo a ser alcançado pela mesma. Será apresentada também a metodologia utilizada para alcançar os objetivos definidos e as contribuições da dissertação, antecipando alguns resultados para que seja possível evidenciar as principais diferenças dessa arquitetura em relação a outras.
1.1 Contexto e motivação
A computação em nuvem (VAQUERO et al., 2009) vem se firmando como um novo modelo de computação onde componentes de software e hardware são desenvolvidos como serviços baseados na Web e disponibilizados para uma gama (teoricamente infinita) de usuários. Uma grande vantagem disponibilizada pelas nuvens é a elasticidade de recursos oferecida (KIM et al., 2009, NAPPER e BIENTINESI, 2009, VAQUERO et al., 2009), uma vez que caso um usuário precise de mais recursos computacionais, basta que o mesmo solicite ao provedor da nuvem e os recursos serão automaticamente disponibilizados.
Devido a estas vantagens, a computação em nuvem se mostra atrativa em diversos domínios do conhecimento, inclusive no científico (HOFFA et al., 2008, MATSUNAGA et al., 2008, SIMMHAN et al., 2008, WANG et al., 2008). Grande parte dos experimentos científicos elaborados para comprovar ou refutar uma determinada hipótese são baseados em infraestrutura computacional e simulações (TAYLOR et al., 2007b, MATTOSO et al., 2010). Esses experimentos são chamados de experimentos in silico (TRAVASSOS e BARROS, 2003), nos quais os cientistas normalmente utilizam um conjunto de programas para executar uma determinada atividade. Esses programas normalmente são encadeados formando um fluxo coerente onde a saída de um programa é a entrada do próximo no fluxo de execução. A este encadeamento de programas que representa o experimento que está sendo executado dá-se o nome de Workflow Científico (TAYLOR et al., 2007b, MATTOSO et al., 2010).
2 Os workflows científicos podem ser gerenciados de maneira ad-hoc, mas são mais adequadamente manipulados por complexos mecanismos chamados Sistemas de Gerência de Workflows Científicos (SGWfC), que oferecem o arcabouço necessário para executar, definir e monitorar as execuções dos workflows científicos tanto local quanto remotamente. Existem diversos SGWfC disponíveis para utilização (TAYLOR et al., 2007b), como por exemplo: Kepler (ALTINTAS et al., 2004), VisTrails (CALLAHAN et al., 2006), Taverna (HULL et al., 2006), Pegasus (DEELMAN et al., 2007), Triana (TAYLOR et al., 2007a), Swift (ZHAO et al., 2007), cada um deles com características próprias e vantagens e desvantagens.
Experimentos científicos in silico em larga escala podem ser modelados como workflows científicos. Esses experimentos são caracterizados pela composição e execução de diversas variações de workflows (MATTOSO et al., 2010). Estas variações em execuções incluem parâmetros, dados de entrada e até os programas que compõem o workflow. Nos experimentos em larga escala, estas variações podem ocorrer utilizando uma imensa quantidade de dados ou repetições, as quais necessitam de ambientes de processamento de alto desempenho (PAD) para que produzam resultados em um tempo aceitável (ZHAO et al., 2008). Desta forma, um workflow pode necessitar ser executado em ambientes distribuídos e muitas vezes heterogêneos.
Porém, a execução e a definição do experimento não são os únicos aspectos importantes na experimentação científica. Para que um experimento não seja refutado pela comunidade científica, o mesmo deve ser passível de reprodução sob as mesmas condições em outras instalações por outros grupos de pesquisadores utilizando o método originalmente utilizado. Desta forma, toda a informação relacionada ao experimento, tanto sua definição quanto os dados inicialmente utilizados e gerados durante a sua execução, são fundamentais para que o experimento seja considerado consistente e válido. A este tipo de informação, damos o nome de proveniência (BUNEMAN et al., 2001, DAVIDSON e FREIRE, 2008, FREIRE et al., 2008).
A captura dos metadados de proveniência nos ambientes distribuídos, chamada de proveniência distribuída, ainda é uma questão em aberto. Mesmo dentre os SGWfC concebidos para operar em ambientes distribuídos, como o Swift, Pegasus e o Triana, existem ainda limitações para a captura de proveniência distribuída, seja ela em clusters ou grades computacionais (FOSTER e KESSELMAN, 2004). No ambiente de nuvens computacionais, capturar a proveniência distribuída de um workflow também é um desafio ainda em aberto (OLIVEIRA et al., 2010a). Portanto, a adoção de nuvens
3 computacionais para a execução de workflows sem o apoio de mecanismos para a captura da proveniência distribuída pode representar uma barreira para a validade do experimento como um todo pela comunidade científica. A principal dificuldade da captura e armazenamento de proveniência na nuvem se dá devido à heterogeneidade do ambiente, pelo fato de existir vários tipos possíveis de configurações de hardware e software oferecidos pelos recursos da nuvem, e à mutabilidade, visto que esses recursos são alocados sob demanda.
Atualmente, existem algumas propostas na literatura para capturar e gerenciar proveniência em ambientes distribuídos. Grande parte deles é focada em ambientes como clusters e grades computacionais. Um exemplo destes mecanismos é a Matrioshka (CRUZ et al., 2008a). A Matrioshka tem como objetivo prover uma série de serviços que podem ser acoplados em ambientes distribuídos, como clusters e grades computacionais. O principal diferencial da Matrioshka está em seu apoio à consultas semânticas por meio de relacionamentos entre os metadados de proveniência e ontologias (CRUZ, 2011). Entretanto, a Matrioshka não foi originalmente projetada para operar em ambientes de nuvens computacionais e, portanto, seus serviços precisam ser estendidos para que possam apoiar esse ambiente.
Esta dissertação propõe uma evolução da arquitetura da Matrioshka para que a mesma possa ser utilizada na captura de proveniência de workflows científicos executados em nuvens computacionais e consiga manter as vantagens semânticas da Matrioshka. Assim, um dos objetivos está em responder algumas possíveis questões que podem ser realizadas sobre um experimento executado nesse ambiente, como por exemplo, “Quais os nomes e as versões dos programas utilizados para executar as atividades do workflow X?”, “Quais instâncias do ambiente de nuvem estão disponíveis para executar o workflow X?”, “Qual a configuração da instância utilizada para executar a atividade Y do workflow X?”, etc. Para isso, serão realizadas algumas extensões nos serviços da Matrioshka para atender as especificidades dos ambientes de nuvens computacionais.
1.2 Definição do problema
Atualmente os experimentos científicos em larga escala do tipo in silico (TRAVASSOS e BARROS, 2003) requerem cada vez mais recursos computacionais que podem ser locais ou distribuídos. Com a adoção do modelo de computação em
4 nuvem, novos desafios foram impostos ao cientista, como por exemplo, a migração dos experimentos científicos para esse novo ambiente, o que faz com que novas soluções computacionais sejam necessárias.
Um dos maiores problemas enfrentados pelos cientistas durante essa migração é a coleta dos metadados de proveniência do experimento cientifico. Essa coleta de metadados, conhecida também como proveniência de dados, ainda é uma questão em aberto neste novo paradigma de computação (OLIVEIRA et al., 2010a). A proveniência, também chamada de linhagem ou pedigree, é um registro digital acerca das informações sobre os dados de entrada e saída e processos associados às etapas dos workflows científicos e ao ambiente utilizado para executá-lo. A proveniência é utilizada para permitir a repetibilidade/reprodutibilidade e oferecer dados para o melhor entendimento sobre os experimentos científicos por outros cientistas.
Ao longo do desenvolvimento dessa dissertação surgiram abordagens para execução de workflows científicos em ambientes de nuvem como o Pegasus (KIM et al., 2008) e o SciCumulus (OLIVEIRA et al., 2010b, 2011a, 2011b), porém, essas abordagens não possuem ligação de metadados de proveniência com dados ontológicos, o que limita o escopo de consultas sobre os metadados de proveniência. O problema relevante abordado nessa dissertação é como capturar a proveniência distribuída em ambientes de nuvem considerando os aspectos particulares desses ambientes, como a elasticidade de recursos, instâncias virtualizadas, heterogeneidade entre as instâncias com relação a hardwares e softwares, etc. e ao mesmo tempo permitir um relacionamento com ontologias.
1.3 Objetivo
Desenvolver um conjunto de serviços baseados em arquitetura de código aberto e de software livre que serão acoplados a SGWfC existentes (ou máquinas de execução de workflows científicos) e serão utilizados para auxiliar a coleta de metadados de proveniência, desenvolvendo um repositório de proveniência das atividades do workflow científico executadas na nuvem. Além disso, criar um vínculo com os metadados de proveniência local armazenados pelo SGWfC, caso o mesmo realize a captura desses metadados. Esse conjunto de serviços é uma extensão da proposta original da Matrioshka e foram adaptados de acordo com as especificidades do ambiente de nuvem.
5
1.4 Metodologia
Para alcançar o objetivo proposto por essa dissertação, foi realizada uma revisão da literatura que nos permitiu chegar a conclusões que apontaram para a extensão das funções dos serviços da Matrioshka para a captura de metadados de proveniência nos ambientes de nuvem, além da criação de um novo modelo de dados em que seja possível armazenar esses metadados.
Posteriormente, foi projetada uma adaptação na arquitetura da Matrioshka, a qual foi sendo refinada através da criação de protótipos dos serviços e do modelo de dados a ser utilizado para atender às especificidades do ambiente de nuvem, gerando assim, após a realização de vários testes, componentes de extensão para a arquitetura da Matrioshka voltada para o ambiente de nuvem (PAULINO et al., 2009, 2010, 2011).
Nessa dissertação também utilizamos o conceito de estudo de caso para que se pudesse verificar o funcionamento dos componentes da extensão da arquitetura proposta utilizando o workflow OrthoSearch (CRUZ et al., 2008b), o qual foi escolhido por ser projetado para ser executado em ambientes distribuídos devido à imensa quantidade de dados e processamento a ser realizado para gerar os resultados esperados. Esse workflow é um experimento real de bioinformática utilizado pelo consórcio BiowebDB (www.biowebdb.org).
1.5 Estrutura da dissertação
Essa dissertação está organizada em quatro capítulos além da introdução. O Capítulo 2 apresenta uma breve definição dos principais conceitos utilizados nessa dissertação e, portanto, devem ser definidos, como por exemplo, experimentos científicos, workflows científicos, SGWfC, computação em nuvem e proveniência de dados, além de apresentar alguns trabalhos relacionados com a execução de workflows no ambiente de nuvens. O Capítulo 3 apresenta a arquitetura proposta para a captura de proveniência de workflows científicos executados no ambiente de nuvens. O Capítulo 4 explica como foi realizado o estudo de caso para validar a arquitetura desenvolvida e apresenta os resultados obtidos. E finalmente, no Capítulo 5 é apresentada a conclusão da dissertação, evidenciando as principais contribuições e limitações da mesma, além de relacionar possíveis trabalhos futuros que podem ser desenvolvidos a partir dos resultados apresentados nessa dissertação.
6
Capítulo 2 - Workflows Científicos e Computação em
nuvem
Esse capítulo tem como objetivo definir alguns conceitos que são utilizados nessa dissertação, como experimentos científicos in silico, workflows científicos e sistemas de gerência de workflows científicos (SGWfC), dentre os quais destacaremos o VisTrails, Kepler, Taverna, Pegasus, Triana e o Swift. Levando em consideração as principais características desses SGWfC um deles foi selecionado para ser usado no estudo de caso dessa dissertação. Além dos conceitos mencionados, também definimos com mais detalhes proveniência e sua utilidade em experimentos científicos, computação em nuvem e os principais trabalhos relacionados com a execução de workflows científicos em ambientes de nuvens.
2.1 Proveniência
No domínio científico é possível encontrar diferentes formas de proveniência com os mais diversos propósitos. Por exemplo, publicações são comumente utilizadas para representar a proveniência de dados e resultados de um experimento. GOBLE et al. (2003) resumem as diversas funcionalidades para as informações de proveniência da seguinte maneira:
1 Qualidade dos Dados: informações de proveniência podem ser utilizadas para estimar a qualidade e a confiabilidade dos dados baseando-se na origem dos dados e suas transformações.
2 Auditoria dos Caminhos: os dados de proveniência podem traçar rotas dos dados, determinar a utilização de recursos e detectar erros na geração de dados.
3 Controle de replicação: informações de proveniência detalhadas permitem a derivação de dados e ajudam a padronizar a replicação.
4 Atribuição: mantém controle sobre as informações do dono do experimento e seus dados. Também permite a citação e atribuem responsabilidades em caso de dados errados.
5 Informacional: permite realizar consultas baseadas nos metadados de origem para a descoberta de dados, além de prover o contexto necessário para interpretar os dados.
7 A proveniência pode ser classificada em diversas formas (FREIRE et al., 2008), como por exemplo, as proveniências prospectiva, retrospectiva e analítica. A primeira diz respeito ao processo de definição do workflow científico, a segunda está relacionada com a sua execução e finalmente a terceira com a análise de dados do experimento. Essa dissertação se limita ao estudo da primeira e segunda forma.
Para armazenar a proveniência retrospectiva podem ser utilizados modelos de dados que utilizem como base a mais recente recomendação do Open Provenance Model (OPM) (MOREAU et al., 2008), versão 1.1, o qual propõe uma representação genérica de proveniência. O OPM expressa as relações causais entre Processos, Agentes, Artefatos e Papéis existentes em workflows.
Uma das principais vantagens do OPM é facilitar a interoperabilidade de metadados de proveniência oriundos de ambientes heterogêneos independentemente da tecnologia e dos SGWfC. Por esse motivo o OPM vem sendo utilizado por diversos SGWfC (FREIRE et al., 2008).
2.2 Experimentos in silico
Um experimento científico pode ser definido como “um teste sob condições controladas que é realizado para demonstrar um fato conhecido, examinar a validade de uma hipótese ou determinar a eficácia de algo que ainda não foi analisado” (SOANES e STEVENSON, 2003). Também pode ser definido como “uma situação, criada em laboratório, que tem como objetivo observar, sob condições controladas, o fenômeno de interesse” (JARRARD, 2001).
Entretanto, nas últimas décadas, um novo tipo de experimento foi criado, o experimento in silico (TRAVASSOS e BARROS, 2003). Os experimentos in silico são aqueles em que tanto os objetos de estudo quanto os ambientes são simulados através de modelos computacionais. A utilização dos experimentos in silico vem aumentando muito nos últimos anos principalmente devido ao surgimento dos experimentos científicos em larga escala, os quais devido ao grande volume de dados a ser processado pode levar dias ou até meses para serem executados, por isso, precisam de um ambiente de processamento de alto desempenho (PAD).
Os ambientes de PAD, tais como clusters, grades computacionais e mais recentemente, as nuvens computacionais, surgem como soluções para atender a demanda de recursos computacionais requerida pelos experimentos científicos em larga
8 escala. Dentre esses ambientes, as nuvens computacionais se destacam atualmente, principalmente pela facilidade de configuração e devido a uma de suas principais características, a elasticidade, o que garante que cientistas sem conhecimentos avançados de computação possam configurar seus próprios ambientes de alto desempenho, algo pouco provável de acontecer no caso de clusters e grades computacionais, além de dimensionar seu ambiente de acordo com a demanda requerida de forma específica por cada experimento, o que evita o desperdício de recursos computacionais.
2.3 Workflows científicos
De acordo com o Workflow Management Coalition (WFMC, 1997, BARGA e GANNON, 2007), um workflow pode ser definido como “a automação de um processo de negócio, por completo ou em parte, no qual os documentos, informações e tarefas são passadas de um participante para outro a fim de que uma ação seja tomada de acordo com uma série de regras procedimentais”. Um workflow define a ordem de invocação de atividades e as condições sob as quais devem ser invocadas e sincronizadas. Esta definição foi inicialmente elaborada para definir workflows de negócio, entretanto, pode ser expandida para o domínio científico (TAYLOR et al., 2007b).
Os experimentos in silico, são representados por meio do encadeamento de atividades, onde cada atividade é mapeada para uma aplicação, formando um fluxo coerente de informações e controles, onde os dados de saída de um programa são entradas do próximo programa no fluxo. A esse encadeamento de atividades dá-se o nome de workflow científico.
Experimentos científicos que são modelados como workflows científicos também devem seguir um método científico específico (JARRARD, 2001) e são caracterizados pela definição e execução de diversas variações de workflows no contexto do mesmo experimento (MATTOSO et al., 2010). Estas variações incluem parâmetros, dados de entrada e até os programas que compõem o workflow.
Workflows científicos se assemelham em vários pontos aos workflows de negócio. Entretanto, existem algumas diferenças entre workflows científicos e workflows de negócio que valem a pena serem ressaltadas. As principais são o grande volume de
9 dados que pode ser manipulado em um workflow científico, cujo tamanho é muito variável, e a heterogeneidade de tipos e fontes desses dados.
2.4 Sistemas de Gerência de Workflows Científicos
Os workflows científicos podem ser gerenciados de maneira ad-hoc, mas são mais adequadamente manipulados por mecanismos chamados Sistemas de Gerência de Workflows Científicos (SGWfC), que oferecem o arcabouço necessário para executar, definir e monitorar as execuções dos workflows científicos tanto local quanto remotamente. Geralmente os SGWfC oferecem aos usuários interfaces gráficas que visam facilitar não somente a definição dos workflows, como também sua execução e seu respectivo monitoramento. Alguns desses SGWfC oferecem também apoio à coleta de proveniência dos dados e atividades utilizados durante a definição e execução dos workflows, além de apoiar também a análise desses metadados de proveniência coletados.
Existem diversos SGWfC disponíveis para utilização (TAYLOR et al., 2007b), como por exemplo: Kepler (ALTINTAS et al., 2004), VisTrails (CALLAHAN et al., 2006) e o Taverna (HULL et al., 2006), concebidos para operar em ambientes centralizados, e os SGWfC Pegasus (DEELMAN et al., 2007) , Triana (TAYLOR et al., 2007a) e Swift (ZHAO et al., 2007), concebidos para operar em ambientes distribuídos.
Com relação ao apoio a proveniência, o Kepler possui alguns recursos como os logs, mas os mesmos não foram projetados com a finalidade de serem usados como metadados de proveniência. Swift, Triana e Pegasus apresentam mecanismos projetados especialmente para captura da proveniência da execução distribuída dos workflows. O Taverna e o VisTrails possuem de forma nativa além da coleta dos metadados de proveniência gerados durante a definição e execução dos workflows, o seu respectivo gerenciamento, facilitando assim a consulta e análise da proveniência coletada. O VisTrails possui um modelo de dados no formato XML que é usado para armazenar os metadados de proveniência coletados, além do formato relacional, o que facilita a realização de consultas a esses metadados usando a linguagem SQL e o relacionamento com outras bases de dados relacionais. Um diferencial do VisTrails é capturar a proveniência prospectiva e retrospectiva (FREIRE et al., 2008). Devido a essas características podemos concluir que o SGWfC VisTrails é o mais indicado para ser usado no estudo de caso dessa dissertação, por oferecer de forma nativa, apoio ao
10 gerenciamento de proveniência, com mais semântica que os demais e um modelo de dados relacional para armazenar os metadados coletados a partir do ambiente local de execução do workflow.
Entretanto, é importante destacar uma característica comum a grande maioria dos SGWfC mencionados acima, nenhum possui apoio nativo ao gerenciamento de metadados de proveniência coletados a partir da execução dos workflows científicos em ambiente de nuvens, nem mesmo o Swift, concebido para operar em ambientes distribuídos. A ausência desse apoio dificulta em muito a execução de workflows científicos no ambiente de nuvens.
2.5 Computação em nuvem
Nos últimos anos a computação em nuvem emergiu (VAQUERO et al., 2009) como um novo paradigma computacional onde serviços baseados na Web possibilitaram que os mais diferentes tipos de usuários pudessem obter uma grande variedade de funcionalidades, como infraestrutura, software e hardware, sem que os usuários tenham que lidar com detalhes de desenvolvimento e configuração.
Esse novo paradigma computacional também permite a migração de programas e dados, que são parte fundamental quando modelamos experimentos científicos utilizando a abstração de workflows científicos, de ambientes locais para as nuvens computacionais. FOSTER et al. (2008) examinaram e detalharam as diferenças principais entre grades computacionais e nuvens computacionais, oferecendo assim uma fundamentação teórica para o entendimento e a categorização dos ambientes de nuvem. Esses autores definiram computação em nuvem como “um modelo de computação distribuída em larga escala que é composto por recursos virtualizáveis, dinamicamente escaláveis e que são disponibilizados para os usuários externos através da Web”.
Muitas aplicações estão sendo adaptadas para nuvens, como por exemplo, redes sociais, portais de jogos, aplicações para negócios, workflows científicos (VAQUERO et al., 2009), entre outras. Os serviços mais comuns oferecidos por um ambiente de computação em nuvem e que são importantes para o apoio à execução de workflows científicos seguem os seguintes modelos de computação:
1 SaaS: Software como um Serviço - O software é hospedado na nuvem como um serviço e acessado pelos usuários de acordo com a sua necessidade. Com isso a
11 instalação no computador local do usuário não é mais necessária e os custos com a licença, manutenção e atualização do software são reduzidos à zero.
2 DaaS: Dados como um Serviço - Dados de vários formatos e de diversas origens podem ser acessados e manipulados de forma transparente como serviços pelos usuários.
3 IaaS: Infraestrutura como Serviço - A infraestrutura computacional como grades e clusters de empresas e grandes corporações são disponibilizadas como serviços na Web de forma que se possa tirar proveito de recursos de grande porte sem arcar com seus custos iniciais de implantação e configuração.
Nessa dissertação são utilizados esses três modelos de computação para a execução e captura dos metadados de proveniência dos workflows científicos em ambientes de nuvens computacionais. Por exemplo, os dados utilizados pelas atividades que compõem o workflow são providos pelo DaaS do provedor de nuvem utilizado na execução do workflow.
Dentre as principais vantagens do modelo de computação em nuvem podemos destacar o fato que um usuário comum pode acessar uma grande variedade de recursos sem ter que adquirir e configurar toda a infraestrutura computacional. Essa é uma necessidade importante para aplicações científicas, uma vez que os cientistas devem estar isolados da complexidade do ambiente, focando apenas na gerência do experimento científico. Outras vantagens de suma importância a se destacar são a elasticidade de recursos oferecida e o acesso quase que ininterrupto aos mesmos. Isto é, caso o usuário necessite de mais recursos, basta que o mesmo solicite ao provedor da nuvem e os recursos estarão disponíveis quase que instantaneamente.
Devido a estas vantagens, muitos cientistas já começaram a migrar seus experimentos científicos in silico, baseados em infraestrutura computacional e simulações para o ambiente das nuvens computacionais (HOFFA et al., 2008, MATSUNAGA et al., 2008, SIMMHAN et al., 2008, WANG et al., 2008, OLIVEIRA et al., 2011a).
2.6 Proveniência de Experimentos Científicos em
Nuvens Computacionais
Uma das principais vantagens da utilização do ambiente de nuvens para a execução dos experimentos científicos é prover aos cientistas o acesso a uma grande
12 variedade de recursos sem ter que necessariamente adquirir e configurar a infraestrutura computacional. São exemplos de experimentos in silico adaptados para nuvens, os projetos Sloan Digital Sky Survey e Berkley Water Center (HEY et al., 2009). Outra característica comum a muitos desses projetos é o uso intensivo de workflows científicos utilizando vários SGWfC. Consequentemente surge a necessidade da coleta de metadados de proveniência desses workflows executados na nuvem, pois, é necessário assegurar a reprodutibilidade desses experimentos. Sem esses metadados, o experimento tem sua avaliação e reprodução comprometidas. Por exemplo, em geral a execução em ambientes de nuvem ocorre de forma transparente para o cientista, ou seja, o que se passa na nuvem é uma “caixa preta”. Portanto, é fundamental que os cientistas saibam quais parâmetros foram utilizados e quais produtos de dados foram gerados em cada execução do workflow. Até o momento nenhum dos ambientes de nuvem oferecem, de forma nativa, meios capazes de capturar e armazenar metadados de proveniência produzidos por experimentos in silico.
A captura e o gerenciamento de metadados de proveniência em ambientes distribuídos ainda representam uma questão em aberto (FREIRE et al., 2008, MATTOSO et al., 2010). No caso do ambiente de nuvem, além dos problemas típicos dos ambientes distribuídos para a coleta de metadados de proveniência, existe a questão relativa ao tráfego desses dados utilizando a internet, o que deixa mais suscetível a falhas o sistema responsável por capturar esses metadados. Por esse motivo, a arquitetura de captura descrita nessa dissertação armazena os metadados de proveniência na própria nuvem, sendo esses dados relacionados com os dados capturados localmente pelo SGWfC VisTrails para que o cientista possa ter uma visão geral de todos os metadados de proveniência coletados, tanto localmente pelo SGWfC quanto remotamente pela Matrioshka.
2.7 Trabalhos relacionados
Atualmente os ambientes de nuvem não oferecem de forma nativa o armazenamento de proveniência. Em MUNISWAMY-REDDY et al. (2009) é fornecida uma motivação para que os provedores de nuvem forneçam a captura e armazenamento de proveniência de dados na nuvem de forma nativa, independente da tarefa que está sendo executada na nuvem. Além dos benefícios de validação e reprodução de experimentos científicos, a proveniência também fornece uma maior transparência e
13 segurança da nuvem, fatores que são determinantes para que algumas aplicações possam ser migradas pra nuvem. Porém vários requisitos são enumerados pelo autor para que os ambientes de nuvem possam capturar e armazenar proveniência de forma nativa, e alguns desses requisitos, como por exemplo, a segurança da proveniência armazenada, precisam ser bem definidos, pois, em alguns casos pode comprometer a privacidade do usuário final da nuvem. Com isso podemos perceber que existem ainda muitos desafios para que os provedores de nuvem ofereçam a captura e armazenamento de proveniência de forma nativa, o que pode demorar ainda alguns anos e com isso prejudicar a adesão da nuvem principalmente por cientistas que desejam rodar seus experimentos nesse ambiente.
Em MUNISWAMY-REDDY et al. (2009) os autores mostram também que a computação em nuvem se mostra muito eficiente para o armazenamento de dados, porém, não possui apoio para o armazenamento e posterior consulta de metadados de proveniência. São apresentadas algumas alternativas para o armazenamento da proveniência usando o ambiente de computação em nuvem da Amazon EC2 (AMAZON EC2, 2010) e utilizando o PASS (SIMMHAN et al., 2006). O PASS é um sistema para coleta e armazenamento de proveniência distribuída. O artigo propõe a utilização de três arquiteturas utilizando estruturas de armazenamento nativas da Amazon EC2, o Simple Storage Service (S3), o SimpleDB e o Simple Queueing Service (SQS). As arquiteturas utilizadas são compostas de uma ou mais estruturas de armazenamento, visando assim, minimizar suas limitações quanto ao armazenamento e posterior consulta dos dados armazenados. A arquitetura utilizando apenas o S3 se mostrou ineficiente quanto a consulta dos dados armazenados, a arquitetura utilizando S3 e SimpleDB não garante a atomicidade dos dados e a arquitetura utilizando as três estruturas de armazenamento se mostrou eficiente em todos os requisitos avaliados (atomicidade, consistência, ordenação e eficiência das consultas). Porém, é importante destacar que todo processo de armazenamento é realizado utilizando estruturas nativas da nuvem da Amazon EC2, com isso, caso o ambiente de captura de proveniência não seja a nuvem da Amazon EC2, como por exemplo, utilizando a nuvem da IBM (IBM SMART BUSINESS DEVELOPMENT & TEST, 2010), o sistema terá que ser totalmente adaptado, pois, não utiliza uma estrutura de armazenamento comum entre esses dois ambientes de nuvens.
Outro ponto que merece ser destacado é a enorme quantidade de dados que são armazenados para se obter a proveniência. No ambiente de nuvem, quanto mais dados
14 precisam ser trafegados utilizando a internet, mais suscetível a falhas fica o sistema responsável por capturar e armazenar os metadados de proveniência. Para minimizar a quantidade de metadados que precisam ser armazenados, GROTH et al. (2009) propõem um novo modelo de proveniência. Esse novo modelo proposto armazena metadados de proveniência que são realmente consultados pelos usuários finais, visto que em outros modelos são armazenados volumes de metadados extremamente grandes, nos quais o usuário na prática consulta apenas os metadados de determinadas atividades, e com isso, a enorme quantidade de metadados se torna desnecessária. Os autores utilizam o workflow científico Montage (JACOB et al., 2009) utilizado para processamento de imagens astronômicas, nos testes realizados para armazenamento de proveniência utilizando o novo modelo proposto. Por ser um workflow que trabalha com imagens, o tamanho dos dados gerados e que precisam ser armazenados é extremamente grande, na ordem de petabytes. O modelo de proveniência pipeline-centric consiste basicamente em realizar um levantamento dos dados de proveniência que o usuário final necessita para validar e reproduzir seu experimento científico. No exemplo do artigo utilizando o Montage foi apresentada uma redução significativa do tamanho dos metadados armazenados de proveniência, porém, é preciso destacar que para cada workflow científico onde esse modelo é aplicado é necessário determinar quais metadados precisam ser armazenados.
Recentemente foi proposto o sistema SciCumulus (OLIVEIRA et al., 2010b, 2011a, 2011b) com objetivo específico de executar workflows científicos em larga escala aproveitando os recursos da nuvem. Porém, o SciCumulus não possui ligação de metadados de proveniência com dados ontológicos, o que limita o escopo de consultas sobre os metadados de proveniência.
2.8 Considerações finais
A computação em nuvem, principalmente devido à elasticidade de recursos e a alta disponibilidade, apresenta-se como uma interessante alternativa para a execução de experimentos científicos in silico em larga escala baseados em workflows científicos que demandam ambientes computacionais distribuídos para que sua execução ocorra em um tempo aceitável pelos cientistas. Porém, por ser uma tecnologia ainda incipiente em aplicações científicas a execução dos workflows em nuvens ainda é um problema em aberto, principalmente no que tange à captura e ao gerenciamento de metadados de
15 proveniência gerados nesse ambiente.
16
Capítulo 3 - Captura de Dados de Proveniência de
Workflows Científicos em Nuvens Computacionais
Nesse capítulo é proposta uma nova arquitetura estendida da Matrioshka para coletar e armazenar os metadados de proveniência de workflows científicos executados nos ambientes de nuvens computacionais.
3.1 Histórico
A captura dos metadados de proveniência nos ambientes distribuídos ainda é uma questão em aberto. Mesmo dentre os SGWfC concebidos para operar em ambientes distribuídos, como o Swift, Pegasus e o Triana, existem ainda limitações para a captura de proveniência distribuída, seja ela em clusters ou grades computacionais (FOSTER e KESSELMAN, 2004). Além disso, esses poucos existentes são focados em ambientes como clusters e grades computacionais. Um exemplo destes mecanismos é a Matrioshka (CRUZ et al., 2008a, CRUZ, 2011), cuja arquitetura foi concebida para ambientes de clusters e grades computacionais, e que, por isso, utiliza serviços exclusivos desses ambientes, como por exemplo, gerenciadores de fila (i.e. PBS ou Condor), escalonadores, entre outros. As características do ambiente de nuvens computacionais, como por exemplo, elasticidade de recursos, virtualização, independência de localização, métodos de acesso, entre outras, não são apoiadas pela Matrioshka.
No ambiente de nuvens computacionais, capturar a proveniência distribuída de um workflow também é um desafio ainda em aberto (OLIVEIRA et al., 2010a).
Para a Matrioshka ser utilizada nas nuvens, foi necessário adaptá-la para os modelos de computação (IaaS, SaaS e DaaS) oferecidos pelos provedores de nuvens. A arquitetura da Matrioshka é composta por três componentes: Provenance Broker, Provenance Eavesdrop e o repositório de metadados de proveniência. Estes componentes operam no ambiente distribuído. No entanto, para que a Matrioshka opere no ambiente de nuvem surge a necessidade não só de alterar os três componentes principais da arquitetura original, como também agregar novos componentes, o Dispatcher e o Execution Broker, e criar o conceito de manifestos, os quais são arquivos no formato XML que permitem ao executor do workflow no ambiente de nuvem
17 configurar o ambiente, o experimento e as atividades que serão executadas. O Dispatcher foi criado para realizar a execução de uma determinada atividade do workflow no ambiente de nuvem. O Execution Broker foi criado para controlar a execução das atividades no ambiente de nuvem e sincronizá-las com o ambiente local, função desempenhada pelo escalonador do cluster ou grades computacionais na arquitetura original da Matrioshka, o qual não existe no ambiente de nuvem. Todos os componentes da arquitetura Matrioshka foram desenvolvidos na linguagem Java e o modelo de dados foi instanciado no SGBD relacional MySQL.
3.2 Arquitetura
A arquitetura proposta para a extensão da Matrioshka no ambiente de nuvens (PAULINO et al., 2009, 2010, 2011) possui dois novos componentes incorporados em relação a sua arquitetura original, o primeiro componente tem como função invocar a execução da atividade que será realizada no ambiente de nuvens de dentro do fluxo de execução local do workflow (Dispatcher), e o segundo componente é o responsável por gerenciar essa execução (Execution Broker). Além desses componentes existem outros dois nativos da arquitetura original, o Provenance Eavesdrop, responsável por coletar os metadados de proveniência gerados pela execução das atividades do workflow nas instâncias da nuvem, e o Provenance Broker, que tem a função de persistir esses metadados coletados no modelo de dados estendido seguindo a recomendação do OPM versão 1.1 para armazenar metadados específicos do ambiente de nuvem. Todos os componentes da arquitetura proposta foram desenvolvidos utilizando a linguagem Java e compilados no formato JAR, o que facilita a execução dos mesmos em qualquer sistema operacional.
O Execution Broker, Provenance Broker e o Provenance Eavesdrop são os componentes que trabalham no ambiente de nuvem, já o Dispatcher é o componente que trabalha na máquina local onde o workflow é gerenciado pelo SGWfC.
A comunicação entre o ambiente local de execução do workflow e o ambiente de nuvens é realizada através dos arquivos de manifesto, os quais são: o arquivo de manifesto de configuração do ambiente da nuvem, o manifesto com os dados do experimento científico e o manifesto com os dados das atividades que serão executadas em nuvem. A comunicação entre os componentes da Matrioshka é síncrona e utiliza o protocolo SSH através da biblioteca Ganymed (GANYMED, 2011). A Figura 1
18 apresenta a adaptação da arquitetura da Matrioshka proposta para a coleta de metadados de proveniência de workflows executados em ambientes de nuvens. Os componentes da arquitetura apresentada são explicados detalhadamente durante as próximas seções.
Figura 1. Arquitetura Matrioshka adaptada para a captura de proveniência de workflows científicos executados no ambiente de nuvens (PAULINO et al., 2009, 2010, 2011)
3.2.1 Manifestos
Os arquivos de manifestos são usados para três propósitos. Cada propósito é representado por um arquivo de manifesto específico. O primeiro visa especificar as configurações do ambiente de nuvem que não puderam ser capturadas automaticamente (SetupManifest.xml), o segundo especifica os dados do experimento a ser executado (ExperimentManifest.xml) e o terceiro detalha os dados das atividades que são executadas no ambiente de nuvem (ActivityManifest.xml).
As principais vantagens dos arquivos de manifesto são o fato de eles serem tecnologicamente agnósticos e representarem um conjunto de metadados de proveniência prospectiva associada à execução de uma ou mais atividades de um workflow na nuvem. Grande parte desses metadados será armazenada no Repositório de Proveniência da Nuvem pelo Provenance Broker, conforme mostrado na Figura 1.
19 Em seguida vamos detalhar as informações contidas em cada um dos arquivos de manifesto utilizados. Inicialmente vamos detalhar o arquivo SetupManifest.xml. É importante destacar que os dados das instâncias que estão sendo executadas no ambiente de nuvem que o usuário possui acesso e os dados das imagens de instâncias são coletados automaticamente pelo Execution Broker. A Figura 2 é uma representação da estrutura do arquivo SetupManifest.xml.
Figura 2. Estrutura do arquivo de manifesto de configuração da nuvem. SetupManifest.xml O arquivo SetupManifest.xml possui as seguintes informações:
• InstanceConfigurations: Dados de configurações das instâncias da nuvem, como por exemplo, quantidade de memória principal e secundária, arquitetura, capacidade de processamento, etc.
• UserSubscribe: Dados que são utilizados para acesso do usuário no ambiente de nuvem e a quais imagens de instâncias da nuvem o mesmo criou ou possui acesso.
• ConcreteActivities: Dados das atividades concretas do workflow. É importante destacar que os programas que representam essas atividades devem estar instalados previamente no ambiente antes que as mesmas sejam executadas. Nesse elemento do arquivo XML também é especificado em quais imagens esses programas estão instalados.
• ActivityParameter: São especificados os valores dos parâmetros que podem ser informados para as atividades concretas.
• CloudAccess: Nesse elemento do arquivo XML são especificados os dados de acesso necessários para que o usuário possa utilizar os serviços da nuvem, além de informar qual o endereço da instância que está executando o componente Execution Broker.
20 • ProvenanceBroker: Dados para acessar o Repositório de Proveniência da
Nuvem.
A Figura 3 contém a representação da estrutura do arquivo ExperimentManifest.xml, o qual vamos detalhar a seguir.
Figura 3. Estrutura do arquivo de manifesto com a especificação dos dados do experimento.
ExperimentManifest.xml
• CloudProvider: Dados do provedor do ambiente de nuvem e quais imagens de instância estão armazenadas nesse provedor.
• Institution / Laboratory: Dados da instituição / laboratório ao qual o pesquisador que criou ou está executando o experimento está vinculado. • Researcher: Dados pessoais do pesquisador e informa qual o seu usuário
no ambiente de nuvem.
• Experiment: Informações acerca do experimento, como por exemplo, área, referência bibliográfica, data de criação do experimento, etc.
• ResearchProject: Informações acerca do projeto de pesquisa, como por exemplo, pesquisador coordenador, data de início, duração prevista, etc.
21 • AbstractWorkflow: Dados do workflow abstrato, como por exemplo, a qual experimento ele está vinculado, qual pesquisador foi o responsável por sua criação, etc.
• ConcreteWorkflow: Informações sobre o workflow concreto, dentre as quais podemos destacar, qual o pesquisador responsável por sua criação, qual(is) pesquisador(es) tem(têm) permissão para executá-lo, quais atividades concretas (informadas no SetupManifest.xml) fazem parte desse workflow, a qual workflow do ambiente local de execução o workflow executado no ambiente de nuvens está relacionado, etc.
• AbstractActivities: Dados das atividades abstratas que fazem parte desse workflow e qual(is) atividade(s) concreta(s) as representam.
• CloudAccess / ProvenanceBroker: Mesmas funções informadas durante o detalhamento do SetupManifest.xml.
• ProvenanceVT: Dados para acessar o Repositório de Proveniência Local.
Para finalizar os arquivos de manifestos vamos detalhar o ActivityManifest.xml, o qual possui sua estrutura representada na Figura 4. Para cada atividade executada no ambiente de nuvens é criado um arquivo de manifesto ActivityManifest.xml correspondente aos dados dessa atividade.
Figura 4. Estrutura do arquivo de manifesto com a especificação dos dados da atividade a ser executada no ambiente de nuvem. ActivityManifest.xml
• RemoteActivity: Arquivos de entrada e saída da atividade a ser executada no ambiente de nuvem, nome da atividade concreta a ser executada, quantidade de instâncias da nuvem utilizadas na execução da atividade, etc.
• CloudAccess / ProvenanceBroker: Mesmas funções informadas durante o detalhamento do SetupManifest.xml.
22 Todos os arquivos de manifesto são enviados para o ambiente de nuvens usando o protocolo de comunicação SCP. Com isso o Execution Broker realiza a leitura desses arquivos e, posteriormente, o Provenance Broker realiza a inserção dos dados lidos a partir do SetupManifest.xml e do ExperimentManifest.xml no Repositório de Proveniência da Nuvem. Os dados informados no ActivityManifest.xml são usados para executar as atividades usando os arquivos de entrada e na quantidade de instâncias informadas pelo usuário.
3.2.2 Dispatcher
Inicialmente é necessário determinar qual atividade do workflow deve ser executada na nuvem. A mesma será substituída na modelagem do workflow no SGWfC por um módulo chamado Dispatcher. O Dispatcher é o módulo responsável pela invocação remota dessa atividade na nuvem. É importante destacar que o programa associado a esta atividade deve ser anteriormente instalado nas imagens a partir das quais são criadas as instâncias a que o usuário possui acesso na nuvem. O Dispatcher recebe como parâmetro de entrada um dos seguintes arquivos de manifesto: SetupManifest.xml, ExperimentManifest.xml ou ActivityManifest.xml, os quais são preenchidos conforme descrito na seção 3.2.1.
O Dispatcher realiza a comunicação e o envio dos arquivos de manifesto para o componente Execution Broker, o qual é executado no ambiente de nuvem, fazendo uso respectivamente dos protocolos de comunicação SSH e SCP.
A Figura 5 mostra como é realizada a substituição de uma atividade executada localmente para a execução da mesma no ambiente de nuvem em um workflow para mineração de texto (OLIVEIRA et al., 2007) definido no SGWfC VisTrails.
23 Figura 5. Substituição da atividade executada localmente pelo Dispatcher no VisTrails
Uma outra função do Dispatcher é coletar do Repositório de Proveniência Local do SGWfC o identificador do workflow que está sendo executado e armazená-lo no ExperimentManifest.xml (tag ConcreteWorkflow). Esse identificador é utilizado pelas consultas de proveniência para realizar o relacionamento dos dados armazenados nos dois repositórios de proveniência, tanto o local quanto o da nuvem.
3.2.3 Execution Broker
O Execution Broker é instalado em uma instância do ambiente de nuvem e possui como funções disparar a execução da atividade nas instâncias da nuvem a que o usuário possui acesso e na quantidade que foi informada no arquivo de manifesto ActivityManifest.xml invocando o componente Provenance Eavesdrop, realizar a leitura dos arquivos de manifesto SetupManifest.xml e ExperimentManifest.xml para que os dados dos mesmos sejam armazenados no Repositório de Proveniência da Nuvem ou no banco de dados de Configuração e validar os dados de segurança do usuário para acesso ao ambiente de nuvem no banco de dados de Configuração. Esse banco de dados, conceitualmente explicando, é diferente do Repositório de Proveniência da Nuvem, porém, ambos são implementados em um mesmo banco de dados físico, visto que essas informações de Configuração do ambiente de nuvem podem ser usadas como metadados de proveniência.
O Execution Broker utiliza threads para invocar a execução de uma atividade em mais de uma instância do ambiente de nuvem simultaneamente.
24 Quando a execução da atividade é concluída nas instâncias em que foi disparada, o Execution Broker repassa essa informação ao Dispatcher para que o fluxo de execução local do workflow no SGWfC continue normalmente.
3.2.4 Provenance Broker
O Provenance Broker, assim como o Execution Broker, também é instalado em uma instância no ambiente de nuvem, geralmente na mesma instância do Execution Broker, mas não existem impedimentos para a instalação desse componente em qualquer outra instância do ambiente de nuvem. A função do Provenance Broker é persistir no Repositório de Proveniência da Nuvem e no banco de dados de Configuração os metadados capturados pelo Provenance Eavesdrop durante a execução das atividades na instância ou pelo Execution Broker durante a leitura dos arquivos de manifesto.
O Provenance Broker é um componente da arquitetura original da Matrioshka, no qual foi necessário realizar algumas alterações, as quais foram basicamente a adequação do componente para trabalhar como um serviço disponibilizado no ambiente de nuvem, acessado tanto pelo Execution Broker quanto pelo Provenance Eavesdrop.
3.2.5 Provenance Eavesdrop
O Provenance Eavesdrop é o componente responsável por executar a atividade e capturar os metadados de proveniência gerados durante essa execução em cada uma das instâncias onde as atividades estão sendo executadas. O Provenance Eavesdrop é o componente da arquitetura que interage diretamente com a instância onde ocorre a execução da atividade, além de interagir com o Execution Broker, mantendo-o informado sobre o andamento da execução da atividade e com o Provenance Broker enviando os metadados de proveniência gerados por essa execução. É importante destacar que a instalação do Provenance Eavesdrop é obrigatória em todas as instâncias do ambiente de nuvem que são utilizadas para executar as atividades. Geralmente essa instalação é realizada na imagem utilizada para a criação dessas instâncias, facilitando assim a alocação de novas instâncias no ambiente de nuvem.
O Provenance Broker e o Provenance Eavesdrop trabalham com dados produzidos no ambiente de nuvem que podem ser originados de diversas fontes, como
25 por exemplo, processos em execução, arquivos utilizados ou produzidos ou informações sobre as instâncias.
Assim como o Provenance Broker, o Provenance Eavesdrop também é um componente da arquitetura original da Matrioshka, porém, pelo fato do mesmo interagir diretamente com as instâncias da nuvem foram realizadas nesse componente e no Repositório de Proveniência da Nuvem as principais adaptações necessárias para o funcionamento da arquitetura proposta.
3.2.6 Repositório de Proveniência da Nuvem
A Matrioshka foi adaptada para o ambiente de nuvens com um novo modelo de metadados de proveniência motivado pelas diferenças dos dados disponíveis em clusters e grades computacionais. Como exemplo de algumas dessas diferenças, podemos citar o fato de que as nuvens são fortemente baseadas nos conceitos de virtualização de recursos, onde um cientista pode acessar uma ou mais contas em diferentes provedores de serviço de nuvem que provêem diferentes tipos de instâncias no que se refere à configuração do hardware e software. Além disto, é necessário registrar em qual instância os produtos de dados das atividades do workflow se encontram, quais foram os recursos consumidos, versão dos programas utilizados, dentre outros.
Na proposta original do modelo de dados da Matrioshka havia metadados tais como nós do cluster e detalhes do jobs, os quais eram coletados do ambiente de clusters ou grades computacionais, de forma a descrever o ambiente de execução. Além disso, não havia correlação com a atual versão do OPM. Entretanto, ao desenvolvermos a adaptação da Matrioshka para o ambiente de nuvem, muitos destes metadados perderam o sentido ou devem ser representados de maneira diferente. Por exemplo, o conceito de nó é substituído por máquinas virtuais (instâncias) disponibilizadas pelos provedores de nuvens computacionais e cada instância pode ser diferente da outra no que se refere ao hardware e ao software, pois, o ambiente de nuvens é altamente heterogêneo. Para garantir a reprodutibilidade do experimento é essencial que todos os metadados que descrevem o ambiente de execução e os parâmetros de entrada das atividades do workflow sejam coletados. Visando isso, essa dissertação propõe um novo modelo de dados a ser utilizado pela Matrioshka no ambiente de nuvens. A Figura 6 apresenta esse modelo de dados de proveniência adotado na adaptação da Matrioshka para o ambiente
26 de nuvens. Ele é representado como um diagrama de classes UML e é resultado de um levantamento sobre quais metadados de proveniência podem ser capturados pelos componentes Provenance Eavesdrop e Execution Broker. O modelo de dados é composto por quatro partes principais:
(i) elementos que representam os processos que serão distribuídos nas instâncias na nuvem, por exemplo, as atividades do workflow;
(ii) elementos que representam os cientistas, associados a execução e definição do workflow;
(iii) elementos que representam os artefatos e recursos computacionais utilizados em determinada execução do workflow, e por fim;
(iv) elementos que representam informações relacionadas com a temporalidade do workflow e suas atividades.
27 Uma vez que o modelo de dados seguiu a recomendação do OPM, temos que, as classes na cor amarela correspondem à representação conceitual de um Artefato-OPM, possuindo a mesma semântica, isto é, representam estruturas digitais em sistemas de computação (i.e. parâmetros, bancos de dados, arquivos, instâncias, entre outros). As classes na cor verde são mapeadas como um Processo-OPM. Um processo representa uma ou mais ações que utilizam ou atuam sobre artefatos e produzem novos artefatos. As classes na cor azul representam um Agente-OPM. Um agente é um elemento que catalisa, possibilita, controla ou afeta a execução de um processo. As classes na cor alaranjada são mapeadas como Papéis-OPM. Um papel determina e correlaciona a função de um agente ou artefato em um processo. A classe matri_execution representa o momento das execuções de um processo na nuvem, com a respectiva instância onde ocorreu a execução e o usuário que realizou a mesma.
A utilização desse modelo de dados para armazenar os metadados de proveniência coletados no ambiente de nuvens relacionado ao Repositório de Proveniência Local pode responder várias consultas a serem realizadas pelos cientistas sobre o experimento executado, como por exemplo, “Quantos workflows concretos foram necessários para mapear o workflow abstrato X?”, “Em qual diretório e de qual instância foram armazenados os arquivos de saída da atividade Y?”, “Qual o diretório da máquina local, onde está instalado o SGWfC, que armazena o arquivo de manifesto utilizado para executar a atividade Z?”. No Capítulo 4, onde é descrito o estudo de caso para validar a arquitetura proposta para captura de proveniência, são mostradas as respostas a essas e outras possíveis consultas que podem ser realizadas pelos cientistas.
3.3 Bibliotecas utilizadas na implementação
Os componentes da arquitetura descrita nas seções anteriores utilizam as seguintes bibliotecas para facilitar o desenvolvimento de algumas funções:
a) AWS SDK for Java 1.2.1: Biblioteca desenvolvida pela Amazon para disponibilizar aos desenvolvedores todas as rotinas que podem ser realizadas no ambiente de nuvem da Amazon através da linguagem Java, como por exemplo, listar todas as instâncias que um usuário da nuvem da Amazon possui.
b) Ganymed SSH-2 for Java: Biblioteca que possui funções para utilizar os protocolos de comunicação SSH e SCP para, por exemplo, acessar as instâncias na nuvem ou enviar arquivos de manifesto.
28 c) XStream 1.1.3: Biblioteca para a leitura e escrita de arquivos XML, a qual é
utilizada para trabalhar com os arquivos de manifesto.
d) Driver JDBC para o MySQL 5.1.6: Biblioteca utilizada para realizar a conexão com o SGBD MySQL, o qual armazena o Repositório Local e da Nuvem de Proveniência.
É importante destacar que todas as bibliotecas usadas na arquitetura proposta podem ser utilizadas gratuitamente.
3.4 Considerações finais
Durante a implementação dos componentes da arquitetura proposta surgiram dificuldades, dentre as quais, destacamos o levantamento de quais metadados deveriam ser coletados no ambiente de nuvem e como ocorreria a comunicação entre os componentes.
O levantamento dos metadados a serem coletados foi direcionado pela ontologia de proveniência proposta por (CRUZ, 2011), a qual norteou a escolha desses metadados. Quanto à comunicação entre os componentes da arquitetura, as dificuldades encontradas foram com relação à comunicação do ambiente local (Dispatcher) com o ambiente de nuvem (Execution Broker, Provenance Broker e o Provenance Eavesdrop). Para solucionar esse problema foram utilizados os protocolos de comunicação SSH e SCP, os quais permitem a execução de comandos remotamente e a transmissão de arquivos.
29
Capítulo 4 - Avaliação da arquitetura proposta
A arquitetura proposta nessa dissertação foi avaliada utilizando um experimento real da área de bioinformática. Todas as atividades que fazem parte do workflow que representa esse experimento foram executadas no ambiente de nuvem, favorecendo assim a verificação do funcionamento da coleta dos metadados de proveniência dessas atividades e a posterior consulta aos mesmos, integrando-os com os dados da proveniência local coletada pelo SGWfC.
O OrthoSearch possui como principal função detectar homologias distantes em protozoários (CRUZ et al., 2008b). Inicialmente esse workflow foi desenvolvido utilizando scripts na linguagem de programação Perl. Esse workflow tem sido utilizado pelo consórcio BiowebDB (www.biowebdb.org).
4.1 OrthoSearch
A grande maioria das doenças negligenciadas pelas empresas farmacêuticas afetam, principalmente, as populações de baixa renda de países em desenvolvimento na Ásia, África e América do Sul. Essas populações não possuem condições financeiras de adquirir medicamentos, por isso, não são prioridade para as empresas farmacêuticas. Esse fato vem chamando a atenção de um número cada vez maior de cientistas da comunidade científica internacional, pois, existe uma imensa necessidade de pesquisa dessas doenças para criação de remédios visando minimizar a contaminação e a morte de milhões de seres humanos.
A maioria dessas doenças é causada por cinco protozoários, Trypanosoma cruzi, Trypanosoma brucei, Leishmania major, Plasmodium falciparum e Entamoeba histolytica.
Para explorar as informações e conhecer melhor esses cinco protozoários são usados modelos computacionais, objetivando descobrir maneiras eficientes e de baixo custo para o controle das doenças causadas por eles.
O OrthoSearch foi criado para facilitar as tarefas de pesquisa, análise e apresentação das semelhanças entre estruturas de diferentes organismos que possuem a mesma origem ortogenética e filogenética desses cinco protozoários, utilizando o “Ptn DB”, um repositório de proteínas (arquivo FASTA) de cada protozoário, e os
