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.

Accueil / Solutions / Réseaux industriels & datacom / Réseau de stockage sans perte

Réseau de stockage sans perte : le goulet n'est pas la baie flash, c'est le réseau

Une baie tout-flash promet une latence en microsecondes et la tient — jusqu'à ce qu'une fabrique Ethernet ordinaire perde un paquet sous congestion Incast et transforme cette promesse en un blocage visible par l'application. Nous concevons les réseaux de stockage à partir de vos besoins, la marque des équipements restant un choix ouvert en phase de conception : une fabrique RoCEv2 dédiée avec PFC et ECN réglés sur votre trafic réel, un accès NVMe over Fabric (NoF), et un stockage actif-actif entre sites lorsque les chiffres le justifient vraiment. Dimensionné honnêtement pour un seul cluster de stockage, deux data centers actifs-actifs, ou une reprise après sinistre multi-centres.

Pourquoi la performance du stockage meurt dans le réseau, pas dans la baie

Quatre schémas derrière presque chaque appel « notre baie flash semble lente » que nous recevons :

Une performance tout-flash étranglée par de l'Ethernet ordinaireLa baie peut répondre en microsecondes ; un réseau conçu pour le trafic bureautique perd une trame sous charge et l'application voit à la place un blocage de plusieurs millisecondes — un écart d'un facteur mille que la fiche technique ne mentionne jamais.

Incast transforme « beaucoup de lectures » en embouteillageDes dizaines de serveurs lisant le même LUN en même temps renvoient leurs réponses au même instant — les tampons de commutateur ordinaires ne peuvent pas l'absorber, et les pertes tombent exactement sur le motif de trafic que le stockage utilise le plus.

L'actif-actif et la reprise exigent zéro perte, pas « globalement correct »La réplication synchrone entre deux baies ne tolère aucune retransmission — un paquet perdu ne fait pas que ralentir la réplication, il met en péril la garantie de cohérence pour laquelle toute la conception actif-actif a été achetée.

Le stockage multi-site étire la même exigence sur la distanceUn lien de réplication sans perte dans la baie doit rester sans perte sur un trajet métropolitain ou longue distance — et la distance elle-même impose des limites qu'aucun réglage de commutateur ne peut lever.

Architecture : fabrique RoCEv2 dédiée + réglage PFC/ECN + accès NVMe-oF

Un chemin de stockage conçu pour zéro perte de paquets, non partagé avec — ni espérant ne pas croiser — tout le reste du réseau :

Schéma dessiné par AtlasCommTech selon la pratique de conception data center de niveau opérateur. Les libellés restent en anglais pour la clarté technique.

Pourquoi nous : notre fondateur a passé 13 ans dans l'écosystème des partenaires Huawei à livrer des réseaux opérateurs — où un paquet perdu était un incident à déclarer. Sur une fabrique de stockage, nous traitons chaque trame perdue de la même façon, car c'est exactement ce qui distingue un réseau sans perte sur le papier d'un réseau qui l'est réellement.

Options d'équipement

La solution est d'abord dimensionnée selon vos besoins et votre budget — la même architecture peut être livrée sur les gammes de plusieurs fabricants. Nous vous aidons à choisir selon la disponibilité dans votre pays de destination, le budget et les habitudes d'exploitation de votre équipe.

Huawei — gammes campus d'entreprise, WAN et sécuritéÉcosystème mature avec un réseau de services mondial.

ZTE Wantone — gammes datacom comparablesOrientation rapport qualité-prix ; approvisionnement plus fluide sur certains marchés.

H3C — gammes campus et data centerPortefeuille campus et data center largement déployé.

Commutateurs industriels Atlas — couche d'accès en environnement industrielNotre propre gamme industrielle — utilisée pour des points d'accès de succursale et de périphérie renforcés qui alimentent cette fabrique de stockage ; compatible avec le cœur de stockage de toute marque.

Ce que la conception apporte

Six propriétés d'une fabrique de stockage bien réglée qu'un réseau de data center générique et partagé n'aura jamais :

Zéro perte de paquets sous IncastPFC et ECN sont réglés sur votre motif de trafic réel plusieurs-vers-un, pas sur un modèle — la contre-pression et le marquage de congestion remplacent les pertes avant même qu'elles ne se produisent.

Accès NVMe-oF à une latence quasi localeLes serveurs atteignent les baies tout-flash via le réseau à une latence proche de celle d'un disque directement raccordé — l'objectif de la conception, livré plutôt que promis sur une fiche technique.

Un chemin de stockage dédié, pas partagéLe trafic de stockage dispose de sa propre fabrique ou de ses propres voies réglées — une sauvegarde ou une copie en masse ne devient jamais la raison pour laquelle une transaction se bloque.

Un stockage actif-actif quand les chiffres le justifientRéplication synchrone entre deux sites, dimensionnée honnêtement selon la latence et le coût matériel qu'elle implique réellement — pas vendue par défaut.

Une télémétrie qui détecte les pertes avant l'applicationLa profondeur par file, les compteurs de pause PFC et les marques ECN sont exportés dès le premier jour, pour qu'un problème de congestion naissant apparaisse sur un tableau de bord avant de devenir un ticket de support.

