1,6 TB/s na AWS NÃO É A NOTÍCIA PRINCIPAL para o Qumulo Cloud Native

O Qumulo, uma solução nativa da nuvem, atingiu 1,6 TB/s na AWS, e isso nem é o melhor. Veja o que isso significa para você.

Há anos, os clientes corporativos vêm manifestando a mesma preocupação em relação à nuvem:

“Simplesmente não é rápido o suficiente.”
“Mesmo que fosse, não conseguimos obter capacidade de computação suficiente de forma confiável em uma única zona de disponibilidade.”

Um cliente expôs o desafio de forma direta:

“Precisamos ultrapassar 1,5 TB/s de taxa de transferência sustentada na nuvem, sem comprometer a confiabilidade nem a flexibilidade.”

Esse “B” maiúsculo em TB faz diferença. Trata-se de bytes, não de bits. Um byte equivale a oito bits; portanto, 1,5 TB/s corresponde a aproximadamente 12 terabits por segundo de transferência sustentada de dados. E a sustentabilidade é igualmente importante. Não se trata de um pico de curta duração ou de um aumento impulsionado pelo cache, mas de uma taxa de transferência contínua mantida ao longo do tempo.

Para contextualizar esse número, o streaming de um único filme em 4K normalmente requer cerca de 25 megabits por segundo. A 12 Tb/s, o mesmo sistema poderia, teoricamente, suportar quase meio milhão transmissões simultâneas em 4K.

E para quem está curioso, o Qumulo CNQ superou o desafio, atingindo 1,6 TB/s e 20,7 milhões de IOPS, mas falaremos mais sobre isso depois.

Na verdade, os números de desempenho por si só nunca foram a verdadeira preocupação. Poucas empresas precisam de 1,5 TB/s hoje em dia, mas a experiência nos mostra que planejar apenas com base na demanda atual raramente dá certo. Construir sistemas de alto desempenho a partir de recursos em nuvem costuma ser uma questão de orçamento, tolerância ao risco e fragilidade do sistema. De fato, focar apenas na velocidade é uma ótima maneira de ficar em termos de “você” com o diretor financeiro em muitas organizações — e não no bom sentido. Combinar velocidade com uma arquitetura de infraestrutura frágil pode resolver temporariamente um desafio, mas gera muitos desafios tecnológicos e econômicos adicionais como efeitos em cadeia.

Resolver o problema fundamental da flexibilidade arquitetônica exige uma nova forma de pensar.

A maioria das plataformas de armazenamento em nuvem obriga os clientes a tomarem decisões de infraestrutura de longo prazo logo no início. Desempenho, disponibilidade e custo estão intimamente ligados, exigindo o provisionamento excessivo para atender à demanda de pico, a duplicação de dados para garantir resiliência ou a vinculação de cargas de trabalho a locais específicos. Uma vez tomadas essas decisões, é difícil e caro revertê-las.

Como resultado, o armazenamento passa a ser a restrição em torno da qual as equipes de computação planejam suas atividades, em vez de uma base flexível que se adapta às mudanças nas cargas de trabalho.

A pergunta mais pertinente que os clientes deveriam fazer não é: “Qual é a velocidade máxima desse aparelho?”

A questão é esta: a nuvem é capaz de oferecer um desempenho extremamente alto quando eu precisar, sem me prender a arquiteturas frágeis, armazenamento duplicado ou infraestrutura permanentemente sobredimensionada?

A Qumulo levou esse desafio a sério. Não buscando um número que chamasse a atenção, mas sim comprovando um modelo operacional diferente. E é por isso que 1,6 TB/s NÃO É O DESTQUE. Você pode perguntar: “Qumulo, se escalar para 1,6 TB/s na AWS, “Se essa não é a manchete, qual é?”

E se a verdadeira manchete não fosse sobre velocidade, mas sobre eliminar restrições zonais sem arcar com um custo econômico?

A resposta começa com uma arquitetura nativa da nuvem, e não com uma arquitetura adaptada posteriormente.

