UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
ENSAIO DE INFRAESTRUTURA DE COMPUTAÇÃO EM NUVEM
PARA HOSPEDAGEM DE SERVIÇOS MANTIDOS PELO
LABORATÓRIO DE REDES DE COMPUTADORES DA UNIVALI –
CAMPUS ITAJAÍ
por
Samuel Chaves Euzébio
Itajaí (SC), Junho de 2014
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
ENSAIO DE INFRAESTRUTURA DE COMPUTAÇÃO EM NUVEM
PARA HOSPEDAGEM DE SERVIÇOS MANTIDOS PELO
LABORATÓRIO DE REDES DE COMPUTADORES DA UNIVALI –
CAMPUS ITAJAÍ
Área de Redes de Computadores
por
Samuel Chaves Euzébio
Relatório apresentado à Banca Examinadora
do Trabalho Técnico-científico de Conclusão
do Curso de Ciência da Computação para
análise e aprovação.
Orientador: Fabricio Bortoluzzi, M. Sc.
Itajaí (SC), Junho de 2014.
RESUMO
EUZÉBIO, Samuel Chaves. Ensaio de Infraestrutura de Computação em Nuvem para
hospedagem de serviços mantidos pelo Laboratório de Redes de Computadores da
UNIVALI – Campus Itajaí. Itajaí, 2012. No54. Trabalho Técnico-científico de Conclusão de
Curso (Graduação em Ciência da Computação) – Centro de Ciências Tecnológicas da Terra e
do Mar, Universidade do Vale do Itajaí, Itajaí, 2012.
O Laboratório de Redes de Computadores da UNIVALI – Campus Itajaí hospeda e gerencia
servidores físicos para diversas finalidades de pesquisa. Cada computador é preparado
individualmente e as aplicações hospedadas neles estão confinadas nas limitações do
hardware. Este TTC é sobre a criação de uma infraestrutura de nuvem para o Laboratório de
Redes de Computadores da UNIVALI – Campus Itajaí, de modo que as atuais e futuras
aplicações sejam hospedadas em um ambiente adequadamente escalável.
Palavras-chave: Computação em nuvem. Nuvem Privada. Infraestrutura como Serviço
(IaaS).
ABSTRACT
Currently the Laboratory of Computer Networks UNIVALI - Itajaí College hosts and manages
physical servers for various research purposes. Each computer is prepared individually and
applications hosted on them are confined within its hardware limitations. This paper is about
create a cloud infrastructure for the Laboratory of Computer Networks UNIVALI - College
Itajaí, so that current and future applications to be hosted in a scalable environment properly.
Keywords: Cloud Computing. Private cloud. Infrastructure-as-a-Service (IaaS).
LISTA DE FIGURAS
Figura 1 Ambiente Físico e ambiente virtualizado................................................................... 20
Figura 2 Virtualização Completa. ............................................................................................. 21
Figura 3 Virtualização de Sistema Operacional. ...................................................................... 22
Figura 4 Virtualização KVM. ................................................................................................... 24
Figura 5 Virtualização VMware ESX Server. .......................................................................... 26
Figura 6 Virtualização Xen....................................................................................................... 27
Figura 7 Virtualização KVM. ................................................................................................... 28
Figura 8 Visão do usuário sobre o cluster. ............................................................................... 30
Figura 9 Arquitetura computação em grid. .............................................................................. 34
Figura 10 Pesquisa Cisco .......................................................................................................... 36
Figura 11 Arquitetura computação em nuvem. ........................................................................ 39
Figura 12 Organização da Infraestrutura em nuvem proposta. ................................................ 52
Figura 13 Tela de Login da Nuvem Openstack. ....................................................................... 56
Figura 14 Administração dos Projetos de Nuvem. ................................................................... 57
Figura 15 Membros Projetos Nuvem. ...................................................................................... 57
Figura 16 Templates de Imagens de Sistemas Operacionais. ................................................... 58
Figura 17 Criação de Volumes. ................................................................................................ 61
Figura 18 Volumes Disponíveis. .............................................................................................. 61
Figura 19 Template Flavors (Sabores) Disponíveis. ................................................................ 62
Figura 20 Topologia da rede da nuvem implementada. ........................................................... 65
Figura 21 Redes disponíveis na nuvem. ................................................................................... 66
Figura 22 Acesso à nuvem via smartphone. ............................................................................. 67
Figura 23Visão Global dos recursos computacionais da nuvem. ............................................. 68
LISTA DE ABREVIATURAS E SIGLAS
API
EC2
IAAS
KVM
LBaaS
NIST
PV
QOS
SAAS
TTC
UNIVALI
VM
VMM
Application programming interface
Elastic Compute Cloud(Amazon)
Infraestrutura como serviço
Kernel Virtual Machine
(Load Balance-as-a-Service) Balanceador de carga como serviço.
National Institute of Standards and Technology, Instituto Nacional
dos Estados Unidos de Padrões e Tecnologias.
Paravirtualização
Quality of Service
Software como serviço
Trabalho Técnico-científico de Conclusão de Curso
Universidade do Vale do Itajaí
Virtual Machine
Virtual Machine Monitor
SUMÁRIO
1
INTRODUÇÃO ............................................................................................................... 15
1.1 PROBLEMATIZAÇÃO ............................................................................. 15
1.1.1 Formulação do Problema ....................................................................... 15
1.1.2 Solução Proposta ..................................................................................... 16
1.2 OBJETIVOS ................................................................................................ 16
1.2.1 Objetivo Geral ......................................................................................... 16
1.2.2 Objetivos Específicos .............................................................................. 17
1.3 METODOLOGIA........................................................................................ 17
1.4 ESTRUTURA DO TRABALHO ............................................................... 18
2 FUNDAMENTAÇÃO TEÓRICA ...................................................................................... 19
2.1 VIRTUALIZAÇÃO ..................................................................................... 19
2.1.1 Virtualização Completa .......................................................................... 21
2.1.2 Virtualização de Sistema Operacional .................................................. 22
2.1.3 Paravirtualização .................................................................................... 23
2.1.4 Características e Vantagens da Virtualização ..................................... 25
2.1.5 VMware ESX Server .............................................................................. 26
2.1.6 Xen ............................................................................................................ 27
2.1.7 KVM ......................................................................................................... 28
2.2 CLUSTER ..................................................................................................... 29
2.2.1 Características e vantagens de um cluster............................................ 30
2.3 COMPUTAÇÃO EM GRID ....................................................................... 31
2.3.1 Características da computação em grid ................................................ 32
2.3.2 Tipos de computação em grid ................................................................ 33
2.3.3 Arquitetura da computação em grid ..................................................... 34
2.4 COMPUTAÇÃO EM NUVEM .................................................................. 35
2.4.1 Definição .................................................................................................. 36
2.4.2 Serviço Sob demanda ou Auto-Serviço (On-demand or self–service). 37
2.4.3 Acesso amplo à rede (Broad network Access) ....................................... 37
2.4.4 Agrupamento de Recursos (Resource pooling) .................................... 38
2.4.5 Elasticidade rápida ou Escalabilidade (Rapid elasticity) ..................... 38
2.4.6 Mensurabilidade (Measured Service) .................................................... 39
2.4.7 Software-as-a-Service (SaaS) .................................................................. 40
2.4.8 Platform-as-a-Service (PaaS) .................................................................. 43
2.4.9 Infrastructure-as-a-Service (IaaS) .......................................................... 44
2.4.10 Private Cloud ........................................................................................... 46
2.4.11 Community Cloud ................................................................................... 47
2.4.12 Public Cloud ............................................................................................ 47
2.4.13 Hybrid Cloud ........................................................................................... 48
3 DESENVOLVIMENTO ...................................................................................................... 49
3.1 SERVIÇO SOB DEMANDA OU AUTO-SERVIÇO NA
INFRAESTRUTURA DE NUVEM APLICADA .......................................... 55
3.2 ACESSO AMPLO À REDE NA INFRAESTRUTURA DE NUVEM
APLICADA ........................................................................................................ 66
3.3 AGRUPAMENTO DE RECURSOS NA INFRAESTRUTURA DE
NUVEM APLICADA ........................................................................................ 67
3.4 ELASTICIDADE RÁPIDA OU ESCALABILIDADE NA
INFRAESTRUTURA DE NUVEM APLICADA .......................................... 68
3.5 MENSURABILIDADE NA INFRAESTRUTURA DE NUVEM
APLICADA ........................................................................................................ 71
4
CONCLUSÕES ............................................................................................................... 75
15
1 INTRODUÇÃO
Atualmente o Laboratório de Redes de Computadores da UNIVALI – Campus Itajaí
hospeda e gerencia servidores físicos para diversas finalidades de pesquisa. Cada computador
é preparado individualmente e as aplicações hospedadas neles estão confinadas nas limitações
do hardware fornecido pelo cliente interno proprietário do servidor.
O desprendimento das características de hardware de cada servidor seria mais
vantajoso para acomodar cada sistema dentro de suas reais necessidades, independentemente
do hardware hospedeiro. Ao invés de individualismo entre os servidores, tanto de disposições
de hardware quanto processamento individual específico, a nuvem pode fornecer um
hardware abstrato, sobre medida para cada necessidade de hospedagem de sistemas.
Uma vez que este desejo por manutenabilidade e escalabilidade é mais bem alcançado
por meio do conceito de nuvem este TTC analisa a criação de uma infraestrutura de nuvem
para o Laboratório de Redes de Computadores da UNIVALI – Campus Itajaí, de modo que as
atuais e futuras aplicações sejam hospedadas em um ambiente adequadamente escalável.
Espera-se maior facilidade de manutenção uma vez que não se está mais preso a
características de hardware individualizado e nem software ou sistema operacional e com
maior capacidade e aproveitamento do pequeno poder computacional disponível.
1.1 PROBLEMATIZAÇÃO
1.1.1 Formulação do Problema
O Laboratório de Redes de Computadores da UNIVALI – Campus Itajaí possui hoje
uma infraestrutura que foi projetada sem a preocupação de ser um ambiente escalável. O
gerenciamento da infraestrutura como um todo, é descentralizado, demandando maior tempo
para alocação dos recursos computacionais. A infraestrutura atual está atrelada a servidores
físicos. Quando necessárias modificações ou configurações novas tem-se pouca flexibilidade,
pois cada computador é preparado individualmente, e suas aplicações hospedadas estão
dependentes da configuração de sistemas operacionais com o hardware físico.
16
1.1.2 Solução Proposta
A proposta deste TTC é a criação de uma infraestrutura de nuvem para o Laboratório
de Redes de Computadores da UNIVALI – Campus Itajaí, de modo que as atuais e futuras
aplicações sejam hospedadas em um ambiente adequadamente escalável. Formando um
ambiente mais flexível, uma vez que os servidores não estariam mais presos a características
de hardware individualizado e nem software ou sistema operacional.
Com o desprendimento das características de hardware, fica mais viável acomodar
cada sistema dentro de suas reais necessidades, independentemente do hardware hospedeiro.
Ao invés de individualismo entre os servidores, tanto de disposições de hardware quanto
processamento individual específico, a nuvem fornece um hardware abstrato, sob medida para
a necessidade de cada sistema de pesquisa.
Espera-se que a manutenção dos servidores fique mais gerenciável e flexível. Haverá a
possibilidade de instanciação de novas infraestruturas virtualizadas em tempo imediato e sob
demanda sempre que alguma oportunidade de pesquisa surgir, sem a necessidade de algum
tipo de espera relacionada com a compra ou preparo de novos servidores como etapa de prérequisito durante o desenvolvimento destes projetos.
1.2 OBJETIVOS
Este trabalho está dividido em um objetivo geral e cinco objetivos específicos.
1.2.1 Objetivo Geral
O objetivo deste TTC é implantar o modelo de nuvem privada na infraestrutura de
hospedagem de servidores do Laboratório de Redes de Computadores da UNIVALI –
Campus Itajaí.
17
1.2.2 Objetivos Específicos
1. Revisar a bibliografia em busca das metodologias disponíveis para a criação de
infraestruturas de computação em nuvem.
2. Projetar uma infraestrutura de nuvem adequada para as necessidades de
hospedagem do Laboratório de Redes de Computadores da UNIVALI –
Campus Itajaí.
3. Implantar o modelo de nuvem projetado.
4. Aferir a aderência da nuvem implementada em comparação as propriedades de
autosserviço, acesso amplo à rede, agrupamento de recursos, elasticidade e
mensuração dos recursos alocados. Estas propriedades são descritas na
documentação de Definição de Computação em Nuvem do NIST.
5. Documentar e divulgar este TTC.
1.3 Metodologia
Para que os objetivos deste projeto fossem alcançados, Decidiu-se pela realização de
um levantamento bibliográfico sobre os conceitos de virtualização, que serviu para identificar
a base de uma infraestrutura de computação em nuvem. Também se fez necessário um estudo
sobre cluster e computação em grid, que estão entre as tecnologias básicas para se entender o
comportamento de um ambiente em computação em nuvem.
Um estudo sobre o cenário atual da computação em nuvem, suas definições
juntamente alinhados aos modelos de serviço, evidenciou a necessidade de atualização para
um novo modelo de infraestrutura.
O estudo realizado sobre como adequar os recursos computacionais em formandos
serviços, alinhados juntamente com os modelos de infraestrutura de nuvem, teve papel
fundamental para que fosse desenvolvido o projeto da infraestrutura de nuvem.
18
1.4 Estrutura do trabalho
Esta pesquisa foi dividida em três partes: Introdução, Fundamentação Teórica e
Desenvolvimento. Na Introdução foram abordados brevemente os conceitos de computação
em nuvem, para elucidação das características vantajosas em manter uma infraestrutura de
computação em nuvem.
A Fundamentação Teórica brevemente conceitua três tecnologias, virtualização,
cluster, computação em grid. Essas são tecnologias bases para computação em nuvem. Em
seguida, são expostas características essenciais para compor uma nuvem e seus modelos de
serviço. Os tipos de ambientes de computação em nuvem, juntamente amostrados com
algumas das ferramentas existentes para implementar um ambiente de computação em nuvem.
O capitulo final, refere-se ao desenvolvimento, onde é demonstrada a plataforma de
nuvem escolhida levando em consideração os conceitos abordados e revisados nos capítulos
anteriores. É feito o relato sobre a funcionalidade da virtualização, que fornece e compõe a
base para infraestrutura de nuvem. Também é abordada a disposição da nuvem,
a
organização e o modelo de serviços e quais serviços foram utilizados para compor a nuvem,
uma vez que a tecnologia da plataforma de nuvem escolhida é disposta em módulos. Estes
módulos são configuráveis separadamente para que o usuário final possa servir-se de recursos
computacionais sob demanda. e ainda são responsa abstraem o detalhamento da configuração
da nuvem . A partir do ambiente de nuvem implementados foi feita sua aferição de aderência,
comparando a infraestrutura de nuvem com as propriedades de autosserviço, acesso amplo à
rede, agrupamento de recursos, elasticidade e mensuração dos recursos alocados, definidos na
documentação The NIST Definition of Cloud Computing (NIST Special Publication 800-145).
19
2 FUNDAMENTAÇÃO TEÓRICA
2.1 Virtualização
A virtualização tornou-se comum a área de T.I e imperceptível aos usuários finais ao
longo dos anos (DEDLEY, H., 2009). Com o avanço das estruturas de hardwares, servidores,
com mais capacidade de processamento, armazenamento, surgiu a necessidade de uma melhor
administração para o melhor aproveitamento. A tecnologia de virtualização avançou trazendo
maiores recursos e benefícios para área de T.I, capacitando melhor administrar e distribuir os
recursos avançados da computação. Ela permite que em um mesmo computador físico, possa
tornar-se dinâmico virtualmente hospedando outros computadores virtuais.
A virtualização consiste em uma camada virtual, que faz a abstração entre o hardware
e sistemas operacionais heterogêneos, para que os sistemas operacionais possam ser
executados isoladamente, em uma mesma máquina física. Dado um determinado conjunto de
hardwares cria-se uma camada de software, a qual é chamada de hipervisor, ou também
conhecido como Virtual Machine Monitor (VMM), que possibilita gerenciar e criar máquinas
virtuais (VM). Cada VM, criada pode ter seu sistema operacional independente, alocando
dinamicamente recursos, como memória, processador e espaço em disco. Esta VM fica
restrita somente pela capacidade pelo hardware abstraído pelo hipervisor (SINGHT, Amit,
2004).
20
Figura 1 Ambiente Físico e ambiente virtualizado.
Fonte: THOLETI, Bhanu P, 2011.
Conforme demonstrado na Figura 1, o cenário (a), não está virtualizado, portanto para
hospedar dois sistemas operacionais distintos, são necessários dois computadores distintos. O
cenário (b) demonstra a aplicação da virtualização, que torna possível a aplicação de dois
sistemas operacionais distintos em um mesmo computador (THOLETI, Bhanu P, 2011).
Há diversas formas de virtualização, entre elas:

