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.

Inicio / Soluciones / Redes industriales y datacom / Red de almacenamiento sin pérdidas

Red de almacenamiento sin pérdidas: el cuello de botella no es la cabina flash, es la red

Una cabina todo-flash promete latencia en microsegundos y la cumple — hasta que una fábrica Ethernet ordinaria pierde un paquete bajo congestión Incast y convierte esa promesa en una pausa visible para la aplicación. Diseñamos redes de almacenamiento a partir de sus requisitos, con la marca de los equipos como elección abierta en la fase de diseño: una fábrica RoCEv2 dedicada con PFC y ECN ajustados a su tráfico real, acceso NVMe over Fabric (NoF), y almacenamiento activo-activo entre sitios cuando los números realmente lo justifican. Dimensionado honestamente para un solo clúster de almacenamiento, dos centros de datos activo-activo, o recuperación ante desastres multicentro.

Por qué el rendimiento del almacenamiento muere en la red, no en la cabina

Cuatro patrones detrás de casi toda llamada de "nuestra cabina flash se siente lenta" que recibimos:

Rendimiento todo-flash estrangulado por Ethernet ordinarioLa cabina puede responder en microsegundos; una red construida para tráfico de oficina pierde una trama bajo carga y la aplicación ve en su lugar una pausa de varios milisegundos — una brecha de mil veces que la ficha técnica nunca menciona.

Incast convierte "muchas lecturas" en un atascoDocenas de servidores leyendo el mismo LUN a la vez envían sus respuestas en el mismo instante — los búferes de switch ordinarios no pueden absorberlo, y las pérdidas caen exactamente sobre el patrón de tráfico que más usa el almacenamiento.

Activo-activo y DR exigen cero pérdida, no "más o menos bien"La replicación síncrona entre dos cabinas no tolera retransmisiones — un paquete perdido no solo ralentiza la replicación, pone en riesgo la garantía de consistencia por la que se compró todo el diseño activo-activo.

El almacenamiento multisitio estira el mismo requisito a través de la distanciaUn enlace de replicación sin pérdidas en el rack todavía tiene que seguir siendo sin pérdidas en un trayecto metropolitano o de larga distancia — y la distancia misma impone límites que ningún ajuste de switch puede eliminar.

Arquitectura: fábrica RoCEv2 dedicada + ajuste PFC/ECN + acceso NVMe-oF

Una ruta de almacenamiento diseñada para cero pérdida de paquetes, no compartida con — ni esperando no chocar con — todo lo demás en la red:

Diagrama dibujado por AtlasCommTech siguiendo la práctica de diseño de centro de datos de nivel operador. Las etiquetas se mantienen en inglés por claridad técnica.

Por qué nosotros: nuestro fundador pasó 13 años dentro del ecosistema de socios de Huawei entregando redes de operador — donde un paquete perdido era un incidente reportable. En una fábrica de almacenamiento tratamos cada trama perdida de la misma manera, porque eso es exactamente lo que separa una red sin pérdidas sobre el papel de una que realmente lo es.

Opciones de equipamiento

La solución se dimensiona primero según sus requisitos y presupuesto — la misma arquitectura puede entregarse con las líneas de producto de varios fabricantes. Le ayudamos a elegir según la disponibilidad de suministro en su país de destino, el presupuesto y los hábitos de operación de su equipo.

Huawei — líneas de campus empresarial, WAN y seguridadEcosistema maduro con una red de servicio global.

ZTE Wantone — líneas datacom comparablesOrientación precio-rendimiento; suministro más fluido en algunos mercados.

H3C — líneas de campus y centro de datosPortafolio de campus y centro de datos ampliamente desplegado.

Switches industriales Atlas — capa de acceso en escenarios industrialesNuestra propia línea industrial — utilizada para puntos de acceso de sucursal y borde reforzados que alimentan esta fábrica de almacenamiento; compatible con el núcleo de almacenamiento de cualquier marca.

Qué entrega el diseño

Seis propiedades de una fábrica de almacenamiento bien ajustada que una red de centro de datos genérica y compartida nunca tendrá:

Cero pérdida de paquetes bajo IncastPFC y ECN se ajustan según su patrón real de tráfico de muchos a uno, no una plantilla — la contrapresión y el marcado de congestión reemplazan las pérdidas antes de que ocurran.

Acceso NVMe-oF con latencia casi localLos servidores acceden a las cabinas todo-flash a través de la red con una latencia cercana a la de una unidad conectada directamente — el objetivo del diseño, entregado en lugar de prometido en una ficha técnica.

Una ruta de almacenamiento dedicada, no compartidaEl tráfico de almacenamiento tiene su propia fábrica o sus propios carriles ajustados — un trabajo de respaldo o una copia masiva nunca es la razón por la que una transacción se detiene.

Almacenamiento activo-activo cuando los números lo justificanReplicación síncrona entre dos sitios, dimensionada honestamente según la latencia y el costo de hardware que realmente conlleva — no vendida por defecto.

Telemetría que detecta las pérdidas antes que la aplicaciónLa profundidad por cola, los conteos de pausa PFC y las marcas ECN se exportan desde el primer día, para que un problema de congestión en desarrollo aparezca en un panel antes de convertirse en un ticket de soporte.

