UNIVERSIDADE CANDIDO MENDES
PÓS-GRADUAÇÃO “LATO SENSU”
INSTITUTO A VEZ DO MESTRE
COMPUTAÇÃO EM NUVENS : A NECESSIDADE DE
ESTABELECIMENTO DE UMA POLÍTICA PÚBLICA DE
PROMOÇÃO DO ACESSO, PELA SOCIEDADE CIVIL, AOS
RECURSOS COMPUTACIONAIS PÚBLICOS DE FORMA
COMPARTILHADA E NÃO ONEROSA.
Por: Ricardo Baía Leite
Orientador
Prof. Marcelo Martins Saldanha da Gama
Rio de Janeiro
2011
2
UNIVERSIDADE CANDIDO MENDES
PÓS-GRADUAÇÃO “LATO SENSU”
INSTITUTO A VEZ DO MESTRE
COMPUTAÇÃO EM NUVENS : A NECESSIDADE DE
ESTABELECIMENTO DE UMA POLÍTICA PÚBLICA DE
PROMOÇÃO DO ACESSO, PELA SOCIEDADE CIVIL, AOS
RECURSOS COMPUTACIONAIS PÚBLICOS DE FORMA
COMPARTILHADA E NÃO ONEROSA
Apresentação
Candido
de
Mendes
monografia
como
à
requisito
Universidade
parcial
para
obtenção do grau de especialista em Gestão Pública
Por: . Ricardo Baía Leite
3
AGRADECIMENTOS
Agradeço a Deus, a minha família, a
minha esposa Silvia e aos meus filhos
Bruno e Guilherme pela paciência,
compreensão e apoio. As renomadas
instituições de governo e de ensino e
pesquisa, Secretaria de Estado de
Planejamento e Gestão do Rio de
Janeiro
e
Universidade
Cândido
Mendes, pela sua elevada qualidade,
que em parceria promoveram este
curso e, assim sendo, me permitiram
desfrutar
apreender
desta
e
oportunidade
capturar
novos
de
e
relevantes conhecimentos atualizados.
4
DEDICATÓRIA
Dedico este trabalho a minha esposa
Silvia Maria que sempre me estimulou e
me acompanhou nesta longa jornada.
5
RESUMO
Nesta monografia é atacado o problema da falta de qualidade no acesso
aos recursos computacionais em nuvem pública de forma compartilhada e não
onerosa pela sociedade civil. Este acesso é suportado pelo estabelecimento de
nuvens públicas com recursos computacionais compartilhados tanto pelos
órgãos de Tecnologia da Informação, Comunicação e Entretenimento – TICE
em âmbito público, no nível federal através da empresa pública Serviço
Federal de Processamento de Dados – SERPRO, quanto no nível estadual
através da autarquia Centro de Tecnologia da Informação e Comunicação do
Estado do Rio de Janeiro - PRODERJ. Este tema de Computação em Nuvem
tem se incorporado à disciplina de Rede de Computadores que também é
ministrada nos cursos superiores tecnológicos do estado do Rio de Janeiro.
Destinado também a elevar o nível de qualidade deste ensino e mitigar o
problema detectado, o autor deste trabalho formulou uma base teórica sobre o
tema que pode se desdobrar num futuro projeto de pesquisa científica. Ato
contínuo pretende submeter este projeto, visando lograr êxito na obtenção de
recursos financeiros e tecnológicos oriundos da agência de fomento do estado,
a fundação pública de amparo à pesquisa Carlos Chagas Filho, para sua
implantação.
6
METODOLOGIA
Estamos propondo à investigação aprofundada da construção de uma
nuvem pública computacional de abrangência regional orientada para
aperfeiçoar o acesso da sociedade civil aos recursos computacionais públicos.
Não haverá pesquisa de campo participativa nem na capital nem no interior do
estado. Serão coletados dados a partir de pesquisas bibliográficas e
entrevistas com professores do curso de ciência de computação. Serão
analisados também documentos, artigos em periódicos, livros e sites sobre o
tema em questão.
7
SUMÁRIO
INTRODUÇÃO
8
CAPÍTULO I
O HYPE CYCLE E A COMPUTAÇÃO EM NUVENS
11
CAPÍTULO II
MODELOS E TECNOLOGIAS
22
CAPÍTULO III
INFRAESTRUTURA E IMPLEMENTAÇÃO
49
CAPÍTULO IV
APLICAÇÕES BRASILEIRAS EM DESENVOLVIMENTO
73
CONCLUSÃO
78
ANEXOS
82
BIBLIOGRAFIA CONSULTADA
84
BIBLIOGRAFIA CITADA
84
ÍNDICE
FOLHA DE AVALIAÇÃO
90
91
8
INTRODUÇÃO
A empresa Gartner Group é especialista em consultoria atuando no
desenvolvimento de tecnologias relacionadas à prospecção de informações
técnicas e de mercado necessárias à tomada de decisão cotidiana de seus
clientes corporativos. Presta serviço e trabalha com mais de dez mil empresas,
incluindo o suporte aos profissionais exercendo o cargo de “Chief Information
Officce” - CIO e outros dirigentes executivos da área de Tecnologia da
Informação, Comunicação e Entretenimento - TICE, nas corporações e órgãos
de governo. É considerada uma das maiores e mais respeitadas no setor de
TICE.
Entre as ferramentas de prospecção de maior aceitação pelo mercado
e produzidas periodicamente pelo seu quadro técnico se encontram as figuras
dos “HYPE CYCLE”, ou seja, uma representação gráfica do nível de
maturidade e de aderência bem como de aplicação nos negócios de uma
tecnologia em particular; e também de outra arte iconográfica capaz de
representar por meio de imagem chamada de “MAGIC QUADRANT” a inserção
das empresas no mercado.
Verteremos esses anglicismos livremente para o nosso idioma
utilizando as mesmas figuras denominadas de superciclos e dos quadrantes
mágicos.
O superciclo de uma tecnologia específica sinteticamente está
baseado em quatro fases pelas quais navegam em diferentes momentos. No
estudo de caso apresentado a seguir abordaremos o tema computação em
nuvem. Entretanto a figura 3 do quadrante mágico é povoada pelas empresas
que desenvolvem ou aprimoram as tecnologias no mercado. No presente
estudo de caso a virtualização de servidores físicos com arquitetura x86 será
objeto de nossa atenção, embora saibamos que a virtualização não é um prérequisito mandatório para a computação em nuvem, prevemos um grande
aumento do uso da virtualização em implantação de nuvens devido aos
9
benefícios inerentes ao uso eficiente de servidores e a migração em tempo real
da carga de trabalho.
Sob a ótica do usuário da tecnologia investigada, a mesma pode se
encontrar na fase inicial de disparo, ajuste, estabelecimento ou “setup”, sendo
seguida da fase de pico de expectativas infladas, nível máximo de esperança,
então sucedida pela fase denominada de vale da desilusão, onde ocorre a
segunda e mais importante inflexão da curva para a fase de aclive dos
iluminados, onde os benefícios são alardeados, finalmente alcançando a
derradeira e tão desejada fase do amadurecimento do uso da tecnologia.
Em contrapartida, do ponto de vista comercial as corporações que
desenvolvem uma nova tecnologia podem ser classificadas como líderes de
mercado, concorrentes desafiadoras da posição de liderança, companhias
visionárias ou exploradoras de nichos de mercado. Essas posições variam de
acordo com a perfeição, precisão, plenitude, integralidade e completude da
visão empresarial bem como as habilidades, competências, capacidades,
aptidões, destrezas e agilidades de executar essa visão.
O objetivo deste trabalho é desenvolver a capacidade e o
conhecimento dos servidores públicos na tecnologia de Computação em
Nuvens através de uma pesquisa teórica, aumentando as possibilidades
profissionais dos mesmos quando do término da investigação, pois esta
tecnologia é um novo campo bastante vasto, com muitas possibilidades
profissionais e com o mercado de trabalho ávido e com poucos profissionais
disponíveis.
Oferecer material com informações suficientes para que os servidores
públicos possam planejar, elaborar e especificar um projeto básico de rede de
computadores capaz de implementar Computação em Nuvens .
10
Outro bônus será difundir a tecnologia de Computação em Nuvens e
direcionar o foco em uma área que acreditamos ser de grandes oportunidades
profissionais para os servidores públicos.
Podemos incluir no elenco de objetivos aqueles ditos específicos tais
como (i) apresentar um estudo sobre tecnologia de Computação em Nuvens
com as suas principais características e aplicações sendo desenvolvidas no
Brasil;(ii) elaborar um documento que sirva de base de consulta e
disseminação de conhecimento sobre o tema abordado; e por fim,(iii)
apresentar uma nova visão sobre o tema Computação em Nuvens onde, a
partir do trabalho, possa se dar um foco mais detalhado sobre tal tecnologia,
pois se trata de um assunto com grande crescimento e com ótimas
oportunidades profissionais para o serviço público, indo ao encontro com o
fundamento de um curso de pós graduação em gestão pública.
A relevância deste projeto pode ser sintetizada em quatro razões
principais enumeradas a seguir: (i) a computação em nuvem aplicada ao setor
público precisa ser melhor compreendida, medida e gerenciada;(ii) esta
ferramenta computacional auxilia no aprendizado organizado que precisa se
tornar um processo vitalício para os servidores públicos que hoje, mais do que
nunca, são trabalhadores do conhecimento;(iii) procuramos responder a
seguinte questão: “se ainda não fizemos computação em nuvens na
administração pública, será que é oportuno começar agora, sabendo aquilo
que sabemos?” como o padrão de resposta esperado é não, alguma iniciativa
é desejada, diferentemente de apenas um novo estudo sobre tecnologia nova,
de preferência, planejar o abandono do paradigma atual, de uso do software
como produto, com pagamento de vultosas licenças de uso anual, e passar a
encarar a possibilidade de uso do software como serviço na administração
pública;(iv)na sociedade de organizações modernas qualquer pessoa com
qualquer conhecimento terá de adquirir novos conhecimentos a cada 4 ou 5
anos, sob pena de se tornar obsoleta.
11
Antes de aprofundarmos o tema computação em nuvens propriamente
dito abordaremos o item 1.1 intitulado “O Hype Cycle e a computação em
nuvens” e logo depois o tópico 1.2 “Quadrante Mágico da virtualização de
servidores físicos com arquitetura x86”, ambos no capítulo I.
Na sequência teremos a abordagem da computação em nuvens
propriamente dita dividida no capítulo II com modelos e tecnologias, no
capítulo III com infraestrutura e implementação e finalmente no capítulo IV
concluiremos a base teórica com a apresentação de algumas das aplicações
brasileiras em desenvolvimento.
Primeiramente realizamos a pesquisa bibliográfica em livros e revistas
acadêmicas da área e prosseguimos com periódicos e outros registros
impressos baseados inicialmente nos seguintes autores: SRIDHAR, T. (2010)
The Internet Protocol Journal, Volume 12, No.3/4 ; TAURION, CEZAR (2009)
COMPUTAÇÃO EM NUVEM: transformando o mundo da tecnologia da
informação. Editora Brasport, entre outros, representando o “estado da arte” no
tema investigado.
Foram analisados também documentos, artigos em periódicos e sites
na
Internet
sobre
o
tema
em
questão
TAURION,
CEZAR
(2011)
http://computingonclouds.wordpress.com (documentação indireta).
Nenhuma pesquisa de campo participativa foi realizada devido ao
escopo do projeto, porém pode ser uma contribuição futura levá-la a cabo nas
Instituições Públicas do Estado do Rio de Janeiro visando complementar o
estudo ora iniciado. Neste caso seriam coletados dados a partir de entrevistas
com os servidores públicos destas instituições via questionários aplicados
(documentação direta).
12
CAPÍTULO I
O HYPE CYCLE E A COMPUTAÇÃO EM NUVENS
1.1 - O Hype Cycle e a Computação em Nuvens
Quando uma tecnologia é lançada como no caso da Computação em
Nuvens, pode ser resultado do aperfeiçoamento incremental de alguma
tecnologia já existente, ou ocorre à sensibilização da indústria através dos
hyper cicles difundidos pela consultoria Gartner Group que obedece as
seguintes fases:
•
A tecnologia é anunciada. O anúncio pode ocorrer meses antes da real
disponibilidade do produto ou serviço. Chamamos de fase de lançamento
da tecnologia.
•
Os próprios vendedores trabalham freneticamente e buscam entrelaçar
tudo com a nova tecnologia, mesmo aquilo remotamente relacionado com o
tema, de maneira a pegar carona no interesse crescente da indústria. Os
vendedores sabem que se puderem usar a nova frase de efeito ou uma
palavra da moda em seus materiais de marketing, eles estão certos de
poder desfrutar de uma extensa cobertura da mídia. Este é o momento
quando os vendedores prometem o que não podem entregar. É conhecida
como fase do pico de expectativas infladas.
•
Após um curto período de tempo, os tomadores de decisão da indústria vão
descobrir que o produto ou serviço em questão oferece apenas uma
melhoria incremental e estão convictos que ele não vai resolver todos os
problemas em todos os lugares para todos. Isto é, quando as organizações
aprendem que os fornecedores só estão entregando parte daquilo que foi
prometido. Esta é denominada de fase do vale da desilusão.
•
Os tomadores de decisão da área de TICE,estão habilitados a determinar
se este produto ou serviço se encaixam ou não na solução de seus
problemas em infra-estrutura de TICE. É a fase dita aclive dos
iluminados.
13
•
A partir deste momento começa o uso produtivo da tecnologia. Então,
finalmente chegamos ao platô de produtividade.
Do ponto de vista dos fornecedores é do seu interesse manter esse
hype cycle pairando na segunda etapa do processo por tanto tempo quanto
possível, por outro lado, os usuários finais das organizações querem mover-se
rapidamente em direção as últimas etapas.
Isto, aliás, não é novidade. Aqui estão algumas outras coisas que
passaram pelo mesmo ciclo cada qual no seu tempo.
* Minicomputadores
* UNIX e "sistemas abertos"
* Windows da Microsoft e computação como commodity(comoditizada)
* Monitores de processamento de transações
* Software de banco de dados relacional
* Computação cliente / servidor
* Computadores portáteis
* Palm e PDAs
* Smartphones
* Aplicativos baseados na Web e a própria Web de per si
* Computação de utilidades (Utility computing)
No momento, em abril de 2010, a Computação em Nuvens está
entrando na fase 2 ou segunda etapa. Alguns fornecedores tais como Apple e
Microsoft, têm demonstrado domínio completo sobre os ciclos denominados
pelo grupo Gartner de “hypercicle”. Eles foram e são capazes de usar esse
modelo várias vezes a cada vez que novos produtos são introduzidos no
mercado.
Nas figuras 1 e 2 a seguir apresentamos exemplos de superciclos de
algumas tecnologias emergentes que se situavam em etapas diferentes
também denominadas humoristicamente de: (i) lançamento da tecnologia, (ii)
pico de expectativas infladas; (iii) vale da desilusão,(iv) aclive dos
iluminados e (v) platô de produtividade.
14
Figura 1. Hype Cycle of Emerging Technology Fonte:Gartner Group
Figura 2. Exemplo CRM do Hype Cycle Fonte:Gartner Research
1.2 - O Quadrante Mágico da virtualização de servidores
físicos com arquitetura x86.
A virtualização de servidores físicos com arquitetura x86 é uma das
tendências mais fortes em Tecnologia da Informação, Comunicação e
Entretenimento - TICE nos dias de hoje, e permanecerá assim durante vários
anos. A concorrência está amadurecendo, e o mercado tem um grande
número de opções viáveis.
15
habilidades, competências e capacidades de executar a visão
A virtualização de servidores físicos com arquitetura x86 tem sido um
mercado extremamente dinâmico (e uma grande tendência) desde que a
empresa VMware introduziu nos idos de 2001 os seus produtos com o objetivo
de criar máquinas virtuais em servidores. Durante vários anos, a concorrência
foi muito limitada. No entanto, a partir de 2006 (com as primeiras versões
comerciais de Xen) e 2008 surgiram (com o lançamento do Microsoft Hyper-V)
muitas alternativas de escolhas viáveis. Uma das possíveis escolhas poderá
recair sobre a empresa pioneira, devido a sua condição ótima de elegibilidade
situada no quadrante superior direito da figura 3 onde se destaca pela grande
habilidade de executar e por sua capacidade de visão adiante. Outra boa
escolha poderá recair na companhia Microsoft, posicionada no quadrante
superior esquerdo, ocupando a posição de grande desafiadora da líder de
mercado. Já a organização CITRIX que em 2007 adquiriu a XENSOURCE
também se posiciona de forma isolada, só que desta vez no quadrante inferior
direito classificada como uma instituição visionária. Todas as demais
sociedades estão situadas no quadrante inferior esquerdo da figura 3
reservado as empresas exploradoras de nichos de mercado.
Inicialmente utilizado apenas com o propósito de redução de custos, a
virtualização de servidores físicos com arquitetura x86 está sendo usada agora
também para acelerar os processos operacionais e a implantação de
servidores, além de criação de soluções de recuperação de desastres, onde
antes não existia, e melhorar a disponibilidade do servidor. A virtualização de
servidores com arquitetura x86 é agora considerada uma tendência geral
(cerca de 25%de aceitação pelo mercado), e o caminho estratégico de
virtualização de servidores físicos para utilização em ambientes de
computação em nuvem está se tornando mais evidente para as empresas.
Precisão,plenitude,integralidade e completude da visão
16
Figura 3. Quadrante Mágico para infraestrutura de virtualização de servidores na arquitetura x86.
1.2. 1 – Visão do Mercado
O mercado da infra-estrutura de virtualização de servidores x86 está baseado
em duas tendências de mercado extremamente atuais e importantes: a
modernização da infra-estrutura de Tecnologia da Informação, Comunicação e
Entretenimento - TICE e a computação em nuvem.
Com o objetivo de modernizar a infra-estrutura de TICE , a virtualização está
sendo usada para melhorar a utilização dos recursos, elevar a velocidade de
entrega de recursos e encapsular imagens de carga de trabalho de uma nova
forma que permite a automatização. O efeito da virtualização é também
abstrair os detalhes da implementação dos usuários, ajudando as
organizações de TICE ao longo da jornada para se tornar provedores de
serviços aos seus clientes empresariais (ao invés de ser meros hospedeiros de
equipamentos). A virtualização está permitindo uma mudança fundamental na
forma como as empresas gerenciam, implementam e entregam Tecnologia da
Informação, Comunicação e Entretenimento - TICE.
A virtualização também é um alicerce para os provedores de computação em
nuvem, que estão fornecendo infra-estrutura como serviço. Provedores como a
Amazon, GoGrid, GoDaddy.com e Terremark Worldwide estão usando
máquinas virtuais ou containers (recipientes) como base dos seus serviços de
computação em nuvens. Finalmente, a virtualização também será usada para
migrar em tempo real cargas de trabalho de e para as empresas e provedores
de serviços externos.
A infra-estrutura de virtualização de servidores x86 fornece a fundação para a
gerência mais moderna com novas ferramentas de automação, novas
arquiteturas de segurança, e novos processos. Embora as tecnologias no
mercado de infra-estrutura de virtualização de servidores x86 sejam apenas
facilitadoras, estas tecnologias serão usadas pelos vendedores para atrair
novos clientes para o nível superior de gerência e tecnologias de automação.
As escolhas feitas em camadas inferiores serão importantes.
O mercado recentemente tornou-se muito competitivo. Apesar da empresa
VMware, como pioneira do setor , ter hoje a parte do leão, o mesmo irá
crescer, em termos de volume, cinco vezes durante os próximos três anos.
Aquisições e novos investimentos têm trazido grandes fornecedores de
software, como a Microsoft e a Oracle para este mercado. Uma grande
porcentagem das empresas (principalmente pequenas e médias empresas)
ainda não começou a virtualizar, e eles têm hoje opções que não existiam há
nove anos. Durante os próximos anos, este mercado será influenciado por
novas aquisições, investimentos significativos no gerenciamento complementar
17
do ambiente, mercados de desenvolvimento de aplicações e automação, e
ampliação da tendência de computação em nuvens. Embora o valor para o
cliente continue mudando para ferramentas add-on e tecnologias para o
mercado de infra-estrutura de virtualização, a plataforma de virtualização de
baixo nível continuará a ser o fundamento para essas novas ferramentas, e
assim continuará a ser importante.
Este mercado foi lançado de forma pioneira pelas empresas VMware (para
empresas) e SWsoft (agora Parallels) e pela Xen quando se trata de código
aberto (para provedores de serviços). Os principais lançamentos de produtos
e aquisições ocorridas na história do mercado de infra-estrutura de
virtualização de servidores x86 incluem:
ANO
EVENTOS
2001
VMware ESX Server
SWsoft (now Parallels) Virtuozzo
2003
Xen (open source)
Microsoft acquires Connectix VM technology
2004
Microsoft Virtual Server 2005
EMC acquires VMware
SWsoft acquires Parallels
2005
Solaris 10 (includes Containers)
Novell Suse Linux Enterprise 10 (with Xen)
2006
XenSource XenServer
Virtual Iron
2007
KVM (open source — led by Qumranet)
Oracle VM
Red Hat Enterprise Linux 5.0 (includes Xen)
KVM included in Linux kernel
Citrix acquires XenSource
VMware partial initial public offering (IPO)
2008
Microsoft Hyper-V
Red Hat acquires Qumranet
2009
Red Hat Enterprise Virtualization (RHEV)
Oracle acquires Sun and Virtual Iron
Quadro: Histórico de Eventos Fonte: próprio autor
18
1.2.2 - Definição e descrição do Mercado
O mercado de infra-estrutura de virtualização de servidores x86 está
sendo definido pelas organizações que estão procurando soluções para
virtualizar suas aplicações a partir de seu próprio hardware de servidor com
arquitetura x86 ou sistemas operacionais, reduzindo a necessidade de novas
aquisições de hardware via eliminação do desperdício associado, e
aumentando a flexibilidade no fornecimento de capacidade do servidor em
sintonia com os requisitos demandados pelos aplicativos. Soluções para
alavancar este mercado:
•
Hypervisors
para
criar
máquinas
virtuais;
• Tecnologias de virtualização dos sistemas operativos compartilhados
(também
chamados de "containers");
• Gerenciamento administrativo da virtualização do servidor (baseado em
frameworks);
• Gerenciamento incorporado e embutido na virtualização de servidores
(migração em tempo real, automação básica das funções de gerenciamento
administrativo).
Não estão incluídas funções de gerenciamento de alto nível, tais como
ferramentas de automação operacional que reconhecem e incorporam a
virtualização, ferramentas de desempenho de aplicativos que alavancam e
monitoram a virtualização, ferramentas de recuperação de desastres que
potencializam a virtualização, etc.
1.2.3 - Critérios de Inclusão e Exclusão no Quadrante
Mágico adotados pela consultoria Gartner.
Os fornecedores que foram elegíveis pelo Gartner para inclusão neste
Quadrante Mágico preencheram os seguintes critérios:
19
1.
2.
3.
Devem fornecer soluções baseadas em servidores x86 para virtualizar
aplicações a partir de sistemas operacionais, ou sistemas operacionais a
partir de servidores com hardware x86, usando:
•
Hypervisors
• A tecnologia de Container
Devem fornecer ferramentas administrativas básicas para estas
soluções:
• suítes e frameworks para gerenciamento administrativo de
hypervisors / containers
• tecnologia de gerenciamento incorporada/embutida de
virtualização ( por exemplo, a migração em tempo real).
Devem ter pelo menos 100 organizações diferentes, utilizando os seus
produtos geralmente disponíveis a partir de 01 de fevereiro de 2010.
1.2.4 -
Comunidades de Código Aberto( por exemplo,
hypervisors Xen e KVN) versus Modelos de Negócios de
Software de Código Aberto patrocinados por fornecedores
O Quadrante Mágico da infra-estrutura de virtualização de servidor com
arquitetura x86 inclui apenas as ofertas comerciais baseadas em fornecedores,
e não posições individuais e avaliações de projetos de software open-source
(OSS), como o KVM e o Xen. A omissão de Xen e KVM como projetos de OSS
foi uma decisão deliberada. Os projetos open-source poderiam ser punidos
neste Quadrante Mágico, como conseqüência de ser um desenvolvimento
patrocinado por uma comunidade, se comparados com os objetivos
específicos de marketing e financeiros dos fornecedores utilizando a mesma
tecnologia subjacente. Temos lutado com os prós e contras de articular tais
inconvenientes, quando as organizações de TICE avaliam os méritos do
desenvolvimento apoiado em comunidade versus os projetos de virtualização
suportados por fornecedores.Inevitavelmente, as empresas dirigindo projetos
estratégicos de virtualização dentro de uma instituição ou agência de governo
precisam estar ciente de tais diferenças, mas o Quadrante Mágico é muitas
vezes uma ferramenta gráfica de alta influência na tomada de decisões na qual
a possível análise detalhada extraída do gráfico é encoberta ou não lida por
20
completo. Portanto, nós antecipamos que, quando as posições no gráfico da
Figura 3 - Quadrante Mágico foram traçadas para as empresas Oracle, Novell,
Citrix (responsável pelo Xen) e Red Hat (responsável pelo KVM), sua maior
pontuação alcançada nos critérios compreensão do marketing, estratégia de
marketing e estratégia de vendas, comparado com as versões open-source do
Xen e KVM , criaria contradições e confusão para aqueles que fazem
julgamentos precipitados sobre estas hypervisors.
As comunidades de código aberto são essencialmente fundadas e
dirigidas baseadas no desenvolvimento de código livre para prover serviços
específicos de software. A motivação geralmente gira em torno de uma
ausência de soluções na pilha de software livre OSS ou a falta de soluções
abertas competitivas equivalentes às proprietárias. No caso de Xen e KVM,
ambos surgiram para preencher uma lacuna no mercado para uma versão
open source de um hypervisor para Linux e outros ambientes OSS.
Comunidades de código aberto prosperam ao atrair o interesse dos
desenvolvedores que desejam fazer parte de uma equipe liderada pelos
"brilhantes" desenvolvedores de código e mantenedores. O Linux tem sido um
excelente exemplo, mas o Xen e o KVM também se tornaram outros exemplos
dignos.
Muitas
vezes,
porém, os desenvolvedores buscam melhores
recompensas monetárias (a menos que sejam empregados e apoiados por um
fornecedor).
A compensação financeira geralmente ocorre quando o projeto de
código aberto se torna a pedra angular da estratégia de um fornecedor que
realizou uma aquisição de outra empresa em que os salários e cargos de
gerência são as recompensas e a motivação contínua de melhorias lideradas
pelos projetos de OSS do vendedor (por exemplo, KVM pela Red Hat; Xen por
Citrix; MySQL pela Sun, e mais tarde Oracle e a aquisição da JBoss pela Red
Hat). Os resultados dessas aquisições se tornam fatores de influência na
análise do Quadrante Mágico do Gartner. Por exemplo, a liderança da
comunidade de código aberto Xen, foi adquirida pela Citrix, enquanto a equipe
de desenvolvimento do núcleo do KVM, originalmente formada por uma
empresa israelense chamada Qumranet, foi adquirida pela Red Hat.
21
Os produtos Xen (www.xen.org) e KVM (kvm.org ou www.linux)
continuam a existir como projetos independentes de software de código aberto.
As comunidades que os suportam continuam dando as boas vindas aos novos
desenvolvedores com o intuito de melhorar o código fonte e contribuir para
implementações adicionais (por exemplo,o Xen Cloud, o Xen Orchestra, a
Segurança, e a paravirtualização, etc), embora o projeto original do hypervisor
e muitos dos seus desenvolvedores tenham sido transferidos para um
fornecedor, e o núcleo do código do hypervisor tenha alcançado a estabilidade
para o fim pretendido. Enquanto isso, os vendedores se encarregam de
expandir o núcleo do código para desenvolver, ampliar e integrar os recursos
(por exemplo, a criação do ciclo de vida da máquina virtual, otimização,
planejamento
de
capacidade,
mobilidade,
diagnóstico,
monitoramento,
gerência de armazenamento, alta disponibilidade, portal, etc.). O Quadrante
Mágico representado pela figura 3 da infra-estrutura de virtualização de
servidor com arquiterura x86 destina-se ao mais alto nível de diferenciação no
mercado de virtualização em inovação, marketing, resultados financeiros, a
compreensão e a visão estratégica pelos fornecedores com soluções de
virtualização para plataformas de servidor com arquitetura x86.
Se tivéssemos decidido avaliar o Xen e o KVM, como posições
independentes das empresas CITRIX e RED HAT respectivamente, ocupando
cada qual posições próprias no Quadrante Mágico da figura 3, eles teriam
menores escores de avaliação para os critérios de orientados ao marketing,
porque os seus modelos são tecnicamente dirigidos em comparação com os
modelos de negócio alavancados e dirigidos por
fornecedores. Os
fornecedores são avaliados nos seus ecossistemas de gerenciamento, quanto
aos seus recursos financeiros, de vendas e marketing, e serviços de
integração. Os projetos de código aberto do tipo OSS não têm modelos de
negócio próprios ou recursos financeiros, além daquelas contribuições
voluntárias e de apoio na comunidade e entre os fornecedores.
Atualmente
os
usuários
têm
o
poder
de
optar
dentre
as
implementações específicas do fornecedor de virtualização ou entre os
projetos de código livre apoiados pela comunidade OSS, incluindo os 2 tipos
22
de
virtualização
(sistema
hypervisors),escolhendo
inclusive
operacional
as
ferramentas
hospedado
de
versus
gerenciamento
monitoramento, ou ainda construindo sua própria abordagem
e
com auto-
manutenção ou contando com o suporte dos provedores de serviços externos.
A abordagem de integração e auto-manutenção evita a onerosa subscrição de
licenças de suporte
e a criação de dependências do fornecedor, mas
contribuirá para elevação dos custos de suporte interno, caso as habilidades e
competências da equipe sejam mínimas ou a infra-estrutura existente mal
aplicada, resultando em custos iniciais de implementação superior a média e
tempos elevados de parada de produção e manutenção(downtimes).
CAPÍTULO II
MODELOS E TECNOLOGIAS
A computação em nuvem é uma área emergente que afeta a infraestrutura de TICE, serviços de rede e aplicações. Este capítulo II do presente
estudo apresenta os diferentes aspectos da computação em nuvem, incluindo
a fundamentação, os modelos subjacentes, e a infra-estrutura. O capítulo III vai
fornecer maiores detalhes sobre algumas das tecnologias específicas e
cenários.
O termo "Computação em Nuvem - CN" tem conotações diferentes para
profissionais de TICE, dependendo do seu ponto de vista e muitas vezes dos
seus próprios produtos e ofertas. Como em todas as áreas emergentes as
implantações no mundo real e histórias de sucesso de clientes irão gerar uma
melhor compreensão do termo. Essa discussão começa com a definição deste
termo pelo Instituto Nacional de Padrões e Tecnologia (NIST) norte-americano:
" Computação em Nuvem - CN (Cloud computing) é um modelo para permitir,
sob-demanda e de forma conveniente,o acesso através da rede há um
conjunto compartilhado e configurável de recursos de computação (por
exemplo, redes, servidores, armazenamento, aplicações e serviços) que tanto
podem ser rapidamente provisionados quanto liberados com um esforço
mínimo de gerenciamento ou com uma baixa interação do provedor de
serviços. "
23
Nuvens Híbridas
Nuvem
Privada
Software como
Serviço (SaaS)
Nuvem
Comunitária
Nuvem
Publica
Plataforma como
Serviço (PaaS)
Infraestrutura c/o
Serviço (IaaS)
Autoserviço sob Demanda
Acesso generalizado a
Rede
Rápida Elasticidade
Pool de Recursos
Serviços monitorados e
medidos
Escala Massiva
Computação Resiliente
Homogeinidade
Distribuição Geografica
Virtualização de
Servidores
Orientação à Serviço
Software de baixo custo
Segurança Avançada
Diagrama: Idéia de Nuvem Fonte: próprio autor
24
A seguir uma lista de características de um ambiente de computação em
nuvem - cn. Nem todas características podem estar presentes em uma solução
de nuvem específica.
• Elasticidade e escalabilidade: computação em nuvem nos dá a
possibilidade de expandir e reduzir os recursos de acordo com a
exigência de um serviço específico. Por exemplo, você pode precisar de
um grande número de recursos do servidor apenas no período de
duração de uma tarefa específica. Depois de concluir sua tarefa você
pode então liberar os recursos alocados desse servidor.
•
Pagamento pelo uso (Pay-per-use): Você paga pelos serviços de
nuvem somente quando você usá-los, tanto para o curto prazo (por
exemplo, tempo de CPU) quanto por um período mais longo (por
exemplo, para o armazenamento baseado em nuvem ou caixa-forte de
serviços (vault services)).
•
Sob demanda ou A pedido: Isto porque você demanda os serviços da
nuvem somente quando você precisa deles; eles não são parte
permanente de sua infra-estrutura de TICE, uma vantagem significativa
para a nuvem em vez de usar os serviços de TICE interna. Com os
serviços de nuvem, não há necessidade de ter recursos dedicados à
espera de ser utilizado, como é o caso de serviços internos.
•
Resiliência: A resiliência da oferta de serviços em nuvem pode isolar
completamente a falha de servidores ou de recursos de armazenamento
dos usuários da nuvem. O trabalho é migrado para um recurso físico
diferente na nuvem, com ou sem o conhecimento do usuário e a sua
intervenção.
• Múltiplos Inquilinos/Arrendatários (Multitenancy): provedores de
serviços públicos de nuvem freqüentemente podem arrendar os serviços
da nuvem para múltiplos inquilinos que são usuários simultâneos dentro
da mesma infra-estrutura. O isolamento do servidor e dos dispositivos
de armazenamento de cada diferente inquilino cliente pode se dar
25
fisicamente ou virtualmente, dependendo das necessidades específicas
requeridas pelos distintos usuários.
•
Movimento
da
Carga
de
Trabalho:
Esta
característica
está
relacionada com a propriedade de resiliência e com as considerações
de custo. Aqui, os provedores de CN podem migrar cargas de trabalho
entre os servidores, tanto no interior de um mesmo centro de dados
(Data Center), como através de diferentes centros de dados (mesmo no
caso deste estar localizado em outra área geográfica). Esta migração
pode ser necessária em virtude dos custos (mais barato executar um
trabalho em um centro de dados situado em outro país, com base na
hora do dia ou dos requisitos de potência energética) ou considerações
de eficiência (por exemplo, a largura de banda de rede). Uma terceira
razão poderia ser considerações regulatórias para certos tipos de
Movimento da Carga de Trabalho.
Figura 4: Contexto da Computação em Nuvem Fonte:IPJ Vol.12, No.3/4, 2010
CN implica mudar o montante dos custos lançados na rubrica das
despesas de capital (CapEx), derivados da compra e instalação de servidores,
dispositivos de armazenamento, redes e infra-estruturas correlacionadas, para
uma rubrica seguindo o modelo de despesas operacionais (OPEX), onde você
paga para a utilização desses tipos de recursos. Melhor dizendo esclarecemos
que CapEx, ou gastos em capital (capital expenditures) são despesas que
produzem benefícios ao longo de um período futuro longo (superior a um ano).
26
O CapEx ocorre quando uma empresa compra ativos (imobilizado) ou investe
em ativos já existentes que possuam uma vida útil superior ao exercício em
que ocorre a compra ou investimento. O CapEx é usado pela empresa para
adquirir ou melhorar ativos físicos tais como instalações, equipamento,
veículos e outro tipo de ativos que possuem vidas e usos que não se esgotam
no exercício em que são adquiridos e que, portanto, estão sujeitos a um
reconhecimento
do
respectivo custo ao
longo
de
vários
exercícios,
via amortizações.
A diferença entre uma despesa que é classificada como CapEx e uma
despesa normal é, portanto, o fato da totalidade da despesa normal ser
reconhecida no mesmo exercício em que ocorre, ao passo que os gastos de
capital são reconhecidos ao longo de diversos exercícios, mesmo que sejam
pagos totalmente no exercício em que ocorrem.
A Figura 4 apresenta um diagrama de contexto para CN.
Onde está a diferença da CN do serviço de hospedagem de hosts (
Hosted Services) ?
Do ponto de vista da infra-estrutura, a computação em nuvem é muito
semelhante aos serviços hospedados, um modelo criado há vários anos. Em
serviços hospedados, servidores, dispositivos de armazenamento e infraestrutura de rede são compartilhados entre vários inquilinos e , além disso,
também as várias conexões remotas disponíveis, estas com a singular
capacidade de escalar (apesar do novo dimensionamento ser feito muitas
vezes manualmente através do telefone ou do e-mail do provedor de
hospedagem). CN é diferente na medida em que oferece um modelo de
pagamento pelo uso (pay-per-use) rápido (e automático) e com capacidade de
escalar para cima ou para baixo os recursos alocados, juntamente com a
migração da carga de trabalho. Curiosamente, alguns analistas agrupam os
serviços de hospedagem subordinados a computação em nuvem quando
divulgam seus números de mercado.
27
Virtualização e seus efeitos sobre CN(Cloud Computing)
Pode argumentar-se sobre o efeito positivo que a computação em nuvem
causou
na
aceleração
especificamente
da
da
popularidade
virtualização
de
e
adoção
da
servidores. Então,
virtualização,
o
que
é
a
virtualização? Aqui, a virtualização de software é utilizada para executar
múltiplas máquinas virtuais (VMs) em um único servidor físico para fornecer as
mesmas funções que múltiplas máquinas físicas ofereceriam. Conhecido como
um hypervisor, o software de virtualização faz a abstração do hardware para as
VMs individuais.
A virtualização não é conceito novo, ele foi inventado e popularizado
pela IBM na década de 1960 para a execução de vários contextos de software
em seus computadores de grande porte (mainframe). Ele recuperou a
popularidade na última década em centros de dados por causa de
preocupações de uso do servidor. Os centros de dados e fazendas web (web
farms) consistem de múltiplos servidores físicos. Estudos contendo medições
de uso obtidas em servidores instalados em fazendas web observou que o uso
individual de cada servidor foi muitas vezes abaixo de 15 % , por várias razões,
incluindo as cargas de tráfego e à natureza das aplicações (disponível, nem
sempre totalmente utilizados), entre outros. A maior conseqüência dessa
expansão da quantidade de servidores com baixo uso era o grande impacto
financeiro gerado nos desembolsos tanto do tipo
CapEx quanto OpEx -
máquinas extras e novos custos relacionadas a alimentação elétrica e infraestruturas como refrigeração e bens imóveis.
Sobre virtualização. Um hypervisor pode ser implementado em um
servidor sendo executado diretamente sobre o hardware (um hypervisor de
Tipo 1) ou rodando sobre um sistema operacional (OS) (um hypervisor tipo
2). O hypervisor suporta a execução de várias máquinas virtuais e escalona
seus horários em conjunto com as VMs proporcionando-lhes um acesso
unificado e coerente para a CPU, memória e recursos de I / O na máquina
28
física. A VM normalmente executa um sistema operacional e aplicativos. As
aplicações não estão conscientes de que estão sendo executadas em um
ambiente virtualizado, de modo que não precisam ser alteradas para funcionar
em tal ambiente. A Figura 5 mostra esse cenário. O sistema operacional que
roda na máquina virtual(VM) pode sofrer virtualização -
conscientemente
exigem modificações para rodar por cima de um hypervisor - um esquema
conhecido como paravirtualização (em oposição a virtualização completa).
Migração de VM: Uma vantagem da virtualização
Alguns fabricantes implementaram a migração de VM em sua solução
de virtualização considerada uma grande vantagem para a manutenção do
tempo de disponibilidade (uptime) do aplicativo em um centro de dados. Mas o
que é
migração de VM? Consideremos o caso de um servidor com um
hypervisor e várias VMs, cada uma rodando um sistema operacional e
aplicativos. Se você precisar derrubar o servidor para manutenção (por
exemplo, para adicionar mais memória física ao servidor), você tem que
desligar os componentes de software e reiniciá-los após a janela de
manutenção, afetando significativamente a disponibilidade do aplicativo. A
migração de VM permite mover por completo uma VM (com seu sistema
operacional e aplicativos contidos) de uma máquina física para outra e
continuar a operação da máquina virtual na segunda máquina. Este benefício é
exclusivo para ambientes virtualizados, pois você pode desligar servidores
físicos para realizar tarefas de manutenção com um efeito mínimo sobre a
execução de aplicativos.
29
Figura 5: Hypervisors na Virtualização Fonte:IPJ Vol.12, No.3/4, 2010
Você pode realizar essa migração após a suspensão da VM na
máquina de origem, passando suas informações de atendimento para a
máquina destino e iniciá-la novamente na máquina de destino. Para diminuir o
tempo de inatividade, você pode executar essa migração enquanto a VM está
rodando (daí o nome "migração ao vivo") e retomar o seu funcionamento na
máquina de destino, após todo o estado ter sido migrado.
A seguir alguns dos benefícios da virtualização em um ambiente de
computação em nuvem:
• Elasticidade e escalabilidade: Inicializar e desligar VMs numa máquina física
envolve menos esforço em oposição à instalação de novos servidores e o seu
desligamento.
• Migração da carga de Trabalho: Através de funcionalidades, tais como
migração de “VM ao vivo”, você pode realizar a migração de carga de trabalho
com muito menos esforço em relação à migração da carga de trabalho através
da migração de servidores físicos em locais diferentes.
30
• Resiliência: Você pode isolar a falha do servidor físico do usuário do serviços
através da migração de VMs.
Deve ser esclarecido que a virtualização não é um pré-requisito para a
computação em nuvem. Na verdade, há exemplos de grandes provedores de
serviço de computação em nuvem usando apenas hardware de servidores
físicos comoditizados (sem virtualização) para implementar sua infraestrutura. No entanto, a virtualização fornece um conjunto valioso de
ferramentas e permite uma flexibilidade significativa nas implementações de
computação em nuvem.
Modelos de Serviço importantes em Computação em Nuvens
Esta seção discute alguns modelos populares de computação em nuvem que
hoje são oferecidos como serviços. Embora exista um amplo consenso sobre
estes modelos de serviço, há variações específicas com base em ofertas de
provedores que não surpreende nestes primeiros dias da computação em
nuvem.
Software de nuvem como um Serviço (SaaS)
Considere o caso de uma empresa com seu conjunto de licenças de software
para as várias aplicações que utiliza. Estas aplicações podem ser na área de
recursos humanos, finanças, ou relacionamento com o cliente para citar
alguns. Ao invés de obter licenças para desktop e servidor de produtos de
software que utiliza, uma empresa pode obter as mesmas funções através de
um serviço hospedado de um provedor por meio de uma conexão de rede. A
interface do software é geralmente através de um navegador web. Esse
modelo mais comum de computação em nuvem é conhecido como Software
como Serviço (SaaS) ou um modelo de software hospedado; o provedor é
conhecido como o provedor de SaaS.
31
O modelo de serviço SaaS resguarda a complexidade da instalação do
software, manutenção, upgrades e patches (por exemplo, correções de
segurança) da equipe de TICE interna da empresa, porque o software é agora
gerido centralmente nas instalações do provedor de SaaS. Além disso, o
provedor de SaaS pode fornecer este serviço para vários clientes e empresas,
resultando em um modelo de múltiplos inquilinos (multitenant). O preço desse
serviço SaaS é tipicamente cobrado em uma base por usuário para uma
determinada
largura
de
banda
fixa
e
determinada
capacidade
de
armazenamento. Monitorar o desempenho alcançado pelos aplicativos usados
pelo cliente é da responsabilidade do provedor de SaaS. Salesforce.com é
um exemplo de um provedor de SaaS. A empresa foi fundada para fornecer
serviços hospedados de software, diferentemente de alguns provedores de
software que tem versões hospedadas de suas ofertas convencionais.
Plataforma de nuvem como um Serviço(PaaS)
Ao contrário das funções fixas oferecido pelo SaaS, a plataforma como serviço
(PaaS) fornece uma plataforma de software no qual os usuários podem
construir suas próprias aplicações e hospedá-las em infra-estrutura do
provedor de PaaS. A plataforma de software é utilizada como um framework de
desenvolvimento
para
compilar,
depurar
e
implantar
aplicativos. Freqüentemente fornece serviços de estilo middleware, tais como
banco de dados e serviços de fornecimento de componentes para uso por
aplicativos. PaaS é um verdadeiro modelo de nuvem em que as aplicações
não precisam se preocupar com a escalabilidade da plataforma subjacente
(hardware e software).Quando as empresas desenvolvem suas aplicações
para funcionarem sobre a plataforma de software do provedor PaaS , as
propriedades
de
elasticidade
e
escalabilidade
são
garantidas
transparentemente pela plataforma PaaS.
As plataformas oferecidas por vendedores de soluções PaaS como o Google
32
(com a sua App-Engine) ou Force.com (a oferta do provedor PaaS
denominado Salesforce.com) requer que os aplicativos sejam desenvolvidos
obedecendo
suas
próprias
Interfaces
de
Programação
de
Aplicação
(Application Programming Interface (API)) e sejam escritas em uma linguagem
específica. Esta situação é susceptível de mudar, mas é um motivo de
preocupação quanto ao aprisionamento (lock-in). Além disso, não é fácil migrar
aplicações existentes para um ambiente PaaS. Por conseguinte, PaaS alcança
maior sucesso com as novas aplicações desenvolvidas especificamente para a
nuvem. Monitorar o desempenho alcançado pelos aplicativos usados pelo
cliente também é da responsabilidade do provedor de PaaS. A precificação
para serviços PaaS pode ser na base de uma licença de desenvolvedor do
aplicativo e em uma base de lugares hospedado. Note-se que o serviço PaaS
tem um maior grau de controle do usuário do que o serviço SaaS.
Infra-estrutura de nuvem como serviço (IaaS)
Amazon é sem dúvida o primeiro grande defensor da Infra-estrutura como
serviço (IaaS) através de seu serviço Elastic Cloud Computing (EC2). Um
provedor de IaaS oferece "raw" computação, armazenamento e infra-estrutura
de rede de modo que você pode carregar o seu próprio software, incluindo
sistemas operacionais e aplicativos, sobre esta infra-estrutura. Este cenário é
equivalente a um provedor que hospeda servidores físicos e provisionamento
de armazenamento e que lhe permite instalar o seu próprio sistema
operacional, os serviços web e aplicações de banco de dados sobre as
máquinas provisionados. Amazon permite alugar servidores com uma
velocidade de CPU determinada, memória e capacidade do disco juntamente
com o sistema operacional e os aplicativos que você precisa ter instalado neles
(Amazon fornece algumas "software" enlatado para o sistema operacional e
aplicativos conhecidos como Amazon Machine Images [AMIs ], de modo que
é um ponto de partida). No entanto, você também pode instalar seu próprio SO
(ou
não
OS)
e
aplicações
em
infra-estrutura
de
servidor.
IaaS oferece o maior grau de controle dos três modelos. Você precisa
33
conhecer as necessidades de recursos para sua aplicação específica para
bem explorar IaaS.Dimensionamento e elasticidade são sua tarefas, e não
responsabilidade do provedor. Na verdade, é um centro de dados do tipo façavoce-mesmo que você tem que configurar para fazer o trabalho.Curiosamente,
a Amazon utiliza a virtualização como um alicerce fundamental do seu serviço
EC2, logo o que você realmente obtém é uma máquina virtual quando você
perguntar para uma configuração específica da máquina, embora máquinas
virtuais (VMs) não sejam um pré-requisito para IaaS. A precificação dos
serviços IaaS pode ser na base do seu uso ou mediante subscrição de
assinatura. Tempo de CPU, espaço de armazenamento e a largura de banda
(relacionados com a circulação dos dados) são alguns dos recursos que
podem
ser
faturados
numa
base
de
uso.
Em resumo, estes são três dos modelos mais comuns para a computação em
nuvem. Eles têm variações e add-ons, incluindo armazenamento de dados
como um serviço (fornecimento de acesso a disco na nuvem), a comunicação
como um serviço (por exemplo, um número de telefone universal através da
nuvem), e assim por diante.
Nuvens Pública, Privada e Interna
Nós nos concentramos em provedores de serviços de nuvem cujos centros de
dados são externos aos usuários do serviço (empresas ou indivíduos). Estas
nuvens são conhecidas como nuvens públicas, tanto a infra-estrutura quanto
o controle dessas nuvens é com o provedor de serviços. Uma variação deste
cenário é a nuvem privada. Aqui, o provedor de nuvem é responsável apenas
pela infra-estrutura e não pelo controle. Esta configuração é equivalente a uma
parte de um centro de dados compartilhado que é particionada para utilização
por um cliente específico. Note-se que a nuvem privada pode oferecer serviços
SaaS, PaaS, ou IaaS, embora os serviços IaaS aparentem ser um ajuste mais
natural.
Uma nuvem interna é um termo relativamente novo, aplicado à nuvem de
34
serviços prestados pelo departamento de TICE de uma empresa a partir de
centros de dados da própria empresa. Esta configuração pode parecer contraintuitivo a primeira vista - por que uma empresa proveria serviços de nuvem
para
seus
usuários
disponíveis? Não
internos,
estaria
quando
tal configuração
as
nuvens
anulando
as
públicas
estão
vantagens de
elasticidade e escalabilidade movendo este serviço para dentro da empresa?
Por outro lado, o que acontece é que o modelo de nuvem interna é muito útil
para as empresas. Do ponto de vista das empresas a maior preocupação ao
propor uma mudança para um provedor de computação em nuvem externo são
as questões de segurança e controle. CIOs são naturalmente cautelosos
quando se trata de mover sua infra-estrutura de aplicativo e os dados por
inteiro para um provedor de nuvem externa, especialmente quando se têm
várias pessoas/anos de investimento em suas aplicações e infra-estrutura,
bem como garantias de segurança elaborado em torno de seus dados. No
entanto, as vantagens da computação em nuvem, tais como resiliência,
escalabilidade e migração de carga de trabalho é muito útil tê-las em centros
de dados da própria empresa. A área de TICE da empresa pode usar
faturamento por uso para controlar unidades de negócios individuais ou
controlar o uso departamental dos recursos de TICE
e cobrá-los de
volta. Controlar a proliferação de servidores através da virtualização e a
movimentação das cargas de trabalho que se deslocam para regiões e locais
do mundo, com mais baixos custos de energia e infra-estrutura são de grande
valor em um ambiente de computação em nuvem. Nuvens internas podem
fornecer todos estes benefícios.
Esta classificação de nuvens, como pública, privada e interna não é
universalmente aceito. Alguns pesquisadores vêem a distinção entre as nuvens
privadas e internas como uma pura questão semântica. Na verdade, a
definição proposta no projeto (draft) do NIST considera uma nuvem privada
como sendo o mesmo que uma nuvem interna. No entanto, os conceitos ainda
são válidos e são percebidos pelas empresas provedoras de serviços e nos
ambientes atuais de TICE.
35
Quando é que CN faz sentido?
Terceirização (Outsourcing) completa da infra-estrutura de TICE para um
provedor de CN faz sentido se a sua implantação é um típico "green field"
,especialmente no caso de estar começando a operar, isto é, uma empresa
iniciante . Aqui, você pode se concentrar no seu negócio sem ter que
configurar e provisionar sua infra-estrutura de TICE, especialmente se envolver
principalmente elementos básicos, tais como e-mail, processamento de texto,
ferramentas de colaboração, e assim por diante. Quando sua empresa cresce,
a nuvem fornecida pelo ambiente de TICE pode escalar junto com ela.
Outro cenário para o uso da nuvem é quando um departamento de TICE
precisa incrementar rapidamente o acesso a recursos adicionais de TICE para
satisfazer uma exigência de curto prazo. Exemplos incluem o teste de um
aplicativo desenvolvido internamente para determinar a escalabilidade, a
prototipagem de "software" fora do padrão para avaliar a adequação, a
execução de uma tarefa de uma só vez com uma demanda exponencial sobre
os recursos de TICE, e assim por diante. O termo “cloud bursting” é muitas
vezes usado para descrever este cenário. Os recursos da nuvem podem ser
suavemente ou fortemente associados com os recursos internos de TICE
enquanto perdurar o incremento rápido de recursos adicionais “cloud
bursting”. Em um cenário extremo de baixo acoplamento, apenas os resultados
da “cloud bursting” são fornecidos para o departamento de TICE interno. No
cenário fortemente acoplados, os recursos da nuvem e os recursos internos de
TICE estão sendo usados na solução do mesmo problema e exigem a
comunicação freqüente e compartilhada dos dados.
Em algumas situações, a computação em nuvem não faz sentido para uma
empresa. Considerações jurídicas e regulatórias podem ditar a necessidade
de manter o controle dos dados em segurança na sede da empresa, ou em
um local específico ou área geográfica determinada. Pode ser necessário que
36
o acesso aos dados seja restrito a um conjunto limitado de aplicativos, os quais
precisam ser interno. Outra situação em que a computação em nuvem não é
sempre a melhor opção é quando o tempo de resposta do aplicativo é
crítica. Departamentos de TICE
internos à empresa
podem planejar
sua
infra-estrutura de servidores e sua infra-estrutura de rede para acomodar os
requisitos de tempo-resposta críticos. Apesar de alguns provedores de CN
fornecerem enlaces (links) de alta largura de banda e serem capazes de
especificar Acordos de Nível de Serviço ( Service-Level Agreements - SLAs)
(especialmente no caso do SaaS) para as suas ofertas, as empresas poderiam
ser melhor atendidas no caso dessas aplicações exigentes quando executam
em casa.
Uma interessante variação desses cenários é quando as empresas terceirizam
sua interface WEB (web front ends) com um provedor de nuvem e mantém a
sua aplicação e os servidores de base de dados internos à empresa. Isto é, o
servidor web na nuvem e os servidores de aplicação e de base de dados na
própria empresa. Essa configuração é útil quando a empresa está
incrementando suas ofertas na web, mas não está completamente convicta
sobre a demanda gerada. Pode começar com um pequeno número de
servidores web e escalar para cima ou para baixo conforme o comportamento
da demanda. Além disso, dispositivos de aceleração, como Application
Delivery Controllers (ADCs) podem ser colocados na frente dos servidores web
para garantir o desempenho. Estes dispositivos fornecem balanceamento de
carga do servidor, front-ends para Secure Sockets Layer (SSL), cacheamento
de dados e compressão. A implantação desses dispositivos e da infra-estrutura
associada ao front-end pode ser completamente transparente para a empresa
que só precisa se concentrar sobre a disponibilidade e o tempo de resposta de
suas aplicações que se localizam por trás dos servidores web.
Infra-estrutura de Computação em Nuvem
A discussão mais importante sobre infra-estrutura está relacionada com o
37
centro de dados, a interligação de centros de dados e sua conectividade para
os usuários (empresas e consumidores) do serviço de nuvem.
A visão simplista do centro de dados em nuvem é que ele é semelhante a um
centro de dados corporativo, mas em uma escala diferente, porque tem de
suportar vários inquilinos e fornecer escalabilidade e elasticidade. Além disso,
os aplicativos hospedados na nuvem, bem como a virtualização (quando é
utilizado) desempenham também um outro papel.
Um caso ilustrativo é o paradigma de computação MapReduce que o Google
implementa para fornecer alguns dos seus serviços (outras empresas possuem
suas próprias implementações de MapReduce). Simplificando, o esquema do
MapReduce tem um conjunto de entrada de pares chave-valor, faz o seu
processamento, e produz um conjunto de saída de pares chave-valor. Para
realizar a implementação, o Google tem uma infra-estrutura de servidores
commoditizados
rodando
Linux
interligados
por
switches
Ethernet. Os
dispositivos de armazenamento são discos locais de baixo custo padrão
Integrated Drive Electronics (IDE) conectados a cada servidor.
Jobs, que consistem de um conjunto de tarefas, são escalonados,
programados e mapeados para o conjunto de máquinas disponíveis. O sistema
é implementado através de uma máquina mestre (Master) e várias máquinas
escravas (Workermachines). Estas últimas são escalonadas pelo Mestre para
implementar as tarefas de Map e Reduce, que operam sobre blocos do
conjunto de dados de entrada armazenados localmente. A topologia e a
distribuição de tarefas entre os servidores é otimizada para a aplicação
(MapReduce neste caso). Embora a Google não tenha tornado público os
detalhes de como a infra-estrutura de back-end é implementada para o seus
aplicativos Google Apps e Gmail, podemos supor que a organização física e
lógica é otimizada para as tarefas que precisam ser realizadas, de forma
semelhante ao que é feito para MapReduce.
38
Provedores de SaaS podem particionar seus centro de dados de nuvem de
acordo com a carga, inquilino e tipo de aplicação que eles oferecem como um
serviço. Em alguns casos eles podem ter de redirecionar o tráfego para um
centro de dados diferente, baseado na carga do centro de dados padrão. IaaS
proporciona o maior grau de controle para o usuário, como discutido
anteriormente. Mesmo aqui, a topologia e atribuição de carga pode ser
baseada no número e tipo de servidores que são alocados.
Infra-estrutura de armazenamento
Os dispositivos de armazenamento desempenham um papel importante tanto
no centro de dados quanto nos serviços em nuvem, especialmente em
ambientes com virtualização. Os dispositivos de armazenamento podem estar
conectados localmente ou acessíveis por meio de uma rede - as mais
populares das tecnologias de armazenamento em rede são a Fibre Channel e
o Ethernet. Para acessar essa rede exclusiva de armazenamento, os
servidores estão equipados com adaptadores compatíveis com a tecnologia
Fibre Channel (adaptadores Fibre Channel) ou cartões de interface de rede
padrão Ethernet (adaptadores Ethernet) através do qual eles se conectam a
um canal de fibra ótica ou a um switch Ethernet. O switch oferece a
conectividade para arrays de armazenamento. A tecnologia Fibre Channel é
ainda mais popular, apesar de dispositivos com interfaces Ethernet (Network
Attached Storage - NAS) também terem uma forte presença no centro de
dados.Outra opção de rede de armazenamento baseado em Ethernet é a
tecnologia denominada Internet Small Computer System Interface (iSCSI), que
é bastante popular entre os pequenos centros de dados e nas empresas por
causa da relação custo benefício favorável. Esta tecnologia envolve a
execução do protocolo SCSI em uma conexão TCP/IP sobre o Ethernet(TCP /
IP-over-Ethernet).
Conexões Fibre Channel para os dispositivos de armazenamento em rede
39
necessitam de dois tipos de tecnologias de rede no centro de dados: Ethernet
para a ligação servidor-servidor e servidor-cliente; e Fibre Channel para
conexão entre servidores e dispositivos de armazenamento. Uma iniciativa
recente em tecnologia de centro de dados é uma rede convergente, que
envolve o transporte de Fibre Channel sobre Ethernet (FCoE). O FCoE elimina
a necessidade de cada servidor ter um adaptador Fibre Channel próprio para
se conectar ao dispositivo de armazenamento. Em vez disso, o tráfego Fibre
Channel é encapsulado dentro de um quadro Ethernet e estes são enviados
através de um gateway FCoE que ,na outra extremidade da conexão, fornece
a conversão do Ethernet para o FCoE (Ethernet-to-FCoE) com o intuito de
conectar-se aos arrays de armazenamento que falam apenas Fibre Channel
(veja a figura 6). Alguns produtos/dispositivos de armazenamento já oferecem
funções embutidas de conversão de FC para ETH, isto é, armazenamento
FCoE, desta forma o quadro Ethernet pode ser conduzidos até a extremidade
onde se localiza o array de armazenamento que ele próprio se encarrega da
conversão, eliminando a necessidade de um gateway FCoE. Um adaptador ou
placa de rede espetada no servidor que fornece conexão clássica "Ethernet" e
funções de FCoE é conhecida como uma placa/adaptador de rede
convergentes (CNA). Os ambientes de computação em nuvem podem reduzir
a complexidade da rede de dados e o custo de um centro de dados através da
adoção desta nova tecnologia compatível com as redes convergentes.
Outra área em que o armazenamento é importante é na virtualização e na
migração em tempo real. Quando uma VM migra para uma outra máquina
física, é importante que os dados utilizados pela máquina virtual sejam
acessíveis tanto pela origem quanto pelas máquinas-alvo. Alternativamente, se
a VM é migrada para um centro de dados remoto, logicamente que também os
dados armazenados devem ser migrados. Além disso, em um ambiente
virtualizado, os drivers das placas adaptadoras de rede do tipo Fibre Channel,
Ethernet, ou CNA(convergentes) devem suportar múltiplas máquinas virtuais e
intercalam os diferentes tráfegos de armazenamento gerados pelas VMs em
seus dispositivos de armazenamento. Este entrelaçamento é feito em
40
consonância com o hipervisor e com uma VM designada (ambientes
virtualizados costumam usar essa ferramenta), conforme o caso.
Figura 6: FCoE in a Cloud Data-Center Environment Fonte:IPJ Vol.12, No.3/4, 2010
Computação em nuvem: Efeito na Rede
A discussão anterior indica que a rede é uma parte grande e importante da
computação em nuvem. Um usuário da nuvem se conecta à rede para acessar
os recursos da nuvem, como indicado anteriormente na Figura 4. A nuvem é
acessível através de uma rede pública (Internet) ou através de uma rede
privada (linhas dedicadas ou Multiprotocol Label Switching [MPLS infraestrutura], por exemplo). Portanto, garantia de tempo de resposta dos
aplicativos usados na nuvem dependerá dessa conectividade. Alguns
provedores de nuvem oferecem enlaces (links) dedicados para seus centros de
dados e provêem Acordos de Nível de Serviço – ANS (prestação de SLA) para
garantia do tempo de disponibilidade (uptime) e do tempo de resposta
apropriado, evidentemente que de forma onerosa, faturando como serviço
prestado dentro do ANS(SLA).Outros podem aplicar um regime de melhor
41
esforço, mas fornecendo ferramentas para monitorar e caracterizar o
desempenho do aplicativo e seu tempo de resposta, de modo que os usuários
podem planejar suas necessidades de largura de banda.
O efeito mais significativo sobre a rede está no centro de dados, conforme
indicado anteriormente. Comecemos com a arquitetura de rede ou sua
topologia. A arquitetura de rede mais comum para as empresas é a arquitetura
de três camadas com acesso, agregação ou distribuição e switches de núcleo
(core) ou de backbone. O centro de dados exige uma leve variação que o torna
um pouco diferente destas 3 camadas, como proposto por alguns
vendedores. O centro de dados é constituído principalmente de servidores de
bandeja/prateleira montados e instalados em bastidores(racks) formando um
conjunto interligado através de um switch Ethernet colocado no topo do
bastidor denominado Top-of-rack (TOR) que, por sua vez, se conecta a um
switch de agregação, também conhecida como um switch End-of-Rack (EOR)
(Figura 4) .
O switch de agregação se conecta a outros switches de agregação e através
desses se conecta com outros servidores no centro de dados. Um switch de
núcleo (core) se conecta à vários switches de agregação e fornece a
conectividade com o mundo exterior, normalmente através de nível 3 (Layer 3
(IP)). Pode-se argumentar que a maior parte do tráfego intra centro de dados percorre apenas o switch TOR e os switches de agregação. Assim, os enlaces
(links) entre esses switches e a largura de banda desses enlaces (links)
precisam levar em conta os padrões de tráfego. Alguns vendedores
propuseram uma árvore do tipo FAT-TREE (arvore gorda) ou uma topologia do
tipo LEAF-SPINE(espinha- folha) para resolver esta anomalia, embora esta
não seja a única maneira de projetar a rede do centros de dados. Aliás, a
topologia em árvore do tipo FAT-TREE (arvore gorda) não é nova, ela tem sido
usada em redes padrão Infiniband no centro de dados.
42
Figura 7: Example Data-Center Switch Network Architecture Fonte:IPJ Vol.12, No.3/4, 2010
A presença de servidores virtualizados adiciona uma dimensão
extra. As conexões de rede para servidores físicos terão de envolver grandes
capacidades "fatter pipes", porque o tráfego de várias VMs será multiplexado
para a mesma conexão física Ethernet. Este resultado é esperado porque você
efetivamente agrupou vários servidores físicos em um único servidor físico com
VMs. É bastante comum ter servidores com placas adaptadoras de rede com
padrão Giga Ethernet de 10 Gbps neste cenário.
Novos protocolos para conexões em rede nos Centros de Dados
Numerosas iniciativas e vários organismos de normalização estão se
dedicando e abordando os padrões relacionados à computação em nuvem. Do
lado da rede e focado nos protocolos de baixo nível, o Instituto norteamericano de Engenheiros Elétricos e Eletrônicos conhecido pela sigla IEEE
está
trabalhando
no
desenvolvimento
de
novos
protocolos
e
no
aperfeiçoamento e aprimoramento dos protocolos existentes para centros de
dados. Essas melhorias são particularmente úteis em centros de dados com
redes convergentes – esta nova área é muitas vezes conhecida como
Convergence Enhanced Ethernet (CEE).
43
A seção anterior indicou a importância de FCoE para ambientes de rede
conectando dispositivos de armazenamento convergentes. O Instituto norteamericano de Engenheiros Elétricos e Eletrônicos conhecido pela sigla IEEE
está trabalhando para oferecer garantias FCoE ( porque o Fibre Channel é um
protocolo mais confiável em relação ao paradigma do melhor esforço do
padrão Ethernet) através de um enlace (link) Ethernet no que é conhecido
como "Lossless Ethernet." FCoE é ativado através de um mecanismo de
controle de fluxo com prioridades (Priority Flow Control (PFC)) contido nas
atividades de desenvolvimento do rascunho(draft) do padrão 802.1Qbb do
IEEE. Noutra linha diferente,o draft do padrão IEEE 802.1Qau provê
notificação de congestionamento fim-a-fim através de um mecanismo de
sinalização cuja propagação alcança a porta de entrada, isto é, a porta
conectada a placa de interface de rede(NIC) do servidor. Esse recurso é útil
em uma topologia de centro de dados.
Um terceiro rascunho (draft) de projeto de padrão denominado IEEE
802.1aq define uma construção de ponte de caminho mais curto. Este trabalho
é semelhante ao trabalho que vem sendo feito pelo grupo de trabalho
conhecido como IETF TRILL (Transparent Interconnect of Lots of Links) da
Força Tarefa de Engenharia da Internet ( Internet Engineering Task Force –
IETF) que é responsável pela engenharia e desenvolvimento de protocolos da
Internet, onde atua subdividindo suas tarefas por grupos de trabalho(working
groups) que se responsabilizam pela especificação das normas conhecidas
como Request For Comments - RFCs. A principal motivação por trás deste
trabalho é a natureza relativamente plana da topologia de centro de dados e da
obrigação de encaminhar pacotes através do caminho mais curto entre os
terminais (servidores) para reduzir a latência, ao invés de uma root bridge ou
mecanismos de prioridades normalmente utilizados no Spanning Tree Protocol
(STP). O caminho mais curto de ponte no rascunho(draft) de projeto IEEE
802.1aq é uma iniciativa incremental de avanço para o novo
Multiple
Spanning Tree Protocol (MSTP), que usa o protocolo de roteamento do tipo
estado dos enlaces Intermediate System-to-Intermediate System (IS-IS) para
44
compartilhar as topologias de rede apreendidas por entre os switches e para
determinar o caminho mais curto entre os dois pontos extremos.
O quarto rascunho(draft) de projeto IEEE 802.1Qaz também é conhecido como
Enhanced Transmission Selection (ETS).Ele permite a explosão do tráfego
de baixa prioridade e o uso da largura de banda não utilizada advindas das
filas de tráfego de maior prioridade, proporcionando assim maior flexibilidade.
Funções dos Equipamentos de Rede Virtualizados
Embora a computação em nuvem não dependa de virtualização, várias infraestruturas de nuvens são construídas com servidores virtualizados. Em um
ambiente com servidores físicos, switches são usados para conectar
servidores com outros servidores. Firewalls e controladores de entrega de
aplicativos são outros tipos de equipamentos que você pode usar em um
centro de dados para otimizar e aperfeiçoar a conexão com seus clientes
externos. Em um ambiente virtualizado, você pode mover algumas ou todas
essas funções agrupando-as no interior de um servidor.
Considere o caso do Switch Virtual baseado em software como mostrado na
Figura 8. Ele não é um equipamento de fato, mas sim um software rodando
num servidor. Você pode usar o switch virtual para alternar entre as máquinas
virtuais dentro do mesmo servidor físico e fazer a agregação do tráfego para a
conexão
com
o
switch
externo. O
switch
virtual
é
freqüentemente
implementado como um plug-in para o hypervisor. As VMs têm adaptadores
Ethernet virtuais que se conectam ao switch virtual, que por sua vez se conecta
à placa de rede física do servidor e ao switch Ethernet externo. Para o
administrador da rede, o switch virtual pode aparecer como uma parte da
rede. Ao contrário de switches reais, o switch virtual não necessariamente tem
que rodar os protocolos de rede para operação, nem tem a necessidade de
tratar todas as suas portas da mesma forma, pois sabe que algumas delas são
conectadas a portas virtuais Ethernet (por exemplo, pode evitar o aprendizado
45
do endereço de destino nas portas conectadas as VMs). Ele pode funcionar
através de uma configuração adequada realizada a partir de uma entidade de
gerenciamento externa.
Figura 8: Virtual Ethernet Switch in a Virtualized Server Environment Fonte:IPJ Vol.12, No.3/4, 2010
É possível implementar um firewall virtualizado em uma máquina virtual
em vez de tratá-lo como um plug-in para o hypervisor. Essas VMs são autosuficientes, com um sistema operacional próprio, juntamente com a instalação
do software de firewall. O pacote completo é conhecido como um dispositivo
de firewall
virtualizado (firewall appliance virtual). Essas VMs podem ser
carregados e configurados de modo que os pacotes da rede destinados a
qualquer uma das VMs possam passar pela VM firewall, onde são validados
antes de serem passados para as outras VMs. Outro uso da VM firewall é
como um front-end para os servidores físicos no centro de dados. A
desvantagem de um dispositivo virtual (appliance virtual) é o desempenho
46
atingido, devido à sua implementação como uma função de software em um
ambiente virtualizado.
Gerenciamento ou Gestão
A gerência tem várias dimensões em um ambiente de computação em nuvem:
faturamento,
monitoramento
de
tempo
de
resposta
dos
aplicativos,
configuração dos recursos de rede (virtual e físico) e a migração de carga de
trabalho. Em uma nuvem privada ou num ambiente fortemente acoplado, os
gerenciamentos das aplicações podem ter que ser partilhados entre a nuvem
interna e a nuvem privada.
Você pode gerenciar ambientes de computação em nuvem de várias maneiras,
dependendo da área específica. Você pode gerenciar os equipamentos de
rede (físicos e virtuais), através do uso do protocolo de gerenciamento da
família TCP/IP denominado Simple Network Management Protocol (SNMP) e
de uma máquina operando exclusivamente como console de gerenciamento de
rede. Em um ambiente virtualizado, o provedor de virtualização, muitas vezes
oferece uma estrutura para gerir e controlar VMs, então isso é uma outra parte
da equação. Vários provedores oferecem produtos capazes de atuar como
interface de gerenciamento para nuvens públicas, como por exemplo, o da
Amazon, cujos produtos funcionam como corretores e consoles de
gerenciamento para o seu aplicativo implantado sobre a oferta de nuvem da
Amazon.
É evidente que esta área de gerenciamento para a computação em nuvem
ainda está evoluindo e precisa ser agrupada conjuntamente com uma visão
unificada de gestão.
Computação em nuvem : 5 mitos comuns.
47
Até
agora,
temos
considerado
importantes
as
tecnologias,
a
terminologia e os desenvolvimentos em computação em nuvem. Esta seção
descreve alguns mitos comuns sobre a computação em nuvem.
• Mito 1: Computação em nuvem pode satisfazer todos os
requisitos especificados: escalabilidade, sob demanda, pagamento pelo
uso, resiliência, múltiplos inquilinos e migração de carga de trabalho.
De fato, as implantações de computação em nuvem, raramente
satisfazem todos os requisitos. Dependendo do tipo de serviço ofertado (SaaS,
IaaS ou PaaS), o serviço pode satisfazer subconjuntos específicos desses
requisitos. Há, no entanto, o valor agregado de tentar satisfazer a maioria
destes requisitos quando você está construindo um serviço em nuvem.
• Mito 2: Computação em nuvem é útil somente se você estiver
terceirizando suas funções de TICE para um provedor de serviços
externos.
Não é verdade. Você pode usar computação em nuvem internamente
em seu departamento de TICE para implantações onde estas características
são relevantes: sob demanda, escalável e de pagamento pelo quanto
usa. Vários provedores oferecem ferramentas de software que você pode usar
para criar nuvens no centro de dados da sua própria empresa.
• Mito 3: Computação em nuvem exige virtualização.
Embora a virtualização traga alguns benefícios para a computação em
nuvem, incluindo aspectos como o uso eficiente de servidores e a migração de
carga de trabalho, não é um pré- requisito mandatório para a computação em
nuvem. No entanto, é provável que vejamos o aumento do uso da virtualização
em implantações de nuvens.
• Mito 4 : Computação em nuvem exige que você exponha seus
dados para o mundo exterior.
Com nuvens internas, você nunca terá de expor seus dados para o
mundo exterior. Se a segurança e a privacidade dos dados são preocupações,
você pode desenvolver um modelo de nuvem onde interfaces WEB são front
end
localizados na nuvem e os dados de back end sempre residam nas
instalações da sua empresa.
48
• Mito 5 : Redes Convergentes são essenciais para a computação
em nuvem.
Embora redes convergentes (com FCoE, por exemplo) possuam inúmeros
benefícios e no futuro iremos acompanhar o aumento da sua adoção em
centros de dados , a computação em nuvem é possível sem redes
convergentes. De fato, alguns vendedores de soluções em nuvem utilizam
apenas Fibre Channel para todas as suas necessidades de armazenamento de
hoje. O uso de redes convergentes, no futuro, irá resultar em ganhos de
eficiência, mas não é uma exigência de hoje.
Computação em nuvem: Lacunas e preocupações
A tecnologia de computação em nuvem ainda está em evolução. Várias
empresas, organismos de normalização, e as alianças que se formaram estão
endereçando sua abordagem ao preenchimento de várias lacunas e se
dedicando a resolver algumas preocupações. Algumas dessas inquietações
são as seguintes :
• Segurança: A segurança é uma preocupação significativa para os gerentes
de TICE das empresas, quando eles consideram a possibilidade de uso de um
provedor de serviços em nuvem. A segurança física através do isolamento é
um requisito essencial para as nuvens privadas, mas nem todos os usuários de
nuvem precisam desse nível de investimento. Para estes usuários, o provedor
de nuvem deve garantir o isolamento de dados e a segurança das aplicações
(e disponibilidade) através da separação e isolamento entre os vários
arrendatários ou inquilinos do serviço. Além disso, o processo de autenticação
e autorização dos usuários da nuvem e a criptografia dos dados que trafegam
pela tubulação de rede partindo do usuário até alcançar a aplicação rodando
no provedor de serviços são outros fatores a serem considerados.
49
• Preocupações ligadas a Rede: Quando o incremento do uso da nuvem
provocar ser estouro poderão os servidores contidos na nuvem estar na
mesma camada de rede nível 2, assim como os servidores da empresa? Ou,
se uma topologia de camada de rede nível 3 (Layer 3) estiver envolvida, pois
os servidores da nuvem estão em uma rede fora da empresa? Além disso,
como isso poderia funcionar em centros de dados contendo múltiplas nuvens?
• Preocupações com ligações nuvem-nuvem e a criação de federação de
nuvens: Considere o caso em que uma mesma empresa usa dois provedores
de serviço de computação em nuvem separados e distintos. Recursos de
processamento
computacional
(tempo
de
CPU) e
dispositivos
de
armazenamento sendo compartilhados, juntamente com a autenticação
comum (ou migração de informações de autenticação) são alguns dos
problemas que teremos que nos deparar quando as nuvens tiverem que
"interoperar".Para os serviços virtualizados na nuvem , a migração da VM é
outro fator a ser considerado na federação.
• Preocupações Legais e Regulatórias : Estes fatores tornam-se importante,
especialmente nos casos envolvendo o armazenamento de dados na
nuvem. Pode ser que a legislação que rege os dados não sejam da mesma
jurisdição das leis onde se localiza a empresa.
CAPÍTULO III
INFRAESTRUTURA E IMPLEMENTAÇÃO
A computação em nuvem é uma área emergente que afeta a infraestrutura de TICE, serviços de rede e aplicações. No Capitulo II nós
introduzimos diversos aspectos da computação em nuvem, incluindo a
fundamentação, os modelos subjacentes e a infra-estrutura.
50
Neste Capitulo III, discutimos os aspectos de infra-estruturas específicas de
computação em nuvem, em detalhe, especificamente:
• Infra-estrutura de Rede
• Considerações sobre ligações de nuvem para nuvem e a Federação de
Nuvens
• Segurança
Além disso, iremos fornecer algumas perspectivas sobre os tópicos
selecionados em CN que despertaram maior interesse. Lembre-se que a
computação em nuvem é uma área emergente em que as abordagens de
alguns
desses
computação
em
temas
ainda
nuvem
não
estão
seja
evoluindo. Além
intrinsecamente
disso,
embora
dependente
de
virtualização, há um comum acordo que a virtualização (especificamente, a
virtualização de servidor) será parte integrante das soluções de computação
em nuvem do futuro.
Considere a discussão apresentada nas seções a seguir neste contexto.
Infra-estrutura de rede
Em sentido restrito, a nuvem pode ser tratada como um grande centro de
dados gerido por uma entidade externa, provendo e proporcionando
capacidade de elasticidade, recursos sob demanda, e faturamento por uso.
A arquitetura de centro de dados, muitas vezes segue a muito comum
topologia de acesso à rede de três camadas, composta de acesso,
agregação e núcleo de redes; com a habilitação de elementos de rede tais
como switches e roteadores.
Considere a topologia mostrada na Figura 7 do capítulo II, novamente
publicada aqui.
51
Os servidores podem ser conectados através de um enlace(link) de 1 Gbps
para um comutador (switch) conhecido como Top of Rack (TOR), que por
sua
vez,
é
conectado
através
de
um ou mais enlaces(links) de 10 Gbps para um outro comutador(switch)
denominado End of Row (EOR).
O comutador(switch) EOR é usado para conectividade entre servidores
instalados
em
diferentes
bastidores(racks). A
agregação
de
comutadores(switches) EOR acontece pois todos eles estão conectados
através de enlaces a comutadores (switches) de núcleo(core) permitindo
assim a conectividade para fora do centro de dados.
Do ponto de vista funcional, a organização dos servidores num centro de
dados freqüentemente adota uma arquitetura de três camadas (Um caso
específico de uma arquitetura de n-camadas( n-tier)).
A arquitetura de três camadas funcionais tem uma camada web de
apresentação que funciona como um front end, uma camada de aplicação
onde os aplicativos são executados de acordo com a lógica de processos
de negócios e, finalmente, a camada de Base de Dados (para executar o
sistema de gestão de banco de dados),que é acessada pela camada de
aplicação para as suas funções (veja a Figura 9 na página 53).
52
Reprodução da Figura 7: Example Data-Center Switch Network Architecture Fonte:IPJ Vol.12, No.3/4, 2010
Embora não seja necessário para cada camada ser representada por seus
próprios servidores físicos (por exemplo, você poderia ter o aplicativo e as
funções de banco de dados mapeados em um único servidor físico), esta é
uma representação comum. A razão para este projeto de arquitetura
multicamadas é controlar as conexões e interações, bem como obter
ampliação da escalabilidade e segurança.
Não é incomum para a camada de apresentação estar em uma Zona
Desmilitarizada (DMZ), enquanto as outras camadas estão situadas em
profundidade dentro do centro de dados. Apesar de todas as camadas
poderem se conectar ao dispositivo de armazenamento para executar suas
funções, a camada de Banco de Dados é aquela com os requisitos máximos
de largura de banda de armazenamento.
Daqui resulta que a conectividade do servidor e a topologia da rede para os
centros de dados da nuvem poderia seguir uma organização similar. No
caso de uma empresa, podemos executar as funções de negócios como
antes, mas usando a nuvem externa. A escolha dos servidores, cargas de
software e a sua interconexão dependerá do que você precisa realizar. Nas
seções seguintes, discutiremos como este projeto é tratado em Infraestrutura como serviço (IaaS), uma Plataforma como Serviço (PaaS) e , por
último, Software como Service (SaaS).
53
Figura 9: Three-Tier Functional Server Architecture Fonte:IPJ Vol.12, No.3/4, 2010
Extensão da Infra-estrutura de Centro de Dados – IaaS
Portanto, se a nuvem é vista como uma extensão do centro de dados
existente, IaaS, conforme descrito na capítulo II trata-se de um ajuste
natural. Aqui, você deve especificar o número de servidores em cada
camada, carregar a imagem do servidor apropriado (web, lógica de negócios
ou gerente de banco de dados), e conectá-los (através de um menu ou
Application Programming Interface [API] fornecida pelo provedor de IaaS ),
pela especificação dos enlaces(links) necessários entre eles. Você também
pode especificar a conectividade de rede neste momento (mais sobre isso
depois). Para um administrador de TICE da empresa, este modelo oferece o
maior grau de controle e, em certa medida, uma topologia de operação
familiar. O provedor de CN lida com a elasticidade, garantindo que o número
de servidores e comutadores(switches) é adequada para você configurar e
conectar na topologia especificada. O faturamento por uso e sob demanda
além da adição e remoção de recursos e também são fornecidos pelo
provedor de nuvem. Note que se você tem o controle completo, você
também é responsável pela segurança, o uso de aplicativos e o
gerenciamento de recursos.
54
Infra-estrutura de PaaS e SaaS
No caso de PaaS, você transfere mais controle ao seu provedor de serviços
em nuvem. A plataforma usada para construir o serviço que você requisita
pode escalar de forma transparente, sem qualquer participação sua, a não
ser no momento da configuração. Você não precisa entender sobre a
conectividade em camadas, os requisitos de largura de banda, ou como
funciona tudo em detalhes.
Provedores de serviços de CN podem realizar essa função, muitas vezes
com uma topologia de três camadas semelhante à dos centros de dados
tradicionais. No entanto, alguns deles têm inovado para executar partes
dessa função de forma diferente. Por exemplo, as funções de base de
dados podem depender de um modelo de elevação de capacidade voltada
para o exterior (scaling out) (a divisão do banco de dados em vários
servidores) em vez de crescimento de capacidade voltada para o interior
(scaling up) (aumentando a capacidade da máquina que está executando
os servidores de banco de dados). Sua alegação é que com as nuvens
envolvendo grandes quantidades de dados você pode precisar particionar o
todo para trabalhar sobre as partes menores, assim sendo tornando-se mais
fácil fazer o crescimento para o exterior do que fazer a elevação de
capacidade interna. De acordo com alguns provedores de serviço de CN,
bancos de dados relacionais tradicionais não são candidatos apropriados
para sofrer o processo de elevação de capacidade interno. Assim, alguns
provedores de nuvem ter fornecido os seus próprios modelos e
implementações de banco de dados, um novo tipo comumente conhecido
como banco de dados-chave de valor(Key-value database).
Os Provedores de serviço SaaS têm o maior grau de controle dentre os três
modelos conhecidos. A realização da topologia da rede pode ser similar aos
centros de dados existentes e escalar para cima ou para baixo conforme o
55
número de usuários que são adicionados. No entanto, porque eles oferecem
um conjunto específico de aplicações para os usuários da nuvem, seu
servidor e a topologia de rede são bastante simples.
Para as discussões a seguir, vamos usar o modelo IaaS como
representante do modelo de serviço em nuvem, com uma consideração
primordial sendo essa a tal "nuvem de ruptura"(cloud bursting), isto é, o
incremento de uso da nuvem de forma explosiva; em outras palavras
queremos saber
como uma infra-estrutura de TICE existente pode
aproveitar o poder da nuvem no caso de precisar de recursos
adicionais. Note que algumas das discussões também podem ser relevantes
para as nuvens internas. Além disso, vamos assumir uma infra-estrutura de
servidores virtualizados para a nuvem IaaS porque esta infra-estrutura
proporciona um maior grau de flexibilidade para os provedores de serviço de
CN (Amazon é um exemplo-chave).
A
virtualização
e
suas
demandas
em
conexões
de
comutadores(Switching)
No capítulo II, nós fornecemos o contexto de um comutador (switch) virtual
dentro de um servidor físico contendo várias máquinas virtuais. Existem
alguns fatores de endereçamento e controle a serem considerados neste
modelo. Consideremos um centro de dados com 100 servidores, cada qual
com 16 máquinas virtuais, mas com uma conexão física Ethernet de 10
Gbps para o comutador(switch) externo conectando cada máquina física. Se
fôssemos levar adiante o modelo onde cada servidor físico é substituído
pelo seu equivalente virtual, mas ainda necessitando ser endereçável
(através de um endereço físico da camada de Media Access Control
[endereço MAC] e um endereço lógico IP), você precisaria de 16 endereços
físicos MAC e lógicos IP nos servidores virtuais que agora residem "em
cima" do único enlace(link) físico, para um total de 1.600 endereços em
todos os servidores. Este problema é agravado quando você aumenta o
56
número de máquinas virtuais por servidor. A troca entre endereços MAC
pertencentes às máquinas virtuais é feita pelo comutador (switch) virtual
dentro do servidor.
Considere a topologia na Figura 8. O comutador (switch) virtual trata do
enlace
(link)
físico
como
um
enlace
de
saída(uplink)
para
o
comutador(switch) físico externo. Este comutador(switch) intramachine
Virtual Machine (VM) com um enlace de saída (uplink) para o
comutador(switch) externo está totalmente em linha com a topologia dos
comutadores(switches)
de acesso e de agregação onde a camada de
acesso é incluída dentro do servidor. Observe que cada host físico pode ter
mais de um comutador(switch) virtual para apoiar uma maior segmentação
lógica. Nesses casos, é comum que cada um dos comutadores(switches)
virtuais tenha seu próprio enlace de saída(uplink) conectando-se ao
comutador( switch) Ethernet externo.
O comutador(switch) virtual não precisa aprender os endereços MAC como
um comutador(switch) tradicional, ele assume que todos os quadros com
destino desconhecido devem ser enviadas através do enlace(link) físico (ou
enlace de saída( uplink) para o comutador(switch) físico). Além disso, ele
muda tráfego entre as VMs intramachine de acordo com a política
estabelecida. Por exemplo, você pode proibir duas VMs na mesma máquina
de se comunicar uma com a outra, configurando uma lista de controle de
acesso (Acess Control List - ACL) no comutador(switch) virtual. As VMs
podem estar todas na mesma ou em diferentes VLANs. Transmissões em
broadcast e tráfego intra-VLAN são encaminhadas de acordo com as regras
para cada VLAN. Com efeito, o comutador(switch) virtual é uma função
simples que é usada para a agregação e controle de acesso dentro de um
servidor físico contendo várias VMs.
O gerenciamento destes comutadores(switches) virtuais pode seguir um
modelo de agregação, onde vários comutadores(switches)
virtuais são
57
gerenciados através de um nó externo (máquina física ou VM), como
mostrado na Figura 10. Este nó externo provê a visão de gerência atuando
sob
o
ponto
de
vista
comutadores(switches). Muitas
de
vezes,
gestão,
o
nó
em
externo
nome
pode
dos
executar
protocolos de controle dos planos para as funções de camada 2 / 3, no
sentido que aparece como um plano de controle ou plano de gerenciamento
com várias instâncias do plano de dados (os comutadores(switches)
virtuais). Quando VMs precisam ser migradas para outros servidores físicos,
essa separação de funções de controle
e de funções de plano de
gerenciamento permite uma fácil migração de políticas e de listas de
controle de acesso.
Os comutadores(switches) virtuais têm algumas desvantagens. O tráfego
Inter-VM na mesma máquina não é visível para a rede e não pode ser objeto
de um monitoramento adequado por parte dos administradores de rede. O
Instituto de Engenheiros Elétricos e Eletrônicos norte-americano conhecido
pela sigla IEEE está discutindo abordagens de como fazer a provisão da
propriedade do comutador(switch) da rede externa conseguir enxergar o
tráfego intra-VM. As opções incluem "hair pinning", onde o tráfego inter-VM
ainda seria transferido para um comutador(switch) externo e trazido de volta
para o mesmo servidor físico.
Figura 10: Virtual Switch Aggregation and Management by External Node Fonte:IPJ Vol.12, No.3/4, 2010
58
Nuvens Privada IaaS
Considere uma nuvem IaaS na qual uma empresa se conecta com o intuito
de aumentar a
capacidade do seu servidor por um período limitado de
tempo. Suponha que a empresa usa um esquema de endereçamento
privado baseado na rede 10.xxx para todos os seus servidores, pois são
internos à empresa. Seria ideal se os servidores adicionais fornecidos pela
nuvem IaaS fizessem parte do mesmo esquema de endereçamento (a rede
10.xxx). Conforme mostrado na Figura 4, o provedor de serviços de nuvem
IaaS teve particionada uma parte de sua nuvem pública para configurar
uma nuvem particular para a empresa A. A nuvem privada é acessível como
uma extensão da rede local - LAN para os servidores no centro de dados
da empresa.
Como essa acessibilidade é alcançada? Primeiro é estabelecido um túnel
seguro, posto que é criptogrado tudo o que é transmitido, entre o centro de
dados da empresa e o da nuvem pública formando-se o que chamamos de
uma rede privada virtual ou Virtual Private Network (VPN). Este túnel utiliza
endereços IP públicos para estabelecer a conexão VPN de site-to-site. O
gateway VPN do lado do provedor de serviço de nuvem se utiliza de
múltiplos contextos, cada contexto correspondendo a uma nuvem privada
específica. O
tráfego
proveniente
de
uma
empresa
é
decifrado,
descriptografdo e transmitido ao longo de um comutador(switch) Ethernet
para a nuvem privada da empresa A. Um servidor dentro de um centro de
dados interno a empresa A enxerga um servidor privado na nuvem A como
se estivesse na mesma rede.
Na prática, os servidores do centro de dados podem ser segmentados em
suas próprias VLANs ou redes IP de acordo com a política estabelecida e
as aplicações. As políticas de configuração e de encaminhamento na
extremidade fim da nuvem privada deve também refletir essa segmentação.
59
Figura 11: Exemplo de Nuvem Privada Fonte:IPJ Vol.12, No.3/4, 2010
A seguir, alguns cenários possíveis de evolução desse regime:
• Automação da conexão VPN entre a empresa e o provedor de
serviços em nuvem: Esta automação pode ser feita através de um sistema
de gerenciamento responsável pelo incremento de uso de forma explosiva
da nuvem (cloud bursting) e acréscimo do servidor. O sistema configura os
túneis VPN e configura os servidores na extremidade fim do provedor de
serviço de nuvem. O sistema de gerenciamento é configurado e operado
pelo provedor de serviços em nuvem.
• Integração das funções de VPN de site para site com funções de rede
VPN de provedores de serviços. Por exemplo, provedores de serviços
oferecem VPNs Layer 3 MPLS e VPNs Layer 2 (também conhecido como
Virtual
Private
LAN
Service,
ou
VPLS)
como
parte
de
suas
ofertas .Empresas e provedores de serviços em nuvem podem ser
configurados para utilizar estes serviços de rede.
60
• Os provedores de serviços em nuvem com vários centros de dados:
Em tal situação, um serviço similar ao VPLS, pode ser usado para interligar,
através de uma ponte,
os centros de dados individuais, proporcionando
total transparência do ponto de vista das empresas sobre a localização dos
servidores na nuvem.
CloudNet é um exemplo de uma iniciativa sendo desenvolvida pelo Labs AT
& T e a Universidade de Massachusetts em Amherst para enfrentar os dois
últimos cenários.
Conectividade via Comutação Camada 2 (Layer 2 (switching))
versus
Roteamento Camada 3 (Layer 3(routing) )para Redes em Nuvem.
Empresas e vendedores seguem algumas linhas mestras e orientações
sobre quando usar Comutação camada 2 e Roteamento camada 3 na
rede. Comutação camada 2 é o modo mais simples, onde o endereço MAC
Ethernet e a informação de Virtual LAN (VLAN) são utilizados para
encaminhamento adiante até o destino. A desvantagem de Comutação
camada 2 nas redes é a escalabilidade. Quando usamos endereçamento e
conectividade Camada 2 na forma especificada anteriormente para as
nuvens IaaS, trabalhamos com uma topologia plana, o que não é ideal
quando há um grande número de nós. A opção é usar roteamento camada
3 e sub-redes. Desta maneira fornecendo a segmentação apropriada de
funções ao custo de menor desempenho de encaminhamento e maior
complexidade da rede.
A migração de VM introduz seu próprio conjunto de problemas. O cenário
mais comum é quando uma VM é migrada para um host diferente porém
permanecendo na mesma topologia de camada 2 (com a configuração de
VLAN apropriada). Considere o caso de uma VM com conexões do
61
protocolo Transmission Control Protocol (TCP) abertas e estabelecidas no
momento da migração. Se a migração em tempo real é usada, as conexões
estabelecidas e abertas do TCP não sofrerão nenhuma paralisação, exceto
por um "breve" soluço. No entanto, após a migração, pacotes IP e
segmentos TCP destinados a VM terão de ser resolvidos para um endereço
MAC diferente ou até para o mesmo endereço MAC, mas agora conectados
a um comutador(switch) físico diferente na rede para que as conexões
possam continuar sem interrupção. Uma das soluções propostas incluem
um pedido não solicitado de resolução de endereços do protocolo Address
Resolution Protocol (ARP) partindo da VM que foi migrada permitindo a
atualização das tabelas dos comutadores(switches), outra solução seria
obter um pseudo-endereço MAC para a máquina virtual que seria
gerenciado externamente (definido no trabalho de investigação que está
sendo feito na Universidade da Califórnia em San Diego), e assim por
diante.
Com VPLS e abordagens similares de Comutação camada 2 , a migração
de VM pode continuar como antes, através da mesma camada 2 da
rede. Alternativamente, pode ser menos complexa "congelar" a VM e movêla em qualquer rede de Camada 2 ou de Camada 3 , com conexões TCP
tendo que ser desfeita ou liberada pela contraparte se comunicando com a
VM. Este cenário não é desejado se levarmos em consideração a
disponibilidade das aplicações, mas pode diminuir a complexidade.
Federação de Nuvens
Até aqui temos considerado a situação dos centros de dados próprios ou
gerenciados pelo mesmo provedor de serviços em nuvem. Conectividade
entre os centros de dados para fornecer a visão de "uma nuvem" está
completamente dentro do controle do provedor de serviços em nuvem.
Pode haver situações em que uma organização ou empresa deve ser capaz
62
de trabalhar com vários provedores de CN por causa da migração de um
serviço de uma nuvem para outra, fusão de empresas que trabalham com
diferentes provedores de CN, provedores de CN que prestam serviços de
classe diferenciada, e assim por diante. Interoperabilidade entre nuvens e a
capacidade de compartilhar vários tipos de informações entre as nuvens
tornam-se importantes em tais situações. Embora os provedores de serviços
em
nuvem
encarem
com
menos
urgência
qualquer
tipo
de
interoperabilidade, os clientes das empresas em função de suas
necessidades vão demandá-los nesse sentido.
Esta vasta área de interoperabilidade entre nuvens é conhecida como
federação de nuvem. Uma definição de federação de nuvem de acordo com
o proposto por Reuven Cohen Enomaly pode ser escrita da seguinte forma:
" Federação de Nuvem gerencia a consistência e os controles de acesso
quando duas ou mais nuvens distribuídas geograficamente e independentes
compartilham tanto autenticação quanto arquivos, imagens, recursos
computacionais, comando e controle, ou o acesso a recursos de
armazenamento."
A seguir algumas considerações sobre federação de nuvem:
• Um usuário de empresa que pretenda aceder aos serviços de múltiplas
nuvens seria melhor servido se houvesse apenas um regime de
autenticação unificado suportando uma única senha
(single sign-
on). Este regime pode ser implementado através de um servidor de
autenticação mantido por uma empresa que fornece as credenciais
necessárias para os provedores de serviços em nuvem. Alternativamente,
uma outra solução centralizada seria dispor de um servidor de autenticação
confiável ao qual serve de interface de todos os serviços de nuvem que
podem ser usados.
63
• Recursos computacionais e de armazenamento podem ser orquestrados
através
da
empresa
individual
ou
através
de
um
regime
de
interoperabilidade estabelecidas entre os provedores de nuvens (através de
um acordo de federação, por exemplo). Os arquivos podem precisar ser
transferidos, os serviços podem ser invocados ou demandados e os
recursos de computação, adicionados ou removidos, de forma útil e
transparente. Esta é a área relacionada com a migração de VM e como isso
pode ser feito de forma transparente e confiável. A força tarefa de
gerenciamento do desktop denominada Desktop Management Task Force
(DMTF) lançou uma especificação chamada de Open Virtualization Format
(OVF) para descrever uma VM. É razoável supor que a carga útil para a
migração de VM será no formato OVF para que possa ser interpretada
através de ofertas de vários provedores. Com efeito federação de nuvem,
deve fornecer orquestração de carga de trabalho
transparente entre as
nuvens, em nome do usuário da empresa.
• Conectividade entre nuvens inclui considerações sobre Comutação na
camada 2 versus Roteamento na camada 3 e tecnologias de túnel seguro
que precisam ser negociadas até o acordo. Coerência e um entendimento
comum são requisitos obrigatórios, independentemente do modelo ou das
tecnologias.
• Uma preocupação freqüentemente ignorada em confederação de nuvem
está ao fazer a carga ou processo de faturamento e de reconciliação. Os
sistemas de gerenciamento e de faturamento precisam trabalhar juntos para
a federação de nuvem ser uma opção viável. Esta realidade é reforçada
pelo fato de que as nuvens contam com faturamento por uso. Provedores de
serviços de nuvem talvez precisem analisar atentamente os modelos de
negócio dos provedores de serviços de telecomunicações usados em
acordos de parceria como um possível ponto de partida.
64
Federação de Nuvens é uma área relativamente nova na computação em
nuvem. É provável que os organismos de normalização primeiro tenham que
chegar a um acordo sobre um conjunto de requisitos antes de interfaces de
serviço poderem ser definidas e posteriormente realizados. Provedores de
serviços
e
vendedores
de
inovação
também
serão
afetados
significativamente nesta área, na verdade, os operadores de serviços em
nuvem são susceptíveis de estabelecer relações de troca de tráfego e
começar a abordar este tema, antes mesmo dos organismos de
normalização.
Segurança
Conforme indicado no capítulo II, a maior impedância para os gerentes de
TICE se aventurarem na computação em nuvem é o problema de segurança
e perda de controle. Antes de considerar uma possível mudança para um
provedor de serviços em nuvem, as empresas precisam considerar alguns
dos temas de segurança a seguir:
• Os processos de segurança do provedor de serviços de nuvem terão de
ser tão bons ou melhor
que os processos que a empresa usa. Uma
auditoria de processos do provedor deverá ser feito periodicamente,
possivelmente incluindo patches e atualizações de segurança para os
componentes individuais que são usados. Por exemplo, em um cenário de
IaaS com algumas imagens pré-configuradas de sistemas operacionais e
aplicativos, o provedor de serviços em nuvem deve ter as últimas correções
aplicadas sobre os componentes individuais.
• Infra-estrutura e isolamento de dados deve ser assegurada entre vários
inquilinos do provedor de serviços em nuvem. Esta exigência é complicada
porque está intimamente entrelaçada com o modelo de negócios usado pelo
provedor de nuvem. Por exemplo, um provedor de IaaS pode prover
serviços a vários inquilinos com VMs em execução na mesma máquina
física. Dependendo do tipo de trabalho que será executado na nuvem, esta
configuração pode ou não ser aceitável para um usuário da nuvem. Nesses
65
casos, o provedor de serviços em nuvem deve ter a capacidade de prover
servidores físicos separados para clientes específicos (e de mandar a conta
do serviço prestado de forma apropriada).
• Nos casos em que um hypervisor e VMs são usados, o hypervisor deve ser
tratado como um sistema operacional e devem ter as últimas patches de
segurança aplicadas. Patches e atualizações de segurança também são
essenciais para os sistemas operacionais virtualizados utilizados na VMs.
• Funções de segurança podem ser implantadas como dispositivos virtuais
sobre hypervisors em um ambiente de nuvem. Assim, é possível para os
usuários em um ambiente de nuvem IaaS configurar e carregar seu próprio
firewall ou outro dispositivo de segurança virtual para ser executado dentro
da nuvem. As imagens do software usado para estes dispositivos virtuais
precisam ser gerenciados e com correções aplicadas de maneira similar ao
que é feito no sistema operacional, no próprio hypervisor, e nas outras
aplicações que são gerenciadas e cujas correções de segurança são
aplicadas.
• Registros de Log e trilhas de auditoria para as aplicações são importantes
para as empresas
compreenderem tanto o desempenho do aplicativo
quanto as falhas de segurança. Provedores de serviços de nuvem devem
permitir o acesso à sua aplicação de monitoramento e ferramentas de
controle de perfis, quando aplicável.
• Mecanismos de autenticação ("Você é quem você diz que é") são
necessários em ambas as extremidades da conexão do usuário, tanto no
nível do próprio usuário da nuvem quanto no nível do provedor de serviços
de nuvem. O usuário da nuvem e o operador devem concordar com os
esquemas de autenticação baseados nos certificados digitais ou nas
autoridades certificadoras.
66
• Configuração e atualizações na infra-estrutura de rede devem ser
auditados, controlados e monitorados. Por exemplo, uma incorreta
configuração de VLAN utilizando os comutadores(switches) pode resultar
em padrões de tráfego indesejados entre as máquinas físicas e os recursos
de computação. Seria útil e de boa técnica fazer o log e auditar os registros
de configuração de forma adequada de modo a garantir a segurança e o
tempo de disponibilidade(uptime).
• Como o serviço em nuvem esta exposto ao mundo exterior, as infraestruturas de nuvem devem implementar as funções de segurança através
de sistemas de detecção e prevenção de intrusão, firewall para impedir o
tráfego não permitido, e prevenção de ataque de negação de serviço do tipo
conhecido como Denial of Service (DoS). O serviço de nuvem é vulnerável
ao ataque de negação de serviço distribuído do tipo Distributed Denial of
Service (DDoS), que pode efetivamente saturar as suas linhas de acesso,
resultando em usuários de nuvem trancados pelo lado de fora da nuvem de
serviço. Prevenção de ataques DDoS baseados na rede é uma solução
possível, com uma das técnicas que envolvem a distribuição da infraestrutura de nuvem em áreas geográficas específicas e capacidade para
redirecionar usuários da nuvem em caso de bloqueios DDoS.
Virtualização e Segurança
Duas opções estão em discussão para a segurança no contexto da
virtualização. Ambas são úteis na construção de infra-estruturas de nuvem
habilitadas a partir do plano externo com segurança. Uma opção envolve
plug-ins para o hypervisor para que os pacotes destinados a VMs sejam
capturados e processados pelos plug-ins de segurança. Esta configuração
permite a aplicação das funções de segurança nos pacotes antes deles
chegarem as VMs. A segunda opção é fazer uma VM específica
responsável pelas funções de segurança sem alterar ou acrescentar nada
67
ao hypervisor. A opção do plug-in do hypervisor tem a vantagem de maior
desempenho e isolamento inicial, enquanto que a opção de VM separada
tem a vantagem de manter o hypervisor simples e extrapolando o modelo
que existe em infra-estrutura de servidores físicos. Observe que essas
opções não são mutuamente exclusivas.
A Migração de VM é outra área onde a segurança é uma consideração
importante. O hypervisor é responsável pela comunicação de duas vias,
com a ajuda do hypervisor na máquina física de destino completando a
tarefa de migração. É importante que a conexão entre os hypervisors na
origem e no destino sejam autenticadas e criptografadas durante o curso
dessa migração. Além disso, a migração de VM introduz a possibilidade de
um ataque DoS por um hypervisor rogue que poderia sobrecarregar a
máquina de destino devido a migração de um grande número de VMs para a
máquina de destino. Políticas e lógica são necessárias a nível do hypervisor
para garantir que essas vulnerabilidades sejam abordadas. Além disso, a
otimização baseada em rede pode ser necessária para que a migração ao
vivo não cause congestionamento, o que pode acontecer se um grande
número de VMs precisam ser migrados para uma máquina de destino, ao
mesmo tempo.
Organizações de padronização envolvidos em CN
Várias entidades estão envolvidas em padrões de CN, abordando aspectos
tais como interoperabilidade, os formatos de migração da virtualização e
segurança. Algumas das organizações envolvidas têm estabelecido ligações
com as outras Organizações de Desenvolvimento de Padrões também
conhecidas como Standards Development Organizations (SDOs), para
que não haja duplicação de esforços.
A Força Tarefa de Gerenciamento do Desktop conhecida como grupo
Desktop Management Task Force (DMTF) pertencente à Força Tarefa de
68
Engenharia da Internet( IETF) especificou um formato portátil para embalar
o software para funcionar como uma VM. Conhecido como o formato Open
Virtualization Format (OVF), esse formato do pacote está alcançando uma
utilização crescente. A VM pode ser gravada em um disco ou num
dispositivo de armazenamento externo e pode ser movida de uma máquina
física para outra. O DMTF também formou um grupo chamado Incubadora
de Normas Abertas em Nuvem ou Open Cloud Standards Incubator, que
incide sobre a normalização das interações entre ambientes de nuvem,
incluindo o desenvolvimento da gerência dos recursos, formatos de pacotes
de embalagem e segurança.
O Cloud Security Alliance (CSA) é um novo grupo formado para combater
os aspectos de segurança da computação em nuvem com foco na avaliação
da
segurança
e
gerenciamento. A
parte
inicial
do
esforço
é
no
desenvolvimento de um conjunto(A6) de auditoria, afirmação, avaliação e
garantia (API) .
A Organização para o Avanço dos Padrões da Informação Estruturada ou
Organization for the Advancement of Structured Information Standards
(OASIS) vê a computação em nuvem como uma extensão da Arquitetura
Orientada a Serviços ( Service-Oriented Architecture - SOA), atualmente
usada em ambientes de TICE. As áreas objeto de normalização incluem
segurança e sua política, formato de controle de conteúdo, padrões de
registro e de diretório, bem como outros métodos de SOA.
A associação denominada Storage Networking Industries Association
(SNIA) possui um grupo de trabalho técnico chamado Cloud Storage
Technical Working Group (TWG), que trabalha na solução de problemas
ligados ao uso de dispositivos de armazenamento quando aplicados em
nuvem. Este grupo com a sigla TWG desenvolveu uma interface conhecida
como Data Cloud Management Interface (CDMI), que os clientes usarão
para controle e configuração da nuvem.
69
Perspectivas em CN
Nesta seção, esboçamos e oferecemos perspectivas sobre a computação
em nuvem e ainda abordaremos tópicos que tem despertado maior
interesse (e acalorada discussão). Esta lista não pretende ser exaustiva,
mas proporciona uma rápida visão. Embora esta seção tenha um certo grau
de subjetividade, é dirigida apenas para fornecer uma perspectiva mais
abrangente.
• CN e SOA: Alguns têm a visão de computação em nuvem como um caso
específico de implantação de SOA, e esta visão é mais popular do que
aquela que diz que a computação em nuvem é uma evolução da
SOA. David Linthicum relata que essas visões são complementares já que
os serviços de cloud computing provavelmente serão melhor definidos
através de SOA. IaaS prevê uma nova variante, porque agora você pode
acessar computação direta e recursos de armazenamento como um
serviço. Independente do argumento de que "Já vimos isso antes", há valor
adicionado ao definir e invocar os serviços disponíveis na nuvem.
• Esquemas de virtualização de servidores: Comparações são feitas às
vezes com base em como é feita a abordagem do vendedor de produtos de
virtualização, isto é, como são apresentadas as alternativas que se
contrapõe , virtualização do tipo-1 versus tipo 2 e virtualização completa
versus paravirtualização. Essas abordagens têm prós e contras. A decisão
final depende, muitas vezes dos custos totais, então pode ser útil fazer
avançar o debate a partir deste ponto. Aliás, os vendedores fornecem várias
ferramentas úteis para o backup da VM, recuperação e tolerância a falhas,
gerenciamento de carga, e assim por diante, e esses instrumentos
funcionam
igualmente
bem
para
as
várias
abordagens
de
virtualização. Pode-se argumentar que essas ferramentas e características
70
tais como a migração de VM e os custos associados são as áreas mais úteis
para a comparação.
• Os outros tipos de virtualização: Este estudo deliberadamente omitiu a
discussão de outros tipos de virtualização, incluindo desktops, aplicativos e
virtualização de apresentação.Alguns destes programas (por exemplo
servidor hospedado e virtualização de desktops) são afetados pela nuvem,
especificamente nas áreas de conectividade de rede, autenticação e
qualidade da experiência. Em geral, qualquer experiência de cliente mínimo(
thin client) é afetada pela nuvem ou pelo centros de dados porque a maioria
do trabalho é feito nos servidores. De uma perspectiva de nuvem, esses
tipos de sistemas de virtualização são consideradas como aplicações que
necessitam funcionar de forma confiável e consistente.
• A transferência de dados e a largura de banda de rede: O modelo de
serviço IaaS fornece um modelo flexível, no qual o cliente é cobrado com
base no uso do poder de computação, espaço de armazenamento
consumido, bem como a duração do uso. No entanto, existe um outro fator
importante, os dados precisam ser enviados para trás e para frente entre o
usuário da nuvem e o provedor de serviços em nuvem.Vários provedores
segundo o modelo IaaS cobram pela quantidade de dados transferidos
através do enlace(link).Essa taxa pode rapidamente se elevar caso seus
aplicativos sejam intensivos em comunicação e exijam muito de tráfego de
dados de ida-e-volta. Agora temos outra preocupação que é a quantidade
de tempo que o upload ou download inicial pode consumir, por exemplo,
quando você quiser mover um grande número de seus arquivos para o
dispositivo de armazenamento do provedor IaaS, você pode comprometer o
enlace(link) por horas. De fato, um provedor tem um modelo alternativo
onde os usuários da nuvem podem enviar mídia física de armazenamento
através
de
um
serviço
postal
ou
um
serviço
de
entrega
de
encomendas/pacotes para depois então fazer o upload para o arrays de
armazenamento do provedor de nuvem.
71
• A aceleração de WAN para a nuvem: Continuando do ponto anterior,
protocolos de comunicação e aplicações que se comunicam com
intensidade podem se beneficiar de dispositivos de aceleração WAN que
podem ser usados em ambas as extremidades de um enlace(link) WAN
como
cache
local
e
assim
servir
pontualmente
aos
aplicativos
corporativos. Estes dispositivos não são específicos para a nuvem, eles têm
sido utilizadas há vários anos para melhorar o desempenho do aplicativo
quando uma ligação WAN está envolvida. Recentemente, dispositivos de
rede virtual de aceleração WAN estão sendo implantados, neste caso a
aceleração da WAN é feita por uma VM individual em vez de um dispositivo
dedicado.
• Migração de VM: Este estudo descreveu algumas das preocupações com
a migração de VM em relação às topologias de comutação - camada 2 e
roteamento - camada 3. Outra consideração é a quantidade de dados que
precisam ser movidas quando uma VM é migrada através de uma
rede. Pode vir a ser da ordem de grandeza de vários gigabytes, dependendo
do VM e do ambiente operacional incluído.
A migração ao vivo implementa a transferência de uma forma incremental
de modo que a demanda na rede espalha-se. No entanto, a migração
instantânea (onde a VM fica suspensa ou congelada e migra através da
rede na íntegra) pode causar uma onda de dados na rede, levando a
problemas de desempenho do aplicativo nas máquinas virtuais e nas outras
máquinas físicas. Otimização da quantidade de dados que podem ser
enviados em um período específico de tempo, a reserva de largura de
banda e o policiamento dos dispositivos intermediários de rede é altamente
desejável em tais situações.
• Gerenciamento: Os paradigmas de gerenciamento corrente para os
componentes da nuvem são bastante discretos e provê um alto nível de
72
controle. Por exemplo, é possível acessar a Interface da Linha de Comando
(CLI) de um comutador(switch) específico no centro de dados para
configuração e controle dos parâmetros do comutador(switch). Da mesma
forma, é possível usar o console de gerenciamento fornecido pelo
fornecedor de virtualização para configurar os parâmetros individuais para
os hypervisors e VMs (por exemplo, quando iniciar a migração VM para uma
outra máquina física). Esforços estão sendo feitos para unificar sistemas de
gerenciamento e não apenas através de parcerias entre os provedores
individuais, mas também com interfaces de leitura de máquina (Extensible
Markup Language [XML] sendo uma linha de base) em todos os vários tipos
de
equipamentos
e
software
na
nuvem.
Usuários
das
empresas
normalmente não estão susceptíveis a aceitar soluções pontuais ou
ferramentas que requerem interação do usuário extensiva a longo prazo.
• Considerações sobre Energia: Um dos benefícios da virtualização é a
utilização de um número menor de servidores físicos para realizar uma
função específica. Daqui resulta que o consumo global de energia seria
reduzido, porque você teria menos servidores. Embora este fato possa
realmente ser verdade, seria bom poder caracterizar e monitorar de forma
eficiente a poupança de energia gerada por um aplicativo específico ("Sua
milhagem pode variar"). Por exemplo, a carga em cada servidor e suas
atividades associadas de I / O e o tráfego de armazenamento pode levar a
maiores requisitos de energia em uma base individual de servidor. Outras
considerações incluem a infra-estrutura de hardware do centro de dados
da nuvem, porque o poder e os pressupostos de refrigeração por
bastidor(rack) baseiam-se na carga média do servidor.
• Considerações Legais e regulatórias: James Urquhart elaborou um
conjunto de critérios para a migração de carga de trabalho em vários locais,
um dos quais é "obedecer à lei." Considere o caso de um provedor de
serviços em nuvem ou um operador que tem centros de dados em dois
países distintos. O operador pode utilizar os centros de dados para a
73
migração de carga de trabalho, bem como para fazer o balanceamento de
carga. Um problema pode surgir se as leis de um dos países impõem
limitações sobre o que pode e o que não pode ser feito no centro de dados
situado em seu território.Os cenários incluem o acesso a todos os dados
guardados neste centro de dados pelas autoridades ou a capacidade de
analisar todas as operações sobre o fio(no momento em que acontecem) no
centro de dados.Declarações de política de migração de trabalho devem
ser fornecidos para usuários da nuvem de modo que eles entendam o que
estão assinando. Alternativamente, eles podem ser providos com a
capacidade de definir o conjunto das preferências para a migração de carga
de trabalho. Esta área é potencialmente preocupante, por isso é importante
que os usuários nuvem estão cientes de sua situação específica.
CAPÍTULO IV
APLICAÇÕES BRASILEIRAS EM DESENVOLVIMENTO
Duas aplicações envolvendo vídeos estão sendo desenvolvidas por uma
universidade de ponta brasileira na pesquisa do tema C.N. (PUC-RIO) em
parceria com uma empresa privada (GLOBO.COM) que apresenta os
estudos de caso reais. Os problemas sendo solucionados pelas aplicações
de computação em nuvem em desenvolvimento podem ser segregados, do
ponto de vista da instituição comercial, como sendo do tipo saída de vídeo VÍDEO OUT, permitindo o compartilhamento de sua produção interna com
os seus telespectadores através de um novo canal; e a entrada de vídeo
externo - VÍDEO IN, produzidos independentemente e autonomamente por
seus colaboradores.
No primeiro caso de problemas dito de VÍDEO OUT, a instituição emissora
disponibiliza para download na rede mundial de computadores, através do
seu sítio na Internet, vários vídeos internamente produzidos por dia em
74
diferentes formatos aos seus telespectadores que poderão assisti-los, de
forma assíncrona, quando melhor lhes convier. Neste caso a compressão de
vídeo é extremamente importante devido a necessidade de disponibilizar
cerca de 500 minutos de vídeo por dia, que precisam ser exibidos em
diversas plataformas diferentes(iPhone, Android, Blackberry etc).Em ano de
Copa do Mundo de futebol, imagine dispender 12 horas para codificar o
vídeo da partida final em que o Brasil participou. Esse seria o tempo gasto
pelo processo convencional que pode ser reduzido para 2 minutos caso o
aplicativo que usa C.N. for utilizado, assim disponibilizando para download
em tempo recorde o vídeo como parte de sua recordação. Isso de converter
rapidamente os vídeos produzidos na sua grade de programação cotidiana
ou em grandes eventos contratados de forma exclusiva gera uma
necessidade de processamento monumental. Diante disso, ou a instituição
compra novos servidores físicos aumentando o seu parque instalado de
hardware, ou trata todo o material produzido em formato de vídeo na nuvem.
O tratamento na nuvem requer uma codificação rápida de vídeos e para
tanto baseia-se numa arquitetura composta de duas fases batizadas
conjuntamente de SPLIT&MERGE. Na primeira fase, a de SPLIT, o vídeo é
dividido em chunks (pedaços) que são processados paralelamente, depois
mesclados, e o conjunto é comprimido. Cada chunk corresponde a uma
marcação temporal de inicio e fim, o que torna o processo mais rápido e
eficiente.
O tamanho de cada chunk é sempre maior ou igual ao tamanho do GOP (
group of picture – ver definição em bit.ly/gopdef ) , ou seja, maior do que a
distância entre os key-frames do vídeo, de modo que não haja uma redução
na eficiência da compressão.
Um algoritmo específico decide o tamanho otimizado de cada chunk, de
acordo com o tamanho de entrada. As trilhas de áudio e vídeo são
codificadas em separado, o que permite aplicar diferentes perfis de
codificação, que são escolhidos para cada processamento, juntamente com
75
o formato de saída. O provisionamento de recursos é feito dinamicamente
na nuvem, de acordo com a quantidade de fragmentos a serem
processados.
Na segunda fase, chamada de MERGE, os chunks de vídeo são ordenados
para compor a sequência lógica do vídeo. Em seguida são mesclados. O
áudio é mesclado e remixado ao vídeo. Em seguida, o arquivo final é
reconstruído, reconstituindo o vídeo inteiro já processado. O processo
transcorre utilizando o CLOUDCROWD, um framework baseado em Ruby e
Sinatra, que realiza o processamento de tarefas de maneira paralela e
distribuída. O resultado é a redução drástica da duração do processo de
codificação de vídeo.
No segundo tipo de problema, dito de VÍDEO IN, ao contrário, a instituição
assume o papel de receptora de inúmeros vídeos por dia produzidos
externamente para upload, em diferentes formatos, que são também
recebidos através do sítio da instituição na Internet. Desta maneira
precisamos gerenciar a submissão aberta de vídeos gerados por usuários
na medida em que a Internet elimina as barreiras físicas(por exemplo,
DVDs, fitas e papel). O acesso global oferecido por este tipo de sistema de
submissão on line faz com que se torne difícil estimar o volume de recursos
necessário para processar as submissões. Um exemplo deste tipo de
problema carecendo de solução computacional em nuvens é o sistema de
inscrição anual para o programa no formato de reality show denominado
Big Brother Brasil que se encontra na sua 11ª edição. O processo de
inscrição evoluiu de um sistema manual, baseado no envio de uma fita de
vídeo analógico pelo correio convencional, para um sistema on line que
requer o upload de um vídeo em formato digital. No novo sistema, os
candidatos podem enviar o vídeo no formato que desejarem. Uma vez
recebido, este arquivo deve ser armazenado até o final do processo de
seleção dos participantes, que costuma demandar cerca de três meses.
76
Todos os vídeos recebidos devem ser convertidos para um único padrão, de
modo a facilitar sua exibição durante a fase de avaliação pelos recrutadores.
Como requisito funcional o sistema deve ser capaz de receber um grande
número desconhecido de vídeos durante o período de inscrição. Espera-se
que cerca de 100.000 vídeos sejam recebidos, onde estima-se que 60%
deles sejam enviados durante a última semana de inscrições.
Generalizando, podemos dizer que este tipo de sistema pertence a uma
classe de problemas que podemos chamar de sistemas de submissão
abertos que são caracterizados por :
1. impossibilidade de se estimar o número total de submissões;
2. incerteza sobre os recursos necessários para armazenar e processar as
submissões;
3. os recursos necessários serão úteis apenas durante o processo de
recebimento e processamento. Depois deste período podem ser total ou
parcialmente descartados;
4. existem poucas situações agudas de pico, onde a infra-estrutura terá
de escalar fortemente para disponibilizar o volume de recursos
necessários.
A implementação da solução para o problema dos sistemas de submissão
abertos podem ser endereçadas utilizando-se 3 (três) recursos de
computação em nuvem disponibilizados pela empresa pioneira Amazon, na
forma de um primeiro serviço utilizado para persistir os arquivos de vídeo
convertidos para o padrão desejado e denominado de Amazon Simple
Storage Service – AMAZON S3; um outro segundo
serviço WEB que
fornece uma API para realizar o provisionamento e a liberação de recursos
na nuvem. Pode ser utilizado para instanciar as máquinas necessárias para
fazer o processo de codificação dos vídeos recebidos no formato padrão
desejado e é denominado de Amazon Elastic Compute Cloud – AMAZON
EC2; o terceiro e último é um serviço de fila, utilizado para organizar os jobs
a serem processados( vídeos para transcodificação ) e para avisar do
77
término do processamento ( vídeo pronto, em formato padrão ) e conhecido
como Amazon Simple Queue Service – AMAZON SQS.
Resumidamente, a descrição sucinta da arquitetura criada para tratar da
solução do problema se inicia quando, para cada submissão realizada, o
arquivo original é armazenado na AMAZON S3 e uma mensagem contendo
informação sobre o processamento do job é escrita no SQS QUEUE. Uma
instância do EC2 é então criada e utilizada para processar o job descrito na
fila. Uma vez realizado o processamento do job, uma mensagem é colocada
na fila de saída. Indo além do resumo e complementando-o temos os
seguintes passos a serem obedecidos:
1. arquivo de vídeo recebido é enviado para o repositório (bucket) do S3;
2. cliente escreve uma mensagem na fila de entrada do SQS;
3. instância do EC2 é criada;
4. instância do EC2 faz a leitura da fila de entrada do SQS;
5. com os dados da mensagem, o vídeo é copiado do S3 para a instância
local do EC2;
6. o vídeo é transcodificado e a saída gravada no S3;
7. EC2 escreve uma mensagem na fila de saída com o trabalho realizado;
8. confirmação do trabalho é lida pelo servidor local na fila de saída do
SQS.
Uma vez que todos os vídeos na fila de entrada foram transcodificados, as
instâncias do EC2 são liberadas. Ressaltamos uma questão extremamente
relevante desta implementação que é o seu baixo custo. O custo é inferior a
um centavo por vídeo. Além da redução do custo com esta solução não é
ncessário realizar um investimento inicial em infra-estrutura, nem tentar
fazer uma estimativa precisa do volume de recursos computacionais
necessários para o processamento.
78
CONCLUSÃO
Este trabalho apresenta a área ainda em evolução da computação em
nuvem,
incluindo
as
tecnologias
e
algumas
preocupações
de
implantação. Definições e normalização nesta área ainda é um trabalho em
andamento, mas há um claro valor adicionado ao tratar da computação em
nuvem como uma solução para vários requisitos de TICE. No capítulo III,
proporcionamos um olhar mais detalhado em algumas das tecnologias e
cenários de computação em nuvem. No capítulo IV concluimos a base teórica
com
a
apresentação
de
algumas
das
aplicações
brasileiras
em
desenvolvimento.
Este trabalho pode servir como um artefato didático educacional
(cartilha) sem conotação comercial, portanto neutra, sobre a área de
computação em nuvem.
No capítulo II, nós fornecemos uma introdução à área ainda em
constante evolução da computação em nuvem, incluindo as tecnologias e
algumas preocupações de implantação.
No capítulo III fornecemos uma visão mais detalhada sobre os fatores
de rede na nuvem, aspectos de segurança, e da Federação das
nuvens. Também destacamos algumas áreas que estão atraindo uma atenção
maior dos proponentes e vendedores de computação em nuvem.
No
capítulo IV, concluimos a base teórica com a apresentação de
algumas das aplicações brasileiras que estão em desenvolvimento.
A área de computação em nuvem é muito dinâmica e oferece espaço para
tecnologias inovadoras e novos modelos de negócios. Os trabalhos em curso
no que diz respeito às soluções é substancial, tanto nos laboratórios de
pesquisa de provedores e organizações de desenvolvimento de produto, bem
79
como na academia. É claro que a computação em nuvem vai se confrontar
com avanços e inovações significativos no próximos anos.
No dia 6 de junho de 2011, o presidente-executivo da empresa norteamericana Apple Inc., abrindo os trabalhos de sua conferência anual de
desenvolvedores de aplicativos de TICE, apresentou mundialmente o seu
serviço de nuvem denominado iCloud. A inscrição de qualquer usuário neste
serviço de nuvem privado lhe dará o direito de armazenar até 5 Gigabytes de
dados de forma não onerosa. Os arquivos dos usuários uma vez salvos na
nuvem iCloud serão compartilhados e aparecerão e estarão disponíveis para
serem acessados por todos os aparelhos da empresa que tenham sido
adquiridos pelos usuários, tais como computadores de mesa (iMac e MacPro),
computadores portáteis (MacBook, Pro, Air), computadores do tipo tablet
(iPad), telefones celulares multifunção(iPhone) e tocadores de música(iPod) e
reprodutores de vídeo(iPod touch). Manter todos esses dispositivos compostos
de PCs, tablets e smartphones em sincronia não é tarefa fácil, mas torna-se
responsabilidade do provedor do serviço de nuvem, liberando o usuário desta
obrigação. Nas palavras do executivo fundador da empresa, ele disse, “Nós
temos a solução: vamos rebaixar o PC a um dispositivo. Queremos mover sua
vida digital para a nuvem”.
Uma outra grande empresa norte-americana, a Microsoft já havia dado
um passo adiante na estratégia de adequação de seu modelo de negócios
para Internet, a dita Computação em Nuvem, tendo lançado no dia 17 de
janeiro de 2011 o seu programa Dynamics CRM em sua versão on-line para
gerenciar clientes. Assim este programa se juntou ao pacote Office, ao banco
de dados SQL e até ao sistema operacional Windows, todos desde já podendo
ser acessados pela Internet. O modelo é similar ao de empresas como
Salesforce.com, SugarCRM e Oracle. Essas empresas acreditam que a CN
democratiza o acesso à tecnologia, pois seus programas estarão disponíveis
as empresas de vários países e podem ser adquiridos e acessados pela
Internet mediante o pagamento de uma mensalidade por usuário.
80
As empresas do setor de TICE têm investido fortemente na oferta de
software, serviços e até equipamentos pela Internet. A ideia é aproveitar o
aumento nas velocidades de conexão à rede para criar ofertas capazes de
reduzir custos, tanto para quem compra, quanto para quem vende algo na
nuvem.
Para quem contrata, a vantagem é a economia auferida na compra de
máquinas e na contratação de mão de obra para fazer a estrutura de TICE
funcionar. Basta ter uma conexão à Internet.
Para quem vende, o uso de equipamentos é mais racional, já que não
há desperdício na capacidade utilizada e os custos de manutenção são
diluídos entre os diversos clientes.
Para empresas de software como a Microsoft, a nuvem traz uma outra
vantagem que é o controle da pirataria. Como os sistemas são acessados de
forma centralizada, não há o risco de que cópias ilegais sejam feitas e
distribuídas.
No setor de consultoria de TICE duas grandes empresas se destacam.
A primeira delas é a empresa Gartner Group cujas projeções de mercado da
CN em todo o mundo prevê um crescimento maior que o dobro até 2013,
gerando receitas da ordem de US$ 150 bilhões. A expansão ocorrerá, em
grande parte, em detrimento das vendas de sistemas no formato tradicional,
isto é, a de venda de licenças de uso para programas instalados nos
computadores de empresas e indivíduos. A segunda grande empresa do setor
de consultoria, o instituto International Data Corporation – IDC revelou que em
2010 a CN retirou US$ 7 bilhões das vendas de licenças de software em todo o
mundo.
81
Mirando esse mercado potencial de novos negócios, cada vez mais
empresas privadas tem investido relevantes recursos na construção e
montagem de Centros de Dados próprios ou em parceria visando colocar seus
principais produtos disponiveis nesse modelo.
Da mesma forma que a iniciativa privada se move em direção à nuvem o
serviço público também poderá fazê-lo desde que estalebeça como princípio
uma política pública direcionada ao atendimento das necessidades e
demandas dos cidadãos cada vez mais interconectados.
82
ANEXOS
Índice de anexos
Anexo 1 - Figuras, Diagramas e Quadros.
83
ANEXO 1
FIGURAS, DIAGRAMAS E QUADROS.
Número e página
Figura 1, pg 14
Figura 2,pg 14
Figura 3,pg 15
Quadro, pg17
Diagrama,pg 23
Figura 4,pg 25
Figura 5,pg 29
Figura 6,pg 40
Figura 7,pg 42
Figura 8,pg 45
Figura 7,pg 52
Figura 9,pg 53
Figura 10,pg 58
Figura 11,pg 59
Descrição
Hype Cycle of Emerging Technology
Exemplo CRM do Hype Cycle
Quadrante Mágico para infraestrutura de virtualização de
servidores na arquitetura x8
Histórico de Eventos
Diagrama da Ideia de Nuvem
Contexto da Computação em Nuvem
Hypervisors na Virtualização
FCoE in a Cloud Data-Center Environment
Example Data-Center Switch Network Architecture
Virtual Ethernet Switch in a Virtualized Server Environment
Example Data-Center Switch Network Architecture
Three-Tier Functional Server Architecture
Virtual Switch Aggregation and Management by External Node
Exemplo de Nuvem Privada
84
BIBLIOGRAFIA CONSULTADA
LEITE, RICARDO B., “Notas de Aulas da disciplina de Rede de Computadores
ministrada pelo Prof. MsC. Ricardo B.Leite”, 2011
SRIDHAR, T. “The Internet Protocol Journal”, Volume 12, No.3/4, 2010
TAURION, CEZAR
“Computação em Nuvem: transformando o mundo da
tecnologia da informação”. Editora Brasport, 2009
TAURION, CEZAR “Blog sobre computação em nuvens”
disponível http://computingonclouds.wordpress.com
acessado em : 29 de
junho de 2011
BIBLIOGRAFIA CITADA
1 - Draft NIST Working Definition of Cloud Computing,
disponível http://csrc.nist.gov/groups/SNS/cloud-computing/index.html
acessado em : 10 de junho de 2011
2 - "Identifying Applications for Public and Private Clouds," Tom Nolle,
Searchcloudcomputing,
disponível
http://searchcloudcomputing.techtarget.com/tip/0,289483,sid201_gci13587
01,00.html?track=NL1329&ad=710605&asrc=EM_NLT_7835341&uid=8788654 acessado em :
10 de junho de 2011
3 - "The Wisdom of Clouds," James Urquhart's blog on Cloud Computing,
disponível
http://news.cnet.com/the-wisdom-of-clouds/ acessado em : 11
de junho de 2011
85
4 - "Virtualization – State of the Art," SCOPE Alliance,
disponível http://www.scopealliance.org/sites/default/files/documents/SCOPE-VirtualizationStateofTheArt-Version-1.0.pdf acessado em : 11 de junho de 2011
5 - "Live Migration of Virtual Machines," Clark, et al.,
disponível http://www.cl.cam.ac.uk/research/srg/netos/papers/2005migration-nsdi-pre.pdf acessado em : 12 de junho de 2011
6 - "MapReduce: Simplified Data Processing on Large Clusters," Dean &
Ghemawat,
disponível http://labs.google.com/papers/mapreduce.html acessado em :
12 de junho de 2011
7 - "Cloud Computing Drives New Networking Requirements," The Lippis
Report, 120,
disponível
http://lippisreport.com/2009/02/lippis-report-120-cloud-
computing-drives-new-networking-requirements/ acessado em : 13 de
junho de 2011
8 - "A New Approach to Network Design When You Are in the Cloud," The
Lippis Report, 121,
disponível http://lippisreport.com/2009/03/a-new-approach-to-networkdesign-in-the-cloud/ acessado em : 13 de junho de 2011
9 - "Unified Fabric Options Are Finally Here," The Lippis Report, 126,
disponível http://lippisreport.com/2009/05/lippis-report-126-unified-fabricoptions-are-finally-here/ acessado em : 14 de junho de 2011
10 - "Virtualization with Hyper-V," Microsoft,
disponível http://www.microsoft.com/windowsserver2008/en/us/hypervoverview.aspx acessado em : 14 de junho de 2011
11 - "Citrix XenServer," Citrix,
disponível
http://www.citrix.com/English/ps2/products/feature.asp?contentID=1686939
acessado em : 15 de junho de 2011
86
12
-
"VMware
Virtual
Networking
Concepts,"
VMware,
disponívelhttp://www.vmware.com/files/pdf/virtual_networking_concepts.pdf
acessado em : 15 de junho de 2011
13 - "Cisco Nexus 1000v Virtual Ethernet Switch," Cisco Systems,
disponível http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9
902/data_sheet_c78-492971.html acessado em : 17 de junho de 2011
14
-
"Application
Delivery
Layland
Challenge,"
Consulting,
disponível http://www.edgedelivery.org/dl/whitepapers/Application_Delivery_Challenge.pdf
acessado
em : 18 de junho de 2011
15 - "Cloud Networking: Design Patterns for 'Cloud-Centric' Application
Environments,"
disponível http://www.aristanetworks.com/en/CloudCentricDesignPatterns.p
df acessado em : 20 de junho de 2011
16
-
IEEE
802.1Qaz
–
Enhanced
Transmission
Selection,
disponível http://www.ieee802.org/1/pages/802.1az.html acessado em : 21
de junho de 2011
17
-
IEEE
802.1Qau
–
Congestion
Notification,
disponível http://www.ieee802.org/1/pages/802.1au.html acessado em : 22
de junho de 2011
18
disponível
IEEE
802.1Qbb
–
Priority
Flow
Control,
http://www.ieee802.org/1/pages/802.1bb.html acessado em :
23 de junho de 2011
19
-
IEEE
802.1aq
–
Shortest
Path
Bridging,
disponível http://www.ieee802.org/1/pages/802.1aq.html acessado em : 25
de junho de 2011
20 - IETF Transparent Interconnection of Lots of Links (trill) Working Group,
disponível http://www.ietf.org/dyn/wg/charter/trill-charter.html acessado em :
27 de junho de 2011
87
21 -
T. Sridhar, "Cloud Computing: A Primer, Part 1: Models and
Technologies," The
Internet
Protocol
Journal, Volume
12,
No.
3,
September 2009.
22 -
"Building Data-Centric n-Tier Enterprise Systems," PowerVision white
paper,
disponível http://www.powervision.com/html/news/n_tier_arch.pdf acessado
em : 01 de junho de 2011
23
-
"Networking
in
the
(Storm)
Clouds,"
Michael
Morris,
disponível http://www.networkworld.com/community/node/43872 acessado
em : 02 de junho de 2011
24
-
"Is
the
Relational
Database
Doomed?"
Tony
Bain,
disponível http://www.readwriteweb.com/enterprise/2009/02/is-therelational-database-doomed.php acessado em : 02 de junho de 2011
25
-
"Cisco
VN-Link:
Virtualization-Aware
Networking,"
disponível http://www.cisco.com/en/US/solutions/collateral/ns340/ns517/ns
224/ns892/ns894/white_paper_c11525307_ps9902_Products_White_Paper.html acessado em : 02 de junho
de 2011
26 - IEEE work (in progress) on Virtual Ethernet Bridging—VEPA and VN-Tag
approaches—search for "VEPA" and "VN-Tag" in the directory at:
disponível http://www.ieee802.org/1/files/public/docs2009 acessado em :
23 de junho de 2011
27 - "PortLand: A Scalable Fault-Tolerant Layer 2 Data Center Network Fabric,"
Mysore
et
al.,
disponível http://ccr.sigcomm.org/online/?q=node/503 acessado em : 04 de
junho de 2011
28 - "VL2: A Scalable and Flexible Data Center Network," Greenberg et al.,
disponível
http://ccr.sigcomm.org/online/?q=node/502 acessado em : 05
de junho de 2011
29 - "The Case for Enterprise-Ready Virtual Private Clouds," Wood et al.,
disponível http://www.usenix.org/event/hotcloud09/tech/full_papers/wood.p
df acessado em : 09 de junho de 2011
88
30 - "Solving the Problem of Cloud Interoperability," Reuven Cohen,
disponível http://reuvencohen.sys-con.com/node/798504 acessado em : 10
de junho de 2011
31 - "Security Guidance for Critical Areas of Focus in Cloud Computing," Cloud
Security
Alliance,
disponível http://www.cloudsecurityalliance.org/guidance/csaguide.pdf
acessado em : 11 de junho de 2011
32 - Rational Survivability Blog, Chris Hoff's blog on various topics, including
cloud
security,
disponível http://www.rationalsurvivability.com/blog/ acessado em : 15 de
junho de 2011
33 - "Hey, You, Get Off of My Cloud: Exploring Information Leakage in ThirdParty
Compute
Clouds"
by
Ristenpart,
et
al,
disponível http://people.csail.mit.edu/tromer/papers/cloudsec.pdf acessado
em : 15 de junho de 2011
34 - "Empirical Exploitation of Live Virtual Machine Migration," Oberheide et
al.,
disponível http://www.eecs.umich.edu/techreports/cse/2007/CSE-TR-53907.pdf acessado em : 17 de junho de 2011
35
-
List
of
and
links
to
cloud
standards
organizations,
disponível http://cloud-standards.org/wiki/index.php?title=Main_Page/
acessado em : 18 de junho de 2011
36
-
"Open
Virtualization
Format
Specification,"
DMTF,
disponível
http://www.dmtf.org/standards/published_documents/DSP0243_1.0.0.pdf
acessado em : 19 de junho de 2011
37 - "SOA cloud computing relationship leaves some folks in a fog," David
Linthicum,
disponível http://www.gcn.com/Articles/2009/03/09/Guest-commentarySOA-cloud.aspx acessado em : 20 de junho de 2011
89
38 - "Is your data center ready for virtualization," Eaton white paper,
disponível http://i.zdnet.com/whitepapers/Eaton_Is_your_data_center_read
y_for_virtualization.pdf acessado em : 21 de junho de 2011
39 - "The great paradigm shift of cloud computing is not self-service," James
Urquhart,
disponível http://news.cnet.com/8301-19413_3-10127654240.html?tag=mncol;txt acessado em : 22 de junho de 2011
90
ÍNDICE
FOLHA DE ROSTO
2
AGRADECIMENTO
3
DEDICATÓRIA
4
RESUMO
5
METODOLOGIA
6
SUMÁRIO
7
INTRODUÇÃO
8
CAPÍTULO I
O HYPE CYCLE E A COMPUTAÇÃO EM NUVENS
11
1.1 - O HYPE CYCLE E A COMPUTAÇÃO EM NUVENS
12
1.2 – O QUADRANTE MÁGICO DA VIRTUALIZAÇÃO DE SERVIDORES
FÍSICOS COM ARQUITETURA X86
14
1.2.1 - Visão do Mercado
16
1.2.2 - Definição e descrição do Mercado
18
1.2.3 - Critérios de Inclusão e Exclusão no Quadrante Mágico adotados
pela consultoria Gartner
18
1.2.4 - Comunidades de Código Aberto( por exemplo, hypervisors Xen e
KVN) versus Modelos de Negócios de Software de Código Aberto
patrocinados por fornecedores
19
CAPÍTULO II
MODELOS E TECNOLOGIAS
22
CAPÍTULO III
INFRAESTRUTURA E IMPLEMENTAÇÃO
49
CAPÍTULO IV
APLICAÇÕES BRASILEIRAS EM DESENVOLVIMENTO
73
CONCLUSÃO
78
ANEXOS
82
BIBLIOGRAFIA CONSULTADA
84
BIBLIOGRAFIA CITADA
84
ÍNDICE
90
91
FOLHA DE AVALIAÇÃO
Nome da Instituição:
Título da Monografia:
Autor:
Data da entrega:
Avaliado por:
Conceito: