UNIVERSIDADE SALVADOR - UNIFACS

CURSO DE CINCIA DA COMPUTAO

Lipe Ribeiro Teixeira Silva

Anlise comparativa de solues de Computao em Nuvem: avaliao de maturidade e perspectivas

Salvador 2012.1

Lipe Ribeiro Teixeira Silva

Anlise comparativa de solues de Computao em Nuvem: avaliao de maturidade e perspectivas

Monograa apresentada Coordenao do Curso de Cincia da Computao da Universidade Salvador - UNIFACS, como requisito parcial para a obteno do grau de Bacharel em Cincia da Computao. Orientador: Profo . Christian Guerreiro

Salvador 2012.1

RESUMO

A popularizao da Internet a partir da dcada de 1990 e o crescimento do conceito relativo a virtualizao propiciaram o momento oportuno para o desenvolvimento da Computao em Nuvem. A ideia de ter acesso a informao a qualquer momento e de qualquer lugar e que os recursos sejam fornecidos de acordo com a demanda bastante atraente para empresas de todos os tamanhos e segmentos, assim como para usurios nais. Atualmente no h uma especicao aberta e sob a autoridade de um rgo normatizador, ou seja, no h um formato realmente padronizado. Sendo assim, diversas instituies acadmicas e no-acadmicas tm trabalhado no desenvolvimento de solues de cdigo aberto na nuvem. Este trabalho apresenta as solues de cdigo aberto mais populares para Computao em Nuvem. A atividade de pesquisa tem como foco a anlise das ferramentas OpenNebula, Eucalyptus (Elastic Utility Computing Architecture for Linking Your Programs To Useful Systems), openQRM (open Qlusters Resource Manager) e OpenStack, fazendo um comparativo de suas principais caractersticas. Palavras-chave: Computao em Nuvem, Sistemas Distribudos, Virtualizao, ferramentas de cdigo aberto, OpenNebula, Eucalyptus, openQRM, OpenStack.

ABSTRACT

The popularization of the Internet from the 1990s and the growth of the concept related to virtualization provided the best time to the development of Cloud Computing. The idea of having access to information anytime and anywhere and that resources are provided according to demand is very attractive to companies of all sizes and segments, as well as for end users. Currently there is not an open specication under the authority of a standard-setting body, in other words, there is not actually a standardized format. In this way, various academic and nonacademic have worked on developing open source solutions in the cloud. This paper presents the most popular open source solutions on Cloud Computing. The research activity have the focus on the analysis of the tools OpenNebula, Eucalyptus, OpenQRM and OpenStack, making a comparison of its main features. Keywords: Cloud Computing, Distributed Systems, Virtualization, open source tools, OpenNebula, Eucalyptus, OpenQRM, OpenStack.

LISTA DE FIGURAS

1 2 3 4 5 6 7 8 9

Viso Geral - Nuvem Computacional (RUSCHEL; ZANOTTO; MOTA, 2010) . . . . Sistema Distribudo Tpico (TANENBAUM; STEEN, 2006) . . . . . . . . . . . . . Arquitetura Eucalyptus (EUCALYPTUS, 2012b) . . . . . . . . . . . . . . . . . . Sistema Modular OpenNebula (OPENNEBULA, 2012b) . . . . . . . . . . . . . . Arquitetura OpenNebula (OPENNEBULA, 2012b) . . . . . . . . . . . . . . . . . Processos OpenNebula (OPENNEBULA, 2012b) . . . . . . . . . . . . . . . . . . Arquitetura libvirt (OPENNEBULA, 2012c) . . . . . . . . . . . . . . . . . . . . Arquitetura openQRM (OPENQRM, 2012b) . . . . . . . . . . . . . . . . . . . . Arquitetura OpenStack (OPENSTACK, 2012a) . . . . . . . . . . . . . . . . . . .

15 19 36 45 45 46 48 52 57

LISTA DE TABELAS

1 2 3 4 5 6

Descrio dos estados do servio (EUCALYPTUS, 2012a) . . . . . . . . . . . . . Relao Falha X Disponibilidade do sistema (EUCALYPTUS, 2012a) . . . . . . Evoluo Projeto OpenNebula (OPENNEBULA, 2012a) . . . . . . . . . . . . . . Evoluo Projeto openQRM (SOURCEFORGE, 2012) . . . . . . . . . . . . . . . Evoluo Projeto OpenStack (OPENSTACK, 2012b) . . . . . . . . . . . . . . . Quadro Comparativo das Solues . . . . . . . . . . . . . . . . . . . . . . . .

39 41 44 51 56 65

LISTA DE ABREVIATURAS E SIGLAS

3G AMQP API CaaS CAGR CC CLC CPU DaaS DeaaS DHCP DraaS DRBD EaaS EAI EBS EC2 ERP HA HPC HTTP IaaS IBM ICMP IDC InaaS iSCSI

3rd Generation Mobile Telecommunications, Advanced Message Queue Protocol, Application Programming Interface, Communication as a Service, Compound Annual Growth Rate, Cluster Controller, Cloud Controller, Central Processing Unit, Database as a Service, Development as a Service, Dynamic Host Conguration Protocol, Disaster Recovery as a Service, Distributed Replicated Block Device, Everything as a Service, Enterprise Application Integration, Elastic Block Store, Elastic Compute Cloud, Enterprise Resource Planning, High Availability, High Performance Computing, Hypertext Transfer Protocol, Infrastructure as a Service, International Business Machines, Internet Control Message Protocol, International Data Corporation, Information as a Service, Internet Small Computer System Interface,

p. 14 p. 56 p. 15 p. 26 p. 17 p. 34 p. 34 p. 14 p. 25 p. 26 p. 61 p. 27 p. 48 p. 27 p. 22 p. 35 p. 34 p. 24 p. 40 p. 34 p. 22 p. 13 p. 22 p. 31 p. 17 p. 25 p. 35

ItaaS LAN LDAP LTE LVM LXC MaaS NAS NASA NAT NC NFS NNTP NSF NTT P2V PaaS PDA PHP POP3 PraaS QEMU QoS S3 SaaS SAN SC SeaaS SLA SMTP SNMP SOAP

Integration as a Service, Local Area Network, Lightweight Directory Access Protocol, Long Term Evolution, Logical Volume Manager, Linux Containers, Management as a Service, Network-Attached Storage, National Aeronautics and Space Administration, Network Address Translation, Node Controller, Network File System, Network News Transfer Protocol, National Science Foundation, Nippon Telegraph and Telephone Corporation, Physical-to-Virtual, Platform as a Service, Personal Digital Assistant, Hypertext Preprocessor, Post Ofce Protocol 3, Process as a Service, Quick EMUlator, Quality of Service, Simple Storage Service, Software as a Service, Storage Area Network, Storage Controller, Security as a Service, Service Level Agreement, Simple Mail Transport Protocol, Simple Network Management Protocol, Simple Object Access Protocol,

p. 26 p. 33 p. 54 p. 14 p. 47 p. 57 p. 26 p. 47 p. 55 p. 61 p. 34 p. 35 p. 31 p. 34 p. 62 p. 50 p. 24 p. 16 p. 50 p. 31 p. 26 p. 57 p. 16 p. 34 p. 23 p. 35 p. 34 p. 26 p. 16 p. 31 p. 31 p. 22

SSL StaaS TaaS TCP TI UML V2P V2V VDI VGrADS VLAN VMM XML

Secure Socket Layer, Storage as a Service, Testing as a Service, Transmission Control Protocol, Tecnologia da Informao, User Mode Linux, Virtual-to-Physical, Virtual-to-Virtual, Virtual Desktop Infrastructure, Virtual Grid Application Development Software Project, Virtual Local Area Network, Virtual Machine Manager, Extensible Markup Language,

p. 31 p. 25 p. 26 p. 21 p. 14 p. 57 p. 50 p. 50 p. 21 p. 34 p. 44 p. 30 p. 22

SUMRIO

Introduo 1.1 1.2 1.3 Motivao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Estrutura do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13 13 13 13 14 14 17 18 18 19 20 22 23 23 23 24 24 25 27 27 28

Computao em nuvem 2.1 2.2 2.3 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contexto Histrico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 2.4 Sistemas Distribudos . . . . . . . . . . . . . . . . . . . . . . . . . . . Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Virtualizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TI Verde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Modelos de servio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 2.4.2 2.4.3 2.4.4 Software como Servio (SaaS) . . . . . . . . . . . . . . . . . . . . . . Plataforma como Servio (PaaS) . . . . . . . . . . . . . . . . . . . . . Infraestrutura como Servio (IaaS) . . . . . . . . . . . . . . . . . . . . Outros modelos de servio . . . . . . . . . . . . . . . . . . . . . . . .

2.5

Modelos de implementao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.1 2.5.2 Nuvem pblica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Nuvem privada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.5.3 2.5.4 3 Critrios 3.1 3.2 3.3 3.4 3.5 4

Nuvem comunitria . . . . . . . . . . . . . . . . . . . . . . . . . . . . Nuvem hbrida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28 28 30 30 30 31 31 32 33 33 33 34 34 36 36 38 40 41 42 42 43 43 44 46 46

Sistemas de Virtualizao Suportados . . . . . . . . . . . . . . . . . . . . . . Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alta Disponibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Situao Atual do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Solues 4.1 Eucalyptus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 4.1.2 4.1.3 4.1.4 4.1.5 4.1.6 4.1.7 4.1.8 4.2 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Histria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sistemas de Virtualizao Suportados . . . . . . . . . . . . . . . . . . Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alta Disponibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . Situao Atual do Projeto . . . . . . . . . . . . . . . . . . . . . . . .

OpenNebula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 4.2.2 4.2.3 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Histria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.3.1 4.2.3.2 4.2.3.3 Front End . . . . . . . . . . . . . . . . . . . . . . . . . . . Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Datastore . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2.3.4 4.2.4 4.2.5 4.2.6 4.2.7 4.2.8 4.3

Service Network e VM Networks . . . . . . . . . . . . . . .

47 47 47 47 48 49 49 49 50 51 52 52 52 53 54 55 55 55 55 57 57 60 61 62 63 63

Sistemas de Virtualizao Suportados . . . . . . . . . . . . . . . . . . Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alta Disponibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . Situao Atual do Projeto . . . . . . . . . . . . . . . . . . . . . . . .

openQRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 4.3.2 4.3.3 4.3.4 4.3.5 4.3.6 4.3.7 4.3.8 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Histria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sistemas de Virtualizao Suportados . . . . . . . . . . . . . . . . . . Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alta Disponibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . Situao Atual do Projeto . . . . . . . . . . . . . . . . . . . . . . . .

4.4

OpenStack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 4.4.2 4.4.3 4.4.4 4.4.5 4.4.6 4.4.7 4.4.8 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Histria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sistemas de Virtualizao Suportados . . . . . . . . . . . . . . . . . . Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alta Disponibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . Situao Atual do Projeto . . . . . . . . . . . . . . . . . . . . . . . .

Comparativo das Solues 5.1 Sistemas de Virtualizao Suportados . . . . . . . . . . . . . . . . . . . . . .

5.2 5.3 5.4 5.5 5.6 6

Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alta Disponibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Situao Atual do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Quadro Comparativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63 63 64 64 65 66 66 67

Concluso 6.1 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Referncias

13

INTRODUO

1.1

MOTIVAO

A utilizao da Computao em Nuvem est se tornando cada vez mais frequente. Dessa forma, o gerenciamento da estrutura de nuvens virtuais um campo a ser trabalhado devido falta de padronizao e variedade de solues hoje apresentadas. Este trabalho apresenta um comparativo das principais caractersticas do OpenNebula, Eucalyptus, openQRM e OpenStack.

1.2

OBJETIVOS

Este trabalho objetiva fazer uma anlise comparativa das ferramentas de cdigo aberto OpenNebula, Eucalyptus, openQRM e OpenStack, com foco no modelo de implementao denominado IaaS (Infrastructure as a Service), conforme critrios estabelecidos no captulo 3. A pesquisa teve como base os sites ociais das ferramentas, alm de artigos e livros relacionados com a rea de pesquisa.

1.3

ESTRUTURA DO TRABALHO

Este trabalho encontra-se estruturado da seguinte forma: o captulo 2 descreve a base terica necessria para entender os conceitos de Computao em Nuvem, modelos de servio e de implementao suportados; no captulo 3 so apresentados os critrios que sero analisados em cada um dos frameworks; no captulo 4 so apresentadas as caractersticas bsicas de cada ferramenta, alm da anlise dos critrios adotados para comparao das solues; no captulo 5 feito o comparativo entre todas as solues para cada um dos critrios adotados anteriormente; no captulo 6 apresentada uma concluso sobre o trabalho, alm de uma tabela resumo para melhor visualizao do mesmo e ainda h uma indicao do que poder ser desenvolvido como trabalhos futuros.

14

COMPUTAO EM NUVEM

2.1

INTRODUO

A constante queda no preo de laptops e smartphones, entre outros, alm da facilidade do acesso a Internet atravs das redes 3G (3rd Generation Mobile Telecommunications) e LTE (Long Term Evolution) tem elevado o nmero de usurios conectados de forma constante nos ltimos anos. Com isso, tornou-se necessrio fazer o gerenciamento de toda massa de dados que circula nessas transaes. Diante deste desao, precisava-se desenvolver uma nova viso para discutir possveis solues. Desta necessidade surgiu a Computao em Nuvem (Cloud Computing). O conceito de nuvem surge da disposio fsica dos elementos envolvidos no modelo. Os recursos computacionais (como redes, servidores, armazenamento, aplicaes e servios) cam localizados em data centers de empresas de qualquer parte do mundo, o que nos leva a necessidade de um termo que abstraia a localizao. Dessa forma, adotou-se o termo nuvem. Devido ao fato de permitir escalabilidade e elasticidade, o modelo oferece aos administradores de TI (Tecnologia da Informao) uma maneira de aumentar a capacidade de acordo com a demanda. Com a adoo do modelo, no existe a necessidade de alto investimento na substituio de hardware obsoleto, na compra de licenciamento de softwares ou no treinamento de pessoal, uma vez que todo o processamento se d em servidores localizados nas nuvens, pagando apenas pelos recursos utilizados do provedor (rede, armazenamento, memria, CPU (Central Processing Unit), entre outros). A convergncia de uma gama de importantes tecnologias permite computao na nuvem prover servios de forma transparente para o usurio, dentre outras funcionalidades e particularidades. As caractersticas essenciais so as vantagens que as solues de computao em nuvem oferecem. Em conjunto, algumas dessas caractersticas denem a computao em nuvem e fazem a distino com outros paradigmas. Abaixo veremos as cinco caractersticas essenciais deste tipo de soluo (VERAS, 2012):

