Virtualização em Linux hoje e amanhã
Antes de mais nada, é importante notar que eu estava convencido a postar esta entrada no blog em inglês, até mesmo porque minhas postagens em inglês recebem muito mais leitura do que as postagens em português (bem mais, de 15 a 20 vezes mais, para ser sincero), mas decidi não fazê-lo por achar que seria interessante ter esse conteúdo em português, visto que eu mesmo procurei muito por algo do tipo e não consegui encontrar nada interessante.
Outro ponto importante a ser levando em consideração é que eu não sou um cientista da computação, um físico, um matemático e nem mesmo estudo profissionalmente ou a fundo sistema operacionais em um nível mais baixo. O que eu sou, isso sim, é um entusiasta do software livre que tem muita vontade de aprender sobre novas tecnologias e gosta de estudá-las um pouco mais do que a maioria das pessoas.
Dito isso, obviamente, absorva o conteúdo que irei escrever aqui com isso em mente e, também devido a isso, entenda que, como não sou e nem pretendo ser o dono da verdade, possivelmente muita coisa do que eu disser aqui pode não estar completamente correta. Cabe a você, leitor, pesquisar e tirar suas próprias conclusões com base no conteúdo aqui apresentado e a enorme quantidade de material adicional existente por aí.
Deixando os avisos de lado, é evidente que para quem quer que tenha acompanhando minhas postagens no blog ou no Twiiter/identi.ca que eu me interesso muito pelo assunto virtualização. Mais especificamente, tenho me interessado muito ultimamente pela solução de virtualização KVM. Não somente eu, aliás, visto que a mesma está recebendo colaborações maçiças de inúmeros grandes nomes e empresas do cenário do software livre (Red Hat, IBM, Intel, AMD, etc).
É fácil perceber, porém, que ainda existe muito preconceito em relação a essa solução. E nem todo o preconceito ainda existente é errado pois, na verdade, em relação a performance, outras soluções completamente baseadas no conceito de para-virtualização, como o Xen, por exemplo, ainda são mais interessantes.
Porém, no estágio atualmente de desenvolvimento, o KVM já evoluiu muito e não é mais aquele brinquedo feio relegado aos testes informais de final de semana, que só nos são interessantes para sabermos que os mesmos existem, mas que, no mundo real, não possuem muita utilidade.
Isso se deve a, em minha opinião, dois motivos : primeiro, devido ao interesse pelas tecnologias de virtualização ser tão alto, isso ter levado os fabricantes de hardware a se concentrarem em oferecer soluções que entregam uma base física muito mais bem preparada para essas tecnologias e, segundo, devido aos desenvolvedores do KVM que, entendendo que esse era o futuro, se concentrarem em resolver problemas mais importantes ao invés de tentar contornar limitações de hardware que eles sabiam que em breve começariam a ser removidas.
Mérito seja dado, o Xen inovou muito e reavivou uma enorme onda de interessados nas vantagens da virtualização, trazendo, de fato, com o conceito de para-virtualização, a virtualização utilizável para o mundo x86 e, com isso, para as massas. Porém, isso teve um custo, já que, por se dedicar muito a explorar as possibilidades desse conceito, o Xen ficou preso a uma base extremamente mais complexa e, por isso, com uma menor probabilidade de ser oficialmente aceita como cidadão de primeiro nível na terra do kernel.
O KVM, por outro lado, tomou uma posição mais radical, decidindo desde o início que, para conseguir um design mais simples e um ritmo de desenvolvimento bem mais rápido, simplesmente deixaria de lado toda essa história de para-virtualização e já iniciaria como um grande usuário das então recém lançadas tecnologias de virtualização assistidas por hardware.
Logicamente, hoje em dia, temos o KVM portado e funcional em plataformas PowerPC e S/390, mas, na época, isso se resumiu a adotar e depender pesadamente das tecnologias VMX da Intel e SVM da AMD, as quais essas empresas tinham acabado de implementar em suas novas linhas de processadores. Por algum tempo, inclusive, foi bastante complicado encontrar sistemas oficialmente suportados pelos grandes integradores de hardware que fornecessem soluções de hardware baseadas nesses novos processadores.
Atualmente, é claro, isso já é passado e a maioria dos sistemas entry-level oferecido pelos integradores de hardware, bem como soluções de desktop corporativos, já incluem processadores que, no mínimo, suportam essas tecnologias (a primeira onde da virtualização recente em hardware x86), inclusive o laptop a partir do qual eu escrevo esse texto e o computador de mesa self-made aqui ao meu lado. Ou seja, já virou objeto comum.
O Xen, por estar focado em virtualização baseada em sua menina dos olhos, a para-virtualização, demorou um pouco mais para tirar proveito dessas novas tecnologias e entrou na briga oferecendo uma solução de virtualização assistida por hardware bem mais tarde, com o lançamento de sua série 3.x, que inclusive teve que receber modificações massivas para se adaptar a esse novo paradigma.
Hoje, o Xen suporta tanto para-virtualização quanto virtualização assistida por hardware, mas ainda sofre de diversos problemas estruturais que o impedem de ser aceito como um cidadão de primeiro nível oficialmente no kernel Linux. Sim, todos os usuários do Xen atualmente ou sujam suas mãos integrando-o manualmente em suas distribuições ou dependem de um trabalho hercúleo das distribuições GNU/Linux para mantê-lo integrado a seus núcleos, dependendo de forward-ports de código baseado no kernel 2.6.18 intermináveis.
Lógico, alguns podem se dar ao luxo de adquirir a versão comercial do Xen diretamente da XenSource/Sun, mas a partir desse ponto eu já considero que saímos do terreno das soluções abertas/livres e entramos no terreno de soluções comerciais, as quais, sinceramente, não me agradam. Não por custo ou por ideologia, mas sim porque, via de regra, simplesmente não tem como alcançar o nível de maturidade das soluções totalmente abertas/livres.
É importante notar que a técnica de para-virtualização só funciona para virtualizar sistemas operacionais hóspedes que possam ser modificados de forma a colaborar com o sistema operacional hospedeiro. Dessa forma, por motivos óbvios, quaisquer sistemas operacionais de código-fonte fechado, como os sistemas operacionais da família Windows da Microsoft, não conseguem obter vantagem dessa técnica.
Ou seja, na prática, o Xen só passou a ser uma plataforma de virtualização realmente multiplataforma (suportando sistemas operacionais de código-fonte fechado e sistemas operacionais de código-fonte aberto) a partir da série 3.x. O KVM, por outro lado, nasceu já com uma natureza multiplataforma nesse sentido, visto que, desde sempre, dependeu da existência das tecnologias de virtualização assistidas por hardware, as quais não demandam a modificação do sistema operacional hóspede.
Exatamente por depender das tecnologias de virtualização assistidas por hardware e não suportar inicialmente o conceito de para-virtualização, o KVM sempre entregou uma performance inferior ao Xen, visto que, em um ambiente que utiliza tecnologias de virtualização assistidas por hardware, o I/O do sistema operacional hospedeiro é interceptado e tratado por drivers no hypervisor, os quais na verdade emulam um driver real, obviamente não fornecendo a mesma performance de um driver real.
Inclusive, ao menos até o momento, o Xen também utiliza, para sua implementação de virtualização assistida por hardware, os drivers emulados fornecidos pelo QEMU, da mesma forma que o KVM. Ou seja, ao menos em relação a performance de I/O (dispositivos de blocos/discos e rede), a implementação de virtualização assistida por hardware do Xen e o KVM eram semelhantes.
Porém, particularmente, eu acredito que a percepção de que a performance inferior das tecnologias de virtualização assistidas por hardware seja uma verdade imutável esteja mudando e, a médio prazo, não mais será uma verdade absoluta.
Já há algum tempo, o KVM vem adotando técnicas de para-virtualização onde a mesma é perceptivelmente necessária (não em toda a sua implementação de virtualização, como é o caso do Xen). Por exemplo, desde a versão 13 (e já estamos na versão 84 atualmente) o KVM começou a incluir suporte rudimentar a alguns conceitos de para-virtualização, sendo que a partir da versão 61 o mesmo acrescentou suporte a pvclock, ou seja, para-virtualização do relógio do sistema operacional, para eliminar problemas de sincronização entre o hospedeiro e o sistema operacional hóspede.
Adicionalmente, a partir da versão 64, foi acrescentado suporte a para-virtualização de MMU (Memory Management Unit, ou Unidade de Gerenciamento de Memória). É interessante notar que, desde 2007, já haviam patches disponíveis (os quais, posteriormente, foram incorporados a árvore oficial de desenvolvimento) para implementar suporte a para-virtualização no KVM.
Na época, Ingo Molnar, da Red Hat, enviou seus patches para acrescentar suporte a para-virtualização no KVM indicando benchmarks bastante interessantes. Basicamente, com os patches aplicados, alguns cenários com testes de mudança de contexto no kernel apresentaram uma melhora de quatro vezes (400%) em relação a execução dos mesmos sem tais patches.
E, nos cenários que os patches em questão acrescentaram o menor ganho de performance em mudanças de contextos, ainda assim o ganho de performance foi da ordem de 30% em relação ao KVM sem tais patches aplicados. Ou seja, claramente, uma melhora significativa. Desde então, esses patches foram melhorados e incluídos oficialmente no KVM e muita coisa foi melhorada, aumentando ainda mais os benefícios trazidos.
Desde a versão 60 do KVM, foi incluído também suporte a VirtIO, ou seja, seguindo a tradição de utilizar para-virtualização somente onde o uso da mesma realmente faz sentido sem causar efeitos colaterais negativos, os desenvolvedores do KVM incluíram drivers (módulo de kernel) para-virtualizados para acesso a dispositivos de blocos (virtio_blk) e dispositivos de rede (virtio_net), efetivamente removendo a dependência dos drivers emulados fornecidos pelo QEMU.
Já há algum tempo atrás, Avi Kivity, líder no desenvolvimento do KVM, postou em seu blog um texto afirmando que a para-virtualização estava morta. Exageros a parte, se analisarmos os argumentos que ele utiliza, podemos ver claramente que o avanço dos fabricantes de processadores irá nos levar rapidamente a um patamar onde realmente se preocupar com para-virtualização não será mais algo tão importante.
Em seu post, Avi comenta que a combinação de paginação de memória implementada em hardware através das tecnologias NPT (Nested Paging Tables) da AMD ou EPT (Extended Page Tables) da Intel, junto com o suporte a páginas de memória grandes (large pages) entrega performnce equivalente ou, em alguns casos, ultrapassa a performance da para-virtualização em muitos cenários.
Segundo Avi, o custo de se comunicar com o hypervisor é simplesmente maior do que deixar que o hardware atual que implementa tais tecnologias gerencie tudo isso de forma transparente, mesmo ainda antes de levar em consideração os custos envolvidos na para-virtualização, como chamados de sistema (syscalls) mais lentas.
Ainda segundo Avi, o KVM, mais uma vez, entendendo essa segunda onda da virtualização suportada pelos processadores mais atuais, refletiu a obsolescência planejada da para-virtualização de MMU em seu design, implementando o suporte a esse recurso de forma que tal suporte pudesse ser habilitado ou desabilitado de forma dinâmica.
Ou seja, expondo esse suporte aos sistemas operacionais hóspedes e fornecendo aos mesmos performance melhorada quando o hardware do hospedeiro suporta tais tecnologias, mas lidando de maneira amigável com hospedeiros que não possuem suporte a essa tecnologia, utilizando para-virtualização de MMU, nesse caso.
Outro ponto interessante em relação as escolhas de design acertadas do KVM em comparação com o Xen é a questão do I/O. Em outro post em seu blog, Avi comenta sobre a questão da mantenabilidade em contraste com a questão da performance.
Em seu post, Avi cita que I/O no KVM é realizado no contexto do hypervisor, mantendo performance completa. Como o Xen, o KVM reutiliza a pilha de I/O do kernel Linux, porém, a reutiliza de forma que os usuários possam desfrutar das mais novas melhoras no kernel nesse departamento, bem como dos mais novos drivers para novos dispositivos.
O que é interessante notar, no entanto, é que o Xen, apesar de também realizar I/O no contexto do hypervisor, como Avi nota, possui o problema adicional de não ter resolvido por completo o problema da mantenabilidade, visto que, oficialmente, ainda está preso ao kernel 2.6.18, a última versão para a qual a XenSource (criadora do Xen), antes de ser adquirida pela Sun Microsystems, portou oficialmente os patches do Xen.
Versões dos patches do Xen para núcleos mais novos são na verdade um hack temporário, um forward-port do código-fonte baseado no kernel 2.6.18, adaptado para núcleos mais novos. Pessoalmente, eu somente conheço forward-ports adaptados para o kernel 2.6.26, o mesmo que o Debian, por exemplo, está utilizando, o qual, aparentemente, foi um esforço realizado pelo pessoal da Novell.
O problema é que o Xen, apesar de ter saído na frente do KVM e ter alguns anos de vantagem em relação ao mesmo, agora está perdendo terreno, visto que sua equipe de desenvolvimento está bastante atarefada portando o código para funcionar com base na nova estrutura genérica de para-virtualização do kernel Linux, o paravit_ops.
O paravirt_ops foi criado como uma resposta a crescente demanda de utilização de para-virtualização e como maneira de se ter somente um único framework genérico para essa necessidade, visto que muitas soluções de virtualização estavam tendo seus esforços duplicados, cada qual tendo que implementar seu próprio framework de para-virtualização.
Exatamente por ter escolhido iniciar toda sua implementação de para-virtualização como um projeto isolado do kernel Linux, sem as vantagens de se ter a crítica de diversos desenvolvedores competentes do kernel questionando suas decisões de design, o Xen está agora pagando o preço, tendo um tremendo trabalho para adaptar seu código a esse novo framework genérico introduzido relativamente recentemente ao kernel Linux.
E o KVM, não vai precisar também se adaptar ? Não, pois, como citei, o KVM não utiliza para-virtualização completamente em sua implementação de virtualização, mas sim somente nos pontos específicos onde a mesma faz mais sentido. E, ao contrário do Xen, o KVM foi desenvolvido desde o início dentro da comunidade de desenvolvimento do kernel Linux.
Ou seja, desde o início, por ter a crítica dos desenvolvedores do kernel Linux em todo o seu processo de desenvolvimento, o KVM é uma solução com um design mais do que aprovado pelos desenvolvedores do kernel, tanto que, desde a versão 2.6.20 do kernel Linux, está incluído oficialmente no kernel, sendo a primeira solução de virtualização nativa em Linux que eu acredito que tenha um brilhante futuro.
E, por estar ativamente sendo desenvolvido dentro da comunidade de desenvolvimento do kernel, recebendo os olhares e as dicas de todos os que da mesma participam, é uma solução que não lhe obriga utilizar um kernel obsoleto para ter uma estabilidade um pouco mais garantida, como é o caso do Xen.
Inclusive, o Xen foi removido oficialmente do Fedora 9 na época em que o mesmo foi lançado, exatamente por não existir um porte oficial do mesmo para o kernel utilizado por padrão por essa distribuição GNU/Linux e os desenvolvedores da mesma não acreditarem que seria correto perder ainda mais tempo tentando manter viva uma árvore de desenvolvimento (através de novos forward-ports) que está fadada a morrer logo mais, visto que o desenvolvimento da base Xen que será utilizada futuramente está ocorrendo atualmente no ramo que está portando o código Xen para o framework paravirt_ops.
Em contraste, o KVM continua se beneficiando dos numerosos recursos do kernel Linux, tendo ganhado sem precisar fazer esforço algum todas as virtudes do código desse kernel, como gerenciamento de energia avançado, suporte a suspensão/hibernação e diversas outras funcionalidades interessantes.
Resumindo, o KVM está sendo desenvolvido no mesmo ritmo frenético do kernel Linux, até mesmo porque está integrado completamente ao mesmo, enquanto o Xen, ao menos por enquanto, terá que suar bastante a camisa para se adaptar aos padrões que inicialmente optou por não se importar em seguir, para somente depois de todo esse trabalho, começar a pensar em convencer a equipe de desenvolvimento do kernel Linux a aceitar sua integração a árvore oficial de desenvolvimento do kernel.
É compreensível, agora, todo o burburinho que está ocorrendo ao redor do KVM e toda a preocupação e investimento das grandes empresas do software livre em apoiar o desenvolvimento do mesmo ? Particularmente, eu acredito que não há muitas dúvidas sobre o que o futuro da virtualização em Linux nos reserva : a mesma será baseada em KVM.
E você, qual sua opinião sobre esse assunto ? Importa-se de deixar seu comentário aqui e enriquecer esse post com suas observações, complementado as informações aqui expostas ? 
Recent Comments