Un lien de réplication de reprise dimensionné honnêtementC'est la distance qui fixe la limite de la réplication synchrone, pas la configuration du commutateur — nous vous disons dans quel régime se trouvent réellement vos sites avant tout engagement sur une topologie.

Trois tailles, une même logique

Donnez le nombre de baies, le nombre d'hôtes et l'exigence de réplication — le palier donne la forme de la fabrique :

Les chiffres qui guident la conception :

Zéro perte de paquets tolérée sur le chemin de stockage — les seuils PFC et ECN sont réglés sur votre cluster, pas copiés d'un modèle

Liaison leaf-spine de stockage maintenue non bloquante ou proche de l'être — la fabrique est dimensionnée sur votre motif de lecture/écriture, pas un ratio de sursouscription générique

Distance de réplication synchrone plafonnée par la tolérance de latence de votre plateforme de stockage — pas par la longueur de fibre disponible

Palier	Site type	Contenu de la conception
Cluster de stockage unique	Une salle · un cluster tout-flash unique desservant un environnement de calcul	Une paire de leaf de stockage dédiée avec RoCEv2, PFC et ECN réglés sur le cluster, un accès NVMe-oF depuis chaque hôte, une gestion hors bande et une télémétrie par file dès le premier jour — dimensionné pour prouver zéro perte de paquets avant de s'étendre à un second site.
Deux data centers actifs-actifs	Deux sites dans la distance de réplication synchrone · activité sensible aux coupures	Une fabrique de stockage par site, une interconnexion dédiée à faible latence portant la réplication synchrone, des rôles actif-actif validés selon la tolérance de latence réelle de votre plateforme de stockage, et un test de bascule répété avant la mise en service.
Reprise après sinistre multi-centres	Sites au-delà de la distance synchrone · activité réglementée ou de niveau archivage	Une fabrique de stockage par site plus un lien de réplication asynchrone dimensionné honnêtement selon la distance concernée, des rôles primaire-secours avec un manuel de bascule écrit et répété, et des objectifs de reprise actés sur papier avant toute commande de matériel.

Rôles d'équipement (catégories, pas de modèles)

La solution s'appuie sur ces catégories d'équipements — la marque est choisie avec vous en phase de conception. Les modèles exacts dépendent du nombre d'hôtes, du nombre de baies et de la distance de réplication — nous les spécifions après réception de votre liste de besoins.

Rôle	Fonction
Commutateur leaf de stockage	Connecte les hôtes NVMe-oF et les baies tout-flash avec RoCEv2 réglé par port ; dimensionné selon le nombre d'hôtes et le motif de lecture/écriture plutôt qu'un nombre de ports générique.
Commutateur spine de stockage	La couche haut débit dédiée où chaque leaf de stockage se branche — maintenue non bloquante pour que la congestion Incast ait une issue autre que la perte de trame.
Routeur de bordure / lien DCI	Porte le lien de réplication synchrone ou asynchrone vers un second site — dimensionné selon la distance réelle et la tolérance de latence de votre plateforme de stockage.
Plateforme de réglage PFC/ECN et de télémétrie	Là où le contrôle de congestion est configuré et validé par cluster, et où les compteurs de perte et de pause par file sont surveillés — c'est du temps d'ingénierie, pas une case à cocher dans un assistant.
Commutateur de gestion hors bande	Un petit commutateur séparé câblé au port de gestion de chaque équipement — votre porte d'entrée quand c'est la fabrique de stockage elle-même qu'il faut diagnostiquer.
Plateforme de gestion	Topologie de toute la fabrique, historique de profondeur de file et sauvegarde de configuration — pour qu'un réglage soit documenté, pas une connaissance tribale.

Envoyez votre liste de besoins — nombre d'hôtes, nombre de baies, motif de lecture/écriture, distance de réplication — et la liste des modèles suit. Cet ordre garde la conception honnête.

Notes de conception et limites honnêtes

À lire avant de vous engager :

Un réseau RoCE sans perte ne pardonne pas les erreurs de configuration. Des seuils PFC et ECN mal réglés peuvent être pires que l'absence de configuration sans perte — une fabrique mal réglée transforme une perte ordinaire en un blocage qui se propage à tous les hôtes partageant la file. Nous réglons chaque commutateur à la main à la livraison, pas à partir d'un modèle copié sur le cluster de quelqu'un d'autre.
La valeur d'un réseau de stockage réside dans le zéro perte de paquets — le test de recette doit donc mesurer la perte de paquets et la latence réelles sous votre motif de trafic réel, pas s'arrêter à la lecture d'une fiche technique. Nous menons ce test avec vous avant la réception, pas après une réclamation.
Cette page s'adresse à l'équipe stockage et reprise après sinistre, pas à l'équipe cluster GPU. Si votre charge de travail est l'entraînement IA et que le trafic est de la communication collective entre accélérateurs, notre solution AI Computing Datacenter Network est dimensionnée spécifiquement pour ce motif de trafic — les fabriques se ressemblent sur le papier et sont réglées très différemment en pratique.
Le vrai actif-actif entre deux sites coûte cher — il double le matériel de stockage et impose des exigences strictes de latence et de cohérence que les baies elles-mêmes appliquent. La plupart des clients sont mieux servis par un primaire-secours avec bascule rapide et répétée ; nous ferons ce comparatif honnêtement avant que vous ne dépensiez pour l'option la plus coûteuse.
Le réseau délivre zéro perte de paquets à la couche stockage — il ne garantit pas la cohérence des données au niveau applicatif, l'intégrité des sauvegardes ni les objectifs de point de reprise. Ces engagements relèvent de votre plateforme de stockage et de votre logiciel de sauvegarde ; nous concevons le chemin réseau et disons clairement quelles promesses se situent une couche plus haut.

