dados, representando a fase <strong>de</strong> pré-cópia utilizada pelo mecanismo<strong>de</strong> live migration. Nesta fase ocorre uma transferênciainicial <strong>de</strong> todos os dados armazenados na memóriaprincipal, para permitir que posteriormente somente os dadosalterados sejam transferidos. O tempo total <strong>de</strong> execuçãoda fase <strong>de</strong> pré-cópia foi <strong>de</strong> aproximadamente 11,7 segundos(para facilitar a visualização das outras iterações, o gráficona figura 4 teve o eixo das abscissas <strong>de</strong>slocado, iniciandoem 11,4 segundos ao invés <strong>de</strong> iniciar no instante zero). Duranteeste processo é possível observar a interferência da reserva<strong>de</strong> recursos sobre os <strong>de</strong>mais processos em execução,<strong>de</strong>monstrada pela inexistência <strong>de</strong> dados alterados (representadosem preto) no intervalo <strong>de</strong> tempo relativo a essaiteração.As iterações executadas buscam atingir uma condiçãoon<strong>de</strong> a migração ocorra <strong>de</strong> forma rápida, transferindo-seo menor número possível <strong>de</strong> dados <strong>de</strong> modo a provocarum tempo mínimo <strong>de</strong> indisponibilida<strong>de</strong> do sistema. Namigração representada pela figura 4 a condição mínima nãofoi encontrada, ou seja, a migração ocorreu após a execuçãodo número limite <strong>de</strong> iterações.Embora a i<strong>de</strong>ntificação da melhor condição <strong>de</strong> migraçãonão tenha ocorrido neste caso, o processo <strong>de</strong> migração damáquina virtual durou aproximadamente 12,9 segundos, emum tempo total <strong>de</strong> execução <strong>de</strong> 4 minutos e 39 segundos,representando aproximadamente 4,6% do tempo total <strong>de</strong>execução.No segundo caso consi<strong>de</strong>rado, partiu-se do mesmoambiente <strong>de</strong> experimentação <strong>de</strong>scrito na seção 5.1 parainvestigar-se a migração <strong>de</strong> uma máquina virtual executandoa aplicação <strong>de</strong> computação distribuída (MeteoP2P).Neste caso, migrou-se a máquina virtual que processava osdados para um terceiro computador. A figura 5 apresenta aevolução do processo <strong>de</strong> migração ocorrido neste caso.Na figura 5 observa-se as trinta iterações ocorridas paraefetuar a migração da máquina virtual. Nesta migraçãoo tempo <strong>de</strong> execução da iteração inicial correspon<strong>de</strong>nte àfase <strong>de</strong> pré-cópia foi <strong>de</strong> aproximadamente 22,57 segundos,representando 81% em um tempo total <strong>de</strong> migração<strong>de</strong> 27,77 segundos. Este tempo inicial <strong>de</strong> transferência éproporcional ao gran<strong>de</strong> volume <strong>de</strong> dados manipulados pelaaplicação MeteoP2P (o gráfico representado pela figura 5também teve o eixo das abscissas <strong>de</strong>slocado para facilitar avisualização).Assim como no primeiro caso avaliado, a i<strong>de</strong>ntificaçãoda melhor condição para migração não ocorreu, ocasionandoa suspensão da máquina virtual e a sua ativação nocomputador <strong>de</strong> <strong>de</strong>stino após atingir-se o número máximo<strong>de</strong> iterações. Nesta análise, o tempo total <strong>de</strong> execução obtidofoi <strong>de</strong> aproximadamente 38 minutos e 40 segundos e otempo total <strong>de</strong> migração foi <strong>de</strong> 27,77 segundos, representandoaproximadamente 1,2% do tempo total <strong>de</strong> execução.As avaliações efetuadas utilizando-se o mecanismo <strong>de</strong>Figura 5. Migração <strong>de</strong> uma máquina virtualexecutando MeteoP2Plive migration em aplicações características <strong>de</strong> ambientes <strong>de</strong>computação <strong>de</strong> alto <strong>de</strong>sempenho indicam que a sobrecargaimposta pelo mecanismo <strong>de</strong> migração não compromete significativamenteo <strong>de</strong>sempenho final da aplicação, viabilizandoa utilização <strong>de</strong>ste mecanismo para controle dinâmico<strong>de</strong> recursos.6. ConclusãoNeste trabalho investigou-se o impacto da utilização <strong>de</strong>ambientes virtualizados em plataformas <strong>de</strong> alto <strong>de</strong>sempenho.O principal critério consi<strong>de</strong>rado nesta análise foi aintrusivida<strong>de</strong> do monitor <strong>de</strong> máquinas virtuais Xen sobreaplicações <strong>de</strong> computação paralela e distribuída, inclusiveem casos <strong>de</strong> migração <strong>de</strong> uma máquina virtual para outrohospe<strong>de</strong>iro físico.Os resultados obtidos mostraram que a sobrecarga envolvidano uso <strong>de</strong> Xen foi relativamente baixa nos diferentescasos consi<strong>de</strong>rados. Tais resultados indicam que Xen po<strong>de</strong>constituir uma alternativa viável <strong>de</strong> virtualização em plataformas<strong>de</strong> processamento <strong>de</strong> alto <strong>de</strong>sempenho.Referências[1] Project JXTA. Disponível em: http://www.jxta.org/. Acessoem: julho 2006.[2] TOP500 supercomputer sites. Disponível em:http://www.top500.org/. Acesso em: julho 2006.[3] P. Barham, B. Dragovic, K. Fraser, S. Hand, T. Harris,A. Ho, R. Neugebauer, I. Pratt, and A. Warfield. Xen andthe art of virtualization. In Proc. 19th ACM Symposium onOperating Systems Principles (SOSP ’03), pages 164–177,Bolton Landing, USA, Oct. 2003. ACM.
[4] S. Childs, B. Coghlan, D. O’Callaghan, G. Quigley, andJ. Walsh. A single-computer grid gateway using virtual machines.In Proc.19th International Conference on AdvancedInformation Networking and Applications (AINA’05). IEEEComputer Society, 2005.[5] C. Clark, K. Fraser, S. Hand, J. G. Hansen, E. Jul, C. Limpach,I. Pratt, and A. Warfield. Live migration of virtualmachines. In Proc. 2nd Symposium on Networked SystemsDesign and Implementation (NSDI ’05), Boston, USA, May2005. Usenix.[6] J. Dike. User Mo<strong>de</strong> Linux. Prentice Hall PTR, 2006.[7] R. Figueiredo, P. Dinda, and J. Fortes. A case for grid computingon virtual machines. In Proc. International Conferenceon Distributed Computing Systems (ICDCS ’03),2003.[8] R. Goldberg. Survey of virtual machine research. IEEEComputer, 7(6):34–45, 1974.[9] W. Huang, J. Liu, B. Abali, and D. Panda. A case for highperformance computing with virtual machines. The 20thACM International Conference on Supercomputing, 2006.[10] D. Milojicic, V. Kalogeraki, R. Lukose, K. Nagaraja,J. Pruyne, B. Richard, S. Rollins, and Z. Xu. Peer-to-PeerComputing. Technical Report HPL-2002-57, HP Labs, PaloAlto, USA, 2002.[11] M. V. Neves, T. Scheid, A. S. Charão, G. S. Welter, andO. L. L. <strong>de</strong> Moraes. Análise paralela e distribuída <strong>de</strong> dadosmicrometeorológicos utilizando a plataforma JXTA. InProc. Workshop of Computational Grids and Applications(WCGA ’06), 2006.[12] A. Petitet, R. C. Whaley, J. Dongarra, and A. Cleary. HPL- A Portable Implementation of the High-Performance LinpackBenchmark for Distributed-Memory Computers. Disponívelem: http://www.netlib.org/benchmark/hpl/. Acessoem: julho 2006.[13] D. C. Plummer. Ethernet Address Resolution Protocol: Orconverting network protocol addresses to 48 bit Ethernetaddress for transmission on Ethernet hardware. RFC 826(Standard), Nov. 1982.[14] B. Quetier, V. Neri, and F. Cappello. Scalability comparisonof 4 host virtualization tools. Technical Report 1433,INRIA/LRI, Université Paris-Sud, 2006.[15] J. E. Smith and R. Nair. The architecture of virtual machines.IEEE Computer, 38(5):32–38, 2005.[16] J. Sugerman, G. Venkitachalam, and B.-H. Lim. VirtualizingI/O <strong>de</strong>vices on VMware workstation’s hosted virtualmachine monitor. In Proc. 2001 Usenix Annual TechnicalConference, pages 1–14. Usenix Assoc., 2001.[17] A. Whitaker, M. Shaw, and S. D. Gribble. Denali:Lightweight virtual machines for distributed and networkedapplications. Technical Report 02-02-01, University ofWashington, 2002.