Virtualização completa;

Virtualização de Sistema Operacional;

Paravirtualização.
21
2.1.1 Virtualização Completa
Segundo King, Samuel T. et al 2003, a virtualização completa ocorre quando o
hipervisor é implementado diretamente sobre o hardware. A partir deste, obtém-se hardware
virtualizado para um ou mais sistemas operacionais que irão ser executados. A separação dos
sistemas operacionais heterogêneos acontece através da criação de máquinas virtuais sobre
este hipervisor.
O principal benefício da virtualização completa é que o sistema operacional da
máquina virtualizada não sofre qualquer tipo de alteração. Em compensação, o sistema
virtualizado executa mais lentamente e hipervisor precisa implementar alternativas para que
as operações privilegiadas possam ser executadas em processadores que não suportem a
virtualização nativamente. Além destas alternativas, cabe ao hipervisor realizar a tradução,
por exemplo, do endereçamento de memória virtual para memória do hardware físico
(THOLETI, Bhanu P, 2011).
Figura 2 Virtualização Completa.
Fonte:THOLETI, Bhanu P, 2011.
Conforme ilustrado na Figura 2, a primeira camada de baixo para cima é a camada de
hardware. Esta camada fornece os recursos computacionais como, processador, memória e
espaço em disco, que vão ser virtualizados pela camada do hipervisor. A camada do
hipervisor, o hospedeiro, vai administrar e alocar os recursos entre as máquinas virtuais
22
hospedeiras. O que torna possível que cada máquina virtual (VM) seja capaz de executar
individualmente seu sistema operacional e aplicações específicas.
2.1.2 Virtualização de Sistema Operacional
Semelhante a virtualização completa, porem com o diferencial de que o hipervisor ser
aplicado sobre um sistema operacional que já consolidou os recursos de hardware.
(THOLETI, Bhanu P, 2011).
Figura 3 Virtualização de Sistema Operacional.
Fonte:THOLETI, Bhanu P, 2011.
Conforme demonstrado na Figura 3, semelhante ao modelo anterior, a camada de
hardware fornece os recursos computacionais que serão consolidados pela camada do Sistema
Operacional base. A camada do hipervisor, o hospedeiro, vai administrar e alocar os recursos
disponibilizados pelo sistema operacional base, entre as máquinas virtuais hospedeiras. O que
torna possível que cada máquina virtual hospede esteja apta a executar individualmente seu
sistema operacional e aplicações especificas.
23
2.1.3 Paravirtualização
Paravirtualização (PV) é uma técnica de virtualização que apresenta uma interface de
software para as máquinas virtuais. É semelhante ao primeiro modelo, de virtualização
completa, porém na paravirtualização, o sistema a ser virtualizado (sistema convidado) sofre
modificações para que a interação com hipervisor seja mais eficiente (THOLETI, Bhanu P,
2011).
Esta técnica foi proposta a fim de melhorar o tempo que o sistema operacional
convidado gasta na execução de operações que são mais difíceis de executar em um ambiente
virtual em relação a um ambiente não virtualizado (THOLETI, Bhanu P, 2011).
Embora exija que o sistema a ser virtualizado precise ser modificado, é está alteração
que permite que o sistema convidado consiga acessar recursos do hardware diretamente,
evitando desgaste da tradução que ocorre, por exemplo, no modelo de virtualização completa.
Porem está alteração diminui a portabilidade de todo sistema virtualizado. O acesso é
monitorado pelo hipervisor, que fornece ao sistema convidado todos os “limites” do sistema,
tais como endereços de memória que podem ser utilizados (LAUREANO, Mauro, 2006).
A paravirtualização reduz a complexidade do desenvolvimento das máquinas virtuais,
já que, historicamente, os processadores não suportam a virtualização nativa. O desempenho
obtido é a principal razão para utilizar a paravirtualização, o que compensa as modificações
que serão implementadas nos sistemas convidados (LAUREANO, Mauro, 2006).
Arquitetonicamente, a PV funciona através da abertura de canais adicionais de
comunicação entre o hipervisor e o sistema operacional das máquinas virtuais hospedes
(COELHO, Fabio et al, 2008).
24
Figura 4 Virtualização KVM.
Fonte:COELHO Fabio et al, 2008.
Conforme demonstrado na Figura 4, é importante salientar que os domínios são as
máquinas virtuais criadas a partir do hipervisor. Estas podem ser de dois tipos, privilegiadas
(domínio 0) e não privilegiadas (domínio U). O hipervisor é o responsável por controlar os
recursos de comunicação, de memória e de processamento das máquinas virtuais, mas não
possui os drivers para manipular os dispositivos diretamente (COELHO, Fabio et al, 2008).
Quando a máquina virtual hospedada é iniciada, esta pertencente ao domínio U, uma
máquina virtual do domínio 0, é criada. O que está presente no domínio 0, acessa uma
interface de controle. As máquinas virtuais dos domínios U só podem ser criadas, iniciadas e
desligadas através do domínio 0. Na máquina virtual do domínio 0 é executado um sistema
operacional com núcleo modificado, que pode acessar os recursos da máquina física, ou seja
privilégios de acesso. Permite também a comunicação com as máquinas virtuais do domínio
U (COELHO, Fabio et al, 2008).
O sistema operacional do domínio 0 tem que ser modificado para possuir os drivers
de dispositivo da máquina física(hardware) e que tratam, por exemplo,das requisições de
acessos à rede, espaço de disco, que são realizadas pelas máquinas virtuais do domínio U
(COELHO, Fabio et al, 2008).
25
2.1.4 Características e Vantagens da Virtualização
A virtualização é formalizada de acordo com as seguintes características: (RUEST, N.,
RUEST, D., 2009) e (SINGHT, Amit, 2004).
Diminuir a quantidade de servidores físicos, ou seja, ter um servidor físico com uma
boa estrutura de hardware. A partir deste, utilizar a virtualização para melhor aproveitar o uso
do hardware, através da criação de máquinas virtuais. Isso reduz principalmente custos de
energia com refrigeração e administração da infraestrutura.
A capacidade de heterogeneidade de sistemas operacionais em um mesmo servidor,
não sendo mais necessária a aquisição de um novo computador físico para executar diferentes
sistemas operacionais. A separação dos sistemas operacionais heterogêneos ocorre criando
máquinas virtuais para cada um deles.
Melhora na manutenção da infraestrutura, proporcionando maior mobilidade e
migração, já que pode ser feito via software, sem interferência de hardware e sem
preocupação de configuração no novo hardware. Outro atributo ligado a esta característica é a
viabilidade do balanceamento de carga, onde é possível mover uma máquina virtual que está
em um hardware físico sobrecarregado para um novo ocioso. Essa capacidade é conhecida
como live migration. Isso repercute também em backup e restauração com maior facilidade e
gerenciamento. Como cada máquina virtual é uma entidade independente das demais, a
administração das diversas instancias é simplificada e centralizada.
Compatibilidade do software: A máquina virtual fornece uma abstração compatível, de
modo que todo o software escrito para ela funcione. Por exemplo, em uma máquina virtual
com um sistema operacional de alto nível funcionarão os programas escritos na linguagem
de alto nível. A abstração da máquina virtual frequentemente pode mascarar diferenças nas
camadas do hardware e do software abaixo da máquina virtual (LAUREANO, Mauro, 2006).
Inspeção, o hipervisor tem acesso e controle sobre todas as informações do estado da
máquina virtual, como estado da CPU, conteúdo de memória, eventos entre outros.
(LAUREANO, Mauro, 2006)
A
virtualização
fornece
benefícios
exclusivos
para
construir
arquiteturas
dinamicamente escaláveis. A nova natureza dinâmica da virtualização e as novas capacidades
que ela fornece, são necessários novos esquemas de gerenciamento, em um nível superior,
26
fornecendo uma orquestração geral do ambiente virtual, em outras palavras, principio de um
ambiente de computação em nuvem.
Hypervisors possuem várias implementações com diferentes características e formas
de virtualização, três deles são (THOLETI, Bhanu P, 2011):

VMware ESX Server;

Xen;

KVM.
2.1.5 VMware ESX Server
O VMware ESX Server adota a primeira forma de virtualização conhecida como
completa, uma plataforma corporativa. A arquitetura dele é demonstrada conforme Figura 5.
Figura 5 Virtualização VMware ESX Server.
Fonte: THOLETI, Bhanu P, 2011.
Conforme Figura 5, a primeira camada na parte inferior, que representa o hardware, os
recursos computacionais que podem ser virtualizados. Em seguida na camada superior tem-se
a camada do hipervisor. Fazendo uma das conexões com a camada das máquinas virtuais
implementadas com o hipervisor ESX, existe o serviço de console que controla a instalação,
27
configuração, administração, solução de problemas e manutenção do ESX Server. O console
de serviço reside na sua própria máquina virtual (THOLETI, Bhanu P, 2011).
2.1.6 Xen
O Xen, outro modelo de hipervisor que segue a forma de virtualização completa e
também em algumas de suas distribuições, segue a forma de paravirtualização. Xen é uma
ferramenta de código aberto e está licenciado sob a GNU General Public License (GPL2). A
arquitetura do Xen é moldada conforme Figura 6.
Figura 6 Virtualização Xen.
Fonte: THOLETI, Bhanu P, 2011.
Conforme demonstrado na Figura 6, a primeira camada base refere-se aos recursos
computacionais, que são extraídos do hardware. Em seguida vem a camada do hipervisor
Xen, que abstrai e administra os recursos, servindo como base para as máquinas virtuais.
A fim de continuar servindo suporte a paravirtualização, mas agora oferecer também
virtualização completa, o Xen dividiu os domínios U entre para-virtualizados (domínios UPV) e virtualizados (domínios U-HVM). Os domínios U-PV sabem que não tem acesso direto
ao hardware e por isso precisam de drivers específicos para acesso à rede e ao disco
(COELHO, Fabio et al, 2008).
28
Os domínios U-HVM (HVM, hardwarer virtual machine), por não serem
modificados, iniciam tentando executar a BIOS. O Xen virtual firmware é um componente
que simula uma BIOS com todos os procedimentos normais de um boot. Depois, um Qemu
(Emulador de Processador) associado a uma U-HVM emula o hardware para que a máquina
virtual possa usar o disco e a rede (COELHO, Fabio et al, 2008).
2.1.7 KVM
O Kernel virtual machine (KVM), utiliza o modelo de drivers paravirtualizados. Na
Figura 7 é demonstrada a arquitetura KVM.
Figura 7 Virtualização KVM.
Fonte:THOLETI, Bhanu P, 2011.
Conforme demonstrado na Figura 7, a primeira a camada é a de hardware base, em
seguida na camada superior encontra-se o hipervisor KVM. Na arquitetura KVM a máquina
virtual é implementada como um sistema operacional Linux com seu escalonamento padrão.
Isso permite se beneficiar de todas as funcionalidades do kernel do Linux, que também serve
para manter a conexão com as demais máquinas virtuais (THOLETI, Bhanu P, 2011).
29
O modelo KVM herda recursos de gerenciamento de memória do Linux, como por
exemplo, suporte a NUMA (Non-Uniform Memory Access, memória para multiprocessadores)
permitindo que as máquinas virtuais possam acessar eficientemente grandes quantidades de
memória (THOLETI, Bhanu P, 2011).
Compartilhamento de página de memória é suportado através de um recurso chamado
Kernel SamePage Merging (KSM). O KSM analisa a disposição de memória nas máquinas
virtuais classificando-as por páginas de memória idênticas. Quando encontrada a igualdade, o
KSM agrupa o endereçamento em uma única página, compartilhada entre as máquinas
virtuais. Possibilitando armazenar apenas uma única cópia da pagina memória. Se um cliente
tenta mudar esta página compartilhada, será dada a sua própria cópia privada. (THOLETI,
Bhanu P, 2011)
A abordagem que a KVM tem é a de tornar um kernel Linux um hipervisor,
simplesmente carregando um módulo do kernel. Este módulo exporta um dispositivo
chamado /dev/kvm. Com este dispositivo, uma VM tem seu próprio espaço de endereço
separado do espaço do kernel ou de qualquer outra VM em execução. Dispositivos na árvore
(/dev) são comuns a todos os processos de espaço do usuário, porém o dispositivo KVM é
diferente pelo fato de que cada processo que o utiliza, acessa um mapa diferente (para
oferecer suporte ao isolamento das VMs). Com o kernel atuando como um hipervisor é
possível então iniciar outros sistemas operacionais, como outro kernel Linux ou Windows
(TIM JONES, M., 2007).
2.2 Cluster
Cluster surge como uma tecnologia decorrente a necessidade de alto processamento de
dados para diversas áreas do ramo cientifico, pesquisas dentre tantas outras. Um cluster é o
trabalho mutuo entre dois, ou mais computadores interconectados (nós escravos) via rede,
resultando para o usuário como se fosse um único computador, que atendem suas requisições.
Clusters são formados pelo nó controlador, onde seu sistema operacional é replicado aos nós
escravos formando assim conceitualmente um único computador com sistema operacional
homogêneo e expansível (PITANGA, Marcos, 2003).
30
Figura 8 Visão do usuário sobre o cluster.
Fonte: O Autor(2012).
A Figura 8 demonstra a visão do usuário final sobre o a tecnologia de cluster. O
usuário acessa um único computador que abstrai os demais nós do cluster.
Segundo PITANGA, Marcos (2003), pesquisadores, organizações e empresas estão
utilizando os clusters porque necessitam incrementar a sua escalabilidade, gerenciamento de
recursos, disponibilidade ou processamento a nível supercomputacional a um preço
disponível.
2.2.1 Características e vantagens de um cluster
Clusters têm como vantagem aumento rápido da carga de poder computacional. O
aumento é feito com a adição de um nó escravo ao cluster, sendo assim, consegue-se a baixo
custo manter um nível supercomputacional (BACELLAR, Hilário ,2010).
São conhecidos como sistemas tolerantes a falhas (failover), por proporcionar uma alta
disponibilidade. Por exemplo, um dos nós escravo falhando não prejudicará o cluster inteiro,
pois a solução será somente trocar aquele nó escravo. Essa troca é feita sem indisponibilizar o
cluster. A viabilidade desta troca ocorre devido ao software de monitoramento, conhecido
como heart-beat. (BACELLAR, Hilário, 2010).
31
Outro modelo de cluster conhecido como de alto desempenho ou balanceamento de
carga, permite que tarefas que exigem uma maior capacidade de processamento sejam
realizadas distintamente em nós escravos de maior capacidade ou ociosos (BACELLAR,
Hilário, 2010).
É necessário que para tratar este balanceamento de carga, o sistema tenha rotinas
preparadas para paralelização distribuídas, geralmente no modelo de threads. Em servidores
web, por exemplo, este controle permite que nós escravos administrem requisições e caso
ocorra uma falha em um nó, os demais ativos são reorganizados para que atendam as tarefas
(PITANGA, Marcos, 2003).
2.3 Computação em Grid
O termo computação em grid foi criado por Ian Foster e Carl Kesselmans em 1990.
Era uma metáfora para encaminhar a solução de um problema grave na época: o acesso
múltiplo e simultâneo a diferentes recursos de processamento, de armazenamento e de
programas. (GANDOUR, Fábio L, 2010)
Computação em grid é um modelo de infraestrutura computacional, que organiza
computadores em uma grade de rede, aumentando assim sua capacidade de processamento,
dividindo as tarefas entre os computadores que compõe o grid. Esta rede pode ser local ou
uma rede de longa distância. Os grids removem as conexões que atrelam aplicações,
servidores, bases de dados, máquinas, armazenamento, entre outros, tratando tudo como um
serviço virtualizado. Assim, os recursos computacionais podem estar em um mesmo ambiente
ou alocados em diferentes locais, geograficamente distantes. (FOSTER, Ian et al,2001)
Com a interface de usuário autenticado, acessar o sistema de computação em grid não
seria diferente de acessar os recursos de uma máquina local. Qualquer computador autorizado
tem acesso a um enorme poder de processamento e capacidade de armazenamento. Uma vez
dentro do grid computacional, o poder de processamento, a memória e armazenamento de
dados, são recursos distribuídos que usuários autorizados podem explora-los para execução de
tarefas. Para o usuário individual, é como se o seu computador tivesse se transformado em um
supercomputador. (STRICKLAND, Jonathan, 2009)
Dentre as diferenças entre as tecnologias de cluster e grid, pode-se citar que o cluster
possui um controlador central, onde é possível utilizar todo o processamento do cluster. Os
32
nós de um cluster encontram-se geograficamente na mesma rede local. Os grids por sua vez
são uma arquitetura mais democrática onde embora possa existir um controle centralizado,
existe também ambientes onde empresas, universidades e grupos de usuários, compartilham
os ciclos ociosos de processamento em seus sistemas em troca da utilização da parte do tempo
de processamento do grid. Por exemplo, duas empresas sediadas em países com fusos-horário
diferentes formam um grid, de modo que uma possa utilizar os ciclos de processamento
ociosos da outra em seus horários de pico. Com o fuso horário diferente, os picos de acessos
aos servidores de cada empresa ocorrerão em horários diferentes. (PITANGA, Marcos, 2003)
2.3.1 Características da computação em grid
As características da computação em grid segundo Heinz Stockinger(2007) são:

Colaboração:
compartilhamento
de
recursos
entre
os
computadores
pertencentes a rede distribuída que compõe o grid.

Agregação: oferece aos usuários, ou computador pertencente ao grid, a
capacidade de processamento virtual somada, através de todos os
individualmente compartilhados.

Virtualização: apresentação dos serviços grid via uma interface simples,
abstraído os detalhes e regras complexas da sua arquitetura.

Heterogeneidade: composição por recursos computacionais heterogêneos, tais
como hardware, sistemas operacionais e software diferente, possuindo
desempenho diferente.

Controle descentralizado: um único usuário, ou computador pertencente ao
grid, não proprietário de todo o sistema. Mas cada nó pode solicitar a todo
sistema o compartilhamento de processamento ao quebrar uma tarefa recebida.

Interoperabilidade: é necessário um padrão entre sistemas para construção do
grid, para que haja comunicação entre os nós e processamento mutuo.

Segurança: um único usuário, ou computador pertencente ao grid, já autorizado
tem um limitado tipo de operações que pode correr nos serviços da Grid. O
aproveitamento de protocolos e normas é essencial para que os sistemas em
33
grid possam realizar funções fundamentais como autenticação, autorização,
descobrimento de recursos compartilhados.
2.3.2 Tipos de computação em grid
Segundo Heinz Stockinger (2007), alguns tipos de grids são diferenciados conforme
sua organização:

Enterprise Grids: são formados dentro de um ambiente corporativo, entre sua
própria rede. A limitação com grids externos e acessos externos é feito através
de um firewall, assim os recursos ficam protegidos e compartilhados dentro da
organização corporativa. Fisicamente descentralizado, mas virtualmente
centralizado, uma vez que todos dentro da corporação vão ter acesso a toda
informação. Enterprise grids são conhecidos também como Intragrid.

Partner Grids: são grids interligados entre organizações de áreas de interesse e
pesquisa em comum. Por exemplo, empresas no ramo químico de farmácias,
compartilham meios para atingir um objetivo em comum. Partner grids são
também chamados de Extragrid.

Service Grids: são sistemas abertos que possibilitam acesso independentemente
de qual grids eles pertencem. A partir desse sistema em comum, usuários
podem aproveitar os recursos computacionais sem saber onde estão
localizados, ou a que empresa pertencem, apenas pagam conforme uso.
Conceito de Sofware-as-a-Service(SaaS) aplicado na computação em nuvem.
34
2.3.3 Arquitetura da computação em grid
A organização de um modelo de grid é explicada na Figura 9 através de camadas.
Figura 9 Arquitetura computação em grid.
Fonte: Dantas, M.A.R, 2004.
Na camada base, tem-se a camada de redes, onde ocorre a conectividade para os
recursos do grid. Assim, podemos imaginar os switches, roteadores e a infraestrutura das
redes de comunicação (Dantas, M.A.R, 2004).
Em seguida a camada de recursos, desta camada fazem parte servidores primários e
dispositivos de armazenamento. Exemplos de configurações que representam ao nível de
recursos são os clusters, os serviços de armazenamento e computadores especiais tais como os
supercomputadores (Dantas, M.A.R, 2004).
A próxima camada é o middleware que fornece protocolos, e bibliotecas, permitindo
que múltiplos elementos heterogêneos (servidores, ambientes de armazenamento, redes e
outros elementos), participem de um ambiente de grid unificado. Para que a dos elementos
heterogêneos ocorra eles são padronizados em software e domínio com base no middleware
comunição Exemplos de heterogeneidade são os diferentes sistemas operacionais, sistemas de
arquivos e protocolos de comunicação entre redes (Dantas, M.A.R, 2004).
Por fim a camada de aplicação e serviços, que é onde ficam os conjuntos de
ferramentas de desenvolvimento. Milhares de aplicações diferentes compõem este nível. A
porção de serviço deve prover diversas funções de gerenciamento, métricas utilizáveis, todos
os parâmetros para o uso virtual dos recursos compartilhados entre diferentes usuários ou
computadores participantes do grid (Dantas, M.A.R, 2004).
35
2.4 Computação em Nuvem
A computação em nuvem emergiu como o sucessor natural de diferentes vertentes de
sistemas distribuídos, virtualização, cluster e computação em Grid. Agregando características
e benefícios destas tecnologias antes exploradas separadamente. Como uma plataforma
inovadora, a computação em nuvem está fazendo com que governos e grandes empresas e
corporações adotarem, cederem aos benefícios de sistemas distribuídos com renovado
interesse (UDDOH, Emmanuel, 2011).
Em termos evolutivos, a computação em nuvem anuncia a terceira onda de Tecnologia
da Informação. Esta frente da computação em nuvem faz com que recursos computacionais
tais como plataforma (PaaS), infraestrutura (IaaS), software (SaaS) sejam fornecidos como
um serviço através da rede local, ou internet. Os usuários são cobrados com base no seu uso
de recursos computacionais, como por exemplo, pelo serviço de armazenamento de dados.
Com este novo modelo de adoção de tecnologia em informação, o governo dos EUA registrou
um forte interesse no desenvolvimento da tecnologia de computação em nuvem para a
melhoria da economia. Com um plano estratégico já desenvolvido chamado de Federal Cloud
Computing Strategy (2011) pretende fazer a alteração da sua infraestrutura tradicional para
uma nova alocada em computação em nuvem (UDDOH, Emmanuel, 2011).
A computação em nuvem proporciona infraestrutura de serviços para empresas,
corporações, instituições de ensino, pesquisas e órgãos governamentais. Um dos fatores que
proporcionou este crescimento foi o anuncio de grandes empresas de tecnologia adotarem o
modelo de cloud computing, entre elas o Google e IBM (Vouk, M. A., 2008).
Em recente pesquisa da Cisco (2010), 27% das companhias no Brasil já utilizam
aplicações baseadas em cloud computing, enquanto que a média mundial é de 18%. A
pesquisa foi realizada em 13 países, entre eles Brasil, EUA, México, Reino Unido, Alemanha,
Índia, China e Japão.
A pesquisa também resultou que um em cada três profissionais de TI migrarão mais da
metade de seus dados e aplicativos para nuvens privadas nos próximos três anos. A previsão
da adoção de computação em nuvem é mais alta no México (71%), quanto que no Brasil
(53%) e EUA (46%) (Cisco, 2010).
36
Figura 10 Pesquisa Cisco
Fonte:Cisco (2010).
Conforme Figura10, em pesquisa da Cisco (2010), as respostas de “Sim,vão
implementar” e “Sim, já está em planejamento” ocupam 58% da pesquisa. Isso demonstra
que a TI está migrando do modelo tradicional de infraestrutura e partindo para um ambiente
de computação em nuvem.
2.4.1 Definição
Computação em nuvem é segundo Weiss, (2007) é a agregação de poderosos serviços,
aplicativos, recursos computacionais sendo integrados e disponibilizados na internet.
Para o MELL, Peter; GRANCE, Timothy (2011), computação nas nuvens é um novo
modelo computacional que permite a onipresença ao usuário, decorrente de acesso sob
demanda a recursos computacionais configuráveis, tais como, redes de computadores,
servidores, armazenamento, aplicativos e demais recursos que possam ser entregues como
serviço. Estes serviços são liberados e fornecidos com o mínimo esforço para gerenciamento,
ou interação de quem está comprando com quem está prestando o serviço.
37
Segundo Gandour, Fábio L. (2008) Cloud Computing é uma abordagem emergente na
infraestrutura de TI compartilhada, na qual os recursos de sistemas estarão conectados para
prestar serviços.
A computação em nuvem resume-se em um serviço de provisionamento de recursos de
computação, como por exemplo, processamento e armazenamento. Com base em um serviço,
entrega-se capacidade adicional, para que seja possível escalar dinamicamente o serviço em
computadores e efetuar armazenamento de forma simples e transparente (Jones, M.
Tim,2008). Para implementar uma nuvem e usufruir dos seus benefícios é necessário
contemplar algumas características.
Conforme definição do MELL, Peter; GRANCE, Timothy (2011), dentre as
características essenciais, ou imprescindíveis para computação em nuvem estão classificadas
cinco: serviço sob demanda, acesso à rede ampla, agrupamento (do inglês, pool) de recursos,
escalabilidade e serviço medido.
2.4.2 Serviço Sob demanda ou Auto-Serviço (On-demand or self–service)
Como serviço sob demanda o consumidor pode provisionar recursos computacionais,
armazenamento em rede. Automatizadamente conforme necessário sem intervenção humana
com o prestador do serviço (MELL, Peter; GRANCE, Timothy, 2011).
Ao invés de despejar capital para manter uma infraestrutura em alto nível para atender
a alta carga de processamento computacional que ocorre esporadicamente, utiliza-se recursos
sob demanda (on-demand). Recursos sob demanda são alocados conforme solicitado e
necessário (FURHT, Borko, 2010).
2.4.3 Acesso amplo à rede (Broad network Access)
Recursos estão disponíveis através da rede, são acessados através de mecanismos
padrões, meio padrão, que permite o uso de plataformas heterogêneas como, por exemplo,
telefones celulares, tablets, notebooks e estações de trabalho (MELL, Peter; GRANCE,
Timothy, 2011).
O acesso ao serviço contratado da nuvem não fica preso a uma linguagem de
programação, ou ao sistema operacional especifico. O recurso computacional fica
38
transparente para o usuário final, tornando-o independente do uso de uma plataforma
especifica. (MELL, Peter; GRANCE, Timothy, 2011).
2.4.4 Agrupamento de Recursos (Resource pooling)
Os recursos de computacionais são organizados em pool (agrupados) para atender
vários consumidores usando um modelo multi-tenant. Este modelo por sua vez permite que os
mais diversos recursos computacionais, sejam compartilhados entre os consumidores, com
diferentes recursos físicos e virtuais dinamicamente atribuídos de acordo com a demanda do
consumidor. Há um senso de localização independente, centralizado, unificado, cujo cliente
geralmente não tem controle ou conhecimento sobre a exata localização dos recursos
oferecidos, mas pode ser capaz de especificar localização a um nível superior de abstração.
Exemplos de recursos incluem o armazenamento, processamento, memória e largura de banda
de rede. (MELL, Peter; GRANCE, Timothy, 2011)
2.4.5 Elasticidade rápida ou Escalabilidade (Rapid elasticity)
Elasticidade rápida ou Escalabilidade. Capacidade de controle de recursos
computacionais pode ser elasticamente provisionada, ou seja, aumentada ou reduzida,
rapidamente conforme necessidade, a liberação de mais recursos ocorre de maneira
transparente. Em alguns casos isso ocorre automaticamente, para escalar rapidamente
proporcional exterior e interior com a demanda. Para o consumidor final, as capacidades
disponíveis para provisionamento parecem ser ilimitadas, podem ser adequadas em qualquer
quantidade a qualquer momento (MELL, Peter; GRANCE, Timothy, 2011)
A tecnologia chave que possibilita esta escalabilidade é a virtualização. Permite
melhor uso de um servidor, agregando vários sistemas operacionais e aplicativos em um único
computador compartilhado. A virtualização também permite a migração on-line de modo que,
se um servidor que é sobrecarregado, pode ser migrado para um servidor novo, já que ambos
são de disposição virtual, não estão mais atrelados a uma disposição física especifica.
(JONES, Tim M, 2008)
A escalabilidade permite que a sobrecarga de um servidor, ou um sistema possa ser
tratado na camada de infraestrutura, a IaaS. Por exemplo, tem-se um servidor que está
sobrecarregado. É possível então formar uma instancia deste servidor, tornando-o uma
39
imagem virtual. Com a imagem definida, é possível criar novas máquinas, novas instancias do
servidor sobrecarregado dentro da nuvem, duplicando-a. Então executar o processamento
paralelamente. Durante o processamento, é possível incluir e remover recursos de forma
manual ou automática, tornando-se assim um modelo baseado em cluster (Orlando,Dan
2011).
2.4.6 Mensurabilidade (Measured Service)
Conforme os recursos computacionais (por exemplo, processamento, armazenamento,
largura de banda e contas de usuários ativos) são provisionados como serviço, e conforme são
tratados separadamente é possível ter um controle e medição sobre cada um, o que acaba
sendo uma base para alavanca-los assim que necessário. Contudo controle do uso de recursos
pode ser monitorado e relatado, proporcionando transparência para o provedor e consumidor
do serviço utilizado (MELL, Peter; GRANCE, Timothy, 2011).
Uma nuvem não possui somente um serviço, mas um conjunto deles. A divisão em
três camadas proporciona uma melhor organização, onde cada camada torna-se um serviço
disponibilizado em nuvem. A Figura 11, demostra a organização em camadas.
Figura 11 Arquitetura computação em nuvem.
Fonte: AMRHEIN, Dustin; SCOTT, Quint, 2009.
40
2.4.7 Software-as-a-Service (SaaS)
Software-as-a-Service (SaaS) é a camada que fica na parte superior a camada final que
aproveita-se dos recursos das camadas inferiores,Paas e Iaas, para manter-se.Coforme MELL;
GRANCE, (2011),Saas é capacidade fornecida ao consumidor, de ter aplicativos em execução
em uma infraestrutura de nuvem.Com as aplicações estando na nuvem, ficam acessíveis a
partir de vários dispositivos de cliente. Podendo ser acessados por de interface de programas
smartclients, ou pelo próprio navegador de internet, e-mail baseado no conceito web, ou
softwares específicos que tenham a especialização de conexão com a nuvem. O consumidor
não precisa administrar ou controlar a infraestrutura de nuvem, incluindo rede, servidores,
sistemas operacionais, armazenamento ou mesmo capacidades individuais de aplicação.
Abstratamente o consumidor somente se conectará ao seu aplicativo, software que está na
nuvem. O consumidor estará restrito somente à pré-configuração de limitação da nuvem,
como por exemplo, espaço de disco que será pré-definido, mas conforme a necessidade
apareça pode ser aumentado.
Também pode relacionar a SaaS ao modelo de software de implementação de um
sistema centralizado para execução em um computador local (ou remotamente a partir da
nuvem). Como um serviço fornecido regularmente, a SaaS permite o controle e medição de
um aplicativo e pagamento somente pelo tempo utilizado.
Os aplicativos fornecidos através do modelo SaaS beneficiam consumidores aliviandoos da instalação e manutenção de software e podem ser usados através de modelos de
licenciamento que suportam pagamento para conceitos de uso (AMRHEIN, Dustin; SCOTT,
Quint, 2009).
SaaS é a capacidade de acessar softwares como um serviço. Uma abordagem anterior à
SaaS era o Provedor de Serviços de Aplicativos,Active Server Pages (ASP). Os ASPs
fornecem assinaturas ao software que são hospedados ou enviados pela Internet. Dessa
maneira, você não adquire o software, simplesmente faz uso de acordo com suas
necessidades. Todo acesso que acontece é controlado, como por exemplo, o tempo de
utilização, conforme o tempo de uso terá uma cobraça relativa sobre, definida pelo provedor
do serviço (JONES, Tim M, 2008).
Outra perspectiva da SaaS é a utilização do software pela Internet que é executado
remotamente. Esse software na forma de serviço é utilizado por um aplicativo local (definido
41
como serviços da Web) ou um aplicativo remoto observado por um navegador da Web
(JONES, Tim M, 2008).
Um exemplo de serviço de aplicativo remoto é o Google Apps, que fornece vários
aplicativos corporativos por meio de um navegador da Web padrão (Google Apps, 2012).
Como por exemplo: editor de texto, editor de planilha, editor de apresentações, entre outros.
Um servidor de aplicativos é uma estrutura de software que expõe APIs para serviços
de software (como gerenciamento de transações ou acesso ao banco de dados). Exemplos
incluem o Red Hat JBoss Application Server, Apache Geronimo e o IBM WebSphere
Application Server(JONES, Tim M, 2008).
Outro exemplo recente da SaaS é o navegador de internet Chrome da Google. Esse
navegador é um ambiente ideal, um novo desktop, através do qual os aplicativos podem ser
entregues (tanto local quanto remotamente) além de fornecer a experiência tradicional de
navegação pela Web. Na pagina oficial do fabricante (Google Chrome, 2012) ele descreve
que os aplicativos da web são websites interativos e avançados. Eles podem oferecer uma
ampla variedade de recursos ou ter o foco em uma única tarefa, como edição de fotos ou
compras. Você pode acessar facilmente os aplicativos da web na Chrome Web Store (JONES,
Tim M, 2008).
Na camada de software (SaaS) é possível desenvolver a característica de Pool de
Recursos, especificamente tratando-se do modelo multi-tentant. Uma aplicação que atende a
múltiplos clientes, chamados de tenants ou inquilinos. Esta arquitetura permite que múltiplos
inquilinos (empresas ou clientes) compartilhem os mesmos recursos físicos como, por
exemplo, um aplicativo ERP, mas permanecendo logicamente isolados. Dentro do modelo
multi-tenant existem quatro tipos de inquilinos segundo (TAURION, Cezar, 2010).