1import os
2import sys
3from datetime import datetime
4import libnfs
5
6os.environ['LD_LIBRARY_PATH'] = "/var/task/lib:/var/task/libnfs:" + os.environ.get('LD_LIBRARY_PATH', '')
7sys.path.append('/var/task')
8
9def handler(event, context):
10    try:
11        nfs = libnfs.NFS("nfs://YOUR_CNQ_ADDRESS/YOUR_NFS_EXPORT")
12    except Exception as e:
13        return {"statusCode": 500, "body": "Error connecting to NFS export: " + str(e)}
14    
15    try:
16        timestamp = datetime.now().isoformat()
17        message = f"Hello from AWS Lambda via CNQ! - {timestamp}\n"
18        
19        f = nfs.open("/testing-from-lambda.txt", "w+")
20        f.write(message)
21        f.close()
22    except Exception as e:
23        return {"statusCode": 500, "body": "Error writing to file: " + str(e)}
24    
25    try:
26        f = nfs.open("/testing-from-lambda.txt", "r")
27        content = f.read()
28        return {"statusCode": 200, "body": content}
29    except Exception as e:
30        return {"statusCode": 500, "body": "Error reading file: " + str(e)}
31
32Built for the Cloud from the Beginning

A arquitetura da Qumulo foi projetada para a nuvem, e não adaptada a ela. Essa diferença é importante.

A maioria dos sistemas de armazenamento de arquivos na nuvem não falhou devido a uma execução deficiente. Eles falharam porque herdaram premissas de uma era definida pelo hardware e nunca foram totalmente reprojetados para operações baseadas na nuvem.

Os sistemas de arquivos tradicionais foram construídos com base em uma verdade física simples: o hardware de armazenamento definia tanto a capacidade quanto o desempenho. Mais discos significavam mais espaço, e mais espaço significava maior taxa de transferência. Capacidade e desempenho estavam fisicamente interligados. Não era possível escalar significativamente um sem o outro. Esse modelo fazia todo o sentido quando as organizações compravam discos giratórios, instalavam servidores em racks e montavam suas próprias redes.

Quando os provedores de nuvem lançaram os serviços gerenciados de arquivos, muitas dessas mesmas suposições foram mantidas.

Alguns serviços ajustam a capacidade automaticamente, mas o desempenho continua vinculado à quantidade de dados armazenados. Outros exigem que os clientes provisionem a capacidade e a taxa de transferência em conjunto, como atributos fixos. Existe elasticidade, mas ela é limitada pelo mesmo acoplamento que existia nos ambientes locais.

Como o desempenho e a capacidade continuam ligados, os clientes se veem diante de duas opções pouco atraentes:

• Provisão para picos: pagar para garantir o máximo de desempenho e capacidade em todos os momentos, mesmo quando a utilização estiver baixa

• Provisão para média: economizar dinheiro até que as cargas de trabalho atinjam um limite e o desempenho se torne o gargalo

A maioria das equipes opta pela primeira opção porque o custo de cargas de trabalho com restrições de desempenho ou prazos não cumpridos supera em muito o custo do provisionamento excessivo; no entanto, pagar pelo que você talvez A necessidade é o oposto da economia da nuvem.

O problema se agrava quando a diversidade de protocolos entra em cena. Os ambientes Linux esperam o NFS. Os ambientes Windows exigem o SMB. As aplicações modernas dependem cada vez mais do acesso a objetos por meio de APIs compatíveis com S3.

O resultado é a fragmentação. Serviços diferentes, modelos de escalonamento diferentes, comportamentos operacionais diferentes. As equipes que executam cargas de trabalho mistas costumam gerenciar vários sistemas de armazenamento, cada um otimizado para um caso de uso específico.

Com o passar do tempo, o armazenamento passa a ser o fator limitante em torno do qual as equipes de computação planejam suas atividades.

“Quanto espaço de armazenamento temos?”, perguntam eles. “O que podemos rodar?”

Isso está ao contrário. A infraestrutura deve se adaptar às cargas de trabalho, e não o contrário.

O Qumulo, nativo da nuvem, rompe esse acoplamento.

