Ceph: Uma Jornada até 1 TiB/s

Engenheiros dissecaram um cluster de armazenamento Ceph que alcança mais de 1 TiB/s de throughput de leitura usando 68 servidores com muitos NVMe, focando em onde estão os verdadeiros gargalos (rede vs. PCIe vs. CPU) e o quão perto a configuração chega dos limites teóricos. Muitos ponderam os pontos fortes do Ceph — resiliência, crescimento horizontal e conjunto de recursos — contra sua complexidade e latência, especialmente para homelabs e workloads de banco de dados, e o comparam com alternativas como MinIO, SeaweedFS, Longhorn, GlusterFS, ZFS, btrfs e EOS. A conversa também aborda escolhas práticas de hardware, de switches e NICs 100 GbE+ até clusters com Raspberry Pi, e a história do Ceph e seu uso no mundo real em ambientes como OpenStack, Kubernetes, CERN e implantações AWS personalizadas.

Hardware e rede para 1 TiB/s

  • A discussão observa que existem switches de 800 Gbps, mas NICs de 800 G ainda não estão disponíveis de forma prática; a contagem de lanes PCIe e as gerações são uma restrição, mas não um bloqueio duro se forem usadas 32 lanes.
  • A maioria dos participantes assume que switches modernos de 100 GbE (pizza-box / leaf-spine / fabrics Clos) conseguem lidar com a taxa máxima em todos os ports; qualquer switch que não consiga é considerado equipamento “toy”.
  • Switches 40/56/100 GbE usados agora estão relativamente baratos; alguns “bargain” MikroTik e switches usados de datacenter são mencionados como amigáveis para homelab.
  • A análise do cluster de benchmark conclui que a rede, e não os drives NVMe, é o gargalo; os 1 TiB/s medidos correspondem a ~65% da capacidade teórica da rede entre os nós.

Características de desempenho do Ceph

  • O Ceph oferece forte escalabilidade e resiliência, mas com sobrecarga de CPU notável e latência relativamente fraca, especialmente em comparação com NVMe local.
  • Os detalhes do benchmark destacam flags de otimização do compilador e contenção entre threads de OSD/IOMMU como fatores de desempenho surpreendentemente grandes; os desenvolvedores admitem que o modelo de threading precisa de redesign.
  • Para bancos de dados transacionais, vários participantes alertam que a latência do Ceph costuma ser alta demais, embora alguns relatem latência de block (RBD) aceitável com bom hardware.

Ceph em homelabs

  • Muitos desaconselham Ceph em casa, a menos que o objetivo seja aprender; os mínimos de hardware (múltiplos nós, rede rápida, discos não-SMR) e a complexidade são reais.
  • Outros executam Ceph com sucesso em clusters Proxmox, mini-PCs, NUCs e até Raspberry Pis/placas ODROID, aceitando menor desempenho e maior latência.
  • Um tema recorrente: Ceph é excelente para resiliência e elasticidade, não para velocidade bruta nem simplicidade.

Alternativas e sistemas relacionados

  • Alternativas comuns para homelab: SeaweedFS, Longhorn, MinIO, Garage, GlusterFS (embora o suporte da Red Hat esteja chegando ao fim), EOS, ZFS (especialmente mirror vdevs), Btrfs, LVM+mdadm e SnapRAID.
  • Trade-offs discutidos:
    • MinIO: bom object store S3, mas sensível a mudanças no tamanho do cluster e exige discos rápidos.
    • Garage: simples, apenas duplicação; adequado para homelabs, não para grandes datasets.
    • ZFS mirrors: expansão incremental fácil e resilvering rápido, mas eficiência de espaço de 50%.
    • EOS no CERN: ajustado para cargas de trabalho de física, complementa o Ceph em vez de substituí-lo.

Complexidade operacional e racional

  • O Ceph é visto como “não implemente a menos que você queira dizer isso”: complexo, mas singularmente bom para armazenamento em hardware commodity, grande, barato, altamente disponível e com escalabilidade linear.
  • Ele sustenta implementações OpenStack/Kubernetes, sistemas internos tipo EBS e caches de alto IOPS, onde usuários relatam grandes ganhos de custo e desempenho em relação ao armazenamento em bloco da nuvem.