ANA PAULA MATIAS COMPARAÇÃO ARQUITETURAL E DE DESEMPENHO DE AMBIENTES DE VIRTUALIZAÇÃO JOINVILLE, SC JULHO, 2009

Transcrição

1 I ANA PAULA MATIAS COMPARAÇÃO ARQUITETURAL E DE DESEMPENHO DE AMBIENTES DE VIRTUALIZAÇÃO JOINVILLE, SC JULHO, 2009

2 II UNIVERSIDADE DO ESTADO DE SANTA CATARINA UDESC CENTRO DE CIÊNCIAS TECNOLÓGICAS DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO ANA PAULA MATIAS COMPARAÇÃO ARQUITETURAL E DE DESEMPENHO DE AMBIENTES DE VIRTUALIZAÇÃO Trabalho de conclusão de curso submetido à Universidade do Estado de Santa Catarina como parte dos requisitos para a obtenção do grau de Bacharel em Ciência da Computação. Dr. Rafael R. Obelheiro Orientador JOINVILLE SC JULHO, 2009

3 III ANA PAULA MATIAS COMPARAÇÃO ARQUITETURAL E DE DESEMPENHO DE AMBIENTES DE VIRTUALIZAÇÃO Este Trabalho de Conclusão de Curso foi julgado adequado para a obtenção do título de Bacharel em Ciência da Computação e aprovado em sua forma final pelo Curso de Ciência da Computação Integral do CCT/UDESC. Banca Examinadora Orientador: Rafael R. Obelheiro, Dr Membro: Ricardo Ferreira Martins, M.Sc Membro: Débora Cabral Nazário, M.Sc. JOINVILLE - SC (03/07/2009)

4 IV A Deus, única presença, causa e substância de tudo. Aos meus pais, cujo exemplo de honestidade e trabalho tem sido um norteador para a minha vida. Aos meus familiares pelo apoio durante toda graduação.

5 V AGRADECIMENTOS Em qualquer tarefa sobre a qual nos engajamos acredito que há pessoas especiais que nos impulsionam e nos fazem continuar. Por isso, agradeço em primeiro lugar a Deus, autor e protetor da minha vida, por conceder-me toda a força, inspiração e perseverança, e às seguintes pessoas: Meus familiares, que acreditaram no meu potencial e que com muito esforço me deram à educação necessária para que eu chegasse até aqui; Meu professor orientador, pela disponibilidade, pelas sugestões dadas, pelas dúvidas esclarecidas, pelo apoio sempre encontrado e principalmente pelo carinho; Meus amigos de modo geral, pelos debates e propostas inovadoras, pela inspiração e pelo companheirismo que sempre mostraram para comigo; e A todos que direta ou indiretamente contribuíram para a realização deste estudo.

6 VI RESUMO Será realizado um estudo comparativo entre os ambientes de virtualização Xen e UML, que possuem diferentes arquiteturas, tentando identificar as situações em que cada arquitetura é mais indicada. As comparações incluem aspectos qualitativos (facilidade, restrições, e questões relativas ao uso) e quantitativos (usando ferramentas que permitam fazer benchmarking). A análise dos resultados vai buscar identificar as causas dos comportamentos observados nas arquiteturas dos ambientes de virtualização (Xen e UML) que serão estudados. Palavras-chave: Máquinas Virtuais. Xen. UML. benchmarking.

7 VII ABSTRACT This work presents a comparative study between Xen and UML, two virtualization environments with different architectures, trying to identify the situations in which each architecture is more appropriate. The comparison includes qualitative aspects (ease, restrictions and usage-related ones) and quantitative (obtained using benchmarking tools). The analysis of the results seeks to identify the causes of the observed behavior in the architecture of the specific virtualization environments studied. Keywords: Virtual Machines. Xen. UML. benchmarking.

8 VIII LISTA DE ILUSTRAÇÕES Figura 1 - Estrutura de um Sistema de Virtualização...15 Figura 2 Estrutura de Virtualização...19 Figura 3 - Sistema Computacional Padrão...20 Figura 4 - Virtualização de Linguagem de Programação ou Aplicação...21 Figura 5 - Virtualização do Sistema Operacional...22 Figura 6 - Virtualização do hardware...23 Figura 7- Técnica de Virtualização Total...25 Figura 8 - Técnica de Paravirtualização...26 Figura 9 - Consolidação de Servidores...28 Figura 10 - Modelo da arquitetura Xen...33 Figura 11 - Resumo das ferramentas de benchmarking...45 Figura 12 Cenário 1 - Sistema Computacional Típico...46 Figura 13 Cenário 2 Ambiente de Virtualização Xen...47 Figura 14 Cenário 3 Ambiente de Virtualização UML...48 Figura 15 Teste de Processador Lmbench...51 Figura 16 Teste de Processador - Sysbench...52 Figura 17 Teste de Memória Lmbench...55 Figura 18 Teste de Memória Lmbench...56

9 IX Figura 19 Teste de Memória - Sysbench...57 Figura 20 Teste de Disco Sysbench...59 Figura 21 Teste de Disco (Desempenho do sistema de arquivos) Bonnie Figura 22 Teste de Disco Bonnie Figura 23 Teste de Rede (TCP) - Iperf...64 Figura 24 Teste de Rede - Netperf...65 Figura 25 Teste de Rede (TCP_RR/UDP_RR) - Netperf...66

10 X LISTA DE TABELAS Tabela 1 Comparação entre Virtualização Total e Paravirtualização...26 Tabela 2 Comparação qualitativa entre Xen e UML...37

11 XI LISTA DE ABREVIATURAS E SIGLAS AMD AVs BIOS CPU CS DLPI MMV MV SCTP SO TCP TI UDP UML XTI Advanced Micro Devices Ambientes de Virtualização Basic Input/Output System Central Processing Unit Consolidação de Servidores Data Link Provider Interface Monitor de Máquinas Virtuais Máquina Virtual Stream Control Transport Protocol Sistema Operacional Transmission Control Protocol Tecnologia da Informação User datagrama Protocol User Mode Linux X/Open Transport Interface

12 XII SUMÁRIO 1 INTRODUÇÃO OBJETIVOS Objetivo geral Objetivos específicos ESTRUTURA DO TRABALHO DE CONCLUSÃO DE CURSO VIRTUALIZAÇÃO O QUE É VIRTUALIZAÇÃO CAMADAS DE VIRTUALIZAÇÃO Virtualização de linguagens de programação ou nível de aplicação Virtualização do hardware TÉCNICAS DE VIRTUALIZAÇÃO Virtualização total ou full virtualization Relação entre a virtualização total e a paravirtualização Recompilação dinâmica ou dynamic recompilation APLICAÇÕES E VANTAGENS DE VIRTUALIZAÇÃO DESVANTAGENS DA VIRTUALIZAÇÃO CONSIDERAÇÕES PARCIAIS ARQUITETURAS DE VIRTUALIZAÇÃO: DESCRIÇÃO E COMPARAÇÃO QUALITATIVA VIRTUALIZAÇÃO EM NÍVEL DE HARDWARE: XEN VIRTUALIZAÇÃO EM NÍVEL DE SISTEMA OPERACIONAL: UML COMPARAÇÕES QUALITATIVAS CONSIDERAÇÕES PARCIAIS...38

13 4 CRITÉRIOS PARA O ESTUDO QUANTITATIVO...39 XIII 4.1 MÉTRICAS FERRAMENTAS DE BENCHMARKING Lmbench Bonnie Iperf Netperf Ubench Considerações sobre as ferramentas de benchmarking CENÁRIOS DE TESTES CONSIDERAÇÕES PARCIAIS RESULTADOS DAS FERRAMENTAS DE BENCHMARKING PROCESSADOR MEMÓRIA DISCO REDE ANÁLISE COMPARATIVA QUANTITATIVA CONSIDERAÇÕES PARCIAIS...70 CONCLUSÃO...72 REFERÊNCIAS...74 ANEXOS...80

14 14 1 INTRODUÇÃO Com a evolução dos computadores pessoais e o desenvolvimento das redes, houve uma popularização dos ambientes cliente/servidor, em contraste com os antigos sistemas centralizados em máquinas de grande porte (mainframes) e terminais. Com isso, o número de servidores cresceu significativamente no ambiente de Tecnologia da Informação (TI) das empresas. Uma das consequências de tal crescimento foi o aumento no custo e na complexidade associados ao gerenciamento desses servidores (EWEEK, 2007). Com isso, surgiu uma estratégia que vem sendo cada vez mais utilizada para amenizar a situação: a Consolidação de Servidores (CS). Ela substitui vários servidores físicos (muitos dos quais com bastante capacidade ociosa durante boa parte do tempo) por servidores lógicos implementados sobre um conjunto menor de servidores físicos. Através da CS, são proporcionadas algumas vantagens, como: gerenciamento centralizado e um melhor aproveitamento dos recursos de hardware dos equipamentos. A virtualização é uma técnica chave para a CS, pois a sua utilização facilita a consolidação, uma vez que os servidores lógicos ficam isolados uns dos outros, mesmo compartilhando o mesmo hardware. A virtualização insere uma camada extra de software entre o hardware e o SO, com o objetivo de criar diversos sistemas virtuais, que executam de maneira isolada entre si (FIGUEIREDO et al., 2005). Dessa forma, diversos Sistemas Operacionais (SOs) podem executar concorrentemente sobre o mesmo hardware, com a camada extra de software, conhecida como Monitor de Máquinas Virtuais (MMV) ou hypervisor, controlando o acesso físico dos mesmos ao hardware. Esta organização clássica de um sistema virtualizado é ilustrada na figura 1.