Desde o início, o CNQ separou, por padrão, o desempenho da capacidade. A computação é escalonada independentemente do armazenamento de objetos durável, sendo que o desempenho é aumentado ou reduzido por meio do ajuste dos recursos de computação, em vez da pré-alocação de capacidade. Os clientes pagam apenas pelo armazenamento que consomem, enquanto o desempenho se torna um atributo elástico, em vez de um compromisso fixo.

Isso permite que a CNQ ofereça suporte a serviços de arquivos corporativos de uso geral de maneira econômica, ao mesmo tempo em que se adapta a cargas de trabalho especializadas e de alta intensidade, sem obrigar os clientes a um provisionamento excessivo permanente ou a silos de armazenamento fragmentados.

Isso deixa a manchete bem clara: CNQ: Projetado para a nuvem, não adaptado a ela. Mesmo assim, parece que falta alguma coisa.

O desafio: ser mais rápido do que em um ambiente local, sem rede de segurança

A exigência do cliente não era teórica.

No ambiente local, a carga de trabalho era executada em um único data center, com os recursos de computação localizados próximos ao armazenamento para minimizar a latência. Se ocorresse uma falha na infraestrutura — seja de energia, refrigeração ou rede —, a carga de trabalho seria interrompida. Havia um sistema de recuperação de desastres, mas, como a maioria dos sistemas desse tipo, ele era assíncrono, pouco testado e incapaz de manter o desempenho total da carga de trabalho.

O sistema funcionava, mas era frágil.

Tradicionalmente, a migração para a nuvem nunca teve a ver com velocidade. O objetivo era eliminar pontos únicos de falha sem introduzir novas restrições. Mas, se isso pudesse ser feito rapidamente, como isso afetaria os negócios dos nossos clientes?

Na nuvem, as expectativas eram claras:

• Superar o desempenho das instalações locais

• Evite a dependência de uma única Zona de Disponibilidade

• Manter o desempenho total durante falhas

• Faça isso sem dobrar os custos de armazenamento

É justamente nesse último requisito que muitos sistemas de arquivos em nuvem apresentam deficiências.

A maioria das ofertas com várias zonas de disponibilidade (Multi-AZ) utiliza replicação. Cópias completas dos dados são mantidas em cada zona para garantir a disponibilidade. Embora seja eficaz em termos de durabilidade, essa abordagem traz consequências reais. Os custos de armazenamento aumentam linearmente com o número de zonas. O desempenho de gravação é reduzido devido à coordenação entre as zonas. A configuração Multi-AZ passa a ser algo que os clientes reservam para cenários de falha, em vez de para a operação normal.

Ao mesmo tempo, a disponibilidade de recursos de computação na nuvem não está distribuída de maneira uniforme.

Cargas de trabalho que exigem muito da GPU e da CPU frequentemente enfrentam restrições de capacidade que variam de acordo com a zona e ao longo do tempo. Um projeto que vincula os dados a uma única zona obriga a computação a segui-los, mesmo quando há capacidade disponível em outros locais da região. Os clientes acabam tendo que procurar instâncias, reservar recursos de computação antes que os dados estejam prontos (o que é oneroso) ou adiar completamente o trabalho (o que prolonga o tempo até a obtenção dos resultados).

O cliente desafiou a Qumulo em termos de velocidade, confiabilidade e resiliência. A solução deve oferecer maior desempenho, ao mesmo tempo em que elimina a dependência em nível de zona, elimina a duplicação de armazenamento e permite que as cargas de trabalho sejam executadas onde quer que haja capacidade de computação disponível a qualquer momento.

A Qumulo resolve esse problema no nível da arquitetura, em vez de simplesmente sobrepor a disponibilidade às premissas legadas.

A arquitetura: disponibilidade em múltiplas zonas por padrão, não por duplicação

No centro dessa implantação estava um cluster CNQ com várias zonas de disponibilidade (AZ), distribuído uniformemente por três zonas de disponibilidade dentro de uma única região da AWS.

