1294053276

COPPE/UFRJ
AVALIAO EXPERIMENTAL DE TCNICAS DE VIRTUALIZAO

ATRAVS DE BALANCEAMENTO DE CARGA EM CLUSTERS DE
COMPUTADORES
Almir Dominicini Fernandes
Dissertao de Mestrado apresentada ao

Programa de Ps-graduao em Engenharia
de Sistemas e Computao, COPPE, da
Universidade Federal do Rio de Janeiro,
como parte dos requisitos necessrios
obteno do ttulo de Mestre em Engenharia
de Sistemas e Computao.
Orientador: Claudio Luis de Amorim
Rio de Janeiro
Setembro de 2010

COMPUTADORES
DISSERTAO SUBMETIDA AO CORPO DOCENTE DO INSTITUTO

ALBERTO LUIZ COIMBRA DE PS-GRADUAO E PESQUISA DE
ENGENHARIA (COPPE) DA UNIVERSIDADE FEDERAL DO RIO DE
JANEIRO COMO PARTE DOS REQUISITOS NECESSRIOS PARA A
OBTENO DO GRAU DE MESTRE EM CINCIAS EM ENGENHARIA DE
SISTEMAS E COMPUTAO.
Examinada por:
Prof. Claudio Luis de Amorim, Ph.D.
Prof. Felipe Maia Galvo Frana, Ph.D.
Prof. Alexandre Sztajnberg, D.Sc.
RIO DE JANEIRO, RJ BRASIL

SETEMBRO DE 2010
Fernandes, Almir Dominicini

Avaliao Experimental de Tcnicas de Virtualizao
atravs de Balanceamento de Carga em Clusters de
Computadores/Almir Dominicini Fernandes. Rio de
Janeiro: UFRJ/COPPE, 2010.
XII, 86 p.: il.; 29, 7cm.
Dissertao (mestrado) UFRJ/COPPE/Programa de
Engenharia de Sistemas e Computao, 2010.
Referncias Bibliogrficas: p. 62 67.
1. Virtualization. 2. Load Balance. 3. Migration. I.
Amorim, Claudio Luis de. II. Universidade Federal do Rio
de Janeiro, COPPE, Programa de Engenharia de Sistemas
e Computao. III. Ttulo.
iii
Resumo da Dissertao apresentada COPPE/UFRJ como parte dos requisitos

necessrios para a obteno do grau de Mestre em Cincias (M.Sc.)

COMPUTADORES

Setembro/2010

Programa: Engenharia de Sistemas e Computao
Apresenta-se, nesta dissertao, a comparao de duas tcnicas de virtualizao
de sistemas. Neste trabalho, avaliada a eficincia destas duas tcnicas de virtualizao. Essa avaliao ocorre em um cluster de mquinas fsicas, onde cada mquina
fsica suporta diversas mquinas virtuais, que por sua vez, podem migrar entre as
mquinas fsicas, sempre que esta migrao for necessria para balancear a carga
do sistema. Avalia-se tambm a eficincia das tcnicas em migrar as suas Mquinas
virtuais. Para montar o ambiente necessrio a esta avaliao, foi preciso desenvolver
um gerenciador de mquinas virtuais, que o responsvel por balancear a carga do
sistema. A apresentao deste gerenciador tambm est no escopo da dissertao.
iv
Abstract of Dissertation presented to COPPE/UFRJ as a partial fulfillment of the

requirements for the degree of Master of Science (M.Sc.)
EXPERIMENTAL EVALUATION OF VIRTUALIZATION TECHNIQUES BY

LOAD BALANCING IN A COMPURTER CLUSTER

September/2010
Advisor: Claudio Luis de Amorim

Department: Systems Engineering and Computer Science
In this work we present a comparison between two system virtualization techniques. We compare this techniques with respect to their efficiency, in an environment composed by two physical machines hosting several virtual machines, that can
be switched among the physical machines each time such migration is needed, due
to load balancing constraints. We also compare the efficiency of this two techniques
to migrate theirs virtual machines. In order to build our testing environment, we
developed a virtual machine manager that acts as a load balancer. The virtual
machine manager is also presented in this work.
Sumrio
Lista de Figuras
ix
Lista de Tabelas
xi
1 Introduo
1.1 Objetivos e Contribuies . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Organizao da Dissertao . . . . . . . . . . . . . . . . . . . . . . .
2 Virtualizao
2.1 Introduo . . . . . . . . . . . . . . . . .
2.1.1 Fundamentos . . . . . . . . . . .
2.1.2 Classes de Virtualizao . . . . .
2.1.3 Mquina Virtual de Sistema . . .
2.2 Tcnicas de virtualizao de Sistemas . .
2.2.1 A Virtualizao Clssica . . . . .
2.2.2 Virtualizao no Nvel do Sistema
2.3 Migrao de Mquinas Virtuais . . . . .
1
2
3
.
.
.
.
.
.
.
.
4
4
6
8
10
11
11
17
19
.
.
.
.
.
.
.
.
22
23
23
23
24
26
28
30
32
4 Avaliao Experimental
4.1 Objetivos dos Experimentos . . . . . . . . . . . . . . . . . . . . . . .
4.2 Ambiente Experimental . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Organizao dos Experimentos . . . . . . . . . . . . . . . . . . . . . .
34
34
35
38
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
Operacional
. . . . . . .
3 Virtualizao e Balanceamento de Carga

3.1 Tecnologias de Paravirtualizao e Containers . . . .
3.1.1 Eficincia . . . . . . . . . . . . . . . . . . . .
3.1.2 Isolamento . . . . . . . . . . . . . . . . . . . .
3.1.3 Gerencia de Recursos . . . . . . . . . . . . . .
3.1.4 Migrao . . . . . . . . . . . . . . . . . . . . .
3.2 Gerenciador de Mquinas Virtuais . . . . . . . . . . .
3.3 Algoritmo de Balanceamento de Carga . . . . . . . .
3.3.1 O Algoritmo de Balanceamento Implementado
vi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4.4
4.5
4.6
4.7
4.8
4.9
Aplicaes Utilizadas nos Experimentos . . . . . . . . . . . . .

4.4.1 Sinttica . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.2 Sinttica-Randmica . . . . . . . . . . . . . . . . . . .
4.4.3 Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . .
Validao Experimental do Gerenciador de Mquinas Virtuais
Experimento1 . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6.1 OpenVZ . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6.2 Xen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6.3 Comparao OpenVZ x Xen . . . . . . . . . . . . . . .
Experimento2 . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.7.1 OpenVZ . . . . . . . . . . . . . . . . . . . . . . . . . .
4.7.2 Xen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.7.3 OpenVZ x Xen . . . . . . . . . . . . . . . . . . . . . .
Experimento3 . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.8.1 OpenVZ . . . . . . . . . . . . . . . . . . . . . . . . . .
4.8.2 Xen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.8.3 OpenVZ x Xen . . . . . . . . . . . . . . . . . . . . . .
Discusso dos Resultados . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
41
41
42
42
43
44
45
46
46
48
48
49
49
51
52
53
54
54
5 Trabalhos Relacionados
56
5.1 Comparao entre Tcnicas de Virtualizao . . . . . . . . . . . . . . 56
5.2 Migrao de Mquinas Virtuais . . . . . . . . . . . . . . . . . . . . . 57
5.3 Balanceamento de Carga . . . . . . . . . . . . . . . . . . . . . . . . . 58
6 Concluses
59
6.1 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Referncias Bibliogrficas
62
A Migrao de Game Interativo no OpenVZ

A.1 Introduo . . . . . . . . . . . . . . . . . .
A.2 Migrao de Conteiners . . . . . . . . . . .
A.2.1 Live migration no Openvz . . . . .
A.3 Migrao em Bandas Limitadas . . . . . .
A.3.1 TC . . . . . . . . . . . . . . . . . .
A.4 Ambiente Experimental . . . . . . . . . .
A.5 Migrao de MV sem Aplicaes . . . . . .
A.5.1 Tempo Total de Migrao . . . . .
A.5.2 Downtime . . . . . . . . . . . . . .
A.6 Migrao de MVs Com Aplicaes Reais .
68
68
69
69
70
70
71
71
71
72
73
vii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
A.6.1 Descrio dos Experimentos . . . . . . . . . . . . . . . . . . . 73

A.6.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
A.7 Concluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
B O Gerenciador de MVs e o Ambiente Experimental
B.1 Detalhes do Algoritmo de Balanceamento . . . . . . .
B.2 Instalao do Gerenciador de Mquinas Virtuais . . .
B.3 Modificaes no Gerenciador Base . . . . . . . . . . .
B.3.1 Estrutura do Gerenciador . . . . . . . . . . .
B.3.2 Modificaes . . . . . . . . . . . . . . . . . . .
B.4 Dica . . . . . . . . . . . . . . . . . . . . . . . . . . .
Glossrio
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
76
77
77
80
80
80
81
82
viii
Lista de Figuras
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
Arquitetura de um sistema no virtualizado. . . . . . . . . . . . . .

Arquitetura de um sistema virtualizado. . . . . . . . . . . . . . . .
Mapeamento do sistema virtual em um sistema real. . . . . . . . . .
Arquitetura das camadas na virtualizao de processo. . . . . . . .
Viso da processo, na virtualizao de processo. . . . . . . . . . . .
Arquitetura das camadas na virtualizao de sistema. . . . . . . . .
Viso da mquina virtual na virtualizao de sistema. . . . . . . . .
Disposio do Monitor de Mquina Virtual nas camadas do sistema
virtualizado. O MMV com o maior privilgio do sistema. . . . . . .
2.9 Disposio do Monitor de Mquina Virtual nas camadas do sistema
virtualizado. O MMV no nvel de privilgio de aplicao do SO. . .
2.10 Disposio do Monitor de Mquina Virtual nas camadas do sistema
virtualizado. O MMV ora no nvel de privilgio da aplicao, ora no
maior nvel de privilgio do sistema. . . . . . . . . . . . . . . . . . .
2.11 Virtualizao no nvel do SO. . . . . . . . . . . . . . . . . . . . . .
3.1
3.2
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
.
.
.
.
.
.
.
7
7
8
10
10
11
11
. 13
. 13
. 13
. 18
Estrutura do anel de E/S, o qual usado para transferir dados entre

o Xen e as mquinas virtuais hospedadas. . . . . . . . . . . . . . . . 26
Arquitetura do balanceador de carga do sistema. CL representa o
Controle Local. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Sistema Experimental. . . . . . . . . . . . . . . . . . . . . . . . . .
Configurao Balanceada . . . . . . . . . . . . . . . . . . . . . . . .
Configurao Desbalanceada. . . . . . . . . . . . . . . . . . . . . .
Grfico do consumo total de CPU de trs Mquinas Fsicas. Cada
cor representa carga gerada por uma mquina virtual. . . . . . . . .
Experimento1, OpenVZ. Tempo de execuo das MVs. . . . . . . .
Experimento1, XM. Tempo de execuo das MVs. . . . . . . . . . .
Experimento1, OpenVz x Xen. Tempo de execuo das MV. . . . .
Experimento1, OpenVz x Xen. Tempo de execuo mdio das MV. .
Experimento2, OpenVZ. Tempo de execuo das MVs. . . . . . . .
ix
. 37
. 39
. 40
.
.
.
.
.
.
44
45
46
47
48
49
4.10
4.11
4.12
4.13
4.14
4.15
Experimento2,
Experimento2,
Experimento2,
Experimento3,
Experimento3,
Experimento3,
XM. Tempo de execuo das MVs. . . . . . . . . . .

OpenVz x Xen. Tempo de execuo das MV. . . . .
OpenVz x Xen. Tempo de execuo mdio das MV. .
OpenVZ. Tempo de execuo das MVs. . . . . . . .
.
.
.
.
.
.
50
50
51
52
53
54
A.1 Tempo Total de Migrao: tempo(s) X Banda (MB) . . . . . . . . . . 72

A.2 Downtime: tempo(s) X Banda (MB) . . . . . . . . . . . . . . . . . . 73
Lista de Tabelas
4.1
4.2
4.3
Especificao de Software - OpenVZ. . . . . . . . . . . . . . . . . . . 35

Especificao de Software - Xen. . . . . . . . . . . . . . . . . . . . . . 35
Especificao do Hardware. . . . . . . . . . . . . . . . . . . . . . . . 36
xi
Lista de Listagens
4.1 Sinttica1.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2 Sinttica-radomica.py . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
B.1 Algoritmo de Balanceamento Implementado . . . . . . . . . . . . . . 77
xii
Captulo 1
Introduo
Nos ltimos vinte anos, a tecnologia da informao tem viabilizado solues disruptivas, que acontecem com velocidades cada vez mais espantosas. A disponibilidade,
a rapidez, a maneira de acesso e a forma como so computados os dados e informaes, afeta diretamente a operao das empresas, e tambm, a forma de se comunicar, sociabilizar e trabalhar das pessoas. Assim, a tecnologia da informao serve
de base para mudanas de conceitos e quebra de paradigmas que tm, de maneira
cada vez mais frequentes, influenciado a vida de mais pessoas. A virtualizao est
certamente entre as principais tecnologias capaz de proporcionar tais mudanas.
O uso de virtualizao em servidores uma tendncia mundial. A explicao
desta adoo, est na maneira como a virtualizao de servidores resolve alguns
dos problemas impostos s empresas, cujo negcio, est diretamente relacionado
a tecnologia da informao. Com a virtualizao de servidores, pode-se melhor
aproveitar o espao fsico, reduzir substancialmente o custo com manuteno, infra
estrutura e energia eltrica. E esta ltima, alm de implicar na reduo dos custos,
condiz com as prticas das empresas que adotam a TI verde 1 . O impacto da
virtualizao no se restringe a esses aspectos. Combinada com a computao em
cluster, a virtualizao se torna uma das tecnologias que servem como base para
o surgimento da cloud computing 2 , ou computao na nuvem. A computao na
nuvem est mudando a maneira das empresas enxergarem as reas de TI. E por
outro lado, as empresas de TI tero que se adaptar para desenvolver novos produtos
e servios que estaro imersos nessa nova realidade.
Usar a tecnologia de virtualizao nos clusters de computadores, possibilita aumentar a utilizao dos clusters. A virtualizao permite uma utilizao mais flexvel
1
TI verde um conjunto de prticas para tornar mais sustentvel e menos prejudicial o uso da
tecnologia da informao
2
Cloud Computing um modelo de computao onde o processamento, o armazenamento e
o software, so acessados remotamente e esto em algum lugar no necessariamente conhecido
por quem os usa. Apesar desta ser uma das definies, vale lembrar que cloud computing um
paradigma ainda em evoluo, cujas definies ainda no so muito claras.
das mquinas de um cluster. Os utilizadores de um cluster tm flexibilidade para

escolher seu prprio sistema operacional e seu prprio ambiente de execuo, criando seu prprio cluster virtual. O cluster fsico pode ser usado simultaneamente
por vrios clusters virtuais. As mquinas virtuais podem ser balanceadas entre as
mquinas do cluster, de maneira a melhorar vazo do sistema. As mquinas do cluster podem ser ligadas ou desligadas de acordo com a demanda, visando a economia
de energia. O isolamento proporcionado pelo uso de mquinas virtuais nos clusters permite que um cluster seja usado por aplicaes com caractersticas diversas.
Isso implica em dizer que, pessoas ou empresas poderiam usufruir deste sistema,
ou tambm, que pessoas ou empresas poderiam pagar para que, por exemplo, seus
servidores de aplicaes fossem executados num cluster remoto. Ambientes semelhantes a este, como o EC2[55] da Amazon, j so realidades, e sua adoo, por
empresas, crescente.
Todo este cenrio serviu como motivao para alcanar os objetivos desta dissertao.
1.1
Objetivos e Contribuies
O objetivo desta dissertao comparar a eficincia de duas solues de virtualizao

que implementam tcnicas distintas. Para isso, ser analisado o comportamento das
tcnicas de virtualizao, quando as mquinas virtuais executam em um cluster de
computadores, sendo que, as mquinas virtuais podem migrar entre as mquinas
do cluster. As migraes ocorrem com a finalidade de balancear a carga entre as
mquinas do sistema e so determinadas por um programa que gerencia as MVs.
As constribuies desta dissertao so as seguintes:
Avaliao de duas tcnicas de virtulaizao Cumprindo os objetivos propostos, foram avaliadas duas tcnicas de virtualizao de sistemas. Esta dissertao apresenta e compara as caractersticas e dificuldades das tcnicas de
virtualizao quando operam sobre cluster com balanceamento de carga.
Gerenciador de mquinas virtuais Para realizar a avaliao dessas duas tcnicas, foi composto um sistema formado por um cluster de mquinas, mquinas
virtuais executando sobre as mquinas, aplicaes executando sobre as MVs
e um gerenciador de MVs, responsvel por manter a carga balanceada entre
as mquinas do sistema. Esse gerenciador est habilitado para operar com as
duas tcnicas de virtualizao.
Implementao de um algoritmo de balanceamento de carga Foi
adaptado e implementado o algoritmo eficiente [7] de balanceamento de carga
2
Assign-U estendido [7]. Este algoritmo foi desenvolvido para operar balanceamento de carga de processo. Nesta dissertao, est implementado para
balancear MVs.
1.2
Organizao da Dissertao
Esta dissertao se divide em seis captulos. O Captulo 2 apresenta a fundamentao utilizada neste trabalho. Neste captulo, so discutidos os conceitos, classes e
tcnicas de virtualizao. O Captulo 3 descreve detalhes especficos das tcnicas de
virtualizao usadas nos experimentos. O Captulo 3, tambm apresenta os softwares e os algoritmos implementados para gerenciar a migrao de mquinas virtuais.
O Captulo 4, mostra os detalhes referentes ao ambiente experimental e a anlise
dos resultados obtidos nos experimentos.
Finalmente, o Captulo 6 apresenta concluses a respeito dos rumos e resultados
desta dissertao, assim como sugestes de trabalhos futuros.
Captulo 2
Virtualizao
Neste captulo, so apresentados alguns fundamentos deste trabalho. Estes fundamentos so importantes para o bom entendimento dos objetivos propostos e da
anlise experimental. O principal tema abordado neste captulo a virtualizao,
contemplando os conceitos, classes de virtualizao e identificando o potencial desta
tecnologia.
2.1
Introduo
Apesar do crescimento acelerado do uso de virtualizao nos ltimos anos, um

equvoco pensar que o conceito de virtualizao surgiu no incio deste perodo. Na
verdade, os primeiros artigos que tratam deste tema na computao, surgiram h
mais de 30 anos. Entre o fim da dcada de 60 e o incio de 70, em um contexto
tecnolgico diferente do que vivemos atualmente, surgiram as primeiras definies
[52] e implementaes [54] [51] do uso de virtualizao na computao. Foi naquela
poca que surgiram os primeiros mainframes, que por serem computadores grandes e
caros, geralmente tinham que ser compartilhados por um grande nmero de usurios.
Neste cenrio, surgia um forte incentivo ao uso de virtualizao, j que diferentes
usurios, desejavam utilizar SOs diferentes. Com o desenvolvimento da tecnologia, o
hardware passou a ser mais barato e os mainframes foram substitudos por desktops.
Desta forma, diminuiu o interesse pelo uso de virtualizao.
Recentemente, o uso de MVs voltou a se tornar popular. Os grandes e caros
mainframes de ontem, so hoje os tambm grandes e caros clusters computacionais
que ainda so compartilhados por muitos usurios e tambm esto habilitados a usar
virtualizao. Um outro motivo para o retorno da virtualizao est no grande
poder computacional dos desktop atuais e na otimizao das novas tecnologias de
virtualizao, que em conjunto, tornam suportvel o overhead resultante do uso da
virtualizao, mesmo em computadores pessoais.
Os benefcios que o uso de virtualizao pode trazer so muitos, entre eles podemos citar:
Portabilidade: Permite executar um programa binrio compilado para uma
arquitetura diferente da mquina fsica que ser utilizada na execuo.
Mltiplos Ambientes Seguros: Vrias mquinas virtuais podem executar,
simultaneamente, em uma mesma mquina fsica. Cada MV tem a iluso de
que a mquina fsica exclusivamente sua. Qualquer problema que ocorra
dentro de uma MV, seja por executar um programa malicioso ou at mesmo
por existir algum bug no sistema operacional da MV, improvvel que as
outras MVs hospedadas na mesma mquina sejam afetadas. Essa caracterstica
permite que mquinas hospedem diferentes servios em diferentes MVs sem
que uma eventual falha de segurana de um servio venha comprometer a
segurana do outro.
Mltiplos Sistemas Operacionais: Em uma nica mquinas pode-se ter
diferentes MVs com sistemas operacionais diferentes. Permite que o usurio
utilize, simultaneamente, na mesma mquina, diferentes programas que executam em SOs distintos. Tambm uma boa soluo para o problema de
usurio da mesma mquina que necessitam de usar SOs diferentes.
Monitorar eventos: Algumas implementaes de mquinas virtuais possibilitam ao desenvolvedor monitorar com mais facilidade alguns eventos do sistema. A virtualizao pode facilitar a obteno do trace e permite at mesmo
ter uma imagem ou um dump da mquina virtual, e a partir desta imagem, vrias instncias da MV original podem ser criadas, facilitando ao desenvolvedor
encontrar erros no sistema.
Migrao das Mquinas Virtuais: A virtualizao permite a migrao de
MVs entre diferentes mquinas de forma transparente para a aplicao, ou seja,
as aplicaes continuam a execuo naturalmente como se ainda estivessem na
mesma mquina. Migrar uma MV entre mquinas pode ser muito til quando
se identifica que uma mquina est sobrecarregada ou at mesmo quando algum recurso de hardware da mquina est prestes a falhar. A capacidade de
migrao pode ser considerada uma das mais importantes vantagens do uso de
virtualizao. Esta caracterstica muito relevante neste trabalho e ser mais
explorada neste e nos captulos seguintes.
2.1.1
Fundamentos
Os computadores modernos esto certamente entre as mquinas mais poderosas

