Qumulo LogoQumulo Logo

Blog

Uma breve história dos namespaces globais e onde estamos hoje

Há mais de vinte anos, o armazenamento corporativo vem buscando um único objetivo: um espaço de nomes global.

O desafio é que, embora o termo tenha permanecido o mesmo, seu significado vem evoluindo continuamente. Peça a cinco profissionais de armazenamento que definam um namespace global (GNS) e é provável que você receba cinco respostas diferentes. Alguns pensam em um único sistema de arquivos que abrange centenas de nós de armazenamento. Outros pensam em usuários colaborando entre vários escritórios. Outros ainda pensam em um software que se sobrepõe à infraestrutura de armazenamento existente para apresentar uma visão unificada dos dados.

Todos eles se referem a um namespace global. Apenas descrevem diferentes gerações desse namespace.

Essa distinção é importante porque as organizações atuais estão avaliando tecnologias como o Cloud Data Fabric da Qumulo com base na definição com a qual já estão familiarizadas. Para entender por que o Cloud Data Fabric representa uma abordagem arquitetônica diferente, vale a pena analisar como o setor chegou a esse ponto.

Os espaços de nomes globais resolveram, inicialmente, um problema de escala

A primeira geração de um namespace global não tinha, na verdade, nada a ver com ser global. O objetivo era resolver um dos maiores desafios operacionais enfrentados pelo armazenamento corporativo na época: a escalabilidade.

À medida que as organizações acumulavam mais dados, acumulavam também mais sistemas de arquivos. Os administradores eram obrigados a gerenciar dezenas, às vezes centenas, de espaços de nomes independentes, cada um com seus próprios limites de capacidade, tarefas de gerenciamento e sobrecarga operacional. O que os clientes queriam não era colaboração global; eles queriam um armazenamento que pudesse continuar crescendo sem a necessidade de criar continuamente novos sistemas de arquivos.

O NAS com escalabilidade horizontal mudou esse modelo. Um único sistema de arquivos podia abranger centenas de nós de armazenamento, continuando a crescer tanto em capacidade quanto em desempenho. Do ponto de vista do usuário, ele funcionava como uma unidade Z: infinitamente grande. Em vez de se perguntar onde os dados estavam armazenados, os usuários simplesmente acessavam o mesmo espaço de nomes, independentemente da quantidade de armazenamento que tivesse sido adicionada nos bastidores.

Para a época, esse foi um avanço arquitetônico significativo. Ele simplificou drasticamente o gerenciamento de armazenamento, permitindo que as organizações expandissem sua capacidade muito além do que as plataformas NAS tradicionais podiam suportar.

Mas essa arquitetura partia do princípio de que tudo ficava em um único local. Enquanto os usuários, os aplicativos e os dados permaneciam dentro de um único data center, ela funcionava excepcionalmente bem. No entanto, quando as organizações começaram a distribuir pessoas e cargas de trabalho por vários locais, um namespace capaz de escalar infinitamente dentro de um único local deixou de ser suficiente.

Então, a nuvem mudou a definição

À medida que as organizações se expandiram por diversas regiões e continentes, as prioridades do setor mudaram.

De repente, as empresas passaram a ter equipes de engenharia em vários países. As empresas de engenharia contavam com diferentes arquitetos que precisavam compartilhar arquivos CAD entre continentes. Pesquisadores colaboravam entre instituições, e as empresas passaram a exigir cada vez mais que os funcionários acessassem dados compartilhados, independentemente de sua localização.

O desafio já não era mais criar um único sistema de arquivos grande.

O desafio era disponibilizar um único sistema de arquivos em todos os lugares.

Essa exigência deu origem a uma segunda geração de tecnologias de namespace global. Em vez de se concentrarem exclusivamente na ampliação do armazenamento dentro de um único data center, essas arquiteturas centralizavam os metadados, armazenavam os dados em um armazenamento de objetos na nuvem e implantavam dispositivos de borda próximos aos usuários. Do ponto de vista do usuário, os arquivos apareciam em um compartilhamento de arquivos corporativo familiar, embora a arquitetura subjacente tivesse se tornado geograficamente distribuída.

Para muitas cargas de trabalho, essa abordagem funcionou extremamente bem. Os projetos costumavam ser de responsabilidade de um único escritório, com o trabalho sendo repassado entre locais, em vez de várias equipes modificarem os mesmos arquivos simultaneamente. A colaboração remota tornou-se significativamente mais fácil, pois os usuários podiam acessar os mesmos dados independentemente da localização.

