- 14.2.1 Comparação
- 14.2.2 Sistema Operacional nativo versus virtualização com Xen
- 14.2.3 Paravirtualização no Xen
14.2 XEN - Xen virtual machine monitor
Xen é um Monitor de Máquinas Virtuais (VMM) que provê uma camada de abstração entre o hardware e o sistema operacional virtualizado. Todo o código do micro-kernel e das aplicações da VMM do Xen está sob GPL.
Xen provê paravirtualização de Sistemas Operacionais com alterações no kernel para a arquitetura xen em hardwares x86/x86_64 e full virtualization em hardwares x86/x86_64 com suporte a virtualização assistida sem necessidade de modificações do sistema operacional hospede.
O Xen é mantido pela Universidade de Cambridge e conta com apoio de empresas globais da área de tecnologia da informação tais como IBM, HP, Intel, AMD entre outras. Para maiores informações acesse o sítio do projeto na Universidade de Cambridge http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ou o sítio Xen Sources http://www.xensource.com.
Alguns ports do Xen estão disponíveis para outros sistemas operacionais como NetBSD, FreeBSD e Solaris.
A dependência do Sistema Operacional de um hardware exclusivo parece estar se tornando coisa do passado. No futuro se pretende ter um Sistema Operacional que não dependa exclusivamente do hardware e de sua localização geográfica.
O Xen nasceu do projeto NetOS (Networks and Operating Systems), criado pelo ``Computer Laboratory's Systems Research Group" e pretende, como o próprio nome do projeto pai sugere, criar uma camada de abstração onde o Sistema Operacional ``navegue" nos recursos dos servidores por uma rede TCP/IP.
Trazendo estes conceitos para o presente, imagine o seguinte cenário: poderemos estar acessando dados de uma determinada aplicação em um dado momento no tempo rodando em um servidor físico no Brasil e em outro momento estes mesmos dados estar localizado em outro continente sem que ao menos o usuário que os acessa perceba a mudança geográfica do Sistema Operacional.
Aliando-se sistemas de balanceamento de carga, alta disponibilidade, consolidação de recursos computacionais e sistemas de arquivos em cluster, esta tarefa parece estar se materializando.
14.2.1 Comparação
Ao contrário do VMWare, o Xen é executado diretamente sobre o hardware, no ring 0, e possui uma máquina virtual chamada de Dom0. Essa máquina tem acesso privilegiado ao hypervisor, permitindo a ela as operações necessárias que as demais máquinas virtuais não podem executar. A máquina virtual Dom0 é então responsável pelo gerenciamento de toda a estrutura de gerenciamento de virtualização fazendo uso de aplicações que tem acesso ao hypervisor. É nesta máquina virtual que se parametriza a virtualização do hardware e a fatia entregue para cada máquina virtual que não tenha acesso direto ao hardware e ao hypervisor.
No sítio da Sun http://www.sun.com/emrkt/innercircle/newsletter/brazil/0706vass.php, são feitas algumas ponderações sobre tecnologias de virtualização:
- Vmware:
Embora atraente, a abordagem de máquina virtual do VMware pode ser relativamente cara em termos de desempenho. Geralmente, o hypervisor consome entre 5 e 15% da potência total da CPU, enquanto cada sistema operacional aumenta a carga. No final, as empresas podem consumir uma grande quantidade de recursos da CPU simplesmente para comportar a infra-estrutura de máquina virtual. - Xen:
Recentemente, o software de código aberto, Xen, surgiu como alternativa ao VMware. Como o VMware, o Xen suporta a execução de vários sistemas operacionais no mesmo hardware. O Xen é uma forma de virtualização de nível mais baixo, com a qual os administradores podem virtualizar várias partes de um sistema, incluindo a memória e a CPU. Como ele reside a um nível baixo, este oferece isolamento de falhas e recursos computacionais consideráveis.
Há vários motivos para se considerar o Xen:
- é um programa de código aberto,
- é relativamente leve, portanto, não consome uma quantidade absurda de recursos da CPU.
- atinge um alto grau de isolamento entre as tecnologias de máquina virtual.
- como qualquer outra tecnologia de máquina virtual, suporta combinações variadas de sistemas operacionais e versões, além de permitir que os administradores iniciem e executem dinamicamente uma instância do sistema operacional sem afetar o serviço.
14.2.2 Sistema Operacional nativo versus virtualização com Xen
Algumas justificativas são válidas para a utilização de virtualização. Ainda no sítio da Sun http://www.sun.com/emrkt/innercircle/newsletter/brazil/0106feature.php:
``A popularidade da virtualização tem a ver com seu princípio filosófico - a convicção de que os data centers estão abarrotados de servidores subutilizados. Ela parece solucionar o problema criado pelo paradigma predominante do 'um servidor para um aplicativo' que resulta do super-provisionamento visando à máxima performance. As taxas de utilização de servidores podem oscilar entre 5% e 15%. Por fim, a promessa de servidores baseados em commodities resultou em data centers excessivamente caros de gerenciar, alimentar e refrigerar.begintex2html_deferred
Esta afirmação faz cair por terra a tese de que é necessário o uso de ``um servidor por aplicação", considerando que servidor neste caso é subentendido por hardware. As taxas de utilização do processador do hardware podem ser melhor aproveitadas utilizando sistemas de virtualização, aumentando o uso dos processadores (o Xen provê virtualização dos processadores ou mesmo balanceamento de carga entre eles), reduzindo o espaço físico do Data Center e em contra partida reduzindo o consumo de energia elétrica para a alimentação dos servidores e conseguentemente para outros ítens como condicionador de ar.
Ainda, com Xen é possível manter um SLA muito interessante. A possibilidade de dar manutenção física nos servidores sem necessidade de parada dos serviços é um diferencial que todo administrador deseja ter para não sofrer no momento da parada de um hardware. Basta para isso ter um outro servidor configurado e migrar em tempo real (50ms) o sistema operacional de um domínio para outro. Esta migração em tempo real (live migration) exige, no entanto, que certos aspectos de configuração do ambiente sejam respeitados para que ela possa acontecer. Estes requisitos são os seguintes:
- Ambos os hosts (origem e destino da máquina virtual) devem executar um daemon chamado xend, que é a parte do VMM responsável pela gerência das máquinas virtuais;
- Ambos os hosts devem executar a mesma versão do Xen;
- Ambos os hosts devem estar na mesma rede;
- Ambos os hosts devem ter acesso ao sistema de arquivos utilizado pelos guests. Na prática, isto significa que deve haver um sistema de arquivos compartilhado (por exemplo, NFS) visível aos hosts;
- O host de destino deve possuir memória livre o suficiente para acomodar a nova máquina virtual.
Se estes requisitos não puderem ser atendidos, ainda é possível que seja realizada a migração. No entanto, a migração realizada será mais lenta e envolverá a suspensão da atividade do sistema em migração, suspensão esta que será percebida pelos clientes remotos utilizando as aplicações presentes na máquina virtual.
14.2.3 Paravirtualização no Xen
O Xen usa uma técnica completamente diferente do que conceitualmente é utilizada em outros hypervisors. Na paravirtualização, o Sistema Operacional hospede é portado para uma camada de hardware (ring 1) que virtualiza todas as relações do Sistema Operacional com o hardware. Quando o Sistema Operacional atualiza estruturas de dados do hardware, tais como a tabela de paginação ou da início a uma operação do acesso direto da memória, o Sistema Operacional hospede faz chamadas na API que é oferecida pelo hypervisor.
Isto, por sua vez, permite que o hypervisor mantenha o controle de todas as mudanças feitas pelo Sistema Operacional, e decida como modificar as interrupções do hardware. O hypervisor é mapeado no endereço de cada Sistema Operacional hospede, minimizando o tempo do interrupção entre todo o hardware e o hypervisor. Finalmente, trabalhando cooperativamente com os Sistemas Operacionais hospedes, o hypervisor ganha a introspecção adicional do Sistema Operacional, e pode fazer com que ele fique ciente do fato que foi virtualizado. Isto pode ser uma grande vantagem para o sistema hospedeiro - por exemplo: o hypervisor pode informar ao hospede em real-time qual foi sua última atividade, permitindo um reescalonamento bem mais eficiente dos sistemas hospedados.
A paravirtualização disponibiliza benefícios significantes em termos de drivers de dispositivos e interfaces. Essencialmente, drivers de dispositivos podem ser virtualizados utilizando o modelo de paravirtualização, e assim, garantindo recursos de baixo nível separados por domínios como memória, CPU e outros recursos. Além disso, o próprio hypervisor é protegido de eventuais erros e problemas com os drivers dos dispositivos e ainda pode-se empregar qualquer dispositivo disponível no mercado não precisando assim um hardware ou driver especifico. E ainda, sistemas Operacionais virtualizados são muito mais portáveis quando virtualizados pelo hardware: eles são virtualizados em níveis baixos e, a gerência do hardware são módulos que funcionam sob o controle do hypervisor.