Virtualização para máquinas virtuais
As máquinas virtuais são o backbone da computação em nuvem. Quando você cria uma instância de EC2 na AWS ou em uma máquina virtual no Azure, o provedor de serviços de nuvem não dedica um servidor físico à instância ou à máquina virtual. Em vez disso, ele cria uma máquina virtual em um servidor físico. Essa máquina virtual pode ser uma das muitas hospedados no servidor. Porém, devido à virtualização, a máquina virtual é semelhante a um servidor dedicado. Ela é isolada de maneira lógica de outras máquinas virtuais e um programa errôneo que cause a falha ou comprometa de outra forma uma máquina virtual não pode afetar programas em execução em outras máquinas virtuais, mesmo que compartilhem um host físico. Além disso, um servidor que hospeda duas VMs pode executar um sistema operacional (por exemplo, Linux) em uma VM e em outro sistema operacional (como o Windows) na outra.
As máquinas virtuais também são usadas fora da computação em nuvem. Por exemplo, um produto popular chamado Parallels que os usuários do Mac executem o Windows e o macOS lado a lado hospedando o Windows em uma VM. Os desenvolvedores de software frequentemente usam VMs para testar programas porque as máquinas virtuais fornecem um ambiente consistente e isolado facilmente replicável de um computador para outro.
Todas essas máquinas virtuais são instâncias de VMs de sistema, que virtualizam um sistema inteiro (computador físico). Porém, há também VMs de processo, que fornecem a base para linguagens de programação populares, como Java e C#. Vamos examinar ambos os tipos, discutir como funcionam e entender por que, entre os dois tipos, são as VMs de sistema que fornecem a base para a computação em nuvem.
Máquinas virtuais do Windows
Uma VM de processo (Figura 1) é uma VM capaz de dar suporte a um processo individual, desde que o processo esteja ativo. Uma VM de processo é encerrada quando o processo que ela hospeda termina. Do ponto de vista de uma VM de processo, um computador consiste em um espaço de endereço de memória virtual, registradores de nível de usuário e instruções para executar um programa. De acordo com essa definição, um processo em um sistema operacional de uso geral também pode ser chamado de "computador". No entanto, um processo regular só pode dar suporte a binários de programa compilados para a arquitetura do processador ou a ISA (arquitetura do conjunto de instruções) do computador host. A execução de binários compilados para um ISA diferente daquele do computador host, por exemplo, a execução de programas compilados para processadores ARM em computadores equipados com CPUs Intel, não é compatível com processos regulares. No entanto, uma VM de processo permite que isso aconteça.
Figura 1: VM do Processo.
As VMs de processo dão suporte a ISAs que diferem de ISAs do host por meio de emulação, o que permite que as interfaces e as funcionalidades de um sistema (a origem) sejam implementadas em um sistema com interfaces e funcionalidades diferentes (o destino). Um exemplo de emulação é a execução de um programa compilado para a família antiga de processadores 6502/6510 usada pelos primeiros computadores da Apple em um processador x86. A abstração da VM de processo é fornecida por um software de virtualização chamado de runtime. O runtime fica acima do sistema operacional do host e do hardware subjacente. É esse runtime que emula as instruções e/ou chamadas do sistema quando os ISAs de participante e host são diferentes.
As VMs de processo estão disponíveis desde meados da década de 1960 anos e foram usadas primeiramente para converter as linguagens intermediárias geradas por compiladores no código do computador para o processador do host, em parte para simplificar o processo de portar compiladores para novas arquiteturas de processador. Elas têm usos semelhantes atualmente. Um JVM (Máquina Virtual Java), por exemplo, é uma máquina virtual de processo que compila o código de bytes Java (as instruções emitidas por um compilador de Java) para o código de máquina nativo e o executa no computador host. Os programas escritos em C# e outras linguagens com suporte no CLR (Common Language Runtime) da Microsoft também empregam VMs de processo para compilar para o código de computador as instruções de CIL (Common Intermediate Language) emitidas pelos compiladores. As VMs de processo cuja finalidade é executar linguagens intermediárias produzidas por compiladores de linguagem às vezes são chamadas de VMs de linguagem de alto nível ou VMs HLLs, de forma abreviada.
Em resumo, uma VM de processo é semelhante a um processo normal em execução em um SO. No entanto, uma VM de processo permite, via emulação, a execução de aplicativos compilados para um ISA diferente daquele do computador host. Além disso, as VMs de processo HLL fornecem a base para linguagens gerenciadas populares, como Java e C#. O termo "gerenciado" neste contexto refere-se ao fato de que Java e C# gerenciam a memória em nome de seus aplicativos e fornecem proteções contra erros comuns de programação, como o uso indevido de ponteiros e o cruzamento dos limites de matrizes na memória.
Máquinas virtuais do sistema
Diferentemente das VMs de processo, uma VM de sistema virtualiza um computador inteiro virtualizando um conjunto completo de recursos de hardware, incluindo processadores, memória e dispositivos de E/S. O software de virtualização, ou hipervisor, que também é conhecido como um VMM (monitor de máquina virtual), fica entre o hardware e o sistema operacional e cria a ilusão de que o sistema operacional e os aplicativos que ele hospeda estão sendo executados em computadores autônomos (Figura 2).
Figura 2: VM do sistema.
O hipervisor gerencia a alocação e o acesso aos recursos de hardware subjacentes. Ele permite que várias VMs sejam executadas lado a lado e fornece a cada VM a ilusão de pertencer a todos esses recursos. O computador físico é chamado de host e um sistema operacional em execução em uma VM em um host é chamado de SO convidado ou sistema operacional convidado (Figura 3). Cada VM pode ser inicializada, desligada e reinicializada assim como um host regular. Uma VM só pode ser executada em um host por vez, mas pode ser desligada, movida para outro host e iniciada lá. Portanto, embora uma VM só possa ser executada em um host em um determinado momento, ela pode ser migrada para hosts diferentes ao longo de um período.
Figura 3: Sistema único hospedando várias VMs.
Os primeiros hipervisores foram executados em mainframes IBM na década de 1960. Os hipervisores iniciais foram implementados inteiramente no software ou confiavam em hardware para aumentar o desempenho. Na verdade, alguns mainframes são enviados com hardware especial apenas para dar suporte à virtualização. No momento, os microprocessadores populares da Intel e da AMD têm suporte integrado para virtualização, um recurso que pode ser habilitado ou desabilitado na maioria dos computadores por meio de configurações de firmware. O suporte de virtualização nativa em CPUs é o principal motivo pelo qual a popularidade das VMs explodiu em meados para o final da década de 2000. Ele ofereceu uma geração de hipervisores baratos, mas com recursos completos, como VMware, Hyper-V e VirtualBox, bem como hipervisores de software livre, como Xen1. Mesmo antes da computação em nuvem entrar em moda, as organizações começaram a usar esses hipervisores para virtualizar cargas de trabalho nos próprios data centers. Isso acelerou a transição para a computação em nuvem, permitindo que as organizações que já usam servidores virtualizados fizessem "lift and shift" das cargas de trabalho para a nuvem carregando imagens de máquina virtual existentes e criando VMs com base nelas.
Os hipervisores também veem o uso em computadores desktop em produtos como Parallels e o Docker Desktop para Windows. O último usa um hipervisor de host (Hyper-V ou VirtualBox) para executar contêineres do Docker em VMs Linux hospedadas no Windows. Os pesquisadores de segurança consideram que os hipervisores têm um valor inestimável, pois uma VM comprometida por malware não afeta outras VMs, o sistema operacional do host nem o hardware subjacente. Uma VM comprometida pode ser rapidamente interrompida e, se desejado, recriada em seu estado descomprometido sem risco para o restante do sistema.
Como uma VM de processo, uma VM do sistema pode dar suporte a ISAs diferentes do sistema host. VMs como essas são amplamente usadas em emuladores que permitem executar jogos escritos para Xbox, PlayStation e outras plataformas de hardware em computadores desktop. Os emuladores implementados dessa maneira (por meio de hipervisores que utilizam o suporte de virtualização em CPUs) geralmente têm melhor desempenho do que os emuladores em VMs de processo que virtualizam totalmente os conjuntos de instruções por meio de software.
Diferente de uma VM de processo, uma VM de sistema pode apresentar ao sistema operacional e aos aplicativos que ela hospeda recursos que diferem em termos de quantidade e tipo do host físico. Por exemplo, uma VM do sistema pode fornecer mais processadores, às vezes chamados de CPUs virtuais ou vCPUs, que o sistema host.
Os data centers que oferecem computação em nuvem como um serviço para os clientes usam VMs de sistema para virtualizar cargas de trabalho e consolidar servidores. Deste ponto em diante, quando usamos o termo "máquina virtual" ou "VM", estamos nos referindo às VMs de sistema, a menos que especificado de outra forma. Na próxima lição, discutiremos como as VMs de sistema beneficiam a computação em nuvem e por que a computação em nuvem talvez não existisse, e certamente não seria tão econômica, sem a virtualização.
Referências
- Barham et al. (2003). "Xen and The Art of Virtualization.", Anais do 19º Simpósio da ACM sobre os Princípios dos Sistemas Operacionais (SOSP '03). ACM, New York, NY, USA.