Inquilino isolado: Neste modelo, cada inquilino tem seu próprio escalonamento
de recursos computacionais, sendo assim não há compartilhamento de
recursos. Apesar de que a aplicação é oferecida a múltiplos clientes a partir do
mesmo servidor, este modelo não é multi-inquilino. É similar ao modelo
tradicional de hospedagem, onde cada usuário tem seu próprio conjunto de
recursos computacionais e sua própria instancia da aplicação. Para a uma oferta
42
SaaS, este modelo carece de agilidade e elasticidade, porque adicionar um
novo inquilino requer o provisionamento de sua própria instancia de hardware
e software. Também não permite economia de escala. Embora não seja
verdadeiramente Computação
em
Nuvem, é
um
passo
nesta
direção,
oferecendo como atrativo a facilidade de uma rápida oferta para SaaS
(TAURION, Cezar, 2010).

Multi-inquilino via hardware compartilhado (virtualização): Neste modelo,
cada inquilino tem seu próprio escalonamento de recursos computacionais,
porem a alocação é dinâmica a partir de um pool de recursos, via mecanismos
de virtualização. Bastante similar ao modelo anterior, mas permitindo
elasticidade na camada do hardware. Entretanto, apresenta limitações, pois a
unidade de alocação e liberação de recursos é a máquina virtual, onde a
aplicação vai operar (TAURION, Cezar, 2010).

Multi-inquilino via container: Vários inquilinos são executados na mesma
instancia de um container de aplicação (um servidor de aplicações), mas cada
inquilino está associado a uma instancia separada do software de banco de
dados. O ambiente de execução é compartilhado entre vários inquilinos, mas a
plataforma de dados é a mesma. A premissa do modelo é que o isolamento do
banco de dados garante a integridade dos dados dos inquilinos, ao mesmo
tempo em que o container de execução, por ser compartilhado, oferece as
vantagens de elasticidade e customização. Para garantir o isolamento dos
inquilinos dentro de uma única instancia do container ou servidor de
aplicações, este deve ser desenhado com funcionalidade para gerenciar a
alocação de recursos aos seus inquilinos (TAURION, Cezar, 2010).

Multi-inquilino com pilha de software compartilhada: É uma evolução do
modelo anterior, além do container da aplicação, também uma única instancia
do banco de dados que é compartilhada por todos os inquilinos (TAURION,
Cezar, 2010).
43
2.4.8 Platform-as-a-Service (PaaS)
Platform-as-a-Service, ou PaaS, provê a base para a SaaS, para o desenvolvimento e
suporte dessa camada. É capacidade oferecida ao consumidor de implantar para a
infraestrutura nuvem aplicativos adquiridos, criados usando linguagens de programação,
bibliotecas, serviços e ferramentas de suporte do provedor. O consumidor não vai administrar
ou controlar a infraestrutura da nuvem, incluindo rede, servidores, sistemas operacionais, ou
armazenamento, mas vai ter nesta camada o controle sobre os aplicativos implementados e
configurações do ambiente do aplicativo de hospedagem (MELL, Peter; GRANCE, Timothy,
2011).
A PaaS é semelhante à IaaS, mas inclui sistemas operacionais e serviços exigidos que
focam em um aplicativo específico. Por exemplo, a PaaS, fornece um sistema operacional
particular e um conjunto de aplicativos, como um banco de dados(JONES, Tim M, 2008).
Um exemplo interessante de PaaS é o Google App Engine. Segundo site oficial
(Google App Engine) da plataforma, o App Engine é um conjunto completo de
desenvolvimento que utiliza tecnologias familiares para construir e hospedar aplicativos da
web. Depois que o aplicativo é enviado para o Google, ele é hospedado e recebe a
escabilidade da plataforma do Google. Ele estando nesta plataforma não é necessário produzir
instancias novas do aplicativo, nem particionar o banco de dados ou comprar máquinas. O
App Engine fornece às APIs para armazenamento e gerenciamento de dados persistentes
(utilizando a Google Query Language, ou GQL), dentre demais tecnologias escalonáveis
como, por exemplo, BigTable e GFS. A sandbox na qual é executado o aplicativo da Web
restringe o acesso ao sistema operacional subjacente.
Outro exemplo de PaaS é o 10gen, que é ao mesmo tempo uma plataforma de nuvem e
um pacote de software livre que pode ser transferido por download para a criação de suas
próprias nuvens privadas. 10gen é uma pilha de software semelhante ao App Engine. A
plataforma também utiliza o conceito de sandbox para isolar aplicativos e fornecer um
ambiente confiável para um vasto número de computadores utilizando seu próprio servidor de
aplicativos (JONES, Tim M, 2008).
44
2.4.9 Infrastructure-as-a-Service (IaaS)
Camada base para a computação em nuvem, fornece a sustentabilidade das camadas de
SaaS e PaaS. Tratando infraestrutura como serviço na nuvem, para o consumidor é a
capacidade de prestação processamento, armazenamento e redes como serviço. O cliente é
capaz de implantar e executar o software arbitrário, que pode incluir sistemas operacionais e
aplicações. O consumidor não vai administrar ou controlar a infraestrutura exatamente, mas
tem controle sobre sistemas operacionais, armazenamento e aplicativos implantados. Alem de
um controle limitado aos recursos computacionais, tais como componentes de rede
selecionados (por exemplo, firewalls do host) (MELL, Peter; GRANCE, Timothy, 2011).
Essencialmente, é a capacidade de fazer arrendamento de um computador, ou uma
servidor, com limitações específicas quanto à qualidade do serviço em executar um sistema
operacional arbitrário e um software. Esta camada difere da PaaS no sentido de que o
hardware virtual é fornecido sem uma pilha de software. Em vez disso, o consumidor fornece
uma imagem de uma máquina virtual que é chamada em um ou mais servidores virtualizados
(AMRHEIN, Dustin; SCOTT, Quint, 2009).
Os serviços de infraestrutura abordam o problema de equipar de forma apropriada os
datacenters, assegurando o poder de computação quando necessário. Além disso, devido ao
fato das técnicas de virtualização serem comumente empregados nessa camada, economias de
custos decorrentes da utilização mais eficiente de recursos podem ser percebidas (AMRHEIN,
Dustin; SCOTT, Quint, 2009).
A IaaS é a forma mais bruta de serviço de computação (fora do acesso à infraestrutura
física). Quando se fala em infraestrutura de nuvem comercialmente, o Amazon Elastic
Compute Cloud (EC2) é usado como referencia. No EC2 da Amazon, é possível especificar
uma máquina virtual definindo seu sistema operacional e conjunto de aplicativos. Após a
definição básica citada anteriormente, é possível implementar seus aplicativos nela ou
fornecer sua própria imagem de máquina virtual para executar nos servidores. Em seguida,
você é cobrado pelo tempo de processamento, quantidade informação armazenada e largura
de banda da rede utilizada (JONES, Tim M, 2008).
O projeto Eucalyptus (Elastic Utility Computing Architecture for Linking Your
Programs To Useful Systems) é uma implementação de software livre semelhante ao EC2 da
Amazon compatível com a interface do serviço comercial. O Eucalyptus conta com o Linux e
45
o Xen para a virtualização do sistema operacional. O Eucalyptus foi desenvolvido na
Universidade da Califórnia, em Santa Bárbara, para pesquisas de computação em nuvem. O
Eucalyptus é organizado em uma estrutura hierárquica, através de componentes principais de
alto nível tais como Gerente de Instancia (Instance Manager) e o Gerente de Nuvem (Cloud
Manager). Essa organização facilita a utilização de recursos que estão alocados em redes
separadas (JONES, Tim M, 2008).
Outra plataforma estilo EC2 na IaaS, é a plataforma Enomalism de computação em
nuvem. O Enomalism é um projeto de software livre que fornece uma estrutura de
computação em nuvem com funcionalidade semelhante ao EC2. O Enomalism é baseado no
Linux, com suporte para Xen e Kernel Virtual Machine (KVM). Mas ao contrário das outras
soluções IaaS puras, o Enomalism fornece uma pilha de software baseada na estrutura de
aplicativo da Web TurboGears e Python (JONES, Tim M, 2008).
Dentro da IaaS a virtualização tem papel importante, o software IaaS que tem código
de baixo nível que é executado de maneira independente do sistema operacional, chamado
de hipervisor. O hipervisor é responsável por classificar os recursos de hardware e alocar tais
recursos baseado na demanda. Esse processo de agrupamento de recursos pelo hipervisor
torna possível a virtualização. A partir da virtualização é possível um computador físico, ser
vários computadores, ao invés de máquinas físicas tornam-se máquinas virtuais alocadas
dentro de um mesmo computador físico. Além de serem alocadas em um único computador
físico, as máquinas virtuais também podem ser alocados em uma infraestrutura compartilhada,
que tem como base várias organizações, ou computadores. Quando estão alocadas em
organizações, estas possuem interesses similares em relação a requisitos de segurança e
considerações de conformidade, tratando-se da nuvem como um todo. (Orlando, Dan 2011).
Conforme MELL; GRANCE (2011), há quatro modelos de implementação de nuvem:

Private Cloud

Community Cloud

Public Cloud