15 15 Figura 1 - Estrutura de um Sistema de Virtualização Existem diversas técnicas de virtualização, sendo estas as mais utilizadas atualmente: Virtualização Total - é um método onde o Gerenciador de MVs intermedia o hardware com as MVs. A grande vantagem dessa técnica é poder usar SOs virtualizados sem nenhuma modificação, porém não possui o melhor desempenho possível. Exemplos: VMWare Server, VMWare Workstation, UML, Adeos, VirtualBox, Virtual PC (LINTEC, 2003). Paravirtualização é um método que cria um espaço compartilhado entre as MVs. A grande vantagem dessa técnica é o desempenho, sendo muito próximo da Máquina Real, porém o SO que gerencia as MVs precisa de modificações para sua execução. As MVs também precisam de modificações para serem executadas, a não ser que exista suporte no processador para a virtualização. A Intel e a AMD (Advanced Micro Devices) disponibilizam suporte em hardware à virtualização em alguns modelos comercializados atualmente. Se o processador usado possuir suporte à virtualização embutido, então é possível executar a MV sem modificações no SO virtualizado. Exemplo: Xen (BARHAM et al., 2003). Recompilação dinâmica este método consiste em traduzir durante a execução de um programa as instruções de um formato para outro. O sistema pode adequar o código gerado de forma a refletir o ambiente original do programa. Exemplo: QEMU (TIJMS, 2000). Existem diferentes tecnologias para virtualização, cada uma com vantagens e desvantagens na comparação entre elas, mas não fica claro esta comparação. Logo, este é o

16 16 problema encontrado, visto que depende do que será avaliado e se tem maior ou menor desempenho, isto dependendo da tecnologia utilizada. Portanto, o objetivo é comparar as arquiteturas com diferenças de virtualização, tentando entender de que forma as escolhas de projeto influenciam no ponto de vista dos usuários dessas arquiteturas. 1.1 OBJETIVOS Objetivo geral Fazer uma comparação arquitetural e de desempenho dos ambientes de virtualização (AVs) Xen e UML, que possuem diferentes arquiteturas, tentando identificar as situações que favoreçam um ou outro tipo de ambiente. A comparação inclui aspectos qualitativos e quantitativos e a análise dos resultados vai buscar identificar as causas do comportamento observado na arquitetura das MVs Objetivos específicos Realizar estudo sobre virtualização e os AVs Xen e UML, efetuando uma comparação qualitativa entre os AVs escolhidos. Após será feito um pré-estudo sobre as ferramentas de benchmarking para posteriormente analisar o desempenho dos AVs distintos. A seguir, será feita uma análise e comparação dos resultados de desempenho com base na arquitetura.

17 ESTRUTURA DO TRABALHO DE CONCLUSÃO DE CURSO O presente trabalho está estruturado em cinco capítulos. O primeiro apresenta uma introdução sobre o trabalho e define seus objetivos. O segundo capítulo apresenta o estudo feito para o entendimento sobre camadas, técnicas, aplicações, vantagens e desvantagens da virtualização. O capítulo três apresenta dois ambientes específicos de virtualização (Xen e UML), estes baseados em arquiteturas distintas, e a comparação qualitativa entre os AVs. No capítulo quatro serão discutidas quais serão as métricas, ferramentas de benchmarking e os cenários de testes que serão utilizados para fazer as comparações quantitativas. No capítulo cinco, estão os resultados obtidos com as ferramentas de benchmarking para a seleção das métricas, bem como a análise e comparação entre os resultados. No capítulo seis, são apresentadas as considerações finais.

18 18 2 VIRTUALIZAÇÃO O presente capítulo tem por finalidade elucidar os principais conceitos referentes à virtualização, as camadas de virtualização, técnicas e algumas aplicações citando as vantagens e desvantagens. 2.1 O QUE É VIRTUALIZAÇÃO Visando o melhor aproveitamento do poder dos mainframes, no início da década de 70 foi criada uma técnica para permitir que diversas MVs compartilhassem o mesmo hardware subjacente (GOLDBERG, 1974). Basicamente, a virtualização é uma técnica que insere uma camada extra de software entre o hardware e o SO, com o objetivo de criar diversos sistemas virtuais, que executam de maneira isolada entre si (FIGUEIREDO, 2005). Dessa forma, diversos SOs podem ser executados concorrentemente sobre o mesmo hardware, com a camada extra de software, conhecida como Monitor de Máquinas Virtuais (MMV) ou hypervisor, controlando o acesso físico dos mesmos ao hardware. Esta organização clássica de um sistema virtualizado é ilustrada na figura 2, onde temos o Host que é o Hardware Hospedeiro onde serão executadas as MVs e o Guest (Sistema Operacional Convidado), representado como SO 1, SO 2, SO 3, sendo os softwares que serão executados dentro de cada MV. Temos também aplicações convidadas (Aplicação 1, Aplicação 2, Aplicação 3), estas executadas acima do SO..

19 19 Figura 2 Estrutura de Virtualização A virtualização permite múltiplas MVs, com SOs diferentes executando isoladamente, lado a lado no mesmo hardware. Cada MV tem seu próprio hardware virtual (por exemplo: memória, processador, etc.) em cima do qual um SO e aplicações são carregados. Máquinas virtuais são geralmente encapsuladas em arquivos, assim elas ficam mais fáceis de serem salvas, copiadas e de se prover uma MV. Dessa forma, sistemas completos (com aplicações totalmente configuradas, sistema operacional, BIOS e hardware virtual) podem ser movidos, em questão de segundos, de um servidor físico a outro para manutenção em tempo mínimo (KALLAS, 2006). De acordo com Carvalho (2007), a virtualização possui alguns benefícios: Particionamento: Múltiplas aplicações e SOs podem ser executados em um mesmo servidor físico. Os servidores podem ser consolidados em MVs, dando escalabilidade às arquiteturas. Além disto, os recursos computacionais são tratados em uma política uniforme para que sejam alocadas máquinas virtuais de maneira controlada. Isolamento: As MVs são completamente isoladas da máquina hospedeira e de outras MVs. Há isolamento de falhas e segurança ao nível do hardware, ou seja, se uma MV tem problemas, todas as outras não são afetadas. Os dados não vazam

20 20 entre MVs e aplicativos podem somente se comunicar em conexões de rede configuradas. Encapsulamento: Todo o estado da MV é encapsulado: memória, imagens em disco e estado dos dispositivos de E/S. Um completo ambiente de MV é salvo em um arquivo, fácil de fazer backup, de ser movido e copiado. A padronização de hardware virtualizado é fornecida para a aplicação, garantindo compatibilidade. 2.2 CAMADAS DE VIRTUALIZAÇÃO Observando o Sistema Computacional Padrão representado na figura 3, podemos aplicar a virtualização em diferentes camadas. Dadas as diferentes interfaces entre as camadas que compõem o sistema, as possibilidades de virtualização em termos de camadas são as seguintes: virtualização de linguagens de programação ou nível de aplicação, virtualização do sistema operacional e virtualização do hardware (LAUREANO, 2006). Figura 3 - Sistema Computacional Padrão

21 Virtualização de linguagens de programação ou nível de aplicação Uma MV de aplicação suporta a execução de um processo ou aplicação individual. Ela é criada sob demanda, no momento do lançamento da aplicação convidada, sendo destruída quando a aplicação finaliza sua execução. O conjunto de MV + aplicação é visto então como um único processo dentro do SO subjacente, submetido às mesmas condições e restrições que os processos nativos (SMITH & NAIR, 2004). A virtualização é obtida por meio da abstração da MV. Conforme se observa na figura 4, a aplicação utiliza essa camada para executar as instruções do programa. Essa solução garante que uma aplicação possa ser executada em qualquer plataforma de software ou hardware, pois a camada é abstraída de forma idêntica em todas as plataformas, porém é necessária uma MV específica para cada uma. Java é um exemplo dessa arquitetura (ROSENBLUM, 2004). Figura 4 - Virtualização de Linguagem de Programação ou Aplicação Fonte: (LAUREANO, 2006).

22 Virtualização do sistema operacional As MVs partilham o mesmo hardware e o SO da máquina física através de uma camada de virtualização (MMV), cuja responsabilidade será gerenciar várias máquinas para o usuário, executando em paralelo, sendo que estas são independentes e isoladas uma das outras, conforme mostra a figura 5. Um ambiente operacional para uma aplicação consiste de SO, bibliotecas em nível de usuário e outras aplicações, algumas estruturas de dados do sistema especifico, um sistema de arquivos, além de outras definições de um ambiente. Se estas características forem parecidas, fica difícil poder notar a diferença entre o sistema real e o virtualizado. Esta é a ideia principal por trás das técnicas de virtualização do SO, onde acima da camada de virtualização é criada uma partição para cada MV e cada uma vai ter o seu próprio endereço de IP e outros recursos de hardware (embora sejam limitados), chegando a ter uma réplica do ambiente operacional sobre a máquina física. Com uma cuidadosa separação e a utilização de técnicas de multiplexação, cada MV pode ser capaz de exportar um ambiente operacional completo, sendo que estes vão se manter isolados uns dos outros. O UML e FreeBSD são exemplos dessa arquitetura (NANDA & CHIUEH, 2005). Figura 5 - Virtualização do Sistema Operacional

