Como funciona o Proxmox: a ASNetworking explica VMs, contentores, KVM e QEMU

Obrigado à ASNetworking pelas explicações visuais claras neste curso de Proxmox em espanhol. O capítulo dois cria o modelo mental por detrás de um anfitrião virtualizado: o que uma VM obtém de uma máquina física, como funciona a atribuição de recursos, em que diferem os contentores e por que motivo QEMU e KVM aparecem juntos. Veja o vídeo original para acompanhar toda a explicação do criador.

Veja antes de ler: Esta lição conceptual de 20 minutos é útil se está a considerar o Proxmox VE para um laboratório doméstico, mas quer compreender as suas camadas antes de instalar seja o que for. Os diagramas passam de um servidor físico e vários sistemas convidados para discos com provisionamento fino, contentores, o kernel Linux, QEMU e KVM. Alguns gráficos mostram máquinas empresariais de grandes dimensões ou capacidades ilustrativas; são exemplos didáticos, não especificações de hardware para um servidor compacto.

A distinção fundamental é entre aquilo que é mostrado a um sistema convidado e aquilo que o anfitrião realmente tem disponível. Uma VM pode ver os seus próprios núcleos de CPU, RAM, disco e sistema operativo, embora esses recursos tenham origem, em última análise, no mesmo anfitrião físico. O Proxmox VE reúne a gestão de VMs e de contentores Linux numa única interface; este capítulo explica a arquitetura, em vez de medir o desempenho ou demonstrar uma instalação concluída.

Um anfitrião físico, várias máquinas separadas

A virtualização permite que um servidor execute vários sistemas operativos convidados como VMs distintas. Cada sistema convidado vê hardware virtual e pode executar as suas próprias aplicações, enquanto o anfitrião agenda o CPU subjacente e gere a memória física, o armazenamento e a rede. É por isso que uma VM de teste com Linux e uma VM separada para serviços podem coexistir sem ser necessário um computador físico por tarefa.

O sobrecompromisso exige um orçamento de recursos real

A ASNetworking apresenta o sobrecompromisso: atribuir aos sistemas convidados mais recursos virtuais do que aqueles que o anfitrião poderia fornecer se todos os exigissem em simultâneo. Isto pode ser sensato quando as cargas de trabalho atingem o pico em momentos diferentes. Não se trata de hardware adicional. Uma procura simultânea elevada pode provocar contenção de CPU, pressão sobre a memória ou armazenamento mais lento. Num pequeno laboratório doméstico, comece com a RAM e o armazenamento físicos que realmente tem, reserve espaço para o anfitrião e acompanhe a utilização antes de adicionar outro sistema convidado.

O provisionamento fino altera o momento em que o espaço em disco é consumido

Um disco virtual pode apresentar uma capacidade lógica superior ao espaço físico que consumiu até ao momento. O gráfico do vídeo mostra cinco discos virtuais de 1 TB num disco físico de 1 TB, utilizando atualmente 100 GB cada um. Isto só funciona enquanto as gravações reais couberem no disco físico. Se os sistemas convidados preencherem coletivamente os seus discos virtuais, o anfitrião pode ficar sem espaço muito antes de as capacidades apresentadas sugerirem um problema. Verifique o espaço físico livre, o formato de armazenamento, os instantâneos e as cópias de segurança, em vez de planear apenas com base na capacidade virtual anunciada.

O episódio aborda também a hierarquização da memória. A RAM e o armazenamento mais lento têm funções diferentes: mover dados inativos para uma camada mais lenta pode ajudar a gerir a pressão, mas não faz com que o armazenamento tenha o desempenho da RAM. Considere cada funcionalidade de poupança de recursos como uma solução de compromisso que deve ser validada face à carga de trabalho, sobretudo num anfitrião com memória limitada.

O que o hipervisor gere

O hipervisor situa-se entre os recursos físicos e as VMs. O diagrama, nesta fase do vídeo, salienta que cada VM tem a sua própria carga de trabalho, mas continua dependente do CPU, da RAM, do disco e da rede de um único anfitrião. O Proxmox VE acrescenta as ferramentas de gestão destes sistemas convidados, incluindo uma interface Web e serviços de configuração e administração. A sua arquitetura inclui máquinas virtuais KVM e contentores LXC.

As VMs e os contentores proporcionam limites diferentes

Uma VM inclui um sistema operativo convidado e hardware virtual. Um contentor Linux isola as aplicações e o seu espaço de utilizador, partilhando o kernel Linux do anfitrião. Isto torna geralmente um contentor mais leve do que uma VM completa, mas trata-se de um modelo diferente de isolamento e de sistema operativo. Um sistema convidado Windows, ou uma carga de trabalho que beneficie de um kernel separado, deve ficar numa VM. Um serviço Linux adequado pode caber num contentor LXC. A documentação do LXC do Proxmox explica o modelo de contentores com mais detalhe.

Os contentores e as VMs também podem ser combinados: um ambiente de execução de contentores pode funcionar dentro de uma VM quando esse limite for adequado à implementação. O quadro comparativo do vídeo inclui configurações bare metal, virtualizadas, contentorizadas e combinadas. Escolha o limite de acordo com o serviço e com os seus requisitos de segurança, compatibilidade e manutenção; um contentor não é simplesmente uma VM mais pequena.

Onde se enquadram o Linux, o QEMU e o KVM

O Proxmox VE é uma plataforma baseada em Linux com uma interface de gestão; não precisa de memorizar todos os comandos para compreender o papel dos seus componentes. O criador mostra brevemente a página de transferências do Proxmox e, em seguida, explica as camadas técnicas subjacentes a uma VM. Esse ecrã de transferências identifica a família de produtos, enquanto o modelo de virtualização é explicado mais diretamente pelo diagrama QEMU/KVM seguinte.

O KVM é a capacidade de virtualização do kernel Linux, utilizando extensões de virtualização do CPU compatíveis. O QEMU fornece o processo da máquina virtual e dispositivos emulados ou paravirtualizados; em conjunto, o QEMU e o KVM executam VMs com aceleração de hardware. Esta é uma forma útil de interpretar as etiquetas no Proxmox, em vez de imaginar o QEMU e o KVM como dois hipervisores concorrentes. O guia QEMU/KVM do Proxmox aborda a configuração e as capacidades das VMs.

Aplique o modelo a um pequeno laboratório doméstico

O vídeo mostra brevemente um gráfico da quota de mercado dos hipervisores. As percentagens não são necessárias para escolher uma plataforma para um laboratório doméstico e não devem ser tratadas como dados de mercado verificados de forma independente. A decisão mais útil é concreta: que cargas de trabalho precisam de sistemas operativos convidados completos, quais podem partilhar um kernel Linux e quantas cabem no seu orçamento real de RAM e disco.

Para um anfitrião compacto, como o mini servidor doméstico ZimaBoard 2, comece por associar um ou dois serviços modestos, verifique o CPU, a memória, o suporte de arranque e o armazenamento ligado do modelo exato e só expanda depois de observar a utilização real. Isto é uma aplicação do modelo de recursos da lição, não uma afirmação de que o vídeo avalia o desempenho do ZimaBoard 2 ou valida um determinado número de VMs. Mantenha as cópias de segurança separadas dos discos virtuais com provisionamento fino.

Com estas camadas esclarecidas, o próximo capítulo pode concentrar-se nas escolhas práticas de instalação. Veja o capítulo sobre instalação da ASNetworking para conhecer a discussão sobre RAM, formatos de armazenamento e associação de interfaces de rede antes de criar o seu primeiro anfitrião.