A Fronteira Entre Testes e Negócios

Um dos erros mais comuns cometidos por administradores de sistemas iniciantes é tentar transpor diretamente as simplificações adotadas em um ambiente de laboratório doméstico (Homelab) ou de testes para a infraestrutura de produção corporativa.

Em laboratório, a tolerância a falhas é alta, o custo é o limitador principal e o downtime afeta poucas pessoas. Em produção, a indisponibilidade gera impacto financeiro direto, e a arquitetura deve ser desenhada para mitigar pontos únicos de falha em todas as camadas (Compute, Network, Storage, Power).

🏢

Definição de Produção

Ambientes produtivos corporativos exigem acordos de nível de serviço (SLAs). Para garantir alta disponibilidade (HA) real no Proxmox VE, a arquitetura física e lógica deve ser tratada de forma estrita, sem atalhos operacionais.

Requisitos de Quorum e o Problema de 2 Nós

Para criar um cluster Proxmox VE com suporte a Alta Disponibilidade (HA) automatizada, o sistema operacional precisa manter o quorum. O quorum é o consenso de que a maioria dos nós está online e operando em conjunto.

A Regra da Maioria: Um cluster precisa de mais de 50% dos votos ativos para tomar decisões de gerenciamento ou iniciar failovers.
O Cenário de 2 Nós: Se você criar um cluster com apenas 2 nós e um deles falhar, o nó restante terá apenas 50% dos votos. Sem quorum (maioria estrita), o nó sobrevivente bloqueia escritas no sistema de arquivos /etc/pve e se recusa a iniciar as VMs do nó que caiu. Isso é uma medida de proteção contra o cenário de Split-Brain (onde os dois nós perdem a comunicação entre si, mas continuam ativos, tentando assumir os mesmos IPs e discos, corrompendo os dados).
A Solução para Produção:
- Mínimo de 3 nós físicos ativos no cluster.
- Alternativa de custo otimizado: 2 nós físicos + 1 QDevice (Quorum Device). O QDevice é um serviço leve (geralmente rodando em um micro PC ou Raspberry Pi externo) que atua apenas como terceiro voto de desempate, sem hospedar VMs.

Storage Local vs. Storage Compartilhado

A flexibilidade de storages no Proxmox VE altera significativamente as capacidades de recuperação de desastres do ambiente:

Storage Local (Laboratório): Utiliza SSDs ou HDDs conectados diretamente ao host físico (via LVM-thin, ZFS local ou diretórios). Se o host queimar, as VMs estão inacessíveis até que os discos físicos sejam fisicamente movidos para outro host ou restaurados a partir de backups.
Storage Compartilhado (Produção): As imagens de disco das VMs residem em uma estrutura acessível por todos os hosts do cluster simultaneamente.
- Exemplos: NAS/SAN dedicada via NFS ou iSCSI, ou uma solução hiperconvergente como o Ceph, que une os discos de todos os nós em um único pool redundante distribuído pela rede.
- Benefício: Permite Live Migration (migração de VMs sem interrupção de serviço) e Alta Disponibilidade (se um nó físico morrer, os nós sobreviventes iniciam as VMs afetadas imediatamente, pois têm acesso direto aos discos virtuais).

Desenho de Rede em Produção

Enquanto um laboratório utiliza apenas uma interface de rede Gigabit padrão compartilhada para tudo, uma infraestrutura de produção exige a separação física ou lógica (VLANs) dos fluxos de tráfego críticos:

Tráfego de Redes no Proxmox VE:
├── Rede Corosync (Baixa latência, dedicada apenas para manter o quorum do cluster)
├── Rede de Storage (Altíssima largura de banda - ex: 10GbE ou superior para Ceph/iSCSI)
├── Rede de Migração e Backup (Alto throughput para não saturar tráfego de usuários)
└── Rede de Clientes (Tráfego das VMs/Containers conectadas aos usuários)

Para redundância física nas placas de rede, utiliza-se a técnica de Network Bonding (como LACP/802.3ad ou Active-Backup), combinando duas ou mais portas físicas em uma única interface lógica.

Tabela Comparativa: Laboratório vs. Produção

Critério / Item	Cenário de Laboratório	Cenário de Produção
Quantidade de Nós	1 ou 2 nós físicos	Mínimo 3 nós (ou 2 nós + QDevice)
Tipo de Storage	SSD local simples ou ZFS single	Storage compartilhado (Ceph, SAN iSCSI/NFS)
Conexões de Rede	1x link de 1GbE integrado	Mínimo 2x links de 10GbE com LACP (Bonding)
Repositórios de Updates	`pve-no-subscription` (testes rápidos)	`pve-enterprise` (estável e homologado)
Estratégia de Backup	Backups manuais ou locais periódicos	Proxmox Backup Server (PBS) dedicado e externo
Alimentação Elétrica	Fonte simples conectada à tomada	Fontes redundantes ligadas a UPSs (No-breaks) distintos

Procedimento de Verificação de Quorum

Para diagnosticar a saúde de um cluster e verificar a quantidade de votos e estado de quorum atual, utilize a CLI do Proxmox VE.

status-cluster.sh bash

Verificar o status de comunicação e votos do cluster

pvecm status

Listar os nós que pertencem ao cluster ativo

pvecm nodes

Validação

Você entendeu a aula se consegue responder:

Por que um cluster de 2 nós sem QDevice não é adequado para cenários de Alta Disponibilidade (HA) em produção?
Qual a diferença operacional de um desastre em um host usando Storage Local vs. Storage Compartilhado?
O que é o cenário de Split-Brain e como o quorum o evita?
Por que a rede do Corosync deve ser isolada de redes de backup e tráfego de storage?

Boas Práticas

Use Repositórios Enterprise: Em produção, desative o repositório no-subscription e ative o repositório de subscrição oficial. Isso garante pacotes exaustivamente testados, evitando bugs surpresa em atualizações.
Implemente o Proxmox Backup Server (PBS): Em vez de fazer backups simples via VZDump em storages de rede comuns, utilize um servidor PBS dedicado. O PBS realiza deduplicação na origem, criptografia forte e backups incrementais extremamente velozes, poupando rede e storage.
Mantenha redundância de switches: Conecte os links do seu LACP (Bonding) em switches físicos diferentes (utilizando empilhamento ou tecnologias como vPC/MLAG) para evitar que a falha de um switch de rede derrube o host.

Laboratório vs. produção

🎯 Objetivos desta aula

🔑 Pré-requisitos