Construindo um Cloud
Rodrigo Albani de Campos – [email protected]
“Design is not just what it looks like and feels like. Design is how it works.” – Steve Jobs
Indice
Indice ............................................................................................................................................. 1
Resumo.......................................................................................................................................... 2
Um pouco de história .................................................................................................................... 2
Por que agora? .............................................................................................................................. 3
A tecnologia............................................................................................................................... 3
O mercado ................................................................................................................................. 4
Características da Nuvem .............................................................................................................. 5
Construindo um Cloud .................................................................................................................. 6
A Rede ....................................................................................................................................... 6
Os Dados ................................................................................................................................... 8
A Virtualização......................................................................................................................... 11
Orquestração e Gerência ........................................................................................................ 15
Conclusão e Considerações ......................................................................................................... 15
Construindo um Cloud
1
Resumo
O assunto mais comentado no mercado da tecnologia da informação recentemente é o Cloud
Computing, ou Computação em Nuvem. Muito se fala sobre o consumo de TI como um serviço
nesse novo modelo de negócio, mas o que é de fato a Nuvem e como ela é construída?
Esse artigo pretende desmistificar o que existe por trás de um serviço de nuvem, mostrar quais
as principais tecnologias utilizadas e ajudar a entender o que precisa ser levado em
consideração na contratação de um serviço com o objetivo de garantir a maior aderência
possível entre a demanda de negócio e a oferta contratada.
Além disso, o artigo sedimenta alguns conceitos sobre Cloud, os diversos modelos de serviço e
entrega e principais características.
Um pouco de história
A ideia básica da computação em nuvem é a habilidade de um ou mais sistemas integrados
em oferecer capacidade de computação e armazenamento distribuídos para um conjunto
heterogêneo de usuários finais, permitindo assim que a capacidade computacional seja
oferecida como um serviço. Conceitualmente, assemelha-se a como consumimos energia
elétrica ou água.
A possibilidade de um dia a computação ser consumida dessa forma foi proposta
originalmente por John McCarthy1 em um discurso realizado em 1961 no MIT, quando os
primeiros sistemas de compartilhamento de tempo estavam sendo desenvolvidos naquela
universidade.
“If computers of the kind I have advocated become the computers of the future, then
computing may someday be organized as a public utility just as the telephone system is a
public utility... The computer utility could become the basis of a new and important industry.” –
John McCarthy
Esses sistemas foram base para a evolução da computação como conhecemos hoje, já que
permitiam que um único sistema computacional operasse de forma compartilhada, como se
fosse capaz de realizar mais de uma operação ao mesmo tempo.
Em meados da década de 70, o conceito de distribuição de processamento e armazenamento
foi previsto por outros pioneiros da ciência da computação como Grace Hooper2, conforme
podemos ler no livro de Russel McGee, “My Adventure with Dwarfs: A Personal History in
Mainframe Computers”3.
O autor chama a atenção para o fato de Hooper, já naquela época, acreditar que grandes
computadores seriam substituídos por diversas máquinas de diferentes tamanhos e
1
http://www-formal.stanford.edu/jmc/
http://en.wikipedia.org/wiki/Grace_Hopper
3
http://www.cbi.umn.edu/hostedpublications/pdf/McGee_Book-4.2.2.pdf
2
Construindo um Cloud
2
capacidades conectadas por uma rede. Qualquer usuário em qualquer “nó” da rede poderia se
comunicar com outras máquinas e outros usuários em outros nós, assim como poderia ter
acesso a dados em qualquer banco de dados conectado na rede desde que tivesse permissão
para isso.
Ao longo dos anos o conceito de multitarefa e de compartilhamento de tempo se solidificou e
virou comum, porém a tecnologia que permitiu a difusão do conceito de nuvem se não se
consolidou até meados dos anos 2000 com o estouro das dot-com.
O gráfico a seguir representa o processo evolutivo da computação ao longo dos anos até a
atualidade.
Figura 1 - Evolução de Sistemas de Computadores
Por que agora?
O Cloud Computing, assim como acontece com outras tecnologias, desponta agora como
resultado de dois fatores: a disponibilidade tecnológica e a demanda do mercado.
A tecnologia
É a tecnologia que torna esse modelo computacional viável. Em particular, a disponibilidade e
ubiquidade de rede de alta velocidade por um custo aceitável permite que serviços
computacionais sejam distribuídos em escala global.
Construindo um Cloud
3
Andy Grove4, cofundador e CEO da Intel de 1987 até 1998, desenvolveu sobre a
disponibilidade de banda de rede em um discurso em 1988:
“If you are amazed by the fast drop in the cost of computing power over the last decade, just
wait till you see what is happening to the cost of bandwidth.” – Andrew Grove
De forma semelhante, em 1994, Bill Gates afirmou em um artigo da PC Magazine que em uma
década teríamos banda infinita.
O fato é que a rede acaba sendo o amálgama que une os componentes da nuvem. Sem o
advento das redes de grande capacidade, estáveis e com um custo aceitável, a nuvem como
concebemos hoje não seria possível.
Outro avanço fundamental foi o amadurecimento e popularização das tecnologias de
virtualização. Apesar de não serem novas, essas tecnologias estavam anteriormente
disponíveis apenas em equipamentos de grande porte e complexidade.
Apesar de a virtualização não ser um fator preponderante, já que muitas arquiteturas na
nuvem são baseadas em componentes multiusuários não necessariamente virtualizados, a
habilidade de segmentar a infraestrutura facilita a adoção e o desenvolvimento na nuvem.
O mercado
Se por um lado a tecnologia que permite a computação em nuvem evoluiu e se tornou
amplamente disponível, o mercado apresentou em contrapartida a demanda por um modelo
de consumo de computação sem precedentes.
Uma teoria que sumariza de forma eficiente essa demanda é a do Redshift5, que posiciona o
mercado em duas situações opostas.
De um lado estão as empresas cuja demanda computacional é ultrapassada pela tecnologia
disponível, ou seja, que potencialmente desperdiçam recursos ou que não tem capacidade de
consumir tudo o que lhes é oferecido. Essas empresas, pelo que prega a teoria, estariam em
decaimento para o azul, ou em Blueshift.
Considerando a alta ociosidade observada em vários Datacenters pode-se assumir que a
maioria das empresas se encontra nesse espectro.
De outro lado, temos empresas cuja demanda ultrapassa, em alguns casos em várias ordens de
magnitude, a capacidade computacional que pode ser entregue em um único equipamento,
não importa o quão grande seja o mesmo. Para estas empresas, diz-se que estão em
decaimento para o vermelho, ou Redshift.
Um exemplo clássico de redshift foi a crise observada pelo eBay em 1999, quando a maior
máquina Sun disponível não era capaz de atender a demanda computacional do banco de
dados principal do site de leilões.
4
5
http://en.wikipedia.org/wiki/Andrew_Grove
http://bit.ly/red-shift
Construindo um Cloud
4
“By November 1999, the database servers approached their limits of physical growth” – Randy
Shoup and Dan Pritchett – SD Forum 20066
Apesar de atualmente termos máquinas com muito mais capacidade do que em 1999, a
realidade é que empresas de escala web não teriam como centralizar o processamento ou o
armazenamento de seus dados em um único equipamento, a exemplo do que ocorreu com o
eBay em 1999.
Curiosamente, as soluções para os problemas de blueshift e redshift são as mesmas, e
permeiam quatro fatores fundamentais:
1.
2.
3.
4.
Distribuição do tráfego
Elasticidade instantânea
Escalabilidade de processamento
Escalabilidade de armazenamento
Não por coincidência, essas são características que encontramos no conjunto de tecnologias
que chamamos hoje de Cloud Computing.
Características da Nuvem
Devido a grande repercussão de mercado da computação em nuvem, o termo acabou sendo
pervertido e utilizado de forma até exagerada. Praticamente qualquer recurso computacional
oferecido fora das instalações do cliente hoje em dia carrega o termo “nuvem” ou “cloud” em
seu nome.
O que define então, de forma descomprometida, a computação em nuvem?
O National Institute of Standards and Technology (NIST) oferece um conjunto de cinco
características que procuram definir o que é um serviço de computação em nuvem7. Apesar de
a definição ser considerada incompleta por muitos, é bastante concisa e define uma referência
que vem se tornando padrão para o mercado.
Essas características são:



6
7
Auto-Serviço Sob Demanda: Um cliente pode de forma unilateral provisionar
capacidade computacional, como por exemplo, tempo de processamento de um
servidor ou armazenamento de dados na rede, conforme a sua necessidade e sem
precisar de interação humana com um ou mais provedores de serviço.
Acessibilidade ubíqua pela rede: Os recursos estão disponíveis pela rede e podem ser
acessados através de mecanismos padrão que viabilizam o seu uso por plataformas
heterogêneas e de portes distintos.
Compartilhamento de recursos: Os recursos computacionais do provedor são
compartilhados de forma que sirvam a múltiplos clientes usando um modelo multi-
http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf
http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf
Construindo um Cloud
5


locatário (multi-tenant), com recursos físicos e virtuais sendo dinamicamente alocados
e redistribuídos conforme a demanda do cliente. Existe uma sensação de
independência de localidade de tal forma que o cliente geralmente não controla ou
desconhece exatamente a posição exata dos recursos provisionados, apesar de poder
determinar a localidade em um nível mais abstrato (país, estado ou datacenter).
Exemplos de recursos incluem armazenamento de dados, processamento, memória e
largura de banda de rede.
Elasticidade rápida: A capacidade contratada pode ser provisionada e devolvida de
forma elástica, em alguns casos até mesmo automaticamente, para rapidamente
escalar para mais ou menos conforme a demanda. Para o cliente, a capacidade
disponível é virtualmente ilimitada e pode ser ajustada em qualquer quantidade e em
qualquer momento.
Serviço mensurável: Sistemas em nuvem automaticamente controlam e otimizam a
utilização de recursos através do uso de mecanismos de métricas em um nível de
abstração apropriado para o tipo de serviço (exemplos incluem armazenamento,
processamento, largura de banda de rede e número de contas ativas). A utilização de
recursos pode ser monitorada, controlada e registrada, oferecendo transparência
tanto para o provedor quando para o consumidor do recurso utilizado.
Construindo um Cloud
A construção de uma infraestrutura de nuvem deve ser alinhada com objetivos e requisitos
claros. Essas demandas variam de acordo com o cenário que se pretende atacar, porém alguns
componentes são onipresentes por se fazerem necessários para que a solução ofereça todas
as características de um ambiente de nuvem.
A Rede
Seja qual for a solução ou stack adotado para a construção da nuvem, um componente básico
e essencial para a sua construção é a rede.
De fato, devido à natureza compartilhada e heterogênea da nuvem, a rede é um dos fatores
críticos de sucesso para garantia da estabilidade e segurança dos serviços que serão
hospedados na mesma.
Esta ainda é uma área que vem se consolidando e ainda não existe de fato um padrão. Os
fatores que devem ser considerados para a escolha da solução ou de um fornecedor são:



Capacidade de isolar máquinas virtuais de tal forma que uma não possa “enxergar” o
tráfego da outra
Capacidade de impedir que uma máquina assuma inadvertidamente o endereçamento
de outra, independente de camada
Capacidade de proteger componentes de roteamento do sistema de colisões de
endereçamento propositais ou não feitas pelos usuários da nuvem
Construindo um Cloud
6






Capacidade de criar redes privadas isoladas entre máquinas de um mesmo domínio ou
cliente
Capacidade de criar redes privadas isoladas mantendo o endereçamento da rede
privada do cliente (essencial para a criação de nuvens híbridas)
Capacidade de limitar o volume de tráfego da máquina virtual
Capacidade de contabilizar o volume de dados trafegado para casos em que a
bilhetagem seja feita considerando essa métrica
Capacidade de oferecer recursos de firewall e demais proteções contra ataques
Escalabilidade para atender ao novo paradigma, onde a quantidade de redes lógicas é
muito maior
Tecnologias relevantes
Recentemente uma série de tecnologias vem sendo apresentadas com o objetivo de resolver
os desafios da computação em nuvem.
Essa lista não é uma compilação completa das tecnologias que vem despontando no mercado,
mas pretende esclarecer alguns termos que tem se tornado comum nas discussões sobre o
assunto.
VXLAN
Uma das maneiras mais tradicionais e difundidas de fazer o isolamento de redes é o IEEE
802.1Q VLAN8. Esse padrão define – entre outras coisas – um método para a rotulagem de
segmentos de rede com um identificador de 12 bits, permitindo dessa forma a segmentação
lógica de uma rede em 4096 blocos isolados.
O problema é que em arquiteturas de nuvem multi-tenant esse limite muitas vezes é
ultrapassado, fazendo necessária a criação de um novo padrão.
Um grupo de fornecedores incluindo Cisco, VMWare, Citrix e Red Hat propuseram então um
novo padrão chamado VXLAN (Virtual eXtensible LAN) que utiliza um identificador de
segmento de 24 bits, permitindo assim a criação de mais de 16 milhões de segmentos
distintos, um valor muito mais adequado para a nova realidade dos ambientes de nuvem.
Além disso, o protocolo propõe um encapsulamento IP utilizando UDP, o que permite que a
LAN seja estendida em camada 3.
OpenFlow
O OpenFlow9 vem sendo apresentado como uma evolução para as arquiteturas tradicionais de
redes, propondo um modelo que visa atender a necessidade de oferecer a capacidade de
programar uma rede de forma análoga ao que se faz com sistemas operacionais de servidores.
De grosso modo, em uma arquitetura de rede tradicional as camadas de controle (control
plane) e de tráfego (data plane) ficam no mesmo equipamento, a arquitetura OpenFlow
8
9
http://en.wikipedia.org/wiki/IEEE_802.1Q
http://www.openflow.org/documents/openflow-wp-latest.pdf
Construindo um Cloud
7
permite a separação dessas camadas de tal forma que as tomadas de decisão sobre
roteamento, permissões e controles fiquem em um equipamento diferente daquele por onde
o tráfego passa, conforme o diagrama seguinte pretende demonstrar.
Figura 2 - Diagrama Simplificado do OpenFlow
Os Dados
Quando tratamos dos dados na nuvem se faz necessário esclarecer de quais tipos de dados
estamos falando, já que o para cada um dos problemas existem uma ou mais soluções
distintas.
O primeiro ponto que deve ser esclarecido é sob qual modelo de serviço estamos oferecendo
esses dados.
Uma forma de oferecer dados é no conceito de IaaS (Infraestrutura como serviço), em que a
grosso modo estamos falando de virtualização da infraestrutura de storage. Nesse modelo, em
geral, estamos falando em oferecer um dispositivo de bloco, como um disco ou uma unidade
lógica.
Outra forma de oferecer dados é no conceito de PaaS (Plataforma como infraestrutura). Nesse
modelo o acesso aos dados é garantido por uma API ou SDK, que permite o desenvolvimento
ou integração de componentes de software que acessam uma plataforma que oferece
capacidades de armazenamento de dados.
Dentro desses dois modelos de serviço, podemos caracterizar os dados como:


Dados do usuário
o Dados dos usuários que devem ser compartilhados entre várias máquinas ou
serviços na nuvem
o Dados dos usuários que são privados dentro do contexto da máquina ou do
serviço e não devem ser compartilhados
Dados do provedor de infraestrutura
o Backups mantidos para recuperação de desastre
o Dados necessários para aprovisionamento dos serviços (imagens, templates)
Construindo um Cloud
8
o
o
Áreas de transferência e retenção para controle do ciclo de vida dos serviços
Dados de monitoramento e orquestração da nuvem
Cada uma dessas categorias traz desafios que precisam ser mitigados durante a construção do
ambiente.
Para os dados do usuário, os principais pontos de atenção são:






Isolamento dos recursos de dados de tal forma que seja possível oferecer garantias de
desempenho e qualidade de serviço para o acesso aos dados
Proteção contra acessos não autorizados aos dados do usuário
Havendo necessidade, a capacidade de oferecer criptografia dos dados
Desempenho constante e estável no acesso aos dados
Capacidade de estender os volumes oferecidos
Havendo necessidade, a capacidade de compartilhar os dados entre diversas máquinas
virtuais ou serviços mediante permissão concedida pelo usuário
Tecnologias relevantes
De forma análoga ao que observamos em redes, a área de armazenamento de dados tem se
desenvolvido para atender ao novo paradigma. Os modelos tradicionais de SAN não se
adaptam a todo o tipo de instalação em nuvem e inclusive na grande maioria dos fornecedores
de Cloud público esse modelo sequer é utilizado.
Storage Area Networks
As Storage Area Networks (SAN) são utilizadas frequentemente em nuvens privadas, onde as
cargas de trabalho são conhecidas e geralmente previsíveis, e em ambientes onde a
responsabilidade pela alta disponibilidade do sistema não está embarcada no software,
dependendo, portanto de uma infraestrutura que permita, por exemplo, a movimentação de
cargas de trabalho entre diferentes servidores sem parada na aplicação.
Como esse tipo de movimentação exige uma área de troca de dados comum entre diversos
servidores da nuvem o modelo de SAN se mostra eficiente.
Alguns fabricantes disponibilizam inclusive uma integração entre a camada de gerencia da
nuvem e os equipamentos de storage, permitindo assim que operações intensivas de acesso
aos dados sejam gerenciadas diretamente pelo subsistema de discos, minimizando a carga de
gestão do orquestrador. Um exemplo disso é o VAAI10 da VMWare.
Em contrapartida, a utilização de uma SAN e a consolidação das máquinas virtuais em poucos
ou em um único equipamento pode ser crítica em cenários com milhares de máquinas virtuais
ou serviços, onde uma eventual falha ou até mesmo uma manutenção programada pode fazer
com que toda ou grande parte da nuvem fiquem indisponíveis.
10
http://www.vmware.com/products/vstorage-apis-for-array-integration/overview.html
Construindo um Cloud
9
Outro ponto relevante ao se considerar uma SAN é o custo, em geral mais alto do que soluções
menos sofisticadas para o armazenamento de dados. Esse custo se reflete tanto em
equipamento quanto na operação do sistema, que demanda profissionais com um maior nível
de expertise.
Direct-Attach Storage
Os sistemas de disco diretamente conectados (DAS) foram por muitos tempos
desconsiderados ou menosprezados em meios corporativos onde eram considerados pouco
confiáveis ou menos flexíveis do que as Storage Area Networks ou mesmo os sistemas de
Network Attached Storage (NAS).
Recentemente, porém, o advento de sistemas distribuídos mais sofisticados e também o
avanço nas tecnologias de virtualização fizeram com que as empresas passassem a
reconsiderar a utilização de subsistemas de disco diretamente conectados nos servidores, sem
a necessidade de uma rede para a interconexão e compartilhamento desses dados.
O aumento na confiabilidade dos discos e a disponibilidade ubíqua de controladoras RAID
também contribuíram para que o DAS perdesse a reputação de baixa disponibilidade.
Além disso, as configurações de nuvem pública fazem com que seja interessante a redução da
abrangência do impacto em caso de falhas, com uma distribuição e separação dos pontos
únicos de falha entre centenas e até mesmo milhares de servidores. Dessa forma, se assume
como aceitável a perda temporária de um conjunto reduzido de máquinas ou serviços virtuais,
pois as arquiteturas de sistemas utilizadas na camada de aplicação estariam prontas para
automaticamente transferir essa carga para outro servidor.
Object Storage
Outra classe de dispositivos para o armazenamento de dados que tem se tornado bastante
popular são os Dispositivos para Armazenamento de Objetos (OSD).
Essa categoria de sistemas e equipamentos se diferencia dos sistemas tradicionais ao oferecer
o acesso aos dados de forma mais abstrata, com acesso oferecido geralmente por uma API ou
SDK, e oferecendo recursos sofisticados como controle de ciclo de vida, replicação,
deduplicação, distribuição geográfica do dado e controles de compartilhamento.
Uma característica frequentemente encontrada nos sistemas de Armazenamento de Objetos é
a utilização de um subsistema de disco de baixo custo, com mecanismos de replica e proteções
implantadas via software. A escalabilidade se dá de forma horizontal, ou seja, com a adição de
novos servidores no sistema.
O projeto OpenStack11 oferece um típico sistema de Armazenamento de Objetos dentro do
seu stack.
11
http://openstack.org/software/openstack-storage/
Construindo um Cloud
10
Deduplicação de dados
Os sistemas de armazenamento modernos tem oferecido uma tecnologia chamada de
deduplicação, que oferece uma potencial economia no consumo líquido de storage através da
não duplicação de dados que são idênticos independentes do proprietário.
Um exemplo típico são os arquivos do sistema operacional das máquinas virtuais, que em geral
são iguais e permanecem inalterados na maioria das máquinas.
O racional é que não faz sentido ocupar mais de um “bloco” de storage para armazenar dados
que são comuns entre si.
Apesar de a tecnologia ser mais eficiente em ambientes com grandes volumes compartilhados,
típicos das SAN e dos Object Storages, o mesmo vem sendo aplicado e aproveitado com
ganhos significativos mesmo em instalações relativamente pequenas, características dos
sistemas de discos diretamente conectados.
As vantagens da deduplicação trazem um pênalti em termos de consumo de processamento e
memória, e em alguns casos também existe uma perda de desempenho.
Um dos sistemas de arquivos responsáveis pela popularização do uso de deduplicação é o ZFS,
que oferece essa capacidade nativa desde Outubro de 200912.
A Virtualização
Atualmente a virtualização é praticamente onipresente no desenvolvimento de soluções de
computação em nuvem, sendo em alguns casos confundida com o próprio conceito de nuvem.
Uma maneira mais correta de ver a virtualização é entender ela como um grande facilitador,
porém é importante compreender que por si só ela não é capaz de entregar todas as
vantagens desse novo paradigma.
Alguns outros componentes lógicos são fundamentais, como por exemplo, a automação e
orquestração do ambiente.
Breve história da virtualização
A tecnologia de virtualização teve o começo de seu desenvolvimento muito próximo das
tecnologias de multitarefa e compartilhamento de tempo. Esses avanços na ciência da
computação foram contemporâneos na década de 1960 e tiveram como precursores sistemas
derivados do CP-40, um sistema operacional desenvolvido pela IBM para seus primeiros
mainframes.
Um dos frutos do CP-40 foi CP-67/CMS, que viabilizava o compartilhamento de tempo em
Sistemas IBM 360.
12
http://en.wikipedia.org/wiki/ZFS#Deduplication
Construindo um Cloud
11
Figura 3 - IBM S/360
Na década de 1980 a Locus Computing Corporation13 apresentou alguns dos primeiros
sistemas de virtualização para plataforma 80286, permitindo a execução de aplicativos MSDOS como guests em um sistema Unix System V.
No final da década de 90 a VMWare passou a oferecer uma série de sistemas que permitiam a
virtualização em máquinas x86 e em 2003 foi lançado o primeiro sistema de virtualização de
código aberto, o Xen14.
Tipos de Virtualização
A virtualização de sistemas é dividida em três categorias:
Virtualização Total
Simulação completa da
camada de hardware,
permitindo que o sistema
operacional e os aplicativos
sejam utilizados com pouca
ou nenhuma modificação.
Virtualização Parcial
Nem todos os componentes
da máquina hospedeira são
simulados no ambiente
virtualizado, fazendo com
que sejam necessárias
alterações para a migração
de algumas aplicações para
esse ambiente.
Paravirtualização
Não existe uma simulação da
camada de hardware, mas
sim uma divisão em domínios
ou partições lógicas com
recursos e capacidade
isoladas. Em geral exige que
os aplicativos e sistemas
sejam desenvolvidos
especificamente para o
ambiente onde serão
13
http://en.wikipedia.org/wiki/Locus_Computing_Corporation
http://www.brianmadden.com/blogs/gabeknuth/archive/2007/08/16/a-brief-history-of-xen-andxensource.aspx
14
Construindo um Cloud
12
executados.
Tecnologias Relevantes
Como peça fundamental de diversas implantações de nuvem, a camada de virtualização vem
evoluindo e oferecendo recursos cada vez mais avançados. Entre esses recursos alguns são
extremamente relevantes para a definição de uma arquitetura de nuvem.
Isolamento de recursos
Mesmo em sistemas que oferecem virtualização total, muitas vezes não existe um isolamento
de recursos que garanta aos sistemas uma parcela fixa e predeterminada dos recursos da
máquina física.
Isso pode fazer com que eventualmente um dos usuários do sistema consuma recursos em
excesso, causando impacto no desempenho das outras máquinas hospedadas no mesmo
equipamento. Esse comportamento é muitas vezes chamado de neighbouring effect, que em
tradução livre expressa o impacto das máquinas “vizinhas” no comportamento de outras
máquinas. Tais eventos são especialmente críticos em ambientes de nuvem pública, onde
existe pouco ou nenhum controle sobre a utilização de recursos por parte de usuários que
compartilham o mesmo equipamento.
Atualmente o isolamento de memória e processamento já é algo resolvido na maioria dos
hypervisors, porém o controle de acesso aos subsistemas de disco ainda é deficitário na
maioria dos ambientes de nuvem compartilhado, principalmente quando o subsistema de
discos está conectado através de redes não especializadas, como por exemplo, em NAS ou até
mesmo em iSCSI.
Frequentemente o que se encontra em ambientes de nuvem é a distribuição de recursos de
acesso aos dados por fair share, ou seja, se entende que os recursos serão distribuídos de
forma homogênea entre as máquinas virtuais de acordo com a capacidade de cada uma delas
de gerar demanda, sem que haja garantia nenhuma da capacidade entregue.
O Cloud do UOL Host procura resolver essa questão através de mecanismos de controle que
garantem níveis de desempenho alinhados com a capacidade do plano contratado.
Overcommit de memória
O overcommit é a capacidade do hypervisor de entregar para as máquinas virtuais hospedadas
uma quantidade de memória que em sua totalidade excede a própria capacidade da máquina
física.
A motivação para o uso dessa tecnologia é a capacidade de aumentar a concentração de
máquinas virtuais em um mesmo servidor, permitindo assim um melhor aproveitamento do
equipamento.
Isso é feito através de um conjunto de tecnologias que pode ser transparentes ou não para os
sistemas que rodam nas máquinas virtuais:
Construindo um Cloud
13



