Sistemas de Gerência

São várias as soluções de propósito geral para gerência de workflow concebidas inicial- mente para grades. XCAT [165], baseado na especificação CCA (Common Component Architecture), propõe um arquitetura com componentes distribuídos. Em [166] são discu- tidos e propostos algoritmos para composição de serviços e escalonamento direcionado a workflow. Permite composição, visualização, verificação, escalonamento e monitoramento na execução dos workflows. Seu foco é na composição de serviços, não sendo ideal para escalonamento de tarefas. Em [167] é apresentada a Grid Workflow Infrastructure, ba- seada em OGSA e que usa os conceitos de WS-BPEL. Belloum et al. [168] discutem o Laboratório Virtual para e-Ciência (Virtual Laboratoty for e-Science - VL-e). O VL-e é composto por um sistema de workflow e uma interface gráfica através da qual são feitas as execuções. O sistema de workflow (Workflow System Virtual Laboratory Abstract Machine - WS-VLAM) é a ferramenta para desenvolvimento de aplicações que integra serviços com anotações semânticas, proveniência de dados e coordena recursos para e-Ciência. A ar- chitetura VL-e é flexível permitindo a integração com outras plataformas como Taverna e Kepler. No entanto é direcionado ao ambiente de grade.

[169] propõe uma solução para executar partes do workflow na nuvem. A solução usa wokflows abstratos com anotações sobre os requisitos das tarefas a fim de preparar dinamicamente VMs para a execução. A arquitetura proposta usa templates que permitem

a criação de workflows em diversas linguagens e que podem ser executados por vários motores. A solução proposta é útil em ambientes híbridos com grade e nuvem pública, mas não trabalha com workflows de serviços e não opera em nuvens híbridas. O Generic Workflow Execution Service (GWES) [170] é um sistema de gerenciamento de workflows de código aberto desenvolvido pela Frauenhofer-Gesellschaft para a gestão e automatização de workflows complexos em ambientes heterogêneos. A orquestração passa por cinco níveis de abstração: requisição do usuário, workflow abstrato, os serviços candidatos, instâncias de serviços e recursos. A requisição do usuário é feita através de operações abstratas independentes do workflow abstrato. O workflow abstrato é mapeado em tempo de execução nos recursos disponíveis, processo no qual são criadas as instâncias escolhidas dentre os serviços candidatos. GWES foi originalmente desenvolvido para a tecnologia de grade Globus e foi ajustado para nuvem.

O ambiente híbrido com grade e nuvem requer de certa forma que a gerência providen- cie facilidades na nuvem para aplicações destinadas ao ambiente da grade. Aplicações de e-Ciência são um bom exemplo desses requisitos. [171] destaca as caracteríticas específi- cas de aplicação, a descrição das tarefas e serviços, a preparação do software necessário, a configuração dos serviços e o gerenciamento de execuções de longa duração, caracteríticas de aplicações para grade, como desafios a serem encaminhados na nuvem. O CEO através de seu conjunto de serviços torna transparente ao usuário a preparação dos serviços, a escolha dos recursos computacionais não importando se os recursos computacionais são oriundos da grade ou da nuvem. Além disso, sua fábrica de gerentes de execução e a troca de informações através de notificação permitem a execução por tempo indeterminado.

Existem vários arcabouços e ferramentas para geração, refinamento e execução de workflows [172]. Geralmente associados a projetos de porte, esses arcabouços usam estra- tégias distintas para fazer a gerência de workflows. A seguir são discutidos alguns desses projetos.

• Triana:

Triana [173, 174] é um sistema de workflow orientado a análise de dados desenvol- vido pela Universidade Cardiff. Ele provê uma interface para programação visual com funcionalidades para representar unidades. O workflow é montado arrastando e conectando as aplicações dentro do espaço de trabalho. A execução do workflow é definida através de unidades de controle (ciclos) e lógicas (decisão), além de uni- dades para interconexão usadas para formar grupos. Clientes Triana, como Triana GUI, usam um TCS (Triana Controlling Service) para criar remotamente, execu- tar e visualizar os resultados dos workflows. Cada TCS interage com o motor do Triana e cada motor fornece um serviço capaz de executar tarefas no local, ou em outros servidores através da distribuição do código respeitando a política de dis- tribuição especificada. A política de distribuição baseia-se em grupos de unidades,

