4.2 Implementa¸c˜ ao do Sistema Proposto
4.2.1 Painel de controle
Foi desenvolvido, um painel de controle que permite uma f´acil visualiza¸c˜ao do uso de recursos das m´aquinas f´ısicas e virtuais em tempo real. O painel consiste em
gr´aficos mostrando a utiliza¸c˜ao de CPU, mem´oria e rede. Este painel foi desenvolvido utilizando a biblioteca Matplotlib. A Figura 4.3 mostra o painel de controle em
funcionamento com algumas m´aquinas virtuais de teste, utilizando duas m´aquinas da plataforma FITS.
Cap´ıtulo 5
Resultados
Para validar o funcionamento do sistema, foi desenvolvido um cen´ario de teste
que permite avaliar o comportamento e a eficiˆencia do algoritmo em diferentes casos de sobrecarga. Atrav´es deste cen´ario de teste tamb´em foi poss´ıvel observar o com-
portamento do Dom´ınio-0 durante as migra¸c˜oes e atividades de rede. A carga de CPU foi simulada utilizando o programa Stress [36], de licen¸ca livre, que permite
gerar cargas de trabalho de forma controlada.
5.1
Cen´ario de teste
Conforme especificado na Se¸c˜ao 4.1, as m´aquinas monitoradas devem possuir con-
figura¸c˜oes homogˆeneas de hardware. Dentre os computadores dispon´ıveis na plata- forma de teste FITS, foram selecionadas duas m´aquinas equipadas com processador
Intel I7 de 3.2 GHz e 16 GB de mem´oria RAM. O sistema operacional instalado nas m´aquinas ´e o Debian Weezy e o hipervisor Xen utilizado ´e a vers˜ao 4.1.3. As
imagens dos discos e os arquivos de configura¸c˜ao encontram-se em um n´o central da arquitetura do FITS e s˜ao acess´ıveis por qualquer m´aquina do testbed. O sis-
tema de gerˆencia foi instalado em uma m´aquina fora da plataforma FITS, mas com configura¸c˜oes de hardware idˆenticas `as m´aquinas monitoradas e dentro da mesma
sub-rede IP. A escolha de colocar o sistema inicialmente fora da plataforma de teste foi feita com o intuito de n˜ao interferir nos experimentos sendo realizados no FITS
Tabela 5.1: Configura¸c˜oes das m´aquinas virtuais. Nome vCPUs Mem´oria (MB)
cpu1 8 512 cpu2 8 512 cpu3 8 512 memory1 1 8192 memory2 1 2048 memory3 1 4096
Para criar diferentes situa¸c˜oes de sobrecarga foram utilizadas m´aquinas virtuais
com diferentes configura¸c˜oes, de modo a consumir cada um dos recursos monito- rados. A lista dos dom´ınios virtuais utilizados e as suas respectivas configura¸c˜oes
podem ser vistas na Tabela 5.1, onde os nomes dos dom´ınios indicam qual recurso ´e mais utilizado por eles.
O cen´ario de teste ´e dividido nas seguintes etapas:
1. cria¸c˜ao das m´aquinas memory1, memory2 na m´aquina f´ısica leblon.gta.ufrj.br ;
2. cria¸c˜ao da m´aquina memory3 na m´aquina leblon.gta.ufrj.br ;
3. cria¸c˜ao das m´aquinas cpu1 e cpu2 na m´aquina f´ısica paodeacucar.gta.ufrj.br e
da m´aquina cpu3 na leblon.gta.ufrj.br ;
4. destrui¸c˜ao da m´aquina memory1 na m´aquina f´ısica leblon.gta.ufrj.br e da
m´aquina memory2 na paodeacucar.gta.ufrj.br ;
5. gera¸c˜ao de carga em 5 vCPUs da m´aquina cpu2 e em 2 vCPUs do dom´ınio
cpu3.
A figura 5.1 mostra a configura¸c˜ao das m´aquinas leblon.gta.ufrj.br e paodeacu-
car.gta.ufrj.br em cada uma das etapas do cen´ario de testes.
A Figura 5.2 mostra o uso de mem´oria e processador pelas duas m´aquinas f´ısicas
monitoradas, sem nenhuma m´aquina virtual em execu¸c˜ao al´em do Dom´ınio-0. Atrav´es desta figura, ´e poss´ıvel notar que o uso do processador pelo dom´ınio de controle ´e
Figura 5.1: Configura¸c˜oes das m´aquinas monitoradas em cada uma das etapas do
cen´ario de testes.
muito pequeno e a sua mem´oria alocada est´a na ordem de 12% da quantidade de
mem´oria total. As linhas vermelhas representam os limiares de seguran¸ca utilizados.
O primeiro item do cen´ario de testes visa criar um conjunto inicial de m´aquinas virtuais na m´aquina f´ısica leblon.gta.ufrj.br. A Figura 5.3(a) mostra a utiliza¸c˜ao de
CPU durante esta etapa, na qual ´e poss´ıvel notar o consumo de CPU do Dom´ınio- 0 para realizar a cria¸c˜ao das duas m´aquinas virtuais no intervalo entre 20 e 60
segundos. Tamb´em ´e poss´ıvel observar, na Figura 5.3(b) o aumento da quantidade de mem´oria alocada da m´aquina f´ısica devido a cria¸c˜ao das m´aquinas virtuais.
O item 2 do cen´ario de testes cria a m´aquina memory3 na m´aquina leblon.ufrj.br e est´a ilustrado na Figura 5.4. ´E poss´ıvel notar na Figura 5.4(b) que a quantidade
de mem´oria alocada atinge 100% na amostra 83, obrigando o Dom´ınio-0 a realizar o bal˜ao de mem´oria e ceder uma parte da sua mem´oria ao dom´ınio rec´em criado.
Como o limiar de seguran¸ca de mem´oria foi ultrapassado, o Orquestrador de mi- gra¸c˜ao foi acionado (Figura 5.5). Conforme o esperado, a m´aquina escolhida para
a migra¸c˜ao foi a memory2 que possui menor quantidade de mem´oria dentre as 3 m´aquinas virtuais em execu¸c˜ao e, portanto, tem o menor custo de migra¸c˜ao. A Fi-
gura 5.6 representa as duas m´aquinas f´ısicas ap´os a migra¸c˜ao da m´aquina memory2. Atrav´es da Figura 5.6(b), ´e poss´ıvel observar que a migra¸c˜ao resolveu a sobrecarga de
mem´oria da m´aquina leblon.gta.ufrj.br e alocou corretamente o dom´ınio memory2 na m´aquina paodeacucar.gta.ufrj.br (Figura 5.6(d)). Tamb´em ´e poss´ıvel observar
nas Figuras 5.6(a) e 5.6(c) o consumo de processamento do Dom´ınio-0 das duas m´aquinas f´ısicas para realizar a migra¸c˜ao.
No terceiro item do cen´ario de testes s˜ao criadas as m´aquinas virtuais cpu1, cpu2 e cpu3. Essa etapa ´e ilustrada na Figura 5.7. Conforme pode ser observado na
Figura 5.7(b), a cria¸c˜ao da m´aquina cpu3 gera uma nova sobrecarga de mem´oria em leblon.gta.ufrj.br. De acordo com o algoritmo de decis˜ao, a m´aquina cpu3 ´e selecio-
nada para a migra¸c˜ao, pois apresenta a menor quantidade de mem´oria alocada. O resultado da migra¸c˜ao pode ser observado na Figura 5.8.
Comparando a migra¸c˜ao da m´aquina cpu3 (Figura 5.8(a)) e da m´aquina me-
mory2 (Figura 5.6(a)), verifica-se que a dura¸c˜ao da migra¸c˜ao da cpu3 ´e menor que a dura¸c˜ao da migra¸c˜ao da m´aquina memory2. Isso se deve `a diferen¸ca da quanti-
dade de mem´oria alocada as duas m´aquinas: a cpu3 possui 512 MB de mem´oria, enquanto a memory2 possui 2048 MB. Esta constata¸c˜ao valida o crit´erio de decis˜ao
adotado neste projeto que opta por migrar m´aquinas com menor mem´oria alocada, reduzindo o tempo de migra¸c˜ao e o uso de CPU do Dom´ınio-0.
Observando o uso do processador pelo Dom´ınio-0 da m´aquina leblon.gta.ufrj.br na Figura 5.8(a) ´e poss´ıvel verificar que a migra¸c˜ao causou um consumo de CPU
durante um intervalo de aproximadamente 60 segundos nessa m´aquina, enquanto na m´aquina paodeacucar.gta.ufrj.br (Figura 5.8(c)) a utiliza¸c˜ao de CPU pelo Dom´ınio-0
foi de aproximadamente 20 segundos. ´E poss´ıvel, ent˜ao, verificar que, para realizar a migra¸c˜ao de uma m´aquina virtual, o Dom´ınio-0 da m´aquina de origem utiliza o
processador durante um intervalo de tempo mais longo que o Dom´ınio-0 da m´aquina f´ısica de destino, ou seja, o overhead causado pela migra¸c˜ao ´e maior na origem do
Na etapa 4, as m´aquinas memory1 e memory2 das m´aquinas leblon.gta.ufrj.br e paodeacucar.gta.ufrj.br s˜ao desligadas (Figura 5.9), permitindo verificar o comporta-
mento do Dom´ınio-0 durante o desligamento de dom´ınios virtuais. Nota-se que esse processo n˜ao causa um grande consumo de processador, apenas um pico de curta
dura¸c˜ao, como pode ser observado no instante 50s da Figura 5.9(a) e no instante 60s da Figura 5.9(c).
No item 5, ´e simulada uma carga de trabalho, atrav´es do programa Stress, nas m´aquinas cpu1, cpu2 e cpu3, como mostra a Figura 5.10(a). Nesta mesma figura, ´e
poss´ıvel observar que a utiliza¸c˜ao do processador da m´aquina paodeacucar.gta.ufrj.br ultrapassa o limiar de seguran¸ca, acionando o algoritmo de migra¸c˜ao. De acordo
com o algoritmo de decis˜ao, a m´aquina selecionada para a migra¸c˜ao ´e a cpu2, pois ´e a que apresenta a maior rela¸c˜ao processamentomem´oria . O resultado da migra¸c˜ao pode ser
visto na figura 5.11, onde ´e poss´ıvel verificar a diminui¸c˜ao da mem´oria alocada da m´aquina paodeacucar.gta.ufrj.br e um aumento na quantidade de mem´oria alocada
na m´aquina leblon.gta.ufrj.br.
Os resultados obtidos nos testes demonstram que a ferramenta proposta ´e capaz de realizar o monitoramento de CPU, mem´oria e rede, detectar a escassez de recursos
e distribuir as cargas de trabalho entre as m´aquinas f´ısicas monitoradas. Tamb´em foi poss´ıvel observar o comportamento do Dom´ınio-0 em diferentes situa¸c˜oes, como
cria¸c˜ao, migra¸c˜ao e desligamento de m´aquinas virtuais. O sistema desenvolvido cumpre, ent˜ao, todos os objetivos descritos no Cap´ıtulo 4.
(a) Uso do processador da m´aquina le- blon.gta.ufrj.br.
(b) Mem´oria alocada da m´aquina le- blon.gta.ufrj.br.
(c) Uso do processador da m´aquina paodea- cucar.gta.ufrj.br.
(d) Mem´oria alocada da m´aquina paodeacu- car.gta.ufrj.br.
(a) Uso de processador da m´aquina le- blon.gta.ufrj.br.
(b) Mem´oria alocada da m´aquina le- blon.gta.ufrj.br.
Figura 5.3: Configura¸c˜ao da m´aquina leblon.gta.ufrj.br ap´os a cria¸c˜ao das m´aquinas
virtuais memory1 e memory2.
(a) Uso de processador da m´aquina le- blon.gta.ufrj.br.
(b) Mem´oria alocada da m´aquina le- blon.gta.ufrj.br.
Figura 5.4: Configura¸c˜ao da m´aquina leblon.gta.ufrj.br ap´os a cria¸c˜ao da m´aquina virtual memory3.
(a) Uso do processador da m´aquina le- blon.gta.ufrj.br.
(b) Mem´oria alocada da m´aquina le- blon.gta.ufrj.br.
(c) Uso do processador da m´aquina paodea- cucar.gta.ufrj.br.
(d) Mem´oria alocada da m´aquina paodeacu- car.gta.ufrj.br.
(a) Uso do processador da m´aquina le- blon.gta.ufrj.br.
(b) Mem´oria alocada da m´aquina le- blon.gta.ufrj.br.
(c) Uso do processador da m´aquina paodea- cucar.gta.ufrj.br.
(d) Mem´oria alocada da m´aquina paodeacu- car.gta.ufrj.br.
(a) Uso do processador da m´aquina le- blon.gta.ufrj.br.
(b) Mem´oria alocada da m´aquina le- blon.gta.ufrj.br.
(c) Uso do processador da m´aquina paodea- cucar.gta.ufrj.br.
(d) Mem´oria alocada da m´aquina paodeacu- car.gta.ufrj.br.
(a) Uso do processador da m´aquina le- blon.gta.ufrj.br.
(b) Mem´oria alocada da m´aquina le- blon.gta.ufrj.br.
(c) Uso do processador da m´aquina paodea- cucar.gta.ufrj.br.
(d) Mem´oria alocada da m´aquina paodeacu- car.gta.ufrj.br.
(a) Uso do processador da m´aquina le- blon.gta.ufrj.br.
(b) Mem´oria alocada da m´aquina le- blon.gta.ufrj.br.
(c) Uso do processador da m´aquina paodea- cucar.gta.ufrj.br.
(d) Mem´oria alocada da m´aquina paodeacu- car.gta.ufrj.br.
(a) Uso do processador da m´aquina le- blon.gta.ufrj.br.
(b) Mem´oria alocada da m´aquina le- blon.gta.ufrj.br.
(c) Uso do processador da m´aquina paodea- cucar.gta.ufrj.br.
(d) Mem´oria alocada da m´aquina paodeacu- car.gta.ufrj.br.
Figura 5.10: Carga de trabalho nas m´aquinas cpu1, cpu2 e cpu3 gerada com o
(a) Uso do processador da m´aquina le- blon.gta.ufrj.br.
(b) Mem´oria alocada da m´aquina le- blon.gta.ufrj.br.
(c) Uso do processador da m´aquina paodea- cucar.gta.ufrj.br.
(d) Mem´oria alocada da m´aquina paodeacu- car.gta.ufrj.br.
Cap´ıtulo 6
Conclus˜ao
A virtualiza¸c˜ao de computadores ´e uma tecnologia que se tornou popular nos
´
ultimos anos e tem sido largamente utilizada nos novos data centers, pois permite a consolida¸c˜ao de servidores e aplica¸c˜oes, al´em de proporcionar novos modelos de
neg´ocio, como servi¸cos de computa¸c˜ao em nuvem. A virtualiza¸c˜ao tamb´em tem sido empregada em rede de computadores e ´e uma das tecnologias de base nas propostas
de “Internet do Futuro” que utilizam a abordagem pluralista.
Apesar de trazer muitas vantagens, a virtualiza¸c˜ao tamb´em tr´as novos desafios,
dentre os quais est˜ao a gerˆencia dos recursos f´ısicos e o aprovisionamento adequado destes recursos `as m´aquinas virtuais. Dado que as m´aquinas virtuais executam
diferentes aplica¸c˜oes e possuem perfis diferentes de utiliza¸c˜ao de recursos que podem variar ao longo do tempo, ´e necess´ario que a gerˆencia das m´aquinas virtuais seja
realizada considerando a elasticidade na demanda e assegure o cumprimento dos acordos de n´ıveis de servi¸co (SLA) das aplica¸c˜oes em execu¸c˜ao nas m´aquinas virtuais.
O trabalho desenvolvido prop˜oe um sistema de gerˆencia automatizado de recursos para ambientes virtualizados, no qual ´e poss´ıvel realizar o monitoramento, a detec¸c˜ao
de sobrecargas e a distribui¸c˜ao de cargas de trabalho. O sistema ´e capaz de monitorar a utiliza¸c˜ao do processador, a quantidade de mem´oria alocada e o tr´afego de rede de
um conjunto de computadores, detectando escassez desses recursos e distribuindo cargas, de forma a evitar perda de desempenho nas aplica¸c˜oes em execu¸c˜ao. O
mecanismo de distribui¸c˜ao de cargas foi baseado na t´ecnica de migra¸c˜ao ao vivo fornecida pelo Xen, que permite a migra¸c˜ao de m´aquinas virtuais entre n´os f´ısicos,
sem a interrup¸c˜ao dos servi¸cos em execu¸c˜ao.
O sistema foi testado utilizando m´aquinas do testbed FITS, permitindo a va-
lida¸c˜ao da proposta. Foi elaborado um cen´ario de teste que permite testar o sistema nos diferentes cen´arios de sobrecarga e os resultados obtidos atrav´es dele mostram
que o sistema implementado ´e capaz de atender os objetivos propostos. Tamb´em foi implementado um painel de controle que permite a visualiza¸c˜ao do uso dos recursos
computacionais em tempo real.
6.1
Trabalhos Futuros
A implementa¸c˜ao realizada no escopo deste projeto ´e um prot´otipo do sistema
proposto. Como trabalho futuro, pretende-se integrar os mecanismos de monitora-
mento e distribui¸c˜ao de carga nas m´aquinas do FITS e disponibiliz´a-los como servi¸co na interface Web da plataforma de teste. Para isso, pretende-se alterar a arquitetura
do sistema, de forma que os perfis de uso sejam gerados de modo distribu´ıdo em cada uma das m´aquinas f´ısicas monitoradas. Esta abordagem reduz o trabalho a ser
realizado no n´o f´ısico de gerˆencia e torna as medidas mais confi´aveis e precisas em ambientes com uma grande quantidade de computadores e dom´ınios virtuais, como
´e o caso do FITS.
A ferramenta de monitoramento desenvolvida poder´a auxiliar na valida¸c˜ao de
propostas para Internet do Futuro testadas no FITS, j´a que permite a visualiza¸c˜ao em tempo real do comportamento das m´aquinas presentes na plataforma de teste.
A parte de monitoramento tamb´em pode ser utilizada como base para trabalhos futuros ligados a detec¸c˜ao de intrus˜ao baseados em anomalia. O monitoramento das
m´aquinas e a distribui¸c˜ao de cargas ser˜ao implementados no FITS como servi¸cos diferentes, pois, apesar de ser interessante monitorar o uso dos recursos de todas as
m´aquinas virtuais, nem todas as m´aquinas podem ser migradas, j´a que a localidade fixa da m´aquina virtual pode ser indispens´avel em determinados testes de rede de
Referˆencias Bibliogr´aficas
[1] WEN, Y., ZHAO, J., ZHAO, G., et al., “A Survey of Virtualization Technolo-
gies Focusing on Untrusted Code Execution.” In: You, I., Barolli, L., Gentile, A., et al. (eds.), IMIS, pp. 378–383, 2012.
[2] FIGUEIREDO, R. J. O., DINDA, P. A., FORTES, J. A. B., “Guest Editors’
Introduction: Resource Virtualization Renaissance.”, IEEE Computer, v. 38, n. 5, pp. 28–31, 2005.
[3] MEISNER, D., GOLD, B. T., WENISCH, T. F., “PowerNap: eliminating server idle power.” In: Soffa, M. L., Irwin, M. J. (eds.), ASPLOS, pp. 205–216, 2009.
[4] BOBROFF, N., KOCHUT, A., BEATY, K., “Dynamic Placement of Virtual Machines for Managing SLA Violations.” In: Integrated Network Management,
pp. 119–128, 2007.
[5] MATTOS, D. M. F., MAURICIO, L. H., CARDOSO, L. P., et al., “Uma
Rede de Testes Interuniversit´aria com T´ecnicas de Virtualiza¸cao H´ıbridas”. In: Simp´osio Brasileiro de Redes de Computadores e Sistemas Distribu´ıdos, 2012.
[6] WOOD, T., CHERKASOVA, L., OZONAT, K., et al., “Profiling and mo- deling resource usage of virtualized applications”. In: Proceedings of the 9th
ACM/IFIP/USENIX International Conference on Middleware, Middleware ’08, pp. 366–387, 2008.
[7] “The road map from virtualization to cloud computing. Aces- sado em: Maio 2013. Dispon´ıvel em: http://easystreet.com/wp-
content/uploads/2012/12/Gartner The-Road-Map-From-Virtualization-to- Cloud-Computing-G00210845 English.pdf”.
[8] TAN, L., CHAN, E. M., FARIVAR, R., et al., “iKernel: Isolating Buggy and Malicious Device Drivers Using Hardware Virtualization Support”. In: Procee-
dings of the Third IEEE International Symposium on Dependable, Autonomic and Secure Computing, DASC ’07, pp. 134–144, 2007.
[9] BARHAM, P., DRAGOVIC, B., FRASER, K., et al., “Xen and the art of virtualization”. In: Proceedings of the nineteenth ACM symposium on Operating
systems principles, SOSP ’03, pp. 164–177, 2003.
[10] XEN.ORG, “How Does Xen Work? Acesso em: Maio de 2013. Dispon´ıvel em
http://www-archive.xenproject.org/files/Marketing/HowDoesXenWork.pdf”.
[11] GOVINDAN, S., NATH, A. R., DAS, A., et al., “Xen and co.: communication-
aware CPU scheduling for consolidated xen-based hosting platforms”. In: Pro- ceedings of the 3rd international conference on Virtual execution environments,
VEE ’07, pp. 126–136, New York, NY, USA, 2007.
[12] CHERKASOVA, L., GUPTA, D., VAHDAT, A., “Comparison of the three CPU
schedulers in Xen.”, SIGMETRICS Performance Evaluation Review, v. 35, n. 2, pp. 42–51, 2007.
[13] “Credit Scheduler. Acesso em: Junho de 2013. Dispon´ıvel em: http://wiki.xensource.com/xenwiki/CreditScheduler.”
[14] “XenMemoryUsage. Acesso em: Julho de 2013. Dispon´ıvel em: http://docs.vmd.citrix.com/XenServer/4.0.1/installation/apd.html”.
[15] J.H. SCHOPP, K. F., SILBERMANN, M., “Resizing Memory with Balloons
and Hotplug”, In Proceedings of the Linux Symposium, , 2006.
[16] XEN.ORG, “Xen Best Practices. Acesso em: Maio de 2013. Dispon´ıvel em:
http://wiki.xen.org/wiki/Xen_Best_Practices”, Janeiro 2013.
[17] EGI, N., GREENHALGH, A., HANDLEY, M., et al., “Evaluating Xen for
Router Virtualization.” In: ICCCN, pp. 1256–1261, 2007.
[18] MATTOS, D. M. F., FERRAZ, L. H. G., COSTA, L. H. M. K., et al., “Evalua-
of the 3rd International Conference on Information and Communication Sys- tems, ICICS ’12, pp. 4:1–4:7, 2012.
[19] LEE, M., KRISHNAKUMAR, A. S., KRISHNAN, P., et al., “XenTune: Detec- ting Xen Scheduling Bottlenecks for Media Applications.” In: GLOBECOM,
pp. 1–6, 2010.
[20] CLARK, C., FRASER, K., HAND, S., et al., “Live migration of virtual ma-
chines”. In: Proceedings of the 2nd conference on Symposium on Networked Systems Design & Implementation - Volume 2, NSDI’05, pp. 273–286, 2005.
[21] MOREIRA, M. D. D., FERNANDES, N. C., COSTA, L. H. M. K., et al., “In- ternet do Futuro: Um Novo Horizonte”. In: ”Minicursos do Simp´osio Brasileiro
de Redes de Computadores - SBRC, 2009.
[22] JACOBSON, V., SMETTERS, D. K., THORNTON, J. D., et al., “Networ-
king named content”. In: Proceedings of the 5th international conference on Emerging networking experiments and technologies, pp. 1–12, 2009.
[23] FEAMSTER, N., GAO, L., REXFORD, J., “How to lease the internet in your spare time”, SIGCOMM Comput. Commun. Rev., v. 37, n. 1, pp. 61–64, Jan.
2007.
[24] MCKEOWN, N., ANDERSON, T., BALAKRISHNAN, H., et al., “OpenFlow:
enabling innovation in campus networks”, SIGCOMM Comput. Commun. Rev., v. 38, n. 2, pp. 69–74, Mar. 2008.
[25] “libvirt - The virtualization API. Acesso em: Mar¸co 2013. Dispon´ıvel em:
http://libvirt.org/index.html.”
[26] GMACH, D., ROLIA, J., CHERKASOVA, L., et al., “Capacity Management
and Demand Prediction for Next Generation Data Centers.” In: ICWS, pp. 43–50, 2007.
[27] WOOD, T., SHENOY, P. J., VENKATARAMANI, A., et al., “Sandpiper: Black-box and gray-box resource management for virtual machines.”, Com-
[28] CARVALHO, H. E. T., DUARTE, O. C. M. B., “VOLTAIC: volume optimiza- tion layer to assign cloud resources”. In: Proceedings of the 3rd International
Conference on Information and Communication Systems, ICICS ’12, pp. 3:1– 3:7, 2012.
[29] KHANNA, G., BEATY, K., KAR, G., et al., “Application Performance Ma- nagement in Virtualized Server Environments”. In: Network Operations and
Management Symposium, 2006. NOMS 2006. 10th IEEE/IFIP, pp. 373–381, 2006.
[30] ARZUAGA, E., KAELI, D. R., “Quantifying load imbalance on virtualized
enterprise servers”. In: Proceedings of the first joint WOSP/SIPEW internati- onal conference on Performance engineering, WOSP/SIPEW ’10, pp. 235–242,
2010.
[31] SONNEK, J., GREENSKY, J., REUTIMAN, R., et al., “Starling: Minimizing
Communication Overhead in Virtualized Computing Platforms Using Decentra- lized Affinity-Aware Migration”. In: Proceedings of the 2010 39th International