15

Figura 1: Viso Geral - Nuvem Computacional (RUSCHEL; ZANOTTO; MOTA, 2010) Elasticidade e Escalonamento: Recursos podem ser adquiridos de forma rpida e elstica, em alguns casos automaticamente, caso haja a necessidade de escalar com o aumento da demanda, e liberados, na retrao dessa demanda. Para os usurios, os recursos disponveis para uso parecem ser ilimitados e podem ser adquiridos em qualquer quantidade e a qualquer momento. A virtualizao auxilia a elasticidade rpida na Computao em Nuvem, criando vrias instncias de recursos requisitados utilizando um nico recurso real [Aboulnaga et al. 2009]. Alm disso, a virtualizao uma maneira de abstrair caractersticas fsicas de uma plataforma computacional dos usurios, exibindo outro hardware virtual e emulando um ou mais ambientes que podem ser independentes ou no. Self-Service Sob Demanda: O consumidor de servios da computao na nuvem espera adquirir recursos computacionais de acordo com sua necessidade e de forma instantnea. Para suportar este tipo de expectativa, as nuvens devem permitir o acesso em auto-atendimento para que os usurios possam solicitar, personalizar, pagar e usar os servios desejados sem interveno humana. O usurio pode adquirir unilateralmente recurso computacional, como tempo de processamento no servidor ou armazenamento na rede, na medida em que necessite e sem precisar de interao humana com os provedores de cada servio. O hardware e o software dentro de uma nuvem podem ser automaticamente recongurados, orquestrados e estas modicaes so apresentadas de forma transparente para os usurios, que possuem pers diferentes e assim podem personalizar os seus ambientes computacionais, por exemplo, instalao de software e congurao de rede para a denio de determinados privilgios. Empresas que atuam na rea de IaaS oferecem uma API (Application Programming Interface) prpria, que pode ser utilizada para a requisio dinmica de recursos atravs de scripts personalizados. A Computao em Nuvem no mais que um modelo de prestao de servios. Neste tipo de computao, tudo o que pode oferecer um sistema de computao fornecido como um servio.

16

Faturamento e Medio por uso: Uma vez que o usurio tem a opo de requisitar e utilizar somente a quantidade de recursos e servios que ele julgar necessrio, os servios devem ser cobrados com base em um uso de baixa durao, como por exemplo, medido em horas de uso. Os consumidores pagam aos provedores de servio de nuvem de acordo com o consumo efetuado (modelo de pagamento pelo uso semelhante a utilidades como energia e gs). Por esta razo, as nuvens devem implementar recursos que garantam um eciente comrcio de servios, tais como tarifao adequada, contabilidade, faturamento, monitoramento e otimizao do uso. Esta medio de uso dos recursos deve ser feita de forma automtica e de acordo com os diferentes tipos de servios oferecidos (armazenamento, processamento, largura de banda e contas dos usurios ativas) e prontamente reportada, permitindo uma maior transparncia comercial. O uso de recursos pode ser monitorado e controlado, possibilitando transparncia para o provedor e o usurio do servio utilizado. Para garantir a QoS (Quality of Service), pode-se utilizar a abordagem baseada em SLA (Service Level Agreement). O SLA fornece informaes sobre os nveis de disponibilidade, funcionalidade, desempenho ou outros atributos do servio como o faturamento e at mesmo penalidades em caso de violao destes nveis. Amplo acesso rede: Os recursos devem estar disponveis atravs da rede e acessados atravs de mecanismos padres que permitam a utilizao dos mesmos por plataformas heterogneas, como smartphones, laptops, PDAs (Personal Digital Assistant), entre outros. A interface de acesso a nuvem no obriga os usurios a mudarem suas condies e ambientes de trabalho, como por exemplo, linguagens de programao e sistema operacional. J os softwares clientes instalados localmente para o acesso nuvem so leves, como um navegador de Internet. Infraestrutura computacional, plataformas de desenvolvimento e aplicaes so acessadas via rede atravs de protocolos padro. Isto possibilita a utilizao dos servios por mquinas clientes que variam de desktops robustos a dispositivos mveis com severas limitaes de recursos. A Computao em Nuvem desenvolve a ideia da Internet com aplicaes remotas. Pooling de Recursos: No atendimento a mltiplos usurios verica-se a grande disparidade entre as necessidades dos mesmos, tornando essencial a capacidade de personalizao dos recursos da nuvem. Desde servios de infraestrutura, a servios de plataforma e servios de software. Os recursos computacionais do provedor so organizados em um pool para servir mltiplos usurios usando um modelo multi-tenant ou multi-inquilino, com diferentes recursos fsicos e virtuais, dinamicamente atribudos e ajustados de acordo com a demanda dos usurios. Estes

17

usurios no precisam ter conhecimento da localizao fsica dos recursos computacionais, podendo somente especicar a localizao em um nvel mais alto de abstrao, tais como o pas, estado ou centro de dados. Exemplos de recursos incluem o armazenamento, processamento, memria, largura de banda de rede e mquinas virtuais.

2.2

CONTEXTO HISTRICO

