56
Anais
Implantação de Aplicações em Múltiplas Plataformas de Nuvem
Diego Souza1, Thiago Sena1, Everton Cavalcante1, Nélio Cacho1, Thais Batista1,
André Almeida1,2, Frederico Lopes3, Thomas Diniz3,
Flávia C. Delicato4, Paulo F. Pires4
1
2
DIMAp, Universidade Federal do Rio Grande do Norte (UFRN) – Natal, RN
Instituto Federal de Educação do Rio Grande do Norte (IFRN) – Parnamirim, RN
3
ECT, Universidade Federal do Rio Grande do Norte (UFRN) – Natal, RN
4
DCC/IM, Universidade Federal do Rio de Janeiro (UFRJ) – Rio de Janeiro, RJ
{diegodimap, lord.sena, evertonranielly, fred.lopes, thomasfdsdiniz,
fdelicato, paulo.f.pires}@gmail.com, [email protected],
[email protected], [email protected]
Resumo. Neste artigo descrevemos nossa experiência de implementação e
implantação de uma aplicação usando três plataformas de nuvem, com o
objetivo de analisar as similaridades e diferenças entre elas, bem como as
facilidades e dificuldades com relação à implantação de aplicações usando os
serviços providos por essas plataformas. Apresentamos também as lições
aprendidas de forma a orientar desenvolvedores e ajudá-los a minimizar ou
evitar possíveis problemas enfrentados ao implantar aplicações em nuvem.
Abstract. In this paper we describe our experience in implementing and
deploying an application using three cloud platforms, aiming to analyze the
similarities and differences between them, as well as the facilities and
difficulties regarding to the deployment of applications using services
provided by these platforms. Furthermore, we also present the lessons learned
in order to guide developers and aid them avoiding possible problems that
they may experience when deploying cloud applications.
1. Introdução
A Computação em Nuvem (Armbrust et al., 2009; Zhang et al., 2009; Wang et al. 2010; Mell e
Grance, 2011) é um paradigma que possibilita o acesso ubíquo e sob demanda a um conjunto de
recursos computacionais disponibilizados como serviços. Facilidades de armazenamento,
infraestrutura, plataformas e softwares são providos como serviços em ambientes de nuvem.
Atualmente há uma variedade de ambientes de nuvem disponíveis no mercado que dão
suporte ao desenvolvimento de aplicações. Amazon Web Services (AWS)1, Google App Engine
(GAE)2, Microsoft Azure Platform3 e OpenStack4 são alguns exemplos de ambientes de
desenvolvimento de aplicações em nuvem. Esses diferentes ambientes seguem diferentes tipos
de modelos de provisão de serviços e cada um fornece uma gama de serviços que se diferenciam
em diversos aspectos tais como preço, facilidade de uso e desempenho.
1
Amazon Web Services (AWS) – http://aws.amazon.com
Google App Engine (GAE) – http://code.google.com/appengine/
3
Microsoft Windows Azure – http://www.windowsazure.com/
4
OpenStack Cloud Software – http://openstack.org/
2
X Workshop em Clouds e Aplicações
Dado esse cenário de diversidade de ambientes de nuvem, um dos principais desafios
em termos de desenvolvimento de aplicações diz respeito à implementação, implantação e
migração de aplicações na nuvem, que são tarefas desafiadoras no sentido da maior
complexidade inerente à heterogeneidade desses ambientes (Galán et al. 2009; Sampaio et al.
2011). Tais ambientes não são implementados utilizando padrões comuns; cada um possui sua
própria API, ferramentas de desenvolvimento, mecanismos de virtualização, características de
governança, tecnologias de implantação e gerenciamento de recursos, etc. Consequentemente,
os usuários tendem a optar por implementar suas aplicações em um ambiente específico,
tornando-se altamente dependentes de um único provedor de nuvem, problema conhecido como
cloud lock-in (Armbrust et al. 2009), sendo impossibilitados de aproveitar as melhores
características de diferentes ambientes. Além disso, essa dependência implica que, em caso de
indisponibilidade de um serviço do ambiente, a aplicação não tem a flexibilidade de recorrer ao
serviço equivalente em outro ambiente.
De forma a endereçar esse problema, este artigo tem como objetivo mostrar aspectos de
implementação e implantação de uma aplicação usando três importantes ambientes de nuvem:
AWS, GAE e OpenStack. A finalidade é implantar tanto diferentes componentes da mesma
aplicação em diferentes nuvens, como também os mesmos componentes em diferentes nuvens.
Assim, podemos analisar as similaridades e diferenças existentes entre tais ambientes, bem
como analisar as facilidades e dificuldades para implantação de aplicações usando os serviços
providos por eles. Este artigo está estruturado da seguinte forma. A Seção 2 discute sobre
trabalhos relacionados. A Seção 3 apresenta o exemplo que será usado ao longo desse artigo e
os detalhes de implementação e implantação desse exemplo nos diferentes ambientes de nuvem
analisados. A Seção 4 discute sobre as lições aprendidas e ressalta vantagens e desvantagens de
cada ambiente. Por fim, a Seção 5 contém algumas considerações finais e são delineadas
direções para trabalhos futuros.
2. Trabalhos Relacionados
Existem vários trabalhos na literatura que descrevem experiências com uso de plataformas de
nuvens. Os trabalhos citados nesta seção apresentam as experiências de uso com base na
comparação entre várias plataformas utilizadas.
No trabalho de Peng et al. (2009) são utilizados fatores como escalabilidade, interface
Web, suporte a virtualização, confiabilidade, etc. para avaliar várias plataformas de nuvem
(AbiCloud, Eucalyptus, Nimbus e OpenNebula). Por sua vez, Cerbelaud et al. (2009)
apresentam as experiências de uso de quatro plataformas (ECP, Eycalyptus, OpenNebula e
oVirt) no tocante a gerenciamento de imagens (criação, atualização e armazenamento) e
instanciação de imagens (monitoramento, quotas, controle de usuário e gerencia de clusters).
Nessa mesma linha, Sempolinski e Thain (2010) descrevem as principais características de três
plataformas de nuvem (Eucalyptus, OpenNebula e Nimbus) e apresentam como tais
características podem representar problemas na utilização destas plataformas. Finalmente, Endo
et al. (2010) apresentam um conjunto de desafios de uso criados pela falta de padronização nas
interfaces fornecidas por sete plataformas de nuvem.
As experiências de uso descritas pelos trabalhos relacionados são baseadas em
elementos arquiteturais da infraestrutura de cada plataforma analisada, como, por exemplo, o
tipo de biblioteca de virtualização suportada por cada plataforma e como tal elemento influencia
nas aplicações implantadas. Por outro lado, nosso trabalho tem como foco relatar as mudanças
necessárias no código de uma aplicação Web para migrá-la de um ambiente de Nuvem para
outro. Tais relatos complementam os existentes na literatura, pois permitem antecipar para o
desenvolvedor quais problemas de implementação poderão ser encontrados quando uma mesma
aplicação for implantada em mais de uma plataforma de nuvem.
57
58
Anais
3. Utilizando Plataformas de Nuvem
Nesta seção utilizaremos um estudo de caso para analisar como é feita a implementação e a
implantação de funcionalidades de uma aplicação em três das principais plataformas de Nuvem
existentes: Amazon Web Services (AWS), Google App Engine (GAE) e OpenStack. Os nossos
objetivos são: (i) relatar como implementar e implantar aplicações para essas plataformas de
nuvem, e; (ii) ressaltar as vantagens e desvantagens de cada plataforma, bem como levantar as
dificuldades que surgiram para cada etapa. Para o estudo de caso, selecionamos o Health
Watcher (HW) (Soares et al., 2006), que se trata de uma aplicação Web para registro de queixas
e outras informações sobre problemas de saúde em uma cidade. Esta escolha foi motivada pelo
fato do HW ser uma aplicação real e bem documentada, tendo sido usada em diferentes
contextos. Analisando sua parte técnica, o HW possui requisitos encontrados em diversos
sistemas, como interface gráfica Web, persistência relacional, suporte à concorrência e uso de
tecnologias de implementação como Java Servlets, JDBC (Java Database Connectivity) e RMI
(Remote Method Invocation).
A Figura 1 mostra os módulos do HW que foram implantados utilizando os serviços de
nuvem providos por diferentes plataformas.
Figura 1: Módulos do HW e serviços de nuvens.
Para analisar os serviços providos por diferentes plataformas de Computação em
Nuvem, usamos alguns módulos do HW, como ilustra a Figura 1. Os módulos do HW e os
respectivos serviços de nuvens nos quais eles serão implementados são os seguintes:
•
Módulo Web: este módulo é responsável por apresentar a interface gráfica ao usuário,
composta por páginas HTML e formulários, que são exibidos através de um navegador
web. As requisições dos usuários são feitas através do módulo Web e os retornos dessas
requisições são apresentados aos usuários também pelo módulo Web. A implantação do
HW na nuvem é feita através da criação de instâncias com suporte a um servidor Web.
Usamos o Apache Tomcat como servidor Web para este estudo de caso. As requisições
do HW e seus resultados consomem processamento. Com a implantação do HW nas
plataformas de nuvem, objetivamos analisar os serviços de capacidade computacional
(Amazon EC2, GAE e OpenStack Compute).
•
Módulo de Persistência: este módulo é útil para analisarmos os serviços de
persistência, relacional ou não, das plataformas de nuvens.
•
Módulo de log: com este módulo podemos analisar os serviços de armazenamento de
informações simples (e.g. apenas texto) e também serviços de log em nuvem.
X Workshop em Clouds e Aplicações
•
Módulo de Autenticação: o HW possui um módulo de autenticação simples que não é
suficiente para testarmos os serviços de autenticação disponíveis nas plataformas de
nuvem. Dessa forma, foi necessário desenvolver um módulo de autenticação adicional
para este fim.
•
Módulo de Gerenciamento de Arquivos: originalmente o HW não possui um módulo
de gerenciamento de arquivos; porém, visando analisar este tipo de serviço das
plataformas de nuvem, nós o adicionamos ao HW. Assim, é possível associar uma
imagem a cada sintoma de uma doença cadastrada no HW e depois exibir esta imagem
durante uma consulta àquele sintoma.
Vale salientar que as plataformas AWS e OpenStack categorizam-se como IaaS
enquanto que o GAE é PaaS. Desta maneira, os objetivos desses provedores de nuvem diferem
um pouco entre si. O AWS e o OpenStack oferecem serviços na nuvem, já o GAE oferece uma
camada de middleware para execução de aplicações na nuvem. Todavia, o AWS e o OpenStack
também oferecem a possibilidade de se instalar um servidor web e um banco de dados,
possibilitando assim a implantação de uma aplicação. Já o GAE não provê um controle total das
instâncias, porém é possível implantar aplicações em Java ou Python de maneira simples. Para
este estudo de caso, desenvolvido utilizando-se a linguagem Java, as diferenças de objetivos de
IaaS e PaaS não influenciam muito, uma vez que os serviços utilizados são semelhantes:
servidor web, banco de dados, logging. gerenciamento de arquivos e autenticação.
A seguir, explicaremos cada serviço de nuvem que foi usado para este estudo de caso.
Também mostraremos os trechos de código responsáveis pelo acesso ao serviço.
Adicionalmente, o processo de implantação de cada módulo na nuvem será detalhado.
3.1. AWS
A plataforma Amazon Web Services (AWS) é amplamente utilizada por empresas de vários
tamanhos e domínios e provê serviços relacionados a capacidade de processamento, facilidades
de armazenamento, e várias outras funcionalidades que permitem que empresas façam a
implantação de suas aplicações e serviços a um custo baixo, de maneira flexível, escalável e
confiável. Entre tais serviços, podemos destacar: (i) Amazon EC2, que oferece recursos
computacionais elásticos através da criação de instâncias de máquinas virtuais para hospedar
aplicações; (ii) Amazon SimpleDB, que implementa um banco de dados não relacional; (iii)
Amazon S3, que permite o armazenamento de arquivos na nuvem, e (iv) Amazon RDS, que
permite a criação de instâncias de bancos de dados relacionais, como MySQL e Oracle.
3.1.1 Módulo Web
Para gerenciar as páginas Web e formulários do HW, optamos por usar o servidor Web Apache
Tomcat5 por ser open-source, rápido, leve e estar disponível no AWS. Ele já vem instalado em
instâncias pré-configuradas do Amazon Elastic Compute Cloud (EC2)6.
Uma aplicação Web, com extensão .war pode ser implantada em uma instância
Amazon EC2 com o Apache Tomcat instalado. Há duas maneiras de executar esta implantação.
A primeira é gerando o arquivo .war e executando o seu upload através do Amazon Elastic
Block Store (EBS)7. Com isso, uma instância é criada automaticamente no Amazon EC2 e a
aplicação é posta em execução em uma URL a ser fornecida pelo Amazon EBS. Essa operação
5
Apache Tomcat – http://tomcat.apache.com/
Amazon Elastic Compute Cloud (EC2) – http://aws.amazon.com/ec2/
7
Amazon Elastic Block Store (EBS) – http://aws.amazon.com/ebs/
6
59
60
Anais
pode ser feita usando o console de gerenciamento do AWS. A segunda maneira é utilizando o
plug-in do AWS para a IDE Eclipse.
3.1.2 Módulo de Persistência
O Amazon Relational Database Service (RDS)8 foi usado para realizar persistência de dados do
HW no AWS. Este serviço oferece suporte a banco de dados MySQL e Oracle. Para utilizar o
Amazon RDS, é necessário acessar o console do serviço e criar uma instância de banco de
dados. Para este estudo de caso, utilizamos o MySQL, versão 5.1.50. Em seguida, é necessário
fornecer autorização às máquinas que irão acessar este banco de dados, através do endereço IP
das mesmas. Em uma máquina autorizada, já é possível acessar o banco de dados através do seu
endpoint, que é um dos atributos do banco de dados no Amazon RDS. A porta para o MySQL é,
usualmente, a 3306. Nesse ponto fizemos o restore do banco de dados do HW no Amazon RDS.
O HW já possui toda a infraestrutura necessária à persistência relacional de dados. Para
direcionar todos os comandos SQL da aplicação para o banco de dados no Amazon RDS é
necessário colocar o endereço do endpoint do banco de dados da nuvem no caminho do Java
Database Connectivity (JDBC), conforme o trecho marcado na linha 32 da Figura 2.
Figura 2: Trecho da classe ConstantsHW para conexão com o Amazon RDS.
Figura 3: Trecho da classe LogMechanism com uso do Amazon SimpleDB
3.1.3 Módulo de Log
O HW possui um módulo de log que envia todas as informações relevantes para a classe
LogMechanism. O AWS não oferece um serviço de Log explícito, como o GAE, porém, oferece
um serviço de armazenamento de informações puramente textuais, chamado Amazon
SimpleDB9. Utilizamos este serviço para armazenar as informações de Log do HW. Para
realizar o armazenamento das informações de log do HW no SimpleDB, fizemos algumas
alterações na classe LogMechanism original. Todas as informações de log do HW são
redirecionadas para esta classe, que realiza o armazenamento das informações para futuras
auditorias. As alterações realizadas nesta classe são mostradas na Figura 3. Nessa figura, é
mostrado o método addLog, que recebe uma mensagem de log e seu respectivo nível de
importância. Na linha 80, uma lista para armazenar essas informações é criada. As linhas 97 a
102 adicionam informações a esta lista. Finalmente, na linha 103, essas informações são
enviadas ao Amazon SimpleDB, no endereço armazenado na variável domainSDB, definida na
classe ConstantsHW, que contém as definições de variáveis que são utilizadas ao longo de todo
o projeto HW.
8
9
Amazon Relational Database Service (RDS) – http://aws.amazon.com/rds/
Amazon SimpleDB – http://aws.amazon.com/simpledb/
X Workshop em Clouds e Aplicações
3.1.4 Módulo de Autenticação
O AWS possui um serviço de controle de acesso aos seus recursos e serviços, o AWS Identity
and Access Management (IAM), no endereço http://aws.amazon.com/iam/. Porém, para utilizálo seria necessário alterar de maneira considerável a arquitetura do HW. O HW originalmente
está preparado para realizar uma autenticação através de um banco de dados relacional. Para
realizar uma autenticação utilizando o IAM da Amazon seria necessário alterar toda a parte de
modelo, persistência, padrões de projeto e configurações relacionadas com a funcionalidade de
login. Por esse motivo, optamos por não analisar este serviço, uma vez que uma das restrições
do estudo de caso é não alterar a arquitetura já consolidada do HW.
3.1.5 Módulo de Gerenciamento de Arquivos
O módulo de gerenciamento de arquivos (GA) não existe no HW original. Este módulo foi
adicionado para analisarmos os serviços de GA das plataformas em nuvem. O suporte ao GA foi
feito sem mudanças significativas na arquitetura do HW. Adicionamos um campo no formulário
de cadastro de novos sintomas, no qual o usuário pode associar uma imagem a cada novo
sintoma. Cada imagem é armazenada com o código do sintoma mais a extensão .jpg.
Posteriormente, ao consultar uma doença, o usuário poderá visualizar os sintomas e suas
respectivas imagens.
No AWS, o serviço de gerenciamento de arquivos é o Amazon Simple Storage Service
(S3) . Para fazer o upload de uma imagem, é preciso criar um objeto PutObjectRequest.
Como pode ser visto na Figura 4, esse objeto recebe como parâmetros o nome do bucket (um
container para objetos armazenados no Amazon S3 que pode ser recuperado de maneira
unívoca através de uma chave de acesso), o nome com o qual a imagem será salva e o arquivo
que representa a imagem. Por questões de segurança, apenas o criador do arquivo no Amazon
S3 tem autorização para visualizá-lo. Para fornecer permissão para que qualquer pessoa possa
ver a imagem, é preciso executar a linha 79, que dá permissão para o público em geral. Por fim,
na linha 80, o objeto PutObjectRequest, no caso a imagem, é lançada no Amazon S3.
10
Figura 4: Classe InsertSymptom com upload de uma imagem para o Amazon S3
3.1.6. Implantação
A implantação da aplicação completa na nuvem requer alguns cuidados e configurações
adicionais. As formas de se implantar uma aplicação no AWS já foram mostradas nas subseções
anteriores. Veremos, a seguir, as interações que precisam ser configuradas para que haja
comunicação entre os módulos do HW. As interações entre módulos do HW que representam
comunicação entre serviços no AWS são: (1) módulos Web e Persistência utilizando Amazon
EC2 e Amazon RDS; (2) módulos Web e Gerenciamento de Arquivos utilizando Amazon EC2
e Amazon S3.
Para que a interface Web possa se comunicar com o banco de dados na nuvem, é
preciso que a aplicação implantada no Apache Tomcat em uma instância do Amazon EC2 possa
acessar o banco de dados do HW implantado no Amazon RDS. Para tal, é preciso configurar as
permissões de segurança no console do serviço, autorizando o acesso da instância ao banco de
dados. A comunicação da interface gráfica com o sistema de arquivos é necessária para que as
imagens das doenças possam ser mostradas dentro das páginas HTML. Isto não é trivial, já que
10
Amazon Simple Storage Service (S3) – https://console.aws.amazon.com/s3/
61
62
Anais
com a aplicação implantada na nuvem, o sistema de arquivos não é o que usamos normalmente,
visto que os arquivos estão em um local diferente do qual se encontram as páginas HTML.
Assim, é preciso fornecer permissão de visualização em cada arquivo para que a instância do
Amazon EC2 onde está implantado o HW possa exibir as imagens. Isso já é feito
automaticamente no código do HW ao fazer o upload de uma imagem para o Amazon S3,
conforme detalhado na seção 3.1.5.
3.2. GAE
O Google App Engine (GAE)11 prioriza o suporte a hospedagem de aplicações Web com suporte
nativo para Python e Java. A virtualização e elasticidade claramente observadas na plataforma
da Amazon são praticamente imperceptíveis no GAE. Isto ocorre porque todo o gerenciamento
de virtualização e a elasticidade são feitos de forma automática pelo GAE, de acordo com o
número de requisições recebidas por uma aplicação.
3.2.1 Módulo Web
O HW usa a API Java Servlet como um mecanismo de interação com o servidor web. Quando o
GAE recebe uma solicitação, ele determina qual classe de servlet deve ser chamada através de
um arquivo de configuração XML (web.xml) conhecido como descritor de implantação.
3.2.2 Módulo de Persistência
Para o mecanismo de persistência do HW, foi usada a API JDO (Java Data Object) para o
armazenamento de dados no GAE. Essa interface é oferecida pelo DataNucleus Access
Platform, uma implementação de código aberto de vários padrões de persistência Java, com um
adaptador para o armazenamento de dados do GAE. Essa plataforma de acesso requer um
arquivo de configuração chamado jdoconfig.xml, que especifica o armazenamento de dados
do GAE como o backend para a implementação do JDO.
Para criar classes JDO, utilizam-se anotações Java para descrever como as instâncias
devem ser armazenadas e como devem ser recriadas ao serem recuperadas do armazenamento
de dados. No trecho de código apresentado na Figura 5, referente à classe Employee (que
representa um funcionário que utiliza o HW), os campos privados da classe são anotados como
@Persistent para determinar que o DataNucleus os armazene como propriedades de objetos
no armazenamento de dados do Google App Engine. Cada entidade tem uma chave exclusiva
entre todas as entidades do GAE, e a chave de um objeto é armazenada em um campo da
instância; o campo de chave principal é identificado através do uso da anotação @PrimaryKey.
Figura 5. Anotações referentes à persistência da classe Employee.
Em termos de gerenciamento da persistência de dados, para cada solicitação que usa o
armazenamento de dados é requisitada a instância da classe PersistenceManager (já criada
com o uso do padrão singleton), como mostrado na linha 26 do trecho de código da classe
EmployeeRepositoryJDO apresentado na Figura 6. Para persistir o objeto de uma classe, é
invocado o método makePersistent sendo passado como parâmetro o referido objeto, como
mostrado na linha 30 da Figura 6.
11
Google App Engine (GAE) – https://appengine.google.com/
X Workshop em Clouds e Aplicações
Figura 6. Persistência da classe Employee via JDO usando makePersistent.
A classe javax.jdo.PersistenceManager, própria do JDO, utiliza uma instância
da classe PersistenceManagerFactory para persistir os dados na nuvem do Google. Com
isso, basta implantar a aplicação no GAE; se a aplicação for executada localmente, será criado
um arquivo binário simulando o serviço de dados BigTable do GAE na máquina local.
3.2.3 Módulo de Log
Para a implementação da funcionalidade de logging do HW no GAE, o primeiro passo foi
copiar o arquivo logging.properties, que contém informações sobre o sistema de logging
do GAE (basicamente nível default de erros), para o diretório WAR da aplicação e depois
definir uma propriedade no arquivo de configuração appengine-­‐web.xml, ativando assim o
serviço de log da Google. Feito isso, na classe LogMechanism, é chamado um método que
recebe como parâmetro um objeto que contém as informações de log do HW a serem
armazenadas. Com isso, informações importantes são persistidas no serviço de logging do GAE;
essas informações podem ser acessadas diretamente pelo navegador através do console de
gerenciamento do GAE.
3.2.1.4 Módulo de Autenticação
Considerando a possibilidade de permitir múltiplas formas de autenticação, utilizando contas de
infraestruturas de plataformas de nuvem, foi adicionada a autenticação utilizando um serviço
Google,
o
Authentication
and
Autorization
for
Google
App.
Os
mecanismos/protocolos/bibliotecas que o desenvolvedor pode utilizar para realizar as tarefas de
autenticação são: OAuth 2.0, OpenID e ClientLogin API.
Para submeter o pedido de autenticação é necessário formar uma URL e, através de um
pedido do tipo POST, enviar os parâmetros de autenticação. Para realizar esse procedimento, foi
utilizada a biblioteca HttpComponents da Apache, que é uma implementação Java dos
principais componentes do protocolo HTTP. Conforme disponibilizado na API ClientLogin a
URL que deve ser utilizada para enviar uma requisição POST seria
https://www.google.com/accounts/ClientLogin?.
Foi criada uma classe GoogleLogin onde é realizada a requisição POST à API
ClientLogin para autenticação de usuário. O método estático authenticate recebe como
parâmetros o login e a senha da conta que será autenticada. Primeiramente é criado um objeto
da classe DefaultHttpClient que representa um cliente HTTP e, em seguida, criado um
objeto da classe HttpPost que encapsula uma requisição do tipo POST, fornecendo como
parâmetro para o construtor o endereço HTTP da interface ClientLogin. Como estão sendo
enviados os dados de usuário e senha, para proteger os mesmos é necessário enviar esses dados
codificados, aumentando assim a segurança da requisição. Logo, o cliente HTTP envia a
requisição POST ao servidor, cuja resposta é encapsulada em um objeto da classe
HttpResponse. Conforme definido na API, se o processo de autenticação, representado pela
chamada ao método execute da classe DefaultHttpClient, retornar como resposta a string
“OK”, a autenticação foi realizada com sucesso e o método authenticate retorna o valor
true (verdadeiro); em caso contrário, houve falha na autenticação e o método retorna o valor
false (falso).
63
64
Anais
3.2.5 Módulo de Gerenciamento de Arquivos
O GAE provê um serviço chamado Blobstore, que permite o armazenamento de objetos de
dados de tamanho até 2 GB, objetos esses denominados blobs e que são exibidos como
respostas a manipuladores de solicitação. As aplicações não criam dados de blob diretamente;
em vez disso blobs são criados indiretamente, via formulário Web enviado por outra requisição
HTTP POST.
Para implementar esse serviço, seria necessário alterar de forma significativa a estrutura
do HW, removendo o padrão de projeto Adapter. Por esse motivo, o serviço de sistema de
arquivos utilizando Blobstore do GAE não foi incluído, pois uma das restrições do estudo de
caso é não alterar a arquitetura já consolidada do HW.
3.2.6. Implantação
Para fazer a implantação do HW no GAE, é necessário que a aplicação tenha um
registro de ID, fornecido quando se cria um aplicativo usando o Console de administração do
GAE. Depois de registrado o ID para o HW, este é enviado para o GAE usando o plug-in do
Eclipse ou uma ferramenta de linha de comando do SDK.
3.3. OpenStack
O OpenStack é um projeto mantido pela Rackspace e NASA com o objetivo de oferecer
soluções para todos os tipos de nuvem de maneira escalável e fácil de implementar. Produto de
uma comunidade global de desenvolvedores, o OpenStack oferece serviços de processamento
(OpenStack Compute), armazenamento de arquivos (OpenStack Storage) e imagem virtual
(OpenStack Image). Ele é utilizado por grandes empresas, como é o caso do MercadoLivre12.
Neste trabalho criamos uma nuvem privada usando o OpenStack e implantamos o HW para
analisar os serviços providos.
3.3.1 Módulo Web
O módulo Web do HW foi implantado na nuvem privada do OpenStack sem maiores alterações,
dado que sua API é baseada na do Amazon EC2. Porém, como será descrito em detalhes na
seção 3.3.6, foi necessário instalar o servidor Web Apache Tomcat e fazer configurações de
permissão de acesso para que fosse possível o acesso ao HW em execução na nuvem privada.
Foram configuradas também permissões em portas do sistema operacional Ubuntu relacionadas
com o Tomcat e com o MySQL.
3.3.2 Módulo de Persistência
O HW original já possuía um sistema de persistência relacional. Para utilizar este sistema na
nuvem privada, fizemos alterações nas configurações de banco de dados do HW e apontamos
para utilizar o MySQL instalado na nuvem. O acesso ao banco de dados é feito via JDBC e o
endereço do banco de dados é localhost, pois o banco é visto como local pelo HW, e a porta é a
3306. O procedimento de instalação do banco é descrito na seção 3.3.6.
3.3.3 Módulo de Log
O OpenStack não possui um serviço de log. Para que este módulo do HW pudesse ser testado
também nesta plataforma, criamos uma tabela no banco de dados e utilizamos o módulo de
persistência para armazenar as informações de log da aplicação, a saber, nível de importância,
12
Usuário do OpenStack – http://openstack.org/user-stories/mercadolibre-inc/
X Workshop em Clouds e Aplicações
mensagem e data/hora. Há também a possibilidade de se salvar o log em arquivo. Como o HW
está implantado na nuvem privada, seu acesso ao sistema de arquivos do sistema operacional é
similar ao acesso local. Todavia, é preciso dar as devidas permissões no diretório onde o HW
salvará os arquivos de log.
3.3.4 Módulo de Autenticação
O HW original possui um módulo de autenticação que utiliza o banco de dados relacional.
Como o OpenStack não oferece este serviço de autenticação, optamos por realizar a
autenticação utilizando o banco de dados instalado na nuvem privada. Assim, esse módulo não
fica comprometido e o HW pode ser executado completamente, já que algumas funcionalidades
exigem o login do usuário para serem acessadas.
3.3.5 Módulo de Gerenciamento de Arquivos
A nuvem privada que criamos oferece toda sua capacidade de armazenamento para as
aplicações a serem executadas nela. Assim, configuramos o HW para que as imagens enviadas
pelos usuários sejam armazenadas nos servidores que compõem a nuvem e fiquem à disposição
da aplicação para futura exibição quando consultadas.
3.3.6. Implantação
A nuvem OpenStack usada para hospedar o HW foi criada para a realização deste estudo de
caso. O sistema operacional é uma distribuição Linux, Ubuntu Server acompanhado de um
software de virtualização. Em uma visão estrutural, a abordagem adotada possibilita o uso de
diferentes arquiteturas para instalação da nuvem OpenStack, sendo todas elas compostas por três
componentes principais: um nó de controle, um de rede e um ou mais nós de processamentos.
Eles podem ser distribuídos em arquiteturas single, dual ou multinode de acordo com a
necessidade do usuário, tendo em vista que cada uma tem requisitos de hardware e software
específicos. Para a implantação do HW no OpenStack, por questões de simplicidade, foi
utilizada a arquitetura single node, onde todos os componentes OpenStack são instalados em
uma mesma máquina física.
Depois de feita a instalação de base, ou seja, o sistema operacional acompanhado do
software de suporte, foi realizado o deploy do OpenStack Nova de acordo com a arquitetura
escolhida. Em seguida foi necessário acessar o nó de controle e configurar as permissões de
acesso de usuário e rede. Tendo finalizado esses passos, a nuvem está pronta para receber as
instâncias de máquinas virtuais. Elas podem ser geradas diretamente no sistema, usando a
ferramenta Euca2ools ou ainda com auxilio de algum software com GUI, como por exemplo, o
Dashboard Horizon (que já é instalado durante o deploy do OpenStack Nova) ou com um plugin do Firefox chamado HibridFox. É importante ressaltar que para criar uma instância é
necessário ser um usuário da nuvem, logo para cada usuário é gerado um arquivo de permissão
com extensão .pem. Esse arquivo é usando exatamente na criação da instância da máquina
Virtualizada, servindo também de chave autenticadora para efetuar o login na máquina
instanciada. Este login pode ser feito via ssh, ou ainda através do Horizon, que disponibiliza
uma opção de acesso VNC. Com a instância ativa, foi necessário fazer a instalação do Apache
Tomcat e do MySQL na própria máquina virtual. Tendo realizado esses procedimentos, a
instância estava pronta para a implantação do HW.
Depois de configurada a nuvem do OpenStack, foi feita a restauração do banco de dados
do HW e o deploy da aplicação no Apache Tomcat. Configurações adicionais de permissão não
foram necessárias, pois a execução é similar a uma execução local. Porém, para acessar a
instância e fazer qualquer procedimento, é preciso utilizar ssh e passar o arquivo de permissão.
65
66
Anais
4. Discussão
Esta seção tem como objetivo discutir as facilidades e dificuldades de desenvolvimento e
implantação do estudo de caso nas três diferentes plataformas de nuvem supracitadas. Para cada
módulo do HW foram realizadas configurações distintas para cada ambiente de nuvem,
mostrando que há diferenças significativas no processo de implantação de uma aplicação para
cada ambiente.
Para a implantação do Módulo Web no AWS e OpenStack foi necessário apenas gerar
o arquivo .war e realizar a implantação na instância contendo o Apache Tomcat. Para o GAE,
foram feitas algumas alterações no projeto, como no arquivo web.xml. O
Módulo
de
Persistência foi o que apresentou maiores diferenças de uma nuvem para a outra. No AWS foi
necessário instanciar um banco de dados MySQL no Amazon RDS e configurar permissões de
acesso. Já no OpenStack foi necessário apenas instalar o MySQL na instância e usar como se
fosse um banco de dados local, dadas as permissões necessárias de acesso via rede. Já para usar
o BigTable do GAE, foi necessário anotar todas as classes relacionadas com a persistência de
dados para que o JDO pudesse persistir os dados no banco em questão. Para que o Módulo de
Log do HW armazenasse as informações de log no GAE foi necessário apenas alterar uma
configuração no arquivo logging.properties e adicionar uma linha de código na classe
LogMechanism. Como escolhemos utilizar o Amazon SimpleDB para armazenar essas
informações no AWS, foram necessárias algumas alterações de código nas classes
ConstantsHW e LogMechanism. Já para salvar o log do HW no OpenStack, nós fizemos uma
ligação com o Módulo de Persistência e salvamos os dados em uma tabela do banco de dados. O
Módulo de Autenticação foi criado no HW e testado no GAE utilizando o Authentication and
Autorization for Google App. A classe GoogleLogin foi criada para realizar a autenticação e
algumas alterações foram feitas em outras classes do HW relacionadas com o login. Já para o
AWS e OpenStack, foi utilizado o login convencional do HW, que utiliza o banco de dados para
realizar a autenticação. O Módulo de Gerenciamento de Arquivos foi testado no AWS
utilizando o Amazon S3. Algumas alterações foram feitas na classe InsertSymptom, para que
as imagens dos sintomas fossem armazenadas no referido serviço. No OpenStack os arquivos
foram armazenados no sistema de arquivos local, como se o HW fosse executado localmente.
Não usamos o serviço BlobStore do GAE porque para usá-lo seria necessário alterar a
arquitetura do HW.
Os valores a serem pagos variam para cada plataforma de nuvem. Como nós
implantamos uma nuvem privada utilizando o OpenStack, podemos considerar que o custo
monetário para executar os serviços nessa nuvem foi zero, mas houve necessidade de se
remunerar um administrador responsável por configurar a plataforma e seus serviços.. Já para
executar o HW durante 90 dias no AWS, com uma média de mil requisições por dia, seria
necessário pagar um total de R$ 295,86 e apenas R$ 101,52 no GAE (considerando a
extrapolação da cota gratuita que essas plataformas proveem). Uma combinação de execução
com diferentes módulos em diferentes nuvens também é possível, resultando em variações
nestes preços entre zero, quando todos são executados no OpenStack, e R$ 295,86, quanto todos
são executados no AWS durante o mesmo período de tempo.
Sobre o esforço para a realização deste estudo de caso, podemos dizer que o OpenStack
foi o mais trabalhoso por ter exigido a criação da nuvem privada, instalação do software
necessário e configuração da rede e das permissões. As dificuldades encontradas incluem: (i) o
funcionamento de alguns softwares que se deu de maneira diferente da esperada, o que foi
corrigido com o uso de uma versão mais recente; (ii) a nuvem ter se mostrado um pouco
instável em situações nas quais o servidor ficou sem conexão a rede, de modo que quando a
conexão era reestabelecida, os serviços do OpenStack ficavam inativos, e; (iii) o problema de
falta de sincronização entre componentes da nuvem, o que foi contornado sincronizando a
X Workshop em Clouds e Aplicações
67
nuvem privada com algum servidor externo. O esforço para utilizar o GAE e o AWS pode ser
resumido ao aprendizado da API de acesso aos serviços, além do pagamento das taxas devidas.
Um resumo sobre os passos necessários para se implantar cada módulo do HW e o
preço de implantação são resumidos na Tabela 1. As células em negrito representam em que
plataforma o quesito analisado é mais vantajoso. A última linha da tabela apresenta o preço final
para cada plataforma.
Tabela 1 – Visão Geral das Plataformas de Nuvem
Quesito/Plataforma
AWS
Módulo Web
-Uso de credenciais
-Uso de plugin do Eclipse. Deploy console do EBS.
Módulo de Persistência
-Permissão para desenvolver
-Permissão para acessar
Módulo de Log
-Serviço SimpleDB.
-Simples e barato
-Aprender API
Módulo
Autenticação
Módulo de
Arquivos
Implantação
Preço
de
G.
de
-Banco de dados do HW
-Serviço S3.
-Confiável e barato
-API simples.
-A implantação simples. Deploy pelo console do
EBS.
R$295,86/90 dias
GAE
-Configuração de
arquivos -Estrutura
de projeto prédefinida
-Uso de JDO
-Anotação
nos
modelos
-Configurar
jdoconfig.xml
-Serviço de Log do
GAE –Configurar
logging.properties
e
appengineweb.xml.
-Serviço
de
autenticação
do
GAE .
-Criar uma classe
para acessar o
serviço
OpenStack
-Implantação similar à local.
Conexão com o banco é feita
através de JDBC como para
um banco local.
Foi utilizado o banco de dados
do HW para armazenar as
informações de Log.
-Banco de dados do HW
-Não foi feito no
GAE
-Uso do
privada
HD
da
nuvem
-Plugin do Eclipse.
-Criação e configuração da
nuvem.
R$101,52/90 dias.
R$0,00/90 dias.
5. Conclusão
Neste artigo apresentamos as principais experiências adquiridas ao se implantar uma mesma
aplicação em três plataformas de nuvem. Estas experiências permitem orientar desenvolvedores
sobre possíveis problemas que os mesmos podem enfrentar ao se implantar aplicações nas
nuvens. Entre as orientações, destacamos os cuidados com o uso de alguns serviços, como
autenticação, persistência, log e armazenamento de arquivos. Além destas contribuições, o
artigo também discutiu e demonstrou que, em termos de nuvem pública, a implantação do HW
no GAE demandou menos recursos financeiros em comparação com o serviço fornecido pela
Amazon. Apesar da implantação dos módulos do HW no OpenStack ter custo zero, dado que foi
criada uma nuvem privada, foi preciso reservar um servidor apenas para esta finalidade e alocar
uma máquina para hospedar a plataforma. Como resultado, houve uma elevação nos custos de
utilização da nuvem privada. Porém, a criação da nuvem privada nos permitiu analisar também
o processo de criação desse tipo de provedor de serviço, aumentando nossa visão de apenas
usuários de serviços de nuvem para também de provedores de serviço de nuvem. Como
trabalhos futuros, pretendemos avaliar, através de diferentes técnicas de teste, fatores adicionais
que influenciam na implantação de uma aplicação nas nuvens. Pretendemos também avaliar
através da definição e execução de um benchmark qual a relação custo/desempenho de utilizar
uma mesma aplicação em várias plataformas de nuvem. Além da realização de testes e análise
da execução de um benchmark, pretendemos fazer uma análise do tráfego de dados dentro da
nuvem através do uso de softwares como o Lattice (Clayman et al. 2010). Este software também
68
Anais
poderá ser utilizado para analisarmos o tráfego de dados entre diferentes nuvens, quando a
aplicação tiver módulos implantados em nuvens distintas. Nosso objetivo com esses novos
trabalhos é coletar informações para que os módulos de uma aplicação sejam implantados em
nuvens que apresentem melhores características como preço, disponibilidade, desempenho,
dentre outras.
Agradecimentos
Esse trabalho foi desenvolvido no contexto do projeto AltoStratus, financiado pelo CTIC/RNP
(Rede Nacional de Pesquisa). Thiago Sena e Nélio Cacho são parcialmente apoiados pelo
projeto FAPERN PPP-III-013/ 2009. Nélio Cacho é parcialmente apoiado pelo Instituto
Nacional de Engenharia de Software (INES), financiado pelo CNPq 573964/2008-4.
Referências
Armbrust, M. et al. (2009) Above the clouds: A Berkeley view of Cloud Computing – Technical report.
Reliable Adaptive Distributed Systems Laboratory, University of California at Berkeley, USA.
Cerbelaud, D. et al. (2009) “Opening the clouds: Qualitative overview of the state-of-the-art open source
VM-based cloud management platforms”. Proc. of the 10th ACM/IFIP/USENIX Int. Conf. on
Middleware (Middleware’09). New York, NY, USA: Springer-Verlag, pp.1-8.
Clayman, S et al (2010) “Monitoring Service Clouds in the Future Internet. Towards the Future Internet Emerging Trends from European Research. (pp. 115 - 126). IOS Press: Amsterdam, The Netherlands.
Endo, P. et al. (2010) “A survey on open-source Cloud Computing solutions”. Anais do VIII Workshop
em Clouds, Grids e Aplicações (WCGA 2010). Porto Alegre, RS: SBC, pp. 3–16.
Galán, F. et al. (2009) “Service specification in cloud environments based on extensions to open
standards”. Proc. of the Fourth Int. ICST Conf. on Communication System Software and Middleware
(COMSWARE 2009). New York, NY, USA: ACM.
Greenwood, Phil et al. (2007) “On the impact of aspectual decompositions on design stability: An
empirical study”. Proc. of the 21st European Conf. on Object-Oriented Programming (ECOOP2007).
LNCS, 4609. Springer, pp.176–200.
Mell, P.; Grance, T. (2011) The NIST Definition of Cloud Computing – NIST Special Publication,
Reports on Computer Systems Technology. National Institute of Standards and Technology,
Gaithersburg, MD, USA.
Peng, J. et al. (2009) “Comparison of several Cloud Computing platforms”. Proc. of the Second Int.
Symposium on Information Science and Engineering (ISISE 2009). Piscataway, NJ, USA: IEEE
Computer Society, pp. 23-27.
Rittinghouse, J.; Randsome, J. (2010) Cloud Computing: Implementation, management and security.
Boca Raton, FL, USA: CRC Press.
Sempolinski, P; Thain, D. (2010) “A Comparison and critique of Eucalyptus, OpenNebula and Nimbus”.
Proc. of the IEEE Second Int, Conference on Cloud Computing Technology and Science (CloudCom
2010). Piscatway, NJ, USA: IEEE Computer Society, pp. 417–426.
Soares, Sérgio; Borba, Paulo; Laureano, Eduardo (2006) “Distribution and persistence as aspects”.
Software – Practice & Experience 36(7), pp.711–759.
Wang, L. et al. (2010) “Cloud Computing: A perspective study”. New Generation Computing 28(2), pp.
137–146.
Zhang, Q. et al. (2010) “Cloud Computing: State-of-the-art and research challenges”. Journal of Internet
Services and Applications 1(1), pp. 7–18.
Download

WCGA 2012-CameraReady