SciCumulus 2.0: Um Sistema de Gerência de Workflows Científicos para Nuvens Orientado a Fluxo de Dados *

Transcrição

1 paper:6 SciCumulus 2.0: Um Sistema de Gerência de Workflows Científicos para Nuvens Orientado a Fluxo de Dados * Vítor Silva 1, Daniel de Oliveira 2 e Marta Mattoso 1 1 COPPE Universidade Federal do Rio de Janeiro (UFRJ 2 Instituto de Computação Universidade Federal Fluminense (IC/UFF {silva, marta}@cos.ufrj.br, danielcmo@ic.uff.br 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 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: 239

2 (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 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 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 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 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

3 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 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

4 diversas MVs, dedicando uma das MVs de execução para o controle do algoritmo adaptativo (i.e. quando dimensionar o ambiente. Gerênciado Ambientede Nuvem SciCumulusStarter 1 Validaçãode Workflow 2 Submissão deworkflow Submissão deconsultas Legenda: FluxodeDados FluxodeControle 3 10 Bancode Dadosde Proveniência SciCumulusCore Monitoramento 4 Escalonamento 8 Gerênciade Comunicação A:vação 6,7 5 9 Sistemade 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

5 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 Dependência SciCumulus Elementoraiz Nenhum Nenhuma creden<als CredenciaisparaaAmazon access_key,secret_access_key SciCumulus environment Configuraçõesdoambiente type,cluster_name SciCumulus binary Informaçõesdearquivosbinários directory,conceptual_version,execu<on_version SciCumulus machine vm constraint workspace Configuraçãodasmáquinas virtuais Tiposdemáquinasvirtuais disponíveis Restriçõesdoambienteedo workflow Configuraçõespara armazenamentodearquivos image,user,password Type,financial_cost,disk_space,ram,gflops, planorm,cores workflow_exectag,max_<me,max_financial_cost, max_vm_amount,total_ram,total_disk,alfa1, alfa2,alfa3,cores upload,bucket_name,workflow_dir, compressed_workspace,compressed_dir SciCumulus machine SciCumulus SciCumulus database Configuraçõesdabasededados name,username,password,port,server,path SciCumulus query Especificaçãodaconsulta sql SciCumulus conceptualworkflow Especificaçãodoworkflow conceitual tag,descrip<on SciCumulus ac<vity Especificaçãodasa<vidades tag,descript,type,ac<va<on,template,extractor conceptualworkflow rela<on Especificaçãodasrelações reltype,name ac<vity field Especificaçãodoscampos name,type,input,output,decimalplaces,opera<on rela<on execu<onworkflow rela<on Especificaçãodoworkflow&de execução& Especificaçãodasrelaçõesde entradadoworkflow&deexecução tag,execmodel,expdir,max_failure, user_interac<on,redundancy,reliability name,filename SciCumulus execu<onworkflow O Monitoramento provê a tolerância a falhas no SciCumulus 2.0. Essa extensão foi inspirada no SciMultaneous (Costa et al 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

6 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: 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 Davidson, S. B., Freire, J., (2008, "Provenance and scientific workflows: challenges and opportunities". In: ACM SIGMOD, p 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 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 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 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 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