computaÇÃo em nuvem: uma nova abordagem em … · computaÇÃo em nuvem: uma nova abordagem em...
TRANSCRIPT
COMPUTAÇÃO EM NUVEM:
UMA NOVA ABORDAGEM EM AMBIENTES DE REDE
ANDRÉ COVELINHAS DA ROCHA
Centro Universitário da Cidade do Rio de Janeiro
RIO DE JANEIROJUNHO/2009
COMPUTAÇÃO EM NUVEM:
UMA NOVA ABORDAGEM EM AMBIENTES DE REDE
ANDRÉ COVELINHAS DA ROCHA
Centro Universitário da Cidade do Rio de Janeiro
Prof. FREDERICO SAUER
Orientador
RIO DE JANEIROJUNHO/2009
II
COMPUTAÇÃO EM NUVEM:UMA NOVA ABORDAGEM EM AMBIENTES DE REDE
André Covelinhas da Rocha
Projeto desenvolvido durante o curso de Tecnologia em Redes de Computadores, apresentado ao Centro Universitário da Cidade, UniverCidade, como pré-requisito para obtenção do título de Tecnólogo em Redes de Computadores.
Comissão Examinadora:
________________________________________Prof. Frederico Sauer Guimarães Oliveira, Doutor
________________________________________Prof. Celso Rabelo Machado Pinto, Especialista
________________________________________Prof. Rodrigo de Almeida David, Especialista
RIO DE JANEIROJUNHO/2009
III
Este trabalho reflete a opinião do autor e não
necessariamente a da UniverCidade. Autorizo por
meio desta a difusão deste trabalho.
____________________________________André Covelinhas da Rocha
IV
DEDICATÓRIA
Este trabalho é dedicado a minha família,
especialmente minha mãe, que graças a sua
confiança, seu apoio, seu incentivo e
principalmente pela dádiva da vida, tenho mais
uma vez a oportunidade de expressar a minha
opinião.
Dedico também a todos os meus professores, que
tanto se sacrificam para trazer conhecimentos que
muitas vezes excedem os limites do escopo das
disciplinas que ministram. A eles, entrego através
deste gesto simbólico o título de verdadeiros
amigos, em especial ao Prof Sauer, ao Prof Celso,
ao Prof Sobral e ao Prof Paulo.
A materialização deste trabalho reflete todo o
ensinamento que foi adquirido.
André Covelinhas da Rocha
V
AGRADECIMENTOS
Agradeço a Deus por mais esta oportunidade, a
minha mãe, a minha namorada Fabíola, ao meu
orientador, aos demais professores e a todos os
meus amigos, inclusive os de âmbito profissional
e acadêmico, por acreditarem em mim, me
apoiarem, confiarem, incentivarem e também pela
compreensão pelas faltas que deixei no período
em que me dediquei a extenuante tarefa que
concluí com a realização deste trabalho. A minha
namorada, agradeço pela paciência e pelo
carinho, e por sempre me incentivar a fazer e agir
da melhor forma possível, o que me empurra
além do limite e faz com que eu descubra novas
capacidades.
André Covelinhas da Rocha
VI
EPÍGRAFE
Sucesso, é conquistar aquilo que você ama. Felicidade, é
amar aquilo que você já conquistou.
Dalai Lamma
VII
SUMÁRIO
CAPÍTULO 1 .....................................................................................................................10
1 - INTRODUÇÃO ............................................................................................................10
CAPÍTULO 2 .....................................................................................................................12
2 - COMPUTAÇÃO EM NUVEM ....................................................................................12
2.1. COMPARAÇÕES .......................................................................................................14
2.2. HISTÓRIA ..................................................................................................................16
2.3. ANATOMIA DA COMPUTAÇÃO EM NUVEM ......................................................18
2.3.1. Software Como Serviço.............................................................................................19
2.3.2. Plataforma Como Serviço.........................................................................................19
2.3.3. Infra-estrutura Como Serviço....................................................................................20
2.4. TIPOS DE IMPLEMENTAÇÃO DA NUVEM ..........................................................22
2.4.1. Nuvens Públicas........................................................................................................22
2.4.2. Nuvens Privadas........................................................................................................22
2.4.3. Nuvens Híbridas........................................................................................................23
2.5. APROVEITAMENTO DA NUVEM ..........................................................................23
2.5.1. Usando a Nuvem.......................................................................................................24
2.5.2. Alavancando a Nuvem..............................................................................................24
2.5.3. Construindo a Nuvem................................................................................................26
2.6. CARACTERÍSTICAS ................................................................................................26
2.6.1. Independência de Dispositivo e Local......................................................................26
2.6.2. Multi-locação............................................................................................................27
2.7. MITIGAÇÃO DE RISCOS..........................................................................................28
VIII
CAPÍTULO 3 .....................................................................................................................31
3 - VIRTUALIZAÇÃO ......................................................................................................31
3.1. VIRTUALIZAÇÃO DE SISTEMAS OPERACIONAIS ............................................37
3.2. VIRTUALIZAÇÃO DE PLATAFORMA ...................................................................37
3.3. VIRTUALIZAÇÃO DE REDE ...................................................................................39
3.4. VIRTUALIZAÇÃO DE APLICAÇÕES .....................................................................40
CAPÍTULO 4 .....................................................................................................................42
4 - IMPLEMENTANDO UM AMBIENTE DE NUVEM .................................................42
4.1. SISTEMAS UTILIZADOS .........................................................................................43
4.2. DIAGRAMA DE REDE .............................................................................................46
4.3. INSTALAÇÃO DOS SISTEMAS ..............................................................................50
4.3.1. Firewall + Proxy Reverso + DNS..............................................................................51
4.3.1.1. Configurações de Segurança..................................................................................53
4.3.1.2. Configurações do Serviço DNS..............................................................................56
4.3.1.3. Configurações do Proxy Reverso...........................................................................60
4.3.2. Cloud Server..............................................................................................................62
4.3.2.1. Instalação dos Softwares Necessários....................................................................65
4.3.3. Gerência....................................................................................................................71
4.4. CONSIDERAÇÕES SOBRE A CONTRIBUIÇÃO DO TRABALHO ......................86
CAPÍTULO 5 .....................................................................................................................88
5 - CONCLUSÃO ..............................................................................................................88
APÊNDICE 1 – ARQUIVO DE CONFIGURAÇÃO DO VICOMPRESS ..................92
REFERÊNCIAS BIBLIOGRÁFICAS .........................................................................93
IX
10
CAPÍTULO 1
1 - INTRODUÇÃO
Na era tecnológica contemporânea, têm-se recursos computacionais mais
que suficientes para atender a grande maioria das necessidades de usuários, sejam eles
domésticos ou empresariais. No entanto, paga-se por “poder de fogo” além do que
realmente é necessário, pois para muitos se faz necessário apenas a leitura e envio de
mensagens, navegação web, e acesso a sistemas de escritório. Despesas com maquinário
estão sempre acompanhadas de despesas de manutenção, pois computadores possuem
inúmeros componentes físicos (hardware) e lógicos (software) interdependentes. A fim de
minimizar desperdício de recursos computacionais e também de capital com atividades
mantenedoras e renovação de licenças de software, propõe-se a utilização de um ambiente
centralizado em “nuvem”, não suscetível a perda de informações, e acessível de qualquer
lugar do mundo, através de dispositivos conectados à internet.
Este trabalho apresenta de forma objetiva e prática o conceito de
Computação em Nuvem (Cloud Computing), e como projetar e implementar este ambiente,
11
de forma a torná-lo capaz de fornecer funcionalidades essenciais ao expediente de todos,
sejam usuários domésticos ou empresariais.
A Computação em Nuvem é uma tecnologia emergente que altera o conceito
em termos de infra-estrutura, onde a execução de dados e softwares acontece diretamente
na nuvem (internet). Ela abstrai a plataforma de aplicação de softwares da infra-estrutura
de hardware subjacente, desobrigando o usuário de estar preso a um hardware específico.
A Computação em Nuvem está mostrando que é possível nos dias atuais o
uso de tecnologia antes apresentada apenas em publicações sobre tecnologias do futuro.
O trabalho está segmentado da seguinte forma: O capítulo 2 descreve os
conceitos fundamentais da computação em nuvem. O capítulo 3 descreve os tipos de
virtualização existentes, e de que forma elas estão inseridas no conceito deste trabalho. O
capítulo 4 descreve os passos necessários para implementar e gerenciar um ambiente de
nuvem, e descreve as considerações a respeito da contribuição do trabalho. O capítulo 5
conclui o trabalho.
12
CAPÍTULO 2
2 - COMPUTAÇÃO EM NUVEM
Computação em Nuvem é um modelo emergente de computação, que se
refere ao uso de tecnologia computacional (Computação), e desenvolvimento e distribuição
de aplicações baseadas em internet (Nuvem), onde recursos são dinamicamente
virtualizados e dimensionados de forma escalável1, para serem disponibilizados como
serviços na web. Uma característica interessante da Computação em Nuvem é o fato da
mesma ocultar de desenvolvedores e usuários finais a complexidade de sua infra-estrutura,
apresentando aos mesmos apenas uma interface para acesso aos sistemas. Usuários não
precisam ter conhecimento ou até mesmo saber o que existe no interior da nuvem para que
possam se beneficiar de seus recursos. Este modelo de utilização pode ser melhor
entendido na ilustração 1, onde a área identificada por 1 representa de forma abstraída o
interior da infra-estrutura real, e a área identificada por 2 representa o que é percebido
pelos usuários.
1 Passível de aumento de capacidade de forma dinâmica, de acordo com a necessidade.
13
A Nuvem é uma metáfora para internet, baseada em como ela é representada
nos diagramas de redes de computadores. Ela é uma abstração da complexa arquitetura que
representa.
Tim O'Reilly, CEO2 da O'Reilly Media, definiu a computação em nuvem da
seguinte forma:
“It's one of the foundations of the next generation of computing. It's a world where the network is the platform for all computing, where everything we think of as a computer today is just a device that connects to the big computer we're building. Cloud computing is a great way to think about how we'll deliver computing services in the future.”
De acordo com esta definição, a computação em nuvem é um dos
fundamentos para a próxima geração de computação, onde a rede será a plataforma, e tudo
o que se pensa hoje em termos de computador, será apenas um dispositivo que se conectará
ao grande computador que está sendo construído. A computação em nuvem é uma grande
forma de pensar como serão distribuídos serviços computacionais no futuro.
2 CEO: Chief Executive Officer. Em português, "Diretor-executivo" ou "diretor-geral".
Ilustração 1: Acesso a recursos em nuvem
14
2.1 - COMPARAÇÕES
A Computação em Nuvem é freqüentemente confundida com os seguintes
termos:
● Computação em Grade (Grid Computing), que é uma forma de
computação distribuída onde um “Super e Virtual Computador” é composto de um cluster
de computadores fracamente acoplados 3 , agindo em conjunto para realizar tarefas maiores.
Grids também necessitam que aplicações estejam em conformidade com suas interfaces de
software (IBM Grid Literature, 2006). O modelo grid difere do modelo de nuvem, pois é
voltado a realização de tarefas específicas, com início e fim definidos, onde o modelo de
nuvem (que pode utilizar em sua arquitetura a tecnologia de grid), é voltado ao
fornecimento contínuo de um serviço.
● Computação Utilitária (Utility Computing), que é o “empacotamento”
e disponibilização de recursos computacionais de processamento e armazenamento, através
de um modelo de negócio de fornecimento de serviços, similar ao modelo adotado no
fornecimento de energia elétrica, onde consumidores pagam pela quantidade de recursos
consumidos. Embora pareçam similares, as diferenças entre utility computing e cloud
computing são grandes. Utility computing está relacionada ao modelo de negócio em que
se baseia o fornecimento de serviços, através da infra-estrutura de um provedor, onde
normalmente o aumento de capacidade está atrelado ao upgrade de recursos. Já Cloud
computing, apesar de utilizar o mesmo sistema de cobrança e fornecimento de serviços,
3 Computadores interligados através de uma rede.
15
possui habilidade para crescimento dinâmico de capacidade, tornando possível a alocação
de recursos sob-demanda, em tempo real, permitindo que aplicações que necessitem de
processamento mais intensivo não se limitem a capacidade de uma determinada infra-
estrutura. (IBM Systems Journal, 2004)
● Computação Autonômica (Autonomic Computing), que são sistemas
de computadores capazes de auto-gerenciamento. O conceito teve origem quando a
preocupação com o aumento do poder de processamento deixou de ser tão grande, e
decidiu-se mudar a linha de pesquisa de forma a descobrir meios de construir
computadores mais “inteligentes”, ao invés de poderosos. A abordagem utilizada para esta
adição de inteligência foi a construção de sistemas baseados em elementos artificiais
inspirados em elementos biológicos, permitindo assim que sistemas solucionem seus
próprios problemas, dispensando a alocação de tempo e mão-de-obra necessárias a
realização de manutenções. (IBM Research – Autonomic Computing, 2009)
Em computação em nuvem, o crescimento dinâmico de ambientes depende,
entre outras coisas, que sistemas sejam capazes de perceber situações e tomar decisões por
conta própria.
De fato, muitas implementações de Computação em Nuvem realizadas
atualmente, dependem de grids, possuem características autonômicas e são cobradas como
serviços tradicionais.
Nota do Autor:4 Este trabalho utiliza o termo “Servidor” para remeter a serviços e aplicações. O termo, em nenhuma forma, está diretamente associado a máquinas ou computadores, e sim, as aplicações que são executadas nos mesmos.
4 Servidor não é máquina, e sim, um processo. (Simone Markenson, 2008)
16
2.2 - HISTÓRIA
Resumidamente, computação em nuvem é um meio de distribuir recursos de
TI como serviços. Quase todos os recursos de TI podem ser distribuídos como um serviço
de nuvem: aplicações, poder de processamento, capacidade de armazenamento,
networking, ferramentas de desenvolvimento, e até mesmo serviços de comunicação.
A computação em nuvem começou a ser utilizada em larga escala por
provedores de serviços de internet como Google5, Amazon6 e outros, com a construção de
suas próprias infra-estruturas. Assim, uma nova arquitetura emergiu: Massively Scaled -
Recursos de sistemas distribuídos horizontalmente, abstraídos como serviços virtuais de
TI, agrupados e gerenciados continuamente. Este modelo arquitetural foi apresentado por
George Gilder, através do artigo The Information Factories7. Este artigo fala sobre uma
arquitetura, onde os dados estão em sua maioria residentes em servidores em “algum lugar
na internet”, e as aplicações rodam tanto em “servidores de nuvem” quanto no browser do
usuário.
Tanto nuvens como grids são construídos para escalonar horizontalmente de
forma muito eficiente. Ambos foram desenhados para resistir a falhas de nós ou elementos
individuais, e são cobrados por uso. No entanto, normalmente grids processam trabalhos
5 Google App Engine: Com o Google App Engine, é possível criar aplicativos da web sobre os mesmos sistemas escaláveis dos aplicativos do Google, através do fornecimento de um ambiente de aplicativos totalmente integrado, que facilita a criação de aplicativos escaláveis, que crescem de um usuário para milhões, sem preocupações com a infra-estrutura. <http://code.google.com/intl/pt-BR/appengine/> Acessado em 05 de abril de 2009.
6 Amazon EC2: Serviço web, que fornece através de nuvem, capacidade computacional redimensionável. É desenhado de forma a tornar mais fácil para desenvolvedores o escalonamento de aplicações web. <http://aws.amazon.com/ec2/> Acessado em 05 e abril de 2009.
7 The Information Factories: Revista Wired, outubro de 2006. <http://www.wired.com/wired/archive/14.10/cloudware.html> Acessado em 05 de abril de 2009.
17
em série, com um ponto de início e fim definidos, a despeito de serviços em nuvem, que
podem ser contínuos. Além disso, nuvens expandem os tipos de recursos disponíveis
(armazenamento de arquivos, bancos de dados, e serviços web), e aumentam a
aplicabilidade da web para aplicações empresariais.
Ao mesmo tempo, o conceito de computação utilitária (utility computing),
tornou-se foco em projetos e operações de TI. Como Nick Carr observou em seu livro The
Big Switch8, a infra-estrutura de serviços de computação estava começando a se tornar
similar ao uso da eletricidade como serviço fundamental. O livro em questão fala sobre
como seria excepcional poder comprar recursos computacionais sob-demanda, pagando
apenas pelo que fosse necessário, quando necessário.
Para usuários finais, computação em nuvem significa que não existem
custos com aquisição de hardware, gerenciamento de licenças ou upgrades de software,
contratação de novos empregados ou consultores, locação de instalações, e custos de
capital de qualquer natureza. Não existem custos implícitos, apenas uma contagem pelo
consumo ou uma taxa fixa de inscrição. Utiliza-se somente o que for necessário, e paga-se
somente pelo que for utilizado.
A computação em nuvem eleva o modelo de computação utilitária ao
próximo nível. É uma forma nova e evoluída deste modelo, em que muitos tipos diferentes
de recursos (hardware, software, armazenamento, comunicações, etc.) podem ser
combinados e recombinados on the fly9, para alcançar capacidades ou serviços específicos,
de acordo com a necessidade do cliente. Desde ciclos de CPU para projetos de HPC (high
performance computing10) a altíssima capacidade de armazenamento para backups de
8 The Big Switch <http://www.nicholasgcarr.com/bigswitch/> Acessado em 05 e abril de 2009.9 O termo On The Fly significa em tempo de vôo, ou seja, em tempo de execução, sem a necessidade de
paralisação para alterar configurações.10 High Performance Computing: Modelo de computação de alto desempenho, utilizado para processamento
intensivo de dados, através de uma rede fracamente acoplada. Exemplo: Cluster.. <http://www.sun.com/servers/hpc/index.jsp> Acessado em 05 de abril de 2009.
18
grandes corporações, a computação em nuvem pode, em tempo real, distribuir virtualmente
qualquer capacidade de TI.
2.3 - ANATOMIA DA COMPUTAÇÃO EM NUVEM
Enquanto a primeira revolução da internet viu o modelo three-tier11 ou n-
tier emergir como uma arquitetura geral, o uso de virtualização em nuvens criou um novo
conjunto de camadas: aplicação, plataforma e infra-estrutura. Estas camadas não
encapsulam apenas recursos sob-demanda, mas também definem um novo modelo de
desenvolvimento de aplicações. Em cada camada de abstração, existe uma miríade de
oportunidades de negócio, no tocante a definição de serviços que podem ser oferecidos em
uma base pay-per-use12.
11 Three-tier: Modelo de programação em três camadas, onde o software é desenvolvido baseando-se em camadas de responsabilidades, e cada uma destas partes é executada em um computador diferente (Ariel Ortiz Ramirez, Julho de 2000). <http://www.linuxjournal.com/article/3508> Acessado em 05 de abril de 2009.
12 Pay-per-use: Diretamente traduzido para o português: "pague para usar".
Ilustração 2: Camadas da Computação em Nuvem
19
A ilustração 2 representa a fundação das camadas existentes em uma
arquitetura de nuvem. Como se pode perceber, é necessário que se possua uma infra-
estrutura sólida, para que sob a mesma, possa estabelecer-se uma plataforma onde serão
disponibilizadas aplicações baseadas em nuvem.
2.3.1 - SOFTWARE COMO SERVIÇO (Software as a Service – SaaS): Representada
como “Aplicação” na ilustração 1, é a camada mais alta, e possui como característica
oferecer serviço sob-demanda, em forma de uma aplicação completa, via “multi-
arrendamento” ou multitenancy (uma única instância de um software executa na infra-
estrutura e servidores de um operador de nuvem, e serve a múltiplas organizações clientes -
tenants). Um exemplo de SaaS é a empresa Salesforce.com. No entanto, existem outros,
incluindo o Google Apps, que oferece serviços básicos de negócio, como o e-mail. As
aplicações da Salesforce.com precedem em alguns anos a definição de computação em
nuvem. No entanto, esta empresa criou um outro segmento, o Force.com, e passou a operar
em mais de uma camada de computação em nuvem. Este segmento se apresenta de forma a
ser um ambiente amigável de desenvolvimento de aplicações, também conhecido como
Plataforma como Serviço.
2.3.2 - PLATAFORMA COMO SERVIÇO (Platform as a Service – PaaS):
Representada como “Plataforma” na ilustração 1, é a camada do meio, e prevê o
encapsulamento por abstração de um ambiente de desenvolvimento de serviços. Este
ambiente abstraído normalmente é, por exemplo, uma imagem Xen13 (adotado pela Amazon
13 Xen: É um hypervisor, e suas imagens são máquinas virtualizadas. <www.xen.org> Acessado em 06 de abril de 2009.
20
Web Services) ou Vmdk14, contendo uma “pilha” básica web, que pode ser, por exemplo,
uma distribuição Linux, com um servidor web e um ambiente de programação (como Perl15
ou Ruby16).
Ofertas de PaaS podem sustentar todas as fases do desenvolvimento e teste
de softwares, e podem também ser específicas a uma área particular, como gerência de
conteúdos.
Um exemplo comercial deste tipo de oferta é o Google App Engine, que
serve aplicações na infra-estrutura do Google. Serviços PaaS como este podem prover uma
grande flexibilidade. No entanto, podem ser limitados pela capacidade disponível no
provedor.
2.3.3 - INFRA-ESTRUTURA COMO SERVIÇO (Infrastructure as a Service – IaaS):
Representada como “Infra-estrutura” na ilustração 1, é a camada mais baixa de serviço
fornecido, e representa um meio de distribuir através da rede serviços padronizados de
armazenamento e capacidade computacional. Servidores, sistemas de armazenamento,
switches, roteadores, e outros dispositivos são agrupados (através de tecnologia de
virtualização, por exemplo) de forma a serem capazes de lidar com tipos específicos de
cargas.
O exemplo comercial mais conhecido desta camada é o Amazon Web
14 Vmdk (Virtual Machine Disk): É um dos formatos de discos virtuais utilizados por máquinas abstraídas pelos produtos da VMware <www.vmware.com> Acessado em 06 de abril de 2009.
15 Perl (Practical Extraction And Report Language): É uma linguagem de programação estável e multiplataforma, utilizada em aplicações de missão crítica, onde destaca-se o uso para desenvolvimento de aplicações web de todos os tipos. <http://www.perl.org/> Acessado em 05 abril de 2009.
16 Ruby: Linguagem dinâmica, open source, com foco na simplicidade e na produtividade. Tem uma sintaxe elegante de leitura natural e fácil escrita. <http://www.ruby-lang.org/pt/> Acessado em 05 abril de 2009.
21
Services, cujos serviços EC26 e S317 oferecem capacidade computacional e de
armazenamento, respectivamente. Outro exemplo é a Joyent <http://www.joyent.com/>
acessado em 05 de abril de 2009, cujo produto principal é uma linha de servidores
virtualizados que fornecem uma infra-estrutura de alta escalabilidade sob-demanda, com a
finalidade de rodar páginas web, incluindo aplicações mais bem elaboradas, escritas em
Ruby on Rails18, PHP19, Python20 e Java21. Existe também o GoGrid
<http://www.gogrid.com/> acessado em 06 de abril de 2009, que opera de forma
semelhante à este último.
17 S3: Simple Storage Service – Serviço de armazenamento para internet, destinado a tornar a computação escalar para web mais fácil para desenvolvedores. <http://aws.amazon.com/s3/> Acessado em 05 de abril de 2009.
18 Ruby on Rails: É um framework de desenvolvimento web, gratuito e de código aberto. <http://www.rubyonrails.pro.br/> Acessado em 05 de abril de 2009.
19 PHP (Hypertext Preprocessor): É uma linguagem de programação amplamente utilizada, voltada ao desenvolvimento de conteúdo dinâmico para web. <http://php.net/> Acessado em 05 de abril de 2009.
20 Python: É uma linguagem de programação de alto nível orientada a objetos, que pode ser utilizada para o desenvolvimento de vários tipos de aplicações. <http://www.python.org/> Acessado em 05 de abril de 2009.
21 Java: Sua versatilidade, eficiência, portabilidade de plataforma e segurança fazem dela a tecnologia ideal para a computação em rede. <http://java.com/pt_BR/about/> Acessado em 05 de abril de 2009.
Ilustração 3: Tipos de serviços de nuvem e alguns ofertantes, sobre as camadas que tornam possível a computação em nuvem.
Autor: Cloudtrends.
22
A ilustração 3 exemplifica, na cor azul, os tipos de serviços de nuvem
apresentados e algumas de suas operadoras. Na cor verde, as camadas tecnológicas que
tornam a computação em nuvem possível. Nesta ilustração, têm-se uma visão mais clara da
hierarquia tecnológica que dá origem a computação em nuvem.
2.4 – TIPOS DE IMPLEMENTAÇÃO DA NUVEM
Uma companhia pode escolher utilizar um provedor de serviços de nuvem
ou construir seu próprio. Esta possibilidade deu origem a alguns conceitos, que possuem
vantagens distintas: (Sun, 2009)
2.4.1 - NUVENS PÚBLICAS: São geridas por terceiros, e tarefas de muitos clientes
diferentes compartilham recursos da infra-estrutura existente no interior da nuvem.
Usuários finais não possuem visão sobre as tarefas de outros, e estas por sua vez, podem
estar em execução no mesmo recurso, ao mesmo tempo. Esta é a forma tradicional de
computação em nuvem, e também é conhecida como nuvem externa.
2.4.2 - NUVENS PRIVADAS: São uma boa opção para companhias que lidam com
proteção de dados e necessidades relacionadas ao nível de serviço. Elas são uma infra-
estrutura sob-demanda, mantidas por um único cliente, que controla quais aplicações irão
executar, e onde. Neste modelo privado, o cliente possui o servidor, a rede, os discos, e
23
pode decidir quais usuários estarão autorizados a utilizar a infra-estrutura. Esta forma de
computação em nuvem também é conhecida como nuvem interna.
Mesmo os que se sentirem compelidos a construir uma arquitetura de nuvem
privada, provavelmente sentirão a necessidade de executar também aplicações no espaço
de uma nuvem pública. Esta necessidade dá origem a um outro conceito: o de Nuvem
Híbrida.
2.4.3 - NUVENS HÍBRIDAS: Combinam os modelos de nuvem pública e privada. Neste
modelo, existem partes da infra-estrutura que são de uso exclusivo e partes que são de uso
compartilhado. Nuvens híbridas pretendem oferecer escalonamento externo e sob-
demanda, ao custo de ser necessário lidar com a complexidade existente em determinar
como aplicações serão distribuídas por estes ambientes diferentes. Embora empresas
possam se sentir atraídas pelas promessas de uma nuvem híbrida, acredita-se que esta
opção, pelo menos inicialmente, será reservada apenas a aplicações apátridas, que não
necessitarão de bancos de dados complexos ou esquemas de sincronização.
2.5 - APROVEITAMENTO DA NUVEM
Computação em nuvem não significa apenas que um usuário possa carregar
em uma nuvem pública imagens de máquinas contendo toda sua pilha de software, como
no caso da Amazon Web Services. Existem vários caminhos diferentes para explorar esta
infra-estrutura, juntamente com o ecossistema de novos modelos de negócio.
24
2.5.1 - USANDO A NUVEM: O número e qualidade de ofertas públicas de serviços
baseados em nuvem é crescente (Johnm Willis, 2008). Usar uma nuvem é freqüentemente
a melhor opção para iniciantes, projetos de pesquisa, desenvolvedores de web 2.0 ou
apenas experimentadores, que desejem uma maneira simples e de baixo custo para iniciar.
Quando se é iniciante em internet, é recomendável que se mantenha os custos com TI os
menores possíveis. Esta é exatamente a finalidade de uma nuvem. A ilustração 4
exemplifica alguns dos ofertantes de serviços de nuvem.
2.5.2 - ALAVANCANDO A NUVEM: Normalmente, empresas estão utilizando nuvens
públicas para funções específicas ou gerenciamento de picos de carga. A nuvem é uma
alternativa para:
● Teste e Desenvolvimento: Este provavelmente é o caso mais
interessante para empresas (e não apenas desenvolvedores iniciantes). Não há a
necessidade de comprar computadores para iniciar um determinado projeto, sem saber se o
mesmo será aprovado.
Ilustração 4: Ofertas de serviços de nuvem. Autor: Dion Hinchcliffe.
25
● Descarga Funcional: Pode-se utilizar a nuvem para gerenciar picos de
carga específicos. Como exemplo, a empresa SmugMug22 processa a miniaturização de
imagens através de um processo batch (em seqüência) na nuvem. Segue um
pronunciamento de Don MacAskill, CEO da SmugMug:
“We really don't want to operate datacenters anymore. We'd rather spend our time giving our customers great service and writing great software than managing physical hardware.”
Este pronunciamento expressa a vontade do diretor em focar seu tempo no
desenvolvimento de melhores aplicações para os clientes, ao invés de desperdiçá-lo com
administração de equipamentos.
● Antecipação: Nuvens oferecem uma nova opção para gerenciar picos
de carga ou antecipar picos para serviços em demanda. Esta é uma opção muito atraente
para empresas. No entanto, potencialmente é um dos mais difíceis casos de uso, pois o
sucesso é dependente do estado total da aplicação, e também da interdependência com
outros conjuntos de dados que podem necessitar serem replicados e balanceados entre dois
sites.
● Experimentação: Não será mais necessário realizar o download de
demos de novos softwares, para depois instalá-los, licenciá-los e só então poder testá-los.
No futuro, a avaliação de softwares pode ser realizada dentro da nuvem, antes que licenças
e suporte precisem ser comprados.
22 SmugMug: Serviço de compartilhamento de vídeos e fotos. <http://www.smugmug.com/> Acessado em 05 de abril de 2009.
26
2.5.3 - CONSTRUINDO A NUVEM: Apesar dos benefícios econômicos da computação
em nuvem, é necessária muita cautela na adoção da plataforma, pois deve-se antes de
qualquer movimento, assegurar a aplicação rigorosa de políticas de segurança. Uma vez
estabelecidos estes padrões, pode-se iniciar a migração e posteriormente a homologação de
sistemas empresariais maduros em um ambiente de nuvem privada, de forma a avaliar e
convencionar os níveis ideais necessários de capacidade computacional.
2.6 - CARACTERÍSTICAS
Serão examinadas agora algumas características que fazem da nuvem um
ambiente atrativo.
2.6.1 - INDEPENDÊNCIA DE DISPOSITIVO E LOCAL: Permite que usuários
acessem sistemas utilizando um navegador web, independentemente de sua localização e
dispositivo utilizado, tais como PCs, celulares, Thinclients23, etc. Sua infra-estrutura é off-
site24 (normalmente fornecida por terceiros) e acessada pela internet, tornando possível o
acesso a partir de qualquer lugar do mundo.
23 Thinclient: É um computador cliente de uma rede modelo cliente-servidor, que possui poucos ou nenhum aplicativo instalados, de forma a depender de um servidor central para o processamento de dados.
24 Off-site: Tomando lugar ou localizado longe do local original, com a finalidade de realizar uma determinada atividade. Ex: Uma estação de tratamento de resíduos. <http://www.answers.com/topic/off-site> Acessado em 05 de abril de 2009.
27
A ilustração 5 mostra um dispositivo para utilização de pilhas web, que
podem ser sistemas operacionais completos.
2.6.2 - MULTI-LOCAÇÃO: Possibilita o compartilhamento de recursos e distribuição de
custos entre um grande grupo de usuários, tornando possível:
● Centralização da infra-estrutura em áreas de baixo custo;
● Aumento da capacidade de gerenciamento de picos;
● Melhor aproveitamento e eficiência de sistemas ociosos;
● Aumento da Confiabilidade através do uso de múltiplos sites
redundantes (continuidade do negócio e recuperação de desastres);
● Aumento da Escalabilidade através de fornecimento sob-demanda, em
tempo real, de recursos computacionais;
● Aumento da Segurança devido à tratamento cauteloso dos dados;
● Aumento da Sustentabilidade, pois com a melhor utilização de recursos,
Ilustração 5: CherryPal C114. Autor: Green Corporation.
28
menor é a energia consumida com operação e resfriamento de máquinas, diminuindo assim
a emissão de carbono.
2.7 - MITIGAÇÃO DE RISCOS
Apesar da evolução da tecnologia de computação em nuvem, é possível que
com o advento da crise financeira global iniciada no ano de 2008, empresas fiquem
receosas em adotá-la. É provável que a questão da segurança neste tipo de ambiente seja
um dos principais motivos causadores de preocupações quando se pensa em adotar a
plataforma, pois a grande maioria dos administradores de rede estão acostumados a
estarem próximos a seus ambientes.
Uma outra questão a ser considerada é a disponibilidade dos dados. É
recomendável que antes de se contratar uma infra-estrutura de nuvem seja feita uma
análise cautelosa na Política de Segurança do provedor do serviço.
A empresa Gartner25, que possui foco em consultoria e análise tecnológica,
exemplifica alguns itens que devem ser discutidos em detalhes com o fornecedor da
solução, e quais as informações devem ser solicitadas. Esta lista pode ser visualizada
abaixo.
1. Acesso Privilegiado por Usuário: Questionar sobre quem possuirá
acesso especializado aos dados, e também sobre a contratação e gerência de tais
administradores;
25 Gartner: Seven cloud-computing security risks <http://www.infoworld.com/d/security-central/gartner-seven-cloud-computing-security-risks-853> Acessado em 05 de abril de 2009.
29
2. Conformidade da Concessão: Certificar-se de que o fornecedor está
disposto a se submeter à auditorias externas e certificações de segurança;
3. Locação de Dados: Consultar se o provedor permite algum nível de
controle sobre a locação dos dados;
4. Segregação de Dados: Certificar-se de que existe uso de criptografia em
todos os estágios da migração e também da operação, e que os esquemas criptográficos
tenham sido desenhados e testados por profissionais experientes;
5. Recuperação: Saber em quanto tempo dados extraviados por uma
situação de desastre podem ser recuperados, e também se será possível realizar uma
restauração completa do ambiente;
6. Suporte Investigativo: Questionar se o fornecedor dispõe de
profissionais qualificados para investigar a ocorrência de possíveis atividades impróprias
ou ilegais;
7. Termo de Longa Viabilidade: Deixar claro o que acontecerá com os
dados caso a companhia abandone o negócio, e também como estes serão devolvidos e em
qual formato.
Como se pode perceber pelos itens acima, é de extrema importância levar
em consideração a segurança do ambiente, pois este novo conceito de computação em
nuvem pode causar a impressão de que esta plataforma é uma solução definitiva para
30
alguns dos problemas de infra-estrutura enfrentados atualmente. Assim, vale ressaltar que
deve existir uma grande preocupação com as decisões e ações que devem ser executadas
em caso de desastre. Devido ao disposto, é recomendável que além dos itens sugeridos
faça-se uso de tecnologias que garantam a consistência e a disponibilidade dos dados das
empresas. Algumas destas tecnologias podem ser vistas no Capítulo 4.
31
CAPÍTULO 3
3 - VIRTUALIZAÇÃO
Embora as tecnologias fundamentais da computação em nuvem como
escalabilidade horizontal e computação distribuída já estejam disponíveis há algum tempo,
a Virtualização (abstração de recursos computacionais) é a Pedra Angular26 da tecnologia
para todas as arquiteturas de nuvem. Com a capacidade para virtualizar computadores,
dispositivos de armazenamento, desktops e aplicações através de um sistema operacional
abstraído por um hypervisor27, um amplo vetor de recursos de TI pode ser alocado sob-
demanda.
26 A Pedra Angular: Salmo 118:22 – A pedra angular que os construtores rejeitaram, veio a ser posta como principal pedra.
27 Hypervisor: Permite que um computador rode múltiplos sistemas operacionais simultaneamente. <http://www.vmware.com/interfaces/paravirtualization.html> Acessado em 06 de abril de 2009.
32
A ilustração 6 exemplifica como computadores são virtualizados. Uma
camada de virtualização é adicionada entre o hardware e o sistema operacional, e permite
que múltiplos sistemas operacionais executem concorrentemente como máquinas virtuais,
em um único computador, compartilhando e particionando dinamicamente os recursos
físicos (processador, memória, rede e armazenamento).
O crescimento nos últimos anos da disponibilidade ubíqua de redes de
banda larga a custos acessíveis é igualmente crítico. O que outrora estava disponível
apenas a uma pequena porcentagem de usuários de internet, agora é oferecido à maior
parte do mundo. A banda larga permite que massivos recursos de computação e dados
sejam acessados através de um browser. Recursos virtualizados podem estar em qualquer
lugar na nuvem, podendo ser acessados remotamente por programadores ou usuários
finais.
Adicionalmente, através de tecnologias capacitantes, a computação em
nuvem pode remeter a capacidades de TI em uma escala absolutamente sem precedentes.
Alguns exemplos destas tecnologias são:
Ilustração 6: Virtualização – Autor: Vmware.
33
● Sistemas de Arquivo sofisticados, a exemplo do ZFS28 da Sun
Microsystems, que pode suportar uma capacidade virtualmente ilimitada de
armazenamento, garantir a integridade e gerência de dados, e até gerar clones de discos que
estejam em operação.
● Padrões de Arquitetura, que permitem o desenvolvimento acelerado
de estruturas de nuvem super-escalares, através do fornecimento de soluções redundantes
para problemas comuns.
● Novas Técnicas, voltadas a gerência de dados estruturados, não-
estruturados e semi-estruturados, podem fornecer uma melhoria radical no processamento
intensivo de dados.
● Imagens de Máquinas (snapshots), podem ser instantaneamente
mobilizadas, simplificando e acelerando dramaticamente a alocação de recursos,
aumentando assim a agilidade e responsividade de operações de TI.
28 ZFS: The Solaris ZFS offers a dramatic advance in data management with an innovative approach to data integrity, tremendous performance improvements, and a welcome integration of file system and volume management capabilities. <http://www.sun.com/software/solaris/zfs_learning_center.jsp> Acessado em 05 de abril de 2009.
Ilustração 7: Recursos físicos migrados para Nuvem – Autor: Gene Smith
34
A ilustração 7 simboliza a migração de arquiteturas físicas para arquiteturas
de nuvem. Nesta imagem, são usados como recursos para implementação da nuvem
servidores blade e storages.
Virtualização é a pedra angular em concepção técnica para todas as
arquiteturas de nuvem. Na computação em nuvem, refere-se primariamente a virtualização
de plataforma ou abstração de recursos físicos de TI, das pessoas e aplicações que os usam.
Ela permite que servidores, dispositivos de armazenamento, e outros hardwares sejam
tratados como um grupo de recursos ao invés de sistemas discretos, fazendo com que estes
recursos possam ser alocados sob-demanda. Na computação em nuvem, existe o interesse
em técnicas como paravirtualization, que permite que um único servidor seja tratado como
múltiplos servidores virtuais, e clustering, que permite que múltiplos servidores sejam
tratados como um único servidor.
Como um meio de encapsulamento de recursos físicos, a virtualização
resolve vários dos desafios do núcleo de gerentes de data-centers, e traz ainda algumas
vantagens específicas, incluindo:
● Altas taxas de utilização: Anteriormente a virtualização, estimava-se
que a taxa média de utilização da maioria das máquinas e dispositivos de armazenamento
em data-centers empresariais era inferior a 50% da capacidade disponível, e que taxas
entre 10% e 15% eram comuns. A ilustração 8 exemplifica esta estatística. Através da
virtualização, cargas podem ser encapsuladas e transferidas para sistemas ociosos ou
subutilizados – o que significa que sistemas já existentes podem ser consolidados, e que a
compra de hardware adicional pode ser adiada ou evitada.
35
● Consolidação de recursos: A virtualização permite consolidar
múltiplos recursos de TI. Além da consolidação de servidores e armazenamento, ela provê
uma oportunidade para consolidar a arquitetura dos sistemas, a infra-estrutura de
aplicações, bancos de dados, interfaces, redes, estações de trabalho, e até processos do
negócio, resultando em diminuição de custos e aumento de eficiência.
Ilustração 8: Caso real de consolidação de servidores: Baixo consumo de CPU justifica virtualização. Autor: Azul Seguros
Baixo consumo de CPU e RAM, mesmo com 5 máquinas abstraídas
Melhor Aproveitamento de Recursos
36
● Menor consumo de energia: O custo da eletricidade necessária para
implementar data-centers empresariais está ascendendo. Estima-se (Sun Microsystems,
2009) que para cada dólar gasto em hardware para computadores servidores de aplicações,
um dólar adicional é gasto em energia (incluindo o custo para rodar e resfriar máquinas).
Usar a virtualização para consolidar serviços torna possível diminuir o consumo total de
energia, e conseqüentemente o de capital.
● Economia de espaço físico: O aumento da quantidade de computadores
servidores continua sendo um problema sério na maioria dos data-centers, e a expansão
deste último nem sempre é uma opção disponível, pois os custos de construção são sempre
muito elevados. A virtualização pode aliviar esta tensão, pois permite consolidar muitos
sistemas virtuais em poucos sistemas físicos.
● Recuperação de desastres: A virtualização pode aumentar as taxas de
disponibilidade de serviços em todas as áreas, fornecendo novas opções em soluções de
recuperação de desastres, garantindo assim a continuidade do negócio.
● Custos reduzidos de operação: Acredita-se que existe uma proporção
de 8 para 1, em termos de despesas com manutenção e aquisição de nova infra-estrutura,
respectivamente. A virtualização pode mudar a racionalização máquinas/administrador,
reduzindo o total de carga administrativa necessária, diminuindo assim custos
operacionais.
A ilustração 8 mostra a janela de administração básica de um sistema
VMWare Server (VMWare, 2009), que é um dos produtos de virtualização disponíveis no
37
mercado. Como se pode perceber, os hosts consolidados (virtualizados), bem como o
computador em que ocorre a virtualização, consomem muito pouco processamento, dando
a visão clara de como recursos podem ser melhor aproveitados através do uso desta
técnica.
3.1 - VIRTUALIZAÇÃO DE SISTEMAS OPERACIONAIS
O uso de Níveis de Virtualização ou Particionamento de Recursos29 (IBM,
2008) em arquiteturas de nuvem pode ajudar a resolver alguns dos problemas de
segurança, privacidade e questões regulatórias existentes na mesma, e que atrasam sua
adoção.
3.2 - VIRTUALIZAÇÃO DE PLATAFORMA
Permite que sistemas operacionais distintos (Linux, Windows, Solaris, etc.) e
suas respectivas aplicações executem em um determinado sistema. Existem dois modelos
básicos:
● Virtualização Completa – Total simulação de hardware: Um
29 Particionamento de Recursos: Subconjunto de recursos de hardware, virtualizados como computadores independentes, onde uma máquina física pode ser particionada em múltiplas máquinas lógicas.
38
computador completo, com seus respectivos componentes (disco, rede, memória, vídeo,
etc.) é emulado através da implementação de Hypervisors Tipo 2, que executam no topo de
um sistema operacional tradicional;
● Paravirtualização – Oferece um modelo “similar” do hardware
subjacente, compartilhando recursos físicos do mesmo, através da implementação de
Hypervisors Tipo 1, que executam diretamente no hardware.
Existem vantagens e desvantagens em cada um dos modelos de
virtualização de plataforma. Normalmente, quanto mais abstraído do hardware subjacente
é o sistema operacional, menos características específicas podem ser acessadas. O aumento
da abstração também pode aumentar a probabilidade de ocorrerem limitações e reduções
na performance. Por outro lado, como se pode observar na ilustração 9, quanto menos
abstraído é o sistema operacional, mais características específicas podem ser acessadas, e
menor é a probabilidade de ocorrerem limitações e reduções de performance. No entanto,
podem ocorrer potenciais problemas de compatibilidade.
39
3.3 - VIRTUALIZAÇÃO DE REDE
Técnicas de Balanceamento de Carga são um constante em computação de
nuvem, pois a medida que se escalam os sistemas físicos e virtuais, igualmente escala-se a
complexidade de gerenciar os picos de carga que são gerados na distribuição dos serviços.
Balanceadores de carga agrupam múltiplos computadores e serviços atrás de
um endereço IP virtual. Eles realizam a distribuição dos recursos de acordo com as
requisições aos serviços, e fornecem resistência automática a falhas quando estas ocorrem
em um dos nós da arquitetura. Enquanto balanceadores baseados em hardware superam em
performance os balanceadores baseados em software, sua flexibilidade é sempre limitada.
Engenheiros terminaram por fim escrevendo softwares que interagem com o hardware
Ilustração 9: Relação entre Funcionalidade e Abstração. Autor: Sam Johnstone
40
através de interfaces sub-otimizadas, ou ainda através do uso de um grande número de
computadores para resolver o problema em questão.
Um desafio significativo em redes de computação em nuvem não é apenas o
fornecimento de uma interface individual e virtual de rede para um dado ambiente, mas
também a necessidade crescente de infra-estruturas de nuvem que ofereçam data-centers
privados mais complexos, e que provisionem um conjunto de diferentes papéis com
interconexões lógicas entre si.
3.4 - VIRTUALIZAÇÃO DE APLICAÇÕES
Existe também a figura dos containers30 dentro da nuvem. A tecnologia de
container web implementada na nuvem impacta diretamente na produtividade e
flexibilidade do desenvolvedor. O container web é a parte da aplicação servidora que
gerencia Servlets31, arquivos JSP32, e outros componentes de 3 camadas (web-tier).
Atualmente, a maior parte dos ofertantes de computação em nuvem
concentram-se em virtualização de plataforma, e o desenvolvedor escolhe qual sistema
operacional será utilizado como plataforma de desenvolvimento. No entanto, com o
aumento da quantidade de nuvens públicas, provavelmente nuvens privadas irão oferecer
30 Container: Elemento de software que implementa múltiplos recursos, aumentando a flexibilidade de desenvolvimento de aplicações. <http://java.sun.com/webservices/containers/index.html> Acessado em 05 de abril de 2009.
31 Servlet: Mecanismo simples e consistente para expandir as funcionalidades de um servidor web. <http://java.sun.com/products/servlet/index.jsp> Acessado em 05 de abril de 2009.
32 JSP (JavaServer Page): Fornece um meio rápido e simples de criar conteúdo web dinâmico <http://java.sun.com/products/jsp/> Acessado em 05 de abril de 2009.
41
abstrações de ambientes de programação de nível mais elevado. Espera-se que com o
passar do tempo, o nível de abstração das interfaces para desenvolvedores avance, ao passo
que novas funcionalidades agreguem-se à plataforma.
Off-Topic: A ilustração 10 refere-se a uma idéia curiosa sobre virtualização,
que foi utilizada no cinema. No filme The Matrix (1999), seres humanos eram
virtualizados.
Ilustração 10: Imagem retirada do filme The Matrix. Autores: Andy Wachowski e Larry Wachowski
42
CAPÍTULO 4
4 - IMPLEMENTANDO UM AMBIENTE DE NUVEM
Padrões abertos são críticos para o crescimento da computação em nuvem, e
softwares livres fornecem a fundação para muitas implementações desta tecnologia.
Este trabalho não se destina a ser um manual de instalação de sistemas
operacionais. Por isso, serão cobertos aqui apenas os pontos relevantes de configuração
destes. No entanto, a instalação e configuração das aplicações será apresentada de forma
mais detalhada, pois estão diretamente ligadas a materialização do ambiente.
Todos os softwares e sistemas utilizados neste trabalho são de código aberto
ou livres de licenças, não constituindo seu uso infração de distribuição não autorizada ou
violação de copyright. Os scripts apresentados foram desenvolvidos pelo autor, e podem
ser utilizados e alterados livremente, desde que sejam mantidos os créditos originais. Será
apresentada a seguir uma breve descrição das aplicações e ferramentas utilizadas nesta
implementação.
43
4.1 - SISTEMAS UTILIZADOS
● OpenSolaris: Versão open source do sistema Solaris, utilizado
tipicamente em grandes empresas. Possui alta tolerância a cargas e falhas, além de grande
performance, e conta com recursos nativos de virtualização e alta disponibilidade. (Sun
Microsystens, 2009)
● Slackware: Distribuição Linux rápida e estável, que apesar do uso ser
relativamente fácil, é adotada por administradores mais experientes. (Volkerding, 2009)
● Debian: Distribuição Linux de fácil administração, que conta com
milhares de softwares disponíveis em sua base. (Debian GNU/Linux, 2009)
● ViCompress: É um proxy de cache para o protocolo HTTP, que possui
suporte a compressão de dados. Open source e extremamente flexível, é utilizado para
reduzir o consumo de banda e aumentar os tempos de resposta em aplicações que rodam no
protocolo HTTP. Possui a habilidade para compactar páginas de texto, fazendo com que a
quantidade de dados a ser transferida seja reduzida, minimizando assim o consumo do link
de dados, possibilitando desta forma transferências mais rápidas. (ViSolve, 2009)
● Apache: Servidor web (HTTP/HTTPS) open source de grande robustez.
O objetivo de seus desenvolvedores é fornecer um servidor seguro, eficiente e expansível,
que esteja em conformidade com o padrão HTTP. É o servidor web mais popular da
Internet desde Abril de 1996. (The Apache Software Foundation, 2009)
44
● OpenSSL: Conjunto de ferramentas open source, robustas e completas
em funcionalidades, que fornecem uma forte biblioteca criptográfica voltada a
implementar as criptografias SSL (Secure Sockets Layer) v2/v3 e TLS (Transport Layer
Security) v1, o que possibilita realizar comunicações seguras. (OpenSSL Project, 2009)
● PHP: Linguagem de programação amplamente utilizada, voltada ao
desenvolvimento de aplicações web. A figura 11 exemplifica o crescimento da adoção da
linguagem PHP (Hypertext Preprocessor) nos últimos anos. (PHP, 2009)
● Netfilter (IpTables): Firewall nativo em sistemas Linux capaz de operar
nos modos stateless packet filtering e statefull packet filtering. É capaz ainda de realizar
tradução de endereços de rede (NAT) e outras funções avançadas, como filtragem por
strings, que podem ser lidas de dentro de cabeçalhos. (Netfilter, 2009)
● Net-SNMP: Conjunto de aplicações open source, que implementam os
protocolos SNMPv1, SNMPv2c e SNMPv3, utilizados na gerência de sistemas e ambientes
de rede. (Net-SNMP, 2009)
Ilustração 11: Adoção da linguagem PHP nos últimos anos. Autor: PHP
45
● DjbDNS: Servidor DNS rápido e seguro, que segundo seu
desenvolvedor, é imune aos tipos de ataque desferidos contra servidores convencionais.
Existe uma recompensa em dinheiro para o primeiro que descobrir uma falha de segurança
neste software. (D.J.Bernstein, 2009)
● Nagios: Ferramenta bem conhecida para gerência de redes. Possibilita a
monitoria de serviços, máquinas e ativos de rede. As informações obtidas podem ser
utilizadas em planejamento pró-ativo, identificação e resolução rápida de problemas. Pode
ser customizada de forma a atender qualquer tipo de monitoramento. (Nagios, 2009)
● Cacti: Ferramenta de fácil uso complementar ao Nagios. Gera e
armazena gráficos de monitoramento, que são administrados através de uma interface
intuitiva. Muito robusto, é capaz de monitorar redes com centenas de ativos. (Cacti, 2009)
● Centreon: Ferramenta que roda sob a plataforma Nagios. Através de sua
interface, facilita a configuração e consolida o uso deste sistema. (Centreon, 2009)
● MySQL: Banco de Dados open source muito popular devido a sua
consistência, desempenho, confiabilidade e fácil operação. (MySQL, 2009)
● EyeOS: Aplicação que simula um sistema operacional através de
tecnologias web. (EyeOS, 2009)
● OpenOffice: Suíte open source completa de escritório. Seu
desenvolvimento já alcançou um grau de maturidade que o torna comparável às suítes
46
comerciais. (OpenOffice, 2009)
● Scripts: Desenvolvidos para facilitar a instalação, aumentar a segurança,
suportar a integração, a gerência e a manutenção da arquitetura apresentada.
4.2 - DIAGRAMA DE REDE
Para a implementação prática deste trabalho, propõe-se o diagrama de rede
exibido na ilustração 12.
Ilustração 12: Diagrama de rede proposto para realização do trabalho.
47
1) Cloud Server: Principal fornecedor de serviços deste projeto. Foi
escolhida a plataforma OpenSolaris para seu desenvolvimento, devido ser uma plataforma
estável, robusta e de grande performance, além de possuir ferramentas nativas para
virtualização e expansão dinâmica de recursos. Como algumas das preocupações são a
escalabilidade e a disponibilidade do ambiente, a plataforma em questão apresentou-se
como melhor alternativa.
2) Banco de Dados: Foi utilizada a aplicação MySQL como servidor de
banco de dados, devido a sua grande popularidade, consistência, performance, fácil
operação e manutenção.
3) Gerência: Através das aplicações Nagios, Cacti e Centreon, realiza o
monitoramento ostensivo do ambiente, bem como a coleta de informações úteis, como
consumo de processamento, disco e banda de rede. O monitoramento permite saber o
estado dos hosts (se os mesmos estão online e com tempo de resposta adequado), e dos
serviços (se os mesmos estão “rodando” e respondendo de forma otimizada). A coleta das
informações citadas permite que seja realizado um planejamento pró-ativo de crescimento
da arquitetura, bem como identificar onde e quando falhas ocorrerem, através de avisos e
alarmes configurados com base em thresholds33, afim de diminuir o downtime34 e agilizar a
resolução de problemas.
33 Valores mínimos “toleráveis”, que representam o estado normal de um determinado sistema. A excedência destes valores significa que um sistema está operando fora de suas especificações, e que uma ação corretiva deve ser empregada, afim de restabelecer o estado normal do mesmo, evitando dificuldade ou instabilidade no acesso ao recurso.
34 Quantidade de tempo que um determinado host ou serviço permanece indisponível.
48
4) Backup Server: Serviço responsável por realizar e manter cópias de
segurança de informações sensíveis, como dados de usuários, configurações de sistemas e
informações armazenadas em banco de dados. A implementação deste serviço permite que
sejam recuperadas em pouco tempo informações necessárias a reconstrução parcial ou total
de ambientes, bem como dados que eventualmente possam ser extraviados pelos usuários.
5) Firewall + Proxy Reverso + VPN: Fornece a segurança fundamental
do ambiente, bem como evita o processamento redundante de informações, além de
garantir um meio seguro para administração dos sistemas. A segurança é implementada
através da utilização do Netfilter (IpTables), que através da criação de regras de acesso,
permite a comunicação entrante oriunda de ambiente externo apenas para as aplicações
disponibilizadas publicamente. O proxy reverso, como encontra-se antes do Cloud Server,
intercepta as requisições HTTP e HTTPS, evitando que este tenha que processar e
responder novamente a uma solicitação que já tenha sido realizada e armazenada em cache
anteriormente, como o acesso a uma determinada página ou imagem. Este serviço aumenta
a confiabilidade do ambiente, pois faz com que o cloud server processe apenas requisições
“úteis”, diminuindo assim o desperdício de ciclos de CPU. A VPN fornece um nível a mais
de segurança, pois disponibiliza um canal seguro (criptografado) para que os
administradores realizem intervenções mais avançadas. Ela permite que os sistemas sejam
acessados e configurados remotamente, apenas por pessoal autorizado.
6) DNS Server: Serviço que associa endereços IP a FQDN (full qualified
domain name), que são nomes de domínio qualificados, como por exemplo,
“univercidade.br”. É fundamental para que os serviços possam ser acessados através da
internet e da intranet. Foi escolhida a aplicação DjbDNS, pois possui excepcional
49
desempenho e segurança. Segundo seu desenvolvedor, é imune aos ataques conhecidos,
como por exemplo, envenenamento de cache de zonas. Ainda segundo seu desenvolvedor,
devido a arquitetura modular da aplicação, onde 3 programas realizam tarefas específicas
(diferentemente de outras aplicações monolíticas, onde apenas uma aplicação realiza todo
o trabalho), um simples computador 486 é capaz de gerenciar mais de 500 domínios, com
um desempenho satisfatório. A confiança de seu mantenedor em seu trabalho é tão grande
que há uma recompensa em dinheiro para quem apontar falhas de segurança na aplicação.
Nota: De acordo com a ilustração 12, o ambiente proposto apresenta o uso
de um Roteador, VLANs e máquinas independentes, responsáveis pelos servidores. A idéia
inicial era utilizar um roteador virtual, emulado com a aplicação Dynamips (Christophe
Fillot, 2009), através da interface GNS3 (Jeremy Grossmann e Xavier Alt, 2009). No
entanto, devido ao baixo desempenho e limitações deste emulador, o mesmo não pôde ser
utilizado, pois comprometeria a qualidade do projeto. Outras limitações foram a
disponibilidade de ativos de rede (switch gerenciável, para criação de VLANs),
capacidade de processamento e quantidade de memória (para execução de máquinas
virtuais). Devido a isso, foi necessário o acúmulo de funções, se fazendo necessário
executar mais de um servidor por máquina virtual, onde o ideal seria que cada máquina
ficasse responsável por apenas um servidor. Porém, a qualidade do resultado final não
ficou comprometida com esta prática.
50
4.3 – INSTALAÇÃO DOS SISTEMAS
As informações apresentadas a seguir não compreendem a única forma
possível para a materialização do ambiente proposto. Elas expressam apenas o ponto de
vista do autor, e foram elaboradas levando-se em consideração os limites dos recursos
disponíveis durante a realização do projeto. Devido a estas limitações, será implementada
apenas a parte que se acredita ser a mais nobre. Isto significa que os serviços de VPN e
Backup não serão implementados, além de que alguns processos tenham que ser
acumulados em um mesmo host, conforme descrito na tabela a seguir:
NR FUNÇÃO NOME DE HOST SERVIÇOS1 firewall alfa Firewall, Proxy Reverso e DNS2 cloudserver beta Serviços e Aplicações Web3 gerencia gama Nagios, Cacti e Banco de Dados
Apesar do disposto, foram observadas boas práticas de segurança e
configuração das aplicações envolvidas. Os nomes de host praticados foram escolhidos
com base em orientação do professor Paulo Mendonça (Segurança de Redes) em sala de
aula, de que deve-se evitar utilizar nomes cognitivos para máquinas importantes em um
ambiente de rede.
Por convenção, serão adotadas as seguintes nomenclaturas para os
segmentos de rede utilizados:
DMZ: Área onde serão fornecidos serviços publicamente.
LAN: Área de tráfego interno apenas.
51
4.3.1 - FIREWALL + PROXY REVERSO + DNS: Sistemas de firewall são fundamentais
para a segurança de ambientes de rede, pois previnem o acesso não autorizado a estas ou a
serviços específicos, através da criação de perímetros de segurança (Paulo Mendonça,
2009). Este trabalho aborda a implementação de um Firewall Statefull, pois como está
sendo levada em consideração a segurança do ambiente, acredita-se que este modelo seja o
mais adequado. Também será feito uso de um proxy reverso, que ficará localizado antes do
servidor web, e funcionará realizando cache de páginas e arquivos acessados com maior
freqüência, evitando desta forma que o servidor web desperdice recursos com tarefas
redundantes, realizando na maior parte do tempo operações mais relevantes. O serviço
DNS, por ser sensível, foi escolhido com cautela, pois está sendo buscada nesta
implementação a maior performance e segurança possível. Todos estes ficarão alocados em
uma mesma máquina, que no tocante a hardware, propõe-se que possua 3 interfaces de
rede, para que se possam acomodar todos os segmentos da mesma. Deverá ainda, possuir
um disco de 20Gb e 256Mb de memória RAM. Para sistema operacional, será utilizado o
Slackware 12.2, sem ambiente gráfico, levando-se em consideração os seguintes detalhes:
● Particionamento de Disco: Do total disponível, 25% deverão ser
alocados para a partição root (“/”), 25% para a partição usr, 10% para a partição swap e o
restante para a partição var. O filesystem utilizado deverá ser o EXT4, devido sua
consistência e desempenho, proporcionados por técnicas como Alocação Tardia, Marcas
Temporais de maior resolução (nanosegundos) e verificações melhores de integridade.
(Mathur, 2007)
● Configurações de Rede: O nome de host deverá ser “alfa”. Será
utilizado um domínio fictício para todas as máquinas deste trabalho, denominado
52
“forenaite.net”. A interface de rede identificada por “eth0” será responsável pela
comunicação do segmento DMZ, que representa a área onde serão disponibilizados
serviços publicamente através da internet, e deverá possuir o endereço IP 10.0.0.1/28. A
interface de rede identificada por “eth1” será responsável pela comunicação do segmento
LAN, onde serão realizadas as comunicações internas, como gerência do ambiente, acesso
a banco de dados e gravação de backups (este último não implementado neste trabalho). O
endereço IP deverá ser 172.16.1.1/26. A interface de rede identificada por “eth2” será
responsável pela comunicação com a rede externa (internet). Deverá possuir endereço de
rede 10.128.0.11/24, pois é um endereço IP pertencente ao mesmo segmento de rede do
link de dados utilizado durante o desenvolvimento deste trabalho. Seu gateway deverá ser
10.128.0.10, pois neste trabalho é quem fornecerá acesso à internet. Finalizando a
configuração básica de rede, existe a figura do servidor DNS, que será o próprio firewall,
pois conforme explicado no início deste capítulo, algumas funções serão acumuladas. O
endereço utilizado será 127.0.0.1, tendo em vista que os processos de firewall e DNS
estarão executando no mesmo host.
Observação: A instalação padrão do sistema Slackware não fornece opção
para configurar todas as interfaces de rede. De fato, permite que seja configurada apenas
uma interface no ato da instalação. Para configurar as demais interfaces, será necessário
editar o arquivo “/etc/rc.d/rc.inet1.conf”, adicionando ao mesmo as configurações
pendentes, conforme exibido na ilustração 13.
53
Para validar as alterações, basta reiniciar o serviço de rede, através da
execução do comando “/etc/rc.d/rc.inet1 restart”.
4.3.1.1 - Configurações de Segurança: Conforme dito no capítulo 4.3.1, para a
implementação da solução proposta será utilizado um Firewall Statefull, através da
utilização da aplicação IPTables. Para isso, deverá ser criado em “/etc/rc.d/rc.firewall” um
script, que realizará a configuração desta aplicação. Este script deverá possuir o seguinte
conteúdo:
#!/bin/bash
# Fore FW. Andre Rocha, Maio de 2009
case "$1" instop)
# Limpa as regras do Firewall #iptables -Fiptables -t nat -Fiptables -X 2> /dev/nulliptables -t nat -X 2> /dev/null
;;
Ilustração 13: Adicionando as configurações pendentes
54
start)# Declara Interfaces #IF_DMZ=eth0IF_LAN=eth1# Interface que da acesso ao link intrenetIF_INET=eth2
# Declara Redes #LAN=172.16.1.0/26DMZ=10.0.0.0/28# Rede utilizada durante o desenvolvimento do trabalhoINET=10.128.0.0/24
# Ativa o forward de IPs #/bin/echo 1 > /proc/sys/net/ipv4/ip_forward
# Limpa as regras do Firewall #iptables -Fiptables -t nat -Fiptables -X 2> /dev/nulliptables -t nat -X 2> /dev/null
# Nega todos os acessos por padrao #iptables -P INPUT DROPiptables -P FORWARD DROP
# Evita Spoofingiptables -A FORWARD -i $IF_INET -s ! $INET -j DROPiptables -A FORWARD -i $IF_LAN -s ! $LAN -j DROPiptables -A FORWARD -i $IF_DMZ -s ! $DMZ -j DROPiptables -P OUTPUT ACCEPT
# Habilita o NATiptables -t nat -A POSTROUTING -o $IF_INET -j MASQUERADE
# Permite Loopbackiptables -A INPUT -i lo -j ACCEPTiptables -A FORWARD -i lo -j ACCEPT
# Habilita modo Statefulliptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPTiptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# Descarta pacotes invalidosiptables -A FORWARD -m state --state INVALID -j DROPiptables -A INPUT -m state --state INVALID -j DROP
# Libera IPs da Administracaoiptables -A FORWARD -s 10.128.0.4 -j ACCEPTiptables -A FORWARD -s 10.128.0.9 -j ACCEPT
# Permite Acesso ao Proxy Reverso #PortasTCP=" 80 443 "for A in $PortasTCPdo
iptables -A INPUT -i $IF_DMZ -p tcp --dport $A -j ACCEPTiptables -A INPUT -i $IF_LAN -p tcp --dport $A -j ACCEPTiptables -A INPUT -i $IF_INET -p tcp --dport $A -j ACCEPT
done
55
# Permite acesso ao DNSiptables -A INPUT -i $IF_LAN -p udp --dport 53 -j ACCEPTiptables -A INPUT -i $IF_DMZ -p udp --dport 53 -j ACCEPTiptables -A INPUT -i $IF_INET -p udp --dport 53 -j ACCEPT
# Permite SSH - Nao deve ser liberado em caso de producaoiptables -A INPUT -i $IF_LAN -p tcp --dport 22 -j ACCEPTiptables -A INPUT -i $IF_DMZ -p tcp --dport 22 -j ACCEPT
# Permite Ping #iptables -A INPUT -i $IF_DMZ -p icmp -j ACCEPTiptables -A INPUT -i $IF_LAN -p icmp -j ACCEPTiptables -A INPUT -i $IF_INET -p icmp -j ACCEPTiptables -A FORWARD -i $IF_DMZ -p icmp -j ACCEPT
# Permite SNMP #iptables -A INPUT -i $IF_LAN -p udp --dport 161 -j ACCEPT
# Permite acesso aos/dos servidores da LAN #ServerLAN=" 1 2 3 "for I in $ServerLANdoiptables -A FORWARD -i $IF_LAN -p tcp -d 172.16.1.$I -j ACCEPTiptables -A FORWARD -i $IF_LAN -p udp -d 172.16.1.$I -j ACCEPTiptables -A FORWARD -i $IF_LAN -p tcp -s 172.16.1.$I -j ACCEPTiptables -A FORWARD -i $IF_LAN -p udp -s 172.16.1.$I -j ACCEPTiptables -A FORWARD -i $IF_DMZ -p tcp -d 10.0.0.$I -j ACCEPTiptables -A FORWARD -i $IF_DMZ -p udp -d 10.0.0.$I -j ACCEPTiptables -A FORWARD -i $IF_DMZ -p tcp -s 10.0.0.$I -j ACCEPTiptables -A FORWARD -i $IF_DMZ -p udp -s 10.0.0.$I -j ACCEPTiptables -A FORWARD -i $IF_DMZ -p tcp -o $IF_INET -j ACCEPTiptables -A FORWARD -i $IF_DMZ -p udp -o $IF_INET -j ACCEPTiptables -A FORWARD -i $IF_INET -p tcp -o $IF_DMZ -j ACCEPTiptables -A FORWARD -i $IF_INET -p udp -o $IF_DMZ -j ACCEPTdone
# Bloqueia NETBIOS NetBIOS=" 137 138 139 "for L in $NetBIOSdo
iptables -A FORWARD -i $IF_LAN -p tcp --dport $L -j DROPiptables -A FORWARD -i $IF_LAN -p udp --dport $L -j DROPiptables -A FORWARD -i $IF_DMZ -p tcp --dport $L -j DROPiptables -A FORWARD -i $IF_DMZ -p udp --dport $L -j DROPiptables -A FORWARD -i $IF_INET -p tcp --dport $L -j DROPiptables -A FORWARD -i $IF_INET -p udp --dport $L -j DROP
done
# Habilita Logs #Logs=" 0 1 2 "for G in $Logsdo
iptables -A INPUT -i eth$G -j LOG --log-prefix "InputDeny_eth$G-Log "
iptables -A INPUT -i eth$G -j DROPiptables -A FORWARD -i eth$G -j LOG --log-prefix
"ForwardDeny_eth$G-Log "iptables -A FORWARD -i eth$G -j DROP
done;;
56
restart)$0 stop$0 start
;;
*)echo "Uso: /etc/rc.d/rc.firewall {start|stop|restart}"exit 1
;;esac
exit 0
Para que o script possa ser executado, deverá ser atribuída a permissão
correspondente, levando em consideração que apenas o usuário administrador do sistema
identificado por “root”, possa manipulá-lo. Para obter este nível de privilégio, basta
executar o comando “chmod 700 /etc/rc.d/rc.firewall”.
4.3.1.2 - Configurações do Serviço DNS: Conforme dito no Capítulo 4, o serviço DNS
utilizado neste trabalho é o DjbDNS, pois acredita-se que suas características são as mais
apropriadas ao objetivo desta implementação, por englobarem segurança, baixo consumo
de recursos e alta performance. Não é possível afirmar que sua instalação seja complexa,
mas certamente demanda uma grande quantidade de trabalho, pois possui dependências
(softwares que são pré-requisitos). Para facilitar o entendimento, é preciso que alguns
detalhes sejam elucidados. O primeiro deles é o fato deste software ser modular, ou seja,
possui processos separados que são responsáveis por funções específicas. Estes processos
serão descritos a seguir.
● DNSCache: É apenas um “resolvedor” recursivo, criado com a
finalidade única de encontrar endereços IP para os hosts solicitados, através de queries
(perguntas) UDP e TCP para servidores autoritativos (servidores que possuem autoridade
57
sobre domínios), conforme necessidade. Ele utiliza uma técnica de restrições a respeito do
que será retornado como resposta, para evitar ataques relacionados a este tipo de consulta,
como por exemplo, o envenenamento de cache, ou em sua forma original, DNS Cache
Poisoning (SecureWorks, 2007). Os servidores autoritativos são encontrados através de
uma cadeia de delegações, que começa pelos endereços dos servidores root (servidores
raiz) configurados internamente. Tudo isso faz parte do modelo de segurança empregado
nesta solução. Se o DNSCache não houvesse sido desenhado para funcionar desta forma,
estaria passivo aos mesmos tipos de ataque de envenenamento de cache sofridos pelos
servidores DNS atualmente não-seguros35, como por exemplo, o Bind (ISC, 2009).
● TinyDNS: Serve autoritativamente (possui autoridade sobre domínio)
nomes, exclusivamente por queries UDP. Por ser autoritativo, não serve nomes
recursivamente (responde a consultas sobre domínios sobre os quais não tem autoridade)
de forma direta, e tampouco responde a queries TCP. Este serviço recebe requisições de
hosts apenas por intermédio de outros servidores recursivos, como o DNSCache ou o Bind.
Devido a isso, seu endereço IP nunca deverá ser configurado em um sistema operacional
na área referente a “Servidores DNS” ou semelhante.
● AxfrDNS: Serve nomes autoritativamente, através de queries TCP
apenas, ao mesmo tempo em que é o servidor de transferência de zonas.
Existem dois motivos para se utilizar programas separados para cada
função. Um deles é limitar incursões de segurança, e o outro é devido ao fato de muitos
sites não necessitarem de transferência de zonas, evitando assim que um serviço
desnecessário esteja em execução. A exemplo do Bind, que é um software monolítico (um
35 Bind DNS Cache Poisoning <http://www.trusteer.com/bind9dns> Acessado em 17 de maio de 2009.
58
mesmo processo é responsável por várias funções), a agregação de funcionalidades
excessivas em um único módulo é o principal motivo para ocorrência de desastres na
segurança (RFC 2010, RFC 2870).
Com o intuito de diminuir a complexidade envolvida na instalação deste
sistema, todas as aplicações necessárias foram agrupadas em um único arquivo, e foi
desenvolvido um script que automaticamente o obtém e resolve as dependências,
instalando posteriormente o DjbDNS. Este script deve ser executado com privilégios de
administrador, e seu código será apresentado a seguir.
#!/bin/bash
# Fore DjbDNS Installer. Andre Rocha, Maio de 2009
# Realiza o download dos softwares necessários, inclusive dependênciascd /usr/srcwget http://www.auroradigital.com.br/djbdns.tar.gztar zxvf djbdns.tar.gz
# Instalacao do UCSPI-TCP, que e a primeira dependenciatar zxvf ucspi-tcp-0.88.tar.gzcd ucspi-tcp-0.88patch < ../ucspi-tcp_errnopatchmake && make setup check
# Instalacao do DAEMONS TOOLS, que e a segunda dependenciamkdir -p /package ; chmod 1755 /packagecd /packagetar xzvf /usr/src/daemontools-0.76.tar.gzcd /package/admin/daemontools-0.76/srcpatch < /usr/src/daemontools_errnopatchcd ..package/install
# Instala o TinyDNScd /usr/srctar zxvf djbdns-1.05.tar.gzcd djbdns-1.05patch < ../djbdns_errnopatchmake && make setup check
# Cria as contas de usuário necessáriasuseradd -s /dev/null -d /dev/null dnscacheuseradd -s /dev/null -d /dev/null dnsloguseradd -s /dev/null -d /dev/null tinydns
59
Após realizada a instalação, deve-se proceder com a configuração do
sistema. O comando “dnscache-conf dnscache dnslog /etc/dnscache 172.16.1.1” configura
o módulo DNSCache, que após ativado, passará a responder às solicitações que chegarem
pela interface do segmento LAN. O endereço IP 172.16.1.1 nunca deverá ser cadastrado
nos registros de NS (Name Servers). Deve ser configurado apenas nos sistemas
operacionais, na área referente a “Servidores DNS” ou “Nameserver”, pois sua função é
apenas resolver nomes. O comando “ln -s /etc/dnscache /service” habilita o DNSCache.
Por padrão, este software não responde a nenhuma rede que não for explicitamente
autorizada. Para informar as redes que estão autorizadas a utilizar o cache, basta executar
os comandos “touch /etc/dnscache/root/ip/10.0.0”, que libera a rede DMZ, “touch
/etc/dnscache/root/ip/172.16.1”, que libera a rede LAN, e em seguida “touch /etc/dnscache/
root/ip/127”, que libera o acesso via loopback.
O módulo TinyDNS é o próximo a ser configurado. Primeiramente, deve-se
cadastrar o endereço IP do servidor autoritativo (que possuirá autoridade sobre o domínio).
Isso pode ser feito através do comando “tinydns-conf tinydns dnslog /etc/tinydns 10.0.0.1”.
O comando “ln -s /etc/tinydns /service” habilita o serviço TinyDNS.
A próxima ação a ser executada é informar ao TinyDNS o domínio sobre o
qual ele terá autoridade. Isso pode ser feito através do comando “cd
/service/tinydns/root ; ./add-ns forenaite.net 10.0.0.1 ; ./add-ns 0.0.10.in-addr.arpa
10.0.0.1 ; make”. Este comando, além de realizar o informado, também cadastra o
“reverso” (função que resolve um endereço IP para um nome de servidor) dos IPs deste
domínio. Agora basta adicionar o mesmo a lista de servidores “root”, com o comando “cd /
etc/dnscache/root/servers ; echo 10.0.0.1 > forenaite.net ; ln -s forenaite.net 0.0.10.in-
60
addr.arpa”. Feito isso, os nomes dos hosts onde serão executados serviços públicos podem
ser cadastrados, através do comando “cd /service/tinydns/root ; ./add-alias
ns1.forenaite.net 10.0.0.1 ; ./add-host beta.forenaite.net 10.0.0.2 ; ./add-host
gama.forenaite.net 10.0.0.3 ; ./add-alias www.forenaite.net 10.0.0.1 ; make”. Seguindo
recomendação do professor Paulo Mendonça (Segurança de Redes) em sala de aula, o
nome de host do firewall não será cadastrado no serviço DNS. Os hosts onde serão
executados os serviços internos podem ser cadastrados com o comando “cd
/service/tinydns/root ; ./add-host sol.forenaite.net 172.16.1.2 ; ./add-host mon.forenaite.net
172.16.1.3”.
Nota: Em um ambiente real de produção, é recomendável que seja utilizado
um serviço DNS a parte, de forma que atenda apenas a rede interna.
Para que todas as alterações entrem em vigor, basta reiniciar o serviço, com
o comando “svc -h /service/dnscache/”.
Isto conclui a configuração do servidor DNS.
4.3.1.3 - Configurações do Proxy Reverso: O último sistema a ser configurado para este
host é o proxy reverso. Para este serviço será utilizada a aplicação ViCompress, devido às
características apresentadas no capítulo 4. Acredita-se que sua instalação não seja
complexa, pois a documentação disponível no site do desenvolvedor36 é bastante clara. O
36 ViCompress HTTP Compression & Caching Proxy <http://www.visolve.com/vicompress/vicompress.html>Acessado em 17 de maio de 2009.
61
serviço de proxy reverso deve ser configurado de forma que intercepte as requisições
entrantes direcionadas ao protocolo HTTP, confrontando o resultado das solicitações com o
conteúdo de sua árvore de cache. Caso a resposta para a solicitação conste no cache do
proxy reverso, o mesmo se encarregará de a enviar diretamente ao solicitante, sem que esta
chegue ao servidor web. Esta prática visa aumentar a performance e o balanceamento de
processos do ambiente, fazendo com que as aplicações envolvidas funcionem de forma
otimizada e sem “gargalos”. Para agilizar o processo de instalação, foi criado o seguinte
script, que se destina a realizar automaticamente a instalação da aplicação ViCompress.
#!/bin/bash
# Fore ViCompress Installer. Andre Rocha, Maio de 2009
# Faz o download e descompacta a aplicacaocd /usr/srcwget http://www.visolve.com/vicompress/vicompress-1.0.9.tar.gztar xzf vicompress-1.0.9.tar.gz ; cd vicompress-1.0.9/src/
# Prepara o código fonte para ser instalado./configure /usr/vicompress
# Compila e instala o softwaremake && make install
Antes que a aplicação ViCompress possa ser inicializada, é necessário que a
mesma seja configurada. Os detalhes acerca deste processo podem ser vistos em sua
documentação oficial. O último passo é automatizar a inicialização deste software, para
que o mesmo execute automaticamente toda vez que o sistema operacional for inicializado.
Isto pode ser feito através do comando “ln -s /usr/vicompress/bin/vicompress.sh
/etc/rc.d/rc.vicompress”.
62
O acesso a este script deve ser controlado, de forma que somente o
administrador do sistema possa manipulá-lo. Isso pode ser feito através do comando
“chmod 500 /etc/rc.d/rc.vicompress”. Isto finaliza a configuração e também a instalação
deste host. Para fins acadêmicos, o arquivo de configuração do ViCompress pode ser
examinado na íntegra no Apêndice 1, pois mesmo o manual da aplicação citar os pontos
relevantes do processo, acredita-se que há espaço para interpretações variadas.
A ilustração 14 exemplifica o benefício da utilização de um proxy reverso.
Como se pode perceber, houve uma significativa economia no link de dados, o que agiliza
processos e diminui custos.
4.3.2 - CLOUD SERVER: Da parte de hardware, a máquina utilizada deverá possuir 2
interfaces de rede, com a finalidade de acomodar os segmentos DMZ e LAN. Deverá
possuir ainda um disco de 30Gb, e 1Gb de memória RAM. O sistema operacional utilizado
será o OpenSolaris, e deverão ser levados em consideração os seguintes detalhes:
Ilustração 14: Economia de banda com uso de proxy reversoAutor: ViSolve
sem cachee sem
compressão
com cachee compressão
63
● Particionamento de Disco: Do total disponível, 25% deverão ser
alocados para a partição root (“/”), 25% para a partição var, 10% para swap e o restante
para a partição home, pois tipicamente é onde ficam armazenados os dados dos usuários. O
filesystem deverá ser o ZFS28, devido sua consistência, capacidades nativas de backup,
clonagem, self-healing37, escalabilidade e fácil administração; além de possibilitar o uso de
conteiners38. Mais informações sobre a instalação do OpenSolaris podem ser obtidas na
documentação oficial39.
● Configurações de Rede: O nome de host deverá ser “beta”. O nome de
domínio será “forenaite.net”. A Interface de rede identificada por “e1000g0” será
responsável pela comunicação com o segmento DMZ, e deverá possuir o endereço IP
10.0.0.2/28. A interface de rede identificada por “e1000g1” será responsável pela
comunicação com o segmento LAN, e deverá possuir endereço de rede 172.16.1.2/26.
Como o servidor DNS utilizado será o firewall, o sistema deverá ser configurado de forma
que as requisições DNS apontem para o endereço IP 172.16.1.1. Desta forma, as consultas
de nomes realizadas pelas máquinas da rede interna utilizarão como meio físico o
segmento de rede LAN. Esta prática melhora a performance da rede, pois serão utilizados
meios apartados para comunicação, de acordo com o público atendido. Ou seja, as
comunicações pertinentes à DMZ ocorrerão por um meio físico, e as comunicações
pertinentes à LAN ocorrerão por outro.
37 Self-healing: Capacidade autônoma de recuperação após uma falha.
38 Solaris Conteiners: Tecnologia que permite virtualização de forma nativa em sistemas Solaris <http://www.sun.com/software/solaris/virtualization.jsp> Acessado em 06 de maio de 2009.
39 OpenSolaris Documentation: <http://www.opensolaris.org/os/documentation/> Acessado em 06 de maio de 2009.
64
Como as configurações de rede em ambientes Solaris são tipicamente mais
complexas, as mesmas serão cobertas em detalhes. Serão descritos a seguir, os passos
necessários a obtenção de uma configuração correta para o ambiente proposto.
A primeira ação que deve ser realizada é o cadastramento das subnets que o
sistema faz parte. Este processo requer que as mesmas sejam declaradas no arquivo
“/etc/inet/netmasks”. No caso deste trabalho, este arquivo possuirá conteúdo semelhante ao
apresentado na ilustração 15.
O próximo passo é realizar a configuração de nome de host, pois caso este
não esteja configurado, não será possível atribuir corretamente os endereços IP para as
interfaces de rede. Para isso, basta substituir o conteúdo do arquivo “/etc/nodename” pelo
texto “beta”. Para habilitar a interface de rede que faz parte do segmento DMZ do
ambiente, deve-se criar o arquivo “/etc/hostname.e1000g0” com o conteúdo “beta_dmz”.
Para a interface de rede que faz parte do segmento LAN, o processo é semelhante, bastando
criar o arquivo “/etc/hostname.e1000g1” com o conteúdo “beta_lan”. A atribuição de
endereços IP a estas interfaces deverá ser feita através da manipulação do arquivo
“/etc/hosts”, que deve possuir conteúdo semelhante ao apresentado na ilustração 16.
Ilustração 15: Cadastro de Subnets
65
A próxima ação necessária ao processo de configuração de rede constitui em
informar o sistema sobre o servidor DNS a ser utilizado. Para isso, basta criar o arquivo
“/etc/resolv.conf”, com o conteúdo “nameserver 172.16.1.1”. Para que o sistema passe a
utilizar este servidor, deve-se manipular o arquivo “/etc/nsswitch.conf”, onde a linha que
possui o conteúdo “hosts: files” deve ser alterada para “hosts: files dns”.
Para finalizar a configuração de rede, basta definir qual será a rota padrão.
Para isso, basta inserir no arquivo “/etc/defaultrouter” o conteúdo “10.0.0.1”. A tabela de
rotas do sistema pode ser visualizada através do comando “netstat -rn”. Todas as alterações
realizadas somente entrarão em vigor após o reboot do sistema.
4.3.2.1 – Instalação dos Softwares Necessários: Através do gerenciador de pacotes,
deverão ser adicionadas as seguintes aplicações: PHP, Apache Web Server, Expect, System
Management Agent, OpenOffice e OpenOffice-pt-BR. Estas aplicações possuem
dependências (dependem de outros pacotes para funcionarem). Devido a isso,
automaticamente serão instalados outros aplicativos, além dos que foram selecionados.
Um item fundamental para a segurança desta implementação é o uso de
criptografia de dados. Comunicações criptografadas são mais seguras, pois mesmo que o
tráfego seja interceptado, não será possível decodificar os dados capturados, garantindo
Ilustração 16: Atribuição de endereços IP
66
assim a privacidade dos usuários do sistema. Como os serviços serão fornecidos via web, é
necessário que seja habilitado o protocolo HTTPS, que implementa o uso de criptografia
SSL sobre o protocolo HTTP. A configuração deste protocolo em servidores web baseados
em Apache é trivial, pois todas as informações necessárias estão presentes no manual do
produto40. No entanto, é necessária a utilização de uma chave privada para criptografia.
Esta chave deve possuir uma senha secreta, que precisa ser inserida todas as vezes que o
serviço HTTPS for iniciado. Esta interatividade conflita com a proposta deste trabalho,
pois sistemas de nuvem devem possuir características que o tornem o mais automático
possível. Uma prática que pode resolver esta questão é a criação de uma chave privada que
não possua senha cadastrada. Porém, esta não é uma prática aceitável, pois caso a chave
privada seja roubada, o ladrão poderá utilizar a mesma livremente, pois não haverá uma
senha para controlar seu uso legítimo. Desta forma, o infrator poderá assumir facilmente a
identidade do proprietário, e poderá aplicar golpes virtuais, como por exemplo, enviar
mensagens assinadas digitalmente passando-se por outra pessoa. Para resolver esta
questão, será utilizado um simples script criado em linguagem Expect41. Esta linguagem é
capaz de realizar a captura de mensagens específicas de um terminal, como por exemplo,
uma solicitação de senha, permitindo que sejam criadas respostas para as mesmas,
automatizando assim o processo. Este script pode ser armazenado em
“/etc/scripts/startssl”, e seu nível de acesso deve ser controlado, de forma que apenas o
administrador do sistema tenha acesso, pois possuirá informações sensíveis. A definição do
privilégio pode ser feita com o comando “chmod 500 /etc/scripts/startssl”. Será
apresentado a seguir o código do script que foi desenvolvido para a automatização do
processo de inicialização do servidor web com uso de criptografia.
40 Apache SSL/TLS Encryption <http://httpd.apache.org/docs/2.2/ssl/> Acessado em 17 de maio de 2009.
41 Expect é uma ferramenta para automatizar aplicações interativas, como Telnet e FTP. (Charles Hymes, 2009)
67
#!/usr/bin/expect
# Fore ApacheSSL Auto Start. Andre Rocha, Maio de 2009
# Nao exibe no terminal a informacao que sera inseridaset force_conservative 1
set timeout -1
# Software que sera iniciado e que solicitara os dadosspawn /usr/apache2/2.2/bin/apachectl -f /etc/apache2/2.2/httpd.conf -k start
match_max 100000
# Espera exibicao de uma determinada string, e envia a respostaexpect "Enter pass phrase:"send -- "univercidade\r"expect eof
● Nota: Tipicamente, uma autoridade certificadora deve assinar o
certificado digital gerado, para que o mesmo tenha sua autenticidade reconhecida. Sem um
certificado assinado, um servidor web utilizando criptografa SSL não funcionará. Por isso,
foi preciso assinar localmente o certificado. Certificados assinados localmente não são
menos seguros que certificados assinados por uma autoridade certificadora. A diferença, é
que a assinatura deste último já vem cadastrada nos sistemas operacionais atuais, e a
assinatura do anterior, como foi criada localmente, não. Devido a isso, quando o servidor
web referenciado neste trabalho for acessado através do protocolo HTTPS, será exibida
uma mensagem referente ao certificado utilizado não ser reconhecido. Isto não representa
nenhum tipo de risco para o sistema ou para o utilizador. Um exemplo da mensagem
exibida pode ser visto na ilustração 17.
68
A comprovação da eficácia do uso de criptografia pode ser demonstrada
através do uso da ferramenta Wireshark42, que possui a capacidade de analisar em detalhes
o tráfego de uma rede. A ilustração 18 exibe a captura de um tráfego não criptografado.
Como se pode perceber na ilustração 18, dados trafegam em texto claro, o
que torna possível que terceiros tenham acesso a informações pessoais.
42 Wireshark: Go Deep <http://www.wireshark.org/> Acessado em 24 de maio de 2009.
Ilustração 17: Certificado digital assinado localmente
Nome da autoridade
que assinou o certificado
Ilustração 18: Captura de tráfego não criptografado
Dadostrafegando
em texto claro
69
A ilustração 19 exibe a captura de um tráfego criptografado. Nesta imagem
percebe-se claramente que não é possível visualizar nenhum tipo de informação pessoal.
Para finalizar a configuração do servidor web, é necessário fazer com que o
mesmo inicie automaticamente quando o sistema operacional for iniciado. Para isso, será
criado outro script, que se encarregará de iniciar este serviço juntamente com o uso de
criptografa, sem que para isso seja necessário inserir manualmente a senha da chave
privada gerada. Este script deve ser armazenado em “/etc/rc3.d/S01apache”, e é necessário
que seja atribuída permissão de execução para o mesmo, de forma que somente o
administrador do sistema possa manipulá-lo. Isto pode ser feito com o comando “chmod
500 /etc/rc3.d/S01apache”. Seu código será mostrado a seguir.
Ilustração 19: Captura de tráfego criptografado
70
#!/bin/bash
export PATH=/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/apache2/2.2/binexport LD_LIBRARY_PATH=/lib:/usr/apache2/2.2/lib:/usr/apache2/2.2/libexec
case $1 in
'start') /etc/scripts/startssl ;;
'stop') /usr/apache2/2.2/bin/apachectl stop ;;
'restart') /usr/apache2/2.2/bin/apachectl stop sleep 2 /etc/scripts/startssl ;;
*) echo "Uso: $0 start|stop|restart" exit 1 ;;esac
Uma vez finalizada a configuração do servidor web, será iniciado o processo
de instalação do sistema EyeOS, que será responsável por fornecer serviço de desktop em
nuvem. A instalação deste sistema é muito simples, e não será coberta em detalhes, pois
existe farta documentação acerca deste tópico no site do desenvolvedor43. O mesmo se
aplica a integração do OpenOffice ao ambiente EyeOS. Um desktop de nuvem possui
funções similares a um desktop tradicional, proporcionando assim um uso intuitivo. A
ilustração 20 exibe um desktop EyeOS. Como se pode perceber, as semelhanças são claras.
43 EyeOS Quick Install Instructions <http://wiki.eyeos.org/Quick_Install_Instructions> Acessado em 17 de maio de 2009)
71
4.3.3 - GERÊNCIA: De um modo geral, a gerência de redes de computadores é de
fundamental importância para a manutenção do ambiente e conseqüente continuidade do
negócio. Possuir aplicações de gerência bem dimensionadas e bem configuradas, além de
permitir monitoramento ostensivo, auxilia na tomada de decisões, possibilitando que
atitudes pró-ativas sejam tomadas e problemas sejam resolvidos em um menor espaço de
tempo ou até mesmo sejam evitados. Também permite identificar pontos específicos de
“gargalo”, o que torna possível realizar uma reorganização do ambiente, evitando assim
que novos equipamentos tenham que ser adquiridos ou tenham que passar por um processo
de upgrade, diminuindo desta forma o desperdício de capital, que pode ser empregado de
forma mais eficiente. Com base neste pensamento, optou-se por montar um ambiente de
Ilustração 20: Desktop de Nuvem com sistema EyeOS
72
gerência, que além de possibilitar tudo o que foi citado, servirá de ferramenta para
comprovar a validade e eficácia de se possuir um ambiente baseado em tecnologia de
nuvem, como por exemplo, a implementação prática deste trabalho.
Para materializar a figura do gerente, será necessário utilizar um
computador a parte, que deve possuir configuração de hardware semelhante a apresentada
a seguir. Da parte de hardware, a máquina deve possuir 2 interfaces de rede, além de um
disco de 30Gb, e 256Mb de memória RAM. O sistema operacional utilizado será o Debian
5.01. Para o preparo da máquina, deverão ser levados em consideração os seguintes
detalhes:
● Particionamento de Disco: Do total disponível, 35% deverão ser
alocados para a partição root (“/”), 55% para a partição var, 3% para swap e o restante para
a partição log. Nesta última, ficarão armazenados os logs das aplicações, pois um sistema
de gerência tipicamente gera grandes quantidades de logs. O filesystem deverá ser o
EXT344, nativo em sistemas Linux, por questões de integridade e disponibilidade.
● Configurações de Rede: O nome de host deverá ser “gama”, e o nome
de domínio será “forenaite.net”. A Interface de rede que será responsável pela comunicação
com o segmento LAN deverá possuir endereço IP semelhante a 172.16.1.3/26, enquanto
que a interface de rede responsável pelo segmento DMZ deverá possuir endereço IP
semelhante a 10.0.0.3/28. O servidor DNS a ser utilizado possui IP 172.16.1.1, e o gateway
também ficará a cargo desta mesma máquina.
44 EXT3 <http://www.redhat.com/support/wpapers/redhat/ext3/> Acessado em 28 de maio de 2009.
73
Inicialmente, o ambiente de gerência foi desenvolvido e implementado em
plataforma Slackware. No entanto, as operações de automatização e a complexidade dos
scripts criados para esta plataforma adicionaram um certo grau de dificuldade à
manutenção do ambiente proposto. O autor acredita que gerar complexidade além do
necessário não é uma boa prática, e a medida adotada em favor da resolução desta questão
foi a alteração do sistema operacional original para a distribuição Debian, pois este possui
ferramentas que facilitam a instalação de aplicativos, minimizando assim a quantidade de
intervenções administrativas necessárias. Com esta alteração, o script criado para
automatizar a instalação e configuração dos sistemas de gerência teve uma redução
significativa em sua quantidade de linhas de código, o que diminui a complexidade de
manutenção.
Uma das aplicações utilizadas para realizar a gerência é o Centreon45, que
através da utilização da aplicação Nagios46, consolida o monitoramento ostensivo, além de
manter em banco de dados um histórico dos resultados do monitoramento. Não é possível
afirmar que sua instalação seja complexa, mas certamente demanda uma grande quantidade
de trabalho, pois possui várias dependências (softwares que são pré-requisitos) que
precisam ser resolvidas antes que se inicie o processo. Com a finalidade de simplificar as
operações envolvidas na instalação do Centreon, foi desenvolvido um script que
automaticamente resolve todas as dependências e realiza a instalação propriamente dita.
Vale ressaltar, que a utilização de scripts para automatizar tarefas é de
extrema importância, pois no caso de uma situação de desastre onde nem as cópias de
45 Centreon <www.centreon.com> Acessado em 19 de maio de 2009.
46 Nagios <www.nagios.org> Acessado em 19 de maio de 2009.
74
segurança estejam disponíveis, será possível restabelecer o estado original dos sistemas em
um curto espaço de tempo. Sem a adoção desta prática, é possível que incontáveis horas
técnicas sejam necessárias até que o ambiente retorne a seu estado original, o que
dependendo do caso pode multiplicar os prejuízos. O resultado deste desenvolvimento
pode ser conferido abaixo.
#!/bin/bash
# Fore Nagios & Centreon Installer. Andre Rocha, Maio de 2009# Escrito com funcoes para facilitar a manutencao# Algumas verificacoes nao inclusas para diminuir o tamanho do codigo# Compatibilidade: Debian 5.01 lenny
### CABECALHO ###
clear
if [ "$1" = "" ]then
printf "\nO que voce quer fazer? Preciso de uma opcao!\n"printf "\nUse: $0 [ all | centreon | nagios ]"printf "\nOnde 'all' realiza todas as operacoes,\ne as demais
realizam apenas o escolhido.\n\n"exit 1
fi
### FUNCOES ###
function resolv_depends(){printf "\nResolvendo as dependencias ...\n\n" ; sleep 3apt-get -y install sudo mailx lsb-release \build-essential apache2 apache2-mpm-prefork \php5 php5-mysql php-pear php5-ldap php5-snmp \php5-gd mysql-server-5.0 libmysqlclient15-dev \rrdtool librrds-perl libconfig-inifiles-perl elinks \libcrypt-des-perl libdigest-hmac-perl libdigest-sha1-perl \libgd-gd2-perl snmp snmpd libnet-snmp-perl libsnmp-perl \libgd2-xpm libgd2-xpm-dev libpng-dev libsdl-perl \eperl libperl-dev ssh tofrodos}
function account_create() {
printf "\nCriando as contas de sistema necessarias ...\n\n"sleep 5groupadd nagcmd ; groupadd nagiosuseradd -c Nagios -d /home/nagios -g nagios -G nagcmd -m -s
/bin/bash nagiosusermod -a -G nagcmd www-datausermod -G crontab nagios}
75
function nagios_install(){printf "\nInstalando o NAGIOS + NDOUTILS + CENTREON + MYSQL
...\n\n" ; sleep 5apt-get -y install ndoutils-nagios3-mysql}
function ndoutils_setup(){printf "\nConfigurando o NAGIOS para utilizar o NDOUTILS ...\n\n" ;
sleep 5htpasswd -c -b /etc/nagios3/htpasswd.users nagiosadmin univercidadegrep -v "broker_module" /etc/nagios3/nagios.cfg >
/tmp/nagios.cfg.tmpecho "broker_module=/usr/lib/ndoutils/ndomod-mysql-3x.o
config_file=/etc/nagios3/ndomod.cfg" >> /tmp/nagios.cfg.tmpcat /tmp/nagios.cfg.tmp > /etc/nagios3/nagios.cfgchown nagios:nagios /etc/nagios3/*echo "grant select,insert,update,delete on ndoutils.* to
ndoutils@'' identified by 'ndoutils';"|mysql -uroot -punivercidade}
function ndoutils_start(){printf "\nIniciando o NDOUTILS ...\n\n" ; sleep 5sed s/0/1/g /etc/default/ndoutils > /tmp/ndoutils.tmpcat /tmp/ndoutils.tmp > /etc/default/ndoutils/etc/init.d/ndoutils start}
function get_centreon(){echo -ne "\nFazendo o download do Centreon ...\n\n" ; sleep 2wget http://www.auroradigital.com.br/centreon-2.0.2.tar.gzif [ $? -ne 0 ]then
echo -ne "\nErro ao fazer o download do Centron!\n"echo -ne "\nGrave manualmente o arquivo de instalacao em
'/usr/local/src'"echo -ne "\ne execute '$0 centreon' para continuar a
instalacao.\n\n"exit 1
elseecho "Download realizado com sucesso!" ; sleep 2sleep 3
fi}
function install_centreon(){echo -ne "\nInstalando o Centreon ...\n\n" ; sleep 2cd /usr/local/srctar xzvf centreon-2.0.2.tar.gz ; cd centreon-2.0.2ln -f /usr/lib/ndoutils/ndomod-mysql-3x.o /usr/sbin/ndomod.o./install.sh -i -f /usr/local/src/centreon-
2.0.2/tmpl/vardistrib/debian-lennychown -R nagios:www-data /etc/nagios3}
76
### PROGRAMA PRINCIPAL ###
case $1 inall)
resolv_dependsaccount_createnagios_installndoutils_setupndoutils_startget_centreoninstall_centreon
;;
centreon)get_centreoninstall_centreon
;;
nagios)nagios_installndoutils_setupndoutils_start
;;esac
Nota: Durante o processo de desenvolvimento do ambiente de gerência foi
enfrentado um grave problema de desempenho em uma das principais aplicações que são
pré-requisitos. A proposta deste trabalho é obter um ambiente de alto desempenho, e para
isso, é necessário que todas as aplicações envolvidas funcionem da forma mais otimizada
possível. A aplicação em questão é o RRDTool, que é responsável pela tarefa de gerar os
gráficos de acordo com as instruções enviadas pelos softwares Centreon e Cacti. A versão
afetada foi a 1.3.8, lançada em 19 de maio de 2009. Apesar dos esforços empregados
(diversos parâmetros diferentes de compilação, e pesquisas no fórum oficial da aplicação),
não foi possível sanar o problema. A solução encontrada foi fazer downgrade (utilizar uma
versão mais antiga) para a versão 1.2.23 da aplicação. As ilustrações 21 e 22 representam o
problema enfrentado e a resolução do mesmo, respectivamente.
77
Na ilustração 21, a aplicação em questão aparece como processo que mais
consome recursos de processamento.
Na ilustração 22, a aplicação em questão não mais figura na lista dos
processos que mais consomem processamento.
Ilustração 21: Consumo excessivo de CPU pelo RRDTool 1.3.8
Ilustração 22: Downgrade para versão 1.2.23 do RRDToll: Dramática diminuição de processamento.
78
A configuração inicial do Centreon pode ser realizada sem maiores
dificuldades, tendo em vista sua interface ser bastante intuitiva. Esta interface pode ser
visualizada no endereço “http://mon.forenaite.net/centreon”. O primeiro acesso inicia
automaticamente o processo de configuração. Neste processo, apenas é necessário que
sejam informados nomes de usuário, senhas e nomes para os bancos de dados que serão
utilizados. Para este trabalho as informações adotadas foram:
● Centreon Database Name: centreon
● Centstore Database Name: centreon_ods
● Database password: centreon
Os próximos passos são realizar a configuração interna da ferramenta e
definir os monitoramentos. Isso deve ser feito de forma que todos os serviços de todos os
hosts sejam monitorados, inclusive os itens de hardware, como interfaces de rede,
processadores e discos. Os detalhes acerca deste processo não serão cobertos, pois a
própria ferramenta possui manual de configuração. O monitoramento contará com o
auxilio do protocolo SNMPv2c, por este ser mais estável (Sauer, 2009). Para isso, o
mesmo deverá estar instalado e em execução nos hosts monitorados. Apesar deste
protocolo e suas ferramentas associadas fazerem parte dos sistemas operacionais
modernos, ele deverá ser configurado para que funcione corretamente. Uma observação
importante é quanto ao uso da community padrão, que é denominada de “public”. Esta
community não deverá ser utilizada, devido a questões de segurança (Sauer, 2009). A
mesma deverá ser alterada para “supercloud”, ou outro nome diferente de “public”. Em
sistemas OpenSolaris, o SNMP pode ser configurado direto no arquivo
“/etc/sma/snmp/snmpd.conf”, através das seguintes mudanças:
79
● Alterar a linha que possui o texto “rocommunity public” para
“rocommunity supercloud”
● Alterar a linha que possui o texto “syslocation "System administrators
office"” para “syslocation "forenaite.net"”
● Alterar a linha que possui o texto “syscontact "System administrator"”
para “syscontact "[email protected]"”
Após a configuração, é necessário ativar o serviço através do comando
“svcadm enable sma”.
Em sistemas Slackware e Debian, a configuração do SNMP que atende a
esta implementação pode ser realizada através da substituição do conteúdo do arquivo
“/etc/snmp/snmpd.conf” pelo exibido a seguir:
com2sec local localhost supercloudcom2sec lan 172.16.1.0/255.255.255.192 supercloud
group fore v1 localgroup fore v2c localgroup fore usm localgroup fore v1 langroup fore v2c langroup fore usm lan
view all included .1 80
access fore "" any noauth exact all none noneaccess fore "" any noauth exact all all none
syslocation forenaite.netsyscontact [email protected]
disk / 10000load 5 10 15
80
Para monitorar servidores web baseados em Apache, basta incluir em seu
arquivo de configuração as diretivas abaixo:
ExtendedStatus On
<Location /server-status> SetHandler server-status Order deny,allow Deny from all Allow from .forenaite.net</Location>
<Location /server-info> SetHandler server-info Order deny,allow Deny from all Allow from .forenaite.net</Location>
A ilustração 23 exibe a interface de um sistema Centreon, monitorando
detalhes de um host do ambiente.
Ilustração 23: Monitoria via Centreon
81
Nota: A documentação oficial não deixa claro a configuração que possibilita
o acesso do Centreon à base de dados do Nagios. Com o objetivo de auxiliar na
implementação, será exibida na ilustração 24 o local e as informações corretas que devem
ser utilizadas para possibilitar o acesso da ferramenta à base citada.
Como se pode perceber, a ilustração 24 indica de forma numerada o “passo-
a-passo” a percorrer até alcançar os campos que devem ser preenchidos, bem como seus
valores corretos.
Vale ressaltar que a instalação do Centreon não inutiliza a ferramenta
Nagios, que permanece ativa e em funcionamento. O Centreon é apenas uma interface de
configuração que facilita seu uso.
Ilustração 24: Configurações de acesso do Centreon à base de dados do Nagios
OBSERVAR OS LOCAIS INDICADOS EM VERMELHO
1
2
3 4
5
82
Como recurso complementar a gerência, foi utilizada a ferramenta Cacti47,
que tem a capacidade de gerar vários tipos de gráficos que auxiliam no acompanhamento
do estado dos sistemas. Estes gráficos permitem, entre outras coisas, visualizar o consumo
de processamento, consumo do link de dados, consumo de disco, e quantidade de processos
ativos. Foi realizada a instalação e configuração tendo por base os procedimentos descritos
na página oficial da ferramenta48. Os aplicativos adicionais que foram instalados
anteriormente para satisfazer as dependências da ferramenta Centreon também são
utilizados para o Cacti, dispensando assim que novas dependências (softwares que são pré-
requisitos) tenham que ser resolvidas. A interface do Cacti pode ser acessada através do
endereço “http://mon.forenaite.net/cacti”.
Dica: O site Debian Help49 oferece diversos modelos para geração de
gráficos compatíveis com o Cacti.
A ilustração 25 exibe uma compilação de gráficos que podem ser gerados
pelo Cacti. As informações foram coletadas do host “beta” (CloudServer).
47 Cacti: Complete Network Graphing Solution <http://www.cacti.net/> Acessado em 23 de maio de 2009.
48 Installing Under Linux <http://www.cacti.net/downloads/docs/html/install_unix.html> Acessado em 23 de maio de 2009.
49 Debian Help <http://www.debianhelp.co.uk/cactitemplates.htm> Acessado em 23 de maio de 2009.
83
Um aspecto interessante a ser analisado estando de posse de uma ferramenta
de gerência é o comparativo entre um sistema tradicional, como por exemplo, um
notebook, e um sistema de nuvem, como por exemplo o ambiente implementado neste
trabalho. As ilustrações 26 e 27 exibem o comparativo entre as arquiteturas de nuvem e
tradicional, respectivamente, através de gráficos gerados durante uma sessão de 4 (quatro)
horas de uso contínuo de cada estrutura individualmente.
Ilustração 25: Gráficos de consumo de recursos gerados pelo Cacti
84
Como se pode perceber na ilustração 26, o sistema que mais consome
processamento é o CloudServer, que teve um pico máximo de 1,6% de consumo de CPU
com 90 processos em execução. Os demais sistemas, Firewall e Gerência, alcançaram
juntos a marca de 150 processos, e no entanto não chegaram a consumir 1% de CPU.
Na ilustração 27, pode ser observado que um único sistema, no momento
em que atingiu pico máximo de 46 processos em execução, chegou a consumir 70% de
CPU. Como se pode perceber, um sistema tradicional realiza uma carga maior de trabalho,
Ilustração 26: Sistemas que compõe o Ambiente de Nuvem
Ilustração 27: Sistema Tradicional
85
pois precisa processar sozinho todos os trâmites necessários a atender as requisições dos
usuários. Sob este aspecto, um sistema de nuvem leva vantagem, pois seus processos estão
distribuídos por áreas de competência, sendo tratados em computadores diferentes. O
trabalho em conjunto faz com que toda a arquitetura funcione de forma otimizada, pois sua
carga está distribuída, o que aumenta a confiabilidade do ambiente.
Uma outra abordagem pode ser analisada através da interface do hypervisor
utilizado para o desenvolvimento deste trabalho (VMWare ESX50). Nesta interface, vê-se o
consumo exato de processamento de cada máquina virtual utilizada. A ilustração 28
exemplifica este consumo.
Analisando a ilustração 28, fica claro o baixo consumo de recursos
computacionais necessários para a execução do ambiente proposto.
50 VMWare ESX: Produto comercial da empresa VMWare, fornecedora de soluções para virtualização de ambientes.
Ilustração 28: Consumo Individual de processamento de cada máquina virtual.
86
4.4 – CONSIDERAÇÕES SOBRE A CONTRIBUIÇÃO DO TRABALHO
Este trabalho foi objetivamente destinado a buscar resultados de obtenção de
competências nas seguintes áreas:
● Contribuição para a preservação de recursos naturais, essenciais para a
vida humana;
● Contribuição para o aumento da disponibilidade dos recursos
computacionais, cada vez mais essenciais para qualquer elemento da sociedade;
● Contribuição para a redução do risco para a empresa cujas vocações não
são diretamente da área de prestação de serviços de TI;
● Contribuição na implementação de procedimentos automatizados que
possibilitam resolução de falhas dos sistemas em execução, dispensando a ação reativa do
suporte;
● Contribuição com o gerenciamento otimizado, possibilitando a utilização
de ferramentas proativas centralizadas;
● Contribuição por conta do uso preferencial de ferramentas livres e
gratuitas, reduzindo o custo com software e serviços;
● Contribuição no desenvolvimento de scripts de tarefas que consumiriam
horas de trabalho em comparação com casos de resolução ad-hoc, onde as soluções são
desenvolvidas caso-a-caso.
87
A luz destes objetivos pode-se entender que:
● A preservação de recursos naturais é obtida através da implementação de
soluções baseadas na virtualização;
● O aumento da disponibilidade será obtido através da implementação do
conceito da nuvem, onde os recursos são transparentes ao usuário e as contingências são
acionadas de forma que o usuário sequer perceba seu acionamento;
● A concentração de esforços nas empresas é obtida através da
transferência de responsabilidades para outra empresa, cujo esforço de serviços é focado
em disponibilidade de serviços, e não de competências específicas;
● O uso de scripts especiais para a implementação de serviços é eficaz
para a automatização da implementação de procedimentos vários, descritos detalhadamente
no capitulo 4. Adicionalmente, em caso de desastres, os scripts possibilitam o
restabelecimento do estado original dos sistemas em curto espaço de tempo;
● As ferramentas de gerência e de segurança adotadas e adicionadas à
nuvem conferem ao administrador um conjunto de informações que permitem uma postura
proativa no combate às falhas e as ameaças; e
● O uso exclusivo de soluções livres e gratuitas faz com que a
implementação seja de baixíssimo custo e retorno garantido.
Os resultados obtidos permitem afirmar que os objetivos definidos no início
do trabalho em termos de contribuição na área de Redes de Computadores foram
alcançados.
88
CAPÍTULO 5
5 - CONCLUSÃO
Conforme apresentado neste trabalho, a computação em nuvem se propõe a
prover recursos computacionais como um serviço, e com isso, a habilidade para escalar
dinamicamente o mesmo, de forma simples e transparente, através do uso de computadores
e armazenamento adicionais. O segredo está nas tecnologias já existentes, que unidas,
tornam a nuvem uma realidade. Como destaque, uma das mais importantes idéias por trás
da computação em nuvem é a escalabilidade, e a tecnologia chave que torna isso possível é
a virtualização. Esta última permite melhor uso de um servidor, possibilitando agregar
múltiplos sistemas operacionais e aplicações em um único computador compartilhado.
Também permite migração online, o que significa que se um computador ficar
sobrecarregado, uma instância de um sistema operacional (e suas aplicações) podem ser
migradas para um novo computador menos atarefado. De uma forma simplista,
computação em nuvem é a migração de computação e armazenamento que existem dentro
de uma empresa para o exterior da mesma, em um ambiente de nuvem, onde se pode
89
definir necessidade de recursos (como computação e quantidade de banda), e agregá-los
virtualmente no interior da infra-estrutura de um provedor de nuvem.
Apesar das preocupações, um ambiente de nuvem se propõe a oferecer
segurança tão boa quanto ou melhor que um ambiente local, pois em nuvem tornam-se
mandatórios o uso de técnicas como criptografia de arquivos e de comunicação, o que
impede que terceiros, mesmo que tenham acesso aos arquivos físicos e fluxos de dados,
possam decifrá-los. Além disso, existem os logs de acesso, possibilitando que se realizem
auditorias quando forem necessárias. Com a centralização dos dados, há o aumento de
recursos focados em segurança, pois provedores devotam esforços para solucionar
problemas que muitos consumidores não podem arcar.
A implementação realizada para vivenciar aspectos peculiares da
computação em nuvem permitiu agregar a visualização da utilização dos recursos de forma
otimizada e eficiente.
Através da monitoria e análise dos gráficos, foi possível perceber o melhor
aproveitamento e balanceamento de recursos de um ambiente de nuvem, em comparação
com um sistema tradicional centralizado. Também foi possível perceber a importância do
uso da criptografia, quando foi realizada a captura de tráfego criptografado e não
criptografado. Ficou clara também a importância do desenvolvimento de scripts que
suportam a solução adotada, pois além de automatizarem tarefas (o que facilita na
recuperação de uma situação de desastre), auxilia na automatização do funcionamento
normal do ambiente, visão clara para o uso de criptografa SSL em servidor web, que em
sua forma original, necessita que toda vez que o mesmo for iniciado, o administrador do
sistema esteja presente para que seja inserida a senha secreta da chave de criptografia
utilizada. Foi possível ainda comprovar a eficácia do uso de um proxy reverso, que provê
uma economia considerável no consumo do link de dados. Outro detalhe importante é
90
inerente ao baixo requisito de hardware, pois ficou claro que máquinas com poucos
recursos, desde que distribuídas adequadamente, podem rodar de forma satisfatória um
ambiente de nuvem. Concluindo, apesar das dificuldades técnicas enfrentadas para
implementar e manter um ambiente de nuvem, o uso desta tecnologia é compensadora,
pois possibilita a exploração de novas formas de operação, novos horizontes e também
novos planos de negócio, trazendo assim benefícios reais a seus utilizadores.
Como trabalhos futuros, pode-se propor a extensão deste trabalho das
seguintes formas:
● Distribuição do ambiente proposto em cluster;
● Realizar a implementação de todo o ambiente proposto em um
hypervisor que suporte alocação dinâmica de ciclos de CPU e quantidade de memória
compartilhada, a exemplo do VMware ESX, evidenciando a distribuição dinâmica de
recursos;
● Realizar a implementação de todo o ambiente proposto em plataforma
OpenSolaris, utilizando os recursos Conteiner e Zones, evidenciando suas características
funcionais;
● Expandir as funcionalidades do cloud-desktop, agregando mais
aplicações na “pilha” destinada à usuários tradicionais;
● Criar “pilhas” para finalidades específicas, de forma a disponibilizá-las
sob demanda, com a finalidade de “levantar” em pouquíssimo tempo um ambiente de
trabalho;
● Através da implementação do protocolo PXE e do preparo de uma
imagem para boot via rede (remoto) que contenha apenas um ambiente gráfico e um
browser, criar terminais “burros” (thinclients23), para acesso aos cloud-desktops.
91
● Pesquisar empresas brasileiras que já estejam utilizando tecnologias de
nuvem, e quais foram os benefícios obtidos com a mudança.
● Pesquisar a associação da tecnologia de nuvem com o chamado TI
Verde, apontando similaridades e benefícios.
● Etc.
92
APÊNDICE 1 – ARQUIVO DE CONFIGURAÇÃO DO VICOMPRESS
# Vicompress configuration file
webserver 10.0.0.2 80webserver 10.0.0.2 443hostheader sol.forenaite.netlisten 0.0.0.0 80listen 0.0.0.0 443outgoingip 0.0.0.0enable_sessions yesenable_compression yesenable_caching yescache_memory 200max_cacheditem_size 512cache_expires 240enable_dns_caching yesdns_expires 48user nobodyrotatesize 100logformat squidenable_debug noaccesslog /usr/vicompress/log/accesslogerrorlog /usr/vicompress/log/errorlogerrorpage /usr/vicompress/etc/errorpage.htmllogstats /usr/vicompress/logstats
93
REFERÊNCIAS BIBLIOGRÁFICAS
Base de Conhecimento da Sun Microsystems<http://sunsolve.sun.com> Acessado em 11 de março de 2009.
Laboratório de Tecnologia de Nuvem da IBM Corporation<http://www.ibm.com/ibm/cloud/labs/> Acessado em 10 de março de 2009.
VMWare Server<http://www.vmware.com/products/server/> Acessado em 04/04/2009.
VMWare White Papers<http://www.vmware.com/solutions/whitepapers/virtualization.html> Acessado em 04/04/2009.
10 Obstacles to Cloud Computing by UC Berkeley, written by Michael Sheehan<http://blog.gogrid.com/2009/02/19/10-obstacles-to-cloud-computing-by-uc-berkeley-how-gogrid-hurdles-them/> Acessado em 05 de abril de 2009.
Cloud Computing Trends<http://cloudtrends.blogspot.com/> Acessado em 05 de abril de 2009.
Cherrypal<http://www.cherrypal.com/> Acessado em 05 de abril de 2009.
Cloud Computing: The Next Great Buzzword?<http://www.ignitesocialmedia.com/blog/gene/> Acessado em 05 de abril de 2009.
What is the Cloud?<http://vinf.net/2009/01/08/what-is-the-cloud/> Acessado em 05 de abril de 2009.
Patrick J. Volkerding<http://www.slackware.com> Acessado em 03 de maio de 2009.
Open Solaris<http://www.opensolaris.org/os/> Acessado em 03 de maio de 2009.
Solaris<http://www.sun.com/software/solaris/10/index.jsp> Acessado em 03 de maio de 2009.
ViSolve ViCompress<http://www.visolve.com/vicompress/index.php> Acessado em 03 de maio de 2009.
The Apache Software Foundation<http://www.apache.org/> Acessado em 03 de maio de 2009.
OpenSSL<http://www.openssl.org/> Acessado em 03 de maio de 2009.
94
PHP<http://www.php.net/> Acessado em 03 de maio de 2009.
Netfilter Iptables<http://www.netfilter.org/> Acessado em 03 de maio de 2009.
Net-SNMP<http://www.net-snmp.org/> Acessado em 03 de maio de 2009.
D.J.Bernstein DjbDNS<http://cr.yp.to/djbdns.html> Acessado em 03 de maio de 2009.
Nagios<http://www.nagios.org/> Acessado em 03 de maio de 2009.
Cacti<http://www.cacti.net/> Acessado em 03 de maio de 2009.
Centreon<http://www.centreon.com/> Acessado em 03 de maio de 2009.
MySQL<http://www.mysql.com/> Acessado em 03 de maio de 2009.
EyeOS<http://eyeos.org/> Acessado em 03 de maio de 2009.
OpenOffice<http://www.openoffice.org/> Acessado em 03 de maio de 2009.
Jeremy Grossmann e Xavier Alt - GNS3<http://www.gns3.net/> Acessado em 03 de maio de 2009.
Christophe Fillot - Dynamips<http://www.ipflow.utc.fr/index.php/Cisco_7200_Simulator> Acessado em 03 de maio de 2009.
IBM Grid Literature<http://www-03.ibm.com/linux/grid/resources/> Acessado em 04 de maio de 2009.
IBM Systems Journal<http://www.research.ibm.com/journal/sj43-1.html> Acessado em 04 de maio de 2009.
IBM Research – Autonomic Computing<http://www.research.ibm.com/autonomic/> Acessado em 05 de maio de 2009.
Johnm Willis Blog<http://www.johnmwillis.com/cloud-computing/cloud-vendors-a-to-z-revised/> Acessado em 05 de maio de 2009.
95
Dion Hinchcliffe Blog<http://blogs.zdnet.com/Hinchcliffe/> Acessado em 05 de maio de 2009.
IBM Logical Partitioning<https://www-01.ibm.com/servers/resourcelink/lib03030.nsf/pagesByDocid/477FB265C41837818525737C007DD123?OpenDocument&pathID=1> Acessado em 10 de maio de 2009.
Mathur - EXT4 Filesystem<https://ols2006.108.redhat.com/2007/Reprints/mathur-Reprint.pdf> Acessado em 16 de maio de 2009.
EXT4<http://kernelnewbies.org/Ext4#head-97cbed179e6bcc48e47e645e06b95205ea832a68> Acessado em 16 de maio de 2009.
Charles Hymes - Expect<http://expect.nist.gov/> Acessado em 17 de maio de 2009.
SecureWorks - DNS Cache Poisoning<http://www.secureworks.com/research/articles/dns-cache-poisoning/> Acessado em 17 de maio de 2009.
ISC – Internet Systems Consortium<https://www.isc.org/> Acessado em 17 de maio de 2009.
RFC 2010 - Operational Criteria for Root Name Servers(http://www.rfc-archive.org/getrfc.php?rfc=2010 - Acessado em 17 de maio de 2009.
RFC 2087 - IMAP4 QUOTA extension<http://www.rfc-archive.org/getrfc.php?rfc=2087> Acessado em 17 de maio de 2009.
Centreon<http://www.centreon.com> Acessado em 19 de maio de 2009.
Debian GNU/Linux<http://www.debian.org/index.pt.html> Acessado em 28 de maio de 2009.