/ Nesta edição, temos a segunda parte do guia de instalação do Promox.
No artigo da edição passada apresentámos o Proxmox como plataforma de virtualização, juntamente com factores importantes a levar em conta após a sua instalação. Neste artigo abordaremos essas boas práticas, levando em consideração o objectivo definido: gerir máquinas virtuais.
Montar um servidor 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). Para que o vosso hardware seja compatível com a instalação, é preciso um 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:
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á as opções ‘Suspender’ e ‘Stop’ apresentam um maior período de inactividade 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 - 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 criam 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.