Falando de virtualização

Este post faz referência sobre virtualização computacional, modelo de abstração de recursos computacionais, afim de prover redução de recursos necessários para consolidar diferentes arquiteturas, sob um único hardware básico (ou avançado, indo do gosto do freguês).

Pretendo cobrir a parte sobre virtualização de sistemas operacionais (virtualização de plataformas), portanto, não falarei detalhadamentesobre as outras abordagens de virtualização. Apesar de ser um assunto relativamente novo, é um assunto, ao mesmo tempo, relativamente muito velho. Entendo por virtualização a grande invenção da memória virtual (que abstrai um segundo dispositivo de armazenamento, como memória principal, e estende sobre esse o espaço de endereçamento de instruções), as interfaces virtuais de rede (onde, por exemplo, dependendo das capacidades do dispositivo, pode-se criar diversas interfaces de rede virtuais, com diversos pontos de acesso em IP, por exemplo, sob um único dispositivo físico), as interfaces virtuais de armazenamento (que podem ser, desde abstrações via rede, até um storage inteiro virtual), VPNs (que nada mais são que redes inteiras virtuais), virtualização de desktops (como terminais burros, ou por exemplo, serviços de terminais remotos), virtualização e clustering de sistemas de gestão de bancos de dados, e por aí vai!

Falando sobre Hypervisor

Para entrar no tema que eu quero sobre virtualização, não dá pra começar sem falar de uma entidade chamada de Hypervisor. Este é o sujeito responsável por prover uma interface lógica entre o que vai prover um ambiente de virtualização (chamado comumente de hospedeiro) e o que vai ser virtualizado (chamado comumente de convidado). Técnicamente, é uma porção de código que é executado pelo software hospedeiro, e age como um controlador de hardware e monitor do sistema operacional do software convidado. Geralmente, nesses moldes, o sistema operacional convidado, executa sob um nível abaixo do nível do Hypervisor.

A primeira figura exibe quais as camadas definidas na arquitetura de virtualização a qual estou me referindo.

Figura 1 – Arquitetura básica da virtualização provida pelo Hypervisor.

Há dois principais modos de execução do Hypervisor. O modo nativo (portanto, para virtualization), e o modo abrigado (portanto, full virtualization).

O primeiro modo de execução, chamado abrigado (com a palavrinha mágica – hosted), faz com que toda a plataforma de hardware disponível ao convidado seja totalmente virtualizada. Portanto, são implementados e aplicados gatilhos e tratadores nas chamadas de sistema e instruções de máquina (instruções nativas – sistema operacional convidado não sofre nenhuma modificação) enviadas pelo sistema operacional convidado, e convertidas para as instruções de máquina e chamadas de sistema do sistema operacional hospedeiro, portanto, executadas nativamente. O resultado de tais ações é novamente convertido para o formato de retorno do sistema operacional convertido, e tudo caminha nas mil maravilhas.

A figura 2 mostra um modelo esquemático de aplicação do modelo 1 do Hypervisor.

Figura 2 – Arquitetura básica do modelo hospedado.

Definem-se como vantagens dessa abordagem, o fato sistema operacional convidado não precisa ser modificado; para este, é uma máquina física como qualquer outra. Não há custos adicionais, nem modificação no software original, reservando as características originais do sistema operacional convidado. A grande desvantagem dessa abordagem é o desempenho comprometido (em relação ao desempenho original, o que não significa que fique lento – leia-se sem condições mínimas de emprego em um ambiente corporativo de produção). A queda do desempenho dá-se pela interpretação de todas as instruções disparadas pelo hardware virtual disponível para a máquina convidada. Além disso, claro, ainda há o escalonamento de processos do sistema operacional, através de um núcleo premptivo.

O segundo modo de execução, chamado nativo (com a palavrinha mágica – bare-metal), cria um meio termo nas coisas. Através de um núcleo de chamadas de sistema (vulgo Kernel, no mundo *nix) modificado, torna o sistema operacional convidado, alguém que sabe que está sendo virtualizado, mas que consegue, através desse núcleo modificado, alcançar nativamente o hardware disponível na arquitetura do sistema hospedeiro. Mágico, não?

Este novo núcleo, é então parte do Hypervisor (que agora é parte do sistema operacional convidado, e parte do sistema operacional hospedeiro), fazendo com que seja mais simples chegar ao hardware, e fazer algumas traduções das chamadas mais críticas do sistema.

Como vantagens da técnica, está principalmente o desempenho, tornando as coisas mais fáceis, fazendo com que não haja tradução de instruções, nem emulação de hardware. Por exemplo, se você comprou sua nova Intel® PRO/1000 GT Desktop Adapter, ele vai ser Intel no sistema hospedeiro, e Intel no sistema convidado. Na primeira abordagem, ela seria Intel no sistema hoespedeiro, e Network Virtual Driver, no sistema convidado. A principal desvantagem é a modificação do núcleo do sistema convidado, aumentando a probabilidade do número de falhas (por sair da árvore principal de desenvolvimento do software, e ter dedos de terceiros), incompatibilidade de padrões, aumento de custo de manutenção, e blá blá blá.

