Erasure code no Ceph: combinações k+m, redundância, eficiência e desempenho

Réplica 3 é o padrão do Ceph e o mais simples de operar, mas custa caro: para guardar 1 TB você consome 3 TB de disco. Com erasure code, o mesmo nível de proteção contra falhas pode custar 1,5 TB ou menos, liberando o dobro de espaço útil no mesmo hardware.

Neste tutorial você vai entender como o erasure code funciona, comparar as combinações k+m mais usadas em redundância, eficiência e número de hosts, calcular o cenário do seu cluster, criar os pools para RBD, CephFS e RGW e ver na prática o que acontece quando hosts caem.

Como o erasure code funciona

Em vez de copiar o objeto inteiro várias vezes, o Ceph divide cada objeto em k pedaços de dados e calcula m pedaços de paridade. Os k+m pedaços (chunks) vão para OSDs em domínios de falha diferentes, normalmente hosts diferentes. Qualquer conjunto de k pedaços é suficiente para reconstruir o objeto.

Exemplo com um objeto de 4 MB em um perfil 4+2:

objeto de 4 MB
  ├─ dado 1    1 MB  → host A
  ├─ dado 2    1 MB  → host B
  ├─ dado 3    1 MB  → host C
  ├─ dado 4    1 MB  → host D
  ├─ paridade 1 1 MB → host E
  └─ paridade 2 1 MB → host F

Gravado no total: 6 MB   (réplica 3 gravaria 12 MB)
Pode perder até 2 hosts quaisquer sem perder o objeto

Daí vêm as duas contas que guiam toda a escolha:

• Eficiência (espaço útil sobre o bruto): k / (k+m). No 4+2, 4/6 = 66,7%.
• Overhead (bruto consumido por TB útil): (k+m) / k. No 4+2, 1,5x. Na réplica 3, 3x.
• Falhas sem perda de dados: m.

Combinações k+m comparadas

A tabela considera o domínio de falha por host e o min_size padrão do Ceph para pools EC: k+1 (ou k quando m=1, marcado com *).

O que a tabela mostra:

• 4+2 tem a mesma proteção da réplica 3 (duas falhas sem perda, uma com gravação normal) usando metade do disco.
• 6+3 tem a mesma eficiência do 4+2, mas aguenta uma falha a mais. O preço é precisar de pelo menos 9 hosts e recuperar lendo de mais OSDs.
• Perfis com m=1 (2+1, 4+1) são armadilhas: o Ceph define min_size = k, então após a queda de um único host o pool continua gravando sem nenhuma redundância, e uma segunda falha antes da recuperação perde dados.
• Aumentar k melhora a eficiência, mas exige mais hosts e deixa gravações pequenas e recuperação mais caras.

Calculadora de espaço e falhas

Informe o perfil e o tamanho do cluster para ver o espaço útil e quantas falhas ele aguenta. A conta considera domínio de falha por host e o mesmo espaço bruto em cada host.

No exemplo padrão (7 hosts com 100 TB cada, 700 TB brutos), a réplica 3 entrega 233 TB úteis e o 4+2 entrega 467 TB. Considerando a margem de 20% que todo cluster Ceph deve manter livre, são cerca de 187 TB contra 373 TB.

Perder dados x parar de gravar

Esse é o ponto que mais confunde. O pool EC tem dois limites diferentes:

• Perda de dados só acontece com mais de m pedaços indisponíveis. Com pelo menos k pedaços, o objeto pode ser reconstruído (desde o Octopus, o Ceph recupera com apenas k pedaços).
• Gravações param quando restam menos de min_size pedaços. O padrão (com m de 2 ou mais) e a recomendação da documentação é min_size = k+1, para que nunca se grave um dado com zero margem de proteção.

No 4+2: com 1 host fora, tudo funciona normalmente (5 de 6 pedaços). Com 2 hosts fora, os dados estão íntegros, mas os PGs afetados ficam inativos e as gravações neles param até a recuperação. Reduzir o min_size para k libera as gravações, mas significa gravar sem nenhuma redundância: só faça isso de forma temporária e consciente.

Quantos hosts você precisa

Com crush-failure-domain=host, cada pedaço precisa ficar em um host diferente. Então:

• k+m hosts é o mínimo para o pool funcionar.
• k+m+1 hosts ou mais é o recomendado. Com um host a mais, quando um falha o Ceph reconstrói os pedaços perdidos nos que sobraram e o cluster volta a ficar saudável sozinho. Com exatamente k+m, o pool fica degradado até o host voltar.
• Espaço livre para a recuperação. Ao perder um host, os dados dele são redistribuídos entre os demais. Mantenha ocupação baixa o suficiente para isso caber sem atingir o limite de nearfull.

Em clusters pequenos, com 3 ou 4 hosts, réplica 3 costuma ser a escolha certa. Dá para usar EC com vários pedaços por host via regra CRUSH customizada, mas a queda de um host leva vários pedaços de uma vez e a proteção real fica bem menor do que o m sugere.

Criando o perfil e o pool

O perfil define k, m e o domínio de falha. Ele não pode ser alterado depois que o pool é criado: errou o perfil, só criando outro pool e migrando os dados.

# Perfil padrão do cluster (não use em produção sem revisar)
ceph osd erasure-code-profile get default

# Perfil 4+2 com um pedaço por host
ceph osd erasure-code-profile set ec-42 \
    k=4 m=2 \
    crush-failure-domain=host

# Restringindo a uma classe de disco
ceph osd erasure-code-profile set ec-42-hdd \
    k=4 m=2 \
    crush-failure-domain=host \
    crush-device-class=hdd