A limitação dessa geração não era a escala — era a consistência em tempo real.

Essas arquiteturas partiam do pressuposto de que o trabalho era, em grande parte, sequencial, e não simultâneo. As equipes repassavam projetos de um escritório para outro ou, na maioria das vezes, trabalhavam em diferentes partes de um conjunto de dados. Quando vários usuários, aplicativos ou cargas de trabalho de IA passaram a precisar ler e gravar os mesmos dados simultaneamente em diferentes regiões, a arquitetura começou a mostrar suas limitações.

Esses limites incluem:

  • Os metadados estão centralizados, o que gera latência nas operações distribuídas globalmente.

  • O bloqueio de arquivos fica mais lento com o aumento da distância ou deixa de funcionar completamente.

  • É difícil alcançar a consistência forte sem comprometer o desempenho.

  • Os dispositivos de borda armazenam dados em cache, o que significa que a invalidação e a sincronização do cache se tornam cada vez mais complexas.

  • A IA, a computação de alto desempenho (HPC) e os pipelines de mídia modernos exigem muitos gravadores e leitores simultâneos, e não apenas acesso distribuído.

O próximo desafio foi preservar a infraestrutura existente

À medida que os ambientes corporativos continuavam a crescer, os clientes passaram a exigir outro requisito.

Poucas organizações desejavam substituir todas as plataformas de armazenamento simplesmente para obter os benefícios de um espaço de nomes compartilhado. Anos de investimento em infraestrutura haviam criado ambientes compostos por vários sistemas de armazenamento, cada um atendendo a diferentes aplicativos e cargas de trabalho.

Isso levou a outra evolução arquitetônica.

Em vez de criar um novo sistema de arquivos, as arquiteturas de sobreposição criaram um espaço de nomes comum em todo o armazenamento existente. As organizações puderam preservar a infraestrutura que já possuíam, ao mesmo tempo em que ofereciam aos usuários uma visão única e unificada de seus dados.

A proposta de valor era atraente porque a adoção se tornou significativamente mais fácil. Os clientes podiam continuar utilizando os investimentos em armazenamento já existentes, ao mesmo tempo em que simplificavam a forma como os usuários localizavam e acessavam as informações.

Como toda decisão arquitetônica, no entanto, essa abordagem envolveu compromissos.

Uma plataforma gerenciava o espaço de nomes, enquanto outra plataforma gerenciava os dados subjacentes. A coordenação de dois sistemas independentes introduziu uma complexidade operacional adicional, pois o gerenciamento de metadados, a consistência, a recuperação e o gerenciamento de dados passaram a exigir a integração de várias tecnologias.

Mais uma vez, isso não era uma falha. Refletia o problema que os clientes estavam tentando resolver naquela época.

As cargas de trabalho modernas mudaram o problema mais uma vez

Olhando para trás, é fácil comparar as arquiteturas atuais com os requisitos do passado. Essa não é a maneira correta de pensar sobre a evolução do espaço de nomes global.

Cada geração enfrentou o desafio determinante de sua época.

  • A primeira geração resolveu o problema da escala.

  • O segundo possibilitou a colaboração global.

  • A terceira preservou a infraestrutura existente.

As cargas de trabalho atuais simplesmente exigem os três.

A inteligência artificial, a produção de mídia, as ciências da vida, os serviços financeiros e outros setores que fazem uso intensivo de dados mudaram radicalmente a forma como as organizações trabalham com dados. Equipes em todo o mundo precisam, cada vez mais, trabalhar simultaneamente nos mesmos conjuntos de dados, em vez de se revezarem nos projetos.

Isso altera os requisitos para a própria plataforma de armazenamento.

  • A resiliência e a disponibilidade são importantes.

  • A coerência é importante.

  • A capacidade de combinação é importante.

  • O desempenho é importante.

O desafio não é mais simplesmente tornar os dados visíveis em vários locais. As organizações não podem mais tolerar consistência eventual, desempenho imprevisível, serviços de dados corporativos fragmentados, resiliência frágil ou a complexidade operacional de integrar vários sistemas. Cada local deve funcionar como se os usuários estivessem conectados ao mesmo sistema de arquivos local.

Isso representa um requisito arquitetônico fundamentalmente diferente daquele para o qual as gerações anteriores de espaços de nomes globais foram projetadas.

O Cloud Data Fabric da Qumulo representa uma abordagem arquitetônica diferente

É aí que o Cloud Data Fabric muda o jogo.

