Home / Solutions / Industrial Networking & Datacom / Lossless Storage Network

Lossless Storage Network: The Flash Array Is Not the Bottleneck, the Network Is

An all-flash array promises microsecond latency and delivers it — until an ordinary Ethernet fabric drops one packet under Incast congestion and turns that promise into an application-visible stall. We engineer storage networks from your requirements, with equipment brand chosen openly at design stage: a dedicated RoCEv2 fabric with PFC and ECN tuned to your actual traffic, NVMe over Fabric (NoF) access, and active-active storage between sites when the numbers actually justify it. Sized honestly for a single storage cluster, two active-active data centers, or multi-center disaster recovery.

Why Storage Performance Dies in the Network, Not the Array

Four patterns behind almost every "our flash array feels slow" call we get:

All-flash performance strangled by ordinary EthernetThe array can answer in microseconds; a network built for office traffic drops a frame under load and the application sees a multi-millisecond stall instead — a thousand-fold gap the spec sheet never mentions.

Incast turns "many reads" into a pile-upDozens of servers reading the same LUN at once send their responses back at the same instant — ordinary switch buffers cannot absorb it, and the drops land exactly on the traffic pattern storage uses most.

Active-active and DR demand zero loss, not "mostly fine"Synchronous replication between two arrays has no tolerance for retransmits — a dropped packet does not just slow replication, it risks the consistency guarantee the whole active-active design was bought for.

Multi-site storage stretches the same requirement across distanceA replication link that is lossless in the rack still has to stay lossless across a metro or long-haul path — and distance itself sets limits no amount of switch tuning can remove.

Architecture: Dedicated RoCEv2 Fabric + PFC/ECN Tuning + NVMe-oF Access

A storage path engineered for zero packet loss, not shared with — or hoping not to collide with — everything else on the network:

Architecture drawn by AtlasCommTech following carrier-grade data center design practice. Diagram labels are kept in English for engineering clarity.

Why us: our founder spent 13 years inside the Huawei partner ecosystem delivering carrier networks — where a dropped packet was a reportable incident. On a storage fabric we treat every dropped frame the same way, because that is exactly what separates a lossless network on paper from one that actually is.

Equipment Options

The solution is sized to your requirements and budget first — the same architecture can be delivered on several vendors' product lines. We help you choose by supply availability in your destination country, budget and your team's operating habits.

Huawei — enterprise campus, WAN and security linesMature ecosystem with a global service network.

ZTE Wantong — comparable datacom linesPrice-performance direction; supply runs smoother in some markets.

H3C — campus and data-center linesWidely deployed campus and data-center portfolio.

Zhongxin Shutong industrial switches — industrial-scenario access layerOur own industrial line — used for hardened branch and edge access points that feed into this storage fabric; compatible with any brand's storage core.

What the Design Delivers

Six properties a properly tuned storage fabric has that a shared, generic data-center network never will:

Zero packet loss under IncastPFC and ECN are tuned against your actual many-to-one traffic pattern, not a template — back-pressure and congestion marking replace drops before they ever happen.

NVMe-oF access at near-local latencyServers reach all-flash arrays over the network close to the latency of a directly attached drive — the point of the design, delivered rather than promised on a datasheet.

A storage path dedicated, not sharedStorage traffic gets its own fabric or its own tuned lanes — so a backup job or a bulk copy never becomes the reason a transaction stalls.

Active-active storage when the numbers justify itSynchronous replication between two sites, sized honestly against the latency and hardware cost it actually carries — not sold by default.

Telemetry that catches drops before the application doesPer-queue depth, PFC pause counts and ECN marks are exported from day one, so a developing congestion problem shows up on a dashboard before it shows up as a support ticket.

A DR replication link sized honestlyDistance sets the limit on synchronous replication, not switch configuration — we tell you which regime your sites are actually in before you commit to a topology.

Three Sizes, One Design Logic

Tell us your array count, host count and replication requirement — the tier tells you the shape of the fabric:

