CEO - uma infraestrutura para orquestração de workflows de serviços em ambientes computacionais híbridos

“CEO - Uma Infraestrutura para Orquestração de

Workflows de Serviços em Ambientes

Computacionais Híbridos”

CAMPINAS

2014

Ana Regina Machado - CRB 8/5467

Senna, Carlos Roberto,

Se58c SenCEO - uma infraestrutura para orquestração de workflows de serviços em ambientes computacionais híbridos / Carlos Roberto Senna. – Campinas, SP : [s.n.], 2014.

SenOrientador: Edmundo Roberto Mauro Madeira.

SenTese (doutorado) – Universidade Estadual de Campinas, Instituto de Computação.

Sen1. Fluxo de trabalho. 2. Computação em nuvem. 3. Redes de computadores. I. Madeira, Edmundo Roberto Mauro,1958-. II. Universidade Estadual de Campinas. Instituto de Computação. III. Título.

Informações para Biblioteca Digital

Título em outro idioma: CEO - an infrastructure to service workflow orchestration in hybrid computational systems

Palavras-chave em inglês: Workflow

Cloud computing Computer networks

Área de concentração: Ciência da Computação Titulação: Doutor em Ciência da Computação Banca examinadora:

Edmundo Roberto Mauro Madeira [Orientador] Thaís Vasconcelos Batista

Bruno Richard Schulze Islene Calciolari Garcia

Nelson Luis Saldanha da Fonseca Data de defesa: 27-10-2014

Programa de Pós-Graduação: Ciência da Computação

Powered by TCPDF (www.tcpdf.org)

CEO - Uma Infraestrutura para Orquestração de

Workflows de Serviços em Ambientes

Computacionais Híbridos

Carlos Roberto Senna

27 de outubro de 2014

Banca Examinadora:

• Prof. Dr. Edmundo Roberto Mauro Madeira (Orientador) • Profa. Dra. Islene Calciolari Garcia

Instituto de Computação - UNICAMP • Prof. Dr. Nelson Luis Saldanha da Fonseca

Instituto de Computação - UNICAMP • Profa. Dra. Thaís Vasconcelos Batista

Departamento de Informática e Matemática Aplicada - UFRN • Prof. Dr. Bruno Richard Schulze

Laboratório Nacional de Computação Científica • Profa. Dra. Maria Beatriz Felgar de Toledo

Instituto de Computação - UNICAMP (Suplente) • Prof. Dr. Luiz Eduardo Buzato

Instituto de Computação - UNICAMP (Suplente) • Prof. Dr. Daniel Macêdo Batista

Instituto de Matemática e Estatística - USP(Suplente)

1_{Suporte financeiro de: Bolsa do CNPq (processo 142574/2007-4) 2007–2009}

Over the last few years good results have been achieved in initiatives of parallel and dis-tributed computing that culminated in computational clouds, transforming the Internet into a virtual processing plant. Complex applications organized by workflows in general are candidates for parallelization, and can have their performance strongly benefited when executed on grids, clouds, or hybrid environments. However, it is still up to the user a significant part of preparing this environment (software and hardware) before using all that computing power for execution of workflows. This thesis presents an infrastructure for managing the execution of workflows with tightly coupled services in hybrid environ-ments composed of grids and computational clouds. The Infrastructure, called Cloud Execution Orchestration (CEO), consists of a middleware that makes the management and execution of workflows through the CEO Language (CEOL) specially designed for building workflows of services for these environments. The proposed infrastructure sup-ports the execution of workflows interacting with the domains of the environment (grids and clouds) transparently without any user intervention. With CEOL the user can build abstract workflows, without the location of computational resources, since resources will be chosen in conjunction with the scheduler and the CEO going to prepare them be-fore the execution. Besides of functionalities for provisioning services on demand during the execution of workflows, the macro architecture facilitates the connection of private cloud with public cloud and supports parallel processing because may operate in hybrid environments formed by the combination of computational grids and clouds.