e complexas produzidas pelo homem. Esses computadores contm diversos chips,
onde cada chip, por sua vez, contm centenas de milhares de transistores. Estes
pequenos chips ficam interligados fisicamente entre si e com outros dispositivos. Se
adicionarmos a esta estrutura o SO, aplicaes, drivers e bibliotecas; temos uma
poderosa mquina cujos limites ainda so desconhecidos.
Juntar esses diversos componentes de hardware e software para formar um complexo sistema computacional, se torna mais fcil quando este sistema dividido em
camadas de abstrao separadas por uma interface bem definida. As camadas de
abstrao formam uma hierarquia onde as camadas de hardware so classificadas
como de baixo nvel e as de software, camadas de alto nvel. Uma vantagem notvel
do uso de camadas de abstrao com interfaces bem definidas, poder desenvolver
uma camada independentemente do desenvolvimento da outra. Comunidades de
desenvolvedores ou empresas podem assim, concentrar seus esforos no desenvolvimento de apenas um, ou alguns dos nveis da camada. Determinada equipe de
trabalho no precisa conhecer os detalhes das camadas adjacentes, pois a interface
entre as camadas j estava definida, e fica como responsabilidade de outra equipe
implementar o que foi definido pela interface de um componente da camada adjacente. Um exemplo claro de empresas que trabalham neste contexto so a AMD[31]
e a Microsoft[28]. Enquanto a AMD desenvolve microprocessadores com conjunto de
instrues Intel IA-32, a Microsoft desenvolve compiladores que mapeiam linguagens
de alto nvel de abstrao para este mesmo conjunto de instrues.
Essa diviso de camadas com interfaces bem definidas no traz somente vantagens. Ter interfaces bem definidas entre as camadas limitam sua portabilidade,
pois, os componentes desenvolvidos para uma interface no conseguem operar com
outros que implementam uma interface distinta. Existem processadores com diferentes conjuntos de instrues, assim como existem tambm SOs com arquiteturas
muito distintas. Aplicaes que j esto em cdigo binrio, teoricamente s podem
executar, de forma direta, sobre um determinado conjunto de instrues e SO especficos. Resolver este problema talvez seja uma das caractersticas mais notvel da
virtualizao. Voltar a ateno para este fato pode ajudar na compreenso do que
vem a ser a virtualizao.
Definio
A Virtualizao foi a maneira encontrada para dar maior portabilidade aos componentes das camadas e subsistemas. Virtualizar um sistema (ou subsistema)
mapear as interfaces e demais recursos, visveis para outros sistemas que operam so6
bre a camada de virtualizao, para as interfaces e recursos existentes sob a camada

de virtualizao. A camada de virtualizao pode informar para esse sistema, que
o hardware que est sob ela, possui mais, menos, e at recursos diferentes do que
este realmente possui. A Figura 2.1, representa a arquitetura de um sistema sem
virtualizao, j a Figura 2.2, apresenta a arquitetura tradicional de um sistema
virtualizado. Na Figura 2.2, temos a camada de virtualizao inserida entre o SO e
a camada de hardware, os traos que separam a camada de SO e de virtualizao so
diferentes dos que separam a camada de virtualizao da camada hardware. Esse
traos so diferentes, para representar a diferena entre as interfaces, o que significa
que o SO no diretamente dependente do hardware.
Figura 2.1: Arquitetura de um sistema

no virtualizado.
Figura 2.2: Arquitetura de um sistema

virtualizado.
Formalmente, pode-se ver o processo de virtualizao como um isomorfismo[52].

Como ilustrado pela Figura 2.3, apresentada na publicao [52]. Para uma sequncia
de operaes no sistema virtual, que leva este sistema de Si para Sj, existe uma
sequncia de operaes e que modifica de forma equivalente o sistema real de Sj
para Sj. De maneira mais restrita, pode-se pensar que as operaes no sistema
virtual so requisitadas pela camada de SO camada de virtualizao, e as operaes
no sistema real so as operaes requisitadas pela camada de virtualizao camada
de hardware.
Figura 2.3: Mapeamento do sistema virtual em um sistema real.
2.1.2
Classes de Virtualizao
Antes de apresentar as diferentes tcnicas de virtualizao, instrutivo, falar sobre

o significado de mquina no ponto de vista de um processo de usurio e do sistema
operacional.
Na perspectiva de um processo executando um programa de usurio, uma mquina consiste em um espao de endereamento lgico onde ficam armazenados seus
registradores e instrues, permitindo a execuo do cdigo e armazenamento de
seu estado. Toda a parte de I/O de processo s pode ser realizada por intermdio
do sistema operacional. Desta maneira, pode-se dizer que, para um processo, a
mquina uma combinao de hardware com o SO.
Na perspectiva do SO, a mquina subjacente suporta a execuo de todo o
sistema, onde o sistema todo o ambiente de execuo que suporta os processos
de diferentes usurios. O SO o responsvel por compartilhar, entre os processos
usurios, todos os recursos de hardware disponveis. Enquanto os processos iniciam,
executam e terminam, o SO deve permanecer executando normalmente e em caso
de reboot ele deve manter seu estado. Pode-se dizer que para o SO, uma mquina
todo o hardware subjacente, com o qual ele se comunica atravs do ISA1 [46].
Como caracterizado pelo isomorfismo apresentado anteriormente, o processo de
virtualizao se divide em duas partes. A primeira consiste no mapeamento dos
recursos virtuais como registradores, memria e arquivos em recursos reais da mquina fsica. A segunda parte o uso das instrues da mquina real para realizar
1
Instruction Set Architecture Representa os limites entre o software e o hardhare.
as aes solicitadas pela mquina virtual.

Tradicionalmente, as mquinas virtuais so divididas em duas principais classes,
so elas: mquinas virtuais de processo e as mquinas virtuais de sistema. Essas
classes refletem as duas diferentes conotaes de mquina descritas anteriormente,
isto , enquanto a primeira reflete a virtualizao da mquina na forma como
vista pelo processo, a segunda representa a virtualizao da mquina na viso do
SO. Apesar de no ser consenso entre os autores da rea [49], a classe de mquina
virtual no Nvel do SO ou de Container considerada como uma classe intermediria
entre classe de MV de processo e a classe de MV de sistema.
Mquinas Virtuais de Processo
As mquinas virtuais de processo so criadas para suportar apenas uma aplicao.
A mquina criada quando a aplicao inicia, e descartada quando o processo
termina. O software de virtualizao desta classe comumente chamado de runtime
e se localiza acima de uma combinao hardware e software vista pelo processo. As
Figuras 2.4 e 2.5 refletem respectivamente, a arquitetura desta classe e a viso que o
processo tem da mquina sobre a qual ele executa. Note que o processo da aplicao
s interage com o software de virtualizao, isso implica que sua execuo independe
do tipo de hardware e SO sobre o qual ele executa, pois toda a interao com o
hardware e com SO de responsabilidade da camada de virtualizao. Existem
vrias implementaes de MVs de processo, a mais comum, que tambm pode ser
considerado como virtualizao de processos, a multiprogramao, empregada em
quase todos os SOs atuais e fornece a um processo a iluso de ter toda a mquina
exclusivamente para ele. Um outro tipo, que se tornou popular com o uso da Java
Virtual Machine [53], prov a independncia da plataforma utilizada. Esse tipo de
MV, no nvel de processo, permite a portabilidade da execuo do processo, e seu
ambiente virtual no necessariamente correspondem ao de alguma plataforma real
existente.
Figura 2.4: Arquitetura das camadas na

virtualizao de processo.
2.1.3
Figura 2.5: Viso da processo, na virtualizao de processo.
Mquina Virtual de Sistema
As mquinas virtuais de sistema provm o ambiente completo do sistema no qual

possivelmente coexistem muitos processos de diferentes usurios. Nesta classe, o
SO hospedado deve ter acesso aos recursos do hardware subjacente, incluindo os
de rede e a interface grfica. As Figuras 2.6 e 2.7 representam, respectivamente, a
arquitetura e a viso do SO sobre a virtualizao de sistemas. Na Figura 2.7 nota-se
que a execuo do SO se d de maneira independente em relao ao hardware. O SO
depende da camada de virtualizao, deixando toda interao com o hardware por
conta da mesma. O software representado na camada de virtualizao, responsvel
pela virtualizao do sistema denominado Monitor de Mquina Virtual(MMV).
Tambm existem diferentes implementaes de mquinas virtuais de sistemas, e por
serem parte importante deste trabalho, sero melhor exploradas nas sees seguintes.
10
Figura 2.6: Arquitetura das camadas na

virtualizao de sistema.
Figura 2.7: Viso da mquina virtual

na virtualizao de sistema.
Como o foco do trabalho est em comparar alguns tcnicas de virtualizao

de sistemas, no ser descrita a virtualizao de processos. Porm importante
conhecer mais detalhes das tcnicas de virtualizao de sistemas, pois a anlise dos
resultados apresentados neste trabalho dependem do conhecimento de algumas das
tcnicas de virtualizao de sistemas. Na prxima seo sero detalhadas algumas
dessas tcnicas.
2.2
Tcnicas de virtualizao de Sistemas
Existem diferentes tcnicas de virtualizao de sistemas. Antes de escolher uma

tcnica, ou uma tecnologia de virtualizao, deve-se saber se a escolhida mais
adequada para atender as necessidades pr-definidas. Geralmente, as caractersticas
mais preponderantes na escolha do tipo de virtualizao esto diretamente relacionadas ao isolamento e a eficincia proporcionada pelo tipo [52]. O isolamento indica
o nvel de independncia entre as MVs, ou seja, o quanto um erro ou o consumo
de recursos em uma MV pode influenciar a execuo de outra MV. J a eficincia
est ligada ao nvel de overhead gerado pela uso da tcnica de virtualizao, ou seja,
quanto mais eficiente menor o overhead. Nas prximas subsees so apresentadas
conceitos bsicos das tcnicas consideradas importantes para esta dissertao.
2.2.1
A Virtualizao Clssica
A principal caracterstica deste tipo de virtualizao a presena do software de

virtualizao, conhecido como monitor de mquina virtual (MMV), ou em ingls
11
virtual machine monitor (VMM), que fica localizado entre o hardware e as MV hospedadas. Para esta tcnica, o MMV quem deve gerenciar o compartilhamento
dos recursos de hardware disponveis para as mquinas virtuais. O MMV detm os
recursos fsicos do hardware e pode torn-los disponveis para as MVs hospedadas.
Cada MV possui a iluso de que tem os recursos de forma exclusiva. Os recursos virtuais vistos pelas MVs podem ou no ter um recurso fsico correspondente. Quando
o recurso no existir fisicamente, o MMV deve emular as funes deste recurso virtual. Geralmente isso feito por uma combinao entre software e outro recurso real
disponvel no sistema. responsabilidade do MMV agendar e gerenciar a alocao
de recursos como registrador de cpu, memria real do sistema e os dispositivos de IO
disponveis no sistema. Por essas caractersticas, pode-se dizer que a relao entre
um SO e as aplicaes que nele executam, so semelhantes a relao existente entre
o MMV e as mquinas virtuais hospedadas.
Como apresentado nas Figuras 2.8, 2.9 e 2.10, a disposio do MMV pode variar
em relao aos outros componentes do sistema. Na Figura 2.8 o MMV o nico
componente que executa no nvel de privilgio mais alto, MVs executam em modo
menos privilegiado. O MMV deve emular o nvel de execuo dos SOs hospedados
para que estes sejam executados como usualmente. O problema desta configurao
est na necessidade de remover o SO existente na mquina antes de instalar o MMV.
Na Figura 2.9, existe um SO hospedeiro abaixo do MMV, executando em um nvel
de privilgio maior que este. Neste caso, apesar de no ser preciso retirar o SO
para instalar o MMV, esta configurao perde em termos de eficincia, pois insere
uma camada de software a mais entre as aplicaes e o hardware. Uma forma de
aproveitar um pouco da vantagem das duas disposies anteriores, seria permitir
que o MMV executasse tanto em modo privilegiado quanto em modo usurio, como
apresentado na Figura 2.10, onde o MMV pode aproveitar os benefcios de executar
nos dois nveis de privilgio.
Abaixo, apresentado como realizada a gerncia dos recursos por essas tcnicas
de virtualizao:
Virtualizao dos Processadores
Virtualizar um processador implica em executar as instrues de todas as MVs
hospedadas no sistema. Essa execuo pode proceder de duas maneiras. A primeira,
por meio de emulao. Nesta, o MMV deve examinar a instruo e emular essa
instruo executando uma, ou um conjunto de instrues para produzir um resultado
equivalente ao da instruo emulada. Emulao a nica maneira de virtualizar
quando a ISA do processador hospedado diferente da ISA suportada pela MV
hospedada. A segunda forma a execuo direta da instruo no processador.
Executar a instruo diretamente , geralmente, mais rpido do que emular sua
12
Figura 2.8: Disposio do Monitor de

Mquina Virtual nas camadas do sistema virtualizado. O MMV com o maior
privilgio do sistema.

Mquina Virtual nas camadas do sistema virtualizado. O MMV no nvel de
privilgio de aplicao do SO.

Mquina Virtual nas camadas do sistema virtualizado. O MMV ora no nvel
de privilgio da aplicao, ora no maior
nvel de privilgio do sistema.
13
execuo. O problema da segunda forma de execuo que esta s pode ser utilizada
quando o processador possui a mesma ISA suportada pela MV hospedada.
Mesmo quando o MMV, executando seguindo o modelo de camadas apresentado
na Figura 2.8, e a ISA do processador for igual a ISA suportada pelas MVs, as MVs
devem executar sempre em modo menos privilegiado que o MMV, o que importante para que o MMV mantenha o controle do sistema [52] Mas existem instrues
destas MVs que necessitam executar em modo privilegiado para que procedam corretamente. O MMV deve ento emular estas instrues para que as MVs executem
como se detivesse o modo privilegiado do sistema. Essa emulao gera overhead.
Existem tambm instrues no privilegiadas que no podem executar diretamente
sem a interveno do MMV. Essas instrues so crticas para o MMV, pois diferentemente das instrues privilegiadas elas no geram interrupo, dificultando a
tarefa do MMV. A arquitetura Intel IA-32 por exemplo, contm muitas instrues
desta categoria. Por este motivo o IA-32 considerada uma arquitetura que no
eficientemente virtualizvel [46]. Quanto mais execuo direta, menos emulao
de instruo, mais eficiente a virtualizao se torna. Desta forma, a eficincia da
virtualizao est diretamente relacionada com a forma que a MMV lida com essas
instrues privilegiadas [45]. A maneira como o MMV identifica e lida com estas
instrues outro fator influente na eficincia desta virtualizao.
A tecnologia de virtualizao Xen[29] modifica o SO hospedado a fim de contornar as dificuldades inerentes a virtualizao de processadores com arquitetura IA-32.
Este tipo de virtualizao que modifica o SO hospedado chamada de Paravirtualizao. Devido a essas modificaes, a interface da mquina virtual provida pelo
Xen ligeiramente diferente da arquitetura real do processador. Apesar de invasiva,
essa modificao justificada pelo ganho de desempenho gerado pela diminuio no
overhead da virtualizao do processador. J o VMWare[30], outra tecnologia de
virtualizao da classe de virtualizao de sistemas, aplica a tcnica de Virtualizao Total. Esta tcnica utiliza o MMV, mas no faz nenhuma modificao no SO
hospedeiro. O MMV do VMware obrigado a examinar sequencialmente os blocos
de instrues, antes da execuo, em busca de instrues crticas. Caso encontre
uma instruo crtica, esta ser substituda por uma instruo de interrupo para
o MMV. Quando esta interrupo for executada, o MMV assume o controle e emula
a execuo da instruo crtica. No modificar o SO traz a vantagem de no precisar
alterar as camadas de software adjacentes. Mas o grande problema de no faze-la
o overhead necessrio para virtualizar a arquitetura IA-32. Esse overead pode ser
inaceitvel em algumas situaes.
14
Virtualizao da Memria
Pode-se considerar que a virtualizao de sistema uma generalizao dos conceitos
utilizados na memria virtual, atualmente implementado nos SOs [43] . Assim como
uma MV hospedada v os recursos do sistema de maneira diferente do que realmente
, a memria que o SO aloca a um processo tambm diferente da memria fsica
que suportada. A memria virtual dos OSs comuns, sem virtualizao, necessita de
uma tabela de pginas para fazer o mapeamento da endereo virtual de um processo
para a correspondente memria fsica deste. Para utilizar a memria na virtualizao
do sistema, geralmente, necessrio incluir mais uma camada entre a memria fsica
e a memria virtual vista pelo processo. Isso feito adicionando mais uma tabela,
para cada MV hospedada, que mapeia o endereo real em endereo fsico. Observe
que neste caso, o endereo real no corresponde diretamente ao endereo fsico. O
MMV passa MV hospedada a iluso de que o endereo real corresponde ao endereo
fsico, mas na verdade, ainda preciso utilizar uma tabela para traduzir o endereo
real para o endereo fsico.
Se a virtualizao fosse utilizada simplesmente como apresentado at aqui, seria
necessrio fazer duas tradues de endereo para, a partir do endereo virtual, chegar ao endereo fsico. A fim de diminuir este overhead, o MMV mantm, alm das
pginas de traduo virtual-real e real-fsico, criada uma pgina sombra que faz a
traduo direta de endereo virtual para endereo fsico. Para utilizar essa traduo
direta, tambm preciso que o MMV virtualize o registrador que contm o ponteiro
para a tabela de pgina dos processos da MV, fazendo que ele aponte para a tabela
de pgina sombra. Apesar de diminuir o overhead, a utilizao da tabela de pginas
sombra no soluciona todos os problemas relacionados com eficincia da virtualizao da memria pelo MMV. Quando ocorre uma operao de E/S(Entrada e Sada)
com os endereos reais (como comum nos SOs), o MMV precisa utilizar a tabela
que contm a traduo real-fsico para converter os endereos. O que pode degradar
o sistema neste caso, o fato das pginas reais contguas utilizadas no E/S no
necessariamente corresponderem a pginas fsicas contnuas, o que pode prejudicar
o mecanismo de cache do sistema [44].
Para tecnologias que utilizam virtualizao total, como o caso do VMware, se
faz necessrio o uso de pginas sombra como descrito acima [1]. Para o Xen, uma
tecnologia que usa paravirtualizao, cada SO mantm sua tabela para a traduo
direta de endereo virtual para endereo real. Para garantir o isolamento, as MVs
tm apenas direito de leitura nas tabelas de pgina. Quando um SO de uma VM
hospedada deseja alterar essa tabela, ocorre ento uma interrupo para o MMV,
para que este verifique se a operao do SO permitida, executando-a em caso
positivo [40]. Tanto o Xen quanto o VMware deixam as decises de alocao e
15
transferncia entre o disco e a memria, swap a cargo dos SOs hospedados, isso
impede que deciso conflitantes entre o SO e o MMV degradem a eficincia do
sistema.
Virtualizao de E/S
A virtualizao dos dispositivos de entrada e sada constitui uma das partes mais
complexas da implementao de um sistema de mquinas virtuais. Alm de existir
uma grande e crescente quantidade de tipos de dispositivos de IO, cada um destes
tipos possuem caractersticas peculiares, o que implica na necessidade de drives
especficos para cada tipo de dispositivo. Este fato dificulta a implementao da
virtualizao destes dispositivos. Abaixo, seguem as trs estratgias mais utilizadas
na implementao da virtualizao de dispositivos:
E/S Direta Na primeira estratgia, a de E/S direta, o dispositivo alvo acessado
diretamente pelo driver do dispositivo instalado na mquina virtual. Neste
caso no existe interveno direta do MMV na comunicao entre a aplicao
da MV e o dispositivo. Se por um lado esse fato pode tornar a virtualizao do
dispositivo eficiente, por retirar um intermedirio na comunicao entre a aplicao e o dispositivo, por outro lado, a ausncia do MMV nesta comunicao
dificulta o compartilhamento do dispositivo em questo.
E/S Virtual, com transao emulada Na transao emulada, somente uma
MV especial ter acesso direto ao dispositivo. Todos as outras MVs do sistema
que desejarem utilizar o dispositivo, devem interagir com a MV especial para
que esta interaja com o dispositivo. Esta interao ocorre da seguinte forma:
primeiramente um controlador virtual de uma MV recebe, de uma aplicao
desta MV, um pedido de E/S para algum dispositivo, ento o controlador
virtual repassa o pedido, atravs do MMV, para um controlador nativo da
mquina especial. Aps receber o pedido, o controlador nativo da MV especial interage diretamente com o dispositivo a fim de atend-lo. Devido a
necessidade da incluso dos controladores especiais nos SOs das MVs, a estratgia de transao emulada utilizada em sistemas paravirtualizados. O Xen
utiliza esta estratgia para virtualizar os dispositivos do sistema e para agilizar
a transferncia dos dados do E/S para os domnios utilizam um esquema de
anel de E/S,conforme descrito em [40].
E/S usando emulao de dispositivo Na ltima estratgia, o MMV possui a
tarefa de emular o dispositivo para que a MV, juntamente com o seu software
de controle do dispositivo, tenham a iluso de estar interagindo diretamente
com o dispositivo emulado. O MMV intercepta as iteraes da MV com o
16
dispositivo, emula e retorna o que foi pedido pela MV ao dispositivo emulado.

