No mundo da tecnologia, geralmente esperamos que gigantes como Google ou Meta lancem sistemas de armazenamento inovadores e de código aberto. Mas e se um dos motores de dados mais robustos — capaz de lidar com centenas de petabytes — viesse de um lugar inesperado, como uma empresa de negociação algorítmica? Pois foi exatamente isso que aconteceu: a XTX Markets acabou de abrir o código do TernFS, o sistema de arquivos distribuído que alimenta sua infraestrutura de pesquisa e machine learning em escala exabyte.
Imagine um time de Fórmula 1 projetando seu próprio motor para garantir alta performance nos mínimos detalhes — foi assim que nasceu o TernFS. As cargas intensivas de IA e análise quantitativa da XTX superaram rapidamente as limitações de soluções prontas como NFS e produtos comerciais. Assim, criar um sistema personalizado (em vez de adaptar algo existente) virou questão de sobrevivência técnica.
Por que construir outro sistema de arquivos?
A pergunta é óbvia: por que uma trading firm decidiu reinventar a roda? A resposta está na escala absurda e no perfil WORM (write-once, read-many) dos dados envolvidos — milhões de modelos, trilhões de arquivos, infraestrutura que começou com desktops e NFS, e hoje suporta centenas de milhares de CPUs e dezenas de milhares de GPUs para pesquisa de mercado.
Com o crescimento do poder computacional, o gargalo passou a ser o armazenamento. Sistemas de arquivos “universais” não aguentavam a demanda, e os comerciais eram caros ou simplesmente não atendiam aos requisitos de performance, resiliência e flexibilidade. Por isso, a XTX fez como as tech giants… só que com um twist: abriu o código, criando uma oportunidade rara para a comunidade HPC e IA ver como se constrói um Distributed Filesystem TernFS em produção.
A arquitetura do TernFS
O TernFS é formado por quatro pilares simples e modulares — cada um resolvendo um grande problema de escala e performance:
- Metadata Shards: Armazenam toda a estrutura de diretórios e metadados dos arquivos. São 256 shards lógicas, cada uma com cinco réplicas (liderada por uma implementação própria de consenso à la Raft e usando RocksDB). O segredo para escalar metadados está aqui: cada diretório pertence a uma shard, e os shards nunca comunicam diretamente entre si.
- CDC (Cross-directory coordinator): Quando uma operação requer múltiplos shards — criar/remover diretórios ou mover arquivos entre eles — entra em ação o CDC. Orquestrado como outro cluster replicado, executa transações distribuídas de forma paralela, mantendo alta taxa de throughput.
- Block Services: Cada arquivo, assim que gravado, é dividido em spans e depois em blocos de dados e blocos de paridade. Os blocos residem nos chamados Block Services, que são tipicamente discos rígidos ou SSDs individuais. Uma política por diretório decide para onde vão os dados: arquivos grandes e lidos sequencialmente caem em discos, arquivos pequenos e de acesso aleatório vão para flash.
- Registry: O ponto de partida de qualquer cliente TernFS. A Registry mantém a localização (IPv4) de todos os Metadata Shards, CDCs e Block Services, além do status e da capacidade dos drives. É o servidor de confiança para montar e explorar o sistema, usando DNS apenas para si próprio, simplificando o kernel module no Linux.
Impondo escala e resiliência
Na produção, o Distributed Filesystem TernFS atinge números impressionantes:
- Mais de 500PB distribuídos em 30.000 discos rígidos e 10.000 drives flash, espalhados por três data centers distintos.
- Performance extrema: múltiplos terabytes por segundo em horas de pico, servido para mais de 100.000 nós de computação.
- Política de replicação automática e multi-site: tanto metadados quanto conteúdos de arquivo são replicados entre data centers, de forma resiliente a falhas temporárias e permanentes. O particionamento de falha é pensado para evitar perda catastrófica de dados — por isso a escolha refinada de criptografia (AES para assinaturas) e codificação Reed-Solomon para tolerância a falhas físicas.
Recursos, trade-offs e decisões conscientes
É importante destacar que o TernFS não é para todos — aliás, nem deveria ser. Os arquivos são imutáveis (nada de editar depois de escrever), permissões ficam fora do sistema (delegadas a outros serviços), e o sistema não é ideal para microarquivos (o tamanho mediano no XTX é de 2MB). O throughput na criação de diretórios/removidos é mais baixo que outras operações, devido ao desenho modular do CDC.
Por outro lado, os pontos fortíssimos do TernFS incluem:
- Reed-Solomon redundancy: Arquivos são repartidos em blocos de dados + paridade, conferindo tolerância a múltiplas falhas de disco sem perdas. Na prática, no XTX usa-se uma configuração de D=10 e P=4 — ou seja, até quatro discos podem falhar sem perder o arquivo completo.
- Checksums agressivos: CRC32-C em todo bloco, intercalado a cada página de 4KB, fácil de validar (inclusive com leitura parcial) e rápido tanto por hardware quanto software.
- Snapshots: Ao deletar arquivos ou diretórios, na prática só se cria referências fracas, facilmente recuperáveis via API ou ferramenta interna, evitando perda por erro humano.
- Scrubbing automático: Um processo dedicado lê e verifica todos os blocos, substituindo qualquer bloco corrompido antes que possa causar dano.
Como acessar: do kernel Linux ao S3
No XTX, o acesso principal ao TernFS se dá via kernel module Linux — uma integração direta, NOT via FUSE, que garante performance máxima e capacidade de customização. Embora não completamente POSIX, o módulo é suficiente para grande parte dos workflows em IA e pode ser adaptado para outros padrões.
Para quem busca interoperabilidade fora do kernel, existe uma S3 Gateway, que traduz comandos S3 (o padrão da cloud storage) para chamadas TernFS. Essa implementação, baseada em Go, serve como ponto de partida para integrações personalizadas — e há planos (ainda em gestação) para gateways NFS e interfaces web/JSON para automações simplificadas.
O futuro aberto e o impacto na comunidade
Abrir o código do Distributed Filesystem TernFS é mais que um gesto — é uma ruptura silenciosa. Pela primeira vez, uma infraestrutura de armazenamento de classe global, projetada por uma das empresas mais intensivas em dados do mercado financeiro, foi colocada nas mãos da comunidade HPC, IA, e além.
Se o desafio do TernFS é encontrar o público certo — cargas de trabalho massivas, leitura intensiva, WORM e operação multi-site — seu benefício está em permitir que outros times construam seus próprios motores de armazenamento, tal como uma equipe de corrida. O repositório oficial está disponível no GitHub (sem parâmetros de rastreamento), pronto para quem quiser explorar e contribuir.