Ao longo dos últimos anos bons resultados foram alcançados em iniciativas de computa-ção paralela e distribuída que culminaram nas nuvens computacionais, transformando a Internet em uma usina virtual de processamento. Aplicações complexas organizadas atra-vés de workflows em geral são candidatas à paralelização e podem ter seu desempenho fortemente beneficiado quando executadas em grades, nuvens ou ambientes híbridos. No entanto, ainda cabe ao usuário uma parte significativa da preparação desse ambiente (soft-ware e hard(soft-ware) antes de efetivamente usar todo esse poder computacional na execução de workflows. Esta tese apresenta uma infraestrutura para gerenciamento da execução de workflows de serviços fortemente acoplados em ambientes híbridos compostos por grades e nuvens computacionais. A infraestrutura denominada Cloud Execution Orchestration (CEO) é composta por um middleware que faz a gerência da execução de workflows e por uma linguagem (CEO Language - CEOL) especialmente desenhada para a constru-ção de workflows de serviços para esses ambientes. A infraestrutura proposta suporta a execução de workflows interagindo com os domínios do ambiente (grades e nuvens) de forma transparente sem qualquer intervenção do usuário. Com a CEOL o usuário pode construir workflows abstratos, sem a localização dos recursos computacionais, pois os re-cursos serão escolhidos em conjunto com o escalonador e serão devidamente preparados pelo CEO para a execução. Além das funcionalidades para aprovisionamento de serviços sob demanda durante a execução de workflows, a macro arquitetura facilita a conexão da nuvem privada com nuvens públicas e oferece suporte ao processamento paralelo na medida em que opera em ambientes totalmente híbridos formados pela combinação de grades e nuvens computacionais.

Agradeço a minha família, a minha mãe, ao meu pai (em memória), a Glória e ao Pedro que são a razão de tudo.

Ao meu orientador, Professor Edmundo R. M. Madeira, pela paciência e perseverança, pela ajuda e por acreditar sempre que o objetivo seria atingido. Este trabalho não seria possível sem a sua participação.

Ao Prof. Guido Araujo, do Instituto de Computação da UNICAMP, pela compreenção e ajuda.

Aos meus professores da graduação na UFSCar, José Hiroki Saito e Durval Makoto Aka-matu (em memória), que mais uma vez apoiaram a minha iniciativa.

Ao Professor Hugo Fragnito, do Instituto de Física da UNICAMP, por mais uma vez ter confiado no meu potencial.

Aos amigos Francis, Rose e Caio que agiram como catalisadores nessa minha jornada ao mundo científico.

Ao mentor e amigo Professor Marco Aurélio Pinheiro Lima, do Instituto de Física da UNICAMP, pelo apoio, incentivo e ensinamentos.

Aos colegas do Laboratório de Redes de Computadores do Instituto de Computação. Ao Instituto de Computação pela oportunidade dada.

Ao CNPq que tornou este trabalho possível através da Bolsa de Doutorado oferecida.

Lema do montanhista

Abstract ix Resumo xi Agradecimentos xiii xv 1 Introdução 1 1.1 Motivação . . . 1

1.2 Aspectos sobre as Tecnologias Envolvidas . . . 2

1.3 Objetivos . . . 4

1.4 Principais Contribuições . . . 5

1.5 Publicações . . . 7

1.6 Estrutura do Trabalho . . . 7

2 Definições e Conceitos Relacionados 9 2.1 SOC e Composição de Serviços . . . 9

2.2 Grades Computacionais . . . 12 2.3 Virtualização . . . 16 2.4 Nuvens Computacionais . . . 16 2.5 Ambiente Híbrido . . . 24 2.6 Sistemas de Workflow . . . 28 3 Trabalhos Relacionados 31 3.1 Grades Computacionais . . . 31

3.1.1 Infraestruturas de grade computacional . . . 32

3.1.2 Globus Toolkit . . . 35

3.2 Nuvens Computacionais . . . 38

3.2.1 Amazon Elastic Compute Cloud . . . 38 xvii

3.3.1 Sistemas de Gerência . . . 50

3.3.2 Linguagens . . . 60

3.3.3 Aprovisionamento de Serviços Sob Demanda . . . 64

3.3.4 Integração com Escalonadores . . . 65

3.3.5 Monitoramento e Proveniência . . . 66

3.4 Testbed Orientado a Serviços . . . 67

4 CEOL: Uma Linguagem para Construção de Workflows 69 4.1 A Estrutura de um Workflow CEOL . . . 71

4.2 Notação e Considerações Gerais . . . 72

4.2.1 Atividade . . . 73

4.2.2 Expressão . . . 73

4.3 Elementos da Linguagem . . . 74

4.3.1 workflow . . . 74

4.3.2 import . . . 75

4.3.3 er, domain e scheduler . . . 76

4.3.4 definitions . . . 77 4.3.5 process . . . 78 4.3.6 variables e variable . . . 79 4.3.7 services e gsh . . . 80 4.3.8 faultHandlers . . . 83 4.3.9 fileLocation e fileCopy . . . 84 4.3.10 invoke . . . 85 4.3.11 assign . . . 87 4.3.12 echo . . . 88 4.3.13 return . . . 88 4.3.14 exit . . . 89 4.3.15 clear . . . 89 4.3.16 if . . . 90 4.3.17 while . . . 90 4.3.18 sequence . . . 90 4.3.19 flow . . . 91 4.3.20 transfer . . . 91 4.3.21 execute . . . 92 4.3.22 javacode . . . 93

4.4 Um exemplo de workflow CEOL - Aplicação Filtro de Mediana . . . 93 xix

5.1 Principais componentes . . . 111

5.2 CEO Dashboard: a interface com o usuário . . . 118

5.3 CEO Run Service . . . 120

5.4 CEO Maestro: a Gerência de Workflows . . . 122

5.4.1 O Modelo para Integração entre Gerência de Workflows e Escalo-nadores . . . 124

5.4.2 Serviço para Integração com Escalonadores (SIS) . . . 132

5.4.3 Modelo CEO do Mapa de Alocação de Recursos para Ambientes Híbridos . . . 134

5.4.4 A Criação de Instâncias dos Serviços (ICS) e a geração do workflow concreto . . . 136

5.4.5 Execução do Workflow Concreto (WES) . . . 138

5.4.6 Monitoramento e Modelo de Proveniência . . . 139

5.4.7 Acesso a VMs em “Domínios Fechados” . . . 140

5.4.8 Serviço para Integração com as Nuvens do Ambiente Híbrido (CMS/-CIS) . . . 141

5.5 CEO Utility Services . . . 142

5.5.1 Serviço para Publicação Dinâmica (DDS) . . . 143

5.5.2 Serviço para Monitoramento de Recursos (RMS) . . . 147

5.5.3 Serviço para Integração com Sistemas de Gerência de Redes Virtuais (VNIS) . . . 151

5.6 CEO Assistant Maestro: interligação entre os domínios . . . 152

5.6.1 CEO Inter Domain Control Protocol . . . 153

5.6.2 Execução Típica com o Suporte do Assistant Maestro . . . 155

5.7 Modelo para configuração dos domínios do ambiente . . . 155

6 Aplicações, Experimentos e Resultados 161 6.1 CEO Service-Oriented Testbed (SOT) . . . 161

6.1.1 A Infraestrutura do SOT . . . 162

6.1.2 Aspectos Sobre o Protótipo de Software . . . 163

6.1.3 Resultados com o Testbed Orientado a Serviços . . . 163

6.1.4 Avaliação de Máquinas Virtuais no SOT . . . 168

6.2 Cenários e Aplicações Sobre Publicação Dinâmica de Serviços . . . 177

6.2.1 Avaliando os Custos da Publicação Dinâmica de Serviços . . . 177

6.2.2 Outros Cenários . . . 179

6.2.3 Análise Qualitativa . . . 180 xxi

6.3.2 Monitoramento como ferramenta para avaliação de nuvens públicas 184 6.3.3 Estudo de Caso . . . 184 6.4 Cenários de Aplicação em Nuvens Híbridas . . . 185 6.4.1 Escalonamento de Workflows Otimizado por Custo . . . 186 6.5 Caracterização de Workflows e o Serviço Emulador . . . 189 6.6 Gerência de Redes Virtuais em Nuvens Computacionais . . . 192 6.6.1 Sobrecarga pelas Redes Virtuais no Ambiente . . . 194 6.6.2 Desempenho das Redes Virtuais . . . 196 6.6.3 Adaptação das Redes . . . 198 6.6.4 Um Estudo de Caso sobre Adaptação das Redes . . . 200 6.7 Avaliando Escalonadores de Workflows de Serviços em Nuvens

Computa-cionais . . . 201 6.7.1 Workflows Emulados . . . 202 6.7.2 Precisão de Emulação . . . 204 6.7.3 Avaliação de Políticas de Escalonamento Através da Emulação de

Workflows . . . 207

7 Conclusão 211

Referˆencias Bibliogr´aficas 215 A Estrutura de Diretórios do CEO 243 B Configuração de Domínios - Testbed LRC 245

B.1 Configuração do Ambiente Híbrido . . . 245 B.2 Configuração da Grade Privada Local . . . 245 B.3 Configuração da Nuvem Privada Local . . . 247 B.4 Configuração para Acesso à Nuvem Pública . . . 249 B.5 Configuração das Classes de Hosts . . . 252

C Workflow Filtro de Mediana 255

C.1 Workflow submetido pelo usuário . . . 256 C.2 Arquivo intermediário gerado pelo WMS e enviado ao DGS . . . 258 C.3 Arquivo CEO-DAG gerado pelo DGS . . . 261 C.4 Mapa de Alocação para Ambiente Híbrido (Grade e Nuvem Privada) . . . 262 C.5 Mapa de Alocação para Ambiente Híbrido (Grade e Nuvem Pública Amazon)264 C.6 Mapa de Alocação para Ambiente Híbrido (Grade e Amazon usando VPC) 266

5.1 Mapa de alocação para o ambiente Grade + Nuvem Privada. . . 135 5.2 Mapa de alocação para o ambiente Grade + Nuvem Privada + Nuvem

Pública. . . 142 6.1 Especificação dos Recursos Computacionais. . . 169 6.2 Desempenho dos Recursos Computacionais nos Experimentos. . . 176 6.3 Características dos recursos computacionais. . . 177 6.4 Tempos médios para a execução dos workflows (ms). . . 178 6.5 Tempos das atividades para a publicação dinâmica (ms). . . 178 6.6 Classes de VMs. . . 184 6.7 Recursos da Nuvem Híbrida. . . 186 6.8 Cenários usados para avaliar o desempenho das redes virtuais. . . 196 6.9 Tempos de Execução Reais e Emulados para os Serviços de Filtro de Mediana.204 6.10 Tempos de Execução dos Workflows Montage 25 e 50 Emulados. . . 205 6.11 Resultados do Workflow LIGO. . . 206 6.12 Tempo de Execução para Filtro de Mediana. . . 207 C.1 Mapa de alocação para o ambiente Grade e Nuvem Privada . . . 263 C.2 Mapa de alocação para o ambiente Grade e Nuvem Pública Amazon . . . . 265

2.1 Arquitetura da Nuvem Computacional ([4]). . . 18 2.2 Modelo NIST de Referência Conceitual para Nuvem Computacional ([76]). 20 2.3 Nuvem pública ([76]). . . 22 2.4 Nuvem privada ([76]). . . 22 2.5 Nuvem comunitária ([76]). . . 23 2.6 VPC configurada na Amazon. . . 24 2.7 Nuvem híbrida ([76]). . . 25 3.1 Serviços e componentes do Globus Toolkit [90]. . . 36 3.2 Uso do WS-GRAM na submissão de tarefas. . . 37 3.3 Componentes do Nimbus Workspace [154]. . . 45 3.4 Arquitetura OpenNebula. . . 46 3.5 Arquitetura conceitual do OpenStack Grizzly [163]. . . 47 3.6 Macro arquitetura ASKALON [184]. . . 54 3.7 Macro arquitetura do [190]. . . 55 3.8 Uma submissão com o Condor DAGMan. . . 57 3.9 Componentes Pegasus e os estágios de tratamento de dados [199]. . . 58 4.1 Filtro de Mediana. . . 94 4.2 DAG para o Workflow que aplica o filtro de mediana em 5 partes. . . 95 5.1 Macro funcionalidades do CEO em um ambiente híbrido. . . 110 5.2 Componentes de software da arquitetura CEO. . . 111 5.3 Os serviços do CEO Portal. . . 112 5.4 Macro arquitetura do CEO Maestro. . . 113 5.5 CEO Assitant Maestro. . . 114 5.6 Os serviços do CEO Utility Services. . . 115 5.7 Os componentes e serviços da infraestrutura CEO. . . 115 5.8 O relacionamento entre os serviços durante a execução do workflow. . . 116 5.9 CEO Dashboard - Interface com o usuário. . . 118 5.10 CEO Dashboard - Navegando nas três áreas do usuário. . . 118

5.13 Acompanhando as submissões pelo Dashboard. . . 121 5.14 Arquitetura do CEO Maestro. . . 123 5.15 DAG original abstrato e DAG dgs. . . 125 5.16 Workflow em ambiente oportunista. . . 145 5.17 Arquitetura do Assistant Maestro. . . 153 6.1 CEO Service-Oriented Testbed (SOT). . . 162 6.2 Tempo da Aplicação Local x Serviços. . . 165 6.3 Tempo de Execução: Arquivo Único x Arquivo Segmentado. . . 166 6.4 Tempo de Execução em Paralelo de Serviços em Recurso Único. . . 167 6.5 Comparação Entre Execução Local e Execução Paralela. . . 167 6.6 Tempos de Execução das Aplicações NS2. . . 171 6.7 Tempos de Execução dos workflows simples. . . 172 6.8 Tempos de Execução dos workflows sequenciais e paralelos. . . 172 6.9 Tempos de Execução de Aplicações NS2 com Arquivo Log. . . 173 6.10 Tempos de Execução de de Workflows com Arquivo Log. . . 173 6.11 Execução de Workflow Paralelo com Log x Execução de Workflow Paralelo

sem Log. . . 174 6.12 Sobrecarga de CPU na Execução de Workflows Paralelos com e sem Log. . 175 6.13 Makespan Cumulativo para o workflow. . . 185 6.14 Resultados para imagens de 5.000 × 5.000. . . 187 6.15 Resultados para imagens de 9.500 × 9.500. . . 188 6.16 Estruturas Básicas de um Workflow [248]. . . 189 6.17 DAG Original x DAG Emulador. . . 190 6.18 Rede Substrato. . . 193 6.19 Workflow usado para avaliar a sobrecarga das redes virtuais. . . 194 6.20 Resultados para imagens com 10.000 × 10.000 pontos em todas as redes

disponíveis. . . 195 6.21 Desempenho das redes virtuais roteando até 3 fluxos através dos enlaces

1Gbps e 100Mbps. . . 197 6.22 Workflow usado na avaliação da adaptação das redes virtuais. . . 198 6.23 Estudo de caso sobre adaptação de redes virtuais para o workflow da Figura

6.22. . . 199 6.24 Workflow que aplica o filtro de mediana fragmentando o arquivo em 3 partes.200 6.25 Tempos de transferência de dados para as ações tomadas. . . 201 6.26 Workflow que aplica o filtro de mediana em 5 partes. . . 202

6.29 Makespam médio para a emulação do filtro de mediana. . . 208 6.30 Makespam médio para a emulação do Montage e LIGO. . . 209 6.31 Makespam médio para a aplicação real do filtro de mediana. . . 209

Introdução

1.1 Motivação

Ao longo dos últimos anos bons resultados foram alcançados em iniciativas de computa-ção paralela e distribuída que culminaram nas nuvens computacionais, transformando a Internet em uma usina virtual de processamento. Neste momento a tecnologia nos per-mite integrar recursos locais (redes, grades e nuvem privada) a centros de computação intensiva (datacenters), formando um ambiente híbrido e heterogêneo acessível através da Internet.

Aplicações complexas organizadas através de workflows em geral são candidatas à paralelização e podem ter seu desempenho fortemente beneficiado quando executadas em grades, nuvens ou ambientes híbridos. Um workflow é uma descrição precisa de um procedimento, um processo multipasso para coordenar várias tarefas, como um roteiro sofisticado [1]. Cada tarefa representa a execução de um processo computacional, como a execução de um programa, o envio de uma consulta a um banco de dados ou a invocação de um serviço para utilizar um recurso remoto. Os dados de saída de uma tarefa são con-sumidos pelas tarefas subsequentes de acordo com uma topologia gráfica predefinida que orquestra o fluxo de dados. Além do que, em geral, a topologia oferece boas possibilidades para processamento paralelo. Sistemas para gerência de workflows podem automatizar a sua execução na tentativa de manter o usuário em seu foco de trabalho sem perder tempo gerenciando o sistema computacional.

No entanto, ainda cabe ao usuário uma parte significativa da preparação desse am-biente (software e hardware) antes de efetivamente usar todo esse poder computacional na execução de workflows. A motivação dessa tese é justamente essa falta de suporte ao usuário ainda existente nesses ambientes computacionais. As grades oferecem bom suporte ao processamento paralelo, mas seus sistemas de gerência de workflow ainda não oferecem suporte adequado principalmente aos workflows que processam serviços com

tarefas fortemente acopladas. Como um exemplo desse quadro ainda cabe ao usuário preparar o ambiente publicando previamente todos os serviços envolvidos. Nas nuvens computacionais o suporte é ainda menor, pois estas não oferecem suporte ao paralelismo. Essa restrição está sendo contornada com o uso de grades previamente instaladas em ima-gens de ambientes operacionais. A Amazon [2] é uma das poucas alternativas ao permitir a montagem de clusters com o uso da grade Oracle [3] em seu ambiente. Mas cabe ao usuário a montagem do cluster instanciando as máquinas virtuais preparando-as para o uso e pagando pelos recursos já na fase de preparação.

O ambiente híbrido potencializa os requisitos necessários para a execução de work-flows, pois cada domínio tem suas próprias exigências. Em uma grade de produção, com recursos sempre disponíveis, é necessário publicar todos os serviços em todos os recursos para que todos os recursos estejam prontos para o uso. Mas isso gera uma so-brecarga causando queda no desempenho e restringindo recursos com menor configuração no processamento de tarefas com maiores requisitos. No entanto, mesmo optando pela sobrecarga a estratégia não é suficiente em grades oportunistas, pois esse tipo de domínio demanda observação contínua dos recursos disponíveis para que possam ser aproveitados. Na nuvem seria necessário preparar imagens com todos os serviços publicados para que estas tenham a capacidade de apoiar a criação de máquinas virtuais (VM) prontas para o uso. No entanto, isso não seria suficiente pois na nuvem há o problema da localização dos recursos, pois as VMs são criadas pela infraestrutura da nuvem que lhes confere IPs conforme o seu mapeamento. Para aproveitar os recursos da nuvem o usuário deve criar todas as VMs, obter sua localização e fazer os devidos acertos no workflow. Em nuvens híbridas, de forma similar ao que ocorre em grades oportunistas, o usuário deve observar a disponibilidade dos recursos na sua nuvem privada, e só quando for necessário, “alugar” recursos na nuvem pública, pois de outra forma não obteria a melhor relação custo/-benefício. Além disso, um ambiente híbrido cujos domínios usem tecnologias distintas exige do usuário fluência em todos os dialetos das tecnologias com implicações diretas na construção e execução dos workflows.

A infraestrutura proposta nesta tese exime o usuário dessas tarefas operacionais. Ao trabalhar com workflows abstratos, sem a identificação dos recursos, publicar dinamica-mente os serviços e preparar os recursos computacionais sejam físicos ou virtuais indepen-dente do domínio no qual estejam, permite ao usuário tratar apenas da lógica de execução do workflow, deixando o trabalho de preparação para o sistema de workflow.

1.2 Aspectos sobre as Tecnologias Envolvidas

A computação em nuvem leva o usuário ao mundo da supercomputação dando-lhe a sen-sação de poder computacional e capacidade de armazenamento ilimitados, acessíveis a

partir da sua estação de trabalho. Ao usar uma nuvem, o usuário acessa recursos de com-putação como utilitários que podem ser alugados e liberados conforme a necessidade [4]. Através da virtualização a nuvem oferece recursos computacionais com várias opções de arquitetura de hardware, de memória, de armazenamento e conectividade acessíveis via Internet. A computação em nuvem provê hardware sob demanda permitindo que empresas executem seus sistemas proprietários transformando gastos fixos em despesas conforme o consumo reduzindo investimentos. Ela oferece como principais benefícios a preservação do investimento inicial, a redução de custos operacionais, a redução de custos de manu-tenção e escalabilidade fornecida sob demanda. Tais características da nuvem fornecem elasticidade ao ambiente de computação do usuário tornando os sistemas adaptáveis às suas necessidades.

As principais características da computação em nuvem são o auto-atendimento sob demanda, acesso ubíquo à rede, localização independente de recursos (reliability), elas-ticidade rápida (scalability) e pagamento pelo uso. A computação em nuvem pode ser disponibilizada através de três modelos: software como serviço (software as a service - SaaS), plataforma como serviço (platform as a service - PaaS) e infraestrutura como serviço (infrastructure as a service - IaaS), modelos que são baseados nos padrões da Computação Orientada a Serviços (Service Oriented Computing - SOC) [5]. Em qual-quer um desses modelos é possível construir nuvens privadas com acesso de uso exclusivo, nuvens públicas que disponibilizam recursos a todos que estejam dispostos a pagar por seu uso e nuvens híbridas onde a nuvem privada também oferece acesso a recursos vindos da pública para suprir a falta momentânea de recursos em picos de processamento por exemplo. Na computação em nuvem detalhes são abstraídos do usuário. Eles não ne-cessitam ter conhecimento, especialização, ou controle sobre a infraestrutura tecnológica da nuvem que os suporta. Tipicamente a computação em nuvem envolve a provisão de recursos dinamicamente escaláveis, muitas vezes virtualizados, como serviços através da Internet [6].

A Virtualização [7] de recursos é um conceito fundamental nas nuvens computacionais. A virtualização é o processo de apresentação de grupos lógicos ou conjuntos de recursos computacionais que podem ser acessados de forma abstrata com benefícios sobre a confi-guração original dos mesmos. A virtualização de software abstrai o hardware através da criação de interfaces para máquinas virtuais (Virtual Machines - VMs). Tais VMs repre-sentam recursos físicos como unidades de processamento (CPUs), memória, conexões de rede e periféricos (discos, impressoras, etc). Cada VM deve ser um ambiente de execução isolado e independente dos demais. Dessa forma, cada VM pode ter seu próprio sistema operacional, suas aplicações e seus serviços de rede. Esse isolamento dá ao usuário controle total sobre o recurso não exigindo qualquer conhecimento sobre o hardware hospedeiro.

As nuvens públicas oferecem recursos com limitação de interconexão de baixa latência que ainda precisam ser providos por nuvens ou ambientes privados, como por exemplo, grades computacionais previamente instaladas nas imagens de ambientes, que são usadas na instanciação de VMs. Através dessas imagens é possível criar uma grade computacional usando recursos da nuvem para suportar o processamento paralelo.

A facilidade da computação sob demanda oferecida pela nuvem exige maior escalabi-lidade, flexibilidade e disponibilidade dos serviços. Ela permite aos usuários manterem o uso de seus sistemas (computadores, cluster e grades) agregando a nuvem ao seu leque de opções. No entanto a união das tecnologias de grade e nuvem gera um sistema híbrido de computação com novas exigências notadamente para a gerência de recursos. Para atender a esses requisitos é importante que a infraestrutura ofereça reconfiguração com a possibi-lidade de publicação de novos recursos ou atualização dos já disponíveis sem interromper as tarefas em execução. Além disso, apesar de usar o paradigma SOC essas tecnologias não oferecem suporte para a coordenação e composição dinâmica de serviços.

Para permitir o aprovisionamento sob demanda é necessário suportar a instanciação dinâmica de serviços, isto é, colocar o serviço no recurso computacional, publicá-lo para que possa ser tratado por um container e ativar o container para que este possa atender as requisições ao serviço. Em um sistema híbrido composto por nuvem privada com a pos-sibilidade de acesso a nuvens públicas, a gerência de workflow deve atender aos requisitos em alguns níveis. Primeiro deve oferecer facilidades para que o usuário faça submissões sem a obrigação de escolher ou indicar a localização dos recursos computacionais a serem usados. Na esfera da nuvem privada, o gerente de workflow deve encontrar os melhores recursos disponíveis e, quando necessário, fazer a publicação dinâmica dos serviços nesses recursos. Por outro lado, ao nível da nuvem pública a gerência de workflow deve ser capaz de interagir com a interface da nuvem para obter os recursos computacionais. Após isso, deve prepará-los conforme as necessidades do workflow, fazendo a publicação dinâmica dos serviços nos recursos oriundos da nuvem pública quando necessário. Além disso, a gerência de workflow pode oferecer personalizações que permitam o melhor uso das fa-cilidades do sistema híbrido. Um exemplo é a configuração que permite usar a nuvem pública somente em casos onde todas as possibilidades locais já foram esgotadas. Essa configuração aumenta o poder computacional sem investimento em infraestrutura física ampliando as vantagens do uso de nuvens.

1.3 Objetivos

Esta tese apresenta uma infraestrutura para gerenciamento da execução de workflows de serviços fortemente acoplados em ambientes híbridos compostos por grades e nuvens computacionais. A infraestrutura denominada Cloud Execution Orchestration (CEO) é

composta por um middleware que faz a gerência da execução de workflows e por uma linguagem (CEO Language - CEOL) especialmente desenhada para a construção de work-flows de serviços para esses ambientes. A infraestrutura proposta suporta a execução de workflows interagindo com os domínios do ambiente (grades e nuvens) de forma trans-parente sem qualquer intervenção do usuário. Com a CEOL o usuário pode construir workflows abstratos, sem a localização dos recursos computacionais, pois os recursos se-rão escolhidos em conjunto com o escalonador e sese-rão devidamente preparados pelo CEO para a execução. Além das funcionalidades para aprovisionamento de serviços sob de-manda durante a execução de workflows, a macro arquitetura facilita a conexão da nuvem privada com nuvens públicas e oferece suporte ao processamento paralelo na medida em que opera em ambientes totalmente híbridos formados pela combinação de grades e nuvens computacionais.

1.4 Principais Contribuições

• Uma infraestrutura para execução de workflows de serviços em ambientes híbridos. A infraestrutura é formada por um conjunto de serviços que oferecem as

seguintes funcionalidades (Seção 5):

– Publicação dinâmica de serviços: ao identificar a melhor opção de recurso

computacional a infraestrutura pode publicar o serviço nesse recurso se for necessário. A publicação dinâmica é executada não importando se o recurso é da grade ou da nuvem.

– Instanciação dinâmica de serviços: durante a execução do workflow a

infraestrutura procura, na grade e na nuvem, a melhor opção em recursos computacionais disponíveis para executar cada um dos serviços.

– Coordenação automática de referências (endpoint reference service):

ao oferecer instanciação dinâmica, algumas atividades devem ser transparentes ao usuário. Por exemplo, um serviço executado gera um arquivo que é usado em serviços subseqüentes no workflow. Como a localização dos serviços é feita sob demanda, a infraestrutura resolve as referências entre os serviços durante a execução não requerendo a interferência do usuário.

– Execução de workflows abstratos: a infraestrutura CEO trabalha com

com os escalonadores, os serviços do CEO encontram os recursos mais ade-quados ao processamento preparando-os para a execução sem a intervenção do usuário.

– Integração entre nuvens com tecnologias distintas: através da separação

entre as ações de gerência e a troca de informações com o software da nuvem, a infraestrutura CEO pode operar com nuvens que usem tecnologias distintas simultaneamente.

– Operação com domínios fechados: trabalhando de forma distribuída o

CEO pode gerenciar execuções em domínios fechados onde os recursos são acessíveis apenas a partir de pontos específicos do ambiente (portais).

• Linguagem para construção de workflows: além de permitir ao usuário des-crever workflows de serviços a CEO Language (CEOL) dispõe de facilidades que são imprescindíveis ao ambiente da nuvem. Os workflows devem ser abstratos pois o usuário em geral não sabe onde estão os recursos computacionais. A CEOL cobre todos os requisitos de abstração suportando a movimentação de arquivos inclusive o tratamento para upload e download. A linguagem também oferece diretivas espe-cíficas para a nuvem como por exemplo identificação de tipo de imagem (Seção 4). • Um modelo para a construção de ambiente híbrido e heterogêneo: o modelo de arquitetura proposto permite a integração de domínios formados pela agregação das tecnologias de grade, nuvem privada e nuvem pública. O modelo é formalizado através de documentos XML/XML Schema (Seção 5.7).

• Um modelo para integração entre gerência de workflow e escalonadores: a arquitetura do sistema de gerência de workflows define um modelo de integração com escalonadores. O CEO tem componentes para gerar informações a partir do workflow CEOL em grafos acíclicos direcionados (Direct Acyclic Graphs - DAGs) usados pelos escalonadores para indicar quais recursos computacionais devem ser usados. O modelo é formalizado através de documentos XML/XML Schema (Se-ção 5.4.1).

• Um modelo para integração entre gerência de workflow e o

monitora-mento dos ambientes: a arquitetura CEO define como agregar ao monitoramonitora-mento

da execução de workflows informações vindas do monitoramento feito nos ambientes de grade ou de nuvem. O modelo, formalizado através de documentos XML/XML Schema, permite que outros produtos/plataformas tenham acesso às informações do monitoramento facilitando a integração (Seção 5.5.2).

• Um modelo para integração entre gerência de workflow e sistemas de

gerência de redes virtuais: a arquitetura CEO define interfaces que permitem a

troca de informações entre esses dois níveis de gerência (Seção 5.5.3).

• A implementação de um protótipo: para validar a infraestrutura proposta foi implementado um protótipo usado na execução de vários tipos de workflows e experimentos.

• Testbed: foi construído um testbed onde onze máquinas físicas são interligadas através de duas redes locais. O testbed tem configuração flexível que permite avaliar a execução de workflows em grades, nuvem privada e ambientes híbridos. Foi usado também para avaliar políticas de escalonamento e suportar o desenvolvimento e avaliação de sistemas para virtualização de redes (Seção 6.1).

• Serviço emulador de workflows: para facilitar as avaliações foi construído um serviço que permite a emulação de workflows sem requerer os programs e os arqui-vos das aplicações reais. Com esse serviço emulador foi possível avaliar workflows que emulam o comportamento de aplicações científicas amplamente usadas como Montage [12] e LIGO [13] (Seção 6.5).

1.5 Publicações

O trabalho desta tese gerou 13 publicações. A primeira versão da CEOL (denominada GPOL), foi publicada em [14]. Avaliações sobre a execução de workflows de serviços fortemente acoplados foram publicados em [15] e [16]. Os resultados obtidos com a publicação dinâmica de serviços foram mostrados em [17]. Resultados obtidos com a modelagem e avaliação da execução de workflows de serviços em ambiente híbrido (grade e nuvem) foram mostrados em [18]. Os resultados obtidos com experimentos para avaliação de gerência em redes virtuais foram apresentados em [19], [20] e [21]. Os resultados obtidos na avaliação de desempenho de máquinas virtuais em grades orientadas a serviços foram mostrados em [22]. Os resultados do uso do testbed e da infraestrtura na avaliação de políticas de escalonamento foram apresentados em [23], [24] e [25] e os resultados da infraestrutura no monitoramento em nuvens privadas foram mostrados em [26].

1.6 Estrutura do Trabalho

• Capítulo 3: mostra os trabalhos relacionados aos tópicos desta tese.

• Capítulo 4: descreve a linguagem para construção de workflows para ambientes híbridos CEO Language (CEOL).

• Capítulo 5: apresenta a arquitetura CEO e descreve seus componentes.

• Capítulo 6: mostra aplicações e experimentos que demonstram as funcionalidades

do CEO e resultados obtidos com o seu uso.

• Capítulo 7: apresenta as conclusões sobre o trabalho, comenta sobre suas princi-pais contribuições e possíveis extensões.

Definições e Conceitos Relacionados

Este capítulo apresenta os conceitos básicos e definições gerais usadas nesta tese. Inicial-mente são definidos Serviços Web, a computação orientada a serviços e como podem ser feitas composições de serviços. Em seguida é definido o modelo de Grade Computacio-nal, sua arquitetura e caracteríticas com ênfase nas arquiteturas orientadas a serviço, um dos principais focos dessa tese. Os conceitos sobre Virtualização são apresentados intro-duzindo a definição da Computação em Nuvem para em seguida fazer a caracterização de Ambientes Híbridos formados por combinações diversas entre grades e nuvens (priva-das, públicas e híbridas) usadas em conjunto. Encerrando o capítulo são apresentados os conceitos sobre sistemas para Gerência de Workflows.

2.1 SOC e Composição de Serviços

Os serviços são os elementos fundamentais do paradigma computacional chamado de Computação Orientada a Serviços (SOC - Service-oriented Computing), onde as aplica-ções são desenvolvidas como uma composição de serviços [5]. Ao aplicarmos os conceitos de SOC na Internet criamos os Serviços Web. Serviço Web (WS) define uma técnica para descrição de componentes de software, métodos para acessar esses componentes e métodos para localizar e identificar esses componentes. WS permite o desenvolvimento de aplicações distribuídas para a Internet. Os Serviços Web oferecem interoperabilidade universal, são baseados nos protocolos abertos da Internet, tem como foco a troca de men-sagens e permitem a criação de aplicações com um baixo nível de integração (fracamente acopladas). O conceito WS é fundamental nesta tese. Para suportar o paralelismo nos workflows, optou-se por usar grades computacionais baseadas na arquitetura OGSA, onde os serviços da grade são modelados como WS [27]. Na nuvem computacional o conceito é nativo uma vez que o conceito de nuvem foi criado com base no paradgima da orientação a serviços [28]. Além disso, o principal objetivo da infraestrutura aqui proposta é gerenciar

a execução de composições de serviços (workflows).

“Um WS é um sistema de software projetado para suportar interoperabilidade da inte-ração máquina-a-máquina sobre uma rede. Ele tem uma interface descrita em um formato processável pela máquina (especificamente WSDL - Web Services Description Language). Outros sistemas interagem com um WS da maneira prescrita através de mensagens SOAP (Simple Object Access Protocol), tipicamente transportadas usando HTTP (Hypertext Transfer Protocol) com conteúdo XML (eXtensible Markup Language) em conjunto com outros protocolos da Internet” [29]. SOAP [30] provê mensagens entre o provedor do serviço e o requisitante. É um mecanismo que envolve a XML [31] que define convenções para RPC (Remote Procedure Call) e convenções para mensagens, sendo independente do protocolo de transporte (HTTP por exemplo). SOAP é a forma com que os WSs são invocados. WSDL é um documento XML que descreve operações, seus parâmetros e tipos de dados requeridos. Um documento WSDL [32] também contém informações sobre como acessar o serviço. O serviço é identificado por uma URI (Uniform Resource Identifier), mas pode ser uma entrada no UDDI (Universal Description, Discovery and Integration) [33].

Os Serviços Web estão migrando de seu modelo inicial e estão sendo usados em intera-ções mais robustas que fazem parte dos processos de negócio [34]. Os WSs são compostos ou agregados de maneira a formar aplicações distribuídas que envolvem vários participan-tes. Esta composição de WSs pode ser feita através de conceitos como Orquestração ou Coreografia [35]. A Coreografia estabelece protocolos para definir como deve ser a troca de mensagens entre os WSs participantes do processo de negócio. A Orquestração define um fluxo de interações entre os WSs em um processo.

Em uma composição de serviços, independente do conceito usado, alguns aspectos são importantes;

• A ordem das interações entre os serviços;

• As regras que devem orientar a seqüência de interações;

• A relação entre as mensagens trocadas pelos WS participantes; • Os aspectos relevantes ao iniciar e encerrar o processo; e

• As possibilidades para restaurar interações já realizadas.

Os conceitos de Coreagrafia e Orquestração atendem a maioria dos requisitos citados. A seguir são detalhados esses conceitos e duas especificações correspondentes.

1. Coreografia

Coreografia define protocolos para a troca de mensagens entre um conjunto de ser-viços Web, onde cada um dos serser-viços tem igual responsabilidade na troca dessas mensagens. Na coreografia todos os participantes são responsáveis pelo processo, ou seja, não é centralizado. Uma coreografia pode ser descrita através da WSCI (Web Services Choreography Interface) [36] uma especificação atualmente sob a responsa-bilidade da W3C [37]. WSCI define as mensagens entre os serviços e os participantes no processo de colaboração. A especificação suporta correlação de mensagens, re-gras de seqüência, tratamento de exceções, transações, e a dinâmica na colaboração. O aspecto fundamental do WSCI é que este só descreve o procedimento visível entre os serviços Web. WSCI não endereça a definição do processo executável de negócio. Cada documento WSCI descreve um dos participantes na troca de mensagens, e não há um processo único que gerencie a interação. WSCI pode também ser visto como uma camada adicionada no topo da pilha dos serviços Web. WSDL pode ser usada para descrever os pontos de entrada em cada serviço disponível, e WSCI pode des-crever as interações entre essas operações WSDL. WSCI suporta transações e tem tratamento para exceções. [38] é um exemplo de uso de coreografia em serviços Web que usa WISC.

2. Orquestração

Orquestração trata processos executáveis de negócios que podem interagir interna e externamente com um WS. Na orquestração o processo é sempre controlado a par-tir da perspectiva de uma das partes do negócio. O termo orquestração de serviços Web pode ser usado para descrever a criação de processos de negócios, executáveis ou colaborativos, que usem tais serviços. A orquestração deve ser dinâmica e fle-xível. Flexibilidade pode ser obtida através da clara separação entre a lógica do processo e os serviços usados. Essa separação pode estar dentro do motor de or-questração, que manipula o fluxo do processo, chamando os serviços apropriados e determinando os próximos passos a serem completados. Uma linguagem para defi-nição de uma orquestração é a WS-BPEL (Web Service Business Process Execution Language) [39]. WS-BPEL modela o procedimento dos serviços Web na interação do processo de negócio [40]. Define uma gramática baseada em XML para descrever a lógica de controle, requerida para coordenar os serviços participantes no fluxo do processo. Essa gramática é interpretada e executada pelo motor de orquestração, que é controlado por um dos participantes.

Uma composição WS-BPEL é um processo de negócio, ou um workflow, que inte-rage com um conjunto de Serviços Web. A composição é formada por duas partes. Na primeira parte (<definitions>), são feitas as definições das mensagens que serão

trocadas, dos serviços e operações usados (<portTypes>) e os tipos de ligação entre os parceiros (<partnerLinkType>). A segunda parte (<process>), é a estrutura do processo de negócio, onde são definidos os parceiros (<partnerLinks>) e as ativi-dades entre eles. Cada passo do processo é chamado de atividade. Exemplos de atividades são: invoke (invoca uma operação em um WS), assign (copia dados de um local para outro), if, sequence (executa os passos em sequência) e flow (define que um grupo de passos deve ser executado em paralelo). Um WS, pela própria defi-nição, não mantém o estado. WS-BPEL usa um mecanismo chamado de correlação de mensagens para manter o estado de uma interação [34]. Os campos principais nas mensagens de dados são identificados e usados para relacionar as mensagens trocadas entre os parceiros (<message> e <variables>).

3. WS-BPEL x WSCI

Comparando as duas especificações é possível notar que WS-BPEL enfatiza a cria-ção do processo executável de negócio, enquanto que WSCI concentra-se na troca de mensagens entre os serviços. WSCI é mais colaborativo, requerendo cada par-ticipante na troca de mensagens que define a interface WSCI. WS-BPEL é mais introspectivo, descrevendo um processo executável a partir da perspectiva de um dos participantes.

A linguagem é a ferramenta do usuário para descrever a composição dos serviços. Em um ambiente híbrido com grade e nuvem é importante que a linguagem tenha capacidade para descrever de forma abstrata não só o relacionamento entre os serviços mas também os requisitos da aplicação em relação ao ambiente computacional. A abstração é fundamental pois os recursos são escolhidos dinamicamente. Na nuvem os recursos são virtualizados tendo a localização definida no instante da criação da instância e nas grades oportunistas recursos são ofertados conforme a sua disponibilidade.

A linguagem WS-BPEL atende corretamente quando o objetivo são processos de negó-cios e pode ser usada para descrever workflows. No entanto, quando usada para descrever workflows a serem executados em grades, nuvens e ambientes híbridos torna-se complexa exigindo um alto grau de especialização do usuário. Por essa razão nesta tese optou-se por criar uma nova linguagem denominada CEOL descrita em destalhes no Capítulo 4.

2.2 Grades Computacionais

Grades computacionais são ambientes para computação distribuída de alto desempenho que permitem o compartilhamento de recursos heterogêneos. Conceitualmente uma grade consiste no compartilhamento coordenado de recursos por organizações multi-institucionais

e dinâmicas [8, 9]. Esse compartilhamento pode ser de arquivos, acesso direto a compu-tadores, software e dados, por exemplo. Ele requer controle sofisticado, com provedores e consumidores definindo claramente o que é compartilhado, quem pode acessar, enfim, as condições para que o compartilhamento ocorra. O conjunto de indivíduos e/ou institui-ções definido através dessas regras de compartilhamento forma as Organizainstitui-ções Virtuais (VO - Virtual Organizations) [8].

Grades computacionais podem ser aplicadas na exploração de recursos pouco utiliza-dos [41], supercomputação distribuída, computação de alto desempenho [42], computação sob demanda, uso intensivo de dados e colaboração [43, 44]. A grade é uma coleção de máquinas que são referenciadas como nós, recursos, membros, enfim de diversas maneiras [41, 45]. De forma geral os recursos de uma grade podem ser computacionais, armaze-namento, comunicação, software e licenças, reserva, procura, agendamento e gerência. A grade possui protocolos para gerenciar os recursos compartilhados, e que são responsáveis por negociações de segurança, monitoramento, enfim o controle dessas operações com-partilhadas feitas nos recursos individuais, mas em geral não suportam a execução de workflows.

Serviços da Grade

Uma interface de serviço associada a um recurso da grade é conhecida como um Serviço da Grade (SG). Um recurso e seu estado são controlados e gerenciados através do SG no ambiente da grade. Um SG pode acessar mais que um recurso e múltiplos SGs podem acessar o mesmo recurso. Além disso um SG pode criar uma nova instância do recurso, usando para isso o conceito de Fábrica das grades. Vários recursos da grade podem inte-ragir ou integrar outros recursos dependendo dos requisitos da aplicação, lembrando que essa interação está ocorrendo no ambiente heterogêneo da grade. Dessa forma é necessário um framework que possa abstrair os detalhes de implementações específicas do ambiente através, por exemplo, de um sistema de mensagens entre grades. A arquitetura SOA oferece tal framework e pode ser usada como base na integração de recursos heterogêneos em vários níveis da arquitetura das grades.

Apesar dos SGs serem implementados usando a tecnologia dos Serviços Web existem diferenças fundamentais entre eles. O Serviço Web é persistente e isso é usado em sua localização e uso. Já um SG é concebido para recursos virtuais em um ambiente dinâmico. Um SG pode ser transiente ou persistente, podendo ser criado e destruído dinamicamente, muito diferente de um Serviço Web que está acessível conforme a descrição do seu WSDL correspondente. Essas características dos SGs mostradas tem forte impacto na gerência, descoberta e uso dos SGs.

Open Grid Service Architecture (OGSA)

O OGF (Open Grid Forum) [46] usou os princípios SOA como base da OGSA (Open Grid Service Architecture) [27, 47], que provê um framework para implementar uma grade. Na OGSA todos os recursos, sejam físicos ou lógicos, são modelados como Serviços da Grade. Isso permite que os SGs usem o modelo de mensagem dos Serviços Web, seu serviço de descrição e de descoberta. Assim, um SG em OGSA é um Serviço Web potencialmente transiente, baseado nos protocolos da grade e que usa WSDL.

OGSA define uma semântica uniforme para exposição dos Serviços da Grade. Define mecanismos padronizados para criar, nomear e descobrir instâncias de serviços transientes da grade. Provê transparência de localização e tratamento para múltiplos protocolos para essas instâncias. Suporta facilidades integradas às plataformas nativas nos ambientes computacionais. As interfaces dos serviços OGSA são descritas em WSDL, incluindo mecanismos para criação e composição de sistemas sofisticados de distribuição e gerência do ciclo de vida, alterações e notificações dos serviços, além da definição dos protocolos de comunicação. O registro UDDI e documentos WSIL (Web Service Interface Language) [48] são usados para localizar o serviço, e o protocolo de transporte SOAP é usado para conectar dados e aplicações que acessam os serviços da grade.

No contexto da grade um recurso representa um estado ou um dado e provê alguma capacidade útil através de uma interface. Essa interface associada a um recurso define um grupo de operações lógicas que podem ser invocadas pelos clientes. Os conceitos da arquitetura orientada a serviço [5] podem ser aplicados na definição das interfaces dos recursos da grade transformando-as em interfaces padronizadas de Serviços Web. Entretanto os WSs não mantêm o estado, isto é, nenhuma informação entre duas chamadas a um WS é armazenada. Ocorre que a manutenção do estado de um recurso ou serviço nas grades é freqüentemente necessária, sendo esta uma diferença importante entre Serviços Web e Serviços da Grade.

OGSA oferece gerência de estado através da qual os Serviços da Grade podem man-ter seu estado inman-terno. Serviços inman-teragem com outros, através da troca de mensagens, baseada na invocação de serviços. O estado interno de um serviço pode ser garantido, permitindo aplicações orientadas a transações. OGSA possui também mecanismos para capturar as informações de estado associadas a um serviço numa operação que causou falha. Quando uma falha ocorre, a mensagem keepalive é interrompida indicando que o serviço não foi executado. O Serviço de Grade automaticamente encontra outro recurso computacional para substituí-lo.

OGSA possui um mecanismo para troca de mensagens assíncronas (notificações) que avisam os clientes sobre eventos que ocorreram, como por exemplo, mudanças nas propri-edades, eventos associados ao tempo de vida, etc.

WSRF

A especificação WSRF (Web Services Resource Framework) [49] proposta pela OASIS [50], é um conjunto de especificações, que define o relacionamento entre Serviços Web (que não mantêm estado) com recursos que mantêm estado. Com WSRF um Serviço da Grade é transformado em um recurso de acordo com a especificação WS-Resource. WSRF usa a especificação WS-Notification em Serviços da Grade para construir notificações sobre mudança de estado usando Serviços Web.

WS-Resource [49] é uma construção que modela recursos que mantém estado (stateful resource) usando frameworks da arquitetura para Serviços Web. Um recurso modelado através de construções WS-Resource pode ser implementado como um arquivo, um sis-tema de arquivos, registros em um banco de dados ou mesmo em uma estrutura residente em memória. A composição entre um recurso que mantém estado e um Serviço Web é chamada de um WS-Resource, e o componente gerado por essa composição tem outros requisitos. Um Serviço Web expõe sua interface através da construção portType, sendo através dele que o Serviço Web torna disponível suas operações ao cliente. Um Serviço Web torna-se um WS-Resource quando a sua definição portType (no arquivo WSDL cor-respondente) é associada com uma representação XML das propriedades que mantêm o estado, descritas conforme o framework WS-Resource.

Em WSRF o estado é mantido implicitamente via subsistema com o qual o Serviço Web interage, ou seja, a gerência da instância e do estado é delegada a um componente externo. A implementação WSRF passa implicitamente o identificador do recurso quando o cliente interage com um WS-Resource. Para isso WSRF usa um conjunto de convenções tais como XML, WSDL e WS-Addressing.

WS-Addressing [51] padroniza o endereço que representa um Serviço Web, cuja re-presentação é chamada de EPR (Endpoint Reference). EPR é usado em WSRF para representar a informação contextual que disponibiliza a comunicação do cliente com o WS-Resource. Um EPR contém o endereço do Serviço Web e informações das propri-edades do recurso, que incluem um identificador para a instância. A criação de um identificador de recurso é análoga à criação de uma nova instância de um WS-Resource, que por sua vez é análoga à criação de um Serviço da Grade (conforme OGSA).

Na implementação do protótipo para validar a arquitetura da infraestrtura proposta nesta tese foi usado o Globus Toolkit Versão 4 (GT4) [52] como middleware de grade com-putacional. O GT4 é uma implementação OGSA com WSRF desenvolvida pela Globus Alliance.

A dinâmica das grades e das organizações virtuais reforçam a necessidade de aprovisi-onamento sob demanda, onde os requisitos organizacionais devem nortear a configuração do sistema. Cabe ao ambiente prover dinamicamente os serviços relacionados com cada aplicação no momento do uso, não sendo recomendável disponibilizar todos os serviços

em todos os recursos computacionais da grade. Para permitir o aprovisionamento sob demanda é necessário suportar a instanciação dinâmica de serviços, isto é, colocar o ser-viço no recurso computacional, publicá-lo para que possa ser tratado por um container e ativar o container para que este possa atender as requisições ao serviço. A infraestru-tura proposta nesta tese agrega funcionalidades para aprovisionamento de serviços sob demanda durante a execução de workflows uma vez que as grades, e em especial a que está sendo usada no protótipo construído, o GT4, não oferece essa funcionalidade.

2.3 Virtualização

Virtualização [7] é o processo de apresentação de grupos lógicos ou conjuntos de recursos computacionais que podem ser acessados de forma abstrata com benefícios sobre a con-figuração original dos mesmos. A virtualização de software abstrai o hardware através da criação de interfaces para máquinas virtuais (VMs). Tais VMs representam recursos físicos como unidades de processamento (CPUs), memória, conexões de rede e periféricos (discos, impressoras, etc). Cada VM é um ambiente de execução isolado e independente dos demais. Dessa forma, cada VM pode ter seu próprio sistema operacional, suas apli-cações e seus serviços de rede. Esse isolamento oferece aos usuários controle total sobre o recurso. Tais características oferecidas pela virtualização permitem isolamento dos usuá-rios em um ambiente de nuvem computacional, por exemplo. Virtualização constitui a base da computação em nuvem, uma vez que permite recursos computacionais oriundos de grupos de servidores que são disponibilizados dinamicamente sob demanda como recursos virtuais para aplicativos.

2.4 Nuvens Computacionais

A computação em nuvem leva o usuário ao mundo da supercomputação dando-lhe a sen-sação de poder computacional e capacidade de armazenamento ilimitados. Ao usar uma nuvem, o usuário acessa recursos de computação como utilitários que podem ser aluga-dos e liberaaluga-dos conforme a necessidade [4]. Através da virtualização a nuvem oferece recursos computacionais com várias opções de arquitetura de hardware, de memória, de armazenamento e conectividade acessíveis via Internet. A computação em nuvem provê hardware sob demanda permitindo que empresas executem seus sistemas proprietários transformando gastos fixos em despesas conforme o consumo, reduzindo investimentos. Ela oferece como principais benefícios a preservação do investimento inicial, a redução de custos operacionais, a redução de custos de manutenção e escalabilidade fornecido sob demanda. Tais características da nuvem fornecem elasticidade ao ambiente de

compu-tação do usuário tornando os sistemas adaptáveis às suas necessidades. Na compucompu-tação em nuvem detalhes são abstraídos do usuário. Eles não necessitam ter conhecimento, especialização, ou controle sobre a infraestrutura tecnológica. Tipicamente a computação em nuvem envolve a provisão de recursos dinamicamente escaláveis, muitas vezes virtu-alizados, oferecidos como serviços através da Internet [6]. As principais características da computação em nuvem são o autoatendimento com aprovisionamento de recursos sob demanda, acesso ubíquo à rede, localização independente de recursos (reliability), elasti-cidade rápida (scalability), auto-organização onde os provedores gerenciam seus recursos e pagamento pelo uso.

Arquitetura da Nuvem Computacional

O conceito de nuvem computacional está em formação não existindo portanto um padrão que defina a sua arquitetura [53]. Trabalhos como [54, 55, 56, 57, 58, 59] apresentam propostas e comentam possibilidades para uma definição de arquitetura para nuvem com-putacional já existindo iniciativas que discutem padrões abertos [60, 61]. O National Ins-titute of Standards and Technology (NIST) define “uma nuvem computacional como um modelo que permite acesso sob demanda via rede a um conjunto compartilhado de recursos computacionais configuráveis (por exemplo, redes, servidores, armazenamento, aplicações e serviços) que podem ser rapidamente aprovisionados e liberados com um mínimo esforço de gerenciamento ou interação com o provedor de serviços. (Cloud computing is a mo-del for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.”) [6]. Por esta ser a definição mais citada atualmente, será usada como base nesta tese. De maneira geral a arquitetura da nuvem computacional (Figura 2.1) pode ser dividida em quatro camadas: os equipamentos (hardware), a infraestrutura, a plataforma e a camada de aplicação [4].

• A camada de equipamentos: esta camada é responsável pela gestão dos recursos físicos da nuvem. Ela inclui servidores, roteadores, switches, sistemas de refrigeração e de energia, sendo geralmente implementada no centro de dados (data center). Ati-vidades típicas dessa camada incluem configuração dos equipamentos, tratamento de tolerância a falhas, gerência de recursos, tráfego, energia (green computing) e controle do ambiente.

• A camada de infraestrutura: essa camada cria um conjunto de recursos de computação e armazenamento através do particionamento de recursos físicos usando tecnologias de virtualização, como o Xen [62], KVM [63] e VMware [64]. É uma

Figura 2.1: Arquitetura da Nuvem Computacional ([4]).

camada essencial pois agrega facilidades como atribuição dinâmica de recursos, que só podem ser disponibilizadas através de tecnologias de virtualização.

• A camada da plataforma: essa camada é constituída por sistemas operacionais e arcabouços de aplicação. Sua finalidade é minimizar o ônus da implantação de apli-cativos diretamente nas máquinas virutais (virtual machines - VM). Por exemplo, o Google App Engine [65] opera na camada da plataforma fornecendo APIs para suportar a implementação de armazenamento, banco de dados e lógica de negócios. • A camada de aplicação: essa camada consiste nas aplicações reais em nuvem. Diferente de aplicativos tradicionais, aplicações podem aproveitar as facilidades da nuvem (autoatendimento, acesso ubíquo e elasticidade) para alcançar melhor de-sempenho, disponibilidade e menor custo operacional. Pela óptica do provedor de nuvem o CEO é uma aplicação estando dessa forma inserido nesta camada.

Modelo de Negócio

A computação em nuvem utiliza um modelo de negócio orientado a serviço, onde os recursos de hardware e do nível de plataforma são fornecidos sob demanda como serviços. Conceitualmente cada camada da arquitetura é implementada e disponibilizada como um serviço para a camada de cima, que por sua vez pode ser um vista como um cliente da camada inferior. Na prática as facilidades da nuvem estão sendo agrupadas em três categorias: software como serviço (Software as a Service - SaaS), plataforma como serviço (Platform as a Service - PaaS) e infraestrutura como um serviço (Infrastructure as a Service - IaaS) [6, 4, 58].

• Software como serviço (SaaS): esse modelo oferece ao consumidor a utilização de aplicativos do provedor que são executados na infraestrutura da nuvem. As apli-cações são acessíveis através do navegador da Internet a partir de dispositivos leves (thin client). O consumidor não gerencia nem controla a infraestrutura da nuvem, incluindo rede, servidores, sistemas operacionais, armazenamento, ou mesmo capa-cidades de aplicativos individuais. Exemplos de provedores de SaaS (mostrados do lado direito da Figura 2.1), incluem Google Apps [66], Facebook [67], YouTube [68], Salesforce.com [69] e SAP [70].

• Plataforma como serviço (PaaS): esse modelo permite ao consumidor implantar aplicações usando linguagens e ferramentas suportadas pelo provedor. O consumidor não gerencia nem controla a infraestrutura da nuvem, incluindo rede, servidores, sistemas operacionais ou armazenamento, mas tem controle sobre os aplicativos implementados e possivelmente sobre a hospedagem de aplicativos de configurações de ambiente. Exemplos desse modelo (lado direito da Figura 2.1) são o Google App Engine [65], a Microsoft Windows Azure [71] e Amazon S3 [72].

• Infraestrutura como serviço (IaaS): nesse modelo a capacidade fornecida ao consumidor é o processamento, armazenamento, redes e outros recursos de compu-tação onde o consumidor é capaz de implementar e executar software arbitrário, que pode incluir sistemas operacionais e aplicativos. Esse aprovisionamento de recursos em geral é feito através de máquinas virtuais. Exemplos de provedores de IaaS são Amazon Elastic Compute Cloud [2], a Globus Nimbus [73], a OpenStack [74] e a Eucalyptus [75], sendo que alguns desses também fornecem software para a criação de nuvens privadas.

Modelo de Referência Conceitual

O NIST propos um modelo de referência conceitual para computação em nuvem [76]. Esse modelo identifica os principais atores, suas atividades e funções na computação em nuvem. O diagrama da Figura 2.2 mostra uma arquitetura genérica de alto nível e se destina a facilitar a compreensão dos requisitos, usos, características e padrões de computação em nuvem.

Esse modelo de referência conceitual define cinco principais atores: o consumidor (consumer), o provedor (provider), o transportador (carrier), o auditor e o distribuidor (broker). Cada ator é uma entidade (uma pessoa ou uma organização) que participa de uma transação ou processo e/ou executa tarefas em computação em nuvem. As principais características desses atores são:

Figura 2.2: Modelo NIST de Referência Conceitual para Nuvem Computacional ([76]).

comercial com, e usa o serviço dos, provedores de nuvem. Consumidores precisam SLAs para especificar os requisitos de desempenho técnico a serem cumpridos pelo provedor de nuvem. SLAs podem cobrir termos em relação à qualidade do serviço, segurança e soluções para as falhas de desempenho. Um provedor de nuvem tam-bém pode listar nos SLAs um conjunto de premissas não explicitamente feitas aos consumidores, ou seja, limitações e obrigações que o consumidor deve aceitar. Um consumidor pode escolher livremente um provedor de nuvem com melhor preço e condições mais favoráveis. Exemplos de serviços disponibilizados ao consumidor por um provedor SaaS podem ser CRM (customer relationship management), gerência de documentos, e-mail, gerência de conteúdo, finanças, redes sociais. Exemplos de serviços disponibilizados ao consumidor por um provedor PaaS podem ser bases de dados, desenvolvimento de aplicações, inteligência em negócios, testes e desenvolvi-mento. Exemplos de serviços disponibilizados ao consumidor por um provedor IaaS podem ser armazenamento, computação, hospedagem de plataforma, gerência de recursos e armazenamento de cópias de segurança (backup).

• Provedor (provider): uma pessoa, organização ou entidade responsável por fazer e manter um serviço à disposição dos interessados. Um provedor de SaaS implanta, configura, mantém e atualiza o funcionamento dos aplicativos de software em uma infraestrutura de nuvem para que os serviços sejam provisionados nos níveis espera-dos pelos consumidores. Um provedor de PaaS gere a infraestrutura computacional para a plataforma e executa o software que fornece os componentes da plataforma, como a pilha de software, bancos de dados e outros componentes de middleware. O provedor de PaaS também apoia o processo de desenvolvimento, implantação e

ges-tão, fornecendo ferramentas como ambientes integrados de desenvolvimento (IDEs), versão de desenvolvimento do software em nuvem, kits de desenvolvimento de soft-ware (SDKs), implantação e ferramentas de gerenciamento. Para IaaS, o provedor de nuvem adquire os recursos de computação físicos subjacentes ao serviço, incluindo os servidores, redes, armazenamento e infraestrutura de hospedagem. O provedor IaaS atua sobre o software necessário para tornar os recursos disponíveis através de um conjunto de interfaces de serviço e abstrações de recursos de computação, tais como máquinas virtuais e interfaces de rede virtual.

• Auditor (auditor): uma entidade que pode realizar avaliações independentes so-bre os serviços prestados, soso-bre as operações do sistema de informação, soso-bre o desempenho e sobre os aspectos de segurança oferecidos pela nuvem.

• Transportador (carrier): um intermediário que fornece conectividade e trans-porte dos serviços da nuvem vindos do provedor para o consumidor.

• Negociador (broker): uma entidade que gerencia o uso, o desempenho e a entrega dos serviços da nuvem, e negocia as relações entre os provedores e consumidores. A infraestrutura CEO pode ser usada tanto pelos consumidores como oferecida pelos provedores. O consumidor pode incluir o CEO em condições de uso dentro de imagens que serão usadas na criação de máquinas virtuais no modelo IaaS e provedores de SaaS podem oferecer o CEO como opção aos seus consumidores.

Tipos de Nuvens

Há muitas questões a considerar ao executar aplicações no ambiente da nuvem compu-tacional. Por exemplo, alguns prestadores de serviços podem visar redução de custo de operação, enquanto outros podem priorizar a confiabilidade e a segurança. De acordo com o objetivo podem ser configuradas nuvens públicas, privadas, comunitárias, privadas virtualizadas e híbridas, cujas características são descritas a seguir:

Nuvem pública é uma nuvem onde provedores oferecem seus recursos como serviços ao público em geral. Nuvens públicas oferecem benefícios importantes aos consumidores, incluindo nenhum investimento de capital em infraestrutura e a transferência de riscos para os provedores. No entanto, não oferecem controle refinado sobre dados, rede e configurações de segurança, o que dificulta a sua eficácia em muitos cenários de negócios. A Figura 2.3 ilustra o relacionamento entre a nuvem pública e seus consumidores.

Nuvem privada, também conhecida como nuvens internas, são concebidas para uso exclusivo de uma única organização. Uma nuvem privada pode ser construída e gerida pela própria organização (Figura 2.4 [A]) ou por provedores externos (Figura 2.4 [B]).