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 Wantong — 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.
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.