Montar um servidor em casa com o Proxmox, em condições ideais, requer sempre investimento e esse não é o propósito deste artigo, mas sim, usarem o hardware que têm parado em casa e fazerem uso dele.
Foi isso que fiz, com o meu computador (composto por um processador AMD APU A10 7850K, 8 GB de memória RAM e um disco de 240 GB SSD) que estava a ter pouco uso. Para o vosso hardware ser compatível com a instalação, é preciso processador Intel ou AMD de 64-bits, motherboard compatível com Intel VT ou AMD-V, 1 GB de memória RAM e uma placa de rede. Se estiverem reunidos este mínimos, já podem pôr mãos à obra. Para o objectivo de correr máquinas virtuais com distribuições Linux e Containers, o hardware usado é mais do que suficiente e vou partilhar o que fiz passo a passo.
Estrutura e configuração de rede
No Proxmox podem criar clusters no topo, depois nodes abaixo e, em seguida, as máquinas virtuais e os containers. Segundo as boas práticas, é aconselhável criar pelo menos um cluster, muito devido à facilidade depois de mover as diferentes máquinas virtuais entre vários nodes, que são conjuntos de máquinas virtuais e containers.
Criei então um cluster principal com o nome ‘lab’ e associei ao ‘node’ criado no processo de instalação do Proxmox. Se tiverem outro servidor, podem associar um outro link para redundância.
No que diz respeito à configuração de rede, como uso o router do operador e acredito que a maioria dos leitores também, por padrão a gama de IP é 192.168.*.* e no processo de instalação, o Proxmox atribui um IP dentro dessa gama para o ‘node’, que no meu caso foi 192.168.1.7. Podem mudar o IP no webportal na opção Network no ‘node’ ou configurar por linha de comandos da seguinte forma:
- nano /etc/network/interfaces
Activar firewall e criar grupos de segurança
Este aspecto nunca deve ser desconsiderado, mas para testar máquinas virtuais não será necessário nada de muito complicado, mas devem fazer dois tipos de configuração no cluster principal: activar a firewall e criar grupos de segurança.
A firewall vêm descativada por padrão; depois de activa, deixam de aceder remotamente ao servidor porque se não forem definidas regras. Por isso o meu conselho é fazerem logo a ativação junto com as regras diretamente no servidor, usando o nano como editor e colocar as seguintes configurações:
- nano /etc/pve/firewall/cluster.fw
[OPTIONS]
enable: 1
policy_in: DROP
[RULES]
IN ACCEPT –p tcp –dport 22
IN ACCEPT –p tcp –dport 8006
Para gravar basta carregar em ‘Ctrl + O’ e, para sair do editor, ‘Ctrl + X’. Estas regras permitem definir o tráfego de entrada e saída, com as regras de entrada apenas via SSH na porta 22 e acesso Web via porta 8006. Criar grupos de segurança é uma opção importante porque serão usados depois nas máquinas virtuais criadas, facilitando as configurações. Como exemplo, criei um grupo de segurança com o nome acessos: na opção de security Group, seleccionem ‘create’ e escrevam o nome ‘acessos’ ou outro nome que queiram dar. Depois, nas regras, vão ser definidas permissões de tráfego via HTTP, HTTPS, SSH, VNC, RDP, SMB e ping, conforme podem ver na imagem. Basta seleccionarem o protocolo ou podem também selecionar a macro do que querem. Estas configurações podem ser feitas novamente no /etc/pve/firewall/cluster.fw. Uma terceira opção (no meu caso não vi necessidade de o fazer) é o IPSet, que permite criar regras especificas para grupos de IP ou ranges de IP no cluster principal, ficando disponíveis depois nos nodes e máquinas virtuais criadas. Fica apenas a informação, caso pretendam explorar melhor este ponto.
Full Backup, Backup Compression e Snapshots
A escolha do backup a fazer será sempre pessoal, mas um full backup é, no geral, a melhor solução porque guarda literalmente tudo, inclusive configurações. Se optarem por um full backup podem escolher: Snapshot, Suspend ou Stop. O snapshot mantém a máquina virtual activa, mas continua a fazer a cópia de segurança, podendo causar alguma perda de desempenho e um maior tempo de backup. Já a opção ‘Suspender’ e o ‘Stop’ apresentam um maior período de inatividade durante o processo de backup, mas como não estamos numa empresa, a minha sugestão é a opção ‘Stop’, garantindo assim um backup mais preciso e com menor tempo de confirmação. Um outro tipo de backup é compactar nos formatos LZO ou GZIP, sendo que o mais rápido (mas com menor compactação) é o LZO que em alguns cenários é melhor como rapidez de restauro da máquina virtual, mas como não se trata de uma empresa, o meu conselho é o GZIP, apesar de consumir mais recursos do sistema. Os Snapshots são, muito provavelmente, os mais comuns para quem está habituado a usar máquinas virtuais, porque cria uma imagem do sistema à data do Snapshot, comparando a um restauro do sistema em ambientes Windows. Qualquer que seja a opção de backup, devem fazê-lo para um outro disco e não para onde o Proxmox está instalado. Agora sim estão preparados para criar máquinas virtuais e containers.
Conclusão: A percentagem do que foi escrito nestes dois artigos sobre o Proxmox é uma gota no imenso oceano que é a plataforma, porque está recheado de opções e pequenos pormenores que fazem depois diferença em ambientes empresariais, para usarem em casa estas são as bases essenciais.