23 Virtualização do hardware A virtualização do hardware ocorre em ambientes de MVs construídos para suportar SO convidados completos, com aplicações convidadas executando sobre eles. Uma MV de sistema suporta um ou mais SOs convidados, com suas respectivas aplicações, executando de forma isolada e independente, conforme mostra a figura 6. Cada SO convidado elucida estar executando sozinho sobre a plataforma de hardware (MAZIERO, 2008). Quando ocorre um erro durante a execução de uma instrução privilegiada (MV), ao invés de gerar uma exceção, a instrução é enviada para o MMV. Isso permite que o MMV tome o controle da máquina para manter cada MV isolada sem que o erro afete as outras MVs que estão executando. O MMV executa as instruções sobre o processador ou emula os resultados, retornando-as ao MV. A arquitetura mais popular é a X86, esta não totalmente virtualizada, ou seja, certas instruções privilegiadas falham sem retornar exceções quando são executadas com privilégios insuficientes. As técnicas de virtualização devem ter alguma solução para passar a controlar o MMV: quando executa instrução de falha (NANDA & CHIUEH, 2005). VMWare, Virtual PC, Denali e Xen são exemplos dessa arquitetura. Figura 6 - Virtualização do hardware Fonte: (ROSENBLUM, 2004).

24 TÉCNICAS DE VIRTUALIZAÇÃO Constuma-se utilizar diferentes termos para descrever um mesmo tipo de virtualização. Basicamente, existem três tipos de virtualização: Virtualização Total, Paravirtualização, e Recompilação Dinâmica, estas o enfoque desta seção Virtualização total ou full virtualization Virtualização total (figura 7) é um método onde o MMV intermedia o hardware com as MVs, onde o SO virtualizado executa em cima do hardware emulado, perdendo desempenho. É uma técnica de virtualização utilizada para permitir que qualquer software possa ser executado sem a necessidade de fazer modificações nos SOs convidados, mas o sistema virtualizado executa de forma mais lenta e o MMV precisa implementar alternativas para que as operações privilegiadas possam ser executadas em processadores que não suportem a virtualização nativamente (processadores Intel 32 bits, por exemplo). (SILVA, 2007). Para isso, esta técnica realiza uma simulação completa do hardware da máquina de modo que qualquer SO possa ser executado. Esta simulação implica em representar o conjunto de instruções do processador, a memória principal, interrupções, exceções e acesso aos diversos dispositivos existentes (SUGERMAN et al., 2001). VMWare, UML, Virtual Server e Virtual PC são exemplos de virtualização total.

25 25 Figura 7- Técnica de Virtualização Total Paravirtualização ou paravirtualization Na paravirtualização (figura 8) são feitas alterações no SO convidado (hóspedes) para facilitar a virtualização. Com isto, perde-se a portabilidade do sistema, mas se ganha desempenho, permitindo que o SO convidado acesse diretamente os recursos do hardware. Este acesso é monitorado pelo MMV, que fornece ao SO convidado todos os limites do sistema, tais como endereços de memória que podem ser utilizados e endereçamento em disco (CROSBY, 2006). Os SOs convidados e o SO virtualizador (hospedeiro) possuem tarefas em comum, reduzindo assim a complexidade do desenvolvimento das MVs. Assim, os SOs totalmente diferentes podem ser executados paralelamente em uma MV. O SO virtualizador praticamente não consome recursos, compensando assim as modificações que precisam ser feitas no SO convidado (LAUREANO, 2006). Xen é um exemplo de paravirtualização.

26 26 Figura 8 - Técnica de Paravirtualização Relação entre a virtualização total e a paravirtualização Na tabela 1, tem-se a comparação entre a virtualização total e paravirtualização: Tabela 1 Comparação entre Virtualização Total e Paravirtualização. Virtualização Total O SO convidado não precisa sofrer qualquer tipo de alteração. Grande portabilidade Perda de desempenho Acesso à memória virtual - Sempre que o SO convidado acessa a memória virtual, o MMV faz a tradução dos endereços para acessar a memória real, exige do MMV um trabalho adicional para o gerenciamento da memória. Paravirtualização O SO convidado sofre modificações para que a interação com o MMV seja mais eficiente; Perda de portabilidade Ganho de desempenho Acesso à memória virtual - Sempre que o SO convidado acessa a memória virtual, o monitor informa ao SO convidado qual o espaço de memória que pode ser utilizado, e este acessa diretamente a memória sem interferência do MMV.

27 27 Acesso a disco o SO convidado enxerga o disco como seu para uso exclusivo. Sempre que o sistema realiza uma chamada de sistema para acesso ao disco, o MMV deve captura essa chamada, interpretá-la e repassá-la para o sistema que executa a operação. Fonte: LAUREANO (2006). Acesso a disco - o SO convidado sabe que o disco é compartilhado e realiza diretamente o acesso ao disco (sem interferência do MMV), bem como aos demais dispositivos (mouse, teclado, etc.), o MMV somente controla a ordem de acesso, no caso de múltiplos SO convidados em execução simultaneamente. Nota-se que a paravirtualização possui melhor desempenho que a virtualização total. Isso se deve, basicamente ao fato de que os drivers de dispositivos que são executados nas MVs paravirtualizadas serem os drivers reais para os dispositivos físicos, diferentemente dos drivers emulados da virtualização total Recompilação dinâmica ou dynamic recompilation Esta técnica consiste em recompilar partes do código de um programa durante a sua execução. Com o isso, o sistema pode adequar o código compilado para refletir o ambiente de execução original do programa, além de talvez produzir um código mais eficiente, explorando informações que não estão disponíveis para um compilador estático tradicional. Em outros casos, um sistema pode empregar a recompilação dinâmica como parte de uma estratégia de otimização adaptável para executar uma representação portátil do programa como os bytecodes do Java ou.net (LAUREANO, 2006). A recompilação dinâmica é feita em 7 passos, descrito por Tijms (2000). Em primeiro momento, o código binário é varrido para que seja identificada uma sequência de bits correspondentes a seção de código do programa em execução. Logo após esse passo, os bits agrupados anteriormente são divididos em instruções, juntamente com os parâmetros delas. Então as instruções são transformadas para uma representação mais próxima da máquina nativa. Um código em uma linguagem de alto nível é gerado a partir da representação

28 anterior, código esse que é compilado e reescrito na linguagem nativa. Assim, temos uma sequência de bits agora executáveis no hardware nativo APLICAÇÕES E VANTAGENS DE VIRTUALIZAÇÃO A utilização da virtualização está se tornando uma alternativa para vários sistemas computacionais pelas vantagens em custo e também pela sua portabilidade. Entre as diversas aplicações de virtualização, podemos destacar as seguintes (MAZIERO, 2008): O compartilhamento de hardware é frequentemente utilizado, pois permite executar vários SOs sobre uma mesma plataforma de hardware. Uma área de aplicação desse modelo é a consolidação de servidores (figura 9), ou seja, substituir vários servidores físicos (muitos dos quais com bastante capacidade ociosa durante boa parte do tempo) por servidores lógicos implementados sobre um conjunto menor de servidores físicos. Através da CS, são proporcionadas algumas vantagens como gerenciamento centralizado e um melhor aproveitamento dos recursos de hardware dos equipamentos. Figura 9 - Consolidação de Servidores Fonte: (SHIVELEY, 2006) Experimentação com redes e sistemas distribuídos: é possível construir uma rede de MVs, comunicando-se por protocolos de rede como o TCP/IP, sobre um único computador hospedeiro. Isto torna possível o desenvolvimento e implantação de

29 29 serviços de rede e de sistemas distribuídos sem a necessidade de uma rede real, o que é especialmente interessante dos pontos de vista didático e experimental; Segurança: a propriedade de isolamento provida pelo MMV torna esta abordagem útil para isolar domínios, usuários e/ou aplicações não confiáveis. Pode-se, por exemplo, executar uma aplicação maliciosa dentro de uma MV para observar seus efeitos sobre o SO convidado (hóspede); Desenvolvimento de software de baixo nível: o uso de MVs para o desenvolvimento de software de baixo nível, como partes do núcleo do SO, módulos e protocolos de rede, tem vários benefícios com o uso de MVs. Por exemplo, o desenvolvimento e os testes podem ser feitos sobre a mesma plataforma. Outra vantagem visível é o menor tempo necessário para instalar e lançar um núcleo em uma MV, quando comparado a uma máquina real. Por fim, a execução em uma MV pode ser melhor acompanhada e depurada que a execução equivalente em uma máquina real. Outras vantagens de virtualização são (BRANDÃO & VAHL, 2007): Otimização do uso da CPU: As máquinas atuais estão cada vez mais robustas, com mais recursos de memória e processamento. Usando servidores isolados fisicamente há uma subutilização da CPU dos mesmos. Assim, com a virtualização, é possível isolar sistemas diferentes em cima de um único hardware, fazendo um uso melhor dos recursos de máquina; Economia de espaço: com a necessidade de menos máquinas físicas menos espaço para o servidor será necessário; Economia de Energia: A economia de energia se deve não só a energia gasta para manter os servidores ligados, mas também a energia gasta para manter os sistemas de refrigeração.

