O duelo NVMe: vSAN ESA contra Ceph na batalha por menor latência e uso de CPU

      Ricardo Vilela 9 min de leitura
      O duelo NVMe: vSAN ESA contra Ceph na batalha por menor latência e uso de CPU

      Comparamos a arquitetura do VMware vSAN ESA e do Ceph em clusters NVMe. Descubra qual storage definido por software entrega mais IOPS com menor overhead de processamento.

      Compartilhar:

      A revolução dos discos NVMe mudou as regras do jogo no armazenamento corporativo. Antes, os discos rígidos mecânicos e até os SSDs SATA eram os grandes gargalos de qualquer infraestrutura. Hoje, as unidades NVMe são tão absurdamente rápidas que o gargalo mudou de lugar. O problema agora é o software.

      Quando você empilha dezenas de drives capazes de entregar milhões de IOPS (operações de entrada e saída por segundo), a CPU do servidor começa a suar para gerenciar tudo isso. É aqui que entra a verdadeira guerra da infraestrutura hiperconvergente (HCI). De um lado, temos o VMware vSAN ESA, uma solução comercial altamente otimizada. Do outro, o Ceph, o gigante do open source que domina nuvens privadas.

      Resumo em 30 segundos

      • vSAN ESA: Roda direto no kernel do hypervisor, otimizado para NVMe puro, entregando latência mínima com baixo uso de CPU.
      • Ceph: Robusto e open source, mas sua arquitetura atual em espaço de usuário consome mais processamento para gerenciar os mesmos NVMes.
      • O dilema: Pagar o alto custo de licenciamento por núcleo da Broadcom ou investir em engenheiros caros para dominar o Ceph.

      A colisão de filosofias entre kernel e espaço de usuário

      Para entender por que um software de storage consome mais CPU que outro, precisamos olhar para onde ele mora dentro do sistema operacional. O vSAN da VMware tem uma vantagem de campo injusta. Ele é construído diretamente dentro do kernel do ESXi. Isso significa que o caminho entre a máquina virtual que solicita o dado e o disco NVMe físico é extremamente curto.

      O Ceph adota uma filosofia diferente. Ele roda no espaço de usuário (user space) do Linux. Para que um dado saia de uma aplicação e chegue ao disco físico em um cluster Ceph tradicional, ele precisa cruzar a fronteira entre o espaço de usuário e o kernel do sistema operacional várias vezes.

      Diagrama ilustrando o caminho de dados no kernel do ESXi versus o espaço de usuário do Ceph Figura: Diagrama ilustrando o caminho de dados no kernel do ESXi versus o espaço de usuário do Ceph

      Cada uma dessas travessias gera o que chamamos de troca de contexto (context switch). Em discos lentos, você nunca notaria isso. Mas quando um SSD NVMe responde em microssegundos, essas trocas de contexto se acumulam, gerando latência e forçando a CPU a trabalhar dobrado apenas para mover os dados de um lado para o outro.

      Como a arquitetura de camada única do vSAN ESA elimina gargalos

      A VMware percebeu que sua arquitetura original do vSAN (agora chamada de OSA) estava ficando obsoleta para hardwares modernos. A arquitetura antiga exigia grupos de discos divididos em duas camadas. Uma camada de cache (discos mais rápidos) e uma camada de capacidade (discos maiores).

      O vSAN ESA (Express Storage Architecture) jogou essa regra no lixo. Ele foi reescrito do zero para operar em uma arquitetura de camada única (single-tier), desenhada exclusivamente para dispositivos NVMe. Todos os discos no servidor contribuem tanto para performance quanto para capacidade simultaneamente.

      💡 Dica Pro: O vSAN ESA não suporta discos SAS ou SATA. Se você planeja migrar para esta arquitetura, seu hardware precisa ser composto 100% por unidades NVMe homologadas na lista de compatibilidade da VMware.

      Ao eliminar a necessidade de mover dados constantemente da camada de cache para a camada de capacidade (um processo conhecido como destaging), o vSAN ESA reduziu drasticamente a amplificação de gravação. O resultado direto é uma economia massiva de ciclos de CPU e uma vida útil muito maior para a memória flash dos seus NVMes.

      O custo do processamento distribuído no BlueStore do Ceph

      O Ceph é uma maravilha da engenharia distribuída. Ele não tem um ponto único de falha e pode escalar para exabytes de dados. O motor de armazenamento padrão do Ceph hoje é o BlueStore. Ele foi um salto gigantesco em relação ao passado, pois grava dados diretamente no dispositivo de bloco, ignorando sistemas de arquivos tradicionais como Ext4 ou XFS.

      No entanto, o BlueStore ainda depende de um banco de dados interno (RocksDB) para gerenciar os metadados de onde cada bloco de informação está guardado. Gerenciar esse banco de dados em tempo real exige muito processamento.

      Ilustração conceitual de uma CPU saturada enquanto os discos NVMe aguardam comandos Figura: Ilustração conceitual de uma CPU saturada enquanto os discos NVMe aguardam comandos

      Em um cluster Ceph equipado apenas com NVMes de última geração (como os drives PCIe Gen 4 ou Gen 5), é muito comum ver os núcleos da CPU do servidor baterem 100% de uso muito antes de os discos atingirem seu limite de IOPS. Você acaba comprando discos caríssimos que ficam ociosos porque o processador não consegue enviar comandos rápido o suficiente.

      A comunidade open source sabe disso. O projeto Ceph Crimson está em desenvolvimento ativo para resolver exatamente esse problema. O Crimson visa contornar o kernel do Linux usando tecnologias como SPDK (Storage Performance Development Kit), permitindo que o Ceph fale diretamente com o NVMe. Mas, por enquanto, o BlueStore ainda dita as regras em produção.

      Tabela comparativa: vSAN ESA vs Ceph

      Para facilitar a decisão técnica, resumimos as principais diferenças arquiteturais e operacionais entre as duas plataformas quando expostas a ambientes de altíssima performance.

      Característica VMware vSAN ESA Ceph (BlueStore)
      Integração Nativo no Kernel do ESXi Espaço de Usuário (Linux)
      Otimização NVMe Camada única (Single-tier) Depende de RocksDB/Metadados
      Uso de CPU Baixo a Médio Alto (Gargalo em NVMes rápidos)
      Latência Base Microssegundos (Consistente) Ligeiramente maior (Trocas de contexto)
      Custo de Licença Alto (Assinatura por núcleo) Zero (Open Source)
      Complexidade Baixa (Turn-key) Alta (Curva de aprendizado íngreme)

      Análise de latência e saturação de CPU em cargas transacionais

      A teoria é ótima, mas como isso se traduz no mundo real? Imagine um banco de dados SQL processando milhares de transações financeiras por segundo (cargas OLTP). Esse tipo de aplicação gera blocos de dados muito pequenos (geralmente 4K ou 8K) de forma totalmente aleatória.

      O vSAN ESA brilha nesse cenário. Como o caminho de dados é curto e não há camada de cache para saturar, a latência permanece plana e previsível. O banco de dados recebe a confirmação de gravação quase instantaneamente.

      Gráficos comparativos mostrando latência consistente versus picos de latência de cauda Figura: Gráficos comparativos mostrando latência consistente versus picos de latência de cauda

      No Ceph, o cenário de blocos pequenos e aleatórios é o pior possível para o uso de CPU. O overhead de rede somado ao processamento do RocksDB pode gerar o que chamamos de latência de cauda (tail latency). A maioria das requisições é rápida, mas uma pequena porcentagem sofre atrasos significativos. Para bancos de dados sensíveis a tempo, esses picos de latência podem causar travamentos em cascata na aplicação.

      ⚠️ Perigo: Nunca implemente um cluster 100% NVMe (seja vSAN ou Ceph) sem uma rede de altíssima performance. Switches de 25GbE são o mínimo absoluto, sendo 100GbE com suporte a RDMA (Remote Direct Memory Access) a recomendação ideal para evitar que a rede se torne o novo gargalo.

      Licenciamento da Broadcom versus a curva de aprendizado open source

      Se o vSAN ESA é tão eficiente no uso de hardware, por que alguém escolheria o Ceph? A resposta se resume a duas palavras: modelo de negócios.

      Após a aquisição da VMware pela Broadcom, o modelo de licenciamento mudou drasticamente. As licenças perpétuas acabaram. Agora, você paga uma assinatura baseada no número de núcleos de CPU dos seus servidores. Para datacenters de médio e grande porte, o custo de manter o vSAN ESA disparou, forçando muitas empresas a repensarem suas estratégias de infraestrutura.

      Balança pesando o custo de licenças comerciais contra a complexidade técnica do open source Figura: Balança pesando o custo de licenças comerciais contra a complexidade técnica do open source

      O Ceph, por ser open source, não cobra um centavo por licença de software. Você pode escalar para centenas de petabytes sem pedir permissão a nenhum fornecedor. No entanto, o custo do Ceph é pago em capital humano.

      Configurar, otimizar e manter um cluster Ceph exige engenheiros de infraestrutura altamente especializados. Um erro na configuração do mapa CRUSH (o algoritmo que decide onde os dados são guardados) pode derrubar a performance do cluster inteiro. O vSAN, por outro lado, é praticamente "plug and play" para quem já domina o ecossistema vSphere.

      O veredito para o seu datacenter

      A escolha entre vSAN ESA e Ceph para ambientes NVMe não é apenas uma decisão técnica. É uma decisão financeira e operacional.

      Se a sua empresa exige latência ultrabaixa para bancos de dados críticos, tem orçamento para licenças corporativas e prefere uma solução integrada com suporte de fábrica, o vSAN ESA é o vencedor indiscutível. Ele extrai cada gota de performance dos seus NVMes sem derreter os processadores do servidor.

      Por outro lado, se você está construindo uma nuvem privada em larga escala, tem uma equipe de engenharia forte e precisa fugir do aprisionamento tecnológico (vendor lock-in) imposto pelas novas regras da Broadcom, o Ceph é o caminho. Fique atento ao projeto Ceph Crimson nos próximos ciclos de atualização. Quando ele atingir a maturidade em produção, a vantagem de CPU do vSAN poderá finalmente ser neutralizada, nivelando o campo de batalha do armazenamento definido por software.

      Por que o vSAN ESA consome menos CPU que as versões anteriores? O vSAN Express Storage Architecture (ESA) foi reescrito para operar em uma única camada (single-tier) otimizada exclusivamente para NVMe. Isso elimina a necessidade de grupos de disco com cache e capacidade separados, reduzindo drasticamente a amplificação de gravação e o overhead de CPU.
      O Ceph é inadequado para clusters 100% NVMe? Não é inadequado, mas sua arquitetura tradicional (BlueStore) roda no espaço de usuário (user space), o que gera mais trocas de contexto com o sistema operacional e uma latência base ligeiramente maior. O projeto em desenvolvimento Ceph Crimson visa resolver exatamente esse gargalo para mídias ultrarrápidas.
      Qual a principal diferença de custo entre vSAN ESA e Ceph? O vSAN ESA exige licenciamento comercial da VMware (agora sob o modelo de assinatura por núcleo da Broadcom), o que aumenta o custo de aquisição (CapEx/OpEx). O Ceph é open source e não possui custo de licença, mas exige um investimento considerável em horas técnicas e profissionais especializados para sua manutenção.
      #vSAN ESA #Ceph #NVMe #storage definido por software #latência de storage #infraestrutura hiperconvergente #overhead de CPU
      Ricardo Vilela
      Assinatura Técnica

      Ricardo Vilela

      Especialista em Compras/Procurement

      "Especialista em dissecar contratos e destruir argumentos de vendas. Meu foco é TCO, SLAs blindados e evitar armadilhas de lock-in. Se não está no papel, não existe."