How is this different from your AI Computing Datacenter Network solution?

Different buyer, different traffic. The AI computing page is for the team running GPU training — the fabric moving collective-communication traffic between accelerators. This page is for the team running storage and disaster recovery — the fabric moving reads, writes and replication between servers and all-flash arrays. Both need a lossless Ethernet fabric with RoCEv2, PFC and ECN, but they are usually different networks serving different clusters, sized and tuned against different traffic patterns. If your problem is GPUs waiting on the network, that page is yours; if it is storage latency, Incast stalls or replication between arrays, this page is.

What is NVMe over Fabric and why does it need a lossless network?

NVMe over Fabric (NoF) lets a server talk to an all-flash array over the network at close to the latency of a locally attached drive — but only if the network never drops a packet along the way. Ordinary Ethernet handles congestion by discarding frames, which an NVMe host recovers from by retransmitting — and a retransmit at flash speed is a stall the application can see. A lossless fabric applies back-pressure and congestion marking instead of dropping, so the array's speed actually reaches the application.

Do we need active-active storage, or is primary-standby enough?

For most customers, primary-standby with fast, rehearsed failover is the better trade. True active-active across two sites is expensive — it doubles storage hardware and imposes strict latency and consistency requirements between the arrays — and it only pays off when the cost of a short storage outage genuinely exceeds that price. We will run that comparison with you honestly before you commit to either.

Can you validate that our current network is the bottleneck before we rebuild anything?

Yes, and we would rather do that first. Packet loss counters, PFC pause counts, ECN marks and per-queue latency on your existing fabric will tell you honestly whether storage performance is being lost to the network or to something else — a busy controller, an undersized array or an application access pattern often look identical to network congestion on a dashboard. If the network turns out to be innocent, that is a useful result and a cheaper one than a rebuild that fixes nothing.

Does this work over long distance for multi-center DR?

It works, within limits that distance itself sets — not the network design. Synchronous replication for true active-active needs latency low enough that round-trip time stays within your storage platform's tolerance, which in practice caps the usable distance at metro scale. Beyond that distance, asynchronous replication to a standby site is the honest answer, and we will tell you which regime your sites actually fall into before you commit to a topology.

Início / Soluções / Redes industriais e datacom / Rede de storage sem perdas

Rede de storage sem perdas: o gargalo não é o array flash, é a rede

Um array totalmente flash promete latência em microssegundos e cumpre — até que uma malha Ethernet comum perca um pacote sob congestionamento Incast e transforme essa promessa em uma travada visível para a aplicação. Projetamos redes de storage a partir dos seus requisitos, com a marca dos equipamentos como escolha aberta na fase de projeto: uma malha RoCEv2 dedicada com PFC e ECN ajustados ao seu tráfego real, acesso NVMe over Fabric (NoF), e storage ativo-ativo entre sites quando os números realmente justificam. Dimensionado honestamente para um único cluster de storage, dois data centers ativo-ativo, ou recuperação de desastres multicêntrica.

Por que o desempenho do storage morre na rede, não no array

Quatro padrões por trás de quase toda chamada de "nosso array flash parece lento" que recebemos:

Desempenho totalmente flash estrangulado por Ethernet comumO array pode responder em microssegundos; uma rede construída para tráfego de escritório perde um quadro sob carga e a aplicação vê, em vez disso, uma travada de vários milissegundos — uma diferença de mil vezes que a ficha técnica nunca menciona.

Incast transforma "muitas leituras" em um engarrafamentoDezenas de servidores lendo o mesmo LUN ao mesmo tempo enviam suas respostas no mesmo instante — os buffers de switch comuns não conseguem absorver isso, e as perdas caem exatamente no padrão de tráfego que o storage mais usa.

Ativo-ativo e DR exigem zero perda, não "mais ou menos bem"A replicação síncrona entre dois arrays não tolera retransmissões — um pacote perdido não apenas atrasa a replicação, ele arrisca a garantia de consistência pela qual todo o design ativo-ativo foi comprado.

O storage multissite estica o mesmo requisito através da distânciaUm link de replicação sem perdas no rack ainda precisa continuar sem perdas em um trajeto metropolitano ou de longa distância — e a própria distância impõe limites que nenhum ajuste de switch consegue remover.