Uma Zona de Disponibilidade (AZ) é um conjunto fisicamente separado de um ou mais data centers dentro de uma região da AWS. Cada AZ foi projetada para operar de forma independente, com sua própria fonte de alimentação, refrigeração e rede, ao mesmo tempo em que está conectada a outras AZs na região por meio de links de alta largura de banda e baixa latência. Essa separação permite que os aplicativos permaneçam disponíveis mesmo que todo um data center sofra uma interrupção no serviço.

A durabilidade é garantida pelo Amazon S3 em nível regional, onde os dados são protegidos automaticamente em várias instalações. É por isso que a AWS oferece 11 noves (99,999999999% de durabilidade), amplamente considerado como a referência do setor para proteção de dados.

Por padrão, a arquitetura do CNQ abrange várias Zonas de Disponibilidade da AWS sem exigir réplicas completas dos dados dos clientes em cada zona. Como resultado:

• O custo de armazenamento é o mesmo, independentemente de o CNQ ser executado em uma ou em várias zonas de disponibilidade (AZs)

• O desempenho de gravação não é prejudicado pela replicação entre zonas

• A operação Multi-AZ é o estado normal, não um modo de falha

Observação: Normalmente, os serviços com várias zonas de disponibilidade (multi-AZ) custam o dobro das suas implementações com uma única zona de disponibilidade (single-AZ). Manter o custo igual representa um benefício econômico significativo.

Se uma Zona de Disponibilidade ficar indisponível, o cluster continua operando nas zonas restantes, sem perda de dados e sem a necessidade de failover para uma cópia secundária.

Esse projeto é mais simples, mais rápido e, em termos de custos, mais barato do que as abordagens com várias zonas de disponibilidade (AZ) baseadas em réplicas.

Seria fácil colocar isso como manchete: A CNQ Architecture oferece resiliência em várias zonas (Multi-AZ) sem duplicação de dados. Não está errado. Mas podemos fazer ainda melhor.

A vantagem do CNQ com múltiplas zonas de disponibilidade para cargas de trabalho com uso intensivo de GPU

O Multi-AZ costuma ser abordado como um recurso de disponibilidade, o que é válido, mas, hoje em dia, a disponibilidade é considerada um requisito básico. O que realmente importa é o que o CNQ oferece em termos de computação, ou seja, tornar a aquisição de GPUs e CPUs muito menos complicada.

A maioria dos sistemas de arquivos em nuvem, mesmo aqueles comercializados como multi-AZ, vincula o armazenamento a uma única zona primária. A computação precisa seguir os dados. Se não houver GPUs ou CPUs disponíveis nessa zona, a carga de trabalho fica paralisada, mesmo quando há capacidade ociosa em outro local da região.

Isso obriga as equipes a procurarem GPUs e CPUs. Primeiro, elas buscam instâncias de computação, que são escassas. Em seguida, reservam e pagam por essa computação antes que ela possa ser utilizada. Depois, surge o problema dos dados. Grandes conjuntos de dados precisam ser copiados ou transferidos para o local onde a computação foi encontrada. Somente após a conclusão de todas essas etapas é que o trabalho pode ser retomado. O CNQ elimina essa restrição.

Com o CNQ, os recursos de computação em várias Zonas de Disponibilidade podem acessar o mesmo conjunto de dados simultaneamente. Os clientes podem agregar a capacidade de todas as zonas em um único pool lógico, sem precisar copiar ou reorganizar os dados.

Se houver GPUs disponíveis em uma zona na segunda-feira e em outra zona na terça-feira, os clientes não precisam transferir dados nem reconstruir a infraestrutura. Basta direcionar a implantação existente do CNQ para onde quer que haja recursos de computação disponíveis.

Do ponto de vista do cliente, isso permite:

• Acesso mais rápido a GPUs e CPUs escassas

• Sem fases de reorganização ou cópia de dados

• Sem penalidades de replicação

• Sem aumento no custo de armazenamento

O trabalho pode começar imediatamente, pois os dados já estão disponíveis em todas as Zonas de Disponibilidade do S3, que funciona como a camada de armazenamento persistente. Ao contrário do Amazon Elastic Block Store (EBS) ou do armazenamento vinculado à instância, essa arquitetura não exige a cópia ou a rehidratação dos dados em cada zona antes que a computação possa começar. Em vez disso, o sistema de arquivos acessa os dados localmente em cada AZ por meio do NeuralCache. Essa abordagem elimina os esforços de preparação de dados que levam semanas e mantém os recursos computacionais caros totalmente utilizados desde o início.