Hybrid Cloud
46
2.4.10 Private Cloud
A Private cloud é a infraestrutura provisionada para uso exclusivo de uma única
organização compreendendo vários consumidores (por exemplo, unidades de negócios). Pode
ser uma infraestrutura proprietária, gerenciada e operada pela própria organização. Pode ser
também um produto de terceiros, mas de acesso exclusivo. Podendo existir dentro ou fora das
instalações da organização. (MELL, Peter; GRANCE, Timothy, 2011)
Nuvens privadas existem dentro rede coorporativa, protegidas pelo firewall da
empresa e são gerenciadas pela organização. São serviços de nuvem que o cliente cria e
controla dentro de seu empreendimento. Nuvens privadas oferecem vários benefícios
semelhantes das nuvens públicas. A diferença, é que a organização do cliente é responsável
por configurar e manter a nuvem (AMRHEIN, Dustin; SCOTT, Quint, 2009).
As justificativas para adoção de uma nuvem privada são econômicas (redução de
custos) e qualidade dos serviços, com maior agilidade no atendimento às demandas dos
usuários por recursos computacionais (TAURION, Cezar, 2011).
A redução de custos é provocada pela padronização e automação dos serviços de TI.
Com padronização e automação, reduzem-se os custos operacionais, liberando-se o tempo
perdido em funções banais e agregando-o para atividades de maior valor. Além disso, com
automação, obtêm-se maior utilização dos ativos computacionais, aproveitando-se melhor o
parque computacional já instalado. Um subproduto da padronização e automação é a
possibilidade de mudar-se a relação entre TI e os seus usuários, criando-se políticas mais
visíveis e adequadas (TAURION, Cezar, 2011).
Com uma nuvem privada abre-se oportunidade de TI criar catálogos de serviços e seus
respectivos níveis de serviço medidos. A automação também reduz os erros causados por
intervenções manuais e libera os colaboradores de TI para atuarem focados no atendimento
aos usuários, que nas atividades de pouco ou nenhum valor agregado, como alocar espaço em
disco ou reservar horas em servidores (TAURION, Cezar, 2011).
Outro benefício palpável é a agilidade que a nuvem oferece à organização. A nuvem
privada abstrai os recursos computacionais aos usuários, que em uma visão como serviço, não
se preocupam mais onde e como as aplicações serão executadas. A TI, por sua vez, abre
47
espaço para os usuários serem mais inovadores e arriscarem mais em novos produtos e
serviços (TAURION, Cezar, 2011).
2.4.11 Community Cloud
Na community cloud, a infraestrutura de nuvem é provisionada para uso exclusivo de
uma comunidade de consumidores, ou organizações que têm preocupações comuns (por
exemplo, a missão, requisitos de segurança, política e considerações de adesão). O
gerenciamento pode ser feito pela comunidade proprietária e operada por uma ou mais das
organizações na comunidade. Podendo existir dentro ou fora das instalações da organização
(MELL, Peter; GRANCE, Timothy, 2011).
2.4.12 Public Cloud
A infraestrutura de nuvem é provisionada para uso aberto ao público em geral. Pode
ser uma infraestrutura proprietária, gerenciada e operada pela própria organização, ou
acadêmico, ou organização governamental, ou alguma combinação dentre os grupos
envolvidos. Ela existe nas instalações do fornecedor de cloud (MELL, Peter; GRANCE,
Timothy, 2011).
Uma nuvem pública é o que se considera uma nuvem no sentido usual, ou seja,
recursos fornecidos dinamicamente pela Internet usando aplicativos da Web de um provedor
terceirizado fora do local. Este fornecedor compartilha os recursos e fatura pelas métricas de
uso impostas ao consumidor. Nuvens públicas existem além do firewall da empresa e são
completamente hospedadas e gerenciadas pelo provedor da nuvem (AMRHEIN, Dustin;
SCOTT, Quint, 2009).
As nuvens públicas tentam a fornecer aos consumidores elementos de TI sem
problemas. Seja software, infraestrutura de aplicativo ou infraestrutura física, o provedor de
nuvem assume as responsabilidades de instalação, gerenciamento fornecimento e manutenção.
Os clientes são cobrados somente pelos recursos usados, portanto, a subutilização é eliminada
(AMRHEIN, Dustin; SCOTT, Quint, 2009).
Esses serviços, provisionados através de uma nuvem publica são oferecidos com
convenção sobre configuração. O que significa que são fornecidos com a ideia de acomodar
os casos de uso mais comuns. As opções de configuração são geralmente um subconjunto
48
menor do que seriam se o recurso fosse controlado diretamente pelo consumidor. Nesse caso,
os consumidores têm pouco controle sobre a infraestrutura, os processos que requerem forte
segurança e conformidade, não sao boas opções para irem à nuvens públicas (AMRHEIN,
Dustin; SCOTT, Quint, 2009).
2.4.13 Hybrid Cloud
Na infraestrutura de nuvem, é uma composição de duas ou mais nuvens distintas
(community cloud, private cloud ou public cloud) que permanecem entidades únicas, que são
unidas pela tecnologia padronizada ou proprietária, que permite que dados e aplicações
operem de maneira portável, tanto em um modelo, quanto no outro (por exemplo, uma nuvem
fazer balanceamento de carga entre as nuvens) (MELL, Peter; GRANCE, Timothy, 2011).
Nuvens híbridas são uma combinação de nuvem pública e privada usando serviços que
estão nos espaços públicos e privados. As responsabilidades de gerenciamento são divididas
entre o provedor da nuvem pública e a empresa em si. Usando uma nuvem híbrida, as
organizações podem determinar os objetivos e requisitos dos serviços a serem criados e obtêlos baseados na alternativa mais adequada (AMRHEIN, Dustin; SCOTT, Quint, 2009).
49
3 DESENVOLVIMENTO
A Fundamentação Teórica sobre os conceitos da computação em nuvem proporcionou
a identificação das características essenciais, os modelos de nuvem e como uma infraestrutura
de computação em nuvem deve comportar-se. Nesta etapa da pesquisa, foi definido o roteiro
para implantar o modelo de nuvem privada na infraestrutura de hospedagem de servidores do
Laboratório de Redes de Computadores da UNIVALI – Campus Itajaí. Ao término foi
avaliada a infraestrutura de computação em nuvem implementada, aferindo sua aderência
conforme as propriedades de nuvem definidas na documentação de MELL, Peter; GRANCE,
Timothy (2011), The NIST Definition of Cloud Computing (NIST Special Publication 800145). Esta documentação foi elaborada para planejamento de sistemas, gerentes de programas,
técnicos entre outros que pretendem adotar a computação em nuvem como consumidores ou
como fornecedores de serviços em nuvem. O NIST também determina os aspectos
importantes da nuvem, servindo esta documentação como um meio para comparação de
serviços. Fornece uma linha de base de conhecimento para a discussão do que é a computação
em nuvem e qual a melhor forma de uso da nuvem (MELL, Peter; GRANCE, Timothy, 2011).
As propriedades comparadas para aferir a aderência da nuvem são o autosserviço ou
serviço sob demanda, acesso amplo à rede, agrupamento de recursos, elasticidade e
mensuração dos recursos alocados, tanto nos aspectos de como os serviços devem se
comportar e também sobre como devem ser entregues.
NIST é Instituto Nacional de Padrões e Tecnologia dos Estados Unidos, que promove
métodos de métricas, padrões de tecnologia em diversas áreas. Este sempre com o objetivo de
equipar a indústria e comércio dos Estados Unidos com as ferramentas e informações
necessárias relativas à normalização. O que capacita estes a competir com maior eficácia no
mercado global. Os Laboratórios do NIST realizam pesquisas de classe mundial, buscando
que os avanços da tecnologia e infraestrutura do país ajudem as empresas norte-americanas
melhorar continuamente produtos e serviços além de padronizá-los. O NIST também
desenvolve testes, métodos de ensaio e de referência, prova de implementações de conceito e
análise técnica para promover o desenvolvimento e uso produtivo da tecnologia da
informação(NIST, 2014).
A partir das análises feitas sobre as características de computação em nuvem,
Infrastructure-as-a-Service e Private Cloud a plataforma mais adequada para o cenário do
50
Laboratório Redes da UNIVALI - Campus Itajaí, é o Openstack. O Openstack é uma
plataforma open source que gerencia agrupamento de recursos como: rede, armazenamento e
processamento, servindo-os ao usuário final como serviços sob demanda. Dentre as
características especificas da ferramenta que motivaram a escolha, estão:

Produto open source. Boa documentação, com grande e crescente comunidade
de usuários. Licença Apache 2.0.

Grandes empresas e instituições incentivam o projeto Openstack. Entre elas:
NASA, Rackspace, DELL, HP, Intel, AMD, Microsoft, Redhat, Ubuntu e
Cisco.

Serviços propostos para nuvem como: armazenamento, rede, processamento,
identidade de autorização a acesso aos serviços controle, todos divididos em
módulos configuráveis separadamente. O Openstack não é um sistema
monolítico, empacotado. A proposta do Openstack é ser multi-tarefa através da
divisão em serviços, que são configurados separadamente e por fim integrados
e gerenciados pelo próprio Openstack.

Permite a administradores e usuários o acesso a provisão de recursos através de
um portal web de autosserviço.

Suporte a demais serviços de outras nuvens como API EC2 da Amazon.

Múltiplos modelos de rede: VLAN, FlatDHCP, Flat.

Sistema de armazenamento de dados. Software pra criação de data storages
redundantes e escaláveis usando clusters, com funcionalidade similar ao
Amazon Simple Storage Service (Amazon S3).

Escalabilidade multidimensional.

Grupos de segurança: segurança por usuário, regras e projeto.

Gerenciamento online de máquinas virtuais: permite o gerenciamento de
imagens de discos virtuais.
51

Hipervisor suporte para o Microsoft Hyper-V, Citrix XenServer, Xen, KVM,
VMWware ESX, LXC e QEMU.

Suporte a diferentes formatos de máquinas virtuais como: Raw, Machine
(kernel/ramdisk outside of image), VHD (Hyper-V), VDI (VirtualBox), qcow2
(Qemu/KVM),VMDK (VMWare), OVF (VMWare, entre outros).
A Revisão Bibliográfica sobre as formas de virtualização capacitou a escolha pelo
modelo de hipervisor, que é baseado na arquitetura KVM. Como sistema operacional base, foi
utilizada a distribuição Ubuntu 12.04, que suporta o modelo de virtualização KVM. O Ubuntu
12.04 também foi desenvolvido e preparado para integração com o Openstack. (Ubuntu,
2010).
A disposição física do ambiente em que a nuvem foi implementada está composta por
três servidores do Laboratório de Redes da UNIVALI – Campus Itajaí, organizados em:

Nó Controlador da Nuvem: com hardware HP Proliant ML 350, possui um
processador com quatro núcleos de 1.86GHz de frequência. Memória RAM
4GB. Espaço em Disco 200GB.

Nó Controlador da Rede da Nuvem: com hardware HP Proliant ML 350,
possui um processador com quatro núcleos de 1.86GHz de frequência.
Memória RAM 4GB. Espaço em Disco 70GB.

Nó da Nuvem: com hardware HP Proliant ML 350, possui um processador com
quatro núcleos de 1.86GHz de frequência. Memória RAM 4GB. Espaço em
Disco 500GB.
52
Figura 12 Organização da Infraestrutura em nuvem proposta.
Fonte: O autor (2012).
Conforme demonstrado na Figura 12 Infraestrutura em nuvem proposta, um dos
computadores terá o papel de Nó Controlador da Nuvem, fornecendo toda a funcionalidade da
nuvem exceto a hospedagem de máquinas virtuais e o controle geral dos serviços de
rede. Este servidor irá hospedar os módulos de serviços:

O Nova Services(2013), responsável por processar a nuvem, o motor que
executa as atividades solicitadas pelos demais serviços da nuvem ou mesmo
pelo usuário via Dashboard. Neste computador não tem todo o conjunto de
serviços do Nova. Conforme configuração não é instalado o serviço NovaCompute que realiza a virtualização dos recursos computacionais tornando-os
máquinas virtuais via integração com o hipervisor, no caso o KVM. Este
serviço foi instalado no computador que é o nó da nuvem. Apesar de o NovaCompute não estar presente no nó controlador, é o nó controlador da nuvem
que está configurado o Nova Schedule que vai determinar a fila de
processamento a ser executada pelo nova-compute.

O Dashboard Horizon: é uma interface web de painel de controle de fácil
acesso, que serve ao usuário para: administração da nuvem, configurações de
usuário, máquina virtuais redes virtuais. Enfim o agrupamento de recursos
53
geral da nuvem disponibilizados na infraestrutura do Openstack (Horizon
Dashboard, 2014).

Serviço Keystone:gerencia e controla os acessos de usuários, serviços e
hóspedes da nuvem.

Serviço Glance: classifica e administra as bibliotecas de imagens de máquinas
virtuais da nuvem (Opensatck Glance, 2014).

Serviço Cinder: responsável por integrar os recursos de armazenamento,
controlando os volumes lógicos. Estes são criados a partir do espaço disponível
dos discos rígidos, formando os blocos de armazenamento. Utiliza-se das
integrações e suporte das tecnologias iSCSI e LVM para realizar o serviço de
armazenamento.

Serviço Ceilometer: Responsável pela coleta de dados referentes medição, em
termos de processamento e uso de recursos para possível cálculo de custos.
Estes custos referem-se ao preço pela utilização dos recursos da nuvem.
Todos os três servidores estão interligados pelo Nó Controlador da Rede da Nuvem
que administra a maior parte dos serviços de rede, como servidor de DHCP, roteamento da
rede dos nós da nuvem com a internet com sub-redes, roteamento dos programas e aplicações
da nuvem, controle de IPs flutuantes e conectividade de metadados. (Opensatck Grizzly,
2014). Para realizar estas atividades, o Controlador da Rede da Nuvem detém os serviços:
 O Quantum DHCP Agent é o serviço que faz a atribuição de endereços IP para
máquinas virtuais na nuvem.
 Openvswitch-switch é o serviço que funciona como um switch só que virtual,
interliga as redes e sub-redes. Aproveita-se da capacidade das máquinas
virtuais para criarem suas próprias redes virtuais dentro do projeto (tenant) no
qual estão inseridas. Interfaces virtuais de diferentes projetos podem se
conectar de diversas maneiras, gerando diversas possibilidades de utilização
(OpenVswitch, 2014).
 Quantum L3 Agent é o serviço que controla as pontes de rede. Realiza a
separação e a interligação das redes virtuais internas da nuvem, como por
54
exemplo, a comunicação de uma rede interna da nuvem com a internet, ou
entre as redes de uma mesma nuvem ou nuvens separadas, protegendo a
integridade de cada rede distinta.
O terceiro e último computador que compõe o modelo organizacional demonstrado na
Figura 12 é o Nó da Nuvem, este é o processador da nuvem, também o agente de serviço
baseado nas integrações com o controlador da nuvem e com o controlador de rede, que
fornecem o suporte para o seu desempenho. Perante a organização estabelecida é neste nó que
é realizada a configuração do hipervisor. Este é responsável por realizar a hospedagem das
máquinas virtuais da nuvem. Para execução destas funcionalidades o Nó da nuvem detém os
serviços:
 Libvirt-bin é o kit de ferramentas e bibliotecas que torna possível a
comunicação da nuvem Openstack com os hypervisors, entre eles o KVM. As
solicitações para as máquinas virtuais são feitas via libvirt para o hipervisor,
como iniciar, parar, pausar, salvar, restaurar e migrar uma máquina virtual
(Libvirt, 2014).
 KVM foi o hipervisor escolhido, ele fornece o suporte para a criação das
máquinas virtuais, como gerenciamento de memória, armazenamento, driver
de interface para dispositivos de entrada e saída.
 Nova-compute é processador das máquinas virtuais o serviço dentro do