Transparent Page Sharing: O TPS é similar ao conceito de deduplicação de dados,
porém se aplica na memória volátil ao invés dos dados em disco. Como algumas
páginas de memória de máquinas virtuais distintas podem armazenar conteúdo
idêntico, o hypervisor cria uma tabela de referência para essa página de memória
indicando que duas ou mais máquinas virtuais tem o mesmo dado e mantém apenas
uma página alocada na memória real que é compartilhada entre as máquinas virtuais.
O TPS não depende de nenhuma modificação ou driver instalado nas máquinas
virtuais, ele atua de forma transparente.
Ballooning: O ballooning é uma técnica que permite que o sistema operacional que
roda na máquina virtual notifique ao hypervisor a sua demanda real de memória,
possibilitando que a memória física seja alocada dinamicamente de acordo com as
necessidades do ambiente. Essa técnica depende de um driver específico instalado no
sistema operacional da máquina virtual e consequentemente depende de um suporte
específico para que possa ser utilizado.
Swapping: Da mesma forma que um sistema operacional pode usar uma área de swap
para armazenar em disco páginas de memória não utilizadas, o hypervisor pode aplicar
a mesma técnica para fazer com que áreas de memória com utilização pouco
frequente sejam retiradas da memória física e transportadas para uma área de swap.
Essa técnica também é transparente para o sistema operacional da máquina
virtualizada, porém pode trazer um pênalti de desempenho quando sua utilização for
muito frequente ou em casos em que o overcommit ultrapassar uma taxa de
concentração razoável.
Thin Provisioning
O thin provisioning consiste em um recurso frequentemente oferecido tanto pelos subsistemas
de disco quanto pelos hypervisors, e em resumo é a entrega de um volume de dados lógico de
um tamanho maior do que o que foi efetivamente alocado no disco físico.
Isso faz sentido já que em muitos casos o usuário não utiliza de fato a capacidade total de
disco que foi oferecida no plano contratado, porém pode ser um problema critico em
ambientes de nuvem pública onde o comportamento do conjunto de usuários é imprevisível e
muitas vezes o aumento da capacidade de disco no servidor não é possível.
Snapshot
Diversos hypervisors oferecem a capacidade de gerar um snapshot (fotografia) da máquina
virtual. Essa fotografia persiste o estado atual da máquina virtual, de sua memória volátil e de
seus dispositivos de armazenamento de tal forma que é possível recuperar essa condição no
futuro.
Esse recurso difere de um procedimento tradicional de backup já que na maioria dos casos não
é possível fazer uma recuperação pontual de um arquivo ou diretório, sendo necessária a
recuperação completa do ambiente para que se extraia um dado específico.
Construindo um Cloud
14
Uma utilização típica do recurso de snapshot é para a realização de backups de emergência
antes de uma manutenção no ambiente ou alterações no sistema operacional, como a
instalação de uma atualização de segurança por exemplo.
Orquestração e Gerência
Provavelmente o campo mais indefinido dentro do universo da computação em nuvem são as
camadas de orquestração e gerência.
Uma série de soluções e iniciativas vem sendo apresentadas, porém a maioria delas acaba
sendo enviesada para atender um Hypervisor ou um ambiente específico, tornando a solução
especializada em, por exemplo, nuvens públicas ou privadas.
Muitas vezes é necessário construir a camada de orquestração e gerência do zero,
principalmente em ambientes públicos onde frequentemente se encontra uma grande
diversidade de componentes e fornecedores de soluções e não existe um orquestrador capaz
de contemplar todas as tecnologias envolvidas na construção do ambiente.
Entre as funções normalmente encontradas em um orquestrador para ambientes de
computação em nuvem, identificamos frequentemente as seguintes características:






