Un vistazo en 30 segundos
- ONTAP 9.19.1 incorpora NFS y SMB a SnapMirror active sync, hasta ahora una tecnología de bloque.
- La protección se hace a nivel de SVM (Storage Virtual Machine), no por grupo de consistencia.
- NetApp declara RPO 0 y conmutación transparente; el RTO real depende del protocolo.
- La SVM secundaria queda dormida: no sirve datos hasta que hay failover, aunque sus volúmenes se pueden clonar a otra SVM.
- Las IP y la configuración de protocolos deben ser idénticas en ambos lados, y hace falta un mediador en un tercer sitio.
- Es una primera versión: solo FlexVol, sin FlexGroup, sin grupos de consistencia, sin SnapLock ni MetroCluster.
Durante años, montar continuidad de negocio con RPO 0 sobre almacenamiento de archivos era el problema feo del diseño. Si la carga hablaba iSCSI o Fibre Channel había camino; si hablaba NFS o SMB, la conversación acababa casi siempre en replicación asíncrona y en asumir una ventana de minutos de datos pendientes de viajar al segundo centro de datos.
Con ONTAP 9.19.1, NetApp ha extendido SnapMirror active sync —lo que antes se llamaba SnapMirror Business Continuity— a cargas NAS. Es un cambio pequeño en el titular y bastante grande en la práctica: la misma tecnología que protegía LUN y namespaces NVMe pasa a proteger volúmenes servidos por NFS y SMB, con conmutación automática entre dos sistemas ONTAP.
Merece la pena mirarlo con calma, porque la novedad viene con condiciones y porque, en el fondo, obliga a repetir una distinción que se sigue confundiendo: replicar datos no es lo mismo que tener los mismos datos en dos sitios en todo momento.
De proteger bloques a proteger también archivos
SnapMirror active sync apareció en ONTAP 9.9.1 para cargas SAN y ha ido creciendo versión a versión. Este es el recorrido, que ayuda a entender dónde encaja la novedad:
| Versión ONTAP | Qué añadió |
|---|
| 9.9.1 | iSCSI y FC sobre clústeres AFF y ASA, configuración activo/activo asimétrica |
| 9.15.1 | Activo/activo simétrico en clústeres de 2 nodos |
| 9.16.1 | ASA r2 y simétrico de 4 a 4 nodos |
| 9.17.1 | NVMe para cargas VMware y ONTAP Cloud Mediator |
| 9.19.1 | NFS y SMB a nivel de SVM, en AFF y AFX |
En esta primera implementación NAS, los protocolos soportados son NFS v3 en adelante y SMB 2.x o posterior —SMB 1 se queda fuera—, sobre clústeres AFF de dos nodos o AFX de cuatro nodos. AFX es la variante desagregada de ONTAP que NetApp presentó en 2025, con la capa de cómputo separada de la de capacidad; que entre en la lista desde el primer día dice bastante de hacia dónde mira el fabricante.
El funcionamiento se parece poco al del SAN, y ahí está lo interesante.
Cómo funciona en NAS: la SVM entera, y una copia dormida
En una relación SAN, la unidad protegida es el grupo de consistencia: un conjunto de volúmenes o unidades de almacenamiento que se fotografían a la vez para mantener el orden de escritura. En NAS no hay nada de eso. La unidad protegida es la SVM completa, y el constituyente es el volumen.
Se crea una SVM destino de tipo dp-destination en el clúster secundario, se establece la relación con la política AutomatedFailOver y se inicializa. A partir de ahí ONTAP replica de forma síncrona los datos y también la configuración de red y protocolos necesaria para que el segundo entorno pueda ponerse en pie.
La parte que sorprende a quien viene del mundo SAN: la SVM secundaria permanece inactiva. No sirve NFS ni SMB mientras el primario funciona, y sus LIF están caídas a propósito. El motivo es aritmética de red pura: para que la conmutación sea transparente, las direcciones IP tienen que ser las mismas a los dos lados, y dos SVM con la misma IP levantadas a la vez se pisarían. El acceso de lectura y escritura es solo del primario.
Eso no significa que el hardware secundario esté ahí mirando. Los volúmenes del secundario se pueden clonar dentro de otra SVM y usar esa copia para desarrollo, pruebas, UAT o informes sin tocar la relación de protección. Es, probablemente, la forma más honesta de justificar la segunda cabina ante quien firma la factura.
Quién decide que hay que conmutar
Igual que en las configuraciones SAN, hace falta un árbitro. ONTAP Mediator —o ONTAP Cloud Mediator, disponible desde 9.17.1 y alojado por NetApp— recibe la salud de ambos clústeres y forma con ellos un quórum de tres partes: para tomar una decisión, al menos dos tienen que estar de acuerdo.
Esto tiene una consecuencia de diseño que conviene decir en voz alta y pronto en el proyecto: el mediador on-premises vive en un tercer emplazamiento, con energía y red independientes de los otros dos. No es un detalle de la instalación, es un requisito de arquitectura. Si el árbitro está enchufado al mismo cuadro eléctrico que uno de los dos sitios, el diseño de alta disponibilidad tiene un agujero conceptual del tamaño de ese cuadro. La variante en cloud existe justo para ahorrarse ese tercer sitio.
Failover: no todos los protocolos se comportan igual
Aquí está el matiz más importante para dimensionar expectativas, y el que más se pierde en los resúmenes del anuncio:
| Protocolo | Comportamiento en la conmutación | RPO |
|---|
| NFS v3 y posteriores | Conmutación no disruptiva | 0 |
| SMB 3 con Continuous Availability (CA) | Conmutación no disruptiva | 0 |
| SMB 2 y SMB 3 sin CA | Sí hay interrupción durante el failover | 0 |
| SMB 1 | No soportado | — |
Dicho de otro modo: el RPO 0 se mantiene en todos los casos soportados, pero la transparencia depende de qué esté hablando el cliente. Si tienes recursos compartidos SMB sin Continuous Availability, la aplicación va a notar el corte aunque no pierdas un solo dato. Vale la pena auditar eso antes de prometer nada a negocio.
La letra pequeña de la primera versión
ONTAP 9.19.1 es el estreno del NAS en esta tecnología y se nota en la lista de lo que todavía no encaja. Es información pública de la documentación, pero rara vez llega al titular:
| Elemento | ¿Soportado en NAS? |
|---|
| Volúmenes FlexVol | Sí |
| Volúmenes FlexGroup | No |
| Grupos de consistencia de aplicación | No |
| Volúmenes SAN dentro de la SVM protegida | No (la inicialización falla si hay LUN) |
| SnapLock | No |
| Configuración MetroCluster | No |
| FlexCache | No |
| SVM migrate | No |
| SnapMirror to cloud | No |
| FabricPool | Parcial (la política de tiering all no se permite) |
| Auditoría | Sí, solo se replican los logs consolidados de la SVM |
| FPolicy y antivirus | Sí |
| Estilo de seguridad NTFS | Sí (en SAN no está soportado) |
Dos avisos operativos más. El primero: no se puede convertir directamente una relación de SVM DR en una relación de SnapMirror active sync para NAS; hay que borrar la relación anterior, crear una SVM destino nueva y establecer e inicializar la relación desde cero. El segundo: si en la SVM que quieres proteger conviven volúmenes con LUN, la inicialización directamente no arranca. Ninguna de las dos cosas es dramática, pero cambian el plan de migración.
Qué significa realmente RPO 0 (y qué no)
Conviene separar los dos conceptos que casi siempre se citan juntos.
El RPO (Recovery Point Objective) responde a cuántos datos puedo permitirme perder. Una copia cada seis horas puede significar, en el peor caso, seis horas de trabajo evaporado. Una réplica asíncrona frecuente reduce mucho esa ventana, pero nunca la cierra: siempre hay un intervalo entre la escritura en origen y su llegada al destino.
La replicación síncrona cambia el planteamiento: la escritura no se da por buena hasta que está protegida en ambos lados. De ahí el objetivo de RPO 0, es decir, ninguna pérdida de datos confirmados dentro de la relación.
El RTO (Recovery Time Objective) responde a otra pregunta distinta: cuánto tarda el servicio en volver. Y aquí toca ser preciso, porque es donde más se estira el lenguaje comercial. NetApp habla de RPO 0 con conmutación transparente para los escenarios soportados; no de un RTO 0 universal para cualquier carga NAS. Con SMB sin CA, ya lo hemos visto, hay corte.
Lo desarrollamos con calculadora en mano en la guía sobre cómo dimensionar RTO y RPO en tu disaster recovery, porque pedir cero a todo por defecto es una de las decisiones más caras que se toman en infraestructura.
Por qué esto importa al diseñar un cloud privado en dos centros de datos
Cuando alguien dibuja una arquitectura de alta disponibilidad repartida entre dos salas, casi siempre empieza por el cómputo: nodos redundantes, clúster de virtualización, quórum, reglas de reinicio automático. Y esa parte suele quedar bien resuelta.
El almacenamiento es donde se cae el plan. Una plataforma sobre Proxmox VE o VMware puede tener todos los nodos que quieras, pero la disponibilidad real de una máquina virtual depende de dónde vivan sus discos. Si el volumen solo existe en una ubicación, perder esa ubicación deja las máquinas inaccesibles aunque sobre cómputo en la otra. Ahí no falla el hipervisor, falla el diseño. Es un tema que ya tocamos al hablar de alta disponibilidad y clúster Proxmox en producción.
Lo que aporta la novedad de NetApp es tirar una frontera que llevaba años en pie. Hasta ahora, la respuesta técnica a «quiero RPO 0» pasaba por llevar la carga a bloque: presentar LUN por iSCSI o FC aunque la aplicación hubiera vivido feliz sobre un recurso compartido. Con NFS y SMB en la ecuación, el requisito de continuidad deja de imponer el protocolo, y eso simplifica bastantes conversaciones: almacenes de ficheros compartidos, repositorios de aplicación, datastores NFS de virtualización, directorios de usuarios.
También cambia algo en la lista de la compra. Un diseño así son dos cabinas del mismo tipo, un enlace entre sitios que aguante la latencia de la escritura síncrona, direccionamiento idéntico a ambos lados y un tercer punto para el mediador. No es la opción por defecto para todo: es la opción para lo que de verdad no puede perder un dato.
Replicación síncrona y backup resuelven problemas distintos
Tener RPO 0 no elimina la necesidad de hacer copias. Son mecanismos complementarios y responden a amenazas diferentes.
La replicación síncrona protege frente a fallos de infraestructura y pérdida de una ubicación. No protege frente a lo que se hace mal dentro del dato: si una aplicación borra registros, si alguien elimina un directorio por error o si un cifrado de ransomware empieza a arrasar ficheros, esos cambios llegan al segundo sistema tan rápido como todo lo demás. Con RPO 0, el desastre también se replica con RPO 0.
Por eso una arquitectura de protección seria se construye por capas:
| Capa | Frente a qué protege |
|---|
| Alta disponibilidad local | Fallo de un servidor o de un componente |
| Replicación síncrona | Fallo de la cabina o pérdida de una ubicación |
| Snapshots | Errores recientes, recuperación rápida de versiones |
| Backup independiente e inmutable | Borrados, corrupción, ransomware, recuperación histórica |
| Segundo centro de datos | Incidencia grave de sitio |
La combinación concreta la marcan los objetivos de recuperación de cada aplicación. Para muchos servicios es perfectamente razonable asumir un RPO de minutos u horas a cambio de menos complejidad y menos coste. Para bases de datos transaccionales, ERP, plataformas financieras o determinados repositorios de ficheros, la respuesta suele ser otra. Sobre la capa de copias, la referencia sigue siendo la regla 3-2-1 con backup inmutable frente a ransomware.
Cómo lo vemos desde cloudprivado.com
En las arquitecturas que diseñamos, el almacenamiento en red NAS/SAN se apoya en cabina empresarial NetApp, con NFS e iSCSI sobre tejido dedicado, snapshots y geo-replicación entre centros de datos en España y la UE. Y cuando la carga no admite pérdida de datos, la conversación va al almacenamiento síncrono entre dos sitios, con su tercer punto de quórum para evitar el split-brain.
Que NFS y SMB entren en SnapMirror active sync amplía el catálogo de cargas a las que se puede ofrecer ese nivel de continuidad sin pedirle a nadie que cambie de protocolo. Con dos condiciones que ponemos siempre encima de la mesa antes de dibujar nada:
- No todo necesita RPO 0. La pregunta correcta no es «¿me lo puedes dar?», sino «¿qué me cuesta perder quince minutos de esta carga concreta?». Casi siempre hay dos o tres sistemas que justifican el síncrono y una docena que van perfectos con réplica asíncrona.
- La foto completa incluye el backup. Un diseño con dos sitios en espejo y sin copias inmutables no es una arquitectura de continuidad, es un único punto de fallo lógico repartido en dos edificios.
Si estás valorando repartir infraestructura entre dos centros de datos y no tienes claro qué cargas merecen replicación síncrona y cuáles no, esa es exactamente la conversación que nos gusta tener antes de que nadie firme una cabina.
Preguntas frecuentes
¿Qué es SnapMirror active sync?
Es la tecnología de NetApp ONTAP para continuidad de negocio: replica datos de forma síncrona entre dos sistemas y permite que las aplicaciones conmuten al secundario sin intervención manual ni scripts propios. Se llamaba SnapMirror Business Continuity antes de ONTAP 9.15.1. Con 9.19.1 amplía su soporte a NAS con NFS y SMB.
¿SnapMirror active sync para NAS ofrece RPO 0 y RTO 0?
RPO 0 sí, en todos los escenarios NAS soportados. El RTO depende del protocolo: la conmutación es no disruptiva con NFS v3 en adelante y con recursos SMB 3 Continuous Availability, mientras que en SMB 2 y SMB 3 sin CA hay interrupción durante el failover aunque no se pierdan datos.
¿Puedo usar el sistema secundario para algo mientras tanto?
Por los protocolos NAS no: la SVM secundaria está dormida y sus LIF caídas para no colisionar con las IP del primario. Lo que sí puedes hacer es clonar sus volúmenes dentro de otra SVM y usar esos clones para desarrollo, pruebas, UAT o informes sin afectar a la relación de protección.
¿Hace falta un tercer centro de datos?
Hace falta un tercer punto de quórum. ONTAP Mediator se instala en un host Linux en un emplazamiento con energía y red independientes de los dos clústeres; desde ONTAP 9.17.1 existe la alternativa de ONTAP Cloud Mediator, alojado por NetApp, que evita tener que montar y mantener ese tercer sitio.
¿La replicación síncrona sustituye al backup?
No, y conviene tenerlo claro: resuelven problemas distintos. La replicación mantiene la disponibilidad ante fallos de infraestructura; el backup te devuelve un estado anterior cuando el problema está en el propio dato —un borrado, una corrupción, un cifrado por ransomware—. Un cambio destructivo se replica igual de rápido que uno legítimo.
¿Puedo migrar una relación de SVM DR existente a esta configuración?
No de forma directa en ONTAP 9.19.1. Hay que eliminar la relación de SVM DR, crear una SVM de destino nueva, establecer la relación de SnapMirror active sync e inicializarla.
Fuentes
¿Tienes cargas sobre NFS o SMB que no pueden perder datos y no sabes si justifican replicación síncrona? Analizamos contigo carga por carga qué RPO necesita cada una y diseñamos la arquitectura entre dos centros de datos sin pagar por cero donde no hace falta. Empieza por el almacenamiento síncrono o hablemos de tu proyecto.