Openstack que cria e finaliza as instancias de máquinas virtuais por meio de
APIs de hipervisor, neste caso API libvirt.
Após a definição e organização do ambiente de nuvem instalado, foi verificada sua
aderência perante as propriedades de nuvem definidas na documentação de MELL, Peter;
GRANCE, Timothy (2011), The NIST Definition of Cloud Computing (NIST Special
Publication 800-145). Dentre as propriedades comparadas está o autosserviço ou serviço sob
demanda, acesso amplo à rede, agrupamento de recursos, elasticidade e mensuração dos
recursos alocados. Para cada uma destas propriedades foi definido um subcapítulos a partir
dos 3.1 ao 3.5. Em cada um destes subcapítulos foi feito o detalhamento dos serviços
entregues pela nuvem e enquadrando-os com a sua propriedade corespondente, como, por
55
exemplo, o portal web funcionando como painel de controle para o usuário utilizar-se dos
serviços da nuvem, está relacionado com a propriedade de autosserviço.
3.1 Serviço Sob demanda ou Autosserviço na Infraestrutura de nuvem
Aplicada
O Serviço Sob Demanda ou Autosserviço, segue o princípio de que a nuvem deve
servir ao usuário sem que este tenha de se preocupar com configuração, instalação,
organização da estrutura computacional que deseja utilizar. O usuário solicita o serviço de
processamento computacional, como por exemplo, armazenamento, sem a preocupação onde
fisicamente estarão gravados os dados pelo serviço de armazenamento. Portanto, o usuário
recebe uma visão abstrata do serviço. Esta visão está fundamentada no conceito de que
computação em nuvem deve ser entregue ao usuário final assim como é entregue o serviço de
energia elétrica, comparando-os no sentido de que não importa origem nem pelo meio que são
entregues, ou ainda onde exatamente estão armazenados, desde que a entrega do serviço seja
de forma padronizada, sendo possível utilizá-lo em qualquer lugar desde que disponível, e
caso contratado, deve-se pagar pelo o que foi efetivamente foi utilizado. O recurso energia
elétrica, equivale-se com computação em nuvem aos recursos computacionais de
armazenamento, processamento e rede serem provisionados padronizadamente para que o
usuário possa usufruí-los sem preocupações (Vecchiola et al, 2009).
O atendimento das requisições solicitadas pelo usuário é realizado por meio de uma
API (Advanced Programming Interface – Interface Avançada de Programação) juntamente
com os serviços de provisionamento. A interface padrão, Dashboard Horizon, permite ao
usuário acessar e gerenciar toda a nuvem de modo simples e fácil. O detalhamento referente
ao funcionamento do Dashboard Horizon é mais bem exposto no subcapítulo seguinte, 3.2,
que o compara com a propriedade de acesso amplo à rede. A Figura 13 – Tela de Login da
Nuvem Openstack, demonstra a tela de acesso principal de login para acesso à nuvem.
56
Figura 13 Tela de Login da Nuvem Openstack.
Fonte: O autor (2014).
A plataforma de nuvem Openstack é dividida em projetos, como pode ser visualizado
na Figura 14. Cada projeto tem suas regras de permissões, controle de usuários e membros
como pode ser visualizado na Figura 15 – Membros Projetos Nuvem. Cada serviço também
precisa de ajustes de permissão para executar atividades que possam interferir na área de
outros serviços e não ocorram conflitos de acesso. O usuário com acesso adequado configura
o projeto conforme suas necessidades dentro dos limites do agrupamento de recursos
computacionais liberados. O usuário consegue instanciar uma ou mais máquinas virtuais por
meio do Dashboard Horizon. Define para cada instância o poder de processamento
computacional selecionável, desde o tamanho de volume de dados até a organização da rede
que a máquina virtual instanciada pertence.
57
Figura 14 Administração dos Projetos de Nuvem.
Fonte: O autor (2014).
Figura 15 Membros Projetos Nuvem.
Fonte: O autor (2014).
A possibilidade de criar templates pré-configurados para máquinas virtuais, faz com
que não seja necessário ao usuário conhecimentos avançados referentes ao detalhamento
infraestrutura da nuvem e de como aplicá-los. Com os templates prontos e disponíveis cabe ao
usuário servir-se conforme suas preferências. Na plataforma de nuvem Openstack existem
dois tipos de templates, um para imagens de sistemas operacionais, e outro para faixa de
recursos computacionais.
58
Os templates de imagens são preparados a partir de imagens de sistemas operacionais
pré-carregadas para a nuvem. Estas possibilitam sua associação com a máquina virtual. São
demonstradas na Figura 16 - Templates de Imagens de Máquinas Virtuais, duas imagens de
sistemas operacionais que já foram pré-carregadas e estão prontas para uso. Uma das imagens
refere-se ao sistema operacional Ubuntu e outra ao sistema operacional CirrOS. Com o
template pronto o usuário define qual atende melhor sua necessidade e solicita o seu
provisionamento no momento da criação da máquina virtual. Portanto a máquina virtual já é
instanciada com a pré-instalação do sistema operacional escolhido.
Figura 16 Templates de Imagens de Sistemas Operacionais.
Fonte: O autor (2014).
A liberação destes templates só é possível com a configuração do serviço de registro e
catálogo de imagens, o Glance. Para criar o catálogo de imagens, são carregadas as imagens
para dentro da nuvem, para que estas futuramente possam ser utilizadas pelo usuário para
criar a sua máquina virtual. Ao carregar a imagem para nuvem é considerada sua configuração
tanto para o formato de disco, quanto para o formato do contêiner.
O formato de disco de uma imagem de máquina virtual é o formato que o hipervisor
interpreta para que seja possível sua comunicação entre o disco virtualizado com o disco
físico. A partir desta interpretação torna-se possível a virtualização. Os hipervisores e os
discos virtuais têm diferentes formatos de disco. Para realizar a virtualização, a nuvem que foi
criada com base no Openstack, consegue atender os seguintes formatos:

RAW. Um formato de imagem de disco não estruturado. Formato comum, padrão de
disco rígido. Arquivos sem uma extensão acatam este formato.
59

VHD. O formato de disco Virtual Disk Format, é comumente usado por hipervisores
como: VMware, Xen e VirtualBox entre outros.

VMDK. Formato de disco desenvolvido e utilizado por hipervisor VMware .

VDI. Formato de disco desenvolvido e utilizado pelos hipervisores VirtualBox, e
também aceito pelo emulador virtualizador QEMU.

QCOW2. Formato de disco utilizado por hipervisor KVM, compatível com o
emulador QEMU que pode se expandir de forma dinâmica.

AKI, ARI, AMI. Formatos de discos desenvolvidos para utilização na plataforma
proprietária de nuvem da Amazon.
O formato de contêiner trata de encapsular os dados virtualizados. Indica se a imagem
de máquina virtual está em um formato de arquivo que também contém metadados sobre a
máquina virtual real. Dentre os formatos de containers estão: Bare, OVF, AKI, ARI e AMI

Bare, formato atende a virtualização completa, onde não é necessário que a imagem
possua a proteção específica em relação à virtualização.

OVF, Open Virtualization Format, é formato padrão para realizar a distribuição de
dispositivos computacionais físicos em virtuais.

AKI, ARI, AMI. Formatos de imagens que já incorporam o formato de contêiner por
padrão são desenvolvidos e utilizados pela plataforma proprietária de nuvem da
Amazon.
Na Figura 16, pode ser visualizado que ambas as imagens já carregadas tanto a do
sistema operacional Ubuntu quanto a do sistema operacional Cirros, foram criadas com
formato de disco QCOW2 e formato contêiner Bare.
O usuário ao provisionar uma máquina virtual com suas preferências através da
solicitação via Dashboard Horizon, esta máquina tem a definição do seu volume de disco
rígido virtualizado. Para que o usuário sirva-se do serviço de armazenamento de dados foi
implementado o serviço Cinder da nuvem Openstack.
60
O Cinder é responsável por armazenar os dados das instancias das máquinas virtuais
em blocos de dados físicos, a partir de volumes lógicos. Em outras palavras é o serviço Cinder
que virtualiza o agrupamento de recursos de dispositivos de armazenamento em blocos,
fornecendo ao usuário final uma API de autosserviço para solicitar e consumir esses recursos.
Inibindo assim a preocupação e conhecimento de onde realmente implantado, ou em que tipo
de dispositivo está o seu armazenamento. Para realizar está conversão de dados e armazenálos o Cinder utiliza-se de alguns serviços base como o Open-iSCSI e LVM (RHOTON, 2013).
O Open-iSCSI (Internet Small Computer System Interface), possibilita a execução de
comandos de disco rígido SCSI encapsulados sobre protocolo IP, o que remove o vínculo da
gravação de dados com o computador local. Possibilita que todos os dados, inclusive
relacionados ao sistema operacional não estejam necessariamente sendo gravados na máquina
física, a qual está sendo virtualizada. O acesso à unidade de armazenamento ocorre em nível
de bloco de dados. O funcionamento ocorre com uma solicitação de leitura ou escrita de
dados a partir de computador origem. Então este comando de leitura e escrita SCSI é
encapsulado em um pacote de rede via protocolo IP. Após isso é endereçado ao computador
de destino que recebe pacote IP com o comando SCSI e o processa. O processamento vai
recuperar ou gravar a informação para o computador que originou a solicitação..
O serviço base LVM (Logical Volume Management), agrupa e padroniza partições de
um disco rígido em volumes lógicos de dados que podem ser facilmente redimensionados.
Com o LVM, um disco rígido ou conjunto de discos rígidos é alocado em um ou
mais volumes físicos. Os volumes físicos são combinados em grupos de volumes lógicos.
Quando um novo disco rígido é adicionado ao grupo de volume lógico, suas partições podem
ser expandidas (LEWIS, 2006).
Com a integração destes dois serviços base, Open-iSCSI e LVM com o serviço Cinder
da nuvem Openstack, é possível provisionar armazenamento de dados como serviço sob
demanda ao usuário final. Além de permitir que usuário sirva-se da possibilidade de escalonar
a quantidade de espaço de disco, tanto quanto quantidade de discos (chamado de volumes
perante a nuvem Openstack) a utilizar em seu projeto de nuvem. Porem a escalabilidade estará
confinada dentro dos limites de espaço de disco disponível para nuvem. A Figura 17 - Criação
de Volumes demonstra a criação do volume via Dashboard Horizon, bem como espaço total
disponível para ser alocado em um volume ou distribuído em vários.
61
Figura 17 Criação de Volumes.
Fonte: O autor (2014).
A Figura 18 Volumes Disponíveis ilustra os volumes já criados, que estão disponíveis
para serem associados a máquinas virtuais e seus tamanhos.
Figura 18 Volumes Disponíveis.
Fonte: O autor (2014).
As definições referentes a quantidade de processadores e memória RAM para a
máquina virtual a ser instanciada na nuvem, também são realizadas via templates. Cada
template define uma escala de processamento. As escalas estão definidas de mais leve com
512mb de memória RAM e um processador virtual, até a capacidade que os computadores
62
físicos que compõem a nuvem puderem oferecer sendo virtualizados. A definição deste
template de processamento para a nuvem Openstack é Flavors (Sabores). Na Figura 19
Template Flavors (Sabores) Disponíveis, é possivel verificar os flavores para seleção do
usuário ao instanciar sua máquina virtual na nuvem.
Figura 19 Template Flavors (Sabores) Disponíveis.
Fonte: O autor (2014).
A criação dos templates flavors tem dependência direta com o hipervisor, no caso da
nuvem Openstack implementada neste trabalho, o KVM é o hipervisor. Além do hipervisor, o
driver de virtualização para hipervisor, o Libvirt também é tão essencial quanto, pois este
auxilia o hipervisor na entrega ao usuário as funcionalidades de virtualização por meio de
APIs.
O Libvirt é o driver de virtualização para hipervisor que fornece um meio padrão para
que seja possível gerenciar as máquinas virtuais executando sistemas operacionais de modo
convidado, sobre o hipervisor de um computador. Como resultado, o Libvirt fornece APIs
necessárias para realizar as atividades como: provisionar, criar, modificar e controlar as
máquinas virtuais dentro dos limites hipervisor para essas operações. O Libvirt comunica-se
com um hipervisor para executar as solicitações da API. O modelo de interface via APIs torna
possível solicitar e processar as requisições remotamente. A API não trata políticas de
virtualização de alto nível ou recursos de gerenciamento de múltiplos nós de máquinas
virtuais, como balanceamento de carga, mas a API consegue servir recursos para que estas
funcionalidades sejam implementadas sobre o Libvirt, ou mesmo no hipervisor. O Libvirt
63
consegue isolar aplicativos das frequentes mudanças, que podem ocorrer no nível mais baixo
da estrutura de virtualização (LIBVIRT, 2014).
O Libvirt é um conjunto de ferramentas de gerenciamento para aplicações com foco
em virtualização baseado em APIs, assim como a plataforma de nuvem Openstack, que é
baseado em APIs RESTful (Representational state transfer - Transferência do Estado
Representativo ).As APIs do Openstack utilizam-se das funcionalidades as APIs do Libvirt,
onde estas fazem o intermédio das requisições referente a virtualização com o hipervisor . O
Libvirt é o principal responsável em possibilitar abstração por meio de APIs comuns com
funcionalidades comuns, e a interação destas APIs entre si, tornam o ambiente de nuvem
escalável.
O KVM foi hipervisor escolhido para implantação da nuvem Openstack, por ser o
hipervisor mais testado com integração ao Openstack e mais estável, sendo considerado o
padrão para implantação. Conforme já abordado na sessão 2.1.7 KVM, no Capitulo 2
Fundamentação Teórica, o KVM faz a virtualização através do kernel do Linux, tendo grande
responsabilidade no controle da paginação de memória e virtualização dos dispositivos do
computador físico que foi virtualizado. O hipervisor KVM suporta os seguintes formatos de
imagem de máquina virtual:

RAW.

QEMU Copy-on-write (qcow2).

Disk QED Qemu aprimorada.

VMDK, formato de disco da máquina virtual, referente a proprietário VMWare.
O serviço Nova-Compute permite o controle do modelo de processador do
computador físico via hipervisor KVM. Este controle inclui a capacidade maximizar o
desempenho de máquinas virtuais, através da exposição de novos recursos de processador do
computador físico para a máquina virtual, e também garante um padrão de processador
consistente em todas as máquinas, removendo possíveis variáveis de incompatibilidade entre
os processadores diferentes.
O KVM é quem fornece as possibilidades de funcionalidades virtualizadas ao Libvirt,
que por sequencia as organiza e distribui em forma de APIs.
64
Para proporcionar ao usuário final o serviço de rede além da virtualização realizada
dos dispositivos de rede dos computadores físicos, foram implementados os serviços base
Openvswitch, Quantum L3 Agent e Vlan bridge-utils.
Openswitch como já abordado anteriormente tem o mesmo papel de um switch físico,
porém virtualizado. Os Hipervisores precisam da capacidade de direcionar e controlar o
tráfego entre as máquinas virtuais com as redes da nuvem. O Openvswitch possibilita que a
rede seja identificada entre as máquinas virtuais para que estas possam facilmente comunicarse. Também garante que a rede não vai ser afetada se a máquina virtual for migrada para outro
computador físico. O que torna possível isso é o princípio de soft state Este mantém o estado
da camada de Enlance de rede IP, em uma tabela e encaminha para a camada de Rede, os
estados dos dados roteáveis, a política de QoS, e configuração de monitoramento. Este
direcionamento via camada de Rede é apoiada pelo serviço Quantum L3 Agent.
Juntamente com o hipervisor o Openvswitch compõe o serviço Quantum, é
responsável pela criação de redes privadas virtuais internas na nuvem para comunicação entre
as máquinas virtuais desta rede. Também permite a criação de sub-redes e roteadores para
essas redes.O que possibilita inclusive a saída da rede da máquina virtual para a rede de
computadores físicos. Para gestão da rede da nuvem Openstack é feita a subdivisão em três
redes de centros de dados físicos básicos distintos, que são:

Rede de gerenciamento: rede de troca de dados interna entre os serviços e
componentes da nuvem Openstack. Os endereços de IP são somente acessados dentro
do centro de dados.

Rede de dados: rede de comunicação de dados entre as máquinas virtuais da nuvem.

