Replique el grupo, no el disco: consistencia en la replicación entre cabinas
Por qué replicar cada volumen por separado puede dejar una copia remota que no arranca, cómo lo arreglan los grupos de consistencia y cómo probar una réplica sin riesgo.
La replicación entre cabinas parece la forma más sencilla de disaster recovery: la cabina copia sus discos a otra cabina en otro datacenter, y nada dentro de sus servidores tiene que cambiar. Es así de sencillo, siempre que replique juntas las cosas correctas. Replique cada volumen por su cuenta y puede acabar con una copia perfecta de cada disco y una base de datos que se niega a arrancar.
Una copia de cada disco no es una copia de la aplicación
La mayoría de las aplicaciones serias escriben en más de un volumen. Una base de datos guarda sus ficheros de datos en un disco y su log de transacciones en otro. Un servidor de correo separa el almacén de mensajes de sus logs. Una máquina virtual puede tener un disco de sistema y un disco de datos que solo tienen sentido juntos.
Estas aplicaciones dependen del orden de escritura. La base de datos escribe primero el registro del log y después la página de datos, y al recuperarse reproduce el log para llevar los ficheros de datos a un punto consistente. Si la copia del volumen del log en la sede remota es unos segundos más antigua que la copia del volumen de datos, la sede remota tiene páginas de datos que apuntan a registros del log que allí no existen. La base de datos ve un estado imposible. En el mejor de los casos se recupera con trabajo; en el peor, no abre.
Cuando cada volumen se replica de forma independiente, cada copia avanza a su propio ritmo, así que los discos remotos casi nunca están en el mismo instante. La respuesta es un grupo de consistencia: un conjunto de volúmenes que la cabina replica como una sola unidad, conservando el orden de las escrituras en todos ellos. En HPE 3PAR es un grupo de Remote Copy. Otras cabinas tienen su propio nombre para la misma idea. Se llame como se llame, la regla es la misma. Todo lo que una aplicación necesita para arrancar va en un solo grupo.
Elegir qué va en un grupo
Empiece por la aplicación, no por la lista de volúmenes:
- Enumere cada volumen en el que escribe la aplicación, incluidos los fáciles de olvidar: el volumen con el archivo del binary log o del write-ahead log, un tablespace temporal separado, un disco de configuración.
- Póngalos todos en un solo grupo.
- Mantenga las aplicaciones no relacionadas en grupos separados, para que una pueda conmutarse, probarse o pausarse sin tocar la otra.
Después decida cuánto se acerca la copia al original.
¿Cómo de cerca debe estar la copia?
Hay dos grandes familias de modos de replicación, y la elección tiene tanto de física como de preferencia.
El modo síncrono mantiene la copia al día a costa de un viaje de ida y vuelta en cada escritura, pequeño a distancia metropolitana y medible entre países. El asíncrono funciona a velocidad local y el retraso es su punto de recuperación.
Ninguno es correcto en general. Un sistema transaccional cuyo último minuto de pedidos es valioso puede justificar la latencia de escritura; una plataforma de contenidos que puede perder unos minutos de ediciones normalmente no. La respuesta correcta sale de preguntar qué le costaría al negocio perder ese intervalo, y de medir después si la aplicación tolera la latencia del modo más estricto.
Mantenga la replicación fuera del camino de producción
El tráfico de replicación compite con la E/S de los hosts si usted lo permite. Dele puertos dedicados en la cabina, mantenga esos puertos apartados de los que usan los hosts, y limite cada enlace de replicación a un único partner. Vigile el retraso de la replicación, no solo el estado del enlace. Un enlace que está arriba mientras la copia se queda más atrás cada hora es el modo de fallo que convierte un plan de disaster recovery en una sorpresa.
Pruebe la réplica sin romperla
Una réplica que nunca se ha arrancado es una esperanza. La buena noticia es que puede probarla sin interrumpir la replicación:
- Tome un snapshot en un punto en el tiempo de los volúmenes secundarios del grupo en la cabina remota. Haga el snapshot del grupo entero a la vez, para que la copia de prueba sea tan consistente como la réplica.
- Presente los snapshots a un host de prueba aislado en la sede remota. Mantenga ese host fuera de la red de producción, para que la copia no pueda responder tráfico real, enviar correo real ni ejecutar tareas programadas contra sistemas reales.
- Arranque la aplicación exactamente como lo haría en un desastre, usando su runbook escrito y nada más.
- Compruébela a nivel de aplicación: la base de datos abre y pasa su propia comprobación de consistencia, los recuentos de filas y los registros más recientes están donde el punto de recuperación dice que deberían estar, y un inicio de sesión en la aplicación funciona.
- Cronométrelo, desde la decisión de conmutar hasta la primera transacción con éxito. Ese número es su tiempo real de recuperación, diga lo que diga el plan.
- Elimine los snapshots y registre el resultado, incluido cualquier cosa que le haya sorprendido.
Ejecute la prueba después de cualquier cambio en el grupo, y con una periodicidad regular aunque nada haya cambiado, porque las aplicaciones añaden volúmenes sin hacer ruido.
La replicación no es backup
La replicación copia los cambios fielmente, y eso incluye una tabla borrada, un cifrado por ransomware y un despliegue defectuoso. En segundos o minutos el error está en los dos sitios. Una réplica le protege de perder una sede; los backups con historial le protegen de sus propios datos. Necesita ambos, y los backups debería extraerlos un sistema al que el lado de producción no pueda llegar.
Cómo lo hacemos nosotros
Entre nuestros datacenters de Atenas y Ámsterdam, los volúmenes de los clientes pueden replicarse cabina a cabina en HPE 3PAR, con los volúmenes relacionados colocados en el mismo grupo de Remote Copy para que se mantengan consistentes entre sí. El modo de replicación se acuerda por servicio, la replicación corre por puertos dedicados, un partner por par de puertos, sobre nuestra propia interconexión privada entre las sedes, y las réplicas de datos alojados en la UE se quedan dentro de nuestra infraestructura en la UE. Dentro de cada sede las cabinas están en federación, así que los volúmenes también se mueven entre cabinas en caliente. Los backups están al lado, separados y pull-only.
Si no está seguro de que su copia remota arrancaría el día que la necesite, merece la pena averiguarlo en un día tranquilo. Con gusto le ayudamos a diseñar los grupos y la prueba.
Related
- /what-we-do/storage-compute/storage-replication-federation/
- /what-we-do/storage-compute/disaster-recovery/
- /what-we-do/storage-compute/enterprise-san-storage/
Publicado el 25 de agosto de 2026.
Todas las notas de campo