podendo ser paralela ou peer-to-peer. Ambas distribuem grupos de unidades em máquinas separadas, no entanto, o mecanismo de peer-to-peer depende dos dados intermediários passados entre os hosts, enquanto que na política paralela não há essa dependência. Triana usa o conceito de representação abstrata onde as tarefas não são associadas a um conjunto específico de recursos. Dessa forma pode esco- lher dinamicamente os hosts distribuindo-os de forma mais eficaz. Triana permite a construção de workflows com serviços WSRF, mas apesar da interface gráfica, o usuário deve ser um especialista nesse tipo de serviço, pois deve dominar detalhes como WS-ResourceProperty e End Point Reference. Triana é oritentado a dados e não oferece facilidades para ambientes híbridos.

• Taverna:

Taverna [175, 176, 177] é o sistema de gerência de workflow do projeto myGrid [178], um middleware cujo objetivo é dar suporte personalizado a experimentos de biolo- gia. O Taverna é uma colaboração entre várias universidades, institutos e indústrias européias. Taverna provê modelos de dados, aceita extensões de tarefas e oferece uma interface gráfica para o usuário, além de permitir a integração com o Free- Fluo [179] um motor de workflow para transferência de arquivos intermediários e invocação de serviços. Em Taverna o modelo de dados pode ser representado tanto pelo formato gráfico como pela SCUFL (Simple Conceptual Unified Flow Language), uma linguagem basead em XML. O modelo de dados consiste em entradas, saídas, processadores, fluxos de dados e de controle. Para especificar a ordem de execução o controle de fluxo pode acionar transições de estado durante a execução de proces- sadores associados. Em nível de execução o Taverna provê mecanismos multitarefa para acelerar a interação entre processo, permitindo aos usuários especificarem quan- tas instâncias concorrentes enviaram requisições em paralelo para os processadores. Ele oferece bom suporte a serviços capazes de manipular processos simultâneos e pode reduzir o tempo de espera dos serviços pois á capaz de enviar dados da próxima etapa enquanto está processando. O Taverna, integrado às facilidades do myGrid, permite configurar tolerância a falha em cada processador do workflow, indicando o número de tentativas, tempo de espera e processador alternativo. O usuário pode ainda especificar níveis para falhas em cada processador. Taverna/myGrid adota os conceitos de SOA suportanto tipos diferentes de serviços, incluindo serviços Web ba- seados em WSDL, soaplab bioservices [180], e serviços locais como programas Java. Ele também permite o uso de UDDI e diretório de ontologias [181] como serviço de nomes. O Taverna não oferece facilidades para o gerenciamento em ambientes híbridos.

• UNICORE:

UNICORE (Uniform Interface to Computing Resources) [92] oferece um sistema OGSA/WSRF open source de grade pronto para o uso (ready-to-run). UNICORE torna os recursos de computação e de dados distribuídos disponíveis de uma forma segura acessível por intranets e pela Internet. No workflow UNICORE as depen- dências entre as tarefas são representadas através de DAGs que incluem também as dependências de tempo [182]. Um workflow UNICORE pode conter controle de fluxo, condicionais, repetições e ações condicionais para suspender a execução da tarefa. Além disso, oferece três tipos de opções para a execução: a primeira base- ada no código de retorno da execução anterior, uma segunda opção indicada através de um arquivo de configuração e uma terceira que é determinada por agendamento (data e hora). UNICORE provê uma ferramenta gráfica para usuários criarem work- flows e convertê-los em AJO (Abstract Job Object), um objeto Java serializável. Os objetos AJOs, workflows convertidos, são submetidos ao servidor UNICORE. O servidor converte a submissão em lotes de tarefas que são enviadas para processa- mento nos recursos computacionais. O servidor também garante as dependências de dados. UNICORE permite aos usuários executar grupos de tarefas em vários re- cursos. Uma área temporária é usada para suportar a transferência de dados entre as tarefas. O UNICORE também permite aos usuários especificar explicitamente transferências de dados entre as tarefas ficando responsável pela movimentação de dados. O UNICORE, originalmente projetado para grades, vem sendo atualizado ao longo do tempo. Rings e Grabowski discutem em [183] possiblidades para a integra- ção entre grade e nuvem no UNICORE. Nessa linha, os autores tecem considerações sobre a integração da grade Globus com nuvens Amazon e Eucalyptus. No entanto, nenhuma dessa opções foi implementada até o momento.

