Proxmox em servidor dedicado alugado: quando faz sentido

Comprar três servidores, colocá-los em colocation e montar o cluster é o desenho clássico — e exige capital imobilizado antes de qualquer receita. Alugar servidor dedicado inverte isso: custo mensal, zero investimento inicial, entrega em horas em vez de meses.

É um caminho legítimo e com restrições específicas. Vale conhecê-las antes, porque algumas só aparecem quando você tenta montar cluster.

O que o modelo resolve

Nenhum capital imobilizado. Custo operacional desde o primeiro mês, sem aprovação de investimento.
Entrega rápida. Servidor disponível em horas; prazo de aquisição de hardware próprio é medido em meses.
Hardware é problema do fornecedor. Disco que falha, fonte que queima, garantia — não é sua.
Datacenter, energia e link inclusos, com redundância que você não precisou projetar.
Reversível. Dimensionou errado? Troca de plano ou devolve.

Para quem está validando demanda, esse conjunto é difícil de superar. Você descobre o consumo real dos seus clientes sem comprometer caixa — e depois dimensiona o cluster próprio com dados em vez de estimativa.

O que o modelo custa

Margem menor por cliente. O aluguel embute a margem do fornecedor. Ao longo de três anos, hardware próprio em colocation costuma sair bem mais barato.
Menos controle sobre o hardware. Você pega o que o catálogo oferece, não o que dimensionou.
Menos controle sobre a rede — e é aqui que estão as restrições sérias.

As restrições de rede, que são o ponto central

Esta é a parte que não aparece no site do fornecedor e decide o desenho inteiro.

A rede entre os servidores

Cluster Proxmox precisa de rede de baixa latência entre os nós para o quórum, e de rede rápida e dedicada para storage distribuído. Em dedicado alugado, você normalmente tem uma interface pública e, dependendo do fornecedor, uma rede privada opcional.

As consequências:

Corosync sobre a internet pública não é desenho. Latência variável faz o cluster perder quórum e reiniciar nós sozinho, de forma intermitente e difícil de diagnosticar. Se o fornecedor oferece rede privada entre os servidores, ela é obrigatória; se não oferece, cluster não é uma boa ideia ali.
Ceph exige rede dedicada e rápida. Sem rede privada de capacidade adequada entre os nós, storage distribuído entrega desempenho ruim de forma constante. Na maioria dos ambientes de dedicado alugado, Ceph não é o caminho — replicação ZFS entre dois nós costuma ser a opção realista.
Servidores podem não estar no mesmo rack, nem no mesmo andar. Latência entre eles varia conforme o fornecedor aloca, e você não controla.

Os endereços IP

Como as VMs recebem endereço muda completamente em relação ao datacenter próprio:

Você recebe um bloco de endereços, ou endereços avulsos cobrados individualmente.
Alguns fornecedores exigem que o tráfego saia com o MAC registrado da máquina física, o que impede simplesmente colocar a VM em bridge com endereço público.
A solução usual é roteamento: o host roteia o bloco para as VMs, em vez de pontear. Funciona bem e exige configuração consciente.
DNS reverso costuma ser configurável pelo painel do fornecedor — importante se você vai hospedar correio.

Rede entre clientes

Isolar clientes em VLANs próprias — o que é obrigatório ao vender cloud — depende de a rede privada do fornecedor suportar segmentação. Quando não suporta, a alternativa é rede sobreposta por software, que adiciona uma camada a operar.

A questão da redundância

O ponto que mais confunde: o fornecedor garante a infraestrutura, não a sua aplicação.

Se o servidor falhar, o fornecedor troca o hardware. Isso leva horas, e as suas VMs ficam fora o tempo todo.
Alta disponibilidade de verdade continua exigindo mais de um nó e storage acessível por ambos.
Com dois dedicados e replicação ZFS, você sobrevive à perda de um — perdendo o que mudou desde a última replicação.