Un enlace de replicación de DR dimensionado honestamenteLa distancia fija el límite de la replicación síncrona, no la configuración del switch — le decimos en qué régimen están realmente sus sitios antes de comprometerse con una topología.

Tres tamaños, una misma lógica

Díganos su número de cabinas, número de hosts y requisito de replicación — el nivel define la forma de la fábrica:

Los números que guían el diseño:

Cero pérdida de paquetes tolerada en la ruta de almacenamiento — los umbrales PFC y ECN se ajustan a su clúster, no se copian de una plantilla

Enlace leaf-spine de almacenamiento mantenido no bloqueante o cerca de serlo — la fábrica se dimensiona según su patrón de lectura/escritura, no una relación de sobresuscripción genérica

Distancia de replicación síncrona limitada por la tolerancia de latencia de su plataforma de almacenamiento — no por lo lejos que llegue la fibra

Nivel de escala	Sitio típico	Qué incluye el diseño
Clúster de almacenamiento único	Una sala · un solo clúster todo-flash que sirve a un entorno de cómputo	Un par de leaf de almacenamiento dedicado con RoCEv2, PFC y ECN ajustados al clúster, acceso NVMe-oF desde cada host, gestión fuera de banda y telemetría por cola desde el primer día — dimensionado para probar cero pérdida de paquetes antes de extenderse a un segundo sitio.
Dos centros de datos activo-activo	Dos sitios dentro de la distancia de replicación síncrona · negocio sensible al tiempo de caída	Una fábrica de almacenamiento por sitio, una interconexión dedicada de baja latencia que lleva la replicación síncrona, roles activo-activo validados según la tolerancia de latencia real de su plataforma de almacenamiento, y una prueba de conmutación ensayada antes de la puesta en marcha.
Recuperación ante desastres multicentro	Sitios más allá de la distancia síncrona · negocio regulado o de nivel archivo	Una fábrica de almacenamiento por sitio más un enlace de replicación asíncrona dimensionado honestamente según la distancia involucrada, roles primario-reserva con un manual de conmutación escrito y ensayado, y objetivos de recuperación acordados sobre papel antes de pedir cualquier hardware.

Roles de equipo (categorías, no modelos)

La solución se construye con estas categorías de equipos — la marca se elige con usted en la fase de diseño. Los modelos exactos dependen de su número de hosts, número de cabinas y distancia de replicación — los definimos después de recibir su lista de requisitos.

Rol	Función
Switch leaf de almacenamiento	Conecta hosts NVMe-oF y cabinas todo-flash con RoCEv2 ajustado por puerto; dimensionado según el número de hosts y el patrón de lectura/escritura en lugar de un número de puertos genérico.
Switch spine de almacenamiento	La capa de alta velocidad dedicada donde se conecta cada leaf de almacenamiento — mantenida no bloqueante para que la congestión Incast tenga adónde ir además de una trama perdida.
Router de borde / enlace DCI	Lleva el enlace de replicación síncrona o asíncrona a un segundo sitio — dimensionado según la distancia real y la tolerancia de latencia de su plataforma de almacenamiento.
Plataforma de ajuste PFC/ECN y telemetría	Donde el control de congestión se configura y valida por clúster, y donde se vigilan los contadores de pérdida y pausa por cola — esto es tiempo de ingeniería, no una casilla en un asistente.
Switch de gestión fuera de banda	Un pequeño switch separado cableado al puerto de gestión de cada equipo — su vía de entrada cuando lo que hay que diagnosticar es la propia fábrica de almacenamiento.
Plataforma de gestión	Topología de toda la fábrica, historial de profundidad de cola y copia de configuración — para que un cambio de ajuste quede documentado, no en el conocimiento de una sola persona.

Envíenos su lista de requisitos — número de hosts, número de cabinas, patrón de lectura/escritura, distancia de replicación — y la lista de modelos llega después. Ese orden mantiene el diseño honesto.

Notas de diseño y límites honestos

Lea esto antes de decidir:

Una red RoCE sin pérdidas no perdona errores de configuración. Umbrales PFC y ECN mal ajustados pueden ser peores que no tener configuración sin pérdidas — una fábrica mal ajustada convierte una pérdida ordinaria en una pausa que se propaga a todos los hosts que comparten la cola. Ajustamos cada switch a mano en la entrega, no a partir de una plantilla copiada del clúster de otra persona.
El valor de una red de almacenamiento es la cero pérdida de paquetes — así que la prueba de aceptación tiene que medir la pérdida de paquetes y la latencia reales bajo su patrón de tráfico real, no detenerse en leer una ficha técnica. Realizamos esa prueba con usted antes de la recepción, no después de una queja.
Esta página es para el equipo de almacenamiento y recuperación ante desastres, no para el equipo del clúster GPU. Si su carga de trabajo es entrenamiento de IA y el tráfico es comunicación colectiva entre aceleradores, nuestra solución de Red de Centro de Datos de Cómputo IA está dimensionada específicamente para ese patrón de tráfico — las fábricas se parecen en el papel y se ajustan de forma muy diferente en la práctica.
El verdadero activo-activo entre dos sitios es caro — duplica el hardware de almacenamiento e impone requisitos estrictos de latencia y consistencia que las propias cabinas exigen. A la mayoría de los clientes les conviene más un primario-reserva con conmutación rápida y ensayada; haremos esa comparación honestamente antes de que gaste en la opción más costosa.
La red entrega cero pérdida de paquetes a la capa de almacenamiento — no garantiza la consistencia de datos a nivel de aplicación, la integridad de las copias de respaldo ni los objetivos de punto de recuperación. Esos compromisos pertenecen a su plataforma de almacenamiento y software de respaldo; diseñamos la ruta de red y decimos claramente qué promesas están una capa por encima.