Arquitetura: malha RoCEv2 dedicada + ajuste PFC/ECN + acesso NVMe-oF

Um caminho de storage projetado para zero perda de pacotes, não compartilhado com — nem esperando não colidir com — tudo mais na rede:

Diagrama desenhado pela AtlasCommTech seguindo a prática de projeto de data center de nível operadora. Os rótulos permanecem em inglês para clareza técnica.

Por que nós: nosso fundador passou 13 anos dentro do ecossistema de parceiros da Huawei entregando redes de operadoras — onde um pacote perdido era um incidente reportável. Em uma malha de storage tratamos cada quadro perdido da mesma forma, porque é exatamente isso que separa uma rede sem perdas no papel de uma que realmente é.

Opções de equipamento

A solução é dimensionada primeiro pelos seus requisitos e orçamento — a mesma arquitetura pode ser entregue com as linhas de produto de vários fabricantes. Ajudamos você a escolher conforme a disponibilidade de fornecimento no país de destino, o orçamento e os hábitos de operação da sua equipe.

Huawei — linhas de campus empresarial, WAN e segurançaEcossistema maduro com uma rede de serviços global.

ZTE Wantone — linhas datacom comparáveisDireção de custo-benefício; fornecimento mais fluido em alguns mercados.

H3C — linhas de campus e data centerPortfólio de campus e data center amplamente implantado.

Switches industriais Atlas — camada de acesso em cenários industriaisNossa própria linha industrial — usada para pontos de acesso de filial e borda reforçados que alimentam esta malha de storage; compatível com o núcleo de storage de qualquer marca.

O que o projeto entrega

Seis propriedades de uma malha de storage bem ajustada que uma rede de data center genérica e compartilhada nunca terá:

Zero perda de pacotes sob IncastPFC e ECN são ajustados conforme seu padrão real de tráfego muitos-para-um, não um modelo — a contrapressão e a marcação de congestionamento substituem as perdas antes mesmo que aconteçam.

Acesso NVMe-oF com latência quase localOs servidores acessam os arrays totalmente flash pela rede com latência próxima à de uma unidade conectada diretamente — o objetivo do projeto, entregue em vez de prometido em uma ficha técnica.

Um caminho de storage dedicado, não compartilhadoO tráfego de storage tem sua própria malha ou suas próprias faixas ajustadas — um job de backup ou uma cópia em massa nunca vira o motivo de uma transação travar.

Storage ativo-ativo quando os números justificamReplicação síncrona entre dois sites, dimensionada honestamente conforme a latência e o custo de hardware que realmente carrega — não vendida por padrão.

Telemetria que detecta perdas antes da aplicaçãoA profundidade por fila, as contagens de pausa PFC e as marcações ECN são exportadas desde o primeiro dia, para que um problema de congestionamento em desenvolvimento apareça em um painel antes de virar um chamado de suporte.

Um link de replicação de DR dimensionado honestamenteA distância define o limite da replicação síncrona, não a configuração do switch — dizemos em qual regime seus sites realmente estão antes de você se comprometer com uma topologia.

Três portes, uma mesma lógica

Informe seu número de arrays, número de hosts e requisito de replicação — a faixa define a forma da malha:

Os números que guiam o projeto:

Zero perda de pacotes tolerada no caminho de storage — os limiares de PFC e ECN são ajustados ao seu cluster, não copiados de um modelo

Leaf-para-spine de storage mantido não bloqueante ou próximo disso — a malha é dimensionada conforme seu padrão de leitura/escrita, não uma taxa de oversubscription genérica

Distância de replicação síncrona limitada pela tolerância de latência da sua plataforma de storage — não por até onde a fibra chega

