0
CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA
PAULA SOUZA
FACULDADE DE TECNOLOGIA DE LINS PROF. ANTONIO SEABRA
CURSO SUPERIOR DE TECNOLOGIA EM REDES DE COMPUTADORES
KLEDER AUGUSTO DE ANDRADE SILVA
IMPLEMENTAÇÃO DE UMA INFRAESTRUTURA DE CLUSTER
VIRTUALIZADA COM ALTA DISPONIBILIDADE
LINS/SP
2º SEMESTRE/2012
1
CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA
PAULA SOUZA
FACULDADE DE TECNOLOGIA DE LINS PROF. ANTONIO SEABRA
CURSO SUPERIOR DE TECNOLOGIA EM REDES DE COMPUTADORES
KLEDER AUGUSTO DE ANDRADE SILVA
IMPLEMENTAÇÃO DE UMA INFRAESTRUTURA DE CLUSTER
VIRTUALIZADA COM ALTA DISPONIBILIDADE
Trabalho de Conclusão de Curso apresentado à
Faculdade de Tecnologia de Lins para obtenção
do Título de Tecnólogo em Redes de
Computadores.
Orientador: Prof.Ms Alexandre Ponce de Oliveira
LINS/SP
2º SEMESTRE/2012
2
KLEDER AUGUSTO DE ANDRADE SILVA
IMPLEMENTAÇÃO DE UMA INFRAESTRUTURA DE CLUSTER
VIRTUALIZADA COM ALTA DISPONIBILIDADE
Trabalho de Conclusão de Curso apresentado à
Faculdade de Tecnologia de Lins, como parte dos
requisitos necessários para obtenção do título de
Tecnólogo em Redes de Computadores sob
orientação do Prof. Ms Alexandre Ponce de
Oliveira
Data de Aprovação:__/__/____
______________________________
Orientador (Alexandre Ponce de Oliveira)
______________________________
Examinador 1
______________________________
Examinador 2
3
Dedico este trabalho à minha família
que
me
apoiou
em
todos
os
momentos, na caminhada para um
futuro
de
sucesso,
baseado
esforço e dedicação do presente.
Kleder Augusto de Andrade Silva
no
4
AGRADECIMENTOS
Na conclusão de uma importante etapa da minha vida, venho agradecer a
todos que estiveram presentes neste caminho.
Primeiramente a Deus pela vida saúde que desfruto.
A minha esposa Patricia que tanto se dedicou e me apoiou nesta caminhada.
A minha filha Giovana por ser o brilho na minha vida e por ter compreendido a
ausência enquanto me dedicava aos estudos.
Ao meu pai Luiz Carlos e minha mãe Terezinha, que se dedicam
carinhosamente a mim, meus irmãos e neta.
Aos meus Irmãos Karise e Kledson que diretamente me apoiaram nesta
etapa.
Um agradecimento especial ao professor Alexandre Ponce, que além de
proporcionar conhecimento durantes as aulas, foi fundamental na conclusão desta
monografia sendo meu orientador compreendendo as dificuldades e compartilhando
seu amplo conhecimento.
A todos os professores que com competência e dedicação formam
profissionais capacitados e pessoas mais preparadas para a vida.
Agradeço a Fatec pelo espaço e organização, fundamentais para formação de
alunos mais preparados para o mercado de trabalho.
Um agradecimento especial aos amigos que fiz durante os estudos, pessoas
importantes que se apoiaram durante as dificuldades e sorriram durante as alegrias
Kleder Augusto de Andrade Silva
5
RESUMO
Este trabalho teve como objetivo propor a utilização de virtualização sobre uma
estrutura de cluster de computadores, com a utilização de softwares livres, estrutura
de hardware de baixo custo e combinação de alta disponibilidade dos recursos, alta
performance de processamento e segurança das informações. Para que seu
entendimento seja possível, foram abordados conceitos de sistemas distribuídos
sobre computação de grande porte, tecnologias que visam maior capacidade de
processamento com a junção de vários equipamentos. Foi apresentado também um
estudo sobre cluster, com a definição dos seus tipos, aplicações, vantagens e
limitações. Para a estruturação do cluster foi utilizado LVM junto com o gerenciador
de volumes DRBD que proporciona uma base de dados confiável e disponível para
cluster. Outro assunto abordado foi a virtualização com sua evolução e aplicação
sob o conceito de flexibilidade dos recursos, neste contexto foi utilizado o Hypervisor
Xen em conjunto com o gerenciador de virtualização e cluster Ganeti, esta
ferramenta foi desenvolvida pela empresa Google e utilizada no gerenciamento de
seus servidores e cluster. A aplicação abrange todas as ferramentas e conceitos e
resulta em uma infraestrutura altamente disponível, com grande capacidade de
processamento, segura e de baixo custo. Este cenário é ideal para aplicação em
ambiente acadêmico, corporativo ou qualquer outro que tenha necessidade de
alinhar flexibilidade, escalabilidade e confiança na infraestrutura de TI para
disponibilização de serviços.
Palavras-chave: Cluster. Xen. DRBD. Ganeti. Disponibilidade. Performance.
6
ABSTRACT
This work aimed to propose the use of virtualization on a structure of cluster
computers, using free software, hardware structure of combination of low cost and
high resource availability, high performance processing and information security. For
the understanding to be possible, concepts of distributed system were discussed
over computing of large size , technologies that aim higher processing capacity with
the addition of various equipment. It was also presented a study on cluster, with the
definition of their types, applications, advantages and limitations. For the structure of
the cluster it was used LVM along with the volume manager DRBD that provides a
reliable database and available for cluster. Another issue addressed was
virtualization with its evolution and application under the concept of flexible resources
in this context was used in conjunction with Xen Hypervisor virtualization manager
and the cluster Ganeti, this tool was developed by Google and used in the
management of their servers and cluster. The application includes all the tools,
concepts and results in a highly available infrastructure with high processing
capacity, safe and low cost. This scenario is ideal for applying in academic
environment, corporate or any other in need of aligning flexibility, scalability and
reliability in the IT infrastructure for provision of services.
Keywords: Cluster. Xen. DRBD. Ganeti. Availability. Performance.
7
LISTA DE ILUSTRAÇÕES
Figura 1.1 – Sistemas Distribuídos............................................................................ 16
Figura 1.2 – Diagrama de Cluster para Alta Disponibilidade ..................................... 20
Figura 1.3 – Computação em Grade ......................................................................... 22
Figura 2.1 - Cluster para serviço WEB ...................................................................... 24
Figura 2.2 – Diagrama de funcionamento do DRBD ................................................. 27
Figura 2.3 – Diagrama de funcionamento do Cluster HPC ....................................... 28
Figura 2.4 – Cluster Beowulf ..................................................................................... 29
Figura 3.1 – Diagrama da Virtualização .................................................................... 32
Figura 3.2 – Arquitetura da Virtualização .................................................................. 34
Figura 3.3 – Máquina Virtual ..................................................................................... 35
Figura 3.4 – Diagrama Virtualização Total ................................................................ 36
Figura 3.5 – Diagrama Paravirtualização .................................................................. 38
Figura 3.6 – Diagrama Virtualização Assistida .......................................................... 39
Figura 3.7 – Arquitetura Xen ..................................................................................... 40
Figura 4.1 – Diagrama da estrutura do cluster .......................................................... 42
Figura 4.2 – Inicialização do cluster .......................................................................... 50
Figura 4.3 – Verificação do status do cluster ............................................................ 51
Figura 4.4 – Progresso de criação de instância ........................................................ 52
Figura 4.5 – Status DRBD ......................................................................................... 52
Figura 4.6 – Listagem inicial das instâncias .............................................................. 53
Figura 4.7 – Incialização de instância ....................................................................... 53
Figura 4.8 – Conexão ao console da instância.......................................................... 53
Figura 4.9 – Diagrama cluster ................................................................................... 54
Figura 4.10 – Migração de instância ......................................................................... 54
Figura 4.11 – Listagem de instâncias após migração ............................................... 55
Figura 4.12 – Diagrama cluster pós migração da VM2 ............................................. 55
Figura 4.13 – Migração de todas instâncias de um nó .............................................. 56
Figura 4.14 - Diagrama do cluster pós migração de todas intancias ......................... 57
Figura 4.15 – Diagrama do cluster – simulação de falha .......................................... 57
Figura 4.16 - Diagrama do cluster pós falha no node2.............................................. 58
Figura 4.17 – Listagem de instâncias após falha de nó do cluster ............................ 58
Figura 4.18 – Listagem de instâncias pós failover..................................................... 59
8
Figura 4.19 - Diagrama do cluster pós failover .......................................................... 59
9
LISTA DE QUADROS
QUADRO 1.1 – Diferenças entre computação de grande porte e distribuída............29
QUADRO 4.1 – Configuração das instâncias.............................................................52
10
LISTA DE ABREVIATURAS E SIGLAS
AD – Active Directory
CPU – Central Processing Unit
DRBD - Distributed Replicated Block Device
HA – High Avaliability
HPC- Cluster High Performance Computing
IP – Internet Protocol
LVM – Logical Volume Manager
LVS - Linux Virtual Server
NIC – Network Interface Controller
OOB – Out of Band
OSI - Open Systems Interconnection
PC – Personal Computer
RAID - Redundant Array of Independent Disks
TCP – Protocolo de Controle de Transmissão
TI – Tecnologia da Informação
VM – Virtual Machine
11
SUMÁRIO
1 SISTEMAS DISTRIBUÍDOS ............................................................................. 15
1.1 PARADIGMAS DA COMPUTAÇÃO DE GRANDE PORTE ......................... 17
1.2 SISTEMAS DE COMPUTAÇÃO DISTRIBUÍDOS ........................................ 18
1.3 COMPARATIVOS ENTRE COMPUTAÇÃO DE GRANDE PORTE E
DISTRIBUÍDA ...................................................................................................... 19
1.4 COMPUTAÇÃO EM CLUSTER ................................................................... 20
1.5 COMPUTAÇÃO EM GRID ........................................................................... 21
2 CLUSTER DE COMPUTADORES .................................................................... 23
2.1 CLUSTERS DE ALTA DISPONIBILIDADE .................................................. 24
2.1.1
Linux Virtual Server ............................................................................... 25
2.1.2
Heartbeat ............................................................................................... 26
2.1.3
Distributed Replicated Block Device ...................................................... 26
2.2 CLUSTER DE ALTO DESEMPENHO .......................................................... 27
2.3 CLUSTER BEOWULF .................................................................................. 29
3 VIRTUALIZAÇÃO ............................................................................................. 31
3.1 MÁQUINA VIRTUAL .................................................................................... 34
3.2 HYPERVISORS ........................................................................................... 35
3.3 TÉCNICAS DE VIRTUALIZAÇÃO ................................................................ 35
3.3.1
Virtualização Total ................................................................................. 36
3.3.2
Paravirtualização ................................................................................... 37
3.3.3
Virtualização Assistida por Hardware .................................................... 38
3.4 SOFTWARES DE VIRTUALIZAÇÃO ........................................................... 39
3.4.1
VMware ................................................................................................. 39
3.4.2
Xen ........................................................................................................ 40
3.4.3
Hyper-V ................................................................................................. 41
4 IMPLEMENTAÇÃO ........................................................................................... 42
12
4.1 INSTALAÇÃO E CONFIGURAÇÕES INICIAIS ............................................ 44
4.1.1
Ganeti .................................................................................................... 45
4.1.2
Xen ........................................................................................................ 45
4.1.3
Configuração DRBD .............................................................................. 47
4.1.4
Topologia de Rede ................................................................................ 47
4.2 INICIALIZAÇÃO DO AMBIENTE .................................................................. 49
4.3 DEMONSTRAÇÃO DO AMBIENTE ............................................................. 51
4.3.1
Criação de Instâncias ............................................................................ 51
4.3.2
Movimentação de Instâncias entre nós do Cluster ................................ 54
4.3.3
Simulação de Desligamento Programado do Nó Máster ....................... 55
4.3.4
Simulação de Desligamento Não Programado do Nó Máster ............... 57
CONCLUSÃO ...................................................................................................... 61
REFERÊNCIAS ................................................................................................... 64
13
INTRODUÇÃO
A necessidade de acesso constante a informação é uma realidade cada vez
maior em nossa sociedade, onde qualquer ambiente que dependa da tecnologia da
informação tem em seus principais objetivos a total disponibilidade dos recursos e
informações.
Com a crescente demanda para acesso a informação, a arquitetura de um
ambiente de TI esta cada vez mais voltada para a alta-disponibilidade com ênfase
na segurança dos dados. É cada vez mais importante que as empresas alinhem as
estratégias de negócios com base nos investimentos na tecnologia da informação.
(VERAS, 2011)
Uma abordagem bem sucedida para a solução da necessidade de altadisponibilidade, segurança e grande poder de processamento baseia-se em
tecnologias de software opensource, que unem todos os requisitos para atingir estes
objetivos, com o uso de tecnologias gratuitas e altamente eficientes. (SALLES et. al.,
2009)
Atualmente a virtualização é uma tecnologia cada vez mais presente em
ambientes de TI, através dela é possível obter o maior aproveitamento dos recursos
físicos de hardware, tendo foco em flexibilidade e disponibilidade das informações e
serviços. (CARISSIMI, 2008)
A tecnologia de cluster é outra tecnologia amplamente utilizada atualmente,
seja para alta disponibilidade dos recursos, quanto para atender a alta demanda
para processamento. O cluster faz com que um ou mais computadores funcionem
em cooperação para atender a demanda de processamento e requisição de
recursos.(SLTI, 2006)
A utilização aliada de virtualização e cluster fornece o conjunto de benefícios
que cada um possui, consolidando uma estrutura completa para atendimento das
atuais demandas da tecnologia da informação. Esta combinação proporciona
agilidade aos negócios, facilidade de gerenciamento, capacidade de expansão e
poder de processamento, ainda motivação pela segurança e confiabilidade na
arquitetura. (ANTONOPOULOS, 2005)
A importância deste estudo em um ambiente acadêmico é grande, uma vez
que nesta etapa o estudante precisa ter contato com um ambiente amplamente
tecnológico, alinhado as necessidades e demandas do mercado consumidor destas
14
tecnologias e recursos. Este contato promove uma base de conhecimento mais
completa das principais tecnologias voltadas para o conceito de supercomputação.
A pesquisa foi feita com base em bibliografia específica aos assuntos
abordados, artigos acadêmicos, materiais disponibilizados na internet e também
documentação oficial dos softwares descritos ou utilizados
Este projeto tem como objetivo o desenvolvimento de uma arquitetura de
virtualização baseada em um cluster de computadores, com a combinação de alta
disponibilidade dos recursos e alta performance de processamento.
O ambiente prático aqui desenvolvido tem por objetivo simular a situação real
para aplicação destas tecnologias, onde são apresentadas situações que
necessitam de contingência de operação para promover a alta disponibilidade dos
recursos, bem como a segurança das informações contidas na estrutura em
questão.
Para atingir o objetivo da proposta, foi desenvolvido um cluster com dois nós,
onde o volume de dados é compartilhado através do gerenciador de volumes DRBD.
Estes volumes de dados são entregues ao Ganeti, que é o gerenciador de cluster
escolhido para o projeto, sendo este também responsável pelo gerenciamento da
camada de virtualização e suas instâncias.
Dentro do cenário proposto será feita simulação de situações reais de
manipulação e gerenciamento das instâncias alocadas no cluster o mais próximo de
um ambiente real.
Desta forma, o trabalho está estruturado da seguinte forma: o primeiro
capítulo descreve os conceitos sobre sistemas distribuídos em suas definições e
aspectos, no segundo capítulo é feito o estudo mais aprofundado da tecnologia de
cluster, com a definição dos seus tipos, aplicações, vantagens e limitações, o
conceito
de
virtualização,
sua
evolução,
aplicação
sob
o
contexto
de
disponibilização, flexibilidade dos recursos é descrito no terceiro capítulo, o quarto
capítulo apresenta o estudo de caso, onde são aplicados os conceitos em ambiente
que define uma situação real para aplicação da proposta, por fim, tem-se as
conclusões finais sobre o trabalho.
15
1 SISTEMAS DISTRIBUÍDOS
Neste capítulo são abordados todos os conceitos relacionados à essência da
computação de grande porte, tecnologias que visam promover maior capacidade de
processamento através da união de equipamentos em um único bloco de
processamento central. Componentes assimétricos, ou seja, desde computadores
convencionais até mesmo mainframes de grande porte. Esta composição é
transparente ao usuário, que tem como apresentação de uso um frontend que não
transparece a estrutura física e de gerenciamento envolvidos nesta arquitetura
computacional.
Segundo Tanenbaum e Steen (2007, p.1): “Um sistema distribuído é um
conjunto de computadores independentes que se apresenta aos seus usuários como
um sistema único e coerente”.
Para Coulouris, Dollimore e Kindberg (2007, p.15), “Um sistema distribuído é
aquele no qual os componentes localizados em computadores interligados em rede
se comunicam e coordenam suas ações apenas passando mensagens”.
Segundo Tanenbaum e Steen (2007), uma característica importante esperada
de um sistema distribuído é a escalabilidade da estrutura, sendo possível a
ampliação por meio de adição de componentes ao conjunto fazendo uso da
independência das unidades no comportamento do conjunto, somando capacidade e
recursos na estrutura como um todo
Conforme explica Coulouris, Dollimore e Kindberg (2007), o motivo principal
que leva a construção e definição de um sistema distribuído é o compartilhamento
de recursos, que podem ser gerenciados por servidores a fim de atender aos
clientes que os necessitam.
Segundo Tanenbaum e Steen (2007), a entrega dos serviços independente
da situação direta da estrutura é proporcionada pela independência dos
componentes, mediante a administração do sistema de gerenciamento central,
permanecendo o processamento disponível mesmo que componentes estejam
avariados ou indisponíveis.
Ainda segundo Tanenbaum e Steen (2007), pela transparência obtida, os
usuários e sistemas não percebem que a estrutura está em processo de
manutenção, uma vez que o cerne do sistema não atribui uma função específica a
um determinado componente.
16
Para Caulouris, Dollimore e Kindberg (2007), a heterogeneidade de
componentes, a segurança e a escalabilidade são fatores fundamentais nos desafios
de concepção de um sistema distribuído, principalmente no que tange a ampliação
de usuários, adição de componente e transparência da estrutura.
Na figura 1.1 é mostrado como os computadores em paralelo se comportam
durante a divisão das funções por meio da camada de sistema distribuído.
Figura 1.1 – Sistemas Distribuídos
Fonte: Tanenbaum; Steen, 2007, p.1
De acordo com Tanenbaum e Steen (2007), a funcionalidade de um sistema
distribuído, tem como principal componente um software específico, também
conhecido como Middleware, que desempenha a função de fazer a interconexão de
todos
os
componentes
físicos
do
conjunto,
disponibilizando
interface
de
processamento para as aplicações que serão executadas e entregues aos usuários
dos sistemas.
Segundo Tanenbaum e Steen (2007, p.222), “Para suportar computadores e
redes heterogêneas e, simultaneamente oferecer uma visão de sistema único, os
sistemas distribuídos costumam ser organizados por meio de uma camada de
software”.
Essa adaptabilidade aos diversos tipos de configuração e de componentes
nos permite maior aproveitamento dos recursos não ficando restrito a uma
arquitetura de hardware, sendo este um fator importante no custo de implantação e
manutenção da estrutura, bem como a ampliação e escalabilidade futura do projeto
em questão. (TANENBAUM; STEEN, 2007)
17
1.1
PARADIGMAS DA COMPUTAÇÃO DE GRANDE PORTE
Conforme Slti (2006, p 28) “A computação de grande porte é definida como
sistema de alta capacidade de computação, também conhecida como “Alta
plataforma”,
esta
é
caracterizada
pela
utilização
de
Mainframes
e
supercomputadores”.
Nascidos em 1946, os Mainframes são sistemas de computação capazes de
processar grande quantidade de solicitações de dados de milhares de usuários
conectados através de uma rede distribuída. Estes equipamentos geralmente
ocupam grandes espaços físicos e demandam ambientes específicos para o seu
funcionamento, onde temperatura e umidade são alguns dos fatores ambientais
importantes no projeto de sua instalação. (SLTI, 2006)
Na década de 60 foi apresentado o conceito de supercomputador, que é um
computador de alta capacidade de processamento e também com grande
quantidade de memória, normalmente empregado em pesquisas científicas e
militares. Este ambiente é voltado para pesquisas que exigem grande capacidade de
processamento e disponibilidade de recursos, muitas vezes para simulações de
resultados das pesquisas. (SLTI, 2006)
A distinção entre supercomputadores e mainframes não é clara e direta,
mas genericamente são diferenciados pelas tarefas submetidas, os
supercomputadores são utilizados na solução de problemas em que o
tempo de cálculo é um limite (processamento), enquanto os mainframes são
utilizados em tarefas que exigem alta disponibilidade, envolvem alta taxa de
transferência de dados (internos ou externos ao sistema) e acessos
simultâneos. (SLTI, 2006)
De acordo com Slti (2006), quando estes equipamentos chegam a sua
capacidade limite de processamento, se faz necessária a ampliação de sua
capacidade através da adição de novo hardware ao conjunto, ou até mesmo a
substituição total do equipamento. Ambas as alternativas tem como principal impacto
o elevado custo financeiro, uma vez que a aquisição de dispositivos de hardware
proprietário significam valores elevados já que não existe componente compatível
para aquisição no mercado.
Outro ponto importante citado por Slti (2006), é que no sistema de
computação de grande porte, não é possível calcular de forma precisa a demanda
por processamento, as soluções adquiridas excedem a carga necessária de
processamento.
18
1.2
SISTEMAS DE COMPUTAÇÃO DISTRIBUÍDOS
Foco principal dos sistemas distribuídos no que diz respeito à arquitetura
computacional, computação em cluster e computação em grade, tem como objetivo
principal o alto desempenho computacional e a alta disponibilidade para entrega dos
recursos.
Para Tanenbaum e Steen (2007, p.222), “Uma classe importante de sistemas
distribuídos é a utilizada para tarefas de computação de alto desempenho”.
Esta classe permite a utilização modular de equipamentos de pequeno porte,
trabalhando
de
forma
coordenada
promovendo
maior
capacidade
de
processamento.
Segundo Morimoto (2005), clusters e grades computacionais tem como ideia
central a cooperação de equipamentos ligados através de uma rede, fazendo uso da
capacidade individual para executar processamento de grande carga.
De acordo com Slti (2006), existem cinco gerações bem definidas de sistemas
distribuídos, os quais podem ser elencados em um período de 20 anos.
A primeira geração utilizava uma arquitetura muito lembrada nos dias atuais,
popularmente conhecida como terminais burros, caracterizando pelo processamento
e armazenamento centralizado das informações. Um servidor era responsável por
receber as solicitações de inicialização dos terminais remotos, estabelecendo o
processo
de
envio,
recebimento,
processamento
e
armazenamento
das
informações. (SLTI, 2006)
A segunda geração, se baseia na primeira com relação ao processamento e
armazenamento das informações, diferenciando-se por conter uma pequena
capacidade de processamento local, a qual era utilizado para executar a emulação
do terminal de acesso remoto. (SLTI, 2006)
Já na terceira geração, o conceito de aplicações cliente/servidor é utilizado,
onde o cliente conta com considerável capacidade de processamento. A interação
de sistemas é feita por meio de compartilhamento de funções e tarefas, onde o
terminal tem condição de executar tarefas juntamente com o servidor das
aplicações. (SLTI, 2006)
A quarta geração se caracteriza pela utilização de aplicações multicamadas e
interfaces distintas para as aplicações. O processamento é delimitado de acordo
com as regras do negócio. (SLTI, 2006)
19
E por fim a quinta geração é baseada em grid computing, caracterizada pela
utilização do processamento contido em um pool virtual, permitindo ao cliente a
utilização dos recursos necessários sob demanda, sem a necessidade de alocação
rígida e inflexível dos recursos disponíveis na infraestrutura física dos componentes.
(SLTI, 2006)
1.3
COMPARATIVOS ENTRE COMPUTAÇÃO DE GRANDE PORTE E
DISTRIBUÍDA
A computação de grande porte e a computação distribuída compartilham
algumas
semelhanças,
as
duas
arquiteturas
demandam
estruturas
físicas
semelhantes no que diz respeito à segurança e controle de acesso ao ambiente,
refrigeração, fornecimento ininterrupto de energia elétrica e organização do espaço
físico. (SLTI, 2006)
Pode-se citar o alto poder de processamento, alta disponibilidade, suporte a
milhares de transações e usuários simultâneos, contingenciamento de recursos,
administração do ambiente e grande capacidade de armazenamento de dados.
(SLTI, 2006)
O quadro 1.1 exibe as diferenças entre computação distribuída e de grande
porte.
Quadro 1.1- Diferenças entre computação de grande porte e distribuída
Computação de grande porte
Sistemas distribuídos: Cluster e Grid
- Alto custo de implantação;
- Baixo custo de implantação;
- Dependência de fornecedor único;
- Independência de fornecedores;
- Utilização de hardware específico;
- Facilidade de negociação;
- Alto custo de manutenção;
- Utiliza hardware comum, padrão PC;
- Dificuldade de redimensionamento do
- Baixo custo de manutenção;
ambiente;
- Facilidade de redimensionamento do
- Utilização parcial da capacidade de
ambiente;
processamento;
-
- Grande custo total de propriedade;
processamento;
- Tecnologia estabelecida no mercado.
- Baixo custo total de propriedade;
Maximização
da
- Tecnologia inovadora.
Fonte: (SLTI, 2006)
capacidade
de
20
1.4
COMPUTAÇÃO EM CLUSTER
Segundo Tanenbaum e Steen (2007), computação em cluster tem seu
conceito uma maior homogeneidade dos componentes (computadores) que
participam da sua implementação, comunicando-se através de uma rede e
compartilhando uma camada de sistema que gerencia os sistemas operacionais de
cada nó do cluster, deixando transparente este processo ao cliente, ou seja, o
mesmo não percebe onde ou como é processada a carga de trabalho.
Conforme Morimoto (2005) explica, um cluster é formado por um conjunto de
equipamentos gerenciado por um ponto central, onde cada nó se torna um escravo
executando
tarefas
escalonadas
por
um
gerenciador
central.
É
utilizado
principalmente para aplicações com alta necessidade e complexidade de
processamento, bem como atividades de renderização.
A computação em cluster na maioria dos casos é utilizada para computação
paralela, onde diversas máquinas desempenham a tarefa de processamento de
forma compartilhada. (TANENBAUM; STEEN, 2007)
A figura 1.2 demonstra o diagrama de um cluster de alta disponibilidade e
performance.
Figura 1.2 – Diagrama de Cluster para Alta Disponibilidade
Fonte: Cloud, 2010.
21
Segundo Tanenbaum e Steen (2007), este modelo de computação distribuída,
tornou-se popular com a diminuição dos custos de aquisição dos equipamentos.
Como sua implementação podia ser feita com equipamentos convencionais, a
aquisição de componentes para manutenção ou ampliação tornava a estrutura mais
barata, flexível e simplificada.
1.5
COMPUTAÇÃO EM GRID
Conforme definido por Slti (2006, p.169) “Os grids computacionais surgiram
na década de 90 com o intuito de viabilizar a execução de aplicações de forma
paralela e recursos computacionais geograficamente dispersos pertencente à uma
mesma organização”.
No primeiro momento a computação em grid tinha como principal objetivo
substituir as plataformas baseadas em supercomputadores, que tinham elevados
custos de aquisição e manutenção, além de se tornarem obsoletos em um espaço
de tempo relativamente curto, sendo necessária a sua substituição por completo.
(SLTI, 2006)
A segunda proposta tangia a questão de execução de grande volume de
processamento, superando a capacidade que um computador individual teria
condições de executar. (SLTI, 2006)
Para Morimoto (2005), a tecnologia de computação em grade é mais
democrática, tanto no sentido de heterogeneidade dos componentes, onde diversos
tipos de equipamentos tem condição de participar da estrutura, bem como sua forma
de participação nas tarefas necessárias.
A diferenciação prática com relação ao conceito de computação em cluster é
o fato que a arquitetura em grid faz com que a parte ociosa de um nó seja destacada
para atender a demanda de processamento necessário para determinada tarefa no
grid, desta forma gerando autonomia na utilização dos recursos uteis e disponíveis
(MORIMOTO, 2005)
O nó não fica dedicado ao processamento, disponibiliza somente a
capacidade ociosa naquele momento, retomando esta capacidade disponibilizada
caso tenha necessidade. Existe também a troca, onde o nó pode fazer uso da
capacidade de processamento do grid, caso tenha necessidade por esta demanda
de processamento. (MORIMOTO, 2005)
22
A figura 1.3 ilustra o conceito de diversidade de equipamentos que podem
compor um grid.
Figura 1.3 – Computação em Grade
Fonte: Salustino, 2012.
Segundo Tanenbaum e Steen (2007), diversas tecnologias podem compor
uma estrutura de computação em grade, desde computadores convencionais até
supercomputadores passando por componentes periféricos.
Tem como base o compartilhamento e interoperabilidade dos recursos,
formando um conjunto de funções amplamente disponíveis para utilização dos
usuários participantes da organização ou domínios. (TANENBAUM; STEEN, 2007)
Os recursos são dispostos à medida que passam a participar da organização,
desta forma a escalabilidade de recursos é facilitada, evitando complexidade na
participação de componentes. (TANENBAUM; STEEN, 2007)
Segundo Morimoto (2005), um grid pode ser formado por computadores de
uma empresa distribuídos geograficamente pelo mundo, interligados através da
WEB, e que podem executar funções de processamento em tempo integral, pois
devido ao fuso horário sempre haverá equipamentos disponíveis para execução de
funções.
Este capítulo abordou vários conceitos importantes e que serviram de base
para o desenvolvimento do segundo capítulo que aborda com maiores detalhes
computadores em cluster, sendo este, tecnologia fundamental na implementação
deste projeto.
23
2 CLUSTER DE COMPUTADORES
Desenvolvido na década de 60 pela empresa IBM, quando duas máquinas
permitiram a interligação de seus mainframes a um custo moderado. Este conceito
ainda hoje é aplicado, uma vez que a utilização de dois ou mais equipamentos para
a solução de um problema é considerado tecnicamente um cluster. (PITANGA,
2008)
Cluster são grupos de servidores trabalhando juntos para alcançar
determinada funcionalidade. Estes atuam como se fossem um único servidor,
propiciando funções de alta disponibilidade e performance para o ambiente
proposto. (VERAS, 2011)
Segundo Pitanga (2003), um cluster é formado por dois ou mais
computadores denominados nodos, interligados através de uma interface de rede,
com a finalidade de executar as funções ou tarefas necessária, transparecendo ao
usuário que esta foi executada por um único computador, sendo isto denominado
transparência de sistema.
Para Morimoto (2005) um modelo lógico de composição de cluster, é aquele
que faz uso de computadores parecidos entre si, para evitar gargalos no
processamento devido ao fato de um equipamento ser mais lento que os outros.
Na década de 80 esta arquitetura passou a ganhar espaço e importância,
quando
fatores
determinantes
surgiram,
tais
como,
desenvolvimento
de
processadores de alto desempenho, desenvolvimento de redes de computadores
com baixa latência e padronização das ferramentas de computação paralela e
distribuídas, foram determinantes para a consolidação desta arquitetura. (PITANGA,
2008)
De acordo com Veras (2011) a ideia central da utilização de cluster e a
combinação de seus tipos, é promover a disponibilidade e desempenho, diminuindo
a complexidade de gerenciamento.
O termo clustering atualmente é ligado a diversas denominações de
tecnologias e configurações, podendo ser divididas em duas grandes arquiteturas
básicas, sendo a primeira denominada Cluster High-availability (HA), ou em sua
tradução, Cluster de Alta Disponibilidade e a segunda categoria o Cluster High
Performance Computing (HPC), conhecido como Cluster de Alto Desempenho.
(PITANGA, 2008)
24
2.1
CLUSTERS DE ALTA DISPONIBILIDADE
Atualmente sistemas de computação são responsáveis pelos mais diversos
tipos de atividades, dentro de um ambiente corporativo isto esta ligado a tarefas
administrativas, financeiras, gestão de pessoas e propriamente a comunicação.
(SLTI, 2006)
Estas necessidades formam um ambiente de alta dependência de recursos e
informação, tendo uma arquitetura operacional crítica, onde a inoperância ou
instabilidade na entrega de serviços e informações poderá acarretar diretamente em
prejuízos operacionais e financeiros. (SLTI, 2006)
A alta disponibilidade vem a foco justamente para resolver este tipo de
situação, garantindo o funcionamento de serviços de rede, armazenamento de
dados, processamento e comunicação mesmo se houver uma ou mais falhas e
dispositivos, sejam eles hardware ou software. (PITANGA, 2008)
A alta disponibilidade tem como objetivo disponibilizar uma função ou serviço
permanentemente ou segundo padrões de somente paradas programadas. Paradas
não planejadas estão diretamente ligadas à qualidade do serviço e prejuízos
financeiros. (PITANGA, 2008).
Figura 2.1 - Cluster para serviço WEB
Fonte: Hamc, 2008
Na figura 2.1 é exemplificado o funcionamento de serviço WEB, onde caso o
servidor principal falhe, o secundário atende o serviço sem qualquer prejuízo ao
cliente.
25
A disponibilidade de sistemas e recursos é vital para qualquer negócio, visto
que a indisponibilidade destes pode significar prejuízos financeiros diretos. Uma
empresa que trabalha com sistema de e-commerce (vendas pela internet) necessita
que seus servidores WEB e meios de comunicação estejam 24 horas disponíveis,
com capacidade suficiente para atender qualquer demanda. (PITANGA, 2008)
Em qualquer projeto que dependa de recursos ou sistemas, é importante levar
em consideração fatores ligados a infraestrutura, como por exemplo, o fato de
qualquer hardware estar sujeito a falhas, seja ela por fatores ligados a saturação de
componentes e defeitos de fabricação, e no caso de software, problemas ligados à
configuração incorreta e inconsistência de desenvolvimento. (PITANGA, 2008)
Do ponto de vista tecnológico temos duas categorias de soluções que são
ligadas diretamente a alta disponibilidade de recursos.
Alta
disponibilidade
por
hardware
é
alcançada
basicamente
pelo
monitoramento e redundância de recursos de hardware, o que impacta diretamente
nos custos físicos da estrutura. Nesta categoria os equipamentos possuem duas
fontes de alimentação, dois sistemas independentes de fornecimento de energia,
discos rígidos com espelhamento, utilização de tecnologia Hotswap onde os
componentes podem ser substituídos sem a necessidade de desligamento do
equipamento. (SLTI, 2006)
Alta disponibilidade por software, nesta categoria são aplicados softwares que
tem a função de gerenciar um conjunto de equipamentos ou servidores, fazem o
monitoramento de funcionamento, e em caso de falha de um deste, o mecanismo de
decisão é acionado a fim de redirecionar ou redistribuir tarefas aos demais
equipamentos disponíveis. Linux Virtual Server (LVS), HeartBeat e Distributed
Replicated Block Device (DRBD) são alguns softwares relacionados a esta solução e
serão foco do projeto. (SLTI, 2006)
2.1.1 Linux Virtual Server
Tecnologia que permite desenvolver ambientes de alta escalabilidade, onde a
expansão de capacidade e recursos é garantida pela facilidade de adição de novos
nós de armazenamento e processamento. Pode oferecer serviços de maior
capacidade, desempenho ou redundância, sendo este último essencial no caso de
parada de um dos servidores por problema ou manutenção. (SLTI, 2006)
26
O LVS opera como um roteador da camada do modelo Open Systems
Interconnection (OSI), onde o cliente ao acessar um serviço não consegue saber a
qual servidor esta conectado, ou a qual será numa próxima conexão ao serviço.
(SLTI, 2006)
2.1.2 Heartbeat
Resultado do projeto GNU/Linux que visa promover confiança, disponibilidade
e suportabilidade, tem como principal objetivo efetuar monitoramentos que resultam
ações. (SLTI, 2006)
Heartbeat monitora o funcionamento dos dois equipamentos através de uma
interface de rede, caso um falhe, o outro assume o serviço do nó que ficou
indisponível. Utiliza o conceito de servidor primário e servidor secundário, onde o
servidor secundário fica a espera de qualquer falha do primeiro para assumir os
serviços neles alocados, sem qualquer prejuízo ao funcionamento ou aos dados
processador. (SLTI, 2006)
O mecanismo de funcionamento deste cenário é delimitado a partir do ponto
em que um intervalo de tempo de resposta é configurado como máximo aceito, o
qual o servidor primário tem que enviar informação de funcionamento, caso este
tempo seja excedido o servidor secundário assume que o primeiro não esta mais em
operação, e assim passa a responder pelo servidor inoperante, atribuído a si a
funções que estavam sendo executadas no dispositivo que está inoperante. (SLTI,
2006)
2.1.3 Distributed Replicated Block Device
O DRBD é formado por um módulo no kernel do Linux juntamente com um
conjunto de programas e scripts, tem como principal função formar um sistema de
arquivo distribuído pela rede. Seu funcionamento é semelhante à criação de um
Redundant Array of Independent Disks (RAID) de discos físicos locais em um único
equipamento. (SLTI, 2006)
Todas as transferências do DRBD são feitas através da interface de rede,
utilizando um conjunto de protocolos, dentre eles o Protocolo de Controle de
Transmissão (TCP) e o Internet Protocol (IP). (SLTI, 2006)
27
Em todos os nós da rede é criado um vínculo pelo gerenciador central que
aloca uma partição local comum a cada um, não sendo acessível diretamente pelo
equipamento em que esta alocado o volume de dados. Toda escrita é feita no nó
controlador e redirecionada por está para os níveis inferiores, propagando para o
restante dos servidores secundários, que gravam as informações nos blocos de
nível mais baixo. (SLTI, 2006)
Na figura 2.2 são exibidos os níveis de partições e a arquitetura de nó
primário e secundário.
Figura 2.2 – Diagrama de funcionamento do DRBD
Fonte:Hellman, et al, 2012
Caso ocorra alguma falha no dispositivo primário, imediatamente o dispositivo
secundário é promovido a primário e as transferências serão feitas no sentido do
dispositivo disponível. Assim que o servidor defeituoso voltar à operação, o seu
estado de primário poderá ser devolvido ou não, dependendo da configuração
estabelecida. (SLTI, 2006)
2.2
CLUSTER DE ALTO DESEMPENHO
Esta solução é muito atrativa para ambientes que necessitam de alto poder de
processamento, tais como universidades e empresas, que tem como principal
obstáculo os custos relacionados à aquisição de um computador de grande porte.
(PITANGA, 2008)
28
Cluster de Alto Desempenho tem a capacidade de processamento com
grande volume de Gigaflops, a partir de um conjunto de computadores comuns e
com utilização de software gratuito, o seu custo é muito inferior a um único servidor
de capacidade equivalente. (SALLES et. al., 2009)
Esta arquitetura tem grande aceitação no mercado não somente pelo seu
custo de implantação, mas também pelos custos relacionados a manutenção e
ampliação de capacidade. A capacidade pode ser ampliada de acordo com a
necessidade do negócio, não tendo impacto significativo principalmente de
comparado quando existe esta necessidade em uma estrutura que utiliza a
arquitetura de supercomputador (PITANGA, 2008)
Questões
relativas
a
processamento
paralelo
e
distribuído
foram
evidenciadas, a busca por maior taxa de transferência, baixa latência de rede e
confiabilidade eram pontos colocados em propósitos especiais de análise nos
projetos das infraestruturas. (PITANGA, 2008)
Esta arquitetura tem como principal objetivo atribuir performance e
disponibilidade para grandes tarefas, sendo esta dividida em pequenas tarefas que
são distribuídas para as estações (nodos) através de interface de rede. (SALLES et.
al., 2009)
Na figura 2.3 é demonstrado um Cluster HPC .
Figura 2.3 – Diagrama de funcionamento do Cluster HPC
Fonte: Anterio, 2012
29
Nesta categoria de cluster é comum ser lembrado o nome Beowulf, sistema
de cluster desenvolvido pela National Aeronautics and Space Administration (NASA),
são utilizados em computação científica, área financeira e médica, sendo funções
diretamente ligadas a necessidade de alto processamento. (SALLES et. al., 2009)
2.3
CLUSTER BEOWULF
Com nome de um grande herói inglês que enfrentava grandes desafios tais
como monstros e dragões, o software foi batizado com este nome em referência ao
desafio que enfrentaria a alta demanda de processamento. (SALLES et. al., 2009)
A sua arquitetura é dividida em um nó central de controle, denominado nó
mestre, que tem a função de controlar o cluster através do monitoramento, recepção
e distribuição das tarefas entre os nós. (SALLES et. al., 2009)
Os nós escravos são conhecidos como backends, que tem como única função
executar as funções de processamento atribuídas pelo nó mestre. Nestes backends
não existe a necessidade de instalação de teclado ou mouse, também não é
necessária a utilização de discos rígidos. (SALLES et. al., 2009)
Os nós de frontend desempenham função de servidores de arquivos para os
demais clusters e função de gateway. O gateway fornece o acesso ao ambiente
externo do cluster, a figura 2.4 ilustra este mecanismo.
Figura 2.4 – Cluster Beowulf
Fonte: (SALLES et. al., 2009)
30
A utilização de cluster baseado no Beowulf permite a construção de uma
solução que pode alcançar altas taxas de gigaflops, com a utilização de
computadores simples e sistemas operacionais de código aberto.
São evidentes as vantagens na utilização de cluster em situações onde
grande poder de processamento é imposto. Empresas e instituições que possuem
esta demanda logo percebem esta vantagem frente aos custos de computadores de
grande porte. Esta percepção se dá ao fato de que tudo no ambiente corporativo
esta ligado diretamente ao investimento para aquisição, manutenção e capacidade
de processamento para atender a demanda requisitada. (PITANGA, 2008)
Independência de arquitetura e fornecedores é importante, pois a instituição
não depende de um mesmo padrão de hardware para manutenção e ampliação,
podendo utilizar equipamentos de custo acessível.
31
3 VIRTUALIZAÇÃO
A virtualização é atualmente uma das tecnologias mais lembradas nos
ambientes ligados a Tecnologia da Informação (TI), e tido como o futuro dos
ambientes computacionais. (CARISSIMI, 2008)
Virtualização não é uma tecnologia contemporânea, teve seu início na década
de 60, onde se buscava obter maior aproveitamento dos caros mainframes. Cada
equipamento possuía seu sistema operacional padrão e era necessária uma solução
que permitisse a utilização de software legados das empresas. (CARISSIMI, 2008)
O primeiro sucesso nesta direção foi obtido pela empresa IBM, que buscava
formas de administrar seus mainframes, aproveitar todo recurso disponível e
aumentar a disponibilidade dos serviços e recursos. Outra questão foco ter somente
um sistema operacional por equipamento, sendo este fator ligado diretamente aos
resultados dos investimentos e custos. (BLOKDIJK; MENKEN, 2008)
Com a evolução dos sistemas operacionais e restrição de quantidade destes
no mercado, capacidade cada vez maior em hardware e o paradigma de estruturas
distribuídas, voltou o foco sobre a tecnologia de virtualização. (CARISSIMI, 2008)
A virtualização tornou-se a base estrutural de qualquer Data Center, onde se
obtêm a divisão física de um servidor em vários servidores virtuais, com impacto na
administração e benefícios obtidos com esta tecnologia. (VERAS, 2011)
Os benefícios da virtualização estão ligados diretamente a necessidade atual
por demanda de processamento e administração de recursos, sendo assim
aplicadas em diferentes soluções para usuários, organizações empresariais,
instituições governamentais, ensino e ciência. (BLOKDIJK; MENKEN, 2008)
Com a ampliação na utilização de redes de computadores, é comum o
administrador de infraestrutura lidar com diferentes tecnologias ao mesmo tempo.
Em estruturas computacionais, é comum o atendimento desta demanda ser feito por
soluções baseadas em um único servidor, compatibilizando e direcionando o
conjunto de clientes dependentes daquela tecnologia. (BLOKDIJK; MENKEN, 2008)
O paradigma de “um servidor por serviço” em muito se deve a conceitos que
variam da compatibilidade à segurança. Na maioria dos casos o resultado desta
exclusividade é o não aproveitamento total da capacidade do processamento ou
recursos disponíveis, o que significa diretamente prejuízo financeiro já que o
investimento esta sendo utilizado com capacidade inferior a total disponível.
(CARISSIMI, 2008)
32
A virtualização já foi definida como a emulação de hardware ou software,
através de uma plataforma de sistema sob um hardware físico. Esta emulação
definia soluções relacionadas a emular memória, discos, funções de redes,
sistemas, dentre outros. (BLOKDIJK; MENKEN, 2008)
De acordo com Blokdijke Menken (2008), o conceito de emulação foi
redefinido a partir do momento que o próprio hardware passou a disponibilizar
suporte a virtualização, onde começou a participar diretamente da administração do
sistema e das funções virtualizadas. (BLOKDIJK; MENKEN, 2008)
O sentido prático do uso da virtualização esta primeiramente ligado ao
aproveitamento máximo dos recursos físicos disponíveis. É conhecido que a média
inicial de consolidação de servidores é de 10 a 30% dos recursos disponíveis, o
restante da capacidade de processamento fica ociosa. (VERAS, 2011)
A virtualização visa prover solução para este problema, tornando eficiente a
utilização dos recursos disponíveis. Por exemplo, uma empresa que utiliza cinco
diferentes servidores para cinco serviços diferentes, com a virtualização passa a ter
condição de executar os cinco serviços em um único servidor físico, mesmo que os
sistemas sejam aplicados em diferentes plataformas, este exemplo é ilustrado pela
figura 3.1 Diagrama da Virtualização. (VERAS, 2011)
SERVIDOR
1
SERVIDOR
2
SERVIDOR
3
SERVIDOR
4
SERVIDOR
5
MÁQUINA
VIRTUAL 1
MÁQUINA
VIRTUAL 2
MÁQUINA
VIRTUAL 3
MÁQUINA
VIRTUAL 4
MÁQUINA
VIRTUAL 5
SERVIDOR VIRTUALIZADO
5:1
Figura 3.1 – Diagrama da Virtualização
Fonte: (VERAS, 2011)
33
Além do aproveitamento financeiro muito observado pelas empresas em seus
negócios, outro fator que traz aplicação prática para a virtualização é o
aproveitamento de espaço físico do ambiente, tornando-o mais funcional.
(BLOKDIJK; MENKEN, 2008)
A administração de uma estrutura virtualizada é facilitada, pois o ambiente
físico é otimizado e sua operação é centralizada. Várias máquinas virtuais podem
ser administradas de um mesmo local físico, não sendo necessários espaços
diferentes para administrar o Data Center. Insto se torna cada vez mais importante
em ambientes onde o aproveitamento de espaço é cada vez mais valorizados nos
projetos de infraestrutura.(VERAS, 2011)
Em momento onde a sustentabilidade e autossuficiência são termos cada vez
mais presentes em qualquer debate, no ambiente tecnológico não seria diferente. A
virtualização esta ligada diretamente ao termo TI Verde, onde se busca o menor
impacto ambiental resultante da infraestrutura, sem deixar de lado os resultados e
beneficios esperados para o projeto. (VERAS, 2011)
Disponibilidade dos recursos é outro ponto bastante explorado com a
utilização de uma estrutura virtualizada, fator determinante no projeto, uma vez que
qualquer empresa dependente de recursos computacionais necessita do menor
tempo de parada possível. Qualquer negocio que dependa de recursos
computacionais tem como principal foco, a constante disponibilização do recursos
para o perfeito andamento das atividades. (BLOKDIJK; MENKEN, 2008)
Outro aspecto bastante importante em um ambiente virtualizado é a
portabilidade, pode-se utilizar sistemas de diversas plataformas em ambiente de
teste virtualizado, sem a necessidade de plataformas físicas para execução de
testes ou simulação de ambiente de produção. Com este modelo a economia de
equipamentos, tempo de teste e segurança são fatores determinantes na utilização
desta tecnologia em qualquer ambiente que exija prévio desenvolvimento e
simulação antes da aplicação real do projeto, sendo isto fator determinante no
sucesso da pesquisa em questão. (CARISSIMI, 2008)
A virtualização como componente central da infraestrutura, é responsável por
entregar ao sistema hóspede um conjunto de instruções relativas ao acesso de
hardware, permitindo que estes funcionem da mesma forma como se estivessem
sendo executados diretamente sobre o hardware físico do equipamento. A camada
de virtualização é conhecida como Hypervisor ou monitor de máquina virtual.
(VERAS, 2011)
34
Na figura 3.2 é ilustrada a virtualização com Hypervisor.
VM
1
AP
1
VM
2
AP
N
SO 1
AP
1
VM
N
AP
N
SO 2
AP
1
AP
N
SO 3
HYPERVISOR
SERVIDOR
FÍSICO
Figura 3.2 – Arquitetura da Virtualização
Fonte: (VERAS, 2011)
3.1
MÁQUINA VIRTUAL
Máquina Virtual é a denominação dada ao sistema operacional responsável
por dar suporte e gerenciamentos aos sistemas operacionais nele instalados.
(VERAS, 2011)
“Uma máquina virtual é um container de software totalmente isolado e capaz
de executar sistemas operacionais e aplicações próprias como se fosse um servidor
físico”. (VERAS, 2011, p.88)
Esta máquina virtual funciona como se fosse o servidor físico, não podendo
ser notada estas diferenças pelo sistema operacional hospede acima desta camada.
O comportamento de acesso ao hardware é transparente, isso faz com que o
sistema operacional acesse o disco rígido, memória, CPU e placa de rede como se
estivesse tendo controle total e único sobre estes componentes de hardware.
(VERAS, 2011)
35
A figura 3.3 exibe a interação da maquina virtual
RAM
VIRTUAL
DISCO
VIRTUAL
NIC
VIRTUAL
IDE
VIRTUAL
VM
SCSI
VIRTUAL
CPU
VIRTUAL
CD-ROM
VIRTUAL
Figura 3.3 – Máquina Virtual
Fonte: (VERAS, 2011)
3.2
HYPERVISORS
Hypervisor é uma máquina virtual de sistema que permite a coexistência de
diversos sistemas operacionais, serviços e usuários em uma mesma plataforma de
hardware. Sua principal função é organizar o acesso dos sistemas operacionais ao
hardware, de forma que uma não interfira no funcionamento da outra ou mesmo que
percebam a existência de outros sistemas operacionais sobre a mesma plataforma
de hardware. (VERAS, 2011)
Esta camada de virtualização é responsável também por garantir a segurança
e o isolamento entre os sistemas operacionais que estão instalados na estrutura.
Esse isolamento não permite que qualquer execução de processo isolado no
sistema operacional possa degradar o funcionamento do servidor físico, assim
impactar no funcionamento dos outros sistemas hospedados neste hypervisor.
(VERAS, 2011)
3.3
TÉCNICAS DE VIRTUALIZAÇÃO
36
A virtualização pode ser obtida de acordo com algumas técnicas: Virtualização
Total, Paravirtualização e Virtualização assistida por hardware. (VERAS, 2011
3.3.1 Virtualização Total
Nesta categoria de virtualização o hypervisor cria uma imagem do hardware e
apresenta esta ao sistema operacional hospedado, dando a este a impressão de
estar rodando diretamente sob o hardware. (VERAS, 2011)
Não existe a necessidade de qualquer mudança de hardware ou no software
mesmo porque o conjunto de drivers é genérico, isto se faz necessário devido à
grande quantidade de dispositivos e modelos. (VERAS, 2011)
Uma das vantagens desta modalidade é a portabilidade do sistema
operacional instalado, uma vez que os drivers são genéricos. Desta forma o sistema
operacional hospedado pode ser ligado a qualquer servidor sem a necessidade de
adaptação ou instalação de novos drivers. (VERAS, 2011)
A figura 3.4 ilustra o mecanismo de funcionamento da Virtualização total.
Execução
direta dos
requests da
Aplicação
Ring 3
(Aplicações do Usuário)
Ring 2
Ring 1 (SO convidado)
Translação
Binários dos
requests
do SO
Ring 0 (VMM)
SERVIDOR
Figura 3.4 – Diagrama Virtualização Total
Fonte: (VERAS, 2011)
37
Esta categoria de virtualização tem sua desvantagem ligada diretamente ao
fato de os conjuntos de drivers serem genéricos. O hardware físico real pode ser
subutilizado pelo fato de as instruções de utilização seguirem o padrão definido pelo
hypervisor, assim não aproveita a capacidade máxima do hardware disponivel.
(VERAS, 2011)
Outro fator de desvantagem é o fato deste hypervisor funcionar como
interpretador das instruções, principalmente as sensíveis ao funcionamento. Desta
forma os comandos e instruções são interpretados e testados pelo hypervisor, o que
acaba degradando a performance do sistema operacional hospedado. (VERAS,
2011)
3.3.2 Paravirtualização
Esta categoria de virtualização surgiu como uma alternativa de solução dos
problemas encontrados na virtualização total. (VERAS, 2011)
Na paravirtualização, o sistema hóspede é modificado para chamar o
hypervisor sempre que uma instrução sensível for executada. Desta forma o
hóspede que tem seu kernel modificado, tem condições de executar instruções sem
a necessidade de acompanhamento ou interpretação do hypervisor. (VERAS, 2011)
Estas técnicas permitem que o sistema operacional hóspede tenha mais
desempenho de execução, pois o acesso ao hardware não necessita de todas as
interpretações das instruções, tal como acontece no modelo de virtualização total.
(VERAS, 2011)
O gerenciamento de drivers é feito de forma diferente, onde não mais é
utilizado um conjunto de drivers genéricos. Na Paravirtualização o conjunto de
drivers é nativo. Esta técnica permite que o acesso ao hardware por parte dos
sistemas hóspedes, seja feito através de drivers específicos e compatíveis com as
características do hardware, assim faz com que o sistema ganhe uma maior
performance, pois aproveitará toda capacidade de hardware disponível. (VERAS,
2011)
Conforme a figura 3.5 exemplifica, o sistema operacional é modificado para
acesso direto ao hardware, fazendo a entrega e recebimentos dos comandos,
fazendo que as instruções de acesso ao hardware sejam feitas diretamente no
equipamento físico.
38
Execução
direta dos
requests da
Aplicação
Ring 3
(Aplicações do Usuário)
Ring 2
Ring 1
Ring 0 (SO CONVIDADO
PARAVIRTUALIZADO)
Hypercalls para a
camada de virtualização
Substituem instruções
do SO não virtualizadas
CAMADA DE
VIRTUALIZAÇÃO
SERVIDOR
Figura 3.5 – Diagrama Paravirtualização
Fonte: (VERAS, 2011)
A desvantagem desta categoria de virtualização se deve ao fato de exigir que
o sistema operacional hospedado permita alteração em sua estrutura de kernel. Esta
característica pode ser encontrada em sistemas operacionais baseados em Linux,o
contrário desta condição acontece com o sistema operacional Windows, que não
permite alteração em sua estrutura. (VERAS, 2011)
3.3.3 Virtualização Assistida por Hardware
A virtualização assistida por hardware surgiu com a participação dos
fabricantes de processadores na busca de melhorar o desempenho da virtualização.
Os fabricantes passaram a utilizar extensões específicas para virtualização
dentro de seus processadores da plataforma x86. (VERAS, 2011)
As tecnologias Intel (Intel VT) e AMD (AMD-VT) modificaram a forma de como
as instruções eram gerenciadas internamente e entregue ao sistema, desta forma
houve um ganho significativo de performance, em estrutura que utiliza a
virtualização total, praticamente equiparando a performance da paravirtualização.
(VERAS, 2011)
39
O mecanismos de funcionamento da virtualização assistida por hardware é
exibido na figura 3.6.
Execução
direta dos
requests da
Aplicação
Ring 3
(Aplicações do Usuário)
Ring 2
Ring 1
Ring 0 (SO CONVIDADO
PARAVIRTUALIZADO)
Requests do SO para o
VMM sem translação
binária ou
PARAVIRTUALIZAÇÂO
CAMADA DE
VIRTUALIZAÇÃO
SERVIDOR
Figura 3.6 – Diagrama Virtualização Assistida
Fonte: (VERAS, 2011)
3.4
SOFTWARES DE VIRTUALIZAÇÃO
Existem diversas ferramentas no mercado para implementação de uma
infraestrutura de virtualização,e fazendo uso de tecnologias variadas. (CARISSIMI,
2008)
3.4.1 VMware
O VMware é na realidade um conjunto de soluções para virtualização e
administração desta estrutura. Fazem parte deste conjunto o VMware ESX, VMware
ESXi, Virtual SMP, VMFS, VMware Server, VMware Workstation, Fusion, VMware
Player e o VCenter. (CARISSIMI, 2008)
40
Diretamente voltado para virtualização de plataforma de servidores, estão o
VMware ESXi e o VMware ESX, tendo estes diferenças internas de projeto e como
alguns procedimentos de gerenciamento são executados. (CARISSIMI, 2008)
3.4.2 Xen
O Xen é uma arquitetura de virtualização baseado na doutrina de software
livre, desenvolvido na universidade de Cambridge. Este projeto resultou em uma
empresa chamada XenSource inc, que foi adquirida pela empresa Citrix no ano de
2007. (CARISSIMI, 2008)
Os domínios são dois tipos de máquinas virtuais, diferenciados pelo nível de
privilégio que cada um tem para acessar o hardware. Estes domínios são chamados
de domínio 0 (privilegiado) e domínio U (não privilegiado). (CARISSIMI, 2008)
Por não ser capaz de interagir diretamente com os sistemas hóspedes, o Xen
necessita de um sistema inicial, o domínio 0, somente depois deste ser iniciado, as
máquinas virtuais no domínio U podem se gerenciadas. (CARISSIMI, 2008)
O domínio 0 pode executar ações de acesso e gerenciamento ao hardware
físico, bem como acesso as demais máquinas virtuais que estão em domínio U. O
domínio 0 pode ser um sistema operacional modificado, dotado de dois drivers
especiais responsáveis por gerenciar as requisições de acesso a rede e ao disco,
feitos por máquinas virtuais que se encontrar em domínio U. (CARISSIMI, 2008)
A arquitetura de funcionamento do Xen é ilustrado na figura 3.7.
Máquina Virtual 1
AP1
Máquina Virtual 2
APn
AP1
APn
Domínio 0
Gerenciamento
Núcleo Linux
(modificado)
Núcleo Linux (modificado)
OpenSolaris (modificado)
Driver virtual
Driver virtual
Drivers físicos
Hypervisor (Xen)
Gerenciamento de CPU e memória
Hardware
Dispositivos de E/S
Figura 3.7 – Arquitetura Xen
Fonte: (VERAS, 2011)
41
A primeira versão do hypervisor Xen foi desenvolvida para atender os
quesitos de paravirtualização, ou seja, primou-se pela performance do sistema.
(CARISSIMI, 2008)
Esta característica tornava seu uso restrito somente a sistemas operacionais
baseados em Unix modificável, ficando de lado softwares como, por exemplo, o
Microsoft Windows. (CARISSIMI, 2008)
Com o intuito de compatibilizar a ferramenta com o conceito de virtualização
total, a partir da versão 3, o Xen passou a dar suporte aos sistema operacionais não
modificáveis, entretanto somente em plataforma dotada de processadores com
tecnologia Intel-VT ou AMD-V. (CARISSIMI, 2008)
3.4.3 Hyper-V
O Hyper-V é a aposta da Microsoft para atingir o mercado de virtualização
mais amplo. Este hypervisor é a sequência de softwares da família Microsoft,
voltados para o ambiente de virtualização. (CARISSIMI, 2008)
Antes do Hyper-V, softwares como Virtual PC e Microsoft Virtual Server
faziam a vez da Microsoft no nicho de mercado da virtualização. (CARISSIMI, 2008)
Baseado em Microsoft Windows 2008 Server, o Hyper-V conta com um
conjunto de ferramentas que visam facilitar e automatizar o processo de
virtualização. (CARISSIMI, 2008)
Exemplo destas ferramentas é Manager Physical-to-Virtual, responsável por
auxiliar a conversão de servidores instalados diretamente sob o hardware em
servidores virtuais, e também o Shadow Copy Services, que permite procedimentos
eficientes de backup e de alta disponibilidade dos recursos. (CARISSIMI, 2008)
O aspecto de segurança do Hyper-V recebeu atenção especial, podendo citar
a utilização do “execute-disable-bit”, mecanismo este existente nos novos
processadores e que diminui muito os ataques por vírus e outras ameaças.
(CARISSIMI, 2008)
Ainda dentro de ferramentas Microsoft outro aspecto de segurança é a
integração deste Hypervisor ao Active Directory (AD), fazendo assim uso das
políticas de segurança. (CARISSIMI, 2008)
42
4 IMPLEMENTAÇÃO
O desenvolvimento do ambiente neste trabalho foi feito de uma forma mais
aprofundada, sem abordar conceitos básicos de funcionamento e configuração de
ambiente. No decorrer deste capítulo foram utilizadas ferramentas específicas,
sendo descritas durante o desenvolvimento do trabalho.
Os manuais dos softwares utilizados neste trabalho podem ser encontrados
em seus sites oficiais e também nos manuais disponibilizados após a instalação
destes:
DRBD - http://www.drbd.org/docs/install/
Xen - http://wiki.xen.org/wiki/Category:Tutorial
Ganeti - http://docs.ganeti.org/ganeti/current/html/install.html
Toda a implementação foi feita em ambiente pré-virtualizado em Oracle
Virtual Box, instalado no sistema operacional Windows 7. Neste ambiente foram
criadas as máquinas virtuais necessárias para composição do cluster. Estas
máquinas virtuais têm características idênticas diferenciando-se unicamente por
configurações de comunicação em rede e identificação.
A figura 4.1 ilustra a arquitetura proposta e seus relacionamentos.
VM1
VM2
VM3
Hypervisor Xen
GANETI
DRBD
NODE1
Figura 4.1 – Diagrama da estrutura do cluster
Fonte: Elaborado pelo autor, 2012.
NODE2
43
A primeira máquina virtual foi nomeada node1, desempenha função de
membro do cluster e nó primário, sendo esta responsável em um primeiro momento
como ponto central de gerenciamento do cluster.
A segunda máquina virtual tem o nome de node2, sendo esta membro do
cluster com característica de membro secundário, pode em determinado momento
ou necessidade assumir a função de nó primário, executando assim as funções de
gerenciamento do ambiente.
A partir deste ponto cada nó é tratado como uma unidade autônoma, sem a
necessidade de mencionar que esta se encontra em um ambiente virtualizado.
Para implementação do cluster foram utilizados equipamentos virtualizados e
idênticos com as seguintes características:
1 processador
1024 mb de memória
1 disco rígido 10 GB para sistema operacional
1 disco rígido 30 GB para o volume de dados compartilhado pelo DRBD
1 placa de rede padrão 100/1000
O sistema operacional escolhido para a implementação do projeto foi o Linux
Debian Squeeze 64 bits, sua instalação foi feita sem qualquer pacote adicional ou
interface gráfica, isso disponibiliza um sistema operacional mais leve e enxuto.
Pacotes adicionais necessários para o funcionamento do projeto serão
adicionados com o andamento da implementação, através dos repositórios oficiais
da distribuição.
A escolha do sistema operacional é unicamente pessoal, podendo ser
utilizadas outras distribuições, resguardando apenas características operacionais e
comandos de cada uma.
Os sistemas operacionais das máquinas virtuais que serão instaladas no
cluster também farão uso do mesmo sistema operacional.
Os principais softwares utilizados foram:
DRBD 8 – Conforme já mencionado, este software tem a função de
compartilhar o volume de dados selecionados em cada membro do cluster.
Através deste é feita a sincronização dos volumes lógicos entre os
dispositivos, isso faz com que todos os nós tenham acesso às mesmas informações.
44
Este também garante a segurança e integridade do cluster, uma vez que os dados
se encontram replicados nas unidades físicas de cada membro do cluster.
Xen 4.0 amd64 – hypervisor de código aberto já mencionado anteriormente.
Cluster manager Ganeti – É uma ferramenta desenvolvida pela empresa
Google para gerenciamento de cluster, amplamente utilizada em sua estrutura de
clusters.
Ganeti-instance-debootstrap
0.9
–
responsável
por
gerar
o
sistema
operacional que fica hospedado no cluster, disponibiliza uma imagem básica para
download e instalação do Debian.
4.1
INSTALAÇÃO E CONFIGURAÇÕES INICIAIS
Como ponto inicial, todos os nós membros do cluster são considerados
inicializados e com comunicação entre si e para a internet, com isso, é preciso fazer
a instalação de pacotes que são necessários para o funcionamento da estrutura.
Não foram descritas as funcionalidades, pois não faz parte do escopo do
projeto, alguns softwares são pré-requisitos para o funcionamento de outros. A
instalação é feita através do comando #aptitude install seguido do nome do
software desejado.
Os pacotes necessários são:
- xen-linux-system
- drbd8-utils
- lvm2
- openssh
- bridge utilities
- iproute2
- arping
- ndisc6
- python, versão 2.4 superior, exceto 3.0
- python openssl bindings
- simplejson python module
- pyparsing python module
- pyinotify python module
- pycurl python module
- ctypes python module
45
- socat
- paramiko
4.1.1 Ganeti
Com a conclusão da instalação dos pacotes, é necessário efetuar a instalação
do gerenciador de cluster Ganeti. Esta instalação é feita através do download direto
do software e sua respectiva instalação. Alguns diretórios são necessários para
acomodação de funções, os comandos a seguir descrevem estas etapas:
# wget http://ganeti.googlecode.com/files/ganeti-2.4.2.tar.gz
# tar xvzf ganeti-2.4.2.tar.gz
# cd ganeti-2.4.2
# ./configure --localstatedir=/var --sysconfdir=/etc
# make
# make install
# mkdir /srv/ganeti
# mkdir /srv/ganeti/os
# mkdir /srv/ganeti/export
Deste ponto em diante todos os softwares necessários estão instalados,
agora pode-se iniciar o processo de configuração e inicialização do cluster e suas
instâncias.
4.1.2 Xen
Após a instalação do Xen na etapa inicial, algumas configurações e
procedimentos são necessários para seu perfeito funcionamento da infraestrutura
proposta.
Uma função importante a ser configurada é migração em tempo real das
máquinas virtuais entre os nós do cluster. Esta função permite a movimentação das
instâncias entre os nós do cluster para melhor adequação da estrutura, cópia destas
instâncias e recuperação de falhas caso algum dos nós do cluster apresente
problema.
46
Para
isto
é
necessário
modificar
as
configurações
do
arquivo
"/etc/xen/xen-config.sxp", fazendo a alteração ou inclusão das seguintes
entradas:
(xend-relocation-server yes)
(xend-relocation-port 8002)
(xend-relocation-address '')
(xend-relocation-hosts-allow '^10\\.0\\.0\\.[10-13]+$')
(vncpasswd '')
(vnc-listen '0.0.0.0')
A linha (xend-relocation-hosts-allow…) delimita o intervalo de IP´s
dos nós que participam do cluster. Esta configuração deve estar de acordo com o
escopo da rede.
Outro ponto importante nesta etapa de configuração é a definição das
configurações de hardware, sendo estes parâmetros assumidos pelo hypervisor
quando do início da estrutura. Deve se observar o limite da capacidade física dos
equipamentos que serão utilizados na composição do cluster.
Para a configuração do ambiente de teste, foi delimitado o uso de 1
processador e 1024 MB de memória, sendo estes parâmetros inseridos no arquivo
de configuração "/etc/default/grub" com a inserção das seguintes linhas:
GRUB_CMDLINE_XEN=dom0_mem=1024M maxcpus=1
Para a validação da alteraçãofeitas é necessário executar o seguinte
comando:
# update-grub2
Outro parâmetro necessário é a definição do kernel padrão para o dom0 e
para domU.
# ln -s /boot/vmlinuz-2.6.32-5-xen-amd64 /boot/vmlinuz2.6-xenU
47
# ln -s /boot/initrd.img-2.6.32-5-xen-amd64 /boot/initrd2.6-xenU
Após a reinicialização dos equipamentos, as novas opções de kernel iniciadas
são Xen 4.0.
4.1.3 Configuração DRBD
O DRBD trabalha em conjunto com o gerenciador de volumes LVM, faz com
que os volumes localizados em diferentes equipamentos trabalhem em RAID-1,
assim espelha as informações entre os volumes.
Na descrição inicial do ambiente onde foi delimitada a configuração de
hardware, em cada nó do cluster foi reservado uma unidade de disco de 30GB, para
utilização como volume compartilhado no DRBD. Esta unidade não pode ter
qualquer volume criado, fica a cargo do LVM criar este volume para então o DRBD
assumir o sincronismo das unidades.
Após a criação do volume este é entregue ao Ganeti, que é responsável pelo
gerenciamento do cluster e seus respectivos volumes.
O Ganeti por padrão tem um nome comum para buscar o volume do grupo,
sendo este necessariamente chamado de xenvg.
A criação deste volume é feito através do comando a seguir:
# pvcreate /dev/sda
# vgcreate xenvg /dev/sda
A partir deste ponto o volume criado por LVM e sincronizado pelo DRBD já
está pronto para gerenciamento pelo Ganeti.
4.1.4 Topologia de Rede
É preciso que todos os membros do cluster tenham em seus arquivos de
reconhecimento de nomes “/etc/hosts”, as configurações que indiquem os nomes e
IP´s de todos os nós envolvidos na estrutura, bem como cada sistema operacional
hospedado na camada de virtualização.
48
Ainda existe a necessidade de uma entrada como IP e nome que foi dado ao
cluster, sendo este IP responsável pela interface de gerenciamento do cluster.
As entradas para o arquivos de nomes são:
127.0.0.1 localhost
# node1 que participa fisicamente do cluster:
10.0.0.11 node1.google.com.br node1
# node2 que participa fisicamente do cluster:
10.0.0.12 node2.google.com.br node2
# vm1, vm2 e vm3 que são máquinas virtuais hospedadas:
10.0.0.20 vm1.google.com.br vm1
10.0.0.21 vm2.google.com.br vm1
10.0.0.22 vm3.google.com.br vm3
# endereço de acesso que gerencia o cluster:
10.0.0.100 cluster01.google.com.br cluster01
A utilização do domínio google.com.br é apenas uma ilustração do ambiente.
A interface de rede física foi modificada para trabalhar em modo bridge, onde
além de responder pelo próprio nó físico, também irá responder pelos IPs do cluster
e das máquinas virtuais. A modificação foi feita no arquivo /etc/network/.
Após a modificação, o conteúdo do arquivo referente à configuração de rede
no primeiro nó ficou da seguinte forma:
auto xen-br0
iface xen-br0 inet static
address 10.0.0.12
netmask 255.255.255.0
network 10.0.0.0
broadcast 10.0.0.255
gateway 10.0.0.1
bridge_ports eth0
bridge_stp off
bridge_fd 0
As configurações do segundo nó são semelhantes, resguardando as devidas
configurações para configuração da rede. Após esta etapa os nós estão habilitados
para comunicação, desta forma, torna-se apto para a configuração do DRBD
49
4.2
INICIALIZAÇÃO DO AMBIENTE
A inicialização do cluster é o primeiro passo para começar a operar o
ambiente, neste ponto é necessário informar quais equipamentos farão parte do
cluster e qual papel é desempenhado.
A definição de nó primário e secundário é necessária para informar ao cluster
de onde partem os comandos de gerenciamento do ambiente. Na estrutura proposta
o nó primário é denominado node1, enquanto o node2 é o secundário.
O gerenciador de cluster Ganeti possui um conjunto de comandos específicos
para gerenciamento dos nós do cluster e também das máquinas virtuais que nele
estejam em execução. A partir deste ponto as máquinas virtuais serão chamadas de
instâncias para melhor compreensão.
O Ganeti possui dois modos de operação, sendo o primeiro modo o xen-pvm
que dá suporte a paravirtualização do ambiente e o segundo modo o xen-hvm,
sendo este responsável por virtualização assistida por hardware.
Com o modo de suporte de paravirtualização, as instâncias devem ser
baseadas em sistemas operacionais modificáveis, ou seja, a camada de
virtualização pode modificar o sistema operacional, para melhor adequar e gerenciar
o funcionamento.
Para ambiente onde o sistema operacional não é modificável, é necessário
habilitar o modo de virtualização assistida por hardware, onde os conjuntos de
instruções contidos no processador darão auxilio na execução desta instância. Nesta
situação o hardware deve conter a tecnologia de suporte à virtualização em seu
hardware físico.
Durante a inicialização do cluster já é definida a característica de suporte a
virtualização, bem como quais nós farão parte do cluster. Posteriormente é possível
adicionar novos nós ao ambiente e também fazer a mudança de suporte da
virtualização.
O comando a seguir inicia o cluster com as características desejadas e com o
nome cluster1 para o ambiente.
# gnt-cluster init -H xen-pvm:kernel_path=/boot/vmlinuz2.6-xenU,initrd_path=/boot/initrd-2.6xenU,blockdev_prefix=xvd,root_path=/dev/xvda1 cluster01
50
Figura 4.2 – Inicialização do cluster
Fonte: Elaborado pelo autor, 2012.
Após a inicialização do cluster já é possível interagir com o ambiente criado.
Com o comando #gnt-cluster verify é possível verificar o estado da estrutura
do cluster.
Neste ponto o cluster já esta inicializado, entretanto, com um único nó. Este
nó assume a condição de nó primário e a partir dele é feito o gerenciamento dos nós
e instancias participamentes da infraestrutura.
A próxima etapa foi adicionar o segundo nó ao cluster, nó este identificado
como node2. O comando a seguir cria o nó secundário e passa como parâmetro a
opção de assumir a função de primário caso seja necessário, muitas vezes isto é
necessário casa ocorra alguma falaha no nó principal. Sem esta possibilidade o
cluster ficaria sem o nó principal de gerenciamento
# gnt-node add --master-capable=yes node2
Deste ponto em diante o cluster contém dois nós e seus volumes
compartilhados pelo DRBD já estão sincronizados. Todas as informações gravadas
por qualquer um dos nós serão automaticamente gravadas nas unidades
compartilhadas entre os equipamentos, permitindo a sempre disponibilização dos
dados gravados.
A figura 4.3 exibe a situação de funcionamento do cluster e seus respectivos
nós.
51
Figura 4.3 – Verificação do status do cluster
Fonte: Elaborado pelo autor, 2012.
O próximo passo é a criação de instâncias no cluster e a sua manipulação
entre os nós, isto é feito pelo comando a seguir:
# gnt-instance add -t drbd --disk 0:size=5g -B memory=128 -o
debootstrap+default -n node1:node2 vm2
gnt-instance add –t DRBD indica que a instância foi criada no volume DRBD.
--disk 0:size=5g indica que o tamanho do disco é de 5Gb.
-o debootstrap+default indica origem dos arquivos de instalação do sistema
operacional.
-n node1:node2 vm1 define os nós onde a instância pode ser alocada.
4.3
DEMONSTRAÇÃO DO AMBIENTE
4.3.1 Criação de Instâncias
Para simulação e teste do ambiente, foram feitos testes de migração de
instância entre os dois nós do cluster de acordo com as etapas descritas e exibidas
a seguir.
Como primeiro passo foram criadas três instâncias Linux no cluster, com
configurações conforme quadro 4.1.
Quadro 4.1 – Configuração das instâncias
52
Nome
vm1
vm2
vm3
IP
10.0.0.20
10.0.0.21
10.0.0.22
Memória
256 Mb
128 Mb
64 Mb
HD
10GB
4GB
2GB
Fonte: Elaborado pelo autor, 2012.
Todas as instâncias foram criadas com o nó primário node1 e com failover
em node2. Durante o processo de criação da instância a tela de progresso é exibida
pela figura 4.4.
Figura 4.4 – Progresso de criação de instância
Fonte: Elaborado pelo autor, 2012.
O comando #watch cat /proc/drbd, ilustrado pela figura 4.5, exibe
informações relativas à sincronização do volume de dados DRBD entre os nós do
cluster.
Figura 4.5 – Status DRBD
Fonte: Elaborado pelo autor, 2012.
Na figura 4.6 pode ser verificado o status, após criação das instâncias.
53
Figura 4.6 – Listagem inicial das instâncias
Fonte: Elaborado pelo autor, 2012.
Na figura 4.7 pode ser visto que a instância vm3 esta com status
ADMIN_down, isto é devido a mesma não ter sido iniciada após a sua criação. A
inicialização é feita através do comando mostrado pela figura 4.6.
Figura 4.7 – Incialização de instância
Fonte: Elaborado pelo autor, 2012.
Deste ponto em diante as instâncias já estão operacionais e pode comportar
serviços, sistemas e demais funções necessárias.
O acesso ao console de uma instância é feito através do comando mostrado
pela figura 4.8, neste caso foi feito acesso na instância vm1 e verificado seu sistema
de arquivos.
Figura 4.8 – Conexão ao console da instância.
Fonte: Elaborado pelo autor, 2012.
Para sair do console de determinada instância, é necessário pressionar as
teclas CTRL + ] simultaneamente.
54
4.3.2 Movimentação de Instâncias entre nós do Cluster
Após a criação das instâncias, as mesmas se encontram no node1 do cluster
e o segundo nó do cluster fica ocioso. A figura 4.9 ilustra esta situação.
Figura 4.9 – Diagrama cluster
Fonte: Elaborado pelo autor, 2012.
Para um cluster com características de alto desempenho e balanceamento de
carga, as instâncias precisam ser divididas entre os nós. Para simular este ambiente,
a instância vm2 é movimentada para o segundo nó.
O comando gnt-instance migrate é utilizado para migrar a instância
vm2, posicionando-a no nó secundário conforme pode ser visualizado pela figura
4.10.
Figura 4.10 – Migração de instância
Fonte: Elaborado pelo autor, 2012.
A figura 4.11 exibe a listagem das instâncias e é possível verificar a
modificação da instância vm2 do nó primário para o nó secundário.
55
Figura 4.11 – Listagem de instâncias após migração
Fonte: Elaborado pelo autor, 2012.
Este processo é rápido e a instância teve poucos segundos de parada
durante a transferência. Isto se deve ao fato de que o tempo necessário para
transferência é referente às mudanças de mapeamento e endereçamento de
memória, a base de dados sempre esta disponível através do DRBD.
Com esta migração caso node1 apresente problemas, a instância vm2
permanece em funcionamento. Também está garantido o maior aproveitamento dos
recursos de hardware, pois ambos nós desempenham função de processamento.
A figura 4.12 ilustra a nova situação do cluster:
Figura 4.12 – Diagrama cluster pós migração da VM2
Fonte: Elaborado pelo autor, 2012.
4.3.3 Simulação de Desligamento Programado do Nó Máster
As situações aqui exibidas ilustram os procedimentos tomados caso algum
dos nós do cluster tenha que ser desligado de forma planejada.
Este cenário tem como ponto de partida a necessidade de manutenção do
node1, mesmo com duas instâncias em operação.
Para este processo pode ser aplicada a situação anterior de migração de
instâncias, mas existe uma condição onde é possível fazer failover completo do nó.
56
Com o comando gnt-instace failover, todas as instâncias do node1
são migradas para o node2 ao mesmo tempo. Este processo é ilustrado pela figura
4.13.
Figura 4.13 – Migração de todas instâncias de um nó
Fonte: Elaborado pelo autor, 2012.
Após o processo é possível verificar que todas as instâncias estão alocadas
no node2, este procedimento é similar ao processo de migração, onde as instâncias
permanecem indisponíveis por pouco tempo, tendo como tempo médio 4 minutos
para a efetivação da migração de todas instâncias.
Antes que o node1 seja desligado é necessário informar ao cluster que
node2 é o novo nó master. Isto se faz necessário, pois todos os comandos de
gerenciamento do cluster necessariamente tem que ser feito a partir do nó máster.
Para este procedimento é necessário acessar o console do node2 e executar
os seguintes comandos:
# gnt-cluster masterfailover,
# gnt-cluster redist-info
O segundo comando informa ao node1 que existe um novo master no cluster,
automaticamente node1 é definido como secundário, não sendo possível executar a
administração do cluster a partir deste.
Com estes procedimentos executados é possível desligar node1 e a nova
estrutura das instâncias no cluster é ilustrada pela figura 4.14:
57
Figura 4.14 - Diagrama do cluster pós migração de todas intancias
Fonte: Elaborado pelo autor, 2012.
4.3.4 Simulação de Desligamento Não Programado do Nó Máster
Caso o nó master seja desligado de forma inesperada, a capacidade de
gerenciamento do cluster é perdida até que este nó seja restabelecido ou até que
seja definido que o nó secundário assuma esta posição de gerenciamento.
Outra questão a ser tratada nesta situação é o fato de que as instâncias que
se encontravam no nó master não foram migradas da forma convencional. Desta
forma será necessária a execução de failover forçado.
Para esta simulação é assumida a condição que node2 é o nó primário, nele
estão contidas as instâncias vm1 e vm3. Já o node1 é secundário e contém somente
a instância vm2, conforme ilustrado pela figura 4.15.
Figura 4.15 – Diagrama do cluster – simulação de falha
Fonte: Elaborado pelo autor, 2012.
Após o desligamento do node2 uma mensagem de erro é apresentada no
console do node1 esta mensagem informa que o nó primário está indisponível,
neste ponto as instâncias que estavam alocadas em node2 também estão
indisponíveis. A figura 4.16 ilustra a nova condição do cluster após o desligamento
do node2
58
Figura 4.16 - Diagrama do cluster pós falha no node2
Fonte: Elaborado pelo autor, 2012.
Diante desta situação é necessário tornar node1 o nó de gerenciamento do
cluster para permitir a execução de comandos de gerenciamento e posterior
recuperação das instâncias vm1 e vm3.
Para o início da recuperação é necessário acessar o console do node1 e
executar o comando:
# gnt-cluster masterfailover --no-voting.
O parâmetro --no-voting não verifica se existe outro nó primário, e força
node1 assumir a condição de gerenciamento.
Após este procedimento node1 torna-se nó primário, agora com as funções
de gerenciamento do cluster e das instâncias. Ainda têm-se as instância vm1 e vm3
paralisadas, pois estavam atribuídas ao nó que não esta mais operacional. A figura
4.17 exibe o atual status das instâncias que estavam alocadas em node2.
Figura 4.17 – Listagem de instâncias após falha de nó do cluster
Fonte: Elaborado pelo autor, 2012.
Como o volume de dados do DRBD é replicado entre todos os nós do cluster,
o node1 tem acesso às informações e dados das instâncias paralisadas, com isso é
possível fazê-lo assumir o controle destas instâncias.
59
O comando descrito a seguir força node1 inicializar as instâncias que
estavam em node2.
#gnt-node failover --ignore-consistency node2
Após este procedimento todas as instâncias criadas no cluster estão alocadas
no node1 e inicializadas, a figura 4.18 mostra o status das instâncias.
Figura 4.18 – Listagem de instâncias pós failover
Fonte: Elaborado pelo autor, 2012.
Ao se restabelecer, o node2 permanece no cluster com status de primário,
pois era sua condição no cluster quando foi desligado. A figura 4.19, ilustra o atual
status do cluster:
Figura 4.19 - Diagrama do cluster pós failover
Fonte: Elaborado pelo autor, 2012.
Para solucionar esta questão é necessário acessar o console do node1 e
executar o comando descrito a seguir que define node2 como secundário.
# gnt-cluster masterfailover
Também é necessário informar a todos nós do cluster qual a atual situação de
gerenciamento, isto é feito através do comando gnt-cluster redist-conf
60
Com isso, o cluster foi restabelecido e seus nós já podem gerenciar as
instâncias. Para exibir quem é o nó primário do cluster basta executar o comando
descrito a seguir.
# gnt-cluster getmaster
Este capítulo apresentou de uma forma prática e bem objetiva a configuração
de todos os softwares necessários para funcionamento do cluster e simulações de
alguns de seus recursos, é importante salientar que os capítulos anteriores serviram
de base para a implementação do cluster.
61
CONCLUSÃO
A proposta de utilização conjunta de virtualização com cluster permite
flexibilidade e garantia de entrega de serviços em um ambiente de TI e tem como
ponto chave a segurança das informações e a disponibilidade dos recursos.
O custo e eficiência deste ambiente são fatores determinantes para sua
aplicação. A utilização de softwares Open Source e a característica de hardwares
flexíveis determinam o baixo custo, o que sempre é levado em consideração em
qualquer projeto de infraestrutura de TI.
O DRBD é uma solução para armazenamento de dados, sua utilização
impacta diretamente no custo da infraestrutura e sua função é semelhante ao
funcionamento de uma unidade de Storage, que em sua grande maioria tem
elevados custos de aquisição e manutenção.
A manipulação da estrutura é muito dinâmica e versátil, o que é muito
importante em um ambiente de alta disponibilidade.
Para exemplificar os resultados obtidos, vale citar os tempos de manipulação
e parada das instâncias no cluster. Todo o processo de migração de uma
determinada instância entre os nós do cluster teve tempo médio de 36 segundos na
execução total do processo, com perca média de 3 pacotes do comando ping que
fazia o monitoramento da disponibilidade. A quantidade de pacotes perdidos durante
o monitoramento por ping mostra que a instância ficou pouco tempo indisponível.
Estes resultados são expressivos porque denotam a alta disponibilidade dos
recursos.
Outra característica importante obtida foi o maior aproveitamento da
capacidade de processamento da estrutura. As instâncias podem ser alocadas de
acordo com a capacidade de processamento de cada nó do cluster, assim maximiza
o aproveitamento dos recursos de hardware disponíveis.
Ao alcançar os objetivos do projeto, foi possível avaliar o quanto esta solução
atende as necessidades do ambiente que busca garantia e eficiência dos recursos
de TI. Os resultados ilustram o que qualquer ambiente que depende de tecnologia
de informação pode esperar da infraestrutura e entrega de serviços e recursos.
A operação das funções de gerenciamento das instâncias se torna fácil e
intuitivo com a utilização do Ganeti.
62
No ambiente proposto algumas características e funções não foram
implementadas, tais como failover automáticos das instâncias, tolerância a falhas e
comunicação com o ambiente externo ao cluster. As limitações se devem
exclusivamente ao ambiente onde foi realizada a implementação.
O cenário ideal é a utilização de equipamentos físicos reais e não máquinas
virtuais criadas no sistema operacional Windows 7 em hardware limitado de um
notebook, sendo este fator determinante nas limitações da arquitetura.
Para comunicação com o meio externo ao cluster é necessário modificar a
topologia de rede e utilizar um roteador para reconhecimento e acesso as rotas.
De posse de uma estrutura de hardware mais robusta, funções como failover
automático das instâncias e tolerância a falhas podem ser implementadas.
O failover automático faz com que as instâncias alocadas em um nó, sejam
migradas automaticamente para outro nó caso ocorra uma falha inesperada, a
documentação oficial do Ganeti indica a configuração do Out of Band (OOB) para
satisfazer esta necessidade, sendo isto passível de aplicação em projetos futuros.
Outra função de melhoria seria a instalação do módulo Remus para garantir
tolerância a falhas, onde o objetivo é zerar o tempo de parada de instância caso
ocorra alguma falha em qualquer membro do cluster. Segundo a documentação
oficial, esta função acaba por exigir elevada capacidade de comunicação dos
membros do cluster, uma vez que as instruções de memoria e processador são
sincronizadas em tempo real entre os nós.
A arquitetura proposta foi implementada sobre a ferramenta de virtualização
Virtual Box, o que causou bastante dificuldade e limitação da capacidade de
processamento e comunicação da estrutura com o meio externo ao ambiente.
Como a aplicação conjunta de cluster e virtualização é um tema recente
existe pouco material de referência disponível, o que se torna um fator de dificuldade
porque a utilização somente de referências técnicas dos fornecedores eleva o grau
de dificuldade no entendimento e aplicação dos softwares relacionados.
Para futuros projetos, além da implementação das funções dos softwares
Remus e OOB conforme já citado, seria de grande importância elaborar um
comparativo entre o funcionamento da virtualização sobre cluster frente a
virtualização diretamente sobre um servidor físico.
Este comparativo levaria em consideração a performance obtida em
determinada função ou serviço alocados na infraestrutura em questão. Este
63
resultado pode ser determinante na adoção da arquitetura ou mesmo qualificar quais
aplicações podem ser utilizadas em cada um dos cenários.
64
REFERÊNCIAS
ANTERIO. High Performance Computing Cluster (HPC Cluster). 2012. Disponível
em: <http://www.anterio.com/index.php?id=170> Acesso em: 20 Jun. 2012.
ANTONOPOULOS, Andreas M.. Virtualization and clustering: combining two
winning
strategies.
2005.
Disponível
em:
<http://www.networkworld.com/newsletters/2005/0404datacenter1.html> Acesso em:
20 Nov. 2012.
BLOKDIJK, Gerard; MENKEN, Ivanka. Virtualization: The Complete Cornerstone
Guide to Virtualization Best Practices: Concepts, Terms, and Techniques for
Successfully Planning, Implementing and Managing Enterprise It Virtualization.
2. ed.: Emereo Pty Limited, 2008.
CARISSIMI; A. Virtualização: da teoria a soluções. Minicurso do 26º Simpósio
Brasileiro de Redes de Computadores e Sistemas Distribuídos, 2008 Rio de Janeiro.
Disponível em: <http://www.gta.ufrj.br/ensino/CPE758/artigos-basicos/cap4-v2.pdf>
Acesso em: 12 nov. 2011.
CLOUD. Esquema do Alojamento "Cloud". 2010. Disponível
http://www.3abytes.com/Alojamento/Cloud> Acesso em: 07 Jun. 2011.
em:
<
COULOURIS, George, DOLLIMORE, Jean, KINDBERG, Tim. Sistemas
Distribuídos – Conceitos de Projeto. 4. ed. Porto Alegre: (Bookman), 2007.
HAMC. Introdução à Alta Disponibilidade: Heartbeat e DRBD. 2008. Disponível
em: < http://ha-mc.org/node/15> Acesso em: 20 Jun. 2011.
HELLMAN, B. et al. DRBD Users’s Guide. 2012. Disponível
<http://www.drbd.org/docs/introduction> Acesso em: 20 nov. 2012.
em:
MORIMOTO,
Carlos
E.
Clustering.
Disponível
em:<http://www.hardware.com.br/termos/clustering> Acesso em: 09 Jun. 2011.
PITANGA, Marcos. Computação em Cluster. 2003. Disponível em:
http://www.clubedohardware.com.br/artigos/Computacao-em-cluster/153/1> Acesso
em: 05 Jun. 2011.
PITANGA, Marcos. Computação em Grade - Uma Visão Introdutória. 2004.
Disponível em: <http://www.clubedohardware.com.br/artigos/124/2> Acesso em: 08
Jun. 2011.
PITANGA, Marcos. Construindo supercomputadores com Linux. 3. ed. Rio de
Janeiro: Brasport, 2008.
SALLES, D. et al. Cluster HPC – High Performance Computing. Artigo da
disciplina de Sistemas Distribuídos. Faculdade de Tecnologia de Guaratinguetá,
2009. Disponível em:<http://www4.fct.unesp.br/ronaldo/uploads>
65
SALUSTINO, Alex. Computação em nuvem. 2012. Disponível em:
<http://divulgabiblio.blogspot.com.br/2012/11/computacao-em-nuvem.html> Acesso
em: 01 Dez. 2012.
SLTI , Secretaria de Logística e Tecnologia da Informação. Guia de Estruturação e
Administração do Ambiente de Cluster e Grid. Brasília, 2006.
TANENBAUM, Andrew S., STEEN, Maarten Van. Sistemas Distribuídos –
Conceitos e Paradigmas. 2. ed. São Paulo: Person, 2007.
VERAS, Manoel. Virtualização – Componente Central do Datacenter. 1. ed. Rio
de Janeiro: Brasport, 2011.