Esta estratgia menos invasiva e mais limitada do que a anterior. Menos
invasiva pois no se faz necessrio modificaes no SO e controlador de dispositivo. Mais limitada porque a capacidade de emulao do MMV est limitado
aos recursos que este possui. Alm disso, essa estratgia no eficiente, pois
a emulao do dispositivo por parte do MMV adiciona ainda mais overhead
a virtualizao. Por suas caractersticas, esta tcnica utilizada na Virtualizao Total. A fim de evitar as limitaes e o overhead acima abordados,
uma das verses do VMware, VMWare Workstation, aproveita o fato do MMV
como um processo usurio no SO hospedeiro, como na Figura 2.9 para efetuar
a virtualizao de seus dispositivos [39]. A virtualizao ocorre da seguinte
maneira, sempre que alguma aplicao do SO de alguma MV fizer uma requisio de IO, a parte do MMV acoplada ao hardware converte esta requisio
para uma aplicao do SO hospedeiro. Assim, a requisio pode ser atendida
por um software controlador instalado no SO hospedeiro. Uma vantagem desta
abordagem que no necessrio colocar softwares controladores no MMV.
Por outro lado, muitos pedidos de IO podem sobrecarregar o SO hospedeiro.
2.2.2
Virtualizao no Nvel do Sistema Operacional
Esta classe de virtualizao, tambm conhecida como virtualizao por Containers,

e se apresenta como uma alternativa virtualizao clssica. Existem cenrios
que requerem sistemas de virtualizao mais eficientes e no requerem diferentes
sistemas operacionais. Para estes casos, a virtualizao por containers pode ser mais
adequada. Nesta tcnica, o kernel do sistema operacional principal compartilhado
entre todas as mquinas virtuais do sistema. O fato de compartilhar o kernel, evita
que mais uma camada de software seja adicionada ao sistema, o que torna mais
eficiente as tcnica desta classe. Este mesmo fato torna as mquinas virtuais menos
isoladas em relao a tcnicas da virtualizao clssicas, j que um problema no
kernel pode afetar todas as mquinas. A Figura 2.11 representa bem o que esta
tcnica. Os processos das MVs so segregados em conteiners distintos. Assim, no
ponto de vista do kernel, as MVs so um conjunto de processos. J para a MV,
ela tem a impresso de que est executando de forma exclusiva no kernel, ela no
consegue "ver"os processos que esto em outros containers. Tambm mostrado a
separao entre plataforma virtual e a plataforma hospedeira. A plataforma virtual
representa a viso do sistema pelas MVs. A plataforma hospedeira, representa a
viso do kernel compartilhado.
17
Figura 2.11: Virtualizao no nvel do SO.
Existem diversas tecnologias pertencente a esta classe de virtualizao, entre eles

o OpenVZ [33], Virtuozzo [37], Linux-VServer [36], Solaris Zones [35] and
FreeBSD Jails [34]. A diferena bsica entre eles est no SO hospedeiro e nas tcnicas
empregadas no Kernel do SO para isolar as MVs.
ssaryname=OpenVZ, description=OpenVZ uma tecnologia de virtualizao em
nvel de sistema operacional baseada no sistema operacional e ncleo Linux. O
OpenVZ uma base do Parallels Virtuozzo Containers, um software proprietrio
fornecido pela Parallels. O OpenVZ licenciado sob a verso 2 da GPL.
As tcnicas bsicas de segurana nos sistemas de virtualizao por Containers
so:
Espao de endereamento separados para cada MV, ou seja, contexto diferente
para containers diferentes.
Controle de acesso por meio de filtros; aqui os filtros tm um papel semelhante
ao que os MMV tem na classe MV de sistemas. Os filtros controlam o acesso
aos objetos do kernel, verificando em tempo real se a execuo do container
est de acordo com suas permisses de acesso.
Virtualizao do Processador
Diferente da virtualizao clssica, esta tcnica, no emprega nenhuma emulao do
processador. As aplicaes das MVs executam da mesma maneira que executariam
em SO sem virtualizao. Elas veem o processador da mesma maneira que viriam
se executadas em um SO comum. A diferena para os SOs sem virtualizao que
18
aqui os PID dos processos so virtualizados; cada Container conhece apenas os seus
processos. Outra diferena que tambm necessrio escalonar o processador entre
as mquinas virtuais.
Virtualizao da Memria
No difere muito da forma empregada no SOs comuns. O fato de possuir os filtros e
colocar cada MV em espaos de endereamento distintos, permite que esta tcnica
use a memria virtual como nos SOs comuns.
Virtualizao de IO
Parte dos problemas enfrentados na Virtualizao Total e na Paravirtualizao com
os drives dos dispositivos, no existem na virtualizao por container. Como na Virtualizao por Containers se tem apenas um kernel para todas as MVs, o problema
dos drivers para tcnica, se resume a forma como este recurso ser compartilhado
entre as MVs. Para um dos mais importantes recursos de IO, a interface de rede,
a forma de virtualizao empregada pelos produtos desta classe buscam em comum
as seguintes caractersticas:
1. Cada container possui seu prprio IP;
2. O trfego dos container so isolados;
3. Cada container deve ter suas prprias regras de firewall;
Cada produto aplica tcnicas diferentes com finalidades parecidas. No Solaris
criado um Switch virtual e tambm as VNICs (virtual network interface card),
interfaces de virtuais de rede para cada container. As VNICs permitem que cada
container possua seu endereo de IP, enquanto o switch direciona os dados da interface fsica para a interface virtual de cada container, permitindo o isolamento.
2.3
Migrao de Mquinas Virtuais
Um benefcio direto da virtualizao de sistemas, poder realizar balanceamento

de carga e preveno de falhas migrando as MVs. A migrao de MVs soluciona
muitos dos problemas que se tem na migrao de processos, como os apresentados
nos trabalhos [41],[47] e [48]. A migrao de MVs se beneficia da capacidade que
possuem os sisteama virtualizados de migrar instncias de SOs entre mquinas fsicas
distintas. Existem diversas maneiras de fazer essa migrao, e em algumas dessas
maneiras, a migrao pode ocorrer de forma transparente, tanto para as aplicaes
executadas na MV migrada, quanto para o usurio das aplicaes. Assim, uma
19
MV pode migrar de uma mquina fsica para outra, sem que o usurio saiba que a
MV mudou de mquina fsica. Possivelmente, essa uma das caractersticas mais
notveis da virtualizao e parte do sucesso atual da virtualizao em clusters e data
centers deve-se a essa potencialidade. A migrao de MVs tem sido utilizada em
clusters e data centers, principalmente por permitir economia de energia, otimizao
do recursos e preveno contra falhas [26]. Para economizar energia, sempre que os
recursos de um cluster ou de um data center estiverem subutilizados, pode-se migrar
todas as MVs para um conjunto de mquinas fsicas e desligar as outras mquinas
fsicas que no fazem parte deste conjunto. Para otimizar os recursos, pode-se fazer o
balanceamento da carga das mquinas fsicas. Neste caso, deve-se migrar as MVs das
mquina sobrecarregadas para as mquina subutilizadas. Uma forma de se prevenir
contra falha de hardware seria migrar as MVs de uma determinada mquina, assim
que esta apresentasse algum indcio de falha.
Por questes de eficincia, todas as formas de migrao devem buscar diminuir
tanto o downtime 2 quanto o tempo total de migrao3 . Dependendo das aplicaes,
o impacto de um, pode ser mais importante que o outro. Por exemplo, se o que
motivou a migrao de uma MV foi uma falha na mquina fsica, necessrio que
o tempo total de migrao seja pequeno. Mas no caso da migrao de alguma
MV que execute aplicaes interativas, um pequeno downtime passa a ser de maior
importncia. Abaixo, so apresentadas as principais formas de migrao utilizadas
pelas tcnicas de virtualizao de sistemas.
Pra e copia Esta a forma mais simples de migrao e favorece o baixo tempo
de migrao total da MV, j que este tempo ir depender basicamente do tamanho da memria total da MV. Por outro lado, esta a forma que apresenta
o pior downtime, pois a MV migrada no executar durante todo o perodo
de migrao. Para migrar uma MV utilizando este mtodo, deve-se primeiramente parar a MV. A partir deste momento a MV e todas suas aplicaes
no esto mais executando. O prximo passo ento, transferir toda instncia
do SO de uma mquina fsica para outra. Aps a transferncia, a MV pode
comear a executar na mquina de destino.
Cpia sobre demanda Nesta forma o downtime sempre muito baixo. J o
tempo total de migrao alto. Aqui, o primeiro passo uma pequena parada
na aplicao para a transferncia das estruturas essenciais do kernel. Aps
a transferncia, a MV comea a executar na mquina de destino. As partes
restantes, que ainda ficaram na MV de origem, so enviadas para o destino no
2
Downtime o tempo em que a MV fica totalmente parada devido a algum passo da migrao,
neste instante nenhuma das aplicaes desta MV estar executando.
3
O tempo total de migrao o tempo que decorrente desde o incio da migrao at o seu final.
20
momento do primeiro uso no destino. Note que enviar uma pgina somente no
momento do seu uso degrada a aplicao, pois necessrio esperar a pgina
migrar da origem at o destino. Outro fato importante o tempo total de migrao que pode ser excessivamente longo, pois a migrao s ser concluda
quando toda, ou quase toda, a memria da MV for utilizada na mquina de
destino.
Pr-cpia A Pr-cpia pode ser vista como um balano entre as outras duas formas
de migrao. Pelas suas vantagens, a pr-cpia utilizada pelas tecnologias de
virtualizao como a principal forma de migrao de suas MVs. A pr-cpia
utiliza fases iterativas onde a MV continua executando na origem, e somente
no ltimo passo iterativo que a MV para de executar na origem e passa a
executar no destino. Na primeira iterao, a mquina continua executando e
toda a memria copiada para a mquina de destino. Na iterao N s so
copiadas as partes de memria modificadas aps a iterao N-1. No ltimo
passo, aps ser interrompida a execuo da MV, as pginas modificadas na
iterao anterior so copiadas para a mquina de destino, aps a cpia a MV
inicia a execuo na mquina de destino encerrando assim a migrao.
As diferentes tcnicas de virtualizao exigem formas diferentes para migrar suas
MVs. As caractersticas de cada tcnica de virtualizao, e principalmente, a forma
como a memria de cada MV vista pela tcnica, faz com que cada tcnica aborde
a migrao da MV de maneira diferente. O fato de diferentes tcnicas procederem
a migrao de suas MVs de forma distinta, est entre as principais motivaes para
esta dissertao.
Este captulo apresentou os fundamentos de virtualizao, enfatizando a virtualizao de sistemas. Foram descritas as duas principais classes de virtualizao
de sistemas, so elas, virtualizao clssica e virtualizao no nvel do SO. Foram
apresentadas tambm, as caractersticas das tcnicas de virtualizao pertencentes a
estas duas classes. A maneira como uma tcnica gerencia os recursos do sistema e a
forma que esta efetua migrao de suas MVs, so fundamentos bastante explorados
nos prximos captulos.
21
Captulo 3
Virtualizao e Balanceamento de
Carga
Neste captulo, so apresentados os sistemas que serviro de bases para o ambiente experimental explorado no captulo seguinte. Comeando pelas tcnicas de
virtualizao, cuja apresentao recorre aos conceitos contidos no captulo anterior,
acrescidos de caractersticas mais especficas das tcnicas de virtualizao explorados. O captulo concludo com a explicao do sistema de balanceamento de carga
implementado e utilizado nos experimentos deste trabalho.
Existem trabalhos cientficos [25],[24],[23],[22],[21],[19] que comparam o desempenho de diferentes tecnologias, representantes de cada uma das classes de virtualizao
apresentadas no captulo anterior. Os aspectos mais relevantes nessas comparaes
so, certamente, a eficincia e o isolamento das mquinas virtuais [52]. Quando se
compara o isolamento, considerada a probabilidade de bug no software que gerncia
os recursos das mquinas, e tambm o quanto uma MV executando aplicaes maliciosas ou apenas sedentas por recursos, influencia a execuo de outra MV. Para
comparar a eficincia, so medidos os tempos de execuo de algumas aplicaes
quando executadas em cada tecnologia, a quantidade de memria usada por cada
MV, a escalabilidade, entre outros. Em alguns casos a comparao das tecnologias
podem envolver tambm a eficincia da migrao.
O objetivo deste trabalho comparar a eficincia de duas tecnologias que implementam tcnicas de virtualizao distintas. Diferente do que foi realizado em outros
trabalhos, ser comparado o tempo total de execuo de aplicaes que esto executando sobre MVs, sendo que estas MVs podem migrar entre as mquinas fsicas de
um cluster. Estas migraes ocorrem com a finalidade de balancear a carga entre as
mquinas fsicas do sistema e so determinadas por um algoritmo de balanceamento.
Para realizar essas avaliaes, foi construdo um sistema formado por um cluster
de mquinas fsicas, mquinas virtuais executando sobre as mquinas fsicas, aplicaes executando sobre as MVs e um gerenciador de MV. Este ltimo, que para tentar
22
manter a carga das mquinas fsicas balanceadas, ir realizar migraes de mquinas

virtuais entre as mquinas fsicas do sistema. Esta subseo se dedica a explicar a
parte do sistema que gerncia as MVs, com destaque para o balanceamento de carga
por ele este realizado.
3.1
Tecnologias de Paravirtualizao e Containers
As duas tecnologias escolhidas para realizao dos testes so o Xen e o OpenVZ. O

Xen implementa a tcnica de Paravirtualizao, representando a classe de virtualizao de sistemas. O OpenVZ implementa a tcnica de virtualizao por Containers,
representando a classe de virtualizao no nvel de SO. O Xen e o OpenVZ foram
escolhidos por estarem entre os representantes gratuitos mais eficientes de sua classe
e tambm por serem tecnologias de cdigo aberto. Nas subsees seguintes so comparados a eficincia, o isolamento e a gerncia de recursos do OpenVZ e do Xen.
Esses aspectos so importantes na anlise dos resultados presentes na prxima seo.
3.1.1
Eficincia
O trabalho [22] mostra que operaes bsicas como criao de um processo, troca
de contexto e acesso a memria, so mais custosas no Xen, enquanto no OpenVZ os
tempos ficam prximos ao de um sistema sem virtualizao.
O trabalho [21] conclui que o OpenVZ apresenta alto desempenho no acesso ao
disco e na execuo de aplicaes cientficas. J o Xen demonstra excelente largura
de banda, mas alta latncia no uso da rede.
Alm destes fatos, tambm podemos considerar que o aproveitamento da memria mais eficiente no OpenVZ, j que, cada MV no Xen deve executar seu prprio
kernel. Por isso, e pelos resultados de [19], o nmero de MVs que podem executar,
simultaneamente maior no OpenVZ e apresenta melhor escalabilidade do que o
Xen.
3.1.2
Isolamento
Apesar de no ser consenso [19], por no compartilhar o mesmo kernel, o Xen

proporciona maior isolamento entre as MVs. No OpenVZ, todas as mquinas virtuais
esto dependentes do complexo kernel do Linux. Um erro neste kernel, pode afetar a
execuo de todas as MV. J as MVs do Xen so dependentes do monitor de mquina
virtual, cuja complexidade menor do que a do kernel do sistema operacional usado
no OpenVZ. Mas no so somente erros no Kernel ou no MMV que podem provocar
falhas de isolamento, o gerenciamento dos recursos da MF tambm podem provocar
23
falhas no isolamento. falha de isolamento uma MV usar o processador por mais

tempo, em detrimento de outras MVs com a mesma prioridade. Testes realizados
em [25] mostram que no OpenVZ, a execuo de algumas aplicaes sedentas por
recursos em uma MV causavam impacto em outras MVs, caracterizando falha no
isolamento. J no Xen, sob o mesmo cenrio de execuo, a falha de isolamento no
ocorreu.
3.1.3
Gerencia de Recursos
Gerencia de Processamento
OpenVZ O OpenVZ usa, em dois nveis, o algoritmo de escalonamento Fair-Share
para decidir como o processador ser alocado. No primeiro nvel, o escalonador
usado para decidir qual MV ter o processador. No segundo nvel, ser
decidido qual processo da MV escolhida far uso do processador.
Existem diferentes implementaes do algoritmo Fair-Share, mas a base de todas elas a atribuio de pesos para as MVs e para os processos. No OpenVZ,
o tempo de alocao do processador para as MVs proporcional ao peso atribudo a uma MV. Assim, se uma MV A receber peso 1000 e uma MV B receber
peso 500, A executar duas vezes mais do que B quando houver concorrncia
pelo recurso CPU.
Xen No Xen, existem disponveis dois tipos de escalonadores de CPU; so eles:
SEDF e o CreditScheduler [27]. O SEDF um escalonador preemptivo que
utiliza algoritmos de tempo real para garantir tempos de execuo previamente determinados. O Credit Sheduler, escalonador padro do Xen 3.0,
baseado em crditos e segue o modelo Fair-Share. No Credit Scheduler, cada
MV recebe um crdito ou um peso. O crdito atribudo a uma MV, determina quanto uma MV ter de tempo de CPU quando houver concorrncia
por esse recurso. Assim, se uma MV A recebe 50 e uma MV B recebe 100
de crdito, em um perodo de concorrncia por CPU, B ir executar 2 vezes
mais do que A. Cada vez que uma VCPU executa, parte de sua quantidade
de crditos recalculada. Se a quantidade de crditos de uma VCPU for negativa, ela ser classificada como over, quando os crditos so positivos, essa
VCPU classificada como under. Cada processador tem uma fila de VCPUs
para gerenciar, essa fila ordenada pela classificao da VCPU, VCPUS com
classificao under sempre estar a frente dos VCPUS com classificao over.
Sempre que uma VCPU chegar a fila de um processador, ela ser colocada
atrs das VCPUs que possuem classificao igual a sua.
24
Gerncia de Memria
OpenVZ A alocao de memria para as MVs do OpenVZ se d de forma flexvel.
O sistema pode compartilhar parte da memria usada pelas MVs. Existem dois
parmetros importantes para a alocao de memria de uma MV no OpenVZ.
Um deles, o privvmpages, determina o limite mximo de memria que pode ser
alocado para a MV, o outro, vmguarpages, diz qual a quantidade garantida
de memria que a MV tem a sua disposio. Desta forma, uma MV pode usar
uma quantidade de memria maior do que a memria reservada para ele, desde
que essa quantidade seja menor do que o valor estabelecido em privvmpages.
Conforme foi notado nos experimentos, essa abordagem otimiza o uso deste
recurso.
Xen Se por um lado, a alocao de memria para as MVs do Xen menos flexvel,
as MVs do Xen tm autonomia de gerenciar a memria que foi alocada a ela.
Quando o monitor de mquina virtual cria o ambiente da MV, como se a MV
estivesse recebido parte da RAM da MF. A mquina virtual tem que usar essa
memria para alocar seu SO e suas aplicaes. Em momento algum, a MV vai
poder utilizar mais memria do que foi previamente configurado, a no ser que
faa swap. Mesmo que uma MV no esteja ocupando toda memria alocada,
nenhuma outra MV poder utilizar essa memria.
Gerncia Entrada e Sada
OpenVZ A alocao deste recurso ocorre em dois nveis, de maneira semelhante a
alocao da CPU. A diferena que no segundo nvel usado o escalonador
CFQ ( Completely Fair Queuing ). Cada MV possui uma prioridade, e o
escalonador distribui a banda de IO de acordo com as prioridades das MVs.
Xen O Xen dispes de MV especial com mais privilgios que as outras mquinas
virtuais. Esta MV chamada de domnio 0 e todas as requisies de E/S so
centralizadas nela. Como a gerncia dos dispositivos de E/S feita por uma
camada de software que fica entre estes dispositivos, as MVs e o Domnio 0,
para realizar operaes de E/S deve ocorrer transferncia vertical de dados,
ou seja, transferncia de dados entre as camadas. Buscando uma transferncia
eficiente, com baixo overhead, o Xen implementa o mecanismo de anel de descritores de arquivo, cuja estrutura, mostrada na Figura 3.1. O anel consiste
em uma fila circular de descritores alocados pela MV e acessados por meio
do Xen. Os descritores no contm diretamente os dados de E/S, mas so
referncias indiretas para buffers que contm os dados de E/S, e estes, por sua
vez, so alocados de maneira separada pela SO da MV em questo. O acesso a
25
cada anel, se baseia em dois pares de ponteiros produtor/consumidor. Sempre

que uma MV faz uma requisio, ela requisio gravada no anel e o ponteiro
produtor de requisio incrementado, o Xen ento, remove uma requisio
quando incrementa o ponteiro consumidor de requisio deste anel. As respostas s requisies, so colocadas no anel de maneira semelhante, s que neste
caso, o Xen passa a ser o produtor, enquanto a MV ser a consumidora. Este
mecanismo de anel suficientemente genrico para suportar os mecanimos de
E/S dos dispositivos.
Figura 3.1: Estrutura do anel de E/S, o qual usado para transferir dados entre o
Xen e as mquinas virtuais hospedadas.
3.1.4
Migrao
Por utilizarem tcnicas bastante distintas na virtualizao, enquanto o Xen utiliza

