Como funciona implantação de Proxmox: fases para provedores e empresas

De que peças o Proxmox VE é feito

O Proxmox VE é um Debian com um conjunto de ferramentas de virtualização já integradas e uma interface web para controlar tudo. Entender as peças ajuda a ler a proposta e o relatório de entrega.

• KVM e QEMU: rodam as máquinas virtuais completas, com sistema operacional próprio, inclusive Windows.
• LXC: roda contêineres, que dividem o núcleo do Linux do servidor e gastam menos memória que uma máquina virtual.
• Corosync: leva as mensagens entre os nós e conta os votos do cluster.
• Sistema de arquivos do cluster: copia a configuração de todas as máquinas para todos os nós, para que qualquer um consiga religar qualquer máquina.
• Gerente de alta disponibilidade: vigia as máquinas marcadas como críticas e as religa em outro nó quando o delas cai.
• ZFS ou Ceph: guardam os discos das máquinas, com cópia programada ou distribuída entre os nós.

Tudo isso é controlado pela interface web, aberta no navegador a partir de qualquer nó. A Táquion Tech configura essas peças na implantação de Proxmox e deixa a interface acessível só pela rede de gerência, longe da rede dos usuários e dos assinantes.

Máquina virtual ou contêiner?

A escolha é feita sistema por sistema, ainda no levantamento. Contêiner economiza memória, mas só roda Linux e depende do núcleo do servidor; máquina virtual isola mais e aceita qualquer sistema.

Como funciona implantação de Proxmox na ordem em que acontece

A implantação segue sete fases numa ordem que o próprio Proxmox impõe: primeiro os nós, depois o cluster, depois os discos e o backup, e só no fim os sistemas. Inverter essa ordem obriga a reinstalar nós.

Os prazos em dias saem depois do levantamento: [PREENCHER prazo típico por fase]. O que faz o esforço subir, como Ceph ou máquinas vindas do VMware, está explicado no guia sobre quanto custa implantação de Proxmox.

Por que o nome e o endereço do nó precisam ser definitivos

Porque o cluster grava o nome e o endereço de cada nó na configuração compartilhada e nos certificados internos. Trocar um deles depois da formação do grupo costuma exigir tirar o nó do cluster e reinstalá-lo [CONFIRMAR na documentação].

Na prática: os comandos que formam o cluster

A formação do cluster cabe em poucos comandos, e o que importa é o que eles definem: os dois caminhos de rede do Corosync e quais máquinas ficam sob vigilância. O bloco abaixo mostra a sequência típica.

Quem cuida da empresa não precisa rodar nada disso, mas pode pedir a saída do último comando de conferência no relatório de entrega. Ela mostra quantos nós votam e se o cluster tem quórum.

# No primeiro nó: cria o cluster com dois caminhos de rede
pvecm create cluster-empresa --link0 198.51.100.11 --link1 203.0.113.11

# Em cada nó seguinte: entra no grupo apontando para o primeiro
pvecm add 198.51.100.11 --link0 198.51.100.12 --link1 203.0.113.12

# Confere os votos e o quórum
pvecm status

# Coloca a máquina 101 sob alta disponibilidade
ha-manager add vm:101 --state started --max_restart 1 --max_relocate 1

# Replica o disco da máquina 101 para o nó pve2 a cada 15 minutos (ZFS)
pvesr create-local-job 101-0 pve2 --schedule "*/15"

O intervalo da replicação é uma decisão de negócio, e não só técnica. Com cópia a cada 15 minutos, uma máquina que sobe no outro nó volta com os dados de até 15 minutos atrás; o Ceph evita essa perda, mas pede rede própria e pelo menos três nós.

O que a empresa ou o provedor separa antes da instalação?

Separe servidores com virtualização ativada, endereços e nomes definitivos, VLANs no switch e acesso ao console de cada servidor. Sem o console, uma implantação remota para no primeiro reinício.

• Virtualização ligada no servidor: a opção de virtualização do processador ativada na configuração da placa, sem a qual o Proxmox não roda máquinas virtuais.
• Discos entregues direto: controladora em modo de passagem, quando o desenho usa ZFS ou Ceph [CONFIRMAR na documentação].
• Endereços e nomes: um IP fixo de gerência e um nome por nó, escolhidos de vez.
• VLANs no switch: gerência, cluster, armazenamento e sistemas, com as portas de cada servidor marcadas.
• Lugar para as cópias: um equipamento separado para o Proxmox Backup Server, de preferência em outra sala ou outro POP.
• Responsável por janela: quem libera o horário e testa o sistema depois de cada migração.