Preguntas frecuentes

¿En qué se diferencia esto de su solución de Red de Centro de Datos de Cómputo IA?

Comprador diferente, tráfico diferente. La página de cómputo IA es para el equipo que ejecuta el entrenamiento de GPU — la fábrica que mueve el tráfico de comunicación colectiva entre aceleradores. Esta página es para el equipo que ejecuta el almacenamiento y la recuperación ante desastres — la fábrica que mueve lecturas, escrituras y replicación entre servidores y cabinas todo-flash. Ambas necesitan una fábrica Ethernet sin pérdidas con RoCEv2, PFC y ECN, pero suelen ser redes distintas que sirven a clústeres distintos, dimensionadas y ajustadas para patrones de tráfico distintos. Si su problema son las GPU esperando por la red, esa página es la suya; si es la latencia de almacenamiento, los bloqueos por Incast o la replicación entre cabinas, esta página es la suya.

¿Qué es NVMe over Fabric y por qué necesita una red sin pérdidas?

NVMe over Fabric (NoF) permite que un servidor se comunique con una cabina todo-flash a través de la red con una latencia cercana a la de una unidad conectada localmente — pero solo si la red nunca pierde un paquete en el camino. El Ethernet ordinario gestiona la congestión descartando tramas, de lo cual un host NVMe se recupera retransmitiendo — y una retransmisión a velocidad flash es una pausa que la aplicación puede ver. Una fábrica sin pérdidas aplica contrapresión y marcado de congestión en lugar de descartar, para que la velocidad de la cabina realmente llegue a la aplicación.

¿Necesitamos almacenamiento activo-activo, o basta con primario-reserva?

Para la mayoría de los clientes, un primario-reserva con conmutación rápida y ensayada es el mejor compromiso. El verdadero activo-activo entre dos sitios es caro — duplica el hardware de almacenamiento e impone requisitos estrictos de latencia y consistencia entre las cabinas — y solo se justifica cuando el costo de una breve interrupción de almacenamiento realmente supera ese precio. Haremos esa comparación con usted honestamente antes de que se decida por cualquiera de las dos.

¿Pueden validar que nuestra red actual es el cuello de botella antes de reconstruir algo?

Sí, y preferiríamos hacer eso primero. Los contadores de pérdida de paquetes, los conteos de pausa PFC, las marcas ECN y la latencia por cola en su fábrica existente le dirán honestamente si el rendimiento de almacenamiento se está perdiendo por la red o por otra cosa — un controlador ocupado, una cabina insuficiente o un patrón de acceso de aplicación a menudo se ven idénticos a la congestión de red en un panel. Si la red resulta ser inocente, ese es un resultado útil y más barato que una reconstrucción que no resuelve nada.

¿Esto funciona a larga distancia para DR multicentro?

Funciona, dentro de los límites que la propia distancia impone — no el diseño de red. La replicación síncrona para un verdadero activo-activo necesita una latencia lo bastante baja para que el tiempo de ida y vuelta permanezca dentro de la tolerancia de su plataforma de almacenamiento, lo que en la práctica limita la distancia útil a escala metropolitana. Más allá de esa distancia, la replicación asíncrona a un sitio de reserva es la respuesta honesta, y le diremos en qué régimen están realmente sus sitios antes de que se comprometa con una topología.

Envíenos su número de hosts y su requisito de replicación

Un ingeniero responde con un diseño de fábrica de almacenamiento y la lista de categorías de equipos. Envíe su lista de requisitos — la lista de modelos llega después.

WhatsApp con un ingeniero →

Soluciones relacionadas

Red de centro de datos de cómputo IALa versión de entrenamiento de GPU de una fábrica sin pérdidas: tráfico de comunicación colectiva entre aceleradores en lugar de lecturas y escrituras entre hosts y cabinas. Red de producción IT/OT automotrizDe dónde viene gran parte de los datos que contiene esta fábrica de almacenamiento: datos de trazabilidad y calidad de una línea de vehículos de cuatro procesos, leídos por el MES bajo una frontera controlada. Red de centro de datos OTT / nubeEl lado de cómputo de propósito general junto a esta fábrica de almacenamiento: capacidad de hosting y nube multiinquilino para todo lo que no es específico de almacenamiento.

Solo usamos cookies para analítica anónima — sin publicidad ni rastreo entre sitios.Política de privacidad