Embed Size (px)
Citation preview
UNIVERSIDADE FEDERAL DE MATO GROSSO
COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM SISTEMAS DE
INFORMAÇÃO
RELATÓRIO DE ESTÁGIO SUPERVISIONADO
INFRAESTRUTURA COMPUTACIONAL COM USO DE
TECNOLOGIAS DE NUVEM E CONTAINERS
GLÁUCIO CARLOS FERREIRA
CUIABÁ – MT
2016
UNIVERSIDADE FEDERAL DE MATO GROSSO
COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM
SISTEMAS DE INFORMAÇÃO
RELÁTORIO DE ESTÁGIO SUPERVISIONADO
INFRAESTRUTURA COMPUTACIONAL COM USO DE
TECNOLOGIAS DE NUVEM E CONTAINERS
GLÁUCIO CARLOS FERREIRA
Relatório apresentado ao Instituto de
Computação da Universidade Federal de
Mato Grosso, para obtenção do título de
Bacharel em Sistemas de Informação.
CUIABÁ – MT
2016
UNIVERSIDADE FEDERAL DE MATO GROSSO
COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM
SISTEMAS DE INFORMAÇÃO
GLÁUCIO CARLOS FERREIRA
Relatório de Estágio Supervisionado apresentado à Coordenação do Curso deSistemas de Informação como uma das exigências para obtenção do título deBacharel em Sistemas de Informação da Universidade Federal de Mato Grosso
Aprovado por:
Prof. MSc. Nilton Hideki Takagi
Instituto de Computação
(Coordenador de Estágios)
Prof. Dr. Josiel Maimone de Figueiredo
Instituto de Computação
(ORIENTADOR)
MSc. César Eduardo Guarienti
Instituto de Computação
(SUPERVISOR)
Dedicatória
A Deus, Pai e Amigo de todas as horas. Àminha família e a todas as pessoas que meapoiaram nesta caminhada. E in memoriam aduas grandes mulheres, muito importantes naminha vida, minha mãe Maria Eni Ferreiraminha avó Maria Luiza Moreira, das quaissinto imensa saudade!!!
Agradecimentos
A DEUS por ter me dado forças e me ajudado a concluir mais esta etapa
importante da minha vida, e por ser o Pai e o Amigo de todas as horas.
À minha família pelo apoio incondicional.
Ao Prof. Dr. Josiel Maimone de Figueiredo, meu orientador e Diretor do
Instituto de Computação, a quem também agradeço pela oportunidade deste estágio.
Ao MSc. César Eduardo Guarienti, meu supervisor, pela amizade,
paciência, dedicação, ensinamentos, apoio, encorajamento e confiança durante este
estágio.
Aos professores do Instituto de Computação pela grande contribuição à
minha vida acadêmica e formação profissional, em especial aos professores do Curso
de Sistemas de Informação.
Aos meus amigos e colegas do Curso de Sistemas de Informação.
E aos técnicos do Instituto de Computação, em especial aos meus amigos da
Coordenação de SI Carlos e Milton, e ao grande amigo Juscelino Nascimento
(Black).
“Os dias prósperos não vêm poracaso; nascem de muita fadiga epersistência.”
Henry Ford
SUMÁRIO
LISTA DE SIGLAS E ABREVIATURAS................................................................................11
RESUMO............................................................................................................................... 12
INTRODUÇÃO...................................................................................................................... 13
Organização deste Trabalho........................................................................................14
1 REVISÃO DE LITERATURA..............................................................................................16
1.1 Virtualização.....................................................................................................16 1.1.1 Vantagens da Virtualização.....................................................................17 1.1.2 Monitor de Máquina Virtual (Hypervisor)..............................................18 1.1.3 Paravirtualização.....................................................................................19 1.1.4 Virtualização Completa...........................................................................19 1.2 Computação em Nuvem....................................................................................20 1.2.1 Modelos de Implementação....................................................................21 1.2.2 Características Essenciais.......................................................................22 1.2.3 Modelos de Serviços...............................................................................23 1.3 Sistemas Distribuídos........................................................................................24 1.4 Clusters.............................................................................................................25 1.5 Grids..................................................................................................................26 1.6 Middlewares......................................................................................................26 1.7 Gerenciamento da Nuvem.................................................................................27 1.7.1 Principais Características do Gerenciamento com o OpenNebula.........27 1.7.2 Principais Funções e Ferramentas...........................................................29 1.8 Tecnologia de Containers.................................................................................31 1.8.1 Diferença entre Máquina Virtual e Container.........................................32 1.8.2 Diferença entre Containers LXC e Docker.............................................33 1.9 Estrutura do Docker..........................................................................................34 1.9.1 Funções...................................................................................................36 1.9.2 Ferramentas.............................................................................................37
2 MATERIAS, TÉCNICAS E MÉTODOS..............................................................................38
2.1 Materiais Utilizados..........................................................................................38 2.2 Instalação da Plataforma OpenNebula..............................................................39 2.2.1 Instalação e configuração do Front-end..................................................39 2.2.2 Instalação dos Hosts................................................................................40 2.2.3 Considerações finais sobre a instalação da plataforma...........................40 2.3 Instalação da Tecnologia de Containers...........................................................42
3 RESULTADOS...................................................................................................................44
3.1 Plataforma OpenNebula....................................................................................44 3.2 Tecnologia de Containers.................................................................................58 3.3 Persistência de dados........................................................................................62 3.4 Migração on-line...............................................................................................62
4 DIFICULDADES ENCONTRADAS....................................................................................65
5 CONCLUSÕES.................................................................................................................. 66
6 REFERÊNCIAS BIBLIOGRÁFICAS..................................................................................67
LISTA DE FIGURAS
Figura 1: (a) paravirtualização (b) virtualização completa – Adaptada de
(TANENBAUM, 2003)...............................................................................................18
Figura 2: Visão básica de Computação em nuvem.....................................................22
Figura 3: Papéis dos atores nas três camadas..............................................................24
Figura 4: Características dos clusters computacionais – Fonte: Adaptado de (ALVES,
2008)...........................................................................................................................25
Figura 5: Middleware em um Sistema Distribuído – Fonte: Adaptado de
(TANENBAUM; STEEN, 2007)................................................................................27
Figura 6: Estrutura básica do OpenNebula.................................................................28
Figura 7: Cloud Bursting (Nuvem de Ruptura)..........................................................29
Figura 8: Diferença entre (a) Máquinas Virtuais (b) Containers................................33
Figura 9: Estrutura do Docker.....................................................................................35
Figura 10: Sistema de arquivos multicamadas do Docker.........................................36
Figura 11: Tela de logon.............................................................................................41
Figura 12: Imagens sameersbn/MySQL :latest e sameersbn/redmine:3.1.1-3............42
Figura 13: Imagem dell/wordpress.............................................................................43
Figura 14: Infraestrutura (front-end e hosts)...............................................................44
Figura 15: Datastores..................................................................................................45
Figura 16: Atributos, permissões e informações do Datastore nfs-imgens................46
Figura 17: Marketplace...............................................................................................47
Figura 18: Escolha do Datastore na importação de imagens do Marketplace...........47
Figura 19: Imagens.....................................................................................................48
Figura 20: Relação de templates.................................................................................48
Figura 21: Templates – configurando CPU, memória e hypervisor...........................49
Figura 22: Escolha do host hospedeiro.......................................................................50
Figura 23: Participação em Nuvem Híbrida...............................................................50
Figura 24: Templates de redes virtuais........................................................................51
Figura 25: Informações, permissões e atributos para template de rede......................52
Figura 26: Informações do range de endereços IP.....................................................53
Figura 27: Máquinas Virtuais......................................................................................54
Figura 28: Acesso à máquina virtual...........................................................................55
Figura 29: Hosts..........................................................................................................55
Figura 30: Informações, permissões e atributos de um host.......................................56
Figura 31: Dashboard para máquinas virtuais e hosts................................................57
Figura 32: Dashboard para usuários, imagens e redes virtuais..................................58
Figura 33: Redirecionamento de portas do Container Wordpress..............................60
Figura 34: Monitoramento em tempo real de containers............................................60
Figura 35: Wordpress executado a partir de container................................................61
Figura 36: Redmine executado a partir de container..................................................61
Figura 37: Ping disparado contra a máquina virtual ID 77.........................................63
Figura 38: Máquina virtual ID 77 antes da migração.................................................63
Figura 39: Máquina virtual ID 77 após a migração....................................................64
LISTA DE SIGLAS E ABREVIATURAS
ARPA Advanced Research Projetcts Agency
ARPANET Rede Advanced Research Projetcts Agency
CN Computação em Nuvem
CPU Central Processing Unit
DHCP Dynamic Host Configuration Protocol
E/S Entrada/Saída
IP Internet Protocol
IPV4 Internet Protocol version 4
IPV6 Internet Protocol version 6
KVM Kernel-Based Virtual Machine
NSF National Science Foundation
NSFNET Rede National Science Foundation
SSH Secure Shell
TCP Transport Control Procotol
TI Tecnologia da Informação
VM Máquina Virtual
VMM Monitor de Máquina Virtual
VMMs Monitores de Máquina Virtualização
VMs Máquinas Virtuais
WWW World Wide Web ou simplesmente web
RESUMO
Este trabalho foi desenvolvido com o objetivo de demonstrar a viabilidade de
implantação de estrutura computacional em nuvem e da utilização da tecnologia de
containers. Buscando um modelo de gestão flexível, escalável e de baixo custo, para
o gerenciamento de recursos computacionais, oferecido pela Nuvem. Aliado a
benefícios como agilidade, controle, leveza e portabilidade, para aplicações,
oferecidos pela tecnologia de containers. Foram utilizados os recursos da
infraestrutura de TI do Instituto de Computação da Universidade Federal de Mato
Grosso. Para implementação da Plataforma como serviço (PaaS) foi utilizado o
software livre OpenNebula versão 4.14.2 desenvolvido pela OpenNebula Systems. E
para a tecnologia de containers foi utilizado o, também software livre, Docker. O
sistema operacional utilizado foi Linux Ubuntu Server 14.04 LTS. Foram alcançados
os resultados esperados com relação ao gerenciamento de recursos computacionais e
aplicações pela web com a utilização de containers. Assim como a migração de
máquinas virtuais em execução, sem provocar indisponibilidade dos serviços ou
recursos. A realização deste trabalho de estágio contribuiu de forma significativa na
consolidação dos conhecimentos que o aluno adquiriu durante o curso de Sistemas de
Informação e, o auxiliou na aquisição de uma nova gama de conhecimentos.
INTRODUÇÃO
A internet foi criada a partir da interconexão de duas redes de pesquisas nos Estados
Unidos. Uma delas a ARPANET, inicialmente chama de ARPA (Advanced Research Projetcts
Agency), foi criada no fim dos anos 1950. E a NSFNET criada pela NSF (National Science
Foundation) no fim dos anos 1970. Entre as décadas de 1970 e 1990 a internet oferecia quatro
aplicações básicas: correio eletrônico, o logon remoto, a transferência de arquivos e o
newsgroup.
Mas quando a aplicação web (WWW – World Wide Web) e o navegador Mosaic foram
criados, a internet passou a atrair milhares de pessoas. A web possibilitou a configuração de
páginas com conteúdos diversas (texto, imagens, áudio e vídeo) e links que permitiam
interligar outras páginas.
Desde então, a forma como se lida com a informação não é mais a mesma, foram
observadas mudanças no cotidiano de pessoas e instituições, a forma como as pessoas se
comunicam e os meios utilizados para esta comunicação, como, por exemplo, aplicativos para
computadores e para dispositivos móveis. Telegram1 e WhatsApp2 são dois bons exemplos de
aplicativos de mensagens instantâneas muito utilizados atualmente. Também na forma de
discutir e partilhar ideias, com o uso de grupos de discussão e redes sociais. O pagamento de
contas on-line, graças aos serviços bancários disponibilizados via web. A retirada de certidões,
boletos referentes a impostos e taxas, entre outros documentos, sem a necessidade de
enfrentas longas filas, também tronou-se realidade. A partir do momento que órgãos públicos
disponibilizaram diversos serviços via web.
Mas este avanço tecnológico leva a uma quantidade cada vez maior de dispositivos
conectados. Que contribuem com o crescimento exponencial de tráfego, armazenamento e
gerenciamento de quantidades cada vez maiores de dados. Este crescimento torna-se ainda
maior com o advento da internet das coisas (internet things). Ou seja, o avanço tecnológico
provoca uma demanda crescente de recursos computacionais, fazendo-se, então, necessário a
otimização desses recursos.
A virtualização oferece a otimização no uso dos recursos computacionais, trazendo1 http://www.telegram.org2 http://www.whatsapp.com
13
muitos benefícios. O que leva à simplificação da manutenção, redução do espaço físico
necessário e, consequentemente, à redução dos custos com condicionamento térmico do
ambiente. Podem ser observados, ainda, a redução de custos operacionais e ganhos quanto a
flexibilização e centralização na administração do ambiente.
A gestão eficiente dos recursos computacionais contribui para melhoria da qualidade
dos serviços prestados e redução dos custos operacionais. Não seria diferente no mundo
acadêmico, onde são muitas as demandas e os recursos escassos. A construção da Nuvem e
disponibilização de aplicações com a tecnologia de containers, utilizando soluções baseadas
em software livre, somados a oportunidade de um novo aprendizado são a base da motivação
deste trabalho.
O seu objetivo é demonstrar a viabilidade da implementação de estrutura
computacional em nuvem e da utilização da tecnologia de containers. A finalidade é fazer o
gerenciamento de recursos computacionais (processamento, memória, rede, entre outros) e
aplicações pela web.
A utilização da Computação em Nuvem oferece um modelo de gestão flexível,
escalável e de baixo custo. Aliada à tecnologia de containers oferece outros benefícios como
agilidade, controle, leveza e portabilidade.
Organização deste Trabalho
As seções a subsequentes foram organizadas da seguinte forma:
• Revisão de Literatura: representa o embasamento teórico necessário à
realização das atividades deste trabalho.
• Materiais, Técnicas e Métodos apresentam a infraestrutura utilizada, assim
como as principais características e principais componentes da plataforma e da
tecnologia de containers. Assim como as técnicas e métodos utilizados na
implementação.
• Resultados: apresenta argumentos e imagens que demonstram que os
14
resultados esperados foram alcançados.
• Dificuldades Encontradas: discorre sobre as dificuldades encontradas na
realização deste trabalho.
• Conclusões: traz as lições aprendidas, ao longo do estágio supervisionado.
15
1 REVISÃO DE LITERATURA
1.1 Virtualização
A virtualização foi introduzida com os mainframes3, quando a IBM4 lançou o termo
“Time Sharing” (tempo compartilhado).
Uma das razões para se introduzir a virtualização na década de 1970 foi permitir que
software herdado executasse em caros hardwares de mainframe. O software não somente
incluía várias aplicações mas, na verdade, também os sistemas operacionais para aos quais
tinha sido desenvolvido. Essa abordagem voltada ao suporte de software herdado foi aplicada
com sucesso nos mainframes IBM 370 (e seus sucessores), que ofereciam uma máquina
virtual para a qual tinham sido transportados diferentes sistemas operacionais
(TANENBAUM; STEEN, 2007).
Na plataforma x86, a virtualização chegou apenas no final da década de 1990, com o
lançamento do VMware Virtual Plataform, que posteriormente, viria a ser chamado de
VMware Workstation. Um produto da empresa americana VMware5, considerado o primeiro
produto comercial para virtualização na plataforma x86.
Com o passar dos anos, foram surgindo outros produtos. Entre os quais destacam-se o
Hyper-V da Microsoft6 e, os Open Source (código aberto), Xen7 e KVM8 (Kernel-based Virtual
Machine – Máquina Virutal Baseada em Kernel) Linux.
A virtualização permite que um único computador hospede múltiplas máquinas
virtuais, cada uma com seu próprio sistema operacional. A vantagem dessa abordagem é que a
falha em uma das máquinas virtuais não faz com que as outras falhem automaticamente. Em
um sistema virtualizado, diferentes servidores podem funcionar em diferentes máquinas
virtuais, o que mantém o modelo de falha parcial de um multicomputador a um custo mais
3 Computadores de grande porte4 http://www.ibm.com5 http://www.vmware.com6 http://www.microsoft.com7 http://www.xenproject.org8 http://www.linux-kvm.org
16
baixo e de muito mais fácil manutenção (TANENBAUM, 2003).
1.1.1 Vantagens da Virtualização
As perspectivas em relação à virtualização, tornaram-se ainda melhores, quando
fabricantes de processadores, como AMD9 e Intel10, introduziram em seus produtos as novas
tecnologias AMD-V e Intel-VT, respectivamente.
Essas tecnologias interceptam instruções e controlam o monitor de máquina virtual
(hypervisor), eliminando a necessidade de uma camada de software complexa e problemas de
desempenho. Estas tecnologias proporcionaram melhorias significativas para a virtualização,
tanto na eliminação de barreiras quanto na implementação de plataformas de virtualização
mais eficientes.
A execução de softwares nas máquinas virtuais apresenta outras vantagens além do
forte isolamento. Uma delas é que ter menos máquinas físicas significa economia de dinheiro
em hardaware e em eletricidade e menos espaço ocupado no escritório (TANENBAUM,
2003).
A virtualização oferece diversas vantagens em relação à infraestrutura do modelo
tradicional, trazendo benefícios imediatos para as empresas. Desempenha papel de grande
importância na consolidação de servidores. Os benefícios alcançados pela virtualização
podem ser percebidos com facilidade. Por exemplo, a economia alcançado pelo
compartilhamento de hardware permite utilizar os recursos desse hardware de forma mais
eficiente. Logo, reduz a necessidade de aquisição de mais hardware. Assim, é possível reduzir
o espaço físico necessário, simplificar a manutenção e, consequentemente, reduzir
significativamente os custos do condicionamento térmico do ambiente.
Pode-se, ainda, ressaltar os benefícios com a centralização da administração, a
facilidade e rapidez na implantação de sistemas em uma infraestrutura virtual. E a migração
on-line de sistemas convidados para outro servidor hospedeiro, também chamado de host. A
migração on-line é utilizada quando existe a necessidade de atualização ou substituição do
9 http://www.amd.com10 http://www.intel.com
17
hardware. Também conhecida como Live Migration, ela pode reduzir e até eliminar o tempo
de inatividade de sistemas implementados em máquinas virtuais.
Os benefícios alcançados com o uso da virtualização são numerosos. Além daqueles
já descritos, destacam-se outros como o isolamento, a segurança da informação e a
elasticidade. Todas essas características fazem da virtualização um dos principais pilares da
Computação em Nuvem (Cloud Computing).
1.1.2 Monitor de Máquina Virtual (Hypervisor)
O monitor de máquina virtual (VMM), também conhecido como hypervisor, age como
uma camada de software, intermediária, entre hardware real e o sistema operacional
convidado, ou sistema operacional virtualizado, fornecendo a este a ilusão de que o mesmo
fora instalado sobre o hardware subjacente.
O monitor de máquina virtual pode ser entendido como a camada responsável por
virtualizar os sistemas operacionais convidados. Ele também gerencia e controla os recursos
de hardware que foram disponibilizados e compartilhados entre as máquinas virtuais
(processadores, memória e discos).
Existem duas abordagens para a virtualização. Um tipo de hypervisor (ou monitor de
máquina virtual) denominado hypervisor tipo 1 e um hypervisor tipo 2 (TANENBAUM,
2003). A Figura 1 exemplifica ambos os tipos.
18
Figura 1: (a) paravirtualização (b) virtualização completa – Adaptadade (TANENBAUM, 2003)
1.1.3 Paravirtualização
Na paravirtualização o monitor de máquina virtual é instalado diretamente sobre o
hardware, não havendo entre eles um sistema operacional. Na verdade, ele é o sistema
operacional, já que este é o único programa funcionando no modo núcleo. Sua tarefa é
gerenciar múltiplas cópias do hardware real, denominadas máquinas virtuais
(TANENBAUM, 2003).
Essa característica auxilia o monitor de máquina virtual (hypervisor tipo 1) a
apresentar desempenho muito próximo do desempenho de um sistema nativo, ou seja,
desempenho de uma máquina real. O que proporciona à paravirtualização uma performance
melhor que a virtualização completa. Porém, a parvirtualização apresenta uma limitação que é
a necessidade de o sistema operacional convidado ter seu kernel alterado.
Xen é um monitor de máquina virtual que atua na paravirtualização e na virtualização
completa. Mas neste trabalho, será visto apenas sua atuação na paravirtualização.
1.1.4 Virtualização Completa
Na virtualização completa, ao contrário da paravirtualização, existe um sistema
operacional sobre o hardware real, chamado de sistema operacional hospedeiro. Assim, o
monitor de máquina virtual é instalado sobre este sistema operacional. É simplesmente um
programa do usuário funcionando, digamos, no windows ou no Linux, que funciona como um
‘interpretador’ do conjunto de instruções da máquina e também cria uma máquina virtual
(TANENBAUM, 2003).
KVM Linux é um monitor de máquina virtual baseado no kernel do linux (hypervisor
tipo 1) e atua apenas na virtualização completa. Embora apresente desempenho inferior,
comparado à paravirtualização, a virtualização completa, não exige alterações de kernel dos
sistemas operacionais convidados. Desta forma, pode-se virtualizar o sistema operacional
convidado tal como ele é.
19
1.2 Computação em Nuvem
Computação em Nuvem é, atualmente, um dos assuntos mais abordados na área da
Tecnologia da Informação. A Computação em Nuvem pode ser definida como um modelo que
possibilita acesso, de modo conveniente e sob demanda, a um conjunto de recursos
computacionais configuráveis (por exemplo, redes, servidores, armazenamento, aplicações e
serviços) que podem ser rapidamente adquiridos e liberados com mínimo esforço gerencial ou
interação com o provedor de serviços (MELL; GRANCE, 2011).
A Computação em Nuvem é construída a partir de modelos tecnológicos diversos,
onde conceitos novos e outros antigos formam a base desse complexo ambiente
computacional, formado a partir de tecnologias como sistemas distribuídos, clusters, grids e
middlewares.
A sua característica é fornecer serviços e produtos de Tecnologia da Informação,
como processamento, armazenamento e largura de banda de rede, sob demanda, com baixo
custo. Custo este que deve ser calculado com base no consumo do usuário, tal como a energia
elétrica, gás encanado, entre outros serviços.
O objetivo da Computação em Nuvem é fornecer serviços computacionais via web
ocultando toda a complexidade da execução em camadas inferiores mais próximas ao
hardware (GUARIENTI, 2016). E atender desde o usuário final, aquele que vai utilizá-la para
armazenar seus documentos pessoais, até as grandes empresas, que pretendem terceirizar suas
áreas de Tecnologia da Informação ou, simplesmente, reduzir seus custos com infraestrutura.
Isto é possível, já que toda a responsabilidade com reparos, manutenções, atualizações, entre
outras rotinas mais, é transferida ao provedor (prestador) de serviços de Computação em
Nuvem.
Para ter acesso aos serviços disponibilizados pela Nuvem o cliente necessita apenas de
uma conta de usuário e um dispositivo com acesso à internet. Atendidos estes dois requisitos
básicos, o cliente está apto a consumir os serviços ofertados por meio da web.
Isto implica que a Nuvem precisa lidar com clientes heterogêneos. Há aqueles que se
conectam utilizando dispositivos móveis, com sua ampla variedade de sistemas operacionais.
E há outros que se conectam utilizando notebooks, computadores ou servidores mas que,
20
também, apresentam sistemas operacionais diversos.
A Figura 2 apresenta um exemplo simples mas eficiente da Computação em Nuvem.
Onde percebe-se não apenas a heterogeneidade de sistemas operacionais mas também a
diversificação da capacidade do hardware dos dispositivos envolvidos. Isto deixa claro que
poder de processamento e armazenamento estão disponíveis na Nuvem.
1.2.1 Modelos de Implementação
Segundo (MELL; GRANCE, 2011) há quatro modelos de implementação da
Computação em Nuvem, conforme se segue:
• Nuvem Privada: A infraestrutura de nuvem é provisionada para uso exclusivo de
uma única organização compreendendo vários consumidores (por exemplo,
unidades de negócio). Pode ser propriedade, gerenciada e operada pela
organização, um terceiro, ou alguma combinação dos mesmos, e que podem existir
ou não no local.
• Nuvem Pública: A infraestrutura de nuvem é provisionado para uso aberto pelo
público em geral. Pode ser propriedade, gerenciados e operados por uma empresa,
universidade ou organização governamental ou alguma combinação delas. Ela
existe nas instalações do provedor de nuvem.
• Nuvem Comunitária: A infraestrutura de nuvem é provisionada para uso
exclusivo por uma determinada comunidade de consumidores de organizações que
têm preocupações em comum (por exemplo, missão, requisitos de segurança,
política e considerações de conformidade). Pode ser propriedade, gerenciada e
operada por um ou mais das organizações na comunidade.
• Nuvem Híbrida: A infraestrutura de nuvem é uma composição de dois ou mais
infraestruturas de nuvens distintas (privada, comunidade ou público) que
permanecem entidades únicas, mas são vinculados em conjunto com a tecnologia
padronizada ou proprietária que permite portabilidade de dados e aplicativos (por
21
exemplo, nuvem estourando para balanceamento de carga entre nuvens).
A Figura 2 apresenta uma visão geral de Computação em nuvem.
1.2.2 Características Essenciais
A Computação em Nuvem possui cinco características essenciais, segundo (MELL;
GRANCE, 2011):
• Serviço sob demanda: O usuário pode adquiri recursos computacionais, como
processamento e armazenamento, conforme sua necessidade e
automaticamente, sem a necessidade de interação do usuário com o provedor
de serviços.
• Amplo acesso à rede: O acesso ao recursos da Nuvem não pode forçar o
usuário a alterar seu ambiente. Os recursos precisam estar disponíveis, por
meio de mecanismos padronizados, de tal forma a atenderem clientes de
plataformas heterogêneas, em hardware e software (como, por exemplo
dispositivos móveis, notebooks e desktops).
22
Figura 2: Visão básica de Computação em nuvem. Fonte:http://www.ebah.com.br/content/ABAAABuXAAC/computacao-nuvens-acesso-informaca
• Pool de recursos: Recursos computacionais do provedor são reunidos para
servir vários consumidores usando um modelo multi-tenant, com diferentes
recursos físicos e virtuais dinamicamente atribuído e transferido de acordo com
a demanda do consumidor. Exemplos de recursos incluem o armazenamento,
processamento, memória e largura de banda de rede
• Elasticidade: Os recursos podem ser adquiridos de forma rápida e elástica, em
alguns casos automaticamente, caso haja a necessidade de escalar com o
aumento da demanda, e liberados, na retração dessa demanda. Para os usuários,
os recursos disponíveis para uso parecem ser ilimitados e podem ser adquiridos
em qualquer quantidade e a qualquer momento.
• Serviço Medido: a medição do serviço garante transparência. Os recursos
computacionais utilizados devem ser otimizados, controlados e monitorados.
Os usuários precisam ser informados da medição e devem pagar apenas por
aquilo que consumiram.
1.2.3 Modelos de Serviços
A Computação em Nuvem baseia-se na oferta de uma grande variedade de recursos,
sejam eles hardware e ou software. E é formada por camadas. Segundo (MELL; GRANCE,
2011), a estrutura da Computação em Nuvem é vista formada por três camadas. São elas:
• Software como Serviço (Software as a Service – SaaS): Esta é a camada onde
são disponibilizados softwares e aplicativos específicos, executados na
infraestrutura de Nuvem. As aplicações são acessíveis a partir de vários
dispositivos de cliente, através de uma interface tal como um navegador web
por exemplo, ou uma interface de programa.
• Plataforma como Serviço (Platform as a Service – PaaS): Esta camada é,
normalmente, destinada aos desenvolvedores de soluções para Computação em
Nuvem. Onde podem ser encontrados recursos de programação, bibliotecas e
23
linguagens de programação, entre outros recursos.
• Infraestrutura como Serviço (Infrastructure as a Service – IaaS): Esta é a
camada mais baixa, por meio da qual são disponibilizados os recursos de rede,
processamento e armazenamento. É onde se encontram os recursos de
hardware de forma geral.
A Figura 3 apresenta as três camadas interconectadas logicamente e seus respectivos
atores.
1.3 Sistemas Distribuídos
A computação em Nuvem nos dá a ideia de que utilizamos recursos de uma
infraestrutura capaz de prover recursos ilimitados e de maneira elástica. Assim como em um
sistema distribuído, definido por (TANENBAUM; STEEN, 2007) como um conjunto de
máquinas independentes que se apresentam ao usuário como um sistema único e consistente.
24
Figura 3: Papéis dos atores nas três camadas. Fonte:http://www.ebah.com.br/content/ABAAAfyUkAJ/computacao-nuvens
1.4 Clusters
Clusters são caracterizados pelo agrupamento de vários computadores, através de uma
conexão de rede, podendo estar em um laboratório ou mesmo espalhados por um campus
universitário (DANTAS, 2005). Os computadores integrantes de um cluster são chamados
nós. São utilizados na computação em nuvem para prover recursos computacionais, já que
possuem maior poder computacional.
O conceito de cluster se restringe apenas ao hardware e ao sistema operacional,
necessitando de um ambiente de software (middleware ou ambientes de programação) para
dar origem aos sistemas distribuídos (ALVES, 2008).
Atualmente não existe uma classificação aceita para os clusters (ALVES, 2008). A
Figura 4 apresenta algumas características de clusters.
25
Figura 4: Características dos clusters computacionais – Fonte: (ALVES, 2008).
1.5 Grids
Grids computacionais constituem outra forma de agrupamento de máquinas para
compartilhar recursos. Esse agrupamento representa a interoperabilidade entre ambientes
computacionais heterogêneos dispersos, em que o usuário acessa o ambiente através de uma
interface única (DANTAS, 2005).
Ao contrário dos clusters, os grids não pertencem a uma mesma administração,
podendo ser, inclusive, um consórcio entre instituições (universidades por exemplo). Um grid
computacional pode estar instalado ao redor do mundo, pertencendo várias instituições com
vários usuários. Por esse motivo os grids apresentam grandes complicações, como o
monitoramento de recursos disponíveis, a migração de aplicações e o balanceamento de carga
(ALVES, 2008). Analogia semelhante pode ser feita com Nuvens Híbridas.
1.6 Middlewares
Middlewares podem ser definidos como uma camada de software existente entre as
aplicações do usuário e o sistema operacional, oferecendo certas estruturas de dados e
operações, permitindo o relacionamento, em grupo, de processos e usuários em máquinas
distantes, de modo consistente e uniforme, na presença de diferentes arquiteturas de hardware
e sistemas operacionais (TANENBAUM; STEEN, 2007).
A Figura 5 apresenta um modelo de middleware.
26
1.7 Gerenciamento da Nuvem
Para o gerenciamento da Nuvem foi a plataforma OpenNebula, em função de suas
exigências de hardware serem muito flexíveis. A documentação também foi considerada,
assim como as opções de suporte técnico, que é feito através do fórum da comunidade, com
participação dos desenvolvedores.
A quantidade mínima de máquinas para infraestrutura na plataforma OpenNebula é de
duas máquinas (um host e um front-end). É possível se utilizar apenas uma máquina, que faria
os papéis de host e front-end, simultaneamente. Porém, esta prática não é recomendada por
seus desenvolvedores.
1.7.1 Principais Características do Gerenciamento com o OpenNebula
O OpenNebula se mostra uma plataforma estável, escalar, segura e elástica.
Disponibiliza diversas ferramentas e interfaces, que não apenas ajudam a organizar mas
também tornam as operações mais fáceis e simples. Nativamente, o OpenNebula suporta os
monitores de máquina virtual: KVM Linux, Xen e VMware. E diversas opções de autenticação
27
Figura 5: Middleware em um Sistema Distribuído – Fonte: Adaptado de(TANENBAUM; STEEN, 2007).
e de sistemas de arquivos para os datastores11.
A Figura 6 apresenta os módulos que formam o núcleo do OpenNebula.
Outro recurso importante de grande utilidade é a interoperabilidade com outras
Nuvens como Amazon12 EC2, Microsoft13 Azure e IBM14 Softlayer, através do Cloud Bursting
(Nuvem de ruptura). Este recurso vai de encontro a característica da computação em nuvem,
garantindo escalabilidade e expansão do pool de recursos da Nuvem.
A transparência aos administradores da nuvem vem do fato de que uma região AWS
EC2, SoftLayer datacenter ou um local Azure é modelado como qualquer outro host (embora
potencialmente com uma capacidade muito maior), então o programador pode colocar uma
máquina virtual na nuvem externa da mesma forma como ele vai fazer em qualquer outro host
local (OPENNEBULA, 2016).
Cloud Bursting é um modelo em que os recursos locais de uma nuvem privada são
combinados com recursos de provedores de nuvem remotos. O provedor remoto pode ser um
11 Armazenam imagens e arquivos diversos relacionados às imagens de máquinas virtuais.12 http://aws.amazon.com13 http://www.microsoft.com/Azure14 http://www.softlayer.com
28
Figura 6: Estrutura básica do OpenNebula. Fonte: (OpenNebula, 2016).
serviço de nuvem comercial, como Amazon EC2, IBM SoftLayer ou Microsoft Azure. O apoio
prestado a estouro de nuvem permite ambientes de hospedagem altamente escaláveis
(OPENNEBULA, 2016).
A Figura 7 apresenta o modelo Cloud Bursting (Nuvem de ruptura).
1.7.2 Principais Funções e Ferramentas
O gerenciamento da Nuvem com OpenNebula é simplificado pela interface limpa e
intuitiva da plataforma. Suas principais funções e ferramentas são:
• Catálogos imagens: é uma coleção das imagens para implementação das
máquinas virtuais.
• Catálogos de redes: é uma coleção de redes virtuais, com o IPv4, IPv6, ou
redes mistas, que possibilita o isolamento completo entre redes virtuais.
• Catálogo de templates: é uma coleção de templates, criados a partir das
imagens armazenadas no(s) Datastore(s), são, na verdade, padrões de
máquinas virtuais previamente configuradas, aguardando o memento de
serem instanciadas.
• Monitoramento e controle de recursos virtuais: são ferramentas utilizadas
no controle do ciclo de vida das máquinas virtuais que estão em execução.
29
Figura 7: Cloud Bursting ou Nuvem de Ruptura. Fonte: (OPENNEBULA, 2016).
• Monitoramento da Nuvem e Controle de Aplicações: são ferramentas que
permite gerenciar aplicações elásticas multicamadas.
• Usuários e Grupos: Ferramenta utilizada para gerenciar grupos e usuários.
Possui características como ACL15 refinada para alocação de recursos e
gerenciamento de cotas de recursos para controlar e limitar processamento,
armazenamento e rede de utilização.
• Hosts: ferramenta para a completa gestão dos hosts físicos na nuvem.
• Monitoramento: faz o monitoramento constante de recursos virtuais,
através de indicadores de desempenho (processamento, memória e
armazenamento, entre outras funcionalidades).
• Contabilidade: Um sistema configurável para visualizar e reportar os dados
de uso de recursos, para permitir tarifação, ou para garantir parte justa dos
recursos entre os usuários.
• Networking: é um subsistema de rede personalizável, cuja finalidade é
integrar com os requisitos específicos da rede de centros de dados
existentes, para permitir o isolamento total entre as máquinas virtuais que
compõem um serviço virtualizado.
• Armazenamento: dá suporte a vários tipos de armazenamentos de dados.
Proporcionando flexibilidade no planejamento da infraestrutura de
armazenamento e benefícios com relação ao desempenho.
• Segurança: Os recurso de segurança estão espalhados por vários
subsistemas: como nos mecanismos de autenticação e autorização.
Utilizando ACLs permite o gerenciamento de qualquer recursos.
• Alta disponibilidade: possui suporte às arquiteturas de alta disponibilidade
com comportamento configurável.
• Clusters: são agrupamentos de computadores (hosts) que compartilham
armazenamentos de dados e redes virtuais, proporcionando balanceamento
de carga, alta disponibilidade e computação de alto desempenho.
15 Lista de Controle de Acesso (Access Control List)
30
1.8 Tecnologia de Containers
A tecnologia de containers não é uma tecnologia nova. Já fora implementada no
FreeBSD16 Jails e no OpenVZ17, um dos pioneiros no uso da tecnologia LXC18(Linux
Container).
LXC é o conjunto bem conhecido de ferramentas, modelos, biblioteca e ligações de
linguagem. É muito baixo nível, muito flexível e abrange praticamente todas as características
de contenção suportada pelo kernel upstream (LINUX CONTAINERS, 2016).
A tecnologia LXC utiliza cgroups e namespace. O cgroups é uma característica do
Kernel Linux que provê mecanismos para organização de processos em forma de grupos e
limita recursos de máquina, como consumo de processador, memória e entrada/saída (E/S).
Namespace é uma característica que permite o sistema criar diversos contextos diferentes em
um mesmo sistema, o que permite criar diferentes ambientes independentes que são
executados no mesmo sistema base.
Um container é uma forma de virtualização no nível do sistema operacional, um
ambiente totalmente isolado, simulando um sistema independente no mesmo host. Tornando,
assim, possível executar aplicações com todas as configurações necessárias (variáveis de
ambiente, pacotes etc.) e todas as suas dependências com o mínimo de impacto (DOCKER,
2016).
Um container pode ser construído, iniciado, parado e removido do sistema.
Normalmente, um container é construído e iniciado muito rapidamente. Mas a principal
característica de um container é ser parado ou descartado quando a aplicação é finalizada.
Assim, a tecnologia de containers auxilia na otimização dos recursos computacionais. A
utilização de containers oferece outros benefícios como o isolamento e alocação semelhantes
aos de máquinas virtuais, mas uma abordagem de arquitetura diferente lhes permite ser muito
mais portátil e eficiente.
Containers não exportam portas para o mundo real nem tão pouco para outros
16 https://www.freebsd.org17 https://openvz.org18 https://linuxcontainers.org
31
containers, apenas para o host hospedeiro. Cada container possui um endereço ip19 virtual. É
possível “linkar” containers entre si, permitindo, assim, a comunicação entre eles.
Para utilização da tecnologia de containers foi escolhido o Docker. Em função deste
oferecer comandos mais simplificados, em relação ao LXC, e porque a plataforma
OpenNebula oferece em seu Marktplace imagens de máquinas virtuais com o Docker.
Desenvolvido na linguagem Go, o Docker teve seu projeto foi iniciado em 2013. É um
software muito dinâmico, no ano de 2015 começou na versão 1.5 e no fim do mesmo ano
estava na versão 1.9. Atualmente encontra-se na versão 1.11.
Pode-se conceituar o Docker como um conjunto de tecnologias utilizadas para a
construção de containers, é baseado na tecnologia LXC. Uma desvantagem no uso da
tecnologia de containers é que ela, ainda, não oferece interface gráfica. Logo, todo o trabalho
precisa ser executado por meio da linha de comando. Porém, o Docker possui uma
programação mais amigável e permite obter os mesmos resultados que o LXC com menos
esforço.
Docker é uma plataforma aberta para o desenvolvimento, transporte e execução de
aplicativos. Na sua essência, o Docker fornece uma maneira de executar praticamente
qualquer aplicação segura isolada em um container. O isolamento e segurança permitem que
se executem muitos containers simultaneamente em um mesmo host (DOCKER, 2016).
1.8.1 Diferença entre Máquina Virtual e Container
Na virtualização completa, tem-se um host hospedeiro e um sistema operacional, sobre
qual é instalado um monitor de máquina virtual. As funções do monitor de máquina virtual
são, basicamente, gerenciar os recursos disponibilizados, implementar e gerenciar as
máquinas virtuais. Cada máquina virtual possui um sistema operacional, sobre o qual são
instalados arquivos binários, bibliotecas, aplicativos, entre outros.
A tecnologia de containers, implementa um sistema de arquivos multicamadas, que
possui características de herança e compartilhamento. Desta forma, os containers, construídos
19 Protocolo internet (internet protocol).
32
por meio da mesma imagem, compartilham a mesma base. Assim, um container precisa
apenas ter instalados os arquivos binários necessários a correta execução de seus aplicativos.
A Figura 8 exemplifica tal diferença.
Outra comparação interessante pode ser observada na Tabela 1, onde são comparadas
as imagens de máquinas virtuais e containers. Estas informações foram obtidas durante
manipulação de imagens do OpenNebula e do Docker.
Tabela 1: Comparação de tamanho de imagens
IMAGEM TAMANHO
Máquina Virtual De 5GB a 10GB
Container (com aplicação) De 65MB a 600 MB
1.8.2 Diferença entre Containers LXC e Docker
Containers LXC são como máquinas virtuais com um sistema operacional totalmente
funcional e cada container possui o seu sistema operacional. Enquanto containers Docker são
33
Figura 8: Diferença entre (a) Máquinas Virtuais (b) Containers. Fonte: (DOCKER, 2016).
projetados para suportar uma única aplicação, e suas dependências, e compartilham a mesma
imagem base.
Quanto a persistência de dados, em LXC, podem ser armazenados no próprio
container ou no host. Com Docker, para que se possa garantir a persistência dos dados é
preciso armazená-los fora do container, utilizando a função volumes.
Com LXC os containers são construídos com baixo acoplamento, enquanto no
Docker containers são construídos em camadas somente leitura.
LXC possui comandos verbosos, portanto, pouco amigáveis, enquanto Docker possui
uma linha de comandos amigáveis e de fácil utilização.
1.9 Estrutura do Docker
Docker usa uma arquitetura cliente-servidor, onde o cliente e o servidor podem ser
executados no mesmo sistema, mas tem-se a opção de um cliente Docker poder ser conectado
remotamente a um servidor Docker (DOCKER, 2016). Seus três componentes básicos são:
• imagens: imagens podem conter um sistema operacional e aplicações. É por
meio de uma imagem que se constrói um ou mais containers.
• registros: armazenam imagens públicas e privadas que podem ser adquiridas e
utilizadas na construção de containers.
• containers: podem ser comparados a uma pasta ou diretório. Um container
Docker mantém tudo o que é necessário para que uma aplicação possa ser
executada. Cada container é criado a partir de uma imagem Docker.
A Figura 9 mostra a estrutura do Docker.
34
O registro público do Docker é fornecido com o Docker Hub . Ele serve uma enorme
coleção de imagens existentes (DOCKER, 2016). Estas imagens podem ser oficias do Docker,
ou criadas e disponibilizadas por usuários da comunidade.
Containers oferecem um ambiente tão perto possível, do que se deseja obter a partir de
uma máquina virtual, mas sem a sobrecarga que vem com o funcionamento de um kernel
separado e simulando todo o hardware (DOCKER, 2016).
No caso do Docker, especificamente, ele oferece mecanismos que permitem controlar
CPU e memória utilizados pelos containers. Este controle pode ser definido no momento que
o container é instanciado. Após a versão 1.10 foram implementados novos recursos que
permitem alterar o número máximo de processadores e quantidade de memória que um
container pode utilizar, mesmo com ele em execução.
O Docker possui modelo de sistema de arquivos multicamadas e a ideia de herança e
compartilhamento. É criada uma camada sobre o bootfs20 e sobre esta camada é construído o
container, a partir de uma imagem com um sistema operacional e aplicações. A partir de
então, para qualquer container que for construído com base na mesma imagem, neste host,
será construído um container isolado e independente dos outros já construídos, porém sobre a
mesma imagem base. Gerando economia de recursos como espaço em disco, processamento e
memória.
20 Onde fica de Boot do sistema e o Kernel Linux.
35
Figura 9: Estrutura do Docker. Fonte: (DOCKER, 2016).
A Figura 10 apresenta o sistema de arquivos multicamadas do Docker.
1.9.1 Funções
O Docker possui algumas funções muito interessantes, são elas:
• Volumes de dados: função que proporciona persistência de dados, já que
containers são projetados para descartados ao final da aplicação.
• Mapeamento de portas: por padrão containers Docker não exportam suas
portas para o mundo real, elas são expostas e mapeadas apenas para o host
hospedeiro.
• Link entre container: containers podem ser “linkados”, uns aos outros,
proporcionando comunicação direta entre eles.
• Construtor Dockerfiles: trata-se de um poderoso script, onde são inseridos
comandos do Docker e também do Linux, para execução de tarefas na
construção de containers. O Dockerfiles é utilizado para personalizar e
automatizar a construção de containers e também para criar e alterar
imagens.
36
Figura 10: Sistema de arquivos multicamadas. Fonte: (DOCKER, 2016).
1.9.2 Ferramentas
E entre as principais ferramentas do Docker destacam-se:
• Docker Hub: serviço de registro e hospedagem de imagens;
• Docker Machine: Automatiza o provisionamento de containers na rede
ou na Nuvem;
• Docker Swarm: utilizada para criar clusters. A imagem é construída pelo
Docker e atualizada regularmente através de uma compilação
automatizada. A imagem tem várias opções e subcomandos que podem
ser usados para criar e gerenciar um cluster Swarm;
• Docker Compose: é uma ferramenta para definição execução de
aplicativos multi containers. Esta ferramenta possui comandos para
acompanhar todo o ciclo de vida de uma aplicação. Pode ser definido
como um processo de três etapas:
1. Definir o ambiente da aplicação com um auxílio do script
Dockerfile;
2. Definir os serviços que compõem a aplicação em docker-
compose.yml para que eles possam ser executados em
conjunto em um ambiente isolado;
3. Por último, executa docker-compor-se, assim, o compose
inicia e executa o aplicativo.
37
2 MATERIAS, TÉCNICAS E MÉTODOS
Para realização deste trabalho foram utilizados recursos da infraestrutura de
Tecnologia da Informação (TI) do Instituto de Computação da Universidade Federal de Mato
Grosso – UFMT. Onde a infraestrutura conta com a proteção de nobreaks21, firewall22 e
proxy23 reverso.
2.1 Materiais Utilizados
Para construir a infraestrutura de Nuvem Privada, foram implementados um front-
end e dois Hosts. Para front-end foi utilizado um microcomputador Lenovo (desktop24) e para
os Hosts foram utilizados dois servidores. Front-end e Host foram interconectados à rede
local, do Instituto de Computação. A rede possui velocidade de 1 (um) Gigabit por segundo
(Gbps). As especificações de configuração dos equipamentos são as seguintes:
front-end:
• Processador intel Core 2 Duo,
• 01 HD SATA 160 GB,
• 4 GB de memória RAM,
• 1 Interface de rede de 1 Gbps
Host1 e Host2:
• Processador intel Xeon Octa Core,
• 04 HD’s SAS 160GB em modo Raid
21 Equipamento capaz de fornecer energia elétrica temporariamente, a partir do uso de baterias.22 Hardware ou software que define se determinado conteúdo é permitido ou não no tráfego de dados com
destino ou origem da rede local (GUARIENTI, 2016).23 Recurso de segurança que impede um usuário de acessar diretamente um servidor de páginas da Internet,
criando uma camada adicional nessa conexão (GUARIENTI, 2016).24 Microcomputador de mesa.
38
• 8 GB de memória RAM,
• 2 Interfaces de rede de 1 Gbps
2.2 Instalação da Plataforma OpenNebula
A plataforma OpenNebula, utilizada neste trabalho, está na versão 4.14.2 e possui
como componentes básicos para sua implementação:
• Front-end: responsável por executar os serviços do OpenNebula, é ele
quem faz todo o gerenciamento da Nuvem.
• Hosts: eles hospedam as máquinas virtuais, são responsáveis por prover
os recursos necessários, como, por exemplo, processamento e
armazenamento.
• Datastores: armazenam as imagens base das máquinas virtuais.
• Rede física: provê a interconexão entre front-end e hosts.
2.2.1 Instalação e configuração do Front-end
O front-end foi configurado no microcomputador Lenovo (desktop), com sistema
operacional Ubuntu Server 14.04 LTS e os serviços do OpenNebula (opennebula e
opennebula-sunstone). Também foi instalado o nfs-kernel-server do Linux para que o diretório
dos Datastores fosse compartilhado com os hosts. O sistema operacional Ubuntu Server
14.04 LTS foi escolhido por ser indicado na documentação do OpenNebula e amplamente
utilizado no meio acadêmico.
Durante a instalação é criada, automaticamente, uma senha para o usuário
administrativo oneadmin.
39
Imediatamento após a instalação, conforme orientações da documentação da
plataforma, a pasta onde são armazenados os Datastores foi compartilhada via NFS do Linux.
Também foi configurada a chave pública (public key) para permitir que front-end e hosts
possam se comunicar sem senha, por SSH25.
Foi criado um quarto Datastore personalizado que recebeu o nome de nfs-imagens,
destinado ao armazenamento de imagens de máquinas virtuais. Este Datastore possui
propriedades idênticas a do Datastore Default. Assim, na construção desta Nuvem, foram
utilizados tanto o Datastore nfs-imagens como o Datastore Default.
2.2.2 Instalação dos Hosts
Os hosts, assim como o front-end, foram configurados com o sistema operacional
Ubuntu Server 14.04 LTS. Após a instalação do sistema operacional, foi instalado o monitor
de máquina virtual KVM Linux, e todas as suas dependências. O KVM é um dos três monitores
de máquina virtual suportados pela plataforma. Em seguida foi instalado o opennebula-node.
2.2.3 Considerações finais sobre a instalação da plataforma
Todos os Datastores foram armazenados no front-end, como configuração padrão do
OpenNebula. O endereço base para os Datastores é /var/lib/one/datastores. Eles são
armazenados como diretórios ou pastas. Cada Datastore possui uma pasta, que recebe como
nome o ID do Datastore. Por exemplo, os Datastores system, default e files, padrão da
plataforma, recebem ID 0 (zero), 1 (um) e 2(dois), respectivamente. O primeiro Datastore
criado manualmente, recebe ID igual a (100) cem. Assim, os próximos Datastores que forem
criados receberão o ID do anterior incrementado em 1 (um).
Com relação à rede, tanto front-end quanto os hosts foram configurados para operar
25 Secure Shell é, ao mesmo tempo, um programa de computador e um protocolo de rede que permitem aconexão com outro computador na rede de forma a permitir execução de comandos de uma unidade remota.
40
com endereço IP atribuído por DHCP26. A rede do Instituto de Computação possui servidor
DHCP, que será o responsável por atribuir o endereço IP ao front-end e aos hosts.
Assim que é carregado e começa a operar o front-end ativa sua função de
monitoramento, que varre o sistema o tempo todo. Sua função é verificar hosts, Datastores,
imagens, máquinas virtuais em execução, entre outras mais.
Portanto faz-se necessário efetuar a cópia da chave pública (public key) do front-end
para os hosts, garantindo a comunicação sem senha por ssh.
Com o front-end em operação todas as funções e ferramentas do OpenNebula podem
ser acessadas pela interface web. É preciso um computador com interface gráfica, um
navegador web. Será solicitado nome e senha para acesso. Deve-se utilizar o usuário
administrativo oneadmin e a senha criada automaticamente durante a instalação.
A Figura 11 apresenta a página de logon mostrada ao usuário que acessa o front-end
via web.
26 Protocolo de configuração Dinâmica de Máquina (Dynamic Host Configuration Protocol).
41
Figura 11: Tela de logon.
2.3 Instalação da Tecnologia de Containers
Para a instalação da tecnologia de containers, a ser implementada com o Docker,
foram utilizadas, inicialmente, duas máquinas virtuais.
As máquinas foram acessadas via web, especificamente por meio da interface do
opennebula-sunstone. O sistema operacional Ubuntu Server 14.04 LTS foi atualizado,
incluindo na lista de repositórios o Docker. Em seguida, foram verificadas as dependências
para instalação, que foi concluída com sucesso.
Com o Docker instalado e iniciado, foram adquiridas, por meio Docker-Hub,
seguintes as imagens:
• sameersbn/MySQL :latest: com última versão do SGBD27 MySQL ,
• sameersbn/redmine:3.1.1-3: com a versão 3.1.1-3 da aplicação Redmine.
• dell/wordpress: versão da aplicação wordpress, compartilhada pela
Comunidade Dell.
A Figura 12 apresenta as imagens sameersbn/MySQL:latest e
sameersbn/redmine:3.1.1-3, armazenadas na máquina virtual, ID 77.
27 Sistema Gerenciador de Banco de Dados
42
Figura 12: Imagens sameersbn/MySQL :latest e sameersbn/redmine:3.1.1-3.
A Figura 13 apresenta a imagem dell/wordpress, armazenada na máquina virtual ID
78, obtida por meio do comando docker images.
Na máquina virtual ID 77 foram criados dois containers, um para o banco de dados
MySQL e outro para a aplicação Redmine. A máquina virtual foi instanciada com um
processador e 2GB (gigabytes) de memória RAM.
Com relação à persistência de dados, foi utilizada a função de volume de dados. A
pasta /var/lib/MySQL/ da máquina virtual foi mapeada para a pasta /var/lib/MySQL/ do
container. Desta forma, o banco de dados gravará seus arquivos na pasta do MySQL, da
máquina virtual e não no container. Esta função garante a persistência dos dados, caso o
container seja descartado.
Na máquina virtual ID 78 foi criado apenas um container, baseado na imagem
dell/wordpress, onde são executados a aplicação wordpress e o SGBD MySQL. Também neste
container, foi utilizada a função de volumes de dados, a fim de garantir a persistência de
dados.
43
Figura 13: Imagem dell/wordpress.
3 RESULTADOS
Nesta seção são apresentados os resultados obtidos com a instalação e utilização da
plataforma OpenNebula e da tecnologia de containers. Para se tirar proveito da migração on-
line, permitida pela virtualização com KVM Linux, a tecnologia de containers foi utilizada em
máquinas virtuais. São apresentados argumentos e Figuras que demonstram graficamente os
resultados.
3.1 Plataforma OpenNebula
A plataforma foi instalada com sucesso, os hosts foram integrados ao front-end com
mínimo esforço. Foram criados apenas usuários administrativos. A plataforma OpenNebula,
como já dito anteriormente, possui uma organização de usuários e grupos, baseada em listas
de acessos (ACLs) muito eficiente, que garantem que usuários só terá acesso à aquelas
funções para as quais recebeu permissões específicas.
A Figura 14 mostra como ficou a organização da plataforma.
44
Figura 14: Infraestrutura (front-end e hosts). Fonte: (OPENNEBULA, 2016).
O front-end armazena os Datastores, que podem ser configurados com drivers SSH
ou shared (compartilhamento).
Com a utilização de drivers de transferência SSH, não é preciso nenhum tipo de
compartilhamento. A cópia das imagens do front-end para os hosts é feito por SSH. É este o
padrão da plataforma OpenNebula. Embora, muito prática, esta abordagem limita a migração
de máquinas virtuais à migração off-line, ou seja, as máquinas só podem ser migradas quando
estiverem desligadas.
Para a utilização de drivers de transferência shared (compartilhamento) no
Datastore, foi utilizado o NFS28 (nfs-kernel-server) do Linux. Sendo necessário, para tanto,
compartilhar a pasta onde estão armazenados os Datastores, no front-end, e montar o volume
em cada um dos hosts. Esta abordagem possibilita a utilização da migração on line. Assim,
pode-se migrar as máquinas virtuais mesmo quando elas estão em execução.
A Figura 15, apresenta os Datastores com seus atributos (ID, proprietário, grupo,
nome, capacidade de armazenamento, cluster, tipo e status).
28 Sistema de Arquivos de Rede (Network File System)
45
Figura 15: Datastores
Na Figura 16 apresenta o Datastore nfs-imagens. Pode-se observar na aba info
informações como ID do Datastore, se ele faz parte de um cluster, o seu status, tipo de
arquivo que armazena, neste caso é do tipo imagem. Também podem ser vistos o caminho
padrão para o Datastore no sistema de arquivos, assim como os atributos como, por exemplo
o TM_MAD do tipo shared (compartilhamento). E acessando a aba Images são mostradas
todas as imagens armazenadas nesse Datastore.
A Figura 17 apresenta a interface do Marketplace, a loja da plataforma que
disponibiliza diversas imagens, gratuitamente. São dezenas de imagens de diversos sistemas
operacionais, nos formatos qcow2 e raw. Algumas imagens são exclusivas para KVM Linux,
outras para VMware e outras para Xen. Há também aquelas que podem ser usadas com
qualquer um dos três monitores de máquina virtual. Ao encontrar a imagem desejada, basta
clicar sobre ela e em seguida no botão import.
46
Figura 16: Atributos, permissões e informações do Datastore nfs-imgens
O próximo passo é selecionar o Datastore onde a imagem deve ser armazenada e
novamente clicar no botão import. A partir de então, é iniciado o download da imagem.
A Figura 18 mostra a escolha do Datastore.
47
Figura 17: Marketplace
Figura 18: Escolha do Datastore na importação de imagens do Marketplace
Terminado o download da imagem ela recebe o status READY, isto significa que a
imagem está pronta e disponível para ser instanciada. Quando ela está sendo utilizada, seu
status é alterado para USED.
Conforme pode ser visto na Figura 19, cada imagem possui ID, proprietário, grupo,
nome, Datastore, tipo, status e a informação de quantas máquinas virtuais foram
implementadas a partir da imagem. Há, ainda, a opção de clonar imagens.
A Figura 20 mostra uma relação de templates configurados e prontos para serem
instanciados.Templates são modelos de máquinas virtuais, padrões de máquinas virtuais
previamente configuradas, aguardando o memento de serem instanciadas. É através de um
template que se aplica as configurações à máquina virtual.
48
Figura 19: Imagens
Figura 20: Relação de templates
Por meio de templates é que se define qual a quantidade de processadores e memória
quer serão alocados para a máquina virtual, assim como o monitor de máquina virtual
responsável pela virtualização, conforme a Figura 21.
É por meio dos templates, também, que se escolha o host hospedeiro, assim
como a imagem que será utilizada para criar a máquina virtual.
A Figura 22 apresenta a escolha do host hospedeiro.
49
Figura 21: Templates – configurando CPU, memória e hypervisor.
Templates têm, ainda, a função de preparar a máquina virtual para ser migrada para
outra Nuvem (Microsoft Azure, Amazon EC2 ou IBM Softlayer), conforme pode ser visto na
Figura 23.
50
Figura 23: Participação em Nuvem Híbrida.
Figura 22: Escolha do host hospedeiro
Outra opção oferecida pelos templates é a configuração de rede para a máquina
virtual. Podem ser criados diversos templates, que atendam a várias redes. E é por meio deles
que se define em que rede uma determinada máquina virtual será conectada. A escolha do
template de rede pode ser feita na aba Networking do Update VM Template, conforme pode
ser visto nas Figuras 21, 22 e 23.
E possível criar e configurar templates de redes virtuais acessando o menu
Infraestructure e selecionando a opção Virtual Networks (redes virtuais), conforme mostra a
Figura 24.
A Figura 25 mostra as informações, permissões e atributos de um determinado
template de rede. Nos atributos podem ser vistos a placa de rede virutal Bridge br0, gateway,
endereço de rede (network address), a máscara de rede (network mask) e outras como VLAN e
VLAN ID.
51
Figura 24: Templates de redes virtuais.
Selecionando a aba Address tem-se acesso aos ranges de rede. Selecionando um
desses ranges obtêm-se informações como tipo de endereçamento IP (IPV4 ou IPV6), o
endereço IP inicial e final, a quantidade de endereços IP disponibilizados para o range
selecionado, entre outros.
A Figura 26 mostra as opções da aba Address.
52
Figura 25: Informações, permissões e atributos para template de rede.
Com relação às máquinas virtuais instanciadas, neste trabalho, foram configuradas
para utilizar endereço IP atribuído por DHCP. Sendo utilizado, neste caso, o template de rede
virtual ID 1, de nome ic.
Foram criadas e instanciadas máquinas virtuais com sistemas operacionais de
servidores Linux (CentOS, Debian e Ubuntu). Mas nada impede que sejam instaladas
máquinas virtuais com sistema operacionais de desktop.
A Figura 27 mostra as máquinas virtuais. A plataforma OpenNebula disponibilizas
diversas ferramentas para manipulação das máquinas virtuais como, por exemplo, iniciar,
migrar, pausar e remover (deletar), acessar, entre outras mais.
53
Figura 26: Informações do range de endereços IP.
Por padrão, as máquinas virtuais só podem ser acessadas por ssh, pelo front-end
utilizando-se o usuário administrativo oneadmin. Os outros usuários, ainda que façam parte
do grupo administrativo oneadmin, precisam acessá-las pela interface web.
Como pode ser observado na Figura 27, à direita, logo depois do endereço IP da
máquina virtual, há um ícone de computador na cor azul. Clicando sobre este ícone, é aberta
uma nova aba, no navegador web, onde a máquina virtual é disponibilizada, conforme mostra
a Figura 28.
54
Figura 27: Máquinas Virtuais.
Quanto ao hosts, a plataforma disponibiliza controles eficientes e de fácil operação. Os
hosts fazem parte do menu infraestructure (infraestrutura). Neste menu tem-se acesso a todas
as informações referentes aos hosts. A Figura 29 mostra os hosts 1 e 2. Nela podem ser
observadas informações tais como, o número de máquinas virtuais alocadas em cada host, a
utilizão de CPU e memória, assim como o status do host.
Figura 29: Hosts
55
Figura 28: Acesso à máquina virtual
Outras informações sobre um host podem ser obtidas, clicando sobre ele, o resultado
e mostrado na Figura 30. Na aba info observa-se o ID, nome, status, o tipo de monitor de
máquina virtual que o host utiliza, sua capacidade e alocação de memória, CPU e
armazenamento do Datastore. Podem ser observados, ainda, a arquitetura do host, velocidade
e nome do modelo do processador.
Na aba Graphs, capacidade e alocação de memória e CPU, são apresentados em dois
gráficos distintos. Na aba Vms são fornecidas informações sobre as máquinas virtuais
hospedadas no host.
56
Figura 30: Informações, permissões e atributos de um host
Pode-se, ainda, utilizar a opção Dashboard do menu para obter informações
detalhadas em forma de gráficos. Neste caso, as informações não se limitam apenas aos hosts,
são apresentadas informações sobre as máquinas virtuais, usuários, imagens de máquinas
virtuais e redes virtuais, conforme pode ser visto nas Figuras 31 e 32.
Figura 31: Dashboard para máquinas virtuais e hosts.
São informações detalhadas sobre o consumo diário das máquinas virtuais com
relação a CPU, memória e disco, medidos por hora.
O número total de máquinas virtuais e hosts, número de máquinas e hosts ativos,
inativos e apresentaram erro.
Na Figura 32, é informado o número de usuários, o número de imagens e o espaço
em disco consumido por elas e, ainda, o número de redes virtuais e o número de endereços IP
utilizados. São mostradas, ainda, informações detalhadas sobre o consumo diário dos usuários
57
com relação a CPU, memória e disco, medidos por hora.
3.2 Tecnologia de Containers
Esta subseção apresenta os resultados alcançados com a tecnologia de containers,
implementado com o Docker, que foi instalado em duas máquinas virtuais.
Containers (LXC e Docker) não possibilitam a migração on-line. Caso seja necessário
transferir o container para outro host (físico ou virtual) é necessário efetuar o backup do
container e restaurá-lo em outro host. O que significa que os serviços disponibilizados pelo
container seriam parados, causando indisponibilidade. Por este motivo, os container foram
construídos em máquinas virtuais, que oferecem a possibilidade de migração enquanto as
58
Figura 32: Dashboard para usuários, imagens e redes virtuais.
máquinas estão em execução, evitando, assim, a indisponibilidade dos serviços ou recursos.
Com a tecnologia de containers tem-se acesso a um recurso interessante, que é a
possibilidade de se limitar a quantidade máxima de memória e CPU que um container pode
utilizar. No Docker este recurso está disponível a partir da versão 1.10.
Containers não exportam suas portas para o mundo real, apenas para o host onde
estão hospedados. Então, na construção de container é feito um mapeamento entre as portas
do host hospedeiro e as portas dos container.
A máquina virtual ubuntu_docker ID 77, foi configurada com a tecnologia de
containers, e executa a aplicação Wordpress (servidor apache + Banco de dados MySQL).
Neste caso, as portas 80 e 3306 do container foram mapeadas para as portas 80 e 3306 da
máquina virtual, respectivamente.
Enquanto a máquina ubuntu_docker ID 78, foi configurada com dois containers, um
deles executando a aplicação Redmine e o outro executando o banco de dados MySQL,
necessário ao funcionamento do Redmine. Assim, foi preciso “linkar” estes containers. A
porta utilizada pelo banco de dados MySQL não foi mapeada com o host, porque para este
container não vai ser necessário exportar nenhuma porta. A aplicação Redmine conseguirá
utilizar o banco de dados MySQL através da porta padrão, graças ao “link” criado entre os dois
containers.
Uma característica que chama a atenção, na utilização de containers, é o pouco
tempo que um container leva para ser construído e entrar em operação. Quando um container
é construído pela primeira vez, há a dependência do downalod da imagem. Mas construir um
ou mais containers a partir de imagens armazenadas localmente é muito rápido.
A Figura 33 mostra o resultado de um comando solicitando que sejam apresentados
todos os containers ativos e inativos, neste caso na máquina virtual ID 77. Nesta máquina
virtual há apenas um container. Nesta mesma Figura podem ser observadas outras
informações como ID, nome da imagem de origem, mapeamento de portas e protocolos
utilizados, entre outras informações.
Uma opção muito interessante na tecnologia de containers quanto ao mapeamento de
portas, é possibilidade de definir qual rede o container atenderá. Na Figura 33 observa-se que
no redirecionamento das portas 80 e 3306, o endereço IP é 0.0.0.0, ou seja, o container vai
atender às solicitações de qualquer rede, nas portas 80 e 3306. Se esse endereço IP é alterado,
59
o container passa a responder apenas às solicitações, oriundas dessa nova rede. Este recurso é
importante quando se deseja restringir o acesso ao recurso ou serviço, ou para aumentar a
segurança. Para tanto foi utilizado o comando docker ps -a.
A tecnologia de containers permite, ainda, que eles sejam monitorados em tempo
real, por meio do comando docker stats. A Figura 34 mostra o monitoramento em tempo real
executado para os containers da máquina virtual ID 78. Podem ser observadas informações
importantes quanto a utilização de CPU, uso e limite de memória, assim como informações de
entrada e saída (E/S) de rede e disco.
Com os containers construídos e ativos, pode-se verificar a disponibilidade dos
serviços Wordpress e Redmine. Com um navegador web, basta digitar no campo endereço, o
IP da máquina virtual e a porta do serviço, em ambos os casos foi utilizada a porta 80. A
60
Figura 33: Redirecionamento de portas do Container Wordpress
Figura 34: Monitoramento em tempo real de containers.
Figura 35 mostra a aplicação Wordpress em execução.
A aplicação Redmine também foi testada com sucesso. A Figura 36 mostra a
aplicação em execução. Pode ser observado na tela a apresentação dos dois projetos criados
anteriormente.
61
Figura 35: Wordpress executado a partir de container.
Figura 36: Redmine executado a partir de um container.
3.3 Persistência de dados
Um site foi configurado a partir da ferramenta Wordpress com o nome IC-UFMT e
cadastrado dois usuários. Na aplicação Redmine foram criados dois projetos, Testando
migração e Programa de estágio, e ainda, dois usuários. A finalidade era verificar a
persistência de dados.
Os testes de persistência de dados ocorreram normalmente e com sucesso, para as
duas aplicações testadas, Wordpress e Redmine.
No primeiro teste, os container foram parados e, posteriormente, reiniciados. Então
as aplicações foram testadas quanto a persistência dos dados. No site configurado com a
ferramenta Wordpress, os logins dos usuários, previamente, criados não foram alterados ou
apagados. O login ocorreu normalmente. No Redmine os logins dos usuários, também,
funcionaram normalmente, e os dois projetos continuaram sendo exibidos na página principal.
No segundo teste, os containers foram parados e descartados, assim como suas
imagens. Ao reconstruí-los e executar as aplicações percebeu-se que os dados haviam
persistido.
3.4 Migração on-line
Para efetuar os testes de migração on-line, foram utilizadas as máquinas virtuais ID
77, hospedada no host2 e ID 78, hospedada no host1. As aplicações Wordpress e Redmine
foram executadas. Enquanto a aplicação Wordpress era utilizada, a máquina virtual ID 77,
que a hospeda, foi migrada do host2 para o host1. Em um terminal Linux, foi disparado o
comando ping contra a máquina virtual ID 77. Enquanto a migração ocorria, as páginas do
Wordpress foram acessadas normalmente. A Figura 37 apresenta parte dos pings disparos
contra a máquina virtual ID 77, durante a migração.
62
A Figura 38 mostra as máquinas virtuais antes da migração. É possível observar que
a máquina virtual ID 77 estava hospedada no host2.
63
Figura 38: Máquina virtual ID 77 antes da migração.
Figura 37: Ping disparado contra a máquina virtual ID 77
A Figura 39 mostra as máquinas virtuais depois da migração, percebe-se que a
máquina virtual ID 77 agora está hospedada no host1.
Conclui-se que a migração on-line foi obtida com sucesso.
64
Figura 39: Máquina virtual ID 77 após a migração.
4 DIFICULDADES ENCONTRADAS
Durante a realização deste estágio, foram encontradas dificuldades com relação à
documentação da plataforma OpenNebula e da tecnologia de containers Docker.
No caso do da plataforma, não se pode afirmar que a documentação seja ruim. De
fato não é. Mas existem problemas que não são solucionados a contento. Por exemplo,
segundo a documentação o sistema de arquivos GlusterFS é compatível com a plataforma e
com o monitor de máquina virtual KVM, e todos os passos necessários para implementá-lo.
Mas, infelizmente, quando ele é implementado, o front-end adiciona as imagens no Datastore,
montado com o GlusterFS, mas não consegue copiá-las para os hosts.
Foram feitos contatos com desenvolvedores via fórum, da comunidade OpenNebula,
muito demorado, o tempo de espera chegou a 11 (onze) dias. E no caso do GlusterFS, as
informações retornadas foram controversas.
GlusterFS é uma nova tecnologia, cuja empresa desenvolvedora foi recentemente
adquirida pela Red Hat. Trata-se de um sistema cujo principal objetivo é a escalabilidade e
redundância. GlusterFS agrega múltiplas unidades de armazenamento remotas em um único
volume. As unidades de armazenamento, são chamados de bricks (tijolos).
Com relação a tecnologia de containers, implementada com o Docker, o problema é
que se trata de um produto recente e muito dinâmico. Ainda está em desenvolvimento. A
documentação não é ruim, mas é falha. Há poucos artigos sobre ele.
Com relação à infraestrutura, a dificuldade encontrada foi a limitação de memória
dos servidores, que era de apenas 8GB (gigabytes) e a falta de um storage, que
proporcionasse maior poder de armazenamento.
65
5 CONCLUSÕES
O objetivo deste trabalho foi alcançado com sucesso, por meio da realização das
atividades propostas. Pois assim, foi possível demonstrar a viabilidade da implementação de
estrutura computacional em nuvem e da utilização da tecnologia de containers para
aplicações. O gerenciamento de recursos computacionais (processamento, memória, rede,
entre outros) e aplicações pela web, também foram alcançados.
Os benefícios oferecidos pela virtualização foram notados, claramente, durante o
trabalho.
A plataforma OpenNebula se mostrou organizada e muito eficiente, apresentando
uma interface limpa, amigável e de fácil utilização e estável.
O Docker se mostrou muito eficiente, de fácil manipulação e implementação muito
rápida.
Pode-se dizer, com certeza, que as atividades realizadas, a revisão de literatura, os
desafios enfrentados e a convivência com o supervisor, tiveram papel muito significativo na
consolidação dos conhecimentos que o aluno adquiriu durante o curso de Sistemas de
Informação. E, ainda, que contribuíram para a aquisição de uma nova gama de
conhecimentos.
Para o desenvolvimento deste trabalho, os conhecimentos adquiridos em disciplinas
como Gerenciamento de Projetos, Sistemas de Informação, Sistemas Operacionais, Redes e
Segurança de Redes, foram essenciais.
A pesquisa acadêmica e o software livre são grandes aliados.
A universidade não é apenas uma fonte de pesquisa mas também disseminadora do
conhecimento.
66
6 REFERÊNCIAS BIBLIOGRÁFICAS
ALVES, L. C. D. Políticas de escalonamento memory-intensive para aplicaçõesdistribuídas. São Carlos, SP: Universidade ALVESde São Paulo, Maio 2008.
ALVES, L. C. D. O impacto da virtualização no desempenho de aplicações distribuídasbaseadas em SOA e a sua influência nos modelos de desempenho. São Carlos, SP:Universidade de São Paulo, Dezembro 2013.
ANDERSON, C. Docker. Docker, IEEE Software. n. Symphony Commerce, p. 4, 2015.
CHIERICI, A.; VERALDI, R. A quantitative comparison between xen and kvm.Conference Series 219 (2010) 042005. Anais... In: 17TH INTERNATIONALCONFERENCE ON COMPUTING IN HIGH ENERGY AND NUCLEAR PHYSICS(CHEP09). 2010Disponível em: <http://iopscience.iop.org/1742-6596/219/4/042005>. Acessoem: 2 jan. 2016
DANTAS, M. Computação Distribuída de Alto Desempenho: Redes, Clusters e GridsComputacionais. 1.a ed. Rio de Janeiro, RJ. Axcel Books do Brasil Editora Ltda, 2005.
Docker - Build, Ship, and Run Any App, Anywhere. Disponível em:<http://www.Docker.com/>. Acesso em: 10 abr. 2016.
GRAZIANO, C. D. A performance analysis of Xen and KVM hypervisors for hosting theXen Worlds Project. Ames, Iowa. Iowa State University, 2011.
GUARIENTI, C. E. Infraestrutura de e-science para contexto ambiental. Cuiabá, MT.Universidade Federal de Mato Grosso, 2016.
HABIB, I. Virtualization with KVM. Virtualization with KVM, v. Volume 2008, n. Issue166, p. 6, fev. 2008.
KVM. Disponível em: <http://www.linux-kvm.org/page/Main_Page>. Acesso em: 10 abr. 2016.
Linux Containers. Disponível em: <https://linuxcontainers.org/>. Acesso em: 10 abr. 2016.
LXC. Disponível em: <https://help.ubuntu.com/lts/serverguide/lxc.html>. Acesso em: 10 abr. 2016.
MELL, P.; GRANCE, T. The NIST Definition of Cloud ComputingNIST - NationalInstitute of Standards and Technology - USA, , 2011. Disponível em:<http://faculty.winthrop.edu/domanm/csci411/Handouts/NIST.pdf>. Acesso em: 15 mar. 2016
OpenNebula 4.14.2 documentation. Disponível em: <http://docs.opennebula.org/4.14>.
67
Acesso em: 10 abr. 2016.
TANENBAUM, A. S. Computer Networks. 4. ed. Amsterdam, Netherlands: Prentice Hall,2002. Tradução Vandenberg D. de Souza, Editora Campus Elsevier. Rio de Janeiro, RJ.
TANENBAUM, A. S. Sistemas Operacionais Modernos. 2.a Ed. ed. São Paulo, SP. PearsonEducation do Brasil, 2003.
TANENBAUM, A. S.; STEEN, M. V. Sistemas Distribuídos Princípios e Paradgmas. 2. ed.São Paulo, SP. Pear, 2007.
The Xen Project, the powerful open source industry standard for virtualization.Disponível em: <http://xenproject.org/>. Acesso em: 10 abr. 2016.
68