FAQ

En quoi cela diffère-t-il de votre solution AI Computing Datacenter Network ?

Acheteur différent, trafic différent. La page IA computing s'adresse à l'équipe qui gère l'entraînement GPU — la fabrique qui achemine le trafic de communication collective entre accélérateurs. Cette page s'adresse à l'équipe qui gère le stockage et la reprise après sinistre — la fabrique qui achemine les lectures, écritures et réplications entre serveurs et baies tout-flash. Les deux ont besoin d'une fabrique Ethernet sans perte avec RoCEv2, PFC et ECN, mais ce sont généralement des réseaux différents desservant des clusters différents, dimensionnés et réglés sur des motifs de trafic différents. Si votre problème, ce sont des GPU qui attendent le réseau, cette page-là est la vôtre ; si c'est la latence de stockage, des blocages Incast ou la réplication entre baies, celle-ci l'est.

Qu'est-ce que NVMe over Fabric et pourquoi a-t-il besoin d'un réseau sans perte ?

NVMe over Fabric (NoF) permet à un serveur de dialoguer avec une baie tout-flash via le réseau à une latence proche de celle d'un disque directement raccordé — mais seulement si le réseau ne perd jamais un paquet en chemin. L'Ethernet ordinaire gère la congestion en rejetant des trames, dont un hôte NVMe se remet en retransmettant — et une retransmission à la vitesse du flash est un blocage visible par l'application. Une fabrique sans perte applique la contre-pression et le marquage de congestion au lieu de rejeter, pour que la vitesse de la baie atteigne réellement l'application.

Avons-nous besoin d'un stockage actif-actif, ou le primaire-secours suffit-il ?

Pour la plupart des clients, un primaire-secours avec bascule rapide et répétée est le meilleur compromis. Le vrai actif-actif entre deux sites coûte cher — il double le matériel de stockage et impose des exigences strictes de latence et de cohérence entre les baies — et ne se justifie que lorsque le coût d'une courte coupure de stockage dépasse réellement ce prix. Nous ferons ce comparatif honnêtement avec vous avant tout engagement sur l'une ou l'autre option.

Pouvez-vous valider que notre réseau actuel est le goulet avant de reconstruire quoi que ce soit ?

Oui, et nous préférerions faire cela d'abord. Les compteurs de perte de paquets, de pause PFC, les marques ECN et la latence par file sur votre fabrique existante vous diront honnêtement si la performance de stockage est perdue à cause du réseau ou d'autre chose — un contrôleur occupé, une baie sous-dimensionnée ou un motif d'accès applicatif ressemblent souvent à une congestion réseau sur un tableau de bord. Si le réseau se révèle innocent, c'est un résultat utile et moins cher qu'une reconstruction qui ne résout rien.

Cela fonctionne-t-il sur longue distance pour une reprise multi-centres ?

Cela fonctionne, dans les limites que la distance elle-même impose — pas la conception réseau. La réplication synchrone pour un véritable actif-actif nécessite une latence assez faible pour que le temps d'aller-retour reste dans la tolérance de votre plateforme de stockage, ce qui plafonne en pratique la distance utilisable à l'échelle métropolitaine. Au-delà, la réplication asynchrone vers un site de secours est la réponse honnête, et nous vous dirons dans quel régime se trouvent réellement vos sites avant tout engagement sur une topologie.

Envoyez le nombre d'hôtes et l'exigence de réplication

Un ingénieur répond avec une conception de fabrique de stockage et la liste des catégories d'équipements. Envoyez votre liste de besoins — la liste des modèles suit.

Contacter un ingénieur sur WhatsApp →

Solutions associées

Réseau de datacenter de calcul IALa version entraînement GPU d'une fabrique sans perte : trafic de communication collective entre accélérateurs plutôt que lectures et écritures entre hôtes et baies. Réseau de production IT/OT automobileD'où viennent une bonne partie des données que porte cette fabrique de stockage : données de traçabilité et de qualité d'une ligne véhicule à quatre procédés, lues par le MES sous une frontière contrôlée. Réseau de datacenter OTT / CloudLe côté calcul généraliste juxtaposé à cette fabrique de stockage : capacité cloud et hébergement multi-tenant pour tout ce qui n'est pas spécifique au stockage.

Nous n'utilisons des cookies que pour des statistiques anonymes — pas de publicité, pas de suivi intersites.Politique de confidentialité