30 DESVANTAGENS DA VIRTUALIZAÇÃO Uma das grandes desvantagens da utilização de MVs, é que o desempenho pode se torna limitado por compartilhar recursos de hardware com a máquina hóspede (GOMES & FRACALOSSI, 2007). Outras desvantagens que são notadas: Exige uma máquina com configuração de alta performance, pois vai utilizar diferentes SOs executando ao mesmo tempo sendo assim precisa de mais processamento, para não executar devagar. O desempenho das MVs é inferior ao obtido com as máquinas físicas. Risco na utilização de uma única máquina física como ponto central para diversos SOs e aplicações. Esta desvantagem pode ser contornada com a utilização de dispositivos de hardware redundantes. Embora para isso, seja necessário um maior investimento financeiro. 2.6 CONSIDERAÇÕES PARCIAIS Constata-se que, com a virtualização, pode-se criar diversas MVs (com SOs distintos e suas aplicações) que executam sobre o mesmo hardware. A virtualização é composta pelas camadas a nível de SO, hardware e aplicação. As técnicas de virtualização mais utilizadas são: virtualização total, paravirtualização e recompilação dinâmica. A virtualização possui vantagens como segurança, isolamento, particionamento, economia de espaço e energia. A principal desvantagem é o desempenho das MVs, sendo inferior ao obtido com as máquinas

31 31 físicas. Com isso, em muitos casos conclui-se que as vantagens superam as desvantagens, quando os requisitos de desempenho não são tão críticos. No próximo capítulo, serão descritos os ambientes de virtualização Xen e UML, e após será feita a comparação qualitativa entre os ambientes, considerando a consolidação de servidores.

32 32 3 ARQUITETURAS DE VIRTUALIZAÇÃO: DESCRIÇÃO E COMPARAÇÃO QUALITATIVA. Neste capítulo serão descritos os ambientes de virtualização Xen e UML e será feita uma comparação qualitativa entre eles. Estas ferramentas foram escolhidas, pois estão em camadas diferentes, sendo que a Xen está na camada de hardware e a UML na camada do SO. Elas também possuem diferentes técnicas de virtualização: o Xen utiliza a técnica de paravirtualização e o UML a técnica de virtualização total. Além disso, são ferramentas de código aberto e são altamente utilizadas em ambientes acadêmicos, bem como aplicações de produção. 3.1 VIRTUALIZAÇÃO EM NÍVEL DE HARDWARE: XEN O Xen é um MMV que provê uma camada de abstração entre o hardware e o SO virtualizado, sendo construído visando o alto desempenho e a forte isolação entre os SOs virtuais. Desenvolvido pela Universidade de Cambridge, todo o código e as aplicações do MMV do Xen são de código aberto (open source), baseados na abordagem clássica de implementação de virtualização, onde o MMV possui o nível mais alto de privilégios. O Xen possui suporte a diversas arquiteturas como IA-32, AMD64 e EM64T (BARHAM et al., 2003).

33 33 A abordagem clássica de virtualização apresenta limitações em arquiteturas implementadas utilizando a especificação Intel IA-32, onde os SOs virtualizados ainda conseguem executar instruções com um privilégio maior. Para contornar este problema arquitetural, o monitor Xen utiliza a técnica de paravirtualização para adaptar a execução dos SOs virtualizados. Através da paravirtualização, Xen garante que os sistemas virtualizados não tenham acesso direto aos recursos disponíveis, permitindo desta forma uma virtualização eficiente sobre a arquitetura Intel x86 (YOUSEFF, 2006). A virtualização clássica implementada utilizando a técnica de paravirtualização requer pequenas alterações nos SOs virtualizados, já que a interface oferecida pelo MMV difere em alguns pontos da interface real do computador. Efetuando-se estas alterações, um SO adaptado permite que os processos e serviços internos executem sem nenhuma alteração em seus códigos, sem impor uma sobrecarga limitante que comprometa o desempenho final das aplicações (MENON et al. 2005). Atualmente, SOs como Linux, NetBSD, FreeBSD, e Windows XP possuem implementações adaptadas para execução sobre a interface virtual implementada por Xen. A implementação do monitor Xen (figura 10) é dividida especificamente entre o MMV (hypervisor) e os domínios Xen, que são a representação das MVs existentes. O Xen carrega um componente chamado de hypervisor antes de carregar o SO, sendo responsável por controlar os recursos de comunicação, memória e processamento das MVs, ou seja, é como se o hypervisor estivesse executando direto no hardware. As MVs no Xen são chamadas de domínios ou simplesmente Dom. Por isso, precisam ter um SO inicial invocado pelo hypervisor que é chamado de Domínio0 ou simplesmente Dom0. O hypervisor não possui drivers e controladores de hardware; logo precisa do Dom0 para esta comunicação. O Dom0 é o responsável por controlar as demais máquinas que se chamam Domínio Uniprivileged ou DomU, todas as MVs são gerenciadas pelo Dom0 (SANTOS, 2008). Figura 10 - Modelo da arquitetura Xen

34 34 Além de gerenciar o acesso aos recursos de hardware existentes, o MMV Xen implementa através do Domain0 um conjunto de chamadas de sistema que permitem migrar um SO entre computadores. A independência de hardware obtida pelo monitor Xen permite que MVs sejam encapsuladas e migradas entre computadores com arquitetura virtualizada. Este processo de migração pode ser efetuado sem a interrupção dos serviços em execução sobre o SO virtualizado. O mecanismo de live migration (CLARK et al. 2005) implementado por Xen utiliza técnicas que efetuam a migração completa de um sistema sem interromper a disponibilidade do serviço. A migração de MVs surge como ferramenta auxiliar para administradores de redes e servidores, já que um SO pode migrar sem interromper os serviços em execução, permitindo a manutenção do hardware do computador hospedeiro quando necessário. Porém, esta ferramenta somente pode ser utilizada em ambientes que utilizam um sistema de compartilhamento de arquivos e diretórios, como NFS (Network File System) já que a implementação atual do mecanismo de live migration não possui suporte para migração do sistema de arquivos local (XEN, 2008). 3.2 VIRTUALIZAÇÃO EM NÍVEL DE SISTEMA OPERACIONAL: UML O User-Mode Linux (UML) é um projeto open source que permite o usuário executar uma implementação do kernel do Linux, onde a arquitetura suportada é outro kernel do Linux [HOSKINS, 2006]. Foi desenvolvido por Jeff Dike no ano 2000, como uma alternativa para uso de MVs em ambientes Linux. É utilizado como alternativa para se executar versões diferentes de Linux e processos embaixo do Linux. É possível utilizar para testar novas distribuições ou aplicativos sem alterar a máquina real (HONEYNET, 2002). O UML suporta as arquiteturas X86, X86-64, Power PC e utiliza a técnica de virtualização total (LAUREANO, 2006). Normalmente, os programas aplicativos fazem suas requisições ao kernel, que por sua vez aciona os recursos de hardware da máquina conforme solicitado (sem esquecer que este kernel sempre é específico para a arquitetura do computador em questão). Mas no caso do UML, os programas do usuário fazem requisições ao kernel e, embora eles não saibam disso,

35 35 este kernel vai passar todas as requisições para o outro da máquina hospedeira, fazendo a comunicação com o hardware. O consumo de memória de cada sessão virtual é proporcional ao demandado pelos processadores que estão executando. A virtualização ocorre através da interceptação das chamadas de sistema e a máquina não tem acesso ao hardware nativo, exceto se permitido (ROSSI, 2008). O UML executa apenas sobre Linux, mas há planos de portá-lo para outras plataformas. Ele executa os binários do hospedeiro sem necessidade de recompilação ou religação. Tudo que a máquina cria fica confinado a ela, não se propagando para outras instâncias ou hospedeiro. Seus parâmetros de memória e disco podem ser modificados dinamicamente, possuindo escalonador e sistema de memória virtual próprios, usando o sistema hospedeiro somente para acessos ao hardware (BUCHACKER & SIEH, 2002). O UML é executado no nível do usuário, então a segurança é garantida. O kernel do UML roda sobre uma máquina virtual que não necessariamente corresponde à sua configuração física, incluindo os dispositivos, sistemas de arquivos, quantidade de memória, interfaces de rede e tudo o mais. A máquina virtual do UML suporta interface de rede, podendo ter seu próprio IP e comunicar-se com o hospedeiro e com outras máquinas da sua rede local. Pode-se até rodar múltiplas MVs no seu computador, cada uma com seu próprio IP comunicando-se com as demais (NANDA & CHIUEH, 2005). A utilização de memória apresenta alguns problemas, já que cada instância UML se comporta exatamente como um kernel, isto é, não libera memória a não ser que seja solicitado a fazê-lo, mantendo dados em cache. Uma máquina UML é vista como um arquivo no sistema nativo, e corresponde a uma imagem de um disco, contendo partições e arquivos da MV (BUCHACKER & SIEH, 2002). O UML foi construído originalmente para trabalhar com tracing threads (TT), sendo cada processo da MV mapeado para um processo no hospedeiro. A TT rastreia chamadas de sistema nos processos da UML, intercepta-as e desvia o fluxo de execução para o kernel UML. O problema com este esquema é a possibilidade dos processos poderem acessar o hospedeiro, uma vez que estão no seu espaço de endereçamento. Além disso, este mecanismo é lento, pois há quatro chaveamentos de contexto: uma entrega e um retorno de sinal (QUÉTIER et al., 2006). Para resolver este problema, um novo mecanismo foi implementado,o Separate Kernel Address Space (SKAS). Este mecanismo requer modificação no ptrace do kernel hospedeiro, mas é pouco intrusivo, segundo a documentação (DIKE, 2006).

