1
Universidade do Estado do Rio de Janeiro
Centro de Ciência e Tecnologia
Faculdade de Engenharia
Alexandre Ribeiro Freitas
Daniele Melo Nunes
Análise de Desempenho de Redes Usando Máquinas Virtuais
Rio de Janeiro
2013
1
Alexandre Ribeiro Freitas
Daniele Melo Nunes
Análise de Desempenho de Redes Usando Máquinas Virtuais
Projeto de graduação apresentado, como
apresentado
como
exigência
para
conclusão do curso de Engenharia de
Telecomunicações da Universidade do
Estado do Rio de Janeiro.
Orientador: Prof. D. Sc. Michel Pompeu Tcheou
Coorientador: Prof. M. Sc. Felipe da Rocha Henriques
Rio de Janeiro
2013
1
CATALOGAÇÃO NA FONTE
UERJ / REDE SIRIUS / BIBLIOTECA CTC/B
F866 Freitas, Alexandre Ribeiro.
Análise de Desempenho de Redes Usando
Máquinas Virtuais/ Alexandre Ribeiro Freitas,
Daniele Melo Nunes. – 2013.
105f.
Orientador: Michel Pompeu Tcheou.
Coorientador: Felipe da Rocha Henriques.
Projeto Final (Graduação) - Universidade do
Estado do Rio de Janeiro, Faculdade de
Engenharia.
Bibliografia p.82-84.
1. Engenharia eletrônica. 2. Telecomunicações.
3. Redes de computadores. 4. Virtualização. I.
Nunes, Daniele Melo. II. Tcheou, Michel Pompeu.
III. Universidade do Estado do Rio de Janeiro. IV.
Título.
CDU 621.38+39
Autorizo, apenas para fins acadêmicos e científicos, a reprodução total ou parcial
desta tese, desde que citada a fonte.
Assinatura
Data
Alexandre Ribeiro Freitas e Daniele Melo Nunes
Análise de Desempenho de Redes Usando Máquinas Virtuais
Projeto de graduação apresentado, como
apresentado como exigência para conclusão do
curso de Engenharia de Telecomunicações da
Universidade do Estado do Rio de Janeiro.
Aprovado em:
Banca Examinadora:
______________________________________________________________
Prof. Michel Pompeu Tcheou, D. Sc., UFRJ (Orientador)
Faculdade de Engenharia - UERJ
______________________________________________________________
Prof. Felipe da Rocha Henriques, M. Sc., UERJ (Coorientador)
Centro Federal de Educação Tecnológica Celso Suckow da Fonseca –
CEFET/ UnED Petrópolis
______________________________________________________________
Prof. Lisandro Lovisolo, D. Sc., UFRJ
Faculdade de Engenharia - UERJ
______________________________________________________________
Prof. Marcelo Gonçalves Rubinstein, D. Sc., UFRJ
Faculdade de Engenharia - UERJ
Rio de Janeiro
2013
AGRADECIMENTOS
Agradeço a Deus pelo Seu grande amor por mim, por todas as oportunidades,
pela capacitação e força para superar os desafios. Aos meus amigos que com
paciência e compreensão compreenderam os dias de ausência. Aos meus familiares
que com compreensão e incentivo me ajudaram a passar por todas as dificuldades.
A minha mãe, Maryuse, pelo amor incondicional, pela força e compreensão nos
momentos de desespero. A minha namorada, Lílian Arcanjo, pois sem o seu apoio,
compreensão, carinho e incentivo, nada disso teria sido possível. Agradeço também
ao nosso orientador Michel Tcheou pela ajuda sem medidas e também por todos os
momentos de compreensão, incentivo e paciência. Ao nosso coorientador Felipe da
Rocha pela paciência e compreensão. E por fim ao professor Lisandro Lovisolo por
ceder o laboratório PROSAICO para a realização dos testes.
Alexandre Ribeiro Freitas
AGRADECIMENTOS
Em primeiro lugar, agradeço a Deus por ter me dado à oportunidade de estar
aqui e por ter me dado ao longo desses anos força, persistência, flexibilidade e
inteligência emocional para chegar até está etapa. Em segundo, agradeço a minha
família por ter me proporcionado educação e me dado incentivo, base emocional e
financeira e a todos os colegas que tiveram a consideração, a generosidade de
compartilhar o conhecimento, sem ajuda deles esse sonho não seria possível.
Agradeço ao meu companheiro, Elton Braz, pelo incentivo, conselhos e pela
compreensão e a minha dupla de projeto, Alexandre Ribeiro Freitas, que através
desses anos lutou ao meu lado. Acreditamos num sonho e fomos atrás do nosso
objetivo, objetivo este que se realiza na concretização desse trabalho de final de
curso. Não podemos deixar de agradecer ao nosso orientador Michel Tcheou que foi
um líder, e exerceu sua liderança participativa nos guiando com muita humildade e
sabedoria aos caminhos certos para a realização desse sonho.
Daniele Melo Nunes
RESUMO
A Internet, da forma como se encontra hoje, já se expandiu em todos os seus
âmbitos, e deverá buscar uma nova estratégia para atender as aplicações e
necessidades de seus clientes. É neste contexto que se realizam estudos de
arquiteturas alternativas para a Internet do futuro e a virtualização de redes mostrase uma importante ferramenta para a nova arquitetura da Internet. O objetivo deste
trabalho está em criar máquinas virtuais através da ferramenta de virtualização
denominada Xen Cloud Platform e interconectá-las, bem como, verificar e analisar
as vantagens e desvantagens deste modelo em comparação com máquinas sem a
presença de virtualização. Ao longo deste trabalho será visto desde a instalação até
a configuração das máquinas virtuais e por fim irá se avaliar com a ferramenta iperf o
desempenho da rede com máquinas virtuais.
Palavras-chave: Virtualização. Redes de computadores. Xen Cloud Platform.
ABSTRACT
‪
The Internet in the way we know today has already
‪expanded in several
scopes ‪and must found new strategies to fulfill the applications and needs of the
customers.‪ ‪In this context, studies of alternatives architectures for future Internet are
being carried out and network virtualization is becoming an important tool to develop
new Internet architectures. The purpose of this work is to create ant interconnect
computer networks using virtual machines through the
‪Xen Cloud Platform‪
virtualization tool as well as to identify advantages and disadvantages of this
approach with respect to networks without the use of virtualization. Throughout this
work it will be demonstrated how to install and set up virtual machines. In the end, we
will evaluate the performance of the network with virtual machines by using the Iperf
tool.
‪
‪
Keywords: Virtualization. Network. Xen Cloud Platform.
LISTA DE IUSTRAÇÕES
Figura 1- Meios físicos presentes na Internet............................................................ 16
Figura 2 - As sete camadas do modelo OSI [19]. ...................................................... 18
Figura 3 - Comparação entre as camadas do Modelo OSI e do Modelo TCP/IP[20].
........................................................................................................................... 20
Figura 4 - Formato do datagrama IPv4 [3]. ............................................................... 25
Figura 5 - Cabeçalho do segmento UDP. .................................................................. 28
Figura 6 - Cabeçalho do segmento TCP [3]. ............................................................. 30
Figura 7 - Arquitetura cliente-servidor. ...................................................................... 32
Figura 8 - Arquitetura P2P. ........................................................................................ 33
Figura 9 - Arquitetura híbrida cliente servidor/P2P .................................................... 33
Figura 10 - Estrutura básica de um sistema virtualizado. .......................................... 41
Figura 11 - Sistema virtualizado [27]. ........................................................................ 43
Figura 12 - Estrutura da Virtualização total [10]. ....................................................... 44
Figura 13 - Esquema da paravirtualização [10]. ........................................................ 46
Figura 14 - Relação entre o hypervisor, Dom0 e DomU [2]. ...................................... 49
Figura 15 - Estrutura de funcionamento do XCP [14]. ............................................... 50
Figura 16 - Arquitetura Xen[22]. ................................................................................ 51
Figura 17 - Interfaces do Xen [29]. ............................................................................ 54
Figura 18 - Modos de rede virtual [12]. ...................................................................... 58
Figura 19 – Tabela de comparação entre o modo bridge e o modo de roteamento
[12]. .................................................................................................................... 59
Figura 20 - Interface‪‪“vif1.0”. .................................................................................... 61
Figura 21 - Interface eth0. ......................................................................................... 61
Figura 22 - Interfaces backend vif e frontend vif do domínio hóspede [12]. .............. 62
Figura 23 - Driver virtual funcionando no modo bridge [12]. ...................................... 63
Figura 24 - Resultado do comando traceroute. ......................................................... 63
Figura 25 - Comando brctl show na máquina virtual. ................................................ 64
Figura 26 - Topologia do Xen em seu modo de roteamento [12]. ............................. 64
Figura 27 - O comando ping não recebe resposta. ................................................... 65
Figura 28 - Domínio hóspede comunicando-se com a Internet. ................................ 66
Figura 29 - Esquema do funcionamento em modo NAT [14]..................................... 67
Figura 30 - Interface gráfica do XenCenter. .............................................................. 69
Figura 31 - Ambiente de teste CRSR – C2S1. .......................................................... 71
Figura 32- Ambiente de teste CRSR – C1S2. ........................................................... 71
Figura 33 - Ambiente de teste CRSV – C2S1. .......................................................... 72
Figura 34 - Ambiente de teste CVSR – C1S2. .......................................................... 72
Figura 35 - Ambiente de teste CVSR – C2S1. .......................................................... 73
Figura 36 - Ambiente de teste CRSV – C1S2. .......................................................... 73
Figura 37 - Ambiente de teste CVSV – C2S1............................................................ 74
Figura 38 - Ambiente de teste CVSV – C1S2............................................................ 74
Figura 39 - Gráfico de Vazão usando o Iperf/TCP considerando o PC1 como
servidor. ............................................................................................................. 75
Figura 40 - Gráfico de Vazão usando o Iperf/TCP considerando o PC1 como cliente.
........................................................................................................................... 76
Figura 41 - Gráfico do Jitter usando o Iperf/UDP, considerando o PC1 como servidor.
........................................................................................................................... 77
Figura 42 - Gráfico do Jitter usando o Iperf/UDP, considerando o PC2 como servidor.
........................................................................................................................... 78
INTRODUÇÃO ............................................................................................... 10
1.
CONCEITOS DE REDES DE COMPUTADORES ......................................... 15
1.1
Modelo OSI .................................................................................................... 17
1.2
Modelo TCP/IP .............................................................................................. 19
1.2.1 Camada Física ................................................................................................ 21
1.2.2 Camada de Enlace ......................................................................................... 21
1.2.3 Camada de Rede ............................................................................................ 23
1.2.4 Camada de Transporte ................................................................................... 26
1.2.5 Camada de Aplicação ..................................................................................... 32
1.3
Métricas de Desempenho ............................................................................ 37
2.
VIRTUALIZAÇÃO .......................................................................................... 38
2.1
Conceitos de Virtualização .......................................................................... 40
2.2
Tipos de Virtualização .................................................................................. 44
3.
FERRAMENTAS DE VIRTUALIZAÇÃO ........................................................ 47
3.1
Xen Cloud Platform ...................................................................................... 47
3.1.1 Arquitetura do XCP. ........................................................................................ 51
3.1.2 Configuração de Redes no XCP ..................................................................... 56
3.2
Virt-manager ................................................................................................. 68
3.3
XenCenter...................................................................................................... 69
4.
RESULTADOS EXPERIMENTAIS ................................................................. 70
4.1
Ambientes de testes. .................................................................................... 71
4.2
Resultados .................................................................................................... 74
5.
CONCLUSÃO ................................................................................................. 79
5.1
Discussão sobre o Xen ................................................................................ 79
5.2
Análise dos resultados ................................................................................ 80
5.3
Trabalhos Futuros ........................................................................................ 81
REFERÊNCIAS .............................................................................................. 82
APÊNDICE A.................................................................................................. 85
APÊNDICE B: INSTALAÇÃO DO XEN CLOUD PLATFORM. ...................... 86
APÊNDICE C: INSTALAÇÃO DA MÁQUINA VIRTUAL NO CITRIX
XENCENTER. ................................................................................................. 98
10
Introdução
A ARPANET1(Advanced research Project network), desenvolvida na época da
guerra fria, foi a primeira rede de comutação por pacotes e tinha como objetivo, ser
uma rede altamente distribuída e tolerante a falhas [1]. Com o crescimento da
ARPANET, surgiram problemas aparentes de interconexão de diferentes redes.
Nesse contexto surgiu o conceito de gateways2, e a proposta do TCP3 (Transmission
Control Protocol) que visava tratar e recuperar erros de transmissão e falhas de
sequenciamentos de pacotes. O programa também visava o endereçamento de nós
e encaminhamento de pacotes. Posteriormente o TCP foi dividido em dois
protocolos, o TCP, e o IP4(Internet Protocol). Assim nascia o modelo em camadas
TCP/IP tornando-se o modelo de referência da arquitetura da Internet [1].
O modelo da Internet como vemos hoje, foi desenvolvido a partir de alguns
principios [1-4], como:

modelo em camadas: cada camada possue funções específicas e presta
serviços a camada superior. Isso reduz a complexidade do sistema e
permite que diferentes tecnologias compartilhem dados entre sí;

comutação de pacotes e melhor esforço: a técnica de datagrama5
utilizada na comutação por pacotes visa a busca por um caminho
alternativo enquanto ocorrer uma falha na infraestrutura existente. A idéia
de melhor esforço é que os pacotes sejam entregues da forma como for
possível;
1
Desenvolvida pela agência Americana ARPA (Agência de Pesquisas em Projetos Avançados)
em 1969. O objetivo ara interligar as bases militares e os departamentos de pesquisa do governo
americano.
2
Elemento de rede utilizado para interconexão de diferentes redes.
3
Protocolo da camada de transporte do modelo TCP/IP.
4
Protocolo da camada de rede do modelo TCP/IP.
5
Unidade de transferência básica de dados, associada a uma rede de comutação de pacotes em que
não há garantia de entrega.
11

princípio fim-a-fim: implica uma rede com núcleo simples e inteligência
nas pontas;

entrega imediata: visa a entrega imediata na ausência de falhas e
sobrecargas da rede;

endereçamento global: consiste em um endereçamento hierárquico que
permite a tomada de decisões no encaminhamento de pacotes. O
endereço IP além de identificar os nós, provê uma forma conveniente de
localização global;
O fato da estrutura da Internet ser simples possibilitou o grande avanço da
mesma como vemos hoje, de modo que pessoas de diferentes países e culturas a
utilizam de diversas formas. Contudo, essa‪ simplicidade‪ acaba‪ por‪ “engessar”‪ a‪
Internet colocando restrições no desenvolvimento de aplicações, assim ela tem
evoluído através de pequenas melhorias. Essas melhorias estão modificando o
projeto inicial da Internet, gerando alguns problemas estruturais [1-4], como:

endereçamento: com o aumento de dispositivos móveis e a grande
demanda da população mundial, o endereço de 32 bits (IPv4 6) tornou-se
insuficiente. Para reduzir a escassez de endereços, foram introduzidos
alguns protocolos, entre eles, o DHCP7 (Dynamic Host Configuration
Protocol), e o NAT8 (Network Address Translation). Esses protocolos têm
aumentado a sobrevida da Internet, porém essas alternativas restringem o
desenvolvimento de aplicações e vão contra os princípios da Internet.
Como alternativa para este problema foi proposto o IPv6 (Internet Protocol
versão 6). Entretanto, a implementação do IPv6 tem sido um desafio, isto
porque existem problemas de compatibilidade entre ele e o IPv4 [1];

segurança: a cada dia surgem novas formas de ameaça na Internet,
como disseminação de vírus e ataques de negação de serviço. Existe uma
6
É a quarta versão do Protocolo IP. Utiliza 32 bits para o endereçamento.
7
Protocolo de serviço TCP/IP que oferece configuração dinâmica de terminais, com concessão de
endereços IP.
8
Técnica em que o dispositivo de uma rede interna, recebem um IP válido para acessar a Internet.
12
guerra entre a defesa de sistemas e hackers que se aproveitam da
fragilidade de um sistema que cresceu sobe demanda e não se armou
para as ameaças. As formas de ataque estão cada vez mais sofisticadas e
se adaptam aos sistemas de defesa. Quando a Internet foi projetada, a
ideia inicial era que os problemas de segurança deveriam ser tratados
pelas estações finais. No entanto, devido aos ataques distribuídos de
negação de serviço (Distributed Denial-of-Service-attacks-DDoS), surgiu a
necessidade de alguns mecanismos de segurança serem providos pelo
núcleo da rede.
Outro problema é a segurança em roteadores. No caso do protocolo
BGP9 (Border Gateway Protocol), por exemplo, existe uma chave que é
trocada a cada par de roteadores vizinhos. Essa medida dita quais
roteadores podem trocar informações, porém não impede que informações
sejam inseridas de forma maliciosa por outros roteadores;

mobilidade: no meio sem fio a perda de pacotes devido a mobilidade
pode ser mal interpretada, porque o TCP assume que a perda de pacote
ocorre devido ao congestionamento da rede e saturação dos buffers10 nos
roteadores. O custo do congestionamento é decorrente dos segmentos
reenviados pelo transmissor. Se a retransmissão ocorre de forma
prematura, o receptor receberá cópias do segmento gerando tráfego sem
necessidade. Outro problema pode ocorrer no handover11. Quando um
dispositivo muda de ponto de acesso, ocorre uma requisição de endereço
IP. Nesse contexto, percebe-se que o conceito da Internet perdeu sua
9
Protocolo de roteamento dinâmico utilizado para a comunicação entre ASs (Autonomous System).
Cada provedor de Internet (Internet Service Provider) gerencia um AS, conectando o cliente a outros
provedores de serviço. O gerenciamento de todos os As é feito de forma independente dos outros,
dando a vantagem de escolhas do protocolo de roteamento a ser utilizado, escolha nas políticas de
gerenciamento e os tipos de serviços prestados [1-4].
10
Região da memória temporária utilizada para o armazenamento de dados.
11
Procedimento empregado em redes sem fio para tratar a transição de uma unidade móvel de uma
célula para outra.
13
originalidade, pois inicialmente, os dispositivos mantêm as suas conexões
constantes sem que haja perda de dados.
Pode-se concluir que a Internet, da forma como se encontra hoje, já se
expandiu em todos os seus âmbitos, e deverá buscar uma nova estratégia para
atender de forma escalável as aplicações e necessidades de seus consumidores. É
neste contexto que se realizam estudos de arquiteturas alternativas para a Internet
do futuro, atendendo a alguns desafios [1-3,5], como:

suporte à novas tecnologias de rede;

alto nível de segurança;

garantia na qualidade de serviço;

eficiência energética;

separação entre planos de controle e gerenciamento de dados;

isolamento;

mobilidade;

escalabilidade.
Um dos requisitos fundamentais contidos nesta proposta está na questão da
flexibilidade. Esse requisito tem dividido a opinião dos pesquisadores, em duas
abordagens [1,2,5-8]:
2. Abordagem Purista: defende a melhoria a longo prazo, idealizando uma
arquitetura de
rede completamente nova e produzida sem ter como
arquitetura base a Internet. Nesse contexto, a virtualização de redes seria
somente um conjunto de ferramentas que seriam utilizadas para atender aos
desafios da Internet do Futuro;
2. Abordagem Pluralista: defende melhorias em curto prazo. Essa nova
arquitetura suportaria uma pilha de protocolos, desencadeando uma migração
suave. Técnicas de redes sobrepostas e de virtualização tornam-se cruciais
graças à necessidade de se permitir a coexistência em paralelo de múltiplas
arquiteturas de protocolos. Nesse contexto arquiteturas para virtualização,
14
como o XCP12(Xen Cloud Platform), permitem que cada máquina virtual
possa operar como um roteador virtual, com propriedade e pilhas de
protocolos distintas[1,2,5-17].
Assim, a virtualização de redes, mostra-se como uma importante ferramenta
de testes para a nova arquitetura da Internet.
Este trabalho tem como objetivo criar máquinas virtuais através da ferramenta
de virtualização denominada Xen Cloud Platform e interconectá-las, bem como,
verificar e analisar as vantagens e desvantagens deste modelo em comparação com
máquinas sem a presença de virtualização. Para avaliação de desempenho da rede,
serão realizados testes como, vazão da rede, perda percentual de pacotes, taxa de
entrega de pacotes e Jitter13.
No Capítulo 2, são apresentados os conceitos de rede de computadores.
No Capítulo 3, são apresentados conceitos de virtualização.
No Capitulo 4, é feita uma exposição sobre as ferramentas utilizadas neste
projeto: Xen Cloud Platform, virt-manager, XenCenter e Iperf.
No Capítulo 5, são apresentados os ambientes de testes além de comentários
sobre os resultados encontrados.
No Capítulo 6, apresenta-se a conclusão do projeto e possíveis propostas
para projetos futuros.
12
Plataforma aberta de virtualização.
13
Variação de atraso entre pacotes.
15
1. Conceitos de redes de computadores
As redes de dados são redes digitais que são utilizadas para enviar dados
entre dispositivos. Para que a transmissão destes dados seja feita de maneira
satisfatória, é necessário que estas redes estejam interligadas. As redes, os dados
e as informações podem variar de tamanho e também em quantidade, entretanto
todas as redes possuem alguns elementos básicos em comum, como:
A. regras para definir como as mensagens são enviadas, direcionadas ou recebidas e
também interpretadas;
B. mensagens ou unidades de informação que trafegam de um dispositivo para outro;
C. interligação entre os dispositivos para que haja o transporte de mensagens;
D. dispositivos que trocam mensagens entre si.
Os dispositivos acima mencionados podem ser utilizados tanto para
transmitir e receber dados, como também para redirecioná-los dentro da rede.
Esses dispositivos podem ser switches14, roteadores15, computadores, entre outros.
Comumente, os dispositivos finais de uma rede são mencionados como hosts,
podendo ser tanto de origem como de destino de uma mensagem.
Para que uma rede funcione, os dispositivos precisam estar conectados entre
si. As conexões podem ser com fio ou sem fio. Em conexões cabeadas, pode-se
utilizar o cobre ou fibra óptica. Nas conexões sem fio o meio físico é a atmosfera
terrestre, ou seja, a transmissão dos dados é feita através de ondas
eletromagnéticas. Em um percurso pela Internet a mensagem pode trafegar por
14
Switches são dispositivos que filtram e encaminham pacotes entre segmentos (sub-redes) de redes
locais.
15
Equipamento que realiza a comunicação entre diferentes redes de computadores, ou seja, ele
permite a comunicação entre computadores distantes entre si.
16
meio de uma variedade de meios físicos. A Figura 1 mostra alguns exemplos de
meio físico.
Figura 1- Meios físicos presentes na Internet.
Enviam-se e recebem-se mensagens por meio de serviços como e-mail, envio
de mensagens instantâneas, World Wide Web (www) e telefonia IP. Para que estes
serviços possam ser fornecidos pelos dispositivos, eles devem ser governados pelos
chamados protocolos, que nada mais são que um conjunto de regras. Atualmente o
padrão da indústria é um conjunto de protocolos chamado TCP/IP (Transmission
Control Protocol/ Internet Protocol), sendo a principal pilha de protocolos da Internet.
A pilha TCP/IP especifica os mecanismos de formatação dos protocolos, roteamento
e consequentemente de endereçamento dos hosts que permitem que as mensagens
sejam enviadas ao receptor correto.
Os protocolos são regras para a comunicação entre dispositivos para que
uma mensagem seja enviada ao seu destino. Entretanto, para que uma
determinada requisição seja completada, é necessária a interação de diversos
protocolos. Essa interação entre os protocolos é melhor entendida através do
modelo em camadas.
A divisão através de um modelo em camadas auxilia na criação do protocolo,
impede que alterações de tecnologia de uma camada afetem outras camadas e
17
fornece um idioma único para descrever as funções e as capacidades da rede. Um
modelo em camadas descreve a operação dos protocolos dentro de cada camada,
bem como a interação entre uma camada superior e inferior.
Existem dois tipos básicos de modelos de rede: modelos de protocolo e
modelos de referência.
Um modelo de referência fornece uma referência comum para uma
consistente manutenção dentro de todos os tipos de protocolos de rede e serviços.
Um modelo de referência não tem a intenção de ser uma especificação de
implementação ou de fornecer em nível suficiente de detalhe para definir de
maneira precisa os serviços da arquitetura de rede. O principal propósito de um
modelo de referência é o de auxiliar em um entendimento mais claro das funções e
processos envolvidos.
O modelo de referência OSI (Open Systems Interconnection) é o modelo de
referência de rede mais amplamente conhecido. Ele é usado para a elaboração de
rede de dados, especificações de operação e resolução de problemas.
Um modelo de protocolo é definido com base no modelo de referência onde
em cada camada é descrito um conjunto de protocolos específicos. O conjunto
hierárquico de protocolos representa tipicamente toda a funcionalidade necessária
para fazer a interface do homem com a rede de dados. O modelo TCP/IP é um
exemplo de modelo de protocolo
Embora os modelos TCP/IP e OSI sejam os modelos básicos usados ao se
discutir funcionalidades de rede, os projetistas de protocolos de rede, serviços ou
dispositivos, podem criar seus próprios modelos para representar seus produtos.
Essencialmente, os projetistas precisam se comunicar com a indústria relacionando
seu produto ou serviço com o modelo OSI ou com o modelo TCP/IP, ou com
ambos.
1.1 Modelo OSI
O modelo OSI (Open Systems Interconnection) foi aprovado pela
Organização Internacional de Normatização (ISO - International Organization for
Standardization) no início da década de 80, para ser um modelo de referência com
18
o intuito de permitir a comunicação entre máquinas, mesmo que de diferentes
fabricantes [3,4].
O modelo OSI oferece uma lista de funções e serviços que podem ocorrer em
cada camada. As camadas do modelo OSI estão representadas na Figura 2.
Figura 2 - As sete camadas do modelo OSI [19].
Camada 1 – Camada Física: Responsável pela transmissão binária entre
terminais fisicamente interligados. Nesta camada, são definidas as interfaces físicas
e elétricas dos dispositivos de rede;
Camada 2 – Cama de Enlace: Provê uma forma eficiente de transmissão
binária para a camada de Rede. Reúne um conjunto de bits em um quadro. Além
disso, na camada de enlace, pode haver confirmação da entrega dos quadros. Há
19
também controle de fluxo, de modo a impedir que o transmissor sobrecarregue o
receptor, tratamento de erros, e o controle de acesso ao meio compartilhado;
Camada 3 – Camada de Rede: Os pacotes são organizados de modo que
eles possam trafegar através da conexão de rede a partir do host de origem até o
host de destino, ou seja, determina-se como os pacotes serão roteados. A camada
de rede também trata diferentes tipos de endereçamento entre uma rede e outra;
Camada 4 – Camada de Transporte: Sua função é garantir que as
mensagens sejam entregues sem erros, sem perdas, em sequência e sem
duplicação. Ela retira das camadas adjacentes a responsabilidade de transferência
de dados. Nesta camada, os fragmentos são entregues não apenas nos endereços
corretos, mas também em suas respectivas portas.
Camada 5 – Camada de Sessão: Provê o estabelecimento da sessão entre
os processos em execução em estações diferentes, ou seja, usuários de diferentes
máquinas podem estabelecer sessões entre eles. Também realiza-se controle de
diálogo (quem deve transmitir, e quando isso deve ocorrer), e a sincronização,
permitindo que transmissões partam de onde pararam;
Camada 6 – Camada de Apresentação: Faz uma tradução dos dados a
serem apresentados na camada de aplicação. Define a sintaxe e a semântica para
a apresentação dos dados. Possibilita a comunicação entre computadores com
diferentes formas de apresentação de dados;
Camada 7 – Camada de Aplicação: Contém uma série de aplicações
necessárias aos usuários.
Os protocolos do modelo OSI não são amplamente utilizados devido à
grande velocidade na qual a Internet baseada em TCP/IP foi aceita. Não
aprofundaremos os estudos dos protocolos do modelo OSI, para mais detalhes ver
[3,4], além do fato de que o projeto tem por base os conceitos do modelo TCP/IP.
Na próxima seção será abordado com mais detalhes o modelo TCP/IP.
1.2 Modelo TCP/IP
O modelo TCP/IP é proveniente da ARPANET e dos protocolos utilizados na
época (TCP e IP), que deram nome ao modelo [3,4]. Não há uma norma específica
20
para se utilizar os protocolos, há somente recomendações. As funcionalidades dos
protocolos são definidas em um fórum público e por um conjunto de documentos de
conteúdo público, são os RFC (Requests for Comments) [3,4]. A forma como a
entrega de dados é feita por uma rede é definida por estes protocolos, que devem
estar presentes tanto nos hosts de origem como no host de destino [3,4].
A pilha de protocolos do modelo TCP/IP está dividida em cinco camadas,
como na Figura 3. Cada camada e seus respectivos protocolos serão abordados
com mais detalhes nas próximas sessões.
Figura 3 - Comparação entre as camadas do Modelo OSI e do Modelo TCP/IP[20].
Durante o processo comunicação de um host com o outro, a informação
passa por todas as camadas do modelo TCP/IP, sendo encapsulada no host de
origem, para então ser transmitida pelo meio, e desencapsulada pela sua camada
par no host receptor. Por cada nível de camada em que os dados passam são
agregadas informações adicionais de roteamento, de endereçamento e para a
detecção e correção de erros.
As Unidades de Dados de Protocolos (PDU – Protocol Data Unit) recebem
nomes diferentes quando são tratadas em uma determinada camada:

camada Física: bits;

camada de Enlace (Acesso a Rede): quadros;

camada de Rede: pacotes;
21

camada de Transporte: segmento;

camada de Aplicação: dados.
Nas próximas seções, serão descritos os principais grupos de protocolos que
compõem cada uma das camadas do modelo TCP/IP, assim como os serviços
oferecidos por cada uma das camadas.
1.2.1
Camada Física
A camada física define as interfaces mecânicas, elétricas e de sincronização
da rede. Vários meios físicos podem ser utilizados para a transmissão, e cada um
deles possuem características distintas quanto a sua capacidade de transmissão,
custo, largura de banda, facilidade de instalação e de manutenção. Os meios de
transmissão são divididos em meios guiados, como fios de cobre e fibras ópticas, e
em meios não guiados como ondas de rádio e raios laser [3,4].
A Internet, nossa base de estudos e de transmissão de testes, possui todos
os tipos de meios de transmissão envolvidos, sendo quase que impossível,
determinar por quais meios físicos os dados estão trafegando, em um dado instante
de tempo. Desta forma, para maiores informações sobre as características dos
meios de transmissão ver [3,4].
1.2.2 Camada de Enlace
Uma das funções da camada de enlace está em fornecer um meio para que
haja a troca de dados sobre um enlace local comum. O protocolo de camada de
enlace define o formato dos quadros trocados entre os nós16 nas extremidades do
enlace, assim como as ações realizadas por estes nós ao enviar e receber os
quadros. Entre outros serviços oferecidos pela camada de enlace, está o controle
de acesso ao meio compartilhado e detecção de erros.
Os protocolos da camada de enlace especificam o encapsulamento de um
pacote em um quadro e as técnicas de sincronização. A técnica usada para levar o
quadro a intervalos determinados para o meio é chamada de método de controle de
16
Nomenclatura para dispositivos de rede conectados a um meio comum.
22
acesso ao meio. Para os dados serem transferidos através de vários meios
diferentes, a atuação de métodos de controle de acesso ao meio pode ser exigido
durante o processo de comunicação.
Os métodos de controle de acesso ao meio descritos pelos protolocos da
camada de enlace definem os processos pelos quais os dispositivos de rede podem
acessar o meio e transmitir quadros. O dispositivo final usa um adaptador para
fazer a conexão com a rede [3,4];
As LANs são redes de computadores concentradas em uma área geográfica
pequena, como um edifício, escola ou laboratório da uma universidade. Nessa rede
todos os computadores e demais dispositivos são diretamente conectados, assim
utilizam o mesmo protocolo de enlace. Para que haja acesso à Internet, é necessário
que um roteador local esteja conectado a rede.
O protocolo de redes locais mais difundido atualmente é o Ethernet. Existem
inúmeras tecnologias de rede local Ethernet e que operam em diferentes
velocidades, podendo rodar sobre cabo coaxial, par trançado de cobre ou até
mesmo fibra óptica.
Os nós têm endereços de camada de enlace, que pode ser denominado um
endereço de LAN, um endereço físico ou endereço MAC (Media Access control –
controle de acesso ao meio). O endereço MAC possui um conjunto de 6 bytes e
cada byte do endereço é expresso como um par de endereços hexadecimais, como
por exemplo, "00:19:B9:FB:E2:58".
Uma diferença em relação ao endereçamento IP é que o endereço MAC não
se altera por mais que o dispositivo mude de lugar, ou mesmo de rede.
Quando um nó da rede tem por objetivo enviar um quadro para outro nó, o
remetente insere no quadro o endereço MAC de destino enviando o quadro para o
endereço LAN. Cada um dos adaptadores dentro da mesma LAN receberá o
quadro e verificarão se o endereço MAC de destino que está no quadro combina
com o seu próprio endereço MAC. Se houver combinação de endereços, o
adaptador extrairá o datagrama dentro do quadro e o repassará para a camada
superior da pilha de protocolos. Se não houver combinação dos endereços haverá
o descarte do quadro sem passar o datagrama de camada de rede para a camada
superior da pilha de protocolos. Quando o adaptador remetente tem por objetivo
enviar o quadro para todos os adaptadores da rede ele insere um endereço de
23
broadcast MAC especial no campo de endereço do destinatário do quadro. Em
geral o endereço broadcast é uma cadeia de 48 bits consecutivos em notação
hexadecimal, ou seja, FF-FF-FF-FF-FF-FF [1].
As pontes são dispositivos que ligam duas ou mais redes que utilizam
protocolos diferentes (por exemplo, Ethernet e Token Ring17) ou dois segmentos de
uma mesma rede. Idealmente as bridges devem ser totalmente transparentes, ou
seja, deve haver a possibilidade de comunicação entre máquinas de qualquer
segmento independente dos tipos de LANs que estejam sendo utilizadas. Em sua
forma mais simples, uma bridge transparente opera em modo promíscuo, aceitando
assim cada quadro transmitido em todas as LANs a que ela está conectada.
Com a chegada dos dados, a bridge deve decidir se deve encaminhá-lo ou
não para outra LAN. Para tomar esta decisão, a bridge procura o endereço de
destino em uma grande tabela (hash), que pode listar todo destino possível e
informar qual LAN ele pertence. Ao se conectar uma bridge pela primeira vez, todas
as tabelas hash estão vazias, assim nenhuma bridge sabe onde estão os
destinatários. Para resolver isso elas utilizam um algoritmo que faz com que cada
quadro de entrada para um destino desconhecido seja enviado a todas as LANs.
Com o passar do tempo as bridges aprendem onde estão os destinatários. Após o
momento em que se descobre o destinatário, os quadros destinados a ele são
colocados somente na LAN apropriada e não mais enviados por toda a rede.
1.2.3 Camada de Rede
A camada de rede tem o papel de transportar pacotes entre hosts. A camada
de rede pega o segmento da camada de transporte do host remetente, encapsula
cada segmento em um datagrama e envia o datagrama ao seu roteador vizinho.
As funções de roteamento são empregadas pela camada de rede. Na
camada de rede, um pacote ao chegar à interface de entrada de um roteador, este
deve conduzi-lo até a interface de saída correta, de acordo com o endereço IP de
17
Protocolo que opera na camada física (ligação de dados) e de enlace. dependendo de sua
aplicação.
24
destino. Além disso, a rota ou o caminho entre o remetente e o destino são
determinados pela camada de rede.
A camada de rede pode disponibilizar alguns serviços específicos como:

entrega garantida: serviço que garante a entrega de pacotes, sejam eles entregues
tardiamente ou não;

entrega garantida com atraso limitado: o pacote será entregue com um atraso
máximo estabelecido;

entrega de pacotes na ordem;

largura de banda mínima garantida: se a transmissão for feita a uma taxa abaixo da
estabelecida, a camada de rede garante que nenhum pacote será perdido e
chegará dentro de um atraso também estabelecido;

jitter máximo garantido
Outros serviços importantes providos pela camada de rede são as redes de
circuitos virtuais (CVs) e as redes de datagramas. Nos circuitos virtuais há a
determinação do caminho entre remetente e destinatário, ou seja, toda a série de
enlaces pelo qual os pacotes passarão até atingir seu objetivo. Após o
estabelecimento do CV os pacotes poderão trafegar pela rede. Nas redes de
datagrama sempre que um sistema final envia um pacote, este é marcado com o
endereço de destino e enviado para a rede desejada. Isso acontece sem que um
CV seja estabelecido. A Internet é um exemplo de uma rede de datagramas.
O IP é o protocolo da camada de rede. Atualmente há duas versões do
protocolo IP em uso , o IP versão 4, e o IP versão 6. Neste trabalho, considera-se
somente o IPv4 pois foi a versão utilizada neste , para maiores informações sobre o
IPv6, consulte [3,4]. Na Figura 4 é mostrado o formato do datagrama IPv4.
25
Figura 4 - Formato do datagrama IPv4 [3].
Os campos do datagrama são os seguintes:

versão (4bits): versão do protocolo IP que foi usada para criar o datagrama;

comprimento do cabeçalho (4bits): necessário para determinar onde os dados
começam, pois o datagrama IPv4 pode conter diferentes números de opções;

tipo de serviço: identificam diferentes tipos de datagramas IP, como especificação
de atraso, ou confiabilidade;

comprimento do datagrama: comprimento do datagrama medido em bytes,
incluindo cabeçalho e dados;

identificador, flags e deslocamento de fragmentação: estes três campos
controlam a fragmentação e a união dos datagramas;

tempo de vida: Este campo garante que o datagrama não fique circulandopara
sempre na rede. Este campo é decrementado de uma unidade cada vez que o
datagramaé processado por um roteador;

protocolo da camada superior: especifica qual protocolo da camada de transporte
utilizado para criar a mensagem que está sendo transportada na área de dados do
datagrama;
26

soma de verificação de cabeçalho: auxilia um roteador na detecção de erros de
bits de um datagrama IP recebido;

endereço IP da fonte e do destino: especifica o endereço IP de 32 bits da fonte e
do destino;

opções: permite a ampliação do cabeçalho IP;

dados: é onde realmente os dados estão, contém segmentos da camada de
transporte (TCP ou UDP) ou mensagens ICMP.
Na Internet, cada uma das interfaces dos hosts e roteadores tem um
endereço IP que irá codificar seu número de rede e seu número de host. O
endereço IP tem 32 bits que são usados nos campos de endereço de fonte e
endereço de destino dos pacotes IP. Os endereços são escritos em notação
decimal separada por pontos, no qual cada byte do endereço é escrito em sua
forma decimal e separado dos outros bytes do endereço por um ponto. Por
exemplo, para o endereço 152.92.155.1 teremos em binário, o seguinte número:
10011000.1011100.10011011.0000001.
Os endereços IPs não podem ser escolhidos de forma aleatória. Uma parte
do endereço IP é atribuída às interfaces de hosts e roteadores. Um endereço a
essa
sub-rede
é
designado
pelo
endereço
IP.
Temos
como
exemplo
152.92.155.4/25, a notação /25 é conhecida como máscara de rede, indica que os
25 números mais a esquerda do conjunto de 32 bits irão definir o endereço de subrede. A sub-rede é uma rede logicamente isolada das demais, e não fisicamente.
1.2.4 Camada de Transporte
Para a realização da comunicação, a camada transporte trata os dados da
camada de aplicação de modo que eles sejam corretamente reconhecidos e
possam ser endereçados na camada de rede. A responsabilidade da camada de
transporte é prover a comunicação fim-a-fim geral dos dados de aplicação.
Para realizar este processo, a camada de transporte segmenta os dados,
permitindo que eles trafeguem pela rede sem que haja congestionamento. No host
de destino a camada de transporte deve garantir que os dados segmentados sejam
27
reagrupados em ordem correta. A multiplexação também permite que diversas
aplicações sejam executadas ao mesmo tempo no computador.
Para associar os fluxos que são gerados pela camada de aplicação estes
precisam ser identificados pela camada de transporte. Insere-se então a
identificação de número de porta. Existe apenas um número de porta para cada
processo18 que pretende acessar a rede. Para a correta identificação, é inserido no
cabeçalho da camada de transporte o número de porta, indicando qual aplicação
aquele segmento de dado está associado.
Há uma porta de origem e destino em cada um dos cabeçalhos de cada
segmento ou datagrama. Diversas aplicações comuns têm uma designação de
porta padrão, entretanto quando um cliente faz uma solicitação, a sua porta de
origem é gerada aleatoriamente. O único requisito é que ela não entre em conflito
com as outras portas em uso. A camada de transporte irá rastrear esta porta para
que quando uma resposta for retornada ela poderá ser encaminhada para a
aplicação correta.
A combinação do endereço IP e do número de porta identifica
exclusivamente um processo único que é executado em um dispositivo específico.
Um par {IP,porta} é único, identificando a conversação entre dois hosts e consistem
em endereços IP de origem e destino. Como exemplo, uma solicitação enviada a
um servidor web (porta 80), sendo executado em um host de endereço
152.155.92.1, seria destinado ao soquete( par {IP,porta}) 152.155.92.1: 80.
Existem múltiplos protocolos da camada de transporte, justamente pelo fato
de que diferentes aplicações têm diferentes necessidades, quanto a tolerância a
erros, a atrasos, necessidade de que os dados cheguem na ordem correta ou não.
Assim alguns protocolos fornecem funções mais básicas, enquanto que outros
garantem características adicionais em detrimento do desempenho, podendo
sobrecarregar a rede.
Os protocolos mais comuns da camada de transporte são o TCP e o UDP,
que se diferenciam pelas funções distintas que implementam. A seguir faremos
menção a ambos assim como ao endereçamento de porta associado a eles.
18
Programa de computador em execução.
28
A. UDP
O IP não pode ser usado para a transmissão na sua forma bruta, pois a
camada de transporte não saberia o que fazer com o pacote. O UDP adiciona os
campos de porta de origem e de destino para esse fim. Assim a camada de
transporte poderá entregar os dados de forma correta sabendo quais são as suas
aplicações correspondentes.
O UDP adiciona os campos de número de porta da origem e do destino nas
mensagens do processo de aplicação para fazer a multiplexação e a
demultiplexação, adiciona mais dois outros campos, o UDP length e o UDP
cheksum e passa o segmento resultante para a camada de rede. A camada de rede
por sua vez encapsula o segmento dentro de um datagrama IP e em seguida tenta
entregar o segmento ao host de destino utilizando a técnica de melhor esforço. O
UDP não realiza controle de fluxo e não há apresentação entre as entidades
remetentes e destinatárias da camada de transporte antes de enviar o segmento,
por isso, diz-se que o UDP é não orientado a conexão. Na Figura 5 é mostrado o
cabeçalho do segmento UDP.
Figura 5 - Cabeçalho do segmento UDP.
Como mencionado acima, a estrutura do UDP é composta por quatro
campos, cada um deles consistindo em 2 bytes. Os números de porta vão permitir
que o host de origem saiba como repassar os dados da aplicação ao processo
correto que está funcionando no host de destino. A soma de verificação é utilizada
pelo receptor para que ele saiba se ocorreu algum erro na transmissão do
segmento. O campo comprimento especifica o comprimento do segmento UDP,
incluindo o cabeçalho em bits. Devido a sua grande simplicidade, o UDP adiciona
29
uma pequena sobrecarga de cabeçalho no pacote, se comparado com o TCP.
Assim algumas aplicações dão preferência ao uso do UDP em relação ao TCP.
O UDP é comumente utilizado para aplicações em multimídia, como VoIP
(Voz sobre IP), recepção de áudio e vídeo armazenados, e telefone por Internet,
pois essas aplicações não se adaptam bem ao controle de congestionamento
presente no TCP. Outra aplicação está na atualização de tabelas de roteamento,
como no protocolo RIP19 (Routing Information Protocol). As atualizações do RIP
ocorrem de forma periódica. As atualizações perdidas são substituídas por
atualizações mais recentes, tornando inútil a recuperação das atualizações
perdidas, fazendo com que o UDP seja mais adequado para esta função. Ele
também é utilizado para levar dados de gerenciamento de rede como o SNMP 20
(Simple Network Management Protocol), pois geralmente essas aplicações devem
ser capazes de funcionar quando a rede está em estado de congestionamento.
Para finalizar, com o objetivo de evitar atrasos no estabelecimento de conexões
TCP, o DNS21 (Domain Name System) também roda sobre UDP.
B. TCP
Alguns serviços requerem uma entrega confiável de dados, e o UDP não
pode proporcionar isso. O TCP veio com o propósito de preencher esta
necessidade e se tornou o principal elemento da Internet.
Uma das diferentes características entre o protocolo UDP e o TCP, é que o
TCP é orientado a conexão. Isso significa que antes dele começar a transmissão de
datagramas pela rede, os dois processos precisam enviar alguns segmentos
preliminares para o outro com o objetivo de estabelecer parâmetros da
transferência dos dados em questão. O TCP roda somente em sistemas finais, ou
seja, os elementos da rede como Roteadores e Switches não mantém estados de
conexão, então eles apenas enxergam os datagramas e não as conexões.
Cada máquina compatível com o TCP tem uma entidade de transporte TCP
que gerencia fluxos e interfaces TCP para a camada IP. O serviço full-duplex do
19
Protocolo de Roteamento.
20
Protocolo da camada de aplicação, que realiza o gerenciamento de redes IP.
21
Sistema de gerenciamento de nomes que associa os nomes aos endereços IP.
30
TCP permite que haja transmissão de dados simultaneamente em ambos os lados
da conversa, entretanto esta conexão é sempre ponto a ponto, isto é, entre um
único remetente e um único destinatário. O TCP não permite multicast, quando um
remetente transfere dados para vários destinatários em uma única operação.
O cabeçalho TCP tem 20 bytes (12 bytes a mais que do que o cabeçalho do
UDP). Ele possui números das portas de destino e de origem, que serão utilizados
para a demultiplexação e multiplexação dos dados para as camadas superiores. Na
Figura 6 é apresentada a estrutura do cabeçalho do segmento TCP.
Figura 6 - Cabeçalho do segmento TCP [3].
O cabeçalho TCP apresenta os seguintes campos:

número da Porta de Origem e de Destino: contém os números de portas TCP
que identificam os programas de aplicação dos extremos de uma conexão;

número de sequência (32 bits): posição de cada segmento de dado na palavra
original, usado para a implementação de um serviço confiável;

número de reconhecimento (32 bits): especifica o próximo byte aguardado.
Também utilizado para o serviço de entrega confiável;

tamanho do Cabeçalho (TCP header length): informa quantas palavras de 32-bits
existem no cabeçalho TCP. Devido ao campo de opções do TCP o cabeçalho deste
pode ter comprimento variável;
31

opções (Opcional e de comprimento variável): utilizado como fator de aumento
de escala da janela para a utilização em redes de alta velocidade;

janela de Recepção (16 bits): controle de fluxo. Indica o número de bytes que um
destinatário está disposto a aceitar;

reservado: Campo reservado para o futuro;

ponteiro Urgente: é utilizado para indicar um deslocamento de bit no número de
sequência no qual os dados urgentes deverão estar

URG (1 bit): Se o ponteiro urgente estiver sendo usado, o valor 1 é atribuído. Indica
o deslocamento de bit no número de sequencia no qual os dados urgentes deverão
estar;

ACK (1bit): Indica se o campo Número de reconhecimento é válido;

PSH (1bit): Se ele estiver marcado, o destinatário deverá encaminhar os dados
para a camada superior imediatamente;

RST (1bit): Reinicia uma conexão devido a falha no host ou outra razão;

SYN (1bit): Utilizado para estabelecer conexões;

FIN (1bit): Usado para encerrar uma conexão;

checksum: confere o cabeçalho TCP;

dados: São os dados a serem transmitidos.
Para que o TCP estabeleça uma conexão, o servidor aguarda de forma
passiva por uma conexão de entrada. O cliente por sua vez envia um segmento
TCP com o bit SYN ativado e um bit ACK. Este segmento especifica o tamanho
máximo do TCP que o está disposto a aceitar, o endereço IP, a porta que se deseja
conectar e opcionalmente senhas e outros dados do usuário.
Quando este
segmento proveniente do cliente chegar ao servidor, a entidade TCP do servidor
verifica se realmente á um processo esperando uma conexão, caso contrário, a
conexão é rejeitada. Para que a conexão seja aceita é necessário que haja algum
processo na escuta da porta em questão. Se a conexão for aceita, um segmento de
confirmação será retornado. O segmento SYN, enviado como resposta, consome
apenas 1 byte de espaço.
Para o encerramento das conexões basta que uma das partes envie um
segmento com o bit FIN ativado, informando a outra parte que não há mais bits a
32
serem transmitidos. Quando há a confirmação do FIN esse sentido é desativado
para o envio de novos dados, entretanto os dados podem continuar a fluir no outro
sentido. A conexão só será encerrada, quando os dois sentidos das conexões
estiverem desativados.
1.2.5 Camada de Aplicação
A camada de aplicação tem por objetivo fornecer a interface entre as
aplicações que utilizamos para a comunicação com o outro, e a rede pela qual
nossas mensagens são transmitidas. As aplicações são a razão de ser e existir da
rede de computadores. Para que haja comunicação entre a rede, as aplicações
devem rodar nos dois sistemas finais.
A forma como a aplicação é organizada nos vários sistemas finais é
determinada pela arquitetura de aplicação, podendo ser:

arquitetura cliente-servidor: neste tipo de arquitetura, há sempre um hospedeiro
que está sempre em funcionamento (servidor) e que tem por objetivo atender a
requisição de vários outros hospedeiros (clientes). Neste tipo de arquitetura, os
clientes não se comunicam entre si. O serviço também possui um endereço fixo,
denominado IP. A Figura 7 mostra este tipo de arquitetura;
Figura 7 - Arquitetura cliente-servidor.
33

arquitetura P2P: nesta arquitetura, partes arbitrárias de hospedeiros (peers), que
podem mudar seu endereço IP ao se reconectarem a rede, comunicam-se entre si.
Este tipo de arquitetura é altamente escalável. Uma grande parte do tráfego da
Internet utiliza este tipo de arquitetura de aplicação. A Figura 8 mostra este tipo de
arquitetura;
Figura 8 - Arquitetura P2P.

Arquitetura híbrida cliente servidor/P2P: um exemplo de arquitetura híbrida é a
mensagem instantânea. A conversa entre dois usuários é instantânea, entretanto
quando o usuário utiliza a aplicação de mensagem instantânea ele se cadastra em
um servidor central. A Figura 9 mostra esse tipo de arquitetura;
Figura 9 - Arquitetura híbrida cliente servidor/P2P
34
Para realizar a comunicação, a camada de transporte utiliza o número de
porta para identificar a aplicação nos hosts de origem e de destinos. Programas de
servidor geralmente utilizam um número de porta pré-definido. A seguir será falado
sobre os protocolos de aplicação e seus respectivos números de porta UDP e TCP
que são normalmente associados à aplicação em questão.
Os protocolos da camada de aplicação definem como os processos
(programas que rodam dentro de um sistema final) de uma aplicação, funcionando
em sistemas finais diferentes, se comunicam entre si. A seguir abordaremos a
respeito de alguns protocolos da camada de aplicação.
A. DNS (Domain Name System)
O DNS tem por essência um sistema hierárquico de resolução de nomes e
utiliza um conjunto distribuído de servidores para associar os nomes aos endereços
numerados (endereço IP). Ao se comunicar, os protocolos DNS utilizam um único
formato, chamado de mensagem, sendo utilizadas para todos os tipos de consultas
de cliente e respostas de servidor, mensagens de erro e transferência de
informações de registro de recursos entre servidores. Os protocolos TCP e UDP
associam a porta 53 para a aplicação DNS.
Geralmente, o cliente utiliza mais de um endereço de servidor DNS para
resolver os nomes, pois pode acontecer de que o servidor DNS solicitado não
conheça o endereço procurado, desta forma, ele passa a solicitação para outros
servidores. No caso de solicitações futuras, o primeiro servidor mantém o valor
armazenado em seu cache de nome.
B. HTTP (Hypertext Transfer Protocol)
O HTTP é o protocolo de camada de aplicação da Web. Ele é implementado
em um programa cliente e outro servidor. O HTTP define a estrutura das
mensagens que são enviadas por este programa.
35
A página Web é constituída por objetos, que nada mais são do que arquivos,
como o HTML, JPEG22(Joint Photographic Experts Group) e etc., que podem ser
acessados por um único URL23(Uniform Resource Locator). Um browser irá
apresentar a página requisitada ao usuário e fornecer algumas características de
navegação e de configuração. Ele nada mais é do que um agente de usuário Web.
Desta forma, o HTTP vai definir como os clientes Web solicitam aos servidores as
páginas Web.
C. FTP ( File Transfer Protocol)
O FTP é um serviço que permite o compartilhamento de arquivos entre um
host local e um host remoto por meio de uma autenticação. Para que haja sucesso
na transferência de arquivos, o FTP precisa de duas conexões. Uma para a
transferência dos arquivos e outra somente para comandos e respostas.
Durante o inicio da sessão FTP, o lado do cliente inicia uma conexão TCP de
controle na porta 21 com o lado do servidor (host remoto). Ele envia por esta
conexão de controle a identificação e a senha do usuário e o comando para alterar
o diretório remoto. Ao receber um comando para a transferência de arquivo, o lado
do servidor, abre uma conexão TCP de dados para o lado do cliente transferindo
assim os arquivos.
D. DHCP (Dynamic Host Configuration Protocol)
O DHCP atribui um endereço IP, máscara de sub-rede, gateway entre outros
parâmetros para novos dispositivos de uma rede. O servidor DHCP é contatado, e
escolhe o endereço de uma lista pré-configurada de endereços, chamada de pool e
o aluga ao host por um período determinado. Quando o host não está mais
presente na rede, seu endereço IP torna-se vago para ser atribuído a outros hosts
caso seja necessário. O DHCP garante também que cada endereço IP seja
exclusivo.
22
Método de compressão de imagem.
23
É o endereço de um arquivo, impressora disponível em uma rede.
36
O processo de atribuição de endereço IP acontece de seguinte forma [3,4]:
1. ao se conectar a rede um dispositivo configurado para obter endereço DHCP, este
transmite um pacote DCHP DISCOVER para identificar o servidor DHCP
disponível;
2. o servidor responde oferecendo um endereço IP, máscara de sub-rede, etc (DHCP
OFFER);
3. O servidor retornará uma mensagem DHCP ACK, e caso o cliente confirme, então
a atribuição de endereço foi finalizada;
4. se houver invalidez no endereço, o servidor responderá com um DHCP NAK
(Negative Acknowledgement - confirmação negativa);
5. se isso acontecer o processo de seleção deverá recomeçar com uma nova
mensagem DHCP DISCOVER sendo transmitida;
6. a cada período de tempo da conexão, um pedido de renovação deve ser enviado
por meio da mensagem DHCP REQUEST;
E. Telnet
O Telnet provê de forma prática o acesso a terminais remotos da mesma
forma que é feito com terminais diretamente acoplados. O acesso é feito por linha
de comando. Para se conectar ao servidor, o Telnet cria um dispositivo virtual que
virá a fornecer os mesmos recursos de uma sessão de terminal com acesso à
interface de linha de comando do servidor [3,4].
A partir do momento em que a conexão é estabelecida o usuário poderá
executar qualquer que seja a função autorizada no servidor. É como se ele
estivesse utilizando uma sessão de linha de comando no próprio servidor, podendo
até mesmo desligar o sistema.
Apesar de o protocolo suportar autentificação, seus dados não são
criptografados, ou seja, qualquer um pode interceptar e interpretá-los facilmente.
Comumente, utiliza-se o Protocolo SSH (Secure Shell) para um acesso mais
seguro ao servidor [3,4]. O SSH além de fornecer uma autenticação mais forte que
o Telnet, também suporta o transporte de dados de sessão utilizando criptografia.
37
1.3 Métricas de Desempenho
Em redes de computadores, são utilizadas algumas métricas de modo a
verificar a qualidade e estabilidade da rede. Para realizar a análise de desempenho
dos ambientes de teste deste projeto consideraremos as seguintes métricas:

vazão da rede (throughput): Capacidade total de um canal em processar e
transmitir dados durante um determinado período de tempo;
𝑉𝑎𝑧ã𝑜 =

𝑁ú𝑚𝑒𝑟𝑜 𝑚é𝑑𝑖𝑜 𝑑𝑒 𝑏𝑖𝑡𝑠 𝑞𝑢𝑒 𝑒𝑛𝑡𝑟𝑎 𝑜𝑢 𝑠𝑎𝑖 𝑑𝑎 𝑟𝑒𝑑𝑒
𝑈𝑛𝑖𝑑𝑎𝑑𝑒 𝑑𝑒 𝑇𝑒𝑚𝑝𝑜
[𝑏𝑖𝑡𝑠 𝑠]
(1)
taxa de entrega de pacotes: Razão entre a quantidade total de pacotes recebidos
e pacotes transmitidos;
𝑇𝑎𝑥𝑎 𝑑𝑒 𝑒𝑛𝑡𝑟𝑒𝑔𝑎 𝑑𝑒 𝑝𝑎𝑐𝑜𝑡𝑒𝑠 =

Jitter(𝒅𝒗𝒊𝒌 )
é
calculado
𝑃𝑎𝑐𝑜𝑡𝑒𝑠 𝑟𝑒𝑐𝑒𝑏𝑖𝑑𝑜𝑠
𝑃𝑎𝑐𝑜𝑡𝑒𝑠 𝑡𝑟𝑎𝑛𝑠𝑚𝑖𝑡𝑖𝑑𝑜𝑠
pela
diferença
𝑥100[%]
entre
os
(2)
atrasos
de
pacotes
consecutivos[18],
𝑑𝑣 𝑖𝑘 = 𝑇𝐵𝑘 − 𝑇𝐴𝑘 − (𝑇𝐵𝑖 − 𝑇𝐴𝑖 )
(3)
onde:
𝑇𝐴𝑖 𝑒 𝑇𝐴𝑘 - instante de saída dos pacotes i e k marcado pelo relógio do host A.
𝑇𝐵𝑖 𝑒 𝑇𝐵𝑘 - instante de chegada mesmos pacotes marcados pelo host B.
A partir destas métricas pretende-se avaliar o impacto da presença de
máquinas virtuais na rede. Com a vazão será verificado se a taxa de transferência
se mantém inalterada verificando se o processamento imposto pela camada de
virtualização. A perda de pacotes será avaliada de modo a verificar se a camada de
virtualização insere alguma instabilidade na rede e para finalizar, o Jitter será
avaliado com o objetivo de verificar se seus valores continuarão dentro do valor
apropriado para transferência de vídeos, imagem e dados.
38
2. Virtualização
A virtualização tem sido destaque no mundo da tecnologia da informação. A
origem das máquinas virtuais remonta a década de 70 com a linguagem UCSD
Pascal, da Universidade da Califórnia em San Diego. Naquela época, era comum
que cada computador (mainframe24), tivesse seu próprio sistema operacional, e isso
se tornou uma das principais razões para o aparecimento das máquinas virtuais, isto
porque se tornava caro executar os sistemas operacionais em diversos mainframes,
devido à necessidade de se legalizar os sistemas operacionais. Pesquisas mostram
que há uma diminuição de custos em até 60% no ambiente de TI, devido à redução
na aquisição de novas máquinas, facilidade de gerenciamento, licenças de software,
consumo de energia, aumento da taxa de utilização dos servidores, e maior
eficiência operacional. [1,2,21]
De uma maneira mais formal, uma máquina virtual é definida como sendo
uma duplicata eficiente e isolada de uma máquina real. Segundo [24], uma duplicata
é uma cópia idêntica de uma máquina original, ou seja, a máquina virtual deve ter o
mesmo funcionamento de uma máquina real. O termo isolamento, indica o fato de a
máquina virtual funcionar como se fosse um computador independente, assim o
usuário que utilizar uma máquina virtual não encontrará diferenças em relação a
uma máquina real, com a vantagem de que não há propagação de falhas entre
máquinas virtuais e o sistema hospedeiro [21].
No ambiente de uma máquina virtual, não se inclui somente a aplicação, mas
todo o sistema operacional referente à máquina que o executa. As máquinas virtuais
(VM – Virtual Machine), em sua primeira idealização, foram criadas pela IBM há 60
anos como uma forma de compartilhar sistemas de mainframes grandes e caros. A
linha de mainframes 370 da IBM e seus sucessores oferecia uma máquina virtual
portada para várias de suas plataformas, sobre a qual as aplicações eram
executadas. Dessa forma era possível executar, ou migrar, uma aplicação de uma
plataforma para outra desde que houvesse uma versão de máquina virtual para a
plataforma cliente.
24
Computador de grande porte, dedicado normalmente ao processamento de um grande volume de
informações.
39
Embora a virtualização tenha surgido como uma inovação, esse conceito foi
deixado de lado por muitos anos, entretanto, com o aumento do poder
computacional dos atuais processadores, a disseminação de sistemas distribuídos e
a onipresença das redes de computadores causaram, o ressurgimento da
virtualização.
A preocupação com a otimização do uso de energia, o custo
operacional e o melhor aproveitamento do hardware dos servidores, foram os
principais motivos para a migração de servidores físicos para sistemas operacionais
virtualizados. Hoje com o avanço da tecnologia é possível, que por meio da
virtualização, que uma única máquina de maior porte faça o trabalho de até mil
servidores menores.
A virtualização tem sido utilizada como uma ferramenta para desktop ou
storage25. Através de virtualização de storage é possível criar uma estrutura
interconectada, em que equipamentos passam a ter inteligência, e capacidade de
alocar, de forma centralizada, os dados de acordo com a intensidade da utilização e
demanda. No caso da virtualização de desktops, a vantagem está na simplificação
do gerenciamento, redução de custos, maior segurança e possibilidade de acesso
remoto. As máquinas virtuais em desktops podem ser usadas para definir ambientes
experimentais sem comprometer o sistema operacional original da máquina, ou
ainda,
para
compor
plataformas
distribuídas
como
clusters26
e
grades
computacionais.
De acordo com [22] a virtualização pode solucionar alguns problemas, como:
Estrutura de servidores com baixa utilização: as empresas possuem um
grande parque de servidores com baixa utilização dos recursos. Em média, um
ambiente composto por servidores distribuídos tem taxa de aproveitamento entre
10% e 20%. Dessa forma a consolidação de servidores por meio da virtualização
permite maximizar os recursos do hardware e otimizar a utilização das máquinas em
taxas que ficam acima dos 80%;
Custos com licenças de software: os custos com licenças de software têm
grande peso nos orçamentos de TI. Para cada servidor distribuído, existe a
25
Rede de armazenamento.
26
Ou aglomerado de computadores, é formado por um conjunto de computadores.
40
necessidade de adquirir e renovar uma série de licenças de software. Atualmente, a
maioria dos licenciamentos de software é por núcleo. A consolidação em menor
quantidade de máquinas reduz o número de núcleos, diminuindo, com isso, os
custos com as licenças;
Altas despesas com energia: quanto mais servidores uma empresa possui,
maiores as despesas com energia e resfriamento. A redução no número total de
servidores resultará em redução no número de dispositivos para resfriamento e
consequente diminuição no consumo de energia;
Ambientes pouco flexíveis: quando uma empresa identifica a necessidade de
ampliar seu ambiente de TI, encara a necessidade de abrir uma ordem de compras
para adquirir novas máquinas. Desde a solicitação até o recebimento do novo
servidor, o processo para implementação desse novo sistema pode passar de um
mês. A virtualização reduz drasticamente o tempo de introdução de novas cargas de
trabalho, com implementação de máquinas virtuais em apenas poucos minutos,
contra as várias semanas necessárias para a instalação de máquinas físicas;
Sistemas distribuídos e falta de padronização: um parque heterogêneo de
servidores é de difícil gerenciamento, requer espaço para hospedagem de um
número cada vez maior de máquinas e dificulta a integração entre os aplicativos de
negócios. A consolidação de servidores elimina a necessidade por servidores
adicionais, licenciamentos em excesso, custos e complexidade com manutenção;
Devido a gama de aplicações em que a virtualização pode ser empregada,
houve um grande investimento nessa tecnologia por parte de fabricantes de
processadores e no desenvolvimento de produtos de software. Os processadores
mais recentes da Intel e da AMD contam com soluções de hardware especialmente
projetadas para suportar a virtualização [1-3].
2.1 Conceitos de Virtualização
A técnica de virtualização permite a execução concorrente de múltiplos
sistemas operacionais nas máquinas virtuais em um mesmo hardware físico. Essa
função é exercida pelo monitor de máquina virtual (hypervisor), que fica responsável
por multiplexar o acesso ao hardware e prover fatias lógicas de recursos para os
sistemas virtualizados. De tal forma, cada máquina virtual pode ter seu próprio
41
sistema operacional, aplicativos e serviços de rede (Internet). Pode-se também,
interligar virtualmente cada uma dessas máquinas virtuais através de switches e
roteadores virtuais [5-17]. A estrutura de um sistema virtualizado é mostrada na
Figura 10.
Figura 10 - Estrutura básica de um sistema virtualizado.
A estrutura de um ambiente virtual consiste em três partes básicas:

o sistema real, nativo ou hospedeiro, que contém ferramentas de hardware e de
software do sistema;

o sistema virtual, ou sistema hóspede que é o responsável por executar um sistema
virtualizado dentro de um sistema real;

camada de virtualização, hypervisor, ou monitor de máquina virtual, que simula as
interfaces virtuais a partir de uma única interface real;
O monitor de Máquina virtual ou hypervisor é a parte do software que
gerencia os recursos da máquina real e virtual. Ele é o responsável por criar as
máquinas e administrar o seu funcionamento, alocando para cada máquina um
sistema operacional que funciona de forma independente. O MMV também pode
42
fornecer proteção ao sistema servidor, de forma que a máquina não realize qualquer
operação indevida no hardware.
As principais funções do hypervisor são:

criar um ambiente de máquinas virtuais;

alterar o privilégio de modo de execução;

reservar recursos da CPUs para as máquinas virtuais;

gerenciar o recurso de memória e disco destinado para as máquinas virtuais;

gerenciar o controle a outros dispositivos como CD-ROM, drive, e dispositivos de
rede.
O hypervisor deve prover um ambiente de execução de programas idênticos
ao ambiente de máquina real, e controlar os recursos sobre o sistema real. Com o
objetivo de maximizar o desempenho, o monitor de máquina virtual pode, permitir
que o sistema hóspede execute as instruções diretamente sobre o hardware da
máquina física em modo usuário [25].
O monitor de máquina virtual pode ser implementado de duas formas:
diretamente sobre o hardware da máquina real ou sobre o sistema operacional da
máquina hospedeira [6]. No primeiro caso, chamamos de monitor nativo, ou de tipo
1, o MMV é implementado entre o hardware e os sistemas hóspedes. Neste caso,
todos os recursos são gerenciados pelo MMV, cada máquina virtual se comporta
como uma máquina física completa que pode executar o seu próprio sistema
operacional [25]. Esta abordagem é empregada por um dos principais sistemas de
virtualização, o XEN27[28].
O segundo caso, chamado de monitor convidado ou de tipo 2, o MMV é um
processo sendo executado no sistema operacional hospedeiro [25]. Neste caso os
recursos de hardware são divididos entre as máquinas virtuais e entre outros
serviços que estão sendo executados no hospedeiro.
Os monitores de máquina virtual são constituídos de três princípios
fundamentais:
27
Software de virtualização. Xen permite a execução de vários sistemas operacionais,
simultaneamente, sobre um mesmo hardware.
43

princípio da eficiência: É extremamente importante que um grande números de
instruções do processador virtual sejam executadas pelo processador real, sem que
haja a intervenção do monitor. As instruções que não puderem ser tratadas pelo
processador real, precisam ser tratadas pelo monitor;

princípio da equivalência: O monitor deve prover um comportamento de execução
semelhante ao da máquina real, para o qual oferece suporte de virtualização, salvo
haja necessidade de se fazer alterações de recursos das máquinas;

princípio da integridade: Todas as requisições de recurso de hardware devem ser
alocadas explicitamente pelo monitor (memória, processamento e etc);
Na Figura 11 mostra-se o esquema de um sistema virtualizado, onde tem-se
dispositivos de hardware acessando o sistema operacional, que realiza a interface
entre a máquina virtual e a camada de hardware, realizando o gerenciamento de
recursos.
Figura 11 - Sistema virtualizado [27].
44
2.2 Tipos de Virtualização
A implementação de máquinas virtuais pode ser obtida através de duas
técnicas: virtualização total ou completa e a paravirtualização. Essas duas técnicas
diferem-se por modificar ou não os sistemas operacionais hospedeiros.
A virtualização total permite o uso do sistema operacional e aplicações, como
se estivessem executando diretamente sobre o hardware original. A grande
vantagem dessa abordagem é que o sistema operacional hóspede não precisa ser
modificado para executar sobre o hypervisor. Desta forma o sistema operacional
hóspede cria uma réplica do hardware real. Esse tipo de virtualização necessita de
um hardware com características específicas, já que qualquer execução privilegiada
de acesso a I/O devem ser analisadas de acordo com critérios definidos pelo
hypervisor. A virtualização completa só ocorre dentro de uma mesma arquitetura, por
exemplo, uma arquitetura de 32 bits só poderá virtualizar a arquitetura 32 bits.
Na Figura 12 pode-se ver a estrutura da virtualização total. Percebe-se que
os aplicativos (Ap) das duas máquinas virtuais são executados sobre um sistema
operacional não modificado.
Figura 12 - Estrutura da Virtualização total [10].
45
A virtualização completa também possui desvantagens. O software de
virtualização pode prejudicar o desempenho do sistema, de modo que as aplicações
funcionem mais lentamente em sistemas virtualizados do que se
fossem
executadas em sistemas não virtualizados. Parte dos recursos de processamento de
dados do servidor físico deve ser reservada para o hypervisor. Embora o hypervisor
resolva todos os problemas em relação às máquinas virtualizadas, isso traz uma
queda de desempenho devido ao processamento que o hypervisor tem que fazer,
como por exemplo, traduzir instruções.
A emulação de hardware (virtualização total) se utiliza de softwares para
realizar a interface com o sistema operacional hóspede (a fim de comunicar-se com
hardware simulado inexistente), causando problemas de compatibilidade de drivers.
O hypervisor contém drivers de dispositivo e em alguns casos pode haver falta de
compatibilidade entre os novos drivers instalados, impedindo que o software de
virtualização seja executado na máquina. Estes problemas ocorrem em parte porque
as arquiteturas dos computadores não foram projetadas tendo a virtualização em
mente.
A paravirtualização tenta minimizar os problemas mencionados acima
alterando o sistema operacional virtual, implementando uma arquitetura que seja
voltada para facilitar a virtualização. Ela modifica os sistemas operacionais hóspedes
para que eles reconheçam o monitor de máquina virtual. Nessa abordagem, o
sistema hóspede é modificado para chamar o monitor de máquina virtual sempre
que for executada uma instrução. Além disso, na paravirtualização os dispositivos de
hardware são acessados por drivers do próprio monitor de máquina virtual. Por outro
lado a paravirtualização é menos flexível, pois precisa de modificações no sistema
operacional hóspede, para que este possa trabalhar perfeitamente.
Na Figura 13 pode-se ver a estrutura da paravirtualização. Neste caso,
percebe-se que os aplicativos (Ap) das duas máquinas virtuais são executados
sobre um sistema operacional modificado.
46
Figura 13 - Esquema da paravirtualização [10].
O uso da técnica de virtualização provê alguns benefícios como, por exemplo,
a possibilidade de se poder trabalhar em um ambiente onde haja uma grande
variedade de plataformas de software sem ter aumento no número de plataformas
de hardware. Os servidores hóspedes podem migrar de uma máquina física e assim
balancear a carga de processamento dinamicamente, além da possibilidade de
múltiplas funções poderem ser executadas em uma mesma máquina física. Os
sistemas convidados podem migrar de uma máquina física para a outra enquanto
estão rodando, o que possibilita o aumento do seu nível de segurança.
A virtualização de servidores permite um modelo de gerenciamento visando a
economia e redução de custos de empresas, isola um programa ou uma estação de
trabalho dentro da rede, utilizando assim um servidor físico para criar diversos
servidores. Geralmente, instala-se um aplicativo de virtualização no sistema
operacional e dentro dele há instalado diversos outros sistemas operacionais,
economizando espaço e gasto com computadores [4,27].
47
3. Ferramentas de virtualização
Neste trabalho, utilizou-se o XCP (Xen Cloud Platform) como ferramenta de
virtualização para criar a rede de testes. Também utilizamos o Open XenCenter para
criar as máquinas virtuais Linux e poder gerenciá-las remotamente. Para realizar os
testes, utilizamos a ferramenta de análise de desempenho de rede Iperf.
3.1 Xen Cloud Platform
O XCP é um software de virtualização open-source e de computação na nuvem
[1-10]. O XCP contém um monitor de máquina virtual (hypervisor) Xen e foi
desenvolvido dentro do âmbito de um projeto de pesquisa da Universidade de
Cambridge, que resultou na criação da empresa XenSource inc. que posteriormente
em 2007 foi adquirida pela Citrix System.
O Xen é um hypervisor que fornece um isolamento para as máquinas virtuais.
Xen é a síntese de vários produtos e projetos sendo uma plataforma aberta gerida
pelo Xen.org. O hypervisor em si é similar em todos esses projetos porém a forma
de gerenciamento pode se tornar diferente, o que pode muitas vezes pode causar
confusão se não for clara qual a pilha de ferramentas que está sendo usada.
É importante deixar claro que o XCP é uma plataforma aberta do Xen e foi
projetado especificamente para o ambiente empresarial e para nuvem, enquanto que
o Citrix XenServer é um produto comercial baseado no XCP e exibe a mesma pilha
de ferramentas e APIs de gerenciamento. Fazendo uma analogia pode-se pensar
que da mesma forma que o Red Hat Enterprise Linux é derivado do Fedora, o
XenServer é baseado no XCP. O XenServer tem sua versão gratuita, porém
aplicativos adicionais só serão habilitados obtendo-se licença.
Diferente das outras ferramentas de virtualização o Xen apresenta um recurso
que permite criar um hypervisor que não possui drive de dispositivos, e ainda assim
consegue controlar os recursos das máquinas virtuais. O Xen consiste em uma
máquina virtual que executa um kernel28 Linux modificado e que possui acesso a
dispositivos de entrada e saída e a outras máquinas virtuais.
28Núcleo do sistema operacional
48
O Domínio U ou DomU é a denominação dada para as máquinas virtuais
que rodam outros sistemas operacionais, estas possuem um drive virtual para
acesso de recursos de hardware. O Domínio 0 ou Dom0 é responsável por criar as
máquinas virtuais referentes ao Domínio U, inicializá-las e desligá-las, ou seja, é a
parte do sistema responsável pelo gerenciamento do Domínio U, além de ter acesso
aos dispositivos da máquina física, também é o responsável pelas requisições de
acesso a rede. Assim o Domínio 0 é a camada responsável pelo tratamento das
requisições feitas pelo Domínio U e é o primeiro a inicializar as configurações de
boot depois do Xen.
O XCP apresenta estes mesmos conceitos de domínios, este contém o
Domínio 0 Linux kernel. Os domínios são máquinas virtuais do Xen e são de dois
tipos: privilegiado (Domínio 0) ou não privilegiado (Domínio U). A função do
hypervisor é controlar os recursos de memória, de comunicação e de
processamentos das máquinas virtuais, não possuindo drivers de dispositivos. O
hypervisor inicia o Domínio 0 pois este não é capaz de suportar nenhum tipo de
interação com os sistemas hóspedes. Dessa forma, as outras máquinas virtuais só
podem ser iniciadas após a execução do Domínio 0. Assim como no Xen, o Domínio
0 é responsável por criar, iniciar e terminar as máquinas virtuais de Domínio U.
As máquinas virtuais não possuem privilégio de execução dentro do sistema,
porém pode-se perceber que no Xen o software OpenStack29 também roda no
Domínio U. Isso traz um nível de segurança entre o software de sistema virtualizado.
Há projetos que preveem a divisão do Domínio 0 em múltiplos domínios
privilegiados, isto traria maior separação de componentes críticos aumentando os
níveis de separação [2]. Atualmente temos em sua arquitetura 3 níveis de
separação: Domínio 0, OpenStack Domínio U e as máquinas virtuais (sem
privilégio).
A Figura 14 mostra o interação entre o hypervisor, o Domínio 0 e as demais
máquinas virtuais (Domínio U).
29
Software de código aberto capaz de gerenciar os componentes de múltiplas infraestruturas
virtualizadas, assim como o sistema operacional gerencia os componentes de nossos computadores.
49
Figura 14 - Relação entre o hypervisor, Dom0 e DomU [2].
Inicialmente o Xen implementava somente a técnica de paravirtualização, ou
seja, era necessário modificar os sistemas operacionais hóspedes (Domínio U) para
torná-los conscientes do hypervisor. Após a sua terceira versão, o Xen passou a
oferecer suporte à virtualização completa, permitindo o uso de sistemas
operacionais não modificados, mas isso só é possível se o processador oferecer
suporte de hardware à virtualização (Intel VT ou AMD-V). Com isso, o Domínio U
passou a ter duas nomenclaturas, o Domínio U-PV (paravirtualized) para ambientes
paravirtualizados e o Domínio U-HVM (hardware virtualized) para ambientes
virtualizados. Isto se refere a interação entre o Xen, Dom0 e o Kernel dos sistemas
convidados. Os U-PVs convidados são conscientes do fato que precisam cooperar
com o Xen e o Domínio 0 trazendo melhor desempenho ao sistema, já os U-HVMs
convidados não estão cientes do seu ambiente e fingem que estão executando
diretamente no hardware, ou seja, não entendem que são máquinas virtualizadas. O
Domínio U-PV, por não ter acesso direto ao hardware necessita de drivers especiais
50
para acesso a rede e ao disco. Já os domínios U-HVM por não serem modificados,
iniciam tentando executar a BIOS30[1,2,24].
O XCP combina as capacidades de isolamento do Xen hypervisor com maior
segurança e tecnologias de virtualização de rede para oferecer um conjunto de
serviços de infraestrutura de nuvens virtuais. A Figura 15 mostra a estrutura de
funcionamento do XCP. Seus módulos serão explicados com mais detalhes na
Seção 4.1.1, quando será analisada com mais profundidade a arquitetura do XCP.
Figura 15 - Estrutura de funcionamento do XCP [14].
Neste trabalho escolheu-se utilizar o XCP como ferramenta de virtualização
pelos seguintes motivos [1-9]:

velocidade de processamento;

escalabilidade31;

características de classes de serviços, como migração de processos sem que estes
sejam interrompidos;
30 O BIOS é um programa de computador pré-gravado em memória permanente executado por um
computador quando ligado. Ele é responsável pelo suporte básico de acesso ao hardware, bem como
por iniciar a carga do sistema operacional.
31
Capacidade da rede de suportar crescimento de sua estrutura sem que sua qualidade seja afetada.
51

possibilidade de se criar roteadores virtuais utilizando a técnica de virtualização de
máquina;

possibilidade de se poder migrar um processo de um roteador virtual para o outro
sem que esse processo tenha que ser interrompido;
Estudos mostram que os atuais computadores pessoais providos de
processadores com múltiplos núcleos permitem a construção de roteadores
eficientes e de baixo custo [5-14]. Assim enquanto o roteador virtual permite um
plano de controle e um plano de dados, o XCP permite que esses dois planos sejam
virtualizados. Cada roteador virtual implementa os seus próprios planos de controle
e de dados, assim o XCP torna a rede mais programável em relação a outras
tecnologias que virtualizam apenas o plano de controle e compartilham o plano de
dados. Essa é a principal vantagem para o uso do XCP na virtualização de
roteadores e, por isso, é utilizado em diversas plataformas de testes e projetos de
novas arquiteturas da Internet do Futuro [10].
3.1.1 Arquitetura do XCP.
Na Figura 16 é mostrada a arquitetura do Xen Cloud Platform.
Figura 16 - Arquitetura Xen[22].
52
Dentro da arquitetura mostrada temos o hypervisor Xen, o Domínio 0 e o
OpenStack Domínio U. O Domínio 0, executa o XAPI e algumas partes do
OpenStack (alguns plugins e‪regras‪de‪isolação).‪O‪XAPI‪ou‪“XenAPI”‪é‪uma‪pilha‪
de ferramentas usada pelo XenServer [15]. O XAPI é o cérebro do XenServer e além
de gerenciar os recursos, suas outras funções são: processamento das
configurações, inicialização dos caminhos de rede, criação da base de dados,
gerenciamento dos repositórios de armazenamento, gerenciamento das máquinas
virtuais e da rede. Para conversar com o XAPI é necessário utilizar a pilha de
ferramentas do próprio XAPI.
O XenServer necessita de uma requisição via XAPI. A cópia da base de
dados do XAPI é sincronizada entre os hosts em um pool32, assim todos os hosts
têm uma copia da base de dados do XAPI tendo conhecimento do que se passa no
sistema. Em um pool de hosts existe um host que é responsável por enviar a todos
os outros uma base de dados para a sincronização, este host é denominado Master.
Se por algum motivo o host Master falhar, um novo host é eleito Master e passa a
compartilhar informações com todos os outros. Quando são coletados os relatórios
de status do XenServer a base de dados é armazenado em um relatório de status.
Por exemplo, o XenCenter, software que será utilizado neste trabalho para gerenciar
remotamente as máquinas virtuais, realiza uma requisição ao XAPI quando cada
host necessita trocar informações com a máquina Master, em um pool.
O OpenStack Domínio U é responsável por fazer a interface com o cliente.
Ele executa o código nova-compute em uma máquina paravirtualizada que é
executada no host que se encontra em gerenciamento[13]. O processo novacompute é um daemon que cria e termina as instâncias virtuais da máquina,
executando uma série de comandos a fim de ligar a máquina virtual e atualizar seu
status em uma base de dados. Este processo é complexo e não faz parte do escopo
do nosso projeto. Cada host executa uma instância local de uma nova-compute. O
OpenStack DomU também oferece execução da nova-network, que gerencia os
endereços IPs via DHCP. A nova-compute é executada somente nos sistemas
32
Parque de máquinas.
53
hóspedes e inserem ao sistema um nível de segurança e isolamento entre softwares
de sistemas privilegiados e o software do OpenStack[4-9].
Anova-network trabalha de forma similar ao nova-compute. Esta executa
tarefas de rede tal qual a criação de rede, criação de bridges, mudança de regras
de Iptables33, ou seja, toda e qualquer tarefa relativa à rede.
O XenServer ( parte integrante do XCP) tem uma interface física de rede eth0.
Desta forma, o Domínio0 possui a bridge xenbr0. O Domínio U é uma máquina que
geralmente tem quatro interfaces, com pode-se ver na Figura 17. Essas interfaces
são nomeadas a escolha do administrador da rede.

eth0 conectado ao XAPI (Carrega o tráfego relativo aos XAPI);

eth1 xenbr2 tráfego de rede relativo ao Tenant;

eth2 xenbr0 tráfego de gerenciamento dos protocolos (MySQL, RabbitMQ, Glance,
etc);

eth3 xenbr1 tráfego público (protocolo IP, API dos dispositivos finais);
33
Ferramenta que permite a criação de regras de firewall e NATs
54
Figura 17 - Interfaces do Xen [29].
A interface do DomU
que conecta a rede pública é utilizada pela nova-
network que envia tráfego via IP à rede correta. Pode-se também criar uma VLAN
em uma interface do XenServer e então associá-la a uma determinada bridge. Existe
suporte a três modos de gerenciamento de rede, o Flat Network Manager, Flat
DHCP Network Manager e o VLAN Network Manager.
No Flat Network manager, o administrador de rede especifica a interface de
rede. Os endereços IPs são escolhidos a partir de uma sub-rede e então associados
às máquinas virtuais. Cada instância recebe um valor fixo de endereço IP que estão
contidos em um grupo de endereços. O administrado deverá criar uma bridge nos
sistemas que rodam o serviço nova-network. Todas as instâncias do sistema são
55
associadas à mesma bridge e esta configurada manualmente pelo administrador de
rede [22-26].
No Flat DHCP Mode, o OpenStack inicia o serviço de DHCP que entrega
endereço IP de determinada sub-rede às instâncias de máquina virtual e fica a cargo
do administrador de rede a configuração manual das bridges. O endereço de subrede do grupo de máquinas virtuais é especificado pelo administrador de rede. Da
mesma forma como no modo Flat Network manager todas as instâncias são
associadas a uma única bridge com o adicional de que nesse caso temos um
servidor DHCP sendo executado e configurando todas as instâncias. O computador
faz uma configuração adicional na tentativa de fazer uma ponte entre o dispositivo
Ethernet (Flat interface, eth0 por default). Para cada instância será alocado um IP
fixo e configurado um servidor dnsmasq com MAC/IP para máquina virtual ou seja
dnsmasq não faz parte do processo de escolha de endereço IP este apenas entrega
IPs de acordo com o mapeamento feito pelo nova-network. Instâncias recebem IP
fixo por meio do módulo dhcpdiscover. Esses IPs não são atribuídos a nenhuma
interface de rede do host, somente às interfaces das máquinas virtuais hóspedes.
Quando a máquina virtual inicializa, esta envia pacotes para o servidor DHCP que
responde com o endereço IP. Na realidade, o endereço IP é atribuído pela novanetwork que o disponibiliza ao servidor DHCP, este somente diz a máquina virtual
qual será o seu IP[25-33].
Em cada configuração com o Flat networking, os hosts com nova-network são
responsáveis por encaminhar tráfego da rede privada configurada com range fixo
opcional no nova.conf. O modo flat DHCP habilita o teste de ping nas máquinas
virtuais utilizando IP fixo através do nova-network, porém não é possível realizar
este teste de uma VM para outra. Este é o comportamento esperado.
O modo VlAN Network Mode cria uma VLAN e uma bridge para cada máquina
virtual. Para múltiplas máquinas a rede em modo VLAN requer um switch que
suporte tagueamento34 de VLAN(IEE 802.1Q). Há intervalos de IPs privados que
somente são acessados dentro da VLAN, de modo que para que os usuários
tenham acesso a instâncias em seus projetos, uma VPN necessita ser criada
(usualmente chamada de cloudpipe) [15]. Hosts geram um certificado e uma chave
34
Colocar marcação de VLAN nos pacotes.
56
para usuários terem acesso a VPNs automaticamente. Nesse modo, cada máquina
virtual tem a sua própria VLAN, bridge de rede e sub-rede[4-9].
As sub-rede são especificadas pelo administrador de rede e atribuídas
dinamicamente às máquinas virtuais quando requerido. O servidor DHCP é iniciado
para cada VLAN e entrega através destas o endereço IP às máquinas virtuais.
Todas as instâncias pertencem a um projeto que são associadas a mesma VLAN. O
OpenStack cria as bridges de rede e VLANs quando requerido.
3.1.2 Configuração de Redes no XCP
O Xen permite grande flexibilidade na configuração de rede. É possível
permitir comunicação entre Xen hóspedes de uma mesma máquina bem como a
comunicação entre Xen hóspedes e a rede global. Os sistemas hóspedes podem ter
funcionalidades de roteador e de NAT. Uma rede virtual local pode ser criada para
habilitar hóspedes e a comunicação privada entre eles sem o uso de uma rede
física.
Uma regra básica do Xen é o compartilhamento entre a rede física e os
múltiplos hóspedes. Logicamente cada Domínio U deverá ter uma interface de rede
virtual (NIC – Network Interface Controller). O Xen multiplexa a saída de pacotes de
cada rede virtual dentro da rede física. Similarmente, o Xen demultiplexa a entrada
de pacotes da rede virtual para cada NIC correspondente ao seu Domínio U. Isso
pode ser feito em três modos, bridge, router ou Natwork Address Translation (NAT).
Por outro lado, uma interface de rede virtual não requer uma interface de rede
física para funcionar. Poderá ser criada uma rede virtual em segmentos entre
domínios hóspedes que não necessitam se comunicar com um dispositivo físico. Ou
seja, sistemas hóspedes podem ter múltiplas interfaces de rede compostas por
interfaces físicas e lógicas que garantem o acesso ao segmento de rede virtual.
Outro aspecto importante das redes virtuais é decidir a topologia de rede. O
administrador está livre para construir a topologia virtual dentro do sistema Xen. O
administrador deverá decidir qual endereço IP deverá atribuir a cada interface da
rede virtual. Cada segmento de rede deverá ter a máscara de rede e um
identificador de rede para guiar o endereço IP e permitir o roteamento. As interfaces
que são roteadas na camada 2 para fora da rede obtém o endereço IP de um
57
servidor DHCP externo. As interfaces de rede virtuais também podem ser atribuídas
manualmente. As configurações de rede virtuais e topologias tem um grande
impacto sobre o desempenho e segurança do sistema.
Como mencionado acima, o Xen provê três modos de rede virtual para os
hóspedes, bridged, routed e NAT. No modo de bridge a interface de rede virtual
“vif1.0”‪ é‪ visível‪ à‪ camada‪ Ethernet externa, já no modo router,‪ o‪ “vif1.0”‪ não‪ é‪
visível a camada Ethernet, porém os endereços IP o são.‪No‪modo‪NAT,‪o‪“vif1.0”‪e‪
o endereço IP não são visíveis.
A bridge retransmite o tráfego entre múltiplas interfaces de rede baseada no
endereço, independente dos protocolos das camadas superiores. O roteador
encaminha os pacotes às camadas superiores baseadas no endereço IP através da
Internet e o gateway NAT traduz entre um único ponto de roteamento o endereço IP
externo a vários endereços IPs locais que não são roteáveis. O gateway NAT
remapeia os soquetes dos sistemas convidados para a porta do Domínio 0. A Figura
18 mostra estes três modos de operação.
58
Figura 18 - Modos de rede virtual [12].
No modo de roteamento, o driver domain35 conecta duas redes de diferentes
segmentos: a rede interna dos sistemas hóspedes e a rede externa, conectando-o a
Internet. Quando o driver domain age como gateway NAT, ele continua a agir como
um roteador. Além disso, ele mapeia a porta do endereço IP dos sistemas
35
Domínio U com acesso físico ao dispositivo de hardware.
59
convidados, ou seja, funciona como Proxy. Os IPs dos domínios hóspedes estão por
trás do driver domain e são invisíveis a rede externa. A tabela da Figura 19 compara
o modo bridging com o modo routing.
Figura 19 – Tabela de comparação entre o modo bridge e o modo de roteamento
[12].
A. Modo Bridging
No modo bridging,‪ a‪ ferramenta‪ “brctl”‪ é‪ utilizada‪ para criar um software de
interface bridge no drive de cada domínio. A interface de rede física é então
associada a uma determinada bridge. As interfaces internas dos sistemas
convidados são associadas a interface do software bridge no momento de sua
criação. Quando a interface bridge recebe os dados da interface física, ela os
retransmite por diferentes domínios utilizando seu endereço MAC, dando a ideia que
o domínio recebe dados da Ethernet. Neste modo, os sistemas hóspedes são
transparentes para a Ethernet. Quando o driver é configurado para ser roteador,
usando as regras de IPtables Linux, todos os pacotes recebidos pela interface pela
rede física, são processados pelo driver da camada de rede IP. O driver domain
busca a tabela de entrada do endereço IP e encaminha os pacotes para os
convidados de acordo com o endereço IP de destino.
O modo bridging multiplexa e demultiplexa os pacotes pelo endereço MAC,
enquanto que no modo router esse processo é feito pelo endereço IP. Enquanto que
ao firewall Linux‪ provê‪ o‪ filtro‪ de‪ pacotes‪ “iptables”,‪ o‪ pacote‪ “Linux‪ bridge utils”‪
também provê o filtro Ethernet “ebtables”,‪ habilitando‪ a‪ funcionalidade‪ de‪ filtros‪
dentro da bridge. Com o modo bridge habilitado, pode-se também controlar e
assegurar‪o‪tráfego‪de‪rede‪dentro‪da‪configuração‪do‪“IP‪packet‪firewall”.
60
No Xen, o modo padrão de configuração é o bridge. As interfaces virtuais do
Domínio U são flexíveis para serem associadas às bridges no momento da
configuração. Desse modo é fácil garantir a isolação e a segurança entre os
domínios. É possível também dedicar uma interface física a um único domínio,
dando acesso direto aos dispositivos físicos. Neste caso, o driver domain não está
envolvido nos processos do domínio hóspede36.
Normalmente os sistemas hóspedes compartilham as mesmas NICs.
Entretanto, caso um deles tenha um maior tráfego de rede, é importante assegurar
que eles tenham suas próprias NICs de modo a garantir seus serviços. Assim, o
sistema hóspede se comporta de maneira semelhante a uma máquina física e tem
total controle sobre a rede.
Quando os pacotes são enviados aos sistemas hóspedes a bridge ou o
roteador o driver domain recebe‪ os‪ pacotes‪ e‪ os‪ direciona‪ à‪ ”backend vif deste
domínio. Então a interface backend vif direciona os pacotes para a interface
(frontend vif) do sistema hóspede. Quando o sistema hóspede envia dados para a
Internet os dados são enviados a uma interface frontend “vif”que são armazenadas
em um buffer, e então encaminhadas a uma interface backend “vif”‪ e‪ então são
encaminhadas através de uma bridge ou roteador para o driver domain. Enfim, a
bridge entrega os dados a Internet. A Figura 20 mostra‪a‪presença‪da‪“vif1.0”‪como‪
interface do XCP.
36
Domínio que executa sobre uma máquina virtual. DomU ou máquina virtual.
61
Figura 20 - Interface‪‪“vif1.0”.
O veth0 e o vif0.0 formam
um par de interfaces do Domínio 0, veth0 é
renomeado para ser o eth0, como mostrado Figura 21.
Figura 21 - Interface eth0.
O xenbr0 é a interface bridge configurada no driver domain. A Vif1.0 é a
interface de rede externa onde são executados os domínios hóspedes. Pode-se ver
que o eth0, vif0.0,vif1.0 e xenbr0 compartilham o mesmo endereço MAC
FE.FF.FF.FF.FF.FF, que é o endereço de broadcast. Isso indica que a interface
física, o loopback do Domínio 0, a interface externa dos domínios hóspedes utilizam
a mesma bridge (xenbr0) para propagar pacotes de broadcast. Quando a interface
62
física recebe pacotes, os envia diretamente através da bridge xenbr0, então o
software bridge determina a qual interface externa será encaminhada os dados.
Então, eth0 não necessita de um IP, somente de um endereço MAC. A Figura 22
mostra as interfaces backend vif e frontend vif do domínio hóspede.
Figura 22 - Interfaces backend vif e frontend vif do domínio hóspede [12].
As interfaces virtuais correspondentes aos domínios hóspedes, eth0, são
configuradas dentro do domínio hóspede. Do ponto de vista dos drivers domain, o
eth0 do domínio hóspede é o vif1.0. A Figura 23 mostra um drive virtual funcionando
no modo bridge.
63
Figura 23 - Driver virtual funcionando no modo bridge [12].
Com o comando traceroute pode-se mapear a rota de um pacote de uma
máquina para outra. Pode-se perceber que há somente um salto entre a máquina
virtual e máquina externa que estão na mesma sub-rede. Neste projeto, criaram-se
duas máquinas virtuais funcionando em modo bridge. A Figura 24 mostra que o
traceroute executado de uma das máquinas virtuais para uma máquina real mostra
que o Domínio 0, cujo IP é 152.92.155.45 não é indicado em seu mapeamento.
Figura 24 - Resultado do comando traceroute.
Percebeu-se que através do wireshark (analisador de protocolo de rede) que
a interface xenbr0 trabalha como um switch, isto porque o software bridge não faz
uma requisição ARP, entregando os dados diretamente ao domínio específico.
Percebe-se também a partir do comando brctl show que todos os domínios estão
dentro de uma mesma bridge. O Xen possui um script padrão que cria uma bridge
64
chamada‪de‪“xenbr0”‪sobre‪a‪interface‪eth0‪da‪máquina‪física. A Figura 25 mostra
especificações da máquina virtual que foi criada neste projeto.
Figura 25 - Comando brctl show na máquina virtual.
B. Modo de Roteamento
Como mencionado, o roteador é o dispositivo de rede que está acima da
camada de enlace. Ele processa pacotes e os entrega através do endereço IP de
destino. O modo de roteamento do Xen funciona da mesma forma que um roteador
físico. Domínios hóspedes são roteados da Ethernet através do driver domain. Na
Figura 26, pode-se ver a topologia do Xen em seu modo de roteamento. O driver
domain atua como roteador direcionando os pacotes para os domínios hóspedes.
Figura 26 - Topologia do Xen em seu modo de roteamento [12].
65
Para habilitar o modo router é necessário descomentar a configuração
network-script network-route, adicionalmente deve-se inserir o seguinte script em
etc/xen/scripts/networks-route:
Echo 1 > /proc/sys/net/ipv4/ip_forward
Echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp
A primeira linha deste comando é a linha padrão do script, que indica que o
driver domain passa a atuar como um roteador. A segunda linha indica o script do
default gateway, pois quando o proxy ARP é configurado o roteador atua como um
proxy ARP, respondendo a requisição ARP do domínio hóspede quando o endereço
de destino se encontra em outra rede. É importante observar que sem a adição da
segunda linha, caso o domínio hóspede envie pacote ICMP para a rede externa este
não recebe nenhuma resposta. O domínio hóspede questiona a sua interface
externa, mas como resposta recebe o endereço MAC da própria interface virtual
externa. A Figura 27 mostra o disparo da máquina virtual para uma máquina real de
IP 152.92.155.21.
Figura 27 - O comando ping não recebe resposta.
Após a realização deste procedimento, percebe-se que o domínio hóspede
recebe resposta da máquina de destino, como mostra a Figura 28, o domínio
hóspede pode agora se comunicar pela internet.
66
Figura 28 - Domínio hóspede comunicando-se com a Internet.
Depois de inicializar o domínio hóspede deve-se configurá-los como mostra o
exemplo abaixo:
Vif‪=‪[‪„ip‪=‪128.153.144.96‟‪]
NETMASK‪=‪“255.255.255.0”
GATEWAY‪=‪“128.153.144.204”
Assim todos os pacotes que chegarem a interface física do driver domain
serão encaminhados de acordo com a tabela de roteamento. Por outro lado, todos
os pacotes que saírem dos domínio hóspedes serão encaminhados ao gateway.
Para confirmar a configuração, utiliza-se o comando ifconfig -a. Para maiores
informações sobre o modo de roteamento, veja [12].
C. Modo NAT
O gateway NAT funciona de forma semelhante ao modo de roteamento, com
a diferença de que há um mapeamento de porta para cada par de IP/porta
(soquete). No modo NAT os domínios hóspedes se encontram por trás do driver
domain. Por trás da rede virtual os domínios hóspedes se encontram em sua própria
rede privada, cada qual com seu endereço IP privado. Contudo, na Internet não há
ciência da existência dos domínios hóspedes, não sendo possível comunicar-se com
67
eles por meio de seus endereços IPs. Os dados de determinada sub-rede passam
pelo drive domain com diferentes números de porta.
O gateway NAT traduz os pacotes que chegam em uma porta para o interior
do domínio hóspede e sua apropriada aplicação. Por exemplo, a máquina 10.0.0.11,
inicia uma conexão TCP pela porta 6789, o gateway NAT pode mudar o endereço de
pacote de saída para que pareçam vindos do IP 128.153.145.111 e porta 9876. O
gateway NAT irá perceber que o tráfego de entrada pela porta 9876 deverá ser
encaminhado para o soquete 10.0.0.11/6789. Isso é possível para que múltiplos
hosts compartilhem o mesmo endereço IP a fim de acessar a Internet. A Figura 29
mostra o esquema do funcionamento em modo NAT.
Figura 29 - Esquema do funcionamento em modo NAT [14].
Para habilitar o modo NAT, deve-se descomentar a configuração (networkscript network-nat) e (vif-script vif-nat) no script etc/xen/scripts/networks-route. Como
o funcionamento em modo NAT não faz parte do escopo deste projeto, para obter
maiores informações veja [12].
68
3.2 Virt-manager
Para realizar a instalação do Xen Cloud Platform, utilizou-se o gerenciador de
máquinas virtuais. O virt-manager é um software37 flexível e livre. Para que haja a
conexão do Xen Cloud Platform com a Internet é necessário criar um script para
associar a interface eth0 a bridge “virbr0”.‪Este‪script‪deve‪ser‪executado‪no‪terminal‪
do Linux antes de se iniciar o Virt-manager. Para visualizar o script veja o apêndice
A. O procedimento de instalação do XCP pode ser visto no apêndice B.
Abaixo seguem as configurações dos computadores que foram utilizados para
a instalação do XCP, bem como a instalação de suas respectivas máquinas virtuais.