paravirtualizao e o OpenVZ usa containers, a migrao das MVs pelo Xen tambm
ocorre de maneira bastante distinta da migrao utilizada pelo OpenVZ. No captulo
passado, que aborda os fundamentos de virtualizao, foram apresentados alguns
mtodos genricos de migrao. Abaixo, apresentado de maneira mais especfica,
como o OpenVZ e o Xen implementam a migrao online 1 de MV.
1
A migrao de uma MV chamada de online quando o downtime no percebido pela aplicao, ou seja, o downtime estando na casa dos milisegundos.
26
Migrao no Xen
A forma de migrao utilizada pelo Xen a pr-cpia. Como tambm j apresentado,
nesta forma de migrao o tempo downtime baixo mas o tempo total de migrao
alto. Neste modelo de migrao, a MV pode ser vista como rea de memria e isso
possibilita o uso da pr-cpia como forma de migrao. No artigo [18] relatado o
uso bem sucedido deste modelo para a migrao de VMs executando aplicaes de
alta interatividade, no caso, um jogo interativo.
Migrao no OpenVZ
A migrao no OpenVZ ocorre na forma pra e copia. E como j apresentado,
uma forma simples de migrao que resulta em um baixo tempo de migrao e alto
downtime.
Em pesquisa que antecede esta trabalho, foi avaliado a migrao de MVs do
OpenVZ, esta migrao acorreu quando a MV executava no servidor de um jogo interativo; os resultados deste experimentos nos levou a avaliar como ocorria a migrao e se era possvel melhor-la. Os resultados desta pesquisa podem ser conferido
no apndice A desta dissertao. A principal concluso desta pesquisa foi que o
alto tempo de downtime na migrao das MVs do OpenVZ foi inaceitvel para este
tipo de aplicao. Quanto ao esforo em melhorar a migrao no OpenVZ, diminuindo o downtime, esbarra na estrutura da tcnica de virtualizao utilizada. Na
virtualizao por containers, a MV no pode ser vista apenas como uma regio de
memria. Os processos da MV fazem parte de um kernel que no vai ser migrado,
aps a migrao da MV, os processos devem ser recriados no kernel da MF de destino. Aplicar a pre-cpia no OpenVZ invivel para a estrutura atual da tcnica
de virtualizao, pois uma modificao na mquina fsica de origem pode implicar
em algumas modificaes na estrutura do Kernel. Isso impossibilita o uso de fases
iterativas de migrao como utilizada na forma de migrao por pr-cpia. Dessa
forma, melhorar a migrao no OpenVZ pode implicar em alterar tambm sua forma
de virtualizao. Um ponto positivo na migrao do OpenVZ est na sua simplicidade, fazendo com que sua execuo necessite de pouco processamento, como foi
observado nos experimentos realizados no trabalho apresentado no apndice A.
Enquanto a migrao do Xen mais complexa, apresentando baixo downtime
e alto tempo de migrao total, a migrao do OpenVZ mais simples, com alto
downtime e baixo tempo total de migrao. Este um dos fatores que estimula os
testes feitos nesta trabalho.
Para aplicaes no interativas, como a grande maioria das aplicaes que utilizam clusters, pretende-se comparar o overhead gerado pela virtualizao. E parte
deste overhead est relacionado a migrao das MVs. Em um cenrio onde temos
27
um cluster de mquinas fsicas contendo MVs, e onde estas MVs podem migrar,
realizando balanceamento de carga entre as mquinas fsicas, o downtime, o tempo
de migrao e a complexidade da migrao, podem influenciar no tempo total de
execuo das aplicaes das MVs do sistema. Enquanto o dowtime afeta diretamente
a execuo da MV que est sendo migrada, o tempo total de migrao e a complexidade da migrao podem exigir computao extra, afetando o desempenho de outras
MVs. Este um fator importante que considerado nos testes aqui realizados.
3.2
Gerenciador de Mquinas Virtuais
Para executar os experimentos necessrio um gerenciador de mquinas virtuais.

Este gerenciador tem, por funo, manter a carga gerada pelas MVs balanceada
entre as mquinas fsicas do sistema. Para cumprir sua funo, o gerenciador deve
coletar informaes sobre a carga de cpu das mquinas fsicas e virtuais que compem o ambiente experimental, e baseado no conjunto de informaes que recebeu,
decidir se devem haver migraes de MVs para que o sistema seja balanceado. Caso
exista a necessidade de migrar MVs, o gerenciador realiza a migrao das MVs, provavelmente, tornando o sistema mais balanceado do que estava antes da migrao.
Existem balanceadores que tratam a qualidade de servio das aplicaes, como a
avaliao da qualidade do balanceamento no est no escopo desta dissertao essa
funcionalidade no ser implementada no balanceador.
Como na poca no havia nenhum balanceador gratuito, capaz de atender as
necessidades acima descritas para o Xen e para o OpenVZ, foi desenvolvido, nesta
dissertao, um gerenciador de MVs baseado no Usher [15], [17]. O Usher foi escolhido por ser de cdigo aberto, modular, e por j possuir algumas funcionalidades
que seriam bsicas para efetuar o gerenciamento das MVs nos exeperimentos. Outro fato influente, que o Usher est totalmente implementado em Python, que
uma linguagem orientada a objeto e j conhecida. Dentre as principais modificaes
feitas, pode-se citar a nova capacidade de gerenciar MVs do OpenVZ, a codificao
de um algoritmo responsvel por balancear a carga do sistema e a adequao para
que o gerenciador funcionasse de forma automtica, no necessitando de interveno
humana para realizar a migrao. O gerenciador criado herdou todas essas caractersticas, inclusive tambm est totalmente escrito em Python. A arquitetura do
balanceador mostrada na Figura 3.2.
Abaixo, so apresentados os mdulos do balanceador utilizado.
Controlador Local Em cada mquina fsica existe um controlador local. sua
funo, fornecer ao controlador central as informaes de sua mquina fsica
e tambm das MVs que no momento estejam executando sobre sua mquina
28
Figura 3.2: Arquitetura do balanceador de carga do sistema. CL representa o

Controle Local.
fsica. Os controladores locais tambm executam a migrao de suas MVs

quando ordenados pelo controlador central.
Controlador Central O controlador central o responsvel por receber as informaes dos controladores locais e inform-los sobre uma possvel necessidade
de migrao. As informaes recebidas dos controladores locais so direcionadas para o balanceador. Caso exista alguma necessidade de migrao, o
balanceador informa ao controlador central, e este por sua vez, informa ao
controlador local qual a MV que deve ser migrada e qual a mquina fsica
de destino. necessrio somente um controlador para todo o sistema.
Balanceador o modulo que contm o algoritmo de balanceamento de carga que
analisa se o sistema est desbalanceado. Sempre que aferido desbalanceamento no sistema, ele decide qual MV deve ser migrada e para qual mquina
fsica esta MV deve ir. O balanceador tem como tarefa, realizar a interpretao de todos os dados coletados, e de acordo com essa interpretao, ordenar
ou no, alguma ao com a finalidade de balancear a carga entre as MF do
sistema. Na prxima seo apresentado, com mais detalhes, o algoritmo de
balanceamento usado.
O gerenciador tem potencial para fornecer as seguintes informaes ao algoritmo
de balanceamento: quantidade de memria usada por cada MV, porcentagem de
CPU usada pelas MVs e pela mquina fsica, quantidade de dados trafegados por
cada MV na interface de rede e a localizao atual de cada uma MV. Mas devido a
restrio na anlise feita pelo algoritmo de balanceamento empregado, este s recebe
informaes sobre o uso de CPU das mquinas fsicas e virtuais e a localizao das
29
MVs. Portanto, as decises de migrao das MVs so decididas a partir da avaliao

da carga de CPU das mquinas virtuais e fsicas e da localizao das MVs.
O apndice B, apresenta detalhes de implementao e instrues de instalao e
uso do gerenciador de mquina virtual implementado nesta dissertao.
3.3
Algoritmo de Balanceamento de Carga
O balanceamento de carga uma tcnica aplicada para distribuir a carga de trabalho

entre dois ou mais servidores, enlaces de rede, CPU, ou outros recursos; a fim de
otimizar a utilizao destes recursos, maximizar o desempenho e evitar sobrecarga.
Em geral o balanceamento de carga consiste em trs fases [14]. A primeira, consiste
na coleta de informaes. A segunda, busca determinar qual seria a distribuio
tima para o estado em que o sistema se encontra. na terceira fase que a ao
de balanceamento executada. O balanceador de carga pode ter uma das seguintes
classificaes:
Esttico A regra de balanceamento definida uma nica vez, baseada em informaes estticas do sistema ou aplicaes.
Dinmico A regra de balanceamento modificada em resposta ao estado atual do
sistema ou das aplicaes. O estado do sistema ser constantemente atualizado
e as decises tomadas so baseadas nas informaes atuais e possivelmente,
dos estados anteriores do sistema.
Ao balancear a carga, tenta-se evitar que no sistema, existam simultaneamente
mquinas com recursos subutilizados e mquinas com recursos superutilizados. Na
maioria dos casos, realizar balanceamento de carga timo impraticvel, devido a
complexidade computacional para resolver o problema. Conforme [4], o problema
de balanceamento de carga similar a problemas de alta complexidade computacional, que no podem ser resolvido de maneira exata em tempo polinomial. Para
contornar esta limitao, heursticas 2 ou algoritmos de aproximao 3 , so usados
para apresentarem solues aproximadas do balanceamento de carga timo.
Antes de apresentar o algoritmo escolhido, cabe explicar sua relevncia neste
trabalho e o motivo de sua escolha de qual seria o algoritmo implementado. Como o
algoritmo de balanceamento o mesmo na realizao de todos os testes, este no deve
influenciar significativamente os resultados relativos, do Xen com os do OpenVZ. De
fato, diferentes balanceadores, ou at mesmo uma modificao nos parmetros de
2
Algoritmos que produzem respostas aproximadas para algum problema.

Algoritmos que produzem resposta aproximadas para problemas, sendo que a diferena entre
a resposta do algoritmo e a resposta tima, sempre menor que um limite definido.
3
30
um balanceador, podem modificar, por exemplo, o nmero de migraes realizadas.

E como a migrao pode ser mais eficiente para uma das tcnicas, o nmero de
migraes pode influenciar no tempo de execuo das aplicaes.
Diante destas consideraes, foram estudados os seguintes algoritmos de balanceamento de carga antes da escolha de qual seria implementado. Todos eles pertencem
a classe de balanceadores dinmicos. Os algoritmos estudados esto:
Algoritmo apresentado em [12] As decises sobre a migrao de MVs so tomadas localmente por cada mquina fsica. Todas as mquinas fsicas tm
informaes sobre todas as mquinas do sistema. A avaliao da carga de
cada mquina baseada no tamanho da fila da CPU, da utilizao da CPU,
da utilizao da memria e da rede.
Autonomous Learning [11] Neste algoritmo, a deciso de migrao baseada
em um limiar dinmico. Com o decorrer das migraes, o algoritmo vai aprendendo e variando o limiar de acordo com o que foi observado por ele no histrico
da sua execuo. A avaliao da carga de cada mquina fsica s considera a
utilizao de CPU.
Self-Training [10] um algoritmo centralizado, onde as decises de migrao
so tomadas por um controlador central e este pondera o uso de CPU, rede
e memria. Ele se baseia no resultado desta ponderao para tomar suas
decises sobre migrao das MVs. Um fator tambm determinante na escolha
da migrao o SLA 4 das MVs.
Balack-box and Gray-box [3] Wood e outros [3], desenvolveram dois algoritmos para resolver o problema de balanceamento. Um deles, o Black-Box,
estima a carga da mquina, baseado no carga de CPU, rede e quantidade de
swap realizado na mquina. J o outro algoritmo, o Gray-Box, se baseia em
mais parmetros alm da carga da CPU, para avaliar a carga da mquina.
Os parmetros adicionais so especficos de aplicaes que executam nas MVs.
Segundo os autores, o com estes parmetros adicionais, pode-se garantir qualidade de servio as aplicaes. Neste caso, o motivo das migraes no estaria
somente em balancear a carga do sistema, mas para que o SLA de uma determinada aplicao no fosse violado.
Assign-U Estendido [7] O Algoritmo escolhido, apresentado em [7], foi baseado
no Assign-U. O Assign-U foi criado para direcionar tarefas para mquinas, e
estas tarefas permaneciam nestas mesmas mquinas at o fim de sua execuo.
A extenso do Assign-U, prev a realocao das tarefas durante suas execues.
4
SLA(Service Level Agreement), em portugus, acordo de nvel de servio, um acordo que

estabelece um nvel mnimo de qualidade para determinado servio.
31
Todas as ao deste algoritmo so baseadas em uma funo no linear, que

determina quando deve haver migrao de tarefas, qual tarefa deve migrar e
para onde deve migrar.
3.3.1
O Algoritmo de Balanceamento Implementado
O algoritmo que foi implementado e apresentado no trabalho [7], visto como uma
verso mais elaborada do algoritmo Assign-U [6], pois aquele, promove remanejamento das tarefas, podendo migra-las aps o incio de sua execuo. O algoritmo
apresentado em [7] um algoritmo de aproximao eficiente [9], criado para migrar
tarefas, portanto, ser adaptado para migrar MVs. O algoritmo recebe como entrada o percentual utilizado de CPU de cada mquina fsica, o percentual que cada
MV usa de sua mquina fsica atual e qual essa mquina fsica. Como sada, ele
diz se o sistema est balanceado ou no. Quando o sistema est desbalanceado o
algoritmo reporta a MV que deve ser migrada, a mquina fsica de origem e de destino, para que ocorra sua migrao. A escolha deste algoritmo se justifica por ser de
simples implementao, ter complexidade computacional polinomial e por ter uso
facilmente adaptado para virtualizao de sistemas, cujo elemento base de migrao
uma MV.
A equao e a inequao, apresentadas a seguir, so determinantes para as aes
tomadas por este algoritmo guloso 5 .
v - Varivel que representa uma das mquinas virtuais do sistema.
i e j - Variveis que representam uma das mquinas fsicas do sistema. Sempre,
i 6= j.
hi (v) - Carga atual de CPU sobre a mquina i, sem contar com a carga gerada
pela MV v.
pi (v) - Carga que a MV v gera sobre a mquina i.
li (v) - Carga atual de CPU sobre a mquina i.
(i) Condio de equilbrio:
ahi (v)+pi (v) ahi (v) 2(alj (v)+pj (v) alj(v) )
(ii) Custo marginal:
Hi (v) = ali (v)+pi (v) ali (v)
5
Algoritmo guloso, ou ganancioso, uma tcnica de algoritmos para resolver problemas de

otimizao, sempre realizando a escolha que parece ser a melhor no momento; fazendo uma escolha
tima local, na esperana de que esta escolha leve at a soluo tima global.
32
A inequao, apresentada em (i), reflete a condio de equilbrio que determina

se o sistema est ou no balanceado. A mquina i, representada no lado esquerdo
da inequao, a mquina que contm atualmente a MV v. No lado direito, temos
a mquina j com potencial de receber a MV v. Enquanto a inequao satisfeita,
significa que o sistema se mantm balanceado. Caso a inequao no esteja satisfeita, implica que a mquina i est em desequilbrio em relao a mquina j. Para
equilibr-la novamente, a MV v, deve migrar para alguma mquina a ser determinada pela equao (ii).
A equao, apresentada em (ii), representa o custo marginal, que constitui a
base de escolha da mquina de destino. A mquina de destino a ser escolhida, ser
a que possuir o menor custo marginal.
De maneira intuitiva, pode-se ver o lado esquerdo da inequao como uma quantificao da carga sobre o mquina i, e o lado direito, a tentativa de prever como
seria se a MV v estivesse executando na mquina j. Se a carga total gerada em j for
sensivelmente menor que a gerada em i, indica que o sistema est em desequilbrio e
que para equilibr-lo, a MV v, que executa em i, deve migrar para outra mquina.
O pseudo algoritmo, originado da condio de equilbrio e do custo marginal,
apresentado no apndice B.
Os produtos de virtualizao, juntamente com o sistema de balanceamento apresentado neste captulo, sero a base do ambiente experimental discutido no prximo
captulo.
33
Captulo 4
Avaliao Experimental
Considerando que, toda avaliao proposta neste trabalho, se baseia em experimentos reais e no simulados, a etapa descrita neste captulo foi a mais longa e trabalhosa
desta dissertao. O ambiente experimental, formado pela combinao de diversos,
e muitas vezes complexos softwares, que deveriam interagir entre si, fez com que a
concluso desta etapa se tornasse um desafio.
Outro fator desafiador, foi a construo da metodologia a ser utilizada. Existem
trabalhos, como [10],[3],[2] e [42], que fazem comparaes entre algoritmos de balanceamento. Existem outros, como [5],[20],[22] e [18], que comparam a migrao de
tcnicas de virtualizao. Nos experimentos apresentados neste captulo, busca-se
comparar a eficincia das tcnicas de virtualizao, quando suas MVs podem ser
migradas, conforme determinado por um algoritmo de balanceamento. O caminho
seguido foi baseado nas metodologias usadas nestes trabalhos, utilizando diferentes aplicaes, variando as execues; ora com sistema de balanceamento, ora sem
sistema de balanceamento; ora com carga balanceada, ora com carga desbalanceada.
O OpenVZ e o Xen sero utilizados nos experimentos como representantes das
tcnicas de virtualizao por container e para-virtualizao, respectivamente. Mais
detalhes sobre os objetivos dos experimentos, assim como, o ambiente experimental
e os resultados, podem ser conferidos neste captulo.
4.1
Objetivos dos Experimentos
O objetivo dos experimentos comparar a influncia do overhead de virtualizao do

sistema e do overhead de migrao para duas tcnicas de virtualizao de sistemas.
As comparaes dos resultados dos experimentos, devem expor, alm do overhead
de virtualizao, o custo envolvido na migrao das MVs. Este custo da migrao
composto pelo overhead de migrao, que definimos como o tempo de CPU ocupado
para migrar uma MV, e o downtime de migrao, que o tempo de inatividade da
MV durante a migrao. Enquanto o downtime influencia diretamente a mquina
34
migrada, o overhead de migrao pode influenciar todas as MVs localizadas nas

MFs de origem e destino da migrao. O tempo de execuo das aplicaes deve
refletir todos esses overheads. Os experimentos, apresentados neste captulo, tem
por objetivo expor esses overheads e a influncia da migrao no balanceamento de
carga do sistema. Estes experimentos
4.2
Ambiente Experimental
Os testes foram realizados no LCP1 e todos os softwares usados nos experimentos so

gratuitos, de cdigo aberto e sempre citados como referncia em trabalhos cientficos
da rea. Como o foco dos experimentos comparar os resultados de duas tcnicas
de virtualizao, procurou-se usar softwares o mais semelhante possvel para as duas
tecnologias de virtualizao. As caractersticas dos softwares so representadas nas
duas Tabelas a seguir, 4.1 e 4.2. A primeira Tabela, 4.1, mostra os softwares e
suas verses, que foram utilizados no experimento realizados com o Openvz como
tecnologia de virtualizao.
Ambiente OpenVZ
SO Hospedeiro
CentOS 5.2
Kernel Hospedeiro
2.6.18-128.1.1.el5.028stab062.3PAE
SO Hospedados (MVs)
CentOS 5.2
Kernel Hospedado
2.6.18-128.1.1.el5.028stab062.3PAE
Verso do OpenVZ
2.6.18
Verso do NFS
NFSv4
Tabela 4.1: Especificao de Software - OpenVZ.
A Tabela 4.2, apresenta a configurao dos softwares, quando a tecnologia de
virtualizao usada nos experimentos foi Xen.
Ambiente Xen
Hospedeiro
CentOS 5.2
Kernel Hospedeiro
2.6.18-92.1.13.el5xen
SO Hospedados (MVs)
CentOS 5.2
Kernel Hospedado (MVs)
2.6.18-92.el5xen
Verso do Xen
3.2.1
Verso do NFS
NFSv4
Tabela 4.2: Especificao de Software - Xen.
A Tabela abaixo 4.3 apresenta as especificaes de hardware usados nos experimentos.
1
Laborotrio de Computao Paralela da COPPE/UFRJ. Para mais detalhes sobre o LCP, veja
no site www.lcp.coppe.ufrj.br.
35
Processador
Memria RAM
Rede (MVs)
Disco
Hardwares
Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
2GB
100 Mbit/s
160 GB 7.200 RPM SATA
Tabela 4.3: Especificao do Hardware.