Controle e gestão do aprovisionamento de máquinas virtuais dentro dos clusters de
servidores, incluindo a distribuição para melhor aproveitamento do hardware
instalado.
Controle e gestão da instalação do sistema operacional e pacotes básicos de software
nas máquinas virtuais.
API para comunicação da camada de orquestração com as interfaces de controle do
sistema para o usuário final
API para comunicação da camada de orquestração com ferramentas de gestão do
ambiente de nuvem
Agendamento e controle de operações para manutenção do ambiente
Integração com sistemas heterogêneos e hypervisors distintas
Conclusão e Considerações
Por mais que hoje existam diversas nuvens “prontas”, qualquer instalação um pouco mais
sofisticada provavelmente exigirá a integração de componentes não previstos na concepção
original do ambiente. Além disso, compreender os sistemas e tecnologias envolvidos na
construção de um ambiente de nuvem pode ajudar na escolha da solução correta e também
facilitar o entendimento de comportamentos e situações decorrentes do uso do ambiente em
nuvem.
Como referência, o diagrama final de um ambiente de nuvem, com todos os sistemas
devidamente acoplados seria o seguinte:
Construindo um Cloud
15
Figura 4 - Diagrama de uma nuvem
Vale frisar que diferentes problemas exigem diferentes soluções e que devido ao ritmo de
evolução da tecnologia envolvida com a computação em nuvem é necessária uma atualização
constante.
O UOL Host mantém seu compromisso de se manter na vanguarda da tecnologia ao oferecer
artigos e informações relevantes para o mercado e para os seus clientes. Esse mesmo
compromisso é aplicado em seus produtos e serviços.
Construindo um Cloud
16