será chamado de PC1 o computador com as seguintes configurações:
Hardware: Intel Core 2 quad-core @ 2.83GHz, 8GB RAM;

será chamado de PC2 o computador com as seguintes configurações: Intel
Core i7-3770 CPU @ 3.4GHz x8, 8GB de memória RAM;

ambos possuem o sistema operacional: Ubuntu 12.04x64;

ambos possuem suporte para virtualização completa;

a taxa Ethernet é de 100Mbs, full Duplex para ambos.
Estas máquinas se encontram dentro do Laboratório de PROcessamento de
Sinais, Aplicações Inteligentes e Comunicações (PROSAICO). O procedimento para
a instalação da máquina virtual pode ser visto do Apêndice C.
37
Ferramenta de virtualização utilizada para instalar o XCP sobre a máquina real[12].
69
3.3 XenCenter
Para a criação das máquinas virtuais e gerenciamento das mesmas utilizouse o aplicativo XenCenter. Ele é um console gráfico que permite a administração de
modo centralizado de todos os servidores da nuvem. Com ele pode-se iniciar,
reiniciar e monitorar as máquinas virtuais, bem como instalá-las sobre o Xen Cloud
Platform [10]. Após conectar o XenCenter ao XCP, é exibido algo como na Figura
30.
Figura 30 - Interface gráfica do XenCenter.
No momento de se conectar ao XCP ele pede o IP da máquina além de sua
senha. Quando a conexão é estabelecida é possível criar as máquinas virtuais, bem
como verificar o console do XCP. Neste projeto criou-se duas máquinas virtuais, com
sistema operacional Linux Ubuntu 10.04. Cada uma delas está em um computador
diferente.
70
4. Resultados Experimentais
Com a rede em perfeito funcionamento, e as máquinas virtuais criadas,
utilizou-se a ferramenta Iperf para realizar os testes de desempenho da rede. O Iperf
é um software livre do tipo cliente/servidor. Com ele pode-se testar e medir a vazão
da rede além de avaliar outros parâmetros como Jitter e perda de pacotes[28].
Para utilizar o Iperf basta iniciá-lo em modo servidor em uma máquina,
utilizando o comando:
>Iperf –s
Enquanto que na outra máquina deve-se iniciá-lo em modo cliente, com o comando:
>Iperf –c <IP_do_Servidor>
Dessa forma, o cliente passará a enviar tráfego TCP para o servidor por 10
segundos, e em seguida mostrará a quantidade de dados transferidos (MBytes) e a
taxa atingida (Mbits/s).
O Iperf realiza testes TCP, que é o seu padrão, e testes UDP, executando os
seguintes comandos no servidor e no cliente, respectivamente
>Iperf –s –u (no servidor)
>iperf –c <IP_do_Cliente> -u
Para mais detalhes sobre os comandos do Iperf, ver [28].
Para a avaliação do desempenho da rede deste projeto foram transmitidos
fluxos UDP, variando-se a banda utilizada, utilizando os valores de: 250Kbits/s,
500Kbits/s 750Kbits/s, 1Mbits/s, 1,25Mbits/s e 1,5Mbits/s. Para cada uma desses
valores de banda foi tirada a média do resultado de dez testes. Realizaram-se
também testes com fluxo TCP. Cada fluxo também foi enviado dez vezes, e
considerou-se um intervalo de confiança de 95% para a média. O intervalo de
confiança será representado pela barra vertical nos gráficos. O intervalo de
confiança [80] da média de n amostras pode ser definido da seguinte forma:
𝐼𝐶 = 𝑋 +
−𝑡
𝑆
𝑛
,
(4)
Onde, 𝑋 é a média das amostras; é um valor obtido através de uma tabela de
quantis da distribuição t, chamado Valor Crítico; S é o desvio das amostras; e n é a
quantidade de amostras, que neste caso é dez.
71
4.1 Ambientes de testes.
Para realizar os testes de desempenho de rede, criaram-se os seguintes
ambientes:
A. Ambiente CRSR – C2S1: a máquina real no PC1 funciona como servidor e a
máquina real no PC2 funciona como cliente, como ilustrado na Figura 31.
Figura 31 - Ambiente de teste CRSR – C2S1.
B. Ambiente CRSR – C1S2: a máquina real no PC1 funciona como cliente e a máquina
real no PC2 funciona como servidor, como ilustrado na Figura 32.
Figura 32- Ambiente de teste CRSR – C1S2.
72
C. Ambiente CRSV – C2S1: a máquina virtual no PC1 funciona como servidor e a
máquina real no PC2 funciona como cliente, como ilustrado na Figura 33.
Figura 33 - Ambiente de teste CRSV – C2S1.
D. Ambiente CVSR – C1S2: a máquina virtual no PC1 funciona como cliente e a
máquina virtual no PC2 funciona como servidor, como apresentado na Figura 34.
Figura 34 - Ambiente de teste CVSR – C1S2.
73
E. Ambiente CVSR – C2S1: a máquina real no PC1 funciona como servidor e a
máquina virtual no PC2 funciona como cliente, como ilustrado na Figura 35.
Figura 35 - Ambiente de teste CVSR – C2S1.
F. Ambiente CRSV – C1S2: a máquina real no PC1 funcionando como cliente e a
máquina virtual no PC2 funciona como servidor, como visto na Figura 36.
Figura 36 - Ambiente de teste CRSV – C1S2.
G. Ambiente CVSV – C2S1: a máquina virtual no PC1 funciona como servidor e a
máquina virtual no PC2 funciona como cliente, como apresentado na Figura 37.
74
Figura 37 - Ambiente de teste CVSV – C2S1.
H. Ambiente CVSV – C1S2: a máquina virtual no PC1 funcionando como cliente e a
máquina virtual no PC2 funciona como servidor, como ilustrado na Figura 38.
Figura 38 - Ambiente de teste CVSV – C1S2.
Para todos os testes formam feitas análises com TCP e UDP.
4.2 Resultados
Inicialmente, avaliou-se a vazão para cada um dos ambientes de teste
75
utilizando-se o Iperf realizando a transmissão via fluxo TCP. Analisando os gráficos
das Figuras 39 e 40, percebe-se que a taxa de transferência dos ambientes CRSR
– C2S1, CRSR – C1S2 e dos ambientes CVSR – C2S1, CRSV – C1S2, CRSV –
C2S1, CVSR – C1S2 são semelhantes, ou seja, neste caso a ferramenta de
virtualização é transparente para a rede. Percebe-se que quando o PC2 funciona
como servidor os resultados são equivalentes, indicando que neste caso o
desempenho não depende do fato da máquina funcionar como servidor ou como
cliente.
Figura 39 - Gráfico de Vazão usando o Iperf/TCP considerando o PC1 como
servidor.
76
Figura 40 - Gráfico de Vazão usando o Iperf/TCP considerando o PC1 como cliente.
Quando se comparam os ambientes CRSV – C2S1 e CVSV – C2S1, no
gráfico da Figura 39, e os ambientes CRSR – C1S2 e CVSV – C1S2, no gráfico da
Figura 40, percebe-se uma leve queda na taxa de transferência. Isso acontece
possivelmente pela inserção das duas máquinas virtuais, e suas respectivas
camadas de virtualização que exigem mais do poder de processamento dos
computadores.
Utilizaram-se também fluxos UDP através do Iperf para analisar a rede. Neste
caso, os fluxos UDP podem representar a transferência de conteúdo multimídia,
como vídeo, por exemplo. Nestes testes avaliou-se a variação do atraso entre
pacotes (Jitter), métrica importante para a transmissão de vídeo na rede [30]. De
acordo com os gráficos da Figura 41 e 42, não há um aumento do jitter de forma
considerável. Este leve aumento pode ser explicado pela inserção da camada de
virtualização. Como foi visto no capítulo 3 devido a sua arquitetura esta camada
insere um maior tempo no processamento dos pacotes. Ainda assim o maior valor
de jitter medido, foi em torno de 0,5ms, o que, de acordo com [31] não compromete
o desempenho da rede.
77
Figura 41 - Gráfico do Jitter usando o Iperf/UDP, considerando o PC1 como servidor.
78
Figura 42 - Gráfico do Jitter usando o Iperf/UDP, considerando o PC2 como servidor.
É importante ressaltar que em todos os testes realizados, não foi identificada
a perda de pacotes, indicando que mesmo com a camada de virtualização, a rede
continua estável. É importante comentar que a vazão da rede em todos os testes
considerando fluxos UDP atingiu o seu valor máximo. Dessa forma, entende-se que
se podem aproveitar os benefícios de se utilizar a máquina virtual, sem que seja
necessário comprometer o desempenho da rede. Em todos os testes realizados a
rede com a presença de máquinas virtuais se manteve com o desempenho
praticamente inalterado.
79
5. Conclusão
Neste trabalho procurou-se avaliar o impacto de máquinas virtuais presentes
em uma rede local, dentro do Laboratório de PROcessamento de Sinais, Aplicações
Inteligentes e Comunicações (PROSAICO). Com isso criaram-se as máquinas
virtuais, utilizando a ferramenta de virtualização Xen Cloud Platform. Com os
ambientes de testes montados realizaram-se os testes de fluxo UDP e de fluxo TCP
utilizando a ferramenta iperf. Assim pode-se avaliar a qualidade de serviço da rede
na presença de máquinas virtuais além de aprofundar os conhecimentos na
arquitetura Xen, e contribuir para o estudo sobre virtualização e máquinas virtuais.
5.1 Discussão sobre o Xen
Um grande benefício do hypervisor do Xen é sua neutralidade com relação
aos vários sistemas operacionais, permitindo a
coexistência de vários sistemas
operacionais como Linux, Solaris, DBS, entre outros.
O aspecto crítico para a escolha do hypervisor é garantir que a solução seja
segura especialmente quando a solução é implantada no ambiente empresarial. O
Xen prove uma serie de ferramentas de segurança, como por exemplo, cada
Domínio U é isolado do outro além de não haver nenhuma forma de acesso a
memória ou acesso via rede. Somente o Domínio 0 tem o privilégio de se comunicar
com o hardware via hypervisor.
Com relação ao desempenho, o hypervisor do Xen permite que o sistema
operacional hóspede coopere com o hypervisor a fim de melhorar o desempenho
para operações de I/O, CPU, e memória de virtualização. O domínio hóspede tem
ciência que está sendo executado em uma plataforma virtualizada e está apto a dar
assistência ao hypervisor em uma série de tarefas.
As diretivas de segurança preveem restrições ao hardware de forma que não
haja interações entre hosts. Ter o hypervisor separado do sistema operacional
aumenta incrivelmente o desempenho. Qualquer operação feita deverá obedecer a
uma série de tarefas que são padronizadas, e a maior partes dessas tarefas não são
relatadas ao processo dos domínios hospedes o que impacta em maior
desempenho. O hypervisor do Xen está apto a processar a virtualização para
80
hospedes sem maior operação no sistema de modo a estar sintonizado ao
processamento dos mesmos, à demanda dos usuários e as requisições do host. O
padrão dentro do Xen é customizar o ambiente de forma assegurando que a
infraestrutura do Xen seja capaz de atingir a expectativa dos usuários.
A plataforma Xen é a mais usada em ambientes de Cloud computing. Líderes
como Amazon, Cloud.com, GoGrid, e Rackspace se beneficiam de suas vantagens.
A plataforma Xen oferece um pacote completo de serviços para provedores de
serviço que queiram operar com uma infraestrutura virtualizada. O Xen também está
presente em soluções dos fornecedores Avaya, Cisco, Citrix, Fujitsu, Lenovo, Novell,
Oracle, Samsung, VALinux, e outros.
A virtualização já deixou de ser uma tendência para ser uma realidade no
mundo corporativo já que além da economia de recurso trata-se também de uma
tecnologia verde. Com virtualização pode-se executar vários serviços, programas, ou
até mesmo sistemas operacionais possibilitando simular hardwares diferentes em
um único equipamento, como roteadores, switches, servidores e celulares.
5.2 Análise dos resultados
Considerando os resultados dos testes, podem-se perceber algumas
vantagens no uso da virtualização utilizando o Xen Cloud Platform. Pode-se
gerenciar as máquinas virtuais remotamente, criar várias máquinas virtuais em um
servidor, otimizando os recursos da máquina. Além disso, podem ser percebidos
benefícios de economia de recursos, segurança, entre outros. Também podemos
avaliar, com a ferramenta iperf, a qualidade de serviço da rede bem como suas
características de desempenho.
Os resultados encontrados em todos os ambientes de teste mostra que se
pode ter um ambiente de rede com desempenho semelhante a uma rede sem
virtualização. Sua taxa de transferência manteve-se constante e sem perda de
pacotes. Ao se avaliar o Jitter com os testes de fluxo UDP, percebeu-se um leve
aumento no Jitter, entretanto, como já foi discutido, este aumento não afeta o
desempenho da rede nem mesmo em aplicações de fluxo de vídeo. Isto mostra que
mesmo com a camada de virtualização presente, a rede é capaz de suportar as
demandas de transmissão de imagem e vídeo.
81
Neste trabalho, encontram-se os tutoriais de instalação do XCP e das
máquinas virtuais, bem como conteúdos necessários para um bom conhecimento da
virtualização e da ferramenta Xen a fim de contribuir para o enriquecimento da
literatura e disseminação do conhecimento nesta área.
Das contribuições deste trabalho, pode-se perceber que com o Xen Cloud
Platform, o cliente poderá implementar a infraestrutura do fornecedor a sua escolha
e oferecer serviços de virtualização em código aberto para cliente, nuvens e
servidores. Pode-se perceber ao longo deste trabalho que a proposta é criar uma
plataforma de inovação, facilitando uma infraestrutura que oferece mais flexibilidade
e maior qualidade de serviço e, ao mesmo tempo, redução de custo e eficiência na
utilização de recursos.
5.3 Trabalhos Futuros
Como proposta para trabalhos futuros tem-se a criação de uma VPN (Virtual
Private Network). Com a VPN pode-se enviar pacotes a hosts da rede pública como
se estes fizessem parte da nossa rede privada. Seria interessante testar o
desempenho da rede utilizando-se VLANs, podendo segmentar a rede em mais
domínios de broadcast, e avaliar o impacto das máquinas virtuais neste contexto.
Pretende-se comparar o desempenho do XCP com outras ferramentas de
virtualização, como VirtualBox, VmWare, e OpenFlow [1,2,3]. Com estas
comparações espera-se avaliar o XCP em diferentes contextos e compará-lo com
outras ferramentas de virtualização.
Além disso, também pretende-se testar o desempenho da rede utilizando o Xen em
modo de roteamento ou em modo NAT.
82
Referências
[1] Moreira, M. D. D, Fernandes, N. C., Costa, L. H. M. K., Duarte, O. C. M. B.,
Internet do Futuro, Um Novo Horizonte, 27º. SBRC, Minicurso cap.1, pp1-59, 2009.
[2] Fernando N. N. Farias, José M. Dias Júnior, João J. Salvatti, Sérgio Silva,
Antônio J. G. Abelém, Marcos R. Salvador and Michael A. Stanton. Pesquisa
Experimental para a Internet do Futuro: Uma Proposta Utilizando Virtualização e o
Framework Openflow. Capítulo 1. XXIX Simpósio Brasileiro de
Redes de
Computadores e Sistemas Distribuídos.
[3] Keith W. Ross e James F. Kurose. Redes de Computadores e a Internet:
Uma Abordagem Top-down. 3ᵃ ed. São Paulo: Pearson Addison Wesley, 2006.
[4] Andrew S. Tanenbaum. Computer Networks. 3ᵃ ed. Prentice Hall PTR: New
Jersey, 1996.
[5] Farias, F. N. N., Júnior, J. M. D., Salvatti, J. J., Silva, S., Abelém, A. J. G.,
Salvador,‪M.‪ R.,‪ Stanton,‪ M.‪ A.,‪ “Pesquisa‪ Experimental‪para‪ a‪ Internet‪ do‪ Futuro:‪
Uma Proposta Utilizando Virtualização e o Framework Openflow”,‪ 29°‪ SBRC,‪
Minicurso cap.1, pp19-34, 2011.
[6] Hugo E. T. Carvalho., Controle de Acordos de Nível de Serviço em Redes
Virtuais Baseado em Lógica Nebulosa [trabalho de conclusão de curso]. Rio da
Janeiro. Universidade Federal do Rio de Janeiro. COPPE-UFRJ. Departamento de
Eletrônica e de Computação; 2011.
[7] Paul, S., Pan, J., Jain, R., Architectures for the future networks and the
next generation Internet: A survey. Computer Communications. 2011 Jan 15. Sect: 242.
[8] Braden, R., Clark, D., Shenker, S., Wroclawski, J., Developing a NextGeneration Internet Architecture. White paper, DARPA; 2000;
[9] Igor M. Moraes, Pedro S. Pisa, Hugo E. T. Carvalho, Rafael S. Alves, Lyno
Henrique G. Ferraz, Tiago N. Ferreira, Rodrigo S. Couto, Daniel José da Silva Neto,
Victor P. da Costa, Renan A. Lage, Luciano V. dos Santos, Natalia C. Fernandes,
Miguel Elias M. Campista, Luís Henrique M. K. Costa, Otto Carlos M. B. Duarte.,
VNEXT: Uma Ferramenta de Controle e Gerenciamento para Redes Virtuais
Baseadas em Xen [artigo]. Rio de Janeiro. Universidade Federal do Rio de Janeiro;
2011.
83
[10] Alexandre Carissini. Virtualização: da teoria a soluções. Capítulo 4.
Universidade Federal do Rio Grande do Sul. Instituto de Informárica. 26º Simpósio
Brasileiro de Redes de Computadores e Sistemas Distribuídos; 2008.
[11]‪ Apostol‪ T.‪ Vassilev.‪ “Security Benefits from OS Virtualization: Real or
Virtual ? [paper]; 2007.
[12] Jeanna N. Matthews, Eli M, Dow. Todd Deshane, Wenjin Hu, Jeremy B.
P. F. Wilbur, Brendan Johnson. Running Xen: A Hands-On Guide to the Art of
Virtualization. Prentice Hall: Boston, 2008.
[13] Xen.org. Citrix Systems, Inc; [acesso em 1 de Dezembro de 2012].
Disponível em: http://www.xen.org.
[14] Xen.org. Citrix Systems, Inc; [acesso em 1 de Dezembro de 2012].
Disponível em: http://www.xen.org/download/xcp/index.html.
[15] pdub.net. Patrick F. Wilbur; [acesso em 1 de Dezembro de 2012]
Disponível em: http://pdub.net/2011/12/03/howto-install-xcp-in-kvm/.
[16] Ubuntu Documentation. Free license; [acesso em 1 de Dezembro de
2012]. Disponível em: https://help.ubuntu.com/community/KVM/Installation.
[17] Dedoimedo.com. Dedoimedo.com; [acesso em 10 de Janeiro de 2013]
Disponível em: http://www.dedoimedo.com/computers/xen-cloud.html.
[18] Rodrigo dos Santos B. G. Barbosa, Djamel F. H. Sadok. Calculando
métricas unidirecionais na Internet [Trabalho de conclusão de curso]. Universidade
Federal de Pernambuco. Centro de Informática; 2005.
[19] UFForense – Forense computacional; [acesso dia 10 de Janeiro de
2013].
Disponível em:
http://ufforense.wordpress.com/2011/08/05/introducao-as-
redes-de-computadores-modelo-osi.
[20] Arquitetura e Protocolos TCP/IP. [acesso dia 15 de Janeiro de 2013].
Disponível em: http://www.diegomacedo.com.br/arquitetura-e-protocolos-tcp-ip/.
[21] Popek, Gerald J. e GOLDBERG, Robert P. Formal Requirements for
Virtualizable Third Generation Architeture [paper]. Communications of the ACM.
Volume 17, Número 7, Jul de 1974.
[22] IBM. United States: IBM.inc; [acesso dia 15 de Janeiro de 2013].
Diponível em: www.ibm.com.
[23] Wlodarz, J. J. Virtualization: A Double-edged sword [paper]. 2007.
84
[24] Laureano, M. A. P., Detecção de Instrução em Máquinas Virtuais.
Pontifícia Universidade Católica do Paraná. 5º Simpósio de Segurança em
Informática - SSI. São José dos Campos, 2003. P. 1 – 7.
[25] Laureano, M. A. P., Uma abordagem para a Proteção de Detectores de
Intrusão Baseada em Máquinas Virtuais[ dissertação de Mestrado]. Curitiba.
Pontifícia Universidade Católica do Paraná, 2004.
[26]Virtualização: a TI virtual. IBM.inc; [acesso em 15 de Janeiro de 2013];
Disponível em: http://www.ibm.com/midmarket/br/pt/articles_businessunit_4Q03.html
[27] Redes e Servidores. [acesso em 15 de Janeiro de 2013]. Disponível em:
http://redes-e-servidores.blogspot.com.br/2011/11/virtualizacao-total-explicada.html.
[28] Iperf.fr. Iperf Licence. [acesso dia 12 de Janeiro de 2013]. Disponível em:
http://iperf.fr/.
[29] XenServer/Networking Flags.[acesso em 15 de Janeiro de 2013].
Disponível em: https://wiki.openstack.org/wiki/XenServer/NetworkingFlags.
[30] Diogo M. F. Mattos, Lyno Henrique G. Ferraz, Luís Henrique M. K. Costa,
and Otto Carlos M. B. Duarte, Virtual Network Performance Evaluation for Future
Internet Architectures. Universidade Federal do Rio de Janeiro - GTA/COPPE/UFRJ.
[31] Dalbert M. Mascarenhas, Felipe da Rocha Henriques, Glauco F. Amorim
e Luis C. dos Santos C. Retondaro. Avaliação da Transferência de Fluxos Multimídia
em uma rede em Malha Sem Fio. XXX Simpósio brasileiro de Telecomunicações.
SBrT‟12.
85
Apêndice A
#!/bin/bash
ifconfig eth0 down
ifconfig lo down
ifconfig virbr0 down
ifconfig wlan0 down
brctl addif virbr0 eth0
ifconfig wlan0 up
ifconfig lo up
ifconfig virbr0 up
ifconfig eth0 up
sudo /etc/init.d/networking restart
86
Apêndice B: Instalação do Xen Cloud Platform.
Para instalar o Xen Cloud Platform deve-se realizar os seguintes
procedimentos:
A - Instalando os Pacotes necessários
Os seguintes pacotes precisam ser instalados no Ubuntu:
-kvm
-virt-manager
Abra o terminal do Linux (Ctrl+Alt+T) e execute o comando:
sudo apt-get install qemu-kvm libvirt-bin bridge-utils
Adicione os seguintes pacotes adicionais:
sudo apt-get install virt-manager vinagre
Para saber se máquina suporta virtualização, execute os seguintes
comandos:
egrep -c '(vmx|svm)' /proc/cpuinfo
Se aparecer 0, o CPU não suporta virtualização de hardware. Se aparecer 1,
ou outro valor, pode-se habilitar a virtualização pelo BIOS. Alternativamente pode-se
executar o seguinte comando:
kvm-ok, se aparecer:
INFO: /dev/kvm exists
KVM acceleration can be used
Pode-se utilizar o kvm, mas se aparecer:
INFO: Your CPU does not support KVM extensions
KVM acceleration can NOT be used
Pode-se
comprometido.
até
rodar
máquinas
virtuais,
porém
o
desempenho
será
B - Fazendo o download do Xen Cloud Platform (XCP).
Após executar esses comandos, o próximo passo é baixar a imagem iso do
XCP.
Utilizou-se neste projeto o XCP 1.6, e pode ser baixado no seguinte endereço:
http://xen.org/download/xcp/index_1.6.0.html
87
Após baixar a imagem, a copie para outro diretório sem ser o home. Para
resolver isso criou-se o diretório da seguinte forma (com o nome de vmimages):
sudo mkdir /vmimages
Copie a imagem para este diretório usando o comando cp:
sudo “local_conde_está_a_imagem”/”nome _a_imagem_que _se_quer_copiar “cp
/vmimages
C- Instalando o XCP no Kvm.
Agora a máquina virtual será criada, e assim será instalado o XCP dentro
desta máquina virtual. No terminal execute o comando:
sudo virt-manager
1. No canto superior esquerdo há um ícone de janela de gerenciamento de
virtualização, clique em create a new virtual machine.
2. Clique em: usar imagem iso. Busque a imagem no diretório onde salvamos
ela e clique em avançar.
88
3. Escolha o quantidade de memória (RAM) da sua máquina virtual e o número
de máquinas virtuais. Obedecendo ao critério de que cada máquina virtual
deverá ter no mínimo 2MB de memória.
4. Habilite o armazenamento para a máquina virtual. Escolha o tamanho do
disco rígido da máquina virtual. E selecione alocar o disco inteiro agora.
Clique em avançar.
5. Escolha‪ as‪ configurações‪ de‪ rede,‪ selecione‪ Rede‪ virtual‪ „default‟:‪ NAT,‪ e‪
escolha o tipo de arquitetura se é 86(32bits) ou 64. Clique em Concluir para
iniciar a instalação.
89
Completando a instalação do XCP:
A instalaçao do XCP está programada para começar logo após a criação da máquina
virtual. Assim continue com os seguintes passos:
6. Reinice a máquina virtual para que o XCP comece a instalação,
primeiramente, selecione a configuração do teclado, selecione a configuração
desejada e clique em OK
90
7. Ele irá perguntar : load a device driver or simply proceed with the installation.
Selecione OK e continue com o processo de instalação
8. Aceite os termos do software clicando em Accept Eula.
91
9. Selecione conforme a imagem acima e clique OK
10. Escolha usar o Local Media e clique OK
92
11. Quando ele perguntar: Whould you reach the Supplemental Packs prompt,
escolha não, se não sabe do que se trata.
12. Ele vai perguntar se quer que verifique a fonte de instalação, clique em OK
93
14. Ele vai pedir para definir um password e um login.
15. Habilite o DHCP
94
16. Ele vai pedir para você selecionar a área em que você está.
17.Continue com a instalação. Se decidir usar o NTP para a automática
configuração de tempo, três servidores são conhecidos, pode-se usar o
95
0.pool.ntp.org, 1.pool.ntp.org e2.pool.ntp.org.
18. Clique em Install XCP.
96
19. Se tudo der certo, pode-se ver a mensagem de instalation complete.
Clique em OK. Depois disso, reinicie a máquina virtual.
20. Se tudo der certo você verá a tela abaixo, que indica que o XCP está
97
inicializando dentro da sua máquina virtual.
21. Para finalizar, a tela principal do XCP aparecerá como na imagem a
seguir.
98
Apêndice C: Instalação da máquina Virtual no Citrix XenCenter.
1. Criando o local onde será armazenada a imagem iso
Primeiro, verifique a existência da pasta “/var/opt/xen/iso_import”.‪ Se‪ esta‪
pasta não existir, crie ela usando mkdir –p /var/opt/xen/iso_import.
2. Criando o repositório ISO.
Execute o seguinte comando:
xe
sr-create
name-label=MyISORepository
type=iso
device-
config:legacy_mode=true device-config:location=/var/opt/xen/iso content-type=iso
3. Baixando a Imagem
Entre neste link, e baixe a imagem do ubuntu( utilize a versão alternative):
https://launchpad.net/ubuntu/+cdmirrors
escolha um dos servidores.
http://mirror.globo.com/ubuntu/releases/12.04/
e escolha a imagem iso. Copie o link dela e cole no repositório que foi criado, junto
com o comando wget
wget
http://mirror.globo.com/ubuntu/releases/12.04/ubuntu-12.04.2-alternative-
amd64.iso
4. Com a imagem no repositório, criar a máquina virtual
Clique em Create a new virtual machine
Processo de Instalação do Ubuntu.
A. Selecione English.
99
B. Selecione South America.
100
B. Coloque o hostname, o nome do usuário e também a senha.
101
102
C. Escolha particionar o disco inteiro.
103
104
D. Selecione o Software que se quer instalar.
105
Após isso o Ubuntu encontra-se instalado no XCP.