A Figura 4.1, mostra a arquitetura do ambiente experimental. Todas as mquinas esto interconectadas por meio de um switch, formando uma rede com as
caractersticas apresentada Tabela 4.3. A mquina superior usada somente para
a gerncia das MVs hospedadas nas outras mquinas fsicas. Esta mquina executa
o mdulo CC (Controle Central) do gerenciador apresentado no captulo anterior.
As MFs (Mquinas fsicas), localizadas na parte inferior da Figura, so as mquinas
que hospedam todas as MVs envolvidas nos testes. Todas essas mquinas fsicas
possuem o mdulo CL (Controle Local) do gerenciador. Todas as MFs com mdulo
CL so clientes e servidores NFS (Network file System) 2 . A instalao das MVs
envolvidas nos testes so igualmente distribudas pelas MFs e toda parte persistente
em disco do SO das MVs dividida entre as mquinas fsicas. Por exemplo, se tivermos trs MFs e nove MVs, cada MF receber os arquivos persistentes de trs MVs.
A MF exporta, via NFS, toda rea de disco de suas MVs, por outro lado, todas as
outras MFs montam todos os diretrios exportados. Desta maneira, todas as MFs
tm acesso aos arquivos de todas as MVs do sistema. O sistema foi configurado desta
maneira para permitir que as MVs possam migrar de maneira mais eficiente, sem
necessidade de levar para a mquina de destino toda a instalao do seu SO e todos
os seus arquivos. Assim, uma MV pode estar executando na MF1 e estar acessando
seus arquivos localizados fisicamente na MF2. O Xen j estava habilitado a operar
a migrao dessa maneira, mas o OpenVz teve seu script de migrao levemente
modificado para funcionar desta forma.
Conforme comentado no Captulo 3, a gerncia de memria se d de maneira
distinta para cada uma das tcnicas de virtualizao experimentadas. Por ser um
quesito importante na comparao das tcnicas, as configuraes que definem a
quantidade de memria usada pelas MVs tenta aproximar as condies das duas
tcnicas. Para as duas primeiras aplicaes, foi configurado 100MB e para a a
terceira 200MB. O tamanho da memria da MV importante por influenciar diretamente na quantidade de dados trafegados na migrao, e consequentemente, no
tempo total de migrao.
O intervalo entre as coletas de dados por parte do controle central de 10 segundos. O intervalo configurvel no gerenciador. O tempo de 10 segundo foi escolhido
2
Sistema de arquivo distribudo usado para compartilhar arquivos e diretrios entre sistemas
interconectados, criando assim um diretrio virtual
36
Figura 4.1: Sistema Experimental.
37
baseado no tempo total de migrao das MVs. Para cada experimento, as aplicaes
so iniciadas simultaneamente.
4.3
Organizao dos Experimentos
A apresentao dos experimentos e seus resultados est dividida em trs sees.

Cada seo apresenta os experimentos realizados com uma aplicao diferente. No
Experimento1 e no Experimento2, usada aplicao sinttica e no Experimento3,
uma aplicao real. Os testes realizados nos experimentos contemplam igualmente
as duas tecnologias de virtualizao em questo. Para cada aplicao, so avaliadas algumas variaes quanto a distribuio do workload sobre as MF e quanto
possibilidade de ativao do balanceador de carga do sistema. Em especial, para o
experimento referente a compilao do kernel, so variados parmetros de compilao da aplicao e capacidade da rede. Em todos os experimentos so usadas nove
mquinas virtuais.
Enquanto as variaes realizadas no Experimento3 so explicadas na Seo 4.8,
que apresenta o Experimento3; as possveis variaes sobre a distribuio inicial do
workload e a ativao do balanceamento de carga, so descritas abaixo:
Balanceado - Sem Migrao Conforme a Figura 4.2, as MVs so igualmente distribudas sobre as MF, cada MF recebendo 3 MV. Esta configurao permanece
durante toda execuo, pois no realizada migrao para balancear a carga
do sistema.
Balanceado - Com Migrao Nesta variao, as MVs iniciaro o experimento
igualmente distribudas sobre as MFs do sistema, conforme a Figura 4.2. Como
permitido a migrao, ao final da execuo, a distribuio das MVs em relao
as mquinas fsicas pode estar totalmente alterada.
Desbalanceado - Sem Migrao Neste caso, o sistema fica desbalanceado, a distribuio das MVs ocorre como representado na Figura 4.3 por toda a execuo
do experimento. A MF1 recebe cerca de 78% do workload, o que corresponde
a execuo de 7 MVs, e a MF2 e MF3 recebem 11% cada uma, correspondendo
a uma MV para a MF2 e uma para a MF3.
Desbalanceado - Com Migrao Neste experimento, o balanceador ativado e
a disposio inicial das MVs tambm se d conforme a Figura 4.3. Ao balancear
a carga do sistema, o balanceador migra MVs de uma MF para outra, alterando
a disposio inicial das MVs. Balanceando a carga, espera-se que melhore o
tempo mdio de execuo da aplicao Sinttica que executa nas MVs.
38
Figura 4.2: Configurao Balanceada
39
Figura 4.3: Configurao Desbalanceada.
40
4.4
Aplicaes Utilizadas nos Experimentos
Todas as aplicaes usadas nos experimentos tm perfil CPU-Bound, ou seja, seu desempenho est diretamente relacionado ao tempo de CPU alocado para a aplicao
e a capacidade de processamento desta CPU. Em termos de desempenho, o processador deve ser visto como gargalo para quase todos os experimentos. A motivao
de se usar aplicaes CPU-Bound se deve ao objetivo de expor, alm do downtime,
o overhead de migrao das tcnicas. Ao executar aplicaes CPU-Bound em todas
as MVs, espera-se que tanto o downtime quanto o overhead de migrao influenciem
no tempo de execuo desta MV. O mecanismo de migrao e as aplicaes das MVs
estaro competindo pelo recurso CPU das MF.
Todas as variaes realizadas nos experimentos, so executadas no mnimo sete
vezes. O erro apresentado nos grficos, reflete o desvio padro destas execues.
Foram utilizadas nos experimentos, duas aplicaes sintticas e uma aplicao real,
e por isso, as aplicaes foram denominamos de Sinttica1, Sinttica-Randmica e
Kernel. Nas subsees a seguir, so apresentadas mais caractersticas das aplicaes
usados nos experimentos:
4.4.1
Sinttica
Baseado no projeto Stress [32], a funo apresentada abaixo calcula por diversas
vezes a raiz quadrada de um nmero randmico. As instrues desta funo sero
puramente matemticas, requerendo uso intenso de processador. Esta aplicao foi
utilizada no Experimento1.
i n t hogcpu ( v o i d )
{
i n t a=0, c =0;
while (1) {
i f ( a == 19000) {
usleep (10) ;
a = 0;
c++;
i f ( c ==18000)
return 0;
}
a++;
s q r t ( rand ( ) ) ;
}
}
41
Listagem 4.1: Sinttica1.c
4.4.2
Sinttica-Randmica
A funo apresentada na listagem 4.2, escrita na linguagem Python, executa com alguma probabilidade um determinado nmero de instncias da aplicao Sinttica. O
loop principal executado cinco vezes, e em cada iterao, um dos casos seguintes ir
ocorrer: Com probabilidade de 0,2 executado uma instncia da aplicao Sinttica.
Com probabilidade 0,2 so executadas duas instncias da aplicao Sinttica. Com
probabilidade 0,1 so executadas quatro instncias da aplicao Sinttica. Com probabilidade 0,5 a MV fica "dormindo"por 30 segundos. Diferente do que ocorre com
a funo Sinttica pura, a funo Sinttica-Randmica apresenta uso no regular de
CPU. Esta aplicao foi utilizada no Experimento2.
import s y s
import os , random , time
s e e d = s y s . argv [ 1 ]
random . s e e d ( s e e d )
f o r nexec in range ( 5 ) :
a = random . r a n d i n t ( 0 , 100)
i f a < 20:
os . system ( " s i n t e t i c a 1 nthread 1 " ) ;
continue ;
i f a < 40:
continue ;
i f a < 50:
continue ;
time . s l e e p ( 3 0 ) ;
continue ;
Listagem 4.2: Sinttica-radomica.py
4.4.3
Kernel
Esta aplicao se refere a compilao do kernel do linux. uma aplicao real,

geralmente executada por desenvolvedores do kernel, utilizada em comparaes de
42
modelos de virtualizao [24] e faz parte de benchmarks. A compilao do kernel

requer, alm do uso intenso de CPU, muito acesso ao disco rgido. A verso do
kernel compilada no experimento, foi a linux-2.6.12, assim como no trabalho [24],
usando o comando "make -j8 bzImage". O parmetro -j8 indica a quantidade de
jobs simultneos que usados na compilao do kernel, recomenda-se 2 jobs para cada
processador da mquina fsica, conforme [56]. Como cada MF tinha 4 processadores,
foi usado o parmetro j8 no comando de compilao. Esta aplicao foi utilizada
no Experimento3.
4.5
Validao Experimental do Gerenciador de

Mquinas Virtuais
Antes de comear os experimentos propostos, foram executados testes experimentais de validao do gerenciador de mquinas virtuais implementado. Nesta seo
apresentado um dos testes de verificao. Neste teste, pode-se avaliar tanto o funcionamento do gerenciador de mquina virtual, quanto o algoritmo de balanceamento
e toda interao dos softwares do sistema. Antes de chegar a verso final, esse teste
foi til na depurao de todos os softwares e sua integrao. Na execuo deste
teste, foram usadas 4 MV e 3 MF. Cada mquina virtual executa uma aplicao,
cuja execuo est basicamente associada ao uso de CPU. Propositalmente, as aplicaes comeam a execuo em tempos diferentes e podem variar a carga de CPU
durante a execuo.
A Figura 4.4, apresenta como foi o andamento do teste realizado. Esta Figura
contm trs grficos alinhados pelo eixo x. Cada grfico est relacionado com uma
MF. Em cada um destes grficos, o eixo y representa o percentual do consumo de
CPU da mquina fsica. No eixo x, tem-se o tempo decorrido em segundos. O
consumo de CPU total da MF, a soma do consumo de CPU atribudo as MVs que
esto nesta MF. O consumo de cada MV representado na Figura por uma cor,
independente da MF na qual ela esteja, e mesmo quando a MV migra de MF, a cor
correspondente ao consumo desta MV na MF de destino, ser a mesma que era na
origem.
De posse dessas informaes, podemos analisar os grficos da Figura 4.4. Nos primeiros 25 segundos, nenhuma MV executa alguma aplicao. No segundo 25, duas
MVs, representadas pela cor roxa e verde, iniciam execuo consumindo quase 20%
de CPU de suas MFs. Neste momento, tem-se um desbalanceamento do sistema,
mas de nada adiantaria migrar qualquer uma das MVs, pois o desbalanceamento iria
permanecer. O balanceador "entende"este fato, e no executa nenhuma migrao.
No segundo 120, uma nova MV, representada pela cor amarela, inicia execuo,
43
elevando o percentual de uso de CPU da sua MF para 40%. Imediatamente, o gerenciador nota o desbalanceamento e migra a MV amarela, rebalanceando o sistema.
No segundo 225, a ltima MV, representada pela cor cinza, comea a execuo que
vai aumentando gradualmente o percentual de uso de CPU de sua MF. O gerenciador s realiza uma migrao em resposta ao desbalanceamento causado por essa
MV cinza, quando nota que pode balancear melhor o sistema migrando a MV verde,
deixando o sistema melhor balanceado.
Figura 4.4: Grfico do consumo total de CPU de trs Mquinas Fsicas. Cada cor
representa carga gerada por uma mquina virtual.
4.6
Experimento1
Este experimento se baseia na execuo da aplicao Sinttica com uma variao

na distribuio da carga inicial sobre as MFs do sistema. Para este experimento,
todas as MVs do sistema executaro o mesmo trabalho, que consiste em duas instncias da Aplicao Sinttica1. Essas instncias so executadas, simultaneamente
em todas as MVs. Com as configuraes utilizadas para este experimento, quando
44
duas instncias da aplicao Sinttica1 executada em uma MF com a CPU no

sobrecarregada, a aplicao ocupa cerca de 48% da CPU desta MF.
No experimento so usadas 3 MFs, e sobre elas, so distribudas 9 MVs que executaro instncias da aplicao Sinttica. As variaes executadas neste experimento,
so: Balanceada - Sem Migrao, Desbalanceada - Sem Migrao e Desbalanceada Com migrao. As trs subsees seguintes apresentam os resultados das variaes
deste experimento para os dois modelos de virtualizao:
4.6.1
OpenVZ
A Figura 4.5, mostra os resultados obtidos para a execuo da aplicao Sinttica1,

nos diferentes cenrios, usando o OpenVZ como tcnica de virtualizao. Conforme
indicado na legenda da Figura 4.5, o eixo x, identifica as MVs, o eixo y, se refere ao
tempo de execuo da aplicao que executada na MV e a cor identifica a forma
de execuo. Por exemplo, para a execuo Balanceada, a aplicao da mquina
virtual 1 demorou cerca de 113 segundos.
350
Balanceado - Sem Migracao

Desbalanceado - Sem Migracao
300
Desbalanceado - Com Migracao
Tempo(s)
250
200
150
100
50
0
Maquinas Virtuais OpenVZ
Figura 4.5: Experimento1, OpenVZ. Tempo de execuo das MVs.
Quando a configurao inicial do sistema desbalanceado, representado nos grficos de resultados pelas cores vermelha e verde, as MVs que apresentam maiores
tempos de execuo, as MVs 1 a 7, so que inicialmente estavam localizadas na
MF1, conforme indicado na Figura 4.3. Este tempo de execuo explicado pela
sobrecarga do recurso CPU, provocada pelo grande nmero de MVs. Quando a
45
configurao inicial Balanceada, representado pela cor azul, as MVs, e consequentemente, o workload, est igualmente distribudo sobre as MF do sistema. Como
era de se esperar, o balanceamento da carga melhorou o tempo de execuo das
aplicaes.
4.6.2
Xen
A Figura 4.6, mostra os resultados obtidos na execuo da aplicao Sinttica1, nos

diferentes cenrios, usando o Xen como tcnica de virtualizao. A apresentao
grfica ocorre da mesma maneira que na Figura anterior 4.5.
350

300
Tempo(s)
250
200
150
100
50
0
Maquinas Virtuais Xen
Figura 4.6: Experimento1, XM. Tempo de execuo das MVs.
4.6.3
Comparao OpenVZ x Xen
A Figura 4.7, relaciona os resultados do OpenVZ e do Xen quando a configurao

do sistema Desbalanceado - Com Migrao. Conforme os resultados apresentados na Figura 4.7, em geral, as MVs do OpenVZ concluram a execuo antes das
MVs do Xen. Esses resultados podem ser atribudos a dois fatores principais. O
primeiro, pode ser notado comparando o tempo de execuo das MVs, quando estas
executavam sobre alguma MF sobrecarregada. Conforme mostrado na Figura 4.7, o
Xen no teve boa escalabilidade para executar aplicaes puramente CPU-Bound.
Quando o sistema estava desbalanceado e havia sete MVs executando aplicaes
46
CPU-Bond sobre uma MF, o tempo de execuo das MVs do OpenVZ foi menor
que o tempo de execuo das MVs do Xen. O outro fator, est relacionado com o
tempo de migrao das MVs. Quanto menor o tempo de migrao das mquinas
virtuais, mais rpido ser o balanceamento de carga, e quanto mais balanceada a
carga, melhor ser o througput do sistema. A velocidade da migrao refletiu nos
resultados apresentados. Note que para a MV 9 da Figura 4.5, para o sistema desbalanceado (cores verde e vermelho), o tempo de execuo foi maior quando houve
balanceamento de carga. Isso representa o impacto da primeira MV que foi migrada
para balancear a carga, pois, esta passou a disputar recursos de CPU com a MV1.
Como pode ser observado na Figura 4.6, o impacto equivalente quase insignificante
para o Xen.
350
VZ Desbalanceado - Com Migracao

XM Desbalanceado - Com Migracao
300
Tempo(s)
250
200
150
100
50
0
Maquinas Virtuais VZ e XM
Figura 4.7: Experimento1, OpenVz x Xen. Tempo de execuo das MV.
A Figura 4.8, mostra a mdia do tempo de execuo das aplicaes das MVs, isto
, o tempo mdio que as MVs do sistema demoraram para realizar sua execuo.
O eixo y corresponde ao tempo mdio de execuo, j o eixo x, a tecnologia de
virtualizao avaliada. Com o sistema desbalanceado, realizar o balanceamento de
carga melhorou igualmente o tempo de execuo das MVs. Tanto para o OpenVZ,
quanto para o Xen, o tempo melhorou em 39%.
47
350

300
Tempo(s)
250
200
150
100
50
0
OpenVZ
Xen
Tecnologia de Virtualizacao
Figura 4.8: Experimento1, OpenVz x Xen. Tempo de execuo mdio das MV.
4.7
Experimento2
No Experimento2, a aplicao utilizada como base a Sinttica-Randmica. Neste

experimento, so usadas 3 MFs e sobre elas so distribudas 9 MVs executando a
aplicao Sinttica-Randmica. Todas as 9 MVs do sistema iniciaro simultaneamente a execuo desta aplicao, mas isso no significa que o trabalho gerado na
execuo da aplicao estar igualmente distribudo sobre as MVs. As variaes
neste experimento se restringem a: Balanceado - Sem Migrao e Balanceado com
migrao. As caractersticas desta aplicao dificultam o trabalho do balanceador.
Durante o experimento, ocorrem mudanas aleatrias da carga gerada por uma MV,
o que pode influenciar o balanceador a realizar migraes desnecessrias. Neste experimento avaliado se essas migraes, geralmente desnecessrias, iro prejudicar
o tempo de execuo total das MVs.
As duas subsees seguintes apresentam os resultados das variaes deste experimento para os dois modelos de virtualizao.
4.7.1
OpenVZ
A Figura 4.9 mostra que o balanceamento de carga praticamente no alterou os

tempos execuo. Isso indica que mesmo com algumas migraes desnecessrias, o
sistema no teve seu tempo de execuo prejudicado. As migraes no prejudica-
48
ram o tempo de execuo das aplicaes justamente pela caracterstica da aplicao.

Por ser puramente CPU-Bound e por no ter sobrecarregado as MFs, a aplicao
no prejudicou nem o downtime, nem o tempo total de migrao. Como resultado,
as migraes no prejudicaram o tempo de execuo das MVs.
400
Balanceado - Com Migracao
Tempo(s)
300
200
100
4.7.2
Xen
A Figura 4.10 tambm mostra que mesmo com migraes desnecessrias, ocorridas
com o Xen, no prejudicou o tempo de execuo dos MVs.
4.7.3
OpenVZ x Xen
A comparao entre os tempos do OpenVZ e do Xen, apresentadas nas Figuras 4.12 e

4.11, indicam que as duas tcnicas tiveram resultados muito parecidos quando experimentados com a aplicao Sinttica-Randmica. Isso mostra que, ou os overheads
das migraes e execues foram insignificantes, ou que foram apenas muito parecidos.
49
400
Balanceado - Com Migracao
Tempo(s)
300
200
100
400
VZ Desbalanceado - Com Migracao
XM Desbalanceado - Com Migracao
Tempo(s)
300
200
100
Maquinas Virtuais VZ e XM
Figura 4.11: Experimento2, OpenVz x Xen. Tempo de execuo das MV.
50
350

300
Tempo(s)
250
200
150
100
50
0
OpenVZ
Xen
Figura 4.12: Experimento2, OpenVz x Xen. Tempo de execuo mdio das MV.
4.8
Experimento3
A aplicao, usada neste experimento, a compilao do kernel do linux-1.6.12

com o comando: "make -j8 bzImage". Neste experimento, tambm so usadas trs
MFs, essas MFs recebem 9 MVs, sobre as quais igualmente distribudo o trabalho
de compilao realizado pelo sistema. A compilao iniciada ao mesmo tempo
em todas as MVs. Com as configuraes utilizadas nos experimentos, e quando a
compilao do kernel executada em uma MF com a CPU no sobrecarregada, a
aplicao ocupa cerca de 80% da CPU.
Para este experimento, foi necessrio considerar as quantidades de memria alocada para cada MV. Se inicialmente foi alocado pouca memria, por conta da baixa
demanda das aplicaes experimentadas, a quantidade de memria requerida para
a compilao do kernel deve ser o dobro do que vinha sendo usada, passando de
100MB para 200MB. No OpenVz, pelas caractersticas de uso de memria, conforme
explicado no Captulo 3, no houve problemas. Mas essa mudana teve bastante
impacto para o Xen. Foi necessrio descobrir o mnimo de memria adequada para
que a aplicao no realizasse swap. Essa necessidade surge da escassez de memria
da MF que deve suportar mais de 7 MVs, e conforme explicado no captulo anterior, no Xen, a quantidade de memria reservada para as MV deve ser menor que a
quantidade total de memria da MF.
As subsees seguintes, apresentam os resultados das variaes deste experimento
51
para os dois modelos de virtualizao.
4.8.1
OpenVZ
Como j era esperado, a Figura 4.13 mostra como o balanceamento de carga melhorou o tempo de execuo das aplicaes das MVs. O destaque apresentado nesta
Figura, so os tempos de execuo das MVs 1, 2, 3, 4, 5, 6 e 7 para a configurao
Desbalanceado - Sem migrao, representado pela cor verde. O tempo de execuo
das MVs 1, 2, 3, e 4, cerca de 40% maior que o tempo das MVs 5, 6 e 7, mas essas
MVs executam o mesmo workload na mesma MF conforme mostrado na Figura 4.3.
Na verdade, esse resultado aponta a influncia do disco na compilao do kernel.
O tempo das MVs 1, 2, 3 e 4 maior por que seus arquivos devem ser acessados
remotamente, diferente do que ocorre com as MVs 5,6 e 7 cujos arquivos so locais,
trazendo mais velocidade no acesso ao disco. Como a compilao exige muita escrita em arquivo e realizar a escrita nos arquivos remotos piora o tempo de execuo
da aplicao, o tempo de execuo foi maior nas aplicaes cujos arquivos estavam
remotos.
500
Tempo(s)
400
300
200
100
52
4.8.2
Xen
Dois fatos se destacam na Figura 4.14. O primeiro, que o balanceamento de carga

