Linux no despertar da era virtual
Vários em um
CAPA
A virtualização pode economizar tempo, dinheiro e trabalho,
mas é necessário usar a ferramenta certa para a tarefa.
por Wilhelm Meier e Torsten Kockler
34
http://www.linuxmagazine.com.br
Virtualização | CAPA
C
om certeza você pode usar seus ciclos de CPU para
buscar formas de vida extraterrestres, como demonstrou
o projeto SETI@Home, mas isso não é tudo. Quando
um computador é incapaz de explorar todo o potencial de
uma CPU moderna, você pode deixar vários computadores
tentarem. Múltiplos servidores virtuais num pequeno número
de máquinas físicas compõem uma solução para melhorar o
uso dos recursos de hardware, ao mesmo tempo consolidando
o panorama do sistema.
O tema de capa deste mês é a virtualização no Linux.
Apresentaremos o popular monitor de máquinas virtuais Xen,
e examinaremos também a ferramenta alternativa de virtualização Vserver. Por último, mostraremos um exemplo de
virtualização no mundo real com o VMware ESX Server.
Virtualização é uma das palavras em voga atualmente, apesar de a idéia não ser exatamente nova. Desde a introdução
da linguagem de programação Java, a maioria das pessoas usa
pelo menos uma máquina virtual. E talvez alguns leitores
se lembrem do sistema UCSD Pascal p, uma das primeiras
máquinas virtuais para Pascal.
A virtualização na camada do sistema operacional data de
um bom tempo atrás. A primeira máquina virtual foi o VM/
CMS da IBM, do final da década de 1960. E essa tecnologia
ainda é usada atualmente: com o nome de z/VM, ela suporta
o uso eficiente do Linux nos servidores IBM zSeries.
Máquinas virtuais
Uma máquina virtual normalmente emula um ambiente de
execução. Isso é, ela emula a interface com esse ambiente.
(Diferentemente da emulação, a simulação refletiria todos
os estados internos do ambiente ao mesmo tempo).
Na linguagem de programação Java, fala-se sobre a Máquina Virtual Java (JVM, na sigla em inglês), uma emulação
de uma máquina hipotética baseada em especificações estritas [1]. Os estados internos não são realmente importantes
para o usuário. A JVM funciona como um processador virtual
dentro de um ambiente virtual de execução.
Esse tipo de emulação também é possível num sistema computacional completo. A tarefa normalmente não é gerenciada
pelo hardware, mas requer um componente de hardware especial
para esse suporte – um tipo de sistema operacional rudimentar
conhecido como Monitor de Máquina Virtual (VMM, na sigla
Debian
FreeBSD
Gentoo
Kernel
Linux
Kernel
FreeBSD
Kernel
Linux
Monitor de Máquina Virtual (VMM)
Hardware
Figura 1 A máquina virtual com um Monitor de Máquina Virtual. O
VMware ESX é um exemplo prático disso.
Linux Magazine #24 | Outubro de 2006
Debian
Kernel
Linux
FreeBSD
Gentoo
Kernel
FreeBSD
VMM
Kernel Linux
Hardware
Figura 2 Máquina virtual com um sistema operacional hospedeiro
completo: é assim que o VirtualPC da Microsoft funciona,
por exemplo.
em inglês) ou hypervisor (figura 1). Entretanto, o hardware, principalmente a CPU, deve satisfazer alguns requisitos [2].
O VMware [3] e o VirtualPC ou VirtualServer [4] suportam esse tipo de virtualização na arquitetura x86. Todavia, os processadores Intel e AMD não oferecem tudo que é
necessário para suportar a virtualização de forma eficiente
[2]. Para isso, cada instrução de máquina que permite acesso
aos recursos do sistema hospedeiro precisaria acionar uma
interrupção de software, a menos que ele esteja rodando em
um dos modos privilegiados do processador [5]. As CPUs
Vanderpool [6], da Intel, e Pacifica [7], da AMD, serão os
primeiros processadores a suportar esse recurso de forma
eficiente. Hoje em dia, produtos como o VMware e o VirtualPC contornam esse problema de formas que podem afetar
consideravelmente o desempenho.
O Xen [8] é outra técnica de hypervisor que requer modificações no sistema operacional hóspede sem uma tecnologia
Vanderpool ou Pacifica. O Xen utiliza uma técnica conhecida
como para-virtualização, em contraste com a virtualização total
usada pelo VMware ou o VirtualPC. Falaremos mais sobre o
Xen e a para-virtualização mais adiante nesta edição.
As virtualizações completa e parcial oferecem um ambiente de execução completo exatamente como um sistema
computacional físico. É por isso que se faz necessário instalar
um kernel de sistema operacional independente na máquina
virtual, embora esse não tenha que ser o mesmo kernel usado
pelo sistema hospedeiro.
Os kernels dos sistemas hospedeiro e hóspede podem ser
idênticos. À primeira vista, parece não fazer muito sentido
desviar-se através da máquina virtual. Afinal, o monitor de
máquina virtual simplesmente provê o mesmo ambiente de
execução que o sistema hospedeiro oferece. Mas, se olharmos
mais de perto, veremos por que a virtualização faz sentido para
muitos ambientes. Por exemplo, talvez queiramos consolidar
vários sistemas computacionais físicos em um único sistema
poderoso para reduzir custos e esforço de administração.
Olhando mais de perto, obviamente é muito importante saber
o que se está tentando com a virtualização. Os fatores a se levar em
conta são desempenho, segurança, custo e complexidade. Existe
uma visão geral das várias abordagens de virtualização em [9].
35
CAPA | Virtualização
Definindo objetivos
Se a idéia for oferecer ambientes de execução virtuais
homogêneos, mas separados, a virtualização completa é
uma boa solução. Mesmo que você tenha sistemas hospedeiros diferentes, as máquinas virtuais ainda podem
ser configuradas identicamente. Isso acrescenta a possibilidade de alocar sistemas hóspedes arbitrariamente,
ou até dinamicamente, dentro de um conjunto de sistemas físicos.
Ao mesmo tempo, o supercomprometimento, ou seja,
o planejamento múltiplo de recursos físicos nas máquinas virtuais, pode ajudar a economizar. Obviamente, isso
supõe o uso de perfis de carga balanceados. Picos de uso
em múltiplas máquinas virtuais não podem ocorrer num
mesmo momento.
O sistema hospedeiro fica completamente desvinculado de seus hóspedes, assim como os hóspedes entre si, do
ponto de vista estrutural. Isso é absolutamente importante
para o aspecto da segurança. Todos os sistemas usam a
mesma CPU, mas não faz diferença se o sistema hospedeiro for um monitor de máquina virtual separado – como é
o caso com o VMware ESX – no qual Linux, FreeBSD e
Windows® podem rodar como sistemas hóspedes, ou se
a máquina virtual precisar de um sistema hóspede completo, como o VirtualPC da Microsoft (figura 2).
O segundo cenário é bastante complexo, pois acrescenta mais um componente de software para o gerenciamento do sistema hóspede no topo do componente
de virtualização.
O desempenho da CPU em instruções de máquina
não privilegiadas numa máquina virtual é teoricamente
idêntico ao do ambiente nativo. Porém, a safra atual de
CPUs Intel e AMD necessitam de ajustes que afetam o
desempenho. Assim, a performance da periferia virtual
pode ser muito diferente. Em cada caso, será necessário
verificar se a virtualização realmente ajudará a atingir
os objetivos.
Servidores virtuais
Se os requisitos não obrigarem à virtualização completa, e se
os kernels dos sistemas operacionais hóspede e hospedeiro
puderem ser idênticos, as partições dos servidores virtuais ou
sistemas operacionais podem ser uma opção. Se o kernel de
um sistema operacional tiver a capacidade de alocar processos,
e dividir o sistema de arquivos e todos os outros recursos de
forma que os processos nas diferentes partições não influenciem uns aos outros e os recursos não atinjam outras partições, as partições poderão ser operadas mais ou menos como
servidores físicos separados. A aplicação desse princípio a um
sistema Linux ou Unix parece abrir vetores que antes eram
imperfeitos ou dificílimos de se alcançar (figura 3).
As vantagens do particionamento são óbvias: menor latência e
desperdício em comparação com máquinas virtuais, onde múltiplos
kernels rodam em paralelo ou numa hierarquia, e onde os dados
são colocados em vários buffers e copiados repetidamente.
Assim como em máquinas virtuais, o perfil de carga dos
serviços e aplicativos rodando nas partições deve ser levado
em conta. A redução de desempenho em comparação com
um ambiente nativo pode ser irrisória, mas não se pode ignorar o planejamento da capacidade, e há limites para o supercomprometimento.
Se as threads não estiverem encapsuladas somente em
processos tradicionais, mas também associadas a uma partição única, os processos de root da partição A não podem
ver nem influenciar os da partição B. O mesmo se aplica ao
sistema de arquivos. Se a partição A receber exclusivamente
uma subárvore no diretório /A, e a partição B no diretório
/B, as permissões para o onipotente usuário root do Unix são
gentilmente canalizadas para uma partição única. É claro
que todos os outros recursos, como interfaces de rede, precisam ser alocados de forma semelhante. O acesso direto
ao hardware tem que ser excluído, e o acesso a /dev/kmem ou
/dev/sda deve ser restrito aos processos do usuário root em
uma partição específica.
Projetos
Figura 3 Particionamento do sistema operacional. Essa é a tecnologia usada pelo Linux VServer, OpenVZ, jails do FreeBSD
e zonas do Solaris.
36
Uma implementação bastante inicial desse projeto pode ser
encontrada no conceito de jails (prisões), introduzido pelo
FreeBSD [10]. As jails acrescentam o particionamento do
espaço do processo e da infra-estrutura de rede ao conceito
familiar do Unix/Linux de chroot jails. Processos privilegiados
num ambiente de jail não conseguem mais realizar ações que
afetem o sistema todo. Por exemplo, é impossível carregar ou
descarregar módulos do kernel, montar sistemas de arquivos,
criar arquivos de dispositivo ou reiniciar o sistema de dentro
de um ambiente de jail.
O Linux VServer [11] e o OpenVZ [12], assim como a variante comercial Virtuozzo [13], que também pode ser utilizada
para o Microsoft Windows, estão disponíveis para o kernel Linux. O Solaris 10 e posteriores, da Sun, dispõem de um produto
tecnicamente comparável que usa contêineres ou zonas [14], e
isso naturalmente também está disponível no OpenSolaris [15].
Basicamente, as mesmas restrições das jails do FreeBSD se aplicam às zonas do OpenSolaris. No Linux, o Linux VServer e o
OpenVZ usam soluções técnicas diferentes, que se refletem em
diferentes conjuntos de patches para o kernel. As ferramentas
para espaço de usuário também são diferentes.
No momento da escrita deste artigo, nem o Linux VServer
nem o OpenVZ faziam parte do kernel Linux oficial, embo-
http://www.linuxmagazine.com.br
Virtualização | CAPA
ra as modificações introduzidas por esses projetos já estejam
bastante avançadas e estáveis. Ambos os projetos buscam a
aprovação dos desenvolvedores do kernel, e seria legal ver
alguns requisitos básicos para suporte à virtualização serem
incluídos em seu código.
Linux VServer
O projeto Linux VServer é baseado nos mecanismos oferecidos pelo kernel Linux atual, como recursos POSIX para
processos [16], namespaces, limites de recursos e atributos
estendidos do sistema de arquivos. Entretanto, isso não é suficiente para cumprir as exigências. Os patches do VServer
acrescentam contextos de processo, e suportam a vinculação
de processos a endereços de rede. Além dessas extensões críticas de funcionalidade básica, os patches adicionam restrições
a permissões para todos os processos dentro de um contexto,
baseados em recursos POSIX, assim como a possibilidade de
associar arquivos a um contexto específico.
Aplicações práticas precisam lidar com o agendamento e
contabilização dirigidos ao contexto, e o suporte a muitas dessas
tarefas já está disponível. Além disso, o util-vserver fornece um
conjunto bastante útil de ferramentas de espaço de usuário.
OpenVZ
Apesar de o Virtuozzo da SWsoft já estar no mercado há algum tempo, sua derivação de código aberto, o OpenVZ, só
foi lançado há poucos meses. O OpenVZ fornece modificações ao kernel Linux, adicionando algumas ferramentas de
espaço do usuário.
Assim como o Linux VServer, o OpenVZ introduz contextos para isolar processos. A virtualização de rede não se
baseia em “apelidos” de interfaces, o que significa que cada
SV (servidor virtual) pode usar seu próprio firewall. O controle
dos recursos usados por um SV é baseado nos user bean counters, que suportam um bom grau de granulosidade. Porém,
o projeto atualmente não tem instrumentos para sincronizar
os sistemas de arquivos do SV, como a quebra de links do
copy-on-write (CoW) do Linux VServer.
Zonas do Solaris
As zonas de virtualização do Solaris são um componente do Solaris 10. A Sun tem ampla experiência com o particionamento
de sistemas Unix de grande porte. O particionamento estático foi
introduzido já em 1996, como uma opção nas máquinas E10000.
Contudo, as partições eram praticamente autônomas, cada uma
com seu próprio kernel de sistema operacional. O antecessor direto do componente atual foi o Resource Manager, introduzido
no Solaris 9. Isso permitiu que os administradores vinculassem
processos a conjuntos, e que controlassem o consumo dos recursos desses conjuntos. Isso não oferecia aos administradores a possibilidade de isolar os ambientes de execução, mas esse recurso
apareceu depois, com a introdução das zonas.
A tecnologia por baixo das zonas do Solaris é bastante semelhante à usada pelo Linux VServer e o OpenVZ, e baseia-se
no particionamento do sistema operacional. Há ferramentas
poderosas para instalar e gerenciar as zonas. Montagens em
loopback podem ser usadas para sincronizar as zonas, apesar
de isso não ser tão eficiente quanto a quebra de links do CoW
ou o UnionFS [17].
■
Linux Magazine #24 | Outubro de 2006
Mais Informações
[1] JVM-Spec (em inglês):
http://java.sun.com/docs/books/vmspec/
2nd-edition/html/VMSpecTOC.doc.html
[2] Popek, G.J; Goldberg, R.P; “Formal requirements for
virtualizable third generation architectures”, Communications
of the ACM, Vol. 17, Julho/1974 (em inglês):
http://portal.acm.org/citation.cfm?id=361011.361073
[3] VMware: http://www.vmware.com
[4] Microsoft Virtual Server e Virtual PC (em inglês):
http://www.microsoft.com/windows/virtualpc/
default.mspx e http://www.microsoft.com/
windowsserversystem/virtualserver/default.mspx
[5] Robin, J.S.; Irvine, C.E.; “Analysis of the Intel Pentium’s Ability to
Support a Secure Virtual Machine Monitor” (em inglês):
http://www.usenix.org/publications/library/
proceedings/sec2000/full_papers/robin/robin.pdf
[6] Tecnologias de virtualização da Intel (em inglês):
http://www.intel.com/technology/computing/vptech/
[7] AMD Pacifica (em inglês):
http://www.amdboard.com/pacifica.html
[8] Xen (em inglês):
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/
[9] Visão geral de máquinas virtuais (em inglês):
http://en.wikipedia.org/wiki/
Comparison_of_virtual_machines
[10] FreeBSD jails (em inglês):
http://www.awprofessional.com/articles/
article.asp?p=366888&seqNum=9 ] e
http://docs.freebsd.org/44doc/papers/jail/jail.html
[11] Linux VServer (em inglês): http://linux-vserver.org/
[12] OpenVZ (em inglês): http://openvz.org/
[13] SW-Soft Virtuozzo (em inglês): http://www.virtuozzo.com/
[14] Contêineres do Solaris 10 (em inglês):
http://www.sun.com/software/solaris/utilization.jsp e
http://www.usenix.org/events/lisa04/
tech/full_papers/price/price_html
[15] Zonas do OpenSolaris (em inglês):
http://www.opensolaris.org/os/community/zones/
[16] POSIX / IEEE 1003.1e and 1003.2c (retirado) (em inglês):
http://wt.xpilot.org/publications/posix.1e/
[17] Homepage do UnionFS (em inglês):
http://www.fsl.cs.sunysb.edu/project-unionfs.html
Os autores
Torsten Kockler é um assistente do Professor Wilhelm
Meier, que leciona sistemas operacionais e linguagens de
programação no Departamento de Ciência da Computação/Tecnologia de microssistemas da Universidade Técnica de Kaiserslautern, em Zweibrücken, Alemanha.
O Professor Wilhelm Meier leciona sistemas operacionais e
linguagens de programação no Departamento de Ciência da
Computação/Tecnologia de microssistemas da Universidade Técnica de Kaiserslautern, em Zweibrücken, Alemanha.
37