Mais uma vez, você deve estar pensando: com certeza essa deve ser a manchete: A CNQ e a arte de tornar a busca por GPUs mais suportável. Estamos no caminho certo. Vamos ver se conseguimos superar isso.

Aumente a capacidade até o nível que desejar e, em seguida, reduza-a novamente

O cliente solicitou atingir uma taxa de transferência sustentada superior a 1,5 TB/s na nuvem, sem comprometer a confiabilidade ou a flexibilidade. A Qumulo criou uma implantação de teste que acabou superando as expectativas, alcançando 1,6 TB/s de taxa de transferência agregada sustentada e 20,7 milhões de IOPS. De fato, esses números são impressionantes (leitores futuros, por favor, consultem a data de publicação para contextualizar), mas tratam-se de requisitos de pico ou médios? E se você é um cliente lendo isto e está interessado em 1,6 TB/s e 20,7 milhões de IOPS, não se preocupe, nós temos a solução para você! Veja abaixo.

Muitos clientes priorizam a flexibilidade e precisam da capacidade de aumentar ou reduzir os recursos conforme a demanda muda. Conforme discutido anteriormente, os clientes frequentemente escolhem entre provisionar para picos de demanda a um custo elevado ou dimensionar para o uso médio, correndo o risco de quedas no desempenho. Esse dilema destaca o valor central da nuvem: a variabilidade. Essa configuração pode custar cerca de US$ 5.000 por hora, o que a torna valiosa quando necessária, mas economicamente inviável para operação contínua. A capacidade de utilizar esse nível de desempenho apenas quando necessário torna uma abordagem baseada em nuvem economicamente viável em comparação com a infraestrutura local.

O CNQ permite que os clientes alcancem o desempenho máximo sem precisar pagar pela capacidade máxima o tempo todo. Essa é a diferença.

Em muitos sistemas de arquivos na nuvem, o desempenho está vinculado à capacidade provisionada permanentemente. Se você dimensionar a capacidade com base nos picos de demanda, pagará o preço de pico o tempo todo, mesmo quando a carga de trabalho diminuir.

O CNQ separa essas decisões.

Os clientes podem aumentar significativamente o desempenho para cumprir um prazo, uma janela de treinamento ou atender a um pico de produção e, em seguida, reduzir a escala assim que o pico passar. Você não fica preso a uma configuração máxima apenas para lidar com picos ocasionais.

Essa elasticidade se aplica não apenas à escala, mas também à escolha das instâncias. Nessa implantação, os tipos de instância foram ajustados no meio do processo de projeto devido a restrições de capacidade regionais. O cluster simplesmente cresceu para 250 nós, sustentando cerca de 333.000 conexões, utilizando uma largura de banda menor por nó, sem a necessidade de qualquer reprojeto.

Posteriormente, os clientes podem migrar para famílias de instâncias mais recentes a um custo menor, por meio da substituição gradual, sem tempo de inatividade nem migração de dados.

Juntos, finalmente descobrimos o título: A CNQ oferece Desempenho máximo sem comprometimento máximo. É mesmo? Mas por que alguém precisaria desse nível de desempenho máximo?

Os momentos que exigem desempenho máximo extremo

Nem toda carga de trabalho exige um rendimento extremo, e é exatamente essa a questão.

Essa arquitetura não se trata de funcionar sempre a 1,6 TB/s. Trata-se de ter a opção de atingir essa velocidade quando o tempo é essencial, sem sofrer prejuízos financeiros ou operacionais no restante do tempo.

O que parece excessivo hoje costuma se tornar o padrão de amanhã. Então, por que alguém precisaria desse desempenho?

Imagine uma empresa do setor de energia decidindo se deve arrendar um poço avaliado em um bilhão de dólares. A questão não é se a análise vai custar alguns milhões a mais em gastos com nuvem. A questão é quem chega à resposta primeiro. Ser o primeiro a chegar pode determinar quem fica com o ativo e quem sai de mãos vazias.

