Controlling the Parallel Execution of Workflows Relying on a Distributed Database
Autores
5873 |
51,2701
|
|
5872 |
51,2701
|
Informações:
Publicações do PESC
Título
Controlling the Parallel Execution of Workflows Relying on a Distributed Database
Linha de pesquisa
Engenharia de Dados e Conhecimento
Tipo de publicação
Dissertação de Mestrado
Número de registro
Data da defesa
23/7/2015
Resumo
Simulações computacionais de larga escala requerem processamento de alto desempenho, envolvem manipulação de muitos dados e são comumente modeladas como workflows científicos centrados em dados, gerenciados por um Sistema de Gerência de Workflows Científicos (SGWfC). Em uma execução paralela, um SGWfC escalona muitas tarefas para os recursos computacionais e Processamento de Muitas Tarefas (MTC, do inglês Many Task Computing) é o paradigma que contempla esse cenário. Para gerenciar os dados de execução necessários para a gerência do paralelismo em MTC, uma máquina de execução precisa de uma estrutura de dados escalável para acomodar tais tarefas. Além dos dados da execução, armazenar dados de proveniência e de domínio em tempo de execução permite várias vantagens, como monitoramento da execução, descoberta antecipada de resultados e execução interativa. Apesar de esses dados poderem ser gerenciados através de várias abordagens (e.g, arquivos de log, SGBD, ou abordagem híbrida), a utilização de um SGBD centralizado provê diversas capacidades analíticas, o que é bem valioso para os usuários finais. Entretanto, se por um lado o uso de um SGBD centralizado permite vantagens importantes, por outro, um ponto único de falha e de contenção é introduzido, o que prejudica o desempenho em ambientes de grande porte. Para tratar isso, propomos uma arquitetura que remove a responsabilidade de um nó central com o qual todos os outros nós precisam se comunicar para escalonamento das tarefas, o que gera um ponto de contenção; e transferimos tal responsabilidade para um SGBD distribuído. Dessa forma, mostramos que nossa solução frequentemente alcança eficiências de mais de 80% e ganhos de mais de 90% em relação à arquitetura baseada em um SGBD centralizado, em um cluster de 1000 cores. Mais importante, alcançamos esses resultados sem abdicar das vantagens de se usar um SGBD para gerenciar os dados de execução, proveniência e de domínio, conjuntamente, em tempo de execução.
Abstract
Large-scale computer-based scientific simulations require high performance computing, involve big data manipulation, and are commonly modeled as data-centric scientific workflows managed by a Scientific Workflow Management System (SWfMS). In a parallel execution, a SWfMS schedules many tasks to the computing resources and Many Task Computing (MTC) is the paradigm that contemplates this scenario. In order to manage the execution data necessary for the parallel execution management and tasks’ scheduling in MTC, an execution engine needs a scalable data structure to accommodate those many tasks. In addition to managing execution data, it has been shown that storing provenance and domain data at runtime enables powerful advantages, such as execution monitoring, discovery of anticipated results, and user steering. Although all these data may be managed using different approaches (e.g., flat log files, DBMS, or a hybrid approach), using a centralized DBMS has shown to deliver enhanced analytical capabilities at runtime, which is very valuable for end-users. However, if on the one hand using a centralized DBMS enables important advantages, on the other hand, it introduces a single point of failure and of contention, which jeopardizes performance in a large scenario. To cope with this, in this work, we propose a novel SWfMS architecture that removes the responsibility of a central node to which all other nodes need to communicate for tasks’ scheduling, which generates a point of contention; and transfer such responsibility to a distributed DBMS. By doing this, we show that our solution frequently attains an efficiency of over 80% and more than 90% of gains in relation to an architecture that relies on a centralized DBMS, in a 1,000 cores cluster. More importantly, we achieve all these results without abdicating the advantages of using a DBMS to manage execution, provenance, and domain data, jointly, at runtime.
Arquivo