Por que o console remoto do servidor é obrigatório

A implantação de Proxmox é feita por acesso remoto para todo o Brasil, e a instalação começa antes de existir sistema operacional. Só a placa de gerência do próprio servidor, que mostra a tela e monta a imagem de instalação à distância, permite instalar e recuperar um nó sem alguém na frente dele.

Servidores sem essa placa ainda funcionam, mas cada reinício que dá errado vira uma ligação para alguém da empresa ir até a sala. Vale combinar quem atende essas ligações antes da primeira janela.

Erros que travam cada fase e o sinal de cada um

Os erros mais comuns aparecem como nós que saem e voltam do cluster, cópias que param e máquinas que sobem no nó errado. Cada um tem um sinal que dá para ver antes da entrega.

• Instalação com versões diferentes: um nó instalado com outra versão entra no cluster, mas a migração entre nós falha ou dá aviso.
• Corosync na rede de dados: no horário de pico, o registro mostra nós perdendo e recuperando o quórum, e o gerente de alta disponibilidade reinicia um nó sem motivo aparente.
• Relógios desencontrados: os eventos dos nós não batem no horário e a autenticação entre eles começa a falhar.
• Replicação sem espaço: o pool de ZFS enche com as cópias programadas e a tarefa passa a falhar em silêncio.
• Grupo de alta disponibilidade aberto demais: uma máquina é religada num nó que não enxerga o disco dela e não sobe.
• Máquina sem agente instalado: sem o agente do QEMU, o desligamento e a cópia não conversam com o sistema dentro da máquina.

O primeiro sinal de quase todos esses erros aparece no registro de tarefas da interface ou numa mensagem de alerta, desde que alguém leia. Por isso os alertas por e-mail ou pelo Zabbix são ligados antes da migração, e não depois.

Como escolher a ordem de migração dos sistemas

A regra é começar pelo que pode parar e terminar pelo que não pode. O monitoramento vai primeiro, porque, já dentro do cluster, ele vigia a migração dos outros sistemas.

1. Monitoramento e registros: se algo der errado, ninguém de fora percebe.
2. Sistemas em par: um DNS de cada vez, enquanto o outro responde sozinho.
3. Sistemas internos: arquivos e ferramentas da equipe, numa janela fora do expediente.
4. Sistemas críticos: autenticação de assinantes e ERP por último, com o fornecedor acompanhando quando for preciso.

Exemplo: como funciona implantação de Proxmox num provedor regional

O caso é ilustrativo e junta situações frequentes em provedores com alguns milhares de assinantes. Ele mostra o caminho completo, do levantamento à entrega.

O provedor roda o servidor de autenticação dos assinantes, dois DNS recursivos, o Zabbix e o ERP, cada um num servidor físico diferente, quase todos sem garantia. A decisão é montar três nós com ZFS replicado.

1. Levantamento: o DNS vira contêiner, os demais viram máquinas virtuais, e a ordem de migração é combinada com o dono.
2. Instalação e cluster: os três nós recebem o Proxmox VE pelo console remoto e formam o grupo com dois caminhos de rede.
3. Backup: um servidor de cópias é montado em outro POP, e uma máquina de teste é restaurada antes de tudo.
4. Migração: o Zabbix muda primeiro; depois um DNS, outro DNS, a autenticação numa madrugada e o ERP num domingo.
5. Prova: o nó que roda a autenticação é desligado; a máquina sobe em outro nó em minutos, e quem já estava conectado segue navegando [CONFIRMAR no concentrador].

O detalhe que só aparece na prova é que, durante a troca, apenas os assinantes que tentam conectar de novo precisam esperar. O guia sobre como funciona a implantação de clusters de virtualização explica a diferença entre essa troca e a migração planejada, e o de implantação de DNS recursivo mostra por que o par de DNS aguenta a mudança sem parada.

O que fica com a sua equipe depois da entrega

Fica um cluster com alertas ligados, cópias agendadas e restauradas uma vez, e os roteiros para operar sem quem implantou. A lista serve para conferir a entrega.

Perguntas frequentes

Thiago Manoel

Responsável técnico da Táquion Tech · Registro profissional [PREENCHER]

Mais de 15 anos em operações de rede, com gestão de infraestruturas de TI, administração de data centers e condução de equipes em migrações de TI e telecomunicações, com foco em alta disponibilidade e segurança.

A Táquion Tech é uma empresa de engenharia de redes de Balneário Camboriú (SC) que projeta, opera e dá suporte a redes de provedores de internet e de empresas.

Conheça a equipe da Táquion Tech