Em vez de se perguntar como criar outro namespace global, a Qumulo abordou o problema sob uma perspectiva diferente. Em vez de sobrepor camadas de software ao armazenamento ou coordenar vários sistemas independentes, o próprio sistema de arquivos passa a ser geograficamente distribuído.

Essa distinção é significativa porque uma única plataforma gerencia todas as funções essenciais do sistema de arquivos.

  • Uma única plataforma gerencia os metadados.

  • Uma única plataforma garante a persistência e a integridade dos dados.

  • Uma única plataforma determina a localização dos dados, o armazenamento em cache e o desempenho em todas as instalações.

O NAS corporativo sempre foi mais do que apenas um armazenamento compartilhado de arquivos. Ele oferece a consistência, a resiliência, a segurança, a proteção de dados e o gerenciamento centralizado dos quais as organizações dependem para executar cargas de trabalho de produção. O Cloud Data Fabric estende esses mesmos recursos corporativos a locais geograficamente distribuídos, em vez de limitá-los a um único data center.

Como a plataforma é definida por software e composível, o namespace global não está mais vinculado a nenhuma infraestrutura específica. As organizações podem implantar armazenamento e pontos de acesso onde for mais adequado — seja no local, na nuvem, na borda ou em várias regiões — sem alterar a forma como os usuários ou aplicativos interagem com seus dados. Em vez de unir tecnologias separadas, o Cloud Data Fabric oferece um único sistema de arquivos corporativo geograficamente distribuído que combina escalabilidade, colaboração global, recursos de NAS corporativo e flexibilidade de infraestrutura em uma única arquitetura.

O resultado é surpreendentemente simples. Os usuários têm acesso ao mesmo sistema de arquivos corporativo, com desempenho, serviços de dados, resiliência e segurança consistentes, estejam eles trabalhando do outro lado do corredor ou do outro lado do mundo.

O debate sobre o GNS também precisa evoluir

Um namespace global não é um conceito ultrapassado. É um conceito em evolução.

Nas últimas duas décadas, o termo foi redefinido várias vezes, pois a computação corporativa tem apresentado continuamente novos desafios. Cada geração de espaços de nomes globais representou uma resposta adequada aos problemas que as organizações estavam tentando resolver naquele momento.

As empresas de hoje, no entanto, esperam mais do que qualquer geração anterior poderia oferecer. Elas precisam da escala das plataformas NAS modernas, da colaboração entre sistemas distribuídos globalmente e da flexibilidade para implantar onde quer que seus negócios exijam, tudo isso mantendo a consistência, o bloqueio, o desempenho, a resiliência e os serviços de dados corporativos que os usuários já esperam.

A Apple oferece uma analogia útil. É possível montar um conjunto perfeitamente funcional de dispositivos de diferentes fabricantes. Um laptop com Windows, um celular Android, fones de ouvido Bose e um relógio Garmin podem, cada um à sua maneira, se destacar. O que torna o ecossistema da Apple atraente não é o fato de cada dispositivo ser superior individualmente, mas sim o fato de eles funcionarem juntos como uma experiência coesa.

O Cloud Data Fabric aplica a mesma filosofia ao armazenamento corporativo. Em vez de tratar o armazenamento local, os sistemas de arquivos nativos da nuvem, as implantações na borda, os aceleradores de IA e a colaboração global como produtos separados, ele oferece a arquitetura que os reúne em uma única plataforma. CNQ, ANQ, aceleradores de borda, aceleradores de IA na nuvem, Stratus e futuras inovações tornam-se componentes de um único ecossistema de dados integrado, em vez de tecnologias isoladas.

É por isso que o Cloud Data Fabric não deve ser visto simplesmente como mais um namespace global.

Isso representa a próxima evolução da própria ideia. Assim como cada geração anterior ampliou a definição do que um namespace global precisava resolver, o Cloud Data Fabric amplia-a novamente ao unificar NAS corporativo, colaboração global, infraestrutura composível e implantação nativa da nuvem em uma única arquitetura.

E quem sabe? Talvez a geração seguinte à próxima consiga resolver algo que ainda nem sequer imaginamos. Talvez consiga fazer com que os dados corporativos pareçam estar localizados na Terra, na Lua e em Marte.

Afinal, isso sempre foi Uma Breve História dos Espaços de Nomes Globais, e não o capítulo final.

O futuro não consiste em conectar mais recursos de armazenamento. Trata-se de permitir que pessoas, aplicativos e IA trabalhem com os mesmos dados em qualquer lugar.