captura de dados de proveniÊncia de workflows...
TRANSCRIPT
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, 47 p.: 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
4.3 Configuração do experimento.......................................................................... 32
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
Figura 8. Workflow utilizado para avaliação da arquitetura proposta............................ 33
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
Quadro 7. Resultado da consulta de proveniência (vi) ................................................. 40
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.
Figura 6. Modelo de dados de proveniência para o ambiente de nuvens
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
30
comparando com os arquivos contidos no “COGs DB”, copiados previamente do
repositório do National Center for Biotechnology Information
(www.ncbi.nlm.nih.gov/COG). Esses arquivos COGs armazenam genes ortólogos, ou
seja, que possuem um ancestral em comum, das vias metabólicas, as quais
desempenham um papel fundamental na vida dos protozoários. Esses serão os dados de
entrada do OrthoSearch.
A Figura 7 mostra o workflow OrthoSearch completo, porém, no experimento
dessa dissertação estaremos utilizando apenas uma parte desse workflow, visto que o
foco é a coleta de proveniência e apenas com algumas das atividades realizadas por esse
workflow foi possível verificar o funcionamento da arquitetura proposta.
Além dos dados de entrada, “COGs DB” e “Ptn DB”, explicados anteriormente,
foram utilizados o programa MAFFT e o pacote de programas HMMER, com exceção
do programa HMMPFAM. O MAFFT otimiza o alinhamento dos genes ortólogos com
base em propriedades físicas dos aminoácidos, reduzindo o tempo de processamento nas
demais atividades do workflow. O HMMER é um conjunto de programas que tem a
função de descobrir as melhores correspondências entre os genes dos protozoários com
os genes armazenados nos arquivos COGs.
Na Figura 7 é demarcada, com um retângulo de linha contínua, a parte do
workflow OrthoSearch que será utilizada no experimento dessa dissertação para avaliar
a arquitetura proposta.
Figura 7. Workflow OrthoSearch (CRUZ et al., 2008b)
31
4.2 Configuração do ambiente
O ambiente de nuvem inicialmente utilizado para realização dos testes com os
módulos desenvolvidos foi o da IBM, que possui o mesmo modelo de acesso e controle
utilizado pela nuvem da Amazon. Já o estudo de caso apresentado nessa dissertação
utilizando o experimento OrthoSearch foi realizado na nuvem da Amazon, utilizando a
Elastic Compute Cloud (EC2), o ambiente de nuvem propriamente dito da Amazon, e o
Simple Storage Service (S3), o serviço de armazenamento disponibilizado pela
Amazon. É importante destacar que a nuvem da Amazon é comercial e, portanto, a
cobrança é realizada de acordo com os recursos utilizados. Porém, existem alguns
softwares livres, como por exemplo, o Eucalyptus (NURMI et al., 2008) que permitem
a instalação e configuração de um ambiente de nuvem utilizando recursos
computacionais próprios e que devido a isso não são realizadas cobranças a cada
utilização do ambiente, como ocorre nos ambientes de nuvens comerciais.
No ambiente de nuvem da Amazon existem vários tipos de configuração de
hardware de instâncias, os quais variam de acordo com a imagem utilizada para criar a
instância. Essa imagem é criada utilizando o serviço Amazon Machine Image (AMI)
com o intuito de armazenar os softwares instalados na instância e evitar perda de tempo
na instalação desses softwares toda vez que uma instância é criada. Essa imagem é
armazenada dentro do próprio ambiente de nuvem da Amazon, em um serviço chamado
Elastic Block Store (EBS). As imagens de instâncias utilizadas nesse experimento são
as seguintes:
(i) ami-16c3367f: Nessa imagem está instalado o sistema operacional Ubuntu
10.10, o SGBD MySQL 5.1.41, para armazenamento do Repositório de
Proveniência da Nuvem, os componentes da arquitetura proposta Execution
Broker e Provenance Broker e o Java Runtime Environment 6 para execução
desses componentes.
(ii) ami-e2c3368b: Nessa imagem está instalado o sistema operacional Ubuntu
10.10, o componente da arquitetura proposta Provenance Eavesdrop, o Java
Runtime Environment 6 para execução desse componente, o sistema de arquivos
S3QL 1.0.1 (S3QL, 2011), o qual é utilizado para mapear os dados armazenados
no serviço Amazon Simple Storage Service (S3) onde estão os dados de
entrada/saída utilizados/gerados pelo workflow e os seguintes programas usados
pelas atividades do workflow: MAFFT 6.717b e o pacote de programas
32
HMMER 2.3.2, o qual é composto pelo HMMBUILD, HMMCALIBRATE e
HMMSEARCH.
As duas imagens são executadas na arquitetura i386 e ocupam cada uma 15 Gb de
espaço no EBS. Os tipos de configurações de hardware disponíveis e o preço de
utilização por hora para as imagens acima durante a execução do experimento realizado
no dia 30/07/2011 foram os seguintes:
Quadro 1. Configuração de hardware e preços de utilização dos tipos de instâncias disponíveis
Tipo da
instância Memória
Disco
rígido
Unidades de
processamento
Cores de
processamento Arquitetura Preço
Small 1.7 Gb 160
Gb
1 ECU* 1 Core 32 bits $0,085/h
Medium 1.7 Gb 350
Gb
5 ECU* 2 Cores 32 bits $0,17/h
Micro 613 Mb 15 Gb 1 ECU* 1 Core 32 ou 64
bits
$0,02/h
*ECU (EC2 Compute Unit): 1 ECU é equivalente a capacidade de processamento de
1.0 a 1.2 GHz.
Dentre os tipos de instâncias disponíveis para serem utilizadas nesse experimento
utilizamos o tipo “Micro”. Esse tipo foi escolhido basicamente pelo baixo custo de
utilização e pelo fato do experimento proposto não levar em consideração questões
relativas ao desempenho.
4.3 Configuração do experimento
O workflow OrthoSearch foi definido no SGWfC VisTrails, conforme mostrado na
Figura 8. As quatro primeiras atividades do workflow foram utilizadas para armazenar
no Repositório de Proveniência da Nuvem os metadados relativos à configuração do
ambiente, através do arquivo de manifesto SetupManifest.xml, além dos dados coletados
do ambiente de nuvem pelo Execution Broker, e a configuração do experimento, através
do arquivo de manifesto ExperimentManifest.xml. As outras oito atividades representam
os programas utilizados pelo workflow, com seus respectivos arquivos de manifesto
ActivityManifest.xml, para processar os arquivos de entrada. Todas as atividades, tanto
as de configuração do ambiente quanto do experimento, e as atividades do workflow
OrthoSearch são executadas no ambiente de nuvem da Amazon.
33
Figura 8. Workflow utilizado para avaliação da arquitetura proposta
A execução do experimento foi realizada utilizando seis instâncias do tipo
“Micro”, sendo cinco instanciadas a partir da imagem “ami-e2c3368b”, a qual possui a
instalação dos programas utilizados pelas atividades do workflow OrthoSearch. Nessas
instâncias foram mapeados os diretórios armazenados no S3 usando o sistema de
arquivos S3QL. Esses diretórios foram utilizados para armazenar todos os arquivos de
entrada/saída usados/gerados por esse workflow. Cada instância possui um diretório
específico. A sexta instância foi criada a partir da imagem “ami-16c3367f”, onde foi
armazenado o Repositório de Proveniência da Nuvem. Essa instância foi a responsável
por receber as informações de execuções e metadados de proveniência gerados pelas
34
cinco instâncias que executam as atividades do workflow no ambiente de nuvem e
manter a conexão SSH com o componente Dispatcher no ambiente local de execução
do workflow. Ao finalizar cada uma das atividades invocadas pelo Dispatcher no
ambiente de nuvem, o fluxo de execução do workflow retorna para o ambiente local e
assim outra atividade é invocada para ser executada, tudo isso controlado pelo SGWfC
VisTrails.
Inicialmente dentro do diretório mapeado em cada uma das instâncias, existem
duzentos e vinte e quatro arquivos COGs e um arquivo FASTA, um para cada um dos
cinco protozoários utilizados no experimento. Esses arquivos estão contidos no “Ptn
DB”. Por esse motivo foram instanciadas cinco instâncias, cada uma para executar o
experimento utilizando um arquivo FASTA diferente.
Abaixo é mostrado um exemplo do fluxo de execução realizado pelo workflow
OrthoSearch usando o arquivo “COG0022” e o gene do protozoário Entamoeba
histolytica (ehisto.100.fasta) através de linhas de comando para executar os programas:
(i) mafft COG0022 > COG0022.mafft
(ii) hmmbuild COG0022.hmm COG0022.mafft
(iii) hmmcalibrate COG0022.hmm
(iv) hmmsearch -E 0.1 COG0022.hmm ehisto.100.fasta > cog0022_ehisto.txt
Como é possível observar o arquivo de saída de uma atividade é utilizado como
arquivo de entrada na atividade posterior, com exceção da última atividade,
HMMSEARCH. Nessa atividade além do arquivo de saída gerado pela atividade
anterior, também é utilizado como arquivo de entrada um segundo arquivo, o FASTA
referente ao gene do protozoário a ser comparado. É importante destacar também que
nessa última atividade é utilizado o parâmetro “-E 0.1”. Esse é um parâmetro de corte
utilizado para definir o grau de igualdade entre os genes contidos nos arquivos COGs
com os genes do protozoário. Quanto menor esse parâmetro maior o grau de igualdade
dessas proteínas. Esse parâmetro varia de acordo com a necessidade da pesquisa que
está sendo realizada no momento.
O workflow executado com as configurações do ambiente descritas na seção 4.2
foi iniciado às 15:41:43 do dia 30/07/2011 e sua execução foi concluída às 08:03:32 do
dia 08/08/2011. A atividade HMMSEARCH foi a mais demorada, iniciando às 00:21:13
do dia 01/08/2011 e sendo finalizada às 08:03:32 do dia 08/08/2011. Importante
destacar que esses tempos são relativos à execução das atividades nas cinco instâncias.
Todos esses dados, além de todos os arquivos gerados, localização desses arquivos,
35
instâncias que foram utilizadas na execução, usuário responsável pela execução do
workflow, etc estão armazenados no Repositório de Proveniência da Nuvem.
4.4 Consultas à proveniência
Com o intuito de mostrar que os metadados coletados pela arquitetura proposta
são capazes de responder a uma série de possíveis consultas que podem ser necessárias
para permitir a reprodução do experimento por outros cientistas ou para que o próprio
cientista que executou o experimento tenha dados para melhor entender os resultados
obtidos, são propostas algumas consultas que podem ser respondidas utilizando o
Repositório de Proveniência Local e da Nuvem. Essas consultas foram divididas em três
categorias, consulta de proveniência prospectiva, proveniência retrospectiva e consultas
que utilizam os dados da proveniência local e da nuvem.
Essas consultas foram escritas em linguagem natural e transformadas para a
linguagem SQL, para que fosse possível retornar os dados para respondê-la a partir do
SGBD MySQL. Abaixo são mostradas duas possíveis consultas que podem ser
realizadas utilizando os metadados de proveniência prospectiva armazenados no
Repositório da Nuvem.
(i) Quais instâncias do ambiente de nuvem estão disponíveis para executar o
workflow “ortho.vt”?
SELECT mi.Instance,
mi.PublicDNS,
mi.Allocated
FROM matrioshka.matri_workflow_concrete mwc
INNER JOIN matrioshka.matri_activity_concrete mac
ON mac.WfID=mwc.WfID
INNER JOIN matrioshka.matri_activity_image mai
ON mai.ActivityID=mac.ActivityID
INNER JOIN matrioshka.matri_instance mi
ON mi.ImageID=mai.ImageID
WHERE mwc.Name="ortho.vt"
AND mi.Allocated=0
GROUP BY mi.Instance;
36
Quadro 2. Resultado da consulta de proveniência (i)
Instance PublicDNS Allocated
i-2715e746 ec2-174-129-145-195.compute-1.amazonaws.com 0 i-311be950 ec2-50-19-23-198.compute-1.amazonaws.com 0 i-471ae826 ec2-107-20-31-160.compute-1.amazonaws.com 0 i-9d1be9fc ec2-50-17-169-171.compute-1.amazonaws.com 0 i-a91ae8c8 ec2-50-19-146-109.compute-1.amazonaws.com 0
O Quadro 2 mostra a relação de todos os endereços das instâncias do ambiente de
nuvem habilitadas para executar o workflow concreto “ortho.vt” desenvolvido no
SGWfC VisTrails, ou seja, essas instâncias possuem os programas necessários para
executar esse workflow e não estão sendo utilizadas em outra execução de workflow no
momento.
(ii) Quais os nomes e as versões dos programas utilizados para executar as
atividades do workflow “ortho.vt”?
SELECT mac.Name,
mac.Version
FROM matrioshka.matri_workflow_concrete mwc
INNER JOIN matrioshka.matri_activity_concrete mac
ON mac.WfID=mwc.WfID
WHERE mwc.Name="ortho.vt";
Quadro 3. Resultado da consulta de proveniência (ii)
Name Version
mafft 6.717b hmmbuild 2.3.2 hmmcalibrate 2.3.2 hmmsearch 2.3.2
O Quadro 3 mostra os programas utilizados durante a execução do workflow
“ortho.vt” com suas respectivas versões a fim de permitir a um cientista que esteja
reproduzindo o experimento utilizar as mesmas versões dos programas utilizados na
execução a ser reproduzida em seu ambiente.
Abaixo são mostradas duas possíveis consultas utilizando os metadados de
proveniência retrospectiva armazenados no Repositório de Proveniência da Nuvem.
37
(iii) Quais foram os parâmetros utilizados para executar cada uma das atividades do
workflow “ortho.vt”? O que cada um desses parâmetros representa?
SELECT mac.Name,
map.ParamValue,
map.ParamDescription
FROM matrioshka.matri_workflow_concrete mwc
INNER JOIN matrioshka.matri_activity_concrete mac
ON mac.WfID=mwc.WfID
LEFT JOIN matrioshka.matri_activity_parameter map
ON map.ActivityID=mac.ActivityID
WHERE mwc.Name="ortho.vt";
Quadro 4. Resultado da consulta de proveniência (iii)
Name ParamValue ParamDescription
mafft null null
hmmbuild null null
hmmcalibrate null null
hmmsearch -E 0.1 Parâmetro de corte
O Quadro 4 mostra todos os programas executados pelo workflow “ortho.vt” e os
respectivos parâmetros utilizados durante suas execuções. Os programas que são
executados sem parâmetros possuem na coluna “ParamValue” o valor null.
(iv) Qual a configuração da instância utilizada para executar a atividade
HMMSEARCH do workflow “ortho.vt”?
38
SELECT mic.*
FROM matrioshka.matri_workflow_concrete mwc
INNER JOIN matrioshka.matri_activity_concrete mac
ON mac.WfID=mwc.WfID
INNER JOIN matrioshka.matri_execution me
ON me.ActivityID=mac.ActivityID
INNER JOIN matrioshka.matri_instance mi
ON mi.InstanceID=me.InstanceID
INNER JOIN matrioshka.matri_instance_configuration mic
ON mic.ID=mi.ID
WHERE mwc.Name="ortho.vt"
AND mac.Name="hmmsearch"
GROUP BY mic.Type;
Quadro 5. Resultado da consulta de proveniência (iv)
ID Memory Disk Type CPU_Units CPU_Cores Supported_Platform
9 613 Mb 15 Gb
Micro 1 ECU 1 Core 32 ou 64 bits
O Quadro 5 mostra as configurações de hardware da instância utilizada na
execução da atividade HMMSEARCH do workflow “ortho.vt”, permitindo assim ao
pesquisador conhecer qual o ambiente computacional utilizado na execução dessa
atividade.
Para finalizar as possíveis consultas que podem ser realizadas utilizando os
metadados de proveniência capturados pela Matrioshka, propomos duas consultas que
utilizem, ao mesmo tempo, os metadados armazenados nos dois Repositórios de
Proveniência, o Local e o da Nuvem.
(v) Qual a versão do VisTrails e o usuário local da máquina onde está instalado o
SGWfC foram utilizados na execução das atividades do workflow “ortho.vt” na
instância i-2715e746?
39
SELECT mac.Name,
we.vt_version,
we.user
FROM matrioshka.matri_instance mi
INNER JOIN matrioshka.matri_execution me
ON me.InstanceID=mi.InstanceID
INNER JOIN matrioshka.matri_activity_concrete mac
ON mac.ActivityID=me.ActivityID
INNER JOIN matrioshka.matri_workflow_concrete mwc
ON mwc.WfID=mac.WfID
INNER JOIN vt.workflow_exec we
ON we.entity_id=mwc.WfVtID
WHERE mi.Instance="i-2715e746"
AND mwc.Name="ortho.vt"
GROUP BY mac.Name;
Quadro 6. Resultado da consulta de proveniência (v)
Name vt_version user
hmmbuild 1.5 kdu hmmcalibrate 1.5 kdu hmmsearch 1.5 kdu mafft 1.5 kdu
O Quadro 6 mostra a partir de qual versão do SGWfC VisTrails as atividades do
workflow “ortho.vt” foram invocadas e qual o usuário da máquina local realizou essa
invocação para que as atividades fossem executadas na instância do ambiente de nuvem.
(vi) Qual a versão do esquema do banco de dados utilizado pelo VisTrails para
armazenar os metadados de proveniência local gerados pelo experimento
OrthoSearch on the Clouds?
40
SELECT w.version
FROM matrioshka.matri_experiment me
INNER JOIN matrioshka.matri_workflow_abstract mwa
ON mwa.ExperimentID=me.ExperimentID
INNER JOIN matrioshka.matri_workflow_concrete mwc
ON mwc.WfAbsID=mwa.WfAbsID
INNER JOIN vt.workflow w
ON w.id=mwc.WfVtID
WHERE me.Name="OrthoSearch on the Clouds";
Quadro 7. Resultado da consulta de proveniência (vi)
version
1.0.2
O Quadro 7 mostra a versão do esquema do banco de dados utilizado para
armazenar os metadados de proveniência gerados no experimento OrthoSearch on the
Clouds no Repositório de Proveniência Local do SGWfC VisTrails.
As consultas realizadas evidenciam o potencial da arquitetura no que se refere aos
metadados de proveniência coletados no ambiente de nuvens computacionais, os quais
também podem ser utilizados juntamente com os metadados de proveniência do
ambiente local onde o SGWfC está instalado, conforme demonstrado na consulta (vi).
Através dos repositórios de metadados de proveniência existentes na arquitetura
proposta, consultas podem ser respondidas utilizando tanto os metadados de
proveniência prospectiva quanto retrospectiva.
41
Capítulo 5 - Conclusão
Concluindo a dissertação, nesse capítulo são apresentadas as principais
contribuições da arquitetura proposta para a coleta de proveniência no ambiente de
nuvens computacionais, além das suas limitações e os trabalhos que ainda precisam ser
realizados.
5.1 Contribuições A arquitetura proposta traz como principal contribuição para a comunidade
científica a possibilidade da execução de experimento científicos in silico mapeados
como workflows científicos em ambientes de nuvens computacionais, um novo
paradigma de computação que vem sendo largamente utilizado na indústria. Porém, na
execução de experimentos científicos o ambiente de nuvens é ainda pouco utilizado.
Isso ocorre principalmente pela carência nesses ambientes de um mecanismo para a
coleta de metadados de proveniência.
Para solucionar essa carência é proposta a adaptação da arquitetura da Matrioshka
para esse novo ambiente, a qual inicialmente foi proposta para o ambiente de clusters e
grades computacionais.
Com a utilização dessa nova arquitetura proposta, um grande número de cientistas
que não possuem recursos para montar ambientes computacionais geralmente caros e
complexos, como clusters e grades computacionais, ou desejem realizar experimentos
in silico exploratório, o que não justifica a instalação e configuração desses ambientes,
podem utilizar o ambiente de nuvens computacionais e contar com um mecanismo que
vai garantir a reprodutibilidade e a validade desses experimentos perante outros
cientistas. A proposta dos serviços de nuvens para workflows científicos e seus
resultados são discutidos em (PAULINO et al., 2011).
Outra contribuição dessa arquitetura é a possibilidade de utilizar os metadados de
proveniência coletados para realizar avaliações de desempenho comparando os
experimentos executados no ambiente de nuvem com os experimentos executados em
outros ambientes, locais ou distribuídos.
O modelo de dados do Repositório de Proveniência da Nuvem também é uma
contribuição que merece destaque, visto que, através do levantamento bibliográfico
42
realizado não foi localizado nenhum modelo de dados com o propósito de armazenar os
metadados de proveniência, tanto prospectiva quanto retrospectiva, para o ambiente de
nuvens. Esse modelo de dados pode ser utilizado por outros mecanismos de coleta de
proveniência da nuvem, ou estendido para armazenar também proveniência do ambiente
local de execução do SGWfC, levando em consideração que o mesmo segue as
recomendações do OPM.
5.2 Limitações do trabalho
Existem algumas limitações na arquitetura apresentada nessa dissertação. A
primeira se refere a criação dos manifestos utilizados para informar os dados de
configuração do ambiente de nuvem utilizado (SetupManifest.xml), do experimento
(ExperimentManifest.xml) e das atividades do workflow executadas no ambiente de
nuvem (ActivityManifest.xml). Na arquitetura proposta os dados contidos nesses
manifestos são incluídos manualmente pelo cientista o que pode ser uma tarefa
trabalhosa.
A segunda limitação se refere à ausência de uma interface para o cientista realizar
consultas de proveniência na base de metadados capturados do ambiente de nuvem e
local, simultaneamente. Atualmente essas consultas são realizadas utilizando
ferramentas próprias do SGBD MySQL.
A terceira limitação é que a arquitetura proposta foi avaliada apenas no SGWfC
VisTrails. O relacionamento entre o Repositório de Proveniência Local com o
Repositório de Proveniência da Nuvem ocorre utilizando identificadores próprios do
esquema de proveniência do VisTrails.
5.3 Trabalhos futuros
Como trabalhos futuros podem ser criados cartuchos para a geração dos dados
contidos nos arquivos de manifesto. Esses cartuchos podem ser usados para capturar
esses dados de outras ferramentas e gerar automaticamente os arquivos de manifestos
necessários para o funcionamento da arquitetura proposta. Além disso, pode ser criada
uma ferramenta para a realização de consultas de proveniência mais intuitiva sem a
necessidade do cientista interagir com ferramentas próprias do SGBD.
43
Um outro trabalho futuro a ser realizado é a integração dos repositórios de
proveniência local e da nuvem em um único repositório, com o objetivo de otimizar a
realização de consultas que utilizem os metadados de proveniência coletados nos dois
ambientes.
44
Referências Bibliográficas ALTINTAS, I., BERKLEY, C., JAEGER, E., JONES, M., LUDASCHER, B., MOCK,
S., 2004, "Kepler: an extensible system for design and execution of scientific workflows". In: Scientific and Statistical Database Management, pp. 423-424, Grécia.
AMAZON EC2, Amazon Elastic Compute Cloud. Disponível em: <http://aws.amazon.com/ec2/>. Acesso em: 10 set. 2010.
BARGA, R., GANNON, D., "Scientific versus Business Workflows". In: Workflows for
e-Science, Springer, pp. 9-16, 2007. BUNEMAN, P., KHANNA, S., TAN, W., "Why and Where: A Characterization of
Data Provenance", International Conference on Database Theory, 316-330, 2001
CALLAHAN, S. P., FREIRE, J., SANTOS, E., SCHEIDEGGER, C. E., SILVA, C. T., VO, H. T., 2006, "VisTrails: visualization meets data management". In: SIGMOD, pp. 745-747, Chicago, Illinois, USA.
CRUZ, S., 2011, Uma estratégia de apoio à gerência de dados de proveniência em
experimentos científicos. Tese de D.Sc., COPPE/UFRJ, Rio de Janeiro, RJ, Brazil.
CRUZ, S. M. S. D., BARROS, P. M., BISCH, P. M., CAMPOS, M. L. M., MATTOSO, M., 2008a, "Provenance Services for Distributed Workflows". In: Proceedings
of the 2008 Eighth IEEE International Symposium on Cluster Computing and
the Grid, pp. 526-533 CRUZ, S. M. S. D., BATISTA, V., DÁVILA, A. M. R., SILVA, E., TOSTA, F.,
VILELA, C., CAMPOS, M. L. M., CUADRAT, R., TSCHOEKE, D., et al., 2008b, "OrthoSearch: a scientific workflow approach to detect distant homologies on protozoans". In: Proc. of the ACM SAC, pp. 1282-1286, Fortaleza, Ceara, Brazil.
DAVIDSON, S. B., FREIRE, J., 2008, "Provenance and scientific workflows: challenges and opportunities". In: Proceedings of the 2008 ACM SIGMOD
international conference on Management of data, pp. 1345-1350, Vancouver, Canada.
DEELMAN, E., MEHTA, G., SINGH, G., SU, M., VAHI, K., "Pegasus: Mapping Large-Scale Workflows to Distributed Resources", In: Workflows for e-Science, Springer, pp. 376-394, 2007.
FOSTER, I., ZHAO, Y., RAICU, I., LU, S., 2008, "Cloud Computing and Grid Computing 360-Degree Compared". In: Grid Computing Environments
Workshop, 2008. GCE '08, pp. 10-11. FOSTER, I., KESSELMAN, C., 2004, The Grid: Blueprint for a New Computing
Infrastructure. Morgan Kaufmann. FREIRE, J., KOOP, D., SANTOS, E., SILVA, C. T., 2008, "Provenance for
Computational Tasks: A Survey", Computing in Science and Engineering, v. 10, n. 3, pp. 11-21.
GANYMED, Ganymed SSH-2 for Java. Disponível em: <http://www.ganymed.ethz.ch/ssh2/>. Acesso em: 31 ago. 2011.
GOBLE, C., WROE, C., STEVENS, R., 2003, "The myGrid project: services, architecture and demonstrator". In: Proc. of the UK e-Science All Hands Meeting
45
GROTH, P., DEELMAN, E., JUVE, G., MEHTA, G., BERRIMAN, B., 2009, "Pipeline-centric provenance model". In: Proceedings of the 4th Workshop on
Workflows in Support of Large-Scale Science, pp. 1-8, Portland, Oregon. HEY, T., TANSLEY, S., TOLLE, K., 2009, The Fourth Paradigm: Data-Intensive
Scientific Discovery. Microsoft Research. HOFFA, C., MEHTA, G., FREEMAN, T., DEELMAN, E., KEAHEY, K.,
BERRIMAN, B., GOOD, J., 2008, "On the use of cloud computing for scientific workflows". In: IEEE Fourth International Conference on eScience (eScience
2008), Indianapolis, USA, pp. 7-12 HULL, D., WOLSTENCROFT, K., STEVENS, R., GOBLE, C., POCOCK, M. R., LI,
P., OINN, T., 2006, "Taverna: a tool for building and running workflows of services", Nucleic Acids Research, v. 34, n. 2, pp. 729-732.
IBM SMART BUSINESS DEVELOPMENT & TEST. Disponível em: <https://www-949.ibm.com/cloud/developer/dashboard>. Acesso em: 19 mar. 2010.
JACOB, J. C., KATZ, D. S., BERRIMAN, G. B., GOOD, J. C., LAITY, A. C., DEELMAN, E., KESSELMAN, C., SINGH, G., SU, M., et al., 2009, "Montage: a grid portal and software toolkit for science-grade astronomical image mosaicking", Int. J. Comput. Sci. Eng., v. 4, n. 2, pp. 73-87.
JARRARD, R. D. Scientific Methods. Online book, 2001. Disponível em: <http://emotionalcompetency.com/sci/booktoc.html>. Acesso em: 10 ago. 2011.
KIM, J., DEELMAN, E., GIL, Y., MEHTA, G., RATNAKAR, V., 2008, "Provenance trails in the Wings-Pegasus system", Concurrency and Computation: Practice &
Experience, v. 20 (Apr.), pp. 587-597. KIM, W., KIM, S. D., LEE, E., LEE, S., 2009, "Adoption issues for cloud computing".
In: Proceedings of the 11th International Conference on Information Integration
and Web-based Applications & Services, pp. 3-6, Kuala Lumpur, Malaysia. MATSUNAGA, A., TSUGAWA, M., FORTES, J., "CloudBLAST: Combining
MapReduce and Virtualization on Distributed Resources for Bioinformatics Applications", IEEE eScience 2008, 222-229, 2008.
MATTOSO, M., WERNER, C., TRAVASSOS, G. H., BRAGANHOLO, V., MURTA, L., OGASAWARA, E., OLIVEIRA, D., CRUZ, S. M. S. D., MARTINHO, W., 2010, "Towards Supporting the Life Cycle of Large-scale Scientific Experiments", Int Journal of Business Process Integration and Management, v. 5, n. 1, p. 79-92.
MOREAU, L., FREIRE, J., FUTRELLE, J., MCGRATH, R., MYERS, J., PAULSON, P., "The Open Provenance Model: An Overview", Provenance and Annotation
of Data and Processes, 323-326, 2008. MUNISWAMY-REDDY, K., MACKO, P., SELTZER, M., 2009, "Making a cloud
provenance-aware". In: First workshop on Theory and practice of provenance, pp. 1-10, San Francisco, CA.
NAPPER, J., BIENTINESI, P., 2009, "Can cloud computing reach the top500?". In: Proceedings of the combined workshops on UnConventional high performance
computing workshop plus memory access workshop, pp. 17-20, Ischia, Italy. NURMI, D., WOLSKI, R., GRZEGORCZYK, C., OBERTELLI, G., SOMAN, S.,
YOUSEFF, L., ZAGORODNOV, D., 2008, "The Eucalyptus Open-source Cloud-computing System". In: Proceedings of Cloud Computing and Its
Applications. OLIVEIRA, D., BAIÃO, F., MATTOSO, M., 2007, "MiningFlow: Adding Semantics
to Text Mining Workflows". In: First Poster Session of the Brazilian Symposium
on Databases, pp. 15-18, João Pessoa, PB - Brazil.
46
OLIVEIRA, D., BAIÃO, F., MATTOSO, M., "Towards a Taxonomy for Cloud Computing from an e-Science Perspective", In: Cloud Computing: Principles,
Systems and Applications (to be published), Heidelberg: Springer-Verlag, 2010a. OLIVEIRA, D., OCANA, K., OGASAWARA, E., DIAS, J., BAIÃO, F., MATTOSO,
M., 2011a, "A Performance Evaluation of X-ray Crystallography Scientific Workflow using SciCumulus". In: International Conference on Cloud
Computing, Washington D.C. OLIVEIRA, D., OGASAWARA, E., BAIÃO, F., MATTOSO, M., 2010b,
"SciCumulus: A Lightweigth Cloud Middleware to Explore Many Task Computing Paradigm in Scientific Workflows". In: International Conference on
Cloud Computing, pp. 378 - 385, Miami, FL. OLIVEIRA, D., OGASAWARA, E., OCANA, K., BAIAO, F., MATTOSO, M., "An
Adaptive Parallel Execution Strategy for Cloud-based Scientific Workflows", Concurrency and Computation: Practice and Experience, 2011b.
PAULINO, C., CRUZ, S., OLIVEIRA, D., CAMPOS, M. L. M., MATTOSO, M., 2011, "Capturing Distributed Provenance Metadata from Cloud-Based Scientific Workflows", Journal of Information and Data Management, v. 2, n. 1, pp. 43-50.
PAULINO, C., OLIVEIRA, D., CRUZ, S. M. S., CAMPOS, M. L. M., MATTOSO, M., 2010, "Captura de Metadados de Proveniência para Workflows Científicos em Nuvens Computacionais". In: Anais do XXV Simpósio Brasileiro de Banco de
Dados, Belo Horizonte, Minas Gerais, Brazil. PAULINO, C., OLIVEIRA, D., CRUZ, S. M. S., MATTOSO, M., 2009, "Captura de
Proveniência de Workflows Científicos Executados em Nuvem". In: Proc. III
Sessão de Pôsteres do XXIV SBBD, Fortaleza, Ceara, Brazil. S3QL. Disponível em: <http://code.google.com/p/s3ql/>. Acesso em: 10 set. 2011. SIMMHAN, Y., BARGA, R., VAN INGEN, C., LAZOWSKA, E., SZALAY, A., 2008,
"On Building Scientific Workflow Systems for Data Management in the Cloud". In: eScience, 2008, pp. 434-435
SIMMHAN, Y., PLALE, B., GANNON, D., 2006, "A Framework for Collecting Provenance in Data-Centric Scientific Workflows". In: ICWS, pp. 427-436
SOANES, C., STEVENSON, A., 2003, Oxford Dictionary of English. 2 ed. Oxford University Press.
TAYLOR, I., SHIELDS, M., WANG, I., HARRISON, A., "The Triana Workflow Environment: Architecture and Applications", In: Workflows for e-Science, Springer, pp. 320-339, 2007a.
TAYLOR, I. J., DEELMAN, E., GANNON, D. B., SHIELDS, M., 2007b, Workflows
for e-Science: Scientific Workflows for Grids. 1 ed. Springer. TRAVASSOS, G. H., BARROS, M. O., 2003, "Contributions of In Virtuo and In Silico
Experiments for the Future of Empirical Studies in Software Engineering". In: Proc. of 2nd Workshop on Empirical Software Engineering the Future of
Empirical Studies in Software Engineering, pp. 117-130, Roma. VAQUERO, L. M., RODERO-MERINO, L., CACERES, J., LINDNER, M., 2009, "A
break in the clouds: towards a cloud definition", SIGCOMM Comput. Commun.
Rev., v. 39, n. 1, pp. 50-55. WANG, L., TAO, J., KUNZE, M., CASTELLANOS, A. C., KRAMER, D., KARL, W.,
2008, "Scientific Cloud Computing: Early Definition and Experience". In: 10th
IEEE HPCC, pp. 825-830, Los Alamitos, CA, USA. WFMC, I., 1997, The WfMC glossary, pp. 385-421.
47
ZHAO, Y., HATEGAN, M., CLIFFORD, B., FOSTER, I., VON LASZEWSKI, G., NEFEDOVA, V., RAICU, I., STEF-PRAUN, T., WILDE, M., 2007, "Swift: Fast, Reliable, Loosely Coupled Parallel Computation". In: Proc. of the 3rd
IEEE World Congress on Services, pp. 199-206, Salt Lake City, USA. ZHAO, Y., RAICU, I., FOSTER, I., 2008, "Scientific Workflow Systems for 21st
Century, New Bottle or New Wine?". In: IEEE Congress on Services, pp. 467-471.