Cluster LXD com Ceph: containers e VMs com alta disponibilidade

Para provedores e empresas de hospedagem, o LXD é uma alternativa enxuta aos hipervisores tradicionais: gerencia containers de sistema e máquinas virtuais no mesmo cluster, com uma API completa e pouca sobrecarga. Combinado com o Ceph como storage, permite mover cargas entre servidores e sobreviver à queda de um host sem perder dados.

Neste tutorial você vai entender como um cluster LXD com Ceph funciona, o que muda entre containers e VMs, como ficam a migração e a alta disponibilidade, as opções de rede e as decisões de dimensionamento que precisam ser tomadas antes da instalação.

O que é o LXD

O LXD é um gerenciador de containers e máquinas virtuais mantido pela Canonical. Ele expõe tudo por uma API REST, usada pela linha de comando lxc, pela interface web e por ferramentas de automação. Os principais conceitos:

• Instâncias: containers ou VMs, criados a partir de imagens.
• Perfis: conjuntos reutilizáveis de configuração (CPU, memória, discos, rede) aplicados às instâncias.
• Pools de storage: onde ficam os discos, que podem ser locais (ZFS, LVM, diretório) ou remotos (Ceph).
• Projetos: separam instâncias, perfis e redes, com limites de recursos por projeto, útil para separar clientes ou ambientes.

Desde 2023 existe também o Incus, um fork comunitário do LXD com a mesma base. Os conceitos deste tutorial valem para os dois.

Containers de sistema e VMs

Diferente do Docker, que roda uma aplicação por container, o LXD roda containers de sistema: um sistema operacional completo, com init, serviços e usuários, que se comporta como uma VM, mas compartilha o kernel do host.

Poder escolher por instância, no mesmo cluster e com as mesmas ferramentas, é uma das maiores vantagens do LXD.

Como funciona o cluster

Vários servidores LXD formam um cluster que compartilha a mesma configuração, os mesmos perfis, redes e pools de storage. Qualquer membro aceita comandos para o cluster inteiro:

# Membros do cluster e o estado de cada um
lxc cluster list

# Cria uma instância em um membro específico, no pool do Ceph
lxc launch ubuntu:24.04 web01 --target host2 --storage remoto

O estado do cluster fica em um banco de dados distribuído, replicado entre os membros por consenso. Por isso o mínimo para tolerar a falha de um membro é três servidores: com dois, a queda de um deixa o outro sem maioria, e o cluster para de aceitar alterações.

Por que Ceph como storage

Com storage local (ZFS ou LVM em cada servidor), os discos de uma instância ficam presos ao host. Se ele cair, a instância cai junto, e mover para outro servidor exige copiar o disco inteiro pela rede.

Com o Ceph, os discos ficam distribuídos e replicados entre os servidores. O LXD suporta três formas de uso:

• Ceph RBD: discos em bloco para containers e VMs, a forma principal;
• CephFS: volumes de arquivos compartilhados entre várias instâncias ao mesmo tempo;
• Ceph Object: buckets compatíveis com S3, gerenciados pelo próprio LXD.

O Ceph pode rodar nos mesmos servidores do LXD (hiperconvergido) ou em servidores separados. A Canonical oferece o MicroCeph para simplificar a instalação, e o MicroCloud, que junta LXD, MicroCeph e MicroOVN em um único processo de implantação. Para entender como escolher entre réplica e erasure code, veja o tutorial de erasure code no Ceph.

Migração, evacuação e alta disponibilidade

Com os discos no Ceph, mover uma instância entre servidores não exige copiar dados, só transferir a execução:

# Move a instância para outro membro
lxc move web01 --target host3

# Manutenção: tira todas as instâncias de um membro
lxc cluster evacuate host2

# Depois da manutenção, devolve as instâncias
lxc cluster restore host2

• VMs podem ser migradas em execução, sem desligar, quando a migração com estado está habilitada.
• Containers normalmente são movidos com uma reinicialização de poucos segundos.
• Evacuação automática: com o parâmetro cluster.healing_threshold, o LXD reinicia em outros membros as instâncias de um servidor que ficou fora do ar por mais tempo que o limite definido.