ceph osd erasure-code-profile ls
ceph osd erasure-code-profile get ec-42

# Pool usando o perfil
ceph osd pool create dados-ec erasure ec-42
ceph osd pool get dados-ec min_size
# min_size: 5

No Ceph Tentacle (versão 20) ou mais novo, ative as otimizações de erasure code, que melhoram o desempenho de I/O pequeno e eliminam desperdício de espaço com preenchimento. A documentação recomenda um stripe_unit de 16K para uso geral, e ele também só pode ser definido na criação:

ceph osd erasure-code-profile set ec-42-otimizado \
    k=4 m=2 \
    crush-failure-domain=host \
    stripe_unit=16K

ceph osd pool create dados-ec erasure ec-42-otimizado
ceph osd pool set dados-ec allow_ec_optimizations true

O allow_ec_optimizations não pode ser desligado depois de ativado e só funciona com todos os monitores e OSDs no Tentacle ou mais novo.

Usando com RBD, CephFS e RGW

Criar o pool EC é só o começo. Cada forma de acesso ao Ceph tem exigências próprias, e ignorá-las é a causa mais comum de pools EC que "não funcionam" ou ficam lentos:

Em clusters já em produção, mudar dados de um pool replicado para EC não é uma alteração de configuração: exige criar pools novos e migrar os dados, com planejamento de espaço, de desempenho durante a cópia e de rollback.

Simulando a queda de hosts

Em um ambiente de testes com 7 hosts e o pool 4+2, vale ver o comportamento antes de confiar nele em produção. O noout impede que o Ceph comece a redistribuir os dados durante o teste:

ceph osd set noout

# Derruba os OSDs de um host (cephadm)
ceph orch host maintenance enter host3

ceph -s
#   health: HEALTH_WARN
#           noout flag(s) set
#           1 host (12 osds) down
#           Degraded data redundancy: ... pgs degraded, ... pgs undersized
#   → leituras e gravações continuam normalmente

# Segundo host fora
ceph orch host maintenance enter host5
ceph health detail
#   Reduced data availability: ... pgs inactive
#   → PGs com só 4 de 6 pedaços: dados íntegros, gravações paradas (min_size 5)

# Volta tudo
ceph orch host maintenance exit host5
ceph orch host maintenance exit host3
ceph osd unset noout
ceph -s

Sem o noout e com hosts sobrando, depois do intervalo de mon_osd_down_out_interval (10 minutos por padrão) o Ceph marca os OSDs como out e reconstrói os pedaços nos hosts restantes, voltando a ficar saudável sem intervenção.

Desempenho e quando não usar

Erasure code não é de graça. O que muda em relação à réplica:

• Gravações pequenas são mais caras. Alterar parte de um objeto exige ler, recalcular a paridade e regravar. O Tentacle reduziu muito esse custo com o allow_ec_optimizations, mas em versões anteriores a diferença para réplica 3 é grande, principalmente em HDD.
• Mais CPU nos OSDs para codificar e decodificar.
• Recuperação lê de k OSDs para reconstruir cada pedaço, gerando mais tráfego de rede que a réplica. O plugin CLAY (plugin=clay, com o parâmetro d) reduz esse tráfego, útil em clusters grandes com HDD.
• m alto pesa nas gravações. Para blocos e arquivos, a documentação recomenda m de no máximo 3.

Do tutorial à produção

A escolha do perfil é a decisão mais importante, e a mais difícil de desfazer. Mas um cluster Ceph saudável em produção depende de muito mais do que o perfil, e isso fica fora deste tutorial:

• Dimensionamento. Hosts, discos, rede de cluster e de clientes, CPU e memória por OSD para a carga real, com espaço para a recuperação após falhas.
• Migração de réplica para EC. Criação dos pools novos, migração dos dados sem parar as VMs e os serviços, e plano de rollback.
• Desempenho. Testes de carga antes da produção, ajuste de PGs, classes de disco e regras CRUSH por tipo de uso.
• Operação. Monitoramento, alertas de nearfull e PGs degradados, atualizações de versão e procedimentos para troca de discos e hosts.
• Integração. Ceph como storage do Proxmox, OpenStack ou CloudStack, e object storage S3 para clientes.

Perguntas frequentes

Qual a melhor combinação de erasure code no Ceph?

Não existe uma única melhor. Para clusters de 7 a 10 hosts, 4+2 é o ponto de partida mais comum: 66,7% de eficiência e duas falhas sem perda de dados. Clusters maiores podem usar 6+3 ou 8+3 para tolerar três falhas, e 8+2 quando o foco é espaço.

Posso mudar o k e o m de um pool existente?

Não. O perfil de erasure code não pode ser alterado depois que o pool é criado. É preciso criar um novo pool com o perfil desejado e migrar os dados.

Erasure code serve para máquinas virtuais?

Serve, com allow_ec_overwrites e metadados em pool replicado, mas a latência de gravações pequenas é maior que em réplica 3. A partir do Ceph Tentacle, a opção allow_ec_optimizations reduz bastante essa diferença. Para bancos de dados e VMs muito sensíveis a latência, réplica 3 em SSD continua sendo a escolha mais segura.

Quantas falhas um pool 4+2 suporta?

Suporta a perda de 2 hosts (ou OSDs, conforme o domínio de falha) sem perder dados. Com o min_size padrão de k+1 = 5, o pool continua aceitando leitura e gravação com 1 falha; com 2 falhas os dados estão íntegros, mas as gravações param até a recuperação.