36 36 Do ponto de vista da UML, o SKAS melhora o desempenho, mas não modifica sua funcionalidade, enquanto que do ponto de vista do hospedeiro, os processos UML desaparecem, restando apenas os quatro essenciais, e há redução na carga do processador (DIKE, 2006). 3.3 COMPARAÇÕES QUALITATIVAS Com a comparação qualitativa determina-se alguns critérios que ajudem a enxergar as especialidades de cada ferramenta os critérios de comparação buscam destacar as facilidades e restrições de cada ferramenta, visando identificar situações mais favoráveis a um ou outro AV. Embora existam diversos outros critérios que podem ser comparados, foram selecionados aqueles mais relevantes em cenários de consolidação de servidores. Os critérios que serão utilizados para fazer a comparação são estes: Documentação se os ambientes de virtualização (AVs) possuem documentação com qualidade e quantidade necessária; Dificuldade de instalação grau de dificuldade (baixo, médio, alto) de instalação dos AVs; Licença qual o tipo de licença de cada AV; Plataformas disponíveis para uso são os SOs que suportam os AVs; Plataformas suportadas (convidado) quais os SOs que podem ser utilizados como convidados nos AVs; SO convidado = SO hospedeiro se o SO que é convidado tem que ser igual ao que está no SO hospedeiro; Arquitetura convidada = Arquitetura hospedeira se a arquitetura convidada tem que ser igual à arquitetura hospedeira; Convidados com SMP (Symmetric Multi-Processing) se o processador permite que o SO convidado distribua as tarefas entre dois ou mais processadores, assim analisando se permite que vários processadores partilhem o processamento de instruções requisitadas pelo sistema;

37 Aplicações de MV enxergam o software no SO hospedeiro se a MV enxerga os softwares que estão sendo executados no SO hospedeiro; Realocação de memória para a MV em execução se é possível realocar mais memória do que o que esta disponível para o AV em execução; Suporta a migração de AVs (Live migration) se durante a execução da MV, ela pode ser deslocada para outro sistema físico de acolhimento, sem parar os serviços ou executar a mesma. Utilizando estes aspectos, a tabela 2 mostra a comparação qualitativa entre o Xen e o UML. Os dados da tabela foram baseados nos autores LAUREANO (2006) e COLAB (2006). Tabela 2 Comparação qualitativa entre Xen e UML Documentação Dificuldade de instalação Licença Plataformas disponíveis para uso Plataformas suportadas (convidado) SO convidado = SO hospedeiro Arquitetura convidada = arquitetura hospedeira Xen Existe, mas não em quantidade. Média (pois precisa configurar os domínios) GPL (Licença Pública Geral) NetBSD, Solaris e Linux Linux, Solaris, Windows XP e 2003 Server (todos precisam de CPU que possuam bom desempenho) Não - pois suporta Solaris, Linux, Windows Guest e host têm que ser da mesma arquitetura (x86, 32 ou 64 bits). Porém, no XEN pode ter versão 64 bits como host e 32 bits como guest sem problemas, afinal o XEN virtualiza tudo. UML Existe, mas não em qualidade e quantidade. Baixa (pois é só compilar o Kernel) GPL versão 2 (Licença Pública Geral) Linux Linux Sim - Linux tem que rodar Linux O UML também pode ser 32 bits rodando sobre um host 64 bits. Convidados com SMP Sim Não Aplicações na MV enxergam software no SO hospedeiro? Não Não Realocação de memória para a MV em execução Sim Não Suporta a migração de AVs - Live Migration Sim Não 37

38 38 Com a tabela 2 percebe-se que o Xen é uma ferramenta que possui mais funcionalidades, tornando-se a mais poderosa, porém é mais complexa para utilização. Já o UML não é tão poderoso, porém é mais simples que o AV Xen. Com isso pode-se concluir que, dependendo do contexto onde será utilizado o AV, deve-se utilizar o mais adequado à situação. 3.4 CONSIDERAÇÕES PARCIAIS Neste capítulo, foram descritos os AVs Xen e UML e feita uma comparação qualitativa entre eles. O Xen é executado na camada de hardware e utiliza a técnica de paravirtualização, sendo assim, o SO sofre algumas modificações na hora da instalação, para que a interação com MMV seja mais eficiente. O Xen é um ambiente que possui muitas funcionalidades, como suporte a migração de AVs, realocação de memória durante a execução. Como possui muitas funcionalidades, precisa-se de um computador com alto desempenho, porque senão vai tornar o processamento de baixo desempenho. Além disto, a UML é executada na camada de software e utiliza a técnica de virtualização total, não precisando sofrer modificações no SO no momento da instalação. Com isto, tem perda de desempenho e possui grande flexibilidade, pois tem a capacidade de criar e destruir as MVs criadas dentro de segundos, e as instâncias são reconfiguradas dinamicamente. No capítulo 4, primeiramente serão definidas as métricas e depois um pré-estudo sobre as ferramentas de benchmarking que medem as métricas selecionadas. Por último, serão definidos os cenários de teste que serão utilizados para obter os dados.

39 39 4 CRITÉRIOS PARA O ESTUDO QUANTITATIVO Este capítulo tem como objetivo fazer um estudo preliminar sobre as comparações quantitativas, cujo principal objetivo é medir o desempenho de cada AV. Serão apresentados os critérios utilizados para fazer o estudo das ferramentas de benchmarking. Primeiramente serão discutidas as métricas que serão utilizadas, após serão explicadas algumas ferramentas de benchmarking para medir estas métricas e, por último, quais serão os cenários de testes. 4.1 MÉTRICAS De uma maneira geral, o desempenho das aplicações que rodam em um sistema é determinado pelo desempenho do disco, rede, memória, e processador. Aplicações específicas são mais influenciadas por um ou outro fator, dependendo das suas características. Assim, um programa que realiza cálculos intensivos depende mais do desempenho do processador do que da rede, situação que se inverte no caso de um servidor de arquivos, por exemplo. Como o objetivo da comparação quantitativa é medir o impacto no desempenho dos AVs, pretende-se obter métricas de desempenho dos recursos mencionados que sejam afetados pelos AVs. As métricas selecionadas foram: Disco - testes de escrita/leitura de um arquivo, abrir/fechar um arquivo, overhead de uma chamada de sistema, entrada/saída de um caracter por vez, um bloco de caracteres

40 40 e reescrita seqüencial. Testes de criação/leitura/exclusão de arquivos seqüenciais e randômicos; Memória - teste de memória, com operações de alocação, cópia de dados na memória; Rede testes para medir a taxa de transferência de dados na rede, via TCP e UDP, largura de banda; Processador - velocidade dos processos e performance do processador na criação de processos, threads e testes aritméticos. Este último, porém não será medido, pois não é afetado pelo AV. Somente foi citado porque sempre quando se expressa medir desempenho de processador relaciona-se a testes aritméticos, todavia não será o enfoque das métricas deste trabalho. 4.2 FERRAMENTAS DE BENCHMARKING A seguir serão descritas algumas ferramentas de benchmarking que permitem obter as métricas de desempenho do sistema computacional. Os resultados são utilizados para realizar as avaliações comparativas de desempenho destes sistemas. De acordo com Carter (2003), um conjunto de benchmarks consiste de uma série de programas que serão executados no sistema. Já no que diz respeito à avaliação, o responsável direto pela pontuação do sistema é o tempo que o sistema demora para executar os programas do conjunto de benchmarks. As ferramentas descritas nos subtópicos deste foram selecionadas pela ampla utilização em avaliações de desempenho, além de serem open sources, permitindo obter as métricas descritas na seção 4.1.

41 Lmbench É utilizado para comparar diferentes implementações de sistemas. É um benchmark que reporta o tempo de execução em microssegundos para cada microbenchmark que o compõe. É utilizado para analisar o desempenho de diferentes sistemas Linux. Além disso, é um benchmark open source (MCVOY & STAELIN, 1996). Possui a capacidade de avaliar a transferência entre dados e o processador, cache, memória, rede e disco. Inclui suporte a multiprocessadores, e é capaz de analisar a performance de sistemas paralelos e distribuídos (STAELIN, 2004). De acordo com Brown & Seltzer (1997) as características são: Largura de banda da leitura/escrita da memória: determina a largura de banda da memória através da repetição da soma de um grande vetor; Largura de banda da releitura do arquivo: mede a largura de banda alcançada, a leitura de arquivos do cache a partir do sistema de buffer do cache; Largura de banda da entrada/saída do cache; Latência do sistema de arquivos que fornece o tempo requerido para criar ou remover um arquivo de vários tamanhos; Latência de leitura da memória; Latência de comunicação interprocessos fornecendo o tempo necessário para chamar um processo para realização de tarefas. A principal desvantagem é a sua utilização em sistemas que não têm (ou não usam) hardware com tempo em microssegundos. Também é inconsistente no tratamento estatístico dos dados, pois ele captura o menor valor das repetições das medidas, intencionando o melhor resultado possível e ignorando os resultados com overhead (BROWN & SELTZER, 1997).