no melhorou o tempo de execuo das MVs. O segundo, se refere a influncia do
disco, conforme comentado na subseo 4.8.1. O uso do balanceador no melhorou
o tempo de execuo, devido a complexidade e ao tempo necessrio para migrar
uma MV que estava compilando a aplicao Kernel. A grande quantidade de escrita
em memria complica a migrao da MV, quando esta realizada com tcnica de
pr-cpia, como o caso do Xen. A longa demora para migrar apenas uma mquina
virtual prejudicou o balanceamento, e consequentemente a eficincia de execuo do
sistema, resultando em alto tempo de execuo das aplicaes, mesmo habilitando
o balanceamento de carga. O tempo semelhante de execuo para as sete primeiras
MVs do Xen, na configurao Desbalanceado - Sem Migrao (representado pela
cor verde), difere do equivalente, apresentado para o OpenVZ. Este fato est relacionado com o algoritmo de escalonamento de CPU usado nos duas tcnicas. As
condies so iguais para os dois, mas o OpenVZ favorece as MVs com disco local,
em detrimento das MVs com disco remoto.
500
Tempo(s)
400
300
200
100
53
4.8.3
OpenVZ x Xen
Conforme discutido na subseo 4.8.1, ao observar os resultados do OpenVZ para a

configurao Desbalanceado -Sem Migrao, as MVs cujo sistema de arquivo estava
na MF local, tiveram tempo de execuo menor se comparado com as MVs com
arquivos remotos. J a subseo 4.8.1, para Xen, com essa mesma configurao, as
MVs tiveram tempo de execuo parecido. Pela Figura 4.15, pode-se notar que os
tempos mdios para a configurao Desbalanceado - Sem Migrao, so equivalentes.
Por esse motivo, pode-se concluir que o OpenVZ favorecia as MVs com acesso mais
rpido ao disco, em detrimento as MVs que tinham acesso mais lento ao disco remoto,
essa priorizao caracteriza falha de isolamento [25].
350

300
Tempo(s)
250
200
150
100
50
0
OpenVZ
Xen
4.9
Discusso dos Resultados
Os experimentos apresentados mostraram que a tcnica de migrao pode influenciar na qualidade do balanceamento de carga. O Experimento1 e principalmente
o experiento3, mostram que, a tcnica de live migration usada pelo Xen, impediu
que o sistema fosse balanceado no tempo desejado, enquanto a tcnica usada pelo
OpenVZ, permitiu um balanceamento mais eficiente. Os passos iterativos, realizados
na pr-cpia implementada pelo Xen, em conjunto com sua tcnica de virtualizao,
geraram grande quantidade de dados que foram transferidos pela rede durante as
54
fases da pr-cpia. A demora na transferncia desses dados, tornou o balanceamento

de carga ineficiente. Quanto maior a capacidade das mquinas do cluster, maior seria o impacto do tempo de transferncia total de MV, pois o recursos das mquinas,
estariam temporariamente desperdiados. Seria interessante verificar se o impacto
do tempo de migrao seria maior em um cluster com mais mquinas.
No Experimento2, apesar das caractersticas bastante peculiares da aplicao
utilizada, com destaque para o baixo tempo de migrao total, as migraes desnecessrias realizadas na tentativa de balancear o sistema, no impactou o tempo
execuo das MVs. Este fato pode indicar que dificilmente o overhead de migrao
de mquina virtual - quando o tempo total de migrao baixo - e at mesmo o
downtime, tanto do Xen quanto do OpenVZ, ser relevante em algum sistema de
balanceamento que no use aplicaes interativa ou de tempo real. Por outro lado,
um tempo longo de migrao pode tornar o balanceamento de carga invivel. Num
cenrio onde a carga de processamento gerado pelas MVs muito varivel e o tempo
de migrao destas MVs muito alto, para este caso balancear a carga do sistema
pode at ser prejudicial, piorando a eficincia do cluster.
O Experimento3 tambm pode revelar uma falha de isolamento do OpenVZ.
Sobre as condies impostas no Experimento3, o gerenciador do recurso CPU do
OpenVZ, favoreceu determinadas MVs em detrimento de outras MVs da mesma
MF. Esse fato s foi notado neste experimento, devido a caracterstica da aplicao
usada no Experimento3, pois esta, tambm dependia do tempo de acesso ao disco,
enquanto as utilizadas nos outros experimentos, eram puramente CPU-Bound. A diferena entre os resultados do Xen e o OpenVZ, pode ser atribuda as caractersticas
dos escalonadores de processo por eles utilizados.
Ao comparar os resultados do Xen e do OpenVZ obtidos nos experimentos realizados, foi observado que o tempo de migrao total de uma MV pode influenciar
diretamente na qualidade do balanceamento de carga e consequentemente no
throughput do sistema.
55
Captulo 5
Trabalhos Relacionados
Com o crescente interesse sobre as tecnologias de virtualizao, muitas pesquisas
realizadas neste campo, buscando geralmente melhorar a eficincia e a segurana
de sistemas em diversas reas da computao. Este fato ressalta a importncia
desses trabalhos sobre o futuro da virtualizao. Neste captulo, so abordados os
trabalhos que serviram como base para esta dissertao ou que exploram algum
assunto diretamente relacionado ao tema aqui abordado.
Na primeira seo so relacionados os trabalhos que exploram ou comparam
caractersticas de sistemas de virtualizao. A segunda seo, a 5.2, apresenta os
trabalhos que abordam a migrao de mquinas virtuais. Na ltima seo, so
discutidos os trabalhos sobre algoritmos de balanceamento de carga.
5.1
Comparao entre Tcnicas de Virtualizao
Com toda a expectativa sobre o futuro da virtualizao, busca-se comparar as tecnologias de virtualizao que esto em evidncia. O artigo Xen and the Art of Virtualization [40] apresenta a arquitetura e algumas estratgias de virtualizao, usadas
pelo Xen, para implementar para-virtualizao. Ainda neste trabalho, so realizadas
comparaes de eficincia, que apresentam a superioridade da para-virtualizao sobre a virtualizao total. Em outro trabalho , Soltesz [19] apresenta a arquitetura de
um sistema virtualizado por containers, e usa execues de microbenchmarks para
comparar sua eficincia com as das outras tcnicas de virtualizao. Para grande
parte das funes bsicas do SO testadas, a tcnica de containers foi superior a de
para-virtualizao.
Mesmo com algumas restries, virtualizao de sistemas tm sido aplicadas em
clusters de alto desempenho como citado no trabalho [13]. Apesar dos desafios de
eficincia, a virtualizao pode melhorar a utilizao dos recursos e a comodidade
para os usurios de clusters de alto desempenho. Em seu trabalho, Walters [24] compara a eficincia de diferentes estratgias de virtualizao. So usados benchmarks
56
de computao cientfica para comparar Xen, Openvz e VMware quanto a eficincia no uso dos recursos de CPU, rede e disco. Toda as anlises dos resultados so
baseadas nos resultados individuais de cada um destes recursos; no considerado
o interrelacionamento dos recursos nem a possibilidade de migrao das mquinas
virtuais do sistema.
Em uma tentativa de resolver, simultaneamente, o problema de desempenho
da virtualizao total e a necessidade de alterao do SO hospedado na paravirtualizao, a arquitetura x86 foi estendida para suportar a virtualizao clssica. No trabalho de Adams, Agesen e outros [24], so comparadas as primeiras
implementaes de virtualizao com suporte de hardware com a virtualizao total. A virtualizao por hardware demonstrou ser menos eficiente na maioria dos
testes realizados. Os autores concluram que os resultados refletem a imaturidade
da tecnologia. Foi verificado que os pontos de maior dificuldade da virtualizao
por software e por hardware no so comuns, desta forma, a espectativa de uma
combinao mais madura dessas duas tcnicas torna a tecnologia de virtualizao
promissora.
O trabalho [25], se preocupa em comparar somente a capacidade de isolamento
das tcnicas. Para avaliar o isolamento, medido o quanto uma aplicao, faminta
por recurso e executando em uma MV, pode influenciar a execuo de aplicaes que
esto em outra MV. Nos testes, foram comparados as tcnicas de virtualizao total,
para-virtualizao e virtualizao por containers. Os resultados foram sensivelmente
diferentes para cada uma das classes. A tcnica de virtualizao total forneceu
isolamento perfeito nos testes, a para-virtualizao, um nvel de isolamento muito
prximo do perfeito, j o isolamento da virtualizao por containers, foi em alguns
casos ruim e estando sempre abaixo das outras classes.
5.2
Migrao de Mquinas Virtuais
A migrao de instncias de SOs entre mquinas fsicas resultado de uma separao clara entre hardware e software. Essa caracterstica torna bastante atrativo
o uso de virtualizao em data centers por facilitar o remanejamento por falhas e
permitir balanceamento de carga. Chiristopher Clark, em seu trabalho [18], alm de
revisar alguns mtodos de migrao de MVs que podem ser usados em data centers,
apresentam o conceito de WWS(writable working set) que serve como base em sua
proposta de melhoria na migrao por pr-cpia. Nos testes, a pr-cpia modificada
no trabalho apresentou downtime, imperceptvel, de apenas 60 ms na migrao de
um servidor de jogo interativo.
Reconhecendo o potencial dos sistemas de virtualizao em permitir a consolidao de servios em um ou mais servidores fsicos, Padala, em seu trabalho [22]
57
preocupa-se em encontrar a tecnologia de virtualizao e a configurao mais adequada para consolidar determinados servios. Neste sentido, so realizados testes
combinando a consolidao dos servidores web e de banco de dados em dois servidores fsicos, utilizando o Xen ou o OpenVz como tecnologia de virtualizao. Um
programa simula as requisies realizadas pelos clientes ao servidor web e este, por
sua vez, acessa o banco de dados. So realizados testes de escalabilidade, neste
caso, aumentando o nmero de clientes requisitantes, tempo de resposta do servidor
e consumo de cpu. Nestes testes o OpenVZ apresentou resultados superiores aos
apresentados pelo Xen.
5.3
Balanceamento de Carga
Em 1997, antes da repopularizao dos sistemas de virtualizao, James e outros

[6] usaram um algoritmo de alocao de rotas para Circuitos Virtuais, como base
para balancear a execuo de jobs por diversas mquinas fsicas disponveis. J no
trabalho [3], aproveitando as facilidades oferecidas pela migrao de MV, o autor
prope algoritmos para balancear a carga do sistema migrando MVs entre as mquinas fsicas. No sistema de balanceamento proposto, so coletadas periodicamente
informaes sobre a carga de cpu, memria e rede gerada por cada uma destas VMs.
Para decidir se deve haver migrao, essas informaes so tratadas e comparadas
com o SLA proposto para cada MV. Uma limitao do sistema implementado que
este s suporta Xen como sistema de virtualizao.
Em um trabalho recente [2], foi proposta uma mtrica que avalia o desbalanceamento da carga do sistema. Esta mtrica resultou na criao de um framework
de balanceamento de MVs. A arquitetura do framework e o algoritmo de balanceamento deste trabalho so semelhantes aos apresentados nesta dissertao. O
gerenciamento tambm centralizado e o algoritmo guloso, buscando o menor
desbalanceamento para cada iterao, parecido com o que foi implementado aqui.
A diferena entre o trabalho [2] e esta dissertao, so os objetivos e as limitaes.
Enquanto o trabalho se preocupa em comparar o seu algoritmo de balanceamento
com os j existentes a dissertao busca comparar as tcnicas de virtualizao. O
framework do trabalho suporta somente a tecnologia VMware ESX, j o sistema de
balanceamento desta dissertao pode operar com o Xen e com o OpenVZ.
58
Captulo 6
Concluses
Nesta dissertao realizada uma comparao experimental da eficincia e do comportamento das tcnicas de virtualizao por containers (OpenVZ) e paravirtualizao (Xen), quando suas mquinas virtuais esto sujeitas a migrao, com a finalidade
de balancear a carga de processamento de um cluster de computadores. O principal
objetivo, apontado no incio desta dissertao, de comparar experimentalmente a
eficincia e o comportamento de duas tcnicas de virtualizao, quando suas mquinas virtuais podem ser migradas para balancear a carga de CPU do sistema.
Os resultados apontam algumas caractersticas presentes na migrao implementada pela tcnica usada no Xen, que podem ser prejudiciais para a realizao
do balanceamento de caraga. O alto tempo total de migrao, resultante da tcnica
de migrao usada pelo Xen, fez com que o balanceamento acontecesse de maneira
lenta, subutilizando a capacidade do sistema e aumentando o tempo total de migrao da aplicao. No entanto, o objetivo de comparar a influncia da sobrecarga
de migrao das mquinas virtuais no foi totalmente satisfeito. Para as aplicaes
experimentadas neste trabalho, o overhead de migrao foi sempre insignificante, e
portanto, no era passvel de comparao. Mas, sabe-se que para aplicaes interativa ou de tempo real, este overhead pode ser determinante na escolha da tcnica
de virtualizao.
Um resultado secundrio, que vai alm dos objetivos propostos neste trabalho,
est a falha de isolamento de MV ocorrida em um dos experimentos. Neste mesmo
sentido, fica como legado do trabalho realizado, o gerenciador de mquinas virtuais,
hbil para realizar outros experimentos, tanto para avaliar virtualizao de sistemas
como para comparar algoritmos de balanceamento de carga.
6.1
Trabalhos futuros
Durante a discusso dos resultados deste trabalho, notou-se a necessidade de ampliar

e diversificar os experimentos aqui realizados. Outros trabalhos poderiam explorar
59
algumas ideias ou o prprio ambiente aqui desenvolvido, a fim de ampliar os resultados obtidos nesta pesquisa. Entre estes possveis trabalhos, esto:
Ampliar a Quantidade de Tcnicas de Virtualizao Avaliadas
Neste trabalho, foram avaliadas duas tcnicas de virtualizao, que so considerados atualmente como as mais eficientes. Mas existem outras tcnicas importantes, que poderiam, a partir dos resultados dos experimentos, serem classificadas quanto a sua eficincia em ambientes com balanceamento de carga.
A virtualizao total, por ser uma das mais utilizadas, e a virtualizao com
o auxlio de hardware, por demonstrar ser uma tcnica promissora [24], deveriam tambm ter sua eficincia avaliada, quando executada em um cluster que
permita migrar MVs com a finalidade de balancear a carga do sistema.
Ampliar a Quantidade de Mquinas Fsicas e Virtuais no Sistema
A difuso do uso de Cloud Computing pode implicar na necessidade de grandes
clusters com suporte a virtualizao. Neste ambiente, o balanceamento de
carga pode aumentar a eficincia do sistema. Como tais clusters podem ser
compostos por centenas de MFs e MVs, importante identificar qual tcnica
ou combinao de tcnicas de virtualizao pode ser mais adequada para estes
grandes sistemas.
Aplicaes com Caractersticas Diferentes
Existem importantes tipos de aplicaes que poderiam ser avaliadas. Aplicaes de execuo paralela, aplicaes interativas, aplicaes com muita escrita
em memria e aplicaes que demandam uso intenso da rede. So aplicaes com caractersticas distintas e que podem gerar resultados diferentes dos
encontrados nos experimentos aqui realizados. Por exemplo, sabe-se que aplicaes com escrita intensa em memria apresentam maior impacto no dowtime
e no tempo de migrao das MVs, isso vale tanto para o OpenVZ[5] quanto
para o Xen[26], e este impacto poderia enfatizar algum resultado obtido nesta
dissertao. Seria interessante avaliar as tcnicas por meio de aplicaes que
exploram recursos variados do sistema virtualizado, isso tornaria a avaliao
mais completa.
Acrescentar Novos Parmetros para Determinar o Balanceamento
O algoritmo de balanceamento poderia utilizar outras mtricas para determinar o equilbrio do sistema. Seria vlido utilizar como mtrica a carga gerada
na rede e tambm quantidade de escritas em memria. J existem algoritmos
que utilizam esses parmetros, mas seus trabalhos se restringem a avaliar o
algoritmo construdo e no as tcnicas de virtualizao.
60
Avaliar as Tcnicas de Migrao quando Usadas para Balancear

Carga do Sistema
Conforme j mencionado no Captulo 2, na seo que trata a migrao de
mquinas virtuais, as tcnicas de migrao tm qualidades distintas. Sabe-se
que o custo de se ter um baixo downtime a complexidade e o tempo total
de migrao. Em contrapartida, a migrao para e copia tem alto downtime
mas, baixa complexidade e menor tempo de migrao. Enquanto o uso de live
migration resulta em melhor tempo de execuo das aplicaes da MV migrada, a migrao executada por essa tcnica, pode impactar, negativamente,
o tempo de execuo das aplicaes de MVs, que estejam executando na origem ou no destino. Por esse motivo, seria interessante realizar experimentos
com tcnicas diferentes de migrao.
61
Referncias Bibliogrficas
[1] DEVINE, SCOTT W., B. Virtualization system including a virtual machine monitor for a computer with a segmented architecture, May 2002. Disponvel
em: <http://www.freepatentsonline.com/6397242.html>.
[2] ARZUAGA, E., KAELI, D. R. Quantifying load imbalance on virtualized enterprise servers. In: WOSP/SIPEW 10: Proceedings of the first joint
WOSP/SIPEW international conference on Performance engineering, pp.
235242, New York, NY, USA, 2010. ACM. ISBN: 978-1-60558-563-5. doi:
http://doi.acm.org/10.1145/1712605.1712641.
[3] WOOD, T., SHENOY, P., ARUN. Black-box and Gray-box Strategies for
Virtual Machine Migration. pp. 229242. Disponvel em: <http://www.
usenix.org/events/nsdi07/tech/wood.html>.
[4] SINGH, A., KORUPOLU, M., MOHAPATRA, D. Server-storage virtualization: integration and load balancing in data centers. In: SC 08: Proceedings of the 2008 ACM/IEEE conference on Supercomputing, pp. 112,
Piscataway, NJ, USA, 2008. IEEE Press. ISBN: 978-1-4244-2835-9.
[5] ZHAO, M., FIGUEIREDO, R. J. Experimental study of virtual machine migration in support of reservation of cluster resources. In: VTDC 07:
Proceedings of the 2nd international workshop on Virtualization technology in distributed computing, pp. 18, 2007. ISBN: 978-1-59593-897-8.
doi: http://doi.acm.org/10.1145/1408654.1408659.
[6] ASPNES, J., AZAR, Y., FIAT, A., et al. On-line routing of virtual circuits
with applications to load balancing and machine scheduling, J. ACM,
v. 44, n. 3, pp. 486504, 1997. ISSN: 0004-5411. doi: http://doi.acm.org/
10.1145/258128.258201.
[7] AWERBUCH, B., AZAR, Y., PLOTKIN, S., et al. Competitive routing of
virtual circuits with unknown duration. In: SODA 94: Proceedings of
the fifth annual ACM-SIAM symposium on Discrete algorithms, pp. 321
62
327, Philadelphia, PA, USA, 1994. Society for Industrial and Applied
Mathematics. ISBN: 0-89871-329-3.
[8] FENG, W.-C., CHANG, F., FENG, W.-C., et al. A traffic characterization of
popular on-line games, IEEE/ACM Trans. Netw., v. 13, n. 3, pp. 488
500, 2005. ISSN: 1063-6692. doi: http://dx.doi.org/10.1109/TNET.2005.
850221.
[9] KEREN, A., BARAK, A. Opportunity Cost Algorithms for Reduction of
I/O and Interprocess Communication Overhead in a Computing Cluster, IEEE Trans. Parallel Distrib. Syst., v. 14, n. 1, pp. 3950, 2003.
ISSN: 1045-9219. doi: http://dx.doi.org/10.1109/TPDS.2003.1167369.
[10] MOHAMMADPOUR, P., SHARIFI, M., PAIKAN, A. A Self-Training Algorithm for Load Balancing in Cluster Computing. In: NCM 08: Proceedings of the 2008 Fourth International Conference on Networked Computing and Advanced Information Management, pp. 104109, Washington,
DC, USA, 2008. IEEE Computer Society. ISBN: 978-0-7695-3322-3-01.
doi: http://dx.doi.org/10.1109/NCM.2008.178.
[11] CHOI, H. W., KWAK, H., SOHN, A., et al. Autonomous learning for efficient
resource utilization of dynamic VM migration. In: ICS 08: Proceedings
of the 22nd annual international conference on Supercomputing, pp. 185
http://doi.acm.org/10.1145/1375527.1375556.
[12] WERSTEIN, P., SITU, H., HUANG, Z. Load Balancing in a Cluster Computer. In: PDCAT 06: Proceedings of the Seventh International Conference on Parallel and Distributed Computing, Applications and Technologies, pp. 569577, Washington, DC, USA, 2006. IEEE Computer Society.
ISBN: 0-7695-2736-1. doi: http://dx.doi.org/10.1109/PDCAT.2006.77.
[13] MERGEN, M. F., UHLIG, V., KRIEGER, O., et al. Virtualization for highperformance computing. , 2006. ISSN: 0163-5980.
[14] DEVARAKONDA, M. V., IYER, R. K. Predictability of Process Resource
Usage: A Measurement-Based Study on UNIX, IEEE Trans. Softw. Eng.,
v. 15, n. 12, pp. 15791586, 1989. ISSN: 0098-5589. doi: http://dx.doi.
org/10.1109/32.58769.
[15] MCNETT, M., GUPTA, D., VAHDAT, A., et al. Usher: an extensible framework for managing custers of virtual machines. In: LISA07: Proceedings of the 21st conference on Large Installation System Administration
63
Conference, pp. 115, Berkeley, CA, USA, 2007. USENIX Association.