Numbers we design around:

Zero tolerated packet loss on the storage path — PFC and ECN thresholds are tuned to your cluster, not copied from a template

Storage leaf-to-spine kept non-blocking or close to it — the fabric is sized against your read/write pattern, not a generic oversubscription ratio

Synchronous replication distance capped by your storage platform's latency tolerance — not by how far the fiber happens to run

Scale tier	Typical site	What the design includes
Single storage cluster	One room · one all-flash cluster serving a compute environment	A dedicated storage leaf pair with RoCEv2, PFC and ECN tuned to the cluster, NVMe-oF access from every host, out-of-band management and per-queue telemetry from day one — sized to prove zero packet loss before it spans a second site.
Dual active-active data centers	Two sites within synchronous-replication distance · downtime-sensitive business	A storage fabric per site, a dedicated low-latency interconnect carrying synchronous replication, active-active roles validated against your storage platform's actual latency tolerance, and a rehearsed failover test before go-live.
Multi-center disaster recovery	Sites beyond synchronous distance · regulated or archival-tier business	Per-site storage fabric plus an asynchronous replication link honestly sized to the distance involved, primary-standby roles with a written and rehearsed switchover runbook, and recovery targets agreed on paper before any hardware is ordered.

Equipment Roles (Categories, Not Models)

The solution is built from these equipment categories — the brand is chosen with you at design stage. Exact models depend on your host count, array count and replication distance — so we spec models after your requirements list, not before.

Role	What it does
Storage leaf switch	Connects NVMe-oF hosts and all-flash arrays with RoCEv2 tuned per port; sized by host count and read/write pattern rather than a generic port count.
Storage spine switch	The dedicated high-speed layer every storage leaf plugs into — kept non-blocking so Incast congestion has somewhere to go besides a dropped frame.
Border router / DCI link	Carries the synchronous or asynchronous replication link to a second site — sized against the actual distance and your storage platform's latency tolerance.
PFC / ECN tuning and telemetry platform	Where congestion control is configured and validated per cluster, and where per-queue drop and pause counters are watched — this is engineering time, not a checkbox in a wizard.
Out-of-band management switch	A small separate switch wired to every device's management port — your way in when the storage fabric itself is what needs diagnosing.
Management platform	Fabric-wide topology, queue-depth history and configuration backup — so a tuning change is documented, not tribal knowledge.

Send us your requirements list — host count, array count, read/write pattern, replication distance — and the model list follows. That order keeps the design honest.

Design Notes & Honest Limits

Read this before you commit:

A RoCE lossless network is unforgiving of configuration. Badly tuned PFC and ECN thresholds can be worse than no lossless configuration at all — a mistuned fabric turns an ordinary drop into a stall that spreads to every host sharing the queue. We tune every switch by hand at handover, not from a template copied off someone else's cluster.
The value of a storage network is zero packet loss — so acceptance testing has to measure actual packet loss and latency under your real traffic pattern, not stop at reading a spec sheet. We run that test with you before sign-off, not after a complaint.
This page is for the storage and disaster-recovery team, not the GPU cluster team. If your workload is AI training and the traffic is collective communication between accelerators, our AI Computing Datacenter Network solution is sized for that traffic pattern specifically — the fabrics look similar on paper and are tuned very differently in practice.
True active-active across two sites is expensive — it doubles storage hardware and imposes strict latency and consistency requirements the arrays themselves enforce. Most customers are better served by primary-standby with fast, rehearsed failover; we will run that comparison honestly before you spend on the more expensive option.
The network delivers zero packet loss to the storage layer — it does not guarantee application-level data consistency, backup integrity or recovery point objectives. Those commitments belong to your storage platform and backup software; we design the network path and say plainly which promises live one layer up.

FAQ

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.

Send us your host count and replication requirement

An engineer replies with a storage fabric design and the equipment-category list. Send us your requirements list — the model list follows.

WhatsApp an engineer →