42 Sysbench O benchmark Sysbench foi desenvolvido para medir parâmetros importantes para um sistema que está executando um banco de dados sob carga intensiva. De acordo com Kopytov (2004) os testes medem as performances nos seguintes itens: CPU, escalonador (scheduler), E/S dos arquivos, alocação de memória e a velocidade de transferência da memória, além das performances de threads POSIX e de um banco de dados. CPU: calcula números primos até um valor máximo especificado pelo usuário, sendo que todos os cálculos são realizados utilizando 64 bits; Threads: vários threads são criados e eles competem entre si por mutex; Mutex: vários threads são criados e eles competem por mutex. Entretanto, o lock adquirido sobre o mutex é ganho por um período muito curto de tempo. Sua finalidade é examinar a desempenho da implementação dos mutexes; Memória: a memória é lida ou escrita de forma sequencial e os threads criados podem acessar tanto blocos de código globais quanto blocos de código locais; E/S de arquivos: vários tipos de operações de E/S em arquivos podem ser executadas. As operações incluem escritas, reescritas e leituras sequenciais, e leituras e escritas randômicas de arquivos; Banco de dados: operações comuns de bancos de dados (criação de tabelas, remoção de tabelas, inserção de dados e outras) são executadas para medir a performance de uma base de dados Bonnie++ É uma ferramenta que tem como objetivo realizar uma série de testes de disco e perfomance de sistemas de arquivos. De acordo com Coker (2008) os testes podem ser:

43 43 Testes de escrita seqüencial em arquivos: escrita de um caracter por vez (macro putc()), de um bloco de caracteres (função write()) e reescrita de blocos de caracteres (funções read(), lseek() e write()); Testes de leitura seqüencial de arquivos: leitura de um caracter por vez (macro getc()) e de blocos de caracteres (função read()); Testes de criação/leitura de arquivos randômicos: alguns processos são criados (em geral três) e executados em paralelo, criando o arquivo e escrevendo em partes aleatórias deste arquivo Iperf Foi desenvolvido para medir o desempenho de rede, como medir a taxa de TCP, UDP e desempenho (FREEBSD, 2006). O Iperf (IPERF, 2008) é uma ferramenta para medir largura de banda. Jperf pode ser associado com o Iperf para gerar os gráficos escritos em Java. A ligação de rede é delimitada, pois dois hosts que executam o Iperf. Esta ligação de rede pode medir: Latência (tempo de resposta ou RTT) pode ser medida com o comando ping; Jitter (variação de latência) pode ser medida com o teste Iperf UDP; Perda de pacotes pode ser também medido com um teste Iperf UDP; Largura de banda é medida através do teste de TCP; Utiliza as diferentes capacidades de TCP e UDP para fornecer estatísticas sobre os links de rede. Tem funcionalidade cliente e servidor, é um open source que é compatível em Linux, Unix e Windows Netperf

44 44 O Netperf pode ser utilizado para medir vários aspectos do desempenho da rede. O foco principal é a transferência de dados, resposta de desempenho utilizando TCP ou UDP. É uma ferramenta open source, e possui dois módulos: o netserver (servidor) e o netperf(cliente). É necessário disparar em uma máquina o servidor e na outra o cliente. É possível abrir duas conexões netserver na mesma máquina, mas precisam estar executando em portas diferentes (NETPERF, 2007). O Netperf é um benchmark usado para medir a performance de redes e dispositivos de redes (NETPERF, 2007). Os testes incluídos no Netperf incluem testes de throughput (vazão) e latência end-to-end (fim-a-fim). Esses testes realizam transferências de dados via protocolos TCP e UDP, tanto transferências unidirecionais quanto do tipo request/response, seguindo o modelo básico cliente-servidor. Transferências de dados via protocolos TCP e UDP unidirecionais e do tipo request/response sobre os protocolos IPv4 e IPv6 usando a interface Sockets; Transferências de dados via protocolos TCP e UDP unidirecionais e do tipo request/response sobre os protocolos IPv4 e IPv6 usando a interface XTI (X/Open Transport Interface); Transferências de dados em nível da camada de rede (link-level) unidirecionais e do tipo request/response usando a interface DLPI (Data Link Provider Interface); Sockets UNIX (Unix Domain Sockets); Transferências de dados via SCTP (Stream Control Transport Protocol) unidirecionais ou request/response sobre IPv4 e IPv6 usando a interface Sockets Ubench É um programa de benchmark que utiliza a capacidade de máquinas multiprocessadas. É uma ferramenta open source e pode ser compilado com os parâmetros escolhidos. O Ubench (UBENCH, 2005) faz testes de CPU e memória, estes divididos em duas partes. A primeira mede o desempenho da CPU através de operações matemáticas com números

45 45 inteiros e números de ponto flutuante. Já a segunda realiza uma série de alocações e cópias de dados na memória. Testes aritméticos: operações aritméticas com números inteiros e números de ponto flutuante por três minutos, usando vários processos; Testes de memória: operações de alocação de dados na memória e de cópia de dados da memória por outros três minutos, usando também vários processos. Ao final do processo, ele faz uma média aritmética entre os dois valores. Sendo assim ele disponibiliza três valores que são: o valor dos testes de CPU, memória e a média entre os dois valores, sendo que estes valores só servem para comparar sistemas entre si Considerações sobre as ferramentas de benchmarking A figura 11 mostra um resumo das ferramentas de benchmarking e o que se deseja avaliar, sendo separadas por processador, memória, disco e rede. Figura 11 - Resumo das ferramentas de benchmarking

46 46 As ferramentas que foram utilizadas são a Lmbench, Sysbench, Bonnie++, Iperf, e Netperf. Não será utilizada a ferramenta UBench, pois as outras ferramentas de processador e memória (Lmbench e a Sysbench) são mais completas. O Lmbench não será utilizado para medir as métricas de rede, visto que as outras ferramentas descritas são mais eficazes. As ferramentas disponibilizam vários testes para obtenção das métricas, mas somente utilizou-se as métricas mais pertinentes aquelas citadas na seção CENÁRIOS DE TESTES O objetivo da avaliação quantitativa é identificar qual o custo de desempenho de cada AV. As métricas de desempenho serão obtidas na camada de aplicação. Primeiro serão obtidos os dados de um sistema sem virtualização, onde as métricas serão medidas dentro do SO. Nos cenários com virtualização, as métricas serão obtidas dentro da camada de aplicação da MV de cada AV. Para a realização destes testes serão utilizadas as ferramentas de benchmarking (Lmbench, Sysbench, Bonnie++, Netperf, Iperf) para obter as métricas definidas, sendo que para cada ferramenta serão realizados dez testes, fazendo a média entre eles e o desvio padrão. Após será feito uma avaliação dos dados, para que nenhum teste tenha o desvio padrão superior a 10%, assim tendo dados consistentes. O resultado que será utilizado para obtenção dos resultados finais vai ser a média entre os dez testes. Os cenários serão separados em: Cenário 1 é o sistema computacional típico (Nativo), sem virtualização, conforme mostra a figura 12. As métricas serão medidas no SO; Figura 12 Cenário 1 - Sistema Computacional Típico

47 47 Configurações do cenário 1: o SO: Debian Lenny GNU/Linux 5.0 o Memória: 3 GB o Processador: Core 2 Duo o Disco: duas partições sda2: 210 GB sistema de arquivos ext3 sdb1: 512 MB área de swap Cenário 2 será instalado o Xen, e irá se medir as métricas com ferramentas de benchmarking, conforme mostra a figura 13. As métricas serão medidas dentro das aplicações de cada MV, ou seja somente nas MVs que forem DomU. Na Dom0 não vai ser medida porque é a camada de privilégio do Xen. Figura 13 Cenário 2 Ambiente de Virtualização Xen Configurações do cenário 2: o MMV: Xen 3.3 o SO Host: Não aplicável (o MMV é o próprio SO) o SO Guest: Debian Lenny GNU/Linux 5.0, kernel modificado para suportar o MMV Xen. o Memória SO host: 3 GB o Memória SOs guests: 512 MB o Processador: Core 2 Duo o Discos Virtuais: duas partições sda1: 15 GB sistema de arquivos ext3 sda2: 512 MB área de swap

48 48 Cenário 3 será instalado o UML e as métricas também serão medidas com ferramentas de benchmarking, conforme mostra a figura 14. As métricas serão medidas dentro das aplicações de cada MV. Figura 14 Cenário 3 Ambiente de Virtualização UML Configurações do cenário 3: o MMV: User Mode Linux o SO Host: Debian Lenny GNU/Linux 5.0. o SO Guest: Debian L enny GNU/Linux 5.0, kernel o Memória SO host: 3 GB o Memória SOs guests: 512 MB o Processador: Core 2 Duo o Discos Virtuais: duas partições sda1: 15 GB sistema de arquivos ext3 sda2: 512 MB área de swap 4.4 CONSIDERAÇÕES PARCIAIS Para as comparações quantitativas foram selecionadas métricas que têm como objetivo medir o impacto no desempenho dos AVs. A partir delas, foi feita uma pré-seleção das ferramentas de benchmarking que permitam obter as métricas selecionadas. Após são

49 49 descritos os cenários de testes que serão utilizados para coletar as informações para fazer a comparação entre os AVs. No próximo capítulo, serão mostrados os resultados obtidos com cada ferramenta de bechmarking nos cenários de testes definidos.