Na dcada de 1980 Mark Weiser usou pela primeira vez o termo Computao Ubqua para descrever a onipresena da informtica no cotidiano das pessoas. O conceito requer computadores pequenos, baratos e com tecnologias de ligao com ou sem os a computadores de maior dimenso. A partir de ento, com a popularizao da Internet na dcada de 1990 e o rpido crescimento da produo e comercializao de dispositivos computacionais mveis, o panorama tecnolgico observado na atualidade comeou a se formar. Com o aumento da conectividade dos indivduos, surgia, inteiramente on line, uma poderosa plataforma de servios. O conceito adotado por Mark Weiser se concretizou a partir do instante que a tecnologia passou a ser inserida onde nunca havia sido imaginado. No nal da dcada de 1990, j com uma grande quantidade de servios web disponveis e a necessidade de acess-los atravs de dispositivos cada vez mais limitados, formava-se um ambiente propcio para o surgimento da Computao em Nuvem. Alm disso, nesse mesmo momento, crescia o conceito das tecnologias de virtualizao de hardware para lidar com o problema do consumo de recursos computacionais e com o desenvolvimento e utilizao de software. Sendo assim, a Computao em Nuvem uma evoluo tecnolgica natural, no uma nova tecnologia. Pesquisa da IDC (International Data Corporation) mostra que a receita mundial de servios de TI em nuvem pblica ultrapassou US$ 21,5 bilhes em 2010 e chegar a US$ 72,9 bilhes em 2015, representando uma taxa composta de crescimento anual (CAGR (Compound Annual Growth Rate) de 27,6%. Este rpido crescimento mais de quatro vezes o crescimento projetado para o mercado de TI em todo o mundo como um todo (6,7%). Em 2015, um em cada sete dlares gastos em pacotes de software, servidor e ofertas de armazenamento ser atravs do modelo de nuvem pblica. Computao em Nuvem um ingrediente essencial de uma transformao maior da indstria de TI e muitas outras indstrias que usam a TI para se transformar. Outros ingredientes ativados pela Computao em Nuvem incluem a exploso de aplicativos mveis e a disponibilidade crescente de banda larga sem o (WEB, 2012). A grande vantagem na adoo da Computao em Nuvem permitir utilizar os recursos

18

computacionais de forma mais econmica e otimizada, possibilitando uma reduo de custos operacionais (menos hardware, manuteno simplicada, reduo de gastos com energia e resfriamento, alm do aluguel de espao fsico) e administrativo (contratando prossionais) para manter sua prpria infraestrutura, o que representa um fator extremamente relevante considerando-se a reduo de gastos com TI, alm da tendncia atual pela adeso a TI Verde. Com a Computao em Nuvem estas empresas podem alugar a infraestrutura necessria de outras empresas que possuem enormes data centers (como a Amazon) e, com isso, conseguem atingir economias de escala oferecendo tais servios a um baixo custo a qualquer cliente.

2.3
2.3.1

ARQUITETURA
SISTEMAS DISTRIBUDOS

De acordo com o conceito de pooling de recursos e elasticidade e escalonamento, a Computao em Nuvem materializada num ambiente externo, composto por um data center que comporta dados de diversas empresas de vrias localidades, permitindo o aumento e diminuio de recursos de acordo com a necessidade do cliente, ou seja, um ambiente capaz de oferecer recursos virtualmente ilimitados e de forma elstica. O aspecto coletivo do funcionamento destes data centers caracteriza o que denominado um sistema computacional distribudo. Um sistema distribudo aquele que denido como um conjunto de unidades de processamento independentes, que atravs da troca de comunicao e gerenciamento de sincronizao pode processar uma aplicao em diferentes localidades em sistemas com caractersticas prprias diferentes, dando a impresso ao usurio que toda a aplicao gerenciada por um sistema nico. Temos o conceito de sincronizao em um sistema centralizado e no sistema distribudo. No sistema centralizado a sincronizao feita atravs do compartilhamento de reas de memria, j no sistema distribudo ocorre a sincronizao atravs da troca de mensagens. A aplicao no sistema distribudo pode ser dividida em partes diferentes e ser processada em diversos ncleos de processamento. Assim, a computao distribuda consiste em adicionar o poder computacional de diversos computadores interligados por uma rede de computadores. A unio desses diversos computadores com o objetivo de compartilhar a execuo de tarefas, conhecida como sistema distribudo. O objetivo criar a iluso que a aplicao (ou as aplicaes) esto sendo processadas em um nico sistema, permitindo a sensao que tudo isso ocorre sem o compartilhamento de reas de memria, no entanto, a sincronizao feita a partir de trocas de mensagens. Faz parte do

19

objetivo a situao da aplicao ser processada de modo que o ambiente que opera fornea situaes favorveis ao compartilhamento de recursos, sabendo que diferentes recursos estaro disponveis em unidades de processamento diferentes. Em um sistema distribudo tpico, a camada de middleware composta pelo software responsvel pelo provimento de uma interface de comunicao nica e pela coordenao de usurios e aplicaes para a utilizao de mquinas distintas, cada uma com seu prprio sistema operacional.

Figura 2: Sistema Distribudo Tpico (TANENBAUM; STEEN, 2006) Desta forma, o termo nuvem est diretamente relacionado a utilizao de um grande sistema distribudo.

2.3.2

MIDDLEWARE

Middleware o neologismo criado para designar as camadas de software que no constituem diretamente aplicaes, mas que facilitam o uso de ambientes ricos em tecnologia da informao. A camada de middleware concentra servios como acesso a bases de dados, mensagens, chamadas de procedimentos, monitoramento de transaes, requisio de objetos, diretrios, ferramentas para segurana, entre outros. As aplicaes tradicionais implementam vrios destes servios, tratando-os de forma independente. J as aplicaes modernas delegam e centralizam estes servios na camada de middleware. Ou seja, o middleware atua como um elemento que aglutina e d coerncia a um conjunto de aplicaes e ambientes. Apesar de suas limitaes, todas as formas de middleware so teis para facilitar a comunicao entre diferentes aplicaes. A seleo do middleware inuencia na arquitetura da aplicao, porque o middleware centraliza a infraestrutura do software e sua implantao. O

20

middleware introduz uma camada de abstrao na arquitetura do sistema e assim reduz sua complexidade consideravelmente. Por outro lado, cada produto de middleware introduz uma sobrecarga de comunicao no sistema, que pode inuenciar no desempenho, escalabilidade, rendimento e outros fatores de ecincia. Isto deve ser levado em considerao no desenho da arquitetura de integrao, particularmente se os sistemas so crticos e so usados por um grande nmero de usurios concorrentes (TANENBAUM; STEEN, 2006). Os servios de IaaS existentes atualmente funcionam atravs da utilizao de interfaces de web services oferecidas por estes middlewares, atravs das quais os clientes alocam recursos contidos na infraestrutura do provedor.

2.3.3

VIRTUALIZAO

A virtualizao o processo de executar vrios sistemas operacionais em um nico equipamento. Uma mquina virtual um ambiente operacional completo que se comporta como se fosse um computador independente. Com a virtualizao, um servidor pode manter vrios sistemas operacionais em uso. Dentro do cenrio tecnolgico brasileiro, a virtualizao vem ganhando novas nalidades e atraindo aqueles que precisam realizar o milagre da multiplicao, j que se trata de fazer caber mais informao em menor espao fsico. Um conceito importante sobre virtualizao o do host (hospedeiro). O hospedeiro referese a mquina na qual ocorrer a virtualizao, ou seja, o hardware fsico onde o sistema operacional executado. Uma mquina na qual feita a virtualizao pode contar com apenas um sistema operacional hospedeiro sendo executado por vez. No entanto, podem ser executados diversos sistemas operacionais virtualizados (visitantes) simultaneamente. As cinco principais vantagens do uso da virtualizao so (VERAS, 2011): Racionalizao da manuteno: Reduzindo o nmero de servidores fsicos possvel cortar gastos de manuteno do hardware de forma relevante; Melhor uso de recursos: Todo crescimento implica em aumento de gastos, mas quem consegue fazer mais com menos certamente economiza energia eltrica, espao, refrigerao e administrao; Autonomia de aplicativos: Quando cada aplicativo est inserido em seu prprio servidor virtual possvel evitar que upgrades e mudanas gerem impacto em toda rede e venham a comprometer a rotina de trabalho; Ganho de ecincia: A virtualizao permite apresentar produtos, servios e projetos ao

21

mercado com maior agilidade, j que possvel acessar desktops remotamente e com segurana; Conformidade ideal: Vrias tecnologias de sistemas operacionais podem coexistir em uma nica plataforma, ou seja, possvel haver sistemas Windows e Linux no mesmo servidor, o que uma grande vantagem para as empresas que vm renovando sua infraestrutura de TI ao longo dos anos. As diferentes modalidades existentes de virtualizao oferecem benefcios diversos, como uma melhor utilizao do sistema atravs do compartilhamento de recursos fsicos, execuo de aplicaes em ambientes isolados, eliminao de conitos de domnio (como utilizao das mesmas portas TCP (Transmission Control Protocol), utilizao simultnea de vrios sistemas operacionais em uma nica mquina e isolamento de falhas. A seguir, so descritos os cinco principais tipos de virtualizao (VERAS, 2011): Virtualizao de Servidores: Tcnica de execuo de um ou mais servidores virtuais sobre um servidor fsico. Permite maior densidade de utilizao de recursos (hardware, espao e etc), enquanto permite que isolamento e segurana sejam mantidos. Diferente da poca dos mainframes, a virtualizao dos servidores agora acontece em servidores x86; Virtualizao de Desktops: Trata da congurao dos desktops dos usurios nais em uma infraestrutura centralizada virtual. Isso signica que as aplicaes de desktop tambm passam a executar em um data center, sob a forma de mquinas virtuais. Este o conceito de VDI (Virtual Desktop Infrastructure), que permite a montagem dinmica de desktops, oferecendo maior conabilidade e otimizao do uso de espao em disco com a consolidao do armazenamento e exibilidade na escolha do sistema operacional. Existem limitaes para o uso desta tcnica de forma generalizada. Normalmente a sua adoo antecedida por um trabalho de levantamento da situao a ser considerada; Virtualizao do Armazenamento (Storage): A ideia introduzir um componente (appliance) que permite que as diversas unidades heterogneas de armazenamento (discos fsicos) sejam vistas como um conjunto homogneo de recursos de armazenamento. A virtualizao do armazenamento no to popular quanto a virtualizao de servidores; Virtualizao de Aplicaes: Trata do conceito de execuo do programa por completo, em um repositrio central, permitindo a congurao centralizada do aplicativo, o que melhora seu gerenciamento, alm de permitir que a congurao ou recongurao seja feita em um nico lugar; Virtualizao de Redes: Arquitetura que proporciona um ambiente de rede separado para cada grupo ou organizao. Estes ambientes lgicos so criados sobre uma nica infraestrutura

22

compartilhada de rede. Cada rede lgica fornece ao grupo de usurios correspondente com plenos servios de rede, semelhantes aos utilizados por uma rede tradicional no virtualizada. A experincia da perspectiva do usurio nal a de ter acesso a uma rede prpria, com recursos dedicados e polticas de segurana independentes. Assim, a virtualizao da rede envolve a lgica segmentao da rede de transportes, os dispositivos de rede, e todos os servios de rede. Devido s diversas redes lgicas compartilharem uma infraestrutura de rede comum, muitas vezes centralizada e com um conjunto de equipamentos e servidores, os grupos de usurios podem colaborar com maior exibilidade e capacidade de gerenciamento. Esta colaborao permite novos processos de negcio, que no seriam possveis (e nem sequer imaginveis) atravs de uma rede tradicional. A virtualizao a pea chave para a construo de um ambiente com tais funcionalidades de multi-arrendamento. O carter elstico da nuvem com a proviso de recursos virtualmente ilimitados, obtido atravs da criao de novas instncias de mquinas virtuais quando se faz necessrio, oferecendo ao cliente upgrades de recursos instantneos e automatizados.

2.3.4

WEB SERVICES

Web Service uma soluo utilizada na integrao de sistemas e na comunicao entre aplicaes diferentes. Com esta tecnologia possvel que novas aplicaes possam interagir com aquelas que j existem e que sistemas desenvolvidos em plataformas diferentes sejam compatveis. Os Web Services so componentes que permitem s aplicaes enviar e receber dados em formato XML (Extensible Markup Language). O acesso sempre ser via HTTP (Hypertext Transfer Protocol), mas internamente existe uma string XML que est empacotada em um protocolo SOAP (Simple Object Access Protocol). De acordo com a (MICROSOFT, 2006), SOAP um padro aberto criado pela Microsoft, Ariba e IBM (International Business Machines) para padronizar a transferncia de dados em diversas aplicaes, por isso, se d em XML. Essencialmente, o Web Service faz com que os recursos da aplicao do software estejam disponveis sobre a rede de uma forma normalizada. Existe uma grande motivao sobre a tecnologia Web Service, pois possibilita que diferentes aplicaes comuniquem entre si e utilizem recursos diferentes. O objetivo dos Web Services a comunicao de aplicaes atravs da Internet. Esta comunicao realizada com intuito de facilitar a EAI (Enterprise Application Integration), que

23

signica a integrao das aplicaes de uma empresa, ou seja, interoperabilidade entre a informao que circula numa organizao nas diferentes aplicaes como, por exemplo, o comrcio eletrnico com os seus clientes e seus fornecedores. A Computao em Nuvem torna possvel a utilizao de infraestrutura de hardware e software remotamente, oferecendo-os como servios aos usurios nais. Isto possvel devido utilizao de interfaces de Web Services, atravs das quais requisies so traduzidas para o processamento por parte dos servidores de gerenciamento dos provedores, que administram o provimento de recursos de acordo com suas polticas internas de segurana e SLA estabelecidos com seus clientes.

2.3.5

TI VERDE

TI Verde ou Green IT, ou ainda, Tecnologia da Informao Verde uma tendncia mundial voltada para o impacto dos recursos tecnolgicos no meio ambiente. A preocupao dessa tendncia est desde a utilizao mais eciente de energia, recursos e insumos na produo de tecnologia, assim como no uso de matria prima e substncias menos txicas na fabricao (SLB, 2009). Alm disso, abrange recursos tecnolgicos que consumam menos energia, que no agridam o meio ambiente na sua utilizao e por m no proporcione ou minimize impactos no seu descarte, permitindo reciclagem e reutilizao. Sendo assim, a Computao em Nuvem e a virtualizao em it data centers so classicadas como tecnologias verdes, pois contribuem para a reduo do consumo de energia e das emisses de dixido de carbono.

2.4
2.4.1

MODELOS DE SERVIO
SOFTWARE COMO SERVIO (SAAS)

A abordagem do SaaS (Software as a Service) tem o potencial de transformar a forma com que os departamentos de tecnologia da informao relacionam-se e, at mesmo, o que pensam sobre o seu papel como provedores de servios para o restante da empresa. O surgimento do SaaS como um mecanismo de entrega de software cria uma oportunidade para que os departamentos de TI alterem o seu enfoque: de implantar e dar suporte aos aplicativos a gerenciar os servios que esses aplicativos oferecem. Por sua vez, um departamento de TI centralizado

24

em servio, bem-sucedido, produz mais valor para o negcio, diretamente, ao fornecer servios desenhados a partir de fontes internas e externas, e se alinhados com os objetivos corporativos (IBM, 2011c). Nesse modelo, as empresas deixam de comprar licenas e passam a ser assinantes dos softwares, que so acessados pela Internet. Nas pequenas e mdias empresas, por exemplo, o novo modelo vai permitir acesso a softwares que antes eram quase proibitivos, devido ao custo inicial (licena e hardware) e de manuteno (verses e suporte), como no caso dos atuais softwares de gesto empresarial (ERP) (Enterprise Resource Planning).

2.4.2

PLATAFORMA COMO SERVIO (PAAS)

PaaS (Platform as a Service) frequentemente a classicao mais confusa da computao em nuvem, pois pode ser difcil de identicar, frequentemente sendo confundida com IaaS ou com SaaS. O fator de denio que torna PaaS exclusiva que permite que desenvolvedores desenvolvam e implementem aplicativos da Web em uma infraestrutura hospedada, ou seja, PaaS permite aproveitar os recursos de computao aparentemente innitos de uma infraestrutura de nuvem (IBM, 2011b). Outra grande vantagem da PaaS a produtividade. O simples fato de no haver necessidade de car projetando balanceamento de carga, replicao, cluster, instalando e congurando middlewares (servidores de aplicao, banco de dados, etc.) j um grande ganho. Alm disso, os grandes fornecedores esto criando uma camada de componentes prontos para uso, APIs e aceleradores de desenvolvimento nessas plataformas, para cada vez mais acelerar o desenvolvimento, como o caso do Google App Engine e do Force.com (Salesforce).

2.4.3

INFRAESTRUTURA COMO SERVIO (IAAS)

IaaS refere-se ao fornecimento de infraestrutura computacional (geralmente em ambientes virtualizados) como um servio. Ao invs de se comprar novos servidores e equipamentos de rede, quando necessrio a ampliao de servios so aproveitados os recursos ociosos disponveis e provisionado novos servidores virtuais infraestrutura existente de maneira dinmica. Os meios no precisam ser comprados se podemos comprar somente os servios de informaes de que a organizao necessita. No estamos falando de terceirizao ou de locao de infraestrutura, estamos falando na aquisio de servios de informao, ou seja, da aquisio do produto nal gerado por toda a infraestrutura de TI e no dos meios para ger-lo (IBM, 2011a).

25

Em conformidade com as cinco caractersticas principais da Computao em Nuvem, o modelo de IaaS fornece infraestrutura de forma dinmica, automatizada e inerentemente escalvel. Com isto, o cliente do servio pode aumentar ou diminuir a quantidade de recursos alocados para si de acordo com sua necessidade. Ao abrir mo de uma infraestrutura prpria atravs da adeso ao IaaS, uma organizao v muitos de seus dados ultrapassarem seus domnios, sendo armazenados na nuvem, um ambiente sobre o poder administrativo de terceiros. Dessa forma muitas questes relacionadas segurana da informao so levantadas, sendo este um dos principais pontos de discusso do campo da Computao em Nuvem.

2.4.4

OUTROS MODELOS DE SERVIO

A variedade de servios disponveis em uma nuvem faz com que sua classicao seja extendida a todo tempo. Outras nomenclaturas so encontradas com relativa facilidade no mercado. Todavia, a estrutura da Computao em Nuvem visivelmente formada pelas trs camadas fundamentais expostas nos subitens anteriores. Atualmente, este tipo de classicao amplamente aceito na literatura, pois engloba grande parte dos subtipos encontrados e dene suas funcionalidades de forma coerente e concisa. medida que a computao em nuvem ganha fora, muito se discute sobre como deni-la em termos de modelo de computao. Alternativas de maturidade foram publicadas e debatidas, e os fornecedores tm um modelo para seus prprios produtos. Abaixo foram listadas outras categorias de tecnologia de Computao em Nuvem alm das principais j apresentadas (COMPUTERWORLD, 2010): Armazenamento como Servio (StaaS) (Storage as a Service): Como o nome indica, a capacidade de utilizar o storage que existe sicamente em um site remoto, mas , um recurso para qualquer aplicativo que requer armazenamento. o componente mais primitivo da computao em nuvem, explorado pela maioria dos outros; Banco de Dados como Servio (DaaS) (Database as a Service): Capacidade de utilizar os servios de um banco de dados hospedado remotamente, compartilhando-o com outros usurios. Funcionaria logicamente como se o banco de dados fosse local. Diversos fornecedores oferecem diferentes modelos, mas sua fora est em explorar a tecnologia de banco de dados que normalmente custaria milhares de dlares em hardware e licenas de software; Informao como Servio (InaaS) (Information as a Service): Capacidade de consumir

26

qualquer tipo de informao, hospedada remotamente, por meio de uma interface bem denida, como uma API; Processo como Servio (PraaS) (Process as a Service): Recurso remoto que pode reunir muitos outros, tais como servios e dados, sejam eles hospedados no mesmo recurso de Computao em Nuvem ou remotamente, para criar processos de negcio. possvel pensar em um processo de negcio como um aplicativo que abrange sistemas, explorando servios e informaes essenciais que so combinados em sequncia para formar processos. Em geral, eles so mais fceis de mudar do que os aplicativos, proporcionando agilidade a quem utiliza estes mecanismos de processos fornecidos sob demanda; Integrao como Servio (ItaaS) (Integration as a Service): Capacidade de fornecer uma pilha de integrao completa a partir da nuvem, incluindo interface com aplicativos, mediao semntica, controle de uxos, design de integrao e assim por diante. Em essncia, a integrao como servio abrange a maioria dos recursos e das funes encontradas na tecnologia convencional de EAI, mas fornecidos como um servio; Segurana como Servio (SeaaS) (Security as a Service): Capacidade de fornecer servios de segurana essenciais remotamente, via Internet. A maior parte dos servios de segurana disponveis rudimentar, porm alguns mais sosticados, tais como gerenciamento de identidade, comeam a ser oferecidos; Gesto como Servio (MaaS) (Management as a Service): Qualquer servio sob demanda que permita gerenciar um ou mais servios de Computao em Nuvem, como gerenciamento de tempo de atividade, topologia, utilizao de recursos e virtualizao. Tambm comeam a surgir sistemas de governana, como capacidade de aplicar polticas denidas para dados e servios; Teste como Servio (TaaS) (Testing as a Service): Capacidade de testar sistemas locais ou fornecidos em nuvem empregando software e servios de teste hospedados remotamente. importante observar que, embora um servio de nuvem exija teste em si mesmo, os sistemas de teste como servio podem vericar outros aplicativos em nuvem, web sites e sistemas empresariais internos, e no requerem espao para hardware ou software na corporao; Desenvolvimento como Servio (DeaaS) (Development as a Service): As ferramentas de desenvolvimento tomam forma na Computao em Nuvem como ferramentas compartilhadas, ferramentas de desenvolvimento web-based e servios baseados em mashup; Comunicao como Servio (CaaS) (Communication as a Service): Uso de uma soluo de comunicao unicada hospedada em data center do provedor ou fabricante;

27

Tudo como Servio (EaaS) (Everything as a Service): Quando se utiliza tudo, infraestrurura, plataformas, software, suporte, enm, o que envolve TIC como um Servio; Recuperao de Desastres como Servio (DraaS) (Disaster Recovery as a Service): Recurso aplicado em uma nuvem privada ou usado em conjunto com um servio de nuvem pblica para proteger dados e aplicativos em execuo nestas nuvens. Nestes locais o acompanhamento dos nveis de temperatura e umidade muito importante.

2.5

MODELOS DE IMPLEMENTAO

No modelo de implementao, dependemos das necessidades das aplicaes que sero implementadas. A restrio ou abertura de acesso depende do processo de negcios, do tipo de informao e do nvel de viso desejado. Percebemos que certas organizaes no desejam que todos os usurios possam acessar e utilizar determinados recursos no seu ambiente de computao em nuvem. Surge assim, a necessidade de ambientes mais restritos, onde somente alguns usurios devidamente autorizados possam utilizar os servios providos. Os modelos de implementao da Computao em Nuvem podem ser divididos em: Privado, Pblico, Comunidade e Hbrido (UFRJ, 2009).

2.5.1

NUVEM PBLICA

As nuvens pblicas so aquelas que so executadas por terceiros. As aplicaes de diversos usurios cam misturadas nos sistemas de armazenamento, o que pode parecer ineciente a princpio. Porm, se a implementao de uma nuvem pblica considera questes fundamentais, como desempenho e segurana, a existncia de outras aplicaes sendo executadas na mesma nuvem permanece transparente tanto para os prestadores de servios como para os usurios. Um dos benefcios das nuvens pblicas que elas podem ser muito maiores do que uma nuvem privada, por exemplo, j que elas permitem uma maior escalabilidade dos recursos. Essa caracterstica evita a compra de equipamentos adicionais para resolver alguma necessidade temporria, deslocando os riscos de infraestrutura para os prestadores de infraestrutura da nuvem. H ainda a possibilidade de destinar algumas pores da nuvem pblica para o uso exclusivo de um nico usurio, criando o chamado data center privado virtual, que prov a esse usurio uma maior visibilidade de toda a infraestrutura. Para este modelo de implantao as restries de acessos no podem ser aplicadas, quanto ao gerenciamento de redes, a aplicao de tcnicas de autenticao e autorizao tambm no

28

ser possvel. Na nuvem pblica, a infraestrutura disponibilizada para o pblico em geral, sendo acessado por qualquer usurio que conhea a localizao do servio.

2.5.2

NUVEM PRIVADA

As nuvens privadas so aquelas construdas exclusivamente para um nico usurio (uma empresa, por exemplo). Diferentemente de um data center privado virtual, a infraestrutura utilizada pertence ao usurio, e, portanto, ele possui total controle sobre como as aplicaes so implementadas na nuvem. Uma nuvem privada , em geral, construda sobre um data center privado. Caso o usurio queira aumentar os recursos utilizados em sua nuvem privada, ele deve adquirir novos equipamentos, como sistemas de armazenamento, por exemplo, j que a sua nuvem est limitada capacidade de seu sistema fsico. Em uma nuvem pblica, como j foi falado anteriormente, no h essa necessidade, uma vez que, como os recursos so facilmente escalveis, basta o usurio reservar uma quantidade maior deles. Devido a essas diferenas, diz-se que as nuvens pblicas so mais adequadas para aplicaes temporrias, enquanto que as nuvens privadas so um ambiente mais apropriado a aplicaes permanentes que demandam nveis especcos de qualidade de servio e de localizao dos dados. Para esse modelo de implantao so empregados polticas de acesso aos servios. Gerenciamento de redes, conguraes dos provedores de servios e a utilizao de tecnologias de autenticao e autorizao so as principais caractersticas deste modelo, que mais caro, porm garante uma maior segurana.

2.5.3

NUVEM COMUNITRIA

O modelo comunidade caracterizado pelo fato da infraestrutura de nuvem ser compartilhada por vrias organizaes e suporta uma comunidade especca que partilha as mesmas preocupaes como misso, requisitos de segurana, poltica e consideraes de conformidade. Pode ser gerenciado pelas organizaes ou por terceiros e podem existir localmente ou remotamente.

2.5.4

NUVEM HBRIDA

A infraestrutura de nuvem hbrida uma composio de duas ou mais nuvens (privado, comunidade ou pblico) que permanecem entidades nicas, mas so unidos por proprietrias

29

de tecnologia padronizada que permite a portabilidade dos dados e aplicaes. As nuvens hbridas combinam os modelos das nuvens pblicas e privadas. Elas permitem que uma nuvem privada possa ter seus recursos ampliados a partir de uma reserva de recursos em uma nuvem pblica. Essa caracterstica possui a vantagem de manter os nveis de servio mesmo que haja utuaes rpidas na necessidade dos recursos. A conexo entre as nuvens pblica e privada pode ser usada at mesmo em tarefas peridicas que so mais facilmente implementadas nas nuvens pblicas, por exemplo. O termo computao em ondas , em geral, utilizado quando se refere s nuvens hbridas. vlido destacar que as nuvens hbridas introduzem a complexidade de determinar a maneira como as aplicaes so distribudas entre nuvens pblicas e privadas. A relao entre os dados e os recursos de processamento, por exemplo, deve ser considerada. Se uma aplicao possui uma grande quantidade de dados, o seu processamento em uma nuvem pblica pode no ser favorvel, j que passar esses dados de sua nuvem privada para uma nuvem pblica pode ser muito custoso.

30

CRITRIOS

Este captulo descreve detalhadamente os critrios adotados para a comparao entre as solues apresentadas neste trabalho. Os itens so apresentados individualmente para melhor entendimento.

3.1

SISTEMAS DE VIRTUALIZAO SUPORTADOS

Nuvens computacionais so compostas, em sua maioria, por conjuntos de mquinas virtuais. Sendo assim, os frameworks para Computao em Nuvem que operam a nvel de IaaS devem possuir a capacidade de gerenciar essas mquinas. Atualmente, encontramos vrios sistemas que implementam a virtualizao. Nesse contexto, um bom framework de IaaS deve prover suporte ecaz ao maior conjunto de sistemas que implementam a virtualizao, aumentando assim seu escopo de trabalho. Um exemplo de sistema de virtualizao o Hypervisor (ou VMM (Virtual Machine Manager)), dispositivo de software entre o hardware e o sistema operacional que responsvel por fornecer a abstrao da mquina virtual. Alm disso, o VMM permite o funcionamento e gerncia de diversos sistemas operacionais alocados sobre uma mesma estrutura fsica (CPU, memria , etc). O vSphere, da VMware, um exemplo de hypervisor utilizado atualmente. Esse tpico trata da enumerao dos sistemas de virtualizao suportados por cada uma das solues apresentadas.

3.2

BACKUP

Nesta seo ser tratada como cada uma das solues lida com uma das principais questes da rea de TI, o backup. O backup muito valorizado por quem j perdeu informaes importantes e no teve possibilidade de as recuperar. Portanto, um procedimento altamente recomendvel devido a frequncia com que se perde informao digital, seja por aes despropositadas do usurio ou mau funcionamento dos sistemas.

31

3.3

MONITORAMENTO

Esta seo ir analisar como feito o monitoramento de servios e de desempenho para mquinas virtuais e os hosts que as hospedam numa viso global orientada ao servio e sua disponibilidade. Entre os pontos a serem analisados podemos destacar: Envio de alertas (email, SMS ou qualquer outro meio denido pelo usurio) quando algum problema ocorrer e tambm quando houver soluo para o mesmo; Monitoramento de hosts e mquinas virtuais; Monitoramento de servios de rede (SMTP (Simple Mail Transport Protocol), POP3 (Post Ofce Protocol 3), HTTP, NNTP (Network News Transfer Protocol), ICMP (Internet Control Message Protocol), SNMP (Simple Network Management Protocol)); Recursos ou equipamentos de rede (largura de banda, uso de CPU e disco); Monitoramento remoto utilizando SSH ou SSL (Secure Socket Layer); Permitir distino dos equipamentos que esto indisponveis dos que esto inalcanveis; Checagem em paralelo, ou seja, fazer diferentes monitoramentos ao mesmo tempo; Interface web; Visualizao do atual status da rede, noticaes, histrico de problemas e logs.

3.4

ALTA DISPONIBILIDADE

Esta seo ir abordar como as solues apresentadas trabalham para garantir que seus servios estejam on line o maior tempo possvel. Este quesito envolve a organizao e implementao de clusters de hosts e mquinas virtuais visando aumentar a disponibilidade do ambiente ou mesmo possibilitar a tolerncia a falhas.

32

3.5

SITUAO ATUAL DO PROJETO

Esse quesito aborda a respeito do estado atual dos projetos. Questes como nmero de usurios e os segmentos que cada um dos frameworks se desenvolveu e o nvel de maturidade de cada ferramenta em seus projetos sero tratados.

33

SOLUES

4.1
4.1.1

EUCALYPTUS
INTRODUO

O Eucalyptus um framework para sistemas de computao em nuvem que opera a nvel de IaaS. Esse sistema possibilita a usurios e administradores de sistemas de Computao em Nuvem a manipulao de mquinas virtuais atravs de funcionalidades como criao, controle e nalizao de mquinas virtuais. O Eucalyptus foi desenvolvido com o intuito de ampliar os estudos acadmicos em sistemas de Computao em Nuvem, visto que, um dos primeiros sistemas dessa modalidade que possui cdigo aberto e estrutura adaptada a um escopo de recursos que usa infraestrutura fsica (processamento, armazenamento, rede, dentre outras) normalmente encontrada e disponvel em grupos acadmicos de pesquisa. De acordo com (EUCALYPTUS, 2012a), o Eucalyptus possui uma arquitetura de software baseada em Linux que implementa nuvens privadas e hbridas de forma escalvel com aumento da ecincia na infraestrutura existente de TI de uma empresa. Como o Eucalyptus fornece IaaS, pode-se congurar os recursos (hardware, armazenamento e rede) conforme necessrio. A nuvem do Eucalyptus implantada no data center das empresas. Como resultado, a organizao tem um controle total da sua infraestrutura de nuvem. possvel implementar e impor vrios nveis de segurana. Dados condenciais gerenciados pela nuvem no precisam deixar os limites da empresa, mantendo os dados completamente protegidos contra acesso externo pelo rewall local. Eucalyptus foi projetado desde o incio para ser fcil de instalar e no intrusivo. Seu framework modular independente da linguagem de comunicao. Eucalyptus tambm o nico que oferece uma cobertura de rede virtual que isola o trfego de rede de usurios diferentes, bem como permite que dois ou mais clusters pertenam a mesma LAN (Local Area Network).

34

4.1.2

HISTRIA

De acordo com (EUCALYPTUS, 2012c) o Projeto Eucalyptus comeou na Computer Science Department at the University of California, Santa Barbara com o pesquisador Rich Wolski e seu time, com o propsito de investigar a rea de HPC (High Performance Computing), mais especicamente a partir do projeto VGrADS (Virtual Grid Application Development Software Project) nanciado pela NSF (National Science Foundation). Para concluir os testes nais do VGrADS em supercomputadores, foi escolhida a nuvem pblica da Amazon. No entanto, VGrADS sempre foi um projeto conjunto entre Universidade e Laboratrios de Pesquisa com dados privados e era necessria uma investigao local mais detalhada sobre os comportamentos de diferentes aplicaes. A partir de ento, no incio de fevereiro de 2008, iniciou-se o desenvolvimento da plataforma opensource Eucalyptus. A primeira verso foi lanada em 29 de maio de 2008 com suporte apenas a EC2 (Elastic Compute Cloud) e em dezembro de 2008 foi includa a interface com o servio S3 (Simple Storage Service). Em 2009, a equipe Eucalyptus criou a companhia Eucalyptus Systems Inc. para comercializar o Eucalyptus Enterprise.

4.1.3

ARQUITETURA

Eucalyptus composto por seis componentes: CLC (Cloud Controller), Walrus, CC (Cluster Controller), SC (Storage Controller), NC (Node Controller), and VMware Broker, este opcional. Cada componente um servio da web independente. Essa arquitetura permite que Eucalyptus exponha cada servio da web como uma API bem denida, independente de idioma e para oferecer suporte a padres de servio Web existentes para comunicao segura entre seus componentes (EUCALYPTUS, 2012a). O CLC o ponto de entrada na nuvem para administradores, desenvolvedores, gerentes de projeto e usurios nais. O CLC consulta o controlador de n para obter informaes sobre recursos, toma decises de programao de alto nvel e faz solicitaes para os controladores de cluster. Como interface para a plataforma de gerenciamento, o CLC responsvel por expor e gerenciar os recursos virtualizados subjacentes (servidores, rede e armazenamento). O CLC pode ser acessado atravs do EC2 e um painel de controle baseado na web. Walrus permite aos usurios armazenar dados persistentes, organizados como buckets e objetos. Voc pode usar o Walrus para criar, excluir e listar os buckets, ou para colocar, receber e excluir objetos ou para denir polticas de controle de acesso. Walrus tem interface compatvel com o S3. Ele fornece um mecanismo para armazenar e acessar imagens de mquinas virtuais e

35

dados do usurio. Walrus pode ser acessada por usurios nais, se o usurio estiver executando um cliente de fora da nuvem ou de uma instncia de mquina virtual em execuo dentro da nuvem. O CC geralmente executado em uma mquina que tem conectividade de rede para ambas as mquinas que executam o NC e para a mquina executando o CLC. CCs reunem informaes sobre um conjunto de mquinas e programa a execuo da VM em ns especcos. O CC tambm gerencia as redes da mquina virtual. Todos os ns associados com um nico CC devem estar na mesma sub-rede. O SC fornece funcionalidade semelhante para o EBS (Elastic Block Store) da Amazon. O SC capaz de fazer a interface com vrios sistemas de armazenamento (NFS (Network File System), dispositivos de SAN (Storage Area Network), iSCSI (Internet Small Computer System Interface), etc.). EBS exporta volumes de armazenamento que podem ser anexados por uma VM e montados ou acessados como um dispositivo de bloco cru. Os volumes do EBS so comumente usados para armazenar dados persistentes. Um volume de EBS no pode ser compartilhado entre VMs e s pode ser acessado da mesma zona de disponibilidade em que a mquina virtual est executando. Os usurios podem criar snapshots dos volumes do EBS que de forma instantnea so armazenados na Walrus e disponibilizados em zonas da disponibilidade. O suporte a SAN do Eucalyptus permite que voc use os dispositivos da SAN de nvel empresarial para hospedar armazenamento EBS dentro de uma nuvem do Eucalyptus. O NC executado em qualquer mquina que hospeda instncias de VMs. O NC controla as atividades da VM, incluindo a execuo, inspeo e terminao de instncias. Ele tambm obtm e mantm um cache local de imagens de instncia e consulta e controla o software de sistema (sistema operacional do host e o hypervisor) em resposta a consultas e solicitaes de controle de CC. O NC tambm responsvel pela gesto de ponto de extremidade da rede virtual. VMware Broker (Broker) um componente opcional do Eucalyptus ativado apenas em verses do Eucalyptus com suporte da VMware. O agente permite que o Eucalyptus implante mquinas virtuais sobre elementos da infraestrutura do VMware. por intermdio do Broker que todas as interaes entre o CC e os hypervisors da VMware (ESX/ESXi) ocorrem, diretamente ou por meio do VMware vCenter. A Figura 3 representa a arquitetura do Eucalyptus implementada com alta disponibilidade do IaaS. Esse tpico ser tratado na seo 4.1.7.

36

Figura 3: Arquitetura Eucalyptus (EUCALYPTUS, 2012b)

4.1.4

SISTEMAS DE VIRTUALIZAO SUPORTADOS

Atualmente o Eucalyptus possui suporte para os seguintes Hypervisors: Xen, KVM e VMware.

4.1.5

BACKUP

Para fazer backup e restaurar o Eucalyptus deve-se completar as seguintes tarefas: 1. Shut Down no Eucalyptus 2. Backup no Eucalyptus 3. Restaurao do Eucalyptus atravs de um Backup Shut Down Devido a uma falha fsica, mudana de topologia, backup ou upgrade pode ser necessrio realizar um shut down no Eucalyptus. recomendvel que os componentes do Eucalyptus

37

sejam desligados na ordem reversa da qual foram iniciados. Para parar o sistema, deve-se desligar os componentes na ordem listada abaixo. Antes de desligar o Eucalyptus recomendvel que todos os usurios sejam noticados que todas as instncias sero encerradas: 1. Shut Down All Instances 2. Shut Down the NCs 3. Shut Down the CC 4. Shut Down the Broker 5. Shut Down the SCs 6. Shut Down Walrus 7. Shut Down the CLC Backup O backup do Eucalyptus envolve salvar o contedo de diretrios especcos de cada componente. No host do CLC, estes diretrios so: O arquivo de congurao Os arquivos de bancos de dados As chaves de criptograa Para o host do Walrus (que, a depender da congurao, pode ser o mesmo host do CLC): Os buckets do Walrus. O recomendado fazer o backup desta pasta apenas se tiver bastante espao disponvel no disco de reposio. Se o local dos buckets do Walrus um local de armazenamento externo (como NFS), recomendvel o backup local. Para o host do Storage Controller (pode ser o mesmo host do CLC): Os volumes do SC. O recomendado fazer o backup desta pasta caso no esteja usando o suporte da SAN. Caso esteja usando um dispositivo SAN com suporte, faa o backup de volumes armazenado na SAN.

38

Para fazer backup do Eucalyptus: 1. Calcular o espao em disco necessrio para armazenar os arquivos que estaro no backup (isto mais relevante para buckets e volumes, que podem ser grandes). Por exemplo, em uma instalao de um cluster com caminhos de buckets e volumes padro. 2. Crie um diretrio para armazenar o backup em um local com espao em disco suciente. Restaurao do Eucalyptus atravs de um Backup No caso do sistema sofrer uma falha, pode-se restaurar o Eucalyptus atravs de um backup, executando as seguintes tarefas: 1. Desligar quaisquer componentes de Eucalyptus em execuo. 2. Caso seja uma recuperao de uma atualizao que falhou, e esteja tentanto reverter ou a atualizar novamente, este seria o momento certo para: Remover todos os componentes de software relacionados ao Eucalyptus. Instalar a verso apropriada. Substituir o estado salvo. Como possui interao total com o AWS, o Eucalyptus fornece backup atravs do S3 da Amazon. O S3 permite o armazenamento e recuperao de qualquer quantidade de dados a qualquer momento, de qualquer local da Web. O Amazon S3 proporciona o acesso a uma infraestrutura de armazenamento de dados altamente dimensionvel, convel, rpida e econmica. Esta infraestrutura de armazenamento permite o benefcio do conhecimento e das economias da dimenso que a Amazon criou ao suportar a sua prpria infraestrutura de misso crtica.

4.1.6

MONITORAMENTO

O Eucalyptus depende de um adequado apoio operacional, alm de manuteno. Nesse sentido, o Eucalyptus fornece acesso viso atual do estado do servio e a capacidade de manipular este estado. Pode-se inspecionar o estado do servio, garantir a sade do sistema e ainda identicar os servios defeituosos. Voc pode modicar um estado de servio para manter as atividades e aplicar polticas externas de servios de colocao.

39 Estado ENABLED Operacional Sim Em uso pelo sistema Sim Descrio O servio est funcionando corretamente e est selecionado para o processamento de pedidos O servio est funcionando corretamente, mas no selecionado para o processamento de pedidos O servio no est funcionando corretamente O servio no consegue contactar o sistema O servio foi parado por um administrador

DISABLED

Sim

No

NOTREADY BROKEN STOPPED

No No N/A

No No No

Tabela 1: Descrio dos estados do servio (EUCALYPTUS, 2012a) Na tabela 1 h a descrio de todos os estados do servio: A visualizao do estado do servio indica: Tipo de componente do servio; Partio em que o servio est registrado; O nome exclusivo do servio; Viso atual do estado do servio. A sada padro inclui os servios que so registrados durante a congurao, bem como informaes sobre o servio de DNS, se houver. Pode-se fazer pedidos para recuperar informaes sobre o servio que ltrado por meio de: O estado atual (por exemplo, NOTREADY); Host onde o servio est registrado; Partio onde o servio est registrado; Tipo de servio (por exemplo, CC, ou Walrus). Na investigao de falhas de servio, pode-se especicar eventos para retornar um resumo da ltima falha. Dessa forma recupera-se informaes teis principalmente para depurao.

40

Nesse sentido, o Eucalyptus capaz de gerar arquivos de congurao para aplicativos especializados em monitoramento como o Nagios e o Ganglia.

4.1.7

ALTA DISPONIBILIDADE

Alta disponibilidade (HA) (High Availability) o resultado da combinao das funcionalidades fornecidas pelo Eucalyptus para manter o funcionamento adequado dos sistemas constituintes. As seguintes funcionalidades esto habilitadas para a manuteno dessa caracterstica: Deteco de falhas de servio e o monitoramento da integridade do sistema: reunir o status do servio, determinar a topologia de servio atual, admitir solicitaes que podem ser atendidas usando somente topologias com servios com bom funcionamento; Ferramentas para interrogar a sade do sistema: acesso a informaes de estado do servio; Pesquisa de erros para ajudar a determinar a causa: o acesso s informaes de falha impacta a funo de servio; Failover automatizado quando servios redundantes so congurados: remoo de servios com defeito e a habilitao de servios com bom funcionamento; Controle de estado do servio: capacidade de remover individualmente um componente de determinado servio de operao sem interromper o servio; Substituio/restaurao de servios de componentes: processos de substituio/restaurao de um componente de servio aps uma falha de perda total, por exemplo falha de disco. Noes bsicas sobre a disponibilidade do sistema: O impacto de uma falha do servio com a disponibilidade do sistema depende da implantao e congurao do sistema. A tabela 2 detalha o escopo que uma falha de servio pode ter em relao a disponibilidade do sistema para cada tipo de componente. Uma maneira rpida de avaliar a disponibilidade do sistema determinar se: A nuvem tem um CLC habilitado; A nuvem tem um Walrus habilitado;

41 Componente Cloud Controller Walrus Cluster Controller Escopo (Regio da Falha) Nuvem Nuvem Zona de Disponibilidade Descrio O CLC um servio de nuvem e deve ter ao menos um sevio ativo Walrus um servio de nuvem e deve ter ao menos um sevio ativo CCs esto associados a uma partio e solicitaes especcas para uma zona de disponibilidade de servio. Uma zona de disponibilidade no deve ter um CC operacional, pois solicitaes sero rejeitadas para a zona correspondente SC esto associados a uma partio e solicitaes especcas para uma zona de disponibilidade de servio. Uma zona de disponibilidade no deve ter um volume de storage contoller operacional e solicitaes de criao de sero rejeitadas para a zona correspondente VMware Broker est associado a uma partio e solicitaes especcas para uma zona de disponibilidade de servio. Uma zona de disponibilidade no deve ter um VMware Broker operacional e solicitaes sero rejeitadas para a zona correspondente Arbitrators esto associados com um host que executa servios de componentes voltados para o usurio (CLC, Walrus). Cada host deve ter um Arbitrator operacional. Se um host de servio do componente tiver um Arbitrator congurado, mas com defeito uma condio de fail-stop ocorre e relatrio de servios do hospedeiro gera um erro NOTREADY NCs esto associados a cada n e interagem com o hypervisor para atender as solicitaes especcas do n

Storage Controller

Zona de Disponibilidade

VMware Broker

Zona de Disponibilidade

Arbitrators

Host de Servios voltados para o usurio

Node Controller

Compute Host

Tabela 2: Relao Falha X Disponibilidade do sistema (EUCALYPTUS, 2012a) A zona de disponibilidade tem um CC habilitado; A zona de disponibilidade tem um SC habilitado; O Arbitrator associado a um host que executa servios voltados para o usurio (se um Arbitrator for congurado).

4.1.8

SITUAO ATUAL DO PROJETO

O Eucalyptus, atualmente, divide-se em dois grandes segmentos: Eucalyptus IaaS e o Eucalyptus Opensource. O Eucalyptus Opensource de cdigo aberto, porm possui algumas

42

limitaes se comparado ao Eucalyptus IaaS que uma soluo mais completa possuindo principalmente um suporte melhor ao sistema virtual Vmware, alm de compatibilidade com o AWS. Em nmeros, estima-se que atualmente 25.000 nuvens computacionais utilizem uma das verses do Eucalyptus (ambientes acadmicos e comerciais).

4.2
4.2.1

OPENNEBULA
INTRODUO

De acordo com o (OPENNEBULA, 2012a), o OpenNebula.org um projeto open source que desenvolve a soluo padro da indstria para criao e gerenciamento de data centers corporativos virtualizados e infraestruturas na nuvem. OpenNebula visa proporcionar uma camada de gerenciamento aberta, exvel, extensvel e abrangente para automatizar e orquestrar a operao de datacenters virtualizados, aproveitando e integrando solues implantadas existentes para redes, armazenamento, virtualizao, monitoramento ou gerenciamento de usurios. O projeto OpenNebula.org tem os seguintes objetivos a m de levar a inovao na gesto de data centers de nuvem corporativa: Desenvolver a soluo mais avanada, altamente escalvel e exvel para a criao e gerenciamento de data centers virtualizados e infraestruturas na nuvem; Garantir a estabilidade e a qualidade de distribuio de software; Colaborar com os usurios mais exigentes das ferramentas de gerenciamento de data centers e nuvem; Propagao do conhecimento do projeto; Suporte do ecossistema de componentes de cdigo aberto que esto sendo criados em torno do projeto; Apoiar a comunidade de usurios e desenvolvedores que contribuem para o projeto; Colaborar com outros projetos de cdigo aberto e comunidades; Colaborar com os principais projetos de pesquisa em inovao de Computao em Nuvem.

43

Os principais valores do projeto OpenNebula.org so: Abertura dos processos e a tecnologia; Excelncia, por ser um projeto de alta qualidade em cada aspecto de suas operaes; Cooperao com os esforos de cdigo aberto e projetos de pesquisa para avanar em Computao em Nuvem; Inovao em novas tecnologias e mtodos para atender s necessidades de implantaes em larga escala de nuvem.

4.2.2

HISTRIA

OpenNebula foi criado como um projeto de pesquisa em 2005 por Ignacio M. Llorente e Rubn S. Montero. Desde sua primeira verso pblica do software em maro de 2008, houveram evolues atravs de verses de cdigo aberto e agora opera como um projeto open source. OpenNebula o resultado de muitos anos de pesquisa e desenvolvimento em gesto eciente e escalvel de VMs em intraestruturas distribudas, com estrita colaborao da comunidade de usurios (OPENNEBULA, 2012a). A tecnologia OpenNebula amadureceu graas a esses usurios e desenvolvedores. Diferentes projetos, grupos de pesquisa e empresas construram novos componentes da nuvem para complementar e melhorar a funcionalidade fornecida por este conjunto de ferramentas de cdigo aberto. Em maro de 2010, os principais autores de OpenNebula criaram C12G Labs para permitir que o projeto OpenNebula no seja vinculado exclusivamente ao nanciamento pblico. OpenNebula.org agora um projeto gerido pelos C12G Labs. A tabela 3 fornece um resumo bastante detalhado das principais etapas do projeto OpenNebula.

4.2.3

ARQUITETURA

Visando criar um sistema modular e independente de plataforma, e ao mesmo tempo tentando suprir essas funcionalidades descritas acima, que so raramente encontradas em sistemas de computao em nuvem similares, foi denida e desenvolvida a arquitetura do OpenNebula, sendo essa mostrada na Figura 4.

44 Verso OpenNebula 3.4 Released OpenNebula 3.4 Beta Release OpenNebula 3.2 Released OpenNebula 3.2 Beta Release OpenNebula 3.0 Released OpenNebula 3.0 Beta 2 Release OpenNebula 3.0 Beta1 Release OpenNebula 2.2 Released OpenNebula 2.2 Beta1 Release OpenNebula 2.0 Released OpenNebula 2.0 Beta1 Release OpenNebula Cloud Toolkit Goes Commercial New Web Site for OpenNebula.org OpenNebula 1.4 Released OpenNebula Cloud Announcement OpenNebula 1.4 RC Released! OpenNebula 1.4 Beta 2 Released! New Research Grants to Fund OpenNebula until 2012 OpenNebula Tarantula Stable version 1.2.1 OpenNebula 1.4 Beta1 Codename Hourglass out for Testing Ubuntu 9.04 (Jaunty Jackalope) has been released today bringing OpenNebula OpenNebula Wins the Best Demo Award at OGF25/4th EGEE-UF OpenNebula 1.2 release OpenNebula 1.2 beta release Release of OpenNebula 1.0 for Data Center Virtualization & Cloud Solutions New Technology Preview (TP2) of the OpenNebula (ONE) Virtual Infrastructure Engine Technology Preview of the OpenNebula (ONE) Virtual Infrastructure Engine Lanamento 10/04/2012 29/03/2012 17/01/2012 16/12/2011 03/10/2011 08/09/2011 20/07/2011 28/03/2011 02/03/2011 24/10/2010 28/07/2010 05/05/2010 24/02/2010 16/12/2009 18/11/2009 18/11/2009 30/10/2009 04/09/2009 29/07/2009 23/07/2009 23/04/2009 09/03/2009 06/02/2009 05/12/2008 24/07/2008 24/07/2008 24/07/2008

Tabela 3: Evoluo Projeto OpenNebula (OPENNEBULA, 2012a) Os componentes bsicos do OpenNebula so: Front End: executa os servios do OpenNebula; Host: habilitados com hypervisor e fornecem os recursos necessrios para as VMs; Datastore: armazena as imagens das VMs; Service Network e VM Networks: redes fsicas usadas para oferecer suporte a servios bsicos (interligao dos servidores de armazenamento e operaes de controle do OpenNebula) e a VLAN (Virtual Local Area Network) para as VMs, respectivamente. 4.2.3.1 FRONT END

O modo de operao da nuvem construda por meio da ferramenta OpenNebula baseado em uma arquitetura semelhante ao modelo clssico dos clusters, onde um n de front end

45

Figura 4: Sistema Modular OpenNebula (OPENNEBULA, 2012b) responsvel pela execuo dos servios de administrao da infraestrutura, enquanto os demais ns computacionais executam as mquinas virtuais que consumiro os recursos disponveis. Neste modelo, ao menos uma rede de comunicao fsica utilizada para a interligao de todos os ns. A Figura 5 ilustra o ambiente constitudo pela nuvem privada em questo.

Figura 5: Arquitetura OpenNebula (OPENNEBULA, 2012b) O n de front end executa o OpenNebula Daemon, que representa o ncleo do sistema e administra o ciclo de vida das mquinas virtuais, alm de outros aspectos relativos ao funcionamento dos demais ns (como rede, armazenamento e hypervisors). Neste n tambm so executados os drivers da ferramenta, responsveis pela constituio de interfaces entre o ncleo do sistema e elementos externos, como hypervisors e sistemas de arquivos especcos. O n de

46

front end pode, ainda, atuar como repositrio de imagens de mquinas virtuais, embora este no seja seu modo de funcionamento ideal. Os demais ns tm hypervisors habilitados para a execuo de mquinas virtuais. A comunicao entre o n de front end e os ns com hypervisors se d por meio de canais de SSH. Alternativamente, a criptograa destes canais pode ser desabilitada, resultando em um melhor tempo de transmisso das imagens das mquinas virtuais a serem executadas em um dado n. OpenNebula compreende a execuo de trs tipos de processos, como pode ser visto na Figura 6. O OpenNebula daemon (oned): Um processo centralizado que gerencia o ciclo de vida das VMs e orquestra a operao de todos os mdulos; Os drivers: Para acessar aos sistemas especcos do cluster (por exemplo, armazenamento ou hypervisors). Fornecem uma abstrao da camada de virtualizao subjacente. Assim, OpenNebula no est vinculado a nenhum ambiente especco, proporcionando uma camada uniforme de gesto, independiente da tecnologia de virtualizao utilizada; O scheduler: Para ajustar a locao das VMs com base em um conjunto de polticas pr-denidas.

Figura 6: Processos OpenNebula (OPENNEBULA, 2012b)

4.2.3.2

HOST

Os hosts so as mquinas fsicas que executaro as VMs. Durante a instalao, deve-se congurar a conta administrativa do OpenNebula para ser capaz de utilizar o SSH para os hosts, e dependendo do hypervisor utilizado essa conta de est autorizada a executar comandos com privilgios de root. 4.2.3.3 DATASTORE

O OpenNebula usa datastores para lidar com as imagens de disco das VMs. Imagens das VMs so registradas ou criadas (volumes vazios) em um armazenamento de dados. Em

47

geral, cada armazenamento de dados deve ser acessvel atravs do front end usando qualquer tecnologia adequada NAS (Network-Attached Storage), SAN ou armazenamento com conexo direta. Quando uma VM implantada as imagens so transferidas do datastore aos hosts. 4.2.3.4 SERVICE NETWORK E VM NETWORKS

O OpenNebula fornece um subsistema de rede personalizvel e facilmente adaptvel para integrar melhor com os requisitos de rede especcos de datacenters existentes. Para oferecer conectividade de rede para as VMs entre hosts diferentes, feita uma conexo entre a interface de rede de mquina virtual a uma bridge no host fsico. Deve-se criar a bridge com o mesmo nome em todos os hosts.

4.2.4

SISTEMAS DE VIRTUALIZAO SUPORTADOS

O OpenNebula possui suporte aos seguintes VMMs: Xen, KVM e VMware.

4.2.5

BACKUP

Para gerenciar o backup, o OpenNebula utiliza o LVM (Logical Volume Manager). Uma das vantagens deste conceito que h um nico lugar para backup e restaurao, no servidor de armazenamento, onde pode-se usar os recursos de clonagem/snapshot para criar backups dos servidores sem interrupo do servio (OPENNEBULA, 2012b). Alm disso o LVM permite o redimensionamento dinmico, ou seja, com o sistema operacional sendo utilizado. A grande desvantagem do LVM que por ser um nico disco virtual a recuperao de dados bastante prejudicada.

4.2.6

MONITORAMENTO

O OpenNebula oferece interfaces de gerenciamento para integrar as funcionalidades do ncleo dentro de outras ferramentas de gerenciamento do datacenter, como frameworks para monitoramento. Para este m, OpenNebula implementa a libvirt, uma interface aberta para o gerenciamento de mquinas virtuais, e tambm uma interface de linha de comando. Estas funcionalidades so expostas aos usurios externos atravs de uma interface para nuvem. A implementao do libvirt no OpenNebula permite usar qualquer aplicativo libvirt em um nvel distribudo. Desta forma possvel usar qualquer ferramenta libvirt, como o virt-manager,

48

para conectar-se ao OpenNebula. Sendo assim voc pode gerenciar e monitorar suas VMs em um ambiente distribudo usando as ferramentas libvirt. A arquitetura do libvirt apresentada na Figura 7 abaixo:

Figura 7: Arquitetura libvirt (OPENNEBULA, 2012c) Por exemplo, pode-se criar o domnio com virsh create e em seguida o OpenNebula vai olhar para um recurso adequado, transferir as VMs e iniciar a VM usando qualquer um dos hypervisors suportados. A gesto distribuda completamente transparente para a aplicao libvirt.

4.2.7

ALTA DISPONIBILIDADE

Tornando o OpenNebula totalmente redundante: De acordo com (OPENNEBULA, 2012d), para tornar o OpenNebula totalmente redundante preciso ter dois controladores de nuvem em modo ativo/passivo de alta disponibilidade. Esses ns tambm iro fornecer armazenamento exportando uma partio DRBD (Distributed Replicated Block Device). Os discos da VM sero criados sobre os volumes lgicos LVM nesta partio. Esta soluo, alm de ser totalmente redundante, ir fornecer armazenamento de alta velocidade porque no usamos arquivos NFS para implantar as parties da VM e sim

49

snapshots. No entanto, o NFS ainda se faz necessrio para exportar o diretrio de dados da nuvem do OpenNebula. Estas so as aes a serem tomadas: Instalao de 2 servidores, habilitando o SSH em ambos; Criar um diretrio especco para replicao do DRBD e um outro para exportao dos sistemas de arquivos da VM; Congurar 2 placas de rede para gerenciar a replicao de dados e se comunicar com a SAN e uma 3a placa para acesso externo do cluster a LAN; Congurar a LAN; Congurar o MySQL; Congurar o DRBD. A partir da, como j mencionado, as duas parties DRBD sero visveis atravs da rede, embora de formas diferentes: um disco ser exportado atravs de NFS, enquanto o outro apresentar suas parties LVM para o hypervisor.

4.2.8

SITUAO ATUAL DO PROJETO

O OpenNebula mantem apenas um projeto que possui cdigo aberto. Atualmente, esse framework largamente utilizado principalmente por universidades, centros de pesquisa e empresas de ramos como hospedagem de dados e telefonia. Estima-se que o OpenNebula distribua 4.000 cpias do seu projeto por ms.

4.3
4.3.1

OPENQRM
INTRODUO

O openQRM uma soluo em cdigo aberto para gerenciamento de data centers em uma nuvem computacional. Projetado para automatizar os data centers e gerenci-los de uma maneira escalvel, o openQRM possui entre suas muitas caractersticas uma arquitetura exclusiva que unica a implantao entre mquinas fsicas e virtuais dentro de um nico console de gerenciamento. openQRM integra-se com todas as principais tecnologias de virtualizao e suporta

50

de forma transparente migraes P2V (Physical-to-Virtual), V2P (Virtual-to-Physical) e V2V (Virtual-to-Virtual). O storage do openQRM utiliza snapshots para clonar servidores para implantao rpida, backup / restaurao, servidor para controle de verso, redimensionamento de disco e armazenamento persistente em nuvem. O openQRM tambm fornece failover N para 1 permitindo que grupos de servidores possam usar um nico servidor em standby. O failover de mquinas fsicas para virtuais tambm realizado. Com seu conceito de capacidade de plug o openQRM combina produtos de cdigo aberto e comerciais de terceiros na administrao de data centers, monitoramento de sistema e servio, alta disponibilidade e com provisionamento automatizado dentro de um nico console de gerenciamento.

4.3.2

HISTRIA

A verso inicial do openQRM foi desenvolvida pela empresa Qlusters fundada em 2001. Inicialmente a Qlusters esteve concentrada em HPC mudando seu foco de negcios para o gerenciamento de data centers em 2003. A primeira verso do openQRM foi baseada na linguagem de programao Java sendo desenvolvida at a verso 3.1.4 quando a empresa fechou suas portas no incio de 2008. O impressionante que a verso do openQRM de 2005 j incluia um sistema de provisionamento totalmente automatizado e o suporte para implantao de mquinas virtuais muito semelhante ao conceito que hoje atribudo a Computao em Nuvem, sendo nomeado Utility Computing. Com um crescimento grande e complexo causado por um longo desenvolvimento histrico das ltimas verses do 3.x, o openQRM teve sua licena comercial alterada para open source em 2006. Matthias Rechenburg estava trabalhando como gerente de projetos da Qlusters desde o incio desta verso do openQRM. Com o fechamento da Qlusters em 2008 ele decidiu continuar com o projeto do openQRM dirigido a comunidade open source. A verso 4.0 do openQRM foi reescrita do zero, tendo suas caractersticas e mecanismos voltados para a linguagem PHP (Hypertext Preprocessor) tornando-se muito mais leve. No prazo de apenas 2 anos de re-design a equipe do openQRM conseguiu superar as funcionalidades do openQRM antigo, alm de deixar pronta a verso corporativa. O lanamento do openQRM 5.0 est previsto para 1o de agosto de 2012. Mesmo aps o fechamento da Qlusters a equipe do openQRM decidiu manter seu nome original, hoje administrada pela openQRM Enterprise.

51

A tabela 4 fornece um resumo bastante detalhado das principais etapas do projeto openQRM.
Verso openQRM-4.9 openQRM-4.8 openQRM-4.7 openQRM-4.6 openQRM 4.5 openQRM 4.4 openQRM 4.3 openQRM 4.2 openQRM 3.1.4 openQRM 4.1 openQRM 4.0 openQRM 3.5.2 (discontinued) openQRM 3.1.3 openQRM 3.1.2 openQRM 3.1 openQRM 3.0 openQRM 2.2 openQRM 2.1 Data de Lanamento 31/10/2011 31/03/2001 30/09/2010 05/01/2010 18/07/2009 14/03/2009 30/12/2008 15/11/2008 26/09/2008 26/09/2008 13/06/2008 08/04/2008 18/03/2007 28/12/2006 22/11/2006 05/10/2006 25/07/2006 08/02/2006

Tabela 4: Evoluo Projeto openQRM (SOURCEFORGE, 2012)

4.3.3

ARQUITETURA

Como a viso geral do conceito apontada para o gerenciamento de um data center com todos os seus componentes uma tarefa difcil que faz com que (como conhecemos) rapidamente sobrecarregue os recursos de um nico aplicativo, a alta disponibilidade s pode funcionar bem se todos os componentes esto bem integrados e colaborem de uma forma denida. O servidor do openQRM constitudo pela base e pelos plugins. A base centralizada apenas gerencia os plugins e fornece a estrutura para que estes possam interagir por exemplo, com recursos, imagem, storage e outros objetos. Essa abordagem tem diversas vantagens: desenvolvimento rpido porque os desenvolvedores podem trabalhar em paralelo com plugins diferentes; robustez reforada por causa de uma base robusta que no muda muito; fcil integrao de componentes de terceiros atravs de uma API de plugin bem denida; os bugs em um dos plugins no prejudicam o sistema base;

52

Figura 8: Arquitetura openQRM (OPENQRM, 2012b) menor complexidade porque o plugin gerencia apenas o seu prprio ambiente; menos cdigo no mecanismo base e menos cdigo signica menos bugs; melhor escalabilidade porque os plugins podem ser ativados / desativados em tempo real; os plugins so fceis de se desenvolver por causa do conceito base com que foram desenhados.

4.3.4

SISTEMAS DE VIRTUALIZAO SUPORTADOS

O openQRM possui suporte ao Xen, KVM e VMware. Tambm possui suporte ao LinuxVServer.

4.3.5

BACKUP

Assim como o OpenNebula, o openQRM tambm utiliza o LVM.

4.3.6

MONITORAMENTO

Em relao ao monitoramento, nenhuma ferramenta apresentada para o controle dos componentes do openQRM e das mquinas virtuais. O openQRM possui integrao com softwares de monitoramento (tais como Nagios, Zabbix e collectd).

53

4.3.7

ALTA DISPONIBILIDADE

Ao falar sobre TI Verde a abordagem atual usar a virtualizao para consolidar muitos servidores fsicos para executar como virtuais em um host hypervisor. Enquanto este mtodo bom para diminuir o consumo geral de energia, muitas vezes esquecido que dada a situao, no caso do nico host hypervisor falhar todos os servidores virtuais que rodam nesse host tambm caro indisponveis. Dessa forma, no moderno mundo virtual, se faz necessrio cuidar especialmente da alta disponibilidade. HA em nvel de recurso: O mtodo usual para manter o sistema altamente disponvel utilizar 10 servidores personalizados: Obter 10 servidores adicionais com as mesmas conguraes do host em uso; Congurar a sincronizao dos discos entre os 10 pares de servidor; Implementar uma soluo de fail-over para o servio em execuo sobre os 10 clusters. Como resultado, este mtodo requer 20 sistemas fsicos para manter 10 servidores de alta disponibilidade. HA no openQRM: Implantar os 10 servidores personalizados via openQRM; Adicione 1 servidor como Hot-Standby. No caso de um dos 10 servidores personalizados parar o openQRM vai usar o sistema de um disponvel para reinici-lo atravs dos seus mtodos de implementao rpida. Sendo assim, 10 (ou mais) servidores de alta disponibilidade podem ser congurados com apenas uma nica sendo Hot-Standby. Isso economiza o consumo de energia de 9 servidores! HA em Nvel de Aplicao: Para o nvel de aplicao, HA pode ser feito no openQRM adicionando vericaes personalizadas pelo Nagios para monitorar o estado do servio de uma aplicao especca. Caso esta vericao falhe, ele pode tomar algumas aes para reativar o servio: Reiniciar o servio;

54

Forar um reboot; Forar um fail-over para uma aplicao passiva de espera. HA em nvel de aplicao ainda no est automatizado no openQRM, portanto deve ser realizado de forma manual. HA para o servidor de openQRM: A equipe do openQRM recomenda usar o Linux-HA para a congurao da alta disponibilidade. Segue abaixo os requisitos para o openQRM HA: 2 ou mais sistemas para os ns do cluster ativos e utilizando openQRM Armazenamento-Compartilhado fornecendo ao servidor openQRM arquivo de dados Base de dados (remoto) externo Pode-se levar em considerao o openQRM instalado no sistema fsico ou na mquina virtual. Abaixo so descritos os passos para instalar o openQRM em alta disponibilidade: Instalar o sistema operacional nos sistemas dedicados para os ns do cluster openQRM Montar o armazenamento compartilhado em openQRM em todos os ns do cluster Congurar o Linux-HA com um cluster de endereo IP Instalar o openQRM em um nico sistema! O Linux-HA car responsvel por sempre manter o sistema em funcionamento.

4.3.8

SITUAO ATUAL DO PROJETO

O openQRM divide-se em dois projetos: o Open Source e o Enterprise. O openQRM Open Source de cdigo aberto, porm possui algumas limitaes se comparado ao openQRM Enterprise que uma soluo mais completa possuindo principalmente um suporte melhor ao Vmware, alm de autenticao pelo protocolo LDAP (Lightweight Directory Access Protocol) (OPENQRM, 2012a).

55

4.4
4.4.1

OPENSTACK
INTRODUO

OpenStack oferece software open source para criar nuvens pblicas e privadas. OpenStack uma comunidade e um projeto para ajudar as organizaes a executar nuvens de computao virtuais ou storage. OpenStack contm uma coleo de projetos open source que so mantidos pela comunidade, incluindo o Compute (codinome Nova), o Object Storage (codinome Swift) e o Image Service (codinome Glance). OpenStack fornece uma plataforma operacional ou toolkit, para orquestrar as nuvens. OpenStack mais facilmente denido quando os conceitos de Computao em Nuvem se tornam aparentes. Dessa forma o OpenStack tem como misso fornecer nuvens computacionais pblicas e privadas de forma escalvel e elstica. No corao de sua misso h um par de requisitos bsicos: nuvens devem ser simples de implementar e massivamente escalveis.

4.4.2

HISTRIA

O OpenStack um conjunto de projetos de software open source que empresas e provedores de servios podem usar para congurar e operar sua infraestrutura de computao e armazenamento em nuvem. Fundada em 2010 teve a Rackspace (provedor de infraestrutura americano) e a NASA (National Aeronautics and Space Administration) (agncia espacial americana) como seus principais contribuidores iniciais para o projeto. A Rackspace forneceu sua plataforma Cloud Files para implementar o aspecto de armazenamento (Object Storage) do OpenStack, enquanto que a NASA entrou com o Nebula para implementar o lado computacional (Compute). O consrcio OpenStack desde ento agregou mais de 100 membros em menos de um ano, incluindo a Canonical (responsvel pelo Ubuntu), Dell e Citrix. Essex foi a ltima verso (das cinco) lanada pelo OpenStack, em abril de 2012. Antes desta foram lanadas as verses Austin, Bexar e Cactus, alm da Diablo. A tabela 5 mostra a evoluo do projeto OpenStack, indicando a data de lanamento prevista para sua nova verso, a Folsom:

4.4.3

ARQUITETURA

O OpenStack consiste de vrios componentes principais. Um controlador de nuvem contm muitos desses componentes e interage com todos os outros. Um servidor API atua como

56 Verso Folsom Essex Diablo Cactus Bexar Austin Data de Lanamento 27/09/2012 (previso) 05/04/2012 22/09/2011 15/04/2011 03/02/2011 21/10/2010

Tabela 5: Evoluo Projeto OpenStack (OPENSTACK, 2012b) web service front end da controladora de nuvem. O controlador fornece recursos de servidor e contm, normalmente, o servio de computao. O componente The Object Store, opcionalmente, oferece servios de armazenamento. Um gerenciador de autenticao fornece, alm desse servio, autorizao quando usado com o sistema de computao ou voc pode usar o Identity Service (keystone) como um servio de autenticao separado. Um controlador de volume fornece armazenamento de blocos rpido e permanente para os servidores. Um controlador de rede proporciona redes virtuais para permitir que servidores possam interagir uns com os outros e com a rede pblica. Um programador seleciona o controlador mais adequado para uma instncia de host. O OpenStack construdo sobre uma arquitetura baseada em mensagens, nada compartilhado. Um controlador de nuvem se comunica com o armazenamento do objeto interno atravs de HTTP, mas ele se comunica com um scheduler, com o controlador de rede e com o controlador de volume via AMQP (Advanced Message Queue Protocol). Para evitar o bloqueio de cada componente enquanto aguarda uma resposta, o OpenStack usa chamadas assncronas, com um retorno de chamada que obtm acionado quando uma resposta recebida. Para obter a propriedade de nada compartilhado com vrias cpias do mesmo componente, o OpenStack mantm todo o estado do sistema de nuvem em um banco de dados. Object Storage (Swift): oferece armazenamento de objeto. Ele permite que armazenamento ou recuperao de arquivos, mas no montar diretrios como um servidor de arquivos). Existem vrias empresas de prestao de servios de armazenamento comercial baseados em Swift. Estes incluem KT, Rackspace (que originou o Swift) e a Internap. Image Service (Glance): fornece um catlogo e um repositrio de imagens de disco virtual. Estas imagens de disco so principalmente usadas no OpenStack Compute. Embora este servio seja tecnicamente opcional, qualquer nuvem necessitar dele.

57

Compute (Nova): fornece servidores virtuais a demanda. Semelhante ao servio de EC2 da Amazon, ele tambm fornece servios de volume anlogos para EBS. usado internamente na NASA (onde se originou). A partir da quinta verso foram promovidos dois novos projetos para o status do projeto ncleo: Dashboard (Horizon): fornece uma interface de usurio baseada na web modular para todos os servios do OpenStack. Identity (Keystone): fornece autenticao e autorizao de todos os servios do OpenStack. Ele tambm fornece um catlogo de servios dentro de uma implantao especca. Esses novos projetos oferecem infraestrutura adicional para oferecer suporte aos trs projetos originais.

Figura 9: Arquitetura OpenStack (OPENSTACK, 2012a)

4.4.4

SISTEMAS DE VIRTUALIZAO SUPORTADOS

O OpenStack possui suporte ao KVM, LXC (Linux Containers), QEMU (Quick EMUlator), UML (User Mode Linux), VMware e Xen.

4.4.5

BACKUP

Processo de recuperao de desastres atravs do Nova

58

Um incidente nunca planejado, por sua denio. s vezes, simplesmente as coisas no do certo. Nesta seo, ser analisado o gerenciamento da nuvem aps um desastre e como facilmente fazer o backup dos volumes de armazenamento persistente, que uma outra abordagem, quando enfrentar um desastre. Apresentao do processo de recuperao de desastres Um desastre pode acontecer com vrios componentes da arquitetura: uma falha no disco, uma perda de rede, um corte de energia, etc. Neste exemplo, supomos a seguinte congurao: 1. Um controlador de nuvem (Nova-api, Nova-objecstore, Nova-volume, Nova-network) 2. Um n de computao (Nova-compute) 3. Uma SAN usada pelos volumes de Nova (aka SAN) O exemplo de desastre ser o pior: uma queda de energia. Perda de potncia aplica-se a trs componentes. Abaixo temos o que funciona e como so executados antes do acidente: De SAN para o controlador de nuvem, ns temos uma sesso iSCSI ativa (usada para o volume de Nova). Do controlador de nuvem para o n de computadores tambm temos sesses iSCSI ativas (gesto do volume de Nova). Para cada volume uma sesso iSCSI feita (portanto, se temos 14 volumes EBS, temos 14 sesses). Do controlador de nuvem para o n de computadores tambm temos iptables/ebtables que permite o acesso do controlador de nuvem para a instncia em execuo. E, pelo menos, do controlador de nuvem para o n de computadores, temo salvo no banco de dados o estado atual de instncias executando e a xao de volumes (ponto de montagem, identicao de volume, o status do volume, etc...) Agora, aps a queda de energia e o reincio de todos os componentes de hardware, a situao a seguinte: A partir da SAN para a nuvem, a sesso iSCSI j no existe.

59

A partir do controlador de nuvem para o n de computao, as sesses iSCSI j no existem. A partir do controlador de nuvem para o n de computao, o iptables e ebtables so recriados, desde que, no boot, a rede da Nova reaplique as conguraes. A partir do controlador de nuvem, instncias transformam-se em um estado de desligamento (porque j no esto funcionando) No banco de dados, dados no foram atualizados corretamente, j que a Nova no poderia ter adivinhado o acidente. O plano executar as seguintes tarefas na ordem exata. Qualquer etapa extra seria perigosa nesta fase: 1. Obter a relao atual de um volume a sua instncia, uma vez que o anexo ser recriado. 2. Atualizar o banco de dados para limpar o estado parado. (Depois disso, a etapa anterior no poder ser realizada). 3. preciso reiniciar as instncias (sair de um estado de desligamento para um estado de execuo). 4. Aps a reinicializao, reanexar os volumes de suas respectivas instncias. O processo de recuperao de desastres Instanciar o volume, recriando o anexo: Essa relao poderia ser gurada executando a lista de volumes da nova Atualizao de banco de dados Em segundo lugar, atualizar o banco de dados para limpar o estado parado. Agora que os anexos esto salvos se faz necessrio restaurar cada volume no banco de dados limpo. Agora, ao executar a lista de volumes da Nova todos os volumes devem estar disponveis. Reincio de instncias preciso reiniciar as instncias. Isso pode ser feito por meio de um reincio na Nova.

60

Nesta fase, dependendo da imagem, para alguns casos iro reiniciar completamente e se tornar alcanveis, enquanto outros vo parar no estgio plymouth. No aconselhvel reinicializar uma segunda vez os que esto parados nessa fase (abaixo, a quarta etapa). Na verdade, isso depende se foi adicionada uma entrada para esse volume ou no. Imagens criadas podem permanecer em um estado pendente, enquanto outras vo ignorar o volume ausente e comear. De qualquer modo a ideia dessa fase somente pedir a Nova para reiniciar a cada instncia, para que o estado armazenado seja preservado. Anexar volume Aps a reinicializao, pode-se reanexar os volumes de suas respectivas instncias. Agora se a Nova tiver restaurado o estado de direito, hora de anexar os volumes. Nessa fase, instncias que estavam pendentes na seqncia de inicializao (plymouth) iro automaticamente continuar seu reincio normalmente. SSH em instncias Se alguns servios dependem do volume o ideal seria simplesmente reiniciar a instncia. Essa reinicializao precisa ser feita desde a instncia propriamente dita, no atravs de Nova. Recuperao de desastres com script Existe um script que executa estes cinco passos. O test mode permite que voc execute essa seqncia inteira para apenas uma instncia. Para reproduzir a perda de energia, conecte com o n de computao que executa essa mesma instncia e feche a sesso iSCSI. Essa ao deve ser feita manualmente e no atravs de Nova. O OpenStack utiliza o XenCenter para fazer o monitoramento e gerenciamento das mquinas virtuais. O XenCenter possui suporte exvel ao console utilizado. Para o gerenciamento do backup a sugesto pelo uso do Gladinet Cloud Backup. Este software foi lanado primeiro como um produto independente. Hoje, o Gladinet Cloud Backup se integra com o servio de Shadow Copy do Windows para fornecer servios de nuvem para armazenamento de snapshots.

4.4.6

MONITORAMENTO

O monitoramento do OpenStack feito atravs do Nova, seu gerenciador da infraestrutura computacional. Atravs da API Server (nova-api), Nova fornece uma interface para que o

61

mundo exterior interaja com a infraestrutura da nuvem. O API Server o nico componente do Nova que o mundo exterior usa para gerenciar a infraestrutura. O gerenciamento feito atravs de web services, utilizando uma API compatvel com a EC2. O API Server se comunica com os outros componentes necessrios atravs da Message Queue (Fila de Mensagens). Os componentes do OpenStack comunicam-se entre si atravs do protocolo AMQP implementado pela Message Queue. O Nova usa chamadas assncronas para as requisies, com um mecanismo que acionado quando a resposta recebida. Uma vez que a comunicao assncrona, nenhuma das pontas ca bloqueada por muito tempo em um estado de espera. Isto especialmente importante dado que muitas aes invocadas atravs das APIs envolvem tempos longos, como criar uma instncia ou fazer o upload de uma imagem. O OpenStack utiliza o XenCenter para fazer o monitoramento e gerenciamento das mquinas virtuais.

4.4.7

ALTA DISPONIBILIDADE

Opes existentes de alta disponibilidade para redes O DHCP (Dynamic Host Conguration Protocol) tratado pela nova-network. Os hosts de computao podem, opcionalmente, ter seus prprios IPs pblicos, ou eles podem usar o host de rede como sua porta de entrada. Este modo bastante simples e funciona na maioria das situaes, mas tem uma grande desvantagem: a rede possui um ponto nico de falha! Se o host de rede for desligado por qualquer motivo, impossvel se comunicar com as VMs. Aqui esto algumas opes para evitar o ponto nico de falha. HA opo 1: conexo Para eliminar o host de rede como um ponto nico de falha, nova-compute pode ser congurado para permitir que cada host de computao faa todos os trabalhos de rede para suas prprias VMs. Cada host de computao faz NAT (Network Address Translation), DHCP e atua como um gateway para todas as suas prprias VMs. Esta instalao requer adicionar um IP na rede VM para cada host no sistema e isso implica um pouco mais de sobrecarga nos hosts de computao. Dessa forma todos os hosts do sistema estaro executando o nova-compute, nova-network e servios da nova-api. Cada host faz DHCP e faz NAT para o trfego de pblico para as VMs em execuo no host especco. Neste modelo, cada host de computao requer uma conexo Internet pblica e a cada host tambm atribudo um endereo de rede VM onde ele escuta o

62

trfego DHCP. O servio da nova-api necessrio para que ele possa atuar como um servidor de metadados para as instncias. Para executar no modo HA, cada host de computao deve executar os seguintes servios: nova-compute nova-network nova-api HA opo 2: Failover Nos laboratrios da NTT (Nippon Telegraph and Telephone Corporation) foi criado um ha-linux que permite um failover de 4 segundos para um backup dinmico do host de rede. Esta soluo denitivamente uma opo, embora exija um segundo host que essencialmente no faz nada a no ser que haja uma falha. Alm disso, 4 segundos podem ser muito longos para algumas aplicaes em tempo real. HA opo 3: Multi-NIC A Nova possui suporte para multi-NIC. Dessa forma pode-se fazer uma bridge de uma determinada VM em vrias redes. Sendo assim surgem mais algumas opes de alta disponibilidade. possvel congurar duas redes em VLANs separadas e dar as VMs uma NIC e um IP em cada rede. Cada uma dessas redes pode ter seu prprio host de rede atuando como o gateway. Neste caso, a VM tem dois caminhos possveis para ser roteada. Se um deles falhar, ele tem a opo de usar o outro. A desvantagem dessa abordagem que ele libera o gerenciamento de cenrios de falha para o convidado. O convidado deve estar ciente das vrias redes e ter uma estratgia para alternar entre eles.

4.4.8

SITUAO ATUAL DO PROJETO

Conhecido como o Linux da Computao em Nuvem (STACKOPS, 2012), o OpenStack mantem 3 servios principais em seu projeto de cdigo aberto, o de Infraestrutura Computacional (Nova), o de Infraestrutura de Armazenamento (Swift) e o de Gerenciamento de Imagens (Glance). Atualmente, esse framework utilizado por 3386 especialistas, entre pesquisadores e desenvolvedores, alm de 183 empresas.

63

COMPARATIVO DAS SOLUES

5.1

SISTEMAS DE VIRTUALIZAO SUPORTADOS

Em relao aos sistemas de virtualizao possvel destacar que todas as solues apresentadas suportam o Xen, KVM e o VMware. J o openQRM, alm dos citados, suporta tambm o Linux-VServer (fornece virtualizao para sistemas GNU/Linux). Entretanto a soluo que se destaca nessa caracterstica o OpenStack, que suporta os mais variados sistemas de virtualizao, como o LXC (fornece virtualizao para sistemas Linux), QEMU (emulador genrico e open source) e UML (fornece virtualizao para sistemas Linux). Sendo assim, em relao ao critrio Sistemas de Virtualizao Suportados, o OpenStack o que abrange mais Hypervisors entre as solues apresentadas.

5.2

BACKUP

O XenCenter foi projetado com uma interface grca simples, criando snapshots de uma mquina virtual para ns de backup de forma rpida e segura, j que no interrompe os discos da mquina virtual quando executado. O XenCenter permite snapshots manuais ou por scripts, alm de possuir disaster recovery integrado. Alm disso o XenCenter possui integrao com o OpenStack, o que facilita a instalao/congurao e evita problemas no uso dirio. Sendo assim, em relao ao critrio Backup, o OpenStack se destaca das demais solues.

5.3

MONITORAMENTO

Observando as caractersticas das ferramentas de monitoramento utilizadas pelas solues observa-se que XenCenter a ferramenta mais completa entre as apresentadas.

64

Principais caractersticas do XenCenter: Gesto de instalao, congurao e ciclo de vida da mquina virtual completa Acesso aos consoles VM (Xvnc no Linux e Remote Desktop no Windows) Congurao de armazenamento remoto, incluindo suporte a iSCSI Gerenciamento dinmico de memria Integrao com o OpenStack Entre outras Sendo assim, em relao ao critrio Monitoramento, o OpenStack se destaca das demais solues.

5.4

ALTA DISPONIBILIDADE

A alta disponibilidade apresentada pelo OpenStack chama a ateno por oferecer 3 opes: por conexo, por failover e por multi-nic. A API Nova usada nesse processo e o destaque ca por conta da HA por failover. Essa opo utiliza um ha-linux produzido pela NTT que permite um failover de 4 segundos para um backup dinmico de um host. Sendo assim, em relao ao critrio Alta Disponibilidade, o OpenStack se destaca das demais solues.

5.5

SITUAO ATUAL DO PROJETO

Com um acordo com a AWS anunciado em maro de 2012, a Eucalyptus rmou parceria de compatibilidade com a Amazon. Isso signica que o Eucalyptus ir fornecer compatibilidade com o principais servios da Amazon (EC2, EBS, AMI, S3 e IAM). Dessa forma a Eucalyptus ter o monitoramento, gerenciamento de servios de nuvem e gerenciamento de imagem totalmente providos pela AWS, alm de poder padronizar a aplicao e condies de uso ajudando a manter dados privados em seu prprio data center. Sendo assim, em relao ao critrio Situao Atual do Projeto, o Eucalyptus se destaca das demais solues.

65

5.6

QUADRO COMPARATIVO
Eucalyptus Xen, KVM VMware Amazon S3 Nagios e Ganglia Cloud Controller 2 projetos; 25 mil nuvens e OpenNebula Xen, KVM VMware LVM libvirt Redundncia 1 projeto; 4 mil cpias/ms e openQRM Xen, KVM, VMware e LinuxVServer LVM Nagios, Zabbix e collected Linux-HA 2 projetos; N/A OpenStack Xen, KVM, VMware, LXC, QEMU e UML XenCenter XenCenter Nova 1 projeto (3 servios); 3386 pesquisadores e 183 empresas

Critrios Hypervisors Suportados Backup Monitoramento Alta Disponibilidade Situao Atual do Projeto

Tabela 6: Quadro Comparativo das Solues

66

CONCLUSO

Este trabalho props uma anlise comparativa das principais solues de Computao em Nuvem. Dentre as solues avaliadas e de acordo com os critrios abordados, podemos destacar o OpenStack. Apresentando suporte a hypervisors diversicados, alm dos mais tradicionais, o OpenStack, atravs do XenCenter, garante o backup e o monitoramento de suas nuvens com estabilidade, j que a ferramenta integrada a soluo. O OpenStack tambm dispe de um processo de alta disponibilidade bastante ecaz, alm de contar com a NASA como contribuidora inicial do projeto e com outras grandes empresas como usurios atuais (Intel e AT&T).

6.1

TRABALHOS FUTUROS

Algumas possibilidades de trabalhos futuros esto relacionadas a incluso de outros critrios avaliativos, tais como: Gerncia e Alocao das Mquinas Virtuais (Provisionamento) Gerncia e Alocao de Recursos (Armazenamento, CPU, Memria e Rede) Realocao Dinmica de Recursos API

67

REFERNCIAS

COMPUTERWORLD. 11 categorias de cloud computing - Tecnologia - COMPUTERWORLD. 2010. ltimo acesso em 20 de maio de 2012. Disponvel em: <http://computerworld.uol.com.br/tecnologia/2010/03/03/11-categorias-de-cloudcomputing/>. EUCALYPTUS. Eucalyptus 3.0.2 Administration Guide. [S.l.], 2012. Disponvel em: <http://www.eucalyptus.com/eucalyptus-cloud/documentation>. EUCALYPTUS. Eucalyptus Architecture | Cloud Computing Software from Eucalyptus. 2012. ltimo acesso em 17 de junho de 2012. Disponvel em: <http://www.eucalyptus.com/eucalyptus-cloud/iaas/architecture>. EUCALYPTUS. The Eucalyptus Story. 2012. ltimo acesso em 17 de junho de 2012. Disponvel em: <http://www.eucalyptus.com/about/story>. IBM. Modelos de servio de computao em nuvem, Parte 1: Infraestrutura como servio. 2011. ltimo acesso em 23 de maio de 2012. Disponvel em: <http://www.ibm.com/developerworks/br/cloud/library/cl-cloudservices1iaas/>. IBM. Modelos de Servios de Computao em Nuvem, Parte 2: Plataforma como Servio. 2011. ltimo acesso em 23 de maio de 2012. Disponvel em: <http://www.ibm.com/developerworks/br/cloud/library/cl-cloudservices2paas/>. IBM. Modelos de Servios de Computao em Nuvem, Parte 3: Software como Servio. 2011. ltimo acesso em 23 de maio de 2012. Disponvel em: <http://www.ibm.com/developerworks/br/cloud/library/cl-cloudservices3saas/index.html>. MICROSOFT. Web Services. 2006. ltimo acesso em 23 de maio de 2012. Disponvel em: <http://msdn.microsoft.com/pt-br/library/cc564893.aspx>. OPENNEBULA. About the OpenNebula.org Project. 2012. ltimo acesso em 23 de junho de 2012. Disponvel em: <http://www.opennebula.org/about:about>. OPENNEBULA. OpenNebula: The Open Source Solution for Data Center Virtualization. 2012. ltimo acesso em 17 de junho de 2012. Disponvel em: <http://www.opennebula.org/>. OPENNEBULA. OpenNebula: The Open Source Solution for Data Center Virtualization. 2012. ltimo acesso em 24 de junho de 2012. Disponvel em: <http://opennebula.org/documentation:archives:rel1.4:libvirtapi>. OPENNEBULA. Setting up High Availability in OpenNebula with LVM. 2012. ltimo acesso em 21 de junho de 2012. Disponvel em: <http://blog.opennebula.org/?p=1523>.

68

OPENQRM. openQRM | Leading Open Source Data Center and Cloud Computing Plattform - Version Comparison. 2012. ltimo acesso em 26 de junho de 2012. Disponvel em: <http://www.openqrm-enterprise.com/about-openqrm/feature-comparison.html>. OPENQRM. openQRM | openQRM keeps your data center up and running. 2012. ltimo acesso em 24 de junho de 2012. Disponvel em: <http://www.openqrm.com/?q=node/42>. OPENSTACK. OpenStack Compute Starter Guide. [S.l.], 2012. Disponvel em: <http://docs.openstack.org/>. OPENSTACK. Releases - Wiki. 2012. ltimo acesso em 24 de junho de 2012. Disponvel em: <http://wiki.openstack.org/Releases>. RUSCHEL, H.; ZANOTTO, M. S.; MOTA, W. C. da. Computao em nuvem. p. 15, 2010. SLB. TI VERDE - TI Verde - Software Livre Brasil. 2009. ltimo acesso em 25 de maio de 2012. Disponvel em: <http://softwarelivre.org/ti-verde>. SOURCEFORGE. openQRM - Browse Files at SourceForge.net. 2012. ltimo acesso em 19 de junho de 2012. Disponvel em: <http://sourceforge.net/projects/openqrm/les/>. STACKOPS. StackOps. 2012. ltimo acesso em 25 de junho de 2012. Disponvel em: <http://www.stackops.com/>. TANENBAUM, A. S.; STEEN, M. V. Distributed Systems. Principles and Paradigms. 2a . ed. [S.l.: s.n.], 2006. 705 p. UFRJ. Computao em Nuvem. 2009. ltimo acesso em 20 de maio de 2012. Disponvel em: <http://www.gta.ufrj.br/ensino/eel879/trabalhos_vf_2009_2/seabra/arquitetura.html>. VERAS, M. Virtualizao - Componente Central do Datacenter. 1a . ed. [S.l.]: Brasport, 2011. 364 p. VERAS, M. Cloud Computing - Nova Arquitetura da TI. 1a . ed. [S.l.: s.n.], 2012. 240 p. WEB, I. Emerson Network Power separa fato de co em cloud computing - IT Web. 2012. ltimo acesso em 25 de maio de 2012. Disponvel em: <http://itweb.com.br/voceinforma/emerson-network-power-separa-fato-de-ccao-em-cloud-computing/>.