A evacuação automática resolve a queda de um host, mas cria um risco: se o problema for de rede e não do servidor, a mesma instância pode acabar rodando em dois lugares. Isso exige cuidado com o limite de tempo, com a rede do cluster e com testes antes de ativar em produção.

Rede: bridges, VLANs e OVN

O LXD oferece vários tipos de rede, e a escolha define como os clientes e serviços vão se comunicar:

• Bridge com VLANs: cada instância ligada a uma VLAN da rede física. Simples, mas toda VLAN precisa existir em todos os servidores e switches.
• Macvlan e SR-IOV: acesso direto à rede física, com mais desempenho e menos flexibilidade.
• OVN: redes virtuais que existem no cluster inteiro, com roteamento, NAT, balanceamento e ACLs, sem criar VLANs nos switches. É a opção para redes isoladas por cliente ou projeto.

O OVN precisa de uma rede física de saída (uplink) bem planejada, com IPs públicos roteados ou anunciados por BGP, e é a parte que mais costuma dar trabalho na implantação.

O que dimensionar antes

Algumas decisões são fáceis de tomar no início e caras de mudar depois:

• Número de servidores. Três é o mínimo; quatro ou mais dão folga para manutenção e recuperação do Ceph.
• Hiperconvergido ou separado. Ceph nos mesmos servidores economiza hardware, mas compete por CPU e memória com as instâncias.
• Rede do Ceph. Interfaces dedicadas e rápidas (25 Gbps ou mais) para o tráfego do Ceph, separadas do tráfego das instâncias. Rede lenta é a causa mais comum de desempenho ruim.
• Discos. NVMe para cargas sensíveis a latência; HDD só para dados frios e backups.
• Memória. O Ceph consome alguns GB por disco, e isso precisa ser descontado do que sobra para as instâncias.
• Modelo de rede. VLANs ou OVN, e como os IPs públicos chegam às instâncias.

Do tutorial à produção

Com os conceitos claros, um cluster de testes sobe em uma tarde. Uma cloud em produção, que hospeda clientes e sobrevive a falhas, exige o que fica fora deste tutorial:

• Projeto do hardware e da rede. Servidores, discos, interfaces e switches dimensionados para a carga real e para a recuperação após falhas.
• Ceph ajustado. Pools, réplica ou erasure code, classes de disco e regras de distribuição para cada tipo de uso.
• Rede OVN e IPs públicos. Uplinks, anúncio por BGP, redes isoladas por cliente e regras de segurança.
• Alta disponibilidade testada. Evacuação automática configurada com segurança e testes de queda de host antes de colocar clientes.
• Operação. Backups, monitoramento, atualizações sem parada e integração com o portal do cliente.

Perguntas frequentes

Qual a diferença entre LXD e Incus?

O Incus é um fork do LXD criado em 2023 pela comunidade Linux Containers, depois que a Canonical assumiu o controle do LXD. Os dois têm a mesma origem, conceitos e comandos muito parecidos, mas seguem caminhos separados desde então. Os conceitos deste tutorial valem para ambos.

Quantos servidores são necessários para um cluster LXD?

Para o banco de dados do cluster tolerar a falha de um membro, são necessários pelo menos três. Com Ceph no mesmo hardware, três também é o mínimo para réplica 3, mas quatro ou mais hosts permitem que o Ceph se recupere sozinho quando um falha.

Containers LXD são seguros para hospedar clientes?

Os containers do LXD são sem privilégio por padrão, o que isola bem o processo do container do host. Ainda assim, todos compartilham o mesmo kernel. Para clientes que precisam de kernel próprio, módulos específicos ou isolamento máximo, use máquinas virtuais, que o LXD gerencia no mesmo cluster.

Dá para migrar uma VM entre hosts sem desligar?

Sim. Com storage compartilhado no Ceph e a migração com estado habilitada na VM, o LXD move máquinas virtuais em execução entre os membros do cluster. Containers normalmente são movidos com uma reinicialização rápida, já que os discos estão no Ceph e não precisam ser copiados.