50 50 5 RESULTADOS DAS FERRAMENTAS DE BENCHMARKING As ferramentas de benchmarking foram escolhidas devido à sua ampla utilização em avaliações de desempenho, por serem ferramentas open source e que permitem medir as métricas selecionadas na seção 4.1. Buscando um resultado mais confiável, para todos os valores obtidos foram realizadas 10 execuções, e foi calculada a média entre eles. 5.1 PROCESSADOR Para obter as métricas de processador foram utilizadas as ferramentas de benchmarking Lmbench e Sysbench. Essas ferramentas obtêm diversas medidas que descrevem o desempenho do processador, sendo aqui apresentadas aquelas que correspondem às métricas selecionadas na seção 4.1. LMBENCH No Lmbench foram escolhidos os testes de fork+exit, fork+execve, fork+bin/sh, quem medem o desempenho do sistema na criação de processos. Foi utilizado a extensão lat_proc que tem como objetivo a criação de processos em três formas diferentes, cada um mais caro

51 51 do que o anterior. Os efeitos consistem em medir o tempo que leva para criar uma base de thread de controle. As formas são listadas e descritas abaixo: o fork+exit - cria um processo filho que encerra sua execução imediatamente após o seu início. Mede basicamente o custo de criação de um novo processo; fork+execve - cria um processo filho que executa uma nova aplicação (um programa que exibe Hello, world! ). Este teste mede o custo de criação do processo e da carga de uma aplicação simples. fork+bin/sh - cria um processo filho, que invoca um shell (interpretador de comandos) para que este execute uma aplicação. Mede o custo de se criar um novo processo que invoca uma aplicação complexa. Na figura 15 tem-se os resultados dos testes de processador do Lmbench, os resultados também podem ser observados no anexo A Teste de processador (Microssegundos). Teste de Processador - Lmbench Criação de Processos - Microssegundos - Quanto menor melhor Fork+exit Fork+execve Fork+/bin/sh Sem Virtualização Xen UML Figura 15 Teste de Processador Lmbench Pode-se observar na figura 15 que o custo de criação de processos do UML é maior do que o custo de criação do Xen. Comparativamente, a diferença em termos de execução de uma nova aplicação é menor do que o custo de criação. O tempo no UML é aproximadamente cinco vezes maior no fork+exit em comparação ao Xen, e aproximadamente três vezes no fork+/bin/sh. O Xen tem os dados mais próximos do ambiente sem virtualização.

52 52 SYSBENCH Para análise das métricas de processador, foram feitos os testes de: CPU - cada pedido consiste no cálculo dos números primos até o valor especificado (foi utilizado 20000). Todos os cálculos são realizados utilizando inteiros de 64 bits; Thread cria um determinado número de threads que concorrem por um determinado numero de mutexes (semáforos). Nos testes realizados, foram criadas 64 threads e dois mutexes. Cada thread executa um laço em que ela trava o mutex, dá sua vez na CPU (permitindo que outra thread seja escalonada) e destrava o mutex quando é reescalonada. Os testes realizados executam requisições, sendo que cada requisição corresponde a executar o laço 100 vezes. Na figura 16, têm-se os resultados dos testes de processador realizados com a ferramenta de benchmarking Sysbench, os resultados também podem ser observados no anexo B Teste de processador. Teste de Processador - Sysbench 500 Processador - Microssegundos - Quanto menor melhor Thread CPU Sem Virtualização XEN UML Figura 16 Teste de Processador - Sysbench Conforme as figuras 15 e 16 pode-se observar que o Xen obteve melhor desempenho com relação aos testes de processador. Já era esperado que o UML obtivesse menor desempenho com relação ao Xen, isso ocorreu porque o Xen utiliza a técnica de paravirtualização e é executado na camada de hardware, sendo assim todos os processos têm

53 53 acesso direto ao hardware. Logo, somente passarão pelo MMV se ocorrer alguma anomalia, tornando-se assim mais eficiente. Já no UML, todos os programas do usuário fazem requisições ao kernel e este vai passar todas as requisições ao kernel da máquina hospedeira, fazendo a comunicação com o hardware; sendo assim, o processamento tem menor desempenho.

54 MEMÓRIA Para obter as métricas de memória foram utilizadas as ferramentas de benchmarking Lmbench e Sysbench. Essas ferramentas obtêm diversas medidas que descrevem o desempenho de memória, sendo aqui apresentadas aquelas que correspondem às métricas selecionadas na seção 4.1. LMBENCH Para análise das métricas de memória, foram feitos primeiramente os testes de largura de banda do bcopy, que tem como objetivo determinar a largura de banda da memória executada pela rotina de cópia de memória. As formas utilizadas da função bcopy são: unrolled bcopy - é uma implantação otimizada manualmente, e libc bcopy - é a versão da biblioteca C padrão. Na figura 17, tem-se os resultados dos testes de memória (unrolled bcopy, libc bcopy) do Lmbench, os resultados também podem ser observados no anexo A Teste de memória.

55 55 Teste de Memória - Lmbench 1400 Memória - MB/s - Quanto maior melhor Unrolled bcopy Libc bcopy Sem Virtualização Xen UML Figura 17 Teste de Memória Lmbench Para a figura 17, pode-se observar que o Xen obteve desempenho superior com relação ao UML. Pode-se notar também que a implantação feita manualmente é mais lenta do que a implementação que utiliza a biblioteca C padrão. Estes dados são para uma transferência de 128 Megabytes de dados. Para obter as outras métricas de memória, foram feitos os testes que são: Banda de leitura mede o tempo para ler os dados no processador. Calcula a soma de uma matriz de valores inteiros. Ele acessa cada quatro palavras. Banda de escrita - mede o tempo para escrever dados na memória. Atribui um valor constante a uma matriz de memória de valores inteiros. Ele acessa cada quatro palavras. Banda de leitura/escrita mede o tempo para ler os dados na memória, e em seguida, escrever os dados para a mesma localização da memória. Para cada elemento em um array ele adiciona o valor atual de uma soma em execução antes da atribuição de uma nova (constante) valor para o elemento. Ele acessa cada quatro palavras. Na figura 18, têm-se os resultados dos testes de memória (Banda de leitura, Banda de escrita, Banda de leitura/escrita) do Lmbench, os resultados também podem ser observados no anexo A Teste de memória.

56 56 Teste de Memória - Lmbench Memória - MB/s - Quanto maior melhor Banda de leitura Banda de escrita Banda de leitura/escrita Sem Virtualização Xen UML Figura 18 Teste de Memória Lmbench Pode-se observar na figura 17 e 18, que o Xen obteve desempenho ligeiramente melhor do que o UML, porque seus resultados chegaram mais próximos dos resultados sem virtualização. Os comentários gerais serão apresentados junto com os resultados da figura 19. SYSBENCH Para fazer a análise das métricas de memória, foram feitos os testes com operações de leitura de dados na memória e escrita de dados na memória. A realização destes testes é executada de maneira que a memória é lida ou escrita de forma seqüencial e os threads. Para realização destes testes, foi utilizado um arquivo de 4095 Megabytes para transferência, e um foi o número de threads utilizadas. Na figura 19 tem-se os resultados dos testes de memória (leitura de dados na memória, escrita de dados na memória) do Sysbench. Os resultados também podem ser observados no anexo B Teste de memória.

57 57 Teste de Memória - Sysbench 200 Memória - MB/sec - Quanto maior melhor Leitura de dados na memória Escrita de dados na memória Sem Virtualização XEN UML Figura 19 Teste de Memória - Sysbench Pode-se observar que a perda de desempenho em operações envolvendo memória é pequena. A diferença de desempenho observada no Sysbench ocorre porque o teste do Sysbench executa uma transferência de dados em blocos de 1 KB, e entra a leitura/escrita de cada bloco são executados operações envolvendo mutexes. Conforme os resultados mostrados na figura 16, os custos associados a operações com mutexes variam de acordo com o uso de virtualização, o que explica as diferenças encontradas com relação aos testes do Lmbench. Os resultados mostrados nas figuras 17, 18 e 19 evidenciam que os AVs têm pouco impacto sobre as operações que usam a memória. Isso era esperado, pois nenhum dos AVs estudados requer a tradução dos endereços de memória gerados pelos processos de usuário no sistema guest, como poderia acontecer em um MMV que fizesse emulação de hardware. As diferenças maiores se verificam em operações de gerenciamento de memória, como alocação e desalocação de memória e carga de tabelas de páginas. As pequenas variações observadas nos testes realizados devem-se a outros overheads do sistema, como no escalonamento dos processos.

58 DISCO Para obter as métricas de disco foram utilizadas as ferramentas de benchmarking Sysbench e Bonnie++. Essas ferramentas obtêm diversas medidas que descrevem o desempenho de disco, sendo aqui apresentadas aquelas que correspondem às métricas selecionadas na seção 4.1. SYSBENCH Para análise das métricas de disco, foram feitos os testes de E/S de arquivos. As operações utilizadas para os testes de E/S foram: Escrita/Leitura Randômica, Escrita Randômica, Leitura Randômica, Leitura Seqüencial, Reescrita Seqüencial, Escrita Seqüencial, pois são as operações disponíveis da ferramenta de benchmarking Sysbench para testes de E/S, e com estas operações consegue-se medir as métricas selecionadas na seção 4.1. E/S de arquivos este modo de teste produz diversos tipos de arquivos de E/S, os utilizados foram: Escrita/Leitura Randômica, Escrita Randômica, Leitura Randômica, Leitura Seqüencial, Reescrita Seqüencial, Escrita Seqüencial. Ao preparar uma fase, o Sysbench cria uma série de arquivos com um tamanho total (nos teste foi utilizado um arquivo de 3 GigaBytes). Depois, na fase de execução, cada thread (16 foi o número de threads utilizadas nos testes) executa as operações de E/S sobre o arquivo. Na figura 20, têm-se os resultados dos testes de disco realizados com a ferramenta de benchmarking Sysbench, os resultados também podem ser observados no anexo B Teste de Disco.

