Ceph: a jornada rumo a 1 TiB/s
(ceph.io)- A Clyso realizou testes de burn-in antes de migrar um cluster Ceph baseado em HDD para uma implantação NVMe de 10 PB e alcançou 1,0 TiB/s de leitura em um único cluster com 630 OSDs
- O hardware final era composto por 68 Dell PowerEdge R6615 com 10 NVMes por nó, mas o teste de maior desempenho foi feito com os 63 nós disponíveis e 630 OSDs
- Os gargalos iniciais foram resolvidos corrigindo o c-state da CPU no BIOS, a contenção no mapeamento IOMMU do kernel e um problema nas flags de compilação do RocksDB nos pacotes Deb upstream do Ceph para Ubuntu; o tempo de compaction caiu cerca de 3x e a escrita aleatória de 4 KB melhorou 2x
- O pico na configuração com replicação 3X foi de 1025 GiB/s em leitura de 4 MB, 270 GiB/s em escrita de 4 MB, 25,5 M IOPS em leitura aleatória de 4 KB e 4,9 M IOPS em escrita aleatória de 4 KB; com erasure coding 6+2, registrou 547 GiB/s em leitura de 4 MB e 387 GiB/s em escrita
- O risco restante é que, em escritas de grande escala, alguns PGs entram no estado active+clean+laggy, derrubando fortemente o throughput; para obter throughput maior com mais de 10 NVMes por nó, é necessária uma rede de 200 GbE ou mais
Projeto de um cluster Ceph NVMe de 10 PB
- O cliente queria migrar o cluster Ceph existente, baseado em HDD, para uma implantação NVMe de 10 PB e não tinha exigências específicas para RBD, RGW ou CephFS
- As condições do projeto incluíam distribuição em 17 racks, espaço de 4U por rack, energia, refrigeração, densidade e preferência por fornecedor
- Os novos nós precisavam ser integrados ao cluster existente sem interrupção de serviço, e a rede já era uma configuração Ethernet rápida previamente implantada
- A proposta inicial previa 34 nós 2U de dois sockets distribuídos em 17 racks, mas no fim foi escolhida a configuração baseada em Dell projetada pela Clyso
- O orçamento final ficou cerca de 13% mais barato que a configuração original
- A memória por OSD foi reduzida, mas ainda ficou em torno de 12 GiB por OSD, com throughput de memória maior
- Usa configuração de socket único, mais recursos totais de CPU, maior throughput total de rede e processadores AMD mais novos com RAM DDR5
- O uso de nós menores reduziu pela metade o impacto da falha de um nó na recuperação do cluster
Hardware e configuração básica
- As especificações do sistema eram as seguintes
- Nodes: 68 × Dell PowerEdge R6615
- CPU: 1 × AMD EPYC 9454P 48C/96T
- Memory: 192GiB DDR5
- Network: 2 × 100GbE Mellanox ConnectX-6
- NVMe: 10 × Dell 15.36TB Enterprise NVMe Read Intensive AG
- OS: Ubuntu 20.04.6 Focal
- Ceph: Quincy v17.2.7 upstream Deb packages
- O cliente queria limitar o consumo adicional de energia por rack a cerca de 1000~1500 W
- O TDP total de 4 nós por rack foi estimado em no mínimo 1120 W, somando energia base, pico de CPU e ineficiência da fonte de alimentação
- Considerou-se que, se necessário, seria possível reduzir o cTDP do processador para cortar cerca de 100 W por rack
- O servidor Dell 1U tinha uma configuração próxima da geração mais recente dos sistemas usados no laboratório de desempenho upstream do Ceph
- Durante os testes, foram encontrados problemas de desempenho que não existiam no hardware da geração anterior, mas afetaram este hardware
Método de teste e escolha de benchmark
- O teste de burn-in foi realizado implantando um cluster Ceph temporário com CBT e executando testes com FIO
- Foi configurado
osd_memory_targetde 8 GB nos OSDs- Em produção, acreditava-se ser possível usar um
osd_memory_targetmais alto
- Em produção, acreditava-se ser possível usar um
- O cliente não precisava testar workloads de block ou S3, mas foi usado o engine
librbddo FIO em vez deRADOS bench- Em grande escala, é difícil determinar quantas instâncias de
RADOS benchsão necessárias para saturar o cluster, e no passado houve casos em que vários pools simultâneos foram necessários - Para comparação com resultados anteriores do laboratório upstream, foram usados os mesmos testes FIO baseados em librbd
- Também foi considerado o fato de o FIO ser uma ferramenta amplamente conhecida e confiável
- Em grande escala, é difícil determinar quantas instâncias de
- O teste com kernel RBD foi omitido
- O engine
librbdevita problemas em que mount points antigos acabam exigindo reboot do sistema - Esse cluster não tinha acesso via IPMI, e o prazo para concluir os testes era apertado
- Com base em testes anteriores, esperava-se que o desempenho total fosse em geral semelhante se houvesse clientes suficientes
- O engine
- Os testes incluíram replicação 3X e erasure coding 6+2
- O msgr V2 foi testado tanto em modo sem criptografia quanto em modo secure
ms_client_mode = securems_cluster_mode = securems_service_mode = securems_mon_client_mode = securems_mon_cluster_mode = securems_mon_service_mode = secure
- O FIO primeiro preenchia os volumes RBD com gravações grandes e depois executava testes de IO de 4 MB e 4 KB por 300 segundos cada
- Em execuções de depuração, isso foi reduzido para 60 segundos
- Processos em segundo plano como scrub, deep scrub, PG autoscaling e PG balancing foram desativados
O impacto da quantidade de PGs no desempenho
- Testes anteriores no laboratório upstream mostraram que a quantidade de PGs pode ter grande impacto no desempenho
- Com poucos PGs, a distribuição aleatória pode ficar irregular e afetar o desempenho; em alguns casos, isso pode ser mitigado com balancing adicional
- Em clusters rápidos, a contenção do lock de PG dentro do OSD também pode desempenhar um papel importante no desempenho geral
- Esse problema não é fácil de mitigar além de aumentar o número de PGs
- Mesmo em testes com apenas 60 OSDs, o desempenho de leitura aleatória do pool RBD com replicação 3X escalou até 16384 PGs
- As escritas atingiram o pico antes, mas ainda houve benefício até 2048 PGs
- Não se deve aplicar cegamente uma quantidade alta de PGs em produção
- Defaults do Ceph, como comprimento do PG log e atualização de estatísticas de PG, podem influenciar
- Pode ser necessário reavaliar se a prática tradicional de 100 PGs por OSD ainda faz sentido
Problemas iniciais de desempenho e comportamento estranho
- O primeiro acesso ao novo hardware só foi possível na semana seguinte ao Thanksgiving nos EUA, e o plano original era fazer 1 a 2 semanas de validação de burn-in antes de integrar ao cluster existente
- Os testes de desempenho de baixo nível inicialmente pareciam bons
- O teste de rede com iperf chegou perto de 200 Gb/s por nó
- O desempenho básico de alguns SSDs NVMe em alguns nós também parecia razoável
- Em todos os 68 nós, o sistema operacional havia sido implantado por engano em 2 drives OSD, e não nos drives internos de boot Dell BOSS m.2
- Assim, em vez do teste planejado com 3 nós e 30 OSDs, os testes foram feitos usando apenas 8 NVMes por nó
- Os primeiros resultados com Ceph ficaram muito abaixo do esperado, mesmo considerando o número reduzido de OSDs
- Apenas a leitura aleatória chegou perto de um nível aceitável, mas ainda insuficiente
- Ao restringir a análise a testes com nó único e OSD único, surgiu um padrão anormal
- Um sistema que funcionava bem em teste com OSD único piorava após um teste com 8 OSDs
- Depois disso, até o teste com OSD único mantinha desempenho ruim por algumas horas antes de se recuperar
- Se não fosse executado um teste multi-OSD, o desempenho permanecia alto
- Esse mesmo problema não foi reproduzido ao executar FIO diretamente no drive
- Durante o teste com 8 OSDs, um OSD específico usava muito mais CPU do que os demais
- O profile wallclock do OSD mostrava muito tempo gasto em
io_submit, um padrão normalmente visto quando a fila do drive está cheia e o kernel fica bloqueado
Três correções
-
Modo de desempenho do BIOS e c-state
- A primeira correção foi no BIOS, que não estava em modo maximum performance, deixando o c-state da CPU ativado
- O Ceph é muito sensível à latência causada pelas transições de c-state da CPU
- Ao desativar o c-state com o modo maximum performance, o desempenho melhorou 10~20%, mas ainda não era suficiente para atingir a meta
-
Contenção no IOMMU
- O segundo problema apareceu no profile do perf do lado do kernel
- Em execuções ruins, muito tempo era gasto em
native_queued_spin_lock_slowpathe no caminho de mapeamento DMA do IOMMU alloc_iovaiommu_dma_alloc_iovaiommu_dma_map_sgnvme_map_datanvme_queue_rq- Ao desativar o IOMMU no kernel, o desempenho de leitura/escrita de 4 MB no teste com 8 nós melhorou bastante
- Mesmo depois disso, o problema de escrita aleatória de 4 KB continuou
-
Flags de compilação do RocksDB
- O terceiro problema era que o desempenho de escrita aleatória de 4 KB e de compaction do RocksDB estava abaixo do esperado
- Em casos semelhantes no passado com Ceph, os sintomas estiveram ligados a duas causas
- Compilação sem suporte a TCMalloc
- Compilação sem as flags corretas do cmake e sem otimizações adequadas do compilador
- Os pacotes upstream do Ceph para Ubuntu incluíam TCMalloc
- Nos logs de build do pacote Ubuntu 17.2.7, foi confirmado que o RocksDB não havia sido compilado com as flags corretas
- Canonical e Gentoo já haviam corrigido esse problema em seus próprios builds
- Usuários de cephadm em Debian/Ubuntu usando o container upstream aparentemente não foram afetados
- Ao compilar um pacote customizado 17.2.7 corrigido, o tempo de compaction caiu cerca de 3x e o desempenho de escrita aleatória de 4 KB dobrou
Testes de escala na primeira semana de 2024
- Em 2 de janeiro, os testes de desempenho atrasaram por causa da resposta a uma grande falha em outro cluster relacionado
- A partir de sexta-feira, o CBT e os testes foram reconfigurados, e desta vez foi possível usar todos os 10 drives por nó
- O número de clientes FIO foi aumentado até ficar, em média, em cerca de 1 cliente FIO com
io_depth128 por OSD - O teste com 3 nós registrou 63 GiB/s em leitura aleatória de 4 MB
- O teste com 10 nós registrou 213,5 GiB/s
- Escalando de forma quase linear em relação aos 3 nós, em cerca de 98,4%
- Naquele momento, apenas 63 dos 68 nós estavam disponíveis
- 32 nós, com 320 OSDs, foram colocados de um lado
- Em 31 nós clientes, foram executados 10 processos FIO por nó
- Na escala de 320 OSDs, foram alcançados 635 GiB/s de leitura e mais de 15 milhões de IOPS em leitura aleatória de 4 KB
- A latência média e a tail latency permaneceram consistentes nos testes de escala
- Acredita-se que isso tenha sido influenciado pelo aumento conjunto da quantidade de PGs e de clientes FIO junto com os OSDs
- Os testes estavam em um ponto de IO muito intenso, em que adicionar mais IO não aumentava o desempenho e só elevava a latência
Alcançando 1 TiB/s com 630 OSDs
- Como não havia mais nós clientes separados para o teste de capacidade total, os processos FIO foram colocados junto nos nós OSD
- Há uma chance de 1/63 de um cliente se comunicar com um OSD local, o que traz uma pequena vantagem de rede
- Por outro lado, colocar clientes FIO junto dos nós OSD também pode causar perda de desempenho
- A implantação via CBT de 630 OSDs em 63 nós levou cerca de 15 minutos
- A primeira tentativa ficou em cerca de 950 GiB/s, muito perto de 1 TiB/s
- Depois disso, foram reduzidos os shards do OSD e as threads do async messenger, e foi aplicado o tuning de RocksDB do Reef
- O desempenho de leitura caiu um pouco e o de escrita melhorou
- O desempenho de escrita aleatória melhorou quase 20%
- O impacto maior parece ter vindo das mudanças em shards/threads
- Também foram feitos experimentos dobrando o número de PGs e aumentando novamente o número de clientes
- A leitura aleatória de 4 MB melhorou um pouco com o aumento no número de clientes
- O IOPS de leitura aleatória pequena piorou
- Com 8 FIO por nó, totalizando 504 processos, o desempenho de escrita sequencial caiu muito
- Quando 504 processos FIO executaram escritas de 4 MB, alguns PGs entraram no estado active+clean+laggy
- Com o tempo, o número de PGs laggy aumentava, mesmo com throughput muito abaixo da capacidade do cluster
- O cluster não se recuperava desse estado até o fim da carga
- Segundo a documentação do Ceph, no estado laggy o IO é pausado temporariamente porque a réplica não consegue confirmar a tempo um novo lease vindo do primário
- No fim, a configuração padrão do Ceph, com 8 shards, 2 threads por shard e 3 threads de msgr, foi a melhor para leitura de 4 MB
- Em condições de 256K PGs, 630 OSDs e 504 processos clientes FIO, o
ceph -smostrou 1,0 TiB/s read- Todos os 630 OSDs estavam em estado up/in
- Todos os 262145 PGs estavam em estado active+clean
- As operações de leitura mostradas foram 266,15k op/s
Resultados com erasure coding 6+2
- O cluster real que o cliente pretendia migrar usava configuração 6+2 erasure coding, então foi necessário um teste separado
- Para os testes de EC, foram escolhidos valores de PG, shard e clientes que haviam funcionado bem nos testes anteriores
- Como as threads do async messenger pareciam muito ocupadas, também foi testado aumentar esse número acima do padrão
- Com 4 a 5 async msgr threads, foram obtidos os seguintes resultados
- Leitura: mais de 500 GiB/s
- Escrita: quase 400 GiB/s
- A razão de a leitura 6+2 EC ser mais lenta que a replicação 3X é a diferença no overhead de rede
- Na replicação, o OSD primário só precisa ler os dados locais e enviá-los ao cliente, então o overhead de rede é efetivamente 1X
- Em 6+2 EC, o primário precisa ler dos réplicas 5 dos 6 chunks para montar o objeto e então enviá-lo ao cliente
- O overhead total de rede da requisição é aproximadamente
(1 + 5/6)X
- Em escritas, o padrão é o oposto
- Na replicação 3X, o objeto enviado pelo cliente ao primário é reenviado pelo primário para dois secundários, totalizando overhead de rede de 3X
- Em EC, só é necessário enviar 7/8 dos chunks aos secundários, o que resulta em melhor desempenho em escritas grandes
- O IOPS de IO pequeno é outra questão
- Em leituras/escritas muito pequenas, o Ceph acessa todos os OSDs participantes do PG daquele objeto
- Mesmo que os dados de interesse estejam em apenas um chunk, os dados são buscados em todos os OSDs participantes do stripe
- A Clyso reativou este PR, implementado no verão de 2023, para partial stripe reads em erasure coding, e o efeito foi grande
- Ainda não está claro se isso poderá ser mergeado no Squid
O impacto da criptografia do msgr
- Para estimar o impacto caso o cliente use criptografia no nível do msgr, também foram feitos testes com msgr v2 encryption
- Em ambos os casos, replicação 3X e erasure coding 6+2, os resultados com criptografia ativada foram comparados aos anteriores
- O maior impacto apareceu em leituras grandes
- Caiu de cerca de 1 TiB/s para cerca de 750 GiB/s
- Os demais itens mostraram degradação de desempenho mais moderada, mas consistente
- Também queriam testes de scaling de PG e de kernel RBD, mas o sistema precisava ser devolvido ao cliente para re-imaging e integração
Resumo do melhor desempenho final
- Os melhores números alcançados nos testes foram os seguintes
| Item | 30 OSDs (3x) | 100 OSDs (3x) | 320 OSDs (3x) | 630 OSDs (3x) | 630 OSDs (EC62) |
|---|---|---|---|---|---|
| FIO co-localizado | No | No | No | Yes | Yes |
| 4MB Read | 63 GiB/s | 214 GiB/s | 635 GiB/s | 1025 GiB/s | 547 GiB/s |
| 4MB Write | 15 GiB/s | 46 GiB/s | 133 GiB/s | 270 GiB/s | 387 GiB/s |
| 4KB Rand Read | 1.9M IOPS | 5.8M IOPS | 16.6M IOPS | 25.5M IOPS | 3.4M IOPS |
| 4KB Rand Write | 248K IOPS | 745K IOPS | 2.4M IOPS | 4.9M IOPS | 936K IOPS |
- Depois do fim dos testes, todo o hardware foi re-imaged, e os novos OSDs foram implantados no cluster HDD existente do cliente
- A migração foi controlada com o script upmap-remapped do Dan, e cerca de 80% dos dados existentes foram movidos para OSDs baseados em NVMe
- No início, decidiram não aplicar imediatamente todo o tuning usado nos testes e primeiro verificar o comportamento do cluster majoritariamente na configuração padrão
- Os dados dos testes poderão ser usados no futuro para fazer tuning adicional do sistema caso o cliente enfrente problemas de desempenho
Desafios restantes e limites de escala
- O problema de PG laggy sob cargas de escrita em grande escala precisa ser resolvido
- Não é aceitável que o Ceph entre em colapso quando a carga de escrita cresce
- Este teste confirmou que o Ceph consegue saturar NICs de 2×100GbE
- Para aumentar ainda mais o throughput ao usar mais de 10 drives NVMe por nó, será necessário 200GbE ou mais
- IOPS é mais complexo
- O número de PGs pode ter grande impacto
- O modelo de threading do OSD também desempenha um papel importante
- Em várias implantações, surgiu um teto de cerca de 400K~600K IOPS de leitura aleatória por nó
- Pontos de melhoria citados incluem o async msgr e a interface com o kernel, além da forma como a thread do OSD é despertada quando novo trabalho entra na fila do shard
- Já houve modificações no código do OSD para melhorar os resultados sob alta carga, mas ao custo de piorar a latência em baixa carga
- Melhorar IOPS exigirá abordagens em várias frentes e possivelmente reescrever parte do código de threading do OSD
1 comentários
Opiniões no Hacker News
O Ceph tem uma história interessante.
Ele foi criado pelos fundadores da DreamHost por uma necessidade interna, e a DreamHost já oferecia, na prática, serviços desse tipo antes mesmo de os termos IaaS e PaaS se consolidarem no setor, como VPS, servidores gerenciados de SO/banco de dados/aplicações.
Depois, eles fizeram o spin-off do Ceph, que foi adquirido pela Red Hat.
https://en.wikipedia.org/wiki/DreamHost
Era uma época sem textos de marketing lapidados para vender cada frase; eles simplesmente compartilhavam algo com que estavam brincando.
Pelo que lembro, era um projeto universitário de um dos fundadores, ao qual os outros fundadores se juntaram dando apoio; pelo que sei, o Docker também teve uma origem parecida.
A UCSC foi um lugar de onde saiu muita pesquisa em armazenamento de qualidade.
Bom artigo. No CERN, também chegamos recentemente a 1 TB/s, mas foi com EOS (https://cern.ch/eos), não com Ceph.
https://www.home.cern/news/news/computing/exabyte-disk-stora...
Porém, nosso cluster EOS tem muito mais nós e usa HDDs em sua maioria. O CERN também usa Ceph amplamente.
Eu adorava esse tipo de experimento. Trabalhando como tech lead na Cisco, tive o privilégio de montar Kubernetes em bare metal e configurar GlusterFS e Ceph por conta própria, para aprender e comparar qual era melhor.
Pelo que lembro, foi por volta de 2017/2018; bons tempos. Este artigo também foi muito bom.
Alguns SSDs NVMe estavam mais usados do que outros e isso gerava diferença; era um trabalho realmente absurdo.
Seria bom se alguém tentasse reduzir ainda mais a escala dos nós. O sistema descrito aqui tem 10 discos por nó e cerca de 300 W/nó, então dá por volta de 30 W por disco
O overhead é bem grande, e é preciso bastante espaço de armazenamento só para obter algum nível de redundância
Com um pouco de engenharia, acho que daria para reduzir tudo a um décimo. Algo como criar um pequeno computador de placa única com 4 lanes PCIe para NVMe, 2x10GbE (2 soquetes SFP+), uma CPU ARM ou RISC-V suficientemente rápida, e adicionar eMMC ou um slot SD para boot
Assim daria para descer para uma escala de poucos nós, e também reduzir a exposição de perder 10 discos de uma vez em uma única falha
Acho que seria possível colocar muitos desses sistemas em um gabinete 4U e, opcionalmente, incluir no mesmo gabinete dois switches totalmente independentes para agregar os nós internos
A instalação foi realmente dolorosa por causa do processador armhf, mas, depois que começou a funcionar, funcionava bem. Só era lento por causa da única NIC de 1 Gb
Na época era só para aprendizado
[0] https://www.hardkernel.com/shop/odroid-hc2-home-cloud-two/
Em breve devo receber dois ARM Turing RK1 de 7 W, cada um entregando 4 GB/s via PCIe 3x4, e a placa de cluster Turing Pi 2 comporta 4 deles no formato ITX
Com custo total de US$ 820, espero mais de 3 Gbps por watt
Até agora, as lanes PCIe são o gargalo. Mesmo um SSD de 2 TB de US$ 90 é anunciado como 7 GB/s em PCIe 4x4, então ainda não vejo computadores de placa única como a solução ideal
A linha Ampere Altra parece suportar PCIe 4x128 a 40 W, então um blade 1U com rede de 100G poderia ser interessante
Mas, mesmo em homelab, já vi muitos bugs relacionados a ARM e otimizações ausentes, então talvez seja difícil dizer que esse tipo de solução já está pronta para datacenters
Para justificar uma configuração Ceph com interfaces de 10 Gbps hoje, ela teria que ser realmente pequena e muito barata
Em uma escala tão pequena, é bem provável que seja melhor ter armazenamento NVMe local em cada servidor
É uma estimativa grosseira do tipo 1 TB/s × 8 bits/byte × 1024 GB/TB ÷ 34 nós ÷ 300 W
Um sistema ARM muito eficiente, como um Mac mini novo, consome cerca de 10 W em uso interativo e consegue lidar com uma rede de 10 Gbps, então fica por volta de 1 Gbps por watt em termos de dados
Ou seja, o cluster do texto original fica, em termos aproximados, em um nível de bits/segundo/watt parecido com o de um sistema ARM muito eficiente
Não acho que usar nós pequenos vá melhorar a eficiência real; pelo contrário, é provável que custe mais. Hoje, servidores potentes têm desempenho por watt bem bom
De todo modo, isso é software open source rodando em hardware de uso geral, então dá até para experimentar por conta própria com algumas centenas de dólares
Quando o sistema operacional e o dispositivo NVMe estão distantes um do outro, o controlador precisa inferir a intenção das requisições para lidar da melhor forma com agrupamento e wear leveling, o que gera uma ineficiência natural
O novo recurso FDP (flexible data placement) é uma tentativa de resolver isso dando mais controle ao sistema operacional
O ideal seria puxar isso para o lado do sistema operacional host e expor a flash tanto quanto possível como um “enorme array burro de transistores conectado como dispositivo PCIe”
Ao remover camadas de abstração, acho que daria para compor o sistema em unidades de hardware tipo Atom, com NIC integrada de 100 Gbps e uma quantidade proporcional de flash, para obter o paralelismo desejado
Deve ter havido um momento na história em que a quantidade total de dados digitais armazenados no mundo chegou pela primeira vez a 1 TiB
Esse dia quase certamente ocorreu nos últimos 60 anos
E agora um servidor de uma organização bastante arbitrária está movendo essa quantidade de dados a cada segundo. Nem é um projeto de pesquisa nacional ou supranacional
Texto interessante. Operamos um cluster de armazenamento Ceph para manter nosso cache de camadas do Docker
Depois que migramos do EBS para o Ceph, a diferença de throughput foi enorme. O throughput de escrita subiu de 146 MB/s e 3.000 IOPS para 900 MB/s e 30.000 IOPS
A melhor parte é que ele praticamente simplesmente funciona. Quase não exige cuidado, fora coisas ocasionais como trim do sistema de arquivos
Foi uma melhoria enorme para o sistema de cache
[0] https://depot.dev/blog/cache-v2-faster-builds
No fim, ao migrar para racks próprios, reduzimos o custo de novo para quase um décimo, e ficamos mais livres ao desenvolver capacidade operacional interna
Pelo blog isso não ficou imediatamente claro
Os piores problemas que tive com armazenamento dinâmico dentro de clusters não foram problemas puros de I/O
Eram situações em que o software controlador de armazenamento do Kubernetes não lidava bem com problemas do mundo real, por exemplo quando um pod morre e o PVC não é anexado até terminar um timeout muito longo, enquanto o pod fica em ContainerCreating até o bloqueio do PVC ser liberado
Isso aconteceu em vários clusters usando rook/ceph e Longhorn
Tenho curiosidade se alguém já rodou Ceph em um homelab. Da última vez que pesquisei, os requisitos de hardware eram bem altos
Quando funciona bem, é excelente, mas, quando dá problema, vira uma dor de cabeça enorme
Se o interesse é em armazenamento distribuído em si, há opções melhores para uma configuração de homelab
O seaweedfs foi muito estável por anos, tanto em pequena quanto em enorme escala, e de fato migrei uma configuração Ceph de produção para ele
Quando estava no mundo Kubernetes, o Longhorn também foi estável
O GlusterFS ainda é aceitável se você entrar sabendo o que está assumindo
Mas era muito difícil obter um desempenho decente, e, em clusters pequenos, o daemon de metadados podia travar com bastante facilidade
No fim, quando a diversão acabou, voltei para ZFS em uma única máquina
Primeiro, é preciso ter em mente que o Ceph é um sistema de armazenamento distribuído, então ter vários nós é a premissa básica
Para aprendizado, dá para virtualizar tudo em uma única máquina, mas é muito melhor ter máquinas físicas separadas
O Ceph, de forma parecida com o ZFS, prefere acesso físico aos discos
Além disso, é necessária uma boa conexão de rede. Acho que é nisso que as pessoas geralmente pensam quando falam dos altos requisitos de hardware do Ceph
O ideal é ter pelo menos 10GbE; se quiser desempenho maior, precisa de mais do que isso. Especialmente em operações como backfill, pode haver muito tráfego de rede
Se você conseguir equipamentos de homelab baratos, 25Gbps também é bom; 50Gbps é tecnicamente quase um beco sem saída, e 100Gbps funciona bem
Ainda assim, para um homelab, mini PCs baratos ou NUCs com 10GbE rodam suficientemente bem e permitem obter desempenho aceitável e bom aprendizado
Você pode instalar o Ceph diretamente em bare metal, ou, se quiser seguir o caminho de Kubernetes no homelab, pode usar o Rook(https://rook.io/)
Espero que ajude; se tiver mais perguntas, é só falar
Nesse nível, dificilmente dá para chamar de hardware grande
[1] https://ceph.io/en/news/blog/2022/install-ceph-in-a-raspberr...
No mínimo 10Gb, de preferência 40Gb ou mais; se usar discos giratórios, é melhor ter pelo menos uns 6 discos em cada um de alguns nós
Se for tudo SSD, é bem provável que dê para reduzir muito o número de discos por nó
Fiz as contas porque queria ver como 1 TiB/s se compara aos limites teóricos do hardware real
Este cluster é composto por 68 nós, e cada nó é um Dell PowerEdge R6615(https://www.delltechnologies.com/asset/en-us/products/server...)
A configuração usada é um R6615 com 10 baias para drives U.2, e o link U.2 transmite dados por 4 lanes PCIe de 4ª geração. Uma lane PCIe tem 16 Gbit/s e, graças à codificação 128b-132b, o overhead é de cerca de 3%, praticamente desprezível
Portanto, a largura de banda máxima de um link U.2 é 16×4=64 Gbit/s, ou seja, 8 Gbyte/s. Porém, o drive U.2 NVMe usado, o Dell 15.36TB Enterprise NVMe Read Intensive AG, parece ter throughput de leitura de 7 Gbyte/s(https://www.serversupply.com/SSD%20W-TRAY/NVMe/15.36TB/DELL/...), então o link U.2 de 8 Gbyte/s não é o gargalo
Como há 10 drives U.2 por nó, cada nó consegue entregar I/O de leitura local de até 10×7=70 Gbyte/s
Mas a largura de banda de rede de cada nó é de apenas 200 Gbit/s (2×100GbE Mellanox ConnectX-6), ou seja, 25 Gbyte/s. Isso significa que, em leituras remotas, a capacidade de 70 Gbyte/s dos drives não é totalmente aproveitada e a rede é o gargalo
Assumindo que não haja gargalos adicionais de rede, os 68 nós podem fornecer 68×25=1700 Gbyte/s de leitura pela rede. O autor de fato mediu em benchmark 1 TiB/s, mais exatamente 1025 GiB/s=1101 Gbyte/s, portanto cerca de 65% do máximo teórico de 1700 Gbyte/s
É bem bom, mas, se todos os nós conseguissem saturar completamente ao mesmo tempo os links de rede de 200 Gbit/s, teoricamente poderia ir um pouco além
Ao ler o texto inteiro, fiquei com a impressão de que a complexidade do Ceph pesa bastante na CPU. É bem surpreendente que apenas não compilar módulos com -O2 (o “Fix Three” linkado pelo autor: https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1894453) possa fazer com que, em workloads de I/O puro, “alguns workloads fiquem até 5 vezes mais lentos”(https://bugs.gentoo.org/733316)
Também é estranho que threads de OSD desperdicem CPU em excesso ao pegar um spinlock do IOMMU. Concordo com a conclusão de que o modelo de threading do OSD não é ideal
Um benchmark sintético relativamente simples de 100% leitura não deveria expor contenção de threads. Isso se essa parte da arquitetura de software do Ceph tivesse sido bem projetada. É um problema que dá para corrigir, então espero que os desenvolvedores do Ceph deem mais prioridade a ele
O laboratório upstream do Ceph tem máquinas da Dell com a geração anterior do mesmo chassi 1U e processadores AMD Rome, e elas não sofrem esse problema mesmo entregando desempenho semelhante na mesma escala, cerca de 30 OSDs
O cliente disse que já tinha visto esse problema antes em seu datacenter e espera conseguir identificar a causa junto com a AMD
No verão passado, trabalhei um pouco em reforços provisórios para o modelo de threading existente do OSD. Coisas como double buffering no handoff entre o async msgr e as threads worker, e wake-up adaptativo de threads
Sob carga, isso conseguiu aumentar bastante o desempenho e a eficiência, mas teve como custo maior latência sob baixa carga. Por padrão, o Ceph é muito agressivo em acordar threads quando entra novo I/O em um shard específico
Conversei com outro desenvolvedor principal, e ambos chegamos à conclusão de que uma reestruturação completa do código de threading faria mais sentido
Com 320 OSDs, isso dá algo em torno de 1,6 TiB/s
Pelo menos foram esses os números que encontrei. Também não há tantas análises desses discos NVMe enterprise
Ainda assim, parece um número que combina bem com a NIC. Nessa escala, a maioria dos workloads provavelmente parece I/O aleatório na camada de armazenamento
O surpreendente é por que escolheram nós 1U, mais difíceis de resfriar, com 10 SSDs e NIC 2×100Gb
Se tivessem usado nós 2U com 24 SSDs e NICs 2×200Gb ou 400Gb, poderiam ter eliminado o gargalo de rede e também reduzido energia graças a ventoinhas maiores e mais lentas e a menos pacotes de CPU. O número de núcleos por soquete também poderia ser maior
Com menos nós, o domínio de impacto de falhas aumenta, mas, com algo como 34 nós, não acho que isso seria um problema tão grande
Com menos nós, talvez também fosse possível montar uma rede mais plana com algo como 4 switches
Os racks e switches já existem e também são bastante usados para outros fins, então o espaço físico adicional por causa do Ceph é muito pequeno :)