ISBN: 978-1-59327-152-7.
[16] CentOS. Disponvel em: <http://www.centos.org>.
[17] Usher.
Disponvel em:
UsherDevelopment>.
<http://usher.ucsd.edu/trac/wiki/
[18] CLARK, C., FRASER, K., HAND, S., et al. Live migration of virtual machines. In: NSDI05: Proceedings of the 2nd conference on Symposium
on Networked Systems Design & Implementation, pp. 273286, Berkeley,
CA, USA, 2005. USENIX Association.
[19] SOLTESZ, S., PTZL, H., FIUCZYNSKI, M. E., et al. Container-based
operating system virtualization: a scalable, high-performance alternative
to hypervisors, SIGOPS Oper. Syst. Rev., v. 41, n. 3, pp. 275287, 2007.
ISSN: 0163-5980. doi: http://doi.acm.org/10.1145/1272998.1273025.
[20] BHATTIPROLU, S., BIEDERMAN, E. W., HALLYN, S., et al. Virtual
servers and checkpoint/restart in mainstream Linux, SIGOPS Oper.
Syst. Rev., v. 42, n. 5, pp. 104113, 2008. ISSN: 0163-5980. doi:
http://doi.acm.org/10.1145/1400097.1400109.
[21] WALTERS, J. P., CHAUDHARY, V., CHA, M., et al. A Comparison of Virtualization Technologies for HPC, Advanced Information Networking and
Applications, International Conference on, v. 0, pp. 861868, 2008. ISSN:
1550-445X. doi: http://doi.ieeecomputersociety.org/10.1109/AINA.2008.
45.
[22] PADALA, P., ZHU, X., WANG, Z., et al. Performance evaluation of virtualization technologies for server consolidation. Relatrio tcnico, 2007.
[23] BARHAM, P., DRAGOVIC, B., FRASER, K., et al. Xen and the art of virtualization. In: SOSP 03: Proceedings of the nineteenth ACM symposium
on Operating systems principles, pp. 164177, New York, NY, USA, 2003.
ACM. ISBN: 1-58113-757-5. doi: http://doi.acm.org/10.1145/945445.
945462.
[24] ADAMS, K., AGESEN, O. A comparison of software and hardware techniques
for x86 virtualization. In: ASPLOS-XII: Proceedings of the 12th international conference on Architectural support for programming languages and
operating systems, pp. 213, New York, NY, USA, 2006. ACM. ISBN:
1-59593-451-0. doi: http://doi.acm.org/10.1145/1168857.1168860.
64
[25] MATTHEWS, J. N., HU, W., HAPUARACHCHI, M., et al. Quantifying the
performance isolation properties of virtualization systems. In: ExpCS
07: Proceedings of the 2007 workshop on Experimental computer science,
p. 6, New York, NY, USA, 2007. ACM. ISBN: 978-1-59593-751-3. doi:
http://doi.acm.org/10.1145/1281700.1281706.
[26] NAGARAJAN, A. B., MUELLER, F., ENGELMANN, C., et al. Proactive
fault tolerance for HPC with Xen virtualization. In: ICS 07: Proceedings
of the 21st annual international conference on Supercomputing, pp. 23
http://doi.acm.org/10.1145/1274971.1274978.
[27] Xen CreditScheduler.
Disponvel em:
xenwiki/CreditScheduler.>.
<http://wiki.xensource.com/
[28] Microsoft, 2010. Disponvel em: <http://www.microsoft.com/>.

[29] Xen, 2010. Disponvel em: <http://www.xen.org/>.
[30] VMware, 2010. Disponvel em: <www.vmware.com>.
[31] Amd, 2010. Disponvel em: <http://www.amd.com/>.
[32] Stress. Disponvel em: <http://weather.ou.edu/~apw/projects/stress/>.
[33] OpenVZ. Disponvel em: <http://wiki.openvz.org/Main_Page>.
[34] The Jail Subsystem. Disponvel em: <http://www.freebsd.org/doc/en_US.
ISO8859-1/books/arch-handbook/jail.html>.
[35] Solaris Containers. Disponvel em: <http://www.freebsd.org/doc/en_US.
ISO8859-1/books/arch-handbook/jail.html>.
[36] Vserver.
Disponvel em:
Linux-VServer.org>.
[37] Virtuozzo.
Disponvel em:
pvc45/>.
<http://linux-vserver.org/Welcome_to_
<http://www.parallels.com/products/
[38] Python Programming Language. Disponvel em: <http://www.python.org/>.

[39] SUGERMAN, J., VENKITACHALAM, G., LIM, B.-H. Virtualizing I/O Devices on VMware Workstations Hosted Virtual Machine Monitor. In:
Proceedings of the General Track: 2002 USENIX Annual Technical Conference, pp. 114, Berkeley, CA, USA, 2001. USENIX Association. ISBN:
1-880446-09-X.
65
[40] BARHAM, P., DRAGOVIC, B., FRASER, K., et al. Xen and the art of virtualization. In: SOSP 03: Proceedings of the nineteenth ACM symposium
on Operating systems principles, pp. 164177, New York, NY, USA, 2003.
ACM. ISBN: 1-58113-757-5. doi: http://doi.acm.org/10.1145/945445.
945462.
[41] OSMAN, S., SUBHRAVETI, D., SU, G., et al. The design and implementation of Zap: a system for migrating computing environments. In: OSDI
02: Proceedings of the 5th symposium on Operating systems design and
implementation, pp. 361376, New York, NY, USA, 2002. ACM. ISBN:
978-1-4503-0111-4. doi: http://doi.acm.org/10.1145/1060289.1060323.
[42] BHADANI, A., CHAUDHARY, S. Performance evaluation of web servers
using central load balancing policy over virtual machines on cloud. In:
COMPUTE 10: Proceedings of the Third Annual ACM Bangalore Conference, pp. 14, New York, NY, USA, 2010. ACM. ISBN: 978-1-45030001-8. doi: http://doi.acm.org/10.1145/1754288.1754304.
[43] SILBERSCHATZ, A., GALVIN, P. B. Operating System Concepts. Boston,
MA, USA, Addison-Wesley Longman Publishing Co., Inc., 1997. ISBN:
0201591138.
[44] HENNESSY, J. L., PATTERSON, D. A. Computer architecture: a quantitative
approach. San Francisco, CA, USA, Morgan Kaufmann Publishers Inc.,
2002. ISBN: 1-55860-596-7.
[45] ROBIN, J. S., IRVINE, C. E. Analysis of the Intel Pentiums ability to support
a secure virtual machine monitor. In: SSYM00: Proceedings of the 9th
conference on USENIX Security Symposium, pp. 1010, Berkeley, CA,
USA, 2000. USENIX Association.
[46] SMITH, J., NAIR, R. Virtual Machines: Versatile Platforms for Systems and
Processes (The Morgan Kaufmann Series in Computer Architecture and
Design). San Francisco, CA, USA, Morgan Kaufmann Publishers Inc.,
2005. ISBN: 1558609105.
[47] MILOJII,
D. S., DOUGLIS, F., PAINDAVEINE, Y., et al. Process migration, ACM Comput. Surv., v. 32, n. 3, pp. 241299, 2000. ISSN:
0360-0300. doi: http://doi.acm.org/10.1145/367701.367728.
[48] BARAK, A. The MOSIX Multicomputer Operating System for High Performance Cluster Computing, Journal of Future Generation Computer
Systems, v. 13, pp. 45, 1998.
66
[49] SMITH, J. E., NAIR, R. The Architecture of Virtual Machines, Computer,

v. 38, n. 5, pp. 3238, 2005. ISSN: 0018-9162. doi: http://dx.doi.org/10.
1109/MC.2005.173.
[50] HENNESSY, J., PATTERSON, D. Computer Architecture - A Quantitative
Approach. Morgan Kaufmann, 2003.
[51] R. J. ADAIR, R. U. BAYLES, L. W. C., CREASY, R. J. A Virtual Machine
System for the 360/40. Relatrio tcnico, IBM Cambridge Scientific Center Report No. G320-2007, 1966.
[52] POPEK, G. J., GOLDBERG, R. P. Formal requirements for virtualizable
third generation architectures, Commun. ACM, v. 17, n. 7, pp. 412421,
1974. ISSN: 0001-0782. doi: http://doi.acm.org/10.1145/361011.361073.
[53] LINDHOLM, T., YELLIN, F. Java Virtual Machine Specification. Boston,
MA, USA, Addison-Wesley Longman Publishing Co., Inc., 1999. ISBN:
0201432943.
[54] CREASY, R. J. The origin of the VM/370 time-sharing system, IBM J. Res.
Dev., v. 25, n. 5, pp. 483490, 1981. ISSN: 0018-8646.
[55] AMAZON. EC2, 2010. Disponvel em: <http://aws.amazon.com/ec2/>.
[56] LINUXCHIX. Kernel Hacking Lesson, 2006. Disponvel em: <http://www.
linuxchix.org/content/courses/>.
67
Apndice A
Migrao de Game Interativo no
OpenVZ
Este apndice, parte de um relatrio sobre experimentos que avaliam a migrao
de mquinas virtuais no OpenVZ. Os resultados obtidos nos experimentos, antecederam e motivaram parte do trabalho realizado na dissertao. Na seo A.1 feita
uma breve introduo sobre o contedo do apndice. A seo A.2, trata a migrao
de MVs da virtualizao por containers. Na seo A.3 explicado como foram realizadas as configuraes de rede, para suportar o primeiro experimento. A seo A.4
apresenta o ambiente experimental. Na seo A.5, apresentado o primeiro conjunto de experimentos. Na seo A.6, tem-se o segundo conjunto de experimentos.
E por fim, na seo A.7, feita a concluso do apndice.
A.1
Introduo
Este relatrio apresenta os resultados dos testes de migrao de uma mquina virtual entre duas mquinas fsicas, bem como a interpretao crtica dos resultados
apresentados. O objetivo dos experimentos identificar os problemas e encontrar
possveis solues para modelo de migrao MV usado na virtualizao por containers.
So realizados experimentos migrando uma MV sem aplicaes, variando a taxa
de transmisso da rede e usando um compactador para compactar os dados transmitidos. E tambm so feitos experimentos com a migrao, em rede Gigabit, de
MVs executando diferentes aplicaes.
68
A.2
Migrao de Conteiners
As MVs de conteiners, so mas complicadas para migrar as MVs que usam migrao
total ou paravirtualizao. Este fato se deve a diferena entre estas duas arquiteturas. Na virtualizao total, basta ver a MV, com todos os seus processos como
parte da memria; neste caso, abstratamente, pode-se dizer que basta copiar toda
a rea de memria da MV, que se deseja migrar, para a mquina destino, e aps a
cpia desta rea de memria a MV passa a executar no destino. Para os containers,
no se pode migrar todo o SO, j que ele compartilhado entre as MVs. Neste caso,
deve-se migrar, juntamente com as pginas dos processos, informaes com as quais
seja possvel recriar as estruturas da MV no kernel da mquina destino. Este fator
dificulta a implementao de live migration com baixo downtime e explica porque os
mecanismos de migrao de MVs virtualizada por containers, so considerados ruins
quando comparado com os mecanismos disponveis para migrar MVs de sistemas de
virtualizao total ou paravirtualizao.
A.2.1
Live migration no Openvz
Atualmente, a migrao do openvz pode ser dividida nas seguintes fases:

1. Suspend - Nesta fase todos os processos da MV so interrompidos, no podendo
mais executar. Isso necessrio para manter a consistncia de memria entre
o fim da execuo da MV na origem e o incio da execuo da MV no destino.
2. Dump - O processo de Dump realizado com a finalidade de coletar as informaes necessrias para recriar a MV no destino. Entre essas informaes
coletadas esto: as estruturas de kernel e as pginas de memria de cada processo. Todas estas informaes so colocadas em um arquivo chamado arquivo
de dump.
3. Copy Dump File. Aps a concluso do arquivo de dump, necessrio enviar
este arquivo para a mquina destino, isso feito neste passo.
4. Undump. Agora que a mquina destino possui as informaes, contidas no
arquivo de dump, necessrias para recriar a mquina virtual, realizado o
Undump. Por meio do arquivo de dump pode-se saber as estruturas de kernel
e outros recursos que devem ser alocados para executar uma MV consistente
com a MV que estava executando na MV fonte.
5. Restart - Este ltimo passo, habilita os processos da MV para serem executados
na mquina de destino.
69
A.3
Migrao em Bandas Limitadas
Para realizao dos experimentos, foi necessrio utilizar uma ferramenta que limitasse taxa de transmisso da rede.
A.3.1
TC
O TC (Traffic Control), em portugus, controle de trfego, atua por meio de algoritmos que manipulam como os dados so transferidos pela interface fsica de rede.
sua responsabilidade por enfileirar, descartar, priorizar, assim como, dar garantia a
um determinado trfego, muitas vezes, sendo necessrio reduzir o trfego das demais
conexes.
O kernel do linux estruturado utilizando os conceitos de Qdiscs, Classes e
Filters, para gerenciar o enfileiramento do trfego de sada das interfaces de rede.
O TC utiliza estes conceitos, abaixo explicados, para controlar o trfego da rede.
Qdiscs As disciplinas de enfileiramento - Queueing Discipline -, tambm chamadas

de algoritmos de escalonamento de pacotes, so utilizadas para controlar os
pacotes, antes de serem transmitidos para a interface de rede, adicionando a capacidade de prover qualidade de servio - Quality of Service -, limite de trfego,
alm de poder priorizar um determinado trfego. Existem vrios algoritmos
que implementam estas funcionalidades de controle dos dados transmitidos,
e cada interface de rede possui um algoritmo principal associado, conhecido
como qdisc root.
Classes As classes so utilizadas para agrupar um ou vrios trfegos, que compartilham um mesmo controle ou limite. Utiliza uma estrutura de rvore, onde
a classe principal chamada de class root, esta, indica o valor mximo a ser
utilizado pela interface, e consequentemente, o valor a ser distribudo entre as
sub-classes. Assim como, a class root tem uma ou vrias classes ligadas a ela,
cada classe que est ligada a classe root, pode possuir uma ou vrias classes,
assim,sucessivamente. Com isto, possvel elaborar complexas estruturas de
controle de trfego.
Filters Os filtros definem as regras e direcionam os pacotes para uma determinada
classe. O algoritmo mais utilizado Universal 32bit comparisons (U32), capaz
de identificar pacotes por IP de origem, IP de destino, porta de origem e porta
de destino.
Segue abaixo o script que foi utilizado para o controle do trfego e a explicao
dos comandos:
70
#Retirando qualquer controle aplicado a interface Eth0:

tc qdisc del dev eth0 root
#Disciplina de enfileiramento aplicada a Eth0 ser HTB:
qdisc add dev eth0 handle 1: root htb default 1000
#Class principal, class root, com limite e garantia de 600000Kbit:
tc class add dev eth0 classid 1:1000 root htb rate 60000Kbit ceil 60000Kbit
#Classe que compartilha o limite da class root, com limite e garantia de $LIMITE:
tc class add dev eth0 classid 1:1001 parent 1:1000 htb rate $LIMITE ceil $LIMITE
#Disciplinas de enfileiramento para atuar sob cada classe, classless qdiscs:
tc qdisc add dev eth0 handle 1001: parent 1:1001 cbq default 1000
#Filtros que direcionam os pacotes para as respectivas classes, filters:
tc filter add dev eth0 parent 1: protocol ip prio 5 u32 flowid 1:1001 match
ip src 10.10.40.0/24
A.4
Os testes coletam os tempos inerentes a migrao MV para diferentes taxas de

transmisso da rede, variando tambm a forma de migrao que pode ser com ou
sem compactao. Usado compactador Bzip2, para compactar o arquivo de dump
(Dump File), migrado entre as mquinas fonte e destino. Os principais tempos
a serem coletados so: tempo de migrao total e o downtime. O resultado dos
teste deve revelar se vantajoso ou no utilizar compactao na migrao de uma
mquina virtual, que migra em uma rede com uma determinada largura de banda.
As mquinas so IBMs com processador Pentium D 3.0GHz, 2048KB de cache,
ligadas por uma rede Gigabit. So usadas duas mquinas com as caractersticas
acima. Os experimentos ocorrem migrando as MVs entre essas duas mquinas.
A.5
Migrao de MV sem Aplicaes
Nesta seo so apresentados os grficos que relacionam os tempos parciais e totais

do processo de migrao, com a largura de banda disponvel para tal migrao.
A.5.1
Tempo Total de Migrao
A figura 1 apresenta o tempo total de migrao, com compactao, identificado pela

letra (Z), ou sem compactao, referido por (NC), para diferentes limitaes de
banda na conexo entre as mquinas fonte (10.10.40.70) e destino (10.10.40.40).
71
1 104
8 103
8144.0
7110.0
6 103
4 103
1422.0
5MB
10MB
30MB
C
N
C
N
C
N
C
N
C
N
1MB
118.0 129.0
50MB
84.0 124.0
164.0 162.0
272.0 248.0
815.0 711.0
1630.0
2 103
70MB
100MB
Figura A.1: Tempo Total de Migrao: tempo(s) X Banda (MB)
A.5.2
Downtime
Na figura A.2 apresentado o downtime ocorrido durante a migrao da MV, com

(Z) ou sem compactao (NC), para diferentes limitaes de banda na conexo das
mquinas fonte(10.10.40.70) e destino(10.10.40.40).
72
Figura A.2: Downtime: tempo(s) X Banda (MB)
A.6
Migrao de MVs Com Aplicaes Reais
Neste experimento, apresentado com detalhes o tempo de dowtime na migrao

de uma MV. Durante todo perodo de migrao, so executadas sobre as MVs, aplicaes com caractersticas distintas. O tempo decorrente do downtime, detalhado
para cada uma delas, com o objetivo de identificar as fases crticas da live migration
no OpenVZ, para estas aplicaes. Aqui, a migrao foi dividida em sete fases, so
elas: First Rsync, Suspend, Dump, Copy Dump File, Sencond Rsync, Undump e
Resume. Destas fases, as ltimas seis so as que mais interessam neste momento,
pois sua soma, informam o tempo de downtime da migrao.
A.6.1
Descrio dos Experimentos
As mquinas virtuais a serem migradas so Debian e executam no Openvz. Para

cada aplicao foram feitas cinco migraes sendo que, os resultados abaixo apresentados se referem a mdia dos resultados obtidos nestas cinco migraes. A seguir
apresentada uma breve descrio de cada uma das aplicaes testadas.
Allocator Programa escrito em C que aloca 500MB de memria e escreve o nmero
1 em cada uma destas posies toda a memoria alocada. Esta aplicao utiliza
muita memria, gerando um arquivo grande de dump.
73
Compiler Compilao do kernel linux 2.6. Compilao do kernel exige muito processamento.
Game Um servidor de jogos, Openarena-server, executado na MV que ser
migrada, simultaneamente duas mquinas fsicas da mesma rede rodam o
OpenArena-client. O OpenArena uma verso livre do Quake-3. Este tipo
de jogo requer muita interatividade, muita troca de mensagens entre o servidor e o cliente, e esta troca de mensagens deve ocorrer em tempo real. Esta
aplicao utiliza muito os recursos de rede.
Http-server A MV roda o servidor http, Apache2. Para simular a utilizao deste
servidor foi executado em uma outra mquina fsica da rede o httperf com
o seguinte comando: httperf server 10.10.40.237 port 80 uri /sites/ rate
150 num-conn 60000 num-call 20. Este comando diz que sero efetuadas
conexes ao servidor 10.10.40.237 uma taxa de 150 conexes por segundo,
cada conexo far 20 chamadas antes de ser fechada. Esta aplicao exige
muito dos recursos de rede.
Mysql-server executado na MV o servidor Mysql e o sql-bench. O comando
sql-bench aqui executado cria e manipula tabelas do banco de dados. Estas
operaoes requerem processamento e memria.
A.6.2
Resultados
A tabela seguinte apresenta todos os dados da migrao coletados para cada aplicao. As ltimas seis linhas representam, sequencialmente, as fases na qual a MV est
parada, ou seja, as fases da migrao onde a aplicao no est sendo executada.
MV size (MB)
Dump size (MB)
1o rsync (s)
Suspend (s)
Dump (s)
Copy Dump File (s)
20 rsync (s)
Undump (s)
Resume (s)
Dowtime (s)
Allocator
Compilator
Game
Http-Server Mysql-Server
545
503
13.44
0.06
2.52
11.10
0.42
1.00
0.14
15,24
711
16
18.84
0.03
0.13
0.51
1.38
0.73
6.10
8.08
682
21
13.82
0.02
0.16
0.76
0.44
0.38
0.34
2.1
272
5.7
7.32
0.59
0.87
0.24
0.84
0.31
1.07
3.92
74
541
55.4
14.62
0.05
0.32
1.34
0.80
1.03
0.83
4.37
A tabela mostra onde esto os gargalos da migrao realizadas pelo OpenVZ.

