Professional Documents
Culture Documents
Rio de Janeiro
Setembro de 2010
Examinada por:
iii
iv
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
. . . . . . .
vi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4.4
4.5
4.6
4.7
4.8
4.9
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
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
68
68
69
69
70
70
71
71
71
72
73
vii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
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
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
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,
.
.
.
.
.
.
50
50
51
52
53
54
Lista de Tabelas
4.1
4.2
4.3
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.
1.1
Objetivos e Contribuies
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
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
2.1.2
Classes de Virtualizao
2.1.3
10
2.2
2.2.1
A Virtualizao Clssica
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
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
2.2.2
17
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
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
3.1
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
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
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
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
29
3.3
30
31
3.3.1
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
32
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
4.2
Ambiente Experimental
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
Sistema de arquivo distribudo usado para compartilhar arquivos e diretrios entre sistemas
interconectados, criando assim um diretrio virtual
36
37
baseado no tempo total de migrao das MVs. Para cada experimento, as aplicaes
so iniciadas simultaneamente.
4.3
38
39
40
4.4
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
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:
os . system ( " s i n t e t i c a 1 nthread 2 " ) ;
continue ;
i f a < 50:
os . system ( " s i n t e t i c a 1 nthread 4 " ) ;
continue ;
time . s l e e p ( 3 0 ) ;
continue ;
Listagem 4.2: Sinttica-radomica.py
4.4.3
Kernel
4.5
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
4.6.1
OpenVZ
300
Tempo(s)
250
200
150
100
50
0
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
300
Tempo(s)
250
200
150
100
50
0
4.6.3
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
300
Tempo(s)
250
200
150
100
50
0
Maquinas Virtuais VZ e XM
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
4.7.1
OpenVZ
48
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
49
400
Balanceado - Sem Migracao
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
50
350
300
Tempo(s)
250
200
150
100
50
0
OpenVZ
Xen
Tecnologia de Virtualizacao
Figura 4.12: Experimento2, OpenVz x Xen. Tempo de execuo mdio das MV.
4.8
Experimento3
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
Balanceado - Sem Migracao
Desbalanceado - Sem Migracao
Tempo(s)
400
300
200
100
52
4.8.2
Xen
Tempo(s)
400
300
200
100
53
4.8.3
OpenVZ x Xen
300
Tempo(s)
250
200
150
100
50
0
OpenVZ
Xen
Tecnologia de Virtualizacao
4.9
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
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
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
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
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
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
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
194, New York, NY, USA, 2008. ACM. ISBN: 978-1-60558-158-3. doi:
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
<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
32, New York, NY, USA, 2007. ACM. ISBN: 978-1-59593-768-1. doi:
http://doi.acm.org/10.1145/1274971.1274978.
[27] Xen CreditScheduler.
Disponvel em:
xenwiki/CreditScheduler.>.
<http://wiki.xensource.com/
<http://linux-vserver.org/Welcome_to_
<http://www.parallels.com/products/
[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
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
69
A.3
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.
A.4
Ambiente Experimental
A.5
A.5.1
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
A.5.2
Downtime
72
A.6
A.6.1
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.7
Concluso
75
Apndice B
O Gerenciador de MVs e o
Ambiente Experimental
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
B.2
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
de "Source0:
xen-3.2.0.tar.gz"para "Source0:
xen-
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
B.3
B.3.1
Estrutura do Gerenciador
B.3.2
Modificaes
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
81
Lista de Abreviaturas
Algoritmo de Aproximao
CFQ
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
Fair-Share
HPC
IA-32
ISA
Job
83
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
MV
MVs
OpenVZ
Overhead
Overhead de Migrao
84
Reboot
SO
Swap
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
Vazo
VCPU
VMware
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
86