• ASKALON:

ASKALON [184] é um ambiente de computação híbrido (grade e nuvem) com su- porte ao desenvolvimento de aplicações desenvolvido pela Universidade de Inns- bruck, Austria. O objetivo do ASKALON é simplificar o desenvolvimento e otimi- zação de aplicações que podem aproveitar o poder de grade e da nuvem. O projeto ASKALON é baseado em novas ferramentas, serviços e metodologias para fazer o de- senvolvimento de aplicações científicas e otimizar aplicações reais em grade e nuvem. ASKALON usa o AGWL (Abstract Grid Workflow Language) [185] e o Teuta [186], para suportar o desenvolvimento de workflows. AGWL é uma linguagem baseada em XML que provê diretivas para sequências, paralelismo, decisão e interação na estrutura do workflow. Ela permite também especificar propriedades e restrições sobre os parâmetros das tarefas cujas dependências podem otimizar a execução do

workflow. Teuta é uma interface gráfica que usa diagramas UML para especificar o workflow. O ASKALON tem arquitetura baseada em SOA (Figura 3.6), suporta certificados X509 e segurança baseada em GSI, trabalha com serviços Web e serviços WSRF, oferece um portal único para acesso ao ambiente híbrido, grade Globus e nuvem pública Amazon e suporta APIs EC2 Amazon.

Figura 3.6: Macro arquitetura ASKALON [184].

O ASKALON torna as caracteríticas do ambiente transparentes ao desenvolvedor de aplicações, oferece um modelo de aplicação de alto nível com otimizações genéricas baseadas em restrições de custo e desempenho, possui serviços avançados baseados em algorítmos genéricos, e tecnologias Web semântica e ontologias, faz avaliação (prediction) do comportamento do ambiente (grade e nuvem) e oferece detecção e gerenciamento de falhas.

A orquestração de workflow, feita pelo GridARM (Askalon’s Grid Resource Mana- gement), provê registro distribuído para mapear tarefas nos domínios [187]. Ele inclui pesquisa automática de problemas de desempenho e falha da infraestrutura. Monitora o desempenho dos componentes mantendo informações estáticas da in- fraestrutura e informações dinâmicas dos recursos computacionais, de rede e das aplicações. O serviço executor de workflow faz publicação dinâmica de serviços coordenando a ativação [188], e provê tolerância a falhas das atividades tanto na nuvem como na grade. Além disso, oferece um meta-escalonador para mapear as aplicações do workflow nos recursos do ambiente híbrido.

O ASKALON é um projeto interessante que oferece um conjunto completo de funci- onalidades para a execução de workflows em ambiente híbrido com grade e nuvem. No momento usa APIs EC2 Amazon para fazer o interfaceamento com o ambiente

de nuvem. A arquitetura CEO, através dos serviços CMS/CIS (Seção 5.4.8), po- tencialmente permite a conexão com qualquer tipo de tecnologia de nuvem. Além disso, a gerência de workflow CEO, através do Assistant Maestro (Seção 5.6) pode operar de forma distribuída coordenando as atividades dentro de cada um dos do- mínios/tecnologias.

• Swift:

Swift é um sistema que traz a computação paralela aos workflows científicos [189]. É uma ferramenta de programação para especificação, execução e gerência de work- flows em larga escala. A sua base é uma linguagem simples (script language), denominada SwiftScript, que especifica de forma concisa computação paralela com- plexa baseada em conjuntos de dados dinâmicos e interações para mapear dados em larga escala em diversos formatos. O Swift provê um motor de workflow para escalonamento e balanceamento de carga, que pode interagir com vários sistemas de gerenciamento de recursos como o Condor. A arquitetura Swift é formada por quatro componentes que cuidam da especificação do programa, do escalonamento, da execução e do aprovisionamento, conforme mostra a Figura 3.7.

Figura 3.7: Macro arquitetura do [190].

Os programas SwiftScript são compilados em um plano abstrato de computação, que são escalonados pelo motor de workflow nos recursos computacionais. O apro- visionamento de recursos é flexível sendo disponibilizado através de uma interface que pode ser implementada como o host local, um cluster, uma grade ou um serviço EC2 Amazon. Um componente importante é o serviço para gerência de workflow na nuvem (Swift Cloud Workflow Management Service - SCWMS) que atua como intermediário entre o cliente e o gerente de recursos da nuvem. O SCWMS oferece uma interface Web para configurar os serviços, as informações do gerente de recursos

e os dados do ambiente de aplicação. Ele provê funcionalidades para programação e compilação de SwiftScripts, escalonarmento de workflows, aprovisionamento de recursos, monitoramento e tem um mecanismo para tolerância a falhas. A flexi- bilidade do Swift está nas interfaces para acoplamento com outras soluções. Por exemplo, para criação de clusters virtuais é usado o Falkon [191]. No entanto, essa flexibilidade ainda não permite a execução de workflows que usem simultaneamente recursos oriundos de ambientes híbridos, pois o seu motor de execução não oferece essa capacidade.

• SciCumulus: faz a gerência da execução paralela das atividades de workflows ci- entíficos em nuvens [192]. Sua arquitetura é formada pelas camadas cliente, dis- tribuição, execução e dados. A camada cliente inicia a execução das atividades do workflow e pode ser implantada através de soluções como o Kepler [193]. A camada de distribuição faz o upload/download dos dados e inicia execução paralela que segue o plano de escalonamento para as atividades na nuvem. A camada de execução dis- para a execução dos programas que fazem parte do workflow nas VMs disponíveis. A camada de execução também cuida da proveniência dos dados nos repositórios da camada de dados. O SciCumulus considera as flutuações de desempenho do ambi- ente em seu modelo adaptativo de execução. O SciCumulus não opera em sistemas híbridos e não trata workflows de serviços.

• Trident: o projeto Trident foi criado pela Microsoft como uma ferramenta para a comunidade científica [194]. O Trident é implentetado sobre o Microsoft Windows Workflow Foundation [195], e usa as funcionalidades de motores de workflow ba- seados no Microsoft SQL Server e na tecnologia de clusters Windows HPC Server. Parte integrante do projeto, DryadLINQ [196] combina a infraestrutura Dryad [197] para execução de sistemas paralelos e a linguagem de consulta LINQ (Language- Integrated Query), uma extensão da linguagem de programação C#. Dryad foi concebida para simplificar a implementação de aplicações distribuídas em clusters baseados em computadores que usam sistema Windows, mas ela requer conheci- mento técnico dos usuários. DryadLINQ é uma camada de abstração que simplifica o processo de implementação de aplicações baseadas em Dryad. Apesar de ofere- cer muitas facilidades para execução de workflows é uma solução proprietária cuja integração com outras plataformas não é trivial. Talvez por essa razão não ofereça suporte adequado a ambientes híbridos.

• Condor: Condor é um batch queueing system para gerenciar tarefas de computação intensa [133]. Reuni as funções de um escalonador, um gerente de recursos e um sistema de balanceamento de carga num só produto. Condor-G [198], uma versão direcionada a grades, une as tecnologias Condor e Globus. Globus é responsável

pela infraestrutura da Grade enquanto que o Condor-G é usado para submissão e alocação de tarefas, recuperação de erros (pontos de verificação) e pela criação de um ambiente amigável de execução.

Outro componente do projeto Condor é o meta-escalonador DAGMan (Directed Acyclic Graph Manager), um serviço para execução de múltiplas tarefas com depen- dências, na forma declarativa. A representação dessas dependências é especificada como parte de um DAG (Directed Acyclic Graph - Grafo Acíclico Direcionado), onde os nós representam programas e as arestas representam as dependências entre esses programas. Os DAGs são definidos através de diretivas armazenadas em arquivos de texto, onde cada nó representa uma tarefa Condor, que usa alguns arquivos como entrada e gera outros arquivos como saída da execução. Os arquivos são executados pelo uso do comando condor submit dag <dagfile>. O lado esquerdo da Figura 3.8 mostra o DAG representado pelas diretivas que estão no lado direito.

Figura 3.8: Uma submissão com o Condor DAGMan.

Vários projetos, inclusive alguns aqui descritos, usam o Condor. As vantagens do DAGMan são a simplicidade na especificação do workflow através de arquivo texto e a sua integração com escalonadores. Como desvantagens não oferece uma represen- tação XML das descrições, é um sistema fechado, não oferece uma interface gráfica e é direcionado para tarefas apresentando restrições quando usado na gerência de serviços.

• Pegasus:

O projeto Pegasus engloba um conjunto de tecnologias para executar aplicações ba- seadas em workflow em vários ambientes computacionais incluindo desktops, clus- ters, grades e nuvens. O seu principal componente, o Pegasus Workflow Manage- ment System (WMS), permite aos usuários construirem workflows abstratos sem

identificar a localização dos recursos computacionais, sem detalhes específicos do ambiente operacional ou especificações de baixo nível de middlewares como Condor, Globus ou EC2 Amazon. O WMS recebe do usuário uma representação abstrata do workflow (um DAG) e gera o workflow executável conforme a disponibilidade dos recursos computacionais. O Pegasus usa três componentes principais, cujo relacio- namento é mostrado no lado esquerdo da Figura 3.9: o Pegasus Mapper, o Condor DAGMan e o Condor Schedd. O Pegasus Mapper gera o workflow executável ba- seado no abstrato fornecido pelo usuário. Ele encontra o software apropriado, os dados e os recursos computacionais necessários. O Mapper também reestrutura o workflow para otimizar o desempenho e acrescenta transformações para o gerencia- mento de dados e proveniência. O Condor DAGMan executa as tarefas do workflow respeitando suas dependências. O Condor Schedd efetivamente executa as tarefas do workflow, seja nos recursos locais ou remotos.

Figura 3.9: Componentes Pegasus e os estágios de tratamento de dados [199].

O Mapper pode fazer otimizações no workflow nos estágios de entrada e saída de dados, conforme ilustrado no lado direito da Figura 3.9. Por exemplo, em work- flows de grande porte o Mapper pode limitar o número de estágios independentes de entrada e controlar o número de conexões com o sistema de armazenamento. O Mapper pode também incluir tarefas de limpeza para eliminar arquivos temporários ou remover tarefas para os quais já existam resultados (reutilização de dados). Re- centemente houve a inclusão do Pegasus Lite, um motor leve semiautomático para

execução de tarefas em nós de trabalho remotos em VMs da nuvem (ao alto na Fi- gura 3.9). Pegasus Lite trabalha sob a gerência do Pegasus WMS, de quem recebe as tarefas, sendo responsável pela gerência da execução e do aprovisionamento dos dados nas VMs.

O projeto Pegasus abriga uma série de trabalhos de gerência de workflow. Da extensa relação, disponível em [200] podem ser destacados [201, 202, 203, 204, 205, 199] que tratam diretamente de ambientes híbridos com combinações diversas de grade e nuvem pública. Com a recente inclusão do Pegasus Lite agora é possível ao sistema Pegasus gerenciar de forma distribuída a execução de workflows em um ambiente híbrido e heterogêneo. O desenho arquitetônico é semelhante ao usado no CEO. No entanto, o Pegasus ainda é direcionado à execução de tarefas não oferecendo facilidades como a publicação dinâmica, que são fundamentais para a execução de workflows de serviços em nuvens.

Alguns trabalhos propõem soluções para execução de workflows em grades ou em nu- vens, mas poucos tratam o ambiente híbrido. [206] explora o uso de nuvens em workflows científicos. A abordagem é avaliar as vantagens e desvantagens entre a execução em um ambiente local, se disponível, e a execução remota em um ambiente virtual, acessível atra- vés da Internet. O trabalho em [207] descreve um sistema leve e escalável para execução de workflows para nuvens. O sistema pode executar workflows compostos por múltiplos Haddop MapReduce [139, 152] ou programas legados. No entanto, esses trabalhos não oferecem suporte à execução de serviços na nuvem.

Em [208] os autores discutem questões que limitam o uso de nuvens para aplicações altamente distribuídas em sistemas híbridos. Entretanto, não analisam a questão da in- teroperabilidade entre plataformas distintas e também não oferecem suporte a workflows de serviços. Os autores propõem um sistema híbrido formado pelo DIET Grid [209] e o Eucalyptus em [210]. Eles mostram caminhos para conectar essas duas arquiteturas bem como as requisições para fazê-lo, mas não discutem o suporte a serviços ou workflows. Em [211], os autores mostram uma solução que automaticamente escalona os passos do workflow em hosts sub-utilizados e provê novos hosts usando a infraestrutura da nuvem. Esse interessante trabalho estende a implementação BPEL [39] para escalonar dinami- camente os serviços chamados em um processo, baseado na carga dos hosts alvo. Para