Na área da saúde, uma análise genômica mais rápida pode significar a diferença entre uma incerteza prolongada e uma decisão terapêutica capaz de salvar vidas.

No setor de mídia e entretenimento, a velocidade pode determinar se um projeto será lançado dentro do prazo previsto ou se os atrasos se transformarão em custos não planejados que eliminam as margens de lucro. Renderização mais rápida, análise mais rápida e iteração mais rápida significam menos equipes criativas ociosas, à espera da infraestrutura.

Em todos esses exemplos, a limitação não é a quantidade de dados que pode ser armazenada. É o tempo necessário para obter insights e o tempo para tomar decisões. Quando a infraestrutura fornece respostas mais rapidamente, as organizações não estão apenas executando cargas de trabalho com mais rapidez; elas também estão apresentando resultados mais rapidamente. Elas estão reduzindo ciclos de decisão inteiros e gerando mais valor a partir de seu recurso mais caro e insubstituível: o tempo dos especialistas.

Imagine o que sua empresa poderia alcançar quando o desempenho pudesse ser ampliado ou reduzido conforme a necessidade, você deixasse de pagar por capacidade ociosa e passasse a pagar por resultados.

Certamente a manchete deve ser: Não espere mais pela infraestrutura. A CNQ oferece resultados mais rapidamente. Mas será que isso realmente abrange tudo?

O efeito cumulativo

Ao proporcionar uma taxa de transferência agregada sustentada de 1,6 TB/s em leitura sequencial, a Qumulo superou a meta de desempenho original do cliente em mais de 50% em comparação com os sistemas locais. Para atingir esse nível de desempenho, foi necessária uma arquitetura nativa da nuvem, construída inteiramente sobre a infraestrutura padrão da AWS e abrangendo três Zonas de Disponibilidade.

Mais importante ainda, este trabalho mostra que um desempenho extremo não exige sacrifícios inaceitáveis.

Além da taxa de transferência de 1,6 TB/s, o sistema atingiu 20,7 milhões de IOPS com latência inferior a um milissegundo.

Mas o verdadeiro valor vai além dos números. A arquitetura permite que os clientes distribuam recursos de computação por todas as Zonas de Disponibilidade, em vez de ficarem restritos a uma única zona, facilitando significativamente a aquisição de GPUs e CPUs em grande escala. Isso também comprova a resiliência do CNQ na AWS, oferecendo excelente disponibilidade de dados e durabilidade de 99,9999999%, sem inflar os custos de armazenamento por meio de duplicação. Os clientes mantêm a flexibilidade de escolher famílias de instâncias que atendam às suas necessidades de desempenho e orçamentos, pagando apenas pelo que realmente utilizam.

Em conjunto, essas capacidades geram um efeito cumulativo, o que chamamos de Efeito cumulativo.

Talvez não seja apenas uma manchete que deva chamar sua atenção. Talvez sejam todas elas.

• O Qumulo, nativo da nuvem, atingiu 1,6 TB/s na AWS

• CNQ: Projetado para a nuvem, não adaptado a ela

• A arquitetura CNQ oferece resiliência em várias zonas (Multi-AZ) sem duplicação de dados

• CNQ e a arte de tornar a busca por GPUs mais suportável

• A CNQ oferece desempenho de ponta sem exigir o máximo de dedicação

• Não espere mais pela infraestrutura. A CNQ oferece resultados mais rapidamente

Essa combinação é a história.

Conclusão

Essa implantação comprovou que um sistema de arquivos nativo da nuvem pode oferecer desempenho excepcional sem comprometer outros aspectos:

• Multi-AZ por concepção, não por duplicação

• Desempenho que se adapta tanto ao aumento quanto à redução da demanda

• Liberdade para executar programas onde houver recursos de computação disponíveis, e não onde os dados estejam fixados

• O que resulta em resultados mais rápidos

A nuvem não precisa apenas ser rápida o suficiente. Com a arquitetura certa, ela pode ser mais flexível, mais resiliente e mais econômica do que os sistemas locais jamais foram.