Faixa de porte	Local típico	O que o projeto inclui
Cluster de storage único	Uma sala · um único cluster totalmente flash servindo um ambiente de computação	Um par de leaf de storage dedicado com RoCEv2, PFC e ECN ajustados ao cluster, acesso NVMe-oF de cada host, gestão fora de banda e telemetria por fila desde o primeiro dia — dimensionado para provar zero perda de pacotes antes de se estender a um segundo site.
Dois data centers ativo-ativo	Dois sites dentro da distância de replicação síncrona · negócio sensível a paradas	Uma malha de storage por site, uma interconexão dedicada de baixa latência carregando a replicação síncrona, papéis ativo-ativo validados conforme a tolerância de latência real da sua plataforma de storage, e um teste de failover ensaiado antes de entrar em produção.
Recuperação de desastres multicêntrica	Sites além da distância síncrona · negócio regulado ou de nível de arquivamento	Uma malha de storage por site mais um link de replicação assíncrona dimensionado honestamente conforme a distância envolvida, papéis primário-reserva com um manual de comutação escrito e ensaiado, e metas de recuperação acordadas no papel antes de encomendar qualquer hardware.

Papéis de equipamento (categorias, não modelos)

A solução é construída com estas categorias de equipamentos — a marca é escolhida com você na fase de projeto. Os modelos exatos dependem do seu número de hosts, número de arrays e distância de replicação — nós os definimos após receber sua lista de requisitos.

Papel	Função
Switch leaf de storage	Conecta hosts NVMe-oF e arrays totalmente flash com RoCEv2 ajustado por porta; dimensionado pelo número de hosts e padrão de leitura/escrita, não por uma contagem de portas genérica.
Switch spine de storage	A camada de alta velocidade dedicada onde cada leaf de storage se conecta — mantida não bloqueante para que o congestionamento Incast tenha para onde ir além de um quadro descartado.
Roteador de borda / link DCI	Carrega o link de replicação síncrona ou assíncrona para um segundo site — dimensionado conforme a distância real e a tolerância de latência da sua plataforma de storage.
Plataforma de ajuste PFC/ECN e telemetria	Onde o controle de congestionamento é configurado e validado por cluster, e onde os contadores de descarte e pausa por fila são observados — isso é tempo de engenharia, não uma caixa de seleção em um assistente.
Switch de gestão fora de banda	Um pequeno switch separado cabeado à porta de gestão de cada equipamento — sua porta de entrada quando é a própria malha de storage que precisa ser diagnosticada.
Plataforma de gestão	Topologia de toda a malha, histórico de profundidade de fila e backup de configuração — para que uma mudança de ajuste fique documentada, não apenas no conhecimento de uma pessoa.

Envie sua lista de requisitos — número de hosts, número de arrays, padrão de leitura/escrita, distância de replicação — e a lista de modelos vem em seguida. Essa ordem mantém o projeto honesto.

Notas de projeto e limites honestos

Leia isto antes de decidir:

Uma rede RoCE sem perdas não perdoa erros de configuração. Limiares de PFC e ECN mal ajustados podem ser piores do que nenhuma configuração sem perdas — uma malha mal ajustada transforma uma perda comum em uma travada que se espalha para todos os hosts que compartilham a fila. Ajustamos cada switch manualmente na entrega, não a partir de um modelo copiado do cluster de outra pessoa.
O valor de uma rede de storage é a zero perda de pacotes — então o teste de aceitação precisa medir a perda de pacotes e a latência reais sob seu padrão de tráfego real, não parar em ler uma ficha técnica. Fazemos esse teste com você antes da aceitação, não depois de uma reclamação.
Esta página é para a equipe de storage e recuperação de desastres, não para a equipe do cluster GPU. Se sua carga de trabalho é treinamento de IA e o tráfego é comunicação coletiva entre aceleradores, nossa solução de Rede de Data Center de Computação IA é dimensionada especificamente para esse padrão de tráfego — as malhas parecem semelhantes no papel e são ajustadas de forma muito diferente na prática.
O verdadeiro ativo-ativo entre dois sites é caro — dobra o hardware de storage e impõe requisitos rígidos de latência e consistência que os próprios arrays exigem. A maioria dos clientes é melhor servida por primário-reserva com failover rápido e ensaiado; faremos essa comparação honestamente antes de você gastar na opção mais cara.
A rede entrega zero perda de pacotes para a camada de storage — ela não garante a consistência de dados em nível de aplicação, a integridade de backup ou os objetivos de ponto de recuperação. Esses compromissos pertencem à sua plataforma de storage e software de backup; projetamos o caminho de rede e dizemos claramente quais promessas estão uma camada acima.

Perguntas frequentes

Em que isso difere da sua solução de Rede de Data Center de Computação IA?

Comprador diferente, tráfego diferente. A página de computação IA é para a equipe que roda treinamento de GPU — a malha que move o tráfego de comunicação coletiva entre aceleradores. Esta página é para a equipe que roda storage e recuperação de desastres — a malha que move leituras, escritas e replicação entre servidores e arrays totalmente flash. Ambas precisam de uma malha Ethernet sem perdas com RoCEv2, PFC e ECN, mas geralmente são redes diferentes servindo clusters diferentes, dimensionadas e ajustadas para padrões de tráfego diferentes. Se o seu problema são GPUs esperando pela rede, aquela página é a sua; se é latência de storage, travadas por Incast ou replicação entre arrays, esta página é a sua.

O que é NVMe over Fabric e por que precisa de uma rede sem perdas?

NVMe over Fabric (NoF) permite que um servidor converse com um array totalmente flash pela rede com latência próxima à de uma unidade conectada localmente — mas somente se a rede nunca descartar um pacote pelo caminho. O Ethernet comum lida com congestionamento descartando quadros, dos quais um host NVMe se recupera retransmitindo — e uma retransmissão na velocidade do flash é uma travada que a aplicação percebe. Uma malha sem perdas aplica contrapressão e marcação de congestionamento em vez de descartar, para que a velocidade do array realmente chegue à aplicação.

Precisamos de storage ativo-ativo, ou primário-reserva é suficiente?

Para a maioria dos clientes, primário-reserva com failover rápido e ensaiado é a melhor opção. O verdadeiro ativo-ativo entre dois sites é caro — dobra o hardware de storage e impõe requisitos rígidos de latência e consistência entre os arrays — e só compensa quando o custo de uma breve interrupção de storage realmente supera esse preço. Faremos essa comparação com você honestamente antes de você se comprometer com qualquer uma das opções.

Vocês podem validar que nossa rede atual é o gargalo antes de reconstruirmos qualquer coisa?

Sim, e preferiríamos fazer isso primeiro. Os contadores de perda de pacotes, contagens de pausa PFC, marcações ECN e latência por fila na sua malha existente dirão honestamente se o desempenho do storage está sendo perdido para a rede ou para outra coisa — um controlador ocupado, um array subdimensionado ou um padrão de acesso de aplicação muitas vezes parecem idênticos ao congestionamento de rede em um painel. Se a rede se mostrar inocente, esse é um resultado útil e mais barato do que uma reconstrução que não resolve nada.

Isso funciona a longa distância para DR multicêntrica?

Funciona, dentro de limites que a própria distância impõe — não o projeto de rede. A replicação síncrona para um verdadeiro ativo-ativo precisa de latência baixa o suficiente para que o tempo de ida e volta permaneça dentro da tolerância da sua plataforma de storage, o que na prática limita a distância utilizável à escala metropolitana. Além dessa distância, a replicação assíncrona para um site reserva é a resposta honesta, e diremos em qual regime seus sites realmente estão antes de você se comprometer com uma topologia.

Envie seu número de hosts e seu requisito de replicação

Um engenheiro responde com um projeto de malha de storage e a lista de categorias de equipamentos. Envie sua lista de requisitos — a lista de modelos vem em seguida.

WhatsApp com um engenheiro →

Soluções relacionadas

Rede de data center de computação IAA versão de treinamento de GPU de uma malha sem perdas: tráfego de comunicação coletiva entre aceleradores em vez de leituras e escritas entre hosts e arrays. Rede de produção IT/OT automotivaDe onde vem boa parte dos dados que esta malha de storage guarda: dados de rastreabilidade e qualidade de uma linha de veículos de quatro processos, lidos pelo MES sob uma fronteira controlada. Rede de data center OTT / nuvemO lado de computação de propósito geral ao lado desta malha de storage: capacidade de hospedagem e nuvem multilocatária para tudo que não é específico de storage.

Usamos cookies apenas para análises anônimas — sem anúncios, sem rastreamento entre sites.Política de privacidade