59 59 Teste de Disco - Sysbench Teste de E/S - MB/sec - Quanto maior melhor Escrita Seqüencial Reescrita Seqüencial Leitura Seqüencial Escrita Randômica Leitura Randômica Escrita/Leitura Randômica Sem Virtualização XEN UML Figura 20 Teste de Disco Sysbench Para cada teste se aplica uma carga diferente sobre o sistema de arquivos, o que significa que os resultados de testes distintos não podem ser diretamente comparados entre si. Por exemplo, o teste de escrita seqüencial envolve operações de escrita, enquanto o teste de escrita randômica envolve operações. Ainda assim, pode-se concluir que a escrita no UML tem maior custo, conforme mostra a figura 20, pois o UML perde mais desempenho com relação ao Xen em todos os testes que envolvem escritas. A penalidade para leituras do disco é menor, mas o Xen ainda é melhor do que o UML em todos os casos. BONNIE++ Para fazer a análise das métricas de disco, foram feitos testes de performance dos sistemas de arquivos, representados na figura 21, e os testes de criação/leitura/exclusão de arquivos seqüenciais e randômicos, representados na figura 22. O Bonnie++ foi iniciado através do comando bonnie++ -u root -n 512 -s 512 -r 256, indicando que, em cada teste, o número de arquivos utilizados para a criação de um arquivo teste foi 512 arquivos (-n 512), foram utilizados também arquivos de 512 MBytes (- s 512), 256 MBytes (-r 256) de memória RAM e os direitos do usuário como root (-u root). Para a escrita seqüencial existem três tipos de testes de escritas que podem ser realizados (COKER, 2008):

60 60 Por caracter: a função putc() é utilizada para preencher todo o arquivo de caractere em caractere; Por bloco: o arquivo é preenchido utilizando blocos de tamanho igual ao tamanho do bloco do sistema de arquivos; Reescrita: cada bloco do arquivo é lido, seu conteúdo é embaralhado e depois reescrito no disco. Este teste comprova a eficiência do cache do sistema de arquivos e da velocidade de transferência de dados. E para a Leitura seqüencial pode ser realizado dois tipos de testes (COKER, 2008): Por caractere: o arquivo é lido de caractere em caractere utilizando getc(); Por bloco: o arquivo é lido utilizando blocos do mesmo tamanho dos blocos do sistema de arquivos. Na figura 21, tem-se os resultados dos testes de disco (Escrita Seqüencial Caracter, Escrita Seqüencial Blocos de Caracteres, Escrita Seqüencial Reescrita, Leitura Seqüencial Caracter, Entrada Leitura Blocos de caracteres) da ferramenta de benchmarking Bonnie++. Os resultados também podem ser observados no anexo C Teste de Performance do Sistema de Arquivos. Teste de Disco - Bonnie Performance do Sistema de Arquivos (K/sec) - Quanto maior melhor Escrita Seqüencial - Caracter Escrita Seqüencial - Blocos de caracteres Escrita Seqüencial - Reescrita Leitura Seqüencial Caracter Leitura Seqüencial Bloco Sem Virtualização XEN UML Figura 21 Teste de Disco (Desempenho do sistema de arquivos) Bonnie++

61 61 Pode-se observar na figura 21 que o Xen obteve melhores resultados do que o UML, comprovando o verificado no teste com o Sysbench. A diferença de desempenho com o Bonnie++ foi maior, pois os testes desta ferramenta impõem mais carga ao sistema do que os testes do Sysbench. Para a realização dos testes de criação de arquivos randômicos e leitura de arquivos randômicos são criados alguns processos (em geral são três) que são executados em paralelo, criando o arquivo e escrevendo em partes aleatórias deste arquivo. Os testes de criação e leitura de arquivos seqüenciais seguem o mesmo processo do que os arquivos randômicos, apenas em vez de escrever em partes aleatórias do arquivo, se escreve seqüencialmente dentro deste arquivo. Na figura 22 tem-se os resultados dos testes de disco (Criação de arquivos seqüenciais, Leitura de arquivos seqüenciais, Exclusão de arquivos seqüenciais, Criação de arquivos randômicos, Leitura de arquivos randômicos, Exclusão de arquivos randômicos) da ferramenta de benchmarking Bonnie++. Os resultados também podem ser observados no anexo C Teste de criação/exclusão. Teste de Disco - Bonnie++ Criação/Exclusão (K/sec) - Quanto maior melhor Criação de arquivos seqüenciais Leitura de Exclusão de arquivos arquivos seqüenciais seqüenciais Criação de arquivos randômicos Leitura de arquivos randômicos Exclusão de arquivos randômicos Sem Virtualização XEN UML Figura 22 Teste de Disco Bonnie++ Pode-se observar na figura 22, que os testes de criação, leitura e exclusão de arquivos seqüenciais têm melhor desempenho com relação aos testes de criação, leitura e exclusão de arquivos randômicos, isso já era esperado, o acesso seqüencial a arquivos aproveita melhor os buffers de dados e por isso requer menos acessos a disco do que o acesso randômico.

62 62 De acordo com as figuras 20, 21 e 22, pode-se notar que o Xen obteve melhor desempenho nos testes de Disco, isso já era esperado, pois o Xen utiliza a técnica de paravirtualização e é virtualizado na camada de hardware, assim o SO convidado sabe que o disco é compartilhado e realiza diretamente o acesso ao disco (sem interferência do MMV), bem como aos demais dispositivos (mouse, teclado,...). O MMV somente controla a ordem de acesso, no caso de múltiplos SOs convidados em execução simultaneamente. Já no UML, o SO convidado enxerga o disco para seu uso exclusivo. Assim, sempre que o sistema realiza uma chamada de sistema para acesso ao disco, o MMV deve capturar essa chamada, interpretá-la e repassá-la para que o sistema anfitrião execute a operação. Logo, o resultado da chamada de sistema é então repassado para o SO convidado, sendo assim o UML tem perda de desempenho. Em situação onde o desempenho do acesso a disco é um fator critico (como no caso de servidores de arquivos), pode-se dizer que o UML não é uma boa opção.

63 REDE Para obter as métricas de rede foram utilizadas as ferramentas de benchmarking Iperf e Netperf. Essas ferramentas obtêm diversas medidas que descrevem o desempenho de rede, sendo aqui apresentadas aquelas que correspondem às métricas selecionadas na seção 4.1. O ambiente de rede utilizado foi uma rede Ethernet com velocidade de 100 Mbps e os computadores foram conectados através de um switch. Enquanto estavam sendo executados os testes de rede, a rede estava com baixo tráfego. IPERF Esta ferramenta de benchmarking foi utilizada para obter as métricas de rede. Foram feitos testes de desempenho da rede na transferência de dados via TCP. A realização dos testes de TCP transmite dados (vetor de 8 KB para TCP) durante 10 segundos, e mede o total de bytes transmitidos e a largura de banda durante a transmissão. Para a realização destes testes foram utilizados dois computadores: um como servidor, e outro como cliente. Primeiramente foi inicializado o computador definido como servidor (um computador com sistema Debian Lenny): Para os testes de TCP o servidor foi inicializado com o comando iperf s. Após, foi executado no computador cliente (o que possui os AVs (Xen/UML)) os comandos de testes: Para os testes de TCP foi utilizado o comando iperf -c (sendo que o IP é o IP do servidor). Na figura 23, têm-se os resultados dos testes de rede de TCP, da ferramenta de benchmarking Iperf. Os resultados também podem ser observados no anexo D Teste de Rede.

64 64 Figura 23 Teste de Rede (TCP) - Iperf Pode-se observar na figura 23, que os valores ficaram semelhantes, isso ocorreu pela baixa carga de dados transferidos. Os comentários gerais serão feitos junto com os comentários das figuras 24 e 25, ao final desta seção. NETPERF Esta ferramenta de benchmarking foi utilizada para obter as métricas de rede. Foram feitos testes de transferência de dados na rede, via TCP/UDP. Para isso foram feitos testes de TCP/UDP Stream - que mede fluxo (ou stream) de dados de TCP/UDP na rede, TCP/UDP Request/Response que faz a solicitação e resposta de TCP/UDP. Para a obtenção das métricas de TCP/UDP, foram utilizadas duas máquinas físicas, uma como servidor e outro como cliente. Primeiramente foi inicializado o computador definido como servidor (inicializado com o comando netserver, em um computador com o sistema Debian Lenny), e após no computador cliente foi realizada as operações de: Para os testes de TCP_STREAM o cliente foi inicializado com o comando netperf -H , sendo que o IP é o IP do servidor, Para os testes de UDP_STREAM o cliente foi inicializado com o comando netperf -H t UDP_STREAM, sendo definido o tipo de operação com o comando t UDP_STREAM, é a especificação do teste.