Enquanto o maior responsvel, pelos downtimes, sofridos pelas aplicaes Allocator
e Game, foi a cpia do arquivo de dump, a maior parte do dowtime, sofrido pelas
aplicaes Compilator e Http-Server, foi por conta do tempo de resume.
A.7
Concluso
Notou-se que os tempos de downtime so muito elevados, muitas vezes inaceitveis

para algumas aplicaes, principalmente as que exigem interao em tempo real.
Observou-se que um dos fatores responsveis por esse tempo, a ineficincia dos
mecanismos de dump, umdump e restart. O outro fator, que destacado quando se
tem um MV que utiliza muita memria fsica, o tempo de migrao do arquivo de
Dump.
75
Apndice B
O Gerenciador de MVs e o
Este apndice expes os detalhes tcnicos do gerenciador de mquinas virtuais. O
apndice, contempla tambm, os passos necessrios para a instalao e configurao
do ambiente experimental desta dissertao. A Seo B.1, apresenta detalhes da
implementao do gerenciador e do algoritmo de balanceamento de mquinas virtuais, usado no gerenciador; a Seo B.2, apresenta os passos que devem seguidos para
instalar o ambiente experimental. Na seo B.3.2, so apontadas a estrutura e as
modificaes realizadas para implementar o gerenciador de mquinas virtuais usado
nos experimentos; por fim, a Seo B.4 apresenta uma dica, fruto da experincia
adquirida com a montagem do ambiente experimental.
76
B.1
Detalhes do Algoritmo de Balanceamento
O Algoritmo de balanceamento implementado uma verso para MVs do algoritmo

Assign-U estendido [7], que foi concebido para balancear o sistema por meio de migraes de MVs. O pseudo algoritmo apresentado na listagem B.1, apresenta o loop
do algoritmo que foi implementado em python. No loop principal, verificado se
existe alguma mquina em desequilbrio, isto , alguma mquina com CPU sobrecarregada em relao as demais. Caso exista tal mquina, calculado qual mquina
de destino que apresenta menor custo marginal. Ento, uma mquina virtual
migrada.
O cdigo do algoritmo de balanceamento implementado foi copiado para a pasta
de plugins do gerenciador.
;MF
r e p r e s e n t a o c o n j u n t o de maquinas v i r t u a i s do
sistema .
; MV_i r e p r e s e n t a o c o n j u n t o de maquinas v i r t u a i s da
maquina i .
; migra ( a , x , y ) migra a mv a da maquina x para a y .
; d e s t i n o ( v ) r e t o r n a a maquina com menor c u s t o m a r g i n a l .
f o r a l l i in MF do :
f o r a l l v in MV_i do :
f o r a l l j in MF, j not i do :
i f not e q u i l i b r i o ( i , j , v ) do :
l < d e s t i n o ( v )
migra ( v , i , l )
exit
end i f ;
end f o r ;
end f o r ;
end f o r ;
Listagem B.1: Algoritmo de Balanceamento Implementado
B.2
Instalao do Gerenciador de Mquinas Virtuais
Vale ressaltar, a dificuldade enfrentada para instalar este framework. Alm de ser
dependente de mdulos que no so oficialmente suportados, o tutorial no est
77
completo e, aparentemente, estes problemas so novidades na comunidade. Os dois

problemas enfrentados na instalao so:
1. Uma das ferramentas usadas pelo Usher, a libxenstat, no oficialmente suportada pelo Xen. Eis a origem dos problemas seguintes. Como a biblioteca
no oficialmente suportada, necessrio compila-la a partir de um cdigo
fonte do Xen.
2. O segundo problema decorrente do primeiro. Aps a compilao e instalao
da libxenstat, ocorre um erro relacionado a incompatibilidade entre a verso
compilada da libxenstat e a verso instalada do Xen. Este erro relatado pela
comunidade do Xen, mas em um contesto diferente.
Os passos aqui descritos um complemento ao tutorial de instalao oficial ??,
desenvolvidos para sobrepor a incompatibilidade com os mdulos do Xen. Como
a linguagem usada na implementao interpretada, o gerenciador desenvolvido
instalado da mesma maneira que o Usher, s alterando os arquivos do gerenciador.
Abaixo, so enumerados os passos para a instalao do Xen, OpenVZ e do Gerenciador.
1. Instalar o CentOS 5.2 conforme sugerido no site do ??.
2. $mkdir /usr/src/redhat
3. $cd /usr/src/redhat/SOURCES
4. $rpm -i http://bits.xensource.com/oss-xen/release/3.2.0/centos-5.1/xen3.2.0-0xs.centos5.src.rpm
5. Edite o arquivo: ../SPECS/xen.spec
Altere a verso: de "Version: 3.2.0"para "Version 3.2.1"
Altere a fonte:
3.2.1.tar.gz"
de "Source0:
xen-3.2.0.tar.gz"para "Source0:
xen-
Descomente a linha: "# /usr/lib/xen/boot/hvmloader"para "/usr/lib/xen/boot/hvmloader"

6. $yum -y install transfig texi2html tetex-latex gtk2-devel libaio-devel gnutls-devel
rpm-build.i386 (dependencies needed for rpmbuild of xen.spec in CentOS)
7. $cd /usr/src/redhat/SPECS ; rpmbuild -ba ./xen.spec
8. $yum install -y libidn-devel SDL-devel curl-devel python-devel ncurses-devel
dev86 openssl-devel glibc-devel gcc gnutls-devel
78
9. Edite o arquivo:/etc/yum.conf
Altere "gpgcheck=0"para "gpgcheck=1".
10. $cd /usr/src/redhat/RPMS/i386; yum -y install xen-3.2.1-0xs.i386.rpm xenlibs-3.2.1-0xs.i386.rpm xen-devel-3.2.1-0xs.i386.rpm
11. Edite o arquivo: /etc/grub.conf
Altere a linha: "kernel"para "kernel /xen.gz-3.2
12. $reboot
13. $wget
http://dag.wieers.com/rpm/packages/mercurial/mercurial-0.9.51.el5.rf.i386.rpm
14. $rpm -ivh mercurial-0.9.5-1.el5.rf.i386.rpm
15. $cd /usr/src/redhat/SOURCES/;tar -zxvf xen-3.2.0.tar.gz
16. $cd xen-3.2.0; make dist
17. $yum install swig
18. $cd tools/xenstat/libxenstat/
19. Edite o arquivo: /etc/grub.conf
Altere a linha: PYTHON_VERSION=2.43 para PYTHON_VERSION=2.4
20. $make
21. $make python-bindings
22. $gcc -O2 -fomit-frame-pointer -m32 -march=i686 -DNDEBUG -std=gnu99
-Wall
-Wstrict-prototypes
-Wno-unused-value
-Wdeclaration-afterstatement -D__XEN_TOOLS__ -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -Isrc -I../../../../tools/libxc
-I../../../../tools/xenstore
-Lsrc
-L../../../../tools/xenstore/
L../../../../tools/libxc/ -I/usr/include/python2.4 -lpython2.4 -shared lxenstat xenstat.o xc_private.o xc_linux.o xc_domain.o xc_misc.o xs.o
xs_lib.o xenstat_linux.o -o ../bindings/swig/python/_xenstat.so ../bindings/swig/python/_xenstat.c
79
Para instalar o o gerenciador e o OpenVZ, pode ser seguido

o procedimento de instalao sugerido em seus sites oficiais, respectivamente,
http://usher.ucsd.edu/trac/wiki/UsherDocumentation
e
http://wiki.openvz.org/Main_Page.
B.3
Modificaes no Gerenciador Base
Foram alteradas diversas funes para que o gerenciador suportasse os experimentos.

Como o Usher ainda est incompleto e ainda no implementado balanceamento
de carga, foi necessrio acrescentar alguns mtodos ao seu cdigo. O objetivo inicial
era de trabalhar com o framework, Usher, como usurio deste, mas logo foi notado
que seria impossvel implementar balanceamento de carga desta forma. Foram ento
acrescentadas mais funcionalidades ao framework, com a finalidade de disponibilizar
aos plugins todos os dados e mtodos necessrios para o balanceamento de carga.
B.3.1
Estrutura do Gerenciador
As modificaes, acima citadas, foram facilitadas pelas modularidade do gerenciador

base, e pelas caractersticas da linguagem de programao utilizada, que interpretada e orientada a objeto. A pasta principal do gerenciador composta dos seguintes
diretrios:
Controle_Central Este diretrio contm arquivos que sero executados somente
no n que servir de controle central. Os arquivos deste diretrio contm
funes que manipulam os dados recebidos dos controles locais.
Controle_Local Este diretrio contm arquivos que sero executados somente
no n que servira de controle local. Os arquivos deste diretrio contm as
funes responsveis por interagir com as tecnologias de virtualizao, a fim
de coletar informaes das mquinas fsicas e virtuais. Sempre que o controle
central determinar, as funes deste arquivo devem pedir para a tecnologia de
virtualizao migrar uma determinada MV.
Plugins Contm a inteligncia do gerenciador. As funes deste diretrio so responsveis por decidir sobre as migraes. O algoritmo descrito na seo anterior, est codificado neste diretrio.
B.3.2
Modificaes
Uma das mais importantes funcionalidades adicionadas, foi a criao de mais um

evento que disparado periodicamente acordando a funo do plugin e passando
80
para esse, o objeto controle. O objeto de controle possui todos os outros objetos
relacionados ao controle central. Assim, a funo tem a sua disposio os mtodos
que coletam os dados necessrios para definir se alguma migrao deve ser efetuada,
caso alguma migrao seja necessria, um dos mtodos implementados no objeto
controle ser capaz de efetuar tal migrao, tambm estar disponvel no objeto de
controle. Foi tambm adicionado ao controle central, um mtodo de coleta peridica,
que solicita a todos os controles locais, os dados sobre a utilizao de CPU de
suas mquinas. Para satisfazer tal requisio, foi implementado um mtodo em
uma funo do diretrio de controle local, para que este repasse ao controle, tais
informaes. Outro mtodo peridico foi acrescentado ao controle. O objetivo deste
outro mtodo atualizar as informaes sobre a carga de CPU e memria das
mquinas virtuais gerenciadas.
Foi verificado uma incoerncia na nomenclatura das MVs. Sempre que o controle
central renomeava uma MV, a renomeao ocorria na tecnologia de virtualizao e
no controle central, mas no ocorria no controle local. Uma forma de correo deste
erro, que foi implementada, no permitir que o controle central renomeie as MVs.
Essa opo foi a escolhida, pois para os objetivos dos experimentos, tais renomeaes
so suprfluas e prejudiciais.
Para que o gerenciador tambm suportasse a tecnologia de virtualizao OpenVZ,
foi necessrio adicionar ao mdulo do gerenciador local, funes com a capacidade
de reconhecer as mquinas virtuais hospedadas em sua mquina, ler na mquina
a carga gerada por cada mquina virtual, executar comando de migrao de uma
determinada mquina virtual, entre outras.
B.4
Dica
Aps a montagem de todo ambiente experimental. Foi verificado um problema que

ocorreu tanto para o Xen quanto para o OpenVZ. Sempre que ocorria uma migrao
de uma MV cuja data da mquina de origem era maior que a data da mquina
de destino, o processamento de qualquer aplicao desta MV ficava extremamente
lendo.
Para resolver foi instalado um servidor de horas (NTP) para que a data de todas
as mquinas envolvidas no experimento fosse sempre a mesma.
81
Lista de Abreviaturas
Algoritmo de Aproximao
Em linhas gerais, Algoritmos de aproximao so algoritmos que no necessariamente

produzem uma soluo tima, mas solues
que esto dentro de um certo fator da soluo
tima., 30
CFQ
Completely Fair Queuing o escalonador de

E/S usado no kernel do Linux. A ideia deste
escalonador limitar a vazo de E/S de um
determinado processo, de acordo com a prioridade pr estabelecida a este processo., 25
Termo ingls que cuja traduo Computao na Nuvem. Computao na Nuvem um
modelo de computao onde o processamento,
o armazenamento e o software, so acessados
remotamente e esto em algum lugar no necessariamente conhecido por quem os usa., 1
Aglomerado de computadores, formado por
um conjunto de computadores interligados que
podem trabalhar junto, podendo ser visto
como um nico computador., 1, 20, 22, 55,
60
Conteiner como pode ser chamada uma mquina virtual da classe de virtualizao no nvel do SO., 17, 26, 27, 57, 68
Em portugus, escalonador por crditos. Este
escalonador atribui crditos as VCPUs, e a
prioridade de execuo destas VCPUs, pode
estar relacionado com a quantidade de crdito
atribuda., 24
Cloud Computing
Cluster
Container
Credit scheduler
82
Downtime
Tempo que uma mquina virtual, em migrao, permanece sem executar. Este tempo geralmente ocorre no momento em que a mquina virtual, que est sendo migrada, deixa
de executar na origem e passa a executar no
destino., 26, 48, 55
E/S
Entrada/Saida, ou em ingls,IO, representa

operaes de entrada ou sada de dados por
meio de um software ou hardware. So exemplos de unidades de sada de um computador:
monitor, caixas de som, impressora, disco rgido., 15
Fair-Share
Fair-share um algoritmo de escalonamento.

A estratgia deste algoritmo que cada processo receba determinada frao do poder de
processamento da CPU., 24
HPC
HPC (High-performance computing) um

termo ingls, aplicado para designar super
computadores ou clusers de alto desempenho.
O uso dos HPC geralmente est relacionado
com processamento de pesquisas cientficas.,
67
IA-32
Termo ingls, Intel Architecture 32-bit, que se

refere ao conjunto de instruo do processador
da Intel., 6, 14
Instruction Set Arquitecture. Interface entre
a ltima camada de software e o hardware., 8
ISA
Job
Termo ingls que descreve uma tarefa ou um

processo que deve ser alocado a uma mquina.,
42
83
Jogos interativos on-line
Neste classe de jogos, a mquina dos jogadores recebem e enviam dados para um servidor
remoto que geralmente est na wan. Jogos
iterativos exigem baixa latncia na troca de
mensagens ponto-a-ponto., 1
Kernel
Termo ingls que significa ncleo, o componente central do SO da maioria dos computadores; ele serve de ponte entre aplicativos e o
processamento real de dados feito a nvel de
hardware, 17, 23, 38
Live Migration
Termo usado para se referir a um tipo de migrao cujo downtime geralmente imperceptvel., 54
Migrao de mquina virtual
A migrao de mquinas virtuais consiste na

migrao de instancias de SOs entre mquinas., 3, 21, 27, 36, 59
Mquina virtual de sistema., 2, 21, 22, 26, 53,
60
Mquinas virtuais de sistema., 2, 21, 22, 26,
53, 60
MV
MVs
OpenVZ
Overhead
Overhead de Migrao
OpenVZ uma tecnologia de virtualizao em

nvel de sistema operacional baseada no sistema operacional e ncleo Linux. O OpenVZ
uma base do Parallels Virtuozzo Containers,
um software proprietrio fornecido pela Parallels. O OpenVZ licenciado sob a verso 2 da
GPL., 23, 45, 60
Overhead a quantidade extra de processamento que determinada tecnologia necessita
para funcionar, 4, 25, 49
Overhead de Migrao a quantidade extra
de processamento que uma determinada tecnologia de virtualizao tem que usar a fim de
migrar uma mquina virtual., 34, 41, 59
84
Reboot
Termo ingls para se referir a reinicializao

do SO., 8
SO
Swap
Sistema operacional., 6, 14, 21, 56

Termo em ingls que significa troca ou paginao. Swap a troca de dados entre o disco
rgido e a memria principal. O swap ocorre
quando no existe mais memria fsica disponvel para um processo. O SO realiza swap pra
tentar estender virtualmente a memria fsica
da mquina.., 51
TC
Traffic Control. Ferramenta usada para realizar controle de trfego da interface de rede.,
70
Tempo decorrido desde o incio at o fim da
migrao da mquina virtual., 20, 27, 36, 61
Tempo total de migrao
Vazo
VCPU
VMware
Em ingls, Througput. Vazo a quantidade

de dados transferidos de um lugar a outro, ou
a quantidade de dados processados em um determinado espao de tempo, pode-se usar o
termo vazo para referir-se a quantidade de
dados transferidos em discos rgidos ou em
uma rede, por exemplo, 2
VCPU (Virtual CPU), so as CPUs virtuais
que so atribudas as mquinas virtuais do
Xen. Cada MV possui um ou mais VCPU.
Existem filas de CPU para executar nas CPUs
reais., 24
VMware um software de virtualizao que
implementa virtualizao total. A empresa
desenvolvedora do VMware, a VMware Inc.,
14, 58
85
WWS
WWS (Writable Working Set) um termo ingls, usado para referenciar as pginas de memrias que foram escritas durante uma das
fase de migrao por pr-cpia, e que devem
ser reenviadas para o destino., 57
Xen
Xen um software livre de virtualizao para

as arquiteturas x86, x86-64, IA-32, IA-64 e
PowerPC. O Xen implementa a tcnica de
paravirtualizao.Xen foi originalmente como
um projeto de pesquisa na Universidade de
Cambridge, liderado por Ian Pratt, fundador
da XenSource, Inc. Em 15 de agosto de 2007,
a XenSource foi adquirida pela Citrix System
Inc., 14, 24, 46, 59
86

1294053276

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

1294053276

Transféré par

Droits d'auteur :

Formats disponibles

COPPE/UFRJ

AVALIAO EXPERIMENTAL DE TCNICAS DE VIRTUALIZAO

Almir Dominicini Fernandes

Dissertao de Mestrado apresentada ao

AVALIAO EXPERIMENTAL DE TCNICAS DE VIRTUALIZAO

DISSERTAO SUBMETIDA AO CORPO DOCENTE DO INSTITUTO

Prof. Claudio Luis de Amorim, Ph.D.

Prof. Felipe Maia Galvo Frana, Ph.D.

Prof. Alexandre Sztajnberg, D.Sc.

RIO DE JANEIRO, RJ BRASIL

Fernandes, Almir Dominicini

Resumo da Dissertao apresentada COPPE/UFRJ como parte dos requisitos

AVALIAO EXPERIMENTAL DE TCNICAS DE VIRTUALIZAO

Almir Dominicini Fernandes

Orientador: Claudio Luis de Amorim

Abstract of Dissertation presented to COPPE/UFRJ as a partial fulfillment of the

EXPERIMENTAL EVALUATION OF VIRTUALIZATION TECHNIQUES BY

Almir Dominicini Fernandes

Advisor: Claudio Luis de Amorim

3 Virtualizao e Balanceamento de Carga

Aplicaes Utilizadas nos Experimentos . . . . . . . . . . . . .

A Migrao de Game Interativo no OpenVZ

A.6.1 Descrio dos Experimentos . . . . . . . . . . . . . . . . . . . 73

Arquitetura de um sistema no virtualizado. . . . . . . . . . . . . .

Estrutura do anel de E/S, o qual usado para transferir dados entre

XM. Tempo de execuo das MVs. . . . . . . . . . .

A.1 Tempo Total de Migrao: tempo(s) X Banda (MB) . . . . . . . . . . 72

Especificao de Software - OpenVZ. . . . . . . . . . . . . . . . . . . 35

das mquinas de um cluster. Os utilizadores de um cluster tm flexibilidade para

O objetivo desta dissertao comparar a eficincia de duas solues de virtualizao

Apesar do crescimento acelerado do uso de virtualizao nos ltimos anos, um

Os computadores modernos esto certamente entre as mquinas mais poderosas

bre a camada de virtualizao, para as interfaces e recursos existentes sob a camada

Figura 2.1: Arquitetura de um sistema

Figura 2.2: Arquitetura de um sistema

Formalmente, pode-se ver o processo de virtualizao como um isomorfismo[52].

Figura 2.3: Mapeamento do sistema virtual em um sistema real.

Antes de apresentar as diferentes tcnicas de virtualizao, instrutivo, falar sobre

Instruction Set Architecture Representa os limites entre o software e o hardhare.

as aes solicitadas pela mquina virtual.

Figura 2.4: Arquitetura das camadas na

Figura 2.5: Viso da processo, na virtualizao de processo.

Mquina Virtual de Sistema

As mquinas virtuais de sistema provm o ambiente completo do sistema no qual

Figura 2.6: Arquitetura das camadas na

Figura 2.7: Viso da mquina virtual

Como o foco do trabalho est em comparar alguns tcnicas de virtualizao

Tcnicas de virtualizao de Sistemas

Existem diferentes tcnicas de virtualizao de sistemas. Antes de escolher uma

A principal caracterstica deste tipo de virtualizao a presena do software de

Figura 2.8: Disposio do Monitor de

Figura 2.9: Disposio do Monitor de

Figura 2.10: Disposio do Monitor de

dispositivo, emula e retorna o que foi pedido pela MV ao dispositivo emulado.

Virtualizao no Nvel do Sistema Operacional

Esta classe de virtualizao, tambm conhecida como virtualizao por Containers,

Figura 2.11: Virtualizao no nvel do SO.

Existem diversas tecnologias pertencente a esta classe de virtualizao, entre eles

Migrao de Mquinas Virtuais

Um benefcio direto da virtualizao de sistemas, poder realizar balanceamento

manter a carga das mquinas fsicas balanceadas, ir realizar migraes de mquinas

Tecnologias de Paravirtualizao e Containers

As duas tecnologias escolhidas para realizao dos testes so o Xen e o OpenVZ. O

Apesar de no ser consenso [19], por no compartilhar o mesmo kernel, o Xen