Ou seja: dedicado alugado não dispensa o desenho de redundância, só tira de você o problema de consertar o hardware.

E o quórum continua valendo: dois nós precisam de um terceiro votante, que pode ser uma VPS barata em outro fornecedor — o que, por sinal, é uma das poucas vantagens de rede nesse modelo, já que o árbitro fica naturalmente fora do mesmo destino de falha.

Quando faz sentido

Faz sentido quando:

Você está validando demanda antes de comprometer capital. É o caso mais forte.
O volume ainda é pequeno e não justifica três servidores comprados.
Você precisa de um segundo site para backup externo ou disaster recovery, sem montar outro datacenter.
Há necessidade de presença geográfica onde você não tem estrutura.
O orçamento é operacional, não de investimento — restrição comum em empresa que prefere despesa a imobilizado.

Não faz sentido quando:

O volume já justifica hardware próprio; a margem perdida passa a ser significativa.
Você precisa de Ceph e o fornecedor não oferece rede privada adequada.
Há exigência de controle sobre a localização física e a cadeia de custódia do dado.
A carga é intensiva em I/O e você precisa escolher o perfil de disco.

O desenho que funciona bem

Para quem vai nesse caminho, o arranjo que recomendamos:

Dois dedicados no mesmo fornecedor, com rede privada entre eles — confirmada antes de contratar.
QDevice em uma VPS barata, de preferência em outro fornecedor ou outra região, como terceiro votante.
ZFS local em cada nó, com replicação programada entre eles — e o RPO dessa replicação escrito no seu acordo de serviço.
Endereços roteados para as VMs, com DNS reverso configurado.
Proxmox Backup Server em um terceiro local, nunca no mesmo fornecedor dos nós de produção.
Firewall do Proxmox ativo, com a interface de gestão acessível apenas por VPN — porque aqui o host tem endereço público, e isso é bem mais exposto que num datacenter próprio.

O item 6 merece ênfase. Interface de gestão de hipervisor com endereço público é a situação de maior risco deste artigo, e é a configuração padrão em dedicado alugado. Resolver isso é a primeira tarefa, não a última.

O caminho de saída

Se o plano é migrar para infraestrutura própria depois, vale preparar desde o começo:

Infraestrutura como código desde o primeiro dia, para que recriar o ambiente seja aplicar o código.
Backup externo, que já é o seu mecanismo de migração.
Medir o consumo real por cliente — é esse dado que vai dimensionar o cluster próprio corretamente.

Com essas três coisas, a migração para colocation deixa de ser projeto e vira procedimento.

Erros comuns

Corosync sobre a internet pública, com cluster perdendo quórum de forma intermitente.
Tentar Ceph sem rede privada adequada entre os nós.
Supor que o fornecedor garante a disponibilidade das suas VMs.
Interface de gestão do Proxmox exposta com endereço público.
Não verificar se há rede privada entre os servidores antes de contratar.
Pontear VM com endereço público onde o fornecedor exige roteamento.
Backup no mesmo fornecedor dos nós de produção.
Dois nós sem terceiro votante.
Não escrever o RPO da replicação ZFS no acordo com o cliente.
Ficar no aluguel depois que o volume já justificava hardware próprio.
Não medir consumo real, e dimensionar o cluster futuro por estimativa.

Onde a Solvefy/Cloud entra

Como parceiros oficiais Proxmox, montamos os dois desenhos e a ponte entre eles. Em dedicado alugado: validação dos requisitos de rede antes da contratação, cluster com QDevice externo, replicação ZFS com RPO definido, endereços roteados, backup em terceiro local e a interface de gestão fechada atrás de VPN. E, quando o volume justifica, conduzimos a migração para o cluster próprio dimensionado com o consumo real que você já mediu — com infraestrutura como código desde o início, para que a travessia seja procedimento e não projeto.

Quer começar sem imobilizar capital e com o caminho de saída pronto? Fazemos um diagnóstico gratuito, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.