Baixar o PDF

29th SBBD – Demos and Applications Session – ISSN 2316-5170
October 6-9, 2014 – Curitiba, PR, Brazil
paper:6
SciCumulus 2.0: Um Sistema de Gerência de Workflows
Científicos para Nuvens Orientado a Fluxo de Dados *
Vítor Silva1, Daniel de Oliveira2 e Marta Mattoso1
1
2
COPPE – Universidade Federal do Rio de Janeiro (UFRJ)
Instituto de Computação – Universidade Federal Fluminense (IC/UFF)
{silva, marta}@cos.ufrj.br, [email protected]
Resumo. Ao contrário dos workflows de negócio, os workflows científicos são
centrados no grande fluxo de transformação de dados. Entretanto, as
abordagens dos sistemas de workflows em larga escala ainda são voltadas à
gerência da execução paralela de tarefas ao invés de gerenciar as relações
entre os dados ao longo fluxo de geração dos dados do workflow. Este artigo
apresenta a execução do SciCumulus 2.0 e sua nova camada de submissão de
execução paralela que oferece diferentes níveis para a modelagem de
workflows, assim como a configuração do ambiente de paralelismo e consultas
aos dados de domínio e de proveniência em tempo de execução.
1. Introdução
Nos últimos anos, os experimentos científicos computacionais têm aumentado em
complexidade em termos do número de execuções e do volume de dados produzidos.
Esses experimentos podem ser modelados como um conjunto de atividades e um fluxo
de dados entre elas. Cada atividade pode ser um programa de computador que processa
um conjunto de dados de entrada e produz um outro conjunto de dados de saída,
gerando o fluxo de dados dos chamados workflows científicos. Sistemas de Gerência de
Workflows Científicos (SGWfC), como o Swift/T (Wozniak et al. 2013), executam
workflows com processamento de alto desempenho (PAD), incluindo os ambientes de
nuvens de computadores. Para prover paralelismo, as atividades do workflow são
subdivididas em tarefas menores (que chamamos de ativações). Cada ativação atua
sobre um elemento do conjunto de valores de parâmetros a ser consumido. Os SGWfC
paralelos distribuem as ativações para os recursos computacionais nesses ambientes,
respeitando as dependências de dados entre elas. A gerência da dependência do fluxo de
dados do workflow é um dos diferenciais dos SGWfC em relação a soluções que
programam esse controle por scripts ou Hadoop, ou de forma independente (manual).
Ao contrário dos workflows de negócio, os workflows científicos são centrados
no fluxo de transformação dos dados (Davidson and Freire 2008). Entretanto, as
abordagens dos SGWfC ainda são fortemente voltadas à gerência das ativações ao invés
do fluxo de dados como um todo. Pode-se classificar os dados envolvidos na execução
paralela de workflows científicos em quatro categorias: (i) dados do domínio, (ii) fluxo
de dados gerados na execução do workflow, (iii) fluxo das atividades executadas e (iv)
dados de desempenho da execução do workflow. Essas quatro categorias, embora
relacionadas, são tratadas de modo independente pelos SGWfC. Apenas as categorias
*
Este artigo foi parcialmente financiado pelo CNPq e FAPERJ.
Vídeo em: https://s3.amazonaws.com/SBBD-Demo/Video-Final.mp4.
239
29th SBBD – Demos and Applications Session – ISSN 2316-5170
October 6-9, 2014 – Curitiba, PR, Brazil
(ii) e (iii) são interligadas pelos SGWfC por meio de dados de proveniência. SGWfC
registram o fluxo de dados e atividades, capturando a proveniência prospectiva
(estrutura e dependências das atividades) e retrospectiva (relacionados à execução do
workflow) (Davidson and Freire 2008). Após a execução do workflow, cientistas podem
consultar a base de dados de proveniência para analisar o fluxo dos dados até os
resultados. Embora esse registro seja um grande avanço em relação às soluções que não
utilizam proveniência, a análise de workflows com dados em larga escala necessita de
um monitoramento do perfil computacional da geração do fluxo de dados (e.g. tempo de
execução das atividades). É preciso ainda relacionar esse fluxo aos dados do domínio.
Em dados de proveniência que contêm apenas metadados sobre os dados do domínio, o
relacionamento aos dados de domínio ainda se dá de forma "manual". Dados do perfil
computacional, em geral, são representados em logs. Entretanto, logs são difíceis de
serem consultados e ferramentas do ambiente PAD são independentes do contexto do
fluxo de transformação de dados, limitando o poder analítico.
Para realizar a integração das quatro categorias de dados, Ogasawara et al.
(2011) propuseram uma abordagem algébrica, centrada em dados, para a execução de
workflows. Essa álgebra faz uso da tecnologia de sistemas de bancos de dados
relacionais para gerenciar o fluxo de transformação de dados em workflows de forma
integrada, sendo tanto a definição do workflow quanto seus dados representados em
relações dentro do banco de dados de proveniência. À medida que as ativações são
executadas, esta base de dados de proveniência registra o perfil do desempenho das
execuções em relações voltadas para apoiar o monitoramento via consultas. Da mesma
forma, tuplas representam, como valores ou referência a arquivos de dados do domínio,
os dados de entrada das atividades. Assim, a abordagem algébrica integra em uma base
de dados de proveniência, as quatro categorias de dados do experimento científico,
gerando uma ferramenta essencial na análise de dados científicos em larga escala.
Com o intuito de desenvolver um SGWfC que tirasse proveito dos ambientes de
nuvens e dessa integração no banco de dados de proveniência, a abordagem algébrica
foi incorporada à máquina de workflows que deu origem ao SciCumulus (Oliveira et al.
2010). A proveniência foi usada, de modo original, para que uma série de componentes
oferecessem: monitoramento, tolerância a falhas, re-execuções, etc. (Costa et al. 2012).
Além disso, o SciCumulus usou a proveniência para explorar a elasticidade na
computação em nuvens, para a execução paralela de workflows, implementando um
algoritmo adaptativo para a alocação dinâmica de recursos computacionais. Ao
consultar o histórico via proveniência ele minimiza o custo financeiro, o tempo de
execução e a confiabilidade dos recursos computacionais (Viana et al. 2011, Oliveira et
al. 2012). Desde a sua primeira versão, o SciCumulus ainda não foi apresentado como
ferramenta de demonstração. O SciCumulus 2.0 integra, em uma única ferramenta,
diversos componentes anteriormente propostos de modo isolado, e cria uma camada de
software para a modelagem de experimentos sem a necessidade de uma interação direta
com o ambiente de PAD. Tal camada oferece diferentes níveis de abstração para a
modelagem dos workflows, assim como a configuração do ambiente de PAD e consultas
analíticas aos dados de proveniência em tempo de execução.
Embora seja grande o número de SGWfC com paralelismo (Bux e Leser 2013),
nenhum deles oferece um acesso integrado às quatro categorias de dados envolvidas na
execução e análise do workflow científico. Os sistemas mais relacionados a esse
trabalho são o Swift/T e o Pegasus, devido ao paralelismo. Entretanto, nesses sistemas,
240
29th SBBD – Demos and Applications Session – ISSN 2316-5170
October 6-9, 2014 – Curitiba, PR, Brazil
os dados de proveniência são disponibilizados apenas no final da execução do workflow.
Para monitorar o desempenho durante a execução, o Pegasus disponibiliza uma base de
dados relacional para consultas sobre o perfil de execução. Assim, o Pegasus opera com
duas bases, uma para registrar as informações de execução das atividades e outra para
os dados de proveniência do fluxo de dados e atividades do workflow executado. Além
da redundância de dados, essa separação em duas bases, não permite consultas do tipo
"quais os valores dos parâmetros das ativações com tempo de execução acima da
média". Embora essa consulta seja possível na base de proveniência do Swift, ela só
pode ser submetida quando a execução já terminou e muitas vezes sem acesso aos dados
de domínio, como o parâmetro mencionado.
O restante deste artigo é organizado da seguinte forma: a Seção 2 apresenta o
SciCumulus 2.0, incluindo a sua arquitetura com os mecanismos de interação e
integração de dados via proveniência, enquanto que a Seção 3 conclui este artigo.
2. SciCumulus 2.0: um SGWfC Orientado a Fluxo de Dados
Esta seção apresenta uma visão geral do SciCumulus 2.0 e seus recursos de gerência de
fluxos de dados guiada por dados de proveniência. Na álgebra de Ogasawara et al.
(2011) cada atividade do workflow é associada a uma operação. Essas operações
determinam como a atividade consome e produz dados. O conjunto de dados de entrada
e saída das atividades são operandos, representados como relações. Cada ativação
consome uma tupla da relação operando que contém parâmetros e referências a arquivos
necessários para realizar o processamento da atividade (ativação) gerando uma tupla
correspondente na relação de saída. Assim, o banco de dados de proveniência (Figura 1)
se torna uma peça fundamental não só para a análise do experimento por parte do
usuário, mas para a própria execução por parte do SGWfC, uma vez que atua como um
catálogo de estatísticas que pode ser consultado e analisado.
A arquitetura do SciCumulus 2.0 é definida a partir de três camadas principais
(Figura 1): SciCumulus Starter, SciCumulus Core e o Banco de Dados de Proveniência.
O SciCumulus Starter configura o ambiente para a execução paralela do workflow e
invoca a sua execução na nuvem. É implementado por uma aplicação independente que
executa na máquina do cientista sem que seja necessário instalar nenhuma aplicação ou
biblioteca (apenas copiar um .jar). Ele possui três componentes principais com as
funções de: gerência do ambiente de nuvem, submissão de workflows e a validação do
workflow. A gerência do ambiente de nuvem instancia e destrói um conjunto de
máquinas virtuais (MVs) interconectadas na nuvem (i.e. cluster virtual). Ele inicializa
ou exclui um conjunto de MVs, cria configurações de segurança necessárias (como
grupos de segurança, chaves de acesso, entre outros), assim como define uma hierarquia
dessas MVs, a fim de obedecer a arquitetura do SciCumulus Core (Oliveira et al. 2012)
que é baseada em MPI e exige uma MV de controle para a distribuição das ativações.
Essa instanciação inicial de MVs é baseada em consultas aos dados históricos de
proveniência para que o SciCumulus Starter possa dimensionar o ambiente para a
execução. O SciCumulus Core pode ainda instanciar novas MVs ou destruir, em tempo
de execução de acordo com a demanda seguindo o algoritmo adaptativo proposto por
Oliveira et al. (2012). Vale ressaltar que enquanto o SciCumulus original executava o
controle do algoritmo adaptativo em uma máquina remota (que deveria possuir conexão
permanente obrigatória), o SciCumulus 2.0 submete um pedido de execução para as
241
29th SBBD – Demos and Applications Session – ISSN 2316-5170
October 6-9, 2014 – Curitiba, PR, Brazil
diversas MVs, dedicando uma das MVs de execução para o controle do algoritmo
adaptativo (i.e. quando dimensionar o ambiente).
SciCumulus)Starter)
Submissão)
de)Workflow)
Gerência)do)
Ambiente)de))
Nuvem)
1)
Validação)de)
Workflow)
))))))SciCumulus)Core)
3
9)
Monitoramento)
10)
Submissão)
de)Consultas)
2)
4)
8)
Banco)de)
Dados)de)
Proveniência)
Legenda:)
))Fluxo)de)Dados)
))Fluxo)de)Controle)
Escalonamento)
5)
Gerência)de)
Comunicação)
6,)7)
A:vação)
Sistema)de)
Arquivos)
)
)
)
Alocação) )
Adapta:va) )
)
)
)
)
)
)
)
)
)
)
)
)
))
)
Figura 1. A Arquitetura do SciCumulus 2.0
A validação de workflows registra a especificação conceitual de workflows na
base de dados de proveniência. Este componente valida um arquivo XML que contém a
especificação do workflow e então registra no banco de proveniência a estrutura do
workflow para ser usada no momento da execução. A submissão do workflow inicia a
execução paralela de um workflow que já foi registrado na base de proveniência. A
inserção do SciCumulus Starter na arquitetura do SciCumulus 2.0 é uma mudança
importante em relação às primeiras versões do SciCumulus, cuja inicialização era
realizada a partir de SGWfC de terceiros (e.g. VisTrails). Utilizando o SciCumulus
Starter, a execução do workflow depende apenas do SciCumulus 2.0. O SciCumulus
Starter é invocado por: java –jar SciCumulusStarter.jar <funcionalidade> <arquivo
XML>. Os valores para o argumento de funcionalidade incluem: -cc: cria cluster de
MVs na nuvem, -dc: exclui cluster de MVs; -icw: insere workflow na base de
proveniência; -ucw: atualiza workflow na base de proveniência; -dcw: exclui workflow
da base de proveniência; -sew: submete workflow para execução paralela e -q: consulta
a base de proveniência. Além do argumento de funcionalidade, deve ser informado um
arquivo de configuração, especificado de acordo com um XML schema próprio do
SciCumulus. Cada tag do XML a ser informada se encontra no Quadro 1. Os elementos
a serem informados no arquivo de configuração variam de acordo com a funcionalidade.
Os termos estão em inglês para facilitar a interoperabilidade com a recomendação de
padrão de proveniência PROV da W3C.
SciCumulus Starter ainda permite ao usuário executar consultas no banco de
proveniência em tempo de execução por meio do componente de submissão de
consultas. Além dos dados padrão de proveniência, tanto a consulta aos dados do
domínio como do progresso da execução dos workflows podem ser submetidas via SQL
especificado pelo usuário ou pré-configuradas no componente.
O SciCumulus Starter invoca o SciCumulus Core por meio do seu componente
de submissão de workflows. O SciCumulus Core é uma aplicação paralela
implementada em MPJ (MPI para linguagem Java) e que é executada em todas as MVs
que fazem parte do cluster virtual. O SciCumulus Core gerencia a execução de
workflows científicos, conforme a arquitetura apresentada na Figura 1. Quando um
workflow é submetido ao SciCumulus Core, a primeira etapa (#3 na Figura 1) consiste
242
29th SBBD – Demos and Applications Session – ISSN 2316-5170
October 6-9, 2014 – Curitiba, PR, Brazil
na análise e envio dos dados previamente registrados na base de proveniência para esse
workflow na nuvem. Já a segunda etapa (#4) consiste no envio dos dados de
proveniência e a requisição, respectivamente, do início da execução do workflow. O
Monitoramento analisa os dados de proveniência para verificar as atividades pendentes
e que apresentam todas as suas dependências atendidas. Para essas atividades, o
Escalonamento identifica as ativações que fazem parte dessa atividade (#5). Ao mesmo
tempo, possíveis adaptações na quantidade de MVs são analisadas em tempo real pela
Alocação Adaptativa (#9). Em caso de adaptações necessárias para atender a requisitos
dos cientistas como tempo máximo de execução, são realizadas mudanças por esse
componente, reportando ao Escalonador apenas essas mudanças de MVs.
Quadro 1. Elementos do arquivo de configuração no formato XML
Elementos)
Descrição)
Atributos)
SciCumulus)
Elemento)raiz)
Nenhum)
Dependência)
Nenhuma)
creden<als)
Credenciais)para)a)Amazon))
access_key,)secret_access_key)
SciCumulus)
environment)
Configurações)do)ambiente)
type,)cluster_name)
SciCumulus)
binary)
Informações)de)arquivos)binários)
directory,)conceptual_version,)execu<on_version)
SciCumulus)
machine)
Configuração)das)máquinas)
virtuais)
image,)user,)password)
SciCumulus)
vm)
Tipos)de)máquinas)virtuais)
disponíveis)
Type,)financial_cost,)disk_space,)ram,)gflops,)
plaNorm,)cores)
machine)
constraint)
Restrições)do)ambiente)e)do)
workflow)
workflow_exectag,)max_<me,)max_financial_cost,)
max_vm_amount,)total_ram,)total_disk,)alfa1,)
alfa2,)alfa3,)cores)
SciCumulus)
workspace)
Configurações)para)
armazenamento)de)arquivos)
upload,)bucket_name,)workflow_dir,)
compressed_workspace,)compressed_dir)
SciCumulus)
database)
Configurações)da)base)de)dados)
name,)username,)password,)port,)server,)path)
SciCumulus)
query)
Especificação)da)consulta)
sql)
SciCumulus)
conceptualWorkflow)
Especificação)do)workflow)
conceitual)
tag,)descrip<on)
SciCumulus)
conceptualWorkflow)
ac<vity)
Especificação)das)a<vidades)
tag,)descript,)type,)ac<va<on,)template,)extractor)
rela<on)
Especificação)das)relações)
reltype,)name)
ac<vity)
field)
Especificação)dos)campos)
name,)type,)input,)output,)decimalplaces,)opera<on)
rela<on)
execu<onWorkflow)
Especificação)do)workflow&de)
execução&
tag,)execmodel,)expdir,)max_failure,)
user_interac<on,)redundancy,)reliability)
SciCumulus)
rela<on)
Especificação)das)relações)de)
entrada)do)workflow&de)execução)
name,)filename)
execu<onWorkflow)
O Monitoramento provê a tolerância a falhas no SciCumulus 2.0. Essa extensão
foi inspirada no SciMultaneous (Costa et al. 2012) que verifica a ocorrência de erros por
meio de consultas ao banco de proveniência. Três características importantes desse
mecanismo são: a replicação de ativações em execução, quando um recurso
computacional está ocioso e não possui ativações pendentes; o cálculo de confiabilidade
de uma determinada MV em virtude do número de ativações com falhas de execução; e
o número máximo de falhas permitido em uma ativação, para que a mesma seja
desconsiderada da execução do workflow. Diferentemente do SciMultaneous, o
SciCumulus 2.0 provê a tolerância a falhas em tempo de execução dentro da própria
gerência de ativações (elemento Ativação da Figura 1). O SciCumulus 2.0 não necessita
de uma MV extra para a recuperação de falhas, como no SciMultaneous.
Após a determinação da MV que deve executar (ou re-executar, caso uma falha
seja identificada) uma ou mais ativações, o Escalonamento envia tal mapeamento (i.e.
conjunto de MVs e ativações) para a Gerência de Comunicação, que envia (#5) e recebe
(#6) mensagens (com dados e valores de parâmetros de cada ativação) entre as MVs. Ao
receber uma ou mais ativações, a MV deve executá-la (s) pelo componente de Ativações
(#6 e #7). Quando a MV central recebe ativações finalizadas pelas MVs executoras, os
dados de proveniência dessas ativações são enviados ao Monitoramento, que assume o
243
29th SBBD – Demos and Applications Session – ISSN 2316-5170
October 6-9, 2014 – Curitiba, PR, Brazil
controle e identifica as atividades pendentes e distribui novas ativações para as MVs
que estiverem ociosas.
3. Conclusão
Experimentos científicos, mesmo se executados em paralelo, podem ter uma longa
duração necessitando de monitoramento. Várias tentativas de configurações são
necessárias para se chegar a uma conclusão final. SciCumulus (Oliveira et al. 2012),
uma máquina de workflows capaz de gerenciar a execução de workflows em ambientes
de nuvem, foi estendido e várias ferramentas desenvolvidas externamente foram
incorporadas, de modo a facilitar sua instalação e execução, gerando o SciCumulus2.0.
Uma característica que se mantém original em relação ao estado da arte é ser orientado
ao fluxo de transformação de dados do workflow. Essa é uma característica importante,
pois o banco de dados de proveniência serve de apoio à interface com a máquina de
workflows, tanto para a configuração quanto para o monitoramento e análise de dados
em larga escala por parte do cientista. Além disso, o SGWfC passa a ter acesso a um
catálogo de estatísticas auxiliando a geração do plano de execução e estratégias
adaptativas em tempo de execução. A demonstração objetiva a apresentação do
SciCumulus 2.0, suas contribuições originais e evoluções.
Referências Bibliográficas
Bux, M., Leser, U., (2013), Parallelization in Scientific Workflow Management
Systems, CoRR/arXiv:1303.7195.
Costa, F., Oliveira, D. de, Ocana, K., Ogasawara, E., Dias, J., Mattoso, M., (2012),
"Handling Failures in Parallel Scientific Workflows Using Clouds". In: WORKS
workshop IEEE/ACM SC Companion, p. 129–139.
Davidson, S. B., Freire, J., (2008), "Provenance and scientific workflows: challenges
and opportunities". In: ACM SIGMOD, p. 1345–1350.
Lee, K., Paton, N. W., Sakellariou, R., Deelman, E., Fernandes, A. A. A., Mehta, G.,
(2008), "Adaptive Workflow Processing and Execution in Pegasus". In: 3rd
International Conference on Grid and Pervasive Computing, p. 99–106.
Ogasawara, E., Dias, J., Oliveira, D., Porto, F., Valduriez, P., Mattoso, M., (2011), "An
Algebraic Approach for Data-Centric Scientific Workflows", In: Proc. of VLDB
Endowment, v. 4, n. 12, p. 1328–1339.
Oliveira, D., Ogasawara, E., Baião, F., Mattoso, M., (2010), "SciCumulus: A
Lightweight Cloud Middleware to Explore Many Task Computing Paradigm in
Scientific Workflows". In: 3rd Int Conference on Cloud Computing, p. 378–385.
Oliveira, D., Ocaña, K., Baião, F., Mattoso, M., (2012), "A Provenance-based Adaptive
Scheduling Heuristic for Parallel Scientific Workflows in Clouds", In: Journal of
Grid Computing, v. 10, n. 3, p. 521–552.
Wozniak, J. M., Armstrong, T. G., Wilde, M., Katz, D. S., Lusk, E., Foster, I. T.,
(2013), "Swift/T: Large-Scale Application Composition via Distributed-Memory
Dataflow Processing". In: IEEE/ACM CCGrid, p. 95–102
244