A figura 3 define um modelo esquemático de como aconteceria a implantação do segundo caso.

Figura 3 – Implantação do modelo nativo do Hypervisor.

Em relação ao modelo de virtualização de plataformas, com a presença de um Hypervisor, o assunto termina por aqui. Não há muito mais novidades na área.

Continuando com o assunto de virtualização, é válido dizer que o hardware x86 é particularmente difícil de virtualizar. Com essa motivação, tanto a Intel, quanto a AMD, criaram tecnologias de virtualização diretamente embutidas no processador. A Intel a chamou de Intel-VT (VanderPool), e a AMD, AMD-V (Pacifica). Tais extensões são responsáveis por adicionar capacidades que são difíceis ou ineficientes de virtualizar via software, facilitando o trabalho do pessoal que desenvolve na área.

Falando sobre implementações

Há diversos softwares comerciais e livres que implementam este modelo de monitor de máquinas virtuais, e com a idéia geral de virutalização de plataformas, dá pra nomear algumas categorias, de forma simplificada, e alguns softwares virtualizadores, que a implementam.

No primeiro modelo, nativo, encaixam-se nomes como VMware ESX Server, IBM System z Hypervisor, Microsoft Hyper-V, Xen, Citrix XenServer, Oracle VM Server, Parallels Server, Sun’s Logical Domains Hypervisor, e finalmente, o Kernel-based Virtual Machine (KVM), disponível nas distribuições empresariais de Linux. Todos esses softwares permitem a virtualização do sistema operacional hospedeiro, bem como o sistema operacional convidado, exigindo a modificação de seu núcleo.

Já no segundo modelo, hospedado, encaixam-se nomes como VMware Server, VMware Workstation, VMware Fusion, o projeto livre QEMU, Microsoft Virtual PC e Microsoft Virtual Server, Sun’s VirtualBox, Parallels Workstation e Parallels Desktop. Estes software virtualizam qualquer sistema opercional comum, sem a necessidade de sua modificação.

Virtualização e instâncias de sistemas operacionais

Especificamente, o Sun Solaris e o BSD, implementam um outro modelo de virtualização de sistema operacional.

O Sun Solaris (a partir de 2005) implementa Zones, definido como um abstração virtual do sistema operaciona, onde aplicações executam. Tais aplicações são protegidas e separadas umas das outras. Através de uma única instância principal do sistema operacional, pode-se gerencial diversas Zones (como instâncias do mesmo sistema).

O uso do gerenciamento de recursos da arquitetura em questão, faz com que uma Zone seja chamada de Container, criando o conceito de Solaris Containers. A maioria das pessoas utilizam  os dois termos, sem fazer distinção entre eles.

Existem dois tipos de Zones. As Zones nativas, criam instâncias do mesmo sistema operacional (Solaris), enquanto as Branded Zones, disponibilizam uma insfra estrutura virtual de hardware, para que seja possível criar instâncias de outros sistemas operacionais, como o Linux, por exemplo.

Da mesma maneira, existem os Jails (que vieram antes dos Containers, em 1990, criados a partir do FreeBSD). Jail implementa o mesmo sentido de abstração do sistema operacional, criando instâncias desse, fazendo com que haja muito mais flexibilidade do uso do sistema operacional, em um ambiente de produção.

Acredito que o uso de instâncias de sistema operacional, tenha tido como principal motivação, a flexibilidade de modelos de segurança que o *nix não conseguia prover, mas isso é um outro assunto.

Para terminar o post, volto a dizer que virtualização pode ser vista de diversas formas, e existem diversos modelos e ferramentas para implementar. Vão desde abstrações de hardware de entrada e saída, até abstrações do sistema operacional. O que vale realmente realmente, é estudar e medir as necessidades e as disponibilidades, para que seja feita a escolha certa.

O modelo de cloud computing se encaixa em virtualizações. É um tema recente, poderoso, mas com a escolha errada, pode se tornar extremamente perigoso.

Até a próxima!

Referências:

http://en.wikipedia.org/wiki/Virtualization

http://en.wikipedia.org/wiki/Hypervisor

http://www.sun.com/servers/coolthreads/ldoms/index.jsp

http://en.wikipedia.org/wiki/Paravirtualization

http://www.ibm.com/developerworks/br/library/l-hypervisor/index.html

http://blogs.technet.com/lpalma/archive/2008/10/01/paravirtualiza-o-emula-o-bare-metal.aspx

http://www.intel.com/products/desktop/adapters/pro1000gt/pro1000gt-overview.htm