NetApp quer comprar a PEAK:AIO — promessa de trilhões de arquivos ainda é meta

2 de outubro de 2026 às 10:00|Autor: Equipe editorial da QUASA|5 min de leitura

Em 25 de setembro de 2026, a NetApp anunciou, em comunicado oficial, a intenção de adquirir a PEAK:AIO e apresentou o suporte a trilhões de arquivos como objetivo de uma futura arquitetura baseada em ONTAP. A proposta é incorporar serviços de metadados e acesso paralelo a arquivos para acompanhar o crescimento de clusters de IA. A aquisição ainda não foi concluída, e a escala anunciada não é um resultado medido do sistema integrado.

A StorageReview informa que os termos da transação não foram divulgados e descreve um teste anterior em que software da PEAK:AIO, executado em um servidor Dell PowerEdge R7725xd, entregou 160 GB/s por NVMe-oF RDMA a dois clientes. A medição diz respeito àquela configuração de armazenamento, não à integração planejada com ONTAP. O fechamento do negócio continua sujeito às condições habituais e a aprovações regulatórias.

O que a NetApp pretende integrar ao ONTAP

O plano combina as inovações de metadados da PEAK:AIO, um namespace global e acesso paralelo baseado em NFS com o ONTAP como base para os dados. Um namespace oferece uma visão organizada dos arquivos compartilhados; os serviços de metadados ajudam a localizar cada arquivo e a administrar informações necessárias para acessá-lo. Essa divisão é relevante quando muitos clientes procuram arquivos ao mesmo tempo, mesmo antes de começar a transferir seu conteúdo.

Na arquitetura apresentada pela NetApp, metadados e dados ficam separados para que os serviços de metadados possam crescer independentemente da capacidade de armazenamento. A intenção é atender mais solicitações sobre arquivos sem depender apenas da expansão do espaço onde o conteúdo está guardado. A empresa descreve essa combinação como uma evolução para clientes do ONTAP, mas não detalhou em qual produto ou configuração a tecnologia da PEAK:AIO apareceria primeiro.

Por que os metadados importam para as GPUs

Uma GPU só consegue processar dados que o sistema lhe entrega. Antes da leitura de um arquivo, o armazenamento precisa resolver operações como localizar seu nome, consultar atributos e indicar onde está o conteúdo. Se muitos processos fazem essas solicitações simultaneamente e o serviço de metadados não acompanha o ritmo, a leitura pode atrasar apesar de haver capacidade para guardar os dados.

O NFS paralelo, ou pNFS, permite separar a coordenação do acesso da transferência do conteúdo. Depois de receber informações sobre a disposição dos dados, um cliente pode se comunicar com servidores de dados por caminhos paralelos. Isso oferece uma forma de evitar que um único serviço concentre toda a transferência, mas não garante, por si só, maior utilização das GPUs: o efeito depende dos clientes, da rede, da carga de trabalho e da implementação.

A NetApp associa a arquitetura proposta à redução de pausas das GPUs causadas por espera de dados. Trata-se de um benefício esperado, não de um ganho quantificado no anúncio. Para demonstrá-lo na combinação com ONTAP, seria preciso observar tanto as operações de metadados quanto a entrega de dados sob uma carga definida e medir o efeito sobre o processamento.

O que o Lattice já mostra

O repositório do Lattice apresenta uma implementação aberta de servidor de metadados em espaço de usuário para NFSv4.2 e pNFS Flex Files; o próprio projeto a classifica como versão inicial para pesquisa, desenvolvimento e testes, ainda não recomendada para produção sem validação independente. O código mostra como a PEAK:AIO aborda o problema de distribuir operações de metadados, mas seu estado público não equivale a uma função já entregue no ONTAP.

Na organização descrita pelo projeto, vários servidores de metadados podem compartilhar uma autoridade baseada em RonDB, enquanto servidores de dados atendem o acesso ao conteúdo por caminhos separados. O objetivo dessa separação é ampliar o atendimento às operações sobre arquivos sem prender todo o trabalho a um servidor fixo. A existência dessa arquitetura no repositório, porém, não estabelece quantos arquivos uma implantação de produção suporta nem demonstra o comportamento da futura combinação com os produtos da NetApp.

O que o teste de desempenho não mede

O ensaio anterior com software da PEAK:AIO mede taxa de transferência em um conjunto específico de servidor, unidades de armazenamento, rede e clientes. Ele é evidência de desempenho daquela configuração sob as condições relatadas. Não mede o fechamento da aquisição, a capacidade de um namespace distribuído em produção ou a eficiência de uma arquitetura com ONTAP.

São grandezas diferentes: largura de banda descreve a velocidade de transferência do conteúdo; desempenho de metadados descreve a resposta a operações como localizar, abrir ou alterar arquivos; escala do namespace diz respeito ao volume de arquivos que o sistema consegue administrar. Uma medição favorável de transferência não comprova automaticamente as outras duas. Também não informa se as GPUs de um cluster passariam menos tempo esperando dados após a integração proposta.

O que ainda falta saber sobre a aquisição

Não há preço divulgado para a transação, prazo público para a integração nem resultados publicados de escala em produção da arquitetura combinada. O anúncio também não fixa uma data em que clientes do ONTAP poderiam receber as capacidades planejadas. Antes disso, a operação precisa cumprir as condições de fechamento e obter as aprovações aplicáveis.

Assim, a história permanece em três estágios distintos: uma intenção de aquisição anunciada, um projeto aberto de metadados ainda experimental e medições anteriores de software da PEAK:AIO em outra configuração. O próximo dado capaz de aproximar a promessa da realidade será uma especificação da integração acompanhada de testes da arquitetura entregue. Por enquanto, o suporte a trilhões de arquivos continua sendo uma meta, não uma escala demonstrada para o conjunto NetApp–PEAK:AIO.