Ceph: a jornada rumo a 1 TiB/s

Ceph: a jornada rumo a 1TiB/s

• Um artigo sobre a jornada de melhoria de desempenho de um cluster Ceph, contando como, após um longo processo de depuração e otimização de performance, foi alcançada uma taxa de processamento de dados de 1TiB/s.
• Compartilha vários problemas técnicos e suas soluções que surgiram enquanto a empresa Clyso ajudava a construir um cluster Ceph de 10 petabytes baseado em NVMe.
• A rede do cliente é extremamente rápida, sendo uma das configurações Ethernet mais velozes disponíveis.

Agradecimentos

• Agradece ao cliente da Clyso, cuja colaboração tornou possível compartilhar essa experiência com a comunidade Ceph.
• Também agradece à IBM/Red Hat e à Samsung por fornecerem o hardware usado nos testes comparativos.
• Estende agradecimentos aos contribuidores do Ceph por seus esforços em tornar o Ceph um excelente software.

Configuração do cluster

• O cliente propôs 34 nós 2U de soquete duplo distribuídos em 17 racks, mas a Clyso sugeriu várias configurações usando nós menores.
• No fim, a arquitetura da Dell foi escolhida para reduzir custos e oferecer maior largura de banda de memória, mais recursos de CPU e maior throughput de rede.
• Isso também reduziu pela metade o impacto da recuperação do cluster em caso de falha de um nó.

Configuração de testes

• Um cluster Ceph temporário foi implantado com CBT, e foram executados testes com FIO.
• Foram usados testes de FIO baseados em biblioteca para dividir o cluster em unidades menores e comparar com resultados anteriores.
• Foram testadas replicação 3X e codificação de apagamento 6+2, além da versão 2 de mensagens nos modos criptografado e seguro.

Atenção à quantidade de PGs

• Foi testado experimentalmente o impacto da quantidade de PGs no desempenho.
• Uma quantidade alta de PGs pode ter efeito positivo na performance, mas em produção isso deve ser considerado junto com outras configurações.

O que tornou o começo difícil

• Após o primeiro login no hardware, houve dificuldade para resolver os problemas devido ao desempenho abaixo do esperado.
• Os testes iniciais de performance foram bons, mas houve degradação ao testar com vários OSDs.

Comportamento estranho

• Ao executar várias combinações de testes com OSDs, foi descoberto um padrão anormal de desempenho.
• Observou-se que, após testes com múltiplos OSDs, o sistema perdia desempenho e só se recuperava algumas horas depois.

Três soluções

• O problema de latência causado pela transição de CPU c-state foi resolvido, melhorando ligeiramente a performance.
• Desativar o IOMMU trouxe uma grande melhora de desempenho.
• Um problema nas flags de compilação do RocksDB foi corrigido, dobrando a performance de escrita aleatória 4K.

A primeira semana de 2024

• No primeiro dia do ano, uma grande falha em outro cluster impediu foco total nos testes de performance.
• Na sexta-feira, os testes foram retomados e confirmou-se que o cluster funcionava bem mesmo sob alta carga.

O sorriso do destino

• Com a melhora dos resultados, confirmou-se que o cluster escalava de forma linear.
• Em um cluster com 63 nós, foi alcançada uma taxa de processamento de dados de 635GiB/s.

Uma Estrela da Morte parcialmente funcional

• Como faltavam nós de cliente, foi necessário compartilhar os nós OSD com os processos do FIO.
• Mesmo nessa configuração, foi alcançado desempenho próximo de 950GiB/s.

Alcançando 1TiB/s

• Ajustando a quantidade de shards de OSD e o número de threads do messenger, foi alcançada uma taxa de processamento de dados de 1TiB/s.

Dormir; codificação de apagamento

• Após testar com replicação 3X, o cluster foi reconfigurado e testado com a codificação de apagamento 6+2 que o cliente usaria.
• A performance de leitura ultrapassou 500GiB/s, e a de escrita chegou a quase 400GiB/s.

Opinião do GN⁺:

1. Este artigo descreve em detalhes o processo de otimização de desempenho de um cluster Ceph e oferece insights técnicos ao mostrar um caso real de obtenção de alta performance por meio de uma resolução de problemas complexa.
2. Mostra como a colaboração com o cliente, o esforço dos contribuidores da comunidade e várias estratégias de otimização de hardware e software podem gerar grandes resultados no mundo real.
3. O texto oferece informações úteis não só para especialistas que trabalham com sistemas de armazenamento de dados em larga escala, mas também para profissionais interessados em otimização de desempenho.

[GN⁺]

Comentários no Hacker News

• A marca de 1 TB/s no CERN e a história do Ceph
  • Um usuário menciona que o CERN alcançou uma velocidade de 1 TB/s com o cluster EOS, explicando que esse cluster usa principalmente HDDs e tem mais nós. Também compartilha a história interessante de que o Ceph foi criado na Dreamhost por necessidade interna e depois adquirido pela Red Hat.
• Experiência de um antigo líder técnico e apreço pelo Ceph
  • Um usuário relembra sua experiência trabalhando como líder técnico na Cisco, configurando Kubernetes em bare metal e experimentando GlusterFS e Ceph, dizendo que gostava dessas experiências. Também elogia o texto por ter sido bem escrito.
• Sugestão de reduzir o tamanho dos nós
  • Um usuário aponta que o consumo de energia por nó no sistema atual é alto e sugere um esforço de engenharia para reduzir o tamanho dos nós. Com isso, argumenta que menos nós já seriam suficientes e que seria possível reduzir o impacto de uma falha única sobre 10 discos.
• Perspectiva histórica sobre o volume de armazenamento de dados digitais
  • Um usuário comenta que, em algum momento nos últimos 60 anos, deve ter existido um dia em que 1 TiB de dados digitais foi armazenado pela primeira vez no mundo, e expressa espanto pelo fato de hoje essa quantidade de dados ser movimentada a cada segundo.
• Experiência de melhora de desempenho do cache do Docker com um cluster Ceph
  • Um usuário compartilha que opera um cluster de armazenamento Ceph para manter o cache de camadas do Docker e que, após migrar de EBS para Ceph, o throughput melhorou bastante. Ele também comenta que o Ceph quase não exige manutenção.
• Problemas com software de controlador de armazenamento dentro do Kubernetes
  • Um usuário afirma que o maior problema relacionado a armazenamento dinâmico dentro do Kubernetes não está no I/O, mas no software do controlador de armazenamento quando ele enfrenta problemas reais. Em especial, relata ter passado por situações em que PVCs só eram anexados depois de muito tempo ao usar rook/ceph e Longhorn.
• Análise do desempenho de 1 TiB/s frente ao limite teórico do hardware
  • Um usuário analisa como o desempenho de 1 TiB/s se compara ao limite teórico do hardware e aponta que a rede está causando o gargalo. Também conclui que a complexidade do Ceph impõe uma carga considerável à CPU e que o modelo de threading do OSD não está otimizado, manifestando esperança de melhorias.
• Pedido de comparação entre Ceph e outros motores de armazenamento de objetos
  • Um usuário diz que gostaria de ver comparações e benchmarks entre o Ceph e outros motores de object storage, como MinIO e Garage.
• Pergunta sobre a adequação do Ceph para armazenamento de bancos de dados transacionais e latência de IO
  • Um usuário pergunta se o Ceph é adequado para armazenamento de bancos de dados transacionais e como é a latência de IO, acrescentando que gostaria de migrar para um sistema de arquivos mais barato que possa competir com sistemas como o cluster file system da Oracle ou o Veritas.