Rede externa: rede de saída da nuvem com acesso a internet, as máquinas virtuais da
nuvem conseguem acesso a internet, ou a rede física de computadores por meio desta
rede.
Na nuvem Openstack implementada é pré-definido e configurado o cenário de rede
que é mais bem demonstrado pela Figura 20 - Topologia da rede da nuvem implementada. O
tipo de rede de dados está endereçada com a faixa de IP 50.50.1.0/24. A comunicação das
máquinas virtuais da rede de dados é feita através do router_univali. Este roteador virtual é
responsável por direcionar o acesso à rede externa, resultando no acesso com a internet. Este
65
também é responsável pelo auxilio na composição de IPs (Internet Protocol – Protocolo de
Internet) externos para nuvem na rede com faixa de IP 192.168.1.120/24.
Figura 20 Topologia da rede da nuvem implementada.
Fonte: O autor (2014).
A nuvem implementada tem disponível para o usuário final sirva-se do serviço de rede
alocando as máquinas virtuais, a rede ext_net, que fornece acesso à rede externa, e a rede
net_univali que é a rede privada interna para comunicação entre as máquinas virtuais,
conforme pode ser visto na Figura 20 Redes disponíveis na nuvem. Já na Figura 21, podem
ser visualizadas as redes que estão disponíveis bem como seus estados de funcionamento.
66
Figura 21 Redes disponíveis na nuvem.
Fonte: O autor (2014).
3.2 Acesso amplo à rede na Infraestrutura de nuvem Aplicada
Assim como no Autosserviço, a nuvem tem que atender a requisições vindas de diversos
dispositivos e comunicar-se ao usuário via uma interface padrão. O Dashboard Horizon é o
painel de controle da nuvem que abstrai os detalhes e complexidades da nuvem ao usuário
final, conforme já abordado no subcápitulo 3.2. O Dashboard Horizon é disponibilizado como
um aplicativo web, desenvolvido em python no Framework Django, implementado sobre
mod_wsgi e servidor de páginas web Apache, que o possibilita ser acessado via qualquer
dispositivo que tenha acesso a internet e consiga carregar uma página de internet. A
requisição é feita acessando o Dashboard Horizon. Este interpreta a solicitação e repassa a
requisição para a API responsável para atende-lá. No momento seguinte interage com o
serviço responsável para executar a requisição. Enfim retorna ao usuário via Dashboard o
resultado (OPENSTACK, 2014).
67
Figura 22 Acesso à nuvem via smartphone.
Fonte: O autor (2014).
A Figura 22 demonstra o acesso realizado via smartphone ao Dashboard Horizon. Para
que fosse realizado este teste o smartphone foi conectado na mesma rede da nuvem via
conexão wireless, através de um navegador de internet, pode-se acessar o Dashboard
Horizon.
3.3 Agrupamento de Recursos na Infraestrutura de nuvem Aplicada
A nuvem é composta a partir da virtualização de dispositivos físicos, que quando
virtualizados podem ser mais bem aproveitados e distribuídos. Os recursos computacionais
virtualizados são agrupados e totalizados para que o usuário final possa organizá-los e
distribuí-los conforme sua preferência ou necessidade. A disponibilidade e quantificação dos
68
recursos computacionais são segmentadas por projetos dentro da nuvem Openstack, onde
cada projeto pode ser considerado uma nuvem secundária.
A Figura 23 Visão Global,
apresenta o resumo da quota de recursos computacionais que podem ser utilizados.
Figura 23Visão Global dos recursos computacionais da nuvem.
Fonte: O autor (2014).
3.4 Elasticidade rápida ou Escalabilidade na Infraestrutura de nuvem
Aplicada
O conceito de recursos computacionais infinitos é proporcionado pelo entendimento de
que a nuvem não está restritamente atrelada aos recursos disponibilizados no momento. Esses
recursos podem ser incrementados com a adição de novos dispositivos físicos, que quando
virtualizados e configurados compartilham do mesmo padrão dos atuais, presentes na nuvem.
Em outras palavras, os novos recursos computacionais estão aptos a serem agrupados com os
recursos já existentes. Isso tudo é possível com base na disponibilidade e gerenciamento dos
recursos como serviços.
A plataforma de nuvem Openstack foi projetada para ser escalável horizontalmente, que é
escalabilidade por adição de nós de nuvem dividindo a carga de processamento entre eles. Em
vez de migrar a nuvem para servidores com maior capacidade, pode-se adicionar mais
servidores e simplesmente instalar serviços configurados de forma idêntica. Em seguida é
69
possível escalar e balancear a carga entre os grupos de serviços funcionalmente idênticos, que
comunicam-se em um barramento de mensagens padrão. A preocupação fica em torno do
hardware que vai ser adicionado a nuvem, que deve possuir o mesmo tipo de processador para
suportar a migração da instância. Quanto a possível diferença de processamento que pode
ocorrer entre as máquinas virtuais, o serviço Nova-Scheduler controla a fila de processos,
equilibrando a carga proporcionalmente aos diferentes poderes de processamento. As
diferenças no dimensionamento, como quantidade de núcleos dos processadores, e a
quantidade de memória RAM, são tratadas para que se tornem equivalentes ao usuário final.
A formação desta escalabilidade na plataforma de nuvem Openstack depende da interação
do usuário mesmo que se tenham recursos computacionais extras, para que seja possível a
criação de uma nova máquina virtual para realizar escalonamento horizontal. Afim de que
escalabilidade seja realizada de maneira automatizada, é necessário que existam recursos
computacionais disponíveis e a configuração de três serviços: Heat, LBaas e Ceilometer. Cada
um destes serviços tem uma tarefa específica, mas quando integrados é possível alcançar o
objetivo de escalabilidade automática.
O Heat é um serviço para orquestrar múltiplas instâncias virtuais, redes e outros serviços
de modo automatizado por meio da comunicação do modelo de WebService com integração
com as APIs dos serviços da nuvem. Para que ocorra a automação primeiramente é necessária
a criação de um agrupamento de recursos computacionais. Cada um destes recursos é um
componente de um agrupamento e deve estar descrito no modelo de template do agrupamento
de recursos. A descrição de cada um desses recursos deve conter um tipo de recurso. O tipo de
recurso define o que é o recurso alocado, se é uma instância de uma máquina virtual, ou se é
um roteador virtualizado, ou uma sub-rede. Definidos os tipos de recurso e suas propriedades
relacionadas, como por exemplo, se for uma instância de máquina virtual deve-se ter a
definição do template de imagem de sistema operacional corespondente. Já se o recurso for do
tipo referente à rede, um roteador, por exemplo, é definido a quais redes, este está conectado.
Com as propriedades do modelo de template, os recursos podem ser tratados como objetos na
comunicação com o WebService. As alterações feitas nesses objetos são repassadas do
WebService para as APIs de serviços da nuvem, portanto é possível a criação de scripts para
realização de alterações nos recursos computacionais alocados como objetos.
No processo de automação da escabilidade da nuvem, o serviço Heat é responsável pela
integração e dos serviços LBaaS e Ceilometer . Com a configuração dos parâmetros para o
70
Heat informando sua área de atuação e o que deve ser feito, este passa a coordenar os serviços
de LBaaS (Load Balance-as-a-Service – Balanceador de Carga como Serviço) e Ceilometer,
executando-os sem a necessidade de interação com o usuário.
O serviço LBaaS é responsável por distribuir as solicitações de clientes em vários
servidores. Este melhora a tolerância a falha do servidor, minimiza o tempo de resposta do
usuário final e evita gargalos na utilização de recursos.O LBaaS executa sempre sobre um
agrupamento de recursos(pool) pré-definido .As operações realizadas pelo serviço LBaaS são:

Balanceamento da carga de tráfego rede de um cliente para serviços da nuvem, ou
máquinas virtuais da nuvem, presentes na mesma rede ou em redes diferentes.

Persistência de sessão de nuvem. Existem dois modelos de persistência de sessão
padrão, a do IP de origem e de HTTP Cookies. Na persistência pelo IP de origem, as
requisições de rede provenientes do mesmo endereço IP de origem são tratados pelo
mesmo membro do agrupamento de recursos. No modelo HTTP Cookies, ao ser
realizado a primeira requisição de rede de um cliente, a função de balanceamento de
carga cria um cookie, para que as solicitações subsequentes, contendo o mesmo valor
de cookie sejam tratadas pelo mesmo membro do agrupamento de recursos.

Monitoramento do status atividade dos serviços de aplicativos. Através de requisições
baseadas em protocolo ICMP (Internet Control Message Protocol – Protocolo de
Controle de Mensagens via Internet) e HTTP (Hyper-Text Transfer Protocol Protocolo de Transferência de Hipertexto).

Obtenção de estatísticas de monitoramento agrupamento de recursos. O LBaaS
fornece um conjunto de estatísticas de cada agrupamento de recursos. Estas estatísticas
detalham a quantidade de bytes recebidos pelos membros do agrupamento de recursos,
bem como os bytes enviados, as conexões ativas e total de conexões realizadas.
O monitoramento que o LbaaS faz é referente ao controle de uso, mas ele por si só não
tem controle em relação à carga da utilização dos recursos. Para controle de carga deve-se
utilizar o Ceilometer.
Através do Ceilometer é possível realizar o controle de carga e sobre carga do
agrupamento de recursos. O Ceilometer é o serviço que faz a mensurabilidade da utilização da
nuvem para que seja possível a tarifação e caso da nuvem ser comercializada. Maior
71
detalhamento sobre o serviço Ceilometer está descrito no subcapítulo seguinte, que trata a
aderência da nuvem comparando-a com a propriedade de Mensurabilidade.
Com os três serviços, Heat, LBaaS e o Ceilometer integrados,
a automação da
escalabilidade da nuvem ocorre a partir da parametrização do serviço Ceilometer que deve
sinalizar através de um aviso ou alerta a sobrecarga do agrupamento de recursos. Este sinal de
sobrecarga é encaminhado ao serviço do Heat que está programado para quando recebê-lo,
seja instanciada uma nova máquina virtual para dividir a sobrecarga. Após a nova máquina ser
instanciada o Heat avisa ao serviço de balanceamento de carga, LbaaS, que está maquina está
presente ao agrupamento de recursos e deve ser equilibrada a carga do agrupamento de
recursos.
3.5 Mensurabilidade na Infraestrutura de nuvem Aplicada
A realização da mensurabilidade da nuvem implementada Openstack é feita pelo
serviço Ceilometer, que é distribuído como módulo que pode ser implementado para nuvem.
O objetivo do serviço Ceilometer é mensurar o processamento dos recursos computacionais
alocados para a nuvem como serviço. Perante a quantificação de utilização é padronizado as
métricas para mensuração. O processo de mensuração passa por três etapas, medição,
classificação e tarifação. A etapa de tarifação é aplicada para realizar a cobrança do usuário
final, auxiliando na determinação do preço pelo uso da nuvem, caso esta seja comercializada.
A forma com que são coletados os dados é por meio de uma camada de notificação
criada pelo serviço Ceilometer, onde os serviços da nuvem antes de qualquer execução
passam por ela. A cada processo que passa pela camada de notificação são gerados as
informações sobre os serviços da nuvem. Estes dados são interpretados pelo Agente Coletor
do Ceilometer. Na interpretação dos dados coletados, são aplicadas métricas de mensuração
para apresentação de valores padronizados. Depois dos dados coletados serem tratados, eles
são gravados no banco de dados ou em um arquivo simples para serem resgatados e
posteriormente demonstrados ao administrador da nuvem.
O serviço Ceilometer contempla um componente que é responsável especificamente
pela emissão de notificação de alarme. O componente de alarme permite configurar alarmes
com base na avaliação de métricas sobre limites de carga estipulados na coleta dos dados dos
serviços da nuvem. Um alarme pode ser definido sobre uma única métrica, ou em uma
combinação de métricas. Por exemplo, pode ser definido um alarme que dispare quando o
72
consumo de memória chega a 70% em uma determinada máquina virtual, e se este estado da
memória se manteve por um período maior que de 30 minutos.
Como base, o Ceilometer tem três tipos de métricas, Acumulativa, Bitola (Gauge) e
Delta. Todas estas métricas são aplicadas sobre os recursos computacionais virtualizados, ou
sobre as instancias das máquinas virtuais.
A métrica Acumulativa mensura o aumento de uso em decorrer do tempo. A partir
desta métrica é possível mensurar:

Tempo de uso do processador (processador referente a maquina virtual),
unidade de medida em nano segundo. Os dados são de origem de pesquisa.

Utilização do processador pelo sistema operacional, tempo ocioso do
processador, tempo em espera do processador, esperando processamento dos
dispositivos de entrada e saída. Unidade de medida nano segundo. Os dados
são de origem de notificação.

Número de requisições de leitura e escrita de disco, unidade de medida número
de requisições. Os dados são de origem de pesquisa.

Volume de dados de leitura e escrita em disco. Unidade de medida em Bytes.
Os dados são de origem de pesquisa.

Número de bytes de entrada de saída na interface de rede de uma máquina
virtual. Unidade de medida total de bytes trafegados. Os dados são de origem
de pesquisa.
A métrica de Bitola, mensura dados referentes a atividades relacionadas com IPs
Flutuantes, tempo de processamento de imagens de máquinas virtuais, valores variáveis
referentes à leitura e escrita de dados no respectivo disco. Esta métrica é utilizada na
mensuração de:

Média de utilização de processador. Unidade de medida em percentual. Os
dados são de origem de pesquisa.

Frequência do processador. Unidade de medida MHz. Origem dos dados por
notificação.
73

Utilização do processador pelo sistema operacional em percentual, tempo
ocioso do processador em percentual, tempo em espera do processador em
percentual, esperando processamento dos dispositivos de entrada e saída em
percentual. Unidade de medida nano segundo. Os dados são de origem de
notificação.

Média de requisição de leitura e escrita de disco. Unidade de medida em
requisições por segundo. Os dados são de origem de pesquisa.

Média de bytes escritos e lidos de um disco. Unidade de medida bytes por
segundo. Os dados são de origem de pesquisa

Média de bytes por segundo de entrada de saída na interface de rede de uma
máquina virtual. Unidade de medida bytes por segundo. Os dados são de
origem de pesquisa
A métrica Delta mesura a carga de tráfego quanto é suportado, bem como a largura de
banda. Está métrica mensura como, por exemplo:

Quantidade de requisições criadas para um roteador, ou uma porta de rede, subrede. Quantidade de rotas, requisições por porta, requisições por sub-redes. Os
dados são de origem de Notificação.
Estes são somente alguns exemplos de mensurabilidade utilizados pelo serviço
Ceilometer divididas entre os três tipos de métricas.
A plataforma Openstack na versão que foi implementada, não é perfeitamente aderente
à documentação que definição de computação em nuvem do NIST. Entretanto, novas versões
da plataforma ocorrem a cada semestre. A cada nova versão, a plataforma fica mais estável e
são acrescentadas novas funcionalidades. Uma das funcionalidades que não existia na versão
da nuvem implantada, que já foi liberada em nova versão, é a funcionalidade de
escalabilidade vertical. Escalabilidade vertical é a capacidade de redimensionar o poder
computacional de uma instância, sem que seja necessário instanciar uma nova máquina
virtual. É possível adicionar um novo nó computacional e determinar que os recursos
computacionais dele vão ser alocados para uma máquina virtual já existe, redimensionado o
poder computacional desta máquina virtual. Mesmo assim a plataforma proporciona como
74
serviço uma infraestrutura de nuvem, abstraindo do usuário final maior detalhamento de
configuração da estrutura física. O usuário final consegue servir-se e provisionar recursos
computacionais sob demanda e através destes, formar uma infraestrutura, definidos modelo de
rede, de armazenamento e de capacidade de processamento. É possível mensurar os recursos
computacionais, e acessá-los de qualquer localidade com disponibilidade de internet.
Com a nuvem implementada, foi formada a infraestrutura base para que ela cresça
através da adição de mais nós computacionais. Na nuvem implementada é possível instanciar
maquinas virtuais, criar unidades de armazenamento, criar redes, simular ambientes para
testes de softwares. É possível aproveitar-se das APIs disponibilizas e formar um sistema auto
escalável, onde este quando sobre carregado, solicite à nuvem novas máquinas virtuais para
balancear a carga. È possível mensurar a utilização das máquinas virtuais criadas na nuvem,
ou dos recursos computacionais em separado. É possível configurá-la, liberando-a para acesso
externo, via internet, e provisionar recursos computacionais, ou máquinas virtuais. É possível
gerenciar de modo centralizado, rápido e fácil toda a infraestrutura, controle sobre a rede,
controle sobre o armazenamento de dados, controle sobre o processamento, sobre as
máquinas. Agilidade da manutenção através da formação do catalogo de imagens de sistemas
operacionais e templates flavor. Balancear a carga de sistemas migrados para a plataforma de
nuvem.
75
4 CONCLUSÕES
Este trabalho teve por objetivo explorar o conceito de computação em nuvem aplicada
para oferecer uma infraestrutura como serviço. Para isso, foi feita a revisão bibliográfica da
área de sistemas distribuídos, que proporcionou o entendimento de como ocorreu a evolução
da tecnologia de computação em nuvem. Ficou claro então que as características da
computação em nuvem foram herdadas das tecnologias anteriores, virtualização, cluster e
computação em grid.
A revisão sobre o conceito de computação em nuvem demonstrou a existência de uma
convergência dos recursos de TI para imersão neste paradigma, por motivos de necessidade
crescente por manuteabilidade, escalabilidade e abstração da complexidade da infraestrutura.
Pode se perceber também o aumento da necessidade do usuário pela busca de independência,
do autosserviço, sem ter a preocupação de onde está localizada a infraestrutura fisicamente,
ou configuração que deve ser feita para ter a disponibilidade de acesso à infraestrutura
computacional. A nuvem consegue transformar recursos computacionais ao usuário por meio
de uma interface padrão, permitindo assim a independência do usuário, que realiza sozinho
suas demandas. Os estudos realizados serviram de suporte para determinar quais serviços a
infraestrutura de nuvem deve proporcionar e a base para implementá-los.
A expectativa gerada sobre a possível implementação da nuvem em computadores
simples, não obteve sucesso. O fator fundamental neste caso foi a ausência da instrução de
virtualização nativa nos processadores, como por exemplo, VT-X(Virtualização nativa nos
processadores da plataforma Intel) e AMD-V(Virtualização nativa nos processadores da
plataforma AMD). O hardware e os processadores utilizados neste primeiro ambiente não
tinham a instrução nativa de virtualização.
Quanto à tentativa da aplicação do ambiente de nuvem sobre um ambiente já
virtualizado, é válida, mas somente para fins de conhecimento do funcionamento da nuvem.
Pois neste caso já ocorreu a virtualização, e para seu funcionamento deveria ocorrer a
virtualização sobre a virtualização, o que não é possível. Sobre um ambiente já virtualizado
pode-se somente simular a virtualização, como por exemplo, a virtualização QEMU.
Aplicando a simulação de virtualização perde muito rendimento, pois o processador vai
processar dois ciclos para que cada processo gerado a partir desta simulação. Portanto tornase inviável a utilização da nuvem para execução de tarefas que demandam por processamento.
76
Em ambos os casos a premissa determinante para formar-se uma infraestrutura de
nuvem é a virtualização. Para que a virtualização seja favorável e não um obstáculo na
execução na nuvem, se faz necessária a aplicação sobre uma infraestrutura cujos
processadores apresentem a instrução de virtualização nativa. A demanda por processamento
da nuvem e a integração de tecnologias de virtualização exigiu alteração do ambiente e busca
por uma estrutura de computadores mais modernos, com maior capacidade de processamento
e principalmente com a instrução de virtualização nativa.
A plataforma de nuvem escolhida, o Openstack, não tem uma instalação monolítica ou
empacotada. A proposta do Openstack é ser multitarefa através da divisão em serviços, que
são configurados separadamente e por fim integrados e orquestrados pelo próprio Openstack.
Cada um destes módulos corresponde a um determinado serviço da nuvem. O detalhamento
para prestar cada serviço tem uma dependência em tecnologias variadas, onde cada uma
destas gera a necessidade de conhecimento aprofundado. Apesar da complexidade na
implantação de cada serviço, a plataforma de nuvem escolhida Openstack, é benéfica por
possuir ampla gama de recursos que podem ser provisionados e integrados. Existem inúmeras
possibilidades tanto de aprofundamento quanto de melhorias através incorporação em cada
um dos serviços. Com o aprofundamento do conhecimento na plataforma Openstack pode-se
notar que ela está tornando-se referência padrão de plataforma de nuvem, com grandes
corporações investindo em seu crescimento. Pela plataforma ser de código aberto, cada uma
destas corporações consegue adaptá-la conforme sua necessidade específica.
Os conceitos de nuvem e sua aplicação por meio do Openstack foram contrastados
frente à sua aderência as definições de computação em nuvem descritas na documentação The
NIST Definition of Cloud Computing (NIST Special Publication 800-145) pelo NIST. Cada
propriedade definida na documentação no NIST, foi atendida por um ou mais serviços da
nuvem implementada.
Como conclusão final pode-se afirmar que o modelo de nuvem na sua camada mais
baixa, de infraestrutura como serviço, não atende por completo os requisitos que uma nuvem
deve proporcionar ao usuário, principalmente na abstração do detalhamento de configuração.
Sempre em algum quesito é necessária a intervenção do usuário na infraestrutura física para
atender completamente as requisições feitas para o serviço da nuvem. Entre essas
intervenções pode citar a configuração que deve ser realizada para adição de mais Nós
Computacionais na nuvem. A tecnologia de computação em nuvem ainda é muito incipiente e
77
ainda não se tem um padrão exato a ser seguido. A plataforma Openstack assim como a
tecnologia de computação em nuvem está em constante alteração para facilitar sua instalação.
A tecnologia Openstack passa por constantes atualizações que ocorrem a cada semestre, para
tornar a nuvem mais estável. Portanto a cada semestre é liberada uma nova versão da
plataforma. Desde o início do desenvolvimento deste trabalho de pesquisa foram liberadas
quatro versões diferentes.
Como trabalhos futuros propõem-se realizar (i)desenvolvimento de aplicações para a
nuvem implementada explorando as funcionalidades de escalabilidade e serviços sob
demanda; (ii) Portabilidade de sistemas para nuvem implementa; (iii) Aprimoramento dos
recursos de escalabilidade a partir da atualização da versão da plataforma, como tornar a
nuvem escalável verticalmente além de horizontalmente; (iv) Aumentar o tamanho da nuvem,
torná-la uma nuvem Híbrida ou Pública, bem como sua capacidade de processamento
adicionando cada vez mais nós; (v) Disponibilizar acesso a nuvem para pesquisa e uso com
aplicações que demandam de processamento. Como por exemplo, oferecer acesso à nuvem,
para que alunos possam desenvolver aplicações em larga escala. Além do desenvolvimento
destas aplicações, testá-las e executá-las o que exige uma infraestrutura flexível e de fácil
acesso.
78
REFERÊNCIAS
AMRHEIN, Dustin; SCOTT, Quint. Computação em Nuvem para a Empresa: Parte 1:
Capturando a Nuvem. 2009. Disponível em
<http://www.ibm.com/developerworks/br/websphere/techjournal/0904_amrhein/0904_amrhei
n.html>. Acesso 20 abril de 2012.
BACELLAR, Hilario Viana. Cluster: Computação de Alto Desempenho. 2010. Campinas,
SP, Brasil.
CISCO, Connected World Report: Part 3, Data Center. Disponível em:
<http://newsroom.cisco.com/dlls/2010/ekits/Cisco_Connected_World_Report_PartIII.pdf >.
Acesso em 27 março de 2012.
CHRISTESEN, Sune. 20 Cloud Platforms (IaaS software). 2011. Disponível em
<http://www.datacentermap.com/blog/cloud-software-389.html>. Acesso 11 de abril de 2011.
COELHO, Fabio, et al. Trabalho de Redes de Computadores I. 2008. Disponível em: <
http://www.gta.ufrj.br/grad/09_1/versao-final/virtualizacao/index.html>. Acesso em: 17 abril
2012.
DEDLEY, H. History of Virtualization. 2009. Disponível em:
<http://www.infobarrel.com/History_of_Virtualization>. Acesso em: 03 abril 2012.
FERRER, Rafael. Nuvem poderá movimentar US$ 1,45 bi em 2015. 2011. Disponível em <
http://info.abril.com.br/noticias/ti/nuvem-podera-movimentar-us-1-45-. shl>. Acesso em 16
de maio de 2012.
FOSTER, Ian et al. The Anatomy of the Grid: Enabling Scalable Virtual Organizations, Intl
J. Supercomputer Applications. 2001. Disponível em:
<http://www.globus.org/alliance/publications/papers/anatomy.pdf >Acesso em: 17 abril 2012.
FURHT, Borko, ESCALANTE, Armando. Handbook of Cloud Computing. ,Springer,
2010.
GANDOUR, Fábio L. Cloud Computing na área. 2008. Disponível em
<http://info.abril.com.br/corporate/storage/cloud-computing-na-area.shtml>. Acesso em 25 de
maio de 2012.
GOOGLE, App Engine. 2012. Disponível em:
<https://developers.google.com/appengine/docs/whatisgoogleappengine?hl=pt-BR>. Acesso
em 27 março de 2012.
GOOGLE, Google Chrome. 2012. Disponível em: <https://www.google.com/chrome/intl/ptBR/more/index.html?hl=pt-br>. Acesso em: 10 de abril de 2012.
HAGUIAR,Alexandre,Openstack Disponível em
<https://www.softwarelivre.gov.br/palestras-tecnicas-cisl/linuxnuvem3> Acesso em: 11 de
maio de 2012.
79
JONES, Tim M. Computação em Nuvem com Linux: Plataformas e Aplicativos da
Computação em Nuvem. 2009. Disponível em:
<http://www.ibm.com/developerworks/br/library/l-cloud-computing/>. Acesso em 28 de abril
de 2012.
JOVANELI, Rogerio. Brasil supera média de cloud computing. 2010. Disponível em <
http://info.abril.com.br/noticias/mercado/brasil-supera-media-mundial-em-cloud-computing09122010-28.shl?2>. Acesso em 11 de maio de 2012.
KING, Samuel T., et al. Operating System
Support for Virtual Machines.. Proceedings of the 2003 USENIX Technical
Conference. Department of Electrical Engineering and Computer Science
University of Michigan.2003.
KUNDRA, Vivek. Federal Cloud Computing Strategy. 2011. Disponível em:
<http://www.cio.gov/documents/federal-cloud-computing-strategy.pdf>. Acesso em: 17 abril
2012.
LAUREANO, Mauro. Máquinas Virtuais e Emuladores:Conceitos, Técnicas e Aplicações.
2006. Disponível em:
< http://www.mlaureano.org/aulas_material/so/livro_vm_laureano.pdf>. Acesso em: 17 abril
2012.
LEWIS, A.J. LVM HOWTO. 2006. Disponível em: < http://tldp.org/HOWTO/LVMHOWTO/index.html > Acesso em 20 de Abril de 2014.
LIBVIRT, libvirt. 2014. Disponível em <http://libvirt.org/> Acesso em: 28 de março de
2014.
M.A.R Dantas. Grids Computacionais Fundamentos, Ambientes e Experiências.
Congresso Brasileiro de Ciência da Computação, Itajaí, 2004, 873 – 882. Itajaí, SC –
Brasil.2004.
MELL,Peter;GRANCE,Timothy. The NIST Definition of Cloud Computing (NIST Special
Publication 800-145). NIST National Institute of Standards and Technology,Gaithersburg,
September 2011. Disponível em: <http://csrc.nist.gov/publications/nistpubs/800-145/SP800145.pdf>. Acesso em: 03 de Março de 2012.
NIST, About NIST. 2014. Disponível em < http://www.nist.gov/ >. Acesso em 03 de junho de
2014.
OPENSTACK,Dashboard Horizon.2014.Disponível em
<http://horizon.openstack.org/intro.html>. Acesso em: 28 de maio de 2014.
OPENSTACK,Grizzly. 2014. Disponível em <http://docs.openstack.org/grizzly/basicinstall/apt/content/basic-install_architecture.html > Acesso em: 28 de maio de 2014.
OPENSTACK, GLANCE. 2012. Disponível em <http://glance.openstack.org/> Acesso em
28 de maio de 2012.
80
OPENSTACK, NOVA. 2013. Disponível em < http://nova.openstack.org/>. Acesso em 28 de
maio de 2014.
OPENSTACK, Openstack. 2014. Disponível em
<http://openstack.org/downloads/openstack-overview-datasheet.pdf>. Acesso em: 28 de abril
de 2014.
OPEN VSWICH, Open vswich. 2014 Disponível em < http://openvswitch.org/>. Acesso em:
13 de maio de 2014.
OPENSTACK, Image-Formats. 2014. Disponível em<http://docs.openstack.org/imageguide/content/image-formats.html> Acesso em 01 de maio de 2014.
ORLANDO, Dan. Modelos de serviço de computação em nuvem, Parte 1: Infraestrutura
como serviço. 2011. Disponível em
<http://www.ibm.com/developerworks/br/cloud/library/cl-cloudservices1iaas/ >. Acesso 12
de abril de 2012.
PITANGA, Marcos. Compuatacao em Cluster. 2003. Disponível em:
<http://www.clubedohardware.com.br/artigos/153>. Acesso em: 17 abril 2012.
PITANGA, Marcos. Computação em Cluster:O estado da arte em computação. Rio de
Janeiro: EditoraBrasport, 2003.
RHOTON, John. Discover OpenStack: The Storage components Swift and Cinder.2013.
Disponível em< http://www.ibm.com/developerworks/cloud/library/cl-openstack-swiftcinder/index.html?ca=dat> Acesso em 12 de maio de 2014.
RUEST, N., RUEST, D., Virtualization: The beginner´s guide, Mc. Graw Hill, New York,
2009, ISBN: 978-07-161401-6.
SINGHT, Amit. An Introduction to Virtualization. 2004. Disponível em:
<http://www.kernelthread.com/publications/virtualization/>. Acesso em: 03 abril 2012.
STOCKINGER Heinz, Defining the Grid: A Snapshot on the Current View.Springer
Netherlands.2007.
STRICKLAND, Jonathan. Como funciona a computação em grade. 2009. Disponível em:
<http://informatica.hsw.uol.com.br/computacao-em-grade.htm> Acesso em: 17 abril 2012.
TAURION, Cezar. Entendendo o modelo multi-tenancy. 2010. Disponível em
<https://www.ibm.com/developerworks/mydeveloperworks/blogs/cTAURION/entry/entenden
do_o_modelo_multi-tenancy?lang=pt_br>. Acesso em 10 de maio de 2012.
TAURION, Cezar. Cloud Computing: Começando a jornada por nuvens privadas. 2011.
Disponível em
<https://www.ibm.com/developerworks/mydeveloperworks/blogs/cTAURION/entry/comecan
do_jornada_por_nuvens_privadas?lang=pt_br>. Acesso 20 abril de 2012.
81
THOMAS, Bittman J. Criando uma nuvem privada. 2009. Disponível em
<http://info.abril.com.br/noticias/corporate/gartner/criando-uma-nuvem-privada-0311200912.shl?4 >. Acesso 02 de maio de 2012.
THOLETI, Bhanu P. Hypervisors, virtualization, and the cloud: Learn about hypervisors,
system virtualization, and how it works in a cloud environment. 2011. Disponível em: <
http://www.ibm.com/developerworks/cloud/library/cl-hypervisorcompare/>. Acesso em: 03
abril 2012.
UDDOH, Emmanuel. Cloud, Grid and High Performace Computing: Emerging
Applications. Hershey. IGI Global, 2011.
UBUNTU, iSCSI Initiator.2014.Disponível em:
<https://help.ubuntu.com/12.04/serverguide/iscsi-initiator.html> Acesso em 03 de Maio de
2014.
Vecchiola C., Chu, X. and Buyya R. Aneka: A software platform for .net-based cloud
computing. CoRR, abs/0907.4622, 2009. Disponível em
<http://arxiv.org/ftp/arxiv/papers/0907/0907.4622.pdf> . Acesso 02 de maio de 2014.
WEISS, Aaron. Computing in the Clouds. Magazine netWorker - Cloud computing: PC
functions move onto the web 2007. New York, Estados Unidos.
82
GLOSSÁRIO
Firewall
Parede corta fogo. Dispositivo que controla o tráfego entre a Internet e
um computador ligado a ela. Impede que usuários não autorizados
entrem neste computador, via Internet, ou que dados de um sistema
caiam na Intenet, sem prévia autorização.
Sandbox
“Caixa de areia” é um ambiente protegido. Programas executados em
um sandbox possuem poucos privilégios e não podem fazer diversas
alterações no sistema.
Thread
É a forma de um processo dividir a si mesmo em duas ou mais tarefas
que podem ser executadas concorrentemente.
Dashboard
Painel de Ferramentas, Painel de instrumentos, Painel de controle
geral. Local onde se pode ter a visão geral da plataforma que está
sendo utilizada.
API
Interface de Programação de Aplicativos, padrão formalizado para
solicitar funcionalidades de um sistema ou recurso e utilizá-lo sem
entrar em detalhes do funcionamento do recurso.
QoS
(Quality of Service) Qualidade de serviço, qualidade do trafego dos
pacotes de rede entre computadores.
Smartclient
Aplicativo cliente simples, que conecta-se com um aplicativo servidor
para ser executado.